CN101159567A - 一种基于分组数据流计费中的处理方法 - Google Patents

Abstract

本发明公开了一种基于分组数据流计费中的处理方法，该方法包含：TPF中设置处理条件及对应于处理条件的处理方式，承载事件发生时，TPF判断承载信息是否与设置的处理条件相匹配，如果是，则TPF按照对应于匹配到的处理条件的处理方式对所述承载进行处理；否则，TPF对所述承载进行FBC控制处理，使得TPF能够直接对一部分承载进行计费处理，无需通过向CRF请求计费规则，并根据CRF的指示进行相应的计费处理。这样，由于TPF具有直接处理对承载的计费的机制，能够分流一部分CRF对承载计费的控制处理，降低了CRF和TPF之间的消息交互，有效避免CRF与TPF之间冗余消息的生成，并降低了新增特性对现有网络的影响，符合实际网络演进的需要。

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数据流进行记录，生成相应的计费信息，TPF205生成的计费信息中可包括通过CRF下发的计费规则中获取的业务信息，业务使用情况，如使用业务的数据流量、或使用业务的时间长度，该时间长度可由TPF 205对过滤出的IP数据流进行统计而获得。TPF 205可通过Gz接口向CGF 207/CCF 208提供生成的计费信息，CGF 207/CCF 208对收到的计费信息进行进一步处理，然后上报至计费中心，由计费中心生成最后的用户话单。

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根据扣除的信用生成计费信息，并向CGF 207/CCF 208提供生成的计费信息，CGF 207/CCF 208对收到的计费信息进行进一步处理，然后上报至计费中心，由计费中心生成最后的用户话单。

OCS 206可要求TPF 205在重鉴权事件(Re-authorisation triggers)发生时向其上报，然后OCS 206根据TPF 205上报的相应重鉴权事件对用户进行重鉴权，并可能对用户的信用重新进行计算。例如，分区域计费时，运营商对不同地域的用户应用不同的费率，OCS 206根据用户当前所在位置确定对应的费率，并根据该费率计算用户的信用，当用户移动至另一位置时，如SGSN发生变化，TPF 205需要将SGSN变化事件上报至OCS 206，以使OCS206根据用户新的当前所在位置确定新的对应费率，并根据新费率重新计算用户新的信用。又如，当OCS 206根据用户使用业务的当前QoS参数确定费率，当用户对QoS参数进行修改，如承载发生修改，TPF 205需要将承载修改事件上报至OCS 206，以使OCS 206根据用户修改后的QoS参数确定新的费率，并根据新费率重新计算用户的信用。目前，3GPP规范中对OCS206通过重鉴权事件上报的机制，控制TPF 205的信用使用情况进行了描述，即TPF 205监测到重鉴权事件发生后向OCS 206上报，OCS 206通过TPF 205上报的重鉴权事件，获知用户的信用使用情况以及承载的变化，对用户的信用重新进行计算并下发给TPF 205。3GPP规范中定义的重鉴权事件可包括：允许信用过期(credit authorization lifetime expiry)事件，用户空闲状态超时(idle timeout)事件，计费键变化(charging key is changed)事件，PLMN变化事件，QoS参数变化事件，RAT类型变化事件。

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

目前，3GPP定义了承载建立时，TPF向CRF请求计费规则，以及在线计费情况下，TPF向OCS请求用户的信用的处理过程如图3A所示：

离线计费情况下，执行步骤301A～步骤305A和步骤308A；在线计费情况下，执行步骤301A～步骤308A。

步骤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选定的计费规则进行相应操作，即建立计费规则，如果提供计费规则中携带有触发事件信息，则TPF对相应触发事件进行存储。

步骤306A～步骤307A：在线计费情况下，TPF根据计费规则中的在线计费指示，向OCS发送信用请求(Credit Request)，请求用户的信用，该信用请求中携带有供OCS确定信用的输入信息。OCS收到信用请求后，确定用户的信用，然后向TPF返回信用响应(Credit Response)，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用，该信用响应中可进一步携带有重鉴权事件信息，TPF收到该信用响应后，可对相应重鉴权事件进行存储；如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值。

