WO2006015543A1 - Procede de traitement d'une re-autorisation, evenement de re-autorisation et declencheurs d'evenement - Google Patents

Procede de traitement d'une re-autorisation, evenement de re-autorisation et declencheurs d'evenement Download PDF

Info

Publication number
WO2006015543A1
WO2006015543A1 PCT/CN2005/001231 CN2005001231W WO2006015543A1 WO 2006015543 A1 WO2006015543 A1 WO 2006015543A1 CN 2005001231 W CN2005001231 W CN 2005001231W WO 2006015543 A1 WO2006015543 A1 WO 2006015543A1
Authority
WO
WIPO (PCT)
Prior art keywords
tpf
event
authentication
crf
ocs
Prior art date
Application number
PCT/CN2005/001231
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 WO2006015543A1 publication Critical patent/WO2006015543A1/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
    • 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/1485—Tariff-related aspects
    • 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/62—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP based on trigger specification
    • 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/204—UMTS; GPRS

Definitions

  • the present invention relates to the field of packet data charging, and more particularly to a processing method for re-authenticating and re-authenticating events and triggering events based on packet data flow accounting.
  • FIG. 1 shows a 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 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, and the SGSN is addressed to the corresponding GGSN according to the APN, the GGSN root
  • the MS may not provide the APN to the SGSN according to the APN.
  • the SGSN may select the default APN according to the subscription information of the MS user.
  • the QoS parameter is the quality requirement of the packet data service specified by the MS. ⁇ Used by the MS to identify a PDP context
  • Step 102 After receiving the Activate PDP Context Request, the SGSN performs security check and encryption with the MS. This step is optional.
  • Step 103 The SGSN parses the address information of the GGSN according to the APN. If the SGSN can parse the address information of the GGSN according to the APN, the TEID is created for the PDP Context, and the TEID can be an International Mobile Subscriber Identity (IMSI) and an NSAPI.
  • the SGSN sends a PDP Context Request to the GGSN.
  • the PDP Context Request contains the PDP type, PDP address, APN, QoS 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. If the GGSN cannot meet the quality of service requirements of the QoS parameters, the GGSN rejects the PDP Context creation request initiated by the SGSN. The SGSN then rejects the PDP Context activation request initiated by the MS.
  • Step 105 After receiving the PDP Context creation response, the SGSN inserts NSAPI and GGSN address information for identifying the PDP Context in the PDP Context, and selects a radio priority according to the agreed QoS parameter, and then returns a PDP Context activation response to the MS (Activate PDP Context Accept ), the PDP Context activation response carries information such as PDP type, PDP address, ⁇ , agreed QoS parameters, wireless priority, PDP configuration options, and the like. And, the SGSN starts charging. After receiving the PDP Context activation response, the MS has established a direct route between the MS and the GGSN, and can perform packet data transmission.
  • Step 106 The MS performs packet data interaction through the SGSN, the GGSN, and the PDN.
  • 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 charging termination point is set in the PDP Context.
  • 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.
  • email email
  • WAP Wireless Application Protocol
  • FTP file transfer protocol
  • 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.
  • 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 data-based charging is much smaller than the charging granularity based on a PDP Context.
  • the granularity can be regarded as the size of the screening hole.
  • the charging granularity based on a PDP Context is a PDP Context.
  • the meshing granularity based on the IP data stream is an IP service data stream is a sieve hole, that is, a plurality of sieve holes are included for one PDP Context, and therefore, the charging and ratio based on the IP data stream is based on Compared to the charging of a PDP Context, IP data stream based charging can provide operators or service providers with more abundant charging means.
  • the 3GPP describes the system structure, functional requirements, and message interaction procedures of the FBC.
  • the FBC system structure supporting online charging is shown in Figure 2A.
  • the customized application based on mobile network enhanced logic (CAMEL, Customised Application for Mobile Network Enhanced Logic (SCP) Service Control Point (SCP) and Service Data Flow Based Credit Control Function (CCF) 202 constitute an online charging system (OCS, Online Charging System ) 206.
  • the CCF 202 communicates with the Service Data Flow Based Charging Rule Function (CRF) 203 through the Ry interface, and the CRF 203 communicates with the Application Function (AF) through the R 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
  • 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 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), etc.
  • MSISDN mobile station international number
  • IMSI international mobile subscriber identity
  • MNC mobile network coding
  • MCC mobile country. Code
  • the charging rules may be different, such as the corresponding rate of the QoS parameter falling. Also fell.
  • the TPF 205 may resend the charging rule request to the CRF 203 to request a new charging rule when the bearer is modified; the CRF 203 selects an appropriate charging rule according to the above input information provided by the TPF 205, and returns to the TPF 205.
  • the selected charging rule includes charging mechanism, charging type, charging key, service data flow filter, and 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 directly.
  • the TPF 205 is provided with a rate, and only the rate-related parameters are provided to the TPF 205; the service data filter is used to indicate which IP data streams the TPF 205 filters, and then the TPF 205 filters the filtered IP data according to the charging rules. Billing.
  • the service data filter may include an IP5 tuple, and the IP5 tuple may include source/destination IP address, source/destination port number (Port Number), protocol identifier (Protocol ID), and the like.
  • the CRF 203 indicates the TPF 205 to the 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, the protocol type is Transmission Control Protocol (TCP), and the filtered IP data stream is calculated according to the charging rule. fee.
  • TCP Transmission Control Protocol
  • 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.
  • 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, the SCP 201 and the 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 and is applied only to online charging. The system can be implemented by adding new functions 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 SGSN changes, the TPF 205 needs to re-examine the basis.
  • the SGSN change event in the right event reports the occurrence of the SGSN change event to the OCS 206, and the OCS 206 re-determines the rate according to the current location of the user update, 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 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 charging rule
  • the enforcement point, CRF 203 is the control point of the charging rule.
  • the triggering event triggers the charging rule request process, that is, the TPF requests the charging rule from the CRF, and the triggering event triggers the TPF to request the charging rule from the CRF.
  • the charging rule request process that is, the TPF requests the charging rule from the CRF
  • the triggering event triggers the TPF to request the charging rule from the CRF.
  • Step 301 The user equipment (UE) sends a Modify Bearer Service Request to the TPF.
  • the GGSN receives the PDP Context Request (Update PDP Context Request).
  • Step 302 After receiving the bearer modification request, the TPF matches the bearer modification event with the pre-stored trigger event. If yes, go to step 303; otherwise, continue to monitor the trigger event.
  • Step 303 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.
  • Steps 304 to 305 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 related 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 charging rule operation instructions.
  • Step 306 After receiving the charging rule, the TPF performs corresponding operations on the charging rule selected by the CRP according to the charging rule operation instruction.
  • Step 307 The TPF returns a Modify Bearer Service Accept to the UE, and continues the subsequent bearer modification process.
  • the bearer modification triggers the re-authentication process, that is, the TPF requests the OCS to re-authenticate the user.
  • the specific implementation process is shown in Figure 4:
  • Step 401 The UE sends a Modify Bearer Service Request to the TPF.
  • the GGSN receives the PDP Context Request (Update PDP Context Request).
  • Step 402 After receiving the bearer modification request, the TPF matches the bearer modification event with the pre-stored re-authentication event. If yes, go to step 403. Otherwise, continue to monitor the occurrence of the re-authentication event.
  • Step 403 The TPF sends a credit control request (Credit Control Request) to the OCS, where the credit control request carries the remaining credit of the user and related charging rule information, and requests the OCS to recalculate the credit of the user.
  • the relevant charging rule information provided by the TPF to the OCS can be obtained from the CRF.
  • Step 404 After receiving the credit control request, the OCS recalculates the credit of the user, and then returns a credit control response (Credit Control Answer) to the TPF. If the OCS calculates the credit of the user, the credit control response carries the OCS re The calculated user credit, if the OCS does not calculate the credit of the user, the credit control response may carry an error reason value.
  • Step 405 After receiving the credit control response, the TPF returns a Modify Bearer Service Accept 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. Modifying the process; if the credit control response does not carry the user's credit, the UE-initiated bearer modification request is rejected.
  • the specification describes the charging mode of the CRF that controls 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: SGSN change events, QoS changes events, RAT type change events, and transport stream template (TFT) changes ( TFT change) event.
  • the specification also describes how the OCS controls the credit usage of the TPF through the mechanism reported by the re-authentication event, that is, the TPF reports to the OCS after the re-authentication event occurs.
  • the OCS obtains the credit usage of the user and the change of the bearer through the re-authentication event reported by the TPF, and recalculates the credit of the user and delivers the credit to the TPF.
  • the re-authentication event defined in the specification may include: a credit authorization lifetime expiry event, a user idle state timeout event, a charging rule is changed event, and may also include some GPRS events. , such as SGSN change event, QoS parameter change event, RAT type change event.
  • both the trigger event and the re-authentication event include GPRS events, such as SGSN change events, QoS parameter change events, RAT type change events, etc., so that for a certain GPRS event, the TPF will use the GPRS event.
  • the trigger event and the re-authentication event are matched. Therefore, the occurrence of the GPRS event needs to be reported to the CRF and the OCS, respectively, resulting in waste of resources of the FBC system.
  • an object of the present invention is to provide a processing method for performing re-authentication
  • another object of the present invention is to provide a method for processing a re-authentication event and a trigger event, which is improved based on packet data flow charging. Implement the process.
  • the present invention provides a processing method for performing re-authentication, the method comprising the following steps:
  • Al and CRF provide re-authentication indication to the TPF
  • the TPF initiates a re-authentication process.
  • the step A1 further includes: the CRF receives an internal or external event, determines whether the TPF is required to initiate a re-authentication process, and if yes, performs step A1.
  • the internal event is: The trigger event reported to the CRF when the TPF detects the trigger event.
  • the external event is: Input information provided by the OCS or AF to the CRF.
  • the process of determining whether the TPF initiates the re-rights right is: determining whether the received event matches the obtained re-authentication event, and if yes, performing step A1.
  • the determining whether the TPF needs to initiate the re-authentication process is: determining whether the event triggered by the received event matches the obtained re-authentication event, and if yes, performing step A1.
  • the re-authentication event is: a re-authentication event configured in the CRF, or a re-authentication event provided by the OCS to the CRF, or a combination of the two.
  • the re-authentication indication further includes: re-authentication event information.
  • the TPF initiates the re-authentication process in step B1:
  • the TPF requests the OCS to re-authenticate the user.
  • the step B1 further includes: the TPF provides re-authentication event information to the OCS.
  • the step B1 further includes: the OCS recalculates the credit of the user, and returns the recalculated user credit to the TPF.
  • the present invention also provides a method for processing a re-authentication event and a trigger event, the method comprising the following steps:
  • the CRF receives an internal or external event, and determines whether the TPF needs to initiate a re-authentication process. If yes, step B2 is performed;
  • the CRF provides a re-authentication indication to the TPF, and according to the received re-authentication indication, the TPF initiates a re-authentication procedure.
  • the internal event is: The event that the TPF reports to the CRF when the trigger event occurs.
  • the external event is: Input information provided by the OCS or AF to the CRF.
  • the trigger event is provided by the CRF to the TPF.
  • the step B2 further includes: the TPF providing the trigger event reported to the CRF as re-authentication event information to the OCS.
  • step A2 The process of determining whether the TPF is required to initiate the re-authentication process in step A2 is as follows: Trigger event matches get re-authentication event, and if so, proceed to step B 2.
  • the re-authentication event is: a re-authentication event configured in the CRF, or a re-authentication event provided by the OCS to the CRF, or a combination of the two.
  • the re-authentication indication further includes: re-authentication event information.
  • the TPF initiates the re-authentication process in step B2 as follows: The TPF requests the OCS to re-authenticate the user.
  • the step B2 further includes: the TPF providing re-authentication event information to the OCS.
  • the step B2 further includes: the OCS recalculates the credit of the user, and returns the recalculated user credit to the TPF.
  • the step B2 further includes: the OCS recalculates the credit of the user, and returns the recalculated user credit to the TPF.
  • the CRF determines whether the TPF is required to initiate a re-authentication process, and if necessary, the CRF instructs the TPF to request the OCS to re-authenticate the user.
  • the TPF can only monitor the occurrence of a trigger event, and report to the CRF when the trigger event occurs, and the CRF determines whether the trigger event requires the TPF to initiate a re-authentication process; the CRF can also be based on external event information, such as OCS, The AF selects the input information from the charging rule provided by the CRF to determine whether the TPF needs to initiate the re-authentication process.
  • the implementation process based on packet data flow charging is improved, the information interaction between the FBC entities is reduced, the resources between the FBC entities are greatly saved, and the information exchange process between the FBC entities is further improved. Clear and clear.
  • Figure 1 shows the PDP Context activation, data transmission, deactivation flowchart
  • Figure 2A shows the structure of the FBC system supporting online charging
  • FIG. 2B is a structural diagram of an FBC system supporting offline charging
  • FIG. 3 is a flow chart showing a triggering rule triggered by a trigger event TPF to a CRF in the prior art
  • FIG. 4 is a flow chart showing a re-authentication of a TPF request OCS by a re-authentication event trigger in the prior art
  • FIG. 5 is a flow chart showing online charging when a trigger event occurs in the present invention.
  • FIG. 6 is a flow chart showing the OCS providing input information to the CRF in the present invention
  • FIG. 7 is a flow chart showing the online charging when the bearer is modified in the present invention
  • Fig. 8 is a flow chart showing the online charging of the CRF based on external input information in the present invention. Mode for carrying out the invention
  • the TPF only monitors the occurrence of the triggering event, and reports to the CRF when the triggering event occurs.
  • the CRF determines whether the TPF needs to initiate the re-authentication process according to the triggering event reported by the TPF. If yes, the TPF is notified to request the OCS. Re-authenticate the user.
  • FIG. 5 is a flowchart showing the online charging when the triggering event occurs in the present invention. As shown in FIG. 5, the online charging implementation process when the triggering event occurs includes the following steps:
  • Step 501 The TPF monitors the occurrence of the trigger event to determine whether the currently occurring event matches the stored trigger event. If yes, go to step 502. Otherwise, continue to monitor the occurrence of the trigger event.
  • the specific implementation process is as follows:
  • the TPF sends a charging rule request to the CRF, where the charging rule request carries charging rule input information, such as UE information, network information, and the like.
  • the CRF selects an appropriate charging rule according to the received revenue information, and the charging mechanism in the charging rule indicates "online charging”.
  • the CRF can further determine that the TPF needs to be monitored according to the input information provided by the TPF. trigger event, The charging rule and the triggering event are then sent to the TPF.
  • the CRF can also provide the TPF with a trigger event that requires it to be monitored.
  • the CRF can continue to send a new trigger event to the TPF after receiving the trigger event reported by the TPF.
  • the CRF When the CRF receives the input information provided by an external entity, such as AF or OCS, it can also provide the TPF with a trigger event that requires it to be monitored. That is, the CRF can actively send a trigger event to the TPF.
  • an external entity such as AF or OCS
  • the TPF After receiving the charging rules and triggering events provided by the CRF, the TPF monitors the occurrence of the triggering event, filters out the corresponding IP data stream according to the filter in the charging rule, and then applies the corresponding charging rule to filter. The outgoing IP data stream is charged.
  • the TPF instructs "online charging” according to the charging mechanism in the charging rule, requests the user credit from the OCS, and the OCS calculates the credit of the user and returns it to the TPF.
  • Step 502 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 and the currently occurring trigger event.
  • Step 503 to step 504 After receiving the charging rule request, the CRF may further select an appropriate charging rule according to the related input information provided by the AF according to the input information carried in the charging rule request, and the CRF is charged according to the charging.
  • the triggering event carried in the rule request determines whether the re-authentication process needs to be triggered.
  • the charging rule is returned to the TPF, and the provided charging rule carries the selected charging rule, the charging rule operation instruction, and Re-authentication indication
  • the re-authentication indication is used to notify the TPF to initiate a re-authentication process, requesting the OCS to re-authenticate the user
  • the re-authentication indication may carry event information that triggers re-authentication, and is used for CRF via
  • the TPF notifies the OCS of the reason for triggering the current re-authentication right; otherwise, the charging rule is returned to the TPF, and the provided charging rule carries only the selected charging rule and the charging rule operation indication.
  • Step 505 After receiving the charging rule, the TPF operates the indication according to the charging rule to the CRF. The selected charging rules are operated accordingly.
  • Step 506 The TPF sends a credit control request to the OCS according to the re-authentication indication carried in the charging rule, where the credit control request carries the remaining credit of the user, and requests the OCS to recalculate the credit of the user.
  • the credit control request may further carry event information that triggers the current re-authentication process in the re-authentication indication, to notify the OCS of the reason for triggering the current re-authentication.
  • Step 507 After receiving the credit control request, the OCS recalculates the credit of the user, and then returns a credit control response to the TPF. If the OCS calculates the credit of the user, the credit control 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 cause value.
  • the CRF may not provide a re-authentication indication to the TPF.
  • the TPF determines whether the OCS is required to re-authenticate the user according to the charging rule sent by the CRF. For example, the TPF determines whether the charging key in the charging rule changes. Or the TPF determines whether the filter in the charging rule changes.
  • the CRF determines whether the TPF needs to initiate the re-authentication process: by pre-configuring the re-authentication event in the CRF, or by carrying the re-authentication event when the OCS provides the input information to the CRF, so that the CRF acquires the TPF.
  • the event that initiates the re-authentication process is performed.
  • the CRF matches the obtained re-authentication event by the triggering event reported by the TPF. If the CRF can match, the CRF determines that the triggering event requires the TPF to initiate the re-authentication process. Otherwise, The CR determines that the trigger event does not require the TPF to initiate the re-authentication process.
  • the CRF learns that the charging rule is modified into a re-authentication event.
  • the AF can provide input information to the CRF, and the CRF selects a new charging rule according to the input information.
  • the CRF receives The AF provides an input information event that triggers the charging rule to modify the SCA event.
  • Figure 6 is a flow chart showing the input of information from the OCS to the CRF in the present invention, as shown in Figure 6.
  • the implementation of the OCS to provide input information to the CRF includes the following steps:
  • Step 601 The OCS sends an OCS-related charging information to the CRF, where the information may further carry a re-authentication event that is sent to the TPF by the CRF.
  • the trigger event sent to the TPF may include a corresponding re-authentication event.
  • the TPF may only monitor the trigger event and report it to the CRF when the trigger event occurs;
  • the triggering event reported by the TPF determines whether the triggering event is a re-authentication event. Whether the TPF needs to initiate a re-authentication process requests the OCS to re-authenticate the user.
  • Step 602 The CRF sends a response message to the OCS.
  • the charging rule is changed in the CRF, or the charging rule is changed when the OCS sends the OCS-related charging information to the CRF.
  • the CRF needs to trigger the re-authentication process when the charging rule changes.
  • the operator performs sub-regional charging for the user, that is, the operator charges the user at different rates according to the range of the local area when the user uses the service.
  • the TPF detects the SGSN in the trigger event. After the change event occurs, the CRF is reported to the CRF. Further, the TPF can provide the CRF with the address information of the SGSN where the user is currently located.
  • the CRF learns the rate of the service used by the user in the current local area according to the SGSN change event and the address information of the SGSN where the user is currently located. Then, the charging rule is modified, such as modifying the charging key in the charging rule, and using the new charging button to indicate the current rate. In addition, the CRF determines that the SGSN change event causes a change in the charging rule. According to the re-authentication event information obtained by the CRF, the TPF needs to initiate a re-authentication process when the charging rule changes. The new charging rule and the re-authentication indication may further carry the re-authentication event information, such as the charging rule change, to notify the OCS via the TPF to trigger the reason of the current re-authentication right.
  • the TPF filters out the filter based on the received charging rule (Filter).
  • the corresponding IP data stream is then charged by the corresponding charging rule for the filtered IP data stream.
  • the TPF requests the OCS to re-authenticate the user according to the re-authentication indication, and the OCS recalculates the credit of the user and returns to the TPF.
  • FIG. 7 is a flowchart showing the online charging when the bearer is modified in the present invention. As shown in FIG. 7, the online charging implementation process when the bearer is modified includes the following steps:
  • Step 701 to step 702 are basically the same as steps 301 to 302.
  • Steps 703 to 708 are basically the same as steps 502 to 507.
  • Step 709 is substantially the same as step 405.
  • the OCS reports and requests a new user credit mechanism, so that the OCS can know the usage of the service by the user, such as the length of time that the user uses a certain service. , or data traffic that occurs when a user uses a service.
  • operators can use some preferential charging policies to attract users. For example, when the accumulated time length of a certain service is reached, the data traffic of a certain service reaches a certain value. At this time, the rate of the corresponding service is adjusted to the preferential rate.
  • the OCS can provide the CRF with input information for determining the charging rule, and notify the CRF to use the new service rate for the user to use the corresponding service. .
  • the CRF selects an appropriate charging rule and sends it to the TPF according to the input information of the charging rule provided by the OCS.
  • the AF may also provide the CRF with input information for determining the charging rule.
  • a service uses time-sharing charging, for example, the rate of the user using the service is different at different times on the same day, and the AF determines that the user uses a certain service to enter.
  • the AF may provide the CRF with input information for determining the charging rule, and notify the CRF to use the new service rate for the user to use the corresponding service for charging.
  • the CRF selects the appropriate charging rule and sends it to the TPF based on the input information of the charging rule provided by the AF.
  • the CRF in the case of online charging, when the CRF is received from the outside, it is used for determining
  • the input information of the fee rule can be used to deliver the appropriate charging rule to the TPF, and the CRF can determine whether the TPF needs to initiate the re-authentication process according to the input information. If necessary, the re-authentication indication is sent to the TPF, and the specific implementation is implemented.
  • the process is shown in Figure 8:
  • Step 801 The CRF receives an internal or external Trigger Event and information related to the event, such as an event in which the AF or OCS sends a charging rule selection input information to the CRF.
  • Step 802 The CRF selects an appropriate charging rule according to the obtained input information.
  • the input information may be the charging related input information provided by the AF.
  • the user uses a certain service provided by the AF, and the service has special requirements for charging, for example, the charging rate is different from the charging rate of other services, so
  • the AF provides the CRF with the charging input information related to the service; the charging related input information provided by the TPF; or the charging related input information provided by the OCS; and the CRF determines whether the TPF needs to initiate the re-authentication
  • the re-authentication indication is sent to the TPF, and the re-authentication indication may further carry the re-authentication event information, so as to notify the OCS via the TPF to trigger the current re-authentication reason. Otherwise, In step 803, the re-authentication indication is not required to be sent to the TPF, and steps 805 to 806 may be omitted.
  • Step 803 If the charging rule changes, the CRF sends a charging rule to the TPF, where the charging rule can carry the selected charging rule, the charging rule operation indication, and the re-authentication indication.
  • Step 804 After receiving the charging rule, the TPF performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation indication.
  • Step 805 The TPF sends a credit request (Credit Request) to the OCS according to the re-authentication indication carried in the provided charging rule, where the credit request carries the remaining credit of the user and related new charging rule information.
  • Request OCS to recalculate the user's credit.
  • the re-authentication event information carried in the re-authentication indication may be further carried in the credit request to notify the OCS of the reason for triggering the current re-authentication right.
  • Step 806 After receiving the credit request, the OCS recalculates the credit of the user, and then returns a credit response (Credit Response) to the TPF. If the OCS calculates the credit of the user, the credit response carries the user credit recalculated by the OCS. If the OCS does not calculate the credit of the user, the credit response may carry an error reason value.

