WO2005027407A1

WO2005027407A1 - Method for assessing charges in data transmission networks and network elements for carrying out methods of this type

Info

Publication number: WO2005027407A1
Application number: PCT/EP2004/051869
Authority: WO
Inventors: Andreas Kanbach; Georg Kastelewicz
Original assignee: Siemens Aktiengesellschaft
Priority date: 2003-09-15
Filing date: 2004-08-20
Publication date: 2005-03-24
Also published as: DE10342555A1

Abstract

The invention relates to, among other things, a simple method in which the following method steps are executed: generating an authorization message (62); transmitting the authorization message (62) over the data transmission network to a service-furnishing computer (30); verifying the authorization of the user for the data transmission according to the contents of the authorization message (62); generating a charge assessment message (82); transmitting the charge assessment message (82) to the service-furnishing computer (30), and; changing or generating a charge assessment date according to the contents of the charge assessment message (82). A comparison between the authorization and charge assessment is easily made possible by virtue of the fact that only one service-furnishing computer (30) is involved.

Description

description

METHOD OF STORING IN DATA TRANSMISSION NETWORKS AND NETWORK ELEMENTS FOR IMPLEMENTING SUCH METHODS

The invention relates to a method for charging in a data transmission network, in which the following method steps are carried out without restriction by the specified sequence:

Generating an authorization message which contains at least one access data item that identifies a data transmission indicator in the data transmission network and at least one user identifier that indicates the user of the data transmission,

- transferring the authorization message via the data transmission network to at least one service provisioning computer - previously to an authorization server,

Checking the authorization of the user for the data transmission depending on the content of the authorization message transmitted to the service providing computer.

- Carrying out a billing for the user.

The data transmission network is a data packet transmission network or a combination of data packet transmission network and circuit-switched data transmission network. The data transfer is a packet data transfer in which a destination address is contained in a packet header and payloads in the packet trunk.

A billing procedure is explained, for example, in the standards of the 3GPP Group (Third Generation Partnership Program), which are published for example on the Internet at the address ftp://ftp.3gpp.org/specs/archive, in particular in the standards :

- 3GPP TS 32.200, 3GPP, Technical Specification Group Services and Systems Aspects, Telecomunication Management, Charging Management, Charging Principles,

- 3GPP TS 32.225, 3GPP, Technical Specification Group Services and Systems Aspects, Telecommunications Management, Charging Management, Charging Data Description for the IP Multimedia Subsystem (IMS).

As a suitable protocol, the protocol Diameter is proposed, which is an extension of the RADIUS protocol (Remote Authentication Dial In User Service). The Diameter protocol is still in de facto standardization and is available as a draft or later as a draft on the Internet site (www.ietf.org) of the IETF (Internet Engineering Task Force). Both protocols are so-called AAA protocols (Authentication, Authorization, Accounting).

Online Charging Reference Point (Rf), Offline Charging Reference Point (Rf), and IMS Service Control (ISC) interfaces are charging interfaces that are not related to one another

Have authorization. For authorization, for example, a separate service-providing computer is used via a Cx interface. For the ISC interface, work is done according to the SIP protocol, see RFC 3261 (Request For Comment), which can also be carried out without authorization. The said interfaces terminate on one side at a so-called S-CSCF unit (Call State Control Function), i. at a connection control unit.

However, the invention generally relates to charging for data packet transfers, i. also according to other standards and using other AAA protocols.

It is an object of the invention to specify a simple charging method which manages in particular with a small number of interfaces and in particular meets existing standards and uses existing or standardization standards. In addition, a server fee unit should be specified.

The invention is based on the consideration that, in particular for the billing of services in 3GPP networks, the account ting application of the Diameter Base Protocol (DBP). The Diameter protocol ordered from the shares:

- Authentication application or application,

- Authorization application or application, and - Accounting application or application.

