故障現象

某運營商反饋存在EPSFallBack呼叫失敗的現象。

故障分析

1.1639.452 用戶從4G返回5G，SMF收到Nsmf_PDUSession_CreateSMContext Request消息，開始處理IMS會話的IDLE態的4G TAU 到5G流程，如圖1所示。

圖1 4用戶從4G返回5G

2.1639.462 SMF發送Npcf_SMPolicyControl_Update Request消息給PCF，上報RatType改變的同時，也攜帶ARP給PCF，如圖2所示。

圖2 攜帶ARP

3.1639.482 PCF發送Npcf_SMPolicyControl_Update Response消息給SMF，下發新的ARP，如圖3所示。

圖3 下發新的ARP

4.1639.482 SMF判斷ARP中Priority Level發生了變化需要發起承載更新。由于UE當前是IDLE態，SMF會先發送Namf_Communication_N1N2MessageTransfer Request給AMF去基站創建資源，如圖4所示。

圖4 創建資源

5.1639.562 SMF收到Nsmf_PDUSession_UpdateSMContext Request恢復連接態后，為避免前端流程還未處理完就下發消息造成前端沖突，會延時200 ms(可配置)再發送承載更新流程，如圖5所示。

圖5 承載更新流程

6.1639.682 SMF在200ms超時前收到了PCF發送的Npcf_SMPolicyControl_ UpdateNotify Request請求建立專載，SMF判斷該流程優先級高，掛起更新流程，立即開始處理創建語音的專載流程。

7.本次語音可以正常進行并觸發EPS Fallback，但是回落后沒有將掛起的更新流程終止，一旦用戶從5G回到4G再回到5G后，SMF會判斷ARP改變再次需要觸發更新流程。當再次收到專載建立時發現該用戶已有2個會話更新流程，不再處理專載建立流程，當2個會話更新流程中的其中一個處理完成后，可以處理新的專載建立流程，如圖6和圖7所示。

圖6 流程處理1

圖7 流程處理2

8.綜上分析，主要場景如下：

a.用戶從4G切回5G。

b.UDM簽約和PCF簽約的ARP中的值不一致，會觸發SMF在4G到5G后發起承載更新流程。

c.在承載更新流程結束前(200 ms)，SMF又收到了語音專載建立流程，優先保證語音通話，本次語音專載建立流程可以成功，掛起承載更新流程。

d.當用戶從5G到4G，掛斷電話后，再回到5G，由于ARP不一致，再次發起了承載更新。如果上次的承載更新流程沒有結束，該用戶會存在2個更新流程待處理，再收到專載建立時不再處理，影響呼叫。

9.4G切回5G TAU流程的信令流程如圖8所示。

圖8 信令流程圖

第1步：開始4G切5G的TAU流程。

第2~3步：更新U面資源。

第4步：4G切5G完成，SMF返回響應消息給AMF。

第5步：SMF通知PCF RatType改變。

第6步：SMF收到PCF響應，需要更新ARP。如果UDM與PCF簽約一致，不需要更新ARP，此時SMF的4G切5G的TAU流程處理完成。

第7~12步：UDM與PCF簽約不一致，需要更新ARP給基站，先向基站申請資源，將IDEL態轉為CONNECT態。

第13步：啟動彈出緩存延時定時器，解決基站、AMF和SMF三方配合問題。

第14~15步：更新ARP發送給基站。 10.綜上分析：4G切回5G時，由于UDM的ARP簽約與PCF不一致，SMF重新更新默認承載的ARP。SMF更新默認承載的ARP時與創建語音專載流程沖突，掛起專載更新，發生了5G到4G再到5G的切換流程后，再次觸發承載更新。此時用戶會存在2個更新流程待處理，SMF再收到專載建立時不再處理，影響呼叫。

故障處理

1.執行如下命令，SMF關閉彈出緩存延時定時器，恢復到與升級前處理一致。

SET NAMFCOMPATIBILITY:DELAYTIMER="0"

定時器實際是為了解決基站、AMF和SMF三方配合問題，關閉定時器可以臨時規避UDM與PCF簽約不一致問題，但是會增加創建專載流程與切換流程沖突場景下的時延。

2.UDM與PCF的ARP簽約不一致是本次的直接觸發原因，建議按照集團規范修改成一致，徹底消除由于不一致帶來的QoS協商冗余流程和信令開銷。

SMF后續版本解決更新默載的流程與創建語音專載流程沖突，造成后續建專載失敗。