CN103686660B

CN103686660B - 一种在pcc架构中用于进行计费的方法和装置

Info

Publication number: CN103686660B
Application number: CN201210360590.XA
Authority: CN
Inventors: 李向阳
Original assignee: Alcatel Optical Networks Israel Ltd
Current assignee: Alcatel Optical Networks Israel Ltd
Priority date: 2012-09-21
Filing date: 2012-09-21
Publication date: 2016-12-21
Anticipated expiration: 2032-09-21
Also published as: CN103686660A

Abstract

本发明的目的是提供一种在PCC架构中用于进行计费的方法和装置。本发明接收来自应用计费端口的、一个应用数据流的应用计费相关信息；并当符合第一预定条件时，根据所述应用计费相关信息，对所述应用数据流进行计费，获得第一计费结果。与现有技术相比，本发明具有以下优点：能够实现应用级别的计费，能够获得单独的应用的计费结果。

Description

一种在PCC架构中用于进行计费的方法和装置

技术领域

本发明涉及通信技术领域，尤其涉及一种在PCC架构中用于进行计费的方法和装置。

背景技术

3GPP引入了策略与计费控制(Policy and Charging Control，PCC)架构。在最新的3GPP TS23.203v11.0.1(2011年1月)版本中，在PCC架构中加入了新的节点——应用检测和控制(Application Detection and Control，ADC)，该ADC包括一个流量检测功能(Traffic Detection Function，TDF)。该ADC/TDF检测应用流量，并报告至策略和计费规则功能(Policy and Charging Rules Function，PCRF)。TDF可以是一个单独的设备，或跟策略和计费执行功能(Policy and Charging Enforcement Function，PCEF)整合在一起。该包含ADC/TDF的新的PCC架构通过在PCRF中确定的计费策略规则，解决了应用层服务的策略问题。该PCC架构引入了Sd参考点(Reference Point)，该参考点在PCRF和单独的ADC/TDF之间。基于不管是预置在TDF中的或者由PCRF通过Sd参考点动态提供的ADC规则，该TDF能动态控制应用检测、及动态控制服务数据流。

然而，上述PCC架构不能对单个应用的数据通信计费，例如，不能单独对Skype、P2P、HTTP计费等。这种限制使得运营商不能把不同的计费策略应用于应用数据通信上。

发明内容

本发明的目的是提供一种在PCC架构中用于进行计费的方法和装置。

根据本发明的一个方面，提供一种在PCC架构包含的计费系统中用于进行计费的方法，其中，所述计费系统与包含于所述PCC架构中的流量检测功能之间具有应用计费端口，该方法包括以下步骤：

a接收来自所述应用计费端口的、一个应用数据流的应用计费相关信息；

b当符合第一预定条件时，根据所述应用计费相关信息，对所述应用数据流进行计费，获得第一计费结果。

根据本发明的另一个方面，还提供了一种在PCC架构包含的计费系统中用于进行计费的计费装置，其中，所述计费系统与包含于所述PCC架构中的流量检测功能之间具有应用计费端口，该计费装置包括：

第一接收装置，用于接收来自所述应用计费端口的、一个应用数据流的应用计费相关信息；

第一计费装置，用于当符合第一预定条件时，根据所述应用计费相关信息，对所述应用数据流进行计费，获得第一计费结果。

与现有技术相比，本发明具有以下优点：1)能够实现应用级别的计费，能够获得单独的应用的计费结果，例如，能够单独对Skype、P2P、HTTP等进行计费；2)能够在实现应用级别的计费的同时，避免同一用户会话由于TDF和PCEF存在并行计费端口导致的应用数据流重复计费。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1a为本发明一个优选实施例的PCC架构示意图；

图1b为本发明另一个优选实施例的PCC架构示意图；

图1c为本发明另一个优选实施例的PCC架构示意图；

图1d为本发明另一个优选实施例的PCC架构示意图；

图2为本发明一个优选实施例的在PCC架构的计费系统中进行计费的方法流程图；

图3为本发明一个优选实施例的在PCC架构的计费系统中进行计费的方法流程图；

图4为本发明一个优选实施例的业务数据流的信用配额用尽后在PCC架构中重新分配应用数据流以及业务数据流的信用配额并计费的方法流程图；

图5为本发明一个优选实施例的应用数据流的信用配额用尽后在PCC架构中重新分配应用数据流以及业务数据流的信用配额并计费的方法流程图；

图6为本发明一个优选实施例的应用终止后在PCC架构中重新分配业务数据流的信用配额并计费的方法流程图；

图7为本发明一个优选实施例的应用启动后在PCC架构中分配应用数据流以及业务数据流的信用配额的方法流程图；

图8为本发明一个优选实施例的建立IP-CAN承载的方法流程图；

图9为本发明一个优选实施例的计费系统的结构示意图；

图10为本发明一个优选实施例的计费系统的结构示意图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本发明作进一步详细描述。

图1a-1d为本发明多个优选实施例的PCC架构示意图。

请参阅图1a，图1a示出了本发明一个优选实施例的非漫游情况下的增强型PCC架构示意图，该PCC架构包括PCRF、PCEF、OCS、OFCS、TDF、SPR、AF、BBERF以及多个参考点Gx、Gy、Gy’、Gz、Gz’、Gxx、Sd、Sy、Rx、Sp，参考点的位置请参见图1a。其中，参考点Gx、Gy、Gz、Gxx、Sd、Sy、Rx和Sp的标准可参见3GPP标准，Gy’与Gy的标准相同或类似，Gz’与Gz的标准相同或类似。

其中，策略和计费规则功能(Policy and Charging Rules Function，PCRF)具有策略控制决策和基于流计费控制的功能，可向PCEF提供关于业务数据流检测、门控、基于QoS和基于流计费(除信用控制外)的网络控制功能。

策略和计费执行功能(Policy and Charging Enforcement Function，PCEF)可负责业务数据流的检测、策略执行和基于流的计费功能，其可设置在GGSN(Gateway GPRSSupport Node，网关GPRS支持节点)或P-GW(即PDN-GW，Packet Data Network Gateway，分组数据网络网关)上。

流量检测功能(Traffic Detection Function，TDF)可检测应用流量，并报告至PCRF。TDF可以是一个单独的设备，也可与PCEF整合在一起。

应用功能(Application Function，AF)可对IP-CAN用户面行为进行动态策略/计费控制，其可设置在业务平台上。

承载绑定及事件报告功能(Bearing Binding and Event Report Function，BBERF)可承载绑定、上行承载绑定校验及当Gxx存在时向PCRF进行事件报告的策略执行点。该功能实体可位于网关中，如P-GW，S-GW等。

用户属性存储器(Subscription Profile Repository，SPR)可存储用户属性。

在线计费系统(Online Charging System，OCS)可实时或准实时地进行计费，其可负责对IMS及分组承载网络进行信用控制计费，并服务于IMS环境下的服务呼叫会话控制功能(S-CSCF，Serving Call Session Control Function，CSCF)、应用服务器、多媒体资源功能控制器(MRFC，Media Resource Function Controller)以及CAP(Cable Access Point，纤缆接入点)接入的分组域接入设备SGSN(Service GPRS Support Node，服务GPRS支持节点)等。

离线计费系统(Offline Charging System，OFCS)可与在线计费系统功能相似，但其进行非实时的计费处理。

其中，OCS和OFCS可统称为计费系统。

请参阅图1b，图1b示出了本发明一个优选实施例的使用UDR的非漫游情况下的增强型PCC架构，该PCC架构包括PCRF、PCEF、OCS、OFCS、TDF、UDR、AF、BBERF以及多个参考点Gx、Gy、Gy’、Gz、Gz’、Gxx、Sd、Sy、Rx、Sp，参考点的位置请参见图1b。其中，参考点Gx、Gy、Gz、Gxx、Sd、Sy、Rx和Sp的标准可参见3GPP标准，Gy’与Gy的标准相同或类似，Gz’与Gz的标准相同或类似。