When billing in an IMS (Internet Protocol Multimedia Subsystem), for example, only the Accounting Application component can be used. The accounting application is fully described with the commands ACR and ACA and can be used for online and for O FILine billing without reference to the other shares of authentication and authorization. Likewise, the authorization application for the authorization of services can be used independently, i. for the authorization check, but not on the so-called Ro, Rf or ISC interface.

The client and server properties or the peer to peer properties of the authorization application and the charging application are described in DiameterprotokolIL by independent state machines, see Diameter Protocol, section 8.1 for authorization (four state machines) and section 8.2 for charging ( three state machines).

Before a billing may take place in 3GPP networks, an authorization of the service and of the subscriber is generally required. An authorization always requires a complete description of the service to be used. For example, in the case of a SIP service (Session Initiation Protocol) in the IP Multimedia Subsystem (IMS), incoming calls may only be made

SIP messages leave the SIP proxy (S-CSCF) if an authorization was successful. On the other hand, a billing of a SIP service and / or a user data transfer always refers to a SIP session or SZP session. These methods are thus independent of each other in the respective 3GPP network elements. Once authorization has been performed, under certain circumstances, such as credit monitoring, there is a need for direct or indirect interaction or correlation between the charging application and the authorization application.

A typical application of the correlation between applications is, for example, that due to an event, e.g. Missing budget of a prepaid subscriber, the service being executed would have to be interrupted by the charging server. However, because the billing server does not have a corresponding message, e.g. Abort session request, a correlation to the authorization server is required, which sends the said message at the instigation of the billing server. This scenario is also known as accounting initiated termination.

While re-authorization usually results in an attribute change of the service, e.g. by prolonging the authorization time or by changing the characterization of the service, de-authorization, e.g. Fraud or error detection, to forcibly trigger the executed service, also referred to as Authorization Initiated Termination. These actions taken by the Authorization Server also have an impact on charging and must be correlated with the charging application.

Both in a distributed as well as in a central server architecture, a correlation between the respective state machines is required.

If the server state machines for authorization and account reservation (accounting), in particular for billing (charging), are arranged on different network elements, matching messages must be sent via the data transmission network during the correlation, which the network overloaded. In addition, the reconciliation reports are not standardized, so that problems can be expected when state machines from different manufacturers are used for authorization and billing.

Therefore, in the method according to the invention for the server side, in addition to the method steps mentioned at the outset, the following steps are carried out:

Transferring the billing message to the service delivery computer to which the authorization message has also been transmitted,

Changing or generating a billing clause depending on the content of the billing message transmitted to the service providing computer.

A correlation between authorization and billing can be performed by this measure within a network element. The state machines for the authorization server and for the charging server are thus executed jointly on a network element, for example as separate applications or state machines or as an application or state machine, as will be explained in more detail below. But even with separate applications or state machines there are already technical effects that lead to a simplification. So there is only one operating system on a network element. The correlation is not complicated by different operating systems. If the two applications are from the same manufacturer, the correlation becomes even easier. The correlation also eliminates the need to send messages over the communication network.

In one embodiment, the two applications use the same communication interface if the client and billing client are operated on the same network element. In another embodiment, the two server applications use different interfaces, if authorization client and billing client are operated on different network elements.

In a development, depending on the authorization message, preparations are already being made for the charging, preferably a check of the account balance of the user and / or a reservation of an amount. This can be carried out in particular if the authorization state machine and the charge state automatic machine are implemented as a state machine.

In a next development, the access to the same record is accessed when checking the authorization and when charging. The data record contains, for example, a user identifier, an access identifier, which is also referred to as a ssion identifier, and possibly a status identifier. This access is given in particular if both state machines provided in the standard state are implemented as a state machine.

In another development, a status data is stored in the data record, which indicates a subsequent status for the processing of the next message with reference to the access code or with the aid of which such a subsequent status can be determined. Such state machines are more complex than state machines with only one ground state, but offer a higher reliability, in particular against misuse of the charge or authorization, when a message arrives the state data is read and determines the next state in which the processing is then continued.

