NOKIA通信基站7745告警浅析

合集下载

7745告警含义

7745告警含义：在一个信道中，呼叫失败而释放信道的比率大于定义的门限值而产生的告警。

可用于监测话务信道和信令信道的功能，助于检测故障信道的TRX.
网络一些使用默认参数的值会影响该告警：
7745告警也是现网中，载频常会出现的一类告警。

引起TRX信道失败的原因有两种，一是由硬件问题引起，二是该载频受到了上行干扰导致。

✓硬件问题：
如果长期某一个或几个特定的信道，每天出现了7745告警。

✓干扰原因：
如果载频出现的7745告警是由于干扰造成，那么该告警出
现的频率和网络无线环境有关。

现网中GSM网络受干扰大
一些，系统7745告警载频数量就多一些。

针对省公司开展的网络质量提升活动中的设备告警处理，我们总结了对7745告警的处理经验，并在现网中中进行了试点式的实验应用，取得了不错的效果，处理结果如下：
上表所示的7745告警类型为在TCH信道上的，告警的补充字符第一位显示的为01TCH信道，此类告警通常采用的处理方法为：1若查看站点是否有干扰情况存在（看是整个基站还是一块载频，若是一个基站就是硬件故障，要是一块载频的话就换频点），优先对干扰进行处理；(如何进行干扰处理)
2干扰消除后，观察告警是否还存在，若存在，再进行重启处理；
3若重启后依然频繁出现告警的载频进行更换处理。

用此类方法大多数的告警都会消除。

(如何找到重启的载频号，更改频点如何确定，倒主频，倒SD时隙？)
补充信息含义如下：
1 表示问题信道类型：取值分为：01 TCH 、0
2 SDCCH
2~9 表示信道所在时隙
其取值分为：00 低于门限（不产生告警）、01 高于门限（产生告警）。

案例：7745信道占用失败率超过门限(昆明晋宁分公司CASE)(诺基亚 GSM)

案例：7745信道占用失败率超过门限（昆明晋宁分公司CASE）
一、故障CASE
本周昆明市晋宁县分公司上报基站故障CASE，站号：4778，站名：洗澡堂，故障现象：基站多块载频出现严重7745告警，已排查天馈系统，更换过载频和合路器，告警仍未消除。

二、故障分析
1、基站侧，检查硬件数据是否配置正确，主要检查RX和TX连线是否正确。

硬件数据配置正确
告警载频
2、基站为FLEXI EDGE站型，使用ECDA（空腔合路器），分析告警，发现出现告警的载频都为偶数载频，检查后台数据RX DIV功能设置（基站使用空腔合路器，若未开启分集接收功能，会导致偶数载频接收信号异常，出现严重7745告警）。

分集接收功能未开启
三、处理方法
1、闭锁故障小区，修改命令ZEQS:BTS=BTS号:L:FHO,20:;
2、开启分集接收功能，修改命令ZEQM:BTS=387:RDIV=Y:;
开启分集接收功能
3、解锁闭锁小区，修改命令ZEQS:BTS=BTS号:U:;。

7745告警的触发机制及其跟踪v3

• 右图显示相同时段同一BTS下其它TRX的上下行质量是正常的，而上页的图象也显示出现7745告警的TRX的上下行质量是不正常的
– 针对SDCCH信道上连续出现的失败率为 100%的7745告警
• 如果跟踪ClearCode发现其原因集中在 (estab_ind_fail_c)上，且集中发生在个别 TRX上，则可以通过其上下行质量来予以确认，或者结合7744告警判断该TRX上是否有干扰。最有效的办法还是派基站工程师上站进行拨打测试并查找具体的原因
7745告警的触发机制及其跟踪
7745告警的定义及分类
ZZBSC123 BCF-0417 BTS-0419 QUAL 2012-09-29 19:36:36.85 ** ALARM TRX -020 8ZZLONGHAITL3 (57677) 7745 CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD 01 00 00 00 01 00 00 00 00 03 01 20d 定义：7745 CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD 在监控时段，BTS的SDCCH 、TCH 信道上的失败率高于系统设置门限值。分类：根据告警补充信息，第一个信息表示问题信道类型，取值分为：01 TCH 、02 SDCCH 最后一个信息（20d），表示在监控时段内，补充信息10&11指示的信道异常释放情况占总释放次数的比率。
灰色覆盖的信息及参数只与 7743告警相关
PARAMETERS FOR CHANNEL SUPERVISIONS PERIOD MIN MAX F% CALLS SUP:TCH 00F0 0004 0078 14 000A SUP:SCH 003C 001E 50 SUP:FAIL 003C 000A SUP:FAIL ACTIVE FROM 07:00 TO 22:00

基站典型告警分析报告7745

基站典型告警分析报告7745告警告警编号：7745告警内容：CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD在一个信道中，呼叫因失败终止的比率超出了设置的门限值。

该告警用来话务和信令信道功能，并检查出可能出故障的信道。

产生此告警的可能原因有：告警描述：01代表TCH信道失败率高的信道信道占用失败率触发原因：1、载频故障；2、载频信道故障；3、天馈或合路故障；4、传输质量差（误码高）导致；5、网外干扰导致；6、网内同邻频干扰导致；7、跳频板件故障引起；8、高温导致载频性能不稳定引起；影响KPI：小区掉话率，切换成功率，无线接入成功率，上下行通话质量恶化。

