CN101808331B - 动态业务流的处理方法及基站 - Google Patents

Abstract

本发明提供一种动态业务流的处理方法及基站，其中方法包括：接收第一动态业务流请求消息；根据第一动态业务流请求消息建立、删除或修改业务的第一动态业务流；接收第二动态业务流请求消息；根据第二动态业务流请求消息建立、删除或修改业务的第二动态业务流；如果建立第二动态业务流失败，则回收为第一动态业务流分配的资源；如果删除第二动态业务流失败，则回收为第二动态业务流分配的资源；如果修改第二动态业务流失败，则回收为第一动态业务流分配的附加资源。本发明实施例提供的方法及基站，在一条动态业务流处理操作成功而另外一条动态业务流处理操作失败的情况下，避免始终保留分配给其中一条动态业务流的资源，从而避免了资源的浪费。

Description

动态业务流的处理方法及基站

技术领域

本发明实施例涉及通信技术领域，尤其涉及一种动态业务流的处理方法及基站。 

背景技术

微波存取全球互通(Worldwide Interoperability for Microwave Access，简称WiMAX)，又称802.16无线城域网，是一种为企业和家庭用户提供“最后一英里”的宽带无线连接方案。 

WiMAX802.16系列协议详细阐述了空口业务流建立或删除过程，结合网络工作组(Network Working Group，简称NWG)的网络侧协议，对初始业务流和预置业务流的建立，形成了比较完整的端到端的解决方案。初始业务流和预置业务流是在移动台(Mobile Station，简称MS)入网完成后需要马上建立的，而且必须建立成功。初始业务流和预置业务流的建立由网络侧发起，建立后不会被删除。初始业务流和预置业务流是MS入网后开展基本业务的保证。 

由于初始业务流和预置业务流会长期占用资源，不能实现资源的动态共享，由于资源是非常有限的，初始业务流和预置业务流在带宽设置、服务优先级以及质量上只是能满足业务基本功能要求。 

动态业务流可以克服初始业务流和预置业务流的上述不足，动态业务流技术在业务数据流传输时动态建立，业务数据流传输结束时动态删除，将有限的资源根据业务需要进行动态分配和共享。通过动态业务流技术，可以能够灵活共享和分配资源，提高带宽利用率。 

动态业务流建立过程与初始业务流和预置业务流相似，都遵循 WiMAX802.16和NWG协议的要求。动态业务流的建立可以由MS发起，也可以由网络侧发起。 

在实际应用中，很多动态业务流是成对建立的，也就是说只有在上行动态业务流和下行动态业务流都建立成功的情况下，MS才能顺利开展业务。例如，对于打电话这种业务来说，就是需要上行和下行动态业务流都建立成功才能保证双方的通话正常。 

由MS发起的建立上行业务流的过程如下：MS发送动态业务流建立请求消息(DSA_REQ)给基站(Base Station，简称BS)，BS查询是否有空闲的资源，如果有，则BS发送数据通道建立请求消息(PATH_REG_REQ)给网关(Gateway，简称GW)，GW分配一个业务流标识(Service Flue Identification，简称SFID)给MS当前请求建立的动态业务流，发送数据通道建立响应消息(PATH_REG_RSP)给BS，该响应中携带SFID。BS接收到该响应后，发送动态业务流建立响应消息(DSA_RSP)。MS收到动态业务流建立响应消息(DSA_RSP)之后，发送动态业务流建立确认消息(DSA_ACK)给BS，BS发送数据通道建立确认消息(PATH_REG_ACK)给GW，完成上行业务流的建立。 

MS发起的建立下行业务流的过程与上述过程类似。 

发明人发现现有技术中至少存在如下问题： 

每一个动态业务流建立，BS都需要为该动态业务流分配资源。对于需要成对建立以保证业务正常进行的两个动态业务流，在建立、删除或修改一条动态业务流之后，如果另一条动态业务流的建立、删除或修改失败，那么BS不会为另一条动态业务流分配资源或者删除另一条动态业务流已有的资源，而之前已经建立或修改的一条动态业务流仍然在占用资源，并且仅靠这一条单独存在动态业务流也不能保证业务的正常进行。可见，如果采用现有的动态业务流建立、删除或修改的方法，对于需要成对建立以保证业务正常进行的动态业务流，会造成资源的浪费。 

发明内容

本发明实施例提供一种动态业务流的处理方法及基站，用以克服现有技术中动态业务流的处理方法导致资源浪费的缺陷。 

本发明实施例提供了一种动态业务流的处理方法，包括： 

接收第一动态业务流请求消息； 

根据所述第一动态业务流请求消息建立、删除或修改业务的第一动态业务流； 

接收第二动态业务流请求消息； 

根据所述第二动态业务流请求消息建立、删除或修改所述业务的第二动态业务流；如果建立第二动态业务流失败，则回收为第一动态业务流分配的资源；如果删除第二动态业务流失败，则回收为第二动态业务流分配的资源；如果修改第二动态业务流失败，则回收为所述第一动态业务流分配的附加资源； 

其中，所述接收第二动态业务流请求消息之后，所述根据所述第二动态业务流请求消息建立、删除或修改所述业务的第二动态业务流之前，所述方法还包括： 

确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流。 

本发明实施例还提供了一种基站，包括： 

第一接收模块，用于接收第一动态业务流请求消息； 

第一处理模块，用于根据所述第一动态业务流请求消息建立、删除或修改业务的第一动态业务流； 

第二接收模块，用于接收第二动态业务流请求消息； 

第二处理模块，用于根据所述第二动态业务流请求消息建立、删除或修改所述业务的第二动态业务流； 

第三处理模块，用于在所述第二处理模块建立第二动态业务流失败的情况下，回收为第一动态业务流分配的资源；在所述第二处理模块删除第二动态业务流失败的情况下，回收分配给第二动态业务流的资源；在所述第二处理模块修改第二动态业务流失败的情况下，回收为所述第一动态业务流分配的附加资源； 

