GSM移动通信LAC区划分及分析.docx

GSM移动通信LAC区划分及分析.docx

《GSM移动通信LAC区划分及分析.docx》由会员分享，可在线阅读，更多相关《GSM移动通信LAC区划分及分析.docx（9页珍藏版）》请在冰豆网上搜索。

GSM移动通信LAC区划分及分析

GSM移动通信LAC区划分及分析

一、简介

   良好的寻呼性能对于所有手机用户是否能够成功作被叫来说十分重要。

这份文档主要分析了我省LA位置区的寻呼性能——寻呼成功率及承载能力，并针对问题LAC提出了规划调整方案。

寻呼性能分析主要评估了我省现网69个LA位置区的寻呼成功率及寻呼负荷，同时给出一些BTS寻呼容量及负荷的计算。

此外，针对我省LAC现状提出适当调整方案及今后的规划建议。

   二、背景

   目前全省市场资费调整，全网话务量急剧增加，网络容量滞后于实际话务量的增长，网络容量问题突出暴露。

由于LA话务量增长迅速，且部分地区LA划分不均衡，使得这些LA下的BTS寻呼负荷及BSC负荷过高，导致手机无法被成功寻呼。

我省郑州、商丘、开封等地曾出现过由于BTS寻呼负荷过高，当大量短信群呼时，对网络造成巨大冲击，大量用户打不成电话，给我们的网络带来了较大损失。

因此，LAC的规划问题目前已突出暴露出来，将LAC的优化及规划提上紧急日程已毋庸置疑!

   LA代表一个位置区域，主要有以下两项功能：

1、在此区域内，网络发起对某个手机的呼叫，此区域内所有的基站都会进行寻呼，因此假如一个LA涵盖的基站数过多，用户数过多，大量的寻呼将导致BTS寻呼负荷过载。

2、手机进入一个新的LA服务范围内，必须发起请求，更新HLR及VLR内的位置记录，因此网络的LA数过多，会造成手机频繁的位置更新，浪费相应的信令资源。

   三、BTS寻呼容量的相关参数设置

   1、寻呼原理分析

   当一个手机被寻呼时，MSC就会通过BSC向对应LAC范围内的所有基站发出寻呼请求。

一个LA可能涵盖数十个甚至数百个小区，所以发至BSC的寻呼信息数量可能会很惊人。

由于BTS必须通过有限的PCH信道向手机发送寻呼请求，因此，过大的LA可能导致BTS的寻呼负荷过载，结果造成信令拥塞及寻呼信息丢失。

   根据GSM的规范，CombinedBCCH/SDCCH小区，每个复帧传送3个寻呼组，而Non-CombinedBCCH/SDCCH小区,每个复帧传送9个寻呼组。

寻呼组可作为寻呼信道（PCH）用来广播寻呼请求，同时也可作为接入授权信道（AGCH）用来回应手机的接入请求（即分配SDCCH）。

操作上，可将数个复帧组合在一起，形成一个寻呼周期，增加小区内的寻呼组数量。

手机会周期性地监听所属的寻呼组，于是当手机作被叫时，会监测到基站发送的寻呼请求，并做出回应。

   寻呼组设置较多意味着手机在监测到正确的寻呼组之前需要等较长时间，这样会增加寻呼的时间。

   寻呼组设置较少会由于手机较为频繁地接听寻呼组而缩短呼叫建立时长，缺点是手机会很费电。

   2、寻呼组设置

   我们可以设置每个小区的寻呼组的数目，两个参数决定了一个小区寻呼组的数量。

这两个参数是：

   NumberOfBlocksForAccessGran、BS_AG_BLKS_RES（0...7）、noOfMultiframesBetweenPaging,BS_PA_MFRMS（2...9）。

   以下NumberOfBlocksForAccessGrant简写为AG，noOfMultiframesBetweenPaging简写为MFR。

   ·CombinedBCCH/SDCCH小区–AG=0...2，而Non-CombinedBCCH/SDCCH小区–AG=0...7，若使用CBCH，则AG=1...7。

这个参数定义了每个复帧内AGCH专用的寻呼组数量。

它可以设成AG=0（即没有专用的AGCH，所有的寻呼组由PCH和AGCH共享。

）或AG>=1（即保留寻呼组作为AGCH专用信道）。

用于AGCH的寻呼组数量取决于小区话务量。

由于我省并未启用CBCH功能，并且在NokiaGSMBSS9中，若没有保留AGCH的情况下，AGCH的优先级高于PCH，因此尽管有需求，也可以将AG设为0。

   ·MFR（2..9）:

这个参数定义了BTS的寻呼周期,即同一寻呼组传送寻呼请求的时间间隔。

例如：

MFR=9的意思是每一寻呼组，以每9个复帧的周期重复一次。

