CN100362794C - 一种基于业务数据流在线计费的信用控制方法 - Google Patents

Abstract

本发明公开了一种基于业务数据流在线计费的信用控制方法，在线计费实现过程中，在线计费系统OCS收到来自传输面功能实体TPF的信用请求之后，OCS根据收到的输入信息，选择适当的信用池，然后确定信用信息，进而向TPF提供该信用信息。通过向OCS提供用户使用分组数据业务的输入信息，使得OCS能够获知正确的信用池，从而对相应信用池中的用户信用进行控制，使得对用户信用的控制和管理更为合理，避免了用户信用信息的错误使用，使得基于FBC机制的在线计费实现过程更为完整、合理。另外，本发明公开了多种向OCS提供输入信息的方式，使得OCS可通过多种途经获取确定信用池的输入信息。

Description

一种基于业务数据流在线计费的信用控制方法

技术领域

本发明涉及计费领域，特别是指一种基于业务数据流在线计费的信用控制方法。

背景技术

随着分组数据业务应用的逐渐广泛，如何准确合理地对分组数据业务进行计费，已成为运营商普遍关注的问题。

图1为分组数据协议上下文(PDP Context，Packet Data Protocol Context)激活、传输数据、去激活流程图，如图1所示，在通用分组无线业务(GPRS，General Packet Radio Service)中，PDP Context激活、传输数据、去激活的实现过程包括以下步骤：

步骤101：用户设备(UE)向服务通用分组无线业务支持节点(SGSN，Serving GPRS Support Node)发送PDP Context激活请求(Activate PDPContext Request)，该Activate PDP Context Request中携带有网络层业务访问标识(NSAPI，Network Layer Service Access Point Identifier)、PDP类型、接入点名称(APN，Access Point Name)、要求的服务质量(QoS)参数、事务标识(TI，Transaction Identifier)等信息，其中，NSAPI在SGSN和网关通用分组无线业务支持节点(GGSN，Gateway GPRS Support Node)之间作为隧道标识(TEID，Tunnel Identifier)的组成部分，用于标识PDP Context；PDP类型包括端对端协议(PPP，Peer-Peer Protocol)类型、网际协议(IP，Internet Protocol)类型等；APN可由UE向SGSN提供，SGSN根据APN寻址到相应GGSN，GGSN根据APN确定UE所要访问的外部网络，UE也可不向SGSN提供APN，此时，由SGSN根据UE用户的签约信息选择缺省的APN；QoS参数为UE指定的分组数据业务所要达到的质量要求；TI用于UE标识一个PDP context。

步骤102：SGSN收到Activate PDP Context Request后，与UE进行安全性检查和加密，该步骤为可选步骤。

步骤103：SGSN根据APN解析GGSN地址信息，如果SGSN能够根据APN解析出GGSN的地址信息，则为PDP Context创建TEID，该TEID可为国际移动用户标识(IMSI，International Mobile Subscriber Identity)与NSAPI的组合，用于在SGSN和GGSN之间唯一标识一个PDP Context，然后SGSN向GGSN发送PDP Context创建请求(Create PDP Context Request)，该Create PDP Context Request中携带有PDP类型、PDP地址、APN、QoS参数、TEID、选择模式等，其中，PDP地址为UE的IP地址，为可选参数，Create PDP Context Request可不携带PDP地址，此时，在后续的处理过程中，可由GGSN为UE分配IP地址，也可由最终与UE建立连接的分组数据网络(PDN，Packet Data Network)为UE分配IP地址；选择模式是指APN的选择模式，即APN是由UE选定的还是由SGSN选定的。如果SGSN无法根据APN解析出GGSN的地址信息，则SGSN拒绝UE发起的PDPContext激活请求。

步骤104：GGSN收到Create PDP Context Request后，根据APN确定外部PDN，然后分配计费标识(Charging ID)、启动计费，并且协商QoS，如果GGSN能够满足QoS参数的服务质量要求，则向SGSN返回PDP Context创建响应(Create PDP Context Response)，该Create PDP Context Response中携带有TEID、PDP地址、链路承载(Backbone Bearer)协议、QoS参数、Charging ID等信息。如果GGSN无法满足QoS参数的服务质量要求，则GGSN拒绝SGSN发起的PDP Context创建请求，然后SGSN拒绝UE发起的PDP Context激活请求。

