TD-LTE掉线优化指导书

1、Product Type Technical ProposalTD-LTE掉线分析指导书R1.3ZTE Confidential Proprietary© 2011 ZTE Corporation. All rights reserved.1(31) TD-LTE掉线分析指导书 内部公开版本更新说明产品版本资料版本资料编号资料更新说明V3.10.10R1.0手册第一次发行V3.10.10R1.2更新了部分案例及思路总结V3.10.10R1.3完善版本，整理框架作者资料版本日期作者审核者批准者R1.02012-1-20李毅R1.22012-08-20李毅-R1.32013-03-30李

2、毅适用对象：TDD网优工程师使用建议：在阅读本文档之前，建议先了解下面的知识和技能：序号知识技能参考资料1TD-LTE产品技能认证二级TD-LTE基本原理与关键技术TD-LTE产品技能认证二级TD-LTE路测工具使用方法后继资料：在阅读完本文档之后，你可能需要下面资料：序号参考资料资料说明1TD-LTE接入优化指导书TD-LTE接入知识掌握，了解接入的分析2TD-LTE切换优化指导书TD-LTE切换知识掌握，了解切换的分析3Super Cell技术白皮书Super Cell设计方法关于这篇文档摘要章节描述Error! Reference source not found. 概述概述3 TDL信

3、令描述介绍TD-LTE信令基本流程和真实信令的差异Error! Reference source not found. 总结掉线原因分析对TD-LTE掉线各种原因分析，说明处理掉线的思路方法，及典型案例说明Error! Reference source not found. 后台掉线率定义掉线原因及KPI处理方法Error! Reference source not found. 总结掉线问题处理思路目录1概述12TD-LTE完整业务流程12.1自研UE信令42.2CNT信令53掉线问题分析53.1掉线率公式83.2重建原因83.2.1定时器不合理83.2.2上行干扰93.2.3下行干扰133

4、.2.4切换准备问题143.2.5有MR但无重配173.3UE触发重建203.3.1UE触发重建未果223.3.2UE触发重建被拒223.4rrcConnectionRelease掉线243.5其他类掉线244后台掉线率定义244.1掉线原因分类及公式254.2KPI分析方法275总结27图目录图 11 TD-LTE信令基本流程1图 12 自研UE信令4图 13 CNT信令5图 21 RRC重建无果5图 22 RRC重建被拒6图 23 异常收到RRC释放消息6图 24 TD-LTE掉线问题总结7图 25 切换参数查看14图 26 切换成功与切换失败表现14图 27 UE触发重建被拒21图 31

5、 TD-LTE掉线处理流程23图 32 影响网优告警列表24 版权所有未经许可不得扩散第28页1 概述本文主要介绍了TD-LTE系统掉线问题优化方法，通过对各局出现的掉线问题进行讲解说明，总结了TD-LTE掉线的处理思路及优化方案，为后续各个外场处理TD-LTE掉线问题提供了优化经验。2 TD-LTE完整业务流程TD-LTE完整业务信令流程如下：图 21 TD-LTE信令基本流程完整的业务流程共包含4部分，分别如图中所标识的 1（红色） 接入过程；2（蓝色） 与NAS层完保交互过程；3（绿色） 无线承载建立过程；4（黄色） 释放过程。当无线承载建立完成 “RRCConnectionReconf

6、igurationComplete”正确到达网络侧，则本次业务建立成功，那么在之后一旦触发RRC重建且被拒或者直接转到IDLE态，那么就代表本次业务掉线，也就是说，如果没有对应的“释放过程”那么就认为掉线。对上述信令过程步骤描述如下：步骤15会建立RRC连接，步骤6、9会建立S1连接，完成这些过程即标志着NAS signalling connection建立完成。消息7的说明：如果UE是刚开机第一次attach，使用的IMSI，无Identity过程；后续如有有效的GUTI，使用GUTI attach，核心网才会发起Identity过程（为上下行直传消息）。消息1012的说明：如果消息9带了U

7、E Radio Capability IE，则eNB不会发送UECapabilityEnquiry消息给UE，即没有1012过程；否则会发送，UE上报无线能力信息后，eNB再发UE Capability Info Indication，给核心网上报UE的无线能力信息。为了减少空口开销，在IDLE下MME会保存UE Radio Capability信息，在INITIAL CONTEXT SETUP REQUEST消息会带给eNB，除非UE在执行attach或者"first TAU following GERAN/UTRAN Attach" or "UE radio

8、capability update" TAU过程（也就是这些过程MME不会带UE Radio Capability信息给eNB，并会把本地保存的UE Radio Capability信息删除，eNB会问UE要能力信息，并报给MME。注："UE radio capability update" TAU is only supported for changes of GERAN and UTRAN radio capabilities in ECM-IDLE.）。在CONNECTED下，eNB会一直保存UE Radio Capability信息。UE的E_UTRAN

9、无线能力信息如果发生改变，需要先detach，再attach。发起UE上下文释放（即2125）的条件：l eNodeB-initiated with cause e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated RRC signalling Integrity Check Failure, Release due to UE generated signalling connection release, etc.; orl MME-initiated with cause e.g. authen

10、tication failure, detach, etc.eNB收到msg3以后，DCM给USM配置SRB1，配置完后发送msg4给UE；eNB在发送RRCConnectionReconfiguration前，DCM先给USM配置DRB/SRB2等信息，配置完后发送RRCConnectionReconfiguration给UE，收到RRCConnectionReconfigurationComplete后，控制面再通知用户面资源可用。消息1315的说明：eNB发送完消息13，并不需要等收到消息14，就直接发送消息15。如果发起IMSI attach时，UE的IMSI与另外一个UE的IMSI重

11、复，并且其他UE已经attach，则核心网会释放先前的UE。如果IMSI中的MNC与核心网配置的不一致，则核心网会回复attach reject。消息9的说明：该消息为MME向eNB发起的初始上下文建立请求，请求eNB建立承载资源，同时带安全上下文，可能带用户无线能力、切换限制列表等参数。UE的安全能力参数是通过attach request消息带给核心网的，核心网再通过该消息送给eNB。UE的网络能力（安全能力）信息改变的话，需要发起TAU。2.1 自研UE信令结合自研UE真实信令过程如下：图 22 自研UE信令自研UE释放过程无法记录，后续版本补充。2.2 CNT信令结合CNT与dongle

12、连接真实信令过程如下：图 23 CNT信令本次释放是UE发起的去附着过程，后续RRC release过程CNT无法体现。3 掉线问题分析3.1 分析思路对于TD-LTE的掉线，是在UE完成“RRCConnectionReconfigurationComplete”处于连接态，之后由于干扰、弱场、其他原因导致的UE上下行失步，触发重建未果或者被拒过程。只要不是终端主动发起的释放，都应算为掉线。目前掉线在信令中表现如下3种情况。l 连接态下触发RRC重建无果图 31 RRC重建无果l 连接状态下触发RRC重建被拒图 32 RRC重建被拒l 连接状态下异常收到RRC释放消息图 33 异常收到RRC释

13、放消息对于非正常释放的掉线问题，TD-LTE引入了重建立机制，对于重建立的掉线的分析要分2部分完成：l 引起重建的原因；l 重建失败的原因；因此基于上述掉线进行分析总结图 34 TD-LTE掉线问题总结对于掉线问题，首先判断的就是覆盖和干扰，利用CNT查看下行RSRP、SINR值，通常RSRP<-115且SINR<-3掉线比例较高；利用基站侧检测工具查看上行干扰。下面结合日本网优阶段发现的掉线案例编写掉线问题分析过程。3.2 掉线率公式目前测试软件CNT(A)对掉线率的定义如下：L3message：(rrcConnectionReestablishmentRequest - rrc

14、ConnectionReestablishmentComplete + rrcConnectionRelease (不含13原因)times*100% / L3 message(Activate default EPS bearer context accept) timesl UE发送rrcConnectionReestablishmentRequest 但无对应的rrcConnectionReestablishmentComplete消息；l 出现rrcConnectionRelease消息，但不包括：- 1系统间切换网络侧释放;- 2用户未激活，网络侧释放资源情况(User Inacti

15、vity)- 3 CSFB的网络侧释放（待确定）说明：对于TDD-LTE制式，掉线对用户感知的评判有所减弱，此公式只是一般情况，后续可以与局方协商对掉线率公式修改，如 RRC重建被拒后2s内业务恢复成功不计做掉话，或者可以用时间掉线比(分母是测试总时长)、公里掉线比(分母是DT测试公里数)3.3 重建原因3.3.1 定时器不合理定时器相关参数优化建议值如下：字段名称优化值字段中文含义byT310_Ue2000msUE监测无线链路失败的定时器长度(T310_UE)byT311_Ue30000msUE监测到无线链路失败后转入idle状态的定时器长度(T311_UE)byT3002000msUE等待

16、RRC连接响应的定时器长度(T300)byT3012000msUE等待RRC重建响应的定时器长度(T301)byT3021sUE收到RRC连接拒绝后等待RRC连接请求重试的定时器长度 (T302)byT3041000msUE等待切换成功的定时器长度(T304)byT304_Cco4000msUE CCO到GRAN的定时器长度(T304)byT3205min小区重选优先级定时器长度(T320)byN3106UE接收下行失步指示的最大个数(N310_UE)byN3111UE接收下行同步指示的最大个数(N311)这类参数都已定标，如发生掉线问题可根据案例查看相关时段是否合理，再结合所有掉线对定时器做

17、全局考虑修改调整。可参考TD-LTE网优参数优化指导书。3.3.2 上行干扰上行干扰包含用户间的上行干扰，设备自身异常处理的上行干扰，以及频段的干扰导致，通常上行干扰主要表现切换失败、重建失败，发生掉线。典型案例分析3.3.2.1 现象描述福冈网络指标摸底阶段中，初期存在接入不成功，切换后异常掉线，这种现象没有一定规律，有时成功有时失败。测试掉线点分布如图所示：图中黑色星为掉线点。通过掉线点分布，掉线点基本在东南边。3.3.2.2 现象分析1.针对该问题，挑选在掉线集中点区域进行定点测试，各种终端都无法连接网络。高通终端表现，一直在IDLE、CONNECTED之前乒乓，无法正常接入。2.查看当

18、时测试数据，在仅能接入的几次其服务小区的RSRP、SINR良好；下行覆盖良好，无干扰。查看信令，UE接入小区后就触发RRC重建，发生掉线。通过高通分析软件QCAT查看掉线过程及重建过程。看到UE原因为UL_DATA后DCI0未达，SR达到最大次数，触发MSG1，由于MSG1无法到达网络侧，不断重发8次后失败，后触发重建。为了验证问题是否有规律性，对站点了定点测试，测试区域如图所示：蓝色区域的站点随机接入和切换成功率较高，而红色区域站点接入困难。站点分布与BBU关系如图：红色区域是掉线集中区域。查看掉线点与BBUID关系，有一定联系，非掉线区域隶属于BBUID=400010（蓝色区域），掉线区域

19、的属于BBUID=400011、400012的BBU下挂小区。因此怀疑可能BBUID=400010与BBUID=400011、400012某些关联设备问题导致。3.根据上述分析查看后台设备告警。BBUID=400011、400012站点的GPS未锁定（对应告警名称：GPS receiver failed to search stars(198091072)），400010站点正常。BBUID=400011、400012站点GPS状态未锁定：BBUID=400010的GPS状态正常：400011、400012无GPS锁星，但仍处于激活态，导致其下挂的小区对周边小区造成GPS干扰，影响其他小区上行

20、接入。对接入切换不成功的小区提取MTS跟踪上行接收功率数据，基站侧接收功率普遍抬高（空载下正常应该在-9699dbm左右），平均在-80dbm左右，受到上行干扰。干扰情况如下表显示：基站侧接收到的RxPow03都很高，上行干扰严重。3.3.2.3 解决方法及验证福冈每个BBU下挂多个RRH（小区），如果GPS锁星失败，此时基站仍然在放电波状态下，就会对周表小区存在干扰。因此把400011、400012的2个BBU下挂的站点闭塞，后再次测试，问题消失，400010下的所有小区接入切换均成功，问题得以解决。3.3.2.4 总结根据上述的分析，如果GPS一旦出现异常，那么对周边站点的干扰是比较严重的

21、。对于没有接通GPS的站点不允许开通释放电波。对于偶然存在GPS失星的情况要通过参数来控制其对别的站点干扰，目前后台有关于GPS失星后的控制方案，其包含2个参数：A. Holdover time-out switch (GPS同步保持) 取值范围：开/关；B. Holdover time-out threshold(GPS同步保持时间门限) 取值范围：60分钟4小时配置在EMS-eNodeB节点配置表，第一个参数必须配置为开，再设置保持时间，默认是60分钟。参数网管截图如下：开关状态为enable，时间默认为60分钟：表示开关打开，基站在60分钟内，GPS没有同步则关闭小区；开关状态为disa

22、ble，时间默认为60分钟：表示开关关闭，小区状态不受GPS是否同步影响，始终保持正常建立状态；3.3.3 下行干扰系统内的下行干扰是产生掉线原因之一，通常表现无主覆盖小区，服务小区与邻区RSRP较好，数值基本接近，但SINR较差，导致解调信号变弱，易失步，因此会触发重建过程，如果重建不成功则产生掉线。由于日本全向天线，无法对天面参数调整，对于下行干扰只能采用降功率方式以及超级小区（超级小区详见SuperCell小区合并算法）暂时解决。但是对于其他局，通常处理方式优先顺序是：1.先天面调整；2.覆盖切换类参数调整；3.最后功率调整。该案例后续针对定向天线补充。3.3.4 切换准备问题通常情况下

23、如果UE上报MR时机不佳，则会伴随着服务小区信号衰减抖动过快，导致掉线。这种情况是由于无法满足切换条件或者切换过早造成。切换的参数包括：A3_offset、TTT、Hysteresis，这3个参数设置过于苛刻或过于简单，都会导致时机不佳换造成掉线。查看三个参数配置情况可看RRC Connection Reconfiguration中的IE字段名称，如图所示：图 35 切换参数查看CNT显示的切换失败信令如下图蓝框内内容所示，红框内信令为正常的切换信令图 36 切换成功与切换失败表现典型案例分析3.3.4.1 现象描述在测试中路口附近是问题多发点，部分小区由于“波导效应”容易出现过覆盖问题，又由

24、于“拐角效应”在路口两侧信号迅速衰落，从而导致掉线。3.3.4.2 现象分析测试路线如下图蓝色箭头所示，其中红色区域为掉线点。在测试路线上主要是PCI=45 小区覆盖，在经过红色区域所以的路口时，PCI=4小区信号突然出现并迅速恶化，导致终端切换进该小区产生掉线。掉线点RSRP分布如上图所示，红色区域显示PCI=4小区突然出现一个尖峰。CNT掉线点信令如下图所示：3.3.4.3 解决方法及验证由测试路线图可知PCI=4小区距离测试路线较远，测试路线应该由PCI=45小区覆盖，但由于“波导效应”导致PCI=4小区信号在路口比服务小区高4dB而触发切换流程导致掉线，而解决此掉线只需要避免UE切换到

25、该小区即可。将PCI=45小区邻区关系中和PCI=4小区邻区“Cell individual offset”设置为-3，在UE测量时增加一个迟滞，从而避免触发切换流程。3.3.4.4 总结在处理路口附近由于突然出现的信号尖峰导致的问题时，由于测试区域均使用全向天线，RS功率/A3事件迟滞/Time to trigger三个参数影响范围较广不建议调整，应优先使用Cell individual offset来解决。3.3.5 有MR但无重配UE具备全频段所有小区探测能力，只要达到上报条件，就会有MR上报，但如果后台没有对服务小区配置合理正确的邻区关系，就无法从网络侧收到切换命令，无法切换。在信令主

26、要表现在UE上报多个MR后，但无切换命令，无线链路超时造成掉线。典型案例分析3.3.5.1 现象描述在某次路测中发现如下图情况，UE上报多个MR多次测量报告现象：3.3.5.2 现象分析查看MR信息，前三次测量报告目标PCI都是28：第一个测量报告内容：第四次测量报告（见图3-3）中有PCI28、19两个小区，第四次测量报告内容：从测量值上看，28比19高3个dB，接着收到了切换命令，切换命令：切换命令： 1 目标小区的PCI=193.3.5.3 解决方法及验证目标小区不是最高的28而是19，所以需要确认源小区的邻区是否添加了PCI=28小区，通过查询源小区的测量控制信息确认源小区漏配邻区：源

27、小区测量控制信息：1：邻区列表中有PCI=19小区查看信令，没有配置28的小区信息，并且通过站点分布发现，服务小区6与28、19都比较近，应属于漏配邻区情况，站点分布如图：因此该问题是由于没有添加PCI=28的小区导致，添加PCI=6àPCI=28小区后切换正常3.3.5.4 总结由于目前SON的自动邻区功能不成熟，路测中遇到多次上报MR始终不切换的情况需要根据实际覆盖与邻区关系对比，添加合适的邻区关系，但是也要避免切换参数不合理的突发信号引起的不良MR情况，需要对每个异常问题深刻分析。3.4 UE触发重建协议中定义了触发重建的流程及信令图 37 RRC重建成功图 38 RRC重建被

28、拒协议中对UE触发重建的原因如下：The UE shall only initiate the procedure when AS security has been activated. The UE initiates the procedure when one of the following conditions is met:l upon detecting radio link failure, in accordance with “Radio link failure related actions or”l 通常无线链路失败，牵扯到公共信道、业务信道的覆盖和干扰情况 l u

29、pon handover failure, in accordance with ”T304 expiry (handover failure)” orl 切换等待定时器超时导致，查看小区邻区及参数是否合理l upon mobility from E-UTRA failure, in accordance with “Mobility from E-UTRA failure” orl 检查配置是否合理及参数l upon integrity check failure indication from lower layers orl 完整性检查失败,如加密算法，与NAS的直传消息受阻导致l up

30、on an RRC connection reconfiguration failure, in accordance with “Reconfiguration failure”3.4.1 UE触发重建未果目前还未发现这种触发重建后没有下文的情况，后续版本补充。根据通常网优经验，发生这种情况一般都是由于UE发送重建立消息过程中，由于覆盖场强过弱、上行功率异常、干扰等导致。按照掉线处理思路流程，先确定个性还是局部问题，然后查看发生该问题的服务小区、目标小区有无硬件告警，再查看覆盖、干扰、参数情况进行判断。3.4.2 UE触发重建被拒该问题通常信令如下图所示：图 39 UE触发重建被拒通常发生R

31、RC被拒一般都是由于版本问题、上下行报文错误、设备原因导致。典型案例分析3.4.2.1 现象描述福冈FT拉网测试中，UE最初占用PCI=25号小区，后切换至PCI=18号小区，切换成功。由于日本全向天线，且在闹市区，存在电平波动，后UE检测到PCI=25号小区满足切换条件，网络下发RRC重配置给UE，携带切换目标小区是原服务小区PCI=25号，可是切换失败，后无线链路失败触发重建立过程：当时信令表现如下：蓝色部分是UE从PCI=25àPCI=18成功，绿色是从PCI=18àPCI=25进行回切失败后RLF，红色是触发重建过程，从PCI=18àPCI=45被拒，造成掉线。3.4.2.2 现象分析这种现象在测试过程中发生次数较多，根据掉线排查思路，优先查看切换失败到重建立过程中覆盖、干扰情况，发现此过程中的前后几秒内小区覆盖较好，SINR>3，无干扰，后查看后台目标服务小区均无硬件告警。抓取不同时间段的LOG，对目标和服务小区切换做了统计，有如下规律：Time原小区目标小区切换结果切换失败说明重建结果17: