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

专利名称：：一种基于分组数据流计费中的处理方法
技术领域：
：本发明涉及分组数据计费领域，特别是指一种基于分组数椐流计费中的处理方法。
背景技术：
：随着分组数据业务应用的逐渐广泛，如何准确合理地对分组数据业务进行计费，已成为运营商普遍关注的问题。图1示出了分组数据协议上下文(PDPContext,PacketDataProtocolContext)激活、数据传输、去激活流程图，如图l所示，在通用分组无线业务(GPRS,GeneralPacketRadioService)中，激活PDPContext、与外部分组数据网络(PDN,PacketDataNetwork)进行数据交互、去激活该PDPContext的实现过程包括以下步骤步骤101:移动终端(MS)向服务通用分组无线业务支持节点(SGSN，ServingGPRSSupportNode)发送PDPContext激活请求(ActivatePDPContextRequest),该ActivatePDPContextRequest中携带有网络层业务访问点才示i只(NSAPI,NetworkLayerServiceAccessPointIdentifier)、PDP类型、接入点名称(APN，AccessPointName)、要求的服务质量(QoS)参数、事务标识(TI,TransactionIdentifier)等信息，其中，NSAPI在SGSN和网关通用分组无线业务支持节点(GGSN,GatewayGPRSSupportNode)之间作为隧道标识(TID，TunnelIdentifier)的组成部分，用于标识PDPContext;PDP类型包才舌端对端协i义(PPP，Peer-PeerProtocol)类型、网际协议(IP，InternetProtocol)类型等；APN可由MS向SGSN提供，SGSN根据APN寻址到相应GGSN,GGSN根据APN确定MS所要访问的外部网络，MS也可不向SGSN提供APN,此时，由SGSN根据MS用户的签约信息选择缺省的APN;QoS参数为MS指定的分组数据业务所要达到的质量要求；TI用于MS标识某个PDPcontext。步骤102:SGSN收到ActivatePDPContextRequest后，与MS进行安全性检查和加密，该步骤为可选步骤。步骤103:SGSN根据APN解析GGSN的地址信息，如果SGSN能够根据APN解析出.GGSN的地址信息，则为PDPContext创建TEID,该TEID可为国际移动用户标识(IMSI，InternationalMobileSubscriberIdentity)与NSAPI的组合，然后SGSN向GGSN发送PDPContext创建请求(CreatePDPContextR叫uest),该PDPContext创建请求中携带有PDP类型、PDP地址、APN、QoS参数、TEID、选择模式等，其中，PDP地址可为MS的IP地址，为可选参数，PDPContext创建请求中可不携带PDP地址，此时，在后续的处理过程中，可由GGSN为MS分配IP地址，也可由最终与MS建立连接的PDN为MS分配IP地址；选择模式是指APN的选择模式，即APN是由MS选定的还是由SGSN选定的。如果SGSN无法根据APN解析出GGSN的地址信息，则SGSN拒绝MS发起的PDPContext激活请求。步骤104:GGSN收到PDPContext创建请求后，根据APN确定外部PDN，然后分配计费标识(ChargingID)、启动计费，并且协商QoS,如果GGSN能够满足QoS参数的服务质量要求，则向SGSN返回PDPContext创建响应(CreatePDPContextResponse)，该PDPContext创建响应中携带有TEID、PDP地址、链路承载(BackboneBearer)协议、商定的QoS参数、ChargingID等信息。如果GGSN无法满足QoS参数的服务质量要求，则GGSN拒绝SGSN发起的PDPContext创建请求，然后SGSN拒绝MS发起的PDPContext激活请求。步骤105:S(}SN收到PDPContext创建响应后，在PDPContext中插入用于标识PDPContext的NSAPI和GGSN地址信息，并根据商定的QoS参数选择无线优先4又，然后向MS返回PDPContext激活响应(ActivatePDPContextAccept),该PDPContext激活响应中携带有PDP类型、PDP地址、TI、商定的QoS参数、无线优先权、PDP配置选项等信息。并且，SGSN启动计费。MS收到PDPContext激活响应，就已经建立了MS与GGSN直接的路由，可以进行分组数据的传输了。步骤106:MS通过SGSN、GGSN与PDN进行分组数据的交互。步骤107:结束分组数据交互后，MS向SGSN发送PDPContext去激活请求(DeactivatePDPContextRequest),该PDPContext去激活请求中携带有TI。步骤108:SGSN收到PDPContext去激活请求后，与MS进行安全性检查和加密，该步骤为可选步骤。步骤109~步骤111:SGSN向GGSN发送PDPContext删除请求(DeletePDPContextRequest)，该PDPContext删除请求中携带有TEID。GGSN收到PDPContext删除请求后，结束对MS的计费，删除对应于TEID的PDPContext,然后向SGSN发送PDPContext删除响应(DeletePDPContextResponse)，该PDPContext删除响应中携带有TEID。SGSN收到PDPContext删除响应后，结束对MS的计费，删除对应于TEID的PDPContext,然后向MS发送PDPContext去激活响应(DeactivatePDPContextResponse)，该PDPContext去激活响应中携带有TI。MS收到PDPContext去激活响应后，删除对应于TI的PDPContext。由图l描述的实现过程可见，当前的GPRS计费系统中，由于计费的起始点设置在PDPContext激活时，计费的终止点设置在PDPContext删除时，因此只能根据PDPContext传输的数据流量进行计费，或是根据PDPContext处于激活状态的时间长度进行计费。然而，在实际应用中，MS与PDN进行数据交互后，该MS可以基于一个激活的PDPContext进4亍多种业务，也就是说，如果PDN能够提供多种业务，如电子邮件(Email)收发业务、基于无线应用协议的(WAP,WirelessApplicationProtocol)的浏览业务、基于文件传输协议(FTP,FileTransferProtocol)的文件传输等业务，则MS在与该PDN建立传输通道后，可通过一个激活的PDPContext承载该PDN能够提供的各种业务，但是，运营商对于各种业务的计费模式很可能采用不同的计费方式，如对于Email收发业务可基于Email接收和发送事件的触发按次计费，对于WAP浏览业务可根据流量计费，对于文件传输业务也可根据流量计费，WAP浏览业务的费率与文件传输业务的费率却不尽相同。这样，根据现有的GPRS计费系统，根本无法对同一PDPContext承载的不同业务进行区分计费。针对上述情况，第三代合作伙伴计划(3GPP，The3rdGenerationPartnershipProject)目前正在讨论如何实现基于IP数据流的计费(FBC,FlowBasedCharging)。对于一个分组数据业务而言，MS的用户使用该业务时，传输和接收到的所有IP数据流(IPFlow),也可为IP分组包(IPpacket)，总称为业务数据流(ServiceDataFlow),即业务数据流是多个IP数据流组成的集合，因此基于IP数据流的计费能够真实反映某个业务数据流对资源的占用情况。基于IP数据流的计费可被认为是通过一些类似筛子的过滤器将同一PDPContext中承载的不同业务的IP数据流分别篩选出来，然后针对不同过滤器过滤出的IP数据流进行分别计费，以达到对不同的业务数据流分别计费的目的。这样，基于IP数据流的计费粒度要远远小于基于一个PDPContext的计费粒度，粒度可看作是筛子孔的大小，基于一个PDPContext的计费粒度是一个PDPContext就是一个筛子孔，而基于IP数据流的计费粒度则是一个IP业务数据流则为一个筛子孔，即针对一个PDPContext中包含多个筛子孔，因此，基于IP数据流的计费与比基于一个PDPContext的计费相比，基于IP数据流的计费能够为运营商或业务提供者提供更为丰富的计费手段。3GPP中对FBC的系统结构、功能要求以及消息交互流程等方面均进行了描述，支持在线计费的FBC系统结构如图2A所示，基于移动网络增强逻辑的客户化应用(CAMEL,CustomisedApplicationforMobileNetworkEnhancedLogic)的业务控制点(SCP,ServiceControlPoint)201和基于业务数据流计费的信用控制功能实体(CCF,ServiceDataFlowBasedCreditControlFunction)202组成了在线计费系统(OCS,OnlineChargingSystem)206。CCF202通过Ry接口与基于业务数据流计费的计费规则功能实体(CRF,ServiceDataFlowBasedChargingRuleFunction)203互通，CRF203通过Rx接口与应用功能实体(AF,ApplicationFunction)204互通，CRF203通过Gx接口与传*命面功能实体(TPF，TrafficPlaneFunction)205互通，CCF202通过Gy4妾口与TPF205互通。支持离线计费的FBC系统结构如图2B所示，CRF203通过Rx接口与AF204互通，CRF203通过Gx接口与TPF205互通，TPF205通过Gz接口分别与计费网关功能实体(CGF，ChargingGatewayFunction)207和计费采集功能实体(CCF,ChargingCollectionFunction)208互通。TPF205承载IP数据流，当IP数据流的承载建立时，TPF205通过Gx接口向CRF203发送计费规则请求，该计费规则请求中携带有与用户和MS相关的信息、承载特性以及与网络相关的信息等，其中与用户和MS相关的信息可为移动台国际号码(MSISDN)、国际移动用户标识(IMSI)等，与网络相关的信息可为移动网络编码(MNC)、移动国家码(MCC)等。另外，由于在IP数据流传输过程中，会对承载进行修改，如对QoS参数进行重新协商，当用户使用同一业务的QoS参数不同时，计费规则可能不同，如QoS参数下降相应的费率也下降。此时，TPF205可在承载修改时，重新向CRF203发送计费规则请求，请求新的计费规则；CRF203根据TPF205提供的上述输入信息选择适当的计费规则，并向TPF205返回选定的计费规则，计费规则中包括计费机制、计费类型、计费键(ChargingKey)、业务数据流过滤器、计费规则优先级等信息。其中，计费机制可为采用在线计费还是离线计费；计费类型可为基于时间长度进行计费还是基于数据流量进行计费；计费键是与费率相关的参数，CRF203可不直接向TPF205提供费率，而只是向TPF205提供与费率相关的参数；业务数据过滤器用于指示TPF205对哪些IP数据流进行过滤，然后TPF205根据计费规则对过滤出的IP数据流进行计费。业务数据过滤器可包含IP5元组，IP5元组可包括源/目的IP地址、源/目的端口号(PortNumber)、协议标识(ProtocolID)等信息，例如，CRF203指示TPF205对源地址为10.0.0.1、目的地址为10.0.0.2、源/目的端口号为20、协议类型为传输控制协议(TCP)的IP数据流进行过滤，并根据计费规则对过滤出的IP数据流进行记录，生成相应的计费信息，TPF205生^的计费信息中可包括通过CRF下发的计费规则中获取的业务信息，业务使用情况，如使用业务的数据流量、或使用业务的时间长度，该时间长度可由TPF205对过滤出的IP数据流进行统计而获得。TPF205可通过Gz接口向CGF207/CCF208提供生成的计费信息，CGF207/CCF208对收到的计费信息进行进一步处理，然后上报至计费中心，由计费中心生成最后的用户话单。CRF203可向-TPF205提供触发事件(EventTrigger)，用以要求TPF205在特定事件发生时，向CRF205请求新的计费规则，如CRF203要求TPF205在某些承载进行修改的事件发生时，向CRF203请求新的计费规则。触发事件可视为与计费规则相关的事件。目前，3GPP规范中对CRF通过触发事件上报机制，控制TPF的计费方式进行了描述，即TPF205监测到触发事件发生后向CRF203上报，CRF203通过TPF205上报的触发事件获知承载发生变化，然后确定相应的计费^见则并下发给TPF205。3GPP规范中定义的触发事件可包括7〉用陆地移动通信网络(PLMN)变化(PLMNchange)事件，QoS参数变化(QoSchanges)事件，无线接入技术(RAT)类型变化(RATtypechange)事件，传输流模板(TFT)变化(TFTchange)事件CRF203除了根据TPF205提供的输入信息选择适当的计费规则之外，CRF203还可根据AF204或OCS206的输入信息选择适当的计费规则，如AF204通知CRF203用户当前使用的业务类型，CRF203根据该业务类型选择相应的计费规则。OCS206作为在线计费系统，由SCP201和CCF202两个功能实体组成，其中，CCF202是执行信用控制的功能实体，仅应用于在线计费系统，可通过在现有的OCS206中增加新的功能来实现。在线计费过程中，CCF202对用户信用进行管理和控制，当用户使用业务时，CCF202对该用户信用池中的信用进行鉴权，并通过Gy接口向TPF205下发用户能够使用的信用。最后，OCS206根据扣除的信用生成计费信息，并向CGF207/CCF208提供生成的计费信息，CGF207/CCF208对收到的计费信息进行进一步处理，然后上报至计费中心，由计费中心生成最后的用户话单。OCS206可要求TPF205在重鉴权事件(Re-authorisationtriggers)发生时向其上报，然后OCS206根据TPF205上报的相应重鉴权事件对用户进行重鉴权，并可能对用户的信用重新进行计算。例如，分区域计费时，运营商对不同地域的用户应用不同的费率，OCS206根据用户当前所在位置确定对应的费率，并根据该费率计算用户的信用，当用户移动至另一位置时，如SGSN发生变化，TPF205需要将SGSN变化事件上报至OCS206，以使OCS206根据用户新^'当前所在位置确定新的对应费率，并根据新费率重新计算用户新的信用。又如，当OCS206根据用户使用业务的当前QoS参数确定费率，当用户对QoS参数进行修改，如承载发生修改，TPF205需要将承载修改事件上报至OCS206，以使OCS206根据用户修改后的QoS参数确定新的费率，并根据新费率重新计算用户的信用。目前，3GPP规范中对OCS206通过重鉴权事件上报的机制，控制TPF205的信用使用情况进行了描述，即TPF205监测到重鉴权事件发生后向OCS206上报，OCS206通过TPF205上报的重鉴权事件，获知用户的信用使用情况以及承载的变化，对用户的信用重新进行计算并下发给TPF205。3GPP规范中定义的重鉴权事件可包括允许信用过期(creditauthorizationlifetimeexpiry)事件，用户空闲状态超时(idletimeout)事件，计费键变化(chargingkeyischanged)事件，PLMN变化事件，QoS参数变化事件，RAT类型变化事件。对应于GPRS网络，TPF205为GGSN,AF为PDN中的一个业务网关或业务服务器，CRF203为新增的逻辑实体。TPF205为计费规则的执行点，CRF203为计费规则的控制点。目前，3GPP定义了承栽建立时，TPF向CRF请求计费规则，以及在线计费情况下，TPF向OCS请求用户的信用的处理过程如图3A所示离线计费情况下，执行步骤301A步骤305A和步骤308A;在线计费情况下，执行步骤301A步骤308A。步骤301A:用户设备(UE)向TPF发送承载建立请求(EstablishBearerServiceR叫uest)，在GPRS网络中，则是GGSN收到CreatePDPContextRequest。步骤302A:TPF收到承载建立请求后，向CRF发送计费规则请求(R叫uestChargingRules)，该计费规则请求中携带有供CRF确定计费^>则的输入信息。步骤303A步骤304A:CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，然后向TPF返回提供计费规则(ProvisionChargingRules)，该提供计费规则中可携带有选定的计费规则和触发事件信息。步骤305A:TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作，即建立计费规则，如果提供计费规则中携带有触发事件信息，则TPF对相应触发事件进行存储。步骤306A步骤307A:在线计费情况下，TPF根据计费规则中的在线计费指示，向OCS发送信用请求(CreditRequest)，请求用户的信用，该信用请求中携带有供OCS确定信用的输入信息。OCS收到信用请求后，确定用户的信用，然后向TPF返回信用响应(CreditResponse),如果OCS确定出用户的信用，则该信用响应中携带有用户的信用，该信用响应中可进一步携带有重鉴权事件信息，TPF收到该信用响应后，可对相应重鉴权事件进行存储；如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值。步骤308A:TPF向UE返回承载建立响应(EstablishBearerServiceAccept)，在线计费情况下，如果信用响应中携带有用户的信用，则TPF接受UE发起的承载建立请求，并继续后续的承载建立流程；如果信用响应中没有携带有用户的信用，则TPF拒绝UE发起的承载建立请求。离线计费情况下，则TPF直接接受UE发起的承载建立请求，并继续后续的承载建立流程。对于承载修改，TPF向CRF请求计费规则，以及在线计费情况下，TPF向OCS请求用户的信用的处理过程如图3B所示离线计费情况下，执行步骤301B步骤306B和步骤310B;在线计费情况下，执行步骤301B步骤310B。步骤301B:UE向TPF发送承载修改请求(ModifyBearerServiceR叫uest),在GPRS网络中，则是GGSN收到PDPContext更新请求(UpdatePDPContextRequest)。步骤302B:率载修改可能使触发事件发生，因此，TPF收到承载修改请求后，判断承载修改事件是否与存储的触发事件相匹配，即确定是否触发计费规则请求流程，如果能够匹配，则触发计费规则请求流程，执行步骤303B;否则，结束当前流程。步骤303B:TPF向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。步骤304B步骤305B:CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则和触发事件信息。步骤306B:TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作，即建立、修改、删除计费规则，如果提供计费规则中携带有触发事件信息，则TPF对相应触发事件进行存储。步骤307B:在线计费情况下，承栽修改可能使重鉴权事件发生，因此，TPF判断承载修改事件是否与存储的某个计费键的重鉴权事件相匹配，即确定是否触发重鉴权流程，如判断承载修改事件是否与某个计费键的重鉴权事件相匹配，如果能够匹配，则触发重鉴权流程，执行步骤308B;否则，结束当前流程。步骤308B步骤309B:TPF向OCS发送信用及重鉴权请求(CreditRequestandRe-authorisationRequest),请求OCS对用户进行重鉴4又并提供信用，该信用及重鉴权请求中携带有供OCS确定信用的输入信息，如向OCS请求基于某个计费键的信用。OCS收到信用及重鉴权请求后，确定用户的信用，然后向TPF返回信用响应，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用，如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值。步骤31OB:TPF向UE返回承载修改响应(ModifyBearerServiceAccept)，在线计费情况下，如果信用响应中携带有用户的信用，则TPF接受UE发起的承载修改请求，并继续后续的承载修改流程；如果信用响应中未携带有用户的信用，则拒绝UE发起的承载修改请求。离线计费情况下，.则TPF接受UE发起的承载建立请求，并继续后续的承载修改流程。对于承载删除，TPF向CRF请求计费规则，以及在线计费情况下，TPF向OCS返回用户的剩余信用的处理过程如图3C所示离线计费情况下，执行步骤301O步骤305C和步骤308C;在线计费情况下，执行步骤301C步骤308C。步骤301C:UE向TPF发送承栽删除请求(RemoveBearerServiceRequest),在GPRS网络中，则是GGSN收到DeletePDPContextR叫uest。步骤302C:TPF收到承载删除请求后，向CRF发送计费规则请求，用于通知CRF用户建立的承载已删除，该计费规则请求中携带有供CRF确定计费规则的输入信息。步骤303C步骤304C:CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则和计费规则操作指示。步骤305C:TPF收到提供计费规则后，根据计费规则操作指示对CRF选定的计费规则进行相应操作，即删除计费规则。步骤306C步骤307C:TPF向OCS发送信用回退(CreditReturn),通知OCS为用户建立的承载已经终止，该信用回退中携带有用户信用的使用情况，如用户使用分组数据业务的时间长度、使用分组数据的流量大小，或是用户的剩余信用。OCS收到信用回退后，向TPF返回信用回退响应(Response)。步骤308C:TPF向UE返回7fL载删除响应(RemoveBearerServiceAccept),接受UE发起的承载删除请求，并继续后续的承载删除流程。由以上描述可见，目前3GPP定义的TPF和CRF之间关于计费MJ'J的交互方式是TPF经过一定的事件触发，如承载建立、删除，或是TPF检测到当前发生的事件与CRF下发的触发事件相匹配时，TPF则发起FBC控制处理，即TPF向CRF发送计费规则请求；CRF根据TPF发送的计费规则请求中携带的相关信息选择相应的计费规则，并向TPF下发。通过目前TPF与CRF进行交互的流程来看，CRF是控制实体，TPF是执行实体，TPF固定地在承栽建立时，通过向CRF请求计费规则使得CRF建立对相应承载的计费控制；相应地，承载删除时，TPF也会固定地向CRF请求计费M^寸，使得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、并结束当前流程；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示出了PDPContext激活、数据传输、去激活流程图；图2A示出了在线计费的FBC系统结构示意图；图2B示出了离线计费的FBC系统结构示意图；图3A示出了承载建立时请求计费规则及信用的处理流程图；图3B示出了.承载修改时请求计费规则及信用的处理流程图；图3C示出了承栽删除时请求计费规则及信用的处理流程图；图4示出了本发明实现过程示意图。具体实施方式为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。本发明中，在TPF中设置设定的处理方法，即设置处理条件及对应于处理条件的处理方式，使得TPF能够直接对一部分承载进行计费处理，无需向CRF请求if费规则，并根据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判断当前承载是否满足设置的处理条件时，可按照优先级的高低顺序，将承载信息与设置的处理条件依次匹配，即优先匹配优先级较高的处理条件，然后再匹配优先级较低的处理条件，这样可确保同一承载同时满足多个设置的处理条件情况下，能够按照对应于优先级高的处理条件的处理方式优先对承载进行处理。优先级、处理条件、及对应的处理方式可参见表一。<table>tableseeoriginaldocumentpage18</column></row><table>表步骤402步輝403:承载事件发生时，TPF判断承载信息是否与设置的处理条件相匹配，如果是，则执行步骤404;否则，执行步骤405。以上所述的承载事件可为承栽建立、承载修改、承载删除等事件。所述承载信息可以承载的APN信息，IP五元组信息，以及以上二者的组合信息，等等。步骤404:TPF按照对应于匹配到的处理条件的处理方式，对相应7"R载进行处理。如果设置了处理条件的优先级，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中进行配置，具体内容如表二所示。<table>tableseeoriginaldocumentpage19</column></row><table><table>tableseeoriginaldocumentpage20</column></row><table>表用户向TPF发起承载建立请求，TPF收到承载建立请求后，根据设置的处理条件的优先级，依次判断建立的承载的APN是否为"ABC"、或"cmnet"、或"cmwap",如果该承载的APN与上述设置的一个APN相匹配，则TPF按照对应于匹配到的处理条件的处理方式，对该岸义载进4亍处理，例如，建立承栽的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提供的计费规则对该承载进行处理。总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。权利要求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、4艮据权利要求1或2所述的方法，其特征在于，步骤A中或步骤C中所述处逑方式为GPRS通用计费方式，或为数据业务通用计费方式，或为以上二者的组合。7、根据权利要求1或2所述的方法，其特征在于，步骤B中所述承载事件为承载建立，或为承载修改，或为承栽删除。8、根据权利要求1或2所述的方法，其特征在于，所述步骤D为TPF向CRF请求计费规则，CRF向TPF返回选定的计费规则，TPF根据收到的计费规则对所述承载进行处理。9、根据权利要求1或2所述的方法，其特征在于，步骤B中所述承载信息为接入点名称，或为IP五元组，或为以上二者的组合。全文摘要本发明公开了一种基于分组数据流计费中的处理方法，该方法包含TPF中设置处理条件及对应于处理条件的处理方式，承载事件发生时，TPF判断承载信息是否与设置的处理条件相匹配，如果是，则TPF按照对应于匹配到的处理条件的处理方式对所述承载进行处理；否则，TPF对所述承载进行FBC控制处理，使得TPF能够直接对一部分承载进行计费处理，无需通过向CRF请求计费规则，并根据CRF的指示进行相应的计费处理。这样，由于TPF具有直接处理对承载的计费的机制，能够分流一部分CRF对承载计费的控制处理，降低了CRF和TPF之间的消息交互，有效避免CRF与TPF之间冗余消息的生成，并降低了新增特性对现有网络的影响，符合实际网络演进的需要。文档编号H04L12/14GK101159567SQ200710181490公开日2008年4月9日申请日期2005年1月20日优先权日2005年1月20日发明者段小琴申请人:华为技术有限公司