CN110324153A - 计费方法以及系统 - Google Patents

Abstract

本申请实施例公开了计费方法以及系统，用于实现对数据业务进行精确的在线计费，确保用户不会出现欠费的情况，提高了数据计费的准确性。本申请实施例方法包括：接收网关发送的第一CCR‑U；确定用户设备的扣费规则已由第一扣费规则变更为第二扣费规则；根据第一扣费规则对用户设备的第一累计已使用业务流量进行扣费，得到用户设备的剩余费用，第一累计已使用业务流量是累计在第一扣费规则变更为第二扣费规则之前的已使用业务流量；为用户设备预留再授权业务流量；根据第二扣费规则，为用户设备预留与再授权业务流量相应的费用；向网关发送CCA‑U，以使得网关允许用户设备使用再授权业务流量，CCA‑U包含再授权业务流量。

Description

计费方法以及系统

技术领域

本申请涉及通信领域，尤其涉及通信领域中的计费方法以及计费系统。

背景技术

随着物联网(internet of things,IOT)的风起云涌，各运营商对当前主流的IOT运营支撑系统的计费功能提出了更高要求，要求IOT业务能够支持在线实时业务需求，提升IOT业务的体验，并通过降低用户的欠费风险来降低运营成本，这样就迫切需要提升IOT运营支撑系统中实时计费系统的性能。IOT业务计费中非常重要的计费功能是数据的业务流量计费(参见图1)，其在IOT业务中占比达到80％以上，提升IOT的数据业务计费的性能能够大幅提升IOT运营支撑系统中实时计费系统的性能。

在现有技术方案中，虽然可以提升IOT的数据业务计费的性能，但会产生计费不准确的问题。

发明内容

本申请实施例提供了一种计费方法以及系统，用于实现对数据业务进行精确的在线计费，确保用户不会出现欠费的情况，提高了数据计费的准确性。

本申请实施例第一方面提供了一种业务处理方法，包括：

计费系统首先接收网关发送的第一信用控制更新请求(credit control requestupdate,CCR-U)，该CCR-U请求消息用于请求扣除已使用但尚未扣费的业务流量所产生的费用以及请求继续授权业务流量(即再授权业务流量)，然后，计费系统可以累计已使用但未扣费的业务流量，随后，计费系统可以判断用户设备的扣费规则是否已由第一扣费规则变更为第二扣费规则，该用户设备为向网关发送请求再授权业务流量的设备；当计费系统确定用户设备的扣费规则已由第一扣费规则变更为第二扣费规则时，则所述计费系统可以根据所述第一扣费规则对所述用户设备的所述第一累计已使用业务流量进行扣费，得到所述用户设备的剩余费用，所述第一累计已使用业务流量累计的是用户设备在所述第一扣费规则变更为所述第二扣费规则之前的已使用业务流量；然后所述计费系统可以为用户设备预留所述再授权业务流量；接着，计费系统会根据所述第二扣费规则为所述用户设备预留与所述再授权业务流量相应的费用；最后所述计费系统可以向所述网关发送信用控制更新应答(credit control answer update,CCA-U)，所述CCA-U包含所述在授权业务流量，从而使所述网关允许所述用户设备使用所述再授权业务流量。

本申请实施例中的计费系统可以是融合计费系统(Convergent Billing System,CBS)或者在线计费系统(Online Charging System,OCS)，也可以是由多个设备组合而成的系统。本申请实施例中的网关可以是网关通用分组无线业务支持节点(gateway ofgeneral packet radio service support node,GGSN)，也可以是服务通用分组无线业务支持节点(services of general packet radio service support node，SGSN)。本申请实施例中的用户设备可以是汽车、移动电话、平板电脑或笔记本电脑等。

本申请实施例中，由于在计费系统接收到网关发送的请求扣除已使用业务流量所产生费用以及再授权业务流量的CCR-U消息后，计费系统首先会累计第一累计已使用业务流量，然后当计费系统能够确定用户设备的扣费规则由第一扣费规则变更为第二扣费规则时，会根据第一扣费规则对第一累计已使用业务流量进行扣费，然后预留用户设备请求的再授权业务流量，并根据第二扣费规则为用户设备预留与再授权业务流量相应的费用，这样当计费系统再次接收到新的CCR-U消息时，计费系统就可以按照变更后的扣费规则对重新累计并且已使用的再授权业务流量扣费，从而实现对数据业务进行精确的在线计费，确保用户不会出现欠费的情况，提高了计费系统的准确性。

基于本申请实施例第一方面，本申请实施例第一方面的第一种实施方式

中，所述确定所述用户设备的扣费规则已由所述第一扣费规则变更为所述第二扣费规则包括：

所述计费系统可以根据所述用户设备的所述扣费规则的变更日志，确定所述用户设备的所述扣费规则已经由所述第一扣费规则变更为所述第二扣费规则，该变更日志经由客户关系管理系统(customer relationship management system,CRM)发送到计费系统。

本申请实施例中，计费系统可以通过用户设备的扣费规则的变更日志，获知用户设备的扣费规则发生了变更，于是可以对扣费规则发生变更前所累计的已使用业务流量按照变更前的扣费规则进行扣费，并按照变更后的扣费规则为用户设备预留再授权业务流量，这样就可以精确计算用户设备所使用费用，确保用户不会出现欠费的情况，提升了计费系统计费的精确度。

基于本申请实施例第一方面的第一种实施方式，本申请实施例第一方面的第二种实施方式中，在所述确定所述用户设备的扣费规则已由所述第一扣费规则变更为所述第二扣费规则之前，所述方法还包括：

所述计费系统可以在接收到CRM发送的扣费规则变更请求消息后，记录并存储所述变更日志。

本申请实施例中，计费系统通过存储扣费规则的变更日志，从而能够根据该变更日志确定扣费规则发生了变更，因此才可以对用户设备的已使用业务流量进行正确的计费以及为下一个再授权业务流量预留正确的相应费用，因此提高了计费系统计费的精确度，能够实现精确的在线计费。

基于本申请实施例第一方面的第二种实施方式，本申请实施例第一方面的第三种实施方式中，根据所述第二扣费规则，为所述用户设备预留与所述再授权业务流量相应的费用包括：

计费系统可以根据所述用户设备的所述剩余费用以及所述第二扣费规则(即变更后的扣费规则)，为所述用户设备预留与所述再授权业务流量相应的费用。如果剩余费用不足，则计费系统只能够根据剩余费用以及第二扣费规则，计算出可以预留给用户设备的相应费用。

本申请实施例中，计费系统将剩余费用与变更后的扣费规则这两个条件结合在一起，基于这两个条件计算与再授权业务流量相应的费用，因此不会出现余额不足而授权的业务流量所对应的金额却高于余额数目的错误，从而进一步提高了计费系统在线计费的精确度，进一步提升了计费系统的准确性。

基于本申请实施例第一方面，本申请实施例第一方面的第四种实施方式中，在根据所述第一扣费规则对所述用户设备的第一累计已使用业务流量进行扣费之后，所述方法还包括：

计费系统对所述第一累计已使用业务流量清零。

本申请实施例中，计费系统在对第一累计已使用业务流量按照变更前的扣费规则进行扣费后，对第一累计已使用业务流量清零，就可以确保在后续的步骤流程中对扣费规则变更后重新累计的业务流量按照变更后的扣费规则预留相应费用并进行扣费，从而确保计费系统计费的准确性。

基于本申请实施例第一方面，本申请实施例第一方面的第五种实施方式中，在接收网关发送的所述第一信用控制更新请求CCR-U消息之前，所述方法还包括：

所述计费系统接收所述网关发送的第二CCR-U消息，然后所述计费系统判断所述用户设备的所述扣费规则是否从所述第一扣费规则变更为所述第二扣费规则，如果所述计费系统确定所述用户设备的所述扣费规则没有从所述第一扣费规则变更为所述第二扣费规则，则所述计费系统可以为用户设备累计第二累计已使用业务流量，所述第一累计已使用业务流量包含所述第二累计已使用业务流量，当计费系统在接收到所述第一CCR-U消息之前只接收到一个所述第二CCR-U消息，则所述第一累计已使用业务流量等于所述第二累计已使用业务流量，当计费系统在接收到所述第一CCR-U消息之前接收到两个以上所述第二CCR-U消息，则所述第一累计已使用业务流量等于两个以上所述CCR-U消息累积下来的已使用业务流量，然后，所述计费系统为所述用户设备预留所述再授权业务流量，并按照没有发生变更的扣费规则(即第一扣费规则)为所述用户设备预留与所述再授权业务流量相应的费用。