确定模块，用于确定所述第一动态业务流与所述第二动态业务流请求消 息涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流。 

本发明实施例提供的动态业务流的处理方法及基站，如果建立第二动态业务流失败，则回收为第一动态业务流分配的资源；如果删除第二动态业务流失败，则回收分配给第二动态业务流的资源；如果修改第二动态业务流失败，则回收为所述第一动态业务流分配的附加资源；而不是如同现有技术那样，一条动态业务流处理操作成功而另外一条动态业务流处理操作失败的情况下，始终保留分配给其中一条动态业务流的资源；避免了资源的浪费。 

附图说明

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

图1所示为本发明动态业务流的处理方法实施例一的流程图； 

图2所示为本发明动态业务流的处理方法实施例二的信令交互图； 

图3所示为本发明动态业务流的处理方法实施例三的信令交互图； 

图4所示为本发明动态业务流的处理方法实施例四的信令交互图； 

图5所示为本发明动态业务流的处理方法实施例五的信令交互图； 

图6所示为本发明动态业务流的处理方法实施例六的信令交互图； 

图7所示为本发明动态业务流的处理方法实施例七的信令交互图； 

图8所示为本发明基站实施例一的结构示意图； 

图9所示为本发明基站实施例二的结构示意图； 

图10所示为本发明基站实施例三的结构示意图。 

具体实施方式

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

如图1所示为本发明动态业务流的处理方法实施例一的流程图，包括： 

步骤101、接收第一动态业务流请求消息。 

步骤102、根据第一动态业务流请求消息建立、删除或修改业务的第一动态业务流。 

步骤103、接收第二动态业务流请求消息。 

步骤104、根据第二动态业务流请求消息建立、删除或修改业务的第二动态业务流；如果建立第二动态业务流失败，则回收为第一动态业务流分配的资源；如果删除第二动态业务流失败，则回收分配给第二动态业务流的资源；如果修改第二动态业务流失败，则回收为第一动态业务流分配的附加资源。 

本发明各实施例中涉及到的资源包括R1口资源和R6口资源，R1是BS和MS之间的空中接口，R1口即BS和MS之间进行通信需要用到的资源，R6口是BS和GW之间的空中接口，R6口资源即BS和GW之间进行通信需要用到的资源。 

上述步骤101-104，可以由BS来执行。 

上述步骤103中，接收第二动态业务流请求消息之后可以进一步包括：确定第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与业务相关的上行业务流和下行业务流。 

确定第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与业务相关的上行业务流和下行业务流的方式大致可以如下： 

(1)根据第一动态业务流请求消息和第二动态业务流请求消息中的请求参数信息，判断第一动态业务流与第二动态业务流请求消息所涉及的第二动态业务流是否是与同一业务相关的上行业务流和下行业务流。 

请求参数信息是第一动态业务流请求消息和第二动态业务流请求消息中包含的各种参数的信息，可以包括调度类型、业务流方向类型和业务质量(Quality of Service，简称QOS)参数。例如，调度类型可以包括尽力而为业务(Best Efforts，简称BE)、非实时轮询业务(Not Real-Time Polling Service，简称nrtPS)、实时轮询业务(Real-Time Polling Service，简称rtPS)、非请求的带宽分配业务(Unsolicited Grant Service，简称UGS)等。业务流方向可以包括上行和下行。QOS是指网络提供更高优先服务的一种能力，包括专用带宽、抖动控制和延迟等指标。 

具体地，如果第一动态业务流请求消息中的调度类型与第二动态业务流请求消息中的调度类型相同，则可以确定第一动态业务流与第二动态业务流请求消息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流。 

有的业务涉及到两个以上的具有相同调度类型的动态业务流，即使第一动态业务流和第二动态业务流具有相同的调度类型，第一动态业务流和第二动态业务流也不是成对的上行业务流和下行业务流。这时根据调度类型是否相同无法准确确定第一动态业务流与第二动态业务流请求消息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流。这种情况下，可以进一步判断第一动态业务流请求消息和第二动态业务流请求中的业务流方向，如果第一动态业务流请求消息和第二动态业务流请求消息中具有相对应的业务流方向，那么可以确定第一动态业务流与第二动态业务流请求消息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流。 

另外，也可以根据第一动态业务流请求消息和第二动态业务流请求消息中的QOS参数来确定第一动态业务流与第二动态业务流请求消息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流。例如，对于电话业务，成对的两个动态业务流具有相同的QOS参数，如果两个动态业务流的QOS参数相同，则可以确定这两个动态业务流是成对的两个动态业务 流。 

在判断第一动态业务流与第二动态业务流请求消息所涉及的第二动态业务流是否是与同一业务相关的上行业务流和下行业务流时，可以综合根据调度类型、业务流方向类型和QOS参数来判断，也可以单独根据调度类型、业务流方向类型或者QOS参数来判断。 

为了更准确地确定第一动态业务流与第二动态业务流请求消息所涉及的第二动态业务流是否是与同一业务相关的上行业务流和下行业务流，还可以根据请求参数信息中的分类器中的五元组信息。该五元组信息具体可以包括分类器中的五元组信息包括源互联网协议(Internet Protocol，简称IP)地址、目的IP地址、协议号、源端口号和目的端口号。 

具体地，如果第一动态业务流请求消息中的源IP地址与第二动态业务流请求消息中的目的IP地址相同，第一动态业务流请求消息中的目的IP地址与第二动态业务流请求消息中的源IP地址相同，第一动态业务流请求消息中的源端口号和第二动态业务流请求消息中的目的端口号相同，第一动态业务流请求消息中的目的端口号和第二动态业务流请求消息中的源端口号相同，且第一动态业务流请求消息中端口与第二动态业务流请求消息中的协议号相同，则可以确定第一动态业务流与第二动态业务流请求消息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流。 