步骤105：SGSN收到Create PDP Context Response后，在PDP Context中插入NSAPI和GGSN地址信息，用于标识该PDP Context，并根据QoS参数选择无线优先权，然后向UE返回PDP Context激活响应(Activate PDPContext Accept)，该Activate PDP Context Accept中携带有PDP类型、PDP地址、TI、QoS参数、无线优先权、PDP配置选项等信息。并且，SGSN启动计费。UE收到Activate PDP Context Accept，建立与GGSN之间的路由，此时，UE与PDN之间已经建立了传输通道，可以进行分组数据传输了。

步骤106：UE通过SGSN、GGSN与PDN进行数据传输。

步骤107：数据传输完毕，UE向SGSN发送PDP Context去激活请求(Deactivate PDP Context Request)，该Deactivate PDP Context Request中携带有TI。

步骤108：SGSN收到Deactivate PDP Context Request后，与UE进行安全性检查和加密，该步骤为可选步骤。

步骤109～步骤111：SGSN向GGSN发送PDP Context删除请求(DeletePDP Context Request)，该Delete PDP Context Request中携带有TEID。GGSN收到Delete PDP Context Request后，结束对UE的计费，删除对应于TEID的PDP Context，然后向SGSN发送PDP Context删除响应(Delete PDPContext Response)，该Delete PDP Context Response中携带有TEID。SGSN收到Delete PDP Context Response后，结束对UE的计费，删除对应于TEID的PDP Context，然后向UE发送PDP Context去激活响应(Deactivate PDPContext Response)，该Deactivate PDP Context Response中携带有TI。UE收到Deactivate PDP Context Response后，删除对应于TI的PDP Context。

由图1描述的实现过程可见，当前的GPRS计费系统中，由于计费的起始点设置在PDP Context激活时，计费的终止点设置在PDP Context删除时，因此只能根据PDP Context传输的数据流量进行计费，或是根据PDP Context处于激活状态的时间长度进行计费。然而，在实际应用中，UE与PDN建立起传输通道后，该UE可以基于一个激活的PDP Context进行多种业务，即如果PDN能够提供多种业务，如电子邮件(Email)收发业务、基于无线应用协议的(WAP，Wireless Application Protocol)的浏览业务、基于文件传输协议(FTP，File Transfer Protocol)的文件传输等业务，则UE在与该PDN建立传输通道后，可通过一个激活的PDP Context承载该PDN能够提供的各种业务，但是，运营商对于各种业务的计费模式很可能采用不同的计费方式，如对于Email收发业务可基于Email接收和发送事件的触发按次计费，对于WAP浏览业务可根据流量计费，对于文件传输业务也可根据流量计费，WAP浏览业务的费率与文件传输业务的费率却不尽相同。这样，根据现有的GPRS计费系统，根本无法对同一PDP Context承载的不同业务进行区分计费。

针对上述情况，第三代合作伙伴计划(3GPP，The 3rd GenerationPartnership Project)目前正在讨论如何实现基于IP数据流的计费(FBC，FlowBased Charging)。对于一个分组数据业务而言，UE的用户使用该业务时，传输和接收到的所有IP数据流(IP Flow)，也可为IP分组包(IP packet)，总称为业务数据流(Service Data Flow)，即业务数据流是多个IP数据流组成的集合，因此基于IP数据流的计费能够真实反映某个业务数据流对资源的占用情况。基于IP数据流的计费可被认为是通过一些类似筛子的过滤器将同一PDP Context中承载的不同业务的IP数据流分别筛选出来，然后针对不同过滤器过滤出的IP数据流进行分别计费，以达到对不同的业务数据流分别计费的目的。这样，基于IP数据流的计费粒度要远远小于基于一个PDPContext的计费粒度，粒度可看作是筛子孔的大小，基于一个PDP Context的计费粒度是一个PDP Context就是一个筛子孔，而基于IP数据流的计费粒度则是一个IP业务数据流则为一个筛子孔，即针对一个PDP Context中包含多个筛子孔，因此，基于IP数据流的计费与比基于一个PDP Context的计费相比，基于IP数据流的计费能够为运营商或业务提供者提供更为丰富的计费手段。

