LTE基站寻呼拥塞率问题分析处理

LTE基站寻呼拥塞率问题分析处理

【摘要】实际现网由于用户量不多，基站负荷较小，4G网络在当前的业务需求以及寻呼策略下，一般的不太容易出现拥塞。本例中描述的是一起单站信道板（BPL）故障

导致寻呼拥塞，由面到点，再通过后台打印进程内容定位出故障位置。给处理寻

呼拥塞积累了一些分析思路。

【关键字】寻呼拥塞寻呼消息堆积

【故障现象】

在滁州日常KPI指标统计中，发现4月22日的网络的寻呼拥塞率从平时的0.00%突变到0.01%。

图1 滁州整网寻呼拥塞率

【告警信息】

检查告警信息，发现并没有大规模基站故障告警，只有部分零散的新开基站存在告警，但不会导致整网的寻呼拥塞率高。

【原因分析】

寻呼拥塞率KPI分析：

寻呼拥塞率=寻呼记录发送不成功次数/混户籍路应发送次数*100%

主要是指eNB由于资源限制原因导致寻呼消息发送失败的情况。

由于目前现网是网络容量大于需求，正常情况下不会出现寻呼拥塞。从核心网的同事了解到当前的寻呼策略是按照最近一次活动的TA寻呼和TA LIST寻呼相结合的。第一次在最近一次活动的TA下寻呼一次，如果寻呼不到，则在相应的TA LIST 范围内进行寻呼。

表1 LTE网络寻呼的参数设置

导致寻呼拥塞的原因可能有：

无线测配置的寻呼参数配置失当或者网络的TA划分不合理：

检查寻呼参数设置如下：

表2 现网寻呼参数的设置

其中nB和T属于协议参数，别的属于算法参数；

广播的基站所用的寻呼周期（T），在UE使用时还有一个参数，叫做UE的专用寻呼周期，两者取小作为UE的实际使用的寻呼周期。该UE的专用寻呼周期（取值范围与小区寻呼周期的相同）来自于UE 自己上报的NAS消息，在寻呼UE时，由核心网在寻呼消息中通知基站。

2、硬件配置问题：

由面到点，查询全网的寻呼拥塞率指标，发现全部集中在滁州学院宿舍楼室分的8槽位BPL板的4/5/6三个小区，如下图：

图2 滁州学院宿舍楼室分寻呼拥塞率

综上，检查滁州学院宿舍楼的参数配置，可以排除寻呼信道不够用的情况；检查滁州学院宿舍楼室分的TAC规划，网管配置跟规划的一致，同个TAC下只有28个站点，排除TAC规划问题。而且检查滁州学院宿舍楼室分无告警。

进一步在BPL1的产品进程（Product），输入g_pdwRnluFrm 然后再读地址的值，发现系统时间没有变化。系统帧号和子帧号不变，

导致广播、寻呼不报BSR，大量寻呼消息堆积把内存占完。

正常的进程应该是变化的：

图3 检查BPL板件参数设置

因此可以定位BPL板问题是造成本站寻呼拥塞的原因，系统帧号和子帧号不变可以判断是BPL的产品进程锁死，属于软件问题，需要进行复位或者更换板件。

【解决方法】

复位BPL板，滁州学院宿舍楼室分寻呼拥塞问题解决：

图4 滁州学院宿舍楼寻呼拥塞率（处理后）

经过检查，全网的寻呼拥塞率也恢复正常：

图5 滁州整网寻呼拥塞率（处理后）

【结论与推广】

本例中是通过BPL板进程，查看状态是否正常，进行BPL板复位或者更换处理。对寻呼拥塞率异常问题，先通过查看寻呼策略和寻呼参数设置是否合理，寻呼信道是否够用，然后再排查TAC规划是否合理。寻呼策略、全网的寻呼参数核查和TAC规划影响面都很大，至少是TAC级别的。由面到点，迅速定位问题的网元，然后通过进一步细节的分析，找出问题原因和解决方案。