Abstract

L'invention concerne un procédé de traitement d'une ré-autorisation. Ce procédé comprend CRF qui fournit une indication de ré-autorisation à TPF, TPF initie un flux de ré-autorisation, en fonction de l'indication de la ré-autorisation reçue. Cette invention a également pour objet un procédé de traitement pour événement de ré-autorisation et déclencheur d'événements. Ledit procédé comporte CRF qui permet de recevoir un événement interne ou externe, puis, d'évaluer si TPF doit initier un flux de ré-autorisation, si tel est le cas, CRF fournit une indication de ré-autorisation à TPF qui initie le flux de ré-autorisation, en fonction de l'indication de ré-autorisation reçue. Selon les modes de réalisation de ladite invention, le flux de chargement basé sur le flux de données de service est utilisé, et l'interaction d'informations entre les entités FBC est diminuée, les ressources entre les entités FBC sont ainsi sauvegardées, et le flux d'interaction des informations entre les entités FBC devient clair et explicite.
PCT/CN2005/001231 2004-08-10 2005-08-10 Procede de traitement d'une re-autorisation, evenement de re-autorisation et declencheurs d'evenement WO2006015543A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200410070068.3 2004-08-10
CN 200410070068 CN1735023A (zh) 2004-08-10 2004-08-10 一种进行重鉴权及重鉴权事件和触发事件的处理方法

