WO2006015548A1 - Methode de traitement fondee sur un evenement de declenchement de chargement et sur un evenement de reautorisation de flux de donnees de paquets - Google Patents

Methode de traitement fondee sur un evenement de declenchement de chargement et sur un evenement de reautorisation de flux de donnees de paquets Download PDF

Info

Publication number
WO2006015548A1
WO2006015548A1 PCT/CN2005/001238 CN2005001238W WO2006015548A1 WO 2006015548 A1 WO2006015548 A1 WO 2006015548A1 CN 2005001238 W CN2005001238 W CN 2005001238W WO 2006015548 A1 WO2006015548 A1 WO 2006015548A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
tpf
ocs
authentication
bearer
Prior art date
Application number
PCT/CN2005/001238
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
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to DE200560006094 priority Critical patent/DE602005006094T2/de
Priority to EP20050772490 priority patent/EP1693984B1/en
Priority to JP2007501099A priority patent/JP4402714B2/ja
Priority to US10/563,023 priority patent/US20080320564A1/en
Priority to CA 2540922 priority patent/CA2540922C/en
Publication of WO2006015548A1 publication Critical patent/WO2006015548A1/zh

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
    • 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
    • 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/66—Policy and charging system
    • 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 based on packet data flow charging trigger event and re-authentication event. Background of the invention
  • 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
  • information such as PDP type, access point name (APN, Access Point Name), required quality of service (QoS) parameter, transaction identifier ( ⁇ , Transaction Identifier), etc.
  • NSAPI is The SGSN and the Gateway GPRS Support Node (GGSN) are used as part of the Tunnel Identifier (TID) to identify the PDP Context.
  • the PDP type includes the end-to-end protocol (PPP, Peer- Peer Protocol type, Internet Protocol (IP) type, etc.;
  • APN can be provided by the MS to the SGSN, and the SGSN is addressed to the corresponding GGSN according to the APN, and the GGSN is 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, TI, agreed QoS parameters, wireless priority, PDP configuration options, and the like. And, SG.SN starts charging.
  • the MS 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 Delete Request to the GGSN.
  • 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 Flow IP Data streams
  • IP Flow IP Data streams
  • the billing based on IP data stream can be considered to be in the same PDP Context through some filter similar to the sieve.
  • the IP data streams of different services are separately filtered, and then the IP data streams filtered by different filters are separately charged to achieve separate charging for different service data flows.
  • the fee granularity is much smaller than the billing granularity based on a PDP Context.
  • the granularity can be regarded as the size of the sieve hole, based on a PDP Conte.
  • the billing granularity of xt is a PDP Context is a
  • 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 process of the FBC.
  • the FBC system structure supporting online charging is shown in Figure 2A.
  • the customized application based on mobile network enhanced logic (CAMEL, Customised Application for Mobile Network Enhanced Logic (SCP) Service Control Point (SCP) and Service Data Flow Based Credit Control Function (CCF) 202 constitute an online charging system (OCS, Online Charging System ) 206.
  • the CCF 202 communicates with the Service Data Flow Based Charging Rule Function (CRF) 203 through the Ry interface, and the CRF 203 communicates with the Application Function Entity (AF) through the Rx interface.
  • the CRF 203 communicates with the Traffic Plane Function (TPF) 205 through the Gx interface, and the CCF 202 communicates with the TPF 205 through the Gy interface.
  • 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 CRJF 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, for example, the corresponding rate of the QoS parameter is decreased. decline.
  • 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 a source/destination IP address, a source/destination port number (Port Number), a 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 current use by the user.
  • the service type, CRF 203 selects the corresponding charging rule according to the service type.
  • 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 only applied to the online meter.
  • the fee 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 CRJF according to the charging rule operation indication.
  • 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 a 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.
  • Trigger events defined in the specification may include: SGSN change events, QoS changes events, RAT type change events, 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 (idle 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.
  • the CRF may select a new charging rule according to the received triggering event, and deliver the selected new charging rule to the TPF.
  • the new charging rule sent by the CRF to the TPF may match the charging rule change event in the re-authentication event, and the re-authentication process is triggered again, so that the first re-authentication process becomes redundant.
  • the processing process wastes the interface resources between the TPF and the OCS in the FBC system.
  • an object of the present invention is to provide a method for processing a packet data stream charging trigger event and a re-authentication event, and to improve a re-authentication process based on packet data flow charging.
  • the present invention provides a processing method based on packet data flow charging trigger event and re-authentication event, the method comprising the following steps:
  • the TPF determines whether the currently occurring bearer event matches the trigger event, and if yes, step B is performed; otherwise, step C is directly performed; B.
  • the TPF triggers the charging rule request process;
  • the TPF determines whether the re-authentication process needs to be triggered. If yes, the re-authentication process is triggered. Otherwise, the current process ends.
  • the step B includes: The TPF requests an accounting rule from the CRF, and the CRF returns a selected charging rule to the TPF.
  • the step B further includes: the TPF providing the CRF with the currently occurring bearer event. If the TPF determines that the currently occurring bearer event matches the triggering event, the determining whether the triggering re-authentication process needs to be triggered in step C is: determining whether the charging rule provided by the CRJF changes, and if so, triggering the re-authentication process ; Otherwise, the current process ends.
  • the method further includes: determining whether the change of the charging rule needs to trigger the re-authentication process, and if yes, triggering the re-authentication process; otherwise, ending the current process.
  • the method further includes: the TPF determining whether the currently occurring bearer event matches the re-authentication event, and if yes, triggering the re-authentication process, and further providing the OCS with the currently occurring bearer Event; otherwise, only the reauthentication process is triggered.
  • the trigger re-authentication process further includes: the TPF providing the OCS with a changed charging rule. If the TPF determines that the currently occurring bearer event does not match the triggering event, the determining whether the triggering re-authentication process needs to be triggered in step C is: determining whether the currently occurring bearer event matches the re-authentication event, and if so, The re-authentication process is triggered; otherwise, the current process is ended.
  • the trigger re-authentication process further includes: the TPF providing the OCS with the currently occurring bearer event.
  • the trigger re-authentication process includes: the TPF requests a user credit from the OCS, and the OCS returns a recalculated user credit to the TPF.
  • the trigger event is provided by the CRF to the TPF.
  • the re-authentication event is provided by the OCS to the TPF, or is provided by the OCS through the CRF to the method according to the present invention.
  • the TPF first determines whether the bearer event that occurs is matched with the trigger event, and if yes, The triggering event is reported to the CRF. Then, it is determined whether the occurrence of the bearer event matches the re-authentication event. If the match occurs, the re-authentication event of the re-authentication event is reported to the OCS, and the subsequent re-authentication process is continued.
  • 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 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 the processing of the trigger event and the re-authentication event in the present invention
  • Fig. 6 is a diagram showing the process message interaction of the trigger event and the re-authentication event in the present invention. Mode for carrying out the invention
  • the TPF when a bearer event occurs, the TPF first determines whether the bearer event that occurred is Matching with the triggering event, if it matches, report the triggering event to the CRF; and then determine whether the occurrence of the bearer event matches the re-authentication event. If it matches, report the re-authentication event to the OCS, and continue to follow. Re-authentication process. In this way, only one re-authentication interaction needs to be performed between the TPF and the OCS, and the re-authentication process when the trigger event and the re-authentication event overlap are optimized.
  • FIG. 5 is a flowchart of processing of a trigger event and a re-authentication event in the present invention. As shown in FIG. 5, the processing of the trigger event and the re-authentication event includes the following steps:
  • Step 501 to step 502 The TPF monitors the occurrence of the bearer event, and determines whether the bearer event that occurs is matched with the trigger event. If yes, step 503 is performed; otherwise, step 507 is performed.
  • Step 503 The TPF triggers the charging rule request process, that is, the TPF provides the CRF with the input information of the selected charging rule, and further provides the CRF with the currently occurring bearer event, to notify the CRF that the triggering event of the charging rule request process is triggered.
  • the CRF is requested to provide a charging rule.
  • the CRF After receiving the charging rule request, the CRF provides the selected charging rule and the charging rule operation instruction to the TPF according to the provisioning input information and the charging event selection charging rule.
  • the TPF performs the corresponding operation on the charging rule selected by the CRF according to the charging rule operation instruction.
  • Step 504 The TPF determines whether the charging rule provided by the CRF is changed. If yes, step 505 is performed; otherwise, step 507 is performed.
  • Step 505 The TPF determines whether the change of the charging rule needs to trigger the re-authentication process. If yes, step 506 is performed; otherwise, step 507 is performed.
  • Step 506 The TPF determines whether the currently occurring bearer event matches the re-authentication event. If yes, step 508 is performed; otherwise, step 509 is performed.
  • Step 507 The TPF determines whether the currently occurring bearer event matches the re-authentication event. If yes, step 508 is performed; otherwise, the current process ends.
  • the re-authentication event that currently triggers the re-authentication process; the OCS provides the recalculated user credit to the TPF and then ends the current process.
  • Step 509 The TPF triggers the re-authentication process, that is, the TPF provides the OCS with the user's remaining credit and related charging rule information, and requests the OCS to recalculate the user's credit; the OCS provides the recalculated user credit to the TPF.
  • Step 506 can also be performed at any time between steps 501 and 505. As long as the TPF determines that the currently occurring bearer event matches the re-authentication event, the next step 508 triggers the re-authentication process to further provide the OCS. The currently occurring bearer event is used to notify the OCS of the re-authentication event currently occurring.
  • FIG. 6 shows a process message interaction diagram of a trigger event and a re-authentication event in the present invention.
  • the message interaction process in the process of triggering event and re-authentication event processing includes the following steps:
  • Step 601 is the same as step 301.
  • Step 602 After receiving the bearer modification request, the TPF matches the currently occurring bearer modification event with the pre-stored trigger event. If yes, go to step 603; otherwise, go to step 608.
  • the specific implementation process is as follows:
  • the TPF sends a charging rule request to the CRF.
  • the charging rule request carries the charging rule input information, such as the information of the UE, the bearer attribute, and
  • the CRF selects the appropriate charging rule based on the received revenue information.
  • the CRF can further determine the triggering event that needs to be monitored by the TPF according to the input information provided by the TPF, and then send the charging rule and the triggering event to the CRF. TPF.
  • the CRF can also provide the TPF with a trigger that requires it to be monitored.
  • the TPF reports the trigger event to the CRF.
  • the CRF can continue to send a new trigger event to the TPF.
  • the CRF receives the input information provided by the external entity, such as the AF and the 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.
  • 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 OCS can provide the TPF with a re-authentication event that requires it to be monitored. For example, in the authentication process, the TPF sends a credit request to the OCS. After receiving the credit request, the OCS calculates the credit of the user and returns it to the TPF. The returned credit response carries the user credit, and may further carry the weight of the woman. The event requires the TPF to monitor the re-authentication event provided. When the re-authentication event occurs, the re-authentication process is triggered, and the current re-authentication event is reported to the OCS. The OCS can also send re-authentication events to the TPF through the CRF.
  • the TPF reports the re-authentication event that is currently occurring to the OCS. After receiving the re-authentication event reported by the TPF, the OCS can continue to send a new re-authentication event to the TPF.
  • Step 603 The TPF sends a charging rule request to the CRF, where the charging rule request carries the input information for the CRF to determine the charging rule, where the charging rule request may further carry the currently occurring bearer related event, to notify The CR triggers a trigger event for the current charging rule request process.
  • Steps 604 to 606 are the same as steps 304 to 306.
  • Step 607 The TPF determines whether the charging rule provided by the CRF changes. If the charging rule changes, it continues to determine whether the change of the charging rule needs to trigger the re-authentication process. If yes, proceed to step 608; If there is no change or the change of the charging rule does not need to trigger the re-authentication process, step 608 is performed.
  • Step 608 The TPF matches the currently occurring bearer modification event with the pre-stored re-authentication event. If yes, step 609 is performed; otherwise, the TPF continues to determine whether it is determined in step 607 whether the re-authentication process needs to be triggered. If necessary, step 609 is performed. If not, step 611 is directly performed.
  • Step 609 The TPF sends a credit request (Credit Request) to the OCS, where the credit request carries the user's remaining credit and related charging rule information, and requests the OCS to recalculate the user's credit. If it is determined in step 607 that the re-authentication process needs to be triggered, the credit request sent by the TPF to the OCS may further carry the modified charging rule information. In addition, if it is determined in step 608 that the re-authentication process needs to be triggered, the bearer information modified in the bearer modification event may be further provided in the credit request message sent by the TPF to the OCS.
  • Step 610 After receiving the credit request, the OCS recalculates the credit of the user, and then returns a credit response (Credit Answer) 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.
  • Step 611 The TPF returns a bearer modification response to the UE, and determines whether to accept the bearer modification request initiated by the UE according to the foregoing processing result. If yes, the subsequent bearer modification process is continued; otherwise, the UE initiated bearer modification request is rejected, for example, if the credit If the response carries the user's credit, the TPF accepts the bearer modification request initiated by the UE, and continues the subsequent bearer modification process. If the credit response does not carry the user's credit, the UE initiates the bearer modification request.
  • step 607 when the TPF determines that the charging rule changes, and the charging rule change event needs to trigger the re-authentication process, step 609 may be directly performed, and step 608 is not performed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Meter Arrangements (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Coin-Freed Apparatuses For Hiring Articles (AREA)
  • Secondary Cells (AREA)
  • Charge And Discharge Circuits For Batteries Or The Like (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 )参数、 事务标识（ Ή, 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指定的分组数据业务所要达到的质量要求； Ή用于 MS标识某个 PDP context
步骤 102: SGSN收到 Activate PDP Context Request后， 与 MS进行 安全性检查和加密， 该步骤为可选步驟。
步骤 103: SGSN根据 APN解析 GGSN的地址信息， 如果 SGSN能 够根据 APN解析出 GGSN的地址信息， 则为 PDP Context创建 TEID , 该 TEID可为国际移动用户标识（ IMSI, 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配置选项等 信息。 并且， SG.SN启动计费。 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 互通， CRF 203 通过 Rx接口与应用功能实体（AF, Application Function ) 204互通， CRF 203通过 Gx接口与传输面功能实 体（ TPF, Traffic Plane Function ) 205互通， CCF 202通过 Gy接口与 TPF 205互通。
支持离线计费的 FBC系统结构如图 2B所示， CRJF 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 )等。 另外， 由于在 IP数据流传输过程 ， 会对承载进行修 改， 如对 QoS参数进行重新协商， 当用户使用同一业务的 QoS参数不 同时， 计费规则可能不同， 如 QoS参数下降相应的费率也下降。 此时， TPF 205可在承载修改时， 重新向 CRF 203发送计费规则请求， 请求新 的计费规则； CRF 203根据 TPF 205提供的上述输入信息选择适当的计 费规则，并向 TPF 205返回选定的计费规则，计费规则中包括计费机制、 计费类型、 计费键、 业务数据流过滤器、 计费规则优先级等信息。 其中， 计费机制可为采用在线计费还是离线计费； 计费类型可为基于时间长度 进行计费还是基于数据流量进行计费；计费键是与费率相关的参数, 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请求新的计 费规则。 触发事件可视为与计费规则相关的事件。
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根据用户当前所在位置确定 费率， 并根据该费率计算用户的信用； 当用户移动至另一位置时， 如 SGSN发生变化， TPF 205需要根据重鉴权事件中的 SGSN变化事件， 向 OCS 206上报 SGSN变化事件的发生， OCS 206根据用户更新后的当 前所在位置重新确定费率，并重新计算用户的信用。又例如，当 OCS 206 根据用户使用业务的当前 QoS参数确定费率， 当用户对 QoS参数进行 修改， TPF 205需要根据重鉴权事件中的承载修改事件， 向 OCS 206上 报承载修改事件的发生， OCS 206根据用户修改后的 QoS参数确定费率， 并重新计算用户的信用。
对应于 GPRS网縿， TPF 205为 GGSN, AF为 PDN中的一个业务 网关或业务服务器， CRF 203为新增的逻辑实体。 TPF 205为计费规则 的执行点， CRF 203为计费规则的控制点。
目前， 3GPP 定义了承载修改时， 在线计费情况下， 触发事件的发 生会触发计费规则请求流程， 即 TPF向 CRF请求计费规则， 触发事件 触发的 TPF向 CRF请求计费规则的处理过程如图 3所示：
步骤 301：用户设备（ UE )向 TPF发送承载修改请求（ Modify Bearer Service Request ), 在 GPRS网络中， 则是 GGSN收到 PDP Context更新 请求（ Update PDP Context Request )。
步骤 302: TPF收到承载修改请求后， 将承载修改事件与预先存储 的触发事件相匹配， 如果能够匹配， 则执行步骤 303; 否则， 继续监测 触发事件的发生。
步骤 303: TPF向 CRF发送计费规则请求（ Request Charging Rules ), 该计费规则请求中携带有供 CRF确定计费规则的输入信息。
步骤 304〜步骤 305： CRF收到计费规则请求后， 根据该计费规则请 求中携带的输入信息， 还可根据 AF提供的相关输入信息， 选择适当的 计费规则， 然后向 TPF返回提供计费规则 （ Provision Charging Rules ), 该提供计费规则中可携带有选定的计费规则和计费规则操作指示。
步骤 306: TPF收到提供计费规则后，根据计费规则操作指示对 CRJF 选定的计费规则进行相应操作。
步驟 307: TPF 向 UE返回承载修改响应 （Modify Bearer Service Accept )， 并继续后续的承载修改流程。
对于在线计费情况下， 承载修改会触发重鉴权流程， 即 TPF请求 OCS对用户进行重鉴权的流程， 具体实现过程如图 4所示：
步驟 401 : UE向 TPF发送承载修改请求（Modify Bearer Service Request ), 在 GPRS 网络中， 则是 GGSN收到 PDP Context更新请求 ( Update PDP Context Request )。 步骤 402: TPF收到承载修改请求后， 将承载修改事件与预先存储 的重鉴权事件进行匹配， 如果能够匹配， 则执行步骤 403， 否则， 继续 监测重鉴权事件的发生。
步骤 403: TPF向 OCS发送信用控制请求（ Credit Control Request ), 该信用控制请求中携带有用户的剩余信用和相关的计费规则信息， 请求 OCS重新计算用户的信用。 TPF向 OCS提供的相关计费规则信息可来 自 CRF。
步骤 404: OCS收到信用控制请求后， 重新对用户的信用进行计算， 然后向 TPF返回信用控制响应（ Credit Control Answer ), 如果 OCS计算 出用户的信用， 则该信用控制响应中携带有 OCS重新计算的用户信用， 如果 OCS未计算出用户的信用，则该信用控制响应中可携带有差错原因 值。
步骤 405: TPF 收到信用控制响应后， 向 UE返回承载修改响应 ( Modify Bearer Service Accept )， 如果信用控制响应中携带有用户的信 用 ,则 TPF接受 UE发起的承载修改请求，并继续后续的承载修改流程； 如果信用控制响应中未携带有用户的信用， 则拒绝 UE发起的承载修改 请求。
目前， 规范中对 CRF通过触发事件上报机制控制 TPF的计费方式 进行了描述，即 TPF监测到触发事件发生后向 CRF上报， CRF通过 TPF 上报的触发事件获知承载发生变化， 然后确定相应的计费规则并下发给 TPF。规范中定义的触发事件可包括： SGSN变化（SGSN change )事件， QoS参数变化（ QoS changes )事件，无线接入技术（ RAT )类型变化（ RAT type change )事件， 传输流模板（TFT ) 变化（TFT change )事件。
另外， 规范中还对 OCS通过重鉴权事件上报的机制控制 TPF的信 用使用情况进行了描述， 即 TPF监测到重鉴权事件发生后向 OCS上报， OCS通过 TPF上报的重鉴权事件，获知用户的信用使用情况以及承载的 变化， 对用户的信用重新进行计算并下发给 TPF。 规范中定义的重鉴权 事件可包括： 允许信用过期 （ credit authorization lifetime expiry )事件， 用户空闲状态超时（ idle timeout )事件， 计费规则变化（ charging rule is changed ) 事件， 还可包括一些 GPRS事件， 如 SGSN变化事件， QoS 参数变化事件， RAT类型变化事件。
通过以上描述可见， 触发事件和重鉴权事件中都包括 GPRS事件， 如 SGSN变化事件、 QoS参数变化事件、 RAT类型变化事件等， 这样， 对于某个发生的 GPRS事件， TPF会将该 GPRS事件同时匹配到触发事 件和重鉴权事件， 因此， 需要分别向 CRF和 OCS上报该 GPRS事件的 发生。
如果 TPF先向 OCS上报重鉴权事件，然后再向 CRF上报触发事件， 由于 CRF可能根据收到的触发事件选择新的计费规则， 并向 TPF下发 选定的新计费规则， 此时， CRF向 TPF下发的新计费规则可能会与重鉴 权事件中的计费规则变化事件相匹配， 而导致再次触发重鉴权流程， 使 得第一次的重鉴权处理成为冗余的处理过程，对 FBC系统中 TPF与 OCS 之间的接口资源造成浪费。 发明内容
有鉴于此， 本发明的目的在于提供一种基于分组数据流计费触发事 件和重鉴权事件的处理方法， 完善基于分组数据流计费的重鉴权流程。
为了达到上述目的， 本发明提供了一种基于分组数据流计费触发事 件和重鉴权事件的处理方法， 该方法包含以下步骤：
A、 TPF判断当前发生的承载事件是否与触发事件相匹配， 如果是， 则执行步驟 B, 否则， 直接执行步骤 C; B、 TPF触发计费规则请求流程；
C、 TPF 判断是否需要触发重鉴权流程， 如果是， 则触发重鉴权流 程， 否则， 结束当前流程。
所述步驟 B包括： TPF向 CRF请求计费规则， CRF向 TPF返回选 定的计费规则。
所述步骤 B进一步包括： TPF向 CRF提供当前发生的承载事件。 如果 TPF判断出当前发生的承载事件与触发事件相匹配， 则步骤 C 中所述判断是否需要触发重鉴权流程为：判断 CRJF提供的计费规则是否 变化， 如果是， 则触发重鉴权流程； 否则， 结束当前流程。
步骤 C中所述触发重鉴权流程之前， 进一步包括： 判断计费规则的 变化是否需要触发重鉴权流程， 如果是， 触发重鉴权流程； 否则， 结束 当前流程。
步骤 C中所述触发重鉴权流程之前， 进一步包括： TPF判断当前发 生的承载事件是否与重鉴权事件相匹配， 如果是， 则触发重鉴权流程， 并进一步向 OCS提供当前发生的承载事件； 否则， 仅触发重鉴权流程。
所述触发重鉴权流程进一步包括： TPF向 OCS提供变化的计费规则。 如果 TPF判断出当前发生的承载事件未与触发事件相匹配， 则步骤 C中所述判断是否需要触发重鉴权流程为： 判断当前发生的承载事件是 否与重鉴权事件相匹配， 如果是， 则触发重鉴权流程； 否则， 结束当前 流程。
所述触发重鉴权流程进一步包括： TPF向 OCS提供当前发生的承载 事件。
所述触发重鉴权流程包括： TPF向 OCS请求用户信用， OCS向 TPF 返回重新计算的用户信用。
所述触发事件由 CRF提供给 TPF。 所述重鉴权事件由 OCS提供给 TPF, 或由 OCS通过 CRF提供给 根据本发明提出的方法， 当承载事件发生时， TPF首先判断发生的 承载事件是否与触发事件相匹配，如果匹配，则向 CRF上报发生的触发 事件； 然后再判断发生的承载事件是否与重鉴权事件相匹配，如果匹配， 则向 OCS 上报发生的重鉴权事件， 继续后续重鉴权流程。 这样， TPF 与 OCS之间仅需要进行一次重鉴权的交互，优化了触发事件和重鉴权事 件重叠时的重鉴权流程， 完善了基于分组数据流计费的重鉴权流程。 附图简要说明
图 1示出了 PDP Context激活、 数据传输、 去激活流程图； 图 2A示出了支持在线计费的 FBC系统结构图；
图 2B示出了支持离线计费的 FBC系统结构图；
图 3示出了现有技术中触发事件触发 TPF向 CRF请求计费规则流 程图；
图 4示出了现有技术中重鉴权事件触发 TPF请求 OCS进行重鉴权 流程图；
图 5示出了本发明中触发事件和重鉴权事件的处理流程图； · 图 6示出了本发明中触发事件和重鉴权事件的处理过程消息交互示 意图。 实施本发明的方式
为使本发明的目的、 技术方案和优点更加清楚， 下面结合附图对本 发明作进一步的详细描述。
本发明中， 当承载事件发生时， TPF首先判断发生的承载事件是否 与触发事件相匹配， 如果匹配， 则向 CRF上报发生的触发事件； 然后再 判断发生的承载事件是否与重鉴权事件相匹配， 如果匹配， 则向 OCS 上报发生的重鉴权事件， 继续后续重鉴权流程。 这样， TPF与 OCS之间 仅需要进行一次重鉴权的交互， 优化了触发事件和重鉴权事件重叠时的 重鉴权流程。
图 5示出了本发明中触发事件和重鉴权事件的处理流程图， 如图 5 所示， 触发事件和重鉴权事件的处理过程包括以下步骤：
步骤 501〜步骤 502: TPF监测到承载事件的发生， 判断发生的承载 事件是否与触发事件相匹配， 如果是， 则执行步骤 503; 否则， 执行步 驟 507。
步骤 503: TPF触发计费规则请求流程， 即 TPF向 CRF提供选择计 费规则的输入信息，并进一步向 CRF提供当前发生的承载事件，用以通 知 CRF当前触发计费规则请求流程的触发事件， 请求 CRF提供计费规 则； CRF接收到计费规则请求后， 根据提供输入信息以及承载事件选择 计费规则， 向 TPF提供选定的计费规则和计费规则操作指示。 TPF收到, 提供计费规则后，根据计费规则操作指示对 CRF选定的计费规则进行相 应操作。
步骤 504: TPF判断 CRF提供的计费规则是否变化， 如果是， 则执 行步骤 505; 否则， 执行步骤 507。
步骤 505: TPF判断计费规则的变化是否需要触发重鉴权流程， 如 果是， 则执行步骤 506; 否则， 执行步骤 507。
步骤 506: TPF判断当前发生的承载事件是否与重鉴权事件相匹配， 如果是， 则执行步骤 508; 否则， 执行步骤 509。
步骤 507: TPF判断当前发生的承载事件是否与重鉴权事件相匹配， 如果是， 则执行步骤 508; 否则， 结束当前流程。 步骤 508: TPF触发重鉴权流程， 即 TPF向 OCS提供用户的剩余信 用和相关的计费规则信息，请求 OCS重新计算用户的信用，并进一步向 OCS提供当前发生的承载事件, 用以通知 OCS 当前触发重鉴权流程的 重鉴权事件； OCS向 TPF提供重新计算的用户信用，然后结束当前流程。
步骤 509: TPF触发重鉴权流程， 即 TPF向 OCS提供用户的剩余信 用和相关的计费规则信息，请求 OCS重新计算用户的信用； OCS向 TPF 提供重新计算的用户信用。
步骤 506也可在步骤 501〜步骤 505之间的任意时刻进行， 只要 TPF 判断出当前发生的承载事件与重鉴权事件相匹配， 则在后续步骤 508触 发重鉴权流程时， 进一步向 OCS提供当前发生的承载事件， 用以通知 OCS当前发生的重鉴权事件。
图 6示出了本发明中触发事件和重鉴权事件的处理过程消息交互示 意图， 如图 6所示， 触发事件和重鉴权事件处理过程中的消息交互过程 包括以下步骤：
步骤 601与步骤 301相同。
步骤 602: TPF收到承载修改请求后， 将当前发生的承载修改事件 与预先存储的触发事件相匹配， 如果能够匹配， 则执行步骤 603; 否贝' J , 直接执行步驟 608。
承载建立时， 具体实现过程如下： 在线计费情况下， 承载建立时， TPF向 CRF发送计费规则请求，该计费规则请求中携带有计费规则输入 信息， 如 UE的信息、 承载属性、 网络信息等， CRF根据收到的收入信 息选择适当的计费规则， 另外， CRF根据 TPF提供的输入信息， 可进一 步确定需要 TPF进行监测的触发事件，然后将计费规则和触发事件下发 给 TPF。
另外， 承载修改时， CRF也可向 TPF提供要求其进行监测的触发事 件， 即当触发事件发生时， TPF向 CRF上报发生的触发事件； CRF收 到 TPF上报的触发事件后， 可继续向 TPF下发新的触发事件。 当 CRF 接收到外部实体， 如 AF、 OCS提供的输入信息后， 也可向 TPF提供要 求其进行监控的触发事件， 即 CRF可主动地向 TPF下发触发事件。
TPF收到 CRF提供的计费规则和触发事件后，对触发事件的发生进 行监测， 并根据计费规则中的过滤器（Filter )过滤出相应的 IP数据流， 然后应用相应计费规则对过滤出的 IP数据流进行计费。
OCS可直接向 TPF提供要求其进行监测的重鉴权事件。如在鉴权流 程中， TPF向 OCS发送信用请求， OCS接收到信用请求后， 对用户的 信用进行计算并向 TPF返回， 返回的信用响应中除携带有用户信用， 可 进一步携带有重婆权事件， 要求 TPF对提供的重鉴权事件进行监测， 当 重鉴权事件发生时触发重鉴权流程， 向 OCS 上报当前发生的重鉴权事 件。 OCS也可通过 CRF向 TPF下发重鉴权事件。
另外， 当重鉴权事件发生时， TPF向 OCS上报当前发生的重鉴权事 件； OCS收到 TPF上报的重鉴权事件后， 可继续向 TPF下发新的重鉴 权事件。
步骤 603: TPF向 CRF发送计费规则请求， 该计费规则请求中携带 有供 CRF确定计费规则的输入信息，该计费规则请求中可进一步携带有 当前发生的承载相关事件，用以通知 CR 触发当前计费规则请求流程的 触发事件。
步骤 604〜步骤 606与步驟 304~步骤 306相同。
步骤 607: TPF判断 CRF提供的计费规则是否变化， 如果计费规则 变化， 则继续判断计费规则的变化是否需要触发重鉴权流程， 如果是， 则可继续执行步驟 608; 如果计费规则未变化或计费规则的变化无需触 发重鉴权流程， 则执行步骤 608。 步骤 608: TPF将当前发生的承载修改事件与预先存储的重鉴权事 件相匹配， 如果能够匹配， 则执行步骤 609; 否则， TPF继续判断在步 骤 607中是否决定需要触发重鉴权流程， 如果需要， 则执行步骤 609, 如果不需要， 则直接执行步骤 611。
步骤 609: TPF向 OCS发送信用请求（Credit Request ), 该信用请 求中携带有用户的剩余信用和相关的计费规则信息 ,请求 OCS重新计算 用户的信用。如果在步骤 607中决定需要触发重鉴权流程时， TPF向 OCS 发送的信用请求中可进一步携带有修改的计费规则信息。 另外， 如果在 步骤 608中决定需要触发重鉴权流程时， TPF向 OCS发送的信用请求消 息中可进一步提供承载修改事件中修改的承载信息。
步驟 610: OCS收到信用请求后， 重新对用户的信用进行计算， 然 后向 TPF返回信用响应（ Credit Answer ),如果 OCS计算出用户的信用， 则该信用响应中携带有 OCS重新计算的用户信用， 如果 OCS未计算出 用户的信用， 则该信用响应中可携带有差错原因值。
步骤 611: TPF向 UE返回承载修改响应，根据以上处理结果确定是 否接受 UE发起的承载修改请求， 如果接受， 则继续后续的承载修改流 程； 否则， 拒绝 UE发起的承载修改请求， 例如， 如果信用响应中携带 有用户的信用， 则 TPF接受 UE发起的承载修改请求， 并继续后续的承 载修改流程； 如果信用响应中未携带有用户的信用， 则拒绝 UE发起的 承载修改请求。
上述流程中， 步骤 607当 TPF判断出计费规则发生变化， 并且计费 规则发生变化事件需要触发重鉴权流程时， 则可直接执行步骤 609， 不 再执行步骤 608。
总之， 以上所述仅为本发明的较佳实施例而已， 并非用于限定本发 明的保护范围。