(2)根据GW为第一动态业务流分配的第一SFID和为第二动态业务流分配的第二SFID，判断第一动态业务流与第二动态业务流请求消息所涉及的第二动态业务流是否是与同一业务相关的上行业务流和下行业务流。 

根据802.16协议规定的流程，GW会为每个动态业务流分配一个SFID。现有技术中，GW为动态业务流分配的SFID只是为了保证可以在网络中唯一标识一个SFID，但是根据GW分配的SFID并不能确定各个动态业务流之间的上下行成对关系。 

为了能够让BS根据业务流的SFID确定各个动态业务流之间的上下行成 对关系，本发明实施例中，BS和GW可以预先协商好策略，通过预先协商好的策略，BS可以判断哪两个SFID对应的业务流是与同一个业务相关的上行业务流和下行业务流。例如，BS和GW可以预先协商：SFID的末尾数字相同的两个SFID对应的业务流是与同一个业务相关上行业务流和下行业务流。 

具体地，BS可以基于预先与GW协商好的策略，判断GW为第一动态业务流分配的第一SFID和第二动态业务流分配的第二SFID是否与同一业务相关，从而判断所述第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是否是与同一业务相关的上行业务流和下行业务流。 

或者，为了能够让BS根据业务流的SFID确定各个动态业务流之间的上下行成对关系，本发明实施例中，GW在为每个动态业务流分配SFID时，可以为各个SFID附加业务标签，具有上下成对关系的动态业务流的SFID可以附加相同或相应的业务标签。 

对于GW来说，GW可以根据接收到的建立数据通道的请求中的参数信息来判断各个动态业务流之间的上下行成对关系，在获取各个动态业务流的上下行成对关系后，即可为具有上下行成对关系的动态业务流的SFID附加相同或相应的业务标签。例如，如果GW根据用于请求建立第一动态业务流的建立数据通道请求中的参数信息和用于请求建立第二动态业务流的建立数据通道请求中的参数信息，确定第一动态业务流和第二动态业务流是具有成对关系的上行业务流和下行业务流。那么，GW可以为第一动态业务流分配SFID为11，为第二动态业务流分配SFID为12，其中第一个数字为业务标签，这两个SFID中的业务标签相同。BS收到第一动态业务流和第二动态业务流的SFID时，可以确定第一动态业务流和第二动态业务流为与同一个业务相关的具有成对关系的上行业务流和下行业务流。 

对于预置业务流和初始业务流，也可以参照类似于动态业务流的方式分配SFID。 

对于BS来说，BS可以判断GW为第一动态业务流分配的第一SFID和 为第二动态业务流分配的第二SFID中是否包含相同或相应的业务标签，该业务标签用于标识与第一动态业务流和第二动态业务流相关的业务，从而判断第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是否是与同一业务相关的上行业务流和下行业务流。 

GW分配给各个动态业务流的SFID中还可以携带业务流类型标识，该业务流类型标识用于标识各个SFID对应的业务流是动态业务流。之所以在各个SFID携带业务流类型标识，是因为一个原始BS下的MS一旦切换到一个目标BS时，该MS在原始BS下的各个业务流的类型无法一并切换到目标BS，这样目标BS无法确定业务流到底是初始业务流、预置业务流还是动态业务流，如果将初始业务流和预置业务流删除，将导致业务无法正常进行。 

对于BS来说，BS在收到GW分配的SFID后，可以判断包含有业务流类型标识的第一SFID和第二SFID是否具有相同的业务标签。 

下面通过具体的例子来说明本发明动态业务流的处理方法的实现过程。 

根据802.16协议的规定，动态业务流的建立可以由MS发起，也可以由网络侧来发起，第一动态业务流请求消息和第二动态业务流请求消息可以是由MS或GW发送给BS的。 

一、由MS发起的创建动态业务流的过程 

如图2所示为本发明动态业务流的处理方法实施例二的信令交互图，包括： 

步骤201、MS发送第一动态业务流请求消息给BS，请求建立第一动态业务流。 

在本实施例中，假设第一动态业务流建立请求消息可以为第一DSA REQ(Dynamic Service Addition Request)消息。第一动态业务流为上行业务流。 

步骤202、BS查询是否有空闲资源，如果有空闲资源，则BS发送第一数据通道注册请求消息，例如第一PATH_REG_REQ(Data Path RegistrationRequest)消息给GW。 

步骤203、GW发送第一数据通道注册响应消息，例如第一PATH_REG_RSP(Data Path Registration Response)消息给BS，第一PATH_REG_RSP中携带GW为第一动态业务流分配的第一SFID。 

步骤204、BS接收到第一PATH_REG_RSP消息后，获取第一SFID，并发送第一DSA_RSP(Dynamic Service Addition Response)消息给MS，并为第一动态业务流分配资源。 

在BS为第一动态业务流分配资源后，BS启动一个计时器。 

步骤205、MS接收到第一DSA_RSP消息后，发送第一DSA_ACK(Dynamic Service Addition Acknowledgement)消息给B S。 

步骤206、BS发送第一PATH_REG_ACK(Data Path RegistrationAcknowledgement)消息给GW。 

经过步骤206之后，完成了第一动态业务流的建立。 

步骤207、MS发送第二DSA_REQ消息给BS，该第二DSA_REQ消息是第二动态业务流请求消息，用于请求建立第二动态业务流。 

步骤208、BS查询是否有空闲资源，如果有空闲资源，则BS发送第二PATH_REG_REQ消息给GW。 

步骤209、GW发送第二PATH_REG_RSP消息给BS，第二PATH_REG_RSP消息中携带GW为第二动态业务流分配的第二SFID。GW可以根据第一PATH_REG_RSP消息和第二PATH_REG_RSP消息中的参数信息确定第一动态业务流和第二动态业务流是与同一业务相关的上行业务流和下行业务流。GW分配第二SFID时，可以根据预先与BS协商好的策略分配，使得BS能够根据第一SFID和第二SFID确定第一动态业务流和第二动态业务流的上下行成对关系。或者，GW也可以为第一SFID和第二SFID附加相同或相应的业务标签，并且可以为第一SFID和第二SFID附加业务流类型标识。区别第一SFID和第二SFID的方式可以参见前述实施例中的介绍。 

