WO2009152847A1

WO2009152847A1 - A method of communication for use in a credit control application, communication system and computer program product

Info

Publication number: WO2009152847A1
Application number: PCT/EP2008/057581
Authority: WO
Inventors: Vesa Hellgren
Original assignee: Nokia Siemens Networks Oy
Priority date: 2008-06-17
Filing date: 2008-06-17
Publication date: 2009-12-23

Abstract

The present invention refers to a method of communication for use in a credit control application, a respective communication system and computer program product, wherein a credit-control server (1) determines, whether a final credit unit has been used for a requested service and if so, sending a Final-Unit-Indication (S40, S50) to a gateway node (3) including a specific code value. A WAP Push message (S55) which explicitly corresponds to the code value is sent to a requester (4) of the service with an indication that a final unit has been used.

Description

Title

A method of communication for use in a credit control appli^¬ cation, communication system and computer program product

The present invention relates generally to a method of commu^¬ nication for use in a credit control application, a respec- tive communication system and a computer program product and, more particularly, to a respective method, a communication system and a computer program product realized in data net^¬ works, where Diameter Credit Control Application (DCCA) and Wireless Application Protocol (WAP) push architecture can be used.

Thus, the present invention may include networks, which are based on 3GPP (3rd Generation Partnership Project), GPP2 (3^rd Generation Partnership Project 2) or OMA (Open Mobile AlIi- ance) reference architectures.

The current accounting models specified in the Radius Ac^¬ counting (RFC2866) Diameter base (DIAMBASE) are not sufficient for a real-time credit control, where credit-worthiness is to be determined prior to service initiation. Also, the existing Diameter authorization applications (NASREQ, DIAMMIP) only provide service authorization, but do not pro^¬ vide credit authorization for prepaid users. In order to sup^¬ port real time credit control, a new type of server was needed in the AAA infrastructure (Authentication, Authoriza^¬ tion and Accounting) i.e. a Diameter credit control server. The Diameter credit control server is the entity responsible for credit authorization for prepaid subscribers.

A service element usually authenticates and authorizes an end user with the AAA server by using AAA protocols (e.g. RADIUS or Diameter base protocol with a possible diameter applica^¬ tion) . Figure 1 illustrates a conventional credit control architec^¬ ture, which consists of a service element 3 with an embedded Diameter credit control client (CC client) , a Diameter credit control server 1, and a AAA server 2. In addition, a business support system 5 may be deployed, which includes at least the billing functionality. The credit control server 1 and the AAA server 2 constitute logical entities in this architecture model. A real configuration can combine them into a single host. The credit control protocol may be the diameter base protocol with the Diameter Credit Control Application (DCCA) .

In Figure 1, when an end user 4A or 4B requests services, such as SIP (Session Initiation Protocol) or messaging, the request is typically forwarded to the service element 3 (e.g. SIP proxy) in the end user's home domain. In some cases it might be possible that the service element 3 in the visited domain can offer services to the end user 4A or 4B. Network access is an example of a service offered in the visited do- main where a Network Access Server (NAS) authenticates and authorizes the end user with the user's home network through an AAA infrastructure (Authentication, Authorization and Accounting) .

It should be noted that there can be a plurality of credit control servers 1 in the communication system for redundancy and load balancing. Moreover, the communication system according to Figure 1 can also contain separate rating servers and accounts can be located in a centralized data base (not shown) .

The term "service" is used and hereinafter will be understood to broadly include any service or goods which are used and/or the user may desire, require or be provided with. The term would be understood to cover the provision or complementary services. In particular, the term "service" will be understood to include e. g. internet protocol multimedia IM ser- vices, conferencing, telephoning, gaming, E-commerce and messaging (instant messaging) .

The term "credit control" defines a mechanism that directly interacts in real-time with an account and controls or moni^¬ tors the charges related to the service usage. Thus, credit control is a process of checking whether credit is available, credit reservation, deduction of credit from the end user account when service is completed and refunding of reserved credit that is not used.

The Diameter credit control Server 1 acts as a prepaid server, performing real-time and credit control. It is lo^¬ cated in the home domain and is accessed by service elements or Diameter AAA servers in real-time for purpose of price de^¬ termination and credit control before the service event is delivered to the end user. It may also interact with the business support system 5.

