DE102005001905A1 - Multimedia service fees charging method for e.g. cellular mobile radio network, involves evaluating parameter of signaling message when sending message between two network units and forwarding evaluation result to fees charging center - Google Patents

Abstract

The method involves evaluating a parameter of a signaling message by a processing unit provided in a conditioning unit when sending the message of a protocol between a network unit e.g. portable mobile terminal and another network unit e.g. application server. The parameter indicates a service for which fees is to be charged. The evaluation result is forwarded with the message of another protocol to a fees charging center. An independent claim is also included for a device for charging fees for a service.

Description

The The invention relates to a method and a device for charging at least a service comprising a first network element and a second network element of a communication network.

In Mobile networks are for the billing the two methods "Online Charging "and" Offline Charging. "While for the user a former network element, such as a mobile station, a mobile computer, a mobile organizer, a computer etc. when "offline Charging "the billing only after using multimedia services, for example, takes place at "Online Charging "the billing in temporal proximity for execution of the service. Therefore, "online charging" is also referred to as real-time charging. The "prepaid billing" is an example a real-time fee, when as temporal proximity to carry out the Serve the account of the user of the mobile radio terminal, for example execution the service is charged.

mobile networks The third generation (for example the UMTS network) are not just for language and variable data streams but also allow the customer to use multimedia services. The billing The use of multimedia services is extremely complex and not yet satisfactory-solved. charging models will be used in mobile networks of the 3rd generation for online and offline charging with a high degree flexibility available to the operators stand.

From of particular importance is the billing of events at service, based on the information available the signaling can result. A billing of events or Services based on signaling is not yet known and is in the 3GPP standardization not clearly described (3GPP TS 32.299 V 0.2.0, 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging Management; Diameter Charging Application; Release 6; 01/2004). Services or events (Events) can u. a. above the so-called IP Multimedia Subsystem (IMS). The IMS (IP Multimedia Subsystem) was released as part of 3GPP Release 5 and Release 6 standardized. The billing in the IMS is in the 3GPP specifications TS 32.225 (Release 5) (3GPP TS 32.225 V5.4.0; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Charging data description for the IP Multimedia Subsystem (IMS), Release 5; 12/2003) and TR 32.815 (3GPP TR 32.815 v6.0.0; Technical Report; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Online Charging System (OCS) architecture study; Release 6; 09/2003), as well as in the specification TS 32.296 (both Release 6) (3GPP TS 32.296 V1.0.0; Technical Specification; 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Online Charging System (OCS): Applications and interfaces, Release 6; 03/2004). The specifications for both release 5 as well for Release 6 are not stable yet. It is expected that the IETF Draft "DIAMETER Credit Control Application "(IETF Internet Draft: Diameter Credit Control Application; draft-ietf-aaa-diameter-cc-03.txt, February 2004) will be referenced. This draft describes the DIAMETER messages for, among other things, session (connection) awards. The technical problem with using the Ro interface to billing is that for a connection charge a relatively complex procedure is used (reservations as well a so-called budget control are required. Furthermore, a state element must over the remain active for the entire time of the connection) and not yet a state element for the Implementation of, for example, the SIP protocol on the Diameter protocol has been described.

The current Architecture in 3GPP networks allows both the time and the volume-based billing of services. Specially for Online Charging is in the IP-based Multimedia Subsystem (IMS) the Ro interface has been standardized. It connects the services connection status control function (Serving Call State Control Function = SCSCF) and the billing center = Online Charging System (OCS) with each other. As protocol for the Ro interface The 3GPP in IMS Rel. 6 became the IETF draft Credit Control Application (CCA) = the Diameter protocol chosen, unrelated to that stands with the SIP signaling. The specification 3GPP TS 32.299 V 0.2.0; 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging Management; Diameter Charging Application; Release 6; 01/2004 Provides that execution service depends on the result of the billing. The described Concept blocks for a "service Request "the execution of Service.

The 3GPP standardization has so far no concrete implementation of a billing of SIP-based sessions (connections) to appropriate messages of the Diameter protocol and no condition element defined for charging. There is also no IP multimedia subsystem (IMS) in use, so that there is also no known state element that the connections between the. corresponding SIP and Diameter messages of Diameter protocol describes.

The Control of services in 3GPP networks is done with the SIP protocol. This is among other things in the specification TS 24.229 (3GPP TS 24.229 V5.6.0; Technical Specification; 3rd Generation Partnership Project; Technical Specification Group Core Network; IP multimedia call control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3; Release 5; 09 / 2003-09). Specifications TS 32.225 (R5) and TS 32.296 (R6) describe like the billing services on the SIP-AS (application server) (R5 and R6, in R6 also referred to as IMS-AS) and on the IMS gateway function (only R6) is.

in the Chapter "Event Charging with Unit Reservation (ECUR) "of TS 32.225 for Release 5 and in the chapter" Event Charging with Unit Reservation "of the TS 32,299 for Release 6 describes that during service request (service request) an ACR start DIAMETER message (R5) or a CCR-initial DIAMETER message (R6) is issued, whereupon for billing so-called units (Units) are reserved at the Vergebührungszentrum. While the provision of the service becomes an ACR interim DIAMETER message (R5) or a CCR update DIAMETER message (R6) deducted, whereupon the user account units are deducted and new units are reserved. After the provision of the service becomes an ACR end DIAMETER message (R5) or a CCR-terminal DIAMETER message (R6) deducted, whereupon the last consumed units are deducted from the user account. It will a DIAMETER state element for the entire duration of the service execution maintained. Here is the service execution or the connection establishment blocked until a DIAMETER Credit Control Response message (CCA) is present. This is also called synchronicity.

