GSM软交换机在话务高峰期的保障应急预案

徐瑞宏

如果CPU各模块负荷不均衡，需要进行模块间负荷调整。

如果CPU各模块负荷已经比较均衡且负荷都很高，需要进行扩容业务处理。

c、数据调整

关闭加密，鉴权次数减少直到关闭，关闭全网寻呼等，以减少信令流量。

二、典型场景分析

1 场景：大量用户同时位置更新导致C/D接口拥塞

当出现因A/Abis接口、C/D接口传输长时间中断或者呼叫处理模块重启等情况，导致较长时间的业务中断后，在系统恢复正常后，大量的用户同时位置更新，造成C/D接口严重拥塞，业务受到较大影响。

1.1 界定方法：

1） 观察是否有C/D口链路拥塞或者故障告警；

2） 观察是否存在大量的位置更新操作超时统计；

3） 观察位置管理业务测量话统，如果发现位置更新成功率显著下降，远远低于平时的指标， 并且存在大量的位置更新操作超时的统计，则确认发生C/D接口发生拥塞。

1.2 应急处理：

1） 第一时间关闭所有鉴权加密配置，减轻C/D口负荷。

2） 使用HLR HTR增强流控。

当MSC到被监控的HLR链路出现拥塞、难以到达（HTR）的现象时，MSC自动启动流控，根据拥塞情况按比例拒绝业务，达到缓解链路拥塞的目的。 MSC根据当前监控周期内的流控级别进行过滤。

流控级别：0～15级。0级为不进行流控。级别越高，被拒掉的请求越多，如级别为15级，则每16个位置更新请求中会拒掉15个，允许通过一个。MSC/VLR根据链路是否出现HTR来调整流控级别。

2 场景：寻呼成功率低

2.1 界定方法：

一般情况下，BSC每小时处理的寻呼请求次数在15-20万次以下。在BSC每小时处理的寻呼请求次数超过BSC寻呼处理能力，观察“位置区话务量测量”话统中的寻呼次数、寻呼响应次数。根据位置区和BSC的对应关系，可以计算出发向某个BSC的寻呼次数和BSC响应的寻呼响应次数。如果寻呼成功率会大幅下降，需要启动寻呼策略调整。

2.2 预防处理：

话务高峰期间，建议提前评估，针对可能存在寻呼过载的BSC，提前修改寻呼策略：

1） 关闭系统中配置的全网寻呼；

2） 调整不合理的LAI-BSC配置：

2.3 应急处理：

将部分业务比如短消息的寻呼次数减少为1次；

如果寻呼量远远大于BSC的处理能力，建议对于所有业务的寻呼都

修改为1次。

3 场景：大量短消息业务导致接通率低

3.1 界定方法：

1） 观察短消息业务测量话统，短消息的移动始发短消息试发次数，移动终接短消息试发次数的数量大量增加；

2） 观察局向出入局话统，中继局向出入局话统，接通率明显下降；

3） 观察和短消息中心连接的链路的负荷，同时观察到短消息中心的链路所在模块的CPU的负荷情况；

4） 如果短消息的试发次数数量大量增加，并且观察到接通率明显下降，进一步观察到短消息中心连接的链路的负荷有较大增长，并且到短消息中心的链路所在模块的CPU的负荷有较大增长，可以判断由于大量短消息业务导致接通率低。

3.2 应急处理：

启动业务流控，进行终结短消息的流控。

4 场景：大量呼叫处理模块WCCU过载

4.1 界定方法：

1） 观察CPU占用率测量话统；

2） 观察是否出现单板CPU过载的告警；

3） 观察各大局向的中继局向话统，分析局向话务统计情况；

4） 出现大量模块频繁过载时，分析各个流向的话务量是否正常，确定系统处于正常过载还是异常过载。

4.2 预防处理：

启动业务流控：

首先查看业务流控的话统结果，在现网话统的基础之上，综合考虑模块的CPU占用率情况，得出业务流控的合理阀值 ，进行配置。

4.3 应急处理

1） 对于正常过载，模块CPU占用率稳定在过载门限上下波动，接通话务量保持稳定，对于此类情况，建议不进行处理；

2） 对于异常过载，需要使用业务流控降低话务量，保持CPU负荷的稳定，并保证一定的接通话务量。

三、实例-四川移动某局点512实施应急保障方案后网络运行分析

1.1 512地震后采取的应急措施

地震后当天下午，试呼次数是平常的9倍，系统拥塞严重，立即采取了如下措施：

1） 关闭鉴权、加密；

2） 寻呼次数调整为1次，寻呼间隔7秒；

3） 关闭彩铃功能；

4） 打开业务流控，每个CCU模块对始发呼叫MO和接收短信SMT进行限制；MO每个模块10-15次，SMT每个模块20次；

5） 漫游号码释放时长从90秒修改为7秒；