附件才33K,直接贴出来得了

这种资料 太简单了吧.

小区常见故障排查
一.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，那么先确认该小区是否修改过配置。
BSS原因的分配失败高，且分布在各个小区，018报告显示分配失败的原因是C181E（requested terrestrial整个BSC 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或者Ready
4. 切换成功率低
切换成功率接近0%
突发性切换成功率恶化时建议先RESET BTS，若不能解决，则及可能时钟偏移，建议现场更换时钟/SUM板。
基站频偏问题
如果小区的切入很差，且观察到所有小区的切入都很差。则可能是基站出现频偏，更换SUM板。
5. 话音信道无占用移动通信
表现为小区话务量为0，或者只有切入话务没有主叫占用，则可能是基站吊死，可Reset BTS，如果依旧无效则切换一块BCCH载频。
6．RSL 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或者LOCK－UNLOCKGPRS；如果无效则对该小区的GPRS功能进行删创
如载频硬件质量有问题会表现为上下行TBF建立成功率低，可以先通过TRX_PER_MARK参数更换PDCH所在的载频位置
2．PDCH分配成功率很低问题（如<20%）
若数据量不大，且GSM无拥塞，可能为无线资源吊死，Reinitialize GPRS，再对PDCH所在载频做Reset。如果无效，可以更换PDCH所在的载频位置。
若数据量大，且GSM业务拥塞时，PDCH分配成功率变低为正常现象，解决方法可以增加MAX_PDCH_HIGH_LOAD的值，但是会增加小区的TCH拥塞。
3．在割接后个别非位置区边界小区GPRS流量异常大
在割接后由于更换了小区的LAC、CI或者RAC，但没有对小区做过Reinitialize GPRS，可能会导致小区GPU内的数据（LAC、CI或者RAC）和OMCR上的不匹配（依然为原值），会导致所有用户ATTACH和RAU失败。用户反复尝试导致流量剧增。只要对该小区做Reinitialize GPRS即可恢复。该问题通过Gb口的信令跟踪更容易发现。

直接贴出来了，各位c友阅知，呵呵