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
-70
10
20
-10
Poor
Coverage
分析方法
采用路测数据分析法。

步骤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）内重建立成功、回到切换前的源小区。

步骤3、进一步分析以下内容：
（1）明确MR消息和RRC连接重配置消息中所提及的目标小区的PCI，确认该PCI所指小区；
（2）分析UE在新的目标小区接收到的广播消息，确认该小区是否就是MR消息上报的小区，用以排除邻区错配的情况；
（3）在OMC中确认邻区配置,检查邻区参数是否正确；
（4）确认OMC中的切换类型（X2、S1）；
（5）确认目标小区的工作状态（小区的功率输出、小区负荷）、排除由于目标小区工作异常导致的切换失败；
（6）确认源小区和目标小区的切换参数（门限、TTT和迟滞等）配置与其他正常小区的相同。

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

解决方案
总的来说，解决此类掉话有以下方法：
1. 检查源小区的邻区配置情况，确认邻区参数配置正确；
2. 确认目标小区的工作状态正常（包括传输无误码、功率输出正常、小区负荷不会
导致拒绝切入）
3. 确认源小区和目标小区的软件版本是否正确；
4. 了解切换失败的规律（是否配置了X2？是否集中在某个小区、该小区的切换成功
率是否低？周边是否有新开站点？是否处于不同的MME边缘？是否处于不同频
率的基站交界处？）
当无法定位问题时，需要总结规律、将归纳后的信息反馈给后方技术支持、以便提交系统开发人员作问题的最终定位。

3.3邻区漏配
现象
由于邻区漏配导致的掉话，通常有以下现象：
1.
掉话前、后的下行覆盖不差（通常大于-105dBm ）； 2.
掉话前、后服务小区的SINR 变差（因为受到邻区信号的干扰）； 3. （关键点）掉话前UE （可能会多次）上报测量报告（MR ）、并且MR 中上报的
PCI ，并没有配置在当前服务小区的邻区列表之中；
4. 掉话后UE 通常会发起小区重选、并重选到一个新的小区。

图 0-3 邻区漏配导致的掉话示意图
-130-110
-90
-70
10
20
-10
Missing
Neighbor
分析方法
采用信令分析法。

步骤1、获取采集到的掉话数据，使用路测数据分析软件OUTUM 进行分析； 步骤2、打开路测数据的信令，定位到掉话时间点，确认以下几个特征：
（1） 掉话前服务小区的RSRP 持续下降；
（2）掉话前，UE（连续）上报MR消息；（目的是：确认邻区信号足够强、是
由于邻区漏配导致的服务小区信号变差、最终导致掉话）
（3）MR消息中UE上报有符合A3（或者A5，取决于系统设置）事件的目标邻
区；
（4）在当前服务小区下发的系统（邻区）消息中，并没有包含MR消息中UE
上报的目标邻区；
（5）UE上报MR后，没有收到eNB发来的用于指示切换的重配置消息。

步骤3、通过基站信息表（或者OMC导出的基站配置表）确认掉话时的主服务小区、MR消息中上报的不在邻区中的PCI归属（即目标小区）；
步骤4、在掉话前的服务小区的邻区列表中添加相应的目标邻区。

解决方案
通过OMC（可以使用界面提供的配置工具、或者批量导入功能），在掉话前的服务小区列表中，添加漏配的邻区。

开启ANR功能，完善邻区配置。

（待验证）
3.4越区覆盖
现象
在支持切换的移动通信网络中，由于无法精确控制无线信号的传播，因此或多或少都会存在越区覆盖的情况。

而由于越区覆盖导致的掉话，通常表现为：
1. 越区覆盖导致“导频污染”：由于越区覆盖的信号较多，导致在某些区域形成“导
频污染”——在覆盖区内，没有稳定的强信号作为主服务小区。

服务小区信号的
频繁变化，是导致掉话的一个主要原因。

2. 越区覆盖对主服务小区的干扰（包括邻区漏配、越区信号的迅速变化等）：在某
些区域，主服务小区受到越区信号的干扰、最终导致掉话。

一方面是由于越区信
号的出现，超出了网络规划设计的预期，初始设计的邻区列表没有加上越区覆盖
的小区；另一方面，在某些区域，越区覆盖的小区信号并不稳定，即使配置了邻
区，也可能会出现由于越区信号的不稳定而无法及时加入邻区的情况。

