WO2006050670A1

WO2006050670A1 - A method for processing a charging key

Info

Publication number: WO2006050670A1
Application number: PCT/CN2005/001898
Authority: WO
Inventors: Xiaoqin Duan
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2004-11-10
Filing date: 2005-11-10
Publication date: 2006-05-18
Also published as: CN1773921A; CN100438412C

Abstract

A method for processing a charging key includes: in the case of the online charging, when the TPF creates the charging rules, it determines whether the TPF has requested the credit threshold relative to the charging key to the OCS according to the charging key of the charging rules, if not, the TPF sends the Credit Request to the OCS; when the TPF deletes the charging rules, according to the charging key of the charging rules, it determines whether there are the charging rules except for the charging rules needed to be deleted using the credit threshold requested relative to the charging key, if not, the TPF returns the remain credit threshold relative to the charging key to the OCS; otherwise, the OCS provides the re-authorization event relative to the charging key to the TPF, when the TPF monitors the re-authorization event occurring, it returns the credit threshold to the OCS which is remained after the charging key corresponding to the re-authorization event consumes the credit threshold. The solution of the invention can decrease effectively the interaction between the TPF and the OCS, increase the processing capability of the TPF and the OCS, and enhance the practicality of the processing course of the whole online charging.

Description

Method for processing billing key

Technical field

The present invention relates to the field of packet data charging, and more particularly to a method for processing a charging rule by a transport plane functional entity. Background of the invention

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

FIG. 1 shows a packet data protocol context (PDP Context, Packet Data Protocol Context) activation, a data transmission, and a deactivation flowchart. As shown in FIG. 1, in a general packet radio service (GPRS), The process of activating PDP Contexts to interact with an external packet data network (PDN, Packet Data Network) and deactivating the PDP Context includes 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. Information (NSAPI, Network Layer Service Access Point Identifier), PDP type, Access Point Name (APN, Access Point Name), required Quality of Service (QoS) parameters, Transaction Identifier (TI), etc., where NSAPI 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, and the GGSN 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. TI is used for MS identification of 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 AP, the TEID is created for the PDP Context, and the TEED can be an International Mobile Subscriber Identity (MSI) 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 identifier (Charging ED), starts charging, and negotiates QoS. If the GGSN can meet the quality of service requirements of the QoS parameter, The SGSN returns a PDP Context Response (Create PDP Context Response), and the PDP Context creation response carries information such as a TEID, a PDP address, a Backbone Bearer protocol, an agreed QoS parameter, and a 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 an NSAPI and GGSN address information for identifying the PDP Context in the PDP Context, and then 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, T-defined QoS parameters, wireless priority, and PDP configuration options. And, the SGSN starts charging. Upon 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 the packet data interaction is ended, the MS sends a PDP Context Deactivation Request (Deactivate PDP Context Request) to the SGSN, where the PDP Context Deactivation Request carries the TI.

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 Delete Response (PDP Context Response) to the SGSN, where the PDP Context deletion response carries the SG SGSN. After the PDP Context deletes the response, the charging of the MS is ended, the PDP Context corresponding to the TEID is deleted, and then the PDP Context Deactivation PDP Context Response is sent to the MS, and the PDP Context deactivation response carries the TI. After the MS receives the PDP Context deactivation response, it deletes the PDP Context corresponding to ΤΙ.

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.

For the above, the third Generation Partnership Project (3GPP, Hie 3rd Generation Partnership Project ) is currently discussing how to implement IP-based billing data streams (FBC, Flow Based Charging) ₀ for a packet data service, MS users When using this service, all IP data streams (IP Flow) transmitted and received may also be IP packets, which are collectively referred to as Service Data Flow, that is, the service data stream is multiple IP data. The set of flows is composed, so the charging based on the IP data stream can truly reflect the occupation of resources by a certain service data flow. The charging based on the rp data stream can be considered as filtering out the different data flows of different services carried in the same PDP Context through filters of similar filters, and then separately filtering the IP data flows filtered by different filters. Fees, 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, the billing based on the EP data stream can provide a more abundant charging means for the operator or the service provider.

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 Rx interface, and the CRF 203 communicates with the Application Function Entity (AF) through the Rx interface. The CRF 203 communicates with the Traffic Plane Function (TPF) 205 through the Gx interface, and the CCF 202 communicates with the TEF 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 CRP 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 the charging mechanism, the charging type, the charging key, the service data stream filter, and the 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 button is a parameter related to the rate, and the CRF 203 may not be 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. The IP5 tuple may include source/destination IP address, source/destination port number (Port Number), protocol identifier (Protocol ID), and the like. For example, CRF 203 indicates TPF 205 to 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, and 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 THF 205 to request a new charging rule from the CRF 205 when a specific event occurs, such as the CRF 203 requiring the TPF 205 to perform an event modification on some bearer. 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. At present, the 3GPP specification describes the charging mode of the CRF that controls the TPF through the triggering event reporting mechanism, that is, after the triggering event is detected, the CRF is reported to the CRF, and the CR detects the change of the bearer through the triggering event reported by the TPF, and then determines the corresponding meter. The fee rules are issued to the TPF. Trigger events defined in the 3GPP specifications may include: Common Land Mobile Communication Network (PLMN) changes (PLMN) Change event, QoS changes event, radio access technology (RAT) type change (RAT type change) event, transport stream template (TFT) change (TFT change) event.

In addition to selecting an appropriate charging rule based on the input information provided by the TPF 205, the CRP 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 an online charging system, and is composed of two functional entities: SCP 201 and 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. Applying only to the online billing system can be achieved by adding new features 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, OCS 206 may require TPF 205 to report to the re-authorisation triggers when they occur, and then OCS 206 re-authenticates the user based on the corresponding re-authentication event on TPF 205, and possibly Recalculate the user's 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, when 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 PLMN changes, the 205 needs to be re-examined. PLMN change event in the right event, The OMC 206 reports the occurrence of the PLMN change event, and the OCS 206 re-determines the rate based on the current location of the user after updating, 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.

In addition, the 3GPP specification also describes the use of the re-authentication event by the OCS to control the credit usage of the TPF. That is, the TPF reports the re-authentication event reported by the TCS to the OCS after the re-authentication event occurs. The credit usage of the user and the change of the bearer are known, and the credit of the user is recalculated and sent to the TPF. The re-authentication events defined in the 3GPP specifications may include: a credit authorization lifetime expiry event, a user idle state timeout event, a charging rule is changed event, a PLMN history event, QoS parameter change event, RAT type change event, transport stream template change event, and the like.

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 enforcement point of the charging rule, and CRF 203 is the control point of the charging rule.

For the service data flow-based charging, in the online charging process, the method for requesting the credit line described in the 3GHP specification is performed based on each charging rule (Charging Rule), and the specific implementation process is as follows: The TPF receives the CF provided After the charging rule, according to the online charging mechanism in the charging rule, when determining that the credit quota needs to be requested for the charging rule for the charging rule, the TPF directly requests the OCS for the credit quota for the charging rule.

However, the charging granularity of the charging rules provided by the CRP to the TPF is for different service data flows. Thus, in the case of online charging, the TF needs to perform online charging interaction for each service data flow, that is, for each service data flow. TPF needs to request credit line from OCS, OCS According to the TPF credit request, each service data stream needs to be assigned a corresponding credit line and sent to the TPF. Since the same user can use multiple services at the same time, multiple service data streams are generated, so this is based on different The processing mechanism of the online data exchange interaction of the service data flow inevitably makes the interaction between the TPF and the OCS too frequent, resulting in a decrease in the processing performance of the TFF and the OCS, thereby greatly reducing the practicability of the entire online charging processing process. SUMMARY OF THE INVENTION

In view of the above, an object of the present invention is to provide a method for processing a charging key to improve the processing performance of TPF and OCS.

In order to achieve the above object, the present invention provides a method for processing a charging key. In the case of online charging, when the charging rule is established, the method includes the step TPF determining whether the charging key is based on the charging key in the charging rule. A credit line for the charging button has been requested from the OCS, and if not, the TPF sends a credit request to the OCS.

The TPF determines that the credit limit for the charging button has been requested from the OCS, and further includes: 1 F does not send a credit request to the OCS, and directly uses the requested credit limit for the charging button.

The TPF directly uses the requested credit limit for the charging button, and further includes: the TPF records the charging rule information corresponding to the charging button of the requested credit line.

The TPF sends a credit request to the OCS in step A, and then further includes step A1: The OCS returns a credit line to the TPF.

The step A1 further includes: the TPF records charging key information that has requested a credit line from the OCS.

The step A1 further includes: the TPF records the charging rule information corresponding to the charging button of the requested credit line.

The present invention also provides a method for processing a charging button, and the OCS provides a needle to the TPF. When the re-authentication event of the charging key occurs, the method further includes the step B: the TPF returns the charging key consumption credit corresponding to the re-authentication event to the OCS. Remaining credit line.

The step B further includes: the TPF records re-authentication event information corresponding to the charging button.

The step B further includes: the OCS performs re-authentication, and then provides the TPF with a newly calculated credit line for the charging button.