3GPP中对FBC的系统结构、功能要求以及消息交互流程等方面均进行了描述，支持在线计费的FBC系统结构如图2A所示，基于移动网络增强逻辑的客户化应用(CAMEL，Customised Application for Mobile NetworkEnhanced Logic)的业务控制点(SCP，Service Control Point)201和基于业务数据流计费的信用控制功能实体(CCF，Service Data Flow Based CreditControl Function)202组成了在线计费系统(OCS，Online Charging System)206。CCF 202通过Ry接口与基于业务数据流计费的计费规则功能实体(CRF，Service Data Flow Based Charging Rule Function)203互通，CRF 203通过Rx接口与应用功能实体(AF，Application Function)204互通，CRF 203通过Gx接口与传输面功能实体(TPF，Traffic Plane Function)205互通，CCF 202通过Gy接口与TPF 205互通。

支持离线计费的FBC系统结构如图2B所示，CRF 203通过Rx接口与AF 204互通，CRF 203通过Gx接口与TPF 205互通，TPF 205通过Gz接口分别与计费网关功能实体(CGF，Charging Gateway Function)207和计费采集功能实体(CCF，Charging Collection Function)208互通。

TPF 205承载IP数据流，当IP数据流的承载建立时，TPF 205通过Gx接口向CRF 203发送计费规则请求，该计费规则请求中携带有与用户和UE相关的信息、承载特性以及与网络相关的信息等，其中与用户和UE相关的信息可为移动台国际号码(MSISDN)、国际移动用户标识(IMSI)等，与网络相关的信息可为移动网络编码(MNC)、移动国家码(MCC)等。另外，由于在IP数据流传输过程中，会对承载进行修改，如对QoS参数进行重新协商，当用户使用同一业务的QoS参数不同时，计费规则可能不同，如QoS参数下降相应的费率也下降。此时，TPF 205可在承载修改时，重新向CRF 203发送计费规则请求，请求新的计费规则；CRF 203根据TPF 205提供的上述输入信息选择适当的计费规则，并向TPF 205返回选定的计费规则，计费规则中包括计费机制、计费类型、计费键、业务数据流过滤器、计费规则优先级等信息。其中，计费机制可为采用在线计费还是离线计费；计费类型可为基于时间长度进行计费还是基于数据流量进行计费；计费键是与计费费率相关的参数，CRF 203可不直接向TPF 205提供计费费率，而只是向TPF 205提供与计费费率相关的参数；业务数据过滤器用于指示TPF 205对哪些IP数据流进行过滤，然后TPF 205根据计费规则对过滤出的IP数据流进行计费。业务数据过滤器可包含IP5元组，IP5元组可包括源/目的IP地址、源/目的端口号(Port Number)、协议标识(Protocol ID)等信息，例如，CRF 203指示TPF 205对源地址为10.0.0.1、目的地址为10.0.0.2、源/目的端口号为20、协议类型为传输控制协议(TCP)的IP数据流进行过滤，并根据计费规则对过滤出的IP数据流进行计费。

另外，CRF 203除了根据TPF 205提供的输入信息选择适当的计费规则之外，CRF 203还可根据AF 204或OCS 206的输入信息选择适当的计费规则，如AF 204通知CRF 203用户当前使用的业务类型，CRF 203根据该业务类型选择相应的计费规则。

