主叫SA用户回落3G的问题处理-电子发烧友网

某运营商反馈，SA用户作为主叫时，出现回落3G的现象。

第一阶段排查(异厂商N的MME区域1）：查看5GC各网元的交换信令，未发现异常。

1.2025.461，IMS网络从5G无线侧接入，pdusession id为1，IP地址为 2408300//，如下图所示。

2.查询对应地址的数据跟踪时间点，如下图所示。

3.2025.941，3gnet从5G无线侧接入，pdusession id为2，如下图所示。

4.2029.441，PCF发起专载建立，如下图所示。

5.2029.471 基站开始回落，如下图所示。

6.2030.221 回落完成，如下图所示。

7.发起4G网络下专载恢复，并且完成，如下图所示。

8.后续信令都无异常。

9.2032.751，发起更新以后，2053.491用户发起挂机，中间20s没有任何信令，如下图所示。

10.查看该段时间对应的数据跟踪，主叫和SBC进行IMS交互，即该段时间没有发现用户回落3G的情况，有200 OK响应消息和Sender Report消息，如下图所示。

11.在此期间核心网控制面和媒体面均正常。

12.2053，用户先发起BYE请求消息。控制面开始释放流程，需要进一步核查用户发送BYE消息的原因。IMS侧无法查看到此时间段内的用户信令。

第二阶段排查：异厂商H的MME区域。现象：主叫拨出后自己挂断，被叫还在振铃。

13.SBC不停的发送承载更新请求，多次更新后SMF释放了承载，网络侧发起修改的时候，收到MME/SGW发起承载修改请求，如下图所示。

14.分析异常信令：网络侧发起epsbid7和8专载修改时，收到MME/SGW发起epsbid=6默载修改请求，如下图所示。

15.在测试过程中普遍反馈SBC 503（ASR 承载释放）较多，分析5GC信令，被叫签约中有视频彩铃，QCI2专载建立后有一次AMBR更新，GTP Update Bearer Request和GTP Modify Bearer Command产生碰撞，如下图所示。

16.GTP Update Bearer Request和GTP Modify Bearer Command碰撞后，RES_ALLO_FAIL，如下图所示。

17.PCF向SBC发送ASR消息，如下图所示。

18.通过对比业务正常的信令发现：正常的流程AMBR为30720，异常的流程AMBR为30000，如下图所示。

19.与MME侧讨论发现SGW收到GTP Update Bearer Request消息，转发给MME后，SGW直接给SMF发送GTP Modify Bearer Command，在SGW上没有MME GTP Modify Bearer Command。

20.初步结论：UDM 5G和4G签约模板速率单位不一致，导致流程冲突。4G的签约为30000Kbps，MME发出ULR请求，HSS返回ULA携带4G的签约AMBR值，由30000Kbps换算成了30720000bps，和从5G侧获取的（30mbps，转换为300000 kbps)不一致。

MME发起MBC修改，和SMF的UBR消息概率流程冲突，释放承载。

21.与客户沟通后：将测试卡4G签约30000000 bit/s，5G签约30 Mpbs后继续拨测。分析信令：SMF在特定流程中收到Modify bearer Command时通过N7接口上报 res_all_fail。

调整统一UDM上4G、5G签约后，信令观察看已基本抑制了MME对IMS承载的MBC消息，业务正常。

第三阶段排查：异厂商N的MME区域2，现象：主叫拨出后自己挂断，被叫还在振铃。

22.异厂商N的MME区域2签约AMBR一致情况下，仍然触发MBC消息，对比异厂商H的MBC，异厂商N多携带FTEID信息，如下图所示。

23.异厂商N的MME答复从N26接口处获取的PL=1，和ULA取到的不一样，ULA取到的ARP是6，所以会发送GTP Modify Bearer Command修改，如下图所示。

24.分析所有正常、异常信令：SMF在收到IMS 承载首次MBC消息后均未做UBReq交互处理（数据业务APN可以正常交互），后续MBC重发过程和其他业务流程概率碰撞后，导致N7上报res_all_fail，呼叫流程异常。

25.与PCF侧沟通得知：在EPSfallback流程中，当PCF下发的IMS会话的ARP与UDM签约的ARP不一致时，假设MME从AMF获取的上下文中IMS会话的ARP是1，而从UDM签约获取的ARP是6，会导致MME会主动发起IMS会话的MBC消息进行QoS修改。