The step B further includes: the TPF providing the OCS with corresponding input information for the OCS to determine the credit information.

The invention also provides a method for processing a charging button, in the case of online charging,

When the TPF deletes the charging rule, the method includes the step C: the TPF determines, according to the charging button in the charging rule, whether there is a charging rule other than the charging rule that needs to be deleted, and uses the credit amount requested for the charging button. If not, the TPF returns the remaining credit limit for the charging button to the OCS.

The step C further includes: deleting the charging rule that needs to be deleted by the TPF. According to the method proposed by the present invention, the manner in which the TPF requests a credit line is based on each billing key. Since different service data flows may have the same billing rate, that is, different billing rules may have the same billing key, the granularity of the credit limit request based on each billing key is greater than per billing. Regular credit line request. In this way, by implementing the processing procedure in which the TPF requests the credit limit based on each charging key, the interaction between the TPF and the OCS can be effectively reduced, the processing performance of the TPF and the OCS is improved, and the practicability of the entire online charging processing process is enhanced. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a PDP Context activation, data transfer, deactivation flowchart; 2A shows a structural diagram of an FBC system supporting online charging;

Figure 2B shows a block diagram of an FBC system supporting offline charging;

FIG. 3 is a schematic diagram showing a process of processing a credit limit based on a charge key in the present invention; FIG. 4 is a schematic diagram showing a process of re-authentication processing based on a charge key 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 manner in which the TPF requests the credit limit is performed based on each charging key, that is, the TPF uses the charging key as an index of the charging rule, and records the charging rule having the same charging key, so that the TPM is established. When charging rules, deleting charging rules, and reporting re-authentication events, the charging rules can be batch processed according to the same charging key, and the processing procedure of the TPF requesting the credit limit based on each charging key is realized.

After the TPF receives the charging rules provided by the CRP, if the new charging rule needs to be established, the TPF first determines whether the charging mechanism in the charging rule to be established is online charging, and if it is online charging, further based on The charging key in the charging rule determines whether a credit line has been requested to the OCS for the charging key. If the credit amount is not requested to the OCS for the charging key, the TPF sends a credit request to the OCS, where the credit request is Carrying the charging button, the OCS calculates a credit line of the user according to the charging button, and returns a credit response to the TPF, where the credit response carries a credit line allocated for the charging button. At this time, the TPF records the charging key of the requested credit line and the corresponding relationship with the corresponding charging rule, and can further record the credit amount allocated by the OCS for the charging key. For example, the TPF establishes an online charging interaction information list, in the list, the charging key item of the requested credit line, and records the charging key, such as Charging Key A, and the corresponding "credit quota item" record OCS is allocated for Charging Key A. The credit line, such as 100M, corresponds to the "accounting rule item" record charging rule identifier, such as Charging If Rule L has requested a credit line to the OCS for the charging key, for example, the TPF has the charging key, such as Charging Key A, in the "Receiving Key Item of the Requested Credit Line" in the online charging interaction information list. If it is determined that the credit line has been requested from the OCS according to the charging key, the TPF no longer requests the credit line from the OCS, and directly uses the credit amount previously requested for the charging key to the OCS, that is, the online charging interaction information list. The credit limit of the "credit key item" corresponding to the "requested credit limit" is 100M. Then, the TPF records the charging key of the requested credit line and the corresponding relationship with the charging rule, that is, in the established online charging interaction information list, the charging key item with the requested credit line is Charging Key A. The identifier of the charging rule is recorded in the corresponding "Accounting Rule Item", such as Charging Rule 2. In this way, according to the online charging interaction information list, the service data flow filtered by the charging rule Charging Rule 1 and the charging rule Charging Rule 2 will consume the credit limit corresponding to the Charging Key A 100M, for example, at a certain moment. When the TPF detects that the sum of the traffic data traffic filtered by Charging Rule 1 and the traffic data traffic filtered by Charging Rule 2 reaches the credit limit of 100M, the TPF will initiate a re-authentication process, send a credit request to the OCS, and request the OCS as Charging. Key A assigns the corresponding credit limit.

