基站维护经验基站可换设备故障处理

1、百度文库基站可换设备故障处理1载频常见故障说明/下文中提到的故障都是客户返修中最常见的，也是返修中最有可能发生“N-Fault-Found”情况的。通过了解造成这些故障的可能原因，用户就能在故障发生时确定故障背后的真正原因。这将减少网络故障时间并提高系统可靠性。1.1"DRINotDetected和“WaitingforConnection”这两种故障都是由于MCU/MCUF不能与载频通信。术语DRI是所有类型载频的软件总称。在“DRINotDetected的情况下，从载频到MCU/MCUF的上行链路中断；而"WaitingforConnection的'情况则是从M

2、CU/MCUF到载频的下行链路中断。这些链路可能受多种因素影响，列举如下：?数据库错误MCU/MCUF试图寻找物理上不存在的载频。?载频未加电或光纤的收发弄反。?TCU上的光纤损坏或弄脏。?CTU的背板接头或前面板有物理损坏。?系统处于过渡状态，会在几分钟内自行恢复。?TCU-B在“tcu_clock0”后没有硬件"reset”，在载频上按"reset”后会恢复。?载频硬件故障，更换载频能正常。?MCU/MCUF硬件故障，更换MCU/MCUF能够恢复正常。?FMUX故障引起，更换FMUX后能够恢复。1.2 "Inhibited”该故障说明载频产生了一个严重告警。当

3、处理一个"Inhibited的”载频时，应当记录下当前的告警。浜件和硬件载频重启。/独换载频。现它原因。111.3 "CodeLoadFail和“CEBConfigurationFail”这两种故障说明在软件下载期间载频的固件和数字硬件间发生通信错误。这可能由各种原因造成。很多情况下该故障可通过重新下载软件清除，载频也可正常工作。1.4 "NoHDLCresetpending”该故障通常是由于MCU/MCUF间的通信中断造成，而载频则可能处于软件下载过/程中或正常工作状态。该故障通常会在几分钟内自行清除，也可通过“INS”载频清除。1.5 "CodeLo

4、ad”这不是故障，只是表明软件下载仍在进行中。一次完整的软件下载可能需要''15-20分钟，但对于载频的过程只要1分钟左右。重要的是尽管可能发生错误，下载过程并没有被中断。在下载过程结束前不要在该器件上进行任何操作，否则会使载频坏掉。1.6 "InvalidCalibrationData”该故障是由于baylevel校准未完成或校准数据在校准完成后未能正确保存，因此需要对接收进行重调。进行baylevel校准最可靠的方法是使用一个简单的终端程序并手工键入命令。校准软件工具常被用来最大限度地减少所需时间。最常用的校准软件工具是“Cindy和“Back：不幸的是这些工具可

5、能无法正确保存校准数据，从而引起该告警。最好在校准完成后手工保存并验证数据。1.7 "Highcall/set-upfailurerate”射频干扰或接收调测引起。这通常是由数据库中射频接口或未优化的切换参数设置引起，也有可能是接收调测不正确引起。在这些情况下最好试用其它频率/信道一段时间并比较统计结果。完整的baylevel校准也可能会提高基站的性能。如果网络中正在发生这类问题，就应进行一次彻底的频率检查以最大限度地减少射频干扰。1.8 DRI150或“ReceiveMatrixBranch1ControlLinkFailure”该告警通常出现在HorizonMacro以及Mcel

6、lMacro类型的站上。DRI150告警表明IADU板子或SURF模块已经与载频失去联络或这些模块上有内部故障。在发生内部故障的情况下，模块会在任意一条射频路径上出现过流状态的时候产生该告警，指示一个或多个LNA的故障。该告警还可能是由于到模块或载频的连接松动；SURF模块未加电；或机柜中的,SURF/IADU板子故障引起。2 MCU/MCUF常见故障说明2.1 无LED指示/这通常表明MCU/MCUF未加电。这可能是由于电路保险被触发或板卡未正确插入插槽；也可能是由于引导程序(bootcode)损坏。为消除引导程序(bootcode)损坏的可能性，应确保当设备正在进行引导程序(bootcod

7、e)更新时不要切断电源。当引导程序(bootcode)更新，或写入非易失性内存，可以看到红色和绿色的LED快速交替闪烁。2.2 不能进行TTY接入这通常是由于MCU/MCUF与PC或终端的连接接口故障引起，也可能是由于引导程序(bootcode)损坏。为消除引导程序(bootcode)损坏的可能性，应确保当设备正在进行引导程序(bootcode)更新时不要切断电源。当引导程序(bootcode)更新，或写入非易失性内存，可看到红色和绿色的LED快速交替闪烁。2.3 "Waitingforsynctoinitialize出现在'TTY这一问题可能由于MCU/MCUF安装不牢固或

