DIRCP 告警处理

利用CP的硬件记录信息认识CP运行情况
摘要:目前日常维护CP的工作不多，当出现CP FAULT告警时，只有参照OPI处理或
者打故障报告。本文介绍如何利用CP本身的记录信息来了解CP的运行情况，
同时帮助解决一些CP FAULT 告警。

关键词:DIRCP ACT ETYPE CODE

在日常的交换维护工作中，爱立信的CP维护大多是用DPWSP.PLLDP指令查看CP的状态和负荷，虽然这两条指令能让我们了解到CP的基本运行情况，但是一旦出现CP FAULT告警（包括A1.A2.A3级别)，只有参照OPI流程的三条指令（REPCI.REMCI.RECCI)处理或者打故障报告。其实我们可以充分利用CP的硬件记录信息，获得当前有关CP的最新运行情况;同时还可以帮助解决CP FAULT的告警。这功能的实现只需要一条指令——DIRCP。
指令DIRCP把CP的硬件运行情况记录一一打印出来，通过对这些打印信息进行分析，我们不难从中得到需要的东西。下面通过一个例子来说明其中的原理:某网元有A2级的CP FAULT告警，输入DIRCP指令（以下是部分打印结果):
ORDERED
CP EVENT RECORD
（第一部分的PRINTOUT)
NO DATE TIME ETYPE ACT REP BNR CODE INF1 INF2 DINO
380 010305 0100 8 H'049D 106 H'0001 H'0000
379 010304 2138 7 H'049E 211 H'0000 H'0000
378 010304 2132 7 H'01A1 700 H'0001 H'0001
378 010304 2132 11 H'01A1 701 H'0002 H'0026
702 H'0001 H'0001
377 010304 2127 7 H'049E 211 H'0001 H'2000
371 010303 0100 8 H'049D 106 H'0001 H'0000
370 010302 1626 7 H'01A1 700 H'0000 H'0001
370 010302 1626 9 H'0006 0 H'0000 H'0000
370 010302 1626 5 2 YES H'04A1 400 H'000A H'0000
401 H'0001 H'000C
401 H'0002 H'0000
403 H'0002 H'0000
370 010302 1626 5 1 YES H'04A1 400 H'000A H'0000
401 H'0001 H'000C
401 H'0002 H'0000
403 H'0002 H'0000
369 010302 0100 8 H'049D 106 H'0001 H'0000
368 010301 0100 8 H'049D 106 H'0001 H'0000
……

（第二部分的PRINTOUT)
CODE INF1EXP INF2EXP
0 RECOVERY FINISHED
IRRELEVANT IRRELEVANT
10

6 MAU ROUTINE TEST
H'0001 = RUN IRRELEVANT
H'0002 = REJECTED CODE
H'0001 = MAU ALARM
H'0002 = ERROR FREE TIME < 2H
H'0003 = ERROR CHECK NOT OK
H'0004 = NOT PARALLEL WO
H'0005 = CPU-A IS NOT EX
400 FAN FAULT IRRELEVANT
H'000A = FANC IN A-SIDE
H'000B = FANC IN B-SIDE
H'001A = FANR IN A-SIDE
H'001B = FANR IN B-SIDE
401 MAI REGISTER REGISTER VALUE
H'0001 = STATER3
H'0002 = STATER4
403 LINK TO BOARD LIST IRRELEVANT
700 CP FAULT
H'0000 = SET ALARM ALARM CLASS (ACL)
H'0001 = RESET ALARM ALARM CLASS (ACL)
H'0002 = CHANGED ALARM NEW ACL AND PREVIOUS ACL
701 BOARD REPLACEMENT
MAGAZINE CODE PCB CODE
H'0000 = CPU-A H'0000 = MAU
H'0001 = CPU-B H'0001 = IPU
H'0002 = FANC-A H'0002 = SPU
H'0003 = FANC-B H'0004 = POUC
H'0004 = FANR-A H'0008 = POWC
702 REASON FOR CHANGE OF BOARD CODE
H'0000 = NO FAULT IRRELEVANT
H'0001 = PERMANENT FAULT ESTIMATED POSITION IN PCB LIST
H'0002 = TEMPORARY FAULT ESTIMATED POSITION IN PCB LIST

END

