故障現(xiàn)象

某運(yùn)營(yíng)商VIP用戶反饋在通話2分鐘后，有掉話的現(xiàn)象發(fā)生。

故障分析

1.分析業(yè)務(wù)流程：UE發(fā)起CMNET的會(huì)話釋放，如下圖所示。

2.CMNET的會(huì)話釋放流程，收到PFCP_SESSION_DELETION_RES后，會(huì)給OCS發(fā)送釋放消息，如下圖所示。

3.IMS會(huì)話的retrieve流程處理完成，準(zhǔn)備5G切4G。

4.CMNET會(huì)話的retrieve流程與CMNET會(huì)話的釋放流程沖突，返回了504，如下圖所示。

5.CMNET會(huì)話的釋放流程處理結(jié)束，如下圖所示。

6.IMS會(huì)話5G切4G完成后，2分鐘后被釋放，如下圖所示。

7.梳理信令流程，如下圖所示。

a.SMF在用戶通話2分鐘時(shí)釋放會(huì)話，是因?yàn)镾MF的定時(shí)器誤刪IMS會(huì)話導(dǎo)致。

b.SMF的定時(shí)器誤刪IMS會(huì)話是由于CMNET會(huì)話的釋放流程與IMS會(huì)話的切換處于沖突中，SMF維護(hù)用戶上下文狀態(tài)錯(cuò)誤，導(dǎo)致定時(shí)器誤判斷此時(shí)用戶仍在5G。

c.CMNET會(huì)話的釋放流程與IMS會(huì)話的切換處于沖突，是因?yàn)镺CS響應(yīng)慢導(dǎo)致。

8.根據(jù)對(duì)信令流程的梳理，該問題出現(xiàn)的概率很低，小于萬分之0.5。

問題概率 = 2分鐘定時(shí)器超時(shí)刪除4G會(huì)話次數(shù) ÷ EPSFALLBACK流程的次數(shù)

分2個(gè)場(chǎng)景：

a.正常場(chǎng)景：4G切5G后，定時(shí)器刪4G會(huì)話。

b.異常場(chǎng)景：5G切4G后，定時(shí)器誤刪4G會(huì)話。

9.該現(xiàn)象必須要滿足下面5個(gè)條件才會(huì)發(fā)生。

a.用戶的2個(gè)會(huì)話必須在同一個(gè)SMF。

b.CMNET數(shù)據(jù)會(huì)話在語音呼叫前，在5G側(cè)發(fā)起釋放。

c.CMNET數(shù)據(jù)會(huì)話釋放流程中OCS響應(yīng)比較慢，CMNET數(shù)據(jù)會(huì)話釋放流程未結(jié)束。

d.CMNET數(shù)據(jù)會(huì)話釋放結(jié)束前，用戶IMS會(huì)話5G切4G完成。

e.用戶通話時(shí)長(zhǎng)超過2分鐘。

10.SMF啟動(dòng)2分鐘定時(shí)器是根據(jù)協(xié)議針對(duì)異常的保護(hù)。在5G切4G時(shí)，未收到AMF釋放5G會(huì)話；或者4G切5G時(shí)，未收到MME釋放4G會(huì)話，SMF通過啟動(dòng)定時(shí)器刪除資源。

11.SMF釋放會(huì)話時(shí)間短，正常釋放會(huì)話的流程只用了20毫秒，如下圖所示。

故障處理

1.綜上分析：用戶的CMNET數(shù)據(jù)會(huì)話在5G側(cè)發(fā)起釋放，由于OCS響應(yīng)慢，所以釋放流程未結(jié)束。同時(shí)用戶又發(fā)起了IMS語音呼叫。在IMS語音會(huì)話切換到4G后，SMF會(huì)啟動(dòng)定時(shí)器以保證用戶協(xié)議一致。由于CMNET會(huì)話的釋放流程與IMS會(huì)話的切換處于沖突中，SMF維護(hù)用戶上下文狀態(tài)錯(cuò)誤，導(dǎo)致定時(shí)器誤判斷此時(shí)用戶仍在5G，2分鐘后刪除了IMS語音會(huì)話。

2.在后續(xù)版本中解決該問題。

審核編輯：湯梓紅