DE69635252T2

DE69635252T2 - System und Verfahren mit wiederverhandelten Bitrateservice

Info

Publication number: DE69635252T2
Application number: DE69635252T
Authority: DE
Inventors: Matthias Sophia-Antipolis Grossglauser; Srinivasan Berkeley Heights Keshav; David New Providence Tse
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1995-04-19
Filing date: 1996-04-10
Publication date: 2006-07-06
Anticipated expiration: 2016-04-11
Also published as: JPH08298512A; CA2172318A1; EP0739114A3; CA2172318C; US5604731A; EP0739114B1; DE69635252D1; EP0739114A2; JP3012899B2

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft die Bereitstellung eines Mehrbenutzer-Zugangs-Bitratendienstes in einem nichtexklusiven Übertragungsnetzwerk.
Allgemeiner Stand der Technik
Mit dem Aufkommen von Multimedia-Daten- und Unterhaltungsdienst und der immer weiter zunehmenden Popularität des Internet wird die Wichtigkeit diensteintegrierter Telekommunikationsnetze („ISNs") in der zukünftigen Kommunikationsinfrastruktur schnell offensichtlich. Derzeitige Entwürfe für ISNs ermöglichen in der Regel drei Arten von Diensten: konstante Bitrate („CBR"), variable Bitrate („VBR") und verfügbare Bitrate („ABR"). Derzeitige ISN-Entwürfe ermöglichen CBR-Dienst, der mit existierenden leitungsvermittelten Telekommunikationsnetzen kompatibel ist. Ähnlich wird der ABR-Dienst für Kompatibilität mit dem Internet und Datentransfer-Anwendungen im Internet-Stil ausgelegt. Entwurfsbetrachtungen in Bezug auf VBR wurden durch Betrachtungen für zukünftigen Telekommunikationsverkehr vorgeschrieben, wobei die Übertragung komprimierter Videoinformationen besonders betont wird. Diese Art von Videoinformationen ist im allgemeinen durch eine intrinsische langfristig gemittelte Datenrate gekennzeichnet, die durch Perioden von Spitzenratendatenbursts punktiert wird. Um die Übertragung von solchem burst-artigem Verkehr über ein Standard-CBR-Dienstnetzwerk zu erleichtern, müßte jeder Datenburst über Pufferung vor dem Eintritt in das Netzwerk geglättet oder reduziert werden (wodurch unannehmbare Verzögerungen für Echtzeit-Videosignale verursacht werden), oder die CBR-Rate müßte auf einen bestimmten Wert gesetzt werden, der der Spitzendatenrate der gesendeten Videoinformationen sehr nahe kommt (wodurch Netzwerkbetriebsmittel vergeudet werden und dadurch das Multiplexen von Signalen in dem Netzwerk stark begrenzt wird). Wenn solche burst-artigen Videoinformationen über ein ABR-Dienst-Netzwerk übertragen werden, besteht ähnlich keine Garantie, daß die „verfügbaren" Netzwerkbetriebsmittel ausreichen, um unannehmbare Datenverzögerungen und/oder -verluste zu vermeiden. Derzeitige Entwürfe für VBR-Netzwerkdienste, wie zum Beispiel die von A. E. Eckberg in B-ISDB/ATM Traffic and Congestion Control, IEEE Network, September 1992, Seiten 28–37, besprochenen, ergänzen im wesentlichen den Standard-CBR-Dienst mit der Fähigkeit, mit mäßigen Datenbursts fertigzuwerden.
Um sicherzustellen, daß burst-artige Datenübertragungen ohne unannehmbare Datenverzögerungen und/oder -verluste durch ein VBR-Netzwerk geführt werden können, ist es wesentlich, daß das VBR-Netzwerk mit einer genauen Charakterisierung der zu sendenden Daten ausgestattet wird. Diese Charakterisierung wird über zusammen mit den Daten übertragene Verkehrsdeskriptoren zu einem VBR-Netzwerk übermittelt. Um Datenübertragungseffizienz innerhalb eines VBR-Netzwerks aufrechtzuerhalten, ist es wünschenswert, eine genaue Charakterisierung des gesendeten Verkehrs unter Verwendung von so wenig Verkehrsdeskriptoren wie möglich bereitzustellen. In der Praxis hat sich dies als schwierig erwiesen – besonders wenn es sich bei den gesendeten Daten um komprimiertes Video handelt.
Komprimierte Videodaten entsprechen einfach nicht dem von den Entwicklern von VBR-Dienst-Netzwerken in betracht gezogenen „mäßig burst-artigem" Verkehrsmodell. Wie in der Technik wohlbekannt ist, enthalten komprimierte Videodaten in der Regel relativ lange Intervalle (in der Größenordnung von einigen 10 Sekunden), in denen die Datenrate nahezu der betrachteten Spitzenrate für ein typisches VBR-Modell beträgt (siehe E. P. Rathgeb, Policing of Realistic VBR Video Traffic in an ATM Network, International Journal of Digital and Analog Communications Systems, Bd. 6, Seiten 213–226, 1993; M. W. Garrett und W. Willinger, Analysis Modeling and Generation of Self-Similar VBR Video Traffic, ACM Sigcomm '94, Seiten 269–280, University College London, August 1994). Diese längeren hochratigen Datenbursts sind auf Szenen zurückzuführen, die viel Bewegung und/oder sich schnell ändernde Lichtpegel abbilden. Wenn für solchen Verkehr ein Verkehrsdeskriptor des Leaky-Bucket-Typs verwendet wird, sieht man sich einer Reihe schlechter Wahlen gegenüber.
Man nehme zum Beispiel an, daß der Videodatenverkehr durch das in 1 dargestellte System geroutet wird. Wie gezeigt werden Videodaten von dem Netzwerkteilnehmerstandort 100 zu dem Fernbenutzerstandort 101 über das VBR-Netzwerk 102 gesendet. Als Reaktion auf das Signal aus dem Prozessor 103 werden Daten von der komprimierten Videoquelle 104 mittels des Quellenpuffers 105 und des Reglers 106 zu dem VBR-Netzwerk 102 übertragen. Der Regler 106 ist ein Datenregler des Typs „Leaky-Bucket", eines in der Technik wohlbekannten Typs. Diese Art von Regler ermöglicht die Ausgabe von Daten mit einer bestimmten Rate als Funktion der Verfügbarkeit von Daten-Token (107) innerhalb des Token-Bucket-Registers 108. Token werden in dem Token-Bucket-Register 108 mit einer vorbestimmten Rate „abgelegt" und ausgeschöpft, wenn Daten den Regler 106 durchlaufen – wenn der Token-Bucket 108 leer ist, dürfen keine zusätzlichen Daten den Regler 106 durchlaufen. Diese Token sind von virtueller Beschaffenheit; das heißt, sie dienen nur zur Messung des Datenflusses durch den Regler 106 und werden nicht in den abgehenden Datenstrom eingefügt. Wenn die Tokenverfügbarkeit/Datenrate des Reglers 106 so gewählt wird, daß die Rate der Datenausgabe aus dem Regler 106 die mittlere Datenrate approximiert, mit der Daten die komprimierte Videoquelle 104 verlassen (eine Bedingung, die den statistischen Multiplexgewinn in dem VBR- Netzwerk 102 maximiert) und wenn die Größe des Token-Bucket-Registers 108 (d.h. die maximale Anzahl der Token, die in diesem Register gehalten werden können) auf einen mäßigen Wert gesetzt wird (um so eine Überlastung des VBR-Netzwerks 102 zu vermeiden), muß der Quellenpuffer 105 sehr groß sein, um einen längeren hochratigen Datenburst aus der komprimierten Videoquelle 104 zu unterstützen. Unter Ausschluß der Verfügbarkeit eines solchen großen Quellenpuffers werden Datenverluste auftreten. Auch wenn der Quellenpuffer 105 groß genug gemacht wird, um solche langen Bursts der Spitzenvideoübertragung handzuhaben, ist das Ergebnis weiter noch lange nicht ideal – Datenverluste werden vermieden, aber aufgrund des großen Quellenpuffers nehmen die Gerätekosten zu und es treten in Bezug auf die Quellenausgabe lange Verzögerungen auf.
Wenn das Token-Bucket-Register 108 dagegen groß genug gemacht wird, um es dem Token-Regler 106 zu ermöglichen, den Quellenpuffer 105 schnell von Datenüberschwemmungen zu befreien, die sich aus langen Videodatenbursts ergeben, sind große Netzwerk- und Fernbenutzerstandort-Puffer (109, 110) notwendig, um Datenverluste zu vermeiden und eine ordnungsgemäße Ablieferung eines benutzbaren Videosignals an den Empfänger/Betrachter 111 sicherzustellen. Indem es solchen Bursts erlaubt wird, frei abgezogen und in das VBR-Netzwerk 102 eingespeist zu werden, wird ferner einem einzelnen Netzwerkteilnehmerstandort die Möglichkeit gegeben, VBR-Netzwerk 102 zu unterbrechen, indem er es mit zig Megabytedaten überflutet.
Das Phänomen langer Spitzen von hochratigen Daten führt also zu hohen Datenverlusten, großen Verzögerungen zwischen Quelle und Empfänger oder einer unterbrechungsanfällgen unregulierten VBR-Netzwerkumgebung. Mit dem gegebenen aktuellen Rahmen des VBR-Netzwerkdienstes gibt es keine klare Möglichkeit, alle diese Probleme gleichzeitig zu vermeiden. Dies ist eine einfache Folge des Umstands, daß die in komprimierten Videodaten auftretenden langen Spitzen gegen die grundlegenden Entwurfsannahmen für VBR-Dienst verstoßen.
EP-A-0 632 671 lehrt ein Verfahren und eine Vorrichtung zur Bereitstellung von Dateien für einen abgesetzten Knoten mit dem Schritt des Bestimmens, ob Bandbreite verfügbar ist, um eine von einem abgesetzten Knoten angeforderte Datei über eine Kommunikationsstrecke zu übertragen, des Reservierens von für die angeforderte Datei angeforderter Bandbreite, wenn Bandbreite als verfügbar bestimmt wird, und des Öffnens der angeforderten Datei zur Übertragung nur dann, wenn Bandbreite reserviert ist.
Kurze Darstellung der Erfindung
Ein System und Verfahren gemäß der Erfindung werden in den unabhängigen Ansprüchen definiert. Bevorzugte Formen werden in den abhängigen Ansprüchen definiert.
Gemäß den Prinzipien der Erfindung werden die obigen Probleme gelöst durch Bereitstellung eines Datenübertragungssystems und eines Verfahrens, das entweder ein Netzwerk mit neu ausgehandelter variabler Bitrate („RVBR") oder ein Netzwerk mit neu ausgehandelter konstanter Bitrate („RCBR") verwendet. In diesen Netzwerken werden Datenübertragungsraten zwischen einem Absender und einem Empfänger schnell als Funktion zuvor gespeicherter Datenübertragungsinformationen und Systempufferstände neu ausgehandelt. Ein solchen System und Verfahren kann ohne weiteres in existierenden CBR- und/oder VBR-Netzwerkarchitekturen implementiert werden. Die RCBR- und RVBR-Netzwerke ermöglichen die Implementierung intelligenter Datenverkehrsverwaltungssysteme, die auf die Rate, mit der neue Verbindungen oder Verbindungsanforderungen in das Netzwerk eintreten oder dieses verlassen, die Häufigkeit und Dauer längerer Spitzenratendatenbursts sowie das Auftreten kurzer Datenübertragungsspitzen reagieren.
Kurze Beschreibung der Zeichnung
Es zeigen:
1 ein vereinfachtes Blockschaltbild der Architektur eines vorbekannten VBR-Netzwerkdatenübertragungssystems;
2 ein vereinfachtes Blockschaltbild der Architektur eines neu ausgehandelten VBR-Netzwerks mit einer beispielhaften Ausführungsform der Erfindung; und
3 ein vereinfachtes Blockschaltbild der Architektur eines neu ausgehandelten CBR-Netzwerks mit einer alternativen Ausführungsform der Erfindung.
Ausführliche Beschreibung der Erfindung
2 zeigt in vereinfachter Form die Architektur eines RVBR-Netzwerks mit einer beispielhaften Ausführungsform der Erfindung. Das dargestellte System umfaßt einen Netzwerkteilnehmerstandort 200, einen Fernbenutzerstandort 201 und ein RVBR-Netzwerk 202. Wie gezeigt, enthält der Netzwerkteilnehmerstandort einen Leaky-Bucket-Regler 203, ein Token-Bucket-Register 204, Daten-Token 205, einen Quellenpuffer 206, eine Videoquelle 207, einen Videodatenübertragungsratenspeicher 208 und einen Prozessor 209. Die Videoquelle 207 enthält ein bestimmtes komprimiertes Videoprogramm, das über das RVBR-Netzwerk 202 zu dem Fernbenutzerstandort 201 übertragen wird. Der Videodatenübertragungsratenspeicher 208 enthält einen zuvor zusammengestellten Datensatz der Momentan-Übertragungsraten, die in dem RVBR-Netzwerk 202 aufrechterhalten werden müssen, um die Echtzeitübertragung des in der Videoquelle 207 gespeicherten komprimierten Videoprogramms zu unterstützen. Um zum Beispiel effiziente Übertragung eines komprimierten Videosignals zu ermöglichen, das einen typischen Spielfilm repräsentiert, ist es sehr wahrscheinlich notwendig, die Übertragungsrate in dem RVBR-Netzwerk 202 alle paar Sekunden zu ändern (aufgrund der verschiedenen Bewegungsgrade und/oder Beleuchtung von Szene zu Szene). Der in dem Speicher 208 gespeicherte Datensatz der Momentan-Übertragungsraten besteht deshalb aus einer Auflistung von Raten R₀ bis R_n, die jeweils auf ein spezifisches Segment (S₀ bis S_n) des in der Videoquelle 207 gespeicherten bestimmten komprimierten Videoprogramms indiziert sind. Außerdem besteht wie in 2 gezeigt das RVBR-Netzwerk 202 aus einem herkömmlichen VBR-Netzwerk (212), das von Netzwerkneuaushandlungssteuerung 213 verwaltet wird. Das RVBR-Netzwerk 202 ist außerdem als einen Puffer 214 enthaltend gezeigt. Der Fernbenutzerstandort 201 ist als einen Puffer 210 und einen Empfänger/Betrachter 211 enthaltend gezeigt.
Im Betrieb dient ein Signal aus dem Prozessor 209 zum Einleiten der Übertragung eines bestimmten komprimierten Videodatenprogramms aus der Videoquelle 207 zu einem Fernbenutzerstandort 201. Dieses Prozessorsignal kann als Reaktion auf eine Benutzeranforderung erzeugt werden (was für interaktive Anforderung- oder Pay-Per-View-Videosysteme der Fall wäre), oder das Signal kann gemäß einem vorbestimmten Zeitplan durch den Prozessor 209 erzeugt werden. Das Einleitungssignal wird über die Leitung 215 zu dem Videodatenübertragungsratenspeicher 208 übertragen. Der Ratenwert R₀ (der mit dem Anfangssegment S₀ des in der Videoquelle 207 gespeicherten bestimmten komprimierten Videodatenprogramms assoziiert ist) wird aus dem Videodatenübertragungsratenspeicher 208 zu der Netzwerkneuaushandlungssteuerung 213 übertragen. Die Übertragung von R₀ dient als Anforderung zum Erhalten einer Verbindung in dem RVBR-Netzwerk 202, die eine Datenübertragung von R₀ Bit pro Sekunde(„bps") zwischen dem Netzwerkteilnehmerstandort 200 und dem Fernbenutzerstandort 201 unterstützen kann. Die Kommunikation zwischen dem Videoübertragungsratenspeicher 208 und der Netzwerkneuaushandlungssteuerung 213 wird über eine Außerbandzeichengabeverbindung 216 bewirkt. Systeme, die Außerbandzeichengabe zwischen Netzwerkteilnehmerstandorten und Netzwerksteuerungen ermöglichen, sind in der Technik wohlbekannt.
Der Vorgang des Aushandelns der angeforderten R₀-Übertragungsbandbreite in dem RVBR-Netzwerk 202 wird durch die Netzwerkneuaushandlungssteuerung 213 durchgeführt. Diese Aushandlung ist der bei der Einleitung von Anrufverbindungen in gewöhnlichen VBR-Netzwerken durchgeführten ähnlich. Ein Netzwerkvermittlungssystem (in diesem Fall die Netzwerkneuaushandlungssteuerung 213) vergleicht eine ankommende Anforderung von Übertragungsbandbreite mit verfügbaren Netzwerkbetriebsmitteln. Wenn die Betriebsmittel verfügbar sind, wird die Anforderung angenommen und dem anfordernden Teilnehmer Netzwerkzugang gewährt. Wenn die Anforderung derzeitige Netzwerkbetriebsmittel übersteigt, wird dem Teilnehmer der Zugang verweigert. Beliebige von mehreren im Handel erhältlichen programmierbaren Telekommunikationsnetzvermittlungssystemen wären dafür geeignet, als die Netzwerkneuaushandlungssteuerung (213) in dem System von 2 zu dienen. Ein solches Vermittlungssystem ist zum Beispiel die Vermittlung 4 ESS^TM, die von AT & T Corp. hergestellt und in The Bell System Technical Journal, Bd. 56, Nr. 7, September 1977, beschrieben wird. Natürlich besteht ein endlicher Zeitraum t_neg, der erforderlich ist, um eine Anforderung zu empfangen, als Reaktion auf diese Anforderung eine Bandbreitenaushandlung durchzuführen und Netzwerkzugang für den anfordernden Teilnehmer herzustellen. Die Verwendung zur zeit verfügbarer Vermittlungssysteme, wie zum Beispiel des 4 ESS^TM in dem System von 2 würde zu einem t_neg in der Größenordnung von 50 ms führen.
Unter der Annahme, daß die R₀-Bandbreitenanforderung erfolgreich ist, sendet die Netzwerkneuaushandlungssteuerung 213 ein Bestätigungssignal über die Zeichengabeverbindungsleitung 217 zu dem Prozessor 209. Dieses Bestätigungssignal kommt ungefähr zum Zeitpunkt t₀ + t_neg an dem Prozessor 209 an; wobei t₀ der Zeitpunkt des Sendens der R₀-Ratenanforderung aus dem Videodatenübertragungsratenspeicher 208 zu der Netzwerkneuaushandlungssteuerung 213 ist. Nach Empfang dieser Bestätigung stellt der Prozessor 209 den Leaky-Bucket-Regler 203 und die Menge an Daten-Token 205 in dem Token-Bucket-Register 204 für die ausgehandelte Datenrate ein. Der Prozessor 209 weist dann die Videoquelle 207 an, das Datensegment S₀ von dem Netzwerkteilnehmerstandort 200 zu dem Fernbenutzerstandort 201 zu senden.
Zu einem Zeitpunkt, der ungefähr t_neg vor dem Abschluß der Übertragung des Segments S₀ liegt, wird der Videodatenübertragungsratenspeicher 208 von dem Prozessor 209 angewiesen, den Ratenwert R₁ (der mit dem komprimierten Videosegment S₁ assoziiert ist) zu der Netzwerkneuaushandlungssteuerung 213 zu senden. Diese Übertragung von R₁ dient als Anforderung einer Verbindung in dem RVBR-Netzwerk 202 zur Unterstützung einer Datenübertragung von R₁ bps – der Rate, die erforderlich ist, um das komprimierte Videosegment S₁ erfolgreich zu senden. Unter der Annahme, daß diese Anforderung erfolgreich ist, empfängt der Prozessor 209 über die Zeichengabeverbindung 217 ein Bestätigungssignal. Als Reaktion stellt der Prozessor 209 den Leaky-Bucket-Regler 203 und das Token-Bucket-Register 204 entsprechend ein und weist dann die Videoquelle 207 an, das Datensegment S1 von dem Netzwerkteilnehmerstandort 200 zu dem Fernbenutzerstandort 201 zu senden.
Diese Sequenz von Anforderung/Aushandlung/Bestätigung/Einstellung/Übertragung wird wiederholt, bis alle n Segmente des in der Videoquelle 207 gespeicherten komprimierten Videoprogramms zu dem Fernbenutzerstandort 201 übertragen wurden.
Es wird nicht angenommen, daß das RVBR-Netwzerk 202 für die ausschließliche Benutzung eines Benutzers reserviert ist. Die an die Betriebsmittel des RVBR-Netzwerks 202 durch die gleichzeitige Übertragung von Daten zwischen vielen Teilnehmern und Benutzern gestellten Anforderungen führen folglich fast unausweichlich zu der Verweigerung einer oder mehrerer Bandbreitenanforderungen. Falls eine Bandbreitenanforderung erfolglos bleibt, kann das System von 2 programmiert sein, auf eine von drei Weisen zu reagieren.

1) Verringerung der Rate komprimierter Videodaten, die aus der Videoquelle 207 übertragen werden. Nachdem die Netzwerkneuaushandlungssteuerung 213 bestimmt, daß die angeforderte Übertragungsrate die derzeitigen Fähigkeiten des RVBR-Netzwerks 202 übersteigt, wird ein diesen Umstand anzeigendes Signal über die Zeichengabeverbindung 217 zu dem Prozessor 209 gesendet. Als Reaktion weist der Prozessor 209 die Videoquelle 207 an, die Rate der Übertragung komprimierter Videodaten zu verringern (der Leaky-Bucket-Regler 203 und das Token-Bucket-Register 204 werden auch entsprechend eingestellt). Diese Datenratenverringerung läßt sich durch Verschlechtern der Videoauflösung und/oder Vermindern der Videoeinzelbildrate erreichen. Beides führt zu der Übertragung eines qualitativ minderwertigeren Videosignals zu dem Fernbenutzerstandort 201. Der verschlechterte Grad der Videoübertragung wird bis mindestens zum Abschluß der nächsten Bandbreitenaushandlungssequenz fortgesetzt.
2) Verringerung der Rate der durch das RVBR-Netzwerk 202 übertragenen Videodaten. In diesem Szenario weist der Prozessor 209, wenn eine bestimmte Übertragungsratenanforderung erfolglos bleibt, die Videoquelle 207 nicht an, das komprimierte Videodatenübertragungssignal zu reduzieren, wodurch die Anforderungserfolglosigkeit angezeigt wird, der Prozessor 209 stellt den Leaky-Bucket-Regler 203 und das Token-Bucket-Register 204 auf die bestimmte Datenrate ein, die das RVBR-Netzwerk 202 unterstützt. Folglich sendet die Videoquelle 207 das nächste Segment komprimierter Videodaten mit der angeforderten Rate. Da RVBR 202 eine solche Übertragung nicht unterstützen kann, akkumulieren sich Videodaten in dem Quellenpuffer 206. Diese akkumulierten Daten werden mit jeglicher Rate, die RVBR unterstützen kann, zu dem Fernbenutzerstandort 201 übertragen. Vorausgesetzt, daß der Quellenpuffer 206 groß genug ist, um mit dem ankommenden Datenvolumen aus der Videoquelle 207 fertigzuwerden, sollte als Folge kein Datenverlust entstehen, lediglich eine Verzögerung ihres Empfangs an dem Fernbenutzerstandort 201. Aufgrund der Gefahr des Datenverlustes während der Quellenpuffer 206 voll oder nahezu voll ist, kann der Prozessor 209 so programmiert werden, daß die oben beschriebene Routine nur dann ausgeführt wird, wenn der Quellenpuffer 206 relativ leer ist.
3) Die Verbindung wird beendet und/oder nicht hergestellt. Diese höchst extreme Möglichkeit würde gewöhnlich als ein unerwünschtes Ergebnis betrachtet. Das System vom 2 könnte jedoch so programmiert werden, daß beim Erfolglosbleiben einer Bandbreitenanforderung die Verbindung zwischen dem Netzwerkteilnehmerstand 200 und dem Fernbenutzerstandort 201 einfach beendet oder niemals hergestellt wird (falls die erfolglose Anforderung die anfängliche Verbindungsanforderung war).