本申请实施例中，计费系统可以在确定扣费规则没有发生变更时，只是累计用户设备的第二累计已使用业务流量，而不会对第二累计已使用业务流量进行扣费，并还是按照没有发生变更的扣费规则为用户设备预留再授权业务流量，这样通过裁减扣费步骤，从而大幅提升了计费系统的运营性能，节约了设备的运营成本。

基于本申请实施例第一方面，本申请实施例第一方面的第一种实施方式至第五种实施方式中的任意一种实施方式，本申请第六种实施方式中，所述扣费规则可以为套餐的收费标准或者资费规则。

本申请实施例中，扣费规则有多种选项，因此提高了实现方案的灵活性和可实现性。

本申请实施例第二方面提供了一种计费系统，该计费系统具有实现上述第一方面中计费系统行为的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第三方面提供了一种计算机存储介质，该计算机存储介质用于储存为上述第二方面的计费系统所用的计算机软件指令，其包括用于执行为计费系统所设计的程序。

本申请实施例第四方面提供了一种计算机程序产品，该计算机程序产品包括计算机软件指令，该计算机软件指令可通过处理器进行加载来实现上述第一方面的方法流程。

附图说明

图1为本申请实施例中的一种计费系统的框架示意图；

图2为本申请实施例中计费方法流程示意图；

图3为本申请实施例中计费方法的另一流程示意图；

图4为本申请实施例中计费方法的另一流程示意图；

图5为本申请实施例中计费方法的另一流程示意图；

图6为本申请实施例中计费系统的单元组成示意图；

图7为本申请实施例中计费系统的另一单元组成示意图；

图8为本申请实施例中计费系统的硬件结构示意图。

具体实施方式

本申请实施例提供了一种计费的方法以及系统，用于实现对数据业务进行精确的在线计费，确保用户不会出现欠费的情况，提高了数据计费系统的准确性。

请参阅图1，图1为用户设备如何通过计费网络获得业务流量的结构示意图，如图1所示，该计费网络主要包括：用户设备10、网关20、计费系统30以及客户关系管理系统CRM40。下面首先对用户设备10、网关20、计费系统30以及CRM40分别进行说明。

用户设备10包括汽车、移动电话、平板电脑、笔记本电脑等。

网关20是用于计费交互的网元，负责转发计费和授权流量的请求以及响应消息的对话管理功能，网关20可以包括GGSN和SGSN，也可以只包括GGSN或SGSN。

GGSN是通用分组无线业务(general packet radio service,GPRS)网络中的关键部分，用于GPRS网络和外部分组交换网络(例如Internet，X.25，wimax)之间的交互。从外部网络看，GGSN就是一个子网的路由器，因为GGSN对外部网络隐藏了GPRS的底层结构。当GGSN接收到一个指定用户的数据时，会检查用户是否是活动的。如果是，GGSN将数据转发给SGSN来服务用户，如果用户是不活动的，则丢弃数据包。GGSN使得GPRS/通用移动通信系统(universal mobile telecommunications system,UMTS)网络中的终端具有了移动的能力。GGSN将来自SGSN的GPRS分组转换成外部网络对应的格式，然后发送给对应的分组数据网络。反过来，GGSN将外部网络的数据转换成全球移动通信系统(global system formobile communications,GSM)的地址格式的报文，再发送给对应的SGSN。因此，GGSN存储了用户当前GSN的地址及其位置寄存器(location register,LR)的属性(profile)。GGSN负责当前连接的用户设备的IP地址分配和默认路由，GGSN还具有认证和计费的功能。

SGSN是用于收发用户的分组数据包，其功能包括分组路由和传输、移动管理、逻辑链路管理、认证和计费。SGSN的位置寄存器存储了SGSN中注册的所有用户的位置信息{例如当前小区，拜访位置寄存器(visitor location register),VLR}和个人信息{国际移动用户识别码(international mobile subscriber identification number,IMSI)，地址}等。

计费系统30可以是CBS或者OCS，也可以是由多个设备组合而成的系统。

CRM40是以客户数据的管理为核心，利用信息科学技术，实现市场营销、销售、服务等活动自动化，并建立一个客户信息的收集、管理、分析、利用的系统，帮助企业实现以客户为中心的管理模式。CRM40主要有高可控性的数据库、更高的安全性、数据实时更新等特点，提供日程管理、订单管理、发票管理、知识库管理等功能。

基于上述图1的系统框架，请参阅图2，以下结合图2对本申请实施例中计费方法的实施例按照如下步骤流程进行说明：

步骤201、用户设备10向网关20发送开始使用业务流量的业务请求消息；

当用户设备10需要使用数据业务时，就会向网关20发送开始使用业务流量的请求消息。

步骤202、网关20向计费系统30发送信用控制初始请求(credit control requestinitial,CCR-I)；

网关20在接收到用户设备发送的请求消息后，会向计费系统30发送对用户设备10进行鉴权的请求消息CCR-I，请求对用户设备10进行鉴权。对用户设备10的鉴权包括鉴权用户设备10是否欠费或停机，也就是说，鉴权用户设备10是否处于可以使用业务的状态。

步骤203、计费系统30对用户设备10进行鉴权；

计费系统30在接收到网关发送的CCR-I后，会查询用户设备10的用户数据，其中包括用户设备10是否欠费或者停机的用户数据。

步骤204、计费系统30向网关20发送信用控制初始应答(credit control answerinitial,CCA-I)；

计费系统30对用户设备10完成鉴权后，会向网关20发送CCA-I消息，用于响应网关20发送的CCR-I请求消息，告知网关20对用户设备10鉴权成功。如果用户设备10没有欠费或者停机等的不良用户数据，则允许用户设备10开始使用业务流量。

步骤205、网关20建立与用户设备10之间的数据业务会话；

网关20在接收到计费系统30的CCA-I消息后，会向用户设备10发送业务请求消息的响应消息，允许用户设备10开始使用业务流量的响应消息，并建立与用户设备10之间的数据业务会话。

步骤206、用户设备10向网关20发送授权业务流量的请求消息；

用户设备10在接收到网关20发送的CCA-I消息后，获知用户设备10可以开始使用业务流量，用户设备10就会向网关20发送请求授权使用业务流量的请求消息。

步骤207、网关20向计费系统30发送信用控制更新请求CCR-U；

步骤网关20在接收到用户设备10发送的请求消息后，会向计费系统发送CCR-U请求消息，请求为用户设备10授权业务流量。

步骤208、计费系统30预留业务流量以及相应费用；

计费系统30在接收到网关20发送的CCR-U请求消息后，会为用户设备10预留请求授权的业务流量。例如，用户设备10向网关20请求授权1M的业务流量，那么计费系统30就会在接收到网关20发送的CCR-U请求消息后，为用户设备10预留1M的业务流量，并为用户设备10预留与1M的业务流量相应的费用。

步骤209、计费系统30向网关20发送信用控制更新应答CCA-U；

计费系统30为用户设备10预留了业务流量之后，会接着向网关20发送CCA-U消息，告知网关20已为用户设备10预留了业务流量，也就是说，告知网关20已授权给用户设备10业务流量。该CCA-U消息中包含了预留的业务流量，

步骤210、网关20响应用户设备10使用授权的业务流量的请求；

网关20接收到计费系统30的CCA-U消息后，会响应用户设备10的授权业务流量的请求，允许用户设备10使用授权的业务流量。

步骤211、网关20监控用户设备10使用授权的业务流量；

网关20允许用户设备10使用授权的业务流量之后，会监控用户设备10使用授权的业务流量的情况。

步骤212、用户通过CRM40向计费系统30发送变更用户设备10的扣费规则的请求消息；

用户设备10在使用完授权的业务流量之后，用户可以向CRM40发送扣费规则变更的请求消息，CRM40在接收到该扣费规则变更的请求消息之后，会将该请求消息转发给计费系统30，也就是请求将扣费规则由第一扣费规则变更为第二扣费规则，例如原来1M的业务流量是1$，变更后为1M是2$。

步骤213、计费系统30向CRM40发送扣费规则变更成功的响应消息；

计费系统30接收到CRM40发送的变更扣费规则的请求消息后，会根据该请求消息变更扣费规则，并向CRM40发送该请求消息的响应消息，告知CRM40已成功变更用户设备10的扣费规则。

步骤214、网关20向计费系统30再次发送CCR-U请求消息；

