基站可换设备故障处理载频常见故障说明F文中提到的故障都是客户返修中最常见的，也是返修中最有可能发生WQFault-Found”情况的。

通过了解造成这些故障的可能原因，用户就能在故障发生时确定故障背后的真正原因。

这将减少网络故障时间并提高系统可靠性。

1.1“DRI Not Detected"和"Waiting for Connection,,这两种故障都是由于MCU/MCUF不能与载频通信。

术语DRI是所有类型载频的软件总称。

在“DRI Not Detected”的情况下，从载频到MCU/MCUF的上行链路中断；而“Waiting for Connection”的情况则是从MCU/MCUF到载频的下行链路中断。

这些链路可能受多种因素影响，列举如下：•数据库错误一一MCU/MCUF试图寻找物理上不存在的載频。

•载频未加电或光纤的收发弄反。

・TCU上的光纤损坏或弄脏。

・CTU的背板接头或前面板有物理损坏。

•系统处于过渡状态，会在几分钟内口行恢复。

・TCU-B在”tcu_clock 0”后没有硬件"reset",在载频上按"reset"后会恢复。

•载频硕件故障，更换載频能正常。

・MCU/MCUF硕件故障，更换MCU/MCUF能够恢复正常。

・FMUX故障引起，更换FMUX后能够恢复。

1.2“Inhibited"该故障说明载频产生了一个严重告警。

当处理一个“Inhibited。

的载频时，应当记录下当前的告警。

•软件和硕件载频重启。

•更换敎频。

•其它原因。

1.3“Code Load Fail” 和U CEB Configuration Fail J,这两种故障说明在软件下载期间载频的固件和数字硕件间发生通信错误。

这可能由各种原因造成。

很多情况下该故障可通过重新下载软件清除，载频也可正常工作。

1.4“No HDLC reset pending”该故障通常是由于MCU/MCUF间的通信中断造成，而载频则可能处于软件下载过程中或正常工作状态。

该故障通常会在儿分钟内口行淸除，也可通过JNS”#戈频清除。

1.5“Code Load”这不是故障，只是表明软件下载仍在进行中。

一次完整的软件下载可能需耍15・20 分钟，但对「•戦频的过程只耍1分钟左右。

重要的是尽管可能发生错误，下载过程并没有彼中断。

在下载过程结束前不要在该器件上进行任何操作，否则会使载频坏掉。

1.6"Invalid Calibration Data”该故障是由于bay level校准未完成或校准数据在校准完成后未能正确保存，因此需岌对扱工山j U 辺行bay level怙们邛J处、是使用•个沖仰於芹尺序并手工键入命令。

校准软件工具常被用來最大限度地减少所需时间。

最常用的校准软件I••具是Xindy w和“'Back仁不幸的是这些工具可能无法正确保存校准数据，从而引起该告警。

最好在校准完成后手工保存并验证数据。

1.7“High call/set-up failure rate獰射频干扰或接收调测引起。

这通常是由数据库中射频接口或未优化的切换参数设置引起，也有可能是接收调测不正确引起。

在这些情况下最好试用其它频率/信道一段时间并比较统计结果。

完整的bay level校准也可能会提高基站的性能。

如果网络中正在发工这类问题• 就应进行一次彻底的频率检査以最大限度地减少射频干扰。

1.8DR1150 或“Receive Matrix Branch 1 Control Link Failure”该告警通常出现在Horizon Macro以及Mcell Macro类型的站上。

DRI 150告警表明IADU板子或SURF模块已经与载频失去联络或这些模块上有内部故障。

在发生内部故障的情况下，模块会在任意一条射频路径上出现过流状态的时候产生该告警，指示一个或多个LNA的故障。

啟人警还可能是由于到模块或裁频的连接老动；SURF 模块未加电：或机柜中的SURF/IADU板子故障引起。

2 MCU/MCUF常见故障说明2.1无LED指示这通常表明MCU/MCUF未加电。

这可能是由丁•电路保险被触发或板卡未正确插入插槽；也可能是由丁•引导程序(boot code)损坏。

为消除引导程序(boot code)损坏的可能性，应确保当设备正在进行引导程序(bootcode)更新时不耍切断电源。

当引导程序(boot code)更新，或写入非易失性内存，可以看到红色和绿色的LED快速交替闪烁。

2.2不能进行TTY接入这通常是由丁MCU/MCUF与PC或终端的连接接厂I故障引起，也可能是由丁•引导程序(boot code)损坏。

为消除引导程序(boot code)损坏的可能性，应确保当设备正在进行引导程序(boot code)更新时不要切断电源。

当引导程序(boot code)更新，或写入非易失性内存，可看到红色和绿色的LED快速交替闪烁。

2.3“Waiting for sync to initialize^^出现在TTY这一问题可能由于MCU/MCUF安装不牢固或遭损坏的引导程序(boot code)所致。

为防止软件被损坏，当MCU/MCUF软件正在更新，或者正在写入NV-RAM 时必须确保不要让MCU/MCUF掉电。

这一过程可通过面板上LED灯红绿快速变换识别。

2.4MCU/MCUF连续不断的重新启动遭损坏的引导程序(boot code)或BTS和BSC之间的传输中断都会导致这一问题。

