完结小说,盗墓笔记有声小说,有声小说打包下载

某運營商反饋，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修改。