FDD-LTE--LTE基站出现RRH瞬断故障案例分析.doc

2014年12月 ASB FTM Dec.2014 PAGE 13 2014年11月 ASB FTM Nov.2014 PAGE 1 LTE基站出现RRH瞬断故障案例分析 上海贝尔股份有限公司FTM团队 摘要：10月22日17:05至17:12左右，某地LTE基站出现部分RRH瞬断故障，RRH发生退服后自行恢复服务，平均持续时间约1分钟左右。因故障持续时间较短，且临近下班，导致该故障未能及时发现. 关键词：FDD LTE; RRH瞬断 1 故障现象/功能介绍 10月22日17:05至17:12左右，某地FDD LTE基站出现部分RRH瞬断故障，RRH发生退服后自行恢复服务，平均持续时间约1分钟左右。因故障持续时间较短，且临近下班，导致该故障未能及时发现。 直至第二天，接到现场反馈故障信息后，上海贝尔现场技术人员立即向公司的二线支持部门申请技术支持，同时安排人员开始故障信息的收集工作。在问题分析的过程中，从分公司到总部领导都十分重视，组织了无线技术支援中心召开电话会议，分析故障可能原因，并派研发专家赶赴现场。 根据统计分析，本次小区退服涉及基站102个，退服后的RRH中断约1分钟左右后继续正常工作，经统计涉及到退服的基站分散在15个BBU池内，且BBU池中，并不是所有的BBU下面下挂的RRH都出现退服现象，没有明显的规律，退服小区的统计较为分散. 2 原因分析/原理介绍 本次批量基站发生的故障，告警信息为IK4006006 – RFM COMM FAIL，该告警表示基站控制板eCCM在连续30秒的时间内没有收到RRH的心跳信号，就会认为RRH已经退出了服务，并产生IK4006006告警。根据告警信息和现场工程师收集了相关log信息，研发部门进行了分析，我们认为外部因素也可能引发故障的发生，故需要寻找并检查网络拓扑中的相关节点，是否能够发现一些线索，如传输光路出现误码、瞬断等都可能引起心跳丢失。同时，我们也不排除产品自身问题的可能性。因此我们从产品自身和外部环境两个方面同时着手进行了深入仔细的排查。 2.1产品自身原因 在接到故障信息后，上海贝尔现场技术人员在第一时间收集了日志文件，并提交上级技术支持和研发人员分析。下面我们将从uptime、日志文件，软件版本，产品批次这四个方面进行分析： 2.1.1日志文件分析 C板日志文件分析 从C板的pltf.Swlogs中我们发现，有errorno=104的错误信息，该信息表明因为RRH关闭和BBU的socket，而导致BBU给rrh下发reset request。 pltf.SwLogs#1： //socket关闭，pathmapping出错。 c[2014/10/22 09:09:25.568780858] sev:INFO src:SocketThread runST():nbytes = -1 RFM-1-1 socket = 177 = P[2014/10/22 09:09:25.568821354] sev:INFO src:SocketThread runST():errorno = 104 // 104 /* Connection reset by peer */ 2014/10/22 09:09:25.662968341] sev:INFO error:0x105063 src:PATHMAP-1-1:: //reset RRH RO only： socket-1. (socket-1 代表此时C板和RRH的socket已经关闭) 2014/10/22 09:10:12.560383837] sev:INFO error:0x10388e src:RFM-1-1:: [ OamRfmPRO.cc / startCrashDumpChore / 4593 ]: Socket available for crashdump. 2014/10/22 09:10:12.560411854] sev:INFO error:0x10388e src:RFM-1-1:: [ OamRfmPRO.cc / startCrashDumpChore / 4598 ]: Create Crashdump Chore. : c[2014/10/22 09:09:41.549058866] sev:INFO src:Soc