TD-LTE掉线优化指导书.docx

Product Type Technical Proposal

TD-LTE掉线分析指导书
R1.3

ZTE Confidential Proprietary
© 2013 ZTE Corporation. All rights reserved.
1(31)

TD-LTE掉线分析指导书 内部公开▲

版本更新说明

产品版本
资料版本
资料编号
资料更新说明
V3.10.10
R1.0

手册第一次发行
V3.10.10
R1.2

更新了部分案例及思路总结
V3.10.10
R1.3

完善版本，整理框架

作者
资料版本
日期
作者
审核者
批准者
R1.0
2012-1-20
李毅

R1.2
2012-08-20
李毅

-
R1.3
2013-03-30
李毅

适用对象：TDD网优工程师

使用建议：在阅读本文档之前，建议先了解下面的知识和技能：
序号
知识技能
参考资料
1
TD-LTE产品技能认证二级
TD-LTE基本原理与关键技术

TD-LTE产品技能认证二级
TD-LTE路测工具使用方法

后继资料：在阅读完本文档之后，你可能需要下面资料：
序号
参考资料
资料说明
1
TD-LTE接入优化指导书
TD-LTE接入知识掌握，了解接入的分析
2
TD-LTE切换优化指导书
TD-LTE切换知识掌握，了解切换的分析
3
Super Cell技术白皮书
Super Cell设计方法
关于这篇文档
摘要
章节
描述
Error! Reference source not found. 概述
概述
3 TDL信令描述
介绍TD-LTE信令基本流程和真实信令的差异
Error! Reference source not found. 总结掉线原因分析
对TD-LTE掉线各种原因分析，说明处理掉线的思路方法，及典型案例说明
Error! Reference source not found. 后台掉线率定义
掉线原因及KPI处理方法
Error! Reference source not found. 总结
掉线问题处理思路
目录
1 概述 1
2 TD-LTE完整业务流程 1
2.1 自研UE信令 4
2.2 CNT信令 5
3 掉线问题分析 5
3.1 掉线率公式 8
3.2 重建原因 8
3.2.1 定时器不合理 8
3.2.2 上行干扰 9
3.2.3 下行干扰 13
3.2.4 切换准备问题 14
3.2.5 有MR但无重配 17
3.3 UE触发重建 20
3.3.1 UE触发重建未果 22
3.3.2 UE触发重建被拒 22
3.4 RRCCONNECTIONRELEASE掉线 24
3.5 其他类掉线 24
4 后台掉线率定义 24
4.1 掉线原因分类及公式 25
4.2 KPI分析方法 27
5 总结 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 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（黄色） 释放过程。
当无线承载建立完成 “RRCConnectionReconfigurationComplete”正确到达网络侧，则本次业务建立成功，那么在之后一旦触发RRC重建且被拒或者直接转到IDLE态，那么就代表本次业务掉线，也就是说，如果没有对应的“释放过程”那么就认为掉线。对上述信令过程步骤描述如下：
步骤1～5会建立RRC连接，步骤6、9会建立S1连接，完成这些过程即标志着NAS signalling connection建立完成。
消息7的说明：如果UE是刚开机第一次attach，使用的IMSI，无Identity过程；后续如有有效的GUTI，使用GUTI attach，核心网才会发起Identity过程（为上下行直传消息）。
消息10~12的说明：如果消息9带了UE Radio Capability IE，则eNB不会发送UECapabilityEnquiry消息给UE，即没有10~12过程；否则会发送，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 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无线能力信息如果发生改变，需要先detach，再attach。
发起UE上下文释放（即21～25）的条件：
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.; or
l MME-initiated with cause e.g. authentication failure, detach, etc.
eNB收到msg3以后，DCM给USM配置SRB1，配置完后发送msg4给UE；eNB在发送RRCConnectionReconfiguration前，DCM先给USM配置DRB/SRB2等信息，配置完后发送RRCConnectionReconfiguration给UE，收到RRCConnectionReconfigurationComplete后，控制面再通知用户面资源可用。
消息13~15的说明：eNB发送完消息13，并不需要等收到消息14，就直接发送消息15。
如果发起IMSI attach时，UE的IMSI与另外一个UE的IMSI重复，并且其他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连接真实信令过程如下：
图 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释放消息

