关于对爱立信GSM系统BSC中大LAC区潜在问题的探讨.doc

关于对爱立信GSM系统BSC中大LAC区潜在问题的探讨
作者： 叶小华 Email：yxh@

一、 公共控制信道CCCH的结构
对于非混合型的BCCH信道（即SDCCH-8），一个51帧的复帧内包含9个CCCH块，而混合型的BCCH信道（即SDCCH-4）只有3个CCCH块。这些CCCH块在下行信道中由PCH和AGCH共同使用，可以通过参数设定一定数量的块只用于AGCH（爱立信参数名：AGBLK）。所以每小时可以用于寻呼的CCCH块的数量为：
1． 非混合型的BCCH信道：(9-AGBLK) × 3600 / 0.2354
2． 混合型BCCH信道：（3－AGBLK）× 3600 / 0.2354
其中0.2354是复帧的周期。
在现网中，AGBLK一般设为1，因此上面的公式计算结果分别为122300和30600。

二、 寻呼命令（PAGING REQUEST）
一个PAGING REQUEST在一个CCCH块中传送，一个PAGING REQUEST信令可以同时呼叫4个TMSI或2个IMSI，又或1个IMSI+2个TMSI。
寻呼由MSC控制，具体的呼叫策略可以有多种，包括：是否使用TMSI，是否进行二次寻呼，二次寻呼是否使用跨位置区的全局寻呼。在合肥的两个爱立信MSC中，目前的设置是不使用TMSI，开启二次寻呼，二次寻呼为全局寻呼。
同时，爱立信的BSC支持寻呼自动重传，即BSC对于收到MSC的每一个寻呼指令，都发出两个PAGING REQUEST。以合肥为例，一次呼叫就是呼叫一个IMSI，MSC将指令发给BSC后，BSC会对同一IMSI呼叫2次。因此处理一个呼叫需要一个CCCH块。

三、大LAC区潜在的问题
爱立信的BSC一向以大LAC区著称，即一个LAC中可以包含相当多的基站，BSC处理PAGING命令的能力非常强。
使用大位置区的好处在于LAC边界小区少，位置更新消耗少，可以减少SDCCH的负荷，同时降低手机用电量。但它引发的问题是：小区的PCH负荷增加，有可能产生寻呼拥塞、延迟甚至丢失。
结合第一二点可以知道，如果一个非混合型的小区，每小时处理寻呼的次数（一次寻呼和二次寻呼的总次数）超过了122300次，就回产生寻呼丢失；而对于混合型的小区，这个数字只有30600。当然，任何一个小区在任一小时也不会有这么多的用户做被叫。但是很不幸的是，当一个用户在某个小区下做被叫的时候，与这个小区处于同一LAC中的所有小区都必须发出寻呼消息。由此推断，同一LAC下的所有小区处理的寻呼消息是相同的，处理的次数等于MSC发往这个LAC的呼叫次数，这个数字是相当大的，完全有可能超过单个小区能处理的寻呼小区的极限。
以合肥BSC2为例，目前配置为1个LAC区，123个基站，353个小区，850个载频。
合肥MSC2只带有BSC2一个BSC，使用IMSI寻呼，二次寻呼使用全局寻呼，登陆用户数最高达16.9万。假设二次寻呼的比例为10％，则一个被叫业务产生的PAGING REQUEST信令为
（1 ＋ 10％）× 2 ＝ 2.2 个IMSI呼叫（乘2是因为BSC2支持寻呼自动重传）
而需要的CCCH块为：2.2/2 = 1.1。因此，对于混合型和非混合型的小区，每小时PCH可以支持的被叫业务次数最多为：
1． 非混合型BCCH信道：122300/1.1 = 111181呼叫/小时
2． 混合型BCCH信道：30600/1.1 = 27818呼叫/小时
所以，如果合肥MSC2在某个忙时PAGING的次数超过了27818这个上限，则在混合型的小区中会产生寻呼拥塞，而且肯定会有部分寻呼失。而且随着PAGING次数的增加，这些小区寻呼拥塞和丢失的现象也更加严重。对于非混合型的小区也是如此，只不过上限为111181而已。

四、实际情况
那么合肥BSC2有多少混合型配置的小区呢？寻呼次数有没有超过 它们的上限呢？意识到上面的问题后，我对合肥BSC2下小区的配置情况做了一个摸底：共有39个小区被配置为混合型BCCH信道。同时我调出了合肥MSC2自2003年以来每天24小时的历史统计数据，结果令我大吃一惊：从2003年1月以来，每天的忙时寻呼次数就一直超过50000次。其中在03年9月30日18时寻呼次数最高曾经达到146110次，04年12月24日达到127498次，目前的寻呼次数稳定在90000次左右。也就是说，从2003年以来，在这些混合型的小区中就一直存在着寻呼拥塞和丢失的现象。而当寻呼次数达到最高峰的时候，可以想象这些小区寻呼拥塞和丢失的现象是多么严重！而且从上面的计算可以知道，当寻呼次数超过了111181次时，合肥BSC2下的所有小区都会存在寻呼拥塞和丢失现象。
我立即将合肥BSC2中这39个小区改成非混合型的，尽管这些调整可能会造成部分小区的TCH和SDCCH拥塞。同时因为HFMSC2最忙时的寻呼次数早已经超过122300这个上限，我认为应该立即对HFBSC2重新规划LAC区的划分或者改用TMSI寻呼方式，以减少这种寻呼拥塞和丢失的现象，最大限度的挽回因此而丢失的话务量。

五、结论
结论是很明显的：
对于采用IMSI寻呼策略的交换机，如果某个LAC区最忙时的寻呼次数（一次寻呼和二次寻呼的总次数）超过了30600，那么在这个LAC中就不能存在混合型配置的小区，
如果寻呼次数超过了122300，就应该重新规划LAC区的划分。当然也可以考虑用TMSI进行寻呼。
对于有多个LAC区的MSC，爱立信没有针对每个LAC的寻呼次数的统计，只能根据各个LAC区下小区总的话务量来估计。

以上文字都属于我个人观点，如有错误，敬请指正。
2005-2-23