DE60131139T2 - Verfahren, um End-to-End Quality von Service-Verhandlungen für verteilte Multimedia Anwendungen zu erzielen - Google Patents

Verfahren, um End-to-End Quality von Service-Verhandlungen für verteilte Multimedia Anwendungen zu erzielen Download PDF

Info

Publication number
DE60131139T2
DE60131139T2 DE2001631139 DE60131139T DE60131139T2 DE 60131139 T2 DE60131139 T2 DE 60131139T2 DE 2001631139 DE2001631139 DE 2001631139 DE 60131139 T DE60131139 T DE 60131139T DE 60131139 T2 DE60131139 T2 DE 60131139T2
Authority
DE
Germany
Prior art keywords
qos
negotiation
peers
peer
phase
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 - Fee Related
Application number
DE2001631139
Other languages
English (en)
Other versions
DE60131139D1 (de
Inventor
Davide Mandato
Andreas Kassler
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
Original Assignee
Sony Deutschland GmbH
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 Deutschland GmbH filed Critical Sony Deutschland GmbH
Application granted granted Critical
Publication of DE60131139D1 publication Critical patent/DE60131139D1/de
Publication of DE60131139T2 publication Critical patent/DE60131139T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Description

  • Die hier präsentierte Erfindung betrifft generell das Gebiet verteilter Multimediaanwendungen und -technologien bzw. -techniken. Sie umfasst Forschungs- und Entwicklungsprobleme, die insbesondere Multimedia-Middleware, Quality of Service Management (QoS-Management), Ressourcenreservierungsmechanismen (Resource Reservation mechanisms), mobile Endgeräte und drahtlose Kommunikation betreffen.
  • Zunächst wird die in der vorliegenden Beschreibung und in den Ansprüchen benutzte Terminologie kurze erläutert:
    Begriff Definition
    Adaptationspfad (Adaption Path) Ein geordneter Satz von QoS-Verträgen, die den Benutzern Präferenzen und Wünsche anzeigen. Typischerweise ist der wichtigste QoS-Vertrag der erste im Pfad.
    Komponente (Component) Eine spezielle Art von Interaktion (beispielsweise Audiokonversation), die unter Benutzung unterschiedlicher Anwendungen realisiert werden kann.
    Konfiguration (Configuration) Ein Satz von Parametern, der zur Implementierung einer Variation gewisser Komponenten erforderlich ist. Potentielle Konfiguration zeigt funktionelle Fähigkeiten des Systems an, während tatsächliche bzw. aktuelle Konfigurationen den Betriebsmodus einer besonderen Instanzierung reflektieren.
    Inhaltsverhandlung (Content negotiation) Austausch von Information, die bei der Übertragung von Daten zum Auswählen einer richtigen Darstellung führt.
    Ökonomieprinzip (Economy Principle) Das Ökonomieprinzip schlägt vor, die teueren Ressourcen als die letzten zu reservieren. Wenn Netzwerkressourcen zwischen mehreren Clients gemeinsam benutzt werden und man typischerweise für sie bezahlen muss, ist es besser, zuerst Ressourcen auf allen Endsystemen zu reservieren und dann als den letzten Schritt Netzwerkressourcen zu reservieren.
    Merkmalsatz (Feature set) Gewisse Sätze von Mediamerkmalen, die von einer Mediamerkmalerklärung beschrieben werden.
    Quality of Service, QoS (Dienstqualität) Der kollektive Effekt einer Dienstausführung bzw. -leistung (service performance), der den Grad von Zufriedenstellung eines Benutzers des Dienstes bestimmt.1 1 Definition aus der ITU-T(früher CCITT)-Empfehlung E.800
    QoS-Änderung (QoS Change) Die Änderung des vom Dienstbenutzer initiierten QoS-Vertrags.
    QoS-Vertrag (QoS Contract) Übereinkommen zwischen einem Dienstbenutzer und einem gegebenen Dienstanbieter (sevice provider), das QoS-Erfordernisse und -Beschränkungen sowie die zum Spurhalten bezüglich QoS während aller Phasen des Dienstes benötigten Grundsätze spezifiziert.
    QoS-Vertragstyp (QoS Contract Type) Erfassungen der 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 [Frolu98] auch als Dimensionen (dimensions)) bekannt). Jeder Parametertyp besteht aus einem Namen und einer Domäne von Werten. QoS-Spezifikationen können einfach als ein Satz von Beschränkungen über den Domänen, einer pro Parametertyp, beabsichtigt sein.
    QoS-Spezifikation (QoS Specification) Genereller Ausdruck (term) zur Identifizierung eines Satzes von QoS-Parametern und -Beschränkungen, die von einem Benutzer spezifiziert werden.
    QoS-Verletzung (QoS-Violation) Die Verletzung einer vom Dienstanbieter verursachten Verletzung eines QoS-Vertrags.
    Drittpartei-Anrufsteuerung (Third party call control) Bei der Drittpartei-Anrufsteuerung erzeugt, modifiziert und beendet ein externer Kontroller Sessionen (Sitzungen) zwischen anderen Teilnehmern.
  • Nun werden die in dieser Beschreibung benutzten Abkürzungen erläutert:
    ATM Asynchronous Transfer Mode (asynchroner Übertragungsmodus)
    CC/PP Composite Capabilities/Preference Profiles (zusammengesetzte Fähigkeiten/Präferenzprofile)
    CSCW Computer-Supported Cooperative Work (computerunterstützte kooperative Arbeit)
    E2ENP End-to-End Negotiation Protocol (End-zu-End-Verhandlungsprotokoll)
    HDTV High Definition Television (hochauflösendes Fernsehen)
    HTTP Hyper Text Transport Protocol (Hypertexttransportprotokoll (Netzwerkprotokoll des WWW))
    IETF Internet Engineering Task Force (Internetentwicklungsaufgabengruppe)
    IP Internet Protocol (Internetprotokoll)
    IRT Initiator-Role-Token (Initiatorrolle-Token)
    MSC Message Sequence Charts (Mitteilungsfolgediagramme)
    OS Operating System (Betriebssystem)
    RDF Resource Description Framwork (RessourcenbeschreibungsRahmen)
    RTP Real Time Protocol (Echtzeitprotokoll)
    RTSP Real Time Streaming Protocol (Echtzeitströmenprotokoll)
    RSVP Ressource Reservation Protocol (Ressourcenreservierungsprotokoll)
    SAP Session Annoncement Protocol (Sessionsankündigungsprotokoll)
    SDP Session Descrition Protocol (Sessionsbeschreibungsprotokoll)
    SIP Session Initiation Protocol (Sessionsinitiationsprotokoll)
    VoD Video an Demand (Video nach Bedarf)
    UML Unified Modeling Language (vereinheitlichte Modelliersprache)
    XML Extended Markup Language (erweiterte Beschreibungssprache)
  • Den Erfindern sind die im Anhang am Schluss der Beschreibung aufgeführten Stand-der-Technik-Dokumente bekannt.
  • Die relevanten Stand-der-Technik-Dokumente werden nun kurz erläutert:
    In W. Marshall et al.: Integration of Resource Management and SIP-SIP Extensions for Resource Management, IETF SIP working group, Work-in-progress (Arbeit fortschreitend), <draft-ietf-sip-manyfolks-resource-01.txt> präsentieren die Autoren einen Mehrphasen-Anrufinstallierungsmechanismus, der Netzwerk-QoS- und -Sicherheit-Herstellung zu einer Vorbedingung für vom Session Initiation Protocol (SIP) initiierte und vom Session Description Protocol (SDP) beschriebene Sessionen macht. Netzwerkressourcen werden vor dem Start der Session unter Benutzung existierender Netzwerkressourcen-Reservierungsmechanismen (wie RSVP) reserviert. Das Ressourcenmanagementprotokoll (resource management protocol) wird zwischen zwei Phasen einer Anrufsignalisierung verschachtelt, und Teilnehmer werden eingeladen, nachdem im Netzwerk Ressourcen verfügbar sind. Eine Bestätigung der Vorbedingungen wird explizit signalisiert. Ressourcenmanagement wird nur für die Netzwerkressourcen ausgeführt. Eine Erweiterung auf SDP wird zum Bestimmen, ob die Vorbedingungen erfüllt sind, eingebracht.
  • Bei G. Camarillo: Confirmation of SDP preconditions, IETF Internet Draft, Work-in-progress, <draft-camarillo-manyfolks-confirm-02.txt> wird ein zusätzliches Richtungsattribut eingebracht, um anzuzeigen, welche Partei die Bestätigung der Vorbedingungen sendet. Schließlich stellt G. Camarillo: Confirmation of SDP preconditions, IETF Internet Draft, Work-in-progress, <draft-camarillo-manyfolks-confirm-02.txt> einen Mechanismus zur Ausführung einer Drittpartei-Anrufsteuerung in einem SIP bei Benutzung von SDP-Vorbedingungen bereit.
  • In RFC 2533, A Syntax for Describing Media Feature Sets, Graham Klyne, 5GM/Content Technologies, März 1999, präsentieren die Autoren ein Format zum Ausdrücken von Mediamerkmalsätzen, die Mediabehandlungsfähigkeiten darstellen. Außerdem ist ein Algorithmus bereitgestellt, der die Merkmalsätze anpasst. Er kann möglicherweise zum Bestimmen, ob die Fähigkeiten eines Senders und eines Empfängers kompatibel sind, benutzt werden.
  • Dieser Anpassungsalgorithmus ist in G. Klyne (Ed.): A revised Media feature set matching algorithm, IETF media feature registration WG, Work-in-progress, <draft-klyne-conneg-feature-match-02.txt> verbessert.
  • Außerdem beschreibt G. Klyne (Ed.): Identifiying composite media features, IETF conneg working group, Work-in-progress, <draft-ietf-conneg-feature-hash-05.txt> ein gekürztes Format für zusammengesetzte Mediamerkmalsätze, das Benutzern ein Hash (Durcheinander, Haschee) der Merkmaldarstellung zum Beschreiben der Zusammensetzung gibt. Dieses kann zum Bereitstellen einer gekürzten Form zum Referenzieren eines beliebigen Merkmalsatzausdrucks unabhängig von irgendeinem besonderen Mechanismus zur Dereferenzierung benutzt werden. In F. Andreasen, SDP Simple Capability Negotiation Requirements, IETF MMUSIC working group, Work-in-progress, <draft-andreasen, mmusic-sdp-simcap-reqts-00.txt> legen die Autoren das Erfordernis fest, dass ein Fähigkeitssatz eine Handhabe aufweisen sollte (ähnlich zum oben erwähnten Hash), die eine leichte Referenzierung des Fähigkeitssatzes ermöglicht.
  • In RFC 2703, Protocol-independent Content Negotiation Framework, Graham Klyne, 5GM/Content Technologies, September 1999, präsentieren die Autoren ein abstraktes Rahmen (framework) für eine protokollunabhängige Inhaltsverhandlung für die Ressourcen, mit denen sie interagiert. Es stellt jedoch nicht den Inhaltsverhandlungsprozess bereit. Es identifiziert die Notwendigkeit zum Ausdrücken der Fähigkeiten des Senders und der zu übertragenden Datenressource, der Fähigkeiten des Empfängers und der Notwendigkeit eines Protokoll zum Austauschen dieser Fähigkeiten. Eine Verhandlung wird durch eine Reihe von Verhandlungs-Metadatenaustauschungen ausgeführt. Die Verhandlung stoppt, wenn eine zu übertragende spezielle 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 betrifft deshalb die Inhaltsverhandlung.
  • Die weitergehende Arbeit bei D. Kutscher et. al.: Requirements for Session Description and Capability Negotiation, IETF Internet-Draft, Work-in-progress, <draft-kutscher-mmusic-sdpng-req-01.txt> identifiziert die Erfordernisse eines sich mit einer Sessionsbeschreibungs- und Endpunktfähigkeitsverhandlung in Mehrparteien-Multimedia-Konferenzszenarios befassenden Rahmens. Abhängig von Benutzerpräferenzen, Systemfähigkeiten oder anderen Beschränkungen können unterschiedliche Konfigurationen für die Konferenz gewählt werden. Die Notwendigkeit eines Verhandlungsprozesses zwischen den Peers wird 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 zum Bekommen einer gültigen Sessionsbeschreibung, die mit den Endsystemfähigkeiten und den Benutzerpräferenzen der potentiellen Teilnehmer kompatibel ist, benutzt. Unterschiedliche Verhandlungsgrundsätze können benutzt werden, um unterschiedlicher Konferenztypen zu reflektieren. Sie identifizieren auch die Notwendigkeit für eine mit einem Sessionsaufbau gekoppelte Netzwerkressourcenreservierung. Schließlich wird ein Vorschlag zur Beschreibung von Fähigkeiten und Bereitstellung der Verhandlungssprache, aber nicht eines Protokolls gezeichnet.
  • Die Autoren von F. Andreasen, SDP Simple Capability Negotiation, IETF MMUSIC working group, Work-in-progress, <draft-andreasen-mmusic-sdp-simcap-00.txt> schlagen einen Satz von SDP-Erweiterungen vor, die einen minimalen und rückwärtskompatiblen Fähigkeitsverhandlungsmechanismus bereitstellen. In B. Beser: Codec Capabilities Attribute for SDP, IETF Internet-Draft, Work-in-progress, <draft-beser-mmusic-capabilities-00.txt> erweitert der Autor ein SDP, so dass Endpunkte die Codecauswahlen kennen und bezüglich eines gemeinsamen Satzes übereinkommen können. Der Kommunikationspartner kann auf diese Weise die Fähigkeiten und Präferenzen des oder der Urheber erhalten. In J. Ott et al.: Capability description for group cooperation, IETF Internet-Draft, Work-in-progress, <draft-ott-mmusic-cap-00.txt> ist eine Notation zur Beschreibung potentieller und spezifischer Konfigurationen von Endsystemen in Mehrparteien-Zusammenarbeitssessionen gegeben. Diese befähigt Mechanismen, Endsystemfähigkeiten zu definieren, einen Satz von gemeinsamen Fähigkeiten zu berechnen und eine ausgewählte Mediabeschreibung zur Benutzung in Sessionsbeschreibungen auszudrücken. Sie stellen kein Protokoll zum Fähigkeitsaustausch bereit. In C. Bormann et al.: Simple Conference Control Protocol, IETF Internet-Draft, Work-in-progress, <draft-ietf-mmusic-sccp-01.txt> definieren die Autoren Dienste für ein einfaches Konferenzsteuerungsprotokoll (simple conference control protocol (SCCP)) für fest gekoppelte Konferenzen. Teilnehmermanagement, Anwendungs-/Sessionsmanagement und Zugriffssteuerungsregeln für verteilte Anwendungsressourcen sind definiert. Der Konferenzzustand, der unter Benutzung eines SIP hergestellt werden kann, wird während der Dauer (lifetime) unter Benutzung des SCCP gemanagt. Dies umfasst das Finden geeigneter Konfigurationen, eine Verhandlung für Konfigurationen und eine Änderung der Konfiguration. Jedoch ist keine Interaktion mit lokalem Ressourcenmanagement beabsichtigt.
  • Die Autoren von K. Nahrstedt und J. M. Smith: The QoS Broker, IEEE Multimedia Magazine, Frühjahr 1995(2)1, Seiten 53–67, präsentierten ein Modell für eine Endpunktarchitektur auf Basis eines QoS-Brokers(QoS-Makler, -Vermittler), der eine funktionelle Entität ist, die Ressourcen an den Endpunkten orchestriert und ein Ressourcenmanagement quer über Schichten bzw. Ebenen koordiniert. Um das System richtig zu konfigurieren, benutzt der Broker Zugangssteuerung (admission control) und Verhandlung. Eine Verhandlung zwischen Peerentitäten führt zu einer gültigen Konfiguration, die alle notwendigen Komponenten des Kommunikationssystems involviert.
  • Im vorliegenden Dokument wird der Begriff Ökonomieprinzip zum Beschreiben der in K. Nahrstedt and J. M. Smith: The QoS Broker, IEEE Multimedia Magazine, Frühjahr 1995 (2)1, Seiten 53–67, beschriebenen Reservierungsordnung benutzt:
    • – Zuerst werden lokalen Ressourcen reserviert.
    • – Dann führt eine Verhandlung mit der Peerentität zu einer Konfiguration, die abgebildet werden kann auf Ressourcenerfordernisse beim Peer, die dann reserviert werden.
    • – Schließlich wird beim letzten Schritt eine Reservierung von Netzwerkressourcen ausgeführt, da Netzwerkressourcen teuer sind und zwischen mehreren Peers gemeinsam benutzt werden.
  • Die Autoren von O. Levin, SIP Requirements for support of Multimedia and Video, IETF Internet-Draft, Work-in-progress, <draft-levin-sip-for-video-00.txt> präsentieren einen Satz von Erfordernissen für ein Anrufsteuerungsprotokoll (call-control protocol) für Multimedia-Echtzeitunterstützung über das IP. Es müssen Fähigkeiten ausgedrückt werden, es müssen Fähigkeiten zum Identifizieren der Menge von Ressourcen, die notwendig sind, signalisiert werden, und es ist ein Anrufsteuerungsmechanismus zum Öffnen/Schließen/Modifizieren von Mediaströmen innerhalb der durch Fähigkeiten und reservierte Ressourcen festgelegten Grenzen notwendig. Auch schlagen sie vor, während einer Session neue Fähigkeiten (wenn verfügbar) anzukündigen. Außerdem müssen die Peers über einen gemeinsamen Satz von zu benutzenden Codecs übereinkommen. Ein Sessionssteuerungsmechanismus zum Starten/Stoppen der Ströme ist zu einem Erfordernis erhoben.
  • In Burness L. et al., The BRAIN Quality of Service Architecture for Adaptable Services wirh Mobility Support, in Proceedings of the PIMRC 2000, London, 2000, Kassler A. et al., BRENTA-Supporting Mobility and Quality of Service for Adaptable Multimedia Communication in Proceedings of the IST Mobile Communications Summit 2000, Galway, Ireland, Oktober 2000, Seiten 403–408 und Kassler A. et al., An Open Endsystem Architecture for Adaptable Multimedia Services with QoS Support in Proceedings of the BRAIN workshop, London, 2000 ist eine Endsystemarchitektur präsentiert, die Lokal-, Peer- und Netzwerkressourcenreservierung in ein Rahmen für End-to-end-QoS-Management integriert. Benutzerpräferenzen und Adaptationspfade werden zusammen mit QoS-Zuständen zum Verhandeln einer QoS auf Anwendungsebene benutzt. Eine Interaktion mit Lokalressourcenmanagement ist eingebracht. Die geschichtete Architektur stellt eine Unterstützung für unterschiedliche Typen von Anwendungen bereit.
  • Die grundsätzliche Idee einer Erweiterung existierender Sessionsprotokollebenen wie SIP zur Vorverhandlung von Adaptationspfaden auf mehreren Ebenen von Stromaggregationen ist in der europäischen Patentanmeldung 00 126 975.2, 8. Dezember 2000 enthalten. Jedoch detailliert diese europäische Patentanmeldung nicht ein voll flügge gewordenes End-to-End-QoS-Verhandlungsprotokoll und integriert nicht Zugriffssteuerungs- und Ressourcenreservierungsaspekte.
  • In der Europäischen Patentanmeldung 00 111 191.3 , 24. Mai 2000 ist ein Datenmodell präsentiert, das Wege zur Erzielung einer QoS-Synchronisation und QoS-Korrelation zwischen mehreren Multimediaströmen detailliert. Ein solches Datenmodell verfeinert die in der vorstehend erwähnten Europäischen Patentanmeldung 00 126 975.2 präsentierten Konzepte. Ein solches Datenmodell deckt jedoch die Beschreibung von Fähigkeit wie Codec nicht ab.
  • Von der Erfindung zu lösendes Problem
  • In [Levin01] legt der Autor auf Seite 2 dar: „(...) herstellen einer Session einer gewissen Qualität auf Basis einer Fähigkeitenübereinkunft während der Sessionsherstellung und durch die Dauer der Session hindurch aufrechterhalten. Das Problem kann als ein Fehlen einer Ausdrückbarkeit in den drei folgenden Bereichen beschrieben werden:
    Fähigkeitenspezifikation, Ressourcenreservierung und Mediastromsteuerung.
  • Das letztendliche gewünschte Ziel ist:
    • – die Fähigkeiten (das heißt unterstützte Media, CODEC-Algorithmen, Bandbreite usw.) ohne Notwendigkeit einer Konfiguration auszudrücken,
    • – die für eine spezielle Session benötigten totalen Ressourcen zu signalisieren (möglicherweise in Form von Fähigkeiten), und
    • – innerhalb einer Session Mediaströme explizit zu öffnen und schließen und die Parameter eines gewissen Stroms innerhalb der Grenzen vorher angekündigter Fähigkeiten und reservierter Ressourcen zu modifizieren".
  • Der Autor legt auch auf Seite 4 dar: „SIP-Erweiterungen können notwendig sein, um die „Fähigkeitenankündigungs"-Phase von der tatsächlichen Öffnung von Mediaströmen zu trennen".
  • Im Hinblick auf den Stand der Technik ist es die Aufgabe der vorliegenden Erfindung, ein QoS-Garantien bereitstellendes Konzept in einer effektiven Weise vorzuschlagen.
  • Diese Aufgabe wird durch die Merkmale der unabhängigen Ansprüche gelöst. Die abhängigen Ansprüche entwickeln die zentrale Idee der vorliegenden Erfindung weiter.
  • Weitere Merkmale, Aufgaben und Vorteile der vorliegenden Erfindung werden nun anhand der Figuren der beigefügten Zeichnungen erläutert.
  • 1 zeigt MSC-Identifizierungsphasen hoher Ebene,
  • 2 zeigt eine funktionelle Zerlegung einer Struktur zur Implementierung der vorliegenden Erfindung,
  • 3 zeigt ein Beispiel einer Vorverhandlungsphase 106 (MSC),
  • 4 zeigt ein Beispiel einer Schnellverhandlungsphase 108 (MSC), und
  • 5 zeigt ein Beispiel zur Implementierung eines E2ENP-Brokers im Fall einer SIP-Implementierung.
  • Es folgen die Erfordernisse, die zur Bereitstellung von QoS-Garantien in einer effektiven Weise von Wichtigkeit sein können.
    • – Bereitstellung eines umfassenden Satzes von Mechanismen und Protokollen, die mehrere Aspekte miteinander verbinden wie 1. Vorverhandlung, die auch unangeschlossen (offline) und veröffentlicht unter Benutzung von beispielsweise LDAP durchgeführt werden kann, 2. mit einer ad-hoc Reservierung integrierte Verhandlung, 2.1 Ökonomieprinzip, 2.2 Koordinierung einer Ressourcenreservierung, verstärkt mit den unten aufgelisteten Merkmalen,
    • – spezielle Beschreibung der Interaktion mit Lokal- und Peerressourcenmanagement (zu diesem Zweck sind gewisse Protokollprozeduren erforderlich),
    • – Benutzung von Zustands-IDs zum Aufbauen und Referenzieren eines Adaptaptationspfads,
    • – explizite Meldung von hierarchischen Zustandsmaschinen für einen Adaptaptationspfad auf unterschiedlichen Ebenen.
  • Eines der Ziele der Erfindung ist, auf die Unterstützung unterschiedlicher Typen von Diensten abzuzielen:
    • – Konversationsdienste (Conversational sevices),
    • – Distributionsdienste (Distribution services)
    • – Informationswiedergewinnungsdienste (Information retrieval sevices)
  • Das durch die vorliegende Erfindung vorgeschlagene Konzept kann an diese unterschiedlichen Typen von Diensten angepasst werden. Der Grund ist, dass abhängig vom Typ des Dienstes unterschiedliche Folgen von Aktionen für die Interaktion zwischen reservierendem Netzwerk und Endsystemressourcen, die auch vom Kommunikationsmodus jedes Peers (Sender/Empfänger) abhängen, erforderlich sein können.
  • Beispielsweise müssen Fragen wie ob ein Empfänger darauf warten muss, von einem Sender kontaktiert zu werden, oder wer eine Ressourcenreservierung auf dem Netzwerk initiiert (der Sender oder der Empfänger) adressiert werden. Die Antworten auf diese Fragen hängen vom Typ des Dienstes ab.
  • Das Konzept eines End-to-End Negotiation Protocol (E2ENP) Die Herstellung einer QoS-befähigten Kommunikationssession kann startend mit einer Verhandlung von QoS-Aspekten auf einer End-to-End-Basis in einem Mehrschrittprozess ausgeführt werden. Die hierdurch vorgeschlagene Idee ist, dass man Peers hat, die im Voraus (das heißt bevor die tatsächliche Kommunikation stattfindet) eine gemeinsame Ebene von QoS verhandeln, über deren Benutzung Peers übereinkommen können. Dies ist eine Form einer Vorverhandlung eines Vokabulars, das Peers später für ein effizientes Behandeln von abhängigen Verhandlungen (beispielsweise bei einer Herstellung von Audio/Video-Strömen) oder Wieder- bzw. Neuverhandlungen (Änderung des QoS-Vertrags während weitergehender Sessionen) benutzen können. Der Vorteil dieser Vorgehensweise ist, dass die zur Neuverhandlung notwendige Zeit reduziert wird, da sich die Peers nur auf einen verhandelten Zustand und nicht auf die Ausführung eines vollen Verhandlungszyklus während eines Strömens (during streaming) beziehen müssen. Außerdem kann der Typ einer Verhandlung auf Basis von Fähigkeiten, die allen Peers laufend verfügbar sind, zugeschnitten werden.
  • Die identifizierten Schritte sind:
    • 1. Vorverhandeln eines Satzes von QoS-Verhandlungen mit den Peers. Ein solcher Satz beschreibt einen Adaptatationspfad für einen generischen Strom eines gegebenen Typs (beispielsweise Audio-, Video- oder Datenströme).
    • 2. Als einen Zwischenschritt verhandeln Peers QoS-Korrelations- und -Synchronisationsaspekte zwischen mehreren Strömen. Dies muss möglicherweise nicht notwendig sein, wenn eine Session nur einen einzelnen Strom aufweist. In diesem Fall würde eine QoS-Korrelation einfach ignoriert. Auf diese Weise baut dieser Schritt das Sessions-Konzept auf. Es sei darauf hingewiesen, dass im Fall, dass Peers mehrere Ströme zu koordinieren haben, QoS-Korrelations- und -Synchronisationsprobleme bei Laufzeit durch Auslösen spezieller Koordinationsfunktionen (auf Basis beispielsweise eines RTP), die von den verhandelten QoS-Zuständen abgeleitet werden, behandelt würden.
    • 3. Als einen letzten Schritt verhandeln Peers QoS-Verträge auf einer Per-Strom-Basis zur Stromherstellungszeit auf Basis des während des Schritts (1) hergestellten vorverhandelten Vokabulars. Bei diesem Schritt wird eine tatsächliche Zugangssteuerung ausgeführt. Zu diesem Zweck wird gemäß einem Aspekt der vorliegenden Erfindung vorgeschlagen, einem Ökonomieprinzip zu folgen, das die Tatsache, dass Netzwerkressourcen gemeinsam benutzt werden müssen und teuerer als lokale Ressourcen sind, beachtet. Der hierdurch vorgeschlagene Prozess basiert auf den Schritten in der folgenden Ordnung: 3.1 Lokale Ressourcen (das heißt vom lokalen System gemanagte (verwaltete) Ressourcen) wie CPU, Speicher und Energie bzw. Leistung werden auf dem Endgerät der die Kommunikation initiierenden Partei (das heißt dem Initiator) reserviert. Diese sind die billigsten Ressourcen, da sie ausschließlich vom Initiator benutzt werden. Die Menge von Ressourcen, die von der initiierenden Partei reserviert werden, korrespondiert mit der Qualität des Initiators, ist am interessantesten und kann gemeistert werden. 3.2 Ferne Ressourcen wie CPU, Speicher und Energie bzw. Leistung werden auf dem Endgerät der die Anforderung zum Herstellen der Kommunikation akzeptierenden Partei (das heißt des Antworters) reserviert. Diese Ressourcen können eventuell von mehreren Initiatoren in Bezug auf mehrere Telekommunikationssessionen wie im Fall eines Video-nach-Bedarf-Szenarios (bei dem der Antworter der Videoserver ist, der mehrere Anforderungen von mehreren Benutzern bedienen muss) gemeinsam benutzt werden. Es macht keinen Sinn zu versuchen, diese gemeinsam benutzten Ressourcen zu reservieren (und so andere Kommunikationssessionen beim Antworter zu beeinflussen), bevor die Verfügbarkeit von Ressourcen auf der Initiatorseite festgestellt ist. 3.3 Nur wenn sowohl lokale als auch ferne Ressource erfolgreich reserviert worden sind, werden Netzwerkressourcen reserviert, die (per Definition) von mehreren Parteien gemeinsam benutzt werden und deshalb in diesem Ausmaß als die insgesamt teuersten Ressourcen angesehen werden können.
    • 4. Diese Erfindung beschreibt eine Protokollprozedur zum Informieren von Peers über Änderungen in der Fähigkeitskonfiguration (beispielsweise die Installation oder Entfernung eines gegebenen Multimediacodecs) eines gegebenen Teilnehmers der gegebenen Kommunikationssession. Durch proaktives Verbreiten dieser Information unter Peers können in Bezug auf jede laufend aktive Kommunikationssession und all die Verhandlungsprozesse, die künftige Versuche zur Herstellung von Kommunikationssessionen betreffen, richtige Aktionen getroffen werden.
  • Die Schritte (2) und (3) (oder (1)2, (2) und (3)) können als einmalige3 oder separat als Folge von Aktionen4 gemeinschaftlich behandelt werden.
  • 2In einem solchen Fall müssen möglicherweise Vorverhandlungen nicht länger gültig sein, sollte sich eine neue Partei einer Session mit einem anderen Verständnis dafür, was ein Adaptationspfad in Bezug auf die schon verhandelten ist, anschließen.
  • 3Als ein Beispiel sei gleichzeitiges Verhandeln und Aufbauen einer Session mit zwei Audio und drei Videoströmen genannt.
  • 4Zuerst Ausführen der Vorverhandlung, dann Starten mit dem ersten Strom und dann Hinzufügen des zweiten Stroms usw.) Es sei darauf hingewiesen, dass in gewissen Fällen möglicherweise nur die Schritte (3.1), (3.2) und (3.3) notwendig sein müssen. Beispielsweise kann dies der Fall sein, wenn alles mittels Voreinstellung (durch Benutzung fester Einstellungen) vorverhandelt wird und nur eine Qualität und Konfiguration eines Videostroms auf einem Server lokalisiert ist.
  • Ein Schlüsselaspekt des E2ENP ist, dass es nicht nur in Verbindung mit Netzwerkressourcenreservierung signalisierenden Protokollen, sondern auch mit anderen Typen von QoS-Architekturen benutzt werden kann. Im letzteren Fall fokussiert eine Vorverhandlung darauf, Peers zu haben, die, in Bezug auf die Fähigkeiten jedes Peers, über die Typen von zu benutzenden QoS-Klassen übereinkommen.
  • Was zu verhandeln ist (What to negotiate)
  • Dieser Abschnitt fokussiert darauf, (i) welcher Typ von Information (ii) unter welchen Umständen verhandelt werden muss.
  • Insbesondere sollten Peers darüber übereinkommen,
    • – welches E2ENP (oder andere Protokoll) zu benutzen ist,
    • – welche Fähigkeiten und Konfigurationen verfügbar und anwendbar sind,
    • – welche QoS-Verträge anwendbar sind und den Adaptationspfad bilden und über
    • – die Adaptationspfade selbst.
  • Typen eines unterstützten E2ENP (Types of supported E2EnP)
  • Die meisten Anwendungen des Standes der Technik sind nicht fähig, das hier beschriebene E2ENP ohne irgendeine spezielle Nach- oder Umrüstung anzuwenden. Eher wenden sie eventuell eine gewisse andere Form eines Verhandlungsmechanismus des Standes der Technik an. Es ist auch vernünftig anzunehmen, dass gewisse künftige Anwendungen eventuell nur teilweise das E2ENP oder gerade andere Versionen davon unterstützen.
  • Aus diesen Gründen ist der erste Typ von Information, der verhandelt werden muss, der Typ und die Version eines unterstützten "E2ENP".
  • Dies kann durch Benutzung eines Verzeichnisservers (directory server) ausgeführt werden. Als ein Beispiel würde ein mit einen gegebenen Peer assoziierter und E2ENP genannter Verzeichniseingang (directory entry) als ein Token wirken, das anzeigt, dass der gegebene Peer das E2ENP unterstützt. Der Verzeichniseingang könnte aussehen wie
    E2ENP = (type of service, protocol to be used, version)
  • Wobei „type of service" (Servicetyp) einen Informationsiwedergewinnungsdienst oder Konversationsdienst anzeigen könnte, „protocol" (protocol to be used = zu benutzendes Protokoll) SIP (zusammen mit SDP) oder H.323 oder RTSP (das heißt welches Protokoll ist das gegebene E2ENP, auf dem basiert ist) anzeigen könnte und „version" (Version) eine Zahl unterscheidender inkrementaler Sätze von Funktionalität anzeigen könnte. Außerdem werden zu den oben erwähnten Protokollen spezielle Erweiterungen benötigt, um die Verhandlung auszuführen und den Adaptationspfad zu beschreiben.
  • Als ein Beispiel kann das E2ENP – auf Basis des Diensttyps – auf die folgenden Protokolle abgebildet werden:
    Diensttyp Protokolle
    Konversationsdienste (Conversational services) SIP (zusammen mit SDP)/H.323 + Erweiterungen
    Distributionsdienste (Distribution services) SAP + RTSP + Erweiterungen
    Audio/Video-nach-Bedarf-Dienste (Schiebe/Zieh-Dienste) (Audio/Video an Demand (Push/Pull) services) RTSP + Erweiterungen
  • Diese Information kann nicht nur von den Peers absichtlich direkt abgefragt werden, sondern die Verzeichnisserver selbst können sie auch proaktiv verteilen.
  • Fähigkeiten (Capabilities)
  • Verschiedene Typen von Fähigkeiten müssen zwischen Peers verhandelt werden:
    • – Mediatypen und QoS-Vertragsdimensionen (Media Types and QoS Contract Dimensions)
    • – Bitraten
    • – Codecs
    • – Endgerätfähigkeiten (Terminal capabilities)
    • – Netzwerkressourcenreservierungsunterstützung (Network Resource Reservation support)
  • Die folgenden Abschnitte analysieren im Detail jeden Typ von Fähigkeiten.
  • Mediatypen und QoS-Vertragsdimensionen
  • Der Typ von Media (Audio/Video/Daten) kann zur Abschirmung (screening) irgendeines Stücks von Information in E2ENP-Mitteilungen benutzt werden. Peers kommen über einen gemeinsamen Satz von Mediatypen überein. Wenn als ein Beispiel ein Empfänger anfordert, einen Live-Audiostrom herzustellen, aber der korrespondierende Audiostromsender kein Mikrofon hat, ist eine weitere Verhandlung von Audiocodecs sinnlos und kann deshalb übersprungen werden. Die Benutzung von Mediatypen übersetzt auf diese Weise beim Strukturieren der E2ENP-Mitteilungen in ein Format, das für die Peers während der Verhandlung bequem ist. Zusätzlich zu Mediatypen identifiziert diese Erfindung die Notwendigkeit, die Liste von QoS-Vertragsdimensionen, aus denen die Verträge gemacht sind, zu inkludieren. Als ein Beispiel kann ein Peer möglicherweise Rahmenrate (frame-rate) und Rahmengröße (frame-size) verhandeln wollen, während andere Peers möglicherweise nur Rahmenrate verhandeln wollen.
  • Als ein Beispiel kann es möglicherweise nutzlos sein zu versuchen, die Rahmengröße zu verhandeln, wenn ein VoD-Server nur eine Darstellung (Version) des Films zur Verfügung hat und keine Netzwerkmediaadaptationseinheit (network media adaptation unit) verfügbar ist.
  • Diese Erfindung schlägt das folgende Format, das Mediatypinformation beschreibt, vor:
    mediaType = (audio(param_audio), video(param_video))
  • Die Verfeinerungen „param_audio" und „param_video" detaillieren die QoS-Vertragsdimensionen wie Rahmengröße, Rahmenrate für Video und Abtastfrequenz und Anzahl von Kanälen für Audio und werden in den nächsten Abschnitten beschrieben. Dieses Format ist bei jeder Mediatypbeschreibung in einer gegebenen E2ENP-Mitteilung anzuwenden.
  • Codecs
  • Bevor Peers QoS-Verträge oder auch Adaptationspfade verhandeln (siehe unten) sollen sie zuerst darüber übereinkommen, welche Codecs generell anwendbar sind. Die erzielbare QoS hängt auch vom Typ verfügbarer Codecs ab. Außerdem ist, selbst wenn ein gegebener Peer mit einem gegebenen Satz von Codecs aus Rahmenet ist, die Benutzung solcher Codecs durch die Verfügbarkeit äquivalenter Codecs bei allen anderen Peers tatsächlich beschränkt.
  • Heutige SIP-Implementierungen ermöglichen die Verhandlung von Codecs zur Einladungszeit auf einer Peer-zu-Peer-Basis und in Bezug auf die Spezifikation wohldefinierter Ströme.
  • Im Rahmen (framework) der vorliegenden Erfindung ist eine Erweiterung einer solchen SIP-Fähigkeit durch Verhandeln der vollständigen Liste verfügbarer Codecs während des Schritts (1) der oben genannten Schritte (1) bis (4) ungeachtet dessen, welche Ströme später zur Stromherstellungszeit benutzt werden, vorgeschlagen. In anderen Worten können Peers auf diese Weise auf einer gemeinsamen Teilmenge von Codecs übereinkommen, bevor die tatsächliche Mediaspezifikation stattfindet.
  • Da außerdem derzeitige und künftige Endgeräte fähig sein sollen, Codecs „im Flug" zu installieren oder entfernen, muss möglicherweise die gemeinsame Menge von Codecs später während der Verbindungszeit (beispielsweise während einer Videokonferenz) neu verhandelt werden. Die Neuverhandlung könnte durch Benutzung neuer SIP-Mitteilungen erreicht werden.
  • Bitraten
  • Zwei Hauptmechanismen werden von Clients zum Minimieren der für Multimediaanwendungen benutzten Größe von Bandbreite angewendet:
    • – Benutzung eines Codecs niedriger (konstanter) Bitrate und dadurch Reduzierung des Netzwerkressourcenbedarfs,
    • – Benutzung von Codecs variabler Bitrate.
  • Clients müssen über einen gewissen Satz (gewisse Menge) kompatibler Codecs übereinkommen. Es muss jedoch sichergestellt sein, dass die Bitrate, die der Codec erzeugt, sowohl von den Clients (zum Senden/Empfangen) als auch vom Netzwerk (sowohl den Zugriffsnetzwerken als auch dem Kern) unterstützt wird. Außerdem kann ein einzelner Codec unterschiedliche Bitratenpegel erzeugen, was von der Codec-Konfiguration abhängt. Als ein Beispiel kann der G.726-Codec Bitraten von 16, 24, 23 oder 40 kb/s erzeugen. Es kann Situationen geben, bei denen der Empfänger nur eine gewisse Konfiguration des gegebenen Codecs handhaben kann. Wenn als ein Beispiel der Empfänger ein 19,6 kb/s-Modem benutzt, kann der Empfänger nur die 16 kb/s-Konfiguration des G.726-Codecs handhaben. Außerdem können gewisse Audiocodecs und mehrere Videocodecs eine variable Bitrate erzeugen, die typischerweise unter Benutzung eines Leckbithaufenmodells (leaky bucket model) spezifiziert wird. In diesem Fall werden die Bitratenerfordernisse und Benutzung einer aufrechtzuerhaltenden Bitrate, einer Spitzenbitrate und einer Burstzeit (Zeitdauer, die anzeigt, wie lange die Quelle mit der Spitzenbitrate senden darf) spezifiziert. Diese Erfindung schlägt vor, dass zusätzlich zu einer Verhandlung des Satzes von kompatiblen Codecs die Peers für jeden Codec über eine gültige Codec-Konfiguration in Form einer Bandbreite, die jeder Peer handhaben kann, übereinkommen müssen. Der Initiator stellt bereit und verhandelt einen Satz von Bandbreitespezifikationen mit den das Leckbithaufenmodell (aufrechtzuerhaltende Bitrate, Spitzenbitrate, Burstzeit) benutzenden Peers, was sowohl konstante als auch variable Bitraten unterstützt. Beim obigen Beispiel würden beide Parteien über dem G.726-Codec mit der folgenden Bitratespezifikation: (Aufrechtzuerhaltende Bitrate, Spitzenbitrate, Burstzeit) = (16, 16, N/A), übereinkommen.
  • Ist über eine kompatible Codec-Konfiguration in Form von Bitraten übereingekommen worden, werden während des Schritts (3) tatsächliche Zielbitraten, die bei der tatsächlichen Konfiguration benutzt werden, mit dem Netzwerk verhandelt.
  • Endgerätfähigkeiten
  • Die physikalischen Charakteristiken von Endgeräten (beispielsweise Monitorgröße) kann sich von Modell zu Modell ändern und die Abgabe von Diensten über Telekommunikationsnetzwerke beeinflussen. Dies ist wichtig, da es beispielsweise keinen Sinn macht, ein Video in HDTV-Qualität zu einem Mobiltelefon zu strömen, das mit einer viel kleineren Anzeige ausgestattet ist. Deshalb müssen Peers beim Verhandeln von QoS über Endgerätfähigkeiten übereinkommen. Solche Endgerätfähigkeiten sind beispielsweise die Größe der Anzeige, die Anzahl verfügbarer Farben, die generellen Fähigkeiten zur Vervollständigung bzw. Aufbereitung (rendering) eines gegebenen Mediatyps (beispielsweise wenn ein Audiomischer verfügbar ist) und alle Arten von Information für Dienste, die zur Vervollständigung bzw. Aufbereitung eines gegebenen Mediatyps notwendig sind.
  • Zu diesem Zweck bietet die CC/PP-Rahmensprache (CC/PP = Composite Capabilities/Preference Profiles (Zusammengesetztfähigkeiten/Präferenzprofile)) (eine Kombination aus XML und RDF) und das Anfrage/Antwort-HTTP-Protokoll (request/reponse HTTP protocol) einen bequemen Weg zum Spezifizieren von Endgerätfähigkeiten in einem RDF-Format.
  • Netzwerkressourcenreservierungsunterstützung
  • Es ist nutzlos zu versuchen, Netzwerkressourcen unter Benutzung eines Signalisierungsprotokolls wie RSVP End-to-End (End-zu-End) anzufordern, wenn vorher festgestellt werden kann, dass einer oder mehrere ferne Peers das RSVP nicht kennen. Zu diesem Zweck ist eine mögliche Lösung, Peers aufzufordern zu prüfen, ob bei ihren Zugriffsnetzwerken ein gegebenes Signalisierungsprotokoll verfügbar ist.
  • Eine weniger komplexe Lösung ist, dass Peers während einer Vorverhandlung einander anzeigen, entlang welcher Richtung sie zum Reservieren von Netzwerkressourcen gehen. Zulässige Werte sind N/A, Sender, Empfänger, Sender/Empfänger, wobei sich die Konzepte von Sender und Empfänger auf das benutzte Ressourcenreservierungsprotokoll (wenn es eines gibt) beziehen. Diese Information kann tatsächlich den Typ von benutztem Reservierungsprotokoll, wenn es eines gibt, modellieren.
  • Beispielsweise agiert in einem einfachen Video-on-Demand-Dienstszenario mit RSVP-verfügbarem End-to-End der Client als ein Empfänger, während der Server als ein Sender wirkt, da das RSVP Empfänger-initiiert ist. Im Fall von YESSIR (siehe [Pan99]), das Sender-initiiert ist, wäre die Konfiguration – aus einer Ressourcenreservierungsprotokoll-Perspektive – entgegengesetzt.
  • Ähnlich würde in einem Videokonferenzszenario mit End-to-End-RSVP-Unterstützung jeder Peer typischerweise als Sender/Empfänger konfiguriert.
  • Wenn für einen gegebenen Peer keine Richtung spezifiziert ist, können die korrespondierenden Peers unmittelbar ableiten, dass kein Netzwerkressourcenreservierungsmechanismus beim gegebenen Peer verfügbar ist. Der Knackpunkt (key point) ist, dass dieses Modell ermöglicht, auch Fälle zu meistern, wo kein QoS-Signalisierungsprotokoll (wie RSVP) End-to-End verfügbar ist. In einem solchen Fall würde jeder Peer einfach als ein Sender (oder garnichts) modelliert. Diese Erfindung integriert die letztere Lösung.
  • QoS-Vertrag
  • QoS-Verträge werden hier als Sätze von Hohe-Ebene-QoS-Charakteristiken definiert, deren jede in der folgenden Form ausgedrückt wird:
    • – Betriebsziel (Operating target): der gewünschte Wert,
    • – Betriebsgebiet (Operating region): ein gewünschtes Intervall von Werten,
    • – Schwellen/Grenzen (Thresholds/limits): ein Satz von Werten der unterschiedliche Zustände in Bezug auf die QoS-Adaptationsgeschäftslogik markiert.
  • Jede der vorstehend erwähnten QoS-Spezifikationen kann eventuell in einem statistischen Format durch beispielsweise Feststellen von Prozenten, Mittelwert, Varianz usw. weiter ausgedrückt werden.
  • Adaptationspfad
  • Peers können nicht nur über einem gegebenen QoS-Vertrag, sondern auch über alternativen Verträgen, die vorteilhafter Weise immer benutzt werden, wenn die Netzwerk- und/oder Endgerätressourcenverfügbarkeit sich über der Zeit ändert, übereinkommen. Auf eine solche Weise weiß jeder Peer exakt, welcher alternative QoS-Vertrag (und unter welchen Umständen) forciert (z. B. geltend gemacht, durchgesetzt, erzwungen) werden soll, um eine kritische QoS-Änderung oder irgendeine QoS-Verletzung in Bezug auf den laufend forcierten QoS-Vertrag zu meistern.
  • Während des Schritts (1) der oben identifizierten Schritte (1) bis (4) werden nur strombezogene Adaptationspfade vorverhandelt. Solche höherer Ebene (mit QoS-Korrelationsausgaben assoziierte) sollen beim Schritt (2) der oben identifizierten Schritte (1) bis (4) auf höherer Ebene verhandelt werden.
  • Zusammen mit dem Bestfall-QoS-Vertrag bildet der Adaptationspfad einen erweiterten QoS-Vertrag. Dieser erweiterte QoS-Vertrag wird verhandelt und indexiert. Wenn ein Peer später entscheidet, auf eine niedrigere Ebene von QoS zu schalten, ist nur der Index, der den QoS-Vertrag als einen Zustand einer hierarchischen Maschine endlicher Zustände (hierachical Finite State Machine (FSM)) identifiziert, notwendig, um dem anderen Peer zu sagen, an diesen QoS-Zustand anzupassen.
  • Typen von E2ENP (Types of E2ENP)
  • Die bei Kommunikationssessionen teilnehmenden Akteure können als Rollen agieren wie:
    • – Sender/Empfänger: der Sender kann nur Daten zu einem Empfänger übertragen, während ein Empfänger Daten von einem Sender empfängt. Eine Zweiwegkonferenz kann mit einem Sender/Empfänger- und Empfänger/Sender-Paar modelliert werden.
    • – Initiator/Antworter: der Initiator lädt Antworter ein, an einer Kommunikationssession teilzunehmen. Der Antworter wartet auf eine Anfrage vom Initiator.
  • Mögliche Kombinationen sind:
    • – Initiator und Sender → Antworter (Responder) und Empfänger (Receiver)
    • – Initiator und Sender → Antworter und Sender
  • In dem Fall, dass der Initiator der Sender ist, initiiert der Sender eines Mediastroms die Session (der Sender lädt ein und der Empfänger wartet darauf, kontaktiert zu werden). Im Fall, dass der Initiator der Empfänger ist, initiiert der Empfänger eines Mediastroms die Session (der Empfänger lädt den Sender ein und der Sender wartet darauf, kontaktiert zu werden). Ein Intitiator/Sender kann mit einem Antworter/Empfänger sprechen. Ein Initiator/Empfänger kann mit einem Antoworter/Sender sprechen.
  • Im Folgenden werden die Schlüsselszenarios, welche den bei dieser Erfindung ins Auge gefassten Typ von E2ENP beeinflussen, aufgelistet.
    • – Peer-zu-Peer-Verhandlung (Peer-to-Peer negotiation): Kann tatsächlich auch auf mehrere Peers, die beispielsweise an einer Videokonferenz teilnehmen, aber wo jedes Peering (Peer-Zusammenbringen) durch einen direkten Peer-zu-Peer-QoS-Verhandlungsmechanismus reguliert wird, erweitert werden.
    • – 1×N-Rundsendeverhandlung (1×N Multicast negotiation): In diesem Fall müssen ein Sender und mehrere Empfänger eine oder mehrere QoS-Charakteristiken zu einem Zeitpunkt verhandeln. Dies kann entweder auf einer Verbindungsseitenbasis (das heißt einen für alle Peers guten kleinsten gemeinsamen Nenner bestimmen) oder auf einer Empfänger-ausgewählten Basis (Peer-zu-Peer-Verhandlung für gewisse QoS-Charakteristiken zwischen gewissen Peers – siehe vorhergehenden Punkt) ausgeführt werden. Im Fall einer Übereinkunftsebene besten Aufwands sind Empfänger noch fähig, zu kommunizieren, selbst wenn sie nicht auf einer kleinsten gemeinsamen QoS-Ebene übereinkommen, andernfalls (beispielsweise im Fall eines garantierten QoS-Grundsatzes) müssen diese Empfänger fallengelassen werden oder müssen andere Mechanismen angewendet werden. Als ein Beispiel können Media-Filter oder -Codeumsetzer zwischen einem Sender und einem Empfänger dazu benutzt werden, Mediaströme derart zuzuschneidern, dass Fähigkeiten von Empfängern und QoS-Zustände an QoS-Zustände von Sender angepasst werden können. Die Media-Codeumsetzer können dazu benutzt werden, von einer Darstellung in eine andere umzusetzen (beispielsweise den Codec des Mediastroms von PCM- in GSM-Audio umzuschalten). Für einer feinergekörnte Anpassung von Mediaqualitäten (beispielsweise Anpassung an Rahmengröße, Rahmenrate oder gewünschte Qualität, ohne den Sender zur Anpassung zu zwingwn) können Mediafilter benutzt werden. Das Verbindungsweite E2ENP kann zum Forcieren einer QoS-Korrelation zwischen mehreren Flüssen von unterschiedlichen Quellen effektiv benutzt werden. Die 1×N-Rundsendeverhandlung kann zum Bestimmen der gemeinsamen QoS nicht nur für den Fall eines zu mehreren Empfängern sendenden einzelnen Senders, sondern auch für den Fall eines einzelnen Empfänger, der die QoS von aus vielen Sendern ankommenden Flüssen korreliert, benutzt werden.
  • Die ITU-T-Empfehlung X.641 (12/97) ISO/IEC 13236: 1998, Information technology – Quality of Service: Framework, welche die vorstehend erwähnten Typen von Verhandlungen beschreibt, behandelt eine 3-Partei-Verhandlung, die einen Initiator, einen Anbieter (Provider) und einen oder mehrere Antworter (Responders) involviert. Bei dieser Erfindung beschränken wir unseren Schutzbereich bzw. Rahmen (scope) jedoch auf die Beziehung zwischen einem Initiator und einem oder mehreren Antwortern auf Anwendungsebene. Die Wahl, Anbieter nicht explizit direkt zu involvieren, ist aufgrund der Tatsache, dass Anbieter nur an Verkehr und Zugangssteuerung beteiligt sind. Deshalb müssen zwischen Peers und den Netzwerkanbietern nur Verkehrsverträge verhandelt werden. Dies kann nur während einer Sessionsherstellung getan werden, da es keinen Sinn macht, Ressourcen (insbesondere Netzwerkressourcen) für eine gegebene Zeitperiode im Voraus, das heißt ohne sie zu benutzen, zu reservieren.
  • Peers können deshalb die hier beschriebene E2ENP-Vorverhandlungsphase durch Übereinkommen über nominale QoS-Ebenen ausführen. Während einer tatsächlichen Verbindungsherstellung können Peers dann die vorverhandelten Verträge benutzen. Diese werden lokal getestet und Ressourcen werden reserviert. Das Resultat dieser Stufe wird dann den Peers offeriert, und alle übermäßigen Ressourcen werden eventuell freigegeben. Schließlich werden auf dieser Ebene Netzwerkressourcen reserviert, was wiederum zu einer Freigabe übermäßiger Ressourcen führen kann. Durch Überwachen der tatsächlichen Verbindungsqualität können Peers dann zu jedem Zeitpunkt entscheiden, ob die gegebenen vorverhandelten QoS-Verträge erfüllt sind, und wenn nicht, ob und wie eine andere QoS-Ebene auf Basis des vorverhandelten Adaptationspfads auszuwählen ist. Maßnahmen zur Vermeidung häufiger Anforderungen zur Änderung von Netzwerkressourcenreservierungen werden, wie es in der Europäischen Patentanmeldung 00 126 975.2 [Manda00b] beschrieben ist, durch richtiges Einbringen von Toleranzen und Hysteresie in die QoS-Verträge und Adaptationspfade hergestellt,.
  • In jedem Fall bewertet jeder Peer während der Vorverhandlungsphase die von anderen Peers empfangenen Angebotegegen vorkonfigurierte Benutzerprofile (User-Profiles), die vorausberechnete Adaptationspfade enthalten. Die Bewertung kann durch Vergleichen jedes Parameters jedes im Angebot bereitgestellten QoS-Vertrags mit der in den Benutzerprofilen enthaltenen korrespondierenden Information erreicht werden. Die Entscheidung, ob ein Angebot zu akzeptieren ist oder ein Gegengebot zu formulieren ist, wird in Bezug auf alle QoS-Dimensionen der Angebots-QoS-Verträge getroffen. Sollte das Angebot QoS-Verträge mit unterschiedlichen QoS-Dimensionen vorschlagen, würde nur die Teilmenge bzw. der Teilsatz gegenseitig verstandener QoS-Dimensionen berücksichtigt.
  • Der Initiator assoziiert jeden QoS-Vertrag seines Angebots mit einem Identifizierer. Antworter teilen die Akzeptanz eines gegebenen QoS-Vertrags (oder den Vorschlag für eine Aktualisierung desselben, als ein Gegengebot) durch Spezifizieren des korrespondierenden Identifizierers mit. Sollte ein Antworter eine bessere QoS-Vertragsentschließung (QoS Contract resolution) charakterisieren (wie im Fall eines gegebenen Angebots-QoS-Vertrags, in Korrespondenz zu welchem mehrere QoS-Verträge mit „feinerer" Körnigkeit bei einem der Antworter verfügbar sind), kann der Antworter zu einem Gegengebot mit neuen QoS-Verträgen zurückkehren. Es liegt am Initiator, diese Gegengebote zu sammeln, die bedeutungsvollsten zu wählen, sie mit neuen Identifizierern zu assoziieren und sie allen Peers in einer neuen Verhandlungsrunde vorzuschlagen.
  • Abbildung zwischen Typ von Dienst und Typ von E2ENP
  • Die folgenden Abschnitte beschreiben, wie ein E2ENP in Bezug auf die oben erwähnten unterschiedlichen Typen von Diensten entwickelt werden kann.
  • Konversationsdienste
  • Dies ist der Fall von Diensten wie Echtzeit-Videokonferenz oder CSCW. Die Schlüsselcharakteristik dieser Dienste ist, dass der Typ von zwischen Peers ausgetauschtem Inhalt am wahrscheinlichsten auf Benutzerinteraktionen mit Systemen und mit anderen Peers basiert ist. Beispielsweise tragen die meisten Videoflüsse Live-Bilder (beispielsweise von einer Web-Cam (Web- bzw. Internet-Kamera) aufgenommen).
  • Ein anderer wichtiger Aspekt ist, dass Peers im Voraus über eine gegebene Agenda, welche die Startzeit und Dauer des Dienstes enthält, übereinkommen müssen. Dies wird in der Internetwelt typischerweise durch Benutzung von SAP und SIP ausgeführt.
  • Die Art und Weise, wie dieser Typ von Diensten tatsächlich entwickelt wird, ist stark implementierungsabhängig. Wird als ein Beispiel eine Videokonferenz genommen, werden in der Telekommunikationswelt spezielle Brücken benutzt, um eine Sterntopologielösung zu offerieren. Jede interessierte Partei kann sich so einfach durch Kontaktieren der Brücke an eine Videokonferenz anschließen. In der Internetwelt ist andererseits die Benutzung einer Rundsendetechnologie üblich: Jede interessierte Partei müsste sich einfach auf die richtige Rundsendegruppe „abstimmen". Aus einer E2ENP-Perspektive jedoch nehmen wir hier an, dass Peers Unisendesignalisierung (unicast signaling) zur Verhandlung einer gemeinsamen Ebene von QoS benutzen sollen.
  • Konversationsdienste können als Fälle von einem einzelnen Initiator und mehreren Antwortern modelliert werden, wobei alle Peers als Sender und/oder Empfänger agieren können. Außerdem kann von einem Ressourcenreservierungsprotokoll jede Partei entweder ein Sender-betriebenes oder Empfänger-betriebenes Netzwerkressourcenreservierungsprotokoll (wenn es eines gibt) benutzen. Infolgedessen fordert ein Initiator gewisse Ressourcen vom Netzwerk und von einem Antworter (da der Antworter die Ressourcen zur Decodierung und Anzeige bereitstellen muss) an. Außerdem managt der Initiator seine eigenen Ressourcen lokal.
  • Distributionsdienste
  • Distributionsdienste können einen Inhaltsanbieter (content provider) und (i) bekannte oder (ii) unbekannte Inhaltskonsumenten (content consumers) involvieren.
  • Im früheren Fall könnte eine SIP- oder RPSP-Erweiterung ähnlich zu dem Fall von Informationswiedergewinnungsdiensten (information retrieval services) (siehe unten) benutzt werden, wobei im letzteren Fall SAP-Erweiterungen hierdurch berücksichtigt werden. Der Sender soll einfach die Liste von Rundsendegruppen, die Empfänger zur „Abstimmung" auf die laufende Inhaltsdistribution auswählen können, ankündigen.
  • Abgesehen vom Fall bekannter Inhaltskonsumenten kann nur eine reduzierte Version eines E2ENP auf ein SAP abgebildet werden. Der Adaptationspfad kann einfach so modelliert werden, dass der Inhaltsprovider den gleichen Inhalt mit unterschiedlichen QoS-Ebenen zu unterschiedlichen Rundsendegruppen (eine pro QoS-Ebene) strömt. Inhaltskonsumenten sollen deshalb einfach die an ihrem Endgerät/Zugriffsnetzwerk verfügbare Ebene von QoS überwachen und sich eventuell auf eine andere Rundsendegruppe abstimmen, wenn in der Zwischenzeit irgendeine QoS-Änderung oder QoS-Verletzung auftritt. Alternativ dazu könnte das voll aufgeblühte bzw. totale (full-blown) E2ENP in Verbindung mit Media-Filter/-Codeumsetzer im Netzwerk benutzt werden, wobei die Mediaströme zugeschnitten werden, um zu den unterschiedlichen QoS-Ebenen zu passen. Zu diesem Zweck sollten Inhaltskonsumenten die Media-Codeumsetzer/-Filter einfach instruieren, zu einer neuen QoS-Ebene zu schalten. Es liegt am Inhaltsanbieter und an den Empfängern, sicherzustellen, dass die auf unterschiedliche Rundsendegruppen verteilten Ströme gegenseitig synchronisiert sind.
  • Zu Optimierungszwecken kann der Sender jedoch die Anzahl von Empfängern pro Rundsendgruppe (Kanal) betreffende Statistiken sammeln, um ein Überfluten des Netzwerks mit Paketen unbenutzter Kanäle zu vermeiden. Dies erfordert eine Signalisierung zwischen dem Inhaltsanbieter und jedem Empfänger. Diese Erfindung adressiert jedoch solche Fälle nicht.
  • Informationswiedergewinnungsdienste
  • Dieser Typ von Diensten wird typischerweise durch Benutzung eines RSP-Protokolls gemanagt. Diese Erfindung schlägt Verbesserungen eines solchen Protokolls zur Erzielung von E2ENP-Zielen vor, ähnlich zu dem, was für den Fall von Konversationsdiensten beschrieben ist. Insbesondere muss man beachten, dass der RTSP-Prozess von den Empfängern durch Auffordern den Sender, gegebene Media (beispielsweise einen Videostrom) durch das RTSP DESCRIBE-Verfahren zu beschreiben, initiiert wird. Durch dieses Verfahren wird ein Empfänger über die unterschiedlichen QoS-Ebenen, die der Sender zum Abspielen des gegebenen Mediums forciert, informiert. Der Empfänger hat so die Möglichkeit zu wählen, welche Ebene zu irgendeinem gegebenen Zeitpunkt zu forcieren ist. Dies ist eine Form von Vorverhandlungsprozess gepaart mit einem Schnellverhandlungszyklus ähnlich dem durch diese Erfindung präsentierten Konzept. Die Schlüsselidee ist, das RTSP DESCRIBE-Verfahren zu verbessern, um alle Information über oben beschriebene Fähigkeiten zu inkludieren und das RTSP mit dem hierdurch präsentierten verteilten Ressourcenmanagementmechanismus zu integrieren.
  • QoS-Korrelationsmerkmale können auch durch Benutzung von SMIL [SMIL98] erreicht werden. Diese Erfindung adressiert die Integration einer solchen Technologie nicht.
  • End-to-End-Neuverhandlungsprotokoll (End-to-End Renegotiation Protocol, E2ERP)
  • Das E2ERP ist die auf Neuverhandlungsausgaben fokussierende Teilmenge des E2ENP. Dieses Protokoll wird immer aktiviert, wenn:
    • 1. QoS-Verletzungen bei einer in den Übertragungsprozess involvierten funktionellen Entität detektiert wird oder
    • 2. die laufend überwachte QoS-Ebene nicht länger mit dem derzeit forcierten QoS-Vertrag kompatibel ist oder
    • 3. eine Notifikation neu entdeckter zusätzlicher Ressourcen durch eine gewisse spezifische Funktionalität empfangen worden ist oder
    • 4. einer der Peers entschied, einen anderen QoS-Vertrag zu forcieren (beispielsweise forderte der Benutzer einer höhere Rahmenrate an).
  • Die Fälle 2 und 3 sind am stärksten auf Optimierungsprozesse bezogen, die es Anwendungen erlauben, ihre QoS-Erfordernisse in einer glatten Weise aufzurüsten/abzurüsten, während Fall 1 dramatische Mängel von Ressourcen behandeln, die Anwendungen ungünstig beeinflussen, wenn sie nicht richtig und prompt behandelt werden.
  • Zu diesem Zweck impliziert Fall 1 eine lokale Neuverhandlung und eventuell Netzwerkressourcen ohne die Notwendigkeit, zu versuchen, die vorher reservierten Ressourcen aufrechtzuerhalten, wohingegen dies in den Fällen 2 und 3 nicht möglich ist. Dies bedeutet, dass, immer wenn man sich mit Optimierungsprobleme befasst, man dafür sorgen muss:
    • – entweder Ressourcen im Übermaß der Differenz zwischen den vorher zugeteilten Ressourcen und der neuen Menge (im Fall einer QoS-Aufrüstung) zuzuteilen,
    • – oder die neuen Ressourcen von einem Arbeitsbereich bzw. einer Arbeitsdatei (scratch) zuzuteilen, während die alten beibehalten werden, bis die Neuverhandlung erfolgreich vollendet worden ist (pessimistische Lösung). Dies kann auch als Versuch, mehr Ressourcen zuzuteilen, während die alten noch beibehalten werden, modifiziert werden. Wenn diese Neuzuteilung fehlgeht, sind die ursprünglich reservierten Ressourcen noch reserviert, andernfalls stehen die neu zugeteilten Ressourcen zur Verfügung;
    • – gewisse Ressourcen zum Schalten in einen niedrigeren QoS-Zustand (im Fall einer QoS-Abrüstung) freizugeben.
  • Die erste Option scheint ganz attraktiv zu sein, aber gewisse Ressourcen können zwischen unterschiedlichen QoS-Zuständen möglicherweise nicht einfach gemeinsam benutzt werden. Beispielsweise kann die Zeitberechnungs- bzw. Zeitsteuerungsinformation über den Teilprozess (thread) eines gegebenen Codecs möglicherweise total nutzlos sein, wenn der Codec gerade dabei ist, verdrängt und durch einen anderen ersetzt zu werden, der auf einem total anderen Teilprozess läuft.
  • Deshalb erscheint die zweite Vorgehensweise, wenngleich pessimistisch, die realistischste zu sein. Im folgenden beziehen wir uns deshalb explizit auf die Zuteilung neuer Ressourcen und spätere Freigabe alter. Außerdem ist die Freigabe von Ressourcen immer möglich, da die Systembelastung erniedrigt wird.
  • Immer wenn eine Neuverhandlung ausgelöst wird, bestimmt jeder Peer aus dem vorverhandelten Adaptationspfad den besten alternativen QoS-Vertrag, der forciert werden sollte, um die detektierte QoS-Änderung/-Verletzung zu meistern. Die Identität des neuen QoS-Vertrags wird zwischen den Peers ausgetauscht, um zu einer Übereinkunft darüber zukommen, welcher QoS-Vertrag tatsächlich forciert werden sollte. Ein vorheriges Verhandeln des Adaptationspfads ermöglicht den Peers, eine solche erneute Verhandlung durch einfaches Austauschen von Identifiziern effizienter auszuführen. Sollten alle Peers eine Verletzung gleichzeitig detektieren, müsste eine gewisse Form eines Streitauflösungsalgorithmus forciert werden. Zu diesem Zweck stehen wohlbekannte unterschiedliche Techniken zur Verfügung: Zuordnen von Master/Slave (Herr/Diener)-Rollen (wobei typischerweise dem Initiator die Masterrolle zugeordnet wird) oder erneutes Versuchen nach Ablauf einer Zufallszeit. Diese Erfindung setzt den Master/Slave-Mechanismus wirksam ein.
  • In Zusammenfassung werden die folgenden Typen von Neuverhandlung identifiziert:
    • a) durch eine QoS-Verletzungs-Detektion ausgelöste Neuverhandlung, wobei vom Arbeitsbereich bzw. der Arbeitsdatei neue Ressourcen zugeteilt werden und die alten Ressourcen automatisch freigegeben werden (für QoS- Abrüstungsfälle ist dies möglicherweise kein Problem sein);
    • b) Neuverhandlung zum Optimieren des Systems, wobei vom Arbeitsbereich bzw. der Arbeitsdatei neue Ressourcen zugeteilt werden und die alten Ressourcen später bei einer E2ERP-erfolgreichen Vollendung freigegeben werden und
    • c) Neuverhandlung zum Optimieren des Systems, wobei vom Arbeitsbereich bzw. der Arbeitsdatei neue Ressourcen zugeteilt werden und die alten Ressourcen automatisch freigegeben werden.
  • Ein Rahmen für dynamische End-zu-End-QoS-Verhandlung und -Steuerung
  • Diese Erfindung präsentiert ein Rahmen (framework) zur Erzielung einer dynamischen End-to-End-QoS-Verhandlung und -Steuerungskoordinierung für verteilte Multimediaanwendungen. Das Rahmen baut auf dynamische Fähigkeitsverhandlung und Spezifikation von Adaptationspfaden und QoS-Verträgen auf Basis von Benutzerpräferenzen. Diese Prinzipien werden nun anhand der Figuren erläutert.
  • Der Initiator 101 findet die Protokollversion unter Benutzung einer Protokollentdeckungseinheit 104, 213 über eine Schnittstelle 214, die einen Verzeichnisserver 102, 215 abfragt. Dies wird mit der lokalen Koordinationseinheit 204 koordiniert. Die Sessionsprotokolleinheit 205 wird für alle Arten von Verhandlungen und Kommunikation benutzt. Insbesondere verhandelt sie mit dem Peer 216 (der ein Antworter 103 ist) einen gemeinsamen Satz von Fähigkeiten und Konfigurationen und baut auf diese Weise in der Vorverhandlungsphase 106 ein Vokabular auf. Sie verhandelt auch QoS-Verträge und Adaptationspfade, die für die Mehrstrom-QoS-Synchronisations- und -QoS-Korrelationsphase 107 benutzt werden. Ein lokales Ressourcenmanagement wird von den Lokalressourcenmanagementeinheiten (ansprechbar für CPU, Puffer und andere lokale Ressourcen) 206 über eine Schnittstelle 211 ausgeführt. Lokalressourcenmanagement wird von der Koordinationseinheit 204 mit Netzwerkressourcenreservierung, die von der Netzwerkressourcenreservierungseinheit 207 ausgeführt wird, über eine Schnittstelle 212 koordiniert.
  • Jede End-to-End-Interaktion während einer Kommunikationssessionsherstellung, das heißt während der Schnellverhandlungsphase 108, wird durch Folgen dem Ökonomieprinzip ausgeführt. Dieses Prinzip legt fest, dass zuerst Lokal-, dann Peer- und schließlich Netzwerkressourcen reserviert werden. Wenn während der Kommunikationssession aufgrund einer Änderung in der Ressourcenverfügbarkeit oder irgendeinem anderen die Ressourcenverfügbarkeit beeinflussenden Grund eine Neuverhandlung notwendig wird, wird die Neuverhandlungsphase 109 ebenso durch Folgen dem Ökonomieprinzip ausgeführt.
  • Schließlich werden während der Freigabephase 110 Ressourcenreservierungen freigegeben. Der lokal Protokollstapel 208 ist mit der Sessionsprotokolleinheit 205 über die Schnittstelle 217 Schnittstellen-verbunden und implementiert das Sessionsprotokoll. Außerdem implementiert der Protokollstapel 208 das Netzwerkressourcenreservierungsprotokoll, das über die Schnittstelle 210 gesteuert wird.
  • Die QoS-Gewahrwerdungs-Anwendungseinheit (QoS Aware Application Unit) 202 benutzt eine FSM-Maschineneinheit 203 zur Steuerung der Zustände all der Ströme, welche die QoS-Gewahrwerdungs-Anwendungseinheit 202 behandelt. Die Koordinationseinheit 204 stellt zusammen mit der FSM-Maschineneinheit über die Schnittstelle 209 den QoS-Gewahrwerdungs-Anwendungseinheiten 202 die Möglichkeit zur Herstellung, Benutzung, Steuerung und Freigabe von Netzwerkverbindungen mit anderen Anwendungen unter Benutzung von QoS-Garantien bereit. Die Herstellung solcher Verbindungen involviert Verhandlung von Fähigkeiten, Konfigurationen, QoS-Verträgen und Anwendungspfaden (von der FSM-Maschineneinheit 203 gemanagt) und Integration von Lokal, Peer- und Netzwerkressourcen entsprechend dem Ökonomieprinzip. Steuerung (control) involviert Neuverhandlung und Integration von Lokal-, Peer- und Netzwerkressourcen und kann einen von der FSM-Maschineneinheit 203 gemanagten Zustandsübergang in Kooperation mit der Koordinationseinheit 204 involvieren. Freigabe (release) involviert Netzwerk- und Lokal- sowie Peerressourcenabbau- und Zustandsmanagement (durch die FSM-Maschineneinheit 203) in Kooperation mit der Koordinationseinheit 204.
  • Diese Erfindung präsentiert auch das Konzept des E2ENP-Brokers(-Vermittlers) 105, einer optionalen Drittparteientität, die zum Entlasten der Peers 101, 103 von der Ausführung der Zeit und Ressourcen raubenden Vorverhandlungsphase 106 (und eventuell auch der Mehrstrom-QoS-Synchronisation und -QoS-Korrelation 107) benutzt werden kann. Jeder Peer 101, 103 kann nach Entdeckung seitens eines Verzeichnisservers 102, welcher E2ENP-Broker 105 zu kontaktieren ist, seinen Adaptationspfad, seine Fähigkeiten und die Liste von auf dem E2ENP-Broker 105 zu kontaktierenden Peers hinaufladen. Der E2ENP-Broker 105 kann beispielsweise als eine verbesserte Version von Audio-/Videokonferenzbrücken oder durch Kombinieren eines verbesserten SIP-Proxyservers (oder SIP-Umadressierungsservers) – behandelt den Verhandlungsprozess – und einer verbesserten Version eines SIP-Registrators (SIP registrar) – speichert den Adaptationspfad und Fähigkeiten und alle ihre zwischenverhandelten Versionen – implementiert werden.
  • Der E2ENP-Broker 105 sammelt auf diese Weise solche Information von jedem Peer 101, 103 und führt den Verhandlungsprozess in seinem Speicherraum lokal aus. Während dieses Prozesses kann der E2ENP-Broker 105 eventuell gewisse der angezeigten Antworter 103 im Interesse des oder der Initiatoren 101 kontaktieren, sollten solche Antworter 103 ihre Information bezüglich des E2ENP-Brokers 105 noch nicht gespeichert haben. Wenn die Verhandlung einmal erfolgreich ausgeführt worden ist, informiert der E2ENP-Broker 105 die Peers 101, 103 über die Verfügbarkeit der Resultate, und jeder Peer 101, 103 kann dann die Resultate herunterladen. Der E2ENP-Broker 105 kann auch mehrere Verhandlungiterationen ermöglichen (die andernfalls zwischen den Peers selbst auszuführen zu teuer sind). Antworter 103 stimmen möglicherweise einem Angebot seitens des Initiators 101 nicht zu und machen deshalb Gegengebote. Die Analyse von Gegengeboten involviert mehrere Rundgangsmitteilungsaustauschungen zwischen Peers und ist deshalb zu Zeitraubend. Der E2ENP Broker 105 kann alle diese Prozesse vermitteln.
  • Beispiel
  • Das Beispiel in diesem Abschnitt stellt die Konzepte unserer Erfindung dar. Es basiert auf einem Echtzeit-Multimediakonferenzszenario unter Benutzung IP-basierter Netzwerke. Ein Mediatransport wird durch Benutzung von RTP/RTCP ausgeführt.
  • Aus Einfachheitsgründen zeigen wir das Prinzip der Erfindung unter Benutzung eines Pseudoprotokolls (QUERY (Anfrage), RESPONSE (Antwort), COMMIT (Übergabe), START (Start), START_ACK (Start Rückmeldung), RESERVE (Reservieren), CONFIRM (Bestätigung)), das auf ein zu standardisierendes existierendes SIP/SDP plus Erweiterungen abgebildet werden kann. Auch ist dieses Beispiel auf zwei Peers A und B beschränkt. Es sei angenommen, dass der Initiator 101 einen Mediastrom (es sei Video angenommen) vom Antworter 103 empfangen will.
  • Der E2ENP-Prozess startet mit der Vorverhandlungsphase 106 unter der Annahme, dass die Protokollentdeckung 104 früher erfolgreich ausgeführt worden ist, wobei eine gemeinsame E2ENP-Version figuriert worden ist, die beide Parteien verstehen.
  • Bei der Vorverhandlungsphase 106 fordert die QoS-Gewahrwerdungs-Anwendungseinheit 202 eine Verhandlung unter Benutzung der lokalen FSM-Maschineneinheit 203 an wobei sie ein Angebot macht. Dieses Angebot enthält eine Liste von Fähigkeiten und Konfigurationen sowie QoS-Verträge und den oder die Adaptationspfade, die alle indexiert sind. Die Beschreibung des Angebots kann unter Benutzung von SDP-Erweiterungen (beispielsweise als ein neues Merkmal des derzeit untersuchten SDPng [DPNG00]) realisiert werden.
  • Die Koordinierungseinheit 204 gibt das Angebot über die Sessionsprotokolleinheit 205 an den die QUERY-Mitteilung, die auf SIP-Erweiterungen basieren kann, benutzenden Peer weiter. Die Sessionsprotokolleinheit 205 des Peers empfängt die QUERY und fordert den Peerkoordinator 204 auf, das Angebot unter Benutzung der Peer-FSM 203 zu evaluieren. Die Peer-FSM passt das Angebot an seinen eigenen Adaptationspfad und seine eigenen Fähigkeiten an und erzeugt einen gemeinsamen Teilsatz (Teilmenge), der in der Antwortermitteilung über den Peerkoordinator 204 an die Peer-Sessionsprotokolleinheit 205 weitergegeben wird, die eine RESPONSE-Mitteilung erzeugt, die auf SIP-Erweiterungen basiert sein kann. Die Sessionsprotokolleinheit 205 des Initiators gibt beim Empfang des neuen Angebots eine Evaluierungs-Anforderung über den Koordinator 204 an die lokale FSM 203 weiter. Schließlich wird das neue Angebot wieder auf Kompatibilität geprüft (es kann möglicherweise leer sein, was anzeigt, dass die Peers inkompatibel sind), und die FSM-Maschine 203 des Initiators (101) sammelt alle neuen Angebote von allen Antwortern und erzeugt einen gemeinsamen Teilsatz, der dann zu allen Peers gesendet wird. Dies wird durch zuerst Senden einer Forcierungs-Mitteilung zum Koordinator 204 ausgeführt, der ihn zur Einheit 205 weitergibt. Die Sessionsprotokolleinheit 205 des Initiators erzeugt die Commit-Mitteilung, die auf SIP-Erweiterungen basieren kann. Die Mitteilung trägt das Angebotsanpassungsresultat (das unter Benutzung von SDP-Erweiterungen beschrieben werden kann). Dieses wird zur Sessionsprotokolleinheit 205 des Antworters 103 verbreitet, der das Resultat über die Koordinationseinheit 204 zur FSM 203 forciert. An diesem Punkt sind alle Kommunikationspartner über einen gemeinsamen Satz von Codecs, Fähigkeiten, Adaptationspfaden und QoS-Zuständen übereingekommen und sind fähig, später die Referenzen (als Zustand-IDs bezeichnet) zu detektieren.
  • Die Annahme, die nun gemacht werden soll, ist, dass der Initiator 101 die tatsächliche Session, die einen einzelnen Videostrom umfasst, initiiert. Die Zustände und Adaptationspfade sind während der gerade beschriebenen Vorverhandlungsphase 106 verhandelt worden. Die QoS-Gewahrwerdungs-Anwendungseinheit 202 des Initiators 101 fordert einen Start des Stroms an, dem ein Strom-ID und sein gewünschtes Zustands-ID gegeben ist, von der lokalen Koordinatoreinheit 204 an, die zuerst lokale Zugangstests ausführt und die lokal die Ressourcen von den Lokalressourcenmanagementeinheiten 206 anfordernden Ressourcen reserviert. Wenn der gewünschte Zustand aufgrund eines Lokalressourcenproblems nicht erfüllt werden kann, würde die Koordinatoreinheit 204 die FSM-Maschine 203 auffordern, den nächsten QoS-Zustand, der entsprechend dem verhandelten Adaptationspfad niedrigere Ressourcenerfordernisse aufweist, zu versuchen. Nach einer erfolgreichen Lokalressourcenreservierung wird die Start-Anforderung zur lokalen Sessionsprotokolleinheit 205 propagiert, die zur Sessionsprotokolleinheit-205-Mitteilung des Peers, die auf SIP-Erweiterungen basieren kann, eine START-Mitteilung sendet. Diese Mitteilung umfasst das forcierte Zustands-ID und Strom-ID (die beide unter Benutzung von SDP-Erweiterungen modelliert werden können). Die Start-Mitteilung wird über die Koordinatoreinheit 204 des Peers zur FSM-Maschineneinheit 203 des Peers weitergegeben, die bezüglich eines gültigen Zustands-IDs prüft. Wenn dieses anerkannt ist, fordert die FSM-Maschineneinheit 203 Ressourcen zur Behandlung der Mediaströme unter Benutzung der Koordinationseinheit 204 und die von den Lokalressourcenmanagementeinheiten 206 bereitgestellten Dienste, die Zugangstests ausführen und die Ressourcen beim Peer reservieren, an.
  • Es sei darauf hingewiesen, dass, wenn die Ressourcen beim Peer nicht garantiert werden können, die Peerkoordinationseinheit 204 die FSM-Maschineneinheit 203 auffordert, ein neues Zustands-ID entsprechend dem vorverhandelten Adaptationspfad auszuwählen. Wenn alles anerkannt wird, fordert die Peer-Koordinationseinheit 204 die Peer-Sessionsprotokolleinheit 205 auf, zur Sessionsprotokolleinheit 205 des Initiators 101 mit dem neuen Zustands-ID eine START_ACK zu senden, die über die lokale Koordinationseinheit 204 zur lokalen FSM-Maschineneinheit 203 weitergegeben wird. Die lokale FSM-Maschineneinheit 203 prüft auf Kompatibilität der Zustände und sagt, wenn sie anerkannt werden, der lokalen Koordinationseinheit 204, eine Reservierung von Netzwerkressourcen (beispielsweise unter Benutzung eines RSVP) über die lokale Netzwerkressourcenreservierungseinheit 207 anzufordern. Wenn das Zustands-ID anders als das ursprünglich ausgewählte ist, instruiert sie die Lokalressourcenmanagementeinheiten 206, die lokale Ressourcenreservierung entsprechend dem neuen Zustands-ID zu aktualisieren (was in 2 nicht gezeigt ist, da wir angenommen haben dass alles gut war). Zusätzlich kann die Koordinationseinheit 204 die Sessionsprotokolleinheit 205 auffordern, eine RESERVE-Mitteilung zum Peer 103 zu senden, sollte dieser Peer reagieren, um die Netzwerkressourcenreservierung in den Zugriffsnetzwerken, an denen sie angebracht sind, zu managen [Marsh00]. In einem solchen Fall löst der Peer 103 beim Empfang der RESERVE-Mitteilung durch seine Sessionsprotokolleinheit 205 seine Koordinationseinheit 204 aus, um Netzwerkressourcen über die Netzwerkressourcenreservierungseinheit 207 des Peers (beispielsweise unter Benutzung eines RSVP) anzufordern. Wenn einmal Ressourcen auf Netzwerkebene reserviert worden sind, sendet die Koordinationseinheit 204 beim Peer 216 eine Bestätigung zum Sender unter Benutzung der CONFIRM-Mitteilung, die von der lokalen Sessionsprotokolleinheit 205 empfangen wird, zurück. Diese Einheit erzeugt eine Bestätigung für die lokale Koordinationseinheit 204. Wenn einmal der Initiator 101 alle Bestätigungen von allen Antwortern 103 gesammelt hat, gibt er die Rolle des Initiators 101 ab, und alles ist richtig eingestellt.
  • Zur Ausführung einer Konkurrenzsteuerung bzw. -kontrolle kann jeder, der eine Vorverhandlungsphase 106, eine Mehrstrom-QoS-Synchronisations- und -QoS-Korrelationsphase 107, eine Schnellverhandlungsphase 108 und/oder eine Neuverhandlungsphase 108 startet, die Rolle des Initiators 101 annehmen. Deshalb startet er mit dem Senden von Mitteilungen zu bekannten Peers, wobei er sie einlädt, an der gegebenen Phase teilzunehmen. Wenn keiner der anderen Peers als ein Initiators 101 agiert, agiert der sie realisierende Peer 216 als ein Initiator 101 und wartet auf eine Bestätigung einer Ressourcenreservierung (Aggregieren von Lokalem und Netzwerk) von den als Antworter 103 agierenden Peers. Wenn andernfalls einer der Peers 216 schon als Initiator 101 agiert, fügt dieser Initiator 101 den möglichen Peer 216 seiner Liste von Antwortern 103 hinzu, und der mögliche Peer 216 wartet darauf, vom Initiator 101 eingeladen zu werden.
  • Ist die gegebene Phase einmal vorüber, das heißt, hat der gegebene Initiator 101 alle Bestätigungen von allen Antwortern 103 einmal gesammelt, „gibt" der als Initiator agierende gegebene Peer die Rolle des Initiators „frei". In diesem Modus wird ein Tokenpassiermechanismus benutzt, bei dem die Akquisition des Token die Rolle des Initiators 101 garantiert und das Passieren ausgeführt wird, wenn eine Phase einmal vollendet ist. Auf diese Weise wird auch der Fall von Kollisionen durch Benutzung einer Master-Slave-Lösung, bei welcher der Master der Initiator 101 und der Slave der Antworter 103 ist, abgedeckt. Der Initiator 101 gibt dem Antworter 103 an, wann eine Netzwerkreservierung zu starten ist. In jedem Fall würde eine Netzwerkreservierung laufend zwischen Peers ausgeführt (mit Ausnahme des Falls eines QoS-Reservierungsignalisierungsprotokolls – ähnlich dem RSVP – wo End-to-End verfügbar ist).
  • Aspekte der vorliegenden Erfindung
  • Nun werden die von der vorliegenden Erfindung vorgeschlagenen unterschiedlichen Konzepte erläutert:
    • – Integration und Erweiterungen unterschiedlicher existierender Protokolle und Technologien bzw. Techniken zum Definieren des E2ENP (einschließlich E2ERP): Insbesondere umfasst dieser Aspekt die folgenden Phasen: Protokollentdeckung 104, Vorverhandlung 106, Mehrstrom-QoS-Synchronisation und -QoS-Korrelation 107, Schnellverhandlung (mit Ökonomieprinzip) 109, Ressourcenreservierungsfreigabe 110. Alle diese sechs Phasen können verkettet sein oder zu unterschiedlichen Zeitpunkten ausgeführt werden. Die Mehrstrom-QoS-Synchronisations und -QoS-Korrelations-107-Phase ist optional, insofern, als sie nur angefordert wird, wenn Peers 216 mit mehrfachen Sende/Empfangs-Strömen interagieren, die korreliert und synchronisiert werden müssen. Die Protokollentdeckungs-104- und Vorverhandlungs-106-Phasen können a priori ausgeführt werden, und die Resultate können dann bei mehreren sukzessiven Kommunikationssessionen angewendet werden, wobei jede Kommunikationssession mit einer speziellen Mehrstrom-QoS-Synchronisations- und -QoS-Korrelationphase 107 initiiert wird. Sollten auch Ergebnisse der letzteren Phase bei mehreren sukzessiven Kommunikationssessionen anwendbar sein, kann jede der Kommunikationssessionen mit einer speziellen Schnellverhandlungsphase 108 initiiert werden. Das Protokoll interagiert während Vorverhandlungs-106-, Mehrstrom-QoS-Synchronisations- und -QoS-Korrelations-107-, Schnellverhandlungs-108-, Neuverhandlungs-109- und Ressourcenfreigabe-110-Phasen mit den Lokalressourcenmanagementeinheiten 206.
    • – Ökonomieprinzip: Gemäß diesem Aspekt kann die Ressourcenzugangssteuerung und Ressourcenreservierung dieser Ordnung folgend angewendet werden: Beim E2ENP-Initiator 101 zuerst, dann bei dem oder den E2ENP-Anwortern 103 und schließlich beim 207 benutzenden Netzwerk. Bei den ersten zwei Schritten werden Ausgaben wie Echtzeit-CPU-Zeitsteuerung, Speichermanagement und Energiemanagement adressiert. Der gleiche Prozess gilt auch im Fall von Neuverhandlungen mit dem Unterschied, dass vorher zugeteilte lokale Ressourcen entweder unmittelbar oder später während der Ressourcenreservierungsfreigabe-110-Phase aktualisiert (entweder freigegeben oder neu zugeteilt) werden müssen. Für die Ressourcenreservierungsfreigabe-110-Phase werden zuerst Netzwerkressourcen, dann Peer und schließlich lokale Ressourcen freigegeben.
    • – Konzept des E2ERP: Gemäß diesem Aspekt kann während der Laufzeit einer so hergestellten Multimediasession zu jeder Zeit jede Komponente eine Adaptation anfordern. Dies erfordert wieder eine Koordinierung eines Lokal-, Peer- und Netzwerkressourcenmanagements entsprechend dem Ökonomieprinzip. Bei der Ausführung dieser Adaptation können Benutzer-definierte oder Benutzer-bereitgestellte Präferenzen implizit benutzt werden, um den Adaptationspfad zu bilden.
    • – Vorverhandlung des Typs von E2ENP: Diese kann während der Protokollentdeckungsphase 104 entweder durch Forcieren von Peers 101, 103, einen Verzeichnisserver 102 abzufragen, oder dadurch, dass letztere eine solche Information ankündigen, ausgeführt werden. Anstelle eines Verzeichnisservers kann auch ein SIP-Register-Server benutzt werden.
    • – Vorverhandlung von Fähigkeiten: Diese kann während der Vorverhandlungsphase 106 durch Benutzung eines speziellen Protokolls wie beispielsweise SIP/SDP plus Erweiterungen ausgeführt werden.
    • – Vorverhandlung einer kompletten Codecliste: Diese kann während der Vorverhandlungsphase 106 durch Benutzung eines speziellen Protokolls wie beispielsweise SIP/SDP plus Erweiterungen ausgeführt werden.
    • – Vorverhandlung von Adaptationspfaden auf Stromebene: Diese kann während der Vorverhandlungsphase 106 durch Benutzung eines speziellen Protokolls wie beispielsweise SIP/SDP plus Erweiterungen ausgeführt werden.
    • – Vorverhandlung von Adaptationspfaden auf Stromaggregationsebene: Diese kann während einer Multistrom-QoS-Synchronisations- und -QoS-Korrelations-107-Phase beispielsweise durch SIP/SDP plus Erweiterungen ausgeführt werden.
    • – Indexierung vorverhandelter QoS-Verträge und -Fähigkeiten: Zur Beschleunigung der Schnellverhandlungsphase 108.
    • – Indexierung vorverhandelter QoS-Verträge und -Fähigkeiten: Zur Beschleunigung der Neuverhandlungsphase 109.
    • – Modellierung des Datenmodells, beschrieben in EPA 00 126 975.2 , in einer erweiterten Version entweder von SDP oder SDPnG. Behandlung einer Installation/Desinstallation von Fähigkeiten auch bei Laufzeit durch Austauschen asynchroner Mitteilungen zwischen Peers zur Mitteilung solcher Ereignisse. Dies kann auf SIP/SDP plus Erweiterungen basiert sein.
    • – Unterstützung eines E2ENP-Brokers 105: Diese ist eine optionale Drittparteientität, die zum Befreien von Peers 101, 103 von der Ausführung einer Zeit- und Ressourcen raubenden Vorverhandlungsphase 106 (und eventuell auch der Multistrom-QoS-Synchronisation und -QoS-Korrealtion 107) benutzt werden. Jeder Peer 101, 103 kann nach Entdeckung von einem Verzeichnisserver 102, welcher E2ENP-Broker 105 zu kontaktieren ist, seinen Adaptationspfad und die Liste von zu kontaktierenden Peers zum E2ENP-Broker 105 hinaufladen. Der E2ENP-Broker 105 kann beispielsweise als eine verbesserte Version von Audio-/Videokonferenzbrücken oder durch Kombinieren eines verbesserten SIP-Proxyservers (oder SIP-Umadressierungsservers) – behandelt den Verhandlungsprozess – und einer verbesserten Version eines SIP-Registrators – speichert den Adaptationspfad und Fähigkeiten und alle ihre zwischenverhandelten Versionen – implementiert werden. Der E2ENP-Broker 105 sammelt auf diese Weise solche Information von jedem der Peers 101, 103 und führt den Verhandlungsprozess in seinem Speicherraum lokal aus. Während dieses Prozesses kann der E2ENP-Broker 105 eventuell einige der angezeigten Antworter 103 im Interesse des oder der Initiatoren 101 kontaktieren, sollten solche Antworter 103 ihre Information auf dem E2ENP-Broker 105 nicht gespeichert haben. Wenn einmal die Verhandlung erfolgreich ausgeführt worden ist, informiert der E2ENP-Broker 105 die Peers 101, 103 über die Verfügbarkeit der Resultate, und jeder Peer kann dann die Resultate herunterladen.
    • – Benutzung des E2ENP-Brokers 105, um mehrere Verhandlungsiterationen zu ermöglichen, die andernfalls zu teuer wären. Die Antworter 103 stimmen möglicherweise einem Angebot vom Initiator 101 nicht zu und machen deshalb Gegengebote. Die Analyse von Gegengeboten involviert mehrere Rundgangsmitteilungen zwischen Peers und ist deshalb zu zeitraubend. Der E2ENP-Broker 105 kann den gegebenen Prozess vermitteln und beschleunigen.
    • – Erweiterung von SIP und RTSP für eine Vorverhandlung 106 eines Adaptationspfads (auf Stromebene) von Fähigkeiten durch Huckepacknehmen dieser Information in den existierenden Mitteilungen des SIP oder RTSP.
    • – Erweiterung von SIP und RTSP zur Vorverhandlung eines Adaptationspfads auf Stromaggregationsebene 107 durch Huckepacknehmen dieser Information in den existierenden SIP oder RTSP-Mitteilungen (gemäß EPA 00 111 191.3 ).
    • – Protokollprozeduren und -mitteilungen zu einer Adressierung von Schnellverhandlungs-108- und Neuverhandlungs-109-Phasen (durch Benutzung der mit den vorverhandelten QoS-Verträgen des Adaptationspfads assoziierten Identifizierer).
    • – Erweiterung von SIP/SDP und RTSP durch Definieren von Mitteilungen für Adressierung: a. QoS-Vertragsverhandlung; b. Koordination von Netzwerkressourcenreservierung (wenn es eine gibt) zwischen Peers.
    • – Erweiterung von SIP und RTSP für Schnellverhandlung 108 durch Benutzung indexierter QoS-Verträge und -Fähigkeiten.
    • – Erweiterung von SIP und RTSP für Neuverhandlung 109 durch Benutzung indexierter QoS-Verträge und -Fähigkeiten.
    • – Koordinierung von Netzwerkressourcenreservierungsmechanismen zwischen Peers entsprechend dem Ökonomieprinzip durch Einführen erkannter Synchronisationsprozeduren in SIP und RTSP während Schnellverhandlungs-108- und Neuverhandlungs-109-Phasen.
    • – Erweiterung von SAP, um Verzeichnisservern 105 eine Ankündigung von benutzten Typen von End-to-End-QoS-Verhandlungsprotokollen zu ermöglichen.
    • – Erweiterung existierender Verzeichnisprotokolle oder von SIP in Bezug auf die Benutzung eines SIP-Registrators, um zur Ermöglichung der Protokollentdeckungsphase 104 benutzte Typen von End-to-End-QoS-Verhandlungsprotokolle zu speichern und/oder wiederzugewinnen.
    • – Erweiterung von SAP zum Ankündigen von Adaptationspfaden in Bezug auf Distributionsdienste, wobei ein AP einfach unterschiedliche Rundsendegruppen auflistet, deren jede auf einen speziellen QoS-Vertrag abzielt.
    • – Alle E2ENP-bezogenen Änderungen bei SIP können theoretisch ebensogut auf H.323 abgebildet werden.
    • – Management von Ressourcenreservierungsfreigabe 110
    • – Die Verhandlung und Neuverhandlung von Fähigkeiten – während, jeweils, der Schnellverhandlungsphase 108 (mit Ökonomieprinzip) und der Neuverhandlungsphase 109 (mit Ökonomieprinzip) – umfasst die Signalisierung, dass die Peers 216 sich miteinander austauschen müssen, um über die Wahl eines Audio- und/oder Videocodecs und dessen Konfiguration (Bitrate usw.) übereinzukommen.
  • Ausführungsform zur Implementierung der vorliegenden Erfindung:
  • Nun wird eine Ausführungsform zur Implementierung der vorliegenden Erfindung anhand der 2 erläutert:
    Jeder Peer 216 besteht aus einer Recheneinheit 201, die einen Protokollstapel 208 (beispielsweise IP und TCP/UDP) und eine Koordinationseinheit 204 aufweist. Die Koordinationseinheit 204 koordiniert:
    • 1. eine Protokollentdeckungsphase 104 durch eine Schnittstelle 214 mit einer Protokollentdeckungseinheit 213;
    • 2. eine Vorverhandlungsphase 106 und eine Multistrom-QoS-Synchronisation und -Korrelation 107 durch eine Schnittstelle 209 mit einer FSM-Maschineneinheit 203 und durch eine Schnittstelle 210 mit einer Sessionsprotokolleinheit 205;
    • 3. eine Schnellverhandlungsphase 108 durch eine Schnittstelle 211 mit Lokalressourcenmanagementeinheiten 206, durch eine Schnittstelle 210 mit einer Sessionsprotokolleinheit 205 und durch eine Schnittstelle 212 mit einer Netzwerkressourcenreservierungseinheit 207;
    • 4. eine Neuverhandlungsphase 109 durch eine Schnittstelle 209 mit einer FSM-Maschineneinheit 203 (zum Evaluieren alternativer QoS-Verträge durch Benutzung des Adaptationspfads), durch eine Schnittstelle 211 mit Lokalressourcenmanagementeinheiten 206, durch eine Schnittstelle 210 mit einer Sessionsprotokolleinheit 205 und durch eine Schnittstelle 212 mit einer Netzwerkressourcenreservierungseinheit 207;
    • 5. eine Freigabephase 110 durch eine Schnittstelle 211 mit Lokalressourcenmanagementeinheiten 206, durch eine Schnittstelle 210 mit einer Sessionsprotokolleinheit 205 und durch eine Schnittstelle 212 mit einer Netzwerkressourcenreservierungseinheit 207.
  • Eine FSM-Maschineneinheit 203 kann Teil einer gegebenen QoS-Gewahrwerdungs-Anwendungseinheit 202 sein oder kann eine separate Entität (Middleware) sein, die mehrfach gegebene QoS-Gewahrwerdungs-Anwendungsheiten 202 benutzen kann. Die FSM-Maschine-Einheit 203 ist ein Softwareprozess, der, nachdem er mit einem gegebenen Adaptationspfad konfiguriert worden ist, zur Implementierung der mit dem gegebenen Adaptationspfad assoziierten FSM im Interesse der QoS-Gewahrwerdungs-anwendungseinheit 202 in Kooperation mit der Koordinationseinheit 204 fähig ist.
  • Eine Protokollentdeckungseinheit 213 ermöglicht der Koordinationseinheit 204, einen Verzeichnisserver 215 (der möglicherweise auch als eine Erweiterung eines SIP-Registrators implementiert sein kann) zu kontaktieren, um die Protokollentdeckungsphase 104 auszuführen. Die Protokollentdeckungseinheit 213 erweitert die Benutzung existierender spezieller Protokolle (wie beispielsweise LDAP, SAP, SIP) durch Anzeigen und Abfragen von Information über ein E2ENP im Interesse der Koordinationseinheit 204.
  • Eine Sessionsprotokolleinheit 205 ermöglicht der Koordinationseinheit 204, die Phasen 106–110 mit Peers 216 auszuführen. Die Sessionsprotokolleinheit 205 erweitert laufende Protokolle wie SIP/SDP oder RTSP (oder auch H.323/H.235) durch Benutzung von SDP- oder SDPnG-Verbesserungen zur Beschreibung von Angeboten/Gegengeboten für einen Adaptationspfad und für Fähigkeiten und durch Einbringen von SIP- oder RTSP-spezifischen (oder auch H.323/H.245-spezifischen) Mitteilungen zur Implementierung der für die Phasen 106 bis 110, insbesondere für die Vorverhandlungsphase 106 und die Multistrom-QoS-Synchronisations- und -Korrelations-107-Phase (umfassend die Ressourcenkoordination gemäß dem Ökonomieprinzip) erforderlichen Signalisierung.
  • Schnittstellen 211 zu den Lokalressourcenmanagementeinheiten 206 werden in Bezug auf die folgenden Klassen von Ressourcen identifiziert:
    • – CPU-Ressourcen
    • – (primäre und sekundäre) Speicherressourcen
    • – Batterieenergie bzw. -Leistung
    • – Externe Hilfsressourcen
  • Für jede Klasse von Ressourcen werden spezielle Lokalressourcenmanagementeinheiten 206 beispielsweise als eine Erweiterung des auf die Recheneinrichtung 201 geladenen Betriebssystems verfügbar gemacht.
  • Die Schnittstelle 211 ermöglicht der Koordinationseinheit 204, die folgenden Aufgaben auszuführen:
    • – Monitorressourcenbenutzung entsprechend unterschiedlichen Kriterien (beispielsweise Pro-Strom- oder Pro-Prozessgeordert),
    • – Registrieren (und Entregistrieren) von zur Koordinationseinheit 204 weiterzuleitenden Mitteilungen, wenn einmal und/oder zu jeder Zeit eine gegebene Bedingung erfüllt ist,
    • – Reservieren (und Freigeben) einer gegebenen Menge von Ressourcen (beispielsweise durch Einstellen eines CPU-Grenztermins (CPU deadline) oder Festlegen eines Speicherbereichs oder eines gegebenen Prozesses),
    • – Aktualisieren einer gegebenen Reservierung (für den Neuverhandlungsfall),
    • – Assoziieren (und Entassoziieren) einer gegebenen Entität wie beispielsweise eines Prozesses mit einer Klasse von Lokalressourcenbenutzung (dieses wird typischerweise für die Ressourcen ausgeführt, die ohne OS-Überwachung nicht direkt ausgeführt werden können). Die Klasse ist eine Art von Priorität, die das OS zur Optimierung einer Ressourcenbenutzung entsprechend Grundsätzen des Benutzers benutzen kann.
  • Jeder Peer 216 kann die Rolle eines Initiators 101 annehmen, vorausgesetzt, dass alle anderen Peers in der Zwischenzeit nicht als Initiator 101 agieren. Die Rolle wird für die ganze Dauer jeder der folgenden Phasen aufrechterhalten:
    • – Vorverhandlung 106,
    • – Multistrom-QoS-Synchronisation und -QoS-Korrelation 107,
    • – Schnellverhandlung 108 (mit Ökonomieprinzip) und
    • – Neuverhandlung 109 (mit Ökonomieprinzip).
  • Während der Ressourcenfreigabephase 110 können gewisse der Peers, die nicht in den Sessionsabbauprozess involviert sind – und demnach die Session mit irgendeinem verbleibenden Peer fortsetzen wollen – auch die Rolle des Initiators 101 in einer laufenden Phase 107, 108 oder 109 annehmen.
  • Sollte ein Peer 216 (hernach der Peer A) versuchen, als ein Initiator 101 zu agieren und andere Peers 216 einladen, für eine der oben erwähnten Phasen als Antworter 103 zu agieren, während die Phase weitergeht, (das heißt während einer der anderen Peers 216 schon als ein Initiator 101 agiert), würde der Peer A darüber informiert, dass es notwendig ist, auf eine Einladung vom derzeit aktiven Initiator 101 zu warten, und der letztere müsste den Peer A zu seiner Liste von Antwortern 103 hinzufügen.
  • Das Ende irgendeiner der vorstehend erwähnten Phasen koinzidiert mit der Sammlung all der Bestätigungen von erfolgreich reservierten Netzwerkressourcen von allen Antwortern 103 auf der Initiator-101-Seite. Der Initiator 101 hat auch jede Bestätigung gegen all die anderen schon empfangenen zu validieren, um eventuell die Benutzung von Ressourcen zwischen Peers durch Vornehmen von Korrekturaktionen auszubalancieren.
  • Wenn einmal das Ende erreicht worden ist, drückt der als Initiator agierende Peer 216 in einen neutralen Zustand ein und gibt so die Rolle des Initiators 103 an irgendeinen möglichen Peer 216 frei. Die Rolle des Initiators 103 kann auf diese Weise als ein logisches Token (die Initiatorrolle Token (Initiator Role Token, IRT)) modelliert werden, das zwischen Peers ausgetauscht werden kann, wenn einmal irgendeine der vorstehend erwähnten Phasen vorüber ist.
  • Andere Peers 216 können sich an eine schon aktive Kommunikationssession zwischen mehreren Peers 216 anschließen. Ist es in diesen Fällen wirklich notwendig und/oder durchführbar, alles neu zu verhandeln? Ein Knackpunkt dieser Erfindung ist die Entkopplung der Vorverhandlungs-106-Phase von den tatsächlichen Multistrom-QoS-Synchronisations- und -QoS-Korrelations-107-, Schnellverhandlungs(mit Ökonomieprinzip)-108- und Neuverhandlungs(mit Ökonomieprinzip)-109-Phasen. Solange Peers 216 zur Sessionsankündigungszeit im Voraus darüber übereinkommen, welche QoS-Ebene zu benutzen ist, können sie sich jederzeit an eine aktive Session anschließen (oder diese verlassen), indem sie den bei dieser Erfindung beschriebenen schnellindexierten Verhandlungsprozess benutzen. Das Schlüsselproblem ist jedoch, wie sich mit Peers 216 befassen, die sich zu einer späteren Zeit an die Konferenz anschließen, ohne irgendetwas vorverhandelt zu haben. In diesem Fall stehen mehrere Optionen zur Verfügung:
    • 1. Vom Arbeitsbereich oder der Arbeitsdatei alles zwischen allen Peers 216 neu verhandeln – dies ist eine undurchführbare Lösung, nicht nur wegen der Dienstunterbrechung mit hoher Latenz, sondern auch weil diese Lösung Abhängigkeiten zwischen den zu beispielsweise einer Videokonferenzsession gehörenden Verbindungen forcieren würde, was in den meisten Fällen unrealistisch ist.
    • 2. Die neuen Peers 216 nötigen, die schon vorverhandelte Information zu akzeptieren: Wenn ein neuer Peer 216 dies nicht akzeptiert, kann er/sie sich nicht an die gegebene Session anschließen.
    • 3. Eine Mediaadaptation durch gewisse in das Netzwerk eingebettete Filter zu forcieren, um den anderen Präferenzen des neuen Peers 216 zu entsprechen. Mehr Details bezüglich dieses Konzepts können in [Pasqu92], [Pasqu93], [Yeado93], [Kassl99a] und [Kassl99b] gefunden werden.
  • Als eine Konklusion nimmt diese Erfindung an, dass entweder Lösung 2 oder 3 durch irgendeine Anwendung forciert wird, die diese Probleme behandeln kann (beispielsweise ein Konferenzsteuerungswerkzeug) und durch Benutzung der Dienste dieser Erfindung forciert wird. Dies bedeutet, dass die Lösungen 2 und 3 außerhalb des Rahmens dieser Erfindung sind.
  • Sollte der E2ENP-Broker 105 benutzt werden und/oder das verhandelte Vokabular im Verzeichnisserver 102 oder SIP-Registrator gespeichert sein, können neue Teilnehmer die vorverhandelte Information von solchen Entitäten vorteilhafter direkt bekommen und infolgedessen nur die Schnellverhandlung 108 (mit Ökonomieprinzip), Neuverhandlung 109 (mit Ökonomieprinzip) auslösen.
  • Das zeitlich asymmetrische Initiator-101/Antworter-103-Schema ist äquivalent zu einer Master/Slave-Konfiguration, bei welcher der Initiator 101 als ein Master agiert und jeder Antworter 103 als ein Slawe agiert.
  • Während einer der Vorverhandlungs-106-, Multistrom-QoS-Synchronisations- und -QoS-Korrelations-107-, Schnellverhandlungs(mit Ökonomieprinzip)-108- und Neuverhandlungs(mit Ökonomieprinzip)-109-Phasen ist es deshalb möglich, mögliche Konflikte, die von eine Phase unabhängig initiierenden Peers 216 entstehen, zu lösen.
  • Während der normalen Konversationsphase (das heißt nach der Schnellverhandlungs-108-Phase) können mehrere Peers 216 irgendeine QoS-Änderung/QoS-Verletzung gleichzeitig detektieren, und dies kann bei einer Anforderung, die Neuverhandlungs-109-Phase entsprechend zu starten, zu Kollisionen führen. Zu diesem Zweck soll der letzte Peer 216, der die Rolle des Initiators 101 annahm, wieder diese Rolle annehmen und die Anforderungen zwischen Peers entscheiden. Dies bedeutet, dass jeder Peer 216 die Identität des Peers 216, der zuletzt als Initiator 101 agierte, behalten soll.
  • Sollte jedoch als schlimmster Fall ein solcher Peer 216 in der Zwischenzeit die Kommunikationssession verlassen haben, wäre die Kollision unvermeidlich. In einem solchen Fall soll jeder Peer 216, der versucht, beim Empfang einer ähnlichen Anforderung von anderen Peers 216 das IRT zu „belegen", eine zufällige Zeit lang blockieren und neu versuchen, wenn eine solche Zeit verstrichen ist. Wenn während dieser Zeit ein anderer Peer 216 eine Anforderung zum Belegen des IRT gesendet hat, würde der bezüglich des Zeitgebers suspendierte Peer 216 entsprechend informiert, und folglich soll er sowohl den Zeitgeber als auch seine Anforderung zum Belegen des IRT abbrechen und folglich die Rolle des Antworters 103 annehmen.
  • In 5 ist ein Beispiel zu Implementierung des E2ENP-Broker-Konzepts gezeigt, bei dem, wie schon erwähnt, das Sessionsinitiationsprotokoll (SIP) bei anderen Teilen dieser Anwendung angewendet ist. Mit SIP-Registratoren 503 sind SIP-Proxiserver und/oder SIP-Umadressierungsserver 501 verbunden. Diese Erfindung schlägt vor, die in den von den SIP-Registratoren 503 durch Inkludieren der bei dieser Erfindung beschriebenen QoS-Spezifikations- und -Fähgikeiteninformation 506 benutzten Datenbanken 504 gespeicherte Ortsinformation 505 zu erhöhen. Ebenso die verhandelte QoS-Information 507 (sowohl die zeitlichen Resultate, die während Verhandlungs-/Neuverhandlungsphasen gezogen werden, als auch die, über die schließlich übereingekommen wird). Immer wenn sie mit dem SIP-Registrator 503 registrieren, können Benutzer so die Information 506 und 507 hinaufladen. Der E2ENP-Broker 502 ist eine Einheit, die über eine spezielle Schnittstelle 508 mittels wohlbekannter Mechanismen (beispielsweise ein JAIN SIP-Servlet API) mit den SIP-Proxyservern und/oder SIP-Umadressierungsservern 501 kommunizieren kann: Immer wenn ein als eine SIP-Erweiterung implementiertes E2ENP-Protokoll benutzt wird, führt der E2ENP-Broker 502 die bei dieser Erfindung beschriebenen Verhandlungs- und Neuverhandlungsphasen in seinem Speicherraum im Interesse aller Peers durch Benutzung der in der Datenbank des Registrators gespeicherten, vorstehend erwähnten Information aus. Der E2ENP-Broker 502 kommuniziert mit dem SIP-Registrator 503 über die Schnittstelle 509. Die vorteilhaften Hauptunterschiede zwischen der Erfindung und dem Stand der Technik
    Techniken (Technologies) Kommentar
    [Bor00] Der hier vorgeschlagene Mechanismus zum Managen eines Konferenzzustandes während Sessionen und Finden geeigneter Konfigurationen durch Verhandeln von Konfigurationen und Ändern derselben basieren auf diesem Stand der Technik. Diese Erfindung integriert dieses Konzept mit Lokal-, Peer- und Netzwerkressourcenreservierung entsprechend dem Ökonomieprinzip. Die Erfindung bringt zusätzliche Adaptationspfade und QoS-Verträge ein und referenziert diese unter Benutzung von Handhabungen. Auch inkludiert diese Erfindung Endgerätfähigkeiten- und Netzwerkressourcenreservierungsunterstützung in die Verhandlungsmechanismen.
    [Burn00], [Kassl00] und [Kassl00a] Der hier vorgeschlagene Mechanismus zum Integrieren eines Lokal- und Fern- sowie Netzwerkressourcenmanagements in ein Rahmen basiert auf diesem Stand der Technik. Zusätzlich definiert diese Erfindung das Protokoll, das zur Verhandlung von Fähigkeiten, Präferenzen und QoS-Zuständen notwendig ist, und identifiziert auch unterschiedliche Versionen des Protokolls unter Benutzung einer Verzeichnisserverlösung oder eines SIP-Registrators.
    [Nahr95] Das hier vorgeschlagene Ökonomieprinzip basiert auf diesem Stand der Technik. Diese Erfindung integriert dieses Konzept mit existierenden Internetprotokollen, inkludiert Adaptationspfade und Indexe und zieht andere Ressourcen wie Batterieenergie bzw. -leistung oder Drahtlosnetzwerkverfügbarkeit in Betracht. Diese Erfindung erweitert die Arbeit durch zuerst Vorverhandeln mehrerer Kandidaten-QoS-Verträge und -Konfigurationen und baut so ein gemeinsames Vokabular auf.
    [RFC2533] zusammen mit [CONNEG00] [CONNEG00a] oder [SDPCN01] Der hier vorgeschlagene Mechanismus zur Darstellung von Mediabehandlungsfähigkeiten, Ausdrücken von Mediamerkmalsätzen und Anpassungsmerkmalsätzen (vergleiche das Angebot mit den lokalen Fähigkeiten) basiert auf diesem Stand der Technik. Diese Erfindung integriert dieses Konzept mit existierenden Internetprotokollen, inkludiert Adaptationspfade und integriert Lokal- sowie Netzwerk- und Peerressourcenreservierung. Diese Erfindung erweitert die Arbeit durch zuerst Vorverhandeln mehrerer Kandidaten-QoS-Verträge und -Konfigurationen und baut so ein gemeinsames Vokabular auf.
    [RFC2703] Der hier vorgeschlagene Mechanismus zur Protokoll-unabhängigen Verhandlung von QoS-Verträgen und -Fähigkeiten basiert auf diesem Stand der Technik. Diese Erfindung verhandelt jedoch QoS-Verträge, Adaptationspfade und Fähigkeiten anstelle eines Inhalts wie in [RFC2703]. Diese Erfindung integriert auch dieses Konzept mit existierenden Internetprotokollen, inkludiert Adaptationspfade und integriert Lokal- sowie Netzwerkressourcenreservierung. Diese Erfindung erweitert die Arbeit durch zuerst Vorverhandeln mehrerer Kandidaten-QoS-Verträge und -Konfigurationen und baut so ein gemeinsames Vokabular auf.
    [SDPNG00] zusammen mit [SDPCN00], [Ott99], [Beser00] Der bei dieser Erfindung vorgeschlagenen Mechanismus zum Ausführen einer Endpunktfähigkeitsverhandlung und Inkludieren von Benutzerpräferenzen und Netzwerkressourcenreservierung basiert auf diesem Stand der Technik. [SDPCN00] fügt SDP-Erweiterungen nur für Fähigkeitsverhandlung hinzu. [Ott99] stellt nur eine Notation für Konfigurationsbeschreibung bereit. [Beser00] stellt nur für Endpunkte zum Verhandeln von Codecs notwendige SDP-Erweiterungen bereit. Diese Erfindung fügt das Verhandlungsprotokoll zum Bestimmen eines gemeinsamen Satzes von Konfiguration hinzu und integriert Lokal-, Peer- und Netzwerkressourcenreservierung durch Beachtung des Ökonomieprinzips. Außerdem integriert die Erfindung den Prozess eines Referenzierens von Konfigurationen durch Handhabungen und baut auf QoS-Verträge. Auch verhandelt diese Erfindung nicht nur Codecs, sondern auch Endgerätfähigkeiten und Netzwerkressourcenreservierungsmechanismen.
    [SIPRES01] zusammen mit [Cama00], [Cama00a] Die hier vorgeschlagene Erfindung basiert auf der Integration von SIP/SDP mit Netzwerkressourcenreservierung als eine Vorbedingung. Diese Erfindung erweitert die Arbeit durch zuerst Vorverhandeln mehrerer Kandidaten-QoS-Verträge und -Konfigurationen und baut so ein gemeinsames Vokabular auf. Auch wird später nur auf Referenzen bezüglich Konfiguration/den QoS-Vertrag hingewiesen. Außerdem integriert diese Erfindung Lokal- und Peerressourcenmanagement mit dem durch diesen Stand der Technik bereitgestellten Konzept durch Beachtung des Ökonomieprinzips. Dieser Stand der Technik deckt nur Eins-zu-Eins-Kommunikation mit Ressourcenreservierung ab und deckt nicht das Verbinden von während angehender Sessionen ausgeführter Operationen mit Verhandlungen ab.
    [Levin01] Die hier vorgeschlagene Erfindung erfüllt viele der in diesem Stand der Technik dargelegten Erfordernisse. Außerdem stellt diese Erfindung die Protokolle und die Mechanismen zum Integrieren von Lokal-, Fern- und Netzwerkressourcenmanagement in ein kohärentes Rahmen unter Beachtung des Ökonomieprinzips bereit. [Levin01] stellt nur Erfordernisse und kein Protokoll oder Mechanismen zum Forcieren der Erfordernisse bereit.
  • Anhang
    • [Beser00] B. Beser, Codec Capabilities Attribute for SDP, IETF Internet-Draft, Work-in-progress, <draft-beser-mmusic-capabilities-00.txt>.
    • [Bhatt99] S. Bhatti, G. Knight, Enabling QoS adaptation decisions for Internet applications, London, UK, 1999.
    • [Blake98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Services, IETF Request for Comments: 2475, December 1998.
    • [Booch99] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison Wesley Longman, 1999.
    • [Bor00] C. Bormann et. al., Simple Conference Control Protocol, IETF Internet-Draft, Work-in-progress, <draft-ietf-mmusic-sccp-01.txt>.
    • [Burn00] L. Burness et al., The BRAIN Quality of Service Architecture for Adaptable Services with Mobility Support, in Proceedings of the PIMRC 2000, London, 2000.
    • [Cama00] G. Camarillo, Confirmation of SDP preconditions, IETF Internet Draft, Work-in-progress, <draft-camarillo-manyfolks-confirm-02.txt>.
    • [Cama00a] G. Camarillo, Third party call control with SDP preconditions, IETF Internet Draft, Work-in-progress, <draft-camarillo-3pcc-qos-00.txt>.
    • [Conneg00] G. Klyne (ed.), A revided media feature set matching algorithm, IETF media feature registration WG, Work-in-progress, <draft-klyne-conneg-feature-match-02.txt>.
    • [Conneg00a] G. Klyne (ed.), Identifying composite media features, IETF conneg working group, Work-in-progress, <draft-ietf-conneg-feature-hash-05.txt>.
    • [Frolu98] S. Frolund, J. Koistinien, QML: A Language for Quality of Service Specification, HP-Lab Technical Reports, HPL-98-10, 980210.
    • [Hand198] M. Handley, V. Jacobson, SDP: Session Description Protocol, IETF Request for Comments: 2327, April 1998.
    • [Hand199] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, SIP: Session Initiation Protocol, IETF Request for Comments: 2543, March 1999.
    • [Hand100] M. Handley, C. Perkins, E. Whelan, Session Announcement Protocol, IETF Request for Comments: 2974, October 2000.
    • [ISOX641] ITU-T Recommendation X.641 (12/97)|ISO/IEC 13236: 1998, Information technology – Quality of Service: Framework.
    • [Kass199a] A. Kassler, P. Schulthess, An End-to-End Quality of Service Management Architecture for Wireless ATM networks, in: Proceedings of the HICSS 32, Mauii, Hawaii, USA, January 1999.
    • [Kass199b] A. Kassler, P. Schulthess, Extending the QoS Paradigm of Wireless ATM to Mobile Broadband Applications and to the User, in: Proceedings of the WCNC '99, September 1999, New Orleans, USA.
    • [Kass100] A. Kassler et al., BRENTA – Supporting Mobility and Quality of Service for Adaptable Multimedia Communication, in Proceedings of the IST Mobile Communication Summit 2000, Galway, Ireland, October 2000, pp. 403–408.
    • [Kass100a] A. Kassler et al., An Open Endsystem Architecture for Adaptable Multimedia Services with QoS Support, in Proceedings of the BRAIN workshop, London, 2000.
    • [Levin01] O. Levin, SIP Requirements for support of Multimedia and Video, IETF Internet-Draft, Work-in-progress, <draft-levin-sip-for-video-00.txt>
    • [Manda00a] D. Mandato, A universal QoS adaptation framework for mobile multimedia applications, European Patent Applications 00 111 191.3 , May 24, 2000.
    • [Manda00b] D. Mandato et al., High-Level interface for QoS-based mobile multimedia applications, European Patent Application 00 126 975.2 , December 8, 2000.
    • [Marsh00] W. Marshall et al., SIP Extension for Resource Management, IETF draft <draft-ietf-sip-manyfolks-resource-00>, November 2000.
    • [Nahr95] K. Nahrstedt and J. M. Smith, The QoS Broker, IEEE Multimedia Magazine, Spring 1995 (2)1, pp. 53–67
    • [Ott99] J. Ott et. al., Capability desciption for group cooperation, IETF Internet-Draft, Work-in-progress, <draft-ott-mmusic-cap-00.txt>.
    • [Pan99] P. Pan, H. Schulzrinne, YESSIR: A Simple Reservation Mechanism for the Internet, Computer Communications Review (CCR), Vol. 29, No. 2, pp. 89–101, April 1999.
    • [Pasqu92] J. Pasquale, G. Polyzos, E. Anderson, V. Kompella, The Multimedia Multicast Channel, Proc. of 3rd International Workshop an Network and Operating System Support for Digital Audio and Video (NOSSDAV 92), San Diego, California, November 1992, pp. 185–192.
    • [Pasqu93] J. Pasquale et al., Filter Propagation in Dissemination Trees: Trading Off Bandwidth and Processing in Continuous Media Networks, Proc. of NOSSDAV 93, Lancaster University, Lancaster, UK, 1993, pp. 269–278.
    • [RFC2533] RFC 2533, A Syntax for Describing Media Feature Sets, Graham Klyne, 5GM/Content Technologies, March 1999.
    • [RFC2703] RFC 2703, Protocol-independent Content Negotiation Framework, Graham Klyne, 5GM/Content Technologies, September 1999.
    • [SIPRES01] W. Marshall et. al., Integration of Resource Management and SIP – SIP Extension for Resource Management, IETF SIP working group, Work-in-progress, <draft-ietf-sip-manyfolks-reource-01.txt>.
    • [SDPCN00] F. Andreasen, SDP Simple Capability Negotiation, IETF MMUSIC working group, Work-in-progress, <draft-andreasen-mmusic-sdp-simcap-00.txt>.
    • [SDPCN01] F. Andreasen, SDP Simple Capability Negotiation Requirements, IETF MMUSIC working group, Work-in-progress, <draft-andreasen-mmusic-sdp-simcap-reqts-00.txt>.
    • [SDPNG00] D. Kutscher et. al., Requirements for Session Description and Capability Negotiation, IETF Internet-Draft, Work-in-progress, <draft-kutscher-mmusic-sdpng-req-01.txt>.
    • [Shulz98] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol (RTSP)", IETF Request for Comments: 2326, April 1998.
    • [SIPRES01] W. Marshall et. al., Integration of Resource Management and SIP – SIP Extensions for Resource Management, IETF SIP working group, Work-in-progress, <draft-ietf-sip-manyfolks-resource-01.txt>.
    • [SMIL98] Synchronized Multimedia Integration Language (SMIL) 1.0 Specification, W3C Recommendation, 15-June-1998.
    • [Yeado93] N. Yeadon, F. Garcia, D. Hutchinson, D. Shepherd, Filters: QoS Support Mechanisms for Multipeer Communications, IEEE Journal an Selected Areas in Communications, Vol. 14, No., 7, September 1993.

Claims (23)

  1. Verfahren zum Austauschen von Mediaströmen zwischen Peers eines Netzwerks, wobei das Verfahren die folgenden Schritte aufweist: – Vorverhandeln (106) eines gemeinsamen Satzes mehrerer indexierter Quality-of-Service-Veträge (QoS-Vertrage) und Endgerätfähigkeiten zwischen Peers, bevor Ströme ausgetauscht werden, wobei ein Initiator-Peer eine erste indexierte Liste von QoS-Verträgen und Endgerätfähigkeiten zu wenigstens einem Antworter-Peer weiterleitet und der wenigstens eine Antworter-Peer eine gemeinsame Teilmenge der empfangenen ersten Liste und seine eigenen QoS-Verträge und Endgerätfähigkeiten erzeugt und die gemeinsame Teilmenge zum Initiator-Peer weiterleitet, und – Verhandeln (108) von QoS-Verträgen auf einer die vorverhandelten QoS-Verträge und Endgerätfähigkeiten benutzenden Pro-Strom-Basis zum Zeitpunkt der Stromherstellung, wobei im Fall einer Neuverhandlung (109) während eines Strömens einer der Peers (216) den Index eines der indexierten vorverhandelten QoS-Verträge und Endgerätfähigkeiten zu den anderen Peers signalisiert.
  2. Verfahren nach Anspruch 1, mit dem Schritt einer Verhandlung (108) von Quality-of-Service-Korrelations- und -Synchronisationsaspekten zwischen mehreren Strömen zwischen mehreren Peers.
  3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Peers (216) während des Vorverhandlungsschritts (106) auf der feinsten Auflösungsebene Mengen von Quality-of-Service- Verträgen auf einer Pro-Strom-Basis und/oder einer Pro-Stromassoziations-Basis verhandeln, wobei Stromassoziationen Bündel von Strömen von einem Sender-Peer zu einem Empfänger-Peer sind.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Peers (216) über Änderungen in der Fähigkeitskonfiguration informiert werden.
  5. Verfahren nach einem der vorhergehenden Ansprüche, wobei vorverhandelte alternative Qualitäts- und Konfigurationsinformation eines gegebenen Typs von Strom schon bei einem Server für Clients zum Auswählen verfügbar sind.
  6. Verfahren nach einem der vorhergehenden Ansprüche, mit den Schritten einer Protokollentdeckung (104), Vorverhandlung (106), optionalen Mehrstrom-QoS-Synchronisation und -QoS-Korrelation (107), Schnellverhandlung, Neuverhandlung (109) und Ressourcenreservierungsfreigabe (110).
  7. Verfahren nach Anspruch 6, wobei alle Phasen konzentriert werden und entweder kontinuierlich oder zu unterschiedlichen Zeiten ausgeführt werden können.
  8. Verfahren nach Anspruch 7, wobei die Mehrstrom-QoS-Synchronisations- und -QoS-Korrelationsphase (107) optional und nur erforderlich ist, wenn ein Initiator (101) durch Benutzung mehrerer Ströme, die auf Basis von nur auf der Initiatorseite (101) zu forcierenden Benutzergrundsätzen korreliert und synchronisiert werden müssen, mit mehreren Peers (216) kommuniziert.
  9. Verfahren nach Anspruch 8, wobei die Protokollentdeckungs- (105) und Vorverhandlungsphase (106) a priori ausgeführt werden und die Resultate dann bei mehreren sukzessiven Kommunikationssessionen angewendet werden können, wobei jede Kommunikationssession mit einer speziellen optionalen Mehrstrom-QoS-Synchronisations- und -QoS-Korrelationsphase (107) initiiert wird.
  10. Verfahren nach Anspruch 9, wobei, wenn die Resultate der Mehrstrom-QoS-Synchronisations- und -QoS-Korrelationsphase auf mehrere sukzessive Kommunikationssessionen anwendbar sind, jede der Kommunikationssessionen mit einer speziellen Schnellverhandlungsphase (108) initiiert werden kann.
  11. Verfahren nach einem der Ansprüche 6 bis 10, wobei das Protokoll während der Vorverhandlungs- (106), Mehrstrom-QoS-Synchronisations- und -QoS-Korrelations- (107), Schnellverhandlungs- (108), Neuverhandlungs- (109) und Ressourcenfreigabephase (110) mit Lokalressourcenverwaltungseinheiten (206) interagiert.
  12. Verfahren nach einem der Ansprüche 6 bis 11, gekennzeichnet durch eine Ressourcen-Zugangssteuerung und Ressourcenreservierung, die entsprechend der folgenden Ordnung angewendet werden: zuerst beim Initiator (101), dann bei dem oder den Antwortern (103) und schließlich zur Netzwerkbenutzung (207).
  13. Verfahren nach Anspruch 12, wobei bei den ersten zwei Schritten Lokalressourcenverwaltungsaufgaben wie Echtzeit-CPU-Zeitsteuerung, Speicherverwaltung und Energieverwaltung adressiert werden.
  14. Verfahren nach einem der Ansprüche 6 bis 13, wobei für die Ressourcenfreigabe (110) zuerst Netzwerkressourcen, dann Peer- (216) und schließlich lokale Ressourcen freigegeben werden.
  15. Verfahren nach einem der Ansprüche 6 bis 14, wobei während der Laufzeit einer so hergestellten Multimediasession zu jeder Zeit irgendeine Komponente irgendeines Peers (216) eine Adaptation anfordern kann und auf diese Weise eventuell eine Neuverhandlungsphase (109) auslösen kann.
  16. Verfahren nach einem der Ansprüche 6 bis 15, mit dem Schritt einer Vorverhandlung des Typs E2ENP während der Protokollentdeckungsphase (104), entweder durch Zwingen von Peers (101, 103), einen Verzeichnisserver (102), der als ein SIP-Registrar implementiert sein kann, zu fragen, oder dadurch, dass die Peers eine solche Information ankündigen.
  17. Verfahren nach einem der Ansprüche 6 bis 16, mit dem Schritt einer Vorverhandlung einer vollständigen Codec-Liste während der Vorverhandlungsphase (106).
  18. Verfahren nach einem der Ansprüche 6 bis 17, mit dem Schritt einer Vorverhandlung von Adaptationspfaden auf Stromebene während der Vorverhandlungsphase (106).
  19. Verfahren nach einem der Ansprüche 6 bis 19, mit dem Schritt einer Vorverhandlung von Adaptationspfaden auf Stromaggregationsebene während einer Mehrstrom-QoS-Synchronisations- und -QoS-Korrelationsphase (107).
  20. Verfahren nach einem der Ansprüche 6 bis 19, gekennzeichnet durch den Schritt einer Indexierung vorverhandelter QoS-Verträge und Fähigkeiten zur Beschleunigung der Schnellverhandlungsphase (108).
  21. Verfahren nach einem der Ansprüche 6 bis 20, gekennzeichnet durch den Schritt einer Indexierung vorverhandelter QoS-Verträge und Fähigkeiten zur Beschleunigung der Neuverhandlungsphase (109).
  22. Verfahren nach einem der Ansprüche 6 bis 21, gekennzeichnet durch den Schritt einer Bearbeitung einer Installation/Deinstallation von Fähigkeiten selbst bei Laufzeit durch Austauschen asynchroner Mitteilungen zwischen Peers zum Informieren über solche Ereignisse.
  23. Computerprogramm mit Instruktionen, die, wenn von einer Recheneinrichtung ausgeführt, die Recheneinrichtung veranlassen, ein Verfahren nach einem der vorhergehenden Ansprüche auszuführen.
DE2001631139 2001-03-27 2001-09-19 Verfahren, um End-to-End Quality von Service-Verhandlungen für verteilte Multimedia Anwendungen zu erzielen Expired - Fee Related DE60131139T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP01107626 2001-03-27
EP01107626 2001-03-27

Publications (2)

Publication Number Publication Date
DE60131139D1 DE60131139D1 (de) 2007-12-13
DE60131139T2 true DE60131139T2 (de) 2008-11-27

Family

ID=38664053

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2001631139 Expired - Fee Related DE60131139T2 (de) 2001-03-27 2001-09-19 Verfahren, um End-to-End Quality von Service-Verhandlungen für verteilte Multimedia Anwendungen zu erzielen

Country Status (1)

Country Link
DE (1) DE60131139T2 (de)

Also Published As

Publication number Publication date
DE60131139D1 (de) 2007-12-13

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)
EP1248431B1 (de) Verfahren um End-to-End Quality of Service Verhandlungen für verteilte Multimedia Anwendungen zu erzielen
DE602004005842T2 (de) Skalierbare und adaptive QoS-Architektur für Mehrkanal Multicast/Broadcast Dienste
DE60104532T2 (de) Proxy-vorrichtung und -verfahren
DE60132387T2 (de) Richtlinien-Koordination in einem Kommunikationsnetz
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE112013001313B4 (de) Ermitteln und Übergehen zu einer verbesserten VOIP-Sitzung
DE60210240T2 (de) Weiterreichen zwischen Mobilfunknetzwerken unterschiedlicher Technologien
DE60036912T2 (de) System und Verfahren zur Bandbreite-Basierte Codec-Auswahl
DE60211881T2 (de) Bindungsinformation für ip mediendatenströmen
JP5244957B2 (ja) 複数のベアラからなるマルチキャストサービスまたはブロードキャストサービスを受信する移動端末およびその方法
DE60036295T2 (de) Schnittstelle auf hoher Ebene für dienstqualitätbasierte mobile Multimedia-Anwendungen
DE102012214245B4 (de) Multistream-Datenübertragung
DE60202763T2 (de) Verfahren, Rechnerprogramm, Kundenendgerät und Netzwerk für die effiziente Benutzung von Netzwerkmittel durch die &#34;just-in-time&#34; Anpassung des Dienstqualitätes basiert auf die Benutzung des Dienstes und das Verhalten des Benutzers
DE112006001922T5 (de) Verfahren und Vorrichtung zur Vergabe von Zugangsberechtigungen (&#34;Floor-Control&#34;) in einem Kommunikationssystem
DE102005036298B3 (de) Verfahren und Kommunikationssystem zur Auswahl eines Übertragungsmodus&#39; für eine Übermittlung von Nutzdaten
DE69917925T2 (de) Steuerung einer angekündigten sitzung
DE60223604T2 (de) Verfahren, Einrichtung, Computerprogrammprodukt und System zur Worterteilung und Sitzungkontrolle
EP2837154A1 (de) Verfahren zur steuerung von datenströmen einer virtuellen sitzung mit mehreren teilnehmern, kollaborationsserver, computerprogramm, computerprogrammprodukt und digitales speichermedium
CN101641917A (zh) 网络资源协商
CN102365850A (zh) 用于提供相关服务级别的方法和装置
DE102012001394A1 (de) Gemeinsamer Medienzugang für Echtzeit-Erst- und Drittparteisteuerung
DE60212988T2 (de) Verfahren, Einrichtung und Computerprogramm zur Auswahl einer Medienübergangskontrollfunktion basierend auf der Überwachung von Resourcen von Medienübergangsfunktionen
EP2938047A1 (de) Verfahren, vorrichtung, computerprogramm, softwareprodukt und digitales speichermedium zur übermittlung und adaption von daten
EP1415437A1 (de) Kennzeichnung der dienstgüte einer informationsübermittlung in einem kommunikationsnetz

Legal Events

Date Code Title Description
8381 Inventor (new situation)

Inventor name: MANDATO, DAVIDE, 70327 STUTTGART, DE

Inventor name: KASSLER, ANDREAS DEPT. OF DIS, 89069 ULM, DE

8381 Inventor (new situation)

Inventor name: MANDATO, DAVIDE, 70327 STUTTGART, DE

Inventor name: KASSLER, ANDREAS, 89081 ULM, DE

8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee