WO2006060964A1

WO2006060964A1 - A system and processing method for charging based on the packet data flow

Info

Publication number: WO2006060964A1
Application number: PCT/CN2005/002139
Authority: WO
Inventors: Xiaoqin Duan
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2004-12-09
Filing date: 2005-12-09
Publication date: 2006-06-15
Also published as: CN1787442A; CN100341278C

Abstract

A system and method for charging based on packet data flow makes the charging rule function (CRF) and the online charging system (OCS) together to constituent a logic function (CRF-OCS). The said CRF-OCS connects to the traffic plane function (TPF) via the interface including the function of Gx datum point and Gy datum point. So the event trigger can be made with the re-authorisation triggers together to implement. The event report mechanism of TPF is unified. The present invention describes a plurality of process of OCS configuration based on the CRF function implemented, and includes: the process of interacting provision charging rules and user credit between TPF and CRF-OCS, the interactive process of between CRF-OCS and TPF based on the charging trigger, the process of interacting relative information between CRF-OCS and AF, and the process of interacting user credit using situation between TPF and CRF-OCS. It makes the process clearer between TPF and OCS or between TPF and CRF.

Description

System and processing method based on packet data flow charging

The present invention relates to the field of packet data charging, and more particularly to a system and processing method based on packet data flow charging. 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 the 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 mesh layer service access point. 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, the SGSN is addressed to the corresponding GGSN according to the APN, and the GGSN determines the external network to be accessed by the MS according to the APN, and the MS may not provide the SGSN. APN, at this time, the SGSN selects the default APN according to the subscription information of the MS user; QoS The parameter is MS The quality requirements to be met by the packet data service; TI is 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 an optional step.

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). The combination of the NSAPI, and then the SGSN sends a PDP Context Request to the GGSN, where the PDP Context creation request carries a PDP type, a PDP address, an APN, a QoS parameter, a TEID, a selection mode, etc., where the PDP address can be The IP address of the MS 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 be the MS that finally establishes a connection with the MS. The IP address is assigned; the selection mode refers to the selection mode of the APN, 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 Response response is generated by the PDP Context Response. The PDP Context creation response carries information such as the TEID, the PDP address, the Backbone Bearer protocol, the agreed QoS parameters, and the Charging ID. If the GGSN fails to meet the quality of service requirements of the QoS parameters, the GGSN rejects the SGSN-initiated PDP Context creation request, and then the SGSN rejects the MS-initiated PDP Context activation request.

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 the PDP type, PDP address, TI, negotiated Information such as QoS parameters, wireless priority, PDP configuration options, etc. 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

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 Response (PDP Context Response) to the SGSN. The PDP Context deletion 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 termination point of charging is set when the PDP Context is deleted, and therefore can only be transmitted according to the PDP Context. Data traffic is billed, or billed based on the length of time the PDP Context is active. 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 wireless application protocol (WAP, Wireless Application Protocol) browsing service, file transfer protocol (FTP) file transfer, etc., the MS establishes a transmission with the PDN. After the transmission channel, an active PDP Context can be used to carry 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 email sending and receiving services, it can be based on Email. The trigger for receiving and sending events is billed on a per-time basis. The WAP browsing service can be based on the flow rate. For the file transmission service, the rate of the WAP browsing service and the rate of the file transmission service are different. In this way, according to the existing GPRS charging system, it is impossible to separately distinguish and charge different services carried by the same PDP Context.

In response to the above situation, the 3rd Generation Partnership Project (3GPP, 3rd Generation Partnership Project) is currently discussing how to implement Flow Based Charging (FBC). For a packet data service, users of MS 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. IP data flow-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, and the granularity can be regarded as the size of the screening hole. The charging granularity based on a PDP Context is a PDP Context, which is a sieve hole. The IP data flow-based charging granularity is that an IP service data stream is a mesh hole, that is, a plurality of mesh holes are included in one PDP Context, and therefore, IP data flow based charging and charging based on one PDP Context. In contrast, IP stream-based billing provides operators or service providers with a richer set of billing methods.

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 customer application based on the 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 constitutes an Online Charging System (OCS) 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 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 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 and the Charging Data Function (CDF) 208 are interworking.

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) and so on. In addition, since the bearer is modified during IP data stream transmission, such as renegotiating QoS parameters, when the QoS parameters of the same service are different, the charging rules may be different, such as the corresponding rate of QoS parameters falling. Also fell. At this time, the TPF 205 may re-send 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 key is a parameter related to the rate, and the CRF 203 may not The rate is directly provided to the TPF 205, 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. The flow is billed. Business data filter The IP quintuple includes the source/destination IP address, the source/destination port number (Port Number), the protocol identifier (Protocol ID), and the like. For example, the CRF 203 indicates that the TPF 205 has a source address of 10.0. 0.1. The IP address of 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 charged according to the charging rule.

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 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 through the triggering event reporting mechanism and the control of the TPF. That is, the TPF 205 detects that the triggering event occurs after the triggering event occurs, and the triggering event reported by the CRF 203 on the CRF 203 through the TPF 205 is known to change the bearer. The corresponding charging rule is then determined and sent to the TPF 205. Trigger events defined in the 3GPP specifications may include: public land mobile communication network (PLMN) change events, QoS parameter change events, radio access technology (RAT) type change events, transport stream templates (TFT) Change events.

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.