用户感知：用户通话过程中，通话突然中断或用户在通话移动过程中非用户原因中断，通话过程中用户感知通话质量不理想等。

派单情况：基站告警监控部门一旦发现7745告警，如信道占用失败率较低，5%以下，且无其它投诉类，可暂观察不处理；如信道占用失败率高（5%以上），且掉话次数较多，可重启载频或载频所在BTS，如重启后1小时左右该7745告警自动消除，则该告警解决；如重启后该告警7745仍然存在，需及时派发工单给网优进行分析处理。

一般处理7745告警分两大类：即一：TCH信道占用失败引起的7745告警；二：SDCCH信道占用失败引起的7745告警。

处理流程大致如下：TCH信道占用失败引起7745告警处理流程：1、查看载频告警是否全部信道，如果是则很可能载频故障，（载频性能严重下降），且排除干扰原因，则此类需要更换载频。

2、如载频告警是单个信道，且重启后该信道一直存在告警，则该载频单个信道故障，此类建议闭锁该信道。

3、合路或天馈类导致的7745告警，一般伴随7601、7604、7607告警，此类故障需派单排查合路或天馈故障。

4、如是传输质量差（误码高）需派单传输部门处理。

查看指令：ZYMO。

5、如是网外干扰引起的7745告警，一般伴随7744、7743告警，且载频时隙多信道告警，则需要派单排查网外干扰。

GSM网（诺西）主要告警分析（1）

GSM网（诺西）主要告警分析（1）1.概述告警信息可以反映网络设备的运行状况，记录了网络运行过程中产生过的故障或影响设备运行的信息，通过对网内告警数据的分析，可以了解网络的运行状况。

我们将对一些影响网络运行指标的重要告警进行分析，并分析影响此类告警的主要原因及相关的解决方案。

2.主要历史告警数据分析2.1告警分类情况为了对现网的告警进行分析我们对告警进行了分类汇总，南昌移动全网的BTS告警信息分为基站告警（7000~7999）和传输故障告警（8000~8999），这两种告警直接反映了网络的运行状况，对网络指标和客户感知度的影响都非常大。

具体告警数量统计情况如下：AlarmNo class MEANING 原因及处理方式TOTAL NUM7600 *** BCF FAULTY 合路器反射功率高告警，可通过测试驻波，更换合路器解决 1 7603 *** BTS FAULTY 射频线松动，可以上站重新连线解决 2 7767 *** BCCH MISSING 重启小区产生的告警，小区处于工作状态后，告警消除5 8050 *** LOSS OF INCOMING 2M SIGNAL 2M丢失告警，上站处理，可解决 28081 *** LOSS OF FRAME ALIGNMENT帧定位丢失，上站检查2M，时钟同步、传输单元、传输侧接收与发射，可解决 18086 *** LOSS OF CRC MULTIFRAME ALIGNMENTCRC复帧定位丢失，上站检查传输侧接收与发射、时钟同步，可解决08099 *** RECEIVED BIT ERROR RATIO (BER) > 1E-3接收比特误码率> 1E-3，上站检查传输侧接收与发射、时钟同步，可解决08150 *** FAULT IN UNIT 更换传输板可解决 17601 ** BCF OPERATION DEGRADED 上下行差异过大告警，可解决747604 ** BTS OPERATION DEGRADED 上下行差异过大告警，可解决127 7606 ** TRX FAULTY 硬件退服告警，可解决40 7607 ** TRX OPERATION DEGRADED 上下行差异过大告警，可解决161 7704 ** PCM FAILURE 传输告警，需沟通后解决90 7706 ** BTS O&M LINK FAILURE BTS操作维护链路故障，可解决3 7725 ** TRAFFIC CHANNEL ACTIVATION FAILURE 信道激活失败，需数据侧配合解决93 7730 ** CONFIGURATION OF BCF FAILED BCF配置失败，上站处理后可解决3 7734 ** BCCH IS NOT AT PREFERRED BCCH TRX BCCH不在优先载频上，上站处理后可解决7 7735 ** TRX TEST FAILED 载频测试失败告警，需上站处理后可解决87737 **INCONSISTENT DATA INRADIORESOURCEMANAGEMENTSTATE FILES无线资源管理状态文件中有冲突数据，需上站处理后可解决27738 ** BTS WITH NO TRANSACTIONS 小区无话务产生的告警，需相关部门协助，可部门解决1377741 ** MEAN HOLDING TIME ABOVE DEFINED THRESHOLD 信道未使用但同时未被释放，重启载频或更换问题载频可解决87743 ** MEAN HOLDING TIME BELOW DEFINED THRESHOLD 话务信道平均占用时长低于门限，可能频点、干扰、TRX、RTC、馈线问题，可解决337744 ** EXCESSIVE TCH INTERFERENCE 过大的信道干扰，可部分解决84 7745 ** CHANNEL FAILURE RATE ABOVE DEFINED TCH 和SDCCH信道掉话率高于门限，可能频点、干扰、TRX、54 THRESHOLD RTC、馈线问题，可解决7746 **CH CONGESTION IN CELL ABOVE DEFINEDTHRESHOLD信道拥塞导致的告警，可解决78066 ** ALARM INDICATION SIGNAL (AIS) RECEIVED传输告警，一般是传输设备或线路故障或设备的环路激活（即传输线路环着）需配合解决138102 ** RECEIVED BIT ERROR RATIO (BER) > 1E-6 接收比特误码率> 1E-6，需配合解决 18179 ** FAR-END ALARM2M丢失或AIS 2M或帧定位丢失或BER> 1E-3，需配合解决 58020 ** BLOCKED FROM USE串传输时，存在冗余数据未删除，删除传输侧冗余数据，告警消除，可解决 38126 ** UNIT FUNCTION DEGRADED 传输单元故障，更换板件，可解决 2 7740 * BEATING BTS ALARM 告警重复出现次数导致门限值后产生的告警，可部分解决48 。

