CN1773917A - 一种计费信息的处理方法 - Google Patents

Abstract

本发明公开了一种计费信息的处理方法，涉及分组数据计费领域，该方法包含：OCS将计费关联标识记录在其生成的计费信息中；TPF将计费关联标识记录在其生成的计费信息中，进而在TPF和OCS分别向计费中心提供各自的计费信息时，使得计费中心能够通过计费关联标识将TPF中的计费信息和OCS中的计费信息建立对应关系，将TPF提供的计费信息与OCS提供的计费信息合并生成用户话单，这样，由于TPF提供的计费信息能够体现出业务的具体使用情况，OCS提供的计费信息能够体现出对用户的扣费情况，因此，将TPF提供的计费信息与OCS提供的计费信息合并后生成的用户话单，就能够体现用户使用的业务信息、业务使用情况以及最终的扣费情况，满足了用户对话单完整性和详尽性的需求。

Description

一种计费信息的处理方法

技术领域

本发明涉及分组数据计费领域，特别是指一种计费信息的处理方法。

背景技术

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

图1示出了分组数据协议上下文(PDP Context，Packet Data ProtocolContext)激活、数据传输、去激活流程图，如图1所示，在通用分组无线业务(GPRS，General Packet Radio Service)中，激活PDP Context、与外部分组数据网络(PDN，Packet Data Network)进行数据交互、去激活该PDPContext的实现过程包括以下步骤：

步骤101：移动终端(MS)向服务通用分组无线业务支持节点(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)之间作为隧道标识(TID，Tunnel Identifier)的组成部分，用于标识PDPContext；PDP类型包括端对端协议(PPP，Peer-Peer Protocol)类型、网际协议(IP，Internet Protocol)类型等；APN可由MS向SGSN提供，SGSN根据APN寻址到相应GGSN，GGSN根据APN确定MS所要访问的外部网络，MS也可不向SGSN提供APN，此时，由SGSN根据MS用户的签约信息选择缺省的APN；QoS参数为MS指定的分组数据业务所要达到的质量要求；TI用于MS标识某个PDP context。

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

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

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

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

步骤106：MS通过SGSN、GGSN与PDN进行分组数据的交互。

步骤107：结束分组数据交互后，MS向SGSN发送PDP Context去激活请求(Deactivate PDP Context Request)，该PDP Context去激活请求中携带有TI。

步骤108：SGSN收到PDP Context去激活请求后，与MS进行安全性检查和加密，该步骤为可选步骤。

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

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

针对上述情况，第三代合作伙伴计划(3GPP，The 3rd GenerationPartnership Project)目前正在讨论如何实现基于IP数据流的计费(FBC，FlowBased Charging)。对于一个分组数据业务而言，MS的用户使用该业务时，传输和接收到的所有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发送计费规则请求，该计费规则请求中携带有与用户和MS相关的信息、承载特性以及与网络相关的信息等，其中与用户和MS相关的信息可为移动台国际号码(MSISDN)、国际移动用户标识(IMSI)等，与网络相关的信息可为移动网络编码(MNC)、移动国家码(MCC)等。另外，由于在IP数据流传输过程中，会对承载进行修改，如对QoS参数进行重新协商，当用户使用同一业务的QoS参数不同时，计费规则可能不同，如QoS参数下降相应的费率也下降。此时，TPF 205可在承载修改时，重新向CRF 203发送计费规则请求，请求新的计费规则；CRF 203根据TPF 205提供的上述输入信息选择适当的计费规则，并向TPF 205返回选定的计费规则，计费规则中包括计费机制、计费类型、计费键(Charging Key)、业务数据流过滤器、计费规则优先级等信息。其中，计费机制可为采用在线计费还是离线计费；计费类型可为基于时间长度进行计费还是基于数据流量进行计费；计费键是与费率相关的参数，CRF 203可不直接向TPF 205提供费率，而只是向TPF 205提供与费率相关的参数；业务数据过滤器用于指示TPF205对哪些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数据流进行记录，生成相应的计费信息。