It is expected in the release 5 there:. Online Charging through replace the mechanisms of Release 6 (i.e., the Hakala Diameter Credit Control Draft (IETF Internet Draft: hakala-diameter-credit-control-draft; draft-hakala-diametercredit-control-05.txt, Harri Hakala, Leena Mattila, Juha-Pekka Koskinen, Marco Stura, November 2002) will not continue in the IETF standardization process tracked and therefore by the 3GPP against the Diameter Credit Control Application Draft (CCA) (IETF Internet Draft: Diameter Credit Control Application; draft-ietf-aaa-diameter-cc-03.txt, February 2004) or Online Charging will be deleted from Release 5. In Release 6, the billing messages for Online Charging are displayed with the Messages Credit Control Request (CCR) and Credit Control Answer (CCA). These two messages are in the Diameter Credit Control Application Draft (IETF Internet Draft: Diameter Credit-Control Application; draft-ietf-aaa-diameter-cc-03.txt, February 2004) and have already been adopted by the 3GPP in the IMS Rel. 6 (3GPP TS 32.299 V 0.2.0; 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging Management; Diameter Charging Application; Release 6; 01/2004).

The The object of the invention is to be seen in a way for an efficient and cost-effective charging for of services in a communication network.

The Task is inventively each things the independent one claims solved. Further developments of the invention are specified in the subclaims.

A core of the invention can be seen in the fact that for the transmission of at least one service, which relates to a first network element and a second network element of a communication network, for example via a cellular mobile network, via an IP network, etc., when sending at least one signaling message a first protocol, for example the SIP protocol, the H.323 etc., between the first network element and the second network element, a state element evaluates at least one parameter of the at least one signaling message indicating the service to be billed. In general, data of a service is exchanged between the first network element and the second network element via the communication network, however, it may also happen that no data of a service is exchanged and yet billing is performed. This can be the case, for example, during a telephone call without exchanging speech. Here is due time. According to the invention, the evaluation result is sent to at least one further signaling message of a second protocol, for example the Diameter protocol, to a billing center. In this case, for example, the first network element may be a mobile radio terminal, a mobile computer, a computer and / or a mobile organizer. The second network element may be, for example, an application server, a presence server, a proxy server, a mobile radio terminal, a mobile computer, a computer and / or a mobile organizer or the like. The invention thus sees ei asynchronous message traffic. An asynchronous message traffic does not affect the flow of the connection. The billing is thus independent of the execution of the service and thus not blocking. In the 3GPP standards the synchronous procedure is used for the Online Charging (real time billing). The state element may, for example, be a network element of a connection state control function (call state control function), an application server, a network element of the IP multimedia subsystem and / or a standalone network element. Furthermore, the state element could be integrated in a service node. As service nodes in 3GPP networks, for example, push-to-talk server (PoC) or conference server, instant messaging server = message server, MMS relay server = multimedia message server, presence server Presence Server, Location Server = Local Server, SIP Gateways (eg MRFC) or Voice Mail (Voicemail Server). The application servers or service nodes have the following specifications: TS 32.296 (3GPP, 3rd Generation Partnership Project, Technical Specification Group Service and System Aspects, Telecommunication Management, Charging Management, Online Charging System (OCS): Applications and Interfaces (Release 6), V1.0.0, March 2004) via a Ro interface.

in the Unlike time-based billing models, they require event-driven Real-time charging models always an immediate or timely decision on the execution of a Service. Within the scope of the Diameter protocol, the Vergebührungszentrum for example, the connection status control functin (S-CSCF) of the IP Multimedia Subsystem inform how to proceed with the execution of the service is. That the decision is not left to the network elements, but from the toll center given and removed from the result of Vergebührungsanfrage.

The Messages for billing for real-time billing can for Example with the messages Credit Control Request (CCR) and Credit Control Answer (CCA) performed become. These two messages are in the IETF draft CCA (IETF Internet Draft: Diameter Credit Control Application; draft-ietf-aaa-diameter-cc-04.txt, March 2004) and were adopted by the 3GPP in IMS Rel. 6 (3GPP TS 32.299 V 0.2.0; 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging Management; Diameter Charging Application; Release 6; 01/2004).

• • Rückruf bei Besetzt (Hinweis an A-TN, dass der B-TN. Frei ist)
• • Anrufweiterschaltung (Hinweis an A-TN, dass der Ruf weitergeleitet wurde)
• • Gebührenanzeige (Advice of Charge)

The charging refers to the use of a service or SIP-based events and is triggered or triggered, for example, by the SIP messages of a connection setup (eg INVITE, 200 OK, ACK). Of course, according to the invention, other signaling protocols such as the H.323 protocol for the method or for the device can be used. With the introduction of the IP multimedia subsystem IMS in mobile networks of the 3rd generation, the user of a first network element not only has the opportunity to use a service, but also certain notifications can be requested. These indications or services provide information about a condition and can be understood as service features (supplementary services, similar to those in the fixed network / GSM), which relate to the connection control or to the execution of the service itself. For example, can. for the connection control the user of a first network element can be provided with the following services or information upon request:

• • Callback on busy (note to A-TN that the B-TN is free)
• • Call Forwarding (Note to A-TN that the call has been forwarded)
• • Advice of Charge

• • Presence Service (update Buddy list)
• • Location Service (Hinweis auf Aufenthaltsort)
• • Push to Talk over Cellular (PoC) (Hinweis auf den Zustand von PTT)
• • Sprachspeicher (Hinweis auf den Zustand des Sprachspeichers)
• • Weckdienst (Hinweis auf Alarm)
• • Instant Messaging (Nachrichten-Dienst)

The following notes may result from the execution of the service or application:

• • Presence Service (update Buddy list)
• • Location Service (notice of whereabouts)
• Push to talk over cellular (PoC) (indication of the condition of PTT)
• • Speech memory (note on the state of the speech memory)
• • Wake-up service (indication of alarm)
• • Instant Messaging (Messaging Service)

Alles these hints or services can can be regarded as asynchronous events and can Users of a first network element useful, possibly chargeable Provide information. The desired Notes can be requested by the user of a first network element. For example becomes the desired event with the SIP method "SUBSCRIBE" or the desired service requested by the user of a first network element. A second network element provides the user with the event or service via the communication network with help of the SIP method NOTIFY available. The standardized procedure is using the SIP-specific event notification in the IETF Internet Default: RFC 3265: Session Initiation Protocol (SIP) -Specific Event Notification, June 2002. However, real-time billing is such events are not yet known.

In the present invention message can For real-time charging, for example, the SUBSRCIBE method can be used, with which the services requested by the user of a first network element can be requested. The desired services are entered as events with a suitable parameter, for example in a SUBSCRIBE signaling message. Currently, the SUBSCRIBE method is a well-known and standardized SIP method by which a user of a first network element can request services over the communications network. The services requested are communicated to the Online Charging System (OCS) as events with appropriate charging parameters. The billing of the services is carried out by the billing center. The correlation between a received SUBSCRIBE method and the Diameter messages used manifests itself in a state element. The state element describes the correlation between the SIP and Diameter messages based on the SUBSRCIBE method.

A Another embodiment of the invention is that at least another signaling message of a second protocol, for example, the Diameter protocol, at least one other parameter for the billing of the service. The at least one further parameter will be the at least one another signaling message of a second protocol, for example by the state element, a network element of the IP multimedia subsystem, a service node or the like added. The at least one additional parameter can be the expected Duration of the service, the expected amount of data of the service and / or specify a fixed amount of money.

The The method described in the invention is characterized by a simple Realization of event-based billing models on the basis Online Charging Micropayment, standardized events or Services, immediate account debits and no expensive reservation procedures out. Here is the introduction unified and simplified with new event-driven services. There is a clear assignment of the requested event on the billing. The user of a service chooses the event itself. Use of the standardized procedure can be used to request notes using SUBSCREBE / NOTIFY respectively. Furthermore, there is no extension of the SIP or Diameter protocol necessary.

The The invention is based on an embodiment shown in a figure explained in more detail. there demonstrate

1 an example of a flow chart for the method according to the invention,

2 an example of a further embodiment of the method according to the invention for billing a service with a fixed timer,

3 a state table too 2 .

4 a flow chart for a solvency check too 2 .

5 State tables too 4 .

6 a flowchart for a rebooking of unused units,

7 State tables too 6 .

8th a flowchart for charging with a flexible timer,

9 State tables too 8th .

10 a flow diagram for charging a service with a fixed timer,

11 a second flowchart for a. Breaking down a connection,

12 a device according to the invention.

1 shows an example of a flowchart for the inventive method. Considering the state element ZE according to the invention, an example of a real-time billing with SIP-based services is discussed. The state element ZE is implemented in the service connection state control function S-CSCF in this example and correlates the SIP method SUBSCRIBE with the Diameter protocol CCR / CCA commands. The NOTIFY messages resulting from the SUBSCRIBE message are not shown. A first network element A-TN sends a SUBSCRIBE message to the service connection status control function S-CSCF and requests a service (NOTIFY). Thereafter, the service connection status control function S-CSCF sends a SUBSCRIBE message to a second network element B-TN / AS / MRFC. When the second network element B-TN / AS / MRFC accepts the request, the second network element B-TN / AS / MRFC returns a 200 OK message to the service connection status control function S-CSCF. The service connection status control function S-CSCF forwards the 200 OK message to the first network element A-TN. Due to the received SUBSCRIBE message and the event contained therein for the requested service in the form of at least one parameter, an evaluation result from the state element ZE in the diens te connection status control function S-CSCF created and sent a Diameter CCR message (Credit Control Request) with the evaluation result to the charging center OCS. The billing of the event is now based on the transmitted evaluation result. As a result of the charging, a Diameter CCA message (Credit Control Answer) is sent to the state element ZE in the service connection status control function S-CSCF.

Under circumstances can with an asynchronous message traffic and a missing credit a one-time fee may not be performed. For low-cost services, this billing model is certainly desirable. On the other hand must be resorted to a synchronous message traffic, if the Result of a charge request in connection with the execution of the requested hint (e.g., higher order services). In this Case, the user of a first network element A-TN on, for example a SUBSCRIBE request received a negative response.

For the method according to the invention, a SUBSCRIBE message could be used according to the following coding example:
SUBSCRIBE sip: andreas@vmail.example.com SIP / 2.0
To: <sip: andreas@example.com>
From: <sip: andreas@example.com>; tag = 78923
Date: Mon, 22 March 2004 03:55:06 GMT
Call Id: 1349882@andreas-phone.example.com
CSeq: 4 SUBSCRIBE
Contact: <sip: andreas@andreas-phone.example.com>
Event: message-summary
Expires: 86400
Accept: application / simple-message-summary
Content-Length: 0

• • Reg (IETF Internet Draft: A Session Iniziation Protocol (SIP) Event Package for Registrations, draft-ietf-sipping-reg-event.txt, J. Rosenberg, October 2002)
• • Presence (IETF Internet Draft: A Presence Event Package for the Session Initiation Protocol (SIP), draft-ietf-simple-presence-l0.txt, J. Rosenberg, January 2003 and IETF: Internet Draft: A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists, draft-ietf-simple-event-list-04, A. B. Roach, J. Rosenberg et al., December 2003)
• • Presence.winfo (Präsenz-Info) (IETF: Internet Draft: A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP), draft-ietf-simple-winfopackage-05.txt, J. Rosenberg, January 2003)
• • Conference (Konferenz) (IETF: Internet Draft: A Session Initiation Protocol (SIP) Event Package for Conference State, draft-ietf-sipping-conference-package-02, J. Rosenberg et al., October 2003)
• • Message-Context (Nachrichten-Kontext)("voice-message" /"fax-message"/"pager-message"/"multimedia-message" /"text-message"/"none")(IETF: Internet Standard: RFC 3458: Message Context for Internet Mail, E. Burger et al.; January 2003)
• • Message-summary (Nachrichten-Zusammenfassung) (IETF: Internet Draft: A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP), draft-ietf-sipping-mwi-04.txt, R. Mahy, December 2003)
• • Refer (IETF: Internet Standard: RFC 3515: The Session Initiation Protocol (SIP) Refer Method, R. Sparks, April 2003)