请参阅图1c，图1c示出了本发明一个优选实施例的使用SPR的归属地路由接入漫游情况下的增强型PCC架构，该PCC架构包括H-PCRF、V-PCRF、PCEF、OCS、OFCS、TDF、UDR、AF、BBERF以及多个参考点Gx、Gy、Gy’、Gz、Gz’、Gxx、Sd、Sy、Rx、Sp、S9，参考点的位置请参见图1c。其中，参考点Gx、Gy、Gz、Gxx、Sd、Sy、Rx、S9和Sp的标准可参见3GPP标准，Gy’与Gy的标准相同或类似，Gz’与Gz的标准相同或类似。其中，H-PCRF、PCEF、OCS、OFCS、TDF、SPR和AF位于用户注册的归属地网络中；V-PCRF和BBERF位于用户当前所在的漫游地网络中。

请参阅图1d，图1d示出了本发明一个优选实施例的使用SPR在访问网络用PCEF(本地越狱)漫游情况下的增强型PCC架构，该PCC架构包括H-PCRF、V-PCRF、PCEF、OCS、OFCS、TDF、SPR、2个AF、BBERF以及多个参考点Gx、Gy、Gy’、Gz、Gz’、Gxx、Sd、Sy、Rx、Sp、S9，参考点的位置请参见图1d。其中，参考点Gx、Gy、Gz、Gxx、Sd、Sy、Rx、S9和Sp的标准可参见3GPP标准，Gy’与Gy的标准相同或类似，Gz’与Gz的标准相同或类似。其中，H-PCRF、SPR、OCS和1个AF位于用户注册的归属地网络中；PCEF、OFCS、TDF、1个AF、V-PCRF和BBERF位于用户当前所在的漫游地网络中。

需要说明的是，上述PCC网络架构仅为举例，其他现有的或今后可能出现的PCC架构如可适用于本发明，也应包含在本发明保护范围以内，并以引用方式包含于此。

图2为本发明一个优选实施例的在PCC架构的计费系统中进行计费的方法流程图。本实施例包括步骤S 1以及步骤S2；本实施例的PCC架构包括计费系统和流量监测功能(以下简称“TDF”)，该计费系统与TDF之间具有应用计费端口，该应用计费端口向计费系统上报应用的应用计费相关信息，该应用计费端口的标准与前述Gy端口相同或相似；其中，本实施例的计费系统可仅包含一个单独的计费系统，也可包含相互独立的两个计费系统，如包含在线计费系统(以下简称“OCS”)以及离线计费系统(以下简称“OFCS”)。当本实施例的计费系统包含OCS以及OFCS时，OCS以及OFCS均可执行步骤S 1以及步骤S2。更优选地，本实施例的PCC架构可为图1a-1d所示实施例中的任一PCC架构，前述应用计费端口为图1a-1d中的Gy’。

本实施例中，对ADC规则进行扩展，以使ADC规则支持以下至少一项应用级别的计费：

1)在线计费；

2)离线计费；

3)在线以及离线计费；

4)不计费。

优选地，ADC规则还能够支持应用级别的下述计费中的至少一项：

1)基于容量的计费；

2)基于时间的计费；

3)基于容量和时间的计费；

4)基于事件的计费；

5)不计费。

并且，ADC规则还包括计费系统(如OCS和OFCS)的地址，以使TDF能够向计费系统发送请求，如计费请求等。

上述支持应用级别的计费的ADC规则可以包括PCRF预分配给TDF的动态ADC规则，也可包括TDF中预配置的ADC规则。优选地，对于同一应用，动态ADC规则的计费参数覆盖预配置的ADC规则。

以下说明本实施例中的步骤S 1以及步骤S2。

在步骤S1中，计费系统接收来自应用计费端口的、一个应用数据流的应用计费相关信息。

其中，一个应用数据流包括一个单独的应用的数据流。

其中，所述应用计费相关信息包括任何与应用计费相关的信息。优选地，应用计费相关信息包括但不限于：

1)应用所属用户设备的网络地址信息；

例如，接入的P-GW地址，S-GW地址，UE用户地址信息，无线接入地址信息等。

2)应用标识信息；

例如，应用标识符等。

3)应用使用时间信息；

例如，应用起始的时间，应用停止的时间，应用运行的时间长度等。

4)应用的服务质量信息(QoS)；

例如，应用所属用户设备使用的带宽、网速等；

5)应用的流量等。

其中，PCC架构中的TDF检测应用，获得上述应用计费相关信息，并通过应用计费端口发送给计费系统。

其中，计费系统可在多种情况下接收TDF发送的应用计费相关信息。

例如，计费系统向TDF发送请求，并接收TDF反馈的应用计费相关信息。

又例如，TDF包括计费触发功能CTF，其检测应用，获取应用的应用计费相关信息，并根据ADC规则定义的计费机制，将应用计费相关信息发送给计费系统。优选地，当应用计费相关信息中的任一项发生变化时，触发CTF向计费系统发送应用计费相关信息等。

优选地，应用计费相关信息与能够触发步骤S2的请求一起发送给计费系统；如与信用控制请求(Credit Control Request，CCR)一起发送给OCS，又如与计费请求一起发送给OFCS等。

需要说明的是，上述举例仅为更好地说明本发明的技术方案，而非对本发明的限制，本领域技术人员应该理解，任何接收来自应用计费端口的、一个应用数据流的应用计费相关信息的实现方式，均应包含在本发明的范围内。

在步骤S2中，当符合第一预定条件时，计费系统根据所述应用计费相关信息，对所述应用数据流进行计费，获得第一计费结果。

其中，所述第一预定条件包括任何启动计费系统进行第一计费结果计算时所应满足的条件。优选地，第一预定条件包括但不限于：

1)接收到PCC架构中的其他模块或设备发送的CCR；优选地，存在该预定条件时，计费系统包括OCS。

更具体地，上述CCR包括：

a)OCS仅对应用数据流进行计费，而不对业务数据流进行计费，则在此情况下，第一预定条件中所指CCR包括OCS接收到的任何CCR。

例如，CCR包括用户设备检测到其业务数据流的信用配额用尽或即将用尽时，向网络端发送，并由网络端的网关接收后转发给OCS的、用于请求分配业务数据流的信用配额的CCR。

又例如，CCR包括TDF检测到应用的应用数据流的信用配额用尽或即将用尽时，向OCS发送的、用于请求分配应用数据流的信用配额的CCR。

又例如，CCR包括TDF接收到应用启动或停止的信息时，向OCS发送的、用于请求分配应用数据流的信用配额或终止应用数据流的信用配额的使用的CCR等。

b)OCS对应用数据流以及业务数据流进行计费，但应用数据流的信用配额分配不会影响业务数据流的信用配额分配；例如，仅限制应用的信用配额(如分别限制Skype、P2P、HTTP的信用配额)，而不限制业务的信用配额。则在此情况下，第一预定条件中所指CCR包括OCS接收到的任何用于为应用数据流请求分配信用配额的CCR。

然而，在此情况下，由于业务数据流的业务计费相关信息由PCEF提供给OCS，则在PCC架构中，会存在从TDF以及PCEF至OCS的两个并行计费端口，并且，由于应用数据流包含于业务数据流中，也即，该两个并行计费端口发送的数据会使得OCS重复统计应用数据流的费用，因此，若需要计算业务数据流的第二计费结果，OCS需要关联(correlate)来自TDF以及PCEF的两个端口(如图1a-1d中的Gy’以及Gy)的数据，以避免对应用数据流的费用进行重复计算。

c)OCS对应用数据流以及业务数据流进行计费，且应用数据流以及业务数据流中任一者的信用配额分配会影响另一者的信用配额分配。则在此情况下，对于其中任一者的CCR会触发OCS发送重认证请求(Re-Authorization Request，RAR)，并在执行重认证后执行计算第一计费结果的步骤。因此，第一预定条件中所述CCR包括基于重认证请求发起的CCR，该优选方案的具体实现方式将在后续实施例中予以说明。

