OMC故障分析案例.doc

1、 通过分析话务报表，我们发现德清-2扇区存在很高的MC739掉话和大量的TCH分配失败MC746B，且该小区的掉话及分配失败主要集中在TRX3、TRX4及TRX5上面，对应的物理硬件编号分别为TRE5、TRE6及TRE8上面，如下图所示：一般情况下出现MC739掉话有如下原因造成：A、 BSC A口电路问题导致此BSC内部若干小区均出现较多的MC739掉话B、 MT120模块隐性或显性故障导致该BSC内部若干小区出现较多的MC739掉话C、 基站传输有误码或故障等原因，导致此传输所带的基站出现MC739掉话D、 基站管理传输的SUM板模块出现故障导致MC739掉话E、 载波故障或者槽位问题导致相应载波出现MC739掉话 由于此BSC仅有德清-2扇区出现了MC739掉话，故基本排除了上述的A、B 2种原因，通过查看基站的传输链路告警信息，此基站传输一直均没有出现过误码，也基本可以排除原因C2、 针对基站SUM模块可能导致的MC739掉话，我们进行了如下故障排查，更换了德清-2、3扇区所对应的SUM板模块，发现掉话依然集中在德清-2扇区的TRE5、TRE6及TRE8上面3、 在排除了以上所述的前4种原因后，我们提出了更换载波的建议，由于本小区同时多载波出现MC739的概率比较低，故我们将更换载波的问题排查建议放在最后，但经过载波多次更换后，德清-2扇区依然存在很高的MC739掉话及高TCH分配失败现象。

且同样出现在TRE5、TRE6及TRE8上面，更换出现高掉话载波所在的槽位问题依然没有得以解决在以上所有的可能原因均排查完毕且问题没有得到解决的情况下，我们尝试删创德清-2扇区的OMC数据及基站数据，删除后我们发现TRE5依然在德清-2扇区上，但TRE6及TRE8在德清-3扇区上面，通过观察后续的多个时段话务报表，MC739掉话依然发生在TRE5、TRE6及TRE8物理硬件上如下图：德清-2扇区掉话情况德清-3扇区掉话情况4、 我们再次删创小区，此次操作我们不仅删创了OMC数据，并且更换了TSU框，结果发现德清-2、3扇区均未出现MC739掉话故判断原TSU下的某块TCUC有问题，为了验证我的判断，我再把这个BTS割接回原来TSU下的不同ABIS端口，再看话务报告，发现这两个小区又出现高掉话和高分配失败的情况查看RSL5、6、8对应的TCUC情况，发现这3个RSL在同一块TCUC上，我更换这块TCUC后看下一小时的话务报告，发现这两个扇区的指标均已正常如下图所示：l 更换TCUC模块后德清-2扇区指标情况l 更换TCUC模块后德清-3扇区指标情况故障总结通过本次故障的处理，我对MC739掉话有了进一步的认识。

MC739掉话除了A口掉话、传输翻转、基站硬件问题等等原因外，TCUC模块隐性故障有问题也会造成小区相应载波出现MC739掉话，通过合理的问题排查思路最终能找出问题的根源。