INVITE消息未轉發導致被叫無法接通的問題處理

故障處理

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

故障分類

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

圖1 VoLTE信令

2.對UPF上的的用戶面抓包分析，發現UPF收到了5個INVITE包，但是未封裝成GTP轉發給基站，如圖2所示。

圖2 用戶面分析

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

圖3 尋呼流程

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

圖4 流程沖突

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

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

圖5 INVITE消息無法轉發

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

a.如果UE處于空閑態，AMF向UE所在注冊區域內的所有gNB發送尋呼消息。

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

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

故障處理

MF后續版本優化此問題的處理流程，針對報沖突失敗的N1N2MessageTransfer流程，需要在一定時間間隔后重發N1N2MessageTransfer Request請求，以便在用戶變成連接態后，可以繼續轉發之前沖突流程的下行數據包。本次先通過SMF熱補丁方式實現此優化功能。

審核編輯：湯梓紅