WCDMARNOCS业务优化掉话问题分析.docx
《WCDMARNOCS业务优化掉话问题分析.docx》由会员分享，可在线阅读，更多相关《WCDMARNOCS业务优化掉话问题分析.docx（64页珍藏版）》请在冰豆网上搜索。
WCDMARNOCS业务优化掉话问题分析
WCDMARNOCS业务优化_掉话问题分析
1掉话分类定义2
1.1路测掉话定义2
1.2话务统计指标2
2掉话分析流程及方法5
2.1常见掉话原因5
2.1.1邻区漏配5
2.1.2覆盖差6
2.1.3切换导致的掉话8
2.1.4干扰导致的掉话9
2.1.5流程交互失败10
2.1.6异常分析10
2.2路测数据分析流程10
2.3话务统计数据分析流程13
2.4跟踪数据分析流程17
2.5告警数据分析流程20
2.6用户投诉分析流程20
2.7调整措施21
2.7.1工程参数21
2.7.2小区参数22
3典型掉话分析28
3.1邻区漏配28
3.1.1现象和分析28
3.1.2解决方法30
3.2覆盖太差30
3.2.1现象和分析30
3.2.2解决办法31
3.3干扰过强31
3.3.1导频污染31
3.3.2上行干扰导致的掉话39
3.4软切换掉话41
3.4.1拐角效应41
3.4.2针尖效应44
3.4.3主导小区变化过快45
3.5硬切换掉话46
3.5.1压缩模式启动太迟46
3.6系统间切换掉话46
3.6.1邻区漏配导致掉话46
3.6.2异系统邻区配置过多导致掉话47
3.6.3LAC配置错误导致的掉话48
3.6.4UE不报测量报告导致掉话48
3.6.5切换不及时导致掉话49
3.6.6物理信道重配置时发生最优小区变更导致掉话52
3.6.7UE回切换失败导致掉话53
3.6.8压缩模式启动太迟54
3.7设备异常掉话54
3.7.1NodeB上行同步导致的掉话55
3.7.2手机问题55
4网优各阶段关注点56
4.1单站测试阶段56
4.2优化前评估阶段56
4.3RF优化阶段56
4.4参数优化阶段56
4.5网优项目验收阶段57
5附录58
5.1覆盖增强技术58
5.1.1塔放58
5.1.2收发分集58
5.1.3RRU58
5.1.4微蜂窝58
1掉话分类定义
1.1路测掉话定义
从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息，满足以下三个条件的任何一个：
1）收到任何的BCH消息（即系统消息）
2）收到RRCRelease消息且释放的原因值为NotNormal
3）收到CCDisconnect，CCReleaseComplete，CCRelease三条消息中的任何一条，而且释放的原因为NotNormalClearing或者NotNormal，Unspecified。
1.2话务统计指标
广义的掉话率应该包含CN和UTRAN的掉话率，由于网优重点关注与UTRAN侧的掉话率指标，本文掉话率描述也重点关注UTRAN侧的KPI指标分析。
UTRAN侧相关指标就是RNC触发释放的各业务RAB个数。
主要包括两个方面：
（1）业务建立成功后，RNC向CN发送RABRELEASEREQUEST消息。
（2）业务建立成功后，RNC向CN发送IURELEASEREQUEST消息，其后收到CN发送的IURELEASECOMMAND。
目前这两种情况用一个指标统计：
RNC_RAB_REL_TRIG_BY_RNC，统计时可按具体业务分类统计。
同时话务统计还统计了RNC触发释放各业务RAB的原因。
掉话率计算：
从大的方面来讲，掉话分为两大类，信令面掉话和用户面掉话；从流程上看，信令面掉话是RNC发起了Iureleaserequest，用户面掉话是RNC主动发起RABreleaserequest。
这两项指标是针对CS和PS分别统计的，根据IU接口的话务统计统计项，定义信令面掉话如下：
用户面掉话可以直接通过RNC掉话率和信令面掉话率相关指标运算得到。
信令面和用户面掉话仅从信令角度区分。
建议话务统计分析时重点关注整个掉话率，重点分析掉话的原因，目前有以下掉话原因统计项：
RNC_PS_RAB_REL_TRIG_BY_RNC_TRB_RESET
RAB_CS_REL_RF_LOSS
RAB_PS_REL_RF_LOSS
RNC_CS_RAB_REL_TRIG_BY_RNC_SRB_RESET
RNC_PS_RAB_REL_TRIG_BY_RNC_SRB_RESET
RNC_CS_RAB_REL_TRIG_BY_RNC_AAL2_LOSS
RNC_PS_RAB_REL_TRIG_BY_RNC_GTPU_LOSS
RAB_CS_REL_ABNORM_LOSS
RAB_PS_REL_ABNORM_LOSS
其中出现最多的为SRB、TRB复位。
上述这些指标可以按照表格分类：
掉话分类
引起原因
对应的信令过程
相关指标
空口原因
RF
RLC复位，RLFailure
SRB_RESET，TRBRESET
RF_LOSS
流程定时器超时
RBSETUP/RECFG
PHY/TRCH/SHO/ASU等过程超时
HHO过程失败
各流程超时统计相关指标
非空口原因
硬件故障
RNC和NODEB之间的传输故障，NCP上报故障
FP同步失败
ABNORM_LOSS
传输层故障
ALCAP上报故障
ABNORM_LOSS
通过MML强行释放用户
O&Mintervention
ABNORM_LOSS
从上述分类看出，话务统计指标目前没有完全按照通常网络优化的掉话原因分类进行统计。
需要说明的是RAN话务统计掉话的定义只从Iu接口的角度进行统计，统计了RNC主动发起的RABrelease请求次数和Iurelease请求次数。
而路测掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致的。
比如说，对于同时进行主被叫通话，工具记录主叫的空口消息，如果被叫异常掉话，那么分析主叫的流程也会是一次掉话，但从话务统计上看，这次主叫是没有掉话指标记录的。
所以两者的定义是不完全一致的，在分析时要注意区分。
2掉话分析流程及方法
2.1常见掉话原因
2.1.1邻区漏配
一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。
对于同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：
方法一：
观察掉话前UE记录的激活集EcIo信息和Scanner记录的BestServerEcIo信息，如果UE记录的EcIo很差，而Scanner记录的BestServerEcIo很好；同时检查Scanner记录BestServer扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中，如果测量控制的邻区列表中中没有扰码，那么可以确认是邻区漏配。
方法二：
如果掉话后UE马上重新接入，如果UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。
方法三：
有些UE会上报检测集（DetectedSet）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。
邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。
异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。
异系统邻区漏配表现为手机在3G掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好（在掉话点用2G测试手机观察RSSI信号）。
邻区优化包括邻区增加和邻区删除两种情况。
漏配邻区的影响是强的小区不能加入激活集导致干扰加大甚至掉话，这时需要增加必要的邻区；冗余邻区的影响是使邻区消息庞大，增加不必要的信令开销，而且在邻区满配时无法加入需要的邻区，这时需要删除冗余邻区。
在RF优化阶段，主要关注邻区漏配的情况.
1AThreshold：
1A事件门限，建议设置为3dB；
1AHysteresis：
1A事件迟滞，建议设置为0dB；
1ATimetoTrigger：
1A时间出发时延，建议设置为0.320s；
1BThreshold：
！
B事件门限，建议设置为6dB；
1BHysteresis：
1B事件迟滞，建议设置为0dB；
1CHysteresis：
1C事件迟滞，建议设置为4dB；
1DHysteresis：
1D事件迟滞，建议设置为4dB；
CountThreshold：
邻区判断次数门限，建议设置为10次
协议规定WCDMA的邻区个数最大为32个，包括同邻频＆异系统之间的.优化中发现的需要添加的必要邻区就无法加入，这时需要删除部分冗余邻区.
2.1.2覆盖差
弱覆盖指的是覆盖区域导频信号的RSCP小于－95dBm。
比如凹地、山坡背面、电梯井、隧道、地下车库或地下室、高大建筑物内部等。
如果导频信号低于全覆盖业务（例如：
VP、PS64K）的最低要求，或者刚能满足要求，但由于同频干扰的增加，导频信道Ec/Io不能满足全覆盖业务的最低要求，将导致全覆盖业务接入困难、掉话等问题；如果导频信号RSCP低于手机的最低接入门限的覆盖区域，手机通常无法驻留小区，无法发起位置更新和位置登记而出现“掉网”的情况。
这类问题通常采用以下应对措施：
●可以通过增强导频功率、调整天线方向角和下倾角，增加天线挂高，更换更高增益天线等方法来优化覆盖。
●对于相邻基站覆盖区不交叠部分内用户较多或者不交叠部分较大时，应新建基站，或增加周边基站的覆盖范围，使两基站覆盖交叠深度加大，保证一定大小的软切换区域，同时要注意覆盖范围增大后可能带来的同邻频干扰；
●对于凹地、山坡背面等引起的弱覆盖区可用新增基站或RRU，以延伸覆盖范围；
对于电梯井、隧道、地下车库或地下室、高大建筑物内部的信号盲区可以利用RRU、室内分布系统、泄漏电缆、定向天线等方案来解决。
一般来说，对于AMR业务而言，当CPICH的EcIo大于-14dB，RSCP大于-100dBm时（采用Scanner的测量值），不可能是由于覆盖不行导致的掉话。
通常所说的覆盖差，主要是指RSCP很差。
下表是规划时要求的OutdoorEcIo和Ec要求（来自国外某网络规划）：
表1EcIo和Ec门限要求
Service
Bitrateofservice
DLEbNo
P_TCH-P_CPICH
EcIothresholds
Ecthresholds
CS12.2
12.2
8.7
-3
-13.3
-103.1
CS64
64
5.9
0
-11.9
-97.8
PS64
64
5.1
0
-12.7
-98.1
PS128
128
4.5
3
-13.3
-95.3
PS384
384
4.6
5
-10.4
-90.6
上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：
如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RLfailure，基本可以认为上行覆盖差导致的掉话；如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是下行覆盖不行导致的掉话。
在合理的链路平衡情况下，而且上下行没有干扰的情况下，上行和下行发射功率会同时受限，此时不一定要严格区分哪一方先出现受限。
如果上下行严重不平衡，则应该初步判定为受限方向存在干扰。
越区覆盖一般是指某些基站的覆盖区域超过了规划的范围，在其他基站的覆盖区域内形成不连续的主导区域。
比如，某些大大超过周围建筑物平均高度的站点，发射信号沿丘陵地形或道路可以传播很远，在其他基站的覆盖区域内形成了主导覆盖，产生孤岛效应。
因此，当呼叫接入到远离某基站而仍由该基站服务的“岛”形区域上，并且在小区切换参数设置时，“岛”周围的小区没有设置为该小区的邻近小区，则一旦当移动台离开该“岛”时，就会立即发生掉话。
而且即便是配置了邻区，由于“岛”的区域过小，也会容易造成切换不及时而掉话。
这类问题通常采用以下应对措施：
●对于越区覆盖情况，就需要尽量避免天线正对道路传播，或利用周边建筑物的遮挡效应，减少越区覆盖，但同时需要注意是否会对其他基站产生同频干扰。
对于高站的情况，比较有效的方法是更换站址，但是通常因为物业、设备安装等条件限制，在周围找不到合适的替换站址。
而且因为极大的调整天线的机械下倾角会造成天线方向图的畸变，所以只能调整导频功率或使用电下倾天线，以减小基站的覆盖范围来消除“岛”效应。
上下行不平衡一般指目标覆盖区域内，上下行对称业务出现下行覆盖良好而上行覆盖受限（表现为UE的发射功率达到最大仍不能满足上行BLER要求）。
或下行覆盖受限（表现为下行专用信道码发射功率达到最大仍不能满足下行BLER要求）的情况。
上下行不平衡的覆盖问题比较容易导致掉话，常见的原因是上行覆盖受限。
确认覆盖的问题简单直接的方式是直接观察Scanner采集的数据，若最好小区的RSCP和EcIo都很低，就可以认为是覆盖问题。
由于缺站、扇区接错、功放故障导致站关闭等原因都会导致覆盖差，在一些室内，由于过大的穿透损耗也会导致覆盖太差，扇区接错或者站点由于故障原因关闭等容易在优化过程中出现，表现为其他小区在掉话点的覆盖差，需要注意分析区别。
2.1.3切换导致的掉话
软切换/同频导致掉话主要有两类原因：
切换来不及或者乒乓切换。
从信令流程上CS业务表现为手机收不到激活集更新命令（同频硬切换时为物理信道重配置），PS业务也有可能收不到激活集更新命令，也有可能在切换之前先发生TRB复位。
从信号上看，切换来不及主要有以下现象：
1）拐角：
源小区EcIo陡降，目标小区EcIo陡升（即突然出现就是很高的值）；
2）针尖：
源小区EcIo快速下降后一段时间后上升，目标小区出现短时间的陡升。
从信令流程上看，一般在掉话前手机上报了邻区的1a或者1c测量报告，RNC也收到了测量报告，并下发了激活集更新消息，但UE收不到激活集更新消息。
乒乓切换主要有以下两种现象：
这类区域是指没有主导小区或者主导小区更换过于频繁的地区。
这样会导致频繁切换，进而降低系统效率，增加了掉话的可能性。
针对无主导小区的区域，应当通过调整天线下倾角和方向角等方法，增强某一强信号小区（或近距离小区）的覆盖，削弱其他弱信号小区（或远距离小区）的覆盖
1）主导小区变化快：
2个或者多个小区交替成为主导小区，主导小区具有较好的RSCP和EcIo每个小区成为主导小区的时间很短；
2）无主导小区：
存在多个小区，RSCP正常而且相互之间差别不大，每个小区的EcIo都很差。
从信令流程上看，一般可以看到1个小区刚刚删除，然后马上要求加入，此时收不到RNC下发的激活集更新命令导致失败。
解决切换来不及导致的掉话，可以通过调整天线扩大切换区，也可以配置1a事件的切换参数使切换更容易发生，或者配置CIO使目标小区能够提前发生切换；解决乒乓切换带来的掉话问题，可以调整天线使覆盖区域形成主导小区，也可以配置1b事件的切换参数减少乒乓的发生等方法来进行。
对于异频切换和系统间切换，在切换前需要通过启动压缩模式来进行异频或者异系统测量，压缩模式启动太迟，可能导致手机来不及测量目标小区的信号，从而产生掉话，也可能手机完成了测量，但下发的异频或者异系统切换请求手机不能正常接收而导致掉话。
对于3G2G系统间切换掉话的常见原因大概如下：
1.邻区漏配置，可以通过配置邻区解决；
2.信号变化太快导致掉话；
3.手机问题，比如UE回切换失败或者UE没有上报异系统测量报告导致掉话等；
4.物理信道重配置时发生最优小区发生变更导致掉话，需要产品算法进行优化；
5.异系统小区配置过多导致掉话，可以通过优化邻区数目解决；
6.LAC区配置错误导致的掉话，可以通过数据配置检查解决。
2.1.4干扰导致的掉话
下行和上行的干扰都会导致掉话。
一般情况下，对于下行，当激活集CPICHRSCP大于-85dB，而激活集综合EcIo小于-13dB产生了掉话，基本上可以认为是下行干扰的问题（当切换不及时的时候，也可能出现服务小区RSCP信号很好，但EcIo很差；但此时监视集小区RSCP和EcIo都很好）；对于上行RTWP比正常值（-107~-105）超过10dB，干扰时间超过2~3s，就有可能造成掉话，需要重点解决。
下行的干扰通常是指导频污染，指覆盖地区存在3个以上的小区满足切换条件，由于信号的波动常常出现激活集替换或者最优小区发生变化，通常当激活集综合质量不好（CPICH的EcIo都在-10dB左右波动），容易出现切换失败导致SRB复位，也可能出现TRB复位。
上行的干扰增加了连接模式的手机上行发射功率，从而产生过高的BLER导致SRB或者TRB复位或者由于失步导致掉话。
另外，在切换的时候，新建链路由于上行干扰问题导致链路不能同步，从而造成该小区的切换成功率低，或者造成切换失败而导致掉话。
通常在没有干扰的情况下，上下行是平衡的，也就是说掉话前上下行的发射功率都会接近最大值。
但当干扰存在时，如果是下行的干扰，往往出现上行发射功率很小或者BLER收敛的情况，但下行发射功率达到最大值同时也伴随着下行BLER不收敛；对于上行干扰，会存在同样的表现，在实际分析可以通过这个方法来区分。
2.1.5流程交互失败
一些需要信令交互的流程，如AMR控制、DCCC以及压缩模式的启停、UE的状态迁移等，常常会由于信号的原因，手机支持方面的原因或者RAN设备和手机的配合问题，导致流程失败，最后导致掉话。
还有一种特殊情况就是在流程的交互过程中，如RB建立，RB重配置等流程中，切换的测量报告不能及时处理，导致信号变差而掉话。
这类问题需要针对特定的流程和手机进行分析，没有一般性的处理方法。
2.1.6异常分析
在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。
比如：
NodeB异常引起同步失败，导致的链路不停增加和删除
比如：
手机不上报1a测量报告导致掉话
这里需要重点注意的是测试手机异常死机引起的掉话问题，一般在拨测过程中容易出现这个问题，具体表现为路测记录的数据中有一段时间没有手机上报的信息。
1一些手机如MOTOA835会丢失掉话前的一些消息，可能导致后处理软件判断错误，发生这种情况的时候需要对比RNC记录的单用户跟踪来排除问题。
2.2路测数据分析流程
掉话数据分析流程如下：
图2掉话分析流程图
图3掉话分析判决树
1.准备数据
路测软件采集数据文件
RNC记录的单用户跟踪
RNC记录的CALLTRACE
2.获取掉话位置
采用路测数据处理软件，获取掉话的时间和地点，获取掉话前后Scanner采集的导频数据，手机采集的激活集和监视集信息，信令流程等。
3.分析Scanner主导小区变化情况
主要分析主导小区的变坏情况，如果主导小区相对稳定，进一步分析RSCP和EcIo情况；
如果主导小区变化频繁，需要区分主导小区变化快的情况，或者没有主导小区的情况，然后进一步进行乒乓切换掉话分析。
4.分析Scanner主导小区信号RSCP和EcIo
观察Scanner最好小区RSCP，EcIo，根据不同的情况分别处理
4.1RSCP差，EcIo差，可以确定为覆盖问题；
4.2RSCP正常，EcIo差（排除切换来不及导致的，同频邻区干扰），可以确定为导频干扰问题；
4.3RSCP正常，EcIo正常，如果UE激活集中小区与Scanner最好小区不一致，可能为邻区漏配或者切换来不及导致的掉话；如果UE激活集中小区与Scanner最好小区一致,可能为上行干扰或者异常掉话。
5.路测重现问题
由于一次路测不一定能够采集到定位掉话问题需要的所有信息，此时需要通过进一步路测来收集数据。
通过进一步的路测也能确认该掉话点是随机掉话的点或者固定掉话点，一般来说固定掉话点一定需要解决，而随机掉话点则需要根据掉话发生的概率来确定是否需要解决。
2.3话务统计数据分析流程
分析话务统计指标时，要先看RNC掉话率指标和信令面掉话率指标，掌握了网络运行的整体情况。
同时对关注的小区（小区集合）针对性地分析，按小区（小区集合）得到更详细的掉话指标。
分析时可使用话务统计分析工具得到不同业务的掉话情况以及大致的掉话原因。
话务统计分析应获得指标明显异常的小区分析，如果小区以前KPI良好，此时很可能是版本、硬件、传输、天馈或者数据出了问题导致的异常，可以结合告警首先从这几个方面检查。
如无明显异常，根据指标将各扇区载频进行统计分类，可整理出各重点指标较差小区列表，对于这些小区进一步细分话务统计指标（如分析更多相关指标，分析小时间间隔，分析可能引起掉话的指标，如切换指标等等），同时结合calltrace看掉话的原因。
实际分析解决问题时，在重点抓住某个指标分析的同时需要结合其他指标一起分析。
需要说明的是话务统计只有在统计量较大时，指标数值才具有指导意义。
例如，出现掉话率为50%并不就代表网络差，只有在呼叫次数、呼叫成功次数、掉话总次数的绝对值都已具备统计意义时，这个数值才具有意义
话务统计分析流程可以简述如下：
1.分析RNC掉话率和信令面掉话率
RNC掉话率统计RNC触发释放的各业务RAB个数，主要包括两个方面：
（1）业务建立成功后，RNC向CN发送RABRELEASEREQUEST消息。
（2）业务建立成功后，RNC向CN发送IURELEASEREQUEST消息，其后收到CN发送的IURELEASECOMMAND。
目前这两种情况用一个指标统计：
RNC_RAB_REL_TRIG_BY_RNC。
信令面掉话主要是RNC发起了IuReleaseRequest。
分析IU口连接释放情况得到信令面掉话率。
2.分析掉话原因
在话务统计分析中还分析引起掉话的主要原因，可分析以下主要指标：
RNC_PS_RAB_REL_TRIG_BY_RNC_TRB_RESET
RAB_CS_REL_RF_LOSS
RAB_PS_REL_RF_LOSS
RNC_CS_RAB_REL_TRIG_BY_RNC_SRB_RESET
RNC_PS_RAB_REL_TRIG_BY_RNC_SRB_RESET
RNC_CS_RAB_REL_TRIG_BY_RNC_AAL2_LOSS
RNC_PS_RAB_REL_TRIG_BY_RNC_GTPU_LOSS
RAB_CS_REL_ABNORM_LOSS
RAB_PS_REL_ABNORM_LOSS
可以将这些指标按照2.2节分类，将其分为空口原因（RF、流程超时）、非空口原因（硬件故障、传输故障、用户干预等），从而对网络有个总体把握，得到影响网络的主要因素。
3.分析小区（小区集合）的掉话率指标
上述只是对整个网络分析，我们可分析小区掉话率指标，主要需要分析小区“AMR掉话率”、“VP掉话率”、“PS掉话率”、“硬切换掉话率”。
对所有小区分别用以上的指标进行排序，选择指标特别差的小区或者最差的一些小区，进一步按照分析掉话原因。
AMR掉话率:
RNC_AMR_RAB_REL_CELL_TRIG_BY_RNC
升级会员 