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

1、lte基站出现rrh瞬断故障案例分析上海贝尔股份有限公司ftm团队摘要：1()月22 0 17:05至17:12左右，某地lte基站出现部分rrh瞬断故障，rrh发生退服后自行恢复服务，平均持续时间约1分钟左右。因故障持续时间 较短，且临近下班，导致该故障未能及时发现.关键词:ldd lte; rrh瞬断1故障现象/功能介绍10月22日17:05至17:12左右，某地fdd lte基站岀现部分rrh瞬断故 障，rrh发生退服后自行恢复服务，平均持续时间约1分钟左右。因故障持续 时间较短，且临近下班，导致该故障未能及时发现。肓至第二天，接到现场反馈故障信息后，上海贝尔现场技术人员立即向公司 的二

2、线支持部门中请技术支持，同时安排人员开始故障信息的收集工作。在问题 分析的过程中，从分公司到总部领导都十分重视，组织了无线技术支援中心召开 电话会议，分析故障可能原因，并派研发专家赶赴现场。根据统计分析，本次小区退服涉及基站102个，退服后的rrh中断约1分 钟左右后继续正常工作，经统计涉及到退服的基站分散在15个bbu池内，且 bbu池中，并不是所有的bbu下而下挂的rrh都出现退服现象，没有明显的 规律，退服小区的统计较为分散.2原因分析/原理介绍木次批量基站发生的故障，告警信息为ik4006006 - rfm comm fail,该 告警表示基站控制板eccm在连续30秒的时间内没有收到

3、rrh的心跳信号， 就会认为rrhq经退出了服务，并产牛ik4006006告警。根据告警信息和现场 工程师收集了相关log信息，研发部门进行了分析，我们认为外部因素也可能引 发故障的发生，故需要寻找并检查网络拓扑中的相关节点，是否能够发现一些线 索，如传输光路出现误码、瞬断等都可能引起心跳丢失。同时，我们也不排除产 品自身问题的可能性。因此我们从产品自身和外部环境两个方而同时着手进行了 深入仔细的排查。2.1产品自身原因在接到故障信息后，上海贝尔现场技术人员在第一时间收集了日志文件，并 提交上级技术支持和研发人员分析。下面我们将从uptime.日志文件，软件版本, 产甜批次这四个方面进行分析：

4、2.1.1日志文件分析 c板日志文件分析从c板的pltf.swlogs中我们发现，有errorno= 104的错误信息，该信息表明 因为rrh关闭和bbu的socket,而导致bbu给rrh下发reset request pltf.swlogs#1 :/socket 关闭,pathmapping 出错。c2014/10/22 09:09:25.568780858 sev:info src:socketthread runst():nbytes = -1 rfm-1-1 socket = 177=p2014/10/22 09:09:25.568821354 sev:info src:socket

5、thread runst():errorno = 104/ 104 /* connection reset by peer */2014/10/22 09:09:25.662968341 sev:info error:0x105063 src:pathaaap-1-1:/reset rrh ro only : socket-1 (socket代表此时 c 板和 rrh 的 socket 已经关闭)2014/10/22 09:10:12.560383837 sev:info error:0x10388e src:rfm-1-1:oamrfmpro.cc / startcrashdumpchore

6、 / 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.:c2014/10/22 09:09:41.549058866 sev:info src:socketthread runst():nbytes = -1rfm-1-1 socket = 176o p2014/10/22 09:09:41.54910174

7、6 sev:info src:socketthread runst():errorno = 104 c2014/10/22 09:10:13.33951961 刀 sev:info src:socketthread runst():nbytes = -1 rfm-1-1 socket = 175t p2014/10/22 09:10:13.339560833 sev:info src:socketthread runst():errorno = 104i竅 2014/10/22 09:10:40.219790782 sev:info error:0x10384a src:rfm-1 -1:oa

8、mrfmresetchore.ee / performstep / 594 :rfm-1 -1: send reset req: perf ormstep (): reset rfm ro only: socket-1 r w2014/10/22 09:12:07.246920023 sev:info src:rfm-1-1 radio de/activation result:actionld=41, status=0x0, errcause=0x0!sam网管日志文件分析网管日志文件时间点和c板trace分析结果一致(c板、b板上时间+8小时 为sam时间)，也表明由于cell outag

