CN102546370B - 业务流修改处理方法、装置和系统 - Google Patents

Abstract

本发明实施例提供一种业务流修改处理方法、装置和系统。业务流修改处理方法，包括：接收修改请求消息，所述修改请求消息用于对已建立的业务流进行参数修改处理；若所述参数修改处理为新增目的对端，且本地路由策略为路径绑定方式的路由策略，则拒绝该修改处理。本发明实施例可以避免出现采用Bearer binding方式进行LR处理时，时常出现某一对端用户误收到本端用户发送给另一对端用户的数据的现象。

Description

业务流修改处理方法、装置和系统

技术领域

本发明实施例涉及通信领域，尤其涉及一种业务流修改处理方法、装置和系统。

背景技术

随着通信技术的快速发展，如何节约数据传输路径资源，降低运营成本，成为各运营商和设备商关注的问题。本地路由(Location Routing，以下简称：LR)技术即为目前解决这一问题的普遍方法。

图1为现有技术中LR技术的网络结构示意图，如图1所示，在传统的路由技术中，用户1向用户2发送数据时，数据的传输路径为：用户1-＞无线接入网-＞核心网-＞无线接入网-＞用户2。因此，从无线接入网到核心网，再从核心网到无线接入网的数据传输路径是重叠的，也即通信承载上下行是重叠的，因此，浪费了网络侧的数据传输资源。LR技术即为当通信承载上下行有重叠时，在最靠近通信节点的网元处进行数据转发。具体来说，对于用户1发送给用户2的数据报文来说，无线接入网(Access Service Network，以下简称：ASN)可以先判断用户1的地址和用户2的地址是否都位于ASN的服务范围内，若不是，则ASN可以采用传统的路由技术，通过核心网转发；若是，则ASN可以采用LR技术，在本地交换单元，例如ASN中的基站(BaseStation，以下简称：BS)或者网关(Gateway，以下简称：GW)处向用户2转发。因此，LR技术可以将本地业务限制在ASN范围内部，从而避免了数据传输资源的浪费，提高了接入效率。目前，LR技术可以采用路径绑定(以下简称：Bearer binding)和IP绑定(以下简称：IP binding)两种方式实现。其中，Bearer binding适用于本地上行承载的目的端为某一特定对端的情况，也即，该本地上行承载上的数据都具有相同的目的IP。Bearer binding可以通过在业务流建立时直接建立本地用户的上行承载和通信对端的下行承载之间的关联关系来实现。该映射关系建立后，ASN中的BS或GW即可直接在关联的上下行业务流之间进行数据转发。

现有采用Bearer binding方式进行LR处理时，时常出现某一对端用户误收到本端用户发送给另一对端用户的数据的现象。

发明内容

本发明实施例提供一种业务流修改处理方法、装置和系统，以避免出现采用Bearer binding方式进行LR处理时，时常出现某一对端用户误收到本端用户发送给另一对端用户的数据的现象。

本发明实施例提供一种业务流修改处理方法，包括：

接收修改请求消息，所述修改请求消息用于对已建立的业务流进行参数修改处理；

若所述参数修改处理为新增目的对端，且本地路由策略为路径绑定方式的路由策略，则拒绝该修改处理。

本发明实施例提供一种业务流修改处理装置，包括：

接收模块，用于接收修改请求消息，所述修改请求消息用于对已建立的业务流进行参数修改处理；

处理模块，用于若所述参数修改处理为新增目的对端，且本地路由策略为路径绑定方式的路由策略，则拒绝该修改处理。

本发明实施例提供一种业务流修改处理系统，包括：Serving SFA设备和Anchor SFA设备，

所述Anchor SFA设备，用于向所述Serving SFA设备发送业务流修改请求消息，所述业务流修改消息用于对已建立的业务流进行参数修改处理；接收所述Serving SFA设备根据所述业务流修改请求消息发送的拒绝修改响应消息，并向所述Serving SFA设备发送新建业务流请求消息；

所述Serving SFA设备，用于接收所述Anchor SFA设备发送的业务流修改请求消息，若本地路由策略为路径绑定方式的路由策略，则向所述AnchorSFA设备发送拒绝修改响应消息，接收所述Anchor SFA设备发送的所述新建业务流请求消息。

本发明实施例在接收到路径修改请求消息后，如果确定该路径修改请求消息是要对已建立的业务流新增目的对端且本地路由策略为路径绑定方式的路由策略，则可以拒绝本次修改处理，从而避免在Bearer Binding方式下，将需要发送给新增的目的对端的数据发送到已经绑定的特定目的对端的现象。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术中LR技术的网络结构示意图；

图2为本发明业务流修改处理方法实施例一的流程图；

图3为本发明业务流修改处理方法实施例二的信令流程图；

图4为本发明业务流修改处理方法实施例三的信令流程图；

图5为本发明业务流修改处理方法实施例四的信令流程图；

图6为本发明业务流修改处理方法实施例五的信令流程图；

图7为本发明业务流修改处理装置实施例一的结构示意图；

