EP1415437A1 - Kennzeichnung der dienstgüte einer informationsübermittlung in einem kommunikationsnetz - Google Patents

Kennzeichnung der dienstgüte einer informationsübermittlung in einem kommunikationsnetz

Info

Publication number
EP1415437A1
EP1415437A1 EP02772124A EP02772124A EP1415437A1 EP 1415437 A1 EP1415437 A1 EP 1415437A1 EP 02772124 A EP02772124 A EP 02772124A EP 02772124 A EP02772124 A EP 02772124A EP 1415437 A1 EP1415437 A1 EP 1415437A1
Authority
EP
European Patent Office
Prior art keywords
call
data
qos
information
instance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02772124A
Other languages
English (en)
French (fr)
Inventor
Andreas KNÄBCHEN
Rainer Liebhart
Heribert Müller
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Nokia Siemens Networks GmbH and Co KG, Siemens Corp filed Critical Siemens AG
Priority to EP02772124A priority Critical patent/EP1415437A1/de
Publication of EP1415437A1 publication Critical patent/EP1415437A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/781—Centralised allocation of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/5087—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to voice services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/509—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to media content delivery, e.g. audio, video or TV

Definitions

  • the invention relates to methods and devices, in particular computer program products, for storing data for identifying the quality of service of an information transmission in a communication network.
  • Quality of service also called QoS (Quality of Service) - is defined differently depending on the context and subsequently evaluated using different metrics.
  • metrics for measuring quality of service are the maximum number of information that can be transmitted (bandwidth), the number of information transmitted, the number of information not transmitted (loss rate), and the - if necessary averaged - time delay in the transmission ( (Transmission) delay), the - possibly averaged - deviation from the otherwise usual distance between two information transmissions (delay jitter, interarrival jitter), or the number of information not permitted for transmission at all (blocking rate).
  • Line-oriented voice networks are designed for the transmission of continuously flowing (voice) information, also referred to in the specialist world as 'conversation', 'call' or 'session'.
  • the information is usually transmitted with high quality of service and security.
  • Delay jitter without fluctuations in the delay time (delay jitter) is important because speech requires a continuous flow of information when played back in the receiving device.
  • a loss of information can therefore not be compensated for by retransmitting the non-transmitted information and usually leads to an acoustically perceptible crack in the receiving device.
  • the transmission of language is also generally referred to as a 'real-time (transmission) service' or as a 'real-time service'.
  • the quality of service is achieved through appropriate dimensioning and planning of the voice networks, with the transmission capacity generally due to the line orientation. is not subject to fluctuations.
  • Security is achieved, for example, by appropriate spatial and organizational partitioning of the voice networks against unauthorized third parties. In the past, for example, the responsibility for voice networks was often in the hands of the state, which largely prevented listening in by third parties, for example . ,
  • Packet-oriented data networks are designed for the transmission of packet streams also referred to in the technical field as 'data packet streams'. It is usually not necessary to guarantee a high quality of service. Without guaranteed quality of service, the transmission of the data packet streams takes place, for example, with delays that fluctuate over time, since the individual data packets of the data packet streams are usually transmitted in the order in which they are accessed by the network, ie the more packets to be transmitted from a data network, the greater the time delays. In the professional world, the transmission of data is therefore also referred to as a transmission service without real-time conditions or as a 'non-realtime service'. Security plays a subordinate role.
  • LAN local area networks
  • VPN Virtual Private Network
  • the best known data network at the moment is the Internet.
  • the Internet is designed as an open (wide area) data network with open interfaces for connecting (mostly local and regional) data networks from different manufacturers. So far, the main focus has been on providing a manufacturer-independent transport platform. Adequate mechanisms to guarantee quality of service and security play a secondary role. For this reason, increased security is currently being implemented primarily with decentralized filter devices - also called 'firewalls' - located at the interfaces to the Internet. Network-internal quality of service and security mechanisms, however, are hardly yet available.
  • the focus is on the transmission of multimedia information (eg audio or video) on the Internet.
  • multimedia information eg audio or video
  • the packets can consequently be designed as Internet, X.25 or frame relay packets, but also as ATM cells. They are sometimes referred to as 'messages', especially when a message is delivered in a packet.
  • Data packet streams and real-time packet streams are exemplary embodiments of traffic streams transmitted in communication networks. Traffic flows are also referred to as 'connections', even in packet-oriented networks in which a connectionless transmission technology is used.
  • information is transmitted in TCP / IP using so-called flows, through which the sender and receiver (e.g. web server and browser) are connected to one another at a logically abstract level despite the non-connection character of IP, i.e. logically abstracted flows also represent connections.
  • sender and receiver e.g. web server and browser
  • logically abstracted flows also represent connections.
  • the call control level includes an (optional) call controller, which among other things the following functions are assigned:
  • - Admission control (optional): Basic admissibility check as to whether and to what extent (eg VoIP-capable) devices may use the communication network.
  • Bandwidth Control (optional): Management of transmission capacities.
  • Zone management Registration of (eg VoIP-capable) devices and provision of the above functions for all devices registered with the call controller.
  • All signaling messages are conveyed by at least one call controller, i.e. all facilities send and receive signaling messages only via the call controller. A direct exchange of signaling messages between the facilities is prohibited.
  • - Call management management of a list of existing calls, e.g. to to be able to generate a busy signal if this cannot be generated by the device itself.
  • Dialed Digit Translation Translation of the dialed digits into an E.164 telephone number or a number from a private numbering scheme.
  • call controllers are the 'gatekeeper' proposed by the ITU in the H.323 standard family or the 'SIP proxy' proposed by the IETF. If a larger communication network is divided into several domains - also called 'zones' - you can a separate call controller can be provided in each domain. A domain can also be operated without a call controller. If several call controllers are provided in a domain, only one should be used be activated by them. From a logical point of view, a call controller should be seen separately from the facilities.
  • the central element of the resource control level is a resource controller, which among other things The following functions are assigned: - Capacity Control: Control of the traffic volume supplied to the communication network by packet streams, e.g. by controlling the transmission capacity of individual packet streams.
  • Priority management (optional): Set, check and, if necessary, correct the priority indicators in the packets according to the priority of their packet streams if the packets are already marked with priorities.
  • the resource controller is also known as a 'Policy Decision Point (PDP)'. It is often within so-called 'edge routers' - also 'edge devices', 'access nodes' or at
  • PER Internet Service Provider
  • ISP Internet Service Provider
  • PER 'Provider Edge Router
  • the PER can only act as a proxy and forward the resource controller-relevant information to a separate server on which the resource controller is implemented.
  • the principle interaction of call controller and resource controller according to the protocols of the IETF and ITU is explained using the example of a call setup between two VoIP devices designed as subscriber terminals.
  • the authentication, authorization and (start of) accounting steps take place within or in part before the actual call setup when a terminal is dialed into the IP network (e.g. via an Internet service provider).
  • This so-called 'AAA' functionality is usually realized by accessing a subscriber database in which all users are stored with their IDs, passwords, rights, etc. This access is slow and comparatively complex.
  • IP network e.g. via an Internet service provider.
  • this AAA process usually takes place once during the user dial-in.
  • a further authentication takes place when a call controller is used if the end device registers with the call controller (e.g. a SIP proxy or an H.323 gatekeeper) of the Internet service provider.
  • the call controller e.g. a SIP proxy or an H.323 gatekeeper
  • H.323 Draft v4 (07/2000)
  • this authentication or registration of a terminal device is carried out with the assigned gatekeeper in accordance with the RAS (Registration, Admission, Status) protocol.
  • the RAS protocol is described in the ITU standard H.225.0 (complete reference cited above).
  • the actual call setup usually begins with the participants' end devices swapping their abilities (eg list of supported codecs) in a first step in order to determine the required resources (eg bandwidth) and the required QoS (eg delay, jitter) .
  • the terminals are designed, for example, as IP telephones; in the case of online video, one of the terminals would be a content or application server, for example in the network of the Internet service provider (ISP).
  • the signaling messages are exchanged either directly between the terminals or by means of at least one call controller. For each call, each variant and the direction of transmission determine which variant is used.
  • the first step in order to determine the required resources (eg bandwidth) and the required QoS (eg delay, jitter)
  • the terminals are designed, for example, as IP telephones; in the case of online video, one of the terminals would be a content or application server, for example in the network of the Internet service provider (ISP).
  • the signaling messages are exchanged either directly between the terminals or by means
  • Variant is e.g. in H.323 Draft v4 (07/2000) referred to as 'direct endpoint call signaling' and the second as 'gatekeeper routed call signaling'.
  • direct endpoint call signaling copies of selected signaling messages can be sent to a call controller.
  • a call controller thus often has knowledge of the resource and QoS requirements coordinated between the end devices. However, these requirements are not actively influenced or verified by the call itself.
  • the resource and QoS request coordinated in this way can be transmitted directly from the participants' end devices to their assigned resource controller.
  • the resource controller After checking the resource and Qo ⁇ request, the resource controller sends a confirmation (or rejection) back to the end device.
  • a 'policy' is activated in the edge router and possibly other routers in the network, with which these routers check and ensure that the traffic caused by the terminal device is within the limits specified in the request .
  • RSVP Resource reSerVation Protocol
  • a plurality of messages are sent which are only used to coordinate the components involved with one another, but not to transmit the “actual information” between the end devices.
  • This information transmitted with the messages is usually referred to as' signaling information ',' signaling data 'or simply as' signaling tion '.
  • the term is to be understood broadly.
  • the messages according to the RAS protocol the messages according to the ITU standard H.245 for controlling user channels of existing calls and all other similarly designed messages are also included.
  • the signaling protocol for establishing a connection (call setup) and clearing (call release) according to the ITU is described, for example, in standard H.225.0, "Media Stream Packetization and Synchronization on Non-Guaranteed QoS LANs", 2000, which is based on the IETF in RFC 2453bis, "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2453bis-02.txt, 09/2000.
  • the "actual information” is also called “useful information", “media information”, “media data” or simply "media” to distinguish it from the signaling.
  • out-of-band means the transmission of information on a different path / medium than the paths provided in the communication network for the transmission of signaling and useful information.
  • this includes a local configuration of devices on site, which e.g. is carried out with a local control device.
  • 'in-band' information is transmitted in the same way / medium, possibly logically separated from the signaling and useful information considered.
  • VoIP Voice over IP
  • an operator can be promised a certain quality of service by an operator in advance.
  • all traffic flows are affected by fluctuations in the network load, which is why the promised quality of service high network load could in principle be undercut.
  • an inventive, preferably continuous, acquisition of data for identifying the actual quality of service of each VoIP transmission could be helpful, since in the event of a dispute, this makes traceable data available
  • measuring devices in the network are generally referred to as sniffers or probing systems, which monitor information transmissions and, in the case of active systems, feed information directly into the network to measure the actual quality of service.
  • sniffers or probing systems which monitor information transmissions and, in the case of active systems, feed information directly into the network to measure the actual quality of service.
  • VoIP there are also measuring devices that act as end devices, initiate information transfers and measure the transmission quality of the information transfer.
  • end devices initiate information transfers and measure the transmission quality of the information transfer.
  • this can only be done with random samples, and this method does not help with customer complaints about their end device, their special network access and especially their subjectively experienced actual quality of service.
  • a service technician would have to replace the subscriber's terminal device with a measuring device on site, for example, in order to then collect quality data in response to the customer's complaint.
  • This method does not allow conclusions to be drawn about past quality losses, for example as a result of excessive network load (also known as 'congestion in the network'). It also cannot be used to demonstrate that the actual quality of service continuously corresponds to or has complied with an agreed quality of service. It is also known to collect quality data at (network-internal) intermediate points of an information transmission, for example at interfaces (also called 'gateways') between networks (for example an interface between a line-oriented voice network and a packet-oriented, integrated voice-data network) or at Concentration points (also called 'multiplexers'), at which a multitude of information transmissions are combined by static or statistical multiplexing to form a higher bit rate information stream in order to be transmitted in a common channel.
  • interfaces also called 'gateways'
  • Concentration points also called 'multiplexers'
  • a transmitter should be able to adapt its transmission behavior depending on the statistical data received (flow and overload control) during the transmission of information.
  • a recipient should be able to deduce whether a problem originates from a local, regional or global cause (error localization).
  • a network monitor should be able to evaluate the performance of the network for transmitting information (network performance).
  • the focus here is on the network as a whole, but not on individual transfers of information.
  • RFC2705 or RFC1889 there is no indication in either RFC2705 or RFC1889 that this data can be used to identify the quality of service of an information transmission, especially to save it.
  • this method does not scale because the effort in the intermediate nodes, for example designed as gateways or multiplexers, increases linearly with the number of information streams transmitted. Because of its use in intermediate nodes, it is primarily geared towards internal control of the performance of a network as a whole through flow and overload control of individual information streams, but is not taken in itself to identify the quality of service of individual information transmissions.
  • the information streams of a bidirectional information transmission are routed separately, only a unidirectional measurement is primarily possible. A subordinate processing step is then required for a bidirectional measurement result.
  • An object of the invention is to show a way which enables an efficient, continuous acquisition of data to identify the actual quality of service of every information transmission in a communication network.
  • the solution scales. Only data on the information transmissions assigned to the end point need to be recorded for each end point. Furthermore, in contrast to an intermediate node, there are usually only one in a terminal limited and mostly largely constant number of endpoints combined (in the case of an H.323 terminal, for example, one each for the forward and backward direction of audio and video, one for H.245 signaling and one for H.225.0 signaling for the assigned gatekeeper).
  • An increase in the number of information transmissions in a network usually takes place through an increase in the number of terminals connected to the network, but not through a (significant) increase in the end points per terminal, so that the load per terminal caused by the data acquisition and transmission according to the invention largely uniform, ie constant, remains.
  • the actual quality of service present in the end point can be continuously measured and also verified at any time by storing the data.
  • Evidence of the actual quality of service is essential for the acceptance of the concepts proposed by the IETF and ITU, as this can make it clear to the participants that a quality of service guaranteed to them is not only promised, but actually made available.
  • the invention is generic and conceptually interoperable since it is independent of a concrete solution.
  • the advantageous effect is associated with an object in which the instance is arranged in the call control level in a communication network comprising a call control level and a resource control level, in particular in a call controller provided in the call control level, that there is no need for separate addressing of the instance for the endpoints, since the already existing address of the call controller can be used instead. This means that there is no longer any need to configure the address of the instance in the end devices to which the respective end points are assigned.
  • An object in which the data in a bidirectional information transmission characterize the quality of service of both transmission directions advantageously eliminates any subsequent correlation of unidirectional measurement results of the two transmission directions to a bidirectional measurement result.
  • the effort for the transmission of information and on ⁇ are wall for the transmission of data at separate times, whereby the endpoint advantageously not especially during the usually relatively complex information transfer is burdened by an additional transmission.
  • the advantageous effect is connected that the solution conforms to the standards, no additional proprietary protocols or messages are required. Furthermore, the additionally inserted data will have no effect on network elements (transparency) that are not involved in this technology: as before, they only react to the original part of the messages (interoperability with legacy network elements).
  • the advantageous effect is that the existing, standardized messages are not modified at all, which is then very important is if no additional, possibly proprietary protocol elements are provided in these messages.
  • Figure 1 shows an arrangement for performing the method according to the invention with a call control level, a resource control level and two end points one information transfer
  • FIG. 2 shows an exemplary embodiment of the arrangement according to FIG. 1 with computer program products for implementing the method according to the invention
  • FIG. 1 shows an exemplary arrangement for carrying out the method according to the invention, which is designed as a communication network with a call control level CCL, a resource control level RCL and two end points A, B of an information transmission.
  • a separate instance SP for storing data QSD, BILL is arranged in the CCL level.
  • An information transmission CALL is shown between the end points A, B, which is mediated by the RCL level and for which the data QSD for identifying the quality of service of the information transmission CALL is recorded in the terminals A, B.
  • messages N are shown between the terminals A, B and the level CCL with which the acquired data QSD are transmitted to the instance SP.
  • FIG. 2 shows a more detailed embodiment of the arrangement according to FIG. 1.
  • the level CCL comprises two call controllers CC, the call controller CC assigned to the end point A being designed as a gatekeeper CC GK and the call controller CC assigned to the end point B being designed as a SIP proxy CC SIP .
  • two configurations SPi, SP 2 of the separate instance SP are shown. The first is designed as an externally implemented separate instance SPi, which is assigned to the gatekeeper CC GK . It could also be assigned to the SIP proxy CC SIP and act as the only instance SP in the CCL level.
  • the second is designed as an integrated realized separate instance SP2, which is integrated in the SIP proxy CC SIP .
  • the first instance SPi is assigned a database DB ⁇ and the second instance SP 2 a database DB B for storing the data QSD, BILL, in the second case the assignment being made via the SIP proxy CC SIP .
  • the databases DB are accessed, for example, using the LDAP protocol (Lightweight Directory Access Protocol). Signaling messages N may be exchanged between the two call controllers CC.
  • the RCL level comprises a central resource controller RC.
  • Two edge routers PER A , PER B are assigned to this for the transmission of information in a communication network.
  • a protocol COPS Common Open Policy Service
  • Protocol SIP Session Initiation Protocol
  • the data QSD are also transmitted.
  • the data QSD could be transmitted in additional, possibly non-standardized, messages N PROP .
  • the edge devices PER A and PER B for example, one of the protocols RSVP, DiffServ, MPLS or COPS is used to reserve resources.
  • a conversation CALL is shown between the end points A and B.
  • the information is transmitted in the communication network using an RTP (Real Time Protocol) protocol.
  • RTP Real Time Protocol
  • RTCP Real Time Control Protocol
  • control variables evaluated according to the invention are also transmitted between the two end points A, B for the data QSD.
  • the communication network is designed, for example, as an IP network. It is obvious to the person skilled in the art that the invention can of course be used in other network types such as, for example, the Internet, intranet, extranet, a local area network (LAN) or one designed, for example, as a virtual private network (VPN) internal network (Corporate Network).
  • VPN virtual private network
  • terminals A and B the call controllers CC and the edge devices PER
  • computer program products P according to the invention are provided, each of which comprises software code sections for the processor-supported execution of the method according to the invention.
  • parts of the computer program products P can also run on special hardware (e.g. crypto processors).
  • the behavior and interaction of the call controller CC, the end points A, B and the instance or instances SP is carried out as an example in the context of an information transmission CALL.
  • the information transmission CALL is also referred to as a conversation CALL.
  • the terminal A with the gatekeeper CC G ⁇ REGIST is riert.
  • the registration is requested by the terminal A with an H.225.0 Registration Request RRQ and answered by the gatekeeper CC GK with an H.225.0 Registration Confirm RCF or with an H.225.0 Registration Reject RRJ.
  • the end point A is then verified by the gatekeeper CC GK , ie authenticated, authorized, etc.
  • user-specific data which are stored, for example, in a database DB A , are accessed using the LDAP protocol or another DB query protocol.
  • the gatekeeper CC GK also determines whether the call signaling should be mediated by itself (gatekeeper routed call signaling) or directly between the end points A, B (direct endpoint call signaling), if necessary with notification to the gatekeeper CC GK on major changes.
  • the terminal B is registered with the SIP proxy CC SIP .
  • call signaling in particular a call setup, is fundamentally possible between the two end devices A, B.
  • This is initiated, for example, by endpoint A by requesting the establishment of the call CALL to endpoint B from gatekeeper CC GK with an H.225.0 admission request ARQ.
  • This ARQ could also contain a QoS requirement.
  • the gatekeeper CC GK then performs authentication and authorization related to the CALL conversation. This also includes an assessment of the QoS requirement. This can be determined, for example, by means of capability negotiation between the two end points A, B, which is effected by means of further H.225.0 messages. With gatekeeper routed call signaling, this is then directly known to the gatekeeper CC GK .
  • the gatekeeper CC GK With direct endpoint call signaling, it could be communicated to the gatekeeper CC G ⁇ .
  • the gatekeeper CC GK starts charging the call CALL, further data BILL being generated. If the terminal B accepts the call CALL, this is indicated to the gatekeeper CC GK by a CONNECT message.
  • an RSVP QoS request is transmitted from the end point A to the Edgedevice PER A.
  • the Edgedevice now carries out a further verification of the QoS requirement.
  • a query is sent to the resource controller RC using the standardized COPS protocol. This checks whether the requested QoS can be made available in the communication network.
  • the Resource Controller RC knows the entire available (or occupied) resources in the communication network in order to be able to send a response to the COPS query.
  • the edge device PER A After receiving the response from the resource controller RC, the edge device PER A reacts as follows: Either the QoS Anforde ⁇ tion due to overload in the communication network rejected or the requested QoS is set configurationally in the communication network, for example by dynamic activation of a policy or alternatively to the RSVP scheduling in Edgedevice PER A by forwarding the RSVP reservation through the network to the other Edgedevice PER B or end point B.
  • end point A After receiving a positive RSVP response from Edgedevice PER A , end point A begins to transmit information. The charge will now be activated at the latest.
  • the media data are transmitted, for example, in accordance with the RTP protocol.
  • additional data for flow control of the call CALL are also transmitted in accordance with the RTCP protocol and the data QSD are recorded in the terminals A, B, taking into account the signaling data of the RTCP protocol that actually serves for flow control.
  • the data QSD recorded in the end point A, B can characterize the quality of service of both transmission directions, even if the two transmissions take place on the RCL level in different ways, because in one end point these two are transmitted - Averages summarized again so that the QoS-characterizing data QSD can be recorded for both directions of transmission. A subsequent merging of separately recorded data QSD is not necessary.
  • the data QSD are temporarily stored in the terminals A, B or are transmitted essentially directly to the separate instance SP. For example, the latter takes place at regular intervals of a few seconds.
  • the end point A and the gatekeeper CC GK can keep regularly exchanged Alive messages are in constant communication (see H.225.0 (02/98), chap. 7.9.1 and 7.9.2, parameter timeToLive in Message Registration Confirm RCF for setting the lifetime of the registration and parameter eepAlive in Message Registration Request RRQ for refreshing, ie extending the life of an existing registration).
  • the period of these keep alive messages is usually regular and in the range of seconds.
  • the data QSD can be included in these messages.
  • the end of the call CALL is indicated by terminal A or B.
  • the gatekeeper CC GK ends the optionally started charging for the call CALL.
  • the reservation of the call CALL expires in the communication network after a short time.
  • the Resource Controller RC can reassign the released resources.
  • the completion of the call CALL is also notified to the call controller CC S ⁇ P by the signaling.
  • the data QSD When the data QSD is buffered, it is transmitted to the instance SP after the information transmission CALL, according to an embodiment of the invention.
  • This transmission according to the invention is carried out with the aid of existing messages N H , which in this exemplary embodiment are designed in accordance with the H.323 standard family or the SIP protocol. 22 5.o / N SIP takes place by inserting the data QSD, for example, as project-specific elements in existing, possibly special message fields, which are provided in the relevant standards, for example, as free fields without function information (optional parameters).
  • separate messages Np R op are also possible for the transmission of the information relevant to the invention.
  • the data QSD are stored in the database DB by the instance SP. According to one embodiment of the invention, the data QSD together with the optionally formed data BILL become Charge for the call CALL saved. In this way, a particularly efficient verification of the quality of a charge-free call CALL is possible, since, as a result of the common storage, no subsequent assignment as part of postprocessing is required.
  • the terminals A, B are ready to set up further calls CALL.
  • the terminals A, B are preferably designed such that the described acquisition and storage of the data QSD according to the invention is carried out with every call CALL.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

