BSS拥塞故障分析与处理.doc

1、M900/M1800 基站子系统 故障分析与处理手册 BSS 拥塞类故障分析与处理i目 录第 1 章 BSS 拥塞问题处理指导书 .1-11.1 概述 .1-11.2 A 接口拥塞 .1-11.2.1 背景知识 .1-11.2.2 处理步骤 .1-21.3 无线信道拥塞 .1-51.3.1 背景知识 .1-51.3.2 分类故障定位 .1-51.4 案例 .1-81.4.1 因同频干扰导致的 SDCCH 拥塞案例 .1-81.4.2 某小区拥塞率过高 .1-81.4.3 传输不稳导致 SDCCH 高度拥塞 .1-91.4.4 大量突发位置更新造成 SDCCH 拥塞 .1-101.4.5 CIC

2、 号配错导致 TCH 拥塞率高 .1-111.4.6 LAC 号设置不当导致 SDCCH 拥塞率过高 .1-12M900/M1800 基站子系统 故障分析与处理手册 BSS 拥塞类故障分析与处理1-1第 1 章 BSS 拥塞问题处理指导书1.1 概述拥塞指各种原因导致的资源不够用而产生的冲突问题，BSS 侧涉及的拥塞资源主要分成两类：有线资源和无线资源。有线资源如 A 接口电路拥塞、Abis接口电路拥塞，主要是 A 接口拥塞， A 接口的拥塞还会伴随所有无线信令信道的拥塞；单纯的无线资源拥塞包括各类信道的拥塞，如 SDCCH 拥塞、TCH 拥塞、 AGCH 拥塞等。 Abis 接口基本不会拥塞

3、，网上也没有类似问题。本文不做讨论。本文介绍拥塞类问题的原理背景、主要表现、定位方法、常用处理手段等。由于 A 接口拥塞和单纯的无线资源拥塞情况区别比较大，本文分别描述两种问题。1.2 A 接口拥塞1.2.1 背景知识A 接口是 BSC 和 MSC 之间的接口，A 接口拥塞是所有拥塞问题中最严重的，涉及 A 接口影响的 BSC 下的所有基站，表现为：(1) 用户普遍无法打电话；(2) 所有基站的无线信令信道同时发生拥塞，通过 BTS 维护台查看信道状态可看到 SDCCH 全部占满且短时间内无缓解迹象，同时又可看到业务信道比较空闲；(3) BSC 的 CPU 占用率维持在较高的水平，在极短的时间

4、内可达到 80%以上甚至更高；(4) 全部或大部分 A 接口 7 号信令链路处于断开链路状态。注意：面对 A 接口 7 号信令闪断或长时间中断、SDCCH 动态调整和信道过载、CPU 占用率过高等现象，切不可慌张，这些只是问题的结果，而不是原因。需要冷静地根据指导逐步解决问题，只要处理得当，系统都可以顺利恢复。M900/M1800 基站子系统 故障分析与处理手册 BSS 拥塞类故障分析与处理1-21.2.2 处理步骤1. 确认 A 接口信令性能的相关话务统计任务是否正在工作相关的话务统计任务有 3 个：“MTP 链路性能测量”、“SCCP 协议性能测量”、“BSC 整体性能测量”。前两个任务的

5、目的是为了直接观察 A 接口的信令情况，应以 15 分钟为一个周期；此时“BSC 整体性能测量”话务统计任务的作用是观察“MSC 发来寻呼请求次数”、“寻呼请求次数”、“PCH 过载次数”等与寻呼量有关的指标，这是观察 A 接口信令流量的一个必要补充。当事故发生时，应登记一个 15分钟周期的“BSC 整体性能测量”，只包含与寻呼有关的几个指标。说明：BSC 在任何情况下（包括正常运行的情况下），都必须登记“MTP链路性能测量”、“SCCP 协议性能测量”这两个话务统计任务，登记其中所有指标，任务周期最多为 15 分钟，其中“MTP 链路性能测量 ”的任务对象为所有模块的所有 7 号链路。建议正

