CN103888928B - 一种业务策略控制方法及系统 - Google Patents

Abstract

本申请公开了一种业务策略控制方法及系统，方法包括：业务管理设备接收用户设备发送的业务访问请求，业务访问请求携带第一业务流信息和用户设备的用户标识；业务管理设备根据业务订购信息集合以及第一业务流信息和用户标识，判断用户是否订购了第一业务流信息对应的业务，业务订购信息集合中包括用户标识与订购业务的对应关系；业务管理设备若判断出用户订购了第一业务流信息对应的业务，则向PCRF发送携带有第一业务流信息和用户标识的更新策略请求，其中，更新策略请求用于请求PCRF将第一业务流信息对应的业务的策略信息发送给GGSN，以使GGSN根据策略信息对第一业务流信息对应的业务执行策略控制。

Description

一种业务策略控制方法及系统

技术领域

本发明涉及通信技术领域，特别涉及一种业务策略控制方法及系统。

背景技术

近年来，随着智能终端与移动互联网的迅猛发展，互联网企业利用运营商的宽带网络发展自己的业务，不少OTT（Over The Top，越过头顶）服务商提供定向流量包形式的业务，OTT服务器，是指互联网企业越过运营商，发展基于开放互联网的各种视频及数据服务业务，强调服务与物理网络的无关性。互联网企业利用电信运营商的宽带网络发展自己的业务，如某些聊天软件都是OTT。不少OTT服务商直接面向用户提供服务和计费，使运营商沦为单纯的“传输管道”，根本无法触及管道中传输的巨大价值。定向流量包，是以IP（Internet Protocol，网络之间互连的协议）、URL（Uniform Resource Locator，统一资源定位符）等方式推出的专用的流量包，用户在上网的时候，根据定向流量包的规则，针对这些特殊的IP、URL的流量在定向流量包中单独进行计费，超出定向流量包范围后再到通用流量包中计费。定向流量包一般分两种：前向型定向流量包：面向使用者也就是最终用户进行收费，包括点播、包月等，这类型的定向流量包主要是针对视频、游戏、社交等内容性业务的用户。后向型定向流量包：也称为流量800，面向OTT服务商或者互联网网站进行收费，所有浏览该网站的用户均免费或者享受流量折扣。

目前访问定向流量包形式的业务是采用了“集中配置”的方案，由客户关系管理设备，如CRM（Customer Relationship Management，客户关系管理）或PRM（PartnerRelationship Management，合作伙伴关系管理）等，负责对OTT服务器提供的所有业务地址列表进行审核，审核完成后，将所有的业务地址列表集中写入GGSN（Gateway GPRS SupportNode，网关支撑节点）中。由GGSN通过查找业务地址列表来寻找到对应的业务，并对该业务执行策略控制。

而GGSN扩展性差，以GGSN为核心的策略控制在执行过程中较易出现瓶颈。若GGSN在策略执行的过程出错则会影响所有业务的使用，后果较为严重。

因此，现有技术存在的技术问题是：以GGSN为核心的策略控制在执行过程中易出错且后果严重。

发明内容

本发明提供一种业务策略控制方法及系统，用以解决现有技术中存在的以GGSN为核心的策略控制在执行过程中易出错且后果严重的技术问题。

在本发明的第一方面，描述了一种业务策略控制方法，所述方法应用于业务管理设备，所述方法包括：业务管理设备接收用户设备发送的业务访问请求，所述业务访问请求携带第一业务流信息和所述用户设备的用户标识；所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，所述业务订购信息集合中包括用户标识与订购业务的对应关系；所述业务管理设备若判断出所述用户订购了所述第一业务流信息对应的业务，则向策略与计费执行功能设备PCRF发送携带有所述第一业务流信息和所述用户标识的更新策略请求，其中，所述更新策略请求用于请求所述PCRF将所述第一业务流信息对应的业务的策略信息发送给网管支撑节点GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

结合第一方面，在第一种可能的实现方式中，所述第一业务流信息和所述用户标识由所述用户设备在发送所述业务访问请求，并判断出所述第一业务流信息与业务集合对应的业务流信息匹配之后上报；或者所述第一业务流信息和所述用户标识是由越过头顶OTT服务器在判断出所述第一业务流信息与所述业务集合对应的业务流信息匹配之后上报。

结合第一种可能的实现方式，在第二种可能的实现方式中，所述业务集合中的业务的生成过程包括：所述业务管理设备接收OTT服务器发送的所述业务对应的业务地址列表，并对所述业务对应的业务地址列表进行审核；所述业务管理设备对所述业务对应的业务地址列表审查完成后，将所述业务对应的业务地址列表发送给客户关系管理设备，以使所述客户关系管理设备基于所述业务对应的业务地址列表生成所述业务，并且将所述业务发送给所述PCRF，业务管理设备；所述业务管理设备接收所述客户关系管理设备发送的所述业务，并将所述业务发送给所述用户设备和/或所述OTT服务器。

结合第一方面，在第三种可能的实现方式中，所述业务订购信息集合中的业务订购信息是由客户关系管理设备根据用户设备发送的业务对应的订购请求生成并发送给所述业务管理设备的，并且所述客户关系管理设备还会将所述业务订购信息发送给PCRF；所述业务管理设备接收所述业务订购信息。

结合第一方面，第一种可能的实现方式，第二种可能的实现方式，第三种可能的实现方式，在第四种可能的实现方式中，所述第一业务流信息具体为五元组信息，所述五元组信息包括：源地址、源端口、目标地址、目标端口，以及协议号。

结合第一方面，第一种可能的实现方式，第二种可能的实现方式，第三种可能的实现方式，第四种可能的实现方式，在第五种可能的实现方式中，所述策略控制具体包括计费策略控制，或服务质量策略控制。

结合第一方面，在第六种可能的实现方式中，所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，具体包括：根据所述用户标识在所述业务订购信息集合中查询所述用户标识订购的业务；判断所述第一业务流信息中的业务地址是否存在于用户标识订购的业务的业务地址列表中。

在本发明的第二方面，描述了一种业务管理设备，包括：接收单元，用于收用户设备发送的业务访问请求，所述业务访问请求携带第一业务流信息和所述用户设备的用户标识；判断单元，用于根据所述接收单元接收的业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，所述业务订购信息集合中包括用户标识与订购业务的对应关系；发送单元，用于所述判断单元判断出所述用户订购了所述第一业务流信息对应的业务时，则向PCRF发送携带有所述第一业务流信息和所述用户标识的更新策略请求，其中，所述更新策略请求用于请求所述PCRF将所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