NOKIA 基站告警

10
© Nokia Siemens Networks
TBBP530数据配置
处理7607案例案例-2 处理案例
•
第二行RTC2的连线数据库错误，导致RTC2的信号无法传到RTC1，造成RTC1相连的6个载频都缺少一路输入，从而造成6个载频7607告警
11
© Nokia Siemens Networks
12
© Nokia Siemens Networks
TBBP530数据配置
处理7745告警的办法及建议告警的办法及建议-2 处理告警的办法及建议
Hale Waihona Puke • 天线的驻波比正常，但是天线的方位角或下倾角差异过大，例如一幅天线方位角朝东，一
幅朝西，两者接收同一用户信号时必然存在很大差异，导致7607
• 机柜内的Rx连线有误、连接不可靠、接头松动弹起或者连线损坏等会造成7607，原因是
天线的接收信号最终通过这些Rx线进入RTC或DDU，接收通路上的任何问题都会导致 7607
•
7
© Nokia Siemens Networks
TBBP530数据配置
处理7607 （RSSI detected Rx signal difference exceeding threshold）告警的主处理）要方法-2 要方法
主要思路：主要思路：通过观察RSSI测量值，分析RSSI值的特点，可以逐步缩小范围，确定故障点 7607告警的主要原因告警的主要原因 • 天馈线性能可以直接导致该告警，例如两幅天线中的一幅驻波比高，接收性能差，这将导致这幅天线接收的信号电平弱，另一幅天线接收电平正常，两者差值超过10dB
TBBP530数据配置
处理7745（CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD）（处理）告警的办法及建议-1 告警的办法及建议

7745基站告警处理(参考版)

故障原因：由于合路器模块故障而导致的衰减不平衡处理建议：更换故障模块
典型案例：【站点信息】东城区尚庄东 2070 【告警信息】S1:TRX 5 S3:TRX8 9 10 11 12 【现场信息】一小区通常是间隔一段时间，单载频出现7745；三小区是该扇区的下半部分载频出现7745. 【处理过程】经检查发现3小区的第 2个WCGT连接的载频均出现掉话且温度极高，更换新的WCGT后该小区告警消除。【解决措施】更换故障的WCGT。
合路器上的连线在未连紧或连线老化的情况下，合路器也会出现高温。
7745故障案例----双工滤波器故障
故障原因：由于双工滤波单元故障而导致的掉话。处理建议：更换故障模块
典型案例：【站点信息】西城区西开经贸学校 5874 【告警信息】S1:TRX 3 5 6 7 8 9 10 【现场信息】基站存在外部干扰，二三小区掉话是伴随干扰出现的【处理过程】一小区通过检查发现本小区的DVGA射频线连接口已经断裂（详见截图），致使本小区大部分载频出现了7745。将一小区损坏的DVGA更换。【解决措施】二三小区确认外部干扰。。
7745故障案例----配置不匹配
故障原因：硬件数据库配置和实际硬件配置不符而导致的掉话处理建议：修改数据配置或更换相符硬件。
典型案例：【站点信息】二七区纬四路服装市场 9757 【告警信息】TRX1 2 4 【现场信息】本站为Metro基站，TRX1 2 4为同类型载频， TRX3与其他载频不同。【处理过程】通过观察发现本站使用了两种不同功率的载频，分别为5W和10W混用。由此导致了掉话，将TRX3更换为10W载频后基站正常，告警消除。【解决措施】Metro基站的载频功率需相同，更换载频为相同功率即可。

NOKIA基站常见告警及处理思路

NOKIA基站基站常见告警及处理思路第一节DE34告警1、7509 RADIO TIMESLOT FAILURE IN TRX——TRX的无线时隙失败。

告警说明：TRX的一些CHDSP中检测到错误情况。

所有的CHDSP时隙告警都用此告警表示。

处理思路：更换TRX。

2、7510 ABIS TESTLOOP FAILURE IN TRX。

——TRX－TRU环路测试中检测到故障。

告警说明：如果同时出现7516和7517告警，则可判断为TRX故障。

如果没有这两个告警，则可判断为TRU故障。

处理思路：检查载频是否同时发生7516和7517告警，如果有，更换TRX单元，如果没有，更换TRUA单元。

3、7514 13MHz CLOCK IS MISSING IN TRX——TRX内部13M时钟丢失。

告警说明：TRX检测到13M时钟发生故障。