步骤308A：TPF向UE返回承载建立响应(Establish Bearer ServiceAccept)，在线计费情况下，如果信用响应中携带有用户的信用，则TPF接受UE发起的承载建立请求，并继续后续的承载建立流程；如果信用响应中没有携带有用户的信用，则TPF拒绝UE发起的承载建立请求。离线计费情况下，则TPF直接接受UE发起的承载建立请求，并继续后续的承载建立流程。

对于承载修改，TPF向CRF请求计费规则，以及在线计费情况下，TPF向OCS请求用户的信用的处理过程如图3B所示：

离线计费情况下，执行步骤301B～步骤306B和步骤310B；在线计费情况下，执行步骤301B～步骤310B。

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

步骤302B：承载修改可能使触发事件发生，因此，TPF收到承载修改请求后，判断承载修改事件是否与存储的触发事件相匹配，即确定是否触发计费规则请求流程，如果能够匹配，则触发计费规则请求流程，执行步骤303B；否则，结束当前流程。

步骤303B：TPF向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。

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

步骤306B：TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作，即建立、修改、删除计费规则，如果提供计费规则中携带有触发事件信息，则TPF对相应触发事件进行存储。

步骤307B：在线计费情况下，承载修改可能使重鉴权事件发生，因此，TPF判断承载修改事件是否与存储的某个计费键的重鉴权事件相匹配，即确定是否触发重鉴权流程，如判断承载修改事件是否与某个计费键的重鉴权事件相匹配，如果能够匹配，则触发重鉴权流程，执行步骤308B；否则，结束当前流程。

步骤308B～步骤309B：TPF向OCS发送信用及重鉴权请求(CreditRequest and Re-authorisation Request)，请求OC S对用户进行重鉴权并提供信用，该信用及重鉴权请求中携带有供OCS确定信用的输入信息，如向OCS请求基于某个计费键的信用。OCS收到信用及重鉴权请求后，确定用户的信用，然后向TPF返回信用响应，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用，如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值。

步骤310B：TPF向UE返回承载修改响应(Modify Bearer ServiceAccept)，在线计费情况下，如果信用响应中携带有用户的信用，则TPF接受UE发起的承载修改请求，并继续后续的承载修改流程；如果信用响应中未携带有用户的信用，则拒绝UE发起的承载修改请求。离线计费情况下，则TPF接受UE发起的承载建立请求，并继续后续的承载修改流程。

对于承载删除，TPF向CRF请求计费规则，以及在线计费情况下，TPF向OCS返回用户的剩余信用的处理过程如图3C所示：

离线计费情况下，执行步骤301C～步骤305C和步骤308C；在线计费情况下，执行步骤301C～步骤308C。

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

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

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

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

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

步骤308C：TPF向UE返回承载删除响应(Remove Bearer ServiceAccept)，接受UE发起的承载删除请求，并继续后续的承载删除流程。

由以上描述可见，目前3GPP定义的TPF和CRF之间关于计费规则的交互方式是：TPF经过一定的事件触发，如承载建立、删除，或是TPF检测到当前发生的事件与CRF下发的触发事件相匹配时，TPF则发起FBC控制处理，即TPF向CRF发送计费规则请求，CRF根据TPF发送的计费规则请求中携带的相关信息选择相应的计费规则，并向TPF下发。通过目前TPF与CRF进行交互的流程来看，CRF是控制实体，TPF是执行实体，TPF固定地在承载建立时，通过向CRF请求计费规则使得CRF建立对相应承载的计费控制；相应地，承载删除时，TPF也会固定地向CRF请求计费规则，使得CRF能够删除先前建立的对相应承载的计费控制。这样，TPF完全作为一个执行实体，被动地根据CRF的下发的指示进行相应操作，丝毫未参与承载的计费控制。也就是说，一旦网络升级成能够支持FBC特性的网络时，所有承载建立时，均会导致TPF与CRF进行交互，由CRF对相应承载进行计费控制。

