1寻呼成功率优化1.1概述寻呼成功率是移动通讯系统中一项基本功能。

他直接影响来话接通率和系统接通率等其它网络指标，影响用户的感受。

寻呼成功率由MSC统计，该指标优化提高要通过交换和无线优化共同努力解决。

指标定义如下寻呼成功率：寻呼相应次数/寻呼请求次数×100％寻呼响应次数：只MSC收到的PAGING RES消息的总和，包括重复寻呼的响应，统计点为MSC寻呼请求次数：指MSC首次发送的PAGING消息的总和，统计点为MSC。

1.2寻呼流程简介寻呼成功率主要涉及到A接口和空口的流程：A1：MSC发来的电路业务请求次数B1：Abis口电路业务寻呼下发次数C1：Abis口电路业务寻呼成功次数。

当MSC从VLR中获得MS的LAC后，将向该LAC区域所有BSC发送PAGING消息。

BSC收到消息后，向该BSC所属全部小区发送Paging Command。

基站收到寻呼命令后，将在无线信道的该IMSI或TMSI所在寻呼组的寻呼子信道上发送Paging Request，该消息携带被寻呼用户的TMSI或IMSI。

MS收到Paging Request 后，通过RACH请求分配SDCCH。

BSC确认后激活相应的SDCCH信道后，在AGCH信道通过 immediate assignment 将该SD信道指配给MS。

MS占用该SD信道成功后，发送Paging Response。

BSC将该消息转发给MSC，完成一次寻呼。

1.3寻呼丢失原因分析1.3.1电路寻呼损失的分析如下图所示我们根据寻呼的基本信令流程，将寻呼损失分为3部分，再结合现网无线与交换的统计，对无线侧的寻呼损失进行量化分析。

（因为MSC与BSC之间，BSC和BTS之间为有线连接，几乎不存在信令在传送过程中的丢失，为了简化分析我们不考虑MSC，BSC和BTS三者之间的信令丢失）。

1.3.1.1“寻呼损失1”部分“寻呼损失1”：从交换机下发PAGING消息到BSC收到手机上发的响应寻呼的RACH请求消息之间损失的寻呼。

如寻呼损失信令分析图，用红圈标出了“寻呼损失1”部分里，可能造成寻呼损失的4个位置①,②,③,④，详细分析如下：①BSC丢弃来自MSC的寻呼消息：如果BSC出现过载，BSC有可能丢弃来自MSC的寻呼消息（虽然在一般情况下是不会出现BSC过载的，但是我们仍然需要加强对BSC负载进行监控，避免这种情况的出现）②BTS丢弃来自BSC的寻呼消息：当BTS出现PCH拥塞时，会造成PAGREQ消息不能发送。

因此我们需要对现网PCH拥塞情况进行为统计，如果存在PCH拥塞，将通过调整参数及扩容，避免或改善该拥塞的发生。

③MS没有收到BTS下发的寻呼消息，有三种原因：MS脱网导致MS收不到寻呼消息MS脱网是造成寻呼损失的主要原因。

当MS处于覆盖盲区，若此时MSC向MS发送了寻呼消息，则MS显然无法响应，产生了寻呼损失，可通过增加基站、天线调整等方案改善覆盖。

传输闪断、掉站等突发因素同样会造成寻呼损失。

寻呼下发时MS正在作位置更新：用户做位置更新会出现几种情况，当用户在本LAC区做位置更新时,若位置更新完成后寻呼还未超时，则继续寻呼，不会影响寻呼响应，但若位置更新完成时寻呼也超时，则影响寻呼响应；从信令及经验上来看，在本位置区做位置更新对寻呼影响较小；但当用户在其他位置区做位置更新时，会影响寻呼成功率。

其它用户行为包括MS掉电，或用户在开机状态下拔电池板，如果在这个时候MSC下发了Paging消息，MS将无法相应，造成寻呼失败。

这是用户行为造成，与网络性能无关，但需要加强宣传，对用户行为进行合理引导。