这些打印信息中我们只关心其中的两部分，第一部分信息是记录某一时刻CP运行状态的信息代码，这些代码当中，我们留意的是ACT.ETYPE.CODE和INF1这四项，它们的不同取值表示不同的意义，在ALEX帮助下可以清楚地查到。第二部分信息是对CODE和INF1.INF2进行注解，从中我们了解到CP本身进行了什么活动，在哪里出现了问题而导致故障。
就拿上面的PRINTOUT来分析:
对PRINTOUT 1:
我们首先关注ACT（Type of ACTivity Registered)，它是CP 有故障的标志。因为CP正常时这一列的内容是空的，它只是在CP出现故障（CP FAULT.MAU FAULT.CORRECTABLE BITE FAULT.SUPERVISORY CIRCUIT FAULT和FAN FAULT)时才会出现，因此不难发现在2001年3月2日16:26 CP 出现了故障，查询ALEX，ACT=1表示故障是在CP进行例行自我检查时出来的，ACT=2表示CP发现故障后再次进行自检以确认告警是否真的存在。ACT是快速诊断CP是否正常的好帮手。其次要看ETPYE，它给我们带来究竟CP出了哪

种故障的信息，或者CP进行了什么样的活动，具体取值代表什么意思同样查ALEX就知道。ETYPE=5，表示CP有风扇故障;正常时CP会定时进行例行的自检工作，ETYPE取值为8，因此ETYPE=8是CP 正常运行的标志。从上面的CP 运行记录看到，在2001年3月2日16:26，CP在自我检查中发现了风扇有问题，因此出了CP FAULT 告警。但究竟风扇怎么回事了？是哪一边的风扇呢？我们需要CODE和INF1.INF2这些附加的详细信息码的帮助。带着CODE=400，INF1=H000A的信息，到第二部分PRINTOUT里查找。
对于PRINTOUT 2，这里起了详细注解CODE和INF1.INF2的作用。只要我们带着它们的取值，在PRINTOUT 2里对号入座，很快就能获知其具体意义。对于本例，CODE=400，INF1=H000A，查到是FANC IN A-SIDE，说明真的是风扇有问题，而且是CP-A边的FANC单元。至此，我们不妨按照OPI流程，假换A边的风扇，试着解决CP FAULT 告警。下面是我处理的过程:
REPCI;
<;
ORDERED

<
WO SDAMSC57/GB/0/0/05/02B AT-4 TIME 010304 2126 PAGE 1
CP DIAGNOSIS

TEST RESULT
FAULT

FAULTTYPE
PERMANENT

MAG PCB REPLACED REASON
FANC-A FAN-1
CPU-A POWC
CPU-A CCU3-0
CPU-B MAU 001103 PERMANENT

END

WO SDAMSC57/GB/0/0/05/02B AT-4 TIME 010304 2127 PAGE 1
REMCI:MAG=FANC-A,PCB=FAN-1;
<;
ORDERED

<
EX-B SDAMSC57/GB/0/0/05/02B AT-4 TIME 010304 2127 PAGE 1
CP MANUAL INTERVENTION

INTERVENTION PREPARATION
SUCCESSFUL

ACTION MAG PCB NOTE
LOCATE FANC-A FAN-1 LOCATE PCB IN POS 30 IN MAG
REPLACE FANC-A FAN-1

END

RECCI;
<;
ORDERED

<
WO SDAMSC57/GB/0/0/05/02B AT-4 TIME 010304 2132 PAGE 1
CP REPAIR

SUCCESSFUL

END

WO SDAMSC57/GB/0/0/05/02B AT-4 TIME 010304 2132 PAGE 1
CP STATE

MAU SB SBSTATE
NRM B WO

END

结果很令人满意。由此证明上述的分析是正确的。
如果过不久CP FAULT 又重新出现，可以初步判断该硬件单元不能正常工作了，建议打故障报告，让爱立信来做深入的分析。如果用上述三条指令试图修复CP，但是失败，还导致CP单边，大家不妨用REPCE指令结束该

次的CP修复流程，估计CP会并边成功的。
fxjuan发布于2006-10-24 16:20:54
交换机故障类型及分析方法
交换机运行中出现故障是不可避免的，但出现故障后应当迅速地进行处理，尽快查出故障点，排除故障，这是维护人员应尽的职责。但是要做到这一点，就必须了解交换机故障的类型及具备对故障进行分析和处理的能力。为此，本文就交换机常出现的故障类型及分析处理的方法作一简要的介绍。