In einem Kommunikationsnetz, das eine Call Control Ebene CCL, eine Resource Control Ebene RCL und zumindest einem einer Informationsübermittlung zugeordneten Endpunkt A umfasst, wird eine für eine Informationsübermittlung ermittelte QoS Anforderung RQ lediglich in der Call Control Ebene CCL aufwändig verifiziert. Im Anschluss wird hieraus ein verschlüsseltes Token T gebildet und über den Endpunkt A an die Resource Control Ebene RCL übermittelt. Letztere verifiziert eine vom Endpunkt A eingehende QoS Anforderung RQ lediglich mit Hilfe des entschlüsselten Tokens T. Im Erfolgsfall wird das Kommunikationsnetz derart konfiguriert, dass die Informationen mit der erfindungsgemäß verifizierten QoS übermittelt werden. Die Erfindung ermöglicht eine effiziente, sichere und korrekte Bereitstellung von QoS in integrierten Sprach- und Datennetzen. Insbesondere werden weitreichende Modifikationen bestehender Router der Resource Control Ebene RCL vermieden. Bei regelmäßig wiederholter Übermittlung der Token T wird zudem ein konsistentes Auslösen der bereitgestellten QoS sowie eine sichere und korrekte Vergebührung der Informationsübermittlung unterstützt.