OCS 206由SCP 201和CCF(Service Data Flow Based Credit ControlFunction)202两个功能实体组成，其中，CCF(Service Data Flow Based CreditControl Function)202是执行信用控制的功能实体，仅应用于在线计费系统，可通过在现有的OCS 206中增加新的功能来实现，在在线计费过程中，CCF(Service Data Flow Based Credit Control Function)202对用户信用进行管理和控制，CCF(Service Data Flow Based Credit Control Function)202可通过Ry接口向CRF 203提供用于选择计费规则的相关信息。用户可对不同的分组数据业务设置多个不同的信用池，当用户使用某个分组数据业务时，CCF(Service Data Flow Based Credit Control Function)202对与该分组数据业务相对应的信用池中的信用进行鉴权，并向TPF 205提供用户能够使用的信用。用户也可对多个不同的分组数据业务设置一个共享的信用池，当用户使用这些分组数据业务时，CCF(Service Data Flow Based Credit ControlFunction)202对与这些分组数据业务相对应的信用池中的信用进行鉴权，并向TPF 205提供用户能够使用的信用。

对应于GPRS网络，TPF 205为GGSN，AF为PDN中的一个业务网关或业务服务器，CRF 203为新增的逻辑实体。TPF 205为计费规则的执行点，CRF 203为计费规则的控制点。

图3A为承载建立时在线计费流程图，如图3A所示，承载建立时在线计费的实现过程包括以下步骤：

步骤301A：UE向TPF发送承载建立请求(Establish Bearer ServiceRequest)，在GPRS网络中，则是GGSN收到Create PDP Context Request。

步骤302A：TPF收到承载建立请求后，向CRF发送计费规则请求(Request Charging Rules)，该计费规则请求中携带有供CRF确定计费规则的输入信息。

步骤303A～步骤304A：CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，然后向TPF返回提供计费规则(Provision Charging Rules)，该提供计费规则中可携带有选定的计费规则和计费规则操作指示。

步骤305A：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作。

步骤306A～步骤307A：TPF向OCS发送信用请求(Credit Request)，向OCS请求用户的信用信息。OCS收到信用请求后，确定用户的信用信息，然后向TPF返回信用响应(Credit Response)，如果OCS确定出用户的信用信息，则该信用响应中携带有用户的信用信息，如果OCS未确定出用户的信用信息，则该信用响应中可携带有差错原因值。

步骤308A：TPF收到信用响应后，向UE返回承载建立响应(EstablishBearer Service Accept)，如果信用响应中携带有用户的信用信息，则TPF接受UE发起的承载建立请求，并继续后续的承载建立流程；如果信用响应中未携带有用户的信用信息，则拒绝UE发起的承载建立请求。

图3B为承载修改时在线计费流程图，如图3B所示，承载修改时在线计费的实现过程包括以下步骤：

步骤301B：UE向TPF发送承载修改请求(Modify Bearer ServiceRequest)，在GPRS网络中，则是GGSN收到PDP Context更新请求(UpdatePDP Context Request)。

步骤302B：TPF收到承载修改请求后，向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。

步骤303B～步骤304B：CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则和计费规则操作指示。

步骤305B：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作。

步骤306B～步骤307B：TPF向OCS发送信用请求，向OCS请求用户的信用信息。OCS收到信用请求后，确定用户的信用信息，然后向TPF返回信用响应，如果OCS确定出用户的信用信息，则该信用响应中携带有用户的信用信息，如果OCS未确定出用户的信用信息，则该信用响应中可携带有差错原因值。

步骤308B：TPF收到信用响应后，向UE返回承载修改响应(ModifyBearer Service Accept)，如果信用响应中携带有用户的信用信息，则TPF接受UE发起的承载修改请求，并继续后续的承载修改流程；如果信用响应中未携带有用户的信用信息，则拒绝UE发起的承载修改请求。

图3C为承载删除时在线计费流程图，如图3C所示，承载删除时在线计费的实现过程包括以下步骤：

步骤301C：UE向TPF发送承载删除请求(Remove Bearer ServiceRequest)，在GPRS网络中，则是GGSN收到Delete PDP Context Request。

步骤302C：TPF收到承载删除请求后，向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。

步骤303C～步骤304C：CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则和计费规则操作指示。

步骤305C：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作。