图 0-4 越区覆盖造成导频污染、并导致掉话示意图 -130
-110-90-7001020-10
Overshooting (Pilot Pollution)
分析方法
路测数据分析法。

步骤1、获取采集到的掉话数据，使用路测数据分析软件OUTUM 进行分析； 步骤2、打开路测数据的信令，定位到掉话时间点，确认以下特征：
（1） 发生掉话的区域，服务小区或者搜索到的邻区信号中有越区覆盖信号（跨
越3“层”或以上的小区）
（2） 判定掉话区域是否为“导频污染区”（覆盖该区域、RSRP > -110dBm 的
小区个数超过3个，通常信号的SINR < 0dB ）
（3） 判定是否存在邻区漏配：检查覆盖该区域的小区邻区列表、是否包含了越
区覆盖的小区
步骤3、确认了存在越区覆盖、以及越区覆盖的具体影响之后，进一步明确覆盖掉话区域的主服务小区、并通过RF 优化、邻区优化等手段，控制越区覆盖信号。

解决方案
1.
越区覆盖的一般优化原则是：在区域中已有合理的稳定信号覆盖的情况下、尽可能地控制越区覆盖的信号： （1） 下调越区覆盖信号的功率 （2） 增加越区覆盖扇区的天线下倾角
（3）在考虑了越区覆盖扇区周边的覆盖情况、以及网络拓扑结构的情况下，谨
慎地调整越区覆盖扇区的天线方位角
2. 如果越区覆盖导致了导频污染，根据网络拓扑结构和相关无线环境来确定最适合
覆盖该区域的扇区、并加强它的覆盖：
（1）上调主覆盖扇区的功率
（2）调整主覆盖扇区的天线下倾角
（3）调整主覆盖扇区的天线方位角
（4）控制其他污染信号对该地区的覆盖
3. 如果越区覆盖未导致导频污染、只是由于邻区漏配而导致掉话，则只需要在掉话
区域相关小区的邻区列表中添加越区覆盖小区即可。

3.5系统设备异常
现象
此类问题的表象不一，总的来说，在确认系统的功率、切换、业务相关参数无误、并排除了无线环境（信号）的影响之后，掉话问题依旧存在，这时可以将问题考虑为
系统设备（可能是硬件或软件）异常。

1. 切换流程异常（在切换区、无法正常完成切换、而导致掉话）
2. 在业务进行到相对固定的一段时间内、发生掉话（并且可复现）
3. 在特定某（几）个扇区、eNodeB下，发生可复现的掉话
4. 跨MME、或者跨TA等，在特殊区域进行业务时，发生可复现的掉话
分析方法
路测数据和OMC统计数据结合分析法。

步骤1、采集掉话区域的路测数据和OMC性能统计数据；
步骤2、分析发生掉话前后的数据，包括：
（1）当时的无线环境（可借助Google Earth来查看）（确定不是由于建筑物阻
挡、拐角等环境因素导致的弱覆盖、快衰落、阴影衰落等）
（2）当时主服务小区和邻区的RSRP、SINR（确认当时的信号覆盖情况）
（3）邻区配置情况（确认邻区都已配置）
（4）小区对的切换、掉话次数统计（确认该扇区的切换是否都失败、掉话率是
否偏高）
（5）掉话时，业务停留在什么地方（例如：在切换过程中掉话、需要确认切换
流程进行到哪个步骤了）
步骤3、排除掉话原因（无线环境、无线弱覆盖和导频污染、邻区漏配等）之后，需要进一步查找掉话的规律性，包括查看：
（1）掉话是否集中在某（几）个有规律（新开站点、跨MME的边界站点等特征）
的扇区、eNodeB？
（2）掉话是否集中在某种类型的切换上（例如经由X2口的切换）？
（3）掉话是否在某次版本升级之后？
解决方案
问题原因定位为系统设备异常之后，需要将问题转交系统开发工程师、并配合抓取进一步分析问题所需的数据、跟踪问题的进展并最终验证该问题得到妥善解决。

3.6干扰
现象
根据干扰的来源、种类、工作频段等特性，我们可以将干扰分为：
（1）外部干扰、内部干扰
（2）带外干扰、带内干扰
（3）窄带干扰、宽带干扰
（4）长时干扰、瞬时干扰
（5）上行干扰、下行干扰
由于干扰分类依据较多，为了便于识别，本文着重从上、下行干扰的角度进行分析。