8、遭损坏的引导程序(bootcode)所致。为防止软件被损坏，当MCU/MCUF软件正在更新，或者正在写入NV-RAM时必须确保不要让MCU/MCUF掉电。这一过程可通过面板上LED灯红绿快速变换识别。2.4 MCU/MCUF连续不断的重新启动遭损坏的引导程序(bootcode)或BTS和BSC之间的传输中断都会导致这一问题。为防止引导程序(bootcode)遭损坏，当MCU/MCUF软件正在更新/或者正在写入NV-RAM时必须确保不要让MCU/MCUF掉电。这一过程可通过面板上LED灯红绿快速变换识别。如果是BTS不能与BSC联系，MCU/MCUF将每30分钟自启动一次。这是正常情况。2.5

9、"FMUXLoopbackFailure”这个告警指示FMUX卡认为光纤连接不能正常工作。这可能由于以下情况造成：FMUX卡没插好、FMUX卡硬件故障、FMUX掉电、光纤安装有问题或折断等。2.6 "NoRedundantLink”主备MCU/MCUF不能正常通信将引发这一告警。如果备边MCU/MCUF刚刚加上电，需要等待30分钟去预热这块板。这是由于板内的高精度的晶体振荡器需要一个稳定的温度才能工作。当然这一告警也可因备用边的MCU/MCUF故障所导致。2.7 "PCMCIAFailure”PCMCIA卡插入不当或不匹配的卡将造成这一告警。正确插入时，PCMCI

10、A卡将与MCU/MCUF面板平齐，并且只有摩托罗拉认可的卡能在这里被使用。3 基站工程师处理CTU和TCU-B的步骤下面将概要地介绍判断问题的方法，包括一些必要的步骤。这些步骤是作为其他一些方法的补充，而不是取代它们。如果经过这些步骤判断，问题依然存在则该设备需要返修。3.1 基站工程师执行的一般性检查3.1.1 验证所有机柜内的设备都加上电，也要检查TCU的插头极性。3.1.2 验证TCU收发线缆的正确连接，包括线缆和连接的情况，例如是否清洁和可靠。3.1.3 验证TCU-B光纤的正确连接，连接是否紧密，并且没有碎屑。这可以通过以下步骤做到：拔出光纤然后用吹气球向MCU/MCUF和TCU的光

11、纤连接口吹风，并用软布擦拭光纤的端头，然后牢固插入。3.1.4 验证数据库和实际硬件安装相一致。disp_equipXfull（在MCU的MMI提示符符下键入，这里的X是立6号）3.1.5 验证MMI提示符出现在载频的RSS端口，如果不是，请验证这个载频的电源开关是否打开。3.1.6 验证LED的状态，如果不是亮的，请验证这个载频的电源开关是否打开。3.1.7 验证这个载频没有被锁住。/StateXdri*（从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号）UnlockXdriYY（从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号）这将解锁这个DRI。3.1.8 检查基站的

12、告警。disp_act_alX（从OMC上的MMI提示符下键入这里X是站号）3.2 "DRINOTDETECTED和“WaitingforConnection”3.2.1 执行在段中的一般性检查，保证系统运行。3.2.2 如果发生“WaitingforConnection错误，等待5-10分钟去观察这个故障是否自动消除。3.2.3 INS这个硬件insXdriYY（从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号）3.2.4 硬件reset这个载频3.2.5 对于TCU-B的检查，清洁所有光纤连接口。对于CTU,检查背板或面板的物理损伤。如果面板弯曲或安装不到位，那么背板不

13、可能正确连接。3.2.6 如果上述步骤不能消除这故障，请试着和同一基站中的载频调换，然后判断是槽位的问题还是载频问题。3.2.7 判断数据库是否最近被修改，如果是，确保数据库和实际硬件安装一致。注：可能为FMUX板子的断口故障，可先将主备用交换测试/也可能为MCU/MCUF故障引起，同样可以swap到备用主处理器进行性能测试来判断主处理器板子的性能！3.3 "Inhibited”3.3.1 执行在段中的一般性检查，保证系统运行，特别注意所有的告警。3.3.2 打开MCU/MCUF的告警模式，INS这个设备，并且在基站正常工作后，记录所有告警。Mode_alarmXon或en_alX（

14、在MCU上的MMI提示符下键入，这里/的X。站号）一/InsXdriYY（从MMI提示符下键入，这里X是站号,、Y是DRI号）3.4 "CodeLoadFail和“CEBConfigurationFail”3.4.1 执行在段中的一般性检查，保证系统运行。3.4.2 INS这块载频。InsXdriYY（从MMI提示符下键入，这里X是站号，Y是DRI号）3.4.3 等待10-15分钟的软件下载。3.4.4 如果这个故障再次出现，重启载频。Reset_devXdriYY（从MMI提示符下键入，这里X是站号，Y是DRI号）3.5 "NoHDLCresetpending”3.5.1