TPF生成的计费信息中可包含业务信息、业务使用情况等，TPF可通过CRF下发的计费规则中获取业务信息，TPF可通过对过滤出的IP数据流进行统计获取业务使用情况，如使用业务的数据流量、使用业务的时间长度等，然后TPF通过Gz接口向CCF/CGF上报生成的计费信息，CCF/CGF对收到的TPF提供的计费信息进行处理，然后上报至计费中心，由计费中心生成最终的用户话单。

OCS 206作为在线计费系统，由SCP 201和CCF(Service Data FlowBased Credit Control Function)202两个功能实体组成，其中，CCF(ServiceData Flow Based Credit Control Function)202是执行信用控制的功能实体，仅应用于在线计费系统，可通过在现有的OCS 206中增加新的功能来实现。在在线计费过程中，CCF(Service Data Flow Based Credit Control Function)202对用户信用进行管理和控制，当用户使用业务时，CCF(Service Data FlowBased Credit Control Function)202对该用户信用池中的信用进行鉴权，并通过Gy接口向TPF 205下发用户能够使用的信用。OCS将用户消耗的信用额度生成计费信息并发送至CCF/CGF，CCF/CGF对收到的OCS提供的计费信息进行处理，然后上报至计费中心，由计费中心生成最终的用户话单。

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

对于基于业务数据流的在线计费过程中，3GPP规范中描述的请求信用额度的处理方式是基于每个计费规则(Charging Rule)进行的，具体实现过程为：TPF收到CRF提供的计费规则后，根据计费规则中的在线计费机制，确定需要为该计费规则向OCS请求信用额度时，TPF直接向OCS请求针对该计费规则的信用额度。

然而，CRF向TPF提供的计费规则的计费粒度是针对不同的业务数据流，这样，在线计费时，TPF需要针对每个业务数据流与OCS进行在线计费交互，即针对每个业务数据流TPF都需要向OCS请求信用额度，OCS根据TPF的请求，需要对每个业务数据流都分配相应的信用额度，并下发给TPF，由于同一用户同时可以使用多个业务，从而产生多个业务数据流，因此，这种基于不同的业务数据流进行在线计费交互的处理机制必然会使得TPF与OCS的交互过于频繁，导致TPF与OCS的处理性能下降，从而使整个在线计费处理过程的实用性大大降低。

基于上述考虑，3GPP规范中新提出了基于每个计费键请求信用额度的处理方式，这里，计费键是指CRF向TPF下发的计费规则中包含计费费率信息的参数。对基于每个计费键请求信用额度的处理方式与基于每个计费规则请求信用额度的处理方式进行比较，就会发现：后一种处理方式的粒度是针对不同的业务数据流进行的，由于每个计费规则指定了每个业务数据流，则对于基于每计费规则请求信用额度的处理方式，TPF需要针对不同业务数据流向OCS请求信用额度，OCS根据TPF的信用请求为不同业务数据流分配信用额度；而前一种处理方式的粒度是针对不同费率信息进行的，TPF针对不同费率信息向OCS请求信用额度，OCS根据TPF的信用请求为不同的费率信息分配信用额度，由于不同的业务数据流可能具有相同的计费费率，因此，基于每个计费键请求信用额度的粒度大于基于每个计费规则请求信用额度。这样，通过实现TPF基于每个计费键请求信用额度的处理过程，可以有效减少TPF与OCS之间的频繁交互，避免了由于频繁交互而导致的处理性能下降，从而使得整个在线计费处理过程更具实用性。

但是，在TPF基于每个计费键请求信用额度的处理方式下，TPF将屏蔽掉所有与业务数据流有关的信息，而只按照计费键向OCS请求信用额度，这样，OCS只能获取计费费率的相关信息，并根据计费费率分配相应的信用额度，但OCS而无法确定分配的信用额度是由哪些业务消耗的，因此，OCS生成的计费信息只能总体上体现信用额度的消耗情况，而无法在细节上体现各业务消耗信用额度的具体情况，如用户使用的哪些业务消耗了信用额度，以及各业务消耗多少信用额度的具体情况，进而使得计费中心最后依据OCS提供的计费信息生成的用户话单中，也无法体现详细的业务信息以及业务使用情况。这样，用户无法通过用户话单明确获知各业务的具体使用情况，影响了用户对FBC在线计费的接受程度，并潜在着可能的用户与运营商之间的计费纠纷。

