W网规高培寻呼问题分析

《W网规高培寻呼问题分析》由会员分享，可在线阅读，更多相关《W网规高培寻呼问题分析（58页珍藏版）》请在金锄头文库上搜索。

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

2、从UE接收寻呼消息的角度来看 寻呼消息分为PAGINGTYPE1和PAGINGTYPE2 由UTRAN决定发送给UE的寻呼类型 PAGINGTYPE1是通过PCCH逻辑信道来寻呼处在IDLE CELL PCH URA PCH状态的UE PAGINGTYPE2是通过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为保证系统运行的稳定性 避免突发的消息风暴对系统的冲击 对包括寻呼在内的某些处理频率很高的消息进行了流控 当RNC收到CN的寻呼消息后 判断系统如果处于

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

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

9、记录 信息收集 参数配置和寻呼相关的参数如下 优化前要注意收集 CN寻呼重发次数 寻呼时间间隔 UTRAN寻呼重发次数 寻呼时间间隔 DRX寻呼周期系数k DRX寻呼周期 2k 一个PICH帧包含的寻呼指示数目NP PICH PCH信道功率配比 CN是否使用全局寻呼 CN寻呼使用的UEID 是IMSI还是TMSI PTMSI 确定优化目标 确定优化KPI目标 位置区寻呼成功率路由区寻呼成功率 位置区寻呼成功率 和 路由区寻呼成功率 这两个KPI指标要达到优化要求 如寻呼成功率达到86 以上 第一章寻呼问题的分析流程 第一节分析流程第二节信息收集第三节问题定位第四节优化验证 问题定位 确定定位方

10、向寻呼问题优化目的是保证寻呼的KPI指标 UE能否成功回寻呼响应直接关系到寻呼的KPI指标 从这个角度上看 寻呼问题可以分为以下三个方向 寻呼消息根本没有在空口下发 最大的可能是寻呼丢失 也是寻呼过程中最常见的问题 具体分析见随后两节 寻呼消息下发 UE没有收到或者是收到错误的寻呼消息 按照用户投诉的情况具体区分 如果只是UE作被叫有问题 可能是PICH和PCH的功率配比过低或手机性能有问题 如果UE主叫被叫都有问题 可能该区域存在信号覆盖盲区 UE收到寻呼后回寻呼响应失败 属于接入失败的问题 解决方法参考 接入过程问题分析 问题定位 确定定位方向在寻呼问题定位过程中 可以通过分析寻呼话统 告

11、警和用户投诉来确定 寻呼丢失一般发生在话务量高的时间段 查看CN的话统 位置区寻呼成功率 和 路由区寻呼成功率 如果这两个指标总是在话务量高的时间段表现得比较低 用户投诉也是集中在这一时间段 则说明寻呼丢失较严重 需要重点分析寻呼丢失的原因 同时查看CN是否有RNC过载告警 RNC是否有流控告警 如果有这些告警存在说明寻呼丢失的可能性很大 如果这两个指标低的事件在时间上近似均匀分布 用户投诉具有地域性 就要检查除 寻呼丢失 外的原因了 如寻呼信道配比 信号覆盖 手机性能等 进一步分析寻呼问题需要到现场进行拨测分析 时间选择在话务量高的时间段 地点选择用户投诉集中的区域 拨测过程中可以在CN和R

12、NC的维护台上跟踪寻呼消息的下发和UE回寻呼响应的过程 问题定位 寻呼丢失原因寻呼在以下情况下会丢失 RNC系统处于寻呼流控状态 当RNC检查到CPU占有率或者消息队列占有率达到预先设置的门限时 就会触发寻呼流控 在寻呼流控状态下寻呼消息无条件丢弃 PCH容量限制 以PCH目前的编码方式 一个TTI只能传输240bits 如果使用IMSI寻呼 同一寻呼时刻只能寻呼3个UE 如果使用TMSI和PTMSI寻呼 同一寻呼时刻只能寻呼5个UE 如果在同一寻呼时刻寻呼UE的个数超过系统的处理能力 就会造成寻呼丢失 其它原因 如IUB口传输故障和设备故障等 这类故障发生几率小 会有相应告警伴随 问题定位