对于非正常释放的掉线问题，TD-LTE引入了重建立机制，对于重建立的掉线的分析要分2部分完成：
l 引起重建的原因；
l 重建失败的原因；
因此基于上述掉线进行分析总结
图 34 TD-LTE掉线问题总结

对于掉线问题，首先判断的就是覆盖和干扰，利用CNT查看下行RSRP、SINR值，通常RSRP<-115且SINR<-3掉线比例较高；利用基站侧检测工具查看上行干扰。
下面结合日本网优阶段发现的掉线案例编写掉线问题分析过程。
3.2 掉线率公式
目前测试软件CNT(A)对掉线率的定义如下：
L3message：
(rrcConnectionReestablishmentRequest - rrcConnectionReestablishmentComplete + rrcConnectionRelease (不含1~3原因)times*100% / L3 message(Activate default EPS bearer context accept) times
l UE发送rrcConnectionReestablishmentRequest 但无对应的rrcConnectionReestablishmentComplete消息；
l 出现rrcConnectionRelease消息，但不包括：
- 1系统间切换网络侧释放;
- 2用户未激活，网络侧释放资源情况(User Inactivity)
- 3 CSFB的网络侧释放（待确定）
说明：对于TDD-LTE制式，掉线对用户感知的评判有所减弱，此公式只是一般情况，后续可以与局方协商对掉线率公式修改，如 RRC重建被拒后2s内业务恢复成功不计做掉话，或者可以用时间掉线比(分母是测试总时长)、公里掉线比(分母是DT测试公里数)
3.3 重建原因
3.3.1 定时器不合理
定时器相关参数优化建议值如下：
字段名称
优化值
字段中文含义
byT310_Ue
2000ms
UE监测无线链路失败的定时器长度(T310_UE)
byT311_Ue
30000ms
UE监测到无线链路失败后转入idle状态的定时器长度(T311_UE)
byT300
2000ms
UE等待RRC连接响应的定时器长度(T300)
byT301
2000ms
UE等待RRC重建响应的定时器长度(T301)
byT302
1s
UE收到RRC连接拒绝后等待RRC连接请求重试的定时器长度 (T302)
byT304
1000ms
UE等待切换成功的定时器长度(T304)
byT304_Cco
4000ms
UE CCO到GRAN的定时器长度(T304)
byT320
5min
小区重选优先级定时器长度(T320)
byN310
6
UE接收下行失步指示的最大个数(N310_UE)
byN311
1
UE接收下行同步指示的最大个数(N311)
这类参数都已定标，如发生掉线问题可根据案例查看相关时段是否合理，再结合所有掉线对定时器做全局考虑修改调整。可参考《TD-LTE网优参数优化指导书》。
3.3.2 上行干扰
上行干扰包含用户间的上行干扰，设备自身异常处理的上行干扰，以及频段的干扰导致，通常上行干扰主要表现切换失败、重建失败，发生掉线。
典型案例分析
3.3.2.1 现象描述
福冈网络指标摸底阶段中，初期存在接入不成功，切换后异常掉线，这种现象没有一定规律，有时成功有时失败。测试掉线点分布如图所示：

图中黑色星为掉线点。通过掉线点分布，掉线点基本在东南边。
3.3.2.2 现象分析
1. 针对该问题，挑选在掉线集中点区域进行定点测试，各种终端都无法连接网络。
高通终端表现，一直在IDLE、CONNECTED之前乒乓，无法正常接入。

2. 查看当时测试数据，在仅能接入的几次其服务小区的RSRP、SINR良好；

下行覆盖良好，无干扰。
查看信令，UE接入小区后就触发RRC重建，发生掉线。

通过高通分析软件QCAT查看掉线过程及重建过程。看到UE原因为UL_DATA后DCI0未达，SR达到最大次数，触发MSG1，由于MSG1无法到达网络侧，不断重发8次后失败，后触发重建。

为了验证问题是否有规律性，对站点了定点测试，测试区域如图所示：

蓝色区域的站点随机接入和切换成功率较高，而红色区域站点接入困难。站点分布与BBU关系如图：

红色区域是掉线集中区域。查看掉线点与BBUID关系，有一定联系，非掉线区域隶属于BBUID=400010（蓝色区域），掉线区域的属于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干扰，影响其他小区上行接入。
对接入切换不成功的小区提取MTS跟踪上行接收功率数据，基站侧接收功率普遍抬高（空载下正常应该在-96~99dbm左右），平均在-80dbm左右，受到上行干扰。干扰情况如下表显示：

基站侧接收到的RxPow0～3都很高，上行干扰严重。
3.3.2.3 解决方法及验证
福冈每个BBU下挂多个RRH（小区），如果GPS锁星失败，此时基站仍然在放电波状态下，就会对周表小区存在干扰。
因此把400011、400012的2个BBU下挂的站点闭塞，后再次测试，问题消失，400010下的所有小区接入切换均成功，问题得以解决。
3.3.2.4 总结
根据上述的分析，如果GPS一旦出现异常，那么对周边站点的干扰是比较严重的。对于没有接通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没有同步则关闭小区；
开关状态为disable，时间默认为60分钟：表示开关关闭，小区状态不受GPS是否同步影响，始终保持正常建立状态；
3.3.3 下行干扰
系统内的下行干扰是产生掉线原因之一，通常表现无主覆盖小区，服务小区与邻区RSRP较好，数值基本接近，但SINR较差，导致解调信号变弱，易失步，因此会触发重建过程，如果重建不成功则产生掉线。由于日本全向天线，无法对天面参数调整，对于下行干扰只能采用降功率方式以及超级小区（超级小区详见《SuperCell小区合并算法》）暂时解决。但是对于其他局，通常处理方式优先顺序是：
1. 先天面调整；
2. 覆盖切换类参数调整；
3. 最后功率调整。
该案例后续针对定向天线补充。
3.3.4 切换准备问题
通常情况下如果UE上报MR时机不佳，则会伴随着服务小区信号衰减抖动过快，导致掉线。这种情况是由于无法满足切换条件或者切换过早造成。切换的参数包括：A3_offset、TTT、Hysteresis，这3个参数设置过于苛刻或过于简单，都会导致时机不佳换造成掉线。查看三个参数配置情况可看RRC Connection Reconfiguration中的IE字段名称，如图所示：
图 35 切换参数查看

CNT显示的切换失败信令如下图蓝框内内容所示，红框内信令为正常的切换信令
图 36 切换成功与切换失败表现

典型案例分析
3.3.4.1 现象描述
在测试中路口附近是问题多发点，部分小区由于“波导效应”容易出现过覆盖问题，又由于“拐角效应”在路口两侧信号迅速衰落，从而导致掉线。
3.3.4.2 现象分析
测试路线如下图蓝色箭头所示，其中红色区域为掉线点。

在测试路线上主要是PCI=45 小区覆盖，在经过红色区域所以的路口时，PCI=4小区信号突然出现并迅速恶化，导致终端切换进该小区产生掉线。

掉线点RSRP分布如上图所示，红色区域显示PCI=4小区突然出现一个尖峰。
CNT掉线点信令如下图所示：

3.3.4.3 解决方法及验证
由测试路线图可知PCI=4小区距离测试路线较远，测试路线应该由PCI=45小区覆盖，但由于“波导效应”导致PCI=4小区信号在路口比服务小区高4dB而触发切换流程导致掉线，而解决此掉线只需要避免UE切换到该小区即可。将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上报，但如果后台没有对服务小区配置合理正确的邻区关系，就无法从网络侧收到切换命令，无法切换。在信令主要表现在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=19
3.3.5.3 解决方法及验证
目标小区不是最高的28而是19，所以需要确认源小区的邻区是否添加了PCI=28小区，通过查询源小区的测量控制信息确认源小区漏配邻区：
源小区测量控制信息：

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重建被拒

协议中对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 upon handover failure, in accordance with ”T304 expiry (handover failure)” or
l 切换等待定时器超时导致，查看小区邻区及参数是否合理
l upon mobility from E-UTRA failure, in accordance with “Mobility from E-UTRA failure” or
l 检查配置是否合理及参数
l upon integrity check failure indication from lower layers or
l 完整性检查失败,如加密算法，与NAS的直传消息受阻导致
l upon an RRC connection reconfiguration failure, in accordance with “Reconfiguration failure”
3.4.1 UE触发重建未果
目前还未发现这种触发重建后没有下文的情况，后续版本补充。
根据通常网优经验，发生这种情况一般都是由于UE发送重建立消息过程中，由于覆盖场强过弱、上行功率异常、干扰等导致。
按照掉线处理思路流程，先确定个性还是局部问题，然后查看发生该问题的服务小区、目标小区有无硬件告警，再查看覆盖、干扰、参数情况进行判断。
3.4.2 UE触发重建被拒
该问题通常信令如下图所示：
图 39 UE触发重建被拒
通常发生RRC被拒一般都是由于版本问题、上下行报文错误、设备原因导致。
典型案例分析
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:41:18:066
25
18
成功
同一单板

17:42:20:905
18
25
失败
重建18，成功
17:42:21:537
18
25
失败
重建18，成功
17:42:59:807
18
25
失败
重建45，失败
3.4.2.3 解决方法及验证
根据上述分析，搜集大量LOG，对切换失败和重建被拒进行分析，得出如下结论：
l 同一单板内，发生回切必然失败；
l 失败后的重建如果UE之前没有占用过某小区，无上下报文必然重建被拒。
后与家里研发确定该问题，是由于终端在收到RRC重配消息（切换命令），在PDCP层执行完整性保护校验时FAIL，之后PDCP上报RRC，触发RLF。完保FAIL的原因是：终端收到的MAC-I与实际计算的MAC-I不匹配，如下：
其他RB cfg index=33，对应SRB1，01:31:38.030 lte_pdcp_dl_protocol.c MAC-I mis-match RB Cfg idx = 33 seq_num = 0, rxed MAC-I = 0x783e182b, Calculated MAC-I = 0xbedccd4b 。
3.4.2.4 总结
该案例重建被拒是由于系统BUG导致，同一单板内回切失败，重建过程中如果重建到未知小区（UE从未占用过的小区）则重建被拒，原因是由于上下行报文不统一造成。
注意:
目前V3.10版本以上，只要配了X2链接，原则上跨站、跨板的重建拒绝问题都可以解决
3.5 rrcConnectionRelease掉线
出现rrcConnectionRelease消息计做掉话，但不包括以下原因：
l 系统间切换网络侧释放;
l 用户未激活，网络侧释放资源情况(User Inactivity)
l CSFB的网络侧释放（待确定）
目前暂未出现该类的掉线，后续有实例补充。
3.6 其他类掉线
其他类的掉线还未发现，但是测试中UE端口丢失是其他类掉线之一，目前CNT暂无法统计Lost Port情况，只能通过测试记录查看。
4 总结
掉线问题处理流程：
图 41 TD-LTE掉线处理流程
通常弱场按照经验是RSRP>-119，下行干扰比较严重经验是SINR>-3。
常规检查：
l 服务小区SINR过低，
l 邻区列表电平相差不大，无主覆盖小区；
l 后台硬件告警排查，如GPS干扰、MTS中各个通道是否正常；
l 邻区漏配；
l 邻区信息错误；
l 系统间邻区关系异常（后期检查）；
l 问题点尝试更换不同终端检查
l 问题点尝试服务小区闭塞解闭塞
设备告警检查：

图 42 影响网优告警列表