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热补丁方式实现此优化功能。

审核编辑：汤梓红