CN1735023A - 一种进行重鉴权及重鉴权事件和触发事件的处理方法 - Google Patents

Abstract

本发明公开了一种进行重鉴权的处理方法，该方法包含：CRF向TPF提供重鉴权指示；TPF根据收到的重鉴权指示，发起重鉴权流程。本发明还公开了一种重鉴权事件和触发事件的处理方法，该方法包含：CRF收到内部或外部的事件，判断是否需要TPF发起重鉴权流程，如果是，则CRF向TPF提供重鉴权指示，根据收到的重鉴权指示，TPF发起重鉴权流程。根据本发明提出的方案，完善了基于分组数据流计费的实现流程，减少了FBC各实体间的信息交互，大大节省了FBC各实体间的资源，使得FBC各实体间的信息交互流程更为清晰、明确。

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返回选定的计费规则，计费规则中包括计费机制、计费类型、计费键、业务数据流过滤器、计费规则优先级等信息。其中，计费机制可为采用在线计费还是离线计费；计费类型可为基于时间长度进行计费还是基于数据流量进行计费；计费键是与费率相关的参数，CRF 203可不直接向TPF 205提供费率，而只是向TPF 205提供与费率相关的参数；业务数据过滤器用于指示TPF 205对哪些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请求新的计费规则。触发事件可视为与计费规则相关的事件。

CRF 203除了根据TPF 205提供的输入信息选择适当的计费规则之外，CRF 203还可根据AF 204或OCS 206的输入信息选择适当的计费规则，如AF 204通知CRF 203用户当前使用的业务类型，CRF 203根据该业务类型选择相应的计费规则。

OCS 206由SCP 201和CCF(Service Data Flow Based Credit ControlFunction)202两个功能实体组成，其中，CCF(Service Data Flow Based CreditControl Function)202是执行信用控制的功能实体，仅应用于在线计费系统，可通过在现有的OCS 206中增加新的功能来实现。在在线计费过程中，CCF(Service Data Flow Based Credit Control Function)202对用户信用进行管理和控制，当用户使用业务时，CCF(Service Data Flow Based Credit ControlFunction)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根据用户当前所在位置确定费率，并根据该费率计算用户的信用；当用户移动至另一位置时，如SGSN发生变化，TPF 205需要根据重鉴权事件中的SGSN变化事件，向OCS 206上报SGSN变化事件的发生，OCS206根据用户更新后的当前所在位置重新确定费率，并重新计算用户的信用。又例如，当OCS 206根据用户使用业务的当前QoS参数确定费率，当用户对QoS参数进行修改，TPF 205需要根据重鉴权事件中的承载修改事件，向OCS 206上报承载修改事件的发生，OCS 206根据用户修改后的QoS参数确定费率，并重新计算用户的信用。

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

目前，3GPP定义了承载修改时，在线计费情况下，触发事件触发的TPF向CRF请求计费规则的处理过程如图3所示：

步骤301：用户设备(UE)向TPF发送承载修改请求(Modify BearerService Request)，在GPRS网络中，则是GGSN收到PDP Context更新请求(Update PDP Context Request)。

步骤302：TPF收到承载修改请求后，将承载修改事件与预先存储的触发事件相匹配，如果能够匹配，则执行步骤303；否则，继续监测触发事件的发生。

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

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

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

步骤307：TPF向UE返回承载修改响应(Modify Bearer Service Accept)，并继续后续的承载修改流程。

对于在线计费情况下，承载修改会触发TPF请求OCS进行重鉴权的流程，具体实现过程如图4所示：

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

步骤402：TPF收到承载修改请求后，将承载修改事件与预先存储的重鉴权事件进行匹配，如果能够匹配，则执行步骤403，否则，继续监测重鉴权事件的发生。

步骤403：TPF向OCS发送信用控制请求(Credit Control Request)，该信用控制请求中携带有用户的剩余信用和相关的计费规则信息，请求OCS重新计算用户的信用。TPF向OCS提供的相关计费规则信息可来自CRF。

