爱立信文档
关于爱立信rbs_log文件的简单分析
农世钦
在rbs_log文件中记录了整个TG的所有软、硬件设备运行信息，通过查看、分析rbs_log文件，可以帮助我们及时发现并解决基站的隐性故障，从而降低设备的故障引起的退服率。虽然从事基站设备维护工作已有三年多，由于本人E文水平较低，通信理论知识基础差，对rbs_log文件未完全了解，对于爱立信rbs_log文件也只能作简单分析，根据日常维护工作中遇到的故障，现简单谈谈如何从rbs_log文件中定位出故障部件，缩小故障范围，最后排除故障。
相信大家都知道如何保存rbs_log文件了吧，不过在此为了照顾新手，还是有必要说一下：
一、首先连接OMT软件，读取IDB数据，如下图：
二、然后选择System界面，点击RBS2000，右键选择Display Log,如下图：
三、将会弹出一个等待画面，需要等待几分钟（与TG的所有设备多少有关），最后显示出rbs_log文件，也可以单个模块（DXU、TRU、ECU）进行保存。
简单说明一下rbs log文件的结构及内容：文件中包含DXU log、TRU log、ECU log三部分，文件中记录了一段时间内整个TG的DXU、TRU、ECU所有运行信息，但DXU、TRU、ECU掉电或重启将会重新刷新纪录。
在记录文件中，每行作为一个记录信息单位，如：
[90-01-01 00:00:00.034] NONAME debug_main.c:2492 TRACEH:No restart info中[90-01-01
00:00:00.034]信息记录的日期及时间，这个为特殊的日期时间，是系统重启的初始日期及时间，系统在完成自检后根据BSC的时钟重置BTS的日期及时间，如完成自检后日期时间为：[06-02-06 10:47:27.454]
因本人水平有限，不能对所有记录进行分析，一般情况下也只是为了处理故障，所以在分析rbs log文件时，根据记录的日期及时间只对存在故障的记录进行分析。
案例一：现在先以柳城西安基站为例，对RBS log进行分析：
1、故障现象：网优提供的2006年2月份基站BS fault中，西安基站存在CF.FC=2A 33，RU=40，对照故障代码表， CF2A为内部错误级别，FC 33为RX分集接收丢失。经与BSC核查，当前无任何隐性故障，现场未发现任何告警。
2、故障判断：产生RX分集接收丢失的原因有很多，因现场未发现任何告警，可能为曾经出现过的故障，产生此种现象的原因可能设备不稳定，硬件老化，天馈线接有头接触不良等。
3、分析RBS LOG记录文件：
1）文件中第4-87行全部为DXU自检重启信息，不用分析，从第88-117行，为DXU、TRU、ECU进初始化完成并正常工作，如第117行：[06-02-06 10:48:34.248] P_MPSS_MMI_HNDL mmi_main.c:581 TRACEH:MMI Indication for OPERATIONAL state ON中OPERATIONAL state ON表示RBS已经正常工作。
2）第124-127行
[06-02-09 16:18:07.612] OMS_HWU hwu.c:32615 FAULT: ANTENNA:1, raise i1a ATSR RXB SLI（蓝色字体指示故障单元，红色字体提示故障内容）
[06-02-09 16:18:07.630] OMS_RU_FH ru.c:55825 FAULT:RU:ANTENNA:1, raise i1a RXB SLI（蓝色字体指示可替换单元，红色字体提示故障内容）
[06-02-09 16:18:07.638] P_MPSS_MMI_HNDL mmi_main.c:581 TRACEH:MMI Indication for BS_ERROR state ON（向BSC发送请求的报告错误告警）
[06-02-09 16:18:08.084] OMS_SO_MAIN so.c:53813 FAULT:SO: CF, 0, raise, RX DIVERSITY LOST（错误告警信息内容，对象为CF级，出现RX分集接收丢失）
以上信息为一次告警过程记录。
3）第128行：[06-02-11 10:47:32.018] P_MPSK_CLOCK timeout_clock_main.c:395 TRACEH:Setting time: 06-02-11 10:47:34.000（时钟重设，存在的告警会刷新）
4）第130-133行，告警再次出现。
爱立信文档
4、通过对以上记录分析，确认RBS曾经在06-02-09 16:18:08.084及06-02-14 19:42:45.380出现过两次RX分集接收丢失告警。对照故障代码手册，参照RX分集接收丢失的处理方法，处理RX分集接收丢失故障，如果由于TRU引起的RX分集接收丢失，可继续对TRU log文件进行分析，更容易找出存在故障的TRU。
5、继续分析RBS LOG记录文件中的TRU部分：
1）TRU LOG记录中，如第140及148行：
[06-02-07 13:01:51.256] T_DCHT_3010 t_dcht_dnl.c:4154 TRACEH:MS Power state is locked!（移动台的发射功率锁定）
[06-02-07 13:02:16.690] T_DCHT_3010 t_dcht_dnl.c:4302 TRACEH:BS Power state is locked! （发射台的发射功率锁定）
这种情况下，TRU正常工作状态。
2)第259行：[06-02-08 10:47:32.986] P_MPSK_CLOCK timeout_clock_main.c:395 TRACEH:Setting time: 06-02-08 10:47:34.96（随DXU初始化完成后重设时间）
3)第1128行：
[06-02-09 16:18:07.582] OMS_HWU hwu.c:33071 FAULT: ATSR:2, raise i2a RX B SIGNAL LEVEL（TRU-2 LOG中出现i2a RX B SIGNAL LEVEL告警）
TRU-0、1、2、3的LOG中，只有TRU-2发现有FAULT: ATSR:2, raise i2a RX B SIGNAL LEVEL告警的故障信息，确认故障是由于TRU故障引起，对于这种当前无BS Fault告警的情况，建议更换TRU-2，以免出现故障时影响通话质量。
案例二：通过查找功能，直接查找包含“Fault”信息，以柳城社冲的Rbs log文件为例
1)如第1122-1129行（TRU-1 log），出现一次电压供应故障：[05-11-21 17:54:01.240] OMS_HWU hwu.c:33071 FAULT: PWU:1, raise i2a PA VOLTAGE SUPPLY
[05-11-21 17:54:01.260] OMS_RU_OBJ ru.c:112386 FAULT:RU:TRU:1, raise i2a PWU PA VOLTAGE SUPPLY
[05-11-21 17:54:01.286] P_MPSS_MMI_HNDL mmi_main.c:581 TRACEH:MMI Indication for FAULT state ON（告警状态打开）
[05-11-21 17:54:01.294] OMS_SO_MAIN so.c:55963 FAULT:SO: TRXC, 1, raise, VOLTAGE SUPPLY FAULT（报告告警内容）
[05-11-21 17:54:05.742] OMS_HWU hwu.c:33071 FAULT: PWU:1, cease i2a PA VOLTAGE SUPPLY
[05-11-21 17:54:05.764] OMS_RU_OBJ ru.c:112386 FAULT:RU:TRU:1, cease i2a PWU PA VOLTAGE SUPPLY
[05-11-21 17:54:05.792] P_MPSS_MMI_HNDL mmi_main.c:581 TRACEH:MMI Indication for FAULT state OFF（故障恢复）
[05-11-21 17:54:05.800] OMS_SO_MAIN so.c:55963 FAULT:SO: TRXC, 1, cease, VOLTAGE SUPPLY FAULT（报告恢复的告警内容）
2)RBS LOG文件中TRU-2 log部分，多次出现FAULT:SO: TRXC, 1, cease, VOLTAGE SUPPLY FAULT告警信息，并且由于FAULT:SO: TRXC, 1, cease, VOLTAGE SUPPLY FAULT，多次引起TRU复位如：[05-11-13 11:10:47.750] OMS_HWU hwu.c:33071 FAULT: PWU:2, raise i2a PA VOLTAGE SUPPLY
[05-11-13 11:10:47.768] OMS_RU_OBJ ru.c:112386 FAULT:RU:TRU:2, raise i2a PWU PA VOLTAGE SUPPLY
[05-11-13 11:10:47.792] P_MPSS_MMI_HNDL mmi_main.c:581 TRACEH:MMI Indication for FAULT state ON
[05-11-13 11:10:47.800] OMS_SO_MAIN so.c:55963 FAULT:SO: TRXC, 2, raise, VOLTAGE SUPPLY FAULT
[05-11-13 11:10:48.246] OMS_HWU hwu.c:32615 FAULT: PWU:2, raise i1a PA VOLTAGE SUPPLY
[05-11-13 11:10:48.248] OMS_HWU hwu.c:33071 FAULT: PWU:2, cease i2a PA VOLTAGE SUPPLY
爱立信文档
[05-11-13 11:10:48.276] OMS_RU_OBJ ru.c:111736 FAULT:RU:TRU:2, raise i1a PWU PA VOLTAGE SUPPLY
[05-11-13 11:10:48.278] OMS_RU_OBJ ru.c:112386 FAULT:RU:TRU:2, cease i2a PWU PA VOLTAGE SUPPLY
[05-11-13 11:10:48.294] OMS_SO_MAIN so.c:55387 FAULT:SO: TRXC, 2, raise, VOLTAGE SUPPLY FAULT I1A
[05-11-13 11:10:48.300] OMS_SO_MAIN so.c:55963 FAULT:SO: TRXC, 2, cease, VOLTAGE SUPPLY FAULT
[05-11-13 11:10:48.378] P_MPSS_MMI_HNDL mmi_main.c:581 TRACEH:MMI Indication for OPERATIONAL state OFF
[05-11-13 11:10:53.230] OMS_HWU hwu.c:32615 FAULT: PWU:2, cease i1a PA VOLTAGE SUPPLY
[05-11-13 11:10:53.234] OMS_HWU hwu.c:33071 FAULT: PWU:2, raise i2a PA VOLTAGE SUPPLY
[05-11-13 11:10:53.258] OMS_HWU hwu.c:33071 FAULT: PWU:2, cease i2a PA VOLTAGE SUPPLY
[05-11-13 11:10:53.266] OMS_RU_OBJ ru.c:111736 FAULT:RU:TRU:2, cease i1a PWU PA VOLTAGE SUPPLY
[05-11-13 11:10:53.270] OMS_RU_OBJ ru.c:112386 FAULT:RU:TRU:2, raise i2a PWU PA VOLTAGE SUPPLY
[05-11-13 11:10:53.288] OMS_SO_MAIN so.c:55387 FAULT:SO: TRXC, 2, cease, VOLTAGE SUPPLY FAULT I1A
[05-11-13 11:10:53.292] OMS_SO_MAIN so.c:55963 FAULT:SO: TRXC, 2, raise, VOLTAGE SUPPLY FAULT
[05-11-13 11:10:53.344] OMS_HWU mps_temp.c:185 TRACEH:TRLR093S (PLS-TRU/R8
CXC1121202_1.R8_12), START CAUSE: ORDERED_RESET, APPL. TYPE: 1（开始复位）
[90-01-01 00:00:00.034] NONAME debug_main.c:2492 TRACEH:No restart info
第1293-1310行出现告警后，引起TRU复位，复位信息从第1311行开始，到1361行结束，并完成初始化。
3)TRU-3 log文件中记录着与TRU-2存在同样的故障，经常出现FAULT:SO: TRXC, 2, raise, VOLTAGE SUPPLY FAULT故障，并引起TRU复位，会影响用户在通话过程中出现掉话现象，建议对存在这种故障现象的TRU进行更换，虽然在TRU-1中也出现过一次，但故障并未引起TRU复位，故没有必要进行更换。
从日常维护工作中得知，电压供给故障（FAULT:SO: TRXC, 2, raise, VOLTAGE SUPPLY FAULT）如果不及时更换，将会出现TRXC I2A 12（TX 输出功率超限）、TX I1B:12（TX 高温）、13（TX 输出功率超限）等故障。
以上只是部分常见故障的简单分析，其他故障可以使用同样的分析方法，仅供各位同事参考，如有不正之处，敬请指出，一起学习，共同进步！
