APP下载

华为CC08机七号电路状态异常处理步骤

2010-05-02

科学之友 2010年10期
关键词:信令中继链路

许 闯

(中国铁通 通化市分公司,吉林 通化 134002)

华为公司生产的 CC08交换机作为新一代技术成熟的数字程控交换设备已在各运营商的网络中得到了广泛的使用,铁通公司成立后也大量使用了08机在现网中使用,通化铁通公司在2002年本地网的建设中广泛的使用了该设备。作为一名基层的设备维护管理人员,在这几年的维护和日常工作中,通过不断的学习和实践积累了一定的维护经验,掌握了一定的故障处理方法和日常维护手段。在新建局所和对开局向中继的工作中经常会遇到七号中继电路的一些问题,在处理问题的过程和与华为技术人员的交流中自己总结了一些经验和心得。愿与大家共同分享维护心得和体会。本文将对七号电路异常状态的处理进行简要的阐述和说明。

1 七号中继电路几种状态的解释和说明

要想准确定位和处理七号中继电路的问题,首先要对七号中继电路状态的各种相关概念有一个正确的认识和掌握。只有这样,才能做好故障的处理和平时的维护工作。在网管维护终端系统通过命令DSP N7C(本文MML命令以128模8 K为例)或通过业务维护系统中的“维护/维护工具导航/七号信令/七号电路查询”可以检查主机中七号中继电路的状态,通常经查询显示的结果有以下几种:空闲、忙、闭塞、未知、故障、维护态、半永久连接和未安装,其中闭塞又可分为可用闭塞(闭塞对端和对端发起“闭塞本端”的操作)和不可用闭塞(闭塞本端),下面以双向中继电路为例,对各中继的状态做一具体的解释和说明:

(1)空闲:表明电路可以接收或发起呼叫,也可以进行维护闭塞、删除。

(2)忙:表明电路正在使用。电路不能再接收或发起呼叫,可以进行维护闭塞,不能删除。

(3)可用闭塞:表明已经闭塞对端电路,此时对端电路状态为不可用闭塞。此状态下仍可以发起出局呼叫,但此电路不会接收到入局呼叫。

(4)不可用闭塞:表明已经闭塞本端电路(对端闭塞或本端闭塞),若为本端发起闭塞,此时对端电路状态为空闲。此状态下不可以发起出局呼叫,但仍可以接收入局呼叫。

(5)导检:表明电路处于导通检验状态。

(6)未知:这种状态表示不知对端电路的状态,在对这条电路或者这条电路所在的端口发起电路复原或者群复原消息后,电路进入此状态。如果未收到对端回复消息,将保持这种状态,直到接收到相应的响应消息,电路状态才变为空闲。处于此状态的电路不能进行接收或发起呼叫,可以进行维护闭塞、删除。

(7)故障:这种状态表示电路有故障、不可用,可能的原因有信令链路处于断开状态、对端目的信令点不可达、传输中断、硬件故障。处于此状态的电路不能进行接收或发起呼叫,可以进行维护闭塞、删除。

(8)半永久连接忙:表明此电路被配置为半永久连接。处于此状态的电路也可以进行维护闭塞、删除。

(9)未安装:这种状态表示不存在该电路,可能对应的电路未安装或单板未激活、该电路没有配置、该电路被用做信令链路通道。

以上9种状态为七号中继电路的不同状态,熟练掌握这几种状态的含义对处理故障、对开局向和做好日常的维护工作至关重要。

2 ISUP电路状态异常的处理步骤

我们在开局或日常维护中有时会出现中继状态异常,或者中继状态显示正常但是无法正常接通的情况,如何才能快速准确的定位故障,在较短的时间内将故障处理好,尽快恢复业务的正常使用呢?一般可以按照以下六个基本步骤进行分析,就可以尽快找到故障点,短时间内恢复七号中继电路业务的畅通。

步骤 1:检查七号链路状态是否正常,链路传输误码或瞬断,造成链路不定期的断开,或者是信令链路故障造成断链,都会造成中继电路状态不正常(可使用命令DSP N7LNK,或通过业务维护系统中的“维护/维护工具导航/七号信令/按目的信令点查询链路”查询)。

步骤 2:检查中继单板状态是否正常上报(可通过业务维护系统中的“维护/维护工具导航/配置/硬件配置状态面板”查询)。

步骤3:查询中继电路状态,中继状态可能是未知、闭塞、故障或未安装等,应针对不同的状态做相应的处理(可使用命令DSP N7C、DSP TKC或通过业务维护系统中的“维护/维护工具导航/七号信令/七号电路查询”)。

步骤4:检查本端数据配置,尤其注意两端CIC配置是否一致(可使用命令LST TKC和LST CIC配合查询)。步骤5:与对端局联系,检查对端局的数据配置。步骤6:检查中继传输

在步骤3的处理过程中提到的中继电路异常一般是指电路状态变为未知、闭塞、故障或未安装态。下面,分别对这几种情况进行说明。

2.1 电路状态为“未知状态”的处理

原因分析:电路状态为“未知”状态的原因是本端发出消息后一直没有收到对端的响应。例如,对这条电路或者这条电路所在的端口发起群复原消息GRS或者电路复原RSC后,如果没有收到对端的响应消息GRA或RLC(TUP中为RLG)电路就会进入此状态;或者发出REL释放消息后没有收到对端的证实消息,RLC电路状态也会变成未知。