图8为本发明业务流修改处理装置实施例二的结构示意图；

图9为本发明业务流修改处理装置实施例三的结构示意图；

图10为本发明业务流修改处理装置实施例四的结构示意图；

图11为本发明业务流修改处理系统实施例的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在现有技术中，采用Bearer binding方式的前提是本地路由承载上的数据的目的地址为一个特定对端。但ASN中的BS或GW在采用Bearer binding方式时，终端或者锚点业务流授权(Anchor Service Flow Authorization，以下简称：Anchor SFA)设备并不知道本地路由承载已经与另一下行数据承载进行了绑定，其可能会对已有的业务流进行新增通信对端的业务流修改操作，另外现有的路径操作实体，比如Serving SFA设备，其在进行路径管理操作时没有考虑本地路由的因素，也有可能会将一新建的业务流与其他业务流置于同一路径中，这些操作都会造成该本地路由承载上的数据需要发送给其它新增对端的情况。但是，本地路由承载上所承载的所有数据包都会默认路由到与其进行绑定的特定对端，而不会到达新增的目的对端。因此，特定对端会时常收到发送给新增的目的对端的数据包，而新增的目的对端总也无法收到数据包。

为此，本发明实施例提供几种技术方案，以解决该技术问题。

图2为本发明业务流修改处理方法实施例一的流程图，如图2所示，本实施例方法可以包括：

步骤201、接收修改请求消息，所述修改请求消息用于对已建立的业务流进行参数修改处理。

步骤202、若所述参数修改处理为新增目的对端，且本地路由策略为路径绑定方式的路由策略，则拒绝该修改处理。

在Bearer binding方式下，ASN中的BS或GW可直接在关联的上下行业务流之间进行数据转发，相应地，本实施例的执行主体可以采用BS中的业务流管理(Service Flow Management，以下简称：SFM)设备、GW中的服务SFA(以下简称：Serving SFA)设备或者Anchor SFA设备实现。本领域技术人员可以理解的是，具体采用哪个执行主体，取决于Bearer binding的LR策略预先下发或者预先存储在哪个主体上。

具体来说，本实施例可以包括用户设备触发参数修改和网络侧业务实体触发参数修改这两种情况。对于用户设备触发参数修改的情况来说，本实施例的执行主体可以为SFM设备或者Serving SFA设备。对于网络侧业务实体触发参数修改的情况来说，本实施例的执行主体可以为serving SFA设备或者Anchor SFA设备。本实施例中的参数修改处理可以是对已建立的业务流的业务流状态、分类规则或者业务流的业务质量(Quality of Service，以下简称：QoS)进行修改的处理。

1、用户设备触发且采用SFM设备作为执行主体

在该情况下，已采用Bearer Binding方式的LR策略可以预先下发给SFM设备，或者预先在SFM设备上建立已采用Bearer Binding方式的LR策略。该SFM设备即可直接在关联的上下行业务流之间进行数据转发。

在业务流已经建立后，用户设备可以向SFM设备发送路径修改请求消息，对已建立的业务流进行参数修改处理。

SFM设备在接收该路径修改请求消息后，可以根据该路径修改请求消息确定用户设备需要对已建立的业务流的何种参数进行修改。若SFM设备确定用户设备所请求的参数修改处理为新增目的对端的修改处理，则SFM设备可以确定用户设备需要将已建立的业务流上承载的数据发送给新增的目的对端。但是，SFM设备可以通过判断获知本地路由策略为已采用Bearer Binding方式的LR策略，则SFM设备即可确定该已建立的业务流上承载的数据只能从用户设备发送到已经绑定的特定对端，而无法发送给新增的目的对端，该新增目的对端的参数修改处理将导致已经绑定的特定对端接收到用户设备需要发送给新增的目的对端的数据。因此，SFM设备将拒绝本次修改处理。从而避免出现特定对端接收到用户设备需要发送给新增的目的对端的数据的现象。

可选地，在本实施例中，SFM设备可以向所述用户设备发送拒绝修改响应消息。可选地，该拒绝修改响应消息中可以包含拒绝原因，例如“添加异常”，从而使得用户设备可以获知SFM设备拒绝本次参数修改处理的原因。

2、用户设备触发且采用Serving SFA设备作为执行主体

在该情况下，已采用Bearer Binding方式的LR策略可以预先下发给Serving SFA设备，或者预先在Serving SFA设备上建立已采用Bearer Binding方式的LR策略，该Serving SFA设备即可直接在关联的上下行业务流之间进行数据转发。

在业务流已经建立后，用户设备可以向SFM设备发送路径修改请求消息，然后SFM设备再将该路径修改请求消息转发给Serving SFA设备。

Serving SFA设备在接收该路径修改请求消息后，可以根据该路径修改请求消息确定用户设备需要对已建立的业务流的何种参数进行修改。若ServingSFA设备确定用户设备所请求的参数修改处理为新增目的对端的修改处理且本地LR策略为已采用Bearer Binding方式的LR策略，则Serving SFA拒绝本次修改处理。从而避免出现特定对端接收到用户设备需要发送给新增的目的对端的数据的现象。

