基站可换设备故障处理指导书.docx

n

更多企业学院：
《中小企业管理全能版》
183套讲座+89700份资料

《总经理、高层管理》
49套讲座+16388份资料

《中层管理学院》
46套讲座+6020份资料 

《国学智慧、易经》
46套讲座

《人力资源学院》
56套讲座+27123份资料

《各阶段员工培训学院》
77套讲座+ 324份资料

《员工管理企业学院》
67套讲座+ 8720份资料

《工厂生产管理学院》
52套讲座+ 13920份资料

《财务管理学院》
53套讲座+ 17945份资料 

《销售经理学院》
56套讲座+ 14350份资料

《销售人员培训学院》
72套讲座+ 4879份资料

基站可换设备故障处理指南修订记录

Date
Version
Issued By
Changes
30 May 2001
1.0
M. Schirmacher
Original

Table of Contents

1 目的
本文件应被用作在现场遇到故障时的快速参考工具。其中包括了大多数常见问题并提供了快速解答和可能的解决方案。通过下列方法，可以减少返修器件的数量，提高网络的整体可靠性。
2 范围
下列方法适用于所有现场工程师。

3 参考资料及注意事项

本文件要求对系统有一般了解，且系统已正确安装，并进行了适当的频率优化。关于下列方法的信息，请咨询当地摩托罗拉分公司或访问摩托罗拉内部网：

本文中使用下列约定：.
黑斜体字代表输入的命令。
斜体字代表关于命令或输出的附加信息。
静电放电注意事项
在任何情况下处理电气设备都必须警惕以防止静电放电损伤。 下列注意事项可以将发生静电放电的可能降低到最小：.

· 必须使用防静电腕带，且应将防静电腕带接至摩托罗拉设备上的防静电接地点。
· 在接触任何器件前应通过触摸机柜的金属表面释放静电。
· 如要接触电路板或数字卡，应只接触前面板或电路板的边缘。应避免接触电路板上的电路或器件。

4 载频常见故障说明

下文中提到的故障都是客户返修中最常见的，也是返修中最有可能发生“No-Fault-Found”情况的。通过了解造成这些故障的可能原因，用户就能在故障发生时确定故障背后的真正原因。这将减少网络故障时间并提高系统可靠性。

4.1 “DRI Not Detected” 和 “Waiting for Connection”

这两种故障都是由于 MCU/MCUF 不能与载频通信。 术语 DRI 是所有类型载频的软件总称。 在“DRI Not Detected”的情况下，从 载频到 MCU/MCUF 的上行链路中断；而“Waiting for Connection”的情况则是从 MCU/MCUF 到载频的下行链路中断。这些链路可能受多种因素影响，列举如下：
• 数据库错误－－MCU/MCUF 试图寻找物理上不存在的载频。
• 载频未加电或极性颠倒。
• TCU上的光纤损坏或弄脏。
• CTU的背板接头或前面板有物理损坏。
• 系统处于过渡状态，会在几分钟内自行恢复。

4.2 “Inhibited”

该故障说明载频产生了一个严重告警。这通常意味着一个真正的故障，但由于缺乏必要的信息，很多这类返修被定为“No Fault Found”。当处理一个 “Inhibited”的 载频时，应当记录下当前的告警。这可以由 OMC 操作人员或 现场工程师按照下列步骤完成。

4.3 “Code Load Fail” 和 “CEB Configuration Fail”

这两种故障说明在软件下载期间载频的固件和数字硬件间发生通信错误。这可能由各种原因造成。很多情况下该故障可通过重新下载软件清除，载频也可正常工作。
4.4 “No HDLC reset pending”

该故障通常是由于MCU/MCUF间的通信中断造成，而载频则可能处于软件下载过程中或正常工作状态。 该故障通常会在几分钟内自行清除，也可通过“INS” 载频清除。

4.5 “Code Load”

这不是故障，只是表明软件下载仍在进行中。一次完整的软件下载可能需要15-20 分钟。重要的是尽管可能发生错误，下载过程并没有被中断。在下载过程结束前不要在该器件上进行任何操作。

4.6 “Invalid Calibration Data”