步骤306C～步骤307C：TPF向OCS发送信用报告(Final Remaining CreditReport)，通知OCS为用户建立的承载已经终止，该信用报告中携带有用户信用的使用情况，如用户使用分组数据业务的时间长度、使用分组数据的流量大小。OCS收到信用报告后，向TPF返回信用报告响应(Response)。

步骤308C：TPF收到信用报告响应后，向UE返回承载删除响应(RemoveBearer Service Accept)，接受UE发起的承载删除请求，并继续后续的承载删除流程。

图4为CRF主动向TPF下发计费规则流程图，如图4所示，CRF主动向TPF下发计费规则的实现过程包括以下步骤：

步骤401：CRF收到某个内部或外部的触发事件(Internal or ExternalTrigger Event)，以及与该事件相关的信息，如AF向CRF发送计费规则选择输入信息的事件。

步骤402：CRF根据获取的输入信息选择适当的计费规则。这些输入信息可为AF提供的计费相关输入信息，例如，用户使用AF提供的某一业务，该业务对计费有特殊要求，如计费费率与其他业务的计费费率不同，因此，AF向CRF提供与该业务相关的计费输入信息；也可为TPF提供的计费相关输入信息。

步骤403：如果计费规则发生变化，CRF向TPF发送提供计费规则，该提供计费规则中可携带有选定的计费规则和计费规则操作指示。

步骤404：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作。

步骤405～步骤406：TPF向OCS发送信用请求，向OCS请求用户的信用信息。OCS收到信用请求后，确定用户的信用信息，然后向TPF返回信用响应，如果OCS确定出用户的信用信息，则该信用响应中携带有用户的信用信息，如果OCS未确定出用户的信用信息，则该信用响应中可携带有差错原因值。

由以上描述可见，在3GPP规范描述的在线计费实现过程中，TPF在承载建立、修改时，会向OCS请求用户的信用信息，OCS会根据TPF的信用请求向其返回用户的信用信息。但是，实际应用中，用户可能会针对不同的分组数据业务设置不同的信用池，当用户使用某个分组数据业务时，OCS只能根据与该分组数据业务相对应的信用池中的信用情况，对用户使用该分组数据业务的合法性进行鉴权，例如，确定信用池中的信用余额是否充足，能否允许用户使用该分组数据业务。这样，根据现有的在线计费信用处理流程，OCS根本无法准确地获知应该使用哪一个信用池，对用户能否使用当前分组数据业务进行鉴权，从而无法向TPF提供相应的信用信息，导致对用户信用的控制与管理非常混乱。

发明内容

有鉴于此，本发明的目的在于提供一种基于业务数据流在线计费的信用控制方法，从而对用户的信用进行清晰明确的控制。

为了达到上述目的，本发明提供了一种基于业务数据流在线计费的信用控制方法，OCS收到来自TPF的信用请求之后，该方法包含以下步骤：

A、OCS根据获取的输入信息选择信用池，并确定信用信息。

所述步骤A包括以下步骤：

A1、CRF向TPF提供输入信息；

A2、TPF收到输入信息后，向OCS发送信用请求，该信用请求中携带有输入信息；

A3、OCS收到信用请求后，根据输入信息选择信用池，并确定信用信息。

所述步骤A1之前进一步包括：CRF收到AF提供的应用/业务输入信息，

所述步骤A1为：CRF向TPF提供与应用/业务输入信息相对应的输入信息。

所述步骤A1进一步包括：CRF向TPF提供计费规则，

所述步骤A2进一步包括：TPF对计费规则进行操作。

所述输入信息携带在所述计费规则中。

所述步骤A为：CRF向OCS提供输入信息，OCS根据所述输入信息选择信用池，并确定信用信息。

所述步骤A为：AF向OCS提供输入信息，OCS根据所述输入信息选择信用池，并确定信用信息。

所述步骤A之后进一步包括：OCS向TPF提供信用信息。

所述输入信息为：业务标识，或业务类型，或业务标识与业务类型的组合。

所述输入信息为：信用池标识。