结合第二方面，在第一种可能的实现方式中，所述第一业务流信息和所述用户标识由所述用户设备在发送所述业务访问请求，并判断出所述第一业务流信息与业务集合对应的业务流信息匹配之后上报的；或者所述第一业务流信息和所述用户标识是由OTT服务器在判断出所述第一业务流信息与所述业务集合对应的业务流信息匹配之后上报。

结合第一种可能的实现方式，在第二种可能的实现方式中，所述业务集合中的业务的生成过程包括：所述接收单元接收OTT服务器发送的所述业务对应的业务地址列表，审核单元对所述业务对应的业务地址列表进行审核；当所述审核单元对所述业务对应的业务地址列表审查完成后，发送单元将所述业务对应的业务地址列表发送给客户关系管理设备，以使所述客户关系管理设备基于所述业务对应的业务地址列表生成所述业务，并且将所述业务发送给所述PCRF，业务管理设备；所述接收单元接收所述客户关系管理设备发送的所述业务，并将所述业务发送给所述用户设备和/或所述OTT服务器。

结合第二方面，在第三种可能的实现方式中，所述业务订购信息集合中的业务订购信息是由客户关系管理设备根据用户设备发送的业务对应的订购请求生成并发送给所述业务管理设备的，并且所述客户关系管理设备还会将所述业务订购信息发送给PCRF；所述接收单元接收所述客户关系管理设备发送的所述业务订购信息。

结合第二方面，第一种可能的实现方式，第二种可能的实现方式，第三种可能的实现方式，在第四种可能的实现方式中，所述第一业务流信息具体为五元组信息，所述五元组信息包括：源地址、源端口、目标地址、目标端口，以及协议号。

结合第二方面，第一种可能的实现方式，第二种可能的实现方式，第三种可能的实现方式，第四种可能的实现方式，在第五种可能的实现方式中，所述策略控制具体包括计费策略控制，或服务质量策略控制。

结合第二方面，在第六种可能的实现方式中，所述判断单元具体用于根据所述接收单元接收的所述用户标识在所述业务订购信息集合中查询所述用户标识订购的业务；判断所述第一业务流信息中的业务地址是否存在于用户标识订购的业务的业务地址列表中。

在本发明的第三方面，描述了一种业务策略控制方法，所述方法应用于PCRF，所述方法包括：PCRF接收业务管理设备发送的携带有第一业务流信息和用户标识的更新策略请求，所述更新策略请求是所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断出所述用户订购了所述第一业务流信息对应的业务之后发送的，其中，所述业务订购信息集合中包括用户标识与订购业务的对应关系；PCRF基于所述更新策略请求，获取所述第一业务流信息对应的策略信息；PCRF将所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

结合第三方面，在第一种可能的实现方式中，所述方法还包括：PCRF接收客户关系管理设备发送的业务，其中所述业务是客户关系管理设备基于业务对应的业务地址列表生成的，其中所述业务对应的业务地址列表是由OTT服务器发送，并由所述业务管理设备审核之后发送给客户关系管理设备的。

在本发明的第四方面，描述了一种PCRF，包括：接收模块，用于接收业务管理设备发送的携带有第一业务流信息和用户标识的更新策略请求，所述更新策略请求是所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断出所述用户订购了所述第一业务流信息对应的业务之后发送的，其中，所述业务订购信息集合中包括用户标识与订购业务的对应关系；获取模块，用于基于接收模块接收的所述更新策略请求，获取所述第一业务流信息对应的策略信息；发送模块，用于将所述获取模块获取的所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

结合第四方面，在第一种可能的实现方式中，所述接收模块还用于接收客户关系管理设备发送的业务，其中所述业务是客户关系管理设备基于业务对应的业务地址列表生成的，其中所述业务对应的业务地址列表是由OTT服务器发送，并由所述业务管理设备审核之后发送给客户关系管理设备的。

在本发明的第五方面，描述了一种业务处理系统，所述系统包括：所述业务管理设备，用于接收用户设备发送的业务访问请求，所述业务访问请求携带第一业务流信息和所述用户设备的用户标识；根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，所述业务订购信息集合中包括用户标识与订购业务的对应关系；若判断出所述用户订购了所述第一业务流信息对应的业务，则向PCRF发送携带有所述第一业务流信息和所述用户标识的更新策略请求，所述更新策略请求用于请求所述PCRF将所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制；PCRF，用于接收业务管理设备发送的携带有第一业务流信息和用户标识的更新策略请求；基于所述更新策略请求，获取所述第一业务流信息对应的策略信息；将所述第一业务流信息对应的策略信息将发送给GGSN；所述GGSN，用于根据所述策略信息对所述用户设备所进行的第一业务流信息对应的业务执行策略控制。

上述技术方案中的一个或多个技术方案，具有如下技术效果或优点：

（1），在本发明中，在用户设备访问业务时，使用业务管理设备来确认用户设备订购的业务。然后向PCRF发送更新策略请求，以使PCRF查找用户设备订购的业务的策略信息，然后发送给GGSN执行策略控制。进而将原本以“GGSN”的策略控制分担到业务管理设备和PCRF，缓解GGSN的压力，并进一步减小GGSN出错的几率。

（2），在本发明中，将业务集合对应的业务流信息存储在用户设备中，使得用户设备在发送业务访问请求，并且使用业务集合对应的业务流信息匹配第一业务流信息之后，再向业务管理设备上报第一业务流信息。避免了在GGSN中执行该匹配的步骤，进一步缓解了GGSN的压力。

附图说明

图1为本发明实施例中业务处理系统的示意图；

图2为本发明实施例中业务生成过程的方法流程图；

图3为本发明实施例中业务订购过程的方法流程图；

图4为本发明实施例中业务访问过程的方法流程图；

图5为本发明实施例中的业务管理设备的功能框图；

图6为本发明实施例中的PCRF的功能框图；

图7为本发明实施例中业务生成的过程图；

图8为本发明实施例中业务使用的方法流程图。

具体实施方式

为了解决现有技术中以GGSN为核心的策略控制在执行过程中易出错且后果严重的技术问题，本发明实施例提出了一种业务策略控制方法及系统。

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

