EP1665630A1

EP1665630A1 - Charging method and charging units

Info

Publication number: EP1665630A1
Application number: EP04766566A
Authority: EP
Inventors: Frank Burghardt; Andreas Kanbach; Peter Kim
Original assignee: Siemens AG; Nokia Siemens Networks GmbH and Co KG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2003-09-15
Filing date: 2004-08-20
Publication date: 2006-06-07
Also published as: KR20060076298A; US20070103117A1; DE10342558A1; JP2007506314A; WO2005027406A1; CN1853368A

Abstract

The invention relates to, among other things, a method in which the following method steps are executed: storing a charge data record with a charge date in a network element (24) of a data transmission network; transmitting a service request message (82) for the use of a service by the user; allocating a service termination date for the user according to the service request message (82); changing the termination date according to the use of the service in the network element (24), and; determining the end of the service according to the service termination date in the network element (62). The method is simple and offers numerous advantages.

Description

description

Procedures for charging and charging units

The invention relates to a method for charging, in which the following method steps are carried out:

storing in a network element of a data transmission network a fee data record with a fee date which indicates the account balance of a fee account of a user who transmits user data via the data transmission network,

Transmitting a service request message for the use of a service by the user,

assigning a service termination date to the user depending on the service request message, the service termination date setting a limit on the use of the service and the value of the fee date being changed,

- Change the termination date depending on the use of the service.

The data transmission network is in particular a data packet transmission network, in particular the Internet or a 3GPP network (third generation partnership program), in particular a UMTS network (Universal Mobile Telecommunication System). In a data packet header, a destination address is saved. The user data is located in a data packet call.

A charging procedure is b> spw. in the standards of the 3GPP group (explained in the third generation), which are published, for example, on the Internet at ftp://ftp.3gpp.org/specs/archive, especially in the standards:

- 3GPP TS 32.200, 3GPP, Technical Specification Group Service and System Aspects, Telecommunication Management, Charging Management, Charging principles,

- 3GPP TS 32.225, 3GPP, Technical- Specification Group Service and System Aspects, Telecommunication Management, Charging

Management, Charging Data Description for the IP-Multimedia Subsystems (IMS). A suitable protocol is the Diameter Base Protocol, which is an extension of the RADIUS protocol (Remote Authentication Dial In User Service) and is referred to below as the Diameter Protocol. The Diameter protocol is still in de facto standardization and is available as a draft or later as a draft on the website (www.ietf.org) of the IETF (Internet Engineering Task Force). Both protocols are so-called AAA protocols (Authentication, Authorization, Accounting).

It is an object of the invention to provide a simple method for charging which can be carried out in particular with simply structured programs and which uses in particular existing standards or standards which are currently being standardized. In addition, simply structured charging units should be specified.

The object related to the method is achieved by a method with the method steps specified in claim 1. Further developments are specified in the subclaims.

In the process according to the invention, the following process steps are carried out in addition to the process steps mentioned at the beginning:

- Change the termination date depending on the use of the service in the network element that also takes over the account management and not as previously in another network element, and - Determining the end of the service depending on the service termination date also in the network element.

The invention is based in particular on the following considerations. In second generation mobile radio networks, ie in particular in the European GSM network (Global System Mobile), authorized mobile radio customers can without a fixed contractual relationship between the mobile radio network operator and the Customers use various services, such as voice services or SMS (Short Massage Service), if the payment of the desired service is guaranteed before the service is carried out. The amount of money can be debited or reserved directly from the customer's credit account. The so-called prepaid customers can monitor the costs at any time. However, budget control takes place in a different network element than the credit account management.

In second generation mobile networks, the services offered are either time-based, e.g. with voice telephony, or charged for after events, e.g. with SMS. Parcel services, e.g. MMS (Multimedia Message Service) in mobile networks of the 2.5th generation can also be billed according to volume, e.g. in kilobytes. The GPRS (Global Paket Radio Service) service is used in particular.