1 故障分类
从笔者多年来维护程控交换机的经验和在工作中遇到的故障来看，交换机的故障一般分为以下类型。
具体类型是:
（1)电路板损坏
电路板上的元器件受损或基板不良，造成电路板不能正常工作。
（2)硬件工注不合适
硬件工注是为减少电路板的种类，而在电路板上设置的一组或几组开关，用以定义该电路板的工作状态或在系统中所处位置，如硬件工注设置得不正确，必会导致该电路板工作不正常。
（3)电路板块类型不合适
硬件更新后，同一名称的电路板块可能有多种不同的型号。在一般情况下，新型号电路板的功能会兼容旧型号电路板的功能，但旧型号的电路板的功能就不一定能兼容新型号电路板的功能了。
（4)机架.模块的问题
机架.模块用于承载电路板，按其在系统中的位置被分为处理机系统的机架.模块，交换系统的机架.模块和维护管理系统的机架.模块等。这些机架.模块也会出故障。
（5)设备供电的问题
整流器提供的-48V直流电被分配到每一个机架及相关的设备上，机架内的电源分配系统负责向模块供电，而每一模块上的电源电路板，都能根据模块内各电路板所需的电压进行调整，然后配送到每一块电路板上。但在这一过程中，任意环节出现问题，都有可能造成供电的故障。
（6)连接电缆和配线架跳线的问题
连接电缆和配线架的跳线是用来连接模块.机架和设备用的，如果这些连接电缆内的缆芯或跳线发生了短路.断路或虚接，就会形成通信系统的故障。
（7)程序BUG
软件程序设计存在着缺陷。
（8)系统数据错误
系统数据，包括软件工注，用于对整个系统进行定义。如系统数据出现错误，也会造成系统全方位的故障，对整个交换局产生影响。
（9)局数据错误
局数据是根据交换局的具体情况而定义的。当局数据出现错误时，也会对整个交换局产生影响。
（10)用户数据错误
用户数据对每一个用户的情况进行定义，如果用户数据被错误设置，出现用户数据错误，会对某个用户产生影响。
2 故障分析和处理的方法
不同的故障会有不同的表现形式，故障分析的目的就是要通过分析故障现象，找出故障的原因和确定故障的

地点，以对故障进行排除。为了使故障分析工作有条不紊和有章可循，需要在故障分析中参照故障分类表的级别，逐步推进。首先是按一级分类，确定是软件故障还是硬件故障，然后根据二级.三级分类进行递推。第五级分类都有很多测试的方法，一些常用的测试方法有:
（1)排除法
根据故障现象，罗列出故障发生的可能性，然后逐步排除。在罗列故障可能性的时候，要尽可能全面一些，不要有遗漏。排除可能性时要从简而繁，避免无效劳动。这种方法的逻辑性较强，可以应对各种各样的故障，但缺点是对维护人员的要求较高，要求维护人员对交换系统有全面深入的了解。
（2)对比法
用本系统正常运行的设备或他局正常的设备作基准，对比故障设备和正常设备之间的区别，找出故障所在。这种方法简单易行，对软件故障的排查尤为有利，但缺点是用途有限，特别是一些故障无法找到有效的对比基准。
（3)替换法
用正常的设备去替换有怀疑的设备，这种方法主要用于对硬件设备故障的处理。替换时应注意正常设备的型号.类型及硬件工注是否与欲替换的设备完全相符。
以上几种方法，在实际运用中，有时是交替使用的，目的是为了迅速准确地找出故障点。
下面结合故障处理来说明故障分析和处理的方法。
故障（1)
故障现象:某新局开通后，一些用户在出局呼叫时，经常呼叫不成功，用话务统计监测时，发现出局呼损过大，近30%，且不分局向。
故障分析:此故障现象无法明确判定出是软件故障还是硬件故障，也没有可比对参照的设备，所以无法使用对比法和替换法，只能使用排除法来处理。
由于该故障与呼叫有关，与用户无关，不会影响用户的其他呼叫，所以可以排除用户电路和交换系统方面的因素。但根据呼叫流程，可以分析出与出局呼叫相关的硬件设备有用户电路.局间中继电路.收发码器和交换系统，与出局呼叫相关的软件系统有用户数据.局间中继局数据和收发码器局数据等。这样，依据由简入繁的原则，可首先进行局是中继电路的测试，结果没有发现什么问题，于是又对收发码器进行测试，发现有近25%的收发码器不能使用，且都集中在相同的模块上。但对这些不能使用收发码器按号码检查其局数据的设定时，并没发现有什么问题，至此可以肯定，该故障属于硬件方面的问题（集中在相同的模块上)。于是对硬件模块和所连接的设备进行了检查，并用对比法，将有不能使用收发码器的模块与收发码器正常工作的模块相比较，才发现是其控制电路板的型号不正确。待更换了正确型号的控制电路板后，故障即被排除。
故障（2)