2)接收到计费请求；优选地，存在该预定条件时，计费系统包括OFCS。

其中，OFCS可在多种情况下接收到上述计费请求。例如：

a)该计费请求可用户设备根据预先已确定的时间发送给网络端，并被OFCS接收；

b)OFCS向用户设备请求发送上述计费请求，则用户设备根据OFCS的请求向其发送计费请求等。

需要说明的是，上述第一预定条件仅为更好地说明本发明的技术方案，而非对本发明的限制，本领域技术人员应该理解，任何启动计费系统进行第一计费结果计算时所应满足的条件，均应包含在本发明的范围内。

具体地，当符合第一预定条件时，计费系统根据预确定的规则，基于应用计费相关信息来对所述应用数据流进行计费，获得应用数据流的第一计费结果。

例如，当接收到CCR，计费系统根据应用标识信息来识别应用，并确定其收费标准，并根据应用使用时间信息确定第一计费结果等。

又例如，当OCS接收到PCC架构中的其他模块或设备，如TDF，发送的用于请求重新分配应用数据流的信用配额的CCR时，根据应用计费相关信息包含的应用流量以及应用的服务质量信息，对应用的应用数据流进行计费，获得应用数据流的第一计费结果。

需要说明的是，上述举例仅为更好地说明本发明的技术方案，而非对本发明的限制，本领域技术人员应该理解，任何当符合第一预定条件时，计费系统根据所述应用计费相关信息，对所述应用数据流进行计费，获得第一计费结果的实现方式，均应包含在本发明的范围内。

需要进一步说明的是，步骤S1执行之后，可立即执行S2；或者，步骤S1执行之后，可待满足第一预定条件时，才执行步骤S2。

需要进一步说明的是，步骤S1和S2仅说明了计费系统对一个应用数据流进行计费的方式，事实上，计费系统可同时对多个应用数据流执行上述步骤S1和S2，获得该多个应用数据流的第一计费结果；更优选地，计费系统还可结合本次所得的第一计费结果以及应用的历史第一计费结果，来获得该应用的最终计费结果，例如，计费总和等。

本实施例的PCC架构能够实现应用级别的计费，能够获得单独的应用的计费结果，例如，能够单独对Skype、P2P、HTTP等进行计费。

图3为本发明一个优选实施例的在PCC架构的计费系统中进行计费的方法流程图。本实施例的计费系统对应用数据流以及业务数据流进行计费；本实施例包括步骤S1、步骤S2、步骤S3以及步骤S4；本实施例的PCC架构包括计费系统、TDF以及策略和计费执行功能(以下简称“PCEF”)，该计费系统与TDF之间具有应用计费端口，该应用计费端口的标准与前述Gy端口相同或相似，该PCEF和计费执行功能之间具有业务计费端口，该业务计费端口向计费系统上报业务数据流的业务计费相关信息；其中，本实施例的计费系统可仅包含一个单独的计费系统，也可包含相互独立的两个计费系统，如包含OCS以及OFCS。当本实施例的计费系统包含OCS以及OFCS时，OCS以及OFCS均可执行步骤S1、步骤S2、步骤S3以及步骤S4。更优选地，本实施例的PCC架构可为图1a-1d所示实施例中的任一PCC架构，前述应用计费端口为图1a-1d中的Gy’，前述业务计费端口为图1a-1d中的Gy。

其中，步骤S1和S2已在参照图2所示实施例中予以详述，在此不再赘述。

本实施例中，在步骤S1中获得的应用计费相关信息包括能够标识所述应用数据流所属业务数据流的第一识别信息；优选地，应用计费相关信息还包括如参照图2所示实施例中所述的应用所属用户设备的网络地址信息、应用标识信息、应用使用时间信息、应用的服务质量信息、应用的流量等。其中，第一识别信息可由网关通过端口Gx提供给PCRF，再由PCRF提供给TDF。

优选地，第一标识信息包括但不限于以下至少一项：

1)PDN-连接-Id(PDN-Connection-Id)；

2)P-GW/SGSN地址；

3)用户预约ID(User Subscription ID)；

4)价格组ID(Rating group ID)；

5)业务ID(Service ID)。

由上述信息，计费系统能够确定业务数据流。

在步骤S3中，计费系统将应用计费相关信息中的第一识别信息与已接收到的用于标识业务数据流的至少一个第二标识信息相匹配，并将相匹配的第二标识信息所对应的业务数据流作为所述应用数据流所属的业务数据流，其中，所述第二标识信息包含于所述业务数据流的业务计费相关信息中，所述业务计费相关信息来自所述业务计费端口。

其中，各个业务数据流的业务计费相关信息在本步骤执行之前由PCEF通过业务计费端口上报给计费系统，该业务计费相关信息可包含任何与业务数据流的计费相关的信息。优选地，业务计费相关信息可包含于发送给计费系统的CCR中。

其中，第二标识信息包含的信息类型与第一标识信息包含的信息类型相同或相似。优选地，第二标识信息同样包含PDN-连接-Id、P-GW/SGSN地址、用户预约ID、价格组ID以及业务ID。

具体地，计费系统将第一标识信息与第二标识信息进行匹配，当应用数据流的第一标识信息与一个业务数据流的第二标识信息相匹配时，将相匹配的相匹配的第二标识信息所对应的业务数据流作为所述应用数据流所属的业务数据流。

例如，应用数据流Application_Data_Flow_1的第一标识信息包括PDN-连接-Id、P-GW/SGSN地址、用户预约ID、价格组ID以及业务ID，计费系统将上述五个信息与各个业务数据流的第二标识信息中类型相同的五个信息进行比对，并比对得到一个业务数据流Sever_Data_Flow_1的第二标识信息中的PDN-连接-Id、P-GW/SGSN地址、用户预约ID、价格组ID以及业务ID，与应用数据流Application_Data_Flow_1的第一标识信息中的类型对应的信息均相同时，判断应用数据流Application_Data_Flow_1的第一标识信息与业务数据流Sever_Data_Flow_1的第二标识信息相匹配，该业务数据流Sever_Data_Flow_1为应用数据流Application_Data_Flow_1所属的业务数据流。

需要说明的是，上述举例仅为更好地说明本发明的技术方案，而非对本发明的限制，本领域技术人员应该理解，任何将应用计费相关信息中的第一识别信息与已接收到的用于标识业务数据流的至少一个第二标识信息相匹配，并将相匹配的第二标识信息所对应的业务数据流作为所述应用数据流所属的业务数据流的实现方式，均应包含在本发明的范围内。

在步骤S4中，当符合第二预定条件时，计费系统将所述所属的业务数据流中应用数据流所占的流量扣除，并结合扣除后所得的剩余流量以及所述业务计费相关信息，确定第二计费结果。

其中，所述第二预定条件包括任何启动计费系统进行第二计费结果计算时所应满足的条件。优选地，第二预定条件包括但不限于以下至少下一项：

更具体地，第二预定条件中所指CCR包括：

a)OCS对应用数据流以及业务数据流进行计费，但应用数据流的信用配额分配不会影响业务数据流的信用配额分配。则在此情况下，第二预定条件中所指CCR包括OCS接收到的任何用于为应用数据流请求分配信用配额的CCR。

然而，与对第一预定条件的说明类似的，在此情况下，由于业务数据流的业务计费相关信息由PCEF提供给OCS，则在PCC架构中，会存在从TDF以及PCEF至OCS的两个并行计费端口，并且，由于应用数据流包含于业务数据流中，也即，该两个并行计费端口发送的数据会使得OCS重复统计应用数据流的费用，因此，若需要计算业务数据流的第二计费结果，OCS需要关联(correlate)来自TDF以及PCEF的两个端口(如图1a-1d中的Gy’以及Gy)的数据，以避免对应用数据流的费用进行重复计算。