3rd generation mobile phone networks, in particular UMTS networks (Universal Mobile Telecommunication Service) are not only designed for voice and variable data streams, but also allow the customer to use multimedia services. The charging for the use of multimedia services is very complex and has not yet been satisfactorily resolved. Various charging models should be available for online charging and offline charging. However, in particular the time-based charging in third generation mobile radio networks is currently only possible with a very high technical outlay, so that a simple and inexpensive method has to be found. An essential feature of such a procedure should be a monitoring of the allocated budget, ie the credit at the time a service is carried out. This property is also referred to as budget control and can be implemented in various network elements, particularly with the IP (Internet Protocol) multimedia subsystem (IMS). No budget control is required for offline charging. Previously, the charging method with charging messages had to be transmitted to the network elements, for example via an address of the Event Charging Function (ECF) contained in the OCS or CCF, which is part of a so-called OCS (Online Charging System).

On the other hand, the method according to the invention enables the selection of the charging method to be left to the OCS or a CCF (Charging Collection Function) for offline charging.

The Diameter Protocol is particularly suitable as a suitable protocol for the authorization message and the charging message. So far, however, only the accounting part of this protocol has been used in connection with charging. For example. However, the inclusion of the authorization part in the charging results in numerous advantages. In particular, charging can be stopped from a charging server. The accounting section has not yet offered such a possibility. The authorization part can be embedded in the accounting part. Alternatively, the accounting part, for example of the diameter protocol, can be embedded in the authorization part of this protocol.

By combining account management and budget control, especially using the Diameter protocol, the following advantages result:

- The core network elements involved no longer need to know the charging method. The selection of the charging method is left to the charging function, i.e. for example the OCS or the CCF.

- Due to the local or topological proximity of the network elements to the OCS or CCF, high time accuracy can be achieved for the time-based charging methods. - Since there is no additional exchange of reservation messages via the network, the granularity of the reservation vation, ie the time or volume interval, can be as small as desired without excessively influencing the network performance.

- Significant reduction in the implementation effort in the network element and in the OCS / CCF. - Increased reliability due to the simplified procedures.

- Standardization of the protocols for the online and offline charging process.

- The procedure is independent of the access network, e.g. GPRS, UMTS, Bluetooth, WLAN IEEE 802.11.

- The Diameter Base protocol does not have to - but - can be expanded. The log can be reduced to a few messages. As a result, commercially available network nodes can be used for various charging methods. - New charging methods can be introduced easily because only changes in the OCS / CCF are required.

In a further development of the method according to the invention, an authorization message is used to prepare the charging or when the charging ends. Alternatively, the authorization messages are used both to prepare the charge and to end the authorization.

In another development, the authorization message contains a user identifier that indicates the user of the data transmission. Depending on the user identifier, the authorization or authorization of the user for data transmission is checked. On the basis of the authorization message and / or depending on the content of the authorization message, a fee type and / or a billing type is also selected.

In a next development, a reservation of a fee amount or a fee time is made on the basis of the authorization message and / or depending on the content of the authorization message. Additionally or alternatively, when editing the authorization message, a Record for the charge is generated. The authorization message is thus used in an unchanged format for additional purposes compared to the previous use.

In another development, the authorization message is transmitted before the preparation of the data transmission is completed, so that a secure procedure against misuse arises. Alternatively, the authorization message is transmitted after the preparation of the data transmission has been completed, so that user data, e.g. Voice data and / or video data can be transmitted.

In a further development, the authorization message fulfills the requirements of the diameter protocol or a protocol based on it. The authorization message is processed in particular in accordance with the diameter protocol or in accordance with a protocol based on this protocol. The specific structure of the authorization message is not specified in the diameter protocol and depends on the application in question.

In a further development, the authorization message used when terminating is an abort message which leads to the abort of the user data transmission, in particular the abort session request message of the diameter protocol or a protocol based thereon.

In an alternative development, the service request message contains a user identifier that indicates the user of the data transmission. Depending on the user identifier, the authorization of the user for data transmission is checked, so that no separate authorization message has to be sent for this purpose. In addition, a charging type and / or a billing type is selected in particular in accordance with the actual purpose of the charging message.

In another development, the charge is an online charge that affects the transmission of user data can. The monitoring of the charge is carried out in a service provider computer which is provided in addition to a service provider computer which controls the data transmission.

In another development, the same service request messages are transmitted for online charging and for offline charging, in particular messages with the same message identifier. Account request message in accordance with the diameter protocol is preferably used, the same account record type preferably being used in both messages, in particular an EVENT_RECORD. This creates a simple procedure in which the same messages are used for several charging methods. The method of charging does not have to be known or determined in the tax calculator.