Claims

权利要求书
1、一种基于分组数据流计费触发事件和重鉴权事件的处理方法，其 特征在于， 该方法包含以下步骤:
A、 TPF判断当前发生的承载事件是否与触发事件相匹配， 如果是， 则执行步骤 B, 否则， 直接执行步骤 C;
B、 TPF触发计费规则请求流程；
C、 TPF 判断是否需要触发重鉴权流程， 如果是， 则触发重鉴权流 程， 否则， 结束当前流程。
2、 根据权利要求 1所述的方法， 其特征在于， 所述步骤 B包括： TPF向 CRF请求计费规则， CRF向 TPF返回选定的计费规则。
3、 根据权利要求 2所述的方法， 其特征在于， 所述步骤 B进一步 包括： TPF向 CRF提供当前发生的承载事件。
4、 根据权利要求 2所述的方法， 其特征在于， 如果 TPF判断出当 前发生的承载事件与触发事件相匹配，则步骤 C中所述判断是否需要触 发重鉴权流程为： 判断 CRJF提供的计费规则是否变化， 如果是， 则触发 重鉴权流程； 否则， 结束当前流程。
5、 根据权利要求 4所述的方法， 其特征在于， 步骤 C中所述触发 重鉴权流程之前， 进一步包括： 判断计费规则的变化是否需要触发重鉴 权流程， 如果是， 触发重鉴权流程； 否则， 结束当前流程。
6、 根据权利要求 4所述的方法， 其特征在于， 步骤 C中所述触发 重答权流程之前， 进一步包括： TPF判断当前发生的承载事件是否与重 鉴权事件相匹配， 如果是， 则触发重鉴权流程， 并进一步向 OCS提供当 前发生的承载事件； 否则， 仅触发重鉴权流程。
7、根据权利要求 4所述的方法， 其特征在于， 所述触发重鉴权流程 进一步包括： TPF向 OCS提供变化的计费规则。
8、 根据权利要求 1所述的方法， 其特征在于， 如果 TPF判断出当 前发生的承载事件未与触发事件相匹配， 则步骤 C中所述判断是否需要 触发重鉴权流程为： 判断当前发生的承载事件是否与重鉴权事件相匹 配， 如果是， 则触发重鉴权流程； 否则， 结束当前流程。
9、根据权利要求 8所述的方法， 其特征在于， 所述触发重鉴权流程 进一步包括： TPF向 OCS提供当前发生的承载事件。
10、 根据权利要求 1所述的方法， 其特征在于， 所述触发重鉴权流 程包括： TPF向 OCS请求用户信用， OCS向 TPF返回重新计算的用户 信用。
11、根据权利要求 1所述的方法，其特征在于，所述触发事件由 CRF 提供给 TPF。
12、 ^^据权利要求 1所述的方法， 其特征在于， 所述重鉴权事件由 OCS提供给 TPF, 或由 OCS通过 CRF提供给 TPF。
PCT/CN2005/001238 2004-08-11 2005-08-11 Methode de traitement fondee sur un evenement de declenchement de chargement et sur un evenement de reautorisation de flux de donnees de paquets WO2006015548A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE200560006094 DE602005006094T2 (de) 2004-08-11 2005-08-11 Verarbeitungsverfahren auf der basis eines charging-trigger-ereignisses und eines neuauthorisationsereignisses eines paketdatenflusses
EP20050772490 EP1693984B1 (en) 2004-08-11 2005-08-11 A processing method based on charging trigger event and re-authorisation event of packet data flow
JP2007501099A JP4402714B2 (ja) 2004-08-11 2005-08-11 フローベース課金におけるイベント・トリガと再認証トリガを取り扱う方法
US10/563,023 US20080320564A1 (en) 2004-08-11 2005-08-11 Method for Handling Event Triggers and Re-Authorization Triggers in Flow Based Charging
CA 2540922 CA2540922C (en) 2004-08-11 2005-08-11 A method for handling event triggers and re-authorization triggers in flow based charging

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200410059148.9 2004-08-11
CNB2004100591489A CN1260910C (zh) 2004-08-11 2004-08-11 基于分组数据流计费触发事件和重授权事件的处理方法