The developments in which only one state machine is used both for the authorization server and for the charging server are based on the consideration that then no additional correlation is required. So For example, the charging state machine, in particular the part required for a one-time charging, is embedded, for example, in the authorizing state machine, as will be explained in more detail below. Consequently, the two server applications fertil are arranged on a network element and are realized in particular by a program. For embedding, there are two variants explained below on the server side.

In a further development, the processing of the authorization message and the processing of the charging message are carried out by the same state machine so that the state machine can assume at least two states in which messages are awaited. The automatic state machine is preferably in the same state upon arrival and / or also immediately after the processing of the two messages, in particular in the state "Open" according to Diameter protocol.

In an alternative development, the processing of the authorization message and the processing of the charging message are also carried out by the same state machine, the state machine processing the Na_chricht on arrival of a message starting from a basic state and then returning to the basic state to respond to the arrival of another To wait for messages. This state machine has a simpler structure than a state machine with several wait states.

The invention also relates to a second aspect

Procedures for the client side or a client in which authorization and charging are connected more closely than before. For the client side, the same or similar considerations apply as for the server side. In particular, in the method according to the second aspect, the same data record is accessed when generating the authorization message and when generating the billing message. The relevant data need only be saved once and are consistent. In particular, when the authorization portion and the charging portion are realized by the same state machine, the same record is applied to the same. Generating both messages accessed.

In particular in combination with the first aspect, considerable simplifications result since only two state machines and only one interface are used in total.

In a development for both methods according to the invention, a connection setup message is generated and transmitted via the data transmission network. The connection establishment message is processed according to the protocol before the authorization message is transmitted, so that a user data transmission connection is set up quickly. Alternatively, the connection setup message is processed according to protocol only after the receipt of a response message for the authorization message, so that the connection setup message is only processed if the authorization is present. If there is no authorization, no network resources are bound.

The invention also relates to charging units with which the methods according to the invention can be carried out. The units contain subunits which are constructed in such a way that during their operation process steps of the methods according to the invention or their developments are carried out. The units can be constructed exclusively by circuitry, i. without processor and program. Alternatively, however, the units contain at least one processor that performs the functions of the subunits when executing the instructions of a program.

Using a common authoring and billing application on the server side or on the client side results in the following technical effects: - The billing no longer needs to be preceded by a separate authorization of the service or subscriber,

the correlation of the authorization application and the charging application becomes simpler or completely eliminated, the number of required interfaces between network elements is reduced, which simplifies both the programming and the debugging,

The user's budget is managed centrally, with no encrypted messages or values being transmitted over the data transmission network,

- The network elements are more scalable,

- New billing methods can be included faster,

- Low development effort by reducing the number of state machines and options.

In the following the invention with reference to the accompanying

Drawings explained. Show:

FIG. 1 shows a first variant for combined state machines on the server side (service side) and on the client side (service side),

FIG. 2 shows a second variant for combined state machines on the server side and on the client side,

FIG. 3 shows a combined state machine on the server side and separate state machines on the client side,

FIG. 4 shows separate state machines on the server side and a combined state machine on the client side FIG. 5 shows the message flow for authorization and charging in the case of combined state machine on the server side and separate state machines on the client side,

FIG. 6 functional units of a server unit with combined state machine, FIG.

FIG. 7 functional units of a client unit with combined state machine, and FIG. 8 shows a server network element with two separate state machines and a client network element with two separate state machines.

FIG. 1 shows a first variant with a combined state machine 10 on the server side and with a combined state machine 12 on the client side. Between the two state machines there is an interface 14 on which messages are transmitted in accordance with the Diameter protocol, which are explained in greater detail below with reference to FIG.

The state machine 10 operates according to the following Z ^~ ustands- table Tl:

The first five lines after the header affect the automation part and correspond to the Diameter Protocol according to Draft or according to the future de facto standard. The authorization part is realized with state notation. The other states of the authorization part also correspond to the Diameter protocol, but are not shown here for reasons of clarity, see section 8.1 of the draft.

