故障处理手册 - 爱立信GSM - - 20090228 - v3.3 - 图文

更新时间：2024-05-26 21:41:01 阅读量：综合文库文档下载

说明：文章内容仅供预览，部分内容可能不全。下载后的文档，内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的，是否完整无缺。

金风1.5故障处理手册推荐度：
相关推荐

故障处理手册_ 爱立信

V3.3

(省网维核心网络维护室编制)

第一部分监控派单说明 ................................................................................................................. 2 第二部分监控自处理部分 ........................................................................................................... 3

1、AP PROCESS REINITIATED ............................................................................................ 3 2、AP REBOOT ....................................................................................................................... 4 3、ILLEGAL LOGON ATTEMPTS ........................................................................................ 4 4、AP FAULT (GENERAL ERROR) ...................................................................................... 5 5、ALI FAULT ......................................................................................................................... 5 6、BACKUP INFORMATION FAULT ................................................................................... 6 7、CP STATE NOT NORMAL ................................................................................................ 7 8、DIGITAL PATH QUALITY SUPERVISION ..................................................................... 7 9、DISTURBANCE SUPERVISION OF TRUNK ROUTES ................................................. 7 10、DISTURBANCE SUPERVISION OF INDIVIDUAL DEVICES .................................... 8 11、EVENT REPORTING THRESHOLD REACHED .......................................................... 8 12、HLR SUBSCRIBERS WITH INCOMPATIBLE DATA SUPERVISION ........................ 9 13、SEIZURE QUALITY SUPERVISION ............................................................................. 9 14、SEIZURE SUPERVISION OF DEVICES IN BSC .......................................................... 9 15、SIGNALLING FAULT SUPERVISION ......................................................................... 10 16、SOFTWARE ERROR ..................................................................................................... 11 17、WNMS连接网元告警 ................................................................................................... 11 第三部分监控预处理部分 ......................................................................................................... 12

1、AP DIAGNOSTIC FAULT ............................................................................................... 12 2、AP PROCESS STOPPED ................................................................................................. 12 3、AP SYSTEM ANALYSIS ................................................................................................. 13 4、AP FILE PROCESSING FAULT ...................................................................................... 15 5、AP SYSTEM CLOCK NOT SYNCHRONIZED ............................................................. 16 6、ANALYSIS DATA FAULT ............................................................................................... 17 7、AUDIT LOG DEACTIVATED ......................................................................................... 19 8、AUDIT FUNCTION THRESHOLD SUPERVISION ...................................................... 19 9、BLOCKING SUPERVISION ........................................................................................... 20 10、BLOCKING SUPERVISION OF DEVICE .................................................................... 20 11、CCITT7 SIGNALLING LINK FAILURE ...................................................................... 21 12、CCITT7 LINK SET SUPERVISION .............................................................................. 22 13、CCITT7 DESTINATION INACCESSIBLE ................................................................... 23 14、CONTINUITY CHECK FAILURE ................................................................................ 23 15、COMMAND LOG BLOCKED ...................................................................................... 24 16、COMMAND LOG OUTPUT ERROR ........................................................................... 24 17、CP FAULT ....................................................................................................................... 25 18、CHARGING DESTINATION FAULT ........................................................................... 25

19、DIGITAL PATH FAULT SUPERVISION ....................................................................... 26 20、DIGITAL PATH UNAVAILABLE STATE FAULT ........................................................ 27 21、DISTRIBUTED GROUP SWITCH FAULT ............................................................. 28 22、DISTRIBUTED GROUP SWITCH CLM CONTROL/ GROUP SWITCH CLM CONTROL .............................................................................................................................. 29 23、EM FAULT ..................................................................................................................... 30 24、IO-FAULT FOR TRAFFIC DISPERSION MEASUREMENT ...................................... 30 25、IO STORAGE SPACE WARNING ................................................................................ 31 26、M3UA DESTINATION INACCESSIBLE ..................................................................... 31 27、MT ROAMING AND HANDOVER NUMBER, ALLOCATION, SUPERVISION ..... 32 28、NETWORK SYNCHRONIZATION FAULT ................................................................. 33 29、RP FAULT ....................................................................................................................... 33 30、SEMIPERMANENT CONNECTION FAULT ............................................................... 34 31、SIZE ALTERATION OF DATA FILES FAULT ............................................................. 35 32、SIZE ALTERATION OF DATA FILES SIZE CHANGE REQUIRED .......................... 35 33、SIZE ALTERATION OF DATA FILES AUTOMATIC SIZE ALTERATION PASSIVE ................................................................................................................................................ 36 34、SWITCHING NETWORK TERMINAL FAULT ........................................................... 36 35、SYNCHRONOUS DIGITAL PATH FAULT SUPERVISION ........................................ 38 36、SYNCHRONOUS DIGITAL PATH UNAVAILABLE STATE FAULT ......................... 39 37、VOLUME LIMIT EXCEEDED ...................................................................................... 39 第四部分关于MGW退服故障处理的操作指引 ..................................................................... 40

1、查看MGW状态： .......................................................................................................... 40 2、查看告警： ....................................................................................................................... 40 3、PING 操作： ................................................................................................................... 41

第一部分监控派单说明

随着核心网智能自动派单的全面启动运行，监控值班人员在接收到智能自动派单系统派发故障工单时，可参考以下说明：

1、可以自处理的告警（详见第二部分），请监控值班人员参考操作手册进行自主处理或派市公司处理，无需派单核心网络维护室。

2、一般故障（详见第三部分），请监控值班人员在接到智能自动派单，包括集团公司派的一般故障工单后，可参考操作手册进行预处理，如预处理不成功或预处理后过一段时间告警重新出现，请派往单核心室做后续处理，并在工单上简要说明预处理情况及输出结果，以便专业室处理人可更好地了解故障处理过程的情况，提高故障工单的处理效率。

3、紧急故障和严重故障，如媒体网关退服，系统限呼、计费拥塞、系统重启/RELOAD并影响业务的故障，请派单并电话通知核心网室值班人员（13500004575），也可先打电话再派单。

4、管理职责不在核心网室的相关告警（如涉及HLR用户数据、传输电路、关口局的IP专线故障和BSC侧告警等），请直接派市公司处理。

5、因工程调试、割接和软件升级、补丁以及夜间因处理故障过程产生和告警等原因引起的告警，以EOMS公布信息为准进行匹配，均无需派单，请监控值班人员督促各项目实施操作人员及厂家操作操作人员，在确认上述操作所产生的告警消除后，方可同意操作人员离场。

6、为避免重复派单，对于一般故障工单，建议只采用自动派单，避免自动派单和手动派单同时进行。

7、本手册的故障处理指引也适应集团工单有关国际局的故障处理，请参照此手册处理集团工单的国际局的故障处理；

8、本手册的故障处理指引是针对系统经常发生的一般故障，并非覆盖系统中所有的故障；

第二部分监控自处理部分

对于本部分所列告警，在没有伴随其它相关严重告警并且不是反复出现时，监控值班人员可参考以下处理步骤进行自主处理，无需派单核心网络维护室。

1、 AP PROCESS REINITIATED

告警信息(举例)：

A2/APZ \ 1447 AP PROCESS REINITIATED

AP APNAME NODE NODENAME 1 GZSM7B1AP1C A GZSM7B1AP1A RESOURCE GROUP PROCESS Disk Group stsprov CAUSE DATE TIME

告警产生原因：APG中某个进程出现问题系统自动对其进行重启动。对于AP1告警处理方法：

1、

2、C:\\> cluster res 检查所有process是否都为online.

3、C:\\> cluster res|findstr –ive online检查存在OFFLINE的进程；

4、C：/>cluster res resource_name /on /wait对存在OFFLINE的进程进行重启 5、C:\\> alist 得到该告警的Alarm Identifier(格式为xxxx:x，本例为6023:1) 6、C:\\> acease 6023:1 删除告警(有时告警会过一两分钟才消除) 7、C:\\> alist 确认告警消除；对于AP2告警处理方法： 1、

2、C:\\> ipconfig 检查AP1的IP地址（ETHERNET ADAPTER PUBLIC的IP 地址）

3、打开SUN TOOLS/TERMIAL。。。窗口 4、C:\\> telnet AP1

5、C:\\> telnet AP2（NODE_A:192.168.170.3;NODE_B:192.168.170.4） 6、C:\\> cluster res|findstr –ive online检查存在OFFLINE的进程；

7、C：/>cluster res resource_name /on /wait对存在OFFLINE的进程进行重启 8、C:\\> alist 得到该告警的Alarm Identifier(格式为xxxx:x，本例为6023:1) 9、C:\\> acease 6023:1 删除告警(有时告警会过一两分钟才消除) 10、C:\\> alist 确认告警消除；

2、AP REBOOT

告警信息(举例)：

A2/APZ \ 0840 AP REBOOT

AP APNAME NODE NODENAME 1 HDG3B1AP1C A HDG3B1AP1A CAUSE DATE TIME Fault initiated 20070731 084035 END

告警产生原因：APG中某个node出现问题或可能存在问题，系统自动对其进行重启动或是人工对某个NODE进行重新启动。

