爱立信常见告警处理

常见告警处理
A1类告警
CP FAULT
一、告警产生原因：
CP FAULT一般是位于CPS或MAU中的硬件故障。

当系统发现一个永久性故障或三个相同类型的暂时性故障或暂时性故障出现频率太高时，MAS 的软件就会产生CP FAULT的告警。

二、告警处理流程：
具体告警处理和操作规程请参考B-MODULE ALEX相应的OPI。

以下为主要操作步骤：
当CP FAULT告警出现时，首先察看CP的状态，若状态为<DPWSP；
CP STATE
MAU SB SBSTATE
NRM B WO
为正常状态，此类的CP FAULT是A3或A2告警，则留到晚上低话务量时处理；其余均为不正常状态，必须马上根据OPI：CP FAULT的ACTIONS进行现场处理。

CP FAULT的诊断测试：
<REPCI；诊断。

同时出现O1告警：SYSTEM STATE REPAIR OF CP OR MAU。

诊断结果有两种情况：
（1）.无怀疑板块列出。

<RECCI；检修，将告警消掉。

（2）.有怀疑板块列出。

a. 错误类型为Permanent(永久性)。

根据提示选择最怀疑板块，准备现场更换。

b. 错误类型为Temporary(临时性)。

若所有的最怀疑板块在最近30天内都换过，则用：
<DIRCP；
<DIECP:INF=PAR;
<DIRRP；收好报告，留待爱立信专家分析。

<REPCE；将诊断进程结束。

若尚有板块可以更换，则参照错误类型为Permanent进行。

在进行现场操作时，故障管理人员对CP的结构、性能和应急措施因相当的清楚, 以避免因操作不当,造成直接的经济损失。

在修理过程种，故障管理人员要仔细确认REPCI的诊断结果, MAG和PCB的准确名称和位置, 若选错MAG和PCB,不但RECCI不能修过, 且会引起A1的CP FAULT和一侧CP的单边。

<REMCI：MAG= ，PCB= ；
此刻系统将所需换的板子隔离出来，我们根据提示，按顺序关电，换板，再开电。

<RECCI；检修。

成功，则CP FAULT告警消失，O1告警消失，CP状态恢复正常。

若不成功，则CP FAULT告警仍在，O1告警仍在。

此时最好再次进行诊断。

注意，在再次诊断之前，只要有O1告警在，就须先将上次诊断进程结束：
<REPCE；O1告警消失。

<REPCI；再次诊断。

<REMCI：MAG= ，PCB= ；选择最怀疑板块关电换板。

<RECCI；检修。

成功，OK。

不成功，则重复上述四步。

BLOCKING SUPERVISION
一、告警产生原因：
中继闭塞监测告警，通过指令设置告警门限：〈BLURC：R=，ACL=，LVB=；如路由中NBLO（DEV闭塞数）大于告警门限值便会发生此告警。

二、告警处理流程：
1．STRSP:R=r;
2．STRDP:R=,STATE=BLOC;显示闭塞的DEV
3．EXDEP:DEV=dev; 显示dev对应的SNT,从而找出对应的DIP
4．DTSTP:DIP=;NTSTP:SNT=;检查DIP、SNT状态。

5．若DIP状态为ABL，说明传输中断，报传输人员处理
CCITT7 SIGNALLING LINK FAILURE
一、告警产生原因：
信令被激活状态下无法正常服务或信令出错后无法恢复正常
二、告警处理流程：
1．查看信令链路状态：
C7LTP：LS= ；
2．将故障SLC进行闭解：
C7LAE：LS= ，SLC= ；
C7LAI：LS= ，SLC= ；
3．若闭解无效则查看信令链路数据：
C7LDP：LS= ；
EXDEP:DEV= ；查看SNT
NTCOP:SNT= ;找到DIP
DTSTP:DIP= ;看DIP状态
若DIP为ABL则报传输处理，若DIP为WO，
EXSCP:NAME= ;看信令所在半永久状态，若状态为ACT则联系对端局闭解或删定信令链路，若状态不为ACT则删定半永久连接，具体操作见
“SEMIPERMANENT CONNECTION FAULT”
如进行以上操作后，告警仍没有清除，报故障管理人员
CCITT7 DESTINATION INACCESSIBLE
一、告警产生原因：
信令网中的某个信令点无法被访问，即信令点不可及告警。

如某一SP瘫掉，或到某一SP的LINK全部中断，没有迂回信令路由的情况，产生此告警。

该告警
一般会伴随“CCITT7 SIGNALLING LINK FAILURE”出现
二、告警处理流程：
<C7RSP：DEST= ；查看到该DEST信令路由情况
C7LTP:LS= ;
以下同处理“CCITT7 SIGNALLING LINK FAILURE”告警步骤
CCITT7 LINK SET SUPERVISION
一、告警产生原因：
两个交换局之间有多条信令链路，通过指令设置告警门限：<C7SUC：LS= ，LVA= ，ACL= ,DMI= ；若被闭掉的链路数大于告警门限便会发生此告警。

