专利名称：一种承载资源预留方法、系统和装置的制作方法
技术领域：
本发明涉及计算机与通信网络技术领域，特别涉及业务与承载分离架构 下的承载资源预留方法、系统和装置。
背景技术：
资源预留协议(Resource Reservation Protocol, RSVP )是一个网络控 制协议，它提供了一种路径资源预留的机制，通过RSVP在IP网络中建立 的承载路径具有能够满足业务数据流需求的带宽和路由器资源。
RSVP的基本工作原理如图1所示，包括如下步骤
步骤101:发送方发送一个路径请求(Path)消息到目的地址，从源地 址到目的地址路径上的每一个支持RSVP的路由器沿着下行路由建立一个 "路径状态表"；
步骤102:为了获得资源预留，接收方发送一个上行的预留请求(Resv) 消息到源地址，表明所要求的服务质量(QoS)类型，还通知为分组预留的 资源，如传输协议和端口号；
步骤103:当所述路径上的每个支持RSVP的路由器沿着上行路径接收 预留请求消息时，采用准入控制过程来验证所收到的预留请求，并且配置所 需的资源。
如果这个预留请求得不到满足，路由器向接收方返回一个预留错误 (ResvErr)消息；而如果这个预留请求可以满足，路由器就发送上行预留 请求消息到下一个路由器。当最后一个路由器接收并接受预留请求消息时， 它再发送一个预留确认(ResvConf)消息给接收方。
通过上述过程，实际上建立了一个从数据发送方到接收方的承载路径，而这条路径上的每一个路由器都为将要到来的数据传输预留了资源。
RSVP通过软状态(Soft State)的方式来管理路由器和主机上的预留状 态，这种软状态通过路径请求和预留请求消息建立，并被上述消息周期性地 刷新。有两种情况都将导致软状态被删除， 一是在给定的时间间隔(一般为 30秒)内，节点(主机或路由器)没有检测到相匹配的刷新消息到达；二 是拆除消息(PathTear或ResvTear)的到达。在节点的软状态的刷新时间过 期或者某个软状态改变的时候，RSVP扫描该节点所要建立的状态，并向它 的后继节点发送路径请求和预留请求刷新消息，用来维持每个节点的软状 态。
图2所示为国际电信耳关盟(International Telecommunications Union, ITU) 的资源和准入控制架构。 一个实时通信会话的建立通常包括两个方面 一是 客户端i殳备(Customer Premises Equipment, CPE ) 101与对端实体通过业务 控制功能(Service Control Function, SCF ) 104等业务层实体之间的业务层 协商；二是CPE 101与对端实体通过传输功能(Transport Function, TF ) 102 等承载层传输实体之间的承载层协商。资源和准入控制功能(RACF) 103 根据SCF 104传递的业务QoS请求，为各种具有下一代网络(NGN)传输 资源控制需求的应用(SIP呼叫、视频流等)提供基于策略的传输资源控制， 将业务信息转换成传输资源要求，并命令TF 102执行策略决策，从而建立 应用功能与底层传输能力之间的关联。当RACF 103中的策略决策功能实体 (Policy Decision Functional Entity, PD-FE )与TF 102中的策略执行功能实 体(Policy Enforcement Functional Entity, PE-FE)之间4妄口采用H.248协i义 时，PD-FE就相当于H.248实体中的Jf某体网关控制器(Media Gateway Controller, MGC) 106， PE-FE就相当于H.248实体中的力某体网关(Media Gateway, MG) 105。 MGC和MG是分组网络中的两个关键构件。MGC负 责呼叫控制功能，MG负责业务承载功能，藉此实现呼叫控制平面和业务承 载平面的分离，从而充分共享网络资源，简化设备升级和业务扩展，大大降 低开发和维护成本。MGC和MG组成的网络架构如图3所示。MGC负责呼叫控制功能， MG负责业务 义载功能，MG之间通过实时传输协议(Real-time Transport Protocol, RTP )交互。网关控制协议是MG和MGC之间通信的主要协议， 目前应用较为广泛的有H.248/MeGaCo和A某体网关控制协议(Media Gateway Control Protocol, MGCP )这两种协议。
以H.248协议为例，MG上的各种资源被抽象表示为终端(Termination )。 终端又分为物理(Physical)终端和临时(Ephemeral)终端，前者代表一些 具有半永久存在性的物理实体，例如TDM通道等，后者代表一些临时申请 用后释放的公共资源，例如RTP流等。另以根(Root)终端代表MG整体。 终端之间的组合被抽象表示为上下文(Context )。上下文可以包含多个终端， 因而以拓朴(T叩ology)来描述终端间的相互关系。对于还未与其它终端发 生关联的终端，由一个称为空(Null)上下文的特殊上下文来包含。
基于协议的这种抽象模型，呼叫的接续实际上就是对终端和上下文的操 作。这种操作通过MGC和MG之间的命令(Command)、请求(Request) 和响应(Reply)来完成。命令类型包括添加(Add)、修改(Modify)、删 减(Subtract )、移动(Move )、审计值(AuditValue )、审计能力 (AuditCapabilities )、通报(Notify)、服务改变(ServiceChange )。命令 参数，也称为描述符(Descriptor),被分类为属性(Property)、信号(Signal)、 事件(Event)、统计(Statistic)。具有业务相关性的参数逻辑上聚合成为 包(Package)。
上述资源和准入控制架构支持两种资源控制模式推(Push)模式和拉 (Pull)模式。推模式的实现步骤如图4中的左图所示，包括
步骤401a: SCF向RACF发出请求，进行QoS资源的授权和控制策略 制定；
步骤402a: RACF将策略决策推送给TF来执行。 拉模式的实现步骤如图3中的右图所示，包括 步骤401b: SCF向RACF发出QoS资源授权请求；
步骤402b: TF接到承载层的QoS信令消息； 步骤403b: TF向RACF发出QoS资源预留请求； 步骤404b: RACF将策略决策指示给TF来执行。
这两种模式之间最大的区别在于绑定机制的选取，即业务层会话与承载 连接之间的关联。
Pull模式的应用又可以分为两种情况 一种是创建上下文的模式 (Context-created MG pull mode ),即MGC在收到业务层的协商信令后， 通过与MG的交互，为会话创建收发媒体和信令所需的上下文和终端等承载 资源(包括为终端分配IP地址和端口等)，并将所分配的相关承载信息发 送给CPE;另一种是没有上下文的模式(Context-less MG pull mode),即 MGC在收到业务层的协商信令后，并不与MG交互来创建会话所需的承载 资源，而是等收到承载层的资源请求后再创建。
在创建上下文的Pull模式下，MGC会将MG中为会话创建的承载资源 信息，包括终端的IP地址和端口等，通过业务层的信令消息(如SIP消息) 发送给CPE。接下来，CPE通过RSVP等资源预留协议，向所述MG上的 终端发送RSVP消息(如RSVP Path消息)，来为会话创建有资源保障的承 载路径。但在没有上下文的Pull模式下，由于在CPE向MG发送承载层的 资源请求之前，MGC和MG并没有为CPE所发起的资源会话创建相关的上 下文和终端等承载资源，无法将相应的承载资源信息发送给CPE,导致MG 可能收不到CPE发出的根据承载资源信息构建的承载消息，从而影响了承 载会话的建立。
其它一些会话建立的应用场景中，CPE可能会首先发起承载层的协商， 不发起或稍后再发起业务层协商。这时，由于会话请求的无法预料性和承载 资源可用性等，MG和MGC难以获知会话所需的资源情况，因此也无法在 收到承载资源请求之前就为即将到来的会话创建和预留必要的资源，这同样 会导致MG不能正确地接收CPE发出的资源请求消息，从而影响了承载会 话的建立。
综上所述，在当前MG和MGC参与的承载资源预留过程中，还存在着 一些环节上的缺陷，导致流程的不完善和会话的无法建立。
发明内容
有鉴于此，本发明实施例一方面提出承载资源控制方法，另一方面还提 出承载资源控制系统以及MG，能够有效地改善业务与承载分离架构下的承 载资源控制。
本发明实施例提出的 一种承载资源预留方法包括如下步骤 在媒体网关MG的根终端上分配用以接收承载请求消息的地址资源； MG接收发往所述地址资源的承载资源请求消息，向媒体网关控制器
MGC上纟艮相应的资源请求事件。
本发明实施例提出的另 一 种承载资源预留方法包括如下步骤 MG接收来自MGC的创建临时终端的指示信息，创建一个用于接收承
载请求消息的临时终端，并为所述临时终端分配地址；
MG在所述临时终端上接收承载层的资源请求消息，并向MGC上4艮相
关资源请求事件；
MGC根据所收到的资源请求事件进行资源策略决策，若请求被授权， 则指示MG为资源会话分配收发数据的承载资源，创建用于收发会话数据的 临时终端。
本发明实施例提出的承载资源预留系统包括MG和MGC;
所述MG用于在自身根终端上分配用以接收承载请求消息的地址资源， 接收发往所述地址资源信息的承载资源请求消息，并根据所收到的检测资源 请求事件的指示，向所述MGC上报相应的资源请求事件；
所述MGC用于向所述MG下发检测资源请求事件的指示。
本发明实施例4是出的MG包括
地址资源管理模块，用于分配用以接收承载请求消息的地址资源，并将 所分配的地址资源通知上报模块；还用于根据所收到的承载资源分配指示分
配承载资源；
接收模块，用于接收发往所述地址资源的承载请求消息，并将所接收的 承载请求消息发送至上报模块；还用于接收承载资源分配指示，并将所收到 的承载资源分配指示发送至地址资源管理模块；
上报模块，用于根据所收到的承载请求消息生成资源请求事件，并将所
生成的资源请求事件对外上报给MGC。
从以上技术方案可以看出，通过在MG上分配和预留地址资源信息，使 MG和MGC在还没有为即将到来的会话创建必要资源的情况下，可以正确 接收承载消息，以便及时决策和响应，从而有效的支持和完善了 NGN中的 传输资源控制和边界网关控制。本发明方案可以应用于业务与承载分离架构 下的承载资源控制。
图1为现有技术中的资源预留协议的工作原理示意图2为现有技术中国际电信联盟的资源和准入控制架构图3为现有技术中媒体网关控制器和媒体网关组成的网络架构图4为现有技术中国际电信联盟的资源和准入控制架构的push模式和
pull模式的资源控制示意图5为本发明实施例一的MGC和MG为会话建立承载^各径的流程图6为图5所示的流程中，在MG上建立临时终端的示意图7为本发明实施例二的在无上下文的Pull模式下，CPE发起的QoS
资源控制过程的示意图8为本发明实施例的MG的内部结构框图。
图9为本发明实施例三在无上下文的Pull模式下，通过扩展事件参数实 现QoS资源控制过程的流程示意图。
具体实施例方式
在CPE或其它网络实体向MG发起承载层的资源请求时，MG和MGC
终端等，这个时候可以通过采用某些技术手段在MG上预留或分配相关的地 址和端口信息，作为MG接收承载消息的地址资源信息，也就是CPE发出 资源请求的目的信息，从而建立起CPE和MG之间的承载路径。实现方法 包括如下几种
一、通过扩展一个属性(Property)参数来表示MG上用以接收岸、载消 息的地址资源信息。
以下为了方便描述，将本实施例扩展的这个属性命名为"承载连接地址 (Bearer Connection Address, bca)" 。 i亥属性参凄t可以归属于一个J见有或 新开发的包。
该参数定义在MG上的ROOT终端，作为网关的属性参数。参数取值 可以包括IP地址、端口 ，以及对应的网络域信息。完成bca属性参lt的配 置后，MG上报MGC完成bca属性参数配置，MGC再将bca属性中携带的 信息(其中包括地址资源信息)通知CPE或其它网络实体。
CPE或其它网络实体通过以bca所包含地址资源信息中的地址(或地址 和端口 )为目的来构建资源请求消息，向MG发起承载层的资源请求。当 MG接收到承载层中发往该目的地址的资源请求消息后，可以由MG的 ROOT终端通过H.248的通报(Notify)消息向MGC报告所检测到的资源 请求事件，请求MGC制定相关策略决策。
参数bca的具体形式可以为一个字符串(String)的列表，列表中的每 个字符串实例(Instance)或元素(Element)包含的参数包括域指示和对 应的地址资源信息，例如可以采用"域指示地址端口，，的一各式。其中的 "域指示，，域可以包括一个或多个域信息；"地址，，域可以是IPv4格式的 地址，也可以是IPv6格式的地址；"端口 ，，域包含对应端口信息。另夕卜，
上述参数中的某些部分如果并不被关心，可以代之以"任选($)"通配符
来表示。所述"域信息"可以是IP域，VPN网络，MPLS网络，ATM网络 或者是其它网络域中的一种或任意组合，其中IP域又可以分为IPv4的私有 网络、公有网络和IPv6的网络。这里所述的"IP域，，是指MG所连接的不 同IP网络。通常一个MG会同时与多个IP网络连接，因此该方法在实际应 用中，MG会为每一个IP网络分配一个IP地址和端口 ，用以接收各个IP网 络的承载请求消息。
应用举例如下MG为IP域"mynet.net"预留地址"202.113.0.119"和 端口 "49232"来接收承载消息，则bca属性参数可以表示为 xxx/bca="mynet.net:202.113.0.119:49232",其中，"xxx，，表示bca所在的包 名。
bca参数的实现，可以有以下三种方法
1. MGC指示MG分配相关地址，通过bca属性参数携带具体取值，MG 按照该参数的指示分配特定地址。
2. MGC指示MG分配相关地址，但并不给出具体取值，由MG来自4亍 分配。
3. 在MG上配置bca参数的取值，无须MGC的指示。当MGC需要获 取MG上该参数的具体取值时，可以通过审计的方法获知。
为明确bca属性取值的选择权，可以定义一个属性(Property)，例如 命名为i青求7fc载连4妄i也址(Request Bearer Connection Address, rbca)属'〖生， 与上述扩展的bca属性参数可以归属于同一个包中。该属性的取值包括显式 (Explicit)和隐式(Implicit)，分别表示MGC指示MG预留bca所示地址 资源信息、由MG自行分配。
若MGC将rbca属性赋值为"显式"下发给MG的根(Root)终端，同 时需要下发bca属性参数，则表示要求MG按照MGC的指示预留bca属性 中所携带的地址和端口等作为接收承载消息的地址。若MGC将该属性赋值 为"隐式"下发给MG的根(Root)终端，则表示要求MG根据缺省值自行
决定所使用的地址和端口等。
当MGC需要指示MG为接收承载上的资源请求消息分配和预留相关地 址资源时，如果MGC希望明确指示预留地址资源信息，则在向MG发送的 命令请求中设置上述bca属性参数，这时可以不同时下发rbca属性，即表示 MGC要求MG预留bca属性所包含地址资源信息；如果MGC仅希望MG 预留相关地址，而不明确指示地址资源信息，则下发rbca属性给MG，其中 rbca属性赋值为"隐式"，这时可以不同时下发bca属性，表示由MG根据 缺省值自行决定所使用的地址资源信息，MG在命令响应中将分配结果携带 给MGC。两种情况下，若预留成功，则为正常响应；若预留失败，则为错 误响应，包括相应的错误码和/或4晉误描述文本，例如"510 Insufficient Resource"表示资源不足。
对于每一个MG和MGC所服务的IP域，MG可以在整个运行过程中都 使用特定的IP地址和端口号来接收通过以bca所包含地址资源信息中的地 址(或地址和端口 )为目的构建的资源请求消息，也可以中间改变地址资源 信息，只是MG需要及时将相关地址资源信息通报给MGC。 MGC可以通过 指示新的bca参数给MG，来更改对应的参数取值信息。
同时，MGC也可以通过针对MG的根(Root)终端审计所述属性，获 得MG上预留用以接收承载消息的地址资源信息。
二、 MGC通过修改MG上ROOT终端的流描述参数，在ROOT终端上 预留地址和端口信息用以接收承载消息。
将MG的ROOT终端上所接收的承载消息流^L为H.248中的一个流， 通过修改(Modify)命令，MGC可以使用本端描述符(Local Descriptor) 和远端描述符(Remote Descriptor)为数据流预留相关的承载资源，所述承 载资源至少包括地址和/或端口信息。在本端描述符中使用会话描述协议 (Session Description Protocol, SDP )信息，指示MG分闺己/预留接收地址和/ 或端口信息以便进行流的接收。MG在分配好相关信息后，通过响应消息将 所分配的地址资源信息等携带给MGC。同时，MGC可以设置该数据流的模式(Mode)属性为"RecvOnly"(仅接收)或"SendRecv"(收发)，为 即将到来的承载消息做好准备。
三、在MG上创建一个上下文，在上下文中加入一个临时终端，MG为 其分配IP地址和/或端口号，用以专门接收在会话承载资源创建之前承载路 径上的请求消息。
该上下文和终端的创建可以是在MG向MGC成功注册之后执行，也可 以是在MGC收到相关的业务层会话信息后执行，但需要是在CPE或其它网 络实体发起请求消息之前完成。
MGC通过添加(Add)请求消息，指示MG创建一个临时终端。MG 仅需要为该终端分配用于接收承载层资源请求消息的资源，包括IP地址和/ 或端口号等，并在Add应答消息中携带给MGC。 MGC接收到MG为所创 建终端分配的地址资源信息后，可以通过业务层的信令消息(如Diameter 或SIP消息)等将相关信息发送给CPE或其它网络实体，用于向MG发起 承载路径相关的资源请求。
与为资源会话创建的上下文和终端不同，这里所创建的临时终端并不需 要用来接收媒体数据，它只是资源会话建立过程中的一个过渡和桥梁。也就 是说， 一旦MGC和MG接受了承载层上的资源请求后，会按照资源会话的 需求和一定的策略规则为会话创建所需的上下文和终端资源，而不再使用这 里所述的临时终端。
当该临时终端接收到承载上发来的资源请求消息后，通过H.248的通报 (Notify)消息向MGC报告检测到的资源请求事件，请求MGC制定相关策 略决策。
所述临时终端的寿命可长可短可以是与特定会话无关的，即存在于创 建之后MG正常运行的整个过程中，该临时终端用以接收任何会话承载资源 分配或创建之前的承载请求消息；也可以是为某个特定会话或某段时期服 务， 一旦MGC和MG接收到某个承载请求消息后，MGC可以指示MG删 除该临时终端，之后再在需要的时候重新创建。四、通过扩展相应的事件参数(parameter)来表示MG上用以4矣收承载 消息的地址资源信息，其中可以包括域指示、IP地址或端口等信息的任意组 合。
以下为了方便描述，将本实施例扩展的这个参数命名为"承载请求地址 (Bearer Request Address ， bra)'，。该参数可以归属于现有或新的承载请求 事件中，例如包含在H.248.55的QoS资源预留的资源决策请求(Resource Decision Request for QoS Resource Reservation, rdrr)事件中。
参数bra的具体形式可以为一个字符串(String)的列表，列表中的每 个字符串实例(Instance)或元素(Element)包含的参数包括域指示和对 应的地址资源信息，例如可以采用"域指示地址端口"的才各式。其中， 所述"域指示，，可以包括一个或多个域信息；所述"地址"可以是IPv4格 式的地址，也可以是IPv6格式的地址；所述"端口"包含对应端口信息。 另外，上述参数中的某些部分如果并不被关心，可以代之以"任选($)" 通配符来表示。同前面所述，这里所述"域信息，，可以是IP域，VPN网络， MPLS网络，ATM网络或者是其它网络域中的一种或任意组合，其中IP域 又可以分为IPv4的私有网络、公有网络和IPv6的网络。通常一个MG会同 时与多个网络域连接，因此该方法在实际应用中，MG会为每一个网络域或 某几个网络域分配一个IP地址和端口 ，用以接收所述网络域的承载请求消 台
应用举例如下MG为IP域"mynet.net"预留地址"202.113.0.119"和 端口 " 49232 "来接收承载请求消息，则bra参数可以表示为xxx /bca="mynet.net:202.113.0.119:49232",其中，"xxx"表示bra所在的事件 名。
当然，上述参数信息也可以拆分为几个参数，例如分别为域指示、IP 地址和端口定义单独的事件参数定义一个参数"承载请求网络域(Bearer Request Realm Value, brrv)",表示MG上4妄收岸义载消息的i或信息；定义 一个参数"承载请求地址值(Bearer Request Address Value, brav)，，，表示MG上用以接收承载消息的地址信息；定义一个参数"承载请求端口值 (Bearer Request Port Value, brpv )"，表示MG上用以接收承载消息的端 口信息。以上参数的具体形式可以为一个字符串(String)的列表，列表中 的每个字符串实例(Instance)或元素(Element)包含的参数为对应的地址 资源信息；当参数中包含多个地址资源信息时，所述三个参数所包含内容需 要前后对应，例如可以是按照顺序的方式对齐，其中brrv取值顺序为域1 、 域2、域3,则brav和brpv的取值也对应为为域1 、域2、域3分配的地址
"f吕息。
当MGC向MG下发资源请求事件(例如，plm/rdrr事件)时，同时包 含如上所述事件参数，要求MG为即将到来的承载请求消息分配相应的地址 资源，如IP地址和端口等。MG在响应消息中将所分配的地址资源信息上 报给MGC。
另外，MGC也可以在下发事件检测指示时，指定地址资源参数的取值， 则表示要求MG按照MGC的指示预留相应的地址资源。
上述扩展的这些参数并不一定必须全部出现在相关事件或属性中，具体 包含哪些参数可以视实际的需要来定，当然也可能包含更多的参数信息。
通过上述方法中的任何一种，MGC和MG为承载层的请求消息分配和 预留了地址和/或端口信息。在实际应用中，也可以采用除以上所述之外的 方式来为承载层的请求消息分配和预留地址和/或端口消息，本发明并未对 分配和预留地址和/或端口消息的具体方式作出限定。当MGC收到CPE或 其它网络实体发起的业务层协商信令时，如果还没有或无法为该会话创建所 需承载资源，则可以将上述预留的地址资源信息响应给发起方，用以发起承 载层的请求消息。CPE或其它网络实体根据所接收到的MG地址资源信息， 构建和发起承载层的资源请求消息。
当MG接收到承载上的请求消息时，如果同时有多个终端共用该地址而 只是端口信息不同时，其中的某个或某些终端可能是真正为会话创建用以收 发媒体数据的，这时MG需要判断由哪个终端(临时终端或ROOT终端)
来处理该请求消息。MG进行上述判断可采用如下方式
根据请求消息中的目的地址资源信息和MG上各终端所处理的地址范
围或域信息的匹配结果来辨别，如果有完全匹配的临时终端，则由该临时终
端来处理并向MGC上才艮；如果没有完全匹配的临时终端，则由上述方法中 所预留地址代表的ROOT终端或专门用以接收承载消息的临时终端来处理 并向MGC上寺艮；
或者，提取请求消息中的目的地址和端口号信息，根据端口号来匹配终 端信息，如果有完全匹配的临时终端，则由该临时终端来处理并向MGC上 报；如果没有完全匹配的临时终端，则由上述方法中所预留地址代表的 ROOT终端或专门用以接收承载消息的临时终端来处理。
上述承载层上的请求消息，可以是资源预留协议(RSVP)的请求消息， 也可以是其它承载信令协议消息，如下一代信令(Next Steps in Signaling， NSIS)消息等。
通过上述方法，实际上在会话建立过程中增加了一个重定向的步骤。以 资源控制的Pull模式为例。第一步，MGC收到业务层的请求消息，在响应 消息中携带MG上用以专门接收资源请求消息的地址和端口等信息；第二 步，MG在所述地址和端口上接收到承载层的资源请求消息，并向MGC上 报相关资源请求事件；第三步，MGC对资源请求进行授权，指示MG为该 会话创建必要的承载资源，包括上下文和终端等，并将相关资源信息携带给 会话发起方(如CPE等)；第四步，CPE重新向MG上创建用以数据收发 的终端发起承载建立请求，如RSVP Path请求。
以下通过具体实施例，对本发明方案的具体实现流程进行阐述。 实施例一MGC和MG通过上述的办法，在MG上分配和预留IP地址 和端口信息，从而方便接收承载路径上即将到来的资源请求消息，为会话创 建有保障资源的承载路径的应用流程。
本实施例中MGC和MG为会话建立承载^各径的相关流程如图5所示， 包括如下步骤
步骤501: MG通过服务改变(ServiceChange )请求消息向MGC发起 注册请求，表明自身资源的可用性。
步骤502: MGC向MG发送携带注册响应的服务改变响应消息。 步骤503: MGC通过添加(Add)请求消息指示MG创建一 个新上下文， 并在上下文中加入一个临时终端，分配该临时终端的地址和端口信息，用以 接收承载层上即将到来的资源请求消息。该上下文和终端创建的目的，是便 于在MGC和MG为某个(些)会话的媒体数据流创建和分配相关资源之前， MG可以接收到承载层上的资源请求消息。因此，所创建的临时终端是MGC 和MG专门用于接收会话资源未创建时承载层上的请求消息，而并不需要用 在实时会话中接收和发送媒体，MGC和MG也就无须为其分配过多的资源， 仅需为其分配必要的地址和端口信息，保证可以接收承载层的请求消息即 可。
步骤504: MG为所创建的临时终端分配资源，并向MGC发送Add响 应消息，其中包括该临时终端的IP地址和端口号等。如图6中所示，MG 才艮据该请求创建临时终端ipO。 MGC接收到MG所创建终端的地址资源信息 后，可以通过业务层的信令消息(如Diameter或SIP消息)等将相关信息发 送给CPE或其它网络实体，用于发起承载路径相关的资源请求。
步骤503和步骤504为前述的第三种方式，即通过创建临时终端的办法 来预留用以接收承载资源请求的地址资源；实际上也可采用前述的前两种方 式，即扩展MG属性参数或在ROOT终端上修改流描述参数的方法来预留 用以接收承载资源请求的地址资源，具体过程可参照前面的描述，故此处不 在赘述。因此图5中所示步骤503和步骤504为可选步骤，用虚线表示。
步骤505: MGC向MG发送修改(Modify)请求消息，该修改请求消 息中携带承载资源请求事件的检测指示，来指示MG检测承载层上的资源请 求事件，例如可以是H.248.55中定义的QoS资源决策请求事件(plm/rdrr), 也可以是承载资源预留相关的路径请求事件等。如果前面是采用第三种方式 预留的地址资源，则MGC还可以指示MG修改所创建的临时终端(如图6
中的ipO)的特性参数；如果前面是采用前两种方式预留地址资源，则MGC 还可以+务改MG上ROOT终端的特性参凄t。
步骤506: MG收到所述修改请求消息中的检测指示后，根据MGC指 示进4于相应处理，并向MGC返回〗务改响应消息。
通过以上步骤，MG上预留了地址(和端口 )用以接收承载上的资源请 求消息，为会话建立做了准备。以下步骤则描述如何通过建立相关的资源会 话。以CPE发起的会话为例，为建立会话所需要的具有资源保障的承载路 径，CPE向对端实体(如本例中的MG )发起资源路径请求消息，如RSVP Path 消息。其中，RSVP Path消息的目的地址和端口号信息为上述MG中所分配 和预留的地址资源信息。
步骤507: MG接收到CPE发出的RSVP Path消息，通过通报(Notify) 请求消息向MGC报告所检测的资源请求事件，用检测事件(ObservedEvents ) 参数的形式携带从RSVP Path消息中提取的必要信息。如果之前创建了终端 ipO,则由ip0上报检测事件；如果没有创建特定终端，则由ROOT终端上 报检测事件。
步骤508: MGC向MG返回Notify响应消息。
步骤509: MGC收到MG的资源请求事件后，根据相关规则和资源状 况信息等对会话请求进行授权。如果^^权通过，通过Add请求消息，MGC 指示MG为资源请求会话创建和分配资源，创建一个新的上下文，并在其中 添加会话所需的临时终端，如图6中所示的IP终端ipl和ip2。
步骤510: MG为所增加的临时终端分配资源，并向MGC发送Add响 应消息，其中包括所创建临时终端的IP地址、采用的语音压缩算法和端口 号等。
与前面步骤503和504创建终端的目的不同，步骤509和510中创建的 上下文和终端资源是通常意义上用于会话中接收和发送媒体数据及相关信 令消息的。MGC接收到MG上为终端(如ipl)分配的地址等相关信息后， 可以通过业务层的信令协商消息发送给CPE或其它网络实体，用于实时会话的建立。
CPE才艮据业务层消息(如SIP Update消息)得到会话的目的地址资源 信息，该目的地址资源信息是会话真实的目的地址资源信息。CPE将该目的 地址资源信息与前面所得到的地址资源信息进行对比，如果两者不同，则以 最新得到的地址资源信息为准，重新发起承载层的资源路径请求消息(RSVP Path消息)。由于承载上的RSVP会话是以目的地址、协议和端口信息为标 识的，所以一旦其中的某个元素(如目的地址)发生了改变，则就是一个新 的RSVP会话，而承载路径上预留的资源状态信息都是与会话绑定的。鉴于 RSVP协议的软状态特性，之前CPE和MG之间的路径上为前一 RSVP会话 所预留的路径状态和资源预留状态会因为没有进一步的更新消息而被自动 删除，从而避免了资源的浪费。当然，CPE和/或MG也可以在新的预留完 成后，主动发起资源拆除消息(RSVP PathTear或ResvTear消息)，来显式 地删除承载上相关的路径和资源预留状态。
以图6为例，CPE会向ipl发起一个新的资源请求消息，如RSVP Path 消息，来为会话数据的传输建立起一条有资源保障的承载路径。
为了说明方便起见，本实施例仅列出了与本发明关系紧密的相关消息步 骤，而省略了实时会话建立过程中可能出现的其它消息，例如会话终端的特 性修改步骤、MG发起的资源预留过程(RSVP Resv)等等。图5中纵向的 流程线中的斜双线则表示该处可能省略了其它与本发明关系不大的步骤。
实施例二在无上下文的Pull模式下，CPE发起的QoS资源控制过程。
本实施例是将本发明方法应用于会话流程中。会话的建立包含业务层的 协商和承载层的协商，在客户端设备发起承载资源请求之前，MGC和MG 使用本发明所述的方法在MG上预留地址和端口用以接收在会话承载资源 分配或创建之前承载路径上的资源请求消息。
图7为资源和准入控制架构下本实施例的处理流程。RACF和TF之间 的接口使用H.248协议，因此RACF也就相当于H.248中的MGC, TF相当 于MG,以下统一用资源和准入控制架构中的名称来表述。该处理流程具体
包括如下步骤
步骤700:在会话发起之前，TF向RACF注册。在RACF注册成功之 后，可能进行RACF指示TF创建用以接收承载资源请求的临时终端的过程， 该过程要保证发生在本例的步骤703之前。
步骤701: CPE通过向SCF发送一个业务请求(如SIP Invite),来发 起一个应用相关的业务。在该业务请求中，可以包含或不包含明确的QoS 业务需求。
步骤702: SCF从请求业务中提取出的相关QoS业务需求，向RACF 发送授权请求，其中携带QoS需求信息。
步骤703: RACF基于网络策略规则对业务请求进行授权。如果请求被 授权，则由于TF上尚未建立该资源会话的承载资源，所以RACF将TF上 所预留的用以专门接收承载层资源请求消息的地址和端口信息答复给SCF。 地址资源信息的分配和预留，可以通过本发明所述的办法，即通过扩展的 MG属性参数、修改ROOT的流描述参数或创建专门临时终端的办法。
步骤704: SCF通过业务层信令消息将所述用以专门接收承载层资源请 求消息的地址和端口信息发送给CPE。
步骤705: CPE通过路径相关的QoS信令，如RSVP Path消息，向TF 的所述用以专门接收承载层资源请求消息的地址和端口发起QoS资源预留 请求。该QoS请求中包含应用业务所需要的QoS需求参数。
步骤706: TF收到承载层的QoS请求后，根据请求消息的目的地址和 端口信息进行对比和匹配，由选定终端通过通报(Notify )请求消息向RACF 报告所检测的资源请求事件，用检测事件(ObservedEvents )参数的形式携 带从Path消息中提取的必要信息。
步骤707: RACF向TF返回Notify响应消息。
步骤708至步骤709: RACF根据用户规格信息、业务信息、网络策略 规则和资源状况等制定资源预留和准入控制决策。如果请求被接纳，则 RACF将资源决策信息下发给TF,例如指示TF为会话分配相关承载资源(上
下文和终端)等。TF将资源分配结果在响应消息中携带给RACF。
进一步，RACF会通过业务层信令将会话的资源协商信息发送给CPE。 CPE根据TF为会话分配的上下文和终端信息，重新向会话真正的目的地址 发起承载层的资源请求(RSVPPath),建立有资源保障的承载路径。而对 于之前所建立的CPE到MG上预留地址之间的临时岸义载iE各径，CPE或MG 可以发起明确的拆除消息来删除。
实施例三在无上下文的Pull模式下，利用本说明书中的方案四实现的 QoS资源控制过程。
参考图9，图9为本发明实施例三在无上下文的Pull模式下，通过扩展 事件参数实现QoS资源的控制过程的流程示意图。本实施例是将本发明方 法应用于会话流程中。会话的建立包含业务层的协商和承载层的协商，在客 户端设备发起承载资源请求之前，MGC和MG l吏用本发明所述的方法在 MG上预留地址和端口用以接收在会话承载资源分配或创建之前承载路径 上的资源请求消息。
步骤901: MGC向MG下发事件检测请求，如发送修改(Modify.request) 请求消息，该修改请求消息中携带承载资源请求事件的检测指示，例如是 H.248.55中定义的QoS资源决策请求事件(plm/rdrr)。事件的指示中携带 相关的参数信息，例如"承载请求地址值(Bearer Request Address Value, brav)"、"承载请求端口值(Bearer Request Port Value, brpv)"。其中， brav和brpv参数取值为'$，，表示MGC请求MG来为该参数分配资源。
例如，其消息格式为
MEGACO/3 [123.123.123.4]:55555
Transaction = 9999 [ Context = - {
Modify = ROOT {
Events = 2222 {plm/rdrr{brav=$， brpv=$}}步骤902: MG4艮据MGC指示进行相应处理，包括地址资源的分配， 并在修改响应消息中将所分配的地址信息携带给MGC。 例如，其消息格式为 MEGACO/3 [124.124.124.222]:55555 Reply = 9999 { Context = - {
Modify = ROOT {
Events = 2222 {plm/rdrr{brav=202.113.0.119， brpv=49232}}
步骤903: MGC收到MG的响应消息后，将MG上为承载请求消息所 分配的地址信息通知给客户端设备，例如CPE。
步骤904: MG接收到CPE发出的承载请求消息，通过通报(Notify) 请求消息向MGC报告所检测的资源请求事件，用检测事件(ObservedEvents ) 参数的形式携带从承载请求消息中提取的必要信息。 步骤905: MGC向MG返回Notify响应消息。 进一步，MGC根据相关策略规则制定资源预留和准入控制决策。 从以上流程可以看出，本发明实施例的承载资源控制系统由MG和 MGC组成，其中，所述MG用于在自身根终端上分配用以接收承载请求消 息的地址资源，接收发往所述地址资源信息的承载资源请求消息，并根据所 收到的检测资源请求事件的指示，向所述MGC上报相应的资源请求事件；
所述MGC用于向所述MG下发检测资源请求事件的指示。所述MGC 还用于对所收到的资源请求事件进行授权，指示MG为会话创建包括用以收 发会话数据的终端的承载资源，并将相关的资源信息发送给所述承载资源请 求的发送方。
MG分配用以接收承载请求消息的地址资源信息，可以是根据MGC下
发分配地址资源信息的指示，或者根据自身的属性参数配置，在自身的根终
端上分配该地址资源信息；也可以分配一个专门用于接收承载请求消息的临 时终端。
在分配了用于进行会话的承载资源后，MG可以根据来自外部的资源删 除消息，来删除所述地址资源信息；或者直接删除所述地址资源信息。
本发明实施例的MG的内部结构框图如图8所示，包括如下模块
地址资源信息管理模块801,用于分配用以接收承载请求消息的地址资 源，并将所分配的地址资源通知接收模块802;还用于根据所收到的承载资 源分配指示分配承载资源；
接收模块802,用于接收发往所述地址资源的承载请求消息，并将所接 收的承载请求消息发送至上报模块803;还用于接收承载资源分配指示，并 将所收到的承载资源分配指示发送至地址资源信息管理模块801;
上报模块803，用于根据所收到的承载请求消息生成资源请求事件，并 将所生成的资源请求事件对外上报给MGC;
所述地址资源信息管理模块801包括分配单元和删除单元，其中，分配 单元用于分配用以接收承载请求消息的地址资源以及分配会话承载资源；删 除单元用于根据所述接收模块所收到的删除指示，或者在已成功分配承载资 源后，删除已分配的用以接收承载请求消息的地址资源。
本发明实施例的技术方案通过MGC和MG分配和预留地址和/或端口消 息，使媒体网关和媒体网关控制器在还没有为即将到来的会话创建必要资源 的情况下，可以正确接收承载消息，以便及时决策和响应，从而有效的支持 和完善了 NGN中的传输资源控制和边界网关控制。本发明方案可以应用于 业务与承载分离架构下的承载资源控制。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本 发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本 发明的保护范围之内。
权利要求
1、一种承载资源预留方法，其特征在于，包括如下步骤在媒体网关MG的根终端上分配用以接收承载请求消息的地址资源；MG接收发往所述地址资源的承载资源请求消息，向媒体网关控制器MGC上报相应的资源请求事件。
2、 根据权利要求1所述的方法，其特征在于，所述在MG的根终端上 分配用以接收承载请求消息的地址资源包括MG接收来自MGC的包含地址资源信息的指示，将所述地址资源分配 为根终端上用以接收承载请求消息的地址资源；或者，MG根据来自MGC的指示，按照预先设置的缺省值确定并分配 根终端上用以接收承载请求消息的地址资源；或者，在MG的根终端配置用以接收承载请求消息的地址资源。
3、 根据权利要求2所述的方法，其特征在于，所述地址资源信息携带 在属性参数或事件参数中。
4、 根据权利要求3所述的方法，其特征在于，所述地址资源信息包括 IP地址、端口、域指示或上述信息的任意组合。
5、 根据权利要求4所述的方法，其特征在于，所述地址资源信息通过 一个参数的方式携带，或通过多个参数的方式携带。
6、 根据权利要求1所述的方法，其特征在于，所述在MG的根终端上 分配用以接收承载请求消息的地址资源包括MG接收来自MGC对其根终端上流描述符参数的修改指示，在所述根 终端上分配用以接收^c载请求信息的地址资源。
7、 根据权利要求1所述的方法，其特征在于，所述MG接收发往所述 地址资源的承载资源请求;肖息包括MG接收承载资源请求消息，将所述承载资源请求消息中的目的地址信 息与MG中的已有的临时终端的地址资源信息进行匹配，若没有匹配的临时终端，则该承载资源请求消息为发往所述分配的用以接收承载请求消息的地 址资源的承载资源请求消息。
8、 根据权利要求1至7任一项所述的方法，其特征在于，所述MG向 MGC上报相应的资源请求事件之后，进一步包括MGC对资源请求事件进行授权，指示MG为资源会话创建包含用以收 发会话数据的终端的承载资源，并将相关的资源信息发送给所述承载资源请 求的发送方；所述发送方向MG上所述用以收发会话数据的终端发起承载建立请求。
9、 根据权利要求8所述的方法，其特征在于，该方法进一步包括MG 删除所述用以接收承载请求消息的地址资源。
10、 一种承载资源预留方法，其特征在于，包括如下步骤 MG接收来自MGC的创建临时终端的指示信息，创建一个用于接收承载请求消息的临时终端，并为所述临时终端分配地址；MG在所述临时终端上接收承载层的资源请求消息，并向MGC上报相 关资源请求事件；MGC根据所收到的资源请求事件进行资源策略决策，若请求被授权， 则指示MG为资源会话分配收发数据的承载资源，创建用于收发会话数据的 临时纟冬端。
11 、根据权利要求10所述的方法，其特征在于，所述MG接收发往所 述地址资源的承载资源请求消息包括MG接收承载资源请求消息，将所述承载资源请求消息中的目的地址信 息与MG中的已有的临时终端的地址资源信息进行匹配，若没有匹配的临时 终端，则该承载资源请求消息为发往所述分配的用以接收承载请求消息的地 址资源的承载资源请求消息。
12、根据权利要求IO所述的方法，其特征在于，该方法进一步包括MGC接收MG为资源会话成功分配承载资源的响应消息，指示MG删 除所述用于接收承载请求消息的临时终端；或MG根据来自外部的资源删除消息，来删除所述地址资源信息；或 MG直接删除所述地址资源信息。
13、 根据权利要求10、 11或12所述的方法，其特征在于，所述MG接 收来自MGC的创建临时终端的指示信息之前，进一步包括所述MG向所述MGC成功注册之后，所述MGC向所述MG下发创建 临时终端的指示信息；或者，所述MGC收到业务层会话信息，向所述MG下发创建临时终端 的指示信息。
14、 一种承载资源预留系统，包括MG和MGC，其特征在于，所述MG用于在自身根终端上分配用以接收承载请求消息的地址资源， 接收发往所述地址资源信息的承载资源请求消息，并根据所收到的检测资源 请求事件的指示，向所述MGC上报相应的资源请求事件；所述MGC用于向所述MG下发检测资源请求事件的指示。
15、 根据权利要求14所述的系统，其特征在于，所述MGC进一步用 于向所述MG下发分配地址资源的指示，则所述MG用于根据所述指示分配 地址资源。
16、 根据权利要求14或15所述的系统，其特征在于，所述MGC进一 步用于对所收到的资源请求事件进行授权，指示MG为会话创建包括用以收 发会话数据的终端的承载资源，并将相关的资源信息发送给所述承载资源请 求的发送方。
17、 一种MG,其特征在于，所述MG包括地址资源管理模块，用于分配用以接收承载请求消息的地址资源，并将 所分配的地址资源通知上报模块；还用于根据所收到的承载资源分配指示分 配承载资源；接收模块，用于接收发往所述地址资源的承载请求消息，并将所接收的 承载请求消息发送至上报模块；还用于接收承载资源分配指示，并将所收到 的承载资源分配指示发送至地址资源管理模块；上报模块，用于根据所收到的承载请求消息生成资源请求事件，并将所生成的资源请求事件对外上报给M G C 。
18、根据权利要求17所述的MG,其特征在于，所述地址资源信息管 理模块进一步包括分配单元，用于分配用以接收承载请求消息的地址资源，以及分配会话 承载资源；删除单元，用于根据所述接收模块所收到的删除指示，或者在所述承载 资源分配模块已成功分配承载资源后，删除已分配的用以接收承载请求消息 的地址资源。
全文摘要
本发明公开了一种承载资源预留方法，包括如下步骤在媒体网关(MG)的根终端上分配用以接收承载请求消息的地址资源；MG接收发往所述地址资源的承载请求消息，并向媒体网关控制器(MGC)上报相应的资源请求事件；MGC根据所收到的资源请求事件进行资源策略决策，若所述资源请求被授权，则指示MG分配相应的承载资源。本发明还公开了一种承载资源预留系统和MG。本发明方案可以使MG和MGC在还没有为即将到来的会话创建必要资源的情况下，可以正确接收承载消息，以便及时决策和响应。
文档编号H04L12/54GK101345703SQ200710305330
公开日2009年1月14日 申请日期2007年12月25日 优先权日2007年8月6日
发明者杨玮玮 申请人:华为技术有限公司