企业培训_td精英营专题培训ps掉线率优化

北京移动TD精英营专题培训 案例分析1 PS掉线率优化 应提前具备或了解的相关知识 HSDPA技术相关知识UE连接态的四种状态 四种状态 迁徙机制 目前网络侧及终端支持情况 PS业务特性及常见KPI定义信令流程及码流解码分析能力重配机制与信令 物理信道重配 传输信道重配 RB重配 小区更新与无线链路失败 七种情况 小区更新的标准流程 RBC算法与4A 4B事件三个常用协议TS25 331 TS25 433 TS25 413 问题描述 目前 北京某区域TD网络各项指标均基本正常 但PS掉线率最近一直居高不下 对比同样采用我司设备的其他区域及其他城市的TD网络的指标 不难发现PS掉线率远高其他地区及城市 最严重的时候日平均达到53 但从小区指标来看 全网没有掉线次数特别突出的小区 属普遍存在现象 PS掉线率计算公式 CMCC集团公司公布的PS掉线率公式如下 由PS掉线率统计公式可知 RNC请求释放分组域的RAB一次记为掉线一次 而RNC请求释放的分组域RAB的原因就可以理解为PS掉线的原因 思考 1 在TD中 什么是掉话 在网络侧以及路测端 又是如何定义掉话的 2 只要UE开始读广播消息了 就是掉话 此种说法是否正确 PS掉线原因统计 从上图指标看 问题区域RNC请求释放的分组域RAB 即PS掉线 次数达到181次 其中 原因值为Ue Operate TimeOut的释放次数达到123次 占掉线总数的68 原因值为Radiolinkfailure的次释放次数达到31次 占总掉线次数的17 这两种原因引起的释放次数占了全网掉线总次数的85 是引起问题区域PS掉线率高的主要原因 原因分析 由以上分析可知 Ue Operate TimeOut UE响应超时 和Radiolinkfailure 无线链路失败 是导致PS掉线率的两个主要原因 如果能将这两类问题解决 那么PS掉线率高的问题就迎刃而解了 无线链路失败 Radiolinkfailure 系统出现无线链路失败的原因可以分为三类 a 终端侧出现异常当终端发生异常 没有上发信号 导致基站侧检测不到上行信号而报无线链路失败 终端侧的异常包括 终端本身出现异常 比如死机 终端与电脑的连接出现异常 比如因为连接线 USB插口 插槽松动而断线 或终端在电脑上的驱动程序出现异常 终端在电脑上的应用程序出现异常 电脑出现异常导致终端方面异常 思考 如果终端侧出现异常 用户一般如何行为 提示 一般用户会对终端进行重启 数据卡重插拔或者电脑关开机等 关机再开机也相当于终端重启 终端重启之后 初始化过程中 将会进行一次LocationUpdate过程 这从系统侧后台信令上可以观察到 并且从上次RLFailure导致掉话到下次重新作起业务来也将会有较大的时延 通常要超过30秒 无线链路失败 Radiolinkfailure b 无线信道环境出现深衰落或者强干扰无线信道环境出现深衰落或强干扰时 会导致基站没有正确解释终端发出的上行信号而报RLFailure 如果是出现深衰落 一般情况下 下行链路的无线信道环境跟上行链路一样 信道质量变差 下行功率会抬升得比较高 并且UE极有可能会上报CellUpdate 思考 几个问题需要大家深入思考并确认 功课平时要做足 1 CellUpdate与radiolinkfailureindication 2 TDD制式上下行链路的互易性 3 上行链路失步的判决机制 下行链路的判决机制 4 相关的定时器与计数器 无线链路失败 Radiolinkfailure c 基站侧出现异常基站解错上行信号或接收不到上行信号而报无线链路失败 此时基站应该会相关告警 且基本上不能接入和保持住包括PS在内的任何业务或终端了 从其他商用城市的采样数据来看 前面三种原因的比例是8 1 1 目前引起无线链路失败主要还是终端问题和用户插拔卡或者是拨号软件响应造成 这些原因属于不可控的范围 只能从逐步改善终端性能解决 手机操作超时 Ue Operate TimeOut 系统出现Ue Operate TimeOut引起的掉线主要是因为物理信道重配置超时或RB重配置超时 而引起物理信道重配置超时或RB重配置超时的常见原因有 a 存在UPPCH的干扰 如果是硬切换的情况下会造成上行同步过程的失败 从而造成物理信道重配置失败b 虚假的邻小区关系造成物理信道重配置超时c RB重配置参数设置不合理造成RB重配置超时d 功率参数配置不合理造成RB或物理信道重配置超时e HS业务与R4业务之间的切换失败 包括从R4到R5的切换和从R5到R4的切换 这种原因主要表现为RB重配置超时 问题分析 邻区关系前期经过认真核查 应不存在普遍问题 邻区个数也不多 邻区关系基本不会影响到Ue Operate TimeOut 检查HSDPA的功率参数设置 也未发现整体的异常 这方面的原因也可以排除 Ue Operate TimeOut的原因很可能是终端问题和R5与R4业务之间的切换问题 问题重现及优化 由上面的分析 终端问题导致的掉线不在我们可控范围之内 Ue Operate TimeOut存在网络的因素 也是最主要的PS掉线原因 我们只能从解决这个因素着手优化 为此 选择在某小区下 拨测重现问题 让数据卡拨号后不断使用各种业务 同时后台对该数据卡IMSI进行信令追踪 问题重现及优化 在连续跟踪2个多小时后 后台发现Ue Operate TimeOut导致PS掉线的信令 从采集的前后台信令看 用户在连续发了5个4B 降速 的测量报告后 开始进行降速 从频点为10071的HSDPA信道 切换到主频点10055的DCH信道 如下图所示 这是典型的HSDPA信道和DCH信道的切换 问题重现及优化 问题重现及优化 在这过程之后RNC接下来进行物理信道重配置 或RB重配置 从物理信道重配置信令解码中可以看到 系统指示终端的连接状态从原来的Cell DCH跃迁到URA PCH 终端上报了物理信道重配置完成后 由于处于URA PCH状态 网络侧并不知道终端的具体位置 cell 当终端要发送上行数据时 根据TS25 331协议描述 必须通过CellUpdate过程跃迁回Cell DCH状态 RRCStatesandStateTransitions 目前行业里对四种状态的支持情况 我司设备 RNC 早已经实现并支持所有的状态 但终端侧 对URA PCH状态的支持效果都不好 在状态的迁徙过程中 极易引起Ue Operate TimeOut造成释放 本次追踪的信令也可以看出 在CellUpdate后 RNC下发小区更新确认消息 但随后UE物理信道重配置超时 导致IuReleaseRequest PS掉线 掉线原因就是我们所关注的Ue Operate TimeOut 问题分析 问题分析 在仔细分析和排查之后 问题的关键点基本定位明晰 在UE无法很好的支持PCH状态的现状下 我司网络侧能否做些修改 减少或者屏蔽掉此类问题 提高用户感知 换个角度想 为什么在别的地方并未大规模出现此类问题 后台参数设置上到底有何不同 思考 UE对PCH态普遍支持不好 所以会出现 能从CELL DCH状态跃迁至URA PCH 但从URA PCH状态跃迁回CELL DCH态时 出现重配超时 导致PS掉话 如果事先就考虑到这一点 不让UE进入到PCH态 是不是这个问题就不会出现了呢 协议中对重配过程的说明 协议中对重配过程的说明 优化 重新认真复查网络侧与此相关的参数配置 检查RNC参数配置 发现RNC打开了RNC支持URA PCH指示的开关 这有可能造成RNC在做信道分配 重配置等判决的时候 将终端在R5到R4信道转换中跃迁到了URA PCH状态 直接造成状态转化时 手机操作超时 而PS掉话 我们尝试将其关闭 如下图所示 观察效果 优化 验证 关闭URA PCH后 从系统侧统计的指标对比 问题区域全天PS掉线率从关闭当天开始 由原来的40 到60 下降到10 以下 而从优化之后的掉话原因来看 Ue Operate TimeOut原因的释放次数从原来的100多次下降到十几次 占总掉线次数的比例也从85 下降到18 75 Ue Operate TimeOut的掉线原因已成为次要原因 如下表所示是优化前后一周同期的数据 总结 通过分析掉线的各种原因 找出PS掉线的主要原因是Ue Operate TimeOut 从拨测和网络侧信令追踪证实Ue Operate TimeOut产生的原因是UE进入URA PCH状态后 从PCH态迁徙到HS DCH态超时 导致IU释放并PS掉线的 通过关闭RNC的支持PCH功能