For example, in the event header of the SUBSCRIBE method or message, the event is message-summary, for example, the Message Waiting Indication service. With this service, the subscriber will be notified accordingly (NOTIFY) to record his voice box. Some other services or events that are based on the SUBSCRIBE method for scheduling real-time charging and standardized for the realization of various multimedia services by the IETF are

• • Reg (IETF Internet Draft: A Session Initiation Protocol (SIP) Event Package for Registrations, draft-ietf-sipping-reg-event.txt, J. Rosenberg, October 2002)
• • Presence (IETF Internet Draft: A Presence Event Package for Session Initiation Protocol (SIP), draft-ietf-simple-presence-l0.txt, J. Rosenberg, January 2003 and IETF: Internet Draft: A Session Initiation Protocol (SIP ) Event Notification Extension for Resource Lists, draft-ietf-simple-event-list-04, AB Roach, J. Rosenberg et al., December 2003)
• • Presence.winfo (Presence Info) (IETF: Internet Draft: A Watcher Information Event Template Package for the Session Initiation Protocol (SIP), draft-ietf-simple-winfopackage-05.txt, J. Rosenberg, January 2003)
• • Conference (IETF: Internet Session: A Session Initiation Protocol (SIP) Event Package for Conference State, draft-ietf-sipping-conference-package-02, J. Rosenberg et al., October 2003)
• • Message Context ("voice-message" / "fax-message" / "pager-message" / "multimedia-message" / "text-message" / "none") (IETF: Internet Standard: RFC 3458: Message Context for Internet Mail, E. Burger et al., January 2003)
• • Message-summary (IETF: Internet Draft: A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP), draft-ietf-sipping-mwi-04.txt, R. Mahy, December 2003)
• • Refer (IETF: Internet Standard: RFC 3515: The Session Initiation Protocol (SIP) Refer Method, R. Sparks, April 2003)

