CN1820466A - 由媒体网关检测媒体网关控制器状态的方法 - Google Patents

Abstract

本发明涉及一种在承载与控制分离的网络中由媒体网关检测媒体网关控制器状态的方法，通过在媒体网关与媒体网关控制器之间通信的接口协议中增加一个协议扩展包，所述方法包括以下步骤：a)由媒体网关向媒体网关控制器发送所述协议扩展包；b)媒体网关控制器接收所述协议扩展包，根据协议扩展包中携带的参数，完成对所述媒体网关的认证；c)根据媒体网关控制器对所述媒体网关的认证结果，所述媒体网关确定媒体网关控制器的链路状态；以及d)定期重复以上步骤。根据本发明，能够使媒体网关实时检测媒体网关控制器的状态，当媒体网关控制器发生故障时，及时向备用媒体网关控制器注册，该特性可以很好地支持应付灾难发生时的网络双归属功能。

Description

由媒体网关裣测

媒体网关控制器状态的方法 技术领域

本发明一般涉及通信技术领域， 更具体地涉及一种在下一代 网络中由媒体网关检测媒体网关控制器状态的方法。 背景技术

在传统交换网络中， 给用户终端提供的功能或业务都直接与 交换机有关。 例如， 在图 1示出的传统交换机的内部组网的示意图 中， 控制信令（以虛线示出）和话音 /数据承载（以实线示出）是 集中在传统交换机 1中的。 传统交换机 1构成了传统交换网络的交 换核心。 从图中可以看出， 对于各个用户终端 2， 传统的 "呼叫 与控制 "功能是和业务结合在一起的， 不同的业务需求的呼叫控 制功能不同。 这种传统交换机不能实现控制与话音 /数据承载的分 离。

随着网络技术的演进， 特别是 IP技术和以 IP网络为代表的宽 带网络的发展， 出现了下一代网络（NGN )的概念。 NGN是一种 综合、 开放的网络构架， 可以提供语音、 数据和多媒体等多种业 务。 NGN可在统一的分組网络上融合通信、 信息、 电子商务和交 易等业务， 满足多样化、 个性化的业务需求， 在继承的基础上实 现与各种业务网络（PSTN/ISDN, PLMN, IN, Internet )之间 的互通， 在全网内快速提供新的语音、 数据、 视频业务等融合业 务。

NGN采用软交换技术， 软交换是一种功能实体， 为 NGN提供 具有实时性的业务呼叫控制和连接控制功能， 是下一代网絡呼叫 与控制的核心。 筒单看， 软交换将传统交换机的功能模块分离为 独立网络部件， 各部件按相应功能进行划分， 采用业务与呼叫控 制分离、 呼叫控制与承载分离技术， 实现开放式网络结构， 使业 务独立于网络。 NGN在网络架构方面主要是将传统交换机中， 信 令控制部分和话音 /数据承载部分进行了分离， 中间使用标准的媒 体网关控制协议， 例如 H.248/Megaco进行交互。

如图 2所示， 图 2示出了 NGN内部组网的示意图。 用户终端 2 (如 IP电话， SoftPhone ) , 通过网络 3 (—般是 IP网络）连接到 不同的地方， 控制信令（以虚线示出）连接到软交换 4 (或称媒体 网关控制器）。 语音 /数据承载（以实线示出）连接到媒体网关 1。 软交换是 NGN的控制核心， 负责处理所管辖的所有呼叫处理， 控 制媒体网关资源。 媒体网关将一种网络中的媒体转换成另一种网 络所要求的媒体格式。 例如， 根据软交换发送来的媒体网关控制 信令， 进行语音 /数据承载的交换。

NGN的基本结构一般分为： 业务层、 控制层、 传输层和接入 层。 其中， 控制层主要完成接继控制、 资源管理等功能， 其核心 是软交换（Softswitch ) , 也称媒体网关控制器（MGC ) 。 媒体 网关控制器对媒体网关（MG )进行承载控制、 资源控制及管理。 媒体网关控制器与媒体网关之间的接口使用例如媒体网关控制协 议（ MGCP )或 H.248/Megaco协议。 MGCP协议是 IETF (互联网 工程任务组）较早定义的媒体网关控制协议。 H.248/Megaco协议 是 IETF, ITU-T制定的媒体网关控制协议， 用于媒体网关控制器 和媒体网关之间的通信。 并且， H.248/Megaco协议配合其它协议 可完成各种 NGN业务。

在 H.248/Megaco协议中的每条消息中包含一个或多个事务处 理， 由 "请求 "和 "响应"构成一个事务（Transaction ) , 每 个事务处理包含一个或多个上下文（context ) , 每个上下文包含 一个或多个命令。 上下文定义了一些终端之间的联系， 上下文是 描述终端之间的拓朴关系和媒体混合 /交换的参数， 可通过例如

