-
Die
vorliegende Erfindung betrifft Datenpaketübertragungen, im Besonderen
die Übertragung von
Echtzeitdaten oder echtzeitnahen Daten über International-Protocol
(IP)-Netzwerke unter
Verwendung standardisierter Protokolle.
-
Das
Echtzeit-Transportprotokoll (RTP) wird weithin für die Übertragung von Echtzeitdaten
oder echtzeitnahen Daten über
IP-Netzwerke verwendet. Es geht mit einem Begleitprotokoll einher,
das Echtzeit-Transport-Steuerprotokoll (RTCP) genannt wird und zum Überwachen
der Übertragung,
Sammeln von Statistiken und Senden von Steuerdaten in der Vorwärtsübertragungsrichtung
oder als eine Rückführung von
dem Empfänger
zurück
zu dem Sender verwendet wird.
-
RTP
beschränkt
normalerweise die Menge an Rückführung durch
zwei Regeln: Erstens wird ein bestimmter Teil (empfohlen werden
5 %) der RTP-Sitzungsbandbreite für RTCP zugewiesen. Sämtliche Empfänger teilen
sich diese Bandbreite und berechnen aus diesem Wert die Zeitdauer,
während
der sie die Rückführung senden.
Die zweite Regel besteht darin, dass das Intervall zwischen zwei
Rückführungs-Übertragungen
wenigstens fünf
Sekunden (fünf
Sekunden als der empfohlene Wert) betragen muss.
-
Zwar
machen diese Regeln RTP für
große Mehrpunkt-Gruppen
(Multicast-Gruppen) stabil und verwendbar, aber es ist nicht für Punkt-zu-Punkt- (Unicast-)
oder kleine Mehrpunkt-Übertragungen
optimiert. Bei diesen Gruppen wäre
mehr Rückführung pro
Benutzer vorteilhaft und könnte
gesendet werden. Das Problem wurde bereits erkannt. Bei einer erweiterten
Version eines neuen RTP-Protokolls entfällt die Regel, nach der das
Intervall zwischen zwei Rückführungs-Übertragungen
wenigstens fünf
Sekunden betragen muss. Somit kann der Empfänger in Abhängigkeit von den Sitzungsparametern
viel mehr Rückführung senden.
Die Regel, nach der die zugewiesene RTCP-Sitzungsbandbreite nicht überschritten
werden darf, gilt weiterhin.
-
Wie
oben erwähnt
wurde, wird der Teil der RTP-Bandbreite für die Übertragung von Steuerdaten,
der für
RTCP zugewiesen wird, im Allgemeinen auf einen empfohlenen Wert
von 5 % festgelegt. Es wird jedoch derzeit eine Lösung standardisiert,
um diesen Teil auf andere Werte zu ändern. Die Bitrate kann außerdem auf
Null eingestellt werden, um RTCP-Rückführung abzuschalten.
-
Schulzrinne
u. a.: „RTP
A Transport Protocol for Real-Time Applications", Internet Draft, 20. November 2001,
im Besonderen Kapitel 6.2 „RTCP transmission
interval", lehrt
auf Seite 18, wie die Rate zum Senden von RTCP-Empfangsmitteilungen
von den Teilnehmern einer Sitzung durch dynamisches Berechnen des
Intervalls zwischen RTCP-Paketübertragungen
zu skalieren ist. Für
jede Sitzung wird dabei angenommen, dass der Datenverkehr einer Gesamtbegrenzung
mit der Bezeichnung „Sitzungsbandbreite" unterliegt, die
unter den Teilnehmern aufzuteilen ist. Diese Bandbreite könnte reserviert
werden und die Begrenzung durch das Netzwerk durchgesetzt werden.
Die Sitzungsbandbreite kann auf Basis mancher Kosten oder der Vorkenntnis
der verfügbaren
Netzwerkbandbreite für
die Sitzung gewählt werden.
Des Weiteren wird vorgeschlagen, dass der Steuerverkehr auf einen
kleinen und bekannten Teil der Sitzungsbandbreite begrenzt sein
sollte, der klein genug ist, dass die Funktion des Transportprotokolls zum
Tragen von Daten nicht beeinträchtigt
und bekannt ist, so dass der Steuerverkehr in die Bandbreitenspezifikation
aufgenommen werden kann, die einem Ressourcenreservierungsprotokoll
verliehen wird, und so dass jeder Teilnehmer seinen Anteil unabhängig berechnen
kann. Es wird empfohlen, dass der Teil der Sitzungsbandbreite, der
RTCP zugewiesen wird, auf 5 % festgelegt wird.
-
Brown,
K.: „The
RTCP gateway: scaling real-time control bandwidth for wireless networks", COMPUTER COMMUNICATIONS,
ELSEVIER SCIENCE PUBLISHERS BV, 30. August 2000, betrifft einen
RTCP-Protokollumsetzer, der die Skalierfunktion bereitstellt, die
erforderlich ist, um drahtlosen Teilnehmern zu ermöglichen,
sich an Konferenzsitzungen hoher Bandbreite zu beteiligen. In Kapitel
3.1 wird ein Mechanismus vorgeschlagen, um Steuerbandbreite an einer
drahtlosen Verbindung zu verringern, ohne RTCP-Funktionalität zu beeinflussen.
In den folgenden Kapiteln wird dieses Konzept ausgearbeitet, wobei
auch das Verringern der Anzahl oder Größe von RCTP-Paketen beinhaltet
ist. Zusätzlich kann
das Mindest-RTCP-Mitteilungsintervall verkleinert werden, um die
Berichtsfrequenz und die Bandbreitenverwendung zu erhöhen, wenn
große
Sitzungsbandbreiten spezifiziert werden.
-
Ott
u. a.: „Extended
RTP Profile for RTCP-based Feedback (RTP-AVPF)", Internet Draft, 21. Oktober 2001,
Audio/Video Transport Working Group, betrifft die Zeitsteuerung
des Sendens von Bestätigungen/Nichtbestätigungen,
um das Mindestintervall zum Senden von RTCP-Mitteilungen unter Berücksichtigung
der Anzahl von mitzuteilenden Ereignissen zu bestimmen. Genauer
gesagt erfolgt die Zeitsteuerung der RTCP-Pakete unter Berücksichtigung
der Anzahl von Ereignissen, die mitgeteilt werden müssen, was
zur Verwendung von unmittelbaren oder frühen RTCP-Paketen in Abhängigkeit
von einer Anzahl von Parametern, einschließlich Sitzungsbandbreite, besondere
Art von Rückführung und
anderer, führt.
-
Die
Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren
zum Übertragen
von Datenpaketen unter Verwendung von RTP- und RTCP-Protokollen
mit einer erhöhten Übertragungseffizienz
bereitzustellen.
-
Diese
Aufgabe wird durch ein Verfahren nach der Darlegung in Anspruch
1 erfüllt.
Bevorzugte Ausführungen
des Verfahrens unterliegen den verschiedenen Unteransprüchen.
-
Die
vorliegende Erfindung basiert auf der Erwägung, dass die spezifische
Umgebung einer bestimmten Medien-Sitzung eine größere Flexibilität in Bezug
auf die RTCP-Bandbreite ermöglicht.
Da Steuerdaten per se die Qualität
des Medienstroms nicht erhöhen,
ist es notwendig, die RTP-Bandbreite für die Übertragung von Medien-Datenpaketen
zu optimieren, statt eine feste Menge für die Übertragung von Steuerdaten
zu verwenden. Andererseits erfordert die Übertragung von Medien-Datenpaketen, dass
eine bestimmte Menge von Steuerdaten zu senden ist. Bei der herkömmlichen
Lösung
des Zuweisens eines festen Teils von RTP-Bandbreite war die RCTP-Bandbreite
entweder zu gering, was aus dem Mindestintervall über fünf Sekunden
zwischen zwei aufeinanderfolgenden RTCP-Paketen resultierte, oder
größer als
benötigt.
-
Zum
Beispiel führen
bei einer Punkt-zu-Punkt-Medien-Sitzung die 5 % der RTP-Sitzungsbandbreite,
die RTCP zugewiesen werden, zu einer Übertragungszeitdauer für die Steuer-Datenpakete
von nur wenigen Millisekunden. Je nach der Bitrate des Senders kann
die Zeitdauer außerdem
in dem Bereich von mehreren Sekunden liegen. Folglich wird zugewiesene
Bandbreite verschwendet und im Besonderen wird bei Verbindungen, bei
denen Bandbreite eine wertvolle Ressource ist, wie z. B. bei drahtlosen
Verbindungen, die Effizienz der Übertragung
in hohem Maße
verringert. Andererseits benötigen
im Besonderen drahtlose Verbindungen eine schnelle Rückführung, um
z. B. den Codec an schwankende Verbindungsbedingungen anzupassen
und dem Sender zu signalisieren, dass erneute Übertragung von Medien-Datenpaketen
erforderlich ist.
-
Das
Verfahren der vorliegenden Erfindung konzentriert sich auf die Idee,
die tatsächlich
benötigte
RTCP-Bandbreite zu bestimmen, die auf Basis bekannter Verbindungsparameter
für eine
einzelne Medien-Sitzung bestimmt wird. Die bestimmte Bandbreite
wird dann für
die Übertragung
von Steuer-Datenpaketen verwendet, während Medien-Datenpakete unter
Verwendung der verbleibenden verfügbaren Bandbreite übertragen
werden. Auf diese Weise wird eine optimierte Bandbreitenzuweisung
mit maximaler Effizienz zur Übertragung
von Medien-Datenpaketen und Zuweisung von RTCP-Bandbreite in einer
ausreichenden Form zum Bereitstellen von Steuerdaten mit einer angemessenen
Rate erzielt. Somit kann unterschiedliche optimierte Bandbreitenzuweisung,
die zu effizientesten Übertragungen
führt,
für jeweilige unterschiedliche
Verbindungen erreicht werden.
-
Nach
einer bevorzugten Ausführung
des Verfahrens umfasst der Schritt des Bestimmens der benötigten RTCP-Bandbreite
den Schritt des Berechnens einer durchschnittlichen Rate und/oder
der Größe der Steuer-Datenpakete.
Zwar ist bei den meisten Fällen
die Größe der Steuer-Datenpakete
festgelegt, aber sie kann außerdem
variabel sein. In diesen Fällen
wird die durchschnittliche Größe vorteilhafterweise
zum Berechnen der benötigten
RTCP-Bandbreite verwendet.
-
Vorzugsweise
werden die Medien-Datenpakete von einem Sender zu einem Empfänger übertragen
und die Steuer-Datenpakete werden als eine Rückführung in der entgegengesetzten
Richtung gesendet.
-
Nach
einer weiteren bevorzugten Ausführung
wird die benötigte
RTCP-Bandbreite (in Bit pro Sekunde) als das Produkt der Größe des Rückführungs-Paketes
und der Rückführungs-Rate
berechnet.
-
Vorzugsweise
wird der erforderliche RTCP-Bandbreitenteil als die RTCP-Bandbreite
dividiert durch die RTP-Bandbreite berechnet. Dieser Teil wird vorzugsweise
während
des Sitzungsaufbaus, z. B. in dem Sitzungsbeschreibungsprotokoll, bestimmt
oder ausgehandelt. Alternativ wird, wenn eine Sitzung bereits eingerichtet
wurde, die laufende Sitzung abgebrochen und es wird eine neue Sitzung aufgebaut.
Als eine weitere Variante könnte
er außerdem
während
einer laufenden Übertragung
signalisiert werden.
-
Im
Folgenden wird die Erfindung ausführlicher beschrieben.
-
Zuerst
wird erläutert,
wie die erforderliche RTCP-Bandbreite auf Basis bekannter Verbindungs- und
Anwendungsparameter bestimmt wird. Wie zuvor erwähnt wurde, ist die RTCP-Bandbreite
für die Medien-Sitzung
und ihre Netzwerk-Verbindungsbedingungen spezifisch. Im Folgenden
werden Beispielszenarien beschrieben, wobei jedes Erfordernisse
für Steuerdaten
aufweist, die Rückführung von dem
Empfänger
zu dem Sender sind.
-
Die
Steuerdaten umfassen vorzugsweise Informationen zu dem Typ von Ereignis,
der dem Sender durch den Empfänger
mitgeteilt wird. Ein typisches Beispiel für ein mitzuteilendes Ereignis
sind der akkumulierte Paketverlust oder andere statistische Daten,
die von dem Empfänger
gesendet werden. Diese Information wird bei dem Medien-Codec als
ein Eingang zum Bestimmen oder Einstellen des Codierungsalgorithmus
verwendet und wird typischerweise in regelmäßigen Intervallen mitgeteilt, wie
z. B. ein Mal pro Umlaufzeit. Für
diesen Typ regelmäßiger Ereignisse
ist die Rückführungs-Rate
bereits durch die Anwendung, die die Rückführung verwendet, vorgegeben.
Es kann sein, dass außerdem zusätzliche
Verbindungscharakteristiken (z. B. Umlaufzeit) berücksichtigt
werden müssen.
-
Ein
anderer Typ von Ereignis ist beispielsweise der spezifische Paketverlust,
der dem Sender so bald wie möglich
nach der Verlusterfassung signalisiert werden sollte. Wenn der Paketverlust
mitgeteilt wird, kann der Sender die Fehlerkompensation erhöhen, wie
z. B. durch Senden einer Intra-Frame-Auffrischung in einem Videocodierer
oder durch Einleiten erneuter Übertragung
von Medien-Datenpaketen. Für
diesen Typ von Ereignis ist es nützlich,
eine durchschnittliche Paketrate und eine durchschnittliche Verlustrate
zu bestimmen.
-
Ein
weiterer Typ von Ereignis ist eine positive oder negative Bestätigung eines
empfangenen Datenpakets. Dieses Ereignis sollte ebenfalls so bald wie
möglich
signalisiert werden, um Eingang für den Sender bereitzustellen,
die Fehlerkompensation des Medien-Codecs zu senken/erhöhen und
die Effizienz der Übertragung
einzustellen, wie zum Beispiel durch Verringern/Erhöhen von
Redundanz oder Verändern der Übertragungsrate.
Für diesen
Typ von Ereignis muss lediglich die mittlere Paketeingangsrate bekannt
sein.
-
Zum
korrekten Berechnen der erforderlichen RTCP-Bandbreite ist zu bevorzugen,
die Größe der Rückführungs-Pakete
zu kennen. Zwar ist bei den meisten Anwendungen die Paketgröße während der Sitzung
festgelegt, aber sie kann außerdem
variabel sein, wie z. B. in Fällen
von Verlustereignissen, wobei es mehr als ein mitzuteilendes Verlustereignis
in einem Rückführungs-Paket
geben kann. Folglich sollte ein durchschnittlicher Wert der Rückführungs-Paketgröße verwendet
werden.
-
Mit
der Größe der Rückführungs-Pakete, s_fb
[bit], und der Rückführungs-Rate,
r_fb [1/s], kann die benötigte
durchschnittliche RTCP-Bandbreite (in Bit pro Sekunde) als bw_rtcp
= s_fb·r_fb
berechnet werden.
-
Die
RTP-Sitzungsbandbreite bw_rtp ist für die Dauer der Sitzung festgelegt.
Eine Berechnung des RTCP-Bandbreitenteils ergibt sich aus: f_rtcp
= bw_rtcp/bw_rtp.
-
Der
berechnete Bandbreitenteil kann entweder bestimmt oder zwischen
dem Empfänger
und dem Sender während
des Sitzungsaufbaus ausgehandelt werden, wobei in diesem Fall der
Bandbreitenteil in dem Sitzungsbeschreibungsprotokoll (SDP) signalisiert
wird. Wenn eine Sitzung bereits eingerichtet wurde, kann sie abgebrochen
werden und es muss eine neue Sitzung aufgebaut werden. Alternativ
ist es möglich,
den berechneten RTCP-Bandbreitenteil gleichzeitig während einer
laufenden Übertragung
zu signalisieren.
-
Das
neue RTP-Protokoll macht erforderlich, die Rückführungs-Mitteilung in regelmäßigen Intervallen
zu planen. Jedoch sind Ausnahmen in Form von „Frühpaketen" möglich,
d. h. dass es, wenn das letzte gesendete Rückführungs-Paket ein regulär geplantes war,
gestattet ist, ein Frühpaket
sofort zu senden. In diesem Fall muss das nächste planmäßige Rückführungs-Paket auf einen späteren Zeitpunkt verschoben
werden, um im Durchschnitt die bestimmte RTCP-Bandbreite nicht zu überschreiten.
-
Die
Mechanismen von Frühpaketen
ermöglichen
einem gut konfigurierten System, die Rückführung nahezu ohne Verzögerung zu
senden. Im Durchschnitt wird die Rückführung mit der bestimmten Rückführungs-Rate
gesendet, wobei die tatsächlichen
Zeitpunkte durch die Frühpakete
(d. h. die Ereignisse selbst) oder die regulär geplante Rückführung bestimmt
werden. Auf diese Weise wird der Verwaltungsaufwand auf einem Minimum
gehalten.