步骤404：OCS收到信用控制请求后，重新对用户的信用进行计算，然后向TPF返回信用控制响应(Credit Control Answer)，如果OCS计算出用户的信用，则该信用控制响应中携带有OCS重新计算的用户信用，如果OCS未计算出用户的信用，则该信用控制响应中可携带有差错原因值。

步骤405：TPF收到信用控制响应后，向UE返回承载修改响应(ModifyBearer Service Accept)，如果信用控制响应中携带有用户的信用，则TPF接受UE发起的承载修改请求，并继续后续的承载修改流程；如果信用控制响应中未携带有用户的信用，则拒绝UE发起的承载修改请求。

目前，规范中对CRF通过触发事件上报机制控制TPF的计费方式进行了描述，即TPF监测到触发事件发生后向CRF上报，CRF通过TPF上报的触发事件获知承载发生变化，然后确定相应的计费规则并下发给TPF。规范中定义的触发事件可包括：SGSN变化(SGSN 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)事件，还可包括一些GPRS事件，如SGSN变化事件，QoS参数改变事件，RAT类型改变事件。

通过以上描述可见，触发事件和重鉴权事件中都包括GPRS事件，如SGSN变化事件、QoS参数改变事件、RAT类型改变事件等，这样，对于某个发生的GPRS事件，TPF会将该GPRS事件同时匹配到触发事件和重鉴权事件，因此，需要分别向CRF和OCS上报该GPRS事件的发生，造成对FBC系统资源的浪费。

发明内容

有鉴于此，本发明的一个目的在于提供一种进行重鉴权的处理方法，本发明的另一目的在于提供一种重鉴权事件和触发事件的处理方法，完善基于分组数据流计费的实现流程。

为了达到上述目的，本发明提供了一种进行重鉴权的处理方法，该方法包含以下步骤：

A1、CRF向TPF提供重鉴权指示；

B1、根据收到的重鉴权指示，TPF发起重鉴权流程。

所述步骤A1之前进一步包括：CRF收到内部或外部的事件，判断是否需要TPF发起重鉴权流程，如果是，则执行步骤A1。

所述内部事件为：TPF监测到触发事件发生时，向CRF上报的触发事件。

所述外部事件为：OCS或AF向CRF提供的输入信息。

所述判断是否需要TPF发起重鉴权流程为：判断接收到的事件是否匹配获取的重鉴权事件，如果是，则执行步骤A1。

所述判断是否需要TPF发起重鉴权流程为：判断接收到的事件引发的事件是否匹配获取的重鉴权事件，如果是，则执行步骤A1。

所述重鉴权事件为：CRF中配置的重鉴权事件，或OCS向CRF提供的重鉴权事件，或以上二者的组合。

所述重鉴权指示中进一步包括：重鉴权事件信息。

步骤B1中所述TPF发起重鉴权流程为：TPF请求OCS对用户进行重鉴权。

所述步骤B1中进一步包括：TPF向OCS提供重鉴权事件信息。

所述步骤B1之后进一步包括：OCS重新对用户的信用进行计算，并向TPF返回重新计算后的用户信用。

本发明还提供了一种重鉴权事件和触发事件的处理方法，该方法包含以下步骤：

A2、CRF收到内部或外部的事件，判断是否需要TPF发起重鉴权流程，如果是，则执行步骤B2；

B2、CRF向TPF提供重鉴权指示，根据收到的重鉴权指示，TPF发起重鉴权流程。

所述内部事件为：TPF监测到触发事件发生时，向CRF上报的事件。

所述外部事件为：OCS或AF向CRF提供的输入信息。

所述触发事件是由CRF向TPF提供的。

所述步骤B2进一步包括：TPF将上报给CRF的触发事件作为重鉴权事件信息提供给OCS。

步骤A2中所述判断是否需要TPF发起重鉴权流程为：判断发生的触发事件是否匹配获取的重鉴权事件，如果是，则执行步骤B2。

所述重鉴权事件为：CRF中配置的重鉴权事件，或OCS向CRF提供的重鉴权事件，或以上二者的组合。

