CN103874240B - 一种信令发起方法、装置及网关设备 - Google Patents

Abstract

本发明实施例提供一种信令发起方法、装置及网关设备。所述方法包括：确定一触发信息；其中，所述触发信息与至少一个第一承载和至少一个第二承载相关；根据所述触发信息判断是否发起包括对所述至少一个第一承载进行第一类型处理的第一请求和对所述至少一个第二承载进行第二类型处理的第二请求的至少两个请求，获取一第一判断结果；当所述第一判断结果为是时，通过一个第一请求信令发起所述至少两个请求。本发明实施例通过一个第一请求信令发起不同类型的承载处理请求，从而减轻了网关设备的信令处理负担。

Description

一种信令发起方法、装置及网关设备

技术领域

本发明实施例涉及通信领域，尤其涉及一种信令发起方法、装置及网关设备。

背景技术

图1为演进的分组核心网（Evolved Packet Core，EPC）核心网络架构图，参照图1，在整个移动网络中，分组数据网（Packet Data Network，PDN）网关（PDN Gateway，PGW）位于移动网络的终点，PGW的主要功能如下：

用户报文过滤转发：根据为用户的安装过滤器，通过不同的承载（Bearer）转发报文；

合法监听；

为用户分配IP地址：提供地址，用于访问PDN网络资源；

用户计费：根据用户的时长、流量进行计费；

用户业务等级控制：不同用户的业务控制等级不同，此功能为不同的用户提供不同的服务等级；

DHCP服务器/客户端：PGW可以实现DHCP服务器、客户端功能。

从3GPP网络架构的演进来看，EPC网络中，把大部分的控制权都交到了PGW网元中，比如说用户、前向网元（如SGW、MME）无法发起专有承载的建立、修改、删除，任何操作，都需要通过命令（Command）消息通知到PGW，由PGW发起专有承载的操作。

另外EPC网络中特别强调PCRF的应用，用户的相关策略如计费方式、用户等级都是通过PCRF进行下发控制，PCRF发起的变更都将触发PGW发起专有承载的建立、修改或删除操作。

图2为PCRF触发的专有承载修改流程，参照图2，PCRF触发的专有承载修改流程如下：

步骤1：PCRF发送“IP连接接入网络（IP-Connectivity Access Network，IP-CAN）会话修改（Session Modification）”消息给PGW；

步骤2：PGW根据收到的IP-CAN Session Modification消息得到承载处理相关规则，根据该承载处理相关规则确定需要对某一或某些承载进行QoS参数更新，向服务网关（Serving Gateway，SGW）发送更新承载请求（Update BearerRequest）消息，通知更新该一或该些承载的QoS参数；

步骤3：SGW收到消息后转发消息到MME；

步骤4-步骤10：这几个步骤中，主要是MME通知eNodeB进行QoS参数更新，eNodeB检查自己的资源是否能够满足要求，如果能够满足，则应答成功；如果eNodeB发现自己的资源不足，那么eNodeB将拒绝此次更新（详细的请参看3GPP规范23.401）；

步骤11：SGW转发MME发过来的更新承载应答（Update Bearer Response）消息给PGW；

步骤12：PGW收到Update Bearer Response消息后，检查执行结果，并根据执行结果决定本地应用何种策略，例如应用最新的QoS参数。处理完成后PGW向PCRF发送应答消息，通知执行结果。

上面是标准的PCRF触发的承载修改，对于PCRF触发的承载创建、删除流程与修改流程类似，可参考图3、图4，详细的描述可参考3GPP规范23.401，在此不再赘述。

图5为UE触发承载资源请求命令，参照图5，用户触发的专有承载创建、修改、删除流程如下：

步骤1：UE发起专有承载参数的更新，如QoS、业务流模板（Traffic FlowTemplate，TFT）参数变更，发送请求承载资源修改（Request Bearer ResourceModification）消息给MME；

步骤2-3：MME、SGW将来自UE的Request Bearer Resource Modification消息中的参数变更信息通过承载资源命令（Bearer Resource Command）消息转发到PGW；

步骤4：PGW根据接收到的Bearer Resource Command消息中携带的参数，决定发起创建、修改或者删除承载流程。对于PGW来说，具体的操作与PCRF触发承载操作相同。

在某些情况下，PGW根据来自PCRF的IP-CAN Session Modification消息或来自UE的参数变更信息，可能确定发起大于一种类型的承载处理请求，以如下PGW应用场景为例：

某个用户在PCRF上签约的总带宽为6兆比特每秒（megabit per second，Mbps），可以建立3个专有承载，其中：

Bearer1用于IP多媒体子系统（IP Multimedia Subsystem，IMS）语音，预留带宽2Mbps；

Bearer2用于正常上网业务，预留带宽2Mbps；

Bearer3用于流媒体业务，预留带宽4Mbps。

用户上线后正常上网，做流媒体业务，此时建立了Bearer2和Bearer3；用户突然需要做IMS语音业务，PGW检测到业务后通知到PCRF，PCRF此时需要触发Bearer1的创建，但是发现当前Bearer2和Bearer3已经占了6Mbps带宽，如果要发起Bearer1的创建，必须要删除已经建立的承载，或者减小某个承载的带宽。

