本发明涉及 IP网络信令传输协议（ SIGTRAN协议 ),尤其涉及 IP网络 信令传输故障的处理方法及装置。 背景技术

随着 IP网络技术的逐步成熟，出现了在 IP网络上传输七号信令等电路 交换信令协议的需求。 为了满足在 IP网络上传输信令协议的需求， 互联网 工程任务组（ IETF, The Internet Engineering Task Force )组成立了专门的信 令传输小组， 他们所制订的 IP 网络信令传输协议（SIGTRAN协议） 支持 通过 IP网络传输传统电路交换信令。 2006年 IETF工作组正式发布了消息 传输协议 （MTP , Message Transfer Protocol ) 第三级用户的适配层协议 ( M3UA, Signaling System 7 ( SS7 ) Message Transfer Part 3 ( MTP3 )-User Adaptation Layer, RFC4666 ), M3UA协议用来实现承载在 IP网络上的信令 消息的可靠有序传递。

电信网络的发展趋势是信令 IP化和容灾备份 (包括信令网和传输网的 容灾备份）,在 IP网络信令中常从容灾备份的角度考虑釆用多� ��传输网通路 来传输 IP网络信令消息。而 IP传输网络由于所经过的路由器以及传输介质 的不同， 传输网络常常存在一些差异性， 经常发生一个传输网络丟包严重 质量很差， 而另外的一个传输网络却从来不丟包质量很好 ； 这种传输网络 的差异性在 IP网络信令层表现为 IP通路的拥塞情况不同， 一般对一个 IP 网络信令 M3UA协议而言看到的是一个个 IP通路偶联，而看不到底层具体 的哪个 IP通路偶联走的哪个 IP传输网络， 即上层 IP网络信令 M3UA对底 层 IP通路偶联都是一视同仁不区分对待的。 由于这个特性就引入了一个问 题， 当一个 IP传输网络发生问题时， 对 IP网络信令 M3UA而言就是承载 在这个 IP传输网络上的 IP通路偶联发生拥塞，根据协议只要发生偶联� ��塞 就需要上报业务局向拥塞，进而导致一个 IP网络信令 M3UA局向发生拥塞， 并导致业务开始进行流量控制。 由于一个 IP传输网络存在问题， 因此这个 拥塞情况长时间得不到改善而一直保持拥塞状 态， 这样业务流量控制就会 不断的加剧业务负荷流控的级别， 可以正常承担的业务流量会不断的由于 流量控制而降低到越来越少， 严重情况下会导致流控过度而发生呼叫全部 控制的瘫局故障。 而在已知的现有技术中还没有一个协议和方案 能很好的 解决这个问题。 发明内容

本发明要解决的主要技术问题是， 提供一种 IP网络信令传输故障的处 理方法及装置， 解决因 IP网络信令传输平面故障而导致的业务中断问� ��。

为解决上述技术问题，本发明提供一种 IP网络信令传输故障处理方法, 包括：

当节点接收到局向到另一个节点的 IP信令链路拥塞报文后， 判断发生 拥塞的 IP信令链路比例是否超过预设的拥塞上报门限� ��

发生拥塞的 IP信令链路比例未超过所述拥塞上报门限时， 不上报业务 局向拥塞； 发生拥塞的 IP信令链路比例超过所述拥塞上报门限时， 上报业 务局向拥塞。

进一步地， 当节点收到局向到另一个节点的 IP信令链路拥塞报文后， 该方法还包括： 对发生拥塞的 IP信令链路设置拥塞标记， 禁止发生拥塞的 IP信令链路承担业务负荷。

进一步地， 所述对发生拥塞的 IP信令链路设置拥塞标记， 禁止发生拥 塞的 IP信令链路承担业务负荷， 具体包括： 在动态路由表中将发生拥塞的 IP信令链路标记为拥塞态， 使业务负荷动态路由在选路时禁止选择标记为 拥塞态的 IP信令链路。

进一步地， 所述上报业务局向拥塞之后， 该方法还包括：

统计动态路由表中标记设为拥塞态的 IP信令链路的数量；

当一个信令局向的所有 IP信令链路都标记为拥塞态时，使所有 IP信令 链路均勾分担业务负荷。

进一步地， 当节点接收到局向到另一个节点的 IP信令链路的解除拥塞 报文后， 该方法进一步包括以下步骤：

触发预先设定的定时器， 开始计时；

在所述定时器到时之前， 不向解除拥塞的 IP信令链路分配业务负荷。 该方法还包括： 在所述定时器计时期间检测所述解除拥塞的 IP信令链 路的故障是否真正恢复， 具体为：

在所述解除拥塞的 IP信令链路上发送心跳消息；

检测所述心跳消息是否导致所述 IP信令链路再次发生拥塞， 如果是， 判定所述解除拥塞的 IP信令链路的故障没有真正恢复，则继续对所� �� IP信 令链路设置拥塞标记； 如果定时器到时， 发送的心跳消息没有导致所述 IP 信令链路再次发生拥塞，判定所述解除拥塞的 IP信令链路的故障真正恢复， 则取消所述 IP信令链路的拥塞标记。

本发明还提供了一种 IP网络信令传输故障处理装置， 该装置包括： 判断单元， 用于当节点接收到局向到另一个节点的 IP信令链路拥塞报 文后， 判断发生拥塞的 IP信令链路比例是否超过预设的拥塞上报门限� �� 报文发送单元， 用于当所述判断单元的判断结果是发生拥塞的 IP信令 链路比例未超过所述拥塞上报门限时， 不上报业务局向拥塞； 还用于当所 述判断结果是发生拥塞的 IP信令链路比例超过所述拥塞上报门限时， 上报 业务局向拥塞。

该装置还包括： 标记设置单元， 用于在动态路由表中将发生拥塞的 IP 信令链路标记为拥塞态， 使业务负荷动态路由在选路时， 禁止选择标记为 拥塞态的 IP信令链路。

该装置还包括： 统计单元， 用于统计动态路由表中标记设为拥塞态的 IP信令链路的数量；

业务分配单元， 用于根据所述统计单元的统计结果， 当一个信令局向 的所有 IP信令链路都标记为拥塞态时，使所有 IP信令链路均勾分担业务负 荷。

该装置还包括： 定时器单元， 用于当节点接收到局向到另一个节点的

IP信令链路的解除拥塞报文后， 触发预先设定的定时器， 开始计时；

相应的， 所述标记设置单元， 还用在所述定时器到时之前保持解除拥 塞的 IP信令链路的拥塞标记；

心跳发送单元， 用于在所述定时器计时期间， 向解除拥塞的 IP信令链 路上发送心跳消息；

检测单元， 用于检测所述心跳消息是否导致所述解除拥塞 的 IP信令链 路再次发生拥塞， 如果是， 则控制所述标记设置单元继续对所述解除拥塞 的 IP信令链路设置拥塞标记； 如果所述定时器到时后， 发送的心跳消息没 有导致所述解除拥塞的 IP信令链路再次发生拥塞， 则控制所述标记设置单 元取消所述解除拥塞的 IP信令链路的拥塞标记。

本发明的有益效果是：

本发明避免了现有技术中一旦部分 IP信令链路发生拥塞， 业务进行负 荷流量控制进而导致业务呼叫损失甚至瘫局的 故障， 解决了 IP信令传输平 面故障导致业务中断的问题。 通过本发明， 可以从机制上最大程度的避免 由于传输平面故障导致业务过度进行负荷控制 ， 使得单平面的传输故障， 对业务不可见对业务不产生任何负面的影响。 对于目前的 IP信令组网下， 优化通信网络提高用户服务质量有非常重要的 意义。 附图说明

图 1是 M3UA协议栈结构图；

图 2是正常情况下的业务负荷分担图；

图 3是发生 IP传输平面故障下的业务负荷分担图；

图 4是本发明一种实施例的结构示意图；

图 5是本发明一种实施例的流程图；

图 6是本发明另一种实施例的结构示意图；

图 7是本发明另一种实施例的流程图。 具体实施方式

下面通过具体实施方式结合附图对本发明作进 一步详细说明。

针对目前的 IP信令组网，本发明对到一个信令局向的 IP信令链路设置 一个拥塞上报门限。 当发生拥塞的 IP信令链路比例未超过设定的门限值时 不上报业务信令局向拥塞， 当发生拥塞的 IP信令链路比例高于设定的门限 值时上报业务信令局向拥塞。 避免了现有技术中一旦部分 IP信令链路发生 拥塞， 即导致业务进行负荷流量控制的缺陷， 使当部分 IP信令链路发生拥 塞时， 只要不超过设定的拥塞上报门限， 就不进行上报， 即不会引起流量 控制， 可以正常承担的业务流量不会减少， 避免了只因部分甚至少部分 IP 信令链路故障而导致的业务呼叫损失甚至瘫局 的故障。

实施例一：

请参考图 1 , 图 1所示的实施例为 SIGTRAN协议栈结构图， 包括两个 节点 NODE A和 NODE B , —个为源信令节点， 另一个为目的信令节点。 本实施例中， 节点 NODE A和 NODE B包括 IP层、 流控传输协议（ SCTP , Stream Control Transmission Protocol )层、 M3UA层、 信令连接控制部分 ( SCCP ) 和事务处理能力应用部分 （ TCAP , Transaction Capabilities Application Part )„ M3UA协议模块的上层业务模块为 SCCP业务模块， 底 层承载在 IP传输网络之上。 M3UA协议模块通过 IP传输网络 1、 IP传输网 络 2为 SCCP业务模块提供可靠有序的业务传递功能。