本文中描述的技术可用于各种通信系统，例如当前2G（第二代移动通信技术）通信系统，3G（第三代移动通信技术）通信系统和下一代通信系统，例如全球移动通信系统（GSM，Global System for Mobile communications），码分多址（CDMA，Code Division MultipleAccess）系统，时分多址（TDMA，Time Division Multiple Access）系统，宽带码分多址（WCDMA，Wideband Code Division Multiple Access Wireless），频分多址（FDMA，Frequency Division Multiple Addressing）系统，正交频分多址（OFDMA，OrthogonalFrequency-Division Multiple Access）系统，单载波FDMA（SC-FDMA）系统，通用分组无线业务（GPRS，General Packet Radio Service）系统，长期演进（LTE，Long Term Evolution）系统，以及其他此类通信系统。

本发明中涉及的用户设备包括但不限于是无线终端，无线终端指的是向用户提供语音和/或数据连通性的设备，具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备。例如，无线终端可以是移动终端，如移动电话（或称为“蜂窝”电话）和具有移动终端的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语言和/或数据。

在本发明的第一个实施例中，首先介绍一种业务处理系统。

下面请参看图1，是本发明实施例中的业务处理系统的功能框图，业务管理系统在图1中标号为01。该系统包括业务管理设备1，PCRF2，GGSN3，OTT服务器4，CRM5（为便于理解，本发明中的客户关系管理设备将使用CRM为例进行说明，PRM和CRM类似，不再赘述）。除此之外，还包括计费系统6。

本发明的业务处理系统为业务生成、业务订购、业务使用提供硬件基础，下面分别介绍业务处理系统中各设备在这三个过程中的具体功能。

首先介绍在业务生成过程中业务处理系统中的各个设备的具体功能，在具体的实施过程中，将以业务集合中的业务的生成过程为例对业务处理系统中各个设备的功能进行介绍，而这些设备在其他的业务生成过程中具有类似的功能，在此本发明不再赘述。

业务管理设备1，用于接收OTT服务器4发送的业务对应的业务地址列表，并对所述业务对应的业务地址列表进行审核；对所述业务对应的业务地址列表审查完成后，将所述业务对应的业务地址列表发送给CRM5，以使所述CRM5基于所述业务对应的业务地址列表生成业务，并且将所述业务发送给所述PCRF2，业务管理设备1；另外，业务管理设备1还用于接收所述CRM5发送的所述业务，并将所述业务发送给所述用户设备7和/或所述OTT服务器4。

CRM5，用于基于所述业务的业务地址列表生成所述业务，并且将所述业务发送给所述PCRF2。

下面结合图1和图2，对业务的生成过程进行说明，此时的业务生成过程实质是单个业务的生成过程，其他业务的生成过程类似，图2为本发明实施例中业务生成过程的方法流程图，假设业务使用业务A举例。

OTT服务器4发送业务A对应的业务地址列表给业务管理设备1。该业务A属于定向流量的范畴，一般都是以定向流量包的形式提供给用户使用。业务地址列表中列出了该业务A所有的业务地址，任一用户设备7访问该业务地址均能够使用业务A。而业务地址列表包括但不限于是IP地址列表。

业务管理设备1接收OTT服务器4业务A对应的业务地址列表之后，对业务A对应的业务地址列表进行审核。

业务管理设备1审核完毕，发送业务A对应的业务地址列表给CRM5。

CRM5基于业务A对应的业务地址列表生成业务A。此时的业务A包含了四个方面的内容：业务A对应的业务地址列表，业务A对应的业务名称，业务A对应的业务流量大小，以及业务A对应的业务费用。具体的内容请参看表1，这四个方面的内容统称为业务A对应的业务流信息。

表1

CRM5将业务A发送给PCRF2和业务管理设备1。具体的，在将业务A发送给PCRF2时，CRM5具体会将业务A对应的“业务地址列表和业务费用”这两项内容发送给PCRF2进行存储。而由于CRM5在生成业务后都会将对应的“业务地址列表和业务费用”发送给PCRF2，因此，PCRF2存储了业务集合对应的“业务地址列表和业务费用”。而在发送业务A给业务管理设备1时，则发送了业务A对应的“业务名称和业务地址列表”。而由于CRM5在每生成一个业务都会想业务管理设备1发送该业务对应的业务流信息。因此，对于业务管理设备1来说，存储的也是业务集合对应的业务流信息。

此外，CRM5将业务A发送给计费系统6。在将业务A发送给计费系统6时，CRM5具体会将业务A对应的“业务流量大小和业务费用”发送给计费系统6，以便于后续GGSN3向计费系统6申请流量配额时，计费系统6能够以业务集合对应的业务流信息为基础，为GGSN3分配流量。对于计费系统6来说，和业务管理设备1类似，实际上存储的也是业务集合对应的业务流信息。

在上面的实施例中，在每个业务生成之后，CRM5都会将其对应的业务流信息发送给PCRF2与计费系统6存储，以替代在GGSN3上存储。因此，GGSN3上不用预先配置业务集合对应的业务流信息，尤其是每个业务对应的业务地址列表和每个业务对应的业务流量大小，能够缓解GGSN3的业务压力。

业务管理设备1基于业务A生成SDK（Software Development Kit，软件开发工具包）和/或API（Application Programming Interface，应用程序接口）。SDK和API中都携带了业务A对应的业务流信息。SDK是一些被用来为特定的软件包、软件框架、硬件平台、操作系统等创建应用软件的开发工具的集合，集成在用户设备7或者用户设备7中的某个应用程序中。它可以简单的为某个程序设计语言提供一些文件，但也可能包括能与某种嵌入式系统通讯的复杂的硬件。SDK还经常包括示例代码、支持性的技术注解或者其他的为基本参考资料澄清疑点的支持文档。当业务管理设备1基于业务A生成SDK之后，则会将SDK发送给用户设备7，以便用户设备7后续调用。API是计算机操作系统或程序库提供给应用程序调用使用的代码，其主要目的是让应用程序开发人员得以调用一组例程功能，而无须考虑其底层的源代码为何、或理解其内部工作机制的细节。API本身是抽象的，它仅定义了一个接口，而不涉入应用程序如何实现的细节。因此，业务管理设备1将业务A对应的业务流信息打包成API之后，会将API发送给OTT服务器4，以便后续OTT服务器4调用。以上仅是以用户A为例介绍SDK和API，在实际情况中，SDK和API携带的应该是业务集合对应的业务流信息。

