System and method for charging in a communications network and a communications network charging server

ES 2 298 429 T3

DESCRIPTION

System and method of billing in a communication network and a billing server in a communication network.

Technical field of the invention

The present invention relates generally to communication networks, and more specifically to a billing system and method in a communication network, and to a billing server in a communication network.

Background of the invention

In current communications networks, that is, in telecommunications networks and in data communications networks, there are no real-time billing protocol mechanisms, over which a customer providing services to the subscriber would be able to carry out a charge to the account of a subscriber residing on a billing server, based on charges calculated by the customer.

The current mechanisms of the real-time billing protocol do not allow any client to request the billing server to evaluate a service event (or events) and to return the number of events that the subscriber is allowed to provide.

Furthermore, the current mechanisms of the real-time billing protocol do not allow any client to inform the subscriber, before and after the execution of the Services Event, about the monetary amount to be used.

The new generation of networks specifies (eg 3G Charges and Billing requirements) the most critical requirements for Accounting applications (Billing Systems) of communication networks. The Accounting application must be capable of evaluating Accounting information in real time. For example, the service environment processes the service event information, which has to be evaluated before or during the delivery / execution of the service.

There are also requirements on end-user credit control of the new generation of communication networks. The Accounting application must be able to check the end user's account to cover the charges for the requested Service Event, prior to the execution of that service event. All billable events related to a specific account must be excluded to the end user when the account has been depleted or expired.

In next generation networks, the number of services offered to the end user and the number of entities that deliver these services to end users will grow. To meet all these new requirements, new types of billing mechanisms are needed in a data communications network, which will support communication between Credit Control applications / servers and the service environment.

A particular problem arises in relation to intelligent network (IN) services, such as special price calls, the Virtual Private Mobile Network (VPN), Prepaid charges and the Personal Number. As prepaid is normally an IN service by itself, it is not convenient to provide prepaid of other IN services for subscribers. To provide prepaid on other IN services, the prepaid functionality has to be integrated with the other particular IN service in a prior art communication system. Therefore, each IN service has to be redesigned with the added prepaid functionality, to be able to offer the service as prepaid.

Document WO 00 05871A1 discloses a prepaid system and a method to allow a prepaid subscriber of the wireless telecommunications system to review the characteristics of the call during a call within the operator node, and from the roaming sites to make a charge. on the subscriber's prepaid account, on a real-time basis. The system includes a switching node that allows to establish a call with the prepaid subscriber when there is a positive balance of the prepaid service, and to terminate the call when the positive balance of the prepaid service is zero. The switching node continuously generates messages formatted by the Data Message Manager (DMH) of the call event in real time, related to the call made by the prepaid subscriber, and forwards these call event messages to an administrative network of prepaid. The prepaid administrative network stores the positive balance of the prepaid service of the prepaid subscriber and generates an initial amount of debit of the charge used during the call at call establishment to reduce the positive balance of the prepaid service. The prepaid administrative network, in response to the call event messages in real time, received from the detailed call event generation means, reviews the initial amount of debit of the charge to generate a debit amount in real time , used during the call to reduce the positive balance of the prepaid service.

Document US 2001 021 647 A discloses a special call rate billing method, comprising the steps of (a) causing an exchange device to receive a call origin signal from a terminal unit of the originating subscriber. the call; (b) causing the exchange device to request from a special billing server whether the subscriber terminal unit is a subscriber terminal unit of

ES 2 298 429 T3 special billing; (c) causing the special billing server to answer the exchange device if the subscriber terminal unit that originated the call is a subscriber terminal unit with special billing; and (d) if the terminal unit that originated the call is a call terminal unit with special billing, as a result of step (c), causing the exchange device to notify a general billing server that the billing unit The subscriber's terminal that originated the call is charged a special billing rate.

