WO2006050669A1

WO2006050669A1 - A process method for charging based on the packet data flow

Info

Publication number: WO2006050669A1
Application number: PCT/CN2005/001897
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: CN100527676C; CN1773922A

Abstract

A process method for charging based on the packet data flow, adding a charging information collection function to the CRF, increasing the intercommunication flow between the CRF and OCS, making the OCS can supply the credit information to the CRF according to the credit request of CRF, e.g. a specific line of credit, whether the line of credit is enough, and the like, and the CRF can return the reimbursable line of credit to the OCS, the OCS reimburses the corresponding line of credit to the user’s account; and increasing the intercommunication flow between the CRF and AF, making the CRF can know the service subscribed by user, and the information whether the use of service is successful. In addition, this invention also provides a system for charging based on the packet data flow, increasing a signaling interface between the CRF and CDF/CGF, making the CRF can report the information generated on the condition of on-line or off-line to the charging center via the CDF/CGF, so that the gathering of service charging based on the FBC system structure is achieved, the demand that running the service in the network is satisfied.

Description

Processing method and system based on packet data flow charging

The present invention relates to the field of packet data charging, and more particularly to a processing method and system 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.

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

Step 101: The mobile terminal (MS) sends a PDP Context Request (Active PDP Context Request) to the Serving GPRS Support Node (SGSN), where the Activate PDP Context Request carries the network access 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., 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 by the MS to identify a PDP context.

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

Step 103: The SGSN parses the address information of the GGSN according to the APN. If the SGSN can parse the address information of the GGSN according to the APN, the TEID is created for the PDP Context, and the TEID can be an International Mobile Subscriber Identity (IMSI) and an NSAPI. The SGSN sends a PDP Context Request to the GGSN. The PDP Context Request contains the PDP type, PDP address, APN. QoS parameter, TEID, and selection mode. The PDP address can be MS. The IP address, which is an optional parameter, may not carry a PDP address in the PDP Context creation request. In this case, the GGSN may assign a DP address to the MS in the subsequent processing, or may allocate 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 the external PDN, 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 is sent to the SGSN. The PDP Context Create Response (Representation PDP Context Response), which carries the TEID, the PDP address, the Backbone Bearer protocol, the agreed QoS parameters, and the Charging ID. If the GGSN cannot meet the quality of service requirements of the QoS parameters, the GGSN rejects the PDP Context creation request initiated by the SGSN. The SGSN then rejects the PDP Context activation request initiated by the MS.

Step 105: After receiving the PDP Context creation response, the SGSN inserts NSAPI and GGSN address information for identifying the PDP Context in the PDP Context, and selects a radio priority according to the agreed QoS parameter, and then returns a PDP Context activation response to the MS (Activate PDP Context Accept), the PDP Context activation response carries information such as PDP type, PDP address, TI, agreed QoS parameters, wireless priority, PDP configuration options, and the like. 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 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 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 SGS sends a PDP Context Request to the GGSN, where the PDP Context delete request carries ΤΕΠ).

After receiving the PDP Context deletion request, the GGSN ends the charging of the MS, deletes the PDP Context corresponding to the TEID, and then sends a PDP Context Response (DDP) to the SGSN. The PDP Context delete response carries the TEID. After receiving the PDP Context deletion response, the SGSN ends the charging of the MS, deletes the PDP Context corresponding to the TEID, and then sends a PDP Context Deactivation Response (Deactivate PDP Context Response) to the MS. The PDP Context deactivation response carries the TL. 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 and the PDN perform data interaction, the MS can perform multiple services based on an activated PDP Context, that is, if the PDN can provide multiple services, such as an email (email) transceiver service, 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 email receiving and dispatching service, the charging and receiving events can be triggered based on the email, and the WAP browsing service can be used for the flow metering. Fees, for the file transfer service can also be based on the flow rate, the WAP browsing service rate and the file transfer service rate are not the same, thus, according to the existing GPRS billing system, can not be the same PDP Context The different services carried are differentiated and charged.