④BTS无法获得MS上发的响应寻呼的RACH消息，有两种原因：上行覆盖差由于上行覆盖差，使BTS没有收到MS发送过来的消息，造成了Paging Loss。

上行干扰严重由于上行干扰严重，使BTS无法正常解码MS在RACH上发的Channel Request消息。

总之，“寻呼损失1”的主要原因有：BSC过载，BTS PCH拥塞，MS处于覆盖盲区，MS 正在作位置更新，上行覆盖差（上下性不平衡），上行干扰严重和其他一些用户行为。

各BSC下并不存在BSC过载，PCH拥塞。

由于干扰严重的小区数量较少，而且会在日常优化中逐步解决，故寻呼损失的主要原因还是覆盖问题，即下行与上行的覆盖不足。

在之后的优化工作中，一方面排除上行干扰，检查上下行不平衡问题，另一方面可通过DT测试优化，天线调整等来改善覆盖。

1.3.1.2“寻呼损失2”部分“寻呼损失2”：从BSC收到手机上发的响应寻呼的RACH请求消息，到BSC下发响应寻呼的Immediate Assignment消息之间损失的寻呼。

如寻呼损失信令分析图，我们用红圈标出了“寻呼损失2”部分里，可能造成寻呼损失的位置⑤，当SDCCH拥塞时BTS无法激活响应寻呼的SD信道，将发送IMASS Reject消息。

造成SDCCH拥塞的原因有：信道资源不够引起的拥塞，设备故障或传输问题引起的拥塞，干扰引起的拥塞，突发业务量引起的SDCCH拥塞，数据配置不合理引起的拥塞以及LAC边界位置更新频繁等等，需要针对不同小区情况采取适当措施。

在优化过程之中将针对SDCCH拥塞较为严重的小区进行重点优化。

1.3.1.3“寻呼损失3”部分“寻呼损失3”：从BSC下发响应寻呼的Immediate Assignment消息，到响应寻呼的SD成功建立，BSC收到MS发来的PAGRES消息并将该PAGRES消息转发给MSC 之间损失的寻呼。

如寻呼损失信令分析图，我们用红圈标出了“寻呼损失3”部分里，可能造成寻呼损失的3个位置⑥，⑦，⑧，详细分析如下：⑥BTS丢失部分Immediate Assignment消息：BTS出现AGCH拥塞时会造成IMASS消息不能发送，我们需要对现网AGCH拥塞情况进行统计，如果存在AGCH拥塞，通过调整参数及扩容，避免或改善该拥塞的发生。

⑦MS没有收到BTS下发的Immediate Assignment消息，有两种原因：MS脱网与用户行为（包括MS掉电，或用户在开机状态下拔电池板）；另外，还与无线环境有关。

⑧BTS无法收到MS上发的Paging Response消息：出现这种情况的原因与④ BTS无法获得MS上发的响应寻呼的RACH消息的原因是一样的，主要是上行覆盖不足和上行干扰的问题，另外我们还需要关注寻呼的相关参数设置，避免寻呼响应上发时相关定时器已经超时，不进行统计。

可以看到在各BSC下的“寻呼损失3”部分寻呼损失的比例较高。

分析寻呼损失的原因，因为各BSC下的AGCH并不拥塞，而且上行干扰并不明显，只有个别小区存在，故寻呼损失的主要原因还是覆盖问题，即下行与上行的覆盖不足。

另外，根据上述时间段的寻呼成功率计算，寻呼损失3也是寻呼损失中比例最大的一部分，是我们优化调整的重点。

1.3.2小结寻呼成功率是一个系统级的问题，涉及MSC、BSC、BTS、MS以及网络的覆盖情况等。

按照寻呼流程对寻呼损失分析之后，可知寻呼成功率出现问题主要和以下几方面有关系：1、基站覆盖情况（避免MS处于覆盖盲区）；2、上行干扰；3、信令信道是否拥塞；4、位置区划分的合理性（避免寻呼时MS正在作位置更新的次数）；5、寻呼相关参数设置（避免寻呼响应上发时相关定时器已经超时，不进行统计）；6、周期位置时间（T3212）等；7、上下行平衡情况；8、PCH，RACH和AGCH信道负荷（避免这些信道过载）；9、手机质量问题。