The invention also relates to a server billing unit and a client billing unit, in particular with units for carrying out the method steps of the method according to the invention or one of its developments. The technical effects mentioned above also apply to the fee units.

The invention is explained below with reference to the accompanying drawings. FIG. 1 shows functional units for signaling data transmission and for billing, FIG. 2 shows the message flow for a SIP session with online billing, with authorization before the data transmission possibility is set up and with triggering by a terminal, FIG. 3 shows the message flow for a SIP -Session online billing, with authorization after setting up the data transmission option and with triggering by a fee calculator, FIG. 4 shows part of the message flow of a SIP session online billing, triggered by a control unit for controlling the data transmission,

FIG. 5 the message flow of a SIP session with offline charging,

Figure 6 functional units of a server unit, which is used for charging, and

Figure 7 functional units of a client unit, which is used for charging.

FIG. 1 shows functional units of a data transmission network 10 for signaling data transmission and for charging. A terminal 12 is connected via an access network 14. The access network 14 leads via a GPRS unit 16 (Global Packet Radio Service) to an IP multimedia subsystem 18 (IMS).

The GPRS unit contains an SGSN unit 20 (serving GPRS service node) and a GGSN unit (gateway GPRS service node) 22, the functions of which are explained in particular in the 3GPP TS 32.200 standard.

The subsystem 18 contains an OCS / CCF unit or an authorization / charging unit 24 and a control unit 26, in particular a P-CSCF (Proxy Call Session Control Function) or an S-CSCF (Serving Call Session Control Function). Subsystem 18 also includes an application server 28, e.g. a video server, an MRF unit (Media Resource Function) or an MRFC unit (Media Resource Function Controller).

So that both the S-CSCF 26 and other network elements can be kept as simple as possible, the budget control function BC: 1. the online charging system (OCS) and

2. assigned to the Charging Collection Function (CCF) of the offline charging system. The OCS and the CCF are not necessarily assigned to a common network element. As a result of the further development of charging methods, ie convergent charging, offline charging is carried out similarly to online charging.

The diameter base protocol is used between the OCS / CCF and the control unit 26 or the unit 28, as explained below with reference to FIGS. 2 to 5. This means that the standardized interfaces Ro (online) and Rf (offline) are already more similar to one another than originally intended. The messages used in the following scenarios can be represented by the following commands of the Diameter Base protocol:

The following applies to all scenarios: - The budget control function BC is positioned on the OCS and the CCF. - The authorization protocol of the Diameter protocol is used for the time-based charging of multimedia services. - The authorization protocol is used in combination with the accounting protocol (Event__Method). Thus, originally independent parts of the Diameter Base protocol are used to charge multimedia services with optional credit reservation, in particular in accordance with the Diameter extension for credit control applications. - Mapping rules for controlling a SIP session using diameter messages are given.

In the following, the SIP messages in particular are not shown with all data fields and in all detail. The attribute-value pairs of the messages of the Diameter Base Protocol (DBP) are also not fully explained.

FIG. 2 shows the message flow for a SIP session with online billing (prepaid), with authorization before the data transmission option is set up, and with triggering by a terminal. A prepaid fee is explained. The timers for waiting for messages are not shown.

In Figure 2 there is a terminal 50 of an A-subscriber, a connection control control unit 52, e.g. an S-CSCF

Unit (Call State Control Function), a terminal 54 and the authorization / charging unit 24 shown, which contains an online charging function (OSC) for online charging and a charging collection function (CCF) for offline charging. The terminal 50 operates according to the SIP protocol and is used to transmit multimedia data (for example audio and video data), in particular voice data, in the data packet transmission network 10, for example on the Internet or in 3GPP networks. The connection control unit 52 also works in accordance with the SIP protocol and serves to control the connection when transmitting data from and to the terminal 50.

The terminal 54 is also used for voice transmission or the transmission of multimedia data. Instead of the terminal, an application server 54 can also be used, which also works according to the SIP protocol (RFC3261) and provides a service, for example viewing, buying or renting videos. In another exemplary embodiment, a multimedia resource function control unit (MRFC) or an MRF takes the place of the application server 54.