b)OCS对应用数据流以及业务数据流进行计费，且应用数据流以及业务数据流中任一者的信用配额分配会影响另一者的信用配额分配。则在此情况下，对于其中任一者的CCR会触发OCS发送重认证请求(Re-Authorization Request，RAR)，以为应用数据流及其所属业务数据流重新分配信用配额，并在执行重认证后执行计算第一计费结果的步骤。因此，第二预定条件中所指CCR包括基于重认证请求发起的CCR。

其中，OFCS可在多种情况下接收到上述计费请求。例如：

需要说明的是，上述第二预定条件仅为更好地说明本发明的技术方案，而非对本发明的限制，本领域技术人员应该理解，任何启动计费系统进行第二计费结果计算时所应满足的条件，均应包含在本发明的范围内。

具体地，当符合第二预定条件时，计费系统将应用数据流所属的业务数据流包含的所有应用数据流所占的流量扣除，并结合扣除后所得的剩余流量以及业务计费相关信息，确定第二计费结果。

例如，在步骤S3中，计费系统确定业务数据流Sever_Data_Flow_1为应用数据流Application_Data_Flow_1所属的业务数据流；且在本步骤执行之前，计费系统已确定业务数据流Sever_Data_Flow_1还包括应用数据流Application_Data_Flow_2以及Application_Data_Flow_3；则在本步骤中，计费系统将业务数据流Sever_Data_Flow_1包含的应用数据流Application_Data_Flow_1、Application_Data_Flow_2以及Application_Data_Flow_3在业务数据流Sever_Data_Flow_1中所占的流量扣除，并结合扣除后所得的、业务数据流Sever_Data_Flow_1中除应用数据流外的其他数据流的剩余流量以及业务计费相关信息，确定其他数据流的第二计费结果。

需要说明的是，上述举例仅为更好地说明本发明的技术方案，而非对本发明的限制，本领域技术人员应该理解，任何当符合第二预定条件时，将所述所属的业务数据流中应用数据流所占的流量扣除，并结合扣除后所得的剩余流量以及所述业务计费相关信息，确定第二计费结果的实现方式，均应包含在本发明的范围内。

需要说明的是，步骤S3和步骤S4，与步骤S2之间并无先后顺序。

需要进一步说明的是，计费系统可同时确定多个应用数据流所属业务数据流，并可同时对多个业务数据流执行步骤S4。

需要进一步说明的是，步骤S3执行之后，可立即执行S4；或者，步骤S3执行之后，可待满足第二预定条件时，才执行步骤S4。

本实施例中，能够避免同一用户会话由于TDF和PCEF存在并行计费端口导致的应用数据流重复计费。

作为本实施例的优选方案之一，本方案中，计费系统包括OCS，用户设备检测到其业务数据流的信用配额用尽或即将用尽时，向网络端发送用于请求分配业务数据流的信用配额的CCR，该CCR进一步为用于为业务数据流请求分配信用配额的第一业务信用额度分配请求(Gy Credit Request，CCRu)。

并且，本方案中，前述第二预定条件中所述基于RAR发送的CCR包括用于为应用数据流请求分配信用配额的第一应用信用额度分配请求(Gy’Credit Request，CCR update)，所述重认证请求包括应用重认证请求(Gy’RAR)。如图4所示，本方案的方法在步骤S4之前还包括步骤S5，前述为应用数据流及其所属业务数据流重新分配信用配额的步骤包括在步骤S4之前执行的步骤S6和S7以及在步骤S4之后执行的步骤S8和S9。

用户设备向网络端发送第一业务信用额度分配请求，并由PCC架构包含的网关接收。

在步骤S5中，OCS接收来自PCC架构包含的网关的第一业务信用额度分配请求。

接着，在步骤S6中，第一业务信用额度分配请求触发OCS向TDF发送应用重认证请求(Gy’RAR)。

接着，在步骤S7中，OCS接收TDF根据应用重认证请求反馈的应用重认证响应(Gy’Re-Authorization Answer，Gy’RAA)，该应用重认证响应包含所述第一应用信用额度分配请求。

需要说明的是，步骤S7可进一步分为多个步骤，例如，先接收TDE发送的用于响应RAR的RAA，再接收TDF发送的第一应用信用额度分配请求(Gy’Credit Response，CCRupdate)。

接着，OCS执行步骤S4；并且，OCS在步骤S8之前还执行步骤S2。

接着，在步骤S8中，OCS向所述流量检测功能反馈第一应用信用额度分配响应(Gy’Credit Response，CCR initial)。该第一应用信用额度分配响应中包含的应用数据流的信用配额可根据步骤S2的第一计算结果以及应用的总体可用信用配额来确定。

在步骤S9中，OCS向网关反馈第一业务信用额度分配响应(GyCredit Response，CCRu)。该第一业务信用额度分配响应中包含的业务数据流的信用配额可根据第一计算结果、第二计算结果以及业务的总体可用信用配额来确定。

需要说明的是，步骤S8和S9之间并无先后顺序。

需要进一步说明的是，应用计费相关信息可随应用重认证响应一起被发送给OCS；业务计费相关信息可随第一业务信用额度分配请求一起被发送给OCS。

作为本实施例的优选方案之一，本方案中，计费系统包括OCS，TDF检测到应用的应用数据流的信用配额用尽或即将用尽时，向OCS发送用于请求分配应用数据流的信用配额的CCR，该CCR进一步为用于为应用数据流请求分配信用配额的第二应用信用额度分配请求。

并且，本方案中，前述第二预定条件中所述基于RAR发送的CCR包括用于为业务数据流请求分配信用配额的第二业务信用额度分配请求，所述重认证请求包括第一业务重认证请求(Gy RAR)，如图5所示，本方案的方法在步骤S4之前还包括步骤S10，前述为应用数据流及其所属业务数据流重新分配信用配额的步骤包括在步骤S4之前执行的步骤S11和S12以及在步骤S4之后执行的步骤S13和S14。

在步骤S10中，OCS接收来自TDF的第二应用信用额度分配请求(Gy’CreditRequest，CCR update)。

接着，在步骤S11中，OCS向网关发送第一业务重认证请求(Gy RAR)。

接着，在步骤S12中，OCS接收网关反馈的第一业务重认证响应，该第一业务重认证响应包含所述第二业务信用额度分配请求。

需要说明的是，步骤S12可进一步分为多个步骤，例如，先接收TDE发送的用于响应RAR的RAA，再接收TDF发送的第二业务信用额度分配请求(Gy Credit Response，CCRu)。

接着，OCS执行步骤S4；并且，OCS在步骤S13之前还执行步骤S2。

在步骤S13中，OCS向TDF反馈第二应用信用额度分配响应。该第二应用信用额度分配响应中包含的应用数据流的信用配额可根据步骤S2的第一计算结果以及应用的总体可用信用配额来确定。

在步骤S14中，OCS向网关反馈第二业务信用额度分配响应。该第二业务信用额度分配响应中包含的业务数据流的信用配额可根据第一计算结果、第二计算结果以及业务的总体可用信用配额来确定。

需要说明的是，步骤S13和S14之间并无先后顺序。

需要进一步说明的是，应用计费相关信息可随第二应用信用额度分配请求一起被发送给OCS；业务计费相关信息可随第一业务重认证响应一起被发送给OCS。

作为本实施例的优选方案之一，本方案中，计费系统包括OCS，TDF接收到应用启动或停止的信息时，向OCS发送用于请求分配应用数据流的信用配额或终止应用数据流的信用配额的使用的CCR，优选地，该CCR进一步为应用信用额度使用终止请求。

