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