未接通事件处理专题

1、本文档为精品文档，如对你有帮助请下载支持，如有问题请及时沟通，谢谢支持! 泉州分公司针对未接通事件专项整治的报告 一、概述： 在省公司下发最近几次的第三方话音业务DT测试结果中，我司的接通率指 标出现了较为明显的波动，同时在我司自行安排的摸底DT路测中也出现了多次 遇到未接通事件，接通率指标比较不理想，如何解决未接通问题成为摆在我司 网优人员的一个重要难题。因此为了有效改善接通率指标，同时提升用户满意 度，我司高度重视，专门组织人员针对未接通事件进行了详细分析及优化，并 针对每次的未接通案例进行研究，总结了未接通的原因和相应的解决方法。现 将这阶段针对未接通事件专项整治工作总结如下： 二、未接

2、通事件的分析： 认真分析了 10月和11月路测过程中出现的27个未接通（包括呼叫失败） 事件的原始路测文件，得出了导致每个事件的原因。这些路测主要集中在泉州 市区、晋江以及机场路。如下表所示： 原因 次数 所占比例 1 被叫位置更新 10 37.0% 2 ；质里差/过覆盖/覆盖弱 5 18.5% 3 TCH拥塞 5 18.5% 4 硬件故障 2 7.4% 5 Paging Delete （10 月 16 日 LAC22981） 2 7.4% 6 被叫频繁的小区重选 1 3.7% 7 :呼叫重建不成功 1 3.7% 8 上行干扰 1 3.7% 合计 27 100% 以下为每一类型事件的原因以及解

3、决它们的方法: 35 1、被叫位置更新： 路测中由于被叫做位置更新导致未接通是一个主要问题。从上表统计中 看，所遇到的 27 个事件中有 10 个是由于被叫做位置更新引起的，占所有事件 中的 37% 。 事件描述如下： 当主叫发起呼叫时，被叫正跨 LAC 边界并进行位置更新。在此期间寻呼将 会失败，因为被叫尚未完成位置更新，对被叫的寻呼消息会被发往原来的 LAC,二次寻呼也仍然不会成功，因为此时的二次寻呼还是在原来的LAC里发 送。 从下面的层三信令看,可以看出 MS1 完成信令到 “Call Proceeding ”,但 是在BTS成功地发送寻呼信息给 MS2之前，MS2进行了位置更新。 二

4、次寻呼 以及后续的寻呼都将会失败,因为 MS2 现在处于一个新的 LAC。 解决方法 1:FEAT 93858 使用NOKIA NSS的FEAT 93858功能，这会解决 MSC内的LAC边界由于 被叫位置更新导致未接通的问题。这个功能是一种寻呼机制,可以提高二次寻 呼手机时的成功率。当主叫呼叫被叫,而被叫恰好在做位置更新,第一次寻呼 将会失败，因为此时网络不知道被叫位置更新到哪里。位置更新处理需要2S时 间，在2S之后，被叫位置更新已完成。MSC在第一次寻呼失败后，间隔 3S后 做第二次寻呼。在开启 FEAT93858功能的情况下，第一寻呼失败后，MSC将在 二次寻呼前从 VLR中寻找目前手

5、机的当前位置信息，然后在新LAC下寻呼被叫 并取得成功，而未开启 FEAT93858功能时的二次寻呼仍然在原来的LAC下进行 将导致未接通。此功能可以有效改善同一MSC下LAC边界由于被叫位置更新导 致未接通的问题，但对于在不同MSC下LAC边界，这个功能对改进呼叫成功率 没有任何帮助。 为了验证这个功能,我们进行了模拟测试,测试方法如下： 1）将MS和路测设备处于Intra-MSC边界小区的覆盖范围内（比如说在 LAC-A） 。 2）使用MS2锁频于相邻LAC （比如说LAC-B）下某一小区的 BCCH频点 3）改变所锁频点，让 MS2处于LAC-A下的一个小区。 4）立即用MS1拨打MS2

6、。 5）观察信令看呼叫是否成功 6）在Inter-MSC边界使用上述同样的方法。 Intra-MSC测试结果： MS1正在呼叫MS2，但MS2正在做LAU和RAU，没有时间监听进来的寻 呼，只能监听使用IMSI的二次寻呼，并且能够响应寻呼应答此次呼叫。 事件过程： MN UalILndNW minted call related SS messages Message typ&: 37 无信道可用 Codhg standard : Standard defined For the GSM PLMNS Location: 2 public network serving the local ue

