BSC无线话务高峰预防及应急措施

A9130 BSC无线话务高峰预防及应急措施
对于无线网络而言，节日期间由于话务流量及话务类型的变化，会导致其话务模型与平常情况下的话务模型有所差别，对无线网络各网元造成一定的影响。

以下将基于ALCATEL GSM BSS系统，分析上述变化对ALCATELA9130 BSC无线网络造成的影响，并提出初步的解决方案。

▼网络话务量增长以及短消息业务的激增引起的信令负荷增加的分析：
1）针对话务增长的分析。

由于元旦，春节网络话务量会较平时有所变化，小区TCH负荷需要进行适当的考虑。

针对TCH话务量的增加，可以通过考查TCH负荷（查ERLANG B表），根据需要增加载频。

但是值得注意的是：在作扩容分析时，必需同时考虑到BSC区域所承载的总体话务量增加情况，是否处于ALCATEL A9130 BSC配置所能承受的范围之内，如果确有必要，则可调整BSC 配置，具体可参考以下BSC配置(基于软件的版本B10)。

Alcatel A9130 BSC配置表
以下分析和预警应对措施基于现场依照Alcatel无线系统对应版本及产品预设计部门的Dimension rule进行配置。

2）针对信令负荷增长的分析。

鉴于A9310BSC继续沿用了A9120BSC的应用层设计，所以在现有配置下每个TCU还是建议最多配置32个SDCCH （NON-COMBINED BCCH 的权重相当于8个SDCCH，COMBINED BCCH 的权重相当于4个SDCCH），这条规则保证了在正常话务的情况下，TCU进程的平均负载保持在正常水平。

一般对于一个映射了若干个CELL 的TCU进程来说，如果其TCH 的平均利用率不会超过80%，SDCCH上的平均利用率也就不超过60%。

但对于一个较大的CELL，映射了32个SDCCH的TCU进程上的负载可能会高，导致在TCU进程上的短暂的负载峰值的出现，此时会触发针对SDCCH的过载保护机制。

实际上对于小的小区（4个TRX或者更少），TCU进程有能力处理更多的SDCCH，或者如果TCU进程上映射每个小区都可能成为LOCATION AREA 的边界时，也可以多配置一些SDCCH。

﹡注：以上SDCCH均指SDCCH子信道。

由于元旦，春节短消息业务激增，特别是群发短消息的存在，使得网络PAGING消息的量增加，PCH信道负荷上升。

这样网络的PAGING容量是否能够承载节日话务高峰就成为一个必须考虑的问题。

以下就Paging在ALCATEL GSM系统中各接口的限制，以及其对ALCATEL无线网元的影响做出分析：
1) Paging在GSM系统中各接口的限制
空中接口（Air Interface）
Paging主要是通过CCCH信道中的PCH信道来传送系统对被叫用户的寻呼。

CCCH信道包括PCH信道和AGCH信道，以BLOCK
为单位。

Panging BLOCK和AGCH BLOCK的数目有Combined和Not Combined两种模式，参数BS_AG_BLK_RES决定两者的数目，两者BLOCK之和为3或9。

在alactel默认的情况下：
- 在Combined模式下Paging BLOCK和AGCH BLOCK的数目分别为2和1；
- 在Not Combined模式下Paging BLOCK和AGCH BLOCK的数目分别为5和4。

根据如下PCH和AGCH信道容量的计算方法，得到小区所能支持最大Paging消息数。

Paging容量 =(每个Paging blocks所能同时呼叫用户数×一个复帧中Paging blocks的数目)÷每个复帧的时长(秒)，
其中每个Paging blocks所能同时呼叫用户数取决于Paging request type, 共有三种类型，如下：
Paging request type1 同时Paging2个用户（IMSI或TMSI）
Paging request type2 同时Paging3个用户（2个IMSI，1个TMSI）
Paging request type3 同时Paging4个用户（4个TMSI）
每复帧寻呼组可以传送4 个TMSI寻呼或2个IMSI寻呼.1个TMSI寻呼占1个寻呼组的1/4，1个IMSI寻呼占1个寻呼组的1/2,网络系统中，若有约20%的寻呼次数采用IMSI寻呼方式，80%的寻呼次数采用TMSI寻呼方式，那么可以计算出:每100个寻呼中包括80个TMSI 寻呼方式和20个IMSI寻呼方式，则每100个寻呼所需的寻呼组数目为：
80×1/4+20×1/2=30。

