GSM坏小区的分析和处理思路

GSM坏小区分析和处理思路1掉话坏小区的解决思路（首先需要区分属于哪一种类型的掉话）TCH掉话，从统计上分为四块：1)BSS原因掉话，对应counter为MC14C2)传输故障掉话，对应counter为MC739（CELL,TRX110）3)切换原因掉话，对应counter为MC6214)无线链路掉话，对应counter为MC736（CELL,TRX110）1.1MC14C的掉话属于设备掉话，一般是硬件故障导致。处理流程如下：高设备掉话MC14C集中在一个载频上更换载频集中在几个载频上，TCU更换TCU调测BSC，重点SWITCH模块该BSC下，多个小区存在高设备掉话是否是否定位故障点后，通知无线设备维护中心进行处理。结合MC14C掉话情况来看，更多的是BSC级的14C掉话，即该BSC下约有60%的小区都有MC14C掉话。对于持续或反复出现此类掉话的BSC，需要协调无线中心进行解决。1.2传输故障掉话首先要区分是单载频的739掉话还是分散在多个载频上。对于非常明显是单载频引起掉话的，且掉话次数超过50次或者单载频掉话率高于5%的，应该当机立断的LOCK载频，有条件的应该马上进行现场拨测，确认是否已好。LOCK载频后指标恢复正常，此时尚不能就此确定是此载频故障而要求更换载频。至少还需要确认以下几点：1）载频优先级：是否因为此载频优先级最高而导致掉话都集中在此载频上？确认单载频故障时，应尽量保证所有载频优先级一致。即使优先级不一致，通过110报告，也应确认其他载频占用没有问题（所谓的问题可能包括：没有占用、TCH占用时长相对过短、SDC占用时长相对过长、739掉话多、TCH分配失败多：用c703-c718，差值相对过大的可能存在隐性故障），如果其他载频也存在掉话，则就基本排除载频硬件问题，而应该往上游考虑ANC或ANY的问题，因为同时多块载频故障的可能性不是很大。2）对于传输掉话，可以暂不考虑跳频方式，如果是非传输掉话，则还需要考虑是否开启了跳频方式。如果采用非跳频方式，单载频的高掉话有可能是此载频所用的频率受到导致。3）是否有告警：Abis告警最常见的包括AIS-2M、误码、FAR-END-ALARM、VSWR、帧失步，CRC告警等。Abis传输有告警，往往导致所有载频都产生739掉话。此时需要通知其他相关维护中心进行处理。对于硬件告警包括TRE硬件降级、RA相关告警、RX-TXCABLE的告警等，有硬件告警而小区指标又异常的，可以通知无线中心协助处理。（如果是SW而非HW告警，则有可能是数据错误或混乱导致，需要核查小区数据或者删创小区辅助解决）。对于多载频掉话小区，除了考虑可能的ANY/ANC/TCU故障外，也需要考虑载频优先级、跳频方式、传输告警等。而对于某BSC下多个小区出现传输掉话时，则需要考虑：（1）BSC级传输故障，需要协调无线维护中心解决；（2）查看A口时隙占用是否异常（018报告中MC750/MC751，而在“吉林移动无线分析系统”中，有非常快捷的专用A口时隙占用的查询页面），如果连续几路A口部分时隙占用都在5s左右，则肯定存在问题。需要协调无线中心处理解决，更换mt120等设备；或者协调交换，将相应时隙共同LOCK。（3）CC-CR相差过大。需要协调无线维护中心或交换解决。1.3无线链路掉话首先区分是单载频还是分散在多载频。从目前阿尔卡特设备情况来看，736掉话基本上都是由于单载频隐性故障导致，更换载频后一般都能得到解决。但是单从110报告是不能武断地确认就是单载频的隐性故障导致而要求基站中心更换载频。在确认问题前，还需要考虑是否开启了跳频；其他载频占用是否都正常；是否是因为此载频优先级最高导致都集中在此载频上，如果载频优先级相同，或者掉话就会分散到所有载频上去？如果是多载频掉话，比如6块载频的小区，掉话主要集中在其中2块载频上，LOCK这两块载频后指标恢复正常，并不能说明此两块载频有隐性故障，而且往往两块载频同时出现故障的可能性并不大。同样地，和上面确认单载频隐性故障一样，也需要考虑载频优先级；是否是因为关闭跳频导致频率干扰？这两块载频是否可能和同一ANC或ANY相连，小区是否是低损耗模式，低损耗模式则最好到现场确认硬件和天馈是否正常，天线方位角是否一致等？另外，对于多载频的无线掉话，最好结合RMS报告进行分析。可以看出上下行电平、上下行质量、路径损耗、TA值等是否正常，确认是否是覆盖过远或弱覆盖导致。此外，还可结合切换原因所占比例快速辅助问题定位，正常应该是better-cell所占比例最高，如果上下行质量切换比例相对过高，则很可能存在频率干扰，电平切换比例过高则可能存在覆盖方面的问题，需要路测确认。综上，问题定位时需要综合考虑的方面或利用的辅助手段包括：载频隐性故障、载频优先级、载频TCH占用和SDC占用时长、跳频方式、是否是ANY/ANC/TCU故障，是否有传输或硬件告警、RMS报告的分析、切换原因比例分析、A口时隙占用是否正常，CC-CR是否基本匹配，更进一步问题定位需要借助路测或信令跟踪仪的手段进行。1.4切换掉话切换掉话可以根据切换的种类分为三部分，如下：MC621（切换掉话）=MC648（跨BSC切换掉话）+MC658（BSC内切换掉话）+MC663（小区内切换掉话）。BSC内切换掉话：当BSC向手机发出切换命令handovercommand时，T3103开始计时，在BSC收到来自切换目标小区的切换完成handovercomplete或者来自源小区的切换失败handoverfailure时将T3103复位，如果handover下发后，T3103逾时仍未收到以上两条消息，则记为一次BSC内切换掉话。小区内切换掉话：小区内切换掉话与TCH分配失败无返回SDCCH类似。跨BSC切换掉话：与BSC内切换掉话类似，只是T3103变为T8。切换掉话处理流程如下：高切换掉话区分切换掉话种类小区内切换掉话参见TCH分配失败处理流程BSC间切换掉话有无BSC间信令配合问题跟踪信令确认问题处理信令配合问题小区间切换检查切换关系是否合理检查切换原因分布检查切换参数是否合理调整切换关系，切换参数分布等切换掉话恢复正常参见空中链路掉话处理调整结束是否无有小区内切换的过程和SDCCH到TCH之间的信道转换过程类似，一般出现高掉话的原因主要有载频硬件故障和上下行干扰严重。小区间的切换，首先需要检查切换关系定义是否正常，然后检查切换参数，切换门限等，另外可以通过检查180报告和实际的地理位置信息，察看实际发生的切换是否合理。如果这些均正常，说明这些切换的发生是必要的，其切换掉话主要原因还是无线链路恶化造成的。跨BSC的切换，如果涉及到跨MSC的情况，其流程较为复杂。其无线方面的分析，与小区内切换相同；切换流程方面需要跟踪信令加以确认。例如，在某种情况下，当目标小区的信道已经准备好，原小区的handovercommand已经下发，但此后由于流程原因，目标小区准备好的信道又释放了，则无论如何切换也不会成功。这其中相当一部份由于无法再返回原信道，即造成掉话。对于此类情况，可能需要联测A口，E口信令进行诊断。1.5B10版增加的掉话分析功能阿尔卡特GSM系统B10版起，在小区级的110报告中增加了对掉话原因的分析，可参考RMS报告、干扰测量进行分析。MC928ANB_TCH_DROP_CAUSE_TOO_LOW_QUALITY_UL上行质量差引起的掉话MC928BNB_TCH_DROP_CAUSE_TOO_LOW_LEVEL_UL上行电平低引起的掉话MC928CNB_TCH_DROP_CAUSE_TOO_LOW_QUALITY_DL下行质量差引起的掉话MC928DNB_TCH_DROP_CAUSE_TOO_LOW_LEVEL_DL下行电平低引起的掉话MC928ENB_TCH_DROP_CAUSE_LONG_MS_BS_DISDANCE手机距离基站过远引起的掉话MC928FNB_TCH_DROP_CAUSE_TOO_SHORT_MS_BS_DISTANCE手机距离基站过近引起的掉话MC928GNB_TCH_DROP_CAUSE_TOO_HIGH_INTERFERENCE_UPLINK上行干扰引起的掉话MC928HNB_TCH_DROP_CAUSE_TOO_HIGH_INTERFERENCE_DOWNLINK下行干扰差引起的掉话MC928INB_TCH_DROP_OTHER_CAUSES其他原因引起的掉话2．切换成功率的解决思路切换成功率也是考核网络性能的一个重要指标，通常切换成功率应保持在95%以上。切换失败主要分为两部分：切换准备失败和切换执行失败。对于切换准备失败，BSC内的原因主要有目标小区拥塞，硬件问题等。对于跨MSC的切换，涉及E口信令转换，编码方式沟通等原因，需要信令跟踪分析。以下仅对切换执行失败的主要处理流程进行说明，即针对无线切换成功率部分。切换失败处理流程如下：切切切切切切切切切切切切BSC切切切BSC切切切切切切切切切切切切切切切切切BSC切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切180切切切切切切切切切切SUM切切切切切切切切切切切切RNP切切切切切切切BCCH切切BSIC切切切切切切切切切切切切切切切切切切切切切180切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切切处理切换失败，首先区分是BSC内切换失败还是BSC间切换失败。判断方法根据110报告中的相关counter，也可以利用阿尔卡特的ARP工具直观查看。当切换执行失败主要为跨BSC间切换时，需要跟踪信令排除信令配合问题。其次，检查切换失败是切入失败还是切出失败，或者切入切出成功率均低。如果切入切出均低，一般该切入切出成功率均在75%以下，同时本小区的分配失败又不高，通常是由于BTS时钟偏移造成，更换SUM板或者更改时钟同步方式即可。工作中发现将时钟同步方式由默认的“FreeRunning”更改为“Gps/Pcmsynchronized”后便能得到解决。如果仅切入成功率低，检查180报告，该报告针对每一条切换关系进行统计，统计内容包含切换切入请求MC400，切换尝试MC401及切换成功MC402。通过检查这几个counter来确定切入失败是集中在某几条切换关系还是所有的切入都差。如果所有切换失败都差，则很可能是本小区存在隐性障碍，需要解决本小区的隐性故障。如果只有某几条切换失败较高，需要RNP核查，看是否有同BCCH，BSIC的误切换发生。如果切出成功率差，同样检查180报告，切出差是集中在某几条切换关系还是所有切换关系。对集中在某几条切出差的情况，则需要检查目标小区是否存在隐性故障。对所有切出均差的情况，需要检查小区覆盖，小区硬件性能，及上下行干扰等。3．TCH分配失败的解决思路3．1BSC级的分配失败BSC分配失败率高，首先检查是否由于某几个小区引起。如果不是，则BSC分配失败多见于181D或181E分配失败，通过018报告可以统计。其中181D是由于拥塞造成，可能是该BSC下某些小区存在严重的拥塞；181E分配失败是由于A口短时隙造成（通过处理A口短时隙解决），或者是由于无线和交换侧所定义的A口时隙状态不一致，如无线侧将部分A口LOCK而交换侧没有LOCK，则会继续分配从而造成失败，此时需要利用K1205跟踪信令，并利用compass等后台软件分析，找出定义不一致的A口时隙。BSC分配失败的处理流程如下：切切切切BSC切切切切切切切切切切切切切切切切切切切切切切切切Counter181D切切切切切切Type018切切切切切切切切切切切Counter181e切切切切切切A切切切切切切切切切切切切A切切切切切切切切切切切180e切切3．2小区的分配失败主要关注三种分配失败：无线链路分配失败（MC746b）、系统原因造成TCH准备失败和系统原因造成TCH分配失败。对于系统原因造成TCH分配失败，一般都在修改小区参数时造成，因此，一般不需要做其他操作，只需观察下一时段指标即可，一般在下一时段