华为技术培训教程-寻呼问题分析培训课件

《华为技术培训教程-寻呼问题分析培训课件》由会员分享，可在线阅读，更多相关《华为技术培训教程-寻呼问题分析培训课件（58页珍藏版）》请在金锄头文库上搜索。

1、,WCDMA RNO 寻呼问题分析,前言,寻呼是网络联系UE的重要途径，和其它流程相比较，寻呼流程在无线网络中表现出频率高、流量大、突发性强等特点，寻呼性能关系到整个无线网络的性能。所以研究寻呼问题对无线网络性能具有很强的现实意义。,课程目标,寻呼问题的分析流程 寻呼问题的典型案例,学习完本课程，您将能够熟悉：,概述,如果网络侧需要主动联系处于空闲模式、CELL_PCH 或者URA_PCH状态的UE，就要发起寻呼流程，寻呼是网络联系UE的重要途径。 和其它流程相比较，寻呼流程在无线网络中表现出频率高、流量大、突发性强等特点，寻呼性能关系到整个无线网络的性能。 从UE接收寻呼消息的角度来看，寻呼

2、消息分为PAGING TYPE1和PAGING TYPE2。PAGING TYPE1是通过PCCH逻辑信道来寻呼处在IDLE，CELL_PCH，URA_PCH状态的UE；PAGING TYPE2是通过DCCH来寻呼处在CELL_FACH，CELL_DCH状态的UE。,概述,网络侧会在以下情况下发起寻呼： UE被叫； 小区系统消息更新； UE状态迁移； 寻呼过程中可能会存在种种问题导致目标UE不能正确收到寻呼消息，如在网络群发短消息和全文寻呼时，不合理的寻呼策略会使得寻呼信道拥塞从而造成寻呼消息大量丢失，严重情形下还会造成系统长期过载；寻呼信道功率配比过低造成寻呼成功率低。 本文将对这些导致寻呼

3、异常的问题进行深入分析，并给出其解决方法。 一个典型的由寻呼引起的被叫流程如下图所示。,概述,UE被叫流程图：,课程内容,T,第一章 寻呼问题的分析流程 第二章 寻呼问题的典型案例,第一章 寻呼问题的分析流程,第一节 分析流程 第二节 信息收集 第三节 问题定位 第四节 优化验证,分析流程,分析流程,寻呼问题分析流程如图所示，大体分为以下几个步骤： 网络信息收集：收集网络与寻呼相关话统、告警、用户投诉、网络规划和优化记录、网络参数配置等信息； 确定优化目标：确定寻呼问题优化的KPI指标； 寻呼问题定位：定位导致寻呼问题的原因； 寻呼问题优化：根据定位结果采用相应的优化调整措施； 优化验证：验证

4、优化后的KPI指标是否达到要求，以及其它寻呼相关信息是否正常。,第一章 寻呼问题的分析流程,第一节 分析流程 第二节 信息收集 第三节 问题定位 第四节 优化验证,信息收集,网络信息收集是寻呼问题分析的第一步，优化人员要获取待优化网络中与寻呼相关的话统、用户投诉、告警、网络规划优化历史记录、无线参数配置等等信息，为后续进一步的深入分析做准备。 需要收集的信息主要包括以下几个方面： 话统 告警 用户投诉 优化历史记录 参数配置,信息收集,话统 寻呼相关的话统指标可以根据不同的寻呼区域分别在RNC、UMSC、SGSN话统台上观测；RNC话统对应一个RNC区域，UMSC话统对应一个位置区，SGSN话

5、统对应一个路由区。 在实际话统分析过程中需要把RNC和CN的话统数据结合起来分析。 RNC的话统中，需要关注“CN_PAGE_IDLE_UE_SUCC_RATE” 和“UTRAN_PAGE1_SUCC_RATE”，这两个指标基本表征了RNC对应寻呼区域的寻呼成功率；前者从CN的角度考察了寻呼的成功率，后者除了包含CN寻呼情况外，还包含UTRAN系统消息更新和UE状态迁移两种情况，这两个指标可以用来分析一个RNC区域的寻呼性能。一个RNC区域一般包括多个位置区。,信息收集,话统（二） UMSC寻呼相关话统指标都是基于一个位置区的。一般情况下，位置区不会跨RNC、BSC配置，可以统计一个位置区的寻

