拥塞问题分析流程

拥塞问题分析流程一、基本知识1、A接口概述A接口是BSC和MSC之间的接口，A接口拥塞是所有拥塞问题中最严重的，涉及A接口连接的BSC控制的所有基站，表现为：用户普遍无法打电话；所有基站的无线信令信道同时发生拥塞，通过BTS维护台查看信道状态可看到SDCCH全部占满且短时间内无缓解迹象，同时又可看到业务信道比较空闲；BSC的CPU占用率维持在较高的水平，在极短的时间内可达到80%以上甚至更高；全部或大部分A接口7号信令链路处于断开链路状态。注意：对A接口7号信令闪断或长时间中断、SDCCH动态调整和信道过载、CPU占用率过高等现象，需要冷静地根据本文指导逐步解决问题。只要处理方法得当，系统都可以顺利恢复。2、无线信道概述这里的无线信道拥塞指单纯的无线信道资源，即个别基站，非大面积的。按信道类型分主要有公用信道的PCH拥塞、AGCH拥塞和专用信道的SDCCH拥塞和TCH拥塞。一般来说，只要位置区划分合理，数据配置中寻呼信道和AGCH比例分配合理，公用信道拥塞的情况很少发生，因此本文主要介绍专用信道的拥塞问题处理。下面说的信道拥塞都指专用信道拥塞。检查是否发生了信道拥塞主要看话务统计中的信道拥塞率，如果某个小区的SDCCH或TCH拥塞率较其它小区明显偏高，则可认为发生了拥塞问题。正常情况下的忙时拥塞率不应超过5%。造成信道拥塞的原因是非常多的，主要有：位置区划分不合理；地面资源不可用导致的拥塞；确实话务量大，需要扩容；突发业务量增大，如火车路过的偏僻站点，节日聚会场合，短信息集中发送时间等；有TRX故障；有干扰造成指配信道失败。二、A接口拥塞故障定位1、确认A接口信令性能的相关话统任务是否在工作相关的话务统计任务有3个：“MTP链路性能测量”、“SCCP协议性能测量”、“BSC整体性能测量”。“BSC整体性能测量”话务统计任务的作用是观察“MSC发来寻呼请求次数”、“寻呼请求次数”、“PCH(PagingChannel)过载次数”等与寻呼量有关的指标，这是观察A接口信令流量的一个必要补充。当事故发生时，应登记一个15分钟周期的“BSC整体性能测量”，只包含与寻呼有关的几个指标。说明：BSC在任何情况下，都必须登记“MTP链路性能测量”、“SCCP协议性能测量”这两个话务统计任务。登记其中所有指标，任务周期最多为15分钟。“MTP链路性能测量”的任务对象为所有模块的所有7号链路。建议正常运行的情况下也登记15分钟周期的“BSC整体性能测量”，只包含与寻呼有关的几个指标，以便问题发生时进行分析。2、通过话统判断A接口信令负荷是否过载在很多案例中，A接口信令链路下行负荷过载都是造成链路闪断或长时间中断的主要原因。观察BSC的“MTP链路性能测量”的话务统计任务，如果某条A接口信令链路已经长时间中断，则可观察其中断前的统计结果。如果某些或所有7号信令链路的“信令链路接收占用百分比”超过40%，说明MSC向BSC下发的消息量过大(一般是寻呼消息下发过多)，造成了A接口7号信令链路下行过载。“MTP链路性能测量”话务统计结果反映的是一个话务统计任务周期内的MTP链路平均占用情况，如果是多次突发性的链路拥塞，不一定能使平均结果超标。这时如果发现“信令链路接受占用百分比”比平时高出2〜3倍或更多，并且从“BSC整体性能测量”中可看到有异常多的PCH过载，则也可认为A接口7号信令链路下行负荷异常。如果某些或所有7号信令链路的“信令链路发送占用百分比”超过40%，说明BSC向MSC上发的消息量过大，造成了A接口7号信令链路上行过载。不过这种情况很难发生。从MTP链路性能测量的其它指标中也可看到信令链路由于拥塞而发生了中断的次数，各项指标综合分析，也可知是否发生了拥塞、以及哪个方向发生了拥塞。说明：40%的链路负荷能力是一个危险的警戒线。在日常维护工作中，如果发现链路负荷超标，应积极采取措施缓解。系统正常运行中，不可能发生上行超标而下行不超标的情况；如果上下行均超标，应考虑增加链路数量；如果只有下行超标，则应通知MSC维护人员采取措施。3、A接口信令链路上行过载时的措施如果信令链路下行未发生过载，则上行也不可能过载；即使发生了下行过载，同时发生上行过载的可能性也很小。一旦发生了上行过载，可暂时关闭上行过载的链路所在模块的一些基站，待观察到“信令链路发送占用百分比”已经低于40%后，才可打开基站。4、A接口信令链路下行过载时的措施此类案例较多。信令链路下行过载的直接原因基本上都是寻呼量过大。MSC向BSC下发超量寻呼的可能原因是MSC/VLR工作异常、或者HLR工作异常、或者SMC(ServiceManagementCenter)突发性地向全网发送了超量的点对点短消息，对此BSS维护人员应立即和NSS(NetworkSubSystem)维护人员取得联系，从NSS侧找到问题的根源，并采取有效措施。当NSS的异常得到恢复、A接口信令链路也恢复后，BSS经过一段时间之后也会逐渐自动恢复正常。如果BSS所有基站的传输发生过大面积的中断，或由于其他原因使得BSS的业务中断过较长一段时间，BSS系统恢复后的十多分钟内，A接口也会有大量的消息下发造成A接口信令链路下行拥塞。这时也不必采取任何行动，系统会自动恢复。可以在A接口信令链路恢复正常后，针对单个小区打开BSC维护台的Abis接口信令跟踪，或使用信令分析仪跟踪某些小区的Abis信令，正常情况下能够看到一些完整的位置更新或呼叫流程，这就说明基站的信令信道拥塞正在解除；如果长时间都未看到任何完整的位置更新或呼叫流程，则说明基站工作异常，需要对基站进行复位。如果希望某些重要基站能加速解除拥塞，在某些特定的条件下有相应的办法：当这些重要基站有相邻的其他小区，并且这些相邻小区的拥塞已经解除，可以对这些重要基站进行复位操作，在复位的过程中使等待位置更新或呼叫的移动台能通过相邻小区完成所需的流程。如果不能满足这些条件，则不可复位基站，复位基站只会延缓拥塞的解除。可以通过拔掉部分基站的E1来加速恢复。5、信令链路未过载的措施如果发生此类情况，主要观察“SCCP协议性能测量”的话务统计结果，当发现:“发出的CR消息数”〉“收到的CC消息数”+“收到的CREF消息数”并且差别明显，同时有大量的“SCCP远端无响应”告警，则可认为MSC的信令处理发生了问题，应及时通知MSC维护人员处理。否则，先观察15分钟，同时分析BSC的告警，并观察是否有单板故障，根据具体情况决定所采取的措施。三、案例1、同频干扰引起SDCCH拥塞［现象描述］某站点SDCCH经常发生突发拥塞，异常时SDCCH的信道请求次数明显增多。［原因分析］现场跟踪信令发现：异常时，在300ms内上报了60多条信道请求，且信道请求内容完全一样。除前面几条分配信道失败外，余下的请求都被拒绝，导致拥塞。检查数据配置，发现在离拥塞A小区10km处有一B小区的TCH频点和该小区的主B频点以及BSIC都一样。分析可能是B小区上的移动台做切换接入，该移动台位于A小区和B小区之间，切入B小区比较困难，而切换接入信号被A小区解为随机接入，从而为每个信道请求分配信道，导致SDCCH拥塞。让现场更改B小区的BSIC，错开A小区的BSIC，拥塞问题消失。［规避措施］TCH的频点要错开，原则上不能使用BCCH频点集的频点。否则除了会造成以上问题外，BCCH信号也会对TCH进行干扰。2、TRX故障引起TCH拥塞［现象描述］某基站的配置为S(6/4/2),从某天开始，该基站话务统计结果显示，1小区(6载频)的TCH溢出非常严重，比如，在某天的忙时(10：00〜11：00)：TCH占用总次数为176，而其TCH溢出次数竟达到36次，拥塞率达到20%。连续观察每天该1小区24小时段的话务统计结果，发现该1小区的TCH拥塞率非常之高，一般都处在15%〜60%之间，几乎每个小时都发生拥塞率过高。发生拥塞率过高时，该小区的话务量都非常低，一般忙时只有0.8Erl左右，且同时，TCH占用遇全忙的次数为0。观察该1小区所有基带的信道状态，全部为“Idle”；获取该小区的基带和RC属性，非常正常，在维护台上看不出异常之处。［处理过程］在基站远端维护中查看BT的信道状态，初步判断出该1小区的BT4、BT5有TCH占用失败的表象。⑵闭塞BT4和BT5，同时闭塞RC4和RC5。登记一个只针对该小区的话务统计任务，含有以下一些指标：TCH占用失败次数、TCH占用请求次数、TCH拥塞率、TCH占用遇全忙次数等，话务统计统计周期为30分钟。第二天晚上去观察前一天晚上的话务统计结果，发现全天的所有时段已没有TCH拥塞，表明确实是RC4、RC5两个载频有问题。⑸解闭BT4、BT5、RC4、RC5。复位RC4(TRX4)、RC5(TRX5)，第二天查看3中所登记的话务统计结果，还有拥塞。去该基站现场插拔TRX4、TRX5，进行锁频拨打测试(在TRX4、TRX5上),仍有TCH占用失败；对TRX4、TRX5互换槽位，进行锁频拨打测试(在TRX4、TRX5上)，仍有TCH占用失败。更换TRX4、TRX5，进行锁频拨打测试(在TRX4、TRX5上)，没有TCH占用失败现象；第二天查看3中所登记的话务统计结果，已没有TCH拥塞现象，问题解决。3、传输不稳引起SDCCH拥塞［现象描述］新开BTS30,开通后SDCCH一直基本上处于全忙状态(A),TCH为(1)或(A)状态，能拨通后通话正常。观察话务统计SDCCH分配失败次数在一千次左右(忙时)。自环BIE端口指示灯有时会闪。LAPD链路故障告警和恢复告警(在一秒之内)，告警频度在十分钟左右出一次。［原因分析］造成SDCCH拥塞的常见原因如下：数据配置错误；SDCCH数量不足；⑶射频问题；无TCH或严重拥塞；传输质量问题。［处理过程］进行数据检查没有发现问题，同时在夜间与其他同型基站BIE端口对换，其他基站工作正常，该站现象依旧，可以排除数据问题和BSC侧硬件问题；由于基站距BSC较远，首先进行与传输有关的话务统计登记察看结果(传输相关)没有异常，但SDCCH话务统计依然异常；更换基站TMU、TRX现象依旧；协调客户对传输测试(同时有另外一个基站开通现象相同)，发现传输有误码，后通过逐段测试，定位在到基站传输所走一段的接入网中有一2MHz传输单板有问题，更换该单板问题解决(两基站在同一块单板)。4、大量突发位置更新引起SDCCH拥塞［现象描述］某本地网无线接通率偏低，从话务统计上分析其主要原因为少数几个站SDCCH拥塞。［处理过程］从话务统计上看，出现拥塞的小区忙时有300〜400次SDCCH占用，均为S(1/1/1)基站，每个小区均配置8个SDCCH/8信道。通常可以满足300〜400次SDCCH占用，但每个小区忙时均出现几十次SDCCH拥塞。登记相应的话务统计，发现SDCCH占用中，绝大部分为位置更新造成。结合基站所处位置，发现上述拥塞基站大部分处在铁路线两个位置区交界处，由此联想到可能是突发的位置更新导致SDCCH拥塞。为了证实上述推测，特登记五分钟话务统计，发现位置更新大部分集中在某五分钟之内。今查询列车时刻表，该时段有四到五列客车经过。列车经过时，大量的突发位置更新集中在很短的时间内进行，导致拥塞。增加SDCCH配置。［建议与总结］对于铁道线上，位置区交界处的基站，在SDCCH配置上要留适当余量。对于S(1/1/1)这种配置较小的基站，打开SDCCH动态分配。5、CIC号配置错误引起拥塞［现象描述］某局TCH拥塞率居高不下，TCH拥塞率(不包括切换)达4%。［处理过程］该网不久前曾经进行版本升级与扩容，升级之前整网TCH拥塞率较低。考虑指标恶化可能与数据修改有关，在大量的数据中要找出问题所在必须有的放矢。分析话务统计数据，取出当天忙时话务统计进行分析，发现拥塞率高的小区基本集中在BSC1的1模块，该模块控制市区大部分基站。1模块各小区拥塞率指标的恶化降低了整网指标。因此将原因大致定位到1模块。因此着重分析1模块。TCH拥塞率(不包括切换)=TCH占用失败次数(不包括切换)/TCH占用请求次数(不包括切换)，因此在话务统计数据中各小区TCH占用失败次数较多。进一步分析TCH占用失败次数多的原因时，TCH占用失败次数(地面资源不可用)占了绝大部分，说明地面资源不可用是造成1模块TCH拥塞率高的主要原因。地面资源不可用的主要原因可能在Abis或A接口电路上，需要进行检查。因为1模块下很多小区都有此现象，Abis接口同时出现故障的可能很小，需集中在A接口上的相应硬件或数据上查找问题。首先检查1模块A接口硬件，发现无故障。再检查1模块中继部分的数据配置，打开中继电路表，首先排序，再检查。发现1模块0群前32个时隙CIC编号为65535,而在中继群表中1模块0群对应电路为BSC至MSC的电路，显然CIC号配错。将其改为0〜31后再动态设定。第二天观察话务统计，发现1模块中各小区拥塞率下降，原来各小区TCH占用失败次数(不包括切换)次数大幅下降，整网拥塞率(不包括切换)由4%降为约2%。6、LAC号配置错误引起SDCCH拥塞［现象描述］某基站的2小区的SDCCH拥塞率高达4.91%，该基站为S(1/1/1)的配置，而每小区忙时TCH话务量不超过3Erl。［处理过程］⑴查看TCH、SDCCH性能测量指标，发现TCH的话务量不大，每小区忙时话务量不超过3Erl，但SDCCH的占用请求次数非常高，忙时高达3032次，话务量达到1.86Erl，拥塞率高达4.91%。SDCCH拥塞