为防止引导程序(boot code)遭损坏，当MCU/MCUF软件正在更新，或者正在写入NV-RAM时必须确保不要让MCU/MCUF掉电。

这一过程可通过面板上LED灯红绿快速变换识别。

如果是BTS不能与BSC联系，MCU/MCUF将每30 分钟自启动一次。

这是正常情况。

2.5“FMUX Loopback Failure”这个告警指示FMUX卡认为光纤连接不能正常工作。

这可能由丁•以下情况造成：FMUX卡没插好、FMUX卡硬件故障、FMUX掉电、光纤安装有问题或折断等。

2.6“No Redundant LinX”主备MCU/MCUF不能正常通信将引发这一告警。

如果备边MCU/MCUF刚刚加上电，需要等待30分钟去预热这块板。

这是由于板内的高精度的晶体振荡器需耍一个稳定的温度才能工作。

当然这一告警也可因备用边的MCU/MCUF故障所导致。

2.7“PCMCIA Failure”PCMCIA卡插入不当或不匹配的卡将造成这一告警。

正确插入时，PCMCIA卡将与MCU/MCUF面板平齐，并11只有摩托罗拉认可的卡能在这里被使用。

基站工程师处理CTU和TCU-B的步F面将概要地介绍判断问题的方法，包括一些必耍的步骤。

这些步骤是作为其他一些方法的补充，而不是取代它们。

如果经过这些步骤判断，问题依然存在则该设备需要返修。

3.1 基站工程师执行的一般性检査3.1.1验证所有机柜内的设备都加上电，也要检查TCU的插头极性。

3.1.2验证TCU收发线缆的正确连接，包括线缆和连接的情况，例如是否清洁和可靠。

3.1.3验证TCU-B光纤的正确连接，连接是否紧密，并且没有碎屑。

这可以通过以下步骤做到：拔出光纤然后用吹气球向MCU/MCUF和TCU的光纤连接口吹风，并用软布擦拭光纤的端头，然后牢固插入。

3.1.4验证数据库和实际硬件安装相一致。

disp_equip X full （在MCU的MMI提示符符下键入，这里的X是站号）3.1.5验证MMI提示符出现在载频的RSS端口，如果不是，请验证这个载频的电源开关是否打开。

3.1.6验证LED的状态，如果不是亮的，请验证这个载频的电源开关是否打开。

3.1.7验证这个载频没有被锁住。

State X drj * * （从MCU上的MMI提示符下键入，这里X是站号，Y是DRI 号）Unlock X dri Y Y（从MCU±的MMI提示符下键入，这里X是站号，Y是DRI号）这将解锁这个DRL3.1.8检查基站的告警。

disp_act_al X （从OMC上的MMI提示符下键入，这里X是站号）3.2“DRI NOT DETECTED^ 和^Waiting for Connection,,3.2.1执行在3.1段中的一般性检查，保证系统运行。

3.2.2如果发生“ Waiting for Connection”错误，等待5・10分钟去观察这个故障是否自动消除。

3.2.3INS这个硬件ins X dri Y Y （从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号）3.2.4硬件reset这个载频3.2.5对于TCU-B的检查，清洁所有光纤连接口。

对于CTU,检查背板或面板的物理损伤。

如果面板弯曲或安装不到位，那么背板不可能正确连接。

3.2.6如果上述步骤不能清除这故障，请试着和同一基站中的载频调换，然后判断是槽位的问题还是载频问题。

3.2.7判断数据库是否最近被修改，如果是，确保数据库和实际硬件安装一致。

注：可能为FMUX板子的断口故障，可先将主备用交换测试也可能为MCU/MCUF故障引起，同样可以swap到备用主处理器进行性能测试來判断主处理器板子的性能！3.3“Inhibited”3.3.1执行在3.1段中的一般性检查，保证系统运行，特别注意所有的告警。

3.3.2打开MCU/MCUF的告警模式,INS这个设备，并且在基站正常工作后，记录所有告警。

Mode_alarm X on或en_al X （在MCU上的MMI提示符下键入，这里的X是站号）Ins X dri Y Y （从MMI提示符下键入，这里X是站号，丫是DRI号）3.4“Code Load Fail” 和“CEB Configuration Fail”3.4.1执行在3.1段中的一般性检查，保证系统运行。

3.4.2INS这块载频。

Ins X dri Y Y （从MMI提示符下键入，这里X是站号，丫是DRI号）3.4.3等待10-15分钟的软件下载。

3.4.4如果这个故障再次出现，重启载频。

ReseLdev X dri Y Y （从MMI提示符下键入，这里X是站号，丫是DRI号）3.5“No HDLC reset pending"3.5.1执行在3.1段中的一般性检查，保证系统运行。

3.5.2INS这个载频ins X dri Y Y （从MMI提示符下键入，这里X是站号，丫是DRI号）3.5.3等待10-15分钟的软件下载。

3.6“Code Load"3.6.1不进行任何操作，等待软件下载的完成。

如果载频在软件下载过程中被重启或者掉电，可能造成永久性的软件损坏。

正常的软件下载过程需要花费20分钟完成，具体依赖于这一基站所需的软件大小。