Method for billing a service in a Telecommunications /data network

The invention relates to a method for charging a service in a telecommunications / data network according to the preamble of claim 1.

The charging of telecommunications services and data services on the basis of prepaid credit (prepaid basis) is now an established charging mechanism and is of great economic importance in connection with the increasing availability of information, products and services via third generation mobile networks. Special emphasis is placed on ensuring a high level of accuracy and security of the billing, both of time-based and volume-based services. The rapidly increasing number of partners integrated in such systems - providers (merchants), customers (consumers), payment service providers, wireless application service providers, advertisers, portal providers etc. - Requires the use of standardized interfaces and protocols with the greatest possible flexibility with regard to their specific requirements and system requirements.

In principle, it should be noted that for the charging of services that require credit monitoring, processes relevant to billing are transmitted to network elements of the telecommunications / data network using a suitable protocol to a charging system (charging system). The protocols known for this can be summarized in three groups with the following features:<ul id="ul0001" list-style="dash" compact="compact"><li>Offline charging or ticketing: The messages are collected on the network element, and measured and shared in the debiting system at a later point in time using the time stamps they contain.</li><li>Online charging: After the network element has sent a start message, it waits for a response from the debiting system before the service is executed.</li><li>Hot billing: The network element sends a message at the beginning and at the end of the service, the service is measured and shared in time in the debiting system in parallel with the service execution. For volume-oriented services, a snapshot of the volume counter is transmitted in each message. An online charging protocol is currently required for prepaid systems. It is necessary here that the network element involved in a charging process itself knows the state of the service to be measured in terms of its time dimension. With these systems, the interfaces (charging interfaces) also carry a relatively high processing load. The invention has for its object to provide an improved method of the generic type, which in particular enables a simplified system design and a reduction in the processing load on the network elements. This object is achieved by a method having the features of claim 1. Appropriate developments of the inventive concept are the subject of the dependent claims. An essential idea of ​​the invention is that - contrary to the previously accepted ideas - a hot billing protocol can also be used for a charging system with credit monitoring, in particular a prepaid system, provided certain conditions are met. This is to be used to implement prepaid charging with the usual properties, namely</li><li>a service interruption to the second when the prepaid credit or credit expires and</li><li>the possibility of determining the end of the service a priori, so that time-cyclical debits are not required.</li></ul>

A major advantage of the proposed method / system is that its simplicity enables it to be used on more network elements. In particular, it is no longer necessary for the network element itself to know the state of a service to be measured over time, but merely to recognize a start or an end. This makes the method presented suitable for distributed systems (in which a pool of network elements takes over the provision of a service). There is also less load on the charging interface. This method is therefore particularly suitable for IP-based session-oriented services (e.g. video call, voice call, streaming) that require cost-optimized infrastructure.

In a preferred embodiment of the invention, the IETF diameter protocol is used as the transmission protocol. Furthermore, the standard diameter protocol can be used as a transmission protocol in conjunction with the RF interface defined by 3GPP, with additional use of the termination message provided therein.

For credit control, it must be required that the hot billing protocol supports a termination message (ABORT) from the charging system. This termination message is a termination message that is independent of the other log messages. The termination message can therefore be sent from the debiting system to a network element involved in the debiting process at any time. Such a termination message can also be referred to as an "free-running termination message", "independent termination message", "independent termination message", "independent abort message" or "out-of-regular-flow-message". The free-running termination message is sent from the server (debiting system, accounting system) to the network element. The provision of the service is terminated by the free running termination message; this changes the subsequent exchange of messages between the debiting system or billing system and the network element. The method according to the invention can thus be designed such that a hot billing protocol is used as the transmission protocol, which supports a free-running termination message from the debiting system. For charging a volume-based billed service, it is additionally required that an interim message be requested after a maximum permissible transferred volume can. It is irrelevant whether the maximum permissible volume is agreed dynamically through the response to the start / interim requests or statically.

For a possible implementation, it is assumed that there is a wake-up service in the debiting system that can activate a service logic on the basis of a previously entered appointment.

Since a possible delay depends on the number of wake-up calls in a unit of time, it should be agreed that when the wake-up call is entered, wake-up orders that are already present for this time period are taken into account. If a maximum number of wake-up calls per unit of time is exceeded, the wake-up call is entered at an earlier date.

It is also assumed that a second charging logic can see the context of a first charging logic. The first logic can be at rest or active at the same time.

It is advantageous if the wake-up time of a first service can be recalculated and changed by a second service. This requirement is not mandatory, an alternative strategy is discussed. For this purpose, an auxiliary service is constructed, which can be activated by a wake-up order and can recalculate the service period. The "used" credit can be debited. The auxiliary service is only required if the wake-up time of a service cannot be changed by another service.

It is also advantageous that a first service can be "woken up" by a second service in order to settle a credit that has been used up until then. This requirement is also not mandatory, since the second service can calculate and take into account the amount to be invoiced under the aforementioned conditions without actually booking it at this time. In the explanation of the calculations it is assumed that this requirement is met.