并且，本方案中，前述第二预定条件中所述基于RAR发送的CCR包括用于为所述业务数据流请求分配信用配额的第三业务额度分配请求，所述重认证请求包括第二业务重认证请求，如图6所示，本方案的方法在步骤S4之前还包括步骤S15，前述为应用数据流及其所属业务数据流重新分配信用配额的步骤包括在步骤S4之前执行的步骤S16和S17以及在步骤S4之后执行的步骤S18和S19。

在步骤S15中，OCS接收来自TDF的应用信用额度使用终止请求。

接着，在步骤S16中，OCS向所述网关发送所述第二业务重认证请求。

接着，在步骤S17中，OCS接收所述网关反馈的第二业务重认证响应，该业务重认证响应包含所述第三业务额度分配请求。

需要说明的是，步骤S17可进一步分为多个步骤，例如，先接收TDE发送的用于响应RAR的RAA，再接收TDF发送的第三业务信用额度分配请求。

接着，OCS执行步骤S4；并且，OCS在步骤S18之前还执行步骤S2。

在步骤S18中，OCS向TDF反馈应用信用额度使用终止响应，则TDF向PDN/AF报告应用终止。

在步骤S19中，OCS向网关反馈第三业务信用额度分配响应。该第二业务信用额度分配响应中包含的业务数据流的信用配额可根据第一计算结果、第二计算结果以及业务的总体可用信用配额来确定。

需要说明的是，步骤S18和S19之间并无先后顺序。

需要进一步说明的是，应用计费相关信息可随应用信用额度使用终止请求一起被发送给OCS；业务计费相关信息可随第二业务重认证响应一起被发送给OCS。

需要说明的是，上述三个优选方案仅为更好地说明本发明的技术方案，而非对本发明的限制。

例如，如图7所示，在应用启动的过程中，也可执行步骤S2和S4。如图7，TDF收到应用启动信息后，向OCS发送信用控制请求，以请求OCS为该启动的应用的应用数据流分配信用额度，OCS根据该信用控制请求执行步骤S3，确定应用数据流所属业务数据流，并向网关发送业务重认证请求，网关根据该业务重认证请求反馈业务重认证应答，其中包含应用信用额度分配请求以及业务计费相关信息，并且，TDF在发送信用控制请求后向OCS发送应用计费相关信息(图未示)，则OCS执行步骤S2和S4，确定第一和第二计费结果，并为应用数据流及其所属业务数据流分配额度，并将所分配的信用额度通过信用控制应答分别提供给TDF和网关，TDF报告PDN/AF应用启动，并根据PDN/AF的反馈向外界反馈应用启动应答。

需要说明的是，前述网关根据该业务重认证请求反馈业务重认证应答的步骤可进一步分为多个步骤，例如，先发送用于响应RAR的RAA，再发送应用信用额度分配请求以及业务计费相关信息。

作为一种优选方案，PCC可在应用启动之前通过图8所示方法建立IP-CAN承载。

具体地，用户设备发起建立IP-CAN承载请求至PGW，以通过eNB和SGW，为应用流在LTE网络中建立IP-CAN。PGW/PCEF通过Gx参考点，发送IP-CAN会话建立请求指示至PCRF。当PCRF通过Gx参考点，接收到IP-CAN会话建立请求指示，该PCRF通过Sp参考点，向用户属性存储器SPR发送用户数据请求，以请求用户数据，该PCRF可以根据该用户数据，确定相应的计费控制规则。该SPR接收到该用户数据请求，进行匹配查询，获得用户数据，并通过该Sp参考点，发送用户数据响应至该PCRF，该用户数据响应中包括与该SPR匹配获得的用户数据。在此，该SPR包含有与所有用户或这些用户签约相关的信息，如用户允许的业务、每个允许业务的优先级、用户允许的QoS信息、用户的类型、用户业务的计费相关信息如接入类型、位置信息和使用次数等。该SPR可以根据服务提供商所提供的应用URL地址、或用户提供的用户信息等进行更新。该PCRF通过Sd参考点，发送会话建立请求(Session EstablishmentRequest)至该TDF，该会话建立请求包括该计费控制规则。该TDF接收到该计费控制规则，并根据该规则对应用或应用流进行检测，进一步地，通过Sd参考点，返回会话建立确认(Session Establishment Acknowledge)至该PCRF。该PCRF通过Gx参考点，返回IP-CAN会话建立响应指示，以授权该IP-CAN会话的建立。该PGW/PCEF执行接收自该PCRF的计费控制规则，并通过Gy参考点，发送信用控制请求至该OCS。该OCS根据该第二信用控制请求，并结合接收自该TDF的第一信用控制请求，运行计费引擎，确定计费控制信息，进一步地，根据该计费控制信息，生成信用控制应答，并返回至该PCEF。该PCEF根据该计费控制信息，执行接收自该PCRF的计费控制规则。该PGW确认该IP-CAN承载建立。

图9为本发明一个优选实施例的计费系统的结构示意图。本实施例的计费系统包括计费装置，该计费装置包括第一接收装置1以及第一计费装置2；本实施例的PCC架构包括计费系统和TDF，该计费系统与TDF之间具有应用计费端口，该应用计费端口向计费系统上报应用的应用计费相关信息，该应用计费端口的标准与前述Gy端口相同或相似；其中，本实施例的计费系统可仅包含一个单独的计费系统，也可包含相互独立的两个计费系统，如包含在线计费系统(以下简称“OCS”)以及离线计费系统(以下简称“OFCS”)。当本实施例的计费系统包含OCS以及OFCS时，OCS以及OFCS均可包括第一接收装置1以及第一计费装置2。更优选地，本实施例的PCC架构可为图1a-1d所示实施例中的任一PCC架构，前述应用计费端口为图1a-1d中的Gy’。

1)在线计费；

2)离线计费；

3)在线以及离线计费；

4)不计费。

1)基于容量的计费；

2)基于时间的计费；

3)基于容量和时间的计费；

4)基于事件的计费；

5)不计费。

以下说明本实施例中的第一接收装置1以及第一计费装置2。

第一接收装置1接收来自应用计费端口的、一个应用数据流的应用计费相关信息。

其中，一个应用数据流包括一个单独的应用的数据流。

1)应用所属用户设备的网络地址信息；

2)应用标识信息；

例如，应用标识符等。

3)应用使用时间信息；

4)应用的服务质量信息(QoS)；

例如，应用所属用户设备使用的带宽、网速等；

5)应用的流量等。

其中，第一接收装置1可在多种情况下接收TDF发送的应用计费相关信息。

例如，计费系统向TDF发送请求，第一接收装置1接收TDF反馈的应用计费相关信息。

又例如，TDF包括计费触发功能CTF，其检测应用，获取应用的应用计费相关信息，并根据ADC规则定义的计费机制，将应用计费相关信息发送给计费装置中的第一接收装置1。优选地，当应用计费相关信息中的任一项发生变化时，触发CTF向计费系统发送应用计费相关信息等。

优选地，应用计费相关信息与能够触发第一计费装置2的请求一起发送给计费系统；如与信用控制请求(Credit Control Request，CCR)一起发送给OCS，又如与计费请求一起发送给OFCS等。

当符合第一预定条件时，第一计费装置2根据所述应用计费相关信息，对所述应用数据流进行计费，获得第一计费结果。

更具体地，上述CCR包括：

a)OCS中的第一计费装置2仅对应用数据流进行计费，而不对业务数据流进行计费，则在此情况下，第一预定条件中所指CCR包括第一计费装置2接收到的任何CCR。

b)OCS中的第一计费装置2对应用数据流以及业务数据流进行计费，但应用数据流的信用配额分配不会影响业务数据流的信用配额分配；例如，仅限制应用的信用配额(如分别限制Skype、P2P、HTTP的信用配额)，而不限制业务的信用配额。则在此情况下，第一预定条件中所指CCR包括第一计费装置2接收到的任何用于为应用数据流请求分配信用配额的CCR。

