WO2006060964A1 - Systeme et procede de traitement permettant une facturation en fonction du flux de paquets de donnees - Google Patents

Systeme et procede de traitement permettant une facturation en fonction du flux de paquets de donnees Download PDF

Info

Publication number
WO2006060964A1
WO2006060964A1 PCT/CN2005/002139 CN2005002139W WO2006060964A1 WO 2006060964 A1 WO2006060964 A1 WO 2006060964A1 CN 2005002139 W CN2005002139 W CN 2005002139W WO 2006060964 A1 WO2006060964 A1 WO 2006060964A1
Authority
WO
WIPO (PCT)
Prior art keywords
ocs
crf
charging
tpf
credit
Prior art date
Application number
PCT/CN2005/002139
Other languages
English (en)
Chinese (zh)
Inventor
Xiaoqin Duan
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2006060964A1 publication Critical patent/WO2006060964A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications

Definitions

  • 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
  • FIG 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
  • GPRS General Packet Radio Service
  • PDN Packet Data Network
  • deactivation flow diagram as shown in Figure 1, in the General Packet Radio Service (GPRS, General Packet Radio Service), activated
  • GPRS General Packet Radio Service
  • PDN Packet Data Network
  • 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.
  • GGSN Gateway GPRS Support Node
  • TID Tunnel Identifier
  • the PDP type includes the end-to-end protocol (PPP, Peer).
  • 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.
  • IMSI International Mobile Subscriber Identity
  • 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.
  • 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.
  • the MS 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
  • 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.
  • 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.
  • PDP Context deletion response carries the TEID.
  • 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. .
  • the MS deletes the PDP Context corresponding to TI.
  • 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.
  • 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.
  • email email
  • WAP Wireless Application Protocol
  • FTP file transfer protocol
  • an active PDP Context can be used to carry various services that the PDN can provide.
  • 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.
  • IP Flow IP data streams
  • IP Flow IP data streams
  • Service Data Flow IP data streams
  • 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.
  • 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.
  • 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.
  • CCF Service Data Flow Based Charging Rule Function
  • AF Application Function Entity
  • TPF Traffic Plane Function
  • 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.
  • 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.
  • MSISDN mobile station international number
  • IMSI international mobile subscriber identity
  • MNC mobile network coding
  • MCC mobile country code.
  • 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.
  • the IP quintuple includes the source/destination IP address, the source/destination port number (Port Number), the protocol identifier (Protocol ID), and the like.
  • 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.
  • TCP
  • 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.
  • Event Trigger a trigger event
  • Trigger events can be thought of as events related to billing rules.
  • 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.
  • 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.
  • PLMN public land mobile communication network
  • RAT radio access technology
  • TFT transport stream templates
  • the CRF 203 may also select an appropriate charging rule based on the input information of the AF 204 or the OCS 206, such as the AF 204 notifying the CRF 203 of the service currently used by the user. Type, CRF 203 selects the corresponding charging rule according to the type of service.
  • the OCS 206 is composed of two functional entities, 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.
  • the CCF 202 manages and controls the user credit.
  • 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. .
  • 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.
  • 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.
  • the OCS 206 determines the rate according to the current QoS parameter of the service used by the user
  • 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.
  • 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.
  • the TPF 205 is a GGSN
  • the AF is a service gateway or a service server in the PDN
  • the CRF 203 is a new logical entity.
  • TPF 205 is the enforcement point of the charging rule
  • CRF 203 is the control point of the charging rule.
  • 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:.
  • TPF established Bearer Service 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. '
  • Step 301B The UE sends a Modify Bearer Service Request to the TPF.
  • 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.
  • 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.
  • Step 301C The UE sends a Bearer Delete Request (Remove Bearer Service Request) to the TPF.
  • 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.
  • OCS 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.
  • Bearer Service Accept Remove Bearer Service Accept
  • 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.
  • 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.
  • the bearer modification triggers the flow that the TPF requests the OCS to re-authorize the user.
  • Figure 4B 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • an object of the present invention is to provide a system for charging based on packet data stream
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 1 shows a PDP Context activation, data transfer, deactivation flowchart
  • FIG. 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. 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. 4B is a flowchart of a bearer modification process during online charging in the prior art
  • FIG. 5 is a flow chart showing the input of charging rules by the AF to the CRF
  • FIG. 6 shows a flow chart of the CRF actively issuing charging rules to the TPF
  • FIG. 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. 8B is a flowchart showing a process of requesting charging rules and user credits when carrying modifications in the present invention
  • 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. 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
  • 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 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.
  • 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.
  • 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.
  • 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.
  • the charging rule triggering event 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.
  • 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.
  • the collection of the charging rule triggering events and the re-authorization events is referred to as a Charging Trigger.
  • the TPF 205 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.
  • 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 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.
  • the charging rule request and the credit authorization request may be implemented in the same message.
  • 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.
  • 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.
  • the TPF 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 are carried by the CRF-OCS.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the TPF accepts the bearer modification request initiated by the UE, and continues to follow. The bearer modification process.
  • 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.
  • the CRF-OCS determines the currently occurring charging triggering 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.
  • 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. .
  • 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.
  • the CRF-OCS can also actively send charging rules to the TPF.
  • 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.
  • 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.
  • AF Input AF input information
  • AF Input Ack AF input information response
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Meter Arrangements (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un système et un procédé de facturation dépendant du flux de paquets de données, dans lesquels la fonction de règles de facturation (CRF) et le système de facturation en ligne (OCS) forment ensemble une fonction logique (CRF-OCS). Cette fonction CRF-OCS est couplée à la fonction plan de trafic (TPF) par l'intermédiaire d'une interface comprenant une fonction à point de référence Gx et point de référence Gy. Le déclenchement d'événements peut être combiné avec le déclenchement d'une nouvelle autorisation. Le mécanisme de rapport d'événements de la fonction TPF est ainsi unifié. L'invention porte en outre sur une pluralité de processus associés à la configuration du système OCS, dépendant de la fonction CRF mise en oeuvre, et comprenant un processus d'interaction entre les règles de facturation des services fournis et le crédit utilisateur, entre la fonction TPF et la fonction CRF-OCS, un processus d'interaction entre les fonctions CRF-OCS et TPF activé par le déclenchement de l'opération de facturation, un processus d'interaction entre des informations connexes entre les fonctions CRF-OCS et AF, et un processus d'interaction associé à l'état du crédit utilisateur entre RPF et CRF-OCS. Cette configuration permet de clarifier les processus se déroulant entre les fonctions TPF et OCS, ou entre les fonctions TPF et CRS.
PCT/CN2005/002139 2004-12-09 2005-12-09 Systeme et procede de traitement permettant une facturation en fonction du flux de paquets de donnees WO2006060964A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB2004100985442A CN100341278C (zh) 2004-12-09 2004-12-09 一种基于分组数据流计费的系统及处理方法
CN200410098544.2 2004-12-09

Publications (1)

Publication Number Publication Date
WO2006060964A1 true WO2006060964A1 (fr) 2006-06-15

Family

ID=36577669

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/002139 WO2006060964A1 (fr) 2004-12-09 2005-12-09 Systeme et procede de traitement permettant une facturation en fonction du flux de paquets de donnees

Country Status (2)

Country Link
CN (1) CN100341278C (fr)
WO (1) WO2006060964A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101296169B (zh) * 2007-04-26 2010-12-08 华为技术有限公司 一种用户会话承载业务建立方法、系统及设备
CN102056117B (zh) * 2009-11-03 2015-08-12 中兴通讯股份有限公司 基于策略和计费控制架构的计费方法与系统
WO2012106881A1 (fr) * 2011-07-12 2012-08-16 华为技术有限公司 Procédé de facturation, dispositif d'accès au réseau et dispositif de cœur de réseau
CN102647696A (zh) * 2011-12-09 2012-08-22 中兴通讯股份有限公司 多媒体业务的计费方法及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002093835A1 (fr) * 2001-05-14 2002-11-21 Ntt Docomo, Inc. Appareil et procede de facturation de services de communication mobile
JP2003134111A (ja) * 2001-10-26 2003-05-09 Nec Corp ルールベースレイティングシステムおよび方法ならびにプログラム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8699472B2 (en) * 2000-05-24 2014-04-15 Nokia Corporation Common charging identifier for communication networks
JP2002135311A (ja) * 2000-10-23 2002-05-10 Nec Corp パケット通信の課金システム及び方法
US20030152039A1 (en) * 2002-02-08 2003-08-14 Timothy Roberts Customer billing in a communications network
CN1450749A (zh) * 2002-04-10 2003-10-22 华为技术有限公司 一种分组数据业务的计费方法
CN100409613C (zh) * 2002-08-08 2008-08-06 中兴通讯股份有限公司 基于无线局域网与码分多址系统相结合的鉴权计费方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002093835A1 (fr) * 2001-05-14 2002-11-21 Ntt Docomo, Inc. Appareil et procede de facturation de services de communication mobile
JP2003134111A (ja) * 2001-10-26 2003-05-09 Nec Corp ルールベースレイティングシステムおよび方法ならびにプログラム

Also Published As

Publication number Publication date
CN1787442A (zh) 2006-06-14
CN100341278C (zh) 2007-10-03

Similar Documents

Publication Publication Date Title
EP1732264B1 (fr) Procédé permettant de commander la facturation d'un service de commutation de paquets
WO2005109758A1 (fr) Methode de traitement pour une taxation en ligne parfaite basee sur le flux de donnees de service
US20070185809A1 (en) Method and system for processing online charging
US7889650B2 (en) Method for establishing diameter session for packet flow based charging
JP4402714B2 (ja) フローベース課金におけるイベント・トリガと再認証トリガを取り扱う方法
EP1804419B1 (fr) Procede de traitement de reautorisation a base de taxation du flux de donnees par paquets
JP4891223B2 (ja) パケットデータサービスの課金ルールを強化する方法及びその機能する方法
WO2007143940A1 (fr) procédé, système et équipement de contrôle des conditions d'utilisation et de la facturation lorsque l'utilisateur est mobile
WO2005109748A1 (fr) Procede de selection de la regle de taxation destine a des utilisateurs
WO2006050669A1 (fr) Procede de chargement en fonction d'un flux de paquets de donnees
WO2005101734A1 (fr) Procede de facturation de services de donnees par paquets et de controle d'acces de flux de donnees de services
WO2006060964A1 (fr) Systeme et procede de traitement permettant une facturation en fonction du flux de paquets de donnees
WO2006015543A1 (fr) Procede de traitement d'une re-autorisation, evenement de re-autorisation et declencheurs d'evenement
WO2006050670A1 (fr) Procede de traitement de cle de taxation
WO2012041148A1 (fr) Procédé et système de contrôle d'utilisation du volume de ressources
WO2006015550A1 (fr) Procede de distribution du numero de dialogue du chargement fonde sur le flux de paquets de donnees

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05818797

Country of ref document: EP

Kind code of ref document: A1