NOKIA基站故障处理-案例分析

第五章案例分析：故障案例分析一：驻马店市区刘阁基站（DE34）TRX2有7533告警（TX ANTENNA OR CONBINER CONNECTION FAULTY）由于连接在同一个合路器上的TRX1工作正常，初步判断AFEA 没有故障，TX连线紧固，则判断可能是TRX坏或者TX连线坏，更换TRX后故障解除。

但是到3月9号，TRX2再次出现7533告警，由于TRX为新换的，TX连线无故障，分析认为合路器AFEA不稳定，存在隐患，更换AFE后故障解除，没有重复出现。

故障案例分析二：西平人和基站（DE34）BCFA故障，更换后无法自启，检查发现软件包不对应（使用的板件是返修的库存板件，没有考虑软件包问题），灌入对应软件包重启后，Sec2和Sec3无法正常工作，其中Sec2的TRX7正常，而TRX8和Sec3的TRX9和TRX10均有7514告警（13MHZ CLOCK IS MISSING IN TRX）按照Nokia告警处理提示应更换TRX，但三块TRX同时坏的可能性不大，考虑可能为其他原因引起。

于是将Sec2正常运行的TRX7和出故障的TRX8倒换位置，（操作过程中对该层PSUA断电）结果Sec2两块TRX均恢复正常。

于是将Sec3的PSUA断电再加电，该扇区亦恢复正常。

分析认为有时TRX内部软件需要重新掉电初始化。

这一点和后来改半速率过程中，有些DE34站虽然数据与BSC完全对应，仍然出现OMU信令不活的现象类似，出现这种情况时，对基站供电单元CSUA掉电再加电就可以解决。

故障案例分析三：遂平红堂基站（UltraSite）O改S后，Sec1一直占不上用户，且有7602（Mismatch between BSC/MMI configuration file and the actual）告警，经检查发现，硬件数据库中Sec1的数据不完整，补充完整后再上传进去，重启BCF，故障解除。

故障案例分析四：妇幼保健院（ULTRASITE）断站，且断站时有7606告警，告警提示为合路器反射功率过高。

根据以往经验，产生这个告警的原因有两种，驻波比过高或合路器坏，测试驻波比正常，更换合路器重起基站后告警消失，后期观察没有再出现这个告警。

故障案例分析五：市区502基站（ULTRASITE）的SEC3反复闪断，有7705，7706，7723，8102等告警。

到基站后发现传输板时而亮黄灯，时而亮绿灯，并且掉话非常明显。

因为有传输告警，所以先从传输板、传输连接件和传输线考虑。

自环传输板正常，检查DDF架。

结果发现DDF架的2M接头松动，紧固后传输板没有再出现间歇性闪烁，基站正常运行。

故障案例分析六：驻马店市区关王庙基站（UltraSite）的Sec2反复出现7604告警（Rx levels differ too much between main and diversity antennas），造成严重掉话。

测量天线驻波比正常，更换宽带合路器WCGA和双工器DVGA仍不能解决，对基站主设备彻底检测确定正常，检查天馈部分，发现馈线进入机房后的接头处松动，重做接头并紧固后告警消除。

对此故障分析认为，有时天馈系统的驻波比正常，并不能说明故障一定不是出在天馈系统。

有些并不严重的连接松动情况可能无法在驻波比中显示。

因此在处理这类故障的时候，测量天馈系统的参数只是判断故障的一个参考，还需要对连接部分进行仔细的检查。

故障案例分析七：西平后吕基站（DE34）白天更改硬件，加载频，数据更改完之后，夜间重启后无法起站。

经现场检查，发现硬件数据库中的TRXSIG速率不对，更改后恢复正常。

据机务员改动数据的过程，发现一个平时没有特别注意到的一个细节问题。

DE34基站在在硬件数据库上改动TRX的位置或者添加、删除TRX时，TRXSIG速率会自动更改为全速率数据及16K，故需要手动更改为半速率数据32K之后再上传。

故障案例分析八：确山、泌阳割接故障处理：割接之后以下基站不能起站：泌阳白果树、泌阳梅林、泌阳条山、泌阳老邱洼、确山桐树园。

现象都是OMU信令不活。

故障处理：泌阳梅林—从基站环路，SXC上ET灯熄灭；断开，入信号丢失灯亮；放通，ET灯熄灭。

即，看起来，基站到SXC线路正常。

机房确认BSC到SXC正常，交叉连接数据也正确。

机房和基站对OMU信令时隙一致，看起来，线路和数据都正常，怀疑起不来是基站吊死或数据丢失。

但是机务员冷起过基站，重做过数据，重做过开通，信令还是不活。

而且基站作模拟开通，基站能够起得来，说明基站主设备没有问题。

现在故障只能定位到物理线路上了，于是联系传输机房改落地DDF架位置，之后信令活，起站正常。

而之后，在处理白果树基站故障时，发现白果树从基站落地DDF架到SXC环路不正常，这是环原梅林落地，两个ET灯同时熄灭。

原来梅林和白果树SXC——交叉机侧DDF架线鸳鸯所致。

泌阳条山—该站有2个机柜，2条传输，第一个机柜OMU信令在7、8时隙，第二个机柜OMU信令在1、2时隙。

