欧美特殊大毛茸茸bbw,亚洲国产精品国自产拍AV在线

故障現(xiàn)象

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

圖 1? 運(yùn)營商A?4G基站告警

故障分析

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

圖2 對端IP地址

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

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

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

4.在運(yùn)營商B的MME上對一個(gè)有S1用戶面路徑不可用告警的運(yùn)營商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過程中給運(yùn)營商A共享站發(fā)出的SGWS1-U地址是10.100.33.X的場景，如圖5所示。

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

6.?查看這個(gè)用戶的相關(guān)流程，發(fā)現(xiàn)當(dāng)其在運(yùn)營商B站點(diǎn)森蘭名軒東區(qū)下時(shí)，S1-U地址是正確的10.100.32.X。而當(dāng)用戶切往換到運(yùn)營商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)營商B站點(diǎn)森蘭名軒東區(qū)切往運(yùn)營商A共享站監(jiān)雙五，從森蘭名軒東區(qū)發(fā)出的S1HO請求中，攜帶了錯(cuò)誤的目標(biāo)TAC5B0D(23309)。而這個(gè)切換目標(biāo)監(jiān)雙五配置的TAC應(yīng)該是5D97(23959)。

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

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

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

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

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

圖9 完成TAC修改

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