故障集锦.docx
- 文档编号:30377929
- 上传时间:2023-08-14
- 格式:DOCX
- 页数:22
- 大小:30.69KB
故障集锦.docx
《故障集锦.docx》由会员分享,可在线阅读,更多相关《故障集锦.docx(22页珍藏版)》请在冰豆网上搜索。
故障集锦
目录
一.CP部分
二.选组部分
三.RP部分
四.计费部分
五.IOG部分
六.APG部分
七.SIZE
八.设备
九.其他
一.CP
1.近期出现的多个局循环小启的故障
出现故障的现象一般是,自动小启之后十来分钟之后又再小启,通过SYELP指令观察CURRENTERRORINTENSITY参数可以发现小启清零之后很快又上升,当上升到1000的门限值以后有会出现自动小启。
由于检查小启原因往往需要一段时间,为了迅速恢复话务一般的处理方法是做RELOAD解决,由于现在的交换局一般都打开BACKUPTOMS功能,因此RELOAD大概只需要2、3分钟时间,对话务的影响是比较少的。
2.DGEMSC频繁重启故障的处理。
8月下旬,DGEMSC由于硬件故障而频繁发生自动小启,甚至大启的故障相信大家仍然印象深刻,下面介绍一下在处理此故障过程中的一点经验。
此故障最早是出现“COMMONCHARGINGOUTPUTERROR”的告警,且是瞬时的,出了告警后很快又会消失。
根据以往经验,出现这种告警经常是由于用于储存计费文件信息的几个SIZE如466,600和601的CHVIEWBLOCK出现拥塞引起的,于是要求值班人员扩这几个SIZE。
很快值班人员反映这几个SIZE扩到最大了,但仍然偶尔有这个告警出现,可见问题不在SIZE拥塞上。
第二天,DGEMSC开始出现自动小启,原因为“PROGRAMHANDLINGERROR”,且重启的幅度很频繁,有时候会上升到自动大启甚至RELOAD。
用SYELP指令查看,每次重启之前错误值都为0,结合SYRIP指令打印重启的EVENTLOG,可知重启是由于交换机的硬件错误引起的。
从DIRCP指令打印CP的EVENTLOG,可以看出RP1,5,6都有出错。
根据爱立信工程师的建议,首先更换了POWC板(CP33的POWC板R2C一下都有隐患,许多时候硬件错误都是由于POWC板引起,而且POWC板也会参与处理RP到CP的信号),但是没有效果,CP仍然频繁的出现重启。
重新检查交换局的各种状态,偶然的用EXSLP指令检查IOG的LINK的状态,发觉SPG1的LINK1工作不稳定,有时是WO,有时是ABL,这一下就基本知道出现“COMMONCHARGINGOUTPUTERROR”告警的原因了。
因为串行RPBUS是两边RPBUS轮流作为ACTIVE边的,二IOG的LINK实际上就是第一条RPBUS,当LINK1为主用边的时候,若ABL的时间过长就会影响计费文件的生成(此时计费文件存放在CP的内存中),从而出现告警。
用IMALP指令查看IOG的告警就完全证实这种推测:
IMMCT:
SPG=1;
:
IMALP:
NODE=A,FRDATE=040724;
ORDERED
:
END;
EXECUTED
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=
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 故障 集锦