该故障是由于bay level校准未完成或校准数据在校准完成后未能正确保存。进行 bay level校准最可靠的方法是使用一个简单的终端程序并手工键入命令。校准软件工具常被用来最大限度地减少所需时间。最常用的校准软件工具是“Cindy”和“Back”。不幸的是这些工具可能无法正确保存校准数据，从而引起该告警。最好在校准完成后手工保存并验证数据。手工校准和验证数据的说明参见手册“Installation and Configuration： BSS Optimization”， 68P02901W43.

4.7 “High call/set-up failure rate”

这通常是由数据库中射频接口或未优化的切换参数设置引起，也是造成RMC返修中出现“No Fault Found”的最主要原因。在这些情况下最好试用其它频率/信道一段时间并比较统计结果。完整的bay level校准也可能会提高基站的性能。如果网络中正在发生这类问题，就应进行一次彻底的频率检查以最大限度地减少射频干扰。

4.8 DRI 150 或 “Receive Matrix Branch 1 Control Link Failure”

该告警通常出现在Horizon Macro类型的站上，而且已经针对这类故障发布了一个 ISB（详情参见ISB Alert 004〕。由于该故障发生在M－Cell设备上的可能性非常低，本文只针对它发生在 Horizon Macro设备上的情况。
DRI 150告警表明SURF模块已经与载频失去联络或SURF模块上有内部故障。 在发生内部故障的情况下，模块会在任意一条射频路径上出现过流状态的时候产生该告警，指示一个或多个LNA的故障。该告警还可能是由于到模块或载频的连接松动，SURF模块未加电，或机柜中的SURF机框故障引起。

5 MCU/MCUF 常见故障说明

下文中提到的故障都是客户返修中最常见的，也是返修中最有可能发生“No-Fault-Found”情况的。通过了解造成这些故障的可能原因，用户就能在故障发生时确定故障背后的真正原因。这将减少网络故障时间并提高系统可靠性。.

5.1 无LED指示

这通常表明MCU/MCUF未加电。这可能是由于电路保险被触发或板卡未正确插入插槽；也可能是由于引导程序(boot code)损坏。为消除引导程序(boot code)损坏的可能性，应确保当设备正在进行引导程序(boot code)更新时不要切断电源。当引导程序(boot code)更新，或写入非易失性内存，可以看到红色和绿色的LED快速交替闪烁。

5.2 不能进行TTY接入

这通常是由于用来连接MCU/MCUF的PC或终端设置不正确。连接 MCU/MCUF的正确TTY设置是9600 Baud，8 bit 和 1 Stop Bit，且无奇偶校验。 这种情况也可能是由于引导程序(boot code)损坏。 为消除引导程序(boot code)损坏的可能性，应确保当设备正在进行引导程序(boot code)更新时不要切断电源。当引导程序(boot code)更新，或写入非易失性内存，可看到红色和绿色的LED快速交替闪烁。

5.3 “Waiting for sync to initialize”出现在TTY

这一问题可能由于MCU/MCUF安装不牢固或遭损坏的引导程序 (boot code) 所致。为防止软件被损坏，当MCU/MCUF软件正在更新，或者正在写入NV-RAM时必须确保不要让MCU/MCUF掉电。这一过程可通过面板上LED灯红绿快速变换识别。

5.4 MCU/MCUF 连续不断的重新启动

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

5.5 “FMUX Loopback Failure”

这个告警指示FMUX卡认为光纤连接不能正常工作。这可能由于以下情况造成：FMUX卡没插好，或FMUX掉电，光纤安装有问题或折断。
5.6 “No Redundant Link”

主备MCU/MCUF不能正常通信将引发这一告警。如果备边MCU/MCUF刚刚加上电，需要等待30分钟去预热这块板。这是由于板内的高精度的晶体振荡器需要一个稳定的温度才能工作。当然这一告警也可因备用边的MCU/MCUF故障所导致。
5.7 “PCMCIA Failure”

PCMCIA卡插入不当或不匹配的卡将造成这一告警。正确插入时，PCMCIA卡将与MCU/MCUF面板平齐，并且只有摩托罗拉认可的卡能在这里被使用。
6 现场工程师处理CTU和TCU-B的步骤

下面将概要地介绍判断问题的方法，包括一些必要的步骤。 这些步骤是作为其他一些方法的补充，而不是取代它们。 如果经过这些步骤判断， 问题依然存在，那么在返修的故障报告中，记录这些测试结果，这将有助于问题根本原因的分析以及设备的返修。