Document WO 98 59504 A1 discloses a control point that manages an Advised Billing (AoC) service provided to mobile subscribers. The control point is informed of each call that involves a mobile station that is subscribed to the Advised Billing service. The control point determines one or more AoC service parameters for the call, and sends them to a switching node currently serving the mobile station. The mobile station receives the AoC parameters from the serving switching node and determines the expected cost associated with the call, and presents that cost to the mobile subscriber. The accumulated costs for that call can be determined and also presented during the call.

Summary of the present invention

It is an object of the present invention to overcome or at least mitigate the disadvantages of the prior art. The present invention provides a system and method for billing in a communication network and a billing server in a communication network.

According to a first aspect of the present invention, there is provided a system for billing in a communication network, comprising an IN service associated with the network, for providing services to subscribers associated with the network. The system further comprises a billing server adapted to manage the subscriber's account information, where the IN service is adapted to send a first billing request message for a service, to the billing server, before providing the service, using an online billing protocol, the billing server being adapted to pre-reserve a quantity of resources in the subscriber's account, said quantity depending on the requested quantity included in said message; and to return a response message that includes the information that indicates whether a pre-reservation of a quantity of resources is made in said subscriber account, to allow the use of said service to said IN service, using said online billing protocol .

According to a second aspect of the present invention, there is provided a method for billing in a communication network comprising an IN service associated with the network, for providing services to subscribers associated with the network, and a billing server having the subscriber's account information and which is adapted to manage the subscriber's account information. The method is characterized by the steps of:

the sending from said service IN of a first billing request message for a service, to the billing server, before providing the service, using the online billing protocol, carry out by said billing server the pre-reservation of an amount of resources from the subscriber's account, where said amount depends on the requested amount included in said message; and returning a response message that includes information indicating whether the amount of resources is pre-reserved in said subscriber account, to allow the use of said service to the IN service, using said online billing protocol.

According to a third aspect of the present invention, a billing server is provided for billing the use of the service in a communication network. The billing server is characterized in that the billing server (2) is adapted to:

manage subscriber account information;

receive a first billing request message for a service from an IN service, before the service is provided, using an online billing protocol, and pre-reserve a number of resources in the subscriber's account, depending said amount of the requested amount included in said message about said service, and returning a response message that includes information indicating whether the amount of resources is pre-reserved in said subscriber account, to allow the use of said service to the IN service, using said online billing protocol.

The advantages of the present invention are that any customer network can debit the account of the specified subscriber on the billing server, any customer can use the billing server to evaluate the event (or events) of the service without knowledge of the actual price and controlling how many of those service events can be supplied to the user, and the customer can provide a cost estimate to the subscribers, before the execution of the service and a final cost of the use of the service after the execution of the service. Another advantage is that intelligent network (IN) services can be provided at prepaid rates without completely redesigning the IN service. Therefore, each IN service does not need to be redesigned with the added prepaid functionality of being able to offer the service as prepaid.

ES 2 298 429 T3

Brief description of the drawings

For a better understanding of the present invention, and in order to show how it can be carried out, reference will now be made to the accompanying drawings, in which:

Figure 1 illustrates the billing system in a communication network, according to the present invention,

Figure 2 illustrates the sequence of messages for the debiting of monetary units in the billing system in a communication network, according to the present invention,

Figure 3 illustrates the sequence of messages to rate service events in the billing system in a communication network, according to the present invention,

Figure 4 illustrates the sequence of messages for estimating costs for billing, in a communication network, according to the present invention,

Figure 5 illustrates a block diagram of the billing system, in a communication network, according to the present invention,

Figure 6 illustrates another embodiment of the system of Figure 1, and

Figure 7 illustrates the message sequence for billing in the billing system in a communication network of Figure 6.

Detailed description of the invention

The solution according to the present invention presents a new mechanism for billing in a communication network. This new billing mechanism allows any customer network to debit the account of the specified subscriber on an Online Billing Server. the monetary amount to be owed is determined by the client.

In the new billing mechanism, according to the present invention, a network client can use the billing server to price the service event or service events, without knowing the actual price and controlling how many of those billing events. service can be provided to the subscriber. In the new billing mechanism according to the present invention, the customer can further provide the user with an estimate of the cost before the execution of the service, and the final cost after the execution of the service.