After the TPF receives the charging rule provided by the CRF, if the charging rule needs to be deleted, the TPF first determines whether the charging mechanism in the charging rule to be deleted is online charging, and if it is online charging, further according to the The charging key in the charging rule determines whether there are other charging rules other than the charging rule to be deleted, and uses the credit amount requested for the charging key, such as in the charging rule Charging Rule 1 to be deleted. When the charging key is Charging Key A, the TPF determines the charging rule recorded in the "Accounting Rule Item" corresponding to the "Charging Key Item of the Requested Credit Line" Charging Key A in the online charging interaction information list. Indicates whether there are other charging rule identifiers besides Charging Rule 1. If there is no other charging rule identifier, the TPF deletes the charging rule specified by the CRF. The service data flow specified by the charging rule is filtered, and the corresponding information in the online charging interaction information list is updated, for example, the charging key Charging Key A in the "receiving key amount of the requested credit line" and its corresponding " The credit limit item "in the credit line and the charging rule item," the charging rule identifier, and the TPF returns the remaining credit line corresponding to the charging button to the OCS, ending the charging button between the TPF and the OCS The interaction operation; if the TPF determines that there are other charging rules using the credit line requested for the charging key, that is, the charging key of the "requested credit line" charging key in the online charging interaction information list The charging rule identifier recorded by the "Accounting Rule Item" corresponding to Key A has other charging rule identifiers besides Charging Rule 1. The TPF deletes the charging rule specified by CF, such as Charging Rule 1, and no longer The service data flow specified by the charging rule is filtered, and the corresponding information in the online charging interaction information list is updated, for example, deleting the charging key with the "receiving credit amount of the requested credit line" is Charging Key A Corresponding to "charging rule item" in the charging rule identifier Charging Rule 1, does not return the credit remaining charging key corresponding to the OCS.

In addition, according to the above processing method of requesting the credit limit based on each charging key, the processing of the re-authentication process may also be based on each charging key. When the TPF sends a credit request to the OCS and the OCS returns a credit response to the TPF, the OCS may further provide a re-authentication event in addition to providing a credit line to the TPF. At this time, the TPF can record the charging key of the requested credit line and the corresponding relationship with the corresponding re-authentication event, for example, the charging key recorded for the "receiving key item of the requested credit line" in the online charging interaction information list. For example, the re-authentication event sent by the OCS is recorded in the corresponding re-recognition event item, and the re-authentication event may be one or more, such as a PLMN change event, a TFT change event, and the like. The OCS can issue the same re-authentication event for different charging keys ^; for example, the OCS issues a re-authentication event for the PLMN change for both the Charging Key A and the Charging Key B. When the TPF detects that the re-authentication event occurs, the TPF searches for the charging key corresponding to the re-authentication event that occurred, and then returns to the OCS the remaining credit line after the charging key consumes the credit line. If it happened The PLMN changes the event, and the TPF searches for the Charging Key A and the Charging Key B corresponding to the PLMN change event according to the information recorded in the online charging interaction information list, and the TPF stops the charging corresponding to the Charging Key A and the Charging Key B respectively. The filtering of the service data flow specified by the rule, calculating the remaining credit limit for the Charging Key A and the Charging Key B to consume the credit line and returning to the OCS, requesting the OCS to reallocate the re-authentication event for the Charging Key A and the Charging Key B's credit limit. After the OCS performs the re-authentication, the TPF is provided with a recalculated credit line for the charging button, and then the TPF uses the new credit line to monitor the credit usage of the service data stream specified by the charging rule corresponding to the charging button. For example, the OCS provides the TPF with the credit line calculated for the Charging Key A and the Charging Key B respectively. After the TPF obtains the new credit limit for the Charging Key A, the TPF specifies the service data for the charging rule corresponding to the Charging Key A. The flow is filtered to monitor whether the service data flow reaches the credit limit. After the credit limit is reached, the allowed credit expiration re-authentication event is triggered, and the TPF re-executes the re-authentication process, requesting the OCS to recalculate the new credit limit for the Charging Key A. Similarly, after the TPF obtains a new credit limit for the Charging Key B, the TPF performs an operation similar to that for the Charging Key A, and will not be described here.

FIG. 3 is a schematic diagram showing a process of processing a credit line based on a charge key in the present invention. As shown in FIG. 3, the process of requesting a credit line based on a charge button includes the following steps:

Steps 301 to 302: The CRF may "receive information from an external entity, for example, the CRP receives a message from the TPF, such as the establishment, modification, or deletion of the bearer, or the CRF receives the information provided by the AP or the OCS related to the charging rule. The input information, the charging rule that needs to be provided to the TPF, the CRF may require the TPF to establish a new charging rule, or the TPF may be required to delete the original charging rule, and the TPF may be required to modify the original charging rule. The selected charging rule is provided to the TPF, and the TPF is instructed to perform corresponding operations on the charging rule.