可选地，在本实施例中，Serving SFA设备可以向SFM设备发送拒绝修改响应消息，SFM设备可以向所述用户设备发送拒绝修改响应消息。可选地，该拒绝修改响应消息中可以包含拒绝原因，例如“添加异常”，从而使得用户设备可以获知Serving SFA设备拒绝本次参数修改处理的原因。

3、网络侧业务实体触发且采用Anchor SFA设备作为执行主体

在该情况下，已采用Bearer Binding方式的LR策略可以预先下发给Anchor SFA设备，或者预先在Anchor SFA设备上建立已采用Bearer Binding方式的LR策略。

网络侧业务实体，例如业务应用实体，在需要对已建立的业务流进行修改时，可以向Anchor SFA设备发送业务流修改触发消息。

Anchor SFA设备在接收该业务流修改触发消息后，可以根据该业务流修改触发消息确定网络侧业务实体需要对已建立的业务流的何种参数进行修改。若Anchor SFA设备确定网络侧业务实体所触发的参数修改处理为新增目的对端的修改处理，则Anchor SFA设备可以确定网络侧业务实体需要将已建立的业务流上承载的数据发送给新增的目的对端。但是，Anchor SFA设备可以通过判断获知本地LR策略为已采用Bearer Binding方式的LR策略，则Anchor SFA设备即可确定该已建立的业务流上承载的数据只能从用户设备发送到已经绑定的特定对端，而无法发送给新增的目的对端，该新增目的对端的参数修改处理将导致已经绑定的特定对端接收到用户设备需要发送给新增的目的对端的数据。因此，Anchor SFA设备将拒绝本次修改处理。从而避免出现特定对端接收到用户设备需要发送给新增的目的对端的数据的现象。

可选地，Anchor SFA设备还可以向Serving SFA设备发送新建业务流请求消息，以使Serving SFA设备为该新建业务流建立新的路径，从而避免使用已经绑定的路径。

4、网络侧业务实体触发且采用Serving SFA设备作为执行主体

在该情况下，已采用Bearer Binding方式的LR策略可以预先下发给Serving SFA设备，或者预先在Serving SFA设备上建立已采用Bearer Binding方式的LR策略。该Serving SFA设备即可直接在关联的上下行业务流之间进行数据转发。

在网络侧业务实体向Anchor SFA设备发送业务流修改触发消息之后，Anchor SFA设备可以向Serving SFA设备发送业务流修改请求消息。若Serving SFA设备确定Anchor SFA设备发送的业务流修改处理请求消息所需的参数修改处理为新增目的对端的修改处理，则Serving SFA设备可以确定需要将已建立的业务流上承载的数据发送给新增的目的对端。但是，Serving SFA设备通过判断可以获知本地LR策略为已采用Bearer Binding方式的LR策略，Serving SFA设备即可确定该已建立的业务流上承载的数据只能从用户设备发送到已经绑定的特定对端，而无法发送给新增的目的对端，该新增目的对端的参数修改处理将导致已经绑定的特定对端接收到用户设备需要发送给新增的目的对端的数据。因此，Serving SFA设备将拒绝本次修改处理，从而避免出现特定对端接收到用户设备需要发送给新增的目的对端的数据的现象。该拒绝修改处理可以为向Anchor SFA设备发送拒绝修改响应消息。可选地，在拒绝该修改处理之后，Anchor SFA设备还可以向Serving SFA设备发送新建业务流请求消息。

具体来说，Anchor SFA设备在收到网络侧业务实体的触发消息后，可以向Serving SFA设备下发业务流修改请求消息，该Serving SFA设备可以将业务流修改请求消息中的Reservation Action设置为modify；Serving SFA设备根据LR策略拒绝后，Anchor SFA设备可以重新发起新建业务流请求消息，并将其中的Reservation Action设置为create，从而使得Serving SFA设备可以新建路径，而不是修改已有业务流参数。

对于上述几种方式来说，若SFM设备、Serving SFA设备或者Anchor SFA设备确定本次参数修改处理是对已建立的业务流的其它参数进行修改，则SFM设备、Serving SFA设备或者Anchor SFA设备可以采用现有技术对已建立的业务流的相应参数进行修改，此处不再赘述。

本实施例中，SFM设备、Serving SFA设备或者Anchor SFA设备在接收到修改请求消息后，如果确定该修改请求消息是要对已建立的业务流新增目的对端的修改处理，则SFM设备、Serving SFA设备或者Anchor SFA设备可以拒绝本次修改处理，从而避免在Bearer Binding方式下，将需要发送给新增的目的对端的数据总发送到已经绑定的特定目的对端的现象。

图3为本发明业务流修改处理方法实施例二的信令流程图，如图3所示，本实施例的方法对用户设备触发且采用Serving SFA设备作为执行主体的方案进行详细说明，本实施例的方法可以包括：

步骤301、用户设备向SFM设备发送路径修改请求消息。