步骤210、BS接收到第二PATH_REG_RSP消息后，获取第二SFID，为 第二动态业务流分配资源，并且判断第一动态业务流和第二动态业务流是否是与同一业务相关的上行业务流和下行业务流，如果是，则BS发送第二DSA RSP消息给MS，并判断第二动态业务流建立成功还是失败，如果失败则执行步骤211。如果成功，则不执行后续步骤。 

具体地，BS可以根据第一PATH_REG_RSP消息和第二PATH_REG_RSP消息中的请求参数信息来判断第一动态业务流和第二动态业务流是否是与同一业务相关的上行业务流和下行业务流，也可以根据第一SFID和第二SFID来判断第一动态业务流和第二动态业务流是否是与同一业务相关的上行业务流和下行业务流，具体的判断方法参见前述实施例的描述。 

BS发送第二DSA RSP消息给MS，并判断第二动态业务流的建立是成功还是失败，具体可以包括：，BS可以在预设的时间内，判断第二动态业务流的建立是否成功。例如，超过预设时间，BS没有收到MS发送的第二DSA_ACK消息，则确定第二动态业务流的建立失败。该预设时间可以从步骤204中的计时器的开启时刻起算。 

步骤211、BS回收为第一动态业务流分配的资源。至于步骤210中为第二动态业务流分配的资源，如果第二动态业务流建立失败，那么该资源会被自动释放掉。 

现有技术中，在第一动态业务流建立成功而第二动态业务流建立失败的情况下，只会回收分配给第二动态业务流的资源，而依然保留分配给第一动态业务流的资源，分配给第一动态业务流的资源实际上被浪费了。实施例二中，虽然第一动态业务流建立成功，但是第二动态业务流建立失败，由于第一动态业务流和第二动态业务流需要同时建立成功才能保证业务的正常进行，所以一并回收分配给第一动态业务流和第二动态业务流的资源可以避免资源的浪费。 

实施例二中描述的是第一动态业务流建立成功，第二动态业务流建立失败的情况。可选的，在上述实施例中也可以是先建立第二动态业务流，再建 立第一动态业务流，如果第二动态业务流建立成功，而第一动态业务流建立失败，则BS可以在为第二动态业务流分配资源后启动一个计时器，判断第一动态业务流在一个预设时间内是否能够重新建立成功，该预设时间可以自BS在为第二动态业务流分配资源后启动的计时器的开启时刻起算。重新建立第一动态业务流的过程与实施例二类似。 

二、由MS发起的删除动态业务流的过程 

如图3所示为本发明动态业务流的处理方法实施例三的信令交互图，包括： 

步骤301、MS发送第一动态业务流请求消息给BS。 

在本实施例中，假设第一动态业务流请求消息为第一动态业务流删除请求消息，第一动态业务流删除请求消息可以是第一该第一DSD_REQ(Dynamic Service Delete Request)消息，该消息用于请求BS删除第一动态业务流。 

步骤302、BS发送第一数据通道删除请求消息给GW，第一数据通道删除请求消息可以是。第一PATH_DEREG_REQ(Data Path DeregistrationRequest)消息。 

步骤303、GW发送第一数据通道删除响应消息给BS，该第一数据通道删除响应消息可以是第一PATH_DEREG_RSP(Data Path DeregistrationResponse)消息。由于步骤301中，第一DSD_REQ消息用于请求删除第一动态业务流，而第一动态业务流的SFID在建立第一动态业务流时GW已经分配好，所以步骤303中无需重新为第一动态业务流分配SFID。 

步骤304、BS接收到第一PATH_DEREG_RSP消息后，发送第一动态业务流删除响应消息给MS，第一动态业务流删除响应消息可以是第一DSD_RSP(Dynamic Service Delete Response)消息，并回收分配给第一动态业务流的资源。回收分配给第一动态业务流的资源后，BS启动一个计时器。 

步骤305、MS接收到第一DSD_RSP消息后，发送第一动态业务流删除 确认消息给BS第一动态业务流删除确认消息可以是第一DSD_ACK(Dynamic Service Delete Acknowledgement)消息。 

步骤306、BS发送第一数据通道删除确认消息给GW，第一数据通道删除确认消息可以是第一PATH_DEREG_ACK(Data Path DeregistrationAcknowledgement)消息。 

经过步骤306之后，完成了第一动态业务流的删除。 

步骤307、MS发送第二DSD_REQ消息给BS，该第二DSD_REQ消息用于请求BS删除第二动态业务流。 

步骤308、BS发送第二PATH_DEREG_REQ消息给GW。 

步骤309、GW发送第二PATH_REG_RSP消息给BS。 

步骤310、BS接收到第二PATH_DEREG_RSP消息后，判断第一动态业务流和第二动态业务流是否是与同一业务相关的上行业务流和下行业务流，如果是，则BS发送第二DSD_RSP消息给MS，并判断第二动态业务流的删除是成功还是失败，如果失败则执行步骤311。如果成功，则回收为第二动态业务流分配的资源。 

具体地，BS可以在预设的时间内，判断第二动态业务流的删除是否成功。例如，超过预设时间，BS没有收到MS发送的第二DSD_ACK消息，则确定第二动态业务流的删除失败。该预设时间可以从步骤304中的计时器的开启时刻起算。 

步骤311、BS回收分配给第二动态业务流的资源。 

现有技术中，在第一动态业务流删除成功而第二动态业务流删除失败的情况下，只会回收分配给第一动态业务流的资源，而依然保留分配给第二动态业务流的资源，分配给第二动态业务流的资源实际上被浪费了。实施例三中，虽然第一动态业务流删除成功，但是第二动态业务流删除失败，一并回收分配给第一动态业务流和第二动态业务流的资源可以避免资源的浪费。 