根据本发明提出的方法，在线计费实现过程中，OCS根据收到的输入信息，选择适当的信用池，然后确定信用信息，进而向TPF提供该信用信息。通过向OCS提供用户使用分组数据业务的输入信息，使得OCS能够获知正确的信用池，从而对相应信用池中的用户信用进行控制，使得对用户信用的控制和管理更为合理，避免了用户信用信息的错误使用，使得基于FBC机制的在线计费实现过程更为完整、合理。另外，本发明公开了多种向OCS提供输入信息的方式，使得OCS可通过多种途经获取确定信用池的输入信息。

附图说明

图1为PDP Context激活、传输数据、去激活流程图；

图2A为在线计费的FBC系统结构示意图；

图2B为离线计费的FBC系统结构示意图；

图3A为承载建立时在线计费流程图；

图3B为承载修改时在线计费流程图；

图3C为承载删除时在线计费流程图；

图4为CRF主动向TPF下发计费规则流程图；

图5为本发明中承载建立时在线计费流程图；

图6为本发明中承载修改时在线计费流程图；

图7为本发明中CRF主动向TPF下发计费规则时在线计费流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。

本发明中，OCS根据收到的输入信息，选择适当的信用池，然后确定信用信息，进而向TPF提供该信用信息。以上所述的输入信息可由CRF通过TPF向OCS转发，也可由CRF直接提供给OCS，还可由AF直接提供给OCS。输入信息可为业务信息，也可为信用池标识，另外，业务信息或信用池标识可仅为输入信息的一部分，即输入信息包含的内容不限于业务信息或信用池标识。

CRF在确定某个分组数据业务的计费方式为在线计费之后，会向TPF提供计费规则、在线计费指示和业务信息，在线计费指示用于通知TPF该分组数据业务的当前计费方式为在线计费，业务信息将由TPF提供给OCS，作为OCS确定使用某个信用池的依据，业务信息可携带在计费规则中，也可携带在在线计费指示中。TPF在收到计费规则、在线计费指示和业务信息后，根据在线计费指示向OCS发送信用请求，该信用请求中携带有业务信息。OCS收到信用请求后，根据业务信息选择适当的信用池，确定信用信息，然后向TPF提供针对计费规则的信用信息。

业务信息可为一个或多个业务标识，用于标识不同的分组数据业务，也可为一个或多个业务类型标识，用于标识不同类型的分组数据业务，还可为一个或多个业务标识与一个业务类型标识的组合，用于标识某类分组数据业务中的不同分组数据业务，或多个业务标识与多个业务类型标识的组合，用于标识不同分组数据业务中的不同分组数据业务。CRF可根据AF或TPF提供的输入信息确定业务信息，例如，CRF可根据AF提供的用户使用的分组数据业务的业务标识；也可根据TPF提供的输入信息获取业务标识，将业务标识作为业务信息直接向OCS提供；或是将业务标识转换为业务类型标识后再向OCS提供。业务信息也可为用户标识、承载特性，计费规则相关内容等信息。

业务信息也可不包括任何内容，此时，OCS将根据不包括任何内容的业务信息，选择缺省信用池确定信用信息，缺省信用池可由用户进行预先配置。

在CRF中可以预先配置用户的信用池标识，由CRF根据AF或是TPF的输入信息确定应当使用的信用池标识后，直接向OCS提供信用池标识，OCS根据信用池标识选择使用的信用池，确定信用信息，然后向TPF提供信用信息。

图5为本发明中承载建立时在线计费流程图，如图5所示，承载建立时在线计费的实现过程包括以下步骤：

步骤501：UE向TPF发送承载建立请求，在GPRS网络中，则是GGSN收到Create PDP Context Request。

步骤502：TPF收到承载建立请求后，向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。

步骤503～步骤504：CRF收到计费规则请求后，首先，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，确定当前分组数据业务的计费方式为在线计费；其次，选择适当的计费规则；再次，向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则和计费规则操作指示，计费规则中携带有在线计费指示和业务信息。进一步地，CRF可根据用户信息确定与其相对应的OCS，将OCS地址信息携带在计费规则中发送给TPF，OCS地址信息用于TPF在向OCS请求用户的信用信息时，能够寻址到与用户相对应的OCS，OCS地址信息可携带在在线计费指示中。