也就是说属于某一特定寻呼组的手机，必须每9个复帧监听一次，也就是说监听间隔时间大约是2.1秒（9*235.4ms）。

   AG，MFR以及寻呼组的数量三者之间的关系如下：

   以我省个别地市为例计算小区寻呼组的数量

   1）CombinedBCCH/SDCCH小区：

   AG=2

   MFR=5

   寻呼组数量=（3-AG）*MFR=5个寻呼组

   2）Non-combinedBCCH/SDCCH小区：

   AG=2

   MFR=5

   寻呼组数量=（9-AG）*MFR=35个寻呼组

   四、BTS寻呼容量的计算

   考虑到SDCCH拥塞，一些小区配置为combinedBCCH/SDCCH，但将BCCH/SDCCH改为combined后会减少每复帧周期的寻呼组的数量。

如上计算，若使用non-combined，寻呼组的数量为35，而用combined时只有5个寻呼组。

以下主要针对combined配置进行深入分析。

   BTS通过寻呼组广播寻呼请求。

下面是一个寻呼请求可能的配置：

   ·2IMSIs

   ·1IMSIand2TMSIs

   ·4TMSIs

   对于现网中部分分公司设置的CombinedBCCH：

每个复帧有3个寻呼组（235ms）,若AG=2，

   每秒寻呼组的数量为：

（2个AGCH->1个PCH）

   =1个PCH/0.235（每复帧）

   =4.25个寻呼组/秒[1]

   每复帧寻呼组可以传送4个TMSIpages或2个IMSIpages。

假设25%用于IMSI，且没有全网寻呼，每复帧寻呼组的寻呼数为：

   1TMSI寻呼占一个寻呼组的¼，1IMSI寻呼占½。

   4个寻呼（100%）=75%（TMSI）+25%（IMSI）

   =3*¼+1*½

   =5/4（所需寻呼组）

   所以，估计每寻呼组的寻呼数为：

   4/（5/4）=3.2[2]/即每寻呼组可寻呼3.2个手机/

   因此，对于CombinedBCCH/SDCCH小区，若AG=2,则每秒的寻呼数为：

   4.25（寻呼组/秒）*3.2（寻呼数/寻呼组）=13.6（寻呼数/秒）[3]

   上面计算了实际现网中AG=2时寻呼的容量，建议将AG由2设为0，这样可以直接增加寻呼的容量，改善寻呼成功率。

以下将计算AG的实际需求及将AG由2设为0之后寻呼容量的增长。

   例如：

   LAC=14384（洛阳10月28日忙时SDCCH分配次数最多的小区63131，SDCCH_ASSIGN=5924）

   CI63131=5924SDCCHAssign（AGCHattempts）

   =5924/3600

   =1.64AGCH/s[4]

   =1.64*0.235

   =0.38/即每复帧用于AGCH的寻呼组为0.38个/

   这个计算结果说明AGCH的需求不足一个寻呼组，所以不需设置专用的AGCH，即可将AG设为0。

   如果将AG由2设为0，则寻呼组的数量将会增加：

   每秒寻呼组的数量：

（0寻呼组用于AGCH，即3寻呼组用于PCH）

   =3个PCH/0.235（每复帧）

   =12.76[5]

   考虑最差情况下，除去AGCH后，每秒实际剩下用于PCH的寻呼组数量

   =12.76-1.64

   =11.12[6]

   因此，CombinedBCCH/SDCCH小区每秒寻呼数为：

（若AG=0）

   11.12（寻呼组/秒）*3.2（寻呼数/寻呼组）=35.58[7]

   因此，[7]式（AG=0）与[3]式相比（AG=2）可知，BTS的寻呼容量可增加162%。

   五、BTS寻呼负荷的计算

   这部分更深层次分析了我省现网配置为CombinedBCCH/SDCCH和Non-combinedBCCH/SDCCH的基站，以及这些基站寻呼负荷现状。

如下表5.1所示。

   个别LAC内的BTS寻呼负荷已经超过100%。

计算结果来自10月20日至10月28日222报告的寻呼试呼数。

下面举例说明BTS寻呼负荷的算法：

   例如：

   LAC=14357（10月20日至10月28日最忙时的寻呼试呼次数为121000）

   每秒寻呼试呼数

   =121000/3600

   =33.6[8]

   对于CombinedBCCH/SDCCHBTS每秒寻呼数[3]=13.6（AG=2），

   所以，对于CombinedBCCH/SDCCH若AG=1，每秒寻呼数=[3]*2=27.2

   LAC14357的寻呼负荷为：

   =Sum（LAC内每秒寻呼数/每秒系统允许寻呼数）

   =（33.6/27.2）

   =1.235

   =123.5%[9]

   注：