实施例三中描述的是第一动态业务流删除成功，第二动态业务流删除失 败的情况。可选的，在上述实施例中也可以是先建立第二动态业务流，再建立第一动态业务流，如果第二动态业务流删除成功，而第一动态业务流删除失败，则BS可以在回收为第二动态业务流分配的资源后启动一个计时器，判断第一动态业务流的在一个预设时间内是否能够重新删除成功，该预设时间可以自BS在回收为第二动态业务流分配的资源后启动的计时器的开启时刻起算。重新删除第一动态业务流的过程与实施例三类似。 

三、由MS发起的修改动态业务流的过程 

如图4所示为本发明动态业务流的处理方法实施例四的信令交互图，包括： 

步骤401、MS发送第一动态业务流请求消息给BS。 

在本实施例中，假设第一动态业务流请求消息为第一动态业务流修改请求消息，用于请求修改第一动态业务流。 

步骤402、BS发送第一数据通道修改请求消息给GW。 

步骤403、GW发送第一数据通道修改响应消息给BS。由于步骤401中，第一动态业务流修改请求消息用于请求修改第一动态业务流，而第一动态业务流的SFID在建立第一动态业务流时GW已经分配好，所以步骤403中无需重新为第一动态业务流分配SFID。 

步骤404、BS接收到第一数据通道修改响应消息后，发送第一动态业务流修改响应消息给MS，并针对该第一动态业务流修改请求消息为第一动态业务流分配附加资源。为第一动态业务流分配附加资源后，BS启动一个计时器。 

步骤405、MS接收到第一动态业务流修改响应消息后，发送第一动态业务流修改确认消息给BS。 

步骤406、BS发送第一数据通道修改确认消息给GW。 

经过步骤406之后，完成了第一动态业务流的修改。 

步骤407、MS发送第二动态业务流请求消息给BS。 

在本实施例中，该第二动态业务流请求消息是第二动态业务流修改请求 消息，用于请求修改第二动态业务流。 

步骤408、BS发送第二数据通道修改请求消息给GW。 

步骤409、GW发送第二数据通道修改响应消息给BS。 

步骤410、BS接收到第二数据通道修改响应消息后，为第二动态业务流分配附加资源，判断第一动态业务流和第二动态业务流是否是与同一业务相关的上行业务流和下行业务流，如果是，则BS发送第二动态业务流修改响应消息给MS，并判断第二动态业务流的修改是成功还是失败，如果失败则执行步骤411。如果成功，则不执行后续步骤。 

具体地，BS可以在预设的时间内，判断第二动态业务流的修改是否成功。例如，超过预设时间，BS没有收到MS发送的第二动态业务流修改确认消息，则确定第二动态业务流的修改失败。该预设时间可以从步骤404中的计时器的开启时刻起算。 

判断第一动态业务流和第二动态业务流是否是与同一业务相关的上行业务流和下行业务流的方法可以参见前述实施例中的介绍。 

步骤411、BS回收针对第一动态业务流修改请求消息配给第一动态业务流的附加资源，也就是说使得分配给第一动态业务流的资源的情况保持与修改第一动态业务流之前一致。至于步骤410中分配给第二动态业务流的附加资源，如果第二动态业务流修改失败，则该附加资源会被自动释放掉。本发明各实施例中，附加资源是指为了修改某个动态业务流而为这个动态业务流额外分配的资源。例如，如图4所示的实施例中，第一动态业务流本本身已经有资源，但是如果要修改第一动态业务流，就需要为第一动态业务流额外再分配资源，额外分配的资源就是附加资源。 

现有技术中，在第一动态业务流修改成功而第二动态业务流修改失败的情况下，只会回收针对第二动态业务流修改请求消息而分配给第二动态业务流的资源，也就是说将第二动态业务流的资源恢复到BS接收到第二动态业务流请求消息之前，而依然保留针对第一动态业务流修改请求消息而分配给 第一动态业务流的资源，在此种情况下分配给第一动态业务流的另外的资源实际上被浪费了。实施例四中，虽然第一动态业务流修改成功，但是第二动态业务流修改失败，通过回收分配第一动态业务流的附加资源，可以避免资源的浪费。 

实施例四中描述的是第一动态业务流修改成功，第二动态业务流修改失败的情况。可选的，在上述实施例中也可以是先修改第二动态业务流，再修改第一动态业务流，如果第二动态业务流修改成功，而第一动态业务流修改失败，则BS可以在为第二动态业务流分配资源后启动一个计时器，判断第一动态业务流在一个预设时间内是否能够重新修改成功，该预设时间可以自BS在为第二动态业务流分配资源后启动的计时器的开启时刻起算。重新修改第一动态业务流的过程与实施例四类似。 

四、由网络侧发起的建立动态业务流的过程 

如图5所示为本发明动态业务流的处理方法实施例五的信令交互图，包括： 

步骤501、GW发送第一动态业务流请求消息给BS。 

在本实施例中，假设第一动态业务流请求消息为第一PATH_REG_REQ消息，用于请求建立第一动态业务流。 

步骤502、BS接收到第一PATH_REG_REQ消息后，获取第一SFID，BS查询是否有空闲资源，如果有空闲资源，则发送第一DSA REQ消息给MS，并为第一动态业务流分配资源。在为第一动态业务流分配资源后，BS启动一个计时器。 

步骤503、MS接收到第一DSA_RSQ消息后，发送第一DSA_RSP消息给BS。 

步骤504、BS发送第一DSA_ACK消息给MS。 

步骤505、BS发送第一PATH_REG_RSP消息给GW。 

步骤506、GW发送第一PATH_REG_ACK消息给BS。 

经过步骤506之后，完成了第一动态业务流的建立。 

步骤507、GW发送第二PATH_REG_REQ消息给BS，该第二PATH_DEREG_REQ消息是第二动态业务流请求消息，用于请求建立第二动态业务流。 