二、告警处理流程：
1．去、激活告警的信令链路：
<C7LAE：LS= ，SLC= ；
<C7LAI：LS= ，SLC= ；
2．根据告警内容，判断是否由传输故障引起：
C7LDP:LS=ls; 查信令的一些参数
EXDEP:DEV=dev; DEV对应的SNT
NTCOP:SNT=snt; SNT对应的DIP
DTSTP:DIP=dip; 传输是否中断
DTQUP:DIP=dip; 传输是否误码
NETWORK SYNCHRONIZATION FAULT
一、告警产生原因：
网络同步采用主从方式，外部时钟是通过话务数字链路接入到ETC板，由ETC板识别出帧同步信息，产生一个8KHZ的信号分别接入三个时钟模块（CLM），经锁相环调整，输出三个互不相干的时钟信号到接收模块（TSS、SPM），由接收模块择优选用。

交换机自身有一个时钟模块，为参考时钟模块（RCM），参考时钟模块是由晶体振荡源组成的时钟，主要用于交换机的备用时钟源，CLM-1 和CLM-2相位锁定为CLM-0（MASTER），当CLM－0输出值较大时，CLM－1、CLM－2
跟随CLM－0导致输出值偏差较大，导致NETWORK SYNCHRONIZATION FAULT。

日常维护中必须对交换机的CLM进行检查、调整，保证其工作在正常值2048+－200范围内。

二、告警处理流程：
NSSTP;查看CLOCK-REFERENRE 状态。

NSDAP; 查看网同步时钟数据
GSCVP; 查看CLM的值
NSBLI;闭掉
NSTEI;测试
NSBLE;解闭
如测试不通过，需由故障管理人员根据相关告警信息进行处理。

测试正常解闭后该时钟参考源会处于UPD状态，此过程约需12小时。

EXTERNAL ALARM
一、告警产生原因：
交换机某些重要的辅助设备，如：电源、风扇，以及基站的天线等发生故障时，在交换机上产生相应的外部告警。

二、告警处理流程：
具体告警处理和操作规程请参考B-MODULE ALEX相应的OPI。

以下为主要操作步骤：
1．若出现的外部告警为电源告警，则应立即通知相关人员到达现场检查电源设备；
2．若为其他外部告警：
（1）则用ALRDP：DEV=ALEX2—；查询外部告警相关参数；
（2）闭解外部告警：BLEAI：DEV=ALEX2—；
BLEAE：DEV=ALEX2—；
（3）若闭解后告警重新出现，则要通知相关人员到达现场处理硬件故障。

SP UNIT FAULT
一、告警产生原因：
SP（支持处理）单元发生故障。

二、告警处理流程：
具体告警处理和操作规程请参考B-MODULE ALEX相应的OPI。

以下为主要操作步骤：
因主要涉及硬件修理，故由故障管理人员操作。

1．查看两个NODE（NODE A和NODE B）的状态：
IMLCT：SPG=0；（假设SPG=0发生故障）
IMCSP；
END；
2．如果出错的是执行侧（EX），则进行测试：
RESUI：SPG=0，NODE= ；
3．若测试通过则将其解开：
BLSNE：SPG=0，NODE= ；
4．若出错的为备用侧（SB），则将其闭掉：
BLSNI：SPG=0，NODE= ；
显示检测报告：DISFP：SPG=0，NODE= ；
若未有错误单元列出则执行2、3步骤，若有错误单元列出则：
RESUP：SPG=0，NODE= ；找出错误单元进行硬件修理，修理成功后执行步骤3。

FILE PROCESS UTILITY AUTOMATIC TRANSFER FAILURE 一、告警产生原因：
具有FPU功能的文件自动传送失败。

二、告警处理流程：
ALLIP;
根据告警内容确认是什么文件出现告警。

IMLCT: SPG=X; (0 或 1)
ILLUP;
ILNPP (: PORT=ALL);
END;
相应的端口是否ABL, 若ABL进行闭解：
IMLCT: SPG=X; (0 或 1)
ILBLI: PORT=X-X-X-X;/ ILBLI: NP=X-X-X-X;
ILBLE: PORT=X-X-X-X;/ ILBLE: NP=X-X-X-X;
ILNPP (: PORT=ALL);
若端口状态仍为ABL,确认硬件损坏,需要更换硬件处理.
若端口状态WO，表示端口状态正常，则进行人工传送文件：
INFUP: FILE=XXX;
INFSP: FILE=XXX, DEST=YYY;
INFTI: FILE=XXX-AAA, DEST=YYY;
INFSP: FILE=XXX, DEST=YYY;
SWITCHING NETWORK TERMINAL FAULT
一、告警产生原因：
1．SNT和GROUP SWITCH之间接口错误被检测到；
2．SNT的外部硬件设备或SNT和外部设备间的接口错误被检测到；
3．SNT单元硬件板子被检测到错误。