PCRF决策需要删除Bearer2，然后创建Bearer1，PCRF可能会将两个承载的处理相关规则通过一条消息下发给PGW。PGW检查到需要删除和创建，由于创建承载请求（CreateBearer Request）消息只能携带要创建的承载，删除承载请求（Delete Bearer Request消息）只能携带要删除的承载，PGW需要先发起Bearer2的删除，接着再发起Bearer1的创建。整个流程中PGW需要与前向网元交互2次才能完成，这就给PGW造成信令处理上的负担。

发明内容

有鉴于此，本发明实施例的目的是提供一种信令发起方法、装置及网关设备，以减轻网关设备的信令处理负担。

为解决上述技术问题，本发明实施例提供方案如下：

本发明实施例提供一种信令发起方法，用于一网关设备，所述方法包括：

确定一触发信息；其中，所述触发信息与至少一个第一承载和至少一个第二承载相关；

根据所述触发信息判断是否发起包括对所述至少一个第一承载进行第一类型处理的第一请求和对所述至少一个第二承载进行第二类型处理的第二请求的至少两个请求，获取一第一判断结果；

当所述第一判断结果为是时，通过一个第一请求信令发起所述至少两个请求。

优选的，所述确定一触发信息包括：

接收来自PCRF或UE的所述触发信息。

优选的，

所述第一类型为创建、修改和删除中的一种，所述第二类型为创建、修改和删除中不同于所述第一类型的一种。

优选的，所述至少两个请求还包括对至少一个第三承载进行第三类型处理的第三请求。

优选的，所述第一类型为创建，所述第二类型为修改，所述第三类型为删除。

优选的，所述第一请求信令为对支持发起所述第一请求的第二请求信令进行扩展后的扩展信令。

优选的，所述方法还包括：

接收一个针对所述第一请求信令的应答信令；其中，所述应答信令包括针对所述第一请求的第一应答信息；

判断所述应答信令是否包括针对所述第二请求的第二应答信息，获取一第二判断结果；

当所述第二判断结果为是时，根据所述第一类型处理所述第一应答信息，且根据所述第二类型处理所述第二应答信息；

当所述第二判断结果为否时，根据所述第一类型处理所述第一应答信息。

本发明实施例还提供一种信令发起装置，用于一网关设备，所述装置包括：

确定模块，用于确定一触发信息；其中，所述触发信息与至少一个第一承载和至少一个第二承载相关；

判断模块，用于根据所述触发信息判断是否发起包括对所述至少一个第一承载进行第一类型处理的第一请求和对所述至少一个第二承载进行第二类型处理的第二请求的至少两个请求，获取一第一判断结果；

发起模块，用于当所述第一判断结果为是时，通过一个第一请求信令发起所述至少两个请求。

优选的，所述确定模块包括：

第一接收模块，用于接收来自PCRF或UE的所述触发信息。

优选的，

所述第一类型为创建、修改和删除中的一种，所述第二类型为创建、修改和删除中不同于所述第一类型的一种。

优选的，所述第一请求信令为对支持发起所述第一请求的第二请求信令进行扩展后的扩展信令。

优选的，所述装置还包括：

第二接收模块，用于接收一个针对所述第一请求信令的应答信令；其中，所述应答信令包括针对所述第一请求的第一应答信息；

判断单元，用于判断所述应答信令是否包括针对所述第二请求的第二应答信息，获取一第二判断结果；

第一处理单元，用于当所述第二判断结果为是时，根据所述第一类型处理所述第一应答信息，且根据所述第二类型处理所述第二应答信息；

第二处理单元，用于当所述第二判断结果为否时，根据所述第一类型处理所述第一应答信息。

本发明实施例还提供一种包括以上所述的信令发起装置的网关设备。

从以上所述可以看出，本发明实施例至少具有如下有益效果：

通过一个第一请求信令发起不同类型的承载处理请求，从而网关设备只需要与前向网元交互一次，从而减轻了网关设备的信令处理负担。

附图说明

图1为现有技术的EPC网络架构图；

图2为现有技术的PCRF触发的专有承载修改流程的示意图；

图3为现有技术的PCRF触发的专有承载创建流程的示意图；

图4为现有技术的PCRF触发的专有承载删除流程的示意图；

图5为现有技术的UE触发承载资源请求命令；

图6为本发明实施例提供的一种信令发起方法的流程示意图；

图7为本发明较佳实施例一的PCRF通过一条消息触发的专有承载修改及删除流程的示意图；

图8为本发明较佳实施例二的PCRF通过一条消息触发的专有承载创建及删除流程的示意图。

[缩略语及中英文对照]

MME Mobility Management Entity，移动性管理实体

UTRAN Universal Terrestrial Radio Access Network，通用陆地无线接入网络

E-UTRAN Evolved Universal Terrestrial Radio Access Network，演进通用陆地无线接入网络

GERAN GSM EDGE Radio Access Network，GSM、EDGE无线接入网络