进一步的，当业务集合生成之后，用户设备7便可以任意订购业务集合中的业务。而业务集合囊括了所有业务对应的业务流信息，下面请参表2，表2中就是业务集合的内容，业务集合使用了业务A和业务B这两种业务举例，并列举了每个业务各自对应的业务流信息。

表2

在用户订购业务的过程中，业务处理系统中的各设备的具体功能如下：

CRM5，用于接收所述用户设备7发送的业务对应的订购请求之后生成业务订购信息，并将所述业务订购信息发送给所述PCRF2。

PCRF2，用于接收CRM5发送的所述业务和所述业务订购信息，并用于基于所述更新策略请求，获取所述第一业务流信息对应的策略信息。而在本发明实施例中，第一业务流信息包括但不限于是五元组信息，所述五元组信息包括：源地址、源端口、目标地址、目标端口，以及协议号；所述五元组信息的源地址和源端口由所述GGSN3分配。

下面结合图1和图3，对用户订购业务的过程进行说明，图3是本发明实施例中业务订购过程的方法流程图。

假设以用户设备7订购业务A为例，具体的订购过程如下：

用户设备7发送业务A对应的订购请求给CRM5。在具体的实施过程中，用户设备7在订购业务A时，可以通过掌厅、网厅、营业厅等渠道提交订购请求。

CRM5基于业务订购请求生成业务A的订购信息。此订购信息表明了用户标识和业务A的订购关系。用户标识具体可以是手机号码、用户账号等等。

CRM5通知用户设备7业务A的订购成功。

CRM5将业务A的订购信息发送给业务管理设备1。

业务管理设备1将业务A的订购信息发送给OTT服务器4。

CRM5将业务A的订购信息发送给PCRF2。

CRM5将业务A的订购信息发送给计费系统6，以便于GGSN3针对业务A向计费系统6申请流量配额时，则会以业务A的订购信息为基础，向GGSN3分配业务A对应的流量。

上面的实施例描述的是用户订购业务的过程，而在实际的过程中，用户A可以订购多个业务，此时CRM5会接收用户设备7订购业务集合中其他业务（例如业务B）的订购请求，对应生成业务B的订购信息，并同步业务B的订购信息给业务处理系统中的其他设备。因此，业务处理系统中的各个设备在存储业务订购信息时，实际上存储的是业务订购信息集合。业务订购信息集合表征了用户设备7在业务集合中订购的多个业务，且业务订购信息集合包括用户标识与订购业务的对应关系。假设某用户A订购了业务A和业务B。那么此时业务订购信息集合中具体包括了用户A对应的用户标识与业务A、业务B的对应关系。当然，业务订购信息集合中也包含了其他用户标识和业务的对应关系，下面请参看表3，描述了用户标识和业务的对应关系（此时的用户标识使用手机号码为例）。在表3中，列举了多个被订购的业务。每个用户标识对应的业务栏中，带“●”符号的表示该用户标识订购了改业务，两者具有订购关系。每一个业务都有对应的业务流信息，即各自对应的业务地址列表、业务名称、业务流量大小、和业务费用。

用户标识	业务A	业务B	业务C	……
					13116356448	●	●
15982039852		●	●
					15841203650	●		●

表3

当用户订购业务之后，用户可以随意使用订购的业务。

在用户使用订购业务的过程中，业务处理系统中的各设备的具体功能如下：

业务管理设备1，用于接收用户设备7发送的业务访问请求，业务访问请求携带第一业务流信息和用户设备7的用户标识；根据业务订购信息集合以及第一业务流信息和用户标识，判断用户是否订购了第一业务流信息对应的业务，业务订购信息集合中包括用户标识与订购业务的对应关系；若判断出用户订购了第一业务流信息对应的业务，则向PCRF2发送携带有第一业务流信息和用户标识的更新策略请求，更新策略请求用于请求PCRF2将第一业务流信息对应的业务的策略信息发送给GGSN3，以使GGSN3根据策略信息对第一业务流信息对应的业务执行策略控制。策略控制具体包括计费策略控制，或服务质量策略控制。

PCRF2，用于接收业务管理设备1发送的携带有第一业务流信息和用户标识的更新策略请求；基于更新策略请求，获取第一业务流信息对应的策略信息；将第一业务流信息对应的策略信息将发送给GGSN3。

GGSN3，用于根据策略信息对用户设备7所进行的第一业务流信息对应的业务执行策略控制。

下面结合图1和图4，对业务的访问过程进行说明，图4是本发明实施例中业务访问过程的方法流程图。

当用户访问订购的某类业务（此处以用户使用业务A为例）时，具体的访问过程如下：

用户设备7基于用户的操作生成业务访问请求。用户的操作是开启业务A的开启操作。

GGSN3给用户设备7分配源地址，源端口，作为五元组信息的部分内容，此时的五元组信息包括：源地址、源端口、目标地址、目标端口，以及协议号。五元组信息中的源地址就是GGSN3为用户设备7临时分配的源地址，而目标地址是业务A提供的业务地址列表中的地址。在用户结束该类业务的使用时，GGSN3临时分配的源地址和端口号不会改变，用来避免用户设备7在访问业务时防火墙为用户设备7分配源地址和源端口，进而导致业务管理设备1从防火墙获取的五元组信息与从GGSN3处获取的五元组信息不一致的问题出现，从而保证在用户设备7访问该类业务的过程中，都使用GGSN3分配的五元组信息，保持信息的一致性。而本发明中的五元组信息隶属第一业务流信息，第一业务流信息包括但不限于是五元组信息。为了便于描述，本实施例使用五元组信息进行描述。

用户设备7内置的SDK会判断五元组信息与业务集合对应的业务流信息是否匹配，并在匹配之后上报五元组信息和用户标识给业务管理设备1。

而业务集合是多类业务的统称。业务集合对应的业务流信息具体包括四大类：业务地址列表，业务名称，业务流量大小，以及业务费用，而业务地址列表包含但不限于是IP地址列表。业务集合的内容具体请参看表2中列举的内容。

而在具体的判断过程中，SDK会将五元组信息中的目的地址与业务地址列表中的业务地址进行比对。若业务地址列表里面有目的地址，说明用户当前访问的地址包含在业务A对应的业务地址列表里，因此SDK会上报五元组信息和用户标识给业务管理设备1。而用户标识包括但不限于是手机号码、用户账号等等。