发明内容

有鉴于此，本发明的目的在于提供一种计费信息的处理方法，使TPF生成的计费信息与OCS生成的计费信息相关联，进一步满足用户对最终话单完整性和详尽性的需求。

为了达到上述目的，本发明提供了一种计费信息的处理方法，该方法包含：

A、OCS将计费关联标识记录在其生成的计费信息中；TPF将计费关联标识记录在其生成的计费信息中。

所述步骤A之前进一步包括：

A01、TPF生成计费关联标识，并提供给OCS。

所述步骤A01进一步包括：TPF向OCS请求针对计费键的信用额度。

所述步骤A01之前进一步包括：TPF建立计费规则时，根据计费规则中的计费键，判断是否已向OCS请求了针对该计费键的信用额度，如果不是，则执行步骤A01。

所述步骤A01进一步包括：TPF向OCS提供TPF标识信息。

所述步骤A之前进一步包括：

A02、OCS生成计费关联标识，并提供给TPF。

所述步骤A02之前进一步包括：TPF向OCS请求针对计费键的信用额度。

所述步骤A02进一步包括：OCS向TPF提供针对计费键分配的信用额度。

OCS判断TPF先前是否未针对所述计费键请求过信用额度，如果是，则执行步骤A02。

所述步骤A02进一步包括：OCS向TPF提供OCS标识信息。

所述步骤A之后进一步包括：TPF和OCS分别向计费中心提供记录有计费关联标识的计费信息中，计费中心将所述计费信息合并处理后生成用户话单。

根据本发明提出的方法，在TPF基于一个新的计费键向OCS请求信用额度时，为需要请求信用额度的计费键分配计费关联标识，并向OCS提供计费关联标识，TPF和OCS分别将计费关联标识记录在相应的计费信息中，进而在TPF和OCS分别向计费中心提供各自的计费信息时，使得计费中心能够通过计费关联标识将TPF中的计费信息和OCS中的计费信息建立对应关系，将TPF提供的计费信息与OCS提供的计费信息合并生成用户话单，这样，由于TPF提供的计费信息能够体现出业务的具体使用情况，即用户使用各业务的业务信息、产生数据流量，或是时长信息，以及消耗的信用额度信息等，OCS提供的计费信息能够体现出对用户的扣费情况，因此，将TPF提供的计费信息与OCS提供的计费信息合并后生成的用户话单，就能够体现用户使用的业务信息、业务使用情况以及最终的扣费情况，满足了用户对话单完整性和详尽性的需求。

附图说明

图1示出了PDP Context激活、数据传输、去激活流程图；

图2A示出了支持在线计费的FBC系统结构图；

图2B示出了支持离线计费的FBC系统结构图；

图3示出了本发明中基于计费键请求信用额度处理过程示意图。

具体实施方式

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

本发明中，在TPF基于一个新的计费键向OCS请求信用额度时，为该计费键分配计费关联标识，并向OCS提供计费关联标识，另外，该计费关联标识也可以是由OCS分配，并向TPF提供。在生成计费信息时，TPF和OCS分别将计费关联标识记录在各自的计费信息中，进而在TPF和OCS分别向计费中心提供各自的计费信息时，使得计费中心能够通过计费关联标识将TPF提供的计费信息和OCS提供的计费信息建立对应关系，将TPF提供的计费信息与OCS提供的计费信息合并生成用户话单，这样，由于TPF提供的计费信息能够体现出业务的具体使用情况，OCS提供的计费信息能够体现出对用户的扣费情况，因此，将TPF提供的计费信息与OCS提供的计费信息合并后生成的用户话单，就能够体现用户使用具体业务的所有详细信息以及最终的扣费情况，满足了用户对话单完整性和详尽性的需求。

