湖州TD寻呼成功率低问题分析处理报告

1、湖州TD寻呼成功率低问题分析湖州TD 某RNC寻呼成功率仅80%左右，与其他TD RNC或GSM的LAC相比差距明显，通过对核心网寻呼策略的分析优化，寻呼成功率提升到96%。以下为对该问题的分析处理，以期对处理寻呼成功率低问题有些借鉴，谢谢指正。一、 问题描述湖州TD RNC9、LAC_ID=55208、织里区域，寻呼成功率仅80%左右，远低于TD其他各RNC及GSM其他LAC的寻呼成功率；统计一周指标发现只有RNC9寻呼成功率明显偏低. （数据来源浙江移动-交换性能分析系统）Ø 四个交换寻呼成功率相当,均稳定在94%左右;Ø 问题RNC9共交换下的各LAC寻呼成功率正常;

2、Ø TD共8个RNC,其他7个RNC寻呼成功率均在90%以上,与问题RNC9差距明显;1).四个交换寻呼成功率相当,稳定在94%左右,一周指标统计图如下: 2) .问题RNC9挂在交换HUZGS4下,该交换下其他LAC的寻呼成功率,指标正常,均在90%以上.3).湖州TD共8个RNC,寻呼成功率差异较大，统计最近一周指标，寻呼成功率较高的RNC5、RNC6达到99%以上，最低的RNC9仅76.02%，其他RNC寻呼成功率92%左右。二、问题分析寻呼成功率是一个系统级的问题，涉及MSC、SGSN、RNC、NodeB和UE，影响寻呼功率的因素有很多，涉及到端到端的众多网元，任何一个网元都

3、会影响最终的寻呼成功率结果。主要影响因素有：l 核心网寻呼策略设置及寻呼参数配置；l 网络覆盖情况及覆盖场景；l 网络干扰情况；l RNC寻呼信道配置；l 23G重选参数设置；l 终端质量； 等等从无线侧网络原因、核心网寻呼策略设置及寻呼参数配置以及寻呼失败TOP用户三个纬度进行分析。<一>无线侧原因分析从信令流程上面可以看到：RNC收到CN下发的Paging消息到RNC给CN回Paging响应消息主要经历Paging消息下发，终端接收Paging消息、及终端收到Paging消息之后建立RRC链接、通过直传消息给RNC上发寻呼响应的过程。 除了以上信令流程失败导致寻呼失败外；在位置

4、区更新过程中，也是寻呼不到用户的，另外寻呼拥塞也是寻呼失败的可能原因，因此无线侧主要从可能导致的这三方面失败的原因进行分析，从核查结果看，问题RNC9未发现无线侧可能导致寻呼成功率异常的原因。l RNC寻呼容量及寻呼能力分析RNC上配置的寻呼信道数及与寻呼容量相关的参数足够承载当前话务负荷的寻呼量，而且从RNC上话统看也不存在PCH拥塞的情况；l 故障告警情况与寻呼成功率的关联对比故障告警的条数与寻呼成功率情况，并没有关联的关系，RNC9反而是故障告警数较少的RNC，从现象上看RNC9的寻呼成功率与故障告警情况并无正向关联；l 话务情况、无线接通率、无线掉话率、CS域23G切换成功率分析通过话

5、务量核查对比，目前各RNC的话务量并不高，且RNC9并无高话务导致拥塞的现象；各RNC无线侧各项指标横向对比正常；l 系统间重选的RRC建立次数和建立成功率成功率对比各RNC的系统间重选RRC建立成功率。RNC9在99.70%以上，可见如果终端能够在收到PAGING消息后正常地发起RRC链接请求，RRC建立成功的概率是非常高的；l 系统间重选的参数核查，保持适当的GAP经过TD->GSM、GSM->TD的重选参数值对比核查。发现RNC9的TD、GSM的重选参数绝大多数是设置正常的，保持着合适的GAP值，可以排除参数设置上导致终端发生频繁异系统重选的情况；l 覆盖分析从RRC链接建立

6、请求终端上报的PCCPCH_RSCP覆盖情况及路测情况两个维度进行覆盖分析评估。RNC9的RRC建立时PCCPCH_RSCP覆盖情况由于其他寻呼成功率正常的RNC、分析对比各RNC的拉网数据也发现，PCCPCH_RSCP覆盖电平统计上，RNC9的覆盖情况对比其他RNC也是稍高一点的；l 干扰分析横向对比各RNC的TS1/TS2 ISCP及UPPCH ISCP情况，RNC9的TS1/TS2 ISCP情况对比其他RNC正常。UPPCH ISCP情况，RNC8比其他RNC偏高一些。但RNC8的周平均寻呼成功率是90%左右，而RNC9的周平均寻呼成功率为74.02%，但RNC9的UPPCH ISCP情