步骤505：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作。

步骤506～步骤507：TPF根据在线计费指示确定需要向OCS请求用户的信用信息后，向OCS发送信用请求，该信用请求中携带有供OCS确定信用池的业务信息。OCS收到信用请求后，根据TPF提供的业务信息，选择适当的信用池，并确定用户的信用信息，然后向TPF返回信用响应，如果OCS确定出针对计费规则的用户信用信息，则该信用响应中携带有用户的信用信息，如果OCS未确定出用户的信用信息，则该信用响应中可携带有差错原因值。

如果CRF向TPF提供了OCS地址信息，则TPF根据OCS地址信息寻址到相应OCS，向该OCS发送信用请求，使得TPF能够根据OCS地址信息更明确地确定所需OCS。

步骤508：TPF收到信用响应后，向UE返回承载建立响应，如果信用响应中携带有用户的信用信息，则TPF接受UE发起的承载建立请求，并继续后续的承载建立流程；如果信用响应中未携带有用户的信用信息，则拒绝UE发起的承载建立请求。

图6为本发明中承载修改时在线计费流程图，如图6所示，承载修改时在线计费的实现过程包括以下步骤：

步骤601：UE向TPF发送承载修改请求，在GPRS网络中，则是GGSN收到Create PDP Context Request。

步骤602：TPF收到承载修改请求后，向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。

步骤603～步骤604：CRF收到计费规则请求后，首先，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，确定当前分组数据业务的计费方式为在线计费；其次，选择适当的计费规则；再次，向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则和计费规则操作指示，计费规则中携带有在线计费指示和业务信息。进一步地，CRF可根据用户信息确定与其相对应的OCS，将OCS地址信息携带在计费规则中发送给TPF，OCS地址信息用于TPF在向OCS请求用户的信用信息时，能够寻址到与用户相对应的OCS，OCS地址信息可携带在在线计费指示中。

步骤605：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作。

步骤606～步骤607：TPF根据在线计费指示确定需要向OCS请求用户的信用信息后，向OCS发送信用请求，该信用请求中携带有供OCS确定信用池的业务信息。OCS收到信用请求后，根据TPF提供的业务信息，选择适当的信用池，并确定用户的信用信息，然后向TPF返回信用响应，如果OCS确定出针对计费规则的用户信用信息，则该信用响应中携带有用户的信用信息，如果OCS未确定出用户的信用信息，则该信用响应中可携带有差错原因值。

如果CRF向TPF提供了OCS地址信息，则TPF根据OCS地址信息寻址到相应OCS，向该OCS发送信用请求，使得TPF能够根据OCS地址信息更明确地确定所需OCS。

步骤608：TPF收到信用响应后，向UE返回承载修改响应，如果信用响应中携带有用户的信用信息，则TPF接受UE发起的承载修改请求，并继续后续的承载修改流程；如果信用响应中未携带有用户的信用信息，则拒绝UE发起的承载修改请求。

以上仅以承载建立、承载修改时，实现在线计费的过程为例对本发明进行了说明，在承载删除时，与承载建立、承载修改实现在线计费的过程基本相同，不同之处仅在于传送的消息，因此，在此不再赘述。

图7为本发明中CRF主动向TPF下发计费规则时在线计费流程图，如图7所示，CRF主动向TPF下发计费规则时，在线计费的实现过程包括以下步骤：

步骤701：CRF收到某个内部或外部的触发事件，以及与该事件相关的信息，如AF向CRF发送计费规则选择输入信息的事件。

步骤702：CRF根据获取的输入信息，确定当前分组数据业务的计费方式为在线计费，选择适当的计费规则。以上所述的输入信息可为AF提供的计费相关输入信息，例如，用户使用AF提供的某一分组数据业务，AF向CRF提供该业务的业务标识；也可为TPF提供的计费相关输入信息，如TPF在计费规则请求中向CRF提供的用户标识。

