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

摘要

本发明的目的是提供一种在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 GPRS Support 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中，当符合第二预定条件时，计费系统将所述所属的业务 数据流中应用数据流所占的流量扣除，并结合扣除后所得的剩余流量以 及所述业务计费相关信息，确定第二计费结果。

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

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

更具体地，第二预定条件中所指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。

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

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

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

b)OFCS向用户设备请求发送上述计费请求，则用户设备根据 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，CCR update)。

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

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

在步骤S9中，OCS向网关反馈第一业务信用额度分配响应(Gy Credit 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’Credit Request，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 Establishment Request)至该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’。

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

1)在线计费；

2)离线计费；

3)在线以及离线计费；

4)不计费。

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

1)基于容量的计费；

2)基于时间的计费；

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

4)基于事件的计费；

5)不计费。

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

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

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

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

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

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

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

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

2)应用标识信息；

例如，应用标识符等。

3)应用使用时间信息；

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

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

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

5)应用的流量等。

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

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

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

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

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

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

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

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

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

更具体地，上述CCR包括：

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

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

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

又例如，CCR包括TDF接收到应用启动或停止的信息时，向OCS 发送的、用于请求分配应用数据流的信用配额或终止应用数据流的信 用配额的使用的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，该优选 方案的具体实现方式将在后续实施例中予以说明。

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

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

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

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

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

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

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

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

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

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

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

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

图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中。

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

具体地，匹配装置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将所述所属的业务数据流 中应用数据流所占的流量扣除，并结合扣除后所得的剩余流量以及所述 业务计费相关信息，确定第二计费结果。

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

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

更具体地，第二预定条件中所指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。

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

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

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

b)OFCS向用户设备请求发送上述计费请求，则用户设备根据 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可待满足第二预定条件时，才执行操作。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作为一种优选方案，PCC可在应用启动之前通过如下方式建立 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 Establishment Request)至该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承载建立。

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

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