NOKIA基站故障处理参考手册(4)

决。如果只有一个小区的某个载频出现干扰，则可能是内部干扰，其产生原因有可能是载频故障，也可能是频点干扰。在使用基带跳频或者无跳频小区，将干扰载频的频点与无干扰载频的频点互换，如果干扰仍出现在同一载频上，则可判断是载频故障，需要更换载频。如果出现在同一频点上，则需要通过调整频点来解决。如果使用射频跳频的小区出现某个载频干扰，则可判断是载频故障，需要更换载频。

4、7745 CHANNEL FAILURE RATE ABOVE DEFINEN THRESHOLD。

告警说明：在一个信道中，呼叫因失败而终止的比例超过了门限值。该告警用来监控话务和信令信道的功能，并检测可能出故障的信道。

处理思路：先查看是否有其他告警，如7744干扰，或者其他硬件故障告警，如果有，则先处理这些告警，如果这些告警处理后，7745告警仍然存在，则可判断为载频出现故障。可先将出现告警的载频重启，如果重启后告警仍然存在，则更换该载频。

7745告警的附加信息：

01 00 00 00 01 00 00 00 00 03 02 34d

第一个01表示：如果是01表示在TCH上失败率高于设定值，02表示在SDCCH上失败率高于设定值； 第二个00到第九个00表示：从0时隙到7时隙，如果有触发到01表示有告警；

第十位表示：在哪个具体的时隙，如果有多个时隙有告警，就表示失败率最高的一个时隙；

产生的告警的原因是多方面的，但主要原因有以下几点： 1．基站板件(载频等)硬件问题（主要原因）；

2．天馈线衰耗(驻波比偏高,或天线问题等)的原因（室内覆盖站比较明显）； 3．基站有外在干扰源影响（比如开会时的人为因数）；

4．切换数据不连续（由于停电基站中断会造成切换数据不连续），这个是暂时的

如果出现了7745告警，则需到现场进行拨打测试和对设备硬件进行检查，方可确定原因，以下是我们对7745处理方法：

Ａ： 从ＢＳＣ的告警分析出在第几载频第几时隙。 Ｂ：到现场检查：

检查基站设备所有的连线是否正确，是否牢固。

对所有的载频所有时隙进行环路测试，确保每个时隙都正常。

针对有告警的载频进行全面的检查和各个时隙多次的拨打测试，并对有问题的做好记录。 观察该站的相邻小区的情况，包括小区间的切换，干扰情况。 Ｃ：检查后和各相关的部门协调配合共同处理。

Nokia 告警补充信息字段

告警补充信息字段：

1－6 XX XX XX XX XX XX 1 2 3 4 5 6 各字段内容：

1、机架（机柜）编号 2、支撑架编号 3、插槽 4、单元类型 5、单元编号 6、子单元编号 单元类型数字与单元名称对照说明：

DE34 单元编号 对应板件 38 39 3C 3E 45 45 4C BCFA CCFA PSUA RMUA TRUA TRXA RTCC UltraSite 单元编号 96 97 98 9A 9B 9C 9D 对应板件 BOIA BB2x TSGx RTGA DVGA PWSB VXTA MetroSite 单元编号 对应板件 7B 7C 7D VIFA FAN TRE 4E

CSUA 9E BLOx 第五章 案例分析：

故障案例分析一：

驻马店市区刘阁基站（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之后再上传。

故障案例分析八：