7、况于其他RNC一样。因此UPPCH ISCP与寻呼成功率偏低也无正向关系； 详见插件报告： <二>寻呼无响应TOP用户、TOP终端分析统计发现，每天的TOP用户对寻呼成功率影响很大，而观察一周，TOP终端比较明显，利用PCHR和亚信平台进行深入发现以下特征：Ø TOP用户对寻呼成功率影响很大，剔除TOP20用户，寻呼成功率可达92%以上，与其他RNC相当；Ø TOP终端相对固定，一周寻呼失败较多的终端集中在10款终端，TOP10终端失败占比达到79.2%；Ø TOP用户不重复但集中在两个号段，TOP终端集中在几个终端，每个IMSI持续失败约9个小时且全

8、部失败、寻呼无响应的用户只有注册、短信、部分有彩信业务，失败集中在482、40482、50482小区 通过以上特征，最终发现在某营业厅销售的SIM卡即为问题IMSI卡，售卡点在开卡时候会用“TOP终端”进行测试验证，然后将手机卡拔出。核心网对这些终端发4-5条温馨短信或彩信，导致大量失败。1.TOP用户是影响寻呼成功率的主要原因TOP用户对寻呼成功率影响很大，观察TOP用户的影响如下：时间寻呼尝试次数寻呼失败次数寻呼成功率TOP10 IMSI失败次数剔除TOP10后寻呼成功率TOP20 IMSI失败次数剔除TOP20后寻呼成功率每日活动用户数8月1720294413579.62%103784.

9、73%129385.99%22608月1819945330383.44%62086.55%91688.03%22278月1918872195489.65%41091.82%58292.73%22608月2018367281484.68%58887.88%89689.56%22258月21287321155659.78%309570.55%550678.94%23278月2226294924064.86%290375.90%453182.09%24048月2320890378281.90%142188.70%182290.62%23688月2420891404780.63%210390.69%2

10、53292.75%2296一周的未寻呼到的TOP 20 IMSI如下：寻呼无响应 IMSI出现次数IMEI终端类型46002757271323167486803000460027682212610366868030004600276822129243598680300046002657250602935486019400华为 HUAWEI T5524600265721028933528616850046002657250602732586019400华为 HUAWEI T55246002268271627032386019400华为 HUAWEI T55246002657210101

11、231786291300TD30T46002768221218330586019400华为 HUAWEI T5524600276822129133048680300046002768221328430486291300TD30T46002768221218229386019400华为 HUAWEI T55246002768221240629286007600中兴通讯 ZTE-T U8624600276822126112928680300046002768221217829246002657201179729186019400华为 HUAWEI T552460027682212177286860

12、19400华为 HUAWEI T55246002768221218028586019400华为 HUAWEI T55246002657250603128586019400华为 HUAWEI T55246002768221217928186019400华为 HUAWEI T552从以上数据可以看出，RNC9每日活动用户数约2300左右，影响寻呼成功率的集中在TOP10或TOP20 用户，并非全LAC下的所有用户的寻呼成功率都较低。同时RNC9寻呼成功率不稳定，也反映TOP用户对寻呼成功率的影响。2.TOP终端分析TOP1O终端失败占总失败达到79.02%一周出现过的寻呼无响应的终端IMEI-TA

13、C共有138款，其中寻呼失败次数大于100次的有2 6款，整体的数据如下:被叫IMEI寻呼无响应次数终端类型860194008087华为 HUAWEI T552868030005223862913004001TD30T861685003232860471001903860076001337中兴通讯 ZTE-T U8628603000098235958803668GT-S3931C35637501534T5668603180048886045700325860296003043592300328886014000268SAMSUNG GT-S5630C35920203240GT-C3730C86

14、014300236SAMSUNG GT-S3930C86020600212HS-N5186016900172T260351510041656788i35854103163ZTE-T U60086103495140TB20035901803140U11135615501133T59086015200107LG GD300s86010600105中兴通讯 ZTE-T U21086022400101HUAWEI T2211TOP 10终端的寻呼无响应次数为26455次，全部无响应次数为33479次，占全网寻呼无响应的79.02%3.TOP终端、TOP用户失败特征TOP用户不重复但集中在两个号段，TO

15、P终端集中在几个终端，每个IMSI持续失败约9个小时且全部失败、寻呼无响应的用户只有注册、短信、部分有彩信业务，失败集中在482、40482、50482小区在找到寻呼失败的主要原因为TOP用户、TOP终端后，对TOP用户和终端做深入的分析。分析时间每天的TOP 10 IMSI只有1个IMSI重复出现，TOP10用户存在不稳定性。但集中在46002768、46002657号段；利用亚信平台对TOP IMSI和TOP终端做深入分析发现，TOP终端基本集中在某几个终端，譬如以下为一周TOP IMSI的数据，IMEI为的终端被96个ISMI使用，IMEI为的终端被31个IMSI使用。被叫IMSIIMS