6、常运行的情况下也登记 15 分钟周期的“BSC 整体性能测量”，只包含与寻呼有关的几个指标，以便问题发生时进行分析。2. 通过话务统计判断 A 接口信令负荷是否过载在很多案例中，A 接口信令链路下行负荷过载都是造成链路闪断或长时间中断的主要原因。观察 BSC 的“MTP 链路性能测量”的话务统计任务，如果某条 A 接口信令链路已经长时间中断，则可观察其中断前的统计结果。如果某些或所有 7 号信令链路的“信令链路接受占用百分比”超过 40%，说明 MSC 向 BSC 下发的消息量过大（一般是寻呼消息下发过多），造成了 A接口 7 号信令链路下行过载。“MTP 链路性能测量”话务统计结果反映的是一

7、个话务统计任务周期内的MTP 链路平均占用情况，如果是多次突发性的链路拥塞，不一定能使平均结果超标。这时如果发现“信令链路接受占用百分比”比平时高出 2、3 倍或更多，并且从“BSC 整体性能测量”中可看到有异常多的 PCH 过载，则也可认为 A 接口 7 号信令链路下行负荷异常。如果某些或所有 7 号信令链路的“信令链路发送占用百分比”超过 40%，说明 BSC 向 MSC 上发的消息量过大，造成了 A 接口 7 号信令链路上行过载。不过这种情况很难发生。M900/M1800 基站子系统 故障分析与处理手册 BSS 拥塞类故障分析与处理1-3另外，从 MTP 链路性能测量的其它指标中也可看到

8、信令链路由于拥塞而发生了中断的次数，各项指标综合分析，也可知是否发生了拥塞、以及哪个方向发生了拥塞。说明：40%的链路负荷能力是有关标准中的规定。事实上，华为 BSC 的 7号链路负荷达到 60%也可正常工作，但此时不能保证对端 MSC 的链路不拥塞，40%是一个危险的警戒线，有关标准并未要求信令负荷能力超过这一界限。在日常维护工作中，如果发现链路负荷超标，应积极采取措施缓解。系统正常运行中，不可能发生上行超标而下行不超标的情况；如果上下行均超标，应考虑增加链路数量；如果只有下行超标，则应通知 MSC 维护人员采取措施。3. 发生 A 接口信令链路上行过载时的措施尚无此类案例。如果信令链路下行

9、未发生过载，则上行也不可能过载；即使发生了下行过载，同时发生上行过载的可能性也微乎其微。一旦发生了上行过载，可暂时关闭上行过载的链路所在模块的一些基站，待观察到“信令链路发送占用百分比”已经低于 40%后，才可打开基站。4. 发生 A 接口信令链路下行过载时的措施此类案例较多。信令链路下行过载的直接原因基本上都是寻呼量过大。MSC 向 BSC 下发超量寻呼的可能原因是 MSC/VLR 工作异常、或者 HLR 工作异常、或者 SMC 突发性地向全网发送了超量的点对点短消息，对此 BSS维护人员应立即和 NSS 维护人员取得联系，从 NSS 侧找到问题的根源，并采取有效措施。当 NSS 的异常得到

10、恢复、A 接口信令链路也恢复后， BSS经过一段时间的之后也会逐渐自动恢复正常。另外，如果 BSS 所有基站的传输发生过大面积的中断，或由于其他原因使得 BSS 的业务中断过较长一段时间，BSS 系统恢复后的十多分钟内， A 接口也会有大量的消息下发造成 A 接口信令链路下行拥塞。这时也不必采取任何行动，系统会自动恢复。可以在 A 接口信令链路恢复正常后，针对单个小区打开 BSC 维护台的 Abis接口信令跟踪，或使用信令分析仪跟踪某些小区的 Abis 信令，正常情况下能够看到一些完整的位置更新或呼叫流程，这就说明基站的信令信道拥塞正在解除；如果长时间都未看到任何完整的位置更新或呼叫流程，则说