TPF收到CRF提供的计费规则后，如果需要建立新的计费规则或修改原有的计费规则时，则TPF首先判断需要建立或修改的计费规则中的计费机制是否为在线计费，如果为在线计费，则进一步根据该计费规则中的计费键，判断是否已针对相应计费键向OCS请求了信用额度，如果是，则TPF不为该计费键分配计费关联标识，也不向OCS请求信用额度，直接使用先前针对该计费键向OCS请求到的信用额度，即该业务数据流将消耗TPF先前针对该计费键向OCS请求到的信用额度，并将先前向OCS请求信用额度时为该计费键分配的计费关联标识，记录在TPF为该计费规则指定的业务数据流生成的计费信息中，然后TPF记录与已请求信用额度的计费键相对应的计费规则信息，如计费规则标识；否则，TPF判断出该计费键为新计费键，即未针对相应计费键向OCS请求信用额度，则为该计费键分配计费关联标识，针对该计费键向OCS请求信用额度，并向OCS提供TPF标识，如TPF地址信息和分配的计费关联标识，这里，计费关联标识中可进一步包含TPF标识，此时TPF只需向OCS提供计费关联标识，然后TPF记录已请求信用额度的计费键与已请求信用额度的计费键相对应的计费规则信息，如计费规则标识，及与计费键之间的对应关系。OCS收到信用请求后，根据用户帐户计算信用额度，并将计费关联标识记录在为该计费键分配信用额度时生成的相应计费信息中，TPF收到OCS提供的信用额度后，依据该信用额度监控与该计费键相对应的计费规则所指定的业务数据流，并将相应计费关联标识记录在为所监控的业务数据流生成的计费信息中。如果为离线计费，则按照离线计费处理流程进行处理。

业务结束后，TPF生成包含业务信息、计费关联标识、TPF标识信息、业务使用情况等内容的计费信息，并经由CCF/CGF向计费中心提供该计费信息；TPF与OCS结束交互后，即基于某一计费键的信用额度的交互结束后，OCS生成包含信用额度扣除信息、计费关联标识、TPF标识信息等内容的计费信息，并经由CCF/CGF向计费中心提供该计费信息，计费中心根据计费关联标识和TPF标识信息将TPF生成的计费信息与OCS生成的计费信息进行合并处理，合并后的计费信息既包含业务信息和业务的使用情况，又包含信用扣除信息，这样，计费中心可根据合并后的计费信息生成向用户提供的最终话单。

以上所述计费关联标识可为在线计费时，在每个TPF中唯一标识一个计费键的标识，也可为在在线计费时，所有TPF中唯一标识计费键的标识。如果计费关联标识在一个TPF中唯一标识计费键，则TPF向OCS请求信用额度时，除OCS提供计费关联标识外，还需向OCS提供TPF标识信息，如TPF地址信息；如果计费关联标识在所有TPF中均能唯一标识某个TPF中的计费键，则TPF向OCS请求信用额度时，可仅向OCS提供计费关联标识。

另外，计费关联标识也可以是由OCS分配，并向TPF提供的。当OCS接收到TPF的信用请求，判断出TPF为一个新的计费键请求信用额度时，OCS为该新的计费键分配新的计费关联标识，并在返回的信用响应中将计费关联标识和OCS标识信息提供给TPF。后续TPF和OCS的处理与上述TPF分配计费关联标识的情况类似，这里不再赘述。

对于OCS判断TPF为一个新的计费键请求信用额度的判断方法，其具体的实现方式可以是：TPF每次向OCS请求基于新的计费键的信用额度时，均建立TPF与OCS之间的新的对话，OCS接收到TPF的信用请求时，根据判断TPF是否是基于TPF与OCS之间新建立的对话来发起该信用请求的，如果是，则判断出接收到的信用请求是TPF为一个新的计费键请求信用额度，否则，则判断出接收到的信用请求是TPF针对原来的计费键请求信用额度。

图3示出了本发明中基于计费键请求信用额度处理过程示意图，如图3所示，基于计费键请求信用额度的处理过程包括以下步骤：

步骤301～步骤302：CRF可根据收到的来自外部实体的信息，例如，CRF收到来自TPF的承载建立、修改或删除等消息，或CRF收到AF或OCS提供的与计费规则相关的输入信息，选择需要向TPF提供的计费规则，CRF可要求TPF建立新的计费规则，或要求TPF对原来的计费规则进行修改。CRF向TPF提供选定的计费规则，并指示TPF对计费规则进行相应操作。