1.4优化相关参数1.4.1NSS侧相关因素分析及提高手段一般情况下，在NSS侧可以通过以下调整寻呼策略来优化寻呼成功率：寻呼次数、寻呼间隔、寻呼方式。

寻呼次数越多，寻呼成功率也越高；寻呼时间间隔必须和BSS侧的寻呼响应时间配合合理，才能提高寻呼成功率。

一般情况下，在MSC可以通过以下调整寻呼策略来优化寻呼成功率。

1.4.1.1寻呼次数和寻呼间隔根据“寻呼损失3”中的原因⑧-( BTS无法收到MS上发的Paging Response消息) ,同时结合MSC侧的寻呼设置，首先优化由于设置不合理而导致的“寻呼响应上发时相关定时器已经超时，不进行寻呼响应统计”。

设置建议：寻呼次数建议设置成3次，寻呼间隔城市设置成 (5/5/5)或（6/5/5）；郊区地区可以设置为(6/8/6) 。

问题分析：对位置区容量较大的位置区，建议寻呼重发次数不能太大，且寻呼重发间隔不能太短。

原因是这样做容易造成基站过载和BSC CPU过载，导致大量的寻呼消息被丢弃，从而造成寻呼成功率急剧下降。

如果寻呼重发间隔设置太短，则在所指定的寻呼次数内还没有收到寻呼响应，MSC就认为预寻呼失败并清除寻呼信息。

之后，即使寻呼响应又上来，但由于寻呼信息已清除，则MSC会通过CLEAR_COMMAND拆除被叫侧无线信道。

上发的寻呼响应将被丢弃，不作统计。

另外，寻呼间隔设置时间太长将导致主叫用户听不到PGTO（PagingTimeOut）录音通知（由被叫端局向主叫用户播放用户不在服务区的录音通知），时间太短将不能收到手机终端的寻呼响应。

寻呼时间间隔必须和BSS侧的寻呼响应时间配合合理，才能提高寻呼成功率。

例如MSC寻呼的时间间隔为4s，但是BSS侧的寻呼响应时间大部分为4.4s，这样肯定会导致寻呼成功率较低，对寻呼机制做调整的理论依据是：寻呼成功率=寻呼响应次数/寻呼请求次数。

其中，寻呼响应次数=一次寻呼响应次数+重复寻呼响应次数；寻呼请求次数=一次寻呼请求次数，不包括重复寻呼次数。

因此，适当增加寻呼次数对寻呼成功率有一定的正面影响。

其次，调整寻呼响应等待时长。

MSC等待响应的定时器超时后，再收到Paging Response。

该响应显然是无效的，BSC不能控制收到Paging和上报Paging Response的时间间隔，也就是说，从理论上讲，MSC超时再收到BSC上报的“无效响应”是不可避免的。

减少无效的“寻呼响应”最直接的办法就是增长MSC等待响应的定时器时长。

如图所示：1.4.1.2寻呼方式（TMSI寻呼或者IMSI寻呼）问题出处：避免PCH信道过载，增加PCH寻呼容量问题分析：（1）由于从理论上讲TMSI寻呼效率是IMSI寻呼效率的2倍，所以采用TMSI寻呼方式相当于提高了PCH的寻呼容量。

（2）对于PCH接近过载或已经过载的网络，建议采用TMSI寻呼方式，可以缓解PCH过载现象。

建议设置：首次寻呼使用TMSI寻呼，第二次使用TMSI寻呼，第三次使用IMSI寻呼。

既增加了PCH寻呼容量，又平衡了TMSI的临时错误。

现网设置合理，不作调整。

1.4.2BSS侧提高寻呼成功率的措施1.4.2.1BTS寻呼重发功能问题出处：根据“寻呼损失3”的原因⑦： MS没有收到BTS下发的Immediate Assignment消息。