Step 303 to step 304: After receiving the charging rule, the TPF operates according to the charging rule. Perform corresponding operations on the charging rules, such as establishing, modifying, or deleting charging rules. In the case of online charging, if the TTPF establishes a new charging rule or modifies the original charging rule, it determines whether the credit line has been requested from the OCS according to the charging button in the charging rule. If yes, the TPF no longer requests a credit line from the OCS, directly using the credit amount previously requested for the charging key to the OCS, that is, the service data stream will consume the credit amount previously requested by the TPF for the charging key to the OCS. Then, the TPF records the charging rule information corresponding to the charging key of the requested credit line, such as the charging rule identifier; otherwise, step 305 is performed. In the case of online charging, if the TPF deletes the original charging rule, it determines whether there are other charging rules using the credit amount requested for the charging button according to the charging button in the charging rule, such as determining and Whether the charging rule corresponding to the charging button has other charging rules in addition to the charging rule to be deleted, and if so, directly deleting the charging rule, and the service specified by the charging rule is no longer specified. The data stream is filtered; otherwise, the TPF stops filtering the service data flow specified by the charging rule, deletes the charging rule, and returns the remaining credit limit for the charging button to the OCS, ending the relationship between the TPF and the OCS. The interaction of the billing key.

Step 305 to step 306: The TPF sends a credit request (Credit Request) to the OCS, where the credit request carries a charging button of the charging rule, and requests the OCS to provide a credit line for the charging button, and further provides a corresponding input. Information for OCS to determine credit information. After receiving the credit request, the OCS calculates the credit line of the user according to the charging button, and then returns a credit response (Credit Response) to the TPF, where the credit response carries the assigned credit line. After receiving the credit response, the TPF uses the received credit limit to monitor the credit usage of the service data stream specified by the charging rule corresponding to the charging button.

FIG. 4 is a schematic diagram showing a process of re-authentication processing based on a charging key in the present invention. As shown in FIG. 4, the process of re-authenticating based on a charging key includes the following steps:

Step 401: The TPF monitors whether the re-authentication event occurs, and if yes, step 402 is performed; Otherwise, return to step 401.

Steps 402 to 403: The TPF searches for a charging button corresponding to the re-authentication event that occurs, and then sends a credit request and re-authorisation request to the OCS, the credit and re-authentication request. The remaining credit line after the credit key is consumed by the charging key and the corresponding input information are carried in the OCS to determine the credit information. After receiving the credit and re-authentication request, the OCS performs the re-authentication right, recalculates the credit line for the charging button, and then returns a credit response and re-authorisation response to the TPF. And the re-authentication response carries a new credit line. After receiving the credit and re-authentication response, the TPF uses the new credit limit to monitor the credit usage of the service data flow specified by the charging rule corresponding to the charging button.

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 a charging key, characterized in that, in the case of online charging, when the TPF establishes a charging rule, the method includes:

A. The TPF determines whether the credit limit for the charging key has been requested from the OCS according to the charging key in the charging rule. If not, the TPF sends a credit request to the OCS.

2. The method according to claim 1, wherein the TPF determines that a credit line for the charging button has been requested from the OCS, and then further includes: the TPF does not send a credit request to the OCS, directly using the request to The credit line for the billing button.

The method according to claim 2, wherein the TPF directly uses the requested credit limit for the charging button, and further includes: the TPF record corresponds to the charging button of the requested credit line. Billing rule information.

The method according to claim 1, wherein the TPF sends a credit request to the OCS in step A, and then further includes:

Al, OCS returns the credit limit to the TPF.

The method according to claim 4, wherein the step A1 further comprises: the TPF records charging key information that has requested a credit line from the OCS.

The method according to claim 4 or 5, wherein the step A1 further comprises: the TPF recording the charging rule information corresponding to the charging button of the requested credit line.

A method for processing a charging key, wherein the OCS provides a re-authentication event for the charging key to the THF, and the TPF detects that the re-authentication event occurs, the method further comprising:

B. The TPF returns, to the OCS, the remaining credit line after the charging key corresponding to the re-authentication event consumes the credit line.

The method according to claim 7, wherein the step B further comprises: the TPF recording re-authentication event information corresponding to the charging button.

9. The method according to claim 7, wherein the step B further comprises: the OCS performing re-authentication, and then providing the TPF with a recalculated credit line for the charging button.

The method according to claim 7, wherein the step B further comprises: the TPF providing the OCS with corresponding input information for the OCS to determine the credit information.

A method for processing a charging key, characterized in that, in the case of online charging, when the TPF deletes the charging rule, the method includes:

C. The TPF determines, according to the charging button in the charging rule, whether there is a charging rule other than the charging rule that needs to be deleted, and uses the credit amount requested for the charging button. If not, the TPF returns to the OCS for the The remaining credit limit of the billing button.

The method according to claim 11, wherein the step C further comprises: deleting, by the TPF, a charging rule that needs to be deleted.