二、告警处理流程：
1．闭掉相应SNT：
NTBLI：SNT= ；
2．测试SNT，找出故障原因：
NTTEI：SNT= ；
3．若有被怀疑硬件列出，交故障管理人员处理，更换硬件后继续测试SNT。

若测试通过则解闭SNT：
NTBLE：SNT= ；告警清除。

GROUP SWITCH FAULT
一、告警产生原因：
GROUP SWITCH被检测到有错误。

二、告警处理流程：
1．检查故障单元状态。

有3种设备类型：Clock Module (CLM) 、Space Switch Module (SPM) 、Time Switch Module (TSM) 。

2．TSM故障的处理步骤：
1）查看所有TSM状态 GSSTP: TSM= ；
2）闭掉有故障的单元GSBLI：TSM= ；
3）测试该TSM GSTEI：TSM= ；
4）若测试结果有错误单元列出则更换硬件，若无则解开TSM：
GSBLE：TSM= ；若测试结果为硬件故障，交故障管理人员更换硬件处理。

3．SPM故障的处理步骤：
注意：对SPM进行闭塞测试时，有可能会引起相关半平面的TSM也同时闭塞，因此对SPM的操作需在话务闲时进行。

1）查看所有SPM状态 GSSTP: SPM= ；
2）闭掉有故障的单元GSBLI：SPM= ；
3）测试该SPM GSTEI：SPM= ；
4）若测试结果有错误单元列出则更换硬件，若无则解开SPM：
GSBLE：SPM= ；若测试结果为硬件故障，交故障管理人员更换硬件处理。

4．CLM故障的处理步骤：
1）ALLIP;查看是否有与CLM相关的EM FAULT告警。

如有，先参照EM FAULT 处理流程修理EM。

修理不成功，交故障管理人员更换硬件处理。

2）没有上述告警，可对故障的CLM进行测试：
闭掉有故障的单元GSBLI：CLM= ；
测试该CLM GSTEI：CLM= ；
若测试结果有错误单元列出则更换硬件，若无则解开SPM：
GSBLE：CLM= ；若测试结果为硬件故障，交故障管理人员更换硬件处
理。

注意：CLM发生故障时，若同时有SPM处于WO/S状态，除测试列出的错误单元外，两者之间的接口板和连线也有可能会存在问题。

5．若某TSM、SPM、CLM频繁出现告警，但通过闭解操作又能修复，需通知故障管理人员进行进一步测试和故障定位。

DIGITAL PATH QUALITY SUPERVISION
DIGITAL PATH UNA V AILABLE STATE FAULT
一、告警产生原因：
传输质量降低，出现误码、滑码等数量超过定义的监测值，即产生上述告警。

二、告警处理流程：
DTSTP:DIP=dip; 显示该DIP状态
DTQUP:DIP=dip; 显示该DIP是否有误码等
DTQSR: 清除误码等
Synchronous Digital PATH QUALITY SUPERVISION
一、告警产生原因：
传输质量降低，出现误码、滑码等数量超过定义的监测值，即产生上述告警。

由于光纤传输质量稳定，上述告警平时较少出现。

在遇光缆割接或环路倒换时会出现大量上述告警。

二、告警处理流程：
TPSTP:SDIP=sdip; 显示该SDIP状态
TPQUP:SDIP=sdip; 显示该SDIP是否有误码等
TPQSR: 清除误码等
Synchronous Digital PATH F AULT
TPSTP:SDIP= ; 显示该SDIP状态
1、若出现MS-0或MS-1状态为ABL则
TPBLI:SDIP= ,MS= ;
TPBLE:SDIP= ,MS= ;闭解MS
PWFSI：
2、若出现VC12-XX状态为ABL
TPCOP:SDIP= ;找出VC12-XX对应的DIP，到传输资料中查找该DIP是否为在用的。

如为在用的则报传输处理，如不在用的则
DTBLI:DIP= ;
TPBLI:SDIP= ,LP= ;闭掉该VC12
RADIO TRANSMISSION GB INTERFACE FAULT
一、告警产生原因：
BSC中“GB”接口告警，常见的有两种情况，一是NS层被闭塞掉，一是NSVC 拥塞或被禁止状态。

二、告警处理流程：
1．NS层被闭塞的情况，一般由SGSN设备告警造成，需故障管理人员处理。

