130广东佛山电信NBIoT用户行为分析与容量优化案例.docx
《130广东佛山电信NBIoT用户行为分析与容量优化案例.docx》由会员分享，可在线阅读，更多相关《130广东佛山电信NBIoT用户行为分析与容量优化案例.docx（22页珍藏版）》请在冰点文库上搜索。
130广东佛山电信NBIoT用户行为分析与容量优化案例
广东-佛山电信NB-IoT用户行为分析与容量优化案例
2019年9月
【摘要】NB-IoT物联网作为中国电信集约运营的战略性基础业务，具有空口环境要求高、网络接入需求多样、终端种类繁杂、覆盖行业范围广等特点，这对其服务保障提出了更高要求。
NB-IoT无线网络系统优化工作是通过全面、系统的网络评估，发现网络存在的主要问题，针对这些问题应用综合优化方法，完成网络覆盖优化、干扰优化、异常事件优化。
在短时间内快速、全面提升网络质量和用户感知，本文结合参考《中国电信NB-IoT无线网络系统优化指导书》简述对NB-IoT现网因用户行为导致RRC连接建立成功率低问题进行分析以及优化的过程。
【关键字】NB-IoT、系统优化、RRC连接、license
【业务类别】NB-IoT
一、推广背景
《中国电信NB-IoT无线网络系统优化指导书》用于支撑NB-IoT无线网络优化工作，目的在于全面提升网络质量和用户感知，为市场业务发展提供必要保证。
该指导书详述了NB-IoT网络性能指标评估、路测指标评估、N800&L800协同覆盖评估方法，详细介绍了网络覆盖优化、干扰优化、异常事件优化、功耗优化以及关键参数的配置。
对弱覆盖、越区覆盖、重叠覆盖、上下行覆盖不平衡、上行干扰、下行干扰等具体问题现象进行了分析，给出优化方案；针对接入性能范畴的RRC连接建立失败、Attach附着失败，移动性能范畴的重选失败，保持性能范畴的空口掉线，共计四种典型的异常事件，分别介绍了其信令流程、异常问题点的定位、分析和优化方案；列举了PSM、eDRX等功耗相关的参数以及NB-IoT的关键参数，对参数的功能进行了描述，对调优的手段和效果进行了详细说明，并给出了配置建议；为提升NB-IoT网络质量和用户感知提供了指引，参照此指导书，对佛山NB-IoT网络问题进行优化及推广验证。
二、推广实施
2.1网管指标评估
网管指标评估是针对呼叫接入类、呼叫保持类、业务流量类、业务完整类、资源负荷类、噪声干扰类、设备可用性等指标进行变化曲线分析、最差小区分析，以界定性能异常的小区或区域，并结合地理化的投诉信息、现场测试信息，以达到判断性能异常原因的目的。
性能变化曲线分析：
以TAC或区域为单位提取系统忙时指标，建立各指标的日变化曲线，对各指标进行横向和纵向的对比，确定性能变化趋势和分析重点。
最差小区分析：
通过统计小区忙时数据，根据设定的门限筛选出最差小区，并进行地理化呈现。
其中NB-IoT小区呼叫接入类指标包括：
RRC连接建立请求次数、NB-IoT小区RRC连接建立成功次数、NB-IoT小区RRC连接建立成功率、RRC连接建立平均时长RRC连接建立最大时长S1信令连接建立尝试次数、S1信令连接建立成功次数、S1信令连接建立成功率、接收的寻呼消息次数、PCH拥塞丢弃的寻呼消息次数、寻呼拥塞率。
2.2NB-IOTUE的小区接入过程
2.2.1MIB-NB传输
在sharetechnote中有详细的描述，如下：
MIB-NB分成8个等长的可以独立编码的子块sub-block，每个子块200bit.（一个MIB-NB经过编码和码率匹配后需要传输1600个bits,如果不考虑重传的话，需要8个子帧来传输一个MIB-NB。
这点与LTE不同，LTE的PBCH在频域上占用6个PRB（NPBCH为一个PRB），只需一个下行子帧就可以搞定一个MIB）。
MIB-NB的发送周期为640ms（64个SFN）,每个子块重复发送8次，SFN%64=0时发送第一个MIB-NB,SFN%8=0新发送一个sub-block。
2.2.2SIB1-NB的传输
1.SIB1-NB的发送周期为2560ms（256SFN）,以160ms（16个连续的SFN）为一个单位，将这个周期分为16份；
2.开始发送SIB1-NB的起始SFNindex由在这个周期内重复次数（repetition）和NNcell_ID指定。
3.这个周期内重复次数（repetition）由MIB-NB中的schedulingINfoSIB1指示。
4.在每一个repetition的16个SFN中，SIB1-NB在间隔一个SFN中的子帧4上发送。
5.SIB1-NB的调度信息在MIB-NB中指示，如下：
MIB-NB调度信息表:
2.3RRC连接建立失败
2.3.1RRC连接建立流程
从UE发起随机接入前导开始到完成RRC连接，整个接入信令流程如下图所示，RRC连接涉及MSG3、MSG4、MSG5。
MSG1：
UE选择确定NPRACH时频资源、发射功率，在MSG1向eNB发送preamble码字。
在NB-IoT系统的MSG1过程中，终端需要选择Preamble码字、NPRACH物理信道的时频资源，来发送Preamble码。
与LTE相比，NB-IoT系统中，NPRACH仅通过时频资源进行区分，不再支持码分。
NB-IoT的NPRACH采用3.75K的子载波间隔，为single-tone模式，并默认跳频。
在NB-IoT中，NPRACH配置相应的repetitions（重复次数）。
NPRACH的repetitions支持{1,2,4,8,16,32,64,128}。
eNB可以为不同的CELs（覆盖等级，CEL0/CEL1/CEL2）配置独立的repetitions。
即NPRACH的时频资源配置是与CEL相关的。
不同CEL的RSRP门限通过广播下发，终端根据RSRP门限来确定自己的CEL，从而选择相应的NPRACH资源发起随机接入。
MSG2：
eNB在收到MSG1后，在特定的时间窗内发送RAR（MSG2）。
发送窗大小由SIB指示，大小为{2,3,4,5,6,7,8,10}*NPDCCH搜索空间周期的倍数，但最大不能超过10.24s。
发送窗的起始位置定义如下：
（a）NPRACH结束后不需要插入ULGAP时，NPRACH结束子帧与发送窗起始子帧之间应间隔3ms；
（b）如果NPRACH传输完成后正好需要插入一个UPGAP，那么应该在ULGAP结束之后开始RAR窗。
NB-IoT的MSG2支持基于NPDCCH调度的RAR传输，NPDCCH由RA-RNTI加扰，在MSG2的调度DCI中指示MSG2的repetitionstimes。
MSG2的RAR对应的RA-RNTI计算为：
RA-RNTI=1+floor（SFN/4）（SFN是NPRACH起始子帧所在的无线帧号）。
MACPDU中的RAPID指示NPRACH频域subcarrierID信息。
一个MSG2中可以包含多个时间相同而频域不同的NPRACH的RAR响应结果，以提高接入能力。
MSG2的RAR内容包含：
TA调整量，TempC-RNTI，MSG3的ULgrant。
MSG3：
UE收到MSG2后，在MSG2授权的NPUSCH资源上，发送携带建立原因的MSG3（RRCConnectionRequest）消息给eNodeB。
MSG3中携带CCCH信令和DVI/PHR，承载MSG3的NPUSCH的扰码由TempC-RNTI生成。
MSG3中携带CCCH根据场景不同而不同，在初始接入时使用RRCConnectionRequest，在RRC重建和RRC恢复时分别使用RRCConnectionReestablishmentRequest和RRCConnectionResumeRequest。
MSG2消息传输结束到MSG3消息传输开始的时间间隔需要>=12ms。
NB-IoT的MSG3支持multi-tone或者single-tone传输，UE通过选择的NPRACHResource，隐含指示其是否支持multi-tone。
但当NPRACH的重复次数为{32,64,128}时，MSG3不支持multi-tone。
不论是CP模式还是UP模式，MSG3的大小都是88bit。
MSG3的消息内容如下所示：
RRC连接建立原因与NAS层过程、NAS呼叫类型相关。
RRCconnectionrequest消息中携带UE标识。
如果上层提供了S-TMSI，则携带S-TMSI信息给eNodeB；如果没有S-TMSI信息，生成一个随机数给eNodeB。
NB-IoT系统中，UE的IMSI信息对eNodeB不可见。
eNodeB为UE建立上下文，如果eNodeB在短时间内，收到同一个UE的多次RRCconnectionrequest消息，则eNodeB只处理最近一次的RRCconnectionrequest。
eNodeB进行SRB1bis资源的准入和资源分配。
信令连接一律准入，不做判断。
如果资源分配成功，则继续后续流程。
如果资源分配失败，RRC连接请求会被拒绝。
当系统过载时RRC连接请求会被拒绝。
MSG4：
eNodeB向UE回复MSG4（RRCconnectionsetup）消息。
MSG4中包含CCCH信令和竞争解决MACCE（UEContentionResolutionIdentityMACControlElement）。
MSG4包含的CCCH信令根据场景不同而不同，在初始接入时使用RRCConnectionSetup，在RRC重建和RRC恢复时分别使用RRCConnectionReestablishment和RRCConnectionResume。
MSG4对应的NPDCCH的搜索空间与MSG2对应的NPDCCH的搜索空间相同，其由TempC-RNTI加扰。
MSG4的调度DCI中指示MSG4的repetitionstimes。
MSG4中携带竞争解决ID。
UE在发送MSG3之后即启动竞争解决定时器。
竞争解决定时器大小由SIB指示，大小为{1,2,3,4,8,16,32,64}*NPDCCH搜索空间周期，但最大不能超过10.24s。
如果竞争解决定时器超时，或者MSG4中的竞争解决ID不是自己的，那么竞争解决失败。
如果竞争解决成功，那么TempC-RNTI成为C-RNTI。
MSG4消息携带有SRB1承载完整的配置信息，包括PHY/MAC/RLC等各个实体的配置参数：
MSG5：
UE收到MSG4消息指示的资源信息，进行无线资源配置，配置完SRB1bis或SRB1后，通过上行逻辑信道UL-DCCH，在SRB1bis上发送MSG5消息（RRCconnectionsetupcomplete）给eNodeB，eNodeB收到RRCconnectionsetupcomplete消息后，RRC连接建立完成。
MSG5可以携带：
（a）来自NAS层的指示信息，例如：
终端是否支持不建立PDN连接的附着，是否支持UP模式优化传输方案等。
（b）上行的初始NAS消息，例如：
AttachRequest、TAURequest、DetachRequest、ServiceRequest、NAS数据等。
2.3.2RRC连接建立失败现象
路测终端信令
从路测设备的软件中观察RRC连接建立失败。
路测（DT/CQT）过程中，从L3信令窗口观察随机接入后发起的RRCConnectionRequest流程，若有异常，则统计为一次RRC异常事件。
主流测试软件均可统计RRC连接建立成功率。
网络侧信令
从网络侧信令跟踪观察RRC连接建立失败。
RRC连接建立过程由三个步骤构成：
（a）UE向eNB发送MSG3，如：
RRCConnectionRequest。
（b）eNB收到MSG3后，向UE发送MSG4，如：
RRCConnectionSetup。
（c）UE向eNB发送MSG5，如：
RRCConnectionSetupComplete。
通过信令跟踪，观察RRC连接建立失败是由于哪个阶段UE/eNB未接收到MSG消息。
网络侧话统数据
从网络侧话统数据观察RRC连接建立失败。
通过RRC连接建立成功率来评估是否存在异常，RRC连接建立成功率是RRC连接建立成功次数与RRC连接建立尝试次数的比值，该指标体现了eNodeB或者小区的UE接纳能力，是衡量接入成功率的一个重要指标。
流程图概要表述了RRC连接建立的过程。
主要包含了RRC连接建立成功，RRC连接建立被拒绝和RRC连接建立失败过程。
主要的采样点如下：
采样点1：
ENB接收到UE的RRC连接建立请求消息，进行采样统计。
采样点2：
ENB发送RRC连接建立消息，进行采样统计。
采样点3：
ENB接收到RRC建立完成消息，进行采样统计。
采样点4：
ENB发送RRC连接拒绝消息，进行采样统计。
采样点5：
ENB等待RRC连接建立完成消息定时器超时，采样统计
Counter需要区分RRC建立的原因和建立失败的原因。
在话统中，导致RRC连接建立失败的主要原因包括以下几类：
（1）eNodeB接纳失败
（2）定时器超时
（3）CCCPU负荷控制
（4）其他原因
从eNodeB侧来看，RRC连接建立失败包括两种情形：
一种是当eNodeB收到UE发送的RRCConnectionRequest消息后，向UE发送了RRCConnectionReject消息。
这种情况对应原因“eNB接纳失败”。
另外一种是eNodeB下发RRCCONNECTIONSETUP消息后，始终没有收到UE的响应（RRCCONNECTIONSETUPCOMPLETE）。
这种情况对应原因“定时器超时”。
2.3.3RRC连接失败定位流程
初步排查
（a）通过话统分析RRC连接失败问题
“TOP小区”问题：
分别去除前10％的“RRC连接建立成功率低TOP小区”，如果整网RRC建立指标明显改善，且与原来持平（或者达到了目标值），则定义为TOP小区问题。
“整网”问题：
分别去除前10％的“RRC连接建立成功率低TOP小区”后，如果整网RRC建立指标没有明显改善，则定义为整网问题。
RRC连接建立成功率趋势分析：
分析RRC连接建立成功率趋势，找出RRC连接建立成功率变化的转折点。
需要同时关联分析RRC连接建立成功率、用户数等信息。
（b）网络侧网元软件版本、硬件版本以及硬件型号差异排查
（c）查询告警、操作、配置等日志
（d）终端模组问题：
排查因终端模组问题导致的RRC连接建立失败，如：
终端异常掉电、终端配置问题或配置丢失、终端拨号机制、终端版本兼容性问题等。
参数核查
目前NB-IoT参数推荐配置，是经过大量现网实践后的参数配置建议，为了避免参数原因导致一些已知问题的重复定位，在路测或者定位问题前，必须优先进行参数核查，确保基站和核心网参数无异常。
与RRC连接建立过程有关的参数有：
（1）UE等待RRC连接响应的定时器长度（T300）
（2）UE监测无线链路失败的定时器（T310_UE）
（3）UE发射功率最大值
（4）上行初始传输重复次数
（5）下行初始传输重复次数
（6）HARQ（ACK/NACK）传输重复次数
（7）MSG4HARQ（ACK/NACK）重复次数
（8）NPDCCHCSS最大重复次数
（9）NPDCCHCSS的起始子帧
（10）NPUSCH子载波带宽及tone数选择方法
（11）竞争解决定时器
（12）上行初始MCS
（13）下行初始MCS
覆盖与干扰分析
在NB-IoT实验局或者建网初期，若未执行全面的清频动作，则可能存在NB的覆盖和干扰问题。
当分析RRC接入失败问题时，在执行完参数核查之后，还需要分析空口无线环境的覆盖和干扰情况。
当无线环境RSRP差，上下行干扰强时，无线环境会影响NPDCCH调度信息、上下行消息的发送和接收。
此时需通过控制或增强覆盖、排查干扰，以保证无线环境相对良好。
通过话统数据对无线环境进行大致排查：
如果20%的终端处于CE2，则优先处理小区下行覆盖问题。
如果NB网络的重叠覆盖度大于20%，则优先处理重叠覆盖问题。
如果RSSI接近-115dBm，则优先进行底噪抑制。
NB-IoT的理论底噪为-174+10*LOG（B）+NF=-132dBm。
其中：
B=15kHz，NF=0（系统噪声系数）。
预留6db门限，故若底噪明显大于-126dBm时，则认为有干扰。
由于物联网终端的安装特性，大多NB终端位置相对固定，则需要对相关小区内的特殊位置进行实测，根据实际情况进行调整。
并通过专业网管的小区用户CE分布指标，分析是否存在弱覆盖。
信令分析
在参数核查和覆盖干扰排查之后，如果还未成功定位问题原因，此时就需要针对性地对RRC连接建立失败现象进行复现，同时记录UE和eNB信令log，定位接入流程出现问题的步骤，做出相应排查。
（a）MSG1是否正常发送与接收
RACH失败有两种情况：
第一种是达到最大尝试次数LL1_RACH_ERROR_MAX_NUM_PREAMBLE_ATTEMPTS。
第二种是T300超时RRC_TIMER_T300_EXPIRY_IND。
具体是先达到最大尝试次数，还是T300先超时，取决于基站的配置。
（b）MSG2是否正常发送与接收
从RARtimer超时次数来分析RACH失败有多少次是由于RAR失败导致的。
RAR失败一般有两种情况：
第一种是preamble基站解析失败。
第二种是NPDSCH或者NPDCCH解析失败。
可以通过RARtimerexpire的次数来查看。
先通过查看SINR值，判断是不是由于下行干扰导致第二种RAR失败。
若SINR良好，则可能是基站没有收到preamble或者没有RAR调度，此时需要查看上行干扰、覆盖、参数配置。
（c）MSG3是否正常发送与接收
如果从UELog中查看UE是否已经将MSG3发送到空口，如果没有发送则需要与UE厂商人员联合分析。
如果UE已发送MSG3，需要同时查看网管上的接入信令中是否有对应的MSG3。
MSG3失败原因可能是MSG3重传达到最大重复次数，此时需要查看是否是存在干扰或者覆盖问题，导致MSG3一直重传失败。
（d）MSG4是否正常发送与接收
查看网管eNB侧信令是否下发MSG4，如果没有则联系eNB侧人员排查，此种情况比较少见。
如果网管侧看到eNB下发MSG4，但是UE侧失败原因为NPDSCH解析失败，则需要排查下行无线环境RSRP或SINR是否比较差，并判断是否已经超过UE的解调能力。
如果无线环境正常，则需要检查NPDCCH调度是否正常，此时需要采集基站底层TTI级日志分析。
T300定时器：
T300计时器用于监控RRC连接建立过程。
当UE发送了RRCConnectionRequest消息后启动该计时器，当UE收到RRCConnectionSetup或RRCConnectionReject消息以后停止并重置该计时器。
当计时器超时后，高层终止RRC连接建立过程并开始小区重选
（e）MSG5是否正常发送与接收
竞争解决完成后，如果UE没有发送MSG5，则需要排查MSG5的调度是否正常。
如果UE发送了MSG5但是基站没有正常接收，则需要排查上行是否存在干扰、NPUSCH的功率控制参数设置是否正常。
其它分析
容量分析：
排查是否由于容量受限，导致无法接入，在随机接入阶段时频资源受限，或者RRC连接个数受限。
2.3.4RRC连接失败常见原因
（1）上行干扰导致MSG3/MSG5/UCI解析失败。
（2）下行干扰导致RAR解析失败/下行DCIN1解析失败/MSG4解析失败。
（3）竞争解决定时器配置不合理导致在定时器超时前还未收到竞争解决消息。
（4）T300定时器设置过短导致定时器超时前未收到MSG4消息。
（5）上行重复次数配置过小导致基站NPUSCH/UCI解调失败。
（6）下行重复次数过低导致NPDSCH解析失败。
（7）RRC连接数达到单板规格。
（8）设备告警，空调、功放等问题导致eNodeB接纳失败。
三、推广效果
3.1推广实践情况
3.1.1问题描述
后台指标监控发现本周佛山电信NB全网（中兴区域）RRC连接建立成功率指标严重恶化（未达标：
93%达标），较上周有明显下降，查询发现主要为嘉诚酒店NB_4（501763_81）指标恶化，出现大量RRC连接建立失败，严重影响全网指标，如下图所示：
查询粒度
小区名称
RRC连接建立成功率
NB-IoT小区RRC连接建立请求次数
NB-IoT小区RRC连接建立成功次数
NB-IoT小区RRC连接建立失败次数
1周
嘉诚酒店NB_4
45.13%
82716
37330
45386
3.1.2分析过程
性能指标分析：
从网管提取嘉诚酒店NB_4问题小区最近指标分析发现，嘉诚酒店NB_4扇区RRC连接建立失败主要原因为:
“小区接纳失败（eNBRRC连接个数不足）和基站RRC成功连接次数license（eNBRRC连接个数不足）”，如下表所示：
开始时间
RRC连接建立最大用户数
RRC连接建立成功率
NB-IoT小区RRC连接建立请求次数
NB-IoT小区RRC连接建立成功次数
NB-IoT小区RRC连接失败次数（UE无应答）
NB-IoT小区RRC连接建立失败次数（小区Reject）
NB-IoT小区RRC连接建立失败次数（其它原因）
NB-IoT小区RRC连接建立失败次数
2019/5/6
0
100.00%
0
0
0
0
0
0
2019/5/7
0
100.00%
0
0
0
0
0
0
2019/5/8
11
30.41%
33693
10246
108
0
23339
23447
2019/5/9
11
29.90%
48786
14588
147
0
34051
34198
2019/5/10
11
28.71%
5816
1670
20
0
4126
4146
2019/5/11
11
31.59%
29571
9342
111
0
20118
20229
2019/5/12
11
33.49%
31084
10410
103
0
20571
20674
2019/5/13
11
34.64%
28092
9732
79
0
18281
18360
2019/5/14
10
47.40%
3561
1688
6
0
1867
1873
2019/5/15
1
100.00%
7
7
0
0
0
0
2019/5/16
11
44.94%
11155
5013
27
6115
0
6142
2019/5/17
79
37.96%
30531
11591
110
18830
0
18940
2019/5/18
61
99.63%
1616
1610
6
0
0
6
2019/5/19
47
99.16%
7754
7689
65
0
0
65
2019/5/20
68
99.30%
11985
11901
83
0
1
84
2019/5/21
64
99.26%
2294
2277
17
0
0
17
用户行为分析：
提取嘉诚酒店NB_4小时级的RRC连接建立次数，发现持续多日该小区用户接入突增都主要发生在19：
00到次日8:
00，初步判断为周边存在集体用户在持续尝试接入，导致RRC连接建立次数明显突增，如下表所示：
Li
升级会员 