搜索
北京移动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开始读广播消息了”，就是掉话——此种说法是否正确？总数目指派建立成功的分组域总数目请求释放的分组域RABRABRABRNC内部公开▲PS掉线原因统计从上图指标看，问题区域RNC请求释放的分组域RAB（即PS掉线）次数达到181次，其中：原因值为Ue_Operate_TimeOut的释放次数达到123次，占掉线总数的68%;原因值为Radiolinkfailure的次释放次数达到31次，占总掉线次数的17%。这两种原因引起的释放次数占了全网掉线总次数的85%，是引起问题区域PS掉线率高的主要原因。PS掉线原因次数统计(20090708)68%17%5%4%3%3%Ue_Operate_TimeOutRlFail_ReportUCIU_errorUeReportCellUpdateUESignallingrelease其他原因内部公开▲原因分析由以上分析可知，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功能，问题得到解决。另外，由于关闭了RNC的PCH状态支持后，网络没有URA_PCH状态，UE从CELL_DCH直接跃迁到空闲状态的次数就增多了。Ue_Operate_TimeOut原因引起的释放次数大大减少了，但USER_Inactive理论上会有所增加。从几天的数据来看，7月11日的USER_Inactive原因有所增加，另外几天增加不是很明显，需观察一段时间再比较。内部公开▲附录：