质差小区处理方法

Page 9
常见掉话原因
•
流程交互问题
一些需要信令交互的流程，如AMR控制、DCCC以及压缩模式的启停、UE的状态迁移等，
常常会由于信号的原因，手机支持方面的原因或者RAN设备和手机的配合问题，导致流
程失败，最后导致掉话。 这类问题需要针对特定的流程和手机进行分析，没有一般性的处理方法。
•
其他异常问题
其他RF原因
AAL2链路异常
射频原因，均属于覆盖质量不好
RNC发现IU CS接口AAL2 Path异常，发起了异常释放，可能为传输设备异常，已知问 题有RB建立过程中马上正常释放被话统统计为该原因异常释放
其他原因
异常原因掉话，需结合RNC日志进行分析
掉话问题信令跟踪优化流程
1 获取单用户跟踪 消息
Page 12
路测数据分析流程
4、分析Scanner主导小区信号RSCP和EcIo 观察Scanner最好小区RSCP，EcNo，根据不同的情况分别处理 4.1 RSCP差，EcNo差，可以确定为覆盖问题； 4.2 RSCP正常，EcNo差（排除切换来不及导致的，同频邻区干扰），可以确定为导 频干扰问题； 4.3 RSCP正常，EcNo正常，如果UE活动集中小区与Scanner最好小区不一致，可能 为邻区漏配或者切换来不及导致的掉话；如果UE活动集中小区与Scanner最好小 区一致,可能为上行干扰或责异常掉话。 5、路测重现问题 由于一次路测不一定能够采集到定位掉话问题需要的所有信息，此时需要通过进一 步路测来收集数据。通过进一步的路测也能确认该掉话点是随机掉话的点或者固 定掉话点，一般来说固定掉话点一定需要解决，而随机掉话点则需要根据掉话发 生的概率来确定是否需要解决。
从信号上看，切换来不及主要有以下两种现象： ① ② 拐角：源小区EcIo陡降，目标小区EcNo陡升（即突然出现就是很高的值）； 针尖：源小区EcIo快速下降后一段时间后上升，目标小区出现短时间的陡升。
乒乓切换主要有以下两种现象：
① ② 主导小区变化快：2个或者多个小区交替成为主导小区，主导小区具有较好的 RSCP和EcIo，每个小区成为主导小区的时间很短； 无主导小区：存在多个小区，RSCP正常而且相互之间差别不大，每个小区 的EcIo都很差。
N
5 通过路测重现问题
话统数据分析流程
1、分析RNC的掉话率指标 主要从整个RNC的整体掉话指标上判断掉话率指标是否正常。 2、分析小区的掉话率指标 对于小区的掉话率指标，主要需要分析小区“AMR掉话率”、“PS掉话率”、“ 硬切换掉话率”、“系统间切换掉话率”， 对所有小区分别用以上的指标进行 排序，选择指标特别差的小区或者最差的一些小区，进一步分析掉话原因。 3、检查小区是否异常 检查小区的告警，排除小区异常方面的原因。 4、分析掉话原因 排除Iu口aal2异常导致的掉话问题；分析是否由于信令RLC复位导致的掉话，还是 业务RLC复位导致的掉话；分析该小区相关的切换指标（分析小区的切入成功率 和切出成功率），确认是否由于切换失败导致的掉话；通过分析小区总带宽接 收功率相关话统指标，分析在掉话率高的时段，是否相应的上行干扰指标也很 高，进一步确认上行干扰导致的掉话问题。 5、通过路测重现问题 当通过话统分析无法进一步解决掉话问题的时候，需要针对小区进行路测，跟踪 手机侧和RNC的信令流程进行分析，详细分析方法请参见路测数据分析流程。
Page 3
掉话空中接口定义
在通话过程中，如果空中接口信息满足下面三个条件中的任何一条，可以判断为掉话： 1. 收到任何的BCH消息（即系统消息）
2.
3.
收到非正常释放的RRC Release消息（释放原因不是 “Normal”）
收到CC Disconnect，CC Release Complete，CC Release三条消息中的任何一 条，而且释放原因是非正常释放（CauseCodeCC是“Unspecified”或其它原因， 而不是”Normal Call Clearing”或者”Normal”）
2 获取掉话点信息
3 SRB复位 掉话 N 4 是否TRB 掉话 N
Y
•解决SRB复位掉话
Y
• 解决TRB掉话
Y Y
•解决异常掉话
是否异常掉 N 话
N 掉话问题解 决 N 6 拨测，重现问题
Y
信令跟踪数据分析流程
1、获取单用户跟踪消息 单用户跟踪消息需要事先在RNC或者M2000上进行跟踪，才能记录相应的消息，一般 情况下，根据IMSI进行跟踪记录的消息用来分析掉话问题是足够的。
分析小区掉话原因
失败原因 OM干预 RAB抢占导致的原因 分析思路 操作维护工作导致的掉话 高优先级抢占引起的CS链路释放，这种掉话在负载和资源不足的时候发生，根据发生 的次数确定是否扩容 UTRAN产生的原因 小区中UTRAN产生的原因导致链路异常释放。这种情况一般对应着处理异常，需要通 过CHR进一步分析 上行RLC复位 上行SRB复位引起链路释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切 换区小等情况） 下行RLC复位 下行SRB复位引起链路释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切 换区小等情况） 上行同步失败 上行链路失步引起的异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、 切换区小等情况），导致UE异常关闭发射机或者上行解调失步 下行同步失败 下行链路失步引起的异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、 切换区小等情况），导致UE异常关闭发射机或者上行解调失步 UU口无响应 UE空口无响应系统发出的命令，覆盖不好导致
2、获取掉话点信息 从单用户跟踪消息来看，掉话的定义是RNC主动发起了RAB释放（消息名称为 RANAP_RAB_RELEASE_REQ），或者RNC主动发起IU释放（消息名称为 RANAP_IU_RELEASE_REQ）。前者对应为用户面掉话，后者对应为信令面掉话。 通过查找以上两条消息，就可以获得掉话点的时间，以及掉话前的信令消息，以便 进一步进行分析。
Page 13
掉话问题话统数据分析流程
1 分析RNC面掉话率
2 分析小区的掉话率指标
3 检查小区是 否设备异常 N
Y
3.1 解决设备问题
4分析掉话原因
4.1信令RB复位 或者业务RB复
Y
解决覆盖问题
位导致的掉话
N
4.2 是否切换导 致掉话
Y
解决切换掉话问题
N N
4.3 是否干扰导 致的掉话Y Nhomakorabea解决干扰问题
Page 19
信令跟踪数据分析流程
4、用户面掉话分析