该告警多出现在DE34基站重新启动过程中，多数为误告警。

处理思路：Reset出现该告警的TRX，必要时重新拔插一下，如果告警仍然出现，则更换该TRX。

4、7523 TRX TEMPERATURE DANGEROUSLY HIGH。

——TRX温度太高。

告警说明：TRX单元中的温度高于80 oC，必需关闭TX电源以防止组件损坏。

处理思路：当温度降低后，TRX能够正常运行，检查基站风扇单元和基站空调，如果TRX温度正常而告警仍然存在，则更换TRX。

5、7524 TX FREQUENCY TUNER OUT OF ORDER。

——TX频率不稳定告警说明：某个TX锁相合成器出现故障，如果不是跳频模式或者基带跳频模式，则TRX仍能工作，如果另一个合成器也未锁定，则TRX一定被闭锁。

在合成器调频模式下，基站时钟被扰乱或者TRX已坏，该告警是致命告警。

处理思路：检查相应的时钟和时钟线，如果都正常，则更换TRX。

6、7533 TX ANTENNA OR COMBINER CONNECTION FAULTY。

7745处理方法

7745告警的处理方法1.7745告警的含义：7745 CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD告警描述：CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD 告警编号：7745原始级别：**建议级别：重要告警(MAJOR)变更原因：不变更设备类型：BTS告警解释：在一个信道中，呼叫因失败终止的比率超出了设置的门限值。

该告警用来话务和信令信道功能，并检查出可能出故障的信道。

产生此告警的可能原因有：1、TRX故障2、载频频点收到干扰？业务影响：出现该告警，提示信道可能出现问题参数说明：参数1 告警是TCH还是SDCCH01: TCH02: SDCCH参数2 信道的故障率是否高于时隙0定义的门限值00: 低于门限值(无告警)01: 高于门限值(告警)参数3 信道的故障率是否高于时隙1定义的门限值00: 低于门限值(无告警)01: 高于门限值(告警)参数4 信道的故障率是否高于时隙2定义的门限值00: 低于门限值(无告警)01: 高于门限值(告警)参数5 信道的故障率是否高于时隙3定义的门限值00: 低于门限值(无告警)01: 高于门限值(告警)参数6 信道的故障率是否高于时隙4定义的门限值00: 低于门限值(无告警)01: 高于门限值(告警)参数7 信道的故障率是否高于时隙5定义的门限值00: 低于门限值(无告警)01: 高于门限值(告警)参数8 信道的故障率是否高于时隙6定义的门限值00: 低于门限值(无告警)01: 高于门限值(告警)参数9 i信道的故障率是否高于时隙7定义的门限值00: 低于门限值(无告警)01: 高于门限值(告警)参数10 故障率最高的时隙参数11 子信道标识 TCH:00: TCH/H –子信道 001: TCH/H –子信道 102: TCH/F -子信道子信道标识SDCCH:00 - 07: SDCCH -子信道0 - 7参数12 指定信道中，测量期间应故障造成的TCH或SDCCH子信道释放占全部信道释放的的比例。

BTS常用告警代码

常用告警含义7743告警，主要是由于GPRS告警引起，不会对掉话率有什么影响，可能会影响彩信、GPRS激活成功率、GPRS掉话率等，处理方式同7745告警。

7745告警：头位数表示：01表示TCH 02表示SDCCH当02时，表示SDCCH掉话率高，查看SDCCH掉话原因，大部分可能为BSC数据错或MSC数据定义有误造成。

当01时，表示TCH掉话率高，最后一位表示载频由于信道失败的掉话占整个载频掉话总数的百分比，如该值超过30％，可考虑重启载频、扇区、BCF。

如重启后仍然存在过多的7745告警，并且小区总体掉话率依然偏高（无直放站情况下大于8％的掉话率）建议更换载频版或BB2板，一般能解决。

1、对于2993的TC掉话告警，我们采取的办法是：如果是单个时隙告警，就关闭该个时隙，让它不再产生TC掉话，因为TC掉话的次数是相当高的，出现2990告警，一个小时的TC掉话就可以到达几百次！所以，我们必须及时采取措施来应对该项告警，如果一个载频由于2993告警关闭了2个或2个以上的时隙，我们就会将其换掉。

还有的情况是由于基站的配置和BSC上的数据不一致，也会导致2993告警的产生，如果是这种情况，就需BSC工程师与现场BTS工程师沟通，双方达成一致的数据配置，都做成一致的数据库，则告警就可解除。

2、对于2915告警，主要是由于基站突发中断或工程新开基站激活ET的时候出现得比较多，我们对于在现网服务的基站采取实时监控的办法，一发生是在用ET的告警，我们马上进行处理，先诊断ET，如果ET无问题，我们再采取自环的方式，判断是那段传输发生了问题，立即解决。

3、对于7767告警，我们主要也是采取实时监控的方式，一发生基站中断的事故，我们马上通知相关部门进行处理。

4、对于8050告警，我们首先察看基站的传输板是否有问题，如果基站无问题，我们将与基站维护人员联系，查清楚是哪个端口有接入，如果无接入产生了该告警，则屏蔽掉该端口，如有接入，则需基站维护人员现场查证后再确认具体故障所在。

alarm

