WO2006015543A1 - A processing method for re-authorization and re-authorization event and event triggers - Google Patents

Abstract

Providing a processing method for re-authorization, the method includes: CRF provides a re-authorization indication to TPF; TPF initiates re-authorization flow according to the received re-authorization indication. Also providing a processing method for re-authorization event and event triggers, the method includes: CRF receives internal or external event, then judges TPF whether need to initiate re-authorization flow, if so, CRF provides a re-authorization indication to TPF, TPF initiates re-authorization flow according to the received re-authorization indication. In accordance with the embodiments provided by the present invention, the service data flow based charging flow is consummated, and the interaction for the information between the FBC entities are decreased, so the resources between the FBC entities is saved, and the interaction flow for the information between the FBC entities become clear and explicit.

Description

 Method for processing re-authentication and re-authentication events and trigger events

Technical field

 The present invention relates to the field of packet data charging, and more particularly to a processing method for re-authenticating and re-authenticating events and triggering events based on packet data flow accounting. Background of the invention

 With the gradual wide application of packet data services, how to accurately and reasonably charge packet data services has become a common concern of operators.

 Figure 1 shows a packet data protocol context (PDP Context, Packet Data Protocol Context) activation, data transmission, deactivation flow diagram, as shown in Figure 1, in the General Packet Radio Service (GPRS, General Packet Radio Service), activated The PDP Context, the data interaction with the external packet data network (PDN, Packet Data Network), and the process of deactivating the PDP Context include the following steps:

Step 101: The mobile terminal (MS) sends a PDP Context Request (Active PDP Context Request) to the Serving GPRS Support Node (SGSN), where the Activate PDP Context Request carries the network layer service access point identifier. (NSAPI, Network Layer Service Access Point Identifier), PDP type, access point name (APN, Access Point Name), required quality of service (QoS) parameter, transaction identifier (TI, Transaction Identifier), etc., where NSAPI is The SGSN and the Gateway GPRS Support Node (GGSN) are used as part of the Tunnel Identifier (TID) to identify the PDP Context. The PDP type includes the end-to-end protocol (PPP, Peer- Peer Protocol type, Internet Protocol (IP) type, etc.; APN can be provided by the MS to the SGSN, and the SGSN is addressed to the corresponding GGSN according to the APN, the GGSN root The MS may not provide the APN to the SGSN according to the APN. The SGSN may select the default APN according to the subscription information of the MS user. The QoS parameter is the quality requirement of the packet data service specified by the MS. ΉUsed by the MS to identify a PDP context

 Step 102: After receiving the Activate PDP Context Request, the SGSN performs security check and encryption with the MS. This step is optional.

 Step 103: The SGSN parses the address information of the GGSN according to the APN. If the SGSN can parse the address information of the GGSN according to the APN, the TEID is created for the PDP Context, and the TEID can be an International Mobile Subscriber Identity (IMSI) and an NSAPI. The SGSN sends a PDP Context Request to the GGSN. The PDP Context Request contains the PDP type, PDP address, APN, QoS parameters, TEID, and selection mode. The PDP address can be MS. The IP address is an optional parameter. The PDP Context creation request may not carry the PDP address. In this case, the GGSN may assign an IP address to the MS in the subsequent processing, or may assign an IP to the MS by the PDN that finally establishes a connection with the MS. Address; The selection mode refers to the APN selection mode, that is, whether the APN is selected by the MS or selected by the SGSN. If the SGSN cannot resolve the address information of the GGSN according to the APN, the SGSN rejects the PDP Context activation request initiated by the MS.

Step 104: After receiving the PDP Context creation request, the GGSN determines an external PDN according to the APN, then allocates a Charging ID, initiates charging, and negotiates QoS. If the GGSN can meet the quality of service requirements of the QoS parameter, the SGSN sends the SGSN to the SGSN. The PDP Context Create Response (Representation PDP Context Response), which carries the TEID, the PDP address, the Backbone Bearer protocol, the agreed QoS parameters, and the Charging ID. If the GGSN cannot meet the quality of service requirements of the QoS parameters, the GGSN rejects the PDP Context creation request initiated by the SGSN. The SGSN then rejects the PDP Context activation request initiated by the MS.

 Step 105: After receiving the PDP Context creation response, the SGSN inserts NSAPI and GGSN address information for identifying the PDP Context in the PDP Context, and selects a radio priority according to the agreed QoS parameter, and then returns a PDP Context activation response to the MS (Activate PDP Context Accept ), the PDP Context activation response carries information such as PDP type, PDP address, Ή, agreed QoS parameters, wireless priority, PDP configuration options, and the like. And, the SGSN starts charging. After receiving the PDP Context activation response, the MS has established a direct route between the MS and the GGSN, and can perform packet data transmission.

 Step 106: The MS performs packet data interaction through the SGSN, the GGSN, and the PDN. Step 107: After ending the packet data interaction, the MS sends a PDP Context Deactivation Request (Deactivate PDP Context Request) to the SGSN, where the PDP Context Deactivation Request carries a defect.

 Step 108: After receiving the PDP Context deactivation request, the SGSN performs security check and encryption with the MS. This step is an optional step.

 Steps 109 to 111: The SGSN sends a PDP Context Request to the GGSN, and the PDP Context Delete Request carries the TEID.

After receiving the PDP Context deletion request, the GGSN ends the charging of the MS, deletes the PDP Context corresponding to the TEID, and then sends a PDP Context Response (DDP) to the SGSN. The PDP Context delete response carries the TEID. After receiving the PDP Context deletion response, the SGSN ends the charging of the MS, deletes the PDP Context corresponding to the TEID, and then sends a PDP Context Deactivation Response (Deactivate PDP Context Response) to the MS. The PDP Context deactivation response carries the TI. . After receiving the PDP Context deactivation response, the MS deletes the PDP Context corresponding to TI.

As can be seen from the implementation process described in FIG. 1, in the current GPRS charging system, since the starting point of charging is set when the PDP Context is activated, the charging termination point is set in the PDP Context. When deleting, it can only be charged according to the data traffic transmitted by the PDP Context, or according to the length of time the PDP Context is activated. However, in actual applications, after the MS interacts with the PDN, the MS can perform multiple services based on an activated PDP Context, that is, if the PDN can provide multiple services, such as email (email), Based on the WAP (Wireless Application Protocol) browsing service and the file transfer protocol (FTP) file transfer service, the MS can pass an activated PDP after establishing a transmission channel with the PDN. The Context carries various services that the PDN can provide. However, the charging mode of the operator for various services is likely to adopt different charging methods. For example, for the E-mail receiving and receiving service, the e-mail receiving and sending events may be triggered by the secondary charging, and the WAP browsing service may be based on the flow accounting fee. For the file transfer service, the rate of the WAP browsing service and the rate of the file transfer service are different according to the flow rate. Therefore, according to the existing GPRS charging system, different services carried by the same PDP Context cannot be performed at all. Perform differentiated billing.

In response to the above situation, the 3rd Generation Partnership Project (3GPP, 3rd Generation Partnership Project) is currently discussing how to implement FBC (Flow Based Charging). For a packet data service, when the user of the MS uses the service, all IP data streams (IP Flows) transmitted and received may also be IP packets, which are collectively referred to as Service Data Flow. ), that is, the service data stream is a set of multiple IP data streams, so the charging based on the IP data stream can truly reflect the occupation of resources by a certain service data stream. IP data stream-based charging can be considered as filtering out IP data streams of different services carried in the same PDP Context through filters of similar filters, and then separately charging IP data streams filtered by different filters. In order to achieve separate billing for different business data streams. In this way, the granularity of the IP data-based charging is much smaller than the charging granularity based on a PDP Context. The granularity can be regarded as the size of the screening hole. The charging granularity based on a PDP Context is a PDP Context. The meshing granularity based on the IP data stream is an IP service data stream is a sieve hole, that is, a plurality of sieve holes are included for one PDP Context, and therefore, the charging and ratio based on the IP data stream is based on Compared to the charging of a PDP Context, IP data stream based charging can provide operators or service providers with more abundant charging means.

 The 3GPP describes the system structure, functional requirements, and message interaction procedures of the FBC. The FBC system structure supporting online charging is shown in Figure 2A. The customized application based on mobile network enhanced logic (CAMEL, Customised Application for Mobile Network Enhanced Logic (SCP) Service Control Point (SCP) and Service Data Flow Based Credit Control Function (CCF) 202 constitute an online charging system (OCS, Online Charging System ) 206. The CCF 202 communicates with the Service Data Flow Based Charging Rule Function (CRF) 203 through the Ry interface, and the CRF 203 communicates with the Application Function (AF) through the R interface. The CRF 203 communicates with the Traffic Plane Function (TPF) 205 through the Gx interface, and the CCF 202 communicates with the TPF 205 through the Gy interface.

 The structure of the FBC system supporting offline charging is as shown in FIG. 2B. The CRF 203 communicates with the AF 204 through the Rx interface, the CRF 203 communicates with the TPF 205 through the Gx interface, and the TPF 205 communicates with the charging gateway function entity through the Gz interface (CGF, Charging). The Gateway Function 207 is interworking with a Charging Collection Function (CCF) 208.

The TPF 205 carries the IP data stream. When the bearer of the IP data stream is established, the TPF 205 sends a charging rule request to the CRF 203 through the Gx interface, where the charging rule request carries information related to the user and the MS, bearer characteristics, and Network related information, etc., wherein the information related to the user and the MS may be a mobile station international number (MSISDN), an international mobile subscriber identity (IMSI), etc., and the network related information may be a mobile network coding (MNC), a mobile country. Code (MCC), etc. In addition, since the bearer is modified during the IP data stream transmission process, such as renegotiating the QoS parameters, when the QoS parameters of the same service are different, the charging rules may be different, such as the corresponding rate of the QoS parameter falling. Also fell. At this time, the TPF 205 may resend the charging rule request to the CRF 203 to request a new charging rule when the bearer is modified; the CRF 203 selects an appropriate charging rule according to the above input information provided by the TPF 205, and returns to the TPF 205. The selected charging rule includes charging mechanism, charging type, charging key, service data flow filter, and charging rule priority. The charging mechanism may be online charging or offline charging; the charging type may be charging based on the length of time or based on data traffic; the charging key is a parameter related to the rate, and the CRF 203 may not directly The TPF 205 is provided with a rate, and only the rate-related parameters are provided to the TPF 205; the service data filter is used to indicate which IP data streams the TPF 205 filters, and then the TPF 205 filters the filtered IP data according to the charging rules. Billing. The service data filter may include an IP5 tuple, and the IP5 tuple may include source/destination IP address, source/destination port number (Port Number), protocol identifier (Protocol ID), and the like. For example, the CRF 203 indicates the TPF 205 to the source address. Filters the IP data stream of 10.0.0.1, the destination address is 10.0.0.2, the source/destination port number is 20, the protocol type is Transmission Control Protocol (TCP), and the filtered IP data stream is calculated according to the charging rule. fee.

 The CRF 203 may provide a trigger event (Event Trigger) to the TPF 205 to request the TPF 205 to request a new charging rule from the CRF 205 when a specific event occurs, such as the CRF 203 requesting the TPF 205 to perform an event modification on some bearers. At the time, a new charging rule is requested from the CRF 203. Trigger events can be thought of as events related to billing rules.

In addition to selecting an appropriate charging rule based on the input information provided by the TPF 205, the CRF 203 may also select an appropriate charging rule based on the input information of the AF 204 or the OCS 206, such as the AF 204 notifying the CRF 203 of the service currently used by the user. Type, CRF 203 selects the corresponding charging rule according to the type of service. The OCS 206 is composed of two functional entities, the SCP 201 and the CCF (Service Data Flow Based Credit Control Function) 202. The CCF (Service Data Flow Based Credit Control Function) 202 is a functional entity that performs credit control and is applied only to online charging. The system can be implemented by adding new functions to the existing OCS 206. In the online charging process, the CCF (Service Data Flow Based Credit Control Function) 202 manages and controls the user credit. When the user uses the service, the CCF (Service Data Flow Based Credit Control Function) 202 is in the user credit pool. The credit is authenticated, and the credit that the user can use is delivered to the TPF 205 through the Gy interface.

 In addition, the OCS 206 may request the TPF 205 to report to the re-authorisation triggers when they occur, and then the OCS 206 re-authenticates the user according to the corresponding re-authentication event reported by the TPF 205, and may recalculate the user. Credit. For example, after the user credit provided by the OCS 206 to the TPF 205 is used, the TPF 205 needs to report the allowed user credit usage expiration event to the OCS 206 according to the allowed credit expiration event in the re-authentication event, and the OCS 206 according to the remaining user account. Information, recalculate the credits allowed to be used by the user. For another example, in the case of sub-area charging, the OCS 206 determines the rate according to the current location of the user, and calculates the credit of the user according to the rate; when the user moves to another location, if the SGSN changes, the TPF 205 needs to re-examine the basis. The SGSN change event in the right event reports the occurrence of the SGSN change event to the OCS 206, and the OCS 206 re-determines the rate according to the current location of the user update, and recalculates the user's credit. For example, when the OCS 206 determines the rate according to the current QoS parameter of the service used by the user, when the user modifies the QoS parameter, the TPF 205 needs to report the occurrence of the bearer modification event to the OCS 206 according to the bearer modification event in the re-authentication event. The OCS 206 determines the rate based on the modified QoS parameters of the user and recalculates the credit of the user.

Corresponding to the GPRS network, the TPF 205 is a GGSN, the AF is a service gateway or a service server in the PDN, and the CRF 203 is a new logical entity. TPF 205 is the charging rule The enforcement point, CRF 203 is the control point of the charging rule.

 At present, when the 3GPP defines the bearer modification, in the case of online charging, the triggering event triggers the charging rule request process, that is, the TPF requests the charging rule from the CRF, and the triggering event triggers the TPF to request the charging rule from the CRF. As shown in Figure 3:

 Step 301: The user equipment (UE) sends a Modify Bearer Service Request to the TPF. In the GPRS network, the GGSN receives the PDP Context Request (Update PDP Context Request).

 Step 302: After receiving the bearer modification request, the TPF matches the bearer modification event with the pre-stored trigger event. If yes, go to step 303; otherwise, continue to monitor the trigger event.

 Step 303: The TPF sends a Request Charging Rule to the CRF, where the charging rule request carries the input information for determining the charging rule by the CRF.

 Steps 304 to 305: After receiving the charging rule request, the CRF may, according to the input information carried in the charging rule request, select an appropriate charging rule according to the related input information provided by the AF, and then return the provisioning to the TPF. Provision Charging Rules, which can be carried with the selected charging rules and charging rule operation instructions.

 Step 306: After receiving the charging rule, the TPF performs corresponding operations on the charging rule selected by the CRP according to the charging rule operation instruction.

 Step 307: The TPF returns a Modify Bearer Service Accept to the UE, and continues the subsequent bearer modification process.

 In the case of online charging, the bearer modification triggers the re-authentication process, that is, the TPF requests the OCS to re-authenticate the user. The specific implementation process is shown in Figure 4:

Step 401: The UE sends a Modify Bearer Service Request to the TPF. In the GPRS network, the GGSN receives the PDP Context Request (Update PDP Context Request). Step 402: After receiving the bearer modification request, the TPF matches the bearer modification event with the pre-stored re-authentication event. If yes, go to step 403. Otherwise, continue to monitor the occurrence of the re-authentication event.

 Step 403: The TPF sends a credit control request (Credit Control Request) to the OCS, where the credit control request carries the remaining credit of the user and related charging rule information, and requests the OCS to recalculate the credit of the user. The relevant charging rule information provided by the TPF to the OCS can be obtained from the CRF.

 Step 404: After receiving the credit control request, the OCS recalculates the credit of the user, and then returns a credit control response (Credit Control Answer) to the TPF. If the OCS calculates the credit of the user, the credit control response carries the OCS re The calculated user credit, if the OCS does not calculate the credit of the user, the credit control response may carry an error reason value.

 Step 405: After receiving the credit control response, the TPF returns a Modify Bearer Service Accept to the UE. If the credit control response carries the user's credit, the TPF accepts the bearer modification request initiated by the UE, and continues the subsequent bearer. Modifying the process; if the credit control response does not carry the user's credit, the UE-initiated bearer modification request is rejected.

 At present, the specification describes the charging mode of the CRF that controls the TPF through the triggering event reporting mechanism, that is, the TPF reports the trigger event to the CRF, and the CRF learns the change of the bearer through the trigger event reported by the TPF, and then determines the corresponding meter. The fee rules are issued to the TPF. The trigger events defined in the specification may include: SGSN change events, QoS changes events, RAT type change events, and transport stream template (TFT) changes ( TFT change) event.

In addition, the specification also describes how the OCS controls the credit usage of the TPF through the mechanism reported by the re-authentication event, that is, the TPF reports to the OCS after the re-authentication event occurs. The OCS obtains the credit usage of the user and the change of the bearer through the re-authentication event reported by the TPF, and recalculates the credit of the user and delivers the credit to the TPF. The re-authentication event defined in the specification may include: a credit authorization lifetime expiry event, a user idle state timeout event, a charging rule is changed event, and may also include some GPRS events. , such as SGSN change event, QoS parameter change event, RAT type change event.

 It can be seen from the above description that both the trigger event and the re-authentication event include GPRS events, such as SGSN change events, QoS parameter change events, RAT type change events, etc., so that for a certain GPRS event, the TPF will use the GPRS event. At the same time, the trigger event and the re-authentication event are matched. Therefore, the occurrence of the GPRS event needs to be reported to the CRF and the OCS, respectively, resulting in waste of resources of the FBC system. Summary of the invention

 In view of this, an object of the present invention is to provide a processing method for performing re-authentication, and another object of the present invention is to provide a method for processing a re-authentication event and a trigger event, which is improved based on packet data flow charging. Implement the process.

 In order to achieve the above object, the present invention provides a processing method for performing re-authentication, the method comprising the following steps:

 Al and CRF provide re-authentication indication to the TPF;

 Bl. According to the received re-authentication indication, the TPF initiates a re-authentication process.

 The step A1 further includes: the CRF receives an internal or external event, determines whether the TPF is required to initiate a re-authentication process, and if yes, performs step A1.

 The internal event is: The trigger event reported to the CRF when the TPF detects the trigger event.

The external event is: Input information provided by the OCS or AF to the CRF. The process of determining whether the TPF initiates the re-rights right is: determining whether the received event matches the obtained re-authentication event, and if yes, performing step A1.

 The determining whether the TPF needs to initiate the re-authentication process is: determining whether the event triggered by the received event matches the obtained re-authentication event, and if yes, performing step A1.

 The re-authentication event is: a re-authentication event configured in the CRF, or a re-authentication event provided by the OCS to the CRF, or a combination of the two.

 The re-authentication indication further includes: re-authentication event information.

 The TPF initiates the re-authentication process in step B1: The TPF requests the OCS to re-authenticate the user.

 The step B1 further includes: the TPF provides re-authentication event information to the OCS. The step B1 further includes: the OCS recalculates the credit of the user, and returns the recalculated user credit to the TPF.

 The present invention also provides a method for processing a re-authentication event and a trigger event, the method comprising the following steps:

 A2. The CRF receives an internal or external event, and determines whether the TPF needs to initiate a re-authentication process. If yes, step B2 is performed;

 B2, the CRF provides a re-authentication indication to the TPF, and according to the received re-authentication indication, the TPF initiates a re-authentication procedure.

 The internal event is: The event that the TPF reports to the CRF when the trigger event occurs.

 The external event is: Input information provided by the OCS or AF to the CRF.

 The trigger event is provided by the CRF to the TPF.

 The step B2 further includes: the TPF providing the trigger event reported to the CRF as re-authentication event information to the OCS.

The process of determining whether the TPF is required to initiate the re-authentication process in step A2 is as follows: Trigger event matches get re-authentication event, and if so, proceed to step B ^2.

 The re-authentication event is: a re-authentication event configured in the CRF, or a re-authentication event provided by the OCS to the CRF, or a combination of the two.

 The re-authentication indication further includes: re-authentication event information.

 The TPF initiates the re-authentication process in step B2 as follows: The TPF requests the OCS to re-authenticate the user.

 The step B2 further includes: the TPF providing re-authentication event information to the OCS. The step B2 further includes: the OCS recalculates the credit of the user, and returns the recalculated user credit to the TPF.

 The step B2 further includes: the OCS recalculates the credit of the user, and returns the recalculated user credit to the TPF.

 According to the method proposed by the present invention, the CRF determines whether the TPF is required to initiate a re-authentication process, and if necessary, the CRF instructs the TPF to request the OCS to re-authenticate the user. In addition, in the present invention, the TPF can only monitor the occurrence of a trigger event, and report to the CRF when the trigger event occurs, and the CRF determines whether the trigger event requires the TPF to initiate a re-authentication process; the CRF can also be based on external event information, such as OCS, The AF selects the input information from the charging rule provided by the CRF to determine whether the TPF needs to initiate the re-authentication process. According to the solution proposed by the present invention, the implementation process based on packet data flow charging is improved, the information interaction between the FBC entities is reduced, the resources between the FBC entities are greatly saved, and the information exchange process between the FBC entities is further improved. Clear and clear. BRIEF DESCRIPTION OF THE DRAWINGS

 Figure 1 shows the PDP Context activation, data transmission, deactivation flowchart; Figure 2A shows the structure of the FBC system supporting online charging;

2B is a structural diagram of an FBC system supporting offline charging; FIG. 3 is a flow chart showing a triggering rule triggered by a trigger event TPF to a CRF in the prior art;

 FIG. 4 is a flow chart showing a re-authentication of a TPF request OCS by a re-authentication event trigger in the prior art;

 FIG. 5 is a flow chart showing online charging when a trigger event occurs in the present invention; FIG.

 6 is a flow chart showing the OCS providing input information to the CRF in the present invention; FIG. 7 is a flow chart showing the online charging when the bearer is modified in the present invention;

 Fig. 8 is a flow chart showing the online charging of the CRF based on external input information in the present invention. Mode for carrying out the invention

 In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be further described in detail with reference to the accompanying drawings.

 In the present invention, the TPF only monitors the occurrence of the triggering event, and reports to the CRF when the triggering event occurs. The CRF determines whether the TPF needs to initiate the re-authentication process according to the triggering event reported by the TPF. If yes, the TPF is notified to request the OCS. Re-authenticate the user.

 FIG. 5 is a flowchart showing the online charging when the triggering event occurs in the present invention. As shown in FIG. 5, the online charging implementation process when the triggering event occurs includes the following steps:

 Step 501: The TPF monitors the occurrence of the trigger event to determine whether the currently occurring event matches the stored trigger event. If yes, go to step 502. Otherwise, continue to monitor the occurrence of the trigger event.

When the bearer is set up, the specific implementation process is as follows: In the online charging mode, when the bearer is established, the TPF sends a charging rule request to the CRF, where the charging rule request carries charging rule input information, such as UE information, network information, and the like. The CRF selects an appropriate charging rule according to the received revenue information, and the charging mechanism in the charging rule indicates "online charging". In addition, the CRF can further determine that the TPF needs to be monitored according to the input information provided by the TPF. trigger event, The charging rule and the triggering event are then sent to the TPF.

 When the bearer is modified, the CRF can also provide the TPF with a trigger event that requires it to be monitored. When the trigger event occurs, the CRF can continue to send a new trigger event to the TPF after receiving the trigger event reported by the TPF.

 When the CRF receives the input information provided by an external entity, such as AF or OCS, it can also provide the TPF with a trigger event that requires it to be monitored. That is, the CRF can actively send a trigger event to the TPF.

 After receiving the charging rules and triggering events provided by the CRF, the TPF monitors the occurrence of the triggering event, filters out the corresponding IP data stream according to the filter in the charging rule, and then applies the corresponding charging rule to filter. The outgoing IP data stream is charged. The TPF instructs "online charging" according to the charging mechanism in the charging rule, requests the user credit from the OCS, and the OCS calculates the credit of the user and returns it to the TPF.

 Step 502: The TPF sends a charging rule request to the CRF, where the charging rule request carries the input information for determining the charging rule by the CRF and the currently occurring trigger event.

 Step 503 to step 504: After receiving the charging rule request, the CRF may further select an appropriate charging rule according to the related input information provided by the AF according to the input information carried in the charging rule request, and the CRF is charged according to the charging. The triggering event carried in the rule request determines whether the re-authentication process needs to be triggered. If yes, the charging rule is returned to the TPF, and the provided charging rule carries the selected charging rule, the charging rule operation instruction, and Re-authentication indication, the re-authentication indication is used to notify the TPF to initiate a re-authentication process, requesting the OCS to re-authenticate the user, and further, the re-authentication indication may carry event information that triggers re-authentication, and is used for CRF via The TPF notifies the OCS of the reason for triggering the current re-authentication right; otherwise, the charging rule is returned to the TPF, and the provided charging rule carries only the selected charging rule and the charging rule operation indication.

Step 505: After receiving the charging rule, the TPF operates the indication according to the charging rule to the CRF. The selected charging rules are operated accordingly.

 Step 506: The TPF sends a credit control request to the OCS according to the re-authentication indication carried in the charging rule, where the credit control request carries the remaining credit of the user, and requests the OCS to recalculate the credit of the user. The credit control request may further carry event information that triggers the current re-authentication process in the re-authentication indication, to notify the OCS of the reason for triggering the current re-authentication.

 Step 507: After receiving the credit control request, the OCS recalculates the credit of the user, and then returns a credit control response to the TPF. If the OCS calculates the credit of the user, the credit control response carries the user credit recalculated by the OCS. If the OCS does not calculate the credit of the user, the credit control response may carry an error cause value.

 In addition, the CRF may not provide a re-authentication indication to the TPF. The TPF determines whether the OCS is required to re-authenticate the user according to the charging rule sent by the CRF. For example, the TPF determines whether the charging key in the charging rule changes. Or the TPF determines whether the filter in the charging rule changes.

 In the present invention, the CRF determines whether the TPF needs to initiate the re-authentication process: by pre-configuring the re-authentication event in the CRF, or by carrying the re-authentication event when the OCS provides the input information to the CRF, so that the CRF acquires the TPF. The event that initiates the re-authentication process is performed. Then, the CRF matches the obtained re-authentication event by the triggering event reported by the TPF. If the CRF can match, the CRF determines that the triggering event requires the TPF to initiate the re-authentication process. Otherwise, The CR determines that the trigger event does not require the TPF to initiate the re-authentication process. It can also determine whether the event triggered by the received event matches the obtained re-authentication event. For example, the received event can trigger the re-authentication event. For example, the CRF learns that the charging rule is modified into a re-authentication event. In the process of the user providing the service by using the AF, the AF can provide input information to the CRF, and the CRF selects a new charging rule according to the input information. At this time, the CRF receives The AF provides an input information event that triggers the charging rule to modify the SCA event.

Figure 6 is a flow chart showing the input of information from the OCS to the CRF in the present invention, as shown in Figure 6. As shown, the implementation of the OCS to provide input information to the CRF includes the following steps:

 Step 601: The OCS sends an OCS-related charging information to the CRF, where the information may further carry a re-authentication event that is sent to the TPF by the CRF.

 After the CRF receives the re-authentication event, the trigger event sent to the TPF may include a corresponding re-authentication event. At this time, the TPF may only monitor the trigger event and report it to the CRF when the trigger event occurs; The triggering event reported by the TPF determines whether the triggering event is a re-authentication event. Whether the TPF needs to initiate a re-authentication process requests the OCS to re-authenticate the user.

 Step 602: The CRF sends a response message to the OCS.

The following process is further described by using an application example as an example. For example, the charging rule is changed in the CRF, or the charging rule is changed when the OCS sends the OCS-related charging information to the CRF. There is a charging rule change re-authentication event. At this time, the CRF needs to trigger the re-authentication process when the charging rule changes. In addition, the operator performs sub-regional charging for the user, that is, the operator charges the user at different rates according to the range of the local area when the user uses the service. At this time, the TPF detects the SGSN in the trigger event. After the change event occurs, the CRF is reported to the CRF. Further, the TPF can provide the CRF with the address information of the SGSN where the user is currently located. The CRF learns the rate of the service used by the user in the current local area according to the SGSN change event and the address information of the SGSN where the user is currently located. Then, the charging rule is modified, such as modifying the charging key in the charging rule, and using the new charging button to indicate the current rate. In addition, the CRF determines that the SGSN change event causes a change in the charging rule. According to the re-authentication event information obtained by the CRF, the TPF needs to initiate a re-authentication process when the charging rule changes. The new charging rule and the re-authentication indication may further carry the re-authentication event information, such as the charging rule change, to notify the OCS via the TPF to trigger the reason of the current re-authentication right. The TPF filters out the filter based on the received charging rule (Filter). The corresponding IP data stream is then charged by the corresponding charging rule for the filtered IP data stream. The TPF requests the OCS to re-authenticate the user according to the re-authentication indication, and the OCS recalculates the credit of the user and returns to the TPF.

 FIG. 7 is a flowchart showing the online charging when the bearer is modified in the present invention. As shown in FIG. 7, the online charging implementation process when the bearer is modified includes the following steps:

 Step 701 to step 702 are basically the same as steps 301 to 302.

 Steps 703 to 708 are basically the same as steps 502 to 507.

 Step 709 is substantially the same as step 405.

 During online charging, when the user credit allocated by the OCS is exhausted by the TPF, the OCS reports and requests a new user credit mechanism, so that the OCS can know the usage of the service by the user, such as the length of time that the user uses a certain service. , or data traffic that occurs when a user uses a service. In order to encourage users to use more services, operators can use some preferential charging policies to attract users. For example, when the accumulated time length of a certain service is reached, the data traffic of a certain service reaches a certain value. At this time, the rate of the corresponding service is adjusted to the preferential rate. At this time, the OCS can provide the CRF with input information for determining the charging rule, and notify the CRF to use the new service rate for the user to use the corresponding service. . The CRF selects an appropriate charging rule and sends it to the TPF according to the input information of the charging rule provided by the OCS.

 In addition, the AF may also provide the CRF with input information for determining the charging rule. For example, a service uses time-sharing charging, for example, the rate of the user using the service is different at different times on the same day, and the AF determines that the user uses a certain service to enter. At the time of the preferential period, at this time, the AF may provide the CRF with input information for determining the charging rule, and notify the CRF to use the new service rate for the user to use the corresponding service for charging. The CRF selects the appropriate charging rule and sends it to the TPF based on the input information of the charging rule provided by the AF.

In the present invention, in the case of online charging, when the CRF is received from the outside, it is used for determining The input information of the fee rule can be used to deliver the appropriate charging rule to the TPF, and the CRF can determine whether the TPF needs to initiate the re-authentication process according to the input information. If necessary, the re-authentication indication is sent to the TPF, and the specific implementation is implemented. The process is shown in Figure 8:

 Step 801: The CRF receives an internal or external Trigger Event and information related to the event, such as an event in which the AF or OCS sends a charging rule selection input information to the CRF.

 Step 802: The CRF selects an appropriate charging rule according to the obtained input information. The input information may be the charging related input information provided by the AF. For example, the user uses a certain service provided by the AF, and the service has special requirements for charging, for example, the charging rate is different from the charging rate of other services, so The AF provides the CRF with the charging input information related to the service; the charging related input information provided by the TPF; or the charging related input information provided by the OCS; and the CRF determines whether the TPF needs to initiate the re-authentication The process, if necessary, in step 803, the re-authentication indication is sent to the TPF, and the re-authentication indication may further carry the re-authentication event information, so as to notify the OCS via the TPF to trigger the current re-authentication reason. Otherwise, In step 803, the re-authentication indication is not required to be sent to the TPF, and steps 805 to 806 may be omitted.

 Step 803: If the charging rule changes, the CRF sends a charging rule to the TPF, where the charging rule can carry the selected charging rule, the charging rule operation indication, and the re-authentication indication.

 Step 804: After receiving the charging rule, the TPF performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation indication.

Step 805: The TPF sends a credit request (Credit Request) to the OCS according to the re-authentication indication carried in the provided charging rule, where the credit request carries the remaining credit of the user and related new charging rule information. Request OCS to recalculate the user's credit. The re-authentication event information carried in the re-authentication indication may be further carried in the credit request to notify the OCS of the reason for triggering the current re-authentication right. Step 806: After receiving the credit request, the OCS recalculates the credit of the user, and then returns a credit response (Credit Response) to the TPF. If the OCS calculates the credit of the user, the credit response carries the user credit recalculated by the OCS. If the OCS does not calculate the credit of the user, the credit response may carry an error reason value.

 In summary, the above description is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention.

Claims

Claim  A method for processing re-authentication, characterized in that the method comprises the following steps: Al, CRF provide re-authentication indication to the TPF;  Bl. According to the received re-authentication indication, the TPF initiates a re-authentication process.  2. The method according to claim 1, wherein the step A1 further comprises: the CRF receiving an internal or external event, determining whether the TPF is required to initiate a re-authentication process, and if yes, performing step A1.  The method according to claim 2, wherein the internal event is: a trigger event reported by the TPF to the CRF when the trigger event occurs.  4. The method according to claim 2, wherein the external event is: input information provided by the OCS or the AF to the CR.  The method according to claim 2, wherein the determining whether the TPF is required to initiate the re-authentication process is: determining whether the received event matches the obtained re-authentication event, and if yes, performing step A1.  The method according to claim 2, wherein the determining whether the TPF needs to initiate the re-authentication process is: determining whether the event triggered by the received event matches the obtained re-authentication event, and if yes, executing Step Al.  The method according to claim 5, wherein the re-authentication event is: a re-authentication event configured in the CRF, or a re-authentication event provided by the OCS to the CRF, or a combination of the two.  The method according to claim 5, wherein the re-authentication indication further comprises: re-authentication event information. The method according to claim 8, wherein the TPF initiates a re-authentication process in step B1: the TPF requests the OCS to re-authenticate the user. 10. The method according to claim 7, wherein the step B1 further comprises: the TPF providing re-authentication event information to the OCS.  The method according to claim 7, wherein the step B1 further comprises: the OCS recalculating the credit of the user, and returning the recalculated user credit to the TPF.  12. A method for processing a re-authentication event and a triggering event, characterized in that the method comprises the following steps:  A2. The CRF receives an internal or external event, and determines whether the TPF needs to initiate a re-authentication process. If yes, step B2 is performed;  B2, the CRF provides a re-authentication indication to the TPF, and according to the received re-authentication indication, the TPF initiates a re-authentication procedure.  The method according to claim 12, wherein the internal event is: an event reported by the TPF to the CRF when the trigger event occurs.  14. The method according to claim 12, wherein the external event is: input information provided by the OCS or AF to the CRF.  The method according to claim 13, wherein the trigger event is provided by the CRF to the TPF.  The method according to claim 13, wherein the step B2 further comprises: the TPF providing the trigger event reported to the CRF as re-authentication event information to the ocs.  The method according to claim 12, wherein the determining, in step A2, whether the TPF needs to initiate a re-authentication process is: determining whether the triggered event matches the acquired re-authentication event, and if so, executing Step B2. The method according to claim 17, wherein the re-authentication event is: a re-authentication event configured in the CRF, or a re-authentication event provided by the OCS to the CRF, or more a combination of the two.  The method according to claim 17, wherein the re-authentication indication further comprises: re-authentication event information.  The method according to claim 19, wherein the TPF initiates a re-authentication process in step B2: the TPF requests the OCS to re-authenticate the user.  The method according to claim 20, wherein the step B2 further comprises: the TPF providing re-authentication event information to the OCS.  22. The method according to claim 19, wherein the step B2 further comprises: the OCS recalculating the credit of the user and returning the recalculated user credit to the TPF.  The method according to claim 12, wherein the step B2 further comprises: the OCS recalculating the credit of the user, and returning the recalculated user credit to the TPF.