质差小区处理方法

WCDMA质差小区处理方法掉话问题分析及优化方法接通率问题分析及优化方法切换成功率问题分析及优化方法干扰小区问题分析优化方法拥塞小区问题分析优化方法Page3课程内容Training.huawei.com第一章掉话分类定义第二章常见掉话原因与掉话处理流程第三章掉话问题解决方法第四章掉话案例分析Page4在通话过程中，如果空中接口信息满足下面三个条件中的任何一条，可以判断为掉话：1.收到任何的BCH消息（即系统消息）2.收到非正常释放的RRCRelease消息（释放原因不是“Normal”）3.收到CCDisconnect，CCReleaseComplete，CCRelease三条消息中的任何一条，而且释放原因是非正常释放（CauseCodeCC是“Unspecified”或其它原因，而不是”NormalCallClearing”或者”Normal”）掉话空中接口定义Page5异常释放信令流程RNCCNIuReleaseRequestIuReleaseCommandIuReleaseComplete正常情况下都是由CN发起Iu口的连接释放如果出现信令面或用户面异常，RNC会主动发起Iu口释放请求，触发掉话下列2种情况下RNC发起IuReleaseRequest被视为正常释放：“UserInactivity”和“UE信令连接释放”RNCCNIuReleaseCommandIuReleaseComplete正常释放流程异常释放流程Page6常见掉话原因•邻区漏配一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。对于同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：方法一：观察掉话前UE记录的激活集EcIo信息和Scanner记录的BestServerEcIo信息，如果①UE记录的EcIo很差，而Scanner记录的BestServerEcIo很好②Scanner记录BestServer扰码与UE激活集扰码不一致③检查出现在掉话前最近的同频测量控制中的邻区列表没有该扰码那么可以确认是邻区漏配。方法二：如果掉话后UE重新驻留的小区扰码不在掉话时的激活集扰码中，也可以怀疑是邻区漏配问题，可以通过测量控制和邻区列表配置进一步进行确认。邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。Page7常见掉话原因•覆盖问题通常所说的覆盖差，主要是指RSCP和EcIo都很差。覆盖的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RLfailure，基本可以认为上行覆盖差导致的掉话；如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是下行覆盖不行导致的掉话。确认覆盖的问题简单直接的方式：直接观察Scanner采集的数据，若最好小区的RSCP和EcNo都很低，就可以认为是覆盖问题。Page8常见掉话原因•切换问题软切换/同频导致掉话主要分为两类原因：切换来不及或者乒乓切换。从信令流程上CS业务表现为手机收不到活动集更新命令（同频硬切换时为物理信道重配置），PS业务有时候会在切换之前先发生TRB复位。从信号上看，切换来不及主要有以下两种现象：①拐角：源小区EcIo陡降，目标小区EcNo陡升（即突然出现就是很高的值）；②针尖：源小区EcIo快速下降后一段时间后上升，目标小区出现短时间的陡升。乒乓切换主要有以下两种现象：①主导小区变化快：2个或者多个小区交替成为主导小区，主导小区具有较好的RSCP和EcIo，每个小区成为主导小区的时间很短；②无主导小区：存在多个小区，RSCP正常而且相互之间差别不大，每个小区的EcIo都很差。Page9常见掉话原因•干扰问题下行干扰一般情况下，对于下行，当CPICHRSCP大于-85dBm，而EcIo小于-13dB，容易产生掉话，基本上可以认为是下行干扰的问题。对于下行，干扰可能是导频污染引起。上行干扰对于上行RTWP比正常值（-104~-105）超过10dB，干扰时间超过2~3s，就有可能造成掉话。Page10常见掉话原因•流程交互问题一些需要信令交互的流程，如AMR控制、DCCC以及压缩模式的启停、UE的状态迁移等，常常会由于信号的原因，手机支持方面的原因或者RAN设备和手机的配合问题，导致流程失败，最后导致掉话。这类问题需要针对特定的流程和手机进行分析，没有一般性的处理方法。在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。例如：同步失败导致的链路不停增加和删除。例如：手机不上报1a测量报告导致掉话。•其他异常问题Page11路测数据分析流程1准备数据UE和Scanner最好小区比较稳定一致N2获取掉话位置和时间3分析Scanner主导小区信号变化4.1RSCP差EcIo差4.2RSCP正常EcIo差4.3RSCP正常EcIo正常邻区漏配上行干扰问题切换不及时确认漏配邻区？覆盖问题异常掉话导频干扰问题不一致确认上行干扰？问题是否解决4重新路测Y主导小区信号稳定？4Scanner最优小RSCP和EcIO乒乓切换问题变化频繁YNPage12路测数据分析流程1、准备数据路测软件采集数据文件RNC记录的单用户跟踪RNC记录的CHR2、获取掉话位置采用路测数据处理软件，比如Analyzer和获取掉话的时间和地点，获取掉话前后Scanner采集的导频数据，手机采集的活动集和监视集信息，信令流程等。3、分析Scanner主导小区变化情况主要分析主导小区的变换情况，如果主导小区相对稳定，进一步分析RSCP和EcIo情况；如果主导小区变化频繁，需要区分主导小区变化快的情况，或者没有主导小区的情况，然后进一步进行乒乓切换掉话分析。Page13路测数据分析流程4、分析Scanner主导小区信号RSCP和EcIo观察Scanner最好小区RSCP，EcNo，根据不同的情况分别处理4.1RSCP差，EcNo差，可以确定为覆盖问题；4.2RSCP正常，EcNo差（排除切换来不及导致的，同频邻区干扰），可以确定为导频干扰问题；4.3RSCP正常，EcNo正常，如果UE活动集中小区与Scanner最好小区不一致，可能为邻区漏配或者切换来不及导致的掉话；如果UE活动集中小区与Scanner最好小区一致,可能为上行干扰或责异常掉话。5、路测重现问题由于一次路测不一定能够采集到定位掉话问题需要的所有信息，此时需要通过进一步路测来收集数据。通过进一步的路测也能确认该掉话点是随机掉话的点或者固定掉话点，一般来说固定掉话点一定需要解决，而随机掉话点则需要根据掉话发生的概率来确定是否需要解决。掉话问题话统数据分析流程2分析小区的掉话率指标1分析RNC面掉话率5通过路测重现问题YNNYNYN3检查小区是否设备异常3.1解决设备问题4分析掉话原因4.1信令RB复位或者业务RB复位导致的掉话4.2是否切换导致掉话4.3是否干扰导致的掉话解决覆盖问题解决切换掉话问题解决干扰问题YN话统数据分析流程1、分析RNC的掉话率指标主要从整个RNC的整体掉话指标上判断掉话率指标是否正常。2、分析小区的掉话率指标对于小区的掉话率指标，主要需要分析小区“AMR掉话率”、“PS掉话率”、“硬切换掉话率”、“系统间切换掉话率”，对所有小区分别用以上的指标进行排序，选择指标特别差的小区或者最差的一些小区，进一步分析掉话原因。3、检查小区是否异常检查小区的告警，排除小区异常方面的原因。4、分析掉话原因排除Iu口aal2异常导致的掉话问题；分析是否由于信令RLC复位导致的掉话，还是业务RLC复位导致的掉话；分析该小区相关的切换指标（分析小区的切入成功率和切出成功率），确认是否由于切换失败导致的掉话；通过分析小区总带宽接收功率相关话统指标，分析在掉话率高的时段，是否相应的上行干扰指标也很高，进一步确认上行干扰导致的掉话问题。5、通过路测重现问题当通过话统分析无法进一步解决掉话问题的时候，需要针对小区进行路测，跟踪手机侧和RNC的信令流程进行分析，详细分析方法请参见路测数据分析流程。分析小区掉话原因失败原因分析思路OM干预操作维护工作导致的掉话RAB抢占导致的原因高优先级抢占引起的CS链路释放，这种掉话在负载和资源不足的时候发生，根据发生的次数确定是否扩容UTRAN产生的原因小区中UTRAN产生的原因导致链路异常释放。这种情况一般对应着处理异常，需要通过CHR进一步分析上行RLC复位上行SRB复位引起链路释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况）下行RLC复位下行SRB复位引起链路释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况）上行同步失败上行链路失步引起的异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况），导致UE异常关闭发射机或者上行解调失步下行同步失败下行链路失步引起的异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况），导致UE异常关闭发射机或者上行解调失步UU口无响应UE空口无响应系统发出的命令，覆盖不好导致其他RF原因射频原因，均属于覆盖质量不好AAL2链路异常RNC发现IUCS接口AAL2Path异常，发起了异常释放，可能为传输设备异常，已知问题有RB建立过程中马上正常释放被话统统计为该原因异常释放其他原因异常原因掉话，需结合RNC日志进行分析掉话问题信令跟踪优化流程1获取单用户跟踪消息2获取掉话点信息3SRB复位掉话6拨测，重现问题YN4是否TRB掉话是否异常掉话•解决SRB复位掉话•解决TRB掉话•解决异常掉话掉话问题解决YYYNNNNYPage18信令跟踪数据分析流程1、获取单用户跟踪消息单用户跟踪消息需要事先在RNC或者M2000上进行跟踪，才能记录相应的消息，一般情况下，根据IMSI进行跟踪记录的消息用来分析掉话问题是足够的。2、获取掉话点信息从单用户跟踪消息来看，掉话的定义是RNC主动发起了RAB释放（消息名称为RANAP_RAB_RELEASE_REQ），或者RNC主动发起IU释放（消息名称为RANAP_IU_RELEASE_REQ）。前者对应为用户面掉话，后者对应为信令面掉话。通过查找以上两条消息，就可以获得掉话点的时间，以及掉话前的信令消息，以便进一步进行分析。Page19信令跟踪数据分析流程3、信令面掉话分析信令面掉话表现为手机或者RNC不能收到确认模式传送的信令，产生SRB复位，导致连接释放。下行方向一般有这些消息可能导致SRB复位：测量控制活动集更新物理信道重配置传输信道重配置RB重配置3G到2G的切换命令（HANDOVERFROMUTRANCOMMAND）手机是否收到这些命令需要手机侧的跟踪消息来确认；上行方向有以下的消息可能导致SRB复位：测量报告活动集更新完成物理信道重配置完成传输信道重配置完成RB重配置完成同样需要RNC侧的跟踪消息来确认是否收到。Page20信令跟踪数据分析流程4、用户面掉话分析用户面掉话主要是TRB复位，这种情况主要在PS业务上发生，voice和VP业务不会产生TRB复位。当活动集中只有一条链路上，会由于RLfailure导致RNC发起IuRelease，RLfailure是上行失步引起的，但是下行失步会使UE关闭发射机，接着就造成上行失步，在定位掉话是上行引起释放还是下行引起的时候，需要分析掉话前手机的发射功率和实时状态监控的下行的码发射功率来区分。下行覆盖差、下行干扰强或者上行干扰都会导致TRB复位。有时候数据业务由于重传次数设置不合理，在切换来不及的情况下，TRB比SRB先产生复位，在分析时要注意区分。Page21信令跟踪数据分析流程5、异常掉话分析异常掉话一般指掉话无法从覆盖、干扰等方面找到原因，也无法根据前面介绍的用户面掉话或者信令面掉话原因来解释，这种掉话往往是设备的异常或者是手机的异常导致的。比如由于传输突然中断导致的掉话、基站设备异常