2．当NSVC告警时，首先检查相关DIP和SNT 状态，正常状态则闭解NSVCI：〈RRVBI：NSVCI=；〈RRVBE：NSVCI=；
3．将相关RP进行分离、闭解：
EXRPP:RP=ALL;(RP类型为RPP的即是)
FCRWS:RP=,SEP=YES;
BLRPI:RP=;
BLRPE:RP=;
4．仍不好，进行NSVCI的重定义：
〈RRGBP；
〈RRVBI：NSVCI=；
〈RRNSE：NSVCI=；
〈BLODI：DEV=；
〈RRNSI：NSVCI=，DEV=，NUMDEV=，DLCI=；
〈RRVBE：NSVCI=；
〈BLODE：DEV=；
〈RRGBP；
NM ROUTE ASR SUPERVISION
一、告警产生原因
路由上话务应占比低于告警门限值。

一般在凌晨话务闲时会产生，能自动恢复，不需处理。

二、告警处理流程：
如该告警在话务忙时出现，或频繁出现，需通知故障管理人员处理。

A2类告警
SEMIPERMANENT CONNECTION FAULT
一、告警产生原因：
在交换机GS内，用于连接PCM信道和信令终端的DEV就是半永久连接。

它只能使用指令来断开。

一般情况是由于传输中断而引起此告警。

二、告警处理流程：
EXSCP:NAME=; 查看半永久连接的DEV数据（该DEV用在DIP和ST上）。

根据相关告警信息，由故障管理人员处理硬件故障。

硬件恢复正常后，告警清除。

如无其他相关告警，半永久连接未恢复，可重定义半永久连接：
EXSPI:NAME=;
EXSSI:DEV1=;
EXSSI:DEV2=;
EXSPE;
EXSCI：NAME=，DEV=；
PORT BLOCKED
一、告警产生原因：
当端口存在故障时（例如无法解闭端口、无法读取端口配置文件、端口发出或收到一个FRMR帧，端口出现硬件故障等，具体分类详见ALEX）,会产生此告
警。

二、告警处理流程：
具体告警处理和操作规程请参考B-MODULE ALEX相应的OPI。

以下为主要操作步骤：
1、根据PORT BLOCKED告警中ALARMINFO内容在ALEX中查找对应处理步骤。

2、以ACTIVATION FAILED为例，操作步骤如下：
IMLCT:SPG=;
ILNPP:检查网络端口数据
ILLUP:检查LU数据
3、数据正确的话进行闭解端口ILBLI:PORT=; ILBLE:PORT=;远程处理时，如果闭解端口后不能清除告警，需要由故障管理人员进行进一步的修理。

4、如果闭解端口后告警没有清除，可用ILLTI进行测试。

如果仍然无法清除告警，可将PORT数据、LU数据删除后重新定义。

5、删除PORT数据
IMLCT:SPG=;
ILBLI:NP=;/ILBLI:PORT=;
ILSLR:NP=;/ILSLR:PORT=;
1、删除LU数据
IMLCT:SPG=;
IMHWP[:NODE=node];检查设备是IOG11还是IOG20
2、如果是IOG11采取以下步骤：
IMLCT:SPG=;
ILLUP:LU=ALL;检查主备用LU的状态
ILBLI:LU=;将主备用的LU人工关闭
ILLUR:LU=;删除LU数据
ILLUI:LU=lu,CHAR=char[,TWIN];定义LU数据
ILBLE:LU=;将LU人工解闭
ILSLI:NP=np,PROT=prot,RATE=rate;定义NP、PORT数据
ILSLC:NP=,;根据需要修改端口参数
ILBLE:NP=;/ILBLE:PORT=;解闭端口
BLOCKING SUPERVISION OF DEVICE
一、告警产生原因：
某些路由上定义了闭掉设备数目监测告警。

如果一条路由上发现太多的设备闭掉，高于设置的门限，BLOS就会产生一个告警，告警级别依赖于命令的设置。

二、告警处理流程：
具体告警处理和操作规程请参考B-MODULE ALEX相应的OPI。

以下为主要操作步骤：
1、暂停该路由监测：
BLURE:R=r...[,PERM];
2、显示dev对应的SNT,从而找出对应的DIP
EXDEP:DEV=dev;
另外可以查看传输告警
3、依次闭掉相应的设备：
BLODI:DEV=dev...;
4、解闭相应的设备：
BLODE:DEV=dev...;
5、复位该路由监测：
BLURI:R=r...;
执行以上操作后若不能清除告警，需故障管理人员进行处理。

HLR SUBSCRIBERS WITH INCOMPATIBLE DATA SUPERVISION
一、告警产生原因：
当不匹配的用户数量达到先前设定的门限值时，告警产生。