6.1 现场工程师执行的一般性检查

6.1.1 验证所有机柜内的设备都加上电，也要检查TCU的插头极性。

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

6.1.3 验证TCU-B光纤的正确连接，连接是否紧密，并且没有碎屑。这可以通过以下步骤做到：拔出光纤然后用吹气球向MCU/MCUF和TCU的光纤连接口吹风，并用软布擦拭光纤的端头，然后牢固插入。

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

disp_equip X full (在MCU的MMI提示符符下键入，这里的X是站号)

6.1.5 验证MMI提示符出现在载频的RSS端口，如果不是，请验证这个载频的电源开关是否打开。

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

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

State X dri * * （从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号）
Unlock X dri Y Y(从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号) 这将解锁这个DRI。

6.1.8 检查基站的告警。记录任何告警以备填写返修报告。

disp_act_al X ( 从OMC上的MMI提示符下键入，这里X是站号)

6.2 “DRI NOT DETECTED” 和 “Waiting for Connection”

6.2.1 执行在6。1段中的一般性检查，保证系统运行。

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

6.2.3 INS 这个硬件

ins X dri Y Y（从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号）

6.2.4 对于TCU-B的检查，清洁所有光纤连接口。对于CTU，检查背板或面板的物理损伤。如果面板弯曲或安装不到位，那么背板不可能正确连接。

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

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

6.3 “Inhibited”

6.3.1 执行在6。1段中的一般性检查，保证系统运行，特别注意所有的告警。

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

Mode_alarm X on 或 en_al X（ 在MCU上的MMI提示符下键入，这里的X是站号）
Ins X dri Y Y（ 从MMI提示符下键入，这里X是站号，Y是DRI号）

6.4 “Code Load Fail” 和 “CEB Configuration Fail”

6.4.1 执行在6。1段中的一般性检查，保证系统运行。

6.4.2 INS 这块载频。
Ins X dri Y Y（从MMI提示符下键入，这里X是站号，Y是DRI号）

6.4.3 等待10-15分钟的软件下载。

6.4.4 如果这个故障再次出现，重启载频。
Reset_dev X dri Y Y（从MMI提示符下键入，这里X是站号，Y是DRI号）

6.5 “No HDLC reset pending”

6.5.1 执行在6。1段中的一般性检查，保证系统运行。

6.5.2 INS 这个载频

ins X dri Y Y（从MMI提示符下键入，这里X是站号，Y是DRI号）

6.5.3 等待10-15分钟的软件下载。
6.6 “Code Load”

6.6.1 不进行任何操作，等待软件下载的完成。如果载频在软件下载过程中被重启或者掉电，可能造成永久性的软件损坏。正常的软件下载过程需要花费15-20分钟完成，具体依赖于这一基站所需的软件大小。

6.6.2 仅当载频处于下载状态（ code load)超过20分钟后，INS 这一载频。

ins X dri Y Y（从MMI提示符下键入，这里X是站号，Y是DRI号）

6.6.3 等待15-20分钟的软件下载

6.6.4 如果这个载频再一次吊死在软件下载状态（Code Load），重启这个载频。

Reset_dev X dri Y Y（从MCU/MCUF上MMI提示符下键入，这里X是站号，Y是DRI号）

6.7 “Invalid Calibration Data”

6.7.1 执行完整的Bay Level调试。

6.7.2 如果使用CINDY或BACK这样的调试软件，必须在完成调试后使用保存命令确保调试结果被存储。可以从载频上读取调试数据然后验证是否有“80”值被存储。如果是“80”值，载频将给出相应告警并且需要重新调试。

对于人工调试指令和数据的验证，请参考BSS用户手册：68P02901W43。

6.8 “High drop call/set-up failure rate”

问题通常是由于无线干扰造成。关于具体的频率优化，请参考无线射频规划( RF Planning Guidelines) 。一个完整的 Bay level 校准会提高这些统计指标。 若有可能，选用另一频率一段时间，然后观察统计结果。若此类问题普遍存在于网络中，那么网络需要进行一次系统的频率优化.

6.9 DRI 150告警 或 “Receive Matrix Branch 1 Control Link Failure”

6.9.1 按照6.1节所述，进行全面的检查，以保证系统的运行。