举例来说，用户设备可以通过向SFM设备发送DSC_Req消息，发起对已建立的业务流的参数修改处理。具体地，该参数修改处理为新增目的对端的参数修改处理。

步骤302、SFM设备向Serving SFA设备发送路径修改请求消息。

SFM设备在接收该DSC请求消息后，可以向Serving SFA设备发送Path_Mod_Req消息，该Path_Mod_Req消息中可以包含已建立的业务流信息以及绑定的数据路径信息。

需要说明的是，若SFM设备在该业务流建立时，也已经获知BearerBinding方式的LR策略，则SFM设备也可以直接向用户设备发送路径修改响应消息，拒绝本次新增目的对端的参数修改处理，而不再执行本实施例的后续操作。

步骤303、Serving SFA设备应用LR策略，拒绝本次参数修改处理。

Serving SFA设备在接收该Path_Mod_Req消息后，可以判断本地LR策略为已采用Bearer Binding方式的LR策略，因此，Serving SFA设备拒绝本次参数修改处理。

步骤304、Serving SFA设备向SFM设备发送拒绝修改响应消息。

Serving SFA设备可以向SFM设备发送Path_Mod_Rsp消息，该Path_Mod_Rsp消息中可以包含已建立的业务流信息以及绑定的数据路径信息。该Path_Mod_Rsp消息中也可以包含拒绝原因。

步骤305、SFM设备向用户设备发送拒绝修改响应消息。

SFM设备在接收Path_Mod_Rsp消息后，可以向用户设备发送DSC_Rsp消息，该DSC_Rsp消息中也可以包含拒绝原因。

本实施例中，Serving SFA设备可以在接收到路径修改请求消息后，若判断本地LR策略为已采用Bearer Binding方式的LR策略，则拒绝本次参数修改处理，从而避免在Bearer Binding方式下，将需要发送给新增的目的对端的数据总发送到已经绑定的特定目的对端的现象。

在图2和图3所示的方法实施例的基础上，本发明实施例在对已建立的业务流进行参数修改处理之前，可以包括：LR策略的下发操作以及业务流建立的初始化操作。

对于LR策略的下发来说，其可以由网络侧业务实体向Anchor SFA设备下发，该网络侧业务实体可以为认证、授权与计费(Authentication，Authorization and Accounting，以下简称：AAA)服务器或者策略计费规则实体(Policy and Charging Rules Function，以下简称：PCRF)。

1、由AAA服务器下发

在用户设备入网时，ASN GW中的Anchor SFA设备可以向AAA服务器发送接入请求Access-Request消息，该消息中包含ASN支持LR能力信息。在具体实现时，Anchor SFA设备可以在Access-Request消息中的WiMAX-Capability中增加支持LR指示LR support indication，其长度为8bit，这8bit的值可以有以下两种划分形式：

1)1bit用于表示是否支持LR(取值yes或者no)，其余7bit预留；

2)3bit：其中1bit用于表示是否支持LR(取值yes或者no)，当支持LR时，用2bit分别取值1，用于指示LR绑定方式为bearer binding或IPbinding，其余5bit预留。

AAA服务器在收到Anchor SFA设备上报的能力之后，决定是否下发LR策略给Anchor SFA设备，如下发，则AAA服务器在返回的准入消息Access-Accept中携带相应的LR策略LR Policy。其长度也为8bit，这8bit的值中，1bit用于表示是否支持LR(取值yes或者no)，当支持LR时，2bit指示LR绑定方式为bearer binding或IP binding)，其余5bit预留。

2、由PCRF下发

在用户设备入网时，ASN GW中的策略计费执行实体(Policy andCharging Enforcement Function，以下简称：PCEF)可以向PCRF发送接入请求Access-Request消息，该消息中包含ASN支持LR能力信息。该PCEF与Anchor SFA设备位于同一GW中。

在具体实现时，PCEF可以在Access-Request中的PCC Capability AVP中增加支持LR的指示LR-support-indication。该LR-support-indication的8bit分配与上述WiMAX-Capability中增加的LR-support-indication的8bit分配类似，此处不再赘述。

PCRF在收到PCEF上报的LR能力之后，决定是否下发LR策略给PCEF，如下发，则PCRF在返回的准入消息Access-Accept中携带相应的LR策略，通过Charging-Rule-Definition AVP体现。

Charging-Rule-Definition::＝<AVP Header：402>

                        [Local-Routing-Policy-Descriptor]

LR Policy的长度为8bit，其中，1bit用于表示是否支持LR(取值yes或者no)，当支持LR时，2bit指示LR绑定方式为bearer binding或IP binding，其余5bit预留。

由上述描述可知，Anchor SFA设备可以获知或者通过与其处于同一GW中的PCEF获知LR策略，以便后续根据该LR策略进行相应的操作。

在Anchor SFA设备获知LR策略后，即可进行业务流建立的初始化操作。在本实施例中，该业务流建立的初始化操作可以包括网络侧业务实体触发业务流建立的情况和用户设备触发业务流建立的情况。下面分别对这两种情况进行详细说明。

