爱立信基站典型故障处理案例分析.doc

爱立信基站典型故障处理案例
案例1：对基站进行IDB的配置总是无法完成，提示为时间超时。当对基站进行IDB数据的配置时，因为TRU与DXU软件版本不一致，或BSC下载软件的同时进行DXU数据配置而产生冲突，或第一次IDB配置电源电压类型错误，或短时间内频繁的对DXU进行IDB配置等原因，偶尔可能导致再进行IDB的数据配置时，出现提示为时间超时而无法完成的现象。导致DXU同机架内部的通信上存在异常现象，出现类似机架掉死的现象，更换DXU无效。解决的办法是，将DXU（或新的DXU）放到同基站的其它机架上，或另外的基站上，仅对DXU加电，按照存在问题的机架配置进行IDB的重新配置，完成后再安装到存在问题的机架上，不必再重新配置，对DXU等各模块加电重起，即可解决问题。案例2：RBS200基站工作不稳定，经常退服。基站各部件的稳定工作离不开稳定的时钟信号，而基站的时钟信号是从PCM传输中提取的，爱立信的基站不提供外部时钟输入的端口,RBS200基站是爱立信早期推出的GSM基站产品，这些基站设备是基于采用传统的PDH传输组网方式而设计的，并不非常适用于SDH传输组网方式，这就会导致RBS200基站在和某些厂家的SDH传输设备配合使用时，导致基站工作不稳定，频繁出现时钟同步的告警，经常退服，严重影响了基站的正常运行。解决办法有两种：一种是将RBS200基站使用的SDH传输更换为PDH传输；另一种是将RBS200基站设备更换为RBS2000基站设备，因为RBS2000对同步要求较RBS200低，能够很好同SDH传输配合工作。案例3：开始时，马厂湖基站有部分TS总是无法正常工作，且不固定在某个载频上，更换TRU、DXU无效，对基站的数据进行拆掉重新加载后仍无效，后来整个基站所有的TS均无法正常工作，基站硬件、传输、数据等均不存在问题。点检查了基站的所有硬件均不存在故障现象，对怀疑有问题的TRU、DXU进行了更换；对传输进行了环路测量，也未发现传输电路存在质量问题；检查小区、基站的定义数据也都正常。怀疑基站的数据存在掉死的现象，但没有确凿的证据。尝试用另外一种方法进行故障的定位。从BSC的ETC传输接口处，即ETRBLT板子2M接口处将马厂湖基站的传输DIP=97同另外一个类似配置的基站装载机厂的传输DIP=98直接进行互换，也就是说互相用对方基站的数据来开通基站。互换后发现，马厂湖基站的数据在装载机厂基站上仍然存在同样的问题，而装载机厂基站的数据在马厂湖基站上却能正常工作。这就可以说明，马厂湖基站的硬件、传输均不存在问题，基站数据确实存在掉死的现象。在确认马厂湖基站的数据存在掉死的情况后，重新定义了新的TG数据，来替换原先存在掉死现象的TG数据，整个基站恢复正常运行。对上述基站数据掉死的解决办法还有一种是进行BSC的重新启动，因为需要在晚上进行，因此可能会导致基站退服的时间较长。案例4：中国银行基站第2小区对应的机架为2个CDUC，4个载频配置，总是在4个载频全部开起来后，又很快全部退服，现象为第1、2个TRU状态为TXnotenabled，第3、4个TRU为Fault灯和Operational灯同时亮。每次对DXU进行复位，总是出现上述的同样现象，整个小区无法正常运行。因为第3、4个TRU总是出现故障现象，将这两个TRU更换，仍然出现同样的故障现象；更换第3、4个TRU对应的第2个CDUC，仍然出现同样的故障现象。将第3、4个TRU放到第5、6个TRU的位置上，将第2个CDU放到第3个CDU的位置，这样载频的位置为第1、2、5、6，甩开TRU第3、4位置不使用，整个小区正常运行，不再出现上述故障现象。根据以上处理过程进行分析，应该是第2个CDUC对应的CDUBUS总线或第3、4个TRU对应的背板存在问题，导致第2个CDUC不能正常工作，不仅导致第3、4个TRU不能正常工作，而且导致整个小区不能正常工作。将第2个CDUC对应的CDUBUS总线拆下来，更换一新的CDUBUS总线后，故障解决，确认是第2个CDUC对应的CDUBUS总线存在问题。下图是CDUBUS的连接示意图：还有一种解决办法，就是将CDUC更换为CDUC+，并且使用Ycable，按照如下图连接：这样就可以不再使用第2个CDUC对应的有问题的CDUBUS总线，就不会出现整个小区开不起来的现象。案例5：沂水城东基站A小区扩容一个机架，由6载频扩容为8载频。在打开跳频的情况下，A小区所有8个载频的时隙全部正常工作后很快陆续全部退服，同时出现1A级的XBusFault告警，但告警很快又消失。对基站A小区复位或闭解CF，仍然是同样的故障现象。将A小区的跳频关掉后可以正常运行。针对出现的XBusFault告警，重点检查了新增扩的机架TRU和DXU背板跳点设置，CDUBUS的连接情况，均未发现