Publications (1)

Publication Number Publication Date
WO2006015543A1 true WO2006015543A1 (fr) 2006-02-16

Family

ID=35839137

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/001231 WO2006015543A1 (fr) 2004-08-10 2005-08-10 Procede de traitement d'une re-autorisation, evenement de re-autorisation et declencheurs d'evenement

Country Status (2)

Country Link
CN (1) CN1735023A (fr)
WO (1) WO2006015543A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111093195A (zh) * 2019-11-29 2020-05-01 北京长焜科技有限公司 一种鉴权策略控制的方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101183939B (zh) * 2006-11-14 2010-06-09 中兴通讯股份有限公司 基于多重认证的重授权方法
CN101291233B (zh) 2007-04-20 2011-04-20 华为技术有限公司 一种实现事件检测的方法及系统
CN107819925A (zh) * 2017-11-15 2018-03-20 珠海市魅族科技有限公司 一种信息传输方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001091446A2 (fr) * 2000-05-24 2001-11-29 Nokia Corporation Identificateur de taxation commun pour reseaux de communications
WO2003081843A1 (fr) * 2002-03-27 2003-10-02 Telefonaktiebolaget Lm Ericsson (Publ) Facturation dans un reseau de communication
EP1422866A1 (fr) * 2002-11-25 2004-05-26 Swisscom AG Procédé et appareil pour déterminer des coûts pour la facturation du transport de données

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001091446A2 (fr) * 2000-05-24 2001-11-29 Nokia Corporation Identificateur de taxation commun pour reseaux de communications
WO2003081843A1 (fr) * 2002-03-27 2003-10-02 Telefonaktiebolaget Lm Ericsson (Publ) Facturation dans un reseau de communication
EP1422866A1 (fr) * 2002-11-25 2004-05-26 Swisscom AG Procédé et appareil pour déterminer des coûts pour la facturation du transport de données

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111093195A (zh) * 2019-11-29 2020-05-01 北京长焜科技有限公司 一种鉴权策略控制的方法