图4为本发明业务流修改处理方法实施例三的信令流程图，如图4所示，本实施例的方法中，业务流建立的初始化操作由网络侧业务实体触发，具体来说，本实施例的方法可以包括：

步骤401、Anchor SFA设备收到网络侧业务实体发送的业务流建立触发消息。

网络侧的AAA服务器或者PCRF可以向Anchor SFA设备发送业务流建立触发消息。

步骤402、Anchor SFA设备向Serving SFA设备发送业务流建立请求消息。

Anchor SFA设备可以向Serving SFA设备发送RR_Req消息，该RR_Req消息中可以包含业务流信息，且该业务流信息中可以包含之前网络侧业务实体下发的LR策略指示，该LR策略指示该新建的业务流支持LR，且其所采用的绑定方式是Bearer Binding的方式。

步骤403、Serving SFA设备向SFM设备发送路径注册请求消息。

Serving SFA设备在接收到Anchor SFA设备发送的RR_Req消息后，可以根据该消息中包含的LR策略获知新建立的业务流支持LR，且其采用的是Bearer Binding的方式。

然后，Serving SFA设备可以向SFM设备发送Path_Reg_Req消息，为该新建业务流建立新的路径，并可以对该新建的业务流加以标识，方便后续路径管理，使得该路径标识只唯一用于该业务流。

可选地，Serving SFA设备在Path_Reg_Req消息中也可以包含该LR策略，从而将该LR策略中继指示至SFM设备，其过程中还可以经过其它网关中继。

步骤404、SFM设备向用户设备发送业务流建立请求消息。

SFM设备在接收该Path_Reg_Req消息后，即可向用户设备发送DSA_Req消息，从而建立于用户设备之间的业务互通。

可选地，SFM设备在DSA请求消息中也可以包含该LR策略，从而将该LR策略中继指示至用户设备，从而使得用户设备可以获知该业务流是采用Bearer Binding方式绑定的，而不会出现图2和图3所示的方法实施例中用户设备在已经采用Bearer Binding方式绑定的业务流中增加目的对端的现象。

需要说明的是，本实施例仅示出了几个主要的交互消息，本领域技术人员可以理解的是，在这些消息的基础上，该交互过程还可以包括其它消息，例如与上述各请求消息的对应的响应消息等。

由上述描述可知，Anchor SFA设备可以将网络侧业务实体下发的LR策略中继给Serving SFA设备和SFM设备，这也即是图2和图3所示的方法中，Anchor SFA设备、Serving SFA设备或者SFM设备均可以作为执行主体的原因。

本实施例中，Anchor SFA设备在网络侧业务实体触发建立业务流时，可以根据LR策略建立LR承载，并且在为该业务流建立LR承载的过程中，还可以明确指示Serving SFA设备、SFM设备以及用户设备该业务流采用BearerBinding方式绑定，从而便于后续对用户设备或者网络侧业务实体针对该业务流增加目的对端的操作。

图5为本发明业务流修改处理方法实施例四的信令流程图，如图5所示，本实施例的方法中，业务流建立的初始化操作由用户设备触发，具体来说，本实施例的方法可以包括：

步骤501、用户设备向SFM设备发送业务流建立请求消息。

用户设备可以向SFM设备发送DSA_Req消息，以请求SFM设备新建业务流。

步骤502、SFM设备向Serving SFA设备发送路径注册请求消息。

SFM设备可以向Serving SFA设备发送Path_Reg_Req消息，以为该新建的业务流建立新的路径。该Path_Reg_Req消息中可以包含新建的业务流信息和数据路径信息。

步骤503、Serving SFA设备向Anchor SFA设备发送业务流建立请求消息。

Serving SFA设备在接收该Path_Reg_Req消息后，可以向Anchor SFA设备发送RR_Req消息。该RR_Req消息中可以包含业务流信息。

步骤504、Anchor SFA设备向Serving SFA设备发送业务流建立响应消息。

Anchor SFA设备在接收该RR_Req消息后，即可根据LR策略向ServingSFA设备发送RR_Rsp消息，该RR_Rsp消息中包含新建的业务流信息。具体地，Anchor SFA设备可以将LR策略包含在RR_Rsp消息中，该LR策略即可以指示该新建的业务流支持LR，且其所采用的绑定方式是Bearer Binding的方式。

步骤505、Serving SFA设备向SFM设备发送路径注册响应消息。

Serving SFA设备在接收到Anchor SFA设备发送的RR_Rsp消息后，可以根据该消息中包含的LR策略获知新建立的业务流支持LR，且其采用的是Bearer Binding的方式。

Serving SFA设备在接收该RR_Rsp消息后，即可向SFM设备发送Path_Reg_Rsp消息，为该新建业务流建立新的路径，并可以对该新建的业务流加以标识，方便后续路径管理，使得该路径标识只唯一用于该业务流。该Path_Reg_Rsp消息可以包含新建的业务流信息和数据路径信息。