如图 2所示， 当 IP传输网络没有发生故障， 所有 IP信令链路都正常 时， NODE A到 NODE B 的业务负荷在 IP信令链路 IPLinkl-IPLink8之间 进行负荷均匀发送， 同样 NODE B 到 NODE A的业务负荷也在 IP信令链 路 IPLinkl-IPLink8之间均匀负荷分担。 即 IP传输平面 A-R1-B、 A-R2-B没 有异常时， IPLinkl-IPLink4承担 50%的业务负荷流量， IPLink5-IPLink8承 担 50%的业务负荷流量。

如图 3所示，当 IP传输网络发生故障， NODE A到 IP路由器（Router ) 1 路径发生异常， 丟包导致 IP通路拥塞。 该异常可能是 IP Routerl发生异 常， 导致 IP 信令链路 IPLinkl-IPLink4 拥塞， 也可能是 IP 信令链路 IPLinkl-IPLink4中的某个或某些链路异常导致部分 拥塞。

本实施例解决 IP网络信令传输故障的处理装置如图 4所示， 包括判断 单元 41和报文发送单元 42。 判断单元 41用于当节点接收到局向到另一个 节点的 IP信令链路拥塞报文后，判断发生拥塞的 IP信令链路比例是否超过 预设的拥塞上报门限； 报文发送单元 42与判断单元 41相连， 用于当判断 单元 41的判断结果是发生拥塞的 IP信令链路比例未超过所述拥塞上报门限 时， 不上报业务局向拥塞； 还用于当判断结果是发生拥塞的 IP信令链路比 例超过所述拥塞上报门限时， 上报业务局向拥塞。 流控单元 44响应到报文 发送单元 42发出的业务局向拥塞报文后， 对节点的业务流量进行控制， 例 如减少业务流量。