当基站侧存在7745的告警时，1.BTS基站工程师首先让BSC侧人员查阅一下是否此载频的掉话率高（了解一下实际情况)2.如果高的话，或客户必须要消除此告警，上站后，先做环路测试，观察是否有问题，如果没有的话，调换TRX位置后再观查。

3.如果还无法消除，只能更换TRX板件了，但原替下来的板件可以放在其它基站继续使用（应该没有问题)附详细信息;7745 信道故障率高于设定门限值含义在测试周期内，一个信道呼叫终止失败率高于运维设定值。

此告警被用于监测话务及信令信道的性能，和发现有可能的故障信道。

根据告警描述, 可以看出这两个告警都是通过BSC 上的统计产生的, 可能有许多方面原因引发, 不是明确的硬件故障告警。

针对7743 和7745 告警的出现，其引发原因较多：1，基站本身硬件故障；2，传输上某个时隙误码率较高；3，BSC 上ET 接口故障引发；4，BSC 相关参数的设定；5，网优无线规划参数设置；告警处理针对基站验收中出现的此类告警，建议采用以下方式处理：首先，请网优人员协助查询问题基站的掉话统计。

如掉话统计在允许的规定范围内，就基站硬件检测本身，我们提出如下处理建议：1，检查告警载频状态，更换载频位置。

将故障载频与正常载频调换位置，观察结果。

如告警与载频同时变更，则基本判断为载频故障，更换新载频。

2，检查设备连线及接头是否安装正确。

即检查机柜内载频与WC 单元，WC 单元与DV 单元，DV 单元与机柜内天线接口连接是否牢靠3，检查天馈线连接是否正确，接头牢靠。

即机柜顶天线接口是否连接正确牢靠。

4，使用天馈线测试仪器，测试天馈线性能指标，提供相应的测试报告。

5，提供相应载频的环路测试报告。

6，如基站硬件检测正常, 掉话率, 上下行质量正常, 且不存在某个TRX 频繁出现相同告警的现象时, 建议综合考虑各种因素的影响, 诸如覆盖情况, 话务量, 优化情况等7，网络优化人员参与协调分析处理, 并提出建议如以上几个方面的检查皆无问题，可排除基站故障，将天馈线性能测试报告和环路测试报告提供维护部门，予以验收。

7745告警处理思路

7745告警处理思路：你首先要明白7745告警的含义，7745告警在BSC参数上可以定义，目前SD定义为80%，TCH定义为20％，也就是说，SD信道时隙占用失败率为80％以上会触发告警，TCH的时隙占用失败率为20％以上会触发告警，对于半速率和全速率，还可根据附加码确定到某一个半速率时隙。

如果一个载频的掉话虽然较高，但时隙均匀的掉话，是不会产生高掉话的。

单时隙的掉话也只能说明这个载频的这个时隙的掉话率偏高，7745告警也只能给你定位问题的参考思路，更多情况下不是由于载频故障，而是由于其它原因导致的掉话。

如果每个载频掉话均匀，你要考虑是整个扇区的问题，楼上说的先关BB观察是比较常用的方法。

给你个解决思路，先把本小区的跳频关了，然后再利用统计p_nbsc_underlay表中的相关counter，主要统计052003－052007这几个counter，看是哪个载频在掉话。

另外，这个表中还有关于各个载频在空闲时隙的干扰情况的counter，也可以结合统计出来分析。

还有，P_NBSC_RX_STATISTICS 表中有各个载频0－7级的上、下行质量，可以对各个载频的质量进行统计分析，一般来说，这些counter 结合起来基本就能分析出问题原因来了，另外还有7745告警等，可以结合起来看具体是哪个时隙。

一般情况下，对于深入排查故障来说，跳频关掉比较好处理，在开跳频的情况下，分析起来比较困难7745 CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD信道失败率高于定义极限告警含意一个信道的通话连接故障率高于运行者定义的极限值。

告警用于通信和信令信道的监控功能和发现可能的故障信道。

附加信息栏1 指示告警出自TCH还是SDCCH信道01：业务信道02：独立专业控制信道2 指示在0时隙信道故障率是否高于定义值00：低于极限（无告警）01：高于极限（由告警）3 指示在1时隙信道故障率是否高于定义值00：低于极限（无告警）01：高于极限（由告警）4 指示在2时隙信道故障率是否高于定义值00：低于极限（无告警）01：高于极限（由告警）5 指示在3时隙信道故障率是否高于定义值00：低于极限（无告警）01：高于极限（由告警）6 指示在4时隙信道故障率是否高于定义值00：低于极限（无告警）01：高于极限（由告警）7 指示在5时隙信道故障率是否高于定义值00：低于极限（无告警）01：高于极限（由告警）8 指示在6时隙信道故障率是否高于定义值00：低于极限（无告警）01：高于极限（由告警）9 指示在7时隙信道故障率是否高于定义值00：低于极限（无告警）01：高于极限（由告警）10 高失败率的时隙11 子信道定义TCH：00：TCH/H-子信道001：TCH/H-子信道102：TCH/F-子信道子信道定义SDCCH：00-07：SDCCH-子信道0-712 在测量时间内，TCH或SDCCH子信道因为故障而释放的数目在所有信道释放的数目的比例。

7745告警处理方案

