TD-LTE掉线优化指导书

适用对象：TDD网优工程师

使用建议：在阅读本文档之前，建议先了解下面的知识和技能：

摘要

目录

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

1概述

本文主要介绍了TD-LTE系统掉线问题优化方法，通过对各局出现的掉线问题进行讲解说明，总结了TD-LTE掉线的处理思路及优化方案，为后续各个外场处理TD-LTE掉线问题提供了优化经验。

2TD-LTE完整业务流程

TD-LTE完整业务信令流程如下：

图21TD-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）的条件：

●    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

●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.2CNT信令

结合CNT与dongle连接真实信令过程如下：

图23CNT信令

本次释放是UE发起的去附着过程，后续RRC release过程CNT无法体现。

3掉线问题分析

3.1分析思路

对于TD-LTE的掉线，是在UE完成“RRCConnectionReconfigurationComplete”处于连接态，之后由于干扰、弱场、其他原因导致的UE上下行失步，触发重建未果或者被拒过程。只要不是终端主动发起的释放，都应算为掉线。目前掉线在信令中表现如下3种情况。

●连接态下触发RRC重建无果

图31RRC重建无果

●连接状态下触发RRC重建被拒

图32RRC重建被拒

●连接状态下异常收到RRC释放消息

图33异常收到RRC释放消息

对于非正常释放的掉线问题，TD-LTE引入了重建立机制，对于重建立的掉线的分析要分2部分完成：

●引起重建的原因；

●重建失败的原因；

因此基于上述掉线进行分析总结

图34TD-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

●UE发送rrcConnectionReestablishmentRequest但无对应的rrcConnectionReestablishmentComplete消息；

●出现rrcConnectionRelease消息，但不包括：

-1系统间切换网络侧释放;

-2用户未激活，网络侧释放资源情况(User Inactivity)

-3 CSFB的网络侧释放（待确定）

说明：对于TDD-LTE制式，掉线对用户感知的评判有所减弱，此公式只是一般情况，后续可以与局方协商对掉线率公式修改，如 RRC重建被拒后2s内业务恢复成功不计做掉话，或者可以用时间掉线比(分母是测试总时长)、公里掉线比(分母是DT测试公里数)

3.3重建原因

3.3.1定时器不合理

定时器相关参数优化建议值如下：

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=6PCI=28小区后切换正常

3.3.5.4总结

由于目前SON的自动邻区功能不成熟，路测中遇到多次上报MR始终不切换的情况需要根据实际覆盖与邻区关系对比，添加合适的邻区关系，但是也要避免切换参数不合理的突发信号引起的不良MR情况，需要对每个异常问题深刻分析。

3.4UE触发重建

协议中定义了触发重建的流程及信令

图37RRC重建成功

图38RRC重建被拒

协议中对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:

●upon detecting radio link failure, in accordance with “Radio link failure related actions or”

●通常无线链路失败，牵扯到公共信道、业务信道的覆盖和干扰情况

●upon handover failure, in accordance with ”T304 expiry (handover failure)”or

●切换等待定时器超时导致，查看小区邻区及参数是否合理

●upon mobility from E-UTRA failure, in accordance with “Mobility from E-UTRA failure” or

●检查配置是否合理及参数

●upon integrity check failure indication from lower layersor

●完整性检查失败,如加密算法，与NAS的直传消息受阻导致

●upon an RRC connection reconfiguration failure, in accordance with “Reconfiguration failure”

3.4.1UE触发重建未果

目前还未发现这种触发重建后没有下文的情况，后续版本补充。

根据通常网优经验，发生这种情况一般都是由于UE发送重建立消息过程中，由于覆盖场强过弱、上行功率异常、干扰等导致。

按照掉线处理思路流程，先确定个性还是局部问题，然后查看发生该问题的服务小区、目标小区有无硬件告警，再查看覆盖、干扰、参数情况进行判断。

3.4.2UE触发重建被拒

该问题通常信令如下图所示：

图39UE触发重建被拒

通常发生RRC被拒一般都是由于版本问题、上下行报文错误、设备原因导致。

典型案例分析

3.4.2.1现象描述

福冈FT拉网测试中，UE最初占用PCI=25号小区，后切换至PCI=18号小区，切换成功。由于日本全向天线，且在闹市区，存在电平波动，后UE检测到PCI=25号小区满足切换条件，网络下发RRC重配置给UE，携带切换目标小区是原服务小区PCI=25号，可是切换失败，后无线链路失败触发重建立过程：

当时信令表现如下：

蓝色部分是UE从PCI=25PCI=18成功，绿色是从PCI=18PCI=25进行回切失败

后RLF，红色是触发重建过程，从PCI=18PCI=45被拒，造成掉线。

3.4.2.2现象分析

这种现象在测试过程中发生次数较多，根据掉线排查思路，优先查看切换失败到重建立过程中覆盖、干扰情况，发现此过程中的前后几秒内小区覆盖较好，SINR>3，无干扰，后查看后台目标服务小区均无硬件告警。

抓取不同时间段的LOG，对目标和服务小区切换做了统计，有如下规律：

根据上述分析，搜集大量LOG，对切换失败和重建被拒进行分析，得出如下结论：

●同一单板内，发生回切必然失败；

●失败后的重建如果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 Cfgidx = 33 seq_num = 0, rxed MAC-I = 0x783e182b, Calculated MAC-I = 0xbedccd4b 。

3.4.2.4总结

该案例重建被拒是由于系统BUG导致，同一单板内回切失败，重建过程中如果重建到未知小区（UE从未占用过的小区）则重建被拒，原因是由于上下行报文不统一造成。

注意:

目前V3.10版本以上，只要配了X2链接，原则上跨站、跨板的重建拒绝问题都可以解决

3.5rrcConnectionRelease掉线

出现rrcConnectionRelease消息计做掉话，但不包括以下原因：

●    系统间切换网络侧释放;

●    用户未激活，网络侧释放资源情况(User Inactivity)

●    CSFB的网络侧释放（待确定）

目前暂未出现该类的掉线，后续有实例补充。

3.6其他类掉线

其他类的掉线还未发现，但是测试中UE端口丢失是其他类掉线之一，目前CNT暂无法统计Lost Port情况，只能通过测试记录查看。

4总结

掉线问题处理流程：

图41TD-LTE掉线处理流程

通常弱场按照经验是RSRP>-119，下行干扰比较严重经验是SINR>-3。

常规检查：

●服务小区SINR过低，

●邻区列表电平相差不大，无主覆盖小区；

●后台硬件告警排查，如GPS干扰、MTS中各个通道是否正常；

●邻区漏配；

●邻区信息错误；

●系统间邻区关系异常（后期检查）；

●问题点尝试更换不同终端检查

●问题点尝试服务小区闭塞解闭塞

设备告警检查：

图42影响网优告警列表