告警处理方法:(与告警1的处理过程基本相同)

1、 cluster node 检查NODE 的状态(两个node都应为up)

3、C:\\> cluster res 检查所有process是否都为online（如有offline参见2.1处理）. 4、C:\\> alist 得到该告警的Alarm Identifier

5、C:\\> acease xxxx:x 删除告警(有时告警会过一两分钟才消除) 6、C:\\> alist 确认告警消除；

说明：对于AP2发生类似的告警，采用二次TELNET的方法登陆到告警的NODE上：（1）、打开OSS中的SUN TOOLS中的TERMAL。。窗口，用TELNET XXX登陆到AP1；（2）、在登陆到AP1的基础上，再次用TELNET 192.168.170.3(对应AP2的NODE_A),192.168.170.4(对应AP2的NODE_B); （3）、参考AP1的处理方法；

3、ILLEGAL LOGON ATTEMPTS

告警信息(举例)：

A2/APZ \ 1513 ILLEGAL LOGON ATTEMPTS

AP APNAME NODE NODENAME 1 GZG33MSCAP1C B GZG33MSCAP1B SECURITY VIOLATION ATTEMPT

告警产生原因：在短时间内，连续三次输错APG登陆密码。

告警处理方法:(与告警1的处理过程基本相同)

1、 cluster res 检查所有process都为online状态.

3、C:\\> alist 得到该告警的Alarm Identifier(格式为xxxx:x，本例为8799:0) 4、C:\\> acease 8799:0 删除告警(有时告警会过一两分钟才消除) 5、C:\\> alist

4、AP FAULT (GENERAL ERROR)

告警信息(举例)：

A2/APZ \ 1747 AP FAULT

AP APNAME NODE NODENAME 1 GZG24MAP1C A GZG24MAP1A PROBLEM

GENERAL ERROR END

告警产生原因：APG系统运行过程中出现的一般性告警信息。告警处理方法:(与告警1的处理过程基本相同)

1、 cluster res 检查所有process都为online状态.

3、C:\\> alist 得到该告警的Alarm Identifier(格式为xxxx:x，本例为8799:0) 4、C:\\> acease 8799:0 删除告警(有时告警会过一两分钟才消除) 5、如上一步无法执行时用C:\\> acease –o 8799:0 6、告警反复出现请派单。

5、ALI FAULT

告警信息(举例)：

*** ALARM 153 A2/APZ \

ALI FAULT

MAG PCB ADDINFO ALI-0 - NO CONTACT END

告警分析：

产生此告警的原因是由于直接终端AT-1被闭塞或吊死引起的。

告警处理：

1．确认没有其它相关告警

若有其它的相关告警，如IO BLOCKED、PORT BLOCKED、LINE UNIT BLOCKED告警，须先处理相关告警后再处理“ALI FAULT”告警。

2、闭解ALI

查看告警，如果还不能消除告警的话就进行下一步骤； 3、闭解ALI的PORT(通常是AT-1)

:ILNPP:PORT=ALL; :ILBLI:PORT=1-1-1-2; :ILBLE:PORT=1-1-1-2; :END;

4、检查SPG的两个NODE的状态均为WO： INMCT：SPG=0； IMCSP； END；

5、若上述处理仍不能解决故障，则需要对SPG=0的执行NODE做一个小启动，相当于对SPG=0做倒边，此操作无风险，无须等到凌晨话务较低时做重启：

SYRSI：SPG=0，NODE=EX_NODE,RANK=SMALL;

6、BACKUP INFORMATION FAULT

告警信息(举例)：

*** ALARM 073 A1/APZ \ BACKUP INFORMATION FAULT FAULT CODE 41 END

告警产生原因：系统备份出错或有关信息异常，常见Fault Code有34、13、23、41、58等。告警处理方法：

1、对于Fault Code 34，可以激活自动DUMP:

对于其它Fault Code：人工做一次系统备份(对于端局在实施备份的要求，在话务闲时，用PLLDP查询，CP负荷在40%以下；对于HLR的系统备份，安排在凌晨进行，避免影响BOSS侧在送修改用户数据时不成功的问题)；

流程如下：

7、CP STATE NOT NORMAL

告警信息(举例)：

*** ALARM 411 O1/APZ \:CP STATE NOT NORMAL :END

告警分析：

产生CP40/50的CP-SB状态不正常的原因是由于修改CP的相关参数，如扩/缩SAE或激活软件补丁引起的。告警处理： 1、 DPWSP；

2、对系统做一个备份：(对于端局的备份要求，话务闲时，用PLLDP查询，负荷在40%以下，对于HLR的系统备份，安排在凌晨进行)； SYBUE；

SYBUP：FILE； SYTUC； SYBUI； 3、DPWSP；

4、若对CP完成备份后，CP还不正常的，需要对CP做一个并边处理： DPPAI；

8、DIGITAL PATH QUALITY SUPERVISION

告警信息(举例)：

*** ALARM 181 A2/APT \ DIGITAL PATH QUALITY SUPERVISION SESR

DIP DIPPART SESL QSV SECTION DATE TIME 1369UPE 15 15 070312 090817 END

告警产生原因：传输电路质量告警（存在误码问题），如ES、SF、DF等。告警处理方法：

1、

3、TPQSR:SDIP=xxxx,DEGR; 清除ET155质量告警；

4、在手动清除后，ES、ES2、SES还会产生，说明传输质量很差，需要派单给传送室进行彻底的处理。

9、DISTURBANCE SUPERVISION OF TRUNK ROUTES

告警信息(举例)：

*** ALARM 507 A2/APT \ DISTURBANCE SUPERVISION OF TRUNK ROUTES R ADL FSGM1O 20 END

告警产生原因：路由设备受到干扰(如电磁干扰等)引起。告警处理过程：

1、

2、

3、告警反复出现请转派单给专业室协助处理。

10、DISTURBANCE SUPERVISION OF INDIVIDUAL DEVICES

告警信息(举例)：

*** ALARM 0956 A2/APT \:DISTURBANCE SUPERVISION OF INDIVIDUAL DEVICES :R

:SGAL2O :SGAL2I :END

告警产生原因：路由上的个别设备受到干扰(如电磁干扰等)引起的告警。告警处理过程：

1、DUIAR:R=SGAL2O&SGAL2I； 2、查看告警：ALLIP；

3、告警反复出现请转派单给专业室协助处理。

11、EVENT REPORTING THRESHOLD REACHED

告警信息(举例)：

*** ALARM 0086 A3/APT \:EVENT REPORTING THRESHOLD REACHED :ENUM THRESHOLD LEVEL :115 TH 10 :END

告警分析：

产生此告警的原因是由于该局的某一局向的信令异常事件记录达到设定的范围值，如某一局向在做相关的链路调整而引起的事件记录，可作为排查故障参考，目前智能派单系统只针对MSC-SEVER局进行派单操作，其它类型的交换端局不做派单处理。告警处理：

1、可用指令 ERESP：ENUM=XXX；查看相关告警；

2、可用指令EREAR:ENUM=XXXX; 释放此告警

3、在清除告警的5分钟后，用指令 ERESP：ENUM=XXX；系统还出现同一告警，可派单给专业室做后续处理；

12、HLR SUBSCRIBERS WITH INCOMPATIBLE DATA SUPERVISION

告警信息(举例)：

*** ALARM 012 A2/APT \

HLR SUBSCRIBERS WITH INCOMPATIBLE DATA SUPERVISION INCDAT 159 END

告警产生原因：主备HLR中用户数据不一致，不一致数量达到告警门限值(100)，即产生告警。

告警处理方法：根据主用HLR用户数据更新备用HLR用户数据 1、

13、SEIZURE QUALITY SUPERVISION

告警信息(举例)：

*** ALARM 246 A2/APT \ SEIZURE QUALITY SUPERVISION R

SDD1O END

告警产生原因：交换局的话务路由上设备占用异常。告警处理方法： 1、

2、

14、SEIZURE SUPERVISION OF DEVICES IN BSC

告警信息(举例)：

*** ALARM 886 A3/APT \ SEIZURE SUPERVISION OF DEVICES IN BSC DETY

RALT END

告警产生原因：BSC到MSC的A接口路由上的设备占用异常。告警处理方法： 1、

2、

15、SIGNALLING FAULT SUPERVISION

告警信息(举例)：

*** ALARM 0853 A2/APT \:SIGNALLING FAULT SUPERVISION :END

告警分析：

产生此告警的原因：是路由上的设备由于存在两个交换局之间的信令配合问题，需要双方交换局协调定位、处理。告警处理：

1、FAIAP:R=ALL; 查询路由上有信令故障的DEVICE.

按照路由上DEVICE的状态为MBL,CBL,LIBL,SEAL对设备进行闭解等操作。

2、如果设备状态是MBL（注：人为关闭）的状态，确认后用指令解闭MBL状态的中继设备。

BLODE：DEV＝XXXX-XXXX；解闭中继设备。

3、若设备状态是ABL,需要进一步判断故障与传输电路是否相关

EXDEP：DEV= XXX-XXXX；根据DEV查找设备对应的SNT。 DTSTP：DIP=XXX；查看传输电路状态。

