1、网络维护中心监控室 1守望麦田守望麦田 守守 护护 网网 络络目 录一 CP 部分二 选组部分三 RP 部分四 计费部分五 IOG 部分六 APG 部分七 SIZE八 设备九 其他一 CP1近期出现的多个局循环小启的故障出现故障的现象一般是，自动小启之后十来分钟之后又再小启，通过 SYELP 指令观察 CURRENT ERROR INTENSITY 参数可以发现小启清零之后很快又上升，当上升到 1000 的门限值以后有会出现自动小启。由于检查小启原因往往需要一段时间，为了迅速恢复话务一般的处理方法是做 RELOAD 解决，由于现在的交换局一般都打开 BACKUP TO MS 功能，因此 REL
2、OAD 大概只需要 2、3 分钟时间，对话务的影响是比较少的。2DGEMSC 频繁重启故障的处理。网络维护中心监控室 2守望麦田守望麦田 守守 护护 网网 络络8 月下旬，DGEMSC 由于硬件故障而频繁发生自动小启，甚至大启的故障相信大家仍然印象深刻，下面介绍一下在处理此故障过程中的一点经验。此故障最早是出现“COMMON CHARGING OUTPUT ERROR”的告警，且是瞬时的，出了告警后很快又会消失。根据以往经验，出现这种告警经常是由于用于储存计费文件信息的几个SIZE 如 466，600 和 601 的 CHVIEW BLOCK 出现拥塞引起的，于是要求值班人员扩这几个 SIZE
3、。很快值班人员反映这几个 SIZE 扩到最大了，但仍然偶尔有这个告警出现，可见问题不在 SIZE 拥塞上。第二天，DGEMSC 开始出现自动小启，原因为“PROGRAM HANDLING ERROR”，且重启的幅度很频繁，有时候会上升到自动大启甚至 RELOAD。用 SYELP 指令查看，每次重启之前错误值都为 0，结合 SYRIP 指令打印重启的 EVENT LOG，可知重启是由于交换机的硬件错误引起的。从 DIRCP 指令打印 CP 的 EVENT LOG，可以看出 RP1，5，6都有出错。根据爱立信工程师的建议，首先更换了 POWC 板（CP33的 POWC 板 R2C 一下都有隐患，许
4、多时候硬件错误都是由于POWC 板引起，而且 POWC 板也会参与处理 RP 到 CP 的信号），但是没有效果，CP 仍然频繁的出现重启。重新检查交换局的各种状态，偶然的用 EXSLP 指令检查 IOG的 LINK 的状态，发觉 SPG1 的 LINK1 工作不稳定，有时是 WO，有时是 ABL，这一下就基本知道出现“COMMON CHARGING OUTPUT ERROR”告警的原因了。因为串行 RP BUS 是两边 RP BUS 轮流作为 ACTIVE 边的，二 IOG 的 LINK 实际上就是第一条网络维护中心监控室 3守望麦田守望麦田 守守 护护 网网 络络RP BUS，当 LINK1
5、 为主用边的时候，若 ABL 的时间过长就会影响计费文件的生成（此时计费文件存放在 CP 的内存中），从而出现告警。用 IMALP 指令查看 IOG 的告警就完全证实这种推测：IMMCT:SPG=1;:IMALP:NODE=A,FRDATE=040724;ORDERED:END;EXECUTED SPS EVENT LOGSPG NODE FR DATE FR TIME TO DATE TO TIME MINCOD MAXCOD1 A 2004-07-24 000000 2004-08-11 224623 1 9999 * OBSERVATION O1/2 2004-07-28 185313I
6、OP SLOGAN NOT DEFINEDCODE SPG NODE UNIT INFO5507 1 A RPVDR.AC2 RPV DUMP FAILED(4078) ADD INFO:Open main file error* OBSERVATION O1/2 2004-07-28 185313IOP SLOGAN NOT DEFINEDCODE SPG NODE UNIT INFO5500 1 A RPVDR CP-SP link disconnectedADD INFO:TRANSCODE IDNO0 4649 SENDER : REGION NODE UNIT IDNO0 17 RP
7、VDR.AC2 4649 * OBSERVATION O1/2 2004-07-28 185426IOP SLOGAN NOT DEFINEDCODE SPG NODE UNIT INFO5500 1 A RPVDR CP-SP link disconnectedADD INFO:TRANSCODE IDNO0 4636 SENDER : REGION NODE UNIT IDNO0 17 RPVDR.AC2 4636 网络维护中心监控室 4守望麦田守望麦田 守守 护护 网网 络络* OBSERVATION CEASING O1/2 2004-07-28 185433IOP SLOGAN NO
8、T DEFINEDCODE SPG NODE UNIT INFO5500 1 A RPVDR CP-SP link connectedADD INFO:TRANSCODE IDNO0 4668 SENDER : REGION NODE UNIT IDNO0 17 RPVDR.AC2 4668 * OBSERVATION O1/2 2004-07-28 185439IOP SLOGAN NOT DEFINEDCODE SPG NODE UNIT INFO5500 1 A RPVDR CP-SP link disconnectedADD INFO:TRANSCODE IDNO0 4636 SEND
9、ER : REGION NODE UNIT IDNO0 17 RPVDR.AC2 4636 从以上的 LOG 可以看出，每隔几秒就出现一次“CP-SP link disconnected”的告警。到此时，故障原因已经非常清楚了，是由于RP BUS 的工作不稳定引起的，在 CP 中，负责 RP BUS 工作的有POWC，SPU 和 RPIRS 板，首先更换 SPU，更换后再用 IMALP 检查 IOG 的告警，仍然有上述告警出现。再更换第一块 RPIRS 板后问题仍然存在，可见问题不在 CP 上，所以需要更换 IOG 上 RPV2，即 IOG 跟 CP 连接的 RP。由于工作不稳定的是 SPG1
10、 的 LINK1，所以直接更换 NODE B 的 RPV2 板，更换后再查看 LINK 的状态和IOG 的告警，状态正常，问题得到解决。从这次故障中，有以下几点经验值得总结： 在故障过程中，曾经由于无法生成计费文件而导致计费停止的故障，值班人员按照经验打开 SPG0 上的计费文件，但网络维护中心监控室 5守望麦田守望麦田 守守 护护 网网 络络由于在打开前没有检查清楚，结果打开的仍然是 SPG1 上的TTFILE，然后再打开 SPG0 上的文件结果计费文件仍然无法生成，在把 SPG1 上的 TTFILE 全部关闭后才正常生成计费文件。根据以往的经验，同时打开两个 TTFILE 是可以正常生成计
11、费信息的，从这次操作可以看出，同时打开三个 TTFILE 有可能导致不能正常生成计费信息。所以以后若出现 SPG1 故障要打开 SPG0 的 TTFILE 时，一定要确认清楚要打开的TTFILE 是在 SPG0 上。 在知道故障原因是由于 SPG1 的 LINK1 不稳定造成时，应该及时人工闭塞这条 LINK，这样做不能避免 CP 的RESTART，当时有可能能够避免出现计费生成错误的告警，从而避免上文提到的计费停止的故障。 串行 RP BUS 中，一个简单的 RP 故障都很有可能影响到 CP 的稳定运行，这在以往的多次故障中都得到验证，必须加以重视。而在处理这次故障中，使用 IMALP 指令
12、检查 IOG的 EVENT 则是发现故障原因的重要工具，尤其是更换完硬件以后，我们无法即时判断 CP 是否仍然会发生重启，而从此EVENT LOG 则可以即时发现 CP 与 IOG 的连接是否正常，从而判断更换硬件后故障是否消除。3DGBHLR 的 IPU 板型号不一致。CP_A 边的 IPU 版本为R2B， CP_B 的 IPU 版本为 R3E，CP 的状态为 CP_A 为 EX,CP_B为 HALT,需要把两边的 IPU 版本更换为一致的电路板。这个故障的经过两次抢修，两次都具有一定的借鉴意义。原来的 DGBHLR 在起局的时候， IPU 电路板两边的版本都是一致，为R2B。由于 CP_B
13、 的 IPU 板出现故障，CP_B 的状态为 halt,需要把有网络维护中心监控室 6守望麦田守望麦田 守守 护护 网网 络络故障的 CP_B 的 IPU 电路板更换，爱立信提供的只是 R3E 版本的IPU 板，R2B 版本的 IPU 电路板已经停产，省公司和爱立信都没有这个型号的存货。为了使交换机尽快恢复正常状态，抢修人员只好决定更换 R3E 的 IPU，REMCI 指令对 IPU 板进行干预后更换电路板，然后 RECCI 指令检测并边，却发现并边不成功。因为DGBHLR 是从 CP30 升级为 CP33，从升级工程的过程可知，在硬件方面需要更换 IPU 和 POWC 两类型的电路板，显示
14、IPU 和 POWC电路板的关系密切。Ptiti,抢修人员尝试对 POWC 电路板进行REMCI 干预，然后并边，依然不能成功。再次尝试对 IPU 和POWC 电路板一起干预，然后 RECCI 修复，经过一段较长的时间UPDATE,终于并边成功， CP 状态转为正常，系统正常。经过一段时间，其他兄弟公司出现了由于 CP 的电路板版本号不一致引起的故障，显然 DGBHLR 存在故障隐患。安排对 DGBHLR做 TEST LOADING 测试，在 DPPAI 并边时候，发现 CP 并边不成功，接着系统发生自动 RELOAD，LOAD RELFSW0 文件，并且RELOAD 不成功，DGBHLR 到
15、各端局信令链中断，CP 不能通信，此时备份的 DGEHLR 承担 DGBHLR 的工作。抢修人员对系统进行干预处理，按下 PHCI 阻止循环 RELOAD，闭塞各端局到 HLR2 的信令链和 DEST，然后进入 CPT 模式，用 PTSRI 直接把 RELFSW2文件（当晚做了最新的 DUMP）通过 LINK1 LOAD 入执行边 CP，持续一个多小时后，RELOAD 成功，解开信令链和 DEST。这时DGBHLR 可以正常运行。虽然 DGBHLR 可以运行，但是此时的 DGBHLR 的 CP_A 是执行状态，IPU 板版本 R2B;CP_B 是 HALT 状态,IPU 版本为 R3E。原网络
16、维护中心监控室 7守望麦田守望麦田 守守 护护 网网 络络则上有两种方案可以解决问题: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 的转换，分离这些操作。抢修人员经过考虑，鉴于
17、先前做 TEST LOADING的时候，使用 DPPAI 并边指令，导致系统循环 RELOAD，所以用RECCI 指令检测并修复，结果 UPDATE 不成功。根据维护经验，可以使用 REPCI，检测 CP 故障，可以使系统自检，CP 恢复正常状态，然后 REPCE 中断后面的检测和修复指令，直接 DPSWI 转换 CP 的EX 边， REMCI 干预 CP_A 的 IPU 板，接着更换 IPU 板并 RECCI 修复并边成功，至此，故障抢修成功。网络维护中心监控室 8守望麦田守望麦田 守守 护护 网网 络络二 RP1MMSC 出现 CP FAULT 及 RP BUS FAULT。此故障是由于一
18、个 RP-4 的硬件错误导致 RP BUS FAUTL 及 CP FAULT，出现硬件错误的是 RP 102，位于 A 边的 BUS，却导致 B边的 RP BUS FAULT，导致我们无法更换此 RP，因为更换此 RP 要断开 A 边的 RP BUS，将会导致 32 个 RP 无法工作。我们采取的办法是在 B 边的 RP BUS 另找一根线，把 RP 102 所在的机框的上下两个机框直接连起来，让 RP BUS 跳过这个机框，排除 RP 102 的影响。用 TEST SYSTEM 的方法可以看到，这样做后 B 边的 RP BUS 已经恢复正常，这样就可以用正常的方法更换 RP 102，然后再把
19、 B 边的RP BUS 恢复原状就彻底解决故障了。2DGDBSC1 出现 MANY RP FAULT，并伴随瞬间负荷过高。DGDBSC1 在 18：31 分出现了 RP FAULT 群告警，同时导致十多个小区的基站倒掉，在指令修复 RP 后，小区依然不能恢复正常，在 19：24 分对 DBSC1 做了一个小启后，小区逐渐恢复正常。并且在 DGIBSC1 等几个 BSC 也出现在 18:30 左右也有大量 RP 自动ABL 的问题。这些 RP 都是用于 TRH 设备的 RPG2。经分析，发现有两个因素导致了这个问题，一是这个局的 TRH 设备资源比较紧张，这些用于 TRH 的 RP 本身的负荷已
20、经比较高（可以用 MERPI 指令测量 RP 的负荷，经过对比，发现 D1 局的用户 TRH 的 RPG2 的负荷比 D2 局的要高很多）。二是无线室在每天的 18：30 会启动一个程序，此程序会让所有 TRH 向用户发送信息，这样就导致了许多RPG2 负荷过高而出现 RP FAULT 甚至自动闭塞。在无线室停止了这个程序以后就没有再出现过这个问题了。但最后解决问题则要通过 TRA 设备的扩容。网络维护中心监控室 9守望麦田守望麦田 守守 护护 网网 络络三 选组级1用 GSCVP 指令打印时钟控制值偏差太大。一般来说，BYB501 和 202 设备的标准值为 2048，根据爱立信的建议，相差
21、 400 范围内是可以接受的。如果超过 400 则需更换硬件，在 BYB202 硬件中，需更换的是 CLG3 板。BYB501 设备中，需更换的 CLB 板。2GROUP SWITCH FAULTa GSBLI 闭该选组b GSTEI 测试，如果结果为“NO FAULTS”，则进行第 d步；否则对测试结果显示的坏板逐一更换，再进行下一步；c replace bord ；d GSBLE；e GSSTP。3TSM-B-49 ABL 指令修复不成功，请处理。选组包括了三类单元：时钟模块（CLM）,时分模块（TSM ）,和空分模块（SPM ）。三者密切相连，所以我们处理故障的时候不能只是着眼于出现故障
22、的模块单元，应该从整体上考虑观察。这个例子很好的体现了这一点。DGAMSC 的选组 TSM-B-49 出现了 ABL 状态，人工闭塞后检测显示结果为 FCODE0，Clock distribution fault，即发送来的时钟信号错误。再使用 GSSTP 看所有的选组(CLM,TSM,SPM)状态，除这个 TSM 外其他都是正常；使用 GSCVP 看时钟模块的主控值，SLAVE 状态的 CLM-0 为，CLM2 为 ，而主控 MASTER 的CLM-2 为 2325，偏离标准值 2048 较大。把 CLM-2 人工闭塞，系统网络维护中心监控室 10守望麦田守望麦田 守守 护护 网网 络络自动比较 CLM-0 和 CLM-2 的控制值，选了接近 2048 标准值的CLM-2。这个时候再次检测 TSM-B-49,可以通过，恢复正常状态。再解闭 CLM-1，也可以通过。再次检查选组的状态，都恢复了正常。为了消除故障隐患，后来我们把这个偏离标准主控值大的 CLM 硬件更换，此类故障就没有再出现了。
