杭州移动NB-IoT网络RRC接通率问题分析
问题现象：
杭州移动NB全网中存在着RRC连接成功率偏低的问题，出现很多相关的top小区，降低了NB全网无线接通率，需要及时处理解决。
统计NB全网关于RRC接通率的指标如下：
表一：关于RRC接通率的相关指标
从9月份统计的一周的数据可以看出：NB全网每天RRC连接请求次数大约9千余次左右，RRC连接建立失败次数为180左右，无线接通率为98.00%左右，从指标上看失败原因全为NB-IoT小区UE无应答而导致RRC连接建立失败，主要表现方式是等待RRC CONNECTION SETUP COMPLETE TIMEOUT。现处理方式分三步，一核查全网参数，并分析优化，二筛选top小区进行逐个分析，三选取典型站点进行现场拨测跟踪分析。
Step1：核查全网参数分析优化
参数分析：
1、通过指标分析，失败原因全为NB-IoT小区UE无应答而导致RRC连接建立失败，主要表现方式是等待
RRC CONNECTION SETUP COMPLETE TIMEOUT。导致等待建立完成定时器超时的原因很多，包括无线环境、上行低噪、告警、以及参数配置不合理等等，先从参数角度分析核查相关参数等待RRC CONNECTION SETUP COMPLETE定时器UUMESSAGEWAITINGTIMER现网存在2套，一套为35秒，
一套按覆盖等级划分最大为65秒分别如图一图二
图一
当参数取值为0时，表示无效值，eNodeB启动NB-IoT等待UE空口响应消息定时器采用MO ENodeBConnStateTimer中参数UuMessageWaitingTimer取值
图二
2、通过指标NB-IoT小区覆盖等级2下RRC连接建立最大时长(毫秒) 说明在一些情况下RRC建立时长是
超过35秒，由于NB网络对时延容忍较大且NB网络在覆盖条件恶劣的情况下需要重复发射技术来增强覆盖，所以对于60多秒的建立时长一般是可以接受的，也说明了将UUMESSAGEWAITINGTIMER配
表二：RRC建立时长超过35秒的事件
2、对比两套参数发现按覆盖等级划分UUMESSAGEWAITINGTIMER的（方案一）接通率的确比配置成
图三
解决措施：将现网方案二的参数改为方案一对应mml命令：MOD NBCELLDLSCHCEALGO: LocalCellId=X, CoverageLevel=COVERAGE_LEVEL_1，UuMessageWaitingTimer=45; MOD NBCELLDLSCHCEALGO:LocalCellId=X,CoverageLevel=COVERAGE_LEVEL_2,UuMessageWaitingTi mer=65;
补充：在处理top小区中发现部分站点一周内RRC连接请求全部失败，核查参数发现参数DCI子帧重复次数兼容开关:关，导致该站下小区无法建立成功，需及时修改，对应MML命令：MOD CELLALGOSWITCH: LocalCellId=1, NbCellAlgoSwitch=DCI_SF_REP_NUM_COMP_SWITCH-1；优先级高
第二步：筛选top小区进行逐个分析
由于NB网络尚未正式商用，用户很少大部分站点一周内只有一两次的建立尝试，无法确定用户行为，无
经分析这些失败的top小区主要发生在覆盖等级2和覆盖等级0
图四
图五
失败原因分析大部分存在上行干扰导致，由于现网用户较少基数过小不排除偶然性失败需要现场定位
由于NB网络有20db的增强覆盖在无线环境较差时上行低噪较高基站很难解析成功导致接通失败
Step3：优化总结
从网管数据采集、现场拨测以及拉网测试这三大块分析可以得出，影响现网NB接通率的主要可以从参数优化，干扰排查和下行质差处理。
参数优化：
选取一套较优参数全网统一
干扰排查：
现场摸排干扰定位
下行质差处理：
信号强度覆盖较好，但就目前信号质量而言主要是重叠覆盖导致的质差，解决措施可从下面几个方向优化：
1、考虑异频组网
2、覆盖收缩降低重叠覆盖度
3、pci优化