11、明基站工作异常，需要对基站进行复位。M900/M1800 基站子系统 故障分析与处理手册 BSS 拥塞类故障分析与处理1-4如果希望某些重要基站能加速解除拥塞，在某些特定的条件下有相应的办法：当这些重要基站有相邻的其他小区，并且这些相邻小区的拥塞已经解除，可以对这些重要基站进行复位操作，在复位的过程中使等待位置更新或呼叫的手机能通过相邻小区完成所需的流程。如果不能满足这些条件，则不可复位基站，复位基站只会延缓拥塞的解除。可以通过拔掉部分基站的 E1 来加速恢复。5. 信令链路未过载的措施华为设备尚无此类案例。在所知的唯一案例中，MSC 已经近于崩溃。如果发生此类情况，主要观察“SCCP 协议性

12、能测量”的话务统计结果，当发现：“发出的 CR 消息数” “收到的 CC 消息数”+ “收到的 CREF 消息数”并且差别明显，同时有大量的“SCCP 远端无响应”告警，则可认为 MSC的信令处理发生了问题，应及时通知 MSC 维护人员处理。否则，先观察 15 分钟，同时分析 BSC 的告警，并观察是否有单板故障，根据具体情况决定所采取的措施。6. 主动了解其他 BSS 的运行情况如果有共 MSC 且共位置区的其他 BSS，现场维护人员也可了解其他 BSS 的运行情况，了解问题发生的范围对问题的定位是有好处的。如果发现多个 BSS 系统同时表现出同样的异常，不论这些 BSS 是否属于同一厂家，

13、只要不是事发前同时对所有发生问题的 BSS 做了同样的操作，则可以认为问题出在 NSS 侧，应及时向 NSS 维护人员反映情况。当上述各步骤均无效时，应及时向公司技术支持部门反映情况，寻求支援。1.3 无线信道拥塞1.3.1 背景知识这里的无线信道拥塞指单纯的无线信道资源，即个别基站，非大面积的。按信道类型分主要有公用信道的 PCH 拥塞、AGCH 拥塞和专用信道的SDCCH 拥塞和 TCH 拥塞。一般来说，只要位置区划分合理，数据配置中寻呼信道和 AGCH 比例分配合理，公用信道拥塞的情况很少发生，因此本文主要介绍专用信道的拥塞问题处理。下面说的信道拥塞都指专用信道拥塞。M900/M1800

14、 基站子系统 故障分析与处理手册 BSS 拥塞类故障分析与处理1-5检查是否发生了信道拥塞主要看话务统计中的信道拥塞率，如果某个小区的SDCCH 或 TCH 拥塞率较其它小区明显偏高，则可认为发生了拥塞问题。正常情况下的忙时拥塞率不应超过 5%。造成信道拥塞的原因是非常多的，主要有：(1) 位置区划分不合理；(2) 地面资源不可用导致的拥塞；(3) 确实话务量大，需要扩容；(4) 突发业务量增大，如火车路过的偏僻站点，节日聚会场合，短信息集中发送时间等；(5) 有 TRX 故障；(6) 有干扰造成指配信道失败。1.3.2 分类故障定位1. 位置区划分不合理 导致的拥塞详见案例 1.4.6。2.

15、 话务量导致的 SDCCH 拥塞和 TCH 拥塞原因：遇到拥塞问题首先要检查话务统计中话务量的统计，如果 SDCCH 和 TCH的话务强度都明显高出正常值，则需要扩容。还有突发业务增大导致的拥塞，如节日集会、文艺演出现场等。定位方法：检查拥塞小区的信道性能话务统计中的话务强度。解决方法：对正常话务量导致的拥塞，只能扩容基站；突发业务导致的拥塞，需要和局方说明情况，由局方决定是否扩容。此外，还可以采取一定措施缓解拥塞，如打开直接重试，将呼叫指配到其它小区的信道上，这样做的前提是拥塞小区周围有合适的邻区。3. 突发业务量增大导致的 SDCCH 拥塞原因：这样的情况多发生于铁路沿线，特别是涵洞出口处

