共享站點(diǎn)S1用戶面路徑不可用告警排查處理

某區(qū)域在12月14-15日開通共建共享后，運(yùn)營(yíng)商A部分4G基站上出現(xiàn)S1用戶面路徑不可用告警告警，同時(shí)E-RAB釋放次數(shù)（S1鏈路故障原因）次數(shù)增多明顯增多，如圖1所示。

圖 1 電信4G基站告警

1. 通過(guò)對(duì)基站告警進(jìn)行分析后發(fā)現(xiàn)，出現(xiàn)告警的S1用戶面路徑不可用告警，對(duì)端IP地址為10.100.33.X，如圖2所示。

圖2 對(duì)端IP地址

2.10.100.33.X均為運(yùn)營(yíng)商B核心網(wǎng)配置地址段，初步判斷為運(yùn)營(yíng)商B業(yè)務(wù)異常導(dǎo)致在運(yùn)營(yíng)商A共享站點(diǎn)上上報(bào)的告警。現(xiàn)場(chǎng)分PLMN統(tǒng)計(jì)S1鏈路故障發(fā)起的釋放次數(shù)，其中新增原因均為運(yùn)營(yíng)商B用戶引起，如圖3所示。

圖3 運(yùn)營(yíng)商B用戶業(yè)務(wù)異常

3.核查運(yùn)營(yíng)商A站點(diǎn)配置的共享運(yùn)營(yíng)商B參數(shù)，無(wú)異常。由于故障為運(yùn)營(yíng)商B用戶和運(yùn)營(yíng)商B用戶面鏈路故障引起，需要運(yùn)營(yíng)商B核心網(wǎng)信令跟蹤判斷。

4.在運(yùn)營(yíng)商B的MME上對(duì)一個(gè)有S1用戶面路徑不可用告警的運(yùn)營(yíng)商A共享站監(jiān)雙五（7.65.227.114）抓包，發(fā)現(xiàn)在handoverrequest消息中攜帶的IP為10.100.33.X，如圖4所示。

圖4 Handoverrequest消息中攜帶的IP為10.100.33.X

5.根據(jù)抓包獲取的時(shí)間，在SEQ中回溯找到了MME在servicerequest過(guò)程中給運(yùn)營(yíng)商A共享站發(fā)出的SGWS1-U地址是10.100.33.X的場(chǎng)景，如圖5所示。

圖5 SGWS1-U地址是10.100.33.X的場(chǎng)景

6.查看這個(gè)用戶的相關(guān)流程，發(fā)現(xiàn)當(dāng)其在運(yùn)營(yíng)商B站點(diǎn)森蘭名軒東區(qū)下時(shí)，S1-U地址是正確的10.100.32.X。而當(dāng)用戶切往換到運(yùn)營(yíng)商A共享站監(jiān)雙五時(shí)，MME下發(fā)的SGWS1-U地址發(fā)生了改變，是錯(cuò)誤的10.100.33.X，如圖6所示。

圖6 SGWS1-U地址變化

7.從SEQ中，回溯發(fā)現(xiàn)S1-U地址發(fā)生改變前，終端從運(yùn)營(yíng)商B站點(diǎn)森蘭名軒東區(qū)切往運(yùn)營(yíng)商A共享站監(jiān)雙五，從森蘭名軒東區(qū)發(fā)出的S1HO請(qǐng)求中，攜帶了錯(cuò)誤的目標(biāo)TAC5B0D(23309)。而這個(gè)切換目標(biāo)監(jiān)雙五配置的TAC應(yīng)該是5D97(23959)。

MME是根據(jù)TAC來(lái)選擇SGW的，根據(jù)切換目標(biāo)TAC=5BXX，MME會(huì)從DNS解析中獲得外省市運(yùn)營(yíng)商B的SGW地址，并從外地SGW中獲得10.100.33.X的S1-U地址，下發(fā)給運(yùn)營(yíng)商A共享站，而導(dǎo)致運(yùn)營(yíng)商A共享站出現(xiàn)S1-U地址面不通的告警，如圖7所示。

圖7 錯(cuò)誤的目標(biāo)TAC5B0D(23309)

8.核查運(yùn)營(yíng)商B站點(diǎn)森蘭名軒東區(qū)配置，發(fā)現(xiàn)其鄰區(qū)中確實(shí)有TAC5B0D(23309)的鄰區(qū)，如圖8所示。

圖8 TAC5B0D(23309)鄰區(qū)

9.運(yùn)營(yíng)商A側(cè)12月15號(hào)凌晨1點(diǎn)38已經(jīng)完成TAC修改，如圖9所示。

圖9 完成TAC修改

核查運(yùn)營(yíng)商B側(cè)鄰區(qū)TAC信息與運(yùn)營(yíng)商A側(cè)實(shí)際配置不一致，應(yīng)當(dāng)是ANR在錨點(diǎn)共享時(shí)已經(jīng)添加此鄰區(qū)，讀取到的TAC即為5B0D(23309)。而后當(dāng)運(yùn)營(yíng)商A側(cè)共享出的TAC更改為5D97(23959)后，因終端上報(bào)的PCI在鄰區(qū)列表中已存在，無(wú)法再次觸發(fā)ANR后續(xù)流程，運(yùn)營(yíng)商B側(cè)TAC未更新且未及時(shí)手動(dòng)更新導(dǎo)致故障。

運(yùn)營(yíng)商B側(cè)刪除5BXX的鄰區(qū)關(guān)系及外部鄰區(qū)定義后，通過(guò)讓ANR重新自動(dòng)添加鄰區(qū)。觀察運(yùn)營(yíng)商A側(cè)S1告警消失，E-RAB指標(biāo)恢復(fù)正常，如圖10所示。

圖10 告警消失

集團(tuán)要求4G共享基站的TAC統(tǒng)一為5DXX號(hào)段，對(duì)于承建方由于之前5G錨點(diǎn)共享已經(jīng)添加共享方鄰區(qū)（非5DXX段）場(chǎng)景下，在共享方開啟4G共享后需要承建方及時(shí)更新對(duì)應(yīng)TAC。

建議共享站開通時(shí)即按集團(tuán)標(biāo)準(zhǔn)TAC進(jìn)行配置開站。

涉及共享站操作需通知對(duì)方，同步修改相關(guān)鄰區(qū)等操作。