在本发明的另一个实施例中，当GGSN3给用户设备7分配源地址，源端口之后，OTT服务器4中的API则会判断第一业务流信息与业务集合对应的业务流信息是否匹配，并在匹配之后上报第一业务流信息和用户标识给业务管理设备1。此处业务对应的业务流信息的具体内容请参看表1，并且此处的判断方式和用户设备7中SDK的判断方式类似，在此本发明不再赘述。

业务集合对应的业务流信息存储在用户设备7或OTT服务器4中，使得用户设备7或OTT服务器4在匹配第一业务流信息并在匹配成功之后，上报第一业务流信息给业务管理设备1。避免了在GGSN3中执行该匹配的步骤，进一步缓解了GGSN3的压力。

业务管理设备1根据业务订购信息集合以及第一业务流信息和用户标识，判断用户是否订购了第一业务流信息对应的业务。业务订购信息集合中包括用户标识与订购业务的对应关系，在具体的判断过程中，业务管理平台根据用户标识查询用户订购的具体业务，然后查询第一业务流信息中的目的地址是否包含在订购的这些业务的业务地址列表里面，此时若查询到第一业务流信息中的目的地址包含在业务A对应的业务地址列表里面，就表示订购了业务A。

若判断出用户订购了业务A，则向PCRF2发送更新策略请求。更新策略请求中携带五元组信息和用户标识，更新策略请求用于请求PCRF2将业务A的策略信息发送给GGSN3，以使GGSN3根据业务A的策略信息对业务A执行策略控制。在发送更新策略请求的过程中，业务管理设备1通过扩展接口传递“五元组信息，更新策略请求”给PCRF2。而策略控制具体包括计费策略控制或服务质量策略控制。若以计费策略控制为例，那么此时的更新策略请求具体就是更新计费策略的请求。以下就使用计费策略控制为例进行描述，服务质量策略控制类似，本发明不再赘述。

PCRF2接受到更新计费策略的请求之后，则根据用户标识、五元组信息查找到业务A的业务费用，生成策略信息发送个GGSN3，策略信息中携带内容包括：业务A的业务费用，五元组信息，用户标识。

PCRF2下发策略信息给GGSN3，

GGSN3通过用户标识和业务A的业务费用，向计费系统6申请流量配额。

计费系统6根据用户标识和业务A的业务费用分配流量给GGSN3。

GGSN3根据流量配额，用户标识，五元组信息形成计费通道，完成业务A的计费。

在本发明的第二个实施例中，描述了一种业务管理设备1。

下面请参看图5，是本发明实施例中的业务管理设备1的功能框图。业务管理设备1具体包括：接收单元501，判断单元502，发送单元503，审核单元504。在执行业务处理的过程中，例如业务生成、订购、使用的过程中，业务管理设备1具有不同的功能，下面将分别介绍在这三个过程中业务管理设备1的功能。

首先描述在业务生成的过程中业务管理设备1的具体功能，而在具体的实施过程中，将以业务集合中的业务的生成过程为例对业务管理设备1的功能进行介绍，此时的业务生成过程实质上是单个业务的生成过程。其他的业务生成过程类似，在此本发明不再赘述。

业务集合中的业务的生成过程如下：

接收单元501接收OTT服务器4发送的所述业务对应的业务地址列表，审核单元504对所述业务对应的业务地址列表进行审核。业务对应的业务地址列表包括但不限于是IP地址列表。以业务A为例，业务A对应有IP地址列表，用户设备7若订购了业务A，便能够获得分配的业务A对应的IP地址，通过访问分配的IP地址，便可以访问业务A。

当所述审核单元504对所述业务对应的业务地址列表审查完成后，发送单元503将所述业务对应的业务地址列表发送给CRM5，以使所述CRM5基于所述业务对应的业务地址列表生成所述业务，并且将所述业务发送给所述PCRF2，业务管理设备1。

所述接收单元501接收所述CRM5发送的所述业务，并将所述业务发送给所述用户设备7和/或所述OTT服务器4。

而在业务订购的过程中，是由CRM5根据用户设备7发送的业务对应的订购请求生成业务订购信息，业务订购信息中包含了用户标识和业务之间的对应关系，表征了用户设备7具体订购了哪类业务。而在实际的情况中，同一个用户还可以订购其他的业务，那么此时生成的便是业务订购信息集合。而业务订购信息集合中的业务订购信息是由CRM5根据用户设备7发送的业务对应的订购请求生成并发送给所述业务管理设备1的，并且所述CRM5还会将所述业务订购信息发送给PCRF2。假设某用户A订购了业务A和业务B。那么此时业务订购信息集合中具体包括了用户A对应的用户标识与业务A、业务B的对应关系。当然，业务订购信息集合中也包含了其他用户标识和业务的对应关系，业务订购信息集合的内容请参看表3，在此本发明不再赘述。而对于业务管理设备1来说，只需接收单元501接收所述CRM5发送的所述业务订购信息即可。

下面介绍在业务使用的过程中业务管理设备1的具体功能。

接收单元501，用于收用户设备7发送的业务访问请求。业务访问请求携带第一业务流信息和所述用户设备7的用户标识。第一业务流信息包括但不限于是五元组信息，所述五元组信息包括：源地址、源端口、目标地址、目标端口，以及协议号。而所述五元组信息的源地址和源端口由所述GGSN3分配。用户标识可以是手机号码、用户账号等等。在本发明的另一个实施例中，所述第一业务流信息和所述用户标识由所述用户设备7在发送所述业务访问请求，并判断出所述第一业务流信息与业务集合对应的业务流信息匹配之后上报的。或者所述第一业务流信息和所述用户标识是由OTT服务器4在判断出所述第一业务流信息与所述业务集合对应的业务流信息匹配之后上报。

判断单元502，用于根据所述接收单元501接收的业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务。在具体的实施过程中，业务订购信息集合是所有用户设备7订购的业务的统称。另外，业务订购信息集合包括用户标识与订购业务的对应关系。

发送单元503，用于所述判断单元502判断出所述用户订购了所述第一业务流信息对应的业务时，则向PCRF2发送携带有所述第一业务流信息和所述用户标识的更新策略请求，其中，所述更新策略请求用于请求所述PCRF2将所述第一业务流信息对应的业务的策略信息发送给GGSN3，以使所述GGSN3根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。策略控制具体包括计费策略控制，或服务质量策略控制。

所述判断单元502具体用于根据所述接收单元501接收的所述用户标识在所述业务订购信息集合中查询所述用户标识订购的业务；判断所述第一业务流信息中的业务地址是否存在于用户标识订购的业务的业务地址列表中。

