湖南移动TDLTE掉线优化指导手册V12.docx

湖南移动TDLTE掉线优化指导手册V12.docx

《湖南移动TDLTE掉线优化指导手册V12.docx》由会员分享，可在线阅读，更多相关《湖南移动TDLTE掉线优化指导手册V12.docx（47页珍藏版）》请在冰豆网上搜索。

湖南移动TDLTE掉线优化指导手册V12

湖南移动TD-LTE掉线优化指导手册

（V1.2）

华为技术有限公司

2015年1月

目录

1概述3

2掉线的相关定义3

2.1终端掉线的定义3

2.2网络侧掉线公式定义4

2.3标口信令7

3掉线问题定位及处理10

3.1掉线分析流程图10

3.2全网掉线分析11

3.3掉线TOP小区分析13

3.4掉线具体原因分析14

3.4.1故障告警14

3.4.2邻区错/漏配17

3.4.3弱覆盖19

3.4.4干扰21

3.4.5切换导致的掉线22

3.4.6相关问题信息反馈到研发25

4掉线相关案例27

案例1-驻波告警导致掉线27

案例2-过覆盖问题导致掉线31

案例3-切换参数不合理导致掉线35

1

概述

本指导手册从KPI公式定义出发，从流程上对掉线率及影响KPI指标的因素进行了进一步的说明；重点介绍了LTE系统内掉话率指标的优化思路、分析方法、定位手段及典型案例。

2掉线的相关定义

2.1终端掉线的定义

CallDropRate=eRABAbnormRel/eRABSetupSuccess*100%

eRABAbnormRel：

eRAB异常释放事件次数

eRABSetupSuccess：

eRAB建立成功事件次数

华为GenexPA软件定义

一、终端没有收到“DEACTIVATEEPSBEARERCONTEXTREQUEST”的NAS消息，也没有收到MME的“DETACHREQUEST”的NAS消息，也没有向网络侧主动发出“DETACHREQUEST”的NAS消息，但收到了RRCConnectionReconfiguration消息，且其中有信元“drb-ToReleaseList”，则生成一次ERABAbnormalRel。

记录ReleaseList下的eps-BearerIdentity个数。

如果ERABnum减完eps-BearerIdentity个数以后是0，则状态迁移到RRC_Idle，否则状态不迁移。

二、或者终端在没有收到“DEACTIVATEEPSBEARERCONTEXTREQUEST”的NAS消息，也没有收到MME的“DETACHREQUEST”的NAS消息，也没有向网络侧主动发出“DETACHREQUEST”的NAS消息，却收到了RRCConnectionrelease消息并且前4s如果有RLC层速率传输（上下行都需要考虑进来的，任何一个方向只要有数传即满足条件），生成一次ERABAbnormalRel，状态迁移到RRC_idle。

三、或者终端之前已经建立了eRAB，但是在收到RRC释放信令之前，因为异常RRCState进入Idle，生成一次ERABAbnormalRel，释放次数增加所有建立的eRAB个数。

四、在没有收到RRCConnectionReconfiguration，DEACTIVATEEPSBEARERCONTEXTREQUEST，DETACHREQUEST，RRCState,RRCConnectionrelease消息时，终端发起RRC请求时将判断一个ERAB异常释放事件。

五、遇到RRCReestablishFail事件时同时输出ERAB异常释放事件，打点时间与RRCReestablishFail相同

2.2网络侧掉线公式定义

CallDropRate=L.E-RAB.AbnormRel/（L.E-RAB.NormRel+L.E-RAB.AbnormRel）*100%

L.E-RAB.AbnormRel：

小区异常释放用户E-RAB的总次数

L.E-RAB.NormRel：

小区正常释放用户E-RAB的总次数

正常释放测量指标

下表1内所示是正常释放话统测量指标

表1正常释放测量指标

指标ID

测量指标

指标描述

单位

1526727547

L.E-RAB.NormRel

eNodeB正常释放E-RAB的总次数

次

1526726687

L.E-RAB.NormRel.QCI.1

小区QCI为1的E-RAB正常释放次数

次

1526726689

L.E-RAB.NormRel.QCI.2

小区QCI为2的E-RAB正常释放次数

次

1526726691

L.E-RAB.NormRel.QCI.3

小区QCI为3的E-RAB正常释放次数

次

1526726693

L.E-RAB.NormRel.QCI.4

小区QCI为4的E-RAB正常释放次数

次

1526726695

L.E-RAB.NormRel.QCI.5

小区QCI为5的E-RAB正常释放次数

次