The Diameter credit control client uses interrogation to ini^¬ tiate a session based credit control process. During the credit control process, it is used to report the used quota and requests a new one. An interrogation maps to a re^¬ quest/answer transaction.

The service element 3 is a network element that provides a service to the end user. The service element may include the Diameter credit control client or another entity that can act as a credit control client on behalf of the service element. Examples of the service element include Network Access Serv^¬ ers (NAS) , SIP Proxy, and Application Servers such as messag^¬ ing server, content server and gaming server.

The problem in the current Diameter Credit Control Applica- tion (DCCA) specification (RFC4006 and 3GPP specification

32.299) is that it does not offer a way to initiate sending of WAP messages from DCCA client to the terminal of an end user. The DCCA specification contains elaborate mechanism for initiating redirection of user plane traffic based on Final- Unit-Indication AVP (Attribute-Value-Pair) . This redirection mechanism can be used e.g. when quota runs out and the end user should be redirected to a portal, where subscriber can purchase more quota, i.e. credit units for a specific ser^¬ vice. However, there is no mechanism, which would allow DCCA server to define that WAP-push message should be sent when quota runs out and DCCA server could define the content of the WAP-push message.

Figure 2 illustrates a status diagram showing how "graceful service determination" works in Diameter credit control ap^¬ plication according to the prior art.

In detail, Figure 2 illustrates a status diagram as defined in RFC4006, section 5.6.

When the user' s account runs out of money, the end user 4 may not be allowed to compile additional chargeable events or services. However, the home service provider may offer some services; for instance, access to a service portal where it is possible to refill or replenish the account for which the user is allowed to benefit for a limited time. The length of this time is usually dependent on the home service provider policy.

In some service environments (e.g. NAS) the graceful service determination may be used to redirect the subscriber or end user 4 to a service portal for online balance refill or other services offered by the home service provider. In this case, the graceful termination process installs a set of packet filters to restrict the user's access capability only to/from specified destinations. All the IP packets not matching the filters will be dropped or, possibly, re-directed to the ser- vice portal. The end user 4 may also be sent an appropriate notification as to why the access has been limited. These ac^¬ tions may be communicated explicitly from the server 1 to the client, i.e. service element 3, or may be configured per- service at the client. Explicitly signaled redirect or re^¬ strict instructions always take precedence over configured ones .

According to Figure 2 the service element 3 including a credit control client (CC client) delivers service to the end user 4 in a step Sl. In a step S2 and S3 a credit control re^¬ quest (CCR) requests for an update of used units to the AAA server 2 and from this server 2 to the credit control server 1. The credit control server 1 submits a credit control an^¬ swer (CCA) to the AAA server 2 in step S4 and from the server 2 to the service element 3 in step S5. This credit control answer CCA may include a Final-Unit-Indication AVP (Attribute-Value-Pair) , which indicates that the granted quota in Granted-Service-Units AVP is the final quota and the action defined in the Final-Unit-Indication shall be executed when the granted quota has been consumed.

The Final-Unit-Indication has the format as shown in Figure 2, wherein the Final-Unit-Action AVP defines the action to be executed. If the action is REDIRECT as shown in Figure 2, then the credit control client shall start redirecting all traffic (which does not match with Filter-Id AVP or Restric^¬ tion-Filter-Rule AVP (not shown) ) to redirection server de- fined by the Redirect-Server AVP, i.e. TS server (Top-up server) .

The Redirect-Address-Type AVP (not shown), thus, defines the type of the redirect address in Redirect-Server-Adress (not shown) . RFC allows usually 4 different values: IPv4 address, IPv6 address, (WAP/HTTP) URL (Uniform Resource Locator) or SIP URI (Uniform Resource Indicator) . The Redirect-Server-Address AVP has type UTFδString, which means that it may contain text, which is interpreted based on the Redirect-Address-Type AVP.

The graceful service termination procedure described in Fig^¬ ure 2 allows, thus, the functionality, to connect the prepaid end user 4 to a top-up server (TS server) 6 that plays an an^¬ nouncement and prompts the end user 4 to replenish the ac^¬ count. In this case, the credit control server 1 sends only the address of the top-up server 6 where the prepaid user shall be connected after the final granted units have been consumed.