所述重鉴权指示中进一步包括：重鉴权事件信息。

步骤B2中所述TPF发起重鉴权流程为：TPF请求OCS对用户进行重鉴权。

所述步骤B2中进一步包括：TPF向OCS提供重鉴权事件信息。

所述步骤B2之后进一步包括：OCS重新对用户的信用进行计算，并向TPF返回重新计算后的用户信用。

所述步骤B2之后进一步包括：OCS重新对用户的信用进行计算，并向TPF返回重新计算后的用户信用。

根据本发明提出的方法，由CRF确定是否需要TPF发起重鉴权流程，如果需要，则CRF指示TPF请求OCS对用户进行重鉴权。另外，本发明中，TPF可仅监测触发事件的发生，在触发事件发生时向CRF上报，由CRF确定该触发事件是否需要TPF发起重鉴权流程；CRF也可根据外部事件信息，如OCS、AF向CRF提供的计费规则选择输入信息，确定是否需要TPF发起重鉴权流程。根据本发明提出的方案，完善了基于分组数据流计费的实现流程，减少了FBC各实体间的信息交互，大大节省了FBC各实体间的资源，使得FBC各实体间的信息交互流程更为清晰、明确。

附图说明

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

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

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

图3示出了现有技术中触发事件触发TPF向CRF请求计费规则流程图；

图4示出了现有技术中重鉴权事件触发TPF请求OCS进行重鉴权流程图；

图5示出了本发明中触发事件发生时的在线计费流程图；

图6示出了本发明中承载修改时的在线计费流程图；

图7示出了本发明中CRF根据外部输入信息的在线计费流程图；

图8示出了本发明中OCS向CRF提供输入信息的流程图。

具体实施方式

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

本发明中，TPF仅对触发事件的发生进行监测，在触发事件发生时向CRF上报，由CRF根据TPF上报的触发事件，确定是否需要TPF发起重鉴权流程，如果是，则通知TPF请求OCS对用户进行重鉴权。

图5示出了本发明中触发事件发生时的在线计费流程图，如图5所示，触发事件发生时的在线计费实现过程包括以下步骤：

步骤501：TPF对触发事件的发生进行监测，判断当前发生的事件与存储的触发事件是否匹配，如果匹配，则执行步骤502，否则，继续监测触发事件的发生。

承载建立时，具体实现过程如下：在线计费情况下，承载建立时，TPF向CRF发送计费规则请求，该计费规则请求中携带有计费规则输入信息，如UE的信息、网络信息等，CRF根据收到的收入信息选择适当的计费规则，该计费规则中的计费机制指示为“在线计费”，另外，CRF根据TPF提供的输入信息，可进一步确定需要TPF进行监测的触发事件，然后将计费规则和触发事件下发给TPF。

承载修改时，CRF也可向TPF提供要求其进行监测的触发事件，即当触发事件发生时，CRF收到TPF上报的触发事件后，可继续向TPF下发新的触发事件。

当CRF接收到外部实体，如AF、OCS，提供的输入信息后，也可向TPF提供要求其进行监控的触发事件，即CRF可以主动地向TPF下发触发事件。

TPF收到CRF提供的计费规则和触发事件后，对触发事件的发生进行监测，并根据计费规则中的过滤器(Filter)过滤出相应的IP数据流，然后应用相应计费规则对过滤出的IP数据流进行计费。TPF根据计费规则中的计费机制指示“在线计费”，向OCS请求用户信用，OCS对用户的信用进行计算并向TPF返回。

步骤502：TPF向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息和当前发生的触发事件。

步骤503～步骤504：CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可进一步根据AF提供的相关输入信息，选择适当的计费规则，并且CRF根据计费规则请求中携带的触发事件，判断是否需要触发重鉴权流程，如果是，则向TPF返回提供计费规则，该提供计费规则中携带有选定的计费规则、计费规则操作指示和重鉴权指示，重鉴权指示用于通知TPF发起重鉴权流程，请求OCS对用户进行重鉴权，进一步地，重鉴权指示中可携带触发重鉴权的事件信息，用于CRF经由TPF通知OCS触发当前重鉴权的原因；否则，向TPF返回提供计费规则，该提供计费规则中仅携带有选定的计费规则和计费规则操作指示。

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

