故障現象

某廠商終端在移動網絡區域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

審核編輯：湯梓紅