WCDMA网络TOP小区处理经验总结

WCDMA网络TOP小区处理经验总结 重庆联通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侧小区的告警，干扰，拥塞情况和指标) )查询问题是单个小区问题还是区域性的问题，如果是单小区问题，则转到第3步;2 如果是区域性的问题，则应该对问题区域的传输数据和核心网数据进行核查，检测传输是否存在故障等。 3)核查无线参数，邻区关系和传输配置参数(如果是系统间切换指标差，也需查询配置的2G侧的数据是否有误，2G邻区是否合理，是否存在漏配等。) )提取关联日志，通过关联日志 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 坏小区无线环境的质量和大概与周围哪些小区存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的周期与交通信号灯的周期完全吻合的原理，确认了干扰源。 5(RRU扫频数据分析法 利用RRU的扫频功能，可以得到干扰的频谱特征，并以此来判断干扰的来源: 直放站或干放的增益过高所造成的干扰通常会令频段内的多个频点的RTWP同时升高。如下图所示: 受3G直放站干扰的小区的扫频图 弱覆盖 一般我们所说的弱覆盖是指ECIO低于-12.5db，一般是通过关联日志进行分析的。 如下面的TOP1 小区10561 所示: Filter1 中Src Cell 输入10561: 按照By Group 查询CS 掉话原因分布，可以看到40 次掉话全部归类为WeakCoverage(弱覆盖),。如要更近一步确定可以查看详细的码流， 例如， 如下的码流可以看到掉话前的测量报告 RSCP<-115dbm,Ec/N0<-15db: 对于弱覆盖的站点需要结合地图，站点所在的地理特征来分析，本例中的站点在边境，属于边境弱覆盖。 单板负荷 随着3G用户量的增加，由于单板负荷高而引起的指标差的问题随之而来。比如在RNC U9.1和U9.3系列版本中，控制面信令，包括NBAP、RRC、RANAP等都是由RCP来处理的。小区归属于某一个RCP模块，UE的每次业务，都由其所驻留小区所属的RCP来处理的。如果这个RCP上的小区话务量都很高，就有可能导致RCP的CPU占用率升高，即使有其它比较空闲的RCP，也不能分担其话务量。我们需要手工将话务量较高的站点迁移到负荷较低的RCP，从而降低RCP的CPU负荷。当然，如果通过站点迁移仍然不能有效降低RCP的CPU负荷，那就需要考虑扩容了。 站点迁移 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 一般通过以下步骤来完成: 分析RCP CPU占用情况，决定迁移方向; 导出各NodeB的话务量; 统计各RCP的话务量; 分析话务量，给出迁移方案。 3.2 CS掉话高问题定位和优化方案 CS掉话在话统中的统计分为两类:RF原因和非RF原因; 一、CS RAB中RF原因导致释放主要分为以下几类: 1、RLC复位导致释放(RLC复位触发:类似应用层的TCP协议，RLC层发送数据后需 要得到确认才可以发送下一段数据。RLC发送方未收到确认-->RLC重传数据--->重传仍未收到--->RLC再次重传---->达到重传次数上限--->触发RLC连接复位--->RLC复位仍无法恢复，则产生掉话或者小区更新。) 2、上行同步失败导致释放 3、Uu口无响应导致的释放 4、其它原因导致的释放 二、CS RAB中非RF原因导致释放 、OM干预导致的CS RAB请求释放 1 2、RAB抢占导致的CS RAB请求释放 、IU接口AAL2链路异常导致RAB释放 3 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%以上。 江津仁沱掉话统计走势图 2011-05-14 0.00% 0 2.1321 -106.3412 UZBCS011江津仁沱 2011-05-15 0.00% 0 2.5625 -106.9481 UZBCS011江津仁沱 2011-05-16 12.50% 23 1.8567 -106.7274 UZBCS011江津仁沱 2011-05-17 12.94% 33 3.98 -106.635 UZBCS011江津仁沱 2011-05-18 18.14% 39 3.5744 -106.5413 UZBCS011江津仁沱 2011-05-19 19.43% 34 2.4214 -106.4449 UZBCS011江津仁沱 2011-05-20 14.21% 27 3.2375 -106.5683 UZBCS011江津仁沱 江津仁沱掉话统计表 分析 : 1、江津仁沱站点掉话率在5月16日突然恶化，查看该站点话务量，没有明显提升，掉 话问题与话务量没有明显关联。 2、查看江津仁沱站点上行RTWP，没有发现异常，一致保持在-106dB左右，排除掉话问题由于内部干扰或者外部干扰导致。 、查看后台告警，发现江津仁沱站点存在传输告警E1/TI链路光电信号丢失，掉话问3 题可能由于传输告警导致，建议分公司处理告警; 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掉话走势图 2011-06-04 UZBCS011江津仁沱 14.97% 44 3.9183 -106.7241 2011-06-05 UZBCS011江津仁沱 14.08% 29 2.9736 -106.8016 2011-06-06 UZBCS011江津仁沱 18.93% 39 2.92 -106.7196 2011-06-07 UZBCS011江津仁沱 10.08% 25 4.0014 -106.642 2011-06-08 UZBCS011江津仁沱 6.12% 12 3.5769 -106.5847 2011-06-09 UZBCS011江津仁沱 0.00% 0 3.8625 -106.6404 2011-06-10 UZBCS011江津仁沱 0.00% 0 3.1328 -106.7569 2011-06-11 UZBCS011江津仁沱 0.00% 0 3.3361 -106.7689 2011-06-12 UZBCS011江津仁沱 0.00% 0 3.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异系统切换统计走势图 2011-05-20 UZBCK116合川沙坪_2 68.75% 60 -105.866 17.2594 2011-05-21 UZBCK116合川沙坪_2 76.85% 47 -106.907 15.0761 2011-05-22 UZBCK116合川沙坪_2 77.43% 51 -106.948 18.5008 2011-05-23 UZBCK116合川沙坪_2 81.92% 49 -106.612 17.3572 2011-05-24 UZBCK116合川沙坪_2 87.17% 29 -106.432 18.8683 2011-05-25 UZBCK116合川沙坪_2 71.14% 101 -106.15 19.8739 2011-05-26 UZBCK116合川沙坪_2 82.16% 43 -105.818 19.8067 2011-05-27 UZBCK116合川沙坪_2 79.28% 23 -105.994 19.2578 合川沙坪-2cs异系统切换统计表 分析 1、合川沙坪-2异系统切换成功率在5月20日突然恶化，查看该站点话务量，没有明显提升，异系统切换成功率低问题与话务量没有明显关联。 2、查看合川沙坪-2上行RTWP，没有发现异常，一致保持在-106dB左右，排除掉话问题由于内部干扰或者外部干扰导致。 3、查看本小区后台告警，未发现任何告警，核查小区的重选参数，异系统切换等参数，未发现异常。 4、通过后台GSMRELATION提取的指标查询合川沙坪-2与周围2G邻区的切换失败次数，发现切换失败主要发生在G网小区460:1:33582:4150，4151，4152三个小区，如下: 2011-05-25 3644 36442 460:1:33582:4150 22 2011-05-25 3644 36442 460:1:33582:4151 16 2011-05-25 3644 36442 460:1:33582:4152 49 查询合川沙坪-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异系统切换走势图 2011-06-05 100.00% 0 2011-06-06 100.00% 0 2011-06-07 94.74% 1 2011-06-08 100.00% 0 2011-06-09 100.00% 0 2011-06-10 100.00% 0 2011-06-11 100.00% 0 2011-06-12 100.00% 0 2011-06-13 100.00% 0 2011-06-14 100.00% 0 2011-06-15 100.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进行切换，目前我们现网中的第六套切换索引就是用于这种情况的。 问题类型 问题原因 解决方法 加强覆盖:1、使用大功率载频或者加站等 2、降低异系统切换门弱覆盖 限，使UE及时切换至2G网络 拐角效应(调整天馈:使主导小区覆盖范围越过拐角;调整参数: 提高1A、1B门限，使小区进入激活集容易，离开激活集困难) 针尖效应:最直接的处理方案为调整天馈，消除针尖。站点在交通 干道旁边，主瓣方向垂直于交通干道的小区也容易出现针尖效应， 该小区信号往往瞬间增强之后瞬间衰弱，UE切换至该小区后来不及各类特殊场景 切换出导致掉话。该情况可以调整天馈，使UE在交通干道上运动时 有个平滑的信号上升和下降过程即可;调整参数原则为提高1A、1B 门限，使小区进入激活集容易(1A参数值越大，越容易加入激活集，CS和PS 1B参数值越大，越难离开激活集)，离开激活集困难，并加快发生掉话高 1D的速度，即降低门限和触发时延。 某个小片区存在过多强导频，RSCP强、Ec/Io差，掉话根本原因为 Ec/Io恶化。在话统中观察一般为TOP小区集中在一个片区或者一 导频污染 个用户在周边小区均存在掉话(这个现象在PS掉话中较明显，因为 PS掉话次数一般远远大于CS掉话)，调整天馈或者调整导频功率， 突出某个主导频，降低干扰。 修改扰码，外部邻区，2G侧的异系统邻区信息也需要相应修改。如同扰码 果是因为某个小区过覆盖引起，可以通过调整天馈控制覆盖。 上行干扰 RTWP问题，需要排除干扰源。如行政部门一般都存在信号屏蔽等 设备。但现网中绝大部分RTWP异常的小区都是因为下挂了室分，因 室分存在问题而导致的。需先协调分公司让室分厂家处理室分问题。 该类问题一般需要从信令上判断，比如信令异常或者丢信令等。(了设备问题 解) 基站告警 手机生产过程中有一步为拔电池，同样会导致掉话。(了解) 邻区漏配情况在关联日志和CNO中可以较为容易的看出，目前现网 邻区漏配或邻区参数有中因邻区漏配或者邻区等参数有误造成掉话高的情况非常少，这类 误 问题很好定位和解决。解决方法:添加漏配的邻区和改正有误的邻 区参数 3G外部邻区定义是否有排查此3G小区的外部邻区定义是否有误，包括CI，BCCH，BSIC 误 等参数 基于覆盖异系统切换参数，小区的接入门限以及切换CIO偏置等各3G小区参数设置不合理 个参数，针对不同情况进行优化修改 CS，PS异 2G小区存在告警，干扰系统硬切处理2G小区告警，干扰等 等 换成功率 2G小区拥塞 处理2G小区拥塞 低 漏配最佳的2G邻区 添加漏配邻区 CS异系统单用户则修改为第七套切换索引，抑制单用户向2G切换; 单用户原因 PS异系统单用户(包括145卡)则修改为第六套切换索引，抑制单 用户向2G切换。 1.preamble的功率攀升不够:可以增加Preamble攀升次数。2.小 区半径设置参数不合理:小区半径参数设置过小，会导致NodeB无 上行RACH 的问题 法同步小区半径范围外的UE，造成接入失败，这主要发生在农村、 郊区等广覆盖场景。 下行FACH 功率配比问增加FACH最大发射功率 题 RRC接入 小区重选参数问题 调整小区重选参数 成功率低 下行专用初始发射功率增加下行专用初始发射功率 偏低 上行初始功控问题 调整功控参数 拥塞问题 解决拥塞 硬件故障或者基站告警 处理故障和告警 在前期我们处理top小区的过程中，也遇到一些困难，比如发现基站硬件故障和告警等， 通知片区负责人和分公司，但问题一直不能得到妥善解决，该类硬件和告警问题目前的处理 系统不完善，有待后续制定一套完善的处理制度，以便能更好更快的解决硬件和告警问题。 目前郊区的大部分小区的小区半径都是5KM，根据前期top小区处理的经验，这些小 区覆盖范围基本上都超出5KM，在5KM之外会出现接入失败和切换掉话，存在接入失败和 掉话的隐患，故后续我们将针对该部分小区进行小区半径优化，进一步改善全网接通率和掉 话率。