所以，每寻呼组的寻呼数为：100÷30=3.33
可以理解为，每寻呼组可以寻呼到3.33 个手机。

如下表可以计算出不同信道结构时的寻呼次数。

在Not Combined下系统的空口的安全值是最大值的70％，也就是180000次每秒。

A接口（A Interface）上的paging限制
对于A9130 BSC的paging容量限制只取决于TRX的配置数量，实际上是Erlang的容量。

它不取决于是否使用HSL高速信令（使用HSL高速信令模式只是强制使在1000TRX配置下系统支持4500Erlang，如果用户不想支持4500Erlang的话可以使用传统信令LSL模式）；
它不取决于是否使用多Muti CCCH，Muti CCCH只是增加空口处理paging的能力；
具体数据如下：
- 在600 TRX配置下2700 Erlang：
72 paging/s max，所以BSC系统最大paging量是259200每秒。

系统安全值是最大值的75％，为194400每秒。

- 在800 TRX配置下3600Erlang：
96 paging/s max，所以BSC系统最大paging量是345600每秒。

系统安全值是最大值的75％，为259200每秒。

- 在1000 TRX配置下4500 Erlang：
121 paging/s max，所以BSC系统最大paging量是435600每秒。

系统安全值是最大值的75％，为326700每秒。

根据以上分析，可得出以下结论
1）A9130 BSC在B9/B10版本系统在600 TRX配置下：72 paging/s，所以BSC系统最大paging量是259200每秒。

系统安全值是最大值的75％，为194400每秒。

2）A9130 BSC在B10版本系统在1000 TRX配置下（无论使用HSL还是双CCCH）：121 paging/s，所以BSC系统最大paging量是435600每秒。

系统安全值是最大值的75％，为326700每秒。

▼ Alcatel GSM BSC模块负载情况的监控及应对方案：
由于ALCATEL的BSS系统是基于分布式系统的设计概念，processor是分布在每个模块上的，它将由于某一processor 的过载退服而引起整个网络瘫痪的风险将到了最低．因此对如此多数量的processor中的一块进行负荷检测并无多大意义．所以我们就模块负载的情况作出分析和相应的应对方案。

在ALCATEL相关设备的负荷推荐值是:
A接口的信令平均负荷安全阀值：0.4 Erlang
ABIS 链路上的平均负荷安全阀值：78 %
OMCP模块的CPU负荷阀值：80%
CCP模块的CPU负荷阀值：80%
TP模块的CPU负荷阀值：80%
以上3种模块的各级别的负荷监控是通过系统软件自动完成的，也可以Linux下的top命令进行监控；其中TP模块的负荷监控最为重要。

A9130 BSC上CCP，OMCP，TP模块的负荷监控：
【CCP板子的CPU Load】
CCP板负责BSC的电信控制，每一个CCP板最多支持200全速率的GSM TRX。

在9130 BSC中，Alcatel在CCP板上采用了高性能的CPU，完全具备处理200 TRX的能力。

基于目前从Alcatel实验室得到的负载测试数据，在Alcatel Nominal Callmix模型下, 在话务量达到2600 Erlangs以及600 TRX时，CCP板子的CPU LOAD 低于80%。

当CCP板子上的CPU LOAD低于80%的时候，系统都是绝对安全稳定的。

Alcatel为了保障产品在任何情况下都安全可靠地运行，在系统中提供了自动过载保护机制，主要应对突发的话务高峰的冲击。

其工作原理是：当CCP板子的CPU LOAD大于80%时，BSC系统开始实时监控这块CCP板子上所有消息队列，如果这些消息队列中堆积了过多未被及时处理的消息时，BSC系统会激活Overload保护机制，对应措施是逐步限制部分小区中部分手机的呼叫请求，保证系统安全，直至Overload的情况消失。