2 shows an example of charging a service with a fixed timer. Of course, the timer could also refer to a fixed amount of money and / or the expected amount of data of the service according to the invention. The connection using the SIP (SIP) protocol is as described in T5 24.229 (3GPP TS 24.229 V5.6.0; Technical Specification; 3rd Generation Partnership Project; Technical Specification Group Core Network; IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3; Release 5; 09 / 2003-09). When the 200 OK message passes the network element of the IP Multimedia Subsystem IMS-NE, a DIAMETER Credit Control Request (CCR) message is sent to the charging center OCS. A network element of the IP multimedia subsystem IMS-NE used in this example can naturally also be the state element according to the invention, a connection status control function CSCF, a service crotch or the like. A first additional parameter "requested action" (Requested-Action AVP) in the Diameter-CCR message is set to direct-charge (DIRECT DEBITING) in this example, and "requested-service-units" for a second further parameter. Service unit AVP), in this example The requested units of time (units) (eg 60 seconds) to wind up the timer. The requested service is identified by means of the sent-in SDP session description AVP and SDP media component AVP. The charging center OCS evaluates the parameters (SDP-AVPs) sent in the Diameter CCR message, calculates a price based on the requested time units (the so-called "rating") and deducts this amount from the user account is sent without waiting for a response to the DIAMETER CCR message, thus not delaying the session (session) setup, and at the same time, a timer whose duration is configurable is raised The timer is the same for all services as the network element of the IP multimedia subsystem IMS NE can not necessarily know which service is requested when the session is set up.The Diameter CCR message is answered with a Diameter CCA message (Credit Control Answer). CCA message), it can be recognized whether or not the user account of a first network element A-TN is sufficiently covered After the timer has expired, a Diameter CCR message is again read ht sent to the charging center OCS, which contains the same parameters (SDP-AVPs).

The the procedure is the same as for the first Diameter CCR message. Changes in the Service parameters are returned to the charging center OCS in the next DIAMETER CCR message Expiry of the timer) announced.

Should If the account does not have sufficient coverage, the Diameter CCR message is sent with a Diameter CCA message, which is a result of checking for account coverage the user account of a first network element A-TN (result code AVP) contains answered. In this case, the SIP connection (session) is aborted. When demolition the connection by the user of the first network element A-TN no further DIAMETER messages exchanged.

3 shows a state table 2 , In the state table, various states, also called state machines, and the actions dependent thereon are represented by the network element of the IP multimedia subsystem IMS-NE or the charging center OCS. For the sake of simplicity, no error cases are taken into account (eg missing responses from the charging center OCS to DIAMETER messages and / or 3xx, 4xx, 5xx and 6xx SIP reply messages). Furthermore, it is assumed that the response messages arrive on Diameter CCR messages in the same order in which the requests were made. An arrival in a different order is considered an error. The Diameter timer, which monitors the arrival of the Diameter CCA message in response to the Diameter CCR message, and invalid messages are not included.