6、呼成功率、第一次寻呼成功率、非第一次寻呼成功率。 位置区的寻呼成功率关注一个位置区的寻呼状况，并不关心寻呼重发次数，而第一次寻呼成功率、非第一次寻呼成功率关注寻呼重发次数对寻呼成功率的影响。 SGSN寻呼相关话统指标都是基于一个路由区的，可以得到某路由区的寻呼成功率。 在话统分析过程中，要重点关注“位置区寻呼成功率”和“路由区寻呼成功率”，这是衡量寻呼性能的KPI指标。,信息收集,告警 按照目前我司的实现，CN和寻呼相关的告警只有“RNC过载”，当CN接收到RNC的过载消息引发此告警。 RNC为保证系统运行的稳定性，避免突发的消息风暴对系统的冲击，对包括寻呼在内的某些处理频率很高的消息进行了流

7、控。当RNC收到CN的寻呼消息后，判断系统如果处于寻呼流控状态，就会丢弃寻呼消息，并记录下寻呼消息丢失的个数。如果寻呼丢失比例达到一定的门限，RNC就会向CN发Overload消息，CN就会控制消息发送流量按照一定的步长减少。如果在一定的时间内没有收到Overload消息，IU的消息流量会逐步增长直至恢复正常。 RNC目前寻呼相关的告警是“流量控制告警”，当RNC处于寻呼流控状态下寻呼消息会无条件丢失。当系统从流控状态恢复时，会产生流量“控制恢复告警”。,信息收集,用户投诉 如果寻呼消息丢失导致手机不能做被叫，主叫用户会听到系统提示音“用户不在服务区”。 可以客户处了解用户投诉情况或直接联系投

8、诉人了解不在服务区发生情况，要重点关注手机被叫失败的情况。 整理投诉信息，寻找规律，观察是否存在下属情况： 是否忙时和闲时都发生；如果寻呼失败在话务高峰，重点分析寻呼拥塞的情形，如果不是在话务高峰，要分析其它因素； 是否被叫手机类型相同，可能存在手机自身问题； 是否投诉地点集中，可能是因为信号覆盖问题； 找到投诉的规律能加快问题解决的速度。,信息收集,优化历史记录 获取网络规划报告，重点关注寻呼区域（位置区、路由区）的划分。规划报告应包括网络所经历各次扩容的规划报告。 对于开通后网络，可能在本次优化之前已经经历了优化过程，在本次优化开始之前应获得各次优化历史记录，了解各次网络调整过程及遗留问题

9、。 应重点关注是否存在覆盖空洞、系统过载、寻呼丢失、寻呼信道功率配比低等方面的优化记录。,信息收集,参数配置 和寻呼相关的参数如下，优化前要注意收集： CN寻呼重发次数、寻呼时间间隔； UTRAN寻呼重发次数、寻呼时间间隔； DRX寻呼周期系数k（DRX寻呼周期 = 2k*10ms）； 一个PICH帧包含的寻呼指示数目NP； PICH、PCH信道功率配比； CN是否使用全局寻呼； CN寻呼使用的UE ID（IMSI、TMSI、PTMSI）；,确定优化目标,确定优化KPI目标： 位置区寻呼成功率 路由区寻呼成功率 “位置区寻呼成功率”和“路由区寻呼成功率”这两个KPI指标要达到优化要求，如寻呼成

10、功率达到85%及以上（ 80% 90%）。,第一章 寻呼问题的分析流程,第一节 分析流程 第二节 信息收集 第三节 问题定位 第四节 优化验证,问题定位,确定定位方向 寻呼问题优化目的是保证寻呼的KPI指标，UE能否成功回寻呼响应直接关系到寻呼的KPI指标。从这个角度上看，寻呼问题可以分为以下三个方向： 寻呼消息根本没有在空口下发；最大的可能是寻呼丢失，也是寻呼过程中最常见的问题。具体分析见随后两节。 寻呼消息下发，UE没有收到或者是收到错误的寻呼消息；按照用户投诉的情况具体区分，如果只是UE作被叫有问题，可能是PICH和PCH的功率配比过低或手机性能有问题；如果UE主叫被叫都有问题，可能该区