发生拥塞的 IP信令链路比例的计算可以釆用现有技术的计� ��方法， 例 如：将到一个局向的发生拥塞的 IP信令链路数量除以根据协议（例如 M3UA 协议）所设定的到一个局向的所有 IP信令链路数量，得出发生拥塞的 IP信 令链路比例。 如果发生拥塞的 IP信令链路比例未超过所述拥塞上报门限时， 不进行 业务局向拥塞的上报， 而此时如果在业务负荷分担方面仍釆用均匀分 担， 即仍然坚持在存在故障的传输通路上传送业务 消息， 丟包重传拥塞等异常 会导致业务消息时延加大而引起通讯服务质量 下降。 为解决这一问题， 如 图 4所示， 处理装置还进一步包括标记设置单元 43 , 标记设置单元 43用于 对发生拥塞的 IP信令链路设置拥塞标记，使发生拥塞的 IP信令链路不承担 业务负荷。具体是，通过在动态路由表 45中将发生拥塞的 IP信令链路标记 为拥塞态， 使业务负荷动态路由在选路时不选择标记为拥 塞态的 IP信令链 路， 避免加重拥塞情况并提高通讯服务质量。

本实施例中 , 判断单元 41还与 M3UA协议模块 40相连， M3UA协议 模块 40负责接收 IP信令链路的拥塞报文， 并提供给判断单元 41。 在其他 的实施例中， 根据源信令节点和目的信令节点之间传输的信 令协议， 也可 以是其他协议模块负责接收 IP信令链路的拥塞报文。 根据具体的要求， 报 文发送和接收也可以由同一个协议模块完成。

当所有的 IP信令链路都发生拥塞后， 虽然已经上报业务局向拥塞， 进 行流量控制， 但可能仍有少量的业务需要通过 IP信令链路传输， 此种情况 下， 处理装置还进一步包括统计单元 46和业务分配单元 47, 如图 4所示， 统计单元 46用于统计动态路由表 45中标记设为拥塞态的 IP信令链路的数 量； 业务分配单元 47, 用于根据统计单元 46的统计结果， 当一个信令局向 的所有 IP信令链路都标记为拥塞态时，使所有 IP信令链路均勾分担业务负 荷。

基于本实施例的装置的一种处理方法实例如图 5所示， 包括以下步骤： 步骤 51 ,事先对到一个信令局向的 IP信令链路设置一个拥塞上报门限， 当节点接收到局向到另一个节点的 IP信令链路拥塞报文后， 执行步骤 52。