9、e,然后bbu给rrh下发lra reset,但 是sam只记录所有enb网元事件，并不能记录事件原因，所以sam相关信息 仅供参考。wed oct 22 17:09:25 cst 2014 cell outage start (cello) type : communications alarmwed oct 22 17:09:27 cst 2014 node is son misaligned => none notification can be handledobject change cause additional text: antenna-mapping (cello,

10、rrh1100)wed oct 22 17:10:46 cst 2014ik4905009 lra reset (rrh1100)b板日志文件分析经过统计发现b板事发时并未重启，而且如果b板发生重启，不可能在1 分钟内恢复。从b板的日志文件中我们只发现了当时cell delete和reconfigure相 关信息，而没有产生cell delete的原因。1)两块b板uptime均为超过51天。2 )两块b板的三个dsp均显示小区delete和activehdbg.swlogs#0 :12014/10/22 09:09:06.882140960 dsp_a (2963;7;499)| cif_s

11、tartup_ce_status =cif_cell_config_delete_ended2014/10/22 09:12:12.958192220 dsp_a (1091;4;763) | cell.preconfig received: cell status = 3 - com ce state = 2 - cif startup ce status = 9ij2014/10/22 09:12:12.959198900 dsp_a (1091;4;900) | cif_startup_ce_status =cif_global_config_rsp_senti l2014/10/22

12、09:12:12.960193680 dsp_a (1091;6;757) | c1f_startup_ce_status = cif_cell_config_rsp_prepared2014/10/22 09:12:12.962186080 dsp_a (1091;7;953) | cif_startup_ce_status =cif cell config active - com ce state = ce active(2) rrh日志文件分析rx2container=7 power=4302014-10-22 09:11:08.0000067cpag0x1010003grpsized

13、own=6 grpsizeup=62014-10-22 09:11:08.0000067cpag0x1010004carriercfg ack_bitmap is 02014-10-22 09:11:08.0000067cpag0x1010004carriercfg ack bitmap is 02014-10-22 09:12:40.0000027cpag0x1010004carriercfg ack_bitmap is 02014-10-22 09:12:40.0000027cpag0x1010004txfreq=1867500 txcontainer=0 tx2container=0ca

14、rriercfg ack_bitmap is 0受rrh硬件限制，rrh内存有限，导致事故发生时的历史log被冲掉，故 没有rrh trace可供分析。但是从rrh eventlog发现当时岀现activate port reports 随后 disable/enable 小区。2014-10-22 09:09:59.0000065cpag0x1020004activate port report2014-10-22 09:10:15.0000098cpag0x1020004activate port report2014-10-22 09:10:31.0000098cpag0x1020004

15、activate port report2014-10-22 09:10:47.0000098cpag0x1020004activate port report2014-10-22 09:11:03.0000099cpag0x1020004activate port report2014-10-22 09:11:08.0000067cpag0x1010003carriercfg: index=1 state=disablerxfreq=1772500 rx1container=1carriercfg: index=1 carriertype=5the state of this carrier

16、 is disable, thethe state of this carrier is disable, thethe state of this carrier is enable, thethe state of this carrier is enable, the2.1.2软件版本分析10刀22日发生小区退服的这102个bbu使用的load并不集中在某个load 上，软件版本信息具体如下：load infobbu no.lr1303 d23 e002021lr1303 d33 e003024lr1303 d40 e006304lr1303 d60 e00830932.1.3硬件批次分

17、析检查c板，b板，rrh的serial number,没发现什么规律，同一批次的 板件在问题当天既有发生故障的，也有止常的，分析如下： c板批次分析:从下面c板的serial number可以看出同一个批次的c板既有发生故障的, 也有当时正常的，如下表中“yp1349 （表示2013年第49周生产）”：1022故障状态（c板）site nameserial number发生问题的bbutahuanbeiz01 b390950 ayp134906390发生问题的bbutahuanbeiz01 b390952 ayp134906393止常tahuanbeiz01 b390953 byp134906

18、3b7正常tahuanbeizol b390954 cyp1349063b5发生问题的bbutahuanbeizol b390955 cyp13440dada正常tahuanbeiz01 b390996 ayp1349063b8发生问题的bbutahuanbeiz01 b391002 ayp1349063b4正常tahuanbeiz01 b391003 ayp1349063a2发生问题的bbutalianhuaz02 b391009 cyp134906396表 c板状态 b板批次分析:从b板serial number中也可以看出同一批次的b板在事发当吋既有下挂小 区全正常的，也有

19、下挂的小区发生故障的，比如说下表中的“yp1343, yp1433” 这两个批次：1022故障状态（b板）site nameserial number正常tapantuz01 b391033 cyp134310930该b板下小区发生问题taxiangpingz02 b390918 byp13410a241正常taxiangpingz02 b390919 ayp134414321该b板下小区发生问题taxiangpingz02 b390920 ayp13431160b该b板下小区发生问题taxiangpingz02 b390921 byp1344140c4该13板下小区发牛问题taxiangpi

