利用RRC重建比例定位异常终端_第1页
利用RRC重建比例定位异常终端_第2页
利用RRC重建比例定位异常终端_第3页
利用RRC重建比例定位异常终端_第4页
利用RRC重建比例定位异常终端_第5页
已阅读5页,还剩5页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、利用RRC重建比例定位异常终端【摘要】 异常终端对网络KPI性能影响大,本文通过某基站RRC重建比例异常问题的解决,通过信令分析定位为某一款终端在异频切换时概率性存在重配置失败触发重建,与此同时摸索出异常终端排查的流程供现场优化工程师参考。 一、   问题描述 通过日常指标监控发现站点LF_H_南浔思进小学自开通以来RRC重建比例指标存在异常,重建比例有时高达80%以上,通过查询话统发现重建原因不属于切换失败和重配置失败(2小区尤为严重),如下表所示: 日期 小区名称 RRC重建比例(%) RRC重建请求次数 RRC重建成功次数 切换失败触发RRC重建请求的次数 重配置失败

2、触发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.11

3、34 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重建比例较高和重配置失败,切换失败没

4、有直接关系,如下图示: 2.3 信令跟踪分析 通过对UU接口跟踪信令进行分析,发现RRC重建集中在某些TOP用户,统计比例如下表: CALL ID 计数项:Call ID 占比 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%

5、 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次以上的CALL ID只有15个,因此占重建用户次数4.6%的用户贡献了96.19%的重建次数,可以确认为Top用户导致的问题。 从信令跟踪来看,异常用户平均2s重建一次,反复重建导致指标恶化。 2.1 现象原因定位 2.1.1  排除常规重建原因 通

6、过分析UU口信令发现,同一TOP终端反复重建,重建原因值为otherFailure,如下图示: 通常引起原因值为“otherFailure”的机制有以下三种: 1)MAC层SRI重传达到最大次数 2)上行RLC重传达到最大次数 3)UE检测到下行无线链路失败 从呼叫日志上分析来看: 1)SR无重传,排除MAC层SRI重传达到最大次数 2)终端在该段时间无数据发送,终端最后一次发起SR到终端发起重建的时间相隔700800ms,而RLC重传达到最大次数需要1.6s,发起重建的时间短于达到上行RLC重传达到最大次数时间,可排除终端上行RLC重传达到最大次数。 3)从日志中来看,下行调度一直可以得到终

7、端的反馈,因此排除UE监测到下行无线链路失败。 因此,排除通常引起重建的三种原因,排除与空口环境的关系。 2.1.1  终端重建原因分析 通过分析CELLDT Trace,发现终端在重建之前,基站给终端下发的CQI上报模式为非周期CQI_Only,但UE没有在eNB要求的CQI Only时刻上报CQI,此后终端开始周期CQI上报,周期为20ms,因此怀疑终端试图通过发起RRC连接重建恢复其周期CQI上报。 CQI周期与非周期上报:CQI上报分为周期上报和非周期上报,周期CQI在PUCCH上报, 但由于上行的单载波特性要求, 当UE有数据在PUSCH上传送时, 周期CQI会随数据一起在

8、PUSCH上传送;非周期CQI在PUSCH上报,当DCI0中CQI request置1时, UE上报非周期CQI。 CQI Only调度原则,在上报非周期CQI时,如果此时有上行数据传输, 则属于随路CQI,与数据一起传送;如果没有上行数据传送则CQI_Only传送,即UE在PUSCH只上报CQI. CQI_Only具有调度优势: 1) 保证CQI的实时性,在周期CQI上报不及时,为了更好的适配网络信道质量变化,触发非周期CQI来继续上报CQI,而当没有上行数传时,就会触发CQI ONLY来获取最新CQI,这样基站可以获取较新的CQI保证下行调度选择MCS的准确性; 2)CQI_Only是在U