At a time tO, the A subscriber wants to set up a connection from his terminal 50 to the B subscriber's terminal 54 in order to make calls. 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 t1, the control unit 52 sends a SIP INVITE message 61 to the terminal 54. The SIP messages 61, 76, 94 can also be routed to the terminal 54 via a number of control units 52.

At a time t2, the control unit 52 sends an authorization request message 62 to the authorization / charging unit 24. The message 62 is in the diameter

Protocol addressed. However, the content of message 62 depends on the application. In the exemplary embodiment, message 62 contains, inter alia:

a session ID which uniquely identifies the signaling connection to be set up, and

- a user identifier that uniquely identifies the A subscriber, - the service requested, and

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

The INVITE message is therefore 60 trigger point for the authorization or for the preparation of the charge.

The message 62 is processed by the authorization / charging unit 24. It is checked whether the A subscriber is authorized, see method step 64. This is the case in the exemplary embodiment. Therefore, the method of charging is determined in a subsequent step 66, e.g. Prepaid. In a method step 68, it is checked whether the A participant's cash balance has a minimum value. In a next method step 70, a minimum sum is reserved, for example, for the "voice telephony" service.

An authorization response message 72 is then generated at a time t4, which in the exemplary embodiment includes contains the following data fields or AVPs (Attribute Value Pairs):

- session ID,

- authorization period,

- Authorization session state.

The message 72 is transmitted from the network element with the authorization / charging unit 24 to the control unit 52 and processed there. The requested service is permitted in accordance with the Diameter Protocol.

The INVITE message 61 is processed in the application server 54 in accordance with the SIP protocol and answered with a confirmation message 76 at a time t8. The confirmation 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 at a time after receipt of the confirmation message 76 tlO a confirmation message 78 to the side of the terminal 50 according to the SIP protocol.

A SIP session 80 has then been set up between the terminal 50 and the application server 54. Via a UDP (User Datagram Protocol) or RTP connection (Real Time Protocol), i.a. Transfer voice data between the terminals 50 and 54. The user data transmission connection belonging to the SIP session 80 has a call ID (identifier) which has to be correlated with the session ID specified in the message 62.

At a time tl2, the control unit 52 sends a diameter charge request message 82 to the authorization / charge unit 24 after the establishment of the SIP session 80 or the user data transmission connection (RTP / UDP). The message 82 is also used as accounting -Request message referred. The message 82 contains, among other things: the session identifier or the session ID and the accountign record type Event_Record.

The message 82 is processed by the authorization / charging unit 24, a timer for the budget control being started in a method step 84. In addition, the authorization / charging unit 24 sends a diameter charging response message 86 to the control unit 52 at a time t14. Message 86 also includes the session ID.

The control unit 52 processes the message 86 and permits the transmission of the voice data.

At a time tl8, subscriber A ends the call, an end message 92 being generated in his terminal 50 and being sent to control unit 52. The control unit 52 uses the message 92 to generate a session end request message 90, which according to the diameter protocol is also used as a session Termination request message (STR) is called and was actually not intended to terminate the charge.

However, in the exemplary embodiment explained, the message 90 is sent to the authorization / charging unit 24 and is used here to end the charging. On the basis of message 90, the charge timer is stopped and any remaining credit, if any, is credited to the account of subscriber A.

At a time t20, the control unit 52 generates an end message 94 in accordance with the SIP protocol. The end message 94 is transmitted to the terminal 54 and processed there in accordance with the SIP protocol. The SIP session or the SIP session is ended in a subsequent method step 96.

After the billing timer stops, the authorization / billing unit 24 sends a session end response message 98 at a time t22, which is also called a session

Termination Answer Message (STA) is called and according to the Diameter Protocol only in the context of a de-autoπsierung and not as used here in connection with the end of the charge.

In another exemplary embodiment, the method explained with reference to FIG. 2 is ended as it is explained below for FIGS. 3 and 4.

FIG. 3 shows the message flow for a SIP session online billing (prepaid), with authorization after the data transmission option has been set up, and triggered by a billing computer.

