TD-LTE网络优化指导书-掉话优化

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切换失败 (8)3.3邻区漏配 (10)3.4越区覆盖 (11)3.5系统设备异常 (13)3.6干扰 (14)3.7拥塞 (16)4话务统计掉话数据分析......................................................... (17)4.1掉话相关的KPI (17)4.2全局掉话率偏高问题分析（Top N） (18)4.3小区（簇）掉话率偏高问题分析 (19)5掉话问题的分析流程 (20)6典型掉话案例分析 (21)6.1弱覆盖导致的掉话 (21)6.2切换失败导致的掉话 (21)6.3邻区漏配导致的掉话 (22)1引言编写本文的目的：1. 整理了与TD-LTE系统中与保持性（掉话）相关的基本概念、信令流程、所涉及的参数。

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

2基础知识知识点：1、掉话的定义2、掉话后UE、eNodeB的操作2.1“连接”与“掉话”的概念本文所提及的“保持性”，指的是“连接”的“保持性”，更狭义地，是指“RRC连接”的“保持性”。

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

图0-1 NAS和AS的几种状态移动性管理（EMM）连接管理（ECM）无线资源控制（RRC）上图给出了从开机到进入激活（数据传输）状态过程中，从不同角度来看的“状态”的变化情况。

从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小节RRC Connection Release）。

图0-2 RRC连接释放（正常）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、重建立失败导致的掉话：信令上可以看到：图0-3 常见掉话的信令表现（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消息。

图0-4 常见掉话的信令表现（2）——空口信号变差等原因导致的掉话3、狭义上来讲，可以认为“只要UE发起了RRC重建立，就意味着RRC连接已断、即产生了掉话”。

在实际项目中，还会碰到这种情况：由于切换失败或其他原因导致的RRC连接重建立，而这种RRC连接重建立往往是成功的。

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

图0-5 常见掉话的信令表现（3）——其他原因导致的RRC重建立注意: 项目执行过程中，需要明确“掉话”的具体定义在实际项目中，通常需要与客户就掉话的定义达成共识。

考虑到实际用户的应用是以数据业务为主，因此项目组与客户协商、达成共识：只要重建立时间在100ms之内（即从UE发起RRCConnectionReestablishmentRequest，到UE回复RRCConnectionReestablishmentComplete的时间间隔小于100ms1），都不计入掉话。

（注：这仅仅是统计方法上的定义）3DT/CQT 常见掉话原因分析3.1弱覆盖现象由于弱覆盖导致的掉话，通常有以下表现：1. 掉话前服务小区的RSRP 持续变差（低于弱覆盖标准2，如：小于-105dBm ）、同时服务小区的SINR 也一起持续变差（小于-5dB ，甚至更低）；2. 掉话后可能会有一段时间（数秒至数分钟不等，取决于实际网络覆盖情况），UE 无数据上报（类似于UE 脱网）。

图 0-1 弱覆盖导致的掉话示意图-130-110-90-701020-10PoorCoverage分析方法采用路测数据分析法。

步骤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 & Capacity Optimization）功能（待实现）3.2切换失败现象由于切换失败导致的掉话，通常有以下表现：1. 首先，在掉话前UE曾发出Measurement Report、并能收到eNB发来的RRCConnectionReconfiguration；2. 但是UE收取目标小区的广播消息之后、立即上报“RRC连接重建立请求”（rrcConnectionReestablishmentRequest; Cause = handoverFailure）；3. 通常UE在切换失败后，都会发起回到源小区的“RRC连接重建立请求”、并且此类RRC连接重建立成功率大部分都是成功的、此类重建立通常也会在100ms内完成。

图0-2 信令（由于切换失败导致的掉话）分析方法采用信令分析法。

步骤1、获取采集到的掉话数据，使用路测数据分析软件OUTUM进行分析；步骤2、打开路测数据的信令，定位到掉话时间点，确认以下几个特征：（1）掉话前UE曾发起Measurement Report消息；（2）UE能够收到eNB发来的带有MobilityControlInfo内容的“RRC连接重配置”消息（3）UE切换到“RRC连接重配置”消息所带的目标小区后、在该小区的BCCH-SCH 上接收到广播消息（systemInformationBlockType1）；（4）UE收完广播消息后、发起“RRC连接重建立（原因为切换失败）”；（5）通常UE能够在较短时间（200ms）内重建立成功、回到切换前的源小区。