In response to the above situation, the 3rd Generation Partnership Project (3GPP, 3rd Generation Partnership Project) is currently discussing how to implement FBC (Flow Based Charging). For a packet data service, when the user of the MS uses the service, all IP data streams (IP Flow) transmitted and received may also be EP packets, which are collectively referred to as Service Data Flow. ), that is, the service data stream is a set of multiple IP data streams, so the charging based on the IP data stream can truly reflect the occupation of resources by a certain service data stream. The IP data stream-based charging can be considered as filtering out the IP data streams of different services carried in the same PDP Context through some filter-like filters, and then separately filtering the data streams 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 a DP 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 charging 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 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 CRJF 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 the Charging Data Function (CDF).

The TPF 205 carries the DP data stream. When the bearer of the IP data stream is established, the TPF 205 sends a charging rule request to the CP 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 (SI), 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 re-send the charging rule request to the CRP 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 rate is 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 BP data streams the TPF 205 filters, and then the TPF 205 filters the filtered IPs according to the charging rules. The data stream is billed. The service data filter may include an IP5 tuple, and the EP5 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 _f , the protocol type is Transmission Control Protocol (TCP), and the filtered BP data stream is filtered according to the charging rule. Billing.

The CRP 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 CRP 205 when a specific event occurs, such as the CRP 203 requesting the TPF 205 to perform an event modification on some bearers. At the time, a new charging rule is requested from the CRF 203. Trigger events can be thought of as events related to billing rules. At present, the 3GPP specification describes the charging mode of the CRF that controls the TPF through the triggering event reporting mechanism, that is, the TPF reports the triggering event to the CRP, and the CRF learns the change of the bearer through the triggering event reported by the TF, and then determines the corresponding The charging rule is delivered 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 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 current use by the user. The service type, CRP 203 selects the corresponding charging rule according to the service type.

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 authenticates the credit in the user's credit pool, and delivers the user to the TPF 205 through the Gy interface. credit.

In addition, the OCS 206 may request the TPF 205 to re-assert the user when the re-authorisation triggers occur, and then the OCS 206 re-authenticates the user according to the corresponding re-authentication event reported by the TPF 205, and It is possible to 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, such as the PLMN changes, TPF 205 is required to report the occurrence of the PLMN change event to the OCS 206 according to the PLMN change event in the re-authentication event, and the OCS 206 re-determines the rate according to the current location of the user, and recalculates the user's credit. For another example, when the OCS 206 determines the rate according to the current QoS parameters of the service used by the user, when the user performs 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 according to the modified QoS parameter of the user, and recalculates the credit of the user.

In addition, the 3GRP 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 event 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 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 CRP 203 is the control point of the charging rule.

For the current FBC system structure, the charging information collection point in the case of offline charging is TPF, and the TPF collects information for the service data stream, such as the data traffic transmitted by the service data stream, the length of time used by the service data stream, etc., and then generates Billing information, and the billing information is sent to the billing center via CGF/CDF 207; the billing information collection point in the case of online billing is TPF and OCS, and the TPF collects information for the service data stream, and the meter The fee information is sent to the billing center via the CGF/CDF, and the OCS collects the charge deduction information, and then generates the billing information, and sends the billing information to the billing center via the CGF/CDF.

However, in the actual network operation, for the value-added service part, the operator usually charges the user two kinds of communication fees and service charges, and the communication fee is used to measure the network resources occupied by the user, which is also called the traffic fee or the bearer fee. The business expense is used to measure the business information of the user using the service. It is also called content fee or information fee. For example, the user passes the mobile terminal The use of "watching TV, business, operators not only need to charge users to use the "watch TV" business process, the data traffic caused by the transmission of services or the length of time used to use the service, but also need to charge the user to watch the TV For example, if the user uses the "game download" service, the operator not only needs to charge the user for the fee generated by the data flow during the download of the game, but also needs to charge the user for the user to purchase the game.