Thus, in a step S6 the credit control client of the service element 3 starts blocking traffic and redirects the traffic to the TS server 6. In a step S7 and S8 a credit control re^¬ quest is again sent to the AAA server 2 and credit control server 1 to update the used units which is responded in steps S9 and SlO by the credit-control server 1 and via the AAA server 2 to the service element 3 by the credit control an- swer CCA including the above-mentioned validity time for the redirection to the top-up server 6.

The main disadvantage of this prior art solution (i.e. con^¬ ventional graceful service termination procedure) is the lim- ited support for redirection actions. In detail, the credit- control server 1 can initiate redirection to IPv4/IPv6 ad^¬ dress, SIP URI or HTTP URL. However, IPv4/IPv6 address would not be a useful address for redirection to the top-up server 6. For example, if the subscriber 4 is using an e-mail cli- ent, even if e-mail traffic from the subscriber end user de^¬ vice is redirected to the top-up page, there is no practical way of showing information to subscriber 4 and replenish the account. Even if some method for e-mail would be found, then there are a plurality of other IP based protocols, where the similar method should be added as well. Furthermore, the con^¬ ventional procedure redirects users only when quota runs out. If, however, the subscriber is in the middle of some critical transaction (e.g. subscriber is just about to buy some expensive goods over shopping portal, but the final credit card transaction is suddenly redirected to operator portal due to quota exhaustion) , redirection causes unnecessary pain to the subscriber . It is, therefore, a need in the art to provide a method of communication for use in a credit-control application as well as a communication system and computer program product which enables an efficient communication.

According to an embodiment of the present invention there is provided a method of communication for use in a credit- control application comprising the steps: determining in a credit control server, whether a final credit unit has been used for a requested service, if so, sending a Final-Unit- Indication to a gateway node including a code value, and sending a WAP Push message, which explicitly corresponds to said code value, to a requester of the service with an indi^¬ cation whether final unit has been used. Thus, an end user may be informed about a situation where credit for a service runs out well before and unconditionally of a redirection- action and the blocking of the traffic.

According to the present invention the code value may include the action WAP_PUSH, which initiates sending of said WAP Push message to the requester, when there is the first packet, which needs to be blocked.

Alternatively, the code value may include the action WAP_PUSH_IMMEDIATE, which immediately initiates sending of said WAP Push message to said requester. Thus, an end user may be informed immediately about the status in the credit- control server and unconditionally of the status of the ser^¬ vice element.

According to the present invention the Final-Unit-Indication includes information defining a link for replenishing an account of the credit units and/or a text for showing to the requester. Thus, a situation where an account has to be filled up by an end user is supported more conveniently and particularly before this situation occurs. The foregoing has outlined rather broadly the features and technical advantages of an embodiment of the present inven^¬ tion in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of embodiments of the invention will be de^¬ scribed hereinafter, which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiments dis^¬ closed may be readily utilized as a basis for modifying or designing other structures or processes for carrying out the same purposes of the present invention. It should also be re^¬ alized by those skilled in the art that such equivalent con^¬ structions do not depart from the spirit and scope of the in^¬ vention as set forth in the appended claims.

For a more complete understanding of the present invention and the advantages thereof, reference is now made to the fol^¬ lowing description taken in conjunction with the accompanying drawings, in which:

Figure 1 illustrates a simplified block diagram of a communi^¬ cation system in accordance with the prior art;

Figure 2 illustrates a status diagram of a graceful service termination in accordance with the prior art;

Figure 3 illustrates a status diagram of a graceful service termination in accordance with a first embodiment of the pre^¬ sent invention; and

Figure 4 illustrates a status diagram of a graceful service termination in accordance with a second embodiment of the present invention.

The making and using of the presently preferred embodiments are discussed in detail below. It should be appreciated, how^¬ ever, that the present invention provides many applicable in^¬ ventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of a specific way to make and use the in^¬ vention, and do not limit the scope of the invention. More^¬ over, the same reference signs refer to same technical fea- tures if not stated otherwise. As far as "may" is used in this application it means a possibility of doing so as well as the actual technical implementation.

The present invention will be described with respect to pre- ferred embodiments in a specific context, namely the graceful service termination using Diameter Credit Control Application (DCCA) and Wireless Application Protocol (WAP) push architec^¬ ture. The invention may also be applied, however, to other protocols in data networks supporting credit control applica- tions.