Add命令进行创建， 也可通过 Subtract命令、 Move命令进行删除。 在 H.248/Megaco中包含若干条命令， 例如 Add、 Subtract, Move、 Modify, Audit Value, Audit Capability, Notify, Service Change 命令， 各种命令通过其携带的参数实现各种业务。 H.248/Megaco 协议下的命令独立于底层传输协议。

在下一代网络（NGN ) 中， 存在很多基于媒体网关控制协议 H.248/Megaco协议的媒体网关（MG ) , 这些网关分布在企业或 用户家中，具有面广、量大、基于动态 IP的特点。但在目前的 NGN 网络中， 由于 H.248/Megaco协议在固定网络中主要在用户数据报 协议上进行传输（UDP ) ， 该 UDP协议没有传输层的链路检测功 能， 而 H.248/Megaco协议也没有定义能否由媒体网关主动发起消 息来检测到软交换的链路状态， 使得在媒体网关控制器出现故障 重启后， 在用户没有主动呼叫的情况下， 媒体网关无法及时知道 媒体网关控制器的状态， 相关的用户作为被叫将受到影响。 例如， 在这种情况下， 将导致其他人无法给受到影响的用户打电话。 发明内容

本发明的一个目的是为了解决因媒体网关控制器与媒体网关 之间进行通信的协议与底层传输协议无关而使媒体网关无法检测 到媒体网关控制器的链路状态这一现有技术中存在的缺陷。

本发明的另一个目的是提出了在基于 H.248/Megaco协议的媒 体网关中增加了对媒体网关控制器的检测功能。

为了实现上述目的， 根据本发明提出了一种由媒体网关检测 媒体网关控制器状态的方法， 其特征在于， 在媒体网关与媒体网 关控制器之间进行通信的接口协议中增加一个协议扩展包， 所述 方法包括以下步骤： a ) 由媒体网关向媒体网关控制器发送所迷协议扩展包； b )媒体网关控制器接收所述协议扩展包， 根据协议扩展包中 携带的参数， 完成对所述媒体网关的认证；

c )根据媒体网关控制器对所迷媒体网关的认证结果， 所述媒 体网关确定媒体网关控制器的链路状态； 以及

d ) 定期重复以上步骤。

优选地， 媒体网关控制器对媒体网关进行认证的步骤包括： 检查媒体网关所发送的协议扩展包中的 IP地址与配置在所述媒体 网关控制器中的数据是否一致。

优选地， 所迷协议扩展包中包括请求事件和结果事件， 其中 结果事件进一步包括媒体网关控制器对媒体网关合法性检测的结 果。

优选地， 通过 H.248/Megaco协议中的 Notify命令携带所述协 议扩展包中的参数，完成媒体网关对媒体网关控制器状态的检测。

优选地， 所述媒体网关控制器与所述媒体网关通过

H.248/Megaco协议， 或通过 MGCP协议进行通信。

优选地， 所迷方法还包括在媒体网关向媒体网关控制器发送 协议扩展包的同时， 或延迟一段时间间隔后， 启动一定时器。

优选地， 在检测到媒体网关控制器的成功响应后， 复位定时 器。

优选地， 在检测到媒体网关控制器失败的响应后， 发送报警 消息并向备用网关注册。

优选地， 在检测到媒体网关控制器失败响应超过一预定次数 后， 或定时器时间设置超过一预定时间期限后， 发送报警消息并 向备用网关注册。

根据本发明提出的方法， 可以让媒体网关主动检测媒体到网 关控制器的连接通信状态。 当媒体网关控制器发生故障时， 及时 向备用媒体网关控制器注册， 该特性可以很好地支持应付灾难发 生时的网絡 归属功能。 当媒体网关控制器发生灾难后， 通过本 发明的方法， 媒体网关可以立即得知当前媒体网关控制器发生了 故障的信息， 并立即向备用的媒体网关控制器注册， 从而把因此 所造成的影响減少到最低。 附图说明