UE User Equipment，用户设备

SGSN Serving GPRS Support Node，GPRS服务支持节点

HSS Home Subscriber Server，归属用户服务器

PCRF Policy and charging rule function，策略与计费规则功能

Operator’s IP Services：运营商网络服务

IMS IP Multimedia Subsystem，IP多媒体子系统

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明实施例进行详细描述。

图6为本发明实施例提供的一种信令发起方法的流程示意图，参照图6，该信令发起方法包括如下步骤：

步骤601，确定一触发信息；其中，所述触发信息与至少一个第一承载和至少一个第二承载相关；

步骤602，根据所述触发信息判断是否发起包括对所述至少一个第一承载进行第一类型处理的第一请求和对所述至少一个第二承载进行第二类型处理的第二请求的至少两个请求，获取一第一判断结果；

步骤603，当所述第一判断结果为是时，通过一个第一请求信令发起所述至少两个请求。

该信令发起方法可以用于一网关设备。

可见，通过一个第一请求信令发起不同类型的承载处理请求，从而网关设备只需要与前向网元交互一次，从而减轻了网关设备的信令处理负担。

在本发明实施例中，所述网关设备可以为PGW。

PGW作为移动网络的终点，需要处理整个移动网络中的用户的信令报文，并提供用户的数据转发服务。从实际应用角度看，一个PGW的容量往往会达到十几万到上百万的用户量，每个用户产生一条信令，对于PGW来说就是几十万到上百万条，而如果每个用户产生更多条信令，PGW需要处理的信令条数就会更多。而PGW的处理能力有限，高峰时可能无法应付如此大的数据量。因此，减轻PGW的信令处理负担是非常重要的。

在本发明实施例中，承载的类型可以为EPC中的专有承载或默认承载。

所述触发信息可以由PGW根据本地配置或者来自在线计费系统（OnlineChargingSystem，OCS）的业务相关信息生成；或者，也可以来自PCRF或UE，则有：

所述确定一触发信息包括：

接收来自PCRF或UE的所述触发信息。

具体地，对于所述触发信息来自PCRF的情况，所述触发信息可以为PCRF发送的IP-CAN Session Modification消息，其中携带了与所述至少一个第一承载和所述至少一个第二承载相关的规则；对于所述触发信息来自UE的情况，所述触发信息可以为RequestBearer Resource Modification消息中与所述至少一个第一承载和所述至少一个第二承载相关的的参数变更信息等触发内容，由MME通过Bearer Resource Command消息经由SGW转发给PGW。

此外，所述触发信息也可以来自大于一个设备，例如：

所述触发信息可以包括与至少一个第一承载相关的第一触发信息和与至少一个第二承载相关的第二触发信息。所述第一触发信息和所述第二触发信息可以分别来自UE和PCRF，或者分别来自PCRF和UE。

这里的类型是指针对承载的处理类型。对于至少一个第一承载包括的承载数目大于1的情况，至少一个第一承载中的不同承载对应的处理类型相同，但并不限制对不同承载的具体处理是否相同。例如，对于至少一个第一承载对应的处理类型为创建的情况，至少一个第一承载中不同承载对应的QoS参数可以相同也可以不同。对于至少一个第一承载对应的处理类型为修改的情况，至少一个第一承载中不同承载对应的更新后的QoS参数可以相同也可以不同。同样地，对于至少一个第二承载包括的承载数目大于1的情况，至少一个第二承载中的不同承载对应的处理类型相同，但并不限制对不同承载的具体处理是否相同。

前面提到，所述触发信息可以包括与至少一个第一承载相关的第一触发信息和与至少一个第二承载相关的第二触发信息。则在至少一个第一承载包括的承载数目大于1的情况下，所述第一触发信息中对应至少一个第一承载中一部分承载的触发信息和剩余部分承载的触发信息可以分别来自UE和PCRF，或者分别来自PCRF和UE。在至少一个第二承载包括的承载数目大于1的情况下，所述第二触发信息中对应至少一个第二承载中一部分承载的触发信息和剩余部分承载的触发信息可以分别来自UE和PCRF，或者分别来自PCRF和UE。

在本发明实施例中，所述第一类型可以为创建、修改和删除中的一种，所述第二类型可以为创建、修改和删除中不同于所述第一类型的一种。

在本发明实施例中，进一步地，所述至少两个请求还可以包括对至少一个第三承载进行第三类型处理的第三请求。

其中，所述第一类型可以为创建，所述第二类型可以为修改，所述第三类型可以为删除。

在本发明实施例中，所述第一请求信令可以为对支持发起所述第一请求的第二请求信令进行扩展后的扩展信令，例如，扩展的Create Bearer Request消息，扩展的UpdateBearer Request消息或扩展的Delete Bearer Request消息。具体地，

考虑到所述至少两个请求包括第一请求和第二请求的情况，当所述第一类型为创建、所述第二类型为修改时，该扩展的Create Bearer Request消息可以为在现有技术的Create Bearer Request消息的基础上添加被修改的承载上下文信息元素（InformationElement，IE）后得到，其中，发起第一请求所需信息和发起第二请求所需信息可以分别包括在现有技术的Create Bearer Request消息本身就包括的承载上下文IE中和该被修改的承载上下文IE中，该被修改的承载上下文IE可以添加到现有技术的Create Bearer Request消息中的任意位置，例如，任意两个相邻IE之间，第一个IE之前，或者最后一个IE之后。

当所述第一类型为创建、所述第二类型为删除时，该扩展的CreateBearerRequest消息可以为在现有技术的Create Bearer Request消息的基础上添加了被删除的承载上下文IE后得到，其中，发起第一请求所需信息和发起第二请求所需信息可以分别包括在现有技术的Create Bearer Request消息本身就包括的承载上下文IE中和该被删除的承载上下文IE中，该被删除的承载上下文IE可以添加到现有技术的Create BearerRequest消息中的任意位置。

当所述第一类型为修改、所述第二类型为删除时，该扩展的UpdateBearerRequest消息可以为在现有技术的Update Bearer Request消息的基础上添加了被删除的承载上下文IE后得到，其中，发起第一请求所需信息和发起第二请求所需信息可以分别包括在现有技术的Update Bearer Request消息本身就包括的承载上下文IE中和该被删除的承载上下文IE中，该被删除的承载上下文IE可以添加到现有技术的Update BearerRequest消息中的任意位置。

而，考虑到所述至少两个请求还包括第三请求的情况，该扩展的CreateBearerRequest消息也可以为在现有技术的Create Bearer Request消息的基础上增加了被修改的承载上下文IE和被删除的承载上下文IE后得到，其中，发起第一请求所需信息、发起第二请求所需信息和发起第三请求所需信息可以分别包括在现有技术的Create BearerRequest消息本身就包括的承载上下文IE中、该被修改的承载上下文IE中和该被删除的承载上下文IE中，该被修改的承载上下文IE和该被删除的承载上下文IE可以添加到现有技术的Create BearerRequest消息中的任意位置，且这两个IE出现该扩展的Create BearerRequest消息中的前后顺序没有要求。

需要说明的是，这里只是列举了扩展消息的几个典型例子，其基本原理在于，使用现有技术的消息中的现有IE来承载与该消息对应的承载处理类型一致的类型的处理请求，而不一致的类型的处理请求则通过在该消息的基础上添加的新的IE来承载。由此，本领域技术人员可以直接得到在现有技术的CreateBearer Request消息、Update BearerRequest消息和Delete Bearer Request消息的基础上进行消息扩展的其它方式以支持通过一个第一请求信令发起所述至少两个请求。这些其它方式也在本发明实施例的记载范围之内，在此不再赘述。

进一步地，考虑到在工程实现中，被发起所述处理请求的网络设备可能不支持所述第一请求信令，有鉴于此，所述方法还可以包括：

接收一个针对所述第一请求信令的应答信令；其中，所述应答信令包括针对所述第一请求的第一应答信息；

判断所述应答信令是否包括针对所述第二请求的第二应答信息，获取一第二判断结果；

当所述第二判断结果为是时，根据所述第一类型处理所述第一应答信息，且根据所述第二类型处理所述第二应答信息；

当所述第二判断结果为否时，根据所述第一类型处理所述第一应答信息。

具体地，所述应答信令可以为支持所述第一类型的现有信令，例如，现有技术的创建承载应答（Create Bearer Response）消息，现有技术的Update BearerResponse消息或现有技术的删除承载应答（Delete Bearer Response）消息；或者，也可以为在该现有信令的基础上进行扩展后的扩展信令，例如，扩展的Create Bearer Response消息，扩展的Update Bearer Response消息或扩展的Delete Bearer Response消息。则对于所述应答信令为该扩展信令的情况，所述第二判断结果为是；对于所述应答信令为该现有信令的情况，所述第二判断结果为否。

更具体地，与前面对所述第一请求信令的描述对应，下面举出几个扩展的CreateBearer Response消息和扩展的Update Bearer Response消息的例子：

当所述第一类型为创建、所述第二类型为修改时，扩展的Create BearerResponse消息可以为在现有技术的Create Bearer Response消息的基础上添加被修改的承载上下文IE后得到，其中，所述第一应答信息和所述第二应答信息可以分别包括在现有技术的Create Bearer Response消息本身就包括的承载上下文IE中和该被修改的承载上下文IE中，该被修改的承载上下文IE可以添加到现有技术的Create Bearer Response消息中的任意位置，例如，任意两个相邻IE之间，第一个IE之前，或者最后一个IE之后。

当所述第一类型为创建、所述第二类型为删除时，扩展的Create BearerResponse消息可以为在现有技术的Create Bearer Response消息的基础上添加了标记为删除的承载上下文IE后得到，其中，所述第一应答信息和所述第二应答信息可以分别包括在现有技术的Create Bearer Response消息本身就包括的承载上下文IE中和该标记为删除的承载上下文IE中，该标记为删除的承载上下文IE可以添加到现有技术的Create BearerResponse消息中的任意位置。