7、r volue : (34) No circuit/channel aviloble1 dumpHex: 03 25 02 e2 a? 朋2 rim： 19:32:16 96 blocked Call Block type: Nq Alerting or Connect 解决方法: 解决此种问题最好就是增加 TCH 信道 ,这可以通过 TRX 扩容或者增加半速 率。 4、硬件故障 在 27 个事件中，其中有 2 个是由于硬件故障造成的，这两个未接通都是发 生在小区 8082 。 事件描述如下： 从三层信令上看 , MS1 发送 “CM Service Request ”之后, BTS 没有响应

8、， 最后 T200 计时器超时导致未接通。从 测量报告可以看出信号强度和质量都非 常好 (RxLev= -55dBm, RxQual =0) 。 这应该是一个 SD 掉话。 查看故障小区列表 , 小区 8082 有 7949 告警 (DIFFERENCE IN RX LEVELS OF MAIN AND DIVERSITY ANTENNA / TRX) ， KPI 指标显示此小区 SDCCH 掉话率非常高 (47%), 800 掉话率 3.2% ， TCH Assignment Blocking Rate 是 15%. 解决方法： 小区 8082 是 Com mon BCCH 小区，主 BTS

9、 是 Talk-Family 站，EGSM BTS是Ultra-Site 站型。在将所有的 BTS都换成Ultra-site 站型后，小区的各项 KPI指标都返回到正常水平。 下图硬件替换后KPI指标: 5、Paging Delete 在27个事件中，其中有 2个是由于paging delete 命令造成的。 事件描述如下： LAC 22981在原来调整割接前每天 17: 00的时候有较多的 paging delete 情况，当有paging delete 命令发送时，从BTS到MTC的寻呼会被删除，这将 会导致路测时的未接通。 泉州的寻呼模型很不一样，寻呼量高峰期并不在话务最忙时，而Netw

10、ork Doctor 222报告只反映了话务忙时的寻呼负载情况，不能反映寻呼高峰时的情 况，为了找出问题，直接使用SQL脚本直接从OMC上取得数据。下表显示出 LAC22981每小时寻呼状况，寻呼高峰是在在17 : 00， MTC和MOC呼叫也最 多（注:17 : 00的寻呼信息与其它时间最大不同是重呼的次多，因为paging deletes 发生） LAC22981 Time MOC MTC Total Call (MTC+MOC) Pagi ng MSG Deleted Pagi ng MSG Traffic 10.16.06 12:00 AM 61901 23685 85586 5542

11、6 0 1617.89 10.16.06 1:00 AM 42532 11430 53962 24874 0 800.23 10.16.06 2:00 AM 32148 6362 38510 12902 0 392.85 10.16.06 3:00 AM 27279 3847 31126 7206 0 213.95 10.16.06 4:00 AM 24330 2684 27014 4629 0 138.11 10.16.06 5:00 AM 25898 2869 28767 4742 0 125.58 10.16.06 6:00 AM 32296 7432 39728 11169 0 230

12、.51 10.16.06 7:00 AM 48800 20288 69088 29312 0 577.23 10.16.06 8:00 AM 78700 50731 129431 66791 0 1394.23 10.16.06 9:00 AM 102501 74850 177351 103562 0 2132.46 10.16.06 10:00 AM 112076 80854 192930 112313 6 2408.31 10.16.06 11:00 AM 115943 81120 197063 110425 0 2411.94 10.16.06 12:00 PM 111885 65163

13、 177048 99375 0 2475.47 10.16.06 1:00 PM 80327 43182 123509 68755 0 1606.71 10.16.06 2:00 PM 93871 60540 154411 91780 0 1882.16 10.16.06 3:00 PM 110500 77774 188274 111065 0 2303.08 10.16.06 4:00 PM 124831 87101 211932 114642 0 2535.35 10.16.06 5:00 PM 127058 98797 225855 208812 30624 2841.81 10.16.

14、06 6:00 PM 124965 97002 221967 138664 5 2983.81 10.16.06 7:00 PM 112128 82092 194220 128463 23 2993.25 10.16.06 8:00 PM 98784 71233 170017 116993 4 2802.83 10.16.06 9:00 PM 101866 71401 173267 119576 0 3127.50 10.16.06 10:00 PM 91463 59905 151368 121912 2 3159.27 10.16.06 11:00 PM 70157 40557 110714