1526726697

L.E-RAB.NormRel.QCI.6

小区QCI为6的E-RAB正常释放次数

次

1526726699

L.E-RAB.NormRel.QCI.7

小区QCI为7的E-RAB正常释放次数

次

1526726701

L.E-RAB.NormRel.QCI.8

小区QCI为8的E-RAB正常释放次数

次

1526726703

L.E-RAB.NormRel.QCI.9

小区QCI为9的E-RAB正常释放次数

次

异常释放测量指标

下表2内所示是异常释放话统测量指标

表2异常释放测量指标

指标ID

测量指标

指标描述

单位

1526727546

L.E-RAB.AbnormRel

eNodeB异常释放有数传的E-RAB的总次数

次

1526726686

L.E-RAB.AbnormRel.QCI.1

小区QCI为1的E-RAB异常释放次数

次

1526726688

L.E-RAB.AbnormRel.QCI.2

小区QCI为2的E-RAB异常释放次数

次

1526726690

L.E-RAB.AbnormRel.QCI.3

小区QCI为3的E-RAB异常释放次数

次

1526726692

L.E-RAB.AbnormRel.QCI.4

小区QCI为4的E-RAB异常释放次数

次

1526726694

L.E-RAB.AbnormRel.QCI.5

小区QCI为5的E-RAB异常释放次数

次

1526726696

L.E-RAB.AbnormRel.QCI.6

小区QCI为6的E-RAB异常释放次数

次

1526726698

L.E-RAB.AbnormRel.QCI.7

小区QCI为7的E-RAB异常释放次数

次

1526726700

L.E-RAB.AbnormRel.QCI.8

小区QCI为8的E-RAB异常释放次数

次

1526726702

L.E-RAB.AbnormRel.QCI.9

小区QCI为9的E-RAB异常释放次数

次

华为eRAN7.0定义:

无线掉线率=（eNodeB发起的S1RESET导致的UEContext释放次数+UEContext异常释放次数）/（UEContext建立成功总次数+小区遗留UE上下文个数）*100%；

E-RAB掉线率=（eNodeB触发的释放原因为异常的E-RAB释放总次数+切换出E-RAB异常释放总次数）/（用户发起E-RAB建立流程且建立成功的总次数+遗留E-RAB总个数）*100%；

网络侧异常释放原因Counter

针对eRAB异常释放原因值的统计目前共有5个

L.E-RAB.AbnormRel.Radio（无线层问题导致的E-RAB异常释放次数）

L.E-RAB.AbnormRel.TNL（传输层问题导致的E-RAB异常释放次数）

L.E-RAB.AbnormRel.Cong（网络拥塞导致的E-RAB异常释放次数）

L.E-RAB.AbnormRel.HOFailure（切换流程失败导致E-RAB异常释放次数）

L.E-RAB.AbnormRel.MME（核心网问题导致E-RAB异常释放次数）

核心网问题导致的异常释放

如下图1/图2中A点所示，为MME主动发起E-RAB/UECONTEXT释放流程，当eNodeB收到来自MME的E-RABRELEASECOMMAND/UECONTEXTRELEASECOMMAND消息时，且释放原因不为“NormalRelease”，“Detach”，“UserInactivity”，“csfallbacktriggered”，“Inter-RATredirection”则统计L.E-RAB.AbnormRel.MME指标。

注：

L.E-RAB.AbnormRel.MME指标并不统计在L.E-RAB.AbnormRel指标内，即核心网主动释放在eRAN2.1SPC400版本之后不计为掉线

非核心网问题导致的异常释放

如图3中A点所示，当eNodeB向MME发送E-RABRELEASEINDICATION消息，当释放原因为无线层错误时，统计L.E-RAB.AbnormRel.Radio指标；当释放原因为传输层错误时，统计L.E-RAB.AbnormRel.TNL指标；当释放原因为网络拥塞时，统计L.E-RAB.AbnormRel.Cong指标。

如果E-RABRELEASEINDICATION消息中要求同时释放多个E-RAB，则相应指标根据具体业务数目按上述原因分别进行累加；

如图4中A点所示，当eNodeB向MME发送UECONTEXTRELEASEREQUEST消息，会释放UE的所有E-RAB。

当释放原因为无线层错误时，统计L.E-RAB.AbnormRel.Radio指标；当释放原因为传输层错误时，统计L.E-RAB.AbnormRel.TNL指标；当释放原因为网络拥塞时，统计L.E-RAB.AbnormRel.Cong指标，本指标统计包括因抢占和资源拥塞导致的异常释放；当释放原因为切换失败时，统计L.E-RAB.AbnormRel.HOFailure指标。