The last five lines refer to the billing part and are similar to the determinations made so far in the Diameter protocol. However, instead of the state "Idle", the state "Open" is used. The charging part is realized without notice of states.

The state machine 12 operates according to the following state table T2:

The first seven lines after the header are for the authorization part and correspond to the Diameter protocol according to Draft or according to the future de facto standard. The authorization part is realized with state notation. The other states of the authorization part also correspond to the Diameter protocol, but are not shown here for reasons of clarity, see section 8.1 of the draft.

The last five lines refer to the billing part and are similar to the determinations made so far in the Diameter protocol. However, instead of the state "Idle", the state "Open" is used. The charging part is realized with notice of states. Apart from the line with the event "Client or device requests one-off service", only the lines for the state PendingE are included in the state machine. The following procedure was used to unify the state authorizations without limitation by the specified sequence: 1. For the accounting application, the "stateless accounting server" (Acc-SSL) is used in accordance with Chapter 8.2 of the Draft Protocol. 2. Considering the event method ("client or device asks for a single service") is used for the accounting application according to chapter 8.2 of the Draft for the Diameter Protocol of state machine "client, stateful accounting" (Acc-CSF) used. 3. The portion of the state machine <Acc SSIJ> designated in 1 is embedded in the state "Open" of the authorization state machine "Server, statefull" (Auth-SSF) of Chapter 8.1 of the Draft for the Diameter Protocol. 4. The portion of the state machine <Acc-CSIT> designated in 2 is embedded in the state "Open" of the authorization state machine "Client, statefull" (Auth-CSF) of Chapter 8.1 of the Draft for the Diameter Protocol. 5. In the "Open" state of the authorization application (client and server side), the accounting application is used with the control codes Accounting Request (ACR - Accounting Request) and Accounting Response (ACA).

FIG. 2 shows a second variant with a combined state machine 20 on the server side and with a unified state machine 22 on the client side. Between both state machines messages are transmitted according to Diameter protocol via an interface 24 between different network elements.

The state machine 20 operates according to the following state table T3:

The table for the state machine 20 indicates the complete state machine. The first line after the header concerns the authorization part and corresponds to the Diameter protocol according to Draft or according to the future de facto standard. The authorization part is realized without noting states.

The last five lines refer to the billing part and agree with the definitions made so far in the Diameter Protocol. The charging part is realized without notice of states.

The state machine 22 operates according to the following transaction table T4:

The first five lines after the header are for the authorization part and correspond to the Diameter protocol Draft or according to the future de facto standard. The authorization part is realized without noting states. The other states of the authorization part also correspond to the Diameter protocol, but are not shown here for reasons of clarity, see section 8.1 of the draft.

The last five lines refer to the accounting part and are similar to the determinations made so far in the Diameter protocol. However, instead of the state "Idle", the state "Open" is used. The charging part is realized with notice of states. Except for the line with the event "Client or device asks one-time service", only the lines for the state PendingE have been included in the state machine.

The procedure was as follows in uniting the state machines without limitation by the order given:

1. For the accounting application, the state machine "Server, Stateless Accounting" (Acc-SSL) is used in accordance with Chapter 8.2 of the Diameter Protocol Draft.

2. Taking account of the event method ("client or device requests one-off service"), the state machine "client, stateful accounting" (Acc-CSF) is used for the accounting application in accordance with chapter 8.2 of the draft for the Diameter protocol.

3. The portion of the state machine (Acc-SSL) identified in 1. is embedded in the Idle state of the server stateless (Auth-SSL) state of Chapter 8.1 of the Diameter Protocol Draft.

4. The portion of the state machine (Acc-CSF) designated in 2 is embedded in the state "Open" of the Authorization State Machine "Client, stateless" (Auth-CSL) of Chapter 8.1 of the Diameter Protocol Draft. 5. In the "open" state of the authorization application (client and server side), the accounting application is the accounting request (ACR) and the accounting answer (ACA).