在本发明的第三个实施例中，介绍了一种PCRF2。

下面请参看图6，是本发明实施例中的PCRF2的功能框图。PCRF2具体包括：接收模块601，获取模块602，发送模块603，

接收模块601，用于接收业务管理设备1发送的携带有第一业务流信息和用户标识的更新策略请求，所述更新策略请求是所述业务管理设备1根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断出所述用户订购了所述第一业务流信息对应的业务之后发送的，其中，所述业务订购信息集合中包括用户标识与订购业务的对应关系；

获取模块602，用于基于接收模块601接收的所述更新策略请求，获取所述第一业务流信息对应的策略信息；

发送模块603，用于将所述获取模块602获取的所述策略信息发送给GGSN3，以使所述GGSN3根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

而在业务生成的过程中，PCRF2的所述接收模块601还用于接收CRM5发送的业务，其中所述业务是CRM5基于业务对应的业务地址列表生成的，其中所述业务对应的业务地址列表是由OTT服务器4发送，并由所述业务管理设备1审核之后发送给CRM5的。

在本发明的第四个实施例中，描述了一种业务策略控制方法。

在具体的实施过程中，该方法应用于业务管理设备，业务策略控制方法包含了业务生成、订购、使用这三个方面，下面将从这三个方面介绍具体的策略控制过程。

下面请参看图7，是业务生成的过程图，而其他的业务生成过程类似，在此本发明不再赘述。

S701，所述业务管理设备接收OTT服务器发送的所述业务对应的业务地址列表，并对所述业务对应的业务地址列表进行审核。而业务的业务地址列表包括但不限于是IP地址列表。

S702，所述业务管理设备对所述业务对应的业务地址列表审查完成后，将所述业务对应的业务地址列表发送给CRM，以使所述CRM基于所述业务对应的业务地址列表生成所述业务，并且将所述业务发送给所述PCRF，业务管理设备。在具体的实施过程中，假设业务以业务A为例，CRM基于业务A对应的业务地址列表生成业务A。此时的业务A包含了四个方面的内容：业务A对应的业务地址列表，业务A对应的业务名称，业务A对应的业务流量大小，以及业务A对应的业务费用。具体的内容请参看表1，这四个方面的内容统称为业务A对应的业务流信息。CRM将业务A发送给PCRF和业务管理设备。具体的，在将业务A发送给PCRF时，CRM具体会将业务A对应的“业务地址列表和业务费用”这两项内容发送给PCRF进行存储。而由于CRM在生成业务后都会将对应的“业务地址列表和业务费用”发送给PCRF，因此，PCRF存储了业务集合对应的“业务地址列表和业务费用”。而在发送业务A给业务管理设备时，则发送了业务A对应的“业务名称和业务地址列表”。而由于CRM在每生成业务都会想业务管理设备发送业务对应的业务流信息。因此，对于业务管理设备来说，存储的也是业务集合对应的业务流信息。此外，CRM将业务A发送给计费系统。在将业务A发送给计费系统时，CRM具体会将业务A对应的“业务流量大小和业务费用”发送给计费系统，以便于后续GGSN向计费系统申请流量配额时，计费系统能够以业务集合对应的业务流信息为基础，为GGSN分配流量。对于计费系统来说，和业务管理设备类似，实际上存储的也是业务集合对应的业务流信息。在上面的实施例中，在业务的生成之后，CRM都会将其对应的业务流信息发送给PCRF与计费系统存储，以替代在GGSN上存储。因此，GGSN上不用预先配置业务集合对应的业务流信息，尤其是每个业务对应的业务地址列表和每个业务对应的业务流量大小，能够缓解GGSN的业务压力。

S703，所述业务管理设备接收所述CRM发送的所述业务，并将所述业务发送给所述用户设备和/或所述OTT服务器。在发送业务A的过程中，业务管理设备具体是基于业务A生成SDK和/或API，当业务管理设备基于业务A生成SDK之后，则会将SDK发送给用户设备。当业务管理设备将业务A对应的业务流信息打包成API之后，会将API发送给OTT服务器。以上仅是以用户A为例介绍SDK和API，在实际情况中，SDK和API携带的应该是业务集合对应的业务流信息。

进一步的，当业务集合生成之后，用户设备便可以任意订购业务集合中的业务。而业务集合囊括了所有业务对应的业务流信息，业务集合的内容请参表2，在此本发明不再赘述。

进一步的，在用户订购业务的过程中，具体是CRM根据用户设备发送的业务对应的订购请求生成并发送给所述业务管理设备的，并且所述CRM还会将所述业务订购信息发送给PCRF，此时，对于用户管理设备来说，仅需接收所述业务订购信息。并转发给订购信息给OTT服务器即可。当然在实际情况中，用户可以订购多个业务，而每个业务都具有各自的业务订购信息，因此，用户管理设备接收到可以是业务订购信息集合，并且也会将其转发给OTT服务器。

当用户订购业务之后，用户可以随意使用订购的业务。

下面请请参看图8，图8是业务使用的方法流程图。

S801，业务管理设备接收用户设备发送的业务访问请求，所述业务访问请求携带第一业务流信息和所述用户设备的用户标识。

S802，所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，所述业务订购信息集合中包括用户标识与订购业务的对应关系。而在具体的实施过程中，所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，具体包括：根据所述用户标识在所述业务订购信息集合中查询所述用户标识订购的业务；判断所述第一业务流信息中的业务地址是否存在于用户标识订购的业务的业务地址列表中。若判断出所述第一业务流信息中的业务地址存在于用户标识订购的业务的业务地址列表中，则表示所述用户订购了所述第一业务流信息对应的业务。

S803，所述业务管理设备若判断出所述用户订购了所述第一业务流信息对应的业务，则向PCRF发送携带有所述第一业务流信息和所述用户标识的更新策略请求，其中，所述更新策略请求用于请求所述PCRF将所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

