华为WCDMA高培――寻呼问题分析

1、华为技术有限公司Huawei Technologies Co. Ltd.产品版本密级V100R001内部公开产品名称: WCDMA RNP共25页WCDMA RNO寻呼问题分析指导书(仅供内部使用）For internal use onlyHUAWEI华为技术有限公司Huawei Technologies Co., Ltd.版权所有侵权必究All rights reserved目录1概述. 82寻呼问题分析过程. 92.1 问题分析流程. 92.2 网络信息收集. 102.2.1 话统 . 102.2.2 告警 . 122.2.3 用户投诉 . 132.2.4 网络规划优化历史记录 . 132

2、.2.5 无线参数配置 . 142.3 确定优化目标. 142.4 寻呼问题定位. 142.4.1 确定基本定位方向 . 142.4.2 寻呼丢失直接原因 . 152.4.3 寻呼丢失原因深入分析 . 152.4.4 其它原因分析 . 162.5 寻呼问题优化. 162.6 优化验证. 163寻呼典型问题分析. 163.1 寻呼区域规划过大. 163.1.1 问题分析 . 163.1.2 优化措施 . 183.2 CN寻呼重发次数和时间间隔设置不合理. 183.2.1 问题分析 . 183.2.2 优化措施 . 193.3 UTRAN寻呼重发次数和时间间隔设置不合理 . 193.3.1 问题分

3、析 . 193.3.2 优化措施 . 193.4 CN使用了全网寻呼 . 193.4.1 问题分析 . 193.4.2 优化措施 . 193.5 DRX寻呼周期系数设置不合理. 203.5.1 问题分析 . 203.5.2 优化措施 . 213.6 NP值设置不合理 . 213.6.1 问题分析 . 213.6.2 优化措施 . 213.7 CN寻呼使用的UE标识 . 223.7.1 问题分析 . 223.7.2 优化措施 . 223.8 UTRAN应激活IMSI ATTACH和DETACH功能 . 223.8.1 问题分析 . 223.8.2 优化措施 . 233.9 寻呼类信道功率配比过低

4、. 233.9.1 问题分析 . 233.9.2 优化措施 . 233.10存在覆盖盲区 . 243.10.1问题分析. 243.10.2优化措施. 243.11手机性能问题 . 243.11.1问题分析. 243.11.2优化措施. 244遗留问题. 24图目录图1典型UE被叫流程 . 9图2寻呼问题分析流程 . 10图3系统消息1解析 . 23表目录表1RNC寻呼话统指标 . 11 表2UMSC寻呼话统指标 . 12 表3SGSN寻呼话统指标 . 12 表4用户投诉信息表 . 13 表5CN ID使用IMSI时寻呼区域计算结果表 . 17 表6IMSI ATTACH和DETACH标识. 2

5、2WCDMA RNO 寻呼问题 分析指导书关键词：寻呼、寻呼区域、寻呼重发摘要：本文首先阐述了寻呼问题解决的一般流程，然后针对寻呼过程可能会出现的典型问题进行 详细分析并给出其优化措施。缩略语清单：Abbreviations缩略语Full spelling英文全名Chinese explanation中文解释DRXDiscontinuous Reception非连续接收LALocation Area位置区PCHPaging Channel寻呼信道PIPaging Indication寻呼指示PICHPage Indication Channel寻呼指示信道RARoute Area路由区RANR

6、adio Access Network无线接入网络RNCRadio Network Controller无线网络控制器RNORadio Network Optimization无线网络优化WCDMAWideband Code Division Multiple Access宽带码分复用1 概述如果网络侧需要主动联系处于空闲模式、CELL_PCH 或者URA_PCH状态的UE，就要发起寻呼流程，寻呼是网络联系UE的重要途径。和其它流程相比较，寻呼流程在无 线网络中表现出频率高、流量大、突发性强等特点，寻呼性能关系到整个无线网络的性 能。所以研究寻呼问题对无线网络性能具有很强的现实意义。从UE接收

7、寻呼消息的角度来看，寻呼消息分为PAGING TYPE1和PAGING TYPE2， 由UTRAN决定发送给UE的寻呼类型。PAGING TYPE1是通过PCCH逻辑信道来寻呼处 在IDLE，CELL_PCH，URA_PCH状态的UE。PAGING TYPE2是通过DCCH来寻呼处在 CELL_FACH，CELL_DCH状态的UE。PAGING TYPE1是本文讨论的重点，PAGING TYPE2可以作为普通的RRC信令处理，本文不作讨论。网络侧会在以下情况下发起寻呼：9UE被叫：为了建立一次呼叫，核心网（CN）通过Iu接口向UTRAN发送寻呼消 息，UTRAN则将CN寻呼消息通过Uu接口上的

8、寻呼过程发送给UE，使得被寻 呼的UE发起与CN的信令连接建立过程。9小区系统消息更新：当系统消息发生改变时，UTRAN为了通知处在空闲模式、 CELL_PCH和URA_PCH状态下的UE进行系统消息更新会触发寻呼过程，以使 UE读取更新后的系统信息。对于处在CELL_FACH状态的UE，为了通知它进 行相应的系统更新需要通过BCCH发送SYSTEM INFORMATION CHANGE INDICATION消息（由于V1.2版本不支持该消息，所以对CELL_FACH状态的 UE不做处理）。9UE状态迁移：为了触发处于CELL_PCH，URA_PCH状态下的UE进行状态迁 移（比如迁移到CEL

9、L_FACH状态），UTRAN会进行一次寻呼流程，作为对 该寻呼的一种应答形式，UE会相应的发起一次小区更新或URA更新。一个典型的由寻呼引起的被叫流程如图 1 所示：CN发寻呼消息给UTRAN，UTRAN 收到寻呼消息后计算出寻呼时刻并获取目标小区，在寻呼时刻到来时将寻呼消息在空口 下发。UE寻呼成功的标志是CN收到UE的寻呼响应消息，整个过程包括寻呼下发和UE 接入等过程，UE接入过程不是本文讨论的范围，请参考接入过程指导书。寻呼过程中 可能会存在种种问题导致目标UE不能正确收到寻呼消息，如在网络群发短消息和全文 寻呼时，不合理的寻呼策略会使得寻呼信道拥塞从而造成寻呼消息大量丢失，严重情形

10、 下还会造成系统长期过载，寻呼信道功率配比过低造成寻呼成功率低。本文将对这些导 致寻呼异常的问题进行深入讨论，并给出其解决方法。UE NASUE ASNSSMSCpagingRR_PAING_INDpagingRANAPRANAPRR_EST_REQ (PAGING RESPONSE)RRC连接建立过程AUTHENTICATION REQUESTINITIAL_DIRECT_TRANSFER (PAGING RESPONSE)AUTHENTICATION RESPONSERR_SECURITY_CONTROL_REQ (IK CK)加密模式控制SETUPCALL CONFIRMRAB 建立过程

11、ALERTCONNECTCONNECT ACKNOW LEDGE图 1 典型UE被叫流程本文结构的基本结构如下：1、概述：简单介绍寻呼发起的时机、寻呼流程、寻呼常见问题等，引出全文；2、寻呼问题分析过程：论述寻呼问题的分析流程，如何逐步深入分析寻呼问题， 每一步需要做的具体工作。3、寻呼典型问题分析：分析影响寻呼常见的典型问题，包括问题的现象，原理和 优化方法。4、遗留问题：本文暂时无法解决的问题。2 寻呼问题分析过程2.1 问题分析流程寻呼问题分析流程如图 2 所示，和网络问题一般分析方法类似，寻呼问题分析步 骤大体分为四个步骤，各个步骤的主要工作是：网络信息收集：收集网络与寻呼相关话统、告

12、警、用户投诉、网络规划和优化记录、 网络参数配置等信息；确定优化目标：确定寻呼问题优化的KPI指标； 寻呼问题定位：定位导致寻呼问题的原因；寻呼问题优化：根据定位结果采用相应的优化调整措施；优化验证：验证优化后的KPI指标是否达到要求以及其它寻呼相关信息是否正常。网络信息收集确定优化目标寻呼问题定位寻呼问题优化优化验证NO是否达到优化目标？YESEND图 2 寻呼问题分析流程2.2 网络信息收集网络信息收集是寻呼问题分析的第一步，优化人员要获取待优化网络中与寻呼相关 的话统、用户投诉、告警、网络规划优化历史记录、无线参数配置等等信息，为后续进 一步的深入分析做准备。2.2.1 话统寻呼相关的话

13、统指标可以根据不同的寻呼区域分别在RNC、UMSC、SGSN话统台 上观测，RNC话统对应一个RNC区域，UMSC话统对应一个位置区，SGSN话统对应一 个路由区。在实际话统分析过程中以分析CN的话统为主，并把RNC和CN的话统数据结 合起来分析。如果话统台上没有寻呼相关的话统任务运行，需要联系局方人员创建寻呼 话统任务。下面在我司寻呼话统实现的基础上分别讨论RNC、UMSC、SGSN与寻呼相 关的话统。RNC的话统情况如表1 所示，需要关注CN_PAGE_IDLE_UE_SUCC_RATE（CN发 起的寻呼空闲状态UE的寻呼成功率）和UTRAN_PAGE1_SUCC_RATE（UTRAN发起

14、寻呼类型1的寻呼成功率），这两个指标基本表征了RNC对应寻呼区域的寻呼成功率。 CN_PAGE_IDLE_UE_SUCC_RATE 从 CN 的 角度考察 了寻呼的 成功率， UTRAN_PAGE1_SUCC_RATE除了包含CN寻呼情况外，还包含UTRAN系统消息更新 和UE状态迁移两种情况（这时UE的寻呼响应消息是小区更新）。这两个指标可以用来 分析一个RNC区域的寻呼性能，一个RNC区域一般包括一个或多个位置区。表1RNC寻呼话统指标话统指标名称话统指标含义话统指标标准测量点CN_PAGE_REQ统计IU接口寻呼的次数收到CN发起的PAGING消息CN_PAGE_IDLE_UE_REQ统

15、计IU接口寻呼空闲用户的次数收到CN发起的PAGING消息，且被寻呼的UE当前为空闲态CN_PAGE_IDLE_UE_SUCC统计寻呼空闲用户成功 的次数收到UE的RRC连接请求消息，且请求原 因 为被叫类原因 ，如 “TerminatingConversational Call”UTRAN_PAGE1_REQ统计由 UTRAN 侧发起 的PAGING TYPE 1消息 的次数由UTRAN侧发起PAGING TYPE 1消息UTRAN_PAGE1_SUCC统计由 UTRAN 侧发起 PAGING TYPE 1消息， 收到UE成功响应的次数UTRAN侧收到UE的寻呼响应类消息CN_PAGE_ID

16、LE_UE_SUCC_R ATE统计CN发起的寻呼空闲 状态UE的寻呼成功率是计算指标，由计算公式CN_PAGE_IDLE_UE_SUCC/ CN_PAGE_IDLE_UE_REQ得到UTRAN_PAGE1_SUCC_RATE统计 UTRAN 发起寻呼 类型1的寻呼成功率是计算指标，由计算公式UTRAN_PAGE1_SUCC/UTRAN_PA GE1_REQ得到UMSC寻呼相关话统指标都是基于一个位置区的，如表2 所示。一般情况下，位置区不会跨RNC、BSC配置，可以统计一个位置区的寻呼成功率、第一次寻呼成功率、非 第一次寻呼成功率。位置区的寻呼成功率关注一个位置区的寻呼状况，并不关心寻呼重

17、发次数，而第一次寻呼成功率、非第一次寻呼成功率关注寻呼重发次数对寻呼成功率的 影响。位置区寻呼成功率 = 第一次发寻呼次数下发寻呼无响应消息数 第一次发寻呼次数第一次寻呼成功率 = 第一次寻呼响应次数 第一次发寻呼次数非第一次寻呼成功率 =接口重复发寻呼次数接口重复寻呼响应次数表2UMSC寻呼话统指标话统指标名称话统指标含义话统指标标准测量点第一次发寻呼次数MSC 第一次发 Paging Req 的次数MSC 向 RNC/BSC 发 PAGING 消息时统计第一次寻呼响应次数MSC 第一 次发 Paging 消息 后，成功收到响应次数第一次 Paging消息发出后，MSC 收到被叫发的 PAG

18、ING RESPONSE消息时 统计接口重复发寻呼次数MSC 不是第一次发 Paging的次数MSC 向 RNC/BSC 发PAGING 消息时统计接口重复寻呼响应次数MSC 非第一次发 PAGING 消 息后，成功收到响应次数非第一次 PAGING 消息发出后，MSC收到 PAGING RESPONSE 消息时统 计Iu接口第一次发寻呼次数Iu接口第一次发Paging次数MSC向RNC发Paging消息时统计Iu接口重复发寻呼次数Iu 接口非第一次发 Paging 的次数MSC 向 RNC 非第一次发 Paging 消息时统计下发寻呼无响应次数未收到寻 呼响应 (PAGINGRESPONSE

19、)消息次数寻呼定时器超期统计SGSN寻呼相关话统指标都是基于一个路由区的，如表3 所示，可以得到某路由区的寻呼成功率。路由区寻呼成功率 RA分组寻呼请求次数RA分组寻呼失败次数RA分组寻呼请求次数表3SGSN寻呼话统指标话统指标名称话统指标含义话统指标标准测量点每个RA分组寻呼请求 次数这项测量提供了在特定路由区中下发分组寻呼请求的次数，不包 括重发的消息。SGSN 发送 Iu 接口寻呼请求消息 （PAGING），消息中的CN Domain为PS每个RA分组寻呼失败次数这项测量提供了在特定路由区中分组寻呼失败的次数重发寻呼消息次数达到最大值在话统分析过程中，要重点关注“位置区寻呼成功率”和“路

20、由区寻呼成功率”，这 是 衡 量 寻 呼 性 能 的 注 意 KPI 指 标 。 RNC 的 寻 呼 话 统 指 标 CN_PAGE_IDLE_UE_SUCC_RATE 和UTRAN_PAGE1_SUCC_RATE 可以作为分析参 考。2.2.2 告警按照目前我司的实现，CN和寻呼相关的告警只有“RNC过载”，当CN接收到RNC的过载消息引发此告警。RNC为保证系统运行的稳定性，避免突发的消息风暴对系统 的冲击，对包括寻呼在内的某些处理频率很高的消息进行了流控。当RNC收到CN的寻呼消息后，判断系统如果处于寻呼流控状态，就会丢弃寻呼消息，并记录下寻呼消息丢 失的个数。如果寻呼丢失比例达到一定的

21、门限，RNC就会向CN发Overload消息，CN就 会控制消息发送流量按照一定的步长减少。如果在一定的时间内没有收到Overload消 息，IU的消息流量会逐步增长直至恢复正常。RNC目前寻呼相关的告警是“流量控制告警”，当RNC处于寻呼流控状态下寻呼 消息会无条件丢失。当单板子系统的CPU占用率或者单板子系统的消息包占用率超过门 限时系统切换到流控状态，并会产生流量控制告警。当系统从流控状态恢复正常工作状 态时，会产生流量控制恢复告警。但是发生“流量控制告警”不一定会丢寻呼，因为 RNC对不同的流控对象（寻呼、串口打印、消息跟踪等）有不同的流控门限，只要有 流控发生就会告警，但是只有寻呼流

22、控发生才会丢寻呼。2.2.3 用户投诉如果寻呼消息丢失导致手机不能做被叫，主叫用户会听到系统提示音“用户不在服 务区”。可以从局方1860客服中心了解用户投诉情况或直接联系投诉人了解不在服务区 发生情况，要重点关注手机被叫失败的情况，需要收集的信息如表4 所示但不限于这些内容【5】：表4用户投诉信息表时间投诉用户姓名投诉用户号码被叫用户号码被叫手机类型投诉地点是否经常发生过程描述整理投诉信息寻找规律观察是否存在下属情况：9是否白天忙时和夜里闲时都发生。如果寻呼失败在话务高峰，重点分析寻呼拥 塞的情形，如果不是在话务高峰，要分析其它因素；9是否被叫手机类型相同。可能存在手机自身问题；9是否投诉地

23、点集中。可能是因为信号覆盖问题； 找到投诉的规律能加快问题解决的速度。2.2.4 网络规划优化历史记录获取网络规划报告，重点关注寻呼区域（位置区、路由区）的划分。网络规划报告 获取方式：如果是网络开通前的优化，则规划报告可以从负责此项目的规划经理处获得。 如果是开通后网络的优化，则规划报告一般可从客户处获得。以上规划报告应包括网络 所经历各次扩容的规划报告。对于开通后网络，可能在本次优化之前已经经历了优化过程。在本次优化开始之前 应获得各次优化历史记录，了解各次网络调整过程及遗留问题。应重点关注是否存在覆 盖空洞、系统过载、寻呼丢失、寻呼信道功率配比低等方面的优化记录。2.2.5 无线参数配置

24、和寻呼相关的参数如下，优化前要注意收集：9CN寻呼重发次数、寻呼时间间隔；9UTRAN寻呼重发次数、寻呼时间间隔；9DRX寻呼周期系数k（DRX寻呼周期 = 2k）；9一个PICH帧包含的寻呼指示数目NP；9PICH、PCH信道功率配比；9CN是否使用全局寻呼；9CN寻呼使用的UE ID（是IMSI还是TMSI、PTMSI）2.3 确定优化目标“位置区寻呼成功率”和“路由区寻呼成功率”这两个KPI指标要达到优化要求， 建议寻呼成功率达到86%以上【3】。2.4 寻呼问题定位2.4.1 确定基本定位方向寻呼问题优化目的是保证寻呼的KPI指标，UE能否成功回寻呼响应直接关系到寻呼 的KPI指标。从

25、这个角度上看，寻呼问题大体上可以分为三个方向：9寻呼消息根本没有在空口下发。如果寻呼消息根本没有在空口下发，最大的可 能是寻呼丢失，寻呼丢失是寻呼过程中最常见的问题，也是本文分析的重点。 寻呼丢失的具体分析见2.4.2和2.4.3两部分。当然寻呼没有发出也有可能是IUB 口传输故障或其它设备故障，这个问题查看告警就能知道，这里不作赘述。9寻呼消息下发了，UE没有收到或者是收到错误的寻呼消息。按照用户投诉的 情况具体区分，如果只是UE作被叫有问题（语音提示“用户不在服务区”）， 可能是PICH和PCH的功率配比过低或手机性能有问题；如果UE主叫被叫都有 问题，可能该区域存在信号覆盖盲区。9UE收

26、到寻呼后回寻呼响应失败。如图 1 所示，这个问题属于接入失败的问题， 解决方法参考WCDMA RNP 接入过程问题分析指导书。在寻呼问题定位过程中，可以通过分析寻呼话统、告警和用户投诉来确定是哪种情 况。寻呼丢失一般发生在话务量高的时间段，查看CN的话统“位置区寻呼成功率”和 “路由区寻呼成功率”，如果这两个指标总是在话务量高的时间段表现得比较低（低于86%），用户投诉也是集中在这一时间段，则说明寻呼丢失较严重，需要重点分析寻呼 丢失的情况。同时查看CN是否有RNC过载告警、RNC是否有流控告警，如果有这些告 警存在说明寻呼丢失的可能性很大。如果这两个指标低的事件在时间上近似均匀分布，用户投诉

27、具有地域性，就要检查 除“寻呼丢失”外的原因了：寻呼信道配比、信号覆盖、手机性能等。进一步分析寻呼问题需要到现场进行拨测分析，时间选择在话务量高的时间段，地 点选择用户投诉集中的区域，拨测过程中可以在CN和RNC的维护台上跟踪寻呼消息的 下发和UE回寻呼响应的过程。2.4.2 寻呼丢失直接原因寻呼在以下情况下会丢失：1、RNC系统处于寻呼流控状态。因为寻呼消息发送频率高，RNC对寻呼进行 了流控，当RNC检查到CPU占有率或者消息队列占有率达到预先设置的门 限时就会触发寻呼流控，在寻呼流控状态下寻呼消息无条件丢弃。2、PCH容量限制。以PCH目前的编码方式，一个TTI只能传输240bits，如

28、果使 用IMSI寻呼，同一寻呼时刻只能寻呼3个UE；如果使用TMSI和PTMSI寻呼， 同一寻呼时刻只能寻呼5个UE【2】。如果在同一寻呼时刻寻呼UE的个数 超过系统的处理能力，就会造成寻呼丢失。3、其它原因：如IUB口传输故障和设备故障等，这类故障发生几率小，可以 从告警台看出。2.4.3 寻呼丢失原因深入分析导致寻呼丢失的直接原因时系统过载、寻呼信道过载等，进一步地深入分析其原因 是CN和RNC使用了不适当的寻呼策略，具体分析见如下链接：9寻呼区域规划过大9CN寻呼重发次数和时间间隔设置不合理9UTRAN寻呼重发次数和时间间隔设置不合理9CN使用了全网寻呼9DRX寻呼周期系统设置不合理9N

29、P值设置不合理9CN使用的UE标识不合理2.4.4 其它原因分析9寻呼类信道功率配比过低9存在覆盖盲区9手机性能问题2.5 寻呼问题优化寻呼问题优化方法针对各个专题在第3节有详细描述。2.6 优化验证在对网络实施了优化调整后，需要验证优化的结果。常用的验证方式有：运行并查 看寻呼相关话统、查看是否有寻呼告警、收集用户投诉信息、实地作手机被叫拨测等。9话统：主要查看“位置区寻呼成功率”和“路由区寻呼成功率”是否达到事先 确定的优化目标86%；9告警：查看CN是否有“RNC过载”告警，RNC是否有流控告警；9用户投诉：在一段时间内是否有用户被叫投诉；9拨测：选择话务高峰期和用户投诉地测试手机被叫成

30、功率，拨测不需要接通， 电话只需要听回铃音或提示音即可。3 寻呼典型问题分析3.1 寻呼区域规划过大3.1.1 问题分析CN通常在一个寻呼区域（位置区或者路由区）对目标UE进行寻呼，这种寻呼又称 作本局寻呼。对CS域业务来说，CN使用位置区来识别和寻呼UE。协议中，位置区被定义为移动终端在不更新VLR的情况下可以自由移动的区域。一个位置区可以涵盖一个或 几个小区。对PS域业务来说，CN使用routing area来识别和寻呼UE。RA定义为在特定操 作模式下，移动终端不需要更新SGSN的情况下可以自由移动的区域。一个RA可以包含 一个或几个小区。路由区和位置区的关系采用了GSM中定义的关系，即

31、：路由区可以 和位置区的大小相等，或者只是某个位置区的子集。如果寻呼区域规划过大，网络寻呼移动台的同一寻呼消息会在许多小区中发送，会 导致寻呼信道负荷过重，同时增加Iub接口上的信令流量。如果小区的寻呼信道在一段 时间内负荷过重，会导致寻呼该小区UE的寻呼消息被丢掉，造成在服务区内的开机用 户不能被寻呼到（用户不在服务区）问题。反之，如果寻呼区域规划过小，那么会造成用户在移动过程进行频繁的位置更新， 从而增加系统的信令流量。对于建网初期，PS业务寻呼需求不大，此时RA不需要刻意 划分的过小，可按照n1来规划。随着网络的不断演进，PS业务的需求不断增多，这 时候可适当减小RA的大小。当然，RA过

32、小也会导致用户在移动过程中寻呼区域更新的 事件增多而导致网络侧信令开销变大，同时也需要考虑到频繁的位置更新会影响手机的 待机时间。寻呼区域的最大值由寻呼信道容量决定。寻呼区域容量的估算方法见【2】，引用【2】典型环境下的寻呼混合容量如表5 ：表5CN ID使用IMSI时寻呼区域计算结果表Erlang P eHrDRXCyncleLengthInN RAMmixRALA131.0.133133231.0.95190331.0.74222431.0.61244531.0.51255631.0.44264731.0.39273831.0.35280931.0.322881031.0.29290表中各个字段的含义：n是位置区大小和路由区大小的比例，LA=nRA; Mmix是PCH每个TTI能够寻呼UE的个数； H 表示在一个DRX cycle length周期内的一条特定寻呼块可支持的话务量；Erlang PerDRX