3 zeigt in vereinfachter Form die Architektur eines RCBR-Netzwerks mit einer alternativen Ausführungsform der Erfindung. Das dargestellte System umfaßt einen Netzwerkteilnehmerstandort 300, einen Fernbenutzerstandort 301 und ein RCBR-Netzwerk 302. Wie gezeigt, enthält der Netzwerkteilnehmerstandort einen Datenregler 303, einen Quellenpuffer 304, eine Videoquelle 305, einen Videodatenübertragungsratenspeicher 306 und einen Prozessor 307. Die Videoquelle 305 und der Videodatenübertragungsratenspeicher 306 enthalten komprimierte Video- bzw. Übertragungsratendaten. Diese Daten weisen ein Format auf, das dem für die Videoquelle 207 und den Videodatenübertragungsratenspeicher 208 von 2 beschriebenen ähnlich ist. Wie in 3 gezeigt, besteht außerdem das RVBR-Netzwerk 302 aus einem herkömmlichen CBR-Netzwerk (310), das von einer Netzwerkneuaushandlungssteuerung 311 verwaltet wird. Das RCBR-Netzwerk 302 ist außerdem als einen Puffer 312 enthaltend gezeigt. Der Fernbenutzerstandort 301 enthält einen Puffer 308 und einen Empfänger/Betrachter 309.
Die Funktionsweise des Systems von 3 ist der des Systems von 2 ähnlich – der Prozessor 307 sendet ein Einleitungssignal über die Leitung 313 zu dem Videodatenübertragungsratenspeicher 306. Als Reaktion wird der Ratenwert R₀ (der mit dem S₀-Segment des in der Videoquelle 305 gespeicherten bestimmten komprimierten Videodatenprogramms assoziiert ist) aus dem Videodatenübertragungsratenspeicher 306 über eine Außerbandzeichengabeverbindung 314 zu der Netzwerkneuaushandlungssteuerung 311 übertragen. Die Übertragung von R₀ dient als Anforderung zum Erhalten einer Verbindung innerhalb des RCBR-Netzwerks 302, die eine Datenübertragung von R₀ bps zwischen dem Netzwerkteil nehmerstandort 300 und dem Fernbenutzerstandort 301 unterstützen kann.
Die Netzwerkneuaushandlungssteuerung 311 führt den Vorgang des Aushandelns der angeforderten R₀-Übertragungsbandbreite in dem RCBR-Netzwerk 302 durch. Diese Aushandlung ist der bei der Einleitung von Anrufverbindungen in gewöhnlichen CBR-Netzwerken durchgeführten ähnlich. Wenn die Netzwerkbetriebsmittel verfügbar sind, wird die Anforderung angenommen und dem anfordernden Teilnehmer Netzwerkzugang gewährt. Wenn die Anforderung die derzeitigen Netzwerkbetriebsmittel übersteigt, wird dem Teilnehmer Zugang verweigert. Wie bei dem System von 2 wären beliebige einer Anzahl im Handel erhältlicher programmierbarer Telekommunikationsnetzwerkvermittlungssysteme (wie z.B. 4 ESS) dafür geeignet, als Netzwerkneuaushandlungssteuerung zu dienen. Die Zeit, die erforderlich ist, um eine Anforderung zu empfangen, eine Bandbreitenaushandlung durchzuführen und den Netzwerkzugangzugang für den anfordernden Teilnehmer herzustellen, wird als t_neg bezeichnet (typischerweise in der Größenordnung von 50 ms).
Unter der Annahme, daß die R₀-Bandbreitenanforderung erfolgreich ist, sendet die Netzwerkneuaushandlungssteuerung 311 ein Bestätigungssignal über die Zeichengabeverbindungsleitung 315 zu dem Prozessor 307. Dieses Bestätigungssignal kommt ungefähr zum Zeitpunkt t₀ + t_neg an dem Prozessor 307 an; dabei ist t₀ der Zeitpunkt des Sendens der R₀-Ratenanforderung aus dem Videodatenübertragungsratenspeicher 306 zu der Netzwerkneuaushandlungssteuerung 311. Wenn er diese Bestätigung empfängt, weist der Prozessor 307 die Videoquelle 305 an, das Datensegment S₀ aus dem Netzwerkteilnehmerstandort 300 zu dem Fernbenutzerstandort 301 zu übertragen.
Zu einem Zeitpunkt von ungefähr t_neg vor dem Abschluß der Übertragung des Segments S₀ weist der Prozessor 307 den Videodatenübertragungsratenspeicher 306 an, den Ratenwert R₁ (der mit dem komprimierten Videosegment S₀ assoziiert ist) zu der Netzwerkneuaushandlungssteuerung 311 zu übertragen. Diese Übertragung von R₁ dient als Anforderung einer Verbindung in dem RCBR-Netzwerk 302 zur Unterstützung der Datenübertragung von R₁ bps – der Rate, die erforderlich ist, um das komprimierte Videosegment S₁ erfolgreich zu übertragen. Vorausgesetzt, daß diese Anforderung erfolgreich ist, empfängt der Prozessor 307 über die Zeichengabeverbindung 315 ein Bestätigungssignal und weist als Reaktion die Videoquelle 305 an, das Datensegment S1 aus dem Netzwerkteilnehmerstandort 300 zu dem Fernbenutzerstandort 301 zu übertragen.
Diese Sequenz von Anforderung/Aushandlung/Bestätigung/Übertragung wird wiederholt, bis alle n Segmente des in der Videoquelle 305 gespeicherten komprimierten Videoprogramms zu dem Fernbenutzerstandort 301 übertragen wurden.
An die Betriebsmittel des RCBR-Netzwerks 302 durch die gleichzeitige Übertragung von Daten zwischen vielen Teilnehmern und Benutzern gestellte Anforderungen können zu der Verweigerung von einer oder mehreren Bandbreitenanforderungen führen und das System von 3 kann dafür programmiert werden, auf eine von drei Weisen auf ein Erfolglosbleiben einer Bandbreitenanforderung zu reagieren.