步骤508、BS接收到第二PATH_REG_REQ消息后，为第二动态业务流分配资源，获取第二SFID，BS判断第一动态业务流和第二动态业务流是否是与同一业务相关的上行业务流和下行业务流，如果是，则BS发送第二DSA_REQ消息给MS，并判断第二动态业务流的建立是成功还是失败，如果失败则执行步骤509。 

具体地，BS可以根据第一PATH_REG_REQ消息和第二PATH_REG_REQ消息中的请求参数信息来判断，也可以根据第一SFID和第二SFID来判断，具体的判断方法参见前述实施例的描述。 

BS发送第二DSA_REQ消息给MS，为第二动态业务流分配资源，并判断第二动态业务流的建立是成功还是失败，具体可以包括：，BS可以在预设的时间内，判断第二动态业务流的建立是否成功。例如，超过预设时间，BS没有收到MS发送的第二DSA_ACK消息，则确定第二动态业务流的建立失败。该预设时间可以从步骤502中的计时器的开启时刻起算。 

步骤509、BS回收给第一动态业务流的资源。至于步骤508中分配给第二动态业务流的资源，如果第二动态业务流建立失败，则该资源会被自动释放掉。 

实施例五中描述的是第一动态业务流建立成功，第二动态业务流建立失败的情况。可选的，在上述实施例中也可以是先建立第二动态业务流，再建立第一动态业务流，如果第二动态业务流建立成功，而第一动态业务流建立失败，则BS可以在为第二动态业务流分配资源后启动一个计时器，判断第一动态业务流在一个预设时间内是否能够重新建立成功，该预设时间可以自BS在为第二动态业务流分配资源后启动的计时器的开启时刻起算。重新建立 第一动态业务流的过程与实施例五类似。 

五、由网络侧发起的删除动态业务流的过程 

如图6所示为本发明动态业务流的处理方法实施例六的信令交互图，包括： 

步骤601、GW发送第一动态业务流请求消息给BS； 

在本实施例中假设第一动态业务流请求消息为第一PATH_DEREG_REQ消息，用于请求删除第一动态业务流。 

步骤602、BS接收到第一PATH_DEREG_REQ消息后，获取第一SFID，BS查询是否有空闲资源，如果有空闲资源，则发送第一DSD_REQ消息给MS，并回收为第一动态业务流分配的资源。在回收为第一动态业务流分配资源后，BS启动一个计时器。 

步骤603、MS接收到第一DSD_RSQ消息后，发送第一DSD_RSP消息给BS。 

步骤604、BS发送第一DSD_ACK消息给MS。 

步骤605、BS发送第一PATH_DEREG_RSP消息给GW。 

步骤606、GW发送第一PATH_DEREG_ACK消息给BS。 

经过步骤606之后，完成了第一动态业务流的删除。 

步骤607、GW发送第二动态业务流请求消息给BS； 

在本实施例中假设第二动态业务流请求消息为第二PATH_DEREG_REQ消息，用于请求删除第二动态业务流。 

步骤608、BS接收到第二PATH_DEREG_REQ消息后，获取第二SFID，BS判断第一动态业务流和第二动态业务流是否是与同一业务相关的上行业务流和下行业务流，如果是，则BS发送第二DSD_RSQ消息给MS，并判断第二动态业务流的删除是成功还是失败，如果失败，则执行步骤609。如果成功，则不执行后续步骤。 

具体地，BS可以根据第一PATH_DEREG_REQ消息和第二 PATH_DEREG_REQ消息中的请求参数信息来判断，也可以根据第一SFID和第二SFID来判断，具体的判断方法参见前述实施例的描述。 

BS发送第二DSD_RSQ消息给MS，为第二动态业务流分配资源，并判断第二动态业务流的删除是否成功。具体地，BS可以在预设的时间内，判断第二动态业务流的删除是否成功。例如，超过预设时间，BS没有收到MS发送的第二DSA_ACK，则确定第二动态业务流的删除失败。该预设时间可以从步骤602中的计时器的开启时刻起算。 

步骤609、BS回收给第二动态业务流的资源。 

实施例六中描述的是第一动态业务流删除成功，第二动态业务流删除失败的情况。可选的，在上述实施例中也可以是先建立第二动态业务流，再建立第一动态业务流，如果第二动态业务流删除成功，而第一动态业务流删除失败，则BS可以在回收为第二动态业务流分配的资源后启动一个计时器，判断第一动态业务流的在一个预设时间内是否能够重新删除成功，该预设时间可以自BS在回收为第二动态业务流分配的资源后启动的计时器的开启时刻起算。重新删除第一动态业务流的过程与实施例六类似。 

六、由网络侧发起的修改动态业务流的过程 

如图7所示为本发明动态业务流的处理方法实施例七的信令交互图，包括： 

步骤701、GW发送第一动态业务流请求消息给BS。 

在本实施例中，假设第一动态业务流请求消息为第一动态业务流修改请求消息，用于请求修改第一动态业务流。 

步骤702、BS接收到第一动态业务流修改请求消息后，获取第一SFID，BS查询是否有空闲资源，如果有空闲资源，则发送第一数据通道修改请求消息给MS，并针对该第一动态业务流修改请求消息为第一动态业务流分配资源。为第一动态业务流分配资源后，BS启动一个计时器。 

步骤703、MS接收到第一数据通道修改请求消息后，发送第一数据通道 修改响应消息BS。 

步骤704、BS发送第一数据通道修改确认消息给MS。 

步骤705、BS发送第一动态业务流修改响应消息给GW。 

步骤706、GW发送第一动态业务流修改确认消息给BS。 

经过步骤706之后，完成了第一动态业务流的修改。 

步骤707、GW发送第二动态业务流请求消息给BS。 

在本实施例中，该第二动态业务流请求消息是第二动态业务流修改请求消息，用于请求修改第二动态业务流。 