Figure 3 shows a unified state machine 30 on the server side and separate state machines 32 and 34 on the client side. State machine 30 is consistent with state machine 10. The state machine 32 for the authorization client agrees with the state machine Auth-CSL described in the Diameter Draft, Chapter 8.1. The state machine 34 for the billing client agrees with that in the Diameter Draft, chapter. 8.2, state machine Acc-CSL.

Between the state machines 30 and 32 there is an interface 36. Between the state machines 30 and 34 there is another interface 38. Messages are transmitted via the interfaces 36 and 38 in accordance with the Diameter protocol.

In another embodiment, the state machine 30 matches the state machine 20. In place of the state machine 32, a state machine with states of states for the authorization client can also be used. In place of state machine 34, a state machine may be used without noting conditions for the billing client.

Figure 4 shows separate state machines 40 and 42 on the server side and a unified state machine 44 on the client side. The state machine 40 for the authorization server agrees with that in the Diameter Draft, Chapter. 8.1, described state machine Auth SSL match. The Ztx stand automaton 42 for the billing server agrees with that in the Diameter Draft, chapter. 8.2, described in Stata.automaten Acc-SSL.

The state machine 44 is similar to the state machine 12. Between the state machines 40 and 44 is an interface le 46. Between the state machines 42 and 44 there is another interface 48 between different network relays. Via the interfaces 36 and 38 messages are transmitted according to Diameter protocol.

In another embodiment, stateant 44 is constructed like state machine 22. State machines 40 and 42 may operate in any combination with or without state notation.

For all variants explained with reference to FIGS. 1 to 4:

1. The session IDs for the accounting and authoriza- tion application are identical for the unified state machines.

2. The concept of the sub-session ID in the accounting application is supported, for example if different applications in a session require different billing.

3. The supervision of the granted credit, i. the Bndget Control) is performed in the server.

4. due to a missing budget (Accounting Initiation Termination) or at the end of an authorization (Authorization Initiated Termination), the server can terminate a SIP session by sending an Abort Session Request message (ASR) _r causing the client easy to set up.

5. The expiration of an authorization is not affected by the unified state machine.

6. In the "Open" or "Idle" state, accounting or linking operations can be performed.

FIG. 5 shows the message flow for authorization and billing in the combined state machine 30 on the server side and separate state machines on the client side. A prepaid charging will be explained. The timers for waiting for messages are not shown. 5, a terminal 50 of an A-subscriber, a connection control control unit 52 containing the state machine 32, eg an S-CSCF unit (Call State Control Function), an application server 54 containing the state machine 54, and the authorization / Billing unit 30, which contains an Online Charging Function (OSC) for online charging and a Charging Collection Function (CCF) for offline charging.

The terminal 50 operates in accordance with the SIP protocol and serves the

Transmission of signaling messages and payload data in a data packet transmission network, e.g. on the Internet or a 3GPP network, in particular in a UMTS network (Universal Mobile Telecommunications System). The connection control unit 52 likewise operates in accordance with the SIP protocol and serves for connection control during the transmission of data from and to the terminal 50. The application server 54 likewise operates in accordance with the SIP protocol (RFC3216) and provides a service which is usually subject to a fee. for example, watching, buying or renting videos.

At a time t0, the A-subscriber wants to establish a connection from his terminal 50 to the application server 54 in order to see the image data of a video. For this purpose, an INVITE message 60 is generated in the terminal 50 and transmitted to the control unit 52. The control unit 52 processes the INVITE message in accordance with the SIP protocol. At a time t2, the control unit 52 sends an authorization request message 62 to the state machine 30. The message 62 is addressed in the Diameter protocol. The content of message 62, however, depends on the application. In the exemplary embodiment, the message 62 contains inter alia:

a session ID that uniquely identifies the connection to be established, and a user identifier that uniquely identifies the A-subscriber,

- the desired service, and - If necessary, a desired payment method, if the payment method does not already result from the service.