处理方法:首先,可以通过网管终端系统自带的七号信令跟踪软件或是其他外挂的七号信令测试仪器来观察本局是否在发群复原消息GRS。如果不发,需要手动对系统进行群复位操作,并观察七号链路信令收发情况,正常情况下本端应该发送群复原消息GRS,对端应该回响应消息GRA。其次,如果群复位不起作用,或者对端交换机不能识别GRS消息,可以用MOD N7TG修改中继群属性,将“群消息超时转单条”设成“是”后,本端发RSC消息后,对端回RLC(TUP中为RLG)消息,之后电路会变成空闲,如果交互过程不对,就要检查两端数据配置及消息格式。最后,在排除硬件故障情况下,如果对端不回响应消息GRA,中继状态肯定会显示“未知”,这时需要双方检查数据配置,尤其注意两端中继电路CIC的一致性。如果对端局发了正确的GRA消息,但是中继状态仍然“未知”,请用LST CIC检查CIC模块表是否有错,是否包含正确的CIC范围值、网标识NI值、DPC值,CIC模块表中每个模块的CIC范围一定要准确,与实际相符;检查中继电路表是否有错,是否有去往同一局向但重复的CIC编码;如果没有错,查询主机里的相应表是否有错,如果有错,联机设定该表,一般均能解决。

2.2 电路状态为“闭塞状态”的处理

原因分析:在维护终端通过命令BLK N7C可以使电路状态变为闭塞,另外当 MPU过载时,主机会根据过载级别闭塞一部分中继电路,MPU占用率下降后,再相应的进行解闭塞的操作(UBL N7C)。国际上规定的闭塞在08机中对应的是闭塞对端,闭塞本端的操作是08机自己的特性,其作用是限制在此电路上的出局呼叫。执行闭塞本端的操作后,不会发出消息去通知对端,对于对端来说,此电路的状态不会发生变化,仍然可以占用并发起呼叫。同样,执行解闭塞本端的操作也不会发出消息去通知对端。

如果对电路进行闭塞对端的操作而没有收到闭塞证实BLA,根据国标,在10~15 s后,重发信号,在发出第一个闭塞/解闭塞信号一分钟后,仍收不到证实,会产生告警,重发闭塞信号仍以1 m in的间隔进行。对解闭塞操作也类似。

处理方法:闭塞是由于对设备的维护需要而进行的操作,对闭塞的处理方法是由闭塞发起方解除闭塞。

2.3 电路状态为“故障状态”的处理

原因分析:中继状态为故障时,可能原因有单板配置、数据配置、电路中断或其他原因而导致的故障。这时,根据查询电路状态返回的不同原因值做相应的处理,可以通过命令DSP N7SYS来查询系统状态,或者在“维护台/七号信令/七号电路查询”,选择“查询系统”来查询。返回值 NULL为正常,表示目的信令点可达,其他的返回值还有目的信令点不可达、断线、帧失步、对端帧失步、对端硬件闭塞、硬件闭塞、话路故障等,可根据实际情况检查相应的数据和硬件情况。

处理方法:首先,如果是由于目的信令点不可达,此时一般需要检查相关的链路数据,可通过维护台七号信令下的“按目的信令点查询链路状态”来确认链路是否正常。

其次,在链路数据确认正确的情况下,需确认传输是否正常,既配置链路的接口框中相应的E1或STU的传输是否正常,如果不正常,可通过分段自环来确认是本端中继板 — 本地DDF架 — 对端DDF架 — 对端中继板哪一段传输线路出现了问题,并且查看有无相关的告警。如果是传输线路的问题,此时一般查询返回的原因中还会包括断线、帧失步、对端帧失步中的一个或几个。

最后,话路故障的原因一般是由于单板故障或是PCM系统故障引起,此原因还应该包括对端硬件闭塞或硬件闭塞,这两个原因一个是对端交换机检测到本端硬件故障,一个是本端交换机检测到硬件故障。HW配置错误、NOD配置错误等也会导致话路故障。措施是检查相应的数据配置和传输。

2.4 电路状态为“未安装状态”的处理

原因分析:电路状态未安装是由于交换机前台没有查询到正确的中继配置数据。

处理方法:首先,需要检查数据配置;是否相应单板配置错误;是否中继电路没有设置;是否中继电路设置成了不可用。其次,应该确认数据配置后是否进行了激活单板的操作。最后,应检查与中继有关的七张表的前后台数据是否一致,如不一致,需要重新发送不一致的表格到前台。

中继七张表具体信息见表1。

表1 中继七张表具体信息

猜你喜欢

信令中继链路
一种移动感知的混合FSO/RF 下行链路方案*
天空地一体化网络多中继链路自适应调度技术
基于Alamouti 码的OFDM 协作系统中继选择算法
自适应多中继选择系统性能分析
浅析民航VHF系统射频链路的调整
基于信令分析的TD-LTE无线网络应用研究
一种IS?IS网络中的链路异常检测方法、系统、装置、芯片
一种基于无线蜂窝网络的共享中继模型
浅谈JSQ-31 V5数字程控用户交换机NO.7及NO.1信令参数设定及不同
LTE网络信令采集数据的分析及探讨