20、ngz02 b390922 byp13440c40b该b板下小区发生问题taxiangpingz02 b390923 byp134413f4d该b板下小区发生问题taxiangpingz02 b390924 ayp1343111ea正常taxiangpingz02 b390925 byp1343117f1该b板下小区发生问题taxiangpingz02 b390928 byp1343117a2正常taxiangpingz02 b390932 ayp134413dd3该b板下小区发生问题taxiangpingz02 b390934 byp134311590该b板下小区发生问题taxiangpin

21、gz02 b391006cyp1344144de该b板下小区发生问题xadadengz01 b391462 cyp13440bf70止常xadadengz01 b391462 cyp1344142ad该b板下小区发生问题xadadengz01 b391463 cyp1344140dd正常xadadengz01 b39146<cyp13431128d该b板下小区发生问题xadadcngz01 b391465 cyp134414500该b板下小区发牛问题xadadengz01 b391466 cyp134414428止常xadadengz01 b391467 cyp134311522表2.1

22、.3.2 b板状态 rrh批次分析:从rrh的serial number中也可以看出同一批次的rrh在事发当时既有正 常的，也有发生故障的,如下表中的“yp1347,yp1408",特别是“yp1408”批次还是挂在同一个bbu (tahuanbeizo 1 _b391002_a)下的rrh,其表现完全 不一样：1022故障状态(rrh)serial number发生问题的rrhtahuanbeiz01 b391002 ayp13471586a发生问题的rrhtahuanbeiz01 b391002 ayp13471587f发生问题的rrhtahuanbeizol b391002 a

23、yp134715858发生问题的rrhtahuanbeiz01 b391002 ayp140805809发生问题的rrhtahuanbeiz01 b391002 ayp140800ee3正常tahuanbeiz01 b391002 ayp1408057f7正常tahuanbeiz01 b391003 ayp134715761正常tahuanbeizol b391003 ayp1347157c5正常tahuanbeizol b391003 ayp134715668表 rrh 状态2.1.4 c 板 uptime 分析通过11月1日16:40 enbtool全网扫描结果发现，发生过

24、小区退服的c板 uptime有一定规律，均接近59days 17hours,即距离10月22日发生小区退服时 间约50dayso而其他地市没有一个站的uptime超过45天，这点可以解释为什么 其他地市没有出现批量小区退服。一共有123块c板在10月20日uptime接近50天，其中102块发牛批量小 区退服。可见,uptime接近50天时,发生小区退服几率为102/123=83%。typeuptime to 50 days (oct 20th )eccmu103eccm220total123表 c板白勺uptime情况挑选3个叩time为58天、53天的站，均发现在23号、28

25、号都发生同样的 小区退服。(与22 fi大批量小区退服现象极其一致，只有4006006 rfm comm fail和cell down alarm)这也从侧面证明uptime和cell down有关系。ipaddruptimecell down658 days, 16:3910月23日1053 days, 16:3510月28日053 days, 16:0910 月 28 口表ip地址的uptime情况但是，我们会继续通过lab验证和查看代码，从而确认uptime是否是cell down 的直接原因。从现象来看，u

26、ptime与cell down有较强的和关性，但是由于关键日志文件 丢失，导致我们目前述不能定位是什么原因导致rrh关闭和bbu的socketo2.2外部环境根据故障现象同一批基站同吋发生同类型故障，我们认为外部因素也可能引 发故障的发生，故需要寻找并检查网络拓中的相关节点，是否能够发现一些线索, 如传输光路出现误码、瞬断、电压的瞬间变化等都可能引起心跳丢失。因此我们 从光传输连接、rrh供电、网管操作、现场环境勘探、网络风暴、gps失步这 6个方面进行了逐步排查。2.2.1光传输连接根据mcrrh的命令rtcshow可看出rrh当前运行的时间(uptime)。自 2014年10月22 下午5

27、时左右发生故障，到enb tool执行的时间10月31日 下午5吋，约为9天。若故障发生吋，rrh会重启，那么rrh到脚本执行吋应 该运行9天左右。下表为发生问题的rrh的uptime吋长统计。从中可以看出，在10月22日 有重启的站仅为33个，而324个站的运行时间为58天。说明当时rrh并没有 重启。另外，历史告警显示当时并没有cpri los/lof告警，这也说明故障发生时, rrh与bbu z间的l1链路是ok的。current running dayscount of rrh0622312458493310121141211412032112513323643733863944114

