基站可换设备故障处理指南.docx
- 文档编号:16914360
- 上传时间:2023-07-19
- 格式:DOCX
- 页数:22
- 大小:31.48KB
基站可换设备故障处理指南.docx
《基站可换设备故障处理指南.docx》由会员分享,可在线阅读,更多相关《基站可换设备故障处理指南.docx(22页珍藏版)》请在冰点文库上搜索。
基站可换设备故障处理指南
基站可换设备故障处理指南
修订记录
Date
Version
IssuedBy
Changes
30May2001
1.0
M.Schirmacher
Original
TableofContents
1目的5
2范围5
3参考资料及注意事项5
4载频常见故障说明6
4.1“DRINotDetected”和“WaitingforConnection”6
4.2“Inhibited”6
4.3“CodeLoadFail”和“CEBConfigurationFail”6
4.4“NoHDLCresetpending”7
4.5“CodeLoad”7
4.6“InvalidCalibrationData”7
4.7“Highcall/set-upfailurerate”7
4.8DRI150或“ReceiveMatrixBranch1ControlLinkFailure”8
5MCU/MCUF常见故障说明8
5.1无LED指示8
5.2不能进行TTY接入8
5.3“Waitingforsynctoinitialize”出现在TTY8
5.4MCU/MCUF连续不断的重新启动9
5.5“FMUXLoopbackFailure”9
5.6“NoRedundantLink”9
5.7“PCMCIAFailure”9
6现场工程师处理CTU和TCU-B的步骤10
6.1现场工程师执行的一般性检查10
6.2“DRINOTDETECTED”&“WaitingforConnection”11
6.3“Inhibited”11
6.4“CodeLoadFail”&“CEBConfigurationFail”11
6.5“NoHDLCresetpending”12
6.6“CodeLoad”13
6.7“InvalidCalibrationData”13
6.8“Highdropcall/set-upfailurerate”13
6.9DRI150多或少告警或“ReceiveMatrixBranch1ControlLinkFailure”13
7现场对于MCU/MCUF问题的判断方法15
7.1对于MCU/MCUF问题的简要判断15
7.2没有灯指示15
7.3TTY端口没有响应15
7.4“WaitingforSynctoinitialize”提示出现在TTY端口16
7.5MCU/MCUF不停地重新启动16
7.6“FMUXLoopbackFailure”16
7.7“NoRedundantLink”17
7.8“PCMCIAFailure”17
附录A18
现场工程师检查CTU’s&TCU-B’s项目列表18
附录B19
现场工程师对MCU/MCUF的检查清单19
附录C21
使用PC卡与MCU/MCUF相连启站21
使用set_site命令。
21
1目的
本文件应被用作在现场遇到故障时的快速参考工具。
其中包括了大多数常见问题并提供了快速解答和可能的解决方案。
通过下列方法,可以减少返修器件的数量,提高网络的整体可靠性。
2范围
下列方法适用于所有现场工程师。
3参考资料及注意事项
本文件要求对系统有一般了解,且系统已正确安装,并进行了适当的频率优化。
关于下列方法的信息,请咨询当地摩托罗拉分公司或访问摩托罗拉内部网:
本文中使用下列约定:
.
黑斜体字代表输入的命令。
斜体字代表关于命令或输出的附加信息。
静电放电注意事项
在任何情况下处理电气设备都必须警惕以防止静电放电损伤。
下列注意事项可以将发生静电放电的可能降低到最小:
.
∙必须使用防静电腕带,且应将防静电腕带接至摩托罗拉设备上的防静电接地点。
∙在接触任何器件前应通过触摸机柜的金属表面释放静电。
∙如要接触电路板或数字卡,应只接触前面板或电路板的边缘。
应避免接触电路板上的电路或器件。
4
载频常见故障说明
下文中提到的故障都是客户返修中最常见的,也是返修中最有可能发生“No-Fault-Found”情况的。
通过了解造成这些故障的可能原因,用户就能在故障发生时确定故障背后的真正原因。
这将减少网络故障时间并提高系统可靠性。
4.1“DRINotDetected”和“WaitingforConnection”
这两种故障都是由于MCU/MCUF不能与载频通信。
术语DRI是所有类型载频的软件总称。
在“DRINotDetected”的情况下,从载频到MCU/MCUF的上行链路中断;而“WaitingforConnection”的情况则是从MCU/MCUF到载频的下行链路中断。
这些链路可能受多种因素影响,列举如下:
•数据库错误--MCU/MCUF试图寻找物理上不存在的载频。
•载频未加电或极性颠倒。
•TCU上的光纤损坏或弄脏。
•CTU的背板接头或前面板有物理损坏。
•系统处于过渡状态,会在几分钟内自行恢复。
4.2“Inhibited”
该故障说明载频产生了一个严重告警。
这通常意味着一个真正的故障,但由于缺乏必要的信息,很多这类返修被定为“NoFaultFound”。
当处理一个“Inhibited”的载频时,应当记录下当前的告警。
这可以由OMC操作人员或现场工程师按照下列步骤完成。
4.3“CodeLoadFail”和“CEBConfigurationFail”
这两种故障说明在软件下载期间载频的固件和数字硬件间发生通信错误。
这可能由各种原因造成。
很多情况下该故障可通过重新下载软件清除,载频也可正常工作。
4.4“NoHDLCresetpending”
该故障通常是由于MCU/MCUF间的通信中断造成,而载频则可能处于软件下载过程中或正常工作状态。
该故障通常会在几分钟内自行清除,也可通过“INS”载频清除。
4.5“CodeLoad”
这不是故障,只是表明软件下载仍在进行中。
一次完整的软件下载可能需要15-20分钟。
重要的是尽管可能发生错误,下载过程并没有被中断。
在下载过程结束前不要在该器件上进行任何操作。
4.6“InvalidCalibrationData”
该故障是由于baylevel校准未完成或校准数据在校准完成后未能正确保存。
进行baylevel校准最可靠的方法是使用一个简单的终端程序并手工键入命令。
校准软件工具常被用来最大限度地减少所需时间。
最常用的校准软件工具是“Cindy”和“Back”。
不幸的是这些工具可能无法正确保存校准数据,从而引起该告警。
最好在校准完成后手工保存并验证数据。
手工校准和验证数据的说明参见手册“InstallationandConfiguration:
BSSOptimization”,68P02901W43.
4.7“Highcall/set-upfailurerate”
这通常是由数据库中射频接口或未优化的切换参数设置引起,也是造成RMC返修中出现“NoFaultFound”的最主要原因。
在这些情况下最好试用其它频率/信道一段时间并比较统计结果。
完整的baylevel校准也可能会提高基站的性能。
如果网络中正在发生这类问题,就应进行一次彻底的频率检查以最大限度地减少射频干扰。
4.8
DRI150或“ReceiveMatrixBranch1ControlLinkFailure”
该告警通常出现在HorizonMacro类型的站上,而且已经针对这类故障发布了一个ISB(详情参见ISBAlert004〕。
由于该故障发生在M-Cell设备上的可能性非常低,本文只针对它发生在HorizonMacro设备上的情况。
DRI150告警表明SURF模块已经与载频失去联络或SURF模块上有内部故障。
在发生内部故障的情况下,模块会在任意一条射频路径上出现过流状态的时候产生该告警,指示一个或多个LNA的故障。
该告警还可能是由于到模块或载频的连接松动,SURF模块未加电,或机柜中的SURF机框故障引起。
5MCU/MCUF常见故障说明
下文中提到的故障都是客户返修中最常见的,也是返修中最有可能发生“No-Fault-Found”情况的。
通过了解造成这些故障的可能原因,用户就能在故障发生时确定故障背后的真正原因。
这将减少网络故障时间并提高系统可靠性。
.
5.1无LED指示
这通常表明MCU/MCUF未加电。
这可能是由于电路保险被触发或板卡未正确插入插槽;也可能是由于引导程序(bootcode)损坏。
为消除引导程序(bootcode)损坏的可能性,应确保当设备正在进行引导程序(bootcode)更新时不要切断电源。
当引导程序(bootcode)更新,或写入非易失性内存,可以看到红色和绿色的LED快速交替闪烁。
5.2不能进行TTY接入
这通常是由于用来连接MCU/MCUF的PC或终端设置不正确。
连接MCU/MCUF的正确TTY设置是9600Baud,8bit和1StopBit,且无奇偶校验。
这种情况也可能是由于引导程序(bootcode)损坏。
为消除引导程序(bootcode)损坏的可能性,应确保当设备正在进行引导程序(bootcode)更新时不要切断电源。
当引导程序(bootcode)更新,或写入非易失性内存,可看到红色和绿色的LED快速交替闪烁。
5.3“Waitingforsynctoinitialize”出现在TTY
这一问题可能由于MCU/MCUF安装不牢固或遭损坏的引导程序(bootcode)所致。
为防止软件被损坏,当MCU/MCUF软件正在更新,或者正在写入NV-RAM时必须确保不要让MCU/MCUF掉电。
这一过程可通过面板上LED灯红绿快速变换识别。
5.4MCU/MCUF连续不断的重新启动
遭损坏的引导程序(bootcode)或BTS和BSC之间的通信中断都会导致这一问题。
为防止引导程序(bootcode)遭损坏,当MCU/MCUF软件正在更新,或者正在写入NV-RAM时必须确保不要让MCU/MCUF掉电。
这一过程可通过面板上LED灯红绿快速变换识别。
如果是BTS不能与BSC联系,MCU/MCUF将每30分钟自启动一次。
这是正常情况。
5.5“FMUXLoopbackFailure”
这个告警指示FMUX卡认为光纤连接不能正常工作。
这可能由于以下情况造成:
FMUX卡没插好,或FMUX掉电,光纤安装有问题或折断。
5.6“NoRedundantLink”
主备MCU/MCUF不能正常通信将引发这一告警。
如果备边MCU/MCUF刚刚加上电,需要等待30分钟去预热这块板。
这是由于板内的高精度的晶体振荡器需要一个稳定的温度才能工作。
当然这一告警也可因备用边的MCU/MCUF故障所导致。
5.7“PCMCIAFailure”
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_equipXfull(在MCU的MMI提示符符下键入,这里的X是站号)
6.1.5验证MMI提示符出现在载频的RSS端口,如果不是,请验证这个载频的电源开关是否打开。
6.1.6验证LED的状态,如果不是亮的,请验证这个载频的电源开关是否打开。
6.1.7验证这个载频没有被锁住。
StateXdri**(从MCU上的MMI提示符下键入,这里X是站号,Y是DRI号)
UnlockXdriYY(从MCU上的MMI提示符下键入,这里X是站号,Y是DRI号)这将解锁这个DRI。
6.1.8检查基站的告警。
记录任何告警以备填写返修报告。
disp_act_alX(从OMC上的MMI提示符下键入,这里X是站号)
6.2“DRINOTDETECTED”和“WaitingforConnection”
6.2.1执行在6。
1段中的一般性检查,保证系统运行。
6.2.2如果发生“WaitingforConnection”错误,等待5-10分钟去观察这个故障是否自动消除。
6.2.3INS这个硬件
insXdriYY(从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_alarmXon或en_alX(在MCU上的MMI提示符下键入,这里的X是站号)
InsXdriYY(从MMI提示符下键入,这里X是站号,Y是DRI号)
6.4“CodeLoadFail”和“CEBConfigurationFail”
6.4.1执行在6。
1段中的一般性检查,保证系统运行。
6.4.2INS这块载频。
InsXdriYY(从MMI提示符下键入,这里X是站号,Y是DRI号)
6.4.3等待10-15分钟的软件下载。
6.4.4如果这个故障再次出现,重启载频。
Reset_devXdriYY(从MMI提示符下键入,这里X是站号,Y是DRI号)
6.5“NoHDLCresetpending”
6.5.1执行在6。
1段中的一般性检查,保证系统运行。
6.5.2INS这个载频
insXdriYY(从MMI提示符下键入,这里X是站号,Y是DRI号)
6.5.3等待10-15分钟的软件下载。
6.6“CodeLoad”
6.6.1不进行任何操作,等待软件下载的完成。
如果载频在软件下载过程中被重启或者掉电,可能造成永久性的软件损坏。
正常的软件下载过程需要花费15-20分钟完成,具体依赖于这一基站所需的软件大小。
6.6.2仅当载频处于下载状态(codeload)超过20分钟后,INS这一载频。
insXdriYY(从MMI提示符下键入,这里X是站号,Y是DRI号)
6.6.3等待15-20分钟的软件下载
6.6.4如果这个载频再一次吊死在软件下载状态(CodeLoad),重启这个载频。
Reset_devXdriYY(从MCU/MCUF上MMI提示符下键入,这里X是站号,Y是DRI号)
6.7“InvalidCalibrationData”
6.7.1执行完整的BayLevel调试。
6.7.2如果使用CINDY或BACK这样的调试软件,必须在完成调试后使用保存命令确保调试结果被存储。
可以从载频上读取调试数据然后验证是否有“80”值被存储。
如果是“80”值,载频将给出相应告警并且需要重新调试。
对于人工调试指令和数据的验证,请参考BSS用户手册:
68P02901W43。
6.8“Highdropcall/set-upfailurerate”
问题通常是由于无线干扰造成。
关于具体的频率优化,请参考无线射频规划(RFPlanningGuidelines)。
一个完整的Baylevel校准会提高这些统计指标。
若有可能,选用另一频率一段时间,然后观察统计结果。
若此类问题普遍存在于网络中,那么网络需要进行一次系统的频率优化.
6.9DRI150告警或“ReceiveMatrixBranch1ControlLinkFailure”
6.9.1按照6.1节所述,进行全面的检查,以保证系统的运行。
6.9.2确定在机柜中有多少载频有这样的告警。
若只有一块载频,那么很大可能是载频和SURF模块间的连接有问题。
disp_act_alXdriYY(从OMCMMI提示符输入该命令,X站号YY是dri号)
6.9.3Lock该站的所有载频.
lockXdriYY(自OMCMMI提示符输入,X是站号YY是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中运行的软件。
stateXdriYY(自OMCMMI提示符输入,X是站号YY是dri号)
重复以上指令直至所有载频进入B-U状态。
若载频不能进入B-U状态,则参考本手册4,6和7节。
7.2LED指示灯不亮
7.2.1按照7.1节中所述,进行检查。
7.2.2确认MCU/MCUF完全插入槽位中。
7.2.3检查MCU/MCUFTTY端口有无响应(提示符)。
7.3TTY端口没有响应(提示符)
7.3.1按照7.1节中所述,进行检查。
7.3.2确认便携机中的串口设置正确。
正确的串口设置是波特率9600,8比特,1位停止位,没有奇偶校验位。
7.3.3通过MCU/MCUF前面板的“fullreset”按钮,复位MCU/MCUF。
7.3.4如果TTY端口还是没有响应(提示符),则引导程序(bootcode)损坏。
返修MCU/MCUF。
为防止问题再度发生,请在MCU/MCUF前面板红绿灯交替闪烁时,不要将MCU/MCUF断电。
7.4“WaitingforSynctoinitialize”提示出现在TTY端口
7.4.1按照7.1节中所述,进行检查。
.
7.4.2将板子从机框中抽出,检查连线并将他们按紧保证可靠连接。
在此过程中应符合防静电要求。
重新插入板子并在TTY端口检查问题是否仍然存在。
7.4.3如果问题依然存在,则引导程序(bootcode)损坏.返修MCU/MCUF.为防止问题以后再度发生,请在MCU/MCUF前面板红绿灯交替闪烁时,不要将MCU/MCUF断电。
7.5MCU/MCUF不停地重新启动
7.5.1按照7.1节中所述,进行检查。
7.5.2若在TTY端口显示“WaitingforSynctoinitialize”提示,请参照7.4节中所述,进行检查。
7.5.3确认NIU板可靠插入,并已加电。
7.5.4确认基站同BSC正常连接,若中间传输不通,MCU/MCUF将每30分钟重新启动一次。
这是正常现象。
7.6“FMUXLoopbackFailure”
7.6.1按照7.1节中所述,进行检查。
7.6.2确认远端FMUX板(remoteFMUX)已插入,并且提供电源的BPSM有绿灯指示。
7.6.3如果主机柜使用FMUX板,确认其可靠插入槽中。
7.6.4确认光纤可靠连接,收发光纤没有交叉。
7.6.5更换光纤以确认是否是光纤的问题。
7.7“NoRedundantLink”
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“PCMCIAFailure”
7.8.1按照7.1节中所述,进行检查。
7.8.2确认PCMCIA卡完全查入槽位中。
完全插入的卡应该和面板齐平。
7.8.3用以下命令确认PCMCIA卡的状态:
stateXCSFP*(自OMCMMI提示符输入,X是站号)
以下是正确的状态:
B-UNoReason
E-UNoReason
D-UNoCode
附录A
现场工程师检查CTU’s&TCU-B’s的检查清单
通用步骤
完成
确认供电,射频(天线)电缆及光纤正确安装和连接。
确认数据库中的定义同实际物理硬件安装相符。
确认在载频RSS端口可以得到MMI提示符。
状态灯亮。
确认载频处于unlocked状态,记录所有当前(active)告警。
“DRINotDetected”,“WaitingforConnection”和“NoHDLCresetpending”
完成
等5-10分钟,问题应该清除。
必要时INS硬件。
“Inhibited”
完成
打开告警模式(enablealarm),INS硬件,记录告警。
“CodeLoadFail”和“CEBConfiguration
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基站 设备 故障 处理 指南
![提示](https://static.bingdoc.com/images/bang_tan.gif)