相应指标根据具体业务数目按上述原因分别进行累加。

并且在MME回复UECONTEXTRELEASECOMMAND消息时，该指标不会被重复记录

2.3标口信令

在eNodeB跟踪到的标准接口信令中，如果存在eNodeB发起的释放，即在S1接口上发往CN的S1AP_UE_CONTEXT_REL_REQ消息内携带的原因值不为“NormalRelease”，“UserInactivity”，“csfallbacktriggered”，“Inter-RATredirection”时统计该指标判断为掉话。

异常掉话通常都是由eNB发起的释放，通知MME释放上下文，因此只要查看S1口发送的S1AP_UE_CONTEXT_REL_REQ消息即可，如下图所示：

图2S1口跟踪的UE上下文正常释放消息

图3S1口跟踪的UE上下文常释放消息

根据对应的时间点，打开标准Uu口的跟踪，找到对应时间点的RRC_CONN_REL消息，如下图所示。

图4Uu口跟踪的RRC常释放消息

打开IFTS跟踪，查找对应的时间点的跟踪是否可以和Uu口、S1口对应上，如果无法对应，说明该IFTS跟踪的UE和当前掉话的UE不是同一个UE，则该IFTS跟踪就没有分析的必要。

如果可以找到IFTS跟踪的UE和当前掉话的UE是同一个UE，则把该S1/Uu/IFTS跟踪返回总部分析。

IFTS跟踪如下：

3掉线问题定位及处理

3.1掉线分析流程图

3.2全网掉线分析

1、首先需要在话统侧获取全网的掉话率指标以及趋势，掉话率趋势分析至少需要分析1~2周左右的数据。

如果全网的掉话率指标突然偏高，一般下列因素会导致全网的掉话率突然增加，需要执行以下的检查：

是否存在传输告警：

观察S1口传输是否出现问题；

是否存在设备告警：

观察eNodeB侧是否存在告警；

是否存在版本升级、割接等操作；

2、全网话务量趋势分析：

分析是否由于话务量突然增加导致掉话率上升；话务量的分析通常可通过e-RAB尝试建立的次数及成功次数的分布来判断，对大话务导致的高掉线，可通过扩容处理。

3、如果面全网的掉话率指标一直偏高，分析小区级别的掉话率指标，把小区级的掉话率指标和掉话绝对次数按从高到低的顺序进行排序，优先分析掉话绝对次数多而且掉话率也很高的Top小区；进行小区掉话指标分析；

4、需要检查小区参数在掉话率异常期间是否存在修改，与掉话率相关参数的几个重要参数（切换类参数在3.4.5章节有详细介绍）如下表所示：

表1部分掉话率相关参数及定时器

参数名

参数中文名

参数含义

MMLCommand

TPERODICBSRTIMER

周期性BSR上报定时器

该参数表示周期性BSR上报定时器时长。

MODTYPDRBBSR

RETXBSRTIMER

BSR重传定时器

该参数表示BSR重传定时器的时长。

BSR发送之后，需要启用该定时器。

MODTYPDRBBSR

SRIPERIOD

SRI周期

该参数表示QCI级别对应的SRI周期。

MODCELLSTANDARDQCI

T304ForEutran

系统切换304定时器

该参数表示系统内切换使用的定时器T304的时长。

如果UE在该时长内无法完成对应的切换过程，则进行相应的资源回退，并发起RRC连接重建过程。

MODRRCCONNSTATETIMER

UeInactiveTimer

UE不活动定时器长度

该参数用来指示eNodeB对UE是否发送和接收数据进行监测，如果UE一直都没有接收和发送数据，并且持续时间超过该定时器时长，则释放该UE，配置为0表示不限制。

MODRRCCONNSTATETIMER

T301

定时器301

该参数表示定时器301的时长，参见3GPPTS36.331。

UE在发送RRCConnectionReestabilshmentRequest时启动该定时器。

定时器超时前，如果UE收到RRCConnectionReestablishment或者RRCConnectionReestablishmentReject或者被选择小区变成不适合小区，则停止该定时器。

定时器超时后，UE进入RRC_IDLE态。

MODUETIMERCONST

T310

定时器310

该参数表示定时器310的时长，参见3GPPTS36.331。

UE在检测到物理层故障时，启动该定时器。

在定时器超时前，如果UE检测到物理层故障恢复，或者触发切换流程，或者UE发起连接重建流程，则停止该定时器。

定时器超时后，如果没有激活安全模式，UE进入RRC_IDLE态；否则，停止T312（如果T312正在运行），同时发起链接重建流程。

MODUETIMERCONST

T311

定时器311

该参数表示定时器311的时长，参见3GPPTS36.331。

UE在发起RRC连接重建流程时启动该定时器。

定时器超时前，如果UE选择了一个EUTRA小区或者异系统小区后，停止此定时器。

定时器超时后，UE进入RRC_IDLE态。

MODUETIMERCONST

N311

常量N311

该参数表示接收到底层的连续"同步"指示的最大数目，参见3GPPTS36.331。

MODUETIMERCONST

N310

常量N310

该参数表示接收到底层的连续"失步"指示的最大数目，参见3GPPTS36.331。

MODUETIMERCONST

5、分析掉话统计结果，对Top小区实施优化措施；优化措施实施后对比该小区的掉话率指标是否改善；分析优化措施是否可以全网复制，如果可以的话安排全网经验复制，分析实施后的指标是否满足要求，如果满足要求，那么结束掉话优化；否则，重新进行Top小区优化。

3.3掉线TOP小区分析

根据掉线统计指标筛选出需要处理的TOP小区，日粒高掉线小区：

累计3个或以上时段无线掉线率大于5%且E-RAB的建立成功总次数>50。

1、提取小区级话统的掉话率指标及趋势，掉话率趋势分析至少需要分析3天左右的数据；如果小区的掉话率指标突然偏高，需要检查eNodeB侧是否存在该小区相关的告警信息。

2、分析小区级掉话原因统计数据，获取导致掉话的各种原因的比例，按照比例从高到低的顺序分别针对不同的原因进行分析；提取掉线原因统计具体步骤如下：

4、是否存在OM操作导致的站点复位，重启等导致的掉话；

查看操作日志MML命令：

LSTOPTLOG；

3.4掉线具体原因分析

3.4.1故障告警

传输问题（S1、X2口复位、闪断等）

eNB故障（单板复位、射频通道故障等）

UE故障等（UE死机、发热、版本缺点等）

在排除了以上的原因之后，其他的掉线一般需要怀疑是否是设备存在问题，需要通过查看设备的日志文件，告警信息等进一步来分析掉线原因。

还有在路测过程中易引起路测终端过热/死机，或者连线脱落/掉电导致的掉线。

通常eNodeB侧的告警可通过在U2000侧进行观察，对于每个告警，都有相关的处理建议，可通过U2000的在线帮助进行阅读。

如下图所示：

图5U2000告警浏览界面

也可通过MML命令查询告警，查看告警MML命令如下：

LSTALMAF（查询当前告警）

LSTALMLOG（查询告警日志）。

可能导致掉线的告警如下表：

告警名称

射频单元驻波告警

射频单元维护链路异常告警

BBUIR光模块收发异常告警

射频单元光模块收发异常告警

射频单元时钟异常告警

单板硬件故障告警

射频单元IR接口异常告警

BBUIR接口异常告警

星卡天线故障告警

星卡锁星不足告警

射频单元光接口性能恶化告警

射频单元业务不可用告警

射频单元硬件故障告警

射频单元发射通道增益异常告警

小区服务能力下降告警

S1接口故障告警

BBUIR光模块故障告警

发现故障引起掉线高，本端能解决的马上处理，需维护人员处理的及时上报沟通，协助处理。

3.4.2邻区错/漏配

通常，网络建设初期优化过程掉线占大多数是由于邻区错/漏配导致的。

对于LTE网络内同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：

方法一：

如果掉线后UE马上重新接入，且UE重新接入的PCI与UE掉线时的PCI不一致，则可以怀疑是邻区错/漏配问题，可以通过测量控制进一步进行确认（从掉线位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。

方法二：

在网络侧，观察eNodeB在收到UE上报的测量报告后如果没有处理，且同时X2口没有往目标小区发送HANDOVER_REQUEST，则可以怀疑是邻小区漏配。

（该方法只适用于异站切换，同站切换没有X2口交互）。

邻区漏配导致的掉线也包括异频邻区漏配和异系统邻区漏配。

异频邻区漏配的确认方法和同频几乎相同，主要是掉线发生的时候，UE没有测量或者上报异频邻区，而UE掉线后重新驻留到异频邻区上。

异系统邻区漏配表现为UE在LTE网络掉线，掉线后UE重新选网驻留到异系统网络，且从信号质量来看，异系统网络的质量很好。