Figure 1 illustrates the billing system in a communication network, according to the present invention. In the billing system according to the present invention, there is a client 1 that provides services to the subscriber and a billing server or billing control server 2 that has the account information of the subscriber. Client 1 and billing server 2 communicate using Online Billing Protocol 3. Online Billing Protocol 3 is a two-way protocol that supports real-time billing. Real-time billing involves taking into account what is done as part of the services that have been provided. Preferably, Online Billing Protocol 3 is based on an IP protocol, such as the Diameter protocol. Alternatively, the Online Billing Protocol is based on the Parlay protocol, on the INAP CS1oenSS7 protocol.

Figure 2 illustrates the sequence of messages for debiting the monetary units in the billing system of a communication network, according to the present invention. The customer can reserve money for a subscriber to use services to be billed in a manner controlled by the customer 1, by sending a Charge Request message 4 to the billing server 2. An alternative Request for Charge message is marked with the numerical reference 6.

In the charge request 4, 6, the subscriber to be charged is identified by a specific Subscriber Identifier, for example the IMSI, the MSISDN, the IP address or the SIP_URL. Customer 1 indicates how much money he wants to reserve to use the services controlled by him (Reserved Monetary Amount). The client 1 can also indicate to the billing server 2 the expected duration during which the monetary amount is to be consumed (Reservation Duration). The billing server 2 uses the message parameters of the Charge Request 4, 6 to determine how it should respond to the request 4, 6.

The billing server 2 then determines, even independently of the value requested by the customer 1, the monetary amount to be reserved on the subscriber's account. The amount can, for example, be a predetermined value independent of the requested value. For example, the amount may equal the requested value if there is enough money in the account. Similarly, the amount may be less than requested in the event that there is not enough money in the subscriber's account, or in the event that the subscriber is unreliable.

It may also be that customer 1 does not indicate a requested monetary amount in Charge Request 4, 6. In this case, billing server 2 needs to determine the monetary amount to reserve, based on other

ES 2 298 429 T3 message parameters, such as the service used, for example the Service Event Information, such as time, data volume, specific service events (for example, web page downloads, requests for hours, etc.) and money, from Charge Request 4, 6, or based on the configuration parameters in the billing server 2. The billing server 2 returns the reserved monetary amount in a Response to Charge 5 message, to customer 1. An alternative Response to Charge message is marked with the numeric reference 7.

The billing server 2 also determines the duration allowed to be used for the consumption of the reserved monetary amount. Duration can be a default value independent of the requested value. For example, the duration may be longer than the requested value in case of signaling of capacity problems, or the duration may be less than what has been requested in case the subscriber is unreliable.

In the case in which the client 1 does not indicate a Duration of the requested Reservation, the billing server 2 needs to determine the duration to reserve, based on other parameters of the message of the Request for Charge 4, 6, or based on the parameters of configuration on billing server 2. The billing server 2 returns the duration of the reservation in a Response message from Charge 5, 7 to customer 1.

The billing server 2 can also choose not to put any time limit on the use of the monetary amount, in which case it does not send the Duration of the Reservation as a parameter of the message. The billing server 2 can also indicate in the message of Charge 5, 7 to the client 1, that the reservation has not been successful, for example in the case that the account of the subscriber is totally exhausted.

When the Response for Charge 5, 7 indicates that the monetary amount has been successfully reserved, the customer 1 will allow the subscriber to initiate the billable transactions on the customer's network. When the subscriber has spent all the monetary amount reserved by the billing server 2, the client 1 again requests more money from the billing server 2 by sending a new Charge Request 6.

In the event that the monetary amount reserved by the charge server 2 has not been spent upon expiration of the reservation time assigned by the billing server 2, the client 1 contacts the billing server 2 and makes a new Charge Request 6 that indicates how much money was actually used by the subscriber (Monetary Amount Used). The new Charge Request 6 message may also include a request for more money.