以下通过参考附图， 对本发明的具体实施方式进行描述， 其 中：

图 1示出了传统交换机内部組网示意图；

图 2示出了 NGN的内部组网示意图；

图 3示出了根据本发明的由媒体网关检测媒体网关控制器状 态的方法的流程图。 具体实施方式

以下结合附图对本发明优选实施方式进行详细描述， 本领域 技术人员知道， 通过对本发明实施例的描迷， 可以对本发明做出 各种改进、 修改或替换， 而均不会脱离本发明的原理。

参照附图 3, 附图 3示出了根据本发明的由媒体网关检测媒体 网关控制器状态的方法的流程图。 本发明的具体实施方式基于 H.248/Megaco协议进行描述， 但本发明并不局限于此。 本发明也 适用于其它的在媒体网关与媒体网关控制器之间使用与 H.248/Megaco协议类似的协议， 例如使用 MGCP协议的网络中。

如前所述， 在 H.248/Megaco协议中， 每条消息中包含一个或 多个事务处理， 每个事务处理包含一个或多个上下文（context ) , 每个上下文包含一个或多个命令。 由 "请求 "和 "响应 "构成 一个事务。 由上下文定义终端之间的联系。 根据本发明， 为实现 媒体网关对媒体网关控制器状态的检测， 本发明的基本思想是： 在媒体网关控制器与媒体网关之间通信的接口协议中， 增加定义 一个新的协议扩展包， 例如在使用 H.248/ egaco协议作为接口协 议的情况下， 新定义一个 H.248/Megaco协议扩展包， 在本文中称 为 H.248协议心跳包 HeartBeat , 通过 H.248/Megaco协议中的 Notify命令携带所迷协议扩展包 HeartBeat中的各个参数， 以及对 所述参数进行认证， 来实现媒体网关对媒体网关控制器状态的检 测。

以下， 通过具体实施例更详细地描述根据本发明的由媒体网 关检测媒体网关控制器状态的方法。 所述实施例是基于 H.248/Megaco协议进行描述的， 为此在 H.248/Megaco协议下的 Notify命令中添加被定义为 H.248/Megaco协议心跳包 HeartBeat 的参数。此处定义的 H.248/Megaco协议心跳包是请求 -响应类型的 协议扩展包， 是心跳请求事件和心跳结果事件的集合， 心跳包中 所定义的内容， 作为 Notify 命令的参数， 通过所述参数， 完成由 媒体网关检测媒体网关控制器状态的功能。

下面举例说明上述过程。

假设媒体网关和媒体网关控制器的配置为：

1. 媒体网关的 IP地址、 端口号： [123.123.123.4]:55555

2.媒体网关控制器的 IP地址、端口号： [125.125.125.111]:55555 基于 H.248/Megaco协议的实现本发明的 H.248/Megaco协议 心跳包 HeartBeat可如下定义：

协议扩展包名称： HeartBeat; 协议扩展包版本： 1;

协议扩展包中包含的事件：

1: 心跳请求事件 （该参数类型是 Event):

心跳请求事件标识： hrtbtreq ( 0x0001 )

参数： 无 心跳结果事件 （该参数类型是 ObservedEvents):

心跳结果事件标识： hrtbtrlt ( 0x0001 )该参数主要是为了 获取媒体网关控制器对媒体网关发出的心跳包的合法性的检测 结果。

类型： enum为枚举类型， 是一种数据结构， 定义了结果 事件出现的各种可能结果。

心跳结果事件的取值： 该取值是媒体网关控制器根据对心 跳包的合法性检测， 给出的检测结果。 之后， 所确定的检测结 果发送给媒体网关。 如下， 媒体网关控制器返回给媒体网关的 检测结果包括：

