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

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

2、%)次数次数请求的次数请求的次数2015-09-16LF_H_南潯思进小学_50308. 3364850784797302015-09-17LF_H_南得思进小学_50180.4223564056161602015-09-18LF_H_南潯思进小学_50493. 507710566105356802015-09-19LF_H_南潯思进小学_50385. 03438979892722802015-09-20LF_H_南得思进小学_50870.828321553215119302015-09-21LF_H_南潯思进小学_50502. 113414255142375802015-09-22LF_H_

3、南潯思进小学_50399. 69613150131236802015-09-23LF_H_南得思进小学_50395. 627712668126527902015-09-24LF_H_南潯思进小学_50299.465489638942782问题处理2. 1告警和操作排查查询基站无相关告警信息，基站配置未出现错误，且基站开通后无相关参数 修改和操作记录，排除基站侧问题。2. 2话统问题分析KPI指标分析可知，该站点RRC重建比例较高和重配置失败，切换失败没有直接关系，如下图示：坐标轴标题-一 RRC重建请求次数-一切换失败触发RRC重建请求的 次数重配S失败触发RRC重建请求的次 数2. 3信令跟

4、踪分析通过对UU接口跟踪信令进行分析，发现RRC重建集中在某些TOP用户，统计比例如下表：CALL ID 计数项：Call ID 占比127092294228. 84%126767185918. 22%126546139013. 63%126093124112. 17%8414053115111.28%1264356436. 30%167909554374. 28%127968360. 35%122385220. 22%122724200. 20%122704190. 19%123079180. 18%123577120. 12%125422120. 12%805436484100. 10%8

5、0543977610. 01%总数10201100. 00%Topi用户的重建次数为2942次，占总数的28.84%, Top5用户的重建次数84. 14%,贡献了绝大多数重建。而用户CalllD总共有327个，重建次数在10次以上的CALLD只有15个，因此占重建用户次数4.6%的用户贡献了 96. 19%的重建次数，可以确认为Top用户导致的问题。从信令跟踪来看，异常用户平均2s重建一次，反复重建导致指标恶化。2. 1现象原因定位2. 1. 1排除常规重建原因图示:W :Tint fc*xJ* T irpiljt4M0:MC*.fiftJiO . j VTlt刃二土馬FL足tUFfy r

6、孰 rTiMvr 1-,丫曲斬一-5歹5厂IhdWTt,13K4如 1 沁 2* !M6 RfiCStffA4T*e*严卡烧尙d飾UfiCRwTkzdK ftJ c*=Eirrf4iurTTM122如TftA_ijiB11 n 59(941) RftC*COMJARfESTtfARts 略察 iPraEi HlCWJTIXD? 04. pajTa camt3i?iieimMTRACE,扁q皿魚iTii珈两匕奁3礼Rfi爭QL覽童扫M和严叫E七只応迫eC* ZW gvHgVX测E?V砸魅 炉TfWOt.144121, 17 :CANTlDC 心.pm To. J,I r rfab tilJ2HH