When the billing server 2 receives the knowledge of the money used by the subscriber, it returns the monetary amount initially reserved to the account, and deducts the monetary amount used from the account. Then the billing server 2 begins to reserve the next monetary amount in the account. If the knowledge of the money used by the subscriber is not received in the message, the billing server 2 deducts the amount based on the amount reserved on receipt of the Charge Request 4, 6, above.

In the event that the initial reservation request 4 has not been successful, customer 1 will determine if he wishes to retry the reservation, for example, with a lower value of the Reserved Currency Units. The billing server 2 may offer the customer 1 some clue to determine what to do in the event of an unsuccessful reservation. The billing session between the customer and the Billing Server can be terminated by the customer 1, according to the instructions from the billing server 2 (Close the Billing Session).

The billing server 2 includes in each Response of Charge 5, 7, the accumulated cost (Accumulated Cost) for the billing session. The final response message 5, 7 also includes the total cost of the billing session.

Figure 3 illustrates the sequence of messages for charging service events in the billing system of a communication network, according to the present invention. Customer 1 can request service event rates and reserve money for a subscriber to use the service by sending a first Charge Request message 8 to the billing server. A second Request for Charge message is marked with the numerical reference 10.

In Charge Request 8, 10, the subscriber to be billed is identified by a specific subscriber identifier, for example the IMSI, the MSISDN or the SIP_URL. Customer 1 indicates the type of service event (Service Event Information) and the number (Number of Events) of such events, which he wishes to be priced. The client 1 can also indicate to the billing server 2 what is the expected duration, during which the service events are to be consumed (Reservation Duration). The billing server 2 uses the message parameters of the Charge Request 8, 10, to determine how it should respond to the request 8, 10.

The billing server 2 then rates the requested service using the service event information and the requested information number, and reserves the corresponding amount of money in the subscriber's account.

The billing server 2 then determines, even independently of the number of events requested by the client 1, the number of events that are guaranteed to be used by the subscriber. The number of events can be, for example, a predetermined value independent of the requested value. For example, the number of events can be equal to the requested value for example in case there is enough money in the account. Similarly, the number of events may be less than requested in the event that there is not enough money in the subscriber's account, or in the event that the subscriber is unreliable.

ES 2 298 429 T3

The billing server 2 returns the number of events that are guaranteed for use by the subscriber, in a Charge Response message 9, to customer 1. An alternative Charge Response message is marked with the numerical reference 11.

The billing server 2 also determines the duration allowed to be used for the consumption of the reserved monetary amount. Duration can be a default value independent of the requested value. For example, the duration may be longer than the requested value in the case of signaling capacity problems, or the duration may be less than the requested value in the event that the subscriber is unreliable.

In the event that the client 1 does not indicate the Duration of the requested Reservation, the billing server 2 needs to determine the duration to reserve, based on other parameters of the message, for example the Service Event Information of the Charge Request 8 , 10, or based on the configuration parameters of the billing server 2. The billing server 2 returns the duration of the reservation in a Reply to Charge 9, 11 message to customer 1.

Alternatively, the Billing Server does not place any duration limit on the use of guaranteed number of events, in which case it does not send the Reservation Duration as a message parameter.

The billing server 2 may also choose not to limit the use of guaranteed number events, in which case it does not send the Reservation Duration as a parameter of the message. The billing server 2 may also indicate in the Reply to Charge 9, 11 message to the customer 1 that the reservation has not been successful, for example, in the event that the subscriber's account is totally depleted.

When the Response to Charge 9, 11 indicates that the pricing of the service event and the reservation of a monetary amount has been successful, the customer 1 allows the subscriber to initiate billable transactions in the customer's network. Once the subscriber has used up all the guaranteed events reserved by the billing server 2, the client 1 again requests more service events from the billing server 2, sending a new Charge Request 8, 10.

In the event that the guaranteed number of events reserved by the billing server 2 has not been spent, upon expiration of the reservation time assigned by the billing server 2, the client 1 contacts the billing server 2 with a new Charge Request 10, which indicates how many events were actually used by the subscriber (Number of Service Events Used). The new Charge Request message 10 may also include a request for more events.