当所述第一类型为修改、所述第二类型为删除时，扩展的Update BearerResponse消息可以为在现有技术的Update Bearer Response消息的基础上添加了标记为删除的承载上下文IE后得到，其中，所述第一应答信息和所述第二应答信息可以分别包括在现有技术的Update Bearer Response消息本身就包括的承载上下文IE中和该标记为删除的承载上下文IE中，该标记为删除的承载上下文IE可以添加到现有技术的Update BearerResponse消息中的任意位置。

对于所述至少两个请求还包括第三请求的情况，当所述第一类型为创建、所述第二类型为修改、所述第三类型为删除时，扩展的Create Bearer Response消息也可以为在现有技术的Create Bearer Response消息的基础上增加了被修改的承载上下文IE和标记为删除的承载上下文IE后得到，该被修改的承载上下文IE和该标记为删除的承载上下文IE可以添加到现有技术的Create BearerResponse消息中的任意位置，且这两个IE出现该扩展的Create Bearer Response消息中的前后顺序没有要求。

同样需要说明的是，这里只是列举了扩展消息的几个典型例子，其基本原理在于，使用现有技术的消息中的现有IE来承载针对与该消息对应的承载处理类型一致的类型的处理请求的应答信息，而针对不一致的类型的处理请求的应答信息则通过在该消息的基础上添加的新的IE来承载。由此，本领域技术人员可以直接得到在现有技术的Create BearerResponse消息、Update BearerResponse消息和Delete Bearer Response消息的基础上进行消息扩展的其它方式以支持通过一个应答信令来应答所述第一请求信令。这些其它方式也在本发明实施例的记载范围之内，在此不再赘述。

在本发明实施例中，对于所述至少两个请求还包括第三请求的情况，当所述第一类型为创建、所述第二类型为修改、所述第三类型为删除时，上述“判断所述应答信令是否包括针对所述第二请求的第二应答信息”可以替换为“判断所述应答信令是否包括针对所述第二请求的第二应答信息和针对所述第三请求的第三应答信息”，则所述第一应答信息、所述第二应答信息和所述第三应答信息可以分别包括在现有技术的Create BearerResponse消息本身就包括的承载上下文IE中、该被修改的承载上下文IE中和该标记为删除的承载上下文IE中。

为了对扩展的消息表述得更加清楚明白，下面给出几个扩展消息的例子。

表1.1给出了扩展的Update Bearer Request消息在现有技术的UpdateBearerRequest消息的基础上添加被修改的承载上下文IE的格式和内容。表1.2给出了该被修改的承载上下文IE的格式和内容。

表1.1：更新承载请求消息内容变更

更新承载请求消息增加如下可选信息元素，可以出现在任何位置：

表1.2：更新承载请求消息中的被删除的承载上下文IE

表2.1给出了扩展的Update Bearer Response消息在现有技术的UpdateBearerResponse消息的基础上添加标记为删除的承载上下文IE的格式和内容。表2.2给出了该标记为删除的承载上下文IE的格式和内容。

表2.1：更新承载应答消息内容变更

更新承载应答消息增加如下可选信息元素，可以出现在任何位置：

表2.2：更新承载应答中的标记为删除的承载上下文IE

表3.1给出了扩展的Create Bearer Request消息在现有技术的CreateBearerRequest消息的基础上添加被修改的承载上下文IE和被删除的承载上下文IE的格式和内容。表3.2给出了该被修改的承载上下文IE的格式和内容。表3.3给出了该被删除的承载上下文IE的格式和内容。

表3.1：创建承载请求消息内容变更

创建承载请求消息增加如下可选信息元素，可以出现在任何位置：

表3.2：创建承载请求中的被修改的承载上下文IE

表3.3：创建承载请求中的被删除的承载上下文IE

表4.1给出了扩展的Create Bearer Response消息在现有技术的CreateBearerResponse消息的基础上添加修改的承载上下文IE和标记为删除的承载上下文IE的格式和内容。表4.2给出了该修改的承载上下文IE的格式和内容。表4.3给出了该标记为删除的承载上下文IE的格式和内容。

表4.1：创建承载应答消息内容变更

创建承载应答消息增加如下可选信息元素，可以出现在任何位置：

表4.2：创建承载应答消息中的修改的承载上下文IE

表4.3：创建承载应答消息中的标记为删除的承载上下文IE

需要说明的是，这里只是给出了几个扩展的消息的消息内容和格式的例子，本领域技术人员通过这几个例子可以直接得到通过其它方式进行消息扩展所对应的消息内容和格式，在此不再赘述。

为了对本发明实施例进一步阐述清楚，下面给出本发明的两个较佳实施例。

<本发明较佳实施例一>

在本发明较佳实施例一中，所述网关设备为PGW；

所述触发信息为来自PCRF的IP-CAN Session Modification消息；

所述第一类型为修改，所述第二类型为删除；

所述第一请求信令为扩展的Update Bearer Request消息，该消息在现有的Update Bearer Request消息的基础上添加了“被删除的承载上下文IE”；