Description

Beschreibung
Kennzeichnung der Dienstgüte einer Informationsübermittlung in einem Kommunikationsnetz
Die Erfindung betrifft Verfahren und Vorrichtungen, insb. Computerprogrammprodukte, zur Speicherung von Daten zur Kennzeichnung der Dienstgüte einer Informationsübermittlung in einem Kommunikationsnetz.
In der Vergangenheit haben sich zwei wesentliche Typen von Kommunikationsnetzen zur Übermittlung von Informationen herausgebildet: Paketorientierte Datennetze und leitungsorien- tierte Sprachnetze. Sie unterschieden sich u.a. durch ihre unterschiedlichen Dienstgüte-Anforderungen.
Dienstgüte - auch QoS (Quality of Service) genannt - wird je nach Kontext unterschiedlich definiert und in der Folge mit jeweils unterschiedlichen Metriken bewertet. Bekannte Beispiele für Metriken zur Messung von Dienstgüte sind die maximal übermittelbare Anzahl von Informationen (Bandwidth) , die Anzahl der übermittelten Informationen, die Anzahl der nicht übermittelten Informationen (Loss Rate) , die - ggf. gemittel- te - zeitliche Verzögerung bei der Übermittlung ( (Transmission) Delay) , die - ggf. gemittelte - Abweichung vom ansonsten üblichen Abstand zwischen je zwei Informationsübermittlungen (Delay Jitter, Interarrival Jitter) , oder die Anzahl der erst gar nicht zur Übermittlung zugelassenen Informationen (Blo- cking Rate) .
Leitungsorientierte Sprachnetze sind auf die Übermittlung von in der Fachwelt auch als 'Gespräch', 'Call' oder 'Session' bezeichneten kontinuierlich strömenden (Sprach-) Informatio- nen ausgelegt. Die Übermittlung der Informationen erfolgt hierbei üblicherweise mit hoher Dienstgüte und Sicherheit. Beispielsweise ist für Sprache eine minimale - z.B. < 200 ms - Verzögerung (Delay) ohne Schwankungen der Verzögerungszeit (Delay-Jitter) wichtig, da Sprache bei Wiedergabe im Empfangsgerät einen kontinuierlichen Informationsfluss erfordert. Ein Informationsverlust kann deshalb nicht durch ein nochmaliges Übermitteln der nicht übermittelten Information ausgeglichen werden und führt im Empfangsgerät üblicherweise zu einem akustisch wahrnehmbaren Knacksen. In der Fachwelt wird die Übermittlung von Sprache verallgemeinert auch als 'Echtzeit- (Übermittlungs-) Dienst ' bzw. als ' Realtime- Service' bezeichnet. Die Dienstgüte wird durch entsprechende Dimensionierung und Planung der Sprachnetze erreicht, wobei die Übermittlungskapazität selbst infolge der Leitungsorientierung grds . keinen Schwankungen unterliegt. Die Sicherheit wird beispielsweise durch entsprechende räumliche und organi- satorische Abschottung der Sprachnetze gegen unbefugte Dritte bewirkt. So lag in der Vergangenheit z.B. die Zuständigkeit für Sprachnetze häufig in staatlicher Hand, wodurch z.B. ein Mithören durch Dritte weitgehend ausgeschlossen werden konnte..
Paketorientierte Datennetze sind auf die Übermittlung von in der Fachwelt auch als 'Datenpaketströme' bezeichneten Paketströmen ausgelegt. Hierbei muss üblicherweise keine hohe Dienstgüte garantiert werden. Ohne garantierte Dienstgüte erfolgt die Übermittlung der Datenpaketströme z.B. mit zeitlich schwankenden Verzögerungen, da die einzelnen Datenpakete der Datenpaketströme üblicherweise in der Reihenfolge ihres Netzzugangs übermittelt werden, d.h. die zeitlichen Verzögerungen werden umso größer, je mehr Pakete von einem Datennetz zu übermitteln sind. In der Fachwelt wird die Übermittlung von Daten deshalb auch als Übermittlungsdienst ohne Echtzeitbedingungen bzw. als 'Non-Realtime-Service' bezeichnet. Sicherheit spielt eine untergeordnete Rolle. Sie wird in kleineren Netzen wie z.B. lokalen Netzen (LAN) bzw. firmeninter- nen Netzen (Corporate Network - auch Virtual Private Network (VPN) genannt) meist durch räumliche Abschottung der Netze bewirkt, da man in diesen Netzen nur Teilnehmer findet, die von vornherein berechtigt sind (sog. ' friendly users').
Das zur Zeit bekannteste Datennetz ist das Internet. Das Internet ist als offenes (Weitverkehrs-) Datennetz mit offe- nen Schnittstellen zur Verbindung von (zumeist lokalen und regionalen) Datennetzen unterschiedlicher Hersteller konzipiert. Das Hauptaugenmerk liegt deshalb bisher auf der Bereitstellung einer hersteller-unabhängigen Transportplattform. Adäquate Mechanismen zur Garantie von Dienstgüte und Sicherheit spielen eine nebengeordnete Rolle. Zur Zeit wird eine erhöhte Sicherheit deshalb vor allem mit dezentralen, an den Schnittstellen zum Internet platzierten Filtereinrichtungen - auch 'Firewalls' genannt - realisiert. Netzinterne Dienstgüte- und Sicherheitsmechanismen sind jedoch noch kaum vorhanden.
Im Zuge der Konvergenz von leitungsorientierten Sprach- und paketorientierten Datennetzen werden Sprachübermittlungs- dienste und zukünftig auch breitbandigere Dienste wie z.B. Übermittlung von Bewegtbildinformationen, ebenfalls in paketorientierten Datennetzen realisiert, d.h. die Übermittlung der bisher üblicherweise leitungsorientiert übermittelten Echtzeitdienste erfolgt in einem konvergenten Sprach-Daten- Netz paketorientiert, d.h. in Paketströmen. Diese werden auch 'Echtzeitpaketströme' genannt. Hierbei ergibt sich das Problem, dass für eine paketorientierte Realisierung eines Echtzeitdienstes eine hohe Dienstgüte erforderlich ist, damit diese mit einer leitungsorientierten Übermittlung qualitativ vergleichbar ist, während zeitgemäße Datennetze und insb. das Internet keine adäquaten Mechanismen zur Garantie einer hohen Dienstgüte vorsehen.
Im folgenden sei auf die Übermittlung von multimedialen Informationen (z.B. Audio oder Video) im Internet fokussiert. Dies stellt jedoch keine wesentliche Einschränkung dar, denn die Dienstgüte-Anforderungen sind nicht speziell für das Internet ausgebildet, sondern gelten allgemein für alle Typen von Datennetzen. Sie sind unabhängig von der konkreten Ausgestaltung eines Datennetzes. Die Pakete können folglich als Internet-, X.25- oder Frame-Relay-Pakete, aber auch als ATM- Zellen ausgebildet sein. Sie werden zuweilen auch als 'Nach- richten' bezeichnet, v.a. dann, wenn eine Nachricht in einem Paket übermittelt wird. Datenpaketströme und Echtzeitpaketströme sind hierbei Ausführungsbeispiele von in Kommunikationsnetzen übermittelten Verkehrsströmen. Verkehrsströme werden auch als 'Verbindungen' bezeichnet, und zwar auch in paketorientierten Netzen, in denen eine verbindungslose Übermittlungs-Technik zum Einsatz kommt. Beispielsweise erfolgen Informationsübermittlung bei TCP/IP mit Hilfe von sog. Flows, durch die Sender und Empfänger (z.B. Web Server und Browser) trotz des erbindungslosen Charakters von IP auf logisch abstrakter Ebene miteinander verbunden werden, d.h. logisch abstrahiert stellen auch Flows Verbindungen dar.
Für die Übermittlung von Sprach- und Bildinformationen über ein paketorientiertes IP-Netz (bspw. das Internet) - auch 'VoIP' genannt - sind in den internationalen Standardisierungsgremien IETF (Internet Engineering Task Force) und ITU (International Telecommunications Union) mehrere Architekturen beschrieben. Allen ist gemeinsam, dass die Call Control Ebene und die Resource Control Ebene funktional voneinander getrennt werden.
Die Call Control Ebene umfasst einen (optionalen) Call Controller, dem u.a. folgende Funktionen zugeordnet sind:
- Address Translation: Umsetzung von E.164 Telephonnummern und anderen Alias Adressen (z.B. Rechnernamen) auf Transportadressen (z.B. Internetadressen).
- Admission Control (optional) : Grundsätzliche Zulässig- keitsprüfung, ob und in welchem Umfang (z.B. VoIP fähige) Einrichtungen das Kommunikationsnetz nutzen dürfen. - Bandwidth Control (optional) : Verwaltung von Übermittlungskapazitäten. - Zone Management: Registrierung von (z.B. VoIP fähigen) Einrichtungen und Bereitstellung obiger Funktionen für alle beim Call Controller registrierten Einrichtungen.
Optional können einem Call Controller zudem folgende Funktionen fallweise zugeordnet werden:
- Call Control Signalling: Alle Signalisierungsnachrichten werden von zumindest einem Call Controller vermittelt, d.h. alle Einrichtungen schicken und erhalten Signalisie- rungsnachrichten nur über den Call Controller. Ein direkter Austausch von Signalisierungsnachrichten zwischen den Einrichtungen ist untersagt.
- Call Authorization: Zulässigkeitsprüfung für eingehende und ausgehende Calls. - Bandwidth Management: Steuerung der zulässigen Anzahl von Einrichtungen, die gleichzeitig das Kommunikationsnetz nutzen dürfen.
- Call Management: Verwaltung einer Liste bestehender Gespräche, um z.B. ein Besetzzeichen erzeugen zu können, falls dies von der Einrichtung selbst nicht erzeugt werden kann.
- Alias Address Modification: Rückgabe einer modifizierten Alias Adresse, bspw. mit einer H.225.0 (vollständige Referenz a.a.O.) Nachricht ACF (Admission Confirm) . Diese Ad- resse muss der Endpunkt beim Verbindungsaufbau verwenden.
- Dialed Digit Translation: Übersetzung der gewählten Ziffern in eine E.164 Telephonnummer oder eine Nummer aus einem privaten Nummerierungsschema.
Beispiele für Call Controller stellen der von der ITU in der H.323 Standard Familie vorgeschlagene 'Gatekeeper' oder der von der IETF vorgeschlagene 'SIP-Proxy' dar. Wird ein größeres Kommunikationsnetz in mehrere Domänen - auch 'Zonen' genannt - gegliedert, kann in jeder Domäne ein separater Call Controller vorgesehen werden. Eine Domäne kann auch ohne einen Call Controller betrieben werden. Sind mehrere Call Controller in einer Domäne vorgesehen, soll nur ein einziger von diesen aktiviert sein. Ein Call Controller ist aus logischer Sicht getrennt von den Einrichtungen zu sehen. Physikalisch muss er jedoch nicht in einer separaten Call Controller Einrichtung realisiert sein, sondern kann auch in jedem End- punkt einer Verbindung (bspw. ausgebildet als H.323 Endpunkt: Endgerät, Gateway, Multipoint Control Unit, etc.) oder auch einer zur programmgesteuerten Datenverarbeitung ausgebildeten Einrichtung (beispielsweise: Rechner, PC, usw.) vorgesehen werden. Auch eine physikalisch verteilte Realisierung ist möglich.
Die Resource-Control-Ebene umfasst als zentrales Element einen Resource-Controller, dem u.a. folgende Funktionen zugeordnet sind: - Capacity Control: Steuerung des dem Kommunikationsnetz durch Paketströme zugeführten Verkehrsvolumens, z.B. durch Kontrolle der Übermittlungskapazität einzelner Paketströme.
- Policy Activation (optional) : ggf. für einen priorisierten Paketstrom Resourcen im Kommunikationsnetz für dessen Ü- bermittlung reservieren.
- Priority Management (optional) : Prioritätskennzeichen in den Paketen entsprechend der Priorität ihrer Paketströme setzen, kontrollieren und gegebenenfalls korrigieren, falls die Pakete bereits mit Prioritäten gekennzeichnet sind.
Der Resource Controller wird auch als 'Policy Decision Point (PDP) ' bezeichnet. Er ist häufig innerhalb von sog. 'Edge Routern' - auch 'Edge Devices', 'Zugangsknoten' oder bei
Zuordnung zu einem Internet Service Provider (ISP) 'Provider Edge Router (PER) ' genannt - realisiert. Alternativ kann der PER auch nur als Proxy fungieren und Resource Controller relevante Informationen an einen separaten Server weiterlei- ten, auf dem der Resource Controller realisiert ist. Das prinzipielle Zusammenwirken von Call Controller und Resource Controller gemäß den Protokollen der IETF und ITU (siehe H.323 Draft v4 (07/2000), Appendix II) sei am Beispiel eines Call Setup zwischen zwei als Teilnehmerendgeräte ausge- bildeten VoIP Einrichtungen erläutert.
Innerhalb oder teilweise auch zeitlich vor dem eigentlichen Call Setup laufen bei Einwahl eines Endgeräts in das IP-Netz (z.B. über einen Internet Service Provider) die Schritte Äuthentisierung, Autorisierung und (Start des) Accounting ab. Diese sogenannte 'AAA' Funktionalität wird üblicherweise durch den Zugriff auf eine Subscriber-Datenbank, in der alle Nutzer mit ihren Kennungen, Passwörtern, Rechten, etc. gespeichert sind, realisiert. Dieser Zugriff ist langsam und vergleichsweise komplex. In den heutigen "Best Effort" IP
Netzen findet dieser AAA Vorgang normalerweise ein Mal während des Einwählens des Nutzers statt. Eine weitere Äuthentisierung erfolgt bei Einsatz eines Call Controllers, wenn sich das Endgerät beim Call Controller (z.B. einem SIP Proxy oder einem H.323 Gatekeeper) des Internet Service Providers registriert. Nach dem H.323 Draft v4 (07/2000) wird diese Äuthentisierung bzw. Registrierung eines Endgeräts beim zugeordneten Gatekeeper gemäß dem RAS (Registration, Admission, Status) Protokoll durchgeführt. Das RAS Protokoll ist im ITU- Standard H.225.0 (vollständige Referenz a.a.O.) beschrieben.
Der eigentliche Call Setup beginnt üblicherweise damit, dass in einem ersten Schritt die Endgeräte der Teilnehmer ihre Fähigkeiten (z.B. Liste der unterstützten Codecs) austau- sehen, um die benötigten Ressourcen (z.B. Bandbreite) und die geforderte QoS (z.B. Delay, Jitter) zu bestimmen. Die Endgeräte sind bei Sprachtelephonie z.B. als IP-Telephone ausgebildet, bei Online-Video wäre eines der Endgeräte ein Content- bzw. Application-Server, z.B. im Netz des Internet Service Providers (ISP) . Der Austausch der Signalisierungsnachrichten erfolgt entweder direkt zwischen den Endgeräten oder unter Vermittlung zumindest eines Call Controllers. Hierbei ist bei jedem Call für jedes Endgerät und für jede Übertragungsrichtung individuell festgelegt, welche Variante zum Einsatz kommt. Die erste
Variante wird z.B. in der H.323 Draft v4 (07/2000) als 'Direkt Endpoint Call Signalling' und die zweite als 'Gatekeeper Routed Call Signalling' bezeichnet. Bei Direct Endpoint Call Signalling können an einen Call Controller ggf. Kopien ausge- wählter Signalisierungsnachrichten übermittelt werden. Ein Call-Controller hat somit häufig Kenntnis von den zwischen den Endgeräten abgestimmten Ressourcen- und QoS-Anforderun- gen. Diese Anforderungen werden jedoch von ihm selbst nicht aktiv beeinflusst oder verifiziert.
In einem zweiten, optionalen Schritt kann die derart abgestimmte Ressourcen- und QoS-Anforderung direkt von den Endgeräten der Teilnehmer an ihren zugeordneten Resource Controller übermittelt werden. Nach Prüfung der Ressourcen- und QoΞ- Anforderung wird von dem Resource Controller eine Bestätigung (oder Ablehnung) an das Endgerät zurückgeschickt.
In einem dritten, ebenfalls optionalen Schritt wird im Edge Router und gegebenenfalls weiteren Routern im Netz eine ' Po- licy' aktiviert, mit der diese Router prüfen und gewährleisten, dass der vom Endgerät verursachte Verkehr innerhalb der Grenzen liegt, die in der Anforderung spezifiziert wurden. Ein Beispiel für einen derartigen Reservierungsmechanismus ist RSVP (Resource reSerVation Protocol) .
Zur Durchführung der drei Schritte wird eine Mehrzahl von Nachrichten versendet, die lediglich zur Abstimmung der beteiligten Komponenten untereinander, jedoch nicht zur Übermittlung der "eigentlichen Informationen" zwischen den Endge- raten dienen. Diese mit den Nachrichten übermittelten Informationen werden üblicherweise als ' Signalisierungsinformatio- nen', ' Signalisierungsdaten' bzw. schlicht als 'Signalisie- rung' bezeichnet. Der Begriff ist dabei weit zu verstehen. So sind z.B. neben den Signalisierungsnachrichten auch die Nachrichten gemäß dem RAS Protokoll, die Nachrichten gemäß dem ITU-Standard H.245 zur Steuerung von Nutzkanälen bestehender Gespräche sowie alle weiteren ähnlich ausgebildeten Nachrichten umfasst. Das Signalisierungsprotokoll für den Verbindungsaufbau (Call Setup) und -abbau (Call Release) nach der ITU ist z.B. im Standard H.225.0, "Media Stream Packetization and Synchronisation on Non-Guaranteed QoS LANs", 2000 be- schrieben, das nach der IETF im RFC 2453bis, "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2453bis-02.txt, 09/2000. Die "eigentlichen Informationen" werden zur Unterscheidung von der Signalisierung auch 'Nutzinformationen', 'Medieninformationen', 'Mediendaten' oder schlicht 'Medien' genannt.
In diesem Zusammenhang versteht man unter 'out-of-band' die Übermittlung von Informationen auf einem anderen Weg / Medium als den im Kommunikationsnetz zur Übermittlung von Signali- sierungs- und Nutzinformationen vorgesehenen Wegen. Insbesondere ist hiervon eine lokale Konfiguration von Einrichtungen vor Ort umfasst, die z.B. mit einer lokalen Steuereinrichtung vorgenommen wird. Demgegenüber werden bei 'in-band' Informationen auf dem gleichen Weg / Medium, ggf. logisch getrennt von den betrachteten Signalisierungs- und Nutzinformationen, übermittelt .
Aufgrund des bisher Ausgeführten wird klar, dass eine Realisierung von VoIP bei den Teilnehmern nur dann breite Akzep- tanz finden wird, wenn die zugehörigen Signalisierungsdaten sowie die als Sprache ausgebildeten Mediendaten im integrierten Sprach-Daten-Netz mit gleicher Dienstgüte übermittelt werden wie im Sprachnetz. Hierbei kann einem Teilnehmer zwar von einem Betreiber eine gewisse Dienstgüte vorab zugesagt werden. In einem integrierten Sprach-Daten-Netz sind jedoch grundsätzlich alle Verkehrsströme von Schwankungen der Netzbelastung betroffen, weshalb die zugesagte Dienstgüte bei hoher Netzlast prinzipiell unterschritten werden könnte. Hilfreich könnte in diesem Zusammenhang eine erfindungsgemäße, am besten kontinuierliche Erfassung von Daten zur Kennzeichnung der tatsächlichen Dienstgüte jeder VoIP Übermitt- lung sein, da so im Streitfall nachvollziehbare Daten zur
Beurteilung der tatsächlichen Dienstgüte von strittigen VoIP Übermittlungen bereitstehen.
Eine derart umfangreiche und aufwändige Erfassung von Quali- tätsdaten kann jedoch weder mit den in den Standards und
Drafts der IETF und/oder ITU vorgeschlagenen Mitteln, noch mit bekannten oder bekannt gewordenen Implementierungen und Lösung technisch adäquat gelöst werden.
Bekannt ist eine fallweise Erfassung mit Hilfe von Messgeräten. Messgeräte im Netz werden im allgemeinen als Sniffer oder Probing-Systeme bezeichnet, die Informationsübermittlungen überwachen und bei aktiven Systemen direkt Informationen in das Netz zur Messung der tatsächlichen Dienstgüte einspei- sen. Für VoIP existieren auch Messgeräte, die als Endgeräte fungieren, Informationsübermittlungen initiieren und die Übertragungsqualität der Informationsübermittlung messen. Natürlich können damit nur Stichproben erfolgen, außerdem hilft dieses Verfahren nicht bei Beschwerden von Kunden über ihr Endgerät, ihren speziellen Netzzugang und insb. ihre subjektiv erfahrene tatsächliche Dienstgüte. In diesem Fall müsste ein Service-Techniker z.B. vor Ort das Endgerät des Teilnehmers durch ein Messgerät ersetzen, um sodann als Reaktion auf die Beschwerde des Kunden Qualitätsdaten zu erheben. Rückschlüsse auf Qualitätseinbußen in der Vergangenheit, z.B. infolge überhöhter Netzlast (auch 'Stau im Netz' genannt) sind bei diesem Verfahren nicht möglich. Auch kann hiermit nicht nachgewiesen werden, dass die tatsächliche Dienstgüte kontinuierlich einer zugesagten Dienstgüte entspricht bzw. entsprochen hat. Weiterhin ist bekannt, an (netzinternen) Zwischenpunkten einer Informationsübermittlung Qualitätsdaten zu erheben, z.B. an Schnittstellen (auch 'Gateways' genannt) zwischen Netzen (z.B. einer Schnittstelle zwischen einem leitungsori- entierten Sprachnetz und einem paketorientierten, integrierten Sprach-Daten-Netz) oder an Konzentrationspunkten (auch 'Multiplexer' genannt), an denen eine Vielzahl von Informationsübermittlungen durch statisches oder statistisches Mul- tiplexing zu einem höherbitratigen Informationsstrom zusam- mengefasst wird, um in einem gemeinsamen Kanal übermittelt zu werden. Im RFC2705 der IETF (Internet Engineering Task Force) , Arango et al, "Media Gateway Control Protocol (MGCP)", 10/1999, Kap. 2.3.5 ist hierzu vorgeschlagen, dass von einem Zwischenknoten einer Informationsübermittlung für jeden von ihm übermittelten Informationsstrom nach Abschluss der Informationsübermittlung bestimmte statistische Daten an einen zugeordneten Call Agent übermittelt werden sollen. Den Daten kommt hierbei gemäß RFC1889, Schulzrinne et al, "RTP: A Transport Protocol for Real-Time Applications", 01/1996, Kapitel 6, "RTP Control Protocol - RTCP", als Hauptfunktion die Unterstützung einer Fluss- und Überlastkontrolle zu. Nach RFC1889, Kap. 6.3.4 ist der Einsatz dieser Daten gezielt auf folgende Wirkungen ausgerichtet:
- Ein Sender soll während der Informationsübermittlung sein Sendeverhalten in Abhängigkeit von den empfangenen statistischen Daten anpassen können (Fluss- und Überlastkontrolle) .
- Ein Empfänger soll ableiten können, ob ein Problem von einer lokalen, regionalen oder einer globalen Ursache herrührt (Fehlerlokalisation) .
- Ein Netzmonitor soll in Abhängigkeit von den statistischen Daten die Leistungsfähigkeit des Netzes zur Informationsübermittlung bewerten können (Netzperformance) . Der Fokus liegt hierbei auf dem Netz als ganzem, jedoch nicht auf einzelnen Informationsübermittlungen.
Es findet sich weder im RFC2705, noch im RFC1889 ein Hinweis, diese Daten zur Kennzeichnung der Dienstgüte einer Informati- onsübermittlung zu nutzen, insb. zu speichern. Außerdem skaliert dieses Verfahren nicht, da der Aufwand in den bspw. als Gateways oder Multiplexer ausgebildeten Zwischenknoten linear mit der Anzahl der übermittelten Informationsströme ansteigt. Wegen seiner Anwendung in Zwischenknoten ist es vor allem auf eine netzinterne Steuerung der Performance eines Netzes als ganzem durch Fluss- und Überlaststeuerung einzelner Informationsströme ausgerichtet, jedoch nicht auf die Kennzeichnung der Dienstgüte einzelner Informationsübermittlungen für sich genommen. Zudem ist bei getrennter Führung der Infor ations- ströme einer bidirektionalen Informationsübermittlung primär lediglich eine unidirektionale Messung möglich.. Für ein bidirektionales Messergebnis ist dann ein nachgeordneter Verarbeitungsschritt erforderlich.
Eine Aufgabe der Erfindung liegt darin, einen Weg aufzuzeigen, der ein effizientes, kontinuierliches Erfassen von Daten zur Kennzeichnung der tatsächlichen Dienstgüte von jeder Informationsübermittlung in einem Kommunikationsnetz ermöglicht .
Diese Aufgabe wird durch die Merkmale von Anspruch 1 gelöst. Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den unter- oder nebengeordneten Ansprüchen.
Mit der Lösung nach Anspruch 1 ist eine Vielzahl von neuen, unerwarteten, vorteilhaften, technischen Wirkungen verbunden:
- Durch Erfassung der Daten von dem Endpunkt selbst skaliert die Lösung. Pro Endpunkt müssen nur Daten zu den dem End- punkt jeweils zugeordneten Informationsübermittlungen er- fasst werden. Weiterhin sind in einem Endgerät - im Unterschied zu einem Zwischenknoten - üblicherweise nur eine begrenzte und zudem meist weitgehend konstante Anzahl von Endpunkten zusammengefasst (bei einem H.323 Endgerät z.B. je einer für Hin- und Rückrichtung von Audio und Video, einer für H.245 Signalisierung und einer für H.225.0 Sig- nalisierung zum zugeordneten Gatekeeper) . Ein Anstieg der Anzahl von Informationsübermittlungen in einem Netz erfolgt üblicherweise durch einen Anstieg der Anzahl von an das Netz angeschlossenen Endgeräten, jedoch nicht durch einen (signifikanten) Anstieg der Endpunkte pro Endgeräte, so dass die durch die erfindungsgemäße Datenerfassung und -Übermittlung verursachte Last pro Endgerät weitgehend gleichmäßig, d.h. konstant, bleibt.
Auch bei getrennter Führung der Informationsströme einer bidirektionalen Informationsübermittlung auf verschiedenen Wegen eines Netzes ist grundsätzlich ein bidirektionales Messergebnis möglich, da in dem Endpunkt üblicherweise die beiden Informationsströme zusammenlaufen und somit die Notwendigkeit einer nachträglichen Korrelation unidirekti- onaler Messergebnisse der beiden Übermittlungsrichtungen zu einem bidirektionalen Messergebnis entfällt.
Durch Erfassung der Daten im Endpunkt einer Informationsübermittlung kann die im Endpunkt vorliegende tatsächliche Dienstgüte kontinuierlich gemessen und durch Speicherung der Daten auch jederzeit nachgewiesen werden. Ein Nachweis der tatsächlichen Dienstgüte ist essentiell für die Akzeptanz der von IETF und ITU vorgeschlagenen Konzepte, da hierdurch den Teilnehmern transparent gemacht werden kann, dass eine ihnen garantierte Dienstgüte nicht nur versprochen, sondern auch tatsächlich zur Verfügung gestellt wird.
Die Erfindung ist generisch und konzeptionell interopera- bei, da sie unabhängig von einer konkreten Lösung ist.
Dies macht die Erfindung zu einer umfassenden Lösung für Kommunikationsnetze an sich. Sie lässt sich insb. sowohl auf H.323 Netze als auch auf SIP Netze anwenden. Dies ist wichtig und somit besonders vorteilhaft, da, wie die Vergangenheit gezeigt hat, der Markt herstellerspezifischen Lösungen wenig Akzeptanz entgegenbringt.
Mit einem Gegenstand, bei dem die Instanz bei einem eine Call Control Ebene und eine Resource Control Ebene umfassenden Kommunikationsnetz in der Call Control Ebene angeordnet, insb. einem in der Call Control Ebene vorgesehenen Call Cont- roller zugeordnet ist, ist die vorteilhafte Wirkung verbunden, dass für die Endpunkte die Notwendigkeit einer separaten Adressierung der Instanz entfällt, da stattdessen die bereits vorhandene Adresse des Call Controllers verwendet werden kann. Somit entfällt auch eine ansonsten erforderliche Konfi- guration der Adresse der Instanz in den Endgeräten, denen die jeweiligen Endpunkte zugeordnet sind.
Eine besonders schöne, vorteilhafte Wirkung ergibt sich für einen Gegenstand, bei dem die Daten zusammen mit weiteren Daten zur Vergebührung der Informationsübermittlung gespeichert werden. Hierbei kann jede einzelne Vergebührung ohne aufwändige, nachträgliche Verknüpfung mit ggf. separat geführten Daten bzgl. ihrer tatsächlichen Dienstgüte gegenüber den Kunden nachgewiesen werden, wodurch insb. das Vertrauen der Teilnehmer in die prinzipiell schwankender Dienstgüte unterworfenen integrierten Sprach-Daten-Netze gestärkt wird. Dieser Nachweis kann wegen der direkten Verknüpfung äußerst effizient bewirkt werden.
Vorteilhaft entfällt bei einem Gegenstand, bei dem die Daten bei einer bidirektionalen Informationsübermittlung die Dienstgüte beider Übermittlungsrichtungen kennzeichnen jegliche nachträgliche Korrelation unidirektionaler Messergebnisse der beiden Übermittlungsrichtungen zu einem bidirektionalen Messergebnis. Bei einem Gegenstand, bei dem die Daten nach der Informationsübermittlung an die Instanz übermittelt werden, sind der Aufwand für die Übermittlung der Informationen und der Auf¬ wand für die Übermittlung der Daten zeitlich entkoppelt, wodurch der Endpunkt vorteilhaft insbesondere während der zumeist vergleichsweise aufwändigen Informationsübermittlung nicht durch eine zusätzliche Übermittlung belastet wird.
Mit dem Gegenstand, bei dem die Daten von dem Endpunkt an die Instanz z.B. als projektspezifische Elemente in vorhandenen, standardisierten Signalisierungsnachrichten, insbesondere Nachrichten zur Anzeige des Abschlusses der Informationsübermittlung übermittelt werden, ist die vorteilhafte Wirkung verbunden, dass die Lösung standardkonform ist, keine zusätz- liehen proprietären Protokolle oder Nachrichten erforderlich sind. Des weiteren werden die zusätzlich eingefügten Daten keine Auswirkung auf Netzelemente haben (Transparenz) , die nicht an dieser Technik beteiligt sind: diese reagieren wie bisher nur auf den ursprünglichen Anteil der Meldungen (Inte- roperabilität mit Legacy-Netzelementen) .
Bei einem alternativen Gegenstand, bei dem die Daten von dem Endpunkt an die Instanz in zumindest einer zusätzlichen, separaten Nachricht übermittelt werden, liegt die vorteilhaf- te Wirkung darin, dass die vorhandenen, standardisierten Nachrichten überhaupt nicht modifiziert werden, was insb. dann sehr wichtig ist, wenn in diesen Nachrichten keine zusätzlichen, ggf. proprietären Protokollelemente vorgesehen sind.
Die Erfindung wird im folgenden anhand von Ausführungsbeispielen, die in den Figuren dargestellt sind, näher erläutert. Es zeigt hierbei:
Figur 1 eine Anordnung zur Durchführung des erfindungsgemäßen Verfahrens mit einer Call Control Ebene, einer Resource Control Ebene sowie zwei Endpunkten einer Informationsübermittlung
Figur 2 eine beispielhaft detaillierter ausgeführte Ausgestaltung der Anordnung nach Figur 1 mit Computerpro- grammprodukten zur Durchführung des erfindungsgemäßen Verfahrens
In Figur 1 ist eine beispielhafte Anordnung zur Durchführung des erfindungsgemäßen Verfahrens dargestellt, die als Kommu- nikationsnetz mit einer Call Control Ebene CCL, einer Resource Control Ebene RCL sowie zwei Endpunkten A, B einer Informationsübermittlung ausgeführt ist. Eine separate Instanz SP zur Speicherung von Daten QSD, BILL ist in der Ebene CCL angeordnet. Zwischen den Endpunkten A, B ist eine Informati- onsübermittlung CALL dargestellt, die von der Ebene RCL vermittelt wird und zu der in den Endgeräten A, B die Daten QSD zur Kennzeichnung der Dienstgüte der Informationsübermittlung CALL erfasst werden. Weiterhin sind zwischen den Endgeräten A, B und der Ebene CCL Nachrichten N dargestellt, mit denen die erfassten Daten QSD an die Instanz SP übermittelt werden.
In Figur 2 ist eine detailliertere Ausgestaltung der Anordnung nach Figur 1 dargestellt. Es sei betont, dass die hierbei aufgezeigten Ausführungen trotz ihrer teilweise sehr konkreten Darstellung lediglich beispielhafter Natur und nicht einschränkend zu verstehen sind. In dieser Ausgestaltung umfasst die Ebene CCL zwei Call Controller CC, wobei der dem Endpunkt A zugeordnete Call Controller CC als Gatekeeper CCGK und der dem Endpunkt B zugeordnete Call Controller CC als SIP-Proxy CCSIP ausgebildet ist. Weiterhin sind zwei Ausgestaltungen SPi, SP2 der separaten Instanz SP dargestellt. Die erste ist als extern realisierte separate Instanz SPi ausgebildet, die dem Gatekeeper CCGK zugeordnet ist. Sie könnte auch dem SIP-Proxy CCSIP zugeordnet werden und als einzige Instanz SP in der Ebene CCL fungieren. Diese potentielle Relation ist durch einen gestrichelten Pfeil zwischen der Instanz SPX und dem SIP-Proxy CCSIP angedeutet. Die zweite ist als integriert realisierte separate Instanz SP2 ausgebildet, die in den SIP-Proxy CCSIP integriert ist. Der ersten Instanz SPi ist eine Datenbank DBÄ und der zweiten Instanz SP2 eine Datenbank DBB zur Speicherung der Daten QSD, BILL zugeordnet, wobei im zweiten Fall die Zuordnung über den SIP- Proxy CCSIP erfolgt. Auf die Datenbanken DB wird z.B. mit dem Protokoll LDAP (Lightweight Directory Access Protocol) zugegriffen. Zwischen den beiden Call Controllern CC werden ggf. Signalisierungsnachrichten N ausgetauscht.
Die Ebene RCL umfasst einen zentralen Resource Controller RC. Diesem sind zwei Edgerouter PERA, PERB zur Übermittlung von Informationen in einem Kommunikationsnetz zugeordnet. Zwischen dem Resource Controller RC und den Edgeroutern PER kommt ein Protokoll COPS (Common Open Policy Service) zum Einsatz. Weiterhin kommt zwischen dem Endpunkt A und dem Gatekeeper CCGκ ein Protokoll H.225.0, zwischen dem Endpunkt A und dem Edgedevice PERÄ sowie dem Endpunkt B und dem Edge- device PERB ein Protokoll RSVP (Resource Reservation Proto- col) und zwischen dem Endpunkt B und dem SIP-Proxy CCSIP ein
Protokoll SIP (Session Initiation Protocol) zur Anwendung. In den standardisierten Nachrichten NH.225.0 NSΪP der Protokolle H.225.0, SIP, RSVP werden jeweils auch die Daten QSD übermittelt. Alternativ könnten die Daten QSD wie angedeutet in zusätzlichen, ggf. nicht standardisierten Nachrichten NPROP übermittelt werden. Zwischen den Edgedevices PERA und PERB kommt z.B. eines der Protokolle RSVP, DiffServ, MPLS oder COPS zur Reservierung von Ressourcen zum Einsatz. Zwischen den Endpunkten A und B ist ein Gespräch CALL aufgezeigt. Die Informationen werden im Kommunikationsnetz durch ein Protokoll RTP (Real Time Protocol) übermittelt. Gemäß einem parallel zu dem Protokoll RTP eingesetzten Protokoll RTCP (Real Time Control Protocol) werden hierbei auch für die Daten QSD erfindungsgemäß ausgewertete Steuergrößen zwischen den beiden Endpunkten A, B übermittelt. Das Kommunikationsnetz ist beispielsweise als IP-Netz ausgebildet. Für den einschlägigen Fachmann ist offensichtlich, dass die Erfindung selbstverständlich in weiteren Netztypen zum Einsatz kommen kann wie z.B. Internet, Intranet, Extra- net, einem lokalen Netz (Local Area Network - LAN) oder einem, z.B. als Virtuelles Privates Netz (VPN) ausgebildeten firmeninternen Netz (Corporate Network) .
In den Endgeräten A und B, den Call Controllern CC und den Edgedevices PER sind erfindungsgemäße Computerprogrammprodukte P vorgesehen, die jeweils Softwarecodeabschnitte zur prozessorgestützten Ausführung des erfindungsgemäßen Verfahrens umfassen. Optional können dabei Teile der Computerprogrammprodukte P auch auf spezieller Hardware (z.B. Krypto- Prozessoren) ablaufen.
Im weiteren wird als Beispiel das erfindungsgemäße Verhalten und Zusammenwirken der Call Controller CC, der Endpunkte A, B und der Instanz bzw. Instanzen SP im Rahmen einer Informati- onsübermittlung CALL ausgeführt. Im weiteren wird hierbei die Informationsübermittlung CALL auch als Gespräch CALL bezeichnet.
Zunächst wird das Endgerät A bei dem Gatekeeper CCGκ regist- riert. Die Registrierung wird von dem Endgerät A durch einen H.225.0 Registration Request RRQ beantragt und von dem Gatekeeper CCGK mit einer H.225.0 Registration Confirm RCF oder mit einer H.225.0 Registration Reject RRJ beantwortet. Vom Gatekeeper CCGK wird dann der Endpunkt A verifiziert, d.h. authentisiert, autorisiert, etc.. Hierzu wird auf nutzerspezifische Daten, die z.B. in einer Datenbank DBA abgelegt sind, mit Hilfe des Protokolls LDAP oder eines anderen DB- Abfrageprotokolls zugegriffen. Weiterhin wird vom Gatekeeper CCGK auch festgelegt, ob das Call Signalling von ihm selbst vermittelt werden soll (Gatekeeper Routed Call Signalling) oder direkt zwischen den Endpunkten A, B (Direct Endpoint Call Signalling) , ggf. mit Benachrichtigung an den Gatekeeper CCGK zu wesentlichen Änderungen. Auf analoge Weise wird das Endgeräte B bei dem SIP-Proxy CCSIP registriert.
Nach Registrierung beider Endpunkte A, B ist ein Call Signal- ling, insb. ein Call Setup, zwischen den beiden Endgeräten A, B grundsätzlich möglich. Dieser wird z.B. von dem Endpunkt A initiiert, indem mit einem H.225.0 Admission Request ARQ der Aufbau des Gesprächs CALL zum Endpunkt B beim Gatekeeper CCGK beantragt wird. Dieser ARQ könnte auch eine QoS Anforderung enthalten. Vom Gatekeeper CCGK wird hierauf eine auf das Gespräch CALL bezogene Äuthentisierung und Autorisierung durchgeführt. Diese umfasst auch eine Bewertung der QoS Anforderung. Diese kann z.B. durch eine mittels weiterer H.225.0 Nachrichten bewirkte Capability Negotiation zwischen den beiden Endpunkten A, B ermittelt werden. Beim Gatekeeper Routed Call Signalling ist diese dann dem Gatekeeper CCGK unmittelbar bekannt. Beim Direct Endpoint Call Signalling könnte sie dem Gatekeeper CCGκ mitgeteilt werden. Optional wird vom Gatekeeper CCGK eine Vergebührung des Gesprächs CALL gestartet, wobei weitere Daten BILL erzeugt werden. Falls das Endgerät B das Gespräch CALL annimmt, wird dies dem Gatekeeper CCGK durch eine Nachricht CONNECT angezeigt.
Im Anschluss wird vom Endpunkt A eine RSVP QoS Anforderung an das Edgedevice PERA übermittelt. Sofern nicht bereits zuvor zwischen Gatekeeper CCGK und Resource Controller RC eine Abstimmung stattgefunden hat, wird nun vom Edgedevice eine weitere Verifikation der QoS Anforderung durchgeführt. Hierzu wird z.B. über das standardisierte Protokoll COPS eine Abfra- ge an den Resource Controller RC gesendet. Dieser prüft, ob die angeforderte QoS im Kommunikationsnetz bereitgestellt werden kann. Der Resource Controller RC kennt hierzu die gesamten vorhandenen (bzw. belegten) Ressourcen im Kommunikationsnetz, um eine Antwort auf die COPS Abfrage senden zu können. Nach Empfang der Antwort des Resource Controllers RC reagiert das Edgedevice PERA wie folgt: Entweder wird die QoS Anforde¬ rung wegen Überlast im Kommunikationsnetz abgelehnt oder die angeforderte QoS wird im Kommunikationsnetz konfigurativ eingestellt, z.B. durch dynamische Aktivierung einer Policy oder alternativ zur RSVP Terminierung im Edgedevice PERA durch Weiterleiten der RSVP Reservierung durch das Netz bis zum anderen Edgedevice PERB oder Endpunkt B.
Nach Erhalt einer positiven RSVP Antwort vom Edgedevice PERA beginnt der Endpunkt A mit der Informationsübermittlung. Spätestens jetzt wird die Vergebührung aktiviert. Hierbei werden die Mediendaten z.B. entsprechend dem Protokoll RTP übermittelt. Während des Gesprächs CALL werden auch zusätzli- ehe Daten zur Flusssteuerung des Gesprächs CALL entsprechend dem Protokoll RTCP übermittelt und es werden in den Endgeräten A, B die Daten QSD unter Berücksichtigung der eigentlich der Flusssteuerung dienenden Signalisierungsdaten des Protokolls RTCP erfasst. Wegen des bidirektionalen Charakters eines Gesprächs CALL können hierbei die im Endpunkt A, B erfassten Daten QSD die Dienstgüte beider Übermittlungsrichtungen kennzeichnen, und zwar auch dann, wenn die beiden Übermittlungen in der Ebene RCL auf unterschiedlichen Wegen erfolgen, denn in einem Endpunkt werden diese beiden Über- mittlungen wieder zusammengefasst, so dass für beide Übermittlungsrichtungen die QoS kennzeichnenden Daten QSD erfasst werden können. Eine nachträgliche Zusammenführung getrennt erfasster Daten QSD ist nicht erforderlich.
Die Daten QSD werden in den Endgeräte A, B zwischengespeichert oder im wesentlichen unmittelbar an die separate In- stanz SP übermittelt. Beispielsweise erfolgt letzteres in regelmäßigem Abstand von einigen wenigen Sekunden. Besonders schöne Vorteile ergeben sich hierbei, wenn zur Übermittlung der Daten QSD bestehende Nachrichten genutzt werden. Beispielsweise können während eines Gesprächs CALL der Endpunkt A und der Gatekeeper CCGK über regelmäßig ausgetauschte Keep Alive Nachrichten in ständiger Verbindung stehen (siehe hierzu H.225.0 (02/98), Kap. 7.9.1 und 7.9.2, Parameter timeToLi- ve in Nachricht Registration Confirm RCF zum Setzen der Lebensdauer der Registrierung und Parameter eepAlive in Nachricht Registration Request RRQ zum Auffrischen, d.h. Verlängern der Lebensdauer einer bestehenden Registrierung) . Üblicherweise ist die Periode dieser Keep Alive Nachrichten regelmäßig und liegt im Sekundenbereich. In diesen Nachrichten können die Daten QSD mitgegeben werden.
Der Abschluss des Gesprächs CALL wird durch Endgerät A oder B angezeigt. Als Folge beendet der Gatekeeper CCGK die optional gestartete Vergebührung des Gesprächs CALL. Die Reservierung des Gesprächs CALL verfällt im Kommunikationsnetz nach kurzer Zeit. Der Resource Controller RC kann die freigegebenen Ressourcen wieder vergeben. Durch Signalisierung wird der Abschluss des Gesprächs CALL auch dem Call Controller CCSιP der Gegenseite mitgeteilt.
Bei Zwischenspeicherung der Daten QSD werden diese gemäß einer Ausführung der Erfindung nach der Informationsübermittlung CALL an die Instanz SP übermittelt. Besonders schöne Vorteile ergeben sich, wenn diese erfindungsgemäße Übermittlung mit Hilfe von bereits bestehenden, in diesem Ausfüh- rungsbeispiel entsprechend der H.323 Standard Familie bzw. dem SIP Protokoll ausgebildeten Nachrichten NH.225.o/ NSIP erfolgt, indem die Daten QSD z.B. als projektspezifische Elemente in bereits vorhandene, ggf. spezielle Nachrichtenfelder eingefügt werden, die in den einschlägigen Standards z.B. als freie Felder ohne Funktionsangabe (optionale Parameter) vorgesehen sind. Selbstverständlich sind auch separate Nachrichten NpRop zur Übermittlung der erfindungsrelevanten Informationen möglich.
Von der Instanz SP werden die Daten QSD in der Datenbank DB gespeichert. Gemäß einer Ausführung der Erfindung werden die Daten QSD zusammen mit den optional gebildeten Daten BILL zur Vergebührung des Gesprächs CALL gespeichert. Auf diese Weise ist ein besonders effizienter Nachweis der Qualität eines vergebührten Gesprächs CALL möglich, da infolge der gemeinsamen Speicherung keine nachträgliche Zuordnung im Rahmen eines Postprocessings erforderlich ist.
Nach Abschluss des Gesprächs CALL sind die Endgeräte A, B bereit zum Aufbau weiterer Gespräche CALL. Vorzugsweise sind die Endgeräte A, B derart ausgebildet, dass die beschriebene erfindungsgemäße Erfassung und Speicherung der Daten QSD bei jedem Gespräch CALL durchgeführt wird.
Abschließend sei betont, dass die Beschreibung der für die Erfindung relevanten Komponenten des Kommunikationsnetzes grundsätzlich nicht einschränkend zu verstehen ist. Für einen einschlägigen Fachmann ist insbesondere offensichtlich, dass Begriffe wie 'Endpunkt', 'Instanz' 'Call Control Ebene' oder 'Resource Control Ebene' funktional und nicht physikalisch zu verstehen sind. Somit können beispielsweise die Endpunkte A, B oder die Instanz SP auch teilweise oder vollständig in
Software und/oder über mehrere physikalische Einrichtungen verteilt realisiert werden.