然而，在此情况下，由于业务数据流的业务计费相关信息由PCEF提供给OCS，则在PCC架构中，会存在从TDF以及PCEF至OCS的两个并行计费端口，并且，由于应用数据流包含于业务数据流中，也即，该两个并行计费端口发送的数据会使得OCS重复统计应用数据流的费用，因此，若需要计算业务数据流的第二计费结果，OCS中的计费装置需要关联(correlate)来自TDF以及PCEF的两个端口(如图1a-1d中的Gy’以及Gy)的数据，以避免对应用数据流的费用进行重复计算。

c)OCS中的第一计费装置2对应用数据流以及业务数据流进行计费，且应用数据流以及业务数据流中任一者的信用配额分配会影响另一者的信用配额分配。则在此情况下，对于其中任一者的CCR会触发OCS发送重认证请求(Re-Authorization Request，RAR)，并在执行重认证后，第一计费装置2执行计算第一计费结果的操作。因此，第一预定条件中所述CCR包括基于重认证请求发起的CCR，该优选方案的具体实现方式将在后续实施例中予以说明。

其中，OFCS中的第一计费装置2可在多种情况下接收到上述计费请求。例如：

a)该计费请求可用户设备根据预先已确定的时间发送给网络端，并被第一计费装置2接收；

具体地，当符合第一预定条件时，第一计费装置2根据预确定的规则，基于应用计费相关信息来对所述应用数据流进行计费，获得应用数据流的第一计费结果。

例如，当接收到CCR，第一计费装置2根据应用标识信息来识别应用，并确定其收费标准，并根据应用使用时间信息确定第一计费结果等。

又例如，当OCS接收到PCC架构中的其他模块或设备，如TDF，发送的用于请求重新分配应用数据流的信用配额的CCR时，第一计费装置2根据应用计费相关信息包含的应用流量以及应用的服务质量信息，对应用的应用数据流进行计费，获得应用数据流的第一计费结果。

需要进一步说明的是，第一接收装置1执行操作，第一计费装置2可立即执行操作；或者，第一接收装置1执行操作，第一计费装置2可待满足第一预定条件时，才执行操作。

需要进一步说明的是，上述内容仅说明了计费装置对一个应用数据流进行计费的方式，事实上，计费装置可同时对多个应用数据流执行上述操作，获得该多个应用数据流的第一计费结果；更优选地，计费装置还可结合本次所得的第一计费结果以及应用的历史第一计费结果，来获得该应用的最终计费结果，例如，计费总和等。

图10为本发明一个优选实施例的计费系统的结构示意图。本实施例的计费装置对应用数据流以及业务数据流进行计费；本实施例的计费装置包括第一接收装置1、第一计费装置2、匹配装置3以及第二计费装置4；本实施例的PCC架构包括计费系统、TDF以及PCEF，该计费系统与TDF之间具有应用计费端口，该应用计费端口的标准与前述Gy端口相同或相似，该PCEF和计费执行功能之间具有业务计费端口，该业务计费端口向计费系统上报业务数据流的业务计费相关信息；其中，本实施例的计费系统可仅包含一个单独的计费系统，也可包含相互独立的两个计费系统，如包含OCS以及OFCS。当本实施例的计费系统包含OCS以及OFCS时，OCS以及OFCS均可包括第一接收装置1、第一计费装置2、匹配装置3以及第二计费装置4。更优选地，本实施例的PCC架构可为图1a-1d所示实施例中的任一PCC架构，前述应用计费端口为图1a-1d中的Gy’，前述业务计费端口为图1a-1d中的Gy。

其中，第一接收装置1和第一计费装置2已在参照图9所示实施例中予以详述，在此不再赘述。

本实施例中，第一接收装置1获得的应用计费相关信息包括能够标识所述应用数据流所属业务数据流的第一识别信息；优选地，应用计费相关信息还包括如参照图2所示实施例中所述的应用所属用户设备的网络地址信息、应用标识信息、应用使用时间信息、应用的服务质量信息、应用的流量等。其中，第一识别信息可由网关通过端口Gx提供给PCRF，再由PCRF提供给TDF。

优选地，第一标识信息包括但不限于以下至少一项：

1)PDN-连接-Id(PDN-Connection-Id)；

2)P-GW/SGSN地址；

3)用户预约ID(User Subscription ID)；

4)价格组ID(Rating group ID)；

5)业务ID(Service ID)。

由上述信息，计费系统能够确定业务数据流。

匹配装置3将应用计费相关信息中的第一识别信息与已接收到的用于标识业务数据流的至少一个第二标识信息相匹配，并将相匹配的第二标识信息所对应的业务数据流作为所述应用数据流所属的业务数据流，其中，所述第二标识信息包含于所述业务数据流的业务计费相关信息中，所述业务计费相关信息来自所述业务计费端口。

其中，各个业务数据流的业务计费相关信息在匹配装置3执行操作之前由PCEF通过业务计费端口上报给计费系统，该业务计费相关信息可包含任何与业务数据流的计费相关的信息。优选地，业务计费相关信息可包含于发送给计费系统的CCR中。

具体地，匹配装置3将第一标识信息与第二标识信息进行匹配，当应用数据流的第一标识信息与一个业务数据流的第二标识信息相匹配时，将相匹配的相匹配的第二标识信息所对应的业务数据流作为所述应用数据流所属的业务数据流。

例如，应用数据流Application_Data_Flow_1的第一标识信息包括PDN-连接-Id、P-GW/SGSN地址、用户预约ID、价格组ID以及业务ID，匹配装置3将上述五个信息与各个业务数据流的第二标识信息中类型相同的五个信息进行比对，并比对得到一个业务数据流Sever_Data_Flow_1的第二标识信息中的PDN-连接-Id、P-GW/SGSN地址、用户预约ID、价格组ID以及业务ID，与应用数据流Application_Data_Flow_1的第一标识信息中的类型对应的信息均相同时，判断应用数据流Application_Data_Flow_1的第一标识信息与业务数据流Sever_Data_Flow_1的第二标识信息相匹配，该业务数据流Sever_Data_Flow_1为应用数据流Application_Data_Flow_1所属的业务数据流。

当符合第二预定条件时，第二计费装置4将所述所属的业务数据流中应用数据流所占的流量扣除，并结合扣除后所得的剩余流量以及所述业务计费相关信息，确定第二计费结果。

更具体地，第二预定条件中所指CCR包括：

a)第二计费装置4对应用数据流以及业务数据流进行计费，但应用数据流的信用配额分配不会影响业务数据流的信用配额分配。则在此情况下，第二预定条件中所指CCR包括OCS接收到的任何用于为应用数据流请求分配信用配额的CCR。

然而，与对第一预定条件的说明类似的，在此情况下，由于业务数据流的业务计费相关信息由PCEF提供给OCS，则在PCC架构中，会存在从TDF以及PCEF至OCS的两个并行计费端口，并且，由于应用数据流包含于业务数据流中，也即，该两个并行计费端口发送的数据会使得OCS重复统计应用数据流的费用，因此，若需要计算业务数据流的第二计费结果，匹配装置4需要关联(correlate)来自TDF以及PCEF的两个端口(如图1a-1d中的Gy’以及Gy)的数据，以避免对应用数据流的费用进行重复计算。

b)OCS中的第二计费装置4对应用数据流以及业务数据流进行计费，且应用数据流以及业务数据流中任一者的信用配额分配会影响另一者的信用配额分配。则在此情况下，对于其中任一者的CCR会触发OCS发送重认证请求(Re-Authorization Request，RAR)，以使计费装置中的分配装置(图未示)为应用数据流及其所属业务数据流重新分配信用配额，并在执行重认证后执行计算第一计费结果的操作。因此，第二预定条件中所指CCR包括基于重认证请求发起的CCR。

其中，OFCS可在多种情况下接收到上述计费请求。例如：