用户设备10的扣费规则发生变更后，且网关20在监测到用户设备10使用完授权的业务流量后，会向计费系统30再次发送CCR-U请求消息，请求对已使用的授权流量进行扣费，同时为用户设备10的下一个请求消息继续请求授权业务流量。

步骤215、计费系统30累计用户设备10的第一累计已使用业务流量；

计费系统30在接收到网关再次发送的CCR-U消息后，会累计用户设备10第一累计已使用的业务流量，该第一累计已使用的业务流量是尚未被扣费的业务流量。

步骤216、计费系统30判断用户设备10的扣费规则已由第一扣费规则变更为第二扣费规则；

计费系统30在接收到网关20再次发送的CCR-U消息后，同时还会判断用户设备10的扣费规则是否发生了变更。本实施例中，步骤215与步骤216之间没有固定的执行先后顺序，可以先执行步骤215，也可以先执行步骤216或者依据情况同时执行步骤215和步骤216，具体此处不做限定。

此外，如果计费系统30确定用户设备10的扣费规则发生了变更，则执行步骤217。

步骤217、计费系统30根据第一扣费规则对第一累计已使用业务流量进行扣费；

当计费系统30确定用户设备10的扣费规则发生了变更时，则计费系统30会根据变更前的扣费规则(即第一扣费规则)对第一累计已使用的业务流量进行扣费。例如，变更前1M是1$，变更后1M是2$，也就是说，第一扣费规则是1M为1$，第二扣费规则是1M为2$，这时就按照变更前的1M是1$对已使用业务流量进行扣费。

步骤218、计费系统30对第一累计已使用业务流量清零；

计费系统30对第一累计已使用业务流量进行扣费后，可以对第一累计已使用业务流量清零。

步骤219、计费系统30预留再授权业务流量以及相应的费用；

计费系统30对已使用业务流量清零后，会再次预留再授权业务流量，作为用户设备10继续请求授权的业务流量，而且，计费系统30还会根据第二扣费规则，为用户设备10与再搜权业务流量相应的费用。

需要说明的是，计费系统30为用户设备10预留业务流量，可以是以扣费规则发生变更前的扣费规则作为预留标准，例如，扣费规则发生变更前，当计费系统30接收到网关20发送的CCR-U消息时，会为用户设备10预留1M的业务流量；此外，计费系统30为用户设备10预留业务流量，也可以是以扣费规则发生了变更后的扣费规则作为预留标准，例如，扣费规则发生了变更后，当计费系统30接收到网关20发送的CCR-U消息时，会为用户设备10预留2M的业务流量，具体此处不做限定。

步骤220、计费系统30向网关发送CCA-U消息；

计费系统30为用户设备10预留再授权业务流量后，会向网关发送CCA-U消息，告知网关已经为用户设备10再次预留了业务流量，该CCA-U消息包含为用户设备10预留的再授权业务流量。

步骤221、网关20响应用户设备10继续授权业务流量的请求；

网关20在接收到CCA-U消息后，会允许用户设备10使用继续授权的业务流量。

步骤222、网关20再次监控用户设备10使用业务流量；

用户设备10接收到允许使用继续授权的业务流量的响应后，就开始使用再授权的业务流量，此时，网关20会再次监控用户设备10使用再次授权的业务流量的情况。

步骤223、用户设备10向网关20发送结束数据业务的请求消息；

用户设备10在使用完再次授权的业务流量后，向网关20发送结束数据业务的请求消息。

步骤224、网关20向计费系统30发送信用控制终止请求(credit control requestterminate,CCR-T)；

网关20在接收到用户设备10发送的结束数据业务的请求消息后，会向计费系统30发送CCR-T请求消息，请求结束用户设备10继续使用数据业务。

步骤225、计费系统30根据第二扣费规则对第三累计已使用业务流量扣费；

计费系统30在接收到网关20发送的CCR-T请求消息后，会根据变更后的扣费规则(即第二扣费规则)对清零后再次积累的已使用业务流量扣费，本实施例中第二扣费规则就是在步骤217中举例的1M为2$。

步骤226、计费系统30向网关发送信用控制终止应答(credit control answerterminate,CCA-T)；

计费系统30在对清零后的重新积累的已使用业务流量扣费后，会向网关20发送该请求消息的CCA-T消息，告知网关20可以结束用户设备10继续使用业务流量的数据业务会话。

步骤227、网关20向用户设备10发送关闭业务会话的响应消息。

网关20在接收到计费系统30发送的CCA-T消息后，会向用户设备10发送结束数据业务会话的响应消息，并将用户设备10的数据业务会话的连接关闭。

自此，用户设备10使用数据业务会话被网关20关闭。

在本申请实施例中，计费系统接收到网关发送的请求扣除已使用业务流量所产生费用以及继续授权业务流量的CCR-U消息后，计费系统将累计已使用业务流量，并判断用户设备的扣费规则是否发生了变更，如果计费系统确定用户设备的扣费规则发生了变更，则会根据变更前的扣费规则对已使用业务流量进行扣费，并为用户设备预留业务流量，且对已使用业务流量清零，然后向网关发送业务流量授权成功的响应，在随后计费系统又接收到来自网关的请求扣费以及继续授权业务流量的CCR-U消息时，计费系统就可以重新累计已使用的业务流量，并在之后的业务流量计费流程中在需要扣费时，能够按照变更后的扣费规则进行扣费，从而实现对数据业务进行精确的在线计费，确保用户不会出现欠费的情况，并且大幅减小了业务流量的使用，降低了设备成本，提高了数据计费系统的准确性以及数据业务计费的性能，能够满足运营商的诉求。

上面的实施例中，如果计费系统30确定用户设备10的扣费规则发生了变更，则计费系统30会根据变更前的扣费规则对已使用业务流量进行扣费。下面的实施例中，请参阅图3，对扣费规则未发生的情况下计费系统30如何进行计费的步骤流程进行详细说明。

下面以一个具体的应用场景为例对另一个实施例进行描述。在以下的实施例中，网关以GGSN为例，计费系统以CBS为例，用户设备以汽车为例对下述实施例进行说明。

需要说明的是，本实施例中，用户设备共发送了4次CCR-U请求消息对已使用业务流量进行扣费以及请求继续授权业务流量，步骤312至步骤315是用户设备第2次发送请求消息CCR-U，当CBS确定扣费规则没有发生变更的部分在步骤312至步骤315中有详细说明；而步骤306至步骤311是用户设备第1次发送CCR-U消息，这是为后面的扣费规则没有发生变更时的技术方案进行铺垫性的说明；步骤317至步骤327是用户设备第3次发送请求消息CCR-U，当CBS确定扣费规则发生了变更的部分在步骤317至步骤327中有详细说明；步骤328至步骤332是用户设备第4次发送请求消息CCR-U，这是为最后的用户设备使用业务流量结束时的步骤流程做铺垫性的说明。本实施例的步骤301至步骤305描述是用户设备开始使用业务流量时的内容，步骤333至步骤337是用户设备结束使用业务流量时的内容。

此外，网关还可以是GSN，计费系统还可以是OCS，具体此处不做限定。此外，以下实施例中的CCR-I消息、CCA-I消息、CCR-U消息、CCA-U消息、CCR-T消息、CCA-T消息均是3GPP标准以及4G标准里的diameter协议中的消息类型，除此之外，也可以是5G标准里的restful协议中的消息类型，具体此处不做限定，不过需要说明的是，在5G标准里的restful协议中的消息是自定义的参数，目前5G规范还没有确定。

步骤301、用户设备向GGSN发送开始使用数据业务的请求；

用户设备为了使用数据业务，首先可以向GGSN发送开通数据业务的请求。

步骤302、GGSN向CBS发送信用控制初始请求CCR-I请求对用户设备鉴权；

GGSN在接收到用户设备发送的开通数据业务的请求之后，可以向CBS发送CCR-I消息请求对用户设备的状态以及请求开通的数据业务进行鉴权。

步骤303、CBS对用户设备鉴权；

CBS在接收到GGSN发送的CCR-I消息之后，就可以对用户设备进行鉴权，查询用户设备是否欠费或停机，并且查询请求开始使用的数据业务，验证用户设备是否可以使用数据业务。

步骤304、CBS向GGSN发送信用控制初始应答CCA-I响应对用户设备鉴权；

CBS对用户设备鉴权后，就可以向GGSN发送CCA-I消息响应已成功完成用户设备的鉴权。

步骤305、GGSN响应用户设备开始使用数据业务的请求；

GGSN在收到CBS鉴权成功消息后，响应用户设备使用业务的请求，建立与用户设备之间的数据业务会话；