9、E没有上行数据时发送的并且没有重传,不会造成UL吞吐量的下降,CQI_Only调度不会影响DRX状态.如果关闭该功能,导致基站不能及时获取下行信道质量,影响下行吞吐量。 分两步进行终端CQI上报模式改变分析: 1) 基站下发CQI_Only调度的原因,整个过程简述:周期CQI->原因1变成非周期CQI-> 原因2变成CQI only。 原因1:DRX周期>5*N+1 原因2:UE此时没有UL数据发送,只发CQI 如下图所示:   终端在进入DRX之前为周期CQI上报,周期为20ms; 终端进入DRX状态(DRX长周期160ms,集团参数),其CQI周期拉长为160m

10、s; 由于基站在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)的时间内无法收到有效

11、的周期CQI上报,所以触发非周期CQI调度,而刚好UE此时没有上行数据发送,所以触发了CQI_Only。 2)通过基站和UE的行为分析,可知终端在CQI Only时刻没有按照eNB指示上报CQI的原因,下图呈现出了基站对某个UE整个CQI_Only调度过程: 编号相同的是对应的一次调度的数据,1是CRC正确的;2、3、4、5是 CRC 错误的;从图看出,基站都是在激活态下发的DCI0,并且CQI_Only的触发不会改变DRX状态,符合协议要求.其中第3组有点特殊,基站在激活态发DCI0,UE可以在休眠态或者激活态发送CQI,属于UE自己的行为.(协议36.331 5.5.4.1:If the

12、UE is configured with DRX, the UE may delay the measurement reporting for event triggered and periodical triggered measurements until the Active Time).其余几组数据基站下发DCI0和UE发CQI都是在激活态完成的。 异常终端进入DRX休眠态不发送CQI是造成RRC连接重建以恢复周期CQI上报的最直接原因。 三、问题解决 将LF_H_南浔思进小学的LongDrxCycle从160ms修改为100ms,当将长周期修改为100ms后,DRX周期<

13、5*N+1(DRX周期改为100ms,5*N+1=101ms),发现重建比率恢复正常,如下图所示: 该验证说明,只要异常终端不进入非周期CQI,就不会触发异常重建,而正常终端由于进入非周期CQI的时候,由于与协议的契合性较好,不会触发重建,不会出现异常终端所出现的问题。 四、异常终端定位 4.1 异常终端TMSI抓取 通过对TOP小区LH_F_南浔思进小学的信令进行跟踪和分析,抓取到异常终端(FGI=7E0FF8DE)用户在某一时刻的TMSI为0x E0 3B 08 10。如下图: 4.2 用户IMSI转换 TMSI与GUTI转换规则如下:   TMSI 0x E0 3B 08 10

14、转换成GUTI为46011130561E03B0810 通过命令DSP MMCTX查询GUTI为46011130561E03B0810的用户IMSI为460110159269389。 4.2 用户手机号提取 通过用户综合调度平台查询IMSI 460110159269389的用户的手机号码为189*。 4.3 异常终端机型定位 通过用户手机号码回访用户,得知用户使用的手机型号为nubiaZ9 MAX,后续推动厂家更新软件版本解决。 五、经验总结 随着4G用户的不断增加,网络许多问题是由异常用户、异常终端导致的。而目前详细话单还不方便提取,本案例中的一些定位异常终端的方法思路可供借鉴。通过本案例总结出定位异常终端的思路如下: 1、通过分析UU口信令发现是引起RRC重建的原因是由异常终端引起的,进一步分析UU口信令排除了无线环境的原因。 2、4G网络不同于CDMA网络,信令传输时不再是IMSI而是网络给IMSI分配的TMSI,定位异常终端需通过信令中的异常终端的TMSI,经过授权通过GUTI在MME网管中查询用户的IMSI,再由综合调度平台查询用户的手机号码,对用户进行回访确定用户使用的终端类型。 1)  通过异常终端长期出现的TOP小区信令,寻找异常终端的TMSI 2)  将TMIS按规则转换

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论