6.9.2 确定在机柜中有多少载频有这样的告警。若只有一块载频，那么很大可能是载频和SURF模块间的连接有问题。

disp_act_al X dri Y Y (从 OMC MMI提示符输入该命令 ， X 站号 Y Y是 dri号)

6.9.3 Lock 该站的所有载频.

lock X dri Y Y (自 OMC MMI提示符输入 ， X是站号 Y Y 是dri 号)

6.9.4 关闭SURF模块电源.

6.9.5 取出SURF模块，再次插回原来的位置，确认可靠插入。

6.9.6 将SURF模块加电。

6.9.7 解锁（Unlock） 所有载频 ，并再次确认告警是否存在。

6.9.8 如果告警还存在， 那么很可能是SURF模块的问题。

7 现场对于MCU/MCUF问题的判断方法

下面将概要地介绍判断问题的方法，包括一些必要的步骤。 这些步骤是作为其他一些方法的补充，而不是取代它们。 如果经过这些步骤判断， 问题依然存在，那么在返修的故障报告中，记录这些测试结果，这将有助于问题根本原因的分析以及设备的返修。

7.1 对于 MCU/MCUF 故障的简要判断

7.1.1 通过检查电源开关和BPSM灯指示，确认机柜中的各个模块都已加电。

7.1.2 通过前面板的“cpu”复位开关，复位 MCU/MCUF。当基站正常工作后，确认所有载频是 Busy-Unlocked (B-U) 。按 “cpu” 复位开关仅复位在 MCU/MCUF中运行的软件。

state X dri Y Y (自 OMC MMI提示符输入， X是站号 Y Y 是dri 号)
重复以上指令直至所有载频进入 B-U 状态。若载频不能进入B-U状态，则参考本手册 4， 6 和7节。

7.2 LED指示灯不亮

7.2.1 按照7.1节中所述，进行检查。

7.2.2 确认MCU/MCUF 完全插入槽位中。

7.2.3 检查MCU/MCUF TTY 端口有无响应（提示符）。

7.3 TTY 端口没有响应（提示符）

7.3.1 按照7.1节中所述，进行检查。

7.3.2 确认便携机中的串口设置正确。正确的串口设置是波特率 9600 ， 8 比特， 1位 停止位，没有奇偶校验位。

7.3.3 通过MCU/MCUF 前面板的“full reset”按钮，复位MCU/MCUF。

7.3.4 如果 TTY端口还是没有响应（提示符）， 则引导程序 (boot code)损坏。 返修MCU/MCUF。为防止问题再度发生，请在MCU/MCUF 前面板红绿灯交替闪烁时，不要将MCU/MCUF 断电。

7.4 “Waiting for Sync to initialize” 提示出现在 TTY端口

7.4.1 按照7.1节中所述，进行检查。.

7.4.2 将板子从机框中抽出，检查连线并将他们按紧保证可靠连接。在此过程中应符合防静电要求。重新插入板子并在TTY端口检查问题是否仍然存在。

7.4.3 如果问题依然存在， 则引导程序 (boot code)损坏. 返修MCU/MCUF . 为防止问题以后再度发生，请在MCU/MCUF 前面板红绿灯交替闪烁时，不要将MCU/MCUF 断电。

7.5 MCU/MCUF 不停地重新启动

7.5.1 按照7.1节中所述，进行检查。

7.5.2 若在TTY端口显示“Waiting for Sync to initialize”提示，请参照7.4节中所述，进行检查。

7.5.3 确认NIU 板可靠插入，并已加电。

7.5.4 确认基站同 BSC 正常连接， 若中间传输不通， MCU/MCUF 将每30 分钟重新启动一次。 这是正常现象。

7.6 “FMUX Loopback Failure”

7.6.1 按照7.1节中所述，进行检查。

7.6.2 确认远端 FMUX板(remote FMUX )已插入，并且提供电源的 BPSM 有绿灯指示。

7.6.3 如果主机柜使用 FMUX板 ， 确认其可靠插入槽中。

7.6.4 确认光纤可靠连接，收发光纤没有交叉。

7.6.5 更换光纤以确认是否是光纤的问题。

7.7 “No Redundant Link”

7.7.1 按照7.1节中所述，进行检查。

7.7.2 按照此节中所述，首先检查备用 MCU/MCUF。

7.7.3 确认主备用MCU/MCUFs 可靠插在槽位中。