The message 62 is processed by the state machine 30, see state table Tl first line. It is checked whether the A-subscriber is authorized for billing, see step 64. This is the case in the embodiment. Therefore, in a following method step 66, the charging type is set, e.g. Prepaid. In a method step 68 it is checked whether the cash credit of the A-

Participant has a minimum value. In a next method step 70, a reservation of a minimum sum for the service "watch video" can be made.

Thereafter, at a time t4, an authorization

Response message 72 generated in the embodiment u.a. the following data fields or AVPs (Attribute Value Pairs) contain:

- Session ID, - Authorization duration,

- Authorization meeting state.

The message 72 is transmitted from the network element with the state machine 30 to the control unit 52 and processed there. According to the Diameter protocol, the requested service is made available, for which purpose an INVITE message 74 is sent from the control unit 52 to the application server 54 in accordance with the SIP protocol at a time t6.

The INVITE message 74 is processed in the application server in accordance with the SIP protocol and answered with an acknowledgment message 76 at a time t8. The acknowledgment message 76 is also referred to as a 200θK message. The confirmation message 76 is transmitted from the application server 54 to the control unit 52. The control unit 76 generates after receiving the confirmation message 76 at a time t10 according to the SIP protocol an acknowledgment message 78 to the side of the terminal 50 out. Thereafter, a SIP session 80 is established between the terminal 50 and the application server 54, in the course of which video data are transmitted from the application server to the terminal 50 via the data packet transmission network. The SIP session 80 has a Call ID (identifier) that must be correlated with the Session ID specified in the message 62.

At a time t12, the application server 54 then sends a Diameter billing request after the establishment of the SIP session 80 but before the start of the transmission of the video data via an RTP (Real Time Protocol) or a UDP (User Datagram Protocol) session Message 82 to the state machine 30. The message 82 is also referred to as an accounting request message. The message 82 contains, inter alia:

the session identifier or the session ID, and

an event_record in which, for example, "one time request" is specified.

According to state table T1, line 7, the message 82 is processed by the state machine 30, wherein a timer for the budget control is started in a method step 84. In addition, a Diameter Charge Response message 86 is sent to the application server 54 by the state machine 30 at a time tl4. The message 86 also contains u.a. :

- the session ID, and

- an event record.

The application server 54 processes the message 86 and begins sending the video data.

At a certain point in time and during the transmission of the video data, the budget bucket expires, process step 86. Thereafter, the state machine 30 according to state table T2, line 3, generates at a time t 16 a Diameter Cancel Session Request message 90, also called abortion Session request message (ASR) is called. The message 90 also contains, inter alia, the session ID and wi_rd transmitted to the control unit 52.

The control unit 52 generates according to SIP protocol on the basis of the message 90 at a time tl8 Endacnricht 92 for the terminal 50. The end message 92 is also referred to as a BYE message. Based on the message 90, the control unit 52 also generates a SIP end message 94 for the application server 54 at a subsequent time t20.

Due to the end messages 92 and 94, the SIP session is terminated. Thereafter, the control unit 52 generates to a. At time t22, a Diameter Cancel Session Response Message 98, also referred to as the Abort Session Answer Message (ASA), is called. The message 98 is transmitted to the state machine 30 and processed there according to Diameter protocol. Message 98 contains, among others:

- the session ID, and - a result code.

In another embodiment, another amount is deducted to prevent premature interruption of the ^" video transmission." In a next embodiment, a telephony connection, in particular a video telephony connection, is set up and charged between the terminals of two users in the control unit, a state machine 12 or 22 used.

In further embodiments, the termination is, for example, caused by the A-subscriber or by another event.

FIG. 6 shows a server unit 100 with a combined state machine 10, 20 or 30. The server unit 100 contains: a memory unit 102,

a receiving unit 104, which may receive an authorization message 62 and a charging message 82, a checking unit 106 which can check the authorization of the user for the data transmission depending on the content of the authorization message, and

a billing unit 108 that can change or generate a billing date depending on the content of the authorization message.

If appropriate, the server unit 100 also contains further units for carrying out the method explained above with reference to FIG. 5.

