ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 关于GSM系统中MSC之CP负荷过高处理的体会(转)

关于GSM系统中MSC之CP负荷过高处理的体会(转)

原创 Linux操作系统 作者:jcszjswkzhou 时间:2019-01-13 07:00:08 0 删除 编辑
某日上海MSC5之CP负荷高达110%,远高于70%的正常值。当时,负担上海任务最重的两个交换
机MSC5和MSC2的有关数据(17:00~18:00)如下:
  MSC5位置更新 240,000次左右
  MSC2位置更新 160,000次左右
  MSC5VLR用户数 81,000个
  MSC2VLR用户数 110,000个
  MSC5话务统计忙时(10:00~11:00)的位置更新数据如下:
  VLR间位置更新 75,000次左右
  VLR内位置更新 113,000次左右
  周期性位置更新 15,000次左右
  这一天,MSC2的CP负荷为87%;此外,根据九、十月份的移动电话日报表得知MSC5中VLR的用
户登记数在逐步上升,其CP负荷也日趋加重。综合分析可以得出MSC5之CP负荷过高的原因如下:
  (1)VLR登记的用户数已偏多。与MSC2相比,因市中心与郊区的话务模式差别太大,虽用户少
一点,但CP负荷已超出许多。
  (2)由于经过MSC5的高架路多及进入G5区域的流动手机多,导致MSC5的位置更新次数太高,尤
其是VLR内位置更新次数太高。
  为此,我们采取了下述的应急和根本解决问题两大步骤,以降低MSC5之CP负荷。
  应急步骤
  应急步骤有以下两种:
  (1)延长手机DETACH(不可及)时间
  手机有两种含义的DETACH,一种叫明确的DETACH,比如:手机断电、关机等;另一种叫隐晦
的DETACH,就是当手机用户在一段时间内没有任何动作时,VLR就自动将它由ATTACH状态变DET
ACH状态。这里需延长的DETACH时间是指后一种含义。我们通过在VLR内部重新设定手机ATTACH
状态进入隐晦的DETACH状态时间值,达到延长手机DETACH时间的目的。实践中,我们将MSCATT
ACH时间由720分钟缩短至360分钟,这样,手机的DETACH时间由于ATTACH时间的缩短反而延长
了。如此,在手机ATTACH状态下(MSC将对其进行定时位置更新),由于DETACH时间的变化,MSC对其进行定时位置更新的次数就减少了,随之MSC的CP负荷也相应减小,而接通率不受影响;但是,这
样做会增加MSC与BSC(基站控制器)之间的信令负荷。
  (2)提高手机登记切换电平
  切换电平由4dB提高到6dB,目的是减少小区间登记切换次数。但这样会导致处于弱信号地区
用户的通话质量下降。
  上述二项措施当MSC5CP负荷降低到适当值后还原。
  根本解决问题步骤
  根本解决问题步骤有以下两大措施。
  (1)小区合并
  MSC5有5个BSC,每个BSC有一个小区代码(lacod),现在将BSC3、BSC4、BSC5合并为一个小区代码。这样做并没有减少寻呼次数,但VLR内部位置更新次数减少了27%,SDCCH负荷减小了
14.27%,MSC负荷减小了1.8%。这表明MSC负荷主要来自VLR之间位置更新及MSC之间的切换次数,因此要从根本上解决还得割接基站,同时降低VLR位置更新次数,HLR负荷也降低。
  (2)调整基站
  将MSC5下BSC5中的基站割接到其他MSC下,这可从根本上解决CP负荷高的问题。
  实践证明解决这次GSM系统中MSC之CP负荷过高的处理方案与实施是及时、有效的,取得了预
期的效果。应急步骤实施后MSC5之CP负荷下降到85%左右,下降近10个百分点。根本解决问题之小区合并步骤实施后,MSC5CP负荷下降到75%左右,调整基站步骤实施后MSC5之CP负荷为60%,忙时位置更新次数为10万。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10294527/viewspace-125866/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2007-08-29

  • 博文量
    218
  • 访问量
    111772