Publications (1)

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

Family

ID=34868765

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/001238 WO2006015548A1 (fr) 2004-08-11 2005-08-11 Methode de traitement fondee sur un evenement de declenchement de chargement et sur un evenement de reautorisation de flux de donnees de paquets

Country Status (8)

Country Link
US (1) US20080320564A1 (zh)
EP (1) EP1693984B1 (zh)
JP (1) JP4402714B2 (zh)
CN (1) CN1260910C (zh)
AT (1) ATE392768T1 (zh)
CA (1) CA2540922C (zh)
DE (1) DE602005006094T2 (zh)
WO (1) WO2006015548A1 (zh)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1303781C (zh) * 2004-04-01 2007-03-07 华为技术有限公司 一种分组数据业务的计费控制方法
CN100397821C (zh) * 2005-01-20 2008-06-25 华为技术有限公司 一种基于分组数据流计费中的处理方法
US7764623B2 (en) * 2005-02-01 2010-07-27 Telefonaktiebolaget L M Ericsson (Publ) Automatic quality of service class management
CN101087248B (zh) * 2006-06-23 2010-08-18 中兴通讯股份有限公司 基于会话业务的网络侧发起承载建立的方法
CN101296094B (zh) * 2007-04-26 2011-02-16 华为技术有限公司 检测承载事件的方法、系统和装置
CN101374055B (zh) * 2007-08-20 2012-12-12 华为技术有限公司 计费处理方法和网络系统、分组数据网络网关及计费系统
CN101453380B (zh) * 2007-11-28 2011-08-24 华为技术有限公司 应用事件检测的方法、系统以及分组流优化功能实体
CN101499911B (zh) 2008-02-03 2013-02-06 华为技术有限公司 计费系统、装置和方法
CN101583152B (zh) * 2008-05-15 2011-08-24 华为技术有限公司 一种信息传递方法、装置和系统
US20100284284A1 (en) * 2009-05-08 2010-11-11 Qualcomm Incorporated VOICE OVER INTERNET PROTOCOL (VoIP) ACCESS TERMINAL
CN102638355A (zh) * 2011-02-14 2012-08-15 阿尔卡特朗讯 基于网络资源使用信息确定策略计费规则的方法和装置
WO2013139004A1 (zh) 2012-03-21 2013-09-26 华为技术有限公司 一种建立演进分组系统承载的方法及基站
CN103402178B (zh) * 2013-08-06 2019-05-31 百度在线网络技术（北京）有限公司 数据流量的控制方法、装置和移动终端
US20160198049A1 (en) * 2013-08-12 2016-07-07 Nec Corporation Wireless communication system and method for charging control
US20170163431A1 (en) * 2014-06-06 2017-06-08 Telefonaktiebolaget Lm Ericsson (Publ) Notification of Network Events Relevant for Policy and Charging Decisions
KR20180099930A (ko) * 2014-10-28 2018-09-05 콘비다 와이어리스, 엘엘씨 기본 네트워크들과의 서비스 계층 과금 상관을 위한 방법들 및 장치들

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07336464A (ja) * 1994-06-08 1995-12-22 Fujitsu Ltd 通信サービス制御装置
US20030153333A1 (en) * 2001-05-14 2003-08-14 Ryo Shirai Obile communication service charging apparatus and mobile communication service charging method
CN1450749A (zh) * 2002-04-10 2003-10-22 华为技术有限公司 一种分组数据业务的计费方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8699472B2 (en) * 2000-05-24 2014-04-15 Nokia Corporation Common charging identifier for communication networks
EP1223737A1 (en) * 2001-01-15 2002-07-17 Lucent Technologies Inc. Providing prepaid service to a GPRS mobile station when roaming
US6954631B2 (en) * 2003-02-13 2005-10-11 Hewlett-Packard Development Company, L.P. Apparatus and method for telecommunications services
US7720960B2 (en) * 2003-03-04 2010-05-18 Cisco Technology, Inc. Method and apparatus providing prepaid billing for network services using explicit service authorization in an access server
US7721296B2 (en) * 2003-06-13 2010-05-18 Ericsson Ab Event based charging in a communications system
GB0329502D0 (en) * 2003-12-19 2004-01-28 Nokia Corp Control decisions in a communication system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07336464A (ja) * 1994-06-08 1995-12-22 Fujitsu Ltd 通信サービス制御装置
US20030153333A1 (en) * 2001-05-14 2003-08-14 Ryo Shirai Obile communication service charging apparatus and mobile communication service charging method
CN1450749A (zh) * 2002-04-10 2003-10-22 华为技术有限公司 一种分组数据业务的计费方法