When the billing server 2 receives the knowledge of the service events used by the subscriber, it returns to the account the amount initially reserved, that is, it cancels the reservation, and deducts from the account a monetary amount equal to the number of service events used. Thereafter, the billing server 2 charges the new service event request and begins to reserve the corresponding amount in the account. If the knowledge about the service events used by the subscriber is not received in the message, the billing server 2 deducts the amount based on the amount already reserved.

In the event that the initial reservation request 8 is unsuccessful, the customer 1 will determine if it wishes to retry the reservation, for example with a smaller number of events. The billing server 2 may give some clue to the customer 1 to determine what to do in the event of an unsuccessful reservation. The billing session between the customer and the Billing Server can be terminated by the customer 1, in accordance with the instructions received from the billing server 2 (Closing the Billing Session).

The billing server 2 includes in each Charge Response 9, 11 the accumulated cost (Accumulated Cost) for the billing session. The final response message 9 also includes the total cost of the billing session.

Figure 4 illustrates the sequence of messages for estimating costs for billing in a communication network, according to the present invention. The client 1 can request the price of the service event (Price Request Indication) before the execution of the service, by sending a Charge Request message 12 to the billing server 2.

By using the service event information and the number of the requested information, the billing server 2 calculates the price of the requested service. The billing server 2 does not perform any account balance checking or account adjustment. The billing server 2 returns the calculated price indication to the customer 1 in a Charge Response message 13. The customer 1 can then inform the subscriber of the cost of the requested service.

Figure 5 illustrates a block diagram of the billing system in a communication network, in accordance with the present invention. In the billing system according to the present invention, there is a Service / Network Element 14 and Service Consumers 15, 16. The Service / Network Element 14 may be a Service Element 14 that provides Services to Consumers 15, 16 of Services or a Network Element 14 that allows Consumers 15, 16 of Services to access the use of the network.

ES 2 298 429 T3

In the billing system according to the present invention, there is also a Credit Control Server 17. Before providing the service, the Service / Network Element 14 contacts the Credit Control Server 17 using the Credit Control Protocol 18 with the Service Event information included (as described in Figures 1- 4 above). The Credit Control Server 17, depending on the Service Event information and as defined by this information, rates the Service Event, assigns a price to the Service Event, checks the credit and makes the pre-reservation.

In the billing system according to the present invention, there is also an Accounting Server 19. The Accounting Server 19 is a server that manages the accounting of different events and services in the client's network.

The Service / Network Element 14 can alternatively deliver the Service Event Information to the Accounting Server 19, using Accounting Protocol 20, this Accounting Server 19 being able to contact the Credit Control Server 17. Credit Control Server 17 and Accounting Server 19 are logical entities. A configuration implementation may contain the Credit Control Server 17 and the Accounting Server 19 forming a single central computer or billing server.

When the Service Consumer 15, 16 requests a service, the request is forwarded to a Service / Network Element 14 in the home domain, which is the same administrative domain, in which the Consumer Credit Control Server 17 is located 15, 16 of Services.

Next the Service / Network Element 14 authorizes the Service Consumer 15, 16 and sends a request to the Credit Control Server 17. Service / Network Element 14 may obtain authorization information from an authorization server. The authorization server may also send to Service / Network Element 14 instructions and identification data related to Credit Control Protocol 18 and Accounting Protocol 20.

The billing system in a communication network, according to the present invention, has two main service scenarios;

- a one-time event used for price request and credit control, and

- various questions that are used for session-based credit control.

The one-time event is used when Service / Network Element 14 wants to know the cost of the Services Event without reservation of credit. It can also be used for a credit check when the one-time event has taken place in the service environment. There may be services offered by Application Service providers, the prices of which are not known in the Service / Network Element. The End User may also wish to know the exact price of a Service Event before requesting the Service Event.