二、告警处理流程：
报送帐务班进行更改
INFINITE FILE END WARNING
一、告警产生原因：
无限连续文件满或写入失败。

二、告警处理流程：
1、使用IOIFP查看子文件的状态。

IOIFP:[FILE=file]；如果为计费文件（TTFILE），通知故障管理人员处理。

统计文件再执行以下操作：
1、使用INFSP查看文件传送情况。

INFSP:FILE=file[-subfile[-gen]],DEST=dest,[,ORDER=order][,IO=io];
与故障管理人员确认为垃圾子文件后，执行以下操作将其删除。

2、使用INFUP查看FPU功能。

INFUP：FILE= file[-subfile[-gen]]，DEST=dest；
3、如有FPU功能，需先取消。

INFUE:FILE= file[-subfile[-gen]]；
4、删除文件。

INFIR：FILE=file[-subfile[-gen]]；告警清除。

VOLUME LIMIT EXCEEDED
一、告警产生原因：
每个VOLUME在硬盘上都定义了一定的空间大小，并且设置了容量门限值。

当VOLUME下的子文件容量大于该门限值时就会产生VOLUME LIMIT EXCEEDED告警。

二、告警处理流程：
1、检查告警中所示卷标的数据：
INMCT:SPG=0;
：INVOP[:VOL=vol];
2、如卷标名是RELVOLUMSW,则执行以下指令查看该卷标下的子文件列表：
INMCT:SPG=0;
:INFIP:FILE= RELCMDHDF;
其他卷标名用指令INFIP:VOL= ;
3、与故障管理人员确认是否需要对文件进行保存。

如需要，由故障管理人员
保存：
将子文件保存，保存方法有2种：一是人工传送、二是拷贝到光盘上。

INFTI:FILE=file,DEST=dest[,EQUIP=equip][,REVERSE]
[,FILEID=fileid,RULE=rule];
INFMT:[SPG=spg,]DEST=dest,VOL1=vol1[,COPIER=copier];
4、不需要保存的文件，直接删除，使卷标的已使用容量小于设置的门限值。

INFUE:FILE=;（有FPU功能的文件先进行该功能的清除）
INFIR:FILE=file;
END;
LINE UNIT BLOCKED
一、告警产生原因：
LU闭塞。

二、告警处理流程：
3、进入DCS子系统
IMLCT：SPG=spg；
4、查看LU板状态：
ILLUP：LU=lu；
5、人工闭LU板：
ILBLI：LU=lu；
6、解闭LU板：
ILBLE：LU=lu；若执行以上操作后，告警仍未清除，交故障管理人员进行硬件检测处理。

SIZE ALTERATION OF DATA FILES SIZE CHANGE REQUIRED
一、告警产生原因：
存储数据的SIZE不够。

二、告警处理流程：
1、查看出现SIZE告警的SAE：
DBTSP：TAB=SAACTIONS；
2、查看出告警的SAE、BLOCK的NI值：
SAAEP：SAE=sae，[BLOCK=block]；
3、自动扩SIZE：
SAALI；
4、如果不成功，手动扩
SAAII：SAE=sae，BLOCK=block，NI=ni；告警清除。

将以上操作做好LOG，交故障管理人员进一步分析。

如同一个SIZE频繁出现告警，需及时通知故障管理人员处理。

（故障管理人员应对产生告警的SIZE 具体作用以及该SIZE拥塞的相关影响进行分析。

通过这种分析，可以及时地了解网络的状态及相关话务模型的趋势。

并且由于执行过SAAII指令增加SIZE值，故在闲时需要做一个人工软件备份）
RP FAULT
一、告警产生原因：
RP 发生硬件故障时会产生上述告警。

二、告警处理流程：
修理所用指令如下:
<REPRI：RP= ；
<REMRI：RP= ，PCB= ；
<RECRI：RP= ；
如果修理不成功，一般为RP硬件故障，交故障管理人员处理。

更换RP硬件时需注意:
1. RP所属的类型.
2. 202型设备需注意RP的位置,电缆。

3. 指令SARPI是对BYB501串型BUS的操作。

当RP FAULT告警出现时，应根据OPI操作流程得出要更换的硬件,进行替换。

当需要中断BYB501机框上一侧串行RP BUS的连接时,则需用指令SARPI防止RP BUS中断对CP运行的干扰,操作结束后, 用指令SARPE恢复。

EM FAULT
一、告警产生原因：
EM（ Extension Module）是交换机中最小的控制单元。

EM有可能是ETC，TSM 或其他单元，当EM有故障时，EM FAULT 告警产生。

二、告警处理流程：
<BLEMI:RP=,(RPT=),EM=;
<BLEME:RP=,(RPT=),EM=;；
如闭解EM无效，进行软件修理：
<REPRI:RP=,EM=;
<REMRI:RP=,EM=,PCB=;
<RECRI:RP=,EM=;
如果修理不成功，一般为EM硬件故障，交故障管理人员处理。

