为客户上网感知保驾护航.docVIP

为客户上网感知保驾护航 ——记云浮G10网元PCU丢帧分析案例 案例背景 2011年，数据业务类投诉已超过基础类投诉成为通信类投诉首位；从2012年5月开始，云浮公司从上到下开展了“为客户上网感知保驾护航”的专项攻关，要求通过半年的专项攻关，能有效降低数据业务投诉比例，扭转移动网络上网在客户心目中速率低的形象。为此，网络优化中心领导和同事团结一致，通过优管理、清流程、抓质量等，对数据业务类问题进行刨根问底，为客户上网感知保驾护航，为移动网络正常运行、公司缔造卓越品牌提供了强有力的支撑。 二、问题案例描述 2012年6月17日7点30分，云浮自动监控系统提示一个红色告警信息，内容为：“YFM04B3掉帧严重，已影响客户手机上网感知，可能引起大规模投诉“。随即监控值班人员对相关设备进行检查，各类与上网相关设备均正常运行。 当天早上8点开始，网络投诉组收到云安县六都镇、云安县云安镇一带出现大面积上网投诉，主要都是反映手机无法上网、或上网速率特别慢，仅仅8点到9点，共收到六都镇、云安镇一带85张上网投诉单，对比6月16日全天收到六都镇、云安镇一带投诉单5张，整整多了17倍。同时监控系统依然提示红色告警未消除，情况迫在眉睫！ 面对这样的突发情况，投诉小组和监控小组及时把情况反馈网络优化专业科室，请求立刻协助处理。优化中心领导高度重视，随即成立突发问题处理小组，对问题展开分析定位。 突发问题处理小组查看告警详细信息：YFM04B3网元PCU下行掉帧数较高。按照流程，优化室兵分两路开始排查情况：第一组成员到达投诉地点，联系客户实地测试上网情况；第二组成员对投诉问题、指标告警进行关联性分析，展开头脑风暴，对问题原因进行分析定位。 第一组成员到达投诉点，现场利用设备测试，确实存在下载速率低、下载断流，严重的小区还出现无法浏览网页，收集出现下载异常的7个主小区（云安黄湾港2、云安六都开发区2、云安黄湾港1、云安黄湾港3、云安六都港3、云安黄湾港D2、云安六都港1），实地情况与客户反映的一致。 第二组成员对可能出现信息告警的原因展开讨论，并对覆盖的网元所有指标进行了分析，发现该BSC从17日7开始出现大量的PCU掉帧，掉帧数从原来的100多突增到40000以上，具体如下： DATE Period Exchid 接通率 下行PCU掉帧数 120617YFM04B3 98.14 107 120617YFM04B3 96.62 37623.00 120617YFM04B3 93.60 49988.00 120617YFM04B3 92.56 54322.00 120617YFM04B3 93.11 36571.00 120617YFM04B3 97.73 68121.00 分析与对策 分析方法： 对于小区掉帧数，正常范围为每小时100个，通过进入RPP板进行小区追踪出来的（ack DISCDL）和（ack DISCUL）是一个累积值，并不是小区的当前值，不过这两个值可以进行清零设置，然后在短时间内比如一个小时内继续追踪该值是否增长迅速并超出正常的范围值，进而判断是否存在故障。 每块RPP板都有自己独立的UNIX操作系统，下面介绍通过UNIX指令进行小区掉帧追踪的方法。其实如果对OPS语言运用非常熟悉的话也可以根据指令写成Script，以自己的风格输出追踪结果，在方便追踪的同时也及能提高工作效率。 RRPCP：RPINFO；（打印BSC激活的RP块数、RP编号）或用 DBTSP：TAB =RPSRPISUPERVS；（打印BSC激活且互为备份的RP块数、编号） TERDI：RP=“RP编号”；（RP入口指令） DISPLAY PROCESS MP_MAC ***；（打印以MP_MAC 开头的所有进程，对于该RP管理下的小区，都会对应着唯一的一个进程，查看该RP下的小区CELLIND为RP_CHHCELL_*** 分析思路: 对于追踪出来的高掉帧小区，如果大部分都集中在同一块RPP板上，则基本可以判定是RPP板故障引起，可通过指令查看RP的告警事件记录，看是否存在故障。如果RPP板没有任何告警事件记录，则有可能是RPP板的隐性故障引起，可以尝试闭塞RPP板后观察一段时间的指标变化。 DIRRP：RP=“RP编号”；（打印RP的告警事件记录） BLRPI：RP=“RP编号”，FORCED；（闭塞RP） 如果高掉帧小区是无规律地分布在不同的RPP板上，则有可能是小区自身的故障引起，可以进行掉包清零，观察短时间内是否迅速增长，且把小区赶至其他的RPP板，观察故障现象