In a first alternative, server unit 100 does not include a processor executing a program. The units 104 to 110 include circuits that are hardwired. In an alternative variant, the functions of

However, units 104 to 110 are provided by a processor 112 upon execution of a program stored in memory 102.

In one embodiment, all of the units 104 through 210 access the memory 102 to perform their functions, see arrows 114.

FIG. 7 shows functional units of a client unit 150 with a / cleaned state machine, e.g. 12 or 22. The CL.Unit 150 contains:

A memory unit 152 for storing data records,

A generating unit 154 capable of generating an authorization message 62 and a charging message 82, and a transmitting unit 156 for transmitting the messages.

The generating unit 154 accesses the same data record in the memory unit 152 when generating the authorization message and generating the billing message.

Optionally, the client unit 150 contains more

Units 158, for example, the functions of a combined supply Stand automation for authorization and billing to provide.

In a first alternative, the client unit 150 does not include a processor executing a program. Units 154 through 158 contain circuits that are hardwired. In an alternative variant, however, the functions of the units 154 to 156 are provided by a processor 160 when processing a program stored in the memory 152.

In one embodiment, all of the units 154-158 access the memory 152 to perform their functions.

FIG. 8 shows a server network element 200 with two separate state machines 202 and 204 for the authorization server and for the charging server and a client network element 210 with two separate state machines 212 and 214 for the authorization client and the charging client, respectively. The state machines are each components of different application programs.

Between the state machines 200 and 204, an adjustment is performed via an internal interface 220 of the network element 200. Likewise, an alignment or a correlation is performed between the state machines 212 and 214 via an internal interface 222 of the Metzelementes 210.

Between the two network elements 200 and 210 there is a magnetic interface 230, which is realized in particular by a single physical interface. The applications with the state machines 202, 204, 212 and 214 are, for example, accessible via different session identifiers (session 1D), see arrows 240 and 252 for the server side and arrows 250 and 252 for the client side. The network element 210 has an SLP interface 260, for example to a subscriber terminal.

Claims

claims

1. A method of charging in a data transmission network, wherein the following method steps are performed without limitation by the specified order:

Generating an authorization message (62) containing at least one access date identifying a data transmission in the communication network and at least one user identifier indicating the user of the data transmission, transmitting the authorization message (62) to at least one service providing computer (30) via the data transmission network;

Checking the authorization of the user for the data transmission depending on the content of the authorization message (62) transmitted to the service providing computer (30),

Generating a billing message (82) containing the access tag and serving for billing the data transmission or the transmitted data, transmitting the billing message (82) to the service delivery computer (30),

Changing or generating a billing date depending on the content of the billing message (82) transmitted to the service provider computer (30).

2. The method according to claim 1, characterized in that depending on the authorization message (62) preparations (66 to 70) are made for the billing, in particular before the confirmation (72) of the authorization message, the preparations preferably a check (68) of the Account balance of the user and / or a reservation (70) of an amount.

3. The method according to claim 1, characterized in that the same record is accessed when checking the authorization and when charging.

4. The method according to claim 3, characterized in that in the data record a state data is stored, which indicates a subsequent state for the processing of the next message with respect to the access flag or with the aid of which such a subsequent state can be determined.

5. Method according to one of the preceding claims, characterized in that the processing of the authorization message (62) and the processing of the charging message (82) are performed by the same state machine, wherein the state machine can assume at least two states in which the arrival is waited for messages, and wherein the state machine is preferably on arrival and / or immediately after, the processing of the two messages in the same state.

6. The method according to claim 5, characterized in that the same state is the state "open" in accordance with the Diameter protocol or according to a protocol based on this protocol, whereby preferably in place of the state provided in the Diameter protocol "Idle" with respect to Billing the state "Open" is used.

7. Method according to one of the preceding claims, characterized in that the processing of the authorization message (62) and the processing of the charging message (82) are carried out by the same state machine, wherein the state machine, on the arrival of a message from a basic state, executes the Message is processed and then returned to the default state to wait for the arrival of further messages.

