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

专利名称：动态业务流的处理方法及基站的制作方法
技术领域：
本发明实施例涉及通信技术领域，尤其涉及一种动态业务流的处理方法及基站。
背景技术：
微波存取全球互通(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, 简称Q0S)参数。例如，调度类型可以包括尽力而为业务(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发起，也可以由网络侧来发
9起，第一动态业务流请求消息和第二动态业务流请求消息可以是由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(DataPath RegistrationAcknowledgement) 消息给GW。经过步骤206之后，完成了第一动态业务流的建立。步骤207、MS发送第二 DSA_REQ消息给BS，该第二 DSA_REQ消息是第二动态业务 流请求消息，用于请求建立第二动态业务流。步骤208、BS查询是否有空闲资源，如果有空闲资源，则BS发送第二 PATH_REG_REQ 消息给GW。步骤209、Gff发送第二 PATH_REG_RSP消息给BS，第二 PATH_REG_RSP消息中携带 Gff为第二动态业务流分配的第二 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，第一数据通道删除请求消息 胃以i。 H—PATH—DEREG—RE^KDatii Path DeregistrationRequest) ff|;|、。步骤303、Gff发送第一数据通道删除响应消息给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、Gff 发送第二 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发送第一数据通道修改请求消息给Gl步骤403、GW发送第一数据通道修改响应消息给BS。由于步骤401中，第一动态 业务流修改请求消息用于请求修改第一动态业务流，而第一动态业务流的SFID在建立第 一动态业务流时GW已经分配好，所以步骤403中无需重新为第一动态业务流分配SFID。步骤404、BS接收到第一数据通道修改响应消息后，发送第一动态业务流修改响 应消息给MS，并针对该第一动态业务流修改请求消息为第一动态业务流分配附加资源。为 第一动态业务流分配附加资源后，BS启动一个计时器。步骤405、MS接收到第一动态业务流修改响应消息后，发送第一动态业务流修改 确认消息给BS。
步骤406、BS发送第一数据通道修改确认消息给GW。经过步骤406之后，完成了第一动态业务流的修改。步骤407、MS发送第二动态业务流请求消息给BS。在本实施例中，该第二动态业务流请求消息是第二动态业务流修改请求消息，用 于请求修改第二动态业务流。步骤408、BS发送第二数据通道修改请求消息给Gl步骤409、Gff发送第二数据通道修改响应消息给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、Gff 发送第一 PATH_REG_ACK 消息给 BS。经过步骤506之后，完成了第一动态业务流的建立。步骤507、Gff 发送第二 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、Gff 发送第一 PATH_DEREG_ACK 消息给 BS。经过步骤606之后，完成了第一动态业务流的删除。步骤607、Gff发送第二动态业务流请求消息给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、Gff发送第一动态业务流修改确认消息给BS。经过步骤706之后，完成了第一动态业务流的修改。
步骤707、Gff发送第二动态业务流请求消息给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确定第一动态业务流与所述第二动态业务流请求消 息所涉及的第二动态业务流是与同一业务相关的上行业务流和下行业务流的情况下，进行相应的处理。 本发明实施例提供的基站，第三处理模块在第二处理模块建立第二动态业务流失败的情况下，回收为第一动态业务流分配的资源；在第二处理模块删除第二动态业务流失 败的情况下，回收分配给第二动态业务流的资源；在第二处理模块修改第二动态业务流失 败的情况下，回收为所述第一动态业务流分配的附加资源。而不是如同现有技术那样，在一 条动态业务流处理操作成功而另外一条动态业务流处理操作失败的情况下，始终保留分配 给其中一条动态业务流的资源；避免了资源的浪费。本领域普通技术人员可以理解实现上述方法实施例的全部或部分步骤可以通过 程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序 在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括R0M、RAM、磁碟或者 光盘等各种可以存储程序代码的介质。最后应说明的是以上实施例仅用以说明本发明的技术方案，而非对其限制；尽 管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解其依然 可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替 换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精 神和范围。
权利要求
一种动态业务流的处理方法，其特征在于，包括接收第一动态业务流请求消息；根据所述第一动态业务流请求消息建立、删除或修改业务的第一动态业务流；接收第二动态业务流请求消息；根据所述第二动态业务流请求消息建立、删除或修改所述业务的第二动态业务流；如果建立第二动态业务流失败，则回收为第一动态业务流分配的资源；如果删除第二动态业务流失败，则回收为第二动态业务流分配的资源；如果修改第二动态业务流失败，则回收为所述第一动态业务流分配的附加资源。
2.根据权利要求1所述的动态业务流的处理方法，其特征在于，所述接收第二动态业 务流请求消息之后进一步包括确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是 与所述业务相关的上行业务流和下行业务流。
3.根据权利要求2所述的动态业务流的处理方法，其特征在于，所述确定所述第一动 态业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上 行业务流和下行业务流，包括若所述第一动态业务流请求消息和第二动态业务流请求消息中的请求参数信息相同， 则确定所述第一动态业务流与所述第二动态业务流请求消息所涉及的第二动态业务流是 与所述业务相关的上行业务流和下行业务流。
4.根据权利要求3所述的动态业务流的处理方法，其特征在于，所述请求参数信息包 括调度类型、业务流方向、业务质量Q0S参数和分类器中的五元组信息；所述分类器中的五元组信息包括源互联网协议IP地址、目的IP地址、协议号、源端口 号和目的端口号。
5.根据权利要求2所述的动态业务流的处理方法，其特征在于，在接收第一动态业务 流请求消息之后，根据所述第一动态业务流请求消息建立、删除或修改业务的第一动态业 务流之前，还包括接收网关GW为所述第一动态业务流分配的第一业务流标识SFID ；在接收第二动态业务流请求消息之后，根据所述第二动态业务流请求消息建立、删除 或修改所述业务的第二动态业务流之前，还包括接收GW为所述第二动态业务流分配的第 二 SFID ；所述确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务 流是与所述业务相关的上行业务流和下行业务流，包括若所述第一 SFID和第二 SFID包含相同或相应的业务标签，则确定所述第一动态业务 流与所述第二动态业务流是与所述业务相关的上行业务流和下行业务流，所述业务标签用 于标识与所述第一动态业务流和第二动态业务流相关的业务。
6.根据权利要求5所述的动态业务流的处理方法，其特征在于，所述第一SFID和第二 SFID还包括业务流类型标识，所述业务流类型标识用于标识所述第一 SFID和第二 SFID所 对应的业务流是动态业务流；若所述第一 SFID和第二 SFID中包含相同或相应的业务标签，则确定所述第一动态业 务流与所述第二动态业务流是与所述业务相关的上行业务流和下行业务流，包括若包含 有业务流类型标识的第一 SFID和第二 SFID具有相同或相应的业务标签，则确定所述第一动态业务流与所述第二动态业务流是与所述业务相关的上行业务流和下行业务流。
7.根据权利要求2所述的动态业务流的处理方法，其特征在于，在接收第一动态业务 流请求消息之后，根据所述第一动态业务流请求消息建立、删除或修改业务的第一动态业 务流之前，还包括接收GW为所述第一动态业务流分配的第一 SFID ；根据所述第二动态业务流请求消息建立、删除或修改所述业务的第二动态业务流之 前，还包括接收GW为所述第二动态业务流分配的第二 SFID ；所述确定所述第一动态业务流与所述第二动态业务流请求消息涉及的第二动态业务 流是与所述业务相关的上行业务流和下行业务流，包括若所述第一 SFID和为第二 SFID相同或相对，则确定所述第一动态业务流与所述第二 动态业务流请求消息所涉及的第二动态业务流是与所述业务相关的上行业务流和下行业 务流。
8.一种基站，其特征在于，包括第一接收模块，用于接收第一动态业务流请求消息；第一处理模块，用于根据所述第一动态业务流请求消息建立、删除或修改业务的第一 动态业务流；第二接收模块，用于接收第二动态业务流请求消息；第二处理模块，用于根据所述第二动态业务流请求消息建立、删除或修改所述业务的 第二动态业务流；第三处理模块，用于在所述第二处理模块建立第二动态业务流失败的情况下，回收为 第一动态业务流分配的资源；在所述第二处理模块删除第二动态业务流失败的情况下，回 收分配给第二动态业务流的资源；在所述第二处理模块修改第二动态业务流失败的情况 下，回收为所述第一动态业务流分配的附加资源。
9.根据权利要求8所述的基站，其特征在于，还包括确定模块，用于确定所述第一动态 业务流与所述第二动态业务流请求消息涉及的第二动态业务流是与所述业务相关的上行 业务流和下行业务流。
10.根据权利要求9所述的基站，其特征在于，所述确定模块包括第一判断单元，用于判断所述第一动态业务流请求消息和第二动态业务流请求消息中 的请求参数信息是否相同；第一确定单元，用于在所述第一判断单元判断所述第一动态业务流请求消息和第二动 态业务流请求消息中的请求参数信息相同的情况下，确定所述第一动态业务流与所述第二 动态业务流请求消息所涉及的第二动态业务流是与所述业务相关的上行业务流和下行业 务流。
11.根据权利要求9所述的基站，其特征在于，所述确定模块包括第一接收单元，用于接收网关GW为所述第一动态业务流分配的第一业务流标识SFID ；第二接收单元，用于接收GW为所述第二动态业务流分配的第二 SFID ；第二判断单元，用于判断所述第一 SFID和第二 SFID是否包含相同或相应的业务标签；第二确定单元，用于在所述第二判断单元判断所述第一 SFID和第二 SFID包含相同或 相应的业务标签的情况下，确定所述第一动态业务流与所述第二动态业务流是与所述业务相关的上行业务流和下行业务流； 所述业务标签用于标识与所述第一动态业务流和第二动态业务流相关的业务。
12.根据权利要求9所述的基站，其特征在于，所述确定模块包括 第一接收单元，用于接收GW为所述第一动态业务流分配的第一 SFID ； 第二接收单元，用于接收GW为所述第二动态业务流分配的第二 SFID ； 第三判断单元，用于判断所述第一 SFID和第二 SFID是否相同或相对； 第三确定单元，用于在所述第三判断单元判断所述第一 SFID和第二 SFID相同或相对 的情况下，确定所述第一动态业务流与所述第二动态业务流是与所述业务相关的上行业务 流和下行业务流。
全文摘要
本发明提供一种动态业务流的处理方法及基站，其中方法包括接收第一动态业务流请求消息；根据第一动态业务流请求消息建立、删除或修改业务的第一动态业务流；接收第二动态业务流请求消息；根据第二动态业务流请求消息建立、删除或修改业务的第二动态业务流；如果建立第二动态业务流失败，则回收为第一动态业务流分配的资源；如果删除第二动态业务流失败，则回收为第二动态业务流分配的资源；如果修改第二动态业务流失败，则回收为第一动态业务流分配的附加资源。本发明实施例提供的方法及基站，在一条动态业务流处理操作成功而另外一条动态业务流处理操作失败的情况下，避免始终保留分配给其中一条动态业务流的资源，从而避免了资源的浪费。
文档编号H04W16/10GK101808331SQ20101014214
公开日2010年8月18日 申请日期2010年4月2日 优先权日2010年4月2日
发明者广远伟 申请人:华为技术有限公司