步骤708、BS接收到第二动态业务流的修改请求消息后，为第二动态业务流分配附加资源，获取第二SFID，BS判断第一动态业务流和第二动态业务流是否是与同一业务相关的上行业务流和下行业务流，如果是，则BS发送第二数据通道修改请求消息给MS，并判断第二动态业务流的修改是成功还是失败，如果失败，则执行步骤709。如果成功，则不执行后续步骤。 

具体地，BS可以根据第二动态业务流修改请求消息和第一动态业务流修改请求消息中的请求参数信息来判断，也可以根据第一SFID和第二SFID来判断，具体的判断方法参见前述实施例的描述。 

BS发送第二数据通道修改请求消息给MS，为第二动态业务流分配资源，并判断第二动态业务流的修改是否成功。具体地，BS可以在预设的时间内，判断第二动态业务流的修改是否成功。例如，超过预设时间，BS没有收到MS发送的第二数据通道修改确认消息，则确定第二动态业务流的修改失败。该预设时间可以从步骤702中的计时器的开启时刻起算。 

步骤709、BS回收分配给第一动态业务流的附加资源。至于步骤708中分配给第二动态业务流的附加资源，如果第二动态业务流的建立失败，则该附加资源会被自动释放掉。 

实施例七中描述的是第一动态业务流修改成功，第二动态业务流修改失败的情况。可选的，在上述实施例中也可以是先修改第二动态业务流，再修 改第一动态业务流，如果第二动态业务流修改成功，而第一动态业务流修改失败，则BS可以在为第二动态业务流分配的资源后启动一个计时器，判断第一动态业务流的在一个预设时间内是否能够重新修改成功，该预设时间可以自BS在为第二动态业务流分配的资源后启动的计时器的开启时刻起算。重新修改第一动态业务流的过程与实施例七类似。 

现有技术中，在第一动态业务流修改成功而第二动态业务流修改失败的情况下，只会回收分配给第二动态业务流的资源，而依然保留分配给第一动态业务流的资源，分配给第一动态业务流的资源实际上被浪费了。实施例七中，虽然第一动态业务流修改成功，但是第二动态业务流修改失败，由于第一动态业务流和第二动态业务流需要同时修改成功才能保证业务的正常进行，所以恢复第一动态业务流的资源，可以避免资源的浪费。 

本发明实施例提供的动态业务流的处理方法，BS如果确定第一动态业务流和第二动态业务流是与同一业务相关的上行业务流和下行业务流，则BS判断第二动态业务流请求消息所请求的操作是否成功；如果第二动态业务流请求消息所请求的操作失败，则回收回恢复分配给第一动态业务流的资源，或者回收分配给第二动态业务流的资源；而不是如同现有技术那样，一条动态业务流处理操作成功而另外一条动态业务流处理操作失败的情况下，始终保留分配给其中一条动态业务流的资源；避免了资源的浪费。 

如图8所示为本发明基站实施例一的结构示意图，该基站包括第一接收模块11、第一处理模块12、第二接收模块13、第二处理模块14和第三处理模块15。其中，第一接收模块11用于接收第一动态业务流请求消息。第一处理模块12与第一接收模块11连接，用于根据第一动态业务流请求消息建立、删除或修改业务的第一动态业务流。第二接收模块13用于接收第二动态业务流请求消息。第二处理模块14与第二接收模块13连接，用于根据第二动态业务流请求消息建立、删除或修改业务的第二动态业务流。第三处理模块15与第二处理模块14和第一处理模块12连接，用于在第二处理模块14 建立第二动态业务流失败的情况下，回收分配给第一动态业务流分配的资源；在第二处理模块14删除第二动态业务流失败的情况下，回收分配给第二动态业务流的资源；在第二处理模块14修改第二动态业务流失败的情况下，回收分配给第一动态业务流分配的附加资源。 

上述基站还可以包括确定模块17，该确定模块17与第一接收模块11和第二接收模块13连接，用于确定第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流。 

具体来说，该确定模块17可以包括第一判断单元171和第一确定单元172。第一判断单元171分别于第一接收模块11和第二接收模块13连接，用于判断第一动态业务流请求消息和第二动态业务流请求消息中的请求参数信息是否相同。第一确定单元172与第一判断单元171连接，用于在第一判断单元171判断第一动态业务流请求消息和第二动态业务流请求消息中的请求参数信息相同的情况下，确定第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流。该第一确定单元172还与第三处理模块15连接，第三处理模块15在第一确定单元172确定第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流的情况下，进行相应的处理。 

如图9所示为本发明基站实施例二的结构示意图，该基站中，确定单元17包括第一接收单元173、第二接收单元174、第二判断单元175和第二确定单元176。第一接收单元173用于接收GW为第一动态业务流分配的第一SFID。第二接收单元174用于接收GW为第二动态业务流分配的第二SFID。第二判断单元175与第一接收单元173和第二接收单元174连接，用于判断第一SFID和第二SFID是否包含相同或相应的业务标签。第二确定单元176与第二判断单元175连接，用于在第二判断单元175判断第一SFID和第二SFID包含相同或相应的业务标签的情况下，确定第一动态业务流与所述第二 动态业务流是与所述业务相关的上行业务流和下行业务流。第二确定单元176还可以与第三处理模块15连接，第三处理模块15在第二确定单元176确定第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流的情况下，进行相应的处理。 

如图10所示为本发明基站实施例三的结构示意图，该基站中，确定模块17包括：第一接收单元173、第二接收单元174、第三判断单元177和第三确定单元178。第三判断单元177分别与第一接收单元173和第二接收单元174连接，用于判断第一SFID和第二SFID是否相同或相对。第三确定单元178与第三判断单元177连接，用于在第三判断单元判断第一SFID和第二SFID相同或相对的情况下，确定第一动态业务流与第二动态业务流是与所述业务相关的上行业务流和下行业务流。第三确定单元178还与第三处理模块15连接，第三处理模块15在第三确定单元178确定第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流的情况下，进行相应的处理。 