Also Published As

Publication number Publication date
CN1735023A (zh) 2006-02-15

Similar Documents

Publication Publication Date Title
US8798575B2 (en) Method for improving service data flow based charging and system thereof
US20070185809A1 (en) Method and system for processing online charging
JP4402714B2 (ja) フローベース課金におけるイベント・トリガと再認証トリガを取り扱う方法
US7889650B2 (en) Method for establishing diameter session for packet flow based charging
JP4482030B2 (ja) パケットデータフローの課金に基づく再認証の処理方法
JP5190085B2 (ja) パケットデータサービスの課金制御方法
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
WO2006050669A1 (fr) Procede de chargement en fonction d'un flux de paquets de donnees
WO2014094488A1 (fr) Procédé et dispositif de gestion de politique de facturation destinés à un service local d'itinérance
WO2005101734A1 (fr) Procede de facturation de services de donnees par paquets et de controle d'acces de flux de donnees de services
WO2006015543A1 (fr) Procede de traitement d'une re-autorisation, evenement de re-autorisation et declencheurs d'evenement
WO2006060964A1 (fr) Systeme et procede de traitement permettant une facturation en fonction du flux de paquets de donnees
CN100397821C (zh) 一种基于分组数据流计费中的处理方法
WO2011127666A1 (fr) Procédé, dispositif et système de traitement pour un prélèvement
WO2006050670A1 (fr) Procede de traitement de cle de taxation
WO2014079323A1 (fr) Procédé, dispositif, et système, pour exécuter une fonction de service local d'itinérance
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 KP KR KZ LC LK LR LS LT LU LV 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): BW GH 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