北京移动TD精英营专题培训 PS掉线率优化

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