As an online charging system, the OCS 206 is composed of two functional entities, SCP 201 and CCF 202, wherein the CCF 202 is a functional entity that performs credit control, and is applied only to an online charging system, which can be added to the existing OCS 206. New features are implemented. In the online charging process, the CCF 202 manages and controls the user credit. When the user uses the service, the CCF 202 authorizes the credit in the user credit pool, and delivers the credit that the user can use to the TPF 205 through the Gy interface. .

In addition, the OCS 206 may request the TPF 205 to report to the user when the re-authorisation triggers occur, and then the OCS 206 pairs the user according to the corresponding re-authorization event reported by the TPF 205. Reauthorize 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-authorization event, and the OCS 206 according to the remaining user account information. , Recalculate the credits that the user is allowed to use. 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 TPF 205 needs to be re-authorized according to the re-authorization. The PLMN change event in the event reports the occurrence of the PLMN change event to the OCS 206, 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-authorization event, 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-authorization event by the OCS 206 to control the credit usage of the TPF 205, that is, the TPF 205 reports the re-authorization event to the OCS 206, and the OCS 206 reports it through the TPF 205. The re-authorization event, the credit usage of the user and the change of the bearer are obtained, and the credit of the user is recalculated and sent to the TPF 205. The re-authorization events defined in the 3GPP specifications may include: a credit authorization lifetime expiry event, a user idle state timeout (idle timeout event), a charging rule is changed event, a PLMN change event, a QoS parameter. Change event, RAT type change event.

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.

Currently, 3GPP defines the processing procedure for requesting charging rules and user credits in the case of online charging when the bearer is established, as shown in Figure 3A:

Step 301 A: The user equipment (UE) sends a bearer setup request to the TPF (established Bearer) Service Request), In the GPRS network, the GGSN receives the Create PDP Context Request:.

Step 302A: After receiving the bearer setup request, 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.

Step 303A to step 304A: After receiving the charging rule request, the CR may, according to the input information carried in the charging rule request, select an appropriate charging rule according to the relevant 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 trigger event information.

Step 305A: After receiving the charging rule, the TPF performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction, that is, the charging rule is established.

Step 306A to step 307A: The TPF sends a credit request (Credit Request) to the OCS according to the online charging indication in the charging rule to request the credit of the user. After receiving the credit authorization request, the OCS determines the credit of the user, and then returns a credit response (Credit Response) to the TPF. If the OCS determines the credit of the user, the credit response carries the credit of the user, if the OCS does not determine the user's credit. Credit, the credit response may carry an error reason value.

Step 308A: After receiving the credit response, the TPF returns an bearer setup response (Establish Bearer Service Accept) to the UE. If the credit response carries the user's credit, the TPF accepts the bearer setup request initiated by the Ufe, and continues the subsequent bearer setup process. If the credit response does not carry the user's credit, the UE initiated bearer setup request is rejected. '

For bearer modification, in the case of online charging, the processing procedure for requesting charging rules and user credit is as shown in Figure 3B:

Step 301B: 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 302B: After receiving the bearer modification request, 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. Step 303B to step 304B: After receiving the charging rule request, the CR may, according to the input information carried in the charging rule request, select an appropriate charging rule according to the relevant input information provided by the AF, and then return the provisioning to the TPF. The fee rule, the provided charging rule may carry the selected charging rule and trigger event information.

Step 305B: After receiving the charging rule, the TPF performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction, that is, establishes, modifies, and deletes the charging rule.

Step 306B to step 307B: The TPF sends a credit authorization request to the OCS according to the online charging indication in the charging rule, requesting the credit of the user. After receiving the credit authorization request, the OCS determines the credit of the user, and then returns a credit response to the TPF. If the OCS determines the credit of the user, the credit response carries the credit of the user. If the OCS does not determine the credit of the user, the OCS The credit response may carry an error cause value.

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

For bearer deletion and online charging, the processing procedure for requesting charging rules and user credit is as shown in Figure 3C:

Step 301C: The UE sends a Bearer Delete Request (Remove Bearer Service Request) to the TPF. In the GPRS network, the GGSN receives the Delete PDP Context Request.

Step 302C: After receiving the bearer deletion request, 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.

Step 303C to step 304C: 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 relevant input information provided by the AF, and then return the provisioning to the TPF. The fee rule, the provided charging rule may carry the selected charging rule and the charging rule operation instruction.

Step 305C: After receiving the charging rule, the TPF selects the CRF according to the charging rule operation indication. The fixed charging rule performs the corresponding operation, that is, deletes the charging rule.

Step 306C to step 307C: The TPF sends a credit report ( Final Remaining Credit Report) to the OCS, and notifies the OCS that the bearer established for the user has been terminated. The credit report carries the usage of the user credit, such as the length of time that the user uses the packet data service. , the amount of traffic using packet data, or the user's remaining credit. After receiving the credit report, OCS returns a credit report response ( Response ) to the TPF.

Step 308C: After receiving the credit report response, the TPF returns a Bearer Service Accept (Remove Bearer Service Accept) to the UE, accepts the bearer deletion request initiated by the UE, and continues the subsequent bearer deletion process.

At present, the 3GPP defines the process of the offline charging, the bearer modification triggers the TPF to request the charging rule from the CRF, and the specific implementation process is as shown in FIG. 4A:

Step 401A: The UE sends a bearer modification request to the TPF. In the GPRS network, the GGSN receives the PDP Context update request.

Step 402A: After receiving the bearer modification request, the TPF matches the bearer modification event with the stored trigger event. If yes, go to step 403 A; otherwise, continue to monitor the trigger event.

