GSM掉话案例集锦 - 图文

GSM掉话案例集锦

内部公开▲

目 录

案例1：上行干扰引起的高掉话 ........................................................................... 3 案例2：载频故障引起的高掉话 ........................................................................... 4 案例3：载频与合路器连线问题导致高掉话 ....................................................... 4 案例4：外部干扰导致高掉话 ............................................................................... 5 案例5：利用TRX基本测量处理AFRIPA站点高掉话问题 ............................. 5 案例6：频点及邻区规划不合理导致掉话 ........................................................... 9 案例7：LAPD PCM时隙故障导致高掉话 ........................................................ 11 案例8：载频隐性故障导致高掉话 ..................................................................... 11 案例9：载频故障引起高掉话 ............................................................................. 11 案例10：网外干扰导致高掉话 ........................................................................... 12 案例11：上行干扰导致高掉话 ........................................................................... 14 案例12：切换不及时导致掉话 ........................................................................... 15 案例13：交换侧问题引起异常掉话 ................................................................... 15 案例14：上下行不平衡造成切换掉话过多 ....................................................... 16 案例15：O&M intervention （O&M干预）掉话 ...................................... 17 案例16：天馈问题导致掉话严重 ....................................................................... 17 案例17：覆盖问题导致单通甚至掉话 ............................................................... 18 案例18：某小区合路器隐性故障忙时掉话几十次 ........................................... 19 案例19：交换侧定时器T305和T308对掉话统计的影响 ........................... 19 案例20：后备板遭雷击损坏导致高掉话 ........................................................... 22 案例21：处理LAPD掉话问题 .......................................................................... 22 案例22：载频指派优先级降低掉话 ................................................................... 24 案例23：接成小鸳鸯线引起高掉话 ................................................................... 25 案例24：MAIO设置不当引起掉话突增 ........................................................... 28 案例25：切换原因导致的掉话 ........................................................................... 28 案例26：天馈及塔放问题造成通话有金属声及掉话 ....................................... 28 案例27：Abis信令跟踪发现引起掉话的隐性问题 .......................................... 31 案例28：天线问题造成高掉话 ........................................................................... 32 案例29：直放站干扰引起高掉话 ....................................................................... 33 案例30：某小区合路器隐性故障导致忙时掉话几十次 ................................... 35 案例31：重叠覆盖深，全网忙时掉话300次左右 ......................................... 36 案例32：创建BTS测量任务快速判断掉话原因 ............................................. 36 案例33：载频温度过高导致掉话 ....................................................................... 37 案例34：切换不及时导致掉话 ........................................................................... 37 案例35：载频故障导致掉话突然增多 ............................................................... 39 案例36：黑龙江绥化移动GSM网络掉话率持续较高 .................................... 41 案例37：阿尔及利亚ATM网络由于传输的异常掉话 ..................................... 41 案例38：直放站的同频干扰导致高掉话 ........................................................... 41 案例39：对直放站功能应用不当造成掉话 ....................................................... 41 案例40：某天线接反导致掉话 ........................................................................... 42 案例41：时钟故障引起掉话 ............................................................................... 43 案例42：数据删减添加后，MAIO未作修改，导致掉话 ............................... 45

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 2/45

内部公开▲

案例1：上行干扰引起的高掉话

现象描述： 卡拉奇 城区部分小区掉话严重，用户大量在这些小区有的时候通话质量很好，有的时候通话质量非常差，时常出现突然掉话的现象。

现象分析：问题出现后，对这些小区进一周24小时的测量报告，性能指标进行了分析。发现这些小区掉话存在一个共同的规律，那就是一天之内在某个时段上掉话的次数非常高，而其它时段掉话并不高，同时这些小区绝大部分掉话是无线链路掉话。而且每天掉话高峰时段也不尽相同。并根据数学分析软件mintab得到掉话率和4、5级干扰比率之间的关系，如下： Fitted Line PlotCall-Drop-Rate2 = 1.182 + 11.66 Interference26SR-SqR-Sq(adj)0.34159391.0?.7\all-Drop-Rate243210.000.050.100.150.20Interference20.250.300.35 通过此关系，我们得知干扰的确是造成掉话的直接原因

解决方法及验证：通过对测量报告中干扰带的分析，发现干扰严重情况和掉话高峰时段的变化趋势比较吻合。接下来对这些站点进行了连续几天的扫频测试，通过对扫频结果的分析找出外部干扰频段的范围。对受到干扰的小区频点进行相应的调整，使其尽量避免使用干扰带内的频点。并配合局方向巴基斯坦无委会提交报告，要求进行清频工作。调整完成后，对问题小区进行了详细的路测和拨打测试。同时也及时地和用户进行联系反馈调整后的情况。从性能报表和测试的结果来看，频点调整后掉话次数明显减少很多。

经验总结：在网络优化中，如果碰到小区掉话次数过高，并且没有一个规律。在排除了硬件问题的前提下，那么引起掉话的原因很有可能是干扰所造成的。至于是由于频点干扰还是由于外部干扰导致的掉话较高，需要通过测试来确定。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 3/45

内部公开▲

案例2：载频故障引起的高掉话

现象描述：利比亚TRI298基站3小区突然出现掉话增多，切换成功率很低，指派失败率很高。

现象分析：从性能统计报表看该小区前几天各项指标都很好，因此怀疑是硬件故障或存在外部干扰，由于话务掉话比太低影响到该小区所属BSC的KPI达标，需立即处理

解决方法及验证：去基站现场发现该站3小区CDU告警（后台没有发现告警信息），于是更换了CDU，更换后进来了CQT测试，发现3小区有两块载频（该站为S444）当手机占用后TCH电平比BCCH电平低20～25dB,且不停地在波动，由于没有带备用TRX，临时将这两块载频与1小区的两块载频对调，然后测试发现手机占用3小区的这两块载频后电平与BCCH载频电平相差很小，而且电平也比较稳定，可以确定是TRX故障，次日再次去该站更换了这两块故障载频，从性能报表看各项指标正常。 经验总结：对于突然出现的高掉话的小区，首先查看告警信息，如果没有明细的告警再上站排查硬件，路测，CQT测试，通过这些手段基本可以定位问题，如果还不能定位，可以跟踪信令，创建问题小区的基本测量，分析基本测量数据，综合分析定位问题原因。 TCH Handover Cell and Location Data UserLabel Area Cell(LAC-CI) rate(%) number 3月10 TRI298-3 LAC8214-CI12983 14.59 3月13 TRI298-3 LAC8214-CI12983 91.25 290 7 rate(%) 51.7 1.48 7.11 90.77 success call total failure rate(%) rate(%) 75.73 91.69 48.29 98.51 3.49 139.06 dropped assign in success success rate(%) traffic TCH Handover out success rate of Handover Call Call drop 案例3：载频与合路器连线问题导致高掉话 现象描述：埃塞俄比亚GSM网络MEKELE城区某小区掉话严重。

现象分析：问题出现后，对这个小区（V1A，S666）进一周24小时的测量报告，性能指标进行了分析。发现这些小区掉话存在一个共同的规律，那就是凡是切换造成的占用TCH后，发生掉话的几率非常高，而初始呼叫占用到TCH的用户发生掉话的几率很小；

解决方法及验证： 通过对测量报告中干扰带的分析，发现基本正常。并对问题小区进行了详细的路测（对空中接口的层3信令分析来看，异常消息有3种，但这3种提示的原因差异很大，并不能得到有用的分析结果）和拨打测试。并修改该小区的BCCH工作频点，同时收集该区域本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 4/45

内部公开▲

用户投诉信息。从性能报表和测试的结果来看，频点调整后掉话次数无明显变化。后来在检查硬件时发现，该小区第5块载波与相应合路器的连接线没有连接导致；

经验总结：在网络优化中，要善于根据具体情况，综合检查各种可能的因素和计划并制定相应的测试任务，最后全方位的分析问题、确定问题的原因并给予解决。

案例4：外部干扰导致高掉话

现象描述：2005年冬天，福建福州福清市龙田区替换了ZTE的GSM网络设备，替换完后，掉话率较高，性能统计上看，这一时段上行干扰带较高，但是不是连续干扰，有的时段次数多，有的时段次数少；