可选地，Serving SFA设备在Path_Reg_Rsp消息中也可以包含该LR策略，从而将该LR策略中继指示至SFM设备，其过程中还可以经过其它网关中继。

步骤506、SFM设备向用户设备发送业务流建立响应消息。

SFM设备可以向用户设备发送DSA_Rsp消息，以指示用户设备业务流已建立。

可选地，SFM设备在DSA_Rsp消息中也可以包含该LR策略，从而将该LR策略中继指示至用户设备，从而使得用户设备可以获知该业务流是采用Bearer Binding方式绑定的，而不会出现图2和图3所示的方法实施例中用户设备在已经采用Bearer Binding方式绑定的业务流中增加目的对端的现象。

由上述描述可知，Anchor SFA设备可以将网络侧业务实体下发的LR策略中继给Serving SFA设备和SFM设备，这也即是图2和图3所示的方法中，Anchor SFA设备、Serving SFA设备或者SFM设备均可以作为执行主体的原因。

本实施例中，Anchor SFA设备在用户设备侧触发建立业务流时，可以根据LR策略建立LR承载，并且在为该业务流建立LR承载的过程中，还可以明确指示Serving SFA设备、SFM设备以及用户设备该业务流采用BearerBinding方式绑定，从而便于后续对用户设备或者网络侧业务实体针对该业务流增加目的对端的操作。

图6为本发明业务流修改处理方法实施例五的信令流程图，如图6所示，本实施例中业务流修改的初始化操作由网络侧触发，且LR策略由ServingSFA执行，具体来说，本实施例的方法可以包括：

步骤601、网络侧业务实体向Anchor SFA设备发送业务流修改触发消息。

网络侧的AAA服务器或者PCRF可以向Anchor SFA设备发送业务流修改触发消息。该业务流修改触发消息触发的参数修改处理为新增目的对端的修改处理。

步骤602、Anchor SFA设备向Serving SFA设备发送业务流修改请求消息。

Anchor SFA设备向Serving SFA设备发送的业务流修改请求消息可以请求Serving SFA设备进行新增目的对端的修改处理。

举例来说，Anchor SFA设备可以向Serving SFA设备发送RR-REQ消息，该消息中的Reservation Action被设置为modify。

步骤603、Serving SFA设备判断本地LR策略为已采用Bearer Binding的LR策略，则向Anchor SFA设备发送拒绝修改响应消息。

Serving SFA设备在接收该业务流修改请求消息后，可以获知Anchor SFA设备需要进行新增目的对端的修改处理，而Serving SFA设备可以通过判断本地存储的LR策略获知该业务流已经被路径绑定，不能对该路径绑定的业务流进行参数修改处理，因此，Serving SFA设备拒绝本次修改处理，例如向Anchor SFA设备发送拒绝修改响应消息。

步骤604、Anchor SFA设备向Serving SFA设备发送新建业务流请求消息。

Anchor SFA设备在接收该拒绝修改响应消息后，可以获知Serving SFA设备拒绝对路径绑定的业务流进行修改，因此，Anchor SFA设备可以向Serving SFA设备发送新建业务流请求消息RR-REQ，该RR-REQ。中的Reservation Action设置为create，从而使得Serving SFA设备可以为该新建业务流建立新的路径，而不是修改已有业务流参数。

本实施例中，Serving SFA设备在网络侧触发修改业务流时，可以通过判断本地LR策略获知该业务流已经被路径绑定，因此，Serving SFA设备拒绝对已路径绑定的业务流进行参数修改，并将拒绝的结果反馈给Anchor SFA设备，使得Anchor SFA设备可以在接收拒绝结果后，向Serving SFA设备发送新建业务流的请求消息，从而使得Serving SFA设备不会修改已有路径中的已存业务流参数，而是按照新建业务流为该新建的业务流建立新的路径。

图7为本发明业务流修改处理装置实施例一的结构示意图，如图7所示，本实施例的装置可以包括：接收模块11和处理模块12，其中接收模块11用于接收修改请求消息，所述修改请求消息用于对已建立的业务流进行参数修改处理；处理模块12用于若所述参数修改处理为新增目的对端且本地路由策略为已采用路径绑定方式的路由策略，则拒绝该修改处理。

本实施例的装置可以为BS中的SFM设备，也可以是ASN GW中的Serving SFA设备或者Anchor SFA设备。

本实施例的装置可以用于执行图2所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图8为本发明业务流修改处理装置实施例二的结构示意图，如图8所示，本实施例的装置在图7所示装置的基础上，进一步地，接收模块11包括第一接收单元111，处理模块12包括第一处理单元121，其中，第一接收单元111用于接收网络侧业务实体发送的业务流修改触发消息；第一处理单元121用于向Serving SFA设备发送新建业务流请求消息，以使所述Serving SFA设备为该新建业务流建立新的路径。

本实施例的装置可以为Anchor SFA设备，其应用于网络侧业务实体触发参数修改的场景，其实现原理与上述图2所示方法实施例的实现原理和效果类似，此处不再赘述。