Generally, business applications such as TV programs and games can be developed by a dedicated service provider (SP) and provide various business applications to users through cooperation with network operators. Although the SP can directly charge the user for the service fee, the SP needs to establish a channel for charging the user for the service fee, such as a billing system, but the method of using the SP to establish the billing system on its own will increase the cost of the SP and improve the cost. The threshold of the SP is not conducive to the SP itself; on the other hand, the SP itself needs to solve the trust problem of the SP by the user to establish the charging system. Therefore, most network operators currently charge the service fee instead of the SP, and perform the same with the SP. The charging mode of business cost sharing, such as China Mobile's "Mobile Monternet" platform and China Unicom's "Unicom Unlimited" is a platform that integrates SPs and provides unified billing. Through the network operator's collection of business expenses, the network operator can focus on the operation of the network only. The SP can focus on the development of the business application only. The user only needs to face a unified charging system and one at the same time. User bills for communication charges and business expenses.

However, based on the current FBC system structure, since there is no signaling interface between the TPF and the AF, the TPF cannot know the information about the success or failure of the service, for example, for the download service, if an abnormal interruption occurs during the download process. At this time, only the communication fee should be charged, and the business fee should not be charged; 'And TPF cannot know the user's subscription service. For example, the charging method used by a user when ordering a service is the monthly subscription. Billing, TPF cannot know that the user's business expenses should be deducted uniformly every month, but not every time the user uses the business. Therefore, based on the current FBC system structure, the charging of business expenses cannot be realized, and the requirements for business operations in the network cannot be met. Summary of the invention

In view of this, an object of the present invention is to provide a processing method based on packet data flow charging, and another object of the present invention is to provide a system based on packet data flow charging, which satisfies service operation in a network. Claim.

In order to achieve the above object, the present invention provides a processing method based on packet data flow charging, the method comprising: a CRF sends a credit request to an OCS, and the OCS returns a credit response to the CRF

Wherein, the credit response carries information on whether the credit line or the credit line is sufficient. The method further includes: the CRF rolls back the credit line that needs to be replenished to the OCS, and the OCS replenishes the received credit line to the user's account.

The OCS receives the credit line that needs to be replenished, and then further includes: The OCS returns a response to the CRP for notifying the CRF that the credit line that needs to be replenished has been received.

The present invention also provides a processing method based on packet data flow charging, the method comprising: the AF notifying the CRF user to request to use the service, the CRF determining whether to allow the user to use the service according to the service subscription information, and if so, notifying the A to provide the user with the service The service; otherwise, the notification AF does not provide the service to the user.

The service subscription information is provided by the AF to the CRF when the user subscribes to the service.

After receiving the service subscription information provided by the AF, the CRF further includes: the CRF returns a response to the AF for notifying that the AF has received the service subscription information.

The notification AF provides the user with the service, and further includes: collecting the CRF start billing information.

The notification AF provides the user with the service, and then further includes the step al: AF notifying the CRJF user of the service usage.

The step a1 further includes: the CRF returns to the AP to notify the AF that it has received Response to business usage.

The step al further includes the step bl: CRP stops collecting the charging information. The step bl further includes: the CRJF sending the charging information to the CDF/CGF. In the case of online charging, the notification AF provides the user with the service, and further includes: the CRF sends a credit request to the OCS, and the OCS returns a credit response to the CRJF.

The step al further includes: the CRJF rolls back the credit amount to be replenished to the OCS, and the OCS replenishes the received credit line to the user's account.

In order to achieve the above object, the present invention further provides a system for charging based on packet data stream, the system comprising: a CRF connected to a TPF, configured to enable a CRF to provide a charging rule to the TPF, and the TPF is connected to the CDF/CGF, The TPF provides charging information corresponding to the bearer to the CDF/CGF; in the system, the AF is connected to the CR for transmitting service related information, and the CRF is connected to the CDF/CGF, and the CRF is provided with the corresponding service to the CDF/CGF. Fee information.