步骤506：TPF根据提供计费规则中携带的重鉴权指示，向OCS发送信用控制请求，该信用控制请求中携带有用户的剩余信用，请求OCS重新计算用户的信用。信用控制请求中可进一步携带有重鉴权指示中触发当前重鉴权流程的事件信息，用以通知OCS触发当前重鉴权的原因。

步骤507：OCS收到信用控制请求后，重新对用户的信用进行计算，然后向TPF返回信用控制响应，如果OCS计算出用户的信用，则该信用控制响应中携带有OCS重新计算的用户信用，如果OCS未计算出用户的信用，则该信用控制响应中可携带有差错原因值。

另外，CRF也可不向TPF提供重鉴权指示，由TPF根据CRF下发的计费规则，判断是否需要请求OCS对用户进行重鉴权，如TPF判断计费规则中的计费键是否变化，或TPF判断计费规则中的过滤器是否变化。

本发明中，CRF判断是否需要TPF发起重鉴权流程可为：通过在CRF中预先配置重鉴权事件，或是通过OCS向CRF提供输入信息时携带重鉴权事件，使得CRF获取到需要TPF发起重鉴权流程的事件，然后，CRF通过对TPF上报的触发事件与获取到的重鉴权事件进行匹配，如果能够匹配，则CRF判断出该触发事件需要TPF发起重鉴权流程，否则，CRF判断出该触发事件不需要TPF发起重鉴权流程；也可为判断收到的事件所引发的事件是否匹配获取的重鉴权事件，如收到的事件能够引发重鉴权事件的发生。如，CRF获知计费规则修改为重鉴权事件，在用户使用AF提供业务的过程中，AF可向CRF提供输入信息，CRF根据该输入信息选择新的计费规则，此时，CRF收到的AF提供输入信息事件则引发了计费规则修改重鉴权事件。

图8示出了本发明中OCS向CRF提供输入信息的流程图，如图8所示，OCS向CRF提供输入信息的实现过程包括以下步骤：

步骤801：OCS向CRF发送OCS相关的计费信息，该信息中可进一步携带需要CRF下发给TPF的重鉴权事件。

CRF接收到重鉴权事件后，向TPF下发的触发事件中可包含相应的重鉴权事件，此时，TPF可仅对触发事件进行监测，并在触发事件发生时向CRF上报；CRF根据TPF上报的触发事件，判断该触发事件是否为重鉴权事件，是否需要TPF发起重鉴权流程，请求OCS对用户进行重鉴权。

步骤802：CRF向OCS发送响应消息。

下面以一应用实例为例对上述过程作进一步描述，例如，在CRF中预先配置计费规则变化重鉴权事件(charging rule is changed)，或是OCS向CRF发送OCS相关的计费信息时携带有计费规则变化重鉴权事件，此时，CRF获知计费规则发生变化时需要TPF发起重鉴权流程。另外，运营商对用户进行分区域计费，即运营商根据用户使用业务时所在地域范围的不同，对用户采用不同的费率进行计费，此时，TPF监测到触发事件中的SGSN变化事件发生后上报给CRF，进一步地，TPF可向CRF提供用户当前所在SGSN的地址信息，CRF根据SGSN变化事件及用户当前所在SGSN的地址信息，获知用户在当前所在地域范围使用业务的费率，然后对计费规则进行修改，如对计费规则中的计费键(charging key)进行修改，使用新的计费键来指示当前费率。并且，CRF判断出该SGSN变化事件引起了计费规则的改变，根据CRF获取到的重鉴权事件信息，计费规则发生变化时需要TPF发起重鉴权流程，此时，CRF向TPF下发新的计费规则以及重鉴权指示，该重鉴权指示中可进一步携带有重鉴权事件信息，如计费规则改变，用以经由TPF通知OCS触发当前重鉴权的原因。TPF根据收到的计费规则中的过滤器(Filter)过滤出相应的IP数据流，然后应用相应计费规则对过滤出的IP数据流进行计费。TPF根据重鉴权指示，请求OCS对用户进行重鉴权，OCS对用户的信用重新进行计算并向TPF返回。