如果DIP为ABL，说明传输电路故障，需要派单传输协助处理。若DIP为WO，对中继设备进行闭解

4、如果设备状态为AB/S，且分布无明显规律，并出现SEIZURE QUALITY SUPERVISON的关联告警，可判断为设备的AB与路由设备占用时长监测功能相关。此功能会将占用时长过短的设备自动AB。转派专业室处理。

5、如果是LIBL（注：对端关闭）的状态，即由对端局闭塞引起的，检查对端局相应路由上中继设备的状态。如果对端局是其他机型或其他运营商设备，与对端局联系处理。 6、如果是CBL（控制设备闭塞）,则说明控制中继设备的RP或EM故障，按照RP FAULT/EM FAULT的处理流程进行处理。

7、如果设备状态SEAL，所在传输正常，则需要判断故障点在本端还是对端。需要联系对端，查看对端显示的设备状态与本端是否一致。并在本端对设备进行闭解、重新激活测试。

BLODI：DEV=XXX-X；闭掉单个设备 EXDAE：DEV=XXX-X；去激活设备 EXDAI：DEV=XXX-X；重新激活设备 BLODE：DEV=XXX-X；解闭设备

上述操作无效，则需派单给专业室做进一步的处理；

16、SOFTWARE ERROR

告警信息(举例)：

*** ALARM 723 A2/APZ \ SOFTWARE ERROR END

*** ALARM 376 A3/APZ \ APPLICATION DETECTED SOFTWARE ERROR END

告警产生原因：软件运行出错，有系统软件和应用软件。交换局任何时候都有大量的软件在运行，偶尔一两个运行出错很正常，在没有伴随SAE拥塞等告警时，可按下面方法处理。告警处理方法：

1、

或SYRAE:RECTYPE=APPLERR; 用于application detected software error告警 3、

17、WNMS连接网元告警

告警信息(举例)：

*** ALARM 8881 A1/APT \:网元: GZS29 (oss_ip: 139.1.1.1) :上次失败时间:

:本次失败时间: 2008-07-17 19:06:56 :故障原因: EAW网元连接失败! :END

告警产生原因：此故障视断连的网元的个数来判断，有可能是网元侧的问题，也有可能是网管的问题。

告警分析：一般是话务网管通过定时去连接网元，目前是20分钟连接网元并下发命令进行数据采集，一当话务网管无法连接网元就产生告警，但是话务网管（WNMS）是先连接到OSS，OSS再连接到网元（NE）。产生网元断连告警的原因：告警处理：（1）、对于同一个市公司中同时有1至2个网元出现网元断连时，可直接在OSS上的CHA手动连接网元，以确认是否真的断连，能正常连接网元，且告警还存在，先观察30分钟后，告警还没消失，则派单给网管支撑室；如果在OSS上也无法连接网元，可能是网元侧接口故障，则派单给核心室处理；对于对于是HLR网元断连时，除派工单外，同时电话通知核心室值班人员；（2）对于同一个市公司中同时有3个网元出现网元断连时，可直接派单给网管支撑室确认

处理，同时电话通知市公司启用本地监控。

第三部分监控预处理部分

出现本部分所列告警，请监控值班人员参考下述方法进行预处理，如预处理不能解决或告警虽可消除但反复出现请派单核心网室处理。

1、AP DIAGNOSTIC FAULT

告警信息(举例)：

*** ALARM 833 A2/APZ \ 1652 :AP DIAGNOSTIC FAULT

:AP APNAME NODE NODENAME : 1 SZSS34AP1C B SZSS34AP1B :ERROR IN ACS_USA_SyslogAnalyser :END

告警产生原因：一般APG系统本身存在某些硬件或软件故障，引起USA频繁地记录EVENT LOG，从而提示维护人员去分析旧的EVENT LOG；告警处理：（1）、APLOC；（2）、ALIST检查是否其它有硬件告警存在，如磁盘镜像问题存在的，可派单给核心室协助处理；对于举例的告警，通常会列出告警8714:X，用指令ACEASE即可；或重启进程ACS_USA_SyslogAnalyser：cluster res resource_name /on /wait 启动offline的资源后清除告警。

如果有查看有告警号为8701和告警参考数据为：C:\\ACS\\logs\\USA\%usa.temp. I/O error : Missing parameter，则进行如下的删除文件：（3）、在ACTIVE NODE中，del C:\\ACS\\logs\\USA\%usa.tmp （4）、ACEASE 8701 （5）、在PASSIVE NODE 中，执行PRCBOOT重启PASSIVE NODE，不影响APG的工作，此操作没有时间限制；（6）、CLUSTER NODE 检查两个NODE的状态均处于UP时，对ACTIVE NODE也做PRCBOOT；（7）、检查两个NODE及RES状态：CLUSTER NODE；CLUSTER RES；（8）、ALLIP；检查告警是否消失；

2、AP PROCESS STOPPED

告警信息(举例)：

*** A2/APZ \ 1535 AP PROCESS STOPPED

AP APNAME NODE NODENAME 1 GZG33MSCAP1C B GZG33MSCAP1B

RESOURCE GROUP PROCESS Disk Group CPS_BUSRV CAUSE DATE TIME Unknown failure 20070910 153524 告警产生原因：APG中的某个进程停止工作。

告警预处理：进程所在的NODE状态正常的前提下有效。

1、 cluster node 检查两个NODE状态

3、C:\\>cluster res 检查cluster的Resource状态

4、C:\\>cluster res|findstr –ive online 列出状态异常的Resource(也可由上一步得到) 5、cluster res resource_name /on /wait 启动offline的资源,也可先停闭再启动。 (cluster res resource_name /off /wait 停闭online的资源)

6、C:\\> acease xxxx:x 删除告警(Resource Online之后告警不会立即自动消除) (Alarm Identifier xxxx:x 由C:\\>alist 列出) 7、此操作也适应AP2及HLR；

3、AP SYSTEM ANALYSIS

告警信息(举例一)：

*** ALARM 937 A2/IO_DEV \ 1447 :AP SYSTEM ANALYSIS

:AP APNAME NODE NODENAME : 1 SDMSC5AP1C A SDMSC5AP1A

:OBJECT COUNTER INSTANCE LIMIT VALUE :Memory Available Bytes <104857600 91574272 :END

告警产生原因及原理分析：

一、对于内存告警，通常是软件问题，由于某些进程长时间占有内存而没有释放，如控制话统的进程STSPROV、STSCONV、STSOPCF，而占用了虚拟内存。可以采取重启进程的方法来恢复，但是对于AP2告警都需要在晚上闲时处理。告警处理方法（一）：

1) APLOC; 进入AP模式下

2) CLUSTER RES 检查所有process是否都为online 3) CLUSTER RES STSMAIN /OFF 停掉STAMAIN进程

4) CLUSTER RES |FINDSTR –IVE ONLINE 查看有哪些进程是OFFLINE(正常情况应该是有STSMAIN、STSPROV、STSCONV、STSOPCF四个进程是OFFLINE的) 5) CLUSTER RES STSMAIN /ON/WAIT 启动STAMAIN进程

6) CLUSTER RES |FINDSTR –IVE ONLINE 查看有哪些进程是OFFLINE（STSPROV、STSCONV、STSOPCF四个进程是OFFLINE的）

7) CLUSTER RES STSMAIN /ON/WAIT 启动STSMAIN进程

CLUSTER RES STSPROV /ON/WAIT 启动STSPROV进程 CLUSTER RES STSCONV /ON/WAIT 启动STSCONV进程 CLUSTER RES STSOPCF /ON/WAIT 启动STSOPCF进程

8) CLUSTER RES |FINDSTR –IVE ONLINE 查看有哪些进程是OFFLINE（正常情况没有进程OFFLINE，如果有OFFLINE的进程则参照上一步启动该进程） 9) CLUSTER RES 检查所有process是否都为online 10) Exit

11) ALLIP:ACL=; 确认告警是否消除。告警处理方法（二）：

上述操作后，几个进程的状态又没有恢复是ONLINE状态，可以采用对APG进行倒边的办法（过程需要5分钟左右），但为了保证APG的正常工作，在对APG进行倒边前先检查APG的备用边（PASSIVE NODE）能正常完成重启，检验方式是：telnet到PASSIVE NODE，执行PRCBOOT指令重启备用边，重启完成后检查PASSIVE NODE的状态时候是否为up，所有process的状态是否都为online。如果一切正常，则可以在ACTIVE NODE执行PRCBOOT指令进行倒边，倒边后检查两个NODE是否都正常，检查告警是否已经消除。 1）、APLOC； 2）、telnet IP（PASSIVE NODE） 3）、PRCBOOT 4）、CLUSTER NODE检查两个NODE都为up状态 5）、CLUSTER RES检查所有process都为online 6）、telnet IP（ACTIVE NODE） 7）、PRCBOOT 8）、CLUSTER NODE检查两个NODE都为up状态 9）、CLUSTER RES 检查所有process是否都为online 10）、Exit 11）、ALLIP:ACL=; 确认告警是否消除。

