卡特小区常见故障排查.doc

卡特小区常见故障排查一. GSM方面1. TCH掉话高判断掉话原因，阿尔卡特有四类掉话（无线掉话MC736，切换掉话MC621，BSS原因掉话MC14c和传输掉话MC739）a) 无线和切换掉话高 载频硬件问题通常掉话只集中在某一块载频上，且次数比其他载频大很多，对该载频作Reset TRX操作。下个时段如果该载频依然掉话高,更换载频。 TCU硬件问题如果掉话集中在某几块载频上（4块以下），观察掉话高的载频是否属于同一块TCUC，如果是，则Reset TCUC。下个时段如果依然掉话高则更换TCUC。通常TCUC故障还会伴随相关载频TCH分配失败高。 合路器模块故障（ANY）如果掉话集中在某几个载频上（4块以下），且这些载频大多数情况下是分布在不同的TCU上。同时小区的其他载频也有不少占用但没有出现高掉话。则这些载频有可能是属于同一个ANY，进基站查看如果是则更换相关ANY。 天线接反 如果发现掉话和所有硬件都无直接关系，同时共站的另一个小区也存在一定程度的高掉话问题。同时都伴随着TCH分配失败高，则通知硬件组检查基站天线有无接成鸳鸯线。b) BSS原因掉话（MC14c掉话） 基站传输问题如果持续多个时段出现，则检查小区的历史告警，是否有传输误码告警。如果有则通知硬件组进站检查基站传输。有些隐性传输故障OMCR上不一定有传输误码告警，依然需要根据共站小区掉话情况判断是否有可能是基站传输问题。 人为操作引起在进行扩容或者改Abis复用方式时，必定会出现MC14c的掉话，这种掉话往往出现在个别扩容过的小区，且下一个时段就会自动消除。 基站传输反复基站传输闪断也会造成高14c掉话，在OMCR上能够看到相应的告警。 BSC的SWITCH平面出现故障这种情况的掉话往往分散在各个小区，掉话次数和小区的话务量成正比，且每个时段都会有，并且还会伴随少量的MC739掉话。排障方法可以通过逐个关闭BSC的SWITCH平面，并查看掉话是否消除来判断究竟是那个平面出现故障，或者对BSC进行Routine Test测试，根据结果分析可能是哪个平面出现问题，更换该平面解决。c) MC739掉话高 载频硬件问题小区级的MC739通掉话常会集中在某个载频上，Reset TRX一般可以排除故障，如果无效更换载频。 A口传输时隙故障整个BSC所有小区的MC739都比较高，则首先根据018报告，将MC750和MC751相除，该差值表示该A口时隙上每个电话的平均占用时长，如果某个时隙有故障，时长会很短。更换时隙占用时长很短的那条PCM链路可以排除故障。或者通过信令跟踪判断是哪路High Way问题。2. SDC拥塞率高 载频硬件问题如果某块载频的SDCCH占用时长特别长，可能是该载SD频资源不释放，对该载频作Reset。如果共小区的几块载频都存在这种现象，则重启相关的TCUC。3. TCH分配失败率高 MC14b过高，对于MC14b突发性地变高建议做Lock/Unlock RA； MC746高，常见的MC746突然变高是某TRE占用失败造成的，可以查看TRX报告，MC703和MC718的差值表示向某一块载频分配失败次数，重起分配失败次数高的TRX和TCUC，无效则更换相关硬件。 个别小区BSS原因的分配失败高，分配失败原因为requested terrestrial resource unavailable或者terrestrial resource already allocated，那么先确认该小区是否修改过配置。 整个BSC BSS原因的分配失败高，且分布在各个小区，018报告显示分配失败的原因是C181E（requested terrestrial resource unavailable或者terrestrial resource already allocated），可以检查018报告或者进行信令跟踪分析，是否存在某路Highway，某根PCM链路或者某些时隙占用时长异常，同时检查OMCR上是否存在某路Highway link failure，如果是，通知交换侧关闭对应的highway.也有可能是跨交换机切换的交换版本不一致导致。需要具体信令分析。 整个BSC BSS原因的分配失败高，且分布在各个小区，018报告显示分配失败的原因是C181J（BSS not equipped）,则需要进行信令跟踪确认哪些0或者16时隙交换侧定义与无线侧不一致。也有可能是无线侧Lock后，交换没有和无线同步起来，需要交换侧将相应时隙设为EBLOCK或者Ready4. 切换成功率低 切换成功率接近0%突发性切换成功率恶化时建议先RESET BTS，若不能解决，则及可能时钟偏移，建议现场更换时钟/SUM板。 基站频偏问题如果小区的切入很差，且观察到所有小区的切入都很差。则可能是基站出现频偏，更换SUM板。5. 话音信道无占用移动通信表现为小区话务量为0，或者只有切入话务没有主叫占用，则可能是基站吊死，可Reset BTS，如果依旧无效则切换一块BCCH载频。6RSL Mapping故障 话务报告中RSL占用正常，而在OMC-R的USD上看到其状态为FLT问题点在OMC-R层，此时可以通过对该RSL的BSC作HW Audit和Alarm/State Audit更新OMC-R的数据，从而正确反映现网的情况。解决方法是重起TCUC，如果无效可以开关跳频，也可以将该小区的减容至1载频再恢复成应有的载频，使得RSL和TCUC的关系从新对应一下，再无效可以删创基站解决。在对小区做过正负扩容后比较容易出现此类问题.7.TCUC负荷过高 小区的寻呼消息丢失（MC8a比同LAC的其他小区少），或者小区SDCCH占用时长变长。检查该小区BCCH所对应的TCUC下，所有载频的SDCCH数量和BCCH数量。建议一块TCUC上配置的BCCH数量不大于1个，SDCCH数量不大于4个。发现此类问题可以适当减少该TCUC上的SDCCH信道数，或者将BCCH切换到小区其他不在这个TCUC的载频上。二. GPRS方面：1上下行TBF建立成功率为零 若USD里PDCH丢失，则Reinitialize GPRS或者LOCKUNLOCK GPRS；如果无效则对该小区的GPRS功能进行删创 如载频硬件质量有问题会表现为上下行TBF建立成功率低，可以先通过TRX_PER_MARK参数更换PDCH所在的载频位置2PDCH分配成功率很低问题（如20%） 若数据量不大，且GSM无拥塞，可能为无线资源吊死，Reinitialize GPRS，再对PDCH所在载频做Reset。如果无效，可以更换PDCH所在的载频位置。 若数据量大，且GSM业务拥塞时，PDCH分配成功率变低为正常现象，解决方法可以增加MAX_PDCH_HIGH_LOAD的值，但是会增加小区的TCH拥塞。 3在割接后个别非位置区边界小区GPRS流量异常大 在割接后由于更换了小区的LAC、CI或者RAC，