RNC常见故障处理设备篇4高级.docx
《RNC常见故障处理设备篇4高级.docx》由会员分享，可在线阅读，更多相关《RNC常见故障处理设备篇4高级.docx（24页珍藏版）》请在冰豆网上搜索。
RNC常见故障处理设备篇4高级
RNC常见故障处理设备篇
课程目标：
●课程目标1
●课程目标2
●课程目标3
●课程目标4
参考资料：
●参考资料1
●参考资料2
●参考资料3
目录
第1章常见故障分类1
第2章常见故障排查思路3
2.1时钟类故障排查思路3
2.2启动类故障排查思路4
2.3传输类故障排查思路5
2.3.1排查前首先要确认的信息：
5
2.3.2不同情况的告警处理5
2.3.3环回诊断法6
2.3.4仪器诊断法7
2.3.5更换单板法7
第3章典型故障案例8
3.1时钟类典型案例8
3.1.1CLKG有“二级时钟基准丢失告警”，时钟一直处于自由震荡的工作模式。
8
3.1.2RNC时钟板有时钟基准丢失告警10
3.2启动类典型案例11
3.2.1整个机框的单板运行均不正常11
3.2.2RPU不能启动故障一例15
3.2.3备用OMP不能正常运行17
3.2.4RCB不能正常运行18
3.2.5CLKG板状态为CATCH20
3.2.6GLI单板插光纤后不能启动20
3.2.7GIPI无法正常启动20
3.2.8UIMU每隔1小时主备倒换21
3.3传输类典型案例24
3.3.1子单元故障24
第一章常见故障分类
摘要
本章介绍了RNC设备时钟、硬件启动、传输以及版本下载等故障的故障现象、故障原因分析和故障处理方法等。
按照外场设备运行中发现的和设备相关的各种故障现象，可以将设备类故障划分为以下几类：
时钟类故障：
主要包括各类基准时钟丢失、锁相环失锁等等；
启动类故障：
单板无法启动、单板反复重启等等；
传输类故障：
告警察看出现链路故障或者链路滑码告警等；
前后台同步和版本升级类故障：
包括前后台数据的同步不成功以及升级过程中版本激活异常等；
其他类故障：
这些故障包括由于系统设计不足或者技术人员操作不当导致的故障等等。
与设备相关的常见故障的故障分类及其典型故障现象见表11。
表11常见故障分类
故障分类
典型故障现象
常见故障原因
时钟类故障
基准时钟丢失、锁相环失锁
输入的时钟基准信号丢失
输入的时钟基准信号变差
时钟连接线缆接触不良
锁相环失锁
单板故障
启动类故障
单板灯常亮，单板反复重启
BOOT不对（没有插紧或者没有烧对，插错）
逻辑未烧或者错误
版本文件错误或者缺少版本
版本和数据库中的版本对应不上
内存条未插好、损坏或者硬盘等硬件损坏IP地址冲突或者数据设置错误
传输类故障
链路故障或者链路滑码告警
单板与传输介质之间的阻抗不匹配
时钟异常
传输设备异常
数据配置错误
前后台同步以及版本升级类故障
前后台数据同步失败，版本升级不成功
新旧版本的前台数据库结构发生了变化，版本升级时数据表冲突
前后台的数据表的更改不同步
其它类故障
包括误操作以及干扰类故障的排查等等
由于前后台配合问题，导致的版本激活不成功
由于配置问题问题导致的RSSI升高
第二章常见故障排查思路
摘要
本章介绍了RNC设备在时钟、硬件启动、传输、版本下载、内部通信等故障的故障现象、故障原因分析和故障处理方法等。
二.1时钟类故障排查思路
时钟类故障发生的不多，处理故障时要清楚时钟提取的机制。
CLKG板是整个RNC的时钟来源，可以实现GPS接入、BITS时钟接入、线路时钟提取，完成时钟同步锁相、时钟分发功能。
CLKG单板对外提供15套系统时钟（包括：
PP2S、8K、16M）至各资源子系统，采用电缆传送。
同时，CLKG单板还需提供10套（8K、32M、64M）时钟给T网的单板使用。
全局时钟拓扑如下图所示。
目前RNC采用的是Iu口线路时钟提取方式，时钟板采用二级钟晶振，在丢失基准后，采取保持（KEEP）策略，保持时间很长，可到半年以上，在保持中，由人工根据基准情况选取合适的时机进行切换。
处理时钟类问题时要注意以下几个关键点：
1、目前从CN提取时钟的端口可配置，默认为APBE板的4号光口（第一个口）,可以根据实际和CN连接的端口进行修改，修改位置在APBE板上点击右键菜单，选择修改，在单板的“基本信息”页面里面，有线路时钟基准，数值有0～3，分别对应APBE端口4～7。
2、检查RNC时钟线缆连接，看从APBE板过来的时钟线连接到CLKG后插卡的8KIN1还是8KIN2，现在默认是8KIN1，后台网管上配置需要和前连线一致。
3、如线缆连接到8kin1，则将后台“配置主用时钟基准”为8kbase，“所有时钟基准”只有8kbase。
如是8kin2，则上述两个配置应该都为8KGPS。
4、目前TDRNC时钟单板并未实现主用时钟基准功能，更没有实现优先级切换功能。
5、“配置的所有时钟基准”参数只是配置了OMP上面的时钟管理模块和告警模块，作用是为了能够检测前台时钟丢失的现象，并不是启用某个时钟基准。
CLKG单板获取当前时钟基准并不受后台参数的影响。
二.2启动类故障排查思路
1、BOOT不对（没有插紧或者没有烧对，插错）
2、逻辑未烧或者错误
3、版本文件错误或者缺少版本
4、版本和数据库中的版本对应不上
5、内存条未插好、损坏或者硬盘等硬件损坏
6、IP地址冲突或者数据设置错误
7、机框拨码错误
二.3传输类故障排查思路
二.3.1排查前首先要确认的信息：
1、检查设备间物理连接的正确性。
主要是检查所对接的两个设备之间的电缆正确性，防止电缆的漏焊、虚焊、接触不良，特别是要防止电缆的混线。
电缆混线会在两处设备侧产生一些异常现象，所以一定要首先保证物理连接的正确性。
2、检查双方对接设备的接地和共地情况
如果设备接地不好，将会直接影响对接。
接地存在的问题通常为：
两个对接的设备未能真正的共地；DDF配线架未按要求接地。
要检查两个对接设备的共地情况，可测量两设备的接地点之间电阻的大小或两个接地点之间有无电位差。
对接不成功时请重点检查两设备是否真正共地。
许多对接不成功的的现象，最后的原因都是两个设备未能真正的共地。
3、检查同轴端口的屏蔽层接地
75Ω非平衡式同轴端口的外导体（即屏蔽层）常规的接地方法是发端接PGND（保护地）、收端悬空（或接PGND）。
可用万用表测试同轴端口的屏蔽层与设备PGND之间的电压，就可以大致判断出同轴端口屏蔽层的接地方式。
如果屏蔽层接地不好，会由于两个地（BGND、PGND）之间存在电位差和交流干扰，从而影响信号对接时的波形，导致对接不成功。
对接不好时要检查双方设备的同轴端口屏蔽层的接地方式是否一致（PGND指保护地，BGND指工作地）
二.3.2不同情况的告警处理
1、对于在告警后台一直存在并不可恢复的告警
a）如有LOS（信号丢失）告警：
首先检查本端设备E1电缆连接是否正常，收发连接是否正确，DDF配线架上E1线连接是否正确。
如果这些都正常，请传输检查发送给本端的信号是否正常。
b）如有AIS（告警指示信号）告警：
首先确认该条E1有没有进行对接，如果没有进行对接，请在配线架上自环该条E1或者取消该子单元的配置。
如果有对接局向，请对端局检查跟传输设备的连接情况。
c）如果有LOCMF（复帧失步）告警：
请确认两端配置的帧格式是否一致。
d）如果有RAI（接收远端告警）：
检查本端的发送是否正常，请对端看对应的告警信息。
如果确认本端发送正常，对端接收有相应告警，请传输配合查故障原因。
2、对于不间断频繁上报又马上恢复的告警类
a）如有LOS（信号丢失）告警：
首先检查本端设备E1电缆连接是否正常，收发连接是否正确，DDF配线架上E1线连接是否正确，是否接触不好或者有串线。
如果这些都正常，请传输检查发送给本端的信号是否正常。
b）如有AIS（告警指示信号）告警：
这种情况本端设备正常，请对端局检查跟传输设备的连接情况，传输设备上是否有相应的告警。
c）如果有LOF（帧失步）、LOCMF（复帧失步）告警：
首先检查本端设备E1电缆连接是否正常，收发连接是否正确，DDF配线架上E1线连接是否正确，是否接触不好或者有串线，配线架上静电地是否正常。
如果这些都正常，请对端也检查这些内容。
d）如果有RAI（接收远端告警）：
检查本端的发送是否正常，请对端看对应的告警信息。
如果确认本端发送正常，对端接收有相应告警，请传输配合查故障原因。
如果对端没有相应告警信息或者看不到，进行环回诊断。
如果上述方法都不能解决故障，需要逐级进行环回诊断。
如果环回诊断查不出原因，需要逐级挂表定位。
3、对于在某个时间段集中上报并恢复的告警
请确认这个时间段对端局是否有相应操作，中间传输设备有相关操作，有什么相关告警。
只要不是多次出现这种情况，可以确认本端设备没有问题。
4、对于随机性零星的告警并恢复
对于偶尔出现的告警（概率很低，比如几天或几十天出现一次），没什么规律性，一般是正常情况，标准规范也允许。
对于比较有规律零星出现告警的情况，只能通过挂表进行定位原因。
二.3.3环回诊断法
1、在本端设备侧的DDF架进行故障E1自环（如下图中1所示），如果故障消失，基本上说明故障源不在本端，进行下一步诊断。
2、请对端局DDF架物理环回给本端（如下图中2所示）或者软件设置远端环回（如下图中3所示）把信号环回本端，如果故障消失，基本说明中间传输设备没有问题，故障在两端设备的配合上。
如果故障还在，说明跟对端设备没有关系，故障原因基本上在中间传输设备。
3、当确认故障原因为中间传输设备时，请传输维护人员协助进行逐级环回诊断。
二.3.4仪器诊断法
如果环回诊断不能定位原因，需要进行挂表诊断
1、在本端挂表，测试仪接对端传送过来的E1信号，检查传输送过来信号是否正常。
看仪器是否有相应告警或误码，如果有说明故障原因不在本端，而是在对端或传输。
2、本端挂表没问题，可以让对端挂表，请对端进行同样方法检测。
3、如果最终定位原因在中间传输设备上，需要传输维护人员配合检查诊断。
二.3.5更换单板法
如果故障集中表现在某一块单板上，可以考虑先更换单板，看故障能否解决。
第三章典型故障案例
摘要
本章介绍了RNC设备在时钟、硬件启动、传输等故障的故障现象、故障原因分析和故障处理方法等。
三.1时钟类典型案例
三.1.1CLKG有“二级时钟基准丢失告警”，时钟一直处于自由震荡的工作模式。
【故障现象】
韩国SKT项目的CLKG告警无法消除，时钟一直处于自由震荡的工作模式。
网管告警为：
（1）InputClockAbnomal
（2）Clockbaselostsecondlevel
【原因分析】
发现CLKG板有时钟告警后，首先按照指导书配置（从APBE板过来的时钟线连接到CLKG的8KIN1）检查了OMCR上配置的时钟基准，发现配置的“设定主用时钟基准为8kbase”，而“配置的所有时钟基准”为两个“8kbase”和“8kGPS”，两者均改成时钟基准为“8kbase”，但是之后观察告警仍未消除，因为时钟板上有“InputClockAbnormal"告警，因为我们的时钟是从CN获取，所以联系三星的核心网工程师，三星工程师说CN有一块板子没上电，等处理完成之后，RNC的CLKG单板仍然有上述告警。
接下来检查时钟提取光口和网管配置是否一致，目前从CN提取时钟的端口可配置，默认为APBE板的4号光口（第一个口）,可以根据实际和CN连接的端口进行修改，网管上修改位置如下，在APBE板上点击右键菜单，选择修改，在单板的“基本信息”页面里面，有线路时钟基准，数值有0～3，分别对应APBE端口4～7。
配置结果可通过探针查看r_unit.info前台生效是哪个端口，此r_unit.info表显示提取线路时钟的光口号（0~3），分别对应4,5,6,7光口；检查后发现CN连接的是5号口，但是网管配置的是从4号口提取时钟，导致提取失败。
【处理方法】
在网管配置中改为从5号口提取时钟，故障解决。
备注：
如线缆连接到8kin1，则将后台“配置主用时钟基准”为8kbase，“所有时钟基准”只有8kbase。
如是8kin2，则上述两个配置应该都为8KGPS。
配置结果可以通过探针查看R_SETTING表，此表字段含义：
第一个DWORD表示时钟的工作模式（注意：
目前本字段无作用，需要屏蔽配置）
0：
CLKG_WORKMODE_FASTCAPUTRE（快捕）
1：
CLKG_WORKMODE_TRACE（追踪）
2：
CLKG_WORKMODE_KEEPUP（保持）
3：
CLKG_WORKMODE_FREE（自由）
第二个DWORD表示是否配置设置主用时钟基准
0：
CHANG_BASE_FORBIDDEN表示否，此时第三个DWORD无效
1：
CHANG_BASE_ALLOWED表示是
第三个DWORD表示需要设定主用时钟基准类型
0：
BASE_2Mbits0
1：
BASE_2Mbits1
2：
BASE_2MHz0
3：
BASE_2MHz1
4：
BASE_8K1
5：
BASE_8K2
6：
保留
第四个DWORD表示所有可能使用的时钟基准（注意：
本字段的含义不是备用时钟基准，将对本字段包含的时钟基准是否丢失进行检测告警。
必需对配置的主用基准是否丢失进行检测，因此：
如果第二个DWORD配置设置主用时钟基准，本字段应该自动包含第三个DWORD中配置的时钟基准）
Bit0=1/0：
设置/未设置BASE_2Mbits0
Bit1=1/0：
设置/未设置BASE_2Mbits1
Bit2=1/0：
设置/未设置BASE_2MHz0
Bit3=1/0：
设置/未设置BASE_2MHz1
Bit4=1/0：
设置/未设置BASE_8K1
Bit5=1/0：
设置/未设置BASE_8K2
Bit6～Bit31预留
三.1.2RNC时钟板有时钟基准丢失告警
【故障现象】
沈阳浑南机房四个RNC时钟板均存在时钟基准丢失告警
【原因分析】
通过观察面板灯，CLKG板实际是在跟踪状态的，一切正常。
经检查是RNC数据配置有问题，浑南机房的RNC连接8KIN1的APBE板没有和CN对接，连接8KIN2的APBE板和CN对接是正常的，而网管配置的时钟基准里两个都配上了。
“设定主用时钟基准类型”为8kBase也就是对应后插卡8kIn1端口为主用时钟基准，“配置的所有时钟基准”为48也就是对应后插卡8KIN1和8KIN2端口，从界面上的理解是：
启用8KIN1和8KIN2时钟基准，但是以8KIN1为主用时钟。
而实际只有8KIN2的输入，造成网管的告警。
【处理方法】
修改网管配置，去掉8KIN1的基准，告警消失。
【备注】
网管可以配置两个时钟基准，但是主用时钟基准只有一个。
目前平台支持2级钟和3级钟，2级钟和3级钟有相应的标准。
2级钟在时钟基准丢失的情况下，锁定当前输出，不自动切换时钟基准，但可以手工切换。
3级钟在时钟基准丢失的情况下，会自动切换时钟基准（不推荐这种方式，如果倒换系统会发生时钟抖动）。
以后平台会支持每一路时钟基准从两个光口提取，即可配置从APBE的４、５两个光口提取线路时钟，这样解决了APS保护的问题。
三.2启动类典型案例
三.2.1整个机框的单板运行均不正常
【故障现象】
青岛扩容涉及到扩单板和机框，开通时发现2架－3框的所有单板运行均不正常，在后台发现所有的单板都有不在位告警。
【原因分析】
检查CHUB的连线经过逐一拔掉查看CHUB单板指示灯的状态，发现CHUB的连线正常，检查机框的拨码开关，发现该机框被拨成1架－3框；拨成2架－3框后正常。
【备注】
每个机框上都有拨码开关，拨码开关位于机框的左上角，新机框一般有一块金属板挡住，需要拧掉螺丝，卸下面板才能看到，如下图所示：
拨码开关有三个，从左到右分别对应局号拨码开关、机架号拨码开关、机框号拨码开关。
机架拨码开关按下述方式进行设置：
对于每一个拨码开关，左边代表低位右边代表高位，拨码开关是左低右高。
拨到上部代表0，下面代表1。
数据库的配置是从1开始的，而拨码开关是从0开始，所以拨码开关对应的值加1才是机架号的具体值。
单板对应的控制面IP地址计算方法为如下：
对于每一个拨码开关（图中黑色的部分代表拨码开关中的拨杆）
左边代表低位、右边代表高位，拨码开关是左低右高；
拨到上面代表0、下面代表1；
实际的局号等于拨码读出值；
实际的机架号、机框号需要在拨码读出值的基础上加1。
局号为BurNo，机架号为RackNo，机框号为ShelfNo，槽位号为SlotNo
（其中BurNo、RackNo、ShelfNo为背板上读出的数字，而实际的局号为BurNo、机架号为RackNo+1、机框号为ShelfNo＋1）
那么该槽位对应单板的控制面IP地址为：
128．BurNo*16＋RackNo．ShelfNo*32+SlotNo．CPUNo*8＋1
这里CPU编号范围为0～3
例如背板上的拨码设置为：
BurNo100、RackNo0000、RackNo1000（即1局1架2框），举例计算单板的IP地址为：
1局1架2框11槽RPU的控制面IP地址为：
128.1*16+0.1*32+11.1*8+1（128.16.43.9）（第二个CPU）
1局1架2框9槽UIM的控制面IP地址为：
128.1*16+0.1*32+9.0*8+1（128.16.41.1）（第一个CPU）
【注：
计算IP地址时，是按照实际的拨码数值来计算的；而我们说局、架、框时是按照背板上拨码相应的局号、机架号＋1、框号＋1来描述的】
三.2.2RPU不能启动故障一例
【故障现象】
青岛RNC1601版本升级，在版本包入库、下载、激活后，重启单板。
OMP正常运行，但RPU在不停的重启。
【原因分析】
1、检查激活的版本包里有RPU的版本
2、在OMP的/IDE0/RELEVER目录下可以看到要升级的RPU版本
3、用串口线连接ROMP的串口上，查看RPU的启动信息发现如下信息：
TimerTasksendtimermessageok!
BootTask'sTimerEV_TIMER_CPU_VERINFO_REQisup!
BootTasksendto128.0.31.9msgsucc!
TimerTasksendtimermessageok!
BootTask'sTimerEV_TIMER_CPU_VERINFO_REQisup!
BootTasksendto128.0.31.9msgsucc!
TimerTasksendtimermessageok!
BootTask'sTimerEV_TIMER_CPU_VERINFO_REQisup!
BootTasksendto128.0.31.9msgsucc!
TimerTasksendtimermessageok!
BootTask'sTimerEV_TIMER_CPU_VERINFO_REQisup!
Sendtimesis10!
BeforeBoardreset!
Boardreset...!
从RPU的启动信息可以看到，RPU要版本了，连续要了10次，没有要到，系统再进行单板重启。
4、检查OMP里的版本配置情况，发现如下信息：
MPX86_2->SCSShowVmmDownInfo
BureauRackShelfSlotCpuPowerTimeStateMsgNameResult
12222840M_WorkEV_NEW_CPU_VERINFO_REQVMM_VERMAP_NOT_CONFIG
12212840M_WorkEV_NEW_CPU_VERINFO_REQVMM_VERMAP_NOT_CONFIG
12242841M_WorkEV_NEW_CPU_VERINFO_REQVMM_VERMAP_NOT_CONFIG
12211841M_WorkEV_NEW_CPU_VERINFO_REQVMM_VERMAP_NOT_CONFIG
12221841M_WorkEV_NEW_CPU_VERINFO_REQVMM_VERMAP_NOT_CONFIG
12241842M_WorkEV_NEW_CPU_VERINFO_REQVMM_VERMAP_NOT_CONFIG
112122854M_WorkEV_NEW_CPU_VERINFO_REQVMM_VERMAP_NOT_CONFIG
从命令显示里可以看出1架－2框－12槽位－CPU2的版本没有配置（该RNC使用1架－2框－12槽位的OMP作为主用OMP），即数据库没有配置RPU的版本。
这样RPU重启时向OMP要版本，因为数据库没有配置，所以要不到版本。
【故障解决】
检查网管数据库UEP用户下TRNC_VERMAP表，选择RNCID=1601和RNCID=0比较发现，在RNC=1601里少了几条记录。
下面的两张图是RNCID=0时的VERMAP，共51条记录。
而RNCID=1601的VERMAP表里记录只有46个，经比对少了LBRDTYPEDB＝5000/5001/5002/5003/5004的记录各一条。
在VERMAP表中加上该条记录，进行数据同步后，RPU启动正常。
三.2.3备用OMP不能正常运行
【故障现象】
北京马连道机房RNC2 备用OMP（1架－2框－11槽位）不能正常运行，显示的告警信息是：
后插卡错误，和前插板不匹配。
【原因分析】
接上超级终端看到如下打印信息
LoadFPGAVerFile...
CheckMOMP'sPCBNumandfpgaversion（fpga.ini）...!
...Fpgaverifyerror!
Fpgaverifyerror!
...Fpgaverifyerror!
MasterOMPFpgaFlashbootfailed!
!
从中可以看出FPGA版本校验错误。
经检查主备OMP的FPGA版本不同（分别是040703和040704），将OMP的FPGA版本更新一致后备用OMP正常运行。
三.2.4RCB不能正常运行
【故障现象】
北京马连道机房RNC3有3个RCB板不能正常运行
【原因分析】
在RCB后面插上后插板，连超级终端检查发现如下打印消息：
AttachedTCP/IPinterfacetofei2.
SucceedSetfei2to100M|FD.
Attachingnetworkinterfacelo0...done.
Bootingfromnetwork
Loading...
Errorloadingfile:
errno=0x3c.
Can'tloadbootfile!
!
正常的为：
AttachedTCP/IPinterfacetofei2.
SucceedSetfei2to100M|FD.
Attachingnetworkinterfacelo0...done.
[B
升级会员 