Patent Application
20070165803
The present invention relates to packet data charging techniques, more particularly to a method for handling re-authorization in packet data flow based charging.
With the wide application of packet data service, how to charge packet data service accurately and reasonably has become a common concern of operators.
In the existing General Packet Radio Service (GPRS) charging system, it is totally impossible to perform separate charging with the existing GPRS charging system for different services the same Packet Data Protocol Context (PDP Context) bears. In view of the above, it is being discussed in the 3rd Generation Partnership Project (3 GPP) as to how to implement Internet Protocol (IP) Flow Based Charging (FBC). compared with the charging based on one PDP Context, charging based on IP Flow can provide more charging approaches for operators or service providers. In 3 GPP, aspects of FBC like system architecture, function requirement and flow of interactive messages are described. FBC system architecture supporting online charging is shown in
FBC system architecture supporting offline charging is shown in
TPF 205 bears IP Flow, and when the IP Flow bearer is established, TPF 205 sends a Charging Rule Request to CRF 203 through the Gx interface, the Charging Rule Request thereof carries relevant information of subscriber and UE, bearer characteristics, network information, and so on, where the relevant information of subscriber and UE can be Mobile Station ISDN (MSISDN), International Mobile Subscriber Identity (IMSI) etc. In addition, since the bearer may be modified during IP Flow transmission, for example, re-conferring on QoS parameters when QoS parameters of the same service are different, charging rules may differ accordingly and charging rate will decrease as QoS parameters decrease. In this case, when the bearer is modified, TPF 205 can resend a Charging Rule Request to CRF 203 to request for new charging rules; CRF 203 selects a proper charging rule according to the input information provided by TPF 205 and then returns the selected charging rule to TPF 205, the charging rule thereof includes information of charging mechanism, charging type, charging key, Service Data Flow Filter, and charging rule priority. The charging mechanism can be online charging or offline charging; the charging type can be charging based on time span or data flow; the charging key is a parameter related with charging rate, and CRF 203 may provide only parameters related with charging rate for TPF 205, rather than directly provide charging rate for TPF 205; the Service Data Flow Filter is used to instruct TPF 205 which IP Flows are to be filtered, then TPF 205 charges these filtered IP Flows according to the charging rules. Service Data Flow Filter can include IP quintuple, which can include such information as Source/Destination IP Address, Source/Destination Port Number, and Protocol ID. For instance, CRF 203 instructs TPF 205 to filter the IP Flow with the Source IP Address 10.0.0.1, Destination IP Address 10.0.0.2, Source/Destination Port Number 20 and the protocol type Transmission Control Protocol (TCP), then charges the filtered IP Flow according to the charging rule.
CRF 203 can provide TPF 205 with event triggers so as to make TPF 205 request CRF 203 for new charging rules when specific events occur, for example, CRF 203 may make TPF 205 request for new charging rules when some events of bearer modification occur.
CRF 203 can determine the appropriate charging rule according to the input information of AF 204 or OCS 20 apart from the input information of TPF 205, for example, AF 204 may notify CRF 203 of the current service type used by the subscribers, and CRF 203 will select the corresponding charging rule according to this service type.
OCS 206 consists of two functions, SCP 201 and CCF 202, wherein, CCF 202 is the function implementing credit control and only used in the on-line charging system, which may be completed by adding new functions to the existing OCS 206. In the process of on-line charging, CCF 202 conducts management and control on the credits, when the user uses the service, CCF 202 makes authentication of the credits in the user's credit pool, and issues the credits available to the user to TPF 205 via interface Gy.
In addition, OCS 206 may require TPF 205 to submit reports when re-authorization triggers occur, then OCS 206 will re-authorize the credit based on the corresponding re-authorization triggers reported by TPF 205 and may possibly re-calculate the credit. For example, when the credit provided for TPF 205 by OCS 206 have been used up, TPF 205, according to the credit authorization lifetime expiry event in the re-authorization triggers, needs to report to OCS 206 the occurrence of the credit authorization lifetime expiry event; OCS 206 re-calculates the credits available to the user For another example, when performing location-specific charging, OCS 206 determines the charging rate according to the current location of the user and calculates the credit based on this rate; when the user moves to another location, if SGSN changes, TPF 205, according to the event of SGSN change in the re-authorization triggers, reports to OCS 206 the occurrence of the event of SGSN change, and re-determines the charging rate based on the updated current location of the user and recalculates the credit. For another example, OCS determines the charging rate based on the current QoS parameter of the service used by the user, when the user modifies the QoS parameter, TPF, according to the QoS change event in the re-authorization triggers, needs to report to OCS 206 the occurrence of the QoS change event, OCS 206 then determines the charging rate based on the modified QoS parameter and re-calculates the credit. The re-authorization triggers defined in the specifications may include credit authorization lifetime expiry event, idle timeout event, charging rule is changed event, as well as some GPRS events, such as SGSN change event, QoS change event, and Radio Access Technique (RAT) type change event.
For a GPRS network, TPF 205 is GGSN, AF is a service gateway or service server in PDN, CRF 203 is an added logical entity. TPF 205 is the executing point of charging rules and CRF 203 is the control point of charging rules.
3 GPP has defined the implementing procedure TPF requesting a charging rule from CRF under on-line charging circumstances when a bearer is established, as shown in
Step 301: User Equipment (UE) sends an Establish Bearer Service Request to TPF. In a GPRS network, it means that GGSN receives a Create PDP Context Request.
Step 302: After receiving the Establish Bearer Service Request, TPF sends to CRF a Request Charging Rules, which carries the input information provided for CRF to determine the charging rule.
Step 303 to 304: After receiving the Request Charging Rules, CRF selects the appropriate charging rule based on the input information carried in the Request Charging Rules or based on the relevant input information provided by AF, and then returns to TPF the Provision Charging Rules, which may carry the selected charging rule and the operation instruction thereof.
Step 305: After receiving the Provision Charging Rules, TPF performs the appropriate operation defined by the CRF-selected charging rule based on the operation instruction of the charging rule.
Step 306: TPF sends to OCS a Credit Request, requesting the credit from OCS.
Step 307: After receiving the Credit Request, OCS determines the user's credit, and then returns to TPF a Credit Response, if OCS succeeds in determining the credit, then this Credit Response will carry the credit, if OCS fails to determine the credit, this Credit Response will carry the error cause.
Step 308: After receiving the Credit Response, TPF returns to UE the Establish Bearer Service Accept, and if the Credit Response carries the credit, then TPF will accept the Establish Bearer Service Request sent by the UE, and continue with the subsequent bearer-establishing process; if the Credit Response carries no user's credit, TPF will reject the Establish Bearer Service Request sent by the UE.
Under on-line charging circumstances, bearer modification will trigger a process of TPF requesting OCS to make re-authorization, the specific implementation is shown in
Step 401: UE sends a Modify Bearer Service Request to TPF, in a GPRS network, it means that GGSN receives an Update PDP Context Request.
Step 402: After receiving the Modify Bearer Service Request, TPF compares the Modify Bearer event with the pre-configured re-authorization triggers, if they match, go to step 403; otherwise, end the current re-authorization process.
Step 403: TPF sends to OCS a Credit Request and Re-authorization Request, which carries the balance of the credit and information related with the charging rule, requesting OCS to re-calculate the credits of the user. The information related with the charging rule provided for OCS by TPF may come from CRF.
Step 404: After receiving the Credit Request and Re-authorization Request, OCS re-calculates the credit and then returns to TPF a Credit Response and Re-authorization Response, if OCS obtains the credit by calculation, the Credit Response and Re-authorization Response will carry the credit re-calculated by OCS; if OCS fails to calculate the credit the Credit Response and Re-authorization Response may carry the error cause.
Step 405: After receiving the Credit Response and Re-authorization Response, TPF returns to UE a Modify Bearer Service Accept, if the Credit Response and Re-authorization Response carries the credit, TPF will accept the Modify Bearer Service Request sent by the UE and continue with the subsequent process of bearer modification; if the Credit Response and Re-authorization Response carries no credit, TPF will reject the Modify Bearer Service Request sent by the UE.
At present, although there is the definition in the Specifications for TPF initiating a re-authorization process to OCS based on that the re-authorization trigger has been detected when a bearer is modified under on-line charging circumstances, and requesting OCS to re-calculate the credit and return the result to TPF, however, in the Specifications, no source of the re-authorization triggers in TPF is mentioned, which leads to uncertainty in the implementation of a re-authorization process.
In view of the above, the present invention is to provide a method for handling re-authorization in packet data flow based charging so as to clarify the implementing process of re-authorization.
According to the embodiments of the present invention, a method for processing the re-authorization based on the charging of the packet data flow, including:
Traffic Plane Function (TPF) monitoring re-authorization triggers;
when a re-authorization trigger is detected, TPF requesting a re-authorization of the credit in a Online Charging System (OCS).
Preferably, the step of TPF monitoring a re-authorization trigger includes: pre-configuring the re-authorization trigger in TPF and TPF receiving the re-authorization trigger information from the OCS.
Furthermore, the re-authorization trigger information is provided in a Credit Response message from the OCS to TPF when a bearer is established, or provided in a Credit Response and Re-authorization Response message from the OCS to TPF when the bearer is modified.
Moreover, the step of TPF requesting the re-authorization of the credit in the OCS further includes: TPF providing the OCS with the re-authorization trigger which is currently triggering a re-authorization process. Preferably, after the step of TPF requesting the re-authorization of the credit in the OCS, the method further including: the OCS re-calculating the credit, and returning to TPF the recalculated credit.
In accordance with the embodiments provided by the present invention, TPF pre-configures re-authorization triggers, or OCS provides TPF with re-authorization triggers, so that TPF is able to monitor accurately the re-authorization triggers to be detected; TPF detects the re-authorization trigger and requests re-authorization of the credit in OCS when the re-authorization trigger is detected, OCS re-calculates the credit and returns to TPF the recalculated credit. In this way, as there are more approaches for providing re-authorization triggers, the re-authorization process in packet data flow based charging can be implemented more clearly and definitely.
Moreover, when requesting the re-authorization of the credit in OCS, TPF can further provide OCS with the re-authorization trigger that has triggered the current re-authorization process, so that the re-authorization information interaction between TPF and OS becomes more reasonable and better-defined.
In order to make technical solution and advantages of the present invention more explicit the present invention is presented in detail with reference to the drawings as follows:
In accordance with the present invention, TPF pre-configures re-authorization triggers, or OCS provides TPF with re-authorization triggers; TPF detects the re-authorization triggers and requests the re-authorization of credit in the OCS when the re-authorization trigger is detected, OCS re-calculates the credit and returns to TPF the recalculated credit.
Step 501 to step 506 are basically the same as step 301 to step 306.
Step 507: After receiving the Credit Request, OCS determines the credit, and then returns to TPF a Credit Response. If OCS succeeds in determining the credit, this Credit Response carries the credit, and, further, the re-authorization trigger information, requesting TPF to monitor the appropriate re-authorization triggers. If OCS fails to determine the credit, this Credit Response carries the error cause. The re-authorization trigger information may include re-authorization triggers, or identities of re-authorization triggers, or combination of re-authorization triggers and identities of re-authorization triggers, or may even include null.
If TPF didn't pre-configures any re-authorization triggers, then the re-authorization trigger information that OCS provides for TPF includes re-authorization triggers, and TPF is requested to monitor the re-authorization triggers received from the OCS. If TPF has pre-configured re-authorization triggers, then the re-authorization trigger information may include the identities of re-authorization triggers, and TPF is requested to monitor the re-authorization triggers corresponding to the identities; or the re-authorization trigger information may include a combination of re-authorization triggers and identities of re-authorization triggers, and TPF is requested to monitor the re-authorization triggers from OCS and the re-authorization triggers corresponding to the identities; or the re-authorization trigger information may contain null, then according to the pre-setting, TPF monitor all the pre-configured re-authorization triggers or not to monitor any of the pre-configured re-authorization triggers.
When there are already some pre-configured re-authorization triggers in TPF, the re-authorization trigger information may also include re-authorization triggers; then according to the pre-setting, TPF will monitor both the re-authorization triggers received from the OCS and all the pre-configured re-authorization triggers or just to monitor the re-authorization triggers received from the OCS.
Step 508: After receiving the Credit Response, if this Credit Response carries the re-authorization triggers information, TPF will start monitoring the appropriate re-authorization triggers according to the re-authorization trigger information, and if detecting the appropriate re-authorization triggers, TPF will request re-authorization of the credit in the OCS.
Step 509 is basically the same as step 308.
It is not strictly required that Step 508 and step 509 be performed in order.
Wherein, OCS can make the re-authorization triggers information carried by the Credit Response or carried by an independent message to be sent to TPF.
Step 601 to step 602 are basically the same as step 401 to step 402.
Step 603: TPF sends to OCS a Credit Request and Re-authorization Request, which carries the balance of the credit and related information of the charging rule, requesting OCS to re-calculate the credit. The related information of the charging rule provided for OCS by TPF may come from CRF. The Credit Request and Re-authorization Request may further carry the currently occurring re-authorization trigger to inform OCS of the specific re-authorization trigger which is currently triggering the re-authorization process.
Step 604 to step 605 are basically the same as step 404 to step 405.
Step 701 to step 702 are basically the same as step 401 to step 402.
Step 703 is basically the same as step 603.
Step 704: After receiving the Credit Request, OCS re-calculates the credit, and then returns to TPF a Credit Response and re-authorization response, if OCS succeeds in calculating the credit, then this Credit Response and re-authorization response carries the credit recalculated by OCS; if OCS fails to calculate the credit, and if the credit is not sufficient, then this Credit Response and Re-authorization Response may carry the error cause. The Credit Response and Re-authorization Response may further carry the re-authorization trigger information, requesting TPF to update the monitored re-authorization triggers.
If TPF didn't pre-configured any re-authorization triggers, the re-authorization trigger information provided for TPF by OCS includes re-authorization triggers, requesting TPF to monitor the re-authorization triggers received from OCS. If TPF has pre-configured some re-authorization triggers, the re-authorization trigger information may include identities of re-authorization triggers, requesting TPF to monitor the re-authorization triggers corresponding to the appropriate identities. The re-authorization trigger information may also include a combination of re-authorization triggers and identities of re-authorization triggers, requesting TPF to monitor the re-authorization triggers received from the OCS and the re-authorization triggers corresponding to the appropriate identities. The re-authorization trigger information may contain null as well, then according to the pre-setting, TPF monitors all the pre-configured re-authorization triggers or not to monitor any of the pre-configured re-authorization triggers.
When there are already some pre-configured re-authorization triggers in TPF, the re-authorization trigger information may also include re-authorization triggers; then according to the pre-setting, TPF will monitor both the re-authorization triggers received from the OCS and all the pre-configured re-authorization triggers or just to monitor the re-authorization triggers received from the OCS.
Step 705: After receiving the Credit Response and re-authorization response, if this Credit Response and Re-authorization Response carries the re-authorization trigger information, TPF will start monitoring the appropriate re-authorization triggers according to the information, if having detected the appropriate re-authorization triggers, TPF will request re-authorization of the credit in the OCS.
Step 706 is basically the same as 405.
The above description are just the preferred embodiments of the present invention, and should not be used to confine the protection scope thereof.
| Number | Date | Country | Kind |
|---|---|---|---|
| 200410062686.3 | Aug 2004 | CN | national |
This application is a continuation of International Patent Application No. PCT/CN2005/001186, filed Aug. 3, 2005, which claims priority to Chinese Patent Application No. 200410062686.3, filed Aug. 6, 2004, all of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN05/01186 | Aug 2005 | US |
| Child | 11671560 | Feb 2007 | US |
