TDSCDMA 掉话问题分析.docx
《TDSCDMA 掉话问题分析.docx》由会员分享,可在线阅读,更多相关《TDSCDMA 掉话问题分析.docx(17页珍藏版)》请在冰豆网上搜索。
TDSCDMA掉话问题分析
TD-SCDMA掉话问题分析
课程目标:
●掌握掉话的定义
●了解话统指标
●掌握话统数据分析流程
目录
第1章概述1
第2章掉话分类定义3
2.1路测掉话定义3
2.2话统指标3
第3章掉话问题分析流程及案例5
3.1DT/CQT掉话问题分析流程及常见掉话原因分析5
3.1.1常见掉话原因分析6
3.2话统数据分析流程8
3.2.1分析RNC掉话率8
3.2.2分析小区(小区集合)的掉话率指标8
3.2.3检查小区是否异常9
3.2.4分析掉话原因9
3.2.5通过路测重现问题9
3.3典型掉话案例分析9
3.3.1弱覆盖掉话9
3.3.2切换区设置不合理引起的掉话问题12
3.3.3越区覆盖引起的掉话问题解决13
3.3.4混合业务掉话率很高现象16
概述
知识点
概述
掉话率反映了系统业务的通讯保持能力,是用户直接感受的重要性能指标之一。
广义的掉话率应该包含CN和UTRAN的掉话率,由于无线网络优化重点关注UTRAN侧的掉话率指标,本文掉话率描述也重点关注UTRAN侧的掉话及优化方法。
掉话率的统计是建立在一定业务的基础之上的,极少的业务量所统计出的高掉话率,对网络优化是没有意义的;极高的业务量所统计出的掉话率往往是与拥塞有关。
我们优化时关注的应该是话务量处于负载正常的小区。
掉话分类定义
路测掉话定义
从UE侧记录的空口信令上看,在通话过程(连接状态下)中,如果空口的消息,满足以下三个条件的任何一个:
A、收到任何的BCH消息(即系统消息)
B、收到RRCRelease消息且释放的原因值为NotNormal
C、收到CCDisconnect,CCReleaseComplete,CCRelease三条消息中的任何一条,而且释放原因为NotNormalClearing或者NotNormal,Unspecified。
话统指标
广义的掉话率应该包含CN和UTRAN的掉话率,由于网优重点关注与UTRAN侧的掉话率指标,本文掉话率描述也重点关注UTRAN侧的KPI指标分析。
UTRAN侧相关指标就是RNC触发释放的各业务RAB个数。
主要包括两个方面:
(1)业务建立成功后,RNC向CN发送RABRELEASEREQUEST消息。
(2)业务建立成功后,RNC向CN发送IURELEASEREQUEST消息,其后收到CN发送的IURELEASECOMMAND。
需要说明的是话统掉话的定义只从Iu接口的角度进行统计,统计了RNC主动发起的RABrelease请求次数和Iurelease请求次数。
而路测掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的,两者不完全一致的。
比如说,对于同时进行主被叫通话,工具记录主叫的空口消息,如果被叫异常掉话,那么分析主叫的流程也会是一次掉话,但从话统上看,这次主叫是没有掉话指标记录的。
所以两者的定义是不完全一致的,在分析时要注意区分。
掉话问题分析流程及案例
知识点
DT掉话分析流程
话统掉话分析流程
常见掉话原因
DT/CQT掉话问题分析流程及常见掉话原因分析
通常DT掉话问题分析流程如下:
图3.11掉话分析流程图
常见掉话原因分析
常见导致掉话的原因有:
邻区漏配
一般来讲,初期优化过程掉话占大多数是由于邻区漏配导致的。
邻区漏配导致的掉话也包括同异频邻区漏配和异系统邻区漏配。
主要是掉话发生的时候,手机没有测量或者上报目标邻区,而手机掉话后重新驻留到目标邻区上。
异系统邻区漏配表现为手机在3G掉话,掉话后手机重新选网驻留到2G网络,从信号质量来看,2G网络的质量很好(在掉话点用2G测试手机观察RSSI信号)。
覆盖差
一般来说,对于Voice而言,当PCCPCH的C/I大于-3dB,RSCP大于-95dBm时,不可能是由于覆盖不行导致的掉话。
通常所说的覆盖差,主要是指RSCP很差。
上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认,需要采用以下的方法来确认:
如果掉话前的上行发射功率达到最大值,并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RLfailure,基本可以认为上行覆盖差导致的掉话;如果掉话前,下行发射功率达到最大值,并且下行的BLER很差,基本可以认为是下行覆盖差导致的掉话。
在合理的链路平衡情况下,而且上下行没有干扰的情况下,上行和下行发射功率会同时受限,此时不一定要严格区分哪一方先出现受限。
如果上下行严重不平衡,则应该初步判定为受限方向存在干扰。
由于缺站、扇区接错、功放故障导致站关闭等原因都会导致覆盖差,在一些室内,由于过大的穿透损耗也会导致覆盖太差。
扇区接错或者站点由于故障原因关闭等容易在优化过程中出现,表现为其他小区在掉话点的覆盖差,需要注意分析区别。
干扰导致的掉话
下行和上行的干扰都会导致掉话。
一般情况下,对于下行,当服务小区PCCPCHRSCP大于-95dBm,而C/I小于-3dB产生了掉话,基本上可以认为是下行干扰的问题(当切换不及时的时候,也可能出现服务小区RSCP信号很好,但C/I很差;对于上行RTWP比正常值(-115dbm)超过10dB,干扰时间超过2~3s,就有可能造成掉话,需要重点解决。
下行的干扰通常是指导频污染,指覆盖地区存在4个以上的小区满足切换条件,由于信号的波动常常出现最优小区发生变化。
上行的干扰增加了连接模式的手机上行发射功率,从而产生过高的BLER导致RB复位或者由于失步导致掉话。
另外,在切换的时候,新建链路由于上行干扰问题导致链路不能同步,造成切换失败而导致掉话。
上行干扰可能来自系统内,也可能来自系统外,绝大部分场景上行干扰来自系统外。
通常在没有干扰的情况下,上下行是平衡的,也就是说掉话前上下行的发射功率都会接近最大值。
当下行干扰存在,往往出现上行发射功率很小或者BLER收敛的情况,但下行发射功率达到最大值同时也伴随着下行BLER不收敛;对于上行干扰,会存在同样的表现,在实际分析可以通过这个方法来区分。
切换导致的掉话
切换导致掉话主要有两类原因:
切换来不及或者乒乓切换。
从信号上看,切换来不及主要有以下现象:
1)拐角:
源小区RSCP陡降,目标小区RSCP陡升(即突然出现就是很高的值);
2)针尖:
源小区RSCP快速下降后一段时间后上升,目标小区出现短时间的陡升。
从信令流程上看,切换来不及一般在掉话前手机上报了邻区的1G或者2A测量报告,RNC也收到了测量报告,并下发了物理信道重配置命令,但UE收不到消息。
乒乓切换主要有以下两种现象:
1)主导小区变化快:
2个或者多个小区交替成为主导小区,主导小区具有较好的RSCP并且每个小区成为主导小区的时间很短;
2)无主导小区:
存在多个小区,RSCP较差而且相互之间差别不大。
解决切换来不及导致的掉话,可以通过调整天线扩大切换区,也可以调整切换参数使切换更容易发生,或者配置CIO使目标小区能够提前发生切换;解决乒乓切换带来的掉话问题,可以调整天线使覆盖区域形成主导小区,也可以调整切换参数减少乒乓的发生等方法来进行。
异常分析
在排除了以上的原因之后,其他的掉话一般需要怀疑设备的问题,需要通过查看设备的日志,告警等进一步来分析掉话原因。
比如:
NodeB异常引起同步失败,导致的链路不停增加和删除
比如:
手机不上报1g,2a测量报告导致掉话
这里需要重点注意的是测试手机异常死机引起的掉话问题,一般在拨测过程中容易出现这个问题,具体表现为路测记录的数据中有一段时间没有手机上报的信息。
由于一次路测不一定能够采集到定位掉话问题需要的所有信息,此时需要通过进一步路测来收集数据。
通过进一步的路测也能确认该掉话点是随机掉话的点或者固定掉话点,一般来说固定掉话点一定需要解决,而随机掉话点则需要根据掉话发生的概率来确定是否需要解决。
话统数据分析流程
分析话统指标时,要先看RNC掉话率指标和信令面掉话率指标,掌握了网络运行的整体情况。
同时对关注的小区(小区集合)针对性地分析,按小区(小区集合)得到更详细的掉话指标。
分析时可使用后台网管得到不同业务的掉话情况以及大致的掉话原因。
话统分析应获得指标明显异常的小区分析,如果小区以前KPI良好,此时很可能是版本、硬件、传输、天馈或者数据出了问题导致的异常,可以结合告警首先从这几个方面检查。
如无明显异常,根据指标将各扇区载频进行统计分类,可整理出各重点指标较差小区列表,对于这些小区进一步细分话统指标(如分析更多相关指标,分析小时间间隔,分析可能引起掉话的指标,如切换指标等等),同时结合CT看掉话的原因。
实际分析解决问题时,在重点抓住某个指标分析的同时需要结合其他指标一起分析。
需要说明的是话统只有在统计量较大时,指标数值才具有指导意义。
例如,出现掉话率为50%并不就代表网络差,只有在呼叫次数、呼叫成功次数、掉话总次数的绝对值都已具备统计意义时,这个数值才具有意义。
话统分析流程可以简述如下:
分析RNC掉话率
RNC掉话率统计RNC触发释放的各业务RAB个数,主要包括两个方面:
(1)业务建立成功后,RNC向CN发送RABRELEASEREQUEST消息。
(2)业务建立成功后,RNC向CN发送IURELEASEREQUEST消息,其后收到CN发送的IURELEASECOMMAND。
分析小区(小区集合)的掉话率指标
上述只是对整个网络分析,我们可分析小区掉话率指标,主要需要分析小区“AMR掉话率”、“VP掉话率”、“PS掉话率”、“不同速率PS掉话率”、“切换成功率”、。
对所有小区分别用以上的指标进行排序,选择指标特别差的小区或者最差的一些小区,进一步按照分析掉话原因。
检查小区是否异常
如果小区以前KPI正常,可检查小区的告警,排除小区异常方面的原因。
分析掉话原因
从后台导出掉话原因数据,主要将其分为空口原因(RF、流程超时)、非空口原因(硬件故障、传输故障、用户干预等),从而对网络有个总体把握,得到影响网络的主要因素。
通过路测重现问题
由于话统给出了趋势,并给出了可能的问题,具体问题的定位和分析还需要结合路测或者针对小区的CT分析来进行。
对于问题小区,一般都需要安排针对小区进行路测,跟踪手机侧和RNC的信令流程进行分析,详细分析方法请参见路测数据分析流程。
典型掉话案例分析
弱覆盖掉话
现象描述:
在京石高速公路进行CS12.2K短呼测试,在下图红圈处发生两次掉话。
图3.31CS12.2K短呼测试掉话点优化前效果
原因分析:
掉话点1的UU口信令如下所示。
图3.32掉话点1UU口信令
掉话点2的UU口信令如下图所示,
图3.33掉话点2UU口信令
从信令图可知,这两个掉话点掉话的原因是radiolinkfailure,即无线链路失败。
此处RSCP值在-95dBm左右,导致掉话发生。
解决方案:
调整北潞园三扇区(6483),方位角由270度调至315度;下倾角由6度调整为3度。
使北潞园三扇(6483)主扇区覆盖高速公路。
调整京虹电联三扇区(6492)、三扇区(6493),下倾角由4度调至2度;PCCPCH发射功率由33.9dBm调至37dBm。
调整韩健鑫豪公司一扇区(6427)、2扇区(6428),PCCPCH发射功率由33.9dBm调至37dBm。
调整后效果图:
图3.34CS12.2K短呼测试掉话点优化后效果图
调整后进行测试,京石高速路呼通正常,无掉话现象发生。
切换区设置不合理引起的掉话问题
现象描述:
在环城南路南段,如图粉色圆圈所标示两处发生掉话。
图3.35掉话地点
第一处:
环城西路和环城南路十字路口,距乌涂1.4km,距凤岗820m,距聚泰纺织800m
第二处:
环城南路上距乌涂800m,距凤岗1km,距聚泰纺织1.4km
无线环境:
环城南路路线笔直,天线视距,地形有明显起伏,周围环境从聚泰到乌涂逐渐由一般城区环境向郊区环境过渡,聚泰纺织和同安乌涂站间距约2.2km。
邻接关系配置:
1521<->1411 ,1411<->3011,3011<->1521
掉话分析:
掉话点有两处:
第一处在十字路口,此处凤岗1扇信号变强,从聚泰纺织1521到凤岗1411进行切换,当刚过路口又可以收到乌涂3011的信号,而凤岗1411由于障碍物阻挡,信号一下子变弱,引起与新小区凤岗1411的失步,导致物理信道重配置失败,同时由于此处有多个邻接关系,在该处起呼,呼通率也不高;第二处在环城南路上距乌涂约800m处,该处是一个明显的上下坡地形,掉话点前后乌涂的信号较好,而掉话点处由于是凹地,乌涂的信号不能到达,而此处可以收到短暂聚泰纺织的信号,此信号不稳定,切换导致掉话。
锁频聚泰纺织1521信号进行测试,路测仪上发现聚泰纺织的2扇的覆盖距离较远,在乌涂站不远处,信号还是较强,需要缩短其覆盖。
解决方法及验证:
针对第一个掉话点:
建议删除1411<->3011的邻接关系,调整凤岗1411的个体偏移,将路口的切换区向上移动,使环城南路上直接由聚泰纺织1521切换到同安乌涂3011,避免出现凤岗1411的信号。
针对第二个掉话点:
增大聚泰纺织1521的下倾角,缩短聚泰纺织的覆盖区,使聚泰纺织和乌涂的切换区向聚泰方向靠近。
调整后环城南路南段覆盖良好,掉话率明显下降。
越区覆盖引起的掉话问题解决
现象描述:
在优化天津TD-SCDMA网塘沽片区过程中,路测时发现从中心北路由南往北行行驶至和广州道交界的十字路口时存在掉话,掉话点如下图所示
图3.36掉话地点
现象分析:
按规划,中心北路的覆盖应该由胜利宾馆1扇区、鸿发花园、广州道3扇区共同承担,但是由于胜利宾馆基站天线挂高比较高(54m),而鸿发花园基站的天线挂高仅为30m,通过分析测试LOG,发现胜利宾馆1扇区(扰码为93)存在明显的越区覆盖,见下图
图3.37路测图
尽管在前期邻区规划时,考虑到了胜利宾馆基站天线挂高比较高的因素,把胜利宾馆1扇区(扰码93)和鸿发花园的1扇区(扰码9)互配了邻区,避免了胜利宾馆1扇区的孤岛效应,但是同时也造成了胜利宾馆1扇区和鸿发花园1扇区的乒乓切换,当UE在十字路口右拐时,由于胜利宾馆1扇区没有和广州道3扇区(扰码45)互配邻小区,UE必须先从胜利宾馆1扇区切回到鸿发花园1扇区,而此时由于UE在拐弯后,受建筑物的阻挡,鸿发花园1扇区的信号衰落很大(差15dB左右),使得UE还来不及从鸿发花园1扇区切换到广州道3扇区就因为与鸿发花园1扇区的无线链路差掉话了,试想如果没有胜利宾馆的越区覆盖,UE早早就应该从鸿发花园1扇区切换到广州道3扇区了,这样也就不会有掉话发生了。
解决方法及验证:
(1)调整胜利宾馆1扇区的下倾角,由2度调整为10度
(2)删去胜利宾馆1扇区和鸿发花园1扇区的邻区关系
(3)调整鸿发花园1扇区和广州道3扇区的时隙优先级为不同,避免同频同时隙切换。
调整后的切换和覆盖图如下
图3.38调整后效果
通过调整,胜利宾馆1扇区的越区覆盖已经解决,中心北路上整个的切换关系也已经理清楚,通过4部UE同时进行切换测试,没有发现掉话现象。
混合业务掉话率很高现象
问题描述:
天津现场反映,目前正按第三方测试方法,进行PS128同时和两部CS12.2进行长保,来计算里程掉话比,发现掉话点比较多,主要是切换掉话,CS掉话而PS不掉。
通过对前后台信令分析发现,CS和PS同时呼叫时被分配在了不同的频点接入。
这种方式是满足现在的DCA算法对频点选择的原则的。
问题分析:
目前的DCA算法在对混合业务接入的载频选择时,有两个方面的考虑,一是尽量避免碎片产生,多个低速率(RU占用少)的用户接入会产生码道碎片,从而导致高速率(RU占用多)的用户无法使用同一个时隙的剩余RU资源。
因此引入了反转载频优先级的策略,即对于RU占用多的业务,从优先级最低的频点接入,而RU占用少的业务,从优先级最高的频点接入。
这样可以有效利用小区的RU资源接入更多的用户。
另一方面,频点的选择也充分考虑了频点呈现的干扰特性,尽量将用户分配在干扰小的频点上。
这两个方面是共同作用的。
产生混合业务掉话严重时,每一个小区三个载频的优先级配置为1/2/3(1为最高优先级)。
例如A小区载频为F7/F8/F9,其中F7为主频点,且优先级最高,A小区的邻区B小区载频为F9/F8/F7,其中F9为主频点,且优先级最高。
当A小区接入CS用户时,根据反转原则,被首先接入了优先级高的F7频点上,而A小区的PS用户,则被接入了优先级低的F9频点上。
当从A小区往B小区切换时,假设PS用户先切换,则PS用户会接入B小区的优先级最低的F7频点,此时PS业务与尚未切换还在A小区里的CS业务是同频的,造成CS业务在切换过程中受到B小区内PS业务的同频干扰,导致掉话。
这就是为什么混合业务以后CS掉话严重的原因。
典型的切换失败的现象就是终端发了测量报告要切换时,由于下行干扰收不到RNC下发的物理信道重配置。
图3.39测试信令
解决方法及验证:
针对这种情况,现场进行了频点优先级的调整。
将每个小区的载频优先级修改为1/1/1,即优先级一样。
此时用户接入时以频点从前到后的顺序来排列优先接入顺序。
同样的例如A小区载频为F7/F8/F9,其中F7为主频点,载频优先级一样,A小区的邻区B小区载频为F9/F8/F7,其中F9为主频点,载频优先级一样。
在A小区CS、PS用户都会接入F7频点,在B小区CS、PS用户都会接入F9频点。
即便PS先切换到B小区,由于主载频是异频的,因此也不会对A小区的CS业务造成下行干扰。
经过修改频点优先级,规避了混合业务导致掉话的现象。