告警信息(举例二)：

*** ALARM 644 A1/IO_DEV \ 0218 :AP SYSTEM ANALYSIS

:AP APNAME NODE NODENAME : 1 SZHLR2AP1C A SZHLR2AP1A

:OBJECT COUNTER INSTANCE LIMIT VALUE :LogicalDisk % Free Space L : <4 3.83 :END

告警产生原因及原理分析：一、产生此类告警的原因是由于某个磁盘的空间达到预设的门限值时而产生。

APG40的硬盘有两类。一类是系统盘，每边（A边和B边）各一块，分为四个分区 C: D: E: F:。另一类是数据盘，是三对硬盘作RAID1镜像。只有执行侧（ACTIVE）可以接入数据盘。数据盘的分区分为J: K: L: M: G: Q: Y: R: S: 。

APG40有一个内部监控磁盘空间使用的程序，根据目前的缺省配置，当所剩磁盘空间小于

总分配空间的16％时，即会生成A2级告警。而小于4％时，即会产生A1告警。当剩余空间重新回到6％时，A1告警消除。而剩余空间回到18％时，A2告警消除。这个告警门限的设定没有特别的原因而且不对某一个磁盘分区有针对性。

随着APG40软件版本的不断升级，正常的系统文件对C:盘（共2GB）的占用会不断增加，从而导致会比较频繁地出现C:盘使用空间不足的告警。就目前软件版本的情况，需定期检查和删除一些不必要的系统日志文件，应该可以使C:盘的剩余可使用空间控制在360MB到400MB之间。从而可以达到消除告警的威胁。

从日常告警的频次统计，C: 盘，K:盘和HLR的L:盘会经常有空间告警现象的出现。告警告警处理方法： 1）、对于C: 盘，一般只确认和删除一些临时的文件，如目录为C：/TEMP和C：/TEST； 2）、对于K:盘，一般是删除旧的ALOG文件；如K：/ACS/LOGS/ALOG/LOGFILE/下比较旧的ALOG文件（一个月前的文件）； 3）、对于L:盘，一般是删除旧的CP 备件文件，一般情况下，一个局只保存4个RELFSWn的文件如RELFSW0、RELFSW1、RELFESW2、RELFSW99，如其它备份文件可删除； DEL RELFSWn

4、AP FILE PROCESSING FAULT

告警信息(举例)：

*** ALARM 102 A2/IO_DEV \:AP FILE PROCESSING FAULT

:AP APNAME NODE NODENAME : 1 PYG6MAP1C A PYG6MAP1A :CAUSE

:FILE TRANSFER FAILED :TRANSFER QUEUE :ALOG

:DESTINATION SET :OSSDESTALOG :END

告警产生原因及原理分析：

统计文件、计费文件、ALOG文件（事件记录文件）的传送方式不同，其中统计文件、计费文件是被动地传，不同的是计费文件是由计费中心通过FTP方式来取，统计文件则是在生成后通知OSS，OSS再通过FTP方式来取；ALOG文件是主动传，直接FTP到OSS。

ALOG文件传送失败，APG40系统中的文件无法传到远端计算机；一般有三种情况：1、网络临时故障（此类情况最多）；2、本地设置和定义的参数不正确；3、对端的参数设置及网络问题。

此类告警通常在OSS因故障连不上机后一般都会出现；在网络故障恢复后，通常使用指令人工重传文件后告警即会消除；最近广州该故障告警比较多，经咨询是广州的OSS升级引起的，通常大面积的出现该告警一般都是网管侧的问题。

生成的ALOG文件先放入K:\\ACS\\LOGS\\ALOG\\LOGFILE（afpls -l ALOG可以查看其实际路径的源目录），ALOG文件满1M后自动传送到OSS对应目录，指令“afpls –ls ALOG”查看文件的传送情况， DELETE状态是已经成功传送并10080分钟后删除了（TIMER表示即将在多少分钟后删除）；FAILED状态是传送失败。告警发生后，不会自动消除，需要通过人工手动传送，alogfind –s afpfti可以查看人工重传的记录。

告警处理方法：

1) APLOC; 进入AP模式下

2) afpls –ls ALOG 查看ALOG文件传送情况，状态为failed的为传送失败文件。 3) afpfti –f ALOG 将传送失败的ALOG文件重传一次，传送成功故障将会消除。

4) afpls –ls alog 查看状态（STATUS）由FAILED变为SEND或READY，表示已经开始

重传

5) alist 需要等待几分钟后，确认文件是否传送成功告警消失。 6) exit

7) ALLIP:ACL=; 确认告警是否消除。

如果手工传送失败，可以尝试以下操作并派单专业室或地市公司处理：

8) cdhver OSSDESTALOG 看目的点状态，结果显示是否STATUS OK。 9) cdhls -l OSSDESTALOG 查看此路径的所有传输参数是否正确，同时可获得对应的对应

的IP。

确认本地交换机的设置没有问题，怀疑是到OSS的网络不通 10) ping x.x.x.x 检查网络是否通

案例：ping 对端的IP, 显示网络路径完全正常；后来注意到A3级的一个告警，是由于刚才那个A2级告警AP FILE PROCESSING FAULT引起的：

DATA OUTPUT, AP COMMON DESTINATION HANDLING, DESTINATION FAULT DESTINATION OSSDESTALOG CAUSE

WRITE FAILURE Problem Data

The connection to the remote host lost or write access denied

再分析上面的告警，确认了是因为AP 文件没有写到OSS的权限。综上分析可以确定是对端网管的设置问题，导致ALOG文件无法正常传送。所以应及时联系对端人员(网管组)协助处理。

备注：1、在检查本端问题时，可以尝试删除ALOG队列、重新定义ALOG队列，再用指令“cdhver OSSDESTALOG”检查状态是否OK，但是本端通常是没有问题的，此步操作不列出，不建议操作。

2、上述操作也包括AP2

5、AP SYSTEM CLOCK NOT SYNCHRONIZED

告警信息(举例)：

*** ALARM 263 A2/ IO_DEV \:AP SYSTEM CLOCK NOT SYNCHRONIZED

:AP APNAME NODE NODENAME : 1 MMSM4B1AP1C A MMSM4B1AP1A :REASON

:DIFFERENCE BETWEEN CP AND AP TIME EXCEEDS 600 S. :END

告警产生原因：

在APG出现此类告警的原因，一般是由于AP 系统同CP之间的时间不同步，两个系统之间的差值大于10分钟引起的，需要对AP的时间进行手动较对。

告警预处理：

1、检查CP 的时间

CACLP；

2、telnet到该网元，检查APG的时间, 确认与CP时间差值是否过大；

date /t time /t

3、若确认是时间相差600秒，则登陆到网元的passive边，修改APG时间与CP 一致

date （修改的日期） time （修改的时间）

4、在PASSIVE 边做完时间修改后，做一个PRCBOOT；

5、检查PASSIVE边状态为UP后，对ACTIVE 边倒边，使得ACTIVE边变为passive边，再进行一次时间修改，使得时间与CP同步

prcboot

date （修改的日期） time （修改的时间） 6、检查、确认告警是否已消除

Allip：acl=；

6、ANALYSIS DATA FAULT

告警信息(举例)：

*** ALARM 695 A2/APT \ 1125 :ANALYSIS DATA FAULT

:FCODE REASON

:4 LOOP IN ROUTE ANALYSIS AT RESTART OF ANALYSIS

:BNBR BO BO1 :8613900301769 58 58

:BNBC BNT BNT1 :13900301769 1 4

:BSNB NAPIB NAPIB1 : 1 1

:ANBR AO AO1 :13922325121 1 1

:ASNB ANT ANT1 : 4 4

: NAPIA NAPIA1 : 1 1 :RC RO INCROUTE OUTROUTE :372 1 CTPPSI GZSA1AO :REROUTING TONE EOS EO :YES 1 1658

:TEST TCL EA PR LOD : 8 0 0 0

:ISAT OSAT AL TMR WSIG :0 0 0 0 :NA NRA RA ISTI ST :1 0 0 0

:MST PLMN IWE SW ISK-TYPE :1 0 0 0

:TN ODR IGWT NS NAR :0 0 0 0 0 :END

告警分析：产生此告警一般是由于做测试或系统发生重启后, 路由重选时所有备用路由电路拥塞，导致产生路由循环。

告警处理:

1) 对于此类告警,可参考ALEX中的OPI进行预处理，首先查看其中的FCODE和REASON，按照FC的不同，处理流程也不同。以下根据FC出现频率,由高到低叙述处理流程。 ? FC=4,REASON=” (loop in routing analysis at restart of analysis) ? 路由重选时所有备用路由电路拥塞，导致产生路由循环，可用命令ANFAR消除告警，若告警重复出现，则派单给资源配置室检查有无数据问题，数据无误由资源配置室转核心室检查是否硬件问题导致全局电路不可用或电路资源不足，需申请电路资源。 ? FC=3 ,REASON=”(loop in B-Number analysis with analysis restart) ? B号码分析循环，可直接派单给资源配置室处理 ? FC=5 ,REASON=”(loop in EOS analysis at restart of analysis) ? 用命令ANFAR消除告警，若告警重复出现-，则派单给资源配置室处理。 ? 对于其他FC的，可用命令清除告警后，若告警重复出现，再派单给核心室处理。

