降低Paging负荷优化方法之RACode调整

1、 降低Paging负荷优化方法之RA Code调整安顺网络优化室2010年10月19日目录一、概述2二、调整RA Code的合理性3RA的划分原则4引入RA Color的设置6RA Color的测试7三、实验结果10修改数据前后的路测对比情况10修改数据前后的指标统计情况12RA调整的应用场景14四、规避措施15五、总结16一、概述目前现网中，Paging负荷的问题较为突出，寻呼负荷高直接导致了寻呼消息丢弃（mc925h），影响了寻呼成功率，造成大量二次拨号，直接影响到终端用户的感受。随着数据业务的高速发展，对PCH信道的负荷也带来了很大的影响。而裂变LAC则会造成基站密集区域产生大量的位置更

2、新，造成较多未接通，如何应对数据业务的增长，降低PS（数据业务）寻呼对网络的冲击，成为目前解决整体寻呼负荷的一个思考方向。现安顺市区有两个LAC，其中LAC34100晚忙时的寻呼量已经超过20万，寻呼丢弃数量最高达到5000次以上，具体数据如下：计数器MC8aMC925hP53a NB_PS_PAGING_REQ_PCHP53b NB_CS_PAGING_REQ_PCH平均值209414123313325376161最大值235335514314924286093最小值1636052117265290953该LAC下面的三个BSC的寻呼量如下表：BSC名称MC8aMC925hP53a NB_P

3、S_PAGING_REQ_PCHP53b NB_CS_PAGING_REQ_PCHANSBSC112032352871288 148058 87229 ANSBSC112091636401102 105833 57808 ANSBSC112172351491322 149207 85942 从上述数据分析可见，导致该LAC下面所有小区的寻呼量过大的主要原因是PS业务的寻呼量过大造成的，而CS业务的寻呼量并不是很大。而由于GPRS的寻呼量不一致，导致这三个BSC的寻呼量不一致。我们将安顺市区所有小区的数据等效话务量形成覆盖图，如下：可见高数据流量区域都很集中，等效数据话务量高于10erl的小区在

4、市区的所有小区比例中占比超过40%，这些都是GPRS的热点地区。当该RA进行寻呼时发生的信令交换量使设备处理能力趋于饱和，建议对热点地区RA的划分更为细致,减少paging时产生的信令负荷。对于这种情况，我们考虑利用RA Code的合理调整来降低寻呼负荷情况。将LAC34100下面的三个BSC的RA进行了修改，修改之后整个LAC的寻呼量下降41%，从最高25万降低到13万，寻呼丢弃MC925H从1391次降低到0次，降幅100%。并且修改RA之后三个BSC的GPU负荷没有增加反而略有下降，同时各项指标保持稳定并略有提升。考虑到还对修改RA后会增加路由更新，对市区的主干道进行数据DT，测试速率从

5、97kbyte/s增加到103kbyte/s，可见路由更新对整体下载速率影响不大。二、调整RA Code的合理性什么是RA呢？RA就是路由区域（Routing Area）。对于话音业务来说，处于空闲模式的移动终端设备作为被叫，网络会对整个位置区域（LA）内的所有移动终端发起PAGING，因此，所有的信令交换就会被限制在一个特定的区域LA内。同样，对于分组数据业务来说，在一个下行的TBF建立时，SGSN会对整个路由区域内（RA）的所有处于STANDBY状态的移动终端设备进行寻呼。对于整个网络来说，同时要负荷GSM和GPRS的PAGING所产生的信令交换。通过划分LA与RA，解决设备信令处理的负荷

6、，所以对LA和RA进行合理的规划是非常必要的。GPRS网络中的小区管理是由(LAC,CI)、RA Code和RA Colour来表征，其中：RA Code : Routing Area Code , 范围 0.255RA Colour : Routing Area Colour, 范围 0.7手机通过监听BCCH的广播信息来获知该小区是否支持GPRS业务以及路由信息。RA Code和RA Colour标识了服务小区与邻小区的RA关系，即是否是属于同一个路由区域。RA Code标识了一个路由区域，那RA Colour的作用是什么呢？RA Code包含在系统信息13中，而RA Colour包含在系