具体地，当符合第二预定条件时，第二计费装置4将应用数据流所属的业务数据流包含的所有应用数据流所占的流量扣除，并结合扣除后所得的剩余流量以及业务计费相关信息，确定第二计费结果。

例如，匹配装置3确定业务数据流Sever_Data_Flow_1为应用数据流Application_Data_Flow_1所属的业务数据流；且在第二计费装置4执行操作之前，匹配装置3已确定业务数据流Sever_Data_Flow_1还包括应用数据流Application_Data_Flow_2以及Application_Data_Flow_3；则第二计费装置4将业务数据流Sever_Data_Flow_包含的应用数据流Application_Data_Flow_1、Application_Data_Flow_2以及Application_Data_Flow_3在业务数据流Sever_Data_Flow_1中所占的流量扣除，并结合扣除后所得的、业务数据流Sever_Data_Flow_1中除应用数据流外的其他数据流的剩余流量以及业务计费相关信息，确定其他数据流的第二计费结果。

需要说明的是，匹配装置3和第二计费装置4，与第一计费装置2执行的操作之间并无先后顺序。

需要进一步说明的是，计费系统可同时确定多个应用数据流所属业务数据流，并可同时对多个业务数据流执行操作。

需要进一步说明的是，匹配装置3执行操作之后，第二计费装置4可立即执行操作；或者，匹配装置3执行操作之后，第二计费装置4可待满足第二预定条件时，才执行操作。

并且，本方案中，前述第二预定条件中所述基于RAR发送的CCR包括用于为应用数据流请求分配信用配额的第一应用信用额度分配请求(Gy’Credit Request，CCR update)，所述重认证请求包括应用重认证请求(Gy’RAR)。本方案的计费装置还包括在第二计费装置4之前执行操作的第二接收装置(图未示)，分配装置包括在第二计费装置4之前执行操作的第一发送装置(图未示)、第三接收装置(图未示)以及在第二计费装置4后前执行操作的第一反馈装置(图未示)、第二反馈装置(图未示)。

第二接收装置接收来自PCC架构包含的网关的第一业务信用额度分配请求。

接着，在第一业务信用额度分配请求触发OCS中的第一发送装置向TDF发送应用重认证请求。

接着，第三接收装置接收TDF根据应用重认证请求反馈的应用重认证响应(Gy’Re-Authorization Answer，Gy’RAA)，该应用重认证响应包含所述第一应用信用额度分配请求。

需要说明的是，第三接收装置可执行多次接收操作，例如，先接收TDE发送的用于响应RAR的RAA，再接收TDF发送的第一应用信用额度分配请求。

接着，第二计费装置4执行操作；并且，第一计费装置在第一反馈装置之前执行操作。

第一反馈装置向所述流量检测功能反馈第一应用信用额度分配响应(Gy’CreditResponse，CCR initial)。该第一应用信用额度分配响应中包含的应用数据流的信用配额可根据第一计算结果以及应用的总体可用信用配额来确定。

第二反馈装置向网关反馈第一业务信用额度分配响应(Gy Credit Response，CCRu)。该第一业务信用额度分配响应中包含的业务数据流的信用配额可根据第一计算结果、第二计算结果以及业务的总体可用信用配额来确定。

需要说明的是，第一反馈装置和第二反馈装置执行的操作之间并无先后顺序。

并且，本方案中，前述第二预定条件中所述基于RAR发送的CCR包括用于为业务数据流请求分配信用配额的第二业务信用额度分配请求，所述重认证请求包括第一业务重认证请求(Gy RAR)，本方案的计费装置还包括在第二计费装置4之前执行操作的第四接收装置(图未示)，分配装置包括在第二计费装置4之前执行操作的第二发送装置(图未示)、第五接收装置(图未示)以及在第二计费装置4后前执行操作的第三反馈装置(图未示)、第四反馈装置(图未示)。

第四接收装置接收来自TDF的第二应用信用额度分配请求。

接着，第二发送装置向网关发送第一业务重认证请求。

接着，第五接收装置接收网关反馈的第一业务重认证响应，该第一业务重认证响应包含所述第二业务信用额度分配请求。

需要说明的是，第五接收装置可执行多次接收操作，例如，先接收TDE发送的用于响应RAR的RAA，再接收TDF发送的第二业务信用额度分配请求。

第三反馈装置向TDF反馈第二应用信用额度分配响应。该第二应用信用额度分配响应中包含的应用数据流的信用配额可根据第一计算结果以及应用的总体可用信用配额来确定。

第四反馈装置向网关反馈第二业务信用额度分配响应。该第二业务信用额度分配响应中包含的业务数据流的信用配额可根据第一计算结果、第二计算结果以及业务的总体可用信用配额来确定。

需要说明的是，第三反馈装置和第四反馈装置执行的操作之间并无先后顺序。

并且，本方案中，前述第二预定条件中所述基于RAR发送的CCR包括用于为所述业务数据流请求分配信用配额的第三业务额度分配请求，所述重认证请求包括第二业务重认证请求，本方案的计费装置还包括在第二计费装置4之前执行操作的第六接收装置(图未示)，分配装置包括在第二计费装置4之前执行操作的第三发送装置(图未示)、第七接收装置(图未示)以及在第二计费装置4后前执行操作的第五反馈装置(图未示)、第六反馈装置(图未示)。

第六接收装置接收来自TDF的应用信用额度使用终止请求。

接着，第三发送装置向所述网关发送所述第二业务重认证请求。

接着，第七接收装置接收所述网关反馈的第二业务重认证响应，该业务重认证响应包含所述第三业务额度分配请求。

需要说明的是，第六接收装置可执行多次接收操作，例如，先接收TDE发送的用于响应RAR的RAA，再接收TDF发送的第三业务信用额度分配请求。

第五反馈装置向TDF反馈应用信用额度使用终止响应，则TDF向PDN/AF报告应用终止。

第六反馈装置向网关反馈第三业务信用额度分配响应。该第二业务信用额度分配响应中包含的业务数据流的信用配额可根据第一计算结果、第二计算结果以及业务的总体可用信用配额来确定。

需要说明的是，第五反馈装置和第六反馈装置执行的操作之间并无先后顺序。

例如，如图7所示，在应用启动的过程中，第一计费装置2以及第二计费装置4也可执行操作。例如，TDF收到应用启动信息后，向OCS发送信用控制请求，以请求OCS为该启动的应用的应用数据流分配信用额度，根据该信用控制请求，匹配装置3执行操作，确定应用数据流所属业务数据流，并向网关发送业务重认证请求，网关根据该业务重认证请求反馈业务重认证应答，其中包含应用信用额度分配请求以及业务计费相关信息，并且，TDF在发送信用控制请求后向OCS发送应用计费相关信息(图未示)，则OCS中的第一计费装置2以及第二计费装置4执行操作，确定第一和第二计费结果，并为应用数据流及其所属业务数据流分配额度，OCS将所分配的信用额度通过信用控制应答分别提供给TDF和网关，TDF报告PDN/AF应用启动，并根据PDN/AF的反馈向外界反馈应用启动应答。

需要说明的是，网关所执行的所述根据该业务重认证请求反馈业务重认证应答的操作可进一步分为多个操作，例如，先发送用于响应RAR的RAA，再发送应用信用额度分配请求以及业务计费相关信息。

作为一种优选方案，PCC可在应用启动之前通过如下方式建立IP-CAN承载。

需要注意的是，本发明可在软件和/或软件与硬件的组合体中被实施，例如，本发明的计费装置可采用专用集成电路(ASIC)或任何其他类似硬件设备来实现。在一个实施例中，本发明的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本发明的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本发明的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。系统权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims

1.一种在PCC架构包含的计费系统中用于进行计费的方法，其中，所述计费系统与包含于所述PCC架构中的流量检测功能之间具有应用计费端口，所述PCC架构还包括策略和计费执行功能，所述计费系统与所述策略和计费执行功能之间具有业务计费端口，该方法包括以下步骤：

