故障處理

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

故障分類

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

圖1 VoLTE信令

2.對UPF上的的用戶面抓包分析，發(fā)現(xiàn)UPF收到了5個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，要求建立用戶面連接。此動作觸發(fā)了AMF的尋呼(paging)流程，如圖3所示。

圖3 尋呼流程

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

圖4 流程沖突

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

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

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

7.AMF收到SMF的N1N2請求后，處理動作有兩種：

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

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

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

故障處理

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

審核編輯：湯梓紅