现象分析：由于这些区域在相应时段都存在上行干扰带，现场路测时，下行质量和电平都正常，但是有时存在无法呼出现象，初步怀疑存在干扰源，由于福建福清市地处海边，主要怀疑是来自军队方面的干扰；

解决方法及验证：办事处同事与联通工作人员一同去该基站覆盖区域进行扫频测试，经测试发现的确有非连续的干扰存在，并且当他们到达此区域测试时有军方人员前来询问，已经确定此区域为军队通讯设施干扰造成此站点掉话率高。由于军方联通方面无法协调关闭干扰源，且整个900m频段都会造成干扰，所以，此站点指标局方也已知道情况，对考核时也表示去掉此站点指标。

经验总结：在出现掉话率高，在正常的工作时段，且伴随这很高的上行干扰带，则一般情况下是外部干扰的问题，需要观察附近可能的干扰源，尤其是银行、政府机关等重要部门；

案例5：利用TRX基本测量处理AFRIPA站点高掉话问题

现象描述：尼日尔Sahelcom 的一个站点Afripa（V2设备配置为S444）存在性能指标差的情况，主要表现为，Afripa_1和Afripa_2存在高掉话、高切换失败、高指配失败现象，Afripa_3小区指标正常，如下表：

TCH in call drop rate(exclude Time 2006-9-4 21:15 Site alias Afripa_bts1 handover)(%) 3.71 TCH dropped call total number 120 Handover success rate(%) 74.23 TCH assign failure rate(%) 13.34 Number of TCH/F Assignment Failure 490 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 5/45

内部公开▲

2006-9-5 21:15 2006-9-6 21:15 2006-9-4 21:15 2006-9-5 21:15 Afripa_bts1 Afripa_bts1 Afripa_bts2 Afripa_bts2 2.86 2.52 4.22 3.99 78 77 86 84 77.12 73.17 64.65 64.4 10.91 12.72 20.41 24.75 328 437 512 679 现象分析：由于存在很高的指配失败率（TCH assign failure rate(%)>10%），所以我们怀疑为硬件故障,从性能管理中提取了这两个小区的TRX基本测量数据，发现Afripa_1的TRX3、TRX4存在平均占用时间远少于TRX1和TRX2的情况，并且Afripa_2的TRX3、TRX4也存在此情况，如下表： Average 13001(Number SITE 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 CELL 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 TRX 1 1 1 2 2 2 3 3 3 4 4 4 1 1 1 2 2 2 Time 2006-8-24 20:00 2006-8-24 21:00 2006-8-24 22:00 2006-8-24 20:00 2006-8-24 21:00 2006-8-24 22:00 2006-8-24 20:00 2006-8-24 21:00 2006-8-24 22:00 2006-8-24 20:00 2006-8-24 21:00 2006-8-24 22:00 2006-8-24 20:00 2006-8-24 21:00 2006-8-24 22:00 2006-8-24 20:00 2006-8-24 21:00 2006-8-24 22:00 of TCH seize) 716 748 763 680 999 887 741 1347 1158 788 1422 1151 786 798 725 630 724 788 13002(Accumulative Time of TCH seize) 16187 17066 16628 13525 21969 17905 8370 15810 12680 8691 15025 12740 15811 16430 16489 12663 14695 17795 occupied time 22.61 22.82 21.79 19.89 21.99 20.19 11.30 11.74 10.95 11.03 10.57 11.07 20.12 20.59 22.74 20.10 20.30 22.58 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 6/45

内部公开▲

22 22 22 22 22 22 2 2 2 2 2 2 3 3 3 4 4 4 2006-8-24 20:00 2006-8-24 21:00 2006-8-24 22:00 2006-8-24 20:00 2006-8-24 21:00 2006-8-24 22:00 444 840 772 450 811 810 3778 6855 5920 4727 8077 8032 8.51 8.16 7.67 10.50 9.96 9.92 从上表可以看出，cell1 和cell 2各有两块载频存在平均占用时长小区其它载频的情况，鉴于一个站点同时出现4块载频故障的可能性不大，并查看LAPD测量和历史告警，没有发现与这四块载频故障相关的信息，初步排除TRX故障；

从集成配置管理中，查看了cell1和cell2的硬件配置情况，发现cell1的TRX3和TRX4是通过一个CDU合路后输出的，cell2的TRX3和TRX4也是通过一个CDU合路后输出的（同理，同时出现两块CDU故障的可能性也较小，排除CDU故障），即cell1和cell2的这两块载频都是共用一根馈线的，所以初步怀疑两小区为馈线接交叉了；

为了进一步验证馈线接交叉的结论，提取了这两个小区的邻区性能，发现有一个邻区yantala_2小区的掉话、切换和指配性能也不好，于是利用mapinfo工具检查了频率分配情况，发现afripa_2的两个TCH频点8和10与yantala_2小区为同频，并且TCH频点8和10刚好分配在TRX3和TRX4上，如下图：

上图所示，如果afripa_1和afripa_2有一根馈线接交叉的话，刚好能造成对yantala_2的同频（频点8和10）干扰，至此初步判断afripa_1和afripa_2小区馈线接交叉，即本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 7/45

内部公开▲

afripa_1右面发射TCH载频（TRX3、TRX4）和afripa_2右面发射TCH载频（TRX3、TRX4）馈线交叉。

解决方法及验证： 现场整改接交叉的这两根馈线（即在BTS机柜顶调整一下跳线），调整后通过后台性能统计观察，发现afripa_1和afripa_2性能情况恢复正常，如下表： 表 1 调整前后TRX基本测量性能数据对比