15、 96674 0 2608.11 10.17.06 12:00 AM 43403 22844 66247 52649 0 1593.48 由于paging delete 命令导致的2个未接通恰好是在10月26日的 LAC22981, 个在 17 : 05，另外一个在 17 : 31。 从三层信令上分析，主叫发起呼叫后，根本就没有被叫的寻呼响应。看主叫 和被叫所占用的小区，他们都在同一个小区(在下例中是小区11043)。从主叫 的测量报告，可以可看出信号强度很好(-78dBm)，质量也很好(RxQual = 0)。因而可以判断出被叫的信号场强和质量也很好。 后来查看统计报告，发现LAC 2298

16、1在17 : 00到18 : 00这段时间里有非 常多的paging delete 命令。下表显示了 paging delete 命令的数量(30624次 删除). LAC22981 Date Pag ing MSG Deleted Pagi ng MSG 10.11.06 5:00 PM 201878 33126 10.12.06 5:00 PM 170159 18186 10.13.06 5:00 PM 213826 32819 10.14.06 5:00 PM 156329 9982 10.15.06 5:00 PM 174527 20522 10.16.06 5:00 PM 20881

17、2 130624 1 10.17.06 5:00 PM 187050 25168 检查小区11043的KPI指标正常，没有上行干扰，sd掉话率和tch掉话率 都在正常水平。从这断定未接通是由于Pagi ng Delete命令造成的。 解决方法： 作了一些调整减少了 paging delete 命令，大多数 BTS的参数AG (NumberOfBIocksForAccessGrant)设为4，这种设置使得多数资源被AG信道 占用，以往的经验，AG参数设为2或者1就已经够用。 对于 Non-Combi ned Con trol Chann el, Number of Pagi ng Group =

18、 (9-AG) x MFR 对于 Combi ned Con trol Chann el, Number of Pagi ng Group = (3-AG) x MFR Pag ing Buffer Size = free buffers (max 8) x Number of Pagi ng Group. 将参数AG的值调的低一些，更多的寻呼信道被分配，寻呼容量也就更 大，在11月27日还将一些基站从 LAC22981和LAC22869调整到 LAC22984。 经过这些调整之后，11月27日LAC22981在17 : 00的paging信息减少 到130,000左右，而paging del

19、ete 也减少到300左右。AGCH缓冲也没有溢 出情况 Date Pag ing MSG Deleted Pagi ng MSG 10.11.2006 17:00 201878 33126； 10.12.2006 17:00 170159 18186 10.13.06 5:00 PM 213826 32819 10.14.06 5:00 PM 156329 9982 10.15.06 5:00 PM 174527 20522： 10.16.06 5:00 PM 208812 30624 1 10.17.06 5:00 PM 187050 25168 11.24.06 5:00 PM 1381

20、84 773： 11.25.06 5:00 PM 140768 2430： 11.26.06 5:00 PM 134439 96 11.27.06 5:00 PM 131982 312 11.28.06 5:00 PM 68195 0 11.29.06 5:00 PM 66755 0 11.30.06 5:00 PM 70564 0 LAC 22981 L BTS割接 AG调整 在11月28日寻呼高峰时段（例如17 : 00到18 : 00）进行了路测，没有因 为paging delete 命令导致未接通，呼叫304,失败了 2次，是由于被叫位置更 新和TCH拥塞造成的。 6、被叫频繁的小区重

21、选 27 个事件中有 1 个是由于被叫频繁的小区重选导致。 事件描述如下： 当MS1拨打MS2, MS2先占用小区13543，然后又重选到小区 8641 , MS1在13541上发起呼叫之后切换到小区 8641。此次未接通，因为在 MS1拨 打MS2时，MS2正在小区重选并解读邻小区BCCH和BSIC码，因而不会监听网 络的寻呼。在 MS1呼叫MS2时，信令上看没有寻呼请求信息，呼叫失败MS1 听到网络的提示信息“ 对不起,您拨打的电话暂时无法接通 ,请稍后再拨 ”， 频繁 的小区重选可能是由于在解读和同步主服务小区的 BCCH 时质量太差所致。 事件过程： 1) MS1 拨打 MS2 2)