系统中存在干扰，会有以下表象：
1. 上行干扰：当只有上行链路受到干扰的时候，可能下行链路并无异常表现；当上
行链路受到干扰的时候，UE的发射功率通常较高（接近UE最大发射功率）、而
且基站侧测得的RSSI偏高
2. 下行干扰：当只有下行链路受到干扰时，可能上行链路并无异常表现；当下行链
路受到干扰的时候，UE测得的RSRP较好、但是SINR偏差。

图 0-5 上行干扰导致掉话示意图
-130
-110-90
-7001020-10
Interference (Uplink)
图 0-6 下行干扰导致掉话示意图
-130
-110-90-70
010
20-10
Interference (Downlink)
分析方法
路测数据+OMC 动态数据分析法。

步骤1、采集掉话时的路测数据、后台动态观察（RSSI ）数据。

步骤2、判断掉话时的数据特征：
（1）基站侧测得的RSSI是否偏高（如：-85dBm以上），如果偏高，说明存在上行干扰；
（2）如果掉话前（几秒内）UE发射功率维持在较高水平（> 20dBm）、而此时并非弱覆盖区域，则说明存在上行干扰；
（3）如果UE测得的服务小区（甚至包括邻区）的RSRP较好（-90dBm甚至更好）、而此时的SINR较差（< 0dB），则说明此时可能存在下行干扰。

步骤3、定位了干扰的大致类型，采取相应的解决办法进行处理。

解决方案
1. 对于上行干扰的进一步确认和排查：
（1）明确干扰所涉及的范围（看路测数据,明确有哪些小区存在此类现象、查看这些小区是否成片分布）、大致定位干扰区域
（2）使用频谱扫描仪（如YBT250等）+八木天线进行扫频、以便进一步定位干扰源
2. 对于下行干扰的进一步确认和排查：
（1）首先确认下行干扰并非系统内部干扰（需要排除越区覆盖、邻区漏配导致的“干扰”现象）
（2）明确了是干扰源来自系统外，需要进一步使用频谱扫描仪+八木天线进行扫频、以定位具体的干扰源。

3. 当确认存在有干扰的情况时，可以采取以下方法进行清除或规避：
（1）确认干扰源、请客户帮忙协调清除干扰源
（2）如果干扰来自其他系统，需要增加我方和其他系统的天线隔离度（水平隔离、垂直隔离度）、或者在干扰源上加装信号屏蔽装置防止信号泄漏带来的干扰
（3）变更我方系统的工作频点或者带宽、避开干扰
（4）开启ICIC功能、并优化相关参数（待验证）
3.7拥塞
现象
当系统资源不足、而用户数较多时，容易出现拥塞，现象包括：
1. 小区实时激活用户数较多
2. 小区开始出现接纳拒绝
3. 小区的发射功率接近饱和
4. 小区的呼叫建立成功率、掉话率指标恶化
分析方法
OMC性能统计数据分析法。

步骤1、采集忙时OMC性能统计数据（包括呼叫、切换和释放数据）；
步骤2、查看掉话时小区的用户数、话务量等情况，确认小区处于高负荷状态；
步骤3、查看小区的呼叫建立成功率、切换成功率和掉话率、以及相应的失败原因；
步骤4、当出现由于小区资源不足而导致接纳拒绝的情况时，可以判定为系统出现拥塞。

解决方案
解决拥塞的方法，从两个大方面入手：
1. 增加系统容量
（1）增加小区功率容量
（2）压缩开销信道的功率、RB资源
（3）功率控制（分配）相关参数的优化
（4）增加基站、扇区、频点（带宽）
2. 改变网络拓扑结构、均衡话务负荷
（1）对于出现功率过载的小区，可以考虑适当收缩覆盖（增大天线下倾角、减小扇区发射功率），使得基站只服务距离较近的用户、减小单用户下行功率开支（2）改善话务热点的拓扑结构（调整扇区天线方位角），
3. 开启SON-CCO功能、及优化相关参数（待实现）
4话务统计掉话数据分析
4.1掉话相关的KPI
1. RRC连接异常掉话率
= RRC连接异常释放次数/ RRC连接建立成功次数X 100%
2. E-RAB掉话率
= E-RAB异常释放次数/ E-RAB建立成功次数X 100%
3. E-RAB掉话率（按QCI统计）
= E-RAB异常释放次数（按QCI统计，QCI 1-9）/ E-RAB建立成功次数（按QCI统计，QCI 1-9）X 100%
4. 激活E-RAB掉话率
= 激活E-RAB异常释放次数/ E-RAB建立成功次数X 100%
4.2全局掉话率偏高问题分析（Top N）
现象
全局（整网）掉话率偏高，通常会在网络建设初期、或者网络重大操作（割接、拆分、升级）期间出现，表现如下：
1. 全局（大面积基站、小区）掉话率偏高
2. 往往会伴随全局（大面积基站、小区）的切换成功率和呼叫建立成功率偏低
分析方法
全局掉话率指标偏高的问题定位，通常可以通过OMC统计指标来找到一些规律，可能的原因有：
1. 全网覆盖受限、或者存在大量越区覆盖的情况
2. 全网邻区漏配、错配情况严重
3. 全网切换参数（包括切换门限、迟滞、TTT、层三滤波系数等）配置有误
4. X2口配置有误（X2口切换失败率偏高）
5. 系统中存在干扰
6. 与其他设备商的业务区交界
7. 系统版本有故障
8. 某些时段用户数少、OMC性能数据不具备统计意义
在具体分析的时候，通常采取OMC性能统计数据分析法。