故障现象:某局一个中央处理机模块不能在双机状态下运行，由人工输入双机命令返回的信息是，中央处理机模块备用侧不能正常工作;用诊断命令对备用侧进行诊断的提示信息是，备用侧一部分电路板不正常。
故障分析:该故障明显地属于硬件的故障。于是按照故障信息的提示，首先运用替换法，将备用侧的电路板更换掉。但是，电路板更换后，故障现象并没消失。就是说，真正的故障点不在备用侧的电路板上，造成备用侧故障的原因，有可能是机架.模块.供电及连接设备等。于是又用排除法对这些设备逐步进行排查，特别是找出了中央处理机模块的工作说明书，仔细分析其由单机转向双机的过程，并由人工发双机命令，先由主用侧接收数据，然后由主用侧通过主被控制电路板向备用侧发送集合，让被用侧进行自检等。这一过程如备用侧正常，就会回复主用侧，并做好接收主用侧信息的准备。如主用侧收到备用侧正常回复的信息，就会向备用侧传送现行数据，实现双机运行。然而现在的问题是，主用侧没有收到备用侧正常回复的信息。是什么原因呢？是主用侧根本就没向备用侧发出双机指令还是备用发出的正常回复信息主用侧收不到呢？这些都与主用侧主备控制电路板的传递有关。为此，通过再启动，强制转换中央处理机模块的主备用设备，并更换了原主用侧的主备控制电路板，故障现象就消失了。
此故障的类型即为电路板损坏故障。
故障（2)
故障现象:某局城建产设局间中继电路设施，但在硬件设施安装完毕后，输入局数据时出现了差错，即出现了局数据存储状态错误的提示。
故障分析:该故障按故障类型，很明显为软件故障，是无法使用替换法的。为此，根据由简入繁的原则，先采用了对比法，即打印出相关的局数据与他局进行比较，很愉就在内存管理表中发现了可疑点。由于局数据内存管理表是按照起始地址.终了地址.存储空间.剩余空间来管理的。而该局内存管理表中剩余空间的数值比存储空间的数值大了很多，很明显是局数据的管理出了问题。于是用机器码修改命令，调整了局数据内存管理表，就排除了这个故障，使局数据的运行达到了正常。
3 结束语
故障的现象是多样的，故障的原因也是多样的，同一故障，可能有多种不同的故障现象。同一故障现象，也可能有多种不同的原因。例如，用户电路板的故障，既可以表现为用户无蜂音.杂音.错号，也可表现为单通.无振铃等。而且，同样是用户无蜂音的现象，其原因也可能是配线架接触不良，用户模块有问题或是交换系统的问题等等。所以，要求在进行故障分析的时候

，一定要尽可能全面.详尽地了解故障现象和灵活地运用故障分析方法。同时，要做好分析记录，整理和记下每一次故障分析.处理的全过程，以积累经验，不断提高故障处理的水平。

A1/APZ "GUYGS6/CN79B/KD" 183 150915 0046
CP FAULT

处理方法：CP修复三部曲
REPCI; !进行CP诊断操作，根据诊断信息判断是Permanent的还是Temporary的!
REMCI:MAG=XX,PCB=XX; !若是Permanent的，则进行REMCI!
RECCI; !并边!

如果REPCI;诊断结果是没有错误：
CP DIAGNOSIS

TEST RESULT
NO FAULT

则执行REPCE;不然会出以下告警：
O1/APZ "NCS3/CN79B/KD/0" 093 150912 0121
SYSTEM STATE

REPAIR OF CP OR AMU

A2/APT "SNIGS6/79B/SPX1" 202 150923 0043
DISTRIBUTED GROUP SWITCH FAULT

UNIT TCASE STATE FTYPE

CLM-0 1 BLOC INTERFACE

DISTRIBUTED GROUP SWITCH STATE

UNIT STATE BLSTATE VAR STATUS

CLM-0 BLOC ABL 10 SLAVE
CLM-1 WO 10 MASTER

UNIT STATE BLSTATE VAR UNIT STATE BLSTATE

XM-A-0-0 WO 0 XM-B-0-0 WO

END

处理方法：
GDBLI:UNIT=CLM-0;
GDTEI:UNIT=CLM-0;!查看POSSIBLE FAULTY BOARDS
GDBLE:UNIT=CLM-0;

如果闭解选组板不行，尝试闭解RP：
BLRPI:RP=7,FORCED;
BLRPE:RP=7;

再不行，做个TERDI:
TERDI:RP=7;

最后只能做个CP大启做最后尝试了：
SYREI:RANK=LARGE,EXPL=PLAN;

最后的最后还是不行，只能做拔插板、换板处理了。

A2/APZ "MYGS8/CN79B/KD/" 456 150915 0208
RP FAULT
RP TYPE
194 RPPS1