By the inventive method Is it possible, very similar to the charge impulses at traditional landline telephony, a connection (session) or a service through event-driven signaling messages (Event messages) to be charged. The above timer of 60 seconds would allow a so-called 60/60 charging.

4 shows a flow chart for a solvency check 2 , It is obvious that asynchronous messaging via DIAMETER messages causes some blurring. Typically, a request to the Verification Center OCS via DIAMETER messages takes about 0.5 seconds. However, this is a time frame that can be justifiable for the network operator.

Problematic is, however, that the user of a first network element A-TN always again can establish a connection (session), even if his account is empty. this could for attacks be used on the communication network (denial of service). This problem can be excluded by implementing the "Solvency Check" will be at the beginning of the message exchange with the Diameter CCR message queried whether the account is still covered, with another parameter in the Diameter CCR message (Requested-Action AVP) is set to "CHECK_BALANCE" If this is not the case, the connection will be terminated immediately. The user of the first network element A-TN still has a short time anyway established a connection, however, the network element of the IP Multimedia Subsystem IMS NE now the user of the first network element A-TN for all paid Lock services.

5 shows the state tables 4 , The states or the state machine for the solvency check (balance check) can be seen in table a). The state machine shows the case without error messages. This state machine is additionally (or even at the same time, if the answer to the solvency request arrives later than the 2000K message sent to the network element of the IP Multimedia Subsystem IMS-NE) to the state machine according to 3 used.

But it is also possible to run the solvency check in the state machines of the base scenario according to 3 to integrate. The state transition of the basic scenario according to Table b) is then replaced by Table c).

6 shows a flowchart for rebooking unused units by the user of a first network element A-TN. In order to achieve a finer granularity (eg second precision) in the billing of the service, the network element of the IP Multimedia Subsystem IMS NE can return "unused" units to the billing center OCS, using the Diameter CCR message, with at least one other parameter (Requested-Action AVP) is set to "REFUND ACCOUNT" and the at least one additional parameter (requested service unit AVP) indicates the unused units.

7 shows the state tables 6 , The state machine is shown in the following table a) in the basic configuration. The state machine shows the case without error messages. The state in table a) is replaced by the state for the rebooking of unused units according to table b). In addition, the state according to c) or, if you want to wait for a response to a Diameter message, the state according to Table d) is added and the states according to Table e).

8th shows a flow chart for a billing with a flexible timer. A further improvement of the method is possible if the same fixed timer is not set for all services, but the charging center OCS uses the service to determine it (eg 30 seconds for (expensive) video telephony, 300 seconds for (inexpensive) voice telephony). Thus, the number of exchanged DIAMETER messages between the network element of the IP Multimedia Subsystem IMS-NE and the Vergebührungszentrum OCS can be reduced. As with the basic solution according to 2 First, a preset timer on the network element of the IP multimedia subsystem IMS NE is mounted. In the Diameter CCR message at the beginning of the connection establishment, the at least one further parameter (Requested Service Unit AVP) is not filled, so that this message from the charging center OCS with a concrete time value in at least one other parameter (Granted Service Unit AVP) in the Diameter CCA message. If the preset Tiner expires, another timer is set up, which contains the time units granted by the charging center OCS minus the already used time units of the preset timer.

9 shows state tables 8th , The state according to the basic configuration in table a) changes according to table b). The state machine shows the case without error messages.

10 shows a flowchart for charging a service with a fixed timer. The following is an example of a message flow in which the service connection status control function S-CSCF, a network element of the IP multimedia subsystem IMS-NE, initiates the charging. In this case, a fixed timer defined on the service connection status control function S-CSCF becomes, as in 2 described, used.

in the Detail, the following functions are performed:

A Solvency verification can be performed at the beginning of the connection setup. If the service is started, a timer is started, and it will be the charging center OCS the for the billing the service necessary parameter with the request a direct debit to pass. The billing center OCS determines the cost based on the delivered parameters the service and book the corresponding amount of money directly from the user account (no reservation). When the timer expires, it will be restarted started, and it will be the charging center OCS for the billing of the Service necessary parameters, as well as the required units resubmit, whereupon a debit takes place again. This process is repeated until the service ends. With a SIP signaling message "SIP BYE" is the connection completed. When this SIP message is received, the service connection status control function can S-CSCF the billing center the left over submit remaining units for credit.