步骤1、采集OMC在一段时间（含系统忙时）内的切换、掉话、呼叫统计数据；
步骤２、分析系统忙时的掉话率指标、找出掉话率排名Top N的小区；
步骤3、将掉话率Top N小区进行分簇，按照本小节、0小节的内容进行分析。

解决方案
针对上述不同原因，采取相应的解决办法：
1. 覆盖相关：具体优化手段见0、0小节。

2. 邻区及切换参数相关：具体优化手段见0、0小节。

3. 系统相关：具体优化手段见0小节。

4. 干扰相关；具体优化手段见0小节。

5. 如果是存在与其他设备商的业务区有交界的情况，可以考虑控制覆盖、规避干扰的办
法，具体优化手段见0、0小节。

4.3小区（簇）掉话率偏高问题分析
现象
在一个成熟、稳定的网络中，通常不再出现全局大面积掉话率偏高的情况，只有个别（簇）扇区、基站的掉话率偏高（Top N小区），表现为：
1. 个别扇区、基站（簇）掉话率偏高
2. 问题基站与周边基站的切换成功率偏低（往往表现为单向切换成功率偏低）
分析方法
OMC性能统计数据分析法。

除了第3章、以及0小节提到掉话原因，具体到小区（簇）掉话分析时，还需要查看Top N 小区（基站）的以下特征（的规律性）：
1. 掉话率偏高的小区（基站）是否新开站点？或该小区（基站）周边有新开站点？（需
要检查该站及周边站点的邻区、切换参数）
2. 掉话率偏高的基站工作是否正常？（有无告警、功率输出是否正常、基站运行的软件
版本是否正确？）
3. 掉话率偏高的扇区，天馈系统是否正常？（天线有无接反？有无驻波比告警？天线的
增益、方位角和俯仰角是否与规划、实际地形相符？）
4. 掉话率偏高的基站，周边的无线环境如何？（有无阻挡、拐角、干扰？）
5. 掉话率偏高的小区，切换、功控等参数是否正确？
6. 掉话率偏高的小区资源是否足够？
解决方案
同0小节提到的解决方案。

5掉话问题的分析流程
根据前面所述的掉话问题分析过程、提取出一套掉话问题分析思路，具体流程如下图所示。

图0-1 掉话问题分析流程图
6典型掉话案例分析
6.1弱覆盖导致的掉话
以某项目为例，在2011年上半年的簇优化测试中，有超过60%的掉话是由于弱覆盖导致的。

案例1、由于弱覆盖导致的掉话
图0-1 案例1、弱覆盖导致的掉话
从路测数据可以看出，掉话时，UE接收到的RSRP < -120dBm、Serving Cell SINR < -2dB，这就是典型的弱覆盖。

6.2切换失败导致的掉话
在网络建设初期，在覆盖良好的情况下，不应出现切换失败的情况；如果出现了切换失败（上报原因值为Handover Failure），可能是跟系统版本有关、也可能与切换参数设置不合理有关。

在某项目中，由于微波对LTE系统的干扰、有部分站点的工作带宽被设置为10MHz，而其他正常小区设置为15MHz。

当UE跨越15MHz和10MHz小区的边界时，由于当时系统尚不支持异频切换，因此目前10MHz小区和15MHz小区之间的相互切换是失败的、会产生掉话。