方法一：闭解RP
BLRPI:RP=194;
BLRPE:RP=194;

方法二：分离闭解RP
FCRWS:RP=194,WS=SEP;
BLRPI:RP=194;
BLRPE:RP=194;

方法三：测试修复RP
REPRI:RP=194;
REMRI:RP=194,PCB=RPPS1;
RECRI:RP=194;

方法四：进入Debug模式做重启
TREDI:RP=194; !如果出结果是CONNECTION FAILED NO ANSWER FROM RP/EMRP，尝试拔插/换板处理。

方法五：换板。

TIPS:以上过程中也要检查一下RP/EM软件有没定错!

*** ALARM 195 A2/APZ "SZ55BR12/ME/G10"U 111113 1428
:RPB-E NETWORK FAULT
:NET
:B
处理方法:
EXRNP:RP=ALL;查看RPB-E RP DATA
EXRPP:RP=rp;查看LINK为DOWN状态的RP状态
FCRWS:RP=rp,WS=SEP;分离RP
BLRPI:RP=rp;
BLRPE:RP=rp;解闭对应的RP
EXRPP:RP=rp;
EXRNP:RP=ALL;RP对应的LINK为UP状态

A3/APT "MYGS6/CN79B/KD/" 007 150826 0212
MT FAILED AUTHENTICATION

MGARP:NLOG=ALL; !查看移动台认证失败的LOG日志。
MGAAR; !复位此告警。

A3/APT "MYGS6/CN79B/KD/" 136 150826 1206
EVENT REPORTING THRESHOLD REACHED
ENUM THRESHOLD LEVEL
117 TH 50

ERESP:ENUM=XX/ALL; !查看事件报告
EREAR:ENUM=ALL,NP; !复位此告警。

A2/CP_RP "SZ24AR12/HD/G12" 661 130425 0002
SOFTWARE ERROR

SYRIP:SURVEY; //查原因
SYRAE:EVENT=XX; !XX=ACT是YES的EVENT号码

或者：
SYRAE:RECTYPE:SOFTERR; //清除,软件错误
SYRAE:RECTYPE:APPLERR; //清除,应用错误

A3/APZ "STDMSC62/KD/0/2" 846 141214 1834
APPLICATION DETECTED SOFTWARE ERROR
清除指令：SYRAE:RECTYPE=APPLERR;

A3/APZ "STDMSC62/KD/0/2" 846 141214 1834
SOFTWARE ERROR
清除指令：SYRAE:RECTYPE=SOFTERR;

SYSTEM RESTARTED: (通常为O级告警，可不处理)
SYRAE:EVENT=event;

A2/APZ "MYGS6/CN79B/KD/" 004 150826 0212
BACKUP INFORMATION FAULT
FAULT CODE 34
AUTOMATIC OUTPUT IS PASSIVE
CP自动备份功能未激活，激活指令：
SYBUI;
SYBUI:DISC;!for CP3X

如果是 FCODE 13:
SYBUE;
SYBUP:FILE;
SYTUC;
SYBUI;
SYBUI:DISC;!for CP3X
A2/APZ "MYGS6/CN79B/KD/" 006 150826 0212
COMMAND LOG BLOCKED
FAULT
FAULT CODE 155
COMMAND LOG NOT ACTIVATED

COMMAND LOG未激活，激活指令：
SYCLI;

O1/APZ "MYGS6/CN79B/KD/" 011 150826 0212
BACKUP INFORMATION FAULT
FAULT CODE 120
RELOADING FUNCTION BLOCKED BY COMMAND

自动RELOAD功能未激活，激活指令：
SYRBE;

A2/APZ "DGLMSC57R/HD/0/" 043 120131 1340
MANUAL EXECUTION OF COMMAND LOG REQUIRED
FNUM
0000043
解决方法如下:
APLOC;
cpfls -ls RELCMDHDF
exit;
IOCMC:STATE=PASSIVE; !SYCLE;
IOCMI:FILE=RELCMDHDF-xxxx;
直至最后一个COMMAND LOG的子文件.如果这种方法还不能消除告警,则用指令强制消除所有CLOG的告警.
SYLAE;消除所有CLOG的告警
IOCMC:STATE=ACTIVE;!SYCLI;

!See Operational Instruction "Command Log File, Manually
Execute".