图9为本发明业务流修改处理装置实施例三的结构示意图，如图9所示，本实施例的装置在图7所示装置的基础上，进一步地，接收模块11包括第二接收单元112，处理模块12包括第二处理单元122，其中，第二接收单元112用于接收用户设备发送的路径修改请求消息；第二处理单元122用于向所述用户设备发送拒绝修改响应消息。

本实施例的装置可以为SFM设备，其应用于用户设备触发参数修改的场景，其实现原理与上述图2所示方法实施例的实现原理和效果类似，此处不再赘述。

图10为本发明业务流修改处理装置实施例四的结构示意图，如图10所示，本实施例的装置在图7所示装置的基础上，进一步地，接收模块11包括第三接收单元113，处理模块12包括第三处理单元123，其中，第三接收单元113用于接收用户设备发送且由SFM设备转发的所述路径修改请求消息；第三处理单元123用于向所述SFM设备发送拒绝修改响应消息，以使所述SFM设备将所述拒绝修改响应消息发送给所述用户设备。

本实施例的装置可以为Serving SFA设备，其应用于用户设备触发参数修改的场景，其实现原理与上述图2所示方法实施例的实现原理和效果类似，此处不再赘述。

本发明业务流修改处理装置实施例五可以采用图7或者图8所示的结构，其中，接收模块11还用于接收网络侧业务实体发送的业务流建立触发消息；处理模块12还用于向Serving SFA设备发送业务流建立请求消息，以使所述Serving SFA设备向SFM设备发送用于指示SFM设备新建路径的路径注册请求消息，所述业务流建立请求消息中包含业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息。

本实施例的装置可以为Anchor SFA设备，其可以用于执行图4所示方法实施例的方法，其实现原理和技术效果类似，此处不再赘述。

本发明业务流修改处理装置实施例六也可以采用图7或者图8所示的结构，其中，接收模块11还用于接收Serving SFA设备在接收SFM设备发送的路径注册请求消息之后发送的业务流建立请求消息；处理模块12还用于向所述Serving SFA设备发送业务流建立响应消息，以使所述Serving SFA设备向所述SFM发送路径注册响应消息，所述业务流建立响应消息中包含业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息。

本实施例的装置可以为Anchor SFA设备，其可以用于执行图5所示方法实施例的方法，其实现原理和技术效果类似，此处不再赘述。

图11为本发明业务流修改处理系统实施例的结构示意图，如图11所示，本实施例的系统可以包括：Serving SFA设备1和Anchor SFA设备2，其中，Anchor SFA设备2用于向Serving SFA设备1发送业务流修改请求消息，所述业务流修改消息用于对已建立的业务流进行参数修改处理；接收ServingSFA设备1根据所述业务流修改请求消息发送的拒绝修改响应消息，并向Serving SFA设备1发送新建业务流请求消息；Serving SFA设备1，用于接收Anchor SFA设备2发送的业务流修改请求消息，若本地路由策略为已采用路径绑定方式的路由策略，则向Anchor SFA设备2发送拒绝修改响应消息，接收Anchor SFA设备2发送的所述新建业务流请求消息。

本实施例的系统可以用于执行图6所示方法实施例的方法，其实现原理和技术效果类似，此处不再赘述。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (19)

1.一种业务流修改处理方法，其特征在于，所述方法的执行主体为路径承载的本地路由策略预先下发或者预先存储的主体，所述方法包括：

接收修改请求消息，所述修改请求消息用于对已建立的业务流进行参数修改处理；

若所述参数修改处理为新增目的对端，且本地路由策略为路径绑定方式的路由策略，则拒绝该修改处理。

2.根据权利要求1所述的方法，其特征在于，所述接收修改请求消息，包括：

锚点业务流授权设备接收网络侧业务实体发送的业务流修改触发消息；

所述拒绝该修改处理，包括：

所述锚点业务流授权设备向服务业务流授权设备发送新建业务流请求消息，以使所述服务业务流授权设备为该新建业务流建立新的路径。

3.根据权利要求1所述的方法，其特征在于，所述接收修改请求消息，包括：

服务业务流授权设备接收锚点业务流授权设备发送的业务流修改请求消息；

所述拒绝该修改处理，包括：

所述服务业务流授权设备向所述锚点业务流授权设备发送拒绝修改响应消息；

所述拒绝该修改处理之后，还包括：

所述服务业务流授权设备接收所述锚点业务流授权设备发送的新建业务流请求消息。

4.根据权利要求1所述的方法，其特征在于，所述接收修改请求消息，包括：

业务流管理设备接收用户设备发送的路径修改请求消息；

所述拒绝该修改处理，包括：

所述业务流管理设备向所述用户设备发送拒绝修改响应消息。

5.根据权利要求1所述的方法，其特征在于，所述接收修改请求消息，包括：

服务业务流授权设备接收用户设备发送且由业务流管理设备转发的路径修改请求消息；

所述拒绝该修改处理，包括：

所述服务业务流授权设备向所述业务流管理设备发送拒绝修改响应消息，以使所述业务流管理设备将所述拒绝修改响应消息发送给所述用户设备。