定位邻小区错/漏配的方法可通过UE的Scanner功能进行扫频，观察是否有更强的的且不在邻小区列表中的小区。

邻小区错/漏配需要结合工参、电子地图等信息进行优化，添加必要的邻区。

进行核查时通过命令对邻区查看：

查询同频邻区MML命令：

LSTEUTRANINTRAFREQNCELL；

查询异频邻区MML命令：

LSTEUTRANINTERFREQNCELL；

对错配的邻区需进行外部小区核查，需提取外部小区数据与现网小区数据进行对比核查，具体步骤如下：

提取现网小区数据MML命令：

查询小区静态参数：

LSTCELL

查询eNodeB功能配置：

LSTENODEBFUNCTION

查看跟踪区域配置信息：

LSTCNOPERATORTA

提取外部小区命令：

查询EUTRAN外部小区：

LSTEUTRANEXTERNALCELL

将外部小区数据和现网小区数据的ENODEBID、TAC、PCI和频点进行对比，将与现网小区数据不符的配置进行修改。

3.4.3弱覆盖

这里所说的弱覆盖是超出了链路预算获得的最大路损得到的下行及上行的覆盖，由于上下行支持的最大路损不一致，通常在LTE中上行较之于下行先受限，故在这里提到的弱覆盖将分为上行弱覆盖及下行弱覆盖。

只要是上行或者下行其中一个存在弱覆盖，则就有导致掉线发生的可能。

弱覆盖问题需要结合实际路测情况及工参进行调整优化。

怀疑弱覆盖原因先检查是否有告警导致，例如驻波告警，天馈接口的回波损耗较大，导致实际输出功率减小，小区覆盖减小。

告警查询MML命令：

LSTALMAF

功率被人为的调低，影响覆盖。

功率查询MML命令：

LSTPDSCHCFG

现场环境、站高和天线下倾角排查，是否有阻挡，天线挂高过低，下倾角过大。

U2000中性能-结果查询中有eNodeB发起的原因为上行弱覆盖的UEContext异常释放次数统计项，可参考。

如图：

3.4.4干扰

通常干扰分为上行干扰及下行干扰，系统内干扰及外来干扰。

不论哪种类型的干扰都会导致掉线。

外部干扰一般指当前网络制式之外的干扰源引起的干扰。

外部干扰源由于非法或不当使用引起对TD-LTE频段的干扰。

集中体现为同频干扰。

常见的外部干扰包括：

军区的通信系统、学校及社会考点的信号屏蔽装置、银行ATM机内警用信号干扰装置等，可通过扫频进行排查。

LTE网内干扰，由于LTE采取的同频组网，因此必然会存在同频干扰，PCI规划不合理还容易导致MOD3干扰。

通常，对于下行，当服务小区的RSRP高于-90dBm，但是SINR低于-6dbm，基本上可以认为是下行干扰的问题（当邻小区错/漏配或切换不及时的时候，也可能出现服务小区RSRP信号很好，但SINR很差的情况）；下行的干扰通常是指导频污染，指覆盖地区存在3个以上的小区满足切换条件，由于信号的波动常常出现频繁小区重选或者乒乓切换，可能会导致掉线。

上行干扰可通过查询PRB干扰噪声统计，系统上行每个PRB上检测到的干扰噪声的平均值（毫瓦分贝）>-110，判断为有上行干扰，具体如图：

通常在没有干扰的情况下，上下行是平衡的，而当下行存在干扰时，会体现在下行受限，上行不受限；而存在上行干扰时，则是上行受限但下行不受限。

3.4.5切换导致的掉线

在时间轴上，可将切换分为如下3类：

过早切换、过晚切换及乒乓切换。

由于重建的引入，通常过早切换能重建回原小区，故不会引发掉线，而过晚切换及乒乓切换易导致掉线。

切换相关参数为了控制切换信令流程的准确和及时，网络侧通过一些参数来控制切换的触发条件，根据我司的切换算法实现，同频切换采用A3事件来触发切换；异频切换采用A1-A2，A3-A4来触发；异系统切换采用A1-A2，B1-B2来实现。

当前最常用的参数有：

同频切换幅度迟滞、同频切换偏置、同频切换时间迟滞、异频A1RSRP触发门限、异频A2RSRP触发门限、基于覆盖的异频RSRP触发门限（A4）、异频切换幅度迟滞、异频切换时间迟滞、CIO。

查询CIO的MML命令：

同频邻区CIO：

LSTEUTRANINTRAFREQNCELL

异频邻区CIO：

LSTEUTRANINTERFREQNCELL

查询同频切换参