七号信令链路断链等问题的处理步骤.docx
- 文档编号:7398914
- 上传时间:2023-01-23
- 格式:DOCX
- 页数:24
- 大小:386.97KB
七号信令链路断链等问题的处理步骤.docx
《七号信令链路断链等问题的处理步骤.docx》由会员分享,可在线阅读,更多相关《七号信令链路断链等问题的处理步骤.docx(24页珍藏版)》请在冰豆网上搜索。
七号信令链路断链等问题的处理步骤
深圳市华为技术有限公司
中央研究部文档科
文档编号
产品版本
密级
6.0
产品名称:
共24页
C&C08B七号信令链路断链等问题处理步骤
(仅供内部使用)
文档作者:
______________日期:
____/____/____
开发/测试经理:
______________日期:
____/____/____
产品经理:
______________日期:
____/____/____
管理办:
______________日期:
____/____/____
深圳市华为技术有限公司
版权所有不得复制
C&C08B七号信令链路断链等问题处理步骤
C&C08B七号信令链路断链等问题处理步骤
关键词:
MTP、七号信令链路、RSMII信令链路、链路业务中断(断链)、LPN7板、定位、MTP二层伪消息、消息跟踪
摘要:
本文档详细描述了七号信令链路断链和RSMII信令链路断链等问题的处理步骤,并给出了典型的案例分析。
附录中给出了LPN7板上报的一些重要的MTP二层消息。
1引言
目前,当发生七号断链且不能立即恢复等问题时,用服人员的处理一般都是拔插NO7或LPN7板或DT板或下电复位MPU等进行处理的,这样不利于定位问题,故有必要规范一下处理步骤。
另外,为了方便处理七号断链问题,用服人员应具备基本的七号知识,尤其是底层信令链路的简单定位过程。
一般发现信令链路断链是通过信令链路不可用告警得知,或通过观察七号信令板(NO7或LPN7)的灯状态得知,或通过电话打不通,查看中继、链路状态后得知,等等,不管通过何种途径得知链路断链,首先要定位出哪一条或哪些信令链路出现故障,然后立即按如下步骤进行处理。
2对七号断链等问题的处理步骤的简要描述
步骤1:
跟踪监视七号信令链路
发现问题时,应立即打开相关信令链路的消息跟踪窗口,并把跟踪消息存盘,以供事后分析。
步骤2:
下发伪命令
对LPN7板或3103的NO7板信令链路,可下发调试伪命令0d,使单板能在断链或定位失败时上报详细的原因信息,供步骤4分析消息时使用;
步骤3:
查看链路状态
从维护台直接查看链路状态,可看到当前主机的链路状态信息,以帮助定位原因;
步骤4:
分析信令链路跟踪的消息
对步骤一和步骤二跟踪到的信令消息进行分析,查找断链或定位失败等原因;
步骤5:
查看告警信息
对以前的断链或定位失败等,可通过告警来查看原因。
3对七号断链等问题的详细处理步骤
步骤1:
跟踪监视七号信令链路
发现有信令链路断链时,立即在终端维护系统上选菜单“[七号信令]/[NO7消息跟踪[M]…]”,打开“七号信令跟踪设置”对话框(见图1),模块号为信令链路所在的模块编号,链路号为需要跟踪的信令链路编号,消息类型选SNM、SLT和L2_CHANGE等(若消息量很少或无,可选择所有的消息类型),选中跟踪信息存盘(S)按钮,按确定按钮可打开“七号信令消息跟踪窗口”(见图2)。
图1七号信令链路消息跟踪设置
图2七号信令消息跟踪窗口
注:
“七号信令消息跟踪窗口”(见图2)中消息的说明:
1)选中某一条消息,按“回车键”可看此消息内容的详细解释。
2)消息前加“>”即黑色的消息表明是从此链路上收到的消息,消息前加“<”即蓝色的消息表明是从此链路上发送的消息;消息前不带“>”或“<”的消息是消息传递部分(MTP)二层消息,它一般只在链路中断、链路的定位过程或对信令链路进行统计时才会产生,这类消息是分析断链原因和定位失败原因的最重要的消息。
消息前加“>”或“<”的消息是指信令链路上接收或发送的正式消息信号单元MSU。
3)MTP二层消息的内容:
TIME是指时间,单位是10毫秒,它是一个相对时间,即从开始跟踪信令链路到消息产生时的时间间隔,最大值为65535,到最大值时又从0开始计时;TYPE是指消息类型,是MTP二层的命令(MTP_L2_CMD)还是MTP二层的响应(MTP_L2_REPORT),MTP二层命令是主机发向单板的命令,MTP二层的响应是单板上报主机的响应;PARA是指命令或响应参数,参数一是指单板类型,00是LPN7板,01是NO7板,后面参数是命令或响应字及内容等,参见消息的详细解释。
注意:
后面对此类消息的举例时只用参数一后面的内容。
对“七号信令消息跟踪窗口”(见图2)中的第一条消息可简单解释如下:
在启动消息跟踪窗口后的19.7秒,MTP向此信令链路下发STOP命令。
4)链路上发送的MSU消息内容:
Service是指消息的业务指示,其中信令链路测试消息用TEST表示,MTP部分的信令网管理消息用MTP表示,TUP、ISUP、SCCP等的消息分别用TUP、ISUP、SCCP等表示;SubSer是指子业务字段,即网络指示NI,NAT是指国内网,INT是指国际网等;Time是消息产生的时间,单位是10毫秒,它是一个相对时间,即从开始跟踪信令链路到消息产生时的时间间隔,最大值为65535,到最大值时又从0开始计时;H1H0是指消息的标题码,标识具体的消息;CIC/SLC对TUP、ISUP消息是电路识别码(CIC),对MTP消息则是信令链路编码(SLC),对SCCP消息则是信令链路选择码(SLS);SLS是指信令链路选择码,对ISUP消息才显示,对其它消息则不显示;OPC是指消息中的起源信令点编码;DPC是指消息中的目的信令点编码;SignalMessage是指此消息的具体内容。
步骤2:
下发伪命令
在终端维护系统上选菜单“[七号信令]/[伪消息]/[MTP二级伪消息[S]…]”,打开“MTP二级伪消息”对话框(见图3),模块号为断链的信令链路所在的模块编号,链路号为断链的信令链路编号,MTP命令设置为0d,参数1~参数7设置为ff,按确定按钮发出开始测试命令。
下发此伪命令的目的是为了使信令链路在断链或定位不成功时,上报详细的原因信息,以帮助定位问题。
图3MTP二级伪消息
步骤3:
查看链路状态
注意:
一定要记录所查看的信令链路状态信息。
1)从链路所在模块查链路状态
a.在终端维护系统上选菜单“[七号信令]/[状态查询[S]…]”,打开“七号信令相关状态查询”对话框(见图4),查询类型选链路状态,内部模块号为断链的信令链路所在的模块编号,模块号是指到哪个模块查询链路状态,此处就等于内部模块号,链路号为断链的信令链路编号,选确定按钮可查看“信令链路状态”,结果窗口见图5。
图4查看链路状态
图5链路状态查询结果窗口
b.若链路的激活状态为“否”,则可能是人为的断开信令链路了,进行如下操作恢复:
在终端维护系统中选菜单“[七号信令]/[链路管理[L]…]”,打开“七号链路管理”对话框(见图6),选择命令(S)选激活链路,模块号为发生断链的信令链路所在的模块编号,链路号为断链的信令链路编号,选确定按钮“激活”此链路;
图6七号链路管理
c.若链路有远端处理机故障,则一般是对局原因,要联系对局进行处理,等远端处理机故障恢复后才能使信令链路变为可用。
对于NO.7板,远端处理机故障时相应链路的LP1或LP2指示灯是灭的。
d.对LPN7板信令链路,若链路的传输业务状态为“是”,而链路的故障状态有时为“是”(多数),有时为“否”,链路的倒换正在进行状态为“是”,若处于这种情况,则链路定期闪断(约10几秒种闪断一次),从“七号信令消息跟踪窗口”看,只有收到的SLTM消息,而本端未发出任何消息,而且在链路定位成功后一般由本端MTP三层下发STOP命令断开链路。
若处于这种状态,并且传输正常,若在2分钟之内没有恢复则只有复位LPN7板或拔插LPN7板解决。
若处于这种状态,并且传输一直不正常,则最好先复位或拔插LPN7板,然后再断开受影响的LPN7板信令链路,等传输恢复后再激活信令链路。
(详见后面的案例分析)
2)从其它七号模块查询断链的链路状态
a.在上述查看链路状态的操作中,把模块号改为其它模块的模块号即可。
例如,要从2号SM模块查看1号SM模块4#链路的链路状态,则模块号为2,内部模块号为1,链路号为4。
b.若传输业务状态与从链路所在模块查询不一致,则要在链路所在的模块使用“七号链路管理”(见图6)来消除状态的不一致。
一般不一致是这种情况:
链路所在模块是传输业务的,但其它模块认为此链路不能传输业务,其它情况一般很快会恢复的。
若有多条信令链路传输业务,则管理禁止信令链路,查询链路状态,确信链路不能传输业务时再解除管理禁止使信令链路传输业务;若只有一条信令链路传输业务,则不能管理禁止,只有断开信令链路,确信链路不能传输业务时再激活信令链路使信令链路能传输业务。
(详见后面的案例分析)
若进行处理时链路已经恢复了,则通过下面的步骤5来查看“信令链路业务中断”和“信令链路定位失败”的告警信息来查看断链原因,否则进行下面的步骤4进行处理。
步骤4:
分析信令链路跟踪的消息
a.对LPN7板的信令链路或3103版本的NO7板信令链路,若信令链路业务中断,则单板会通过命令字e0、e1、e2上报许多原因信息(见图7七号信令消息跟踪窗口的断链示例),从中可看出链路定位失败或业务中断的原因。
详细的原因见后面的附录,下面对通常定位失败和业务中断的原因解释一下。
(对LPN7板原因更详细些)
图7七号信令消息跟踪窗口(断链示例)
b.若单板上报e00102,则断链是由于MTP三层下发停止(STOP)命令使信令链路业务中断的,可能的原因是本端连续(间隔6秒)发出两条信令链路测试消息(SLTM)后,而对端局不回信令链路测试证实消息(SLTA),则在第一次发出SLTM消息12秒后断链,这是协议要求的,从跟踪的消息可很容易看出此情况(第一次发出SLTM消息的时间与下发STOP命令之间的时间差约等于12秒)。
也有可能是在链路定位成功后,本端发不出任何消息,12秒后MTP三层下发STOP命令断链,这就是步骤3中1)-d中的现象,参见上面的处理方法。
若是刚开局,从来还未对接成功过,则要检查数据配置,否则要联系对局进行处理。
也有可能是人为地断开信令链路造成此消息上报的。
c.若单板上报e00108,并且前面上报e10016(见图7中的情况),则定位失败是由于收不到对端的链路状态信号单元――失去定位(LSSU-SIO)信号,如果同时有大量的e30301上报,则是LPN7板收不到对端的任何信号。
LPN7板的信令链路一般是下发定位命令后,30秒种后上报上述信息(3103的NO7板则是约67秒钟后上报上述信息)。
可能的原因一是数据配置错误,即链路所占中继时隙与对端没对上(还未开通情况),联系对端局检查数据配置是否正确;二是由于链路中断时间过长,对端局把信令链路去激活了,一般1240和NEC的机器都有此功能,联系对端局把链路激活即可。
若最终都不能恢复,则在可能的情况下(不会大量影响业务)复位或拔插LPN7板来试一下。
d.若单板上报e00108,并且前面上报e10019,则定位失败是由于链路上误码率过高造成的,一般此种情况在多次定位后能够定位成功。
主要是要检查线路的误码率和本端的时钟配置等。
e.若单板上报e0010F,则断链是由于对端局断链,一般是对端局原因,由对端局查找原因来解决比较方便。
但若跟踪链路上有e20101(LPN7板发送错)的消息上报,则也可能是08机的LAP板硬件原因造成链路上发送的消息有误使对端局断链(误码过高或其它原因),此时应联系公司相关部门来解决。
f.若单板上报e00112,则断链是由于线路上误码率过高引起的,应检查传输和时钟,必要时使用相关仪器检测信令链路的误码率。
七号信令链路要求的线路长期误码率小于10-6。
g.若单板上报e00115,则断链是本端发出MSU后,对端局没有在给定时间内(LPN7板1.5秒,3103的NO7板为2秒)告诉本端已收到此消息,即消息证实延迟过长造成断链的。
根据跟踪的消息时间信息,大约判断哪一条消息对端没给出证实,然后联系对端局看是否收到此消息,若收到则是对端局原因,由对端局解决;若对端未收到此消息,则要用仪器监视信令链路,看链路上是否发出了此消息,消息内容是否正确等,若链路上有此消息且消息无误,则要由对端局查原因。
h.若单板上报e20201,则断链或定位失败一般是LPN7板发不出信号的原因造成的,可能是LPN7板的原因造成的(只是有些临时的2101LPN7板才有此问题,其它一般无此问题),拔插LPN7板可解决此问题。
步骤5:
查看告警信息
a.对2102或正式的2101版本的LPN7板的信令链路或3103版本的NO7板信令链路,若信令链路业务中断或定位失败,可通过查看告警得出信令链路业务中断的原因和定位失败的原因。
若是R002或R003B版本,则在事件告警窗口查看“信令链路业务中断”(告警编号588)和“信令链路定位失败”(告警编号587)的告警信息来查看断链原因;若是R003E或更高的版本,则在BAM上查看调试告警历史文件(一般在\CC08\BAM\WARN\HISTORY目录下的TXT文件),“信令链路业务中断”的告警编号为31022和“信令链路定位失败”的告警编号为31023,从中查看断链原因。
告警中的第一个参数为信令链路的板号,第二个参数信令链路所在板的通道号,第三个参数为断链原因值或定位失败原因值。
具体的原因值参见附录,下面对一些通常的原因进行解释。
b.若“信令链路业务中断”的告警参数为020102,则是板号为2的七号板上通道为1的信令链路即9#信令链路业务中断(即断链),断链原因是MTP三层下发STOP命令,查看其它告警,一般有关于此链路的“信令链路测试失败”的告警产生。
一般是由本端发出测试消息SLTM后对端没有回测试证实消息SLTA或本端发不出测试消息SLTM,具体处理参见上面的步骤4中的相关部分;
c.若“信令链路业务中断”的告警参数为020108,则是板号为2的七号板上通道为1的信令链路即9#信令链路业务中断(即断链),断链原因是信令链路定位不可能,再查看“信令链路定位失败”的告警,从中可查找定位不可能的原因。
例如:
“信令链路定位失败”的告警参数为020116,即是本端信令链路收不到对端的链路状态信号单元LSSU-SIO。
d.若“信令链路业务中断”的告警参数为020112,则是板号为2的七号板上通道为1的信令链路即9#信令链路业务中断(即断链),断链原因是误码率过高断链的,要检测信令链路的传输质量。
4对RSMII断链等问题的处理
对RSMII信令链路的处理可与前面七号断链一样进行处理,但注意以下的问题:
1、跟踪监视RSMII信令链路时,由于RSMII上传输的消息不是标准的消息信号单元MSU,故后台是作为“未知消息”显示的,即在“七号信令跟踪设置”对话框(见图1)中消息类型要选UNKNOWN,这样才能看到信令链路上传输的消息,后台是用红色进行显示的;
后台显示的RSMII链路高层消息的格式如下:
时间的
低字节
时间的
高字节
方向字节
消息长度低字节
消息长度高字节
8E
RSMII消息内容
RSMII消息内容的格式如下:
发送者模块号
发送者进程号
接收者模块号
接收者进程号
消息长度
通道号
序号:
14
包类型:
2
信息内容
其中“包类型”的含义:
00单包01第一包10中间包11最后包
2、在98.4.14号以前的所有版本中,只能跟踪RSMII信令链路的二层消息,在98.4.14号以后的V610R002、V610R003版本中都可在本端跟踪RSMII链路上的所有消息,但只能在本端模块跟踪RSMII信令链路消息,而不能在远端RSMII模块跟踪信令链路的消息;
3、在98年1月10日以后的所有R001、R002、R003版本中,配置RSMII的MTP链路数据时,不再需要配置MTP目的信令点表、MTP路由表、MTP链路集表等,只需要配置MTP链路表。
若多余配了MTP目的信令点表,则会引起MTP目的信令点故障告警,且不能恢复。
另外,注意MTP链路表中的链路集号一定要小于“公共最大元组数”中的MTP链路集数,否则会引起RSMII模块不加载等问题。
另外,对RSMII模块,在“模块描述表”中的“是否安装七号电路”应设为“否”。
4、因市场上的许多MTP数据配置中,仍沿袭以前的配置,即MTP目的信令点表、MTP链路集表、MTP路由表中都配置了RSMII的相关数据,这在RSMII模块较多时,数据较复杂,容易引起混淆、错误等,故现在都应删除MTP目的信令点表、MTP链路集表、MTP路由表中的RSMII相关数据,简化MTP的这几张表格。
但删除数据时应注意以下几点:
●在R002、R002、R003B以及1998年9月3日前的R003E、R003I版本中,MTP目的信令点表的目的信令点索引和MTP链路集表中的链路集号必须连续,从0开始配置,故删除数据后要重新修改MTP的所有表格(MTP目的信令点表、MTP链路集表、MTP路由表、MTP链路表等)。
在1998年9月3日后的R003E、R003I版本中,MTP目的信令点表的目的信令点索引和MTP链路集表中的链路集号可以不连续了,故删除时只需要删除MTP目的信令点表、MTP链路集表、MTP路由表中的相关数据即可;
●删除数据并重新修改数据后,在MTP链路表中,有可能RSMII的链路集号与一般的出局七号链路集号重复或RSMII的链路集号夹杂在出局七号链路集中等,这虽然对主机运行来说没有任何问题,但容易引起数据上的误解,扩充链路也不太方便等,故在今后开局、升级或大改造时,建议按如下的方案配置或修改数据:
1)根据本局今后扩容能连的相邻目的信令点数和能带的RSMII模块数的最大值,估算出最大的MTP链路集数(每个相邻目的信令点需要一个链路集,每个RSMII模块需要两个链路集),然后设置“软件参数表”中的MTP链路集的公共最大元组数,使之大于或等于估算值,例如80或100,但也不要太大;2)把出局七号链路集号从小到大(从0开始)开始配置,而RSMII的链路集号从大到小开始配置,这样RSMII链路与一般的七号出局链路的链路集号就不会重复或混淆了,数据上比较清晰。
5案例分析
1、【现象描述】到同一局向的分布在不同模块中的中继电路状态不一致:
一个SM模块的中继电路状态为空闲,另一个SM模块的中继电路状态为故障,且通过查询系统知故障原因为DPC不可达。
模块间通讯状态一切正常。
从中继电路故障的模块查讯到此局向的目的信令点状态为不可达,而从中继电路空闲的模块查讯到此局向的目的信令点状态为可达。
【原因分析】造成此现象的原因是模块间链路状态的不一致。
在此之前到此局向的链路曾故障过,故障状态向其它模块广播了,并且成功了,但链路恢复后,状态广播由于某种未知的原因没有成功,故中继故障的模块就一直认为DPC不可达,从而中继一直故障。
【解决措施】确认模块间状态通讯正常,若到此局向有多条链路,则先管理禁止到此局向的信令链路,查询链路状态确认链路已不能传输业务时,再解除管理禁止信令链路;若到此局向只有一条信令链路,则先断开到此局向的信令链路,查询链路状态确认链路已不能传输业务时,再激活信令链路。
最后在故障中继的模块目的信令点状态和中继的状态,一般都能恢复正常。
2、【现象描述】LPN7板的某链路在开通业务的过程中,突然打不通任何电话(若只有此一条链路)或呼损极高,观察LPN7板的七号链路,链路间隔13-14秒左右闪断一次。
从告警台可以看到每隔13-14秒左右出现一条“信令链路测试失败”的告警。
查看链路状态,一般是链路传输业务、故障、拥塞、倒换正在进行等状态都为“是”。
跟踪七号信令链路,可以看到链路每隔13-14秒钟下发STOP命令和开始定位命令,但定位成功后能看到接收的测试消息,但看不到任何发出的消息。
如果没有人工干预,链路将始终如此,不能自动恢复。
【原因分析】因为链路始终处于“倒换正在进行”状态,说明链路业务中断后,进行倒换,但倒换没有结束。
根据MTP三层的程序,对NO7板的链路不会出现此问题,而对LPN7板的链路,倒换时MTP三层下发“回收BSNT”或“回收二层消息”的命令,若收不到相应的响应,则LPN7板的链路就会处于“倒换正在进行”状态。
在R001、R002、R003版本中MTP会在3分钟之内进行干涉(激活链路等),时间的长短是随机的。
在链路处于倒换正在进行状态下,MTP三层认为此链路仍然可以传业务,即链路的三层缓冲区仍然可以接收用户部分的消息,但实际上除测试消息和管理禁止消息外并不把消息发到二层,这就有可能在链路经过干涉(激活链路等)定位成功时,链路的三层缓冲区已满了(取决于业务量的大小和链路干涉的时机),从而造成链路的三层缓冲区不能再接收任何消息,测试消息也不能发出去,所以链路一直测试失败,不能开通业务。
所以会一直有“信令链路测试失败”的告警产生,跟踪链路看不到发出的任何消息。
【解决措施】一般产生此问题的时候,都和调整传输有关,即链路不稳时出此问题。
当出现此问题时,只能拔插LPN7板或复位LPN7板来实现。
在9月24日以后的版本通过软件可以解决,链路不正常的时间最多为3分钟,当传输稳定后,链路会在3分钟之内恢复正常。
3、【现象描述】RSMII模块不能加载,从内部七号链路的灯状态来看,链路能定位成功,但每隔7秒多钟闪断一次。
【原因分析】通过七号信令消息跟踪窗口跟踪本端的RSMII链路消息(消息类型要选UNKNOWN和L2_CHANGE),若本端是LPN7板或3103的NO7板信令链路,则利用MTP二层伪命令0d可看到断链原因:
是远端RSMII模块先断链的。
并且在链路定位成功后,只收到对端的一条红色的消息,然后再无任何红色的消息,7秒种以后断链。
收到的一条红色的消息是RSMII模块向本端模块请求自己的模块号,而本端没有响应。
原因一可能是RSMII模块的链路集号超过MTP链路集的最大元组数;原因二可能是“信令链路表”中没有配置此RSMII模块的对应数据。
【解决措施】确认上述两种可能的原因,修改后就可以了。
若仍然恢复不了,则要检查相关数据。
6附录
以下的命令都可通过“MTP二级伪消息”下发到相应的信令链路,“MTP命令”填下面的命令字即可,参见上面的步骤二下发伪命令的方法。
6.1告警解释
【1】“信令链路业务中断”告警参数值的含义
02HMTP三层发来停止(STOP)命令。
08H起始定位控制(IAC)报告定位不可能。
09H接收控制(RC)报告链路故障(由于异常的BSN)。
0AH接收控制(RC)报告链路故障(由于异常的FIB)。
0CH接收控制(RC)报告SIO收到。
0DH接收控制(RC)报告SIN收到。
0EH接收控制(RC)报告SIE收到。
0FH接收控制(RC)报告SIOS收到。
12H信号单元误码率检测(SUERM)报告链路故障。
13H链路状态控制(LSC)报告T1定时器溢出。
14H发送控制(TXC)报告链路故障(由于T6超时-信令链路拥塞时间过长)。
15H发送控制(TXC)报告链路故障(由于T7超时-消息证实延迟过长)。
【2】“信令链路定位失败”告警参数值的含义
0FH接收控制(RC)报告SIOS收到。
16H未定位定时器(T2=30秒)超时。
17H已定位定时器(T3=1.3秒)超时。
19H定位误码率接收过程(AERM)中止验证。
1BH链路
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 七号信令链路断链 问题 处理 步骤
![提示](https://static.bdocx.com/images/bang_tan.gif)