故障現(xiàn)象
某運(yùn)營商反饋,SA用戶作為主叫時,出現(xiàn)回落3G的現(xiàn)象。
故障分析
第一階段排查(異廠商N(yùn)的MME區(qū)域1):查看5GC各網(wǎng)元的交換信令,未發(fā)現(xiàn)異常。1.20:17:25.461,IMS網(wǎng)絡(luò)從5G無線側(cè)接入,pdusession id為1,IP地址為2408:8574:300:4d3d://,如下圖所示。
2.查詢對應(yīng)地址的數(shù)據(jù)跟蹤時間點,如下圖所示。
3.20:17:25.941,3gnet從5G無線側(cè)接入,pdusession id為2,如下圖所示。
4.20:17:29.441,PCF發(fā)起專載建立,如下圖所示。
5.20:17:29.471 基站開始回落,如下圖所示。
6.20:17:30.221 回落完成,如下圖所示。
7.發(fā)起4G網(wǎng)絡(luò)下專載恢復(fù),并且完成,如下圖所示。
8.后續(xù)信令都無異常。9.20:17:32.751,發(fā)起更新以后,20:17:53.491用戶發(fā)起掛機(jī),中間20s沒有任何信令,如下圖所示。
10.查看該段時間對應(yīng)的數(shù)據(jù)跟蹤,主叫和SBC進(jìn)行IMS交互,即該段時間沒有發(fā)現(xiàn)用戶回落3G的情況,有200 OK響應(yīng)消息和Sender Report消息,如下圖所示。
11.在此期間核心網(wǎng)控制面和媒體面均正常。12.20:17:53,用戶先發(fā)起B(yǎng)YE請求消息??刂泼骈_始釋放流程,需要進(jìn)一步核查用戶發(fā)送BYE消息的原因。IMS側(cè)無法查看到此時間段內(nèi)的用戶信令。第二階段排查:異廠商H的MME區(qū)域?,F(xiàn)象:主叫撥出后自己掛斷,被叫還在振鈴。13.SBC不停的發(fā)送承載更新請求,多次更新后SMF釋放了承載,網(wǎng)絡(luò)側(cè)發(fā)起修改的時候,收到MME/SGW發(fā)起承載修改請求,如下圖所示。14.分析異常信令:網(wǎng)絡(luò)側(cè)發(fā)起epsbid7和8專載修改時,收到MME/SGW發(fā)起epsbid=6默載修改請求,如下圖所示。15.在測試過程中普遍反饋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.通過對比業(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上沒有MME GTP Modify Bearer Command。20.初步結(jié)論:UDM?5G和4G簽約模板速率單位不一致,導(dǎo)致流程沖突。4G的簽約為30000 Kbps,MME發(fā)出ULR請求,HSS返回ULA攜帶4G的簽約AMBR值,由30000 Kbps換算成了30720000 bps,和從5G側(cè)獲取的(30 mbps,轉(zhuǎn)換為300000 kbps)不一致。MME發(fā)起MBC修改,和SMF的UBR消息概率流程沖突,釋放承載。21.與客戶溝通后:將測試卡4G簽約30000000 bit/s,5G簽約30 Mpbs后繼續(xù)撥測。分析信令:SMF在特定流程中收到Modify bearer Command時通過N7接口上報 res_all_fail。調(diào)整統(tǒng)一UDM上4G、5G簽約后,信令觀察看已基本抑制了MME對IMS承載的MBC消息,業(yè)務(wù)正常。第三階段排查:異廠商N(yùn)的MME區(qū)域2,現(xiàn)象:主叫撥出后自己掛斷,被叫還在振鈴。22.異廠商N(yùn)的MME區(qū)域2簽約AMBR一致情況下,仍然觸發(fā)MBC消息,對比異廠商H的MBC,異廠商N(yùn)多攜帶FTEID信息,如下圖所示。23.異廠商N(yùn)的MME答復(fù)從N26接口處獲取的PL=1,和ULA取到的不一樣,ULA取到的ARP是6,所以會發(fā)送GTP Modify Bearer Command修改,如下圖所示。24.分析所有正常、異常信令:SMF在收到IMS 承載首次MBC消息后均未做UBReq交互處理(數(shù)據(jù)業(yè)務(wù)APN可以正常交互),后續(xù)MBC重發(fā)過程和其他業(yè)務(wù)流程概率碰撞后,導(dǎo)致N7上報res_all_fail,呼叫流程異常。25.與PCF側(cè)溝通得知:在EPSfallback流程中,當(dāng)PCF下發(fā)的IMS會話的ARP與UDM簽約的ARP不一致時,假設(shè)MME從AMF獲取的上下文中IMS會話的ARP是1,而從UDM簽約獲取的ARP是6,會導(dǎo)致MME會主動發(fā)起IMS會話的MBC消息進(jìn)行QoS修改。由于對于IMS APN,一般情況4G和5G簽約的速率一樣,所以正常EPSFB流程可以不進(jìn)行MBC流程。26.為了優(yōu)化流程,需要將PCF的IMS會話ARP配置修改為6,和UDM簽約保持一致。目前現(xiàn)網(wǎng)配置都為1,如圖18和圖19所示。
故障處理
修改ARP優(yōu)先級,將PCF的IMS會話ARP配置修改為6,和UDM簽約保持一致,后續(xù)測試業(yè)務(wù)正常。