-
Technisches Gebiet der
Erfindung
-
Die vorliegende Erfindung betrifft
eine Multicast-Datenübertragungssteuerung,
wie sie beispielsweise in einem Film-auf-Anforderung-System (movie-on-demand
system) und einem Videokonferenzsystem des Typs verwendet werden
kann, bei dem mehreren Clients Videoströme zur Verfügung gestellt werden, die von
einem zentralen Videoserver bereitgestellt werden.
-
Stand der Technik
-
In vielen Film-auf-Anforderung- und
Videokonferenzsystemen werden mehreren Clients Videoströme zur Verfügung gestellt,
die von einem zentralen Videoserver bereitgestellt werden. Dieser
Prozess (Versorgen mehrerer Clients durch einen einzigen Strom)
wird als Multicasting bezeichnet. In solchen Systemen werden Videodaten
normalerweise auf eine von zwei Arten vom Server an Clients übertragen:
durch "Client-Abruf" ("client pull") oder Server-Eingabe
("server push"). Bei einem Client-Abrufmechanismus
liefert der Server Blöcke
auf Anforderung der Clients hin. Im Gegensatz dazu liefert der Server
bei einem Server-Eingabemechanismus periodisch Blöcke an Clients.
Eine Erläuterung
von Client-Abruf- und Server-Eingabestrategien
ist in der Veröffentlichung "A Preliminary Study
of Push vs. Pull in Motion Video Servers", Second Workshop on High Performance
Communication Subsystems, HPCS '93,
Williamsburg, VA, September 1193, von K. Hwang et al. zu finden.
-
Der Client-Abrufmechanismus bringt
zusätzliche
Nachrichten mit sich, da ein Client den Server über seine Bereitschaft zum
Empfangen eines neuen Blocks benachrichtigen muss.
-
Der Server-Eingabemechanismus kann
andererseits auch dann einen neuen Datenblock an Clients übertragen,
wenn frühere
Blöcke
nicht verarbeitet (wiedergegeben) wurden. Der Grund hierfür ist, dass
die Wiedergabegeschwindigkeit nicht für alle komprimierten Datenblöcke gleich
ist. Daher wird in jedem Client ein größerer Pufferbereich benötigt, um das
Problem eines Pufferüberlaufs
(buffer overflow) zu vermeiden.
-
Die Probleme sind ähnlich wie
beispielsweise in einer Telekonferenzanwendung, bei der derselbe
Datenstrom per Multicasting an mehrere Clients übertragen wird.
-
Beschreibung der Erfindung
-
Dementsprechend stellt die vorliegende
Erfindung ein Verfahren zur Steuerung der Übertragung eines Datenstroms
von einem Server an eine Vielzahl von Clients in einer Multicast-Gruppe
bereit, das die folgenden Schritte umfasst: Empfangen einer Dienstanforderung
zur Übertragung
eines Teils des Datenstroms von irgendeinem der Clients im Server; auf
den Empfang der Dienstanforderung hin Feststellen, ob ein festgelegtes
Rundsendekriterium erfüllt wurde;
und auf die Feststellung hin, dass das Rundsendekriterium erfüllt wurde,
Rundsenden des angeforderten Teils an alle Clients in der Multicast-Gruppe.
-
Die Erfindung stellt außerdem eine
Servervorrichtung zum Steuern der Übertragung eines Datenstroms über ein
Netz an eine Vielzahl von Clients in einer Multicast-Gruppe bereit,
die Folgendes umfasst: ein Speichermittel zum Speichern von Teilen des
zu übertragenden
Datenstroms; ein Schnittstellenmittel zum Empfangen einer Dienstanforderung von
irgendeinem der Clients zur Übertragung
eines Teils des Datenstroms an den Client; ein Rundsendesteuermittel,
um auf den Empfang der Dienstanforderung hin festzustellen, ob ein
festgelegtes Rundsendekriterium erfüllt wurde, und auf eine Feststellung hin,
dass das Rundsendekriterium erfüllt
wurde, den angeforderten Teil an alle Clients in der Multicast-Gruppe
rundzusenden.
-
Folglich ermöglicht die Erfindung die Verwendung
einer Kombination aus Client-Abruf- und Server-Eingabemechanismen,
um sowohl den größeren Pufferbedarf
in den Clients als auch den größeren Nachrichtenaufwand
zu vermeiden, der durch den alleinigen Client-Abrufmechanismus hervorgerufen
wird.
-
In einer ersten Ausführungsform
wird einer der Clients in einer Multicast-Gruppe als Führungseinheit
gekennzeichnet. Wenn eine Dienstanforderung zur Übertragung eines Teils des
Datenstroms von irgendeinem der Clients vom Server empfangen wird,
stellt der Server fest, ob die Dienstanforderung von der Führungseinheit
stammte. Auf die Feststellung hin, dass die Dienstanforderung von
der Führungseinheit
stammte, rundsendet der Server den Teil des Datenstroms an die Clients
in der Multicast-Gruppe. Andernfalls wird die Rundsendung aufgeschoben.
-
In einer anderen Ausführungsform
stellt der Server auf den Empfang der Dienstanforderung zur Wiedergabe
eines Teils von Videodaten (z. B. eines Blocks) von irgendeinem
der Clients in einer Multicast-Gruppe hin fest, ob ein festgelegtes
Rundsendekriterium erfüllt
wurde. Ist dies der Fall, rundsendet der Server den angeforderten
Teil an alle der Clients in der Multicast-Gruppe. Andernfalls wird
der Teil nicht an alle aus der Gruppe übertragen, und das System wird
erneut auf das Rundsendekriterium hin überprüft, wenn eine andere Dienstanforderung
von irgendeinem der Clients empfangen wird.
-
Kurze Beschreibung der
Zeichnungen
-
Die Erfindung wird nun lediglich
beispielhaft mit Bezugnahme auf bevorzugte Ausführungsformen davon beschrieben,
wie sie in den begleitenden Zeichnungen veranschaulicht werden,
in denen:
-
1 ein
Blockschaltbild eines Video-auf-Anforderung-Systems (video-on-demand system) ist,
das eine Servervorrichtung gemäß der vorliegenden
Erfindung enthält;
-
2 ein
Multicast-Übertragungssteuerungsverfahren
zeigt, das im System von 1 verwendet
werden kann, in dem das Rundsendekriterium auf einem statischen
Führungseinheitauswahlschema
(static leader selection scheme) beruht;
-
3 ein
anderes Multicast-Übertragungssteuerungsverfahren
zeigt, das im System von 1 verwendet
werden kann, in dem das Rundsendekriterium auf einem Zählwert von
Clientanforderungen beruht;
-
4 noch
ein anderes Multicast-Übertragungssteuerungsverfahren
zeigt, das im System von 1 verwendet
werden kann, in dem das Rundsendekriterium auf der Wiedergabezeit
beruht; und
-
5 das
Speichern von Wiedergabezeitdaten zur Verwendung im Verfahren von 4 zeigt.
-
Ausführliche Beschreibung der Erfindung
-
1 ist
eine Darstellung eines Video-auf-Anforderung-Systems gemäß einer Ausführungsform
der vorliegenden Erfindung. Das Video-auf-Anforderung-System enthält einen
Videoserver 130, wobei Videos (z. B. 131), beispielsweise
Filme und dergleichen, in Speichereinheiten wie der Plattenmatrix
(disk array) 132 gespeichert werden. Außerdem werden Videoattributdateien
(video attribute files) 133 auf der Plattenmatrix gespeichert,
eine für
jedes Video, die Daten wie die Größe und die Wiedergabegeschwindigkeit
(play rate) des Videos speichern. Gemäß einer Ausführungsform
der vorliegenden Erfindung enthalten die Videoattributdateien außerdem Wiedergabeprotokolldaten
(play history information), die weiter unten ausführlicher
beschrieben werden.
-
Der Videoserver 130 ist
durch eine herkömmliche
Netzschnittstelle 118 mit einem Kommunikationsnetz 120 verbunden.
Clients 110 übertragen über das
Kommunikationsnetz 120 Anforderungen an den Videoserver 130.
Clients können
mit Hilfe von Clientstationen (client stations) 122 Start-,
Stopp-, Pausen- und Fortsetzungsanforderungen übertragen. Um die Stapelverarbeitung
(batching), die VCR-Steuerung und andere Funktionen zu erleichtern,
werden die angeforderten Videos (oder Segmente der angeforderten
Videos) von den Platten 132 in einen Speicherpuffer 134 geladen
und sodann über
diesen den Clients bereitgestellt.
-
Der Videoserver 130 enthält einen
Prozessor (CPU) 112, der unter der Steuerung der verschiedenen
in einem Hauptspeicher 114 befindlichen Programme Verarbeitungsvorgänge ausführt. Diese
Programme enthalten eine Planungseinrichtung (scheduler) 140,
die einen Kanal (d. h. Ressourcen) reserviert und (mit Hilfe der
Sitzungsverwaltungseinrichtung 145) vor dem Start einer
Videowiedergabe Ansichtssitzungen (viewing sessions) einrichtet,
und eine Videowiedergabevorrichtung (video player) 150 für Start,
Stopp, Pause und Fortsetzung der Videowiedergabe auf eine Clientanforderung
hin, nachdem die Planungseinrichtung einen Kanal zur Verfügung gestellt
hat. Fachleute werden erkennen, dass die Steuerung und die Unterstützung der
Videoserverfunktionen außerdem
mehrere herkömmliche
Softwareprozesse 116 beinhalten, die hier nicht ausführlich beschrieben
werden.
-
Der Videoserver 130 kann
unter Verwendung eines beliebigen Prozessors mit ausreichender Leistungsfähigkeit
für die
Anzahl von zu unterstützenden Videoströmen ausgeführt werden.
Beispielsweise könnte
ein Videoserver mit geringer Kapazität unter Verwendung eines RISC-System/6000-TM-Systems ausgeführt werden,
während
ein Server mit höherer Kapazität unter
Verwendung eines ES/9000-TM-Systems (beide von International Business
Machines Corporation von Armonk, New York, erhältlich) ausgeführt werden
könnte.
Die Platten 132 können
in Form eines herkömmlichen
Plattenteilsystems oder einer Plattenmatrix ausgeführt werden.
Das Kommunikationsnetz 120 kann beispielsweise ein Lichtwellenleiternetz
(fiber optic network) oder ein herkömmliches bidirektionales Kabelnetz
sein. Die Clientstationen 122 können beispielsweise in Form
einer Set-Top-Box ausgeführt
werden.
-
Eine Möglichkeit zum Integrieren von
Clientabruf- und auch von Servereingabestrategien ist die Kennzeichnung
eines bestimmten Clients als Führungseinheit
für eine
gegebene Multicast-Gruppe (d. h. eine Gruppe von Clients, die dasselbe
Video als Teil derselben Sitzung betrachten). Die Identität der Clients
in jeder Multicast-Gruppe wird in einer Datenstruktur aufbewahrt
(im Speicher oder der Platte gespeichert), die die Sitzungsverwaltungseinrichtung und
die Videowiedergabevorrichtung gemeinsam nutzen. Wenn die Führungseinheit
den nächsten
Videoblock benötigt, überträgt sie eine
Abrufanforderung an den Server. Der Server behandelt dies als eine
Anforderung im Namen von allen Clients in der Multicast-Gruppe.
Folglich überträgt der Server
den angeforderten Videoblock auf die Abrufanforderung hin per Multicasting
an alle Clients, wodurch ein gemischtes Eingabe-/ Abrufsystem erzeugt
wird.
-
2 zeigt
die schrittweise Steuerung des Multicast-Vorgangs unter einem statischen
Führungseinheitauswahlschema.
Zum Zeitpunkt der Einrichtung einer Multicast-Sitzung kennzeichnet
die Sitzungsverwaltungseinrichtung 145 im Schritt 220 einen
der Clients als Führungseinheit.
Die Kennzeichnung kann durch eine beliebige Anzahl von Kriterien erfolgen,
beispielsweise durch eine Zufallsauswahl, eine Adressenreihenfolge
oder ein Prioritätsschema. Die
Videowiedergabevorrichtung 150 empfängt im Schritt 230 eine
Abrufanforderung zur Übertragung des
nächsten
Datenblocks von einem Client. Im Schritt 240 führt die
Videowiedergabevorrichtung sodann eine Prüfung durch, um festzustellen,
ob die Anforderung von der gekennzeichneten Führungseinheit übertragen
wurde. Ist dies der Fall, überträgt die Videowiedergabevorrichtung
im Schritt 250 den nächsten
Datenblock in einem Multicast-Vorgang an alle Clients in der Multicast-Gruppe.
Falls nicht, ignoriert die Videowiedergabevorrichtung die Anforderung.
Für eine
höhere
Leistungsfähigkeit
kann die Sitzungsverwaltungseinrichtung während der Sitzungseinrichtung
alle Clients mit Ausnahme der gekennzeichneten Führungseinheit anweisen, keine
Abrufanforderungen zu übertragen.
-
3 zeigt
die schrittweise Steuerung des Multicast-Vorgangs unter einem alternativen
Schema, bei dem für
jeden in einem Multicast-Vorgang zu übertragenden Block eine Führungseinheit
dynamisch ausgewählt
wird. In dieser Ausführungsform bewahrt
die Videowiedergabevorrichtung einen Zählwert von Clientabrufanforderungen
(von Mitgliedern der Multicast-Gruppe)
auf, die seit der vorhergehenden Übertragung des Datenblocks
an die Multicast-Gruppe empfangen wurden. Es muss klar sein, dass
für jede
Multicast-Gruppe ein gesonderter Zählwert aufbewahrt wird. Dieser
Zählwert
wird außerdem
in einer Datenstruktur aufbewahrt, die von der Sitzungsverwaltungseinrichtung 145 und
der Videowiedergabevorrichtung 150 gemeinsam genutzt wird. Zum
Zeitpunkt der Einrichtung einer Multicast-Sitzung wird dieser Zählwert von
der Sitzungsverwaltungseinrichtung auf null gesetzt. In der Folge
initialisiert die Videowiedergabevorrichtung den Zählwert nach
der Übertragung
von jedem Block auf null. Beide Initialisierungsvorgänge werden
im Schritt 320 widergespiegelt. Im Schritt 330 empfängt die
Videowiedergabevorrichtung Clientabrufanforderungen (innerhalb einer
gegebenen Multicast-Gruppe) für
den nächsten
Datenblock. Daraufhin erhöht
die Videowiedergabevorrichtung den Zählwert im Schritt 340.
Im Schritt 350 führt
die Videowiedergabevorrichtung eine Prüfung aus, um auf der Grundlage
des aktuellen Zählwertes
festzustellen, ob die Bedingung für die Multicast-Übertragung
des nächsten
Datenblocks erfüllt
wird. Dies kann beispielsweise eine Feststellung sein, ob die Anzahl
von für
die Gruppe empfangenen Anforderungen einen gegebenen Schwellenwert
(z. B. eine festgelegte Anzahl oder mehr als 50% der Clients) überschreitet.
Falls nicht, wartet die Videowiedergabevorrichtung 150 auf
die Ankunft von neuen Clientanforderungen. Andernfalls überträgt die Videowiedergabevorrichtung
im Schritt 360 den nächsten Datenblock
in einem Multicast-Vorgang an alle Clients in der Multicast-Gruppe
und beginnt im Schritt 320 eine neue Multicast-Runde.
-
4 zeigt
eine andere Ausführungsform, wobei
die schrittweise Steuerung des Multicast-Vorgangs unter Verwendung
gespeicherter Zeitdaten (Wiedergabeprotokoll) ausgeführt wird.
Im Schritt 420 liest die Videowiedergabevorrichtung das
Wiedergabeprotokoll für
den nächsten
in einem Multicast-Vorgang
zu übertragenden
Block aus der Videoattributdatei 133 für das im Multicast-Vorgang übertragene
Video. Für
jeden Videoblock enthält
die Videoattributdatei die benötigten
Zeitverzögerung
T_d seit der Multicast-Übertragung
des vorhergehenden Datenblocks. Diese Zeitverzögerung T_d ist ein Schätzwert auf
der Grundlage einer vorhergehenden Wiedergabe des Videos (wie mit
Bezugnahme auf 5 ausführlicher
erläutert
wird). Die Videowiedergabevorrichtung 150 wartet im Schritt 430 diese
Zeitverzögerung
ab. Anschlieflend überträgt die Videowiedergabevorrichtung
im Schritt 440 den nächsten Datenblock
an alle Clients in der Multicast-Gruppe und beginnt im Schritt 420 eine
neue Multicast-Runde.
-
5 zeigt
die Speicherung der Zeitdaten, die für zukünftige Multicast-Vorgänge, wie
die in 4 beschriebenen,
benötigt
werden. Während
einer vorhergehenden Wiedergabesitzung des Multicast-Videos (die
möglicherweise
an einen anderen Benutzer oder eine andere Multicast-Gruppe übertragen
wurde) hält
die Videowiedergabevorrichtung im Schritt 520 (vor dem
Start der Wiedergabe des aktuellen Datenblocks B1) die Zeit in einer
Speicherposition t_s fest. Anschließend wartet die Videowiedergabevorrichtung
im Schritt 530, bis der Client oder die Multicast-Gruppe
meldet, dass er bzw. sie für
die Übertragung
des nächsten
Videoblocks (durch den Server) bereit ist. Auf den Empfang dieses
Signals hin (das in der Tat eine Anforderung des nächsten Videoblocks
für diese
Sitzung ist) speichert die Videowiedergabevorrichtung die aktuelle
Zeit (c_t) und setzt T_d = c_t – t_s.
Im Schritt 550 wird T_d zusammen mit der Blocknummer für den Block
B1 in der Videoattributdatei 133 für das Video gespeichert. Der Wert
T_d wird vom Prozess von 4 zur
schrittweisen Multicast-Steuerung
bei einer späteren
Wiedergabe des Videos in einer anderen Sitzung verwendet. Die Videowiedergabevorrichtung
kehrt sodann zum Schritt 520 zurück, um die nächste Übertragungsrunde
vorzubereiten.
-
Es muss klar sein, dass in den 2 bis 5 die Schleifen verlassen werden und
die Multicast-Sitzung geschlossen wird, sobald der letzte Block
des Videos vom Videoserver an die Clients übertragen wurde.