13、丢失原因分析导致寻呼丢失的直接原因是系统过载 寻呼信道过载等 进一步地深入分析其原因可能是CN和RNC使用了不适当的寻呼策略 主要表现在以下几个方面 寻呼区域规划过大 CN寻呼重发次数和时间间隔设置不合理 UTRAN寻呼重发次数和时间间隔设置不合理 CN使用了全网寻呼 DRX寻呼周期系统设置不合理 NP值设置不合理 CN使用的UE标识不合理详细的分析参见后面的案例 问题定位 其它原因分析可能存在的其它方面的原因有 寻呼类信道功率配比过低存在覆盖盲区手机性能问题详细的分析参见后面的案例 第一章寻呼问题的分析流程 第一节分析流程第二节信息收集第三节问题定位第四节优化验证 问题优化 针对各个专题的寻

14、呼问题优化方法详见第二章节的描述 优化验证 在对网络实施了优化调整后 需要验证优化的结果 话统 查看 位置区寻呼成功率 和 路由区寻呼成功率 是否达到预定的优化目标 告警 查看CN是否有 RNC过载 告警 RNC是否有流控告警 用户投诉 在一段时间内是否有用户被叫投诉 拨测 选择话务高峰期和用户投诉地测试手机被叫成功率 拨测不需要接通 电话只需要听回铃音或提示音即可 课程内容 T 第一章寻呼问题的分析流程第二章寻呼问题的典型案例 第二章寻呼问题的典型案例 寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的U

15、E标识IMSIATTACH DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题 寻呼区域规划过大 现象与分析CN通常在一个寻呼区域 位置区或者路由区 对目标UE进行寻呼 这种寻呼又称作本局寻呼 对CS域业务来说 CN使用位置区来识别和寻呼UE 位置区被定义为移动终端在不更新VLR的情况下可以自由移动的区域 一个位置区可以涵盖一个或几个小区 对PS域业务来说 CN使用routingarea来识别和寻呼UE RA定义为在特定操作模式下 移动终端不需要更新SGSN的情况下可以自由移动的区域 一个RA可以包含一个或几个小区 路由区和位置区的关系采用了GSM中定义的关系 即 路由区可以和位置

16、区的大小相等 或者只是某个位置区的子集 寻呼区域规划过大 现象与分析如果寻呼区域规划过大 网络寻呼移动台的同一寻呼消息会在许多小区中发送 会导致寻呼信道负荷过重 同时增加Iub接口上的信令流量 如果小区的寻呼信道在一段时间内负荷过重 会导致寻呼该小区UE的寻呼消息被丢掉 造成在服务区内的开机用户不能被寻呼到 用户不在服务区 问题 反之 如果寻呼区域规划过小 那么会造成用户在移动过程进行频繁的位置更新 从而增加系统的信令流量 频繁的位置更新会影响手机的待机时间 对于建网初期 PS业务寻呼需求不大 此时RA不需要刻意划分的过小 可按照n 1来规划 随着网络的不断演进 PS业务的需求不断增多 这时候可适当减小RA的大小 优化措施对网络容量或寻呼量大于一定门限的位置区进行位置区分裂 可以有效降低寻呼消息流量 第二章寻呼问题的典型案例 寻呼区域规划过大CN寻呼参数设置不合理UTRAN寻呼参数设置不合理CN使用了全网寻呼DRX寻呼参数设置不合理NP值设置不合理CN寻呼使用的UE标识IMSIATTACH DETACH功能寻呼类信道功率配比过低存在覆盖盲区手机性能问题 CN寻呼参数设置不合理 现象与分