步骤703：根据接收的输入信息，如果CRF确定计费规则发生变化，如CRF根据AF提供的业务标识，确定当前分组数据的计费方式在线计费，需要实时扣除用户使用该分组数据业务的费用，又如CRF根据TPF提供的用户标识，确定该用户属于预付费用户，用户使用所有分组数据业务的费用都需要从用户预先支付的帐户中实时扣除，则CRF选择新的计费规则并向TPF发送提供计费规则，该提供计费规则中可携带选定的计费规则和计费规则操作指示，该计费规则中携带有在线计费指示和业务信息。进一步地，CRF可根据用户信息确定与其相对应的OCS，将OCS地址信息携带在计费规则中发送给TPF，OCS地址信息用于TPF在向OCS请求用户的信用信息时，能够寻址到与用户相对应的OCS，OCS地址信息可携带在在线计费指示中。

步骤704：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作。

步骤705～步骤706：TPF根据在线计费指示确定需要向OCS请求用户的信用信息后，向OCS发送信用请求，该信用请求中携带有供OCS确定信用信息的相关输入信息。OCS收到信用请求后，根据TPF提供的业务信息，选择适当的信用池，并确定针对计费规则的用户信用信息，然后向TPF返回信用响应，如果OCS确定出用户的信用信息，则该信用响应中携带有用户的信用信息，如果OCS未确定出用户的信用信息，则该信用响应中可携带有差错原因值。

如果CRF向TPF提供了OCS地址信息，则TPF根据OCS地址信息寻址到相应OCS，向该OCS发送信用请求，使得TPF能够根据OCS地址信息更明确地确定所需OCS。

在步骤702之后，可由CRF直接向OCS提供业务信息，OCS根据业务信息选择适当的信用池，并确定用户的信用信息，然后OCS向TPF提供用户的信用信息。

另外，也可由AF直接向OCS提供业务信息，OCS根据业务信息选择适当的信用池，并确定用户的信用信息，然后OCS向TPF提供用户的信用信息。

总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (10)

1.一种基于业务数据流在线计费的信用控制方法，其特征在于，在线计费系统OCS收到来自传输面功能实体TPF的信用请求之后，该方法包含以下步骤：

A、OCS根据获取的输入信息选择信用池，并确定信用信息。

2.根据权利要求1所述的方法，其特征在于，所述步骤A包括以下步骤：

A1、基于业务数据流计费的计费规则功能实体CRF向TPF提供输入信息；

A2、TPF收到输入信息后，向OCS发送信用请求，该信用请求中携带有输入信息；

A3、OCS收到信用请求后，根据输入信息选择信用池，并确定信用信息。

3.根据权利要求2所述的方法，其特征在于，

所述步骤A1之前进一步包括：CRF收到应用功能实体AF提供的应用/业务输入信息，

所述步骤A1为：CRF向TPF提供与应用/业务输入信息相对应的输入信息。

4.根据权利要求2所述的方法，其特征在于，

所述步骤A1进一步包括：CRF向TPF提供计费规则，

所述步骤A2进一步包括：TPF对计费规则进行操作。

5.根据权利要求4所述的方法，其特征在于，所述输入信息携带在所述计费规则中。

6.根据权利要求1所述的方法，其特征在于，所述步骤A为：CRF向OCS提供输入信息，OCS根据所述输入信息选择信用池，并确定信用信息。

7.根据权利要求1所述的方法，其特征在于，所述步骤A为：AF向OCS提供输入信息，OCS根据所述输入信息选择信用池，并确定信用信息。

8.根据权利要求1、2、6或7所述的方法，其特征在于，所述步骤A之后进一步包括：OCS向TPF提供信用信息。

9.根据权利要求1、2、6或7所述的方法，其特征在于，所述输入信息为：业务标识，或业务类型，或业务标识与业务类型的组合。

10.根据权利要求1、2、6或7所述的方法，其特征在于，所述输入信息为：信用池标识。

Images