步骤 52, 在接收到 IP信令链路拥塞报文后， 对发生拥塞的 IP信令链 路设置拥塞标记， 使发生拥塞的 IP信令链路不承担业务负荷， 即通过在动 态路由表中将发生拥塞的 IP信令链路标记为拥塞态， 使业务负荷动态路由 在选路时不选择标记为拥塞态的 IP信令链路， 而是将所有的业务负荷都通 过其他正常的 IP信令链路传输。

步骤 53 , 获取发生拥塞的 IP信令链路比例， 判断发生拥塞的 IP信令 链路比例是否超过预设的拥塞上报门限， 如果是则执行步骤 54, 上报业务 局向拥塞； 否则执行步骤 55 , 不上报业务局向拥塞。

其中，步骤 52是为避免仍然坚持在已经拥塞的 IP信令链路上传送业务 负荷， 步骤 52还可以在步骤 53之后。

在改进的实施例中， 如图 5所示， 在对发生拥塞的 IP信令链路设置拥 塞标记后、 且上 业务局向拥塞之后， 还进一步包括以下步骤：

步骤 56, 统计动态路由表中标记设为拥塞态的 IP信令链路的数量， 判 断是否所有的 IP信令链路都发生了拥塞， 如果是则执行步骤 57, 否则转向 步骤 51。

步骤 57, 当一个信令局向的所有 IP信令链路都标记为拥塞态时， 使所 有 IP信令链路均勾分担业务负荷， 这样可避免业务流量无法分发。

上述实施例中， 根据需要， 步骤 53和步骤 52的顺序还可以互换， 依 然可以达到本实施例的效果。

实施例二：

如图 6所示， 本发明解决 IP网络信令传输故障的处理装置包括： 判断 单元 61、 文发送单元 62和标记设置单元 63; 判断单元 61分别与 M3UA 协议模块 60和报文发送单元 62相连。 判断单元 61根据 M3UA协议模块 60接收到的 IP信令链路的拥塞报文， 判断发生拥塞的 IP信令链路比例是 否超出拥塞上报门限， 报文发送单元 62根据判断单元 61的判断结果确定 是否上报业务局向拥塞。标记设置单元 63对发生拥塞的 IP信令链路设置拥 塞标记。 与实施例一不同的是， 该处理装置还包括： 定时器单元 66、 心跳 发送单元 67和检测单元 68 , 用于对发生拥塞的 IP信令链路在解除拥塞后 进行处理。 定时器单元 66, 用于当节点接收到局向到另一个节点的 IP信令 链路的解除拥塞报文后， 根据预先设定的定时器进行计时； 心跳发送单元 67, 用于在定时器计时期间， 向已经解除拥塞的 IP信令链路上发送心跳消 息； 检测单元 68, 用于检测所述心跳消息是否导致该 IP信令链路再次发生 拥塞，如果是，则控制标记设置单元 63继续对该 IP信令链路设置拥塞标记 或保持拥塞标记不变， 并控制心跳发送单元 67停止发送心跳消息， 和控制 定时器单元 66取消定时器计时； 如果定时器到时， 后发送的心跳消息都没 有导致该 IP信令链路再次发生拥塞， 则控制标记设置单元 63取消该 IP信 令链路的拥塞标记。

基于本实施例的装置， 当节点接收到局向到另一个节点的 IP信令链路 的解除拥塞报文后， 其处理流程如图 7所示， 包括以下步骤：

步骤 71 , 接收 IP信令链路的解除拥塞报文， 当接收到后执行步骤 72。 步骤 72, 触发预先设定的定时器开始计时， 并且在定时器到时之前保 持该 IP信令链路的拥塞标记，即在定时器到时之前� ��向解除拥塞的 IP信令 链路分配业务负荷， 然后执行步骤 73。

步骤 73 , 在定时器计时期间， 在已经解除拥塞的 IP信令链路上发送心 跳消息数据， 心跳消息数据可以是定时发送， 然后执行步骤 74。

步骤 74, 判断心跳消息是否导致该 IP信令链路再次发生拥塞， 即检测 是否收到该 IP信令链路再次发生拥塞的报文， 如果是则执行步骤 75 , 否则 执行步骤 77。

步骤 75 , 当检测到一次发送的心跳消息导致该 IP信令链路再次发生拥 塞的报文后， 则继续对该 IP信令链路设置拥塞标记，使该 IP信令链路仍然 不承担业务负荷。 并执行步骤 76, 停止发送心跳消息并取消定时器。 步骤 77,如果本次发送的心跳消息没有导致该 IP信令链路再次发生拥 塞， 则判断定时器是否到时， 如果是则执行步骤 78 , 否则转向步骤 73 , 继 续向已经解除拥塞的 IP信令链路上发送心跳消息数据。