It is generally assumed that a service is released (started) by the network element at the earliest after twice the time necessary for the transmission of a message from the network element to the charging system. This requirement is necessary to schedule a service before the start, in the event that no required credit is available at the start of the transfer. It does not apply if a response to the request is awaited.

The figures serve to explain the principle of the proposed method and to illustrate an exemplary embodiment. Of these show:<ul id="ul0002" list-style="none"><li>1 is a schematic representation of the system link between the telecommunications / data network and the charging system when a charge is made,</li><li>Fig. 2 shows the possible process of charging using the IETF diameter protocol and</li><li>Fig. 3 is a schematic representation of the charging of a pool of http servers as an embodiment of the invention.</li></ul>

Fig. 1 shows how a network element involved in a fee-based service after requesting a service execution (session request) gives a signal START at the start of the service execution (start session) to the assigned debiting system, where budget monitoring is started (start budget control). At the end of the budget monitoring - for example when the prepaid credit is exhausted (stop budget control), the debiting system issues an ABORT signal to the network element, which causes the service execution to end there (stop session).

2 shows a possible procedure for charging by means of an IETF diameter, namely a time-based service which, however, can also be carried out in a volume-oriented manner in a similar manner. The systems involved are again a network element NE and a suitable accounting system. If a service is requested from the NE (a Service Request), the NE first sends an Accounting Start Request (1) to the accounting system. Based on the current credit line, this sets a maximum possible end time for the service ("credit line").

The network element NE provides the service at the earliest after a delay that corresponds to at least twice the runtime of the accounting start request (2 * t_m; configurable in practice). After the regular termination of the service provided, the NE would send an accounting stop request (3).

However, since the credit line is reached earlier in the example shown in FIG. 2, the billing system sends an abort request (2) at the predetermined time, which leads to an immediate termination of the service in the NE.

3 shows a schematic representation of a group of three http servers in cooperation with a proxy that realizes the load distribution in the nested execution of two services for a client, which are billed through a billing system linked to the computer network via a charging interface. The charging follows the principles explained above.

In the multi-server configuration shown, a credit line is used independently by several services. It is assumed that the communication flow from the client initially runs via a load distributor, which includes the providing servers 1..3 in the process. The "Video Service 1" service is provided exclusively by the http server 2, while the "Service 2" is provided by servers 2 and 3 in accordance with a load balancing scheme.

It is now assumed that the client starts Video Service 1 first. The billing system now calculates a maximum possible useful life with end time t based on the existing credit line₁. At a somewhat later point in time, the user starts service 2, which is (accidentally) communicated to server 2 by the billing system. The possible period of use is then reduced by the amount b (in the diagram arrow up). The new calculated end time is now t₂.

If Service 2 is terminated again, a cost factor falls away and the remaining credit line is now sufficient for a period that is longer. This is shown in the diagram by an arrow pointing downwards. The end point is now t₃.

At time t₃ an abortion is now sent. The picture shows the sending of the abort request to the load distributor in order to be able to terminate a distributed service (such as Service 2).

With the method according to the invention, both time-based and volume-based services can be charged in a simple and precise manner, even in the event that a second service is added during the execution of a first service of one type or another. These important use cases are explained in more detail below.

Process for charging a time-based service

The charging server receives a start request when a service is started on the network element. The tariff s (money / time unit) is determined using a rating. The user's credit c is known. The possible period of use therefore arises from<maths id="math0001" num=""><math display="block"><mrow><mtext>t = c / s</mtext></mrow></math><img file="EP1523167A2_D0001.tif" /></maths> The service therefore provides a wake-up call with now () + t.

If a stop request is received before t, the fee will be calculated and booked accordingly. Otherwise the charging logic is activated by the wake-up order and a termination must be sent. The scheduling is exact to the second because the running time of the charging logic and its possible deviations are known beforehand and can be taken into account when entering the wake-up time. The scheduling can be edited with priority.

An interim recalculation is only necessary if external requests arrive, which can cause parameters to change and therefore require a re-rating and a new determination of the term.

Process for charging an additional time-based service

If a second time-based service is added to a running time-based service, the possible runtime must be recalculated since the credit must be distributed to both services.

The service is again reported via a start request. The tariffs s1 and s2 are known. The remaining credit c of the user at this point in time is known (for this purpose, the credit already used is simply offset by the first service). In order to determine the data, at least read access to the context of the first service is required (alternative strategy for lack of possibility of write access see below).

The terms are as follows:<maths id="math0002" num=""><math display="block"><mrow><mtext>t1 = c1 / s1</mtext></mrow></math><img file="EP1523167A2_D0002.tif" /></maths><maths id="math0003" num=""><math display="block"><mrow><mtext>t2 = c2 / s2</mtext></mrow></math><img file="EP1523167A2_D0003.tif" /></maths><maths id="math0004" num=""><math display="block"><mrow><mtext>c = c1 + c2</mtext></mrow></math><img file="EP1523167A2_D0004.tif" /></maths>