The CRF is connected to the CDF/CGF via an Rz interface.

The system further includes: an OCS, connected to the TPF, for providing credit information to the TPF according to the request of the TPF; and connected to the CRF for providing credit information to the CRF according to the request of the CRF.

According to the solution proposed by the present invention, the charging information collection function is added in the CRF, and the interaction process between the CRJF and the OCS is increased, so that the OCS can provide credit information to the CRP according to the CRF credit request, such as a specific credit limit and credit limit. Whether the information is sufficient or not can also enable the CRF to return the credit line to be replenished to the OCS, and the OCS will replenish the corresponding credit limit to the user's account; and increase the interaction process between the CF and the AF, so that the CRF can know the user's order. The situation of the business, and the ability to know the success or failure of the business. In addition, the signaling interface between the CF and the CDF/CGF is added, so that the CRP can report the charging information generated by the online charging or the offline charging to the charging center through the CDF/CGF. The collection of business expenses based on the FBC system structure, satisfied in the network Requirements for conducting business operations in the middle. BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a PDP Context activation, data transmission, deactivation flowchart; FIG. 2A shows a schematic structural diagram of an FBC system supporting online charging;

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

FIG. 3A is a schematic diagram showing a process for implementing CRF requesting credit information from an OCS in the present invention; FIG. 3B is a schematic diagram showing a process for implementing CRF to OCS replenishment credit line in the present invention; FIG. 4A is a view showing a CRF obtaining user through AF in the present invention; Schematic diagram of the business order realization process;

FIG. 4B is a schematic diagram showing the process of realizing the use of the service by the CRF through the AF in the present invention;

5A is a schematic structural diagram of an FBC system supporting online charging in the present invention; FIG. 5B is a schematic structural diagram of an FBC system supporting offline charging in the present invention; FIG. 6 is a schematic diagram showing an implementation process of the first embodiment of the present invention. ;

FIG. 7 is a schematic diagram showing the implementation process of the second embodiment of 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 charging information collection function is added in the CRF, and the interaction process between the CRF and the OCS is increased, so that the OCS can provide credit information to the CRF according to the CRF credit request, such as whether the specific credit limit and the credit limit are sufficient. The information can also enable CRP to 'return the credit line to be replenished to the OCS, and OCS will replenish the corresponding credit limit to the user's account; and increase the interaction process between CRF and AF, so that CKF can know the user subscription. Information on the purchase of a business, and information on the success of the use of the business. In addition, increase

The signaling interface between the CRF and the CDF/CGF enables the CRF to report the charging information generated by the online charging or offline charging to the charging center through the CDF/CGF, thereby implementing the structure based on the FBC system. The collection of business expenses meets the requirements for business operations in the network. '

FIG. 3A is a schematic diagram of a process for implementing CRJF requesting credit information from an OCS in the present invention. As shown in FIG. 3A, the process for requesting CRP to request credit information from an OCS includes the following steps: Step 301A to Step 302A: CR sends a credit request to the OCS ( Credit Request), the credit request carries user identification, business information, rate information, and the like for the OCS to determine the input information of the credit information. After receiving the credit request, OCS returns a credit response (Credit Response) to the OCS, and the credit response carries credit information, such as information such as the user credit limit calculated by the OCS and whether the credit limit is sufficient.

In the case that the credit limit is not consumed or not consumed, the CRF can return the credit amount to be replenished to the OCS, and the OCS will replenish the corresponding credit limit to the user's account.

FIG. 3B is a schematic diagram showing the process of implementing the CRF to the OCS credit line in the present invention. As shown in FIG. 3B, the process of implementing the CRF to the OCS credit line includes the following steps: Step 301B to Step 302B: CF sends a credit to the OCS. A credit return message, which carries information such as a user identifier, business information, and a credit line that needs to be replenished. After receiving the credit replenishment message, OCS will replenish the credit line to be replenished to the user's account, and then return a response (Ack) to the CRF to inform CR that the corresponding credit line has been replenished.

