WCDMA网络TOP小区处理经验总结.doc_第1页
WCDMA网络TOP小区处理经验总结.doc_第2页
WCDMA网络TOP小区处理经验总结.doc_第3页
WCDMA网络TOP小区处理经验总结.doc_第4页
WCDMA网络TOP小区处理经验总结.doc_第5页
免费预览已结束,剩余28页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

重庆联通WCDMA网络Top小区处理经验总结1 概述目前重庆近郊累计收集top小区1298个,累计处理1286个,闭环1131个, top小区闭环情况良好,闭环率达到了87.13%。下面我们对日常优化中处理的top小区经验进行总结,便于后续优化工作的开展。本次统计的top小区类型包括AMR掉话高、CS RAB指派失败、CS异系统切换出成功率低、PS RAB指派失败、PS掉话高、PS异系统切换出成功率低、RRC连接建立成功率低、RTWP异常、电路域RAB建立成功率低、小区拥塞(CE拥塞,IUB拥塞、码资源拥塞和功率拥塞)和异频切换成功率低等。目前全网闭环的top小区类型和数量如下图所示:从上图可以看出, AMR和PS掉话高、CS和PS异系统切换出成功率低、RRC连接建立成功率低等几种情况占了top小区较大的比例。其余的如小区各种资源的拥塞和RTWP异常也占了不少比例,但基本都是基站告警和闪断、直放站影响造成的。2 TOP小区排查手段综述下面给出top小区的排查手段,通过下列方式进行问题排查,最终确定问题所在,然后针对问题根源进行解决。1)查询基站告警,干扰和RTWP,查询是否存在拥塞(如果是系统间切换指标差,也需查询2G侧小区的告警,干扰,拥塞情况和指标)2)查询问题是单个小区问题还是区域性的问题,如果是单小区问题,则转到第3步;如果是区域性的问题,则应该对问题区域的传输数据和核心网数据进行核查,检测传输是否存在故障等。3)核查无线参数,邻区关系和传输配置参数(如果是系统间切换指标差,也需查询配置的2G侧的数据是否有误,2G邻区是否合理,是否存在漏配等。)4)提取关联日志,通过关联日志分析坏小区无线环境的质量和大概与周围哪些小区存在切换关系,再根据这些小区的信号强度和地理位置判断是否存在弱覆盖,导频污染,是否是本小区或者是其他小区越区造成的,是否是单用户造成。另外关联日志中的错误报告也会给出大概的错误原因,但这个只供参考,有时候不是很准确。5)DT测试和信令跟踪。如果经过上面步骤仍然不能确定问题所在,那我们必须进行现场测试和后台的信令跟踪,根据现场的测试情况和后台跟踪的信令进行分析排查。看是否存在阻挡,是否存在各种特殊场景,是否存在快衰等情况。3 各类型TOP小区处理方法及案例3.1 通用问题原因分析本节分析各种对KPI指标影响严重的公共原因。一般严重影响KPI指标的原因有告警、单板故障、干扰及弱覆盖等。其中告警和单板故障均可以从网管处取到数据。下面介绍下干扰和弱覆盖的判别方法:干扰1.RTWP长期数据周期分析法基站的各个小区的RTWP数据以15分钟间隔的粒度储存于RNC的数据库之中,调出后可以利用EXCEL画出各个基站的RTWP长期数据(1-3个月)图。如下图所示:从上图中可以看出RTWP的抬升反映的是本小区的用户的话务量,呈现出明显的昼夜规律、星期规律、节假日规律,并依据此规律初步判断可能的干扰来源,例如:边境地区的GSM900对UMTS900系统造成的RTWP抬升呈现明显的昼夜规律;办公地点的电子设备的干扰呈现明显的朝九晚五规律;商场、餐馆、酒吧、桑拿、KTV等地点的RTWP的抬升情况与其营业时间相吻合,并且与星期、节假日的营业时间规律相吻合;2站点相关性分析法相关性分析法是结合RTWP长期数据分析法的一种常用分析手段。它可用作外部干扰的判断手段以及挑选站点上站的依据。其方法是:将地理位置相近的几个基站的RTWP长期数据图叠加在一起分析,如果基站的RTWP的变化具有相关性,则可说明这些基站可能受到同一个外部干扰源的影响,相关性越强,受到同一个外部干扰的可能性越大。相关性分析主要关注细微、剧烈变化的一致性,因此使用15分钟粒度的RTWP数值来进行比较。相关性分析法可以很快地缩小干扰源的范围,并根据能量的大小确定干扰源的位置,提高干扰源定位的效率,避免重复上站。3地理位置分析法地理位置分析法,就是根据受干扰地点的地理位置特征,初步判断干扰源的来源的一种方法,例如:在深港边境地区面向深圳的扇区RTWP普遍高于背向深圳的扇区的RTWP的站点,其干扰很可能是来自深圳的GSM上行信号;在深港边境地区香港一侧深入到香港内部的地区,某些地势较高的建筑上的站点的RTWP仍很高,其干扰也很可能是来自深圳的GSM上行信号;在装有较多的电视放大器的农村地区,或城市郊区,电视放大器可能成为干扰源;在楼宇密集,有众多的仓库、地下车库、营业场所的区域,一些业主可能会私自安装非法的直放站,这些直放站就可能成为干扰的元凶;地理位置分析法,可以依据以往的经验,初步判断干扰的性质,作为优先排查的一种可能的选择,但不应成为一种先入为主的主观意见。4实时RTWP数据分析法RTWP长期数据分析法得到的是以15分钟为单位的RTWP的平均值。实时RTWP数据分析法得到的是以秒为单位的RTWP的实时变化数值。利用该方法可以:确定干扰源的周期(可以精确到秒)以及与周边干扰源的相关性;确定干扰源的短期波动规律。下图为在排查深圳联通新阳丽舍站点的干扰确定某站点受到交通信号灯的干扰时,使用了PMS实时观察RTWP的方法,通过RTWP的周期与交通信号灯的周期完全吻合的原理,确认了干扰源。5RRU扫频数据分析法利用RRU的扫频功能,可以得到干扰的频谱特征,并以此来判断干扰的来源:直放站或干放的增益过高所造成的干扰通常会令频段内的多个频点的RTWP同时升高。如下图所示:受3G直放站干扰的小区的扫频图弱覆盖一般我们所说的弱覆盖是指ECIO低于-12.5db,一般是通过关联日志进行分析的。如下面的TOP1 小区10561 所示:Filter1 中Src Cell 输入10561:按照By Group 查询CS 掉话原因分布,可以看到40 次掉话全部归类为WeakCoverage(弱覆盖),。如要更近一步确定可以查看详细的码流, 例如, 如下的码流可以看到掉话前的测量报告RSCP-115dbm,Ec/N0RLC重传数据-重传仍未收到-RLC再次重传-达到重传次数上限-触发RLC连接复位-RLC复位仍无法恢复,则产生掉话或者小区更新。)2、上行同步失败导致释放3、Uu口无响应导致的释放4、其它原因导致的释放二、CS RAB中非RF原因导致释放1、OM干预导致的CS RAB请求释放2、RAB抢占导致的CS RAB请求释放3、IU接口AAL2链路异常导致RAB释放4、其他原因导致的CS掉话CS掉话多数出现在“无线环境”和“参数设置”两块。无线环境:1) 弱覆盖:室外RSCP在-95以下一般视为弱覆盖区。处理方案:增强覆盖(1、使用大功率载频或者加站等 2、降低异系统切换门限,使UE及时切换至2G网络)2) 各类特殊场景(一般描述为某某效应):拐角效应(调整天馈:使主导小区覆盖范围越过拐角;调整参数:提高1A、1B门限,使小区进入激活集容易,离开激活集困难)针尖效应:最直接的处理方案为调整天馈,消除针尖。站点在交通干道旁边,主瓣方向垂直于交通干道的小区也容易出现针尖效应,该小区信号往往瞬间增强之后瞬间衰弱,UE切换至该小区后来不及切换出导致掉话。该情况可以调整天馈,使UE在交通干道上运动时有个平滑的信号上升和下降过程即可;调整参数原则为提高1A、1B门限,使小区进入激活集容易(1A参数值越大,越容易加入激活集,1B参数值越大,越难离开激活集),离开激活集困难,并加快发生1D的速度,即降低门限和触发时延。3) 导频污染:某个小片区存在过多强导频,RSCP强、Ec/Io差,掉话根本原因为Ec/Io恶化。在话统中观察一般为TOP小区集中在一个片区或者一个用户在周边小区均存在掉话(这个现象在PS掉话中较明显,因为PS掉话次数一般远远大于CS掉话),调整天馈或者调整导频功率,突出某个主导频,降低干扰。4) 小区同扰码:问题解释:小区A与小区C同扰码(比如200号扰码),小区B与小区A互为邻区关系,用户在小区B接入,200号扰码强度超过门限后将发起切换;此处,若UE接收到的200号扰码为A小区,因为两个小区有邻区关系,不会出现问题,若200号扰码为C小区,则RNC会误判发起切换,在话统中看到结果为,小区B至小区A切换失败,小区B上CS掉话。处理方案:修改扰码,外部邻区,2G侧的异系统邻区信息也需要相应修改。如果是因为某个小区过覆盖引起,可以通过调整天馈控制覆盖。5) 上行干扰:RTWP问题,需要排除干扰源。如行政部门一般都存在信号屏蔽等设备。6) 设备问题:该类问题一般需要从信令上判断,比如信令异常或者丢信令等。7) 手机制造厂:手机生产过程中有一步为拔电池,同样会导致掉话。参数问题:参数问题在特殊场景中出现较多,比如覆盖高速,铁路等一片小区,该类问题一般会开展专项优化。如高速公路:相对于默认参数,需要提高1A门限、时延,使小区容易加入激活集,降低1D门限、时延,使UE及时切换至最好小区,降低滤波,使UE对信号变化更为敏感。8) 邻区漏配,或者邻区等参数有误。邻区漏配情况在关联日志和NCOS中可以较为容易的看出,目前现网中因邻区漏配或者邻区等参数有误造成掉话高的情况非常少,这类问题很好定位和解决。下面附上前段时间处理过的一个案例:江津仁沱AMR掉话率高处理问题描述:江津仁沱站点从5月16日开始,AMR掉话率突然恶化,每天掉话次数由原来的0次上升到20次以上,掉话率恶化至12%以上。江津仁沱掉话统计走势图时间NodeB电路域AMR业务掉话率AMR业务掉话次数小区电路域话务量(爱尔兰)小区上行平均RTWP(dBm)2011-05-14UZBCS011江津仁沱0.00%02.1321-106.34122011-05-15UZBCS011江津仁沱0.00%02.5625-106.94812011-05-16UZBCS011江津仁沱12.50%231.8567-106.72742011-05-17UZBCS011江津仁沱12.94%333.98-106.6352011-05-18UZBCS011江津仁沱18.14%393.5744-106.54132011-05-19UZBCS011江津仁沱19.43%342.4214-106.44492011-05-20UZBCS011江津仁沱14.21%273.2375-106.5683江津仁沱掉话统计表分析 :1、江津仁沱站点掉话率在5月16日突然恶化,查看该站点话务量,没有明显提升,掉话问题与话务量没有明显关联。2、查看江津仁沱站点上行RTWP,没有发现异常,一致保持在-106dB左右,排除掉话问题由于内部干扰或者外部干扰导致。3、查看后台告警,发现江津仁沱站点存在传输告警E1/TI链路光电信号丢失,掉话问题可能由于传输告警导致,建议分公司处理告警;6月1日告警恢复,但该站点掉话问题依然存在,如下图;4、对无线参数,邻区关系和硬件配置进行核查,未发现异常。开始怀疑是小区半径不足,我们将该站点各小区的小区半径由5KM修改为10KM,但掉话问题仍存在,后对传输局向数据进行检查,发现该站点传输配置中的AAL2 VC链路数目不正确,江津仁沱站点E1配置是2条,支持的链路层上承载业务的AAL2 VC链路应该是3条,而该站点却配置了4条,其中多配置的1条是无法进行业务承载的,用户做业务时一旦被分配到这条链路,就将导致掉话,初步估计该站点就是因为这个原因导致的高掉话。优化建议将江津仁沱站点的基站地面资源管理中链路层管理下的AAL2VC链路由4条改为3条。处理方案将江津仁沱站点的基站地面资源管理中链路层管理下的AAL2VC链路由4条改为3条。验证情况6月8号将江津仁沱站点AAL2 VC链路配置数目修改为3条后,从6月9号开始,江津仁沱站点恢复至0掉话,如下图:处理后AMR掉话走势图时间NodeB电路域AMR业务掉话率AMR业务掉话次数小区电路域话务量(爱尔兰)小区上行平均RTWP(dBm)2011-06-04UZBCS011江津仁沱14.97%443.9183-106.72412011-06-05UZBCS011江津仁沱14.08%292.9736-106.80162011-06-06UZBCS011江津仁沱18.93%392.92-106.71962011-06-07UZBCS011江津仁沱10.08%254.0014-106.6422011-06-08UZBCS011江津仁沱6.12%123.5769-106.58472011-06-09UZBCS011江津仁沱0.00%03.8625-106.64042011-06-10UZBCS011江津仁沱0.00%03.1328-106.75692011-06-11UZBCS011江津仁沱0.00%03.3361-106.76892011-06-12UZBCS011江津仁沱0.00%03.4317-106.6554处理后AMR掉话统计表案例总结江津仁沱站点掉话高是由于传输侧数据配置错误导致,由于该站点掉话问题在5月16日突然出现,配置数据没有做过修改,所以我们把问题排查方向定位在无线参数、硬件故障、外部干扰及话务量等可能随时产生变化的因素上,忽略了传输参数设置方面因素,导致问题处理滞后,以后无论碰到任何问题,需要第一时间从各个可能的方向进行分析,才能更快解决问题。3.3 PS掉话高的问题定位和优化方案PS掉话跟CS掉话问题定位与处理手段基本一致,这里就不再列举PS掉话高的处理案例。一、PS RAB中RF原因导致释放主要分为以下几类:1、RLC复位导致释放2、上行同步失败导致释放3、Uu口无响应导致的释放4、其它原因导致的释放二、PS RAB中非RF原因导致释放1、OM干预导致的CS RAB请求释放2、RAB抢占导致的CS RAB请求释放3、GTPU异常导致RAB释放4、其他原因导致的PS掉话PS掉话和CS掉话处理方案相同,相对终端等问题会多一点。特例:145号段,3G上网卡专用号段,开通了3G上网功能,未开通2G功能。无线侧会发起3G-2G切换,由于核心网侧未开通2G功能,不能完成切换,当UE进入3G弱覆盖区容易发生掉话。这类问题处理方式和弱覆盖相同,解决了弱覆盖,145卡就不会产生过多掉话。3.4 CS、PS异系统换成功率低问题定位和处理办法3G外部邻区定义是否有误,3G小区参数设置不合理,2G小区存在告警,2G小区拥塞,漏配最佳的2G邻区。一般故障处理过程为:首先检查3G小区的本小区是否存在告警,当本小区存在告警时,优先处理本小区告警,排查此3G小区的外部邻区定义是否有误,包括CI,BCCH,BSIC等参数;二,在话统提取异系统切换的切换关系,看此3G小区的异系统切换情况,是否存在向单个2G小区大量切换换过程中,存在着大量的失败而导致总体指标下降。如果是此种情况:则去排查此2G小区是否存在告警,2G小区是否拥塞。若不是此种情况,则具体分析此3G小区的外部邻区是否存在着最佳2G邻区漏配(很多时间不光是有邻区就可以,关键是最佳邻区必须配置)。如果以上情况均检查无误,则可以尝试修改基于覆盖异系统切换参数的修改:可以修改此小区的接入门限,让UE提前驻留在2G;修改此小区的2D,2F的门限,提前进入压模,以及切换CIO偏置等各个参数都是可以尝试去修改。现网中的PS异系统切换出成功率低问题绝大部分为145卡用户造成,因为145号段为3G上网卡专用号段,开通了3G上网功能,未开通2G功能。无线测会发起3G-2G切换,由于核心网未开通2G功能,不能顺利切换,但会一直发起切换,故可能在短时间内造成大量的PS异系统切换出失败,目前我们针对145卡的这种情况设置了第六套切换索引,抑制145卡用户向2G切换,就现网第六套切换索引的应用情况来看,效果明显。下面附上最近处理的一个CS异系统切换成功率低案例:合川沙坪-2CS异系统切换出成功率低处理案例问题描述合川沙坪-2从5月20日开始,CS异系统切换成功率突然恶化,每天失败次数由原来的几次上升到40-50次,有时甚至达到将近100次,CS异系统切换成功率恶化至68%左右。合川沙坪-2cs异系统切换统计走势图开始时间小区小区系统间电路域切换出成功率(WCDMA-GSM)电路域系统间小区切换出失败次数小区上行平均RTWP(dBm)小区电路域话务量(爱尔兰)2011-05-20UZBCK116合川沙坪_268.75%60-105.86617.25942011-05-21UZBCK116合川沙坪_276.85%47-106.90715.07612011-05-22UZBCK116合川沙坪_277.43%51-106.94818.50082011-05-23UZBCK116合川沙坪_281.92%49-106.61217.35722011-05-24UZBCK116合川沙坪_287.17%29-106.43218.86832011-05-25UZBCK116合川沙坪_271.14%101-106.1519.87392011-05-26UZBCK116合川沙坪_282.16%43-105.81819.80672011-05-27UZBCK116合川沙坪_279.28%23-105.99419.2578合川沙坪-2cs异系统切换统计表分析 1、合川沙坪-2异系统切换成功率在5月20日突然恶化,查看该站点话务量,没有明显提升,异系统切换成功率低问题与话务量没有明显关联。2、查看合川沙坪-2上行RTWP,没有发现异常,一致保持在-106dB左右,排除掉话问题由于内部干扰或者外部干扰导致。3、查看本小区后台告警,未发现任何告警,核查小区的重选参数,异系统切换等参数,未发现异常。4、通过后台GSMRELATION提取的指标查询合川沙坪-2与周围2G邻区的切换失败次数,发现切换失败主要发生在G网小区460:1:33582:4150,4151,4152三个小区,如下:开始时间NodeB ID源小区 IDGSM邻接小区 ID电路域系统间小区间切换出失败次数,物理信道失败2011-05-25364436442460:1:33582:4150222011-05-25364436442460:1:33582:4151162011-05-25364436442460:1:33582:415249查询合川沙坪-2的2G邻区,不存在漏配情况,查询2G无线参数发现这三个小区为ZCK82合川移通学院_0,1,2小区,查询2G侧合川移通学院的告警,干扰,拥塞和指标,未发现异常情况。至此我们已基本排除2G和3G小区的参数配置错误,告警,干扰,邻区信息错误等情况。5、通过后台提取关联日志,分析关联日志发现,这些天指标的异常都是因为单用户造成,从信令中只能看出失败原因为物理信道重配置失败,初步估计为用户终端或者SIM卡问题。优化建议将江合川沙坪-2的异频异系统切换索引修改为第七套(CS 2D/2F:-115/-113;3A本系统/异系统:-115/-60),抑制单用户向2G进行切换,以免对全网指标造成较大冲击。处理方案将合川沙坪-2的异频异系统切换索引修改为第七套。验证情况6月4号将合川沙坪-2的异频异系统切换索引修改为第七套后,从6月5号开始,合川沙坪-2的异频异系统切换失败次数基本都降为了0,如下图:处理后CS异系统切换走势图开始时间小区系统间电路域切换出成功率(WCDMA-GSM)电路域系统间小区切换出失败次数2011-06-05100.00%02011-06-06100.00%02011-06-0794.74%12011-06-08100.00%02011-06-09100.00%02011-06-10100.00%02011-06-11100.00%02011-06-12100.00%02011-06-13100.00%02011-06-14100.00%02011-06-15100.00%0处理后CS异系统切换统计表案例总结合川沙坪-2异系统切换成功率低是由于单用户原因造成的,由于该问题在5月20日突然出现,3G侧无线参数和配置数据都没有做过修改,所以我们把问题排查方向定位在硬件故障和2G侧,但经过查询后3G不存在硬件故障和告警,2G侧也不存在告警、干扰和指标异常,最后通过关联日志分析定位为单用户原因,对于单用户问题,我们尽量联系单用户了解情况,如手机或者SIM卡存在问题,建议用户去修理或者更换,如实在没办法只能通过修改异系统切换参数抑制单用户向2G侧进行切换。3.5 RRC接入成功率低的问题定位和处理方法RRC 建立失败一般有下面几类原因:1. 上行RACH 的问题2. 下行FACH 功率配比问题3. 小区重选参数问题4. 下行专用初始发射功率偏低5. 上行初始功控问题6. 拥塞问题7. 设备异常问题等基于UE与RNC的信令交互可以分为以下3类:1. UE发起RRC_Connect_Req,RNC没有收到。2. UE发起RRC_Connect_Req,RNC拒绝。3. UE发起RRC_Connect_Req,RNC回复RRC_Setup_Rsp,UE未收到。第一种情况:如果此时Ec/Io较低,则此时可以考虑为覆盖原因造成。如果此时Ec/Io较好(大于-14dB),一般都是RACH问题,通常有以下原因:1.preamble的功率攀升不够:可以增加Preamble攀升次数。2.小区半径设置参数不合理:小区半径参数设置过小,会导致NodeB无法同步小区半径范围外的UE,造成接入失败,这主要发生在农村、郊区等广覆盖场景。第二种情况:RNC拒绝的情况,此种情况基本是由RNC当前的资源拥塞状态引起,包括码,功率,CE等资源。也有可能是RNC本身的设备问题引起,需要看具体的日志进行确认。第三种情况:RNC下发后UE没有收到,说明此时UE有可能已经发生了小区重选。此时可以调整小区重选参数,可以解决此类情况。现网中出现的RRC连接建立成功率低top小区基本都是因为基站告警和硬件故障导致,还有少数为弱覆盖、小区半径不足和参数设置问题(包括FACH功率设置,小区重选参数等)。下面给出前期处理的一个RRC建立成功率低案例永川茶店高速站点RRC建立成功率低处理案例问题描述根据后台系统统计发现,永川茶店高速站点接通率一直很低,网优测试人员现场测试发现永川茶店高速2小区信号存在瞬间闪断现象。情况说明我们提取关联日志查看失败的信令流程,如下图:可以看到失败点是下发Setup消息无响应,同时我们也注意到在上报Request消息时的EC/IO没有问题,查看其它信令流程时,发现情况类似,而且不是单用户引起。这是任取一天的TOP UE情况,发现失败最多的也只有4次,分布较为平均,通过时延查看用户分布也不均匀,基本是在距离基站50-600米的区间内,那么基本可以排除空口环境的因素,遂要求片区人员前往进行现场测试排查。以下为现场测试及排查情况:正常情况图出现闪断问题图分析:如图所示,正常情况时,永川茶店高速2小区所有业务正常,RSCP在-70dBm左右,EC/IO在-6dB左右,该小区会突发性的出现闪断现象,完全没有信号,测试手机处于脱网状态,该站点其余两个小区没有出现闪断问题。更换2、3小区光纤后测试情况在对调2、3小区光纤后,测试发现在原来问题点位置,占用到3小区(psc:203)信号时,出现闪断现象。可以判断该站点闪断现象不是由于NODE B级问题点导致,问题应该出现在天馈或者RRU上,是小区级问题,由于闪断现象出现后,在几秒内可以自动恢复,初步估计为RRU问题。处理建议建议更换该站点RRU,再对问题点进行复测。处理方案更换茶店高速_2小区RRU验证测试情况8日更换RRU后,该小区所有业务正常,测试时间30分钟内,没有出现闪断现象。从指标上也可以看出9月8日后RRC连接建立成功率恢复正常,问题闭环。案例总结遇到接入类问题在空口以及参数设置上均无问题的情况下应该扩大范围,通过现场排查的手段进行定位。3.6 CS和PS RAB建立成功率低问题定位和处理方法RAB建立成功率低一般有以下几类原因:1.覆盖问题覆盖类问题,需进行相应区域RF优化,通过提升覆盖的方式缓解该类失败,对于通过RF优化调整效果甚微的小区,可适当进行驻留门限调整,尽快重选至2G网络;2.干扰问题现象:KPI中可以看到底噪比较高解决方法:干扰类问题,需通过清频、关闭干扰源、增加滤波器、增加隔离度等方式进行缓解;3.双RAB问题现象:终端发起两种以上业务,在建立第二种业务的RAB时失败解决方法:双RAB问题,考虑到无明显用户感受问题可暂缓,该问题主要和终端能力相关。4.Node B资源吊死问题现象为大量 RL failure及RB Complete收不到;解决方法:Node B资源吊死问题,需通过异常探针进行确定,出现类似现象,将异常探针反馈到研发确认。5.手机不回RB Complete问题目前发现的规律是该类终端支持F-DPCH;已知终端为诺基亚N97和N85解决方法:手机不回RB Complete问题,需关注终端能力,判断是否支持F-DPCH,后续通过版本将该功能关闭;6.传输受限问题从KPI指标上看IUB口拥塞很高,查该站传输信息,传输类型为E1时,从关联日志分析信令,表现为RNC进行传输带宽接纳时失败,向NodeB发rlRecfgCancel,内部信令显示:Transport bear Setup Response Part Success。注:内部错误码 7:SmaEstablishCfm-bResult= 7 DBSfailed。这种原因一般为传输受限解决方法:传输扩容7.传输配置错误RAB指派的失败流程都是无线链路重配取消,传输失败,内部原因为12。关联日志看SmaEstablishCfm-bResult= 12具体原因:混合传输FE传输配置错误解决办法:进行FE传输配置修改8.RGHI签名资源不足问题现象:无线链路重配失败,原因为TNBAP_nodeB_Resources_unavailable 异常探针中出现ERR_BAS_BDLSRNOIDLESIG 解决方法:增加E-RGCH/E-HICH码道数。还有一些影响RAB建立成功率的原因,比如FD OB、SB资源不足,基带底层丢包、DSP 1bit软失效等,这些都是在重庆出现过并且导致RAB建立成功率恶化的问题,但是并不典型常见。重庆前期由于传输配置错误导致的RAB建立失败比较严重,下面给出一个具体排查案例:IUR路径带宽配置错误导致RAB连接建立失败。问题描述重庆中兴业务区和华为业务区交界处部分小区涉及IUR口的业务建立失败次数很多,对网络KPI影响很大,并且这些小区的业务建立失败原因都相同,具有共性。排查过程第一步:查看问题站点告警信息,并无告警。第二步:分析问题小区的关联日志,都是RRC阶段在中兴业务区的小区建立的无线链路,然后在RAB建立请求前上报1A事件,准备切换到华为业务区的目标小区,S侧RNC是中兴的,D侧RNC是华为的。最后在业务建立阶段会报IUR口AAL2建立失败,失败原因为7,最终导致该业务建立失败。第三步:根据去年830测试时的经验,各地市也存在IUR口AAL2建立失败导致的业务建立失败,当时的失败原因是34,是由IUR口AAL2 path的CID不足造成的。这里的失败原因为7,是不是也是IUR口的某种资源不足?通过咨询相关研发人员,答复原因7的解释为SIGAPP_SMA_FAIL_CAUSE_NO_MODULE_RESOURCE,可能是IUR口带宽不够。提取其中一个RNC的系统日志分析也发现ANI是4和7的都有失败,而该RNC华为邻接RNC的ANI就是4、7,这也和问题仅出现在中兴和华为之间的IUR口相符,中兴和中兴之间的IUR口就没有该问题。第四步:重点检查IUR口的传输带宽配置。通过对RNC侧地面资源管理的传输配置进行检查,发现网元信息邻接RNC的配置中,中兴和华为的路径配置有差异。邻接RNC是中兴的,配置了一条path,该path的前后向带宽为40000kbps;邻接RNC是华为的,这里则配置了5条path,且路径编号从34至37分别配置了前后向带宽9600kbps,虽然配置了编号为38的路径,但是该路径配置的带宽均为0kbps。那为什么要配这样一条路径,却不分配带宽呢?难道问题就出在这里了,配置了一条无用的path,所以经常导致在IUR口传输建立失败,而不是真正的带宽不足。经过和研发人员沟通,也确认了这一点,如果该路径有用,就要配上带宽,如果没有用,则需要删除该路径。同时和用服人员也了解了一下,配置5条path是华为侧的要求,并且第5条ptah也应该配置实际带宽的,只是当时在配置IUR口数据的时候,导表的结果是第5条path的带宽都为0,需要再手动把这条path的带宽修改成实际值。问题处理找了一个失败次数较多的RNC2768,将该RNC的所有华为邻接RNC路径配置路径编号38的前后向带宽配置为9600kbps。通过观察邻接RNC类型的指标,RNC2768从4月22日修改path带宽配置后,Iur口资源申请失败率和失败次数都明显降低。相应的小区级Counter“分组域RAB指配建立失败的RAB数目,RLMM程序异常”次数也明显降低。对重庆中兴业务区所有RNC配置的华为邻接RNC路径带宽进行核查,将带宽配置为0的路径都进行修改。最终全网“分组域RAB指配建立失败的RAB数目,RLMM程序异常”的次数每天减少1000-1500次。4 总结从前期TOP小区的处理情况来看,总体的处理效果良好,闭环率也较高,但在未闭环的小区中有很大一部分小区,在处理过后失败次数和失败率都有了明显好转,但因为话务量较低,一周失败几次就达不到闭环要求,后续将针对该部分小区进一步进行处理,争取尽快闭环。下面我们总结了下前期处理TOP小区的方法,整理成了如下表格,但PS业务有个特例就是145卡,对于145卡的处理方法如下:145卡掉话高的处理方法基本和弱覆盖相似,解决了弱覆盖145卡就不会产生过多的掉话。145卡造成的PS异系统切换成功率低问题,目前还没有特别好的解决方法,只能是通过修改异系统切换参数,抑制145卡向2G进行切换,目前我们现网中的第六套切换索引就是用于这种情况的。问题类型问题原因解决方法CS和PS掉话高弱覆盖加强覆盖:1、使用大功率载频或者加站等 2、降低异系统切换门限,使UE及时切换至2G网络各类特殊场景拐角效应(调整天馈:使主导小区覆盖范围越过拐角;调整参数:提高1A、1B门限,使小区进入激活集容易,离开激活集困难)针尖效应:最直接的处理方案为调整天馈

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论