然而，在实际应用中，当网络升级成能够支持FBC特性的网络时，由于业务在部属初期，引入新特性会对现有网络产生影响，为了减少引入的FBC特性对现有网络的影响，运营商可能只部署一部分业务按照业务数据流进行计费，其他业务保持原有的计费方式不变，例如，运营商向用户提供了流媒体业务和网页浏览业务，只在流媒体业务中根据不同流媒体内容进行区分计费，对于网页浏览业务则无需根据浏览的网页内容进行区分计费，而是统一按照固定的计费模式进行计费。另外，一些情况下建立的承载也不需要根据内容进行计费，例如，运营商为某个企业提供接入企业内部网络的私有APN，该企业的私有APN只允许企业的注册用户访问，企业的注册用户可通过访问该私有APN进行移动办公，如收发电子邮件、访问企业网络等等，由于运营商向某个企业提供私有APN的计费方式可以是按照包月制收取一定的月租费，因此，对于这种基于私有APN的建立的承载，也就不需要根据不同业务数据流进行计费。

基于以上描述可见，纯CRF控制的对业务数据流计费的方式不符合实际网络演进的需要，而且在很多情况下可能会导致CRF与TPF之间生成大量冗余消息。

发明内容

有鉴于此，本发明的目的在于提供一种基于分组数据流计费中的处理方法，有效避免CRF与TPF之间冗余消息的生成，符合实际网络演进的需要。

为了达到上述目的，本发明提供了一种基于分组数据流计费中的处理方法，该方法包含以下步骤：

A、TPF中设置处理条件及对应于处理条件的处理方式；

B、承载事件发生时，TPF判断承载信息是否与设置的处理条件相匹配，如果是，则执行步骤C，否则，执行步骤D；

C、TPF按照对应于匹配到的处理条件的处理方式对所述承载进行处理，并结束当前流程；

D、TPF对所述承载进行FBC控制处理。

较佳地，所述步骤A进一步包括：设置处理条件的优先级；所述步骤B为：承载事件发生时，TPF根据所述处理条件的优先级的高低，依次判断承载信息是否与设置的处理条件相匹配，直至匹配到设置的处理条件，然后执行步骤C，否则，执行步骤D。

所述步骤A为：直接在TPF中配置处理条件及对应于处理条件的处理方式。

所述步骤A为：CRF向TPF下发处理条件及对应于处理条件的处理方式，TPF对处理条件及对应于处理条件的处理方式进行存储。

步骤A中所述处理条件为接入点名称，或为IP五元组，或为以上二者的组合。

步骤A中或步骤C中所述处理方式为GPRS通用计费方式，或为数据业务通用计费方式，或为以上二者的组合。

步骤B中所述承载事件为承载建立，或为承载修改，或为承载删除。

所述步骤D为：TPF向CRF请求计费规则，CRF向TPF返回选定的计费规则，TPF根据收到的计费规则对所述承载进行处理。

步骤B中所述承载信息为接入点名称，或为IP五元组，或为以上二者的组合。

根据本发明提出的方法，在TPF中设置设定的处理方法，即设置处理条件及对应于处理条件的处理方式，使得TPF能够直接对一部分承载进行计费处理，无需通过向CRF请求计费规则，并根据CRF的指示进行相应的计费处理。这样，由于TPF具有直接处理对承载的计费的机制，能够分流一部分CRF对承载计费的控制处理，降低了CRF和TPF之间的消息交互，有效避免CRF与TPF之间冗余消息的生成，并降低了新增特性对现有网络的影响，符合实际网络演进的需要。

附图说明

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

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

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

图3A示出了承载建立时请求计费规则及信用的处理流程图；

图3B示出了承载修改时请求计费规则及信用的处理流程图；

图3C示出了承载删除时请求计费规则及信用的处理流程图；

图4示出了本发明实现过程示意图。

具体实施方式

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

本发明中，在TPF中设置设定的处理方法，即设置处理条件及对应于处理条件的处理方式，使得TPF能够直接对一部分承载进行计费处理，无需向CRF请求计费规则，并根据CRF的指示再进行相应的计费处理。这样，由于TPF具有直接处理对承载的计费的机制，能够分流一部分CRF对承载计费的控制处理，降低了CRF和TPF之间的消息交互，有效避免CRF与TPF之间冗余消息的生成，并降低了新增特性对现有网络的影响。

