徐水長城傳輸IPRAN過載誘發基站頻閃

一、問題現象

通過日常監控發現，徐水長城區域內近期每日特定時間出現3G基站閃斷，並伴隨出現時鐘不同步告警，通過提取歷史告警發現以下規律：

圖：3G基站閃斷次數

閃斷基站涉及到徐水大王店支局、徐水長城二食堂機房、徐水曼德線束、徐水三期生活間機房，且為同一傳輸環路。在業務量高的情況下就開始出現閃斷，無業務或非高峰期的時候不會出現閃斷。閃斷時間固定為每日10：00-10:20,15:00-15:20,且春節假期期間徐水長城公司放假12天均未發生閃斷。

圖：傳輸拓撲

圖：3G基站告警

相關時間內4G網路無告警、LTE可用率100%。現場測試也印證了4G網路正常而語音回落的3G網路異常問題，第一次測試回落占室分3G,第二、三次產生閃斷回落測試均為室外宏站。

圖：現場實測圖

二、問題分析

1、無線側分析

（1）基站告警分析

loss of supervision（基站脫管）該告警是基站中比較常見的告警，頻繁出現的原因主要有三個：控制板卡CCM故障，頻繁重啟;電源不穩定或欠壓;傳輸鏈路不穩定。

通過統計告警的持續時間，我們發現10個問題站點在過去一個月的時間中一共發生過252次loss of supervision告警，脫管時間持續時長小於3分鐘的情況有217次，佔總次數的86.11%。其中脫管持續時間僅有幾秒鐘的情況有119次，佔總數的47.22%。基站CCM板卡每次重啟大概需要3-5分鐘，因此基本可以排除CCM板卡重啟導致loss of supervision告警頻繁出現的情況。

此外，在基站頻閃的時間點，沒有發現任何基站硬體的告警，而且10個站點在相同的時間段都發生CCM板卡故障的可能性也是微乎其微的，因此建議將故障原因的調查方向放在電源及傳輸兩個方向，由於基站閃斷伴隨時鐘問題，我們也同時排查了1588時鐘伺服器故障可能性。

（2）1588伺服器時鐘相關的告警

BTS SYNCHRONISATION/0 SYN NOT LOCKED TO THE NETWORK

BTS SYNCHRONISATION/0 LOST HIGHER PRIORITY SYN SOURCE

BTS/0 NO GRANT MESSAGE FROM PTP SERVER 1

問題基站的時鐘源是由TP5000(1588時鐘伺服器)提供的，整個時鐘鏈路的簡單拓撲結構為：TP5000→傳輸網路→基站。由此我們也能看出，告警產生的原因也就在這3個節點上。

目前這10個站分布在不同的1588時鐘伺服器上，每個TP5000 Ethernet埠下都帶有其他基站，並且每個TP5000 Ethernet埠容量為500個站，目前下掛數最多的埠也就300多個站，排除容量受限。如果兩台伺服器均有故障，那麼它下掛的站點應該都會出現問題，而受影響的站點就10台，別的站沒有問題，並且也並未發現伺服器有告警，基本可以排除時鐘伺服器的問題。

基站上的配置和時鐘相關的為CCM板卡、乙太網線，結合第一類告警的分析，基站硬體故障的可能性是極小的。

（3）電源問題

涉及到的4個機房中均未發生停電告警，傳輸設備、4G設備均正常運行，故排除市電在頻閃時段停電；因4個機房內均配備基站電池，當設備負載過大，交流電壓變低，電池會及時補償負載這樣就不會有頻閃問題發生，排除電源問題。

2、傳輸側分析

通過傳輸網管查詢頻閃時段傳輸設備的鏈路、埠，發現無明顯告警，但查詢指標有帶寬利用率過高問題。通過提取平均帶寬利用率分析發現，每天10:00-10:15、15:00-15:15帶寬平均利用率突增一倍以上，超過75%。傳輸網管測觀察實時帶寬峰值利用率甚至超過90%，1GE帶寬佔用980M現象，最終確定因傳輸帶寬利用率超限引發基站頻閃。

圖：平均帶寬利用率

3、用戶行為分析

通過多次實地與長城公司員工溝通，發現頻閃的兩個時段（10：00-10：15和15：00-15：15）為廠區全員休息時段，而中午時段11:00-13:00為各車間輪流吃飯、休息時間，該時段內用戶數少於上下午集中休息時段，長城公司管理較為嚴格，工作時段電話、上網行為較少，休息時段業務需求集中爆發，造成帶寬利用率峰值超限，IPRAN選擇性丟棄一部分業務，造成閃斷。

三、問題處理方案

1、臨時方案

針對該問題，傳輸測進行傳輸隧道鏈路均衡,通過修改二食堂機房、徐水長城回遷樓機房、徐水長城公寓綜合樓三個傳輸網元到匯聚的路徑，把流量分攤在GE環的兩個主方向上，在一定程度上環節帶寬壓力，原來被丟棄的流量得到了解決。處理完成後，連續三天均未出現基站閃斷問題，業務保持穩定，問題得以解決。

圖：傳輸拓撲

隧道均衡後，雖然閃斷問題得以解決，但無論是帶寬平均利用率還是峰值利用率未發現明顯變化，原因為修改前平均帶寬利用率和峰值利用率均對於設備來說基本已經飽和，開始丟棄一部分流量。當傳輸埠流量飽和時，基站流量被丟棄了一部分，實際流量應該是傳輸當前流量+丟棄流量，此時網管還是只統計傳輸當前流量，丟棄流量未被統計。路徑優化後，丟棄的流量得到解決，但埠的利用率不一定就會下降。

帶寬超限時實際流量=設備支持最大流量+丟棄流量

未超限實際流量=實際發生流量（小於設備支持最大流量）

2、後續方案

由於傳輸平均帶寬利用率70%以上已達到擴容門限，且目前隧道均衡只能臨時解決閃斷問題，不能有效改善速率、卡頓等用戶感知，同時考慮到業務提升和突發流量，計劃將徐水長城傳輸鏈路由GE環擴容成10GE環，同時針對此次發現的問題需全網核查此類高負荷情況，及時擴容。

四、問題的反思

目前，3G/4G設備大都運行在全IP的數據通信網當中，涉及到的網元、介面、鏈路非常多，每個環節的負荷及隱性問題都會影響到端到端的客戶應用感知。需要傳輸網、數據網、無線網的技術人員協同聯動，共同分析解決，同時也對技術人員跨專業分析能力提出更高要求，同時隨著業務不斷發展，特別是2I2C用戶激增，對無線網、傳輸網承載能力提出了更高要求，應建立起常態化核查、擴容預案。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！