At a time t50, the A subscriber wants to establish a connection from his terminal 50 to the B subscriber's terminal 54 in order to make calls. For this an INVITE message 150 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 t52, the control unit 52 sends a SIP INVITE message 152 to the terminal 54. The terminal 54 processes the message 152 in accordance with the SIP protocol and sends a confirmation message 154 at a time t54, which is also referred to as a 200θK message. The confirmation message 154 is transmitted from the terminal 54 to the control unit 52. After receiving the confirmation message 154 at a time t56, the control unit 52 generates a confirmation message 156 for the terminal 50 in accordance with the SIP protocol.

A SIP session 80 is then set up between the terminal 50 and the terminal 54. In addition, Transfer voice data between the terminals 50 and 54. The SIP session 80 has a session ID (identifier), which is required below.

At a time t102, the control unit 52 sends an authorization request message 162 to the authorization / charging unit 24. The message 162 corresponds to the message 62. In contrast to FIG. 2, this is not an INVITE message but the confirmation message 154 as a trigger point for authorization or for preparations for charging.

The message 162 is processed by the authorization / charging unit 24. It is checked whether the A-subscriber is authorized, see procedural step

164. This is the case in the exemplary embodiment. Therefore, in a subsequent step 166, the type of charging is determined, e.g. Prepaid. In a method step 168, a check is carried out to determine whether the A participant's cash balance has a minimum value. In a next step 170

Reservation of a minimum sum for the "voice telephony" service carried out. An authorization response message 172 corresponding to message 72 is then generated at a time t104.

The message 172 is transmitted from the network element with the authorization / charging unit 24 to the control unit 52 and processed there. The requested service is permitted in accordance with the Diameter Protocol.

At a time tll2, after processing the message 172, the control unit 52 sends a diameter charge request message 182 to the authorization / charge unit 24. The message 182 corresponds to the message 82. Since the messages correspond, they have the same data fields and same functions.

The message 182 is processed by the authorization / charging unit 24, a timer for the budget control being started in a method step 184. In addition, the authorization / charging unit 24 sends a diameter charging response message 186 to the control unit 52 at a time tll4. Message 186 also includes the session ID.

The control unit 52 processes the message 186 and permits the transmission of the voice data.

The budget timer expires at a certain point in time, see method step 188. the budget granted to participant A has been used up. The authorization / charging unit 24 then generates a diameter abort session request message 190 at a time tllδ, which is also referred to as an abort session request message (ASR). The message 190 also contains the session ID and is transmitted to the control unit 52. The control unit 52 generates an end message 192 for the terminal 50 based on the message 190 at a time t11β according to the SIP protocol. The end message 192 is also referred to as a BYE message. On the basis of the message 190, the control unit 52 also generates a SIP end message 194 for the terminal 54 at a subsequent time tl20. The receipt of the message 190 is thus the criterion for triggering the SIP session on both sides.

The SIP session is ended on the basis of the end messages 192 and 194, see method step 196. The control unit 52 then generates a parameter termination session response message 98 at a time tl22, which is also an abort session answer message (ASA ) referred to as. The message 198 is transmitted to the authorization / charging unit 24 and processed there according to the diameter protocol. Message 198 includes, among other things:

- the session ID, and

- a result code.

In another exemplary embodiment, the SIP session according to FIG. 2 or according to FIG. 3 is ended.

The choice of trigger points according to FIG. 1 or FIG. 2 is independent of the charging method or the debiting method, prepaid or postpaid.

FIG. 4 shows part of the message flow of a SIP session online billing (prepaid), triggered by a control unit for controlling the data transmission.

The part of the method according to FIG. 3 going up to method step 160 is carried out up to method step 260. Alternatively, up to a method step 280 corresponding to method step 280, the part of the method according to FIG. 2 going to method step 80 is carried out. In process steps 260 and 280, therefore, the Preparations for data transfer completed as part of a SIP session.

At a point in time t212 following method step 260 or 280, the control unit generates a message 282 which corresponds to message 82 or 182. When the message 282 is processed in the unit 24, the billing time counter (timer) is started. A message 286 is then generated which corresponds to message 86 or 186.

After receiving and processing message 286, an unexpected SIP session error 285 occurs. The following unexpected SIP session errors are possible, for example: - Operator blocks the A subscriber via the Cx interface, which is provided between the HSS (Home Subscriber Server) and the S-CSCF according to the standard, or - the authentication / is faulty ,

