GSM网络寻呼成功率优化探索

GSM网络寻呼成功率优化探索摘要：网络寻呼成功率是评估GSM网络质量的一项重要指标。无线寻呼成功率的高低直接反映了网络的接入性能。根据GSM规范,移动交换系统对一次呼叫可以启动两次寻呼过程,若成功,则记录为寻呼成功;否则,则记录为寻呼失败。计算公式:寻呼成功率=(∑寻呼成功数/∑寻呼尝试数)x100%。本文着重从无线的角度，结合部分交换侧的知识及当前联通网络的具体实例，对如何提高GSM网络寻呼流程中的成功率做了简明的分析和优化探索。关键词：GSM网络；寻呼成功率；联通；优化2008年10月份中国联通郑州分公司GSM网的寻呼成功率一直低于总部考核达标92.5%，因此提出针对郑州寻呼成功率的专项优化工作。无线寻呼成功率的高低直接反映了网络的接入性能。郑州联通GSM网络寻呼成功率专题优化工作是在理论分析的基础上结合网络日常期间状况提出提高寻呼成功率方法。在本次专题中探索研究出了提高寻呼成功率和寻呼信道相关资源配置优化的方案，此次专题优化主要从以下几方面展开，进行了探索与研究。寻呼有关的MSC/BSC测量及Table状态。Paging相关的参数(MSC/BSC/BTS)从理论上对CommonPCH、Paging流程、Paging容量、AGCH、RACH容量进行分析，找出与Paging相关参数最佳设置分析影响寻呼信道效率的主要因素，确定寻呼信道效率的计算方法，在此基础上分析出提高寻呼信道效率的思路。通过本次探索与研究，郑州寻呼成功率在一个月内由92.16％提升到94.02％；此外，通过本次专题研究和探索，总结出一套成熟的全流程寻呼成功率优化方案，具有普遍的推广意义。1.理论分析1.1.CommonPCH分析1.1.1.PCH信道配置概述在GSM系统中，寻呼在PCH信道发送，PCH通常与广播信道（BCCH、FCCH、SCH）和其他公共控制信道（AGCH、CBCH）分时复用，位于BCCH所在载频的TS0时隙上，如下图所示：照片尺寸为20mm*30mm；最好不用红色背景图1.1.1.-1PCH信道配置其中PCH与AGCH在参数的控制下分时共享CCCH块，而CCCH的块数与BCCH载频的TS0的复用方式有关，BCCH载频的TS0主要有以下两种复用方式1)BCCH/SDCCHcombined在该方式下，1个复帧（51帧，235.4ms）中包含3个CCCH块（12个SLOT），即PCH信道最多可为3个，当AGCH（0－2）取值为1时，则PCH信道为3-1＝2。如下图所示：图1.1.1.-2PCH信道配置方式一2)BCCH/SDCCHnon-combined在该方式下，1个复帧中包含9个CCCH块（36个SLOT），即PCH信道最多可为9个，当AG信道（0－7）取值为2时，则PCH信道为9-2＝7。如下图所示：图1.1.1.-3PCH信道配置方式二1.1.2.PagingBlock帧结构每个PAGINGRequest共21个字节（包括帧校验序列FCS和标头flags），最多可包含4个用户，分以下三种情况：1.IMSIPAGINGREQREST；（IMSI:8字节）2.TMSIPAGINGREQREST；（TMSI:4字节）3.1IMSI+2TMSIPAGINGREQREST；如下图所示：图1.1.2.帧结构1.2.寻呼信道相关参数的意义及影响1.AG:接入允许保留块数(0...7)CombinedBCCH/SDCCH小区：AG=0...2，而Non-CombinedBCCH/SDCCH小区：AG=0...7，若使用CBCH，则AG=1...7。这个参数定义了每个复帧内AGCH专用的BLOCK数量。它可以设成AG=0(此时一旦有用户接入，系统则将部分PCH信道转成AGCH信道用于接入)或AG=1(即保留作为AGCH专用信道的块数)。用于AGCH的数量取决于小区话务量。2.MFR:帧寻呼周期(2...9)这个参数定义了BTS的寻呼周期,即同一寻呼组传送寻呼请求的时间间隔。例如：MFR=9的意思是每一寻呼组以每9个复帧的周期重复一次。也就是说属于某一特定寻呼组的手机，必须每9个复帧监听一次，也就是说监听间隔时间大约是2.1秒(9*235.4ms)。另外，该参数还决定了thedepthofpagingbuffer。3.MFR与寻呼时延的关系假设在non-combined情况下，MFR=5,AG=2则paginggroup数量=5*(9-2)=35对于PagingGroup1,BTS发送pagingrequest需要的时间是：6*4.615ms=27.69ms(假定thepagingmessage在第一个block,第一个TMSI)图1.2.-1PAGINGGROUP1帧寻呼周期图对于PagingGroup35,BTS发送pagingrequest需要的时间是：(5*235ms)-(2*4.615ms)=1.165s(假定thepagingmessage在第35个block,最后一个TMSI)PagingGroup1First51TDMAframePagingGroup355th51TDMAframe图1.2.-2PAGINGGROUP35帧寻呼周期图通过上面的分析，如果不考虑BTS的处理时间和Paging的排队时间，则BTS发送Pagingrequest的时间应该在27.69ms与1.165s之间。如果改变MFR,AG则相应的时间会变短，此时，BTS发送Pagingrequest的时间应该在27.69ms与2.1s之间。1.3.寻呼流程分析图1.3.寻呼流程图上图显示网络寻呼的基本信令流程，基本信令流程可分为3大步骤：步骤一为Paging步骤，步骤二为RadioAccess步骤，步骤三位Establishment步骤：步骤一：当MSC从VLR中获得MS当前所处的LAC位置后，会向这一LAC下的所有BSC发出Paging信息（信令1），BSC在收到该Paging信息后，将向该BSC下属的所有小区发出PagingCommand信息（信令2）。而当BTS收到PagingCommand信息后，会向MS下发PagingRequest信息（信令3），该消息携带了被寻呼用户的IMSI或TMSI号码。步骤二：当手机接收到该PagingRequest信息后，通过RACH请求分配SDCCH。BSC在确认BTS激活了所需的SDCCH后，通过占用AGCH发送ImmediateAssignmentCommand要求将该SDCCH指配给手机（信令4至信令9）。步骤三：当手机接收到该ImmediateAssignmentCommand信息后，手机将占用该SDCCH发送PagingResponse信息，BSC将该PagingResponse消息转发给MSC，完成一次成功的寻呼（信令10至信令12）。从信令流程可看出网络寻呼失败的起因将可能由于信令1至信令12的失败所导致。由于MSC与BSC间是有线连接，几乎不可能存在信令在传送过程中的丢失，因此排除信令1和12的丢失所引起的寻呼失败，唯一的可能性是A接口容量的不足所引起的信令1和12的丢失。同样的，由于BSC和BTS之间也是有线连接，几乎也不可能存在信令在传送过程中的丢失，因此也排除信令2、5、6、7、8和11的丢失所引起的寻呼失败。需要提出的是虽然排除了BSC和BTS的信令丢失所引起的寻呼失败，但无可否认如果BSC出现负载状况而导致ABIS接口容量的不足，网络寻呼失败还是会发生。因此，较容易出现网络寻呼失败的原因可能是由于信令3、4、9和10的丢失所引起，这都是空中接口所产生的。下面将从MSC、LAC、BTS、MS四个角度来分析寻呼流程：1.3.1.MSC角度分析当MSC收到网络发来的paging消息时，则向此paging消息包括一个MS的IMSI号码，以及根据MSC的参数中的pagingmethod（MML：ZEDP）来确定发送pagingrequest的范围，详细的解释如下表格所示：表1.3.1.-1各信令代码解释表BSCValueDescriptionCGICI+LAC+MNC+MCCCLICI+LACLAILAC+MNC+MCCLACLACALLALLCELLSINBSCMGWValueDescriptionLAILAC+MNC+MCCLACLAC但是推荐LAC或者LAI的pagingmethod，这样可以减轻MSC和BSC之间的信令负荷。如果MSC/MSS包含较多PLMN的无线网络配置则使用LAI方式。另外如果MSC发送出paging消息以后，则启动T3113定时器，若该定时器超时以后，根据MSC参数中的TMSIPAGEREPETITIONINMTCALL以及AT来确定重发机制。表1.3.1.-2：寻呼重发机制表StrategyTMSIusageTMSIpagerepetition1stpage&ATtimesRepage2ndpage&ATtimesrepage1YesYeswithTMSIwithIMSI2YesNowithTMSINo3NoYeswithIMSINo4NoNowithIMSINo另外可以从下图中明了的理解重发机制：图1.3.1.寻呼重发机制流程图若重发完成以后，MSC仍然没有收到Pagingresponse消息，则该寻呼失败。1.3.2.LAC角度分析从目前网络pagingmethod的默认设置为LAC来分析，当一个LAC下的移动台被寻呼时，MSC就会通过基站控制器(BSC)向对应LAC范围内的所有小区发出寻呼请求｡1.3.3.BSC角度分析BSC根据从MSC收到的paging消息中的IMSI以及小区的CCCH信道配置和寻呼块的配置计算出该MS所在的Paginggroup，另外根据MSC设置的寻呼方式来确定MS识别为IMSI或者TMSI，此时BSC把此消息封装完成后形成一条pagingcommand发送给所有的BTS，此pagingcommand消息中只包括对一个MS的寻呼信息。1.3.4.BTS角度分析BTS接收到BSC发送的Pagingcommand以后，将该寻呼存放在PagingCommand所指明的寻呼组队列中，每隔相同寻呼间帧周期下发该寻呼组的寻呼内容。在一个寻呼保留块中，可以下发2个IMSI寻呼或者4个TMSI寻呼，因此每次下发寻呼时，BTS要针对队列中的寻呼消息类型完成寻呼的合并。寻呼在小区BCCH载波0时隙的PCH信道上被执行。PCH的容量应该正确规划，以避免寻呼消息被删除的情况发生。由于MS不需要监听所有的寻呼信道，而只需要监听属于自己的寻呼组的消息，所以划分寻呼组可以节省电池的耗电量。BTS有一个寻呼缓存，当寻呼消息不能被及时发送出去时，它们被放进缓存里。1.3.5.MS角度分析空闲状态下手机除了接收广播信道上的系统消息，同时还侦听自己所属的寻呼子信道（还有不支持DRX的手机是监听所有寻呼组的寻呼消息的，这种手机有比较高的寻呼成功率）。因此手机接收到对自己的寻呼之后，将向网络侧发出信道请求，完成一次立即指配过程。如果此次立即指配成功，则在指配到的SDCCH信道上上报寻呼响应（PagingResponse），同时完成呼叫的接续过程。1.4.网络容量分析1.4.1.A口容量分析提取2008-10-30-----2008-11-5交换信令链路实际忙时出入链路总负荷数据，根据信令链路实际忙时总负荷不能超0.25判断，发现ZZMSC3A口信令链路过负荷，建议对其扩容，具体每条链路的负荷数据如下表所示：表1.4.1.郑州联通各交换信令链路负荷表序号源点信令链路实际忙时出入链路总负荷最大值1ZZMSC3ZZMSC3/Z3BSC1_1LS1-00.35232ZZMSC3ZZMSC3/Z3BSC1_1LS1-100.23433ZZMSC3ZZMSC3/Z3BSC1_1LS1-120.23484ZZMSC3ZZMSC3/Z3BSC1_1LS1-20.35215ZZMSC3ZZMSC3/Z3BSC1_1LS1-40.35236ZZMSC3ZZMSC3/Z3BSC1_1LS1-80.