7、AUDIT LOG DEACTIVATED

告警信息(举例)：无

告警产生原因：主要是由于APG进行软件升级或是APG进行硬件更换的过程中，人工关闭ALOG功能；告警预处理：

1、 ALOGACT激活即可； 2、 ALOGDEACT去激活 3、 ALLIP；

8、AUDIT FUNCTION THRESHOLD SUPERVISION

告警信息(举例)：

*** ALARM 0098 A2/APZ \:AUDIT FUNCTION THRESHOLD SUPERVISION :TEST 101 :END

*** ALARM 0098 A2/APZ \:AUDIT FUNCTION THRESHOLD SUPERVISION :TEST 102 :END

*** ALARM 0098 A2/APZ \:AUDIT FUNCTION THRESHOLD SUPERVISION :TEST 104 :END

*** ALARM 0098 A2/APZ \:AUDIT FUNCTION THRESHOLD SUPERVISION :TEST 110 :END

告警产生原因：

此告警是PS、RS、DS以及有定义监视的SAE占用已达到事先定义的告警门限；

告警预处理：

对于TEST 101 是指PS空间告警；TEST 102 是RS空间告警；TEST 104 是指DS空间告警；TEST 110 是指SAE空间告警；这几种告警的处理方法、思路是一样的，下面以TEST 110的告警进行说明：

1、查询是哪一个SAE引起告警的； AFTSP：TEST=110，LOG；

2、按扩SAE的步骤扩相应的SAE；（对于TEST XX提示SAE告警，用SAALI无效

果）

SAAII：SAE=XX，NI=YY； 3、检查告警情况： ALLIP；

4、对于CP40/50来说，做完扩SAE后，会引起CP STATE NOT NORMAL告警，需要在话务闲时做一次人工备份。

9、BLOCKING SUPERVISION

告警信息(举例)：

*** ALARM 684 A3/APT \ BLOCKING SUPERVISION

R LVB NDV BLO ZSD2O 55 1114 55 END

*** ALARM 527 A1/APT \ BLOCKING SUPERVISION

R LVB NDV BLO 1MAIN0 32 64 64 END

告警产生原因：

中继闭塞监测告警，当路由中设备闭塞数达到告警门限值时产生该告警。

告警预处理：

1、

2、

6、

一般说来，LIBL为对端故障，需要在对端局进行闭解。

8、如DIP或SNT状态异常，需要先处理DIP或SNT(请参加DIP和SNT处理流程)。

10、BLOCKING SUPERVISION OF DEVICE

告警信息(举例)：

*** ALARM 0141 A3/APT \:BLOCKING SUPERVISION OF DEVICE

:DETY LVB NDV BLO :RTTGD 2403 8364 2436 :END

告警产生原因：

此告警主要针对BSC，该告警的原因很多： 1一般是由于传输中断引起大量的设备不可用； 2、SNT及所控的RP故障引起； 3、工程调测、网络割接引起的；

告警预处理：

1、用命令ALLIP；查看告警是否存在；

2、用命令STBSP：DETY= RTTGD；可查对应闭塞的设备； 3、用命令RADEP：DEV=RTTGD-XX；查看对应的SNT； 4、NTSTP：SNT=XX； 5、NTBLI：SNT=XX； 6、NTTEI：SNT=XX； 7、NTBLE：SNT=XX； 8、BLODE：DEV=XX； 9、STDEP：DEV=XX；

10、闭解后，设备仍不能正常状态，请派单给市公司；如果设备状态为MBL，不需要进行预处理。

11、CCITT7 SIGNALLING LINK FAILURE

告警信息(举例)：

*** ALARM 827 A1/APT \ CCITT7 SIGNALLING LINK FAILURE LS SPID SLC ST

2-19-250-84 FSG08 0 C7ST2-3 SDL

C7PCDD-5,UPD-4065/TS-1 FCODE INFO REASON

104 H'FF SIN, SIE, SIO OR SIOS RECEIVED END

*** ALARM 903 A1/APT \ CCITT7 SIGNALLING LINK FAILURE LS SPID SLC ST

2-19-252-3 JMMGA1 1 C7ST2C-55 SDL

UPD-3809/TS-1

FCODE INFO REASON

200 H'0 EXCESSIVE ERROR RATE DURING ALIGNMENT END

告警产生原因：

引起信令链路告警的原因很多，是信令终端软件出错或硬件故障，或是传输问题，或是由与

信令终端相关的EM、SNT等故障引起，也可以是对端问题。传输故障引起的情况较多。告警预处理：

1、查看并闭解信令链路

2、如上述处理无效，检查信令链对应的传输是否正常

3、如为传输问题则按传输故障流程处理，如传输正常，则可能是RP(EM)、信令终端本身或对端等存在问题，一般需要更换硬件，请派单给核心室做进一步分析处理。 4、信令链路常见的有以下的FCODE和对应的处理方法和故障原因： FCODE 100 108 200 204 206 207 FAULTY 5 FAULTY 6 故障原因传输误码率过高传输被环路传输出现严重误码块接收不到对端信令消息 T2中断 T3中断 RP被闭塞 RP 故障处理方法检查传输线路部分或ETC板接头放直传输即可检查传输线路部分检查对端的信令故障可能是对端比塞或未做数据或传输终端引起传输可能是收发反或交叉线检查RP故障或解开RP 修复RP或换信令终端 12、CCITT7 LINK SET SUPERVISION

告警信息(举例)：

*** ALARM 649 A1/APT \:CCITT7 LINK SET SUPERVISION :LS SPID NACTSL :3-10328 ZCG4 1 :END

告警产生原因：

引起信令链路组告警的原因很多，一般可以是控制信令终端的RP/RP BUS出错或故障，也可以是信令链所在的传输中断，或是对端局问题。传输故障引起的情况较多。告警预处理：

1. 用指令ALLIP;查看告警是否真实存在；.

2. 使用c7ltp查看信令状态，查看信令硬件告警，是否对端人工闭塞信令； 3. 用指令C7LDP：LS=XX；

EXDEP：DEV=C7BTC-X；查看对应的DEV所在的DIP； EXDRP：DEV=C7ST2C-X；查看对应的信令终端所在的RP； DTSTP：DIP=XX； DTQUP：DIP=XX； EXRPP：RP=XX；

如果是RP/RPBUS引起的大量的信令链路故障，请立即派发重要工单到核心室处理.

13、CCITT7 DESTINATION INACCESSIBLE

告警信息(举例)：

*** ALARM 0696 A1/APT \:CCITT7 DESTINATION INACCESSIBLE :DEST SPID :2-19-250-30 DGSC13 :END

告警产生原因：

引起七号信令目的信令不可达的告警原因很多：

1、局间的传输中断引起局间信令链路的直达和转接电路全部中断； 2、对端交换机故障；

3、信令终端或和信令终端有关的RP、TSM故障； 4、目的点信令路由人工闭塞。 5、对端局是工程调测引起的；

告警预处理：

1. 用指令ALLIP;查看告警是否真实存在；.

2. 使用c7RSP：DEST=XX；查看信令路由状态，是否对端人工闭塞信令； 3、使用c7ltp查看信令状态，查看信令硬件告警，是否对端人工闭塞信令； 4、如果是局间的信令链路故障引起的，可用指令C7LDP：LS=XX； EXDEP：DEV=C7BTC-X；查看对应的DEV所在的DIP； EXDRP：DEV=C7ST2C-X；查看对应的信令终端所在的RP； DTSTP：DIP=XX；查看对应的DIP的状态；

DTQUP：DIP=XX；查看对应的DIP的传输质量； EXRPP：RP=XX；查看信令终端所在的RP的状态；

14、CONTINUITY CHECK FAILURE

告警信息(举例)：

*** ALARM 0796 A2/APT \:CONTINUITY CHECK FAILURE :DETY R

:UPDR ZJS07AO :END

告警产生原因及原理分析：当在某一条指定的路由在做连续检测不成功时，一般不影响业务；

告警告警处理方法: 1）、TCCFP：DETY=UPDR；查询测试呼叫连续失败的数据； 2）、STDEP：DEV=XX； 3）、BLODI：DEV=XX； 4）、EXDAE：DEV=XX； 5）、EXDAI：DEV=XX； 6）、TCCCI：DEV=XX；再做一次呼叫连续性测试；（此命令没有风险） 7）、BLODE：DEV=XX； 8）、ALLIP；查询告警是否已消除；

15、COMMAND LOG BLOCKED

告警信息(举例)：

*** ALARM 1984 A2/IO_DEV \ 2317 :COMMAND LOG BLOCKED :FAULT

:FAULT CODE 155

:COMMAND LOG NOT ACTIVATED :END

告警产生原因：一般是由于系统发生自动或是人工RELOAD后，导致COMMAND LOG功能被关闭；另一方面是由于人为的关闭COMMAND LOG功能；

告警处理：

1、SYCLP;查询是否激活COMMAND LOG功能； 2、SYCLI;激活；