本发明具体的实施过程中，业务访问请求具体由用户设备在接收用户操作后发送。而第一业务流信息和用户标识则是由用户设备在发送业务访问请求，并判断出第一业务流信息与业务集合对应的业务流信息匹配之后上报的。或者第一业务流信息和所述用户标识是由OTT服务器在判断出所述第一业务流信息与所述业务集合对应的业务流信息匹配之后上报。第一业务流信息包括但不限于是五元组信息，五元组信息包括：源地址、源端口、目标地址、目标端口，以及协议号，并且五元组信息的源地址和源端口是由GGSN分配。用户标识包括但不限于是手机号码、用户账号等等。具体来说，当用户设备发送业务访问请求之后，用户设备中内置的SDK则会判断第一业务流信息与业务集合对应的业务流信息是否匹配，在匹配之后则会上报第一业务流信息和用户标识给业务管理设备。具体的，业务集合是多类业务的统称。业务集合对应的业务流信息具体包括四大类：业务地址列表，业务名称，业务流量大小，以及业务费用，而业务地址列表包含但不限于是IP地址列表。业务集合的内容可参看表2，表2描述了业务集合对应的业务流信息的具体内容，并使用了业务A和业务B两种业务举例，在此本发明不再赘述。

具体的，SDK在判断第一业务流信息与业务集合对应的业务流信息是否匹配时，具体判断的是第一业务流信息包含的目的地址是否存在于业务集合对应的业务地址列表里。若存在，则上报第一业务流信息和用户标识给业务管理设备。

在本发明的另一个实施例中，第一业务流信息和所述用户标识是由OTT服务器在判断出所述第一业务流信息与所述业务集合对应的业务流信息匹配之后上报。此处业务对应的业务流信息的具体内容请参看表1，并且判断的方式和SDK判断的方式类似，在此本发明不再赘述。将业务集合对应的业务流信息存储在用户设备或OTT服务器中，使得用户设备或OTT服务器在匹配第一业务流信息并在匹配成功之后，上报第一业务流信息给业务管理设备。避免了在GGSN中执行该匹配的步骤，进一步缓解了GGSN的压力。

业务管理设备根据业务订购信息集合以及第一业务流信息和用户标识，判断用户是否订购了第一业务流信息对应的业务。业务订购信息集合中包括用户标识与订购业务的对应关系，在具体的判断过程中，业务管理平台根据用户标识查询用户订购的具体业务，然后查询第一业务流信息中的目的地址是否包含在订购的这些业务的业务地址列表里面，此时若查询到第一业务流信息中的目的地址包含在业务A对应的业务地址列表里面，就表示订购了业务A。

若判断出用户订购了业务A，则向PCRF发送携带有五元组信息和用户标识的更新策略请求。更新策略请求用于请求PCRF将业务A的策略信息发送给GGSN，以使GGSN根据业务A的策略信息对业务A执行策略控制。在发送更新策略请求的过程中，业务管理设备通过扩展接口传递“五元组信息，更新策略请求”给PCRF。而策略控制具体包括计费策略控制或服务质量策略控制。若以计费策略控制为例，那么此时的更新策略请求具体就是更新计费策略的请求。以下就使用计费策略控制为例进行描述，服务质量策略控制类似，本发明不再赘述。

PCRF接受到更新计费策略的请求之后，则根据用户标识、五元组信息查找到业务A的业务费用，生成策略信息发送个GGSN，策略信息中携带内容包括：业务A的业务费用，五元组信息，用户标识。

PCRF下发策略信息给GGSN，

GGSN通过用户标识和业务A的业务费用，向计费系统申请流量配额。

计费系统根据用户标识和业务A的业务费用分配流量给GGSN。

GGSN根据流量配额，用户标识，五元组信息形成计费通道，完成业务A的计费。

在本发明的另一个实施例中，也从PCRF的角度描述了业务策略控制方法。

在具体的实施过程中，PCRF会接收业务管理设备发送的携带有第一业务流信息和用户标识的更新策略请求，所述更新策略请求是所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断出所述用户订购了所述第一业务流信息对应的业务之后发送的，其中，所述业务订购信息集合中包括用户标识与订购业务的对应关系；PCRF基于所述更新策略请求，获取所述第一业务流信息对应的策略信息；PCRF将所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

在本发明的另一个实施例中，PCRF还会接收CRM发送的业务，其中所述业务是CRM基于业务对应的业务地址列表生成的，其中所述业务对应的业务地址列表是由OTT服务器发送，并由所述业务管理设备审核之后发送给CRM的。

通过本发明的一个或多个实施例，可以实现如下技术效果：

（1），在本发明中，在用户设备访问业务时，使用业务管理设备来寻找用户设备订购的业务。然后向PCRF发送更新策略请求，以使PCRF查找用户设备订购的业务的策略信息，然后发送给GGSN执行策略控制。进而将原本以“GGSN”的策略控制分担到业务管理设备和PCRF，缓解GGSN的压力，并进一步减小GGSN出错的几率。

（2），在本发明中，将业务集合对应的业务流信息存储在用户设备中，使得用户设备在发送业务访问请求，并且使用业务集合对应的业务流信息匹配第一业务流信息之后，再向业务管理设备上报第一业务流信息。避免了在GGSN中执行该匹配的步骤，进一步缓解了GGSN的压力。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器，CD-ROM，光学存储器等）上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (19)

1.一种业务策略控制方法，所述方法应用于业务管理设备，其特征在于，所述方法包括：

业务管理设备接收用户设备发送的业务访问请求，所述业务访问请求携带第一业务流信息和所述用户设备的用户标识；

所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，所述业务订购信息集合中包括用户标识与订购业务的对应关系；

所述业务管理设备若判断出所述用户订购了所述第一业务流信息对应的业务，则向策略与计费规则功能设备PCRF发送携带有所述第一业务流信息和所述用户标识的更新策略请求，其中，所述更新策略请求用于请求所述PCRF将所述第一业务流信息对应的业务的策略信息发送给网关支撑节点GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

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

所述第一业务流信息和所述用户标识由所述用户设备在发送所述业务访问请求，并判断出所述第一业务流信息与业务集合对应的业务流信息匹配之后上报；或者

所述第一业务流信息和所述用户标识是由OTT服务器在判断出所述第一业务流信息与所述业务集合对应的业务流信息匹配之后上报。

3.如权利要求2所述的方法，其特征在于，所述业务集合中的业务的生成过程包括：

所述业务管理设备接收OTT服务器发送的所述业务对应的业务地址列表，并对所述业务对应的业务地址列表进行审核；

所述业务管理设备对所述业务对应的业务地址列表审查完成后，将所述业务对应的业务地址列表发送给客户关系管理设备，以使所述客户关系管理设备基于所述业务对应的业务地址列表生成所述业务，并且将所述业务发送给所述PCRF，业务管理设备；