22、MS2 没有监听网络的寻呼信息 3) MS1呼叫建立失败(MS1会听得来自MSC提示“对不起，您拨打的电话 暂时无法接通 ”) 4) 在MS1拨打MS2时，MS2正在小区重选。 5) 未接通 MS1 不能连接 MS2 详细的三层信令分析： MS1 RR Channel Request MS1 _ Cll Attempt MSI MS1呼叫MS2 MSI MS2 MS1 MS1 MS1 MS1 MS1 MS1 MS1 MS2 MS1 MS1 MS1 MSI MS1 MS1 MS1 MS1 MS1 MS1 MS2 MS1 MSI MS1 MS1 MS1 MSI 怦I RR RR RR RR RR

23、RR RR MM RR RR RR RR MM CC RR RR CC RR RR RR RR FIR RR RR RR RR RR i-ii-s Paging Request Type 1 Paging Request Type 1 System Infoirmation Tjipe 4 Paging Request Tpe 2 Paging Request Type 1 Paging Request Type 1 I mmediate Assignment 匚hl Service Request 匚lassmark Change GPRS Su&penion Re口uest Sy stem

24、 InformaTion Type 2ter System Information Type 6 CM Service Accept Setup Measurement Report System Infcrmation Type 5 ter Call Hocmmdin口 Msasurenient Report System InFotmation Type 6 Aiigriment Command Asigriment Lompleh Cell Reselectirm Svstem Informalion Tvpe B Measurerment Report Svtem Informatio

25、n Type 5 Measurement Report System Information Type 6 Measurenient Report nygimm inrormaitin i ype b Measuement Report Ml 对 MS1 的 Call proceeding, MS2应该被寻呼 MS2进行第一次重选 MS1 MSI MSI MSI MSI MSI MSI MSI MS1 MSI MS1 MS1 MSI MS1 MS1 MSI MSI MSI MSI MSI MSI MSI MSI MSI MSI MS1 MS1 MS1 M52 MSI MSI MSI MSI M

26、S2 RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR RR System Information Type 5 ter Measuiement Report Synch Channel InFormation System Information Type 6 Measuremenl Report Handover 匚ommand Handover Access Physical I nfoimotion HMchver Complete Handover Physical I nfoimaAion Sy

27、stem Infornnation Type 6 Measurement Report System Inforrmion Type 5 Measurement Report System Information T)jpe G Measurement Report System Information Type 5 Measuemenl Report System Information Type 6 Measutemerit Report System Infoinnation Type 5 怕r Measurement Report Synch Channel Information S

28、ystem Information Type 6 Measurement Report Synch Channel Information System Information Type 5 Syndi Channel Inhnriation Measurement Report System InJormatiari Tpe 6 Measurement Report Synch Channel Infaroiaition System Infornnation Tvoe 3 MS2监听寻呼 信息，因为它 正在解读和同 步主服务小区 的BCCH和 BSIC 结论: MS1 RR Measure

