WO2006047965A1 - Procede de traitement de facturation en ligne - Google Patents

Procede de traitement de facturation en ligne Download PDF

Info

Publication number
WO2006047965A1
WO2006047965A1 PCT/CN2005/001874 CN2005001874W WO2006047965A1 WO 2006047965 A1 WO2006047965 A1 WO 2006047965A1 CN 2005001874 W CN2005001874 W CN 2005001874W WO 2006047965 A1 WO2006047965 A1 WO 2006047965A1
Authority
WO
WIPO (PCT)
Prior art keywords
ocs
tpf
credit
time
data traffic
Prior art date
Application number
PCT/CN2005/001874
Other languages
English (en)
French (fr)
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=36318899&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2006047965(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP05806963A priority Critical patent/EP1760932A4/en
Publication of WO2006047965A1 publication Critical patent/WO2006047965A1/zh
Priority to US11/651,868 priority patent/US20070185809A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • 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
    • 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
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1467—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network involving prepayment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/81—Dynamic pricing, e.g. change of tariff during call
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • H04M15/8207—Time based data metric aspects, e.g. VoIP or circuit switched packet data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • H04M15/8214—Data or packet based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/20—Technology dependant metering
    • H04M2215/2006—Fixed telephone network, e.g. POTS, ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/22—Bandwidth or usage-sensitve billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/78—Metric aspects
    • H04M2215/7806—Time based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/78—Metric aspects
    • H04M2215/7813—Time based data, e.g. VoIP or circuit switched packet data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/78—Metric aspects
    • H04M2215/782—Data or packet based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing

Definitions

  • the present invention relates to the field of packet data charging, and more particularly to a method for processing online charging. Background of the invention
  • 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
  • PDP Context the data interaction with the external packet data network (PDN, Packet Data Network)
  • 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 network layer service access point identifier.
  • NSAPI Network Layer Service Access Point Identifier
  • PDP type PDP type
  • APN Access Point Name
  • QoS Quality of service
  • TI Transaction Identifier
  • GGSN Gateway GPRS Support Node
  • TID Tunnel Identifier
  • the PDP type includes the end-to-end protocol (PPP, Peer- Peer Protocol type, Internet Protocol (IP) type, etc.;
  • APN can be provided by the MS to the SGSN, the SGSN is addressed to the corresponding GGSN according to the APN, and the GGSN determines the external network to be accessed by the MS according to the APN, and the MS may not be to the SGSN.
  • PPP Peer- Peer Protocol type
  • IP Internet Protocol
  • APN can be provided by the MS to the SGSN, the SGSN is addressed to the corresponding GGSN according to the APN, and the GGSN determines the external network to be accessed by the MS according to the APN, and the MS may not be to the SGSN.
  • Provide APN At this time, the SGSN selects a default APN according to the subscription information of the MS user; the QoS parameter is a quality requirement to be met by the packet data service specified by the MS; and the TI uses the MS to identify a
  • 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 (MSI) and an NSAPI.
  • the SGSN sends a PDP Context Request to the GGSN.
  • the PDP Context Request contains the PDP type, PDP address, APN, QoS parameters, TEID, and selection mode.
  • the PDP address can be MS.
  • the IP address is an optional parameter.
  • the PDP Context creation request may not carry the PDP address.
  • the GGSN may assign an IP address to the MS in the subsequent processing, or may assign an IP to the MS by the PDN that finally establishes a connection with the MS. Address;
  • the selection mode refers to the APN selection mode, that is, whether the APN is selected by the MS or selected by the SGSN. If the SGSN cannot resolve the address information of the GGSN according to the APN, the SGSN rejects the PDP Context activation request initiated by the MS.
  • Step 104 After receiving the PDP Context creation request, the GGSN determines an external PDN according to the APN, then allocates a Charging ID, initiates charging, and negotiates QoS. If the GGSN can meet the quality of service requirements of the QoS parameter, the SGSN sends the SGSN to the SGSN.
  • the PDP Context Create Response (Representation PDP Context Response), which carries the TEID, the PDP address, the Backbone Bearer protocol, the agreed QoS parameters, and the Charging ID.
  • 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.
  • PDP Context Deactivation Request Deactivate PDP Context Request
  • 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 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.
  • the SGSN After receiving the PDP Context deletion response, the SGSN ends the charging of the MS, deletes the PDP Context corresponding to the TEID, and then sends a PDP Context Deactivation Response (Deactivate PDP Context Response) to the MS.
  • the PDP Context deactivation response carries the TI. .
  • the MS After receiving the PDP Context deactivation response, 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 for billing, or root Charging is 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 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.
  • the charging mode of the operator for various services is likely to adopt different charging methods. For example, for the E-mail receiving and receiving service, the e-mail receiving and sending events may be triggered by the secondary charging, and the WAP browsing service may be based on the flow accounting fee.
  • the rate of the WAP browsing service and the rate of the file transfer service are different according to the flow rate. Therefore, according to the existing GPRS charging system, different services carried by the same PDP Context cannot be performed at all. Perform differentiated billing.
  • IP Flows IP data streams
  • Service Data Flow IP data stream
  • IP data stream-based charging can be considered as filtering out IP data streams of different services carried in the same PDP Context through filters of similar filters, and then separately charging IP data streams filtered by different filters. In order to achieve separate billing for different business data streams.
  • the granularity of the IP-based traffic is much smaller than the granularity of the charging based on a PDP Context.
  • the granularity can be regarded as the size of the meshing hole.
  • the charging granularity based on a PDP Context is a PDP Context, which is a sieve hole.
  • the IP granularity based on the IP data stream is an IP service data stream.
  • a mesh hole that is, a plurality of sieve holes for one PDP Context, therefore, IP stream-based charging is compared to IPP-based charging based on IP data stream-based charging for operators or services.
  • Providers offer a richer set of billing methods.
  • the structure of FBC system 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 CRP 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 is interworking with a Charging Collection Function (CCF) 208.
  • CCF Charging Collection Function
  • the TPF 205 carries an IP data stream. When the bearer of the IP data stream is established, the TPF 205 passes.
  • the Gx interface sends a charging rule request to the CRF 203, where the charging rule request carries information related to the user and the MS, a bearer characteristic, and network-related information, etc., wherein the information related to the user and the MS may be a mobile station.
  • the international number (MSISDN), the International Mobile Subscriber Identity (IMSI), etc., and the network related information may be a mobile network coding (MNC), a mobile country code (MCC), or the like.
  • 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 input information provided by the TPF 205, and sends the appropriate charging rule to the TPF 205.
  • the selected charging rule includes the charging mechanism, the charging type, the charging key, the service data stream filter, and the charging rule priority.
  • the charging mechanism may be online charging or offline charging; the charging type may be charging based on the length of time or based on data traffic; the charging button is a parameter related to the rate, and the CRF 203 may not be directly
  • the TPF 205 is provided with a rate, and only the rate-related parameters are provided to the TPF 205; the service data filter is used to indicate which IP data streams the TPF 205 filters, and then the TPF 205 filters the filtered IP data according to the charging rules.
  • the service data filter may include an IP5 tuple.
  • the IP5 tuple may include source/destination IP address, source/destination port number (Port Number), protocol identifier (Protocol ID), and the like.
  • CRF 203 indicates TPF 205 to source address. Filters the IP data stream of 10.0.0.1, the destination address is 10.0.0.2, the source/destination port number is 20, and the protocol type is Transmission Control Protocol (TCP), and the filtered IP data stream is filtered according to the charging rule.
  • the CRF 203 may provide a trigger event (Event Trigger) to the TPF 205 to request the TPF 205 to request a new charging rule from the CRF 205 when a specific event occurs, such as the CRF 203 requesting the TPF 205 to perform an event modification on some 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 TPF, and then determines the corresponding The charging rule is delivered to the TPF. Trigger events defined in the 3GPP specifications may include: PLMN change events, QoS changes events, Radio Access Technologies (RATs) Type change (RAT type change) event, Transport stream template (TFT) change (TFT change) event.
  • RATs Radio Access
  • 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 an online charging system, and is composed of two functional entities: SCP 201 and CCF (Service Data Flow Based Credit Control Function) 202.
  • the CCF (Service Data Flow Based Credit Control Function) 202 is a functional entity that performs credit control. Applying only to the online billing system can be achieved by adding new features to the existing OCS 206.
  • the CCF (Service Data Flow Based Credit Control Function) 202 manages and controls the user credit.
  • the CCF (Service Data Flow Based Credit Control Function) 202 is in the user credit pool.
  • the credit is authenticated, and the credit that the user can use is delivered to the TPF 205 through the Gy interface.
  • the OCS 206 may request the TPF 205 to report to the re-authorisation triggers when they occur, and then the OCS 206 re-authenticates the user according to the corresponding re-authentication event reported by the TPF 205, and may recalculate the user. Credit. For example, after the user credit provided by the OCS 206 to the TPF 205 is used, the TPF 205 needs to report the allowed user credit usage expiration event to the OCS 206 according to the allowed credit expiration event in the re-authentication event, and the OCS 206 according to the remaining user account. Information, recalculate the credits allowed to be used by the user.
  • 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 based on The PLMN change event in the re-authentication event reports the occurrence of the PLMN change event to the OCS 206, and the OCS 206 is updated according to the user. The previous location re-determines the rate 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-authentication event.
  • the 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-authentication event by the OCS to control the credit usage of the TPF. That is, the TPF reports the re-authentication event reported by the TCS to the OCS after the re-authentication event occurs.
  • the credit usage of the user and the change of the bearer are known, and the credit of the user is recalculated and sent to the TPF.
  • the re-authentication events defined in the 3GPP specifications may include: a credit authorization lifetime expiry event, a user idle state timeout event, a charging rule is changed event, a PLM 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.
  • the current 3GPP specifications propose that charging can be performed based on data traffic, charging based on time length, and charging based on data traffic and length of time.
  • the data flow-based charging mode is based on the amount of data transmitted; the time-based charging mode is based on the length of time used to transmit data; based on the combination of data traffic and time length
  • the fee mode is based on the amount of data transmitted over a period of time.
  • an object of the present invention is to provide a method for processing online charging, which clarifies the processing procedure of the combined charging mode based on the traffic and the length of time, and also enables the OCS to control the network resources used by the user.
  • the present invention provides a method for processing based on online charging, the method comprising the following steps:
  • OCS provides credit limit and monitoring conditions to TPF
  • the TPF monitors that the credit limit has been exhausted or the monitoring conditions have been met.
  • the TPF requests the OCS to re-authenticate the user.
  • the step A further includes: the OCS calculates a credit limit based on the data flow according to the user account, where the monitoring condition is a time limit.
  • the step B further includes: the TPF returning the remaining data traffic based credits to the OCS, or the remaining length of time, or a combination of the two, requesting the OCS to provide a new credit based on the data traffic.
  • the step A further includes: the OCS calculating a credit length based on the length of time according to the user account, where the monitoring condition is a data traffic limit.
  • the step B further includes: the TPF returning the remaining time length based credit amount to the OCS, or the remaining data traffic, or a combination of the two, requesting the OCS to provide a new credit length based on the length of time.
  • the step A further includes the step AO: the CRF provides a data flow limit and a time limit to the TPF, and the TPF provides the data flow limit and time limit to the OCS.
  • the step AO further includes: the CRF provides a charging mode indication to the TPF for combined charging based on the data traffic and the length of time, and the TPF provides the data flow and time based on the data flow to the OCS.
  • the length indicates the charging mode indication of the combined charging.
  • step A The credit line described in step A is part of all credit lines under the user account.
  • step B further includes a step C: the OCS provides a credit line and a monitoring condition to the TPF, and then returns to step B.
  • the step C further includes: the OCS calculating a new credit line based on the data traffic according to the remaining data traffic based credit limit, or the remaining time length, or a combination of the two; or, the OCS is based on the remaining time based The length of the credit line, or the remaining data traffic, or a combination of the two, calculates a new credit line based on the length of time.
  • the step B further includes: the OCS determining a reason for triggering the current credit request, if the reason is that the time limit timer expires, the OCS determines whether the data traffic used by the user is lower than a minimum value of the data flow set by the system, if Then, the OCS terminates the current conversation with the TPF; otherwise, the OCS provides the TPF with a time limit and a calculated new data flow-based credit line, and then returns to step B.
  • the OCS terminates the current conversation with the TPF as follows:
  • the OCS sends a termination operation indication to the TPF, and the TPF releases the session of the data flow corresponding to the conversation between the current OCS and the TPF.
  • the OCS in the case of online charging, provides a credit limit to the TPF, and also provides a monitoring condition to the TPF; when the TPF detects that the credit line has been consumed or the monitoring condition has been met, the TPF requests the OCS to perform the user on the TPF. Re-authentication and return the remaining credit limit or remaining monitoring condition information.
  • the OCS can know the monitoring condition information remaining when the credit quota issued to the TPF is used, or the remaining credit limit information when the monitoring condition is satisfied, thereby realizing the combination based on the data traffic and the length of time.
  • Billing also enables OCS to monitor the use of network resources by users for a certain length of time.
  • Figure 1 shows the PDP Context activation, data transmission, deactivation flowchart
  • Figure 2A shows the structure of the FBC system supporting online charging
  • Figure 2B shows a block diagram of an FBC system supporting offline charging
  • FIG. 3 is a schematic diagram showing a processing procedure of a combined charging mode based on data traffic and time length in the present invention
  • Fig. 4 is a diagram showing another processing procedure of the combined charging mode based on data traffic and time length in the present invention. Mode for carrying out the invention
  • the OCS provides a data credit-based credit limit to the TPF, and also provides a time limit to the TPF; the TPF monitors the data traffic according to the credit limit, and starts the time limit timer according to the time limit.
  • the TPF requests the OCS to re-authenticate the user and return the remaining credit limit.
  • the OCS can know the length of time that the credit line issued to the TPF is used, or the credit line that is consumed when the P-time expires, so that data traffic and time can be realized.
  • the combined charging of the length also enables the OCS to monitor the use of network resources by users within a certain length of time.
  • the OCS can also provide a time-based credit limit to the TPF, and also provide a data traffic limit to the TPF; the TPF monitors the length of time according to the credit limit, when the credit line has been consumed. Upon completion or when the data traffic reaches the data traffic limit, the TPF requests the OCS to re-authenticate the user and return the remaining credit limit. Through the interaction between the TPF and the OCS, the OCS can know the credit line issued to the TPF. The remaining data traffic at the time of use, or the credit line remaining when the data traffic reaches the limit, enables combined charging based on data traffic and time length.
  • FIG. 3 is a schematic diagram showing a process of calculating a credit limit by using a traffic-based method in a combined charging mode based on data traffic and a length of time in the present invention, as shown in FIG. 3, when the credit limit is calculated by using a traffic mode
  • the processing of the combined charging mode of data traffic and time length includes the following steps:
  • Step 301 When the CRF provides a Provision Charging Rule to the TPF, the TPF indicates that the current charging mechanism is online charging, and provides the TPF with a charging mode indication based on data traffic and time length combined charging;
  • the CRP can provide the TPF with time limits and data traffic limits to be monitored.
  • the data traffic limit can be either the minimum traffic limit or the highest traffic limit.
  • the CRF provides a time limit of 1 hour to the TPF, and the minimum data flow is 1 Mbyte. , that is, the user needs to use at least 1 Mbyte of data traffic per hour in the charging mode. If the data traffic used is less than 1 Mbyte, the data is charged according to 1 Mbyte of data traffic, if the data traffic exceeds 1 Mbyte, the billing is performed according to the actual data traffic.
  • the CRF can also provide the TPF with a charging button for indicating rate information, such as 2 yuan / M bytes.
  • Step 302 After receiving the charging rule provided by the CRF, the TPF sends a credit request (Credit Request) to the OCS according to the charging mechanism of the online charging, and requests the OCS to provide the user's credit limit, where the credit request carries the OCS to determine the user.
  • the input information of the credit line such as the charging mode based on the data traffic and the length of time combined charging, the time limit, the data flow limit, and the charging key.
  • the charging mode, the time limit and the data flow limit in step 301 and step 302 can be combined in the charging key, provided by a parameter of the charging key, or a new one or more parameters can be defined.
  • Step 303 After receiving the credit request, the OCS indicates according to the user's account and the charging button. Rate information, calculating a credit-based credit amount that the user can use, if the user's account can use 100 Mbytes of data traffic, returning a credit response (Credit Response) to the TPF, the credit response carrying data based The credit limit of the traffic and the time P ⁇ .
  • Rate information calculating a credit-based credit amount that the user can use, if the user's account can use 100 Mbytes of data traffic, returning a credit response (Credit Response) to the TPF, the credit response carrying data based
  • the credit limit of the traffic and the time P ⁇ the OCS can provide only a part of the credit limit to the TPF at a time, such as providing a 10 Mbyte credit line each time.
  • Step 304 to Step 306 After receiving the credit response, the TPF monitors the data traffic according to the credit amount provided by the OCS based on the data traffic, and starts the time limit timer. The TPF detects that the data traffic reaches the credit limit, or the time limit timer expires. The TPF sends a credit request to the OCS, which carries the remaining credit based on the data traffic, or the remaining time limit, requests the OCS to provide new The credit line; the credit request may further carry the reason for the current credit request initiation, so that the OCS can more clearly know whether the reason for triggering the current credit request is whether the data traffic reaches the credit limit or the time limit timer expires.
  • Step 307 After receiving the credit request, the OCS determines the reason for triggering the current credit request. If the reason for triggering the current credit request is that the data traffic reaches the credit limit, the OCS calculates according to the account information of the user and the rate information indicated by the charging button. a new credit line based on the data traffic, and then returning a credit response to the TPF, the credit response carrying a new credit line and time P ⁇ based on the data traffic; if the reason for triggering the current credit request is the time limit timer period If the user is full, the OCS deducts the user according to the charging mode based on the data traffic and the length of time combined charging and the rate information indicated by the charging button.
  • the user uses less than 1 Mbyte of data traffic in 1 hour according to 1 Mbyte.
  • the rate is 2 yuan M bytes, then the user consumes 2 yuan in the 1 hour, and then the OCS calculates the data flow based on the user's remaining account and the rate information indicated by the charging button. a new credit line, and then return a credit response to the TPF, which carries a new credit line based on data traffic in a timely manner Between limits.
  • the subsequent process is to repeat steps 304 to 307 until the user ends the use of the corresponding service or the credit limit in the user account is completely used.
  • the above processing method based on the combined charging mode of the data traffic and the length of time can be utilized to enable the OCS to better control the network resources used by the user.
  • OCS can proactively provide time limits to TPF.
  • TPF monitors data traffic based on credit limits and starts time limit timers based on time limits.
  • the OCS determines that the reason for triggering the credit request is that the time limit timer expires
  • the OCS can further determine the data traffic used by the user in the time limit, if the user uses within the time P ⁇ When the data traffic is small, if the data traffic used by the user within the time limit is lower than the minimum data traffic set by the system, it can be inferred that the user rarely uses the service at present, or the user no longer uses the service, that is, When an abnormal situation occurs, when the user stops using a certain service, the resources on the user side are released, but the resources on the network side are not released yet, and are still occupied.
  • OCS may Proactively initiate the process of terminating the conversation between the current OCS and the TPF, that is, the OCS sends a termination operation indication to the TPF, requesting the TPF to release the dialogue between the corresponding OCS and the TPF.
  • the TPF releases the session of the data stream of the current service corresponding to the conversation between the OCS and the TPF.
  • the present invention also provides a schematic diagram of a process for calculating a credit limit by using a time length based method in a combined charging mode based on data traffic and time length.
  • the processing of the combined charging mode based on data traffic and time length includes the following steps:
  • Step 401 When the CRF provides the charging rule to the TPF, the TPF indicates that the current charging mechanism is online charging, and provides the TPF with a charging mode based on data traffic and time length combined charging. Further, the CRF can provide the TPF with the data traffic limit and time limit to be monitored.
  • the time limit can be the minimum time limit or the maximum time limit. For example, the CRF provides the TPF with monitoring data traffic of 10 Mbytes, the minimum.
  • the time limit is 1 hour, which means that the user can use up to 10 f Mbytes of data traffic per hour in this charging mode. If more than 10 Mbytes of data traffic is used but consumes less than 1 hour, the billing is performed for 1 hour.
  • the CRF may also provide the TPF with a charging button for indicating rate information, such as 2 yuan/hour.
  • Step 402 After receiving the charging rule provided by the CRF, the TPF sends a credit request to the OCS according to the online charging charging mechanism, requesting the OCS to provide the user's credit limit, where the credit request carries an input for the OCS to determine the user credit limit.
  • Information such as billing mode, time limit, data traffic, and billing keys, based on data traffic and time length combined billing.
  • the charging mode, time limit and data traffic in step 401 and step 402 can be combined in the charging key, provided by a parameter of the charging key, or a new one or more parameters can be defined.
  • Step 403 After receiving the credit request, the OCS calculates a credit length based on the time length that the user can use according to the user's account and the rate information indicated by the charging button. If the user's account can use the 10-hour service, the The TPF returns a credit response that carries a credit line based on the length of time and a data traffic limit.
  • OCS can provide only a part of the credit line to TPF at a time, such as providing one hour of credit per time.
  • Step 404 to step 406 After the TPF receives the credit response, the time provided by the OCS is based on The length of the credit line starts the corresponding time length timer and monitors the data traffic used by the user. The TPF monitors that the time length timer expires, or the monitored data traffic reaches the data traffic limit, and the TPF sends a credit request to the OCS, which carries the remaining time-based credit line or the remaining data traffic. Requesting the OCS to provide a new credit line; the credit request may further carry the reason for the initiation of the current credit request, so that the OCS can more clearly know whether the reason for triggering the current credit request is that the length of time reaches the credit limit, or whether the monitored data traffic reaches Data traffic limit.
  • Step 407 After receiving the credit request, the OCS determines the reason for triggering the current credit request. If the reason for triggering the current credit request is that the time length reaches the credit limit, the OCS calculates according to the account information of the user and the rate information indicated by the charging button. a new credit line based on the length of time, and then returning a credit response to the TPF, the credit response carrying a new credit line based on the length of time and the monitored data traffic limit; if the reason for triggering the current credit request is the monitored data traffic When the data traffic limit is reached, the OCS deducts the user according to the charging mode based on the data traffic and the length of time combined charging and the rate information indicated by the charging button.
  • the user spends 10 Mbytes of data traffic for a short period of time.
  • the billing is performed in 1 hour, and the rate is 2 yuan/hour.
  • the user consumes 2 yuan in the period of less than one hour.
  • the OCS calculates a new credit line based on the length of time based on the user's remaining account and the rate information indicated by the charging button, and then returns a credit response to the TPF, the credit response carrying a new credit line based on the length of time and Data traffic limit.
  • the subsequent process is to repeat steps 404 to 407 until the user ends the use of the corresponding service or the credit limit in the user account is completely used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Meter Arrangements (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

一种在线计费的处理方法
技术领域
本发明涉及分组数据计费领域，特别是指一种在线计费的处理方法。 发明背景
随着分组数据业务应用的逐渐广泛， 如何准确合理地对分组数据业 务进行计费， 已成为运营商普遍关注的问题。
图 1示出了分组数据协议上下文 ( PDP Context, Packet Data Protocol Context )激活、 数据传输、 去激活流程图， 如图 1所示， 在通用分组无 线业务（GPRS, General Packet Radio Service ) 中， 激活 PDP Context、 与外部分组数据网络（PDN, Packet Data Network )进行数据交互、 去 激活该 PDP Context的实现过程包括以下步骤：
步骤 101 : 移动终端 （MS ) 向服务通用分组无线业务支持节点 ( SGSN, Serving GPRS Support Node )发送 PDP Context激活请求 ( Activate PDP Context Request ), 该 Activate PDP Context Request中携 带有网络层业务访问点标识（ NSAPI, Network Layer Service Access Point Identifier ), PDP类型、 接入点名称（APN， Access Point Name ) . 要求 的服务质量（ QoS )参数、事务标识（ TI, Transaction Identifier )等信息， 其中， NSAPI在 SGSN和网关通用分组无线业务支持节点 （GGSN， Gateway GPRS Support Node )之间作为隧道标识（ TID, Tunnel Identifier ) 的组成部分， 用于标识 PDP Context; PDP类型包括端对端协议 ( PPP, Peer-Peer Protocol )类型、 网际协议（ IP, Internet Protocol )类型等； APN 可由 MS向 SGSN提供， SGSN根据 APN寻址到相应 GGSN， GGSN才艮 据 APN确定 MS所要访问的外部网络， MS也可不向 SGSN提供 APN, 此时， 由 SGSN根据 MS用户的签约信息选择缺省的 APN; QoS参数为 MS指定的分组数据业务所要达到的质量要求； TI用于 MS标识某个 PDP context。
步骤 102: SGSN收到 Activate PDP Context Request后， 与 MS进行 安全性检查和加密， 该步骤为可选步骤。
步骤 103: SGSN根据 APN解析 GGSN的地址信息， 如果 SGSN能 够根据 APN解析出 GGSN的地址信息， 则为 PDP Context创建 TEID , 该 TEID可为国际移动用户标识（ MSI, International Mobile Subscriber Identity )与 NSAPI的组合， 然后 SGSN向 GGSN发送 PDP Context创 建请求（ Create PDP Context Request )， 该 PDP Context创建请求中携带 有 PDP类型、 PDP地址、 APN、 QoS参数、 TEID, 选择模式等， 其中， PDP地址可为 MS的 IP地址， 为可选参数， PDP Context创建请求中可 不携带 PDP地址， 此时， 在后续的处理过程中， 可由 GGSN为 MS分 配 IP地址， 也可由最终与 MS建立连接的 PDN为 MS分配 IP地址； 选 择模式是指 APN的选择模式， 即 APN是由 MS选定的还是由 SGSN选 定的。 如果 SGSN无法根据 APN解析出 GGSN的地址信息， 则 SGSN 拒绝 MS发起的 PDP Context激活请求。
步骤 104: GGSN收到 PDP Context创建请求后， 根据 APN确定外 部 PDN, 然后分配计费标识（Charging ID )、 启动计费， 并且协商 QoS， 如果 GGSN能够满足 QoS参数的服务质量要求， 则向 SGSN返回 PDP Context创建响应 （ Create PDP Context Response ), 该 PDP Context创建 响应中携带有 TEID、 PDP地址、 链路承载（Backbone Bearer )协议、 商定的 QoS参数、 Charging ID等信息。 如果 GGSN无法满足 QoS参数 的服务质量要求， 则 GGSN拒绝 SGSN发起的 PDP Context创建请求， 然后 SGSN拒绝 MS发起的 PDP Context激活请求。 步骤 105: SGSN收到 PDP Context创建响应后， 在 PDP Context中 插入用于标识 PDP Context的 NSAPI和 GGSN地址信息，并根据商定的 QoS 参数选择无线优先权， 然后向 MS 返回 PDP Context激活响应 ( Activate PDP Context Accept ),该 PDP Context激活响应中携带有 PDP 类型、 PDP地址、 TI、 商定的 QoS参数、 无线优先权、 PDP配置选项等 信息。 并且， SGSN启动计费。 MS收到 PDP Context激活响应， 就已经 建立了 MS与 GGSN直接的路由， 可以进行分组数据的传输了。
步骤 106: MS通过 SGSN、 GGSN与 PDN进行分组数据的交互。 步骤 107: 结束分组数据交互后 MS向 SGSN发送 PDP Context去 激活请求 ( Deactivate PDP Context Request )，该 PDP Context去激活请求 中携带有 Ή。
步骤 108: SGSN收到 PDP Context去激活请求后， 与 MS进行安全 性检查和加密， 该步骤为可选步骤。
步骤 109〜步驟 111 : SGSN向 GGSN发送 PDP Context删除请求 ( Delete PDP Context Request ),该 PDP Context删除请求中携带有 TEID。
GGSN收到 PDP Context删除请求后， 结束对 MS的计费， 删除对应于 TEID的 PDP Context, 然后向 SGSN发送 PDP Context删除响应（ Delete PDP Context Response ),该 PDP Context删除响应中携带有 TEID。 SGSN 收到 PDP Context删除响应后，结束对 MS的计费，删除对应于 TEID的 PDP Context, 然后向 MS发送 PDP Context去激活响应 ( Deactivate PDP Context Response ), 该 PDP Context去激活响应中携带有 TI。 MS收到 PDP Context去激活响应后， 删除对应于 TI的 PDP Context
由图 1描述的实现过程可见， 当前的 GPRS计费系统中， 由于计费 的起始点设置在 PDP Context激活时，计费的终止点设置在 PDP Context 删除时， 因此只能根据 PDP Context传输的数据流量进行计费， 或是根 据 PDP Context处于激活状态的时间长度进行计费。 然而， 在实际应用 中， MS与 PDN进行数据交互后，该 MS可以基于一个激活的 PDP Context 进行多种业务， 也就是说， 如果 PDN 能够提供多种业务， 如电子邮件 ( Email ) 收发业务、 基于无线应用协议的 （ WAP, Wireless Application Protocol )的浏览业务、基于文件传输协议（FTP, File Transfer Protocol ) 的文件传输等业务，则 MS在与该 PDN建立传输通道后，可通过一个激 活的 PDP Context承载该 PDN能够提供的各种业务。 但是， 运营商对于 各种业务的计费模式很可能采用不同的计费方式， 如对于 Email收发业 务可基于 Email接收和发送事件的触发按次计费， 对于 WAP浏览业务 可根据流量计费，对于文件传输业务也可根据流量计费， WAP浏览业务 的费率与文件传输业务的费率却不尽相同， 这样， 根据现有的 GPRS计 费系统， 根本无法对同一 PDP Context承载的不同业务进行区分计费。
针对上述情况， 第三代合作伙伴计划 （3GPP, The 3rd Generation Partnership Project )目前正在讨论如何实现基于 IP数据流的计费（ FBC, Flow Based Charging )。 对于一个分组数据业务而言， MS的用户使用该 业务时，传输和接收到的所有 IP数据流（IP Flow ),也可为 IP分组包（IP packet ), 总称为业务数据流（ Service Data Flow ), 即业务数据流是多个 IP数据流组成的集合， 因此基于 IP数据流的计费能够真实反映某个业 务数据流对资源的占用情况。基于 IP数据流的计费可被认为是通过一些 类似筛子的过滤器将同一 PDP Context中承载的不同业务的 IP数据流分 别筛选出来， 然后针对不同过滤器过滤出的 IP数据流进行分别计费， 以 达到对不同的业务数据流分别计费的目的。这样，基于 IP数据流的计费 粒度要远远小于基于一个 PDP Context的计费粒度， 粒度可看作是筛子 孔的大小，基于一个 PDP Context的计费粒度是一个 PDP Context就是一 个筛子孔， 而基于 IP数据流的计费粒度则是一个 IP业务数据流则为一 个筛子孔， 即针对一个 PDP Context中包含多个筛子孔， 因此， 基于 IP 数据流的计费与比基于一个 PDP Context的计费相比， 基于 IP数据流的 计费能够为运营商或业务提供者提供更为丰富的计费手段。
3GPP中对 FBC的系统结构、 功能要求以及消息交互流程等方面均 进行了描述， 支持在线计费的 FBC系统结构如图 2A所示， 基于移动网 络增强逻辑的客户化应用 （ CAMEL , Customised Application for Mobile Network Enhanced Logic ) 的业务控制点 （ SCP， Service Control Point ) 201和基于业务数据流计费的信用控制功能实体（ CCF, Service Data Flow Based Credit Control Function ) 202组成了在线计费系统（ OCS， Online Charging System ) 206。 CCF 202通过 Ry接口与基于业务数据流计费的 计费规则功能实体 ( CRF , Service Data Flow Based Charging Rule Function ) 203 互通， CRP 203 通过 Rx接口与应用功能实体（AF, Application Function ) 204互通， CRF 203通过 Gx接口与传输面功能实 体（ TPF， Traffic Plane Function ) 205互通， CCF 202通过 Gy接口与 TPF 205互通。
支持离线计费的 FBC系统结构如图 2B所示， CRF 203通过 Rx接 口与 AF 204互通， CRF 203通过 Gx接口与 TPF 205互通， TPF 205通 过 Gz接口分别与计费网关功能实体（ CGF , Charging Gateway Function ) 207和计费釆集功能实体（ CCF, Charging Collection Function )208互通。
TPF 205承载 IP数据流， 当 IP数据流的承载建立时， TPF 205通过
Gx接口向 CRF 203发送计费规则请求， 该计费规则请求中携带有与.用 户和 MS相关的信息、 承载特性以及与网络相关的信息等， 其中与用户 和 MS相关的信息可为移动台国际号码（MSISDN )、 国际移动用户标识 ( IMSI )等， 与网络相关的信息可为移动网络编码（MNC )、 移动国家 码（MCC )等。 另外， 由于在 EP数据流传输过程中， 会对承载进行修 改， 如对 QoS参数进行重新协商， 当用户使用同一业务的 QoS参数不 同时， 计费规则可能不同， 如 QoS参数下降相应的费率也下降。 此时， TPF 205可在承载修改时， 重新向 CRF 203发送计费规则请求， 请求新 的计费规则； CRF 203根据 TPF 205提供的上迷输入信息选择适当的计 费规则，并向 TPF 205返回选定的计费规则，计费规则中包括计费机制、 计费类型、 计费键（Charging Key )、 业务数据流过滤器、 计费规则优先 级等信息。 其中， 计费机制可为采用在线计费还是离线计费； 计费类型 可为基于时间长度进行计费还是基于数据流量进行计费； 计费键是与费 率相关的参数， CRF 203可不直接向 TPF 205提供费率， 而只是向 TPF 205提供与费率相关的参数； 业务数据过滤器用于指示 TPF 205对哪些 IP数据流进行过滤， 然后 TPF 205根据计费规则对过滤出的 IP数据流 进行计费。 业务数据过滤器可包含 IP5元组， IP5元组可包括源 /目的 IP 地址、 源 /目的端口号（Port Number )、 协议标识（ Protocol ID )等信息， 例如， CRF 203指示 TPF 205对源地址为 10.0.0.1、 目的地址为 10.0.0.2、 源 /目的端口号为 20、 '协议类型为传输控制协议（TCP ) 的 IP数据流进 行过滤， 并根据计费规则对过滤出的 IP数据流进行计费。
CRF 203可向 TPF 205提供触发事件（ Event Trigger ),用以要求 TPF 205在特定事件发生时， 向 CRF 205请求新的计费规则， 如 CRF 203要 求 TPF 205在某些承载进行修改的事件发生时， 向 CRF 203请求新的计 费规则。 触发事件可视为与计费规则相关的事件。 目前， 3GPP规范中 对 CRF通过触发事件上报机制控制 TPF的计费方式进行了描述，即 TPF 监测到触发事件发生后向 CRP上报， CRF通过 TPF上报的触发事件获 知承载发生变化， 然后确定相应的计费规则并下发给 TPF。 3GPP规范 中定义的触发事件可包括：公用陆地移动通信网络（ PLMN )变化（ PLMN change )事件， QoS参数变化（ QoS changes )事件，无线接入技术（ RAT ) 类型变化（ RAT type change )事件，传输流模板（ TFT )变化（ TFT change ) 事件。
CRF 203除了根据 TPF 205提供的输入信息选择适当的计费规则之 外， CRF 203还可根据 AF 204或 OCS 206的输入信息选择适当的计费 规则， 如 AF 204通知 CRF 203用户当前使用的业务类型， CRF 203根 据该业务类型选择相应的计费规则。
OCS 206作为在线计费系统， 由 SCP 201和 CCF ( Service Data Flow Based Credit Control Function )202两个功能实体组成，其中， CCF( Service Data Flow Based Credit Control Function ) 202是执行信用控制的功能实 体， 仅应用于在线计费系统， 可通过在现有的 OCS 206中增加新的功能 来实现。在在线计费过程中， CCF( Service Data Flow Based Credit Control Function ) 202对用户信用进行管理和控制， 当用户使用业务时， CCF ( Service Data Flow Based Credit Control Function ) 202对该用户信用池 中的信用进行鉴权， 并通过 Gy接口向 TPF 205下发用户能够使用的信 用。
另外， OCS 206 可要求 TPF 205 在重鉴权事件（Re-authorisation triggers )发生时向其上报， 然后 OCS 206根据 TPF 205上报的相应重鉴 权事件对用户进行重鉴权，并可能重新计算用户的信用。例如， OCS 206 向 TPF 205提供的用户信用使用完毕， TPF 205需根据重鉴权事件中的 允许信用过期事件，向 OCS 206上报其允许的用户信用使用过期事件的 发生， OCS 206根据用户剩余帐户信息， 重新对允许用户使用的信用进 行计算。 又例如， 分区域计费时， OCS 206才艮据用户当前所在位置确定 费率， 并根据该费率计算用户的信用； 当用户移动至另一位置时， 如 PLMN发生变化， TPF 205需要根据重鉴权事件中的 PLMN变化事件， 向 OCS 206上报 PLMN变化事件的发生， OCS 206根据用户更新后的当 前所在位置重新确定费率，并重新计算用户的信用。又例如， 当 OCS 206 根据用户使用业务的当前 QoS参数确定费率， 当用户对 QoS参数进行 修改， TPF 205需要根据重鉴权事件中的承载修改事件， 向 OCS 206上 报承载修改事件的发生， OCS 206根据用户修改后的 QoS参数确定费率， 并重新计算用户的信用。
另外， 3GPP规范中还对 OCS通过重鉴权事件上报的机制控制 TPF 的信用使用情况进行了描述， 即 TPF监测到重鉴权事件发生后向 OCS 上报， OCS通过 TPF上报的重鉴权事件，获知用户的信用使用情况以及 承载的变化， 对用户的信用重新进行计算并下发给 TPF。 3GPP规范中 定义的重鉴权事件可包括： 允许信用过期 （credit authorization lifetime expiry ) 事件， 用户空闲状态超时 （idle timeout ) 事件， 计费规则变化 ( charging rule is changed )事件， PLM 变化事件， QoS参数变化事件， RAT类型变化事件。
对应于 GPRS网络， TPF 205为 GGSN, AF为 PDN中的一个业务 网关或业务服务器， CRF 203为新增的逻辑实体。 TPF 205为计费规则 的执行点， CRF 203为计费规则的控制点。
对于基于分组数据流的计费， 目前 3GPP规范中提出可以基于数据 流量进行计费， 也可以基于时间长度进行计费， 还可以基于数据流量和 时间长度进行计费。 基于数据流量的计费模式是以传输的数据量的大小 作为计费依据； 基于时间长度的计费模式是以传输数据所使用的时间长 度作为计费依据； 基于数据流量和时间长度的组合计费模式是以一段时 间长度内传输的数据量的大小作为计费依据。
目前， 3GPP规范中提出在线计费情况下， 可以基于数据流量和时 间长度来进行组合计费， 但是并未描述具体的实现过程， 使得基于流量 和时间长度的组合计费模式的处理不明确， 影响了基于流量和时间长度 的组合计费模式的可用性和明确性。 发明内容
有鉴于此， 本发明的目的在于提供一种在线计费的处理方法， 明确 基于流量和时间长度的组合计费模式的处理过程，也可使 OCS对用户使 用的网络资源进行控制。
为了达到上述目的， 本发明提供了一种基于在线计费的处理方法， 该方法包含以下步骤：
A、 OCS向 TPF提供信用额度和监控条件；
B、 TPF监测到信用额度已消耗完毕或监控条件已满足， TPF请求 OCS对用户进行重鉴权。
其中， 所述步驟 A之前进一步包括： OCS根据用户帐户计算基于数 据流量的信用额度， 所述监控条件为时间限度。
所述步骤 B进一步包括： TPF向 OCS返回剩余的基于数据流量的信 用额度， 或剩余的时间长度， 或以上二者的组合， 请求 OCS提供新的基 于数据流量的信用额度。
所述步骤 A之前进一步包括： OCS根据用户帐户计算基于时间长度 的信用额度， 所述监控条件为数据流量限度。
所述步骤 B进一步包括： TPF向 OCS返回剩余的基于时间长度的信 用额度， 或剩余的数据流量， 或以上二者的组合， 请求 OCS提供新的基 于时间长度的信用额度。
所述步骤 A之前进一步包括步骤 AO: CRF向 TPF提供数据流量限 度和时间限度， TPF向 OCS提供数据流量限度和时间限度。
所述步骤 AO进一步包括： CRF向 TPF提供基于数据流量和时间长 度进行组合计费的计费模式指示， TPF向 OCS提供基于数据流量和时间 长度进行组合计费的计费模式指示。
步骤 A中所述信用额度为用户帐户下所有信用额度的其中一部分。 所述步骤 B之后进一步包括步骤 C: OCS向 TPF提供信用额度和监 控条件， 然后返回执行步骤 B。
所述步骤 C之前进一步包括： OCS根据剩余的基于数据流量的信用 额度， 或剩余的时间长度， 或以上二者的组合， 计算基于数据流量的新 的信用额度； 或， OCS根据剩余的基于时间长度的信用额度， 或剩余的 数据流量， 或以上二者的组合， 计算基于时间长度的新的信用额度。
所述步骤 B之后进一步包括： OCS确定触发当前信用请求的原因， 如果所述原因为时间限度定时器期满，则 OCS判断用户使用的数据流量 是否低于系统设置的数据流量最小值，如果是，则 OCS终止当前与 TPF 之间的对话； 否则， OCS向 TPF提供时间限度和计算的新的基于数据流 量的信用额度， 然后返回执行步骤 B。
所述 OCS终止当前与 TPF之间的对话为： OCS向 TPF发送终止操 作指示， TPF释放与当前 OCS和 TPF之间对话相对应的业务的数据流 的会话。
根据本发明提出的方法，在线计费情况下， OCS向 TPF提供信用额 度的同时，还向 TPF提供监控条件； 当 TPF监测到信用额度已消耗完毕 或监控条件已满足， TPF请求 OCS对用户进行重鉴权，并返回剩余的信 用额度或是剩余的监控条件信息。 通过 TPF与 OCS的交互， 使得 OCS 能够获知向 TPF下发的信用额度使用完毕时剩余的监控条件信息，或是 监控条件满足时剩余的信用额度信息， 从而可实现基于数据流量和时间 长度的组合计费，也可使 OCS能够对一定时间长度内用户使用网络资源 的情况进行监控。 附图简要说明
图 1示出了 PDP Context激活、 数据传输、 去激活流程图； 图 2A示出了支持在线计费的 FBC系统结构图；
图 2B示出了支持离线计费的 FBC系统结构图；
图 3示出了本发明中基于数据流量和时间长度的组合计费模式的一 种处理过程示意图；
图 4示出了本发明中基于数据流量和时间长度的组合计费模式的另 一种处理过程示意图。 实施本发明的方式
为使本发明的目的、 技术方案和优点更加清楚， 下面结合附图对本 发明作进一步的详细描述。
本发明中， 在线计费情况下， OCS向 TPF提供基于数据流量的信用 额度的同时， 还向 TPF提供时间限度； TPF根据信用额度对数据流量进 行监控， 并根据时间限度启动时间限度定时器， 当信用额度已消耗完毕 或是时间限度定时器期满时， TPF请求 OCS对用户进行重鉴权，并返回 剩余的信用额度。 通过 TPF与 OCS的交互， 使得 OCS能够获知向 TPF 下发的信用额度使用完毕时耗费的时间长度， 或是一定的时间 P艮度期满 时耗费的信用额度 , 从而可实现基于数据流量和时间长度的组合计费， 也可使 OCS能够对一定时间长度内用户使用网络资源的情况进行监控。
另外， 本发明中， 在线计费情况下， OCS还可向 TPF提供基于时间 长度的信用额度的同时， 还向 TPF提供数据流量限度； TPF根据信用额 度对时间长度进行监控， 当信用额度已消耗完毕或是数据流量达到数据 流量限度时， TPF请求 OCS对用户进行重鉴权，并返回剩余的信用额度。 通过 TPF与 OCS的交互，使得 OCS能够获知向 TPF下发的信用额度使 用完毕时剩余的数据流量， 或是数据流量达到限度时剩余的信用额度， 从而可实现基于数据流量和时间长度的组合计费。
图 3示出了本发明中基于数据流量和时间长度的组合计费模式下， 信用额度采用基于流量的方式进行计算的处理过程示意图，如图 3所示， 信用额度采用流量的方式计算时基于数据流量和时间长度的组合计费 模式的处理过程包括以下步骤：
步骤 301 : CRF向 TPF提供计费规则（ Provision Charging Rules )时， 向 TPF指明当前计费机制为在线计费，并向 TPF提供基于数据流量和时 间长度组合计费的计费模式指示； 进一步地， CRP可向 TPF提供需监控 的时间限度及数据流量限度， 数据流量限度可为最低流量限度， 也可为 最高流量限度， 如 CRF向 TPF提供时间限度为 1小时, 最低数据流量 为 1M字节， 即表明该计费方式下用户在每小时内至少需要使用的数据 流量为 1M字节， 如果使用的数据流量不足 1M字节， 则按照 1M字节 的数据流量进行计费， 如果数据流量超过 1M字节， 则按照实际的数据 流量进行计费。另外， CRF还可向 TPF提供用于指示费率信息的计费键， 如 2元 /M字节。
步骤 302: TPF收到 CRF提供的计费规则后， 根据在线计费的计费 机制向 OCS发送信用请求（ Credit Request ),请求 OCS提供用户的信用 额度，该信用请求中携带有供 OCS确定用户信用额度的输入信息，如基 于数据流量和时间长度組合计费的计费模式、 时间限度、 数据流量限度 以及计费键等信息。
这里， 步骤 301和步骤 302中的计费模式、 时间限度和数据流量限 度可合并在计费键中， 通过计费键一个参数提供， 也可定义新的一个或 多个参数来提供。
步骤 303: OCS收到信用请求后， 根据用户的帐户和计费键指示的 费率信息， 计算用户能够使用的基于数据流量的信用'额度， 如果该用户 的帐户能够使用 100M字节的数据流量，则向 TPF返回信用响应（ Credit Response ), 该信用响应中携带有基于数据流量的信用额度及时间 P艮度。 此处， 为避免一次为一个业务分配过多的信用额度， 而导致用户使用其 他业务时的信用受限， OCS可一次仅向 TPF提供一部分信用额度，如每 次提供 10M字节的信用额度。
步骤 304〜步骤 306: TPF收到信用响应后，根据 OCS提供的基于数 据流量的信用额度对数据流量进行监控， 并启动时间限度定时器。 TPF 监测到数据流量达到信用额度， 或时间限度定时器期满， TPF 向 OCS 发送信用请求， 该信用请求中携带有剩余的基于数据流量的信用额度， 或是剩余的时间限度，请求 OCS提供新的信用额度；该信用请求中可进 一步携带有当前信用请求发起的原因，以使 OCS能够更明确地获知触发 当前信用请求的原因是数据流量达到信用额度， 还是时间限度定时器期 满。
步骤 307: OCS收到信用请求后， 确定触发当前信用请求的原因， 如果触发当前信用请求的原因是数据流量达到信用额度，则 OCS根据用 户的帐户信息和计费键指示的费率信息， 计算出基于数据流量的新的信 用额度， 然后向 TPF返回信用响应， 该信用响应中携带有基于数据流量 的新的信用额度及时间 P艮度； 如果触发当前信用请求的原因是时间限度 定时器期满，则 OCS根据基于数据流量和时间长度组合计费的计费模式 以及计费键指示的费率信息对用户进行扣费， 如用户 1小时内使用不足 1M字节的数据流量按照 1M字节来进行计费， 费率为 2元 M字节， 则 该用户在该 1小时内消费了 2元，然后 OCS根据用户的剩余帐户和计费 键指示的费率信息， 计算出基于数据流量的新的信用额度， 然后向 TPF 返回信用响应， 该信用响应中携带有基于数据流量的新的信用额度及时 间限度。
后续过程即为重复执行步骤 304〜步骤 307， 直至用户结束相应业务 的使用或用户帐户中的信用额度全部使用完毕。
另外， 在不是基于数据流量和时间长度进行计费的情况下， 也可利 用以上基于数据流量和时间长度的组合计费模式的处理方式， 使 OCS 对用户使用的网络资源进行更好地控制。
OCS在向 TPF提供基于数据流量的信用额度的同时，可主动向 TPF 提供时间限度， TPF根据信用额度对数据流量进行监控， 并根据时间限 度启动时间限度定时器。 当 TPF向 OCS发送新的信用请求， 并且 OCS 确定触发该信用请求的原因是时间限度定时器期满， OCS可进一步确定 用户在时间限度中使用的数据流量， 如果用户在时间 P艮度内使用的数据 流量很少时， 如用户在时间限度内使用的数据流量低于系统设置的数据 流量最小值， 则可推断该用户目前极少使用该业务， 或是用户已经不再 使用该业务， 即可能是异常情况时， 用户停止使用某个业务时， 用户侧 的资源已经释放， 但网络侧的资源尚未释放， 仍处于占用状态， 这样， 为了避免网络资源的无谓占用或被吊死, OCS可主动发起终止当前 OCS 和 TPF之间的对话的流程，即 OCS向 TPF发送终止操作指示，要求 TPF 释放相应 OCS和 TPF之间对话。 TPF释放当前 OCS和 TPF之间对话对 应的业务的数据流的会话。
另外， 本发明中还提供了基于数据流量和时间长度的组合计费模式 下， 信用额度采用基于时间长度的方式进行计算的处理过程示意图， 如 图 4所示， 信用额度采用时长的方式计算时基于数据流量和时间长度的 组合计费模式的处理过程包括以下步骤：
步骤 401： CRF向 TPF提供计费规则时， 向 TPF指明当前计费机制 为在线计费，并向 TPF提供基于数据流量和时间长度组合计费的计费模 式指示； 进一步地， CRF可向 TPF提供需监控的数据流量限度及时间限 度， 时间限度可为最小时间限度， 也可为最大时间限度， 如 CRF向 TPF 提供监控数据流量为 10M字节，最小时间限度为 1小时， 即表明该计费 方式下用户在每小时内最多使用 10fM字节的数据流量。如果使用了超过 10M字节数据流量却消耗了不足 1小时的时间长度， 则按照 1小时进行 计费， 如果使用的 10M字节的数据流量消耗了超过 1小时的时间长度， 则按照实际的时间长度进行计费， 这样， 可以避免运营商采用基于时间 长度作为信用额度的计算单位时， 用户在短时间内使用大量的网络资源 而导致的运营商的计费损耗。 另外， CRF还可向 TPF提供用于指示费率 信息的计费键, 如 2元 /小时。
步骤 402: TPF收到 CRF提供的计费规则后， 根据在线计费的计费 机制向 OCS发送信用请求， 请求 OCS提供用户的信用额度， 该信用请 求中携带有供 OCS确定用户信用额度的输入信息，如基于数据流量和时 间长度组合计费的计费模式、 时间限度、 数据流量以及计费键等信息。
这里， 步骤 401和步骤 402中的计费模式、 时间限度和数据流量可 合并在计费键中， 通过计费键一个参数提供， 也可定义新的一个或多个 参数来提供。
步骤 403: OCS收到信用请求后， 根据用户的帐户和计费键指示的 费率信息， 计算用户能够使用的基于时间长度的信用额度， 如果该用户 的帐户能够使用 10小时的业务， 则向 TPF返回信用响应， 该信用响应 中携带有基于时间长度的信用额度及数据流量限度。 此处， 为避免一次 为一个业务分配过多的信用额度， 而导致用户使用其他业务时的信用受 限， OCS可一次仅向 TPF提供一部分信用额度，如每次提供 1小时的信 用额度。
步骤 404〜步骤 406: TPF收到信用响应后，根据 OCS提供的基于时 间长度的信用额度启动相应的时间长度定时器， 并监控用户使用的数据 流量。 TPF监测到时间长度定时器期满， 或是监控的数据流量达到数据 流量限度， TPF向 OCS发送信用请求，该信用请求中携带有剩余的基于 时间长度的信用额度，或是剩余的数据流量，请求 OCS提供新的信用额 度; 该信用请求中可进一步携带有当前信用请求发起的原因， 以使 OCS 能够更明确地获知触发当前信用请求的原因是时间长度达到信用额度， 还是监控的数据流量达到数据流量限度。
步骤 407: OCS收到信用请求后， 确定触发当前信用请求的原因， 如果触发当前信用请求的原因是时间长度达到信用额度，则 OCS根据用 户的帐户信息和计费键指示的费率信息， 计算出基于时间长度的新的信 用额度， 然后向 TPF返回信用响应， 该信用响应中携带有基于时间长度 的新的信用额度及监控的数据流量限度； 如果触发当前信用请求的原因 是监控的数据流量达到数据流量限度，则 OCS根据基于数据流量和时间 长度组合计费的计费模式以及计费键指示的费率信息对用户进行扣费， 如用户使用 10M字节的数据流量耗费的时间长度不足 1小时， 则按照 1 小时来进行计费， 费率为 2元 /小时， 则该用户在该段不足 1小时的时间 长度内消费了 2元，
然后 OCS根据用户的剩余帐户和计费键指示的费率信息，计算出基 于时间长度的新的信用额度， 然后向 TPF返回信用响应， 该信用响应中 携带有基于时间长度的新的信用额度及数据流量限度。
后续过程即为重复执行步骤 404〜步驟 407， 直至用户结束相应业务 的使用或用户帐户中的信用额度全部使用完毕。
总之， 以上所述仅为本发明的较佳实施例而已， 并非用于限定本发 明的保护范围。 .