7745告警处理方案一、7745告警内容：CHANNEL FAILURE RATE ABOVE DEFINEDTHRESHOLD，含义为：信道失败率超过门限值。

可用于监测话务信道和信令信道的功能，有助于检测故障信道的TRX。

二、7745告警原因多由于干扰、基站故障、弱覆盖以或者天馈系统性能下降、天线覆盖方位有问题以及射频连线故障或者松动等引起，建议网优排查干扰、解决弱覆盖，基站维护人员处理基站故障，整改天线等问题等方面着手进行处理。

这就要求处理故障的维护人员最好备齐天馈测试仪、测试手机、以及必要的备件。

具体需要采取的措施如下：1.远程登录或者现场查看是否有伴随告警，特别是一些能影响小区性能的告警：7601、7604、7606、7744、8102等等，如果有首先处理这些告警，有可能7745告警随着其他告警的消失而消失。

特别是7744和8102可能需要其他部门如网优或者传输人员配合处理。

2.远程登录或者现场查看小区是否开启Rdiv参数。

3.远程登录查看一下RSSI值，或者到现场查看也可以，从中初步判断射频连线和天馈是否性能不好。

4.远程登录或者现场对载频进行一下环路测试，已初步检查载频硬件和连线是否有问题。

5.如果可能的话，检查天馈的覆盖是否正常，这可以利用测试手机来实现，初步判断小区覆盖方向是否正确；同时如果可能的话从天线附件查看是否覆盖方面正常，方位角、下倾角是否正常，是否有障碍物遮挡天线。

6.检查设备与传输、天馈的连接是否正确，防止传输接反导致的小区覆盖不正确。

7.检查是否存在直放站、载波池、塔放、光纤拉远（射频拉远）设备，并且是否正确设臵。

8.现场拨打测试检查是否存在同、邻频干扰等等。

三、告警具体处理措施：1.网络一些使用默认参数的值会影响该告警：2.有些小区有多个载频甚至整个小区都有7745告警，同时伴随7744干扰告警，这时需要网优排查干扰源，随着7744告警解决，7745告警一般也能解决。

经典的基站7601#7604#7745告警案例及其处理

