OMC故障分析案例.doc

通过分析话务报表，我们发现德清-2扇区存在很高的MC739掉话和大量的TCH分配失败MC746B，且该小区的掉话及分配失败主要集中在TRX3、TRX4及TRX5上面，对应的物理硬件编号分别为TRE5、TRE6及TRE8上面，如下图所示： 一般情况下出现MC739掉话有如下原因造成： BSC A口电路问题导致此BSC内部若干小区均出现较多的MC739掉话。 MT120模块隐性或显性故障导致该BSC内部若干小区出现较多的MC739掉话。 基站传输有误码或故障等原因，导致此传输所带的基站出现MC739掉话。 基站管理传输的SUM板模块出现故障导致MC739掉话。 载波故障或者槽位问题导致相应载波出现MC739掉话。 由于此BSC仅有德清-2扇区出现了MC739掉话，故基本排除了上述的A、B 2种原因，通过查看基站的传输链路告警信息，此基站传输一直均没有出现过误码，也基本可以排除原因C。 针对基站SUM模块可能导致的MC739掉话，我们进行了如下故障排查，更换了德清-2、3扇区所对应的SUM板模块，发现掉话依然集中在德清-2扇区的TRE5、TRE6及TRE8上面。 在排除了以上所述的前4种原因后，我们提出了更换载波的建议，由于本小区同时多载波出现MC739的概率比较低，故我们将更换载波的问题排查建议放在最后，但经过载波多次更换后，德清-2扇区依然存在很高的MC739掉话及高TCH分配失败现象。且同样出现在TRE5、TRE6及TRE8上面，更换出现高掉话载波所在的槽位问题依然没有得以解决。 在以上所有的可能原因均排查完毕且问题没有得到解决的情况下，我们尝试删创德清-2扇区的OMC数据及基站数据，删除后我们发现TRE5依然在德清-2扇区上，但TRE6及TRE8在德清-3扇区上面，通过观察后续的多个时段话务报表，MC739掉话依然发生在TRE5、TRE6及TRE8物理硬件上。如下图： 德清-2扇区掉话情况 德清-3扇区掉话情况 我们再次删创小区，此次操作我们不仅删创了OMC数据，并且更换了TSU框，结果发现德清-2、3扇区均未出现MC739掉话。故判断原TSU下的某块TCUC有问题，为了验证我的判断，我再把这个BTS割接回原来TSU下的不同ABIS端口，再看话务报告，发现这两个小区又出现高掉话和高分配失败的情况。查看RSL5、6、8对应的TCUC情况，发现这3个RSL在同一块TCUC上，我更换这块TCUC后看下一小时的话务报告，发现这两个扇区的指标均已正常。如下图所示： 更换TCUC模块后德清-2扇区指标情况 更换TCUC模块后德清-3扇区指标情况 故障总结 通过本次故障的处理，我对MC739掉话有了进一步的认识。MC739掉话除了A口掉话、传输翻转、基站硬件问题等等原因外，TCUC模块隐性故障有问题也会造成小区相应载波出现MC739掉话，通过合理的问题排查思路最终能找出问题的根源。