BACKUP INFORMATION FAULT
一、告警产生原因：
系统备份功能中产生错误或有制约时产生上述告警。

二、告警处理流程：
在话务闲时做一次系统备份SYBUE；
SYBUP:FILE=RELFSW*;
SYBFP:FILE;
SYTUC;
SYBUI:DISC;打开自动DUMP。

若进行上述操作后，告警仍然不能清除，需要故障管理人员处理。

SOFTWARE ERROR
一、告警产生原因：
交换机出软件错误。

二、告警处理流程：
1、查看软件错误修复情况：
SYRIP：SURVEY；
2、手动清除告警：
SYRAE：RECTYPE=SOFTERROR；或：
SYRAE：EVENT= event；告警清除。

ALI FAULT
一、告警说明：
ALI是IOG的组成部分，一般告警接口单元故障时产生该告警。

二、告警处理流程：
1．查看告警触发条件
ALDIP;
2．闭掉该ALI
ALBLI:ALI=ali;
3．解闭ALI
ALBLE:ALI=ali;告警清除。

如执行以上操作后告警仍不能清除，则交故障管理人员检测硬件，进一步处理。

APPLICATION DETECTED SOFTWARE ERROR
一、告警产生原因：
交换机产生的软件错误被某些应用检测到就会产生一个告警，告警级别依赖于命令的设置。

二、告警处理流程：
1、显示软件错误恢复信息：
SYRIP:SURVEY;
2、SYRIP:EVENT=;将处于ACTIVE状态的EVENT的内容做好LOG，提供爱立信银牌进行分析，查找错误原因。

3、SYRAE:EVENT= ; 清除该告警。

PVC SET-UP FAILURE
一、告警产生原因：
该功能由Data Communication Subsystem (DCS)实现。

此告警产生有多种原因，例如无法从硬盘上载入A侧的PVC信息，B侧的协议无法处理PVC服务等。

二、告警处理流程：
1、根据告警显示内容中的错误类型参照ALEX进行处理操作。

2、下面以“ACCESS BARRED”错误类型为例，操作步骤如下：
IMLCT:SPG=;
/ \
| / \|
| |NTN=ntn...||
ILACP|:+ +|;检查通路参数
| |CUG=cug ||
| \ /|
\ /
ILBLI:NP=;/ILBLI:PORT=;将端口人工闭塞
更改NTN的通路：
ILACC:NTN=ntn +[,PRI=pri][,ICB=icb][,OCB=ocb][,IAC=iac][,OAC=oac]+;
ILBLE:NP=;/ILBLI:PORT=;将端口人工解闭，观察告警是否消失。

AUDIT FUNCTION THRESHOLD SUPERVISION
一、告警产生原因：
交换机定义了CP存储器（PS、DS、RS）占用情况和SAE文件使用监测告警。

如果CP存储器（PS、DS、RS）占用或SAE文件大小高于设置的门限，就会产生一个告警，告警级别依赖于命令的设置。

二、告警处理流程：
1、告警信息TEST决定处理步骤（一般TEST=110）：
2、显示文件使用日志：
AFTSP:TEST=110,LOG;
3、根据得到的SAE值进行自动扩SIZE：
SAALI;
4、若自动扩不成功，则进行人工扩SIZE：(需先和爱立信银牌确认扩充方法)
SAAII:SAE= ,NI= ;
5、重复以上2-4步骤，直到所有SIZE扩完：
6、告警处理完毕,话务闲时做一次人工Dump。

A3类告警
CCITT7 DISTURBANCE SUPERVISION LIMIT REACHED
一、告警产生原因：
7号信令扰动监测。

二、告警处理流程：
1、ALLIP;
2、查看扰动数据：
C7DSP：ENUM=enum；
3、将告警计数器RESET：
C7DSR：ENUM=enum；告警清除。

“C7 event” 报告是对七号信令网络安全监测的重要手段, 在日常维护工作中, 应根据需要激活相应的C7 event 报告。

有个别ENUM对话务有影响：110、120、132、133、145、207，出现以上ENUM告警时由故障管理人员进行处理。

HLR AUTHENTICATION DATA REQUEST FAULT
一、告警说明：
HLR认证数据请求故障，一般当AUC向HLR提请认证数据失败时产生该告警。

二、告警处理流程：
1．查看认证提请失败记录
HGALP:NLOG=\ \;
2．将以上记录做好LOG,交故障管理人员进行分析，并进行相应处理。

3．将告警计数器RESET：
HGALR; 告警清除。

SEIZURE QUALITY SUPERVISION
一、告警说明：
这项功能是用来监测正常呼叫和不正常呼叫的比率。