Now the maximum possible runtime should be determined using both services at the same time.<maths id="math0005" num=""><math display="block"><mrow><mtext>t1 = t2</mtext></mrow></math><img file="EP1523167A2_D0005.tif" /></maths><maths id="math0006" num=""><math display="block"><mrow><mtext>c1 / s1 = c2 / s2</mtext></mrow></math><img file="EP1523167A2_D0006.tif" /></maths>

Using c = c1 + c2 results in<maths id="math0007" num=""><math display="block"><mrow><mtext>c1 = c * s1 / (s1 + s2)</mtext></mrow></math><img file="EP1523167A2_D0007.tif" /></maths>

All information on the right is known. The values ​​c2 and t1 can be determined from the result using the formulas given above. The new wake-up time now () + t1 is now entered for the two services. Both services must be scheduled at the specified time. No intermediate activation is necessary.

If it is not possible to change the wake-up time of a first service from a second charging logic, a suitable credit must be kept. Therefore, not all of the user's credit is used, but only a part (e.g. 20%, with a certain minimum). If this time expires, the service itself recalculates the end time using the mentioned auxiliary service. This procedure requires periodic activation of the services. This replacement solution can block the use of a second service, even if there is sufficient credit in the account.

Process for charging an additional volume-based service

A volume-based service can only be measured by the network element. The granted-unit method is used for this, in which a volume is periodically made available to the network element. Each "disk" has a volume determined by the charging system and a maximum temporal expansion. When a start request arrives, an adequate volume and a corresponding amount of money are reserved. This affects the runtime of an already running, time-based service.

Determining the reservation amount for the volume-based service requires, among other things, knowledge of the maximum throughput per unit of time dmax. The reserved volume is<maths id="math0008" num=""><math display="block"><mrow><mtext>v = dmax * t2</mtext></mrow></math><img file="EP1523167A2_D0008.tif" /></maths> being again<maths id="math0009" num=""><math display="block"><mrow><mtext>t1 = t2</mtext></mrow></math><img file="EP1523167A2_D0009.tif" /></maths> should apply.

For the sake of simplicity, it is again assumed that credit already used has been settled at this time. The credit is now divided between the (first) time-based and the (second) volume-based service:<maths id="math0010" num=""><math display="block"><mrow><mtext>t1 = c1 / s1</mtext></mrow></math><img file="EP1523167A2_D0010.tif" /></maths><maths id="math0011" num=""><math display="block"><mrow><mtext>c2 &lt;dmax * t2 * s2</mtext></mrow></math><img file="EP1523167A2_D0011.tif" /></maths> whereby the tariff s2 carries the unit monetary amount per unit volume.<maths id="math0012" num=""><math display="block"><mrow><mtext>In addition, c = c1 + c2.</mtext></mrow></math><img file="EP1523167A2_D0012.tif" /></maths>

By inserting you get<maths id="math0013" num=""><math display="block"><mrow><mtext>c2 &lt;dmax * ((c-c2) / s1) * s2</mtext></mrow></math><img file="EP1523167A2_D0013.tif" /></maths>

The unitless coefficient dmax * s2 / s1 should be called k.<maths id="math0014" num=""><math display="block"><mrow><mtext>c2 &lt;k * (c-c2)</mtext></mrow></math><img file="EP1523167A2_D0014.tif" /></maths>

Since all values ​​are positive, you get by switching<maths id="math0015" num=""><math display="block"><mrow><mtext>c2 &lt;c * k / (k + 1)</mtext></mrow></math><img file="EP1523167A2_D0015.tif" /></maths>

This means that the credit to be reserved is limited by the right side. It can be calculated from known values. The remaining values ​​t1, t2, c1 result from inserting the value c2 into the equations above.

This formula applies to a "last slice", ie the volume c2 to be reserved can be lower due to other conditions (eg maximum volume to be reserved for a slice or maximum time extension of a slice). With each interim message, the values ​​and run times must be redetermined.

The maximum remaining term of both services can therefore be calculated for the next disc from the given formula. With a corresponding wake-up call, the first service can be scheduled to the second.

This procedure by itself has the disadvantage that a residual amount from the volume-based service is not taken into account. For volume-based services, however, it is typical that the service is "at rest" for a long time and there is no charge. The remaining amount becomes large if a large disk c2 is selected, but the service does not create any volume.

It is therefore proposed to choose a pane size for the volume-based service that depends on the available remaining credit and the expected volume to be generated (e.g. from previous user behavior), i.e. c2 is not only limited by the above formula, but also taking into account one certain minimums also by a factor f with f &lt;100%:<maths id="math0016" num=""><math display="block"><mrow><mtext>c2 &lt;c * k / (k + 1) * f</mtext></mrow></math><img file="EP1523167A2_D0016.tif" /></maths>

The runtimes of existing services are recalculated with every interim report of the volume-based service.

The implementation of the invention is not limited to these use cases and the system configurations mentioned above, but is also possible in a large number of modifications which are within the scope of professional action.