TDLTE网络优化指导书掉话优化.docx

TDLTE网络优化指导书掉话优化.docx

《TDLTE网络优化指导书掉话优化.docx》由会员分享，可在线阅读，更多相关《TDLTE网络优化指导书掉话优化.docx（21页珍藏版）》请在冰豆网上搜索。

TDLTE网络优化指导书掉话优化

TD-LTE网络优化指导书

掉话优化

责任部门：

审核：

批准：

2013-08发布2013-09实施

大唐移动通信设备有限公司发布

目录

1引言3

2基础知识3

2.1“连接”与“掉话”的概念3

2.2正常的连接释放4

2.3异常的连接释放（掉话）5

3DT/CQT常见掉话原因分析7

3.1弱覆盖7

3.2切换失败9

3.3邻区漏配10

3.4越区覆盖12

3.5系统设备异常14

3.6干扰15

3.7拥塞17

4话务统计掉话数据分析18

4.1掉话相关的KPI18

4.2全局掉话率偏高问题分析（TopN）18

4.3小区（簇）掉话率偏高问题分析19

5掉话问题的分析流程20

6典型掉话案例分析22

6.1弱覆盖导致的掉话22

6.2切换失败导致的掉话22

6.3邻区漏配导致的掉话23

1引言

编写本文的目的：

1.整理了与TD-LTE系统中与保持性（掉话）相关的基本概念、信令流程、所涉及的参数。

2.指导TD-LTE网络维护、优化过程中，与掉话相关的问题分析和定位（解决）。

2基础知识

知识点：

1、掉话的定义

2、掉话后UE、eNodeB的操作

2.1“连接”与“掉话”的概念

本文所提及的“保持性”，指的是“连接”的“保持性”，更狭义地，是指“RRC连接”的“保持性”。

因此，本文所称的“掉话”，具体是指UE异常退出RRC_CONNECTED状态导致的连接中断。

图21NAS和AS的几种状态

上图给出了从开机到进入激活（数据传输）状态过程中，从不同角度来看的“状态”的变化情况。

从EPS移动性管理（EMM）的角度来看，在UE成功附着之前，都认为是未登记（Deregistered）状态，直至UE发起、并成功登记。

对于EPS连接管理（ECM）来说，只有在激活态时，UE才会跟EPS是连接的，其余时间，UE处于和EPS的空闲状态。

对于RRC来说，只要UE和网络侧（空口、EPS）有连接，即为RRC的连接状态。

从ECM_Idle态转到ECM_Connected态，不仅涉及RRC连接建立、还涉及到S1连接建立。

RRC连接的建立由NAS发起、并先于S1连接建立完成。

RRC_Connected态的连接仅限于UE和E-UTRAN的控制信息的交互。

RRC连接的释放由eNB发起、紧随S1连接释放之后。

本文所称的“连接”，通常指的是RRC_Connected状态下的连接。

因受目前理解能力和OMC统计数据分析能力的限制，本文暂时只考虑上图中RRC_Connected状态（激活态）、暂不考虑附着过程中的连接状态。

通常将在附着过程中发生的RRC连接中断归为“接入失败”进行分析；本文所分析的“掉话”、仅限于RRC_Connected状态下的连接异常中断。

知识点：

掉话的定义

本文所称的“掉话”，具体是指UE异常退出RRC_CONNECTED状态导致的连接中断。

2.2正常的连接释放

在了解“掉话”之前，需要先了解正常的“通话结束”（即“连接释放”）的过程。

RRC连接释放流程如下图所示（见36.331协议的5.3.8小节RRCConnectionRelease）。

图22RRC连接释放（正常）

UE在接收到RRCConnectionRelease之后，应该：

1、从收到RRCConnectionRelease（或者下层指示收到RRCConnectionRelease消息）起，将下列操作延迟60ms；

2、如果RRCConnectionRelease消息中包含idleModeMobilityControlInfo，存储其中的小区重选优先级信息；如果消息中包含t320，启动该T320定时器（并将定时器取值为t320）；如果没有包含idleModeMobilityControlInfo，UE使用系统信息中广播的小区重选优先级信息。

3、如果RRCConnectionRelease消息中的releaseCause为loadBalancingTAURequired，UE将在离开RRC_CONNECTED时执行操作，并带上releaseCause为loadBalancingTAURequired；如果releaseCause为other，则在离开RRC_CONNECTED时执行操作，并带上releaseCause为other。

UE在离开RRC_CONNECTED时执行的操作：

1、重置MAC；

2、停止除T320以外的所有定时器；

3、释放全部无线资源，包括释放全部已建立的RB的RLC实体、MAC配置和相关的PDCP实体；

4、告诉上层RRC连接释放（带上releaseCause）；

5、如果不是由于收到MobilityFromEUTRACommand消息而触发的离开RRC_CONNECTED状态，UE将（根据离开RRC_CONNECTED的原因）通过执行小区重选过程进入RRC_IDLE，具体见TS36.304[4].

通常情况下，以下情形会触发EUTRAN下发RRCConnectionRelease消息：

1、UE发起Detach之后；

2、TAU之后

3、核心网触发loadBalancingTAURequired之后

2.3异常的连接释放（掉话）

结合常见的掉话类型，从信令上来看，有以下几种体现：

1、重建立失败导致的掉话：

信令上可以看到：

图23常见掉话的信令表现

（1）——重建立失败导致的掉话

1）首先是UE在UL-CCCH上发送“rrcConnectionReestablishmentRequest;Cause=otherFailure”；

2）接着eNB在DL-CCCH上回复“rrcConnectionReestablishmentReject”；