图4示出了本发明实现过程示意图，如图4所示，本发明中提供的设置设定的处理过程包括以下步骤：

步骤401：在TPF中设置处理条件及对应于处理条件的处理方式。所述的处理条件和处理方式可由运营商在TPF中进行预先配置，也可由CRF向TPF下发，由TPF进行存储。CRF可在某时刻批量地向TPF下发，如在网络升级成支持FBC特性的网络时批量地向TPF下发，由TPF对处理条件和处理方式进行存储，又如在处理条件或处理方式有变化时批量地向TPF下发，TPF对存储的处理条件和处理方式进行更新。

在TPF中设置的处理条件可为特定的APN，也可为特定的IP五元组，还可为APN与IP五元组的组合，与处理条件相对应的处理方式可为要求TPF根据设定的处理过程对相应承载进行处理。

所述的处理方式可为GPRS通用计费方式，如基于每个PDP上下文进行统计的计费方式，也可为数据业务通用计费方式，可理解为设置了缺省计费规则的计费方式，还可为以上二者的组合。

另外，TPF中还可设置处理条件的优先级，在TPF判断当前承载是否满足设置的处理条件时，可按照优先级的高低顺序，将承载信息与设置的处理条件依次匹配，即优先匹配优先级较高的处理条件，然后再匹配优先级较低的处理条件，这样可确保同一承载同时满足多个设置的处理条件情况下，能够按照对应于优先级高的处理条件的处理方式优先对承载进行处理。优先级、处理条件、及对应的处理方式可参见表一。

优先级	处理条件	处理方式
			1	APN 1	处理方式1
2	APN 2	处理方式2
			3	IP五元组	处理方式3

表一

步骤402～步骤403：承载事件发生时，TPF判断承载信息是否与设置的处理条件相匹配，如果是，则执行步骤404；否则，执行步骤405。以上所述的承载事件可为承载建立、承载修改、承载删除等事件。所述承载信息可以承载的APN信息，IP五元组信息，以及以上二者的组合信息，等等。

步骤404：TPF按照对应于匹配到的处理条件的处理方式，对相应承载进行处理。

如果设置了处理条件的优先级，TPF可按照优先级的高低顺序，将承载信息与设置的处理条件依次进行匹配，如果能够匹配到，最终，TPF将按照对应于匹配到的优先级最高的处理条件的处理方式，对相应承载进行处理。

步骤405：TPF请求CRF对相应承载进行FBC控制处理，即TPF与CRF进行交互，TPF向CRF发起计费规则请求，请求CRF对该承载提供计费规则，然后TPF根据CRF提供的计费规则对该承载进行处理。

例如，TPF收到承载建立请求后，判断承载信息是否与设置的处理条件相匹配，如判断建立承载的APN是否与设置的APN相匹配，如果承载信息匹配到设置的处理条件，则TPF按照对应于匹配到的处理条件的处理方式，对相应承载进行处理，如果承载信息未匹配到设置的处理条件，则TPF结束对承载的设定处理，向CRF请求计费规则，进入TPF与CRF进行交互的FBC控制处理流程。

另外，对于承载修改或承载删除的承载事件，TPF也可先将承载信息与设置的处理条件进行匹配，如果承载信息匹配到设置的处理条件，则TPF可进一步确定是否按照对应于匹配到的处理条件的处理方式，对相应承载进行处理，如果不是，则TPF结束对承载的设定处理，可向CRF请求计费规则，进入TPF与CRF进行交互的FBC控制处理流程。

例如，将GPRS网络升级成支持FBC特性的网络时，在TPF中设置处理条件及对应于处理条件的优先级和处理方式，以上信息可由CRF向TPF批量下发给TPF，TPF对收到的信息进行存储，也可为直接在TPF中进行配置，具体内容如表二所示。

优先级	处理条件	处理方式
			1	APN＝“ABC”	处理方式1：按照原有GPRS方式基于每个PDP上下文进行统计，采用访问企业私有APN为“ABC”的费率进行计费