用户面掉话主要是TRB复位，这种情况主要在PS业务上发生，voice和VP业务不会 产生TRB复位。 当活动集中只有一条链路上，会由于RL failure导致RNC发起Iu Release， RL failure是上行失步引起的，但是下行失步会使UE关闭发射机，接着就造成上行失步， 在定位掉话是上行引起释放还是下行引起的时候，需要分析掉话前手机的发射功率 和实时状态监控的下行的码发射功率来区分。 下行覆盖差、下行干扰强或者上行干扰都会导致TRB复位。 有时候数据业务由于重传次数设置不合理，在切换来不及的情况下，TRB比SRB先 产生复位，在分析时要注意区分。
Page 4
异常释放信令流程
正常释放流程
RNC CN RNC Iu Release Request Iu Release Command Iu Release Command Iu Release Complete Iu Release Complete
异常释放流程
CN
正常情况下都是由CN发起Iu口的连接释放 如果出现信令面或用户面异常，RNC会主动发起Iu口释放请求，触发掉话 下列2种情况下RNC发起Iu Release Request被视为正常释放： “User Inactivity”和“UE信令连接释放”
WCDMA质差小区处理方法
掉话问题分析及优化方法 接通率问题分析及优化方法 切换成功率问题分析及优化方法 干扰小区问题分析优化方法 拥塞小区问题分析优化方法
课程内容
第一章 掉话分类定义 第二章 常见掉话原因与掉话处理流程 第三章 掉话问题解决方法 第四章 掉话案例分析

