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

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

圖 1 電信4G基站告警

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

圖2 對端IP地址

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

圖3 運營商B用戶業務異常

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

4.在運營商B的MME上對一個有S1用戶面路徑不可用告警的運營商A共享站監雙五（7.65.227.114）抓包，發現在handoverrequest消息中攜帶的IP為10.100.33.X，如圖4所示。

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

5.根據抓包獲取的時間，在SEQ中回溯找到了MME在servicerequest過程中給運營商A共享站發出的SGWS1-U地址是10.100.33.X的場景，如圖5所示。

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

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

圖6 SGWS1-U地址變化

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

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

圖7 錯誤的目標TAC5B0D(23309)

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

圖8 TAC5B0D(23309)鄰區

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

圖9 完成TAC修改

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

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

圖10 告警消失

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

建議共享站開通時即按集團標準TAC進行配置開站。

涉及共享站操作需通知對方，同步修改相關鄰區等操作。