通过观察LTE的的忙时指标，发现某运营商LTE这几天寻呼拥塞率突然变高。寻呼拥塞率由0%上升到1.1%，如下图所示。

2.1 TOP小区分析

通过提取网管U31的寻呼拥塞率指标性能分析，发现寻呼拥塞率主要是由TOP小区引起的，BBU397591站点下挂的6个小区的寻呼拥塞率达到100%，导致整网寻呼拥塞率变高，如下图所示，其他5个小区的指标变化与图片一样。故问题定位为TOP小区问题，重点解决397591站点的寻呼拥塞率问题。

2.2 指标分析

按照每小时粒度提取指标发现，BBU397591站点下挂的6个小区从4月10号开始指标突然恶化，且无线连接成功率几乎为0，寻呼记录丢弃个数几乎为寻呼记录接收个数，RRC连接建立成功次数几乎为0，RRC连接失败次数也为0，如下图所示,其他5个小区的指标变化与图片一样。6个小区均恶化表明为共性问题，重点排查方向为：站点故障告警和这几天是否对这6个小区进行参数修改。

2.3 站点故障排查

排查该站点的当前告警，未发现任何告警，站点正常。查询小区状态，小区也均正常。查询该站点的历史告警，发现BPL板经常重新初始化，初步判断为硬件故障，通知督导安排施工队处理。

2.4 参数核查

为进一步排查是否因为参数问题导致单板经常重新初始化，根据电信参数对该站点进行参数核查，参数均配置正常，同时也将该站点作为源对象与同一机房的其他BBU进行参数对比，未发现参数异常。

2.5 操作记录查询
查询该站的最近几天的历史操作记录均未发现异常操作，而且在指标恶化的这几天没有执行过参数修改。

2.6 指标详细分析

对指标进一步做详细分析发现：

1:同一时间点该BBU下挂的两个物理站点的寻呼记录接收个数有时不一致，如下图所示。怀疑TAC配置成不一样，因为如果TAC相同，这两个物理站点的寻呼记录接收个数应该接近。现网核查6个小区的TAC,发现TAC是一致的。

2:怀疑是否因为寻呼次数激增导致寻呼拥塞，通过对比同一机房的寻呼次数，发现数量级基本一致，而且均未超过寻呼信道容量，如下图所示。

3:问题BBU397591的RRC连接次数几乎为零，寻呼记录丢弃个数接近寻呼记录接收个数，但寻呼拥塞个数均为零。

查阅指标计数器的定义，发现寻呼拥塞个数为0，即寻呼队列并不满，寻呼容量没问题；寻呼记录丢弃个数接近寻呼记录接收个数，即eNodeB每次都错过寻呼时机，并未发送出去。初步怀疑该问题BBU出现挂死，即6个小区为睡眠小区。睡眠小区不会对指标造成影响，平时很难发现，但接入数为0，用户数为0。

4：根据第3步分析，初步判断该问题BBU的6个小区可能为睡眠小区，为进一步确认，提取更详细的指标，包含RRC/寻呼/PRB/MSG3/preamble，发现在问题时段该BBU下挂的6个小区存在很多异常指标。

1：《可使用的Preamble个数》几乎为0。
2：《RRC连接建立成功次数》和《RRC连接失败次数》几乎为0。
3：《Msg3检测成功次数》和《Msg3丢弃次数》几乎为0。
4：《小区上行信道实际使用PRB个数》和《小区上行信道可用的PRB个数》均为0。
5：《小区下行信道实际使用PRB个数》和《小区下行信道可用的PRB个数》均为0。

据此可判定该BBU硬件故障，下挂的6个小区为睡眠小区，睡眠小区的解决办法就是复位RRU，复位单板（BPL板/CC板/FS板），复位整个网元，如果复位未解决问题的话，建议单板重新插拔下或更换单板。