全国爱立信GSM设备典型案例分析与维护经验汇总
一、交换网 (2)
1.1 APG40容量过小的处理 (2)
1.2 关于告警板问题经常需插拨ALCPU板问题报告 (5)
1.3 APG40计费冗余实现方案 (12)
1.4 各种Forlopp吊死 (12)
1.5 手机激活CLIR（主叫隐藏）功能导致主叫失败的说明 (13)
1.6 APG40历史告警 (13)
1.7 Infinite文件虚假告警 (14)
1.8 功能块ALA产生大量FORLOPP的调查研究 (14)
1.9 APG系统告警较多、帐号管理不方便问题 (18)
1.10 AP node故障和SCSI RAID磁盘故障 (19)
1.11 省际彩铃呼叫提示号码不完整或无法听彩铃问题 (20)
1.12关于串话、单通问题的专题分析 (21)
1.13漏话故障处理 (25)
1.14外省拨叫广东彩铃用户听到“未能接通”的通知音 (28)
1.15例行小启引起CP FAULT原因分析 (29)
1.16爱立信端局G17覆盖下的大量用户出现被叫不通分析 (35)
1.17爱立信网元TCP/IP连接中断故障分析 (37)
1.18关于用户取消来电显示后无法正常做被叫的案例分析 (39)
1.19爱立信HLR21 CP内存故障处理经验 (41)
1.20交换机A接口信令中断处理 (46)
1.21移动客户话单中位置小区号和交换机代码不符合问题分析 (49)
1.22爱立信端局短信延迟的处理 (55)
1.23市话拨打移动手机回声有严重回声问题解决 (57)
1.24SYMSC12神州行用户查询亲情号码时播报次序号混乱 (60)
1.25爱立信交换机软件故障处理报告 (68)
二、无线网 (70)
2.1 CZBS6&7 时隙闭塞问题 (70)
2.1 爱立信设备串短信问题分析 (71)
一、交换网
1.1 APG40容量过小的处理
z来源：江苏
z问题描述：
C盘的空间配置太小,经常出现磁盘空间不够的告警；K：L：设计空间过小，有时也会出现关
于容量太小的告警。
故障分析：
目前，硬盘容量的大小，在APG40出厂时已确定；而APG40在长期的运行过程中，会产生大
量的文件，如增加一个用户，就会给其分配相应的配置文件要占用一部分空间；还有一些是在系统
运行过程中产生的LOG文件，如CMD LOG，ALOG等等，另外一个就是系统备份文件。
特别是增加用户的原因，目前在苏州为了加强用户帐权限的管理，分配了一些不同权限的用户
帐号占用了一部分C盘的容量。
针对上述原因，一方面我们向爱立信APG40设计部门提出针对本故障提出相应的意见；另一
方面我们从维护角度考虑，提出下述意见。
z问题处理
A、C：盘空间的维护
检查C:\TEMP目录，该目录是用于存放AP升级用的临时文件以及系统生成的一些记录文件。
该目录下的文件是可以随时清除的，不会给系统正常运行带来影响，最好不要在该目录存放文件。
cd /d C:\TEMP
rd . /s /q
由于APG40的FTP服务器会将一些传送文件作为CACHE留在c:\winnt\profile\….的某些子目
录中，典型的文件是病毒库文件（eg. inort.exe），会占用很多空间。
dir /s c:\winnt\profiles del /s c:\winnt\profiles\*.exe
del /s c:\winnt\profiles\*.zip
有的进程出现软件错误时，会生成一个DEBUG文件，该文件有时会占用很大空间
del c:\winnt\user.dmp
检查event log。如果某个事件（Application, System, Security）的LOG太大，占用20、30MB
空间，可以用PCanywhere登录该Node，打开event viewer, 然后打开相应的事件，并选用“清除历
史记录”选项.
dir c:\winnt\system32\config\*.evt
检查 c:\acs\data\ftp, 该目录是对应ACS的虚拟目录。在该目录下，有可能有一些放到ACS虚拟
目录的临时文件，另外在mktr目录中，存放每次做好mktr的压缩文件
dir c:\acs\data\ftp\* /s
del c:\acs\data\ftp\*.zip /s
检查 FTP 服务器的日志文件, 看是否占用很多空间，原则上所有日志文件都可以删除，除了正
在使用中的以外。
del C:\winnt\system32\LogFiles\*.log /s
查看C:垃圾箱中是否有未彻底删除的垃圾文件。
cd /d c:\Recylcer
del * /s
查看 c:\acs\logs\core, 删除名字以core.unknown开始的文件, 但保留 drwtsn32.log
dir c:\acs\logs\core
del c:\acs\logs\core\core.unkonw.*
从c:\winnt\ now路径,删除所有的Hotfix Uninstall directories目录. 这些目录的名字是“$NTUninstall*$”,其中“*”表示路径名字. 这些全是不在使用的备份文件.
临时的virus signature upgrade文件“*nt86*.exe”应该删除. 它们位于c:\winnt\profiles\XXXX\Temporary Internet Files\.目录下，其中XXXX为用户名。
B、K:盘空间的维护
ALOG
存在于K:\ACS\logs\ALOG\logfile目录中，记录的是所有输入系统的指令（CP和AP），系统产生的告警和EVENT。一般地，这些文件也被要求传送到OSS，并在APG40上保存一定时间（7天）。这个目录中文件的格式为Logfile-2005-01-02-0001，指明了日志文件的生成日期。日志文件的管理有两种方式。一种是可以指定总空间的占用门限。缺省值为100MB。当日志文件的总和超过100MB，最老的文件就被删除掉。一种是指定保存的最长期限，超过期限的日志文件将被自动清除。一般的，HLR的APG40中ALOG文件会比较大，因为HLR的用户数据操作指令比较多。如果指定保存期限，APG40就不会理100MB的限制条件去保存文件了。实际保存文件的总数可能比100MB小，也可能比100MB大。
待传，或未被传送的统计文件
在K:\AES\data\cdh\ftp\OSSDESTx\ready（x=1,2,3…）中，保存所有以RESPONDING方式待传送的统计文件，包括STS和TRARFILE和TRDIPFILE等。由于系统REBOOT或其他原因导致的文件传送失败，这些待传送的文件没有被及时清除，以垃圾的形式存在于上述目录中。一般地，首先确认上述文件是否仍然需要，如果时间太久，统计的信息不再有时效性，则可以将他们直接删除或者从Ready目录挪到Delete目录中。否则将它们拷贝回其原来所在的目录，用手工的方式（afpfti）重新传送。
APG40的系统备份
AGP40的系统备份是将两个NODE的系统压缩以ZIP文件的形式存放于K:\Images\nodea(nodeb)\中。一般的，根据现有K:盘空间的配置，最多可以存放两套APG40的系统备份，共4个ZIP文件，每个文件约430－450MB大小。如果要作多一套备份，请即时删除最老的一套备份。
本地告警输出备份
有的局有配置了告警输出到本地终端。那么在本地在K:\MCS\logs\PDS会生成AD-xxxx.log的文件。由于这类文件不会自动删除，所以如果其数量过大，请酌情删除老的文件。一般地，我们不鼓励在本地保存告警输出，因为APG40内置的AUDIT LOG功能已经保存有各类告警的信息，并且支持搜索和空间自动管理。删除本地告警输出的设置，请作：
C:\>cpdlist -l
DEVICE SEP TYPE TIME STATE QPRT PRCA PARAMETER
AD-1023 No File 0 Idle 0 0-255 -f .
C:\>cpdremove AD-1023
并清空CP的IO路由表
….. C、L:盘空间的维护 L盘存放CP软件的备份以及基站软件等。一般地，MSC和BSC的APG40有足够的空间存放上述文件。但对于HLR，由于其CP备份主要是用户数据，会占用很大的存储空间。有的HLR仅一个CP备份就占用大约3GB的空间。目前，采取WINDOWS NT 自带的压缩工具compact，可以将L:\FMS\data\CPF\RELVOLUMSW目录压缩。对HLR的CP备份，压缩率可以达到90％，效果很好，压缩过程也很简单。在R10系统中，针对HLR，L盘借用了计费盘（Y盘）的空间，分配了17GB。这样，一般地就不需要压缩CP备份文件了。 压缩流程如下所示： 检查目标目录是否已经设定为压缩目录 cd /d L:\FMS\data\CPF\RELVOLUMSW\RELFSW0 compact Listing L:\FMS\data\CPF\RELVOLUMSW\RELFSW0\ New files added to this directory will not be compressed. 24576 : 24576 = 1.0 to 1 R0 24576 : 24576 = 1.0 to 1 R1 6144 : 6144 = 1.0 to 1 R2 48814080 : 48814080 = 1.0 to 1 R3 6144 : 6144 = 1.0 to 1 R4 46452736 : 46452736 = 1.0 to 1 R5 Of 6 files within 1 directories 0 are compressed and 6 are not compressed. 95,328,256 total bytes of data are stored in 95,328,256 bytes. The compression ratio is 1.0 to 1. <-压缩比为1:1, 说明还没有设为压缩目录 压缩选定目录（一般地，分别选定3个目录RELFSW0,RELFSW1,RELFSW2） cd /d L:\FMS\data\CPF\RELVOLUMSW\RELFSW0 compact /c Setting the directory L:\FMS\data\CPF\RELVOLUMSW\RELFSW0\ to compress new files [OK] Compressing files in L:\FMS\data\CPF\RELVOLUMSW\RELFSW99\ R0 24576 : 4096 = 6.0 to 1 [OK] R1 24576 : 4096 = 6.0 to 1 [OK] R2 6144 : 4096 = 1.5 to 1 [OK] R3 48814080 : 3235840 = 15.1 to 1 [OK] R4 6144 : 4096 = 1.5 to 1 [OK] R5 46452736 : 28516352 = 1.6 to 1 [OK] 7 files within 2 directories were compressed. 95,328,256 total bytes of data are stored in 31,768,576 bytes. The compression ratio is 3.0 to 1. <-压缩比为3:1, 说明已经设定为压缩目录。 1.2 关于告警板问题经常需插拨ALCPU板问题报告 z来源：江苏 z问题描述： 交换机经常出现“ALI FAULT”告警，需要插拔ALCPU板修复消除。 故障分析 该告警主要由交换机的IOG系统和告警板接口配合问题，由于不同的故障的原因可能导致该告警的出现，请参考处理意见进行分析处理。 处理意见 I) 检查指令ALALP是否FUNCTION BUSY, 如果有拥塞进行释放 检查 ALALP 是否 FUNCTION BUSY： Commands: ALALP; 释放吊死的终端如果 ALALP 返回FUNCTION BUSY Commands: ALALP; TEST SYSTEM; PRINT V AR ALIM 16; ! CCOMSTATE ! SET V AR ALIM 16 = 0; ! CCOMSTATE = IDLE ! PRINT V AR ALIM 16; ! CCOMSTATE ! END TEST; ALALP; II) 检查/更正ALI对应的NP是否正确定义. 检查ALI对应IO device, port and NTN Commands: ALALP; ! Usually AT device is is AT-1 ! IMLCT:SPG=0; MCDVP:IO=AT-1; ! Usually the NP is 1-1-1-2 and the NTN is 1011102 ! END; 注: 以下指令均基于ALI=0, IO=AT-1, NP=1-1-1-2 and NTN=1011102的定义进行，如有不同配置，请参考进行修改 检查并确保NP参数正确定义 Commands: IMLCT:SPG=0; ILLNP:NP=1-1-1-2,DETAIL; END; Correct result printout: TYPE STATE PROT RATE ADDR USER SLP WO X28/V24 2400 NTN=1011102 ACL = A2 ALTIME = 5 - 20 BITS = 7 FLOWCTR = NOREPEAT FLOWSUP = 0 PACKSIZE = 128 PAD = 1 - 0 2 - 1 3 - 126 4 - 0 5 - 0 6 - 0 7 - 1 8 - 0 9 - 0 10 - 0 11 - 12 12 - 1 13 - 4 14 - 0 15 - 1 16 - 127 17 - 24 18 - 18 19 - 0 20 - 255 22 - 0 PRIV = 1 - 0 5 - 1 PROMPT = * STOPBITS = 2 PARITY = EVEN CTSALARM = ALARM CTSSUP = YES DCDALARM = ALARM DCDSUP = YES DSRALARM = ALARM DSRSUP = YES END III) 检查/更正ALI 和 IO 设备定义 检查 ALEXS 和 ALUPI 的指令组没有发生更改 Commands: IOCTP:COMMAND=ALL; 注: ALEXS and ALUPI 的指令组分配在command category 6 检查ALI IO 设备状态 Commands: ALALP; IOIOP:IO1=AT-1; IOTAP; ! Note: AUTH for AT-1 should be NO ! IOTGP; ! Note: IO device should be part of ALEXS and ALUPI command category, e.g. 6 (see step 5 before) ! IMLCT:SPG=0; MCDVP; MCDCP:DIR=COM; MCDCP:DIR=USER; ILSPP:SP=X29; ILPCP:NTNA=1011102; ! Note: A PVC between 1011102 and X29 session port should exist ! IV) 闭解 ALI 和对应NP. 闭塞所有外部告警 Commands: ALEXP; BLEAI:DEV=EXAL2-x&&-y; 闭解ALI 和port Commands: ALBLI:ALI=0; ILBLI:NP=1-1-1-2; ILBLE:NP=1-1-1-2; ALBLE:ALI=0; ALLTI:ALI=0; ALLTE:ALI=0; ALALP; 检查 ALI 和告警板是否正常工作，如果问题解决，执行第39步去解开所有外部告警接收器。如果没有解决那么进行下一步的处理。 V) 重启Node A. 释放呆死终端 Commands: ALALP; TEST SYSTEM; PRINT V AR ALIM 16; ! CCOMSTATE ! SET V AR ALIM 16 = 0; ! CCOMSTATE = IDLE ! PRINT V AR ALIM 16; ! CCOMSTATE ! END TEST; ALALP; Reload node A. Commands: SYRSI:SPG=0,NODE=A,RANK=RELOAD; 注: Reload 大概需要5分钟左右. 解开并测试 ALI. Commands: ALBLE:ALI=0; ALLTI:ALI=0; ALLTE:ALI=0; ALALP; 检查 ALI 和告警板是否正常工作. 如果问题解决，执行第39步去解开所有外部告警接收器。如果没有解决那么进行下一步的处理。 VI) IOG node A 关电. 将ALCPU 板拔出并检查/重设板中的dipswitches. IOG node A 重新开电。 释放呆死终端. Commands: ALALP; TEST SYSTEM; PRINT V AR ALIM 16; ! CCOMSTATE ! SET V AR ALIM 16 = 0; ! CCOMSTATE = IDLE ! PRINT V AR ALIM 16; ! CCOMSTATE ! END TEST; ALALP; 闭塞ALI. Commands: ALBLI:ALI=0; IODAC; 闭塞node A. Commands: IMMCT:SPG=0; IMCSP; END; BLSNI:SPG=0,NODE=A; IMMCT:SPG=0; IMCSP; END; 检查SPG 上所有LUs 和IO 设备状态 Commands: IMLCT:SPG=0; ILLUP; MCDVP; END; 使用AT连接到Node B 闭塞ALI 端口和IO 设备 Commands: IMLCT:SPG=0; ILBLI:NP=1-1-1-2; END; IOBLI=IO=AT-1; 闭塞Node A上LUs Commands: IMLCT:SPG=0; ILBLI:LU=1-1-1; ILBLI:LU=1-1-2; ILBLI:LU=1-1-3; ILBLI:LU=1-1-4; END; 闭塞SPG0 上CP-SP link Commands: BLSLI:SPG=0,LINK=0; 如果有SPG 1，也要进行的闭塞 Commands: BLSLI:SPG=1,LINK=0; 打开RP bus维护状态 Commands: SARPI; Node A关电. 拔下ALCPU 板并检查 the DIP switch开关. 注: 在ALCPU板上有8个位置的dipswitch开关，对应的描述如下 Dipswitch 6 should be ON when the new fan BFD 509 08 is used (to make is possible to use EXAL2-0 on EXRANG), and OFF when fan BFD 509 04 is used. Dipswitch 7 should be OFF for ALCPU version up R2B, and ON for ALCPU from R2C.) Dipswitch 8 should be ON. This dipswitch configuration is different from ALCPU version R2B and version R2C (see doc. 1551-ROJ 207 013/1 rev D). * * 以下是ALCPU 版本为 R2B的有效配置: ON OFF US STD 1 US (1 2 cat.) / STD (16 cat.) 2 future use X 3 future use X 4 future use X 5 future use X 6 Fan Not Connected Connected 7 future use X 8 Type of host SP RP/EMRP 1.* 以下是ALCPU 版本为 R2C的有效配置: ON OFF US STD 1 US (1 2 cat.) / STD (16 cat.) 2 future use X 3 future use X 4 future use X 5 future use X 6 Fan Not Connected Connected 7 ALEXP Connected Not Connected 8 Type of host SP RP/EMRP 2.Node关电. 3.把ALCPU 板插回并重新连接所有的电缆. 4.Node加电. 注：大概需要5分钟左右. 5.解开 CP-SP link. Commands: BLSLE:SPG=0,LINK=0; 6.结束RP bus维护状态. Commands: SARPE; 7.解开 CP-SP link. Commands: BLSLE:SPG=1,LINK=0; 8.进行Node修复测试. Commands: RESUI:SPG=0,NODE=A; 9.解开 node A. Commands: BLSNE:SPG=0,NODE=A; 10.解开原先闭塞的LUs. Commands: IMLCT:SPG=0; ILBLE:LU=1-1-1; ILBLE:LU=1-1-2; ILBLE:LU=1-1-3; ILBLE:LU=1-1-4; END; 11.解开ALI 端口和IO设备 Commands: IMLCT:SPG=0; ILBLE:NP=1-1-1-2; END; IOBLE:IO=AT-1; 12.解开ALI. Commands: ALBLE:ALI=0; IODAC:ATT; 13.如果收到If fault code 43 ALI LOCKED UP，那么将连接到port 1-1-1-2的电缆重新 插拔并重复上一步骤。 14.测试 ALI. Commands: ALALP; ALLTI:ALI=0; ALLTE:ALI=0; 15.检查ALI 和 Alarm Panel是否正常工作. 如果故障还没解决，请重复第14 到 37 步进行ALCPU板的更换 如果故障还没解决，请重复第14 到 37 步进行ALEXP板的更换 16.解开在第7步闭塞的外部告警. Commands: ALEXP; BLEAE:DEV=EXAL2-x&&-y; ALEXP; z问题处理 根据上述处理意见，根据实际情况进行ALCPU板的插拔或换板操作。 1.3 APG40计费冗余实现方案 z来源：江苏 z问题描述 APG 40 的AP2负责计费，如AP2有问题，由于APG40为冷备份，目前不能自动进行切换，需人工干预，因此会影响计费传送的及时率。 z问题处理 6月15日在WXMSCB进行了REDUNDANCY测试，包括省及无锡公司人员，计费可以由AP2切换到AP1,并最终送至计费中心。问题解决。 技术方案： R10 APG40 edundancy for Charg 1.4 各种Forlopp吊死 z来源：江苏 z问题描述 经常出现长时间FORLOPP吊死的情况。调查： 对SYSTEM RECOVERY SURVEY的调查，近期MSC1包括如下的FORLOPP: H'0008 H'0758 H'6D6C pointer too large in SHEC 而其他MSC较少发现。 检查吊住的FORLOPP（SYFAP:HOURS=24;）； 主要一些低版本的MSC出现功能块为MRRM，GRI,C7TCP，C7CO等。负责呼叫的无线资源的建立，向HLR要求漫游号码，BSSAP消息的建立等。通常和用户的不当操作，或终端的异常有关。在呼叫过程中创建了FORLOPP链，但未正常释放。由于数目并不很多，即功能块可用的资源还有很多，不影响其他呼叫的建立。只是产生维护性告警。如果吊住多天，检查以后，可以通过SYFRI人工释放。 我们也看到在较高版本的MSC或刚刚换型的MSC中，以上的FORLOPP都较少。显然由于在新的补丁包（ACA8&9,ACA10）中也包含了对一些FORLOPP问题的处理。 z问题处理： 交换机升级至R10版本后，经常出现长时间FORLOPP吊死的情况，是由于交换机版本较低，对一些用户行为引起的异常事务不能及时释放造成，相关BLOCK有GRI、MTV、C7CO、UPCNHIT、MRRM、C7TCP等。若不及时释放，会积存很多，只能通过启动来释放。 在七，八月份，交换机软件陆续升级到R10 ACA10 ECA6版本，经过观察，现在FORLOOP吊死的情况已经非常少，有的交换机都没有FORLOOP吊死的情况，经常出现长时间FORLOPP吊死的情况已经消失。可以认为补丁解决了以前的FORLOOP吊死的问题。 此类问题可在今后的软件升级后减少，我们将于九月底将爱立信交换节点升级至ACA10 ECA7，这将有效减少此类告警。 1.5 手机激活CLIR（主叫隐藏）功能导致主叫失败的说明 z来源：江苏 z问题描述 移动用户在手机上激活了主叫号码隐藏功能（CLIR功能）后，如果漫游到爱立信交换机下，无法作主叫，要想作主叫的话，必须在手机上取消CLIR功能或在HLR上打开CLIR功能。 故障说明： CLIR(Calling Line Identification Restriction)是一项用来隐藏主叫号码显示的功能，对于该功能，只有在HLR上开启后，用户才能使用，一旦HLR开启了该功能，HLR会通过MAP操作告诉VLR该用户开启了CLIR功能，在VLR中会存有CLIR的数据。 如果用户在HLR中没有开启CLIR功能，而用户又尝试激活CLIR功能进行呼叫，对该种行为 3GPP 规范TS 24.081中有如下规定： If the subscriber has not subscribed to CLIR and tries to invoke CLIR (i.e. requests that the CLI is not displayed), the SETUP shall be rejected. The MS and the network shall act in accordance with 3GPP TS 24.008 network initiated call clearing procedure, see figure 2.2. MSa Network SETUP ------------------------------------------------------------------------------------------------------------------------> CLIR invocation DISCONNECT/RELEASE/RELEASE COMPLETE <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cause #50 (Facility not subscribed, diagnostic = CLIR not subscribed) Figure 2.2: Requesting restriction of CLI presentation 根据此规定，这种呼叫在MSC中将被拒绝，呼叫被释放，所以说目前MSC的做法是完全符合3GPP 规范的。 z问题处理： 在手机上激活CLIR进行MO呼叫时，爱立信MSC的正常做法是释放呼叫，但应有些营运商的要求，爱立信在R10上准备了补丁CN63MSCMWS5039可使该类话务继续。 1.6 APG40历史告警 z来源：江苏 z问题描述： 个别APG40，主要是版本号为AP02或以下的APG，切边后会将一些历史告警自动发送到网管中心。 该问题的原因是现网部分网元的软件模块ADHADMBIN版本太低引起的，出现这种事情的网元全是在版本号为AP02或以下的网元上。 z问题处理： 此问题可经过把AP软件升级到版本为AP04能得到根本的解决。 这些历史告警文件存放在目录：M:\MCS\DATA\ADH\printouts.下，在完成软件升级彻底解决此问题前，为了避免过多的历史告警上传，可以把此文件夹内的文件删除。 1.7 Infinite文件虚假告警 z来源：江苏 z问题描述： CSMSC11多次出现”infinite file end warning”的告警，经检查判断为假告警。 z问题处理： 通过执行ALEX中OPI关于”INFINITE FILE END WARNING”的相关操作，该现象没有消除。通过查阅相关资料，认定需要进行使用SP补丁解决该问题。 7月24日进行了SP补丁版本升级，升级后的版本为AC-A10。SP Function Change之后，该现象不再出现。 1.8 功能块ALA产生大量FORLOPP的调查研究 z来源：江苏 z问题描述： 最近,在常州地区的CZBSC71,CZHLR12以及CZGW2都出现了大量FORLOPP不能及时释放的问题,经查这些FORLOPP都属于功能块ALA.我们以CZHLR12为例对该问题进行研究. 现象与分析 二零零六年七月十一日,CZHLR12出现了大量FORLOPP不能及时释放的问题. H'0000 050B NORMAL 1 0 H'0000 0004 1851 ALA H'0000 0570 NORMAL 1 0 H'0000 0004 1917 ALA H'0000 05BA NORMAL 1 0 H'0000 0004 1958 ALA H'0000 00606 NORMAL 1 0 H'0000 0004 1821 ALA H'0000 062B NORMAL 1 0 H'0000 0004 1850 ALA H'0000 06AC NORMAL 1 0 H'0000 0004 2200 ALA H'0000 0766 NORMAL 1 0 H'0000 0004 2339 ALA H'0000 07D5 NORMAL 1 0 H'0000 0004 1849 ALA H'0000 07EB NORMAL 1 0 H'0000 0004 1850 ALA H'0000 083B NORMAL 1 0 H'0000 0004 2339 ALA H'0000 0850 NORMAL 1 0 H'0000 0004 2106 ALA H'0000 08DE NORMAL 1 0 H'0000 0004 1855 ALA H'0000 093D NORMAL 1 0 H'0000 0004 2227 ALA H'0000 0990 NORMAL 1 0 H'0000 0004 1842 ALA 指令IOSTP发现系统总是在等待终端AT-10: *IOSTP; IO DEVICE STATUS IOIND STATE SUBSTATE COMMAND USERB USERP USERO FO DEVICE H'1400 READCOM IDLE ADE 0 7 Y NVT-767(767) H'6801 READCOM IDLE ADE *** 1 7 Y AT-1 H'1802 READCOM IDLE ADE 2 7 Y AMTP-0(0) H'6403 USERCON WRITES IOSTP SEC12 9 2 Y AMTP-0(1) DEVICE SEIZURE STATUS SIZIND USERB PRCA STATUS RESPTIME DEVICE TYPE 32 ** AL 35 SEIZED AMTP-0(2) WAITING 0.00 AT-10 SYSDEV SEIZED NVT(998) VIRTUAL 33 ALA 42 PENDING AMTP-0(-) *s AMTP-2(-) NVT(-) VIRTUAL 但是AT-10是不可能一直保持在联机状态的,这就造成功能块ALA尝试捕捉AT-10,因为捕捉不到,直到二十秒超时,才释放FORLOPP,所以这就造成了FORLOPP不能被及时释放. 将系统备用终端改为直连终端AT-4, IOSYC:IO=AT-4; FORLOPP很快被释放,同时我们发现AMTP-2也未正常连接, 功能块ALA也在等待捕捉AMTP-2. *IOSTP; IO DEVICE STATUS IOIND STATE SUBSTATE COMMAND USERB USERP USERO FO DEVICE H'AC00 READCOM IDLE ADE 0 7 Y NVT-767(767) H'9801 READCOM IDLE ADE *** 1 7 Y AT-1 H'1802 READCOM IDLE ADE 2 7 Y AMTP-0(0) H'BC03 READCOM IDLE ADE 3 7 Y AMTP-0(1) H'9C04 USERCON WRITES IOSTP SEC12 9 2 Y AMTP-0(3) DEVICE SEIZURE STAT**US SIZIND USERB PRCA STATUS RESPTIME DEVICE TYPE 44 ALA 42 SEIZED AMTP-0(4) WAITING 0.00 AMTP-2(-) SEIZED NVT(998) VIRTUAL END 指令IOROP将AMTP-2更改为只向AMTP-0吐告警, FORLOPP很快被释放. IOROI:PRCA=32&&61; EXECUTED IO PRINTOUT ROUTING DATA PRCA IO DTYPE CLASSA CLASSUA COND SYSDEV 0&&31 AMTP-0 FIRST 0&1&2&3&4&5 0&1&2&3&4&5 2 YES AMTP-2 FIRST 0&1&2&3&4&5 0&1&2&3&4&5 2 YES 32&&61 AMTP-0 FIRST 0&1&2&3&4&5 0&1&2&3&4&5 2 YES 62&&255 AMTP-0 FIRST 0&1&2&3&4&5 0&1&2&3&4&5 2 YES AMTP-2 FIRST 0&1&2&3&4&5 0&1&2&3&4&5 2 YES z问题处理： 为什么会产生如此多的告警呢? 从TLOG中,可看到很多CCITT7 SIGNALLING LINK FAILURE,这是由于传输闪断造成大量的告警. *** ALARM 368 A2/APT "CHZH12*63R/HB/0"U 060710 1755 CCITT7 SIGNALLING LINK FAILURE LS SPID SLC ST 2-9-255-76 CHZD1 1 C**c7ST2C-36 SDL CZD1-1,C7BTC4-450 FCODE INFO REASON 207 H'0 ALIGNED TIME-OUT (T3 EXPIRED) END TRAFFV2 TRAFFV3 OCSIPH2 **2006-07-11110807AT-10 ** *** ALARM 368 A2/APT "CHZH12*63R/HB/0"U 060710 1755 CCITT7 SIGNALLING LINK FAILURE LS SPID SLC ST 2-9-255-76 CHZD1 1 C7ST2C-36 SDL CZD1-1,C7BTC4-450 FCODE INFO REASON 207H'0 ALIGNE***D TIME-OUT (T3 EXPIRED) 那么AT-10以及AMTP-2为什么会影响告警输出呢? 我们知道正常的告警输出是由功能块ALA产生告警,通过IOROP进行路由分析,决定送往哪个终端, 当告警输出到指定终端,FORLOPP便会释放. 根据IOROP的定义: IO PRINTOUT ROUTING DATA PRCA IO DTYPE CLASSA CLASSUA COND SYSDEV 0&&255 AMTP-0 FIRST 0&1&2&3&4&5 0&1&2&3&4&5 2 YES AMTP-2 FIRST 0&1&2&3&4&5 0&1&2&3&4&5 2 YES 告警会输出到AMTP-0,AMTP-2以及因为SYSDEV 为YES,告警也会输出到 AT-10,因为AT-10 被定义为备用DEV.同时ALA也会捕捉NVT 端口吐告警. 所以只有当ALA同时成功捕捉到AMTP-0,AMTP-2,AT-10以及NVT端口, ALA的FORLOPP才能被释放,因为AT-10和AMTP-2未连接,所以ALA等待超时,造成大量 FORLOPP堆积. 那么从IOG到OSS的路由器是否可造成FORLOPP 延时释放呢?为此我们也做了检查: * 检查IOG中网管端口定义，同时建立最大虚通道数为30。 * 检查OSS中X25 LINK，同时建立最大虚通道数为575。可见在虚通道数上没有瓶颈。并且OSS 对于新增网元数千条的告警信息能在几分钟内完成接收和入库工作。 * 检查路由器中X25协议的Debug信息，无集中的故障发生网元的X25通信请求，并非路由器处理能力不胜任，无法处理过多的X25请求所致。同时路由器上相应端口，运行正常，无质量问题。 由此可见，告警的输出缓慢，原因不在MTP下三层以及网管应用程序。 CZBSC71的AD问题: 与别的网元相比,CZBSC71比较特殊,因为在大量告警需要输出的时候,系统在等待AD2输出告警. *IOSTP; IO DEVICE STATUS IOIND STATE SUBSTATE COMMAND USERB USERP USERO FO DEVICE H'EC00 READCOM IDLE ADE 0 7 Y AMTP-0(0) H'B001 USERCON WRITES IOSTP SEC12 *** 9 2 Y AMTP-0(1) DEVICE SEIZURE STATUS SIZIND USERB PRCA STATUS RESPTIME DEVICE TYPE 88 ALA 42 SEIZED AMTP-0(3) WAITING 0.00 AD2 SEIZED NVT(998) VIRTUAL 而该网元为IOG 20 C ,不应该告警输出到AD2,指令IOCDP发现 IO CONFIGURATION DATA 定义错误. IO CONFIGURATION DATA APPL NUM STR MML01 CPF 1 MML01意味着告警输出到AD 终端,这都是针对APG 40所做的定义,对于IOG 20是不必要的.所以删除错误定义: IOCDE:APPL=MML01; EXECUTED IOCDE:APPL=CPF; EXECUTED IO CONFIGURATION DATA APPL NUM STR END 这样告警输出就不会选择AD终端,告警能够正常释放. 处理方案： 根据上面的分析,若想使告警正常输出,应保证: *系统备用DEV是可用且正常连接的终端,同时应保证AMTP-0及AMTP-2端口畅通.所以建议检查各交 换机确保这些端口能正常输出告警. *对于基于IOG的网元,应用指令IOCDP检查是否定义正确,确保不要捕捉APG 40的AD终端吐告警. 1.9 APG系统告警较多、帐号管理不方便问题 z来源：辽宁 z问题描述： APG系统告警比较多，帐号管理不方便。其中后者主要表现为有些用户权限不够，不能对系统备份文件及计费文件进行拷贝、传送等操作；同时，不能通过传送命令文件的方式创建新用户。 当发现系统故障的时候, APG会产生告警。一些告警是严重的,例如NOT REDUNDANT,一些告警是普通告警。告警对网络来说是必要的,它反映系统的状态。需要关注的是区分告警的级别，通过对告警的分析及处理来保障网络的安全。 不同的用户可以有不同的权限，这也是保障网络安全的一部分。根据运维中的需要，可以更改其权限。 z问题处理： 具体有两种方法： 第一种： 通过Master User Domain (MUD) 这一功能来解决相关问题。通过将每个APG和MUD服务器建立连接,我们能使用Global accounts,这样维护帐号就会方便。 第二种： 对应于不属于ADMINISTRATOR组的用户可通过以下操作解决： Frist: we should check the disks authrity which the function will used. for Dump operation: L:\FMS and G:\Ftpvol will be used. then: we can create an user which have the releated right to access these disks. examples: Check: l:CaCLS l:\FMS /c l:\FMS SZD3AP1D\FMSUSRG:(OI)(CI)R SZD3AP1D\FMSADMG:(OI)(CI)F BUILTIN\Administrators:(OI)(CI)F G:\>caCLS G:\ftpvol /C G:\Ftpvol SZD3AP1D\ACSUSRG:(OI)(CI)R SZD3AP1D\ACSADMG:(OI)(CI)F BUILTIN\Administrators:(OI)(CI)F if not then set: echo Y|cacls L:\FMS /T /C /P FMSUSRG:R FMSADMG:F Administrators:F echo Y|cacls G:\Ftpvol /T /C /P ACSUSRG:R ACSADMG:F Administrators:F create user: net user DUMPuser abcd123 /ADD net localgroup ACSUSRG dumpuser /add net localgroup ACSADMG dumpuser /add net localgroup FMSUSRG dumpuser /add net localgroup FMSADMG dumpuser /add then use this user can do Dump related operation. 2. For FTP operation: The same way should be followed: CACLS k:\aes\data /C k:\aes\data SZD3AP1D\AESUSRG:(OI)(CI)R SZD3AP1D\AESADMG:(OI)(CI)F BUILTIN\Administrators:(OI)(CI)F G:\>caCLS G:\ftpvol /C G:\Ftpvol SZD3AP1D\ACSUSRG:(OI)(CI)R SZD3AP1D\ACSADMG:(OI)(CI)F BUILTIN\Administrators:(OI)(CI)F set if need echo Y|cacls K:\AES /T /C /P AESUSRG:R AESADMG:F Administrators:F echo Y|cacls G:\Ftpvol /T /C /P ACSUSRG:R ACSADMG:F Administrators:F create user: net user uftp abcd123 /ADD net localgroup ACSUSRG uftp /add net localgroup ACSADMG uftp /add net localgroup FTPUSRG uftp /add net localgroup AESUSRG uftp/add net localgroup AESADMG uftp/add 通过传送命令文件的方式来创建用户这一功能，WINFIOL7.0支持该功能。 1.10 AP node故障和SCSI RAID磁盘故障 z来源：辽宁 z问题描述： AP node故障和SCSI RAID磁盘故障较多，辽宁有两个端局在入网2个月后即出现RAID磁盘故障。类似告警有MIRRORED DISKS NOT REDUNDANT (磁盘镜像不冗余)等。磁盘状态为： raidutil -L physical Address Type Manufacturer/Model Capacity Status --------------------------------------------------------------------------- d0b0t0d0 Disk Drive (DASD) FUJITSU MAP3367NP 17522MB Failed drive d0b0t1d0 Disk Drive (DASD) FUJITSU MAP3367NP 17522MB Failed drive d0b0t2d0 Disk Drive (DASD) FUJITSU MAP3367NP 17522MB Failed drive d0b1t0d0 Disk Drive (DASD) FUJITSU MAP3367NP 17522MB Optimal d0b1t1d0 Disk Drive (DASD) FUJITSU MAP3367NP 17522MB Optimal d0b1t2d0 Disk Drive (DASD) FUJITSU MAP3367NP 17522MB Optimal APG节点的RIAD磁盘故障主要包括数据丢失, RAID磁盘故障等. 这些故障有时能导致系统吊死和重启。通常解决RAID磁盘故障的方法有：重建RAID, power cycle 和更换节点。经过调查发现, 大多数的RAID磁盘故障是因为 RAID 的低层微程序错误引起的，现在最新的微程序软件版本是FT08；但有一些是由于节点硬件错误引起的，必须通过替换硬件节点来解决。 z问题处理： 预计多数的问题能在CNI: 109 22-APZ 212 30/4-627 软件包解决。 该软件包包含RAID 低层微程序的升级到FT0A版本，也包括DISKEEPER（磁盘监护）到版本10。RAID 低层微程序的最后版本(FT09) 现在正在测试,很快就能推出。 因APG是高集成计算机工业产品，当APG节点有硬件错误时需以节点为单位更换。 经过进一步调查发现,AP2 NODE A存在PMC硬件故障，导致PMCSDLC_1 资源offline，使node B重启后不能加入cluster。通过更换AP node解决。 1.11 省际彩铃呼叫提示号码不完整或无法听彩铃问题 z来源：辽宁 z问题描述： 近期接到用户投诉，反映拨打省际彩铃用户有时听到号码不完整的录音通知或听普通振铃音，停号码不完整录音通知时，被叫可以正常振铃并且可以接听电话正常通话。 由于被叫已经振铃，说明被叫流程可以正常接续，问题发生在彩铃17244的话务接续上。经测试发现如果彩铃17244话务接续到A局平面时，彩铃过程会异常终止，听号码不全录音通知；如果走软交换平面则接续正常。信令跟踪的结果显示：JNA局直接回送端局REL消息 （CODE=28,incomplete number），导致端局给用户放号码不完整的录音通知，如果通过软交换TMG 转接彩铃话务时不存在此问题，两个路径的IAM消息完全相同，经西门子技术支持测试分析后发现，如果端局发送的彩铃IAM消息中被叫号码属性是未知号码时，西门子A局汇接局交换机认为消息不规范，不予接续下发REL消息，原因值为号码不全。 z问题处理： 修改端局17244的号码类型为BNT=4（国内号码）后测试，彩铃话务接续过程正常。但修改上述数据后测试仍有多半的彩铃呼叫听不到彩铃音，但可以听到正常的回铃音。进行信令跟踪发现，当17244的呼叫IAM消息发送后如果在1秒的时间内未收到ACM消息，爱立信端局将强制释放彩铃话务，主叫听普通回铃音，正常接续。在爱立信端局中有TIMEPRBTRNG参数控制彩铃话务IAM 消息后等待ACM消息的时间，该参数缺省值为1秒，由于省际彩铃话务的接续时间相对较长，修改端局TAB表参数TIMEPRBTRNG为3秒后解决。 The AXE parameter control time between IAM and ACM DBTRI;
相关主题
文本预览