步骤303～步骤304：TPF收到计费规则后，根据计费规则操作指示对计费规则进行相应操作，如建立、修改计费规则。在线计费情况下，如果TPF是建立新的计费规则或修改原来的计费规则，则根据该计费规则中的计费键，判断是否已根据相应计费键向OCS请求了信用额度，如果是，则TPF不为该计费键分配计费关联标识，也不向OCS请求信用额度，直接使用先前针对该计费键向OCS请求到的信用额度，即该业务数据流将消耗TPF先前针对该计费键向OCS请求到的信用额度，并将先前向OCS请求信用额度时为该计费键分配的计费关联标识，记录在TPF为该计费规则指定的业务数据流生成的计费信息中，然后TPF记录与已请求信用额度的计费键相对应的计费规则信息，如计费规则标识；否则，执行步骤305。

步骤305～步骤306：TPF为该计费键分配计费关联标识，然后向OCS发送信用请求(Credit Request)，请求OCS针对该计费键分配信用额度，该信用请求中可进一步携带有TPF地址信息。OCS收到信用请求后，根据请求中的计费键计算用户的信用额度，然后向TPF返回信用响应(CreditResponse)，该信用响应中携带有为该计费键分配的信用额度，并且OCS将接收到的计费关联标识记录在为该计费键分配信用额度时生成的相应计费信息中。TPF收到信用响应后，依据该信用额度监控该计费键对应的计费规则所指定的业务数据流，并将相应计费关联标识记录在为所监控的业务数据流生成的相应计费信息中。

业务结束后，TPF生成包含业务信息、计费关联标识、TPF地址信息、业务使用情况等内容的计费信息，并经由CCF/CGF向计费中心提供该计费信息；TPF与OCS结束交互后，即基于某一计费键的信用额度的交互结束后，OCS生成包含信用额度扣除信息、计费关联标识、TPF标识信息等内容的计费信息，并经由CCF/CGF向计费中心提供该计费信息，计费中心根据计费关联标识和TPF标识信息将TPF生成的计费信息与OCS生成的计费信息进行合并处理，合并后的计费信息既包含业务信息和业务的使用情况，又包含信用扣除信息，这样，计费中心根据合并后的计费信息生成向用户提供的最终话单。

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

Claims (11)

1、一种计费信息的处理方法，其特征在于，该方法包含：

A、OCS将计费关联标识记录在其生成的计费信息中；TPF将计费关联标识记录在其生成的计费信息中。

2、根据权利要求1所述的方法，其特征在于，所述步骤A之前进一步包括：

A01、TPF生成计费关联标识，并提供给OCS。

3、根据权利要求2所述的方法，其特征在于，所述步骤A01进一步包括：TPF向OCS请求针对计费键的信用额度。

4、根据权利要求3所述的方法，其特征在于，所述步骤A01之前进一步包括：TPF建立计费规则时，根据计费规则中的计费键，判断是否已向OCS请求了针对该计费键的信用额度，如果不是，则执行步骤A01。

5、根据权利要求2或3所述的方法，其特征在于，所述步骤A01进一步包括：TPF向OCS提供TPF标识信息。

6、根据权利要求1所述的方法，其特征在于，所述步骤A之前进一步包括：

A02、OCS生成计费关联标识，并提供给TPF。

7、根据权利要求6所述的方法，其特征在于，所述步骤A02之前进一步包括：TPF向OCS请求针对计费键的信用额度。

8、根据权利要求7所述的方法，其特征在于，所述步骤A02进一步包括：OCS向TPF提供针对计费键分配的信用额度。

9、根据权利要求7所述的方法，其特征在于，OCS判断TPF先前是否未针对所述计费键请求过信用额度，如果是，则执行步骤A02。

10、根据权利要求6、7或8所述的方法，其特征在于，所述步骤A02进一步包括：OCS向TPF提供OCS标识信息。

11、根据权利要求1、2或6所述的方法，其特征在于，所述步骤A之后进一步包括：TPF和OCS分别向计费中心提供记录有计费关联标识的计费信息中，计费中心将所述计费信息合并处理后生成用户话单。

Images