• I. Um eine Verbindung zu einem zweiten Netzelement B-TN, AS, MRFC aufzubauen, schickt das erste Netzelement A-TN eine „SIP INVITE" – Nachricht über das IMS Netzwerk zu dem gewünschten zweiten Netzelement B-TN, AS, MRFC. Die Nachricht wird zu der Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF weitergeleitet, da dieses Netzelement für die Ausführung von nutzer-spezifischen Diensten und natürlich für die Vergebührung der Verbindung zuständig ist. Wenn die Solvenzüberprüfung aktiviert ist, dann generiert die Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF eine Diameter-CCR-Nachricht bei Empfang einer „SIP INVITE"-Nachricht. Die Parameter (Attribute-Value-Pairs (AVP)) der Diameter-CCR-Nachricht müssen mit den folgenden Daten versorgt werden, damit das Vergebührungszentrum OCS die Solvenzüberprüfung durchführen kann: a. Der Diameter-CCR-Typ (CC-Request-Type) AVP wird auf „Ereignis-Anfrage" (EVENT REQUEST) gesetzt. b. Der Parameter „angefragte Aktion" (Requested-Action) AVP wird auf „Überprüfe Konto" (CHECK BALANCE) gesetzt. c. Die von der 3GPP spezifizierten SDP-Session-Beschreibungen und SDP-Media-Komponenten -AVPs werden mit den entsprechenden SDP Daten aus der „SIP INVITE" – Nachricht versorgt. Von der Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF wird die „SIP INVITE" – Nachricht zum nächsten IMS Netzelement (z.B.: eine I-CSCF) weitergeleitet. Der Verbindungsaufbau wird dabei nicht unterbrochen.
• II. Das Vergebührungszentrum OCS empfängt die Diameter-CCR-Nachricht und prüft zuerst welche Art der Vergebührung (z. B. Online Charging) durchgeführt werden soll. Das Vergebührungszentrum OCS erkennt durch die Überprüfung des „CC-Request-Types" und der „Requested-Action", dass eine Solvenzüberprüfung durchgeführt werden soll.
• III. Das Vergebührungszentrum OCS bewertet die gelieferten SDP Informationen (der SDP beschreibt welche Art der Verbindung gefordert ist, z.B. Sprachtelephonie oder Videotelephonie) und ermittelt die Kosten für den Dienst.
• IV. Entsprechend der Bewertung der SDP Informationen wird die Deckung des Nutzerkontos überprüft. In diesem Fall weist das Nutzerkonto eine ausreichende Deckung auf, und das Vergebührungszentrum OCS sendet dieses Ergebnis in der Diameter-CCA-Nachricht an die Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF zurück.
• V. Die Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF empfängt die Diameter-CCA-Nachricht und prüft das erhaltene Ergebnis in Form eines Parameters (Check-Balance-Result AVP), welcher in diesem Fall ausreichend Kredit „Enough-Credit" anzeigt. Dementsprechend wird der Verbindungsaufbau nicht abgebrochen.
• VI. Das zweite Netzelement B-TN, AS, MRFC des angerufenen Nutzers schickt eine „SIP 200 OK" – Nachricht, wenn der Nutzer abhebt. Die „SIP 200 OK" – Nachricht wird bei der Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF verwendet, um die „Online"-Vergebührung zu starten. Zu diesem Zweck startet die Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF einen konfigurierbaren Timer und generiert eine Diameter-CCR-Nachricht mit den folgenden Daten: a. Der Anfrage-Typ (Request-Type) wird auf „Ereignis-Anfrage" (EVENT REQUEST) gesetzt. b. Der Parameter „angefragte Aktion" (Requested-Action AVP) wird auf „Direkte Vergebührung" (DIRECT_DEBITING) gesetzt. Diese Einstellung führt dazu, dass der Geldbetrag sofort vom Nutzerkonto abgezogen wird. c. Zur Indikation des Dienstes werden auch die Daten des SDPs in die entsprechenden AVPs eingefügt (SDP-Session-Description und SDP-Media-Component AVPs). d. Entsprechend des Timers der Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF, wird der Parameter angefragte Diensteinheiten (Requested-Service-Unit AVP) ausgefüllt. D.n. die Dauer des Timers entspricht der Anzahl der geforderten Einheiten. Der Verbindungsaufbau wird nicht angehalten, wenn die Diameter-CCR-Nachricht zum Vergebührungszentrum OCS gesendet wird. Aus diesem Grund kommt es zu keiner Verzögerung des Verbindungsaufbaus.
• VII. Das Vergebührungszentrum OCS empfängt die Diameter-CCR-Nachricht und prüft zuerst welche Art der „Online"-Vergebührung durchgeführt werden soll. Das Vergebührungszentrum OCS erkennt, dass entsprechend des angefragten Typs „Request-Type" und der angefragten Ak tion „Requested-Action", der in Schritt. VIII ermittelte Geldbetrag sofort vom Nutzerkonto abgebucht werden soll.
• VIII. Das Vergebührungszentrum OCS bewertet den SDP-Parameter und ermittelt anhand der geforderten Einheiten die Kosten des Dienstes. Der errechnete Betrag wird vom Nutzerkonto sofort abgezogen.
• IX. In der Diameter-CCA-Nachricht sendet des Vergebührungszentrum OCS die gewährten Einheiten an die Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF zurück.
• X. Da das Vergebührungszentrum OCS die geforderten Einheiten zur Verfügung gestellt hat, wird der Verbindungsaufbau nicht beeinflusst.

In the following description, data (SDPs) are provided to the charging center OCS for the determination of the cost of the service (rating). Alternatively, instead of the SDP parameter or the SDP session description parameters AVP and SDP media component AVP, a service indication with the service identifier AVP can also be transmitted to the charging center OCS as a parameter (this is the case, for example). if instead of time, it is charged by volume). In addition, the charging center OCS can be informed of the volume of the SIP signaling, also broken down into "SIP header volume" or "SIP message body volume" (in the message body (message body), additional data such as an image can be transported).