Claims

Patentansprüche
1. Verfahren zur Speicherung von Daten (QoS) zur Kennzeich- nung der Dienstgüte einer Informationsübermittlung (CALL) in zumindest einem Kommunikationsnetz, mit zumindest einem Endpunkt (A) der Informationsübermittlung (CALL) , mit folgenden Schritten:
- von dem Endpunkt (A) werden die Daten (QoS) für die Infor- mationsübermittlung (CALL) erfasst,
- die erfassten Daten (QoS) werden an eine separate Instanz (SP) zur Speicherung der Daten (QoS) übermittelt und von der Instanz (SP) gespeichert.
2. Verfahren nach Anspruch 1, bei dem die Instanz (SP) bei einem eine Call Control Ebene (CCL) und eine Resource Control Ebene (RCL) umfassenden Kommunikationsnetz in der Call Control Ebene (CCL) angeordnet ist.
3. Verfahren nach Anspruch 2, bei dem die Instanz (SP) einem in der Call Control Ebene (CCL) vorgesehenen Call Controller (CC) zugeordnet ist.
4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem die Daten (QoS) zusammen mit weiteren Daten (BILL) zur Vergebührung der Informationsübermittlung (CALL) gespeichert werden.
5. Verfahren nach einem der vorstehenden Ansprüche, bei dem die Daten (QoS) bei einer bidirektionalen Informationsübermittlung die Dienstgüte beider Übermittlungsrichtungen kennzeichnen.
6. Verfahren nach einem der vorstehenden Ansprüche, bei dem die Daten (QoS) nach der Informationsübermittlung (CALL) an die Instanz (SP) übermittelt werden.
7. Verfahren nach einem der vorstehenden Ansprüche, bei dem die Daten (QoS) von dem Endpunkt (A) an die Instanz (SP) in vorhandenen, standardisierten Signalisierungsnachrichten (NH.225.o, NSIP) , insbesondere Nachrichten zur Anzeige des Abschlusses der Informationsübermittlung (CALL) , übermittelt werden.
8. Verfahren nach Anspruch 7, bei dem die Daten (QoS) als projektspezifische Elemente in die vorhandenen, standardisierten Signalisierungsnachrichten (NH.225.0, Si ) eingefügt werden.
9. Verfahren nach einem der Ansprüche 1 bis 6, bei dem die Daten (QoS) von dem Endpunkt (A) an die Instanz (SP) in zumindest einer zusätzlichen, separaten Nachricht (NPR0P) übermittelt werden.
10. Computerprogrammprodukt (P) umfassend Softwarecodeabschnitte, mit denen ein Verfahren nach einem der vorstehenden Verfahrens-Ansprüche durch einen Prozessor ausgeführt wird.
11. Separate Instanz (SP) zur Durchführung eines Verfahrens nach einem der vorstehenden Verfahrens-Ansprüche.
12. Endpunkt (A) , umfassend Mittel zur Durchführung eines Verfahrens nach einem der vorstehenden Verfahrens-Ansprüche.
13. Endpunkt (A) nach Anspruch 12, bei dem die Mittel derart ausgebildet sind, dass das Verfahren bei jeder Informationsübermittlung (CALL) durchgeführt wird.
14. Endpunkt (A) nach Anspruch 13, bei dem die Mittel derart ausgebildet sind, dass die Daten (QoS) bei jeder Informationsübermittlung (CALL) kontinuierlich erfasst werden.
EP02772124A 2001-08-08 2002-08-06 Kennzeichnung der dienstgüte einer informationsübermittlung in einem kommunikationsnetz Withdrawn EP1415437A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02772124A EP1415437A1 (de) 2001-08-08 2002-08-06 Kennzeichnung der dienstgüte einer informationsübermittlung in einem kommunikationsnetz

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP01119178 2001-08-08
EP01119178A EP1284551A1 (de) 2001-08-08 2001-08-08 Kennzeichnung der Dienstgüte einer Informationsübermittlung in einem Kommunikationsnetz
EP02772124A EP1415437A1 (de) 2001-08-08 2002-08-06 Kennzeichnung der dienstgüte einer informationsübermittlung in einem kommunikationsnetz
PCT/EP2002/008774 WO2003015350A1 (de) 2001-08-08 2002-08-06 Kennzeichnung der dienstgüte einer informationsübermittlung in einem kommunikationsnetz