这种机制能够及时保护系统在异常高话务冲击下的稳定运行，而且不会对已接通的产生影响。

【TP板子的CPU Load】
TP板子在9130 BSC中主要负责BSC Application的传输处理功能。

所有9130 BSC和MSC之间, BSC和BTS之间, BSC和MFS之间交互的消息都是从TP板子进出的。

基于目前从Alcatel实验室得到的负载测试数据，在Alcatel Nominal Callmix模型下, 在话务量达到2600 Erlangs以及600 TRX时，TP板子的CPU LOAD低于80%。

当TP板子上的CPU LOAD低于80%的时候，系统都是绝对安全稳定的。

Alcatel为了保障产品在任何情况下都安全可靠地运行，在系统中提供了自动过载保护机制，主要应对突发的话务高峰的冲击。

其工作原理是：当TP板子的CPU LOAD大于80%时，BSC系统会立即激活Overload保护机制，对应的措施是限制整个BSS 系统下的部分手机接入系统，直到CPU Overload的情况消失。

【OMCP板子的CPU Load】
OMCP主要处理BSC的O&M。

基于目前从Alcatel实验室得到的负载测试数据，在Alcatel Nominal Callmix模型下, 在话务量达到2600 Erlangs以及600 TRX时，OMCP板子的CPU LOAD低于80%。

当OMCP板子上的CPU LOAD低于80%的时候，系统都是绝对安全稳定的。

Alcatel为了保障产品在任何情况下都安全可靠地运行，在系统中提供了自动过载保护机制，主要应对突发的话务高峰的冲击。

其工作原理是：当OMCP板子的CPU LOAD大于80%时，BSC系统开始实时监控这块OMCP板子上所有消息队列，如果这些软件进程的消息队列中堆积了过多未被及时处理的消息时，BSC系统会激活Overload保护机制，对应的措施是限制整个BSS 系统下的部分手机接入系统，直到CPU Overload的情况消失。

Alcatel BSC系统CPU负荷过载应急应对措施
在A9120/A9130 BSC系统CPU超过安全阀值并触发了系统Overload机制后，同时可以通过3阶段逐步采用以下方式进一步减轻系统负荷：
准备工作
1）开启用户优先接入功能，确保重点用户的优先接入；
EN_TCH_PREEMPT=ENABLE
EN_EDR=ENABLED
2）开启小区动态SDCCH功能；确保信令拥塞时可以扩充SDCCH信令信道；
3）对重点小区开启半速率功能；
限制用户呼叫
1）话务分流（如降低BSC/LAC边界小区的功率，将话务向周围低负荷BSC/LAC分流，降低(LAC)寻呼量负荷、降低(BSC)话务负荷、降低N7信令负荷）
2）无线侧开启ACC（接入控制级别）分级功能，通过对用户级别逐步分集限制接入；
3）无线侧开启的限呼功能；通过小区的ACCESS Barring功能限制呼叫进入，确保切换进入；
4）在现场已经无法正常发起呼叫时，为确保核心网设备安全，将长期话务溢出的基站关闭；
紧急扩容
1）A9130BSC通过在线扩容CCP模块达到快速扩容的目的（需版本支持）；
2）A口紧急扩容；
3）基站紧急扩容；
A接口的信令负荷过载
网维人员应该检测A接口的信令负荷，可以通过信令统计的方式,或者在OMC_R中的功能中察看相关DTCC的负荷。

系统菜单：BSSUSM ------> USD ------> A Interface．
﹡注：由于此图为机房测试环境，所以有效值均为0，实际值以现场数据为准。

当A接口的信令负荷过高（每条链路超过0.6ERLANG，网络性能会严重退化）。

采取的措施可以是：
1 ) 调整PCH和AGCH配置数目
2 ) 增加LAC，减少Paging消息
3 ) 增加A接口7#信令链路数
4 ) 调整MSC参数，减少Paging重发次数（应急措施）
5 ) 增加A接口链路的数量（一个BSC最多拥有16条七号信令链路）。