Figure 3 illustrates a simplified status diagram of a grace^¬ ful service termination in accordance with a first embodiment of the present invention, wherein same reference signs refer to same or equivalent elements as in Figure 2. Thus, it is referred to Figure 2 and its detailed description in order to avoid unnecessary reiterations.

Figure 3 includes a credit control server 1, an (optional) AAA server 2 (Authentication, Authorization, Accounting) , a service element 3 which preferably includes a credit control client (CC Client) and an end user 4 requesting a specific service. The service element 3 constitutes a gateway node of the home domain and particularly may implement the above- mentioned credit control client supporting the above- mentioned Diameter credit control application.

Moreover, the gateway node or service element 3 supports Wireless Application Protocol (WAP) and may send WAP Push messages to the end user 4 being the requester of a specific service. According to the present invention the credit con^¬ trol server 1 may determine whether a final credit unit or quota has been used for a requested service, which means that money runs out for a specific service. The respective service delivery is indicated by step Sl in Figure 3 while in steps S2 and S3 a credit control request CCR is indicated which could be submitted to the AAA server 2 and from this server to the credit control server 1. Optionally, the AAA server 2 could also be omitted in some specific cases. Credit control request CCR updating the credit-control server 1 and indicat^¬ ing the used units could thus be sent also directly from the credit-control client within the gateway node or service ele- ment 3 to the credit control server 1.

In case a final credit unit has been used for a requested service, the credit control server 1 sends a Final-Unit- Indication to the gateway node 3 and its respective credit control client via steps S40 and S50. Again, the AAA server 2 could be omitted and the respective Final-Unit-Indication could be sent directly from the credit control server 1 to the credit control client in the gateway node 3. In contrast to the prior art according to Figure 2 this Final-Unit- Indication now includes a specific code value indicating the Final-Unit-Action WAP_PUSH_IMMEDIATE as well as it may contain information defining a link for replenishing an account of units, i.e. Redirect-Server : WAP Push message content. Moreover, the Final-Unit-Indication according to Figure 3 may include information defining a text for showing to the requester, i.e. end user 4.

Thus, according to the present invention the credit control server 1 may send an explicit message in e.g. the Final-Unit- Indication to the gateway node 3, which detects this message and sends a respective WAP Push message, which explicitly corresponds to the code value of the Final-Unit-Indication, to the end user 4 requesting the service in a step S55. More^¬ over, an indication may be sent by this WAP Push message that a final unit has been used. Optionally, a free editable mes^¬ sage could be submitted within the field "<text>" of the Fi^¬ nal-Unit-Indication which is also unconditionally submitted to the end user 4 by the WAP Push message in step S55. In a step S60 the credit control client may start blocking traffic if credit units have been completely used, submitting therewith a credit control request CCR in steps S7 and S8 via the AAA server 2 to the credit control server 1. In the same way as already described in the prior art according to Figure 2 the credit control server 1 may answer this request by a credit control answer CCA indicating a specific validity time back to the gateway node 3 in steps S9 and SlO. In a step SIl the end user 4 has now the possibility to refill or replenish the account by directly contacting the top-up server 6 (TS server) . The respective address, i.e. URL, URI etc. may be already included in the Final-Unit-Indication AVP indicating also the Final-Unit-Action AVP: WAP_PUSH_IMMEDIATE .

Thus, a requester or end user 4 could already be informed well before a situation occurs, where quota runs out and all credit units for a specific service have been used. Thus, the present invention provides a more comfortable way for a graceful service termination which is independent from a real situation in the gateway node 3.

Figure 4 illustrates a simplified status diagram of a grace^¬ ful service termination according to a second embodiment of the present invention, wherein same reference signs define same or similar elements as in Figures 2 and 3. Therefore, it is referred to the detailed description of Figures 2 and 3 in order to avoid unnecessary reiterations.