2	APN＝“cmnet”	处理方式2：按照原有GPRS方式基于每个PDP上下文进行统计，采用访问互联网(Internet)数据业务的费率进行计费
			3	APN＝“cmwap”	处理方式3：按照原有GPRS方式基于每个PDP上下文进行统计，采用访问WAP数据业务的费率进行计费
4	源IP＝通配，源端口＝通配目的IP＝129.0.0.1目的端口＝80或源IP＝129.0.0.1，源端口＝80目的IP＝通配，目的端口＝通配	处理方式4：对满足相应IP五元组的数据包进行统计，使用FTP业务的费率进行计费

表二

用户向TPF发起承载建立请求，TPF收到承载建立请求后，根据设置的处理条件的优先级，依次判断建立的承载的APN是否为“ABC”、或“cmnet”、或“cmwap”，如果该承载的APN与上述设置的一个APN相匹配，则TPF按照对应于匹配到的处理条件的处理方式，对该承载进行处理，例如，建立承载的APN为“cmnet”，则TPF采用处理方式2对该承载进行处理，即按照原有GPRS方式基于每个PDP上下文进行统计，采用访问互联网(Internet)数据业务的费率对该承载进行处理；如果该承载的APN无法与上述设置的一个APN相匹配，则TPF继续判断该承载的IP五元组是否满足“源IP＝通配，源端口＝通配，目的IP＝129.0.0.1，目的端口＝80”、或“源IP＝129.0.0.1，源port＝80，目的IP＝通配，目的端口＝通配”的条件，如果满足，则TPF采用处理方式4对该承载进行处理，即对满足该IP五元组的数据包进行统计，使用FTP业务的费率对该承载进行处理；否则，如果该承载不满足TPF中设置的所有处理条件，则TPF结束对承载的设定处理，进入对该承载进行FBC控制处理的流程，即TPF与CRF进行交互，向CRF发起计费规则请求，请求CRF对该承载提供计费规则，然后TPF根据CRF提供的计费规则对该承载进行处理。

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

Claims (9)

1.一种基于分组数据流计费中的处理方法，其特征在于，该方法包含以下步骤：

A、TPF中设置处理条件及对应于处理条件的处理方式；

B、承载事件发生时，TPF判断承载信息是否与设置的处理条件相匹配，如果是，则执行步骤C，否则，执行步骤D；

C、TPF按照对应于匹配到的处理条件的处理方式对所述承载进行处理，并结束当前流程；

D、TPF对所述承载进行FBC控制处理。

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

所述步骤A进一步包括：设置处理条件的优先级；

所述步骤B为：承载事件发生时，TPF根据所述处理条件的优先级的高低，依次判断承载信息是否与设置的处理条件相匹配，直至匹配到设置的处理条件，然后执行步骤C，否则，执行步骤D。

3.根据权利要求1或2所述的方法，其特征在于，所述步骤A为：直接在TPF中配置处理条件及对应于处理条件的处理方式。

4.根据权利要求1或2所述的方法，其特征在于，所述步骤A为：CRF向TPF下发处理条件及对应于处理条件的处理方式，TPF对处理条件及对应于处理条件的处理方式进行存储。

5.根据权利要求1或2所述的方法，其特征在于，步骤A中所述处理条件为接入点名称，或为IP五元组，或为以上二者的组合。

6.根据权利要求1或2所述的方法，其特征在于，步骤A中或步骤C中所述处理方式为GPRS通用计费方式，或为数据业务通用计费方式，或为以上二者的组合。

7.根据权利要求1或2所述的方法，其特征在于，步骤B中所述承载事件为承载建立，或为承载修改，或为承载删除。

8.根据权利要求1或2所述的方法，其特征在于，所述步骤D为：TPF向CRF请求计费规则，CRF向TPF返回选定的计费规则，TPF根据收到的计费规则对所述承载进行处理。

9.根据权利要求1或2所述的方法，其特征在于，步骤B中所述承载信息为接入点名称，或为IP五元组，或为以上二者的组合。

Images