7、统信息3、4中，RA Colour广播周期比RA Code要短, 因此，RA Colour有益于手机及时的侦听到路由区域更新的信息。RA的划分原则依据网络成长性设计，我们分成几个阶段来进行规划阶段一：网络中GPRS/E-GPRS低话务设定RA范围等同于LA范围，属于同一个LA区域的小区分配唯一的RA Code，其中每个小区RA color相同，每个LA区域只有一个RA color.图：RA范围等同于LA范围阶段二：网络中GPRS/E-GPRS中等话务在中等话务GPRS网络中，一个LA区域最多划分8个RA；对LA内的每个RA区域分配唯一的RA Code。对于理想的网络规划，我们推荐每个RA区域包

8、含的小区数达到平衡，但是由于数据业务量分布不均，网络中往往划分了包含不同数量小区的RA,在热点地区，推荐划分较小的RA区域。当网络中分组数据业务增长时，建议将LA区域划分为几个RA区域。图：一个LA区域划分为8个RA阶段三：网络中GPRS/E-GPRS高话务针对一个高业务量的密集型GPRS网络，建议将一个LA区域划分多个RA，最多可达到256个RA,在1个LA划分大于8个RA的情况下，RA CODE必须进行复用，相邻的RA必须分配不同的RA COLOR。图：一个LA区域划分为多个RA（大于8个）随着数据业务量的增加，推荐划分多个RA区域，RA区域越小，信令负荷越少，但是RA越小，当用户在快速移

9、动时，导致了大量的路由区域更新，增加信令流量，并且使数据传输速率降低。在一个高话务的GPRS网络，对RA的合理划分是非常必要的。为了避免不必要的路由区域更新，合理的RA_COLOR规划也是非常必要的。针对现网LAC寻呼负荷较高的问题，可以对一个LAC下包含2个或者2个以上BSC的进行RA Code和RA Color的合理调整设置，改变现网统一的一个LAC一个RA的设置原则。由于现网的PS Paging是按照RA的范围进行发送的，所以如果缩小LAC内的RA范围，可以减少该LAC内的重复无效的PS Paging，从而减少重复无效的PS Paging对PCH信道的负荷，降低寻呼负荷，提高寻呼成功率，

10、改善终端用户的感受。引入RA Color的设置在合理调整RA Code的设置的同时，需要相应的调整RA Color的设置。规范中对RA Color的定义如下（包含在SI3/4中）：RA COLOUR (3 bit field)If the mobile station receives different values of the RA COLOUR field in different cell, the mobile station shall interpret the cell re-selection information as if the two cells belong t

11、o different routeing areas.即在RA Color的设置中，建议如下：1. LAC边界，相应的RA Color应该设置为不一样的值；2. LAC内，如果所有BSC的RA Code设置一致，RA Color也要设置一致；3. LAC内，如果所有BSC的RA Code设置不一致，RA Color也要设置不一致；RA Color的测试针对RA Color是否在LAC内的BSC边界真正起作用，我们选取ANSBSC11203和ANSBSC11217的边界进行路测。边界情况如下图所示；Case1：边界为RA Code不一致RA Color不一致（空闲状态），如下图所示。结果为CRH

12、在小区重选时起作用。Case2：边界为RA Code不一致RA Color不一致（业务状态，FTP下载状态），如下图所示。结果为CRH在小区重选时起作用。Case3：边界为RA Code不一致RA Color一致（空闲状态），如下图所示。结果为CRH在小区重选时不起作用。Case4：边界为RA Code不一致RA Color一致（业务状态，FTP下载状态），如下图所示。结果为CRH在小区重选时起作用。通过RA Color的实际测试，结果汇总如下：CASERA Color是否使CRH起作用边界为RA Code不一致RA Color不一致（空闲状态）是边界为RA Code不一致RA Color不一