In contrast to the embodiment according to Figure 3 the em^¬ bodiment according to Figure 4 now submits the Final-Unit- Action AVP: WAP_PUSH sent in steps S41 and S51 from the credit control server 1 via the AAA server 2 to the service element 3, i.e. gateway node. In detail, the code value of the Final-Unit-Indication AVP (Attribute Value Pair) now includes the action WAP_PUSH which results in a WAP Push message sent to the end user 4, when there is the first packet, which needs to be blocked by the gateway node 3. In detail, after receiving the Final-Unit-Indication AVP with the Final-Unit-Action: WAP_PUSH the credit control client within the gateway node 3 starts blocking traffic in step S60, sends out the credit control request CCR in step S7 via the AAA server 2 in step S8 to the credit control server 1 indicating that quota run out and sending at the same time the WAP Push message in step S71 to the end user 4. Again, an indication that a final unit has been used may be submitted by this WAP Push message to the end user 4 wherein a free ed^¬ itable text could be further shown to the end user 4.

In a same way as already described in Figures 2 and 3, the credit control server 1 acknowledges the credit control re- quest CCR by a credit control answer CCA including a specific validity-time in steps S9 and SlO which enables the end user 4 to fill up the account in step SIl at the top-up server 6 (TS server) .

Thus, according to the present invention two new actions for the graceful service termination procedures are defined. One action (first embodiment) is used to initiate sending a WAP Push message to the subscriber user device immediately, when the credit control client receives the Final-Unit-Indication AVP (Attribute Value Pair) . The other action (second embodi^¬ ment) is used to initiate sending of a WAP Push message to the subscriber end user device, when quota runs out. In both embodiments the credit control server 1 may also define a text information, which could be shown to the subscriber end user device 4.

In detail, two new code values are defined for the Final- Unit-Action AVP. The code value 3 may be used according to the second embodiment to define the action WAP_PUSH, which is used to initiate sending of a WAP Push message to the end user 4 when the related quota has been completely consumed and there is the first packet, which needs to be blocked due to insufficient quota. The code value 4 is used according to the first embodiment of the present invention to define the action WAP_PUSH_IMMEDIATE, which means that the credit control client will immediately initiate sending of a WAP Push message to the end user. Having two different explicit code values offers more flexibility for a credit control applica^¬ tion .

According to the first embodiment the action WAP_PUSH_IMMEDIATE is suitable in those cases where the credit control server 1 wants to send the notification imme^¬ diately to the end user 4, even before the quota runs out completely. According to the second embodiment the action WAP_PUSH is suitable in those cases, where notification send^¬ ing should be delayed as long as possible.

While in the prior art the Redirect-Server AVP defines the address of the respective top-up server 6, according to the present invention the Redirect-Server AVP defines the content of the WAP push message to be submitted to the end user 4. In detail, the content of the Redirect-Server AVP including an optional text information <text> defines explicitly the con^¬ tent of the WAP push message sent from the gateway node 3 to the end user 4. Thus, two new code values are also defined for the Redirect-Server-Type AVP, because there are two types of WAP Push messages. In detail, the code value 4 is used for the WAP Push Service Indication and the code value 5 is used for the WAP Push Service Loading. Service Indication may be used to show text and possible address information such as URL to the end user 4. Service Loading will automatically start loading URI included in the WAP Push message and thus subscriber will be redirected to the top-up server 6 even if the end user 4 is currently not using WAP or HTTP applica^¬ tions .

Moreover, the Redirect-Server-Address AVP may contain the text to be sent in the WAP Push message. This text may con^¬ tain normal text and/or IP-information such as URLs (Uniform Resource Locators) . When the end user 4 gets the WAP Push message, it may contain link information with respect to the top-up server 6 and/or information about why WAP Push message was sent .

According to the present invention the Final-Unit-Indication AVP may also contain Restriction-Filter-Rule AVP to inform the credit control client that traffic to the top-up server 6 may pass. Thus, the WAP Push message may contain link infor^¬ mation to the top-up server 6 and this link information will work even if all the other traffic is blocked based on the Final-Unit-Indication AVP.

The WAP Push architecture used in the present invention is specified by Open Mobile Alliance specifications (OMA) for- mally known as WAP Forum. In detail, the WAP Push architec^¬ ture includes three nodes. The WAP client receives the WAP Push message and it corresponds to the end user. The Push Proxy Gateway (PPG) may send the WAP Push message using push Over-The-Air (OTA) protocol. The Push Proxy Gateway (PPG) is typically implemented as part of the WAP Gateway node. The third node is the Push Initiator (PI), which sends the Push Access Protocol (PAP) request to the Push Proxy Gateway (PPG), when it needs to send the WAP Push message. In gen^¬ eral, the credit control client takes the role of the Push Initiator (PI) . The exception may be the case, where the credit control client implements Push Proxy Gateway (PPG) function and then the credit control client can initiate sending of the WAP push message using push OTA protocol immediately .