步骤306、用户设备向GGSN发送请求授权业务流量的请求；

GGSN在对用户设备发送开通数据业务的响应消息后，用户设备就可以在使用业务时向GGSN发送授权业务流量的请求。

需要说明的是，本实施例中以具体的业务流量为例进行说明，本步骤306中，以请求授权业务流量1M进行以下说明。

步骤307、GGSN向CBS发送信用控制请求CCR-U请求授权业务流量；

GGSN在接收到用户设备发送的授权业务流量1M的请求后，可以向CBS发送CCR-U请求授权业务流量1M。需要说明的是，授权量根据不同的运营商可以灵活配置。

步骤308、CBS预留业务流量以及相应的费用；

CBS在接收到来自GGSN的CCR-U消息后，就可以为用户设备预留业务流量1M以及与该业务流量相应的费用。例如，1M的费用为1$，则CBS为用户设备预留1$。

步骤309、CBS向GGSN发送信用控制应答CCA-U消息成功授权业务流量；

CBS在为用户设备预留业务流量1M之后，会向GGSN发送CCA-U消息，响应GGSN发送的授权业务流量1M的请求，通知GGSN已成功预留业务流量1M。

步骤310、GGSN响应用户设备允许使用业务流量；

GGSN在接收到CBS的CCA-U消息后，就可以响应用户设备，允许用户设备使用业务流量1M。

步骤311、GGSN监控用户设备使用业务流量；

用户设备在接收到GGSN的允许使用业务的消息后，就可以开始使用授权的业务流量1M。在用户设备使用业务流量1M时，GGSN会监控用户设备使用业务流量1M的情况。

在进行以下步骤的说明之前，需要说明的是，从步骤312至步骤332循环执行。

步骤312、GGSN向CBS发送CCR-U请求扣除已使用业务流量所产生的费用以及再授权业务流量；

在GGSN监控用户设备使用完CBS预留的业务流量1M后，GGSN就会向CBS发送CCR-U消息，请求扣除已使用业务流量所产生的费用以及再授权业务流量1M，再授权业务流量是提供给用户设备继续使用的业务流量。

步骤313、CBS累计第二累计已使用业务流量；

CBS在收到GGSN发送的CCR-U消息后，会累计GGSN在所有消息中上报的用户设备已使用但是未扣费的业务流量，本实施例中为1M。

步骤314、CBS判断用户设备的扣费规则是否由第一扣费规则变更为第二扣费规则；

CBS在完成已使用业务流量1M的累计后，可以判断用户设备的扣费规则有否发生变更。扣费规则发生变更前的是第一扣费规则，发生变更后的是第二扣费规则，该第二扣费规则是用户通过CRM将扣费规则变更请求转发给CBS后，CBS根据扣费规则变更请求进行变更的扣费规则。CBS判断用户设备的扣费规则是否发生了变更，是根据CBS有否收到CRM发送的用户设备扣费规则的变更日志，如果用户设备向CRM发送了扣费规则变更的请求，那么CRM就会向CBS发起用户设备扣费规则变更的请求消息，该请求消息中携带有新的扣费规则订购日志。CBS通过判断从上一个CCR-U消息和当前的CCR-U消息之间，有否收到新的扣费规则订购日志。如果CBS确定从上一个CCR-U消息和当前的CCR-U消息之间没有收到新的扣费规则订购日志，则CBS可以确定扣费规则没有发生变更。

需要说明的是，扣费规则可以是用户设备订购的套餐中的资费标准，或是交费标准，所以扣费规则发生变更可以是用户设备的套餐发生了变更，或是缴交的资费规则发生了变更，对于扣费规则的具体内容，具体在此不做限定。

本实施例中，以第一扣费规则是1M为1$、第二扣费规则是1M为2$为例进行说明。

如果CBS确定用户设备的扣费规则没有发生变更，仍然是第一扣费规则，则执行步骤315。

此外，步骤313与步骤314之间没有固定的执行先后顺序，可以先执行步骤313，也可以先执行步骤314，也可以依据情况同时执行步骤314和步骤313，具体此处不做限定。

步骤315、CBS预留业务流量以及相应的费用；

如果CBS确定用户设备的扣费规则没有发生变更，仍然是第一扣费规则，则根据第二累计已使用业务流量1M以及为下一个CCR-U消息预留的业务流量1M，批价后重新预留与1M相应的资费1$。

由于业务流量的计费消息不再是预留、扣费两个阶段的计费模式，因此CBS不需要在收到每个数据业务消息时都调用扣费的流程，而是改为每个消息都只调用预留业务流量的流程，这样就需要将累计发生的已使用业务流量+当前消息待授权的业务流量，按照第一扣费规则批价后重新进行预留，保证计费的正确性。

步骤316、GGSN监控用户设备使用业务流量；

GGSN在接收到CBS的CCA-U消息后，就开始重新监控用户设备使用业务流量的情况。

步骤317、用户向CRM发送将用户设备的第一扣费规则变更为第二扣费规则的指令；

在CBS为用户设备预留好业务流量和资费后，用户向CRM发送将用户设备的第一扣费规则变更为第二扣费规则的指令，例如企业用户向CRM发送重新为用户设备订购一个新的套餐的指令，套餐的资费由每M的1$变为每M的2$。

本实施例中，扣费规则的变更也可以是资费规则的变更，具体此处不做限定。

步骤318、CRM向CBS请求将用户设备的第一扣费规则变更为第二扣费规则；

CRM在接收到用户发送的变更扣费规则的指令后，就会向CBS发送请求消息，请求将用户设备的第一扣费规则变更为第二扣费规则，例如CRM向CBS发送请求订购新的套餐的请求消息。

本实施例中，请求消息也可以是请求资费规则的变更，具体此处不做限定。

步骤319、CBS向CRM发送成功将用户设备的第一扣费规则变更为第二扣费规则的响应；

CBS在接收到CRM发送的变更扣费规则的请求消息后，会向CRM发送响应消息，用于成功响应CRM的请求消息，将用户设备的第一扣费规则变更为第二扣费规则。

步骤320、GGSN向CBS发送CCR-U请求扣除已使用业务流量所产生的费用以及再授权业务流量；

在CBS变更了用户设备的扣费规则后，GGSN再次向CBS发送CCR-U消息，请求扣除第一累计已使用业务流量所产生的费用以及请求继续授权业务流量。

步骤321、CBS判断用户设备的扣费规则是否由第一扣费规则变更为第二扣费规则；

CBS在接收到GGSN发送的CCR-U消息后，就会再次判断用户设备的扣费规则是否由第一扣费规则变更为第二扣费规则，例如CBS判断用户设备是否订购了新的套餐，判断的具体方法如下：根据CBS有否收到CRM发送的用户设备扣费规则的变更日志，如果用户设备向CRM发送了扣费规则变更的请求，那么CRM就会向CBS发起用户设备扣费规则变更的请求消息，该请求消息中携带有新的扣费规则订购日志；CBS通过判断从上一个CCR-U消息和当前的CCR-U消息之间，有否收到新的扣费规则订购日志。如果CBS确定从上一个CCR-U消息和当前的CCR-U消息之间，收到了新的扣费规则订购日志，则CBS就可以确定扣费规则已由第一扣费规则变更为第二扣费规则，则执行步骤322。

本实施例中，请求消息也可以是请求资费的变更，具体此处不做限定。

步骤322、CBS根据第一扣费规则对第一累计已使用业务流量进行扣费；

如果CBS确定用户设备的扣费规则由第一扣费规则(1M为1$)变更为第二扣费规则(1M为2$)，那么CBS就可以根据第一扣费规则对累计的已使用但未扣费的业务流量1M进行批价扣费，这样就可以确保对于累计消费的业务流量进行正确的扣费。

本实施例中，以用户的存款余额在扣费前是100$为例进行说明，扣费后为100$-1$＝99$。

步骤323、CBS对第一累计已使用业务流量清零；

在CBS根据第一扣费规则对第一累计已使用业务流量1M进行扣费后，CBS对累计的已使用业务流量清零。本实施例中，由于第一累计已使用业务流量等于第二累计已使用业务流量，

步骤324、CBS再次预留再授权业务流量；

CBS对已使用业务流量清零后，会再次根据GGSN的CCR-U消息预留业务流量1M，作为用户设备的再授权业务流量。