7.7.4 复位备用MCU/MCUF。

7.7.5 复位主用MCU/MCUF。

7.8 “PCMCIA Failure”

7.8.1 按照7.1节中所述，进行检查。

7.8.2 确认PCMCIA卡完全查入槽位中。 完全插入的卡应该和面板齐平。

7.8.3 用以下命令确认 PCMCIA 卡的状态:

state X CSFP * (自 OMC MMI提示符输入， X是站号)
以下是正确的状态:
B-U No Reason
E-U No Reason
D-U No Code

附录 A
现场工程师检查 CTU’s & TCU-B’s的检查清单

通用步骤
完成
确认供电，射频(天线)电缆及光纤正确安装和连接。

确认数据库中的定义同实际物理硬件安装相符。

确认在载频RSS 端口可以得到MMI 提示符。状态灯亮。

确认载频处于unlocked 状态，记录所有当前（active ）告警。

“DRI Not Detected”， “Waiting for Connection” 和 “No HDLC reset pending”
完成
等 5-10 分钟，问题应该清除。 必要时INS 硬件。

“Inhibited”
完成
打开告警模式(enable alarm)， INS硬件，记录告警。

“Code Load Fail” 和 “CEB Configuration Fail”
完成
INS硬件，并等待15-20 分钟，直至 code load (软件下载)完成 。

必要时复位硬件。

“Code Load”
完成
等待 code load (软件下载)完成， 至少20 分钟内不要中断下载。

INS硬件，等待 15-20 分钟，至 code load (软件下载)完成。

必要时复位硬件。

“Invalid Calibration Data”
完成
做一次完整的Bay Level 校准。

手动确认并且存储数据。

“High drop call/set-up failure rate”
完成
做一次完整的Bay Level 校准。

换用另一频率以避免射频干扰。

附录 B
现场工程师对MCU/MCUF的检查清单

LED 灯不亮
完成
· 检查BPSM 电路 断路器是否有问题。

· 确认MCUF 是否完全插入 机框。

· 检查 TTY端口是否有响应。 如果没有， 参见“No TTY”部分。

TTY 端口无响应
完成
· 确认终端的设置：
9600 Baud
8 Bits
1 Stop Bit
No Parity

· 用“full reset”开关重启MCU/MCUF板。

· 如果TTY端口仍无响应， 则引导程序 (boot code)被破坏。将MCU板返修。为了防止这种问题出现，当MCU板在红灯和绿灯交替闪动时，一定不要关电。

TTY端口显示“Waiting for Sync to initialize”
完成
· 从机框中拔出MCU/MCUF板子并把带状电缆压入槽中。重新插入板子并再次检查TTY端口。确认遵从静电放电保护措施。

连续重启
完成
· 如果TTY端口连续显示“Waiting for Sync to initialize”这条信息，请参见 “Waiting for Sync to Initialize”。

· 确认NIU卡已加电，并且绿色指示灯亮。

FMUX Loopback Failure
完成
· 确认 远端 FMUX 已插入，并且BPSM上的绿色指示灯亮。

· 如果主机柜使用FMUX卡，要确认该卡可靠地插入机柜中。

· 确认光纤两端正确连接，比如，没有“交叉”。

· 调换光纤来证明光纤是否是断的。

No Redundant Link
完成
· 在开始处理MCUF问题时，使用此步骤。

· 确保两个MCUF正确安装在机架中。

· 重启备用MCUF。

· 重启主用MCUF。

PCMCIA 卡故障
完成
· 确认PCMCIA卡完全插入槽中，且该卡同面板平齐。

· 用这条命令确认PCMCIA卡的状态：
state <site> CSFP * * *
正常的状态应当是：
B-U No Reason
E-U No Reason
D-U No Code

附录 C
使用PCMCIA卡启站
使用 set_site 命令

使用set_site 命令

在启站时，set_site 命令非常有用。 使用PCMCIA卡和有效的软件及数据库，可以在与BSC的连接未开通时，开启一个基站。 它还能为新站快速的下载数据，避免了基站等待BSC通过2M传输下载数据，减少了启站所需的时间。
对于set_site 命令只有一个参数，就是站号。 站号必须和基站编号相符。当使用set_site 命令时，有以下一些问题需要注意。

如果不知道站号？