Also Published As

Publication number Publication date
CN1645806A (zh) 2005-07-27
JP2007535833A (ja) 2007-12-06
EP1693984A1 (en) 2006-08-23
US20080320564A1 (en) 2008-12-25
CN1260910C (zh) 2006-06-21
EP1693984B1 (en) 2008-04-16
EP1693984A4 (en) 2006-12-06
CA2540922A1 (en) 2006-02-16
DE602005006094T2 (de) 2009-05-20
ATE392768T1 (de) 2008-05-15
JP4402714B2 (ja) 2010-01-20
CA2540922C (en) 2010-06-22
DE602005006094D1 (de) 2008-05-29

Similar Documents

Publication Publication Date Title
WO2006015548A1 (fr) Methode de traitement fondee sur un evenement de declenchement de chargement et sur un evenement de reautorisation de flux de donnees de paquets
US8798575B2 (en) Method for improving service data flow based charging and system thereof
US7889650B2 (en) Method for establishing diameter session for packet flow based charging
EP1804419B1 (en) A method for processing the re-authorisation based on the charging of the packet data flow
WO2006047965A1 (fr) Procede de traitement de facturation en ligne
WO2005096547A1 (fr) Procede permettant de commander la facturation d'un service de commutation de paquets
JP4891223B2 (ja) パケットデータサービスの課金ルールを強化する方法及びその機能する方法
WO2007143940A1 (fr) procédé, système et équipement de contrôle des conditions d'utilisation et de la facturation lorsque l'utilisateur est mobile
WO2010108356A1 (zh) 一种终端通过多接入网接入的计费方法和系统及上报方法
WO2005109748A1 (fr) Procede de selection de la regle de taxation destine a des utilisateurs
WO2011029289A1 (zh) 漫游场景下承载控制模式的发送方法和系统
WO2006050669A1 (fr) Procede de chargement en fonction d'un flux de paquets de donnees
WO2013060170A1 (zh) 一种提供基于lipa承载的计费支持的方法及装置
WO2014094488A1 (zh) 漫游本地业务的计费策略方法及装置
WO2014107985A1 (zh) 漫游本地业务的在线计费方法、h-ocs及v-ocs
WO2005101734A1 (fr) Procede de facturation de services de donnees par paquets et de controle d'acces de flux de donnees de services
WO2010118673A1 (zh) 策略和计费控制的处理方法、系统及设备
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
WO2018228215A1 (zh) 无线通信的方法和设备
WO2013113263A1 (zh) 一种应用检测控制功能模式的识别方法及系统
WO2011127666A1 (zh) 计费处理方法、计费处理装置和计费处理系统
WO2006050670A1 (fr) Procede de traitement de cle de taxation
WO2014079323A1 (zh) 一种漫游本地业务功能实现方法、装置和系统
WO2012041148A1 (zh) 一种用量监测方法及系统

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2540922

Country of ref document: CA

Ref document number: 2005772490

Country of ref document: EP

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
WWP Wipo information: published in national office

Ref document number: 2005772490

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007501099

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 10563023

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 2005772490

Country of ref document: EP