SPGNODEFRDATEFRTIMETODATETOTIMEMINCODMAXCOD
1A2004-07-240000002004-08-1122462319999
***OBSERVATIONO1/22004-07-28185313
IOPSLOGANNOTDEFINED
CODESPGNODEUNITINFO
55071ARPVDR.AC2RPVDUMPFAILED（4078）
ADDINFO:
Openmainfileerror
***OBSERVATIONO1/22004-07-28185313
IOPSLOGANNOTDEFINED
CODESPGNODEUNITINFO
55001ARPVDRCP-SPlinkdisconnected
ADDINFO:
TRANSCODEIDNO
04649
SENDER:
REGIONNODEUNITIDNO
017RPVDR.AC24649
***OBSERVATIONO1/22004-07-28185426
IOPSLOGANNOTDEFINED
CODESPGNODEUNITINFO
55001ARPVDRCP-SPlinkdisconnected
ADDINFO:
TRANSCODEIDNO
04636
SENDER:
REGIONNODEUNITIDNO
017RPVDR.AC24636
***OBSERVATIONCEASINGO1/22004-07-28185433
IOPSLOGANNOTDEFINED
CODESPGNODEUNITINFO
55001ARPVDRCP-SPlinkconnected
ADDINFO:
TRANSCODEIDNO
04668
SENDER:
REGIONNODEUNITIDNO
017RPVDR.AC24668
***OBSERVATIONO1/22004-07-28185439
IOPSLOGANNOTDEFINED
CODESPGNODEUNITINFO
55001ARPVDRCP-SPlinkdisconnected
ADDINFO:
TRANSCODEIDNO
04636
SENDER:
REGIONNODEUNITIDNO
017RPVDR.AC24636
从以上的LOG可以看出，每隔几秒就出现一次“CP-SPlinkdisconnected”的告警。
到此时，故障原因已经非常清楚了，是由于RPBUS的工作不稳定引起的，在CP中，负责RPBUS工作的有POWC，SPU和RPIRS板，首先更换SPU，更换后再用IMALP检查IOG的告警，仍然有上述告警出现。
再更换第一块RPIRS板后问题仍然存在，可见问题不在CP上，所以需要更换IOG上RPV2，即IOG跟CP连接的RP。
由于工作不稳定的是SPG1的LINK1，所以直接更换NODEB的RPV2板，更换后再查看LINK的状态和IOG的告警，状态正常，问题得到解决。
从这次故障中，有以下几点经验值得总结：
●在故障过程中，曾经由于无法生成计费文件而导致计费停止的故障，值班人员按照经验打开SPG0上的计费文件，但由于在打开前没有检查清楚，结果打开的仍然是SPG1上的TTFILE，然后再打开SPG0上的文件结果计费文件仍然无法生成，在把SPG1上的TTFILE全部关闭后才正常生成计费文件。
根据以往的经验，同时打开两个TTFILE是可以正常生成计费信息的，从这次操作可以看出，同时打开三个TTFILE有可能导致不能正常生成计费信息。
所以以后若出现SPG1故障要打开SPG0的TTFILE时，一定要确认清楚要打开的TTFILE是在SPG0上。
●在知道故障原因是由于SPG1的LINK1不稳定造成时，应该及时人工闭塞这条LINK，这样做不能避免CP的RESTART，当时有可能能够避免出现计费生成错误的告警，从而避免上文提到的计费停止的故障。
●串行RPBUS中，一个简单的RP故障都很有可能影响到CP的稳定运行，这在以往的多次故障中都得到验证，必须加以重视。
而在处理这次故障中，使用IMALP指令检查IOG的EVENT则是发现故障原因的重要工具，尤其是更换完硬件以后，我们无法即时判断CP是否仍然会发生重启，而从此EVENTLOG则可以即时发现CP与IOG的连接是否正常，从而判断更换硬件后故障是否消除。
3．DGBHLR的IPU板型号不一致。
CP_A边的IPU版本为R2B，CP_B的IPU版本为R3E，CP的状态为CP_A为EX,CP_B为HALT,需要把两边的IPU版本更换为一致的电路板。
这个故障的经过两次抢修，两次都具有一定的借鉴意义。
原来的DGBHLR在起局的时候，IPU电路板两边的版本都是一致，为R2B。
由于CP_B的IPU板出现故障，CP_B的状态为halt,需要把有故障的CP_B的IPU电路板更换，爱立信提供的只是R3E版本的IPU板，R2B版本的IPU电路板已经停产，省公司和爱立信都没有这个型号的存货。
为了使交换机尽快恢复正常状态，抢修人员只好决定更换R3E的IPU，REMCI指令对IPU板进行干预后更换电路板，然后RECCI指令检测并边，却发现并边不成功。
因为DGBHLR是从CP30升级为CP33，从升级工程的过程可知，在硬件方面需要更换IPU和POWC两类型的电路板，显示IPU和POWC电路板的关系密切。
Ptiti,抢修人员尝试对POWC电路板进行REMCI干预，然后并边，依然不能成功。
再次尝试对IPU和POWC电路板一起干预，然后RECCI修复，经过一段较长的时间UPDATE,终于并边成功，CP状态转为正常，系统正常。
经过一段时间，其他兄弟公司出现了由于CP的电路板版本号不一致引起的故障，显然DGBHLR存在故障隐患。
安排对DGBHLR做TESTLOADING测试，在DPPAI并边时候，发现CP并边不成功，接着系统发生自动RELOAD，LOADRELFSW0文件，并且RELOAD不成功，DGBHLR到各端局信令链中断，CP不能通信，此时备份的DGEHLR承担DGBHLR的工作。
抢修人员对系统进行干预处理，按下PHCI阻止循环RELOAD，闭塞各端局到HLR2的信令链和DEST，然后进入CPT模式，用PTSRI直接把RELFSW2文件（当晚做了最新的DUMP）通过LINK1LOAD入执行边CP，持续一个多小时后，RELOAD成功，解开信令链和DEST。
这时DGBHLR可以正常运行。
虽然DGBHLR可以运行，但是此时的DGBHLR的CP_A是执行状态，IPU板版本R2B;CP_B是HALT状态,IPU版本为R3E。
原则上有两种方案可以解决问题:
1.把两边的IPU板换为R2B版本；2.把两边的IPU板换为R3E版本。
方案一直接把R2B的IPU板更换到CP_B就可以成功。
方案二需要把执行边倒回到CP_B，然后更换CP_A型号为R2B的IPU板，难度较大。
方案一简单容易，但由于没有R2B型号的IPU板，抢修人员只能使用第二种方案。
使用第二种方案，首先要使CP状态回复正常，即CP_A为EX，CP_B为WO/SB,因为只有在正常状态下，才可以做CP的转换，分离这些操作。
抢修人员经过考虑，鉴于先前做TESTLOADING的时候，使用DPPAI并边指令，导致系统循环RELOAD，所以用RECCI指令检测并修复，结果UPDATE不成功。
根据维护经验，可以使用REPCI，检测CP故障，可以使系统自检，CP恢复正常状态，然后REPCE中断后面的检测和修复指令，直接DPSWI转换CP的EX边，REMCI干预CP_A的IPU板，接着更换IPU板并RECCI修复并边成功，至此，故障抢修成功。
二．RP
1．MMSC出现CPFAULT及RPBUSFAULT。
此故障是由于一个RP-4的硬件错误导致RPBUSFAUTL及CPFAULT，出现硬件错误的是RP102，位于A边的BUS，却导致B边的RPBUSFAULT，导致我们无法更换此RP，因为更换此RP要断开A边的RPBUS，将会导致32个RP无法工作。
我们采取的办法是在B边的RPBUS另找一根线，把RP102所在的机框的上下两个机框直接连起来，让RPBUS跳过这个机框，排除RP102的影响。
用TESTSYSTEM的方法可以看到，这样做后B边的RPBUS已经恢复正常，这样就可以用正常的方法更换RP102，然后再把B边的RPBUS恢复原状就彻底解决故障了。
2．DGDBSC1出现MANYRPFAULT，并伴随瞬间负荷过高。
DGDBSC1在18：
31分出现了RPFAULT群告警，同时导致十多个小区的基站倒掉，在指令修复RP后，小区依然不能恢复正常，在19：
24分对DBSC1做了一个小启后，小区逐渐恢复正常。
并且在DGIBSC1等几个BSC也出现在18:
30左右也有大量RP自动ABL的问题。
这些RP都是用于TRH设备的RPG2。
经分析，发现有两个因素导致了这个问题，一是这个局的TRH设备资源比较紧张，这些用于TRH的RP本身的负荷已经比较高（可以用MERPI指令测量RP的负荷，经过对比，发现D1局的用户TRH的RPG2的负荷比D2局的要高很多）。
二是无线室在每天的18：
30会启动一个程序，此程序会让所有TRH向用户发送信息，这样就导致了许多RPG2负荷过高而出现RPFAULT甚至自动闭塞。
在无线室停止了这个程序以后就没有再出现过这个问题了。
但最后解决问题则要通过TRA设备的扩容。
三．选组级
1．用GSCVP指令打印时钟控制值偏差太大。
一般来说，BYB501和202设备的标准值为2048，根据爱立信的建议，相差400范围内是可以接受的。
如果超过400则需更换硬件，在BYB202硬件中，需更换的是CLG3板。
BYB501设备中，需更换的CLB板。
2．GROUPSWITCHFAULT
a．GSBLI闭该选组
b．GSTEI测试，如果结果为“NOFAULTS”，则进行第d步；
否则对测试结果显示的坏板逐一更换，再进行下一步；
c．replacebord；
d．GSBLE；
e．GSSTP。
3．TSM-B-49ABL指令修复不成功，请处理。
选组包括了三类单元：
时钟模块（CLM）,时分模块（TSM）,和空分模块（SPM）。
三者密切相连，所以我们处理故障的时候不能只是着眼于出现故障的模块单元，应该从整体上考虑观察。
这个例子很好的体现了这一点。
DGAMSC的选组TSM-B-49出现了ABL状态，人工闭塞后检测显示结果为FCODE＝0，Clockdistributionfault，即发送来的时钟信号错误。
再使用GSSTP看所有的选组（CLM,TSM,SPM）状态，除这个TSM外其他都是正常；使用GSCVP看时钟模块的主控值，SLAVE状态的CLM-0为，CLM－2为，而主控MASTER的CLM-2为2325，偏离标准值2048较大。
把CLM-2人工闭塞，系统自动比较CLM-0和CLM-2的控制值，选了接近2048标准值的CLM-2。
这个时候再次检测TSM-B-49,可以通过，恢复正常状态。
再解闭CLM-1，也可以通过。
再次检查选组的状态，都恢复了正常。
为了消除故障隐患，后来我们把这个偏离标准主控值大的CLM硬件更换，此类故障就没有再出现了。
四．计费
1．在计费检查时CHECK_TTFILE出现文件不连续的提示的处理。
不论任何原因产生的计费文件不连续情况都有可能导致计费文件的拥塞从而导致计费停止，必须引起足够的重视。
出现文件序列不连续的情况一般有两种：
a）由于更改了文件的删除时间而导致的不连续。
更改了文件的删除时间后，新生成的文件会按照新的定义时间自动删除，而之前生成的仍然会按照旧的定义时间自动删除，这样就会由于删除时间的不一致而导致部分文件不连续，这种情况属于正常情况，经过两三天更改删除时间之前生成的文件全部删除后就不会出现。
出现这种情况不用处理但一定要记得继续观察。
b）除上一种情况而出现的计费文件不连续，最终都会导致计费的拥塞，必须要人工删除不连续的文件。
用以下指令检查
INFSP:
FILE=TTFILExx,DEST=CHARINGxx；
再用INFIP：
FILE=TTFILExx指令与硬盘上的文件比较，只要是硬盘上有的而用INFSP指令查看没有的文件，都不会自动删除，需要人工删除这些文件。
2．COMMONCHARGINGOUTPUTERROR和CHARGINGVIEWSORLOGSCONGNSTION告警的处理
出现此两个告警的原因是SAE466或SAE600，601的CHVIEWBLOCK出现拥塞引起，因为每成功接续一个通话，都会占用以上每个SAE的至少一个NI，所以任何一个SAE拥塞都会造成计费拥塞，从而无法建立新的通话。
处理办法就是扩SIZE，以上几个SIZE都可以直接用SAALI指令扩。
3．计费文件传送到立信终端失败，需要人工传送。
现在网元存在IOG和APG两类型的设备，所以需要分两类型来描述：
a）IOG:
基本上分打印当前计费做到的文件号，看已经发送和未发送的子文件序号，传送计费文件到立信，最后确认传送成功的四个步骤。
假设打开的计费指针为ttfile01,计费文件号用xxxx来代替,DEST=GSMLINK，以下为对应的四个步骤：
A．IOIFP:
FILE=TTFILE01;
B．INFSP:
FILE=TTFILE01,DEST=GSMLINK;
C．INFTI:
FILE=TTFILE01-xxxx,DEST=GSMLINK;
D．INFSP:
FILE=TTFILE01,DEST=GSMLINK;
b）APG:
由于AP2的计费文件是主动送立信公司，不能传送计费文件一般都是AP2发生了故障，抢修人员把计费文件改为在AP1上生成。
例子为把AP1的TTFILE00目录下的计费文件传送到AP2,再传送至立信计费公司。
步骤如下：
I）得到AP2ACTIVENODENAME（egdgg25map2a）
II）在AP1上执行（AP模式）：
C:
\>cd/dL:
\FMS\data\CPF\CALLVOLUME\TTFILE00
III）在AP1上FTPTOAP2
FTPdgg25map2a
FTP>cdacs
FTP>mkdirttfile00
FTP>mput*.*（“Y”forconfirmthecommand）
五．IOG
1．DGCHLR出现VOLUMELIMITEXCEEDED告警,VOL=RELVOLUSW。
RELVOLUMSW这个VOLUME一般存放的是RELFSW文件和COMMANDLOG（简称CLOG）文件。
多数情况下出现这样的告警是因为RELFSW文件过大从而导致告警出现，但在本故障中，检查发现CLOG文件从开局到故障发生时都没有删除过，光是TLOG文件就占了几百兆。
一般情况下CLOG文件应该定义一个FPU功能，让文件自己能够定期删除（一般定为30天）。
以后遇到此类故障时可以检查一下是否有太多的CLOG文件堆积。
2．SPG=0,VOL=OMFZLIBORD出现VOLUMELIMITEXCEEDED告警。
OMFZLIBORDVOLUME用于存放SP的系统文件。
一般来说，当SP运行起来后，只要不是进行软件升级，系统文件都不会有什么改变，因此此VOLUME也很少会出现这样的告警。
例外的是当我们进行TLOG的搜索的时候，系统会在此VOLUME生成一个名为TLSCRESULT的文件（文件名可能有出入），此文件会记录TLOGSEARCH的结果，如果搜索TLOG的范围太大，如日期很多，使用参数“COMMAND=ALL”等，因为结果输出会很多，就会导致此文件太大而产生告警。
此文件无法人工删除，TLOG搜索完了以后会自动删除，一般第二天告警就会自动消除。
3．MANUALEXECTIONOFCOMMANDLOGREQUIRED告警
出现此告警是因为交换局经过人工RELOAD后产生的。
人工RELOAD后，因为RELOAD所用的备份文件不可能与数据同步，在两次备份文件之间的数据变化系统存在COMMANDLOG中。
在执行完人工RELOAD后，由于可能用于RELOAD的在备份文件生成之后可能有数据变化，就需要执行COMMANDLOG以免数据丢失。
执行COMMAND的指令是IOCMI。
（小心执行，因为可能COMMAND中含有RESTART等危险指令）如果确认无什么数据变化无需执行COMMANDLOG可以用SYLAE指令消除告警。
另外，COMMANDLOG文件不是一个无穷大文件,所以要跳到下一个子文件不能采用指令:
IOIFE:
FILE=;没有REMOVE时间,也没有DUMP=YES/NO的无穷大属性,没有连接DEST；也不能通过SYCLE去活COMMANDLOG功能来实现跳到下一个子文件。
因为COMMANDLOG是在LARGEBACKUP后产生一个新的子文件，所以为了能产生一个子文件,可以通过SYCSI:
SFN=XXXXXXX;如果在INFIP:
FILE=RELCMDHDF;中存在你需要产生的子文件,则只要用SYCSI;的格式激活即可。
4．COMMANDLOGBLOCKED
指令SYCLI;打开COMMANDLOG
5．SPLINKFAULT
先用BLSLE:
SPG=,LINK=;解开，EXSLP看link状态。
如果链路还是FAULT，则需要更换RPV/RPV2板，其对应RP位置为
SPG0
SPG1
LINK0
RP=1
RP=5
LINK1
RP=4
RP=6
6．SPTRACESYSTEMINACTIVE
首先打印IOGRESTART数据以清空内存SPTRACESYSTEM
IMMCT:
SPG=;
IMRDP：
NODE=;
IMTSI:
MODE=SIG,NODE=;
END;
7．SPTRANSIENTFAULTSUPERVISION
一般为临时故障。
BLSNI:
SPG=,NODE=;
RESUI:
SPG=,NODE=;
BLSNE:
SPG=,NODE=;
8．CommandLog的读取，载入
IOFAT:
FILE=;查看CommandLog内容
IOCMC:
STATE=PASSIVE;
IOCMI:
FILE=,[PROC=E];载入
IOCMC:
STATE=ACTIVE;
9．SPUNITFAULT
BLSNI:
SPG=,NODE=;闭塞NODE
RESUP:
SPG=,NODE=;查看NODE故障，如果有硬件故障
则更换。
RESUI:
SPG=,NODE=;修复
BLSNE:
SPG=,NODE=;解开NODE
10．只有P指令能够出结果，其他指令不能输出结果。
指令分为SP指令,CP指令和CPT指令。
所有指令都经过IOG送给CP。
如果是SP指令，则通过入口指令送给CP，CP根据入口指令送给相应的IOG子系统处理；如果是CP指令，则由CP处理，将printout送到SP，在终端输出；如果是CPT指令（在LocalMode模式下），则通过CPU60的LocalPort送给MAU执行，结果经过相同路径返回。
一般情况下，只有P指令输出结果或者所有结果要order的指令不能输出结果，是因为IOG的SPS子系统相关功能块吊死导致，对IOG作smallresrart即可回复正常。
IMMCT:
SPG=;
IMCSP;查看EX/Sbnode的状态
END;
BLSNI:
SPG=,NODE=;闭塞SBnode
SYRSI:
RANK=small，EXPL=other；
在EXnode作smallrestart，之后会出现短暂的连不上机，属正常情况。
待能够连上机后，解开SBnode。
BLSNE:
SPG=,NODE=;
11．DGJBSC1出现了VOLUMELIMITEXCEEDED告警，提示在SPG=0,VOL=OMFZLIBORD出现的告警。
一般来说，出现VOLUME超出LIMIT值的情况是在VOL=CALLVOLUME，由计费文件生成太快或拥塞所致。
或者在VOL=RELVOLUMSW,系统备份文件太大引起。
在SPG=0,VOL=
升级会员 