6.根据权利要求1所述的方法，其特征在于，所述接收修改请求消息包括：

锚点业务流授权设备接收所述修改请求消息；

所述接收修改请求消息之前，还包括：

锚点业务流授权设备接收网络侧业务实体发送的业务流建立触发消息；

所述锚点业务流授权设备向服务业务流授权设备发送业务流建立请求消息，以使所述服务业务流授权设备向业务流管理设备发送用于指示业务流管理设备新建路径的路径注册请求消息，所述业务流建立请求消息中包含业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息。

7.根据权利要求6所述的方法，其特征在于，所述路径注册请求消息中包含业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息。

8.根据权利要求1所述的方法，其特征在于，所述接收修改请求消息包括：

锚点业务流授权设备接收所述修改请求消息；

所述接收修改请求消息之前，还包括：

锚点业务流授权设备接收服务业务流授权设备在接收业务流管理设备发送的路径注册请求消息之后发送的业务流建立请求消息；

所述锚点业务流授权设备向所述服务业务流授权设备发送业务流建立响应消息，以使所述服务业务流授权设备向所述业务流管理设备发送路径注册响应消息，所述业务流建立响应消息中包含业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息。

9.根据权利要求8所述的方法，其特征在于，所述路径注册响应消息中包含业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息。

10.根据权利要求8或9所述的方法，其特征在于，还包括：

所述业务流管理设备将所述业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息发送给用户设备。

11.根据权利要求8或9所述的方法，其特征在于，接收业务流建立请求消息之前，还包括：

锚点业务流授权设备向网络侧业务实体发送接入请求消息，所述接入请求消息中包含支持本地路由能力信息；

所述锚点业务流授权设备接收所述网络侧业务实体发送的接入允许消息，所述业务接入允许消息中包含业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息。

12.根据权利要求11所述的方法，其特征在于，所述网络侧业务实体，包括：AAA服务器或者PCRF。

13.一种业务流修改处理装置，其特征在于，所述装置为路径承载的本地路由策略预先下发或者预先存储的主体，所述装置包括：

接收模块，用于接收修改请求消息，所述修改请求消息用于对已建立的业务流进行参数修改处理；

处理模块，用于若所述参数修改处理为新增目的对端，且本地路由策略为路径绑定方式的路由策略，则拒绝该修改处理。

14.根据权利要求13所述的装置，其特征在于，所述接收模块包括第一接收单元，所述处理模块包括第一处理单元，

所述第一接收单元，用于接收网络侧业务实体发送的业务流修改触发消息；

所述第一处理单元，用于向服务业务流授权设备发送新建业务流请求消息，以使所述服务业务流授权设备为该新建业务流建立新的路径。

15.根据权利要求13所述的装置，其特征在于，所述接收模块包括第二接收单元，所述处理模块包括第二处理单元，

所述第二接收单元，用于接收用户设备发送的路径修改请求消息；

所述第二处理单元，用于向所述用户设备发送拒绝修改响应消息。

16.根据权利要求13所述的装置，其特征在于，所述接收模块包括第三接收单元，所述处理模块包括第三处理单元，

所述第三接收单元，用于接收用户设备发送且由业务流管理设备转发的路径修改请求消息；

所述第三处理单元，用于向所述业务流管理设备发送拒绝修改响应消息，以使所述业务流管理设备将所述拒绝修改响应消息发送给所述用户设备。

17.根据权利要求13或14所述的装置，其特征在于，

所述接收模块，还用于接收网络侧业务实体发送的业务流建立触发消息；

所述处理模块，还用于向服务业务流授权设备发送业务流建立请求消息，以使所述服务业务流授权设备向业务流管理设备发送用于指示业务流管理设备新建路径的路径注册请求消息，所述业务流建立请求消息中包含业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息。

18.根据权利要求13或14所述的装置，其特征在于，

所述接收模块，还用于接收服务业务流授权设备在接收业务流管理设备发送的路径注册请求消息之后发送的业务流建立请求消息；

所述处理模块，还用于向所述服务业务流授权设备发送业务流建立响应消息，以使所述服务业务流授权设备向所述业务流管理设备发送路径注册响应消息，所述业务流建立响应消息中包含业务流支持本地路由且采用路径绑定方式的本地路由策略的指示信息。

19.一种业务流修改处理系统，其特征在于，包括：服务业务流授权设备和锚点业务流授权设备，

所述锚点业务流授权设备，用于向所述服务业务流授权设备发送业务流修改请求消息，所述业务流修改消息用于对已建立的业务流进行参数修改处理；接收所述服务业务流授权设备根据所述业务流修改请求消息发送的拒绝修改响应消息，并向所述服务业务流授权设备发送新建业务流请求消息；

所述服务业务流授权设备，用于接收所述锚点业务流授权设备发送的业务流修改请求消息，若本地路由策略为路径绑定方式的路由策略，则向所述锚点业务流授权设备发送拒绝修改响应消息，接收所述锚点业务流授权设备发送的所述新建业务流请求消息。