利用RRC重建比例定位异常终端讲解Word格式.docx

利用RRC重建比例定位异常终端讲解Word格式.docx

《利用RRC重建比例定位异常终端讲解Word格式.docx》由会员分享，可在线阅读，更多相关《利用RRC重建比例定位异常终端讲解Word格式.docx（9页珍藏版）》请在冰豆网上搜索。

8479

73

0

2015-09-17

180.4223

5640

5616

16

2015-09-18

493.5077

10566

10535

68

2015-09-19

385.0343

8979

8927

228

2015-09-20

870.8283

21553

21511

93

2015-09-21

502.1134

14255

14237

58

2015-09-22

399.696

13150

13123

2015-09-23

395.6277

12668

12652

79

2015-09-24

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

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监测到下行无线链路失败。

因此，排除通常引起重建的三种原因，排除与空口环境的关系。

终端重建原因分析

通过分析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） 

通过用户的手机号码回访用