主叫SA用戶回落3G的問(wèn)題處理

某運(yùn)營(yíng)商反饋，SA用戶作為主叫時(shí)，出現(xiàn)回落3G的現(xiàn)象。

第一階段排查(異廠商N的MME區(qū)域1）：查看5GC各網(wǎng)元的交換信令，未發(fā)現(xiàn)異常。

1.2025.461，IMS網(wǎng)絡(luò)從5G無(wú)線側(cè)接入，pdusession id為1，IP地址為 2408300//，如下圖所示。



2.查詢對(duì)應(yīng)地址的數(shù)據(jù)跟蹤時(shí)間點(diǎn)，如下圖所示。

3.2025.941，3gnet從5G無(wú)線側(cè)接入，pdusession id為2，如下圖所示。

4.2029.441，PCF發(fā)起專載建立，如下圖所示。

5.2029.471 基站開(kāi)始回落，如下圖所示。

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

7.發(fā)起4G網(wǎng)絡(luò)下專載恢復(fù)，并且完成，如下圖所示。

8.后續(xù)信令都無(wú)異常。

9.2032.751，發(fā)起更新以后，2053.491用戶發(fā)起掛機(jī)，中間20s沒(méi)有任何信令，如下圖所示。

10.查看該段時(shí)間對(duì)應(yīng)的數(shù)據(jù)跟蹤，主叫和SBC進(jìn)行IMS交互，即該段時(shí)間沒(méi)有發(fā)現(xiàn)用戶回落3G的情況，有200 OK響應(yīng)消息和Sender Report消息，如下圖所示。

11.在此期間核心網(wǎng)控制面和媒體面均正常。

12.2053，用戶先發(fā)起B(yǎng)YE請(qǐng)求消息?？刂泼骈_(kāi)始釋放流程，需要進(jìn)一步核查用戶發(fā)送BYE消息的原因。IMS側(cè)無(wú)法查看到此時(shí)間段內(nèi)的用戶信令。

第二階段排查：異廠商H的MME區(qū)域?，F(xiàn)象：主叫撥出后自己掛斷，被叫還在振鈴。

13.SBC不停的發(fā)送承載更新請(qǐng)求，多次更新后SMF釋放了承載，網(wǎng)絡(luò)側(cè)發(fā)起修改的時(shí)候，收到MME/SGW發(fā)起承載修改請(qǐng)求，如下圖所示。

14.分析異常信令：網(wǎng)絡(luò)側(cè)發(fā)起epsbid7和8專載修改時(shí)，收到MME/SGW發(fā)起epsbid=6默載修改請(qǐng)求，如下圖所示。

15.在測(cè)試過(guò)程中普遍反饋SBC 503（ASR 承載釋放）較多，分析5GC信令，被叫簽約中有視頻彩鈴，QCI2專載建立后有一次AMBR更新，GTP Update Bearer Request和GTP Modify Bearer Command產(chǎn)生碰撞，如下圖所示。

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

17.PCF向SBC發(fā)送ASR消息，如下圖所示。

18.通過(guò)對(duì)比業(yè)務(wù)正常的信令發(fā)現(xiàn)：正常的流程AMBR為30720，異常的流程AMBR為30000，如下圖所示。

19.與MME側(cè)討論發(fā)現(xiàn)SGW收到GTP Update Bearer Request消息，轉(zhuǎn)發(fā)給MME后，SGW直接給SMF發(fā)送GTP Modify Bearer Command，在SGW上沒(méi)有MME GTP Modify Bearer Command。

20.初步結(jié)論：UDM?5G和4G簽約模板速率單位不一致，導(dǎo)致流程沖突。4G的簽約為30000Kbps，MME發(fā)出ULR請(qǐng)求，HSS返回ULA攜帶4G的簽約AMBR值，由30000Kbps換算成了30720000bps，和從5G側(cè)獲取的（30mbps，轉(zhuǎn)換為300000 kbps)不一致。

MME發(fā)起MBC修改，和SMF的UBR消息概率流程沖突，釋放承載。

21.與客戶溝通后：將測(cè)試卡4G簽約30000000 bit/s，5G簽約30 Mpbs后繼續(xù)撥測(cè)。分析信令：SMF在特定流程中收到Modify bearer Command時(shí)通過(guò)N7接口上報(bào) res_all_fail。

調(diào)整統(tǒng)一UDM上4G、5G簽約后，信令觀察看已基本抑制了MME對(duì)IMS承載的MBC消息，業(yè)務(wù)正常。

第三階段排查：異廠商N(yùn)的MME區(qū)域2，現(xiàn)象：主叫撥出后自己掛斷，被叫還在振鈴。

22.異廠商N(yùn)的MME區(qū)域2簽約AMBR一致情況下，仍然觸發(fā)MBC消息，對(duì)比異廠商H的MBC，異廠商N(yùn)多攜帶FTEID信息，如下圖所示。

23.異廠商N(yùn)的MME答復(fù)從N26接口處獲取的PL=1，和ULA取到的不一樣，ULA取到的ARP是6，所以會(huì)發(fā)送GTP Modify Bearer Command修改，如下圖所示。

24.分析所有正常、異常信令：SMF在收到IMS 承載首次MBC消息后均未做UBReq交互處理（數(shù)據(jù)業(yè)務(wù)APN可以正常交互），后續(xù)MBC重發(fā)過(guò)程和其他業(yè)務(wù)流程概率碰撞后，導(dǎo)致N7上報(bào)res_all_fail，呼叫流程異常。

25.與PCF側(cè)溝通得知：在EPSfallback流程中，當(dāng)PCF下發(fā)的IMS會(huì)話的ARP與UDM簽約的ARP不一致時(shí)，假設(shè)MME從AMF獲取的上下文中IMS會(huì)話的ARP是1，而從UDM簽約獲取的ARP是6，會(huì)導(dǎo)致MME會(huì)主動(dòng)發(fā)起IMS會(huì)話的MBC消息進(jìn)行QoS修改。

由于對(duì)于IMS APN，一般情況4G和5G簽約的速率一樣，所以正常EPSFB流程可以不進(jìn)行MBC流程。

26.為了優(yōu)化流程，需要將PCF的IMS會(huì)話ARP配置修改為6，和UDM簽約保持一致。目前現(xiàn)網(wǎng)配置都為1，如圖18和圖19所示。











修改ARP優(yōu)先級(jí)，將PCF的IMS會(huì)話ARP配置修改為6，和UDM簽約保持一致，后續(xù)測(cè)試業(yè)務(wù)正常。