3、查看告警是否消失：ALLIP：ACL=XX；

16、COMMAND LOG OUTPUT ERROR

告警信息(举例)：

*** ALARM 006 A2/APZ \:COMMAND LOG OUTPUT ERROR :FAULT

:FAULT CODE 65

:FILE ACCESS ERROR :END

告警产生原因：由于存放COMMAND LOG的功能块的BUFFER拥塞引起的。告警预处理：对存放COMMAND LOG的功能块进行相应的操作。 SYCLP;

SYCLI;激活（1）、检查告警存在的时间是否很长，若是很长，则执行以下命令：

SAAEP：SAE=800，BLOCK=LOGB；该NI值表示BUFFER中不能正常输出command log requests；

（2）对该SAE进行扩大后，恢复原来的大小值； SAAII：BLOCK=LOGB，SAE=800，NI=190； SAADI：BLOCK=LOBG，SAE=800，NI=180；（3）、检查告警情况： ALLIP：ACL=A2；（4）、对于CP40/50来说，做完扩SAE后，会引起CP STATE NOT NORMAL告警，需要在话务闲时做一次人工备份。

17、CP FAULT

告警信息(举例)：

*** ALARM 986 A2/APZ \ CP FAULT END

告警产生原因：

CP子系统发生硬件故障，或发现Permanent错误，或发现3个相同类型的Temporary 错误，或Temporary错误频度较高时产生CP fault告警，CP fault可以有A1、A2和A3级。告警预处理：所有CP操作(P指令除外)均需在凌晨后进行。 1、

CP40及之后型号的CP状态：

MAU SB SBSTATE RPH-A RPH-B BUA STATE NRM B WO EX/PWO SB/PWO 1(/2) 2、修理CP(夜间低话务时进行)

3、按OPI流程，只对CP修复一次，如不成功请直接派单给专业室。

18、CHARGING DESTINATION FAULT

告警信息(举例)：（1）、*** ALARM 0586 A1/IO_DEV \:CHARGING DESTINATION FAULT

:AP APNAME NODE NODENAME

: 1 MZG5MAP1C B MZG5MAP1B :TRANSFER QUEUE :RTRFILES :END （2）、*** ALARM 0274 A1/IO_DEV \:CHARGING DESTINATION FAULT

:AP APNAME NODE NODENAME : 2 GZRMSCAP2C A GZRMSCAP2A :TRANSFER QUEUE :RTRFILES :END

告警产生原因：告警是由于该MSC网元里面的RTRFILES文件没有定义DESTINATION跟DESTINATION SET而产生的

告警预处理：

只针对AP1进行预处理，AP2的故障产生的原因是一样的，但AP2是涉及计费文件的传送，可直接派单给核心室确认处理。

对于AP1的预处理，使用FORLOPP进行释放即可。 1、ALLIP：ACL=，FID=YES；查出对应的值FID=XXX； 2、SYFIP：FID=H’xxxx；

3、SYFRI：FID=H’xxxx，BLOCK=，FILENUM=H’xxxx，IND=H’xxxx；

19、DIGITAL PATH FAULT SUPERVISION

告警信息(举例)：

*** ALARM 153 A1/APT \ DIGITAL PATH FAULT SUPERVISION

DIP DIPEND FAULT SECTION HG DATE TIME 217UPET RDI 070924 154228 END

*** ALARM 103 A1/APT \ DIGITAL PATH FAULT SUPERVISION

DIP DIPEND FAULT SECTION HG DATE TIME 634C7B4 AIS 070930 101051 END

告警产生原因：电路不可用，有可能是传输的原因也可能是交换的原因。

告警预处理：先确认该DIP是否在用，如在用则根据故障情况派单(提供两个简易的故障判断方法)。

1、看该DIP是否在用

法1:如伴随有SNT告警(告警产生时间基本相同) ，可初步定位为交换侧故障，请派单核心网室处理。如仅有DIP告警，可初步定位为传输原因并有电路资料的，请派传送室处理；没有传输资料的可派往市公司处理。

法2：在传输网管中近交换侧对故障DIP进行自环，如告警消除可定位为传输故障，如告警还在，可初步定位为交换故障。 SNT/DIP的对应情况及说明： SNT ETRBLT-** ETRALT-** ETMALT-** C7ETC4-** UPET-** ETBL1-** DIP **RBLT **RALT **MALT **C7B4 **UPET **BL1 DEV RBLT-** RALT-** MALT-** C7ETC4-** UPD-** BL1-** 说明 BSC端去BTS的DIP BSC端去MSC的DIP MSC端去BSC的DIP MSC\\GW等端局至HLR\\LSTP\\HSTP等的用于TUP信令的中继 MSC去其它端局的用于isup信令的中继 BL电话的DIP 几种常见的FC码的故障：查看DIP状态，传输状态主要有WO、ABL和MBL；传输ABL时，根据相应的FC码可以初步判断故障，其FC码类型常见的有5种，FC 1＝AIS、FC 2＝LOF、FC 3＝ERATE、FC 4＝RDI 、FC 9＝LOS：

1、FC 1&2 (AIS&LOF)：属于传输中断告警，对于此类故障，应该先在传输架上向本端自环，确定我们本端没有问题后，再和对端联系，要对端也在传输架上自环，如果两边自环都没有问题，那就需要传输室在中间一段检查、处理。

2、FC 2&9 (LOF&LOS)：属于传输中断告警。先在交换机上确认SNT和传输线是好的，然后在传输架上自环本端，如果正常，则和对端联系处理，或将收发反一下，看是否能恢复。

3、FC 4 (RDI)：属于传输远端告警，表示不能够收到信号，能发送信号。这种FC码可能是由于传输头松动，只有一边接好了，另一边松掉，主要是排除本端传输的头是否有问题。

4、FC 3（ERATE）：误码高引起传输中断，要进行误码清除。如果传输误码增加很快，现场维护人员在传输架自环，观察5－10分钟，在此期间，误码没有增加则请传输室处理。如果在自环过程中误码仍然不断增加，则为本端问题，需要重新做传输头。

20、DIGITAL PATH UNAVAILABLE STATE FAULT

告警信息(举例)：

*** ALARM 0824 A3/DIP \

:DIGITAL PATH UNAVAILABLE STATE FAULT

:DIP UAS UASR UASB SECTION BLOCKING DATE TIME :295UPET 090105 203220 :END

告警产生原因：电路不可用，一般是传输的原因或是交换侧传输接口异常引起的原因。告警预处理：参考故障“DIGITAL PATH FAULT SUPERVISION”的处理方法

21、DISTRIBUTED GROUP SWITCH FAULT

告警信息(举例)：

*** ALARM 224 A2/APT \GROUP SWITCH FAULT

UNIT TCASE STATE FCODE TSM-A-37 1 BLOC 0 POSSIBLE FAULTY CARDS

UNIT SUBUNIT MAG CARD TSM-A-37 CILSU LMU-0 RHSNT-93 TRHM RPG END

*** ALARM 244 A2/APT \ DISTRIBUTED GROUP SWITCH FAULT

UNIT TCASE STATE FTYPE XM-A-0-1 1 BLOC INTERNAL POSSIBLE FAULTY BOARDS

UNIT SUBUNIT RP BOARD XM-A-0-1 162 XDB END

*** ALARM 872 A2/APT \ DISTRIBUTED GROUP SWITCH FAULT

UNIT TCASE STATE FTYPE MUX34-A-3 1 BLOC INTERNAL POSSIBLE FAULTY BOARDS

UNIT SUBUNIT RP BOARD MUX34-A-3 136 DLEB END

*** ALARM 056 A2/APT \ DISTRIBUTED GROUP SWITCH FAULT

UNIT TCASE STATE FTYPE CLM-0 4 BLOC INTERNAL

POSSIBLE FAULTY BOARDS

UNIT SUBUNIT RP BOARD CLM-0 132 CGB END

告警产生原因：选组级故障或被检测到错误。

告警预处理：选组级有202、501和810三种型号,202和501属同一类型，有CLM (Clock Module) 、TSM (Time Switch Module) 、SPM (Space Switch Module) 3种设备类型，使用指令GS*，其告警标题为“GROUP SWITCH FAULT”。810 选组有CLM(Clock module)、MUX(Multiplexer unit)、XM(Switch matrix unit)3种设备类型，使用指令GD*，其告警标题为“DISTRIBUTED GROUP SWITCH FAULT”。

1、对于上述有关选组的故障，请参考以下的流程处理：

3、如经上述指令处理后告警虽能消除但反复出现的请派单核心网室做进一步处理，并在工单上注明告警反复出现。

22、DISTRIBUTED GROUP SWITCH CLM CONTROL/ GROUP SWITCH CLM CONTROL

告警信息(举例一)：是对于选组级为AXE501设备：

*** ALARM 0267 A3/APT \:GROUP SWITCH CLM CONTROL :CLM :CLM-0 :END

告警信息(举例二)：是对于选组级为AXE810设备：

*** ALARM 0897 A3/APT \:DISTRIBUTED GROUP SWITCH CLM CONTROL :CLM :CLM-0 :END