3）随后UE发生掉话、开始接收系统广播消息（在BCCH-SCH上的SIB1）、直至UE发起下一次呼叫。

2、空口信号变差等原因导致的掉话：

只能看到信令不完整——UE在没有收到Release消息的情况下，直接从RRC-CONNECTED状态转到RRC-IDLE。

此类掉话的一个典型表象为：

UE发起了RRCConnectionReestablishmentRequest、但是没有收到eNodeB发来的RRCConnectionReestablishment，而且UE也没有发出RRCConnectionReestablishmentComplete消息。

图24常见掉话的信令表现

（2）——空口信号变差等原因导致的掉话

3、狭义上来讲，可以认为“只要UE发起了RRC重建立，就意味着RRC连接已断、即产生了掉话”。

在实际项目中，还会碰到这种情况：

由于切换失败或其他原因导致的RRC连接重建立，而这种RRC连接重建立往往是成功的。

因此，在项目运作的时候，这种RRC重建立是否算作掉话，需要特别关注、在必要时需要和客户达成一致意见。

图25常见掉话的信令表现（3）——其他原因导致的RRC重建立

注意:

项目执行过程中，需要明确“掉话”的具体定义

在实际项目中，通常需要与客户就掉话的定义达成共识。

考虑到实际用户的应用是以数据业务为主，因此项目组与客户协商、达成共识：

只要重建立时间在100ms之内（即从UE发起RRCConnectionReestablishmentRequest，到UE回复RRCConnectionReestablishmentComplete的时间间隔小于100ms），都不计入掉话。

（注：

这仅仅是统计方法上的定义）

3DT/CQT常见掉话原因分析

3.1弱覆盖

现象

由于弱覆盖导致的掉话，通常有以下表现：

1.掉话前服务小区的RSRP持续变差（低于弱覆盖标准，如：

小于-105dBm）、同时服务小区的SINR也一起持续变差（小于-5dB，甚至更低）；

2.掉话后可能会有一段时间（数秒至数分钟不等，取决于实际网络覆盖情况），UE无数据上报（类似于UE脱网）。

图31弱覆盖导致的掉话示意图

分析方法

采用路测数据分析法。

步骤1、采集到相关路测数据，用路测数据分析软件OUTUM进行分析；

步骤2、定位到掉话时间点的数据，通过查看地理化显示的图层（服务小区RSRP、SINR）确认以下特征：

（1）掉话时，UE测得的服务小区RSRP低（如：

<-105dBm）；

（2）掉话时，UE测得的服务小区SINR低（如：

<0dB）

（3）掉话时，UE没有测到（上报）其他（如：

强度>-105dBm的）邻区信号。

解决方案

总的来说，要解决此类掉话，需要改善覆盖，具体的操作步骤和手段有：

1.首先明确当前的弱覆盖区域由哪些扇区的信号覆盖；

2.根据网络拓扑结构和相关无线环境来确定最适合覆盖该区域的扇区、并加强它的覆盖：

（1）排除主覆盖小区的硬件故障（例如：

基带及射频器件故障、天馈系统驻波比告警等）

（2）上调主覆盖小区的RS功率

（3）上调主覆盖扇区的功率

（4）调整主覆盖扇区的天线下倾角

（5）调整住覆盖扇区的天线方位角

（6）建议加站（并调整周边基站天线的方位角和下倾角）

3.开启SON-CCO（Coverage&CapacityOptimization）功能（待实现）

3.2切换失败

现象

由于切换失败导致的掉话，通常有以下表现：

1.首先，在掉话前UE曾发出MeasurementReport、并能收到eNB发来的RRCConnectionReconfiguration；

2.但是UE收取目标小区的广播消息之后、立即上报“RRC连接重建立请求”（rrcConnectionReestablishmentRequest;Cause=handoverFailure）；

3.通常UE在切换失败后，都会发起回到源小区的“RRC连接重建立请求”、并且此类RRC连接重建立成功率大部分都是成功的、此类重建立通常也会在100ms内完成。

图32信令（由于切换失败导致的掉话）

分析方法

采用信令分析法。

步骤1、获取采集到的掉话数据，使用路测数据分析软件OUTUM进行分析；

步骤2、打开路测数据的信令，定位到掉话时间点，确认以下几个特征：

（1）掉话前UE曾发起MeasurementReport消息；

（2）UE能够收到eNB发来的带有MobilityControlInfo内容的“RRC连接重配置”消息

（3）UE切换到“RRC连接重配置”消息所带的目标小区后、在该小区的BCCH-SCH上接收到广播消息（systemInformationBlockType1）；

（4）UE收完广播消息后、发起“RRC连接重建立（原因为切换失败）”；

（5）通常UE能够在较短时间（200ms）内重建立成功、回到切换前的源小区。

步骤3、进一步分析以下内容：

（1）明确MR消息和RRC连接重配置消息中所提及的目标小区的PCI，确认该PCI所指小区；

（2）分析UE在新的目标小区接收到的广播消息，确认该小区是否就是MR消息上报的小区，用以排除邻区错配的情况；

（3）在OMC中确认邻区配置,检查邻区参数是否正确；

（4）确认OMC中的切换类型（X2、S1）；

（5）确认目标小区的工作状态（小区的功率输出、小区负荷）、排除由于目标小区工作异常导致的切换失败；

（6）确认源小区和目标小区的切换参数（门限、TTT和迟滞等）配置与其他正常小区的相同。

步骤4、如果上述分析无法得到明确结论，需要进一步确认该小区的切换成功率，如果该目标小区的切换成功率偏低，初步定为为基站故障（或者系统版本问题），需要进一步将问题反馈给后方