河南移动GSM网络LAC现状分析及解决方案

河南移动GSM网络LAC现状分析及解决方案一个LA可能涵盖数十个甚至数百个小区，所以发至BSC的寻呼信息数量可能会很惊人。 一、简介良好的寻呼性能对于所有手机用户是否能够成功作被叫来说十分重要。这份文档主要分析了我省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。 Combined BCCH/SDCCH 小区 AG =0 . 2 ，而 Non-Combined BCCH/SDCCH 小区 AG = 0 . 7 ，若使用CBCH，则AG= 1 . 7。这个参数定义了每个复帧内AGCH专用的寻呼组数量。它可以设成AG= 0 (即没有专用的AGCH，所有的寻呼组由PCH和AGCH共享。)或 AG= 1 ( 即保留寻呼组作为AGCH专用信道)。用于AGCH的寻呼组数量取决于小区话务量。由于我省并未启用 CBCH 功能，并且在Nokia GSM BSS9中，若没有保留AGCH的情况下，AGCH的优先级高于PCH，因此尽管有需求，也可以将AG设为0。 MFR (2.9): 这个参数定义了BTS的寻呼周期,即同一寻呼组传送寻呼请求的时间间隔。例如：MFR=9的意思是每一寻呼组，以每9个复帧的周期重复一次。也就是说属于某一特定寻呼组的手机，必须每9个复帧监听一次，也就是说监听间隔时间大约是 2.1秒 (9 * 235.4 ms)。AG，MFR以及寻呼组的数量三者之间的关系如下：以我省个别地市为例计算小区寻呼组的数量1)CombinedBCCH/SDCCH小区：AG=2MFR=5寻呼组数量=(3- AG) * MFR = 5 个寻呼组2)Non-combinedBCCH/SDCCH小区：AG=2MFR=5寻呼组数量=(9- AG) * MFR = 35个寻呼组四、BTS 寻呼容量的计算考虑到SDCCH拥塞，一些小区配置为combinedBCCH/SDCCH，但将BCCH/SDCCH改为combined 后会减少每复帧周期的寻呼组的数量。如上计算，若使用non-combined，寻呼组的数量为35，而用combined 时只有5个寻呼组。以下主要针对combined配置进行深入分析。BTS通过寻呼组广播寻呼请求。下面是一个寻呼请求可能的配置： 2 IMSIs 1 IMSI and 2 TMSIs 4 TMSIs对于现网中部分分公司设置的CombinedBCCH：每个复帧有3个寻呼组 (235 ms), 若AG = 2，每秒寻呼组的数量为：(2个AGCH-1个PCH)=1个PCH/0.235(每复帧)=4.25个寻呼组/ 秒 1每复帧寻呼组可以传送4个TMSIpages或2个 IMSI pages 。假设25 % 用于IMSI，且没有全网寻呼，每复帧寻呼组的寻呼数为：1TMSI寻呼占一个寻呼组的? ，1 IMSI 寻呼占? 。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 (AGCH attempts)= 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日最忙时的寻呼试呼次数为)每秒寻呼试呼数=/3600=33.6 8对于CombinedBCCH/SDCCHBTS每秒寻呼数 3 = 13.6 (AG=2)，所以，对于CombinedBCCH/SDCCH若AG=1 ，每秒寻呼数=3 *2=27.2LAC14357的寻呼负荷为：=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寻呼缓冲区满了之后，寻呼信息就会被删除。这些可以明显地从NetworkDoctor 186 报告中观察到。寻呼缓冲区的计数器负责监测。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 的话务量，对于低话务量的小区，将combined BCCH/SDCCH 的基站改为non-combined配置，这样可以增加 至少190%的寻呼容量，同时制定扩容计划。将MSC 的参数， Nu