告警产生原因：

引起选组级时钟单元的告警原因很多： 1、一般可以是由于选组级中时钟板故障； 2、控制该时钟单元的RP故障引起的； 3、连接时钟板的连接电缆的问题； 4、外部接入的时钟源频率偏差较大；

告警预处理：

1、用命令ALLIP；查看告警是否存在；

2、对于上述选组的时钟故障，可参考以下的流程处理：

3、如经上述指令处理后告警虽能消除但反复出现的请派单核心网室做进一步处理，并在工单上注明告警反复出现。

23、EM FAULT

告警信息(举例)：

*** ALARM 598 A2/APZ \ EM FAULT

RP TWIN TYPE EM 120 121 RPM6A 0 END

告警产生原因：

任何定义为EM（ Extension Module）类型的单元出现异常。通常EM由RP控制,编号由0至15。告警预处理：

1、查看和闭解EM

3、如果修复不成功，很可能为硬件故障，请派单核心网室处理。

24、IO-FAULT FOR TRAFFIC DISPERSION

MEASUREMENT

告警信息(举例)：

ALARM 1305 A2/APT \:IO-FAULT FOR TRAFFIC DISPERSION MEASUREMENT :FILE FAULT TYPE

:TRDIPFILE VOLUME ERROR :END

告警分析：

由于统计文件在输出时文件设备无法使用（容量不足）引起的；一般是APG本身的软件缺陷所致，需要加载补丁来最终解决，但可通过以下的方法来处理：

告警处理：

1，对于TRDIPFILE文件，通常是虚假告警，可以用FORLOPP进行释放。 ALLIP：ACL=，FID=YES；查看对应的FID值：FID=XX；

SYFIP：FID=H’xxxx；

SYFRI：FID=H’xxxx，BLOCK=，FILENUM=H’xxxx，IND=H’xxxx； 2，其它统计文件派单地市公司处理。（例如TRARFILE）

25、IO STORAGE SPACE WARNING

告警信息(举例)：

*** ALARM 1577 A2/APZ \:IO STORAGE SPACE WARNING

:AP APNAME NODE NODENAME : 1 GZSS12AP1C A GZSS12AP1A :REASON

:STORAGE USAGE LIMIT REACHED :SOURCE :K:\\MCS\\logs :END

告警产生原因：告警是APG中的K\\mcs\\logs空间不足引起的，需要对该目录下旧文件进行删除处理。

告警预处理：（1）、APLOC；（2）、CD K:\\MCS\\logs （3）、DIR确认是否存在大量的旧文件，若有，则删除旧的文件；（4）、CPFRM XX（XX为旧文件，一般在一个月以前的文件可能删除）（5）、确认告警是否消失：ALIST

26、M3UA DESTINATION INACCESSIBLE

告警信息(举例)：

*** ALARM 170 A1/APT \ 0022 :M3UA DESTINATION INACCESSIBLE :DEST SPID :2-19-250-251 YFG04 :END

告警产生原因：一般是由于传输中断引起链全阻或是对端局异常，包括对端局故障或是软件升级期间的操作引起的。

告警预处理：

1、根据告警信息，在话务网管上确认对端局是否为现网在用局；若为非现网在用局，则确认回单；若为现网在用局，则按以下步骤操作；

2、检查M3UA路由状态，主要看参数DST为AVA； M3RSP：DEST=2-19-250-251； 3、检查M3UA的连接点 M3ASP；

4、激活M3UA路由

M3RAI：DEST=2-19-250-251；

5、在进行上述处理后，告警还没有消除的，则派单给核心室处理。

27、MT ROAMING AND HANDOVER NUMBER, ALLOCATION, SUPERVISION

告警信息(举例)：

*** ALARM 1730 A2/APT \

:MT ROAMING AND HANDOVER NUMBER, ALLOCATION, SUPERVISION :FCODE REASON LATA LAI

: 2 ROAMING NUMBER SHORTAGE LA KNOWN 460-22-10194 :END

告警产生原因：

此告警主要是针对MSC-SERVER局。引起此告警原因很多： 1、ROAMING NUMBER SHORTAGE

2、ROAMING NUMBER SHORTAGE LA KNOWN 3、ROAMING NUMBER SHORTAGE LA UNKNOWN 4、ROAMING NUMBER SHORTAGE LATA KNOWN 5、ROAMING NUMBER SHORTAGE LATA UNKNOWN 6、HANDOVER NUMBER SHORTAGE

7、HANDOVER NUMBER SHORTAGE LATA KNOWN 8、HANDOVER NUMBER SHORTAGE LATA UNKNOWN

现网使用的LAI小区编码是460-00和460-02，对于非460-00和460-02的LAI，通常是现场人员挂微蜂窝小区引起。

告警预处理：对于不同的故障原因，可参考ALEX做处理，以下是做一般处理步骤： 1、用指令ALLIP；确认告警；

2、用指令MGRNP：MSRN=ALL；查看动态漫游号码及切换号码的占用情况；

3、 MGCEP：LAI=460-22-10194；查看和判断该LAI是否有在使用的小区（测试小区除

外，一般测试小区的命名都是比较特殊，如460-07-XXXX-9999）；LAI=460-07-9844-9999是测试场微蜂窝用，由于没有定义LAI与漫游号绑定(MGRLI：LAI=，MSRNS=；)，当开启测试场时，告警就会产生，若把网元LAI与漫游号绑定数据，告警可清除。

4、 MGBSP：BSC=ALL；查看MSC-SERVER下挂哪些BSC； 5、 STRSP：R=BSC1O&BSC2O;

6、用指令ALLIP；确认告警已消失；若不消失，请派单专业室；

28、NETWORK SYNCHRONIZATION FAULT

告警信息(举例)：

*** ALARM 126 A2/APT \ NETWORK SYNCHRONIZATION FAULT REF STATE FCODE 0ETM1,MS-1 BLOC 2 POSSIBLE FAULTY BOARDS UNIT RP BOARD

ETM1-0 ET155E-HOT-O CLB-0 END

告警产生原因：时钟分配或处理模块故障、传输故障等原因引起时钟工作状态异常。

告警预处理： 1、

29、RP FAULT

告警信息(举例)：

*** ALARM 589 A2/APZ \ RP FAULT

RP TYPE 398 RPG3A END

*** ALARM 335 A2/APZ \ RP FAULT

RP TYPE 487 RPPS1

END

*** ALARM 399 A2/APZ \ RP FAULT

RP TYPE 553 RP4S1A END

告警产生原因：RP板发生软件异常或是硬件故障引起的。

告警预处理：对于软交换局TYPE=GARP1E板的RP FAULT，请直接派给核心室处理，其它的类型的RP故障可在白天修复； 1、查看和修理RP：

2、如果修复不了，定位是硬件故障，请派单核心网室进行后续处理。

30、SEMIPERMANENT CONNECTION FAULT

告警信息(举例)：

*** ALARM 1894 A2/SNT \:SEMIPERMANENT CONNECTION FAULT :NAME :JMTGA3-0 :END

告警产生原因：

引起信令链路的半永久连接告警的原因很多，可以是信令终端设备软件异常出错或硬件故障，也可以是信令链所在的传输引起，或是对端问题。传输故障引起的情况较多。告警预处理：

1、检查半永久连接定义的信令链路、传输电路、信令终端 exscp:name=XXXX-Y；

Dev 1 传输通路中用于承载信令链路的信道DEVICE Dev 2 用于处理信令信息的信令终端设备根据SSTATE的状态判断故障点：

Device1 的状态为 BLOC 表示传输通路存在故障 Device 2的状态为 BLOC表示信令终端设备故障建议将半永久连接数据删除重新定义，指令如下: exsce:name=xxxx-y,dev1=xxx-x; exspi:name=xxxx-y; exssi:dev1=xxx-y; exssi:dev2=xxx-y;

exspe;

exsci:name=xxx-y,dev1=xxx-y;

2、传输电路故障

传输中断或误码较严重都会导致信令链路中断，同时出现半永久连接中断的告警。传输中断和误码严重也会有相应告警呈现，或通过以下指令查找传输通路的名称。 Exdep:dev=xxx-y;

Dtstp:dip=xxxy;检查传输通路是否正常 Dtqup:dip=xxxy;检查是否有严重误码

3、信令终端设备故障

造成信令终端设备不可用的原因一般有两类：

SNT故障，一般会有相应的告警switch network fault告警。另一类,RP/EM故障，一般也会有相应的RP FAULT告警。查询控制该信令终端的RP的指令如下: exdrp:dev=xxx-y; C7stp:st=xxx-y;

31、SIZE ALTERATION OF DATA FILES FAULT

告警信息(举例)：

*** ALARM 072 A2/APZ \ SIZE ALTERATION OF DATA FILES FAULT END

告警产生原因：分配给程序存放运行数据的内存空间或数据文件长度不足。

告警预处理：扩SIZE

1、

4、对于进行多次扩SAE后，系统又连续出现告警，则电话联系核心室值班人员协助处理。

32、SIZE ALTERATION OF DATA FILES SIZE CHANGE REQUIRED