*** ALARM 163 A2/CP_RP "SZ09BR12/ME/G10" 110730 0200
:RELOAD PARAMETERS INVALID
:FCODE
:2
:END
处理方法:
出现这个告警是由于无效系统重载参数引起的
APLOC;进入AP模式
CPFLS-ls RELCMDHDF查看command log文件
EXIT;进入CP模式
SYCSI:SNF=0000192;新建command log子文件,文件号要接着去,即是最大
*** ALARM 517 A2/IO_DEV "SZ49ER12/HD/G10"U 110218 1114
:COMMAND LOG OUTPUT ERROR
:FAULT
:FAULT CODE 65
:FILE ACCESS ERROR
:END
处理方法:
重启进程FMS_CPF_SERVER
CLUSTER RES FMS_CPF_SERVER /OFF /WAIT
CLUSTER RES FMS_CPF_SERVER /ON /WAIT

A2/APZ "SNIGS5/CN79/KD/" 554 150806 0014
NO LICENSING INFORMATION AVAILABLE
SOLUTION:
lmlkls !Print installed License Keys.
1.C:\Program Files\AP\ACS\sys>copy lservrc c:\temp\lmfile.txt
2.C:\temp>lminst lmfile.txt

*** ALARM 144 A2/IO_DEV "SZ09AR12/HD/07A"U 091009 1521
:AP SYSTEM ANALYSIS
:AP APNAME NODE NODENAME
: 1 SZ09AAP1C B SZ09AAP1B
:OBJECT COUNTER INSTANCE LIMIT VALUE
:Memory Available Bytes <104857600 98086912
:END
处理方法:
aploc; 进入AP模式
cluster res 查看所有进程
cluster res stsmain /off /wait 结束stsmain进程
cluster res stsmain /on /wait 启动stsmain进程
cluster res |findstr –ive online 查看没有起来的进程
cluster res stsprov /on /wait 启未起来的进程，还有stsconv,stsopcf.
cluster r

es |findstr –ive online 再次查看没有起来的进程，全部已起来
告警检查，告警消除
*** ALARM 152 A2/IO_DEV "SZ09BR12/ME/07B" 110408 1636
:AP FILE PROCESSING FAULT
:AP APNAME NODE NODENAME
: 1 SZ09BAP1C B SZ09BAP1B
:CAUSE
:FILE TRANSFER FAILED
:TRANSFER QUEUE
:BARTRQ
:DESTINATION SET
:RNOFILE
:END
处理方法:
用指令afpfti手动传送不成功
原因是更换APG后设备密码不正确引起的或者由0SS账号引起的
cdhch -u apg123 -p RNOFILEApg@123
更改之后可以正常传送
*** ALARM 577 A3/APT "GZSM11B1R12/GB/"U 080108 0459
:STATISTICS AND TRAFFIC MEASUREMENT FILE ACCESS FAULT
:AP APNAME NODE NODENAME
: 1 GZSM11B1AP1C B GZSM11B1AP1B
:FILE ACCESS OF INTERNAL DATABASE IS NOT POSSIBLE
:END
处理说明:
1. 查看告警ALLIP;
2. 进入AP模式APLOC;
3. 查看APG进程Cluster res
4. 找到进程中相关进程，停掉进程Cluster res stsmain /off /wait
该进程与其他3个进程有关联，停掉该进程后会3个进程与其一起变成offline状态。3个进程分别为:
Stsprov AP FILE PROCESSING FAULT
Stsconv
Stsopcf这三个进程可以用指令查得:cluster res | findstr –ive online
5. 查看确认进程是否已经停掉Cluster res
6. 重新开启进程，注意要对4个进程都开启。
Cluster res stsmain /on /wait
Cluster res stsprov /on /wait
Cluster res stsconv /on /wait
Cluster res stsopcf /on /wait
根据经验，一般当我们起stsmain及stsprov后全部进程就会都起来。
7. 确认进程均已起来Cluster res | findstr –ive online
8. 确认告警是否消除Alist
也可以回到CP模式下用ALLIP确认告警消除。
故障总结:
statistics and traffic measurement file access fault告警为A3级告警。
该告警往往在APG倒边或者APG一边DOWN掉时出现，一般情况下会自动消除，若不能自动消除，则需要对APG相关进程重启或者对APG进行倒边。
APG进程说明如下:
stsmain STS Collection Service
stsopcf STS Output Configuration Service
stsprov STS Provisional Service

CELL LOGICAL CHANNEL AVAILABILITY SUPERVISION
告警描述:CELL LOGICAL CHANNEL AVAILABILITY SUPERVISION
原始级别:A1,A2,A3
建议级别:A1->重大告警,A2->主要告警，A3->次要告警
变更说明:无
设备类型:BSC
告警解释:该告警指示小区逻辑信道损坏情况。根据损坏的逻辑信道的类型和个数分别产生A1,A2,A3级别告警。系统一般设置为以下情况:
1． BCCH可用信道小于1个以下产生A1告警。因为一般情况下一个小区只设置一个BCCH逻辑信道，所以如果产生以上A1告警，即该小区全阻。
2． SDCCH可用信道小于1个时产生A2告警。
3． TCH可用信道监控产生A3告警。
产生此告警的原因可能有:
1、小区与BSC之间配置的传