所述业务管理设备接收所述客户关系管理设备发送的所述业务，并将所述业务发送给所述用户设备和/或所述OTT服务器。

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

所述业务订购信息集合中的业务订购信息是由客户关系管理设备根据用户设备发送的业务对应的订购请求生成并发送给所述业务管理设备的，并且所述客户关系管理设备还会将所述业务订购信息发送给PCRF；

所述业务管理设备接收所述业务订购信息。

5.如权利要求1-4任一权项所述的方法，其特征在于，所述第一业务流信息具体为五元组信息，所述五元组信息包括：源地址、源端口、目标地址、目标端口，以及协议号。

6.如权利要求1-4任一权项所述的方法，其特征在于，所述策略控制具体包括计费策略控制，或服务质量策略控制。

7.如权利要求1所述的方法，其特征在于，所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，具体包括：

根据所述用户标识在所述业务订购信息集合中查询所述用户标识订购的业务；

判断所述第一业务流信息中的业务地址是否存在于用户标识订购的业务的业务地址列表中。

8.一种业务管理设备，其特征在于，包括：

接收单元，用于收用户设备发送的业务访问请求，所述业务访问请求携带第一业务流信息和所述用户设备的用户标识；

判断单元，用于根据所述接收单元接收的业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，所述业务订购信息集合中包括用户标识与订购业务的对应关系；

发送单元，用于所述判断单元判断出所述用户订购了所述第一业务流信息对应的业务时，则向PCRF发送携带有所述第一业务流信息和所述用户标识的更新策略请求，其中，所述更新策略请求用于请求所述PCRF将所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

9.如权利要求8所述的业务管理设备，其特征在于，所述第一业务流信息和所述用户标识由所述用户设备在发送所述业务访问请求，并判断出所述第一业务流信息与业务集合对应的业务流信息匹配之后上报的；或者

所述第一业务流信息和所述用户标识是由OTT服务器在判断出所述第一业务流信息与所述业务集合对应的业务流信息匹配之后上报。

10.如权利要求9所述的业务管理设备，其特征在于，所述业务集合中的业务的生成过程包括：

所述接收单元接收OTT服务器发送的所述业务对应的业务地址列表，审核单元对所述业务对应的业务地址列表进行审核；

当所述审核单元对所述业务对应的业务地址列表审查完成后，发送单元将所述业务对应的业务地址列表发送给客户关系管理设备，以使所述客户关系管理设备基于所述业务对应的业务地址列表生成所述业务，并且将所述业务发送给所述PCRF，业务管理设备；

所述接收单元接收所述客户关系管理设备发送的所述业务，并将所述业务发送给所述用户设备和/或所述OTT服务器。

11.如权利要求8所述的业务管理设备，其特征在于，所述业务订购信息集合中的业务订购信息是由客户关系管理设备根据用户设备发送的业务对应的订购请求生成并发送给所述业务管理设备的，并且所述客户关系管理设备还会将所述业务订购信息发送给PCRF；

所述接收单元接收所述客户关系管理设备发送的所述业务订购信息。

12.如权利要求8-11任一权项所述的业务管理设备，其特征在于，所述第一业务流信息具体为五元组信息，所述五元组信息包括：源地址、源端口、目标地址、目标端口，以及协议号。

13.如权利要求8-11任一权项所述的业务管理设备，其特征在于，所述策略控制具体包括计费策略控制，或服务质量策略控制。

14.如权利要求8所述的业务管理设备，其特征在于，所述判断单元具体用于根据所述接收单元接收的所述用户标识在所述业务订购信息集合中查询所述用户标识订购的业务；判断所述第一业务流信息中的业务地址是否存在于用户标识订购的业务的业务地址列表中。

15.一种业务策略控制方法，所述方法应用于PCRF，其特征在于，所述方法包括：

PCRF接收业务管理设备发送的携带有第一业务流信息和用户标识的更新策略请求，所述更新策略请求是所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断出所述用户订购了所述第一业务流信息对应的业务之后发送的，其中，所述业务订购信息集合中包括用户标识与订购业务的对应关系；

PCRF基于所述更新策略请求，获取所述第一业务流信息对应的策略信息；

PCRF将所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

16.如权利要求15所述的方法，其特征在于，所述方法还包括：

PCRF接收客户关系管理设备发送的业务，其中所述业务是客户关系管理设备基于业务对应的业务地址列表生成的，其中所述业务对应的业务地址列表是由OTT服务器发送，并由所述业务管理设备审核之后发送给客户关系管理设备的。

17.一种PCRF，其特征在于，包括：

接收模块，用于接收业务管理设备发送的携带有第一业务流信息和用户标识的更新策略请求，所述更新策略请求是所述业务管理设备根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断出所述用户订购了所述第一业务流信息对应的业务之后发送的，其中，所述业务订购信息集合中包括用户标识与订购业务的对应关系；

获取模块，用于基于接收模块接收的所述更新策略请求，获取所述第一业务流信息对应的策略信息；

发送模块，用于将所述获取模块获取的所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制。

18.如权利要求17所述的PCRF，其特征在于，所述接收模块还用于接收客户关系管理设备发送的业务，其中所述业务是客户关系管理设备基于业务对应的业务地址列表生成的，其中所述业务对应的业务地址列表是由OTT服务器发送，并由所述业务管理设备审核之后发送给客户关系管理设备的。

19.一种业务处理系统，其特征在于，所述系统包括：

所述业务管理设备，用于接收用户设备发送的业务访问请求，所述业务访问请求携带第一业务流信息和所述用户设备的用户标识；根据业务订购信息集合以及所述第一业务流信息和所述用户标识，判断所述用户是否订购了所述第一业务流信息对应的业务，所述业务订购信息集合中包括用户标识与订购业务的对应关系；若判断出所述用户订购了所述第一业务流信息对应的业务，则向PCRF发送携带有所述第一业务流信息和所述用户标识的更新策略请求，所述更新策略请求用于请求所述PCRF将所述第一业务流信息对应的业务的策略信息发送给GGSN，以使所述GGSN根据所述策略信息对所述第一业务流信息对应的业务执行策略控制；

PCRF，用于接收业务管理设备发送的携带有第一业务流信息和用户标识的更新策略请求；基于所述更新策略请求，获取所述第一业务流信息对应的策略信息；将所述第一业务流信息对应的策略信息将发送给GGSN；

所述GGSN，用于根据所述策略信息对所述用户设备所进行的第一业务流信息对应的业务执行策略控制。