故障現(xiàn)象

用戶反饋在語音呼叫中出現(xiàn)VoLTE會話呼叫異常，出現(xiàn)掉落2G現(xiàn)象。

故障分析

通過SBC側(cè)進行跟蹤，分析用戶在異常時間點的會話信令。

1.用戶A先作為被叫，接到用戶B的INVITE請求消息，如下圖所示。

2.用戶A在0.6秒內(nèi)立即拒絕呼叫，向用戶B發(fā)送603響應，表示拒絕接聽。603通常為手機振鈴時點擊拒絕發(fā)送。

3.用戶A拒絕用戶B發(fā)起的呼叫后，在0.003秒內(nèi)再次瞬間向用戶C發(fā)起了INVITE呼叫請求，如下圖所示。

4.此會話特征為，在少于1秒之內(nèi)，連續(xù)發(fā)生了會話建立、會話刪除、會話建立。

通過SMF側(cè)進行跟蹤，用戶在異常時間點的控制信令分析。

5.1024.129用戶在5G網(wǎng)絡。SMF收到PCF第一次發(fā)起的專載創(chuàng)建請求，SMF成功處理后開始正常進入EPSFB流程。

6.1024.149 5G網(wǎng)絡內(nèi)完成EPSFB流程，開始等待前向的切換請求，如下圖所示。

7.1024.679 SMF第二次收到PCF的通知，請求刪除當前語音專載。此時間對應用戶已拒絕了呼叫。但會話流程還未完成切換。

8.1024.729 SMF收到AMF發(fā)起的Retrive請求以及前向的TAU請求，SMF開始處理5G到4G的TAU流程，因切換優(yōu)先級高，PCF的刪除請求將被暫時緩存，如下圖所示。

9.1024.939 完成TAU后，會話用戶已在4G網(wǎng)絡，此時SMF/PGW開始準備彈出緩存的專載創(chuàng)建/刪除請求。

10.1024.939 SMF第三次收到PCF發(fā)起的專載創(chuàng)建請求，本次專載規(guī)則相同，對應用戶在掛機后于瞬間開始再次發(fā)起呼叫。

11.因SMF正在處理前期已緩存的PCF消息，同時緩存消息中包含刪除規(guī)則信息，對于本次請求進行拒絕，如下圖所示。

12.1025.469 SMF將緩存的PCF消息彈出并完成處理，如下圖所示。

13.此會話特征：在1秒內(nèi)連續(xù)不停的建立專載，刪除專載，建立專載。

1.綜合上述分析，此異常觸發(fā)場景為極短的時間內(nèi)（小于1秒），用戶連續(xù)進行語音業(yè)務，完成建立、刪除、再建立等流程。

2.在IMS側(cè)，業(yè)務會按序觸發(fā)。

3.在SMF側(cè)，因包含EPSFB流程，極短時間內(nèi)連續(xù)發(fā)起業(yè)務，會進入多重沖突緩存流程。SMF的當前處理邏輯如下圖所示。

a.在收到第一次PCF發(fā)起的專載建立請求后，SMF的PCC模塊會通知接入ACTL模塊，觸發(fā)業(yè)務。

b.在接入側(cè)EPSFB流程還未完成時，SMF又立即收到了專載釋放，此時會按優(yōu)先級判斷承載非穩(wěn)態(tài)，消息暫緩處理。由于EPSFB流程未結(jié)束，此時PCC無法確認出接入流程狀態(tài)，選擇緩存而非通知接入側(cè)走釋放流程，可避免接入側(cè)多網(wǎng)元間因被強制打斷而出現(xiàn)更多的沖突場景。待EPSFB流程完全結(jié)束后，會發(fā)起緩存的釋放。

c.在接入側(cè)依然未完成時，PCF再次發(fā)起相同規(guī)則的建立，SMF的PCC模塊會根據(jù)已緩存規(guī)則判斷，因已緩存同規(guī)則的刪除消息，SMF將拒絕本次請求。此處進行拒絕，不繼續(xù)緩存，可提升用戶的感知而不必長時間等待，也避免此場景出現(xiàn)疊加緩存。此處不進行更新，因為上個流程還未完成便強制更新會帶來風險。

4.綜上所述分析：因EPSFB與瞬時連續(xù)專載建立并發(fā)沖突，當前SMF會選擇優(yōu)先完成EPSFB切換等流程。

審核編輯：湯梓紅