提供服务方法、业务代理装置、策略和计费规则功能装置

摘要

本发明公开了一种提供服务方法、业务代理装置、策略和计费规则功能装置。该提供服务的方法包括：接收用于请求提供服务的服务请求；根据该服务请求，确定与该服务相关联的至少一个AF；确定该至少一个AF中的每个AF的QoS需求信息；向PCRF发送QoS授权请求，其中该QoS授权请求中携带该每个AF的QoS需求信息；接收该PCRF发送的授权成功应答，以便于通过该至少一个AF提供该服务，其中该授权成功应答中携带对该每个AF的QoS需求信息的授权。该业务代理装置包括第一接收模块、第一确定模块、第二确定模块、发送模块和第二接收模块。该策略和计费规则功能装置包括接收模块和发送模块。本发明实施例的方法和装置，通过SB集中控制QoS请求，能够降低开发成本和运营成本。

说明书

技术领域

本发明涉及通信领域，特别涉及通信领域中提供服务的方法、业务代理装置、策略和计费规则功能装置。

背景技术

互联网协议(Internet Protocol，简称为“IP”)多媒体子系统(IP Multimedia Subsystem，简称为“IMS”)是通信核心网全IP化演进的主要标志性阶段。目前，随着各大运营商固网与移动的融合，以及信息技术(Information Technology，简称为“IT”)与通信技术(Communication Technology，简称为“CT”)的结合，IMS已经进入实施和商用的时期，国内各大运营商也已经开始IMS及其智能业务的试验。

随着通信网的IP化，通信业务的开发门槛降低，随之而来需要面临的是业务管理问题。在IMS架构下，可以通过初始过滤准则(Initial Filter Criteria，简称为“IFC”)控制各个业务的触发，从而实现业务与控制的分离。并且IFC可以编写成很灵活的可扩展标记语言(Extensible Markup Language，简称为“XML”)脚本，来判断各种业务的触发。但是这还是会导致业务冲突。为此，第三代合作伙伴计划提出了业务代理装置(Service Broker，简称为“SB”)的概念，用于解决业务冲突的问题。

随着下一代宽带网络向IP化的方向发展，包括语音在内的各种业务都运行在IP网络上，于是业务的提供将面临着服务质量(Quality of Service，简称为“QoS”)的问题。由于用户的需求存在着巨大的差异性，并且对于同一个业务的质量要求也不尽相同，用户可以根据自己的实际需求签订不同的服务等级协议(Service Level Agreement，简称为“SLA”)，选择合适的计费方式，因此QoS成了各个计费层面都涉及到的必要元素。当QoS发生变化的时候，需要能够及时地选择相应的计费方式，实现真正的动态、精确计费。同时，运营商为了保持在价值链中的主导地位，避免被管道化，可以通过内容感知和深入的包检测技术，实现对业务流和内容的识别，从而能够感知网络中的各种业务，并提供相应的计费模式，以满足不同服务提供商的不同需求。