15、 执行在段中的一般性检查，保证系统运行。3.5.2 INS这个载频/insXdriYY（从MMI提示符下键入，这里X是站号，Y是DRI号）3.5.3 等待10-15分钟的软件下载。/3.6 CodeLoad3.6.1 不进行任何操作，等待软件下载的完成。如果载频在软件下载过程中被重启或者掉电，可能造成永久性的软件损坏。正常的软件下载过程需要花费15-20分钟完成，具体依赖于这一基站所需的软件大小。3.6.2 仅当载频处于下载状态(codeload)超过20分钟后，INS这一载频。insXdriYY(从MMI提示符下键入，这里X是站号,4Y是DRI号)3.6.3 等待15-20分钟的软件下载3.

16、6.4 如果这个载频再一次吊死在软件下载状态(CodeLoad),重启这个载频。Reset_devXdriYY(从MCU/MCUF上MMI提示符下键入，这里X是站号，丫是DRI号)3.7 "InvalidCalibrationData”3.7.1 执行完整的BayLevel调试。3.7.2 如果使用CINDY或BACK这样的调试软件，必须在完成调试后使用保存命令确保调试结果被存储。可以从载频上读取调试数据然后验证是否有“80”值被存储。如果是“80”值，载频将给出相应告警并且需要重新调、试。对于人工调试指令和数据的验证，请参考BSS用户手册：68P02901W43。3.8 “High

17、dropcall/set-upfailurerate”问题通常是由于无线干扰造成。关于具体的频率优化，请参考无线射频规划(RFPlanningGuidelines)。一个完整的Baylevel校准会提高这些统计指标。若有可能，选用另一频率一段时间，然后观察统计结果。若此类问题普遍存在于网络中，那么网络需要进行一次系统的频率优化3.9 DRI150告警或“ReceiveMatrixBranch1ControlLinkFailure3.9.1 按照节所述，进行全面的检查，以保证系统的运行。3.9.2 确定在机柜中有多少载频有这样的告警。若只有一块载频，那么很大可能是载频和SURF模块间的连接有问题

18、。disp_act_alXdriYY（从OMCMMI提示符输入该命令，X站号YY是dri号）3.9.3 Lock该站的所有载频./lockXdriYY（自OMCMMI提示符输入,X是站号YY是dri号）3.9.4 关闭SURF模块电源.3.9.5 取出SURF模块，再次插回原来的位置，确认可靠插入。3.9.6 将SURF模块加电。3.9.7 解锁（Unlock）所有载频，并再次确认告警是否存在。3.9.8 如果告警还存在，那么很可能是SURF模块的问题。4 现场对于MCU/MCUF问题的判断方法下面将概要地介绍判断问题的方法，包括一些必要的步骤。这些步骤是作为其他一些方法的补充，而不是取代它们

19、。如果经过这些步骤判断，问题依然存在，那么在返修的故障报告中，记录这些测试结果，这将有助于问题根本原因的分析以及设备的返修。4.1 对于MCU/MCUF故障的简要判断、4.1.1 通过检查电源开关和BPSM灯指示，确认机柜中的各个模块都已加电。4.1.2 通过前面板的“cpifi位开关，复位MCU/MCUF。当基站正常工作后确认所有载频是Busy-Unlocked（B-U）。按“cpu复位开关仅复位在MCU/MCUF中运行的软件。stateXdriYY（自OMCMMI提示符输入，X是站号YY是dri号）重复以上指令直至所有载频进入B-U状态。若载频不能进入B-U状态，则参考本手册4,6和7节。

20、4.2 LED指示灯不亮4.2.1 按照节中所述，进行检查。4.2.2 确认MCU/MCUF完全插入槽位中。4.2.3 、检查MCU/MCUFTTY端口有无响应（提示符）。4.3 TTY端口没有响应（提示符）/4.3.1 按照节中所述，进行检查。4.3.2 确认便携机中的串口设置正确。正确的串口设置是波特率9600,8比特，1位停止位，没有奇偶校验位。4.3.3 通过MCU/MCUF前面板的fillreset”按钮，复位MCU/MCUF。4.3.4 如果TTY端口还是没有响应(提示符)，则引导程序(bootcode)损坏。返修MCU/MCUF。为防止问题再度发生，请在MCU/MCUF前面板红绿灯交替闪烁时，不要将MCU/MCUF断电。4.4 "WaitingforSynctoinitialize提示出现在TTY端口4.4.1 按照节中所述，进行检查。.4.4.2 将板子从机框中抽出，检查连线并将他们按紧保证可靠连接。在此过程中应符合防静电要求。重新插入板子并在TTY端口检查问题是否仍然存在。/4.4.3如果问题依然存在，则引导程序(bootcode)损坏.返彳MCU/MCUF.为防止问题以后再度发生，请在MCU/MCU