Claims

权利要求书
1、 一种在线计费的处理方法， 其特征在于， 该方法包含以下步骤：
A、 OCS向 TPF提供信用额度和监控条件；
B、 TPF监测到信用额度已消耗完毕或监控条件已满足， TPF请求 OCS对用户进行重鉴权。
2、 根据权利要求 1所述的方法， 其特征在于， 所述步骤 A之前进 一步包括： OCS根据用户帐户计算基于数据流量的信用额度， 所述监控 条件为时间限度。
3、 根据权利要求 2所述的方法， 其特征在于， 所述步骤 B进一步 包括： TPF向 OCS返回剩余的基于数据流量的信用额度，或剩余的时间 长度，或以上二者的组合,请求 OCS提供新的基于数据流量的信用额度。
4、 根据权利要求 1所述的方法， 其特征在于， 所述步骤 A之前进 一步包括： OCS根据用户帐户计算基于时间长度的信用额度， 所述监控 条件为数据流量限度。
5、 根据权利要求 4所述的方法， 其特征在于， 所述步骤 B进一步 包括： TPF向 OCS返回剩余的基于时间长度的信用额度，或剩余的数据 流量，或以上二者的组合，请求 OCS提供新的基于时间长度的信用额度。
6、 根据权利要求 1、 2或 4所述的方法， 其特征在于， 所述步驟 A 之前进一步包括：
A0、 CRF向 TPF提供数据流量限度和时间限度， TPF向 OCS提供 数据流量限度和时间限度。
7、 根据权利要求 6所述的方法， 其特征在于， 所述步骤 AO进一步 包括： CRF向 TPF提供基于数据流量和时间长度进行组合计费的计费模 式指示， TPF向 OCS提供基于数据流量和时间长度进行组合计费的计费 模式指示。
8、 根据权利要求 1所述的方法， 其特征在于， 步骤 A中所述信用 额度为用户帐户下所有信用额度的其中一部分。
9、根据权利要求 1至 5或 8任一所述的方法， 其特征在于， 所述步 骤 B之后进一步包括：
C、 OCS向 TPF提供信用额度和监控条件， 然后返回执行步骤 B。
10、 居权利要求 9所述的方法， 其特征在于， 所述步驟 C之前进 一步包括：
0CS根据剩余的基于数据流量的信用额度， 或剩余的时间长度， 或 以上二者的组合， 计算基于数据流量的新的信用额度；
或， OCS根据剩余的基于时间长度的信用额度，或剩余的数据流量， 或以上二者的组合， 计算基于时间长度的新的信用额度。
11、 根据权利要求 3所述的方法， 其特征在于， 所述步骤 B之后进 一步包括： OCS确定触发当前信用请求的原因， 如果所述原因为时间限 度定时器期满，则 OCS判断用户使用的数据流量是否低于系统设置的数 据流量最小值， 如果是， 则 OCS终止当前与 TPF之间的对话； 否则， OCS向 TPF提供时间限度和计算的新的基于数据流量的信用额度，然后 返回执行步骤 B。
12、 根据权利要求 11所述的方法， 其特征在于， 所述 OCS终止当 前与 TPF之间的对话为： OCS向 TPF发送终止操作指示， TPF释放与 当前 OCS和 TPF之间对话相对应的业务的数据流的会话。
PCT/CN2005/001874 2004-11-08 2005-11-08 Procede de traitement de facturation en ligne WO2006047965A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05806963A EP1760932A4 (en) 2004-11-08 2005-11-08 METHOD OF PROCESSING ONLINE INVOICING
US11/651,868 US20070185809A1 (en) 2004-11-08 2007-01-09 Method and system for processing online charging

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200410090738.8 2004-11-08
CNB2004100907388A CN1327652C (zh) 2004-11-08 2004-11-08 一种在线计费的处理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/651,868 Continuation US20070185809A1 (en) 2004-11-08 2007-01-09 Method and system for processing online charging