图6示出了本发明中承载修改时的在线计费流程图，如图6所示，承载修改时的在线计费实现过程包括以下步骤：

步骤601～步骤602与步骤301～步骤302基本相同。

步骤603～步骤608与步骤502～步骤507基本相同。

步骤609与步骤405基本相同。

在线计费时，通过TPF在OCS分配的用户信用用尽时，向OCS上报并请求新的用户信用机制，使得OCS能够获知用户对某一业务的使用情况，如用户使用某一业务的时间长度，或用户使用某一业务时发生的数据流量。运营商为鼓励用户更多地使用业务，可采用一些优惠的计费政策来吸引用户，如用户使用某一业务的累积时间长度达到一定值时，或用户使用某一业务的数据流量达到一定值时，对该用户使用相应业务的费率进行调整为优惠费率，此时，OCS可向CRF提供确定计费规则的输入信息，通知CRF对该用户使用相应业务采用新的费率进行计费。CRF根据OCS提供的确定计费规则的输入信息，选择适当的计费规则并下发给TPF。

另外，AF也可向CRF提供确定计费规则的输入信息，例如，某业务使用分时计费，如在同一天的不同时段用户使用该业务的费率不同，当AF确定用户使用某业务进入优惠时段时，此时，AF可向CRF提供确定计费规则的输入信息，通知CRF对该用户使用相应业务采用新的费率进行计费。CRF根据AF提供的确定计费规则的输入信息，选择适当的计费规则并下发给TPF。

本发明中，在线计费情况下，当CRF收到来自外部的、用于确定计费规则的输入信息，可向TPF主动下发适当的计费规则，并且，CRF可根据输入信息确定是否需要TPF发起重鉴权流程，如果需要，则向TPF下发重鉴权指示，具体实现过程如图7所示：

步骤701：CRF收到某个内部或外部的事件(Internal or External TriggerEvent)，以及与该事件相关的信息，如AF或OCS向CRF发送计费规则选择输入信息的事件。

步骤702：CRF根据获取的输入信息选择适当的计费规则。这些输入信息可为AF提供的计费相关输入信息，例如，用户使用AF提供的某一业务，该业务对计费有特殊要求，如计费费率与其他业务的计费费率不同，因此，AF向CRF提供与该业务相关的计费输入信息；也可为TPF提供的计费相关输入信息；也可为OCS提供的计费相关输入信息；并且，CRF判断是否需要TPF发起重鉴权流程，如果需要，则步骤703中需要向TPF下发重鉴权指示，重鉴权指示中可进一步携带有重鉴权事件信息，用以经由TPF通知OCS触发当前重鉴权的原因，否则，步骤703中无需向TPF下发重鉴权指示，且步骤705～步骤706可省略。

步骤703：如果计费规则发生变化，CRF向TPF发送提供计费规则，该提供计费规则中可携带有选定的计费规则、计费规则操作指示和重鉴权指示。

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

步骤705：TPF根据收到的提供计费规则中携带的重鉴权指示，向OCS发送信用请求(Credit Request)，该信用请求中携带有用户的剩余信用和相关的新的计费规则信息，请求OCS重新计算用户的信用。信用请求中可进一步携带有重鉴权指示中携带的重鉴权事件信息，用以通知OCS触发当前重鉴权的原因。

步骤706：OCS收到信用请求后，重新对用户的信用进行计算，然后向TPF返回信用响应(Credit Response)，如果OCS计算出用户的信用，则该信用响应中携带有OCS重新计算的用户信用，如果OCS未计算出用户的信用，则该信用响应中可携带有差错原因值。

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