0x00： Successful (成功）， 表示媒体网关控制器对媒体网关 的认证成功；

0x01： Failed - InvalidMGW (非法 MG), 表示当前媒体网 关是非法媒体网关；

0x02： Failed - OtherReason (失败 -其它原因）， 表示当 前媒体网关因其它原因拒绝心跳请求事件。 基于上迷协议扩展包的认证过程， 即通过检查协议扩展包中 的 IP地址与配置在软交换上的数据是否符合， 所采用的必要步骤 为 （MGC与 MG进行通信的常规示例） ：

步骤 1:

由 MG向 MGC发起心跳包的请求消息： MG发出请求事件的 Notify命令给 MGC, 为此分配事务标识 100和事件请求标识 300， 请 求 MGC进行合法 性检查 并返 回 心 跳 结 果 事 件 ( HeartBeat/hrtbtrit ) 。 发出心跳请求消息同时， 或延迟一时间 间隔后， MG启动一定时器 Tl。该定时器例如可为软件定时器， 直 接由软件通过搡作系统 (如 VxWORKS，等）的接口函数调用即可。 定时器的周期例如可以通过维护台配置。

对步骤 1的操作， 可编程如下：

MEGACO/1 [123.123.123.4]:55555

Transaction=100{

Context- - {

Notify=root{

Events=300{HeartBeat/hrtbtreq}

}

}

}

其中，使用的协议为 " MEGACO ", 该协议的版本号为 " 1 "。 软交换的 IP地址: 123.123.123.4; 端口号 :55555。 事务处理的标识 ID 为 " 100 "。 请求事件的标识 ID 为 " 300 " , 代表事件 " HeartBeat/hrtbtreq "的标识。 Notify命令将标识端点 ID设置 为 " root" , 代表整个网关。 步骤 2:

当 MGC接收到 MG发送的 Notify命令后., 开始进行网关合法 性认证， 即检查心跳包中的 IP地址与配置在软交换上的数据是否 符合。 合法性认证完成后， 由 MGC向 MG返回相应的响应结果， 该响应结果通过使用响应类型的 Notify命令发送回 MG。 在该响应 类型的 Notify命令中， 事件参数为网关合法性认证结果。 其中， 该 响应类型的 Notify命令中的事务标识 ID100与 M0发出的 Notify的 事务标识一致， 事件标识 ID300与请求消息的事件标识也是一致 的。

对步骤 2的操作可编程如下： MEGACO/1 [125.125.125.111〗 : 55555

Reply=100{

Context=― {Notify=root{

ObservedEvents=300 {HeartBeat/hrtbtrlt}

}

}

}

其中， "Reply"代表响应消息， 其事务标识 ID为 " 100", 与请求消息中的事务标识 ID—致； 事件标识 ID为 " 300", 代表 " 心跳结果事件 HeartBeat/hrtbtrlt"的标识， 也与心跳请求消息 中的事件标识 ID—致。 步驟 3:

MG接收到心跳响应后，检查返回的心跳响应结果， 如果是成 功响应， 例如心跳结果事件的取值是 "0x00", 表示网关认证成 功， 媒体网关控制器的状态正常， 在这种情况下， 复位定时器。 如果是失败响应， 例如心跳结果事件的取值是 "0x01", 或心跳 结果事件的取值是 " 0X02", 则应该报警通知后台维护人员， 解决问题。 同时， 通知当前网关向备用网关注册。

例如， 可通过设定定时器的方式， 周期地重复上述步骤， 以 实现 MG对 MGC状态的实时检测。 定时器的时间间隔设置， 可以 人工配置， 优选地， 参考网络业务量以尽可能不增加太大的流量 负荷的方式对定时器进行设定。 在 MGC与 MG通信不正常的情况下：

此时， MG的定时器会超时， 定时器超时后， MG重发 Notify消 息， 同时复位定时器. 当重发了 N次后， （N可以通过维护台配置)， MG 认为 MGC链路状态不正常， 告警并向备用网关注册。 具体步 骤如下： 对步骤 1的操作， 可编程如下：

MEGACO/1 [123.123.123.4]:55555

Transaction=100{

Context- - {

Notify=root{

Events=300{HeartBeat/hrtbtreq}

}

}

}

其中，使用的协议为 " MEGACO ",该协议的版本号为 " 1 "。 软交换的 IP地址: 123.123.123.4; 端口号 :55555。 事务处理的标识 ID 为 " 100 "。 请求事件的标识 ID 为 " 300 "， 代表事件 " HeartBeat/hrtbtreq "的标识。 Notify命令将标识端点 ID设置 为 " root", 代表整个网关。

步骤 2：定时器超时， MG 没有收到 Notify消息的响应。 重发 步骤 1的消息， 同时复位定时器， 重发计数器加 1 。

步骤 3 ： 重复步骤 2， 检查重发计数器， 当重发计数器 >N时， 则告警， 向备用网关注册。 停止重发定时器。 根据本发明的方法， 由媒体网关主动向媒体网关控制器发送 —消息， 例如一个心跳包消息， 因此能够在媒体网关控制器出现 故障后， 及时知道媒体网关控制器的状态， 并及时向备用网关注 册。 该特性可以很好地支持应付灾难发生时的网络双归属功能。 双归属功能是一种网络自愈设计概念， 是为对某个网络节点发生 故障后提供保护而设计的。 所谓 "归属 "是指网络中某一端局归 属于哪一个上级局而言。 " 双归属"是给某个端局指派两个上级 局， 故该局有两个通往其它各局的入口， 其业务需求也被一分为 二。 一般局内的话务被一分为二， 当出现一个局发生故障， 仍可 保证另一局 50 %的话务不受影响。 双归属结构本身虽然没有恢复 能力， 但是同数字交叉连接设备配合使用后， 如果该局至备用的 光纤线路有足够的容量， 则通过备用上级局一般可以恢复 50 %以 上的话务。 由此， 将媒体网关和用户终端同时与两个软交换连接， 例如软交换 1和软交换 2。 当其中一个软交换， 例如软交换 1发生故 障时， 用户终端和媒体网关可以获取该信息， 并向备用软交换， 例如软交换 2, 进行注册， 从而把因此受到的影响减小到最低。 以上， 已经通过结合附图对本发明的具体实施方式进行了描 述。 应该理解， 本领域技术人员在形式和细节上可根据本发明的 原理进行各种修改， 而不脱离本发明随附权利要求书所限定的范 围。

Claims (1)

1. 

   1、 一种在承载与控制分离的网络中由媒体网关检测媒体网关 控制器状态的方法， 其特征在于， 在媒体网关与媒体网关控制器 之间进行通信的接口协议中增加一个协议扩展包， 所述方法包括 以下步骤：

   a ) 由媒体网关向媒体网关控制器发送所述协议扩展包； b )媒体网关控制器接收所述协议扩展包， 根据协议扩展包中 携带的参数， 完成对所述媒体网关的认证；

   c )根据媒体网关控制器对所述媒体网关的认证结果， 所迷媒 体网关确定媒体网关控制器的链路状态； 以及

   d ) 定期重复以上步骤。

   1、 根据权利要求 1的方法， 其特征在于， 媒体网关控制器对 媒体网关进行认证的步骤包括： 检查媒体网关所发送的协议扩展 包中的 IP地址与配置在所迷媒体网关控制器中的数据是否一致。

   3、 根据权利要求 1的方法， 其特征在于， 所述协议扩展包中 包括请求事件和结果事件， 其中结果事件进一步包括媒体网关控 制器对媒体网关合法性检测的结果。

   4、 根据权利要求 1的方法， 其特征在于， 进一步包括： 通过 H.248/Megaco协议中的 Notify命令携带所述协议扩展包中的参 数， 完成媒体网关对媒体网关控制器状态的检测。

   5、 根据权利要求 1的方法， 其特征在于， 所述媒体网关控制 器与所述媒体网关通过 H.248/Megaco协议进行通信。

   6、 根据权利要求 1的方法， 其特征在于， 所述媒体网关控制 器与所述媒体网关通过 MGCP协议进行通信。

   7、 根据权利要求 1的方法， 其特征在于， 还包括在媒体网关 向媒体网关控制器发送协议扩展包的同时， 或延迟一段时间间隔 后， 启动一定时器。

   8、 根据权利要求 1的方法， 其特征在于， 还包括在检测到媒 体网关控制器的成功响应后， 复位定时器。

   9、 根据权利要求 1的方法， 其特征在于， 还包括在检测到媒 体网关控制器失败的响应后， 发送报警消息并向备用网关注册。

   10、 根据权利要求 1或 9的方法， 其特征在于， 在检测到媒体 网关控制器失败响应超过一预定次数后， 或定时器时间设置超过 一预定时间期限后， 发送报警消息并向备用网关注册。