EPSFallBack呼叫失敗的問題處理

故障現(xiàn)象

某運營商反饋存在EPSFallBack呼叫失敗的現(xiàn)象。

故障分析

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

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

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

圖2 攜帶ARP

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

圖3 下發(fā)新的ARP

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

圖4 創(chuàng)建資源

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

圖5 承載更新流程

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

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

圖6 流程處理1

圖7 流程處理2

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

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

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

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

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

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

圖8 信令流程圖

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

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

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

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

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

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

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

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

故障處理

1.執(zhí)行如下命令，SMF關(guān)閉彈出緩存延時定時器，恢復(fù)到與升級前處理一致。

SET NAMFCOMPATIBILITY:DELAYTIMER="0"

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

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

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