Publications (1)

Publication Number Publication Date
EP1415437A1 true EP1415437A1 (de) 2004-05-06

Family

ID=8178279

Family Applications (2)

Application Number Title Priority Date Filing Date
EP01119178A Withdrawn EP1284551A1 (de) 2001-08-08 2001-08-08 Kennzeichnung der Dienstgüte einer Informationsübermittlung in einem Kommunikationsnetz
EP02772124A Withdrawn EP1415437A1 (de) 2001-08-08 2002-08-06 Kennzeichnung der dienstgüte einer informationsübermittlung in einem kommunikationsnetz

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP01119178A Withdrawn EP1284551A1 (de) 2001-08-08 2001-08-08 Kennzeichnung der Dienstgüte einer Informationsübermittlung in einem Kommunikationsnetz

Country Status (6)

Country Link
US (1) US20060209873A1 (de)
EP (2) EP1284551A1 (de)
CN (2) CN1568598A (de)
IL (1) IL160207A0 (de)
NZ (1) NZ531418A (de)
WO (1) WO2003015350A1 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2849733A1 (fr) * 2003-01-02 2004-07-09 Thomson Licensing Sa Dispositif et procede d'ajustement de debit d'un flux de contenus et produits associes
WO2004075582A1 (en) 2003-02-21 2004-09-02 Nortel Networks Limited Data communication apparatus and method for establishing a codec-bypass connection
DE10335432B4 (de) * 2003-07-31 2007-11-29 Nokia Siemens Networks Gmbh & Co.Kg Verfahren zum Übertragen von Nachrichten zwischen Kommunikationsendgeräten
WO2005089055A2 (en) 2004-03-19 2005-09-29 Nortel Networks Limited Communicating processing capabilites along a communications path
US8027265B2 (en) * 2004-03-19 2011-09-27 Genband Us Llc Providing a capability list of a predefined format in a communications network
US7542461B2 (en) * 2004-04-19 2009-06-02 Cisco Technology, Inc. Method and apparatus for dynamically determining when to use quality of service reservation in internet media applications
US7697421B2 (en) * 2005-04-21 2010-04-13 Avaya Inc. Method and apparatus for quality-of-service-based admission control
US8081565B2 (en) * 2005-04-21 2011-12-20 Avaya Inc. Method and apparatus for adaptive control of system parameters for admission control
CN100580770C (zh) * 2005-08-08 2010-01-13 中国科学院声学研究所 基于能量及谐波的语音端点检测方法
US7554987B2 (en) * 2006-10-10 2009-06-30 Motorola, Inc. Quality of service modification using a token in a communication network
WO2008082605A1 (en) 2006-12-28 2008-07-10 Genband Inc. Methods, systems, and computer program products for silence insertion descriptor (sid) conversion
CN101527895B (zh) * 2009-04-08 2012-05-23 华为技术有限公司 业务状态信息获取方法及装置
US8908541B2 (en) 2009-08-04 2014-12-09 Genband Us Llc Methods, systems, and computer readable media for intelligent optimization of digital signal processor (DSP) resource utilization in a media gateway

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09275400A (ja) * 1996-04-04 1997-10-21 Hitachi Ltd Ａｔｍ交換システム
US5892754A (en) * 1996-06-07 1999-04-06 International Business Machines Corporation User controlled adaptive flow control for packet networks
US5777986A (en) * 1996-08-16 1998-07-07 Motorola, Inc. Method and apparatus for controlling quality of service in an ATM network
SE519482C2 (sv) * 1997-03-07 2003-03-04 Telia Ab Metod och anordning i ett telekommunikationssystem för fastställande av mängden av nödvändiga resurser i en given trafiksituation
US6252857B1 (en) * 1998-03-04 2001-06-26 At&T Corp. Method and apparatus for provisioned and dynamic quality of service in a communications network
US6141686A (en) * 1998-03-13 2000-10-31 Deterministic Networks, Inc. Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control
JP2955561B1 (ja) * 1998-05-29 1999-10-04 株式会社ディジタル・ビジョン・ラボラトリーズ ストリーム通信システム及びストリーム転送制御方法
US6097699A (en) * 1998-06-05 2000-08-01 Gte Laboratories Incorporated Method and system for monitoring broadband quality of services
CN1217510C (zh) * 1998-06-05 2005-08-31 英国电迅有限公司 通讯网络
US6366577B1 (en) * 1999-11-05 2002-04-02 Mci Worldcom, Inc. Method for providing IP telephony with QoS using end-to-end RSVP signaling
US6798745B1 (en) * 2000-06-15 2004-09-28 Lucent Technologies Inc. Quality of service management for voice over packet networks
FI20001578A7 (fi) * 2000-06-30 2001-12-31 Nokia Corp QoS-arkkitehtuuri
JP2002209030A (ja) * 2001-01-10 2002-07-26 Fujitsu Ltd 端末装置及び通信サービスの課金方法
US7068666B2 (en) * 2001-04-27 2006-06-27 The Boeing Company Method and system for virtual addressing in a communications network
DE10342294A1 (de) * 2003-09-12 2005-04-28 Siemens Ag Interworking von Protokollen hybrider Multimedianetze
KR100561615B1 (ko) * 2003-11-17 2006-03-15 삼성전자주식회사 휴대 인터넷망의 서비스 품질 제공을 위한 호 수락 제어 장치 및 그 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03015350A1 *