当晚看到OMU信令不活，怀疑是2个传输弄反，于是改了SXC 数据，结果还是不活。

待上午，机务员到站上环路发现，后来的连接是错的，又改回之前的连接，信令活。

本人认为可能是传输设备吊死，到基站环路相当于重新激活一下。

泌阳老邱洼—根据之上的处理经验，我们先查传输线是否鸳鸯，结果发现是落地线鸳鸯。

故障案例分析九：泌阳秦老庄边改宏后基站不能正常工作。

到基站后从表面看BCFA亮红灯，TRUA指示灯正常。

对基站自身重启后出现7829（A-BIS及D-BUS接口连接失败）告警，分别更换BCFA 板及后备板BUS线但告警依旧。

然后考虑可能是BCF无法控制到的TRUA单元存在问题，更换TRUA后重启告警消失，基站恢复正常。

故障案例分析十：汝南综合楼SEC3所有载频均出现7745告警，掉话严重，并且有7601告警，到基站后经过检查发现时钟偏移严重，更改时钟DAC数模转换值，将13MHz时钟调整到误差允许范围内，重启BCF后正常，可不久又再次出现时钟偏移现象。

检查数据发现是由于没有设置传输板的时钟同步造成的，（汝南机务员在前一天处理8150告警时更换了传输板）。

设置传输同步并重作开通后基站恢复。

对此故障的处理反映出一个问题，就是我们在更换基站的板件时，一定要注意对此板件的配置，还要注意更换板件是否对其他板件的配置产生影响。

基站系统是一个整体，要注意板件之间的关联，这样才能使整个系统运行正常。

与此类似的故障还有一例：汝南陶桥（DE34）新开基站,开站时传输板一直亮黄灯，信令不活。

检查数据库、分支表、BCF接口设置都正确。

因此考虑传输原因，从DDF架直接环到交换机房的ET，状态正常，对基站自环传输板亮黄灯，初步判断可能是传输板故障，更换传输板后情况相同。

最后注意到两个传输板都比较新，考虑可能是传输板没有格式化。

于是对传输板进行格式化，重新配置分支表并激活，传输板恢复正常。

分析认为：随着DE34数量越来越少，传输板大多是旧板返修过的，一般不用进行格式化。

但如果是全新的板子，就需要对其进行格式化之后再配置数据。

故障案例分析十一：泌阳消防队(UltraSite)O改S后基站没有告警但是一直起不来，只有Sec3有两块载频能起来。

到现场检查基站数据完整，比较发现，能起来的载频基带部分为BB2A，其余载频基带部分均为BB2F，于是怀疑BSC软件包版本偏低，与交换机房交流证实了是软件版本原因，机房更换高版本软件包后重启，基站恢复正常。

此故障说明，我们在处理故障时一定要注意到细节的问题，善于比较和分析，这样对一些虽然有故障却并没有相关告警提示的障碍才能做出快速准确的判断。

故障案例分析十二：市区刘阁基站（ULTRA）扩容，与机房联系后知道TRX8位置为空位，到基站后加上载频，把相应的数据库和分支表做全后，重启基站，发现第TRX8一直不能被BOIA识别，重新检查软件和硬件确认无误后，故障依然存在，和TRX6调换后，该载频在TRX6位置可以被识别，TRX8位置的载频仍然不能被识别。

建到第10块空位置后，也不能被识别，因此判断是下面六块的公共部分。

使用的是DVGA和WCGA，检查电源BUS线并更换后，故障依然存在，检查从主控层到下面两层的BUS线，发现连接下层载频的BUS线断裂松动，重新紧固后重启，基站恢复正常。

故障案例分析十三：汝南陶桥(DE34)断站，O3配置,合路器用的是RTC ,起站过程中BCCH信令在TRX1,TRX2,TRX3上来回跳跃，基站起来后随即中断，且有7842关于合路器的告警，更换RTCC后重起告警消失，基站恢复正常。

故障案例分析十四：西平南王庄(UltraSite)新开基站，开站后机房通知SEC2，3占不上用户，且没有和设备相关的告警。

到站后检查发现BIOA中没有硬件数据库数据，重做数据库并上载后基站正常工作。

分析原因可能是灌完数据库后没检查，而数据库又没有正常灌入；另外一种可能是NOKIA工程师做数据库时用的Nokia BTS Manager是4.0 版本，由于配套设备不同步，没能及时开站，后来开站时对基站做开通所用的Nokia BTS Manager是3.3.3版本，这种情况下会导致数据库丢失。

故障案例分析十五：市区农行基站（MetroSite）传输板出现故障，经常闪段，需要更换传输板，可BTS Manager 一直连接不到基站，测量连接线正常，检查电脑com口也正常，后来在File项下Options 子项中把com口的连接速率从115200改为9600，顺利连接到基站。

如下图所示：后来市区新华书店基站（ConnectSite）也出现连接不上故障，修改连接速率后便顺利连上。

故障案例分析十六：驻马店市区工行产生7601 BCF OPERA TION DEGRADED告警和7607 Fault in the chain between power unit and MHA告警，到站后发现告警情况如下图示：检查硬件数据库发现把MHA Type设置成了High gain MHA，而实际没有使用MHA，更改数据并上传后故障解决。