28、2143444245346249256158324612total44传输情况2. 2. 2rrh供电不稳在tdd项目中也曾经发生过因为rrh供电不稳，发生过大面积小区退服事 件，因此我们决定在实验室模拟rrh供电不稳环境。实验结果表明，当rrh因 为欠压而断电时，rfm comm fail和cpri相关的告警会同时出现，与当时仅 有rfm comm fail告警不符。说明当时rrh供电正常。2.2.3网管端误操作现场核对了故障前sam中的操作记录，未发现有在网管上做数据修改的记 录，故小区瞬时退服也非修改数据引起。2. 2. 4现场环境挑选3个bbu （下挂15个rrh）,实

29、地检查硬件连接环境。其中，xamaxiangpp2_b391431 _a站6个扇区rrh安装在铁塔。 xamaxiangpp2_b391515_b站三个rrh安装在屋顶，使用交转直屯源模块。 xaxindianz01_b391447_b站1-3扇区rrh安装在屋顶，46扇区rrh安装在 铁塔。区域bbu 池（ipran 节点）名称bbu数量下挂rrh站点名称站号rrh数量cell down翔安马巷pp21翔安区马巷平安保险xamaxiangpp2 b391431 a3ccll3翔安翔安区翔安同民医院xamaxiangpp2 b391431 a3cel 14, 5, 6翔安1翔安区西坂西亭xam

30、axiangpp2 b391515 b3celll,2翔安新店模块局z011翔安区祥吴宋厝xaxindianzol b391447 b3cell2, 3翔安翔安区新店祥吴xaxindianzol b391447 b3cel 16表现场环境情况实地考察结果未发现bbu池、a设备、b设备、rrh安装不符合规范, 同时扇区覆盖区域等也没有明显规律。2.2.5网络风暴曾经在俄罗斯lte项目中发生过因网络风暴导致某些端口被堵塞，同一吋 刻批量socket被关闭，因此我们也怀疑网络风暴是导致这次故障的原因，下面是 我们调查分析情况：a.根据enbtool 11月1 口的数据，全网181个在线

31、基站，所有eccmu/eccm2跟核心网相连网口的vian id都是35,网关mac都为 00:00:00:00:00:01 ovian是隔离广播域的，即隔离网络风暴，不同vian id之间的广播报文是 不能互相通信的，例如，vian 1的广播报文不会被转发到vian 2.所有181个基 站都在同个vian 35,那么当有网络广播风暴时，所有基站都会收到大量的广播 报文。b.分四个时段，统计10月22日厦门全网s1带宽利用率。结果均为0.005% 左右,事发当天无明显异常。其中,tawuxianz01_b390988_a,带宽利用率为0.1% 左右。经调查，该站覆盖区域为学校（同安区五显和同安

32、区育才中学），lte 使用率高。带宽利用率高也属正常。站点14:00-15:0015:00-16:0016:00-17:0017:00-18:00tawuxianz01 b390988 a0.000850.001280.0003920.00177表网络风暴情况2. 2. 6gps时钟失步如果gps时钟失步，不但会出现rrh ik4006006,而且b板也会down掉, 从历史告警看，没有发现b板down的告警，并且也没有gps相关告警出现。 可以排除失步引发问题的可能性。经过gps、研发与第三方对以上总总分析，终于确认了根本原因是：mc-rrh底层用的是vxworks的操作系统，

33、在lr13.3里面的vxworks 6.9 版本有一个bug会导致tcp stack的溢出。vxworks在6里面开始将系统时间存 储单位从uint32修改到uint64,但是在某些地方忘记修改，导致某种情况下 仍然会用uint32来存储时间导致溢此 所以，当49天17小时之后，mc-rrh 会在is的时间里面激活tcp keep live,而这个动作的间隔时间是75秒钟。在 没有得到bbu的ack之后，关闭socket会最终导致socket重建，从而造成 mcrrh重启。3解决方法/配置步骤最终解决方案为lr14版本解决，目前采用workaround的方式临时解决, 其实现原理：1) enb

34、tool会扫描全网基站，当eccm的uptime大于或等于40天且是 mc-rrh站点吋，该站点的所有mc-rrh会被几乎同时重启。2 )如果当前eccm的叩time满足40天且所有mc-rrh被enbtool重启后, enbtool会保存当前的uptime,再过40天后，会将该站所有mc-rrh再重启手动运行方式必须固定每周的某天执行一次，例如，固定每周五执行一次java -jar ./enbtool.jar f ./ipjist-p ./reset_mcrrh_to_avoid_faulty_perties -b 0x10 -c 10 -n 350自动运行方式利用crontab自动调用enbtool,例如，每周五凌晨2点，crontab自动调用 enbtool来扫描全网例如，执行crontab -e,添加如下命令，表示1月、11月、12月的每个周五 的凌晨2点，自动调用enbtool执行该wa0 2* 11,12,1 5 cd /opt/5620sam/auxserv