• I. In order to establish a connection to a second network element B-TN, AS, MRFC, the first network element A-TN sends a "SIP INVITE" message via the IMS network to the ge Wanted second network element B-TN, AS, MRFC. The message is forwarded to the service connection status control function S-CSCF, since this network element is responsible for the execution of user-specific services and, of course, for billing the connection. When the solvency check is enabled, the service connection status control function S-CSCF generates a Diameter CCR message upon receipt of a "SIP INVITE" message The parameters (Attribute-Value-Pairs (AVP)) of the The Diameter CCR message must be provided with the following data to allow the Verification Center OCS to perform the solvency check: a) The CC Request Type AVP is set to EVENT REQUEST , b. The Requested Action parameter AVP is set to CHECK BALANCE. c. The SDP session descriptions and SDP media component AVPs specified by the 3GPP are supplied with the corresponding SDP data from the "SIP INVITE" message, and the service connection status control function S-CSCF sets the "SIP INVITE" - message forwarded to the next IMS network element (eg: an I-CSCF). The connection is not interrupted.
• II. The billing center OCS receives the Diameter CCR message and first checks which type of billing (eg online charging) should be performed. The Vergebührungszentrum OCS recognizes by the verification of the "CC request type" and the "Requested Action" that a solvency check should be performed.
• III. The charging center OCS evaluates the delivered SDP information (the SDP describes what type of connection is required, eg voice telephony or video telephony) and determines the cost of the service.
• IV. According to the evaluation of the SDP information, the coverage of the user account is checked. In this case, the user account has sufficient coverage, and the charging center OCS returns this result in the Diameter CCA message to the service connection status control function S-CSCF.
• V. The service connection status control function S-CSCF receives the Diameter CCA message and checks the result obtained in the form of a parameter (Check Balance Result AVP), which in this case has sufficient credit "Enough Credit Accordingly, the connection is not terminated.
• VI. The second network element B-TN, AS, MRFC of the called user sends a "SIP 200 OK" message when the user answers The "SIP 200 OK" message is sent to the service connection status control function S-. CSCF uses to start the "online" service charge.To do this, the service connection status control function S-CSCF starts a configurable timer and generates a Diameter CCR message with the following data: a Type (Request-Type) is set to "EVENT REQUEST". b. The Requested Action parameter (AVP) is set to Direct Charge (DIRECT_DEBITING). This setting causes the amount of money to be immediately deducted from the user account. c. For indication of the service, the data of the SDP is also inserted into the corresponding AVPs (SDP session description and SDP media component AVPs). d. According to the timer of the service connection status control function S-CSCF, the requested service unit (AVP) is filled out. The duration of the timer corresponds to the number of required units. The connection establishment is not stopped when the Diameter CCR message is sent to the charging center OCS. For this reason, there is no delay of the connection setup.
• VII. The charging center OCS receives the Diameter CCR message and first checks which type of "online" charge is to be carried out. The charging center OCS recognizes that, according to the requested type "request type" and the request requested, "Requested- Action ", the amount of money calculated in step VIII should be debited immediately from the user account.
• VIII. The Verification Center OCS evaluates the SDP parameter and determines the cost of the service based on the requested units. The calculated amount will be deducted immediately from the user account.
• IX. In the Diameter CCA message, the charging center OCS returns the granted units to the service connection status control function S-CSCF.
• X. Since the charging center OCS has provided the required units, the connection establishment is not affected.

• I. Nach Beendigung des Gesprächs schickt das erste Netzelement A-TN eine „SIP BYE" – Nachricht. Diese wird über die IMS Netzelemente zu dem zweiten Netzelement B-TN, AS, MRFC geschickt. Wenn die „SIP BYE" – Nachricht die Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF passiert, dann können die nicht verbrauchten Einheiten zurück an das Vergebührungszentrum OCS geschickt werden, und in weiterer Folge kann ein ent sprechender Geldbetrag auf das Nutzerkonto aufgebucht werden. Wenn die Rückbuchung nicht verbrauchter Einheiten erwünscht ist, dann schickt die Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF bei Empfang der „SIP BYE" – Nachricht eine Diameter-CCR-Nachricht mit den folgenden Informationen an das Vergebührungszentrum OCS: a. Der angefragte Typ (Request-Type) wird auf Ereignis-Anfrage (EVENT REQUEST) gesetzt. b. Der Parameter „angefragte Aktion" (Requested-Action AVP) wird auf „Rückbuchen" (REFUND ACCOUNT) gesetzt. Diese Binstellung führt dazu, dass der Geldbetrag, welcher über die Vergebührung (Rating) ermittelt wird auf das Nutzerkonto aufgebucht wird. c. Zur Indikation des Dienstes werden auch die Daten der SDPs in die entsprechenden AVPs eingefügt (SDP-Session-Description und SDP-Media-Component AVPs). d. Der Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF – Timer beinhaltet die verbleibenden Einheiten, diese werden in den Parameter „angefragten Diensteinheiten" (Requested-Service-Unit AVP) übernommen, um diese an das Vergebührungszentrum OCS zurück zu senden.
• II. Das Vergebührungszentrum OCS bestimmt, welche Aktion verlangt wird, zu diesem Zweck werden die Parameter „Request-Type" und „Requested-Action" überprüft. Entsprechend dieser Informationen erkennt das Vergebührungszentrum OCS, dass ein bestimmter Geldbetrag, welcher in Schritt III bestimmt wird, auf das Nutzerkonto aufgebucht werden soll.
• III. Über die SDP Bewertung und die gelieferten Einheiten errechnet das Vergebührungszentrum OCS den Geldbetrag, welcher auf das Nutzerkonto zurückgebucht werden soll.
• IV. Der errechnete Geldbetrag wird auf das Nutzerkonto aufgebucht.
• V. Nachdem der errechnete Geldbetrag erfolgreich aufgebucht wurde, wird eine Diameter-CCA-Nachricht an die Dienste-Verbindungs-Status-Kontroll-Funktion S-CSCF geschickt.

11 shows a second flowchart for the removal of a connection. Disconnection is not interrupted for posting unused units. The service connection status control function S-CSCF must provide at least one service information (parameter) to the charging center OCS, so that the charging center OCS can calculate the costs for each can determine the service. For this purpose, the service connection status control function S-CSCF may specify the 3GPP-specified SDP AVPs or the. Use Service Identifier AVP.

