各类型掉话分析和处理.doc

各类型掉话分析和处理 一、传输掉话——MC739 1、BSC14传输掉话 图1：BSC14掉话类型情况 上图中，我们可以看到该BSC下一个小时存在MC739掉话有1612次，一般出现这种情况，该BSC下必定有某路传输link存在故障，从而导致大量的传输掉话。 图2：018报告 通过018报告我们可以看到在BSC14下有1634次由于Equipment Failure导致的Clear Request，即掉话，该情况与我们在BSC详细报告中的情况一致。此时我们就需要去察看该BSC的018原始报告，定位出现故障的link到底是哪一条。 图3：原始018报告 上图为原始018报告，其中LINK_ID为A口的时隙号，C750为该时隙上总占用时长，C751为该时隙上的总占用次数，而其中绿底红字部分为我们计算得来的部分：其中占用时长为C750/C751，PCM即Link号，其计算方法为LINK_ID/32的整数部分，而TS为该Link上的时隙号，其值等于LINK_ID/32后的余数部分。 通过添加上述几项后，我们可以对占用时长不正常的时隙进行过滤（一般为小于10秒），经过过滤，我们发现该BSC下的1~4Link下的各TS占用时长都不正常，即该BSC下第一路HW存在故障。至此我们基本定位了故障点，后经过拔插PCM板后，该BSC下HW故障排除，传输掉话次数也恢复正常了。下图为传输掉话前后变化趋势： 图4：传输掉话前后变化趋势 2、BSC19传输掉话 下图中，我们可以看到该BSC下一个小时存在MC739掉话有729次，一般出现这种情况，该BSC下必定有某路传输link或者是某些时隙存在故障，从而导致大量的传输掉话。 图1：BSC19掉话类型情况 图6：018报告 通过018报告我们可以看到在BSC19下有738次由于Equipment Failure导致的Clear Request，即掉话，该情况与我们在BSC详细报告中的情况一致。同样地，我们就需要去察看该BSC的018原始报告，定位出现故障的link到底是哪一条或者是时隙是哪些。 图7：原始018报告 同样地，通过添加计算各时隙的占用时长、PCM号以及TS号，并且过滤不占用时长不正常的时隙，我们可以简便地定位到故障时隙为：第37路link的6和20时隙，第38路link的所有时隙，第39路link的12和26时隙以及第40路link的9和23时隙，为了避免再次发生高传输掉话，我们建议先Lock了以上link和时隙。处理后该BSC的传输掉话次数已经恢复正常，详见下图变化趋势： 图8：传输掉话前后变化趋势 二、无线掉话——MC736MC621 1、硬件原因导致无线掉话 1、载频故障导致无线掉话 Xinfenger1小区 图9：xinfenger1小区掉话类型统计 上图中，我们可以看到xinfenger1小区共有37次掉话，其中有31次为无线链路原因造成的掉话，掉话率指标也非常差。从下图中，我们可以看到掉话主要集中在trx2、3载频上，其中我们发现TRX2载频的TCH和SDCCH占用时长都不正常。 图10：小区TRX详细分析 图11：小区TCH分配失败详细分析 同时，该小区的TCH分配失败次数也相当多，分配失败率为43%以上，如上图所示。怀疑该小区某载频存在硬件故障。通过小区TRX报告，我们可以看到几乎所有的TCH分配失败次数都是集中在TRX2的载频上，因此初步怀疑TRX2对应的载频存在硬件故障，TRX报告见下图： 图12：xinfenger1小区TRX报告 因此，我们将该载频Lock，再次观察小区报告发现掉话次数和TCH分配失败次数都大大减少并且小区指标基本恢复正常，而再次Unlock该载频后观察，结果该小区又出现大量掉话和TCH分配失败次数，因而建议更换该载频。 图13：小区掉话和TCH分配失败次数变化趋势 从上图中，可以看到更换载频后，该小区的掉话和TCH分配失败次数都接近于0，指标已经恢复正常。 Xinyujianzhu1 Xinyujianzhu1小区存在高掉话现象，从话务报告中观察，该小区除了掉话相关指标较差以外，其他指标情况都比较正常，因此我们对该小区进行Abis信令跟踪以确定该小区掉话的原因，具体结果如下： 图14：TRE1电平图 图15：TRE1质量图 图16：TRE9电平图 图17：TRE9质量图 图18：TRE10电平图 图19：TRE10质量图 从上述信令跟踪结果中，我们知道该小区TRE1,TRE9,TRE10质量差，路经损耗大，建议更换TRE1，9，10对应的ANY。 图20：小区掉话次数变化情况 上图中可以看到，该小区掉话次数大大减少了，因此我们初步认为是硬件问题。 2、覆盖不佳导致无线掉话 panpie3 panpie3小区也同样存在突发性高掉话的现象，通过话