The present invention has been described for graceful service termination in Diameter Credit Control Applications (DCCA) . The invention can be used in online charging interfaces, such as Gy interface between GGSN (Gateway GPRS (General Packet Radio Service) Support Node) and OCS (Online Charging System or Ro interface between CDF (Charging Delivery Function) and a charging system (OCS) . This may offer the online charging system a way to inform end users when the end user is running out of money.

Moreover, it can also be used to implement so-called Advice of Charging functionality (AoC) . Online charging system may in this case send a Final-Unit-Indication AVP with action WAP_PUSH to send a WAP push message, which informs the end user that when he or she will first time try to access a cer^¬ tain service it will be locked until the end user or sub- scriber has acknowledged that service price is acceptable.

Figures 3 and 4 illustrate a status diagram of a method and a computer program product according to the present invention. It will be understood that each step of the status diagram and combinations of blocks in the status diagram can be im^¬ plemented by computer program instructions. These computer program instructions may be loaded onto a computer or another programmable apparatus to produce a machine, such that the instructions which are executed on the computer or other pro- grammable apparatus create means for implementing the func^¬ tion specified in the steps of the status diagram. These com^¬ puter program instructions may also be stored in a computer readable memory, e.g. DVD, CD, diskette, that can direct a computer or other programmable apparatus to function in a particular manner. Moreover, these computer program instructions may be downloaded in e.g. a telecommunications network to cause operational steps to be performed on a computer or other programmable apparatus to produce a computer imple^¬ mented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the steps of the status diagram. Accordingly, steps of the status diagram support combinations of means for performing the specified func^¬ tions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each step of the status diagram and combinations of steps in the status diagram can be implemented by special purpose hardware based computer systems which perform a specified function or steps or combinations of special purpose hardware and com^¬ puter instructions.

Although embodiments of the present invention and their ad^¬ vantages have been described, it should be understood that various changes, substitutions and alterations can be made therein without departing from the spirit and scope of this invention as defined by the appended claims. For example, it will be readily understood by those skilled in the art that many of the features, functions, processes and methods de^¬ scribed herein may be varied while remaining within the scope of the present invention. Moreover, the scope of the present invention is not intended to be limited to the embodiments of the status diagram described in the present invention. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention further methods or commu^¬ nication systems presently existing or to be developed later, that perform substantially the same function or achieve sub- stantially the same result as the corresponding embodiments as described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such communication systems and methods .

Claims

Cl aims

1. A method of communication for use in a credit control application comprising the steps: determining in a credit control server (1) whether a final credit unit has been used for a requested service; if so, sending a Final-Unit-Indication (S40, S50; S41, S51) to a gateway node (3) including a code value; and sending a WAP Push message (S55; S71), which explicitly cor- responds to said code value, to a requester (4) of the ser^¬ vice with an indication that a final unit has been used.

2. A method according to claim 1, wherein said code value is the action WAP_PUSH, which initiates sending of said WAP Push message to said requester (4), when there is the first packet which needs to be blocked.

3. A method according to claim 1, wherein said code value is the action WAP_PUSH_IMMEDIATE, which immediately initiates sending of said WAP Push message to said requester (4) .

4. A method according to any of claims 1 to 3, wherein said Final-Unit-Indication includes information defining a link for replenishing an account of credit units.

5. A method according to any of claims 1 to 4, wherein said Final-Unit-Indication includes information defining a text for showing to the requester (4) .

6. A method according to any of claims 1 to 5, wherein said gateway node (3) starts blocking traffic, when the related quota has been consumed.

7. A method according to any of claims 1 to 6, wherein said Final-Unit-Indication is delivered via a AAA server (2) .

8. A method according to any of claims 1 to 7, wherein said gateway node (3) comprises a credit control client.

9. A method according to any of claims 1 to 8, wherein said credit control application is based on DCCA standard.

10. A communication system comprising: a credit control server (1); a gateway node (3) ; and a requester (4) for performing the method steps according to any of claims 1 to 9.

11. A computer program product having computer readable program code portions for performing the method steps according to any of claims 1 to 9.