一种在线计费的处理方法

文档序号:7599419阅读:217来源:国知局
专利名称:一种在线计费的处理方法
技术领域
本发明涉及分组数据计费领域,特别是指一种在线计费的处理方法。
背景技术
随着分组数据业务应用的逐渐广泛,如何准确合理地对分组数据业务进行计费,已成为运营商普遍关注的问题。
图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。
步骤102SGSN收到Activate PDP Context Request后,与MS进行安全性检查和加密,该步骤为可选步骤。
步骤103SGSN根据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激活请求。
步骤104GGSN收到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激活请求。
步骤105SGSN收到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直接的路由,可以进行分组数据的传输了。
步骤106MS通过SGSN、GGSN与PDN进行分组数据的交互。
步骤107结束分组数据交互后,MS向SGSN发送PDP Context去激活请求(Deactivate PDP Context Request),该PDP Context去激活请求中携带有TI。
步骤108SGSN收到PDP Context去激活请求后,与MS进行安全性检查和加密,该步骤为可选步骤。
步骤109~步骤111SGSN向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数据流进行计费。
CRF 203可向TPF 205提供触发事件(Event Trigger),用以要求TPF 205在特定事件发生时,向CRF 205请求新的计费规则,如CRF 203要求TPF 205在某些承载进行修改的事件发生时,向CRF 203请求新的计费规则。触发事件可视为与计费规则相关的事件。目前,3GPP规范中对CRF通过触发事件上报机制控制TPF的计费方式进行了描述,即TPF监测到触发事件发生后向CRF上报,CRF通过TPF上报的触发事件获知承载发生变化,然后确定相应的计费规则并下发给TPF。3GPP规范中定义的触发事件可包括公用陆地移动通信网络(PLMN)变化(PLMN change)事件,QoS参数变化(QoSchanges)事件,无线接入技术(RAT)类型变化(RAT type change)事件,传输流模板(TFT)变化(TFT change)事件。
CRF 203除了根据TPF 205提供的输入信息选择适当的计费规则之外,CRF 203还可根据AF 204或OCS 206的输入信息选择适当的计费规则,如AF 204通知CRF 203用户当前使用的业务类型,CRF 203根据该业务类型选择相应的计费规则。
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 206可要求TPF 205在重鉴权事件(Re-authorisation triggers)发生时向其上报,然后OCS 206根据TPF 205上报的相应重鉴权事件对用户进行重鉴权,并可能重新计算用户的信用。例如,OCS 206向TPF 205提供的用户信用使用完毕,TPF 205需根据重鉴权事件中的允许信用过期事件,向OCS 206上报其允许的用户信用使用过期事件的发生,OCS 206根据用户剩余帐户信息,重新对允许用户使用的信用进行计算。又例如,分区域计费时,OCS 206根据用户当前所在位置确定费率,并根据该费率计算用户的信用;当用户移动至另一位置时,如PLMN发生变化,TPF 205需要根据重鉴权事件中的PLMN变化事件,向OCS 206上报PLMN变化事件的发生,OCS206根据用户更新后的当前所在位置重新确定费率,并重新计算用户的信用。又例如,当OCS 206根据用户使用业务的当前QoS参数确定费率,当用户对QoS参数进行修改,TPF 205需要根据重鉴权事件中的承载修改事件,向OCS 206上报承载修改事件的发生,OCS 206根据用户修改后的QoS参数确定费率,并重新计算用户的信用。
另外,3GPP规范中还对OCS通过重鉴权事件上报的机制控制TPF的信用使用情况进行了描述,即TPF监测到重鉴权事件发生后向OCS上报,OCS通过TPF上报的重鉴权事件,获知用户的信用使用情况以及承载的变化,对用户的信用重新进行计算并下发给TPF。3GPP规范中定义的重鉴权事件可包括允许信用过期(credit authorization lifetime expiry)事件,用户空闲状态超时(idle timeout)事件,计费规则变化(charging rule is changed)事件,PLMN变化事件,QoS参数变化事件,RAT类型变化事件。
对应于GPRS网络,TPF 205为GGSN,AF为PDN中的一个业务网关或业务服务器,CRF 203为新增的逻辑实体。TPF 205为计费规则的执行点,CRF 203为计费规则的控制点。
对于基于分组数据流的计费,目前3GPP规范中提出可以基于数据流量进行计费,也可以基于时间长度进行计费,还可以基于数据流量和时间长度进行计费。基于数据流量的计费模式是以传输的数据量的大小作为计费依据;基于时间长度的计费模式是以传输数据所使用的时间长度作为计费依据;基于数据流量和时间长度的组合计费模式是以一段时间长度内传输的数据量的大小作为计费依据。
目前,3GPP规范中提出在线计费情况下,可以基于数据流量和时间长度来进行组合计费,但是并未描述具体的实现过程,使得基于流量和时间长度的组合计费模式的处理不明确,影响了基于流量和时间长度的组合计费模式的可用性和明确性。

