专利名称：一种分组数据业务的计费控制方法
技术领域：
本发明涉及计费领域，特别是指一种分组数据业务的计费控制方法。
背景技术：
随着分组数据业务应用的逐渐广泛，如何准确合理地对分组数据业务进行计费，已成为运营商普遍关注的问题。
图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。
步骤102SGSN收到Activate PDP Context Request后，与UE进行安全性检查和加密，该步骤为可选步骤。
步骤103SGSN根据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激活请求。
步骤104GGSN收到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激活请求。
步骤105SGSN收到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建立了传输通道，可以进行数据传输了。
步骤106UE通过SGSN、GGSN与PDN进行数据传输。
步骤107数据传输完毕，UE向SGSN发送PDP Context去激活请求(Deactivate PDP Context Request)，该Deactivate PDP Context Request中携带有TI。
步骤108SGSN收到Deactivate PDP Context Request后，与UE进行安全性检查和加密，该步骤为可选步骤。
步骤109～步骤111SGSN向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 Contcxt中包含多个筛子孔，因此，基于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。CCF202通过Ry接口与基于业务数据流计费的计费规则功能实体(CRF，Service Data Flow Based Charging Rule Function)203相连，CRF203通过Rx接口与应用功能实体(AF，Application Function)204相连，CRF203通过Gx接口与传输面功能实体(TPF，Traffic Plane Function)205相连，CCF202通过Gy接口与TPF205相连。
支持离线计费的FBC系统结构如图2B所示，CRF203通过Rx接口与AF204相连，CRF203通过Gx接口与TPF205相连，TPF205通过Gz接口分别与计费网关功能实体(CGF，Charging Gateway Function)207和计费采集功能实体(CCF，Charging Collection Function)208相连。
根据目前3GPP对于实现FBC功能实体的划分，TPF205承载IP数据流，当IP数据流的承载建立时，TPF205通过Gx接口向CRF203发送计费规则请求，该计费规则请求中携带有与用户和UE相关的信息、承载特性以及与网络相关的信息等，其中与用户和UE相关的信息可为移动台国际号码(MSISDN)、国际移动用户标识(IMSI)等，与网络相关的信息可为移动网络编码(MNC)、移动国家码(MCC)等。另外，由于在IP数据流传输过程中，会对承载进行修改，如对QoS参数进行重新协商，当用户使用同一业务的QoS参数不同时，计费规则可能不同，如QoS参数下降相应的费率也下降。此时，TPF205可在承载修改时，重新向CRF203发送计费规则请求，请求新的计费规则；CRF203根据TPF205提供的上述输入信息选择适当的计费规则，并向TPF205返回选定的计费规则，计费规则中包括计费机制、计费类型、计费键、业务数据流过滤器、计费规则优先级等信息。其中，计费机制可为采用在线计费还是离线计费；计费类型可为基于时间长度进行计费还是基于数据流量进行计费；计费键是与计费费率相关的参数，CRF203可不直接向TPF205提供计费费率，而只是向TPF205提供与计费费率相关的参数；业务数据过滤器用于指示TPF205对哪些IP数据流进行过滤，然后TPF205根据计费规则对过滤出的IP数据流进行计费。业务数据过滤器可包含IP5元组，IP5元组可包括源/目的IP地址、源/目的端口号(Port Number)、协议标识(Protocol ID)等信息，例如，CRF203指示TPF205对源地址为10.0.0.1、目的地址为10.0.0.2、源/目的端口号为20、协议类型为传输控制协议(TCP)的IP数据流进行过滤，并根据计费规则对过滤出的IP数据流进行计费。最后，当承载删除时，TPF205也可向CRF203发送计费规则请求，要求CRF提供新的计费规则，此时CRF203可要求TPF205删除先前建立的计费规则。
另外，CRF203除了根据TPF205的输入信息确定计费规则之外，CRF203还可根据AF204或OCS206的输入信息确定计费规则，如AF204通知CRF203用户当前使用的业务类型，CRF203根据该业务类型选取相应的计费规则。
对应于GPRS网络，TPF205为GGSN，AF为PDN中的一个业务网关或业务服务器，CRF203为新增的逻辑实体。TPF205为计费规则的执行点，CRF203为计费规则的控制点。
图3A为承载建立时下发计费规则流程图，如图3A所示，承载建立时下发计费规则的实现过程包括以下步骤步骤301AUE向TPF发送承载建立请求(Establish Bearer ServiceRequest)，在GPRS网络中，则是GGSN收到Create PDP Context Request。
步骤302ATPF收到承载建立请求后，向CRF发送计费规则请求(Request Charging Rules)，该计费规则请求中携带有供CRF确定计费规则的输入信息。
步骤303A～步骤304ACRF收到计费规则请求后，根据该计费规则请求中携带的输入信息选取计费规则，然后向TPF返回提供计费规则(Provision Charging Rules)，该提供计费规则中可携带有选定的计费规则。
步骤305A～步骤306ATPF收到提供计费规则后，根据CRF选定的计费规则，建立新的计费规则，或是删除原有的计费规则，或是删除原有计费规则的同时建立新的计费规则，然后向UE返回承载建立响应(EstablishBearer Service Accept)，接受UE发起的承载建立请求，并继续后续的承载建立流程。
图3B为承载修改时下发计费规则流程图，如图3A所示，承载修改时下发计费规则的实现过程包括以下步骤步骤301BUE向TPF发送承载修改请求(Modify Bearer ServiceRequest)，在GPRS网络中，则是GGSN收到PDP Context更新请求(UpdatePDP Context Request)。
步骤302BTPF收到承载修改请求后，向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。
步骤303B～步骤304BCRF收到计费规则请求后，根据该计费规则请求中携带的输入信息选取计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则。
步骤305B～步骤306BTPF收到提供计费规则后，根据CRF选定的计费规则，建立新的计费规则，或是删除原有的计费规则，或是删除原有计费规则的同时建立新的计费规则，然后向UE返回承载修改响应(Modify BearerService Accept)，接受UE发起的承载修改请求，并继续后续的承载修改流程。
图3C为承载删除时下发计费规则流程图，如图3A所示，承载删除时下发计费规则的实现过程包括以下步骤步骤301CUE向TPF发送承载删除请求(Remove Bearer ServiceRequest)，在GPRS网络中，则是GGSN收到Delete PDP Context Request。
步骤302CTPF收到承载删除请求后，向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。
步骤303C～步骤304CCRF收到计费规则请求后，根据该计费规则请求中携带的输入信息选取计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则。
步骤305C～步骤306CTPF收到提供计费规则后，根据CRF选定的计费规则，建立新的计费规则，或是删除原有的计费规则，或是删除原有计费规则的同时建立新的计费规则，然后向UE返回承载删除响应(RemoveBearer Service Accept)，接受UE发起的承载删除请求，并继续后续的承载删除流程。
另外，对于CRF也可主动向TPF发送计费规则，如当UE与AF进行业务数据传输的过程中，CRF收到AF的计费相关输入信息后，根据AF提供的输入信息选择适当的计费规则，然后主动向TPF下发选定的计费规则。对于AF向CRF提供计费输入信息的具体实现过程如图4所示步骤401AF向CRF发送应用/业务计费相关信息(SendApplication/Service Data Flow Charging Information)。
步骤402CRF收到应用/业务计费相关信息后，向AF返回响应(Ack)，通知AF已收到其发送的计费相关输入信息。
图5为CRF主动向TPF下发计费规则流程图，如图5所示，CRF主动向TPF下发计费规则的实现过程包括以下步骤步骤501CRF收到某个内部或外部的触发事件(Internal or ExternalTrigger Event)，以及与该事件相关的信息，如AF向CRF发送计费规则选择输入信息的事件。
步骤502CRF根据获取的信息选择相应的计费规则。这些信息可为AF提供的计费相关输入信息，例如，用户使用AF提供的某一业务，该业务对计费有特殊要求，如计费费率与其他业务的计费费率不同，因此，AF向CRF提供与该业务相关的计费信息；也可为TPF提供的计费相关输入信息。
步骤503如果需要的话，CRF向TPF发送提供计费规则，该提供计费规则中可携带有选定的计费规则。
步骤504TPF收到提供计费规则后，根据CRF选定的计费规则，建立新的计费规则，或是删除原有的计费规则，或是删除原有计费规则的同时建立新的计费规则。
对于目前3GPP规范中定义的TPF与CRF关于计费规则的交互方式是在一定的触发事件发生时，如承载需要建立、修改或删除时，TPF向CRF发送计费规则请求，CRF根据计费规则请求中携带的信息选择适当的计费规则，并向TPF下发选定的计费规则。这样，请求计费规则的事件点是由TPF进行控制的，在TPF中预先配置请求计费规则的事件点，如设置请求计费规则的事件点为当承载建立、修改以及删除时，均需要TPF向CRF请求计费规则。但是，对于一些情况下，当承载修改时，如修改QoS参数时，修改后的QoS参数与原有的QoS参数相差不大，还没有达到需要修改计费规则的级别，如果此时TPF仍然向CRF请求计费规则，则CRF会选择一个原计费规则相同的计费规则下发给TPF，这样，必然导致TPF与CRF之间生成大量冗余信息。
由以上描述可见，在3GPP规范中，CRF虽然是计费规则的控制点，却并不能够实现对计费的完全控制。
发明内容
有鉴于此，本发明的目的在于提供一种分组数据业务的计费控制方法，使得对分组数据业务计费的控制更为合理完善。
为了达到上述目的，本发明提供了一种分组数据业务的计费控制方法，该方法包含
A、设置触发事件点；B、所述触发事件点发生时，TPF向CRF发送计费规则请求。
所述步骤A为CRF设置触发事件点，并向TPF发送所述触发事件点。
所述步骤A之前进一步包括A0、在TPF中配置静态触发事件点，所述静态触发事件点发生时，TPF向CRF发送计费规则请求。
所述静态触发事件点发生之前进一步包括TPF监测所述静态触发事件点的发生。
步骤A0中所述计费规则请求中携带有用于标明静态触发事件点的事件标识。
所述步骤A为CRF收到计费规则请求后，设置动态触发事件点，并向TPF发送所述动态触发事件点。
所述步骤A0之后进一步包括CRF向TPF提供计费规则。
所述步骤B之前进一步包括TPF存储所述触发事件点，并监测所述触发事件点的发生。
步骤B中所述计费规则请求中携带有用于标明触发事件点的事件标识。
所述步骤B之后进一步包括CRF向TPF提供计费规则。
CRF根据发生的触发事件点确定所述计费规则。
所述触发事件点为CRF根据自身存储信息进行设置。
所述触发事件点为CRF根据AF，或OCS，或TPF，或以上所述任意组合提供的计费相关输入信息设置。
本发明中，由CRF确定需要TPF向其请求计费规则的触发事件点，然后向TPF下发这些触发事件点，当触发事件点发生时，TPF向CRF请求计费规则并提供计费相关输入信息，CRF根据计费相关输入信息选择适当的计费规则，并向TPF下发选定的计费规则，这样，可实现CRF对TPF向其请求计费规则的时机进行控制，避免了由于TPF在不必要的时候向CRF请求计费规则而导致的冗余信息，使得TPF与CRF之间的信息交互更为有效，对于分组数据业务计费的控制更为合理完善。
另外，由于CRF能够获取AF或OCS提供的计费相关输入信息，这些计费相关输入信息可能对计费规则产生影响，根据本发明提出的方法，CRF可根据这些计费相关输入信息灵活设置触发事件点，然后向FPF下发当前设置的触发事件点，使得TPF能够在满足一定条件时，即触发事件点发生时，向CRF请求新的计费规则，这样，使得计费规则的应用更为灵活丰富，这些功能通过现有TPF与CRF的交互是根本无法实现的。
图1为PDP Context激活、传输数据、去激活流程图；图2A为在线计费的FBC系统结构示意图；图2B为离线计费的FBC系统结构示意图；图3A为承载建立时下发计费规则流程图；图3B为承载修改时下发计费规则流程图；图3C为承载删除时下发计费规则流程图；图4为AF向CRF提供计费输入信息流程图；图5为CRF主动向TPF下发计费规则流程图；图6为本发明中CRF控制TPF发送计费规则请求流程图；图7为本发明中实施例一示意图；图8为本发明中实施例二示意图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。
本发明中，由CRF确定需要TPF向其请求计费规则的触发事件点，然后向TPF下发这些触发事件点，当触发事件点发生时，TPF向CRF请求计费规则并提供计费相关输入信息，CRF根据计费相关输入信息选择适当的计费规则，并向TPF下发选定的计费规则。这样，CRF可根据计费规则、计费模式灵活设置触发事件点，实现CRF对计费的完全控制，使得TPF能够有效地向CRF请求计费规则，避免了TPF与CRF之间冗余信息的生成。
图6为本发明中CRF控制TPF发送计费规则请求流程图，如图6所示，CRF控制TPF发送计费规则请求的实现过程包括以下步骤步骤601在TPF中配置向CRF请求计费规则的静态触发事件点，如承载建立，当静态触发事件点发生时，TPF向CRF发送计费规则请求，该计费规则请求中携带有计费相关输入信息，如与用户和UE相关的信息、承载特性以及与网络相关的信息等；该计费规则请求中还可携带有事件标识，用于指示当前计费规则请求为静态触发事件点触发的。
另外，可在TPF中配置多个静态触发事件点，如承载建立、承载删除等，当其中一个静态触发事件点发生时，TPF向CRF请求计费规则。
步骤602CRF收到计费规则请求后，设置要求TPF请求计费规则的动态触发事件点，然后向TPF发送动态触发事件点上报请求，该动态触发事件点上报请求中携带有设置的动态触发事件点列表，动态触发事件点A、动态触发事件点B、动态触发事件点C等等，可为承载修改、划分的QoS参数修改的不同级别段、承载删除等动态触发事件点。
步骤603CRF根据计费规则请求中携带的计费相关输入信息，选择适当的计费规则，然后向TPF发送提供计费规则，该提供计费规则中可携带有选定的计费规则，如计费规则1。
步骤602和步骤603中CRF向TPF发送的各信息可通过一条消息承载。
步骤604TPF收到动态事件点列表和CRF当前选定的计费规则后，存储动态触发事件点列表，根据该计费规则进行计费信息统计，并监测动态触发事件点的发生。
步骤605TPF监测到动态触发事件点A发生，向CRF发送计费规则请求，该计费规则请求中携带有动态触发事件点A发生指示。
步骤606CRF收到计费规则请求后，根据动态触发事件点A发生指示确定该计费规则请求是由动态触发事件点A触发的，并根据动态触发事件点A选择适当的计费规则，然后向TPF发送提供计费规则，该提供计费规则中可携带有选定的新的计费规则，如计费规则2。
步骤607TPF收到提供计费规则后，根据该计费规则进行计费信息统计。
如果有多个动态触发事件点，则TPF继续监测其余的动态触发事件点的发生。
步骤608TPF监测到动态触发事件点B发生，向CRF发送计费规则请求，该计费规则请求中携带有动态触发事件点B发生指示。
步骤609CRF收到计费规则请求后，根据动态触发事件点B发生指示确定该计费规则请求是由动态触发事件点B触发的，并根据动态触发事件点B选择适当的计费规则，然后向TPF发送提供计费规则，该提供计费规则中可携带有选定的新的计费规则，如计费规则3。
步骤610TPF收到提供计费规则后，根据该计费规则进行计费信息统计。
后续流程与上述流程相似，不再赘述。
另外，在同一个会话中，对于GPRS网络，同一个会话即为同一个PDPContext，CRF可多次设置动态触发事件点并发送给TPF。例如，CRF收到AF或是OCS的计费相关输入信息时，可根据计费相关输入信息确定是否需要设置新的动态触发事件点，如果是，则设置新的动态触发事件点并发送给TPF，TPF收到新的动态触发事件点后，存储新的动态触发事件点并监测动态触发事件点的发生。
另外，由于在TPF中可配置向CRF请求计费规则的静态触发事件点，对于一些比较固化的事件，如承载建立，承载QoS修改，流量或者时间长度到达某一个固定的值，承载删除等等，可直接通过在TPF中预先配置静态事件点来向CRF上报承载的变化信息。而不需要CRF向TPF下发动态事件点。对于一些运营商或业务提供商对承载变化的事件很固定，如总是要求业务流量达到10M时TPF向CRF上报，或是总是要求业务激活时长达到100分钟后TPF向CRF上报，而没有其它需要动态配置的事件点，这样，只在TPF中预先配置相应的静态事件点就可以实现，CRF不下发任何动态事件点，可以减轻TPF和CRF之间的信令负荷。
图7为本发明中实施例一示意图，本实施例中将TPF向CRF请求计费规则的静态触发事件点设置为承载建立，CRF将需要TPF向其请求计费规则的动态触发事件点设置为承载修改和承载删除，CRF控制TPF发送计费规则请求的实现过程包括以下步骤步骤701UE向TPF发送承载建立请求，在GPRS网络中，则是GGSN收到Create PDP Context Request。
步骤702TPF收到承载建立请求后，确定静态触发事件点已发生，然后向CRF发送计费规则请求，该计费规则请求中携带有计费相关输入信息，如与用户和UE相关的信息、承载特性以及与网络相关的信息等；该计费规则请求中还可携带有事件标识，用于指示当前计费规则请求为静态触发事件点触发的。
步骤703～步骤704CRF收到计费规则请求后，根据事件标识确定该计费规则请求是由静态触发事件点触发的，然后设置动态触发事件点列表包括承载修改和承载删除，并向TPF发送动态触发事件点上报请求(RequestDynamic Event Report)，该动态触发事件点上报请求中携带有动态触发事件点列表。另外，CRF还可在承载修改的动态触发事件点中设置多个不同的值，如不同的QoS参数级别，每个值均可作为一个独立的动态触发事件点。
步骤705～步骤706CRF根据计费规则请求中携带的计费相关输入信息选择适当的计费规则，然后向TPF发送提供计费规则(Charging RuleResponse)，该提供计费规则中可携带有选定的计费规则。
步骤707～步骤708TPF收到CRF设置的动态触发事件点列表和CRF选定的计费规则后，存储动态触发事件点列表，根据计费规则进行计费信息统计，并监测动态触发事件点的发生。TPF向UE返回承载建立响应，接受UE发起的承载建立请求，并继续后续的承载建立流程。
步骤709一段时间后，UE向TPF发送承载修改请求，在GPRS网络中，则是GGSN收到Update PDP Context Request。
步骤710TPF收到承载修改请求后，确定动态触发事件点列表中的动态触发事件点承载修改已发生，然后向CRF发送计费规则请求，该计费规则请求中携带有动态触发事件点发生指示。
步骤711～步骤712CRF收到计费规则请求后，根据动态触发事件点发生指示确定该计费规则请求是由动态触发事件点承载修改触发的，并根据承载修改选择适当的计费规则，然后向TPF发送提供计费规则，该提供计费规则中可携带有选定的计费规则。
步骤713～步骤714TPF收到提供计费规则后，根据CRF选定的计费规则，建立新的计费规则，或是删除原有的计费规则，或是删除原有计费规则的同时建立新的计费规则，然后向UE返回承载修改响应，接受UE发起的承载修改请求，并继续后续的承载修改流程。
步骤715一段时间后，UE向TPF发送承载删除请求，在GPRS网络中，则是GGSN收到Delete PDP Context Request。
步骤716TPF收到承载删除请求后，确定动态触发事件点列表中的动态触发事件点承载删除已发生，然后向CRF发送计费规则请求，该计费规则请求中携带有动态触发事件点发生指示。
步骤717～步骤718CRF收到计费规则请求后，根据动态触发事件点发生指示确定该计费规则请求是由动态触发事件点承载删除触发的，并根据承载删除选择适当的计费规则，然后向TPF发送提供计费规则，该提供计费规则中可携带有选定的计费规则。
步骤719～步骤720TPF收到提供计费规则后，根据CRF选定的计费规则，建立新的计费规则，或是删除原有的计费规则，或是删除原有计费规则的同时建立新的计费规则，然后向UE返回承载删除响应，接受UE发起的承载删除请求，并继续后续的承载删除流程。
现有技术中，AF可向CRF发送应用/业务计费相关信息，作为CRF选择计费规则的计费相关输入信息；那么，根据本发明提出的方法，AF可向CRF发送应用/业务计费相关信息，作为CRF动态设置动态触发事件点的输入信息。
图8为本发明中实施例二示意图，如图8所示，本实施例中，CRF向TPF下发动态触发事件点的实现过程包括以下步骤步骤801CRF收到某个内部或外部的触发事件，如AF为用户提供积分活动，如果用户访问该AF的某个业务的数据流量达到一定数值，则这个用户访问该业务的后续计费费率将降低，此时，AF要求CRF在某个业务过滤器的数据流量达到一定值时，采用优惠的计费费率对后续的数据流量进行计费信息统计，或如果用户访问该AF的某个业务的使用时间长度达到一定数值，则这个用户访问该业务的后续计费费率将降低，此时，AF要求CRF在某个业务过滤器的使用时间长度达到一定值时，采用优惠的计费费率对后续的数据流量进行计费信息统计。
步骤802CRF配置动态触发事件点，例如，设置动态触发事件点为某个业务过滤器的数据流量达到一定值，或设置动态触发事件点为某个业务过滤器的业务使用时间长度达到一定值。另外，CRF可根据当前获知的信息，如TPF提供的用户/终端信息，承载特性，网络相关信息等选择适当的计费规则。
步骤803CRF向TPF发送动态触发事件点上报请求，该动态触发事件点上报请求中携带有当前设置的动态触发事件点列表，要求TPF在动态触发事件点发生时，向其请求计费规则。
步骤804CRF向TPF发送提供计费规则，该提供计费规则中可携带有当前选定的计费规则，该步骤为可选步骤。
步骤805TPF收到CRF当前设置的动态触发事件点列表，存储该动态触发事件点列表。如果TPF还收到提供计费规则，则根据CRF选定的计费规则，建立新的计费规则，或是删除原有的计费规则，或是删除原有计费规则的同时建立新的计费规则。
步骤806一段时间后，TPF监测到动态触发事件点发生，向CRF发送计费规则请求，该计费规则请求中携带有动态触发事件点发生指示。
步骤807～步骤808CRF收到计费规则请求后，根据动态触发事件点发生指示可确定该计费规则请求是由哪一个动态触发事件点触发的，例如，某个业务过滤器的数据流量已经达到一定值，或某个业务过滤器的业务使用时间长度已经达到一定值，并根据该动态触发事件点选择适当的计费规则，然后向TPF发送提供计费规则，该提供计费规则中可携带有选定的计费规则。
步骤809TPF收到提供计费规则后，根据CRF选定的计费规则，建立新的计费规则，或是删除原有的计费规则，或是删除原有计费规则的同时建立新的计费规则。
另外，CRF也可根据OCS发送的与用户信用相关的计费相关输入信息，对动态触发事件点进行动态设置，相应的流程与上述流程基本相同，在此不再赘述。
总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。
权利要求
1.一种分组数据业务的计费控制方法，其特征在于，该方法包含以下步骤A、设置触发事件点；B、所述触发事件点发生时，TPF向CRF发送计费规则请求。
2.根据权利要求1所述的方法，其特征在于，所述步骤A为CRF设置触发事件点，并向TPF发送所述触发事件点。
3.根据权利要求2所述的方法，其特征在于，所述步骤A之前进一步包括A0、在TPF中配置静态触发事件点，所述静态触发事件点发生时，TPF向CRF发送计费规则请求。
4.根据权利要求3所述的方法，其特征在于，所述静态触发事件点发生之前进一步包括TPF监测所述静态触发事件点的发生。
5.根据权利要求3所述的方法，其特征在于，步骤A0中所述计费规则请求中携带有用于标明静态触发事件点的事件标识。
6.根据权利要求3、4或5所述的方法，其特征在于，所述步骤A为CRF收到计费规则请求后，设置动态触发事件点，并向TPF发送所述动态触发事件点。
7.根据权利要求3所述的方法，其特征在于，所述步骤A0之后进一步包括CRF向TPF提供计费规则。
8.根据权利要求1所述的方法，其特征在于，所述步骤B之前进一步包括TPF存储所述触发事件点，并监测所述触发事件点的发生。
9.根据权利要求1所述的方法，其特征在于，步骤B中所述计费规则请求中携带有用于标明触发事件点的事件标识。
10.根据权利要求1所述的方法，其特征在于，所述步骤B之后进一步包括CRF向TPF提供计费规则。
11.根据权利要求10所述的方法，其特征在于，CRF根据发生的触发事件点确定所述计费规则。
12.根据权利要求1所述的方法，其特征在于，所述触发事件点为CRF根据自身存储信息进行设置。
13.根据权利要求1所述的方法，其特征在于，所述触发事件点为CRF根据AF，或OCS，或TPF，或以上所述任意组合提供的计费相关输入信息设置。
全文摘要
本发明公开了一种分组数据业务的计费控制方法，该方法包含设置触发事件点；触发事件点发生时，TPF向CRF发送计费规则请求。本发明中，由CRF确定需要TPF向其请求计费规则的触发事件点，然后向TPF下发这些触发事件点，当触发事件点发生时，TPF向CRF请求计费规则并提供计费相关输入信息，CRF根据计费相关输入信息选择适当的计费规则，并向TPF下发选定的计费规则，这样，可实现CRF对TPF向其请求计费规则的时机进行控制，避免了由于TPF在不必要的时候向CRF请求计费规则而导致的冗余信息，使得TPF与CRF之间的信息交互更为有效，对于分组数据业务计费的控制更为合理完善。
文档编号H04L12/14GK1645805SQ20041003372
公开日2005年7月27日 申请日期2004年4月9日 优先权日2004年4月1日
发明者段小琴 申请人:华为技术有限公司