The credit line that needs to be replenished as described above may be the remaining credit line after consuming the credit line allocated by the OCS, or may be the entire credit limit of the CRF request. Here, the application scenario of the CRF replenishing the credit line process to the OCS may be: when the business use is unsuccessful, the credit line is not consumed, and the CRF returns all the requested credit lines to the OCS, or the credit line is not After the consumption is completed, the CRP only returns the unconsumed remaining credit line to the OCS, and then the OCS will replenish the received credit line to be replenished to the user's account. In addition, the application scenario of the CRF to the OCS credit limit process may also be: When the service is successfully used, if the requested credit limit has not been exhausted, the CRF needs to roll back the unused credit line to the OCS, and then the OCS will receive The credit line to be replenished is replenished to the user's account.

FIG. 4A shows a schematic diagram of the implementation process of the user service subscription by the CRF in the present invention. As shown in FIG. 4A, the implementation process of the CRF to learn the user service subscription through the AF includes the following steps:

Step 401 to step 402: When the user subscribes to the service, the AF sends a service subscription message (Subscribed Info) to the CRF, where the service subscription message carries service subscription information, such as user identification, service information, and charging mode, and the charging mode. It can be used for monthly billing, billing by number, billing by number, billing by page, and so on. After receiving the service subscription message, the CRF stores the subscription information and can further return a response to the AF, informing the AF that it has received the service order information it sent.

FIG. 4B is a schematic diagram showing the process of implementing the service usage of the CRF through the AF in the present invention. As shown in FIG. 4B, the implementation process of the CRJF learning the service usage by using the AF includes the following steps:

Step 401B: The AF sends a service start message (Service Start) to the CRF, where the service start message carries the user identifier, the service information, and the like, and notifies the CRJF user to start using the corresponding service.

Step 402B: The CRF determines whether the user can use the corresponding service according to the previously obtained service subscription information. If the user can use the corresponding service, in the case of offline charging, the service continues to send a service continuation message (Service Continue) to the AF, and then records related information. If the collection of billing information is started, step 403B may be subsequently performed; in the case of online billing, CR interacts with the OCS to obtain a corresponding credit line, if the OCS provides a credit limit or returns a credit. If sufficient information is available, the CRF sends a service continuation message to A, and then records relevant information, such as starting the collection of the charging information, and subsequently performing step 403B. If the OCS does not provide the credit limit or returns the insufficient credit information, the CKF sends the information to the AF. A service termination message (Service Terminate), which may carry a termination reason. If the user is unable to use the corresponding service, the CRF sends a service termination message to the AF, and the service termination message may carry a termination reason.

Step 403B: If the user successfully uses the service, the AF sends a service success message (Service Success) to the CRF, and the CRF user is successfully used to use the service. If the user fails to use the service, the service failure message is sent to the CRF. Service Failure), informing the CRP user that the service failed.

Step 404B: After receiving the service success/failure message, the CRF ends the collection of the charging information, and may further return a response to the AF, and notify the AF that the user's service usage is known. In the case of online charging, after the CRF receives the service success message, if the allocated credit limit has not been consumed, the CRP can return the unused credit limit to the OCS. After the CRP receives the service failure message, the CF can roll back to the OCS. The credit line that needs to be replenished, the OCS will replenish the credit line to be replenished to the user's account; after the CRF receives the service failure message, the credit line is not consumed, and the CRF will refund all the requested credit lines. To the OCS, or the credit line is not consumed, the CRF only returns the unconsumed credit line to the OCS, and the OCS then replenishes the credit line to be replenished to the user's account.

FIG. 5A is a schematic diagram showing the structure of an FBC system supporting online charging in the present invention. As shown in FIG. 5A, in the case of online charging, the CRF 203 is connected to the CDF/CGF 207 through the Rz interface, and the CRF 203 is used for charging. The information is sent to the CDF/CGF 207, and then the billing information provided by the CRF 203 is reported to the billing center by the CDF/CGF 207, thereby realizing the charging of the service fee based on the FBC system structure in the online case.

