《寻呼成功率指导书》由会员分享，可在线阅读，更多相关《寻呼成功率指导书（28页珍藏版）》请在金锄头文库上搜索。
1、1. 寻呼成功率的背景及定义2. CN 侧影响因素分析及提高手段3. B 侧相关因素分析及提高手段4. 案例分析应用寻呼成功率指导书XXXX 指导书第一章 寻呼成功率的背景及定义背景无线寻呼成功率取自所有的端局(VMSC)，移动用户做被叫或接收短消息过程中端局 (VMSC)向所属用户发起寻呼情况的统计，即寻呼成功之和与寻呼尝试之和的百分比。寻呼成功率考核各地无线覆盖情况、网络运行维护优化的质量等。这项指标的高低反映网络的覆盖规模，网络覆盖本质上是无线的问题，应归于基站的密度、发射接收功率的设置等。通常，每期工程的顺利完成寻呼成功率就会有所提高，而且这个提高幅度同工程的规模成正比。网络优化的目的
2、是尽可能使得寻呼成功率达到工程设计应该达到的水平。那么这项反映网络覆盖的指标如何优化呢？BSS 当然是这项指标的理想跟踪对象，可以将大的系统指标分解到各个小区来定点分析，通过对各个小区或基站的障碍清除、参数调整、高度调整及俯仰角变换等等手段来达到无线的最佳覆盖，从而优化寻呼成功率。其次在 NSS 一边也有一些优化手段可以提高这项指标。本文主要讲述 NSS 侧的一些优化手段。寻呼流程XXXX 指导书 3.PAGIN REQUST 2.PAGIN COMANDMSBTSBSCPCUSGNMSC/VLR 1.PAGIN 12.AIREQST 13.AGINREQUST2 4.CHANEL RQUST
3、 5.CHANEL RQUIED 6. CTIVAION7.L KII AKNOWEDG 8.IMIT ASINC 9.IMEDIATSGN 10.PI RO 1.E ID(PGI RSON)C1B1. PI定义系统寻呼成功率=寻呼响应次数/ 寻呼请求次数*100%寻呼响应次数指本地区所有 MSC 收到的 PAGING RES 消息的响应总和。包括重复寻呼的响应。统计点为 MSC。寻呼请求次数XXXX 指导书定义:指本地区所有 MSC 发出的首次 PAGING 消息（不包括重复寻呼）的总和，统计点为 MSC。语音寻呼成功率=语音寻呼响应次数/ 语音寻呼请求次数话统指标目前版本的实现，对于寻呼方
4、面的统计有四个测量指标：MSC 基本表测量寻呼过程测量MTC 呼通率测量位置区话务测量 话统公式：系统寻呼成功率以 MSC 基本表测量的寻呼响应次数和寻呼次数的比率为准。B 侧的寻呼成功率指标是以 BSC 为单元进行测量，而 N 侧的寻呼成功率指标分为两种：一是以 MSC 为单元进行测量；二是以位置区为单元进行测量。XXXX 指导书第二章 CN 侧影响因素分析及提高手段第一节 寻呼策略影响分析当发现寻呼成功率下降时，首先查看无线环境是否有调整过？无线信号覆盖状况如何？（基站覆盖区域是否有比较多的掉话？较多则说明无线覆盖差。）BSC 是否有 PCH 过载告警（考虑是否有大量群组短信、全网寻呼、大
5、量立即指配）。一般情况下，在 MSC可以通过以下调整寻呼策略来优化寻呼成功率。1 寻呼次数和寻呼间隔；对位置区容量较大的位置区，建议寻呼重发次数不能太大，且寻呼重发间隔不能太短。原因是这样做容易造成基站过载和 BSC CPU 过载，导致大量的寻呼消息被丢弃，从而造成寻呼成功率急剧下降。另外，如果寻呼重发间隔设置太短，则在所指定的寻呼次数内还没有收到寻呼响应，MSC 就认为预寻呼失败并清除寻呼信息。之后，即使寻呼响应又上来，但由于寻呼信息已清除，则 MSC 会通过 CLEAR_COMMAND 拆除被叫侧无线信道。寻呼间隔设置时间太长将导致主叫用户听不到 PGTO（PagingTimeOut）录音
6、通知（由被叫端局向主叫用户播放用户不在服务区的录音通知），时间太短将不能收到手机终端的寻呼响应。寻呼时间间隔必须和 BSS 侧的寻呼响应时间配合合理，才能提高寻呼成功率。例如 MSC 寻呼的时间间隔为 4s，但是 BSS 侧的寻呼响应时间大部分为 4.4s，这样肯定会导致寻呼成功率较低。通过在现场观察比较设置为 7 秒效果最佳，目前系统均设置一般为 5 秒。如果无线侧资源较充足，寻呼次数建议设置 3 次。分析：XXXX 指导书寻呼次数和寻呼间隔的调整是对寻呼成功率的影响最大，在调整时要考虑 B 侧下述因素：1） PCH 资源的数量；2） 忙时一定时间内同时被寻呼的用户数量，数量越大存在接入碰撞
7、的几率也越大；3） BTS 有无重发功能；4） BTS 的寻呼论选算法（决定寻呼重发次数）；关于第一次的寻呼间隔：这个图是一个局点的现网数据统计出来的，可以看出 99的寻呼响应都是在 4 秒之内回的。当然 B 侧的无线环境太差或者 BTS 的寻呼队寻 呼 响 应 时 间 分 布 .jpg列太长也会导致寻呼响应时间超过 5 秒。这个值的设定与 BTS 的寻呼队列机制有关，不同厂商可能差异较大。附：我司的 MSC/BSC/BTS 寻呼过程配合分析图XXXX 指导书XXXX 指导书以上流程中：基站寻呼队列生命周期为5000ms；计算后寻呼响应最长时间约为6840ms，再加上核心网的处理时延，会更长一
8、些，据此建议核心网寻呼等待时间设为7000ms 。2 以 TMSI 进行寻呼还是以 IMSI 进行寻呼；分析：以 TMSI 寻呼可提高安全性，还可以增大无线信道上的寻呼合并比（提高 PCH 的利用率），对于这种情况一般是先用TMSI 进行寻呼，最后一次使用 IMSI 进行寻呼。另外以 IMSI 寻呼还可解决个别用户 TMSI 临时出错的情况。寻呼必须有 IMSI，利用 TMSI 寻呼也必须携带 IMSI，TMSI 寻呼并不是减少寻呼数量，而是节约资源。一个 PCH 只能同时对两个 IMSI 进行寻呼，但是一个 PCH 可以同时对 4 个 TMSI 进行寻呼，相当于 PCH 扩容。MSC 下发的
9、寻呼报文只会携带一个用户的信息，一般既有 TMSI 和 IMSI，或者只有 IMSI，此时 BSC 会做一个判断，如果有TMSI，这时 BSC 就给 BTS 下发携带该 TMSI 的寻呼报文，如果没有 TMSI，BSC 就给 BTS 下发携带该 IMSI 的寻呼报文。寻呼报文到达基站后，为了有效利用无线资源，BTS 会进行寻呼合并，即 Um 接口下去的一个寻呼报文会携带 4 个 TMSI，不够就用填充位填充；或者 2 个 IMSI，不过一般 IMSI 合并比较困难，复用比只有 1：1.2 左右。综上所述：IMSI 只用于给 BSC，用于进行寻呼编码，并不是用于真正下发寻呼处理。一个手机只监视在
10、 PCH 的一个地方，BTS 下发寻呼时，必须根据 IMSI 进行编码，但 BSC 会做一个判断：如果有 TMSI，就使用 TMSI 进行寻呼，如果只有 IMSI，则使用 IMSI寻呼。因为有时系统下发的 TMSI，手机并不认识，因此应该设置至少存在一次使用 IMSI 寻呼。用户在 MSOFTX3000 中第一次寻呼后，如果从 SGSN 发过来一个位置更新的消息，更新了 TMSI 后，MSOFTX3000 依旧以原有 TMSI 进行寻呼XXXX 指导书分析：在现有的设计处理下，如果在寻呼时进行了位置更新，本次呼叫寻呼携带的TMSI不改变，这是正常情况。解决方法：以上情况发生的机率很小，对业务也
11、不是很大影响如要修改（即第一次寻呼后发生位置更新，修改成以新TMSI进行寻呼），实际意义不大，而我们要做的改动大。规避方法：用户担心在信号较弱的地区因为寻呼过程长，而此过程中发生了位置更新导致寻呼失败，我们可以用下面的方法来规避：MOD PGCTRL配置最后一次寻呼使用IMSI，而不是TMSI说明：对于没有分配 TMSI 的情况，系统自动用 IMSI 进行寻呼。建议：如果无线侧寻呼信道较为充足，建议每次寻呼都 IMSI，否则最后一次使用 IMSI（前面几次使用 TMSI）。3 按照按照位置区进行寻呼还是进行全网寻呼（MSC 覆盖范围）；分析：现网一般都是按照位置区进行寻呼的；现网存在这种可能：
12、用户刚漫游到新的位置区，未及时发起位置更新，发起全网寻呼可提高寻呼成功率；注：这种事件的概率一般不大。但发起全网寻呼，会极大增加 B 侧的寻呼话务量，导致 PCH 拥塞。建议：对位置区容量较大的位置区，建议不启动全网寻呼。因为这样做容易造成基站过载和 BSC CPU 过载，导致大量的寻呼消息被丢弃，从而造成寻呼成功率急剧下降。XXXX 指导书但对于位置区容量较小的位置区，可通过启动全网寻呼来提高寻呼成功率。4 是否启动预寻呼；分析：预寻呼是提高接通率的一个手段（如果寻呼不到，则取漫游号码失败，可提高被叫局的接通率），并且可减少资源的浪费。但启动预寻呼有下述负面影响：1）预寻呼失败返回的原因值会
13、影响主叫局的放音； 2）预寻呼如果间隔较长，超过 HLR 取漫游号码定时器时长，会影响接通率；5 是否启动 PSI 寻呼；分析：某些智能业务，对用户的位置信息要求精度比较高，需要发起 PSI 寻呼；但启动 PSI 寻呼会有下述影响：1） 根据以往的经验，某些款式手机在收到一次寻呼消息后，如果在很短时间内容又收到另一次寻呼，则寻呼成功率比较低；如果同时打开了 PSI 寻呼和预寻呼，则两者间的时间间隔很近。2） 启动 PSI 寻呼，会使得一次呼叫有两个寻呼响应，对 CSSR 指标有较大影响。3） 寻呼间隔如果较长，超过 HLR 对应定时器，则可能对呼叫流程产生影响，目前已知通过签约方式触发的彩铃业
14、务会有影响；如果没有特殊需要，建议不要打开 PSI 寻呼。XXXX 指导书PSI寻呼和预寻呼的启动与否不直接影响B侧的寻呼成功率指标，但由于影响B侧的CSSR指标，因此需按照具体情况取舍。6 联合寻呼分析：联合寻呼是在网络同时提供语音业务和分组业务情况下出现的，适用于即签约了 GPRS 业务，也签约了语音业务的用户（下面称为联合寻呼用户），且手机要支持 GPRS 业务。对于联合寻呼用户做语音被叫的寻呼，寻呼路由一般从 Gb 口下发，如果 Gs 口故障，则从 A 接口下发寻呼。当用户状态异常时才可能从两个接口联合下发（此时会统计为两次寻呼）。（仅使用华为公司产品）从 Gb 口下寻呼，寻呼范围为路
15、由区；从 A 口下寻呼，寻呼路由为位置区；路由区一般小于位置区（多个路由区覆盖一个位置区）；因此从 Gs 口下寻呼，寻呼话务量要小于从 A 接口下寻呼。因此在现网关闭 Gs 口时要注意对 B 侧寻呼话务量的影响。7 寻呼范围寻呼范围通常设置为 LAC。因此要详细检查 VMSC 的 LAC 定义，如果没填将不发寻呼消息，如果做多将发出大量没用的寻呼消息，会干扰系统处理浪费资源，因此要求 NSS/BSS 基站数据保持一致。寻呼策略设置建议关于寻呼次数和寻呼间隔：XXXX 指导书MSC 侧的寻呼次数、寻呼时间间隔应设置合理。对于 MSC 侧寻呼成功率的提高主要是调整寻呼方式、寻呼次数和寻呼时间间隔。
16、寻呼次数越多，寻呼成功率也越高；寻呼时间间隔必须和 BSS 侧的寻呼响应时间配合合理，才能提高寻呼成功率。例如 MSC 寻呼的时间间隔为 4s，但是BSS 侧的寻呼响应时间大部分为 4.4s，这样肯定会导致寻呼成功率较低。按照现网相同地区的寻呼策略进行设置，然后由网优人员进行调试。关于用TMSI寻呼还是IMSI寻呼：一般来说，如果 N 侧支持 TMSI 寻呼，前几次寻呼都应该采用 TMSI 寻呼，但最后一次寻呼重发应该采用 IMSI 寻呼。关于是否采用全网寻呼：在覆盖地区较差，且 B 侧寻呼负荷不高的情况下，可考虑最后一次寻呼采用全网寻呼。一般来说，寻呼方式为全网寻呼，肯定能够提高寻呼成功率。注意：并不一定是全网寻呼并寻呼次数越多，就会提高寻呼成功率，这需要考虑 BSS 侧的负荷，响应寻呼信道的利用率等，如果负荷本身就比较高，改为全网寻呼后，BSS 侧的负荷过载，同样会导致寻呼成功率较低。PSI寻呼和预寻呼按照具体需要进行启动，但要注意相