NOKIA Ultrasite GSM900
"C/y;S7{/
"d,N'X'l2m 案例简述
'e*K(C$f.B%} U!U.E移动通信,通信工程师的家园,通信人才,求职招聘,网络优化,通信工程,出差住宿,通信企业黑名单第二扇区有7601、7604告警，其中以7604出现最为频繁
遇到过的几个经典的基站7601#7604#7745告警案例及其处理
一.MSCBSC 移动通信论坛$v;j#O8X6e.\
故障设备
.M;K4W!w'I%~ |&c3b%T移动通信,通信工程师的家园,通信人才,求职招聘,网络优化,通信工程,出差住宿,通信企业黑名单NOKIA Connectsite
1、检查基站设备所有的连线是否正确，是否牢固；
;|"S;d%S!l:U:N+C2、对所有的载频所有时隙进行环路测试，确保每个时隙都正常；
(E7O8y4T&N2m+~mscbsc 移动通信论坛拥有30万通信专业人员，超过50万份GSM/3G等通信技术资料，是国内领先专注于通信技术和通信人生活的社区。针对有告警的载频进行全面的检查和各个时隙多次的拨打测试，并对有问题的做好记录；MSCBSC 移动通信论坛1A%k6N7Y%`#m4T
%I1P!j2L&v2{5K4d"h%d)z$z
3k4u:a!f1~9C | 国内领先的通信技术论坛故障分析mscbsc 移动通信论坛拥有30万通信专业人员，超过50万份GSM/3G等通信技术资料，是国内领先专注于通信技术和通信人生活的社区。8N4Z:j%{)c6~-|
7745告警内容：CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD（占用某个信道的失败率高于设定的门限值），这个告警是用来监视话务信道&信令信道的质量状况，检测可能出现故障的信道；与它相关的参数有四个：一是占用话务信道的失败率门限值是20 %；二是：占用信令信道的失败率门限值是80 %；三是：监视测量信道的时间长度为60分钟；四是：信道的门限值是10 。MSCBSC 移动通信论坛 m+^5s0y*}0a)h

NOKIA基站告警原因及处理方法

NOKIA基站告警原因及处理方法ID alarm_number severitymeans means_c可能的原因1可能的原因2处理方法1 4924272MMI SYSTEMFILE ERROR MMI系统文件错误人机接口系统检测到磁盘文件如内容出错.如一些人机接口文件出错.用户无法打开人机会话拷贝恢复相应的程序块.5024302ERROR INCOMMANDCALENDAR 指令作业计划错误OMU的硬盘太满,导致日历文件丢失.OMU切换过程中日历命令文件丢失.用ZIWX 查看系统盘和备用盘的空间,用ZIWD将不用的文件删除.5124452UNIT TYPE HAS NO REDUNDANCY 单元没有备份对于需要N+1替换型的功能单元,如SU单元,当所有单元均为WO-EX 时,无冗余单元存在.在创建信令系统的过程中,将控制该信令链路的信令单元设为SP的CSSU.用ZUSC将某一单元置为SP-EX状态. 5224942MSRN RESERVATION RATIO 漫游号预留比率当交换机的来话话务量很高,VLR分配的MSRN号码达到门限值80%/100%时,系统产生告警.扩大MSRN的号码范围(ZWVM)5325182NO VALID FALLBACKCOPY FORDEFAULTPACKAGE 默认软件包中无有效的FB备份系统认为默认包无有效的最新的安全备份包.用ZWKS做一系统安全备份.5425251FAILURE IN STORING OF DETAILED CHARGINGDATA 存入详细计费数据失败系统在将计费数据从CHU的内存写入硬盘时可能由于控制文件TTLOFI的问题导致计费数据丢失特别注意若需对CHU单元进行切换,切换之前千万不要对备用CHU进行重启,否则计费数据可能丢失!保证VDS的连接指向,保存计费数据,先进行主备切换后再对备用单元进行重启5525322ANALYSIS FORNETWORKGENERATEDNBR OR FORCHA. CASEIS MISSING NG号或CHARGINGCASE丢失在CM数字分析中却失NETWORKGENERATED的分析在CHARGINGORIGINANALYSIS中却失CHARGINGCASE的分析用ZRDC创建遗漏的NETWORKGENERATED5625482COCA EC1PFAILURE COCA卡故障COCA/ECIP插板检测到错误的定时信号,故导致该插板功能失效.检查M的CLB到COCA/ECIP的插板之间的电缆,或对相关的插板进行检查.5725492FIRSTALARMLIMIT FORUNAVAILABLE VDS-DEVICEDATA FILES REACHED 不可用VDS 数据文件数超过门限存储到VDS的数据突增从VDS传送到BC的数据链路失败或被限制修改VDS存储容量的告警门限.当VDS中积压太多的FULL状态的数据文件,可对积压数据文件进行磁带备份后将FULL状态的文件该为TRANSFERRED状态. 5825592DATA CALL ERRORRATIO EXCEEDED 数据呼叫失败率过高数据业务相关单元故障或半永久连接问题故障对相关数据单元进行诊断,分析处理. 5925902ERROR IN OPENING OUTPUTFILE 打开输出文件失败报告生成程序块RFGPRB无法打开将报告输出指向I/O系统.检查逻辑文件指向或查看LOGS,然后按照ERROR CODE 进行处理.6025962SCCP REGISTRATION ERROR SCCP登记错误SCCP或SCCP子系统无定义或状态不对.用NFI/NFJ/ZNHI查询; 有错.漏则用ZNFB.ZNFD定义后用ZNGC.ZNHC激活. 6126142ERROR IN REPORTFORMING 报告格式错误装载模块出错或从硬盘装载报告生成代码出错用ZIWX查询软件包的BLCODE中是否存在该装载模块.用ZAHO查看是否有相应的硬盘告6226202OMUCONNECTIONFAILURE 操作维护单元连接故障OMU单元的负荷过载ASS链路或GSW 或SSW的连接或插板故障.由辅助信息的第4字段的故障定位进行诊断判断.6326212FAULTYTIME SLOTIN TESTINGOF TIMESLOT BASEDUNIT 单元使用的时隙在两次连续的测试中不通过在测试中由于测试中断出现的告警提示用ZUSC将单元置为TE状态,然后开始测试.根据测试报告的提示进行处理。

7745告警理论与实战处理流程

7745告警理论与实战处理流程第一部分告警定义1. 7745告警含义：CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD（占用某个信道的失败率高于设定的门限值），这个告警是用来监视话务信道&信令信道的质量状况，检测可能出现故障的信道。

2. 影响该告警的网络一些使用默认参数的值ZEEN:TCHFR = TCH failure rate (20 % )SCHFR = SDCCH failure rate (80 % ) PRDCFR = length of supervision period (60 min)CS = channel seizure threshold value ( 10 ) SMBNT = supervision start time ( 08-00) EMBNT = supervision end time ( 18-00)一是：占用话务信道的失败率门限值是20 %；二是：占用信令信道的失败率门限值是80 %；三是：监视测量信道的时间长度为60分钟；四是：信道的门限值是10 。

3.如何看告警信息告警信息附加字段：01 00 00 00 00 00 00 01 00 06 02 90D附加字段解释1 indicates if the alarm is on the TCH or on the SDCCH channel01: TCH02: SDCCH2 indicates if the channel failure rate is above the definedthreshold in time slot 0 01表示TS0高于定义的信道失败率门限00: belove threshold (no alarm)01: above threshold (alarm)3 indicates if the channel failure rate is above the definedthreshold in time slot 1 01表示TS1高于定义的信道失败率门限00: belove threshold (no alarm)01: above threshold (alarm)4 indicates if the channel failure rate is above the definedthreshold in time slot 2 01表示TS2高于定义的信道失败率门限00: belove threshold (no alarm)01: above threshold (alarm)5 indicates if the channel failure rate is above the definedthreshold in time slot 3 01表示TS3高于定义的信道失败率门限00: belove threshold (no alarm)01: above threshold (alarm)6 indicates if the channel failure rate is above the definedthreshold in time slot 4 01表示TS4高于定义的信道失败率门限00: belove threshold (no alarm)01: above threshold (alarm)7 indicates if the channel failure rate is above the definedthreshold in time slot 5 01表示TS5高于定义的信道失败率门限00: belove threshold (no alarm)01: above threshold (alarm)8 indicates if the channel failure rate is above the definedthreshold in time slot 6 01表示TS6高于定义的信道失败率门限00: belove threshold (no alarm)01: above threshold (alarm)9 indicates if the channel failure rate is above the definedthreshold in time slot 7 01表示TS7高于定义的信道失败率门限00: belove threshold (no alarm)01: above threshold (alarm)10 time slot with the highest failure rate 失败率最高的时隙11 subchannel identification TCH: 02表示子信道为tch00: TCH/H -subchannel 001: TCH/H -subchannel 102: TCH/F -subchannelsubchannel identification SDCCH:00 - 07: SDCCH -subchannel 0 - 712 proportion of TCH or SDCCH subchannel releases due to failurein all channel releases on a given channel during the measurementperiod 指定信道，TCH/SD因失败释放信道占所有trx释放信道的百分比第二部分告警处理流程1、告警预处理考虑到告警可实施性，暂拟处理流程如下：1、对于单时隙掉话告警，使用“ZERS”指令，闭锁-解锁该告警时隙，后观察对比。

7745案例

编者:网元: BTS 2011年1月25日案例1基本情况工程师姓名周先仕项目经理姓名项目名称江西移动南昌分公司工作地点南昌市新建县网元种类BTS 站名站号新建药湖3(GBS1806) 案例发生时间2010-12-08 案例处理时间2010-12-10故障现象:站型：Ultra SiteTRX7、TRX8有7745掉话告警，上行链路通话质量差7745告警诠释:7745：CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD 告警含义：在一个信道中，呼叫因失败而终止的比率超出了操作员设置的门限值。

该告警用来监控话务和信令信道的功能，并检测可能出故障的信道。

7745在BSC上的补充信息诠释：01 00 01 01 01 01 01 01 01 040289d1、指示告警是出现在TCH还是在SDCCH信道01:TCH (所指上绿)02:SDCCH2、指示在时隙0(所指上蓝)的信道故障率是否高于指定的门限值00:高于门限值（无告警）01:低于门限值（有告警）3、指示在时隙1(所指上粉红)的信道故障率是否高于指定的门限值00:高于门限值（无告警）01:低于门限值（有告警）4、指示在时隙2(所指上深蓝)的信道故障率是否高于指定的门限值00:高于门限值（无告警）01:低于门限值（有告警）5、指示在时隙3(所指上红色)的信道故障率是否高于指定的门限值00:高于门限值（无告警）01:低于门限值（有告警）6、指示在时隙4(所指上红色)的信道故障率是否高于指定的门限值00:高于门限值（无告警）编者:网元: BTS 2011年1月25日01:低于门限值（有告警）7、指示在时隙5(所指上深红)的信道故障率是否高于指定的门限值00:高于门限值（无告警）01:低于门限值（有告警）8、指示在时隙6(所指上深红)的信道故障率是否高于指定的门限值00:高于门限值（无告警）01:低于门限值（有告警）9、指示在时隙7(所指上深黄)的信道故障率是否高于指定的门限值00:高于门限值（无告警）01:低于门限值（有告警）10、最高故障率的时隙(所指上红色字体)11、TCH 子信道标识：(所指上绿色字体)00：TCH/H-子信道001：TCH/H-子信道102：TCH/H-子信道12、89d为掉话率(所指上蓝色字体)处理过程:此基站是Ultra Site站型,配置是S4/3/3/，根据网优KPI值的数据分析，TRX7、TRX8有7745高掉话告警，到现场后，查看基站的RSSI值，发现TRX7和TRX8的主接收和分集接收偏差很大，用驻波比测试仪表测量驻波比正常，对TRX7和TRX8载频进行环路测试，发现这两个载频的主接收和分集接收偏差很大，后来检查发现载频的RF连线有错丝及未拧到位现象，将载频的RF连线重新调整以及紧固，观察数小时后告警没有再出现。

诺西基站典型故障处理

12
5
994940 PWR – PWR 5
7
6
994940
PWR– PWR 6
8
9
/ 2020/4/22
使用ERXA时的连线
/ 2020/4/22
一、7601风扇和电源线故障
所以当一个基站配置载频大于12块逻辑载频且使用系统扩展模块 ESEA时，千万要注意载频电源线的连接位置，如果位置错误就会出现 7601：Module power cable connections are incorrectly configured告警。
处理过程：1、检查同步设置是否正确，特别注意ULTRA和FLEXI EDGE两种设备类型，当有两队传输的时候，第二对传输也要设置成RX CLOCK
诺西基站典型故障案例
网络维护中心
1
目录
FLEXI 基站7601与7607故障掉话与时钟故障风扇与天馈故障 7606与干扰故障
2
一、7601风扇和电源线故障
告警号：7601
告警内容：风扇告警：ESMA System module cooling fan(s)
report no rotation 电源连线告警：Module power cable connections
/ 2020/4/22
1
INSTALLATION GUIDE
EDGE/BTS 8+8+8 WBC 4:1
2
Bus Cables
3
4
• NUMBE R
CABLE
FROM – TO
5
1
994939 BUS – BUS1
2
994939 BUS – BUS2
6
3

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告警，告警提示为合路器反射功率过高。