Also Published As

Publication number Publication date
NZ531418A (en) 2007-05-31
CN1992646A (zh) 2007-07-04
CN1568598A (zh) 2005-01-19
WO2003015350A1 (de) 2003-02-20
IL160207A0 (en) 2004-07-25
US20060209873A1 (en) 2006-09-21
EP1284551A1 (de) 2003-02-19

Similar Documents

Publication Publication Date Title
EP1368949B1 (de) Übermittlung von Informationen einer verifizierten QoS in einem Kommunikationsnetz
DE60132387T2 (de) Richtlinien-Koordination in einem Kommunikationsnetz
EP1656781A1 (de) Verfahren, software-produkt und vorrichtungen zur signalisierung der modifikation von bearerverbindungen mittels sip protokoll
EP2018765A1 (de) Verfahren zum ermöglichen einer steuerung der dienstqualität und/oder der dienstvergebührung bei telekommunikationsdiensten
EP1415437A1 (de) Kennzeichnung der dienstgüte einer informationsübermittlung in einem kommunikationsnetz
EP1322085B1 (de) Verfahren zur Dienstgüteüberwachung in einem Multimedien paketorientierten Netzwerk
EP1649659B1 (de) Verbindung von teilnehmern in hybriden kommunikationsnetzen
DE60128745T2 (de) Verfahren und Vorrichtung zur Bereitstellung einer Zwischenschicht für den VOIP-Verbindungsaufbau
DE60212988T2 (de) Verfahren, Einrichtung und Computerprogramm zur Auswahl einer Medienübergangskontrollfunktion basierend auf der Überwachung von Resourcen von Medienübergangsfunktionen
EP1656789B1 (de) Abbau von verbindungen in kommunikationsnetzen
DE60222478T2 (de) Ende-zu-ende-tests zwischen gateways in einem ip-netzwerk
EP1282280A1 (de) Verfahren, Steuereinrichtung und Programmmodul zur Steuerung und Lenkung von Datenströmen einer Kommunikationsverbindung zwischen Teilnehmern eines Paketdatennetzes
EP1665676B1 (de) Verfahren zur laststeuerung in einem paketdatennetz
EP1341357B1 (de) Verfahren zur Dienstgütesicherung in einem Kommunikationsnetz sowie Anordnung und Einrichtungen zur Realisierung des Verfahrens
DE602004003070T2 (de) Zugriffsregelung für eine multimedia-sitzung gemäss netzwerk-betriebsmittelverfügbarkeit
EP1227632B1 (de) Verfahren zum Betrieb eines Multimedia-Kommunikationsnetzwerkes
EP1279272A2 (de) Verfahren zum bereitstellen eines zusatz-dienstes für internet-benutzer
DE602005000041T2 (de) Verfahren zur Bestimmung der Leistungsfähigkeit von VoIP-Gateways und Dienstgütevereinbarungen auf Basis von Pfadmessungen
WO2012116713A1 (de) Verfahren zur kommunikation und komponente in einem kommunikationsnetzwerk
EP1266496B1 (de) Verfahren und anordnung zur zulässigkeitsprüfung einer dienstnutzung
EP1513312B1 (de) Multimediale Videotelephonie
DE19833969A1 (de) Verfahren zum Aufbau einer Kommunikationsverbindung
EP1157523B1 (de) Verfahren zur vergabe einer dienstgüte für einen paketstrom
WO2006035044A1 (de) Verfahren zur administration von centrex-funktionsmerkmalen unter verwendung von x.509 attributzertifikaten
EP1902560A1 (de) Verfahren zum aufbau einer multimedialen verbindung bei kaskadierter verbindungsweiterleitung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040120

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

17Q First examination report despatched

Effective date: 20041007

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20080722