能够受此功能监测的电信设备有BT、RT和KR。

一个设备在进行256次呼叫后，正常呼叫和不正常呼叫之间的比率将被检测并与本路由组内所有设备的平均值做比较。

如果比率偏离超过命令创建值，设备就会被认为发生错误或被闭掉。

二、告警处理流程：
1．显示产生告警的设备
SEQIP:R=\ \;
2．将占用质量监测计数器清零
SEQAR:R=r;
SIGNALLING FAULT SUPERVISION
一、告警说明：
信令故障监测告警。

二、告警处理流程：
1．查看指定路由上信令故障设备情况
FAIAP: R=\ \,[,FRP];
2．将监测计数器清零
/ \
|DEV=dev...|
| |
FAIAR:+R=r... +;
| |
|ACL=acl...|
\ /
“AP SYSTEM ANALYSIS”
说明：APG40中，剩余空间不足16%时为A2告警，在不足4％时为A1告警，以上的值包括2％的阈值幅度，即真实的
剩余空间只有18％时告警才会消除。

以上值需通过PCANYWHERE看C:的属性而得。

考虑到系统盘的重要性，我们主要做以下的处理，并得到告警消除的结果。

步骤：
1.检查以下目录：
C:\temp
C:\acs\logs\core
C:\acs\data\ftp
C:\Inetsrv\Ftproot
可以删除大的.log文件，如后缀为OLD的，但保留后缀为new的，将所有的CORE.xxx文件MOVE到F:\acs\logs\core
2.做以下命令检查有无RELOAD文件R1,R2...
dir c:\R? /s 可以MOVE到F:\,也可以删除。

3.检查老的的DDI文件，可以删除，也可以MOVE，确保有适合数目的较新
的DDI文件。

dir /od c:\bur
4.检查FTP的LOG，对于本月前的，无需保留
APZ21233:
dir C:\winnt\system32\LogFiles\MSFTPSVC1
APZ21240:
dir C:\winnt\system32\LogFiles\MSFTPSVC1
dir C:\winnt\system32\LogFiles\MSFTPSVC2
dir C:\winnt\system32\LogFiles\MSFTPSVC3
5.检查回收箱，如有必要通过PCANYWHERE清除：
dir c:\recycler /A /s
6.检查有无“Temporary Internet Files”可以删除。

cd /d c:\winnt\profiles
7.检查有无病毒更新文件，对于老的文件可以删除。

dir *nt86* /A /s DEL *nt86* /A /s
8.在C:\Program Files\CA\eTrust Antivirus\Backup下是否有.BAK文件，
可以将其MOVE到F:\
9．检查C:\Winnt\$NtUninstall…\目录，此类目录不在使用，可以MOVE 到F：盘。

AP CP 失去联系：
a.尝试TELNET到ACTIVE NODE
b.Ping IPN device,确认物理连接正常。

c.命令"cluster netint "来检查和CP的接口是否正常。

C:\>cluster netint
Listing status for all available network interfaces:
Node Net Status
-------------------------- -------------------------- -------
KSMSC3APG1B IPN100-2 Up
KSMSC3APG1B IPN100-1 Up
KSMSC3APG1B Heartbeat 2 Up
KSMSC3APG1B Heartbeat 1 Up
KSMSC3APG1B Local Maintenance Up
KSMSC3APG1A IPN100-2 Up
KSMSC3APG1A IPN100-1 Up
KSMSC3APG1A Heartbeat 2 Up
KSMSC3APG1A Heartbeat 1 Up
KSMSC3APG1A Local Maintenance Up
KSMSC3APG1A Public Up
KSMSC3APG1B Public Up
d.ipnaadm –list
C:\>ipnaadm -list
Connected IPNAs are :
ipna00 ipna01
endlist
e.如果c,d OK,CP_AP仍然无联系，通过CPT连接：
PTCOI;PTWSP;PTSRI:RANK=SMALL;
f.如果无法CPT连接，REBOOT主用侧，做个切换，然后再尝试CPT
连接。

进程死亡
cluster res 来确认进程为ONLINE,OFFLINE,或FAILURE
a.检查死亡或停止的进程在ACTIVE或PASSIVE侧，若在ACTIVE侧，
做切边（prcboot）,让问题的NODE为PASSIVE状态；
b.人工启动进程.
cluster res <process name> /on /wait
cluster停止
类似于NODE DOWN.
a.如何判断cluster down
prcstate 显示状态为UNDEFINED.
b.检查cluster service
net start检查SERVICE是否正常启动
首先为clussvc,其次为ACS_PRC_LBB
c.如果以上SERVICE已经启动，则尝试再次PRCBOOT.
d.如果SERVICE未启动，尝试人工启动：
net start "Cluster Server"
net start "ACS_PRC_LBB"
e.如果能够正常启动，CLUSTER应会稍后正常（UP）
f.如果不能启动，再次启动NODE(prcboot),如仍无效，呼叫爱立信工程师。