FIG. 5B is a schematic diagram showing the structure of the FBC system supported by the present invention; As shown in FIG. 5B, in the case of offline charging, CRF 203 is connected to CDF/CGF 207 through the Rz interface, CRF 203 is used to send charging information to CDF/CGF 207, and then CDF/CGF 207 provides the meter provided by CRF 203. The fee information is reported to the billing center, thereby realizing the charging of the business fee based on the FBC system structure under the online situation.

The connection between the CRF and the CDF/CGF is not limited to being connected through the Rz interface, and other connection methods may be used, such as being indirectly connected through other functional entities.

Regardless of online charging or offline charging, the charging information collection point for service charging is CRP. The CRF collects information for service usage, and then generates charging information, and the charging information is transmitted via CGF/. The CDF 207 is sent to the billing center to collect the business charges based on the FBC system structure.

FIG. 6 is a schematic diagram of an implementation process of the first embodiment of the present invention. As shown in FIG. 6, the specific implementation process of the CRF as the offline charging information collection point in the embodiment includes the following steps: Step 601 to Step 603: AF receives The user subscribes to a service (Subscribe to a Service), and learns that the user subscribes to a certain service, and then sends a service subscription message to the CRF, where the service subscription message carries service subscription information, such as user identification, service information, and charging mode. The billing mode can be monthly billing, billing by number, billing by number, billing by page, and so on. After receiving the service subscription message, the CRF stores the subscription information and can further return a response to the AF, informing the AF that it has received the service order information sent by it.

Step 604 to step 605: After receiving the service request (Service Request) sent by the user, the AF sends a service start message to the CRF, where the service start message carries the user identifier, the service information, and the like, and notifies the CRJF user to start using the corresponding service.

Step 606 to step 607: The CRF determines whether the user can use the corresponding service according to the previously obtained service subscription information. If yes, sends a service continuation message to the AF, and then records related information, such as collecting charging information, and the AF receives the CRF. After the sent service continues the message, the service acceptance message is returned to the user, and the user is notified that the service request has been accepted, and the subsequent Step 608; Otherwise, the CRF sends a service termination message to the AF, and the service termination message may carry a termination reason. After receiving the service termination message sent by the CRF, the AF sends a service rejection message to the user, where the service rejection message can be carried. There is a reason for rejection.

Step 608 to step 609: If the user successfully uses the service, the AP sends a service success message to the CF to notify the CRF user to successfully use the service. If the user fails to use the service, the AP sends a service failure message to the CRF. The CRP user failed to use the service. After receiving the service success/failure message, the CRF ends the collection of the accounting information, and further returns a response to the AF, notifying the AF that the user's service usage is known.

Finally, the CRF generates charging information related to the service usage, and reports the charging information to the charging center through the CDF/CGF, and the charging center generates a business expense list related to the service usage situation for the user.

FIG. 7 is a schematic diagram of the implementation process of the second embodiment of the present invention. As shown in FIG. 7, the specific implementation process of the CRF as the online charging information collection point in the embodiment includes the following steps: Step 701 to Step 705 and Step 601 ~ Steps are the same according to 605.

Step 706 to step 707: The CR determines whether the user can use the corresponding service according to the previously obtained service subscription information. If yes, the OCS sends a credit request, where the credit request carries the user identifier, the service information, the rate information, etc. for the OCS. After determining the input information of the credit information, the OCS returns a credit response to the OCS after receiving the credit request, and the credit response carries the credit information, such as the credit quota calculated by the OCS, whether the credit quota is sufficient, etc.; otherwise, directly executing step 708 The service termination message is sent to the AF, and the service termination message may carry a termination reason.