需要说明的是，CBS为用户设备预留业务流量，可以是以扣费规则发生变更前的扣费规则作为预留标准，例如，扣费规则发生变更前，当CBS接收到GGSN发送的CCR-U消息时，会为用户设备预留1M的业务流量；此外，CBS为用户设备预留业务流量，也可以是以扣费规则发生了变更后的扣费规则作为预留标准，例如，扣费规则发生了变更后，当CBS接收到GGSN发送的CCR-U消息时，会为用户设备预留2M的业务流量，具体此处不做限定。

步骤325、CBS向GGSN发送CCA-U消息；

CBS向GGSN发送CCA-U消息，响应GGSN根据第一扣除规则成功扣除已使用业务流量所产生费用以及成功为用户设备再授权业务流量；

CBS在为用户设备再次预留再授权业务流量后，就会向GGSN发送CCA-U消息，告知GGSN已根据第一扣除规则成功扣除已使用业务流量1M以及成功为用户设备再授权业务流量1M。此时，用户设备的余额变为99$。

步骤326、GGSN允许用户设备使用再授权业务流量；

GGSN在接收到CBS发送的CCA-U消息后，就可以允许用户设备使用再授权业务流量1M。

步骤327、GGSN再次监控用户设备使用业务流量；

用户设备在重新接收到GGSN的允许使用业务的消息后，就可以再次开始使用授权的业务流量1M。在用户设备使用业务流量1M时，GGSN会再次监控用户设备使用业务流量1M的情况。

步骤328、GGSN再次向CBS发送CCR-U请求扣除已使用业务流量所产生的费用以及再授权业务流量；

在GGSN再次监控用户设备使用完CBS预留的业务流量1M后，GGSN就会向CBS再次发送CCR-U消息，请求扣除已使用业务流量所产生的费用以及再授权业务流量1M。

步骤329、CBS再次累计已使用业务流量；

CBS再次接收到GGSN发送的CCR-U消息后，会再次累计GGSN上报的用户设备已使用但是未扣费的业务流量，本实施例中为1M。

步骤330、CBS再次判断用户设备的扣费规则是否由第二扣费规则变更为第三扣费规则；

CBS在再次完成已使用业务流量1M的累计后，可以再次判断用户设备的扣费规则是否发生了变更。判断扣费规则是否发生了变更，是根据CBS有否收到CRM发送的用户设备扣费规则的变更日志，此点在步骤314中已详细说明，此处不再赘述。如果CBS确定扣费规则没有发生变更，即仍然是第二扣费规则，则执行步骤331。

步骤331、CBS再次预留再授权业务流量；

如果CBS确定用户设备的扣费规则没有发生变更，仍然是第二扣费规则，则根据累计已使用业务流量1M以及为下一个CCR-U消息预留的业务流量1M，批价后重新预留与1M相应的资费2$(第二扣费规则是每M为2$)。

步骤332、GGSN再次监控用户设备使用业务流量；

步骤336与步骤316类似，此处不再赘述。

循环执行从步骤312至步骤332。

步骤333、用户设备向GGSN发送结束数据业务的请求；

用户设备在使用完业务流量以后，在结束使用业务数据前会向GGSN发送请求关闭数据业务的消息。

步骤334、GGSN向CBS发送计费信用控制协议结束消息的请求CCR-T；

GGSN在接收到用户设备发送的结束数据业务的请求后，就会向CBS发送CCR-T消息请求结束数据业务，并请求扣除已使用但未扣费的业务流量1M的费用。

步骤335、CBS根据第二扣费规则扣除已使用业务流量的费用；

CBS在接收到GGSN发送的CCR-T消息后，就会以最终变更后的扣费规则(即第二扣费规则)对用户设备的已使用业务流量进行扣费。

由于用户设备的扣费规则自从步骤330由CBS确定的第二扣费规则之后没有再发生变更，因此本步骤335会根据第二扣费规则进行扣费，即扣费后为99$-2$＝97$。

步骤336、CBS向GGSN发送信用控制终止应答CCA-T。

CBS根据最终扣费规则扣除已使用业务流量的费用之后，就会向GGSN发送CCA-T消息，告知GGSN已结束用户设备使用数据业务的操作流程。

步骤337、GGSN响应用户设备结束数据业务。

GGSN接收到CBS的CCA-T消息后，就会发送响应消息至用户设备，告知用户设备已成功关闭数据业务的使用。

本申请实施例中，CBS接收到GGSN发送的请求扣除已使用业务流量所产生费用以及再授权业务流量的CCR-U消息后，CBS会累计已使用业务流量，然后判断用户设备(例如汽车)的扣费规则是否由第一扣费规则变更为第二扣费规则，如果CBS确定用户设备的扣费规则由第一扣费规则变更为第二扣费规则，则会根据第一扣费规则对已使用业务流量进行扣费，并为用户设备预留请求再授权的业务流量，然后对已使用业务流量清零，接着CBS再次接收到新的CCR-U消息时，可以重新累计已使用的再授权业务流量，并在随后的业务流量计费流程中如果需要扣费，则按照第二扣费规则进行扣费，这样就可以实现在线精确计算用户所使用的业务流量的费用，从而确保用户按照正确的金额缴费，不会出现漏缴或少缴业务流量费用的情况，提升了CBS的计费精确度，并且大幅减小了业务流量的使用，降低了设备成本，提高了数据计费系统的准确性以及数据业务计费的性能，能够满足运营商的诉求。

上面的实施例中，在CBS判断扣费规则是否发生变更时，仅需判断一种扣费规则是否发生了变更，例如，仅需判断用户设备是否从套餐A变更为套餐B。

参见图4，下面的实施例进一步对IOT中的CBS判断两种扣费规则是否发生了变更等步骤进行详细说明，这些步骤是与本申请实施例技术方案相关的关键步骤，其中包括：如果CBS确定用户设备没有从套餐A变更为套餐B，则还需判断用户设备是否从资费规则一变更为资费规则二。

此外，本实施例中仍然将网关设为GGSN，将计费系统设为CBS，不过可以将用户设备设为手机终端。

在对下面的实施例中的步骤流程进行说明前，首先介绍以下的与本实施例相关的信息内容。

(1)与套餐变更相关的日志信息

根据CRM的订购操作，CBS会记录设备(本实施例中的设备即为用户设备，即手机)的套餐订购日志信息，其样例如表1所示，表1中包括的项目如下：

表1

设备ID
	套餐ID
套餐生效时间
	套餐失效时间
套餐订购时间
	…

设备ID：IOT中的设备的标识，用来标示设备，每个设备只有唯一的一个标识。

套餐ID：套餐的唯一标识，用于区分不同的套餐。

套餐生效时间：套餐从哪个时间点开始生效。

套餐失效时间：套餐从哪个时间点开始失效。

套餐订购时间：订购套餐的时间点。

…：其他信息。

在数据业务会话消息计费过程中，CBS会记录数据业务消息处理的会话信息，其样例如表2所示，表2中包括的项目如下：

表2

设备号码
	设备ID
上一个消息开始时间
	当前消息开始时间
当前消息使用量
	会话累计使用量
累计未扣费已使用量
	…

其中：

设备号码：为运营商为每个设备分配一个电话号码。

设备ID：为IOT中的设备的标识，用来标示设备，每个设备只有唯一的一个标识。

上一个消息开始时间：为上一个消息的交互时间。

当前消息开始时间：为当前数据业务消息开始的时间。

当前消息使用量：为GGSN在当前消息中上报的设备已使用业务流量或请求授权的业务流量。

会话累计使用量：为GGSN在所有消息中上报的设备已使用的累计业务流量。

累计未扣费的已使用量：为GGSN在所有消息中上报的设备已使用但是未扣费的累计业务流量。

需要说明的是，数据业务会话消息包括本申请实施例中的CCR-I、CCA-I、CCR-U、CCA-U、CCR-T以及CCA-T消息。

在CRM发起的设备订购变更套餐的流程中记录有设备订购套餐的变更日志，CBS在接收到该变更日志的同时，会在数据业务计费过程中记录数据业务会话消息。根据订购套餐的变更日志的套餐生效时间，以及数据业务会话消息的消息开始时间(包括数据业务的上一个消息开始时间以及当前消息开始时间)，CBS判断数据业务的上一个CCR-U消息开始时间、当前CCR-U消息开始时间是否在变更的套餐的生效时间内。如果两个CCR-U消息开始时间都不在变更的套餐的生效时间内，则说明在数据业务会话中，从上一个CCR-U消息到当前的CCR-U消息的过程中没有发生过设备的套餐变更；如果上一个CCR-U消息的开始时间不在变更的套餐的生效时间内，但当前的CCR-U消息的开始时间在变更的套餐的生效时间内，则说明在数据业务会话中，从上一个CCR-U消息到当前的CCR-U消息的过程中发生过设备的套餐变更。

