DE60203779T2 - Ein Verfahren zur Übertragung von End-to-End QoS durch Anwendung des end-to-end negotiation protocols (E2ENP) - Google Patents

Ein Verfahren zur Übertragung von End-to-End QoS durch Anwendung des end-to-end negotiation protocols (E2ENP) Download PDF

Info

Publication number
DE60203779T2
DE60203779T2 DE60203779T DE60203779T DE60203779T2 DE 60203779 T2 DE60203779 T2 DE 60203779T2 DE 60203779 T DE60203779 T DE 60203779T DE 60203779 T DE60203779 T DE 60203779T DE 60203779 T2 DE60203779 T2 DE 60203779T2
Authority
DE
Germany
Prior art keywords
qos
negotiation
e2enp
peers
session
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.)
Expired - Lifetime
Application number
DE60203779T
Other languages
English (en)
Other versions
DE60203779D1 (de
Inventor
Davide Mandato
Andreas Kassler
Teodora Guenkova-Luy
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.)
Sony Deutschland GmbH
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Sony International Europe GmbH
Siemens AG
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 Sony International Europe GmbH, Siemens AG filed Critical Sony International Europe GmbH
Publication of DE60203779D1 publication Critical patent/DE60203779D1/de
Application granted granted Critical
Publication of DE60203779T2 publication Critical patent/DE60203779T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime 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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/18—End to end
    • 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/20—Traffic policing
    • 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
    • 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/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/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
    • 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/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
    • 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/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
    • H04L47/767—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points after changing the attachment point, e.g. after hand-off
    • 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/801—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/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/80—Actions related to the user profile or the type of traffic
    • H04L47/808—User-type 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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/824—Applicable to portable or mobile terminals
    • 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/1069—Session establishment or de-establishment
    • 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
    • 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4038—Arrangements for multi-party communication, e.g. for conferences with floor control
    • 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/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation

Description

  • Ein Verfahren zur Übertragung von End-to-End-QoS durch Anwendung des End-to-End Negotiation Protocol (E2EENP).
  • GEBIET UND HINTERGRUND DER ERFINDUNG
  • Die zugrundeliegende Erfindung betrifft generell das Gebiet der mobilen Daten- bzw. Informationsverarbeitung (computing) in einer drahtlosen Mobilvernetzungsumgebung- bzw. -landschaft mit verteilten Multimedienanwendungen (multimedia applications) und -technologien bzw. -techniken. Insbesondere ist sie auf das Gebiet des Quality-of-Service-Managements (QoS-Management) für adaptive Echt- bzw. Realzeitdienste gerichtet, die verschiedene Zugriffstechniken bei dynamischen drahtlosen Internetprotokoll-Netzwerken (IP-Netzwerke) unterstützen und dadurch Forschungs- und Entwicklungsausgaben (research and development issues) umfassen, die speziell mit Multimedien-Middleware und Ressourcenreservierungsmechanismen verbunden sind. In diesem Kontext schlägt die Erfindung ein Modell zur Definition von Benutzerprofil- und Endgerätfähigkeitsinformation derart vor, dass hierarchische QoS-Vertragspezifikationen (beispielsweise zwingende Korrelationen quer durch verschiedene Sätze bzw. Mengen (sets) von QoS-Verträgen (QoS contracts) für verknüpfte bzw. verbundene Medienströme (related media streams) forciert (forciert umfasst durchgesetzt, geltend gemacht, erzwungen, gezwungen aufgefordert bzw. eingehalten und zur Gewinnung verhandelbarer Information benutzt werden können.
  • Als eine Referenzimplementierung dieses Konzepts schlägt diese Erfindung eine neue Benutzung des von der Internet Engineering Task Force (IETF (Internetentwicklungs-Sonderaufgabengruppe)) standardisierten Session Initiation Protocol (SIP (Sessioninitialisierungsprotokoll)) in Verbindung mit Erweiterungen der Spezifikation des Session Description Protocol Next Generation (SDPng (Sessionbeschreibungsprotokoll der nächsten Generation)) auf der Basis der Extensible Markup Language (XML (erweiterbare Markup-Sprache)) vor, um die Konzepte des End-to-End QoS Negotiation Protocol (E2ENP (End-zu-End-Verhandlungsprotokoll)) zu implementieren. Das Konzept der vorgeschlagenen Lösung gemäß der zugrundeliegenden Erfindung basiert auf einem Vorschlag, der ursprünglich in „Concepts for Service Adaptation, Scalability and QoS Handling on Mobility-Enabled Networks (IST-1999-10050 BRAIN Deliverable 1.2, 03/31/2001, http://www.ist-brain.org/), im folgenden als [BRAIN] bezeichnet, zusammen mit einer spezifischen Referenzarchitektur identifiziert worden ist. Bei diesem Konzept soll ein Satz bzw. eine Menge von grundlegenden Erfordernissen abgeleitet werden. Dadurch soll eine diese Menge von Erfordernissen und die Wahl einer optimalen Lösung hinsichtlich dieser Erfordernissen betreffende Diskussion eröffnet werden.
  • Das Internet hat sich als eine erfolgreiche Architektur zur Abgabe eines breiten Satzes (Menge) von elektronischen Diensten (darunter – unter vielen anderen – Telefonie, elektronische Mitteilungsübermittlung (electronic messaging) und Audio/Video-Dienste) erwiesen, nicht nur bei sitzenden, sondern auch nomadischen Benutzern. Mikro- und Makro-IP-Mobilität und drahtlose IP-Technologien bzw. -Techniken bahnen in der Tat den Weg zur vollen Integration des Internets mit der zweiten und dritten Generation von Mobiltelefonsystemen. Zur Lösung dieser Aufgabe müssen die IP-Netzwerke und -Anwendungen der nächsten Generation die zunehmend wichtigen Herausforderungen des drahtlosen Zugriffs, Mobilitätmanagements, die Bereitstellung von Quality of Service (QoS (Dienstqualität)) und Multimediendiensten angehen.
  • Ein vorherrschendes Problem, dem mobile Benutzer in diesem Kontext am wahrscheinlichsten gegenüberstehen, ist, wie die begrenzte Menge von Ressourcen bei den Endsystemen und im Netzwerk zu bewältigen sind, und instabile Umgebungsbedingungen. Es wird in der Tat erwartet, dass mobile Benutzer häufiger in den ungünstigen Fall geraten, dass ihre QoS-Verträge aufgrund verschiedener Gründe wie Drahtlosverbindungsqualitäts-Verschlechterungen, horizontale und/oder vertikale Übergaben, begrenzte Menge von Mobilendgerät-Ressourcen nicht länger von der Netzwerkinfrastruktur unterstützt werden. Im Rest dieses Dokuments werden diese ungünstigen Fälle als „QoS-Verletzungen" bezeichnet. Durch die Annahme einer richtigen Ressourcen-Überbereitstellung im Hauptnetzwerk (backbone) kann erwartet werden, dass QoS-Verletzungen am wahrscheinlichsten im Zugriffsnetzwerk, insbesondere in seinem Funkübertragungsteil (radio part) entstehen.
  • Überdies benötigen mobile Multimedienanwendungen, die mit einer Vielfalt von Peers simultan ausgetauschte mehrfache Medienströme von Information behandeln, eine effektive und effiziente Weise der Behandlung von QoS-Erfordernissen, insbesondere vor den zuvor erwähnten instabilen Umgebungsbedingungen.
  • Ein möglicher Weg, die instabilen Umgebungsbedingungen zu bewältigen, ist, den Anwendungen der mobilen Benutzer zu ermöglichen, durch Vorausplanen von Gegenmaßnahmen effizient und rechtzeitig auf QoS-Verletzungen zu reagieren. Peers können in der Tat verschiedene alternative QoS-Verträge auf verschiedenen Abstraktionsebenen offline (nicht angeschlossen) verhandeln, so dass zur Verbindungsherstellungszeit und immer wenn QoS-Verletzungen auftreten, Vereinbarungen darüber, wie sich an die geänderten Bedingungen am effektivsten anzupassen ist, zwischen den Peers rechtzeitig erreicht werden kann.
  • Außerdem können Peers einer spezifischen Prozedur zum effektiven Forcieren (Forcieren umfasst Durchsetzen, Geltendmachen, Erzwingen, Zwingen, Auffordern, bzw. Einhalten) der vorverhandelten QoS-Verträge folgen, indem sie vermeiden, irgendeine Netzwerkressourcenreservierung anzufordern, bevor lokale Ressourcen bei allen involvierten Peers bestimmt und deren Reservierungen entsprechend gemacht worden sind. Diese Prozedur wird ferner als „Ökonomieprinzip" bezeichnet.
  • Die Gesamtlösung, welche die oben erwähnten zwei Planungsmechanismen kombiniert, sei nun als „End-to-End-Negotiation Protokoll (E2ENP)" bezeichnet.
  • Insbesondere sei darauf hingewiesen, dass die Verhandlung (negotiation) von Fähigkeiten (beispielsweise Codecs) hierdurch als eine zur Verhandlung von QoS-Präferenzen und Profilinformation von Benutzern komplementäre separate Ausgabe angesehen wird. Intelligente, adaptive Anwendungen und/oder Middleware kann auf diese Weise effektiven Gebrauch von jeder durch die Peers End-zu-End-verhandelter (end-to-end negotiated) solcher Information machen, um die beste Anpassungsstrategie in Reaktion auf eine wie in [BRAIN] beschriebene QoS-Verletzung zu wählen.
  • KURZE BESCHREIBUNG DES PRÄSENTEN STANDES DER TECHNIK
  • Gemäß dem Stand der Technik stehen derzeit verschiedene Verfahren und Technologien bzw. Techniken betreffend das Problem des QoS-Managements in mobilen Umgebungen zur Verfügung, die sich genau auf den Gegenstand der zugrundeliegenden Erfindung beziehen. Zum Verständnis des Kontexts der Erfindung ist es notwendig, die bei diesen Technologien bzw. Techniken involvierten Hauptmerkmale zu erläutern.
  • In der europäischen Patentanmeldung EP 01 122 366.6 ist das E2ENP-Protokoll eingeführt und detailliert beschrieben. Die Erfindung stellt ein Gerüst (framework) zur Erzielung einer dynamischen End-zu-End-QoS-Verhandlung (end-to-end negotiation) und eine Kontroll- bzw. Steuerkoordination für verteilte Multimedienanwendungen bereit. Das Gerüst baut auf dynamische Fähigkeitsverhandlung und Spezifizierung von Adaptierungspfaden und (alternativ dazu) QoS-Verträge (QoS contracts) auf der Basis von Benutzerpräferenzen (user preferences). Insbesondere wird ein Protokoll präsentiert, das End-zu-End-Verhandlungen von alternativer QoS, alternativen Fähigkeiten, Präferenzen und/oder Konfigurationen auf der Basis von Erweiterungen von IP-basierten Protokollen wie SIP, RTSP und/oder SDP in Koordination mit Mechanismen für Netzwerkressourcenreservierung (beispielsweise RSVP), lokale Endgerätressourcenreservierung (beispielsweise CPU, Speicher, Energie, Hilfsgeräte) und Anpassungs- bzw. Adaptierungssmechanismen bereitstellt. Bis zu diesem Grad und in Bezug auf zwei oder mehr Peers werden sechs Phasen identifiziert, durch die Peers Mehrparteien-, Multistrom- und Multimedienkommunikationen herstellen können. Im Detail sind diese Phasen Protokollentdeckung, Vorverhandlung, Multistrom-Zeitsynchronisation und QoS-Korrelation, Schnellverhandlung (dem Ökonomieprinzip gehorchend), Neu- bzw. Wiederverhandlung (dem Ökonomieprinzip gehorchend), und Ressourcenreservierung und/oder -freigabe. Alle diese sechs Phasen können zu verschiedenen Zeiten verkettet und/oder ausgeführt werden.
  • In „Concepts for Service Adaptation, Scalability and QoS Handling on Mobility-Enabled Networks" [BRAIN] werden die Grundlagen des E2ENP-Konzepts präsentiert.
  • In „RTP Payload for Redundant Audio Data" (RSC 2198, Network Working Group, September 1997) von C. Perkins et al., im Folgenden als [RFC 2198] bezeichnet, und „RTP Profile for Audio and Video Conferences with Minimal Control" (Columbia University, work in progress (Arbeit im werden Wörtern), <draft-ietf-avt-profile-new-0,9 txt>) von Schulzrinne et al., im folgenden als [RTP-Profile] bezeichnet, sind die Möglichkeiten von schnellen Neu- bzw. Wiederverhandlungen über Inband-Signalisierung beschrieben. Jedoch betrifft diese Art von Signalisierung nur Änderungen von Codecs und die redundante Unterstützung von unterschiedlich codierten Medien ohne Ansehen der jeweiligen Effekte, wenn QoS unterstützt werden sollte.
  • In „Integration of Ressource Management and SIP – SIP Extensions for Ressource Management" (IETF SIP Working Group, work in progress <draft-ietf-sip-manyfolks-ressource-01.txt>) von W. Marshall et al., im folgenden als [SIPRES01] bezeichnet, und „SIP Extensions for Ressource Management" (IETF Draft, November 2000, <draft-ietf-sip-many-folks ressource-00>) von W. Marshall et al., im folgenden als [Marsh00] bezeichnet, präsentieren die Autoren einen Multiphasen-Rufaufbaumechanismus, der Netzwerk-QoS und Sicherheitsherstellung zu einer Vorbedingung für Sessionen (Sitzungen) macht, die vom Session Initiation Protocol (SIP) initiiert und vom Sessions Description Protocol(SDP) beschrieben werden. Netzwerkressourcen werden reserviert, bevor die Session (Sitzung) unter Verwendung existierender Netzwerkressourcenreservierungsmechanismen (wie RSVP) gestartet wird. Das Ressourcenmanagementprotokoll wird zwischen zwei Rufsignalisierungsphasen geschachtelt, und Teilnehmer werden aufgefordert bzw. eingeladen (invited), nachdem Ressourcen im Netzwerk verfügbar sind. Eine Bestätigung der Vorbedingungen wird explizit signalisiert. Das Ressourcenmanagement (Ressourcenverwaltung) wird nur für die Netzwerkressourcen ausgeführt. Es wird eine Erweiterung zum SDP eingeführt, um zu bestimmen, ob die Vorbedingungen erfüllt sind. Jedoch ziehen [SIPRES01] und [Marsh00] eine Vorverhandlung von QoS und die Integration von Lokal- und Peer-Ressourcenmanagement nicht in Betracht.
  • In „Conformation of SDP Preconditions" (IETF Internet Draft, work in progress, <draft-camarillo-manyfolks-con-firm-02.txt>) von G Camarillo, im folgenden als [CAMA00] bezeichnet, wird ein zusätzliches Richtungsattribut (dirction attribute) eingeführt, um anzuzeigen, welche Partei die Bestätigung der Vorbedingungen sendet. Schließlich stellt [CAMA00] einen Mechanismus zur Ausführung einer Drittparteianrufsteuerung bzw. -kontrolle (third party call control) im SIP, wenn SDP-Vorbedingungen benutzt werden, bereit. Jedoch zieht [CAMA00] eine Vorverhandlung von QoS und die Integration von Lokal- und Peer-Ressourcenmanagement nicht in Betracht.
  • In „A Syntax for Describing Media Feature Sets" (RFC 2533, 5GM/Content Technologies, March 1999) von G. Klyne, im Folgenden als [RFC2533] bezeichnet, präsentiert der Autor ein Format zum Ausdrücken von Medienmerkmalmengen bzw. -sätzen, die Medienbehandlungsfähigkeiten (media handling capabilities) darstellen. Außerdem ist ein Algorithmus bereitgestellt, der die Merkmalsätze anpasst. Er kann eventuell dazu benutzt werden, zu bestimmen, ob die Fähigkeiten eines Senders und Empfängers kompatibel sind. Dieser Anpassungsalgorithmus ist in „A revised media feature set matching algorithm„ (IETF Media Feature Registration <draft-klyne-conneg-feature-match 0,2.txt>) von G. Klyne (editiert), im folgenden als [conneg00] bezeichnet, verbessert. Außerdem ist in „Identifying Composite Media Features„ (IETF Conneg Working Group, work in progress, <draft-ietf conneg-feature-hash-05.txt>) von G. Klyne (editiert), im Folgenden als [conneg00a] bezeichnet, ein abgekürztes Format für zusammengesetzte Medienmerkmalsätze beschrieben, das ein Hash der Merkmaldarstellung zum Beschreiben der Zusammensetzung benutzt. Dies kann dazu benutzt werden, eine abgekürzte Form zur Verweisung bzw. Bezugnahme (referencing) auf einen beliebigen Merkmalsatzausdrucks unabhängig von jedem besonderen Mechanismus für die Verweisungs- bzw. Bezugnahmeaufhebung (de-referencing) bereitzustellen. [RFC2533] zusammen mit [CONNEG00] und [CONNEG00a] oder „SDP Simple Capability Negotiation Requirements" (IETF MMUSIC Working Group, work in progress, <draft-andreasen-mmusic-sdp-simcap-regts-00.txt> von F. Andreasen, im Folgenden als [SDPCN01] bezeichnet, Integrieren weder existierende Internetprotokolle noch inkludieren sie das Konzept von alternativen Vorverhandlungs-QoS-Verträgen, noch integrieren sie lokale, Netzwerk- und Peer-Ressourcenreservierungsmechanismen.
  • In „SDP Simple capability negotiation" (IETF MMUSIC Working Group, work in progress, <draft-andreasen-mmusic-sdp-simcap-00.txt>) von F. Andreasen, im Folgenden als [SDPCN00] bezeichnet, legt der Autor das Erfordernis dar, dass ein Fähigkeitssatz (Fähigkeitsmenge) eine Handhabe inkludieren soll (ähnlich zu dem oben erwähnten Hash), die eine leichte Verweisung bzw. Bezugnahme auf den Fähigkeitssatz erlaubt.
  • In „Protocol-Independent Content Negotiation Framework" (RFC 2703, 5GM/Content Technologies, September 1999) von G. Klyne, im Folgenden als [RFC2703] bezeichnet, präsentiert der Autor ein abstraktes Gerüst für eine Protokollunabhängige Inhaltsverhandlung für die Ressourcen, mit denen es interagiert. Es stellt jedoch nicht den Inhaltverhandlungsprozess bereit. Es identifiziert den Bedarf an einem Ausdrücken der Fähigkeiten des Senders und der zu übertragenden Datenressource, die Fähigkeiten des Empfängers und den Bedarf an einem Protokoll zum Austauschen dieser Fähigkeiten. Eine Verhandlung wird durch eine Reihe von Verhandlungsmetadaten-Austauschen ausgeführt. Die Verhandlung stoppt, sobald eine zu übertragende spezifische Datendatei gefunden worden ist. Der Sender überträgt die Daten, wenn der Sender die Datei bestimmt, andernfalls informiert der Empfänger den Sender. Dieser Vorschlag bezieht sich deshalb auf Inhaltsverhandlung anstelle einer Behandlung einer Vorverhandlung von Konfigurationen-QoS-Verträgen und -Fähigkeiten. Die in [RFC2703] vorgeschlagene Lösung integriert auch nicht lokale, Peer- sowie Netzwerk-Ressourcenreservierung.
  • In „An Offer/Answer Model with SDP" (IETF Internet Draft, work in progress, <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>) von J. Rosenberg und H. Schulzrinne, im Folgenden als [SDPOA00] bezeichnet, ist ein vollständiges Modell für Eins-zu-Eins-Fähigkeitsverhandlungen (one-to-one capabilities negotiation) mit SDP beschrieben. Jedoch hat dieses Modell Probleme mit der Definition von gegenseitig verwiesener Information und Information über eine Gruppierung von Medienströmen wegen der flach hierarchischen Struktur des SDP. Außerdem betrifft dieses Modell nur die Fähigkeitsverhandlung, aber nicht die QoS-Unterstützung.
  • In „Requirements for Session Description and Capability Negotiation" (IETF Internet Draft, work in progress, <draft-kutscher-mmusic-sdpng-req-01.txt>) von D. Kutscher et al., im Folgenden als [SDPNG01] bezeichnet, sind die Erfordernisse eines eine Sessionbeschreibung und Endpunktfähigkeitsverhandlung (end-point capability negotiation) bei Mehrparteien-Multimedienkonferenzszenarios (multi-party multimedia conferencing scenarios) behandelnden Gerüsts identifiziert. Dabei stellt das Dokument einen Satz (Menge) von Erfordernissen bereit, die für ein Gerüst für eine Sessionbeschreibung und eine Endpunktfähigkeitsverhandlung bei Mehrparteien-Multimedienkonferenzszenarios relevant sind. Abhängig von Benutzerpräferenzen, Systemfähigkeiten und/oder anderen Beschränkungen können für die Konferenz verschiedene Konfigurationen gewählt werden. Es wird der Bedarf an einem Verhandlungsprozess zwischen den Peers identifiziert, aber nicht beschrieben, um einen gemeinsamen Satz potentieller Konfigurationen zu bestimmen und eine der gemeinsamen Konfigurationen, die zum Informationsaustausch zu benutzen ist, auszuwählen. Diese Fähigkeitsverhandlung wird dazu benutzt, eine mit den Endsystemfähigkeiten und Benutzerpräferenzen der potentiellen Teilnehmer kompatible gültige Session beschreibung zu bekommen. Zum Reflektieren verschiedener Konferenztypen können verschiedene Verhandlungsgrundsätze (negotiation policies) benutzt werden. Sie identifizieren auch den Bedarf an einer mit der Sessioninstallation gekoppelten Netzwerkressourcenreservierung. Schließlich ist ein Vorschlag zur Beschreibung von Fähigkeiten und Bereitstellung der Verhandlungssprache, aber nicht eines Protokolls entworfen. Jedoch zieht die in [SDPNG01] vorgeschlagene Lösung weder das Verhandlungsprotokoll zur Bestimmung eines gemeinsamen Satzes einer QoS-Konfiguration in Betracht, noch integriert sie lokale, Peer- und Netzwerk-Ressourcenreservierung. Außerdem integriert sie weder den Prozess der Verweisung bzw. Bezugnahme auf Konfigurationen durch Handhaben (handles), noch baut sie auf das QoS-Vertragskonzept. Außerdem behandelt diese Lösung nur die Codecverhandlung, ohne Endgerätfähigkeiten und Netzwerk-Ressourcenreservierungsmechanismen in Betracht zu ziehen.
  • Die neuste Version dieses IETF-Entwurfs (IETF draft), „Session Description and Capability Negotiation" (IETF Internet Draft, work in progress, <draft-ietf-mmusic-sdpng-03.txt>) von D. Kutscher et al., im Folgenden als [SDPNG03] bezeichnet, stellt eine detaillierte XML Schema-Spezifikation und einen Prototyp der Audio-Codec- und RTP-Profile bereit. Verglichen mit einer solchen neuesten, vollständigeren Version dieses IETF-Vorschlags sind (als Erweiterung dieses Vorschlags) die E2ENP-Merkmale:
    • – Notation der E2ENP-Phasen,
    • – neue SDPng-Abschnitte und verschiedene Konfigurationen davon, entsprechend dem Format der mit den verschiedenen E2ENP-Phasen assoziierten PDUs,
    • – Benutzung eines explizieten <session(sitzung)>-Elements im neuen <purpose(zweck)>-Abschnitt anstelle des <owner(eigner)>-Elements im <conf(konf)>-Abschnitt (der noch bleibt, aber für andere Zwecke),
    • – Die Verhandlung und die Benutzung von Sessionidentifizierern, die (beispielsweise über Hash) vom <session> abgeleitet werden, um die Größe von E2ENP-PDUs zu begrenzen, bei denen das <session> (mit einem berechneten Hash) in der ersten PDU jeder gegebenen E2ENP-Phase oder Verkettung davon benutzt wird.
    • – Leasing (Mieten) verhandelter Information,
    • – Verkettung verhandelter Information,
    • – das ursprüngliche <def> ist nur durch neue <qosdef>-Abschnitte ersetzt,
    • – Stützung jedes Typs einer Netzwerk- und/oder Protokollversion im <cfg>-Abschnitt,
    • – Erweiterungen der Audio-Codec- und RTP-Profile,
    • – die Möglichkeit, eine QoS-Korrelations- und Zeitsynchronisationsbeschränkungen auf jeder Abstraktionsebene zu einer lokalen Stärkung des gegebenen Endgeräts oder zum Delegieren dieser an eine Drittparteikomponente bzw. Fremdkomponente (beispielsweise Konferenzbrücke) zu modellieren,
    • – Behandeln von Drittpartei-unterstützten (third-party-assisted) Verhandlungsszenarios, und
    • – Behandeln von Video-Codec-Information.
  • Die zwei Dokumente „Connection-Oriented Media Transport in SDP" (IETF MMUSIC Working Group, work in progress, <draft-ietf-mmusic-sdp-comedia-01.txt>) von D. Yon, im Folgenden als [SDPCO01] bezeichnet, und [SDPNG03] identifizieren die Notwendigkeit einer Definition, welche der Kommunikationsparteien sind in Bezug auf den Verbindungsmodus – Sender, Empfänger oder Sender-Empfänger. Außerdem identifiziert [SDPCO01] die Notwendigkeit anzuzeigen, dass ein einzelner Port (Anschluss) zum Senden oder Empfangen der unterschiedlich codierten Medien mit dem gleichen Inhalt benutzt werden kann. Diese jeweilige Definition mit dem SDP ist wegen der flachen Struktur des Protokolls problematisch, andererseits kann das in [SDPNG03] beschriebene SDPng mit einem XML-Schema Querverweise (cross references) für die jeweilige Beschreibung ausführen. Für den Bedarf an QoS-Verhandlungen kann die Identifikation der Sender- und/oder der Empfängerparteien der Beschleunigung der Verhandlung durch Wählen des am besten geeigneten Verhandlungsmodus (push (schieben), pull (ziehen) oder push-pull (schieben-ziehen)) dienen.
  • Der Autor von [SDPCN00] schlägt einen Satz von SDP-Erweiterungen vor, die einen minimalen und rückwärts kompatiblen Fähigkeitsverhandlungsmechanismus bereitstellen. [SDPCN00] fügt nur SDP-Erweiterungen zur Fähigkeitsverhandlung hinzu.
  • In „Codec capabilities Attribute for SDP" (IETF Internet Draft, work in progress, <draft-beser-mmusic-capabilities-00.txt>) von B. Beser, im Folgenden als [Beser00] bezeichnet, erweitert der Autor das SDP so, dass die Endpunkte die Codecauswahlen kennen und auf einem gemeinsamen Satz (Menge) übereinkommen können. Der Kommunikationspartner kann auf diese Weise Fähigkeiten und Präferenzen des Urhebers (originator) erhalten. Jedoch stellt die in [Beser00] vorgeschlagene Lösung nur SDP-Erweiterungen bereit, die für Endpunkte zum Verhandeln von Codecs notwendig sind.
  • In „capability Description for Group Cooperation" (IETF Internat Draft, work in progress, <draft-ott-mmusic-cap-00.txt>) von J. Ott et al., im Folgenden als [Ott99] bezeichnet, ist eine Notation zur Beschreibung potentieller und spezifischer Konfigurationen von Endsystemen bei Mehrparteien-Zusammenarbeitsessionen (multi-party collaboration sessions) gegeben. Diese ermöglicht Mechanismen zum Definieren von Endsystemfähigkeiten, Berechnen eines Satzes (Menge) gemeinsamer Fähigkeiten und Ausdrücken einer gewählten Medienbeschreibung zur Benutzung bei Sessionbeschreibungen. Sie stellen kein Protokoll für Fähigkeitenaustausch bereit. Jedoch stellt die bei [Ott99] vorgeschlagene Lösung nur eine Notation zur Konfigurationsbeschreibung bereit.
  • In „Simple Conference Control Protocol" (IETF Internet Draft, work in progress, <draft-ietf-mmusic-sccp-01.txt>) von C. Bormann et al., im Folgenden als [Bor00] bezeichnet, definieren die Autoren Dienste für ein einfaches Konferenzsteuerprotokoll (conference control protocol (SCCP)) für eng gekoppelte Konferenzen. Teilnehmermanagement (Teilnehmerverwaltung), Anwendungs/Sessions-Management (bzw. -Verwaltung) und Zugriffssteuerregeln für verteilten Anwendungsressourcen werden definiert. Der Konferenzstatus bzw. -zustand, der durch Benutzung des SIP hergestellt werden kann, wird während der Lebensdauer durch Benutzung des SCCP gemanagt (verwaltet). Dies inkludiert das Finden geeigneter Konfigurationen, Verhandeln bezüglich Konfigurationen und Ändern der Konfiguration. Jedoch ist keine Interaktion mit lokalem und Netzwerk-Ressourcenmanagement beabsichtigt. Das SCCP deckt auch die Behandlung von QoS-Verträgen und wie ihre Konfigurationen vorzuverhandeln sind nicht ab.
  • Das Dokument „The QoS Broker" (IEEE Multimedia Magazine Spring 1995 (2)1, Seiten 53 bis 67) von K. Nahrstedt und J. M. Smith, im Folgenden als [Nahr95] bezeichnet, präsentiert ein Modell für eine Endpunktarchitektur auf der Basis eines QoS-Brokers (Makler, -Informationsmakler), der eine funktionale Entität (entity) ist, die Ressourcen an den Endpunkten orchestriert und das Ressourcenmanagement über Schichten koordiniert. Um das System richtig zu konfigurieren, benutzt der Broker (Makler, Informationsmakler) Zuggriffssteuerung (admission control) und Verhandlung negotiation. Eine Verhandlung zwischen Peer-Entititäten führt zu einer gültigen Konfiguration, die alle notwendigen Komponenten des Kommunikationssystems involviert. Das in [Nahr95] beschriebene Modell integriert weder existierende Internetprotokolle noch zieht es andere Ressourcen wie Batterieleistung oder Drahllosteilnetzwerk-Verfügbarkeit (sub-network availability) in Betracht.
  • „SIP Requirements for Support of Multimedia and Video" (IETF Internet Draft, work in progress, <draft-levin-sip-for-viedeo-00.txt>) von O. Levin, im Folgenden als [LevinO01] bezeichnet, präsentiert einen Satz (Menge) von Erfordernissen für ein Anrufsteuerungsprotokoll (call-control protocol) für Echt- bzw. Realzeit-Multimedienunterstützung (real-time multimedia support) über dem IP. Fähigkeiten müssen ausgedrückt werden, Fähigkeiten müssen signalisiert werden, um die Menge von Ressourcen, die notwendig sind, zu identifizieren, und es besteht ein Bedarf an Rufsteuerungsmechanismen, um Medienströme innerhalb der Grenzen, die durch Fähigkeiten und reservierte Ressourcen festgelegt sind, zu öffnen/schließen/modifizieren. Sie schlagen auch vor, neue Fähigkeiten (wenn verfügbar) während einer Session in Aussicht zu stellen. Außerdem müssen die Peers über einen gemeinsamen Satz (Menge) von zu benutzenden Codecs übereinkommen. Ein Sessionssteuerungsmechanismus (session control mechanism) zum Starten/Stoppen der Medienströme ist als ein Erfordernis gesetzt.
  • Jedoch zieht [LevinO01] nicht die Integration eines lokalen, Fern- und Netzwerk-Ressourcenmanagements in ein kohärentes Gerüst in Betracht, vielmehr stellt [LevinO01] nur Erfordernissen bereit. Es werden weder Protokolle noch Mechanismen zum Forcieren der Erfordernisse vorgeschlagen.
  • In den Dokumenten
    • – „Concepts for Services Adaptation, Scalability and QoS Handling on Mobility-Enabled Networks" [BRAIN],
    • – "QoS Support for an All-IP System Beyond 3G" (IEEE Communication Magazine, August 2001, Vol. 39, No. 8) von T. Robles, A. Kadelka, H. Velayos, A. Lappetelainen, A. Kassler, H. Li, D. Mandato, J. Ojala und B. Wegmann, im Folgenden als [Roble01] bezeichnet,
    • – "BRENTA – Supporting Mobility and Quality of Service for Adaptable Multimedia Communication" (in: Proceedings of the IST Mobile Communications Summit 2000, Galway, Ireland, October 2000, Seiten 403–408) von A. Kassler et al., im Folgenden als [Kass100] bezeichnet, und
    • – "An Open Endsystem Architecture for Adaptable Multimedia Services with QoS Support" (in: Proceedings of the BRAIN workshop, London, 2000) von A. Kassler et al., im Folgenden als [Kass100a] bezeichnet,
    ist eine Endsystemarchitektur (end system architecture) präsentiert, die lokale, Peer- und Netzwerk-Ressourcenreservierung in ein Gerüst für das End-zu-End-QoS-Management integriert, bei dem Benutzerpräferenzen (user Preferences) und Anpassungs- bzw. Adaptierungspfade (adaptation paths) zusammen mit QoS-Zuständen (QoS states) zum Verhandeln einer QoS auf Anwendungsebene benutzt werden. Interaktion mit Lokalressourcenmanagement ist eingeführt. Die geschichtete Architektur stellt eine Unterstützung für verschiedene Typen von Anwendungen bereit.
  • Die drei Dokumente
    • – „Concepts for Service Adaptation, Scalability and QoS Concepts on Mobility-Enabled Networks" (IST Global Summit, 2001, Barcelona, September 2001, Seiten 285–293) von D. Mandato, A. Kassler, T. Sobles, G. Neureiter, im Folgenden als [Manda00] bezeichnet,
    • – „Handling End-To-End QoS in Mobile Heterogeneous Networking Environments" (PIMRC 2001, San Diego, 30/9/2001 bis 3/10/2001, Seiten C-49–C-54) von D. Mandato, A. Kassler, T. Robles und G. Neureiter, im Folgenden als [Manda00a] bezeichnet, und
    • – „Grouping of Media Lines in SDP" (IETF Internet Draft, work in progress, <draft-ietf-mmusic-fid-04.txt>) von G. Camarillo et al., im Folgenden als [Cama01] bezeichnet,
    diskutieren die Möglichkeit einer Bündelung bzw. Gruppierung (grouping) von Medienströmen, ziehen aber nicht Kriterien für die Gruppierung, die Möglichkeit eines rekursiven Gruppengebäudes (eine Gruppe aus vielen Gruppen) und die Behandlung von Realzeit-, Pseudorealzeit- und Nichtrealzeit-Informationsmedienströmen, die ebenfalls gruppiert werden können, nicht in Betracht. Überdies definieren [Manda00] und [Manda00a] Verhandlungsschritte, die bei einmaligen, aber nicht unabhängigen Phasen laufen dürfen oder nicht laufen dürfen und kein Erfordernis an die Konsistenz der verhandelten QoS-Information während einer Verhandlungsphase und nach ihr haben. Dadurch sind in [Manda00] die Kernkonzepte des E2ENP offenbart. Die Behandlung von kollidierenden „Ökonomieprinzip"-Anwendungen ist auch nicht in Betracht gezogen. Außerdem beschreiben [Manda00] oder [Manda00a] die Möglichkeit einer Einstellung und Verwaltung von Adaptierungspfaden für die QoS-Adaptation, die durch eine Drittparteikomponente (QoS-Broker) kontrolliert wird. Die Möglichkeit, dass die Endparteien die Verhandlungen selbst kontrollieren, ist nicht in Betracht gezogen.
  • In „A Framework for End-to-End user Perceived Quality of Service negotiation" (IETF Internet Draft, work in progress, <draft-bos-mmusic-sdpqos-framework-00.txt>) von L. Bos et al., im Folgenden als [Bos01] bezeichnet, ist eine End-zu-End-Benutzer-wahrgenommene QoS-Verhandlung end-to-end user-perceived QoS negotiation) beschrieben, unter der Annahme, dass gewisse Zwischenkomponenten und Dienste stark in die Endentscheidung über die verhandelte QoS-Information der End-Peers involviert sein können. Die beschriebene Entscheidung kann über gewisse Standard-„Vertragstypen" (standard „contract types) getroffen werden. Obgleich erwähnt ist, dass die Signalisierung und der Datenpfad verschiedene Wege durch das Netzwerk gehen können, wird vorgeschlagen, dass gewisse Zwischenkomponenten auf dem Weg des Verhandlungspfads die Verhandlung beeinflussen können, obgleich sie generell nichts mit den Datenpfaden zu tun haben. Durch dieses Protokollmodell ist das Netzwerk nicht transparent. Der Verhandlungsprozess gemäß [Bos01] wird bei einer einmaligen Verschachtelung auch mit einer gewissen Nicht-QoS-Information (beispielsweise Sicherheit, Netzwerkleitwert (network admittance) usw.) ausgeführt, es werden keine Protokollmodularität und Informationskonsistenz in Bezug auf die QoS in Betracht gezogen. Mit dem Modell von [Bos01] ist es nur möglich, einen Push-Modus für die Verhandlung zu benutzen, der für gewisse Anwendungen und Dienste restriktiv sein kann. Die Adaptierungspfade sind nur degradierend („Degradation Path (Degradationspfad") und fest. (Es gibt keine Möglichkeit, verschiedene Übergänge zwischen den abgemachten QoS-Verträgen auszuführen). Das Modell von [Bos01] schlägt Verhandlungen von QoS nur auf Medienstromebene ohne Berücksichtigung gewisser Medienstromabhängigkeiten wie Gruppen und Medienstromhierarchien vor.
  • In „Fundamental Questions Regarding End-to-End QoS" (work in progress, <draft-bergsten-e2eqos-questions-00.txt>) von A. Bergsten, K. Nemeth, I. Cselenyi und G. Feher, im folgenden [Berg01] bezeichnet, ist eine Liste von Schlüsselfragen (in Wirklichkeit reale Erfordernisse) vorgeschlagen. Insbesondere sind „1) der Austausch von QoS-bezogener Information und 2) das Forcieren von QoS-bezogenen Entscheidungen" als „erforderliche Verbesserungen zur Bereitstellung vorhersagbarer End-zu-End-QoS" bezeichnet. Das E2ENP erfüllt diese beiden Erfordernisse insofern, als es
    • – ein Anwendungsebene-Protokoll (application-level protocol) definiert, welches das erste Erfordernis behandelt, und
    • – Ressourcenmanagement entsprechend dem Ökonomieprinzip forciert.
  • Insbesondere in Bezug auf das zweite Erfordernis nimmt das E2ENP die Existenz des in [BRAIN] und [Roble01] beschriebenen Extended Socket Interface (ESI (erweiterte Sockelschnittstelle)) an, bei dem Details des Netzwerk-Ressourcenmanagements für Anwendungen verborgen sind. Dies bedeutet, dass das ESI eine Abstraktionsebene bietet, auf der QoS-unterrichtete Middleware und Anwendungen gebaut werden können. Sollte jedoch das ESI nicht zur Verfügung stehen, nimmt das E2ENP an, dass Anwendungen und/oder Middleware Netzwerkebene-QoS-Verträge von QoS-Verträgen hoher Ebene ableiten sowie auf niedriger ebene überwachte Information zur Auslösung von Anwendungs- und/oder Middleware-QoS-Adaptierungsmechanismen benutzen können.
  • Insbesondere sind in [Berg01] die folgenden fünf Punkte erwähnt:
    • 1. „Das Zugriffsnetzwerk (access network): die Wahrscheinlichkeit einer Überlastung (congestion) ist im Zugriffsnetzwerk die höchste, infolgedessen ist es sehr wahrscheinlich, dass eine gewisse Art eines die QoS-Information unterstützenden Mechanismus hier notwendig ist. „Dies ist exakt die in [BRAIN], [Roble01] (von denen das ursprüngliche Konzept des E2ENP stammt) gemachte Annahme, nach der die ESI-Abstraktion Anwendungen und/oder Middleware (die das E2ENP wirksam einsetzen) erlaubt, nicht nur generell jede Art von verfügbarer Netzwerkarchitektur zu benutzen, sondern auch (insbesondere) eine das Zugriffsnetzwerk betreffende ähnliche Annahme zu machen.
    • 2. „End-zu-End-Signalisierung (end-to-end signaling) zwischen Anwendungen: Es soll angenommen werden, dass in mehreren Fällen ein Informationsaustausch auf hoher Ebene die erste QoS-Sessioninitiierung sein muss". Dies ist exakt eines der Erfordernisse, auf welches das E2ENP abzielt. Außerdem behandelt das E2ENP proaktive Vorverhandlungen von Alternativen von QoS- Verträgen sowie von QoS-Verträgen höherer Ebene. Das E2ENP bietet überdies zusätzlich einen prallen Satz (Menge) von Prozeduren zur Behandlung von Wiederverhandlungen.
    • 3. „Zwischenbereichkommunikation (inter-domain communication), insbesondere bezüglich Peerverbindung bzw. -link (peering link): es ist eine automatische Dienstankündigung notwendig, etwas wie BGP, aber mit QoS-Verbesserungen. Außerdem wird in Betracht gezogen, einen Mechanismus zu haben, der eine Zwischenbereich- bzw. Interdomain-Bereitstellung dieser Ressourcen tatsächlich bereitstellt". Das E2ENP ist ein reines End-zu-End-Anwendungsebene-Protokoll (end-to-end application-level protocol), bei dem nur die Peers (und eventuell gewisse Zwischenkomponenten wie Konferenzbrücken oder Codeumsetzter (transcoder)) direkt involviert sind. Funktionalität niedrigerer Ebene, die Intradomain- und/oder Interdomain-Netzwerkressourcenmanagement und -Routing behandelt, ist dem E2ENP dank dem ESI oder einer äquivalenten Abstraktion verborgen. Dies bedeutet, dass das E2ENP ein reines Anwendungsebeneprotokoll ist, das Peers zum Kommunizieren über jeder Netzwerkarchitektur benutzen können.
    • 4. „Identifizieren, welcher Kunde im Fall einer Netzwerküberlastung zu belasten ist: Wenn eine Serverüberlastung auftritt und ein Vertrag zu brechen ist, sollte es unter der Kontrolle des Netzwerks sein". Das E2ENP ist mit diesem Erfordernis kompatibel, da das E2ENP annimmt, dass die Detektion einer QoS-Verletzung durch die zugrundeliegende Netzwerkarchitektur ausgeführt wird.
    • 5. „Bereitstellen von Erfordernisinformation für Kunden: Kunden könnten die Dienstprovider (provider = Anbieter) über die laufende und beabsichtigte Netzwerkbenutzung, welche beispielsweise die erwarteten Bestimmungen und Verkehrsvolumina spezifizieren, informieren. Der Betreiber könnte dann diese Kenntnis dazu benutzen, sein Netzwerk besser zu dimensionieren und auch die von benachbarten Betreibern zu kaufende Menge bzw. Größe von Diensten berechnen". Dies ist exakt die in [BRAIN] und [Roble01], von denen das ursprüngliche Konzept des E2ENP stammt, gemachte Annahme. Insbesondere können Benutzer nicht nur eine „gegenwärtige bzw. laufende und beabsichtigte Netzwerkbenutzung, welche beispielsweise die erwarteten Bestimmungen und Verkehrsvolumina spezifizieren", in Form von mit dem Netzwerkprovider (während des unten beschriebenen Prozesses) vorverhandelten Anwendungsebene-QoS-Verträgen bereitstellen, sondern auch mit Peers Sätze (Mengen) von alternativen QoS-Verträgen (die APs) und auf unterschiedlichen Abstraktionsebenen austauschen, um Zwischenmedienstrom-Beziehungen (inter-media stream relationships) (ebenso wie mit APs) zu berücksichtigen.
  • Schließlich ist in [Berg01] beschrieben, dass Peers mit ihren Netzwerkprovidern über den Typ von Quality of Service (Dienstqualität) zusammen mit Preisabspracheinformation vor jeder Sessionherstellung übereinkommen müssen. Dies ist ähnlich zu dem oben beschriebenen Prozess, bei dem der Benutzer die Anwendungsebene-QoS-Information spezifiziert, die eventuell zur Abbildung auf die Netzwerkebene-QoS-Verträge, die gegen Vorarrangements mit dem Netzwerkprovider oder über direkte Kommunikation mit letzterem validiert werden, kommen. Wie diese Prozesse niedriger Ebene im Rahmen des E2ENP ausgeführt werden, ist der ESI-Abstraktion (oder ähnlicher Funktionalität) zu danken.
  • Die drei Dokumente
    • – „Conferencing Using SIP" (IETF Internet Draft, work in progress, <draft-khartabil-sip-conferencing-00.txt>) von H. Khartabil, im Folgenden als [Khart01] bezeichnet,
    • – „Models for Multi-party Conferencing in SIP" (IETF SIPPING Working Group, work in progress, <draft-rosenberg-sip-conferencing-models-01.txt>) von J. Rosenberg und H. Schulzrinne, im Folgenden als [Rosen01] bezeichnet, und
    • – „Models for Multi-party Conferencing in SIP" (IETF SIPPING Working Group, work in progress, <draft-ieft-sipping-conferencing-models-00.txt>) von J. Rosenberg und H. Schulzrinne, im Folgenden als [Rosen00a] bezeichnet,
    führen Modelle zur Mehrparteienkonferenz ein, die Szenarios wie Eins-zu-Viele- und Viele-zu-Viele-Verbindungen (one-to-many and many-to-many connections) in Betracht ziehen. Die beschriebenen Modelle ziehen Vorteil aus einer zentralisierten Architektur unter Benutzung eines Konferenzservers. In diesem Fall gibt es keine direkte End-zu-End-Kommunikation (end-to-end communication) zwischen den End-Peers, und die Anwendung des E2ENP könnte auf mehreren verschiedenen Wegen ausgeführt werden:
    • – Direkte Signalisierung zwischen den End-Peers, Datenpfad über den Konferenzserver,
    • – indirekte Signalisierung zwischen den End-Peers über den Konferenzserver, direkte Datenverbindung zwischen den End-Peers, und
    • – indirekte Signalisierung zwischen den End-Peers über den Konferenzserver und Datenpfad über ihn.
  • Eine solche Anwendung des E2ENP kann verschiedene Mitteilungssequenzen und eine E2ENP-Struktur für jedes andere Szenario erfordern. Die Modelle von [Khart01], [Rosen01] und [Rosen00a] betreffen hauptsächlich die Beschreibung der Mitteilungsfolgen durch ein Konferenzszenario unter Benutzung einer zentralisierten Komponente. Durch notwendige Fähigkeiten- und/oder QoS-Verhandlungen und jeweilige Reservierungen können diese Sequenzen Änderungen erfahren, wenn das E2ENP auch auf solche Szenarios angewendet werden soll. Der Vorteil der E2ENP-Anwendung in einem Szenario mit gewissen zentralisierten Komponenten liegt darin, dass das Kommunikationsmodell auf ein Eins-zu-Viele-Szenario reduziert werden kann.
  • Im folgenden soll eine Anzahl von Ausdrücken, die zur Definition der Ansprüche und der Beschreibung der zugrundeliegenden Erfindung notwendig sind, gegeben werden.
    • – Adaptierungspfad (Adaptation Path, AP): Ein geordneter Satz (Menge) von QoS-Verträgen (QoS contracts), der benutzerspezifische Präferenzen und Wünsche anzeigt, die benutzt werden können, um Anwendungen und/oder Middleware zu erlauben, Anpassungs- bzw. Adaptierungsstrategien in vorgeplanter Weise anzunehmen. Typischerweise ist der wichtigste QoS-Vertrag (das heißt, der jenige, den das System versuchen sollte, durch Vorgabe zu forcieren (forcieren umfasst durchsetzen, geltend machen, erzwingen, zwingen, auffordern bzw. einhalten) ist der im Pfad als erster angezeigte. Außerdem kann ein AP die Spezifikation von Regeln inkludieren, welche die Umstände definieren, unter denen das System einen anderen QoS-Vertrag aus seinem gegebenen Satz forcieren soll.
    • – Assoziation (Association): eine Gruppe von mit einem gegebenen Peer assoziierten Medienströmen. Als Unterfall einer Medienströmegruppierung gruppiert eine Assoziation alle Medienströme, die vom gegebenen Endgerät eines Benutzers stammen und/oder dort enden und mit einem gegebenen Peer in der gegebenen Session verbinden. Deshalb soll die Spezifikation einer Assoziation einen Identifizierer des Peers (beispielsweise einen URL, eine Telefonnummer oder ein Paar aus einer IP-Adresse und einer Portnummer) aufweisen.
    • – Antworter (Answerer): Der Antworter ist ein Teilnehmer einer SIP-Session, der eine Antwort auf eine vorgeschlagene Multimediensessionbeschreibung eines Anbieters (siehe unten) erzeugt. Die Antwort enthält eine Beschreibung der Bedingungen, unter denen die vorgeschlagene Sessionbeschreibung des Anbieters unterstützt werden kann. [SDPOA00]
    • – Assoziations- oder Gruppenadaptierungspfade (Association or Groups Adaptation Paths): Als ein Adaptierungspfad modelliert kann eine Konfiguration aus alternativen Assoziationen und Gruppen zusammen mit ihren QoS-Kontexten und Stromebene-QoS-Verträgen benutzt werden, um Anwendungen und/oder Middleware zu erlauben, Adaptierungsstrategien in einer vorgeplanten Weise zu anzunehmen.
    • – Fähigkeit (Capability): Mit einem Hardware- und/oder Softwareprofil eines Endgeräts assoziert beschreibt eine Fähigkeit die Fähigkeit dieses Geräts, gewisse Aufgaben auszuführen und/oder gewisse Informationstypen zu behandeln. Eine einzelne Fähigkeit kann mit einer gewissen Größe bzw. Menge von Hardware- und/oder Softwareressourcen (deren jede einen gegebenen Informationstyp behandelt) assoziert sein. Eine mit einem gegebenen einzelnen Typ von Information assozierte Fähigkeit kann dazu benutzt werden, diese Information bei einer oder vielen QoS-Ebenen zu präsentieren. Andererseits kann eine gegebene QoS-Ebene mit verschiedenen Fähigkeitssätzen assoziert sein (beispielsweise können verschiedene Kodex von der Anwendung her betrachtet eine und dieselbe QoS-Ebene erzeugen).
    • – Verbindungsmodus (Connection Mode): Der Verbindungsmodus betrifft einen durch die Peers ausgetauschten tatsächlichen Datenmedienstrom. Diese Information sind die Medien (Audio, Video usw.), die vom Endbenutzer direkt wahrnehmbar sind. Der Verbindungsmodus stellt fest, wer die Sender- und wer die Empfängerparteien der Medienströme sind.
    • – Datenpfad (Data Path): Der von den Mediendaten (Audio, Video, Text usw.) genommene Netzwerkpfad.
    • – Ökonomieprinzip (Economy Principle): Das Ökonomieprinzip diktiert die Reihenfolge der Ressourcenreservierung. Da Netzwerkressourcen gemeinsam benutzt und auf diese Weise teurer als Endgerätressourcen sind, ist es besser, zuerst die Ressourcen auf allen Endgeräten zu reservieren und dann mit einer Netzwerkressourcenreservierung fortzufahren.
    • – End-zu-End-QoS-Vorverhandlung (End-to-End Qos-Pre-Negotiation): Ein Prozess, den End-Peers vor dem tatsächlichen Start einer Session und unabhängig von der Session selbst ausführen können, um – in einer nicht obligaten Weise – Information über Konfigurationen von QoS-Spezifikationen, die von ihren QoS-Profilen abgeleitet ist, auszutauschen. Diese Konfigurationen umfassen Adaptierungspfade, so dass die End-Peers auf dem Weg proaktiv übereinkommen können, um auf mögliche QoS-Änderungen oder QoS-Verletzungen auf effektive und effiziente Weise zu reagieren. Der Vorverhandlungsnachrichtaustausch hat für die End-Peers informellen Charakter und wird nicht nur zum vorher einander Informieren über die Fähigkeiten und Ausführungsmöglichkeiten, die beim gegebenen Satz von Peers anwendbar sind, benutzt, sondern auch zum Erreichen von Übereinkünften bezüglich einer Neudefinierung gewisser von diesen Konfigurationen. Auf diese Weise können die Peers somit vor jedem speziellen Geschäft ein gemeinsames Vokabular erstellen. Die Resultate dieses Prozesses sind zeitlich beschränkt und können innerhalb ihres Gültigkeitsintervalls mehrere Male benutzt werden.
    • – End-zu-End-QoS-Kompaktverhandlung (End-to-End QoS Compact Negotiation): Ein Prozess, den End-Peers entweder vor oder nach dem aktuellen Start einer Session ausführen können, um auf einer für die gegebene Session und Medienströme zu forcierenden gegebenen QoS-Ebene auf der Basis von Resultaten eines vorher ausgeführten End-zu-End-QoS-Vorverhandlungsprozesses übereinzukommen (es sei angenommen, dass die Validität dieser Resultate noch zu der Zeit, bei der dieser Prozess läuft, gilt). Dieser Prozess ist verglichen mit dem Fall der End-zu-End-QoS-Vollverhandlung bedeutend schneller, da zwischen Peers tatsächlich nur Referenzen von vorverhandelter Information ausgetauscht werden. Bei Vollendung des End-zu-End-QoS-Kompaktverhandlungsprozesses sind die End-Peers über die QoS-Profile, die sie für die Kommunikation benutzen wollen, übereingekommen.
    • – End-zu-End-QoS-Vollverhandlung (End-to-End-QoS Full Negotiation): Ein Prozess, den End-Peers entweder vor oder beim tatsächlichen Start einer Session ausführen können, um auf einer gegebenen QoS-Ebene darin übereinzukommen, die gegebene Session und gegebenen Medienströme, eventuell durch Neudefinieren gewisser der ursprünglich vorgeschlagenen Konfigurationen von QoS-Spezifikationen, zu forcieren. Bei Vollendung des End-zu-End-QoS-Kompaktverhandlungsprozesses sind die End-Peers über die QoS-Profile, die sie für die Kommunikation benutzen wollen, übereingekommen.
    • – End-zu-End-QoS-Kompaktwiederverhandlung (End-to-End-QoS-Compact Re-Negotiation): Ein Prozess, den End-Peers bei Detektion entweder einer QoS-Änderung oder einer QoS-Verletzung auslösen können, um auf einer für die gegebene Session zu forcierenden gegebenen QoS-Ebene auf der Basis eines zuvor angewendeten End-zu-End-QoS-Vorverhandlungsprozesses übereinzukommen (unter der Annahme, dass die Validität dieser Resultate zu der Zeit, zu der dieser Prozess läuft, noch gilt). Dieser Prozess ist im Vergleich zu dem Fall der End-zu-End-QoS-Vollverhandlung bedeutend schneller, da zwischen Peers nur Referenzen von vorverhandelter Information tatsächlich ausgetauscht werden. Bei Vollendung des End-zu-End-QoS-Kompakt-Wiederverhandlungsprozesses sind die End-Peers über neue QoS-Profile, die sie für die Kommunikation zu benutzen beginnen, übereingekommen.
    • – End-zu-End-QoS-Vollwiederverhandlung (End-to-End-QoS Full Re-Negotiation): Ein Prozess, den End-Peers bei Detektion entweder einer QoS-Änderung oder einer QoS-Verletzung auslösen können, um auf einer zu forcierenden gegebenen QoS-Ebene für die gegebene Session und gegebenen Medienströme, eventuell durch Neudefinieren einiger der ursprünglich vorgeschlagenen Konfigurationen von QoS-Spezifikationen, übereinzukommen. Bei Vollendung des End-zu-End-QoS-Vollwiederverhandlungsprozesses sind die End-Peers über neue QoS-Profile, die sie für die Kommunikation zu benutzen beginnen, übereingekommen.
    • – Fluss (Flow): Ein Fluss ist ein Satz (Menge) von Paketen, der einen Überwachungs- bzw. Beobachtungspunkt (observation point) im Netzwerk während eines gewissen Zeitintervalls passiert. Alle zu einem speziellen Fluss gehörenden Pakete weisen einen Satz (Menge) gemeinsamer Eigenschaften auf, die von den im Paket enthaltenen Daten und von der Paketbehandlung beim Beobachtungspunkt abgeleitet sind, wie es in „Requirements for IP Flow Information Export" (siehe <draft-ieft-ipfix-reqs-00.txt>) von J. Quittek et al, im Folgenden als [Quit00] bezeichnet, beschrieben ist. Als Beispiel sollten alle Pakete für einen gegebenen Fluss das gleiche 5-Tupel (Protokoll ID, Quellennetzwerkadresse, Bestimmungsnetzwerkadresse, Quellenportnummer, Bestimmungsportnummer) aufweisen. Einfache Medienströme (das heißt solche ohne multiplexierten Layers) und Layers werden bei einer Transportlayer auf Flüsse abgebildet, wo sie zur Reservierung benutzt werden. Ein einzelner Fluss kann eine einzelne Ebene eines gegebenen Medienstroms oder einen gegebenen einfachen Medienstrom en-block tragen.
    • – Gruppe von Medienströmen (Group of Media Streams): Auf der Basis verschiedener Kriterien können Medienströme zum Forcieren gewisser Beschränkungen logisch gruppiert werden, beispielsweise Gruppieren aller Audiomedienströme zum Forcieren von Übersetzung (translation), Gruppieren aller von einem gegebenen Benutzer bei einem Mehrbenutzerendgerät (multi-user-terminal) geöffneten Medienströme, um Quoten zu forcieren. Eine Gruppe kann auch nur einen einzelnen Medienstrom inkludieren. Gruppen sind zur Darstellung von Bündeln von Medienströmen, die QoS-Gewahrwerdungsanwendungen (QoS-aware applications) als Ganzes behandeln können, wenn bezüglich Ressourcenverfügbarkeit zwischen einer Vielfalt äquivalenter Bündel und innerhalb eines gegebenen QoS-Kontextes Qualität abgehandelt wird, nützlich. Jede Gruppe ist mit einem QoS-Kontext assoziiert.
    • – Zwischenkomponenten (Intermediate Components): Die Zwischenkomponenten sind irgendwelche Netzwerkkomponenten, die zwischen zwei Endgeräten (Anschlüssen), die das durchkommende Protokoll, das die Endgeräte wenigstens auf Netzwerkebene benutzen, verstehen können, auf dem Signalisierungs- und/oder Datenpfad angeordnet sind. Die Zwischenkomponenten können Router, Proxies, unabhängige Dienste, Teile eines Informationsmaklers (Broker) usw. sein. Die Zwischenkomponenten bauen das Netzwerk zwischen den End-Peers.
    • – Layer (Ebene, Schicht): Medienströme können in mehrere Layers codiert werden, wobei jede Layer die Detailebene relativ zu einer gegebenen Basisinformation (von der sogenannten „Base Layer (Basisebene)" geöffneten Medienströmen) inkrementell verbessert. Dies bedeutet, dass ein Hinzufügen von Layers die Detailebene der Basisinformation zunehmend erhöhen kann. Jede Layer kann auf einen gegebenen Fluss abgebildet werden.
    • – Verhandlungsmodus (Negotiation Mode): Der Verhandlungsmodus bezieht sich auf den Signalisierungspfad und die Verhandlungsinformation, die von den Peers zum Austauschen von Information bezüglich des Managements und der Steuerung bzw. Kontrolle der Datenmedienströme benutzt werden. Der Verhandlungsmodus stellt fest, wer bei der Verhandlung die Anbieter- und wer die Antworterparteien sind.
    • – Mediator (Vermittler): Der Mediator bzw. Vermittler ist eine Funktionalität eines Peers zum Umleiten hereinkommender Anrufe zu einem oder mehreren anderen Peers entsprechend gewissen Profilvoreinstellungen des Benutzers und/oder des Dienstproviders des jeweiligen Peers mit einer solchen erleichternden Funktionalität.
    • – Anbieter (Offerer): Der Anbieter ist ein Teilnehmer einer SIP-Session, der eine Multimediensessionsbeschreibung erzeugte, die der Anbieter durch Eröffnen der Multimediensession zu benutzen wünscht. Diese Beschreibung wird zum Antworter transportiert (siehe oben). [SDPOA00]
    • – Peer (Gleichgestellter): Ein mit einem Endbenutzer assoziierter Dienst oder assoziiertes Endgerät.
    • – Qualitiy of Service (QoS (Dienstqualität)): Der kollektive Effekt einer Dienstperformance (Performance = Ausführung, Betriebsverhalten, Leistung, Leistungsfähigkeit), der den Grad an Zufriedenstellung eines Benutzers des Dienstes entsprechend einer Definition aus der ITU-T(früher CCITT) Recommendation E.800 bestimmt. Dadurch kann die QoS für jeden Dienst mit einem Satz (Menge) von Parametern, die den Dienst charakterisieren, beschrieben werden. Als ein Beispiel kann für einen Videokonferenzdienst die QoS als die vom Endbenutzer beobachtete gesamte End-zu-End-QoS, die durch Parameter wie Rahmenrate, visuelle Qualität und Verzögerung gemessen werden kann, definiert werden.
    • – QoS-Änderung (QoS Change): Die vom Dienstbenutzer eingeleitete Änderung des QoS-Vertrags.
    • – QoS-Kontext (QoS-Context): Ein QoS-Kontext identifiziert eine Anordnung von QoS-Parametern, die durch einen gegebenen Satz (Menge) von Medienströmen hindurch forciert werden soll. Ein QoS-Kontext ist eine als eine Spezialisierung des QoS-Vertragskonzepts modellierte logische Identität.
    • – QoS-Vertrag (QoS Contract): Übereinkommen zwischen einem Benutzer und einem gegebenen Dienstprovider, das QoS-Erfordernisse und -Beschränkungen spezifiziert, sowie die zum Spurhalten auf der QoS während aller Phasen des Dienstes erforderlichen Grundsätze (Policies). QoS-Verträge generalisieren das Konzept von Medienstromebene- QoS-Verträgen und von Verträgen höherer Ebene, die sogenannten QoS-Kontexte. Dies bedeutet, dass QoS-Verträge in einer hierarchischen Struktur organisiert werden können.
    • – QoS-Vertragstyp (QoS Contact Type): Erfasst die Struktur einer Klasse von QoS-Verträgen durch Identifizieren, wie individuelle QoS-Verträge die QoS-Eigenschaften über einem gegebenen Satz von QoS-Parametertypen spezifizieren, in „QML: A Language for Quality of Service Specification" (HP-Lab Technical Reports, HPL-98-10, 980210) von S. Frolund und J. Koistinien, im Folgenden als [Frolu98] bezeichnet, auch als Dimensionen (dimensions) bekannt. Jeder Parametertyp besteht aus einem Namen und einem Bereich von Werten. QoS-Spezifikationen können einfach als ein Satz von Beschränkungen über den Bereichen (Domains), einer pro Proparametertyp, intendiert sein.
    • – QoS-Ebene (QoS Level): Der mehrdimensionale QoS-Raum von Parametern, der einen Dienst charakterisiert, kann in mehrere diskrete Teilräume unterteilt werden. Ein gegebener Teilraum wird als eine QoS-Ebene bezeichnet und soll durch den Dienstbenutzer von anderen QoS-Ebenen unterscheidbar sein. Ein QoS-Vertrag beschreibt eine spezielle QoS-Ebene und wird zum Forcieren einer solchen Ebene in dem Fall, dass eine Wiederverhandlung stattfindet, benutzt. In anderen Worten nehmen Benutzer QoS-Ebenen als das Resultat einer Anwendung gewisser QoS-Verträge bei den gegebenen Diensten wahr. Es kann jedoch gewisse natürliche, anwendungsspezifische oder geschäftsspezifische vordefinierte Unterteilungen des QoS-Raums geben, wobei Benutzer dann ihre eigenen QoS-Verträge auf QoS-Ebenen (die zur gegebenen Unterteilung gehören) in unterschiedlichen Ausmaßen (Eins-zu-Eins, Überschneidung, unterschiedliche Granularität usw.) abbilden.
    • – QoS-Parameter (QoS Parameter): Ein QoS-Parameter ist eine funktionelle Darstellung einer einzelnen Charakteristik eines gegebenen Dienstes (als Beispiel die gesamte End-zu-End-Verzögerung (end-to-end delay)).
    • – Den in „Information Technology – Quality of Service: Framework" (ITU-T Recommendation X.641, 12/97, ISO/IEC 13236:1998), im Folgenden als [ISOX641] bezeichnet, dargelegten Definitionen folgend identifizieren QoS-Parameter (in ISO-Terminologie die QoS-Charakteristiken (QoS-characteristics)) messbare, QoS-bezogene Größen und können weiter in generische, spezialisierte und abgeleitete klassifiziert werden. -- Generische QoS-Parameter (generic Qos parameters) versuchen einen gemeinsamen zugrundeliegenden QoS-Parameter zu erfassen, der auf alle besonderen Umstände angewendet werden kann, unabhängig davon, was anzuwenden ist. -- Spezialisierte QoS-Parameter (specialized QoS parameters) sind konkrete Fälle von generischen QoS-Charakteristiken (eventuell können generische QoS-Charakteristiken ausreichend konkret zum Benutzen wie sie sind sein, aber in den meisten Fällen ist eine Spezialisierung erforderlich, um die system- oder netzwerkspezifische Besonderheit zu erfassen). Beispielsweise kann eine generische Zeitverzögerungs-QoS-Charakteristik (Time Delay QoS characteristic) so weiter spezialisiert werden, dass systemimplementationsspezifische Ausgaben reflektiert werden. Die Spezialisierungslösung ist gut geeignet zur Adressierung komplex verteilter System durch Abbilden von QoS-Charakteristiken auf geeignete Ebenen von Abstraktionen (levels of abstractions). -- Abgeleitete QoS-Parameter (derived QoS parameters) erfassen die Abhängigkeiten zwischen QoS-Charakteristiken auf der Basis mathematischer Beziehungen. Gewisse abgeleitete QoS-Charakteristiken können sogar statistischer Natur sein (beispielsweise Maximum, Minimum, Bereich, Mittelwert, Streuung und Standardabweichung, n-Prozentil bzw. n-Prozentsatz, statistische Momente usw.). Auch abgeleitete QoS-Parameter können ganz wie die generischen spezialisiert werden. Deshalb können Spezialisierung und Ableitungen als orthogonale Transformationen von QoS-Charakteristen betrachtet werden. Jedoch muss darauf hingewiesen werden, dass eine Ableitung mehr als eine generische/abgeleitete/spezialisierte QoS-Charakteristik umfassen kann (beispielsweise ist Verfügbarkeit eine Funktion von Zuverlässigkeit und Wartungsfreundlichkeit).
    • – QoS-Profil (QoS Profile): Eine Sammlung von Endbenutzerpräferenzen spezifizierenden Daten in Form von QoS, betreffend die Benutzung eines gegebenen Dienstes. QoS-Profile können auf dem Endgerät des Benutzers oder in spezifischen Datenbanken gespeichert sein.
    • – QoS-Spezifikation (QoS Specification): Genereller Ausdruck zur Identifizierung eines Satzes (Menge) von QoS-Parametern und -Beschränkungen, die von einem Benutzer für einen gegebenen Dienst spezifiziert sind.
    • – QoS-Verletzung (QoS Violation): Die vom Dienstprovider verursachte Verletzung eines Qos-Vertrags.
    • – Session (Sitzung): Ein Satz (Menge) von dauerhaften Verbindungen zwischen zwei oder mehreren Peers (Benutzerendgeräte oder Dienste), welche üblicherweise den Austausch von vielen Paketen „assoziierter Information" (die Information einer Session betrifft ein gewisses Thema oder einen gewissen Vorgang) zwischen den Peers involviert. Gemäß „SDP: Session Description Protocol" (IETF Request for Comments: 2327, April 1998) von M. Handley und V. Jacobson, im folgenden als [Handl98] bezeichnet, ist eine Multimediasession "ein Satz (Menge) von Multimediensendern und -empfängern und die von Sendern zu Empfängern fließenden Datenmedienströme. Eine Multimedienkonferenz ist ein Beispiel einer Multimediensession". Hier werden zwei Sessionstypen in Bezug auf ihren Kontext zur Kenntnis genommen: -- Mediensession (Media Session) – Die Mediensession weist den Kontext einer Übertragung von Benutzerwahrnehmbaren Daten zwischen Peers auf. -- Signalisierungssession – Die Signalisierungssession weist den Kontext einer Verhandlung von Mediensessioneinstellungen und -verweiluungen (stays) auf, die für den Endbenutzer generell unsichtbar sind. Zur Ausführung einer Signalisierungssession können das SIP, SCCP usw. benutzt werden. Die Signalisierungssession ist für die Anwendung sichtbar und kann für den Benutzer nur sichtbar werden, wenn die Anwendung eine gewisse Benutzerintervention oder eine Benutzerereigniserzeugung (beispielsweise Aufbauen eines GUI-Fensters von unten nach oben mit dem Erfordernis, einen oder einen anderen virtuellen Button (Knopf) zu drücken) benötigt.
  • Es sei darauf hingewiesen, dass gewisse Protokolle (beispielsweise das Real-Time Transfer Protocol, RTP (Realzeit-Übertragungsprotokoll)) sowohl die Mediendaten als auch die Medienbeschreibung übertragen kann und so die Medienübertragung und die Signalisierung parallel ausführt.
    • – Signalisierungspfad (Signaling Path): Der von den SIP-Mitteilungen genommene Netzwerkpfad.
    • – Medienstrom (Media Stream): Der kontinuierliche unidirektionale Austausch von Information zwischen zwei Peers auf Anwendungsebene. Es können verschiedene Typen von Medienströmen existieren: Audio, Video, Daten, Text oder jede Kombination daraus. Eine gegebene Partei kann als eine reine Medienstromquelle (die ausschließlich Information aussendet), als eine reine Medienstromsenke (die mediengeströmte Information von einer anderen Partei wie beispielsweise einem Video-on-Demand-Dienst (Auf-Abruf-Videodienst)) sammelt, oder sowohl als Medienstromquelle als auch Medienstromsenke (was typisch für einen Konversationsmodus wie beispielsweise einen Videokonferenzdienst ist) agieren. Ein einzelner Media- bzw. Medienstrom kann auf einen oder mehrere Flüsse abgebildet werden.
  • Im folgenden Abschnitt seien verschiedene mögliche Kommunikationsszenarios beschrieben, die in einer Multimedienlandschaft bzw. -umgebung auftreten können und die aus der Benutzung eines End-to-End QoS Negotiation Protocol (E2ENP) Nutzen ziehen.
  • Der Abschnitt führt zuerst Schlüsseldefinitionen der Parteien und der für die Kommunikation in Betracht gezogenen Komponenten sowie die Strukturen, die sie zum Bilden der Kommunikationsarchitektur bauen, ein.
  • Die beschriebenen Architekturen sind mit gewissen spezifischen Diensten assoziiert. Es werden verschiedene Kommunikationsmoden, welche die Teilnehmer zur Verhandlung von QoS benutzen, in Betracht gezogen. Zum Definieren der Benutzungsfälle sind die folgenden Aspekte zu berücksichtigen.
  • Wer sind die kommunizierenden Parteien,
    wer ist der Initiator der Verbindung,
    wie viele kommunizierenden Partein nehmen bei einem speziellen Kommunikationsszenario teil,
    welche Art von Struktur bauen die kommunizierenden Partein, und
    welche Art von Verbindungsmodus (Senden an individuellen Empfänger (unicast) oder Mehrfachsenden an mehrere Empfänger (multicast)) wird angewendet.
  • Schließlich werden einige Beispiele gegeben, um die Arbeitsidee der Szenarios zu zeigen.
  • Die Endsystem-Kommunikationspartein – Anbieter und Antworter – sind die aktiven Komponenten jeder End-zu-End-Verhandlung. Gemäß den oben dargelegten Definitionen sind die Anbieter und Antworter Peers: Der Anbieter ist die Partei, die den Verbindungsverhandlungsprozess startet. Die vom Anbieter kontaktierten Antworter sind die Parteien, die eine Verbindung mit ihm herzustellen wünschen. Die verschiedenen Parteien können bei der tatsächlichen Kommunikation eine aktive Rolle als ein Sender (das heißt Senden oder Senden/Empfangen von Medienströmen) oder eine passive Rolle als ein Empfänger (das heißt Empfangen von Medienströmen) annehmen.
  • Ein anderer Typ von Kommunikationspartei ist die Zwischenkomponente. Diese Komponenten können in Form von Komplexität in unterschiedlichen Ausmaßen differieren und können auf verschiedenen Ebenen der Netzwerkverbindung angewendet werden. Die Zwischenkomponenten können alle Einrichtungen (Proxies, Router usw.) und Dienste innerhalb des Netzwerks (beispielsweise Benennung, Zuordnung, Präsenz usw.) sein. Die Zwischenkomponenten sind in diesem Fall gerade passive Akteure, die nur den Aufbau der Verbindung zwischen den End-Peers unterstützen, aber nicht die Verhandlungsprozesse zwischen ihnen stören. Die Annahme des E2ENP ist, dass keine Zwischenkomponenten am Verhandlungsprozess teilnehmen, dass sie eher etwas von der verhandelten Information beeinflussen können, bevor oder nachdem die Verhandlung stattgefunden hat. Deshalb ist es notwendig, Zwischenkomponenten in Bezug auf ihre Funktionalität und ihren Einfluss auf die verhandelte Information in Betracht zu ziehen.
  • Durch Herstellung einer Verbindung ist es wichtig, festzusetzen:
    • 1. Der Verhandlungsmodus (negotiation mode) beschreibt die Folge eines Austauschs von Fähigkeit- und QoS-Verhandlungsinformation und welche Partei ihren Vertrag zuerst sendet. In diesem Bereich werden die folgenden Moden differenziert: a. Der Push-Modus (push mode (Schiebemaodus))) wird benutzt, wenn ein Anbieter dem Antworter ein Angebot darüber macht, wie die Verbindungseinstellungen gemacht werden, und im Voraus seine Fähigkeiten und QoS-Wünsche erklärt. Der Push-Modus kann mit Eins-zu-Eins-telefonartiger Sprache-über-IP- bzw. VoIP-Kommunikation (one-to-one teleohone-like Voice-over-IP (VoIP) communication) benutzt werden. b. Der Pull-Modus (pull mode (Zieh-Modus)) wird benutzt, wenn ein Anbieter den Antworter anruft, ohne Wünsche über die Verbindungseinstellungen zu erklären. Der Anbieter gewinnt diese Information vom Antworter wieder und passt seine Wünsche bezüglich des empfangenen Profils an. Dieser Modus kann für verschiedene Dienste wie „Video on demand (Video auf Abruf)" oder durch „virutal lecturing (virtuelles Vortragen bzw. Vorlesen)", wenn der zentrale Peer („VoD Server" oder der Vortragende bzw. Vorlesende) zu benutzende Profile vordefiniert, benutzt werden. c. In gewissen Fällen kann es, immer wenn der Anbieter dem Antworter nicht nur ein Angebot über die Verbindungseinstellungen macht, sondern auch gleichzeitig die Einstellungen des Antworters wiedergewinnt, notwendig sein einen Push-Pull-Modus (push-pull mode (Schiebe-Zieh-Modus)) zu benutzen.
    • 2. Der Verbindungsmodus (Connection Mode): Die Kenntnis, welcher Peer der Sender und welcher der Empfänger ist, dient zur Feststellung, welcher der Verhandlungsmoden (Push/Pull) beim Beginnen einer Verhandlung vernünftiger zu benutzen ist.
    • 3. Die Verbindung arbeitet (insbesondere in den Fällen, bei denen es mehr als einen Teilnehmer gibt) a. als ein Mehrfachsender zu einer Gruppe von Empfängerparteien, b. als ein Einfachsender zu jeder empfangenden Partei.
    • 4. Die Zahl der Kommunikationsparteien (communication parties) ist die Information, die zur Bestimmung, welcher der Verhandlungsmoden (Push/Pull) vernünftiger anzuwenden ist, und in welcher Folge die Verhandlungs-Subprozesse stattfinden würden, notwendig ist. Die Kommunikationsparteien können die folgenden Verbindungsstrukturen (connection structures) bilden: a. Eins-zu-Eins (one-to-one): Diese kann ein Telefoniefall zwischen zwei Parteien sein. Ein typisches Dienstbeispiel hier ist VoIP (siehe Beispiel unten). b. Eins-zu-Viele (one-to-many) – Dies ist der Fall des VoD-Dienstes oder On-line-Vortragens bzw. -Vorlesens (siehe Beispiel unten). c. Viele-zu-Viele (many-to-many) – Ein typisches Beispiel hier ist das virtuelle Konferenzieren (virtual conferencing) (siehe Beispiel unten).
  • Im folgenden Abschnitt sollen einige Beispiele von Komminkationsszenarios beschrieben werden, um den Bedarf an einem Verhandlungsprotokoll besser zu erkennen. Da die sehr einfache Peer-zu-Peer-Kommunikation (Eins-zu-Eins-Kommunikation) schon in der Literatur [SDPOA00] eingehend beschrieben ist, ziehen die folgenden Szenarios einige komplexere Kommunikationsmuster in Betracht. Die Szenarios beschreiben gewisse typische Situationen, die bei dynamischen Kommunikationen und bei Mehrparteiverbindungen auftreten können. Es wird der Einfluss der Mobilität von Einrichtungen und Personen in Bezug auf mobile Netzwerke gezeigt. Es werden einige Ideen möglicher Informationsabhängigkeiten und die Art und Weise, dies zu beschreiben, eingeführt. Die Beispiele zeigen gewisse Aspekte der Mehrparteikommunikation, bei der die Benutzung von Zwischenkomponenten als passive Kommunikationsparteien involviert sein kann.
  • Das in 1 gezeigte Beispiel zeigt eine Anrufverschiebung 108 bei einer Schaltsituation einer Telekommunikationssession 102 für ein Eins-zu-Eins-Kommunikationsszenario 100, zeigend die Idee, wie die zukünftige telefonartige Kommunikation arrangiert werden kann. Die bei diesem Szenario involvierten zwei Benutzer 104a+d seien Mary und Kate genannt.
  • Mary empfängt auf ihrer internetfähigen Uhr 106a1 einen Anruf von ihrer Freundin Kate, die über ihren neuen Freund erzählen will. Der Anruf überträgt eine Mitteilung, die anzeigt, „wer ruft an" (die Identifikation des Anrufers) und „worum geht es bei dem Anruf" (Subjektinformation). Marys Uhr 106a1 kann die empfangenden hochauflösenden Bilder 112 nicht zeigen, da ihr Monitor sehr klein und monochrom ist, so dass sie automatisch die Suche nach einem Gerät 106a2 startet, welches dies tun kann. Sie verbindet sich mit dem zentralen Heimserver und findet heraus, dass Marys Profil anzeigt, dass sie dazu autorisiert ist, ein intelligentes Endgerät 106a2 in ihrem Zimmer bzw. Raum zu benutzen. Die Uhr 106a1 kontaktiert das „Raum"-Gerät 106a2 zur Verschiebung der Session 103 und informiert Mary, dass auf ihrem „Raum"-Gerät 106a2 ein Anruf 110 auf sie wartet. Aus diesem Grund bewegt sich Mary zu ihrem Raum, um den Anruf 110 anzunehmen. Indessen weiß Kate, dass Mary ihren Anruf 110 angenommen hat, jedoch eine gewisse Zeit für die Verschiebungsprozedur 108 benötigt. Diese Information wird dann durch ein geeignetes Protokoll weitergeleitet. Sie weiß auch, dass Mary den Anruf 110 auf einem videofähigen Endgerät 106a2 annehmen kann, so dass sie die Bilder austauschen kann. Einmal in ihrem Raum kann Mary auf ihr intelligentes Endgerät 106a2 zugreifen, um mit ihrer Freundin zu sprechen.
    Mary: „Hi, Kate! Well, you have a new boyfriend?"
    (Hey Kate! Gut, du hast einen neuen Freund?)
    Kate: "Hi, I have also some great pictures of him"
    (Hey, ich habe einige große Bilder von ihm.).
    (Schließlich kann Kate ein paar digitalisierte hochauflösende Bilder 112 und auch ein paar kurze Videoclips ihrer bevorzugten Rockband zu Mary senden).
  • Dieses Szenario betrifft den Fall eines Personal Area Network (PAN, (persönliches Netzwerk)) 604, bei dem eine Drittpartei-unterstützte Verhandlung 608 von Fähigkeiten und QoS auf einer End-zu-End-Basis ausgeführt werden muss. Dies bedeutet, dass Marys Uhr 106a1 fähig ist, im Interesse des neu entdeckten intelligenten Geräts 106a2 zu verhandeln (Stellvertretungsmechanismus (proxying mechanism)).
  • Alternativ dazu könnte der Verhandlungsprozess 806 durch Marys „Raum"-Gerät 106a2 mit Kates Endgerät 106b direkt ausgeführt werden: In diesem Fall würde der Verschiebungsmechanismus 108 den kompletten Verbindungsherstellungsprozess zum neuen Gerät 106a2 vollständig übergeben (Umleitungsmechanismus (redirect mechanism)).
  • Als ein Unterfall dieses Szenarios 100 ist es natürlich auch möglich, dass überhaupt keine Verschiebung 108 erforderlich ist, wobei der Verhandlungsprozess 806 von Marys Uhr 106a1 mit Kates Endgerät 106b direkt ausgeführt werden könnte. Ein solcher Unterfall korrespondiert mit der in [SDPOA00] beschriebenen, sehr einfachen Eins-zu-Eins-Kommunikation. Dieser Fall ist in 8 zusammen mit den Verhandlungsphasen des Signalisierungsprotokolls gezeigt.
  • Das in 2 gezeigte Beispiel zeigt ein virtuelles Vortragen bzw. Vorlesen in einer Situation eines Eins-zu-Viele-Kommunikationsszenarios 200, bei dem ein Vortragender bzw. Vorlesender 202 (Prof. T. Martin) und drei Studenten 204a–c (A, B und C) involviert sind. Dabei sei angenommen, dass Prof. T. Martin einer Konferenz in Rom beiwohnt, während er gleichzeitig seinen üblichen Vorlesungsplan an der Universität Berlin haben sollte. Er hat sich mit seinen Studenten A, B und C arrangiert, dass er die Vorlesung online (angeschlossen) geben wird, indem er Vorteil aus einem freien Schlitz im Konferenzplan zieht, und hat infolgedessen angekündigt, dass die Session 102 um 2:00 Uhr Nachmittags beginnt. Bis zu diesem Grad hat Prof. T. Martin seinen Hotelzimmercomputer konfiguriert, um mehrere verschiedene Sendeprofile, die mit Geräten seiner Studenten korrespondieren, zu unterstützen. Um 1:00 Uhr Nachmittags informiert ihn sein PDA, dass die ersten Studenten eine Verhandlung 806 (oder 809) zur Eröffnung einer Verbindungssession 102 mit seinem Computer in seinem Hotelzimmer begonnen haben. Prof. T. Martin geht zu seinem Zimmer, und um 1:45 Uhr Nachmittags macht er eine Den-Tisch-herum-Prüfung (around the table check) der Teilnehmer A, B und C, bevor er schließlich die Vorlesungssession 102 beginnt. Die Vorlesungsverbindung trägt die Identifikationsinformation, dass sie von akademischer Wichtigkeit ist und dass sie deshalb nicht berechnet wird oder die Gebühren auf einem Universitätskonto kontiert werden.
  • Dieses Beispiel beschreibt den Fall eines Eins-zu-Viele-Kommunikationsszenarios 200. Eine solche Art von Kommunikation ist auch mit dem Fall eines „Video-on-Demand"-Dienstes (VoD-Dienst) äquivalent, mit dem Hauptunterschied, dass bei dem oben beschriebenen Beispiel die Übertragung live und nicht wie beim VoD-Fall voraufgezeichnet ist. Deshalb kann bei dem vorliegenden Beispiel jeder Empfänger A, B und C zur (nominell) gleichen Zeit nur die gleiche Information empfangen.
  • Das in 3 gezeigte folgende Beispiel kann als eine einfache Form einer Videokonferenz 1204a/b in einem Viele-zu-Viele-Kommunikationsszenario 300, bei dem vier Benutzer 302a–d (Caroline, Martha, Miranda und eine Sekretärin) involviert sind, behandelt werden.
  • Es sei angenommen, dass Caroline und Martha Angestellte einer Modedesigngesellschaft in Los Angeles sind. Sie arbeiten an einem eine neue Kollektion betreffenden Verbundprojekt mit ihrer französischen Kollegin Miranda. Jede Woche halten die Damen 302a–c eine Videokonferenz 1204a/b über den laufenden Stand der Entwicklung der Kollektion ab. Caroline und Martha senden ihre Designs zu Miranda zur Prüfung und Zustimmung. Da Miranda eine ganze Menge reist und nicht genug Zeit zum Schreiben von netten Berichten für ihren Chef hat, hat sie ihre Sekretärin autorisiert, ihre Modellerevue zu arrangieren, um eine Präsentation für den Chef vorzubereiten. Wenn die Konferenz schließlich stattfindet, können Miranda, Caroline und Martha Audio- und Videoinhalt sowie Bilder und Textnachrichten auszutauschen beginnen. Indessen hört die Sekretärin 302d online zu und führt das Protokoll der Konferenz ebenso wie sie Mirandas Bemerkungen aufnimmt.
  • Dieses Szenario 300 ist auf den Fall von Information, die von verschiedenen Quellen stammt, gerichtet. Dies ist der Fall einer Gruppe von verknüpften bzw. verbundenen Informationsmedienströmen 206, bei denen die Benutzer möglicherweise eine Korrelation 804 zwischen ausgetauschten Medienströmen (beispielsweise beim Sekretär-Endpunkt) benötigen.
  • Das in 4 gezeigte folgende Beispiel gehört zu einem Viele-zu-Viele-Kommunikationsszenario 400, das ein komplexes Szenario einer Videokonferenz 1204a/b zeigt, bei dem die vier Benutzer 402a–d (Susanne Jones, zwei Prüfer und Mr. Jones) involviert sind.
  • Dabei sei angenommen, dass Susanne Jones ein der Öffentlichkeit zugängliches PhD-Vorexamen macht und sie ihren Vater eingeladen hat, passiv an ihrer Online-Prüfungssession 102 teilzunehmen, indem sie ihm einen Sessionverbindungsschlüssel zum Teilnehmen an der Prüfungssession 102 als Zuhörer 404d gibt. Sie macht eine Online-Präsentation, die an ihre Fachbeauftragten (Supervisors) 404b+c und an eine Gruppe von Zuhörern mehrfachgesendet (multicasted) wird. Die anfänglichen Arrangements der Session 102 werden zwischen Susannes Endgerät 404a und den Endgeräten der Fachbeauftragten 404b+c gemacht, da die Fachbeauftragten 404b+c Notizen über die Präsentation Online austauschen, damit sie Susanne für ihr wirkliches Examen leiten und ihr die positiven und negativen Seiten dieser Präsentation zeigen können. Die Bemerkungen werden direkt auf die Präsentationsseiten oder auf ein gemeinsames weißes Brett geschrieben. Die Notizen werden mit der laufenden Präsentation verbunden, und die anfänglichen Arrangements definieren diese Korrespondenz (Korrelation 804).
  • Sobald die anfänglichen Vereinbarungen getroffen sind, beginnt das Examen. Der Zuhörer 402d und andere Zuhörer können sich zu einem späteren Zeitpunkt anschließen, da sie das laufende Examen nicht als aktive Teilnehmer beeinträchtigen. Jeder sich an die Session 102 anschließende Zuhörer kann Information über die laufende Bewertung der Präsentation bekommen. Das Endgerät von Susannes Vater 404d schließt sich an die Signierung (signing) der Session 102 an, um die Präsentation selbst und die Bewertungen, die ihre PhD-Fachbeauftragten 402b+c geben, zu bekommen. Das Endgerät 404d trifft die korrespondierenden Vereinbarungen mit Susannes Endgerät 404a und dem Endgerät 404b+c der Fachbeauftragten 402b+c entsprechend voreingestellten Profilen, die mit den Wünschen von Susannes Vater korrespondieren, so dass er sich an die Präsentationsmehrfachsendung anschließt und die Bewertungen als Einfachsendungen bekommt.
  • Für einen richtigen Verlauf des Szenarios 400 ist es notwendig, eine Vorstellung darüber zu haben, wie die einzelnen Medienströme 206 zu gruppieren sind, und wer die interessierten Parteien für einen laufenden Medienstrom 206 sind. Bei solchen Szenarios ist es wichtig, Gruppen von Teilnehmern und Gruppen von Medienströmen 206 in einer Session 102 zu definieren. Es ist auch möglich, dass hierarchische Gruppierungsstrukturen zur Kommunikation gebildet werden.
  • Dieses Szenario 400 zeigt auch, dass manchmal nicht nur Realzeitverkehr, sondern auch Nichtrealzeitverkehr als Hochprioritätsverkehr verhandelt werden sollte:
    Beispielsweise muss der eine Liveübersetzung des Examens für einen fremden Teilnehmer tragende Medienstrom 206 von Untertiteln insofern als pseudorealzeitlich betrachtet werden, als er nicht von Nutzen wäre, wenn er mit dem Inhalt nicht Schritt hielte – oder überhaupt nicht zur Abgabe gekommen wäre. In diesem Fall ist der Nichtrealzeitverkehr (Untertitel) zu einem gegebenen Grad mit dem Realzeitverkehr (Livevideo) assoziiert.
  • Das Szenario 400 kann auch auf Netzwerk-604-Spiele und Online-Konferenzen mit mehreren Arbeitsgruppen angewendet werden. Die Komplexität eines solchen Szenarios 400 in Betracht ziehend, kann es notwendig sein oder nicht, gewisse Vorarrangements und -planungen der Mehrparteiverbindung zu treffen.
  • Das in 5 gezeigte Beispiel zeigt gewisse zusätzliche Aspekte der Mehrparteienkommunikation, die auch die Benutzung gewisser Dienste, welche die Entdeckung der Kommunikationsparteien und Dienste unterstützen und den Beginn der Verhandlung 806 (oder 809) in Betracht ziehen. Dabei sind zwei mobile Benutzer 508a+b (Dr. R. Harris und sein Assistent Herr. A. Frank) in dieses Szenario involviert.
  • Bei diesem Beispiel sei angenommen, dass Dr. Harris von Frankfurt nach Paris fährt und an einer Videokonferenz 1204a/b mit seinen französischen Kollegen die Ausführung einer Gehirnoperation eines Patienten in Paris betreffend teilzunehmen hat. Seine Kollegen senden ihm online laufende Überwachungsinformation des Patienten. Sie diskutieren auch über die Durchführung der Operation, um beginnen zu können, sobald Dr. Harris beim Krankenhaus in Paris ankommt. Wenn Dr. Harris in den Zug 502 einsteigt, schließt er sein Endgerät drahtlos an das Zug-LAN an. Der Zugserver ist nun darüber informiert, dass Dr. Harris im Zug-LAN präsent ist.
  • Herr Frank kommt in Straßburg in den Zug 502. Beim Einsteigen in den Zug 502 schließt er sein Endgerät ebenfalls drahtlos an das Zug-LAN an und entdeckt so, dass sein Chef schon in einem anderen Waggon des Zugs 502 ist. (Es sei angenommen, dass der Zug vollständig ausgebucht ist, und deshalb Herr Frank keine Chance hat, einen Sitz in der Nähe von Dr. Harris zu reservieren). Herr Frank setzt einen Anruf ab, um sich auch an die laufende Konferenz anzuschließen. Dabei bilden die Endgeräte von Dr. Harris und Herrn Frank ein „Ad-hoc"-Netzwerk 604 und benutzen das Endgerät von Dr. Harris als eine Verbindung zur „Außenwelt", wobei sie die Konferenzmedienströme 206 zum Endgerät von Herrn Frank neu übertragen.
  • Dieses Szenario 500 ist ein Beispiel einer virtuellen Präsenz durch Benutzung des Zugservers als einen Entdeckungsdienst. Es ist aber auch möglich, gewisse andere Zwischendienste wie Benennungs- und/oder Zuteilungsdienste usw. oder Geräte wie Proxies oder Registratoren zu haben. In diesem Fall unterstützen die Zwischenkomponenten nur den Aufbau der Verbindung zwischen den End-Peers ohne aktiv an den Verhandlungen 808 und 809, welche die End-Peers führen, aktiv teilzunehmen.
  • Im folgenden Abschnitt sollen die Ausgaben, die betreffen, wie die QoS bei sich mit mehreren Typen und Nummern von konkurrierenden Medienströmen 206 befassenden Multimedienanwendungen zu behandeln sind, diskutiert werden. Die Schlüsselaspekte der vorgeschlagenen Lösung gemäß der zugrundeliegenden Erfindung, die Vorverhandlung 802 der Anwendungsebene QoS und die Koordination des verteilten Ressourcenmanagements, bei dem das sogenannte „Ökonomieprinzip" angewendet wird, werden dann detailliert dargelegt. Die in diesem Abschnitt identifizierten Erfordernisse werden in einer Erfordernisliste, die auch Information über Abhängigkeiten zwischen identifizierten Erfordernissen enthält, gesammelt. Ein übergeordnetes Problem, dem mobile Benutzer im Kontext der IP-Netzwerke 604 der nächsten Generation und Anwendungen gegenüberstehen, ist, wie begrenzten Ressourcenmengen bei den Endsystemen und im Netzwerk 604 zu begegnen ist, und instabile Umgebungsbedingungen. Folglich kann das folgende Erfordernis postuliert werden:
    Figure 00470001
  • Multimediensessionen 102 können mehrere Medienströme 206 grundlegender Typen (beispielsweise Audio, Video und Daten) inkludieren. Beispielsweise könnte eine Session 102 für eine gegebene Perspektive eines Benutzers aus zwei Videomedienströmen 206 und vier Audiomedienströmen 206 bestehen, die von verschiedenen Peers (oder auch von einem Peer in einem Umgebungszenario) erzeugt werden. Der gegebene Benutzer würde dann wünschen, die QoS, die sie/er für jeden einzelnen Medienstrom 206 bekommen will, und außerdem jeden Parameter, der das Verhalten des Intermedienstroms 206 möglicherweise bestimmt, zu spezifizieren. Typischerweise befassen sich Videokonferenz-1204a/b-Anwendungen mit Sprach- und Videomedienströmen 206, die beim Endgerät synchronisiert werden müssen. Eine nicht synchronisierte Videokonferenz 1204a/bs kann bei manchen Szenarios nicht zufriedenstellend sein.
  • Außerdem kann zwischen gewissen oder allen zuvor erwähnten Medienströmen 206 eine gewisse Ebene einer Korrelation 804 auf einer Zeit- und/oder QoS-Basis erforderlich sein. Diese Korrelation 804 bildet eine Generalisierung des Problems der Zeitsynchronisation 805. Beispielsweise können Elektronikspielanwendungen und/oder medienreiche interaktive Anwendungen Bündel von Audio- und Videomedienströmen 206 darstellen, die mit dem Benutzer präsentierten Objekten assoziiert sind. Beispielsweise kann ein sich bewegender und/oder drehender Würfel auf einem Monitor mit seinen mit Bildern aus Videomedienströmen 206 strukturierten Flächen angezeigt werden, und können verschiedene Audiomedienströme 206, deren jeder mit einer Würfelfläche assoziiert ist, gespielt werden, immer wenn die korrespondierende Fläche in einer gewissen Richtung orientiert ist.
  • Bis zu diesem Grad sollen Anwendungen fähig sein, nicht nur zu garantieren, dass verbundene Medienströme 206 innerhalb gegebener zeitlicher Verhältnisse gespielt werden (Ausscherzeitsynchronisation (sheer time-synchronisation)), sondern auch, dass die kombinierte QoS eines gegebenen Bündels aus Medienströmen 206 innerhalb gewisser gegebener Beschränkungen liegt (QoS-Korrelation 804). Beispielsweise kann es gerade bei der Fortsetzung des Spielanwendungsbeispiels keinen Sinn machen, gewisse Facetten des angezeigten Würfels in schwarzen und weißen Videos und die anderen als Hochqualitäts-Farbvideos bei höheren Rahmenraten zu haben, selbst wenn die Bilder von einer ausscherzeitlichen (sheer temporal) Perspektive vollständig synchronisiert wären. Es würde eher mehr Sinne machen, alle schwarze und weiße Bewegtbilder (movies) anzeigenden Facetten mit der höchstmöglichen Rahmenrate anzuzeigen und dadurch den sinnlosen Verbrauch von Ressourcen zur Gewinnung von Farbbildern zum Nachteil der Rahmenrate, mit der die Bilder angezeigt würden, zu vermeiden.
  • Natürlich bleibt die Entscheidung, welche Ebene der Korrelation 804 auf QoS-Ebene unter einem Satz von Medienströmen 206 forciert werden sollte, der Diskretion der Entwickler und auch der Benutzer überlassen.
  • Deshalb können Multistromanwendungen zusätzlich zu der Spezifikation von Zeitsteuerungs- bzw. Timingbeziehungen zwischen Gruppen von Medienströmen 206 auch eine Spezifikation einer QoS-Korrelation 804 erfordern. Tatsächlich identifiziert diese Unterscheidung nicht vollständig zwei orthogonale Aspekte, da Zeitsynchronisation als ein spezieller Fall von QoS-Korrelation 804 angesehen werden kann. In dem Fall, dass ein gegebener Medienstrom 206 aus einer Anzahl unterschiedlicher Transportlayerflüsse (beispielsweise wie durch multilayered Codecs erzeugt) bestehen, sind diese Ausgaben sogar noch offensichtlicher.
  • Figure 00490001
  • Es sollte darauf hingewiesen werden, dass die Bündelung von Medienströmen 206 nicht nur anwendungs- oder benutzerabhängig ist, sondern dass sie auch entsprechend einem hierarchischen Schema strukturiert werden kann.
  • Beispielsweise kann es bei Videokonferenz-1204a/b-Anwendungen Sinn machen, verschiedene Gruppen von Medienströmen 206 zu unterscheiden (und deshalb unterschiedlich zu behandeln), um mehrere konkurrierende Fälle der Videokonferenz 1204a/b zu identifizieren, und bei jeder Videokonferenz-1204a/b-Session 102 die verschiedenen Assoziationen des gegebenen Benutzers mit mehreren Peers (jede Assoziation ist ein Bündel aus korrelierten Medienströmen 206) zu identifizieren.
  • Dieser Vorschlag modelliert somit Multistromzeitsynchronisations-805- und QoS-Korrelations-804-Beschränkungen als QoS-Verträge 1108 hoher Ebene, die mit der Liste der beeinflussten Medienströme 206 assoziiert sind. Außerdem erlaubt er eine rekursive Bündelung solcher QoS-Verträge 1108 hoher Ebene zwischen ihnen selbst, was folglich zu einem hierarchischen QoS-Spezifikationsschema, das heißt äquivalent zu einem Baum, führt. Jedes solche Blatt bzw. jeder solche Astknoten bzw. Knoten (leaf) stellt einen Medienstrom 206 dar und weist einen assoziierten QoS-Vertrag auf. Mit einem QoS-Vertrag 1108 hoher Ebene ist ein Vaterknoten assoziiert, der für seine Kinder QoS-Ebenen in Form von Multistrom-Zeitsynchronisation-805- und QoS-Korrelation-804-Beschränkungen spezifiziert.
  • Außerdem können Benutzer verschiedene Mengen von Ressourcen bezüglich verschiedener (Multimedien-) Anwendungen gewähren (grant) und priorisieren (prioritize). Dies ist, wie in [BRAIN] beschrieben, besonders wichtig für Handgeräte mit begrenzten Ressourcen wie Speicher, Batterieenergie. Diese Vorgehensweise führt zu Zeitsynchronisation-804- und QoS-Korrelation-804-Beschränkungen noch höherer Ebene, die vom Handgerät lokal zu forcieren sind. Die korrespondierenden QoS-Verträge 1108 höherer Ebene erweitern das Baumdatenmodell an der Wurzel. Solche zusätzlichen QoS-Verträge 1108 höherer Ebene sind jedoch nicht so gemeint, dass sie mit Peers verhandelt werden. Vielmehr kann jeder Peer QoS-Verträge 1108 hoher Ebene unabhängig forcieren. Alternativ dazu können QoS-Verträge 1108 durch einen gegebenen geschlossenen Satz (Menge) von Peers hindurch global forciert werden, wenn einmal ein Koordinator gewählt worden ist.
  • Figure 00500001
  • Ein möglicher Weg, um QoS-Verletzungen und QoS-Änderungen zu begegnen, ist, den Anwendungen eines mobilen Benutzers zu ermöglichen, auf diese Ereignissen durch Vorausplanen von Gegenmaßnahmen effizient und rechtzeitig zu reagieren.
  • Auf diese Weise können, immer wenn QoS-Verletzungen auftreten, zwischen den Peers Übereinkommen darüber, wie sich an die geänderten Bedingungen am effektivsten anzupassen ist, rechtzeitig erreicht werden.
  • Die diese zwei Planungsmechanismen kombinierende Gesamtlösung wird hierdurch als End-to-End Negotiation Protocol (End-zu-End-Verhandlungsprotokoll) 908 (E2ENP 908) bezeichnet.
  • Figure 00510001
  • Die hierarchische QoS-Spezifikation kann zum Helfen den Anwendungen zu entscheiden, wie sie während Überlastungssituationen reagieren sollen, damit sie den Wünschen eines Benutzers entgegenkommen, verbessert werden.
  • Die Ausscherverhandlung 806 einer einzelnen QoS-Ebene macht tatsächlich nur Sinn während der Laufzeit, da nur während der Laufzeit der Netzwerkprovider in eine Drittparteiunterstützte Verhandlung 806 (bei der die Akteure gemäß [ISOX641] ein Initiator, ein Provider und ein oder mehrere Responder (Erwiderer) sind) involviert werden kann. Um mit der in der IETF-Gemeinde (IETF community) benutzten derzeitigen Terminologie zu harmonieren, wird im Schutzbereich der zugrundeliegenden Erfindung die folgende Benennungskonvention benutzt: Anbieter (offerer) 914 anstelle von Initiator und Antworter (answerer) 911 anstelle von Responder. Dies ist notwendig, wenn Netzwerkressourcen zur Bereitstellung engerer QoS-Garantien explizit zu reservieren sind.
  • Jedoch ist die Notwendigkeit erkannt worden, die kritischsten Phasen mobiler Multimediendienste (die nicht nur Konversations- und Konferenzdienste, sondern auch Informationswiedergewinnung umfassen) aus einer QoS-Perspektive zu beschleunigen: das heißt Verbindungsherstellung und Übergaben. Dies deshalb, weil der zugrundeliegende Verkehr typischerweise verzögerungsempfindlich ist und die Benutzung von heterogenen und mobilen Netzwerken 604 eine begrenzte Bandbreite und Netzwerk-604-Kapazität sowie häufige Übergaben implizieren können. Die hierdurch vorgeschlagene Lösung ist, einen Satz (Menge) von QoS-Ebenen richtig vorauszuplanen, um gegenwärtigen und künftigen Ressourcenmengen zu begegnen.
  • Außerdem kann jeder Satz durch Assoziieren jedes Elements im Satz mit einem eindeutigen Identifizierer zu QoS-(Wieder-)Verhandlungszeiten schnell und eindeutig referenziert werden.
  • Überdies können spezielle Merkmale der Endanwendungen und Dienste verschiedene Verhandlung-806-Moden und verschiedene Ordnungen bzw. Reihenfolgen der ausgetauschten Mitteilungen erfordern.
  • Schließlich sei darauf hingewiesen, dass sich jede QoS-Information von der Kenntnis verfügbarer Ressourcen ableitet. Da jede gegebene, Benutzer-wahrnehmbare Qualität durch Benutzung verschiedener Ressourcen (beispielsweise Codecs) erreicht wird, ist es notwendig, Information über Ressourcen zu sammeln, um einen oder mehrere QoS-Verträge 1108 entsprechend erzeugen zu können. Außerdem wird Information über Ressourcen auch zum Durchführen von Ressourcenreservierungen benutzt.
  • Figure 00530001
  • Mobile Benutzer benötigen die Fähigkeit zur Änderung ihrer Mobilendgerätanbringungspunkte an das Netzwerk 604 unter Beibehaltung der alten Adresse des Netzwerks 604 ebenso wie unter Aufrechterhaltung jeder aktiven Telekommunikationssession 102, wobei drei mögliche Typen von Ereignissen auftreten können (übergeben (handover)).
  • Ist gegeben, dass Benutzer typischerweise Geschäftsbeziehungen mit einem speziellen Netzwerkprovider (beispielsweise ein Abonnement (subscription) mit einem ISP oder eine Guthabenkarte (prepaid-card) mit einem Telecombetreiber) hat, können drei mögliche Übergabetypen auftreten:
    • – Horizontale Übergabe (horizontal handover): Die Übergabe findet innerhalb eines gegebenen administrativen Bereichs (administrative domain) eines Netzwerkproviders und innerhalb des gleichen Typs von Zugriffsnetzwerk 604 statt.
    • – Vertikale Übergabe (vertical handover): Die Übergabe findet zwischen zwei verschiedenen Typen von Zugriffsnetzwerken 604 und/oder über die administrative Grenze zwischen zwei Netzwerkprovidern hinweg statt.
  • Wenn sie mit Übergaben zu tun haben, müssen Benutzer darauf vorbereitet sein, dass sie Änderungen in der Netzwerkressourcenverfügbarkeit gegenüberstehen, die nicht nur vom Typ des Zugriffsnetzwerks 604, auf das zugegriffen wird, abhängen, sondern auch vom Typ von Geschäftsbeziehungen, die Benutzer mit den verschiedenen Netzwerk-604-Betreibern, auf die zugegriffen wird, haben können. In manchen extremen Fällen kann es sein, dass Benutzer tatsächlich versuchen, auf das Netzwerk 604 zuzugreifen, das einem Netzwerk-604-Betreiber gehört, mit dem die Benutzer überhaupt keine Geschäftsbeziehung unterhalten, oder der einen Zugriff der Benutzer einschränken oder die Menge von Ressourcen, die an die Benutzer vergeben ist, beschränken kann. Preisfestsetzungsaspekte (pricing aspects) spielen auch eine Schlüsselrolle.
  • All dies bedeutet, dass, immer wenn Übergaben stattfinden, die Benutzer darauf vorbereitet sein müssen, dramatische QoS-Verletzungen zu erfahren, aber auch, immer wenn während solcher Übergaben die Benutzer auf Netzwerke 604 mit mehr Ressourcen und/oder weniger Einschränkungen zugreifen, vorteilhafter Weise jede potentielle Verbesserung wirksam einsetzen,.
  • Figure 00550001
  • Dem im vorhergehenden Absatz dargelegten Grundprinzip folgend könnten Peers managen, dass sie nicht nur bezüglich eines gegebenen QoS-Vertrags 1108 übereinkommen, sondern auch bezüglich alternativer Verträge, die vorteilhafter Weise immer benutzt werden können, wenn sich die Netzwerk-604- und/oder Endgerät-Ressourcenverfügbarkeit mit der Zeit ändert.
  • Auf eine solche Weise würde jeder Peer exakt wissen, welcher alternative QoS-Vertrag 1108 (und unter welchen Bedingungen) forciert werden soll, um einer kritischen QoS-Änderung oder jeder QoS-Verletzung in Bezug auf den gegenwärtig freigegebenen QoS-Vertrag 1108 zu begegnen.
  • Das Konzept des Adaptierungspfades beschreibt die Spezifikation alternativer QoS-Verträge 1108 zusätzlich zum nominellen einen zusammen mit einem Satz von Regeln, die angeben, welcher alternative QoS-Vertrag 1108 unter welchen Umständen forciert werden sollte. Die alternativen QoS-Verträge 1108 beschreiben typischerweise niedrige QoS-Ebenen im Vergleich zu der einen, die durch den nominellen QoS-Vertrag 1108 spezifiziert ist. Insbesondere identifizieren Adaptierungsgrundsätze wohldefinierte Adaptierung des nominellen QoS-Vertrags 1108 mit einem Satz (Menge) alternierender degradierter QoS-Spezifikationen (d.h. niedrigeren QoS-Ebenen) in Korrespondenz mit wohldefinierten Sätzen (Mengen) von QoS-Änderungen und/oder -Verletzungen, wie sie durch die in „QoS Aspect Lanquages and their Runtime Integration" (in: Lecture Notes in Computer Science, Vol. 1511, Springer-Verlag) von J. P. Loyall et al., im folgenden als [Loyal] bezeichnet, beschriebenen Gesamtmiddleware überwacht werden.
  • Im Schutzbereich der zugrundeliegenden Erfindung wird die in [BRAIN] angegebene Terminologie verwendet, bei der Adaptierungspfad (adaptation path, AP) anstelle von Degradationspfad (Degradation Path) benutzt wird, um hervorzuheben, dass eine Adaptierung tatsächlich auch zum Aktualisieren (upgrade) einer gegebenen Qualität, sollten zu einer späteren Zeit (beispielsweise im Fall einer Übergabe) mehr Ressourcen verfügbar werden, benutzt werden könnte.
  • Figure 00560001
  • Figure 00570001
  • Durch Anwenden des AP auf jeder Ebene der zuvor erwähnten hierarchischen QoS-Spezifikation kann der Adaptierungsprozess durch Inkludieren sowohl von Zeitsynchronisation- und QoS-Korrelation-804-Spezifikationen verbessert werden.
  • Bei diesem Modell ist jede alternative Zeitsynchronisation- und QoS-Korrelation-804-Spezifikation mit einem speziellen QoS-Vertrag 1108 assoziiert.
  • Die Benutzung alternativer QoS-Verträge 1108, die in einem hierarchischen Format strukturiert sind, so dass sie verschiedene Korrelation-804-Aspekte erfassen, erlaubt in der Tat Peers, a priori (zur Vorverhandlung-802-Zeit) auf einem gemeinsamen, strukturierten „QoS-Vokabular (QoS-vocabulary)" ohne das Erfordernis der Intervention des Netzwerkproviders während des Vorverhandlung-802-Prozesses übereinzukommen.
  • Bis zu diesem Grad können Peers, immer wenn sie beim Prozess der End-zu-End-Vorverhandlung 802 teilnehmen, vorteilhafter Weise mit Netzwerkprovidern zur Abonnementzeit vorverhandelte Profilinformation benutzen. Im Fall von Roaming könnte ein Netzwerkprovider über Services Level Agreemements (Dienstebene-Übereinkommen)) Vorschläge machen, dass die Profilinformation von Benutzern (ganz oder teilweise) noch gilt, wenn die Benutzer eine neue Netzwerkdomäne besuchen.
  • Die Forcierung von Beschränkungen der QoS-Korrelation 804 und/oder Zeitsynchronisation 805 impliziert die logische Gruppierung von Medienströmen 206 auf der Basis verschiedener Kriterien. Beispielsweise:
    • – Gruppieren aller Audiomedienströme zur Forcierung synchronisierter Übersetzung,
    • – Gruppieren aller Medienströme 206, die von einem gegebenen Benutzer auf einem Mehrbenutzerendgerät (multi-user terminal) geöffnet werden, um Quoten zu forcieren.
  • Eine Gruppe von Medienströmen 206 könnte eventuell gerade einen einzelnen Medienstrom 206 inkludieren: In einem solchen Fall würde der grundlegende Medienstrom-206-QoS-Vertrag 1108 einfach mit (beispielsweise anwendungsspezifischen) QoS-Beschränkungen höherer Ebene vergrößert.
  • Gruppen sind hauptsächlich zur Darstellung von Bündeln von Medienströmen 206, die QoS-unterrichtete Anwendungen beim Abhandeln von Qualität bezüglich Ressourcenverfügbarkeit als Ganzes behandeln können, unter einer Vielfalt äquivalenter Bündel in einem gegebenen Satz (Menge) von Umgebungsbedingungen nützlich.
  • Bis zu diesem Grad können Peers nicht nur auf dem AP jedes individuellen Medienstroms 206, sondern auch auf alternativen Zusammensetzungen des gegebenen ganzen Bündels zusammen mit speziellen Beschränkungen der QoS-Korrelation 804 und/oder Zeitsynchronisation 805 für jede der resultierenden Konfigurationen proaktiv übereinkommen. Folglich können sich die Anwendungen (und/oder Middleware) an gegebenen QoS-Änderungen und/oder -Verletzungen auf der Basis vordefinierter Regeln anpassen, die diktieren, welche Medienströme 206 adaptiert werden sollten (einschließlich von Aktionen wie Stoppen oder Neustarten eines Stroms) und welche neuen Beschränkungen der QoS-Korrelation 804 und/oder Zeitsynchronisation 805 in der neuen Situation forciert werden sollten.
  • Figure 00590001
  • Es ist auch vernünftig, einen NULL-Strom-QoS-Vertrag (NULL-stream QoS contract) 1108 zu definieren, um während des Adaptierungsprozesses die Möglichkeit zu berücksichtigen, dass in kritischen Situationen einige der Medienströme 206 einer Gruppe nicht länger unterstützt werden können. Auf diese Weise kann man die vollständige Wiederverhandlung 808 der QoS-Einstellungen der ganzen Gruppe von Medienströmen 206 verhindern und folglich die Medienströme 206 innerhalb der laufenden Gruppe, für welche die Grenzbedingungen noch gültig sind, verlassen.
  • Die Idee hinter dem NULL-Strom ist, End-Peers zu erlauben, implizit einen „PAUSE-STREAM"-Befehl (Stromunterbrechungsbefehl) aufgrund einer detektierten QoS-Verletzung/-Änderung auszulösen. Durch Sichern von Information über die verhandelten QoS-Ebenen bevor die Unterbrechung auftritt, könnte man eine solche Information zur korrekten und schnellen Wiederverhandlung von QoS zu einer späteren Zeit benutzen, sollte die QoS-Verletzungs-/Änderungs-Bedingung nicht mehr existieren. Beispielsweise sei angenommen, dass Mary auf ihrem mobilen Gerät 106a1 Videoclips anschaut und dass sie in ihrem Benutzerprofil angezeigt hat, dass sie es, sollte die Verbindungsqualität abnehmen, bevorzugen würde, das Videostreaming zu unterbrechen, um Ressourcen zum Hören des musikalischen Standes (score) zu sichern. Während einer Übergabe findet eine QoS-Verletzung statt, und das Gerät signalisiert konsequenter Weise dem VoD-Server, den Videostrom zu unterbrechen. Der VoD-Server unterbricht das Videostreaming und sichert vorverhandelte QoS-Information, um entsprechend der vorverhandelten QoS (die Zeitsynchronisationsausgaben in Bezug auf den Audiostrom enthält) den Strom wieder aufzunehmen, sobald die Übergabe vollendet ist. Marys Gerät 106a1 hat sich auch die Existenz des Videostroms zu merken, um nicht von neuem die QoS für ihn voll neu zu verhandeln, wenn es ihn wieder aufnimmt.
  • Die Definition von Grenzbedingungen ist anwendungsspezifisch und hängt vom Kontext der Session 102 ab. Generell sollte die Anwendung des NULL-Stroms in einer Gruppe nicht dem Kontext der Session 102 beeinflussen. Dies bedeutet, dass die noch laufenden Medienströme 206 einer Stromgruppe in einer Session 102 für die Endparteien bedeutungsvoll genug sein sollte, um die Stromgruppe aufrechtzuerhalten und sie nicht zu annullieren und sie von neuem wieder zu verhandeln. Infolgedessen ist die Anwendung des NULL-Stroms gerade ein Werkzeug zur Vermeidung von Vollwiederverhandlungen 808 und dient der bedeutungsvollen Adaptierung einer Stromgruppe.
  • Beispielsweise sei der Fall einer Gruppe von Medienströmen 206, die einen Audio- und einen Videomedienstrom 206 enthält, betrachtet. Der korrespondierende Gruppen-AP kann dann eine Option inkludieren, in welcher der Videomedienstrom 206 mit einem NULL-Strom-QoS-Vertrag 1108 assoziiert ist, um das Auftreten marginaler Bedingungen wie Abfallen der Bandbreite unter eine gegebene Schwelle zu berücksichtigen. In einem solchen Fall würde der Videomedienstrom 206 gestoppt, aber das Audio würde weiter mediengeströmt.
  • Figure 00610001
  • Die Assoziation ist ein besonderer Typ einer Medienstrom-206-Gruppierung, die alle Medienströme 206 zwischen dem gegebenen Benutzer und einem gegebenen Peer assoziiert. Dieser Typ von Gruppierung ist die intuitivste, und es wird erwartet, dass sie sehr oft benutzt wird.
  • Figure 00610002
  • Ein QoS-Kontext identifiziert eine Anordnung von QoS-Parametern, welche durch eine gegebene Gruppe von Medienströmen 206 hindurch forciert werden soll. Ein QoS-Kontext ist eine logische Entität (logical entity), die als eine Spezialisierung des QoS-Vertragskonzepts modelliert ist.
  • Dies bedeutet, dass, was auch immer die QoS-Spezifikation individueller Medienströme 206 sein mag, der QoS-Kontext einen Satz von QoS-Beschränkungen forciert, die auf alle zur gegebenen Gruppe gehörenden Medienströme 206 anzuwenden ist.
  • QoS-Kontexte können auch die Parameter, die von den zu den mit den mit den gegebenen Kontexten assozierten Gruppen gehörenden QoS-Verträgen 1108 der individuellen Medienströme 206 abgeleitet sind, erfassen [ISOX641].
  • Beispiele sind die totale Speichergröße oder die mittlere Bandbreite, die vom gegebenen Satz von Medienströmen 206 benutzt wird.
  • Zusammenfassend behandeln QoS-Kontexte Medienstrom-206-Gruppierungs-, QoS-Korrelation-804- und Zeitsynchronisation-Ausgaben, wobei sie genauer auf die Spezifikation von
    • • gemeinsame QoS-Ebene für eine Gruppe von Medienströmen 206,
    • • abgeleitete QoS-Parameter,
    • • QoS-Parameter, die indirekt QoS-Spezifikationen gebündelter Medienströme 206 beeinflussen
    fokussieren.
  • Natürlich kann die Entscheidung darüber, welche Ebene der QoS-Korrelation 804 und/oder Zeitsynchronisation 805 unter einer Gruppe von Medienströmen 206 forciert werden sollte, nicht nur vom Entwickler, sondern auch vom Benutzer getroffen werden.
  • Figure 00620001
  • Gemäß dem vorstehend erwähnten hierarchischen Modell können baumbasierte Hierarchien von QoS-Kontexten definiert werden. Die Knoten (leaves) jeder solchen Datenbaumstruktur würde dann durch QoS-Verträge 1108, die mit den zu einer gegebenen Gruppe von Medienströmen 206 gehörenden individuellen Medienströmen 206 assoziiert sind, dargestellt.
  • Jeder interne Knoten jeder solchen Datenbaumstruktur würde anstelle dessen durch einen QoS-Kontext dargestellt sein, der dann indirekt die QoS-Spezifikation aller Medienströme 206 beeinflusst, deren Qos-Verträge 1108 in dem beim gegebenen internen Knoten wurzelnden Teil- bzw. Sub-Baum inkludiert sind. Dies bedeutet, dass QoS-Kontexte auf diese Weise spezielle QoS-Parameter, die alle zugrundeliegenden Medienströme 206 (beispielsweise Systemebenenzuverlässigkeitsausgaben) indirekt beeinflussen, adressieren können.
  • Überdies können auf einer höheren Ebene in jeder solchen Datenbaumstruktur QoS-Kontexte aus anderen auf niedrigerer Ebene rekursiv definiert werden.
  • Auf diese Weise kann jede solche Datenbaumstruktur zum Vereinigen nicht nur individueller Medienströme 206, sondern auch einer Vielfalt von schon definierten Gruppen von Medienströmen 206 auf der Basis von QoS-Korrelation-804- und Zeitsynchronisation-Kriterien benutzt werden.
  • Figure 00630001
  • Jedem QoS-Kontext kann eine Priorität zugeordnet sein, die QoS-unterrichtete Anwendungen zum Bestimmen der relativen Bedeutsamkeit von Geschwister-QoS-Kontexten benutzen können.
  • Figure 00640001
  • Durch wirksames Einsetzen des Konzepts aus QoS-Kontext und hierarchischer QoS-Spezifikation können Peers das vorstehend erwähnte Konzept des Group AP (GAP (Gruppenadaptierungspfad) forcieren.
  • Natürlich ist das Forcieren von QoS-Korrelation-804- und Zeitsynchronisation-Beschränkungen nur möglich, wenn die in den Prozess der Verhandlung 806 involvierten Peers bezüglich eines gegebenen Geschäfts (welche Anwendung zu benutzen ist, wer zu kontaktieren ist, welche andere Sessionen 102 zu eröffnen sind usw.) a priori übereinkommen.
  • Praktisch forcieren in den meisten Fällen Benutzer diese Beschränkungen lokal und offenbaren diese Information nicht ihren Peers. Der einzige Fall, bei dem diese Beschränkungen durch einen gegebenen Satz von Peers hindurch forciert werden können, ist nur, wenn Drittparteikontrolleinheiten (third-party control units) wie beispielsweise eine Conference Control Unit (Konferenzkontrolleinheit) bereitgestellt sind (typischerweise im Fall von Online-Konferenzszenarios).
  • Figure 00640002
  • Figure 00650001
  • Der Wiederverhandlungsprozess 808 involviert typischerweise einen Anbieter 914 und einen oder mehrere Antworter 106a2 und kann auf einmal oder auf einer iterativen Basis ausgeführt werden [Loyal].
  • Der Anbieter offeriert ein Angebot (bid) den Antwortern 106a2, die es prüfen und dem Anbieter 914 ein Gegenangebot zurückgeben. Der Letztere sammelt die Gegenangebote und bestimmt dasjenige (wenn es eines gibt), das die Erfordernissen aller involvierten Parteien erfüllt. Wenn einmal ein solches optimales Gegenangebot aussortiert worden ist, sendet es der Anbieter 914 jedem Antworter 911 als ein neues Angebot.
  • In einem iterativem Schema könnte der Prozess an diesem Punkt neu starten, sollte einer der Antworter 911 das neue Angebot noch nicht akzeptieren. Die iterative Lösung muss jedoch mit einer oberen Iterationsgrenze beschränkt sein, und sie ist in jedem Fall sehr komplex und nicht effizient.
  • Die Neu bzw. Wiederverhandlung 808 bei den Mehrparteienverbindungsszenarios sollte durch die Möglichkeit einer einzelnen Basis wie bei der Eins-zu-Eins-Wiederverhandlung 808 durchgeführt werden, da das Auftreten von Änderungen durch eine einzelne Kommunikationspartei die Verbindungen der anderen involvierten Parteien nicht beeinflussen kann, das heißt, wenn ein Peer bei seiner Verbindung Probleme entdeckt, bedeutet dies nicht, dass andere Peers auch Probleme mit ihren Verbindungen haben. Deshalb ist es bei Mehrparteienverbindungen besser, die unabhängigen Medienströme 206 auf einer einzelnen Basis wiederzuverhandeln, um die notwendige Signalisierung zu minimieren. Die Medienströme 206 einer Gruppe (abhängige Medienströme 206) können in dem Fall, dass diese Verhandlung 808 die Kontexte der Gruppe nicht beeinflusst, auch auf einer einzelnen Basis wiederverhandelt werden.
  • Figure 00660001
  • Figure 00670001
  • Das hierdurch vorgeschlagene Grundprinzip der Verhandlung 806 ist, den Empfängern zu ermöglichen zu Spezifizieren, welche QoS-Ebene sie empfangen wollen. Der Unterschied zwischen diesem Vorschlag und gegenwärtigen Trends (beispielsweise SDP/SDPng 912) besteht darin, dass die letzteren nicht primär auf die QoS-Verhandlung 806 fokussieren, sondern eher auf die Fähigkeitverhandlung 806. Beispielsweise ermöglichen sowohl das SDP als auch SDPng 912 einem Sender, dem oder den Empfängern Information über Format und Transportinformation, die der Sender zum Senden zu benutzen beabsichtigt, zu geben. Indem versucht wird, das E2ENP 908 an diese wohlbekannte Lösung anzupassen, kann das vorstehend erwähnte Grundprinzip wie folgt gelockert werden: sowohl Sender als auch Empfänger können spezifizieren, welche QoS-Ebene auf Medienstrom-206-Ebene sie senden/empfangen wollen, aber nur Empfänger dürfen spezifizieren, welche APs/Hochniveau-QoS-Ebene sie zum Empfang forcieren wollen. Dies deshalb, weil es wahrscheinlicher ist, dass sich die Empfänger um QoS- Korrelation-804- und Zeitsynchronisation-805-Beschränkungen unter mehreren empfangenen Medienströmen 206 kümmern, während dies für Sender nicht generell von Relevanz ist.
  • Figure 00680001
  • Jedoch wird die Erweiterung dieses Vorschlags, Sendern das Spezifizieren von QoS-Korrelation-804- und Zeitsynchronisation-805- Beschränkungen zwischen den Medienströmen, die sie senden, weiterem Studium überlassen.
  • Peers können einer speziellen Prozedur zum effektiven Forcieren der verhandelten QoS-Spezifikation nicht nur bei der Verbindungsherstellungszeit, sondern auch immer wenn QoS-Verletzungen stattfinden folgen.
  • Bis zu diesem Grad schlägt [BRAIN] vor, die tatsächliche Reservierung von lokalen Ressourcen sowie von Netzwerkressourcen zu koordinieren, um ein Warten auf Netzwerkressourcenreservierung bis die Ressourcen an allen Endpunkten reserviert sind zu vermeiden. Genauer gesagt wird im vorliegenden Dokument der Begriff Ökonomieprinzip dazu. benutzt, die in „The QoS-Broker „ (IEEE Multimedia Magazine, Spring 1995 (2)1, Seiten 53–67) von K. Nahrstedt und J. M. Smith, im Folgenden als [Nahr95] bezeichnet, beschriebene Reservierungsreihenfolge zu beschreiben.
  • Deshalb wird eine Integration der vorstehend erwähnten Prozesse der QoS-Vorverhandlung 802, QoS-Verhandlung 806 und QoS-Wiederverhandlung 808 vorgeschlagen, mit dem Ökonomieprinzip zum Reservieren der teuersten Ressourcen beim letzten Schritt. Da Netzwerkressourcen unter mehreren Clients aufgeteilt werden und man typischerweise für sie bezahlen muss, ist es besser, zuerst Ressourcen auf allen Endsystemen und dann Netzwerkressourcen als der letzte Schritt zu reservieren.
  • Die Folge von Aktionen schaut dann wie das Folgende aus:
    • 1. Zuerst werden lokale Ressourcen reserviert.
    • 2. Dann führt eine Verhandlung 806 mit der Peer-Entität zu einer Konfiguration, die auf Ressourcenerfordernisse beim Peer abgebildet werden können, die dann reserviert werden.
    • 3. Schließlich wird beim letzten Schritt eine Reservierung von Netzwerkressourcen ausgeführt, da Netzwerkressourcen teuer sind und unter mehreren Benutzern gemeinsam benutzt werden.
      Figure 00690001
  • Um lokale, Peer- und Netzwerkressourcenreservierung gemäß dem vorstehend erwähnten „Ökonomieprinzip" zwischen mehr als zwei Peers richtig zu koordinieren, muss während des Spezifizierens des korrespondierenden Protokolls speziell Acht gegeben werden, damit Konsistenz (die auch zu einer besseren Ressourcenbenutzung führt) bereitgestellt und Blockierungen (deadlocks) vermieden werden. Konsistenz führt auch zu einer besseren Ressourcenbenutzung.
  • Der Rest dieses Abschnitts präsentiert zwei Beispielszenarios, die diese Erfordernisse motivieren. Es wird zuerst eine Beschreibung der auf die Beispielszenarios angewendeten generellen Voraussetzungen gegeben. Diese Voraussetzungen illustrieren den Problembereich, jedoch beschränken sie nicht die Anwendbarkeit des Szenarios.
  • Im Folgenden sollen drei äquivalente Endgeräte angenommen werden, deren jedes mit dem gleichen Videocodec ausgerüstet ist. Die Verarbeitungsleistung der Endgeräte ist derart, dass jedes von ihnen 25 Rahmen pro Sekunde für entweder Senden oder Empfangen bewältigen kann.
  • Das heißt, die CPU-Leistung ermöglicht es, entweder 25 Fr/s (Fr = Frame (Rahmen)) im Übertragungsmodus (Erfassen, Komprimieren, Paketieren und Senden) oder im Empfangsmodus (Empfangen der Pakete, Vereinigen, Dekomprimieren und Aufbereiten) zu verarbeiten. Jedoch weist das Endgerät nicht genug Ressourcen zum gleichzeitigen Senden und Empfangen von 25 Fr/s auf. Überdies sei angenommen, dass der Ressourcenverbrauch mit der Zahl der Rahmen pro Sekunde skaliert. Beispielsweise kann das Endgerät gleichzeitig einen Medienstrom 206 mit 10 Fr/s senden und einen anderen Medienstrom 206 mit 15 Fr/s empfangen, um insgesamt 25 Fr/s zu verarbeiten.
  • Das in 6 gezeigte Dialog- bzw. Interaktionsdiagramm für ein Verhandlung-806-Sezenario mit drei Peers 602a–c (A, B und C) zeigt, warum es notwendig ist, Konsistenz bereitzustellen. Dabei sei angenommen, dass zur Zeit t0 der Peer A eine Verhandlung 806 mit dem Peer B zum Veranlassen des Peer A zum Senden eines Medienstroms 206 zum Peer B mit der Rahmenrate von 15 Fr/s initiiert.
  • Peer A reserviert erfolgreich lokale Ressourcen zur Verarbeitung von 15 Fr/s, sendet die Verhandlung-806-Aufforderung zum Peer B, der schon eine fortlaufende Session 102 hat, die 20 Fr/s mit einem anderen Peer verbraucht. Infolgedessen reserviert Peer B Ressourcen für 5 Fr/s zur Verarbeitung des hereinkommenden Medienstroms 206, da das alles ist, was er unterstützen kann. Diese Information wird zurück zum Peer A übertragen, der vorher reservierte Ressourcen zur Unterstützung des verhandelten Rahmenratenwerts von 5 Fr/s freigibt und dann eine Reservierung von Netzwerkressourcen, die zum Zeitpunkt t1 mit 5 Fr/s beginnt.
  • Es sei angenommen, dass das Netzwerk 604 nicht der beschränkende Faktor ist und schließlich Peer A, Peer B und das Netzwerk 604 mit 5 Fr/s für die gegebene Session 102 unterstützen können. Wenn angenommen wird, dass bei irgendeinem Punkt zwischen t0 und t1 der Peer C eine Session 102 mit Peer A erzeugen will, würde Peer A nur fähig sein, dem Peer C zu erlauben, lokal 10 Fr/s (= 25 Fr/s–15 Fr/s) aufzunehmen.
  • Wenn jedoch Peer A die Aufforderung von Peer C bei irgendeinem Punkt in der Zeit nach t1 empfängt, würde Peer A fähig sein, wenigsten 20 Fr/s (= 25 Fr/s–5 Fr/s) für die neue Session 102 mit Peer C aufzunehmen, da die Ressourcenerfordernisse für die erste Session 102 aufgrund von dem Peer B auferlegten Beschränkungen, die außerhalb der Kontrolle des Peer C sind, gefallen sind.
  • Aus diesem Szenario kann das Erfordernis abgeleitet werden, dass jedes solche Protokoll, das lokale, ferne und Netzwerkressourcen zwischen zwei Peers managt, nicht Anfragen bzw. Aufforderungen für Ressourcenerfordernisse von einem anderen Peer dienen sollen, bis das Protokoll bei der Herstellung einer fortlaufenden Telekommunikationssession 102 erfolgreich war. Dieses Erfordernis soll Konsistenz genannt werden.
  • Figure 00720001
  • Das in 7 gezeigte Dialog- bzw. Interaktionsdiagramm für ein Verhandlung-806-Szenario mit zwei Peers 602a+b (A und B) zeigt, warum es notwendig ist, Blockierungen (deadlocks) zu vermeiden, das heißt, warum das E2ENP 908 sicherstellen muss, dass es keine Halte- und Warte-Bedingung gibt, oder dass eine solche Bedingung nur für eine begrenzte Zeitgröße präsent sein kann. Es sei angenommen, dass Peer A einen Videostrom 206 mit 25 Fr/s zum Peer B senden will und umgekehrt.
  • Zur Zeit t0 reserviert Peer A die lokalen Ressourcen und sendet die Aufforderung zur Verhandlung 806 zum Peer B, der diese Aufforderung zur Zeit t2 empfängt. Indessen reserviert Peer B die Ressourcen zur Zeit t1 zum Senden eines Medienstroms 206 zum Peer A. Peer A empfängt diese Aufforderung zur Zeit t3.
  • Deshalb wartet Peer A auf die Antwort von Peer B, wobei er bei der Zeit t0 beginnt, während Peer B auf die Antwort von Peer A wartet, wobei er bei der Zeit t1 beginnt. Wenn beide Peers versuchen, ihre lokalen Ressourcen zur Zeit t2 (Peer B) und Zeit t3 (Peer A) zum Bedienen der fernen Aufforderungen reservieren, gehen sie als Folge beide fehl.
  • Aus diesem Szenario kann das Erfordernis abgeleitet werden, dass jedes Protokoll, das lokale, ferne und Netzwerkressourcen zwischen zwei Peers managt, Blockier(deadlock)-Situationen vermeiden soll oder ihnen wenigstens erlauben soll, nur für eine begrenzte Zeitgröße, nach der das Protokoll in jedem Fall zur Wiederherstellung fähig sein soll, aufzutreten.
  • Figure 00730001
  • Die End-Peers sind generell über ein oder mehrere miteinander verbundene Netzwerke 604, die auch Zwischenkomponenten enthalten, verbunden.
  • Figure 00730002
  • Zwischenkomponenten bieten Dienste an, die nicht nur die Information, die Peers über das E2ENP 908 zu späterer Zeit verhandeln, sondern auch die Resultate des E2ENP-908 Prozesses forcieren können.
  • Zwischenkomponenten sollten über die von den End-Peers getroffene Entscheidung informiert werden. Die Art und Weise der Informierung der Zwischenkomponenten kann dadurch geschehen, dass sie vor dem Start des E2ENP 908 mit einer gewissen Standardprofilinformation unterstützt werden und/oder dass die abgemachten QoS-Verträge 1108 bei einem gewissen Registrierungsdienst publiziert werden.
  • Figure 00730003
  • Figure 00740001
  • Generell könnten die Flüsse, welche die E2ENP-908-Mitteilungsübermittlung (den Signalisierungspfad) ausführen, und die Flüsse, welche die tatsächlichen Medienströme 206 (den Datenpfad) ausführen, nicht nur von netzwerkbezogenen Ausgaben abhängig, sondern auch aus Anwendungs/Dienst-spezifischen Gründen unterschiedlich geroutet (wegegeleitet) werden.
  • Figure 00740002
  • Jedesmal wenn ein Signalisierungspfad und/oder Datenpfad gebildet wird, kann es gewisse, entlang dem Pfad befindliche Zwischenkomponenten (Router, Proxies usw.) geben, deren Benutzung anwendungsspezifisch ist und welche die von den End-Peers benutzten Protokolle teilweise „verstehen" können. Diese Entitäten wären in einer Position, in der sie auch mit dem E2ENP 908 „interferieren" (beispielsweise kann das SIP 910 dies ermöglichen), und würden so die reine „End-zu-End"-Natur des E2ENP 908 zerbrechen.
  • Zur Vermeidung dieser Gefahr zwingt das folgende Erfordernis Zwischenkomponenten dazu, in Bezug auf das E2ENP 908 immer passiv zu sein:
    Figure 00750001
  • Beispielsweise kann dies durch Setzen eines expliziten Kommentars in E2ENP-908-Mitteilungen, der anzeigt, dass Zwischenkomponenten niemals einen E2ENP-908-Inhalt während des E2ENP-908-Prozesses ändern sollen oder durch Vorveröffentlichen einer gewissen der E2ENP-bezogenen Information in einem Registrierungsdienst, den Zwischenkomponenten dann zur Planung von Aktionen befragen können, erreicht werden.
  • Wenn benutzerdefinierte Audioqualität bei einem Codec gemäß den in „RTP Profile for Audio and Video Conferences with Minimal Control" (Columbia University, work in progress, <draft-ietf-avt-profile-new-09.txt>) von H. Schulzrinne et al., im Folgenden als [RTP-Profile] bezeichnet, beschriebenen Standard-Payloadtypdefinitionen (standard payload type definitions (payload = Nutzinformation) der Codecs angewendet werden soll, kann eine einzelne spezielle Qualität auf gerade einen einzelnen Paylosdtyp abgebildet werden, der diese Qualität ausdrückt.
  • Es gibt eine eindeutige Eins-zu-Eins-Abbildung zwischen einer Audioqualität und einer Fähigkeit (Payloadtyp).
  • Andererseits kann ein einzelner Videocodec mehrere Qualitäten erzeugen. Die Qualität eines komprimierten Videos bedeutet die zum Codierer (Codec) gehende Qualität. Sie repräsentiert die visuelle Gesamtqualität der einzelnen Rahmen. Dies bedeutet, dass es durch Anwenden einer gewissen benutzerdefinierten Qualität auf ein Video möglich ist, diese Qualität als einen Kompressionsprozentsatz für die Performance des Videocodec zu definieren. Außerdem ist es bei gewissen Codecs (beispielsweise WaveVideo, format name, „WAVI"), wie sie in „WaveVideo – An Integrated Approach to Adaptive Wireless Video" (in: ACM Monet, Special Issue on Adaptive Mobile Networking and Computing, 1998) von G. Fankhauser, M. Dasen, N. Weiler, B. Plattner und B. Stiller, im Folgenden als [WAVI] bezeichnet, beschrieben sind, möglich, die visuelle Gesamtqualität der Chrominanzebenen der einzelnen Rahmen zu spezifizieren und so zwischen der Luminanzgesamtqualität und der Farbqualität zu trennen. Die Farbqualität kann auch als Prozentsatz ausgedrückt werden. Die verschiedenen Videocodecs weisen eine unterschiedliche Zahl von Kompressionspegeln auf. Wenn ein Benutzer visuell wahrnehmbare Qualität spezifiziert, sollte diese Qualität eindeutig auf eine Zahl abgebildet werden, die den Kompressionspegel des Videocodecs ausdrückt. Wenn der Benutzer seine wahrnehmbare Qualität als eine Zahl oder einen Bereich von Zahlen spezifiziert, sollte diese Einstellung genug Auflösung haben, um eindeutig auf einen gewissen Kompressionspegel eines Codec abzubilden. Infolgedessen können zwei Erfordernisen betreffend die Videoqualitätseinstellung definiert werden.
  • Figure 00760001
  • Figure 00770001
  • Peers sollten einen Ressourcenmanagementgrundsatz vorverhandeln, um immer wenn QoS-Wiederverhandlungen 808 behandelt werden, Instabilitäten bei Laufzeit zu vermeiden.
  • Sollten andernfalls zwei oder mehr Peers, die beispielsweise an einer Videokonferenz 1204a/b angeschlossen sind, eine Ressourcenbenutzung, die einen gewissen Eigentümer-Ressourcenmanagementgrundsatz verletzen, detektieren, könnten die Entscheidungen, die jeder Peer unabhängig treffen würde, die verbleibenden in einer Weise beeinflussen, die den Entscheidungen, die diese anderen Peers gleichzeitig zu treffen versuchen, wiedersprechen. Dies würde zu „Oszillationen (oscillations)" im Ressourcenkonfigurationsraum führen, die auf die Gesamtsystemperformance (overall system performance) und Benutzer-wahrgenommene QoS treffen würde.
  • Aus dem gleichen Grund sollte nur der Sender die Entscheidung zum Auslösen des Wiederverhandlung-808-Prozesses treffen. Sollte jedoch ein Empfänger gleichzeitig eine Verschlechterung einer Ressourcenverfügbarkeit detektieren, könnte er eine Wiederverhandlung 808 auslösen und jede eventuelle Kollision mit anderen Peers (einschließlich des Senders) würde durch Gewähren des Rechts zum Fortführen dieses Prozesses nur dem Sender aufgelöst.
  • Bis zu diesem Grad wird die Definition eines Satzes (Menge) wohldefinierter Ressourcenmanagementgrundsätze vorgeschlagen, über welche die Peers durch eine Verhandlung 806 übereinkommen können. Auf diese Weise können die Peers noch unabhängig ihre eigenen Ressourcen bei der Laufzeit managen, aber in einer koordinierten Weise.
  • Solche Grundsätze (policies) sollten jede logische Kombination wenigstens der folgenden Aspekte abdecken:
    • – Optimierung von Speicherressourcen,
    • – Optimierung von Verarbeitungsenergie bzw. -leistung (processing power),
    • – Optimierung von Netzwerkressourcenperformance (network resource performance) und
    • – Optimierung von Energie- bzw. Leistungsverbrauch (power consumption).
  • Insbesondere die Optimierung von Energie- bzw. Leistungsverbrauch ist mit allen anderen Typen von Ressourcenmanagement korreliert: Beispielsweise zieht Speicherumlagerung (memory swap) Energie bzw. Leistung ab.
  • Sollte ein Grundsatz die Optimierung von Energie- bzw. Leistungsverbrauch nicht explizit spezifizieren, würde infolgedessen der Grundsatz die Benutzung anderer Typen von Ressource optimieren, ohne viel auf die Energie bzw. Leistung zu achten (dies kann beispielsweise bei einem permanent an die Stromnetze angeschlossenen Tischcomputer (desktop PC), der viel Energie bzw. Leistung zum Optimieren jedes Typs von Ressourcen mit Ausnahme der Energie bzw. Leistung hätte, Sinn machen).
  • Sollte ein Grundsatz die Optimierung von Energieverbrauch explizit spezifizieren, würde dieses Grundsatzkriterium alle anderen Optimierungskriterien beeinflussen.
  • Die Benutzung von Grundsätzen erlaubt Anwendungen und/oder Middleware, ihre eigenen Adaptierungsentscheidungen flexibel zu treffen, solange die durch die verhandelten QoS-Verträge 1108 auferlegten Bedingungen und Ressourcenmanagementgrundsätze erfüllt sind. Deshalb sind die Definition und Verhandlung 806 von Prioritäten für QoS-Verträge 1108 nicht erforderlich. Außerdem sind auch die Definition und Verhandlung 806 von Prioritäten für Codecs/Fähigkeiten nicht erforderlich. Der Grund für eine solche Priorisierung (prioritisation) wäre in der Tat wegen der Tatsache, dass Fähigkeiten wie Codecs Ressourcen unterschiedlich voneinander verbrauchen. Nebenbei bemerkt können Codecs, die typischerweise weniger gut als andere ausführen, noch bequemer eine Ressourcenbenutzung optimieren, wenn sie in spezifischen Konfigurationen benutzt werden.
  • Figure 00790001
  • Die dynamische Kommunikationsumgebung erfordert nicht nur Adaptabilität durch die Herstellung und das Management der Datenverbindungen, sondern auch durch Durchführen von Verhandlungen 808 und 809. 1 zeigt einen speziellen Fall für eine Verhandlung 808 und 809 eines Eins-zu-Eins-Kommunikationsszenarios 100, wobei die Peer-zu-Peer- Datenverbindung „Drittpartei-unterstützt" verhandelt wird. Eine solche Art von Verhandlung 806 kann Vorteil aus der Benutzung von Registrierungs-, Zuteilungs-, Präsenzdiensten usw, ziehen und so die durchgreifendere Erfüllung der Erfordernisse für QoS eines Benutzers und die Möglichkeit, mehrere Geräte in der Umgebung eines Benutzers zu entdecken und benutzen, erlaubt.
  • Durch Starten einer Verhandlung 806 können die angerufenen Geräte möglicherweise entdecken, dass es nicht möglich ist, den Anruf zu behandeln. Da das Gerät nicht adaptieren kann, kann der Anruf einfach nicht geschehen. Eine Art von Adaptierung, die in diesem Fall ohne Änderung der Fähigkeiten des Peers angewendet werden kann, wäre, den Anruf entsprechend einer Profildefinition des Benutzers an einen anderen Peer zu delegieren. Eine solche Funktionalität wird hier Mediator bzw. Vermittler 106a1 genannt und beschreibt die Fähigkeit eines Peers, im Interesse von einem gewissen anderen Peer und entsprechend einer voreingestellten Benutzerprofildefinition zu verhandeln. Dieser Typ von Verhandlung 809 wird als „Drittpartei-unterstützte Verhandlung" bezeichnet. Der Mediator bzw. Vermittler 106a1 nimmt aktiv an der Verhandlung 809 zwischen zwei Peers teil, nimmt aber nicht an der Datenverbindung teil. Sollte der Mediator 106a1 aktiv an der Datenverbindung teilnehmen, wäre es zusätzlich notwendig, Funktionalität, die in manchen Fällen in einer notwendigen Umcodierung (transcoding) resultieren kann, zu überbrücken und so in eine Mehrparteienverbindung laufen zu lassen und deren Verhandlung 809 anzufordern. Ein zusätzliches Problem eines sich auf dem Datenpfad befindlichen Mediators 106a1 kann sein, dass das Gerät einen Engpass verursacht und so die Möglichkeit zur Unterstützung der erforderlichen QoS negativ beeinflusst. Hinsichtlich dieser Probleme kann eine solche Art von Adaptabilität nur vorgeformt werden, wenn alle Peers (inklusive Mediator 106a1) Information über ihre Fähigkeitprofile (beispielsweise Gerätbitratendurchsatz) austauschen, was bedeutet, dass eine Mehrparteienverbindung verhandelt werden sollte, die später diskutiert wird. Infolgedessen wird für den Fall der Verhandlung 809 eine Mediation (Vermittlung) in der Weise in Betracht gezogen, dass der Mediator 106a1 nicht am Datenmedienstreaming teilnimmt.
  • Die erleichternde Funktionalität eines Mediators 106a1 wird ausgelöst, wenn ein Anbieter 106b einen Anruf abgibt, den das Gerät nicht behandeln kann. In diesem Fall sucht der Mediator 106a1 nach einem geeigneten Antworter 106a2 und delegiert den Anruf, indem er auch den Benutzer informiert und um Annahme des Delegationszustandes bittet. Folglich empfangen der Anbieter 106b und der Antworter 106a2 über den Mediator 106a1 Profilinformation über jeden anderen, wodurch die Entdeckung und der Prozess der Direktverhandlung 806 zwischen dem Anbieter 106b und dem Antworter 106a2 zu späterer Zeit beschleunigt wird.
  • Die Mediator-106a1-Funktionalität muss zusätzliche Dienste, die seine erleichternde Fähigkeit unterstützen, benutzen können. Die spezielle Anwendung solcher Dienste liegt außerhalb des Bereichs dieses Dokuments, hier wird nur der Vorteil ihrer Benutzung, und wie das E2ENP 908 davon beeinflusst wird, zur Kenntnis genommen.
  • Der Mediator 106a1 sollte darauf achten, dass er sich nicht auf Sessioninformation 112 bezieht, die der einen (Anbieter 106b) oder anderen (zukünftiger Antworter 106a2) Partei, für welche die Vermittlung durchgeführt wird, unbekannt ist. Der Mediator 106a1 sollte die Funktionalität durch eventuelle Umstrukturierung der von einem Peer kommenden Sessioninformation 112 ausführen können, wenn sich auf Information über mehrere Sessionen 103 nur durch Anrufen des Mediators 106a1 verwiesen werden kann, sie aber nicht explizit in der Mitteilung enthalten ist. Infolgedessen sorgt der Mediator 106a1 für eine Komplettierung des Informationssatzes 112 bezüglich der Session 102 durch die Parteien, für welche die Unterstützung gemacht wird. Der Mediator 106a1 ändert nicht die Inhalte der Sessioninformation 112, fügt aber eventuell seinen Anrufen vollständige Beschreibungsteile hinzu, um die von den anderen Verhandlungsparteien 106b und 106a2 gesetzte Information aufzurunden (round up).
  • Figure 00820001
  • NACHTEILE UND UNZULÄNGLICHKEITEN DES STANDES DER TECHNIK
  • In der europäischen Patentanmeldung EP 01 122 366.6 sind das gesamte E2ENP-Konzept, seine Erfordernisse und eine mögliche Implementierung desselben beschrieben, jedoch ohne Detaillierung irgendeiner Implementierung in Bezug auf die gegenwärtigen Technologien. Jede vorverhandelte Information wird nicht rechtzeitig ausgeführt.
  • Obgleich die gegenwärtige Form des SDPng [SDPNG03] in modularer Weise strukturiert ist, zieht es nicht E2ENP-Aspekte in Betracht und kann nicht in einer modularen Weise über verschiedene SIP-(oder anderes Protokoll-)Mitteilungen benutzt werden. Das SDPng basiert auf dem SDP-Anbieter/Antworter-Modell, bei dem komplexe Mehrphasenverhandlungsprozesse wie beispielsweise das im Geltugngsbereich des E2ENP vorgeschlagene eine nicht explizit berücksichtigt werden.
  • Ein zur Berücksichtung von Benutzerprofilinformation als Eingabe für den ganzen QoS-Verhandlungsprozess fähiger Prozess ist weder in der europäischen Patentanmeldung EP 01 122 366.6 noch im SDPng angesprochen.
  • AUFGABE DER ZUGRUNDELIEGENDEN ERFINDUNG
  • Im Hinblick auf die oben erwähnten Erläuterungen ist es die Aufgabe der zugrundeliegenden Erfindung, ein Verfahren vorzuschlagen, das QoS-Management- und Ressourcenreservierungs-Mechanismen für adaptive Echt- bzw. Realzeitdienste und Multimedienanwendungen, die auf mit einem drahtlosen Netzwerk verbundenen mobilen Endgeräten laufen, unterstützt, um an zeitlich variierende Verbindungscharakteristiken (link characteristics) des zugrundeliegenden Mobilfunkkanals (mobile radio channel) dynamisch anzupassen. Dabei sollen auf einer Integration und Koordination eines lokalen, Peer- und Netzwerk-Ressourcenmanagements basierende Konzepte realisiert werden, die Peers erlauben, einen gemeinsamen Satz (Menge) von Fähigkeiten, Qualitäten und Adaptierungsmechanismen, bevor die tatsächliche Kommunikation stattfindet, vorzuverhandeln, um eine garantierte End-zu-End-Qualität für die Endgeräte bereitzustellen.
  • Diese Aufgabe wird durch die Merkmale der unabhängigen Ansprüche gelöst. Vorteilhafte Merkmale sind in den abhängigen Ansprüchen definiert. Weitere Aufgaben und Vorteile der Erfindung gehen aus der folgenden detaillierten Beschreibung hervor.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die zugrundeliegende Erfindung ist grundsätzlich auf ein Modell zum Definieren von Benutzerprofil- und Endgerätfähigkeitinformation derart, dass hierarchische QoS-Vertragsspezifikationen (beispielsweise Erzwingen von Korrelationen quer durch verschiedene Sätze (Mengen) von QoS-Verträgen für verknüpfte bzw. verbundene Medienströme) zur Ableitung verhandelbarer Information forciert (forciert umfasst durchgesetzt, geltend gemacht, eingehalten) und benutzt werden können, gerichtet. Als eine Referenzimplementierung dieses Konzepts beschreibt diese Erfindung eine neue Benutzung des von der Internet Engineering Task Force (IETF) standardisierten Session Initiation Protokoll (SIP) in Verbindung mit Erweiterungen der Session Description Protocol Next Generation(SDPng)-Spezifikation auf der Basis der Extensible Markup Language (XML), um End-to-End-QoS-Negotiation Protocol (E2ENP) Konzepte zu implementieren.
  • Insbesondere erweitert das hierdurch vorgeschlagene Modell die SDPng-Verhandlungsmechanismen, in dem es erlaubt:
    • – dass verschiedene Stücke komplementärer Information übertragende Abschnitte des SDPng bei verschiedenen Phasen des die Bildung eines Vollverhandlungsbildes durch Komplementierung der Verhandlungsphasen erlaubenden E2ENP übertragen werden, wobei jede Phase in der SDPng-Beschreibung explizit erwähnt wird,
    • – das Forcieren (Forcieren umfasst Durchsetzen, Geltendmachen, Erzwingen, Zwingen, Auffordern bzw. Einhalten) von Zeitrahmen für gewisse der für die Vorverhandlungsphase benutzten Abschnitte und dadurch Vermeiden, dass obsolete Information später falsch forciert wird.
  • KURZE BESCHREIBUNG DER ANSPRÜCHE
  • Der unabhängige Anspruch 1 und die abhängigen Ansprüche 2 bis 12 beziehen sich auf eine Erweiterung des Sessions Description Protocol Next Generation zur Implementierung von im Geltungsbereich des End-to-End-Negotiation Protocol (E2ENP) benötigten Konzepten, die eine garantierte End-zo-End-Qualität (end-to-end quality) für eine Telekommunikationsession bereitstellen, wobei Multimedienanwendungen, die auf mit einem drahtlosen Netzwerk verbundenen mobilen Endgeräten laufen, involviert werden, um an zeitlich variierende Verbindungscharakteristiken des zugrundeliegenden Mobilfunkkanals dynamisch angepasst zu werden. In diesem Kontext basieren diese Konzepte auf einer Integration und Koordination von lokalem, Peer- und Netzwerkressourcenmanagement, das den Peers ermöglicht, einen gemeinsamen Satz (Menge) von Fähigkeiten, Qualitäten und Adaptierungsmechanismen, bevor die tatsächliche Kommunikation stattfindet, vorzuverhandeln. Dabei wird das Session Description Protocol Next Generation (SDPng) zum Definieren eines Anwendungsebeneprotokolls benutzt.
  • Als nächstes sind die abhängigen Ansprüche 13 bis 49 auf ein Verfahren zum Implementieren von Konzepten gerichtet, die im Geltungsbereich des End-to-End-Negotiation Protocol (E2ENP), das eine garantierte End-zu-End-Qualität für eine Telekommunikationssession bereitstellt, benötigt werden. Dabei kann das SDPng zum Definieren von Benutzerprofilinformation, die zum Ableiten einer Eingabe für das E2ENP benutzt wird, angewendet werden.
  • Außerdem gehört der unabhängige Anspruch 50 zu einem End-to-End-Negotiation Protocol (E2ENP), bei dem eine QoS-freigegebene Telekommunikationsession durch eine Vorverhandlung alternativer QoS-Aspekte und Fähigkeiten auf einer End-zu-End-Basis hergestellt wird, um im Voraus eine gemeinsame Ebene alternativer QoS und Fähigkeiten herzustellen, über deren Benutzung alle Peers der Telekommunikationsession übereinkommen können.
  • Überdies bezieht sich der abhängige Anspruch 51 auf einen Broker (Makler, Informationsmakler) für eine End-zu-End-Verhandlung, der eine garantierte End-zu-End-Qualität für eine Telekommunikationssession bereitstellt. Dabei kann dieser Broker Peers eines Netzwerks das Ausführen der Vorverhandlungsphase und, optional, die Multistromzeitsynchronisationsphase und die QoS-Korrelationsphase gemäß Anspruch 35 abnehmen.
  • Als nächstes bezieht sich der Anspruch 52 auf eine Softwareroutineimplementierung eines Verfahrens gemäß einem der Ansprüche 13 bis 49, wenn es auf einem Daten- bzw. Informationsverarbeitungsgerät (computing device)ausgeführt wird.
  • Darüber hinaus sind die Ansprüche 53 bis 61 auf einen Peer gerichtet, der zum Implementieren eines Verfahrens gemäß einem der Ansprüche 13 bis 49 konfiguriert ist und der eine Koordinierungseinheit aufweist, welche die verschiedenen Phasen des Verhandlungsprozesses des verteilten Ressourcenmanagementsprozesses (distributed resource management process) koordiniert.
  • Schließlich gehört der abhängige Anspruch 62 zu einem Protokoll, das eine garantierte End-zu-End-Qualität für eine durch Vorverhandlung alternativer QoS-Aspekte und Fähigkeiten auf einer Ende-zu-Ende-Basis hergestellte Telekommunikationsession bereitstellt, um im Voraus eine gemeinsame Ebene für alternative QoS und Fähigkeiten herzustellen, bei deren Benutzung alle Peers der Telekommunikationsession übereinkommen können. Außerdem enthalten die Verhandlung und Wiederverhandlung von Fähigkeiten eine Signalisierung der ausgewählten Codecs und deren Konfigurationen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Weitere Vorteile und mögliche Anwendungen der zugrundeliegenden Erfindung resultieren aus den untergeordneten Ansprüchen sowie aus der folgenden Beschreibung einer Ausführungsform der Erfindung, die in den folgenden Zeichnungen gezeigt sind.
  • 1 zeigt ein die Rufverschiebung in einer Schaltsituation einer Telekommunikationsession zeigendes „Drittpartei-unterstütztes" Eins-zu-Eins-Kommunikationsszenario 100, das die Idee, wie die zukünftige telefonartige Kommunikation ausgebildet sein kann, präsentiert,
  • 2 zeigt ein Eins-zu-Viele-Kommunikationsszenario 200 das eine virtuelle Vorlesung zeigt,
  • 3 umreißt ein Viele-zu-Viele-Kommunikationsszenario, das eine einfache Form einer Videokonferenz zeigt,
  • 4 umreißt ein Viele-zu-Viele-Kommunikationsszenario, das eine komplexe Form einer Videokonferenz zeigt,
  • 5 präsentiert ein Beispiel, das mehrere zusätzliche Aspekte einer Mehrparteienkommunikation, welche die Benutzung gewisser Dienste, welche die Entdeckung der Kommunikationsparteien und -dienste unterstützen, berücksichtigen, und den Start der Verhandlung zeigt,
  • 6 umreißt ein Szenario, das zeigt, warum es notwendig ist, Konsistenz bereitzustellen.
  • 7 umreißt ein Szenario, das zeigt, warum es notwendig ist, Blockierungen (deadlocks) zu vermeiden, das heißt, warum das E2ENP sicherstellen muss, dass es keine Halte- und Warte-Bedingungen gibt oder dass eine solche Bedingung nur für eine begrenzte Zeitgröße vorhanden ist,
  • 8 zeigt ein Dialog- bzw. Interaktionsdiagramm, das die Phasen und Akteure des E2ENP durch ein einfaches Eins-zu-Eins-Verhandlungsszenario zur Herstellung einer einfachen Eins-zu-Eins-Kommunikation zeigt,
  • 9 zeigt die Funktionalität des das SDPng und das SIP benutzenden E2ENP,
  • 10 zeigt ein Beispiel, das die Benutzung des sogenannten <en2enp:alternative-service>-Abschnitts zeigt,
  • 11 zeigt ein Szenario, bei dem von Benutzerprofil- und Systemkonfigurationsinformation abgeleitete Verträge validiert werden,
  • 12 zeigt ein Beispiel eines Benutzers, der sich an zwei verschiedene Videokonferenzsessionen gleichzeitig anschließt, und
  • 13 zeigt ein Beispiel eines Viele-zu-Viele-Szenarios, das „Transitioning to Ad-hoc" bezeichnet wird.
  • DETAILLIERTE BESCHREIBUNG DER ZUGRUNDELIEGENDEN ERFINDUNG
  • Im Folgenden wird die in den 1 bis 13 gezeigte bevorzugte Ausführungsform der zugrundeliegenden Erfindung detailliert erläutert. Die Bedeutung der mit den Bezugszeichen in den 1 bis 13 bezeichneten Symbole kann der Tabelle 3 entnommen werden.
    • 1. Erweiterung des SDPng 912 zur Implementierung von Konzepten des E2ENP 908 und einer hierdurch vorgeschlagenen Erweiterungen, insbesondere: – Der Inhalt des SDPng (912) kann von Benutzerprofilinformation abgeleitet werden, der dann als Eingabe für das E2ENP (908) benutzt wird, – der Inhalt des SDPng (912) kann von Endgerätfähigkeitinformation abgeleitet werden, der dann als Eingabe für das E2ENP (908) benutzt wird. – Einführen von zwei neuen SDPng-Abschnitten, die QoS-Aspekte für einen einzelnen Medienstrom 206 oder Gruppen davon detaillieren, – modulare Benutzung von Abschnitten: Verschiedene Abschnitte des (im tatsächlichen SDPng-912-Entwurf und neu vorgeschlagenen) SDPng können in den verschiedenen Phasen des E2ENP 908-Protokolls ausgetauscht werden, – Hinzufügen eines jeden SDPng-Inhalts in jeder Phase des E2ENP 907 explizit identifizierenden Tags (Markierung), wobei der SDPng-Inhalt tatsächlich eine Protocol Data Unit (Protokolldateneinheit) des E2ENP 908 wird, die über das SIP 910 oder ein ähnliches Protokoll (beispielsweise SCCP) huckepack getragen wird, – E2ENP-9108-vorverhandelte SDPng-Information mit einem Leasing, um die Validität dieser Information zeitlich zu begrenzen, und – Erweiterung der SDPng-912-Unterstützung zur Spezifizierung verschiedener Typen von Netzwerk-604-Adressen über die Direktunterstützung des IP v4 hinaus.
    • 2. Erweiterung des E2ENP 908: – Benutzung des SDPng 912 zum Definieren von Benutzerprofilinformation, die als Eingabe für das E2ENP 908 zu benutzen ist, – Benutzung des SDPng 912 zum Definieren von Endgerätfähigkeitinformation, die als Eingabe für das E2ENP 908 zu benutzen ist,
    • – detaillierte Abbildung des E2ENP 908 auf das SIP-910-Protokoll via Huckepack.
  • Um die im vorhergehenden Kapitel dargelegten Erfordernisse zu erfüllen, wird ein mit End-to-End-QoS Negotiation Protocol (E2ENP 908) bezeichnetes neues Protokoll vorgeschlagen.
  • Bevor mit der Beschreibung des E2ENP-908-Konzepts fortgefahren wird, werden hiermit einige Schlüsselannahmen, welche die generische Beschreibung der oben beschriebenen Akteure und Szenarios vervollständigen, präsentiert.
  • Das einfache Ein-zu-Eins-Kommunikationsszenario 800
  • Die Benutzung der Kommunikationsmoden (Push, Pull und Push-Pull) kann in Bezug auf die Sender und die Empfänger situations- und anwendungsabhängig sein. Einige Standardbenutzungen der Moden werden hier beschrieben:
    • – Wenn der Anbieter keine Vorstellung darüber hat, wie das Profil des Antworters 811 aussieht, kann der Anbieter 810 einen „Pull"-Modus („Zieh"-Modus) benutzen, um zuerst die Einstellungen des Antworters 811 wiederzugewinnen und eventuell die eigenen Einstellungen des Anbieters 810 anzupassen.
    • – Wenn der Anbieter 810 keine Möglichkeiten zur Anpassung hat (oder aus welchem Grund auch immer), kann der Anbieter 810 ihre/seine Einstellungen zum Antworter 811 „pushen" („schieben") um sie/ihn auf diese Weise eventuell zur Anpassung oder Benutzung des „Push"-Modus („Schiebe"-Modus) zu forcieren.
    • – Wenn eine Adaptierung auf den beiden Seiten notwendig sein kann, kann der „Push-Pull"-Modus („Schiebe-Zieh"-Modus) zum Freigeben eines Dreiwegeaustauschs des Vorschlags des Anbieters 810 benutzt werden. Dieser Modus kann zu einem Übereinkommen bei einer Zweiwegekommunikation benutzt werden.
  • Durch die Annahme, dass die „Empfänger" auf gegebene „Sender" abgestimmt sein sollten, sollten die „Empfänger" diejenigen sein, die anpassen (adaptieren). Wenn die „Sender" an gegebene „Empfänger" angepasst sein sollten, findet die Adaptierung (Anpassung) bei den „Sendern" statt.
  • Es gibt drei Szenarios für den Fall des einfachen Eins-zu-Eins-Kommunikationsszenarios 800, die in Betracht ziehen, welche Partei der Anbieter 810 und welche der Antworter 811 ist, welche Partei der Sender oder Empfänger ist und wenn beide Parteien senden und empfangen können bzw. dürfen:
  • – Sender (Anbieter 810) – Empfänger (Antworter 811)
  • Generell können für dieses Szenario sowohl der „Push"- als auch „Pull"-Modus entsprechend den Adaptierungsmöglichkeiten und -Regeln des Senders und/oder des Empfängers benutzt werden. Wenn der Anbieter 810 derjenige ist, der adaptieren sollte, sollte der Anbieter 810 einen „Pull"-Modus benutzen, andernfalls sollte ein „Push"-Modus benutzt werden. Die Benutzung des „Push-Pull"-Modus kann auch angewendet werden, aber bei einem erwarteten Einwegdatenmedienstrom 206 würde dies nur das Signalisierungsprotokoll verkomplizieren und mit dem Erfordernis der E2ENP-Einfachheit im Wiederspruch stehen.
  • – Empfänger (Anbieter 810) -Sender (Antworter 811)
  • Auch in diesem Fall können sowohl der „Push"- als auch „Pull"-Modus entsprechend den Adaptierungsmöglichkeiten und -regeln des Senders und/oder des Empfängers benutzt werden. Der Anbieter 810 ist derjenige, der adaptieren sollte, der Anbieter 106b sollte einen „Pull"-Modus benutzen, andernfalls sollte der „Push"-Modus benutzt werden. Die Benutzung von „Push-Pull" ist hier aus den gleichen Gründen wie bei dem obigen Szenario auch nicht empfehlenswert.
  • – Sender-Empfänger (Anbieter 810) oder Sender-Empfänger (Antworter 811)
  • Wenn alle Peers planen, Medienströme 206 sowohl zu senden als auch zu empfangen, sammelt der Anbieter 810 Information über Empfangsfähigkeiten und QoS-Wünsche des Antworters 811, bevor der Anbieter 810 eine Einladung zum gegebenen Antworter 811 abgibt.
  • Auf diese Weise kann der Anbieter 811 zur Aufforderungs- bzw. Invitationszeit (invitation time) zum Antworter 811 einen Vorschlag senden, der umfasst:
    • – Information über die Fähigkeiten des Anbieters 810 zum Senden und Empfangen von Medienströmen 206,
    • – die eigene gewünschte QoS-Spezifikation des Anbieters 810 zum Empfang von Medienströmen 206, zugeschnitten auf Präferenzen des Antworters 811, und
    • – QoS-Vorschläge zum Senden von Medienströmen 206, zugeschnitten auf Präferenzen des Antworters 811.
  • Der Antworter 811 antwortet dann dem Anbieter 810 mit einer Teilmenge des Angebots (bid) des Anbieters.
  • Dieses Szenario menutzt am wahrscheinlichsten den „Push-Pull"-Modus, da eine bidirektionale Kommunikation hergestellt werden sollte.
  • Eins-zu-Viele-Kommunikationsszenario 200
  • Durch das Eins-zu-Viele-Kommunikationsszenario 200 sind nicht alle Kombinationen von Verbindungsmoden (connection modes) und Verhandlung-806-Moden möglich und vernünftig. Beispielsweise kann das „Single-Receiver and Many-Sender"-Szenario („Einzelempfänger-und-Vielesender"-Szenario) eine Überlastung auf der Empfängerseite verursachen, und dies ist es, warum dieser Fall durch Forcieren des Empfängers, mehrere Verhandlungen 808 und 809 auf einer separaten Basis mit jedem Sender, wie im „Sender (Anbieter 810)-Empfänger (Antworter 811)" Szenario auszuführen, behandelt werden sollte.
  • Einige mit dem Eins-zu-Viele-Szenario korrespondierende wohlbekannte Verbindungsszenarios sind:
    • – Reines Mehrfachsenden: Empfänger „stimmen" sich auf gegebene Sender durch Auswählen einer gegebenen Mehrfachsendegruppe (multicast group) auf der Basis einer vorher (beispielsweise über SAP) verbreiteten Information „ab". In diesem Fall agiert der Sender als eine Art Anbieter 810.
    • – Dieses Szenario würde wie das „Empfänger (Anbieter 810)-Sender (Antworter 811)"-Szenario arbeiten. Dies ermöglicht Flexibilität des Anschließens an die und Verlassens der Session 102. Der Antworter 811 kann dann die Session 102 an eine einzelne Basis für jeden Teilnehmer adaptieren, aber auch die von schon existierenden Sessionen 102 benutzten Ressourcen berücksichtigen. Hatte anstelle dessen der Sender die Rolle des Anbieters 810 eingenommen, sind möglicherweise die Empfänger nicht fähig gewesen, solchen Erfordernissen zu begegnen.
  • In beiden Fällen könnte der Anbieter 810 (entweder Sender oder Empfänger) vorteilhafter weise vorverhandelte Offline-Information zur Beschleunigung der Kommunikationsherstellung bei Laufzeit benutzen. Eventuell könnte dies durch Benutzeragenten, wie sie in den von FIPA – the Foundation for Intelligent Physical Agents (http://www.fipa.org/), im Folgenden als [FIPA] bezeichnet, publizierten Dokumenten beschrieben sind, oder durch einen Broker ausgeführt werden (aber diese Fälle liegen außerhalb des Geltungsbereichs dieses Dokuments). Alle Szenarios, bei denen die Einzelpartei ein Empfänger ist, sollten als Eins-zu-Eins-Verhandlung 806 angesehen werden, da für jeden hereinkommenden Medienstrom 206 ein gewisses separates Ressourcenmanagement notwendig sein kann.
  • Viele-zu-Viele-Kommunikationsszenario 300, 400 oder 500 Dieser Fall könnte wie die Überlagerung mehrerer Verhandlungen 809 behandelt werden, sollten die Peers am Beginn der Wahl eines Konferenzvorsitzenden übereinkommen, wer die Verhandlungen 809 zum Anschließen/Verlassen der Session 102 orchestriert und ihren Verlauf managt. Die Peers könnten auch gewisse A-priori-Arrangements darüber treffen, wie die Kommunikationsumgebung zu konfigurieren ist, bevor sie die realen Verbindungen verhandeln. Die parallelen und/oder sequentiellen Verhandlung-806-Läufe zwischen den verhandelnden Peers sind anwendungsabhängig und deshalb außerhalb des Schutzbereichs der gemäß der zugrundeliegenden Erfindung vorgeschlagenen Lösung.
  • Das E2ENP 908 weist vier Schlüsselphasen auf, nämlich:
    • 1. End-zu-End-QoS-Vorverhandlungsphase 802,
    • 2. Multistrom-QoS-Korrelation-804- und Zeitsynchronisation-805-Forcierungsphase,
    • 3. End-zu-End-Qos-Kompaktverhandlungsphase (mit Ökonomieprinzip), oder kürzer „Schnellverhandlung"-806, und
    • 4. End-zu-End-Qos-Kompaktwiederverhandlungsphase (mit Ökonomieprinzip), kürzer „Schnellwiederverhandlung"-808.
  • Alle vier Phasen können innerhalb der Dauer einer gegebenen Mediensession 102 verkettet sein. Alternativ dazu können die ersten zwei Phasen unabhängig von den letzteren zwei und zu verschiedenen Zeiten, aber strikt der gegebenen Ordnung folgend ausgeführt werden. Endlich können, gegeben, dass die Resultate der verschiedenen E2ENP-908-Phasen innerhalb einer begrenzten Zeitdauer gültig sind, die korrespondierenden Validitätszeitskalen von Phase zu Phase differieren.
  • Insbesondere kann die End-zu-End-Qos-Vorverhandlungsphase 802a priori ausgeführt werden, und die Resultate können dann auf die verbleibenden Phasen mehrerer sukzessiver Telekommunikationsessionen 102 zu späteren Zeiten angewendet werden. Diese Phase wird durch einen Prozess charakterisiert, den Endpeers vor dem tatsächlichen Start einer Mediensession 102 und unabhängig von der Session 102 selbst ausführen können. Die Aufgabe dieser Phase ist es, – in einer nicht obligatorischen Weise – den Austausch von Information zwischen Peers, betreffend Konfigurationen von Fähigkeiten und QoS-Verträgen 1108, wie sie von ihren QoS-Profilen deduziert werden, zu ermöglichen.
  • Diese Konfigurationen inkludieren Adaptierungspfade, so dass die End-Peers auf dem Weg proaktiv übereinkommen können, um auf mögliche QoS-Änderungen oder QoS-Verletzungen in einer effektiven und effizienten Weise zu reagieren. Optional erlaubt diese Phase jedem Paar Peers Verhandlungsgruppenadaptierungspfade auf einer Assoziationsebene zu verhandeln, das heißt eine QoS-Korrelation 804 und Zeitsynchronisation 806 über allen zwischen dem gegebenen Paar Peers hergestellten Medienströme 206 zu verhandeln.
  • Dieser Informationsaustausch weist für die involvierten Peers informellen Charakter auf und wird nicht nur zum vorher einander informieren über die Fähigkeiten und Performancemöglichkeiten, die bei dem gegebenen Satz (Menge) von Peers anwendbar sind, sondern auch zum Erreichen von Übereinkommen beim Neudefinieren gewisser dieser Konfigurationen benutzt. Auf diesem Weg können die Peers somit vor jedem speziellen Geschäft ein gemeinsames Vokabular herstellen.
  • Die Multistrom-QoS-Korrelation-804- und Zeitsynchronisation-805-Forcierungsphase ist insofern optional, als sie nur erforderlich ist, wenn Peers planen, mehrere Medienströme 206, die korreliert und synchronisiert werden müssen, herzustellen. Die individuellen Peers wenden nur eine solche Phase an. Als eine Ausnahme könnte eine separate Entität (beispielsweise eine Zwischenkomponente wie eine Konferenzrufbrücke) auch diese Phase anwenden, sollten die verschiedene Peers sie delegieren, um komplexe Verhandlungen 806 zwischen ihnen durchzuführen. Der Fall von Zwischenkomponenten ist außerhalb des Geltungsbereichs dieser Beschreibung und er ist nur der Vollständigkeit halber erwähnt. Die Phasen und Akteure des E2ENP 908 können dem in 8 gezeigten Dialog- bzw. Interaktionsdiagramm entnommen werden.
  • Die dritte Phase ist durch einen Prozess charakterisiert, den End-Peers entweder vor oder beim tatsächlichen Start einer Mediensession 102 ausführen können, um auf einer für die gegebene Session 102 und gegebenen Medienströme 206 auf der Basis von Resultaten eines vorher angewendeten Prozesses einer End-zu-End-QoS-Vorverhandlung 802 zu forcierenden gegebenen QoS-Ebene übereinzukommen. Dieser Prozess ist im Vergleich zu dem Fall einer End-zu-End-QoS-Vollverhandlung 806 bedeutend schneller, da tatsächliche nur Referenzen von vorverhandelter Information zwischen Peers ausgetauscht werden. Eine End-zu-End-QoS-Vollverhandlung 806 ist ein Prozess, den End-Peers entweder vor oder beim tatsächlichen Start einer Session ausführen können, um auf einer gegebenen QoS-Ebene zum Forcieren der gegebenen Session und gegebener Ströme übereinzukommen, eventuell durch Neudefinieren gewisser der ursprünglich vorgeschlagenen Konfigurationen von QoS-Spezifikationen. Bei Vollendung des End-zu-End-QoS-Kompaktverhandlungsprozesses sind die End-Peers über die QoS-Profile, die sie für die Kommunikation zu benutzen beginnen, übereingekommen. Bei Vollendung des Prozesses der End-zu-End-QoS-Kompaktverhandlung 806 sind die End-Peers über die QoS-Profile, die sie für die Kommunikation anzuwenden beginnen, übereingekommen.
  • Die vierte Phase ist charakterisiert durch einen Prozess, den End-Peers bei einer Detektion von entweder einer QoS-Änderung oder einer QoS-Verletzung auslösen können, um auf einer für die gegebene Mediensession 102 auf der Basis von Resultaten eines vorher angewendeten Prozesses einer End-zu-End-QoS-Vorverhandlung 802 zu forcierenden gegebenen QoS-Ebene übereinzukommen.
  • Dieser Prozess ist im Vergleich zu dem Fall einer End-zu-End-QoS-Vollwiederverhandlung 808 bedeutend schneller, da tatsächlich nur Referenzen von vorverhandelter Information zwischen Peers ausgetauscht werden. Eine End-zu-End-QoS-Vorverhandlung 802 ist ein Prozess, den Peers bei einer Detektion von entweder einer QoS-Änderung oder einer QoS-Verletzung auslösen können, um auf einer für die gegebene Session und gegebenen Ströme forcierten gegebenen QoS-Ebene übereinzukommen, eventuell durch Neudefinition gewisser der ursprünglich vorgeschlagenen Konfigurationen von QoS-Spezifikationen. Bei Vollendung des End-zu-End-QoS-Kompaktwiederverhandlungsprozesses sind die End-Peers über neue QoS-Profile, die sie im Begriff sind, für die Kommunikation zu benutzen, übereingekommen.
  • Bei Vollendung des Prozesses der End-zu-End-QoS-Kompaktwiederverhandlung 808 sind die Peers über neue QoS-Profile, die sie für die Kommunikation zu benutzen beginnen, übereingekommen.
  • Die End-zu-End-QoS-Kompaktwiederverhandlungsphase 808 kann während der Dauer jeder gegebenen Mediensession 102 mehrere Male angewendet werden.
  • Auf der Basis der oben dargelegten Erfordernisse können Peers einen gemeinsamen Ressourcenmanagementgrundsatz proaktiv vorverhandeln, um immer wenn die zu Wiederverhandlungen 808 führenden Bedingungen erfüllt sind, Instabilitäten zu vermeiden.
  • Bis zu diesem Grad können Peers Wiederverhandlungen 808 auf zwei verschiedenen Ebenen ausführen:
    • – Einen schnellen Inbandsignalisierungsprozess (durch beispielsweise Änderung des RTP-Payloadtyps im RTP-Paketheader während der Laufzeit ohne Beeinflussung der derzeit forcierten Anwendungsebene-QoS-Verträge 1108), und -- einen strukturierteren Prozess auf der Basis der End-zu-End-QoS-Wiederverhandlungsphase 808 (immer wenn der frühere Prozess nicht ausreicht, einer gegebenen QoS-Verletzung/Änderung zu begegnen).
  • Insbesondere können Peers wählen, jeden bei einem gegebenen Benutzerebene-QoS-Vertrag 1108 anwendbaren Payloadtyp zu benutzen, wie es unten beschrieben wird. Diese Wahl würde in einem Fall der üblichen RTP-Inbandsignalisierung als eine Form einer sehr schnellen Wiederverhandlung 808 reflektieren. Während die End-zu-End-QoS-Wiederverhandlungsphase 808 stattfinden würde, sollten QoS-Verletzungen oder QoS-Änderungen auftreten, die eine Forcierung eines neuen Benutzerebene-QoS-Vertrags 1108 erfordern.
  • Das in den RTP-Headern enthaltene RTP-Payloadtypfeld kann von Sendern benutzt werden, um zu ihren Empfängern die Entscheidung, einen anderen (verhandelten) Codec zu benutzen, Inband-zu-signalisieren. Dies ist eine Form von Wiederverhandlung 808, die für das E2ENP 908 per se transparent wäre. Jedoch können diese eine Inbandsignalisierung benutzenden Peers noch das E2ENP 908 vorteilhafter Weise dazu benutzen, auf QoS-Verletzungen/Änderungen effektiven und effizient zu reagieren. In diesem Kontext kann die Benutzung der RTP-Inbandsignalisierung leicht durch Forcieren von Peers zum Validieren des neu vorbeschlagenen Codec gegen jede vorverhandelte Information nicht nur in Form von Fähigkeiten sondern auch von QoS-Verträgen 1108 harmonisiert werden.
  • Dies bedeutet, dass der Sender als allererstes die neue Fähigkeit (und dementsprechend Vorbuchungsressourcen (pre-book resources)) sowie einen neuen QoS-Vertrag 1108 (der die Benutzung dieser Fähigkeit optimiert) in Bezug auf die vorverhandelte Information validiert.
  • Es kann Fälle geben, bei denen der Empfänger detektiert, dass nicht genug Ressourcen zur Aktivierung des gegebenen Codec verfügbar sind, während der Sender den Codec schon eingeschaltet und mit ihm codierte Pakete gesendet hat. Der Empfänger kann deshalb diese Pakete nicht decodieren oder sie auf einer niedrigeren QoS-Ebene (beispielsweise niedrigeren Geschwindigkeit/Rahmenrate) decodieren. Um dieses Problem zu bearbeiten, kann angenommen werden, dass der Empfänger die letztere Option (Decodieren auf niedrigerer QoS-Ebene) wählt, aber zum Sender explizit signalisiert, eine niedrigere QoS-Ebene (über E2ENP 908-Kompaktwiederverhandlung 808), beispielsweise eine dazwischenliegende (unter der Annahme, dass vorverhandelte Information verfügbar ist), auszuwählen. Bis zu diesem Grad ist es notwendig zu erwähnen, dass ein Verlieren oder Nichtinterpretieren eines einzelnen Videopakets für die Zeit des QoS-Schaltens zwischen dem Sender und dem Empfänger nicht zu kritisch ist, da aus der Perspektive des menschlichen Benutzers das Fehlen eines einzelnen Videorahmens nicht so leicht bemerkt wird. Infolgedessen sollte die vom Benutzer wahrgenommene Video-QoS durch solche unbedeutenden Videostörungen nicht als ernst beeinträchtigt angesehen werden. Andererseits resultiert ein Verlieren oder Nichtinterpretieren eines einzelnen Audiopakets in hörbarem Krachen oder Knacken (audible cracks), das aus der Perspektive des Benutzer als eine Verletzung angesehen werden sollte. Eine mögliche Lösung dieses Problems kann das in „RTP Payload for Redundant Audio Data" (RFC 2198 Network 604 Working Group, September 1997) von C. Perkins et al., im Folgenden als [RFC2198] bezeichnet, beschriebene Senden redundanter Audiodaten mit der gleichen oder einer anderen Qualität im gleichen Audiopaket sein. Die Pakete übertragen auf diese Weise die Audiodaten zweimal, und wenn ein einzelnes Audiopaket verloren geht, gibt das folgende die verlorenen Daten redundant ab. Zur Unterstützung der Benutzer-wahrgenommenen Audio-QoS sollte eine solche duplizierte Information in Bezug auf die vereinbarten Fähigkeiten und QoS-Verträge 1108 zwischen den Peers abgegeben werden, so dass der Sender unterschiedlich codierte Audiodaten parallel abgeben kann. Der Empfang von einzelnen Audiopaketen mit niedrigerer Qualität sollte aus der Benutzerperspektive nicht als eine Verletzung angesehen werden, da ein Mensch solche Änderungen wie beispielsweise Singularitätsschaltungen (singularity switches) zwischen Mono und Stereo selten bzw. kaum wahrnehmen würde, wenn das Monosignal gleichzeitig auf allen Audioboxen des Geräts gespielt wird. Generell ausgedrückt sollte die Akkumulation von Audio- und Videosingularitätsstörungen als eine Verletzung angesehen werden und sollte nur für die Zeit einer laufenden Wiederverhandlung 808 zugelassen werden. Die Behandlung des Auftretens von Mediensingularitäten ist ein Problem der Realisierung des Ressourcenmanagements, der Toleranz und Steuermechanismen usw., und kann anwendungs- und heuristikabhängig sein.
  • Schlüsselausgaben zur Realisierung der oben beschriebenen Mechanismen sind:
    • 1. Die Inbandsignalisierung reicht nicht aus, allen Peers, die über QoS-Kontrakte 1108 übereingekommen sind, zu erlauben, zu forcieren: dass der vollständige Wiederverhandlung-808-Mechanismus in der Tat durch Benutzung mehrerer strukturierter Lösungsansätze wie des E2ENP 908 erreichbar ist. Jedoch kann als Alternative zur Benutzung des E2ENP 908 der Empfänger die gegenwärtige QoS-Ebene überwachen, eventuell durch wirksames Einsetzen (leveraging) von RTCP-Monitoren, und auf diese Weise identifizieren, welchen der vorverhandelten QoS-Verträge 1108 der Sender derzeit forciert.
    • 2. Netzwerkressourcenreservierungen sollten nicht übergeben werden, bis beide Peers darüber übereingekommen sind, welcher Codec und welcher QoS-Vertrag 1108 zu forcieren ist. Das E2ENP 908 garantiert dies Dank des „Ökonomieprinzips".
  • Auf der Basis von Erfordernissen, die zum Fertigwerden mit Übergabeszenarios benötigt werden, könnten die QoS-Verträge 1108, die von dem vom Benutzer bevorzugten gegebenen Netzwerkprovider nicht unterstützt werden, vorteilhafter Weise als Ersatz bzw. Reserve angesehen werden. Diese Verträge 1108 müssten insofern verhandelt werden, als der Anbieter 810 und der Antworter 811 vorteilhafter Weise vorher über ähnliche Verträge 1108 übereinkommen könnten, um Vereinbarungen zwischen den anderen Peers und ihren gegenwärtig benutzten Netzwerkprovidern zu berücksichtigen.
  • Wenn eine vertikale Übergabe stattfindet, kann jeder Peer versuchen, alle ihre/seine Verträge 1108 einschließlich der Ersatz- bzw. Reserveverträge, die in Bezug auf den neuen Netzwerkprovider und/oder neuen Typ von Zugriffsnetzwerk 604 eventuell anwendbar werden können, zu validieren. Dies bedeutet, dass der eine QoS-Verletzung oder -Änderung detektierende Peer beim Finden, dass gewisse Ersatz- bzw. Reserveverträge 1108 nun validiert sind, eine End-zu-End-QoS-Kompaktwiederverhandlungsphase 808 nicht nur zur Anzeige des neuen zu forcierenden QoS-Vertrags 1108, sondern auch zum „Entblocken" (freigeben) der vorverhandelten Reserveverträge 1108 initiieren kann.
  • Außerdem sei darauf hingewiesen, dass nach einer vertikalen Übergabe gewisse der vorher gültigen Verträge 1108 nicht länger anwendbar sein können. Dies bedeutet, dass das „ieren" solcher Verträge 1108 auch während der End-zu-End-QoS-Kompaktwiederverhandlungsphase 808 berücksichtigt werden sollte.
  • Das E2ENP 908 interagiert während aller vier Phasen mit den Lokalressourcenmanagementfunktionen. Insbesondere interagiert das E2ENP 908 während sowohl der End-zu-End-QoS-Kompaktverhandlungsphase 806 als auch der End-zu-End-QoS-Kompaktwiederverhandlungsphase 808 entsprechend dem „Ökonomieprinzip" und auf der Basis der während der End-zu-End-QoS-Vorverhandlungsphase 802 vorverhandelten Ressourcenmanagementgrundsätze mit den lokalen und Netzwerkressourcenmanagementfunktionen.
  • Ist die hierarchische Struktur der durch die Erfordernisse vorgeschriebenen QoS-Spezifikation gegeben, kann man sich vorgestellen, dass ein diese Erfordernisse gut erfüllendes Modell dasjenige ist, das auf dem Konzept der in „The Unified Modeling Language user Guide" (Addison Wesley Longman, 1999) von G. Booch, J. Rumbaugh und I. Jacobson, im Folgenden als [Booch99) bezeichnet, beschriebene Konzept der hierarchischen Finite State Machine (FSM (Maschine endlicher Zustände)) ist. Bei einem solchen Modell korrespondiert jeder QoS-Vertrag 1108 mit einem Zustand einer hierarchischen FSM. Auf der untersten Ebene dieser hierarchischen Struktur bilden Zustände auf QoS-Verträge 1108 individueller Medienströme 206 ab. Der nominelle QoS-Vertrag 1108 (das heißt derjenige, den der Benutzer durch Vorgaben freizugeben wünscht) korrespondiert mit dem Anfangszustand der FSM, der mit dem gegebenen Adaptierungspfad assoziiert ist. Jeder Adaptierungspfad korrespondiert mit einer elementaren FSM, in der sich Zustände gegenseitig ausschließen. Zustände und/oder vollständige elementare FSMs können in Zuständen höherer Ebene untergebracht werden, die wiederum mit QoS-Verträgen 1108 assoziiert sind. Dies stellt, wie oben angedeutet, das Konzept des QoS-Kontexts dar. In einem gegebenen Zustand höherer Ebene können gleichzeitig untergebrachte FSMs koexistieren. Dies stellt eine Gruppe von Adaptierungspfaden, die mit einem gegebenen QoS-Kontext korreliert sind, dar.
  • Jeder Übergang einer solchen hierarchischen FSM beschreibt eine besondere Änderung eines QoS-Vertrags 1108 in Reaktion auf ein gegebenes Ereignis, beispielsweise eine QoS-Verletzung. Die Übergänge werden immer ausgelöst, wenn sich spezifische Prädikate als wahr erweisen. Dies übersetzt sich in unser Modell zum Vergleichen der Werte speziell überwachter QoS-Parameter gegen die in den gegebenen QoS-Verträgen 1108 festgesetzten korrespondierenden Werte.
  • Übergänge werden eventuell mit Aktionen hoher Ebene (beispielsweise fallenlassen eines existierenden Medienstroms 206 oder starten eines neuen Medienstroms 206) assoziiert. Diese Aktionen können eventuell die Erzeugung von Ereignissen für die Benutzer, die eine temporäre Außerdienstbedingung (out of service condition), beispielsweise aufgrund des Auftretens einer Übergabe, anzeigen, verursachen.
  • Im Unterschied zu der in [Loyal] beschriebenen QoS Description Language (QDL (QoS-Beschreibungssprache)) sind die Spezifikationen von QoS-Verträgen 1108 (und, bis zu einem begrenzten Ausmaß, von QoS-Kontexten) und der hierarchischen FSM voneinander entkoppelt. Dies bringt in die Gestaltung (Design) Modularität und folglich Flexibilität ein: man kann einen gegebenen QoS-Vertrag 1108 mit verschiedenen Adaptierungsgrundsätzen kombinieren, und Adaptierungsgrundsätze können mit verschiedenen hierarchischen FSMs konfiguriert werden.
  • Der beim E2ENP 908 angewendete Verhandlung-806-Prozess besteht grundsätzlich aus dem Laufenlassen eines nicht-iterativen Verhandlung-806-Prozesses in der Verbindungsherstellungszeit, in der Peers einfach zwischen sich selbst einen Satz (Menge) von Zustandsidentifierern in Bezug auf die einen gegebenen vorverhandelten Adaptierungspfad darstellenden hierarchische FSM austauschen.
  • Der Anbieter 810 schlägt ein Angebot vor, und jeder Antworter 811 validiert das Angebot gegen seine eigenen Adaptierungsgrundsätze und antwortet demgemäss mit einem Gegenangebot. Dieses Modell beschränkt den Geltungsbereich der Gegenangebote auf die Definition eines Teilsatzes (Teilmenge) des ursprünglichen Angebots (um die Komplexität des Problems zu beschränken). Dies übersetzt sich auf Antworterebene wie folgt:
    • • in eine auf jeden Punkt im Angebot angewendete QoS-Vertragsübereinstimmungsverifikation (QoS contract conformance verification) sollten in Bezug auf die vorverhandelten QoS-Vertragstypen und QoS-Verträge 1108 die Verträge 1108 in einem XML-Dokument ausgedrückt werden; Übereinstimmungsverifikation könnte beispielsweise durch Forcieren einer vordefinierten, speziellen XML Document Type Definition (DTD (XML-Dokumenttypdefinition)) erzielt werden.
    • • In einen auf die Struktur der ursprünglichen vorverhandelten hierarchischen FSM angewendeten optionalen Satz (Menge) von Beschneidungsoperationen (pruning operations).
  • Es sei darauf hingewiesen, dass, immer wenn sich einer Gruppe von schon kommunizierenden Peers ein neuer Peer anschließt, der neue Peer, den oben beschriebenen gleichen Mechanismen folgend, als der Anbieter 810 eines neuen E2ENP-Prozesses (der eventuell von der End-zu-End-QoS-Kompaktverhandlungsphase startet, sollte der neue Peer schon mit den kommunizierenden Peers vorverhandelte Information haben) agieren kann. Außerdem würde jede Ad-hoc-Erzeugung, -Modifikation oder -Entfernung von QoS-Kontexten und/oder Medienströmen, nach denen der Verhandlung-809-Prozess erfolgreich vollendet (und nicht schon als eine QoS-Änderung im verhandelten Adaptierungspfad berücksichtigt) worden ist, einen neuen Fall des Verhandlungsprozesses 808 und 809 auslösen. Insbesondere sei darauf hingewiesen, dass der Benutzer absichtlich eine QoS-Änderung bei einer schon laufenden Multimedienanwendung verursachen kann, beispielsweise um die Gesamtebene einer QoS oder nur einen gewissen Teil von ihr zu erhöhen oder zu erniedrigen. Diese Verhandlung 808 und 809 würde eine Änderung bei den mit dem Adaptierungspfad assoziierten QoS-Verträgen 1108 reflektieren, könnte aber auch Licht auf die Struktur des Adaptierungspfades selbst werfen. Da der Verhandlungsprozess 808 und 809 sehr teuer ist, kann jede sukzessive inkrementelle Wiederanwendung des E2ENP 908 oder von Teilen davon Ineffizienzen verursachen. Bis zu diesem Grad sei darauf hingewiesen:
    • • In einem Video-on-demand-Szenario kommen beide Parteien auf einem Adaptierungspfad für einen vorbestimmten Satz von Medienströmen 206a priori einfach überein, um QoS-Verletzungen oder QoS-Änderungen zu begegnen. Die Variabilität der zuvor erwähnten Ad-hoc-Änderungen wird deshalb auf diesen Fall nicht angewendet.
    • • Der Anbieter 810 kann eventuell schon Ereignisse wie die Erzeugung, Modifikation oder Entfernung von QoS-Kontexten und/oder Medienströmen 206 im Adaptierungspfad, die er anbietet, berücksichtigen.
    • • Nach der anfänglichen Verhandlung 809 können alle Peers im Vergleich zu dem Fall der anfänglichen Verhandlung 809 die Verhandlung-806-Vereinbarungen schneller zusammenbringen, da die Majorität von ihnen schon verhandelte hierarchische FSM benutzt.
  • Die Regeln zur Behandlung dieser Situationen sind jedoch stark abhängig von dem bei den gegebenen Telekommunikationssessionen 102 angewendeten Managementtyp. Beispielsweise übersetzt sich dies im Fall von Konferenzdiensten in ein Wählen spezifischer Konferenzkontrollgrundsätze und Protokolle. Deshalb ist die Ausscher-E2ENP-908-Funktionalität (sheer E2ENP 908 functionality) in einer solchen Weise erdacht worden, dass sie diese Session-102-Managementaufgaben hoher Ebene zu externen Mechanismen und Protokollen delegiert, die somit außerhalb des Schutzbereichs der zugrundeliegenden Erfindung sind.
  • Durch Erweiterung des E2ENP-908-Phasenlösungsansatzes werden Verbesserungen wie die Einführung von Mikrophasen angedacht. Dies bedeutet, dass Peers vorverhandelte Information inkrementell aktualisieren können, beispielsweise zur Einstellung vorverhandelter Information im Fall vertikaler Übergaben, bei denen die neue Zugriffsnetzwerk-604-Technik/Kapazität und/oder ein neuer Provider anderer QoS-Ebenen im Vergleich zu den vorverhandelten anbieten kann. Bis zu diesem Grad ist eine modulare Beschreibung verhandelbarer Gegenstände notwendig, so dass diese, die durch die Änderungen nicht beeinflusst werden, gültig bleiben. Dies bedeutet, dass für solche Gegenstände dann keine Vollverhandlung 808 notwendig wäre, mit evidenten Vorteilen in Form von Performance in Bezug auf die QoS-Änderungen/Verletzungen-Behandlung. Dieses Konzept ist weiterem Studium überlassen. Insbesondere müssen Aspekte wie Einfluss auf vorexistierende Zustandsmaschinen, die vorverhandelte APs beschreiben, detailliert in Betracht gezogen werden.
  • In den folgenden Abschnitten werden mögliche Wege zur Implementierung der vorgeschlagenen Lösung durch wirksames Einsetzen existierender Protokolle wie SIP 910 und SDPng 912 präsentiert.
  • Bis zu diesem Grad wird das SIP 910 in neuen Moden benutzt, bleibt aber im Wesentlichen ungeändert, während Erweiterungen und gewisse Änderungen der SDPng-Spezifikation hierdurch vorgeschlagen werden, um die oben dargelegten Erfordernisse zu erfüllen. Die Funktionalität des das SDPng 912 und das SIP 910 benutzenden E2ENP 908 ist in 9 gezeigt.
  • Die Idee ist, die Benutzung des SIP 910 zu erweitern und die SDPng-Spezifikation (die laufend in der IETF MMUSIC Working Group studiert wird) so zu verbessern, dass es E2ENP-Erfordernisse bei minimalen und modularen Änderungen inkludiert. Dies ist noch nicht eine flügge gewordene Spezifikation, sondern eher eine detaillierte Erläuterung der hierdurch vorgeschlagenen Idee, mit dem Ziel, innerhalb der technischen Gemeinschaft Interesse zu wecken und Diskussion anzuregen.
  • Bevor anderweitig fortgefahren wird, sei die Ausgabe einer Anwendungsebene-QoS-Spezifikation angesprochen.
  • Benutzer sind typischer Weise daran interessiert, zu definieren, welche Information und mit welcher Qualität (insbesondere wenn sie nicht nur für den Inhalt sondern auch für die QoS zu bezahlen haben) austauschen wollen, unabhängig davon, wie ihre Erfordernisse durch ihre Endgeräte und das Netzwerk 604 tatsächlich ausgeführt werden. Deshalb kann erwartet werden, dass Benutzer ihre Wünsche durch Detaillieren einer Inhaltsbeschreibung und von QoS-Verträgen 1108 ausdrücken wollen. Dieser Typ von QoS-Spezifikation wird als Benutzerebene-QoS-Spezifikation bezeichnet.
  • Außerdem soll angenommen werden, dass Benutzer einen Satz von QoS-Verträgen 1108 als mit einem Satz (Menge) mehrerer verschiedener Inhalte und/oder Dienste assoziiert definieren wollen. Bis zu diesem Grad kann erwartet werden, dass Benutzer entweder diese QoS-Veträge 1108 im Flug spezifizieren wollen oder, vorteilhafter, sie in sogenannten Benutzerprofilinformationsdatenbanken vordefinieren und speichern wollen.
  • Anwendungen oder Middleware übersetzt die Benutzerebene-QoS-Spezifikation in Anwendungsebene-QoS-Spezifikation (Application-Level QoS Specification), die hierdurch als Eingabe für das E2ENP 908 angesehen wird.
  • Im Schutzbereich der zugrundeliegenden Erfindung sind wir tatsächlich daran interessiert, QoS, so wie sie der Benutzer wahrnimmt, wie in „A Framework für End-to-End User-Perceived Quality of Service negotiation 806" (IETF Internet Draft, work in progress, <draft-bos-mmusic-sdpqos-framework-00.txt>) von L. Bos et al., im Folgenden als [Bos01] bezeichnet, beschrieben zu spezifizieren. Jedoch achten wir nicht darauf, wie der Benutzer dies ausdrückt.
  • Es ist klar, dass dort eine Abbildung von den Wünschen und Präferenzen der Benutzer auf einen Satz von QoS-Parametern, welche die Qualität des End-zu-End-Übertragungsprozesses definieren, sein muss. Dieser Satz (Menge) von Parametern wird als die Anwendungsebene-QoS bezeichnet. Diese Abbildung ist anwendungsspezifisch und außerhalb des Schutz- bzw. Geltungsbereichs.
  • Das folgende XML-Dokument ist ein Beispiel, wie Anwendungsebene-QoS-Verträge 1108 spezifiziert werden können: Bei diesem Beispiel sind nur QoS-Verträge 1108 für Audio- und Videomedienströme 206 angezeigt, jedoch ist die Erweiterung zum inkludieren anderer Typen von Medienströmen 206 (wie Daten- oder Steuer- bzw. Kontrollmedienströme 206) geradeaus. Für jeden Typ von Medienstrom 206 wird ein Satz von Anwendungsebene-QoS-Parametern in Form nomineller Werte, nomineller Sätze (Mengen) oder operativer Bereiche spezifiziert.
  • Die in den QoS-Verträgen 1108 für Audiomedienströme 206 angezeigten Parameter reflektieren die in [ATP-Profile] angedeuteten Audiocodecparameter, mit dem Unterschied, dass Benutzerprofilinformation eher Bereiche als feste Konfigurationen dieser Parameter beschreibt. Andererseits reflektieren die in den QoS-Verträgen 1108 für Audiomedienströme 206 angezeigten Parameter nicht die [RTP-Profile]-Vorbeschreibungen, sondern es werden vielmehr in [BRAIN] vorgeschlagene QoS-Parameter benutzt.
  • Figure 01100001
  • Figure 01110001
  • XML-Beispiel 1
    • (Im Beispiel bedeuten beispielsweise: profile = Profil, name = Name, my preferred stream level QoS contracts = meine-bevorzugten-Stromebene-QoS-Verträge, contract = Vertrag, my audio contract-1, -2, -3'' type = mein Audiovertrag-l,-2,-3-Typ, audio = Audio, sampling = Abtastung, rate = Rate, set = Einstellung, range = Bereich, channel = Kanal, video = Video, frame = Rahmen, , size = Größe, color = Farbe, quality = Qualität, overall = gesamt.)
  • In Benutzerprofilen können Benutzer QoS mit verschiedenen Körnigkeitsebenen spezifizieren: Spezielle Soll- bzw. Zielwerte oder operative Bereiche, entweder als diskrete Sätze (Mengen) oder als kontinuierliche Intervalle. Die Rahmengrößeneinstellung (frame-size-set) zeigt die Größe der dargestellten Rahmen an. Sie kann als eine Standardrahmengröße (CIF, QCIF, SIF usw.) und/oder als eine Breite-Höhe-Auflösung in Pixel (beispielsweise 352 × 288) spezifiziert werden.
  • Die Rahmenrateneinstellung (frame-rate-set) bezeichnet ein Intervall zum Spezifizieren einer Soll- bzw. Zielrahmenrate der Peers. Wenn beispielsweise die Rahmenrate auf 20 Fr/s eingestellt ist, sollte der Sender 20 Rahmen pro Sekunde komprimieren, paketieren und senden können. Der Empfänger sollte 20 Fr/s decodieren und berechnen bzw. ändern können. Zusätzliche Information über die Videocodecabbildung in Bezug auf die Rahmengröße kann in „IP/TV CODECs, File Transfer and Storage Requirement Considerations" (White Paper, July 2000, http://www.cisco.com/warp/public/cc/pd/mxsv/iptv3400/tech/i pcod wp.htm), im Folgenden als [WP-CISCO] bezeichnet, gefunden werden.
  • Der Farbqualitätsbereich (color-quality-range) und der Gesamtqualitätsbereich (overall-quality-range) zeigt einen Bereich möglicher Kompressionsebenen für einen einzelnen Rahmen an, die für einen gegebenen Codec zur Verfügung stehen können. Je höher die erzeugte Kompression der Videodaten ist, desto niedriger ist die Qualität. In [Handl98] ist vorgeschlagen, die Qualität mit Nummern zwischen 0 (niedrigste Qualität) und 10 (höchste Qualität) auszudrücken, was anzeigt, dass dies die Qualität eines einzelnen Rahmens sein sollte. Jedoch ist diese Auflösung sehr klein, wenn in Betracht gezogen wird, dass die existierenden Codecs und die in der Zukunft zu entwickelnden Codecs mehr als 10 Kompressionsebenen aufweisen. Der in [Handl98] beschriebene so definierte Bereich erfüllt nicht die oben definierten Erfordernisse, deshalb wird ein breiterer Qualitätbereich zwischen 0 und 10000 vorgeschlagen, bei dem 0 die niedrigste Qualität und 10000 die höchste ist. Dieser Bereich sollte sowohl auf den Farbqualitätsbereich als auch den Gesamtqualitätsbereich angewendet werden. Da die Qualität der Chrominanzebenen eines einzelnen Rahmens für jeden Codec nicht relevant ist, sollte der Farbqualitätsbereich als optional angesehen werden.
  • Der folgende Abschnitt beschreibt einen SDPng-Erweiterungsvorschlag, der die oben dargelegten Erfordernisse berücksichtigt (der Einfachheit und Lesbarkeit wegen folgen wir in diesem Dokument der Konvention einer Anzeige von Zeichen wie „&" wie sie ist, anstelle der durch den XML-Standard erlassenen codeumgeschalteten (escaped) Version (das heißt „&amp;" für „&"). In diesem Kontext ist es die Aufgabe, modulare Erweiterungen zum SDPng 912 zu definieren. Diese kann durch Einführen eines Satzes neuer Abschnitte innerhalb des neuen Namenraums (namespace) „e2enp" gelöst werden. Die neuen Abschnitte können entweder als Teil einer neuen Version des SDPng 912 oder in einem als E2ENP 908 genannten separaten SDPng-912-Profil definiert werden, welches das in „XML Schema: Primer", „XML Schema: Structures" und „XML Schema: Datatypes" (W3C, 2001), im Folgenden als [XMLSC] bezeichnet, beschriebene korrespondierende XML-Schema enthält. Ein solches neues E2ENP-908-Profil würde somit einen Header wie den folgenden darstellen:
    Figure 01130001
  • XML-Beispiel 2
    • (In diesem Beispiel bedeuten beispielsweise: schema = Schema, target = Ziel, space = Raum, element = Element, form = Form, default = Vorgabe, qualified = qualifiziert, attribute = Attribut, unqualified = nicht qualifiziert, import = Importieren, location = Ort.)
  • In jedem Fall werden hierdurch gewisse Änderungen in dem – die Audiocodec- und RTP-Profile enthaltenden – derzeitigen SDPng-Vorschlag, definiert in „Session Description and Capability Negotiation" (IETF Internet Draft, work in progress, <draft-ietf-mmusic-sdpng-0.3.txt>) von D. Kutscher et al., im Folgenden als [SDPNG03] bezeichnet, vorgeschlagen. Wenn akzeptiert, würden diese Änderungen deshalb das ursprüngliche SDPng 912- (und Audio Codec- und RTP-Profile-) XML Schema beeinflussen.
  • Die Entscheidung, ob eine neue Version des SDPng 912 zu bewegen oder eine Erweiterung desselben zu definieren ist, wird zur Diskussion gestellt.
  • Der neue Namenraum „e2enp" soll im Wurzelelement des SDPng-Dokuments (das heißt im <desc>-Element) angezeigt werden.
  • Zu allererst führt dieser Vorschlag die Benutzung eines neuen SDPng-Abschnitts <e2enp:purpose> (purpose = Zweck) ein, um einen SDPng-Inhalt als mit speziellen E2ENP-908-Phasen eindeutig zu identifizieren, entsprechend den oben dargelegten Erfordernissen. Da gemeint ist, dass die SDPng-Information über SIP-910-Standardverfahren huckepack genommen wird, ermöglicht diese Vorgehendweise eine Erweiterung der Benutzungsmöglichkeiten des SIP 910 durch Definieren eines E2ENP-908-SDPng-basierten Metaprotokolls ohne Änderung der SIP-910-Semantik und -Grammatik.
  • Um außerdem die E2ENP-908-Merkmale zu forcieren definiert dieser Vorschlag (i) zwei andere neue SDPng-Abschnitte <e2enp:qoscfg> und <e2enp:qoscfg> und ermöglicht (ii) dass die verschiedenen resultierende Abschnitte des SDPng 912 vom SIP 910 (oder anderen Signalisierungssession-103-Protokollen) über Huckepack zu verschiedenen Zeiten und über verschiedene Verfahren entsprechend den verschiedenen E2ENP-908-Phasen unabhängig abgegeben werden.
  • Dieser Vorschlag führt kleine Änderungen beim SDPng-912-<cfg>-Abschnitt ein und stellt detaillierte Richtlinien darüber, wie die in diesem Abschnitt enthaltene Information mit den anderen neuen Abschnitten zu verbinden ist, bereit.
  • Dieser Vorschlag revidiert auch die SDPng-912-<constraints>-Abschnittssemantik (constraints = Beschränkungen), da der <e2enp:qoscfg>-Abschnitt eine Spezifizierung der QoS-Korrelation 804- und Zeitsynchronisation-805-Beschränkungen ermöglicht und schon die meisten der korrespondierenden Merkmale abdeckt.
  • Dieser Vorschlag versucht auf diese Weise soviel wie möglich modulare Erweiterungen des SDPng 912 zu definieren, um eine leichte Zusammenwirkung (interoperability) mit diese Erweiterungen nicht unterstützenden Anwendungen zu ermöglichen.
  • Das SIP 910 ist als ein Signalisierungssession-103-Protokoll zur Herstellung einer Kommunikation zwischen Peers definiert. Es zieht generell nur die Einleitung (initiation) der Verbindung in Betracht, wobei es die benutzungs- und/oder anwendungsspezifischen Merkmale beiseite lässt. Diese Merkmale werden mit den Mitteln des SDP oder SDPng 912 beschrieben.
  • In manchen Fällen ist es für die Anwendung notwendig, eine gewisse zusätzliche Information darüber zu haben, wie die über das SIP 910 abgegebene SDP/SDPng-Information zu behandeln ist, insbesondere in Betracht zu ziehen, dass von einer Anwendungsperspektive aus das Protokoll wie auf einem modularen Weg läuft. Der „modulare Weg (modular way)" erfüllt nicht immer die ACID-Charakteristiken (ACID = atomicity (Untrennbarkeit), consistency (Konsistenz), isolation (Isolation), durability (Dauerhaftigkeit)) von Transaktionen, was gleich ist, warum diese SIP-Prozedur NICHT generell als eine Transaktion betrachtet werden sollte.
  • Da das E2ENP 908 drei verschiedene Informationsaustausche zwischen Peers (nämlich die End-zu-End-QoS-Vorverhandlung-802-, End-zu-End-QoS-Vorverhandlung-806- und End-zu-End-QoS-Wiederverhandlung-808-Phase) benötigt, ist es notwendig, innerhalb des Protokolls die korrespondierenden Prozeduren zu differenzieren.
  • Das SDPng 912 kann die Signalisierung über den Typ von Phase, den Start/Stopp der gegebenen Phase und/oder den Ressourcenreservierungsstatus unabhängig vom SIP 910 (oder welches Signalisierungssession-103-Protokoll auch immer zum Huckepacknehmen der SDPng-Information benutzt wird) explizit übertragen. Bis zu diesem Grad soll ein SDPng-basiertes Metaprotokoll durch Einführen eines neuen SDPng-Abschnitts definiert werden, um am allerersten Anfang des SDPng-Inhalts als eine Form eines PDU-Headers in der gesamten E2ENP-bezogenen SDPng-Information präsent zu sein.
  • Das folgende Beispiel zeigt eine mögliche Instanzierung des <e2enp:purpose>-Abschnitts:
    Figure 01160001
    Figure 01170001
  • XML-Beispiel 3
    • (In diesem Beispiel bedeuten beispielsweise: purpose = Zweck, session = Session (Sitzung), user = Benutzer, id = Id, version = Version, nettype = Netztyp, addrtype = Adressetyp, addr = Adresse, expires = Abläufe, time = Zeit, use = Benutzung, description = Beschreibung, type = Typ, request = Anforderung, Aufforderung, Anfrage, pre-negotiation = Vorverhandlung, mode = Modus, push = schieben; die Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Das <session>-Element identifiziert die im verbleibendem Abschnitt des SDPng-Inhalts beschriebene gegebene E2ENP-908-Phase eindeutig. Die Definition des <session>-Elements basiert auf dem in [SDPng03] vorgeschlagenen <owner>-Element (owner = Eigner). Die Verhandlung und Benutzung kompakter Sessionsidentifizierer wird von <session> (beispielsweise über Hash) abgeleitet, um die Größe von E2ENP-PDUs zu beschränken. Das <session> (mit einem berechneten Hash) kann in der ersten PDU jeder gegebenen E2ENP-Phase oder Verkettung derselben benutzt werden.
  • Das <expires>-Kindelement zeigt an, wie lange die mit dem gegebenen <session>-Element korrespondierende SDPng- Information als gültig anzusehen ist. Beim Antworten dem Anbieter 810 soll jeder Antworter 811 einen Zeitgeber starten, der auf den im <expires>-Element spezifizierten Wert eingestellt ist. Sollte dieser Zeitgeber ablaufen, sollte der Antworter 811 die korrespondierende SDPng-Information in einen „Zombie"-Zustand bringen. Andererseits sollte der Anbieter 810 die gegebene SDPng-Information auffrischen, bevor der Zeitgeber abläuft.
  • Nur wenn keine sich auf diese SDPng-Information beziehenden Medien- oder Signalisierungssessionen 102/103 mehr existieren, kann der Anbieter 810 und/oder Antworter 811 die „Zombie"-Information still ablegen. Dieses Grundprinzip wird auch auf den Fall einer anderen SDPng-Information angewendet, die sich auf die gegebene obsolete SDPng-Information bezieht (siehe nächster Absatz): So lange jede gültige (das heißt nicht in einem „Zombie"-Zustand befindliche) SDPng-Information, die sich auf die gegebene „Zombie"-SDPng-Information bezieht, existiert, kann der Anbieter 810 und/oder Antworter 811 diese „Zombie"-SDPng-Information nicht still ablegen.
  • Die SDPng-Information, auf die sich das <Session>-Element bezieht, kann in anderen Fällen von SDPng-Inhalt benutzt werden, um sich auf SDPng-Inhalt-definierte Gegenstände zu beziehen. Dieser Mechanismus wird über das <use>-Element bereitgestellt, das die Erzeugung einer Liste von Referenzen zu bekannten vorexistierenden Fällen des <session>-Elements ermöglicht.
  • Beispielsweise soll der einen Fall der End-zu-End-QoS-Verhandlungsphase 806 für ein gegebenes Paar Peers beschreibende SDPng-Inhalt auf im Voraus vorverhandelte Information hinweisen, indem er im <use>-Konstrukt des <e2enp: purpose>-Anschnitts das eindeutige <session>-Element dieser vorverhandelten Information anzeigt. Diese Referenzierung wäre natürlich nicht notwendig (und folglich wäre das <use>-Element nicht vorhanden), sollte der SDPng-Inhalt relativ zu den zwei Phasen in einer einzelnen SIP-Mitteilung (das heißt im Fall von zeitlich nacheinander ausgeführten Phasen) gemeinschaftlich huckepack genommen werden.
  • Die Präsenz des <expires>-Kindelements in den aufgelisteten <session>-Elementen im <use>-Abschnitt ist nicht obligatorisch. Wenn vorhanden, würde, obgleich die Bedeutung von der normalen Benutzung des <expires>-Kindelements etwas differieren würde, seine Präsenz tatsächlich andeuten, für wie lange das gegebene referenzierte <session>-Element als gültig angesehen werden sollte (das heißt die Restzeit der Validität der E2ENP-Session), aus der Perspektive des <session>-Elements des es referenzierenden <session>-Elements. Natürlich kann ein gegebenes <session>-Element für ein Zeitfenster nicht länger als der ursprüngliche Wert der einspezifizierten Zeit des <expires>-Kindelements der referenzierten Sessionen 103 andere referenzieren.
  • Das <description>-Element zeigt die Natur der SDPng-Information an, auf die sich der gegebene <e2enp:purpose>-Abschnitt bezieht. Das „type"-, „name"- und „mode"-Attribut des <description>-Elements sind wie folgt definiert:
    Figure 01190001
    (type = Typ, request = Anforderung, Aufforderung, Anfrage, response = Antwort)
  • Das „type"-Attribut identifiziert, wer der Anbieter 810 und wer der Antworter 811 einer gegebenen E2ENP-908-Phase ist.
    Figure 01190002
    Figure 01200001
    (name = Name, standard = Standard, pre-negotiation = Vorverhandlung, negotiation = Verhandlung, re-negotiation = Neu- bzw. Wiederverhandlung, start = starte, reservation = Reservierung, ready = fertige, cancel = streichen, canceled = gestrichenen, expire = Ablauf, taken over = übernommen)
  • Das "name"-Attribut definiert den Typ der E2ENP-908-Phase, deren Beschreibung im verbleibenden Teil des SDPng-Inhalts enthalten ist:
    „Standard": Standardbenutzung der diesen E2ENP-908-Inhalt gemäß „SIP 910: Session Initiation Protocol", IETF SIP 910 Working Group, ACIRI, März 1999, work in progress, <draft-ietf-sip-rfc2543 bis -04.txt> von M. Handley et al., im Folgenden als [SIPBIS04] bezeichnet, huckpack nehmenden SIP-Mitteilung.
    „Pre-negotiation" 802: Die diesen E2ENP-908-Inhalt huckpack nehmende SIP-Mitteilung wird zum Ausführen der End-zu-End-QoS-Vorverhandlungsphase 802 benutzt.
    „Negotiation" 806: Die diesen E2ENP-908-Inhalt huckpack nehmende SIP-Mitteilung wird zum Ausführen der End-zu-End-QoS-Verhandlungsphase 806 benutzt.
    „Re-negotiation" 808: Die diesen E2ENP-908-Inhalt huckpack nehmende SIP-Mitteilung wird zum Ausführen der End-zu-End-QoS-Wiederverhandlungsphase 808 benutzt.
    „Start-Reservation": Die diesen E2ENP-908-Inhalt Huckpack nehmende SIP-Mitteilung wird zum Signalisieren des Starts eines Reservierungsprozesses (während entweder einer End-zu-End-QoS-Verhandlung- 806-Phase oder einer End-zu-End-QoS-Wiederverhandlungsphase 808) benutzt.
    „Ready-Reservation": Die diesen E2ENP-908-Inhalt huckpack nehmende SIP-Mitteilung wird zur Signalisierung der Vollendung eines Reservierungsprozesses (während entweder einer End-zu-End-QoS-Verhandlungsphase 806 oder einer End-zu-End-QoS-Wiederverhandlungsphase 808) benutzt.
    „Cancel-Reservation": Die diesen E2ENP-908-Inhalt huckpack nehmende SIP-Mitteilung wird zur Signalisierung der Anforderung zum Freigeben vorher reservierter Ressourcen benutzt.
    „Canceled-Reservation": Die diesen E2ENP-908-Inhalt Huckpack nehmende SIP-Mitteilung wird zur Bestätigung der Freigabe vorher reservierter Ressourcen benutzt.
    „Expire": Die dieses SDPng 912 huckpack nehmende SIP-Mitteilung wird zur Erzwingung des Ablaufs der durch das gegebene <session>-Element identifizierten SDPng-Information benutzt. Dem Kontext entsprechend soll die Attributzeit bzw. zugemessene Zeit des <expires>-Kindelements des gegebenen <session>-Elements auf null eingestellt sein. Wenn dieser Befehl benutzt wird, werden die das gegebene <session>-Element referenzierenden E2ENP-908-Inhalte gezwungen, entsprechend dem Grundprinzip freigegeben zu werden.
    „Taken-Over: Dieser Befehl wird vom Mediator 106a1 bei Drittpartei-unterstützten Verhandlungen 806 benutzt, um dem Peer, zu dem die Verhandlung 806 umgeleitet wird, mitzuteilen, dass eine solche Umleitung stattfindet.
  • Sollte eine gewisse Phase verkettet sein, würde das „name"-Attribut nur die späteste Phase anzeigen. Andere Definitionen des „name"-Elements könnten in Zukunft in Betracht gezogen werden.
  • Figure 01220001
  • Das "mode"-Attribut (Modus-Attribut) zeigt den Verhandlung-809-Modus an. Dieses Attribut wird nur angewendet, wenn das Attribut „name" auf „pre-negotiation" oder „negotiation" gesetzt ist. Die vorgegebenen Werte für das „type"-, „name"- und „mode"-Element sind jeweils „request", „standard" und „push".
  • Der <mediation>-Parameter ist optional und kann jeden der folgenden Werte annehmen:
    Figure 01220002
    (mediation = Mediation, Vermittlung, third-party assisted = Drittpartei-unterstützt, external negotiation = externe Verhandlung)
  • Wenn er nicht angewendet wird, ist der Typ der Verhandlung 806 einfach Peer-zu-Peer. Dieser Parameter wird benutzt, um anzuzeigen, dass ein Peer im Interesse von jemand anderem verhandelt. Dies würde auch über den Header „From" („Von") der SIP-Mitteilung und das Element <session> des <purpose>-Abschnitts implizit angezeigt. Die im Interesse von jemand anderem verhandelnden Peers sollten generell als Dienste wie vermittelnde Teile (mediating parts) eines Brokers, von Konferenzdurchführungsdiensten usw. angesehen werden. Der Mediator 106a1 benutzt die Parametervermittlung (parameter meditation), um die verhandelnden Parteien darüber zu informieren, dass er nicht die Partei ist, die zu senden und/oder empfangen beginnt, sondern gerade eine die Verhandlung 806 vermittelnde Partei ist. In diesem Fall sollte der Mediator 106a1 als Anzeige seiner Funktionalität „third-party-assisted" benutzen.
  • Immer beim Anmelden bei einem Netzwerkbetreiber (zur Einschaltzeit und immer wenn eine vertikale Übergabe stattfindet) validiert der Netzwerkbetreiber die (schon gegenüber Endgerätfähigkeiten abgestimmten) QoS-Präferenzen des Benutzers gegenüber den Netzwerkfähigkeiten.
  • Jedoch ist es zu dieser Zeit noch nicht möglich, vorherzusehen, ob und wann Fälle auftreten, bei denen zwei End-Peers keine Chance haben, auf einem gemeinsamen Satz von welchen QoS-Verträgen auch immer übereinzukommen. In solchen Fällen ist es eine typischerweise angenommene Lösung, Umcodierungseinheiten entlang dem Datenpfad einzusetzen.
  • Es wird die Möglichkeit zum Verkoppeln solcher Einheiten mit SIP-Proxis und Verzeichnis- bzw. Direktorydiensten ins Auge gefasst, um den Anbieter zu zwingen, einen speziellen Codeumsetzer oder eine Kette davon zu benutzen.
  • Immer wenn die E2ENP-Session zwischen den zwei End-Peers ausfällt, könnte der Anbieter versuchen, den Netzwerkbetreiber oder irgendeinen anderen Dienstprovider um Unterstützung zur Bereitstellung von Umcodierungsdiensten zu bitten.
  • Dies bedeutet, über einen Direktorydienst irgendeine oder mehrere zur Verfügung stehende Umcodierungseinheiten zu entdecken, welche die gegebenen Erfordernisse des Anbieters und Fähigkeiten des Antworters erfüllt bzw. erfüllen, und eine Drittpartei-Verhandlung zwischen dem Anbieter, den verschiedenen Umcodierern in der Mitte und dem Antworter zu managen (verwalten). Der Umcodierungsdienst würde deshalb das E2ENP analog zu dem benutzen, was heute MEGACO („media Gateway Control (MEGACO)", http://www.ietf.org/htal.charters/megaco-charter.html, im Folgenden als [MEGACO] bezeichnet, tut. Der Umcodierungsdienst (transcoding service) würde die Paarung von Knoten in der Kette von Peers orchestrieren und darauf achten, dass Ressourcen über das E2ENP-Ökonomieprinzip richtig reserviert werden (eine ähnliche Betrachtung gilt für Ressourcenfreigabe).
  • Sollte die Verbindung zwischen den zwei End-Benutzern mehrfache administrative Domänen und/oder Technologien bzw. Techniken umfassen, kann es auch möglich sein, dass von verschiedenen Providern angebotene Umcodierungsdienste kooperieren, wieder durch Benutzung des E2ENP zur Ausführung einer Drittparteiverhandlung.
  • Bis zu diesem Grad beschreibt „external-negotiation" den Fall, in welchem der Mediator 106a1 im Interesse einer Entität, die zu erzwingen versucht, dass zwei Peers das E2ENP zwischen sich aus führen, als eine externe Drittpartei agiert. Der oben angedeutete Umcodierungsdienst würde einen oder mehrere solche „externen Mediatoren" bzw. „externen Vermittler nacheinander steuern.
  • Die Idee einer die Herstellung eines Pfades zwischen mehreren Verarbeitungseinheiten kontrollierenden externen Funktionalität ist in der Literatur wohlbekannt (beispielsweise Z. M. Mao, R. Katz „Achieving Service Portability in ICEBERG", in Proc. Of IEEE 00 Clobe-comm Workshop "2000 IEEE Service Portability and Virtual Customer Enviroments", IEEE, Dezember 2000). Die Aufgabe der hier vorgeschlagenen Lösung ist infolgedessen, eine Erweiterung des Rahmens des E2ENP-Protokolls auf komplexe Fälle zu ermöglichen und dadurch Zwischenkomponenten wie Umcodierer zu erfordern. Bis zu diesem Grad wird das Konzept einer Vielfalt von externen E2ENP-Mediatoren bzw. -Vermittler, die vom Umcodierungsdienstkern kontrolliert werden, als eine von dieser Erfindung vorgeschlagene Neuheit angesehen.
  • Das <mediation>-Element kann eine weitere Entwicklung in Bezug auf zusätzliche Werte, die von den oben beschriebenen verschieden sind, erfahren. Wenn eine aktive Teilnahme des Mediators 106a1 beim Datenmedienstreaming in Betracht gezogen werden soll, oder wenn mehr als eine Mediationskomponente bei der Verhandlung 806 auftreten sollte, beispielsweise eine Involvierung von Conference Control Units (Konferenzkontrolleinheiten), QoS-Broker usw., würde dies über das <mediation>-Element angezeigt. Das folgende Beispiel korrespondiert mit der Startmitteilung einer SIP-Session in der E2ENP-Session zwischen dem Mediator 106a1 und dem künftigen Antworter 106a2:
    Figure 01250001
  • XML-Beispiel 4
    • (invite = auffordern, einladen, from = von, to = zu, content = Inhalt, application = Anwendung, negotiation = Verhandlung, mediation = Mediation third-party assisted = Drittpartei-unterstützt; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Gemäß diesem Beispiel würde der Peer mary fix@195.37.78.173 erkennen, dass der Peer
    „mary moby@3ffe:1200:3012:c006:290:27ff:fe7d:d024"
    gerade ein Mediator 106a1 für den Peer
    „43.196.180.1"
    ist, dessen Eigner „Kate" ist.
  • Die in [SIPBIS04] beschriebene SIP-Antwort „380 Alternative Service" (380 alternativer Dienst) könnte nicht nur dazu, einem Dienst, der den Anruf derzeit nicht machen kann, einen redundanten Dienst anzuzeigen, sondern auch zum Umleiten einer Verbindung zu einem anderen Gerät benutzt werden, wenn der angerufene Peer keine Fähigkeiten hat, den Anruf zu behandeln, aber Vorteil aus der Benutzung gewisser Zuteilungs- und Präsenzdienste zum Detektieren eines anderen Peers in seiner Nähe, der den Anruf behandeln kann, zu ziehen. Der Prozess einer Zuteilung von Geräten und Diensten ist außerhalb des Schutzbereichs der zugrundeliegenden Erfindung, aber es könnten generell existierende Technologien bzw. Techniken wie das in Specification of the Bluetooth System Version 1.1 (http://www.bluetooth.com/files/Bluetooth 11 Specifications Book.pdf), im Folgenden als [BLUE] bezeichnet, beschriebene Bluetooth und das in „SIP 910 Extensions for Presence" (SIMPLE Working Group, work in progress, <draft-rosenberg-impp-presence-01.text>) von J. Rosenberg et al., im Folgenden als [SIPPRE01] bezeichnet, SIP 910 support for presence (SIP 910-Unterstützung für Präsenz) in Betracht gezogen werden.
  • Gemäß [SIPBIS04] sind die alternativen Dienste in „in the message body of the response" (im Mitteilungskörper bzw. -hauptteil der Antwort) beschrieben. Eine mögliche SDPng-912-Struktur, welche die Adresse und die Referenz zu den Profileinstellungen eines alternativen Dienstes beschreibt, ist unten gezeigt:
    Figure 01270001
  • XML-Beispiel 5
    • (alternative = alternativ, service = Dienst, , my-funny-service = mein-lustiger-Dienst, protocol = Protokoll, address = Adresse,; bezüglich der Bedeutung der übrigen englischen Wörter: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Wobei
    TYPE TYPE = "Standard"|"mediation", mit – "standard" – Standardbenutzung wie in [SIPBIS04] definiert, und – „mediation" – für Mediationszwecke.
    SIP_ADDRESS mit der Bildung von in [SIPBIS04] definierten, SIP-konformen Adressen korrespondiert, und
    SIP-VERSION mit der in [SIPBIS04] definierten, SIPkonformen Syntax des SIP 910 korrespondiert.
  • Der Abschnitt <service> wird zum Beschreiben des alternativen Dienstes benutzt, bezieht sich auf schon bekannte E2ENP-Mitteilungssessionbeschreibungen 112 oder wird in ihnen ausgeführt. Viele dieser ausgeführten Beschreibungen starten mit einem <purpose>-Abschnitt. Dadurch kann der Abschnitt <service> wiederholt werden.
  • Im Fall einer Mediation können die mehreren <service>-Abschnitte das gleiche <service-id> aufweisen aber verschiedene Sessionsbeschreibungen adressieren, da der Mediator 106a1 sowohl den Anbieter 106b als auch den zukünftigen Antworter 106a2 über die korrespondierenden Verhandlungen, die der Mediator 106a1 einerseits mit dem Anbieter 106b und andererseits mit dem zukünftigen Antworter 106a2 führt, ohne Adressierung unbekannter Information, wie sie in den Erfordernissen für den Mediator (Vermittler) beschrieben ist, informiert.
  • Wenn die Benutzung Standard gemäß [SIPBIS04] ist, beschreiben die mehreren <service>-Abschnitte mehrere alternative Dienste.
  • Die derzeitige Beschreibung des Abschnitts <alternative-service> ist nur im Sinn des E2ENP und der vermittelten Verhandlung. Eine zusätzliche Beschreibung der Benutzung von <alternative-service> in dem durch [SIPBIS04] beschriebenen Sinn würde in Zukunft in Betracht gezogen, wenn SIP-fähige Dienste berücksichtigt werden.
  • Figure 01280001
  • Figure 01290001
  • XML-Beispiel 6
    • (bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Gemäß den Erfordernissen des Mediators 106a1 ist es nicht erlaubt, Verweise auf unbekannte Sessionen zu benutzen. Das ist es, warum durch Implementieren eines Mediators bzw. Vermittlers das <use>-Element eines <purpose>-Abschnitts in einer betreffenden Session von einem <service>-Abschnitt wie beim obigen Beispiel fortgelassen sein sollte. Der Mediator sollte dann für das Sammeln der ganzen betreffenden Information sorgen und sie explizit (keine Referenzen) in die laufende(n) Beschreibung(en) setzen.
  • 10 zeigt ein Beispiel, das die Benutzung des <e2enp: alternative-service>-Abschnitts zeigt.
  • Die Anzeige der Adresse und Version in der dritten Mitteilung im <service-id>-Element kann direkt vom Anbieter 106b (Kate's Gerät) zum Erzeugen des neuen SIP 910-Anrufs beim neuen Antworter 106a2 (Mary's Heimendgerät) benutzt werden. Diese Information ist speziell in Fällen notwendig, bei denen der Anbieter 106b nichts über das mobile Gerät, wo der Anruf umgeleitet wird, weiß.
  • Verglichen mit dem existierenden SDPng-Vorschlag [SDPNG03] wird hierdurch vorgeschlagen, Codecdefinitionen von RTP-Payloaddefinitionen und Cokecparameterisierung zu unterscheiden. Zur Cokecparameterisierung beabsichtigen wir hierdurch die Liste von die Definition eines gegebenen Codec begleitenden Parametern, beispielsweise die Abtastrate und die Anzahl von Kanälen im Fall von Audiocodec. Dies resultiert in der Definition eines neuen SDPng-Abschnitts und der Neudefinition der Audio Codec- und RTP-Profile.
  • Mit dieser Annahme können sich Verhandlungsparteien durch zuerst entfernen aller Codecs, die nicht von allen Peers unterstützt werden, Übereinkommen schnell nähern. Wenn einmal der gemeinsam vereinbarte Satz von Codecs identifiziert worden ist, können die Verhandlungsparteien, als ein weiterer Schritt, die Verhandlung 806 von Payloadtypen und Codecparameterisierungen behandeln. Die Definition von Payloadtypen ist in [RTP-Profile] beschrieben, und das RTP-Profil ist in [SDPNG03] definiert.
  • In Bezug auf die Audiocodecs sind statische Payloadtypen mit in [RTP-Profile] definierten festen Codecparameterisierungen assoziiert. Deshalb ist nur für dynamische Payloadtypen eine detaillierte Spezifikation einer Codecparameterisierung erforderlich. Deshalb schlagen wir die Benutzung des in [SDPNG03] beschriebenen Inline-Formats (inline format) vor.
  • Was Videocodecs betrifft, so ist die in [RTP-Profile] angedeutete Parameterisierung zur vollen Charakterisierung des gegebenen Codec von einer QoS-Perspektive aus nicht ausreichend. Zwei mögliche Lösungen werden ins Auge gefasst:
    • 1. Vorverhandeln der Namen, Payloadtypen und (teilweise) Parameterisierungen von Codecs vor jeder Benutzer-spezifischen Vorverhandlung 802. Dies bedeutet ein Aufspalten der End-zu-End-QoS-Vorverhandlung-802-Phase in zwei unterschiedliche Teilphasen: In einer frühen Stufe würde nur eine Vorverhandlung 802 von Endgerät-verbundener Information stattfinden; auf diese Teilphase würden dann eine oder mehrere Benutzer-spezifische Vorverhandlung-802-Teilphasen folgen, die Benutzerprofilinformation zu späteren Zeiten wirksam einsetzen, wobei jede dieser späteren Teilphasen Benutzerprofilinformation auf die Resultate der früheren Teilphase abbilden würde. Der Grund zur Vorverhandlung auch einer Codecparameterisierung bei der Endgerät-verbundenen Vorverhandlungs-802-Teilphase stammt von der Tatsache, dass die Verhandlungsparteien den Bereich möglicher Konfigurationen von Videocodecs herabverengen (narrow down) wollen, um Durchführbarkeitserfordernissen in Bezug auf die tatsächliche Menge von Hardware/Software-Ressourcen der gegebenen Peers zu erfüllen.
    • 2. Alternativ dazu, bestimmen, welche Teilmengen (subsets) des Benutzerprofils zu den gegebenen Fähigkeiten und der (potentiellen) Menge lokaler Ressourcen passen, und nur diese Teilmengen zusammen mit Codecnamen und den Payloadtypen mit Peers verhandeln.
  • Die beiden Alternativen sind in dem in 11 gezeigten Diagramm dargestellt. Im Fall einer Verhandlung nur von Codecs ist die „Benutzerebene-QoS" nicht existent, und der „QoS Contracts Sketch" ( QoS-Verträgeentwurf) ist gleich der „System Configuration File" (Systemkonfigurationsdatei). Es würden in einem solchen Fall jeweils nur die Systemfähigkeiten validiert. Diesem Grundprinzip zufolge können Anwendungen auf einfachere Weise gestaltet werden: entweder sie behandeln Codecparameterisierungsverhandlungen 806 in einer früheren Teilphase oder sie behandeln einfach die Verhandlung 806 der Benutzer-spezifischen QoS-Spezifikation.
  • Die Benutzerbeschreibungen können in Universalfähigkeitsbeschreibungen, die Peers zwischen sich offline vorverhandeln können, assimiliert werden. Vorverhandelte Information kann sich auch auf in [SDPNG03] beschriebene SDPng-902-Profile beziehen oder in diese integriert sein.
  • Außerdem sollen in die ursprünglichen SDPng-912-Codecparameterisierung Intervalle eingebracht werden, um die Zahl von zu verhandelnden Gegenständen zu reduzieren. Diese Lösung ermöglicht auch eine Definition von Adaptierungspfaden auf intuitive Weise sowie eine Vermeidung von Zweideutigkeiten, speziell in Bezug auf eine Videomedienstrom-206-Charakterisierung.
  • Ein neuer SDPng-912-<e2enp:qosdef>-Abschnitt stellt Mittel zum Ausdrücken sowohl von Fähigkeiten als auch Stromebene-QoS-Verträgen 1108 auf modulare Weise bereit:
    • – Eine Instanz des mit dem auf „capabilities" gesetzten Attributs „name" qualifizierten <e2enp:qosdef>-Abschnitts beschreibt nur die Endgerät-verbundene Information betreffend Fähigkeiten, während
    • – eine Instanz des mit dem auf „contrakts" gesetzten Attribut „name" qualifizierten <e2enp: qosdef>-Abschnitts die verschiedenen Parameterisierungen dieser Fähigkeiten, die zur gegebenen Benutzerprofilinformation in Form von Stromebene-QoS-Verträgen 1108 passen, beschreibt.
  • Die Anwendung und/oder Midleware wählt den besten Codec aus dem vorverhandelten <e2enp: qosdef name=„capabilities"> und eine Teilmenge von QoS-Verträgen 1108 aus der gegebenen Benautzerprofilinformation aus. Die resultierende Information (eine Teilmenge des Kreuzprodukts aus dem <e2enp:qosdef name=„capabilities"> und der Benutzerprofilinformation) bildet dann den <e2enp:qosdef name=„contracts">-Abschnitt, der die Stromebene QoS-Verträge 1108 auf Anwendungsebene behandelt. Dieser neue Abschnitt unterscheidet sich von der in der Benutzerprofilinformation enthaltenden ursprünglichen Information insoweit, als nun spezielle Codierungsattribute spezifiziert sind. Dieser <e2enp:qosdef name=„contracts">-Abschnitt wird dann zwischen Peers während der Vorverhandlung-802-Phase ausgetauscht. 11 zeigt ein Szenario 1100, bei dem QoS-Verträge 1108 aus Benutzerprofil- und Systemkonfigurationsinformation abgeleitet werden. Danach werden sie validiert.
  • Die Vorverhandlung 802 der zwei Typen von <e2enp:qosdef>-Abschnitte kann zwischen Peers zu verschiedenen Zeiten stattfinden, ungeachtet der späteren tatsächlichen Benutzung, und in der Zeit mit unterschiedlichen Zeitskalen eingestellt werden, durch Benutzung des <expires>-Elements des mit dem gegebenen <e2enp:qosdef>-Abschnitt assoziierten Zweckabschnitts (purpose section). Die Beschränkung der E2ENP-908-Informationsvalidität in der Zeit ist notwendig, um eine Benutzung obsoleter Information zu späterer Zeit zu vermeiden.
  • Der <e2enp:qsdef name=„capabilities">-Abschnitt ermöglicht Peers, über eine gemeinsame Teilmenge von während späterer Mediensessionen 102 zu verhandelnder Fähigkeiten übereinzukommen. Dieser Abschnitt agiert als ein Behälter von zwei Klassen von Elementen, Codecdefinitionen und Payloadtypdefinitionen, die auf jeden Typ von Medien (Audio, Video, usw.) angewendet werden. Definitionen aus den ursprünglichen Audiocodec-, RTP- und VideoCodec-Profilen, die in [SDPng03] spezifiziert sind, werden ins Auge gefasst, um benutzt zu werden, jedoch mit gewissen Erweiterungen, wie sie unten angedeutet sind.
  • Figure 01340001
  • Figure 01350001
  • XML-Beispiel 7
    • (capabilities = Fähigkeiten, codec = Codec, scope = Geltungsbereich, applicable = anwendbar, possible = möglich, format = Format; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Der Einfachheit halber zeigt dieses Beispiel die Definition von Videocodecs sowohl mit als auch ohne Codecparameterisierung. Andernfalls soll der <e2enp:qosdef name=„capabilities">-Abschnitt entweder eine Codecparameterisierung enthalten oder keine von ihnen enthalten.
  • Man kann leicht feststelln, dass die in diesem Abschnitt transportierte Information jetzt äquivalent zu einer Art von Konfigurationsdatei des Endgeräts des Benutzers ist; diese Information ist benutzerunabhängig und folglich komplementär zu dem in der Benutzerprofilinformation beschriebenen Inhalt der Benutzerprofilinformation sowie zu dem Stromebene-QoS-Verträge 1108 behandelnden Inhalt des <e2enp:qosdef>-Abschnitts (abgeleitet von der Benutzerprofilinformation) ist.
  • Das Attribut „scope" zeigt in einer Anforderung (Verhandlungsangebot (negotiation bid)) an, ob das korrespondierende SDPng-912-Element als eine erforderliche (applicable) oder gewünschte (possible) Option anzusehen ist, während in einer Antwort (Verhandlungsgegenangebot (negotiation counteroffer) dieses Attribut anzeigt, ob das korrespondierende SDPng-912-Element validiert (applicable (anwendbar)) oder zurückgewiesen (not applicable (nicht anwendbar)) worden ist.
  • Figure 01360001
  • Der Antworter 811 kann auch im Gegenangebot anzeigen, welche Fähigkeiten und bis zu welchem Umfang er unterstützen kann. Wenn eine gegebene Fähigkeit so unterstützt wird „wie sie ist", wird nur der korrespondierende Identifizierer zusammen mit dem auf „applicable" eingestellten Scope-Attribut angezeigt. Wenn eine gegebene Fähigkeit nicht unterstützt wird, wird der korrespondierende Identifizierer einfach fortgelassen.
  • Wenn der Antworter 811 im Gegenangebot eine modifizierte Version der Parameterisierung einer gegebenen Fähigkeit im <e2enp:qosdef name=„capabilities">-Anschnitt (als eine Teilmenge des ursprünglichen Angebots) vorschlägt, wird die ganze Beschreibung mit den Aktualisierungen bei beiden Typen der <e2enp:qosdef>-Abschnitte retourniert. In jedem Fall enthält der Stromebene-QoS-Verträge 1108 behandelnde <e2enp:qosdef>-Abschnitt in einer Antwort nur aktualisierte Codecparameterisierungen.
  • Außerdem kann der Antworter 811 eine (dem Anbieter 810 zur Vorverhandlung-802-Zeit unbekannte) neue Option anzeigen: Diese wird als „possible" markiert. Die Idee ist, dass der Anbieter 810 auf diese Weise von einer möglichen Option, die eventuell später benutzt werden könnte, sollte der Anbieter 810 mit zu dieser Option passender neuer Fähigkeit aktualisiert sein, informiert werden kann.
  • Beispielsweise kann der Antworter 811 die Unterstützung eines Codec anzeigen, den der Anbieter 810 gegenwärtig nicht unterstützt. Sollte der Anbieter 810 diesen gegebenen Codec irgendwie akquirieren (beispielsweise durch Herunterladen einer Softwarekomponente), könnte der Anbieter 810 dann seine Grundsätze aktualisieren, um diese neue Fähigkeit zu berücksichtigen.
  • Der Wert „possible" könnte auch den Zustand des Antworters 811 als in Bezug auf einen vom Anbieter 810 vorgeschlagenen Codec teilweise beschäftigt anzeigen. Auf diese Weise kann der Antworter 811 seine gegenwärtige Arbeitsbelastung berücksichtigen. Dies könnte beispielsweise in eine Antwort an den Anbieter 810 umgesetzt werden, die anzeigt, dass der Antworter 811 generell eine hohe Kapazität hat, dass jedoch im Moment nur ein Teil davon zur Verfügung steht. Der Anbieter 810 kann dann diese Information für künftige Wiederverhandlungen 808 speichern bzw. sichern, immer wenn er versucht, die Verbindung zum Arbeiten auf einer anderen QoS-Ebene zu aktualisieren.
  • Sollte eine Fähigkeit entfernt oder zu einer späteren Zeit rekonfiguriert werden, würde eine neue Instanz des korrespondierenden <e2enp:qosdef name=„capabilities">-Vorverhandlung-802-Prozesses zwischen Peers stattfinden, um proaktiv und rechtzeitig Information über die gegebene Änderung zu verbreiten, so dass Peers richtige Adaptierungsstrategien anwenden können.
  • Sollte der Antworter 811 eine Fähigkeit als „possible" hinzufügen, würde die korrespondierende Parameterisierung direkt in den <e2enp:qosdef name=capabilities"> Abschnitt in dem mit dieser neuen Fähigkeit korrespondierenden Element zurückgebracht. In diesem Fall zeigt die Parameterisierung einfach Konfigurationsinformation relativ zu dieser Fähigkeit an. Sollte der Anbieter 810 mit dieser Extrafähigkeit zu späterer Zeit aktualisiert werden, könnte der Anbieter 810 gewisse Verträge 1108 aus der Konfigurationsinformation zum Laufen lassen einer neuen Runde des Vorverhandlung-802-Prozesses ziehen bzw. zeichnen.
  • Peers können auch auf den oben beschriebenen Prozess folgende Fähigkeiten zu jeder Zeit neu bzw. wiederverhandeln, um einander über jede Änderung in der Fähigkeitenverfügbarkeit zu informieren.
  • Mit dem obigen Beispiel fortfahrend präsentiert das folgende Codefragment ein Beispiel einer Codecparameterisierung im neuen <e2enp:qosdef name=„contracts">-Abschnitt, wie er von einem im vorhergehenden Abschnitt beschriebenen Abbildungsprozess abgeleitet wird. Dieser Abschnitt behandelt Anwendungsebene-QoS-Verträge 1108, die generell auf jeden Medienstrom 206 des Typs identifizierter Medien anwendbar sind.
  • Dieser neue Abschnitt enthält eine Anzahl komplexer XML-Elemente:
    • – Ein obligatorisches <policy>-Element, das zur Verhandlung des Ressourcenmanagementgrundsatzes zum Forcieren benutzt wird;
    • – höchstens einen Fall jedes der folgenden Elemente: -- <audio>: Beschreibt alle Qos-Verträge 1108 für Audiomedienströme 206, -- <video>: Beschreibt alle QoS-Verträge 1108 für Videomedienströme 206, -- <data>: Beschreibt alle QoS-Verträge 1108 für Datenmedienströme 206, -- <control>: Beschreibt alle QoS-Verträge 1108 für Kontroll- bzw. Steuermedienströme 206,
    wobei solche QoS-Verträge 1108 von der Abbildung von Benutzerprofilinformation auf Fähigkeiten abgeleitet werden. Wenigstens eines dieser Elemente sei präsentiert:
    Figure 01390001
    Figure 01400001
    Figure 01410001
    Figure 01420001
  • XML-Beispiel 8
    • (contracts = Verträge, policy = Grundsatz, let us optimize = lasst uns optimieren, memory = Speicher, predicate = Prädikat, first-term = erster Term bzw. Ausdruck usage = Benutzung, second-term = Zweiter Term bzw. Ausdruck, function = Funktion, and = und, load = Last, or = oder, criterion = Kriterium, expression = Ausdruck, contract = Vertrag, spare = Reserve, map = Abbildung, role = Rolle, receiver = Empfänger; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Die Beschreibung des „color-quality-range" und des „overall-quality-range" ist oben eingeführt. In diesem Fall bedeutet „frame-rate-set" = „10, 15", dass der Empfänger höchstens 15 Fr/s und mindestens 10 Fr/s decodieren können sollte. Jede in weniger als 10 Fr/s resultierende Decodierung wird als eine Verletzung des Vertrags 1108 angesehen. Der Sender braucht nicht mehr als 15 Fr/s bereitstellen, wenn sich nicht ein Vertrag ändert, beispielsweise weil die Entdeckung von mehr Ressourcen auf der Empfängerseite und eine Anforderung (request) für eine Vertragsänderung gemacht wird.
  • Das <policy>-Element transportiert den Typ von zu verhandelnden Grundsätzen. Das „name"-Attribut stellt eine durch den Menschen lesbare Beschreibung des Grundsatzes (policy) bereit. Das optionale <predicate>-Kindelement erlaubt das Ausdrücken eines Boolschen Prädikats, das zwei Terme involviert, wobei jedes aus dem folgenden Satz (Menge) gezogen wird:
    • – „optMemoryUsage" – zeigt den Speicherbenutzungs-Optimierungsgrundsatz an.
    • – „optNetworkPerformance" – zeigt den Netzwerk-604-Performance-Optimierungsgrundsatz an.
    • – „optPowerConsumption" – zeigt den Energieverbrauch-Optimierungsgrundsatz an.
    • – „optCpuLoad" – zeigt den CPU-Belastungs-Optimierungsgrundsatz an.
  • In der Zukunft können mit anderen Grundsätzen korrespondierende zusätzliche Werte hinzugefügt werden.
  • Alternativ dazu kann der Wert der Prädikatterme aus dem Satz (Menge) anderer Fälle des <predicate>-Elements gezogen werden. Der Typ der Boolschen Funktion wird über das „function"-Attribut angezeigt, das jeden Wert aus dem Satz „and" und „or" annehmen kann. Die „not"-Funktion (nicht-Funktion) wird nicht benutzt, da die Abwesenheit eines Grundsatzes implizit anzeigt, dass ein solcher Grundsatz nicht benutzt wird. Das <predicate>-Kindelement ermöglicht auf diese Weise, Kombinationen der oben aufgelisteten elementaren Grundsätze zu spezifizieren. Diese Kombinationen zeigen spezielle Korrelationen zwischen verschiedenen Grundsätzen an.
  • Das <criterion>-Kindelement identifiziert einen gegebenen Grundsatz über das „type"-Attribut, das jeden Wert aus dem oben angedeuteten Satz annehmen kann. Außerdem kann eine Instanz dieses Elements eine Instanz des <predicate>-Elements durch Spezifizieren der Kette bzw. der Zeichenfolge „expression" als Wert des Attributs „type" und durch Benutzung eines eine gegebenen Instanz des <predicate>-Elements identifizierenden zusätzlichen Attributs „idref" forcieren. Das <criterion>-Kindelement ist obligatorisch, und es kann nur eine Instanz von ihm in einem gegebenen Fall des <policy>-Elements erscheinen.
  • Das <contract>-Element stellt das Resultat des Kreuzproduktprozesses dar. Diese zu den verfügbaren Fähigkeiten passenden Anwendungsebene-QoS-Erfordernisse eines Benutzers 1101 werden hierdurch von der Benutzerprofilinformation des Benutzers 1101 kopiert und zwischen Peers verhandelt. Es kann deshalb resultieren, dass am Ende des Verhandlung-806-Prozesses die ursprünglichen Anwendungsebene-QoS-Erfordernisen des Benutzers 1101 auf eine Teilmenge von ihnen eingeschränkt werden.
  • In Bezug auf die oben dargelegten Erfordernisen und das Konzept des Reservevertrags wird hierdurch das <spare>-Kindelement des <contract>-Elements eingeführt, um die Reserveverträge (spare contracts), die vom bevorzugten Netzwerkprovider der gegebenen Benutzer nicht unterstützt werden, anzuzeigen.
  • Das <spare>-Kindelement wäre dann ein optionales Element, und seine Präsenz zeigt an, dass der gegebene Vertrag 1108 vom bevorzugten Netzwerk-604-Betreiber des Anbieters 810 nicht unterstützt wird. Der Antworter 811 filtert auf ähnliche Weise die nicht als Nichtreserve angezeigten auf der Basis ihrer/seiner Übereinkommen mit ihrem/seinem bevorzugten Netzwerk-604-Betreiber aus.
  • Wenn eine vertikale Übergabe stattfindet, kann jede Partei versuchen, alle ihre/seine Verträge 1108 einschließlich der Reserveverträge, die eventuell in Bezug auf den neuen Netzwerkprovider anwendbar werden, validieren.
  • Das <rtp:map>-Element ist als eine Erweiterung des SDPng 912 RTP-Profile [SDPNG03] vorgeschlagen, um die Assoziation gegebener Anwendungsebene-QoS-Verträge 1108 mit einem speziellen Format darzustellen. Der Payloadtyp wird durch das „format"-Attribut dargestellt, welches Instanzen des „name"-Attributs des <rtp:pt>-Elements referenziert.
  • Das Attribut „contract" identifiziert die assoziierte Anwendungsebene-QoS durch Referenzieren von Instanzen des „name"-Attributs des <contract>-Elements.
  • Das Attribut „role" zeigt an, ob das gegebene Assoziationsanwendungsebene-QoS-Vertrag/Strom-Format von einem Empfänger, einem Sender oder einem Sender/Empfänger entsprechend den oben dargelegten Erfordernissen vorgeschlagen wird. Auf diese Weise können nicht nur Empfänger, sondern auch Sender Proaktivinformation, die später zum Entscheiden, wie Wiederverhandlungen 808 auf der Basis von APs zu behandeln sind, verbreiten.
  • Die Konzepte der QoS-Kontext- und Medienstrom-206-Gruppierung (und insbesondere -Assoziation) kann durch Einführen eines neuen Abschnitts <e2enp:qoscfg> als eine Hinzufügung zum <cfg>-Abschnitt modelliert werden. Insbesondere enthält der <e2enp:qoscfg>-Abschnitt eine Adaptierungspfadbeschreibung (AP-Beschreibung) für einen gegebenen Medienstrom 206 sowie die Definitionen von Assoziationen (oder allgemeiner Gruppierungen) davon. QoS-Verträge 1108 höherer Ebene, die QoS-Korrelation-804- und Zeitsynchronisation-805-Beschränkungen zwischen verschiedenen Gruppen von Medienströmen sowie von APs (höherer Ebene) von ihnen erfassen, können auch mit diesem neuen Abschnitt spezifiziert werden.
  • Die im <e2enp:qoscfg>-Abschnitt enthaltene Information kann entweder zwischen Peers, ungeachtet einer späteren tatsächlichen Benutzung, vorverhandelt oder bei der Verbindungsherstellungszeit verhandelt werden.
  • Im Kontext der E2ENP-908-Idee muss der Geltungsbereich des ursprünglichen SDPng-<cfg>-Abschnitts klargestellt werden: Der <cfg>-Abschnitt definiert einfach die Abbildung von Formaten (beispielsweise RTP-Payloadtypen) mit transportbezogener Information, während die volle Definition von APs (in Form der Fähigkeiten und der QoS-Verträge 1108, die in den <e2enp:qosdef>-Abschnitten definiert sind) vom neuen <e2enp:qoscfg>-Abschnitt vollständig unterstützt wird.
  • Der einzige Unterschied zwischen diesem Vorschlag und [SDPNG03] ist die Einführung zusätzlicher Attribute in das <rtp:session>-Element zum Spezifizieren, welcher Typ von Netzwerk 604 und seine Version benutzt wird (das „nettype"- bzw. „addrtype"-Attribut). Diese Änderung beeinflusst das SDPng-912-RTP-Profile [SDPNG03] ebenso. Außerdem werden die Adressen durch Benutzung der in „Support for IPv6 in SDP" (IETF Internet Draft, work in progress, <draft-olson-sdp-ipv6-02.txt>) von S. Olson, G. Camarillo und A. Roach, im Folgenden als [Olson01] bezeichnet, für das SDP vorgeschlagenen Syntax ausgedrückt. Die vorgeschlagenen SDPng-912-Erweiterungen für den <cfg>-Abschnitt sind in dem nachstehenden Beispiel fett angedeutet.
  • Figure 01460001
  • Figure 01470001
  • Figure 01480001
  • XML-Beispiel 9
    • (component = Komponente, stream = Strom, Stream, media = Medien, alt = alternativ, port = Port, Anschluss; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Es sei auf die Benutzung des <cfg>-Abschnitts zum Spezifizieren eines gegebenen Adresse/Port-Paares als mit zwei verschiedenen Payloadtypen, deren Wahl davon abhängt, welcher QoS-Vertrag 1108 (aus dem <e2enp: qoscfg>-Abschnitt) entsprechend AP-Regeln und den im <rtp:map>-Element des <e2enp:qosdef name="contracts">-Abschnitts forciert wird, assoziiert hingewiesen.
  • Der Unterschied zwischen diesem Vorschlag und dem überkommenen SDP und SDPng 912 besteht darin, dass das letztere nicht primär auf QoS-Verhandlung 806, sondern auf Fähigkeitsverhandlung 806 fokussiert. Dies bedeutet, dass das SDP/SDPng 912 einem Sender erlaubt, dem oder den Empfängern Information über Format und Transportinformation, die der Sender zum Senden zu benutzen beabsichtigt, gibt.
  • Beim Versuch, das E2ENP 908 an diese wohlbekannte Lösung anzupassen, sollte man beachten, dass in der End-zu-End-QoS-Vorverhandlungsphase 802 eine Ausscherfähigkeitsverhandlung 806 schon berücksichtigt ist. Tatsächlich kann die Vorverhandlung-802-Phase generell als zur Anzeige von Nurstromebene-QoS-Verträgen 1108, die Peers möglicherweise beide beim Senden und Empfangen benutzen wollen, ausreichend angesehen werden. Insbesondere das Attribut „role" des <rtp:map>-Elements des <e2enp-qosdef name=„contracts">-Abschnitts erlaubt, dies zu tun.
  • Diese zwei homonymen Attribute behandeln jedoch zwei verschiedene Aspekte: Das im <e2enp:qosdef name=„contracts">-Abschnitt benutzte „role"-Attribut erlaubt Empfängern, APs und QoS-Verträge/APs hoher Ebene auf der Basis auch von durch Sender verbreitete Information/Präferenzen zu formulieren, während das „role"-Attribut des <cfg>-Abschnitts nur erlaubt, Anwendung/Middleware selbst zu konfigurieren, um, wie vorstehend erwähnt, Medienströme 206 (unter Fähigkeits- und Transportaspekten) richtig zu benutzen.
  • Der <e2enp: qoscfg>-Abschnitt erlaubt das Definieren von APs ebensowie von QoS-Korrelation-804- und Zeitsynchronisation-805-Beschränkungen auf verschiedenen Ebenen von Abstraktionen, wobei mit Stromebene-QoS-Verträgen 1108 begonnen wird. Jede Abstraktionsebene wird durch das Attribut „name" dieses Abschnitts identifiziert.
  • Ein Beispiel dieses Abschnitts auf Stromebene wird in dem XML-Dokumentfragment unten angedeutet.
  • Figure 01490001
  • Figure 01500001
  • Figure 01510001
  • XML-Beispiel 10
    • (level = Ebene, Niveau, Pegel, adaptation path for single media streams 206 = Adaptierungspfad für einzelnen Medienstrom 206, adapath = Adapfad, nominal = nominell, choice = Wahl, ref = Referenz, event = Ereignis, reason = Grund, higher = höher, path = Pfad, upgrade = aktualisieren, hochrüsten, guard = Schutz, source = Quelle, lower = niedriger, degrade = degradieren, possible assoiciations of media streams 206 between user A and B = mögliche Assoziationen von Medienströmen zwischen zwischen Benutzer A und B, context = Kontext, association = Assoziation, comp = Komponente, par = Parameter, lipsync-delay = Lipsync-Verzögerung, max = Maximum, aggregated = aggregiert; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Die folgenden Absätze detaillieren jedes in diesem Abschnitt erscheinende Element.
  • Die ersten zwei Fälle des in dem obigen Beispiel erscheinenden <adapath>-Elements elauben, zwei unterschiedliche Adaptierungspfade durch Sammeln eines Satzes sich gegenseitig ausschließender, aus dem Satz der <contract>-Elemente des <qosdef name=„capabilities">-Abschnitts gezogener und nur mit Empfängern (entsprechend den oben dargelegten Erfordernissen) assoziierten Stromebene-QoS-Verträge 1108 zu definieren. Jedes <adapath>-Element ist mit einer spezifischen <component> des <dfg>-Abschnitts über das „ref component"-Attribut assoziiert. Dieses Attribut ist nur für <adapath>-Elemente, die Stromebene-APs beschreiben, obligatorisch.
  • Jeder QoS-Vertrag 1108 ist eine alternative Option im AP: folglich die Benutzung des <alt>-Konstrukts, um sie zu definieren („alt" steht für „alternative" (Alternative)). Durch Annahme des oben beschriebenen hierarchischen FSM-Modells stellt jeder dieser APs eine andere FSM dar, deren Anfangszustand durch das Element <default> des gegebenen <adapath>-Konstrukts explizit angezeigt wird.
  • Durch Annahme des oben beschriebenen Hierarchical FSM model (hierarchisches FSM-Modell) kann die Wahl des Schaltens von einem QoS-Vertrag 1108 zu einem anderen in einem gegebenen AP durch Anpassen überwachter QoS-Ebenen an einen im gegebenen AP definierten Satz von QoS-Verträgen 1108 durch Benutzung beispielsweise einer in „Enabling QoS adaptation decisions for Internet applications" (London/UK, 1999) von S. Bhatti und G. Knight, im Folgenden als [Bhatt99] bezeichnet, und [BRAIN] beschriebenen Fuzzy-Logik dynamisch bestimmt werden. Alternativ dazu kann das <adapath>-Konstrukt einen vordefinierten Satz von Zustandsübergängen zwischen diesen QoS-Verträgen 1108 enthalten: In diesem Fall zeigt das <event>-Konstrukt an, welche Übergänge bei der Detektion gegebener Ereignisse wie Rahmenratenerhöhung oder Rahmenratenerniedrigung wie beim obigen Beispiel ausgelöst werden sollten. Diese Ereignisse sind designierte, wohlbekannte Monitornotifikationen darüber, welche Anwendungen und/oder Middleware zur Berücksichtigung bezeichnet werden können bzw. kann. Bis zu diesem Grad sollen sowohl der Name als auch die Semantik von Ereignissen Standardisierungsanstrengungen unterworfen werden. Ein gegebenes <event> kann mit multiplen Pfaden assoziiert sein, deren Auslösungen (Triggers) den einen bestimmen, der aktiviert wird.
  • Die individuellen Übergänge sind in <path>-Konstrukten beschrieben, welche die Auslösebedingung (trigger condition) (als Schutzparameter angezeigt) und die in den Übergang involvierten QoS-Verträge 1108 (mit den Quellen- und Zielattributen angezeigt) beschreiben. Das Quellenattribut im <path>-Konstrukt ist insofern optional, als es Fälle geben kann, bei denen die Spezifikation dieses Attributs absichtlich fortgelassen werden könnte. In diesen Fällen würde der korrespondierende Übergang tatsächlich daraus entstehen, welcher Zustand der gegebenen Hierarchical FSM (hierarchischen FSM) gegenwärtig tatsächlich eingestellt ist. Auf diese Weise kann die Änderung jedes QoS-Vertrags 1108 in dem Fall, dass der korrespondierende Übergang ausgelöst wird, in einem gegebenen Satz auf einem definierten modelliert werden (eine Art Vorgabemechanismus). Beim obigen Beispiel würde das durch die Detektion einer niedrigeren Rahmenrate (siehe das <reason>-Attribut) ausgelöste Ereignis <video1-e-2> die durch das mit Video 1 bezeichnete <adapath>-Konstrukt beschriebene FSM zwingen, video-contrakt-1 (Videovertrag 1) zu forcieren, wobei es keine Rolle spielt, welcher Vertrag 1108 zu der Zeit, bei der das Ereignis aufgetreten ist, forciert war. Um direkte Kommunizierfähigkeit zu erzielen, sollte man vermerken, dass die Peers über die Semantik des Grundattributs (Riesenattribut) übereinkommen sollten. Ausdrücke wie „higher-frame-rate (höhere Rahmenrate)" oder „lower-frame-rate (niedrigere Rahmenrate)", die im obigen Beispiel auftreten, sollten somit zusammen mit ihrer Bedeutung einer Standardisierung unterworfen werden. Diese Vordefinition von Übergängesätzen ist optional.
  • Das Attribut „scope (Geltungsbereich)" zeigt in einer Anforderung (Verhandlungsangebot) an, ob das korrespondierende SDPng-912-Element als eine erforderliche („applicable") oder gewünschte („possible") Option anzusehen ist, während in einer Antwort (Verhandlungsgegenangebot) dieses Attribut anzeigt, ob das korrespondierende SDPng-912-Element validiert („applicable") oder zurückgewiesen („not-applicable") worden ist.
  • Figure 01540001
  • Der Antworter 811 kann auch im Gegenangebot anzeigen, welche Fähigkeiten und bis zu welchem Ausmaß er unterstützen kann. Wenn eine gegebene Fähigkeit unterstützt wird „wie sie ist", wird nur der korrespondierende Identifizierer zusammen mit dem auf „applicable" gesetzten scope-Attribut angezeigt. Wenn eine gegebene Fähigkeit nicht unterstützt wird, wird der korrespondierende Identifizierer einfach fortgelassen. Wenn der Antworter 811 im Gegenangebot eine modifizierte Version der Parameterisierung einer gegebenen Fähigkeit im <e2enp: qosdef>-Abschnitt (als eine Teilmenge des ursprünglichen Angebots (bid)) vorschlägt, wird die ganze Beschreibung mit den Aktualisierungen sowohl in den <e2enp:qosdef name=„capabilities">- als auch <e2enp:qosdef name=„contracts">-Abschnitt zurückgebracht. In jedem Fall enthält der <e2enp:qosdef name=„contracts">-Abschnitt in einer Antwort nur aktualisierte Codecparameterisierungen.
  • Zusätzlich kann der Antworter 811 eine (dem Anbieter 810 bei der Vorverhandlung-802-Zeit unbekannte) neue Option anzeigen. Diese wird als „possible" markiert. Die Idee ist, dass der Anbieter 810 auf diese Weise von einer potentiellen Option informiert werden kann, die eventuell später benutzt werden könnte, sollte der Anbieter 810 mit einer zu dieser Option passenden neuen Fähigkeit aktualisiert (upgraded) werden.
  • Die <context>-Elemente definieren mögliche Assoziationen der gegebenen Medienströme 206 und erlauben so ein Definieren von Zeitsynchronisations- und/oder QoS-Korrelation-804-Beschränkungen. Als solche beschreiben die <context>-Elemente grundsätzlich einen QoS-Vertrag 1108 hoher Ebene.
  • Beim obigen Beispiel sind ein Videomedienstrom 206 und ein Audiomendienstrom 206 als mit einem gegebenen Kontext („association 1-1") zusammen mit sowohl definierten Zeitsynchronisations- als auch QoS-Korrelation-804-Beschränkungen definiert. Alternativ dazu könnte auch ein nur den Audiomedienstrom 206 („association 1-2") enthaltender Kontext benutzt werden.
  • Wann und wie jeder der Kontexte zu forcieren ist, ist im zweiten Fall des beim obigen Beispiel erscheinenden <adapath>-Element beschrieben. In diesem Fall ist die Benutzung des <default>-Elements evident: Die Kombination („association 1-1") eines Audiomedienstroms und eines Videomedienstroms wird als die bevorzugte angezeigt. Der Fall, bei dem nur ein Audiomedienstrom benutzt wird („association 1-2") würde dann als ein Sicherungsfall angesehen, der forciert werden kann, um beispielsweise QoS-Verletzungen zu begegnen. Die individuellen Kindelemente des <adapath>-Elements verweisen auf die Fälle der vorstehend erwähnten <context>-Elemente über das „ref_context"-Attribut.
  • Als eine generelle Regel kann man auf diese Weise das sich wiederholende Auftreten von aufeinander referenzierenden <adapath>- und <context>-Elementen in einer azyklischen Kette von Referenzen anzeigen. Alternative <context>-Konstrukte sind in einem <adapath>-Konstrukt, das eine FSM definiert, gruppiert. Dieser AP und alle anderen (konkurrierenden) können dann wiederum in ein <context>-Konstrukt gewickelt sein, das auf einer höheren Ebene Beschränkungen setzt. Außerdem gibt es auch die Alternative zum Definieren solcher <context>-Konstrukte, die dann in einem AP höherer Ebene gesammelt werden können. Dieser Prozess kann rekursiv angewendet werden.
  • Ein gegebener Benutzer kann QoS-Korrelation-804- und Zeitsynchronisation-805-Beschränkungen höherer Ebene – als eine Form von erweiterter Benutzerprofilinformation – forcieren, um eine Ressourcenbenutzung (und folglich QoS) über gegebenen Sätzen von Medienströmen 206, die mit verschiedenen Peers hergestellt werden, zu orchestrieren. Bis zu diesem Grad muss der gegebene Benutzer diese Information nicht mit den Peers verhandeln.
  • Sollte jedoch der gegebene Benutzer gewisse neue Beschränkungen zu einer späteren Zeit forcieren müssen oder entdecken, dass die bisher existierenden Beschränkungen aufgrund des späteren Anschließens/Verlassens gewisser Peers an die/der gegenwärtig geöffneten Telekommunikationssessionen 102 nicht länger erfüllt sind, können neue Runden des E2ENP 908 entsprechend den gegebenen Konferenzdurchführungsgrundsätzen (die außerhalb des Bereichs der zugrundeliegenden Erfindung sind) erforderlich sein.
  • Eventuell können Peers auch auf eine Drittpartei-Entität, die Vorverhandlungen 802, Verhandlungen 806 und Wiederverhandlungen 808 (die „vollen"), welche QoS-Korrelation-804- und Zeitsynchronisation-805-Aspekte betreffende Spezifikationen höherer Ebene enthalten, managt, zurückgreifen. Diese Entität würde als eine Art von in „QoS-Support for an All-IP System Beyond 3G" (IEEE Communication Magazine, August 2001, Vol. 39, Nr. 8) von T. Robles, A. Kadelka, H. Velayos, A. Lappetelainen, A. Kassler, H. Li, D. Mandato, J. Ojala und B. Wegmann, im Folgenden als [Roble01] bezeichnet, und [BRAIN] beschriebene Art von QoS-Broker agieren, der außerhalb des Schutzbereichs der zugrundeliegenden Erfindung liegt.
  • Medienströme können auf verschiedene Art und Weise assoziiert werden. Beim folgenden Beispiel soll das Konzept einer Session 102 vorgeschlagen werden, das beispielsweise als ein Fall einer Videokonferenz 1204a/b beabsichtigt ist. Bis zu diesem Grad werden die Assoziationen von Medienströmen 206 zwischen dem gegebenen Benutzer (Benutzer A) und ihren Peers (B, C und D) im Kontext der gegebenen Videokonferenz-1204a/b-Session 103 auf verschiedene Weisen angehäuft (clustered). Dann werden die resultierenden Anhäufungen (Cluster) durch Benutzung der vorstehend erwähnten <context>-Konstrukte mit QoS-Kontexten assoziiert.
  • Bis zu diesem Grad kann jeder Cluster mit einem Satz von Beschränkungen assoziiert werden, die spezifische Ebenen von Korrelationen 804, 805 zwischen den verschiedenen Assoziationen von zum gegebenen Cluster gehörenden Medienströmen 206 diktieren. Dies bedeutet, dass die Beschränkungen alle Medienströme 206, die zu jeder Assoziation gehören, unabhängig von den QoS-Spezifikationen der zur gegebenen Assoziation gehörenden individuellen Medienströme 206 beeinflussen. Die <context>-Konstrukte spezifizieren auf diese Weise die QoS-Korrelation 804/805 für konkurrierende Bündel von Medienströmen 206. Wie bei den <adapath>-Konstrukten (eines pro Fall der Videokonferenz) beschrieben, sind dann alternative Kontexte möglich.
  • Diese <adapath>-Konstrukte sind auf diese Weise mit der Beschreibung einer FSM vergleichbar, deren Zustände wiederum andere konkurrierende <adapath>-Konstrukte enthalten, die jeweils die Bündelung von Medienströmen 206 zwischen dem gegebenen Benutzer und einem gegebenen Peer beschreiben. Dieses rekursive Modell ermöglicht die Benutzung von in [Booch99] beschriebenen Zustandsdiagrammen.
  • Figure 01580001
  • Figure 01590001
  • XML-Beispiel 11
    • (videoconference = Videokonferenz; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Mit der oben beschriebenen rekursiven Lösung fortfahrend können wir weitere Medienströme 211 auf der Basis eines Grundprinzips noch höherer Ebene aggregieren. Beispielsweise können wir alle von allen Objekten einer gegebenen Anwendung gemanagten Medienströme 206 assoziieren und den resultierenden QoS-Kontext von anderen Anwendungen differenzieren sowie QoS-Korrelation-804-Spezifikationen höherer Ebene auferlegen bzw. ausschließen.
  • Figure 01590002
  • Figure 01600001
  • XML-Beispiel 12
    • (num = Zahl, active = aktiv, flows = Flüsse, mem = Speicher, req = Anforderung; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Dieses Beispiel zeigt noch einmal die Benutzung des <e2enp: qoscfg>-Abschnitts zum Ausdrücken der oben beschriebenen Information. Bei dem Beispiel können wir sehen, wie diese Spezifikation hoher Ebene ein leichtes Ausdrücken von Beschränkungen bezüglich lokalen Ressourcenverbrauchs inline mit dem in [Roble01] und [BRAIN] beschriebenen BRENTA-Konzept ermöglicht.
  • Die Idee hinter der End-zu-End-QoS-Kompaktwiederverhandlungsphase 808 ist, die Ausführung einer Vollwiederverhandlung 808 während einer Zeit kritischer Aufgaben wie eine Wiederherstellung aus einer QoS-Verletzung aufgrund beispielsweise einer Übergabe zu vermeiden. Diese Aufgabe kann gelöst werden, indem Peers ermöglicht wird, die zu forcierenden neuen (vorverhandelten) QoS-Verträge 1108 einander zu signalisieren und/oder durch Signalisieren der (vorverhandelten) QoS-Verträge 1108, die – bei einer Übergabe zu einem neuen Zugriffsnetzwerk 604 und/oder Netzwerkprovider – als anwendbar und/oder nicht länger anwendbar resultieren. Bis zu diesem Grad ist eine spezielle SDPng-basierte Unterstützung für das E2ENP 908 erforderlich.
  • Der <e2enp:enforce>-neu-SDPng-Abschnitt erlaubt einem der Peers (typischerweise der erste, der eine QoS-Änderung oder -Verletzung detektiert), den anderen Peers zu signalisieren, welche QoS-Verträge 1108 aus den vorverhandelten APs forciert werden sollten.
  • Die Idee ist, Signalisierungsinformation entsprechend der hierarchischen Struktur der vorverhandelten QoS-Spezifikation zu transportieren. Dies bedeutet, jeden QoS-Vertragsnamen korrekt einzugrenzen. Es stehen wenigstens zwei alternative Implementationen zur Verfügung: Benutzen eines Namenraums für QoS-Verträge 1108 oder eine Sprache zum Bezugnehmen auf (referencing) einen gewissen Teil eines Dokuments wie den in der „XML Path Language Recommendation Version 1, http://www.w3.org/TR/ypath, November 1999 beschriebenen XPath-Standard oder die in der „XPointer Recommendation" (W3X, 2000, work in progress, http://www.w3.org/TRxptr), im Folgenden als [XPOINT] bezeichnet, beschriebene noch nicht standardisierte XPointer-Technik bzw. -Technologie.
  • Die erstere Lösung basiert auf der Zuordnung voll spezifizierter Namen zu einem QoS-Vertrag 1108 durch Voranhängen (pre-pending) der Namen jedes QoS-Vertrags 1108 höherer Ebene, von dem der gegebene QoS-Vertrag 1108 in der gegebenen baumbasierten QoS-Spezifikation abhängt, unter Verwendung eines Trennzeichens beispielsweise des Punktzeichens. Diese Lösung erfordert jedoch die konsistente Benutzung von (oft sehr komplexen und langen) Namen durch eine Vielfalt von E2ENP-908-Abschnitte und E2ENP-PDUs hindurch. Außerdem zwingt diese Lösung dazu, dass Anwendungen fähig sind, den gegebenen Namenraum korrekt analysieren.
  • Beispielsweise würde der völlig spezifizierte Name des „video-contrakt-2" im „video1"-AP im „association-1-1"-QoS-Kontext aus dem „associations-A-B"-AP wie folgt aussehen: „associations-A-B.association 1-1.video1.video-contract-2".
  • Die alternative Lösung basiert anstelle dessen auf XPath oder auf der XPointer-Technik (die wie bei der zugrundeliegenden Erfindung noch nicht den Standardisierungsstatus erreicht hat), die beide den laufenden Trend betreffend das unzweideutige Zeigen von Elementen quer durch verschiedene XML-Dokumente anzeigen.
  • Im Geltungsbereich der zugrundeliegenden Erfindung entschieden wir, diese letztere Lösung ohne jeden Verlust von Generalität verglichen mit der oben beschriebenen anderen (oder jeder äquivalenten anderen) in Bezug auf die Konzepte zu benutzen. Um die Wahllösung zu erläutern, führen wir das folgende XML-Dokumentfragment, das die beim oben beschriebenen Beispiel benutzte gleiche Information beschreibt, ein:
    Figure 01620001
    Figure 01630001
  • XML-Beispiel 13
    • (enforce = forcieren, variable = Variable, value = Wert, of = von, select = auswählen; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Der zu forcierende QoS-Vertrag 1108 wird durch das Element <target> angezeigt.
  • In diesem XML-Dokumentfragment kann man die Benutzung des „name"-Attributs für das Wurzelelement des gegebenen Baumzweigs (associations-A-B), leicht erkennen, während die anderen Elemente in diesem Zweig über die Referenzattribute (ref_context, ref_adapath, ref_contract) des jeweiligen Vaters benannt werden. Dies bedeutet, dass nur der Name des <contract>-, <context>- und <adapath>-Elements über mehrere Abschnitte/Phasen eindeutig benutzt werden muss, während die Namen der XML-Kindelemente der vorstehend erwähnten Elemente beliebig gewählt werden können. Durch Benutzung dieser Methode kann man eine Signalisierung nicht nur von Medienstrom-206-Ebene-QoS-Verträgen 1108 wie beim obigen Beispiel, sondern auch jeden QoS-Vertrag 1108 hoher Ebene durch Begrenzen der obigen Spezifikation zu dem gegebenen QoS-Kontext forcieren. Beispielsweise könnte das folgende XML-Dokumentfragment
    Figure 01630002
    Figure 01640001
  • XML-Beispiel 14
    • (bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Zum Signalisieren den anderen Peers, daß „assocation1-1" hoher Ebene forciert werden sollte, ungeachtet der gegenwärtig forcierten Stromebene-QoS-Verträge 1108 (in diesem Fall würden vorgegebene Zustände diktieren, welche Medienstrom-206-Ebene-QoS-Verträge 1108 in diesem neuen QoS-Kontext zu forcieren sind), benutzt werden. Außerdem kann der <e2enp: enforce>-Abschnitt auch benutzt werden, um den anderen Peers einen zu forcierenden speziellen AP zu signalisieren, in welchem der vorgegebene Zustand dann zum Auflösen der verbleibenden Information niedrigerer Ebene benutzt würde. Beispielsweise würde der folgende <e2enp:enforce>-Abschnitt:
    Figure 01640002
  • XML-Beispiel 15
    • (bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Peer A zwingen, „video-contract-1" für den „video1"-Medienstrom 206 zu benutzen, da dieser Vertrag 1108 als im vorverhandelten <e2enp: qoscfg>-Abschnitt als vorgegeben spezifiziert wurde.
  • Die vorstehende erwähnte XPath- (oder auch die XPointer-) Technik kann dazu benutzt werden, einem Peer zu erlauben, den anderen zu signalisieren, welche QoS-Verträge 1108 entsprechend dem obigen Grundprinzip zu blocken sind.
  • Bis zu diesem Grad wird hierdurch ein neuer SDPng-Abschnitt vorgeschlagen: Der <e2enp:block>-Abschnitt. Das folgende Beispiel zeigt die Benutzung eines solchen neuen Abschnitts.
  • Figure 01650001
  • Figure 01660001
  • XML-Beispiel 16
    • (block = blocken; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Der zu blockende QoS-Vertrag 1108 ist durch das Element <target> angezeigt.
  • Die vorstehend erwähnte XPath- (oder auch die XPointer-) Technik kann auch dazu benutzt werden, einem Peer zu erlauben, den anderen zu signalisieren, welche QoS-Verträge 1108 entsprechend dem oben beschriebenen Grundsatz zu entblocken bzw. freizugeben sind.
  • Bis zu diesem Grad wird hierdurch ein neuer SDPng-Abschnitt vorgeschlagen: Der <e2enp:unblock>-Abschnitt. Das folgende Beispiel zeigt die Benutzung eines solchen neuen Abschnitts.
  • Figure 01660002
  • Figure 01670001
  • XML-Beispiel 17
    • (unblock = entblocken, freigeben; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Der zu entblockende QoS-Vertrag 1108 ist durch das Element <target> angezeigt.
  • Im Kontext der in diesem Kapitel präsentierten Lösung kann die Semantik des in „Requirements for Session Description and capability negotiation" (IETF Internet Draft, work in progress, <draft-kutscher-mmusic-sdpng-req-01.txt>) von D. Kutscher et al., im Folgenden als [SDPNG01] bezeichnet, beschriebene ursprüngliche SDPng-912-<constraint>-Abschnitt als eine Form einer QoS-Korrelation-804- und/oder Zeitsynchronisation-805-Beschränkungsspezifikation, die auf die in den vorstehend erwähnten neuen SDPng-Abschnitten beschriebene QoS-Spezifikation angewendet wird, interpretiert werden. Das besagte Dokument stellt einen Satz von Erfordernisenn bereit, die für ein Gerüst zu einer Session-102-Beschreibung und Endpunkt-Fähigkeitsverhandlung in Mehrparteien-Multimedienkonferenzszenarios relevant sind.
  • Durch Berücksichtigung des SIP 910 und SDPng 912 als Protokolle, auf die das E2ENP 908 abgebildet werden sollte, ist es notwendig, zu zeigen, dass das SIP 910 ein nicht symmetrisches Protokoll ist. Das SIP-Anbieter-914-Antworter-911-Modell gibt keine Möglichkeit zum Signalisieren von Fehlern, Ausfallbedingungen oder Ausnahmen (Zustandsänderungen) bei ihrem Auftreten auf der Seite des Anbieters 914. Das E2ENP 908 erfordert mehrere SIP-Mitteilungsumläufe innerhalb seiner Phasen, und jede Einwegmitteilung eines Umlaufs sollte bei der E2ENP-Signalisierung bei allen involvierten Peers sowohl auf ihre Korrektheit als auch Annehmbarkeit geprüft werden. Zusätzlich sollten Zustandsänderungen der End-Peers innerhalb der Laufzeit einer E2ENP-Phase in Betracht gezogen werden. Diese Änderungen können einen Peer betreffen, der in
    • – Verhandlung(en) höherer Priorität,
    • – das Starten interner Prozesse höherer Priorität des Peers, der das Ressourcenmanagement und die E2ENP-908-Profileinstellungen beeinflusst,
    • – Hardware- und/oder Softwarezusammenbrüche, die in Ressourcenausfällen resultieren,
    involviert ist.
  • Bis zu diesem Grad sollte das E2ENP 908, welches das SIP 910 benutzt, in seinem SDPng-912-Hauptteil Fehlercodes, die beim Anbieter 914 auftretende Ausfälle und Gründe für den Ausfall anzeigen, oder den SIP-910-Fehlercode für sowohl den Anbieter 914 als auch den Antworter 912 übertragen. Das Studium der möglichen SDPng-Fehlercodes in Bezug auf das E2ENP und ihre Struktur sollte gänzlich in Betracht gezogen werden. Die jeweiligen neuen SDPng-XML-Fragmente zur Beschreibung der E2ENP-Fehlercodes und Signalisierung von Fehlern zur Lösung dieses Problems werden als eine mögliche Lösung angesehen, aber der Einfachheit halber in den Beispielen nicht gezeigt. Da das E2ENP 908 über huckepack auf das SIP 910 angewendet wird, sollten bei der Entwicklung des E2ENP 908 jeweilige huckepack genommene Fehlercodes und Mitteilungen im SDPng 912 berücksichtigt werden. Generell sollte der Anbieter 912 eine Wiederholung der Anrufe mit Gründenotifikation im SDPng-912-Teil der Mitteilung in Betracht ziehen, und der Antworter 911 sollte Vorteil aus der Benutzung der SIP-910-„Statuscodes" durch auch Beschreiben von Gründen im SDPng-912-Mitteilungsteil ziehen.
  • Das E2ENP sollte fähig sein, die gleiche Möglichkeit zum Signalisieren sowohl interner als auch externer Ausfallbedingungen, von Ausnahmen und von Fehlern, die bei irgendeinem der in die E2ENP-Signalisierung involvierten Peers auftreten, zu liefern. Bis zu diesem Grad sollte das E2ENP durch Anwenden von Fehlercodes bei den vom E2ENP beeinflussten Peers symmetrisch sein.
  • Gemäß „An Offer/Answer Model with SDP" (IETF Internet Draft, work in progress, <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>) von J. Rosenberg und R. Schulzrinne, im Folgenden als [SDPOA00] bezeichnet, kann festgesetzt werden, dass „ein Angebot darauf vorbereitet sein muss, durch dieses Angebot beschriebene Medien zu empfangen, wenn es einmal von einem Anbieter 914 gesendet worden ist". Diese Vorgehensweise ist in Bezug auf das E2ENP 908 und die Adaptierungsmechanismen nicht fehlertolerant, da die mögliche dynamische Rekonfiguration der Peers sowohl in Ausfall- als auch Aktualisierungsfällen, wenn die verhandelten Daten in der Zeit einer laufenden Verhandlung 806 oder bevor ein Medienstreaming gestartet hat ungültig werden, berücksichtigt werden sollte.
  • Es sollte auch in Betracht gezogen werden, dass gewisse Zwischenkomponenten, die entlang dem E2ENP-908-Signalisierungspfad mit End-Peers interagieren, Störungen des Protokolls verursachen können, wenn sie es nicht verstehen. In diesem Fall sollte es Mechanismen zum Detektieren und Wiederherstellen solcher Störungen geben.
  • Das Folgende ist eine Beschreibung möglicher Fehlerfälle, bei denen eine gewisse Notifikationsform zwischen dem Anbieter 914 und dem Antworter 911 notwendig ist, um die Änderungsbedingungen und die verursachten Störungen anzuzeigen. Der Pfeil (→) zeigt mögliche Lösungen an. Das 'A' zeigt einen Antworter 911 und das, 'O' einen Anbieter 914 an.
  • 1. Push-Modus
    • – Der Antworter 911 entdeckt, dass der Vorschlag des Anbieters 914 zu keiner seiner Fähigkeiten passt. o Der Antworter 911 hat die Fähigkeiten zum Herunterladen von Codecs § Der Antworter 911 sollte den Anbieter 914 darüber informieren, dass die Transaktion ein bisschen länger dauern kann, da sie/er Zeit zum Herunterladen und zur Einstellung seiner Profildaten benötigt. → A->O-Antwort mit „100 Trying" oder 183 Session Progress" (trying = versuchen, progress = Fortschritt). o Der Antworter 911 hat keine Fähigkeiten zum Herunterladen von Codecs § Wenn der Antworter 911 ein Dienst ist → A->O-Antwort mit „380 Alternative Service", wenn der Antworter 911 einen solchen Dienst kennt. Der Anbieter 914 kann dann eine neue Vorverhandlung 802 mit dem alternativen Dienst starten. § → Der Antworter 911 entfernt alle Fähigkeiten des Anbieters 106b aus <e2enp:qosdef name=„capabilities"> und macht ein Gegenangebot für die Fähigkeiten und Verträge 1108 (<e2enp:qosdef name=„capabilities"> und <e2enp:qosdef name=„contracts">). -- Wenn der Anbieter 914 Codecs herunterladen kann → lädt der Anbieter 914 Codecs herunter, ordnet eventuell Profile neu an, startet eventuell eine neue Vorverhandlung 802. -- Wenn der Anbieter 914 Codecs nicht herunterladen kann → sollte der Anbieter 914 die Benutzung eines Umcodierungsdienstes in Erwägung ziehen. § → Der Antworter kann auch 606 Not Acceptable ausgeben, wenn der Anbieter 914 um eine Fähigkeitsunterstützung, die momentan nicht verfügbar ist, bittet.
    • – Der Antworter 911 entdeckt, dass der Vorschlag des Anbieters 914 zu den Fähigkeiten des Antworters 911 passt, aber die angebotenen Verträge 1108 nicht unterstützt werden können. o Der Antworter 911 beschneidet (trim) jeweils ihr/sein Profil. § Der Antworter 911 sollte den Anbieter 914 darüber informieren, dass die Transaktion wegen der Profileinstellung ein bisschen länger dauert. → A->0-Antwort mit „100 Trying" oder „183 Session Progress". § → Der Antworter 911 kann auch 606 Not Acceptable ausgeben, wenn der Anbieter 914 um eine QoS-Unterstützung, die im Moment nicht verfügbar ist, bittet. o Der Antworter 911 hat keine Möglichkeit, ihr/sein Profil einzustellen. § Wenn der Antworter 911 ein Dienst ist → A->0-Antwort mit „380 Alternative Service" wenn der Antworter solch einen Dienst kennt. Der Anbieter 914 kann dann eine neue Vorverhandlung 802 mit dem alternativen Dienst starten. § Der Antworter 911 macht ein Gegenangebot für das (<e2enp:qosdef name=„contracts">) durch Beschneiden (trimming) der Bereiche der Verträge 1108 des Anbieters 914 oder durch Vorschlagen vollständig neuer Bereiche → es obliegt dem Anbieter 914, ihr/sein Profil einzustellen und eventuell eine neue Vorverhandlung 802 zu starten.
  • 2. Pull-Modus
    • – Der Anbieter 914 entdeckt, dass die Antwort des Antworters 911 zu keiner ihrer/seiner Fähigkeiten passt. o Der Anbieter 914 hat die Fähigkeiten zum Herunterladen von Codecs. § → Der Anbieter 914 lädt die Codecs herunter, stellt jeweils seine Profile ein und startet eine neue Vorverhandlung 802. o Der Anbieter 914 hat keine Fähigkeiten zum Herunterladen von Codecs. § → Der Anbieter 914 sollte die Benutzung eines Umcodiererdienstes in Erwägung ziehen.
    • – Der Anbieter 914 entdeckt, dass der Vorschlag des Antworters 911 zu keinem ihrer/seiner „contract"-Profile passt. o → Der Anbieter 914 stellt ihr/sein Profil entsprechend ein, bevor er ein Gegenangebot für den Antworter 911 erzeugt. o → Der Anbieter 914 startet eine neue Vorverhandlung 802 im Push-Modus, um die Adaptierung des Antworters 911 zu forcieren.
  • 3. Push-Pull-Modus
  • Dieser Fall sollte als eine Kombination der obigen zwei Fälle behandelt werden.
  • Es kann vorkommen, dass sich einige der vorverhandelten und gesicherten Daten beim Anbieter 914 und/oder Antworter 911 aus Gründen einer Änderung von Profilinformation ändern:
    • – Verschiedene Benutzer erlegen den Geräten (Anbieter 914 und/oder Antworter 911) ihre Performancegrundsätze auf.
    • – Einige (interne und/oder externe) Prozesse höherer Priorität benutzen die Ressourcen, so dass die vorverhandelten Profile nicht länger gültig sind.
    • – Einige Systemkonfigurationsänderungen haben stattgefunden die: o Ausfälle durch eine lokale Ressourcenreservierung aufgrund einer Okkupation oder Ressourcenfehlfunktion. o Ausfall durch Netzwerkressourcenreservierung, wenn beispielsweise das Netzwerk 604 nur „best effort" (besten Aufwand) in Bezug auf die niedrigeren Netzwerk-QoS-Ebenen unterstützt. o Neue Codecs und/oder Hardware-Teileinrichtungen werden gerade installiert und beeinflussen auf diese Weise die Fähigkeiten und die QoS-Profile.
  • Der Anbieter 914 und/oder der Antworter 911 können einen solchen vorzeitigen Verfall durch die Zeit, in der sie eine zusätzliche Vorverhandlung 802 oder eine Verhandlung 806 zu beginnen versuchen, entdecken. In einem solchen Fall sollten die Peers fähig sein, den Verfall der vorverhandelten Daten auf der Seite ihrer Kommunikationspartner forcieren und ihn auf diese Weise vorzeitig in den „Zombie" Zustand bringen.
    • → Notwendige Anzeige des vorzeitigen Verfalls mit folgender neuer Vorverhandlung 802. Bis zu diesem Grad wird das <expires>-Element auf Null gesetzt und es kann ein zusätzlicher Befehl „expire (ablaufen, verstreichen)" benutzt werden.
  • Wenn in der Zeit eines laufenden Medienstreamings eine Profiländerung auftritt, → sollte die Seite, welche die Verletzung entdeckt, einen neuen Vollwiederverhandlung-808-E2ENP-908-Prozess starten.
  • Wenn ein angerufener Peer eine Mitteilung mit einer Anzeige für einen Verhandlung-806-Modus empfängt, die er nicht unterstützt, tritt auf seiner Seite ein Ausfall auf. → In einem solchen Fall sendet der Antworter 811 „606 Not Acceptable" zum Anbieter 810, was im Mitteilungshauptteil den Verhandlung-806-Modus anzeigt, den der Antworter 811 unterstützt. Der Anbieter 810 sollte jeweils die Verhandlung-806-Phase neu starten.
  • Dies könnte bei Benutzung von Diensten der Fall sein, da Dienste fähig sein sollten, mehrere Clients parallel zu unterstützen und auf diese Weise Präferenzen für den Verhandlung-806-Modus aufweisen.
  • Aufgrund von Peer und/oder Netzwerk-604-Ausfällen kann der Hauptteil einer SIP-Mitteilung (das SDPng 912) oder die ganze SIP-Mitteilung missgestaltet sein. Wenn der Antworter 911 eine solche Mitteilung bekommt, können die möglichen Antworten sein.
    • → „400 Bad Request" (bad = schlecht), – wenn die ganze SIP-Mitteilung missgestaltet ist.
    • → „420 Bad Extension" (extension = Erweiterung) – wenn nur die SDPng-912-Mitteilung missgestaltet ist.
  • Wenn der Anbieter 914 eine missgestaltete (malformed) Mitteilung bekommt oder eine „malformed-message"-Notifikation (message = Mitteilung) empfangen hat, → sollte der Anbieter 914 die SIP-910-Anforderung (request) wiederholen.
  • Wenn eine dritte Partei mit der Verhandlung 806 interferiert und dabei eine Verhandlung 806 zu beginnen wünscht, werden die folgenden Schritte ausgeführt.
    • – Wenn der Anruf die gleiche Priorität aufweist: → Der Peer gibt „182 Queued" (queued = in Warteschlange) aus, wenn der Peer entscheidet, dass er den Anruf zu späterer Zeit behandeln kann. → Der Peer gibt „600 Busy" (busy = belegt) aus, wenn ein gewisser anderer Peer mit dem Absetzen des Anrufs schneller war und alle verfügbaren Kapazitäten des antwortenden Peers eingenommen hat. Dies gilt ist insbesondere bei schon laufenden Medienströmen 206, wenn eventuell eine Vollwiederverhandlung 808 erforderlich sein könnte. → Der Peer gibt „603 Decline" (decline = verweigern, ablehnen) ab, wenn ein gewisser anderer Peer mit dem Absetzen des Anrufs schneller war und alle verfügbaren Kapazitäten des antwortenden Peers eingenommen hat, aber der antwortende Peer weiß, wie lange der Anruf fortgesetzt wird. Dies ist auch der Fall, dass eine ähnliche Transaktion in Bezug auf die Priorität im Moment verarbeitet wird und der Anrufer zu warten hat. → Der Peer gibt „380 Alternative Service" aus, wenn der Peer ein Dienst ist und Information über gemeinsame alternative Dienste hat. Wenn der Anruf höhere Priorität hat: o Auf der Anbieter-914-Seite: → Der Anbieter 919 sollte fähig sein, den Antworter 911 über die Unterbrechung der Verhandlung 806 zu informieren – ein gewisser SDPng-912-Fehlercode. o Auf der Antworter-911-Seite: → Der Antworter 911 kann „600 Busy" oder „603 Decline" mit einem die Unterbrechung anzeigenden gewissen Grund ausgeben. → Abhängig von der Priorität des Anrufs und der gegenwärtig verfügbaren Ressourcen durch schon laufende Medienströme 206 kann der Peer eine Schnell- oder Vollwiederverhandlung 808 ausführen, um das Medienstreaming vollständig zu beseitigen.
  • Gemäß [SIPBIS04] kann festgesetzt werden, dass „Proxies generell die Session-102-Beschreibung nicht modifizieren, aber dies tun können bzw. dürfen, wenn es notwendig ist, beispielsweise für Netzwerk-604-Adressentranslatoren, und wenn die Session-102-Beschreibung von einem kryptografischen Integritätsmechanismus nicht geschützt ist". Dies bedeutet, dass die Proxies die SDPng-912- Hauptteile der Mitteilungen verstehen und sie ändern können. Um zu verhindern, dass die E2ENP-908-Mitteilungen von Komponenten, die das Protokoll nicht verstehen, geändert werden, → sollten digitale Signaturen und Digests (Zusammenfassungen) für die E2ENP-Mitteilungen angewendet werden. Im SDPng 912 sollten für das E2ENP 908 auch gewisse zusätzliche Signalisierungsmechanismen angewendet werden, um den Peers zu ermöglichen, einander darüber zu informieren, dass eine E2ENP-Mitteilung durch eine gewisse Netzwerk-604-Komponente, die nicht in das E2ENP 908 verwickelt ist, gerade geändert wird.
  • Die Integrität der Mitteilung sollte als eine Sicherheitsausgabe angesehen werden, die ein Thema für zukünftige Studien ist. Wenn ein Antworter 911 das E2ENP 908 generell versteht, nicht aber seine Version, → gibt der Antworter 911 eine „606 Not Acceptable"-Mitteilung mit der SDPng-912-Beschreibung ab, die anzeigt, dass die E2ENP-908-Version nicht unterstützt wird, aber dass eine andere E2ENP-908-Version unterstützt wird. Dies ist auch zum Garantieren einer Rückwärtskompatibilität der E2ENP-908-Versionen notwendig. Dies bedeutet, dass der die E2ENP-908-Version beschreibende XML-Teil für alle E2ENP-908-Versionen gleich ist.
  • Das in Betrachtziehen von abgeschirmten Netzwerken 604 (das heißt die Benutzung von Proxies, Firewalls) ist eine Sicherheitsausgabe, die ein Thema für zukünftige Studien ist. Das Folgende ist nur eine kurze Beschreibung darüber, wie Sicherheit (security) die E2ENP-908-Fehlermeldung beeinflusst:
    • 1. Die abschirmende Komponente versteht nicht das E2ENP 908, versteht aber das SIP 910 und/oder SDPng 912. In diesem Fall wäre eine Nicht-E2ENP-908-Vorverhandlung 802 mit der abschirmenden Komponente notwendig, um sie transparent für das folgende E2ENP-Protokoll zu machen.
    • 2. Die abschirmende Komponente versteht das E2ENP 908. In diesem Fall kann das E2ENP 908 Information, welche die nichttransparenten Komponenten betrifft, in Form von Referenzen auf eventuelle Nicht-E2ENP-908-Information (Authentifizierungierung (authentication), Sicherheit usw.) übertragen und dadurch den nichttransparenten Komponenten ermöglichen, die E2ENP-Mitteilungen still zu prüfen und weiterzuleiten. Die Anbieter 106b und die Antworter 106a2, die an dieser Information nicht interessiert sind, können sie einfach verwerfen. Diese Vorgehensweise ermöglicht eine stille Behandlung von (in Bezug auf das E2ENP 908) nichttransparenten Komponenten, wodurch sie das Netzwerk 604 explizit transparent macht und gewisse der SIP-910-„Request Failures 4xx"-Mitteilungen (failures = Ausfälle), die das E2ENP 908 negativ beeinflussen können, maskiert.
  • Insbesondere können Ausgaben mit der Benutzung des das E2ENP 908 betreffenden SIP 910 wie folgt zusammengefasst werden:
    • 1. Das E2ENP 908 ist ein Metaprotokoll über dem SIP 910 insofern, als das E2ENP 908 nicht dem Schichtungsparadigma (layering paradigma) folgt.
    • 2. Das E2ENP-Metaprotokoll sollte in den SIP-Mitteilungen explizit genannt werden, um die Interferenz der Zwischenkomponenten bei den E2ENP-Sessionen 103 zu vermeiden. Gemäß der SIP-910-Defintion in [SIPBIS04] „stellt" das „Subjekt"-Headerfeld „eine Zusammenfassung bereit oder zeigt die Natur des Anrufs an, was eine Anruffilterung ermöglicht, ohne dass die Session-102-Beschreibung analysiert werden muss", wodurch die Anzeige
      Figure 01790001
      zum Definieren des Starts einer E2ENP-908-Session 103 bei der Startanforderung (start request) des E2ENP 908 benutzt werden kann. Die das E2ENP 908 verstehenden Zwischenkomponenten würden dann die in der SIP-910-Definition angezeigten Mitteilungen eines E2ENP-908-Anrufs einfach übermitteln. Um die Spur der E2ENP-908-Mitteilungen entlang dem Signalisierungspfad zu halten und sicherzustellen, dass der Anruf für eine End-zu-End-Verhandlung 806 unmissverständlich bzw. klar verstanden wird, sollte eine zusätzliche Anzeige des Metaprotokolls im „Content-Type"-Header („Inhaltstyp"-Header) ausgeführt werden:
      Figure 01790002
      um alle das SIP 910 verstehenden Zwischenkomponenten darüber zu informieren, dass die Mitteilungshauptteile (message bodies) des E2ENP 908 keine Änderungen erfahren sollen. Diese zusätzliche Anzeige ist notwendig, da der „Subjekt"-Header per Definition nur mit den Anforderungsanrufen benutzt wird, was in Bezug auf die Unverletzlichkeit der Antwortanrufe unzureichend ist. In der Struktur des Inhaltstypnamens (content type name) ist „application/e2enp/sdpng" die Anzeige des E2ENP 908 in der Mitte, wodurch der Missbrauch des Mitteilungshauptteils von Komponenten, die das SIP 910 und das SDPng 912, nicht aber das E2ENP 908 verstehen, vermieden wird. Die Komponenten, die das E2ENP 908 verstehen, sollten per se auch das SDPng 912 verstehen.
    • 3. Anmerkung: Eine zusätzliche Benutzung der Statusanrufantwort „380 Alternative Service" sollte durch Ausführen einer Dreiparteienverhandlung in Betracht gezogen werden. Der Antworter 811 ist in einem strukturellen Modell Anbieter-Mediator-Antworter aus der Perspektive des Mediators 106a1 der „alternative service".
  • Im folgenden Abschnitt seien einige Beispiele präsentiert, die zeigen, wie die Lösung in praktischen Fällen benutzt werden kann. Das erste Beispiel behandelt Videokonferenz-1204a/b-Dienste, bei denen Eins-zu-Eins- und Eins-zu-Viele-Szenarios benutzt werden. Das zweite Beispiel behandelt Drittpartei-unterstützte Verhandlung-806-Szenarios. Das dritte Beispiel zeigt den Fall eines Viele-zu-Viele-Szenarios.
  • Insbesondere soll der Fall eines gegebenen Benutzers A in Betracht gezogen werden, der sich, wie in 12 gezeigt, zwei verschiedenen Videokonferenzsessionen 1204a/b anschließt. Der Benutzer A agiert nicht als ein Mischer (Mixer) im Interesse der anderen Peers, sondern nimmt einfach an zwei verschiedenen Videokonferenzen 1204a/b teil. In unserer Terminologie wird jede Instanz der Videokonferenzanwendung als „Videokonferenzsession" (videoconference session) 1204a/b bezeichnet. Der Benutzer A 1202a eröffnet dann die Videokonferenzsession #1 mit dem Benutzer B 1202b und dem Benutzer C 1202c und die Videokonferenzsession #2 mit dem Benutzer D 1202d.
  • Bei diesem Beispiel fokussieren wir einfach auf die Ebene der angeforderten (requested) und vom Benutzer A 1202a wahrgenommenen (perceived) QoS. Deshalb beschränken wir dieses Beispiel auf die Verhandlung 806 der QoS, die der Benutzer A 1202a für von ihren/seinen Peers 1202b/c/d ankommende Medienströme 206 zu erhalten wünscht. Außerdem können wir wohl annehmen, dass der Benutzer A 1202a genug Information zum Forcieren der QoS-Korrelation 804 und Zeitsynchronisation 805 bezüglich aller Medienströme 206 hat, bei beiden Videokonferenzsessionen 1204a/b inkludiert sind.
  • Im Rest dieses Abschnitts wird die folgende Konvention angewendet:
    • 1. Es werden zuerst Mitteilungssequenzdiagramme präsentiert, welche die anzuwendenden Protokollprozeduren detaillieren. Der SDPng-Inhalt wird durch Schlüsselwörter referenziert: Angebote werden mit dem Schlüsselwort „bid-x" (Angebot-x), Antworter mit dem Schlüsselwort „answer-y (Antwort-y) referenziert, in welchen beiden Fällen x und y für einen inkrementellen ganzzahligen positiven Wert steht.
    • 2. Eine detaillierte Beschreibung des SDPng-Inhalts wird dann in einem separaten Teilabschnitt (sub-paragraph) gesammelt.
  • Das folgende Diagramm bezieht sich auf eine Vorverhandlung in einem Ein-zu-Eins-Kommunikationsszenario 100 (wobei in diesem und den nachfolgenden ähnlichen Diagrammen die dort vorkommenden englischen Wörter bedeuten: local = lokal; admission = Zugriff; control = Kontrolle; options = Optionen; answer = Antwort; ok = o.k.; bid = Angebot; session = Session, Sitzung; invite = auffordern, einladen; progress = Fortschritt; command = Befehl; start = Start; resource = Ressource; reservation = Reservierung; network = Netzwerk; ready = bereit, fertig; ringing = Rufen; do = tun, ausführen; refer = Bezugnehmen auf, verweisen; accepted = akzeptiert; notify = bekannt geben, mitteilen; busy = belegt; decline = verweigern, ablehnen; not acceptable = nicht akzeptabel; alternative service = alternativer Dienst; temporarily unavailable = vorübergehend nicht verfügbar):
  • – Push-Modus:
    Figure 01820001
  • – Pull-Modus
    Figure 01820002
    • Anmerkung (1): Der Anbieter 914 kann bzw. braucht nicht die „answer" (Antwort) an den Antworter 911 mit dem zweiten OPTIONS-Verfahren mitteilen.
  • Beispielsweise im Fall eines Video-on-Demand-Szenarios könnte der Anbieter 914 das RTSP DESCRIBE-Verfahren (describe = beschreiben) äquivalent benutzen, um Information über mit gegebenen Medien assoziierten QoS-Verträge 1108 zu sammeln. In diesem Fall müsste der Antworter 911 nicht über die Wahl des Anbieters 914 (das heißt Clients) informiert werden, bis das tatsächliche Medienstreaming gestartet wird. In diesem Dokument fokussieren wir jedoch auf SIP-basierte Konferenzszenarios, bei denen Peers im Wesentlichen auf einer gleichen Länge zu betrachten sind: Jeder Peer ist darauf bedacht, über andere Peers für eine spätere Kommunikation informiert zu werden. Dies trifft insbesondere zu, wenn beispielsweise Peer B beabsichtigt, die QoS-Korrelation 804 und die Zeitsynchronisation 805 zu forcieren. Deshalb passt das oben gezeigte Szenario zu dem hierdurch adressierten Beispiel.
  • – Push-Pull-Modus
    Figure 01830001
    • Anmerkung (2): Beim Empfang eines Angebots (bid) vom Anbieter 914 validiert der Antworter 911 zuerst sein eigenes Angebot (bid) (beispielsweise auf der Basis von Benutzerprofilinformation) und dann das Angebot des Anbieters 914, indem er einem Unterfall des Ökonomieprinzips folgt (zuerst an lokale Ressourcen und dann solche von fernen Peers übergeben).
  • Im folgenden Abschnitt werden die mit den Schlüsselwörtern bid-x, answer-y in den vorherigen Beispielen angezeigten SIP-Mitteilungshauptteile beschrieben.
  • Bid-1.1
    Figure 01840001
  • Figure 01850001
  • Figure 01860001
  • XML-Beispiel 18
    • (Bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Answer-1.1
  • Das Gegenangebot zeigt an, welche Fähigkeiten und bis zu welchem Grad der Antworter 911 unterstützt. Wenn eine gegebene Fähigkeit so unterstützt wird, „wie sie ist", wird nur der korrespondierende Identifizierer zusammen mit den auf „applicable" gesetzten Geltungsbereichattribut (scope attribut) angezeigt. Wenn eine gegebene Fähigkeit nicht unterstützt wird, wird der korrespondierende Identifizierer einfach fortgelassen (beim Beispiel der G.729-Audio-Codec und der WAVI-Video-Codec). Wenn eine gegebene Fähigkeit im <e2enp:qosdef name=„contracts">-Abschnitt aktualisiert wird, wird die ganze Beschreibung mit den Aktualisierungen zurückgebracht. In jedem Fall enthält <e2enp:qosdef name=„contracts"> in einer Antwort nur aktualisierte Codec-Parameterisierungen. Bei dem Beispiel sind der PCMU-Audio-Codec und die H.261-Video-Codecs vom Antworter 911 neu parameterisiert.
  • Eventuell kann das Gegenangebot gewisse Fähigkeiten, die nicht vom Anbieter 914 unterstützt werden, auflisten. Bei dem Beispiel ein L16-Audio-Codec und ein MPEG-2-Video-Codec.
  • Gegenangebote an den <e2enp:qosdef name=„contracts">-Teil eines Angebots (bid) können vom Antworter 911 unabhängig von den korrespondierenden Zeilen im <e2enp:qosdef=„capabilities">-Abschnitt und umgekehrt vorgeschlagen werden. Bei dem Beispiel ist der Bereich des G.722-Audiocodec als „applicable" im <e2enp:qosdef name=„capabilities">-Abschnitt gegengeboten, aber der korrespondierende Vertrag 1108 im <e2enp:qosdef name=„contracts">-Abschnitt ist so beibehalten, wie er ist.
  • Wie vorstehend erwähnt ist ein Gegenangebot zum Vertrag 1108 relativ zum PCMU-Audio-Codec im <e2enp:qosdef name=„contracts">-Abschnitt vorgeschlagen, während das korrespondierende Angebot (bid) im <e2enp:qosdef name=„capabilities">-Abschnitt so beibehalten ist, wie es ist. Diese Flexibilität beruht auf der modularen Definition der verschiedenen Abschnitte.
  • Änderungen in Bezug auf das ursprüngliche Angebot (original bid) werden fett angezeigt. Bei diesem Beispiel antwortet der Antworter 911 dem Anbieter 914 durch Anzeigen, dass:
    • – Der G729-Audio-Codec nicht unterstützt werden kann (korrespondierende Zeilen entfernt).
    • – Der L16-Audio-Codec könnte unterstützt werden (bei eingestellter Konfiguration als „possible" angezeigt).
    • – Der WAVI-Video-Codec kann nicht unterstützt werden (korrespondierende Zeilen entfernt).
    • – Der MPEG-2-Video-Codec könnte unterstützt werden (bei der eingestellten Konfiguration als „possible" angezeigt).
    • – Es soll nur der Netzwerkressourcen-Optimierungsgrundsatz benutzt werden.
    • – Audio-contract-1: Nur eine Teilmenge des vorgeschlagenen Abtastbereichs (sampling range) kann angewendet werden.
    • – Video-contract-2: nur eine Teilmenge des vorgeschlagenen Rahmenratenbereichs (frame-rate-range) kann angewendet werden.
  • Figure 01880001
  • Figure 01890001
  • Figure 01900001
  • XML-Beispiel 19
    • (channels = Kanäle; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • „Bid-1.2" und „Answer-1.2"
  • Dieses Angebot (bid) und diese Antwort (answer) unterscheiden sich von den in den vorherigen Abschnitten beschriebenen anderen insofern, als in diesem Fall der <e2enp:purpose>-Abschnitt den Pull-Modus (pull mode) anzeigt.
  • Für die „OPTIONS":
    Figure 01900002
  • XML-Beispiel 20
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Für das „Bid-1.2":
    Figure 01910001
  • XML-Beispiel 21
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Für die "Answer-1.2":
    Figure 01910002
  • Figure 01920001
  • XML-Beispiel 22
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Die schließliche Antwort vom Peer B ist:
    Figure 01920002
  • XML-Beispiel 23
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Diese Angebote (bids) und Antworten (answers) unterscheiden sich von den in den vorherigen Abschnitten beschriebenen insofern, als der <e2enp:purpose>-Abschnitt in diesem Fall den push-pull-Modus anzeigt. Das „Bid-1.3" soll als <e2enp:purpose> das Folgende enthalten:
    Figure 01920003
    Figure 01930001
  • XML-Beispiel 24
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Insbesondere ist "Answer-1.3 + Bid-1.4" für den Fall, bei dem der E2ENP-908 SDPng-Inhalt sowohl das Angebot (bid) und die Antwort (answer) des Antworters 911 enthält, verantwortlich. Um das Angebot (bid) von der Antwort (answer) zu unterscheiden, soll jedes von ihnen einen anderen <e2enp:purpose>-Abschnitt charakterisieren. Dies bedeutet, dass die Push-Pull-Vorverhandlung 802 in der Überlappung zweier Vorverhandlung-802-Sessionen, jede mit ihrem eigenen Identifizierer, resultiert.
  • Wenn konkreter beispielsweise das „Bid-1.3" einen <e2enp:purpose>-Abschnitt wie den oben angezeigten einen charakterisiert, soll das „Answer-1.3 + Bid-1.4" zwei <e2enp:purpose>-Abschnitte wie die Folgenden charakterisieren:
    Figure 01930002
    Figure 01940001
  • XML-Beispiel 25
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Das Angebot (bid) des Antworters 911 referenziert das Angebot (bid) des Anbieters 914 über das <use>-Konstrukt insofern, als der Antworter 911 sein Angebot auf der Basis nicht nur der Präferenzen des Antworters 911 formuliert (beispielsweise aus Benutzerprofilinformation), sondern auch auf dem Angebot des Anbieters 914 (und eventuell auf der Basis von QoS-Korrelation-804- und/oder Zeitsynchronisation-805-Beschränkungen).
  • Natürlich soll die „Answer-1.4", indem es dem obigen Beispiel folgt, als <e2enp:purpose> das Folgende enthalten:
    Figure 01940002
    Figure 01950001
  • XML-Beispiel 26
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Im folgenden Abschnitt sei die Verhandlung und Ressourcenreservierung beschrieben (wobei resource = Ressource, reservation = Reservierung, progress = Fortschritt, command = Befehl, network = Netzwerk, ready = bereit, fertig, ringing = Rufen bedeuten):
  • – Push-Modus
    Figure 01950002
  • Figure 01960001
    • Anmerkung (1): Nachdem er eine lokale Ressource in Bezug auf "Bid-2.1" vorgebucht hat, reserviert der Peer A schließlich die verhandelte Teilmenge „answer-2.1", um jede übermäßige Ressource freizugeben.
  • – Pull-Modus
    Figure 01960002
  • Figure 01970001
    • Anmerkung (2) : Nachdem er in Bezug auf „Bid-2.2" eine lokale Ressource (local resource) vorgebucht hat, reserviert der Peer B schließlich die vorverhandelte Teilmenge „Answer-2.2", um jede übermäßige Ressource freizugeben.
    • Anmerkung (3): „Bid-2.2" und „Answer-2.1" sind im Wesentlichen äquivalent (zum entsprechenden) „Bid-2.1" und (zur entsprechenden) „Answer-2.1", mit Ausnahme des <e2enp:purpose>-Abschnitts, der das auf „pull" eingestellte Attribut „mode" und, im Fall von „Answer-2.2" das auf „start-reservation" eingestellte Attribut „type" charakterisiert.
  • – Push-Pull-Modus
    Figure 01980001
  • Figure 01990001
    • Anmerkung (4): Nachdem er in Bezug auf "Bid-2.3" eine lokale Ressource vorgebucht hat, reserviert der Peer A schließlich die verhandelte Teilmenge "Answer-2.3", um jede übermäßige Ressource freizugeben.
    • Anmerkung (5): Nachdem er in Bezug auf "Bid-2.4" eine lokale Ressource vorgebucht hat, reserviert der Peer B schließlich die verhandelte Teilmenge "Answer-2.4", um jede übermäßige Ressource freizugeben.
    • Anmerkung (6): "Bid-2.3"/"Bid-2.4" und "Answer-2.3"/"Answer-2.4" sind im Wesentlichen äquivalent zum (entsprechenden) „Bid-2.1" und „Answer-2.1", mit Ausnahme des <e2enp:purpose>-Abschnitts, der das auf „push-pull" eingestellte „mode"-Element und im Fall von „Answer-2.4" das auf „start-reservation" eingestellte Attribut „type" charakterisiert.
    • Anmerkung (7): Die „Answer-2.3" ist eine TSpec zum Empfangen, „Answer-2.4" ist eine TSpec zum Senden.
    • Anmerkung (8): „Answer-2.3" ist eine TSpec zum Senden, „Answer-2.4" ist eine TSpec zum Empfangen.
  • Im folgenden Abschnitt seien die mit den Schlüsselwörtern „bid-x", „answer-y" bei den vorherigen Beispielen angezeigten SIP-Mitteilungshauptteile beschrieben.
  • Bid-2.1
  • Dieses Bid (Angebot) bezieht sich auf vorverhandelte Information, indem der Session-103-Identifizierer, der diese Information über das <use>-Konstrukt im <e2enp:purpose>-Abschnitt eindeutig anzeigt, angezeigt wird. Bei diesem Beispiel ist die in Bezug genommene Information das „Bid-1.1", das zum Vorverhandeln von Fähigkeiten und Stromebene-QoS-Verträgen 1108 benutzt wurde. Alternativ dazu könnten die Peers die in diesem Abschnitt enthaltene AP-Information direkt im „Bid-1.1" verhandelt haben, um die Verhandlung-806-Phase zu beschleunigen.
  • Figure 02000001
  • Figure 02010001
  • Figure 02020001
  • XML-Beispiel 27
    • (adaptation path for single media streams 206 = Adaptierungspfad für einzelne Medienströme 206, possible association of media streams 206 between user A and B = mögliche Assoziation von Medienströmen 206 zwischen Benutzer A und B; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Answer-2.1
  • Was den SDPng-912-<cfg>-Abschnitt betrifft, antwortet bei diesem Beispiel der Antworter 911 dem Anbieter 914 durch Auflisten nur der Transportinformation, über die Übereinkommen erreicht worden ist. Änderungen in Bezug auf das ursprüngliche Angebot werden fett angezeigt. Bei diesem Beispiel antwortet der Antworter 911 dem Anbieter 914 durch anzeigen des Folgenden:
    • – Die „AVP-Video-33"-Option kann nicht unterstützt werden, weil beispielsweise EPv6 vom Antworter 911 nicht unterstützt wird (korrespondierende Zeilen entfernt).
    • – „Association1-1": nur eine Teilmenge der vorgeschlagenen „Lipsync-delay" kann angewendet werden.
    • – „Association1-1": nur eine Teilmenge des vorgeschlagenen „aggregated-bw" kann angewendet werden.
    • – „Association1-2": als „applicable" bestätigt.
  • In dieser Phase verhandeln die Peers einen Medienstrom-206-AP und einen Assoziation-AP über den <e2enp:qoscfg>-Abschnitt: Bei diesem Beispiel antwortet der Antworter 911 mit einer Teilmenge der angebotenen QoS-Korrelation 804- und Zeitsynchronisation-805-Beschränkungen (nur geänderte Elemente werden detailliert: Änderungen werden fett angezeigt).
  • Figure 02040001
  • Figure 02050001
  • XML-Beispiel 28
    • (adaptation path for single media stream = Adaptierungspfad für einzelnen Medienstrom, Possible associations of media streams between user A and B = mögliche Assoziation von Medienströmen zwischen Benutzer A und B; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Um den Befehl zu einem Peer zu starten einer Reservierung von Ressourcen zu signalisieren, charakterisiert der SDPng-Inhalt einfach einen <e2enp: purpose>-Abschnitt mit dem auf "start-reservation" eingestellten Attribut „name" wie im folgenden Beispiel:
    Figure 02050002
    Figure 02060001
  • XML-Beispiel 29
    • (bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Um dem Peer zu signalisieren, dass die Reservierung ausgeführt worden ist, charakterisiert der SDPng-Inhalt einfach einen <e2enp:purpose>-Abschnitt mit dem auf „ready-reservation" eingestellten Attribut „name" wie im folgenden Beispiel:
    Figure 02060002
  • XML-Beispiel 30
    • (bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Wie oben vorweggenommen könnten die Peers die im Rest dieses Abschnitts direkt im „Bid-1.1" beschriebene AP-Information vorverhandelt haben, um die Verhandlung-806-Phase zu beschleunigen. Das Folgende ist ein Beispiel eines Vorverhandlung-802-Angebots und einer Antwortinformation (für den einfachen Fall einer Push-Modus-Vorverhandlung 802) und dann des Verhandlungs-Angebots-806 und der Antwort (wieder im Push-Modus). Das folgende Beispiel basiert auf den oben beschriebenen korrespondierenden.
  • – Bid-1.1 – mit dem Medienstrom-206-AP und Gruppen-AP (in Bezug auf Stromassoziationen)
    Figure 02070001
  • Figure 02080001
  • Figure 02090001
  • Figure 02100001
  • Figure 02110001
  • XML-Beispiel 31
    • (adaptation path for single media streams = Adaptierungspfad für einzelne Medienströme, possible associat. of media streams 206 between user A & B = mögliche Assoziat. von Medienströmen 206 zwischen Benutzer A & B; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • – Answer-1.1 – mit Medienstrom-206-AP und Gruppen-AP (in Bezug auf Stromassoziationen)
    Figure 02110002
  • Figure 02120001
  • Figure 02130001
  • XML-Beispiel 32
    • (adaptation path for single media streams = Adaptierungspfad für einzelne Medienströme, possible ass. of media streams 206 beetween user A & B = mögliche Ass. Von Medienströmen zwischen Benutzer A & B; bezüglich der Bedeutung der übrigen englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Bid-2.1 – nur Medienstrom-206-AP und Gruppen-AP referenzierend (in Bezug auf Stromassoziationen
    Figure 02140001
  • Figure 02150001
  • XML-Beispiel 33
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • Answer-2.2 – Nur auf Medienstrom-206-AP und Gruppen-AP referenzierend (in Bezug auf Stromassoziationen)
    Figure 02160001
  • XML-Beispiel 34
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele und Erklärungen.)
  • In diesem Fall kommen beim Forcieren der vorverhandelten APs sowohl der Anbieter 914 als auch der Antworter 911 implizit überein, indem sie ein Medienstreaming mit den durch das <default>-Konstrukt angezeigten Verträge 1108 starten.
  • Sollte jeder Peer aufgrund gewisser Bedingungen, die zur Zeit der Verhandlung 806 (und des Starts eines Medienstreamings, das unmittelbar nach der Verhandlung 806 angewendet würde) gelten, anders entscheiden, könnte eine reduzierte Version des <e2enp:qoscfg> inkludiert werden, das den oder die neuen vorgegebenen Verträge 1108 anzeigt.
  • Es sei daran erinnert, dass der vorgegebene Zustand im hierarchischen FSM-Modell mit dem Anfangszustand einer gegebenen (eventuell verschachtelten) FSM korrespondiert.
  • Im Fall der Wiederverhandlung 808 wird das „mode"-Attribut des <e2enp:purpose>-Abschnitts nicht benutzt.
  • Figure 02170001
  • Figure 02180001
    • Anmerkung (1): Beide Peers reservieren mit den wiederverhandelten QoS-Ebenen korrespondierende Ressourcen durch Hinzufügen irgendeiner erforderlichen Ressource und/oder Freigeben irgendeiner übermäßigen Ressource in Bezug auf die Menge vorher reservierter Ressourcen.
    • Anmerkung (2): Für eine Beschreibung der „Command-start-reservation" (Befehlstartreservierung) und „Command-ready-reservation" (Befehlbereitreservierung) wird auf die obige Beschreibung verwiesen.
    • Anmerkung (3). Das DO-Verfahren benutzt den einfachen, zuverlässigen Bestätigungsmechanismus des BYE-Verfahrens. Andere Verfahren sind auch möglich. Beispielsweise würde die Benutzung eines re-INVITE (Neu- bzw. Wiederauffordern, Neu- bzw. Wiedereinladen) die Dreiwegebestätigung forcieren, die garantiert, dass die Peers ein Medienstreaming mit der neuen QoS-Ebene in einer koordinierten und sicheren Weise beginnen. Es könnte zum Zwingen den Peer, ein anderes Endgerät zu benutzen, oder zum Ausführen einer End-zu-End-QoS-Vollwiederverhandlung 808 nützlich sein. Die Wahl des richtigen Verfahrens steht für die Diskussion offen.
    • Anmerkung (4): Die „Answer-3.1" in dieser Mitteilung charakterisiert das auf „start-reservation" eingestellte Attribut „type".
  • Im folgenden Abschnitt seien die mit den Schlüsselwörtern bid-x, answer-y in den vorherigen Beispielen angezeigten SIP-Mitteilungshauptteile beschrieben.
  • Bid-3.1
  • Bei diesem Beispiel fordert in Bezug auf die während der vorherigen Phasen (deren letzte durch das <session>-Element identifiziert ist, das von <use>-Element des <e2enp:purpose>-Abschnitts eingewickelt ist) schon verhandelte Information der Peer B den Peer A auf, einen alternativen QoS-Vertrag zu forcieren. Insbesondere fordert der Peer B den Peer A auf, den Stromebene-QoS-Vertrag 1108 „video-contract-2" anstelle des vorgegebenen einen „video-contract-1" in Bezug auf den Videomedienstrom 206 „video1" der gegenwärtig aktiven Assoziation „association1-1" zu forcieren. Dieser Befehl wird über den <enforce>-Abschnitt ausgedrückt. In diesem XML-Fragment ist die Benutzung von XPath in einer simplifizierten Weise gezeigt, um das Konzept des <enforce>-Abschnitts zu erfassen. Eine rigoros formale Beschreibung der gesamten hierdurch vorgeschlagenen SDPng-Erweiterungen wird zu späterer Zeit gegeben.
  • Außerdem entdeckt der Peer A, dass der „video-contract-1" nicht länger bei dem neuen Typ von Zugriffsnetzwerk 604/Netzwerkprovider anwendbar ist. Deshalb signalisiert der Peer A für diesen Vertrag 1108 „Blocken". Sollten Reserveverträge 1108 verfügbar und nun gültig sein, könnte in diesem Angebot (bid) ein „Entblocken"- bzw. „Freigabe"-Signal enthalten sein.
  • Figure 02200001
  • Figure 02210001
  • XML-Beispiel 35
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Alternativ dazu kann der Peer B dem Peer A auch einfach eine gewisse Information höherer Ebene anzeigen, in welcher der Peer A dann die verbleibende Information niedrigerer Ebene durch Zurückgreifen auf vorgegebene Werte auflösen würde.
  • Figure 02210002
  • Figure 02220001
  • XML-Beispiel 36
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Wäre Peer A gezwungen, den "video-contract-1" für den "video1"-Medienstrom 206 zu benutzen, da dieser Vertrag 1108 im vorverhandelten <e2enp:qoscfg>-Abschnitt als vorgegebenen spezifiziert war. Außerdem kann der Peer B den Peer A auffordern (request), auf eine total andere Gruppe von Medienströmen 206, die aus der vorverhandelten Information ausgewählt werden, zu schalten. Beispielsweise kann unter der Annahme, dass die gegenwärtig aktive Assoziation von Medienströmen 206 zwischen Peer A und B die „association1-1" ist, der Peer B den Peer A auffordern, die „association1-2" auszuwählen, wie im folgenden Beispiel des <e2enp:enforce>-Abschnitts:
    Figure 02220002
  • XML-Beispiel 37
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Answer-3.1
  • Gemäß dem Erfordernis 31 sollte der Antworter 911 seine Reaktion beschränken, um entweder das Angebot des Anbieters 914 anzunehmen oder einfach eine niedrigere QoS-Ebene, die aus der vorverhandelten Information auszuwählen ist, zu wählen. Dem im vorhergehenden Abschnitt angezeigten Beispiel folgend könnte der Peer A dann wählen, entweder den Vorschlag so wie er ist zu akzeptieren oder aus der vorverhandelten Information eine alternative Option auswählen, die noch das ursprüngliche Angebot des Anbieters 914 erfüllt.
  • Im ersteren Fall würde die „Answer-3.1" wie folgt aussehen:
    Figure 02230001
  • XML-Beispiel 38
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Die Abwesenheit des <e2enp:enforce>-Abschnitts in der Antwort des Antworters 911 zeigt an, dass der Antworter 911 dem Angebot des Anbieters 914 zugestimmt hat.
  • In dem Fall, dass der Antworter 911 (in diesem Beispiel der Peer A) eine niedrigere QoS-Ebene bevorzugte, würde die „answer-3.1" wie folgt aussehen.
  • Figure 02240001
  • Figure 02250001
  • XML-Beispiel 39
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Bei diesem Beispiel sei angenommen, dass ein "video-contract-3", der eine im Vergleich zu der durch den vorgeschlagenen „video-contract-1" definierten niedrigere Ebene der QoS definiert, vorher zwischen den zwei Peers (in den vorherigen Beispielen nicht gezeigt) verhandelt worden ist. Alternativ dazu kann der Peer A eine niedrigere Ebene der QoS durch Spezifizieren einer anderen Assoziation wie die im vorherigen Abschnitt beschriebene spezifizieren:
    Figure 02250002
    Figure 02260001
  • XML-Beispiel 40
    • (Bezüglich der Bedeutung der englischen Wörter in diesem Beispiel: siehe die vorhergehenden Beispiele.)
  • Im folgenden Abschnitt sei eine Vorverhandlung 802 in einem Eins-zu-Viele-Kommunikationsszenario 200 beschrieben.
  • – Push-Modus
    Figure 02260002
    • Anmerkung (1): Die verschiedenen Antworter „Answer-1.1.Bj" können koinzidieren, partiell differieren oder vollständig voneinander differieren. Im Wesentlichen sind sie äquivalent zu der oben beschriebenen „Answer-1.1".
    • Anmerkung (2): Nach Empfang aller Antworten von Peer Bj kann Peer A QoS-Korrelation-804- und Zeitsynchronisation-805-Beschränkungen forcieren und auf diese Weise mit den Peers Bj neue niedrigere QoS-Ebenen wiederverhandeln.
  • – Pull-Modus
    Figure 02270001
    • Anmerkung (3): Die verschiedenen Antworten "Answer-1.2.Aj" können koinzidieren, partiell differieren oder vollständig voneinander differieren. Im Wesentlichen sind „Answer-1.2.Aj" äquivalent zur oben beschriebenen „Answer-1.2". „Bid-1.2" ist im Wesentlichen äquivalent zu dem oben ebenso beschriebenen einen.
    • Anmerkung (4): Während der lokalen Zugriffskontrolle könnte der Peer B QoS-Korrelation-804- und Zeitsynchronisation-805-Beschränkungen forcieren, bevor er jedem Peer Aj antwortet, aber die verschiedenen Aj führen generell diese E2ENP-908-Phase unabhängig voneinander aus.
  • Deshalb ist es generell nicht möglich, Antworten auf OPTIONS über die korrespondierende SIP-Zeitgeberdauer hinaus zurückzubehalten. Alternativ dazu kann der Peer B entscheiden, eine Auf- bzw. Anforderung (request) innerhalb eines gewissen Zeitfensters zu akzeptieren, wonach der Peer B QoS-Korrelation-804- und Zeitsynchronisation-805-Beschränkungen forcieren und folglich neue Vorverhandlungen 802 mit jedem Peer Aj ausführen kann.
  • In diesem Fall würde der Peer B dann die Rolle des Anbieters 914 einnehmen. Als ein Beispiel könnte der Peer B ein Sender wie im Vorlesungsszenario sein, der mit jedem Empfänger zuerst individuell eine QoS vorverhandelt und dann eventuell eine gewisse Vorverhandlung 802 neu durchläuft, um QoS-Korrelation-804- und Zeitsynchronisation-805-Beschränkungen zu forcieren.
  • Bidirektionale Vorverhandlungsverbindungen für den Fall Eins-zu-Viele können in einer tatsächlichen Viele-zu-Viele-Verbindung resultieren. Deshalb wird dieser Fall hier nicht behandelt.
  • Eine bidirektionale Verhandlung 806 wird hierdurch nicht präsentiert, da dies in Fall eines Viele-zu-Viele-Szenarios resultieren kann, bei dem insbesondere Synchronisationsausgaben Aufmerksamkeit geschenkt werden sollte. Die folgenden Szenarios sind auf diese Weise für den Fall gültig, bei dem der „eine" Peer der Eins-zu-Viele-Beziehung ein Sender (Empfänger) ist und jeder der „vielen" Peers einer solchen Beziehung ein Empfänger (Sender) ist.
  • – Push-Modus
    Figure 02280001
  • Figure 02290001
    • Anmerkung (1): "Bid-2.1" ist im Wesentlichen äquivalent zu dem bei den vorhergehenden Beispielen beschriebenen einen.
    • Anmerkung (2): Ausgleichen (balance) von Ressourcen bei den Antworten von Bj durch Freigeben jeder übermäßigen Ressource.
    • Anmerkung (3): Durch Benutzung der Befehlstartreservierungs-Signalisierung kann der Peer A bestimmen, ob und wann die Netzwerkressourcenreservierungen auf der Basis aller {„Answer-2.1.Bj"} oder nur bezüglich welcher auch immer gegenwärtig verfügbaren Teilmenge davon ausgeführt werden sollte.
    • Anmerkung (4): Basiert auf der answer-2.1.Bj der Bj.
  • – Pull-Modus
    Figure 02300001
  • Figure 02310001
    • Anmerkung (5): Die verschiedenen Antworten "Answer-2.2.Aj" können koinzidieren, partiell differieren oder vollständig differieren.
    • Anmerkung (6): „Bid-2.2" und „Answer-2.2.Aj" sind im Wesentlichen äquivalent zu (korrespondierendem) „Bid-2.1" und „Answer-2.1", mit Ausnahme für den <e2enp:purpose>-Abschnitt, der das auf „pull" eingestellte Attribut „mode" charakterisiert und, im Fall der „Answer-2.2.Aj", das auf „start-reservation" eingestellte Attribut „name" charakterisiert.
    • Anmerkung (7): Auf der Basis der „Answer-2.2.Aj" der Bj.
    • Anmerkung (8): Durch Benutzung der Befehlstartreservierungs-Signalisierung kann der Peer A bestimmen, ob und wann Netzwerkressourcenreservierungen auf der Basis aller {„Answer-2.2.Aj"} oder nur welcher auch immer gegenwärtig verfügbaren Teilmenge davon ausgeführt werden sollte.
  • Ein verhandeln bidirektionaler Verbindungen für den Fall Eins-zu-Viele kann in einer tatsächlichen Viele-zu-Viele-Verbindung resultieren; deshalb wird dieser Fall hier nicht behandelt.
  • Generell sollte die Wiederverhandlung 808 von Mehrparteienverbindungen (wie es die Eins-zu-Viele- Verbindungen sind) äquivalent zu dem Fall von Eins-zu-Eins-Verbindungen angesehen werden. Das Erfordernis 37 führt zu nur zwei speziellen Fällen, wenn mehr als ein Medienstrom 206 simultan wiederverhandelt werden sollte. Diese zwei Fälle sind durch die folgenden Umstände bestimmt:
    • – Wenn die zentrale Komponente (die „Eine") eine Verletzung entdeckt, sollte sie prüfen, ob der beeinflusste Medienstrom 206 ein Medienstrom 206 einer Gruppe ist, und wenn er zu einer Gruppe gehört, der Kontext der Gruppe im Sinne der beeinflussten QoS ist. Durch einzelne Medienströme 206 und durch Entdecken, dass der Kontext der Gruppe nicht beeinflusst wird, führt die zentrale Komponente eine Eins-zu-Eins-Verhandlung 806 mit dem jeweiligen Peer aus, andernfalls führt die zentrale Komponente eine Eins-zu-Viele-Wiederverhandlung 808 aus, wie sie im ersten Fall unten beschrieben wird.
    • – Wenn eine der „Vielen" eine Verletzung entdeckt, signalisiert sie dies der zentralen Komponente auf einer Eins-zu-Eins-Weise, da die „Vielen" nichts über die eventuelle Medienstrom-206-Gruppierung wissen, die von der zentralen Komponente ausgeführt wird. Um zu entscheiden, wie fortzufahren ist, prüft die zentrale Komponente die Abhängigkeiten des beeinflussten Medienstroms 206. o Wenn der Medienstrom 206 nicht zu einer Gruppe gehört oder der Kontext der Gruppe nicht beeinflusst wird, führt die zentrale Komponente die Verhandlung 806 auf eine Eins-zu-Eins-Weise fort. o Wenn die zentrale Komponente Abhängigkeiten entdeckt, die nicht nur den einzelnen Medienstrom 206 beeinflussen, signalisiert sie dem wartenden Anbieter 914 (wie unten beschrieben – Fall 2), dass sie von nun an für die Wiederverhandlung 808 verantwortlich ist. Der Anbieter 914 sollte seinen Anruf beenden und auf ein Angebot von der zentralen Komponente warten.
  • Das Folgende sind die Beispiele bezüglich der zwei Eins-zu-Viele-Wiederverhandlung-808-Fälle:
    • 1. Die zentrale Partei einer gegebenen Eins-zu-Viele-Verbindung entdeckt eine Verletzung, die einen einzelnen Medienstrom 206 seiner gegebenen Gruppe beeinflusst, und führt entsprechend den Profileinstellungen (das heißt den vorverhandelten APs hoher Ebene) dieser Gruppe die notwendige Adaptierung der ganzen Medienstrom-206-Gruppe aus. Im Fall von Eins-zu-Viele-Verbindungen ist es in der Tat nur der als der „Eine" agierende Peer, der auf die Medienstrom-206-Gruppierung acht gibt.
      Figure 02340001
    • 2. Einer der "vielen" Peers entdeckt eine Verletzung:
      Figure 02350001
  • Im Folgenden sei ein Beispiel dafür beschrieben, wie eine Drittpartei-unterstützte Verhandlung unter Benutzung des E2ENP 908 durchgeführt wird.
  • Die verhandelnden Parteien sind:
    A – Der Peer, für den die Mediation ausgeführt wird,
    B – Der Vermittler- bzw. Mediatorpeer 106a1, und
    C – Der Anbieterpeer 914, der den Mediator 106a1 adressiert.
  • Die Drittpartei-unterstützte Verhandlung wird ausgelöst, wenn ein Anbieter 914 ein vermittelndes Gerät anruft und dieser jeweilige Peer entdeckt, dass er den Anruf selbst nicht behandeln kann, aber die Möglichkeit hat, den Anruf an einen anderen Antworter 911 zu deligieren. Der entdeckte Antworter 911 ist aus der Perspektive des Mediators 106a1 ein alternatives Gerät, das der anrufende Anbieter 914 anstelle des Mediators 106a1 und durch jeweilige Anerkennung des Benutzers, welches Gerät der Mediator 106a1 ist, benutzen kann.
  • Der Zweck der Vorverhandlung 802 mit einem Mediator 106a1 ist, dem Mediator 106a1 zu ermöglichen, Information über diejenigen Peers zu sammeln, die in mögliche zukünftige Umleitungen involviert sein können. Der Mediator 106a1 kann dies durch Benutzung gewisser Dienstentdeckungsmechanismen wie JINI, beschrieben in vom JINITM Network 604 Technology (cf. http://www.sun.com/jini/), im Folgenden als [JINI] bezeichnet, veröffentlichten Dokumenten, Bluetooth SDP, wie in [BLUE] beschrieben usw., oder durch direktes Anrufen der betroffenen Peers, für welche die Erleichterung (facilitation) ausgeführt wird, ausführen. Im letzteren Fall kann die Vorverhandlung 802 ähnlich zu dem Fall der Eins-zu-Eins-Vorverhandlung 802, bei welcher der Mediator 106a1 als der Anbieter 914 agiert und der Peer, für den die Vermittlung ausgeführt wird, als der Antworter 911 agiert, ausgeführt werden. Demgemäß ist eine spezielle Anzeige im <e2enp:purpose>-Abschnitt erforderlich, um anzuzeigen, dass der Anbieter 914 der Mediator 106a1 (<mediation mode=„third-party-assisted"/>) ist.
  • In dem Fall, dass die Partei, für welche die Vermittlung ausgeführt wird, die Vorverhandlung 802 mit dem Mediator 106a1 startet, ist das SIP-Schema wie folgt.
  • Figure 02360001
  • Figure 02370001
  • Der Mediator 106a1 nimmt gerade die Einstellungen von A (answer) auf und benutzt sie zum Ausführen der Mediation. Die Vorverhandlung 802 zwischen dem vermittelnden (mediating) Peer und dem Anbieter 914 ist sehr oft die gleiche wie bei der Eins-zu-Eins-Vorverhandlung 802, mit der Anzeige im „purpose"-Abschnitt, dass der Antworter 911 der Mediator 106a1 (<mediation mode=„third-party-assisted"/>) ist. Der Anbieter 914 sollte den Push- oder Push-Pull-Modus zum Auslösen der erleichternden Funktionalität des Mediators 106a1 benutzen. Anstelle der Benutzung von „200 OK" als „answer" für die OPTIONS benutzt der Mediator 106a1 „380 Alternative Service" (380 alternativer Dienst) und zeigt so an, dass es nicht der Peer ist, der zu kommunizieren beginnt. Der Anbieter 914 ist schon über diese Stufe über die Existenz eines alternativen Peers informiert, und in manchen Fällen, bei denen der angerufene Benutzer über die Benutzung des alternativen Peers informiert wird und zustimmt, kann der Anbieter 914 direkt eine Verhandlung 806 mit dem alternativen Peer durch Anwenden des Eins-zu-Eins-Verhandlungs-806-Schemas beginnen.
  • Die Drittpartei-unterstützte Verhandlung sollte immer im Push- oder Push-Pull-modus mit dem Mediator 106a1 ausgeführt werden, um die erleichternde Funktionalität des vermittelnden Peers in dem Fall auszulösen, dass er ein Angebot (bid) nicht unterstützen kann.
  • Figure 02370002
  • Figure 02380001
  • Als ein Resultat dieser Verhandlung weiß der Peer C, wer der Peer A ist, und seine Einstellungen können eine normale Eins-zu-Eins-Verhandlung mit ihm (siehe Eins-zu-Eins-Verhandlung-806-Beispiel) starten.
  • Die Ausführung einer Wiederverhandlung 808 über einen Mediator 106a1 macht nur im Fall einer vollen Wiederverhandlung 808, wenn ein neues Gerät, mit dem zu kommunizieren ist, gewählt werden sollte, Sinn, andernfalls würde die Wiederverhandlung 808 zu komplex. Dies würde in der Tat dem Erfordernis der Einfachheit des E2ENP 908 wiedersprechen und wäre in jedem Fall nicht wirklich logisch, da der Anbieter 914 schon aus der Verhandlung-806-Phase weiß, wer genau sein Antworter 911 ist. Durch eine über einen Mediator 106a1 gehende Wiederverhandlung 808 agiert der Mediator 106a1 als ein Proxy. Im Fall einer vollen Wiederverhandlung 808 ist dieser Prozess der gleiche wie bei der Vorverhandlung 802 und Verhandlung 806, die oben beschrieben sind. Durch eine Wiederverhandlung 808 sollte der Mediator 106a1 auch das Erfordernis bezüglich der Vollständigkeit der verhandelten Daten erfüllen.
  • Der Aufbau und die Verhandlung 806 der Viele-zu-Viele-Kommunikationsszenarios 300, 400 und 500 sind in Bezug auf die betrachteten Szenarios, beispielsweise Konferenzdurchführung, Spielen usw., kontextabhängig. Eine generelle Lösung ist für diesen Fall nicht möglich, aber durch Annehmen gewisser fertiger, themaabhängiger Szenarios, wie sie in „Models of Multi-party-Conferencing in SIP 910" (EITF SIP 910PING Working Group, work in progress, <draft-rosenberg-sip-conferencing-models-01.txt>) von J. Rosenberg und H. Schulzrinne, im Folgenden als [Rosen01] bezeichnet, und „Models for Multi-party Conferencing in SIP" (EITF SIPPING Working Group, work in progress <draft-ietf-sipping-conferencing-models-00.txt>) von J. Rosenberg und H. Schulzrinne, im Folgenden als [Rosen00a] bezeichnet, beschrieben sind, und Entwickeln derselben in Form des E2ENP 908 sollte verstehen helfen, wie das E2ENP 908 funktioniert, wenn Mehrparteienverbindungen angewendet werden. Das aus [Rosen01] genommene und in Form des E2ENP verbesserte Beispiel ist mit einer Ad-hoc-Vernetzung verbunden.
  • Unter Beachtung der Numerierung in 13 werden zur Anwendung des E2ENP 908 die folgenden Schritte berücksichtigt:
    • – Bei Nummer 1 – A übermittelt B seine QoS-Darstellung.
    • – Bei Nummer 4 – B übermittelt dem Konferenzserver die QoS- Darstellung von A und B.
    • – Bei Nummer 4 bis 14 – der Konferenzserver gibt seine Darstellung bezüglich der Konferenz (Nummer 5) an B ab, und B macht die Reservierungen für sich selbst bis zum Server.
    • – Bei Nummer 15 – A erlangt Kenntnis über die Konferenzserver-Darstellung bezüglich der Konferenz von B.
    • – Bei Nummer 17 – A fordert den Konferenzserver mit der vom B-Server abgebebenen Darstellung bezüglich der QoS auf. Dies ist gerade eine Referenz bezüglich der Server-QoS-Darstellung, da die beiden Seiten A und der Konferenzserver schon diese gemeinsame Ansicht kennen.
    • – Bei Nummer 17 bis 27 – A macht die Reservierungen für sich selbst bis zum Server.
    • – Bei Nummer 32 – B übermittelt C die Darstellung des Servers über die Konferenz.
    • – Bei Nummer 34 – C übermittelt dem Server seine entsprechend der Information von B eingeschränkte Darstellung bezüglich der Konferenz.
    • – Bei Nummer 34 bis 44 – C macht die Reservierungen für sich selbst bis zum Server.
    • – Bei Nummer 45 – C informiert B, dass er bereit ist.
    • – Bei den Nummern 49 bis 52 – B informiert zusätzlich den Konferenzserver darüber, dass alle Partner bereit sind und der Server an alle einen Startbefehl abgeben sollte.
  • Aus diesem Beispiel ist es evident, dass einige Ideen aus dem Eins-zu-Eins-Szenario, welche die Reservierungen betreffen, auch bei der Peer-zu-Peer-Kommunikation zwischen den Benutzern und dem Konferenzserver angewendet werden können. Die Angebote (bids) und die Antworten (answers) sind denen beim oben beschriebenen Eins-zu-Eins-Verhandlungsbeispiel gemeinsam. Dieses Beispiel zeigt die Reservierungsprozedur mit SIP-Mitteilungen in der gleichen Weise, wie beim Eins-zu-Eins-Szenario, wobei der einzige Unterschied ist, welche Art von Mitteilungen als SDPng-Aufwand gesetzt werden. Gemäß dem obigen Beispiel gibt es drei verschiedene Rollen, welche die End-Peers spielen können:
    • – Ad-hoc-Conferenzinitiator – wie B
    • – Schon-Konferenzteilnehmer – wie A
    • – Neu-Konferenzteilnehmer – wie C
  • Diese drei Rollen korrespondieren mit drei verschiedenen Kommunikationsmustern mit dem Konferenzserver in Bezug auf die ausgetauschten SDPng-Mitteilungen.
  • Den größten Kommunikationsaufwand hat B (der Ad-hoc-Konferenzinitiator), da er alle SDPng-Mitteilungen der Schon-Konferenzteilnehmer überträgt. Diese Fähigkeit von B ist eine Art Mediationsfähigkeit zum Initialisieren der Konferenz durch Forcieren der betroffenen Peers, mit dem Konferenzserver zu verhandeln, und durch Beendigen der Verhandlung, um die Steuerungen bzw. Kontrollen zum Server zu übertragen.
  • Den kleinsten Kommunikationsaufwand hat ein Schon-Konferenzteilnehmer wie A, da der Konferenzserver schon über das Profil von A über B informiert ist und A nur den Server daran zu erinnern braucht, welches Profil ihm gehört (siehe 13 – Mitteilung 17).
  • Der Neu-Konferenzteilnehmer C erlangt Kenntnis über die validierten Profile der Schon-Konferenzteilnehmer vom Konferenzserver und minimiert auf diese Weise seine Entscheidungseinstellung und ermöglicht ihm, eine schnellere Übereinkunft mit dem Konferenzserver zu treffen. Der Kommunikationsaufwand von C ist somit annähernd der gleiche wie bei der Eins-zu-Eins-Kommunikation, da er die Übereinkunft mit dem Server selbst zu treffen hat.
  • Die folgenden Beispiele stellen einige der oben beschriebenen Fehlerfälle dar.
  • Eins-zu-Eins-Kommunikationsszenario 100
  • – Vorverhandlung 802:
    Figure 02420001
    • Anmerkung (1): Der Antworter 911 antwortet mit „600 Busy", wenn es im Moment keine Kapazität zum Behandeln jedes Anrufs gibt. Alternativ dazu kann der Antworter 911 mit „603 Decline" antworten, was anzeigt, zu welcher späteren Zeit der Anruf stattfinden kann, sollte diese Zeit bekannt sein. Das gleiche kann sowohl beim Push- als auch Pull-modus benutzt werden, aber im Pull-Modus enthält der „OPTIONS"-Ruf kein Angebot (bid):
  • – Verhandlung 806:
    Figure 02420002
  • Figure 02430001
    • Anmerkung (2): Der Antworter 911 gibt "600 Busy" (600 Belegt) ab, wenn ein gewisser anderer Anbieter 914 bei der Abgabe des Anrufs schneller war und alle verfügbaren Kapazitäten des Antworters 911 belegt hat. Der Antworter 911 gibt „603 Decline" (Verweigern) ab, wenn ein gewisser anderer Anbieter 914 mit der Ausgabe des Anrufs schneller war und alle verfügbaren Kapazitäten des Antworters 911 belegt hat, aber der Antworter 911 weiß, wie lange der Anruf fortgesetzt werden soll. Dies ist auch der Fall, wenn in dem Moment in Bezug auf die Priorität eine ähnliche Transaktion verarbeitet wird und der Anrufer zu warten hat. Der Antworter 911 gibt „606 Not Acceptable" (606 Nicht Akzeptabel) ab, wenn der Anbieter 914 um QoS-Unterstützung, die im Moment nicht verfügbar ist, bittet. Der Antworter 911 gibt „380 Alternative Service" (380 Alternativer Dienst) ab, wenn die Bedingungen des Anbieters 914 für ihn nicht akzeptabel sind, aber er einen alternativen Dienst kennt, der diese Bedingungen unterstützen kann. Dieser Anruf sollte mit automatischen Diensten wie VoD benutzt werden. Bei jedem der obigen Fälle kann der Anbieter 914 einen neuen Anruf mit „OPTIONS" starten, da die vorverhandelten Bedingungen nicht länger gültig zu sein brauchen. Dieses Schema ist für alle Kommunikationsmoden (Push, Pull, Push-Pull) anwendbar. Der einzige Unterschied zwischen ihnen ist das Senden eines anfänglichen Angebots (bid) mit dem „INVITE" oder sein späteres Senden (Pull-modus)-
    • – Wiederverhandlung 808: Die Fehlerfälle durch Wiederverhandlung 808 sind die gleichen wie bei der Verhandlung 806. Die jeweiligen Fehleranzeigen werden zu den „DO"-Anrufen des Anbieters 914 als eine Antwort zurückgebracht.
  • Die Struktur der Verhandlung-806-Phasen durch das Eins-zu-Viele-Szenario ähnelt sehr viel dem Eins-zu-Eins-Szenario, und bis zu diesem Grad sind in diesem Fall die beim Eins-zu-Eins-Szenario beschriebenen E2ENP-908-Fehlerfälle ebenfalls gültig. Da das Eins-zu-Viele-Szenario mit der Möglichkeit mehrerer Fehler, die von den „vielen" Peers verursacht werden, verbunden ist, sollte die (die „eine") zentrale Komponente die Fähigkeit aufweisen, solchen Fehlern zu begegnen. Das Folgende sind einige Vorschläge, wie diese behandelt werden können.
    • – Jede Verhandlung-806-Verbindung zwischen dem als die „Eine" agierenden Peer und jeder der als die „Vielen" agierende sollte in Bezug auf die SIP-910-Signalisierung als ein einzelner alleinstehender betrachtet werden. Auf diese Weise brauchen die in die Verhandlung-806-Phase involvierten, als „viele" agierenden Peers nichts über die Fehler zu wissen, die einige Peers der Gruppe machen. Die Fehlerbehandlung findet nur bei der zentralen Komponente statt.
    • – Wenn einige der Verhandlung-806-Verbindungen nicht innerhalb der Zeitgrenze erfolg haben, würden sie zu einer späteren Zeit für eine wiederholte Verhandlung 806 angerufen. Die zentrale Komponente würde dies entweder durch eine Auszeit eines SIP-910-Anrufs oder durch Empfangen einer SIP-Fehlermeldung von der angerufenen Partei detektieren. Da das E2ENP 908 das Erfordernis für Konsistenz, aber nicht für Isolation hat, wäre genug zum Sichern der laufenden Daten der nicht erfolgreichen Anrufe vorhanden, um vor dem Fehler eine Referenz bezüglich ihres laufenden Zustands durch die Wiederholung des Anrufs zu haben. Dies bedeutet, dass kein die E2ENP-908-Läufe sichernder vollständiger Zustand notwendig ist, da kein „undo" (annulieren) notwendig ist.
    • – Die zentrale Partei sollte dazu fähig sein, die Medienströme 206 online zu rekonfigurieren. Wenn einige der Medienströme 206 innerhalb der Zeitgrenze nicht wiederverhandelt werden können, rekonfiguriert die zentrale Komponente demgemäss nur diejenigen, die Erfolg haben, und versucht, die nicht erfolgreichen zu einem späteren Moment wiederzuverhandeln. Hier wiederum brauchen die erfolgreichen Verhandlungen 806 nicht zu wissen, dass gewisse von ihnen ausgefallen sind.
    • – Die zentrale Komponente versucht, die Parteien mit nicht erfolgreicher Verhandlung 806 mehrmals, aber eine begrenzte Anzahl, beispielsweise 3-mal, anzurufen. Wenn es Parteien gibt, deren Verhandlung-806-Phasen nach dem dritten Anruf nicht erfolgreich sind, würden sie aus der Gruppe geworfen, und ihre Medienströme 206 würden eventuell beseitigt, wenn beispielsweise die RTP-Signalisierung über die Datenverbindung auch nicht existent ist. Diese Lösung sollte den nicht erfolgreichen „Vielen" die Möglichkeit geben, die Chance zu einer Wiederherstellung und eines eventuellen Starts des Verhandlung-806-Anrufs durch sie selbst zu haben.
    • – Die parallele Performance der Verhandlung-806-Anrufe ermöglicht die schnelle Ausführung der Verhandlung 806. Demgemäss sollte die zentrale Komponente die Möglichkeit haben, ihre Ressourcen flexibel zu rekonfigurieren. Es ist notwendig zu wissen, wie viele Parteien die zentrale Komponente parallel bedienen kann, und ob diese Grenze die Zentralkomponentenausgaben „486 Busy Here" (486 belegt hier) oder „280 Alternative Service" überschreitet (wenn die zentrale Komponente ein Dienst ist und einen alternativen kennt).
  • Der folgende Abschnitt betrifft den Fall eines Drittparteiunterstützten E2ENP 908, bei dem die Verschiebung-108-Suche (relocation 108 search) ausfällt:
    Figure 02460001
  • Der Mediator 106a1 signalisiert, dass keine Alternative gefunden wurde und der Anbieter 914 wieder im Pull-Modus anrufen sollte, um sich an die Einstellungen des Mediators 106a1 anzupassen.
  • Wenn der Benutzer die Anrufverschiebung 108 verweigert, ist das mögliche Resultat der Verhandlung 806:
    Figure 02470001
    Figure 02480001
  • Der Mediator 106a1 antwortet mit:
    • – „480 Temporarily Unavailable" (480 Vorübergehend Nicht Verfügbar), wenn der Benutzer auf das Signal oder das aufgepoppte (von unten nach oben aufgebaute) Fenster für eine gewisse Zeit nicht reagiert, sie/er sollte als nicht verfügbar angesehen werden.
    • – „603 Decline" (603 Verweigern), wenn der Benutzer den Anruf explizit ablehnt.
    • – „606 Not Acceptable" (606 Nicht Akzeptabel), wenn der Benutzer die Delegierung des Anrufs ablehnt.
  • Wenn die Verhandlung 806 mit dem erwarteten Antworter 911 (die C-Partei) nicht erfolgreich ist, oder die Partei, zu der zu delegieren ist, den Anruf nicht akzeptiert.
  • Figure 02480002
  • Figure 02490001
  • Die Bedeutung dieser Antworten ist:
    • – „480 Temporarily Unavailable", wenn der Benutzer auf das Signal oder das aufgepoppte Fenster für eine gewisse Zeit nicht reagiert, sie/er sollte als nicht verfügbar angesehen werden.
    • – „603 Decline", wenn der Benutzer den Anruf explizit verweigert.
    • – „606 Not Acceptable", wenn der Benutzer kommunizieren will, aber die Delegierung des Anrufs schief gegangen ist. Diese Antwort würde die Initiierung einer neuen Verhandlung 806 mit dem Mediator 106a1 als ein Antworter 911 ermöglichen; der Anbieter 914 sollte auf die Ausführung der neuen Verhandlung 806 im Pull-Modus acht geben, um sich selbst an das Profil des Mediators 106a1 durch nicht Auslösen seiner erleichternden Funktionalität anzupassen.
  • Zum Schluss können die hauptsächlichen vorteilhaften Unterschiede zwischen der zugrundeliegenden Erfindung und dem Stand der Technik kurz wie folgt zusammengefasst werden:
    • – Benutzung des SDPng 912 zur Implementierung des E2ENP-908-Konzepts und dadurch Ausbauen der durch eine XML-basierte Dokomentstruktur gebotene Flexibilität,
    • – Definition einer klaren Schnittstelle zwischen dem E2ENP 908 und Anwendungen aufgrund der Benutzung expliziter Identifizierer, die eine gegebene SDPng-912-Beschreibung auf eine gegebene Phase des E2ENP-908-Prozesses eindeutig abbilden,
    • – Fähigkeit der gleichzeitigen Beschreibung einer Hierarchie von QoS-Kontexten für mehrere Multimedienströme 206,
    • – Fähigkeit der gleichzeitigen Verhandlung einer Hierarchie von QoS-Kontexten für mehrere Multimedienströme 206,
    • – Inkrementelle Verhandlung der Hierarchie von QoS-Kontexten für mehrere Multimedienströme 206 durch Benutzung des Konzepts von Sessionen und Phasen, und
    • – das Konzept einer Vielfalt von externen E2ENP-Mediatoren, die durch den Transcoding-Service-Kern kontrolliert werden, wird als eine durch diese Erfindung vorgeschlagene Neuigkeit angesehen.
  • Tabelle 1: Benutzte Abkürzungen
    Figure 02510001
  • Figure 02520001

Claims (45)

  1. Verfahren zum Austauschen von Medienströmen zwischen End-Peers (810, 811) in einem Netzwerk und zur Stützung des End-to-End Negotation Protocol (E2ENP, 908), wobei die End-to-End-QoS-Verhandlung die Schritte aufweist: – Vorverhandeln (802) mehrerer QoS-Verträge vor der Stromherstellung, – Durchführen einer QoS-Korrelation (804) und Zeitsynchronisation (805) mehrerer Ströme oder einer Gruppe von Strömen, – Verhandeln (806) der Benutzung eines der vorverhandelten (802) QoS-Verträge vor oder zu der Zeit der Stromherstellung, und – Wiederverhandeln (808) eines QoS-Vertrags aus den vorverhandelten (802) Verträgen nach der Detektion einer QoS-Änderung oder -Verletzung, gekennzeichnet durch die Benutzung des Session Description Protocol Next Generation (SDPng, 912) zum Definieren von als Eingabe für das E2ENP (908) zu benutzender Benutzerprofilinformation.
  2. Verfahren nach Anspruch 1, gekennzeichnet durch die Benutzung des SDPng (912) zum Definieren von als Eingabe für das E2ENP (908) zu benutzender Endgerätfähigkeitsinformation.
  3. Verfahren nach einem der Ansprüche 1 und 2, gekennzeichnet durch eine Vorverhandlung (802) von Ressourcenmanagementgrundsätzen zwischen verschiedenen Peers.
  4. Verfahren nach einem der Ansprüche 1 bis 3, gekennzeichnet durch ein Konzept von Ersatzverträgen (1108) und des Konzepts eines Zustands-Blockens oder -Entblockens, das jeweils auf der Anwesenheit oder Abwesenheit von Ersatzmerkmalen in der zugrundeliegenden Vertragsbeschreibung (1108) über die Zulassung des gegenwärtigen Netzwerkproviders basiert.
  5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass Ersatzverträge (1108) derart pro-aktiv verhandelt werden, dass sie in dem Fall, dass Übergabesituationen auftreten und wenigstens einer der Ersatzverträge (1108) anwendbar wird, benutzt werden können.
  6. Verfahren nach einem der Ansprüche 1 bis 5, gekennzeichnet durch eine Signalisierung eines Zustands-Blockens oder Zustands-Entblockens während einer Wiederverhandlung (808), immer wenn eine durch eine Übergabesituation verursachte Technologieänderung und/oder Änderung des jeweiligen Netzwerkproviders stattfindet.
  7. Verfahren nach einem der Ansprüche 1 bis 6, gekennzeichnet durch eine detaillierte Abbildung des E2ENP (908) auf das SIP (910) via Huckepack.
  8. Verfahren nach einem der Ansprüche 1 bis 7, gekennzeichnet durch eine Signalisierungsstützung einer Drittpartei-unterstützten Verhandlung.
  9. Verfahren nach einem der Ansprüche 1 bis 8, gekennzeichnet durch eine Signalisierungsstützung eines Eins-zu-Viele-Kommunikationsszenarios (200) und Viele-zu-Viele-Kommunikationsszenarios (300, 400 und 500).
  10. Verfahren nach einem der Ansprüche 1 bis 9, gekennzeichnet durch das Konzept einer Entwicklung von E2ENP-Signalisierungssessionen, das jedes Vertragsresultat früherer E2ENP-Singalisierungssessionen inkremental auswertet, wodurch jede E2ENP-Singalisierungssession mit einer der verschiedenen E2ENP-Phasen (802, 804, 805, 806, 808) korrespondiert.
  11. Verfahren nach Anspruch 10, gekennzeichnet durch das Konzept einer Entwicklung von (Mikro- und/oder Makro-)E2ENP-Phasen, die in einer mittels mehrerer Referenzketten gebildeten baumartigen Struktur logisch angeordnet sind.
  12. Verfahren nach einem der Ansprüche 10 und 11, gekennzeichnet durch das Konzept eines Leasens von Subbäumen für verschiedene (Mikro- und/oder Makro-)E2ENP-Phasen, die in baumartigen Strukturen angeordnete sind.
  13. Verfahren nach einem der Ansprüche 10 bis 12, gekennzeichnet durch das Konzept einer Entwicklung von Zombiezuständen für die verzögerte Freigabe verfallener Subbäume für die (Mikro- und/oder Makro-)E2ENP-Phasen, Subbäume, die dann freigegeben werden, sobald alle hängigen Verbindungen geschlossen sind.
  14. Verfahren nach einem der Ansprüche 10 bis 13, gekennzeichnet durch das Konzept einer inkrementalen Verhandlung für Mikrophasen.
  15. Verfahren nach einem der Ansprüche 10 bis 14, wobei das RTP angewendet wird, wobei während des Medienströmens der Peers (602a/b/c) eine Wiederverhandlung (808) ausgeführt wird, die auf einem sich auf einen vorverhandelten Quality-of-Service-Vertrag (1108) und einen vorverhandelten Satz von Fähigkeiten beziehenden vorverhandelten Zustand basiert ist, dadurch gekennzeichnet, dass – ein Sender-Peer (602a/b/c) entscheiden kann, das Format des Medienstroms (206) durch Anwendung anders verhandelter Codecs zu ändern und diese Änderung durch Benutzung eines wohlbekannten Inbands durch Einsetzen des RTP-Nutzinformationstyps in die RTP-Header zu einem oder mehreren Empfängern zu senden, wobei der Nutzinformationstyp, immer wenn er in einem abgemachten QoS-Vertrag (1108) verbleibt, mit den neuen Codecs korrespondiert, – oder der Sender-Peer (602a/b/c) eine E2ENP-Signalisierung explizit benutzen kann, wenn eine QoS-Verletzung und/oder eine QoS-Änderung auftritt und/oder QoS-Korrelations- (804) und Zeitsynchronisations-Einschränkungen (805) über mehreren Medienströmen (206) einzuhalten sind.
  16. Verfahren nach einem der Ansprüche 10 bis 15, gekennzeichnet durch das Konzept von NULL-Strömen zum expliziten Stoppen von Medienströmen (206) im Fall von Bandbreitenverringerungen, um Telekommunikationssessionen (102) flexibel aufrechtzuerhalten.
  17. Verfahren nach einem der Ansprüche 10 bis 16, dadurch gekennzeichnet, dass Peers (602a/b/c) während des Vorverhandlungsschritts (802) Sätze von Quality-of-Service-Verträgen (1108) auf einer Per-Strom-Basis und/oder einer Per-Strom-Assoziations-Basis beim feinsten Auflösungspegel, bei dem Medienstrom-Assoziationen Bündel aus Medienströmen (206) von einem Sender-Peer (602a/b/c) zu einem Empfänger-Peer (602a/b/c) sind, verhandeln.
  18. Verfahren nach einem der Ansprüche 1 bis 17, dadurch gekennzeichnet, dass Peers (602a/b/c) über Änderungen bei Quality-of-Service- und/oder Fähigkeits-Konfigurationen via E2ENP-Signalisierung informiert werden.
  19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass vorverhandelte alternative Quality- und Konfigurationsinformation eines gegebenen Typs von Medienstrom (206) schon bei einem Server für Clients zum Auswählen verfügbar ist.
  20. Verfahren nach einem der Ansprüche 1 bis 19, aufweisend die Schritte: Protokollentdeckung, Vorverhandlung (802), optionale Multimedienstrom-QoS-Sychronisation und QoS-Korrelation (804), ein Ökonomieprinzip anwendende Schnellverhandlung, das Ökonomieprinzip und Ressourcenreservierungsfreigabe anwendende Wiederverhandlung (808).
  21. Verfahren nach Anspruch 20, wobei die sechs Phasen optional mehrere Male angewendet werden können, wobei sie entweder kontinuierlich oder zu verschiedenen Zeiten konzentriert und ausgeführt werden und dabei der in Anspruch 32 gezeigten Ordnung folgen.
  22. Verfahren nach Anspruch 21, wobei die Multimedienstrom-Zeitsynchronisations- (805) und QoS-Korrelationsphase (804) optional und nur erforderlich ist, wenn ein Initiator durch Verwendung mehrerer zu korrelierender und synchronisierender Medienströme (206) auf der Basis von nur auf der Initiatorseite zu erfüllenden Benutzergrundsätzen mit mehreren Peers (602a/b/c) kommuniziert.
  23. Verfahren nach Anspruch 22, wobei die Protokollentdeckungs- und Vorverhandlungsphasen (802) a priori ausgeführt werden und die Resultate dann bei mehreren sukzessiven Signalisierungssessionen (103) zur Herstellung mehrerer sukzessiver Telekommunikationssessionen (102) angewendet werden können, wobei jede Telekommunikationssession (102) mit einer spezifischen optionalen Multimedienstrom-Zeitsynchronisations- (805) und QoS-Korrelationsphase (804) initiiert wird.
  24. Verfahren nach Anspruch 23, wobei, wenn die Resultate der Multimedienstrom-Zeitsynchronisationphase (805) und QoS-Korrelationsphase (804) bei mehreren sukzessiven Telekommunikationssessionen (102), die mit einer spezifischen Schnellverhandlungsphase (806) initiiert werden können, anwendbar sind.
  25. Verfahren nach einem der Ansprüche 20 bis 24, wobei das Protokoll während Vorverhandlungs- (802), Multimedienstrom-Zeitsynchronisations- (805) und QoS-Korrelations- (804), Schnellverhandlungs- (806), Wiederverhandlungs- (808) und Ressourcenfreigabephasen mit lokalen Ressourcenmanagementeinheiten interagiert.
  26. Verfahren nach einem der Ansprüche 20 bis 25, wobei während der Laufzeit einer so hergestellten Multimediensession (102) zu jeder Zeit jede Komponente jedes Peers (602a/b/c) eine Anpassung anfordern und so eventuell eine Wiederverhandlungsphase (808) auslösen kann.
  27. Verfahren nach einem der Ansprüche 20 bis 26, aufweisend den Schritt einer Vorverhandlung (802) des Typs des E2ENP (908) während der Protokollentdeckungsphase entweder durch Auffordern von Peers, einen Verzeichnisserver, der als ein SIP-Registrator implementiert sein kann, abzufragen, oder dadurch, dass die Peers eine solche Information ankündigen.
  28. Verfahren nach Anspruch 27, aufweisend den Schritt einer Vorverhandlung (802) verschiedener Fähigkeiten während der Vorverhandlungsphase (802).
  29. Verfahren nach einem der Ansprüche 20 bis 28, aufweisend den Schritt einer Vorverhandlung (802) einer vollständigen Codec-Liste während der Vorverhandlungsphase (802).
  30. Verfahren nach einem der Ansprüche 20 bis 29, aufweisend den Schritt einer Vorverhandlung (802) von Adaptierungspfaden auf Medienstromniveau während der Vorverhandlungsphase (802).
  31. Verfahren nach einem der Ansprüche 20 bis 30, aufweisend den Schritt einer Vorverhandlung (802) von Adaptierungspfaden auf Medienstrom-Aggregationsniveau während der Multistrom-Zeitsynchronisationsphase (805) und der QoS-Korrelationsphase (804).
  32. Verfahren nach einem der Ansprüche 20 bis 31, gekennzeichnet durch die Schritte: – Indizierung von vorverhandelten QoS-Verträgen (1108) und Fähigkeiten zur Beschleunigung der Schnellverhandlungsphase (806), und – Indizieren von vorverhandelten QoS-Verträgen (1108) und Fähigkeiten zur Beschleunigung der Wiederverhandlungsphase (808).
  33. Verfahren nach einem der Ansprüche 20 bis 32, gekennzeichnet durch den Schritt: Abwickeln einer Installierung und/oder Deinstallierung von Fähigkeiten auch bei Laufzeit durch Austauschen asynchroner Nachrichten zwischen Peers (602a/b/c) zur Mitteilung solcher Ereignisse.
  34. Verfahren nach einem der Ansprüche 1 bis 33, dadurch gekennzeichnet, dass die Verhandlung und die Benutzung von Sessions-Identifizierern von Sessions-Identifizierertupeln via Hash abgeleitet wird, um die Größe von E2ENP-PDUs zu begrenzen, wobei die vollständigen Sessions-Identifizierertupel, deren jedes wenigstens ein kalkuliertes Hash aufweist, in der ersten PDU jeder gegebenen E2ENP-Phase oder ihrer Verkettung benutzt werden.
  35. Verfahren nach einem der Ansprüche 1 bis 33 und 34, dadurch gekennzeichnet, dass das E2ENP (908) eine Drittpartei-unterstützte Verhandlung mittels eines Vermittlers (106a1) umfasst.
  36. Verfahren nach einem der Ansprüche 1 bis 33, 34 und 35, gekennzeichnet durch E2ENP-Mechanismen zur Einhaltung von Konsistenz und Vermeidung von Blockierungen.
  37. Verfahren nach einem der Ansprüche 1 bis 33 und 34 bis 36, dadurch gekennzeichnet, dass das E2ENP (908) Eins-zu-Eins-Kommunikationsszenarios (100), Eins-zu-Viele-Kommunikationsszenarios (200) und Viele-zu-Viele-Kommunikationsszenarios (300, 400) behandeln kann.
  38. Verfahren nach einem der Ansprüche 1 bis 33 und 34 bis 37 gekennzeichnet durch einen Codeumsetzungsdienst, der zum Verkoppeln von Codeumsetzungseinheiten mit SIP-Proxies und Verzeichnisdiensten benutzt wird, um dem Anbieter (914) zu ermöglichen, eine spezifische Codeumsetzungseinheit oder eine Kette daraus zu benutzen, immer wenn es erforderlich ist.
  39. Verfahren nach Anspruch 38, dadurch gekennzeichnet, dass der Anbieter (914) die Möglichkeit hat, vom Netzwerkbetreiber oder jedem anderen Dienstprovider Unterstützung anzufordern, um durch Managen einer Dreiparteienverhandlung zwischen dem Anbieter (914), den verschiedenen Codeumsetzern in der Mitte und dem Antworter (911) einen Codeumsetzungsdienst bereitzustellen, immer wenn die E2ENP-Session zwischen diesen End-Peers (914, 911) in dem Fall versagt, dass keine Übereinkunft erreicht worden ist.
  40. Verfahren nach einem der Ansprüche 38 und 39, dadurch gekennzeichnet, dass der Codeumsetzungsdienst die Paarbildung von Knoten in jeder Kette aus Peers (911, 914) orchestriert und darauf achtet, dass Ressourcen via das E2ENP-Ökonomieprinzip richtig reserviert werden.
  41. Verfahren nach einem der Ansprüche 38 bis 40, gekennzeichnet durch eine Kooperation von Codeumsetzungsdiensten, die von verschiedenen Providern durch Benutzung des E2ENP (908) angeboten werden, zur Ausführung einer Dreiparteienverhandlung.
  42. Verfahren nach einem der Ansprüche 34 bis 41, dadurch gekennzeichnet, dass die Fehlerbehandlung des E2ENP (908) durch Anwenden von Fehlercodes auf ein Signal sowohl bei internen als auch externen Ausfallzuständen, Ablaufunterbrechungen und Fehlern, die bei jedem der bei der vom E2ENP (908) beeinflussten E2ENP-Signalisierung involvierten Peers (911, 914) auftreten, symmetrisch ist.
  43. Computersoftwareprogrammprodukt, dadurch gekennzeichnet, dass es ein Verfahren nach einem der Ansprüche 1 bis 33 implementiert, wenn es auf einer Datenverarbeitungseinrichtung läuft.
  44. Peer, konfiguriert zum Implementieren eines Verfahrens nach einem der Ansprüche 1 bis 33, aufweisend eine Koordinierungseinheit, welche die verschiedenen Phasen des End-to-End Negotiation Protocol (E2ENP) des verteilten Ressourcenmanagementprozesses koordiniert, dadurch gekennzeichnet, dass d ie Koordinierungseinheit eine Protokollentdeckung befiehlt und dann eine Vorverhandlungs- (802), optionale Multistrom-Zeitsynchronisations- (805) und QoS-Korrelationsphase (804), Schnellverhandlungphase mit Ökonomieprinzip, Wiederverhandlungphase (808) mit Ökonomieprinzip und Ressourcenreservierungsfreigabephase auslöst und koordiniert.
  45. Peer nach Anspruch 35, gekennzeichnet durch eine Sessionsprotokolleinheit, die der Koordinierungseinheit erlaubt, die verschiedenen Phasen des End-to-End Negotiation Protocol (E2ENP) auszuführen.
DE60203779T 2002-01-23 2002-01-28 Ein Verfahren zur Übertragung von End-to-End QoS durch Anwendung des end-to-end negotiation protocols (E2ENP) Expired - Lifetime DE60203779T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP02001600 2002-01-23
EP20016002 2002-01-23
EP02001900A EP1331785B1 (de) 2002-01-23 2002-01-28 Ein Verfahren zur Übertragung von End-to-End QoS durch Anwendung des end-to-end negotiation protocols (E2ENP)

Publications (2)

Publication Number Publication Date
DE60203779D1 DE60203779D1 (de) 2005-05-25
DE60203779T2 true DE60203779T2 (de) 2006-03-09

Family

ID=27614615

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60203779T Expired - Lifetime DE60203779T2 (de) 2002-01-23 2002-01-28 Ein Verfahren zur Übertragung von End-to-End QoS durch Anwendung des end-to-end negotiation protocols (E2ENP)

Country Status (8)

Country Link
US (1) US7602723B2 (de)
EP (1) EP1331785B1 (de)
JP (1) JP4342948B2 (de)
CN (1) CN1623308B (de)
AT (1) ATE293863T1 (de)
DE (1) DE60203779T2 (de)
ES (1) ES2236370T3 (de)
WO (1) WO2003063439A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015001622A1 (de) 2015-02-09 2016-08-11 Unify Gmbh & Co. Kg Verfahren zur Übertragung von Daten in einem Multimedia-System, sowie Softwareprodukt und Vorrichtung zur Steuerung der Übertragung von Daten in einem Multimedia-System

Families Citing this family (199)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE372639T1 (de) * 2000-12-08 2007-09-15 Sony Deutschland Gmbh Schnittstelle auf hoher ebene für dienstqualitätbasierte mobile multimedia- anwendungen
US8037188B2 (en) * 2003-02-12 2011-10-11 Qualcomm Incorporated Soft handoff across different networks assisted by an end-to-end application protocol
US7912902B2 (en) * 2003-02-13 2011-03-22 Telcordia Licensing Company, Llc Application service peering and aggregation
US7284054B2 (en) * 2003-04-11 2007-10-16 Sun Microsystems, Inc. Systems, methods, and articles of manufacture for aligning service containers
US20050021840A1 (en) * 2003-07-11 2005-01-27 Nokia Corporation Method and an apparatus for enhancing messaging
GB2406464B (en) * 2003-09-29 2006-07-05 Siemens Ag Network entity
US7644182B2 (en) * 2004-03-11 2010-01-05 Hewlett-Packard Development Company, L.P. Reconfiguring a multicast tree
EP1610492B1 (de) * 2004-06-21 2007-04-11 Matsushita Electric Industrial Co., Ltd. Skalierbare und adaptive QoS-Architektur für Mehrkanal Multicast/Broadcast Dienste
US7574510B2 (en) * 2004-07-30 2009-08-11 Nokia Corporation Systems, nodes, and methods for dynamic end-to-end session-enhancing services for transport-level-based connections
US20060072541A1 (en) * 2004-09-28 2006-04-06 Vivian Pecus Network management system & method
US20060083242A1 (en) * 2004-10-20 2006-04-20 Nokia Corporation Address modification in application servers
KR100561686B1 (ko) * 2004-10-22 2006-03-15 에스케이 텔레콤주식회사 이동통신망에서의 화상통화 서비스 제공 방법
US7369502B2 (en) * 2004-12-02 2008-05-06 Cisco Technology, Inc. Intelligent provisioning of DSP channels for codec changes
KR100599174B1 (ko) * 2004-12-16 2006-07-12 삼성전자주식회사 프로파일 정보를 이용한 서비스 제공방법 및 서비스제공시스템
KR100688079B1 (ko) 2004-12-17 2007-03-02 한국전자통신연구원 개인화 서비스를 위한 프로파일 정보 분류 및 처리 방법그리고 이를 이용한 개인화 서비스 제공 시스템
DE102004063298B4 (de) * 2004-12-29 2006-11-16 Infineon Technologies Ag Verfahren zum rechnergestützten Verwalten von Kommunikationsrechten zum Kommunizieren mittels mehrerer unterschiedlicher Kommunikationsmedien in einer Telekommunikations-Konferenz mit mehreren Telekommunikations-Einrichtungen
US8159999B2 (en) 2005-01-25 2012-04-17 Interdigital Technology Corporation Peer-to-peer wireless communication system
US8077635B2 (en) 2005-01-28 2011-12-13 Cisco Technology, Inc. Method and system for reserving facility resources for a conference
US20060218353A1 (en) * 2005-03-11 2006-09-28 Interdigital Technology Corporation Method and apparatus for implementing path-based traffic stream admission control in a wireless mesh network
US7583662B1 (en) * 2005-04-12 2009-09-01 Tp Lab, Inc. Voice virtual private network
CN101208982A (zh) * 2005-05-03 2008-06-25 诺基亚公司 用信号发送用于多媒体会话的服务质量（qos）参数
EP1724984A1 (de) * 2005-05-20 2006-11-22 Alcatel Endgerät mit einem Sender-/Empfänger
CN100544388C (zh) * 2005-07-01 2009-09-23 华为技术有限公司 一种控制业务多次前转套打的方法
US7796589B2 (en) * 2005-08-01 2010-09-14 American Power Conversion Corporation Communication protocol
US9660808B2 (en) * 2005-08-01 2017-05-23 Schneider Electric It Corporation Communication protocol and method for authenticating a system
EP1758334A1 (de) * 2005-08-26 2007-02-28 Matsushita Electric Industrial Co., Ltd. Mediensitzungseinrichtung mit Medienanpassung
US7788698B2 (en) 2005-08-31 2010-08-31 Microsoft Corporation Pre-negotiation and pre-caching media policy
US20070110034A1 (en) * 2005-11-14 2007-05-17 Broadcom Corporation, A California Corporation Pathways analysis and control in packet and circuit switched communication networks
US8077707B2 (en) * 2005-11-18 2011-12-13 Sri International Systems and methods for digital stream denting
US20070121532A1 (en) * 2005-11-28 2007-05-31 Nokia Corporation Application specific encoding of content
US8600530B2 (en) * 2005-12-27 2013-12-03 France Telecom Method for determining an audio data spatial encoding mode
CN101371503B (zh) 2006-01-11 2013-09-25 高通股份有限公司 用于在广域网与局域对等网络之间共享带宽的方法和装置
US8811369B2 (en) 2006-01-11 2014-08-19 Qualcomm Incorporated Methods and apparatus for supporting multiple communications modes of operation
CN101026812B (zh) * 2006-02-24 2010-04-14 华为技术有限公司 在多方通信系统中获得会话参与用户会话能力的方法
EP1850619B1 (de) * 2006-04-28 2012-04-11 Motorola Mobility, Inc. Fähigkeitsaktualisierung während eines Anrufs
US7756134B2 (en) 2006-05-02 2010-07-13 Harris Corporation Systems and methods for close queuing to support quality of service
US7647276B2 (en) * 2006-05-11 2010-01-12 Cfph, Llc Methods and apparatus for electronic file use and management
US7894509B2 (en) 2006-05-18 2011-02-22 Harris Corporation Method and system for functional redundancy based quality of service
EP1858210A1 (de) * 2006-05-19 2007-11-21 Whitestein Information Technology Group AG Verfahren und System zu einem adaptiven Kommunikationsdienstzugang
US8705558B2 (en) 2006-06-01 2014-04-22 Cisco Technology, Inc. Swapping bandwidth reservations
US9112872B2 (en) * 2006-06-07 2015-08-18 Broadcom Corporation Method and system for communication of information by a handheld communication device in an ad-hoc network
US7856012B2 (en) * 2006-06-16 2010-12-21 Harris Corporation System and methods for generic data transparent rules to support quality of service
US8516153B2 (en) 2006-06-16 2013-08-20 Harris Corporation Method and system for network-independent QoS
US8064464B2 (en) 2006-06-16 2011-11-22 Harris Corporation Method and system for inbound content-based QoS
US7990860B2 (en) * 2006-06-16 2011-08-02 Harris Corporation Method and system for rule-based sequencing for QoS
EP1871050B1 (de) * 2006-06-20 2012-01-25 Alcatel Lucent Wimax-Netz, Wimax-Netzelement und eine Verfahrensweise der Behandlung der Dienstleistungsqualität
US8730981B2 (en) 2006-06-20 2014-05-20 Harris Corporation Method and system for compression based quality of service
US7769028B2 (en) 2006-06-21 2010-08-03 Harris Corporation Systems and methods for adaptive throughput management for event-driven message-based data
US8077626B2 (en) * 2006-07-14 2011-12-13 Qualcomm Incorporated Quality of service (QoS) aware establishment of communication sessions
CN101110972B (zh) * 2006-07-18 2010-05-12 华为技术有限公司 分布式架构中sip消息分发和处理方法及其系统
GB2440381B (en) * 2006-07-27 2008-11-05 Motorola Inc An internet protocol multimedia subsystem network element and method of operation therefor
US8300653B2 (en) 2006-07-31 2012-10-30 Harris Corporation Systems and methods for assured communications with quality of service
US7817557B2 (en) * 2006-08-29 2010-10-19 Telesector Resources Group, Inc. Method and system for buffering audio/video data
US7940653B2 (en) * 2006-08-29 2011-05-10 Verizon Data Services Llc Audiovisual data transport protocol
DE602006014887D1 (de) * 2006-09-05 2010-07-22 Ericsson Telefon Ab L M IP-Unicast-Streaming-Dienstablieferung
CN101087301B (zh) * 2006-09-07 2010-05-12 华为技术有限公司 用户接入网络的方法和系统
EP2064855B1 (de) * 2006-09-20 2016-02-24 Orange Verfahren zur kommunikation zwischen mehreren endgeräten
KR20080030899A (ko) * 2006-10-02 2008-04-07 엘지전자 주식회사 맞춤형 방송 신호 수신기 및 방송 수신 방법
US7840686B2 (en) * 2006-10-25 2010-11-23 Research In Motion Limited Method and system for conducting communications over a network
CN101175293B (zh) * 2006-10-30 2010-09-08 华为技术有限公司 采用push模式的呼叫方法
GB2444096B (en) * 2006-11-22 2009-10-14 Adam Hill Audio communications system using networking protocols
US8218458B2 (en) * 2006-11-30 2012-07-10 Cisco Systems, Inc. Method and apparatus for voice conference monitoring
US8019326B2 (en) * 2006-11-30 2011-09-13 Motorola Mobility, Inc. System and method for adaptive contextual communications
US8737349B2 (en) * 2006-12-01 2014-05-27 Sigram Schindler Beteiligungsgesellschaft Mbh Handover process and information support for communication transfer between telecommunication networks
FR2909822B1 (fr) * 2006-12-06 2010-04-30 Radiotelephone Sfr Procede et systeme de controle de l'etablissement de canaux de communication pour permettre une transmission d'informations multimedia.
JP2008153896A (ja) * 2006-12-15 2008-07-03 Nec Corp コンテンツ配信システム、コンテンツ配信側ユーザー端末、コンテンツ被配信側ユーザー端末、コンテンツ配信システムの認証方法
US8959239B2 (en) * 2006-12-29 2015-02-17 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for reporting streaming media quality
US7971132B2 (en) * 2007-01-05 2011-06-28 Dialogic Corporation Universal multimedia engine and method for producing the same
CN101005511B (zh) * 2007-01-17 2010-06-16 华为技术有限公司 QoS资源预留方法、系统及会话建立和修改媒体的方法
US20100053300A1 (en) * 2007-02-02 2010-03-04 Einarsson Torbjoern Method And Arrangement For Video Telephony Quality Assessment
US9998956B2 (en) 2007-02-12 2018-06-12 Sigram Schindler Beteiligungsgesellschaft Mbh Managed handover process
ATE513441T1 (de) * 2007-02-12 2011-07-15 Sigram Schindler Beteiligungs Gmbh ßNETSURFINGß IN VOIP-ANRUFEN MITTELS MANAGED HANDOVERS (MHOS)
US8761009B2 (en) 2007-02-12 2014-06-24 Sigram Schindler Beteiligungsgesellschaft Mbh Managed handover process
US9019830B2 (en) 2007-05-15 2015-04-28 Imagine Communications Corp. Content-based routing of information content
EP2009892B1 (de) * 2007-06-29 2019-03-06 Orange Positionierung der Sprecher in einer 3D-Audiokonferenz
US8151005B2 (en) * 2007-08-04 2012-04-03 Broadcom Corporation System and method for adjusting a level of compression for computing clients
US7929553B2 (en) * 2007-08-10 2011-04-19 Broadcom Corporation System and method for adjusting compression for computing clients based on a latency level
US8856206B2 (en) * 2007-08-28 2014-10-07 International Business Machines Corporation Maintaining message versions at nodes in a network
US8554865B2 (en) * 2007-09-21 2013-10-08 Honeywell International Inc. System and method for remotely administering and synchronizing a clustered group of access control panels
EP2204032A1 (de) * 2007-09-29 2010-07-07 Research In Motion Limited Schemaaushandlung für versionierte dokumente, die in einer verteilten umgebung übertragen werden
US8407299B2 (en) * 2007-10-27 2013-03-26 Research In Motion Limited Content disposition system and method for processing message content in a distributed environment
MX2010005624A (es) 2007-11-30 2010-06-01 Samsung Electronics Co Ltd Metodo y aparato de busqueda de dispositivos de retransmision de servicio de television de protocolo de internet y metodo y aparato de interaccion con dispositivos.
US8614996B1 (en) * 2007-12-12 2013-12-24 Sprint Spectrum L.P. Predictive personality negotiation during session negotiation
EP2073467A1 (de) * 2007-12-21 2009-06-24 Nokia Siemens Networks Oy Nachrichtenübermittlungsmechanismus
US7877453B2 (en) * 2008-01-02 2011-01-25 International Business Machines Corporation System and method for optimizing data traffic in signaling stream of IP multimedia subsystem service
US9705935B2 (en) 2008-01-14 2017-07-11 Qualcomm Incorporated Efficient interworking between circuit-switched and packet-switched multimedia services
CN101222502B (zh) * 2008-01-25 2012-08-22 华为技术有限公司 媒体能力重协商的方法及装置
EP2242266A4 (de) * 2008-02-05 2014-04-02 Samsung Electronics Co Ltd Verfahren und einrichtung zum senden und empfangen von metadaten für eine anwendung, die einen iptv-dienst bereitstellt
US20090207988A1 (en) * 2008-02-15 2009-08-20 Ericsson, Inc. Method and system for telecommunication sessions using only initial signal messages
US8144187B2 (en) 2008-03-14 2012-03-27 Microsoft Corporation Multiple video stream capability negotiation
CN101981930A (zh) 2008-03-28 2011-02-23 三星电子株式会社 针对提供iptv通信服务的应用的信息接收方法及装置
US8595501B2 (en) 2008-05-09 2013-11-26 Qualcomm Incorporated Network helper for authentication between a token and verifiers
CN101282339B (zh) * 2008-05-16 2012-12-12 华为技术有限公司 流媒体系统的能力协商方法、数据传输方法及相关设备
US8902821B2 (en) * 2008-06-12 2014-12-02 Motorola Mobility Llc Method and system for intermediate node quality of service negotiations
US20100069536A1 (en) * 2008-07-17 2010-03-18 Sau Arjun C Process for tailoring water-borne coating compositions
GB0813203D0 (en) * 2008-07-18 2008-08-27 Eldon Technology Ltd Dynamic QoS in a network distributing audio visual content
KR101661210B1 (ko) 2008-07-24 2016-09-29 삼성전자주식회사 Ｉｐｔｖ 통신 서비스 수행 방법 및 장치
US8005015B2 (en) * 2008-07-28 2011-08-23 Telefonaktiebolaget L M Ericsson (Publ) Signaling framework for negotiating and executing composition of registries
US8700033B2 (en) * 2008-08-22 2014-04-15 International Business Machines Corporation Dynamic access to radio networks
US8059615B1 (en) 2008-09-08 2011-11-15 Sprint Spectrum L.P. Selective personality negotiation during session negotiation
US8615575B2 (en) * 2008-10-16 2013-12-24 At&T Intellectual Property I, L.P. Devices, methods, and computer-readable media for providing quality of service optimization via policy-based rearrangements
US8320927B2 (en) 2008-10-16 2012-11-27 At&T Intellectual Property I, L.P. Devices, methods, and computer-readable media for providing broad quality of service optimization using policy-based selective quality degradation
US8346233B2 (en) * 2008-10-16 2013-01-01 At&T Intellectual Property I, L.P. Devices, methods, and computer-readable media for providing sevices based upon identification of decision makers and owners associated with communication services
US9015599B2 (en) * 2008-10-16 2015-04-21 At&T Intellectual Property I, L.P. Devices, methods and computer-readable media for providing control of switching between media presentation screens
US8185489B2 (en) * 2008-10-16 2012-05-22 At&T Intellectual Property, I, L.P. Devices, methods, and computer-readable media for providing calendar-based communication system services
US8391882B2 (en) * 2008-10-22 2013-03-05 Qualcomm Incorporated Method and system for interference management in a spectrum shared by WAN and femto cells
US8904276B2 (en) 2008-11-17 2014-12-02 At&T Intellectual Property I, L.P. Partitioning of markup language documents
US8549198B2 (en) * 2009-03-27 2013-10-01 Schneider Electric It Corporation Communication protocol
US9626681B2 (en) * 2009-04-02 2017-04-18 International Business Machiines Corporation Negotiable information access in electronic social networks
US8972596B2 (en) * 2009-04-28 2015-03-03 The Boeing Company System and method for effecting communications among devices in different domains employing different operating protocols
US9369510B2 (en) * 2009-07-16 2016-06-14 International Business Machines Corporation Cost and resource utilization optimization in multiple data source transcoding
US8953038B2 (en) * 2009-08-31 2015-02-10 International Business Machines Corporation Distributed video surveillance storage cost reduction using statistical multiplexing principle
FR2951898B1 (fr) * 2009-10-27 2015-10-02 Sagem Comm Procede d'etablissement d'une session applicative, dispositif et notification correspondante
US8578020B2 (en) * 2009-12-24 2013-11-05 Empire Technology Development Llc Dynamic mobile application quality-of-service monitoring and reporting
CN102195959B (zh) * 2010-03-11 2015-08-12 中兴通讯股份有限公司 Sip信令的xml数据的解析方法及装置
US20110302287A1 (en) * 2010-06-04 2011-12-08 Muppirala Kishore Kumar Quality of service control
US8943451B2 (en) * 2010-06-23 2015-01-27 Mentor Graphics Corporation Hierarchical finite state machine generation for power state behavior in an electronic design
US20120005351A1 (en) * 2010-07-02 2012-01-05 Cisco Technology, Inc. Method and apparatus for transmitting an application identifier across application elements
TW201215214A (en) * 2010-07-06 2012-04-01 Interdigital Patent Holdings IP multimedia subsystem (IMS)-based pre-negotiation of video codec for video single radio video call continuity
US10250678B2 (en) * 2010-07-07 2019-04-02 Qualcomm Incorporated Hybrid modes for peer discovery
FR2959088A1 (fr) * 2010-09-14 2011-10-21 France Telecom Procede de traitement d'une demande d'etablissement d'une communication, systeme, equipement et programme d'ordinateur correspondants
US8805970B2 (en) * 2010-10-25 2014-08-12 International Business Machines Corporation Automatic management of configuration parameters and parameter management engine
US9043797B2 (en) 2010-10-26 2015-05-26 Qualcomm Incorporated Using pause on an electronic device to manage resources
US9191284B2 (en) 2010-10-28 2015-11-17 Avvasi Inc. Methods and apparatus for providing a media stream quality signal
US10694402B2 (en) 2010-11-05 2020-06-23 Mark Cummings Security orchestration and network immune system deployment framework
US9311108B2 (en) 2010-11-05 2016-04-12 Mark Cummings Orchestrating wireless network operations
US10285094B2 (en) 2010-11-05 2019-05-07 Mark Cummings Mobile base station network
US10687250B2 (en) 2010-11-05 2020-06-16 Mark Cummings Mobile base station network
US10531516B2 (en) 2010-11-05 2020-01-07 Mark Cummings Self organizing system to implement emerging topologies
US9531774B2 (en) * 2010-12-13 2016-12-27 At&T Intellectual Property I, L.P. Multicast distribution of incrementally enhanced content
KR20120083033A (ko) * 2011-01-17 2012-07-25 삼성전자주식회사 무선통신시스템에서 응용 프로그램의 서비스 품질 서비스를 지원하기 위한 시스템 및 방법
US8929561B2 (en) * 2011-03-16 2015-01-06 Apple Inc. System and method for automated audio mix equalization and mix visualization
US8694587B2 (en) * 2011-05-17 2014-04-08 Damaka, Inc. System and method for transferring a call bridge between communication devices
US8966095B2 (en) * 2011-07-08 2015-02-24 Avaya Inc. Negotiate multi-stream continuous presence
US20130304934A1 (en) * 2011-09-29 2013-11-14 Avvasi Inc. Methods and systems for controlling quality of a media session
US20140181266A1 (en) * 2011-09-29 2014-06-26 Avvasi Inc. System, streaming media optimizer and methods for use therewith
US9118738B2 (en) 2011-09-29 2015-08-25 Avvasi Inc. Systems and methods for controlling access to a media stream
US9042449B2 (en) 2011-09-29 2015-05-26 Avvasi Inc. Systems and methods for dynamic transcoding of indexed media file formats
WO2013044367A1 (en) * 2011-09-29 2013-04-04 Avvasi Inc. Systems and methods for media service delivery
US20130124708A1 (en) * 2011-11-10 2013-05-16 Electronics And Telecommunications Research Institute Method and system for adaptive composite service path management
KR102050984B1 (ko) * 2012-03-11 2019-12-02 삼성전자주식회사 와이-파이 디스플레이 네트워크에서 와이-파이 디스플레이 세션을 제공하는 방법 및 장치, 그리고 그에 따른 시스템
US20140095695A1 (en) * 2012-09-28 2014-04-03 Ren Wang Cloud aware computing distribution to improve performance and energy for mobile devices
US9021091B2 (en) * 2012-10-15 2015-04-28 International Business Machines Corporation Transaction middleware based application level transaction instance tracking across a composite application
WO2014066975A1 (en) * 2012-10-30 2014-05-08 Avvasi Inc. Methods and systems for controlling quality of a media session
JP2014090387A (ja) * 2012-10-31 2014-05-15 Ricoh Co Ltd 情報処理装置、会議システムおよびプログラム
US9621480B2 (en) 2013-03-04 2017-04-11 Vigo Software Ltd Data acquisition pertaining to connectivity of client applications of a service provider network
US9391749B2 (en) * 2013-03-14 2016-07-12 Ashwin Amanna, III System and method for distributed data management in wireless networks
US9299049B2 (en) * 2013-03-15 2016-03-29 Sap Se Contract-based process integration
US9519528B2 (en) 2013-04-19 2016-12-13 National Ict Australia Limited Checking undoability of an API-controlled computing system
US9591514B2 (en) * 2013-04-19 2017-03-07 Microsoft Technology Licensing, Llc Optimization of over-the-top (OTT) services on carrier networks
US9563907B2 (en) 2013-06-13 2017-02-07 Vigo Software Ltd Offer based provision of fee based network access
FR3007604A1 (fr) * 2013-06-21 2014-12-26 France Telecom Procede d'acquisition d'un module de codage/decodage dans un reseau de telecommunications
US9344349B2 (en) 2013-07-12 2016-05-17 Nicira, Inc. Tracing network packets by a cluster of network controllers
US9282019B2 (en) 2013-07-12 2016-03-08 Nicira, Inc. Tracing logical network packets through physical network
FR3011704A1 (fr) * 2013-10-07 2015-04-10 Orange Procede de mise en œuvre d'une session de communication entre une pluralite de terminaux
US9894117B2 (en) * 2013-10-09 2018-02-13 Cisco Technology, Inc. File transfers for virtual conferences
US9986044B2 (en) * 2013-10-21 2018-05-29 Huawei Technologies Co., Ltd. Multi-screen interaction method, devices, and system
CN105659615B (zh) * 2013-10-28 2019-11-05 索尼公司 内容供给装置、内容供给方法、终端装置及内容供给系统
US10037554B2 (en) 2013-10-30 2018-07-31 Vigo Software Ltd Aggregated billing for application-based network access and content consumption
CN103634299B (zh) * 2013-11-14 2016-09-14 北京邮电大学 基于多连接的实时流媒体传输终端与方法
US9173133B2 (en) * 2013-12-26 2015-10-27 Cellco Partnership Mobile device with guaranteed QoS
US9462618B2 (en) * 2014-03-06 2016-10-04 Mediatek Inc. Method of call setup time reduction for voice over LTE
DE102014006038A1 (de) * 2014-04-25 2015-10-29 Unify Gmbh & Co. Kg Verfahren und Vorrichtung zur Übermittlung und Adaption von Daten, Computerprogramm, Softwareprodukt und Digitales Speichermedium
FR3026595A1 (fr) * 2014-09-25 2016-04-01 Orange Procede de negociation de codecs dans les reseaux ip
US10469342B2 (en) 2014-10-10 2019-11-05 Nicira, Inc. Logical network traffic analysis
US10574579B2 (en) 2014-10-31 2020-02-25 Hewlett Packard Enterprise Development Lp End to end quality of service in storage area networks
EP3913940A1 (de) * 2014-11-27 2021-11-24 Koninklijke KPN N.V. Infrastrukturbasierter d2d-verbindungsaufbau mit ott-diensten
US20160269493A1 (en) * 2015-03-10 2016-09-15 Qualcomm Incorporated Methods and devices to establish services between service and connectivity strata
FR3034608A1 (fr) * 2015-03-31 2016-10-07 Orange Procede de priorisation de flux medias dans un reseau de communications
KR102353656B1 (ko) * 2015-04-22 2022-01-19 퀄컴 인코포레이티드 Ｍｄｔ 및 ｑｏｅ 메트릭들의 상관 및 결합
KR102401477B1 (ko) * 2015-11-24 2022-05-25 삼성전자주식회사 사용자 단말 장치 및 그 제어 방법
KR102540459B1 (ko) 2016-12-22 2023-06-05 한화비전 주식회사 Rtp/rtsp 표준을 따르는 서버와 클라이언트에서 실시간 영상 스트리밍 방법
US10200914B2 (en) 2017-01-20 2019-02-05 Microsoft Technology Licensing, Llc Responsive quality of service management
US10200306B2 (en) 2017-03-07 2019-02-05 Nicira, Inc. Visualization of packet tracing operation results
EP3621354B1 (de) * 2017-05-08 2022-01-19 Huawei Technologies Co., Ltd. Verfahren und vorrichtung zum bewegen zwischen kommunikationssystemen
US10608887B2 (en) 2017-10-06 2020-03-31 Nicira, Inc. Using packet tracing tool to automatically execute packet capture operations
US10673962B2 (en) * 2017-11-28 2020-06-02 Sap Se Service cross-consumption based on an open service broker application programming interface
US11477667B2 (en) 2018-06-14 2022-10-18 Mark Cummings Using orchestrators for false positive detection and root cause analysis
WO2020005208A1 (en) * 2018-06-26 2020-01-02 Nokia Technologies Oy Methods and apparatuses for enhanced data packet flow handling in communications systems
KR102436246B1 (ko) * 2018-07-05 2022-08-25 삼성전자 주식회사 전자 장치에서 멀티미디어 서비스 제공 방법 및 장치
WO2020062000A1 (en) * 2018-09-28 2020-04-02 Nokia Shanghai Bell Co., Ltd. Proactive resource reservation for communications
CN111107589B (zh) * 2018-11-12 2021-12-24 维沃移动通信有限公司 配置参数协商方法、终端设备、系统和存储介质
CN111290983B (zh) 2018-12-10 2023-05-16 澜至电子科技（成都）有限公司 Usb传输设备及传输方法
EP3895395A1 (de) * 2018-12-10 2021-10-20 Telefonaktiebolaget LM Ericsson (publ) Netzwerkknoten, einheit und verfahren zur handhabung einer kommunikationssitzung in einem kommunikationsnetz
CN111277972B (zh) * 2019-01-25 2022-12-23 维沃移动通信有限公司 一种直接通信接口QoS参数确定方法及相关设备
US11109394B2 (en) * 2019-07-30 2021-08-31 Cypress Semiconductor Corporation Methods, systems and devices for providing differentiated quality of service for wireless communication devices
US11283699B2 (en) 2020-01-17 2022-03-22 Vmware, Inc. Practical overlay network latency measurement in datacenter
US11570090B2 (en) 2020-07-29 2023-01-31 Vmware, Inc. Flow tracing operation in container cluster
US11558426B2 (en) 2020-07-29 2023-01-17 Vmware, Inc. Connection tracking for container cluster
US11196628B1 (en) 2020-07-29 2021-12-07 Vmware, Inc. Monitoring container clusters
US11777863B2 (en) * 2020-12-21 2023-10-03 Landis+ Gyr Innovations Optimized route for time-critical traffic in mesh network
US11736436B2 (en) 2020-12-31 2023-08-22 Vmware, Inc. Identifying routes with indirect addressing in a datacenter
US11336533B1 (en) 2021-01-08 2022-05-17 Vmware, Inc. Network visualization of correlations between logical elements and associated physical elements
CN113301055A (zh) * 2021-06-22 2021-08-24 展讯通信（上海）有限公司 提高ims会话系统兼容性的方法及装置、网络设备及移动设备
US11687210B2 (en) 2021-07-05 2023-06-27 Vmware, Inc. Criteria-based expansion of group nodes in a network topology visualization
US11711278B2 (en) 2021-07-24 2023-07-25 Vmware, Inc. Visualization of flow trace operation across multiple sites
US11855862B2 (en) 2021-09-17 2023-12-26 Vmware, Inc. Tagging packets for monitoring and analysis
CN114866300A (zh) * 2022-04-22 2022-08-05 中国人民解放军国防科技大学 一种基于重放分析的网络协议软件状态变量识别方法
WO2024011019A2 (en) * 2022-07-08 2024-01-11 Qualcomm Incorporated Contextual quality of service for mobile devices

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5574934A (en) * 1993-11-24 1996-11-12 Intel Corporation Preemptive priority-based transmission of signals using virtual channels
US6678264B1 (en) * 1999-06-30 2004-01-13 Nortel Networks Limited Establishing connections with a pre-specified quality of service across a communication network
US6707820B1 (en) * 1999-12-16 2004-03-16 Intervoice Limited Partnership Virtual circuit network dynamic channel management
US7058973B1 (en) * 2000-03-03 2006-06-06 Symantec Corporation Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses
DE60042965D1 (de) * 2000-05-24 2009-10-29 Sony Deutschland Gmbh Dienstqualitätsunterhandlung
ATE372639T1 (de) 2000-12-08 2007-09-15 Sony Deutschland Gmbh Schnittstelle auf hoher ebene für dienstqualitätbasierte mobile multimedia- anwendungen
EP1248431B1 (de) * 2001-03-27 2007-10-31 Sony Deutschland GmbH Verfahren um End-to-End Quality of Service Verhandlungen für verteilte Multimedia Anwendungen zu erzielen
US6957071B1 (en) * 2001-07-18 2005-10-18 Cisco Technology, Inc. Method and system for managing wireless bandwidth resources

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015001622A1 (de) 2015-02-09 2016-08-11 Unify Gmbh & Co. Kg Verfahren zur Übertragung von Daten in einem Multimedia-System, sowie Softwareprodukt und Vorrichtung zur Steuerung der Übertragung von Daten in einem Multimedia-System
WO2016128145A1 (de) 2015-02-09 2016-08-18 Unify Gmbh & Co. Kg Verfahren zur übertragung von daten in einem multimedia-system, sowie softwareprodukt und vorrichtung zur steuerung der übertragung von daten in einem multimedia-system
US10735483B2 (en) 2015-02-09 2020-08-04 Ringcentral, Inc. Method for transmitting data in a multimedia system, and software product and device for controlling the transmission of data in a multimedia system
US11159591B2 (en) 2015-02-09 2021-10-26 Ringcentral, Inc. Method for transmitting data in a multimedia system, and software product and device for controlling the transmission of data in a multimedia system

Also Published As

Publication number Publication date
ATE293863T1 (de) 2005-05-15
DE60203779D1 (de) 2005-05-25
EP1331785B1 (de) 2005-04-20
ES2236370T3 (es) 2005-07-16
JP4342948B2 (ja) 2009-10-14
CN1623308A (zh) 2005-06-01
WO2003063439A3 (en) 2003-12-24
US7602723B2 (en) 2009-10-13
CN1623308B (zh) 2011-11-16
WO2003063439A2 (en) 2003-07-31
EP1331785A1 (de) 2003-07-30
US20050157660A1 (en) 2005-07-21
JP2005527133A (ja) 2005-09-08

Similar Documents

Publication Publication Date Title
DE60203779T2 (de) Ein Verfahren zur Übertragung von End-to-End QoS durch Anwendung des end-to-end negotiation protocols (E2ENP)
US7076552B2 (en) Universal QoS adaptation framework for mobile multimedia applications
DE60104532T2 (de) Proxy-vorrichtung und -verfahren
DE60036295T2 (de) Schnittstelle auf hoher Ebene für dienstqualitätbasierte mobile Multimedia-Anwendungen
JP2004537187A (ja) 分散型マルチメディアアプリケーションのためにエンドツーエンドのサービス品質交渉を提供する方法及び分散型マルチメディアアプリケーションのための分散型リソース管理メカニズムと協調したエンドツーエンドのサービス品質交渉を提供するｉｐに基づくプロトコル及びメカニズム
DE112006001922T5 (de) Verfahren und Vorrichtung zur Vergabe von Zugangsberechtigungen (&#34;Floor-Control&#34;) in einem Kommunikationssystem
Steinmetz et al. Quality of Service: Where are we?
CN101641917A (zh) 网络资源协商
WO2010090808A2 (en) Distributed scheduling, call control, and resource management for dispersed dynamic video communications networks
DE102014006038A1 (de) Verfahren und Vorrichtung zur Übermittlung und Adaption von Daten, Computerprogramm, Softwareprodukt und Digitales Speichermedium
Hakiri et al. Supporting SIP-based end-to-end data distribution service QoS in WANs
Ahmed et al. End-to-end quality of service provisioning through an integrated management system for multimedia content delivery
Delgrossi Design of reservation protocols for multimedia communication
US7406045B2 (en) Modular policy decision point for processing resource-reservation requests within a data network
da Silva et al. CUBE system: a REST and RESTful based platform for liquid software approaches
DE60131139T2 (de) Verfahren, um End-to-End Quality von Service-Verhandlungen für verteilte Multimedia Anwendungen zu erzielen
Park et al. Congestion game modeling for brokerage based multimedia resource management
Diop et al. QoS‐aware and autonomic‐oriented multi‐path TCP extensions for mobile and multimedia applications
Exposito et al. Semantic and architectural framework for autonomic transport services
Maia et al. A distributed QoS control architecture for heterogeneous networks applied to PLC networks
KR101075758B1 (ko) 밀착결합 멀티-컨퍼런스 시스템의 투표 서비스 방법 및 시스템
Guenkova-Luy Coordination of multimedia services and applications in mobile, heterogeneous network environment
Li Agent-augmented network signaling for call setup
Mauthe et al. From requirements to services: a study on group communication support for distributed multimedia systems
Kamilova Policy-based Handoffs across Intermediary Multimedia Content Providers in the Wireless Internet

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE

Owner name: SONY DEUTSCHLAND GMBH, 10785 BERLIN, DE