13、致（业务状态）是边界为RA Code不一致RA Color一致（空闲状态）否边界为RA Code不一致RA Color一致（业务状态）是即合理的设置RA Color可以使手机在空闲状态下同LAC内做跨BSC的小区重选时考虑CRH参数的作用，避免空闲状态下BSC边界上的乒乓小区重选，从而导致频繁RA Update引起的相关的资源开销。由于LAC内多个BSC的RA Code值设置不一样，必然会增加BSC边界部分的RAU次数，由于一次RAU过程中最多会有3次UL信令过程，每次UL信令过程均需要进行UL TBF的请求，故合理的设置RA Color值可以在BSC边界小区重选时引入CRH的作用，减少BSC

14、边界的乒乓RAU过程，从而一定程度的降低由于RA Code设置而带来的UL TBF请求数的增加。RAU过程的信令流程图如下：因此在调整RA的时候，需要考虑将RA Colour进行搭配调整，用以区分边界的RA。三、实验结果修改数据前后的路测对比情况由于新增了路由区导致市区BSC边界新增了路由更新，为此我们进行了修改数据前后的数据FTP下载测试。10月16日凌晨，对市区的LAC34100进行了RA的修改，修改完成之后进行了对比测试。16日上午对整个城区的EDGE路测FTP下载速率为103k，较修改前测试的97k有所提升。测试指标如下：测试日期平均应用层吞吐率(KB/s)LLC层吞吐率kbyte/s

15、下行TBF Open比例下行平均时隙数量1个时隙比例2个时隙比例3个时隙比例4个时隙比例10月8日11.7293.7286.1%3.940.8%0.9%2.5%95.9%10月16日13.16105.3088.9%3.951.2%0.3%0.3%98.1%然后我们再看新增的路由区分布，修改路由区之前的安顺市LAC34100下面三个BSC的RA Code和RA Colour的分布情况：修改路由区之后LAC34100下面小区的RA Code和RA Colour分布情况：下面是数据FTP下载过程中产生的路由更新对比情况：修改数据前的测试结果，共产生9次路由更新，如下修改数据之后，进行全网数据FTP下

16、载测试共产生13次路由更新：对比修改RA前后的测试结果共增加了4次路由更新（平均每次路由更新时间1.25秒，对全网3个小时的测试基本没有产生影响），整体下载速率没有下降，因此新增的几次路由更新对全网的数据DT不会产生明显影响。修改数据前后的指标统计情况观察RA Code和RA Color修改后的Paging负荷、UL_TBF建立成功率的变化情况。取12至15日的数据为修改前数据，16至18日的数据为修改后数据，分别取当天一天最忙时的2个时间段（20点和21点）进行对比。日期最忙时LACBSCmc925hmc8ap53ap76ap77ap402UL_TBF建立成功率2010/10/1220:00

17、34100ANSBSC1120302152009980258179095.31%ANSBSC112098492092081421385588115096.73%ANSBSC112175912151889977639161097.49%2010/10/1221:0034100ANSBSC112030248269142179629824595.22%ANSBSC112091521636209980358378169393.17%ANSBSC11217444724826714210747366097.36%2010/10/1320:0034100ANSBSC112030216665992555778

18、0095.96%ANSBSC11209737215069149200553804697.49%ANSBSC112175922166399923640861097.83%2010/10/1321:0034100ANSBSC112030257376149200640814096.72%ANSBSC112091521608909927060080139093.01%ANSBSC11217599925735214917447565097.52%2010/10/1420:0034100ANSBSC112030214990102994606824598.11%ANSBSC11209873203340148