(2)与资费规则发生变更的相关的日志信息

根据CRM的订购操作，CBS会记录设备(本实施例中的设备即为用户设备，即手机)的套餐订购日志信息，其样例如表3所示，表3中包括的项目如下：

表3

设备ID
	资费规则ID
资费规则的生效时间
	资费规则的失效时间
资费规则的订购时间
	…

其中：

设备ID：为IOT中的设备的标识，用来标示设备，每个设备只有唯一的一个标识，由设备ID可以查找到设备号码。

资费规则ID：为资费标注你的唯一标识，用于区分不同的资费规则。

资费规则的生效时间：为资费规则从哪个时间点开始生效。

资费规则的失效时间：为资费规则从哪个时间点开始失效。

资费规则的订购时间：为订购资费规则的时间点。

在数据业务会话消息计费过程中，CBS会根据资费产品配置系统同步过来的资费规则信息记录数据业务消息处理的会话信息，其样例如表4所示，表4中包括的项目如下：

表4

资费规则ID
	资费规则的类型
资费规则的生效时间
	资费规则的失效时间
费率
	计算单元
…

其中：

资费规则ID：为资费规则的唯一标示，用于区分不同的资费规则。

资费规则的类型：为累计量资费、消费累计资费、使用量资费、简单资费等等。其中，累计量资费是根据时间的累计量计算资费，时间的累计量越多，则单位时间内的资费越便宜，时间的累计量越少，则单位时间内的资费越昂贵；消费累计资费是根据使用的金额累计量计算资费，使用的金额累计量越高，则单位时间内的资费越便宜，使用的金额累计量越少，则单位时间内的资费越昂贵；使用量资费是根据使用的业务流量的累计量计算资费，使用的业务流量的累计量越多，则单位时间内的资费越便宜，使用的业务流量的累计量越少，则单位时间内的资费越昂贵；简单资费是单位时间内的资费是固定值，不会随着其他因素的改变而改变。

资费规则的生效时间：为该资费规则从哪个时间点开始生效。

资费规则的失效时间：为该资费规则从哪个时间点开始失效。

费率：为资费规则的价格。

计算单元：为资费规则计算的跳次，例如，1M为1$，不足1M时也同样按照1M的价格计算；第2M又会增加1$，变为2$；第3M又会增加1$，变为3$，以此类推，计算单元通过跳次按照资费规则计算资费。

在CRM发起的设备订购变更套餐的流程中记录有设备订购套餐的变更日志，CBS在接收到该变更日志的同时，会在资费配置系统同步过来的资费规则信息记录的过程中记录数据业务会话消息。根据订购的资费规则的日志，以及资费规则的配置信息，CBS判断数据业务的上一个消息开始时间、当前消息开始时间是否在变更的套餐的生效时间内。

本实施例中，假设设备号码是13912345678，初始余额是：资金账本100$，同时设备订购套餐的价格是1$/1M，同时GGSN配置的请求的分片流量(即执行循环步骤的业务流量)是1M。

设备的资金账本信息如表5所示。

表5

字段名	记录1
		资金账本ID	3001
资金账本类型	主资金
		设备ID	200001
资金剩余量	100$
		资金预留量	0$
…

设备的订购日志信息如表6所示。

表6

字段名	记录1
		设备ID	200001
套餐ID	4001
		套餐生效时间	20171201 01:00:00
套餐失效时间	201801 00:00:00
		套餐订购时间	20171201 01:00:00
…

资费规则的信息如表7所示。

表7

字段名	记录1
		套餐ID	4001
资费类型	简单资费
		资费规则生效时间	20170101 01:00:00
资费规则失效时间	201901 00:00:00
		费率	1$
计算单元	1M
		…

在进行了上述与本实施例相关的信息内容后，参见图4，下面对本实施例进行详细说明。

步骤401、手机向GGSN请求使用业务流量；

手机(本实施例中的用户设备是手机)设备号码在资费规则生效时间的2017120901：00：00通过已经建立的数据业务会话，请求使用业务流量1M。

步骤402、GGSN向CBS发送CCR-U请求消息；

GGSN通过向CBS发送CCR-U消息，从而将数据业务会话请求消息转发给CBS，请求授权1M业务流量给手机使用。

步骤403、CBS预留业务流量；

参见表8和表9，表8为记录数据业务会话信息，表9为变更资金账本信息。CBS在接收到GGSN发送的授权业务流量的请求后，进行批价计算出需要从100$账本余额中扣除与已使用业务流量1M对应的1$，同时为手机预留1$账本余额。

表8

字段名	记录1
		设备号码	13912345678
设备ID	200001
		上一个消息开始时间	20171209 00:00:00
当前消息开始时间	20171209 01:00:00
		累计未扣费已使用量	0M
会话累计使用量	0M
		…

表9

字段名	记录1
		资金账本ID	3001
资金账本类型	主资金
		设备ID	200001
资金剩余量	100$
		资金预留量	1$
…

步骤404、CBS向GGSN发送CCA-U消息；

CBS根据批价、预留的结果，通过向GGSN发送CCA-U消息，从而将授权的业务流量的结果编码返回给GGSN。

步骤405、GGSN响应手机发送的使用业务流量的请求消息；

GGSN根据授权的业务流量的结果编码，响应手机，允许手机可以使用业务流量。

步骤406、GGSN监控手机的流量使用情况；

步骤407、GGSN向CBS再次发送CCR-U请求消息；

GGSN在20171209 01：15：00监控到手机的数据业务会话的流量使用完毕后，会向CBS再次发送CCR-U请求消息，请求扣费流量是1M，同时请求下一个分片(即执行下一个循环步骤)的授权业务流量。

步骤408、CBS累计已使用业务流量；

CBS在接收到GGSN再次发送的CCR-U请求消息后，会累计本次会话的已使用业务流量，并累计已使用业务流量。参见下表10，表10为记录数据业务会话信息。

表10

字段名	记录
		设备号码	13912345678
设备ID	200001
		上一个消息开始时间	20171209 00:00:00
当前消息的开始时间	20171209 01:15:00
		累计未扣费已使用量	1M
会话累计使用量	1M
		…

步骤409、CBS判断手机的套餐订购日志是否变更；

CBS在接收到GGSN再次发送的CCR-U请求消息后，会判断手机订购的套餐是否发生了变更。例如，原先手机订购的是A套餐，A套餐的服务内容是每使用1M业务流量所需支付的资费是1$，而B套餐的服务内容是每使用1M业务流量所需支付的资费是2$。本实施例中，CBS确定手机的套餐订购日志没有发生变化。

步骤410、CBS判断手机的累计优惠资费规则的信息是否发生变更；

CBS在确定手机的套餐订购日志没有发生变更后，会继续判断手机的累计优惠资费规则的信息是否发生了变化。例如，原先手机订购的资费规则一的服务内容是，如果手机在本月内使用的业务流量是在0M-100M以内，则每使用1M业务流量所需支付的资费为2$，而如果手机在本月内使用的业务流量是在101M-200M以内，则每使用1M业务流量所需支付的资费为1$。而资费规则二的服务内容是，如果手机在本月内使用的业务流量是在0M-100M以内，则每使用1M业务流量所需支付的资费为3$，而如果手机在本月内使用的业务流量在本月内使用的业务流量是在101M-200M以内，则每使用1M业务流量所需支付的资费为2$。若CBS确定手机的累计优惠资费规则的信息没有发生变更，则执行步骤411。

步骤411、CBS预留再授权业务流量；

若CBS确定手机的累计优惠资费规则的信息也没有发生变更，则CBS为手机预留本次请求继续授权的业务流量1M，并且，CBS根据累计未扣费已使用业务流量1M以及本次手机请求授权的业务流量1M，为手机批价预留资金账本2$。参见表11，表11为变更资金账本信息。

表11

字段名	记录
		资金账本ID	3001
资金账本类型	主资金
		设备ID	200001
资金剩余量	100$
		资金预留量	2$
…

步骤412、CBS向GGSN再次发送CCA-U消息；

CBS根据批价、预留的结果，通过再次向GGSN发送CCA-U消息，从而将授权的业务流量的结果编码返回给GGSN。

步骤413、GGSN监控手机的业务流量的使用情况；

步骤414、CRM向CBS发送用户的新的订购请求；