如果不知道站号， 那么很容易通过一个小实验来获得。执行 set_site 命令，使用站号1：
MMI-ROM 1015-> set_site 1
如果站号不是1，将产生一条 FATAL SWFM 并且基站将重启。 参见以下标题为‘如果得到一条cm_init.c FATAL SWFM？’部分的描述，可以得到正确站号。

如果得到一条 “bus_fault_handler ”的FATAL SWFM?

如果MCU/MCUF 的软件版本同PCMCIA 卡上的不一致，一个“bus fault”错误将会产生。该错误是一专门类型的FATAL SWFM， 并且会有象这样的内容：
0 FATAL SWFM ERROR Routine: bus_fault_handler
0 Area: 0x00000000 Error: 0x00000002 PC: 0xc1802ab6 PID: 0x95 (Temp CM)
0 BSS Release: 1.30.30.30.0 Obj Version: 1.6.1.4.b Exec Version: 1.6.2.0.c2
0 01-Jan-1980 00:00:39.820 Subsystem: 0x02 CPU: 0x1015 Board: MCU-F
0 FSLW=01010200 address=00000034

有一些部分可能不一样，但是‘Routine’ 部分将会是‘bus_fault_handler’。 如果你遇到这个问题，这个基站将会软启动很多次，但是将最终硬启动并回到MMI-ROM提示状符态。 这时候，可以用burn_boot命令用PCMCIA卡上的软件来更新MCU/MCUF 上的闪存内容。 burn_boot 命令不含有参数，可在MMI-ROM 提示符下输入，
MMI-ROM 1015 -> burn_boot
Preparing for fast flash programming
Software download not dual_boot capable
Erasing auxillary flash.

Erasing sectors ...done

BOOT PROGRAMMING IN PROGRESS. DO NOT DISRUPT!!!!

Erasing sectors...done
Programming: 651264 of 651264 bytes done
Updating COM table...done
Flashing complete.

!!! REBOOT !!!

如果burn_boot 命令键入后出现一条错误信息，请将PCMCIA 卡从MCU/MCUF 上取下。 把写保护置于关闭位置，再把卡插入MCU/MCUF 。在这个过程中MCU/MCUF不会改写卡中数据。用“full reset”按钮重启 MCUF，并重试burn boot步骤。

如果得到一条“cm_init.c ”FATAL SWFM?
每一个基站的数据库都有专门的站号。当执行set_site命令时， 站号参数必须与数据库中的基站编号相符。如果它们不相符，基站将产生一条 “cm_init.c ”FATAL SWFM， 它将指出软件所希望的站号：
MMI-ROM 1015 -> set 5
Setting subsystem to 6 for site 5

0 FATAL SWFM ERROR Routine: cm_init.c
0 Area: 0x00000700 Error: 0x0000000a PC: 0xc00005c4 PID: 0x95 (Temp CM)
0 BSS Release: 1.6.1.4.b Obj Version: 1.6.1.4.b
0 01-Jan-1980 00:00:33.535 Subsystem: 0x06 CPU: 0x1015 Board: MCU-F
0 Incorrect database. This site is: 5. Database is for site: 92
0

在这个例子中，使用者尝试的站号为5， 但是数据库中设计为92号站， （正如最后一行所示）。 基站将重启， 并且当出现MMI-ROM 提示符时， 使用者应当重新输入set_site 命令， 这次使用站号92：
MMI-ROM 1015 -> set 92
Setting subsystem to 93 for site 92

Process 0x95 (Temp CM) requested a self-initiated soft reset

!!! REBOOT !!!

Reset due to self-initiated soft reset
PCMCIA: Intel Series 2+ Flash detected in socket 0
MMI-ROM 0000 ->
MMI-ROM 0000 ->
MMI-RAM 1015 -> Waiting for System Initialization to complete.....
MMI-RAM 1015 ->

为什么基站在30分钟后重启？
如果RSL与BSC的连接在30分钟内未建立， 基站将自动重启。 既然与BSC没有建立联系， 那么基站假定在配置过程中可能产生错误， 并且重启自己。 这是一个软件特性，而不是设备故障。

“No DRAM Database” 的错误是什么意思？
如果PCMCIA卡上的数据库不存在或不完整，set_site 命令键入后将出现这条错误信息。那么这块卡必须被重新写入数据。