Step 403A: 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.

Step 404A to step 405A: 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 relevant input information provided by the AF, and then return the provisioning to the TPF. The fee rule, the provided charging rule may carry the selected charging rule and trigger event information.

Step 406A: After receiving the charging rule, the TPF performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction, that is, establishes, modifies, and deletes the charging rule.

Step 407A: The TPF returns a bearer modification response to the UE, and continues the subsequent bearer modification process. In the case of online charging, the bearer modification triggers the flow that the TPF requests the OCS to re-authorize the user. The specific implementation process is shown in Figure 4B:

Steps 401B to 406B are the same as steps 401 A to 406A.

Step 407B: The TPF matches the bearer modification event with the stored re-authorization event. If it can match, step 408B is performed. Otherwise, the monitoring of the re-authorization event continues.

Step 408B: If the re-authorization event occurs, or the charging rule changes, the TPF sends a credit request and a re-authorisation request to the OCS, where the credit and the re-authorization request carry the user The remaining credit and related charging rule information may also carry a corresponding re-authorization event, requesting the OCS to recalculate the credit of the user. The relevant charging rule information provided by the TPF to the OCS can come from the CRF.

Step 409B: After receiving the credit control request, the OCS recalculates the credit of the user, and then returns a credit response and a re-authorization response to the TPF. If the OCS calculates the credit of the user, the credit and The re-authorization 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 reason value.

Step 410B: After receiving the credit control response, the TPF returns a bearer modification response 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 modification process; if the credit control If the user does not carry the credit in the response, the bearer modification request initiated by the UE is rejected.

In addition, the CRF can also actively send charging rules to the TPF. For example, when the UE and the AF perform service data transmission, after receiving the charging rule input information of the AF, the CRF selects an appropriate according to the charging rule input information provided by the AF. The charging rule then proactively delivers the selected charging rule to the TPF. The specific implementation process of providing charging rules input information to the CRF to the CRF is shown in Figure 5:

Step 501: The AF sends Application/Service Data Flow Charging Information to the CRF.

Step 502: After receiving the application/service charging related information, the CRF returns a response (Ack) to the AF, and notifies the AF that the charging rule input information sent by the AF has been received. FIG. 6 is a flowchart of a charging rule that is sent by the CRF to the TPF. As shown in FIG. 6, the process for the CF to actively deliver the charging rule to the TPF includes the following steps:

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

Step 602: The CRF selects a corresponding charging rule according to the obtained information. This information can be used to input information for the charging rules provided by the AF. For example, the user uses a certain service provided by the AF. The service has special requirements for charging. For example, the rate is different from the rate of other services. Therefore, the AF provides the CRF. Billing information related to the service; may also input information for the charging rule provided by the TPF.

Step 603: If required, the CRF sends a charging rule to the TPF, and the provided charging rule may carry the selected charging rule and trigger event information.

Step 604: After receiving the charging rule, the TPF performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction, that is, establishes, modifies, and deletes the charging rule.

Step 605 to step 606: The TPF sends a credit authorization request to the OCS to request the credit of the user. After receiving the credit authorization request, the OCS determines the credit of the user, and then returns a credit response to the TPF. If the OCS determines the credit of the user, the credit response carries the credit of the user. If the OCS does not determine the credit of the user, the The credit response may carry an error cause value.

Currently, the specification defines the charging mode of the CRF to control 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: PLMN change events, QoS parameter change events, RAT type change events, TFT change events.

In addition, the specification also describes how the OCS controls the credit usage of the TPF through the mechanism reported by the re-authorization event. That is, the TPF reports the re-authorization event to the OCS after the re-authorization event occurs, and the OCS obtains the credit of the user through the re-authorization event reported by the TPF. The user's credit is recalculated and sent to the TPF. The reauthorization events defined in the specification may include: Allowing credit Expiration event, user idle state timeout event, charging rule change event, PLMN 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-authorization event include a PLMN change event, a QoS parameter change event, a RAT type change event, etc., so that for a certain PLMN event, the TPF will simultaneously match the PLMN event to the trigger event. And the re-authorization event, therefore, it is necessary to separately report the occurrence of the PLMN event to the CRF and the OCS, resulting in waste of the FBC system resources. Summary of the invention

In view of this, an object of the present invention is to provide a system for charging based on packet data stream, and another object of the present invention is to provide a processing method based on packet data stream charging, which improves packet charging based on packet data stream. System structure and implementation process.

In order to achieve the above object, the present invention provides a system for packet data stream charging, the system comprising: a charging rule function entity CRF and an online charging system OCS combined to form a logical function entity CRF-OCS, the CRF- The OCS is connected to the transport plane functional entity TPF through an interface including a Gx reference point and a Gy reference point function.

The functions of the Gx reference point and the Gy reference point include: the TPF requests a charging rule from the CRF-OCS, and the CRF-OCS provides a charging rule to the TPF; or, the TPF requests a credit authorization from the CRF-OCS, CRF-OCS The TPF provides credit; or, the TPF simultaneously requests charging rules and credit authorizations to the CRF-OCS, and the CRJF-OCS provides charging rules and credits to the TPF at the same time. The functions of the Gx reference point and the Gy reference point further include: CRF-OCS provides a charging rule triggering event to the TPF, and requests a charging rule from the CRF-OCS when the TPF monitors the charging rule triggering event; or, CRF - The OCS provides a re-authorization event to the TPF. When the TPF monitors the re-authorization event, it requests a credit authorization from the CRF-OCS. Alternatively, the CRF-OCS provides the charging rule triggering event and the re-authorization event to the TPF, when the TPF monitors When the charging rule triggers an event, it requests the charging rule from the CRJF-OCS. When the TPF monitors the re-authorization event, it requests the CRF-OCS for the credit authorization. The CRF-OCS is further connected to the application function entity AF through an interface including the Rx reference point function.

The invention also provides a processing method based on packet data flow charging, the method comprising: TPF Requesting charging rules and/or credit authorizations from the CRF-OCS including the charging rule function entity CRF and the online charging system OCS, and after receiving the charging rules and/or credit authorization requests, the CRF-OCS returns the charging rules to the TPF. And/or user credit.

The present invention also provides a processing method based on packet data flow charging, the method comprising: when a bearer is established, the TPF sends a charging rule and a credit to a CRF-OCS including a charging rule function entity CRF and an online charging system OCS. Authorization request, for the service data flow that needs to be charged online, CRF-OCS provides corresponding charging rules and user credits to the TPF at the same time.

The present invention also provides a processing method based on packet data flow charging. When the bearer is established, the TPF requests the charging rule from the CRF-OCS including the charging rule function entity CRF and the online charging system OCS, and the CRF-OCS determines Whether the UE user is the network user to which the subscriber is subscribed, and if so, directly returns the charging rule and/or the user credit to the TPF; otherwise, the TPF is provided with the address information of the CRF-OCS of the UE user's home subscription, and the TPF receives the The CRP-OCS address information sends a charging rule and a credit authorization request to the CRF-OCS. After receiving the charging rule and the credit authorization request, the CRF-OCS to which the UE belongs returns a charging rule and/or a user credit to the TPF.

The invention also provides a processing method based on packet data flow charging. When the bearer is established, the TPF requests the charging rule from the CRF-OCS including the charging rule function entity CRF and the online charging system OCS, and the CRF-OCS determines the UE. Whether the user is the network user to which the user belongs, if yes, the charging rule and/or the user credit are directly returned to the TPF; otherwise, the CRF-OCS forwards the charging rule request to the UE user-signed CRF-OCS, and the UE user belongs to The contracted CRP-OCS returns billing rules and/or user credits to the TPF via a visit to the CRF-OCS.

The invention further provides a processing method based on packet data flow charging, the method comprising: providing a charging trigger event to the TPF including a charging rule function entity CRF and an online charging system OCS, and the TPF monitoring the charging When a trigger event occurs, it is reported to the CRF-OCS.

The present invention further provides a processing method based on packet data flow charging, the method comprising: the AF providing input information for selecting a charging rule to the CRF-OCS. Wherein, the method further comprises: the CRF-OCS returning to the AF a response indicating receipt of the input information. The invention further provides a processing method based on packet data flow charging, the method comprising:

The CRF-OCS requires the TPF to return the user credit usage, and the TPF returns the user credit usage information to the CRF-OCS.

According to the solution proposed by the present invention, the CRF function is implemented in the 0CS, so that the trigger event can be implemented in combination with the re-authorization event, and the event reporting mechanism of the TPF is unified, and the present invention also describes each of the OCS structures based on the CRF function. The process makes the process between TPF and OCS and between TPF and CRF clearer. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a PDP Context activation, data transfer, deactivation flowchart;

2A is a schematic structural diagram of an FBC system for online charging;

2B is a schematic structural diagram of an FBC system for offline charging;

FIG. 3A is a flowchart showing a process of requesting charging rules and user credits when an online charging bearer is established; FIG.

FIG. 3B is a flowchart showing a process of requesting charging rules and user credits when the online charging bearer is modified;

FIG. 3C is a flowchart showing a process of requesting charging rules and user credits when an online charging bearer is deleted;

FIG. 4A is a flowchart of a bearer modification process for offline charging in the prior art; FIG.

FIG. 4B is a flowchart of a bearer modification process during online charging in the prior art; FIG.

FIG. 5 is a flow chart showing the input of charging rules by the AF to the CRF;

Figure 6 shows a flow chart of the CRF actively issuing charging rules to the TPF;

Figure 7 is a block diagram showing the structure of the FBC system of the present invention;

FIG. 8A is a flowchart showing a process of requesting charging rules and user credits when a bearer is established in the present invention; FIG.

FIG. 8B is a flowchart showing a process of requesting charging rules and user credits when carrying modifications in the present invention; FIG. FIG. 8C is a flowchart showing a process of requesting a charging rule and a user credit when carrying a deletion in the present invention; FIG.

FIG. 9 is a flow chart showing the processing of the AF providing charging rule input information to the CRF-OCS in the present invention;

Figure 10 is a flow chart showing the process by which the AF provides input information to trigger the charging rules and/or credit authorization requests to the CRF-OCS 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 structure of the FBC system is improved, and the CRP function is added in the OCS system, so that the trigger event and the re-authorization event can be combined and implemented, and the TPF event reporting mechanism is unified, so that the TPF and the OCS, the TPF, and the CRF are unified. The process is more clear. The solution proposed by the present invention is applicable to both online charging and offline charging.

FIG. 7 is a schematic structural diagram of an FBC system according to the present invention. As shown in FIG. 7, in the FBC system structure of the present invention, the functions of two logical functional entities of CRF 203 and OCS 206 are integrated into one logical functional entity. The logical functional entity integrated with CRF 203 and OCS 206 is hereinafter referred to as CRF-OCS 70, and SCP 201 and CCF 202 are included in OCS 206. The CRJF-OCS 70 interworks with the AF 204 through an interface including an Rx reference point function, and the AF 204 can provide input information for selecting a charging rule to the CRF-OCS 70 through the Rx reference point. The CRF-OCS 70 interworks with the TPF 205 through an interface including a Gx reference point and a Gy reference point function, wherein an interface including a Gx reference point and a Gy reference point function can be expressed as a function of Gy+Gx, Gx reference point, and Gy reference point. Including: TPF 205 requests charging rules from CRF-OCS 70, CRF-OCS 70 provides charging rules to TPF 205; alternatively, TPF 205 requests credit authorization from CRF-OCS 70, and CRF-OCS 70 provides credit to TPF 205; The TPF 205 simultaneously requests charging rules and credit authorizations to the CRF-OCS 70, and the CRF-OCS 70 simultaneously provides charging rules and credits to the TPF 205. The functions of the Gx reference point and the Gy reference point further include: The CRF-OCS 70 provides a charging rule triggering event to the TPF 205, and the TPF 205 monitors the charging rule. When the triggering event occurs, the charging rule is requested to the CRF-OCS 70; or, the CRF-OCS 70 provides a re-authorization event to the TPF 205, and when the TPF 205 monitors that the re-authorization event occurs, requests the CRF-OCS 70 for a credit authorization; or The CRF-OCS 70 simultaneously provides a charging rule triggering event and a re-authorization event to the TPF 205. When the TPF 205 monitors that the charging rule triggering event occurs, the charging rule is requested to the CRF-OCS 70, and when the TPF 205 monitors the re-authorization. When an event occurs, a credit authorization is requested from CRF-OCS 70.

In the case of online charging, the charging rule triggering event and the re-authorization event are all requested by the CRF-OCS 70 to request the TPF 205 to monitor the specified event. Therefore, the charging rule triggering event and the re-authorization event can be combined and delivered. The CRF-OCS 70 provides a collection of charging rule trigger events and re-authorization events to the TPF 205. Hereinafter, the collection of the charging rule triggering events and the re-authorization events is referred to as a Charging Trigger.

After detecting the charging trigger event, the TPF 205 notifies the CRF-OCS 70 of the current charging trigger event, and provides the CRF-OCS 70 with the credit that the user has used; the CRF-OCS 70 triggers the event according to the current charging. The charging rules are selected, and the user's credit is recalculated, and then the selected charging rules and recalculated user credits are returned to the TPF 205.

The CRF-OCS 70 can further indicate to the TPF 205 the re-authorization event included in the charging triggering event. Thus, after detecting the charging triggering event, the TPF 205 determines whether the charging triggering event that occurred is a re-authorization event. If the TPF 205 determines that the charging triggering event that occurred is a re-authorization event, the TPF 205 notifies the CRF-OCS 70 of the charging triggering event currently occurring, and provides the CRF-OCS 70 with the credit that the user has used, requesting the CRF-OCS 70 pair. The user performs a re-authorization; the CRF-OCS 70 selects the charging rule based on the currently occurring charging triggering event, and recalculates the user's credit, and then returns the selected charging rule and the recalculated user credit to the TPF 205. If the TPF 205 determines that the charging triggering event that occurred is not a re-authorization event, the TPF 205 only notifies the current charging triggering event of the CRF-OCS 70; the CRF-OCS 70 selects the charging rule according to the currently occurring charging triggering event. The selected charging rule is then returned to the TPF 205.

In addition, the CRF-OCS 70 may not indicate to the TPF 205 the re-authorization event included in the charging trigger event, such that the TPF 205 notifies the CRF-OCS 70 that the current occurrence occurs after the charging trigger event is detected. The charging triggering event, and providing the CRF-OCS 70 with the credit that the user has used, the CRF-OCS 70 determines whether the currently occurring charging triggering event is a re-authorization event, and if so, the CRF-OCS 70 is based on the current occurrence. The fee triggers the event, selects the charging rule, and recalculates the user's credit, and then returns the selected charging rule and the recalculated user credit to the TPF 205; otherwise, the CRF-OCS 70 only triggers based on the currently occurring charging Event, select a charging rule, and then return the selected charging rule to TPF 205.

In the specific implementation process, the charging rule request and the credit authorization request may be implemented in the same message. For example, the TPF 205 sends a charging rule and a credit authorization request (Charging Rule and Credit Request) to the CRF-OCS 70, and the charging rule and The credit authorization request may carry input information for the CRF-OCS 70 to select the charging rule, and input information for the CRF-OCS 70 to determine the user credit, such as related information of the user and the terminal, such as MSISDN, IMSI, etc., bearer characteristics, Such as QoS information, network related information, such as MNC, MCC, etc.

The charging rules, credits provided, and provided charging trigger events provided by the CRF-OCS 70 to the TPF 205 may also be implemented in the same message, such as the CRF-OCS 70 transmitting charging rules and credit responses to the TPF 205 (Charging Rule and Credit Response), the charging rule and the credit response carry the charging rule selected by the CRF-OCS 70, the user credit, and the charging rule and the credit response may also carry a charging trigger event.

FIG. 8A is a flowchart showing a process of requesting charging rules and user credits when a bearer is established in the present invention. As shown in FIG. 8A, the process of requesting charging rules and user credits during bearer establishment includes the following steps:

Step 801A is the same as step 301A.

Step 802A to step 803A: After receiving the bearer setup request, the TPF sends a charging rule and a credit authorization request to the CRF-OCS, where the charging rule and the credit authorization request carry the input information for determining the charging rule by the CRF-OCS and Determining the input information of the user credit, the TPF may be addressed to the corresponding CRF-OCS according to the UE identifier, or may be addressed to the corresponding CRF-OCS according to the data configured by itself, and may also be addressed according to the access point provided by the UE when the bearer is established. Go to the corresponding CRJF-OCS. CRF-OCS receives billing After the rule is requested, it is determined whether the UE user is a home subscriber of the home subscription. If yes, the CRF-OCS is the home CRF-OCS of the UE, and step 806A is performed; otherwise, the CRF-OCS is the visited CRF-OCS of the UE. The visited CRF-OCS may obtain the address information of the UE home CRF-OCS according to the UE identifier, and then perform 804A.

Steps 804A to 805A: The CRF-OCS returns a charging rule and a credit response to the TPF. The charging rule and the credit response carry the address information of the CRF-OCS to which the UE belongs. After receiving the charging rule and the credit response, the TPF sends a charging rule and a credit authorization request to the CRP-OCS according to the received CRF-OCS address information, where the charging rule and the credit authorization request are carried by the CRF-OCS. Input rules for billing rules and user credits.

Step 806A to step 807A: After receiving the charging rule and the credit authorization request, the CRJF-OCS may select an appropriate charging according to the input information carried in the charging rule and the credit authorization request according to the relevant input information provided by the AF. In addition, the CRF-OCS can further determine whether the current charging mode should be online charging, such as determining whether the UE user is a prepaid user, or determining whether the UE user uses the prepaid service. If the CRP-OCS determines that the current charging mode should be online charging, the CRF-OCS calculates the user credit according to the selected charging rule, and returns the charging rule and the credit response to the TPF, in the charging rule and the credit response. The charging rule operation indication, the selected charging rule, and the calculated user credit are carried. If the CRF-OCS does not calculate the credit of the user, the charging rule and the credit response may carry an error reason value. The charging rule and the credit response may further carry a charging trigger event, and may further indicate a re-authorization event included in the TPF charging trigger event. If the CRF-OCS determines that the current charging mode should not be online charging, the charging rules and credit responses provided by the CRF-OCS to the TPF do not carry the calculated user credit and re-authorization event information.

Step 808A: After receiving the charging rule and the credit response, the TPF performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction, that is, establishes a charging rule; and carries the charging rule and the credit authorization request. The billing trigger event is stored.

Step 809A: The TPF returns a bearer setup response to the UE. If the billing is online, and the charging rule and the credit authorization request carry the credit of the user, the TPF accepts the bearer setup initiated by the UE. The request and the subsequent bearer establishment process are continued; if the charging rule and the credit authorization request do not carry the user's credit, the TPF rejects the bearer establishment request initiated by the UE. If the system is offline, the TPF directly accepts the bearer setup request initiated by the UE, and continues the subsequent bearer setup process.

In steps 804A-805A, when the CRF-OCS determines that the UE user does not belong to the network subscriber to which the home subscriber is subscribed, that is, the CRF-OCS is the visited CRF-OCS of the UE, the CRF-OCS acquires the UE-originated CRF-OCS according to the UE identifier. The address information is then forwarded to the UE user-signed CRF-OCS forwarding charging rule request. The CRF-OCS to which the UE user is subscribed returns a charging rule and/or user credit to the TPF via the visited CRF-OCS.

In the bearer setup process, the TPF can directly interact with the CRF-OCS that the UE user subscribes to; or interact with the CRF-OCS that is indirectly signed by the UE user by visiting the CRF-OCS. Therefore, the charging rule is subsequently performed. The process of the credit authorization request is simplified to interact with the CRP-OCS to which the UE belongs.

FIG. 8B is a flow chart showing the process of requesting charging rules and user credits when carrying changes in the present invention. As shown in FIG. 8B, the process of requesting charging rules and user credits during bearer modification includes the following steps:

Step 801B is the same as step 301B.

Step 802B: The bearer modification may trigger a charging trigger event. Therefore, after receiving the bearer modification request, the TPF matches the bearer modification event with the stored charging trigger event. If yes, step 803B is performed; otherwise, the process ends. Current process.

Step 803B: The TPF sends a charging rule and a credit authorization request to the CRF-OCS, where the charging rule and the credit authorization request carry input information for determining the charging rule and the user credit by the CRF-OCS, the charging rule and the credit authorization. The request may further carry the currently occurring charging trigger event, and may further indicate to the TPF the re-authorization event included in the charging trigger event.

Steps 804B to 806B are the same as steps 806A to 808A.

Step 807B: The TPF returns a bearer modification response to the UE. For online charging, if the charging rule and the credit authorization request carry the credit of the user, the TPF accepts the bearer modification request initiated by the UE. And the subsequent bearer modification process is continued. If the charging rule and the credit authorization request carry the error reason value, the TPF rejects the bearer modification request initiated by the UE. For offline charging, the TPF accepts the bearer modification request initiated by the UE, and continues to follow. The bearer modification process.

If the CRF-OCS indicates to the TPF the re-authorization event included in the charging trigger event, the TPF detects whether the charging triggering event is a re-authorization event after the charging triggering event occurs. If yes, the TPF sends the CRF to the CRF. The charging rule and the credit authorization request sent by the OCS carry the CRF-OCS input information for determining the user credit, such as the remaining credit of the user. Otherwise, the charging rule sent by the TPF to the CRF-OCS and the credit authorization request do not carry the CRF. -OCS determines the input information of the user credit; CRF-OCS determines whether to calculate the user credit according to whether the charging rule and the credit authorization request carry the input information for determining the user credit.