19、4525698146096.63%ANSBSC11217121021500210299843864097.62%2010/10/1421:0034100ANSBSC11203025055314845563681598.37%ANSBSC112096115404310299159980186692.70%ANSBSC11217374725053114845650666097.33%2010/10/1520:0034100ANSBSC1120302184979248154875097.90%ANSBSC1120917762184979669648569097.23%ANSBSC1121702184

20、599250841658097.34%2010/10/1521:0034100ANSBSC1120302030849669459476097.92%ANSBSC112094172030879247752370097.30%ANSBSC1121702030849672546862097.24%修改LAC34100的RA之后指标对比情况2010/10/1620:0034100ANSBSC1120301235401917249068098.30%ANSBSC1120981418472003851071097.48%ANSBSC1121701291073749545562097.79%2010/10/

21、1621:0034100ANSBSC1120301199703827553970098.34%ANSBSC112092138172247455407397.30%ANSBSC1121701274172750940157097.64%2010/10/1720:0034100ANSBSC1120301188512065249368098.32%ANSBSC11209513786121730549792397.67%ANSBSC1121701247674007540160097.52%2010/10/1721:0034100ANSBSC1120301168436244346561098.09%ANS

22、BSC112093131502265576027913095.26%ANSBSC1121701236002850745963097.41%2010/10/1821:0034100ANSBSC112030 127842 23265 530 74 0 98.38%ANSBSC112091 131082 40719 528 77 130 97.36%ANSBSC112170 129888 27515 421 61 0 97.17%2010/10/1821:0034100ANSBSC112030 115943 23609 586 75 0 97.97%ANSBSC112090 113776 33062

23、 541 71 1080 94.47%ANSBSC112170 119632 29336 465 62 0 97.45%统计这三个BSC修改EA前后的的20点和21点忙时的平均值如下：LAC忙时BSCmc925hmc8ap53ap76ap77ap402UL_TBF建立成功率3410020:00:00ANSBSC112031660228065116383601801796.94%ANSBSC112096521713351163785597770195.53%ANSBSC11217186022659311637344763097.47%3410121:00:00ANSBSC112030120504

24、3123651769098.23%ANSBSC112090122959278095457527396.59%ANSBSC1121701233753174043461097.50%通过数据汇总，得出在修改RA Code和RA color之后，LAC34100忙时的寻呼负荷均得到了一定程度的缓解。LACBSCmc925h减少比例mc8a减少比例p53a减少比例p76a负荷减少比例p77a负荷减少比例UL_TBF建立成功率增加比例3410020:00:00ANSBSC11203100.00%47.16%52.84%12.79%4.09%1.34%ANSBSC11209100.00%28.23%71.

25、77%3.07%-1.84%1.11%ANSBSC11217100.00%45.55%54.45%3.25%4.64%0.03%通过平均统计可以看出，该LAC在修改后整改LAC的寻呼量从16日之前的208665次降低122279次，降幅41%；统计该LAC下面所有小区的MC925H平均值从1391次降低到0次，降幅100%。从P76a上来看，调整前后对GPU/GP的负荷减少6.37%。即修改前后GPU/GP负荷基本保持不变并略有下降。从UL_TBF建立成功率来看，修改后整体增加比例在0.82%左右。从评估数据可见，本次RA修改对三个BSC的整体指标提升效果非常明显，同时还有效降低了系统负荷。RA调整的应用场景当LAC寻呼量超过告警值18万（各个地区根据BS_AG_BLK_RES设置不同来预估LAC寻呼量的告警值），且MC925h超过1000，分析LAC寻呼量过高主要原因：BS_AG_BLK_RES设置不同的寻呼负荷（一个CCCH块，Not combined结构）。BS_AG_BLK_RES寻呼量60%冗余5245106 147064 4306383 183830 3367660 220596 2428936 257362 1490213 294128 0551489 330894 计算公式：（9-BS_AG_BLK_RES）*寻呼组用户数*（3600/0.235）在1个Pagin