告警信息(举例)：

*** ALARM 468 A2/CP_RP \ 0343 :SIZE ALTERATION OF DATA FILES SIZE CHANGE REQUIRED :END

告警分析：

SAE拥塞告警，需要对SAE进行扩大。当一些进程需要更多资源才能继续运行时，系统会出现该告警。产生该告警的主要原因： 1、以前分配的资源不足，需要扩展

2、系统软件异常造成资源耗尽，需要查明真正原因。

告警处理：

1. 指令DBTSP：TAB=SAACTIONS；查看系统提示的SAE以及BLOCK名称和SAE

的类型。

2. 如果SAE的类型为CONS1和CONS2，可用指令SAALI进行自动扩；清除告警。 3. 如果SAE的类型为MANUAL 的，可用指令SAAII：SAE=XX，BLOCK=XX，NI=XX；

进行扩展；

4. 如果指令扩SAE失败,则派发重要工单到相关专业处理或电话咨询操作.

5、如果在完成SAE扩大后，系统又不停发生“SIZE ALTERATION OF DATA FILES SIZE CHANGE REQUIRED”的告警，则电话给核心室值班人员；

33、SIZE ALTERATION OF DATA FILES AUTOMATIC SIZE ALTERATION PASSIVE

告警信息(举例)：无

告警产生原因：产生此告警的原因有：1）、在做CP 升级或者的加载补丁；2）、在更新SAE的数据库表；3）、人工取消自动扩SAE 的功能；告警处理： 1）、对于是在做CP 升级或者的加载补丁期间产生告警，可由厂家跟踪处理； 2）、对于其它的因素引起的，可用以下的命令： SAOCP;

SAOCS：STATE=ACTIVE； ALLIP；

34、SWITCHING NETWORK TERMINAL FAULT

告警信息(举例)：

（1）*** ALARM 368 A2/APT \ SWITCHING NETWORK TERMINAL FAULT

SNT TCASE STATE FCODE SUBSNT INFO FCINFO RHSNT-46 2 BLOC 17 POSSIBLE FAULTY CARDS

UNIT MAG CARD SUBSNT RHSNT-46 TRHM RPG END

（2）*** ALARM 014 A2/APT \

SWITCHING NETWORK TERMINAL FAULT

SNT TCASE STATE FCODE SUBSNT INFO FCINFO MIWUTS-1 1 TRAFLIM 38 POSSIBLE FAULTY CARDS

UNIT MAG CARD SUBSNT MIWUTS-1 CPU PBA (1 FAULTY DSP) END

（3）*** ALARM 987 A2/APT \ SWITCHING NETWORK TERMINAL FAULT

SNT TCASE STATE FCODE SUBSNT INFO FCINFO ECP-60 1 BLOC 1 POSSIBLE FAULTY CARDS

UNIT MAG CARD SUBSNT ECP-60 ECP4

（4）*** ALARM 1291 A2/APT \:SWITCHING NETWORK TERMINAL FAULT

:SNT TCASE STATE FCODE SUBSNT INFO FCINFO :RTDMA-1423 4 BLOC 38 :EXTERNAL EQUIPMENT FAILURE :EXTP MG :2-2-225336 SZM06 : :END

告警产生原因：SNT本身或与SNT相关的接口异常，如连接MGW的传输中断。对于传统交换的告警（如例1、2、3）预处理如下： 1、查看和闭解SNT

2、如果不成功，则需要把SNT下面的DEV先闭掉。 NTSTP:SNT=;

NTCOP:SNT=; 找到DEV号 BLODI:DEV=; 闭掉下面的设备

STDEP：DEV=xx；查看设备状态是否BLOC，如果为BUSY状态要等待，直到为Bloc为止，然后再闭解SNT

NTBLI:SNT=; 闭塞 NTTEI:SNT=; 测试 NTBLE:SNT=; 解闭

BLODE:DEV=; 解闭DEV 3、、如上述NTTEI测试结果有坏板，请派单核心网室处理。

4、如经上述指令处理后告警虽能消除但反复出现的请派单核心网室做进一步处理，并在工

单上注明告警反复出现。

对于软交换局（如例4）中出现的告警，由于软交换是控制和承载相分离，一般是由于在MGW中的电路故障而引发MSC-SERVER产生 “SWITCHING NETWORK TERMINAL FAULT”告警，处理步骤如下：

<用EMAS登陆到MGW-Element Manager界面，在TDM Temination Groups －》PCMsystem Nr列（225336）找到Ds0Bundle MoRef->225336/1~31（找到逻辑传输号与MSC_server上的SNT的EXTP对应）。

<在ATM->DS-0 Bundles的Name列找到Ds0Bundle=225336/1~31，点击右键查看Properties属性，在LDN上可清楚看到该逻辑电路的实际物理位置： Subrack=2（框号） Slot=25（槽号）

Os155SpiTtp=2253（光纤端口）

Vc12Ttp＝43 ――>正真的物理端口

<确定物理端口后，可在Equipment->Equipment->Subrack=2->找到2253光纤端口，在Name列找到43：E1物理端口号并查看状态，点击右键进行Lock和Unlock解闭端口。常见的FC情况举例：

FC24：RP和DP之间的通信错误。可以尝试闭解SNT，如果不行则需要先闭塞RP，然后闭、测、解SNT，最后解开RP。（例如ECP类的SNT）

FC25：CP和RP之间通信错误，需要查看CP和RP状态，如果都正常，则可尝试REPCI修复CP,REPRI修复RP。

FC34：不可知的SNT错误。一般是对端问题，可能是数据没有定义完整导致的，可以查看： NTCOP:SNT=**;找到对应的DEV，然后EXDEP查看这些DEV是否连接到路由R，如果没有连接到路由，则表明没有带业务，可以派单要求专业室闭塞告警。

FC38：硬件错误，一般要更换硬件才能解决。但是也不排除诊断出错，所以可以尝试闭解SNT，观察告警是否会反复出现。如果反复出现，则派单换换板。

35、SYNCHRONOUS SUPERVISION

DIGITAL PATH FAULT

告警信息(举例)：

*** ALARM 143 A1/DIP “GZ36BBSCR12/GB/”U 080530 1118 :SYNCHRONOUS DIGITAL PATH FAULT SUPERVISION

:SDIP STATE LAYER K L M FAULT INFO DATE TIME :3ETM2 TRAFLIM VC12-22 2 1 2 AIS 080530 111808 :TYPE PL/TTI ERDIINFO :END

告警产生原因：

引起此类告警的原因很多，一般可以是由于ET155中的某些低阶信息故障，如2M传输中断引起的。

告警预处理：

1、TPCOP：SDIP=3ETM2；确认是哪个VC12对应哪条DIP； 2、DTDIP：DIP=XXUPD1；查出对的SNT；

3、NTCOP：SNT=ETM2-3；查出DIP所在的DEV；

4、STDEP：DEV=UPD1-xx&&-yy;确认这些设备是否有连接上路由，有连接上路由的，说明是有用的，需要派单给传送室处理；没有连接路由的，则没有用的，可对此VC12进行人工闭塞操作：

TPBLI：SDIP=3ETM2，LP=VC12-22； 5、查看告警是否消失；ALLIP；

36、SYNCHRONOUS DIGITAL PATH UNAVAILABLE STATE FAULT

告警信息(举例)：

*** ALARM 486 A3/DIP \

:SYNCHRONOUS DIGITAL PATH UNAVAILABLE STATE FAULT :NEAR END (INCOMING DIRECTION)

:SDIP LAYER N-UAS DATE TIME :2ETM2 VC12-4 090107 014749 :END

告警产生原因：引起此类告警的原因很多，一般可以是由于ET155中的某些低阶信息故障，如2M传输中断引起的。告警预处理：可参考故障“SYNCHRONOUS DIGITAL PATH FAULT SUPERVISION”处理，同时建议同告警“SYNCHRONOUS DIGITAL PATH FAULT SUPERVISION”进行压缩合并处理。

37、VOLUME LIMIT EXCEEDED

告警信息(举例)：

*** ALARM 833 A2/APZ \ 2352 VOLUME LIMIT EXCEEDED END

告警产生原因：一般是由于IOG本身的硬盘空间比较小，其中的某个VOLUME使用空间少于设定的门限值的时候，系统就会出VOLUME LIMIT EXCEEDED的告警；

告警处理：

1. 先查看该VOLUME的使用极限: INMCT:SPG=0;

INVOP; 看硬盘有哪些VOL（VOL=RELVOLUME不能随便删！） INVOP：VOL=XX；看使用的和未用的文件有多少

INFIP：FILE=TLOG/TLOGON/TLOGRESTART；查看哪些文件可以删，其中TLOG文件是

记录所有操作的文件，一般是对TLOG中的旧文件进行删除（1 个月以上的文件） END；

2. 对于文件的删除，首先要把该文件从FPU中删除: INFUE:FILE=FILE;

3. 然后再从硬盘上删除文件。 INMCT:SPG=0; INFIR:FILE=FILE; END;

删除一定数量的旧文件后，该VOLUME的空间增加，空间达到所需要的大小后，告警就会消除。