8、 9、 10、
突发干扰导致的高SDCCH掉话请参考Abis掉话中的干扰处理过程。 屏蔽小区的SDCCH高掉话不做处理。
如果仍未恢复，可稍降基站功率，将SDCCH掉话次数降低，避免影响网络性能，并发维护工单至基站维护中心，及时修故故障。
11、 是否近期该地区或该小区有影响SD话务的试验。如有，与试验负责人沟通，权衡是否恢复参数等。
1.3.4 TCH高掉话
【观测手段】
话务网管统计表——NPMDB_V_P_严重问题小区监控表,见GSM性能指标。
【建议措施】
一般常见原因：
1. 高于100次的掉话常见由于强干扰或严重的硬件故障，查看是否有大量7744、7745等告警(ZEOL/ZERO)
2. 同时可以通过对比SDCCH和TCH的掉话率判断是各种故障导致还是人为因素导致，
当SDCCH和TCH掉话率具有相同的变化规律时，大致可认为是非人为因素导致，而如果SDCCH掉话率没有明显变化，TCH掉话率异常，则基本是由于人为因素导致，与无线网络无关。
3. 对于暂时无法修复的故障，可暂时降功率缓解，但调整功率的幅度要兼顾客户感知，
对于人为因素，可以先记录在案，待现场重要事件结束后进行分析处理。 4. 可能造成掉话的重要参数：MO/MS（主从bts）、RXP、PLMN、BAR、RLT、PMAX1/PMAX2(SEG)。 ? 掉话处理流程：
? TR掉话高
TR掉话高可通过以下方式处理：
? 如有告警2992或2993重起载频通常无效。使用如下命令查看ZAHP::NR=2993:;
ZAHP::NR=2992:;来查看是哪些站或BSC TC出现这种问题。
2993告警：一般为单个基站故障。通常伴随7745告警。
** ALARM ........ RRM_BX
(0416) 2993 BTS AND TC UNSYNCHRONIZATION CLEAR CALLS ON ABIS INTERFACE
90d 10d 06 135d 20d 4d
其中红色的90代表BTS号码，黄色的10代表载频号码，紫色的6代表时隙。 找到出问题的站后可以进行相关的操作。
? ? ?
考虑重起该载频 考虑关闭该载频 考虑关闭该时隙
同时检查trx数据是否正确，如果因工程、割接等造成trx数据时隙做错，重起是无效的。判断是BTS现场还是BSCtrx数据时隙做错,重做trx数据纠正。
? 出现2992告警时一般为BSC TC故障，现象是BSC多个BTS出现少量TR掉话，分布比
较均匀。当BSC反复出现此告警时，可以确定是BSC TC板故障，需要及时通知网优值班经理、网运集中监控中心（小号73121～73126）进行处理，并跟踪后续时段
性能。极特殊情况时，也可能不触发2992或2993，但bsc多个站有少量TR掉话，请网运集中监控中心加强监控，找到故障所在。必要时请网运技术支援中心专家协查13901112000。
2992告警：一般为BSC TC故障，现象是BSC多个BTS出现少量TR掉话，不像2993告警，单个BTS大量TR掉话。
** ALARM ........ RRM_BX
(0416) 2992 BTS AND TC UNSYNCHRONIZATION CLEAR CALLS ON A INTERFACE
12 34 56 78 90 AB CD EF GH IJ
? 通过调节BSC参数ITCF，可以对TR掉话有所缓解，建议设为最大值5。(不建议随意
调整)
? LAPD掉话高
LAPD掉话高可通过以下方式处理：
(1) 用指令ZEOL:BCF号；或ZEOH:日期时间，BCF=*；查看告警确定是否为载频退服导致，并查看相关原因，如需要更换载频或做基站硬件处理，与网优基站维护工程师合作处理。
(2) (3)
ZYMO指令查看是否存在传输误码导致传输闪断。 确定基站是否出现过断电原因造成的退服。
? A口掉话高
A口掉话可通过以下方式处理：
1、 如果A口掉话均匀分布在BSC内所有小区上，A口电路存在故障，向网运集中监控中心（小号73121～73126）反映解决。
2、 A口掉话一般都是由于跨MSC的切换引起，可检查相关切换指标和切换参数以及目标小区的工作是否正常。
? BTS以及OTHER掉话高
1、BTS掉话一般在基站告警上有所体现，基本由于基站硬件故障导致，需要与网优基站维护工程师沟通解决。
2、USER掉话由于重起基站导致，不做处理。用用指令ZEOH查看是否有人重起触发告警7710 OBJECT ADMINISTRATIVE STATE CHANGED。
? Abis掉话高
Abis掉话高可通过以下方式处理：
1、 用指令ZEOL或ZEOH，查看告警是否相关载频存在7745告警，可通过重起载频观察。如重起载频后，7745高告警仍然存在，仍然存在高掉话，可尝试锁住载频观察掉话情况，在确定由于某载频故障导致ABIS高掉话后，向网优基站维护工程师发送工单要求更换。
如朝阳二堡子DCS1（ULTRASITE）案例：相关告警，历史告警7745频繁。 BSC194 BCF-0101 BTS-0101 QUAL 2008-07-20 15:21:20.63
** ALARM TRX -008 DCYERPUZI1
(17477) 7745 CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD 02 01 00 00 00 00 00 00 00 00 00 100d
BSC194 BCF-0101 BTS-0101 QUAL 2008-07-20 15:21:20.63
** ALARM TRX -008 DCYERPUZI1
(17476) 7745 CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD 01 00 01 01 01 01 01 01 01 03 02 100d
BSC194 BCF-0101 BTS-0101 QUAL 2008-07-20 12:20:54.56
** ALARM TRX -008 DCYERPUZI1
(17445) 7743 MEAN HOLDING TIME BELOW DEFINED THRESHOLD 00 01 01 01 01 01 01 01 02 02 1d
重起TRX8后出现下面告警，且7606频繁出现：为防止trx自己频繁重起造成掉话，暂关闭TRX8,需要基站维护工程师现场检查。
BSC194 BCF-0101 BTS-0101 PROCES 2008-07-20 16:48:16.43
** ALARM TRX -008 DCYERPUZI1
(17504) 7606 TRX FAULTY Interface problems between O&M and DSP SW. 02 01 04 97 00 00
2、 结合trx质量统计查看每个TRX上分步的掉话情况。如单TRX比小区内其他trx明显掉话次数高，也说明该TRX有故障。如重起无效，需要基站维护工程师现场检查。
3、 4、
检查小区本站或它与临近站是否存在严重的同邻频干扰问题。
BSC指令ZERO查看是否小区TCH信道存在严重上行干扰，干扰处理参考如下：“RF
掉话”中干扰排查过程。
备注：由于7745告警原因重起载频时，有时重起BTS和重起载频效果不一样，可能重起BTS不能恢复，但重起载频却恢复正常，如果小区开有BB或RF跳频，也建议在锁住BTS后，对问题载频进行一次解锁操作后，再解锁BTS。 ? RF掉话高
RF掉话高常规处理方式请参考如下建议：
相关推荐：
loading