本发明实施例提供的基站，第三处理模块在第二处理模块建立第二动态业务流失败的情况下，回收为第一动态业务流分配的资源；在第二处理模块删除第二动态业务流失败的情况下，回收分配给第二动态业务流的资源；在第二处理模块修改第二动态业务流失败的情况下，回收为所述第一动态业务流分配的附加资源。而不是如同现有技术那样，在一条动态业务流处理操作成功而另外一条动态业务流处理操作失败的情况下，始终保留分配给其中一条动态业务流的资源；避免了资源的浪费。 

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

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

Claims (10)

1.一种动态业务流的处理方法，其特征在于，包括：

接收第一动态业务流请求消息；

根据所述第一动态业务流请求消息建立、删除或修改业务的第一动态业务流；

接收第二动态业务流请求消息；

根据所述第二动态业务流请求消息建立、删除或修改所述业务的第二动态业务流；如果建立第二动态业务流失败，则回收为第一动态业务流分配的资源；如果删除第二动态业务流失败，则回收为第二动态业务流分配的资源；如果修改第二动态业务流失败，则回收为所述第一动态业务流分配的附加资源；

其中，所述接收第二动态业务流请求消息之后，所述根据所述第二动态业务流请求消息建立、删除或修改所述业务的第二动态业务流之前，所述方法还包括：

确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流。

2.根据权利要求1所述的动态业务流的处理方法，其特征在于，所述确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流，包括：

若所述第一动态业务流请求消息和第二动态业务流请求消息中的请求参数信息相同，则确定所述第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流。

3.根据权利要求2所述的动态业务流的处理方法，其特征在于，所述请求参数信息包括调度类型、业务流方向、业务质量QOS参数和分类器中的五元组信息；

所述分类器中的五元组信息包括源互联网协议IP地址、目的IP地址、协议号、源端口号和目的端口号。

4.根据权利要求1所述的动态业务流的处理方法，其特征在于，在接收第一动态业务流请求消息之后，根据所述第一动态业务流请求消息建立、删除或修改业务的第一动态业务流之前，还包括：接收网关GW为所述第一动态业务流分配的第一业务流标识SFID；

在接收第二动态业务流请求消息之后，所述确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流之前，还包括：接收GW为所述第二动态业务流分配的第二SFID；

所述确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流，包括：

若所述第一SFID和第二SFID包含相同或相应的业务标签，则确定所述第一动态业务流与所述第二动态业务流是与所述业务相关的上行业务流和下行业务流，所述业务标签用于标识与所述第一动态业务流和第二动态业务流相关的业务。

5.根据权利要求4所述的动态业务流的处理方法，其特征在于，所述第一SFID和第二SFID还包括业务流类型标识，所述业务流类型标识用于标识所述第一SFID和第二SFID所对应的业务流是动态业务流；

若所述第一SFID和第二SFID中包含相同或相应的业务标签，则确定所述第一动态业务流与所述第二动态业务流是与所述业务相关的上行业务流和下行业务流，包括：若包含有业务流类型标识的第一SFID和第二SFID具有相同或相应的业务标签，则确定所述第一动态业务流与所述第二动态业务流是与所述业务相关的上行业务流和下行业务流。

6.根据权利要求1所述的动态业务流的处理方法，其特征在于，在接收第一动态业务流请求消息之后，根据所述第一动态业务流请求消息建立、删除或修改业务的第一动态业务流之前，还包括：接收GW为所述第一动态业务流分配的第一SFID；

所述确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流之前，还包括：接收GW为所述第二动态业务流分配的第二SFID；

所述确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流，包括：

若所述第一SFID和为第二SFID相同或相对，则确定所述第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流。

7.一种基站，其特征在于，包括：

第一接收模块，用于接收第一动态业务流请求消息；

第一处理模块，用于根据所述第一动态业务流请求消息建立、删除或修改业务的第一动态业务流；

第二接收模块，用于接收第二动态业务流请求消息；

第二处理模块，用于根据所述第二动态业务流请求消息建立、删除或修改所述业务的第二动态业务流；

第三处理模块，用于在所述第二处理模块建立第二动态业务流失败的情况下，回收为第一动态业务流分配的资源；在所述第二处理模块删除第二动态业务流失败的情况下，回收分配给第二动态业务流的资源；在所述第二处理模块修改第二动态业务流失败的情况下，回收为所述第一动态业务流分配的附加资源；确定模块，用于确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流。

8.根据权利要求7所述的基站，其特征在于，所述确定模块包括：

第一判断单元，用于判断所述第一动态业务流请求消息和第二动态业务流请求消息中的请求参数信息是否相同；

第一确定单元，用于在所述第一判断单元判断所述第一动态业务流请求消息和第二动态业务流请求消息中的请求参数信息相同的情况下，确定所述第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是与所述业务相关的上行业务流和下行业务流。

9.根据权利要求7所述的基站，其特征在于，所述确定模块包括：

第一接收单元，用于接收网关GW为所述第一动态业务流分配的第一业务流标识SFID；

第二接收单元，用于接收GW为所述第二动态业务流分配的第二SFID；

第二判断单元，用于判断所述第一SFID和第二SFID是否包含相同或相应的业务标签；

第二确定单元，用于在所述第二判断单元判断所述第一SFID和第二SFID包含相同或相应的业务标签的情况下，确定所述第一动态业务流与所述第二动态业务流是与所述业务相关的上行业务流和下行业务流；

所述业务标签用于标识与所述第一动态业务流和第二动态业务流相关的业务。

10.根据权利要求7所述的基站，其特征在于，所述确定模块包括：

第一接收单元，用于接收GW为所述第一动态业务流分配的第一SFID；

第二接收单元，用于接收GW为所述第二动态业务流分配的第二SFID；

第三判断单元，用于判断所述第一SFID和第二SFID是否相同或相对；

第三确定单元，用于在所述第三判断单元判断所述第一SFID和第二SFID相同或相对的情况下，确定所述第一动态业务流与所述第二动态业务流是与所述业务相关的上行业务流和下行业务流。

Images