高校寻呼删除优化专题

高数据流量小区降低PagingDelte的参数设置1. 概述在中国移动数据无线网络从GPRS升级到EGPRS后，数据网络的流量得到迅猛发展。由于目前中国移动都没有使用PBCCH功能，即(E)GPRS业务所用的公共控制信道资源和GSM是相同的，在下行方向上都是使用PCH和AGCH信道。在早期GPRS和EGPRS规划期间，大家都已经知道因为共用CCCH信道资源而会带来原有GSM的CCCH资源负荷的增加，但是在以前GPRS网络中，因为GPRS网络的速率不高，所以终端用户使用无线数据网络的频度较低，GPRS业务对GSM网络中的CCCH负荷的影响尚未凸现出来。但是随着EGPRS的升级，EGPRS无线数据网络的性能得到大幅提升，终端用户在感受了无线快速上网的快感后，越来越频繁地使用EGPRS网络的服务。以及随着EGPRS网络推出全曲下载等等新业务的发展，整个EGPRS网络的数据流量进入了高速发展阶段。随着数据流量的增加，必然也同时给CCCH信道负荷带来巨大的压力。所以导致出现目前网络中高CS话务和高PS话务区域出现较多的Paging Delete消息现象，特别是校园网小区、尤为突出。每逢重大节假日各地州都会出现不同程度的LAC寻呼负荷和LAPD信令负荷过重的现象；另外由于部分少数民族聚集的地州经常会不定期的开展一些民族活动，出现话务量的猛增；这种负荷现状有可能造成部分BSC下大面积用户无法接通甚至BSC退服，因此形势十分严峻。针对此情况，做好节假日期间LAC寻呼负荷的分析以及梳理好LAC分裂计划的流程是非常重要的。针对该问题可以有多种手段对其进行优化调整，基于日常的优化调整的基础上可通过减少数据业务的AGCH数量来缓解对CCCH信道的负荷压力，进而降低paging delete发生的数量2. 寻呼消息介绍由于目前的数据流量迅猛的发展导致目前部分小区的网络性能受到瓶颈的制约，尤其是工业区和学校区的小区受到数据流量的大量冲击导致经常出现PagingDelete，而单小区的PagingDelete可能会导致恶性的大量重复RePaging，进而影响整个LAC的Paging性能，结果是用户接通率的降低我们目前的CCCH块中AG设置为1或者2，这也是多年一直保持的配置，但是2年前的PS业务还仅仅是初期阶段，所以当初这样的设置主要针对的是当初LAC Paging量较大的情况，因为之前单个LAC Paging量有超过100K的。但是目前BSC较多，LAC也比较多，加之随着网络的不断发展，对影响寻呼的信令进行了改造升级（BCCH所在载波由的LAPD信令由之前的16K改造为目前的32K），因此单个LAC的Paging量基本比较少了，因此Paging不是主要的瓶颈。而目前数据业务的发展导致个别小区的PS AG消息消耗量非常大，尤其体现在工业区和学校区周边的小区。因此对于这种情况，我们可能需要对CCCH如何分配AG、PCH的资源重新分配优化：如上图所示，CCCH在51复帧中有9个块，AGCH和PCH共享这9个块，作为规划计算，这里的1个PCH块是可以携带4个TMSI消息或者2个IMSI消息，通常按照平均3个消息计算；而1个AGCH块通常按照1.8个AGCH消息计算（经验值）。因此按照这样的配置，我们是可以计算出每个小时各种AG配置下的消息数量的。云南网络目前使用Non-Combined配置方式，其AGCH信道配置从1个到2个都有，大部分AG配置2个。每TDMA复帧的CCCH信道为9，现网的测算我们从最坏情况考虑，所以测算时AG信道配置数定为2个,这样PCH信道为：9 2 =7个。由于每个PAGING块可以支持3个寻呼信息，而1个51复帧的周期是235ms，所以空中接口的PAGING容量为：（PAGING块的数量每个块能提供的PAGING数）/235ms (73)/235ms 89 page/s，即每小时32.2万寻呼量。Non-Combined配置情况，BTS侧每个小时有32.2万多的page容量，这种配置情况下，一般情况下不会出现BTS侧的寻呼瓶颈问题。云南现网中Abis接口信令速率存在16 Kbps和32Kbps两种。16Kbps速率下，最大平均信令负荷应不超过8kbit/s（1000bytes/s)，超过1200 bytes/s时将可能导致AS7过载。在通常情况下负荷最重的Abis Link所承载的大部分为寻呼信息（约60%），而寻呼信息通常情况为21Bytes。所以Abis口最大的负荷（16K/s）100060%/2129 pages/s （即每小时10.4万寻呼量）。32Kbps情况下，Abis口支持的最大寻呼量是16Kbps的两倍，即每小时约20万寻呼量。51复帧消息块数1小时块数CCCH9137872 51复帧消息块数1小时块数1小时消息数AG115319 27574 PCH8122553 367660 AG230638 55149 PCH7107234 321702 AG345957 82723 PCH691915 275745 AG461277 110298 PCH576596 229787 AG576596 137872 PCH461277 183830 AG691915 165447 PCH345957 137872 AG7107234 193021 PCH230638 91915 三、寻呼优化调整根据寻呼消息数和AG相关的设置，我们对德宏全网近段时间寻呼删除较高的小区进行梳理，梳理发现，部分小区寻呼删除较高，严重影响小区寻呼成功率，具体如下：REPTIMELA_ID_LACBSC_NAMECELL_IDPAGING_DELETE_COMMANDCS_IMM_ASSGN_SENTPACKET_IMMED_ASS_MSGCS_PAGING_MSG_SENTPS_PAGING_MSG_SENTAG_MSGPCH_MSG201103072034917DH_BSC4A39252761971120473827765765852285031135098201103082034917DH_BSC4A39252801371194465208801475863677152138783201103092034917DH_BSC4A392529980854946051665705037254600116942201103102034917DH_BSC4A3925224305936242399772575270051761129957201103072234917DH_BSC4A392523253716129055827836178136216144564201103082234917DH_BSC4A392525160722631709868966178938935148685201103092234917DH_BSC4A392529146509514880759555893419975134889201103072334917DH_BSC4A39253756431145670310711865920581766130391201103082334917DH_BSC4A39253837121410285349785925989299451138484201103092334917DH_BSC4A392537407914318937856755856300108103123858201103102334917DH_BSC4A3925347542657225919655205149032491117010201103112334917DH_BSC4A39253467501511475861734076431690975137723201103122334917DH_BSC4A39253467502898314934612713687514178329214650201103092334917DH_BSC4A2399313490441245729675625630450141123866201103102334917DH_BSC4A239939585480145245655265149550046117021201103112334917DH_BSC4A239937801397643309734046431047285137714201103122334917DH_BSC4A23993126143129333651271228750936494214631201103132334917DH_BSC4A23993249743443333511504499086236794241311201103072334917DH_BSC4A3819218565430931615711855920335924130388201103082334917DH_BSC4A3819211322513149729785915988054860138471201103092334917DH_BSC4A381926673456337466675545628642029123840201103102334917DH_BSC4A381921585476836822655225149141590117013201103112334917DH_BSC4A381921330479632682734076431637478137723201103122334917DH_BSC4A3819211653733308381271348751334571214647我们对寻呼删除较高的39253进行分析：REPTIMELA_ID_LACBSC_NAMECELL_IDPAGING_DELETE_COMMANDCS_IMM_ASSGN_SENTPACKET_IMMED_ASS_MSGCS_PAGING_MSG_SENTPS_PAGING_MSG_SENTAG_MSGPCH_MSG201103072334917DH_BSC4A39253756431145670310711865920581766130391201103082334917DH_BSC4A39253837121410285349785925989299451138484201103092334917DH_BSC4A392537407914318937856755856300108103123858201103102334917DH_BSC4A3925347542657225919655205149032491117010201103112334917DH_BSC4A39253467501511475861734076431690975137723201103122334917DH_BSC4A39253467502898314934612713687514178329214650从上表中我们可以看出AG_MSG（= CS_IMM_ASSGN_SENT + PACKET_IMMED_ASS_MSG）的数量已经达到178K，而PCH_MSG（= CS_PAGING_MSG_SENT + PS_PAGING_MSG_SENT）已经达到214K以下。同时对于这么大的AG消息中明显PACKET_IMMED_ASS_MSG数量是居多的，基本上是CS_IMM_ASSGN_SENT的5倍多，这说明当前部分小区的数据业务的CCCH消息消耗了大部分CCCH资源。假设按照39253对应的AG消息178K和PCH消息214K我们检查表：1小时AG、PCH消息数表51复帧消息块数1小时块数1小时消息数AG115319 27574 PCH8122553 367660 AG230638 55149 PCH7107234 321702 AG345957 82723 PCH691915 275745 AG461277 110298 PCH576596 229787 AG576596 137872 PCH461277 183830 AG691915 165447 PCH345957 137872 AG7107234 193021 PCH230638 91915 从上表看AG要设置为5、或者是6才可以满足要求，考虑到39253大部分时间还是在100K以下，我们调整AG=4先进行相关观察；而从上表我们也很明确的看到PCH是可以满足214K的要求的（PCH为5可以满足229K的要求）。因此我们在2011年3月14日对39253AG参数调整到4（原来为2），对比之前的的DELETE_PAGING_COMMAND数量，我们发现数量明显减少，从2011年3月8肉23点最大83712的PagingDelete下降到最近的2万次左右，效果比较明显REPTIMELA_ID_LACBSC_NAMECELL_IDPAGING_DELETE_COMMANDIMM_ASSGN_SENTPACKET_IMMED_ASS_MSGCS_PAGING_MSG_SENTPS_PAGING_MSG_SENTALL_CCCH_MSGPCH_MSGAG_MSG201103072334917DH_BSC4A39253756431145670310711865920521215713039181766201103082334917DH_BSC4A39253837121410285349785925989223793513848499451201103092334917DH_BSC4A392537407914318937856755856300231961123858108103201103102334917DH_BSC4A3925347542657225919655205149014950111701032491201103112334917DH_BSC4A39253467501511475861734076431622869813772390975201103122334917DH_BSC4A39253467502898314934612713687514392979214650178329201103132334917DH_BSC4A39253184013396010622015044590865381490241310140180201103142334917DH_BSC4A3925337974902567564719145688020538312879476589201103152334917DH_BSC4A3925322199869861701629154939918271311231470399201103162334917DH_BSC4A3925327429871560715563175158517733210790269430201103172334917DH_BSC4A3925332981887163781624325424618933011667872652201103182334917DH_BSC4A392537944762151124630265105017282111407658745201103192334917DH_BSC4A392535918755149961625225291317294711543557512201103202334917DH_BSC4A3925320268930154717630215324918028811627064018201103212334917DH_BSC4A3925319008877952332617005217317498411387361111201103222334917DH_BSC4A392536579870440226630575454016652711759748930同时根据小区的寻呼情况，结合当前寻呼负荷，我们对以上小区影响寻呼的参数也进行了修改。主要如下：1 减少Channel Request重发次数(RET)：RET从4次减少到2次；2 缩短Paging寻呼组的周期(MFR)：MFR从5调到4；3 加大Channel Request重发间隔时长(SLO)：间隔时长(SLO)从12调整到25下图是39253调整后和之前一段时间的PagingDelete数量分布情况(其中3月13日为周末):23993修改调整后寻呼删除情况：REPTIMELA_ID_LACBSC_NAMECELL_IDPAGING_DELETE_COMMANDIMM_ASSGN_SENTPACKET_IMMED_ASS_MSGCS_PAGING_MSG_SENTPS_PAGING_MSG_SENTALL_CCCH_MSGPCH_MSGAG_MSG201103072334917DH_BSC4A239931756343215033711875920514885713039218465201103082334917DH_BSC4A2399319386407553436785955990319600913849857511201103092334917DH_BSC4A2399313490441245729675625630417400712386650141201103102334917DH_BSC4A239939585480145245655265149516706711702150046201103112334917DH_BSC4A239937801397643309734046431018499913771447285201103122334917DH_BSC4A23993126143129333651271228750925112521463136494201103132334917DH_BSC4A23993249743443333511504499086227810524131136