所述第一请求信令由PGW发送给SGW，并由SGW转发给MME；

所述应答信令由MME发送给SGW，并由SGW转发给PGW；

对于所述应答信令，如果MME不支持对该扩展的Update Bearer Request消息中的“请求的删除承载列表”的处理，则所述应答信令为现有的UpdateBearer Response消息，不包含“标记为删除的承载上下文IE”；如果MME支持对该扩展的Update Bearer Request消息中的“标记为删除的承载上下文IE”的处理，则所述应答信令为扩展的Update BearerResponse消息，该消息在现有的Update Bearer Request消息中增加了“标记为删除的承载上下文IE”。

图7为本发明较佳实施例一的PCRF通过一条消息触发的专有承载修改及删除流程的示意图，参照图7，本发明较佳实施例一的流程包括如下步骤：

步骤701，PCRF触发专有承载修改，通过IP-CAN Session Modification消息向PGW下发供PGW确定需要对部分承载进行删除操作的规则；

步骤702，PGW解析PCRF下发的规则，发现要对部分承载进行删除操作；PGW构造扩展的Update Bearer Request消息，其中携带与PCRF下发的规则对应的被删除的承载上下文IE；

步骤703，SGW转发扩展的Update Bearer Request消息到MME；

步骤704，MME根据SGW转发的该扩展的Update Bearer Request消息进行与UE之间的可能的信令交互，并生成扩展的Update Bearer Response消息，将该消息发送给SGW；

步骤705，SGW将来自MME的该扩展的Update Bearer Response消息转发给PGW，PGW收到该消息后，同时处理该消息中的“承载上下文IE”和“标记为删除的承载上下文IE”，完成后该“标记为删除的承载上下文IE”中的所有“删除的承载”正常删除。

考虑到在工程实现中，有的MME可能支持所述第一请求信令，有的MME可能不支持所述第一请求信令，则PGW对于来自SGW的Update BearerResponse消息会有一个判断的过程，根据判断的结果来进行不同的处理，从而步骤704中的“扩展的Update BearerResponse消息”可以替换为“现有的或扩展的Update Bearer Response消息”，且步骤705可以替换为：

SGW将来自MME的该扩展的Update Bearer Response消息转发给PGW，PGW收到该消息后，检查该消息，判断其中是否含有“标记为删除的承载上下文IE”，如果判断结果为否，则PGW不对步骤702中的“被删除的承载上下文IE”中的“删除的承载”进行任何操作，当作什么都没有发生过，继续处理Update Bearer Response消息中的“承载上下文IE”。完成后步骤702中的“被删除的承载上下文IE”中的所有“删除的承载”继续保持原状态。而如果判断结果为是，则PGW同时处理来自SGW的Update Bearer Response消息中的“承载上下文IE”和“标记为删除的承载上下文IE”，完成后该“标记为删除的承载上下文IE”中的所有“删除的承载”被正常删除。

<本发明较佳实施例二>

在本发明较佳实施例二中，所述网关设备为PGW；

所述触发信息为来自PCRF的IP-CAN Session Modification消息；

所述第一类型为创建，所述第二类型为修改；

所述第一请求信令为扩展的Create Bearer Request消息，该消息在现有的Create Bearer Request消息中增加了“被修改的承载上下文IE”；

所述第一请求信令由PGW发送给SGW，并由SGW转发给MME；

所述应答信令由MME发送给SGW，并由SGW转发给PGW；

对于所述应答信令，如果MME不支持对该扩展的Create Bearer Request消息中的“被修改的承载上下文IE”的处理，则所述应答信令为现有的CreateBearer Response消息，不包含“修改的承载上下文IE”；如果MME支持对该扩展的Create Bearer Request消息中的“被修改的承载上下文IE”的处理，则所述应答信令为扩展的Create Bearer Response消息，该消息在现有的CreateBearer Request消息中增加了“修改的承载上下文IE”。

图8为本发明较佳实施例二的PCRF通过一条消息触发的专有承载创建及删除流程的示意图，参照图8，本发明较佳实施例二的流程包括如下步骤：

步骤801，PCRF触发专有承载创建，通过IP-CAN Session Modification消息向PGW下发供PGW确定需要对部分承载进行修改操作的规则；

步骤802，PGW解析PCRF下发的规则，发现要对部分承载进行修改操作；PGW构造扩展的Create Bearer Request消息，其中携带与PCRF下发的规则对应的“被修改的承载上下文IE”；

步骤803，SGW转发扩展的Create Bearer Request消息到MME；

步骤804，MME根据SGW转发的该扩展的Create Bearer Request消息进行与UE之间的可能的信令交互，并生成扩展的Create Bearer Response消息，将该消息发送给SGW；

步骤805，SGW将来自MME的该扩展的Create Bearer Response消息转发给PGW，PGW收到该消息后，处理该消息中的“承载上下文IE”和“修改的承载上下文IE”，完成后该“修改的承载上下文IE”中的所有“修改的承载”修改完成。