Publications (1)

Publication Number Publication Date
WO2006047965A1 true WO2006047965A1 (fr) 2006-05-11

Family

ID=36318899

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/001874 WO2006047965A1 (fr) 2004-11-08 2005-11-08 Procede de traitement de facturation en ligne

Country Status (4)

Country Link
US (1) US20070185809A1 (zh)
EP (1) EP1760932A4 (zh)
CN (1) CN1327652C (zh)
WO (1) WO2006047965A1 (zh)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1303781C (zh) * 2004-04-01 2007-03-07 华为技术有限公司 一种分组数据业务的计费控制方法
GB0525244D0 (en) * 2005-12-12 2006-01-18 Nokia Corp Providing communication service sessions
CN1997093B (zh) * 2006-12-28 2010-07-21 大唐软件技术股份有限公司 计费系统的反算方法及计费系统
US8606222B2 (en) * 2006-12-28 2013-12-10 Tekelec Global, Inc. Methods, systems, and computer program products for performing prepaid account balance screening
DE102007017181B3 (de) * 2007-04-12 2008-08-21 T-Mobile International Ag & Co. Kg Verfahren zur netzgesteuerten Volumen- und/oder Zeitbegrenzung von GPRS/UMTS (2G/3G) basierten Diensten
US8942668B2 (en) * 2007-04-20 2015-01-27 Alcatel Lucent Camel service charging in IMS networks
CN101312473B (zh) * 2007-05-25 2011-12-07 中兴通讯股份有限公司 一种实现预付费计费模式类型切换的方法
CN101316175B (zh) * 2008-06-11 2011-03-02 中兴通讯股份有限公司 在线计费方法
EP2406928B1 (en) 2009-03-10 2017-01-04 Telefonaktiebolaget LM Ericsson (publ) Traffic control by ip multimedia subsystem
CN101990186B (zh) 2009-08-07 2013-11-06 华为技术有限公司 释放资源的方法、装置和系统
US9319318B2 (en) 2010-03-15 2016-04-19 Tekelec, Inc. Methods, systems, and computer readable media for performing PCRF-based user information pass through
US8903974B2 (en) 2010-10-05 2014-12-02 Tekelec, Inc. Methods, systems, and computer readable media for user controlled policy sharing
US9332036B2 (en) 2010-10-15 2016-05-03 Tekelec, Inc. Methods, systems, and computer readable media for providing user receptivity driven policy in a communications network
US8620263B2 (en) * 2010-10-20 2013-12-31 Tekelec, Inc. Methods, systems, and computer readable media for diameter routing agent (DRA) based credit status triggered policy control
CN102547640B (zh) * 2010-12-10 2015-09-16 中兴通讯股份有限公司 一种消费限制业务的签约和执行方法及系统
US8681622B2 (en) 2010-12-17 2014-03-25 Tekelec, Inc. Policy and charging rules function (PCRF) and performance intelligence center (PIC) based congestion control
KR101791533B1 (ko) * 2011-04-28 2017-10-30 삼성전자 주식회사 이동통신 시스템에서 자원 예약 방법 및 시스템
US8996670B2 (en) 2011-08-05 2015-03-31 Tekelec, Inc. Methods, systems, and computer readable media for network metadata based policy control
US9467852B2 (en) * 2012-01-19 2016-10-11 Nokia Solutions And Networks Oy Detection of non-entitlement of a subscriber to a service in communication networks
CN104010287A (zh) * 2013-02-27 2014-08-27 中国移动通信集团广东有限公司 业务叠加包实现方法、装置、ggsn、电子设备和计费系统
CN104144060B (zh) * 2013-05-10 2017-11-07 中国电信股份有限公司 一种基于应用的合作计费方法、装置及系统
CN104468135B (zh) * 2014-11-18 2018-01-23 华为技术有限公司 一种在线计费中交互信息的方法及装置
CN106936603B (zh) * 2015-12-31 2020-12-08 华为技术有限公司 一种数据业务计费方法，装置和系统
CN110933241B (zh) * 2018-09-19 2021-03-23 中移信息技术有限公司 一种发送在线计费请求的方法、装置、设备及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5692037A (en) * 1995-03-31 1997-11-25 Cellular Development Systems On demand real time telephone billing equipment
CN1395398A (zh) * 2001-07-10 2003-02-05 华为技术有限公司 在无线数据业务中使用Radius预付费的方法
US6553108B1 (en) * 1996-06-05 2003-04-22 David Felger Method of billing a communication session conducted over a computer network
CN1464682A (zh) * 2002-06-24 2003-12-31 华为技术有限公司 基于验证、授权、计费协议的宽带预付费的实现方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0884888A1 (de) * 1997-06-13 1998-12-16 Siemens Aktiengesellschaft Verfahren zur Vergebuehrung von Verbindungen in einem Kommunikationsnetz
GB2320852B (en) * 1998-02-06 2000-02-23 Orange Personal Comm Serv Ltd Telecommunications
FI113928B (fi) * 1998-09-30 2004-06-30 Ericsson Telefon Ab L M Ennakolta maksettuja palveluja viestintäjärjestelmässä
CN1395391A (zh) * 2001-07-09 2003-02-05 深圳市中兴通讯股份有限公司 一种宽带接入网络计费方法
GB2387069A (en) * 2002-03-27 2003-10-01 Ericsson Telefon Ab L M Indicating different charging regimes for user and signalling data in a communications network
CN100345411C (zh) * 2002-06-06 2007-10-24 华为技术有限公司 支持分组数据预付费特性的移动用户鉴权计费方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5692037A (en) * 1995-03-31 1997-11-25 Cellular Development Systems On demand real time telephone billing equipment
US6553108B1 (en) * 1996-06-05 2003-04-22 David Felger Method of billing a communication session conducted over a computer network
CN1395398A (zh) * 2001-07-10 2003-02-05 华为技术有限公司 在无线数据业务中使用Radius预付费的方法
CN1464682A (zh) * 2002-06-24 2003-12-31 华为技术有限公司 基于验证、授权、计费协议的宽带预付费的实现方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1760932A4 *