16、的站点。因为位置偏远，一般配置容量不大，当火车经过或停靠时，大量掉网的手机会进行位置更新，M900/M1800 基站子系统 故障分析与处理手册 BSS 拥塞类故障分析与处理1-6导致 SDCCH 拥塞。还有短信息的集中发送时段如春节除夕夜，也很容易发生 SDCCH 拥塞。因为以上两种情况下信令只使用 SDCCH，不会导致 TCH拥塞，而且因为 SDCCH 拥塞，TCH 话务强度会较低。此外，位置区划分不合理，导致位置更新过多也会导致 SDCCH 拥塞。还有一种情况，是传输中断后恢复时也会造成和火车过隧道后同样的问题。此时需要先解决传输问题。定位方法：查看话务统计，SDCCH 拥塞率和话务强度都

17、很高，TCH 正常或偏低，但TCH 有占用请求。检查 LAC 配置是否合理。解决方法：对于这样的问题，是很难避免的，不过可以采取一些措施缓解拥塞。例如增加 SDCCH 的配置，打开 SDCCH 和 TCH 的动态转换等。对于位置区划分问题，需要修改配置。4. 载频故障导致的拥塞原因：当一个多载频配置的小区中的一个载频故障退出服务时，也会导致信道拥塞。定位方法：排除话务原因后，首先检查载频告警（查看单板状态为红色），如果有告警则可以肯定是载频故障；其次检查信道状态，是否有载频的信道状态为 B 或是 O，尝试解闭载频是否有效；最后，如果载频没有任何异常，但信道始终为 I，且长时间无话务，呼叫指配到

18、该载频的信道就失败，有可能是指配问题，请先按指配问题处理指导书处理，切勿直接复位载频。排除指配问题后，有可能是载频损坏或天馈连接故障，一般是上行接收通道故障。对无任何异常告警的载频，但其所在小区又存在拥塞，还可以尝试闭塞怀疑的载频，若小区拥塞问题恢复，则说明闭塞的载频有问题。解决方法：对于可能是指配问题的现象，先按指配问题处理指导书操作；对于有明确告警的故障载频进行更换，对于不能明确 TRX 故障的要先检查天馈各段连线是否正确，天馈驻波是否正常，如一切正常再更换载频验证。5. 干扰造成的拥塞原因：M900/M1800 基站子系统 故障分析与处理手册 BSS 拥塞类故障分析与处理1-7无线接口上

19、的干扰也会造成拥塞，例如在小区附近有和 BCCH 同频的 TCH信号覆盖，在此 TCH 上的切换接入会被小区解为随机接入，导致拥塞SDCCH；在某些版本接收灵敏度很高的情况，也会将干扰信号直接解为接入信号，导致 SDCCH 拥塞。定位方法：检查数据配置，是否有 TCH 频点使用了附近 BCCH 频点的情况，原则上TCH 不能使用 BCCH 频点集里的频点。检查干扰带统计是否有干扰存在。解决方法：修改数据配置，消除干扰。6. 地面资源问题导致的拥塞原因：指配信道时，如果出现 A 接口或 Abis 接口故障会导致指配失败，原因为“地面资源不可用”，同样影响到拥塞率。定位方法：检查话务统计，查出因“

20、地面资源不可用”原因导致的拥塞问题比例，然后检查 A 接口和 Abis 接口数据配置，排除地面资源问题。解决方法：修改数据配置错误，如果数据无错，则可能是连线故障，需要排除。1.4 案例1.4.1 因同频干扰导致的 SDCCH 拥塞案例问题描述：某站点 SDCCH 经常发生突发拥塞，异常时 SDCCH 的信道请求次数明显增多。原因分析：(1) 现场跟踪信令发现：异常时，在 300 多毫秒的时间内上报了 60 多条信道请求，且信道请求内容完全一样。除前面几条分配信道失败外，余下的请求都被拒绝，导致拥塞。M900/M1800 基站子系统 故障分析与处理手册 BSS 拥塞类故障分析与处理1-8(2)

21、 检查数据配置，发现在离拥塞小区 A10km 处有一小区 B 的 TCH 频点和该小区的主 B 频点以及 BSIC 都一样。(3) 分析可能是 B 小区上的手机做切换接入，该手机位于 A 小区和 B 小区之间，切入 B 小区比较困难，而切换接入信号被 A 小区解为随机接入，从而为每个信道请求分配信道，导致 SDCCH 拥塞。(4) 在实验室模拟现场配置，重现了故障，验证了问题。(5) 让现场更改 B 小区的 BSIC，错开 A 小区的 BSIC，拥塞问题消失。解决方法：修改 TCH 的频点或 BSIC。规避措施：TCH 的频点要错开，原则上不能使用 BCCH 频点集的频点。否则除了会造成以上问