考虑到在工程实现中，有的MME可能支持所述第一请求信令，有的MME可能不支持所述第一请求信令，则PGW对于来自SGW的Create BearerResponse消息会有一个判断的过程，根据判断的结果来进行不同的处理，从而步骤804中的“扩展的Create BearerResponse消息”可以替换为“现有的或扩展的Create Bearer Response消息”，且步骤805可以替换为：

SGW将来自MME的该扩展的Create Bearer Response消息转发给PGW，PGW收到该消息后，检查该消息，判断其中是否含有“修改的承载上下文IE”，如果判断结果为否，则PGW不对步骤802中的“被修改的承载上下文IE”中的“修改的承载”进行任何操作，当作什么都没有发生过，继续处理CreateBearer Response消息中的“承载上下文IE”。完成后步骤802中的“被修改的承载上下文IE”中的所有“修改的承载”继续保持原状态。而如果判断结果为是，则PGW同时处理来自SGW的Create Bearer Response消息中的“承载上下文IE”和“修改的承载上下文IE”，完成后该“修改的承载上下文IE”中的所有“修改的承载”修改完成。

<本发明较佳实施例三>

在本发明较佳实施例三中，所述网关设备为PGW；

所述触发信息为来自PCRF的IP-CAN Session Modification消息；

所述第一类型为创建，所述第二类型为修改，所述第三类型为删除；

所述第一请求信令为扩展的Create Bearer Request消息，该消息在现有的Create Bearer Request消息中增加了“被修改的承载上下文IE”和“被删除的承载上下文IE”；

所述第一请求信令由PGW发送给SGW，并由SGW转发给MME；

所述应答信令由MME发送给SGW，并由SGW转发给PGW；

对于所述应答信令，如果MME不支持对该扩展的Create Bearer Request消息中的“被修改的承载上下文IE”和“被删除的承载上下文IE”的处理，则所述应答信令为现有的Create Bearer Response消息，不包含“修改的承载上下文IE”和“标记为删除的承载上下文IE”；如果MME支持对该扩展的CreateBearer Request消息中的“被修改的承载上下文IE”和“被删除的承载上下文IE”的处理，则所述应答信令为扩展的Create Bearer Response消息，该消息在现有的Create Bearer Response消息中增加了“修改的承载上下文IE”和“标记为删除的承载上下文IE”。

本发明较佳实施例三的专有承载创建、修改及删除流程包括如下步骤：

步骤901，PCRF触发专有承载创建，通过IP-CAN Session Modification消息向PGW下发供PGW确定需要对部分承载进行修改操作及对部分承载进行删除操作的规则；

步骤902，PGW解析PCRF下发的规则，发现要对部分承载进行修改操作及对部分承载进行删除操作；PGW构造扩展的Create Bearer Request消息，其中携带与PCRF下发的规则对应的“被修改的承载上下文IE”和“被删除的承载上下文IE”；

步骤903，SGW转发扩展的Create Bearer Request消息到MME；

步骤904，MME根据SGW转发的该扩展的Create Bearer Request消息，进行与UE之间的可能的信令交互，并生成扩展的Create Bearer Response消息，将该消息发送给SGW；

步骤905，SGW将来自MME的该扩展的Create Bearer Response消息转发给PGW，PGW收到该消息后，处理该消息中的“承载上下文IE”、“修改的承载上下文IE”和“标记为删除的承载上下文IE”，完成后该“标记为删除的承载上下文IE”中的所有“删除的承载”被删除，该“修改的承载上下文IE”中的所有“修改的承载”修改完成。

考虑到在工程实现中，有的MME可能支持所述第一请求信令，有的MME可能不支持所述第一请求信令，则PGW对于来自SGW的Create BearerResponse消息会有一个判断的过程，根据判断的结果来进行不同的处理，从而步骤904中的“扩展的Create BearerResponse消息”可以替换为“现有的或扩展的Create Bearer Response消息”，且步骤905可以替换为：

SGW将来自MME的该扩展的Create Bearer Response消息转发给PGW，PGW收到该消息后，检查该消息，判断其中是否含有“修改的承载上下文IE”和“标记为删除的承载上下文IE”，如果判断结果为否，则PGW不对步骤902中的“被修改的承载上下文IE”中的“修改的承载”和“被删除的承载上下文IE”中的“删除的承载”进行任何操作，当作什么都没有发生过，继续处理Create Bearer Response消息中的“承载上下文IE”。完成后步骤902中的“被修改的承载上下文IE”中的所有“修改的承载”和“被删除的承载上下文IE”中的所有“删除的承载”继续保持原状态。而如果判断结果为是，则PGW同时处理来自SGW的Create BearerResponse消息中的“承载上下文IE”、“修改的承载上下文IE”和“标记为删除的承载上下文IE”，完成后该“标记为删除的承载上下文IE”中的所有“删除的承载”被删除，该“修改的承载上下文IE”中的所有“修改的承载”修改完成。

本发明实施例还提供一种信令发起装置，所述装置包括：

确定模块，用于确定一触发信息；其中，所述触发信息与至少一个第一承载和至少一个第二承载相关；