发明内容
有鉴于此,本发明的目的在于提供一种在线计费的处理方法,明确基于流量和时间长度的组合计费模式的处理过程,也可使OCS对用户使用的网络资源进行控制。
为了达到上述目的,本发明提供了一种基于在线计费的处理方法,该方法包含以下步骤A、OCS向TPF提供信用额度和监控条件;B、TPF监测到信用额度已消耗完毕或监控条件已满足,TPF请求OCS对用户进行重鉴权。
所述步骤A之前进一步包括OCS根据用户帐户计算基于数据流量的信用额度,所述监控条件为时间限度。
所述步骤B进一步包括TPF向OCS返回剩余的基于数据流量的信用额度,或剩余的时间长度,或以上二者的组合,请求OCS提供新的基于数据流量的信用额度。
所述步骤A之前进一步包括OCS根据用户帐户计算基于时间长度的信用额度,所述监控条件为数据流量限度。
所述步骤B进一步包括TPF向OCS返回剩余的基于时间长度的信用额度,或剩余的数据流量,或以上二者的组合,请求OCS提供新的基于时间长度的信用额度。
所述步骤A之前进一步包括A0、CRF向TPF提供数据流量限度和时间限度,TPF向OCS提供数据流量限度和时间限度。
所述步骤A0进一步包括CRF向TPF提供基于数据流量和时间长度进行组合计费的计费模式指示,TPF向OCS提供基于数据流量和时间长度进行组合计费的计费模式指示。
步骤A中所述信用额度为用户帐户下所有信用额度的其中一部分。
所述步骤B之后进一步包括C、OCS向TPF提供信用额度和监控条件,然后返回执行步骤B。
所述步骤C之前进一步包括OCS根据剩余的基于数据流量的信用额度,或剩余的时间长度,或以上二者的组合,计算基于数据流量的新的信用额度;或,OCS根据剩余的基于时间长度的信用额度,或剩余的数据流量,或以上二者的组合,计算基于时间长度的新的信用额度。
所述步骤B之后进一步包括OCS确定触发当前信用请求的原因,如果所述原因为时间限度定时器期满,则OCS判断用户使用的数据流量是否低于系统设置的数据流量最小值,如果是,则OCS终止当前与TPF之间的对话;否则,OCS向TPF提供时间限度和计算的新的基于数据流量的信用额度,然后返回执行步骤B。
所述OCS终止当前与TPF之间的对话为OCS向TPF发送终止操作指示,TPF释放与当前OCS和TPF之间对话相对应的业务的数据流的会话。
根据本发明提出的方法,在线计费情况下,OCS向TPF提供信用额度的同时,还向TPF提供监控条件;当TPF监测到信用额度已消耗完毕或监控条件已满足,TPF请求OCS对用户进行重鉴权,并返回剩余的信用额度或是剩余的监控条件信息。通过TPF与OCS的交互,使得OCS能够获知向TPF下发的信用额度使用完毕时剩余的监控条件信息,或是监控条件满足时剩余的信用额度信息,从而可实现基于数据流量和时间长度的组合计费,也可使OCS能够对一定时间长度内用户使用网络资源的情况进行监控。