寻呼负荷是指LAC范围内每个BTS的寻呼负荷，而在此计算的寻呼负荷考虑的是LAC下最差BTS的情况，因此计算出的寻呼负荷仅为最差情况的估计。

   六、网络LAC现状及问题分析

   据表5.1分析可知，目前全省共有69个LA（截止10月20日止），存在问题必须重新规划的LA26个，这些LA的呼叫成功率均低于70%（70%为最低门限）。

其中8个LA下BTS的寻呼负荷已超过90%，涉及新乡、开封、商丘、许昌、南阳、平顶山分公司，情况较为严重。

   大部分LA下都带了较多数量的BTS，这是造成这些LA寻呼负荷高的根本原因。

个别LA下的BSC容量甚至几乎满配置，如新乡BSC5（BSC容量为512，目前已高达502）。

BSC及BTS信令负荷过高直接导致了所在LA寻呼成功率极低。

   此外，信令信道的配置方式也较大程度的制约了LAC本身寻呼的容量。

对于同等条件下的两个不同的LAC，采用Combined配置方式比采用Non-Combined配置方式的成功率低很多。

如郑州的14097的成功率为82.6%,而平顶山的14612的成功率仅为67.6%，关键原因就在于郑州全网的信令信道的配置均为Non-Combined。

   目前我省寻呼负荷已基本接近容量极限，一旦负荷过载，当BTS寻呼缓冲区满了之后，寻呼信息就会被删除。

这些可以明显地从NetworkDoctor186报告中观察到。

   寻呼缓冲区的计数器负责监测。

BTS每30秒向BSC发送包含寻呼缓冲区的CCH_Load_Ind信息，然后BSC将当前类似于Paging_Buffer_Size的寻呼负荷送至统计单元，最小值由计数器3018来记录。

如果寻呼缓冲区（计数器3018）的最小值等于0，就会出现寻呼拥塞。

   然而，NetworkDoctor报告的数据是取每小时的平均值，因此，即时计数器3018的平均值不为0，但瞬间个别的缓冲区也许已出现容量超载的的情况。

   从10月20日至10月28日的186报告分析可以看出，CombinedBTS的寻呼缓冲区较小。

甚至有些BTS的寻呼缓冲区只有“1”且被删除的寻呼信息数量较高。

这就是说在这个例子中当AG设为2时，BTS已经达到容量的极限值。

下面是10月24日忙时186报告。

表5.2：

例OMC110月24日BTS寻呼话务量

   现网风险分析：

   个别BSC的容量过高，会在不同程度上限制BSC的处理能力，进而影响到BSC的服务。

严重时BSC会重启，这样整个BSC下所有的用户全部不能正常使用。

   个别LAC寻呼负荷过载，重发次数瞬间成倍增加，导致A、Abis接口信令负荷过高，手机寻呼信息直接被删除，造成接通率降低。

   从指标方面看，LAC规划不合理直接影响全网SDCCH掉话率偏高，用户感知是手机较难拨通。

   在LAC寻呼负荷过载的情况下，大量短信的冲击足以造成BSC下的大面积用户打不成电话。

也就是说，寻呼负荷低的LAC承受短信冲击的能力远比负荷高的LAC强得多。

   七、LAC规划调整方案

   八、总结及规划建议

   目前我省现网寻呼性能整体水平较低。

问题的根本原因是combinedBCCH/SDCCH基站产生的寻呼拥塞，且忙时部分LAC下的BTS寻呼负荷已接近满载。

   这份LAC现状及规划报告提供了CombineBCCH/SDCCH基站的寻呼容量的计算方法，186报告也极好地证明了很多基站在缓冲区存在排队的问题，或者说当队列已满时，情况更加严重，寻呼信息直接被删除，以至于根本寻呼不到被叫手机。

   为尽快改变目前全网寻呼性能较差的现状，改善寻呼成功率，在此提出以下规划建议：

   由于AG的优先级较高，因此可通过计算得知AGCH的需求量，将combined基站的AG的值由2设为0。

   计算SDCCH的话务量，对于低话务量的小区，将combinedBCCH/SDCCH的基站改为non-combined配置，这样可以增加至少190%的寻呼容量，同时制定扩容计划。

   将MSC的参数，Numberofseach由2设为1，同时将Abis接口16K的信令速率扩至32K。

   经常性地检测信令负荷，避免信令链路拥塞。

   此外，在重新规划LAC时应注意以下几点：

   LAC的范围必须在一个MSC下，不允许跨越MSC。

   为避免LA过大，最重要的规划原则是不要超过BTS的最大寻呼容量。

如果寻呼容量一旦超过BTS的容量极限，就应考虑LA分裂。

根据现网情况，通常一个LA的话务量超过1500ERL时，就应经引起注意。

   必须兼顾寻呼量和位置更新次数之间的平衡问题。

   避免沿主要干道和铁路划分LAC，否则会造成手机的频繁位置更新。