网络侧语音被叫失败案例流程分析

案例一：5GC语音被叫无法接通

分析流程

1）跟踪UPF数据，发现IMS已经下发了INVITE消息给终端。

2）获取SEQ跟踪消息。

3）分析媒体面，终端下发了INVITE后没有响应。分析5GC控制面信令，此时N4接口上报了下行数据测量报告，说明终端处于空闲态，如图1所示。 

图1 控制面信令

4）继续分析后续信令发现AMF给SMF上报尝试寻呼终端，告知SMF等待寻呼，如图2所示。

图2 寻呼终端

5）经过20秒等待，AMF告知SMF寻呼终端失败，如图3所示。

图3 寻呼失败

6）对比网络侧寻呼流程发现，AMF没有发送paging消息给终端，如图4所示。

图4 寻呼流程

7）AMF处理寻呼消息的服务是MT，如图5所示。

图5 查询服务

8）综上分析：目前版本处理寻呼存在缺陷，会导致单用户偶发寻呼进程异常，终端在AMF存在异常后无法恢复。

案例二：INVITE消息未转发导致被叫无法接通

分析流程

1）VoLTE信令中SBC向被叫用户发送了INVITE消息，并且重发了4次，都未收到被叫终端的回复，如图1所示。

图1 VoLTE信令

2）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，要求建立用户面连接。由于AMF对用户的寻呼正在进行中，AMF向SMF回复了HIGHER_PRIORITY_REQUEST_ONGOING，即流程冲突失败，如图4所示。 

图4 流程冲突

5）AMF通过PDUSession_UpdateSMContext Request消息通知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请求后，处理动作有两种：

（1）如果UE处于空闲态，AMF向UE所在注册区域内的所有gNB发送寻呼消息。

（2）如果UE处于连接状态，AMF不需要发起寻呼流程，直接调用SMF的服务化接口Nsmf_PDU Session_Update SM Context Request请求SMF为对应的PDU会话建立用户面连接。

8）由于AMF上用户的状态是用户级别的（空闲态/连接态），在已经通过寻呼流程改变用户状态的过程中，第二次SMF发送的N1N2请求属于冲突流程。因此SMF针对报冲突的会话流程，需要有保护措施，以保证下行数据包能够正常转发。

欢迎关注微信公众号“我想我思”