On the basis of the SIP session error 285, the control unit 52 sends an SIP end message 292 to the terminal 50 at a time t218 and an SIP end message 294 to the terminal 54 at a time t220. On the basis of the two messages 292 and 294 the SIP session then ends in a method step 296.

In connection with the termination, a session end request message 290 is sent from the control unit 52 to the authorization / charging unit 24 at a time t221. The message 290 corresponds to the message 90. On the basis of the message 290, the authorization / charging unit 24 stops the charging timer or time counter in a method step 291. The authorization / charging unit 24 then sends a session end response message 298, which corresponds to the message 98, to the control unit 52 at a time t222. FIG. 5 shows the message flow of a SIP session with offline charging. Except for the deviations explained below, the same messages are transmitted and processed in the same way as explained above with reference to FIG. 2. Therefore, the same points in time and the same messages are denoted by the same reference symbols, the points in time and messages according to FIG.

The differences concern the following procedural steps:

In method step 366, which is carried out instead of method step 66, it is recognized from the user identifier and / or from the service that an offline charge is to be carried out which is billed using a postpaid method.

- Method step 68 relating to the balance check has been omitted and therefore has no corresponding method step.

- In step 370, a fee data record is generated instead of a reservation, which is called S-CSCF CDR (Charging

Data Record) is called. Such a charge data record is explained in more detail, for example, in the 3GPP TS 32.225 standard.

In step 384, the CDR data record is changed in accordance with message 382. - In step 391, the CDR data record is stored or closed properly.

From the point of view of the control unit 52, the charging method need not be known, so that apart from the differences mentioned, the same procedure as in FIG. 2 is carried out.

FIG. 6 shows a server unit 400, which performs the functions of the authorization / charging unit 24 and contains the following units:

a storage unit 402, a transceiver unit 404 which can receive the authorization messages 62, 162, 262 and 362 and the charging messages 82, 182, 282 and 282,

a charging unit 406 which changes a charging date depending on the content of the charging messages 82, 182, 282 and 282, and

an authorization unit which carries out the authorization after receipt of the authorization message 62, 162, 262 or 362, see method steps 64, 164, 264 or 364.

Optionally, the server unit 100 also contains further units 410 for carrying out the methods explained above with reference to FIGS. 2 to 5.

In one exemplary embodiment, all units 404 to 410 access memory 402 in order to perform their functions, see arrow 414. The interaction between charging unit 406 and authorization unit 408 is particularly close, in particular when performing method steps 66 to 70,

166 to 170 or when performing method steps 366 and 370.

In a first alternative, the server unit 400 does not contain a processor that processes a program. Units 404 through 410 contain circuits that are hardwired. In an alternative variant, however, the functions of the units 404 to 410 are performed by a processor 416 when a program stored in the memory 102 is processed.

FIG. 7 shows functional units of a client unit 450 which cooperates with the server unit 400 in the methods explained with reference to FIGS. 2 to 5. The client unit 450 includes:

a storage unit 452 for storing data records, a transceiver 454 for sending messages 62, 162, 262, 362, 82, 182, 282, 382, 90, 290 and 390, and

a generation unit 456 which can generate the messages just mentioned.

The generation unit 456 accesses the same data record in the storage unit 452 when generating the authorization message and when generating the charging message.

Optionally, the client unit 450 also contains further units 458 in order to provide the functions for the authorization and the charging, in particular a receiving unit for receiving the response messages or the message 190.

In one embodiment, all units 454 through 458 access memory 452 to perform their functions, see arrow 460.

In a first alternative, the client unit 450 does not contain a processor that executes a program. Units 454 through 458 include circuitry that is hardwired. In an alternative variant, the functions of the units 454 to 456 are performed by a processor 462 when a program stored in the memory 452 is processed.

Claims

claims

1. Method for charging, in which the following method steps are carried out without restriction by the specified sequence: in a network element (24) of a data transmission network (10), storing a fee data record with a fee date that indicates the account balance of a fee account of a user, the user data the data transmission network (10) transmits, transmitting a service request message (82) for the use of a service by the user, depending on the service request message (82) assigning a service termination date to the user, the service termination date specifying a limit for the use of the service and wherein the value of the fee date is changed,

Changing the termination date depending on the use of the service in the network element (24),

Determining the end of the service depending on the service termination datura in the network element (62).

