1、关于对爱立信 GSM 系统 BSC 中大 LAC 区潜在问题的探讨作者： 叶小华 Email： 一、公共控制信道 CCCH 的结构对于非混合型的 BCCH 信道（即 SDCCH-8） ，一个 51 帧的复帧内包含 9 个 CCCH 块，而混合型的 BCCH 信道（即 SDCCH-4）只有 3 个 CCCH 块。这些 CCCH 块在下行信道中由 PCH 和 AGCH 共同使用，可以通过参数设定一定数量的块只用于 AGCH（爱立信参数名：AGBLK） 。所以每小时可以用于寻呼的 CCCH 块的数量为：1 非混合型的 BCCH 信道：(9-AGBLK) 3600 / 0.23542 混合型 BCCH
2、 信道：（3AGBLK） 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 中，目前的设置是
3、不使用 TMSI，开启二次寻呼，二次寻呼为全局寻呼。同时，爱立信的 BSC 支持寻呼自动重传，即 BSC 对于收到 MSC 的每一个寻呼指令，都发出两个 PAGING REQUEST。以合肥为例，一次呼叫就是呼叫一个 IMSI，MSC 将指令发给 BSC 后，BSC 会对同一 IMSI 呼叫 2 次。因此处理一个呼叫需要一个 CCCH 块。三、大 LAC 区潜在的问题爱立信的 BSC 一向以大 LAC 区著称，即一个 LAC 中可以包含相当多的基站，BSC 处理 PAGING 命令的能力非常强。使用大位置区的好处在于 LAC 边界小区少，位置更新消耗少，可以减少 SDCCH 的负荷，同时降低手
4、机用电量。但它引发的问题是：小区的 PCH 负荷增加，有可能产生寻呼拥塞、延迟甚至丢失。结合第一二点可以知道，如果一个非混合型的小区，每小时处理寻呼的次数（一次寻呼和二次寻呼的总次数）超过了 122300 次，就回产生寻呼丢失；而对于混合型的小区，这个数字只有 30600。当然，任何一个小区在任一小时也不会有这么多的用户做被叫。但是很不幸的是，当一个用户在某个小区下做被叫的时候，与这个小区处于同一 LAC 中的所有小区都必须发出寻呼消息。由此推断，同一 LAC 下的所有小区处理的寻呼消息是相同的，处理的次数等于 MSC 发往这个 LAC 的呼叫次数，这个数字是相当大的，完全有可能超过单个小区能
5、处理的寻呼小区的极限。以合肥 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/
6、1.1 = 111181 呼叫/小时2 混合型 BCCH 信道：30600/1.1 = 27818 呼叫/ 小时所以，如果合肥 MSC2 在某个忙时 PAGING 的次数超过了 27818 这个上限，则在混合型的小区中会产生寻呼拥塞，而且肯定会有部分寻呼失。而且随着 PAGING 次数的增加，这些小区寻呼拥塞和丢失的现象也更加严重。对于非混合型的小区也是如此，只不过上限为 111181 而已。四、实际情况那么合肥 BSC2 有多少混合型配置的小区呢？寻呼次数有没有超过 它们的上限呢？意识到上面的问题后，我对合肥 BSC2 下小区的配置情况做了一个摸底：共有 39 个小区被配置为混合型 BCCH
7、 信道。同时我调出了合肥 MSC2 自 2003 年以来每天 24 小时的历史统计数据，结果令我大吃一惊：从 2003 年 1 月以来，每天的忙时寻呼次数就一直超过 50000 次。其中在 03 年 9 月 30 日 18 时寻呼次数最高曾经达到 146110 次，04 年 12 月 24 日达到127498 次，目前的寻呼次数稳定在 90000 次左右。也就是说，从 2003 年以来，在这些混合型的小区中就一直存在着寻呼拥塞和丢失的现象。而当寻呼次数达到最高峰的时候，可以想象这些小区寻呼拥塞和丢失的现象是多么严重！而且从上面的计算可以知道，当寻呼次数超过了 111181 次时，合肥 BSC2
8、 下的所有小区都会存在寻呼拥塞和丢失现象。 我立即将合肥 BSC2 中这 39 个小区改成非混合型的，尽管这些调整可能会造成部分小区的 TCH 和 SDCCH 拥塞。同时因为 HFMSC2 最忙时的寻呼次数早已经超过 122300 这个上限，我认为应该立即对 HFBSC2 重新规划 LAC 区的划分或者改用 TMSI 寻呼方式，以减少这种寻呼拥塞和丢失的现象，最大限度的挽回因此而丢失的话务量。五、结论结论是很明显的：对于采用 IMSI 寻呼策略的交换机，如果某个 LAC 区最忙时的寻呼次数（一次寻呼和二次寻呼的总次数）超过了 30600，那么在这个 LAC 中就不能存在混合型配置的小区，如果寻呼次数超过了 122300，就应该重新规划 LAC 区的划分。当然也可以考虑用 TMSI进行寻呼。对于有多个 LAC 区的 MSC，爱立信没有针对每个 LAC 的寻呼次数的统计，只能根据各个 LAC 区下小区总的话务量来估计。以上文字都属于我个人观点，如有错误，敬请指正。2005-2-23