Also Published As

Publication number Publication date
CN1327652C (zh) 2007-07-18
EP1760932A1 (en) 2007-03-07
EP1760932A4 (en) 2007-07-25
CN1773920A (zh) 2006-05-17
US20070185809A1 (en) 2007-08-09

Similar Documents

Publication Publication Date Title
WO2006047965A1 (fr) Procede de traitement de facturation en ligne
JP5190085B2 (ja) パケットデータサービスの課金制御方法
WO2005109758A1 (en) A processing method for perfect charging on line based on the service data stream
JP4402714B2 (ja) フローベース課金におけるイベント・トリガと再認証トリガを取り扱う方法
WO2006015547A1 (fr) Procede d'etablissement de dialogues sur la charge de paquets de donnees
WO2006012798A1 (fr) Procede de traitement de reautorisation a base de taxation du flux de donnees par paquets
EP1622304B2 (en) Method for selecting a charging rule in connection with subscriber
JP4891223B2 (ja) パケットデータサービスの課金ルールを強化する方法及びその機能する方法
WO2006015542A1 (fr) Procede de reduction de la charge d'un tpf
WO2006050669A1 (fr) Procede de chargement en fonction d'un flux de paquets de donnees
WO2014094488A1 (zh) 漫游本地业务的计费策略方法及装置
WO2005101734A1 (fr) Procede de facturation de services de donnees par paquets et de controle d'acces de flux de donnees de services
WO2006015543A1 (en) A processing method for re-authorization and re-authorization event and event triggers
WO2006060964A1 (fr) Systeme et procede de traitement permettant une facturation en fonction du flux de paquets de donnees
WO2012041150A1 (zh) 用量监测方法及策略控制与计费规则功能实体
WO2006050670A1 (fr) Procede de traitement de cle de taxation
WO2012041149A1 (zh) 一种用量监测方法及系统
WO2012041148A1 (zh) 一种用量监测方法及系统
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
WWE Wipo information: entry into national phase

Ref document number: 11651868

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2005806963

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005806963

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11651868

Country of ref document: US