为了在业务数据流级别实施门控制、QoS控制以及计费控制，3GPP第7版本在第6版本的流计费(Flow Based Charging，简称为“FBC”)的基础上，制定了策略和计费控制体系结构相关的规范策略和计费控制(Policy Charging Control，简称为“PCC”)。该PCC体系将R6版本中的策略控制功能(即基于服务的本地策略(Service Based Local Policy，简称为“SBLP”)和基于流的计费功能(即FBC)结合在一起，并融合了相关的接口的功能。

在PCC体系中，应用功能装置(Application Function，简称为“AF”)与策略和计费规则功能装置(Policy and Charging Rules Function，简称为“PCRF”)通过Rx接口相连，以实现对QoS进行控制，因此AF过多地关注非功能相关的细节。由于不同AF之间的Qos要求可能不同，有的可能相互关联，有的甚至互相冲突，因此，如何有效地控制和管理QoS是当前所需要解决的技术问题。

发明内容

本发明实施例提供了一种提供服务的方法、业务代理装置、策略和计费规则功能装置，通过SB集中控制QoS请求，从而能够有效地控制和管理QoS。

一方面，本发明实施例提供了一种提供服务的方法，该方法包括：接收用于请求提供服务的服务请求；根据该服务请求，确定与该服务相关联的至少一个应用功能装置AF；确定该至少一个AF中的每个AF的服务质量QoS需求信息；向策略和计费规则功能装置PCRF发送QoS授权请求，其中，该QoS授权请求中携带该每个AF的QoS需求信息；接收该PCRF发送的授权成功应答，以便于通过该至少一个AF提供该服务，其中，该授权成功应答中携带对该每个AF的QoS需求信息的授权。

另一方面，本发明实施例提供了一种提供服务的方法，该方法包括：接收业务代理装置SB发送的服务质量QoS授权请求，其中，该QoS授权请求中携带与一服务相关联的至少一个应用功能装置AF中的每个AF的QoS需求信息；向该SB发送授权成功应答，以便于该SB通过该至少一个AF提供该服务，其中，该授权成功应答中携带对该每个AF的QoS需求信息的授权。

再一方面，本发明实施例提供了一种业务代理装置，该业务代理装置包括：第一接收模块，用于接收用于请求提供服务的服务请求；第一确定模块，用于根据该服务请求，确定与该服务相关联的至少一个应用功能装置AF；第二确定模块，用于确定该至少一个AF中的每个AF的服务质量QoS需求信息；发送模块，用于向策略和计费规则功能装置PCRF发送QoS授权请求，其中，该QoS授权请求中携带该每个AF的QoS需求信息；第二接收模块，用于接收该PCRF发送的授权成功应答，以便于通过该至少一个AF提供该服务，其中，该授权成功应答中携带对该每个AF的QoS需求信息的授权。

再一方面，本发明实施例提供了一种策略和计费规则功能装置，该策略和计费规则功能装置包括：接收模块，用于接收业务代理装置SB发送的服务质量QoS授权请求，其中，该QoS授权请求中携带与一服务相关联的至少一个应用功能装置AF中的每个AF的QoS需求信息；发送模块，用于向该SB发送授权成功应答，以便于该SB通过该至少一个AF提供该服务，其中，该授权成功应答中携带对该每个AF的QoS需求信息的授权。

基于上述技术方案，本发明实施例的提供服务的方法、业务代理装置、策略和计费规则功能装置，通过SB确定与需要提供的服务相关联的至少一个AF中的每个AF的QoS需求信息，并将这些QoS需求信息统一发送给PCRF，从而能够有效地集中控制QoS，减小系统所需传递的信令数量，提高系统的时延性能，并能够降低AF的开发成本，加快业务的即时上市，以及降低运营和维护成本。

附图说明

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

图1是相关技术中策略与计费控制体系的示意性结构图。

图2是根据本发明实施例的方法的一种应用场景示意图。

图3是根据本发明实施例的提供服务的方法的示意性流程图。

图4是根据本发明实施例的确定AF的QoS需求信息的示意性流程图。

图5是根据本发明实施例的提供服务的方法的另一示意性流程图。

图6是根据本发明另一实施例的提供服务的方法的示意性流程图。

图7是根据本发明实施例的提供服务的方法的再一示意性流程图。

图8是根据本发明实施例的业务代理装置的示意性框图。

图9是根据本发明另一实施例的业务代理装置的示意性框图。

图10是根据本发明实施例的策略和计费规则功能装置的示意性框图。

具体实施方式

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

应理解，本发明的技术方案可以应用于各种通信系统，例如：全球移动通讯(Global System of Mobile communication，简称为“GSM”)系统、码分多址(Code Division Multiple Access，简称为“CDMA”)系统、宽带码分多址(Wideband Code Division Multiple Access，简称为“WCDMA”)系统、通用分组无线业务(General Packet Radio Service，简称为“GPRS”)、长期演进(Long Term Evolution，简称为“LTE”)系统、LTE频分双工(Frequency Division Duplex，简称为“FDD”)系统、LTE时分双工(Time Division Duplex，简称为“TDD”)、通用移动通信系统(Universal Mobile Telecommunication System，简称为“UMTS”)等。

应理解，在图1所示的PCC体系中，PCRF通过Rx接口、Sp接口、Gxx接口以及Gx接口，分别与AF、签约数据库(Subscription Profile Repository，简称为“SPR”)、承载绑定和事件上报功能(Bearer Binding and Event Reporting Function，简称为“BBERF”)、策略和计费执行功能(Policy and Charging Enforcement Function，简称为“PCEF”)相连，BBERF可以位于接入网网关(Access Network Gateway，简称为“AN-GW”)中，PCEF可以位于公用数据网网关(Public Data Network Gateway，简称为“PDN-GW”)中，PCEF通过Gy接口以及Gz接口，分别与在线计费系统(Online Charging System，简称为“OCS”)以及离线计费系统(Offline Charging System，简称为“OFCS”)相连。

AF提供应用的功能实体，这些应用需要对用户平面进行动态策略和计费控制，并为PCRF提供动态的应用会话信息。PCRF包含策略控制决策和基于流的计费控制功能。PCRF对PCEF进行基于业务数据流的检测、门控、QoS授权，以及基于流计费的网络控制。PCRF检查AF提供的业务信息是否与运营商预定义的策略规则以及从SPR得到的用户签约信息一致，并根据该信息生成相应的规则，下发给PCEF。PCRF还要对AF提供的业务信息进行QoS授权。

PCEF具有策略执行和基于流计费的功能。PCEF位于PDN网关中，在GPRS的情况下位于网关GPRS支持节点(Gateway GPRS Support Node，简称为“GGSN”)中，在无线局域网络(Wireless Local Area Networks，简称为“WLAN”)的情况下位于私有数据发生器(Private Data Generator，简称为“PDG”)中。PCEF控制用户平面流量和QoS，提供业务数据流的检测和计量，同时与在线和离线计费系统交互。PCEF具体执行PCC规则中对业务数据流定义的QoS、门控等信息，同时向PCRF上报相关业务数据流的改变。

PCC体系的引入，使得可以在PCC的一个操作中能够同时包含策略和计费相关的内容，为运营商提供实时性更强的策略控制和计费体系。融合的策略控制和计费操作将能够合并到同一个流程中完成，从而大大地减少系统所需传递的信令数量，提高系统的时延性能。同时，提供策略控制与计费的信息交互，使得运营商能够根据QoS、策略控制进行计费。

图2示出了根据本发明实施例的方法的一种应用场景示意图。如图2所示，至少一个AF通过Rx接口与SB相连，SB通过Rx+接口与PCRF相连，并与网络侧设备相连，PCRF通过Gx接口与PCEF相连，PCEF通过Gxx接口与网络侧设备相连。应理解，在图2中以两个AF为例进行说明，但本发明实施例并不限于此，例如AF的数量可以根据具体的业务确定。还应理解，在本发明实施例中，AF与SB之间可以采用Rx接口相连，也可以采用内部非标准接口相连，该内部非标准接口具有与Rx接口类似的功能。本发明实施例仅以AF与SB通过Rx接口相连为例进行说明，但是本发明并不限于此。

图3示出了根据本发明实施例的提供服务的方法100的示意性流程图。如图3所示，该方法100包括：

S110，接收用于请求提供服务的服务请求；

S120，根据该服务请求，确定与该服务相关联的至少一个应用功能装置AF；

S130，确定该至少一个AF中的每个AF的服务质量QoS需求信息；

S140，向策略和计费规则功能装置PCRF发送QoS授权请求，其中，该QoS授权请求中携带该每个AF的QoS需求信息；

S150，接收该PCRF发送的授权成功应答，以便于通过该至少一个AF提供该服务，其中，该授权成功应答中携带对该每个AF的QoS需求信息的授权。

业务代理装置SB在接收到诸如网络侧设备发送的服务请求之后，可以根据该服务请求，确定与所请求提供的服务相关联的至少一个AF，并确定该至少一个AF中的每个AF的QoS需求信息。之后，SB可以向PCRF发送QoS授权请求，该QoS授权请求中携带该每个AF的QoS需求信息，并接收该PCRF发送的授权成功应答，以便于通过该至少一个AF提供该服务，其中，该授权成功应答中携带PCRF发送的对该每个AF的QoS需求信息的授权。

因此，本发明实施例的提供服务的方法，通过SB确定与需要提供的服务相关联的至少一个AF中的每个AF的QoS需求信息，并将这些QoS需求信息统一发送给PCRF，从而能够有效地集中控制QoS，减小系统所需传递的信令数量，提高系统的时延性能，并能够降低AF的开发成本，加快业务的即时上市，以及降低运营和维护成本。

在S110中，SB接收业务触发的服务请求，通常，该服务请求由网络或网络侧设备发送，用于请求SB提供服务。

在S120中，SB可以根据需要提供的服务，确定相关联的AF，所关联的AF及AF的数量可以根据需要提供的服务确定。

在S130中，SB需要确定与服务相关联的每个AF的QoS需求信息。在本发明实施例中，可选地，SB根据预置的该至少一个AF中的第一AF的第一QoS需求信息，确定该第一AF的QoS需求信息。即，对于至少一部分AF，在SB中预先存储有其对应的QoS需求信息。应理解，该第一AF可以是该至少一个AF中的一个或一个以上的AF，也可以是该至少一个AF中的所有的AF。

例如，每个AF在接入网络的时候，都要给运营商提出自己的QoS需求信息，SB可以将这个QoS需求信息配置在系统内部，作为预置的QoS需求信息。具体地，例如一个AF固定地需要128K的带宽，不需要动态调整，则该AF可以让SB固定地为这个AF申请128K的带宽。

在本发明实施例中，可选地，如图4所示，提供服务的方法100还包括：

S210，SB接收该至少一个AF中的第二AF发送的QoS改变消息，该QoS改变消息包括该第二AF确定的第二QoS需求信息；

其中SB确定该至少一个AF中的每个AF的QoS需求信息，可以包括：

S220，SB根据该第二QoS需求信息，确定该第二AF的QoS需求信息。

类似地，应理解，该第二AF可以是该至少一个AF中的一个或一个以上的AF，也可以是该至少一个AF中的所有的AF。需要说明的是，在本发明实施例中，确定AF的QoS需求信息的方法200可以包括S210和S220，并且S130可以包括该方法200。

在具体实现过程中，SB可在收到用于请求提供服务的服务请求之后，通知与请求提供的服务相关联的各AF准备提供服务。在收到来自SB的通知之后，如果一AF确定需要改变QoS，则向SB发送上述QoS改变消息。

在本发明实施例中，在SB确定AF的QoS需求信息之前，SB可以接收该至少一个AF中的第二AF发送的QoS改变消息，其中SB确定该至少一个AF中的每个AF的QoS需求信息，可以包括：SB根据该QoS改变消息中携带的第二QoS需求信息，确定该第二AF的QoS需求信息。之后，SB可以将确定的该至少一个AF中的每个AF的QoS需求信息统一发送给PCRF。

在本发明实施例中，在SB将各AF的QoS需求信息统一发送给PCRF之后，SB也可以接收该至少一个AF中的第二AF发送的QoS改变消息，并确定该第二AF的QoS需求信息。之后，SB可以将该第二AF的QoS需求信息单独发送给PCRF，以改变QoS需求。

应理解，在本发明实施例中，SB还可以根据QoS控制策略来具体确定每个AF的QoS需求信息。例如，SB根据第一AF的预置的第一QoS需求信息，或根据第二AF通过QoS改变消息发送的第二QoS需求信息，再基于与业务或与AF性能等相关的QoS控制策略，确定最终的每个AF的QoS需求信息。例如，AF仅能申请128k～512k的带宽，但AF在会话过程中申请了1M带宽，此时SB可以只允许AF请求的最高上限带宽为512k。又例如，对于不同AF的QoS需求信息，SB可以简单地叠加各AF需求的QoS，也可以取最大的QoS。

在S140中，可选地，SB向PCRF发送QoS授权请求，包括：SB向该PCRF发送鉴权授权请求AAR消息，该AAR消息包括该每个AF的QoS需求信息。

在S150中，可选地，SB接收该PCRF发送的授权成功应答，包括：SB接收该PCRF根据该AAR消息发送的鉴权授权应答AAA消息，该AAA消息包括对该每个AF的QoS需求信息的授权。

在本发明实施例中，该AAR消息包括至少一个第一属性值对(Attribute Value Pair，简称为“AVP”)组，例如[RxPlus-Information]AVP组，该至少一个第一AVP组中的每个第一AVP组承载该至少一个AF中的一个AF的QoS需求信息。表1示出了根据本发明实施例的AAR消息的一个具体例子。

表1

在本发明实施例中，AAR消息包括与服务相关联的至少一个AF中的每个AF的QoS需求信息；AAA消息包括对每个AF的QoS需求信息的授权，主要是上报的带宽信息，上行、下行的总带宽，或媒体成分的上行、下行带宽等。下面给出了根据本发明实施例的AAA消息的一个具体例子。

在本发明实施例中，SB与PCRF之间通过Rx+接口进行交互，该Rx+接口是对Rx接口的扩展，以支持对多个AF的QoS同时进行控制，SB和PCRF需要支持该扩展后的Rx+协议，下面给出了Rx+协议扩展说明的一个具体例子。

本发明实施例的提供服务的方法，通过SB确定与需要提供的服务相关联的至少一个AF中的每个AF的QoS需求信息，并将这些QoS需求信息统一发送给PCRF，从而能够有效地集中控制QoS，减小系统所需传递的信令数量，提高系统的时延性能，并能够降低AF的开发成本，加快业务的即时上市，以及降低运营和维护成本。

下面将结合图5所示的方法300，对根据本发明实施例的提供服务的方法进行详细说明。如图5所示，该方法300包括：

S301，来自网络侧的业务请求触发(Trigger)到业务代理装置Service Broker(SB)。

S302，Service Broker根据业务触发规则决定优先触发AF1，并发送业务请求(Service Request)到AF1。

S303，AF1返回业务响应(Service Response)到Service Broker。

S304，Service Broker根据业务排列组合规则决定继续触发AF2，并发送Service Request到AF2。

S305，AF2返回Service Response到Service Broker。

S306，Service Broker返回Trigger响应给网络侧。

S307，Service Broker根据AF1和AF2预置的QoS请求，在一个AAR请求中携带多个AF会话信息到PCRF，建立AF会话。应理解，AF如果需要变更预置的QoS请求，例如需要不同的用户提供不同的QoS，那么AF也可在会话建立时，例如通过业务响应发送到Service Broker，由Service Broker将多个AF会话信息汇总后统一发送给PCRF，建立AF会话。

扩展说明：Service Broker在AAR消息中携带多个【RxPlus-Information】AVP组，每组中携带一个AF的Qos请求信息。

S308，PCRF接收AAR请求，并返回AAA。

S313，网络侧发起会话结束请求到Service Broker。

S314，Service Broker向AF1发起业务结束请求。

S315，AF1返回业务结束响应。

S316，Service Broker向AF2发起业务结束请求。

S317，AF2返回业务结束响应。

S318，Service Broker向PCRF发起STR结束会话。

S319，PCRF返回STA给Service Broker。

在本发明实施例中，如果在会话过程中，AF需要对QoS进行变更，那么AF可以发送QoS改变(QoS Changing)请求到Service Broker，AF与Service Broker之间可以通过Rx接口或内部协议接口进行交互。此时，该方法300可以包括S309至S312，具体而言，

S309，AF1向Service Broker发送QoS Changing请求，该请求中携带改变后的QoS需求信息。

S310，Service Broker向PCRF发起AAR请求，该AAR请求包括改变后的QoS需求信息。此时，Service Broker可以采用Rx+接口发送AAR请求到PCRF，其中携带[Rxplus-Information]。例如AF1需要在会话过程中将QoS上行带宽需求上调到512K，那么AF1可以将携带变更的QoS参数Max-Requested-Bandwidth-UL为512K的AAR请求发送到Service Broker。

S311，PCRF返回AAA响应到Service Broker。

S312，Service Broker向AF1返回QoS Changing响应(AAA)。

应理解，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

本发明实施例的提供服务的方法，通过SB确定与需要提供的服务相关联的至少一个AF中的每个AF的QoS需求信息，并将这些QoS需求信息统一发送给PCRF，从而能够有效地集中控制QoS，减小系统所需传递的信令数量，提高系统的时延性能，并能够降低AF的开发成本，加快业务的即时上市，以及降低运营和维护成本。

上文中结合图1至图5，从业务代理装置SB的角度详细描述了根据本发明实施例的提供服务的方法，下面将结合图6和图7，从策略和计费规则功能装置PCRF的角度描述该方法。

如图6所示，根据本发明实施例的提供服务的方法400包括：

S410，接收业务代理装置SB发送的服务质量QoS授权请求，其中，该QoS授权请求中携带与一服务相关联的至少一个应用功能装置AF中的每个AF的QoS需求信息；

S420，向该SB发送授权成功应答，以便于该SB通过该至少一个AF提供该服务，其中，该授权成功应答中携带对该每个AF的QoS需求信息的授权。

在S410中，PCRF接收SB发送的QoS授权请求，可以包括：PCRF接收该SB发送的鉴权授权请求AAR消息，该AAR消息包括该至少一个AF中的每个AF的QoS需求信息；在S420中，PCRF向该SB发送授权成功应答，可以包括：PCRF向该SB发送鉴权授权应答AAA消息，该AAA消息包括对该每个AF的QoS需求信息的授权。

本发明实施例的提供服务的方法，通过SB确定与需要提供的服务相关联的至少一个AF中的每个AF的QoS需求信息，并将这些QoS需求信息统一发送给PCRF，从而能够有效地集中控制QoS，减小系统所需传递的信令数量，提高系统的时延性能，并能够降低AF的开发成本，加快业务的即时上市，以及降低运营和维护成本。

在本发明实施例中，SB与AF之间的交互协议包括但不限于移动网增强逻辑的用户应用(Customized Applications for Mobile Network Enhanced Logic，简称为“CAMEL”)应用部分(CAMEL Application Part，简称为“CAP”)、会话发起协议(Session Initiation Protocol，简称为“SIP”)、智能网应用规程(Intelligent Network Application Protocol，简称为“INAP”)等协议。下面将结合图7，对AF1与Service Broker之间采用SIP协议，并且AF2与Service Broker之间采用CAP协议为例，对本发明实施例的方法进行描述。

如图7所示，在S501中，业务请求触发到Service Broker；在S502中，Service Broker根据业务触发规则决定优先触发AF1，并发送邀请(INVITE)消息到AF1；在S503中，AF1返回200 OK到Service Broker；在S504中，Service Broker根据业务排列组合规则决定继续触发AF2，并发送启动检出点(Initial Detection Point，简称为“IDP”)消息到AF2；在S505中，AF2返回继续(Continue)消息到Service Broker；在S506中，Service Broker返回触发(Trigger)响应给网络侧；在S507中，Service Broker根据AF1和AF2预置的Qos请求，在一个AAR请求中携带多个AF会话信息到PCRF，建立AF会话；如果AF需要变更预置的Qos请求，也可在会话建立时发送Rx请求到Service Broker，由Service Broker将多个AF会话信息汇总统一后发送给PCRF，建立AF会话；在S508中，PCRF接收AAR请求，并返回AAA；在S509中，网络侧发起会话结束请求到Service Broker；在S510中，Service Broker向AF1发起业务结束请求Bye；在S511中，AF1返回业务结束响应200OK；在S512中，Service Broker向AF2上报呼叫事件ERB(oDisconnect)；在S513中，AF2返回释放呼叫(Release Call，简称为“RC”)；在S514中，Service Broker向PCRF发起会话终止请求(Session Termination Request，简称为“STR”)以结束会话；在S515中，PCRF返回会话终止应答(Session Termination Answer，简称为“STA”)给Service Broker。

应理解，在本发明实施例中，AF可以向Service Broker发送QoS Changing请求，以对QoS进行变更，具体操作可以参考图5所示的方法300，为了简洁，在此不再赘述。还应理解，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

本发明实施例的提供服务的方法，通过SB确定与需要提供的服务相关联的至少一个AF中的每个AF的QoS需求信息，并将这些QoS需求信息统一发送给PCRF，从而能够有效地集中控制QoS，减小系统所需传递的信令数量，提高系统的时延性能，并能够降低AF的开发成本，加快业务的即时上市，以及降低运营和维护成本。

上文中结合图1至图7，对根据本发明实施例的提供服务的方法进行了详细描述，下面将结合图8至图10，详细描述根据本发明实施例的业务代理装置SB以及策略和计费规则功能装置PCRF。

图8示出了根据本发明实施例的业务代理装置800的示意性框图。如图8所示，该业务代理装置800包括：

第一接收模块810，用于接收用于请求提供服务的服务请求；

第一确定模块820，用于根据该服务请求，确定与该服务相关联的至少一个应用功能装置AF；

第二确定模块830，用于确定该至少一个AF中的每个AF的服务质量QoS需求信息；

发送模块840，用于向策略和计费规则功能装置PCRF发送QoS授权请求，其中，该QoS授权请求中携带该每个AF的QoS需求信息；

第二接收模块850，用于接收该PCRF发送的授权成功应答，以便于通过该至少一个AF提供该服务，其中，该授权成功应答中携带对该每个AF的QoS需求信息的授权。

本发明实施例的业务代理装置，通过SB确定与需要提供的服务相关联的至少一个AF中的每个AF的QoS需求信息，并将这些QoS需求信息统一发送给PCRF，从而能够有效地集中控制QoS，减小系统所需传递的信令数量，提高系统的时延性能，并能够降低AF的开发成本，加快业务的即时上市，以及降低运营和维护成本。

在本发明实施例中，可选地，该第二确定模块830还用于根据预置的该至少一个AF中的第一AF的第一QoS需求信息，确定该第一AF的QoS需求信息。

在本发明实施例中，可选地，如图9所示，该业务代理装置800还包括：

第三接收模块860，用于接收该至少一个AF中的第二AF发送的QoS改变消息，该QoS改变消息包括该第二AF确定的第二QoS需求信息，

该第二确定模块830还用于根据该第二QoS需求信息，确定该第二AF的QoS需求信息。

在本发明实施例中，可选地，该发送模块840还用于向该PCRF发送鉴权授权请求AAR消息，该AAR消息包括该每个AF的QoS需求信息，该第二接收模块850还用于接收该PCRF根据该AAR消息发送的鉴权授权应答AAA消息，该AAA消息包括对该每个AF的QoS需求信息的授权。

可选地，该AAR消息包括至少一个第一属性值对AVP组，该至少一个第一AVP组中的每个第一AVP组承载该至少一个AF中的一个AF的QoS需求信息。

根据本发明实施例的业务代理装置800可对应于本发明实施例中的Service Broker(SB)，并且该业务代理装置800中的各个模块的上述和其它操作和/或功能分别为了实现图1至图7中的各个方法的相应流程，为了简洁，在此不再赘述。

本发明实施例的业务代理装置，通过SB确定与需要提供的服务相关联的至少一个AF中的每个AF的QoS需求信息，并将这些QoS需求信息统一发送给PCRF，从而能够有效地集中控制QoS，减小系统所需传递的信令数量，提高系统的时延性能，并能够降低AF的开发成本，加快业务的即时上市，以及降低运营和维护成本。

图10示出了根据本发明实施例的策略和计费规则功能装置900的示意性框图。如图10所示，该策略和计费规则功能装置900包括：

接收模块910，用于接收业务代理装置SB发送的服务质量QoS授权请求，其中，该QoS授权请求中携带与一服务相关联的至少一个应用功能装置AF中的每个AF的QoS需求信息；

发送模块920，用于向该SB发送授权成功应答，以便于该SB通过该至少一个AF提供该服务，其中，该授权成功应答中携带对该每个AF的QoS需求信息的授权。

可选地，该接收模块910还用于接收该SB发送的鉴权授权请求AAR消息，该AAR消息包括该至少一个AF中的每个AF的QoS需求信息，该发送模块920还用于向该SB发送鉴权授权应答AAA消息，该AAA消息包括对该每个AF的QoS需求信息的授权。

可选地，该AAR消息包括至少一个第一属性值对AVP组，该至少一个第一AVP组中的每个第一AVP组承载该至少一个AF中的一个AF的QoS需求信息。

根据本发明实施例的策略和计费规则功能装置900可对应于本发明实施例中的PCRF，并且该策略和计费规则功能装置900中的各个模块的上述和其它操作和/或功能分别为了实现图1至图7中的各个方法的相应流程，为了简洁，在此不再赘述。

本发明实施例的策略和计费规则功能装置，通过SB确定与需要提供的服务相关联的至少一个AF中的每个AF的QoS需求信息，并将这些QoS需求信息统一发送给PCRF，从而能够有效地集中控制QoS，减小系统所需传递的信令数量，提高系统的时延性能，并能够降低AF的开发成本，加快业务的即时上市，以及降低运营和维护成本。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。