• I. After termination of the call, the first network element A-TN sends a "SIP BYE" message, which is sent via the IMS network elements to the second network element B-TN, AS, MRFC If the "SIP BYE" message contains the services Connection status control function S-CSCF passes, then the unused units can be sent back to the charging center OCS, and subsequently a corresponding amount of money can be credited to the user account. If the rebooking of unused units is desired, then upon receipt of the "SIP BYE" message, the service connection status control function S-CSCF sends a Diameter CCR message with the following information to the charging center OCS: a. The requested type (request type) is set to event request (EVENT REQUEST) b The parameter "requested action" (requested action AVP) is set to "REFUND ACCOUNT" the amount of money which is determined via the charge (rating) is debited to the user account c) For indication of the service, the data of the SDPs are also inserted into the corresponding AVPs (SDP session description and SDP media component AVPs). d. The service connection status control function S-CSCF - Timer contains the remaining units, these are taken over into the Requested-Service-Unit (AVP) parameter in order to transmit them to d the charging center OCS.
• II. The charging center OCS determines what action is required, for this purpose the parameters "Request-Type" and "Requested-Action" are checked. In accordance with this information, the charging center OCS recognizes that a certain amount of money, which is determined in step III, should be debited to the user account.
• III. Using the SDP valuation and the delivered units, the charging center OCS calculates the amount of money that is to be returned to the user account.
• IV. The calculated amount of money will be credited to the user account.
• V. After the calculated amount of money has been successfully debited, a Diameter CCA message is sent to the Service Link Status Control function S-CSCF.

12 shows a device according to the invention for carrying out the method according to 1 and 2 , With a receiving unit E, the device receives at least one signaling message of a first protocol. The processing unit V evaluates the at least one parameter contained in the signaling message and sends the evaluation result with at least one further signaling message of a second protocol via a transmitting unit S of the device to a charging center.

Claims (23)

Method for charging at least one service, which relates to a first network element (A-TN) and a second network element (B-TN, AS, MRFC) of a communication network, characterized in that when sending at least one signaling message of a first protocol between the first network element (TN A) and the second network element (TN B, AS, MRFC) a state element (ZE) at least one parameter that evaluates at least one signaling message indicating the service to be billed, and that the evaluation result with at least one further signaling message of a second protocol sent to a Verification Center (OCS). Method according to claim 1, characterized in that that the at least one further signaling message of a second protocol at least one further parameter for the charging of a Dienstes, which between the first network element (TN A) and the second network element (TN B, AS, MRFC) is transmitted contains. Method according to claim 2, characterized in that that the at least one further parameter from the state unit (ZE) of the at least one further signaling message of a second protocol added becomes. Method according to claim 2, characterized in that that the at least one other parameter of a network element of the IP Multimedia Subsystem (IMS-ZE) and / or a service node of the at least one further signaling message of a second Added protocol becomes. Method according to Claims 2 to 4, characterized that the at least one other parameter the expected duration of the service, a fixed amount of money and / or the expected Data amount of the service indicates. A method according to claim 2 to 5, characterized in that depending on at least one Parameter in at least one signaling message of a first protocol, the expected duration of the service, a fixed amount of money and / or the expected amount of data of the service is determined. Method according to Claims 2 to 6, characterized that in at least one signaling message of a second Protocol contains at least one other parameter, the the unused units by a user of the first network element (A-TN) for indicates the requested service. Method according to claims 2 to 7, characterized that the Verification Center (OCS) is signaled with at least one other parameter that from the Verification Center (OCS) a solvency check of the Account of the user of the first network element (A-TN) are performed should. Method according to claim 2, characterized in that that dependent of at least one parameter in at least one signaling message of a second protocol the expected duration of the service, a fixer Amount of money and / or the expected amount of data of the service of Vergebührungszentrum (OCS) is determined. Method according to one of the preceding claims, characterized characterized in that the signaling message of a first protocol is a SIP message and / or an H.323 message. Method according to one of the preceding claims, characterized characterized in that when sending at least one SIP Subscribe signaling message between the first network element (A-TN) and the second network element (B-TN, AS, MRFC) the state element (ZE) at least one parameter of evaluates at least one SIP Subscribe signaling message. Method according to one of the preceding claims, characterized characterized in that the signaling message of a second Protocol is a Diameter message. Method according to one of the preceding claims, characterized in that the state element (ZE) is a network element of the IP Multimedia Subsystem is. Method according to one of the preceding claims, characterized characterized in that the state element (ZE) is a network element. one Link Status Control (CSCF) function of a network element IP Multimedia Subsystem (IMS-ZE), an application server (AS) and / or a stand alone Network element is. Method according to one of the preceding claims, characterized characterized in that the state element (ZE) is a network element. in a service node of the communication network. Method according to one of the preceding claims, characterized characterized in that the state element (ZE) both signaling messages a first protocol as well as signaling messages of a second protocol can handle. Method according to one of the preceding claims, characterized in that the communication network is a cellular mobile radio network and / or an IP network is. Method according to one of the preceding claims, characterized in that the first network element (A-TN) is a mobile radio terminal, a mobile one Computer, a computer and / or a mobile organizer. Method according to one of the preceding claims, characterized characterized in that the second network element (B-TN, AS, MRFC) a Application server (AS), a mobile radio terminal, a proxy server (MRFC), a presence server, a mobile computer, a computer and / or a mobile organizer is. Device for charging at least one service, which is a first network element (A-TN) and a second network element (B-TN, AS, MRFC) of a communication network, - with a Receiving unit (E) in a state unit (ZE) for receiving at least one signaling message of a first protocol when sending between the first network element (A-TN) and the second Network element (B-TN, AS, MRFC), - with a processing unit (V) in a state unit (ZE) for evaluating at least one parameter the at least one signaling message, the one to be billed Indicates service - With a transmitting unit (S) in a state unit (ZE) for sending the evaluation result with at least one further signaling message of a second protocol to a billing center (OCS). Device according to claim 20, characterized in that in that the state unit (ZE) adds at least one additional one Parameters for the at least one further signaling message a second protocol is provided. Apparatus according to claim 20 and 21, characterized in that as a communication network, a cellular mobile network and / or an IP network are provided. Device according to claim 20 to 22, characterized the state element (ZE) is the processor of both signaling messages a first protocol as well as signaling messages a second protocol is provided.