论文部分内容阅读
如果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秒；
如果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秒；