共享站點S1用戶面路徑不可用告警排查處理

故障現(xiàn)象

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

圖 1? 運營商A?4G基站告警

故障分析

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

圖2 對端IP地址

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

圖3 運營商B用戶業(yè)務異常

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

4.在運營商B的MME上對一個有S1用戶面路徑不可用告警的運營商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ù)抓包獲取的時間，在SEQ中回溯找到了MME在servicerequest過程中給運營商A共享站發(fā)出的SGWS1-U地址是10.100.33.X的場景，如圖5所示。

圖5 SGWS1-U地址是10.100.33.X的場景

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

圖6 SGWS1-U地址變化

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

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

圖7 錯誤的目標TAC5B0D(23309)

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

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

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

圖9 完成TAC修改

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

故障處理

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

圖10 告警消失

故障總結(jié)

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

建議共享站開通時即按集團標準TAC進相關(guān)鄰區(qū)等操作。