小区高负荷造成无线接通率低处理案例
故障案例小区高负荷造成无线接通率低处理案例
省公司江苏省专业无线设备类型
设备厂家中兴设备型号B8300 软件版本
关键字无线接通率低小区高负荷
故障描述
在LTE小区日常监控中发现LTE市区城坤钢材市场东_1的RRC建立成功率突然降低，从下图可以看出，该小区RRC建立成功率从11：00开始恶化由原来的99.72%下降至94.17%，每小时RRC建立失败800多次，指标恶化严重影响用户感知。截图如下：
时间
无线接通
率_集团
_zte
RRC连接成
功率_集团
_zte
ERAB建立
成功率_集
团_zte
切换成功
率_集团
_zte
ZJ平均底
噪
2015/6/7 10:00 99.68% 99.72% 99.97% 99.17% -116
2015/6/7 11:00 95.00% 95.09% 99.91% 99.40% -116
2015/6/7 12:00 94.06% 94.17% 99.88% 98.77% -116
2015/6/7 13:00 94.89% 94.93% 99.97% 99.39% -116
告警信息
无
原因分析
1、RRC 失败原因分析：
影响RRC 接入成功率的主要因素如下：小区故障、参数设置不合理，如PRACH 参数配置，最小接入电平、小区存在干扰，上行干扰（杂散干扰、谐波干扰、宽频干扰、大气波导）、下行MOD3干扰、弱场接入RRC 无法完成、用户数多SR 容量不足、CPU 负荷高等。 RRC 建立失败分析流程：
NO
NO
NO
NO
NO
NO
YES
结束
RRC建立成功率低
1、高负荷小区定义：RRC最大用户数≥200；
2、RRC平均用户数≥30且上行PRB利用率大于50%且上行流量大于1G；
3、RRC平均用户数≥30且下行PRB 利用率大于50%且下行流量大于5G；
4、主控板CPU最大利用率>80%
是否存在资源不足
1、参数调整，流量均衡；
2、天馈调整，分担流量；
3、热点区域，增补基站；
是否终端、用户行为异常
1.结合用户投诉情况，安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；
指标是否正常保存跟踪信令及测试数据，提交问题排查交付件至华为研发定位问题。
检查操作，是否存在告
警，传输问题，是否存在网络变动和升级行为等；2.查询单板运行情况；3.传输及EPC侧有网络变动（升级，割接，参数修改等）。
1、通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；
2、检查小区时隙配比是否设置准确
（DE:SA2\SSP7;F:SA2\SSP5）3、如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型；最后干扰处理。
是否存在干扰 1.通过统计TA与RSRP接入确认用户的接入环境，是否为弱场发起RRC请求；3、邻区告警、故障等导致TOP小区存在弱覆盖；4、天馈问题；5、无线环境差；6、基站规划、建设、施工问题；7，天线权值配置与现场天线参数不一致。8.核查参考信号功率是否偏低（常规设置92,122，需结合现场设置）；
是否存在覆盖问题是否存在高质差
1.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差；2、通过后台误码率跟踪，如BLER>10%，确定小区存在高误码；
1、 通过排查，该小区不存在告警、参数、干扰等问题，如下图所示通过提取TA 分布发现该小区TA 分布
主要集中在0-9范围内，覆盖集中在大约0-700米内，不存在远距离接入的情况：
1TA=16Ts=16*32.55ns*300000000/2=78m
基站地理分布:
2、通过查询发现RRC建立失败原因主要为“mo-Data类型RRC连接失败次数，定时器超时”平均
1小时600多次，如图所示：
日期
RRC连接
建立成
功率
mt-Access
类型RRC
连接失败
次数，定时
器超时
mo-Signalling
类型RRC连接
失败次数，定时
器超时
mo-Data
类型RRC
连接失败
次数，定
时器超时
RRC连接
释放次
数，空口
定时器
超时
RRC连接
释放次
数，重建
立失败
引发的
释放2015/6/7 10:00 95.09% 79 132 459 27 93 2015/6/7 11:00 94.17% 80 247 601 54 105
2015/6/7 12:00 94.93% 114 95 594 24 44
4、如下图所示“mo-Data类型RRC连接失败次数，定时器超时”造成的RRC连接建立失败主要是因：CPU负荷是否偏高，用户数多、参数、NI是否偏高、RRU输出功率异常、是否MR任务和其他实时跟踪任务导致接入定时器超时、是否弱场导致接入定时器超时等。
RRC处理手段计数器编号计数器名称/描述信息建议措施
C37320
01 mt-Access类型RRC连接失败次
数，定时器超时(次)
1.检查CPU负荷是否偏高，用户数
是都很多，如是调整SR容量进行
优化2.检查上\下行功控类参数3.
检查NI是否偏高4.检查RRU输出
功率5.检查是否MR任务和其他实
时跟踪任务导致接入定时器超时
6.检查是否弱场导致接入定时器
超时。
C373200002 mt-Access类型RRC连接失败次
数，eNB接纳失败(次)
1.检查接纳控制类参数设置
C373200003 mt-Access类型RRC连接失败次
数，其他原因(次
1.检查是否CPU冲高导致
2.提交
故障单交研发处理
C373200005 mo-Signalling类型RRC连接失败
次数，定时器超时(次)
1.检查CPU负荷是否偏高，用户数
是都很多，如是调整SR容量进行
优化2.检查上\下行功控类参数3.
检查NI是否偏高4.检查RRU输出
功率5.检查是否MR任务和其他实
时跟踪任务导致接入定时器超时
6.检查是否弱场导致接入定时器
超时。
C373200006 mo-Signalling类型RRC连接失败 1.检查接纳控制类参数设置
次数，eNB接纳失败(次)
C373 00007 mo-Signalling类型RRC连接失败
次数，其他原因(次)
1.检查是否CPU冲高导致
2.提交
故障单交研发处理
C373200009 mo-Data类型RRC连接失败次数，
定时器超时(次)
1.检查CPU负荷是否偏高，用户数
是都很多，如是调整SR容量进行
优化2.检查上\下行功控类参数3.
检查NI是否偏高4.检查RRU输出
功率5.检查是否MR任务和其他实
时跟踪任务导致接入定时器超时
6.检查是否弱场导致接入定时器
超时。
C373200010 mo-Data类型RRC连接失败次数，
eNB接纳失败(次)
1.检查接
控
类参数设置
C373200011 mo-Data类型RRC连接失败次数，
其他原因(次)
1.检查是否CPU冲高导致
2.提交
故障单交研发处理
C373200013 highPriorityAccess类型RRC连接
失败次数，定时器超时(次)
1.检查CPU负荷是否偏高，用户数
是都很多，如是调整SR容量进行
优化2.检查上\下行功控类参数3.
检查NI是否偏高4.检查RRU输出
功率5.检查是否MR任务和其他实
时跟踪任务导致接入定时器超时
6.检查是否弱场导致接入定时器
超时。
C373200014 highPriorityAccess类型RRC连接
失败次数，eNB接纳失败(次)
1.检查接纳控制类参数设置
C373200015 highPriorityAccess类型RRC连接
失败次数，其他原因(次)
1.检查是否CPU冲高导致
2.提交
故障单交研发处理
C373200017 emergency类型RRC连接失败次
数，定时器超时(次)
1.检查CPU负荷是否偏高，用户数
是都很多，如是调整SR容量进行
优化2.检查上\下行功控类参数3.
检查NI是否偏高4.检查RRU输出
功率5.检查是否MR任务和其他实
时跟踪任务导致接入定时器超时
6.检查是否弱场导致接入定时器
超时。
C373200018 emergency类型RRC连接失败次
数，eNB接纳失败(次)
1.检查接纳控制类参数设置
C373200019 emergency类型RRC连接失败次
数，其他原因(次)
1.检查是否CPU冲高导致
2.提交
故障单交研发处理
5、通过分析发现该小区每小时空口流量在7GB左右，PRB利用率最高在49%左右，RRC最大用户数250人左右，为严重高负荷小区。通过以上分析最终确认RRC建小区高负荷导致RRC建立成功率低。
时间空口总业
务字节数
(GB)
空口上行
业务字节
数GB
空口下行
业务字节
数GB
[TDD]上
行信道
PRB资源
利用率
[TDD]下
行信道
PRB资源
利用率
RRC连接
建立最大
用户数
RRC连接
建立平均
用户数
2015/6/7 10:00 7.33 0.48 6.85 38.54% 49.02% 187 152.24 2015/6/7 11:00 7.11 0.51 6.6 42.59% 48.49% 254 193.12 2015/6/7 12:00 6.49 0.37 6.12 37.05% 45.12% 236 166.23 2015/6/7 13:00 5.27 0.32 4.95 37.65% 35.75% 268 213.25
处理步骤:
未避免指标继续恶化造成用户投诉临时对以下参数进行了调整:
1、CRS参考信号功率由18->12：
2、A1、A2门限由-92、-95改为-79、-82
3、进行负荷分担
3、如下图所示，随后提取指标发现RRC用户由250下降至170左右，无线接通率指标也恢复正常：
4、该小区因用户较多，造成高负荷，临时调整并不能彻底解决问题，还需扩容吸收话务量。但该站
位于空军后勤学院内，工程队到现场后经过协调整仍无法进入，不能扩容。因在原站上不能进行扩容所以计划调整附近的站点方位角吸收话务，该站最近的两个点为LTE市区后勤学院和LTE市区空后院搬迁，但因LTE市区后勤学院1、3覆盖区域为网格和空军后勤学院比较敏感不符合条件，而LTE市区空后院搬迁为D频段小区覆盖范围较小，综合以上因因素，最终确定在LTE市区空后院搬迁上扩容F频段小区增强覆盖吸收话务。如下图所示：
物理视图，在BBU10槽位新增一了块BPN2板，下挂了3台(M1920A)RRU
拓图视图：
5、扩容前后LTE市区城坤钢材市场东_1小区指标与用户数对比：
6、LTE市区空后院搬迁F_2扩容后用户数