1) Verringerung der Rate komprimierter Videodaten, die aus der Videoquelle 305 übertragen werden. Nachdem die Netzwerkneuaushandlungssteuerung 311 bestimmt, daß die angeforderte Übertragungsrate die derzeitigen Fähigkeiten des RCBR-Netzwerks 302 übersteigt, wird ein diesen Umstand anzeigendes Signal über die Zeichengabeverbindung 315 zu dem Prozessor 307 gesendet. Als Reaktion weist der Prozessor 307 die Videoquelle 207 an, die Rate der Übertragung komprimierter Videodaten zu verringern (der Leaky-Bucket-Regler 303 wird auch entsprechend eingestellt). Diese Datenratenverringerung läßt sich durch Verschlechtern der Videoauflösung und/oder Vermindern der Videoeinzelbildrate erreichen. Der verschlechterte Grad der Videoübertragung wird bis mindestens zum Abschluß der nächsten Bandbreitenaushandlungssequenz fortgesetzt.
2) Verringerung der Rate der durch das RCBR-Netzwerk 302 übertragenen Videodaten. Wenn eine Übertragungsratenanforderung erfolglos bleibt, weist der Prozessor 307 die Videoquelle 305 nicht an, das komprimierte Videodatenübertragungssignal zu reduzieren. Als Reaktion auf ein Signal, das die Anforderungserfolglosigkeit anzeigt, stellt der Prozessor 307 jedoch den Datenregler 303 auf die Datenrate ein, die das RCBR-Netzwerk 302 unterstützt. Folglich sendet die Videoquelle 305 das nächste Segment komprimierter Videodaten mit der angeforderten Rate. Da RCBR 302 eine solche Übertragung nicht unterstützen kann, akkumulieren sich Videodaten in dem Quellenpuffer 304. Diese akkumulierten Daten werden mit jeglicher Rate, die RCBR unterstützen kann, zu dem Fernbenutzerstandort 301 übertragen. Vorausgesetzt, daß der Quellenpuffer 304 groß genug ist, um mit dem ankommenden Datenvolumen aus der Videoquelle 305 fertigzuwerden, sollte als Folge kein Datenverlust entstehen, lediglich eine Verzögerung ihres Empfangs an dem Fernbenutzerstandort 301.
3) Die Verbindung wird beendet und/oder nicht hergestellt. Diese höchst extreme Möglichkeit würde gewöhnlich als ein unerwünschtes Ergebnis betrachtet. Das System vom 3 könnte jedoch so programmiert werden, daß beim Erfolglosbleiben einer Bandbreitenanforderung die Verbindung zwischen dem Netzwerkteilnehmerstand 300 und dem Fernbenutzerstandort 301 einfach beendet oder niemals hergestellt wird (falls die erfolglose Anforderung die anfängliche Verbindungsanforderung war).