a接收来自所述应用计费端口的、一个应用数据流的应用计费相关信息，所述应用计费相关信息包括能够标识所述应用数据流所属业务数据流的第一识别信息；

b当符合第一预定条件时，根据所述应用计费相关信息，对所述应用数据流进行计费，获得第一计费结果；

其中，该方法还包括以下步骤：

x将所述第一识别信息与已接收到的用于标识业务数据流的至少一个第二标识信息相匹配，并将相匹配的第二标识信息所对应的业务数据流作为所述应用数据流所属的业务数据流，其中，所述第二标识信息包含于所述业务数据流的业务计费相关信息中，所述业务计费相关信息来自所述业务计费端口；

y当符合第二预定条件时，将所述所属的业务数据流中应用数据流所占的流量扣除，并结合扣除后所得的剩余流量以及所述业务计费相关信息，确定第二计费结果。

2.根据权利要求1所述的方法，其中，所述第一预定条件和/或所述第二预定条件包括以下至少一项：

-接收到基于重认证请求发起的信用控制请求；

-接收到计费请求。

3.根据权利要求2所述的方法，其中，所述第一预定条件和/或所述第二预定条件包括所述信用控制请求，该方法还包括以下步骤：

i为所述应用数据流及其所属业务数据流重新分配信用配额。

4.根据权利要求3所述的方法，其中，所述信用控制请求包括用于为所述应用数据流请求分配信用配额的第一应用信用额度分配请求，所述重认证请求包括应用重认证请求，该方法在所述步骤y之前还包括以下步骤：

-接收来自所述PCC架构包含的网关的第一业务信用额度分配请求；

其中，所述步骤i在所述步骤y之前包括以下步骤：

-向所述流量检测功能发送所述应用重认证请求；

-接收所述流量检测功能反馈的应用重认证响应，该应用重认证响应包含所述第一应用信用额度分配请求；

其中，所述步骤i在所述步骤y之后还包括以下步骤：

-向所述流量检测功能反馈第一应用信用额度分配响应；

-向所述网关反馈第一业务信用额度分配响应。

5.根据权利要求3所述的方法，其中，所述信用控制请求包括用于为所述业务数据流请求分配信用配额的第二业务信用额度分配请求，所述重认证请求包括第一业务重认证请求，该方法在所述步骤y之前还包括以下步骤：

-接收来自所述流量检测功能的第二应用信用额度分配请求；

其中，所述步骤i在所述步骤y之前包括以下步骤：

-向网关发送第一业务重认证请求；

-接收所述网关反馈的第一业务重认证响应，该第一业务重认证响应包含所述第二业务信用额度分配请求；

其中，所述步骤i在所述步骤y之后还包括以下步骤：

-向所述流量检测功能反馈第二应用信用额度分配响应；

-向所述网关反馈第二业务信用额度分配响应。

6.根据权利要求3所述的方法，其中，该信用控制请求包括用于为所述业务数据流请求分配信用配额的第三业务额度分配请求，所述重认证请求包括第二业务重认证请求，该方法在所述步骤y之前还包括以下步骤：

-接收来自所述流量检测功能的应用信用额度使用终止请求；

其中，所述步骤i在所述步骤y之前包括以下步骤：

-向网关发送所述第二业务重认证请求；

-接收所述网关反馈的第二业务重认证响应，该业务重认证响应包含所述第三业务额度分配请求；

其中，所述步骤i在所述步骤y之后还包括以下步骤：

-向所述流量检测功能反馈应用信用额度使用终止响应；

-向所述网关反馈第三业务信用额度分配响应。

7.一种在PCC架构包含的计费系统中用于进行计费的计费装置，其中，所述计费系统与包含于所述PCC架构中的流量检测功能之间具有应用计费端口，所述PCC架构还包括策略和计费执行功能，所述计费系统与所述策略和计费执行功能之间具有业务计费端口，该计费装置包括：

第一接收装置，用于接收来自所述应用计费端口的、一个应用数据流的应用计费相关信息，所述应用计费相关信息包括能够标识所述应用数据流所属业务数据流的第一识别信息；

第一计费装置，用于当符合第一预定条件时，根据所述应用计费相关信息，对所述应用数据流进行计费，获得第一计费结果；

其中，该计费装置还包括：

匹配装置，用于将所述第一识别信息与已接收到的用于标识业务数据流的至少一个第二标识信息相匹配，并将相匹配的第二标识信息所对应的业务数据流作为所述应用数据流所属的业务数据流，其中，所述第二标识信息包含于所述业务数据流的业务计费相关信息中，所述业务计费相关信息来自所述业务计费端口；

第二计费装置，用于当符合第二预定条件时，将所述所属的业务数据流中应用数据流所占的流量扣除，并结合扣除后所得的剩余流量以及所述业务计费相关信息，确定第二计费结果。

8.根据权利要求7所述的计费装置，其中，所述第一预定条件和/或所述第二预定条件包括以下至少一项：

-接收到基于重认证请求发起的信用控制请求；

-接收到计费请求。

9.根据权利要求8所述的计费装置，其中，所述第一预定条件和/或所述第二预定条件包括所述信用控制请求，该计费装置还包括：

分配装置，用于为所述应用数据流及其所属业务数据流重新分配信用配额。

10.根据权利要求9所述的计费装置，其中，所述信用控制请求包括用于为所述应用数据流请求分配信用配额的第一应用信用额度分配请求，所述重认证请求包括应用重认证请求，该计费装置还包括在所述第二计费装置之前执行操作的以下装置：

第二接收装置，用于接收来自所述PCC架构包含的网关的第一业务信用额度分配请求；

其中，所述分配装置包括在所述第二计费装置之前执行操作的以下装置：

第一发送装置，用于向所述流量检测功能发送所述应用重认证请求；

第三接收装置，用于接收所述流量检测功能反馈的应用重认证响应，该应用重认证响应包含所述第一应用信用额度分配请求；

其中，所述分配装置还包括在所述第二计费装置之后执行操作的以下装置：

第一反馈装置，用于向所述流量检测功能反馈第一应用信用额度分配响应；

第二反馈装置，用于向所述网关反馈第一业务信用额度分配响应。

11.根据权利要求9所述的计费装置，其中，所述信用控制请求包括用于为所述业务数据流请求分配信用配额的第二业务信用额度分配请求，所述重认证请求包括第一业务重认证请求，该计费装置还包括在所述第二计费装置之前执行操作的以下装置：

第四接收装置，用于接收来自所述流量检测功能的第二应用信用额度分配请求；

第二发送装置，用于向网关发送第一业务重认证请求；

第五接收装置，用于接收所述网关反馈的第一业务重认证响应，该第一业务重认证响应包含所述第二业务信用额度分配请求；

第三反馈装置，用于向所述流量检测功能反馈第二应用信用额度分配响应；

第四反馈装置，用于向所述网关反馈第二业务信用额度分配响应。

12.根据权利要求9所述的计费装置，其中，该信用控制请求包括用于为所述业务数据流请求分配信用配额的第三业务额度分配请求，所述重认证请求包括第二业务重认证请求，该计费装置还包括在所述第二计费装置之前执行操作的以下装置：

第六接收装置，用于接收来自所述流量检测功能的应用信用额度终止请求；

第三发送装置，用于向网关发送第二业务重认证请求；

第七接收装置，用于接收所述网关反馈的第二业务重认证响应，该业务重认证响应包含第三应用业务额度分配请求；

第五反馈装置，用于向所述流量检测功能反馈应用信用额度终止响应；

第六反馈装置，用于向所述网关反馈第三业务信用额度分配响应。

13.根据权利要求7至12中任一项所述的计费装置，其中，所述计费系统包括在线费系统以及离线计费系统，所述在线计费系统以及所述离线计费系统均包含所述第一接收装置以及所述第一计费装置。