Following a request 12 from the customer, the Credit Control Server 17 calculates the cost of the requested Service Event, but does not carry out any checking of the account balance or reserve the credit on the account. The requested Service Event price is returned to Service / Network Element 14 with response message 13.

There are certain one-time events for which service execution always succeeds in the service environment. In these cases, Service / Network Element 14 may use the one-time event scenario for actual Credit Control. The Service / Network Element 14 sends a credit control request message 4, 8 to the Credit Control Server 17, before the Service / Network Element 14 allows the Service Event to the Service Consumer 15, 16.

The Credit Control Server 17 charges the Service Event and deducts the corresponding monetary amount from the Consumer account 15, 16 from Services, and returns a credit control response message 5, 9 to the Service / Network Element 14.

In a session-based Credit Check, there are several questions: the first question, the middle question, and the final question. The Service / Network Element 14 sends a message 4, 8 of the first query to the Credit Control Server 17 before the Service / Network Element 14 allows the Service Event to the Service Consumer 15, 16.

The Credit Control Server 17 charges the Service Event and deducts the corresponding monetary amount from the Consumer account 15, 16 from Services, and returns a credit control response message 5, 9 to the Service / Network Element 14. The type of service units granted can be time, volume, event or money, depending on the type of Service Event.

The intermediate question can be submitted as follows. When the Service Consumer 15,16 has used up all the granted service units, the Service / Network Element 14 sends a new request 6, 10 to the Credit Control Server 17. The Credit Control server 17 charges the Service Event and deducts the corresponding monetary amount from the Consumer account 15, 16 from Services, and returns a credit control response message 7, 11 to the Service / Network Element 14 as in the first question. There can be several intermediate questions within a session.

ES 2 298 429 T3

When the Service Consumer 15, 16 ends the Service Event or when all granted units have been used, the Service / Network Element 14 sends a Final Question message 6, 10 to the Credit Control Server 17. After the final question, the Credit Control Server 17 refunds the amount of reserved credit that has not been used to the Consumer account 15, 16 of Services, deducts from the account the monetary amount used and returns a message 7, 11 of reply.

The solution according to the present invention proposes a new protocol mechanism, by means of which a client is able to load a certain amount of monetary units for the particular event (or events) that take place on the network (com / service / multimedia ) under the control of the billing server. The monetary amount to be charged is determined by the client, which sends a charge request to the server that maintains the accounts database. The server reserves the money in the account and assigns a duration during which the money must be consumed or the server must be contacted again. A return message is returned to the client. When the subscriber has spent the reserved money, the client requests the server to withdraw the monetary amount from the account.

In the solution of the new protocol mechanism, according to the present invention, a client is able to request the Billing Server (server that maintains a database of accounts) to rate a particular service event (or events) that takes place on the network (com / service / multimedia), under the control of the client. The server reserves the money in the account according to the resulting pricing and assigns the number of events and the duration during which the events are to be used or the server has to be contacted again. A return message is returned to the client. When the subscriber has used the service events, the client requests the server to withdraw the monetary amount from the account.

In the solution of the new protocol mechanism, according to the present invention, a client is able to provide a mechanism to calculate the total cost of the service event (or events) during a particular service session, according to the information provided. to the Billing Server. This solution addresses the ability to return a cost estimate for the service event (or events) before the service event (or events) run, and the exact final cost after the service event (or events) run for the served subscriber. This cost can be indicated in money.

The solution of the new protocol mechanism, according to the present invention, will improve existing billing systems by allowing account charging based on charges calculated by the querying network. The presented billing mechanism can be applied, for example, to online billing for events taking place on the Service Network and on the IP Multimedia Network. However, note that the solution is not restricted to those networks, but the client can exist on any network.

The solution of the new protocol mechanism, according to the present invention, will also improve the existing billing systems by allowing the charging of the service based on the information of the service event received from the Service Network or the IP multimedia network or some another network. The solution of the new protocol mechanism, according to the present invention, will further improve existing billing systems by allowing to provide the cost estimate before the service execution and the final cost after the service execution.

