WCDMA某站点RRU隐性故障导致无法上网问题分析报告.docx

RRU隐性故障导致无法上网问题分析报告一、问题描述2014年6月18日下午接到用户投诉，用户描述自6月16日起在XXX基站1小区方向无法上网。随后进行了相应小区的KPI指标查询，发现XXX基站-4小区（第1扇区中频小区）分组域业务掉线率升高，其他指标正常，如表1和图1所示。表1XXX基站-4小区相关指标日期小区名称电路域话务量(Erl)分组域FP层流量(Mbytes)分组域业务掉话率(%)分组域业务掉话次数(次)2014-6-13XXX基站-4(16384)41.08722666.720.02%152014-6-14XXX基站-4(16384)46.61363388.460.02%162014-6-15XXX基站-4(16384)44.47193404.360.02%222014-6-16XXX基站-4(16384)44.43311891.720.55%5792014-6-17XXX基站-4(16384)44.99331519.910.52%5792014-6-18XXX基站-4(16384)38.66311551.710.49%5682014-6-19XXX基站-4(16384)20.2147762.340.45%219图1XXX基站-4小区分组域业务掉话趋势图从上面的图表可以发现，从6月16日开始，XXX基站-4小区的分组域业务掉话次数和掉话率都有明显上升。从用户角度看，应该是刚上网就掉线，感知上表现为无法上网。二、问题分析定位从网管分组域业务掉话计数器统计，如表2所示。表2XXX基站-4分组域业务掉话原因统计日期小区名称RNC通过Iu Release Request主动发起释放的分组域RAB数目,DL RLC error on TRB导致的失败(次)RNC通过Iu Release Request主动发起释放的分组域RAB数目,不确定失败(次)2014-6-16XXX基站-4(16384)7805762014-6-17XXX基站-4(16384)7535882014-6-18XXX基站-4(16384)7735672014-6-19XXX基站-4(16384)322242网管显示失败原因为DL RLC error on TRB导致的失败、不确定失败，无法定位具体原因，下面通过关联日志进行进一步分析定位。取RNC563的2014年6月19日上午10点和11点的关联日志，过滤出XXX基站-4（16384）的异常事件，过滤方法如图2所示。图2 筛选XXX基站-4小区的异常事件筛选结果显示该小区失败总次数为245次，弱覆盖原因（WeakCoverage）32次，占13.06%；非特定的无线原因（UnspecRadioReason）99次，占40.41%；非无线原因（NotRadioReason）114次，占46.53%；大部分原因集中在非特定的无线原因和非无线原因上，这两项共占86.94%，如图3所示。图3 失败次数和原因分布将非特定的无线原因和非无线原因两个节点继续展开，发现非特定的无线原因主要集中在小区更新时Uu口超时这个原因上，非无线原因全部是其他原因，如图4所示。图4 非特定的无线原因和非无线原因节点展开小区更新过程在RRC连接模式下的任意一个状态都有可能被触发，触发小区更新过程的原因共有七个，分别是重新进入服务区、RLC发生不可恢复的错误、周期性小区更新、小区重选、无线链路失败、上行链路数据传输、响应寻呼。本例中小区更新的原因是无线链路失败，如图5所示。图5 小区更新原因为无线链路失败对其中任意一个失败记录进行详细原因查看，发现目标小区信息无法解码，如图6所示。图6 小区更新的目标小区无法解码在无线链路失败原因报告里，发现原因有两个，一个是Cell Barred Or Reserved，另一个是Edch Act Full，如图7所示。图7 无线链路失败原因报告检查小区参数不存在问题，基站也不存在任何告警，从这两个原因上基本可以断定是RRU缓存耗尽导致的。对非无线原因中的其他原因进行进一步分析，发现失败的基本集中在PS R99业务释放阶段，如图7所示。图7 非无线原因的其他原因分布对其中一个失败记录进行进一步分析，Iu Release释放原因为非标准的，代码138，如图8所示。图8 Iu口链路释放原因代码138错误指示显示原因值为eNBAP_CauseMisc_oam_intervention，如图9所示。图9 错误指示原因值该种原因基本上是由于信令板阻塞引起。经过以上分析，可以断定问题出现的原因，基本上是由于RRU缓存耗尽，导致信令板阻塞，RRU工作异常导致。三、解决方法将相应RRU复位重启。四、调整后效果重启基站之后，恢复正常，前后指标对比如表3和图10所示。表3 调整前后XXX基站-4指标对比日期小区名称电路域话务量(Erl)分组域FP层流量(Mbytes)分组域业务掉话率(%)分组域业务掉话次数(次)2014-6-13XXX基站-4(16384)41.08722666.720.02%152014-6-14XXX基站-4(16384)46.61363388.460.02%162014-6-15XXX基站-4(16384)44.47193404.360.02%222014-6-16XXX基站-4(16384)44.43311891.720.55%5792014-6-17XXX基站-4(16384)44.99331519.910.52%5792014-6-18XXX基站-4(16384)38.66311551.710.49%5682014-6-19XXX基站-4(16384)20.2147762.340.45%2192014-6-20XXX基站-4(16384)49.72193080.760.02%152014-6-21XXX基站-4(16384)44.26252612.800.01%102014-6-22XXX基站-4(16384)39.28942373.040.02%172014-6-23XXX基站-4(16384)48.02422862.720.01%112014-6-24XXX基站-4(16384)42.69942593.200.03%19图10 调整前后XXX基站-4小区分组域业务掉话趋势图从表3和图10中可以看出，重启之后XXX基站-4小区分组域业务掉话指标恢复到正常水平。五、案例小结RRU隐性故障的问题，在以后的日常优化过程中，可以通过以下步骤发现解决。1、日常投诉工单处理，对于用户反映无法上网的问题，要引起重视。2、通过用户详细位置，定位用户占用的小区，首先需要排除基站告警问题，若基站没有告警，观察该基站下所有小区近期的指标变化情况，主要是业务量是否有所减少，分组域业务掉话率和掉话次数是否突然恶化（有时恶化不明显，在日常指标监控中不容易发现，例如本例中分组域掉话率恶化后在0.5%左右，无线环境恶劣的小区也可能在这个水平，所以需要结合投诉工单处理定