输电路中断;
2、小区与BSC之间配置的传输电路人工闭塞;
3、管理该传输电路的RP、EM、TSM、SNT、DIP退服。
2、基站故障;
3、BSC上该基站配置数据错误;
4、BSC上配置该基站的MO（包括TG/TF/CF/TRX/TX/RX/TS）状态异常。
业务影响:告警对应该小区部分或全部阻塞，该小区覆盖下用户通话受影响。
参数说明:无
处理建议:1. 判断告警对应小区受损情况:
A. 告警级别。一般A1为全阻，A1以下为部分阻塞。
B. RLCRP:CELL=<告警提示小区>;查看小区的各逻辑信道分配情况。
2. 告警初步处理（包括对位故障点，远程处理方法）
A. 根据以上判断，如为全阻，检查小区对应传输状态，包括DIP/SNT/EM/RP/TSM。
B. 检查该小区各MO状态:
RXMSP:MO=,SUBORD;
如某MO状态异常，可尝试使用RXBLI/RXESE/RXESI/RXBLE进行修理。
C．检查小区参数设置情况。
D．检查ABIS通道分配情况:RXAPP:MO=;如分配有问题，可检查参数，TRH是否已满配置。
E．如以上均无问题，检查基站。

A2/CP_RP "HZSM1B3R12/ME/G" 071 130914 0300
SIZE ALTERATION OF DATA FILES SIZE CHANGE REQUIRED

A2/CP_RP "HZSM1B3R12/ME/G" 065 130914 0231
AUDIT FUNCTION THRESHOLD SUPERVISION
TEST 110

解决方法：
SAALI;!自动扩SAE
如果自动扩SAE不成功，尝试手动扩SAE:SAAII，需要扩的SAE用指令DBTSP:TAB=SAACTIONS;查看NEWNI值。

*** ALARM 576 A2/APT "BZBSC15R12/UF/G"U 151001 1303
:RADIO TRANSMISSION TRANSCODER AND RATE ADAPTOR FAULT
:SNT CARD DEV REASON
:RTTG1S-11 TRAB RTTG1D-5984 PARTIAL BOARD FAULT
: RTTG1D-5994
: RTTG1D-6004

处理过程:
A：ALLIP; 查看交换机告警;
B: NTSTP:SNT= ; 查看告警SNT状;
C: NTCOP:SNT= ; 查看告警中出现SNT下面的DEV;
D: STDEP:DEV= ; 查看相关DEV的状态;
E: RRTBI:DEV= ,FORCE; 对出现ABL的DEV进行人工闭塞;
F: RRTBE:DEV= ; 对出现ABL的DEV进行解闭;

处理结论: TRA设备ABL起引，一般通过对DEV闭解来解决。如果对出现问题的DEV进行解闭后设备仍ABL的话，尝试对该板进行拔插一次。再不行换板处理。

RADIO TRANSMISSION TRANSCODER POOL MEAN HOLD TIME SUPERVISION

处理方法：
1.查看那些设备出现告警
RRMAP:TRAPOOL=ALL;
2.检查mean hold time监视数据设置是否正确
RRMSP:TRAPOOL=ALL;
3.根据出告警设备的类型，断开BLOCKING SUPERVISION
RABLE：DETY=…;
4.对告警提示的TRA设备可用RRTBI:DEV= ,FORCE; 来闭塞注意TRA设备一般是5个一组的只要闭塞一组里第一个设备其余4个也都会闭塞。
RRTBI:DEV=XXXX,FORCE;
!关于tra设备如何分组，用STDEP:DEV=…; CONFIG 列是PC的为一组里面的第一个设备。
5.等告警消了,过一段时间再用RRTBE:DEV=XXXX; 把设备解开.
RRTBE:DEV= ;
6.连回BLOCKING SUPERVISION

RABLI：DETY=…;

A3/LOAD "FSM17B7R12/ME/G" 305 140424 0250
RADIO CONTROL ADMINISTRATION
TRH LOAD THRESHOLD EXCEEDED

用指令消除：
RAHAR;
!ALEX中有更具体的操作说明.

C:\>alist

Alarm Identifier Class Category Time

8799:0 A2 APZ Thu Oct 27 15:34:56 2005