22、题外，BCCH 信号也会对 TCH 进行干扰。1.4.2 某小区拥塞率过高现象描述某基站的配置为 S6/4/2，从某天开始，该基站话务统计结果显示，1 小区（6 载频）的 TCH 溢出非常严重，比如，在某天的忙时（10：0011：00）：TCH 占用总次数为 176，而其 TCH 溢出次数竟达到36 次，拥塞率达到 20%。更为严重的是，连续观察每一天该 1 小区 24 小时段的话务统计结果，发现该 1 小区的 TCH 拥塞率非常之高，一般都处在15%60%之间，并且在每天 24 小时中，几乎每个小时都发生拥塞率过高，而发生拥塞率过高时，该小区的话务量都非常低，一般忙时只有 0.8Erl 左右

23、，且同时，TCH 占用遇全忙的次数为 0。观察该 1 小区所有基带的信道状态，全部为“Idle”；获取该小区的基带和RC 属性，非常正常，在维护台上根本就看不出一丝异常之处。处理过程(1) 根据上面所述的方法中，通过在基站远端维护中查看 BT 的信道状态，初步判断出该 1 小区的 BT4、BT5 有 TCH 占用失败的表象；(2) 闭塞 BT4 和 BT5，同时闭塞 RC4 和 RC5；(3) 登记一个只针对该小区的话务统计任务，含有以下一些指标：TCH 占用失败次数、TCH 占用请求次数、 TCH 拥塞率、TCH 占用遇全忙次数等，话务统计统计周期为 30 分钟；M900/M1800 基站子

24、系统 故障分析与处理手册 BSS 拥塞类故障分析与处理1-9(4) 第二天晚上去观察前一天晚上的话务统计结果，发现全天的所有时段已没有 TCH 拥塞，表明确实 是 RC4、RC5 两个载频有问题；(5) 解闭 BT4、BT5、RC4、RC5 ；(6) 复位 RC4（TRX4 ）、RC5（TRX5），第二天查看 3 中所登记的话务统计结果，还有拥塞；(7) 去该基站现场插拔 TRX4、TRX5，进行锁频拨打测试（在TRX4、TRX5 上），仍有 TCH 占用失败；对 TRX4、TRX5 互换槽位，进行锁频拨打测试（在 TRX4、TRX5 上），仍有 TCH 占用失败；(8) 更换 TRX4、TR

25、X5，进行锁频拨打测试（在 TRX4、TRX5 上），没有TCH 占用失败现象；(9) 第二天查看 3 中所登记的话务统计结果，已没有 TCH 拥塞现象，问题解决。原因分析坏板1.4.3 传输不稳导致 SDCCH 高度拥塞现象描述新开 BTS30 基站，开通后 SDCCH 一直基本上处于全忙状态（ A），TCH为（I）或（A）状态，能拨通后通话正常。观察话务统计 SDCCH 分配失败次数在一千次左右（忙时）。自环 BIE 端口指示灯有时会闪。LAPD 链路故障告警和恢复告警（在一秒之内），告警频度在十分钟左右出一次。处理过程(1) 进行数据检查没有发现问题，同时在夜间与其他同型基站 BIE 端口对换，其他基站工作正常，该站现象依旧，可以排除数据问题和 BSC 侧硬件问题；(2) 由于基站距市区较远首先进行与传输有关的话务统计登记察看结果（传输相关）没有异常，但 SDCCH 话务统计依然异常；(3) 更换基站 TMU、TRX 现象依旧；(4) 测量传输由于由电信局来进行，报告是没有问题（由于该基站传输经过多次转接，电信测量是分段进行自己测自己一段且均为软环）；(5) 协调客户对传输测试（同时有另外一个基站开通现象相同），发现传输有误码，后通过逐段测试，定位在到基站传输所走一段的接入网中有一