步骤 78, 取消该 IP信令链路的拥塞标记， 即对该 IP信令链路设置不 拥塞标记， 即在动态路由表中将发生拥塞的 IP信令链路标记为不拥塞态， 使业务负荷动态路由在选路时可选择该 IP信令链路承担业务。

本实施例在 IP信令链路的拥塞解除后，并不立即向该 IP信令链路分配 业务负荷， 而是先对该 IP信令链路进行测试，确认该 IP信令链路确实正常 后才向该 IP信令链路分配业务负荷。本实施例避免了解� ��拥塞的 IP信令链 路在承担业务后马上又发生拥塞， 而一取消业务又恢复正常的抖动情况。

下面以图 3为例， 说明本发明的一种具体实施例。

1、 IP传输平面 A-R1-B发生异常，导致 IPLinkl-IPLink4发生 IP拥塞。

2、 NODE A节点 M3UA协议模块接收到底层上 4艮的 IPLink l-IPLink4 拥塞报文后， 根据配置的拥塞上报门限判断是否需要上报 SCCP业务模块， 如果发生拥塞的 IPLink比例没有超过设定的拥塞上报门限值，则 M3UA协 议模块不上报 SCCP业务模块 NODEB 节点发生拥塞。 因此 SCCP业务模 块也不会对 NODE B 节点的业务进行流量控制， 这样保证用户业务不受损 失。

3、 NODE A节点将发生拥塞的 IPLinkl-IPLink4在动态路由表中标记 为拥塞状态，到 NODEB节点的业务不再选择 IPLinkl-IPLink4 这些拥塞 IP 链路发送业务消息。而将所有的业务消息都通 过另外一个完全正常的 IP传 输通路 IPLink5-IPLink8 进行消息发送。 即 IPLink5-IPLink8承担 NODE A 到 NODE B 节点的 100%业务量。

4、 当 IP传输网络故障恢复时， NODE A到 IP Router 1 路径异常解除， IPLink l-IPLink4 通过 Router 1 发送业务数据不再产生拥塞。 为防止抖动， 当 IP 传输平面 A-R1-B 异常解除， A-Rl-B IP 传输平面不再拥塞， 即 IPLinkl-IPLink4 IP拥塞解除时， IPLinkl-IPLink4不能直接承担业务流量， 避免发生抖动。

5、 NODE A节点 M3UA协议模块接收到底层上 4艮的 IPLinkl-IPLink4 解除拥塞报文后， M3UA 协议模块启动阻尼定时器， 用于监控 IPLinkl-IPLink4 的链路拥塞恢复情况， 如果在阻尼定时器到时之前再次发 生 IPLinkl-IPLink4的拥塞， 则退回到步骤 3 , 且停止本阻尼定时器。 如果 在阻尼定时器到时， IPLinkl-IPLink4 —直没有再发生拥塞情况， 则说明 A-Rl-B IP传输平面已经完全恢复正常， 可以投入业务负荷。

6、 NODE A 节点 M3UA 协议模块在阻尼定时器启动期间， 在 IPLinkl-IPLink4上定时的发送心跳消息报文， 探测 IPLinkl-IPLink4是否真 正拥塞解除， 以及探测在 IPLinkl-IPLink4 上发送心跳报文是否会导致 IPLinkl-IPLink4上再次发生拥塞。 如果再次发生拥塞则退回到步骤 3。

7、 NODE A节点 M3UA协议模块确定阻尼定时器到时、 且没有再次 发生 IPLinkl-IPLink4拥塞，则说明 A-Rl-B IP传输通路已经完全恢复正常， 可以投入服务承载业务流量。 此时 NODE A节点到 NODE B 节点的业务 流量可以在两个 IP传输平面 A-R1-B 以及 A-R2-B 上均匀分担发送业务流 量， 即 IPLinkl-IPLink8 均匀承担业务流量。

综上所述， 本发明解决了 IP网络信令传输平面故障导致的业务中断的 问题， 尤其是 IP网络信令 M3UA协议在底层单平面 IP传输网络发生异常 时业务中断的问题。

以上内容是结合具体的实施方式对本发明所作 的进一步详细说明， 不 能认定本发明的具体实施只局限于这些说明。 对于本发明所属技术领域的 普通技术人员来说， 在不脱离本发明构思的前提下， 还可以做出若干简单 推演或替换， 都应当视为属于本发明的保护范围。