VoNR呼叫失败问题处理

故障现象

某厂商终端在移动网络区域VoNR呼叫失败。

故障分析

1.核心网下发语音专载建立更新流程，如下图所示。

2.基站回复语音专载更新失败，如下图所示。

3.基站在回复语音专载更新失败的同时，发起UE Context Release Request消息，原因为radio_conectiont_with_ue_lost，如下图所示。

4.AMF向SMF连续发送两条Nsmf_PDUSession_UpdateSMContext Request 消息，第一条为通知基站返回语音专载更新失败，第二条为无线发起的UE Context Release Request触发，AMF需要指示SMF将会话进入idle状态，如下图所示。

5.AMF向SMF发送Nsmf_PDUSession_UpdateSMContext Request 消息为连续发送，时间几乎一样，经过传输后顺序稍有差异，SMF先接收到的是将IMS会话进入idle态的Nsmf_PDUSession_UpdateSMContext Request消息，基站回复专载更新响应，如下图所示。

6.当前运营商的SMF在收到基站语音专载建立或更新流程的机制是：判断基站回复的失败态原因值为radio_conectiont_with_ue_lost，归入语音专载失败处理，继而给PCF发送Npcf _SMPolicyControl_Update Request消息，指示RES_ALLO_FAIL。后续PCF通知IMS，IMS会触发SIP 503 Service Unavailable。本次语音呼叫失败，如下图所示。

7.综上分析：中兴通讯SMF在上述语音专载建立/更新流程，根据AMF指示的基站专载建立失败原因值，可以有2种处理：

a.归入语音专载失败处理，呼叫直接失败。

b.挂起语音专载处理，等待延时弹出缓存定时器（默认200ms）和流程冲突定时器（默认3s）两个定时器超时后，可重新尝试语音专载。即在IMS定时器超时前，SMF可能再尝试2次语音专载建立/更新，如果UE在此之前恢复了与基站的连接，呼叫可继续接续。

8.上述原因值可在网管中进行配置，未配置的原因值默认为1）类处理。为了保持与之前版本处理一致，当前所有局点的工程配置中，并未配置radio_conectiont_with_ue_lost。因此当前呼叫必定失败。

9.必须要说明的是，即使SMF将radio_conectiont_with_ue_lost原因值配置为2）类处理，核心网也只能尝试。在极端场景下，SMF的2次语音专载建立/更新重试也不能保证呼叫一定成功。例如：如果UE没有重新与基站恢复空口链接，核心网无法寻呼到UE，或者重新接入到其他核心网网元，呼叫仍然失败。

故障处理

在SMF增加配置，将radio_conectiont_with_ue_lost原因值归为b类处理，并进一步观察。配置命令如下：

ADD N2ONGOINGCFG: RADIO_CONNECTION_WITH_UE_LOST
 

审核编辑：汤梓红