七号信令链路断链等问题的处理步骤.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链路
升级会员 