Average CELBSC SITE L X TRTime of TCH seize) Time of TCH seize) time 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 3 3 3 3 4 4 4 4 3 3 3 3 4 4 4 4 2006-8-14 21:00 2006-8-14 22:00 2006-9-11 21:00 2006-9-11 22:00 2006-8-14 21:00 2006-8-14 22:00 2006-9-11 21:00 2006-9-11 22:00 2006-8-14 21:00 2006-8-14 22:00 2006-9-11 21:00 2006-9-11 22:00 2006-8-14 21:00 2006-8-14 22:00 2006-9-11 21:00 2006-9-11 22:00 889 910 985 1060 905 872 989 1088 882 1110 662 934 907 1155 603 880 7253 7893 18973 23348 6945 8122 18933 22553 6871 8942 12432 17096 12139 15343 13347 17864 8.16 8.67 19.26 22.03 7.67 9.31 19.14 20.73 7.79 8.06 18.78 18.30 13.38 13.28 22.13 20.30 13001(Number 13002(Accumulative occupied 表 2调整前后性能指标数据对比

TCH in call drop SITE CELL Time Site alias rate(exclude handover)(êll total number success rate(%) failure Assignmerate(%) nt Failure TCH dropped Handover TCH assign Number of TCH/F 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 8/45

内部公开▲

) 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2006-9-4 21:15 2006-9-5 21:15 2006-9-6 21:15 2006-9-7 21:15 2006-9-8 21:15 2006-9-9 21:15 2006-9-10 21:15 2006-9-11 21:15 2006-9-4 21:15 2006-9-5 21:15 2006-9-6 21:15 2006-9-7 21:15 2006-9-8 21:15 2006-9-9 21:15 2006-9-10 21:15 2006-9-11 21:15 Afripa_bts1 Afripa_bts1 Afripa_bts1 Afripa_bts1 Afripa_bts1 Afripa_bts1 Afripa_bts1 Afripa_bts1 Afripa_bts2 Afripa_bts2 Afripa_bts2 Afripa_bts2 Afripa_bts2 Afripa_bts2 Afripa_bts2 Afripa_bts2 3.71 2.86 2.52 0.79 0.30 0.38 0.51 0.41 4.22 3.99 0.33 0.40 0.64 0.42 0.38 0.56 120 78 77 28 10 13 14 13 86 84 6 11 17 10 8 15 74.23 77.12 73.17 90.62 91.63 91.79 93.02 94.44 64.65 64.40 92.76 91.53 95.89 95.22 96.50 94.83 13.34 10.91 12.72 3.75 3.53 3.32 3.11 1.23 20.41 24.75 1.54 3.30 2.29 1.95 1.36 1.30 490 328 437 138 122 117 88 40 512 679 28 93 62 47 29 35 经验总结： BSC V2.8及其以后版本增加了对TRX的测量，利用该测量任务我们可以很方便的判断载频的隐形故障（以前我们可以通过闭塞载频或信令跟踪来判断），一般存在问题的载频的平均占用时长都要小于其它正常载频的占用时长，然后再根据掉话、切换及邻区性能情况并结合地理化软件（如mapinfo、wp等）进行频率干扰查询和邻区情况查询等来定位网络问题，而不需要到现场进行拨测和路测。

案例6：频点及邻区规划不合理导致掉话

现象描述：安徽网优提质巡检项目中，后台性能指标显示，无愁3小区（1个载频）业务信道掉话率偏高，导致坏小区比例过高。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 9/45

内部公开▲

现象分析：通过网优软件查看该小区的邻区和频率配置，发现无愁3的邻区和频率规划都不合理。无愁3与同站两小区无愁1、无愁2没有配邻区，邻区关系不完整；且与GEDU1（CI=45111）同频，导致干扰掉话。 解决方法及验证：

1）根据邻区规划原则，对无愁3的邻区做了适当调整，增减修改其邻区关系。 2）优化无愁3频点，将其频点从106调整至122。

在通过上述调整后，后台指标显示，该小区的业务信道掉话率明显降低，不再成为坏小区。 业务信道掉话率日期 别名 (含切换)(%) 2006-3-13 2006-3-14 2006-3-16 2006-3-17 2006-3-18 2006-3-19 2006-3-20 2006-3-21 2006-3-22 2006-3-23 无愁3 无愁3 无愁3 无愁3 无愁3 无愁3 无愁3 无愁3 无愁3 无愁3 7.01 1.36 6.52 2.38 7.27 6.57 0 1.78 5.2 4.25 线话务量 0.1786 0.142 0.2771 0.4027 0.4609 0.3293 0.5238 0.4885 0.3443 0.428 调整后 2006-3-24 2006-3-25 2006-3-26 2006-3-27 无愁3 无愁3 无愁3 无愁3 1.02 1.61 1.08 1.42 0.2323 0.1486 0.2325 0.1792 1 1 1 1 98 62 92 70 0 0 0 0 话总次数 4 1 6 2 8 5 0 2 5 4 次数(含切换) 57 73 92 84 110 76 120 112 96 94 数量 1 0 1 0 1 1 0 0 1 1 业务信道每业务信道掉业务信道占用总坏小区经验总结：频率规划，邻区规划不合理，常常是导致干扰掉话的罪魁祸首。在规划时，应尽量避免不合理的频率，邻区规划。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 10/45

内部公开▲

案例7：LAPD PCM时隙故障导致高掉话

现象描述：基站开通后一切正常，几天后其中4个站TCH指配失败率突然高达40－50％，掉话率升高至10～20％左右，切换成功率也很低，严重影响网络质量，引起用户投诉。 现象分析：问题小区都不存在话务拥塞问题，覆盖良好。在拨测中发现大约50％的通话正常，提出可能是LAPD PCM某个时隙出现问题。

解决方法及验证：后台调换了故障小区的LAPD PCM时隙，现场测试基站工作正常，提取性能报表各项指标也恢复正常；对其余3个站点进行相同的操作，基站都开始正常工作。 经验总结：对新开站要注重拨测工作，保证基站能正常工作。

案例8：载频隐性故障导致高掉话

现象描述：某小区话务统计该小区无线链路失败掉话非常多。 现象分析：无线链路失败掉话过高，查看干扰情况正常，最小接入电平等参数设置正常。同时切入成功率也偏低，指配成功率也偏低，怀疑是硬件存在问题。

解决方法及验证：查看abis口信令，发现该小区有1个tch载频的发射功率特别的低，从而导致各项指标均差。解决办法就是更换载频。

经验总结：载频隐性故障会给网络存在各种各样的问题，建议告警管理能够监控载频的发射功率如果发现异常应报相应的告警。 案例9：载频故障引起高掉话 现象描述：甘肃庆阳焦村边际网2小区掉话很严重

在后台性能统计中发现焦村边际网存在上行的5级干扰，且经常出现掉话，晚忙时掉话达到14～17次左右，严重影响了性能指标。在对焦村边际网路测下行正常，如下图：

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 11/45

内部公开▲

后台统计如图： 经过对频点检查核实并没有同邻频现行，修改频点后5级干扰依然存在，掉话依然严重。 最终发现原因：焦村边际网是BS21设备，掉换1、2小区的载频，2小区干扰消失，1小区出现5级干扰。所以确定为载频问题，更换新的载频后关闭该问题。

案例10：网外干扰导致高掉话

现象描述：后台性能指标统计显示西安北得联大厦站点3小区掉话率高。

现象分析：统计详细的性能数据，查看掉话类型，发现以切换失败掉话居多。检查小区频点、邻区等数据，没有发现问题。跟踪信令，发现上行电平比较强，但上行质量很差，RF资源指示中空闲信道干扰带级别为5，如下图所示。故判断该小区存在网外干扰。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 12/45

内部公开▲

解决方法及验证：尝试使用带外频点（联通针对西安西北郊存在外部干扰而给出的可用频点），修改频点后，掉话次数明显减少，指标正常，问题得到解决。 业务信业务信道占业务信道日期 站名 小区位置区(LAC-CI) 道掉话用总次数掉话率(含总次数 （含切换） 切换)(%) 2005-05-23 2005-05-24 2005-05-25 西安北_得联大厦_DV2 西安北_得联大厦_DV2 西安北_得联大厦_DV2 LAC8411-CI25458 LAC8411-CI25458 LAC8411-CI25458 频点调整后 2005-05-26 2005-05-27 2005-05-28 西安北_得联大厦_DV2 西安北_得联大厦_DV2 西安北_得联大厦_DV2 LAC8411-CI25458 LAC8411-CI25458 LAC8411-CI25458 2 1 1 703 826 495 0.28 0.12 0.2 19 22 39 608 542 790 3.12 4.05 4.93 经验总结：通过信令跟踪，收集上下行的测量报告数据，能准确的定位上下行链路的电平、质量，空闲信道的干扰带信息，非常利于问题的处理。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 13/45

内部公开▲

案例11：上行干扰导致高掉话

现象描述：印度北方SPICE 12201,12553,等基站突然出现高切换失败率,高TCH掉话率,TCH指派失败率等现象,突然投诉率增多严重影响用户的通话效果,而且这种现象一天并不是连续出现,而是在个别时段出现,如13,15,17,20点等时段.

现象分析：问题出现后，我们分析了一个小区的话务报表12201,发现这个小区的掉话全都发上在切换掉话上,建立切换统计测量及信令跟踪发现都是由于上行尝试切换导致的掉话增多, 继续分析发现这个小区的BAND5非常高,由此分析这应该是一种干扰导致的切换掉话,为此我们根据这一思路对周围的站进行了分析,发现周围的站都是高BAND5,而且也存在高掉话率的现象,为此我们对这个区域进行了CQT,DT测试,发现这个地方频繁切换,然后马上掉话,,有时候连电话都无法正常呼出,根据拨打呼叫的难以成都我们逐渐靠近了更本无法起呼的点,即靠近干扰源的监狱地方, 然后判断这是一个上行干扰导致的掉话,为此我们找来了YBT250进行了测试,发现在这个区域存在很强的上行干扰,底噪在-68dbm左右,继续追查这是监狱为防止罪犯用通讯设备而做的干扰仪器.

解决方法及验证：经过对干扰源的确立后,我们报告了相关人士,积极沟通, 要求关闭这个干扰源,但由于政府控制机构,很难协调成功,故这一问题暂时搁置,等待局方的继续协商后解决这一干扰导致的高掉话问题.

经验总结：碰到高掉话问题后不要急于路测,应先分析原因,做到心中有数,然后根据分析一步一步去派查,针对上述案例,我们分析到是干扰源导致的高掉话,为此我们用专业设备本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 14/45

内部公开▲

YBT250进行区域扫频,最终定位了干扰源,找到了问题的根源所在.缓解了我们的工作压力.也确定了局方的认可.

案例12：切换不及时导致掉话

现象描述：利比亚当地车速较快，平均在100KM以上，由于话务繁忙，因此站点密集，一般都在1KM以内，由于邻区关系不够以及切换门限设置问题导致切换不及时，特别是跨BSC切换迟滞，造成掉话。

现象分析：从OMCR统计数据观察，跨交换切换受理比例仅为70％多，在路测过程中，也发现因切换不及时导致的深入孤岛掉话。 解决方法及验证：

对站点密集区域、高速路等切换频繁区域多添加邻区，在原有基础1层基础上添加1.5～2层邻区关系，加大同频同色码复用距离，保证足够的邻区关系，在一层来不及切换的情况下能及时切换到第2层邻区，减少掉话；

修改切换门限，通过降低紧急电平和质量切换门限，确保在通话质量恶化的情况下能及时切换；

打开快速切换功能，特别使针对高速路区域站点，在通话质量恶化时可立即无条件切到其他可用邻区上，避免掉话；

交换侧，通过修改T305/308计时器等手段，降低无线侧掉话率。

案例13：交换侧问题引起异常掉话

现象描述：利比亚办事处要求在VIP区域尽量无掉话，由于VIP区域横跨5个交换局和近20个BSC，站点200多个，在平常测试过程中，有很多交换侧突然拆链造成的掉话，无线UM信令现象为：DESTINATION OUT OF ORDER或NETWORK OUT OF ORDER。

现象分析：在对VIP区域进行长话测试过程中，发现有交换侧异常掉话问题，具体现象为在RX_QUALITY和上下行信号都正常的情况下突然掉话，从路测软件看，UM口信令为：DESTINATION OUT OF ORDER 或 NETWORK OUT OF ORDER，属交换侧异常拆链，无线侧不可控； 解决方案及验证：交换侧通过升级解决；

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 15/45

内部公开▲

案例14：上下行不平衡造成切换掉话过多

现象描述：在某地联通性能分析中发现某小区A掉话率达到10%，掉话次数平均每小时有30多次。 现象分析：

1、直接引用出掉话分类统计指标如下：

无线链路失败引起掉话次数 LAPD链路失败引起掉话次数 切换失败引起掉话次数 C11622 C11623 C11624 2、从掉话分类看，该小区掉话几乎全部为切换掉话； 3、分析切换性能发现该小区向邻区B的切换成功率很低，初步判断A小区切换掉话原因在在A、B两小区切换问题上； 4、核对切换门限等参数，分析频率规划等都未发现问题实质； 5、仔细分析小区B和小区A之间发生的切换，发现A小区切向B小区的原因统计中各类切换分布合理（PBGT切换占70%左右，上下行电平切换和质量切换各占15%左右），但是从B小区向A小区的切换大部分是上行电平和质量切换（共占80%左右）；开始把注意力从掉话的A小区转移到B小区； 6、从性能分析是上看发现B小区话音信道分配成功率很低（联通公司新定义指标），主要原因是指配成功率低，同时也可以发现立即指配成功率也不高。 7、查看前期测试数据发现B小区明显存在越区覆盖问题，从远处下行接收电平（9公里处接收电平-70～-75dbm）来看该站点应该下挂直放站，并怀疑直放站造成上下行平衡问题。<因为该地使用V2.5BSC版本，如果升级后版本此处建议使用信令分析确认上下行平衡> 8、和用户交流是得到结果没有直放站。不过后来了解到该站使用了北京一家公司提供的160W的功放（直接输出功率），而且没有使用塔放。链路预算上下行链路差=（52+102）-（33+108+3）=10dbm。确定问题根源。 解决方法及验证：

1、首先考虑补偿上行来解决上下行不平衡问题，但是考虑到塔放的有效补偿为馈线部分的损耗，该站点采用50m长3/4馈线，加上两个接头<4db，补偿后依然有6db的不平衡，且局方暂时很难完成这方面的整改。

2、考虑到B小区下行功率问题造成切换发生时上行接入不成功，提高该小区作为其他小区本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 16/45

内部公开▲

相邻小区的最小接收电平门限到25（其他小区取15），随后又增加到30。同时针对静态下过覆盖问题，在确认频率方面没问题的同时打开C2允许，取PT=31（CRO取负修正），CRO=10db（后台取5代表10db），调节该小区过度吸收话务且不影响弱覆盖区的正常接入。

3、完成2步骤修改后，小区B拥塞明显降低且话音信道分配成功率明显提高。而小区A的切换掉话次数降低到每小时1、2次，且随着话务量的增加掉话率降低到1%以下。 经验总结：在话务分析时一定要抓住每个细节追根揭底，在必要的时候还要从问题点以外的小区着手发现问题。

案例15：O&M intervention （O&M干预）掉话

现象描述：通过信令数据的详细分析发现，掉话原因是o&m intervention，我们判断是载频的cu单元自动将用户正在进行的通话闭塞造成了掉话。

现象分析：建议进行如下检查：对站点检测。（接地，接头等）； TRM数据删除并更换槽位；看看是否还存在问题；LMT检查TRM中的版本信息；作一次时隙的拨打测试。

解决方法及验证：碰到这种问题，一般是硬件隐性故障。我们一方面加紧协调车辆和人员去现场处理，一方面先在后台闭塞故障载频，确保话务掉话比不受影响。最终的处理过程是这样的：更换载频能彻底解决问题；如果不更换载频，那么把问题载频闭塞一段时间再解闭也能使现象临时的消失，但是不能保证何时再次出现。

案例16：天馈问题导致掉话严重

现象描述：利比亚现场某1800M基站，3个小区，S8/8/8配置，其中1、2小区掉话严重，忙时达到100次以上。 现象分析： （1）该1800M基站后台统计3小区掉话情况正常，其中1、2小区掉话大部分是无线掉话，可以排除传输故障；

（2）1800M频率比较宽松，WP检查该小区与附近小区不存在同邻频现象，且后台干扰带统计，BAND3、4、5干扰情况不存在；可以排除干扰造成掉话。

（3）后台检查小区参数，3个小区基本一致，参数设置合理，可以排除因参数不合理造成的掉话。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 17/45

内部公开▲

（4）现场检查，硬件工作正常，天线倾角、俯仰角与规划一致，无驻波比等告警。 （5）后台MA10跟踪2个掉话小区信令发现：掉话都集中在后4块载频上面。

（6） 现场测试发现，2个小区后4 块载频在该主小区主服方向500-600米处，电平与BCCH电平相差20DBM以上，且4块载频现象一致。基本可排除4块载频同时出现故障的情况。更换CEU、CDU等故障依旧。 综合以上考虑，怀疑天馈出现问题。

解决方法及验证：带天线工检查馈线，发现1小区后4块载频的天馈与2小区后4块载频的天馈接反。造成服务小区的BCCH覆盖范围正常，但当通话占用后4块载频时，由于馈线接在另外小区的天线上面，电平很低，造成掉话。调整馈线后，复测，主服方向上，各载频的电平强度相当。接下来忙时KPI统计，问题小区掉话情况恢复正常。 经验总结：掉话集中在某几块载频时，注意观察载频与馈线之间的关系：掉话的载频是否集中在同一根馈线上面，如果是，就要考虑馈线接反的可能性。这种馈线接反的情况在利比亚现场很普遍，以上属于馈线A2与B2接反的情况，现场还有类似A2与B1的接反情况以及2个小区的馈线全接反的现象。馈线接反也能造成切换方面的问题。

案例17：覆盖问题导致单通甚至掉话

现场描述：某运营商办公室内出现单通或话音断续现象甚至掉话现象。 现象分析：经检查发现该区域信号漂移现象严重，可能存在原因如下： 1）信号较弱

接收电平在－100dBm左右，而且由于多径效应，无线信号强度会有所浮动，因而在通话过程中，由于信号弱导致话音质量RQ达到5～7级时，就会出现单通或话音断续现象甚至掉话。 2）干扰原因 从该区域检测到的频点信息可以看出，这个地方存在邻频干扰现象，且这些频点信号强度较弱，等网优人员到达现场后可以先收集整理全网最新频点数据，进行频点调整。 解决方法及验证： 1）新增基站

为了解决覆盖问题，最有效的办法是增加新站。 2）工程参数调整

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 18/45

内部公开▲

可以进行站点勘查，调整天线方位角，争取每个小区天线的主波瓣都对准用户集中区域，保证在覆盖交叠区域有1个主服务小区。

验证：后经调整天线方位角15度，使得天线的主波瓣角对准用户场所，发现问题解决，多次测试均得到验证。

经验总结：在进行站点勘察时，要尽量了解重点用户群体的位置，每个小区天线的主波瓣都对准用户集中区域，保证信号的良好覆盖。

案例18：某小区合路器隐性故障忙时掉话几十次

现象描述：巴基斯坦EGSM网络中的某个900M基站，为s224配置，覆盖附近的居民区，该基站2小区从7月份开始，忙时掉话次数都在几十次左右。

现象分析：产生掉话问题的原因有很多，为了解决掉话问题，首先从后台无线参数的配置进行检查。进而从硬件方面考虑。

解决方法及验证：首先核对频点，由于在覆盖区内基站相距在2公里左右，该小区频点没有与附近的小区有同频和邻频现象。通过基本测量也发现该小区的1级干扰带以上的计数基本没有，排除了是频点干扰的原因。其次检查邻区关系，发现邻区关系已经十分完善。核对其他的后台无线参数设置都没有发现问题。 为了彻底解决该基站的掉话问题，我们乘车到了现场对该基站进行了测试。首先检查了设备和环境，没有设备告警中，载频、合路器、cmm板间运行正常。在距离2小区约1公里的地方，我们对掉话多的2小区进行了定点拨打测试，发现在占用上2小区的第2机框内载频的时候信号电平下降很大，比BCCH载频低20dB，通话质量很差,6-7级，而占用上第一框载频的时候通话质量良好，电平正常。为了验证是否是载频故障，我们把第一、二机框载频进行互换，再次拨打测试发现第2机框内载频通话质量良好，而第1机框内载频通话质量变差，因此确认是载频故障引起的。

经验总结：如果小区掉话多是因为隐性的硬件故障造成的，可以通过调换怀疑有问题的硬件与确信没有问题的硬件，通过问题是否消失来确认是哪个硬件的问题。

案例19：交换侧定时器T305和T308对掉话统计的影响 T305和T308是两个交换侧定时器，具体作用如下： T305

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 19/45

内部公开▲

? 作用：定时器对挂机过程进行监视 ? 启动：MS发送释放消息 ? 停止： (1) (2)

MSC收到RELEASE消息 MSC收到DISCONNECT消息

? 超时：定时器超时后，MSC发送RELEASE 消息 ? 取值：建议值30s T308

? 作用：资源释放过程监视定时器 ? 启动：MSC发送RELEASE消息 ? 停止： (1) (2)

MSC收到RELEASE COMPLETE消息

MSC收到RELEASE消息，即冲撞时或MS没有收到RELEASE消息造成手机

T305超时。

? 超时：处于“释放请求”状态的网络侧CC实体在T308第一次超时时，将重发RELEASE消息，重新启动T308，继续保持在“释放请求”状态。在T308第二次超时时，网络侧CC实体将释放MM连接，并返回“空”状态 ? 取值：建议值30s 这两个定时器是非常重要的两个定时器，对掉话的统计很大的影响，下面是某地的一次掉话信令分析，可以看出这两个定时器是如何具体影响掉话次数的。 此地目前T305、T308两个定时器分别设置为2.2S 某小区一次掉话的ABIS信令如下：

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 20/45

内部公开▲

这个是某小区的一个CONNECTION FAILURE掉话的信令截图， 从测量报告上来看，无线链路已经非常的恶化，具体对用户的感受来说可能是已经听不见了。请注意看标出的四个关键事件：第一个是下行发过来的DISCONNECT消息，原因值是16，应该是对方用户听不见后主动挂机。由于这边的无线链路非常恶化，不能完成正常的释放流程。于是T305起作用，2.2S后下行发过来RELEASE消息，这是第二个事件。但是这边的无线链路仍不能正常释放，于是按照T308的定义，2.2S，T308超时后系统在下行重发一次RELEASE消息，这就是第三个事件。而第四个事件是CONNECTION FAILURE INDICATION，即RLT为0了，无线链路计了一次掉话。第三个事件和第四个事件之间的事件差不到一秒，距第二个事件约3秒。由此例可见，如果T308进一步减小，在3秒内完成， RELEASE消息的重发，则赶在系统计一次掉话之前，完成正常的释放，就减少了一次掉话。 由上面的分析可以看出，调整T305、T308这两个定时器对减少CONNECTION FAILURE的掉话有一定好处的，如果交换侧原先设置为默认的30S改到一个较小的值，对掉话的统计的影响会非常明显。但是如果本身就较小，再改小后可能效果不是非常的明显。 一般我们建议这两个定时器最小可以改到T305为2S、T308为1S而不会影响正常的业务。

但是修改这两个定时器仅对统计上有好处，对用户感知度并无什么帮助。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 21/45

内部公开▲

案例20：后备板遭雷击损坏导致高掉话

现象描述：在黑龙江的黑河移动分公司进行优化时，从一天的话务统计数据里，发现讷莫尔基站的3个小区忙时掉话次数多在80次左右，查看其他时段掉话次数也比较多，查CMM和TRM板的告警情况，没有历史告警；检查小区参数没有问题，到基站发现CDUG板反复重启，更换CDUG板现象依然存在，继续观察该基站的3个小区掉话，忙时和其他时段掉话次数依然严重。

现象分析：从反复重启的现象上，开始怀疑是传输问题，但查告警里CMM板根本就没有传输顺断和中断的问题，把传输问题排除；更换CDUG板件后，CDUD告警依然存在，用测试手机在基站附近观察，用户反映的信号时有时无现象解决，但后台统计数据掉话依然较高；怀疑天馈是否有问题，因为从了解的情况分析，发现高掉话的前一天下了大雨，是否馈线进水或馈线头松动，造成信号不稳定，掉话高，安排馈线人员全部排查3个小区的馈线，不是馈线问题排除。

解决方法及验证：再次跑到该基站处理，因为该基站话务比较高，所以V2机架有主副两个，有两个载频框是空着的，所以从移动维护人员那取了工具，把没有插载频的载频框后备板拆下，更换到基站小区使用的载频框上，CDUG反复重启问题排除，不存在告警。更换回原来的后备板，问题再次出现，又到基站附近的老乡家询问下雨那天的情况，下大雨伴有闪电和雷声，查看基站接地线，有烧焦现象。在此确认这个掉话问题，主要是由于下雨打雷，接地线安装问题导致基站地机架遭受雷击，载频硬件有保险所以没有被打坏，但后备板确被雷击后出现故障，造成CDUG反复重启，造成高掉话。

经验总结：这种故障情况能碰到非常少，也是一个对工程队安装以后要严格考核的重要安装项目，因为雷击造成基站高掉话，如果接地线过关，应该是不会出现上述问题的。另外，对于故障的原因，也要优化人员在现场多跟基站附近的用户了解情况，有利于尽快排查出故障点。

案例21：处理LAPD掉话问题

现象描述：2006年7月12日性能统计发现EKTA Book Store各方面指标出现异常，特别是掉话非常严重，如表1所示： Table 1

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 22/45

内部公开▲

TCH in call Handover Cell and Location UserLabel Object identifier Area Cell(LAC-CI) rate(exclude rate(%) handover)(%) EKTA Book Bsc3-Site17-Bts1 LAC1003-CI30171 Store-1 EKTA Book Bsc3-Site17-Bts2 LAC1003-CI30172 Store-2 EKTA Book Bsc3-Site17-Bts3 LAC1003-CI30173 Store-3 42.98 39.01 1198 515 21.99 53.04 923 203 32.71 44.51 648 212 handover) number drop success number(exclude call total total dropped TCH seizure TCH 现象分析：经检查基站历史告警，发现微波传输链路经常出现瞬断告警，从基本测量报告表2可以看出大量掉话来自Lapd Link Failure Table 2 11622(Number 11623(Number 11624(Number of Dropped BSC SITE CELL Time Alias Call due to Radio Link Failure) 2006-9-12 3 17 1 20:15 2006-9-12 3 17 1 20:30 2006-9-12 3 17 1 20:45 2006-9-12 3 17 1 21:00 2006-9-12 3 17 2 20:15 3 17 2 2006-9-12 EKTA Book Store-2 2 45 0 EKTA Book Store-2 1 33 0 EKTA Book Store-1 0 13 0 EKTA Book Store-1 0 77 0 EKTA Book Store-1 2 65 2 EKTA Book Store-1 0 53 0 of Dropped Call due to Lapd Link Failure) of Dropped Call due to Handover Failure) 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 23/45

内部公开▲

20:30 2006-9-12 3 17 2 20:45 2006-9-12 3 17 2 21:00 2006-9-12 3 17 3 20:15 2006-9-12 3 17 3 20:30 2006-9-12 3 17 3 20:45 2006-9-12 3 17 3 21:00 EKTA Book Store-3 1 102 3 EKTA Book Store-3 0 157 0 EKTA Book Store-3 5 131 0 EKTA Book Store-3 2 112 2 EKTA Book Store-2 1 51 1 EKTA Book Store-2 0 68 1 解决方法及验证：经通知局方传输工程师故障处理后，2006年7月16日性能统计发现EKTA Book Store基站不仅各方面指标恢复正常，而且话务占用也比故障时增加了一倍以上，如表3所示： TCH in call Handover Cell and Location UserLabel Object identifier Area Cell(LAC-CI) rate(exclude rate(%) handover)(%) EKTA Book Bsc3-Site17-Bts1 Store-1 EKTA Book Bsc3-Site17-Bts2 Store-2 EKTA Book Bsc3-Site17-Bts3 Store-3 LAC1003-CI30173 0.64 84.07 2770 18 LAC1003-CI30172 0.76 84.83 1690 13 LAC1003-CI30171 0.73 94.01 1632 12 handover) number drop success number(exclude call total TCH seizure total dropped TCH 案例22：载频指派优先级降低掉话

现象描述：塞拉里昂城区山坡道路掉话严重

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 24/45

内部公开▲

现象分析：该区域地势太高，城区所有站的信号基本都可以收到，频率资源不够。干扰严重。 解决方法及验证： 现网找不到干净频点在此区域。在该区域所有服务小区采用跳频分配优先，使干扰分集。测试不会出现掉话。

经验总结：载频指派优先级的灵活使用，可提高频率利用率，降低掉话。

案例23：接成小鸳鸯线引起高掉话

现象描述：利比亚GSM网络中的TRI247（S4//4//4配置）基站是2006年2月初刚开通的基站，从开通后该站掉话就比较多。

现象分析：2月13日本地员工BAHA去该基站附近路测的过程中发现该基站1，2小区的天线接反，从统计报表看该站2月15日掉话达462次，直接导致所属BSC22的话务掉话比只有36，没有达标（要求话务掉话比达到中期值90），2月16日我再次去路测证实了该站1，2小区的天线确实接反了，当天就让工程队上铁塔调整了天线。从统计报表发现该站2月16日，17日两天的掉话竟然高达532次和564次且指派失败率很高，于是怀疑是硬件故障，2月18日到该站进行拨打测试，测试中发现该站2小区有两块载频输出功率不稳定，波动值达到17～25dB，当天就更换了这两块载频及CDU单元，我们网优组的几个同事都想着该站应该不会再有那么多的掉话了。可是统计报表显示该站2月18日掉话还有390次，大家都很郁闷，由于该站的高掉话导致2月18日BSC22话务掉话比不达标，后来我们讨论从参数及频率入手进行问题定位，先从基本测量中发现该站2小区干扰带在5级有1个，遂对该站进行了改频，并对邻小区关系进行了彻底检查，结果从报表看该站每天的掉话平均还是150次左右，2月26日该站掉话高达258次导致BSC22话务掉话比再次不达标。2月28日我们和用服部的同事就该站掉话居高不下的情况进行了沟通交流，认为导致掉话多应该还是硬件问题，这需要对基站所有硬件（包括天馈系统）进行彻底仔细的检查。3月1日我和用服部同事到该站进行硬件排查，首先测CDU单元输出功率及驻波比，路测发现天线也没有接反，但在路测过程中发现手机在1小区通话时每当占有1小区后两块载频时手机在起呼后接收电平都有一个陡降，于是怀疑可能是馈线接成了“鸳鸯线”，并继续用万禾路测软件在1，2小区分别进行锁频测试，具体分析如下：

CI 12471 NCC 0 BCC 6 BSIC 06 TCH1 87 TCH2 99 TCH3 68 TCH4 106 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 25/45

内部公开▲

12472 12473 0 0 6 6 06 06 71 81 73 94 124 115 112 120 注：上表是改频后的数据，下面的路测图中显示频率是改频前的频率（万禾软件map图没有及时更新）

上图是在小区1通话（占有BCCH：87，TCH：68），可以看出TCH电平比BCCH电平低18dB，实际上此时手机接收到的TCH：68的信号是从2小区的天线上发射出来的而BCCH：87的信号是从1小区的天线上发射出来的。

上图是手机在2小区通过锁频占用1小区（BCCH：87，TCH：68）的信号进行通话，可以看出TCH电平比BCCH电平高出33dB，这是因为此时的TCH：68的信号是从2小区的天线上发射出来的而BCCH：87的信号是从1小区的天线上发射出来的。

上图是在小区1通话（占有BCCH：87，TCH：106），可以看出TCH电平比BCCH

电平低18dB，实际上此时手机接收到的TCH：106的信号是从2小区的天线上发射出来的而BCCH：87的信号是从1小区的天线上发射出来的。

上图是手机在2小区通过锁频占用1小区（BCCH：87，TCH：106）的信号进行通话，可以看出TCH电平比BCCH电平高出21dB，这是因为此时的TCH：106的信号是从2小区的天线上发射出来的而BCCH：87的信号是从1小区的天线上发射出来的。

上图是手机在1小区通过锁频占用2小区（BCCH：71，TCH：124）的信号进行通话，可以看出TCH电平比BCCH电平高出35dB，这是因为此时的TCH：124的信号是从1小区的天线上发射出来的而BCCH：71的信号是从2小区的天线上发射出来的。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 26/45

内部公开▲

上图是在小区2通话（占有BCCH：71，TCH：124），可以看出TCH电平比BCCH电平低37dB，实际上此时手机接收到的TCH：124的信号是从1小区的天线上发射出来的而BCCH：71的信号是从2小区的天线上发射出来的。

上图是在小区2通话（占有BCCH：71，TCH：112），可以看出TCH电平比BCCH电平低32dB，实际上此时手机接收到的TCH：112的信号是从1小区的天线上发射出来的而BCCH：71的信号是从2小区的天线上发射出来的。

上图是手机在1小区通过锁频占用2小区（BCCH：71，TCH：112）的信号进行通话，可以看出TCH电平比BCCH电平高出15dB，这是因为此时的TCH：112的信号是从1小区的天线上发射出来的而BCCH：71的信号是从2小区的天线上发射出来的。

解决方法及验证：通过以上的路测数据分析可以推断该站1，2小区的馈线接成了“鸳鸯线”，即将1小区的前两块载频和2小区的后两块载频接到1小区的天线上，将2小区的前两块载频和和1小区的后两块载频接到了2小区的天线上，这样导致的直接后果就是指派失败率高，掉话很多，切换成功率也较低。现场在机柜顶部将1，2小区的两根馈线进行了倒换。通过几天的性能统计报表发现该站掉话大幅度的下降了。

通过该站的故障处理建议我们以后在处理异常掉话时可以扩大思路，不仅要对硬件进行测试还要对相关的连接线进行详细仔细的检查，同时在拨测或路测的过程要对每块载频都要有数据记录，这样便于分析和及时发现问题。

经验总结：在利比亚优化期间发现了大鸳鸯线和小鸳鸯线故障造成的呼叫弹回、指配失败、掉话和切换失败问题不下50例，这类问题的处理需要硬件排查人员、abis口信令分析和路测人员一起来分析，定位和解决问题。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 27/45

内部公开▲

案例24：MAIO设置不当引起掉话突增

现象描述：白银某基站某天突然掉话次数狂增。

现象分析：观察基本测量的干扰带发现，小区干扰带有前一天某时间后一直为5，询问用服人员最近是否做过何种操作，得到回答为仅进行过扩容。

解决方法及验证：对该站扩容的数据进行检查，主要是与其他小区数据进行比对，最终发现新扩容扳子的MAIO设置不当，将该板子MAIO修改后，小区恢复正常。

经验总结：对于突然发生的掉话率恶化，可以通过干扰带，检查数据等方法对问题进行定位，或直接更换硬件，这样突然的恶化原因多半来自上述。

案例25：切换原因导致的掉话

现象描述：从4月25日18：00后青田范村三个小区同时出现严重的掉话现象，经查看掉话原因为由于切换原因引起的掉话。

现象分析：通过检查该站点的切换情况表报发现改站点三个小区出现了较多的由于下行干扰导致的小区内切换次数并且大部分都失败。现场测试发现，在下行场强很高的情况下，会随机的出现连续7级质差的话质，经到现场观察发现该站点为一活动房并且没有安装空调，室内温度大约在40－50度之间。

解决方法及验证：拆掉一块载频放到通风的地方进行散热，等该载频降温后重新装上进行测试，发现载频工作恢复正常，那种连续的7级质差没有了，按照前述的方法将本站其它的5块载频也一一做了测试，结果正常，故障得到解决。

经验总结：由于载频环境原因导致输出功率不足，引起上下行链路不平衡，导致出现严重的切换掉话现象，机房环境必须要保持正常状态，才能保证正常工作。

案例26：天馈及塔放问题造成通话有金属声及掉话

现象描述：罗甸边阳投诉电话有金属声，经常掉话。

现象分析：从性能报表中关键KPI中可以看出，切换失败高，指派失败高伴随掉话，干扰带为5，基本可以定位掉话和通话金属声由干扰造成。查看基本测量发现，切换的原因大部分为上行干扰原因导致切换，并且失败率很高，这就更加证明上行干扰是问题的根结，下行没有干扰。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 28/45

内部公开▲

图 下行不存在干扰 表：基本测量 116106(上11674(干11615(话扰带为5时间 别名 音信道掉的平均空话总次数) 闲TCH数) TCH/F) 2006-6-28 罗甸边阳0 19:15 _1 2006-6-28 罗甸边阳1 19:30 _1 2006-6-28 罗甸边阳1 19:45 _1 2006-6-28 罗甸边阳4 20:00 _1 2006-6-28 罗甸边阳3 19:15 _2 0 26 3 23 6 2 34 2 34 2 3 20 2 22 0 1 18 1 19 0 1 11 0 11 0 TCH/F) 成功次数) 失败次数) 尝试 on 尝试 on 区内切换区内切换起的切换起的切换11675(小11676(小行干扰引行干扰引116107(下本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 29/45

内部公开▲

2006-6-28 罗甸边阳4 19:30 _2 2006-6-28 罗甸边阳1 19:45 _2 2006-6-28 罗甸边阳10 20:00 _2 1 58 21 78 1 1 12 0 12 0 1 23 6 29 0 解决方法及验证： 话音信道忙时话音掉话率(不别名 信道掉话含切总次数 换)(%) 罗甸边阳12 _1 罗甸边阳29 _2 4.55 91.26 8.24 1 1.14 92.22 5.63 1 率(%) 率(%) 切换成功指派失败干扰带5 话音信道在基站搬迁后就发现罗甸边阳站掉话异常，干扰带5。见性能报表。 检查系统告警，未发现任何异常告警现象。 检查频率规划数据，没有同邻频现象。 用YBT250扫频后没有发现外部干扰。 因此怀疑是板件的问题，更换了BCCH载频和部分TCH载频，没有改善；更换了CDU也没有改善。后来发现边阳2小区天馈系统有一个遗留的塔放，把塔放甩开后，2小区的干扰问题解决，但1小区问题依旧。怀疑1小区天馈的问题，sitemaster测试后发现天线附近1/2条线驻波比高，更换后，1小区问题解决。（起初现场没有仪表，只有先倒换板件） 故障分析结论：

1小区是由于1/2软跳线的问题导致天馈产生上行干扰，从而导致掉话和通话质量不好。

2小区是由于塔放老化的问题及塔放模块不够的原因造成上行干扰，从而导致掉话和通话质量不好。

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 30/45

内部公开▲

案例27：Abis信令跟踪发现引起掉话的隐性问题

问题描述：后台性能指标显示，商务局3小区掉话较多，一般都在3%左右。

现象分析： 通过规划软件查看商务局3小区的相关参数，频点，BISC，相邻小区等，没有发现异常。于是想通过信令跟踪看能不能发现问题。跟踪到其在忙时的信令后，观察测量报告时发现，当发生掉话时，上行异常。如下图：

上面用MA10分析软件观察出，上行异常，从而导致掉话。

解决方法及验证：更换此小区的BCCH载频。在通过上述调整后，后台指标显示，该小区的掉话次数得到了明显的减少。

TCH掉话次日期 2006-07-27 20:00-21:00 2006-07-28 20:00-21:00 别名 临夏市_商务局_bts3 临夏市_商务局_bts3 数 3 6 无线链路掉话 1 1 切换掉话 2 5 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 31/45

内部公开▲

2006-07-29 20:00-21:00 2006-07-30 20:00-21:00 2006-07-31 20:00-21:00 2006-08-01 20:00-21:00 2006-08-02 20:00-21:00 临夏市_商务局_bts3 临夏市_商务局_bts3 临夏市_商务局_bts3 临夏市_商务局_bts3 临夏市_商务局_bts3 更换后 2006-08-14 20:00-21:00 2006-08-15 20:00-21:00 2006-08-16 20:00-21:00 2006-08-17 20:00-21:00 2006-08-18 20:00-21:00 2006-08-19 20:00-21:00 2006-08-20 20:00-21:00 临夏市_商务局_bts3 临夏市_商务局_bts3 临夏市_商务局_bts3 临夏市_商务局_bts3 临夏市_商务局_bts3 临夏市_商务局_bts3 临夏市_商务局_bts3 2 0 1 0 1 3 0 2 0 0 0 1 3 0 0 0 1 0 0 0 0 11 11 9 10 8 6 6 5 2 8 5 5 4 8 0 经验总结： 对于这种掉话不是很严重的小区，但是感觉在市区的基站掉话还是偏多。如果检查其相关参数又没有发现任何问题的情况下，通过ABIS口的信令跟踪就能发现一些隐性的问题。 案例28：天线问题造成高掉话 现象描述：2006年2月在湖北时间进行优化的过程中发现交警支队二小区掉话次数和掉话都比较高，经常成为坏小区。通过性能统计上看通话的下行质量比较差，因下行质量引起的切换较多。 现象分析：通过基本测量得出该站点下行质量较差。通过信令跟踪发现出现了下行电平较高但通话质量很差的情况。怀疑存在着网内干扰。但是通过WP观察不到明显的同邻频干扰。解决方法及验证：通过路测发现该小区的正对覆盖区域没有明显的干扰，起呼和通话没有发现问题。但是当路测到该小区的背面时，确发现了很强的该小区信号，并且与相邻的一个小区有明显的同频干扰。通过反复路测确认该小区的天线有很强的背向功率，造成小区背向的方向一段干道有明显的干扰，造成起呼困难，掉话的问题。通过和联通沟通最后决定修改频点消除了干扰问题，掉话明显减少。

经验总结：天馈的问题经常会造成网内干扰，仅仅通过后台数据分析和wp的分析无法定位本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 32/45

内部公开▲

出问题。排除掉硬件故障后，需要进行详细的路测。

案例29：直放站干扰引起高掉话

现象描述：缅甸瓦城地区部分基站掉话率较高,我们从后台统计发现存在大量四级和五级干扰带的存在,因此我们分析掉话升高的原因是干扰引起的.

现象分析：为了进一步确认干扰对我们的影响,我们对问题基站进行了分析和排查.在分析过程中我们采用了扫频仪发现主要干扰带集中在GSM的上行频段上.也就是在880-920MHz.我们判定该干扰源的频段与GSM设备相近.

干扰的三维图象

因此我们着重对与GSM频段相近的干扰源做了排查,发现现场有两种使用GSM频段的设备,一是模拟网基站,该设备频段占用了GSM的1-40号频点.这是前期就有的,而且我们的基站频率规划时都避开了这些频点.因此基本排除.另外一种就是私人安装的直放站.我们找到了几个直放站做了测试,确认干扰频带基本吻合.因此判定了干扰源.

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 33/45

内部公开▲

通过ABIS口的分析和后台基本测量的分析进一步确认了干扰引起网络质量下降

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 34/45

内部公开▲

解决方法及验证：通过局方交涉,我们关闭了大多数的直放站.掉话率得到明显降低,达到正常水平.因此我们的分析和判断是正确的.

案例30：某小区合路器隐性故障导致忙时掉话几十次

现象描述：利比亚GSM网络中的某个900M基站，为s444配置，覆盖沿海附近的居民区，该基站2小区从7月份开始，忙时掉话次数都在几十次左右。

现象分析：产生掉话问题的原因有很多，为了解决掉话问题，首先从后台无线参数的配置进行检查。进而从硬件方面考虑。

解决方法及验证：该基站是已经开通了半速率和跳频功能。首先核对频点，由于在覆盖区内基站相距在3公里左右，该小区小区bcch频点没有与附近的小区有同频和邻频现象。通过基本测量也发现该小区的1级干扰带以上的计数基本没有，排除了是频点干扰的原因。其次检查邻区关系，发现邻区关系已经十分完善。核对其他的后台无线参数设置都没有发现问题。

为了彻底解决该基站的掉话问题，我们乘车到了现场对该基站进行了测试。首先检查了设备和方舱环境，从设备告警中没有发现问题，载频、合路器、cmm板间运行正常。方舱空调运行良好，方舱温度正常。在距离2小区约1公里的地方，我们对掉话多的2小区进行了定点拨打测试，发现在占用上2小区的第三和第四机框内载频的时候信号电平下降很大，通话质量很差，而占用上第一和第二机框内载频的时候通话质量良好，电平正常。为了验证是否是载频故障，我们把第一、二机框载频与第三、四机框载频进行更换，再次拨打测试发现第一、二机框内载频通话质量本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 35/45

内部公开▲

良好，第三、四机框内载频通话质量仍旧很差，因此排除了是载频故障引起的。为了验证是否是合路器故障我们把2小区的左右合路器对调再次拨打测试，发现第一、二机框载频通话质量差，电平较低，而第三、四机框内的载频通话质量变得很好，电平正常。因此判断是右边的合路器隐性故障造成了小区掉话次数增多。

经验总结：如果小区掉话多是因为隐性的硬件故障造成的，可以通过调换怀疑有问题的硬件与确信没有问题的硬件，通过问题是否消失来确认是哪个硬件的问题。

案例31：重叠覆盖深，全网忙时掉话300次左右

现象描述：全网忙时掉话300次左右，重叠覆盖深，市区优化 现象分析：优化工作分几步骤进行

1，核查跳频后的参数设置 2，核查硬件工程参数

3，核查频点，邻接小区，切换参数 4，修改交换定时器 5，核查A口链路

解决方法及验证：交换定时器T305 300-120；T308 120 － 50。掉话忙时减少50－70次左右

案例32：创建BTS测量任务快速判断掉话原因

现象描述：话音信道掉话率高，每天忙时掉话次数基本都保持在3%以上，掉话次数大概10次以上平均

现象分析：该基站处于城区边缘基站并且该小区方向冲着城区不过由于地形的关系该基站的地势较低，通过wp软件查看基站周围频点情况，怀疑可能是频率干扰影响。

解决方法及验证：该基站挂在BSC2.8下，新的BSC2.8在BTS测量下多了很多实用的新内容，可以看到每块载频的占用情况和通话质量、先通过建立该小区的BTS测量任务，对忙时进行统计分析。得到数据后发现，该小区的掉话基本都集中在一块载频上，而且话音质量7的采样率占了比较大的比重，慎重考虑期间先换了该载频的频点，隔日观察后问题依旧，更换该载频后掉话次数明显减小，忙时掉话在1－3次，问题解决。

经验总结：对与BSC2.8系统下发现高掉话小区可以通过创建BTS测量任务对该小区进行本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 36/45

内部公开▲

性能指标分析，可快速判断载频的硬件故障。 附：BTS测量报表

BTS测量

案例33：载频温度过高导致掉话

故障现象：从7月16日，神扈镇东大办基站开起来后，该基站1小区掉话严重，1小时内掉话达到上百次，经查看掉话原因为由于无线链路失败掉话和切换原因引起的掉话。 故障分析：通过检查该站点的切换情况表报发现改站点一小区出现了较多的由于下行干扰导致的小区内切换次数并且大部分都失败，而且伴随着有过温告警出现。通过在动态管理中观察，发现一小区BCCH载频隔几分钟呈现闭塞状态，此时会伴随有过温告警出现。

解决方法及验证：现场检查发现该站点第一小区后备板的风扇已经停止工作，载频温度很高，将挡板拆掉后发现风扇与备板连线已经烧断。后经过更换风扇模块，该问题解决。

案例34：切换不及时导致掉话

现象描述：独山县城到郊区的高速路上掉话,测试情况如下：

本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 37/45

内部公开▲

图32 深河大桥附近掉话 从县城行进至独山深河大桥附近，由于MS一直占用独山4站1小区12301的信号，没有切换出去，MS由于接收电平太低导致掉话。 现象分析：首先看一下MS行进至独山麻万站附近的情况，见图33， 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 38/45

内部公开▲

图33 MS在独山麻万站附近的情况

在邻小区列表中我们可以清楚的看到，BCCH22（独山麻万3小区32143）的接收电平为-68dbm，而此时MS的接收电平为-97dbm，按照切换门限8db的原则，此时MS应该切换到了独山麻万3小区。

通过查询后台性能报表，我们发现在徐总手机掉话的那个时段23日晚9：00-10：00，麻万3小区的拥塞率为8.20%，这也就是说从12301到32143的切换由于对方小区32143的拥塞导致切换不成功返回原小区，同时由于12301没有与前进都匀方向的32141（独山麻万1小区）、12162（深河大桥2小区）设置切换关系，这就导致了MS一直占用12301小区信号直至掉话。

解决方法及验证：

1） 增加独山4站1小区和麻万1小区，独山4站1小区和深河大桥2小区的相

互切换关系，避免独山4站1小区由于不能及时与麻万3小区切换而导致掉话。

2） 建议增加麻万3小区的载频1块。

问题得到解决。

案例35：载频故障导致掉话突然增多 现象描述：河北保定移动阜平台峪(BDZ6015_1)小区在2005年10月30日掉话突然增多，在10月31日掉话竟然达到100多次，性能报表如下表：

指标 话音信道掉话率(不含切换)(%) 话音信道掉话率(含切换)(%) 话音信道掉话总次数 话音信道掉话率(不含切换)(%) 无线链路失败引起掉话次数 LAPD链路失败引起掉话次数 切换失败引起掉话次数 由于BSC之间切换失败导致掉话 小区内切换成功次数 10月30日 10月31日 6.44 5.39 46 6.44 39 0 7 0 1 13.75 11.43 118 13.75 110 0 8 0 3 11月1日 16.44 13.64 98 16.44 93 0 5 0 2 本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 39/45

内部公开▲

小区内切换失败次数 0 2 1 现象分析：从上表可以看出掉话次数增加比较明显的是无线链路失败引起的掉话，LAPD链路失败引起的掉话次数为0，切换失败引起掉话次数占得比例很小，由于BSC之间切换失败导致掉话次数为0，因为是突然增加的掉话，而且又是连续的几天，这样我们可以怀疑有可能是小区的硬件损坏引起的掉话增加或者是由于突然增加的干扰引起的掉话，也有可能是由于周围小区断电导致本小区弱覆盖引起（可能性不大因为是连续几天）。

解决方法及验证：通过历史告警查询，可以排除本小区以及周围小区断电引起的掉话，通过小区测试，网优软件查看频率干扰以及干扰带查询可以排除干扰引起的干扰，通过对本小区进行Abis口信令跟踪发现，本小区的掉话基本都集中在频点为18的载频上（如图），于是我们定位掉话问题基本是与此载频有关的硬件存在问题，对此小区进行载频更换后，小区正常。Abis口信令分析如下图：

更换载频前后的性能报表如下表：

指标 话音信道掉话率(不含切换)(%) 话音信道掉话率(含切换)(%) 话音信道掉话总次数 10月30日 10月31日 11月1日 11月2日 11月3日 11月4日 6.44 5.39 46 13.75 11.43 118 16.44 13.64 98 1.63 1.23 10 2.13 1.76 11 1.28 1.03 7 经验总结：掉话问题是网优中经常会涉及的，在分析掉话问题时，可以根据性能报表各个指标数据变化进行问题分析，对于掉话可以将引起掉话的原因分别列出，利用排除法进行查找本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播 40/45

本文来源：https://www.bwwdw.com/article/4f37.html