7、at115Jj, RRC.C0WLRfe?T4B_尺 Mann 阿 iuECRNTttg U : H79 thJtT*wF*lirt；札UiX1224W知百 1) nOOWJJiSTiB*K4*4Fi4i REST4flRtM4F Uj CUECRFEtOS* . Eflijft njiti C/fiftf MMt.zT7M1223WOE.141W24 Wg &7(M9 HRC_OOHNlJitSTAB，CRNIRC 8 pa-fO21 v 1TRACt,盘*MIF 网 nUECPPJTliK IF , pOiTO 弟 trfw 喷.2li7MX _nwiE,UIM，/i 五 i 石&匚丑待

8、17 loilSftV RRC.COKjrftSTif 17RwJfrnUECRrJTr=07 E* pOhTCB.远 bo 哥関沖蒂 iMt：2rflXtir17 4T UJ RRCOOtPNLWFSTAfl-R*ct 和fheuetRNTttO 赳 4C , 2祀 QiTFcVIWff 鉀爭. JiVM计强nucf1? 17 1A71* RftCOOtffCffiESTAfiCHfJTL=Ofl p3fJAtrFaUi.231224HU3JSIT订 I4i： ?2SjRftC_C0MN_RE八5T5BCmTlrSC 乃：PO池*WSfi如34TTAGt.142511IT 7 15C5571

9、中 侯 dflELIg退.e*4x*traur2f 1JUjtBlAtcnml*Yai*UCCWJTITOS 21 pa iT0 JiM*2 11但冲TRAdE.個3炳押冠打衬昶=田战彰占硕OC 10. 0*T0 里虫eI1 mijhlj14.39t1 jOIMW-JI, 11 7 ?1(B3Bj(*RftC.OOWJReaT4aAUHFriKnLtCANTUM E7 住31皿0#1祜里抽431她rwtet.144吨jv. t&lj RRC_COH_ReST4a-CRNTMK： AC.呻恥 CM沖 irf 怕4a*11 w7、/沸TR*J1443f星4 If 7 3岁7趴婪1. 6 Hl耳聲T

10、%F*h*dfn!fflUCRNT1=6B IS p (5*N+1),基站在(5*N+1)的时间内无法收到有效的周期CQI上报，所以触发非周期CQI调度，而刚好UE此时没有上行数据发送，所以触发了 CQI_0 niyo2)通过基站和UE的行为分析，可知终端在CQI Only时刻没有按照eNB指 示上报CQI的原因,下图呈现出了基站对某个UE整个CQI_0nly调度过程：f“跖弓一不畑彳红&表乐I巫败到IX W珂庵 藍邑农眾I范农CQ朗紳两诵村帶如谓编号相同的是对应的一次调度的数据，1是CRC正确的；2、3、4、5是CRC错误的；从图看出，基站都是在激活态下发的DCI0,并且CQI_0nly的触

11、发不会 改变DRX犬态,符合协议要求其中第3组 有点特殊，基站在激活态发DCIO, UE可以在休眠态或者激活态发送CQI,属于UE自己的行为.(协议36. 331 5. 5.4.1 :If the UE is con figured with DRX, the UE may delay the measureme ntreporting for eve nt triggered and p eriodical triggered measureme ntsu ntilthe Active Time)其余几组数据基站下发DCI0和UE发CQI都是在激活态完成的。异常终端进入DRX休眠态不发送CQ

12、I是造成RRC连接重建以恢复周期CQI上 报的最直接原因。三、问题解决将LF_HW M思进小学的LongDrxCycle从160ms修改为100ms当将长周期 修改为100ms后，DRX 周期 v5*N+l( DRX 周期改为 100ms 5*N+1 二 101ms,发现重建比率恢复正常，如下图所示：RRC.重建比例BI0 弓400R眈重建比例该验证说明，只要异常终端不进入非周期CQI,就不会触发异常重建，而正常终端由于进入非周期CQI的时候，由于与协议的契合性较好，不会触发重建，不会出现异常终端所出 现的问题。四、异常终端定位4. 1异常终端TMSI抓取通过对TOP小区LH_Fj南得思进小学

13、的信令进行跟踪和分析， 抓取到异常终端（FGI二7E0FF8DE用户在某一时刻的TMSI为Ox EO 3B 08 10。如下图:Dtldiiro丨c誤廿 ? ： 1 時斗孑釈 RRJ -! irJM.PFO iF何闩.fll j=F fn 3 F r . -： 11 RR-:J V ” =e:J ri . 117 4 47(5*11 RRC. COf JH. *ETVPN&LIEM1W39-24 17 4$ 4 軒 2 4 创 RRC. COr JN 5 TUP. CMPU-fPJe1亞”201 卷伪坨 4 17*W(2T0 ftRC Sf CUR HODEChD利旧-LIEig4.用户IMS

14、I转换2TMSI与GUTI转换规则如下:S-TMI5I1U IMIITSIPLM1 IN IDMIMIEIMice:2 LllTsMl NIC 减二 二!ltiMIMIEGII5, ji t- rMMIECH hrtsM TMISI52v-GUMIMEI*raBGUTITMSI Ox EO 3B 08 10 转换成 GUTI 为 46011130561E03B0810通过命令 DSP MMCT 查询 GUTI 为 46011130561E03B081 (的用户 IMSI 为460110159269389c4. 2用户手机号提取通过用户综合调度平台查询IMSI 460110159269389的用

15、户的手机号码为189*4. 3异常终端机型定位通过用户手机号码回访用户，得知用户使用的手机型号为 n ubiaZ9 MAX,后续推动厂家更新软件版本解决。五、经验总结随着4G用户的不断增加，网络许多问题是由异常用户、异常终端导致的。而冃前详细话单还不方便提取，本案例中的一些定位异常终端的方法思路可供借鉴。通过本案例总结 出定位异常终端的思路如21、 通过分析UU 口信令发现是引起RRC重建的原因是由异常终端引起的，进 步分析UU 口信令排 除了无线环境的原因。2、 4G网络不同于CDMA网络，信令传输时不再是IMSI而是网络给IMSI分配的TMSI,定位异常终端需通过信令中的异常终端的TMS,

16、经过授权通过GUTI在MM网管中查询用户的IMSI,再由综合调度平台查询用户的手机号码，对用户进行回访确足用户使用的终端类型。1）通过异常终端长期出现的TOP小区信令，寻找异常终端的TMSI2）将TMIS按规则转换成的GUTI3）通过MM网管用命令DSPMMCT查询用户的IMSI （需要注意事项：获取用户的IMSI和手机号 码信息以及回访用户获取终端类型，需得到客户的书面授权。）通过客户的综合调度系统用IMSI查询用户的手机号码4）通过用户的手机号码回访用户，获取用户使用的终端类型5）6） 用户的TMSI是定期更新的，MME寸TMSI的更新规则是周期（24小时左 右）内只更新TMSI的第四位，超过周期将更行TMSI全部位数。