INVITE消息未轉(zhuǎn)發(fā)導(dǎo)致被叫無法接通的問題處理

故障處理

某運(yùn)營(yíng)商在VoLTE測(cè)試中，發(fā)現(xiàn)有被叫不通的現(xiàn)象，對(duì)其中一次抓包問題進(jìn)行定位分析。

故障分類

1.SBC分析用戶的VoLTE信令，發(fā)現(xiàn)SBC向被叫用戶發(fā)送INVITE消息并重發(fā)4次，未收到被叫終端的回復(fù)，如圖1所示。

圖1 VoLTE信令

2.對(duì)UPF上的的用戶面抓包分析，發(fā)現(xiàn)UPF收到了5個(gè)INVITE包，但是未封裝成GTP轉(zhuǎn)發(fā)給基站，如圖2所示。

圖2 用戶面分析

3.分析用戶信令，發(fā)現(xiàn)CTNET的UPF由于下行數(shù)據(jù)包先觸發(fā)了到SMF的Session_ Report_Request流程。SMF發(fā)送N1N2MessageTransfer Request消息給AMF，要求建立用戶面連接。此動(dòng)作觸發(fā)了AMF的尋呼(paging)流程，如圖3所示。

圖3 尋呼流程

4.當(dāng)INVITE下行數(shù)據(jù)包觸發(fā)IMS UPF到SMF的Session_Report_Request流程時(shí)，SMF發(fā)送N1N2消息給AMF(226)，要求建立用戶面連接。由于AMF針對(duì)用戶的尋呼正在進(jìn)行中，AMF向SMF回復(fù)了HIGHER_PRIORITY_REQUEST_ONGOING的流程沖突失敗，如圖4所示。

圖4 流程沖突

5.當(dāng)用戶尋呼上來后，AMF通過PDUSession_UpdateSMContext Request消息(238)通知SMF為對(duì)應(yīng)的PDU會(huì)話建立用戶面連接，SMF發(fā)送Session_Modification_ Request消息通知CTNET的UPF建立用戶面鏈接。

6.由于之前AMF對(duì)IMS UPF觸發(fā)的N1N2流程已經(jīng)回復(fù)了拒絕，所以此處AMF不會(huì)再針對(duì)IMS會(huì)話觸發(fā)PDUSession_UpdateSMContext Request消息建立用戶面會(huì)話。導(dǎo)致UPF上IMS會(huì)話的INVITE消息無法轉(zhuǎn)發(fā)給基站，如圖5所示。

圖5 INVITE消息無法轉(zhuǎn)發(fā)

7.AMF收到SMF的N1N2請(qǐng)求后，處理動(dòng)作有兩種：

a.如果UE處于空閑態(tài)，AMF向UE所在注冊(cè)區(qū)域內(nèi)的所有g(shù)NB發(fā)送尋呼消息。

b.如果UE處于連接狀態(tài)，AMF不需要發(fā)起尋呼流程，AMF直接調(diào)用SMF的服務(wù)化接口Nsmf_PDU Session_Update SM Context Request請(qǐng)求SMF為對(duì)應(yīng)的PDU會(huì)話建立用戶面連接。

8.由于AMF上用戶的狀態(tài)是用戶級(jí)別的(空閑態(tài)/連接態(tài))，在已經(jīng)通過尋呼流程改變用戶狀態(tài)的過程中，第二次SMF發(fā)送的N1N2請(qǐng)求屬于沖突流程。但是SMF針對(duì)報(bào)沖突的會(huì)話流程，需要有保護(hù)措施，以保證下行數(shù)據(jù)包能夠正常轉(zhuǎn)發(fā)。

故障處理

MF后續(xù)版本優(yōu)化此問題的處理流程，針對(duì)報(bào)沖突失敗的N1N2MessageTransfer流程，需要在一定時(shí)間間隔后重發(fā)N1N2MessageTransfer Request請(qǐng)求，以便在用戶變成連接態(tài)后，可以繼續(xù)轉(zhuǎn)發(fā)之前沖突流程的下行數(shù)據(jù)包。本次先通過SMF熱補(bǔ)丁方式實(shí)現(xiàn)此優(yōu)化功能。

審核編輯：湯梓紅