11、域存在信号覆盖盲区。 UE收到寻呼后回寻呼响应失败；属于接入失败的问题，解决方法参考“接入过程问题分析”。,问题定位,确定定位方向 在寻呼问题定位过程中，可以通过分析寻呼话统、告警和用户投诉来确定。 寻呼丢失一般发生在话务量高的时间段，查看CN的话统“位置区寻呼成功率”和“路由区寻呼成功率”，如果这两个指标总是在话务量高的时间段表现得比较低，用户投诉也是集中在这一时间段，则说明寻呼丢失较严重，需要重点分析寻呼丢失的原因。同时查看CN是否有RNC过载告警、RNC是否有流控告警，如果有这些告警存在说明寻呼丢失的可能性很大。 如果这两个指标低的事件在时间上近似均匀分布，用户投诉具有地域性，就要检查除

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

13、呼，同一寻呼时刻只能寻呼5个UE；如果在同一寻呼时刻寻呼UE的个数超过系统的处理能力，就会造成寻呼丢失。 其它原因，如IUB口传输故障和设备故障等，这类故障发生几率小，会有相应告警伴随。,问题定位,丢失原因分析 导致寻呼丢失的直接原因是系统过载、寻呼信道过载等，进一步地深入分析其原因可能是CN和RNC使用了不适当的寻呼策略，主要表现在以下几个方面： 寻呼区域规划过大 CN寻呼重发次数和时间间隔设置不合理 UTRAN寻呼重发次数和时间间隔设置不合理 CN使用了全网寻呼 DRX寻呼周期系统设置不合理 NP值设置不合理 CN使用的UE标识不合理 详细的分析参见后面的案例。,问题定位,其它原因分析 可

14、能存在的其它方面的原因有： 寻呼类信道功率配比过低 存在覆盖盲区 手机性能问题 详细的分析参见后面的案例。,第一章 寻呼问题的分析流程,第一节 分析流程 第二节 信息收集 第三节 问题定位 第四节 优化验证,问题优化,针对各个专题的寻呼问题优化方法详见第二章节的描述。,优化验证,在对网络实施了优化调整后，需要验证优化的结果： 话统：查看“位置区寻呼成功率”和“路由区寻呼成功率”是否达到预定的优化目标； 告警：查看CN是否有“RNC过载”告警，RNC是否有流控告警； 用户投诉：在一段时间内是否有用户被叫投诉； 拨测：选择话务高峰期和用户投诉地测试手机被叫成功率，拨测不需要接通，电话只需要听回铃音

15、或提示音即可。,课程内容,T,第一章 寻呼问题的分析流程 第二章 寻呼问题的典型案例,第二章 寻呼问题的典型案例,寻呼区域规划过大 CN寻呼参数设置不合理 UTRAN寻呼参数设置不合理 CN使用了全网寻呼 DRX寻呼参数设置不合理 NP值设置不合理 CN寻呼使用的UE标识 IMSI ATTACH/DETACH功能 寻呼类信道功率配比过低 存在覆盖盲区 手机性能问题,寻呼区域规划过大,现象与分析 CN通常在一个寻呼区域（位置区或者路由区）对目标UE进行寻呼，这种寻呼又称作本局寻呼。 对CS域业务来说，CN使用位置区来识别和寻呼UE，位置区被定义为移动终端在不更新VLR的情况下可以自由移动的区域，

16、一个位置区可以涵盖一个或几个小区。 对PS域业务来说，CN使用routing area来识别和寻呼UE，RA定义为在特定操作模式下，移动终端不需要更新SGSN的情况下可以自由移动的区域，一个RA可以包含一个或几个小区。 路由区和位置区的关系采用了GSM中定义的关系，即：路由区可以和位置区的大小相等，或者只是某个位置区的子集。,寻呼区域规划过大,现象与分析 如果寻呼区域规划过大，网络寻呼移动台的同一寻呼消息会在许多小区中发送，会导致寻呼信道负荷过重，同时增加Iub接口上的信令流量。如果小区的寻呼信道在一段时间内负荷过重，会导致寻呼该小区UE的寻呼消息被丢掉，造成在服务区内的开机用户不能被寻呼到（用户不在服务区）问题。 反之，如果寻呼区域规划过小，那么会造成用户在移动过程进行频繁的位置更新，从而增加系统的信令流量，频繁的位置更新会影响手机的待机时间。 对于建网初期，PS业务寻呼需求不大，此时RA不需要刻意划分的过小，可按照n1来规划。随着网络的不断演进，PS业务的需求不断增多，这时候可适当减小RA的大小。 优化