通過觀察LTE的的忙時指標，發(fā)現(xiàn)某運營商LTE這幾天尋呼擁塞率突然變高。尋呼擁塞率由0%上升到1.1%，如下圖所示。

2.1 TOP小區(qū)分析

通過提取網(wǎng)管U31的尋呼擁塞率指標性能分析，發(fā)現(xiàn)尋呼擁塞率主要是由TOP小區(qū)引起的，BBU397591站點下掛的6個小區(qū)的尋呼擁塞率達到100%，導致整網(wǎng)尋呼擁塞率變高，如下圖所示，其他5個小區(qū)的指標變化與圖片一樣。故問題定位為TOP小區(qū)問題，重點解決397591站點的尋呼擁塞率問題。

2.2 指標分析

按照每小時粒度提取指標發(fā)現(xiàn)，BBU397591站點下掛的6個小區(qū)從4月10號開始指標突然惡化，且無線連接成功率幾乎為0，尋呼記錄丟棄個數(shù)幾乎為尋呼記錄接收個數(shù)，RRC連接建立成功次數(shù)幾乎為0，RRC連接失敗次數(shù)也為0，如下圖所示,其他5個小區(qū)的指標變化與圖片一樣。6個小區(qū)均惡化表明為共性問題，重點排查方向為：站點故障告警和這幾天是否對這6個小區(qū)進行參數(shù)修改。

2.3 站點故障排查

排查該站點的當前告警，未發(fā)現(xiàn)任何告警，站點正常。查詢小區(qū)狀態(tài)，小區(qū)也均正常。查詢該站點的歷史告警，發(fā)現(xiàn)BPL板經(jīng)常重新初始化，初步判斷為硬件故障，通知督導安排施工隊處理。

2.4 參數(shù)核查

為進一步排查是否因為參數(shù)問題導致單板經(jīng)常重新初始化，根據(jù)電信參數(shù)對該站點進行參數(shù)核查，參數(shù)均配置正常，同時也將該站點作為源對象與同一機房的其他BBU進行參數(shù)對比，未發(fā)現(xiàn)參數(shù)異常。

2.5 操作記錄查詢
查詢該站的最近幾天的歷史操作記錄均未發(fā)現(xiàn)異常操作，而且在指標惡化的這幾天沒有執(zhí)行過參數(shù)修改。

2.6 指標詳細分析

對指標進一步做詳細分析發(fā)現(xiàn)：

1:同一時間點該BBU下掛的兩個物理站點的尋呼記錄接收個數(shù)有時不一致，如下圖所示。懷疑TAC配置成不一樣，因為如果TAC相同，這兩個物理站點的尋呼記錄接收個數(shù)應該接近�，F(xiàn)網(wǎng)核查6個小區(qū)的TAC,發(fā)現(xiàn)TAC是一致的。

2:懷疑是否因為尋呼次數(shù)激增導致尋呼擁塞，通過對比同一機房的尋呼次數(shù)，發(fā)現(xiàn)數(shù)量級基本一致，而且均未超過尋呼信道容量，如下圖所示。

3:問題BBU397591的RRC連接次數(shù)幾乎為零，尋呼記錄丟棄個數(shù)接近尋呼記錄接收個數(shù)，但尋呼擁塞個數(shù)均為零。

查閱指標計數(shù)器的定義，發(fā)現(xiàn)尋呼擁塞個數(shù)為0，即尋呼隊列并不滿，尋呼容量沒問題；尋呼記錄丟棄個數(shù)接近尋呼記錄接收個數(shù)，即eNodeB每次都錯過尋呼時機，并未發(fā)送出去。初步懷疑該問題BBU出現(xiàn)掛死，即6個小區(qū)為睡眠小區(qū)。睡眠小區(qū)不會對指標造成影響，平時很難發(fā)現(xiàn)，但接入數(shù)為0，用戶數(shù)為0。

4：根據(jù)第3步分析，初步判斷該問題BBU的6個小區(qū)可能為睡眠小區(qū)，為進一步確認，提取更詳細的指標，包含RRC/尋呼/PRB/MSG3/preamble，發(fā)現(xiàn)在問題時段該BBU下掛的6個小區(qū)存在很多異常指標。

1：《可使用的Preamble個數(shù)》幾乎為0。
2：《RRC連接建立成功次數(shù)》和《RRC連接失敗次數(shù)》幾乎為0。
3：《Msg3檢測成功次數(shù)》和《Msg3丟棄次數(shù)》幾乎為0。
4：《小區(qū)上行信道實際使用PRB個數(shù)》和《小區(qū)上行信道可用的PRB個數(shù)》均為0。
5：《小區(qū)下行信道實際使用PRB個數(shù)》和《小區(qū)下行信道可用的PRB個數(shù)》均為0。

據(jù)此可判定該BBU硬件故障，下掛的6個小區(qū)為睡眠小區(qū)，睡眠小區(qū)的解決辦法就是復位RRU，復位單板（BPL板/CC板/FS板），復位整個網(wǎng)元，如果復位未解決問題的話，建議單板重新插拔下或更換單板。