用户给手机在20171209 01：20：00订购一个新的资费规则(资费规则ID＝5001)，该新的消费累计优惠标准是，如果手机的消费累计达到1$以上，则费率变成2$/1M。CRM将用户的新的订购请求转发给CBS处理，该新的订购请求即是订购新的资费规则的请求。

步骤415、CBS向CRM发送新的订购请求的响应；

CBS向CRM发送响应，告知CRM已成功为手机订购新的资费规则，新的资费规则为2$/1M。

参见表12和表13，表12是设备的订购日志信息，表13是资费规则的信息。

表12

字段名	记录
		设备ID	200001
资费规则ID	5001
		资费规则生效时间	20171209 01:20:00
资费规则失效时间	201801 00:00:00
		资费规则订购时间	20171209 01:20:00
…

表13

字段名	记录
		套餐ID	5001
资费类型	消费累计资费
		资费生效时间	20171209 01:20:00
资费失效时间	201901 00:00:00
		费率	2$
计算单元	1M
		…

步骤416、GGSN向CBS再次发送CCR-U请求消息；

GGSN在20171209 01：25：00监控到手机的数据业务会话的流量使用完毕，会向CBS发送CCR-U请求消息，请求扣费，并请求扣费业务流量是1M，同时请求下一个分片(循环步骤)的授权业务流量。

步骤417、CBS再次累计已使用业务流量；

CBS累计本次会话已使用业务流量和累计已使用未扣费业务流量。参见表14，表14是记录数据业务会话信息。

表14

字段名	记录
		设备号码	13912345678
设备ID	200001
		上一个消息开始时间	20171209 01:15:00
当前消息的开始时间	20171209 01:25:00
		累计未扣费已使用量	2M
会话累计使用量	2M
		…

步骤418、CBS判断手机的套餐是否发生了变更；

由于手机的套餐订购日志发生了变化，与此同时CBS会在上一个消息开始时间(步骤407的CCR-U消息)和当前消息的开始时间(步骤417的CCR-U消息)之间，CBS会判断并确定手机存在套餐的变化。

步骤419、CBS根据套餐变更前的价格扣费；

CBS在确定手机套餐发生了变更，会根据套餐变化前的价格1M/1$对累计未扣费业务流量2M批价扣费2$，扣费后累计扣费业务流量清零。参见表15和表1，表15是变更资金账本信息，表16是记录数据业务会话信息。

表15

字段名	记录
		资金账本ID	3001
资金账本类型	主资金
		设备ID	200001
资金剩余量	98$
		资金预留量	0$
…

表16

字段名	记录
		设备号码	13912345678
设备ID	200001
		上一个消息开始时间	20171209 01:15:00
当前消息的开始时间	20171209 01:25:00
		累计未扣费已使用量	0M
会话累计使用量	2M
		…

步骤420、CBS再次预留业务流量；

CBS对已使用业务流量扣费后，会根据清零后的累计未扣费已使用业务流量0M+本次请求业务流量1M，批价预留1M，并预留资费规则变更后的金额，由于预留的是1M，因此与此相应的的资金账本是2$。参见表17，表17是变更资金账本信息。

表17

字段名	记录1
		资金账本ID	3001
资金账本类型	主资金
		设备ID	200001
资金剩余量	98$
		资金预留量	2$
…

步骤421、CBS向GGSN发送CCA-U消息；

CBS根据批价和预留结果，通过CCA-U消息将授权业务流量的结果编码返回给GGSN。

步骤422、GGSN向手机发送授权业务流量的响应消息；

GGSN在接收到CBS发送的CCA-U消息后，会向手机发送授权业务流量的响应消息，允许手机使用该授权业务流量。

步骤423、GGSN再次监控手机的业务流量使用情况。

循环执行步骤401至步骤423。

在本申请实施例中，当CBS接收到手机请求授权业务流量以及请求扣费的请求消息时，CBS需要先判断订购套餐是否变更以及判断资费规则是否变更，只有在CBS确定订购套餐变更和/或资费规则发生了变更后，CBS才对累计但未扣费的已使用业务流量按照扣费规则变更前的价格执行扣费，这样就可以实现精确计费，并可以减少大部分的扣费步骤流程，实现对数据业务进行精确的在线计费，确保用户不会出现欠费的情况，并且大幅减小了业务流量的使用，降低了设备成本，从而提高了CBS的准确性以及数据业务计费的性能，能够满足运营商的诉求。

上面对本申请实施例中的计费方法进行了描述，下面对本申请实施例中具体的计费业务流程进行描述，参见图5，图5是本申请实施例的业务流程图。

为解决目前已存在的技术方案中的技术问题，本申请实施例的技术方案的总体思路是：

1)在数据业务计费流程中增加套餐变更判断模块和资费场景判断模块，用于判断在数据业务会话持续过程中是否存在套餐变更或者累计消费优惠的场景。

2)如果数据业务会话中的当前消息计费不满足套餐变更的条件，则不再调用扣费子流程，而是根据累计的使用业务流量+下一个消息的授权量来重新计算预留量和反算授权量。

3)如果在数据业务会话中的当前消息计费满足套餐变更或者消费累计优惠资费的条件，则先调用扣费子流程，根据下一个消息的授权量重新计算与流量和反算授权量。

4)由于大部分用户设备在绝大多数场景下不会满足套餐变更条件，所以本申请实施例中的计费系统能够更准确对业务流量计费，大幅提升数据业务计费性能。

本申请实施例在原有的第三代合作伙伴计划(3rd generation partnershipproject,3GPP)标准的技术方案的预留、扣费两个阶段的计费模式的基础上，增加了累计单元、套餐变更判断单元、以及消费累计优惠资费变更单元。下面通过图5的业务流程图对本实施例进行描述。

步骤501、解码：计费系统先对来自网关的请求信息进行解码；

步骤502、要素求解：计费系统从解码后的信息中求解本次数据业务请求消息的计费要素；

步骤503、鉴权：计费系统对抽取出来的用户设备的要素信息进行鉴权，例如对用户设备是否停机或停止缴费进行鉴权，判断是否可以对用户设备授权业务流量；

步骤504、累计已使用量：在计费系统对用户设备鉴权成功并接收到用户设备请求授权业务流量以及扣除已使用业务流量的请求消息后，会累计用户设备已使用的业务流量；

步骤505、套餐变更判断：计费系统在扣费子流程前需要先通过套餐变更判断模块来判断当前的用户设备是否存在套餐变更；如果存在，则再通过步骤505进行下一步的判断操作；如果不存在，则执行步骤507。

步骤506、资费规则变更判断：如果计费系统中的套餐变更判断(本实施例中也可称为资费场景判断)确定当前的用户设备不存在资费变更，则执行步骤508，否则执行步骤507；

步骤507、扣费：扣费由可选的扣费子流程执行。如果计费系统确定用户设备的套餐发生了变更或资费规则发生了变更，则由扣费子流程根据变更前的扣费金额对已使用业务流量进行扣费。如果计费系统能够确定用户设备的套餐和资费规则都没有发生变更，则扣费子流程可以不执行扣费操作，而只是由累计单元累计已使用业务流量；

步骤508、预留：预留业务流量由增强了的预留子流程执行。如果套餐或资费规则发生了变更，计费系统就会通过扣费子流程对已使用业务流量扣费后，为用户设备的下一个请求授权业务流量的请求消息预留授权的业务流量，并预留与授权的业务流量相应的消费金额。如果套餐和资费规则没有发生变更，计费系统就会累计已使用业务流量并为用户设备的下一个请求授权业务流量的请求消息预留授权的业务流量。

步骤509、编码：计费系统在为用户设备预留了业务流量后，会将预留了业务流量的信息进行编码后发送给网关。

本申请实施例中，由于增加了套餐变更判断步骤和资费场景判断步骤，并且将扣费子流程设置为可选的子流程，还增强了预留子流程的性能设计，并且只有在套餐或资费规则发生了变更时才会执行扣费流程，并且会按照变更前的扣费规则进行扣费，因此计费更加精确，从而大幅提升了数据业务计费性能。

上面对本申请实施例中的具体的计费业务流程进行了描述，下面对本申请实施例中的计费系统进行描述，请参阅图6，本申请实施例中计费系统的一个实施例包括：

接收单元601，用于接收网关发送的第一信用控制更新请求CCR-U；

确定单元602，用于确定用户设备的扣费规则已由第一扣费规则变更为第二扣费规则，用户设备为向网关发送请求再授权业务流量的设备；

累计单元603，用于累计第一累计已使用业务流量，第一累计已使用业务流量是累计在第一扣费规则变更为第二扣费规则之前已使用的业务流量；