图1示出了PDP Context激活、数据传输、去激活流程图;图2A示出了支持在线计费的FBC系统结构图;图2B示出了支持离线计费的FBC系统结构图;图3示出了本发明中基于数据流量和时间长度的组合计费模式的一种处理过程示意图;图4示出了本发明中基于数据流量和时间长度的组合计费模式的另一种处理过程示意图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚,下面结合附图对本发明作进一步的详细描述。
本发明中,在线计费情况下,OCS向TPF提供基于数据流量的信用额度的同时,还向TPF提供时间限度;TPF根据信用额度对数据流量进行监控,并根据时间限度启动时间限度定时器,当信用额度已消耗完毕或是时间限度定时器期满时,TPF请求OCS对用户进行重鉴权,并返回剩余的信用额度。通过TPF与OCS的交互,使得OCS能够获知向TPF下发的信用额度使用完毕时耗费的时间长度,或是一定的时间限度期满时耗费的信用额度,从而可实现基于数据流量和时间长度的组合计费,也可使OCS能够对一定时间长度内用户使用网络资源的情况进行监控。
另外,本发明中,在线计费情况下,OCS还可向TPF提供基于时间长度的信用额度的同时,还向TPF提供数据流量限度;TPF根据信用额度对时间长度进行监控,当信用额度已消耗完毕或是数据流量达到数据流量限度时,TPF请求OCS对用户进行重鉴权,并返回剩余的信用额度。通过TPF与OCS的交互,使得OCS能够获知向TPF下发的信用额度使用完毕时剩余的数据流量,或是数据流量达到限度时剩余的信用额度,从而可实现基于数据流量和时间长度的组合计费。
图3示出了本发明中基于数据流量和时间长度的组合计费模式下,信用额度采用基于流量的方式进行计算的处理过程示意图,如图3所示,信用额度采用流量的方式计算时基于数据流量和时间长度的组合计费模式的处理过程包括以下步骤步骤301CRF向TPF提供计费规则(Provision Charging Rules)时,向TPF指明当前计费机制为在线计费,并向TPF提供基于数据流量和时间长度组合计费的计费模式指示;进一步地,CRF可向TPF提供需监控的时间限度及数据流量限度,数据流量限度可为最低流量限度,也可为最高流量限度,如CRF向TPF提供时间限度为1小时,最低数据流量为1M字节,即表明该计费方式下用户在每小时内至少需要使用的数据流量为1M字节,如果使用的数据流量不足1M字节,则按照1M字节的数据流量进行计费,如果数据流量超过1M字节,则按照实际的数据流量进行计费。另外,CRF还可向TPF提供用于指示费率信息的计费键,如2元/M字节。
步骤302TPF收到CRF提供的计费规则后,根据在线计费的计费机制向OCS发送信用请求(Credit Request),请求OCS提供用户的信用额度,该信用请求中携带有供OCS确定用户信用额度的输入信息,如基于数据流量和时间长度组合计费的计费模式、时间限度、数据流量限度以及计费键等信息。
这里,步骤301和步骤302中的计费模式、时间限度和数据流量限度可合并在计费键中,通过计费键一个参数提供,也可定义新的一个或多个参数来提供。
步骤303OCS收到信用请求后,根据用户的帐户和计费键指示的费率信息,计算用户能够使用的基于数据流量的信用额度,如果该用户的帐户能够使用100M字节的数据流量,则向TPF返回信用响应(Credit Response),该信用响应中携带有基于数据流量的信用额度及时间限度。此处,为避免一次为一个业务分配过多的信用额度,而导致用户使用其他业务时的信用受限,OCS可一次仅向TPF提供一部分信用额度,如每次提供10M字节的信用额度。
步骤304~步骤306TPF收到信用响应后,根据OCS提供的基于数据流量的信用额度对数据流量进行监控,并启动时间限度定时器。TPF监测到数据流量达到信用额度,或时间限度定时器期满,TPF向OCS发送信用请求,该信用请求中携带有剩余的基于数据流量的信用额度,或是剩余的时间限度,请求OCS提供新的信用额度;该信用请求中可进一步携带有当前信用请求发起的原因,以使OCS能够更明确地获知触发当前信用请求的原因是数据流量达到信用额度,还是时间限度定时器期满。
步骤307OCS收到信用请求后,确定触发当前信用请求的原因,如果触发当前信用请求的原因是数据流量达到信用额度,则OCS根据用户的帐户信息和计费键指示的费率信息,计算出基于数据流量的新的信用额度,然后向TPF返回信用响应,该信用响应中携带有基于数据流量的新的信用额度及时间限度;如果触发当前信用请求的原因是时间限度定时器期满,则OCS根据基于数据流量和时间长度组合计费的计费模式以及计费键指示的费率信息对用户进行扣费,如用户1小时内使用不足1M字节的数据流量按照1M字节来进行计费,费率为2元/M字节,则该用户在该1小时内消费了2元,然后OCS根据用户的剩余帐户和计费键指示的费率信息,计算出基于数据流量的新的信用额度,然后向TPF返回信用响应,该信用响应中携带有基于数据流量的新的信用额度及时间限度。
后续过程即为重复执行步骤304~步骤307,直至用户结束相应业务的使用或用户帐户中的信用额度全部使用完毕。
另外,在不是基于数据流量和时间长度进行计费的情况下,也可利用以上基于数据流量和时间长度的组合计费模式的处理方式,使OCS对用户使用的网络资源进行更好地控制。
OCS在向TPF提供基于数据流量的信用额度的同时,可主动向TPF提供时间限度,TPF根据信用额度对数据流量进行监控,并根据时间限度启动时间限度定时器。当TPF向OCS发送新的信用请求,并且OCS确定触发该信用请求的原因是时间限度定时器期满,OCS可进一步确定用户在时间限度中使用的数据流量,如果用户在时间限度内使用的数据流量很少时,如用户在时间限度内使用的数据流量低于系统设置的数据流量最小值,则可推断该用户目前极少使用该业务,或是用户已经不再使用该业务,即可能是异常情况时,用户停止使用某个业务时,用户侧的资源已经释放,但网络侧的资源尚未释放,仍处于占用状态,这样,为了避免网络资源的无谓占用或被吊死,OCS可主动发起终止当前OCS和TPF之间的对话的流程,即OCS向TPF发送终止操作指示,要求TPF释放相应OCS和TPF之间对话。TPF释放当前OCS和TPF之间对话对应的业务的数据流的会话。
另外,本发明中还提供了基于数据流量和时间长度的组合计费模式下,信用额度采用基于时间长度的方式进行计算的处理过程示意图,如图4所示,信用额度采用时长的方式计算时基于数据流量和时间长度的组合计费模式的处理过程包括以下步骤步骤401CRF向TPF提供计费规则时,向TPF指明当前计费机制为在线计费,并向TPF提供基于数据流量和时间长度组合计费的计费模式指示;进一步地,CRF可向TPF提供需监控的数据流量限度及时间限度,时间限度可为最小时间限度,也可为最大时间限度,如CRF向TPF提供监控数据流量为10M字节,最小时间限度为1小时,即表明该计费方式下用户在每小时内最多使用10M字节的数据流量。如果使用了超过10M字节数据流量却消耗了不足1小时的时间长度,则按照1小时进行计费,如果使用的10M字节的数据流量消耗了超过1小时的时间长度,则按照实际的时间长度进行计费,这样,可以避免运营商采用基于时间长度作为信用额度的计算单位时,用户在短时间内使用大量的网络资源而导致的运营商的计费损耗。另外,CRF还可向TPF提供用于指示费率信息的计费键,如2元/小时。
步骤402TPF收到CRF提供的计费规则后,根据在线计费的计费机制向OCS发送信用请求,请求OCS提供用户的信用额度,该信用请求中携带有供OCS确定用户信用额度的输入信息,如基于数据流量和时间长度组合计费的计费模式、时间限度、数据流量以及计费键等信息。
这里,步骤401和步骤402中的计费模式、时间限度和数据流量可合并在计费键中,通过计费键一个参数提供,也可定义新的一个或多个参数来提供。
步骤403OCS收到信用请求后,根据用户的帐户和计费键指示的费率信息,计算用户能够使用的基于时间长度的信用额度,如果该用户的帐户能够使用10小时的业务,则向TPF返回信用响应,该信用响应中携带有基于时间长度的信用额度及数据流量限度。此处,为避免一次为一个业务分配过多的信用额度,而导致用户使用其他业务时的信用受限,OCS可一次仅向TPF提供一部分信用额度,如每次提供1小时的信用额度。
步骤404~步骤406TPF收到信用响应后,根据OCS提供的基于时间长度的信用额度启动相应的时间长度定时器,并监控用户使用的数据流量。TPF监测到时间长度定时器期满,或是监控的数据流量达到数据流量限度,TPF向OCS发送信用请求,该信用请求中携带有剩余的基于时间长度的信用额度,或是剩余的数据流量,请求OCS提供新的信用额度;该信用请求中可进一步携带有当前信用请求发起的原因,以使OCS能够更明确地获知触发当前信用请求的原因是时间长度达到信用额度,还是监控的数据流量达到数据流量限度。
步骤407OCS收到信用请求后,确定触发当前信用请求的原因,如果触发当前信用请求的原因是时间长度达到信用额度,则OCS根据用户的帐户信息和计费键指示的费率信息,计算出基于时间长度的新的信用额度,然后向TPF返回信用响应,该信用响应中携带有基于时间长度的新的信用额度及监控的数据流量限度;如果触发当前信用请求的原因是监控的数据流量达到数据流量限度,则OCS根据基于数据流量和时间长度组合计费的计费模式以及计费键指示的费率信息对用户进行扣费,如用户使用10M字节的数据流量耗费的时间长度不足1小时,则按照1小时来进行计费,费率为2元/小时,则该用户在该段不足1小时的时间长度内消费了2元,然后OCS根据用户的剩余帐户和计费键指示的费率信息,计算出基于时间长度的新的信用额度,然后向TPF返回信用响应,该信用响应中携带有基于时间长度的新的信用额度及数据流量限度。
后续过程即为重复执行步骤404~步骤407,直至用户结束相应业务的使用或用户帐户中的信用额度全部使用完毕。
总之,以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。
权利要求
1.一种在线计费的处理方法,其特征在于,该方法包含以下步骤A、OCS向TPF提供信用额度和监控条件;B、TPF监测到信用额度已消耗完毕或监控条件已满足,TPF请求OCS对用户进行重鉴权。
2.根据权利要求1所述的方法,其特征在于,所述步骤A之前进一步包括OCS根据用户帐户计算基于数据流量的信用额度,所述监控条件为时间限度。
3.根据权利要求2所述的方法,其特征在于,所述步骤B进一步包括TPF向OCS返回剩余的基于数据流量的信用额度,或剩余的时间长度,或以上二者的组合,请求OCS提供新的基于数据流量的信用额度。
4.根据权利要求1所述的方法,其特征在于,所述步骤A之前进一步包括OCS根据用户帐户计算基于时间长度的信用额度,所述监控条件为数据流量限度。
5.根据权利要求4所述的方法,其特征在于,所述步骤B进一步包括TPF向OCS返回剩余的基于时间长度的信用额度,或剩余的数据流量,或以上二者的组合,请求OCS提供新的基于时间长度的信用额度。
6.根据权利要求1、2或4所述的方法,其特征在于,所述步骤A之前进一步包括A0、CRF向TPF提供数据流量限度和时间限度,TPF向OCS提供数据流量限度和时间限度。
7.根据权利要求6所述的方法,其特征在于,所述步骤A0进一步包括CRF向TPF提供基于数据流量和时间长度进行组合计费的计费模式指示,TPF向OCS提供基于数据流量和时间长度进行组合计费的计费模式指示。
8.根据权利要求1所述的方法,其特征在于,步骤A中所述信用额度为用户帐户下所有信用额度的其中一部分。
9.根据权利要求1、2、3、4、5或8所述的方法,其特征在于,所述步骤B之后进一步包括C、OCS向TPF提供信用额度和监控条件,然后返回执行步骤B。
10.根据权利要求9所述的方法,其特征在于,所述步骤C之前进一步包括OCS根据剩余的基于数据流量的信用额度,或剩余的时间长度,或以上二者的组合,计算基于数据流量的新的信用额度;或,OCS根据剩余的基于时间长度的信用额度,或剩余的数据流量,或以上二者的组合,计算基于时间长度的新的信用额度。
11.根据权利要求3所述的方法,其特征在于,所述步骤B之后进一步包括OCS确定触发当前信用请求的原因,如果所述原因为时间限度定时器期满,则OCS判断用户使用的数据流量是否低于系统设置的数据流量最小值,如果是,则OCS终止当前与TPF之间的对话;否则,OCS向TPF提供时间限度和计算的新的基于数据流量的信用额度,然后返回执行步骤B。
12.根据权利要求11所述的方法,其特征在于,所述OCS终止当前与TPF之间的对话为OCS向TPF发送终止操作指示,TPF释放与当前OCS和TPF之间对话相对应的业务的数据流的会话。
全文摘要
本发明公开了一种在线计费的处理方法,涉及分组数据计费领域,该方法包含OCS向TPF提供信用额度和监控条件,TPF监测到信用额度已消耗完毕或监控条件已满足,TPF请求OCS对用户进行重鉴权,如果信用额度为基于数据流量的信用额度,则监控条件为时间限度,如果信用额度为基于时间长度的信用额度,则监控条件为数据流量限度。根据本发明提出的方法,通过TPF与OCS的交互,使得OCS能够获知向TPF下发的信用额度使用完毕时剩余的监控条件信息,或是监控条件满足时剩余的信用额度信息,从而可实现基于数据流量和时间长度的组合计费,也可使OCS能够对一定时间长度内用户使用网络资源的情况进行监控。
文档编号H04L12/14GK1773920SQ200410090738
公开日2006年5月17日 申请日期2004年11月8日 优先权日2004年11月8日
发明者段小琴 申请人:华为技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1