Claims (23)

1、一种进行重鉴权的处理方法，其特征在于，该方法包含以下步骤：

A1、CRF向TPF提供重鉴权指示；

B1、根据收到的重鉴权指示，TPF发起重鉴权流程。

2、根据权利要求1所述的方法，其特征在于，所述步骤A1之前进一步包括：CRF收到内部或外部的事件，判断是否需要TPF发起重鉴权流程，如果是，则执行步骤A1。

3、根据权利要求2所述的方法，其特征在于，所述内部事件为：TPF监测到触发事件发生时，向CRF上报的触发事件。

4、根据权利要求2所述的方法，其特征在于，所述外部事件为：OCS或AF向CRF提供的输入信息。

5、根据权利要求2所述的方法，其特征在于，所述判断是否需要TPF发起重鉴权流程为：判断接收到的事件是否匹配获取的重鉴权事件，如果是，则执行步骤A1。

6、根据权利要求2所述的方法，其特征在于，所述判断是否需要TPF发起重鉴权流程为：判断接收到的事件引发的事件是否匹配获取的重鉴权事件，如果是，则执行步骤A1。

7、根据权利要求5所述的方法，其特征在于，所述重鉴权事件为：CRF中配置的重鉴权事件，或OCS向CRF提供的重鉴权事件，或以上二者的组合。

8、根据权利要求5所述的方法，其特征在于，所述重鉴权指示中进一步包括：重鉴权事件信息。

9、根据权利要求8所述的方法，其特征在于，步骤B1中所述TPF发起重鉴权流程为：TPF请求OCS对用户进行重鉴权。

10、根据权利要求7所述的方法，其特征在于，所述步骤B1中进一步包括：TPF向OCS提供重鉴权事件信息。

11、根据权利要求7所述的方法，其特征在于，所述步骤B1之后进一步包括：OCS重新对用户的信用进行计算，并向TPF返回重新计算后的用户信用。

12、一种重鉴权事件和触发事件的处理方法，其特征在于，该方法包含以下步骤：

A2、CRF收到内部或外部的事件，判断是否需要TPF发起重鉴权流程，如果是，则执行步骤B2；

B2、CRF向TPF提供重鉴权指示，根据收到的重鉴权指示，TPF发起重鉴权流程。

13、根据权利要求12所述的方法，其特征在于，所述内部事件为：TPF监测到触发事件发生时，向CRF上报的事件。

14、根据权利要求12所述的方法，其特征在于，所述外部事件为：OCS或AF向CRF提供的输入信息。

15、根据权利要求13所述的方法，其特征在于，所述触发事件是由CRF向TPF提供的。

16、根据权利要求13所述的方法，其特征在于，所述步骤B2进一步包括：TPF将上报给CRF的触发事件作为重鉴权事件信息提供给OCS。

17、根据权利要求12所述的方法，其特征在于，步骤A2中所述判断是否需要TPF发起重鉴权流程为：判断发生的触发事件是否匹配获取的重鉴权事件，如果是，则执行步骤B2。

18、根据权利要求17所述的方法，其特征在于，所述重鉴权事件为：CRF中配置的重鉴权事件，或OCS向CRF提供的重鉴权事件，或以上二者的组合。

19、根据权利要求17所述的方法，其特征在于，所述重鉴权指示中进一步包括：重鉴权事件信息。

20、根据权利要求19所述的方法，其特征在于，步骤B2中所述TPF发起重鉴权流程为：TPF请求OCS对用户进行重鉴权。

21、根据权利要求20所述的方法，其特征在于，所述步骤B2中进一步包括：TPF向OCS提供重鉴权事件信息。

22、根据权利要求19所述的方法，其特征在于，所述步骤B2之后进一步包括：OCS重新对用户的信用进行计算，并向TPF返回重新计算后的用户信用。

23、根据权利要求12所述的方法，其特征在于，所述步骤B2之后进一步包括：OCS重新对用户的信用进行计算，并向TPF返回重新计算后的用户信用。

Images