扣费单元604，用于根据第一扣费规则对用户设备的第一累计已使用业务流量进行扣费，得到用户设备的剩余费用；

第一预留单元605，用于为用户设备预留再授权业务流量；

第二预留单元606，用于根据第二扣费规则，为用户设备预留与授权业务流量相应的费用；

发送单元607，用于向网关发送信用控制更新应答CCA-U，以使得网关允许用户设备使用再所述授权业务流量，CCA-U包含再授权业务流量。

本实施例中，再授权业务流量可以包括用户设备的扣费规则为第一扣费规则时的再授权业务流量，也可以包括用户设备的扣费规则为第二扣费规则时的再授权业务流量。

本实施例中，扣费单元604具体用于根据用户设备的扣费规则的变更日志，确定所述用户设备的扣费规则已由第一扣费规则变更为第二扣费规则。

本实施例中，计费系统还包括：

存储单元608，用于根据客户关系管理系统CRM发送的扣费规则变更请求消息存储所述变更日志。

本实施例中，第二预留单元具体用于根据剩余费用以及第二扣费规则，为用户设备预留与再授权业务流量相应的费用。

本实施例中，计费系统还包括：

清零单元609，用于对第一累计已使用业务流量清零。

本实施例中，接收单元601还用于接收所述网关发送的第二CCR-U；所述确定单元602还用于确定所述用户设备的所述扣费规则未从所述第一扣费规则变更为所述第二扣费规则；所述累计单元603还用于为所述用户设备累计第二累计已使用业务流量；所述第一预留单元605还用于为所述用户设备预留所述再授权业务流量；所述第二预留单元606还用于根据所述第一扣费规则，为所述用户设备预留与所述再授权业务流量相应的费用。

本实施例中，扣费规则可以为套餐的收费标准，也可以为资费规则。因此，如果扣费规则发生变更，可能是由套餐一变为套餐二，也可能是由资费规则一变为资费规则二。

本实施例中，计费系统中各单元所执行的流程与前述图2至图5所示的实施例中描述方法流程类似，此处不再赘述。

本实施例中，当接收单元601接收到网关发送的扣除已使用业务流量所产生费用以及再授权业务流量的请求消息时，累计单元603会累计已使用业务流量，当确定单元602确定用户设备的扣费规则由第一扣费规则变更为第二扣费规则时，扣费单元604会根据第一扣费规则对已使用业务流量进行扣费，得到用户设备的剩余费用，接着第一预留单元605会为用户设备预留再授权业务流量，第二预留单元606会为用户设备预留与授权业务流量相应的费用，从而使得网关能够允许用户设备使用再授权业务流量。由于只有当确定单元602确定用户设备的扣费规则发生了改变，扣费单元604才执行扣费操作，并且是按扣费规则变更前的价格扣费，因此保证了计费的准确性，提高了计费系统的业务处理性能。

上面是计费系统的实施例，下面对本申请实施例中计费系统的另一个实施例进行描述。参阅图7，本申请实施例中的计费系统包括：

接收单元701，用于接收GGSN发送的CCR-U请求消息，该CCR-U请求消息包括GGSN发送的扣除已使用业务流量所产生费用的请求以及继续授权业务流量的请求；

累计单元702，用于累计用户设备的已使用业务流量；

套餐变更判断单元703，用于判断用户设备的套餐是否发生了变更；当套餐变更判断单元确定用户设备的套餐没有发生变更，则由消费累计优惠资费变更判断单元接着对用户设备接着进行资费规则是否发生了变更的判断；

消费累计优惠资费变更判断单元704，用于判断用户设备的资费规则是否发生了变更；如果消费累计优惠资费变更判断单元确定用户设备的资费规则发生了变更，则由扣除单元扣除已使用业务流量相应的费用；

扣费单元705，用于按照变更前的资费规则扣除与已使用但未扣费的业务流量相应的费用；

清零单元706，用于在扣除已使用业务流量的相应费用后，对已使用业务流量进行清零；

预留单元707，用于为用户设备预留再授权的业务流量以及相应的金额；

发送单元708，用于向GGSN发送CCA-U消息，告知GGSN允许用户设备使用再授权的业务流量。

本实施例中，计费系统中各单元所执行的流程与前述图2至图5所示的实施例中描述方法流程类似，此处不再赘述。

上面是本申请实施例中计费系统的实施例，下面请参阅图8，本申请实施例中计费系统的另一个实施例包括：

该计费系统800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央器(central processing units，CPU)801(例如，一个或一个以上处理器)和存储器805，该存储器805中存储有一个或一个以上的应用程序或数据。

其中，存储器805可以是易失性存储或持久存储。存储在存储器805的程序可以包括一个或一个以上模块，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器801可以设置为与存储器805通信，在计费系统800上执行存储器805中的一系列指令操作。

计费系统800还可以包括一个或一个以上电源802，一个或一个以上有线或无线网络接口803，一个或一个以上输入输出接口804，和/或，一个或一个以上操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

本实施例中计费系统800中的中央处理器801所执行的流程与前述图2至图5所示的实施例中描述的方法流程类似，此处不再赘述。

本申请实施例还提供一种计算机存储介质，该计算机存储介质用于储存为前述计费系统800所用的计算机软件指令，其包括用于执行为计费系统800所设计的程序。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机软件指令，该计算机软件指令可通过处理器进行加载来实现前述图2至图5所示的实施例中的方法流程。

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

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

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

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

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

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种计费方法，其特征在于，包括：

接收网关发送的第一信用控制更新请求CCR-U，所述CCR-U用于为用户设备申请再授权业务流量；

确定所述用户设备的扣费规则已由第一扣费规则变更为第二扣费规则；

根据所述第一扣费规则对所述用户设备的第一累计已使用业务流量进行扣费，所述第一累计已使用业务流量是累计在所述第一扣费规则变更为所述第二扣费规则之前的已使用业务流量；

根据所述第二扣费规则，为所述用户设备预留与所述再授权业务流量相应的费用；

向所述网关发送信用控制更新应答CCA-U，以使得所述网关允许所述用户设备使用所述再授权业务流量，所述CCA-U包含所述再授权业务流量。

2.根据权利要求1所述的方法，其特征在于，所述确定所述用户设备的扣费规则已由所述第一扣费规则变更为所述第二扣费规则包括：

根据所述用户设备的所述扣费规则的变更日志，确定所述用户设备的所述扣费规则已由所述第一扣费规则变更为所述第二扣费规则。

3.根据权利要求2所述的方法，其特征在于，在所述确定所述用户设备的扣费规则已由所述第一扣费规则变更为所述第二扣费规则之前，所述方法还包括：

根据客户关系管理系统CRM发送的扣费规则变更请求消息存储所述变更日志。

4.根据权利要求3所述的方法，其特征在于，根据所述第二扣费规则，为所述用户设备预留与所述再授权业务流量相应的费用包括：

获取所述用户设备的剩余费用；

根据所述剩余费用以及所述第二扣费规则，为所述用户设备预留与所述再授权业务流量相应的费用。

5.根据权利要求1所述的方法，其特征在于，在根据所述第一扣费规则对所述用户设备的第一累计已使用业务流量进行扣费之后，所述方法还包括：

对所述第一累计已使用业务流量清零。

6.根据权利要求1所述的方法，其特征在于，在接收网关发送的所述第一信用控制更新请求CCR-U消息之前，所述方法还包括：

接收所述网关发送的第二CCR-U；

确定所述用户设备的所述扣费规则未从所述第一扣费规则变更为所述第二扣费规则；

为所述用户设备累计第二累计已使用业务流量，所述第一累计已使用业务流量包含所述第二累计已使用业务流量；

为所述用户设备预留所述再授权业务流量；

根据所述第一扣费规则，为所述用户设备预留与所述再授权业务流量相应的费用。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述扣费规则为套餐的收费标准或者资费规则。

8.一种计费系统，其特征在于，包括处理器和存储器，其中：

所述存储器，用于存储程序指令；

所述处理器，用于调用并执行所述存储器中存储的程序指令，以使所述计费系统执行如权利要求1至7中任一项所述的计费的方法。

9.一种包含指令的计算机程序产品，其特征在于，当其在计算机上运行时，使得所述计算机执行如权利要求1至7中任一项所述的计费的方法。

10.一种计算机可读存储介质，其特征在于，包括指令，当所述指令在计算机上运行时，使得计算机执行如权利要求1至7中任一项所述的计费的方法。