华为课程 IA003301SMCP故障分析与处理.doc

课程 IA003301SMCP故障分析与处理 ISSUE3.0IA003301 SMCP故障分析与处理ISSUE3.0目 录课程说明目 录课程说明3课程介绍3课程目标4相关资料4第1章 硬件系统故障案例分析51.1 时钟故障处理方法介绍51.1.1 时钟框故障分析简介51.1.2 典型案例分析51.2 MPU加载故障分析处理方法介绍91.2.1 MPU加载原理简介91.2.2 MPU板不加载问题处理的大致思路101.2.3 典型案例分析111.3 其他方面的案例介绍141.3.1 案例一14小 结16习 题16习题答案17第2章 中继系统故障案例分析192.1 中继系统常见故障现象192.1.1 获得故障的途径192.1.2 中继系统常见故障分类192.1.3 中继系统故障产生的常见原因202.2 分析中继系统故障的常用工具介绍212.2.1 业务维护系统中的工具212.2.2 告警台工具262.2.3 指定占用中继(专线呼叫）262.3 七号信令维护深入272.3.1 号信令数据调试的注意事项：272.3.2 TUP常用的消息介绍292.3.3 TUP接续中重要的定时器时长及超时处理：322.3.4 信令网和话路网分离的概念322.3.5 信令链路集和同一个链路集内链路的负荷分担问题：342.4 中继系统故障案例分析352.4.1 典型案例分析352.5 数字中继自环472.5.1 中继自环的目的472.5.2 中继自环的原理472.5.3 中继自环的工具及准备工作472.5.4 通常自环的手段482.5.5 故障定位示例482.5.6 软件实现自环49小 结52习 题52习题答案53第3章 智能数据故障案例分析543.1 MEM单板故障处理方法介绍543.1.1 MEM功能单板简介543.1.2 MEM单板故障分析543.1.3 典型案例分析553.2 智能数据故障分析处理方法介绍593.2.1 智能数据故障分析简介593.2.2 典型案例分析59小 结63习 题63习题答案64第4章 计费与话单故障案例分析664.1 计费与话单系统常见故障现象664.1.1 获得故障的途径664.1.2 计费与话单系统常见故障现象的分类664.1.3 计费与话单系统故障产生的常见原因664.1.4 C&C08的计费原理674.1.5 C&C08的计费方式的实现684.2 分析计费系统故障的常用工具介绍704.2.1 计费告警信息产生的原理介绍：704.2.2 具体操作714.2.3 注意事项724.2.4 计费告警无法恢复的原因724.3 计费与话单系统常见故障的案例分析734.3.1 典型案例分析73小 结82习 题82习题答案83第5章 维护终端故障案例分析855.1 维护终端故障处理方法介绍855.1.1 维护终端故障分析简介855.1.2 典型案例分析85小 结89习 题89习题答案90第6章 SMCP故障案例分析916.1 SMCP故障处理方法介绍916.1.1 SMCP故障分析简介916.1.2 双机维护916.1.3 SMCP故障维护946.1.4 QUERY故障维护976.1.5 OAM的故障维护996.2 SMCP典型故障案例分析996.2.1 典型案例分析99小 结107习 题107习题答案108第7章 智能业务故障案例分析1107.1 业务故障处理方法介绍1107.1.1 智能业务故障分析简介1107.1.2 “无权拨打该号码”故障处理1107.1.3 201业务打不通某地故障分析1117.1.4 典型案例分析112小 结119习 题119习题答案120第8章 SMAP故障案例分析1218.1 SMAP故障处理方法介绍1218.1.1 SMAP故障分析简介1218.1.2 典型案例分析122小 结127习 题127习题答案128附录缩略词表1291IA003301 SMCP故障分析与处理ISSUE3.0课程说明课程说明课程介绍本课程主要介绍了SMCP商业智能网硬件和软件等方面常见故障，描述故障产生的现象，并给出案例分析过程和经验总结。课程目标本课程主要目标： 掌握时钟和MPU加载等常见故障的定位及处理方法 掌握中继系统常见故障的定位及处理方法 掌握智能数据和MEM单板等常见故障的定位及处理方法 掌握计费与话单系统常见故障的定位及处理方法 掌握维护终端常见故障的定位及处理方法 掌握SMCP平台侧常见故障的定位及处理方法 掌握SMCP业务侧常见故障的定位及处理方法 掌握SMAP常见故障的定位及处理方法相关资料1. C&C08数字程控交换机接入网关工程师培训手册第二分册2. C&C08数字程控交换机工程师培训手册V2.0IA003301 SMCP故障分析与处理ISSUE3.0第8章 SMAP故障案例分析第1章 硬件系统故障案例分析1.1 时钟故障处理方法介绍本章节主要介绍了有关硬件方面常见故障的现象，介绍分析、排除、定位有关硬件方面常见故障现象方法，并给出案例分析过程和经验总结。1.1.1 时钟框故障分析简介针对SSAP多模块局的AM/CM、单模块局的SM需要配置时钟框，在时钟维护方面重点需要我们正确描述各个模块的时钟配置和正确连接时钟同步线。一般来说AM/CM均配置了时钟框，所以AM/CM时钟描述为锁“时钟框时钟”，针对下级SM模块没有配置时钟框，我们将它们的时钟描述为“硬件选择”，所谓硬件选择的含义是可以自动选择时钟框时钟、网板内部时钟、DT8K时钟中精度较高的时钟进行锁相。针对配置了时钟框的单模块局我们也需要将SM的时钟描述为锁“时钟框时钟”。正确连接时钟同步线的作用是使得本局和上级局时钟保持同步。上级局时钟只能通过中继E1引入。所以需要我们正确连接时钟同步线。时钟同步线的正确连接详见配线知识部分。1.1.2 典型案例分析现在我们通过一些典型的案例分析来帮助我们进一步理解。1. 案例一故障现象：时钟框内CK3板F0灯闪最后常亮状态，相应的七号链路无法正常建立。分析过程：1）F0灯由闪至常亮，表明CK3板的时钟参考源故障，捕捉不到由中继而来的DT8K信号，可能原因有以下几种：l 时钟框配线及时钟同步线的连接不对l 中继框锁相时钟的拨码开关不当l 传输电路质量不佳造成2）首先检查时钟框的配线是否按插头所标位置接好，结果正常，与中继框的DT8K连线也为正常，将DT8K插头用刀削平反插后也无效。3）检查中继框拨码开关也为正常（锁第一块DTM板的第一个系统）。试着改拨码开关调为锁第二块DTM板的第一个系统时钟，却发现故障消失，CK3板F0灯灭，MOD灯慢闪，LPH7板相应的LINK灯由闪变为常亮。事故原因：原来前两块板虽然均为同一局向（指向长途局），但传输电路分别由干线和农话光端机所承载，因农话传输不佳，虽然在我方DTM板无告警，但仍然有误码，使得无法锁定时钟。解决方法：由原来锁DT8K0改为现在锁DT8K1。2. 案例二故障现象：时钟框中主用CKS板正常，备用CKS板故障（C821CKB、CC02MCB）。分析过程：1）通过互换两块CKS板后，发现故障现象依旧，则可以排除CKS板坏的原因。2）检查CKB上拨码开关，S4全拨为OFF独立局方式，无误。3）检查时钟框连线，发现仅连接了CKB上JT1到MCB上JA18的时钟线。查阅资料得知 新时钟框采用CKS与主机直接通讯，在B型机独立局上与ALM板通讯，0号CKS通过0号CKS板串口（C821CKB上的JT1）与ALM板（映射之后的）6号串口（C802MCB上的JA18）通讯，1号CKS通过1号CKS板串口（SLT槽位的PIN2229）与ALM板（映射之后的）1号串口（ALM板下槽位的PIN916）通讯。增加时钟连线后CKS框单板均上报正常。事故原因：备用CKS板的时钟通信线未正确连接。解决方法：恢复连线。3. 案例三故障现象：AM/CM，中继板有大量滑码告警。分析过程：仔细观察故障范围，只在与其他局对开中继上出现。该局只配CK3板，有两路DT8K引入，DT8K0为经DTM引入BITS，DT8K2为锁上级局。在现场发现前一天有时钟源失步告警，早上有时钟源丢失24小时告警。判断为时钟失锁。分别复位CK30，CK31，SLT板故障现象依旧 ，由于有两路时钟输入，将两路时钟源互换，发现锁相正常，滑码告警消失。判断故障为原DT8K0引入的时钟源时钟不好，但又无法倒换至DT8K2上。为什么会产生这个原因呢？检查数据，发现AM时钟配置表中，时钟为DT8K0，DT8K2可用，而CK3为DT8K0，DT8K1可用。两方的数据不一致造成时钟参考源无法正常切换，将CK3改为DT8K0，DT8K2可用。4. 案例四故障现象：某局的DTM板有滑码告警，无法正常上网。分析过程：1）首先更换DTM板，发现故障现象依旧，因而可以排除DTM板问题。2）分别在本局及上级局的DDF架上针对产生滑码告警的DTM板进行自环，发现滑码告警现象消失，因而可以排除传输的问题。3）检查TMB母板锁相时钟的拨码开关的设置，均正常，是锁相DT8K0，怀疑是否DT8K0引入的时钟不好呢？通过重新设置TMB母板上锁相时钟的开关，从DT8K1引入时钟，故障现象依旧，因而可以排除DT8K0时钟源的问题。4）检查时钟同步线的连接，是从CB01TMB引到时钟框的JA1，连接正确。5）LST SMCLKDES：MN=1，时钟描述为“锁相DT8K0”，与实际时钟同步线的连接不相符。根据实际时钟同步线的连接应该将时钟描述为“时钟框时钟”。6）将SM（独立局）的时钟描述改为“锁相时钟框时钟”，发现滑码告警消失。事故原因：由于时钟同步线的连接与实际的时钟数据描述不一致造成的。解决方法：修改相应数据。5. 案例五故障现象：某AM/CM模块正常运行了7个小时后，出现了所有SM有一块OPT板故障告警和AM/CM侧相应的光接口板故障告警。每一组FBI中有一块告警，FBI板指示灯BER和RMT灯亮，OPT板LFAP指示亮。AM/CM与SM并没有中断，业务也不中断。告警均在两分钟内自恢。26日9：39也发生了一次这样的告警。当天23：00时，出现了连接1、2模块的两块FBI板全部故障，1、2模块与其它模块中断，其它SM均有一块OPT板故障。插拔告警的FBI或OPT板后恢复。接下来的几天一直有不定期地出现光板告警，都能自恢。即使告警恢复，AM/CM机柜的红色告警灯常亮。并且在此期间伴随着一些中继闪断现象。分析过程： 1）由于已经正常运行了7小时，应该不是数据的问题，并且再次检查全局数 据没有发现任何问题。 2）怀疑是数据加载不彻底造成的，于26日晚上加载AM/CM的数据和程序，并加载了所有的SM。故障依旧。 3）怀疑是新增加的FBI影响其它的FBI，比较新增加的FBI、OPT板和原来的FBI和OPT板，FBI均为C814FBI，OPT 板均为C805OPT ，并且光板的拔码开关和跳线开关都打到了正确位置。 4）因为是全局性问题，可能与时钟有关。检查主控框母板后的时钟线连接正常，在后台查看时钟源工作状态和CKS板状态都正常，并且没有任何关于时钟的告警。 5）在OPT和FBI再次告警时，断开2MBits钟，时钟板处于记忆状态，观察一段时间，告警不恢复，重新接上2MBits钟。排除2M时钟不好的可能，怀疑时钟板不好。 6）6槽位的CKS处于主用状态，倒换CKS板，观察两天，没有异常告警。 因而可以初步断定6槽位的CKS有问题。查看CKS误差，发现有-6PPM。据维护人员反映，AM/CM时钟框6槽位的CKS曾经有过告警，但近一段时间没出过。找来一块新的C841CKS（芯片版本高于原来的CKS）换上，并倒换为主用，两块CKS正常运行，观察几天，再没出过OPT板告警。部分中继闪断现象消失。事故原因：由于原主用的CKS板坏造成的。解决方法：更换坏的CKS板。1.2 MPU加载故障分析处理方法介绍1.2.1 MPU加载原理简介MPU板在设置为加载情况下，加电后主机首先读BIOS的程序，在拨码开关设置为加载的状态，主机会根据加载的设置读取BIOS中的相关程序，根据程序向后台发出加载请求，后台BAM收到该模块的加载请求后，假如有程序及格式转换好的数据，就会响应其加载请求，将要加载的程序或数据拆分成一定数量的数据包，发送数据包时BAM会根据每一个数据包前后顺序、大小等加帧头，向该模块发送，其帧头包括该数据包的顺序编码、大小等信息。比如第一个数据包顺序编码为1，第二个顺序编码为2，MPU板收到该数据包后检查其帧头顺序编码是否正确、大小等是否与帧头所表示的一致，假如一致就去掉帧头，放入MPU板的内存中，然后给后台BAM回一个证实信号，同时记录下这次收到的数据包编码，在回证实信号同时MPU板的LAD灯闪一下，表示已经收到了这次的数据，可以继续发送下一个数据包了。MPU板的LAD灯就会这样一闪一闪不断的接受数据并向BAM回证实信号，一直到所有数据全部收齐后LAD灯停止闪动。假如某次收到数据包编码顺序号与预计的不符合，则MPU板会停止接受数据，比如前一次收到数据包的编码为4，后一次收到的数据包编码为6，则MPU板就会认为数据包发送有误，LAD灯就会常亮，一定时间后MPU会自动复位并重新发出加载请求，而从后台BAM那里看就是加载超时，过一段时间后重新加载。即：后台BAM收不到MPU板相关数据包已收到证实信号的话，是不会继续下发数据的，而MPU板收到的数据包帧头信息与预计不符合也不会继续加载下去的。另外注意：MPU板的拨码开关设置或模块类型与BAM后台数据设置的不一样，使上报的加载请求信息与后台数据不一致，BAM是不会下发数据的，即不可能响应其加载请求。1.2.2 MPU板不加载问题处理的大致思路首先应该明确问题的现象是什么？比如不加载可以按以下思路处理：1、检查前后台通信是否正常？2、检查后台的BAM模块号是否正确（独立局与AM/CM是不同的，SSAP-R005I版独立局需要修改注册表）？3、数据是否正确？（主要是配置数据，AM模块描述表等，后台监控状态是否激活等）4、检查D：DATA目录下cc08.bsm以及db_?(相应模块加载文件)是否存在？5、MPU板的芯片是否正确，首先应明确后台的版本是什么，然后根据版本检查MPU上的芯片是否符合相应的版本要求？6、MPU板的拨码开关是否正确？比如模块类型与开关设置是否一致，后台数据设置的与AM的通信速率是多少，实际拨码设置的通信速率是多少？7、相应的传输通路是否存在误码及连接是否正确？与OPT、FBC板间的光纤是否存在交叉现象？相应的模块间链路是否正常建立（可以观察MC2板的建链指示灯F0的状态，如果常亮表示正常建链）。8、相关的电路板是否存在问题，MPU、MC2、OPT、NO7、LAPMC2等，为了对电路板问题定位，可以采用单配置措施，比如MC2、OPT、FBI等均配置一块，看是否可以正常工作？这样便于快速定位有问题的电路板。9、假如出现加载超时现象，可以检查MPU板的内存是否符合要求？芯片是否有问题？相关的电路板是否正常？MC2、OPT、NO7等。10、还需要知道MPU板加载过程中相应指示灯的状态，密切注意MPU板的加载过程，观察MPU板加载在哪一步出现异常： MPU板上电请求加载时，LAD灯亮（此时MC2板的F0灯常亮）。 MPU板加载过程中，LAD灯闪烁（此时MC2板的F0灯灭）。 MPU板加载完时，LAD灯灭、DWR灯亮，表示正在写数据。 MPU板写完数据时，DWR灯灭，PWR灯亮，表示正在写程序。 MPU板写完程序时，PWR灯灭。 如果所设置的数据没有错误，这时MPU板可以正常运行，RUN灯闪 烁，MUI灯亮表示该板为主用状态。（此时MC2板的F0灯将始终处 于常亮状态）。11、如果AM/CM模块的MCCM无法正常加载，请检查时钟框是否上电，SNT板是否在位。1.2.3 典型案例分析1. 案例一故障现象：某局的一个RSM模块局在5月21日下午到晚上接通率很低，只有1.5%左右，几乎处于全阻状态。分析过程：1）观察该模块的状态，发现基本上正常，只有左边的一块OLE板显示故障，其他电路板显示均正常，往里向外打电话及从外向里打基本无法要通，但在模块内打电话是正常的。2）开始以为是右边那块OLE板也有隐含故障，但在更换了OLE板后问题依然没有解决，即电话无法正常出入局。左边显示故障的OLE板在更换后问题也依旧，OLE板上的RNL、BER灯常亮，因此定位问题不是OLE板的。3）估计是光路或传输方面有问题，为了对问题定位，将右边显示正常OLE板的光纤倒换到左边这块OLE板上来，左边这块板也显示正常，但还是无法正常出入局。即虽然一光通路显示正常，但仍然不正常。4）以为是软件或数据有问题，针对备用MPU板进行加载，在加载过程中发现问题，MPU下面的LAD灯在加载过程中应该是一闪一闪的，但发现LAD开始闪了几秒后就不再闪，随后一直常亮，过了一段时间后又重新开始加载，始终不能正常加载完。5）由于在MPU板的加载过程中是由后台的BAM向MPU板发送数据，MPU板在每收到一次数据后给一个证实信号，这时候LAD灯就闪一下，表示收到了BAM的数据同时也给了其回应信号，假如没有收到BAM送的某次数据，MPU板的LAD灯就会常亮，无法继续接受数据加载，因此从现象上看问题还是可能出在传输有误码。6）于是去检查光纤，发现在机柜上方的走线槽道上，二块石膏板压着光纤，将石膏板取走，发现在光纤上有明显的压痕。将石膏板拿走后，二块OLE板的指示灯均显示正常，MPU板也可以正常的加载完。出入局不正常的问题也得到了解决。事故原因：由于软件设计时OLE板对误码的反映不能太敏感，在一二秒内的不正常，不会上报故障，因此看起来是有一块OLE板不正常，一块正常，但实际上二块OLE板的光传输均存在问题，在将石膏板去掉后误码问题解决，这样就一切正常。2. 案例二故障现象： #6SM备板加载结束后，MPU就无法开工。只有BUI灯亮，而RUN等其它灯都灭。分析过程：1）首先怀疑是MPU板坏，于是用已正常开工的模块#5的备用MPU板替换，加载后也无法开工，将#6模块的备用MPU插入#5模块，可正常开工，由此确定与MPU板无关。2）怀疑是交换机程序和数据有错，由于其他模块运行正常，因而可以排除程序的问题，难道是6#模块的数据有问题吗？3）在仔细检查了数据没有发现任何问题。4）怀疑是否是MPU板的内存不足而无法开工呢？查询MPU面板，发现内存果然太小，（具体为： #6模的MPU板剩余内存空间是75848bytes，而正常开工的MPU板剩余内存都是15M以上的）。5）一般来说，内存太小与最大元组数有关，将“模块最大元组表”#6模的数据与#5模的数据进行比较，发现有几张表格#6模值大于#5模：CUG数据表，EST用户数据表，TCI用户数据表，AT0中继群表，AT4中继群表，EM中继群表，ETS中继群表。而这些数据实际在6#模块没有配置，为了节约MPU的内存，需要将这些没有配置的数据表的最大元组数改为最小值“1”。正确修改后发现故障现象消失，MPU板可以正常开工。事故原因：由于6#模块的MPU板的剩余内存少于正常值，所以导致MPU板无法正常开工。解决方法：将实际没有配置的数据表格的模块最大元组表的值改为最小“1”，格式化后，重新加载，恢复正常。 注意：针对某一模块来说，为了节约MPU板的内存，需要将实际没有配置的相关数据表的最大元组数设置为最小值“1”。3. 案例三故障现象：设置备用MPU板备份开关失败及无法备份数据。分析过程：1）检查CC02EMA的芯片U15的版本为COEMA2301，不符合备份要求。2）在R005I版本中二块MPU板的备份与否设置采用软件控制（取消了MPU备份硬件开关的作用），由于R005I版中对EMA芯片的要求比较高，因此在老版本中往往可以正常备份，但升级后假如没有更换EMA板的芯片会导致无法备份数据，R005I版本中要求CC02EMA的芯片U15必须为COEMA2302（COEMA2301无法备份），CC03EMA板的芯片U16必须为COEMA4102、U15必须为5102、否则无法备份，此时在设置备份开关时会有错误提示：主用MPU板备份开关设置成功，备用MPU板备份开关设置失败。设置双机正常备份的指令为 SET BAKMODE: MN=2， BSP=NMB;该指令执行后点该模块主用MPU板，会出现备份进度指示，及备份是否完成。设置双机不备份的指令为：SET BAKMODE: MN=2， BSP=NOB;其中MN指模块号。解决方法：更换CC02EMA的软件版本。 注意：1）一般来说双机的倒换、复位的时间间隔必须要求在30分钟以上，并且双机倒换、复位时必须将数据备份开关设置为“OFF”状态。否则容易引起数据混乱、循环死机的现象。2）对EMA板而言，站在解决实际问题的角度来看，最重要的是其上芯片， 对CC02EMA而言：在R005I版本中，单板软件必须更换为COEMA2302以上，EPLD应更换为COEMA1202以上。否则会导致主备机无法正常备份，主备机倒换断话，备机无法加载，异常加载，主备机备份不对，影响LAP板正常工作等现象。对CC03EMA而言：在R005I版本中，单板软件必须更换为COEMA4102、COEMA5102以上，EPLD必须更换为3101以上，否则会出现异常加载（前面的模块死机），数据备份有问题，主备机无法备份，主备机倒换断话，影响LAP板正常工作等现象。3）CC02EMA及CC03EMA均可用于A、B、C三种模块，只要芯片版本正确就可以。4）CC06MPU板对EMA板的EPLD有要求：在R005I版本中，采用CC02EMA，要求其EPLD为1202，采用CC03EMA，要求其EPLD为3103。其他MPU板无此限制。1.3 其他方面的案例介绍1.3.1 案例一故障现象：原挂A局下的用户，割接后局向由6876改为6875，再拨打6876应听改号通知音，通知用户“号码改为6875”，但拨打后只听“请拨打114查询”？分析过程：1） 因为本局没有语音信箱，因此要从上级局NEC语音邮箱中获取语音通知，到NEC语音信箱数据设定方法如下： 1、将6876用户设为改号状态（CHG DN）。 2、做失败处理“号码更改”，对应一号码变换索引。 3、做号码变换表为插号，变换位置“0”，变换号码“55”。 4、被叫分析表做呼叫字冠“55”选择指向NEC。2） 当用户拨打68761000时，索引到索引表中状态为“改号”，再查失败处理表的“号码更改”，由“号码变换索引”，再查到号码变换表得知新号码是556876，再查被叫分析表55走到NEC的路由，到达NEC方的语音信箱，听改号通知音。3）又多用几部电话呼叫，发现由NEC汇接至我局的电话不能到达NEC语音信箱，而由县局08机汇接的电话则可到达语音信箱，想起在培训中心时老师讲软件参数时提到“允许同一局向套拨”，因为NEC用户拨打6876时索引到被叫分析表“55”走NEC路由，这就涉及到同一局向套拨。再查看软件参数表，其值为“0”，试着将该软件参数改为“1”后，故障现象消失。事故原因：由于涉及同一局向是否允许套拨的参数设置错误。解决方法：将该域改为“1”，表示允许同一局向套拨，即可听改号通知音。而此前听“请查询114台”，因为在失败处理表中的送音类型为“送改号通知音”。小 结本章节主要介绍有关MPU、时钟等硬件方面常见的故障现象及案例，通过案例的分析使得我们掌握了排除故障的常用方法。习 题1. 单模块局和多模块局在时钟配置方面有什么不同呢？2. 如何排除MPU板不加载的故障？习题答案1. 针对多模块局的AM/CM、单模块局的SM需要配置时钟框，SMII、RSMII模块不需要配置时钟框，在时钟维护方面重点需要我们正确描述各个模块的时钟配置和正确连接时钟同步线。一般来说AM/CM均配置了时钟框，所以AM/CM时钟描述为锁“时钟框时钟”，针对下级SM、SMII、RSMII模块没有配置时钟框，我们将它们的时钟描述为“硬件选择”，所谓硬件选择的含义是可以自动选择时钟框时钟、网板内部时钟、DT8K时钟中精度较高的时钟进行锁相。针对配置了时钟框的单模块局我们也需要将SM的时钟描述为锁“时钟框时钟”。正确连接时钟同步线的作用是使得本局和上级局时钟保持同步。上级局时钟只能通过中继E1引入。所以需要我们正确连接时钟同步线。时钟同步线的正确连接详见配线章节。2. 首先应该明确问题的现象是什么？比如不加载可以按以下思路处理：1) 检查前后台通信是否正常？2) 检查后台的BAM模块号是否正确（独立局与AM16或AM32是不同的，SSAP-R05I版独立局需要修改注册表）？3) 数据是否正确（主要是配置数据，AM模块描述表等，后台监控状态是否激活等）？4) 检查D:DATA目录下cc08.bsm以及db_?(相应模块加载文件)是否存在?5) MPU板的芯片是否正确，首先应明确后台的版本是什么，然后根据版本检查MPU上的芯片是否符合相应的版本要求？6) MPU板的拨码开关是否正确？比如模块类型与开关设置是否一致，后台数据设置的与AM的通信速率是多少，实际拨码设置的通信速率是多少？7) 相应的传输通路是否存在误码及连接是否正确？与OPT、FBC板间的光纤是否存在交叉现象？相应的模块间链路是否正常建立（可以观察MC2板的建链指示灯F0的状态，如果常亮表示正常建链）。8) 相关的电路板是否存在问题，MPU、MC2、OPT、NO7、LAPMC2等，为了对电路板问题定位，可以采用单配置措施，比如MC2、OPT、FBI等均配置一块，看是否可以正常工作？这样便于快速定位有问题的电路板。9) 假如出现加载超时现象，可以检查MPU板的内存是否符合要求？芯片是否有问题？相关的电路板是否正常？MC2、OPT、NO7等。10) 还需要知道MPU板加载过程中相应指示灯的状态，密切注意MPU板的加载过程，观察MPU板加载在哪一步出现异常： MPU板上电请求加载时，LAD灯亮（此时MC2板的F0灯常亮）。 MPU板加载过程中，LAD灯闪烁（此时MC2板的F0灯灭）。 MPU板加载完时，LAD灯灭、DWR灯亮，表示正在写数据。 MPU板写完数据时，DWR灯灭，PWR灯亮，表示正在写程序。 MPU板写完程序时，PWR灯灭。 如果所设置的数据没有错误，这时MPU板可以正常运行，RUN灯闪 烁，MUI灯亮表示该板为主用状态。（此时MC2板的F0灯将始终处于常亮状态）11) 如果AM32模块的MCCM无法正常加载，请检查时钟框是否上电，SNT板是否在位。16第2章 中继系统故障案例分析2.1 中继系统常见故障现象本章节主要描述中继系统中常见的故障现象及分析中继系统故障现象的常用工具的使用方法，并通过相应的案例分析来进一步掌握中继系统常见故障定位与处理方法。2.1.1 获得故障的途径机房维护人员获得中继故障的途径有：1) 告警信息中获得；2) 通过维护台控制面板观察到；3) 用户直接申告；4) 对方电信局申告；5) 话务统计信息中获得。其中1）、2）两种情况为日常工作的一部分，例如：通过告警观察看到关于某一PCM系统、信令链路或DPC的告警信息，或者在维护台控制面板发现某一中继板为异常状态。由这种方式得来的故障信息准确度很高，并可直接处理。而3）、4）、5）三种情况的信息，要通过观察和测试来进一步确定。例如话务统计结果表明，某一局向的接通率很低，就需要进一步分析其它相关统计结果，并配合维护台工具的使用，进行呼叫跟踪和信令分析，查找故障原因。2.1.2 中继系统常见故障分类根据故障的性质，中继系统常见故障的现象可作如下划分：1) No.7信令相关故障2) No.1 信令相关故障3) No.7信令和No.1 信令转接时的相关故障4) 局间通话异常（噪音、静音、摘机断话、单向通话等）2.1.3 中继系统故障产生的常见原因1. 传输故障1) 传输损耗大，误码率高 由于中继线接头处接触不好或阻抗不匹配都有可能引起通话噪音、 七号链路不稳定。2) 鸳鸯线（交叉对）：两对中继线互相接岔的现象。由于中继线接成鸳鸯线或局间CIC电路号对错，都可能引起局间通话占用这些中继时出现单通或不通话。例如： 只接岔一对线： T1-R1，R1-T2，T2-R2，R2-T1此时无PCM告警，但是占上该两系统会出现单向通话。 PCM系统收发两对线均接岔：T1-R2，R1-T2，T2-R1，R2-T1此时也无PCM告警，但是占上该两系统会出现不通话。2. 交换机硬件故障1) 中继HW配线异常 2) 中继硬件(DTM、 NO7、LPN7、MFC等板)故障3) 其它相关硬件系统故障(NOD、MPU、BNET等）引起中继系统故障3. 局间信令配合问题或对端局软硬件的问题4. 交换机数据设置错误或交换机主机软件的问题2.2 分析中继系统故障的常用工具介绍2.2.1 业务维护系统中的工具1. 系统配置/硬件配置状态面板在业务维护系统的硬件配置状态面板中，用鼠标右键点中相应的单板（DTM、TUP、ISUP、MFC、NO.7、LAPN7），可以查询这些单板的状态，请注意这些单板的状态数据是来源交换机（即是前台的数据）。1. DTM：一号数字中继板，查询出的状态说明如下：a. 空闲态：只要本端有关一号中继的数据正确，DTM板上相应的通道就呈空闲状态。b. 线路忙态：只要路由分析数据正确且通道空闲就可以占上中继，发 出线路占用信号；而接通与否取决于对方的通道状态；本 端通道空闲并不代表对端也空闲。c. SPC忙态： 当中继电路被半永久连接占用时，显示这种状态。此时它不能再被任何呼叫占用。d. 未安装态：相关DTM中继电路数据、DTM板名配置数据错误。e. 故障态：相关中继电路数据错误。 单板故障（板坏、板未插好或者相应NOD配置错误等）。PCM系统问题（中继线断、中继线及DDF接头、帧失步、DTM板匹配阻抗开关设置等）。2. TUP：七号数字中继板，查询出的状态说明如下：a. 空闲态：只有双方有关七号中继的数据都正确，TUP板上相应的通 道才呈空闲状态。b. 线路忙态：只要路由分析正确且通道空闲就可以占上中继，发出 IAM/IAI（ 初始地址消息）；而接通与否取决于双方CIC是 否完全一致。从“面板”上查询电路状态，只能显示出“线路忙”。 要进一步确定是哪种原因引起的电路忙，可以通过业务维护系统/七号信令/NO。7电路控制/查询电路和查询系统的功能来查询引起电路忙的原因值。TUP线路忙分别有以下几种原因： 被去话电路占用：说明此电路正在被一次呼出的呼叫占用。 被来话电路占用：说明此电路正在被一次呼入的呼叫占用。 正在进行导通检验：说明此电路正在进行导通检验。 电路正在释放：说明这时呼叫已经结束，已发送了拆线信号， 但还没有收到对端局的拆线响应。c. SPC忙态： 当中继电路被半永久连接占用时，显示这种状态。此时它不能再被任何呼叫占用。d. 未安装态：相关TUP中继话路数据、TUP板名配置数据错误。e. 故障态： TUP电路处于故障态，有可能是以下几种原因造成的：DT板故障，PCM系统故障，DPC不可达。要进一步确定是哪种原因引起的电路故障，可以通过业务维护系统/七号信令/NO。7电路控制/查询电路和查询系统的功能来查询引起电路故障的原因值。详细分析过程及原因如下表所示：分析步骤一分析步骤二分析步骤三结论观察硬件控制状态面板中TUP的状态观察查询电路的原因值观察查询系统的原因值引起故障原因故障态话路故障DT故障TUP板坏或未插好、相应的NOD配置错误硬件闭塞对端PCM断线、帧失步、远端帧失步PCM插头问题、TUP单板的匹配阻抗开关设置不正确对端硬件闭塞无DPC不可达DPC的相关数据错误 f. 未知态：TUP中继电路（群）复位发出RSC单电路复位消息或GRS群复位消息后，在未收到对端局的响应（一般是RLG响应RSC，GRA响应GRS）之前，电路处于未知状态。g. 如果TUP电路一直处于未知状态，则首先将与这些电路所对应的所有链路全部跟踪上，观察是否有GRS或RSC消息发出，如果有再观察是否有消息响应，有以下两种情况：如果从链路上跟踪不到复位消息响应（注意中继电路所至局向的所有链路都要观察），则首先看我局发出的GRS/RSC消息中的DPC、OPC、CIC以及GRS消息内容中的“范围值”是否正常，即DPC是否是所要发送的复位消息的接收局的信令点编码，OPC是否是本局信令点编码，CIC值是否在与对端局商定好的CIC范围内，GRS消息的范围值是否小于32。如果上述都是“是”，则在这种情况下就不是本局的问题，应与对端局协调，进一步确定对端局不回消息的原因，有可能是对端局有关的电路数据没有做，也可能数据作了但未激活等。如果从链路上能够跟踪到对端局回了电路复位响应消息，则观察收到的响应消息的OPC、DPC、CIC以及GRA消息的范围值是否正确，如不正确则通知对端局协商解决。如果正确，即本局收到了正确的响应消息，却丢弃了或认为未收到，这时在告警台应该能看到事件告警：“TUP收到未分配的CIC”。这时需检查本局数据，主要是CIC模块表，注意此表中的“目的信令点编码”指的是“编码”而不是“编码索引”。如果从链路上根本没有跟踪到有GRS或RSC消息发出，电路状态仍为未知态，则可能是发出过电路复位消息，在收到响应之前，进行了停止复位的操作。这种情况下只需再次从维护终端对此电路发起复位操作，如果一直收不到响应，则可以按照上述步骤处理。h. 闭塞态：我们的交换机具有三种闭塞态：本端闭塞本端、本端闭塞对端、对端闭塞本端。如果从“面板”上查询电路状态，只能查询到闭塞态。具体要知道是哪种闭塞（也可能是多种闭塞的组合），可以通过业务维护系统/七号信令/NO.7电路控制/查询电路的功能来查询引起电路闭塞的原因值。具体的引起闭塞态的原因值和解除电路闭塞的方法归纳如下表：TUP电路的闭塞态接续情况故障原因解除闭塞的方法本端闭塞本端不能呼出可以呼入进行了本端人工闭塞维护操作进行本端人工打开维护操作本端闭塞对端可以呼出不能呼入进行了本端人工闭塞维护操作进行人工打开对端电路、人工复位电路本局CPU占用率过高主机进行了过载控制对端闭塞本端不能呼出可以呼入对端局向本局发送了人工闭塞电路的消息对端局发送人工群闭塞解除消息i. 维护态：维护态是故障态和闭塞态的组合。即这条电路处于故障态， 同时又处于闭塞态。要进一步确定是哪种原因引起的电路处 于维护态，可以通过业务维护系统/七号信令/NO.7电 路控制/查询电路和查询系统的功能来查询引起电路处 于维护态的原因值。3. MFC：一号信令板，查询出的状态说明如下：1) 只要单板状态正常，查询出的通道状态也往往空闲/占用。2) 如果部分或全部通道故障，请检查配置数据和单板软硬件。4. NO7/LPN7： 七号信令板，查询出的状态说明如下：1) 不能查询通道状态，只能查询到单板正常与否和相关链路的状态。2. 呼叫接续动态跟踪跟踪的对象可以是用户、一号/七号中继的某个通道。因为是动态跟踪，所以跟踪时可以选择“跟踪存盘”，保存相应信息，以便于利用“跟踪回顾”来仔细分析跟踪的结果。对于局间呼叫，可以观察到承载通道和信令通道。承载通道上可以看出具体占用哪一路DT或TUP，信令通道上传送的一号或七号消息也可以直接观察到。3. 数字中继接续跟踪仅指一号中继，信息无法存盘，但能够直观地看到信道的占用状态和过程。4. 七号信令菜单1) 七号信令链路跟踪 在开局、维护、调试工作中，七号信令消息跟踪是发现问题的重要手段和验证操作的依据，是七号信令维护中最常用的功能。例如检测被叫号码是否正确发送，查找局间的不期待消息等，都需要进行七号信令消息信令单元MSU的跟踪。七号信令消息跟踪的对象是七号信令链路。C&C08数字程控交换机对七号信令链路的跟踪，是跟踪某条七号信令链路MTP、TUP、ISUP消息的收发和处理情况，可跟踪MTP第二层和第三层消息，并提供过滤机制，将想要观察的消息过滤出来。在跟踪信息窗口中选中一条消息，敲回车键，即可以显示消息的具体含义。2) 七号信令链路跟踪回顾利用该工具可以将所跟踪的七号信令消息进行存盘，然后在详细分析查看。3) 七号信令相关状态查询利用该工具可以分别针对七号信令的链路状态、目的地状态、路由状态进行查询。4) 七号电路查询七号电路查询可以针对单条电路操作，也可以针对群电路进行操作，它分别提供查询电路和查询系统两个功能。通过这两个功能可以查询出七号中继电路状态的原因值。2.2.2 告警台工具1. 故障告警MTP第一、二层的告警都出现在“故障告警”窗口中，例如“PCM系统告警”，“信令链路不可用”等等。 选中一条告警消息，敲回车键，可以显示告警的具体位置和含义，并给出处理建议。2. 事件告警MTP第三层以上的告警都出现在“事件告警”窗口中，例如“DPC不可达”，“MTP路由不可用”，“MTP链路测试失败”等等。选中一条告警消息，敲回车键，可以显示告警的具体位置和含义，并给出处理建议。3. 出现告警以后的处理分析告警定位故障维护台消息跟踪、状态查询观察单板指示灯数管台分析数据。2.2.3 指定占用中继(专线呼叫）当怀疑局间中继某一个PCM系统不好，或者某两个PCM系统接成鸳鸯线时，可以用指定占用中继电路的方法来拨测定位。操作方法：设定一话机为“话务员”或“测试用户”，在每个PCM系统中选一条电路试拨一下（即专线呼叫），拨打的号码如下：*XX*MM*N*TTTT*PQRABCD#其中：XX为接入码，MM为模块号，N表示电路类型（N=0时表示出局中继电路，N=1表示IDT电路，N=2表示OPT电路），TTTT为电路号，PQRABCD为号码。另外还有下面用法：*99*01*0*0050*1392912345#，链路上将发：IAI ( 1392912345 )*99*01*0*0050*139291234#5，链路上将发：IAI ( 139291234 )、SAO(5) *99*01*0*0050*13929123#45，链路上将发：IAI ( 13929123 )、SAO(4)、SAO(5) *99*01*0*0050*139#2912345，链路上将发：IAI ( 139 )、SAO(2)、SAO(9)、SAO(1)、SAO(2)、SAO(3)、SAO(4)、SAO(5)用上面方法可以：实现重叠发码和成组发码。测试号码长度不受限，不用考虑*XX*MM*N*TTTT* +“ #” 占用的13位。值得大家注意的是，指定中继电路占用呼叫与正常选线呼叫的区别在于：指定中继占用跳过了路由分析阶段。2.3 七号信令维护深入2.3.1 号信令数据调试的注意事项：七号信令调试关键是双方局的数据设置，所以我们需要深入的了解CC08交换机七号数据的正确设置。首先我们理解七号信令方面的一些基本概念： CIC（Circuit Identification Code）：电路识别码，用于两局对接时对电路的标识。只有TUP、ISUP等电路交换业务的消息中，才有CIC字段，其长度定义为12bit，所以一个局向最多只能有4096条电路。在网络管理等消息中没有CIC字段。 SLS（Signalling Link Selection）：一