If the CRF-OCS does not indicate to the TPF the re-authorization event included in the charging triggering event, and the CRF-OCS receives the currently occurring charging triggering event reported by the TPF, the CRF-OCS determines the currently occurring charging triggering event. When it is a re-authorization event, after the TPF detects the charging trigger event, the charging rule and the credit authorization request sent to the CRF-OCS carry the CRF-OCS input information for determining the user credit, such as the remaining credit of the user. . The CRF-OCS determines whether to calculate the user credit according to the judgment result of the charging trigger event. If the currently generated charging trigger event is a re-authorization event, the CRF-OCS calculates the user credit and provides it to the TPF; The event is not a re-authorization event, then the CRF-OCS does not recalculate the user credit, and the original credit is directly carried in the charging rule and credit response returned to the TPF.

FIG. 8C is a flowchart showing the process of requesting the charging rule and the user credit when the bearer is deleted in the present invention. As shown in FIG. 8C, the process of requesting the charging rule and the user credit when the bearer is deleted includes the following steps:

Step 801C is the same as step 301C.

Step 802O: Step 804C: After receiving the bearer deletion request, the TPF sends a charging rule and a credit authorization request to the CRP-OCS, where the charging rule and the credit authorization request carry the CRF-OCS to determine the charging rule and the remaining credit of the user. . After CRF-OCS receives the charging rules and credit authorization request, the root According to the charging rule and the input information carried in the credit authorization request, an appropriate charging rule may be selected according to the relevant input information provided by the AF, and the remaining credit of the user is processed, and then the charging rule and credit are returned to the TPF. In response, the charging rule and the credit response carry the selected charging rule.

Step 805C to step 806C: After receiving the charging rule and the credit response, the TPF performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction, that is, deletes the charging rule, and then returns a bearer deletion response to the UE, accepting The UE initiates a bearer deletion request and continues the subsequent bearer deletion process.

In addition, the CRF-OCS can also actively send charging rules to the TPF. For example, when the UE and the AF perform service data transmission, the CRF-OCS receives the charging rule input information of the AF, and then inputs according to the charging rule provided by the AF. The information selects the appropriate charging rule, and then proactively delivers the selected charging rule to the TPF. The specific implementation process of providing charging rule input information to the CRF-OCS from the AF is shown in Figure 9:

Step 901 to Step 902: The AF sends application/service charging related information to the CRP-OCS. After receiving the application/service charging related information, the CRF-OCS returns a response to the AF, informing the AF that it has received the charging rule input information sent by the AF.

The AF may be addressed to the corresponding CRF-OCS according to the UE identifier, or may be addressed to the corresponding CRF-OCS according to the data configured by itself, and may also be addressed to the corresponding CRF-OCS according to the acquired CRF-OCS address information.

In addition, after the AF provides input information to the CRF-OCS, the CRF-OCS determines whether the re-authorization process needs to be triggered according to the input information of the AF. If yes, if the CRP-OCS selects an appropriate charging rule according to the input information provided by the AF, It is found that the rate indicated by the charging button in the charging rule changes, and the user credit needs to be calculated by applying a new rate. At this time, the user needs to be re-authorized, and the CRF-OCS sends a re-authorization instruction to the TPF. The TPF is required to provide input information for determining the credit of the user, such as the remaining credit of the user. Otherwise, the re-authorization process does not need to be triggered, and the charging rule selected according to the input information from the AF is directly provided to the TPF, and the specific implementation process is as shown in FIG. Show:

Steps A1 to A2: The AF sends AF input information (AF Input) to the CRF-OCS. After receiving the AF input information, the CRF-OCS returns an AF input information response (AF Input Ack) to the AF, and the notification has been received. Received the input information it sent.

Step A3: The CRF-OCS determines whether the re-authorization process is required according to the received AF input information. If yes, step A4a is performed; otherwise, step A4b is performed.

Step A4a: The CRF-OCS may request the TPF to return the credit usage of the user to the user to effectively control the credit of the user, that is, the CRF-OCS sends a Return Credit Request to the TPF, and requests the TPF to provide it for determination. The input information of the user credit, such as the credit usage of the returned user, that is, the remaining credit.

Step A5a: After receiving the return credit authorization, the TPF sends a charging rule and a credit authorization request to the CRF-OCS, where the charging rule and the credit authorization request carry the input information for determining the charging rule and the user credit by the CRF-OCS. Such as the user's remaining credit.

Steps A6a to A8a are the same as steps 806A to 808A.

Steps A4b to A6b: According to the AF input information, the CRF may also select an appropriate charging rule according to the input information from the TPF, and then provide a charging rule to the TPF, and the charging rule may carry the selected meter. Fee rules and billing rules operational instructions. After receiving the charging rule, the TPF performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction.

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

Claims

Claim

A system for charging based on a packet data stream, the system comprising: a charging rule function entity CRF and an online charging system OCS being combined to form a logical function entity CRF-OCS, wherein the CRP-OCS includes The interface of the Gx reference point and the Gy reference point function is connected to the transmission plane functional entity TPF.

The system according to claim 1, wherein the functions of the Gx reference point and the Gy reference point comprise:

The TPF requests charging rules from the CRF-OCS, and the CRF-OCS provides charging rules to the TPF. Alternatively, the TPF requests credit authorization from the CRF-OCS, and the CRF-OCS provides credit to the TPF; or, the TPF requests charging from the CRF-OCS simultaneously. For rules and credit authorization, CRP-OCS provides billing rules and credits to the TPF at the same time.

The CRF-OCS provides a charging rule triggering event to the TPF. When the TPF monitors the charging rule triggering event, it requests the charging rule from the CRF-OCS; or

The CRF-OCS provides a re-authorization event to the TPF, and requests a credit authorization from the CRF-OCS when the TPF monitors the re-authorization event; or

The CRF-OCS provides the charging rule triggering event and the re-authorization event to the TPF. When the TPF monitors the charging rule triggering event, it requests the charging rule from the CRF-OCS. When the TPF monitors the re-authorization event, it sends the CRF to the CRF. -OCS requests a credit authorization.

The system according to claim 1, wherein the CRP-OCS is further connected to the application function entity AF through an interface including an Rx reference point function.

A processing method based on packet data flow charging, characterized in that the method comprises: requesting, by the TPF, a charging rule and/or a credit authorization to a CRF-OCS including a charging rule function entity CRF and an online charging system OCS After receiving the charging rule and/or the credit authorization request, the CRF-OCS returns the charging rule and/or the user credit to the TPF.

The method according to claim 5, wherein the charging rule and/or the credit authorization request carries input information for selecting a charging rule, or a charging trigger event, or a credit already used by the user. , or the user's remaining credit, or any combination of the above.

The method according to claim 5, wherein the returning the charging rule and/or the user credit to the TPF by the CRF-OCS further comprises: providing a charging rule triggering event and/or a reauthorization event.

A processing method based on packet data flow charging, the method comprising: when a bearer is established, the TPF sends a charging rule to a CRF-OCS including a charging rule function entity CRF and an online charging system OCS. The credit authorization request, for the service data flow that needs to be charged online, the CRF-OCS provides the corresponding charging rule and user credit to the TPF at the same time.

A processing method based on packet data flow charging, characterized in that, when a bearer is established, the TPF requests a charging rule from a CRP-OCS including a charging rule function entity CRF and an online charging system OCS, and CRF-OCS determines Whether the UE user is the network user to which the subscriber is subscribed, and if so, directly returns the charging rule and/or the user credit to the TPF; otherwise, the TPF is provided with the address information of the CRF-OCS of the UE user's home subscription, and the TPF receives the The CRF-OCS address information sends a charging rule and a credit authorization request to the CRF-OCS. After receiving the charging rule and the credit authorization request, the CRF-OCS to which the UE belongs returns the charging rule and/or the user credit to the TPF.

A processing method based on packet data flow charging, characterized in that, when a bearer is established, the TPF requests a charging rule from a CRF-OCS including a charging rule function entity CRF and an online charging system OCS, and CRF-OCS determines Whether the UE user is the network user to which the subscriber is subscribed, and if so, directly returns the charging rule and/or the user credit to the TPF; otherwise, the CRF-OCS forwards the charging rule request to the UE user-signed CRF-OCS, the UE user The home-signed CRF-OCS returns charging rules and/or user credits to the TPF via a visit to the CRF-OCS.

A processing method based on packet data flow charging, the method comprising: the charging trigger function entity CRF and the CRF-OCS of the online charging system 0CS provide a charging trigger event to the TPF, and the TPF monitors When the accounting trigger event occurs, it is reported to the CRF-OCS.

The method according to claim 11, wherein the charging triggering event is: a charging rule triggering event, or a re-authorization event, or a combination of the two.

The method according to claim 11 or 12, wherein the reporting to the CRF-OCS is: transmitting, to the CRF-OCS, a charging rule and a credit authorization request carrying a charging trigger event that occurs.

14. The method according to claim 13, wherein the charging triggering event that occurs includes a charging rule triggering event that occurs and/or a re-authorization event that occurs, and is sent to the CRF-OCS. Before the charging rule and the credit authorization request of the charging triggering event, the method further includes: determining, by the TPF, whether the charging triggering event is a re-authorization event, and if yes, sending the re-authorization event to the CRJF-OCS The fee rule and the credit authorization request, the charging rule and the credit authorization request further carry the user credit usage information.

15. The method according to claim 13, wherein the charging triggering event that occurs includes a charging rule triggering event that occurs and/or a reauthorization event that occurs.

The charging rule and the credit authorization request further carry user credit usage information, and after the sending, by the CRF-OCS, the charging rule and the credit authorization request carrying the charging trigger event, the method further includes: CRF-OCS receiving After the charging rule and the credit authorization request, it is determined whether the charging trigger event reported by the TPF is a re-authorization event. If yes, the CRF-OCS selects the charging rule according to the triggered re-authorization event and recalculates the user credit, and then calculates The fee rules and user credits are provided to the TPF; otherwise, the CRF-OCS selects the charging rules and provides them to the TPF.

16. A processing method based on packet data flow charging, characterized in that the method comprises: the AF providing input information for selecting a charging rule to the CRF-OCS.

17. The method of claim 16, wherein the method further comprises: the CRF-OCS returning to the AF a response indicating receipt of the input information.

18. A processing method based on packet data flow charging, characterized in that: the method comprises: CRF-OCS requires the TPF to return the usage of the user credit, and the TPF returns the user credit usage information to the CRF-OCS.