Es versteht sich, daß die oben beschriebenen konkreten Ausführungsformen und Verfahren lediglich die Prinzipien der vorliegenden Erfindung veranschaulichen und daß Fachleute verschiedene Modifikationen vornehmen könnten, ohne von dem Schutzumfang der vorliegenden Erfindung abzuweichen, der nur durch die folgenden Ansprüche begrenzt wird. Eine solche Modifikation wäre zum Beispiel die Verwendung der Erfindung in einem privaten Netzwerk oder die Anwendung der Erfindung auf Netzwerke, die für das Übertragen von digitalen Daten ausgelegt sind, die andere Informationen als komprimiertes Video repräsentieren. Eine andere Modifikation wäre die Anwendung der Erfindung auf RVBR- und/oder RCBR-Netzwerke, bei denen Verbindungen zwischen einem einzelnen Teilnehmerstandort und mehreren Fernbenutzerstandorten gleichzeitig bewirkt werden (d.h. ein einziges Videoprogramm wird zu einer Anzahl von Empfängern „ausgestrahlt").

Claims

Datenübertragungssystem, umfassend: einen ersten Standort (200 oder 300); einen zweiten Standort (201 oder 301); ein Netzwerk, das eine Verbindung zwischen dem ersten und dem zweiten Standort bereitstellt, wobei das Netzwerk ein Netzwerk mit variabler Bitrate (212) oder ein Netzwerk mit fester Bitrate (310) ist; und einen ersten Speicher (207 oder 305), der eine Reihe von Datensegmenten speichert; gekennzeichnet durch einen zweiten Speicher (208 oder 306), der einen zuvor zusammengestellten Datensatz von Momentan-Übertragungsraten speichert, wobei jede der gespeicherten Raten mit einem oder mehreren der gespeicherten Datensegmente assoziiert ist; und eine Netzwerksteuerung (213 oder 311), die so ausgelegt ist, daß sie als Reaktion auf den Inhalt des zweiten Speichers eine Verbindung zwischen dem ersten und dem zweiten Standort aushandelt, die eine bestimmte Bandbreite aufweist.
System nach Anspruch 1, wobei die Reihe von Datensegmenten ein Videosignal repräsentiert.
System nach Anspruch 2, wobei jede der gespeicherten Raten in dem zweiten Speicher die Momentan-Übertragungsrate repräsentiert, die erforderlich wäre, um die Übertragung der Reihe von Datensegmenten so zu unterstützen, daß das repräsentierte Videosignal an dem zweiten Standort in Echtzeit empfangen wird.
System nach einem der vorhergehenden Ansprüche, wobei die Netzwerksteuerung ferner so ausgelegt ist, daß sie eine Verbindung mit einer alternativen Bandbreite in dem Netzwerk aushandelt, wenn die anfängliche Aushandlung einer Verbindung zwischen dem ersten und dem zweiten Standort als Reaktion auf den Inhalt des zweiten Speichers erfolglos bleibt.
System nach einem der vorhergehenden Ansprüche, ferner mit einem Datenspeicher, der so ausgelegt ist, daß er aus dem ersten Speicher zu dem Netzwerk fließende Daten puffert.
System nach Anspruch 5 sofern abhängig von Anspruch 4, wobei die alternative Bandbreite eine Funktion des Inhalts des Datenspeichers ist.
Verfahren zum Bewirken einer Übertragung zwischen einem ersten Standort (200 oder 300) und einem zweiten Standort (201 oder 301) über ein Netzwerk mit variabler Bitrate (212) oder ein Netzwerk mit fester Bitrate (310), mit den folgenden Schritten: Bereitstellen einer Verbindung zwischen dem ersten und dem zweiten Standort über das Netzwerk; und Speichern einer Reihe von Datensegmenten in einem ersten Speicher (207 oder 305); gekennzeichnet durch die folgenden Schritte: Abrufen eines Werts, der eine Momentan-Datenübertragungsrate angibt, aus einem zweiten Speicher (208 oder 306), wobei die gespeicherte Rate mit einem oder mehreren zu übertragenden Datensegmenten assoziiert ist; Aushandeln (213 oder 311) einer Verbindung mit einer bestimmten Bandbreite über das Netzwerk als Reaktion auf den abgerufenen Momentan-Datenratenwert zwischen dem ersten und dem zweiten Standort über das Netzwerk.
Verfahren nach Anspruch 7, wobei die Reihe von Datensegmenten ein Videosignal repräsentiert.
Verfahren nach Anspruch 8, wobei die Übertragung des einen bzw. der mehreren Datensegmente zwischen dem ersten und dem zweiten Standort über das Netzwerk zu dem Empfang des repräsentierten Videosignals an dem zweiten Standort in Echtzeit führt.
Verfahren nach einem der Ansprüche 7 bis 9, ferner mit dem folgenden Schritt: Aushandeln einer Verbindung mit einer alternativen Bandbreite in dem Netzwerk bei Erfolglosbleiben der anfänglichen Aushandlung einer Verbindung mit einer bestimmten Bandbreite als Reaktion auf einen besagten abgerufenen Momentan-Datenratenwert.