EPSFallBack呼叫失败的问题处理

故障现象

某运营商反馈存在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后续版本解决更新默载的流程与创建语音专载流程冲突，造成后续建专载失败。

审核编辑：汤梓红