APG40中的统计简介
APG40中有两类统计，Recording和STS。

Recording类型的统计使用的是CP系统文件。

其统计结果存于L:\FMS\data\CPF\EXCHVOLUME下面。

在MSC中目前使用的Recording类型统计一般是两类.
Traffic Measurements On Routes (TRAR)
Traffic Dispersion Measurement (TRDIP)
这两类统计文件由CP中的MP（Measuring Program）控制生成。

Recording 类型的统计配置是通过CP指令查看。

MSC中查看这两类Recording的命令是:
<TRRPP:MP=ALL;
<TRDMP:MP=ALL;
另一种类型的统计是STS (Statistics and Traffic Measurement)。

STS不使用CP文件系统，而是有自己的数据库及输出文件格式。

STS是以Object Type和Counter的方式从CP申请统计的结果，并将结果存于AP中的数据库中（R:\STS\data\DBTOP），然后又可以将不同类型的Object Type的统计组织成报告。

可以通过Measure Program定期地或人工即时地将统计报告生成不同格式的统计文件（ASN.1或Load File）存放于S:\STS\data\Deliverybuffdir或者S:\STS\data\Deliverydir中以备传到OSS的后台处理程序分析。

STS类型的统计的配置是通过AP指令查看：
查看AP从CP申请了哪些Object Type的Counter统计。

C:\>stmotls -l
查看STS统计报告的配置
C:\>stmrp -L -l
REPORTID IN-USE NAME OBJECT TYPES
2001 yes gxwgzx01 CHASSIGNT HNDOVER UPDLOCAT PAGING
NBRMSCLST LOCAREAST
查看STS统计的Measure Program 设置
C:\>stmmp -L -l
MPID UTC BEGINTIME ENDTIME REPEATS INTERVAL REPORTID
1001 no 08/01/2004 12:00:00 infinite 60 2001 OUTPUTFORMAT STATUS MP-NAME
ASN.1 running MP1001
APG40中统计文件的传送配置和检查是通过如下指令进行的：
检查待传送文件的属性，可以看到该文件所定义的传送队列，当前子文件号，文件类型等信息。

C:\>cpfls -l TRARFILE
CPF FILE TABLE
FILE TYPE CMP VOLUME
TRARFILE inf yes EXCHVOLUME
TRANSFER QUEUE MODE
TRARFILE FILE
RLENGTH MAXSIZE MAXTIME REL ACTIVE SIZE USERS
2048 no no yes 359 0 0 [ 0R 0W]
检查传送队列，可以看到定义到该传送队列的文件所在目录，保存时间，及该传送队列所对应的传送方向
C:\>afpls -l TRARFILE
AFP TABLE
TRANSFER QUEUE USER GROUP
TRARFILE
SOURCE DIRECTORY
L:\FMS\DATA\CPFTQ\TRARFILE
REMOVE DELAY REMOVE TIMER DEFAULT STATUS DESTINATION SET
60 0 READY OSSDEST1
检查传送方向，可以看到传送协议（FTPV2）、模式（被动），远端IP地址（Notification），端口号，虚拟目录名称信息。

C:\>cdhls –l OSSDEST1
CDH DESTINA TION TABLE
DESTINA TION TRANSFER TYPE PARAMETERS
OSSDEST1 FTPV2 -c r
-f 132.110.19.1
-x 50010
-h CDH
C:\>afpls -ls TRARFILE
AFP TABLE
TRANSFER QUEUE REMOVE DELAY USER GROUP
TRARFILE 60
DESTINA TION SET DIR REMOVE TIMER STA TUS FILE OR DIRECTORY TRARFILE
NO 59 DELETE TRARFILE_0000000025
STS类型的统计文件的传送方式与上述Recording类型类似，只是待传文件不是CP文件，而是子目录形式在S:\STS\data\Deliverybuffdir中。

C:\>afpls -l
AFP TABLE
TRANSFER QUEUE
GXWGZX01
SOURCE DIRECTORY
S:\STS\DATA\DELIVERYBUFFDIR
REMOVE DELAY REMOVE TIMER DEFAULT STATUS DESTINATION
14400 0 READY OSSDEST1
C:\>afpls -ls gxwgzx03
AFP TABLE
TRANSFER QUEUE REMOVE DELAY
GXWGZX03 14400
DESTINATION DIR REMOVE TIMER STATUS FILE OR DIRECTORY OSSDEST1
YES 14400 FAILED MP1003_200409120300_1 YES 23 DELETE MP1003_200410091800_72。