CN100341278C - 一种基于分组数据流计费的系统及处理方法 - Google Patents
一种基于分组数据流计费的系统及处理方法 Download PDFInfo
- Publication number
- CN100341278C CN100341278C CNB2004100985442A CN200410098544A CN100341278C CN 100341278 C CN100341278 C CN 100341278C CN B2004100985442 A CNB2004100985442 A CN B2004100985442A CN 200410098544 A CN200410098544 A CN 200410098544A CN 100341278 C CN100341278 C CN 100341278C
- Authority
- CN
- China
- Prior art keywords
- crf
- charging
- ccf
- tpf
- credit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 10
- 238000000034 method Methods 0.000 claims abstract description 76
- 230000004044 response Effects 0.000 claims description 70
- 230000005540 biological transmission Effects 0.000 claims description 21
- 230000008569 process Effects 0.000 abstract description 50
- 230000007246 mechanism Effects 0.000 abstract description 9
- 238000012545 processing Methods 0.000 abstract description 9
- 238000013475 authorization Methods 0.000 abstract description 3
- 230000002452 interceptive effect Effects 0.000 abstract 4
- 230000004048 modification Effects 0.000 description 38
- 238000012986 modification Methods 0.000 description 38
- 230000000875 corresponding effect Effects 0.000 description 26
- 230000008859 change Effects 0.000 description 19
- 230000004913 activation Effects 0.000 description 7
- 238000012217 deletion Methods 0.000 description 7
- 230000037430 deletion Effects 0.000 description 7
- 238000012546 transfer Methods 0.000 description 7
- 230000000977 initiatory effect Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 241000282836 Camelus dromedarius Species 0.000 description 2
- 238000007689 inspection Methods 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 235000007926 Craterellus fallax Nutrition 0.000 description 1
- 240000007175 Datura inoxia Species 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 238000005728 strengthening Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Meter Arrangements (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种基于分组数据流计费的系统及处理方法，在OCS中实现CRF功能，这样，触发事件可同重鉴权事件合并实现，统一了TPF的事件上报机制，并且本发明还描述了基于实现CRF功能的OCS结构下的各种流程，包括TPF与CRF-CCF之间交互计费规则及用户信用的流程，CRF-CCF与TPF之间基于计费触发事件的交互流程，CRF-CCF与AF之间交互相关信息的流程，以及CRF-CCF与TPF交互用户信用使用情况的流程，使得TPF与OCS之间以及TPF与CRF之间的处理流程更为清晰。
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和计费采集功能实体(CDF，Charging data 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 205监测到触发事件发生后向CRF 203上报，CRF 203通过TPF 205上报的触发事件获知承载发生变化，然后确定相应的计费规则并下发给TPF 205。3GPP规范中定义的触发事件可包括：公用陆地移动通信网络(PLMN)变化(PLMN change)事件，QoS参数变化(QoS changes)事件，无线接入技术(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 202两个功能实体组成，其中，CCF 202是执行信用控制的功能实体，仅应用于在线计费系统，可通过在现有的OCS 206中增加新的功能来实现。在在线计费过程中，CCF 202对用户信用进行管理和控制，当用户使用业务时，CCF 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 206通过重鉴权事件上报的机制，控制TPF205的信用使用情况进行了描述，即TPF 205监测到重鉴权事件发生后向OCS 206上报，OCS 206通过TPF 205上报的重鉴权事件，获知用户的信用使用情况以及承载的变化，对用户的信用重新进行计算并下发给TPF 205。3GPP规范中定义的重鉴权事件可包括：允许信用过期(credit authorizationlifetime expiry)事件，用户空闲状态超时(idle timeout)事件，计费规则变化(charging rule is changed)事件，PLMN变化事件，QoS参数变化事件，RAT类型变化事件。
对应于GPRS网络，TPF 205为GGSN，AF为PDN中的一个业务网关或业务服务器，CRF 203为新增的逻辑实体。TPF 205为计费规则的执行点，CRF 203为计费规则的控制点。
目前，3GPP定义了承载建立时，在线计费情况下，请求计费规则和用户信用的处理过程如图3A所示：
步骤301A：用户设备(UE)向TPF发送承载建立请求(Establish BearerService Request)，在GPRS网络中，则是GGSN收到Create PDP ContextRequest。
步骤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收到信用请求后，确定用户的信用，然后向TPF返回信用响应(Credit Response)，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用，如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值。
步骤308A：TPF收到信用响应后，向UE返回承载建立响应(EstablishBearer Service Accept)，如果信用响应中携带有用户的信用，则TPF接受UE发起的承载建立请求，并继续后续的承载建立流程；如果信用响应中未携带有用户的信用，则拒绝UE发起的承载建立请求。
对于承载修改，在线计费情况下，请求计费规则和用户信用的处理过程如图3B所示：
步骤301B：UE向TPF发送承载修改请求(Modify Bearer ServiceRequest)，在GPRS网络中，则是GGSN收到PDP Context更新请求(UpdatePDP C ontext Request)。
步骤302B：TPF收到承载修改请求后，向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。
步骤303B～步骤304B：CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则和触发事件信息。
步骤305B：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作，即建立、修改、删除计费规则。
步骤306B～步骤307B：TPF根据计费规则中的在线计费指示，向OCS发送信用请求，请求用户的信用。OCS收到信用请求后，确定用户的信用，然后向TPF返回信用响应，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用，如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值。
步骤308B：TPF收到信用响应后，向UE返回承载修改响应(ModifyBearer Service Accept)，如果信用响应中携带有用户的信用，则TPF接受UE发起的承载修改请求，并继续后续的承载修改流程；如果信用响应中未携带有用户的信用，则拒绝UE发起的承载修改请求。
对于承载删除，在线计费情况下，请求计费规则和用户信用的处理过程如图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发起的承载删除请求，并继续后续的承载删除流程。
目前，3GPP定义了离线计费情况下，承载修改会触发TPF向CRF请求计费规则的处理过程，具体实现过程如图4A所示：
步骤401A：UE向TPF发送承载修改请求，在GPRS网络中，则是GGSN收到PDP Context更新请求。
步骤402A：TPF收到承载修改请求后，将承载修改事件与存储的触发事件相匹配，如果能够匹配，则执行步骤403A；否则，继续监测触发事件的发生。
步骤403A：TPF向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。
步骤404A～步骤405A：CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则和触发事件信息。
步骤406A：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作，即建立、修改、删除计费规则。
步骤407A：TPF向UE返回承载修改响应，并继续后续的承载修改流程。
在线计费情况下，承载修改会触发TPF请求OCS对用户进行重鉴权的流程，具体实现过程如图4B所示：
步骤401B～步骤406B与步骤401A～步骤406A相同。
步骤407B：TPF将承载修改事件与存储的重鉴权事件进行匹配，如果能够匹配，则执行步骤408B，否则，继续监测重鉴权事件的发生。
步骤408B：如果重鉴权事件发生了，或是计费规则发生了改变，TPF向OCS发送信用及重鉴权请求(Credit Request and Re-authorisationRequest)，该信用及重鉴权请求中携带有用户的剩余信用和相关的计费规则信息，还可携带相应的重鉴权事件，请求OCS重新计算用户的信用。TPF向OCS提供的相关计费规则信息可来自CRF。
步骤409B：OCS收到信用控制请求后，重新对用户的信用进行计算，然后向TPF返回信用及重鉴权响应(Credit Response and Re-authorizationResponse)，如果OCS计算出用户的信用，则该信用及重鉴权响应中携带有OCS重新计算的用户信用，如果OCS未计算出用户的信用，则该信用控制响应中可携带有差错原因值。
步骤410B：TPF收到信用控制响应后，向UE返回承载修改响应，如果信用控制响应中携带有用户的信用，则TPF接受UE发起的承载修改请求，并继续后续的承载修改流程；如果信用控制响应中未携带有用户的信用，则拒绝UE发起的承载修改请求。
另外，CRF也可主动向TPF发送计费规则，如当UE与AF进行业务数据传输的过程中，CRF收到AF的计费规则输入信息后，根据AF提供的计费规则输入信息选择适当的计费规则，然后主动向TPF下发选定的计费规则。对于AF向CRF提供计费规则输入信息的具体实现过程如图5所示：
步骤501：AF向CRF发送应用/业务计费相关信息(SendApplication/Service Data Flow Charging Information)。
步骤502：CRF收到应用/业务计费相关信息后，向AF返回响应(Ack)，通知AF已收到其发送的计费规则输入信息。
图6示出了CRF主动向TPF下发计费规则流程图，如图6所示，CRF主动向TPF下发计费规则的实现过程包括以下步骤：
步骤601：CRF收到某个内部或外部的触发事件(Internal or ExternalTrigger Event)，以及与该事件相关的信息，如AF向CRF发送计费规则输入信息的事件。
步骤602：CRF根据获取的信息选择相应的计费规则。这些信息可为AF提供的计费规则输入信息，例如，用户使用AF提供的某一业务，该业务对计费有特殊要求，如费率与其他业务的费率不同，因此，AF向CRF提供与该业务相关的计费信息；也可为TPF提供的计费规则输入信息。
步骤603：如果需要的话，CRF向TPF发送提供计费规则，该提供计费规则中可携带有选定的计费规则和触发事件信息。
步骤604：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作，即建立、修改、删除计费规则。
步骤605～步骤606：TPF向OCS发送信用请求，请求用户的信用。OCS收到信用请求后，确定用户的信用，然后向TPF返回信用响应，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用，如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值。
目前，规范中对CRF通过触发事件上报机制控制TPF的计费方式进行了定义，即TPF监测到触发事件发生后向CRF上报，CRF通过TPF上报的触发事件获知承载发生变化，然后确定相应的计费规则并下发给TPF。规范中定义的触发事件可包括：PLMN变化(PLMN change)事件，QoS参数变化(QoS changes)事件，无线接入技术(RAT)类型变化(RAT type change)事件，传输流模板(TFT)变化(TFT change)事件。
另外，规范中还对OCS通过重鉴权事件上报的机制控制TPF的信用使用情况进行了描述，即TPF监测到重鉴权事件发生后向OCS上报，OCS通过TPF上报的重鉴权事件，获知用户的信用使用情况以及承载的变化，对用户的信用重新进行计算并下发给TPF。规范中定义的重鉴权事件可包括：允许信用过期(credit authorization lifetime expiry)事件，用户空闲状态超时(idle timeout)事件，计费规则变化(charging rule is changed)事件，PLMN变化事件，QoS参数变化事件，RAT类型变化事件。
通过以上描述可见，触发事件和重鉴权事件中都包括SGSN变化事件、QoS参数变化事件、RAT类型变化事件等，这样，对于某个发生的GPRS事件，TPF会将该GPRS事件同时匹配到触发事件和重鉴权事件，因此，需要分别向CRF和OCS上报该GPRS事件的发生，造成对FBC系统资源的浪费。
发明内容
有鉴于此，本发明的一个目的在于提供一种基于分组数据流计费的系统，本发明的另一目的在于提供一种基于分组数据流计费的处理方法，完善基于分组数据流计费的系统结构和实现流程。
为了达到上述目的，本发明提供了一种基于分组数据流计费的系统，该系统包括：传输面功能实体TPF和计费规则功能实体-信用控制功能实体CRF-CCF，所述TPF用于承载数据业务流，所述CRF-CCF用于选择计费规则及进行信用控制；所述TPF与所述CRF-CCF相连，所述TPF与CRF-CCF分别通过所述连接向对方传送计费及信用控制信息。所述计费及信用控制信息为：TPF向CRF-CCF发送的计费规则和/或用户信用请求、以及CRF-CCF向TPF提供的计费规则和/或用户信用；所述CRF-CCF进一步用于向TPF提供计费触发事件，所述TPF用于在计费触发事件发生时向CRF-CCF上报。所述CRF-CCF进一步与用于提供业务使用信息的AF相连，用于传送确定计费规则的输入信息。
本发明还提供了一种基于分组数据流计费的处理方法，该方法包含：TPF向CRF-CCF发送计费规则及信用请求，CRF-CCF收到计费规则及信用请求后，向TPF返回计费规则和/或用户信用；或CRF-CCF向TPF提供计费触发事件，TPF监测到计费触发事件发生时，向CRF-CCF上报；或AF向CRF-CCF提供用于选择计费规则的输入信息；或CRF-CCF要求TPF返回用户信用的使用情况，TPF向CRF-CCF返回用户信用使用情况信息。
计费规则及信用请求中携带有用于选择计费规则的输入信息，或计费触发事件，或用户已经使用的信用，或用户的剩余信用，或以上任意的组合。
向TPF返回计费规则和/或用户信用进一步包括：提供计费触发事件。
较佳地，承载建立时，CRF-CCF收到计费规则及信用请求之后，进一步包括：CRF-CCF判断UE用户是否为签约的网络用户，如果是，则直接向TPF返回计费规则和/或用户信用；否则，向TPF提供UE归属的CRF-CCF的地址信息，TPF根据收到的CRF-CCF地址信息，向该CRF-CCF发送计费规则及信用请求，UE归属的CRF-CCF收到计费规则及信用请求后，向TPF返回计费规则和/或用户信用。
所述计费触发事件为：计费规则触发事件，或为重鉴权事件，或为以上二者的组合。
所述向CRF-CCF上报为：向CRF-CCF发送携带有计费触发事件的计费规则及信用请求。
所述计费触发事件包括计费规则触发事件和重鉴权事件，向CRF-CCF发送携带有计费触发事件的计费规则及信用请求之前，进一步包括：TPF判断发生的计费触发事件是否为重鉴权事件，如果是，则向CRF-CCF发送携带有重鉴权事件的计费规则及信用请求，该计费规则及信用请求中进一步携带有用户信用使用情况信息。
所述计费触发事件包括计费规则触发事件和重鉴权事件，所述计费规则及信用请求中进一步携带有用户信用使用情况信息，所述向CRF-CCF发送携带有计费触发事件的计费规则及信用请求之后，进一步包括：CRF-CCF收到计费规则及信用请求后，判断TPF上报的计费触发事件是否为重鉴权事件，如果是，则CRF-CCF选定计费规则并重新计算用户信用，然后将计费规则和用户信用提供给TPF；否则，CRF-CCF选定计费规则并提供给TPF。
较佳地，该方法进一步包括：CRF-CCF向AF返回表明收到所述输入信息的响应。
根据本发明提出的方案，在OCS中实现CRF功能，这样，触发事件可同重鉴权事件合并实现，统一了TPF的事件上报机制，并且本发明还描述了基于实现CRF功能的OCS结构下的各种流程，使得TPF与OCS之间以及TPF与CRF之间的处理流程更为清晰。
附图说明
图1示出了PDP Context激活、数据传输、去激活流程图；
图2A示出了在线计费的FBC系统结构示意图；
图2B示出了离线计费的FBC系统结构示意图；
图3A示出了在线计费承载建立时请求计费规则和用户信用的处理流程图；
图3B示出了在线计费承载修改时请求计费规则和用户信用的处理流程图；
图3C示出了在线计费承载删除时请求计费规则和用户信用的处理流程图；
图4A示出了现有技术中离线计费时承载修改处理流程图；
图4B示出了现有技术中在线计费时承载修改处理流程图；
图5示出了AF向CRF提供计费规则输入信息流程图；
图6示出了CRF主动向TPF下发计费规则流程图；
图7示出了本发明中FBC系统结构示意图；
图8A示出了本发明中承载建立时请求计费规则和用户信用的处理流程图；
图8B示出了本发明中承载修改时请求计费规则和用户信用的处理流程图；
图8C示出了本发明中承载删除时请求计费规则和用户信用的处理流程图；
图9示出了本发明中AF向CRF-CCF提供计费规则输入信息的处理流程图；
图10示出了本发明中AF向CRF-CCF提供输入信息触发计费规则和/或信用请求的处理流程图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。
本发明中，对FBC系统结构进行了改进，在OCS系统中增加CRF功能，这样，触发事件和重鉴权事件可合并实现，统一了TPF基于事件上报的机制，使得TPF与OCS及TPF与CRF之间的处理流程更为清晰。本发明提出的方案既适用于在线计费情况也适用于离线计费情况。
图7示出了本发明中FBC系统结构示意图，如图7所示，在本发明的FBC系统结构中，将CRF和CCF两个逻辑功能实体的功能集成在OCS 70中实现，这样，现有中连接CRF与CCF之间的Ry接口变为内部接口，以下将CRF和CCF集成后的逻辑功能实体称为CRF-CCF 701，SCP 201和CRF-CCF 701组成了本发明中的OCS 70，SCP 201与CRF-CCF 701之间的交互遵循CAMEL规范，SCP 201与CRF-CCF 701之间可传送在线计费控制信息。CRF-CCF 701可通过对现有的CCF进行增强，以使其能够实现CRF的功能。CRF-CCF 701通过Rx接口与AF 204互通，AF 204可通过Rx接口向CRF提供用于选择计费规则的输入信息。CRF-CCF 701通过Gy+Gx接口与TPF 205互通，该Gy+Gx接口上需要实现计费规则的请求和提供，用户信用的请求和提供，以及计费规则触发事件和重鉴权事件的提供和触发等功能。
由于在线计费时，计费规则触发事件和重鉴权事件都是由CRF-CCF 701请求TPF 205对指定事件进行监控的，因此，可将计费规则触发事件和重鉴权事件合并下发，即CRF-CCF 701向TPF 205提供计费规则触发事件和重鉴权事件的合集，以下将该计费规则触发事件和重鉴权事件的合集称为计费触发事件(Charging Trigger)。
TPF 205监测到计费触发事件发生后，通知CRF-CCF 701当前发生的计费触发事件，并向CRF-CCF 701提供用户已经使用的信用；CRF-CCF 701根据当前发生的计费触发事件，选择计费规则，并且重新对用户的信用进行计算，然后向TPF 205返回选定的计费规则和重新计算的用户信用。
CRF-CCF 701可进一步向TPF 205指明计费触发事件中包括的重鉴权事件，这样，TPF 205监测到计费触发事件发生后，判断发生的计费触发事件是否为重鉴权事件。如果TPF 205确定发生的计费触发事件为重鉴权事件，则TPF 205通知CRF-CCF 701当前发生的计费触发事件，并向CRF-CCF701提供用户已经使用的信用，请求CRF-CCF 701对用户进行重鉴权；CRF-CCF 701根据当前发生的计费触发事件，选择计费规则，并且重新对用户的信用进行计算，然后向TPF 205返回选定的计费规则和重新计算的用户信用。如果TPF 205确定发生的计费触发事件不是重鉴权事件，则TPF 205仅通知CRF-CCF 701当前发生的计费触发事件；CRF-CCF 701根据当前发生的计费触发事件，选择计费规则，然后向TPF 205返回选定的计费规则。
另外，CRF-CCF 701可不向TPF 205指明计费触发事件中包括的重鉴权事件，这样，TPF 205监测到计费触发事件发生后，通知CRF-CCF 701当前发生的计费触发事件，并向CRF-CCF 701提供用户已经使用的信用，CRF-CCF 701判断当前发生的计费触发事件是否为重鉴权事件，如果是，则CRF-CCF 701根据当前发生的计费触发事件，选择计费规则，并且重新对用户的信用进行计算，然后向TPF 205返回选定的计费规则和重新计算的用户信用；否则，CRF-CCF 701仅根据当前发生的计费触发事件，选择计费规则，然后向TPF 205返回选定的计费规则。
具体实现过程中，可在同一消息中实现计费规则请求和信用请求，例如，TPF 205向CRF-CCF 701发送计费规则及信用请求(Charging Rule and CreditRequest)，该计费规则及信用请求中可携带供CRF-CCF 701选择计费规则的输入信息，以及供CRF-CCF 701确定用户信用的输入信息，如，用户和终端的相关信息，如MSISDN、IMSI等，承载特性，如QoS信息，网络相关信息，如MNC、MCC等。
对于CRF-CCF 701向TPF 205提供的计费规则、提供的信用、以及提供的计费触发事件也可在同一消息中实现，如CRF-CCF 701向TPF 205发送计费规则及信用响应(Charging Rule and Credit Response)，该计费规则及信用响应中携带有CRF-CCF 701选定的计费规则、用户信用，该计费规则及信用响应中还可携带计费触发事件。
图8A示出了本发明中承载建立时请求计费规则和用户信用的处理流程图，如图8A所示，承载建立时请求计费规则和用户信用的处理过程包括以下步骤：
步骤801A与步骤301A相同。
步骤802A～步骤803A：TPF收到承载建立请求后，向CRF-CCF发送计费规则及信用请求，该计费规则及信用请求中携带有供CRF-CCF确定计费规则的输入信息和确定用户信用的输入信息，TPF可根据UE标识寻址到相应CRF-CCF，也可根据自身配置的数据寻址到相应CRF-CCF，还可根据承载建立时UE提供的接入访问点寻址到相应CRF-CCF。CRF-CCF收到计费规则请求后，判断该UE用户是否为签约的网络用户，如果是，即该CRF-CCF为UE的归属CRF-CCF，则执行步骤806A；否则，CRF-CCF可根据UE标识获取UE归属CRF-CCF的地址信息，然后执行804A。
步骤804A～步骤805A：CRF-CCF向TPF返回计费规则及信用响应，该计费规则及信用响应中携带有UE归属的CRF-CCF的地址信息。TPF收到计费规则及信用响应后，根据收到的CRF-CCF地址信息向该CRF-CCF发送计费规则及信用请求，该计费规则及信用请求中携带有供CRF-CCF确定计费规则和用户信用的输入信息。
步骤806A～步骤807A：CRF-CCF收到计费规则及信用请求后，根据该计费规则及信用请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，另外，CRF-CCF可进一步判断当前计费方式是否应为在线计费，如判断UE用户是否为预付费用户，或是判断UE用户是否使用预付费业务。如果CRF-CCF判断出当前计费方式应为在线计费，则CRF-CCF根据选定的计费规则计算用户信用，并向TPF返回计费规则及信用响应，该计费规则及信用响应中携带有计费规则操作指示、选定的计费规则和计算的用户信用，如果CRF-CCF未计算出用户的信用，则该计费规则及信用响应中可携带有差错原因值。计费规则及信用响应中可进一步携带有计费触发事件，并可进一步指明TPF计费触发事件中所包括的重鉴权事件。如果CRF-CCF判断出当前计费方式不应为在线计费，则CRF-CCF向TPF提供的计费规则及信用响应中不携带有计算的用户信用和重鉴权事件信息。
步骤808A：TPF收到计费规则及信用响应后，根据计费规则操作指示对CRF选定的计费规则进行相应操作，即建立计费规则；并对计费规则及信用请求中携带的计费触发事件进行存储。
步骤809A：TPF向UE返回承载建立响应，如果为在线计费，并且计费规则及信用请求中携带有用户的信用，则TPF接受UE发起的承载建立请求，并继续后续的承载建立流程；如果计费规则及信用请求中没有携带有用户的信用，则TPF拒绝UE发起的承载建立请求。如果为离线计费，则TPF直接接受UE发起的承载建立请求，并继续后续的承载建立流程。
由于在承载建立过程，TPF已经获取到UE归属的CRF-CCF的地址信息，因此，在后续进行计费规则及信用请求的过程中均与UE归属的CRF-CCF进行交互，这样，后续描述中涉及的CRF-CCF均为UE归属的CRF-CCF。
图8B示出了本发明中承载修改时请求计费规则和用户信用的处理流程图，如图8B所示，承载修改时请求计费规则和用户信用的处理过程包括以下步骤：
步骤801B与步骤301B相同。
步骤802B：承载修改可能会触发计费触发事件，因此，TPF收到承载修改请求后，将承载修改事件与存储的计费触发事件进行匹配，如果能够匹配，则执行步骤803B；否则，结束当前流程。
步骤803B：TPF向CRF-CCF发送计费规则及信用请求，该计费规则及信用请求中携带有供CRF-CCF确定计费规则和用户信用的输入信息，该计费规则及信用请求中可进一步携带有当前发生的计费触发事件，并可进一步向TPF指明计费触发事件中包括的重鉴权事件。
步骤804B～步骤806B与步骤806A～步骤808A相同。
步骤807B：TPF向UE返回承载修改响应，对于在线计费，如果计费规则及信用请求中携带有用户的信用，则TPF接受UE发起的承载修改请求，并继续后续的承载修改流程，如果计费规则及信用请求中携带有差错原因值，则TPF拒绝UE发起的承载修改请求；对于离线计费，TPF接受UE发起的承载修改请求，并继续后续的承载修改流程。
如果CRF-CCF向TPF指明了计费触发事件中包括的重鉴权事件，则TPF监测到计费触发事件发生后，判断发生的计费触发事件是否为重鉴权事件，如果是，则TPF向CRF-CCF发送的计费规则及信用请求中携带有CRF-CCF确定用户信用的输入信息，如用户的剩余信用，否则，TPF向CRF-CCF发送的计费规则及信用请求中不携带CRF-CCF确定用户信用的输入信息；CRF-CCF根据计费规则及信用请求中是否携带有确定用户信用的输入信息，确定是否计算用户信用。
如果CRF-CCF未向TPF指明计费触发事件中包括的重鉴权事件，并且由CRF-CCF收到TPF上报的当前发生的计费触发事件后，由CRF-CCF判断当前发生的计费触发事件是否为重鉴权事件时，此时TPF监测到计费触发事件发生后，向CRF-CCF发送的计费规则及信用请求中携带有CRF-CCF确定用户信用的输入信息，如用户的剩余信用。由CRF-CCF根据计费触发事件的判断结果确定是否计算用户信用，如果当前发生的计费触发事件为重鉴权事件，则CRF-CCF计算用户信用并提供给TPF；如果当前发生的计费触发事件不是重鉴权事件，则CRF-CCF不重新计算用户信用，向TPF返回的计费规则及信用响应中直接携带原来的信用。
图8C示出了本发明中承载删除时请求计费规则和用户信用的处理流程图，如图8C所示，承载删除时请求计费规则和用户信用的处理过程包括以下步骤：
步骤801C与步骤301C相同。
步骤802C～步骤804C：TPF收到承载删除请求后，向CRF-CCF发送计费规则及信用请求，该计费规则及信用请求中携带有供CRF-CCF确定计费规则和用户的剩余信用。CRF-CCF收到计费规则及信用请求后，根据该计费规则及信用请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，并对用户的剩余信用进行处理，然后向TPF返回计费规则及信用响应，该计费规则及信用响应中携带有选定的计费规则。
步骤805C～步骤806C：TPF收到计费规则及信用响应后，根据计费规则操作指示对CRF选定的计费规则进行相应操作，即删除计费规则，然后向UE返回承载删除响应，接受UE发起的承载删除请求，并继续后续的承载删除流程。
另外，CRF-CCF也可主动向TPF发送计费规则，如当UE与AF进行业务数据传输的过程中，CRF-CCF收到AF的计费规则输入信息后，根据AF提供的计费规则输入信息选择适当的计费规则，然后主动向TPF下发选定的计费规则。对于AF向CRF-CCF提供计费规则输入信息的具体实现过程如图9所示：
步骤901～步骤902：AF向CRF-CCF发送应用/业务计费相关信息。CRF-CCF收到应用/业务计费相关信息后，向AF返回响应，通知AF已收到其发送的计费规则输入信息。
AF可根据UE标识寻址到相应CRF-CCF，也可根据自身配置的数据寻址到相应CRF-CCF，还可根据获取的CRF-CCF地址信息寻址到相应CRF-CCF。
另外，AF向CRF-CCF提供输入信息后，CRF-CCF会根据AF的输入信息判断是否需要触发重鉴权流程，如果是，如CRF-CCF根据AF提供的输入信息选择适当的计费规则后，发现计费规则中的计费键指示的费率发生了变化，需要应用新的费率对用户信用进行计算，此时，需要对用户进行重鉴权，则CRF-CCF向TPF发送重鉴权指示，要求TPF提供确定用户信用的输入信息，如用户的剩余信用，否则，即不需要触发重鉴权流程，直接向TPF提供根据来自AF的输入信息选定的计费规则，具体实现过程如图10所示：
步骤A1～步骤A2：AF向CRF-CCF发送AF输入信息(AF Input)，CRF-CCF收到AF输入信息后，向AF返回AF输入信息响应(AF Input Ack)，通知已收到其发送的输入信息。
步骤A3：CRF-CCF根据收到的AF输入信息，判断是否需要进行重鉴权流程，如果是，则执行步骤A4a；否则，执行步骤A4b。
步骤A4a：CRF-CCF可要求TPF向其返回用户的信用使用情况，以对用户信用进行有效控制，即CRF-CCF向TPF发送返回信用请求(ReturnCredit Request)，要求TPF向其提供用于确定用户信用的输入信息，如返回用户的信用使用情况，即剩余信用。
步骤A5a：TPF收到返回信用请求后，向CRF-CCF发送计费规则及信用请求，该计费规则及信用请求中携带有供CRF-CCF确定计费规则和用户信用的输入信息，如用户的剩余信用。
步骤A6a～步骤A8a与步骤806A～步骤808A相同。
步骤A4b～步骤A6b：CRF根据AF输入信息，也可根据来自TPF的输入信息，选择适当的计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则和计费规则操作指示。TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作。
总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。
Claims (19)
1、一种基于分组数据流计费的系统，其特征在于，该系统包括：传输面功能实体TPF和计费规则功能实体-信用控制功能实体CRF-CCF，所述TPF用于承载数据业务流，所述CRF-CCF用于选择计费规则及进行信用控制；
所述TPF与所述CRF-CCF相连，所述TPF与CRF-CCF分别通过所述连接向对方传送计费及信用控制信息。
2、根据权利要求1所述的系统，其特征在于，所述计费及信用控制信息为：TPF向CRF-CCF发送的计费规则和/或用户信用请求、以及CRF-CCF向TPF提供的计费规则和/或用户信用。
3、根据权利要求1或2所述的系统，其特征在于，所述CRF-CCF进一步用于向TPF提供计费触发事件，所述TPF用于在计费触发事件发生时向CRF-CCF上报。
4、根据权利要求3所述的系统，其特征在于，所述计费触发事件为计费规则触发事件，或为重鉴权事件，或为以上二者的组合。
5、根据权利要求1所述的系统，其特征在于，所述相连为通过Gy+Gx接口相连。
6、根据权利要求1所述的系统，其特征在于，所述CRF-CCF进一步与用于提供业务使用信息的AF相连，用于传送确定计费规则的输入信息。
7、根据权利要求6所述的系统，其特征在于，所述CRF-CCF与AF相连为通过Rx接口相连。
8、一种基于分组数据流计费的处理方法，其特征在于，该方法包含：TPF向CRF-CCF发送计费规则及信用请求，CRF-CCF收到计费规则及信用请求后，向TPF返回计费规则和/或用户信用。
9、根据权利要求8所述的方法，其特征在于，所述计费规则及信用请求中携带有用于选择计费规则的输入信息，或计费触发事件，或用户已经使用的信用，或用户的剩余信用，或以上任意的组合。
10、根据权利要求8所述的方法，其特征在于，所述向TPF返回计费规则和/或用户信用进一步包括：提供计费触发事件。
11、根据权利要求8所述的方法，其特征在于，承载建立时，CRF-CCF收到计费规则及信用请求之后，进一步包括：CRF-CCF判断UE用户是否为签约的网络用户，如果是，则直接向TPF返回计费规则和/或用户信用；否则，向TPF提供UE归属的CRF-CCF的地址信息，TPF根据收到的CRF-CCF地址信息，向该CRF-CCF发送计费规则及信用请求，UE归属的CRF-CCF收到计费规则及信用请求后，向TPF返回计费规则和/或用户信用。
12、一种基于分组数据流计费的处理方法，其特征在于，该方法包含：CRF-CCF向TPF提供计费触发事件，TPF监测到计费触发事件发生时，向CRF-CCF上报。
13、根据权利要求12所述的方法，其特征在于，所述计费触发事件为：计费规则触发事件，或为重鉴权事件，或为以上二者的组合。
14、根据权利要求12或13所述的方法，其特征在于，所述向CRF-CCF上报为：向CRF-CCF发送携带有计费触发事件的计费规则及信用请求。
15、根据权利要求14所述的方法，其特征在于，所述计费触发事件包括计费规则触发事件和重鉴权事件，向CRF-CCF发送携带有计费触发事件的计费规则及信用请求之前，进一步包括：TPF判断发生的计费触发事件是否为重鉴权事件，如果是，则向CRF-CCF发送携带有重鉴权事件的计费规则及信用请求，该计费规则及信用请求中进一步携带有用户信用使用情况信息。
16、根据权利要求14所述的方法，其特征在于，所述计费触发事件包括计费规则触发事件和重鉴权事件，
所述计费规则及信用请求中进一步携带有用户信用使用情况信息，
所述向CRF-CCF发送携带有计费触发事件的计费规则及信用请求之后，进一步包括：CRF-CCF收到计费规则及信用请求后，判断TPF上报的计费触发事件是否为重鉴权事件，如果是，则CRF-CCF选定计费规则并重新计算用户信用，然后将计费规则和用户信用提供给TPF；否则，CRF-CCF选定计费规则并提供给TPF。
17、一种基于分组数据流计费的处理方法，其特征在于，该方法包含：AF向CRF-CCF提供用于选择计费规则的输入信息。
18、根据权利要求17所述的方法，其特征在于，该方法进一步包括：CRF-CCF向AF返回表明收到所述输入信息的响应。
19、一种基于分组数据流计费的处理方法，其特征在于，该方法包含：CRF-CCF要求TPF返回用户信用的使用情况，TPF向CRF-CCF返回用户信用使用情况信息。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100985442A CN100341278C (zh) | 2004-12-09 | 2004-12-09 | 一种基于分组数据流计费的系统及处理方法 |
| PCT/CN2005/002139 WO2006060964A1 (fr) | 2004-12-09 | 2005-12-09 | Systeme et procede de traitement permettant une facturation en fonction du flux de paquets de donnees |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100985442A CN100341278C (zh) | 2004-12-09 | 2004-12-09 | 一种基于分组数据流计费的系统及处理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1787442A CN1787442A (zh) | 2006-06-14 |
| CN100341278C true CN100341278C (zh) | 2007-10-03 |
Family
ID=36577669
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2004100985442A Expired - Fee Related CN100341278C (zh) | 2004-12-09 | 2004-12-09 | 一种基于分组数据流计费的系统及处理方法 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN100341278C (zh) |
| WO (1) | WO2006060964A1 (zh) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101296169B (zh) * | 2007-04-26 | 2010-12-08 | 华为技术有限公司 | 一种用户会话承载业务建立方法、系统及设备 |
| CN102056117B (zh) * | 2009-11-03 | 2015-08-12 | 中兴通讯股份有限公司 | 基于策略和计费控制架构的计费方法与系统 |
| WO2012106881A1 (zh) * | 2011-07-12 | 2012-08-16 | 华为技术有限公司 | 一种计费方法、网络接入设备、核心网设备 |
| CN102647696A (zh) * | 2011-12-09 | 2012-08-22 | 中兴通讯股份有限公司 | 多媒体业务的计费方法及系统 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1350383A (zh) * | 2000-10-23 | 2002-05-22 | 日本电气株式会社 | 用于分组通信的计费系统 |
| JP2003134111A (ja) * | 2001-10-26 | 2003-05-09 | Nec Corp | ルールベースレイティングシステムおよび方法ならびにプログラム |
| US20030152039A1 (en) * | 2002-02-08 | 2003-08-14 | Timothy Roberts | Customer billing in a communications network |
| CN1444824A (zh) * | 2000-05-24 | 2003-09-24 | 诺基亚有限公司 | 用于通信网络的公共计费标识符 |
| CN1450749A (zh) * | 2002-04-10 | 2003-10-22 | 华为技术有限公司 | 一种分组数据业务的计费方法 |
| CN1474535A (zh) * | 2002-08-08 | 2004-02-11 | 深圳市中兴通讯股份有限公司 | 基于无线局域网与码分多址系统相结合的鉴权计费方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030153333A1 (en) * | 2001-05-14 | 2003-08-14 | Ryo Shirai | Obile communication service charging apparatus and mobile communication service charging method |
-
2004
- 2004-12-09 CN CNB2004100985442A patent/CN100341278C/zh not_active Expired - Fee Related
-
2005
- 2005-12-09 WO PCT/CN2005/002139 patent/WO2006060964A1/zh active Application Filing
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1444824A (zh) * | 2000-05-24 | 2003-09-24 | 诺基亚有限公司 | 用于通信网络的公共计费标识符 |
| CN1350383A (zh) * | 2000-10-23 | 2002-05-22 | 日本电气株式会社 | 用于分组通信的计费系统 |
| JP2003134111A (ja) * | 2001-10-26 | 2003-05-09 | Nec Corp | ルールベースレイティングシステムおよび方法ならびにプログラム |
| US20030152039A1 (en) * | 2002-02-08 | 2003-08-14 | Timothy Roberts | Customer billing in a communications network |
| CN1450749A (zh) * | 2002-04-10 | 2003-10-22 | 华为技术有限公司 | 一种分组数据业务的计费方法 |
| CN1474535A (zh) * | 2002-08-08 | 2004-02-11 | 深圳市中兴通讯股份有限公司 | 基于无线局域网与码分多址系统相结合的鉴权计费方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1787442A (zh) | 2006-06-14 |
| WO2006060964A1 (fr) | 2006-06-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1303781C (zh) | 一种分组数据业务的计费控制方法 | |
| CN1302636C (zh) | 一种完善基于业务数据流在线计费的处理方法 | |
| CN1735017A (zh) | 一种基于分组数据流计费的对话建立方法 | |
| CN1691821A (zh) | 一种实现漫游计费的方法及系统 | |
| CN1209938C (zh) | 用于附加用户设备至电信网络的方法与系统 | |
| CN101047988A (zh) | 一种用户漫游状态下的策略及计费控制方法 | |
| CN101047989A (zh) | 一种用户漫游状态下的策略及计费控制方法 | |
| CN101047949A (zh) | 业务数据流的承载控制方法 | |
| CN1968139A (zh) | 策略与计费控制中用户签约信息的处理方法及装置 | |
| CN1260910C (zh) | 基于分组数据流计费触发事件和重授权事件的处理方法 | |
| CN101060367A (zh) | 用于匹配核心网络承载的资源量和受访问网络承载的资源量的移动通信系统 | |
| CN1744559A (zh) | 一种通过业务属性或根据业务计费类型实现路由的方法 | |
| CN1773920A (zh) | 一种在线计费的处理方法 | |
| CN1968503A (zh) | 移动通信系统中获取承载信息的方法及应用 | |
| CN1275422C (zh) | 一种分组数据业务中增强计费规则及进行操作的方法 | |
| CN1277371C (zh) | 一种基于分组数据流计费重鉴权的处理方法 | |
| CN1297174C (zh) | 用户终端之间通过公众陆地移动通信网分组域通信的方法 | |
| CN100341278C (zh) | 一种基于分组数据流计费的系统及处理方法 | |
| CN1773922A (zh) | 一种基于分组数据流计费的处理方法及系统 | |
| CN101064635A (zh) | 一种服务质量协商方法 | |
| CN1808982A (zh) | 一种基于分组数据流计费中的处理方法 | |
| CN1684420A (zh) | 一种实现分组数据业务计费及控制业务接入的方法 | |
| CN1286292C (zh) | 基于通用分组无线业务流量的计费方法 | |
| CN1735024A (zh) | 一种基于业务数据流计费的计费信息处理方法 | |
| CN1735023A (zh) | 一种进行重鉴权及重鉴权事件和触发事件的处理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| ASS | Succession or assignment of patent right |
Owner name: HUAWEI DIGIT TECHNOLOGY CO., LTD. Free format text: FORMER OWNER: HUAWEI TECHNOLOGY CO LTD Effective date: 20100908 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 518129 BANTIAN HEADQUARTER BUILDING OF HUAWEI, LONGGANG DISTRICT, SHENZHEN CITY, GUANGDONG PROVINCE TO: 100085 NO.3, XINXI ROAD, SHANGDI, HAIDIAN DISTRICT, BEIJING |
|
| TR01 | Transfer of patent right |
Effective date of registration: 20100908 Address after: 100085 Beijing, Haidian District on the road, No. 3 Patentee after: Huawei Digit Technology Co., Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: Huawei Technologies Co., Ltd. |
|
| CP01 | Change in the name or title of a patent holder |
Address after: 100085 Beijing, Haidian District on the road, No. 3 Patentee after: Beijing Huawei Digital Technology Co.,Ltd. Address before: 100085 Beijing, Haidian District on the road, No. 3 Patentee before: Huawei Digit Technology Co., Ltd. |
|
| CP01 | Change in the name or title of a patent holder | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20071003 Termination date: 20191209 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |