爱立信基站典型故障处理案例

在确认马厂湖基站的数据存在掉死的情况后，重新定义了新的TG数据，来替换原先存在掉死现象的TG数据，整个基站恢复正常运行。
对上述基站数据掉死的解决办法还有一种是进行BSC的重新启动，因为需要在晚上进行，因此可能会导致基站退服的时间较长。
案例4：中国银行基站第2小区对应的机架为2个CDU C，4个载频配置，总是在4个载频全部开起来后，又很快全部退服，现象为第1、2个TRU状态为TX not enabled，第3、4个TRU为Fault灯和Operational灯同时亮。每次对DXU进行复位，总是出现上述的同样现象，整个小区无法正常运行。
总结：针对多机架级联的基站，第2、3小区退服的情况，要考虑前一级级联的小区所在的机架是否存在DXU故障、PCM传输电缆接错、IDB数据中未定义PCM级联等情况。
案例7：某个基站第2小区有3个时隙LMO状态为0800，复位和更换载频后无效。
检查基站的定义数据，发现第2小区对应的TG-139，在定义半永久连接关系时，将RBLT-1309与DCP 28连接是错误的，导致DCP 28相对应的4个TS时隙，无法正常工作。应该是RBLT-1308与DCP 28连接，正确修改后，故障解除。
因为第3、4个TRU总是出现故障现象，将这两个TRU更换，仍然出现同样的故障现象；更换第3、4个TRU对应的第2个CDU C，仍然出现同样的故障现象。
将第3、4个TRU放到第5、6个TRU的位置上，将第2个CDU放到第3个CDU的位置，这样载频的位置为第1、2、5、6，甩开TRU第3、4位置不使用，整个小区正常运行，不再出现上述故障现象。
首先全面检查基站硬件、传输设备、传输电缆等均没有发现问题，检查柳行头基站数据、小区数据定义也没有发现问题，更换DXU也不能解决问题。
从BSC的ETC传输接口处将柳行头基站的传输同另外一个相同配置且正在运行的松峰基站传输互换，不必改动任何数据，也就是说互相用对方基站的数据来开通。柳行头基站的数据在松峰基站上运行正常，而松峰基站的数据却无法在柳行头基站上运行，这就可以说明柳行头基站的数据不存在错误、掉死等异常情况，而从BSC到柳行头基站的传输通路上存在问题，也可能是基站硬件存在问题（这已排除）。
点检查了基站的所有硬件均不存在故障现象，对怀疑有问题的TRU、DXU进行了更换；对传输进行了环路测量，也未发现传输电路存在质量问题；检查小区、基站的定义数据也都正常。怀疑基站的数据存在掉死的现象，但没有确凿的证据。
尝试用另外一种方法进行故障的定位。从BSC的ETC传输接口处，即ETRBLT板子2M接口处将马厂湖基站的传输DIP=97同另外一个类似配置的基站装载机厂的传输DIP=98直接进行互换，也就是说互相用对方基站的数据来开通基站。互换后发现，马厂湖基站的数据在装载机厂基站上仍然存在同样的问题，而装载机厂基站的数据在马厂湖基站上却能正常工作。这就可以说明，马厂湖பைடு நூலகம்站的硬件、传输均不存在问题，基站数据确实存在掉死的现象。
解决办法有两种：一种是将RBS200基站使用的SDH传输更换为PDH传输；另一种是将RBS200基站设备更换为RBS2000基站设备，因为RBS2000对同步要求较RBS200低，能够很好同SDH传输配合工作。
案例3：开始时，马厂湖基站有部分TS总是无法正常工作，且不固定在某个载频上，更换TRU、DXU无效，对基站的数据进行拆掉重新加载后仍无效，后来整个基站所有的TS均无法正常工作，基站硬件、传输、数据等均不存在问题。
解决的办法是，将DXU（或新的DXU）放到同基站的其它机架上，或另外的基站上，仅对DXU加电，按照存在问题的机架配置进行IDB的重新配置，完成后再安装到存在问题的机架上，不必再重新配置，对DXU等各模块加电重起，即可解决问题。
案例2：RBS200基站工作不稳定，经常退服。
基站各部件的稳定工作离不开稳定的时钟信号，而基站的时钟信号是从PCM传输中提取的，爱立信的基站不提供外部时钟输入的端口, RBS200基站是爱立信早期推出的GSM基站产品，这些基站设备是基于采用传统的PDH传输组网方式而设计的，并不非常适用于SDH传输组网方式，这就会导致RBS200基站在和某些厂家的SDH传输设备配合使用时，导致基站工作不稳定，频繁出现时钟同步的告警，经常退服，严重影响了基站的正常运行。
还有一个例子也是存在故障的TRU导致其背板连接的总线工作异常的情况：某小区新扩一个机架，载频由6个扩容到7个，但是每次启站时总是很快出现驻波比过高的基站告警，所有载频全部退服，故障原因是新扩的TRU（在新扩的副架上）存在问题，虽然表面状态均很正常，但是把它插到机框内加电后，就会干扰背板总线的正常工作，导致出现整个小区驻波比过高的问题产生。
考虑到B小区是级联A小区的，即PCM传输电缆从A小区DXU的G.703-2端口连接到B小区DXU的G.703-1端口，这段传输通路是否存在问题？更换这段通路上的所有传输电缆，仍不能解决问题。再向前考虑一步，是不是A小区DXU的G.703-2端口存在问题，虽然没有故障状态显示？更换A小区的DXU，重新配置IDB数据后，问题解决。
检查基站硬件设备，及传输设备均未发现异常，更换DXU也无法解决问题。在基站上进行故障处理时，发现老式的爱立信开关电源存在模块损坏的情况，但仍能正常工作。经过长时间现场观察，发现交流电压不稳定，忽高忽低，当电压过高时，开关电源的过压保护器便跳脱保护，爱立信开关电源所有的模块处在过压保护的状态，同时传输设备瞬间复位，导致基站瞬断。此时就发现了交流电压过高可能是导致盲校基站瞬断的原因。
怀疑新增扩的2个TRU虽然状态显示正常，但仍然可能存在问题，导致XBbus工作异常。由于A小区的主架的6个TRU和副架的2个TRU间已多次互相倒换位置来排除TRU的问题，已经不能分清哪2个TRU是新增扩的。于是将A小区的所有8个载频全部替换，问题解决。
总结：某个存在故障的TRU可以导致其背板连接的总线工作异常，在这个案例中，导致了XBus工作异常，小区不能打开跳频，但是此TRU的状态显示完全正常。解决办法是替换怀疑有问题的TRU，尤其是新增扩的TRU，不要采取在有问题的小区内互相倒换的方式，因为存在故障的TRU无论在那个位置均可以导致同样的故障现象。应该用其它小区或新带来得TRU替换。
基站数据定义看起来不存在问题，其它检查也做了很多，但基站仍然不能开起来。重点检查基站DIP所连接的SNT的DEVICE数据定义，会发现RBLT的状态不对，为MBL闭掉的状态，试图解闭，可能还会发现未完全定义，再用EXDAI、EXDUI指令进行补充定义，解闭此SNT所带的RBLT，再重新LOAD基站数据后问题解决。
根据以上处理过程进行分析，应该是第2个CDU C对应的CDU BUS总线或第3、4个TRU对应的背板存在问题，导致第2个CDU C不能正常工作，不仅导致第3、4个TRU不能正常工作，而且导致整个小区不能正常工作。
将第2个CDU C对应的CDU BUS总线拆下来，更换一新的CDU BUS总线后，故障解决，确认是第2个CDU C对应的CDU BUS总线存在问题。
针对出现的XBus Fault告警，重点检查了新增扩的机架TRU和DXU背板跳点设置，CDU BUS的连接情况，均未发现异常，更换DXU也不能解决问题。考虑到当时是在上午忙时，此小区承担的话务量很高，有可能是因为A小区重起时接入用户太多导致负荷过高而不能以跳频方式正常运行，设置A小区参数CB=YES禁止待机时手机接入，设置A小区为Layer=3小区限制其它小区手机用户向A小区切换，这样的参数设置曾经解决过类似大容量小区在打开跳频的情况下忙时重起困难的问题，但仍不能解决沂水城东A小区的问题。
（2）某个基站第3小区2个时隙LMO状态为0800，复位无效：
第3小区的2个时隙的故障原因是在定义基站数据时，MO CF的参数SIG=UNCONC错误，因为所有的TRX的SIG=CONC，导致TG分配的DCP不够用。将MO CF的参数该为SIG=CONC，故障消除。
案例8：某个新建基站传输状态正常，硬件也不存在问题，但基站开不起来
这样重点怀疑从BSC到柳行头基站的传输通路上存在问题，需要仔细检查，传输维护人员从BSC往基站方向一段一段进行检查，果然发现在北园传输机房处柳行头基站的传输跳线存在问题，120欧姆4根信号传输线中的一根与配线端子处在似接触非接触的状态，重新卡接后，柳行头基站CF软件load成功，基站顺利开通，问题解决。
对新建基站开不起来的情况，还有BSC侧MO=RXOCF的TEI值与基站OMT软件定义的不一致，导致基站无法同BSC建立联系。此种情况较多的出现在级联基站上，重新定义，使基站的TEI值同BSC侧定义的TEI值一致便可解决问题。
案例9：盲校基站存在瞬断现象，导致信道完好率虽然很接近但达不到100%，同时基站传输设备也出现传输瞬断的现象。
需要注意的是，基站电路环路时是通的，并不能代表基站电路完全不存在问题，因为还存在类似上述传输信号线接触不好、远端告警等一些特殊的传输故障现象。
案例6：付庄基站为3个RBS2202机架级联、4/4/4配置，故障现象为B小区退服，复位后B小区恢复正常，但几小时后又再次退服，基站不存在任何告警。如此反复，B小区工作状态很不稳定。
因为是在基站运行中出现的故障，所以首先怀疑是B小区DXU出现故障，但是更换后仍无法解决。检查B小区的射频电缆、PCM传输电缆、CDU总线均无异常。通过OMT软件监测付庄基站3个机架DXU的PCM连接状态均正常。
类似的故障现象可能还有如下的故障原因：
（1）某个基站第2小区4个时隙LMO状态为0800复位和更换载频无效：用DTIDP指令检查DIP的定义数据，发现MODE=1是错误的。RBS200基站的DIP定义为MODE=1，即传输的第16时隙仅用于传信令，不用于传话音。而此基站为RBS2000基站，正确的定义是MODE=0，如果定义为MODE=1，会导致DCP 16，即传输的第16时隙不能正常使用，出现上述的故障现象，或者导致用户占用时出现单通现象。
爱立信基站典型故障处理案例