16、I-出现次数IMEIIMEI全IMEI次数4600275727132316748680300096460027682212610366868030009646002768221292435986803000964600265721004663588680300096460026572506029354860194003146002657250602732586019400314600276822121833058601940031从PCHR基于IMSI过滤的结果来看，寻呼无响应的用户只有注册、短信、部分有彩信业务，这部分业务均发生在482、40482、50482小区， IMSI一般只出现一天（

17、或者是从从下午到第二天的凌晨），并且所有的IMSI都没有CS业务，当天的寻呼全部失败，持续失败9个小时左右；追踪TOP用户寻呼不到该用户，利用亚信平台信令分析， TOP用户的开卡时间和寻呼失败开始时间对应，在沙丁铁扣行站点（482、40482、50482小区）覆盖区域两个移动营业厅大拇指通信和伟跃通信发现问题终端。综上分析，移动售卡点，在进行试卡操作后，移动平台会下发4-5条温馨短信或彩信，由于工作人员在试卡后非正常关机而是采取直接拔卡的操作，核心网寻呼不到这些IMSI且不停的下发，导致大量的寻呼失败。<三>核心网寻呼策略分析从对TOP用户和TOP终端的分析，定位到寻呼成功率低现象

18、表现为开卡后不停的对“拨卡”的IMSI进行寻呼，导致大量的寻呼失败。当前诺西寻呼策略，不进行全局寻呼，只在寻呼过程中在VLR中查找用户的LAC信息，下发寻呼。根据交换阐述的TD LAC的寻呼机制，如果用户不在服务区，那么整个的寻呼过程为TMSI-TMSI-IMSI-IMSI，中间都间隔是4.8秒，其中前两次TMSI向同一个LAC下发寻呼，第三次IMSI寻呼下发前重新到VLR中查找用户位置信息，更新后下发寻呼。交换机内部模块等待寻呼响应的时间湖州设置为19S，当4次寻呼在该时间内寻呼完成且未寻呼到用户，核心网将认为该用户不在服务区，HLR上会有不可及标志位，核心网将不会继续寻呼；但由于湖州网络设

19、置，4次寻呼的时长超过19s (4.8*4=19.2),HLR 出0x603（交换机内配合的程序块无响应），核心网将继续对这些用户进行寻呼。直到核心网进行位置更新；核心网侧位置更新后，会将手机置为关机状态，这时候就不寻呼了。查询湖州区域的核心网设置的位置更新时间为12小时，所以会导致开卡试机之后，开卡IMSI在很长时间内连续的寻呼失败，在核心网进行位置更新之后，寻呼失败才会消失。三、问题定位及解决通过对寻呼策略和TOP用户的分析，湖州TD RNC9寻呼成功率低问题，外因主要由于用户非正常操作行为，售卡点在“试卡”后没有正常关机，而是进行“拔卡”操作；内因为核心网的寻呼策略不当，交换机在等待寻呼

20、响应时间19秒内不能将不在服务区内的IMSI置为“不可及标志”，停止寻呼。而是要等到核心网位置更新后（位置区更新定时器12H ）停止寻呼，导致大量寻呼失败。基于以上原因，解决建议为：1将开卡手机网络模式选到GSM网络，GSM每次寻呼间隔为3S，会在19S内置该IMSI为“不可及标志”,一次寻呼失败后停止进行寻呼；2.将TD每次寻呼间隔由4.8 S调整到4.5S，这样在19S内寻呼不到某IMSI，核心网将置该IMSI为“不可及标志”,一次寻呼失败后停止寻呼；通过以上处理，指标正常，最近一周RNC9寻呼成功率均值为96%四、后续建议1目前.织里地区LAC较多：共有4个G网LAC和1个TDLAC，在

21、不大的镇区范围内有5个LAC， 势必造成很多的位置区更新用户寻呼不可及的机率较大。2而当前诺西寻呼策略，不进行全局寻呼，只在寻呼过程中在VLR中查找用户的LAC信息，下发寻呼。根据交换阐述的TDLAC的寻呼机制，如果用户不在服务区，那么整个的寻呼过程为TMSI-TMSI-IMSI-IMSI，中间都间隔是4.5秒，其中前两次TMSI向同一个LAC下发寻呼，第三次IMSI寻呼下发前重新到VLR中查找用户位置信息，更新后下发寻呼。这种寻呼策略看似进行了4次寻呼，由于中间只在第三次的IMSI寻呼前查找用户位置信息，如果寻呼时用户进行了位置区更新，那么第二次的TMSI寻呼和第四次的IMSI寻呼意义不大，效率较低，既寻呼不到用户又增加了用户等待时延。3.诺西的寻呼机制每次的寻呼间隔只能设置为相同的值，不能针对性的个性调整，寻呼效率也到影响。合理T网LAC寻呼策略可以设置为：TMSI (等待7秒)IMSI(等待5秒) IMSI，共寻呼三次，每次寻呼都重新在VLR中获取用户当前的位置区信息，时间间隔可以根据T网到G网的重选时延调节。诺西承诺在下