Page 8
常见掉话原因
•
干扰问题
下行干扰
一般情况下，对于下行，当CPICH RSCP大于-85dBm，而EcIo小于-13dB，
容易产生掉话，基本上可以认为是下行干扰的问题。 对于下行，干扰可能是导频污染引起。 上行干扰 对于上行RTWP比正常值（-104~-105）超过10dB，干扰时间超过2~3s，就 有可能造成掉话。
Page 18
信令跟踪数据分析流程
3、信令面掉话分析 信令面掉话表现为手机或者RNC不能收到确认模式传送的信令，产生SRB复位， 导致连接释放。 下行方向一般有这些消息可能导致SRB复位： 测量控制 活动集更新 物理信道重配置 传输信道重配置 RB重配置 3G到2G的切换命令（HANDOVER FROM UTRAN COMMAND） 手机是否收到这些命令需要手机侧的跟踪消息来确认； 上行方向有以下的消息可能导致SRB复位： 测量报告 活动集更新完成 物理信道重配置完成 传输信道重配置完成 RB重配置完成 同样需要RNC侧的跟踪消息来确认是否收到。
在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看 设备的日志，告警等进一步来分析掉话原因。 例如：同步失败导致的链路不停增加和删除。 例如：手机不上报1a测量报告导致掉话。
Page 10
路测数据分析流程
1 准备数据 2 获取掉话 位置和时间 3 分析Scanner主导小区信 号变化
Page 5
常见掉话原因
•
邻区漏配
一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。对于同频邻区，通 常采用以下的办法来确认是否为同频邻区漏配： 方法一：观察掉话前UE记录的激活集EcIo信息和Scanner记录的Best Server EcIo 信息，如果 ① UE记录的EcIo很差，而Scanner记录的Best Server EcIo很好 ② Scanner记录Best Server扰码与UE激活集扰码不一致 ③ 检查出现在掉话前最近的同频测量控制中的邻区列表没有该扰码 那么可以确认是邻区漏配。 方法二：如果掉话后UE重新驻留的小区扰码不在掉话时的激活集扰码中，也可以怀 疑是邻区漏配问题，可以通过测量控制和邻区列表配置进一步进行确认。
主导小区信号 稳定？ 稳定 4 Scanner最优小RSCP 和EcIO
变化频繁
4.1 RSCP差 EcIo差 不一致
4.3 RSCP正常 EcIo正常
4.2 RSCP正常 EcIo差
UE和Scanner 最好小区比较
一致 确认漏配 邻区？ 确认上行 干扰？
N
N
Y
覆盖问题 邻区漏配 切换不及时
Y
上行干扰问题 异常掉话 导频干扰问题 乒乓切换问题
邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。
Page 6
常见掉话原因
•
覆盖问题
通常所说的覆盖差，主要是指RSCP和EcIo都很差。覆盖的问题需要通过掉话前上行或 者下行的专用信道功率来确认，需要采用以下的方法来确认：

如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的 单用户跟踪上看到NodeB上报RL failure，基本可以认为上行覆盖差导致的掉话；
如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是 下行覆盖不行导致的掉话。

确认覆盖的问题简单直接的方式： 直接观察Scanner采集的数据，若最好小区的RSCP和EcNo都很低，就可以认为是覆盖问 题。
Page 7
常见掉话原因
•
切换问题
软切换/同频导致掉话主要分为两类原因：切换来不及或者乒乓切换。 从信令流程上CS业务表现为手机收不到活动集更新命令（同频硬切换时为物理信道重 配置），PS业务有时候会在切换之前先发生TRB复位。
4 重新路测
问题是否解决
Page 11
路测数据分析流程
1、准备数据
路测软件采集数据文件 RNC记录的单用户跟踪 RNC记录的CHR
2、获取掉话位置 采用路测数据处理软件，比如Analyzer和获取掉话的时间和地点，获取掉话前后 Scanner采集的导频数据，手机采集的活动集和监视集信息，信令流程等。 3、分析Scanner主导小区变化情况 主要分析主导小区的变换情况，如果主导小区相对稳定，进一步分析RSCP和 EcIo情况； 如果主导小区变化频繁，需要区分主导小区变化快的情况，或者没有主导小区的 情况，然后进一步进行乒乓切换掉话分析。