29、ment Report MS1 & Snch Channel Information MS2 & S网em InformaAian Type 3 MSI & Handover Commard MSI t Handover Access MSI & Physical Information MSI t Handover Complete MSI 占 Handover MS1 RR 4- Physical I riformatiori MS2 RR 令怕m InJoimotion Type 2te( MS1 RR t Measurement Report MS1 RR O System Infor

30、mation Typ& 5 MS1 RR 會 Measuement Report MS1 RR # Measuement Report MS1 RR & Synch Channel Infoimation MSI RR & System InformaAion Tpe 5 ter MSI RR t Measurement Report MSI RR 2 Synch Channel Infonriaition MSI RR 罟 System Infornnation Type 6 MS1 RR t Measutement Report MS1 RR O Synch Channel Informa

31、tion MS1 RR O Svsem Infoimathn Type 5 MS1 RR t Measurement Report MS1 RR t Measurement Report MS1 RR t Measuiement Report MS1 RR & System Informatian Tpe 6J MSI RR t Measurement Report MS2 RR & Synch Channel Information MS2 MSI RR 4 System Information Type 5 ter MSI CC Alertha MS1 Call Setup MS1 Il

32、b H H uwn v RR RR t Measuremenl Repoit_ 令 Synch Channei iriforniion* MS 2 MS 2 MS1 MS 2 MS 2 MSI MS1 MS2 MSI MSI MS1 MSI MS1 M51 MS1 HR RFI RR RFt RR RR RR RR RR RR RR RR RR FIR RFt RR T 4 县 丹 t Faging FC已qu釧 Typ&l System Infer nriation Type 3 Measurement Repod Paging Request Type 1 Paging Re quasi

33、Typ色 1 System Information Type 3 Blocked 3 Paging Flequ System Information Type 21 er Gystfiffi IhfoirriaticH 3 System Information Type 4 System Infoimalion Type 1 System InfoimsDn Ty的 2 Paging Request Type 1 Pagirifl Request 2 System Info nation Type 13 Channel R equest MS2仍然不能监 听寻呼信息 MS2第二次小区重选 MS

34、1收到不能接通被叫 的提示 呼叫不能建立，作为呼 叫失败记录 经过分析，频繁的小区重选是因为在那片区域没有主控小区，调整了小区 13543和8641的天线加强了这一路段主控 7、呼叫重建失败 27个事件中，有1个是由于呼叫重建失败。 事件描述如下： MOC 信号强度弱或者质量差造成无线链路超时而掉话，因为打开了 RE (Call Re-establishment), MOC 试图重新建立呼叫，发送 “Channel Request ” 之后再发送 “CM Re-establishment Request”。根据三方测试规范的定义 , 这被 认为是一个呼叫尝试，实际上 “Channel Requ

35、est ”之后再发送 “CM Service Request ”的才是一个呼叫尝试，因而，呼叫重建失败很容易和正常的呼叫尝试 混淆。如果重建失败，BTS发送 CM Service Reject ”信息给MS,就像下图所 示那样： 解决方法 : 在这个案例中呼叫失败和掉话的主要原因是弱覆盖和无主控小区，在 SITE1107 增开了一个扇区后，此路段的场强和质量得到很大改善。 下图是调整之后得情况： 8、上行干扰 27 个事件中，有 1 个是由于呼叫上行干扰所致。 事件描述如下： MOC 发送了 3 条 Channel Request ”(RACH)信息给 BTS，但是 BTS 没有 任何响应 。

36、这意味着 MOC 没有 “CM Service Request ”信息，根据三方测试规 范，这个不被认为是未接通，因为缺乏 “CM Service Request ”信令。但是， 这个问题也是需要解决，因为如果发生在 MTC 而不是在 MOC， 那就算是一个 未接通。 MOC在小区18092上起呼，MOC发送的第一条 Channel Request ”信息 没有得到 BTS 的响应，因为此小区的参数 RET (Maximum Number of Retransmission) 设为 2, 手机最多重发 2 次 “Channel Request ”信息 ，然 而，网络仍然没有响应，直到 T312

37、6 计时器超时。 对此有三个普遍原因 : 1) BTS 由于受到上行干扰根本就没有收到“Channel Request ”信息 2) BTS 收到 “Channel Request ”信息，但是 AGCH buffer 已满而不能响应 寻呼 3) BTS 响应了 “Channel Request ”信息并且发送了 “Immediate Assignment ”命令，但是手机由于下行干扰没有收到 小区 18092 的下行接受电平 -64dBm ，非常的强，应该不会有下行质量问 题。 查看KPI,不像有下行干扰，因为该小区的下行质量非常好，全天平均为 99.4% 查看 Network Doctor

38、 s 202 报告 , 这个小区也没有 delete indication (Immediate Assignment or Immediate Rejected message)信息。 查看 Network Doctor s 190 报告, 发现这个小区在 11 月 7 日 15：00 时有 非常强的上行干扰，刚好与路测时段吻合， 上行干扰的 out of band 1 为 36%。 鉴于此，可以推断信息的丢失是由于上行干扰所致。 解决方法： 需要查找干扰源，发现外部干扰在11月9日后突然消失了， 因此认为是突 发的干扰源所致。 三、结论 通过上述的分析和相应的优化工作，最近的路面测试中也获

39、得了较好的效 果,最后一轮测试全部6条路线的呼叫成功率达到98.81%。 试呼次数 呼叫失败次数 接通率| 1st Time All Route (1-6) 397 9 97.73 2nd Time All Route (1-6) 420 6 98.57 3rd Time All Route (1-6) 436 10 97.71 4th Time All Route (1-6) 451 8 P 98.231 5th Time All Route (1-6) 419 5 98.81 每条路线的测试结果如下表 地市 话音DT 接通率 试呼次数 呼叫失败次数 优秀值 98.00% 泉州（测试路线1）