利用RRC重建比例定位异常终端.docx
- 文档编号:3467055
- 上传时间:2022-11-23
- 格式:DOCX
- 页数:9
- 大小:415.89KB
利用RRC重建比例定位异常终端.docx
《利用RRC重建比例定位异常终端.docx》由会员分享,可在线阅读,更多相关《利用RRC重建比例定位异常终端.docx(9页珍藏版)》请在冰豆网上搜索。
利用RRC重建比例定位异常终端
利用RRC重建比例定位异常终端
【摘要】
异常终端对网络KPI性能影响大,本文通过某基站RRC重建比例异常问题的解决,通过信令分析定位为某一款终端在异频切换时概率性存在重配置失败触发重建,与此同时摸索出异常终端排查的流程供现场优化工程师参考。
一、 问题描述
通过日常指标监控发现站点LF_H_南浔思进小学自开通以来RRC重建比例指标存在异常,重建比例有时高达80%以上,通过查询话统发现重建原因不属于切换失败和重配置失败(2小区尤为严重),如下表所示:
日期
小区名称
RRC重建比例(%)
RRC重建请求次数
RRC重建成功次数
切换失败触发RRC重建请求的次数
重配置失败触发RRC重建请求的次数
2015-09-16
LF_H_南浔思进小学_50
308.3364
8507
8479
73
0
2015-09-17
LF_H_南浔思进小学_50
180.4223
5640
5616
16
0
2015-09-18
LF_H_南浔思进小学_50
493.5077
10566
10535
68
0
2015-09-19
LF_H_南浔思进小学_50
385.0343
8979
8927
228
0
2015-09-20
LF_H_南浔思进小学_50
870.8283
21553
21511
93
0
2015-09-21
LF_H_南浔思进小学_50
502.1134
14255
14237
58
0
2015-09-22
LF_H_南浔思进小学_50
399.696
13150
13123
68
0
2015-09-23
LF_H_南浔思进小学_50
395.6277
12668
12652
79
0
2015-09-24
LF_H_南浔思进小学_50
299.4654
8963
8942
78
2
一、 问题处理
2.1告警和操作排查
查询基站无相关告警信息,基站配置未出现错误,且基站开通后无相关参数修改和操作记录,排除基站侧问题。
2.2话统问题分析
KPI指标分析可知,该站点RRC重建比例较高和重配置失败,切换失败没有直接关系,如下图示:
2.3信令跟踪分析
通过对UU接口跟踪信令进行分析,发现RRC重建集中在某些TOP用户,统计比例如下表:
CALLID
计数项:
CallID
占比
127092
2942
28.84%
126767
1859
18.22%
126546
1390
13.63%
126093
1241
12.17%
8414053
1151
11.28%
126435
643
6.30%
16790955
437
4.28%
127968
36
0.35%
122385
22
0.22%
122724
20
0.20%
122704
19
0.19%
123079
18
0.18%
123577
12
0.12%
125422
12
0.12%
805436484
10
0.10%
…
…
…
805439776
1
0.01%
总数
10201
100.00%
Top1用户的重建次数为2942次,占总数的28.84%,Top5用户的重建次数84.14%,贡献了绝大多数重建。
而用户CallID总共有327个,重建次数在10次以上的CALLID只有15个,因此占重建用户次数4.6%的用户贡献了96.19%的重建次数,可以确认为Top用户导致的问题。
从信令跟踪来看,异常用户平均2s重建一次,反复重建导致指标恶化。
2.1现象原因定位
2.1.1 排除常规重建原因
通过分析UU口信令发现,同一TOP终端反复重建,重建原因值为otherFailure,如下图示:
通常引起原因值为“otherFailure”的机制有以下三种:
1)MAC层SRI重传达到最大次数
2)上行RLC重传达到最大次数
3)UE检测到下行无线链路失败
从呼叫日志上分析来看:
1)SR无重传,排除MAC层SRI重传达到最大次数
2)终端在该段时间无数据发送,终端最后一次发起SR到终端发起重建的时间相隔700~800ms,而RLC重传达到最大次数需要1.6s,发起重建的时间短于达到上行RLC重传达到最大次数时间,可排除终端上行RLC重传达到最大次数。
3)从日志中来看,下行调度一直可以得到终端的反馈,因此排除UE监测到下行无线链路失败。
因此,排除通常引起重建的三种原因,排除与空口环境的关系。
2.1.1 终端重建原因分析
通过分析CELLDTTrace,发现终端在重建之前,基站给终端下发的CQI上报模式为非周期CQI_Only,但UE没有在eNB要求的CQIOnly时刻上报CQI,此后终端开始周期CQI上报,周期为20ms,因此怀疑终端试图通过发起RRC连接重建恢复其周期CQI上报。
CQI周期与非周期上报:
CQI上报分为周期上报和非周期上报,周期CQI在PUCCH上报,但由于上行的单载波特性要求,当UE有数据在PUSCH上传送时,周期CQI会随数据一起在PUSCH上传送;非周期CQI在PUSCH上报,当DCI0中CQIrequest置1时,UE上报非周期CQI。
CQIOnly调度原则,在上报非周期CQI时,如果此时有上行数据传输,则属于随路CQI,与数据一起传送;如果没有上行数据传送则CQI_Only传送,即UE在PUSCH只上报CQI.
CQI_Only具有调度优势:
1)保证CQI的实时性,在周期CQI上报不及时,为了更好的适配网络信道质量变化,触发非周期CQI来继续上报CQI,而当没有上行数传时,就会触发CQIONLY来获取最新CQI,这样基站可以获取较新的CQI保证下行调度选择MCS的准确性;
2)CQI_Only是在UE没有上行数据时发送的并且没有重传,不会造成UL吞吐量的下降,CQI_Only调度不会影响DRX状态.如果关闭该功能,导致基站不能及时获取下行信道质量,影响下行吞吐量。
分两步进行终端CQI上报模式改变分析:
1)基站下发CQI_Only调度的原因,整个过程简述:
周期CQI->原因1变成非周期CQI->原因2变成CQIonly。
原因1:
DRX周期>5*N+1
原因2:
UE此时没有UL数据发送,只发CQI
如下图所示:
① 终端在进入DRX之前为周期CQI上报,周期为20ms;
②终端进入DRX状态(DRX长周期160ms,集团参数),其CQI周期拉长为160ms;
③由于基站在5*N+1(N为CQI上报周期)时间内没有收到有效的CQI上报,触发非周期CQI。
算法之所以约束“在5*N+1这段时间内没有CQI上报,就会触发非周期CQI”,是为了保证CQI的时效性,如果周期CQI上报不及时,为了更好的适配网络信道质量变化,触发非周期CQI来继续上报CQI。
当前版本,CQI默认上报周期是20ms,则5*N+1=101ms,而DRX的长周期(LongDrxCycle)配置为160ms,而在DRX休眠期,终端是不能在PUCCH上报周期CQI的,因此终端CQI上报的周期拉长为160ms。
160>(5*N+1),基站在(5*N+1)的时间内无法收到有效的周期CQI上报,所以触发非周期CQI调度,而刚好UE此时没有上行数据发送,所以触发了CQI_Only。
2)通过基站和UE的行为分析,可知终端在CQIOnly时刻没有按照eNB指示上报CQI的原因,下图呈现出了基站对某个UE整个CQI_Only调度过程:
编号相同的是对应的一次调度的数据,1是CRC正确的;2、3、4、5是CRC错误的;从图看出,基站都是在激活态下发的DCI0,并且CQI_Only的触发不会改变DRX状态,符合协议要求.其中第3组有点特殊,基站在激活态发DCI0,UE可以在休眠态或者激活态发送CQI,属于UE自己的行为.(协议36.3315.5.4.1:
IftheUEisconfiguredwithDRX,theUEmaydelaythemeasurementreportingforeventtriggeredandperiodicaltriggeredmeasurementsuntiltheActiveTime).其余几组数据基站下发DCI0和UE发CQI都是在激活态完成的。
异常终端进入DRX休眠态不发送CQI是造成RRC连接重建以恢复周期CQI上报的最直接原因。
三、问题解决
将LF_H_南浔思进小学的LongDrxCycle从160ms修改为100ms,当将长周期修改为100ms后,DRX周期<5*N+1(DRX周期改为100ms,5*N+1=101ms),发现重建比率恢复正常,如下图所示:
该验证说明,只要异常终端不进入非周期CQI,就不会触发异常重建,而正常终端由于进入非周期CQI的时候,由于与协议的契合性较好,不会触发重建,不会出现异常终端所出现的问题。
四、异常终端定位
4.1异常终端TMSI抓取
通过对TOP小区LH_F_南浔思进小学的信令进行跟踪和分析,抓取到异常终端(FGI=7E0FF8DE)用户在某一时刻的TMSI为0xE03B0810。
如下图:
4.2用户IMSI转换
TMSI与GUTI转换规则如下:
TMSI0xE03B0810转换成GUTI为46011130561E03B0810
通过命令DSPMMCTX查询GUTI为46011130561E03B0810的用户IMSI为460110159269389。
4.2用户手机号提取
通过用户综合调度平台查询IMSI460110159269389的用户的手机号码为189********。
4.3异常终端机型定位
通过用户手机号码回访用户,得知用户使用的手机型号为nubiaZ9MAX,后续推动厂家更新软件版本解决。
五、经验总结
随着4G用户的不断增加,网络许多问题是由异常用户、异常终端导致的。
而目前详细话单还不方便提取,本案例中的一些定位异常终端的方法思路可供借鉴。
通过本案例总结出定位异常终端的思路如下:
1、通过分析UU口信令发现是引起RRC重建的原因是由异常终端引起的,进一步分析UU口信令排除了无线环境的原因。
2、4G网络不同于CDMA网络,信令传输时不再是IMSI而是网络给IMSI分配的TMSI,定位异常终端需通过信令中的异常终端的TMSI,经过授权通过GUTI在MME网管中查询用户的IMSI,再由综合调度平台查询用户的手机号码,对用户进行回访确定用户使用的终端类型。
1) 通过异常终端长期出现的TOP小区信令,寻找异常终端的TMSI
2) 将TMIS按规则转换成的GUTI
3) 通过MME网管用命令DSPMMCTX查询用户的IMSI(需要注意事项:
获取用户的IMSI和手机号码信息以及回访用户获取终端类型,需得到客户的书面授权。
)
4) 通过客户的综合调度系统用IMSI查询用户的手机号码
5) 通过用户的手机号码回访用户,获取用户使用的终端类型
6)用户的TMSI是定期更新的,MME对TMSI的更新规则是周期(24小时左右)内只更新TMSI的第四位,超过周期将更行TMSI全部位数。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 利用 RRC 重建 比例 定位 异常 终端
![提示](https://static.bdocx.com/images/bang_tan.gif)