2. The method according to claim 1, characterized in that the service termination date is a time date that specifies a period of time for which the user can use the service, or that the service termination date is a dataset date that specifies an amount of data that is used during the use of the service Service may be transmitted over the data transmission network at most.

3. The method according to claim 1 or 2, marked by the steps:

Generating an authorization message (62) according to an authorization protocol or according to an authorization part of a protocol, transmitting the authorization message (62) via the data transmission network (10), Use the authorization message (62) to prepare the charge or use the authorization message (62) when the charge ends.

4. The method according to claim 3, characterized in that the authorization message (62) contains a user identifier that indicates the user of the data transmission, and that depending on the user identifier, the authorization of the user for data transmission is checked, and that on the basis of the authorization message ( 62) and / or depending on the content of the authorization message (62) a fee type and / or a billing type is selected (66).

5. The method according to claim 3 or 4, characterized in that on the basis of the authorization message (62) and / or depending on the content of the authorization message (62) a reservation of a fee amount or a fee time is made,

and / or that when the authorization message (62) is processed, a charge data record is generated for the charging.

6. The method according to any one of claims 3 to 5, characterized in that the authorization message (62) is transmitted before the preparation of the data transmission has been completed, or that the authorization message (62) is transmitted after the preparation of the data transmission has been completed.

7. The method as claimed in one of claims 3 to 6, characterized in that the authorization message (62) fulfills the requirements of the Diameter protocol or a protocol based thereon. and / or that the authorization message (62) is processed in accordance with the Diarαeter protocol or in accordance with a protocol based on this protocol.

8. The method according to any one of claims 3 to 7, characterized in that the authorization message (62) used when terminating is an abort message which leads to the termination of the data transmission, in particular the abort session request message of the diameter protocol or one thereon building protocol.

9. The method according to claim 1 or 2, characterized in that a further service request message is transmitted before the service request message (82), which contains a user identifier that indicates the user of the data transmission, and that the authorization is dependent on the further service request message of the user is checked for data transmission, and that a fee type and / or a billing type is preferably selected on the basis of the service request message and / or depending on the content of the service request message.

10. The method according to claim 9, characterized in that the service request messages are messages according to the Diameter Base Protocol or a protocol based thereon.

11. The method according to claim 9 or 10, characterized in that an abort message from the. Network element (24) is sent, the abort message being an extension of the now applicable charging part of the Diameter Base protocol.

12th Method according to one of claims 9 to 11, characterized in that the further service request— tion message is transmitted before the preparation of the data transmission has been completed, or that the further service request message is transmitted after the preparation of the data transmission has been completed.

13. The method according to any one of the preceding claims, characterized in that the billing is an online billing that can influence the data transmission, and that the billing is monitored in a service provider computer (24) that is in addition to a service provider computer (52) is provided, which controls the data transmission.

14. The method according to any one of the preceding claims, characterized in that the same service request message (82) is transmitted for an OnJLine billing and for an offline billing, preferably the account request message according to the diameter

Protocol or according to a protocol based on the diameter protocol, the same account record type being used in both service request messages (82), in particular an EVENT_RECORD.

15. charging unit (402), in particular with units for carrying out the method steps of a method according to one of the preceding claims, with a receiving unit (404) for receiving an service request message (82) from a data transmission network, the service request message (82) containing an access identifier , which characterizes a data transmission in the data transmission network, with a charging unit (406) which depends on the

Service request message (82) a charge for the data Carries out transmission and / or the data transmitted during the data transmission, the charging unit maintaining a fee account and terminating the service depending on an interruption date updated when the service is used.

16. The charging unit (402) according to claim 15, characterized by an authorization unit (410) which receives or sends an authorization message (62) according to an authorization protocol or according to an authorization protocol part of a protocol and which the authorization message (62) for preparation or during Ending the charge uses.

17. charging unit (450), in particular with units for performing the method steps of a method according to one of claims 1 to 13, with a transmission unit (454) for sending a service request message (82), wherein the service request message (82) contains an access identifier that a Data transmission in the data transmission network indicates.

18. charging unit (402, 450) according to one of claims 15 to 17, characterized gekennz ei chnet that the charging unit (406) receives and / or sends messages according to the Diameter Base Protocol.