8th . The method of claim 7, wherein the ground state is the state "idle" according to the Diameter protocol or according to a protocol based on this protocol.

9. Method according to one of the preceding claims, characterized in that the processing of the authorization message (62) and the processing of the charging message (82) are carried out by the service providing computer (30) or by service provision computers of a distributed system, and / or the processing of the messages (62, 82) is carried out when a single program is executed.

10. A method for charging in a data transmission network, wherein the following method steps are executed without limitation by the specified sequence: generating an authorization message (62) which comprises at least one access data item that indicates a data transmission in the data transmission network and at least one user identifier containing the user of the data transmission, sending the authorization message (62) from a service use computer (52) via the data transmission network, generating a billing message (82) containing the access identifier, and billing the data transmission or the transmitted data serving, sending the billing message (82) from the service usage calculator (52) over the communication network, accessing the same record upon generation of the authorization message (62) and the billing message (82).

11. The method according to claim 10, characterized in that in the record a status data is stored, which is a subsequent state for the processing of the next message with respect to the access identifier indicates or by means of which such a subsequent state can be determined.

12. Method according to claim 10 or 11, characterized in that the generation of the authorization message (62) and the generation of the charging message (82) are carried out by the same state machine, wherein the state machine can assume at least two states in which the arrival of messages is awaited and, preferably, the state machine each waits in the same state just prior to generating the two messages, and preferably, the state machine returns to the same state immediately after the two messages have been generated.

13. Method according to claim 12, characterized in that the same state is the state "Open" according to the Diameter protocol or according to a protocol based on this protocol, wherein preferably in place of the state provided in the Diameter protocol "Idle" with respect to the charge the state "Open" is used, and wherein preferably only the state "PendingE" is adopted for the billing part of the state machine.

14. Method according to claim 12 or 13, characterized in that the part of the state machine responsible for the authorization stores the subsequent state or a date in the data record from which the subsequent state can be determined, and that the part responsible for the authorization Billing responsible part of the state machine also stores the next state or a date in the record from which the subsequent state can be determined.

15. The method according to any one of claims 10 to 13, characterized in that the competent for the authorization part of the state machine stores no subsequent state or a date in the record from which the subsequent state can be determined, and that responsible for the billing part of On the other hand, state machines store the subsequent state or a date in the data record from which the subsequent state can be determined.

16. The method according to claim 10, characterized in that the generation of the authorization message and the generation of the billing message are performed by the service providing computer or service delivery computers of a distributed system, and / or that the generation of the two messages in the Execution of a single program is performed.

17. Method according to one of the preceding claims, characterized in that a connection setup message (60) is generated and transmitted via the data transmission network and that the connection setup message (60) is processed according to the protocol before transmitting the authorization message (62) or that the connection setup message is processed according to the protocol only after receiving a response message (72) for the authorization message (62).

18. Unit (100) for charging in a data transmission network, in particular for carrying out the method according to one of the preceding claims, having a receiving unit (104) which can receive an authorization message (62) and a charging message (82), wherein the authorization message (62 ) at least one access date, which is a data transfer in the data transfer and the at least one user identifier indicating the user of the data transmission, and wherein the billing message (82) is for billing the data transmission or the transmitted data, with a check unit (106) which determines the authorization of the user for the data transmission Content of the authorization message (62), and a charging unit (108) that can change or generate a charging date depending on the content of the authorization message (82).

A unit (150) for charging in a communications network, in particular for carrying out the method according to any one of claims 10 to 16, comprising a generating unit (154) capable of generating an authorization message (62) and a charging message (82), the authorization message (62) at least one access date, which identifies a data transmission in the data transmission network, and contains at least one user identifier that indicates the user of the data transmission, and wherein the billing message (82) is used to charge the data transmission or the transmitted data, and with a A memory unit (152) for storing records, wherein the generating unit (154) accesses the same record when generating the permission message (62) and generating the billing message (82).