-
Die
Erfindung betrifft ein Verfahren zum Übertragen von Datenströmen zwischen
einem sendenden Host und einem empfangenden Host unter Verwendung
eines Transportprotokolls, so beispielsweise des TCP-Protokolls.
-
Bei
der Kommunikation in Netzwerken zwischen einem sendenden Host und
einem empfangenden Host erfolgt die Übertragung von Datenpaketen
meistens nach dem Best-Effort-Prinzip.
Bei der Kommunikationsverbindung variieren die verfügbare Bandbreite
und die Gegebenheiten der aktuellen Verbindung, weshalb der Endhost über Mechanismen verfügen muss,
mit denen er die Gegebenheiten der aktuellen Verbindung untersuchen
und sich darauf einstellen kann.
-
Mit
der Entwicklung von Netzwerken der dritten Generation werden so
genannte Streaminganwendungen zunehmend wichtig. Unter Streaminganwendungen
versteht man hierbei kontinuierliche Datenströme, so beispielsweise Video-
oder Audiodaten, die üblicherweise
gegenüber
Zeitverzögerungen empfindlich
sind. Um einen Anwender in die Lage zu versetzen, multimediale Datenströme auf einem
tragbaren Empfänger,
so beispielsweise auf einem Mobiltelefon, zu empfangen, muss der
Transportmechanismus einige Anforderungen erfüllen, damit die übertragenen
Daten den resultierenden zeitlichen Randbedingungen genügen. In
einer nach dem Best-Effort-Prinzip arbeitenden Umgebung sind diese
Randbedingungen schwierig zu erfüllen,
was zu Bandbreitenschwankungen und Verzögerungen führt.
-
Um
dem Problem der Bandbreitenanpassung zu begegnen, ist die Erstellung
mehrerer Datenströme
mit unterschiedlichen Codierraten und dennoch gleichem Inhalt an
dem sendenden Host gängig.
Entsprechend der verfügbaren
Bandbreite wird dann zwischen den Datenströmen gewechselt, um die Rate
an die verfügbare
Bandbreite anzupassen. Mit anderen Worten, es werden Inhaltsströme (content
streams) mit mehreren Raten an dem sendenden Host übermittelt,
wobei Vorgänge
des Wechselns zwischen den Strömen
in Abhängigkeit
von der verfügbaren
Bandbreite vorgenommen werden. Der aktuelle Strom wird in einem
Stück an
den empfangenden Host weitergeleitet, weshalb für jeden Wechselvorgang die
bestehende Verbindung abgebrochen und eine neue aufge baut werden
muss. Diese Vorgehensweise ist im Ergebnis ineffizient, da sie den
Datendurchsatz senkt.
-
Alternativ
ist es möglich,
lediglich einen Datenstrom an den empfangenden Host zu übertragen und
Datenpakete in Abhängigkeit
von Prioritäten
und zeitlichen Randbedingungen auszusondern. Dies führt jedoch
zu einem Datenverlust und stellt daher keine optimale Lösung dar.
-
In
dem Beitrag „Video
Coding for Streaming Media Delivery on the Internet" von Conklin G J
FT AL, veröffentlicht
bei „IEEE
Transactions on Circuits Systems for Video Technology", IEEE Inc. New York, US,
Band 11, Nr. 3, März
2001 (2001-03), Seiten 269 bis 281, XPOO1 093477, ISBN: 1051-8215,
werden Internetstreamingmedienverteilungsnetzwerke zur per Streaming
erfolgenden Übermittlung
von Medien in einem Server-Client-Umfeld
unter Verwendung eines Transportprotokolls, so beispielsweise eines TCP-
und UDP-basierten Netzwerkprotokolls, beschrieben. Die Druckschrift
beschreibt die Notwendigkeit des skalierbaren/anpassbaren Streaming
unter Einbeziehung der Idee des Bereitstellens mehrerer Versionen
ein und desselben Inhalts mit einer Codierung für spezifische Klassen der Internetnutzerschaft.
Um die Möglichkeit
dynamischer Änderungen bei
der Kanalbandbreite und der Verluststatistik zu eröffnen, implementiert
der Server einen Mechanismus, durch den ihm mitgeteilt wird, dass
Pakete langsamer als in Echtzeit an die Clients übertragen werden und durch
den die Übertragung
einiger Pakete übersprungen
wird, um eine Neupufferung (rebuffering) oder den Verlust von Verbindungen
auf Seiten der Abspielenden zu verhindern.
-
Bei
dem in dieser Druckschrift beschriebenen System wird der Codierer
verwendet, um mehrere Darstellungen (oder Datenströme) des
für verschiedene
Gegebenheiten optimierten ursprünglichen
Inhalts zu erzeugen. Während
einer Streamingsitzung überwacht
ein Client die aktuelle Bandbreite sowie die Verluststatistik seiner
Verbindung und weist den Server an, zu demjenigen Strom zu wechseln,
dessen Übertragung über den
aktuellen Kanal mit minimaler Verzerrung des rekonstruierten Signals erfolgt.
-
Die
Druckschrift EP-A-0 786 885 betrifft ein Verfahren zum Übertragen
von Paketen von einem übertragenden
Ende an ein empfangendes Ende, wobei die Datenpakete aus einem Bitstrom
gebildet sind und über
ein Paketnetzwerk an einen empfangenden Puffer an dem Empfangsende
gesendet werden, an dem die Daten wiederum gespeichert und ausgelesen
werden. Das im Zusammenhang mit einem bevorzugten Ausführungsbei spiel
beschriebene Netzwerk ist ein ATM-Netzwerk (Asynchronous Transfer
Mode ATM, asynchroner Übertragungsmodus),
bei dem ein Datenpaket eine bestimmte Standardgröße oder Länge aufweist und einen Nutzteil sowie
einen Kopfbereich umfasst.
-
Die
Druckschrift WO 02 054284 A offenbart ein Verfahren zum Übertragen
von Videoinformation zwischen NTTP-Servern und Clients über das
Internet, wobei die Videoinformation in dem Server als Videodatei
gespeichert ist, die aus paketgeteilten Videoströmen besteht. Die Ströme sind
mit unterschiedlichen durchschnittlichen Bitraten kompressionscodiert,
wobei die Bitraten die erwarteten Kanalbitraten zur Übertragung
an den Client abdecken. Jeder Videostrom ist in Datenpakete unterschiedlicher
Länge unterteilt,
von denen jedes einen Kopfbereich und einen Nutzteil aufweist.
-
Im
Zusammenhang mit der Segmentierung des Stromes in Pakete unterschiedlicher
Längen
ist zu beachten, dass größere Pakete
einerseits zu einem geringeren Paketoverhead führen und eine Segmentierung
in große
Pakete andererseits das Intervall vergrößert, in dem der Wechsel zwischen
den Strömen
erfolgen kann.
-
Die
Aufgabe der vorliegenden Erfindung besteht darin, die Wartezeit
des Wechselvorganges zu minimieren sowie eine schnelle in den alten
Zustand erfolgende Rückkehr
für den
Fall einer unrichtigen Wechselentscheidung sicherzustellen.
-
Die
Aufgabe wird erfindungsgemäß durch ein
Verfahren gemäß Anspruch
1 gelöst.
Bevorzugte Ausführungsbeispiele
des Verfahrens sind in den abhängigen
Ansprüchen
angegeben.
-
Das
Verfahren der vorliegenden Erfindung setzt das Vorhandensein von
Inhaltsdatenströmen mit
mehreren Raten an dem sendenden Host voraus. Durch das Verfahren
der vorliegenden Erfindung wird es möglich, zwischen Datenströmen mit
variabler Segmentierung in der Anwendungsschicht je nach Anforderung
während
der Übertragung
schnell zu wechseln. Anstelle der Verwendung von Datenströmen fester
Segmentlänge
werden die für
den Socket bereitgestellten Datensegmente vor, während und nach dem Wechseln
kleiner gemacht. Für
jeden Inhalt werden mehrere Videoströme, die mit unterschiedlichen
Raten codiert sind, in dem Videoserver gespeichert. Bei normalen
Sendegegebenheiten, das heißt,
wenn beim Übertragen
ein bestimmtes Gleichgewicht eingetreten ist, in dem die Bandbreite ausreichend
ist und in dem die Verluste nicht dominieren, wird der Videoinhalt
an den sendenden TCP-Socket in Segmenten gleicher Größe (Unabhängig von
der Stromcodierrate ist die Segmentgröße eine Funktion der Verbindungen
und nicht der Codierrate) weitergereicht. Nur wenn dem Server mitgeteilt
wird, dass ein Stromwechsel erforderlich sein könnte (oder wenn der Server
hiervon auf andere Weise erfährt),
verringert er die Größe dieser
Segmente.
-
Auf
Grundlage des erfindungsgemäßen Verfahrens
sind weder eine Modifizierung der ursprünglich codierten Daten an dem
sendenden Host, noch eine Modifizierung des Transportprotokolls,
noch die Einführung
zusätzlicher
Steuermitteilungen von Nöten,
weshalb die Implementierung dieses Verfahrens einfach ist.
-
Der
Wechsel erfolgt zwischen den Datenströmen unterschiedlicher Rate,
wobei die variable Segmentierung der Datenströme um den Wechselmoment herum
vorgenommen wird. Auf diese Weise kann ein schneller Stromwechsel
von einem alten Datenstrom zu einem neuen vorgenommen werden. Darüber hinaus
wird die Segmentierung während, vor
und nach dem Wechselmoment feiner gemacht, sodass der Wechselvorgang
gegenüber
einer unrichtigen Entscheidung weniger empfindlich ist, wodurch ein
schnellerer weiterer Wechselvorgang ermöglicht wird.
-
Vorzugsweise
beinhaltet der Schritt des Wechselns zwischen Strömen eine
Rückkopplungsmitteilung
(so beispielsweise einen RTSP-Befehl), das heißt eine Kommunikation zwischen
den Hosts dahingehend, wann ein Wechselvorgang von Nöten ist,
und wann die hierfür
notwendigen Vorbereitungen, so beispielsweise eine feinere Segmentierung, getroffen
werden sollen.
-
Von
Vorteil ist darüber
hinaus, wenn die Rückkopplungsmitteilung
wenigstens einen der nachfolgenden Parameter enthält, nämlich die
Länge des
Datensegmentes, eine Kennung der zu sendenden Daten oder einen Stromsteuerbefehl,
wodurch der Betrieb glatter und weniger anfällig für Datenverluste wird.
-
Vorzugsweise
nimmt die Länge
der Datensegmente nach dem Wechselmoment zum Zwecke der Verringerung
der Schnittstellenkommunikation, das heißt zwischen der Anwendung und
dem TCP-Socket, allmählich
zu.
-
Die
vorliegende Erfindung erschließt
sich besser aus der nachfolgenden Detailbeschreibung in Zusammenschau
mit der begleitenden Zeichnung, die sich wie folgt zusammensetzt.
-
1 zeigt
die Grundarchitektur eines sendenden Hosts und eines empfangenden
Hosts, die über
ein Kommunikationsnetzwerk verbunden sind, in dem das erfindungsgemäße Verfahren
zum Einsatz kommen kann.
-
2 ist
ein Blockdiagramm einer Serverarchitektur als sendender Host, in
dem das erfindungsgemäße Verfahren
zum Einsatz kommen kann.
-
3 ist
ein Blockdiagramm einer Clientarchitektur.
-
1 zeigt
die Grundarchitektur eines Kommunikationsnetzwerkes zur Verbindung
eines Videoservers als sendender Host mit einem Videoclient als empfangender
Host. Das Kommunikationsnetzwerk ist beispielsweise ein UMTS-Kernnetzwerk,
ein externes Netzwerk, so beispielsweise das Internet oder ein internes
Inteanet, über
das der Server und der Client unter Verwendung eines Transportprotokolls miteinander
in Verbindung stehen. Als Transportprotokoll wird beispielsweise
TCP ausgewählt,
wobei sich einem Fachmann auf dem einschlägigen Gebiet unmittelbar erschließt, dass
auch andere Protokolle zur Übertragung
von Daten zum Einsatz kommen können.
-
Auf
eher allgemeine Weise wird nachstehend erläutert, wie TCP beim Austausch
von Daten zwischen dem Server und dem Client verfährt.
-
Zunächst muss
der Videoserver seine Daten an das Protokoll übertragen und hierdurch anweisen, dass
dieses die Daten an den Client sendet. Um Daten nacheinander zu
lesen und zu senden, bedient sich das Protokoll einer Art von Puffer
mit zusätzlichen
Funktionalitäten,
eines so genannten TCP-Sockets. Im Allgemeinen werden Sockets eindeutig durch
die IP-Adressen der Korrespondenten, der Protokolle und der Ports
in Verwendung identifiziert. Sobald eine Verbindung zwischen zwei
Sockets hergestellt ist, kann die Kommunikation unter Verwendung
von Schnittstellenaufrufen, darunter beispielsweise „Socket
erstellen" („create
a socket"), „Socket an
Transportadresse binden" („bind a
socket to transport adsress"), „Verbindung
annehmen" („accept
a connection"), „Verbindung
schließen" („close
a connection"), „Daten
senden" („send data"), „Daten
empfangen" („receive
data"), „Daten
schreiben" („write data"), zwischen dem Sender
und dem Empfänger gesteuert
werden.
-
Weitverbreitete
Implementierungen für
Sockets sind beispielsweise UNIX BSD 4.2 und Windows Winsock 2.0,
bei denen äquivalente
Schnittstellenaufrufe implementiert sind.
-
Jeder
Schnittstellenaufruf weist Parameter auf, so beispielsweise für den „Sende"-Aufruf, wobei zu
den wichtigen Parametern der Socketdeskriptor, die Kennung der zu
sendenden Daten und die Länge des
Datenstromes zählen.
Sobald ein Datenstrom in einem Aufruf durchgereicht wird, kann kein
einziges Bit dieses Datenstroms mehr modifiziert werden. Der einzige
Weg, die Übertragung
dieses Datenstroms zu beenden, besteht im Abbruch der Verbindung.
-
Zum
Schließen
der Verbindung muss die Anwendung gleichwohl einen „Schließe"-Aufruf ausgeben.
Schnittstellenaufrufe können
wie beim FTP in Warteschlangen eingereiht (queuing) werden. Bei Anforderung
einer Datei gibt der FTP-Server üblicherweise
zwei Schnittstellenaufrufe für
diese Übermittlung
aus, nämlich
einen den Socket, die Kennung des Datenstromes und die Länge hiervon
angebenden Aufruf „Sende" sowie einen den
Socket identifizierenden „Schließe"-Aufruf. Die beiden
Schnittstellenaufrufe werden in eine Warteschlange eingereiht. Ist
der „Sende"-Aufruf beendet,
so wird die Verbindung unwiederbringlich abgebrochen, da der „Schließe"-Aufruf als Nächstes in
der Warteschlange war.
-
Alternativ
wird die Verbindung, was beispielsweise bei TELNET der Fall ist,
hergestellt, und der Socket wird derart eingestellt, dass er auf
einlaufende Daten, so beispielsweise auf in die Tastatur eingegebene
Befehle, wartet.
-
Selbstredend
kann die Anwendung auch derart konfiguriert werden, dass der Server
lediglich einen „Sende"-Aufruf ausgibt und
dann wartet, dass der Client schließt. Dies ist jedoch nicht der
Regelfall.
-
Darüber hinaus
wird davon ausgegangen, dass das TCP-Protokoll eine Einrichtung
zum asynchronen Signalisieren bestimmter Informationen im Zusammenhang
mit Ereignissen in dem Socket umfasst. Gemäß Spezifikation ist die Information
häufig eine
Fehlermeldung. In anderen Fällen
handelt es sich um Informationen im Zusammenhang mit dem Beenden
bei der Verarbeitung eines SENDE- oder EMPFANGE-Aufrufes oder eines
anderen Schnittstellenaufrufes.
-
Wie
in 1 dargestellt ist, stellt der Videoserver beispielsweise
einen MPEG-4-komprimierten Datenstrom bereit, das heißt einen
gegebenen Videoinhalt, der dem TCP-Socket in Form von Strömen mit
einer Rate oder mit mehreren Raten zur Verfügung gestellt wird. Ströme mit mehreren
Raten werden eigens für
diesen Zweck und die nachfol gende Beschreibung als ein Datenstrom
oder mehrere Datenströme
mit demselben Videoinhalt und unterschiedlichen Codierraten festgelegt.
Die MPEG-Datenströme
werden an den TCP-Socket weitergereicht. Nachfolgend werden die
Daten über
ein IP-Protokoll an den Videoclient übertragen. Es sollte ein Stromsteuerprotokoll,
so beispielsweise RTSP, verwendet werden, um Vorgänge wie
das Abspielen, Anhalten oder Abbrechen der Übertragung auszuführen.
-
2 zeigt
die Grundarchitektur eines Videoservers 200 in einer MPEG-Serveranwendung 210, wo
der Videoinhalt in einem Puffer 211 mit unterschiedlichen
Codierraten bereitgestellt wird. Ein Wechsler beziehungsweise Schalter 212,
der Stromsteuerbefehle RTSP von einem RTSP-Block 220 empfängt, so
beispielsweise „Abspielen", „Anhalten", „Abbrechen" oder „Rate ändern", wählt einen
der Datenströme
aus, der an den TCP-Socket 230 in
Form einer MPEG-Datei weitergeleitet wird.
-
Einem
Fachmann auf dem einschlägigen Gebiet
erschließt
sich unmittelbar, dass andere Stromsteuerprotokolle als RTSP bei
Server und Client Verwendung finden können. Das Stromsteuerprotokoll
weist üblicherweise
das Wahrnehmen von Funktionen betreffend das Abspielen, Vorlaufen, Rücklaufen,
Anhalten und Abbrechen an. Ist darüber hinaus Inhalt mit mehreren
Raten verfügbar,
so kann der Wechsel zu einer höheren
oder niedrigeren Codierrate angewiesen werden.
-
Sobald
ein Server die Anforderung einer Datei mit einem Videoinhalt und
einer Codierung gewünschter
Rate empfangen hat, leitet die Serveranwendung jedes der Segmente,
in das die Datei vorab segmentiert worden ist, nacheinander mittels
konsekutiver Schnittstellenaufrufe, so beispielsweise mittels konsekutiver „Sende"-Aufrufe, an den
TCP-Socket weiter. Im Gegensatz zu aktuellen FTP-Anwendungen wird
die Verbindung nicht abgebrochen, nachdem jeder Datenübertragungsvorgang
beendet worden ist. Die Datenverbindung bleibt offen, sodass keine
Notwendigkeit besteht, immer dann eine neue Verbindung aufzubauen,
wenn ein Segment übertragen
wird. Im Anschluss hieran bildet der TCP-Socket mit diesen Segmenten
Paketdateneinheiten (packet data unit PDUs) zur Übertragung an den Client, so dies
am meisten geeignet ist.
-
Bei
Herstellung einer Verbindung wählt
der TCP-Socket eine Segmentgröße für die Datenströme aus,
die aus Sicht des Servers und unter Berücksichtigung der Kanalbandbreite
für die
Verbindung am besten geeignet ist, und beginnt mit der Übertragung.
-
Anfänglich wird
die Größe der Segmente
vor, während
und nach einem Wechselvorgang klein gemacht, um eine lange Wartezeit
zu vermeiden, bevor ein weiterer Wechselvorgang für den Fall
einer unrichtigen vorhergehenden Wechselentscheidung vorgenommen
werden kann. Anschließend
kann die Größe der Datensegmente
allmählich
während
der Verbindungszeit gesteigert werden.
-
Tritt
eine Änderung
im Zusammenhang mit der verfügbaren
Bandbreite auf, so kündigt
der Videoclient gegebenenfalls einen möglichen Wechselvorgang beispielsweise
mittels einer RTSP-Meldung an, woraufhin der Server eine feinere
Segmentierung vornimmt. Hierdurch wechselt der Server zwischen Datenströmen unterschiedlicher
Codierraten. Dies erfolgt auf Basis der Anfangsinformation sowie
unter nachfolgender Steuerung von Seiten des Clients mittels Rückkopplung.
Alternativ kann dies von Seiten des Servers bestimmt werden, was
jedoch höhere Verarbeitungsanforderungen
an den Server mit sich bringt. Auch eine Kombination von Steuermechanismen
an Server und Client ist möglich.
Die genaue Art und Weise, wie der Server oder der Client die Entscheidung
betreffend die Vornahme eines Wechselvorganges treffen, oder wie
dies bei einem möglichen bereits
bekannten Wechsler erfolgt, liegt außerhalb Schutzbereiches der
vorliegenden Erfindung.
-
Die
Grundarchitektur eines TCP-Streaming-Clients 300 ist in 3 dargestellt.
Der Client 330 umfasst üblicherweise
einen TCP-Socket 310, einen Anwendungsschichtpuffer 320 und
einen Puffermanager 330 für den Anwendungsschichtpuffer.
-
Der
Client 300 verarbeitet die Datensegmente variabler Länge so,
wie sie einlaufen. In Reaktion hierauf sendet er ACKs und nimmt
eine Flusssteuerung vor, um einen Überlauf des TCP-Sockets 310 zu verhindern,
während
die maximale durch die Verbindung ermöglichte Bitrate extrahiert
wird. Zu diesem Zweck kündigt
der TCP-Socket dem Server mittels ACK an, wie viele Daten er aufnehmen
kann, bis der Socket voll ist, und zwar unter Verwendung eines Fensterfeldes
im TCP-Kopfbereich. Gegebenenfalls signalisiert der TCP-Client ein
Nullfenster, wodurch dem Server mitgeteilt wird, in einen Wartemodus
einzutreten, in dem keine Daten gesendet werden, bis der Client
dies wieder zulässt,
solange die Verbindung erhalten bleibt. Der Wartemodus und das Signalisieren
eines Fensterfeldes sind Standardfunktionalitäten des TCP-Protokolls. Verfügt die TCP-Schaltung über größere Datenkapazitäten, so
signalisiert sie dies dem Server. Streamingsteuerbefehle werden dem
Server mittels RTSP-Befehlen signalisiert.
-
Der
Anwendungsschichtpuffer 320, auch „Play-out-Puffer" genannt, empfängt Daten
von dem Socket und übermittelt
diese an die MPEG-Clientanwendung 340. Der Manager 330 für den Anwendungsschichtpuffer 320 empfängt eine
Frameanforderung von der MPEG-Clientanwendung
und gibt eine Socketanforderung unter Berücksichtigung des Zustandes
des Anwendungsschichtpuffers aus. Der Puffermanager 320 stellt
damit sicher, dass die Bitrate, mit der der TCP-Socket 310 die
neuen Daten an den Anwendungsschichtpuffer 320 übermitteln
kann, zu der Bitrate passt, bei der der Anwendungsschichtpuffer
an die MPEG-Clientanwendung 340 geleert wird. Der genaue
Steuermechanismus des Puffermanagers liegt ebenfalls außerhalb
des Schutzbereiches der vorliegenden Erfindung.
-
Schließlich werden
die Daten von der MPEG-Clientanwendung an eine Anzeige 350 übertragen
und dort für
den Anwender sichtbar.