济南基站告警处总结.docVIP

济南基站告警处理总结 实施目的： 由于基站设备现在存在较多告警，且最近新上的6000设备也较多，维护人员对这套设备还不太熟悉；同时也为了维护人员能够更加熟悉相关设备、相关告警的处理流程，我们组织了督导参与一起处理基站的告警。 这次告警的处理，维护人员全程参与，并在处理告警的过程中，就疑难告警进行了深入的沟通交流，为日后工作中准确、规范的排除故障做好了准备。 主要告警： 这几天处理的最多的告警是CF 2A:57,为接收通路不平衡告警，而其中绝大多数为假告警，这样的假告警对基站业务实际上是没有影响的。对于真告警，一般都是伴随着CF 2A:8、CF 2A:33这样的告警出现，我们处理完CF 2A:8、CF 2A:33，CF 2A:57自然就跟着消除。对于如何分辨该告警的真假，我们一般采用测相关TRX的SSI值来区分，对于假告警，我们直接修改天线在OMT中的参数，便可以消除告警。 其次CF 2A:33也出现得较多，为分集接收告警，这样的告警比较影响通话质量。硬件故障可以引起这个告警，像2202 CDU D，如基站西营，2202的TRU,如基站张安小区；2206的CXU，如基站环山路；2206的DTRU，如育贤中学；另外还有一个人为粗心原因造成的，如基站国防教育基地，基站IDB数据配置错误（天线不共享却配置为共享）；阳光假日酒店－南全福商务将两个小区的光纤接得交叉；基站新瑞达，相关人员将2202 CDU D的辅柜掉电，造成与辅柜相连天线丢失一路RX信号。 其它的告警都不是很多，如CF 2A:7,大多为CDU硬件故障，在站上可看到故障CDU是亮红灯的，可直接更换，如基站工程处、市中西河 具体实施： 参与人员：爱立信督导2人 维护工作相关人员 实施周期20120331 为了便于学习，现将主要的告警CF 2A:33、CF 2A:57的处理流程及方法整理如下： CF 2A:57告警处理 济南目前出现的这个告警大多为假告警 如果是真告警，也多是伴随着CF 2A:33、CF 2A:8、CF 2A:9之类的告警同时出现，一般处理完这些告警，CF 2A:57的告警就会随之消除 这里只说明如何处理假的CF 2A:57告警 一般情况下，假的CF 2A:57在用OMT读取告警时，只有这样一条告警，如图 为了确定为假告警，可对上图告警中的RX-2、RX-3对应的TRX2、TRX3进行SSI值的测试，如果SSI值都正常，则为假告警 处理过程 打开OMT，选择Radio－在对应小区上点右键－ Define－Antenna Supervision，如图 选择Antenna Supervision后，出现下图 这些参数的意思为：在0分钟的统计周期内，如果有（达到或超过）000个不平衡度为（或者超过)db的通话采样，2A：57告警 因为是假告警，可以调整参数来消除它 将6db－12db 1440分钟－100分钟 7000次－18000次 点OK后，将基站复位重起后，告警消失 CF 2A:33告警处理 出现CF 2A:33的告警一般有三种情况：IDB错误、连线问题、硬件问题，而我们在处理这个告警时，也是按照这个顺序进行检查 IDB错误 1、2206设备 如果我们要做一个配置为S12的站，需要三个CDUF，该小区的两个跳线分别接到第1个跟第3个CDUF收发共用的接口；但如果不小心在配置小区时，选成了两个小区，实际上做成了2*S6的配置，而这种配置在接天线时，需要在第1个CDUF上接1个小区的两根跳线，在第3个CDUF上接两另一个小区的两根跳线，如下图 S12 2*S6 当配置为2*S6时，要求第1个跟第3个CDUF的RX接口也是要接跳线，以使得每个小区的都能有两路RX信号，但实际上跳线的连接是按S12来接的，每个小区都只有一路RX信号，所以产生分集接收告警 2、6000设备 6000与2000设备在IDB上最大的差异便是天线共享，很多6000的CF 2A:33的告警都是因为IDB错误引起的。 当一个小区的载频分别在两个DUG下时，需要做天线共享；反之，一个小区的载频全都在一个DUG下时，不需要做。 目前做得最多的是3*S8，需要在两个DUG上都做3*S4的配置，且皆为天线共享，在做IDB时，需要注意的地方如下图 每个小区做天线共享时，一个DUG下的RUS并不只是一个小区的全部，它的RX信号还需要其它DUG上的RUS共享过来；如果上图中不小心选成了天线不共享，则一个RUS上需接两根跳线到一副天线上，实际上只有一根，而少了一路RX信号，所以有分集接收告警。 连