In another embodiment of the invention illustrated in figure 6, the system includes an intelligent network IN with a signaling network, which performs message switching between network elements. In this embodiment of the invention, a specific type of signaling protocol, the Camel Application Part (CAP) 21 for GSM / UMTS, is used as a bearer for the exchange of information messages and carries many types of elements. useful for smart grid services. However, CAMEL is only an example and the signaling protocol may be based on another protocol, such as Internet Protocol (IP), Signaling System 7 (SS7), IN Applications Part (INAP) for networks fixed - where CAP and INAP are carried over SS7 / C7 / SIGTRAN. In addition, the intelligent network includes a service switching function (SSF) 22, which is typically located in the (G) MSC 23 of GSM systems. The SSF 22 detects events that indicate a call requiring IN and, after this triggering, suspends the call process and begins a series of transactions with a service control function SCF 24. In this embodiment, the SCF 24 is located in a SCP (Service Control Point) 25, which manages the IN services, that is, the 1,14 clients, such as Special Rate calls, the Mobile Virtual Private Network (VPN), Prepaid billing and Personal Number . In order to provide prepaid billing in IN services, the billing server is adapted to manage online billing and charging. In this embodiment, the billing server is a CCN (Billing Control Node) 22. Therefore, an IN service of the SCP 25 sends billing data to the CCN 26, through another embodiment 27 of the billing protocol. online billing, according to the invention.

A billing request message from SCP 25 to CCN 26 includes an IN service parameter and an IN service information parameter. The IN service parameter identifies the IN service and the IN service information is used to distinguish between different use of the same IN service, for example on-network and off-network calls in VPN.

Other messages from CCN 26 to SCP 25 also include parameters to manage call control and communication connection of the end user, that is, the IN part of the prepaid service, in relation to the status of the account received from the CCN. 26. An account status parameter has different values ​​to carry the status

ES 2 298 429 T3 of the subscriber's account towards the SCP 25. In this embodiment, the different values ​​are active, supervised or excluded. The asset implies that the account can be debited; the supervised implies that the account may be due but that there are warnings, for example that the account is going to be excluded soon, and excluded implies that the account cannot be due.

In addition, it is necessary for the IN service to be able to manage the control of calls and the communication of the end user in relation to the amount available in the account, which would be received from the CCN 26. An account value parameter has different values ​​for transport the amount available from the subscriber's account to the SCP 25.

In this embodiment, the various values ​​are large, medium, and small. These values ​​imply that the account has funds that will cover more than the normally allocated duration or volume, will cover only the allocated duration or volume, or will not cover the normally allocated duration or volume, respectively.

Figure 7 illustrates a sequence of messages to be debited in the communication network billing system of Figure 6. When a VPN call is initiated from a subscriber, the MSC 23 notifies that the IN should only be invoked for the call and SSF 22 sends an initial DP to invoke SCP 25 in step 28. SCP 25 invokes the requested IN service, that is, the VPN in this example, and sends a billing request to CCN 26 in step 29 . The CCN 26 checks the account and notifies that the subscriber needs to be warned about an account with a low balance and returns the result to the SCP 25 in step 30. In step 31, the SCP 25 checks the result and notifies that the subscriber should be warned, where SCP 25 instructs SSF 22 to connect to an SRF (service charging function) 22 '. In addition, the SCP 25 instructs the SRF 22 'to play an announcement to the subscriber in step 32. When the call has been disconnected, the SCP 25 requires a report from the SSF 22 in step 33. In the next step 34, the SCP 25 instructs the SSF 22 to connect the VPN call. The call is connected and proceeds to step 35. When the call has been disconnected, the SSF 22 informs the SCP 25 of the disconnection and re-plays the requested report in step 36. The SCP 25 invokes the IN service and sends a billing request to the CCN 26 through the online billing protocol 27 in step 37. The CCN charges the call and charges the account, after which it returns the result to the SCP 25 at step 38. Disconnection continues when SCP 25 instructs SSF 22 to do so at step 39.