Object of Reference

LOGFILE/SYSTEM-GENERAL

Alarm Text

AP FAULT

PROBLEM

GENERAL ERROR

Problem Data

Thu Oct 27 15:34:55 2005 349003 GZLHLRAP1B 5731 128 NETLOGON EVENTLOG_ERROR_TYPE BUILTIN Rid: 0x220 GZLHLRAP1A %%1377

处理方法：用acease指令消除，一般GENERAL ERROR的AP FAULT为事件性告警，均可用指令直接消除

C:\>acease 8799:0

Alarm ceased.

如果结果为“This alarm cannot be manually ceased.” 则需检查别的原因

验证告警是否消除;

如过告警用acease指令无法消除，或消除之后仍反复出现，请打TR。

MSC-S/VLR用户驱赶:
1.不定向驱赶:
MGSRE:msisdn=8613518360972;
!CTRAI:MSISDN=8613518360972;
2.定向驱赶:
mgtrp:msisdn=8613518360972;
MGNDP;
MGPRI:IMSI=460000*********,NRIV=28;
!MGTRp:msisdn=8613518360972;
如果提示不成功，关机再试。
1.MSCs在升级至R14/13A 版本后，需要使用新指令:MGPRI: imsi=xxxxx, NRIV=xx;替代原R14指令MGSRE: imsi=xxxxx, NRIV=xx; 来做MSC Pool内用户指定NRI驱赶的操作;
2.需要检查SAE=500, BLOCK=MTMSIAN的NI值(>=1)，建议扩容至1000或更高;
3.指定NRI驱赶操作完成后，需要使用指令:MGPRE; 对O2告警进行清除操作;

监听电话流程：
1.定义一个用于监听的号码
EXTPI:BNB1=XXXXXXXXXXX;
2.查看那些DEV处于BUSY状态：
STRSP:R=ALL;
STRDP:R=XXX,STATE=BUSY;
3.启动监听：
MONTI：DEV=MALT-XX;!选状态是BUSY的设备来监听（状态为INCO表示准备占用）
响铃—》按免提监听
CON;
4.监听完成：
END;

AP备份流程：
1.将APG备份做成压缩文件备份到K:\Images(For APG43)或者M:\Images(For APG40)：
burbackup -o

2.将APG备份做到D盘：
burbackup -o -p

3.将D盘压缩做成压缩文件备份到K:\Images(For APG43)或者M:\Images(For APG40)：
burbackup -o -a

Tips:查看AP备份进程：
burbackupstatus

c:\winnt\profiles\cdomc>burbackupstatus
SNGS5AP2A:
Save all disk information and runtime parameter data to file \\SNGS5AP2A\C$\acs\data\BUR\SNGS5AP2A_20150806_034833.ddi completed
Save all disk information and runtime parameter data to file \\SNGS5AP2B\C$\acs\data\BUR\SNGS5AP2B_20150806_034833.ddi completed
Continuing with partition backup please wait
burBackup partition backup completed
2620 directories and 20491 files copied or equal and 0 files locked
SNGS5AP2B:
burBackup partition backup completed
2770 directories and 20700 files copied or equal and 0 files locked
SNGS5AP2A:
burBackup one button backup execution completed
ExitCode : 0

做AP备

份前一般要将D盘清空：
!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!
d:
dir
prcstate&hostname
rmdir d:\ /q /s
!if not ok,then
cacls d:\* /T /E /G Administrators:F
rmdir d:\ /q /s
dir
!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!

如果执行完cacls d:\* /T /E /G Administrators:F 还是有文件删除不了，做个AP倒边，再试一次以上清空D盘的流程。

RL指令吊死：
NOT ACCEPTED
FUNCTION BUSY

1) 闭塞小区（RLSTC:CELL=, STATE=HALTED;)

2）对小区所在TG做TG forlopp release:

a） RXTCP:CELL= , MOTY=RXOTG; 得到TG号

b） RXMOP:MO=RXOTG- ; 得到FID

c）SYFIP:FID= H'xxxx- H'xxxx; 注意前后都有H’

在输出中查找对应行为 “ BLOCK 为RXCMOO，STATUS为ACTIVE1或ACTIVE2， FID-VAR为H'002C 的”，记录下对应行的FILENUM 和 INDIVIDUAL。

d）用以上的信息做下面的指令：

SYFRI:FID= H'xxxx- H'xxxx,block=RXCMOO,FILENUM= ,IND= ;

3)解闭小区（RLSTC:CELL= , STATE=ACTIVE;)

FORLOPP释放不当会引起极其严重的后果，请慎重！