Step 708 to step 709: If the OCS provides the credit limit or returns the credit sufficient information, the CRP sends a service continuation message to the AF, and then records relevant information, such as collecting the collection of the charging information, and the AF receives the service continuation message sent by the CR. After returning a service acceptance message to the user, notifying the user that the service request has been accepted, and subsequently performing step 710; if OCS If the credit limit is not provided or the credit deficiency information is returned, and the user is unable to use the corresponding service, the CRF sends a service termination message to the AF, and the service termination message may carry the termination reason, and after the AF receives the service termination message sent by the CR, A service rejection message is sent to the user, and the service rejection message may carry a reason for rejection.

Step 710 to step 711 are the same as steps 608 to 609.

In the case of online charging, when the service is successful, if the credit limit has not been used or the service fails, the CRP also needs to return the credit limit that needs to be replenished to the OCS, that is, the CRF sends a credit replenishment message to the OCS, in the credit replenishment message. User identification, business information, credit lines that need to be replenished, etc. After receiving the credit replenishment message, OCS will need to replenish the credit line, and then return a response (Ack) to CRP to inform CRF that the corresponding credit line has been replenished.

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 processing method based on packet data stream charging, characterized in that the method comprises: the CR transmitting a credit request to the OCS, and the OCS returning a credit response to the CRF.

The method according to claim 1, wherein the credit response carries information on whether the credit limit or the credit limit is sufficient.

3. The method according to claim 1, wherein the method further comprises: the CRF rolling back a credit limit that needs to be replenished to the OCS, and the OCS replenishes the received credit limit to the user's account.

The method according to claim 3, wherein the OCS receives a credit line that needs to be replenished, and then further includes: the OCS returns a response to the CR for notifying that the CR has received the credit line that needs to be replenished. .

A processing method based on packet data stream charging, the method comprising: the AF notifying the CR user to request to use the service, the CRF determining whether to allow the user to use the service according to the service subscription information, and if yes, notifying the AF as the user Providing the service; otherwise, notifying the AF that the service is not provided to the user:

The method according to claim 5, wherein the service subscription information is provided by the AF to the CRF when the user subscribes to the service.

The method according to claim 6, wherein after receiving the service subscription information provided by the AF, the CRF further comprises: the CRF returning a response to the AF for notifying that the AF has received the service subscription information.

The method according to claim 5, wherein the notifying the AF to provide the service to the user, and further comprising: collecting the CRF starting charging information.

The method according to claim 5, wherein the notifying the AF provides the service to the user, and further comprising: Al, AF informs the CRF user of the business usage.

The method according to claim 9, wherein the step al further comprises: the CRF returning to the AF a response for notifying that the AF has received the service usage.

The method according to claim 9, wherein the step al further comprises:

Bl, CRF stop charging information collection.

The method according to claim 11, wherein the step bl further comprises: the CRF sending the charging information to the CDF/CGF.

The method according to any one of claims 5 to 12, wherein, in the case of online charging, the notification AF provides the user with the service, and the method further comprises: sending a credit request to the OCS, the OCS to the CRJF Returns the credit response.

The method according to claim 13, wherein the step a1 further comprises: the CRF retreating to the OCS a credit line that needs to be replenished, and the OCS replenishing the received credit line to the user's account. on.

15. A system based on packet data flow charging, 'the system comprises:

The CRF is connected to the TPF and is used to enable the CR to provide charging rules to the TPF.

The TPF is connected to the CDF/CGF and is used by the TPF to provide the CDF/CGF with billing information corresponding to the bearer;

Characterized in the system,

The AP is connected to the CRF and is used to transmit service related information.

The CRF is connected to the CDF/CGF and is used by the CRF to provide the CDF/CGF with billing information corresponding to the service.

16. The system according to claim 15, wherein the CR and the CDF/CGF are connected through an Rz interface.

17. Method according to claim 15 or 16, characterized in that the system is further The steps include: OCS, connected to the TPF, for providing a credit letter to the TTPF according to the request of the TPF

And connected to the CRF, used to provide credit information to CRJF according to the CRP request.