判断模块，用于根据所述触发信息判断是否发起包括对所述至少一个第一承载进行第一类型处理的第一请求和对所述至少一个第二承载进行第二类型处理的第二请求的至少两个请求，获取一第一判断结果；

发起模块，用于当所述第一判断结果为是时，通过一个第一请求信令发起所述至少两个请求。

所述装置可以用于一网关设备。

可见，通过一个第一请求信令发起不同类型的承载处理请求，从而减轻了网关设备的信令处理负担。

其中，所述确定模块可以包括：

第一接收模块，用于接收来自PCRF或UE的所述触发信息。

所述第一类型可以为创建、修改和删除中的一种，所述第二类型可以为创建、修改和删除中不同于所述第一类型的一种。

所述第一请求信令可以为对支持发起所述第一请求的第二请求信令进行扩展后的扩展信令。

进一步地，所述装置还可以包括：

第二接收模块，用于接收一个针对所述第一请求信令的应答信令；其中，所述应答信令包括针对所述第一请求的第一应答信息；

判断单元，用于判断所述应答信令是否包括针对所述第二请求的第二应答信息，获取一第二判断结果；

第一处理单元，用于当所述第二判断结果为是时，根据所述第一类型处理所述第一应答信息，且根据所述第二类型处理所述第二应答信息；

第二处理单元，用于当所述第二判断结果为否时，根据所述第一类型处理所述第一应答信息。

本发明实施例还提供一种网关设备，包括以上所述的信令发起装置。所述网关设备例如：PGW。

以上所述仅是本发明实施例的实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明实施例原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明实施例的保护范围。

Claims (11)

1.一种信令发起方法，用于一网关设备，其特征在于，所述方法包括：

确定一触发信息；其中，所述触发信息与至少一个第一承载和至少一个第二承载相关；

根据所述触发信息判断是否发起包括对所述至少一个第一承载进行第一类型处理的第一请求和对所述至少一个第二承载进行第二类型处理的第二请求的至少两个请求，获取一第一判断结果；

当所述第一判断结果为是时，通过一个第一请求信令发起所述至少两个请求；

所述方法还包括：

接收一个针对所述第一请求信令的应答信令；其中，所述应答信令包括针对所述第一请求的第一应答信息；

判断所述应答信令是否包括针对所述第二请求的第二应答信息，获取一第二判断结果；

当所述第二判断结果为是时，根据所述第一类型处理所述第一应答信息，且根据所述第二类型处理所述第二应答信息；

当所述第二判断结果为否时，根据所述第一类型处理所述第一应答信息。

2.如权利要求1所述的方法，其特征在于，所述确定一触发信息包括：

接收来自策略与计费规则功能PCRF或用户设备UE的所述触发信息。

3.如权利要求1所述的方法，其特征在于，

所述第一类型为创建、修改和删除中的一种，所述第二类型为创建、修改和删除中不同于所述第一类型的一种。

4.如权利要求1所述的方法，其特征在于，所述至少两个请求还包括对至少一个第三承载进行第三类型处理的第三请求。

5.如权利要求4所述的方法，其特征在于，所述第一类型为创建，所述第二类型为修改，所述第三类型为删除。

6.如权利要求1所述的方法，其特征在于，所述第一请求信令为对支持发起所述第一请求的第二请求信令进行扩展后的扩展信令。

7.一种信令发起装置，用于一网关设备，其特征在于，所述装置包括：

确定模块，用于确定一触发信息；其中，所述触发信息与至少一个第一承载和至少一个第二承载相关；

判断模块，用于根据所述触发信息判断是否发起包括对所述至少一个第一承载进行第一类型处理的第一请求和对所述至少一个第二承载进行第二类型处理的第二请求的至少两个请求，获取一第一判断结果，所述第一判断结果用于表明所述第一请求和所述第二请求的类型是否不同；

发起模块，用于当所述第一判断结果为是时，通过一个第一请求信令发起所述至少两个请求；

所述装置还包括：

第二接收模块，用于接收一个针对所述第一请求信令的应答信令；其中，所述应答信令包括针对所述第一请求的第一应答信息；

判断单元，用于判断所述应答信令是否包括针对所述第二请求的第二应答信息，获取一第二判断结果；

第一处理单元，用于当所述第二判断结果为是时，根据所述第一类型处理所述第一应答信息，且根据所述第二类型处理所述第二应答信息；

第二处理单元，用于当所述第二判断结果为否时，根据所述第一类型处理所述第一应答信息。

8.如权利要求7所述的装置，其特征在于，所述确定模块包括：

第一接收模块，用于接收来自策略与计费规则功能PCRF或用户设备UE的所述触发信息。

9.如权利要求7所述的装置，其特征在于，

所述第一类型为创建、修改和删除中的一种，所述第二类型为创建、修改和删除中不同于所述第一类型的一种。

10.如权利要求7所述的装置，其特征在于，所述第一请求信令为对支持发起所述第一请求的第二请求信令进行扩展后的扩展信令。

11.一种网关设备，其特征在于，包括权利要求7至10中任一项所述的信令发起装置。