日常优化案例总结及预案.doc

日常优化案例总结及预案诺基亚网络规划和优化部1背景32问题归类33问题解决途径44案例介绍64.1通话质量问题64.1.1干扰64.1.2载频故障74.1.3天馈故障74.2拥塞问题84.2.1硬件故障84.2.2传输问题104.2.3参数设置问题114.2.4容量问题124.2.5边界区域124.2.6覆盖问题134.3切换问题154.3.1基站同步问题154.3.2基站数据库问题154.3.3天馈连接问题164.3.4参数设置问题164.3.5基站主控板故障184.3.6MSC版本问题194.3.7时钟偏移194.4掉话问题214.4.1参数设置问题214.4.2信令配置问题234.4.3基站数据库问题254.4.4覆盖问题264.4.5跳频问题274.4.6干扰284.4.7直放站问题314.4.8塔放问题334.4.9功放问题344.4.10传输故障354.4.11硬件故障384.4.12硬件连接问题444.5其它问题474.5.1话务问题474.5.2信号不稳定494.5.3路测问题494.5.4无线接通率问题504.5.5用EGSM频点排除干扰因素504.5.6寻呼问题514.5.7手机无法接入问题524.5.8脱网问题554.5.9GPRS问题565预案571 背景在日常网络优化过程中，我们经常会遇到各种各样的问题，比如手机接入困难、通话出现噪音或中断、测试结果不理想等，有些问题会影响网络统计指标和排名，有些问题则直接影响终端用户的通话感受，而这些问题处理起来有的比较容易，有的比较棘手，但有时一个比较简单的问题，在处理时可能因为考虑的问题不够全面而使我们陷入僵局。为了让大家在处理这类问题时有更多的经验和思路，在此把过去一年多时间里，各地日常优化中遇到的问题和解决方案进行了分类汇总，并从中挑选出部分有代表性的案例及解决方案供呈现给大家，旨在提高我们解决问题的能力和速度，提升我们的服务价值和客户满意度。2 问题归类这些发生在网络中的问题，按表现形式及其影响，主要可以分为以下几类： 话音质量问题：话音质量不仅是网络考核的一个重要指标，也是影响终端用户感知的一个重要因素。在系统指标方面，通常考核的内容分为上行和下行质量，都是指通话时话音0到5级的和，目前上行质量一般在98%左右，下行质量一般在99%左右；其次话音质量的考核也被纳入道路测试的考核范围，按照集团的要求，下行通话质量应该达到95%以上。在终端用户感知方面，5至7级的话音质量用户会比较敏感，在这种情况下，受话者可能听到比较大的背景噪音，也有可能感觉话音时断时续等，严重影响用户的满意度。而导致话音质量较差的原因却是多方面的，最普遍的情况就是干扰，干扰又可分为网络内部干扰和网络外部干扰，网内干扰是由网络内部频率分配不当引起的，问题一般比较容易发现和解决，但网外干扰形式却具有多样性，有另外运营商的频段干扰，也有来自其它干扰器件的干扰，发现和解决起来比较困难。再就是设备硬件故障也会引起话音质量的恶化。 拥塞问题：这里提及的拥塞包括信令和话音两部分，信令部分的拥塞一般发生在LAC边界而且人流量比较大的区域，主要是由于频繁的位置更新引起，大部分情况下可以通过重新划分LAC或者扩充信令信道的容量来解决，但对于火车经过LAC区时高信令需求所引起的信令拥塞，却一时难以解决。和信令拥塞相比，话务拥塞处理起来相对来说要容易一些，主要通过参数调整，基站扩容等手段来解决。 切换失败：切换失败可以归类在隐性指标的范畴，过多的切换失败不仅会导致更多的掉话，而且会影响通话者的感受。引起切换失败的原因主要来源于硬件因素，同时不合理的参数设置也会导致较高的切换失败率。 掉话问题：掉话问题一直是我们重点关注的指标之一，也是解决起来比较棘手的事情。但由于导致掉话的因素比较复杂，所以处理起来难度较大，有些是由于硬件问题，参数设置问题，干扰和覆盖等因素造成的。 数据业务：随着网络资源的不断丰富，网络需求也越来越大，手机数据业务种类也越来越多，各地数据业务的收入也在稳步增长，因而数据业务的质量也越来越受到重视，现在考核数据业务的主要指标是GPRS上网速度和PDP激活成功率，而这些指标也是与网络的无线环境密切相关的，所以加强无线环境的优化也是解决GPRS数据业务投诉的主要手段。 其它问题：除了以上这些情况，在日常优化中，我们还会遇到其它的问题，比如手机无法打电话，手机信号不好，手机串话等问题，这些问题出现的频率较少，处理起来也相对容易一些。3 问题解决途径每种问题根据其发生的原因和表现，应该采用不同的解决方法，下面根据日常优化中的经验，对这些问题和相应的解决方法总结归纳如下：（1） 话音质量问题： 对于加了塔放的基站，当塔放出现故障时，容易产生干扰，造成较差的通话质量，硬件排障排除后可以得以解决。 有些小区天线位置太高，或者下倾较小，造成较大的越区覆盖，对其它小区产生同频或邻频干扰，影响通话质量，一般可以通过调整天线来解决。 在通话过程中，有时会出现时断时续的现象，此情况一般为载频故障，一般只能通过更换载频来解决。 影响通话质量还有其它原因，比如天馈系统故障，常见的问题有：天线驻波比高，天线避雷器故障等。（2） 拥塞问题： 如果TRX本身出现故障而停止工作，会影响整个小区的容量配置，可能导致较高的话务拥塞，所以当发现小区拥塞时，首先可以检查小区的配置。 造成TRX停止工作除了TRX自身故障外，有时其相关设备的故障也会引起TRX停止工作，比如风扇故障，电源不稳等。这些问题一般需要现场处理。 对于安装了功放的基站，当对基站进行扩容后，功放设备也要进行相应的调整，否则会影响整个小区的工作，造成较大的话务拥塞；同时如果功放设备出现故障，也会因为各TRX发射功率不平衡造成话务拥塞。 在割接过程中，有时可能出现传输线接错的情况，如果发现某一小区话务突增而另一小区话务突减，就可以发生了这种情况，需要进行传输方面的检查。 参数设置也能控制和影响小区的容量，当小区出现拥塞而一时无法扩容时，首先可以通过调整参数来缓解。 当小区越区存在较大的覆盖时，也会很容易造成小区的拥塞，合理控制覆盖是解决拥塞的有效手段。 对于信令信道的高拥塞，首先应该检查是否处于LAC区边界，参数调整有时会有很好的效果。（3） 切换问题： 时钟不同步是造成大量切换失败的主要因素，当发现相邻小区数据正确而出大量切换失败时，有必要对基站时钟同步问题进行检查。 对于新开站或者改型站，如果出现较高的切换失败率，也可以从基站数据库中寻找原因，可以在新建数据库时出现错误。 天线接线错误也是导致高切换失败的常见原因，当发现切换请求与异常时，需要到现场检查一下天线的接线是否有误。 如果基站主控板出现故障，也会引起较高的切换失败率。 在极特殊情况下，无法切换还可能与MSC的版本不兼容有关，特别是对于不同厂家的设备，这种情况更容易发生。 小区的参数和邻区数据的设置问题，也是造成高切换失败率的主要原因，而且当有高切换失败产生，首先应该检查参数和邻区数据的设置情况。（4） 掉话问题： 不当的参数设置也会导致小区出现较高的掉话，特别是新站开通时部分接入或切换参数如果使用了默认值会对掉话产生较大的影响。 在BSC中进行基站重建或新开基站时，如果时隙分配错误，也会导致较高的掉话。 基站不正常中断，有时会引起基站数据库的丢失，当基站重启后，由于数据库不正确也会导致无法接入或较高的掉话现象。 影响掉话率最普遍的原因是覆盖问题，在弱覆盖区域产生掉话的可能性更大，对于这种情况下，加强覆盖是解决掉话的主要手段。 对于开启了跳频功能的基站，如果跳频单元出现故障，也会导致小区出现较高的掉话，常见问题是跳频BUS线有问题或者在跳频范围内的TRX出现故障。 干扰也是产生掉话的主要原因，干扰可以分为频率内部干扰和外部环境干扰，频率内部干扰一般容易发现和解决，但外部干扰查找起来会麻烦一些，需要用外部设备（如扫频仪等）来协助查找。常见的外部干扰有联通CDMA对移动低频的干扰，军工设施或频率干扰仪等。 直放站引起掉话一般有两种情况，其一是直放站本身工作不稳定，其二是直放站与载频配置不协调导致高掉话，基站扩容或减容后比较容易出现这种情况。 为了解决农村边缘地带的弱覆盖问题，在相关基站安装了塔顶放大器，用以提高上行电平信号，但同时上行干扰也随着增大，特别是当塔放出现故障时，有可能产生较强的自激干扰，从而造成高掉话，所以对于塔放的定期检查也是很有必要的。 和塔放类似的另一扩展部件是功放，它的主要功能是用来放大下行信号，同样也是为了解决边缘地带的弱覆盖问题，在使用时，要求与基站现有的TRX呈对应关系，但在扩容时，经常出现TRX容量增加而功放未增加的情况，从而导致发射功率的不均衡，产生较高的掉话。 传输如果存在故障，通常会导致较高的ABIS掉话，特别是当传输不稳定，出现连续闪断时，对掉话的影响更大，所以及时发现和解决传输问题也是控制掉话的重要环节。 其它一些硬件故障，比如载频的上级模块BB2，或者机柜备板出现故障时，都会引起载频工作的不稳定，从而导致较高的掉话，因此，当发现小区掉话较高时，检查和范围有时需要扩展到所有相关的部件。（5） GPRS问题： 在日常优化中，发现的GPRS问题主要与GPRS信道的配置、NSEI的划分有关，最常见的现象是上网速率慢，这类问题解决起来也比较容易，一般对相关小区的质量进行优化，配置进行调整后可以得到解决。（6） 其它问题： 其它的一些问题主要来源于日常用户投诉，主要体现在信号不好、无法接入、寻呼无响应、手机脱网等，不同的问题都有各自的解决方法，具体情况可以参考下面的案例分析。4 案例介绍4.1 通话质量问题4.1.1 干扰4.1.1.1 新乡塔放干扰（1）日常案例出现现象和影响描述40130（HJJIAHE）基站的上行质量近阶段一直不好，平均在93%左右，且该站存在不同等级的干扰（2）日常案例分析和解决方法与基站工程师联系后，前往现场察看，该站的塔放出现故障，将塔放关闭后，干扰随即消失，且上行质量也有所好转，达到98%左右（1） 解决前后对比4.1.1.2 平顶山基站越区覆盖导致路测质量差案例现象描述：本周对市区南环路段进行了测试，在姚孟附近路段下行质量很差，如下图：天辰公司3BCCH:76焦店3BCCH:76案例分析和解决方法：经过分析发现，天辰公司3扇区存在严重的越区覆盖现象，它的76号BCCH频点与焦店3扇区的BCCH频点在姚孟电厂附近路段产生严重的同频干扰，导致了下行质量恶化。决定对天辰公司3扇区的天线进行调整，控制其覆盖。将天辰3的天线下倾角由0度调至7度后复测，覆盖得到了有效的控制，越区覆盖现象得到了解决，同一路段的质量也有所改善。4.1.2 载频故障焦作冯营用户投诉通话质量差分析 日常案例出现现象和影响描述:焦作冯营投诉，通话过程对方听着时断时续，通话质量非常差。 日常案例分析和解决方法:根据用户的投诉，判断可能是载频的上行链路太差。观察冯营第二扇区，发现这个小区的第5、7两块载频的上行质量非常不稳定，一般都在92以下，因此建议基站工程师下站检查载频硬件。根据载频的质量，怀疑这2块载频属于性能下降，在更换后，该小区的上行质量达到了98左右，拨达测试没有发现问题。 调整前后载频上行质量对比：CellNameTRX id2005-8-242005-8-25ULQ 0ULQ 5DLQ 0DLQ 5ULQ 0ULQ 5DLQ 0DLQ 53965FENGYING2568.77%92.84%76.58%99.19%92.44%97.50%89.86%99.21%3965FENGYING2681.78%95.65%75.57%99.10%92.10%98.04%91.10%99.71%3965FENGYING2766.71%91.30%77.75%99.48%89.17%97.58%86.80%99.40%4.1.3 天馈故障4.1.3.1 许昌禹州农村小吕基站通话质量差原因：天馈驻波比高问题描述：许昌禹州农村小吕基站出现众多投诉，反映离站不到1000M的乡政府，出现通话质量差，信号电平差且信号极不稳定现象，经过现场实地勘测，确实存在该问题解决方案：首先通过ODBC提取小区KPI统计，可以发现近期掉话率明显上升，而且上下行质量有明显的下降。关闭小区跳频后，问题依然存在。发现登陆BSC网元，实时查看基站当前告警，存在7949告警，如下： XCBSC10 BCF-004 BTS-004 QUAL 2005-07-12 21:01:43.87. Alarm TRX -006 YZXIAOLV(10238) 7949 DIFFERENCE IN RX LEVELS OF MAIN AND DIVERSITY ANTENNA / TRX0C 07 02 46 06 01因此下发告警单给维护部门对小区天馈系统进行驻波比测试，并同时对合路器进行检查，后追踪反馈：是小区的天馈线和小跳线接头松动，驻波比高达1.6，可能存在信号泄露现象。前后对比：对接头重新连接后，测试驻波比正常，7949告警消失，现场测试通话质量正常，覆盖电平也恢复正常PERIOD_START_TIMEPERIOD_STOP_TIMECELL_IDNW_NAMETrafficHOFDCRDCN2005-7-12 8:002005-7-12 9:0022049YZXIAOLV15.631.16%1.14%162005-7-10 10:002005-7-10 11:0022049YZXIAOLV16.562.75%3.50%404.1.3.2 信阳用户投诉43345声音断续原因：天馈避雷器故障日常案例出现现象和影响描述7月7日，用户投诉43345小区覆盖范围内打电话时，声音断断续续，听不请对方声音，这种现象已经持续好几天了，周围的用户也有同样的现象。日常案例分析和解决方法因为该基站的数据一直都没有改过，并且该小区的频点很干静，不存在频点的干扰问题，所以不是数据的原因。由于该小区下带有一直放站，考虑到是不是直放站的问题，于是将直放站关闭，该现象仍然存在，所以不是直放站的问题，这就考虑到前几天下雨，是不是天馈系统出了问题，于是对该基站的天馈系统进行了检查，通过检查发现，该基站的天馈避雷器坏了，应该是前几天下雨打雷损坏的，于是对避雷器进行了更换，再进行拨打测试，一切正常了。解决前后对比解决后通话恢复正常，上行质量由96.54上升到98.80。4.2 拥塞问题4.2.1 硬件故障4.2.1.1 信阳基站风扇故障造成TCH拥塞原因：TRX风扇故障日常案例出现现象和影响描述通过网管数据分析发现SCYANGANG和SCHEFENGQIAO2 TCH拥塞率超过20%。日常案例分析和解决方法登陆网管系统查看SCYANGANG原配置为O5，但现网只有2块载频工作，其余3块载频均显示BLK状态，察看告警为温度过高，重启后恢复正常，但不久后又退服。判断为室温过高导致载频无法正常工作，建议用户现场检查空调是否工作或载频的风扇是否正常。SCHEFENGQIAO2情况类似。用户现场更换风扇后载频正常工作，拥塞解除。解决前后对比：解决前SCYANGANG和SCHEFENGQIAO2 TCH拥塞率超过20%，之后为0.4.2.1.2 杞县孟寨扩容引起的高拥塞和低话务（1） 日常案例出现现象和影响描述杞县孟寨最近拥塞大幅增加，严重时达50左右，为了缓解该站的拥塞对该站进行扩容，扩容后发现用户无法起呼和切换近来，其话务也突降为1ERL以下，如下表；（2）日常案例分析和解决方法由于小区是故障是在扩容后出现的，怀疑扩容造成的问题，经过现场检查，其DVGA的灯已不亮，说明该单元基本处于不工作状态，更换插槽后正常。（2） 解决前后对比如下图，插槽更换后话务恢复正常。4.2.2 传输问题4.2.2.1 商丘割接接传输接反导致小区拥塞原因：传输接反日常案例出现现象和影响描述7月30日凌晨，商丘进行BSC13入网的割接工作，本次割接将BSC9（柘城县）下部分基站割接到BSC13中，割接工作完毕后发现ZHECHENGXIANJU2拥塞情况非常严重，达到20%左右；日常案例分析和解决方法分析小区数据发现，试呼次数明显增多，较割接前增加了3倍左右，直接导致话务量拥塞，小区掉话率没有太大的变化，基站没有告警，切换正常，上下行质量良好；经过检查相邻小区的数据情况，我们发现ZHECHENGXIANJU3小区话务量比以前有所下降，在交换侧检查后发现问题出在割接工作中两个小区传输接反所致，更改后恢复正常；解决前后对比小区的TCH拥塞率明显得到改善（如图示）：4.2.3 参数设置问题4.2.3.1 增大HYS值缓解SDCCH拥塞现象：平顶山在处理超忙小区的过程中，发现市区汽修厂基站1扇区（58464）SDCCH拥塞比较严重，达到了8.2。对此小区的SD使用情况进行统计分析，发现其用于MTC,MOC和location update的比率分别为9.27%，11%，79.03%。而此基站位置也正好位于市区与郊区的LAC交界处，如图：因此通过分析可知，跨LAC区的小区重选导致location update的次数较多，是造成此小区SDCCH拥塞的主要原因。解决方法：此小区为2个载频的配置，总共已配置了4个SDCCH时隙，已无法再增加SD时隙。因此只能通过参数调整的办法，将此小区（58464）和它周围LAC号不相同的相邻小区的HYS值增加到10DB。效果： 调整后此小区的SD拥塞率由8左右降低到4左右，而用于LC的SD使用比例降低到了56，效果比较明显。4.2.4 容量问题4.2.4.1 开封半速率开启解决拥塞原因： 不能扩容日常案例出现现象和影响描述开封部分小区较为拥塞，个别小区由于某种原因不能扩容；日常案例分析和解决方法对不能扩容的小区采用半速率，可以有效的缓解小区的拥塞；解决前后对比以下是横船湾3扇区的采用半速率前后对比，可见话务大幅上升，拥塞率与切换失败率大幅降低，同时由于半速率的引入造成质量有所下降；4.2.5 边界区域原因：属于LAC边界，硬件故障导致高SD拥塞开封监狱1 SDCCH高拥塞和TCH高掉话（1） 日常案例出现现象和影响描述：28号监狱1扇区突然掉话上升，DCN为103，DCR为14.44%，同时SD拥塞高达76617次。（2） 日常案例分析和解决方法：监狱基站处于LAC边界，从SD拥塞高达76617次来看，怀疑小区SDCCH信道为所在载频所生故障，通过BSC查看，SDCCH信道所处的三块载频掉死，同时基站开了跳频，导致基站掉话大幅上升，关闭跳频，重启基站，同时通知基站班处理，指标恢复正常。（3） 解决前后对比4.2.6 覆盖问题4.2.6.1 三门峡11,464（CHENSONGPO1）高拥塞情况的解决 1/2原因：过覆盖日常案例出现现象和影响描述11,464（CHENSONGPO1）是10B新站，该站位于三门峡市区边缘的一个山上，建站目的是为了覆盖高速和铁路，该小区的规划方位角为100度，该站开通后一直拥塞，扩容后话务量增加，拥塞没有得到缓解。日常案例分析和解决方法经过实地的勘察发现此站天线方位角只有60度刚好覆盖市区，并且此站所处地从而造成吸收了很多市区的话务量。如图：该小区的由于相对市区较高，能够覆盖半个市区，因此能吸收大量的市区话务量，同时也提高了市区的干扰水平。由于该站的目标是为了覆盖高速和铁路，并不是为了吸收市区的话务量，因此我们将该站的方位角调整至100度，使它不能对市区方向，避免对市区造成负面的影响 。解决前后对比下图为天线调整后的天线分布，可以看出调整至100度后避开了对市区的干扰，同时能够减少该小区的话务量。但详细的数据仍待观察。4.3 切换问题4.3.1 基站同步问题4.3.1.1 南阳航务处（45515）切换失败率高的分析处理原因：基站不同步现象和影响描述航务处（45515）基站从7月2号开始切换失败率明显恶化，并且在7月3号又有进一步的恶化，切换失败率高达75%-80%。分析和解决方法发现航务处（45515）切换失败率比较高后，查看该基站的切换报告，发现基站（45515）同所有的邻区切换失败率都很高，只有小区内切换的切换失败率比较低，同恶化前基本上持平，怀疑是基站的同步方面的问题，检查基站告警：有8112告警，通知基站检查硬件。问题解决后切换失败率回落到正常水平解决前后对比基站故障解决后，切换失败率回到正常水平；小区内切换失败率前后浮动不大。4.3.2 基站数据库问题4.3.2.1 开封防疫站3切换失败率达到91%的问题（2） 日常案例出现现象和影响描述防疫站3，在上行质量恢复后，有7705告警，切换失败率达到91%。（3） 日常案例分析和解决方法经基站工程师检查，更换有7705告警的载频后，防疫站3的切换失败率没有太大改善，由于该站的Out Band1比例过大，BSC工程师怀疑是频点有问题，经更改频点，问题仍然存在，恢复回原先的频点，基站工程师到现场重做数据后，切换失败率恢复正常（4） 解决前后指标对比4.3.3 天馈连接问题4.3.3.1 许昌无梁基站馈线接反原因：天馈系统问题描述：无梁基站的三个扇区在切换关系上没有明显的方向性，而且切换成功率较低，现场测试无梁镇基站附近信号混乱。解决方案：首先通过ODBC提取小区KPI的切换统计，发现无梁基站的三个扇区在切换关系上没有明显的方向性，而且切换成功率较低。站外测试在二三扇区有一扇的信号。检查发现柜顶一三扇区馈线混乱，柜内联线交叉，塔上检查馈线后，发现一三扇区的出于交叉状态，两个扇区的发射都装在三扇区内。按照规范重新连接柜内外连线。前后对比：重新连接后，室外测试正常，现场测试通话质量正常START_TIMECITO_ATTTO_SUCCTO_BLOCKTO_SUCCFROM_SUCCFROM_ATTFROM_SUCC2005-7-52203410058700.00%86.57%86.55%10048692005-7-2022034108510770.00%99.26%99.26%108510774.3.4 参数设置问题4.3.4.1 商丘新建微蜂窝小区切换优化(1) 日常案例出现现象和影响描述永城新建微蜂窝新庄煤矿小区用户切换出现问题，向周围的小区不能够进行正常的切换；i. 日常案例分析和解决方法检查小区数据我们发现该小区与周围的小区都已经添加相邻的关系，不存在漏定义小区的情况，检查参数数据发现PLMN设置为4，更改其PLMN参数为17，修改后小区切换关系正常；ii. 新庄煤矿微蜂窝小区切换失败率前后对比：4.3.4.2 焦作单向切换问题：（5） 日常案例出现现象和影响描述5014和5015之间单项切换问题（2）日常案例分析和解决方法通过切换报告发现5014和5015小区之间存在单项切换关系。5014和5015是同一个基站的两个小区，从5014到5015存在800次切换，但是从5015到5014小区的切换尝试是0次。根据以往的判断，存在这样的问题只有两种可能单向和数据做错，由于他们是同一个基站的不同小区，都在同一个BSC上，因此不存在数据做错的问题，所以判断是没有添加单项邻区造成的。在添加5015到5014的邻区是发现该邻区存在，既然邻区存在，数据又准确无误，还有存在的单项切换尝试次数，好像有些想不通问题所在。通过提取该小区的所有邻区LOG文件，逐个的查看5015小区所作的邻区，最后发现这个小区做了2个5014的邻区，一个LAC是14093（错误的）一个LAC是14466（正确的）。在删除多余的邻区后，这2个小区之间的切换恢复正常。（3）解决前后对比S_BSC_IDS_BCF_IDS_BTS_IDS_LACS_CIA_LACA_CIJZBSC121717144665015140935014JZBSC121717144665015144665014时间CELLADJ_CELLATT_FROMSUCC_FROMFailureATT_TOSUCC_TOFailure2005-11-15501550147947900.5001002005-11-16501550148798740.5779678414.3.4.3 驻马店高切换失败问题原因：TSC与BCC参数配置不一致案例故障描述：1月4日发现小区平舆高杨店2（32135）的切入成功率很低，它的相邻小区向它切换的成功率都低于12，该小区的其它指标都很正常。检查该扇区告警发现它的TRX=2有7745告警，怀疑载频故障导致切换到这载频的事件都失败，更换该问题载频。但更换载频后问题依然存在，于是详细检查TRX=2的载频的参数配置。检查中发现它的TSC=1与小区的BCC=3不一致，这很可能切换到该载频时由于TSC与BCC不一致出现同步问题。解决方案：修改TSC=1为3。修改后小区切换恢复正常，其切换指标前后变化如下：日期CI切入成功率切换尝试切换成功相邻小区03-Jan-06321358.54%12411063213603-Jan-06321357.79%988773202603-Jan-06321355.95%739443238903-Jan-06321357.49%561423213403-Jan-06321359.38%480453221903-Jan-06321357.22%374272672203-Jan-06321356.61%333223242503-Jan-063213510.28%107113226603-Jan-06321356.25%9662672303-Jan-063213511.90%84103207503-Jan-06321351.47%6813224503-Jan-06321356.00%5032630003-Jan-06321358.51%474322944.3.5 基站主控板故障4.3.5.1 南阳西峡烟草局（51124）切换失败率高原因：BCF主控板故障现象和影响描述西峡烟草局（51124）从7月30号开始切换失败率异常，切换失败率高达80%多日常案例分析和解决方法西峡烟草局（51124）从7月30号开始切换失败率突然增加很多，由于西峡经常出现强干扰（政府机关开干扰器）的原因，所以开始的时候还以为是干扰原因引起，检查周围几个基站的指标都正常，可以排除外部干扰的原因，如果位外部干扰则会影响周围一片区域内的基站而不是一个基站；由于近期部分基站由于跳频的原因也出现过下行质量差，切换失败率高的现象，一般情况下关跳频后就正常，所以关掉西峡烟草局（51124）的跳频；关跳频后并没有得到改善，并且基站多块载波有7745告警，基站本身有7601和7604告警，并且小区内切换失败率变化不大，所以判断是基站硬件或者传输出问题了，通知检查基站硬件，更换主控板后告警消失，问题得到解决。解决前后对比:问题解决后切换失败率重新回到原来的水平。4.3.6 MSC版本问题4.3.6.1 商丘地区省际切换失败率高优化案例分析1) 日常案例出现现象和影响描述i. 11月份商丘与宿州边界小区出现切换成功率极低几乎为0；2) 日常案例分析和解决方法i. 与宿州交换通过电话联系后得知宿州进行了一次大的网络割接，在对OMC和交换数据进行检查后，并没有发现邻区存在定义错误；ii. 后来经省公司、Nokia与安徽移动进行了协调，多方通力合作，进行数据检查；在12月20日安徽宿州交换进行了打补丁安装，切换恢复正常，成功率由0%升至74%左右；3) 解决前后切换尝试和成功率前后对比：4.3.7 时钟偏移4.3.7.1 商丘柘城洪恩基站时钟设置有误导致切换失败高原因：时钟问题日常案例出现现象和影响描述商丘柘城洪恩基站切换失败率很高，最高时达到40%，此情况出现在7月中下旬基站被雷电将传输板击坏后，基站班更换传输板后，依旧如此；日常案例分析及解决方法提取小区话务统计数据，经过分析后我们发现，该基站三个小区切换成功率都较低（20%-40%），掉话率异常（5%）；8月9日针对此问题，随同NOKIA的BTS工程师一起前往排查，在前往基站的路上，DT路测发现其他小区无法正常向洪恩基站进行切换，测试手机在洪恩站下时，收到的却是其他基站的信号，手机无法正常地通过切换或者小区重选至洪恩基站，重启后经过小区选择可以接入洪恩基站，基站发射功率、驻波一切都正常，检查传输数据发现传输板数据有误，基站时钟设置的也不正确，纠正后再次DT测试，切换正常、小区重选恢复正常；4.3.7.2 商丘切换失败率高的优化案例分析(1) 日常案例出现现象和影响描述商丘市区外贸-1小区（15241）出现高切换失败率（70%），小区掉话及通话质量均正常，没有异常的告警情况；iii. 日常案例分析和解决方法11月16日通知商丘网络部基站班后，及时的对这一问题进行了处理，经过上站检查，发现BCF 13M时钟出现偏差，重新的调整后，小区切换关系恢复正常，目前切换失败率小于1%；（3） 解决前小区掉话次数的前后对比4.3.7.3 平舆黄庄和大孙时钟问题原因：时钟不同步（1）日常案例出现现象和影响描述平舆黄庄和大孙出现切换失败率高现象。（2）日常案例分析和解决方法平舆大孙和黄庄两个边际站切换失败率很高，严重时达到40，造成无法和相邻小区进行切换，从而造成掉话，同时也使得周围相邻小区的TCH-RF-OLD掉话偏高，查看告警，存在7616告警和7601告警，主要是PCM时钟和基站时钟不同步造成，到现场后，修改DAC参数值，将其调回2000，用频率计重新进行频率扫描，频率显示为13MHZ,观察告警，告警消失。（3）解决前后对比图为黄庄和大孙调整前后的切换失败率对比图4.4 掉话问题4.4.1 参数设置问题4.4.1.1 前梁（20349）出现高掉话在周一指标监控是发现前梁（20349）出现高掉话，但并未出现告警及干扰，且掉话几乎全部来自无线掉话，进一步分析发现该站是在周末扩容后开始出现高掉话情况，因此怀疑扩容造成该问题，但是通过对该站硬件检查后并未发现异常，而在数据分析时发现扩容后，该站话务量增长为平时的两倍， SD话务增长为平时的4倍，但切换尝试呈急剧下降趋势，并且平均覆盖距离也由原来的2.0km增加到3.4km，并且通过了解当地并无任何活动，综上考虑怀疑参数的设置方面有问题，经过检查发现该站的参数当前被置于极不合理的值上（如：RXP109db，RLT0 等），怀疑该站参数被异常重置，建议对该站数据进行重建，问题得到解决。DateCell IDSdcch Traffic BHSdcch traffic AvgTch available AvgTch traffic BHHO attempt_1 DailyMS Power in celldistance07_01203491.941.325.9613.022547731205507_022034910.855.2632.0636.19859532263607_03203499.617.264134.6194433332807_04203498.827.1436.4335.49179733332907_052034910.447.1842.330.772025323378PERIOD_STOP_TIMENAMECELL_IDNW_NAMEDCNSUCCTCH_RADIO_FAIL2005.7.6 8:00LHBSC920349QIANLIANG10310841012005.7.6 9:00LHBSC920349QIANLIANG16316331512005.7.6 10:00LHBSC920349QIANLIANG18513311772005.7.6 11:00LHBSC920349QIANLIANG15610781502005.7.6 12:00LHBSC920349QIANLIANG11210601052005.7.6 13:00LHBSC920349QIANLIANG68653662005.7.6 14:00LHBSC920349QIANLIANG77651752005.7.6 15:00LHBSC920349QIANLIANG56616522005.7.6 16:00LHBSC920349QIANLIANG12199102005.7.6 17:00LHBSC920349QIANLIANG19480162005.7.6 18:00LHBSC920349QIANLIANG14508134.4.1.2 驻马店数据配置错误造成34209小区掉话原因：参数在监控时，发现34209小区17:00到18:00的掉话高达2963次，大部分掉话是由TRANSCODER引起的，如下表所示：并有大量2993告警产生。PERIOD_START_TIMENAMECELL_IDNW_NAMEDCNSUCCTCH_RADIO_FAILTCH_TR_FAIL12-Jul-05ZMBSC1034209ZYLEIZHAI2963274202962因检查天馈系统，值班人员将该基站删除，天馈检查完毕后又增加该基站，所以首先怀疑是基站数据配置有问题，查看基站数据：发现该小区的话音信道占用的是1、3、5、7时隙，而信令配置在26、27时隙（此时对应的话务信道时隙为17、19、21、23）,造成了信令时隙和话务时隙不匹配，从而引起大量的TRANSCODER掉话。将基站数据重新配置后，基站恢复正常。下表为基站修改数据前后，掉话对比情况：PERIOD_START_TIMENAMEBTS_IDCELL_IDNW_NAMEDCNTCH_TR_FAIL12-Jul-05ZMBSC105834209ZYLEIZHAI2963296213-Jul-05ZMBSC105834209ZYLEIZHAI704.4.1.3 信阳BTS数据加错引发掉话小区案例分析（6） 日常案例出现现象和影响描述本周二早8点监控时发现SH22JU 3扇区掉话1400多次。（7） 日常案例分析和解决方法查看告警发现BSC有2993告警，通知机房查看数据，发现周一晚上，给该小区加半速率数据时，数据加错了，修改数据后10点掉话恢复正常，掉话10次左右。（3） 解决前后对比数据修改后，掉话10次左右。下表是数据修改前后的数据统计图：4.4.2 信令配置问题4.4.2.1 许昌小区23546TR高掉话分析(1) 问题描述：3月7日早许昌小区23546（CGMAOFANGCHANG3）出现TR高掉话，同时有2993告警。(2) 解决方案：表1TIMENAMECELL_IDNW_NAMETCHTrafficDCRDCNTOTALNOTE3-7 8:00XCBSC523546CGMAOFANGCHANG3160.2988.14%171194BS power decreased3-7 9:00XCBSC523546CGMAOFANGCHANG3130.26117.29%156133BS power decreased3-7 10:00XCBSC523546CGMAOFANGCHANG350.02100.00%1414Faulty TSLs locked and restarted3-7 11:00XCBSC523546CGMAOFANGCHANG371.02101.91%588577Faulty TSLs and TRX locked3-7 12:00XCBSC523546CGMAOFANGCHANG3200.0133.33%26BS power decreased3-7 13:00XCBSC523546CGMAOFANGCHANG3200.0237.50%38BS power decreased3-7 14:00XCBSC523546CGMAOFANGCHANG3200.0128.57%27BS power decreased3-7 16:00XCBSC523546CGMAOFANGCHANG3194.0317.67%56317TSLs reassigned3-7 17:00XCBSC523546CGMAOFANGCHANG3206.090.23%1435Back to normal3-7 18:00XCBSC523546CGMAOFANGCHANG3207.101.12%5448Back to normal3-7 19:00XCBSC523546CGMAOFANGCHANG3207.020.88%4455Back to normal3-7 20:00XCBSC523546CGMAOFANGCHANG3205.680.35%1282Back to normal图2（时隙分支示意）如表1所示，3月7日早发现小区23546长葛毛纺厂3扇区出现高TR掉话，检查告警发现有2个TRX同时出现2993告警。重起载频及基站后仍存在问题，紧接着锁住出现告警的时隙观察但仍旧不能解决问题，只得暂时降低基站功率减少掉话和投诉。在进行多方面的检查后突然想到这几天正在进行信令升级，是否问题出现在此。于是联系相关负责人得知此站在前天夜里确实进行了信令升级，因为此站为ULTRA站，无法远程检查如图2所示意的时隙分支表，于是派遣相关人员去站点进行检查并重新分配时隙后，在下午3点半晚忙时前小区工作恢复正常。4.4.2.2 博爱2993#伴随高掉话（8） 日常案例出现现象和影响描述3月10日早忙时，博爱JZBSC10出现高掉话扇区号为8254最高一次掉话32次。扇区内共有3块载频，其中有3块载频同时出现7745告警。（9） 日常案例分析和解决方我们检查了小区不存在干扰，再检查BSC10上的2993告警时，发现扇区存在2993告警。我们立刻通知移动公司人员检查BTS在BSC配置是否匹配，发现BSC上的数据存在问题。修改之后，基站掉话恢复正常。原因是由于移动公司人员把BTS速率从16K改为32K，而BSC未作改动，而引起。（10） 解决前后对比:4.4.3 基站数据库问题4.4.3.1 博爱西城基站基站硬件数据库丢失引起高掉话（1） 日常案例出现现象和影响描述3月8日早忙时，博爱西城基站出现高掉话扇区号为8036最高一次掉话130次。扇区内共有7块载频，其中有五块载频同时出现7745告警。（2） 日常案例分析和解决方我们检查了小区不存在干扰，