-
Gebiet der
Erfindung
-
Die
Erfindung betrifft ein Verfahren zum Bereitstellen von RTCP-Feedback-Nachrichten
für Datenpakete
wenigstens einer Streaming-Session von einem Client für einen
Streaming-Server, wobei die wenigstens eine Streaming-Session unter
Verwendung eines RTP-Protokolls sowie des RTCP-Protokolls bereitgestellt wird.
Darüber
hinaus wird den RTCP-Feedback-Nachrichten eine RTCP-Bandbreite zugewiesen,
die ein Bruchteil der verfügbaren
Bandbreite der Streaming-Session ist. Darüber hinaus betrifft die Erfindung
einen Client in einem Mobil-Kommunikationssystem, der dieses Verfahren
durchführt.
-
Zugrunde liegender
Stand der Technik
-
Das
3GPP (3rd Generation Partnership Project) übernimmt nach IETF (Internet
Engineering Task Force) standardisierte Protokolle wie beispielsweise
RTP, UDP, IP für
den Transport und Paketvermittlungs-Codecs wie beispielsweise AMR
(Adaptive Multi-Rate) und H.264 (MPEG 4 Teil 10) zum Codieren von Medien.
Die gemäß 3GPP paketvermit
telten Streaming-Dienste (siehe „Universal Mobile Telecommunications System
(UMTS); Transparent End-to-End streaming service; Protocols and
codecs", 3GPP TS
26.234 Version 6.1.0, September 2004, verfügbar auf http://www.3gpp.org)
nutzen den Protokollstapel RTP/UDP, um Audio-/Video-/Text-Media über Streaming
bereitzustellen.
-
RTP
ist ein Echtzeit-Transportprotokoll (siehe Schulzrinne et al., „RTP: A
Transport Protocol for Real-Time Applications", RFC 3550, Juli 2003, alle IETF-RFCs
und Internet Drafts unter http://www.ietf.org verfügbar), das
hauptsächlich
für Echtzeit-
oder Quasi-Echtzeit-Kommunikation,
also für
Kommunikation mit weniger restriktiven Einschränkungen der Verzögerung,
genutzt wird. Es stellt Informationen über die Zeitsteuerung der Medien
bereit, die es transportiert, und ermöglicht darüber hinaus ein Neuordnen und
Neuzusammensetzen beim Empfänger.
-
Ein
integrierter Teil des Protokolls ist das Echtzeitsteuerungsprotokoll
RTCP (Real Time Control Protocol), das minimale Empfangsinformationen
sowie lose Gruppenmitgliedschaft bietet. RTP wird im Allgemeinen
zusammen mit dem RTP/AVP-Profil genutzt (siehe Schulzrinne et al., „RTP Profile
for Audio and Video Conferences with Minimal Control", RFC 3551, Juli
2003), das neben einfachen RTCP-Feedback-Zeitsteuerungsregeln auch die Nutzung
der RTP-Header-Felder und Mappingtabellen für Nutzdatenarten definiert.
Dem RTCP-Protokoll wird ein Bruchteil der verfügbaren RTP-Bandbreite zugewiesen,
um auf faire Weise mit dem Datenverkehr auf TCP/IP-Basis in Wettbewerb
zu treten.
-
UDP
(Postel, „User
Datagram Protocol",
RFC 768, August 1980) ist das Benutzer-Datagramm-Protokoll, das für den Transport
von RTP-Paketen genutzt wird. UDP wird üblicherweise dann eingesetzt,
wenn eine unzuverlässige
Kommunikation für
das jeweilige Medium geeignet ist, wie dies bei Streaming-Anwendungen der
Fall ist. Der Protokollstapel RTP/UDP wird deswegen genutzt, weil
die Einschränkungen
der Zeitsteuerung der Medien keine zuverlässige Kommunikation ermöglichen,
zum Beispiel durch Verwendung des Übertragungssteuerungsprotokolls
TCP (Transmission Control Protocol).
-
Bei
dem RTP werden Paketierungsschemata (Nutzdatenformate) für bestehende
Medienformate (Codecs) von der Arbeitsgruppe „Internet Engineering Task
Force Audio/Video Transport Working Group" (IETF AVT WG) spezifiziert. So gibt
es beispielsweise ein Nutzdatenformat für Sprachdaten, die mit AMR
verschlüsselt
wurden, und ein weiteres für
H.264-Videodaten. Ein in Rey et al., „RTP Retransmission Format", Internet Draft,
IETF AVT Workgroup, August 2003, definiertes RTP-Nutzdatenformat
ermöglicht
darüber
hinaus eine erneute Übertragung
der RTP-Pakete in diesem System. Dies kann insbesondere für 3GPP-PSS-Streaming-Dienste
nützlich
sein.
-
Wie
in dem Dokument „RTP
Retransmission Payload Format" von
Rey et al. spezifiziert, beruht der zum Ausgeben mehrfacher Sendewiederholungen
genutzte Mechanismus darauf, dass der Client die Anforderung nur
nach Bedarf ausgibt. Der Client muss die in Ott et al., „Extended
RTP Profile for RTCP-based Feedback (RTP/AVPF)", Internet Draft, IETF AVT Workgroup,
August 2004 spezifizierten Feedback-Möglichkeiten nutzen. Es können darüber hinaus
andere Bericht-Blöcke
wie beispielsweise die von Friedman et al. in „RTP Control Protocol Extended
Reports (RTCP XR)" (siehe
RFC 3611, November 2003) definierten Berichts-Blöcke genutzt werden.
-
Die
Berichthäufigkeit
kann mit der Standard-RTCP-Berichtintervall-Berechnung berechnet
werden, die in RFC 3550 (siehe Abschnitt 6.3 und Anhang) spezifiziert
ist. Die Abdeckung der Empfängerberichte,
das heißt,
die Anzahl der berichteten Pakete, ist nicht spezifiziert. Der Client
nutzt General-NACK (Negative ACKnowledgement)-Feedback-Mitteilungen, wie
in dem RTP/AVPF-Profil spezifiziert (draft-ietf-avt-rtcp-feedback-11.txt,
unter http://www.ietf.org/internet-drafts/ zu erhalten). Es ist
darauf hinzuweisen, dass der Client keine Pakete bestätigen kann,
die das RTP/AVPF-Profil nutzen, da darin keine Bestätigungsmitteilungen (ACK-Mitteilungen)
spezifiziert sind. Somit wurden keine Vorkehrungen für umfassendes
Berichten, beispielsweise durch Verwenden von RLE-Berichten, getroffen.
-
Darüber hinaus
sind die Loss-RLE-Berichte wie in RFC 3611 definiert, erweiterte
Bericht-Blöcke,
die komprimiert werden können
und standardmäßig ACKs
und NACKs kombinieren, das heißt,
sie können über verlorengegangene
und empfangene Pakete berichten. Diese Berichte wurden für die Netzwerk-Wartung,
Abrechnung, Multicast-Baumableitung
und Sammlung statistischer Daten spezifiziert.
-
Ein
drittes Dokument, das sich mit Loss-RLE-Berichten und Unicast-RTCP-Berichten
befasst, ist das 3GPP-System paketvermittelter Streaming-Dienste
(Packet Switched Streaming Services – PSS). Gemäß diesem Dokument wird empfohlen,
dass Streaming-Clients die Nutzung von Loss-RLE-Bericht-Blöcken implementieren
und redundant über
vergangene RTCP-Intervalle berichten. Darüber hinaus ist zu bemerken,
dass diese Berichte nicht zum Auslösen von Sendewiederholungen
gemäß dem 3GPP-PSS-System genutzt werden
sollten.
-
Redundantes
Berichten in dem Kontext des 3GPP-PSS-Systems wird als das Ermöglichen
einer Mindestanzahl von Berichten über verlorengegangene Datenpakete
vor oder nach der Bearbeitung verstanden. Es gibt jedoch keine Spezifizierung
darüber,
wie dieser Mechanismus an dem Client implementiert werden soll und
wie dieser Mechanismus zusammen mit RTP-Sendewiederholungs-Anforderungen
genutzt werden soll. Redundantes Berichten verlorengegangener Pakete
ist wünschenswert,
da Feedback, das heißt
RTCP-Mitteilungen, üblicherweise
mit unbestätigten
und somit unzuverlässigen
Transportprotokollen wie UDP gesendet werden. Daher kann das von
den Empfängern
einer Session bereitgestellte Feedback verlorengehen, insbesondere
wenn das Bereitstellen der Dienste über drahtlose Zugangsnetze
wie beispielsweise UMTS in Betracht gezogen wird.
-
Wie
oben angegeben, erfordert das PSS-System, dass Loss-RLE-Bericht-Blöcke (RFC
3611) ausschließlich
für Abrechnungs-
und Netzübennrachungszwecke
genutzt werden, wogegen General-NACK-Mitteilungen (RTP/AVPF-Profil)
genutzt werden sollen, um tatsächlich
Sendewiederholungen der verlorengegangenen Datenpakete auszulösen. Das
PSS-System erfordert also, dass das RTCP-Feedback einer Transport-Session
General-NACK- und Loss-RLE-Bericht-Blöcke umfasst, um das Auslösen von
Sendewiederholungen und gleichzeitig (beispielsweise) Abrechnung
und Netzüberwachung
zu ermöglichen.
-
Die
von Rey et al. beschriebenen Mehrfachsendealgorithmen nutzen zum
Auslösen
einer Paket-Sendewiederholung Mitteilungsformate (oder können diese
nutzen), die in dem Dokument RTP/AVPF Draft von Ott et al. beschrieben
werden, also General-NACKs.
-
Sollen
sowohl die empfangenen als auch die nicht empfangenen Pakete berichtet
werden, wie von dem 3GPP-PSS-System empfohlen, kann dies bedeuten,
dass diese Bericht-Blöcke
einen erheblichen Overhead aufbauen, so dass die dem RTPC zugewiesene
vorbehaltene Bandbreite möglicherweise
nicht ausreichend ist, um über
die angeforderte Zeitspanne zu berichten und somit kontinuierliches
Nutzen und/oder Redundanz der Berichte wie erforderlich zu garantieren.
Um darüber
hinaus auch Abrechnungs- und Netzüberwachungsdienste parallel
zu dem Auslösen
der Sendewiederholung zu ermöglichen,
muss das Feedback der Clients, die eine PSS-Session empfangen, redundante
Bericht-Blöcke
(Loss-RLE-Bericht-Blöcke)
enthalten, was ebenfalls einen Overhead hervorruft und die Bericht-Frequenz
und dadurch die Stufe des redundanten Berichtens beeinflusst, die
bereitgestellt werden kann.
-
Zusammenfassung
der Erfindung
-
Es
ist daher die Aufgabe der Erfindung, ein Verfahren zum Optimieren
von RTCP-Feedback
in einer Unicast-Session zu spezifizieren.
-
Die
Aufgabe der Erfindung wird durch die Gegenstände der unabhängigen Ansprüche gelöst. Bevorzugte
Ausführungsformen
sind Gegenstand der abhängigen
Ansprüche.
-
Eine
Ausführungsform
der Erfindung betrifft ein Verfahren zum Bereitstellen von RTCP-Feedback-Nachrichten
für Datenpakete
wenigstens einer Streaming-Session von einem Client für einen
Streaming-Server, wobei die wenigstens eine Streaming-Session unter
Verwendung eines RTP-Protokolls sowie des RTCP-Protokolls bereitgestellt
wird. Gemäß diesem
Verfahren kann der Client zunächst
bestimmen, ob eine maximale Anzahl von Sendewiederholungen für ein Datenpaket,
das innerhalb der Session-Einschränkungen
der Streaming-Session bereitstellbar ist, größer ist als eine minimale Anzahl
von Sendewiederholungen, die durch den Client zu ermöglichen
sind. Ist dies der Fall, können
einem RTCP-Feedback-Paket zum Anfordern der Sendewiederholung verlorengegangener
Datenpakete eine Anzahl von General-NACK-Bericht-Blöcken hinzugefügt werden.
Die zusätzliche
Anzahl von General-NACK-Bericht-Blöcken ermöglicht die minimale Anzahl
von Sendewiederholungen der verlorengegangenen Datenpakete innerhalb
einer Client-Buffer-Zeit. Anschließend kann der Client die maximale
Größe von RTCP-Feedback-Nachrichten
bestimmen, die mit Blick auf die Session-Einschränkungen zulässig sind, und kann dem RTCP-Feedback-Paket
eine Anzahl von Loss-RLE-Bericht-Blöcken zum Berichten über verlorengegangene
Datenpakete hinzufügen,
so dass die Größe des resultierenden
RTCP-Feedback-Paketes die maximale Größe von RTCP-Feedback-Nachrichten nicht übersteigt.
Darüber
hinaus kann der Client das RTCP-Feedback-Paket als eine RTCP-Feedback-Nachricht
zu dem Streaming-Server senden.
-
Eine
weitere Ausführungsform
der Erfindung betrifft ein Verfahren zum Bereitstellen von RTCP-Feedback-Nachrichten
für Datenpakete
wenigstens einer Streaming-Session von einem Client für einen
Streaming-Server. In dieser Ausführungsform
wird wenigstens eine Streaming-Session unter Verwendung eines RTP-Protokolls
sowie des RTCP-Protokolls
bereitgestellt, und eine RTCP-Bandbreite, die ein Bruchteil der
verfügbaren Bandbreite
der Streaming-Session ist, wird den RTCP-Feedback-Nachrichten zugewiesen.
-
Der
Client kann Session-Beschreibungsinformationen empfangen, die Folgendes
anzeigen: die RTCP-Bandbreite für
die RTCP-Feedback-Nachrichten, eine minimale Anzahl von Sendewiederholungen,
die innerhalb der Client-Buffer-Zeit zu ermöglichen ist, eine minimale
Bericht-Redundanz für
verlorengegangene Datenpakete der wenigstens einen Streaming-Session
sowie die Client-Buffer-Zeit. Darüber hinaus kann der Client
die maximale Anzahl von Sendewiederholungen für ein Datenpaket bestimmen,
das auf Basis der Client-Buffer-Zeit und eines RTCP-Berichtintervalls
bereitstellbar ist. Das RTCP-Berichtintervall
kann somit von einer durchschnittlichen Größe von RTCP-Feedback-Nachrichten und der
dem Client zugewiesenen RTCP-Bandbreite abhängig sein.
-
Der
Client kann darüber
hinaus bestimmen, ob die maximale Anzahl von Sendewiederholungen
größer ist
als oder genauso groß wie
die minimale Anzahl von Sendewiederholungen, und wenn dies der Fall
ist, kann er einem RTCP-Feedback-Paket zum Anfordern der Sendewiederholung
verlorengegangener Datenpakete eine Anzahl von General-NACK-Bericht-Blöcken hinzufügen. Diese
Anzahl von General-NACK-Bericht-Blöcken, die
zu dem RTCP-Feedback-Paket hinzugefügt wurde, kann die minimale
Anzahl von Sendewiederholungen der verlorengegangenen Datenpakete
innerhalb der Client-Buffer-Zeit ermöglichen.
-
Der
Client kann darüber
hinaus die maximale Größe von RTCP-Feedback-Nachrichten,
die unter Berücksichtigung
der zugewiesenen RTCP-Bandbreite zulässig ist, sowie die Client-Buffer-Zeit
und die minimale Anzahl von Sendewiederholungen bestimmen und er
kann eine resultierende durchschnittliche Größe von RTCP-Feedback-Nachrichten
auf Basis der durchschnittlichen Größe zuvor gesendeter RTCP-Feedback-Nachrichten
sowie die Größe des RTCP-Paketes
bestimmen, das die Anzahl von General-NACK-Bericht-Blöcken umfasst.
-
Darüber hinaus
kann der Client dem RTCP-Feedback-Paket zum Berichten der verlorengegangenen Datenpakete
eine Anzahl von Loss-RLE-Bericht-Blöcken hinzufügen, wenn die Größe des resultierenden RTCP-Feedback-Paketes
die maximale Größe von RTCP-Feedback-Nachrichten
nicht übersteigt,
und er kann das RTCP-Feedback-Paket als eine RTCP-Feedback-Nachricht
von dem Client zu dem Streaming-Server senden.
-
In
einer weiteren Ausführungsform
der Erfindung werden die Loss-RLE-Bericht-Blöcke dem RTCP-Feedback-Paket
zum Zweck der Abrechnung oder der Netzüberwachung hinzugefügt.
-
In
einer weiteren Ausführungsform
wird die Anzahl von Loss-RLE-Bericht-Blöcken einer Lauflängencodierung
unterzogen, bevor bestimmt wird, ob die Größe des resultierenden RTCP-Feedback-Paketes
einschließlich
der Lauflängencodierung
unterzogenen Loss-RLE-Bericht-Blöcke die
maximale Größe von RTCP-Feedback-Nachrichten
nicht übersteigt.
Indem die Loss-RLE-Bericht-Blöcke
einer Lauflängencodierung unterzogen
werden, kann ihre Größe verringert
werden, während
die Bericht-Redundanz, die mit der jeweiligen Anzahl von Bericht-Blöcken bereitgestellt
werden kann, konstant bleibt.
-
In
einer weiteren Ausführungsform
kann der Client entscheiden, die minimale Bericht-Redundanz zu verringern,
die durch die Session-Beschreibungsinformationen von dem Client
konfiguriert wurde. Es sind verschiedene Möglichkeiten zum Verringern
der Bericht-Redundanz über
verlorengegangene Pakete absehbar.
-
So
kann beispielsweise der Client in einer Variation dieser Ausführungsform
die Uplink-Dienstgüte bestimmen,
die für
Pakete der Streaming-Session bereitgestellt wird, und auf Basis
dieser gemessenen oder bestimmten Dienstgüte (quality of service – QoS) wird
die minimale Bericht-Redundanz beispielsweise dann verringert, wenn
die bestimmte Dienstgüte über einem
vorgegebenen Schwellenpegel liegt.
-
In
einer anderen Variation ist es absehbar, dass die Bericht-Redundanz
durch den Client verringert wird, indem die Größe der Anzahl von Loss-RLE-Bericht-Blöcken verringert
wird.
-
Umfassen
beispielsweise die Daten der Streaming-Session eine Basis-Datenschicht,
die eine Basisqualität
von Streaming-Media und wenigstens eine Verbesserungsschicht zum
Verbessern der Basisqualität von
Streaming-Media umfasst, kann die Größe der Anzahl von Loss-RLE-Bericht-Blöcken verringert
werden, indem nur Informationen eingeschlossen werden, die sich
auf Datenpakete beziehen, die Daten der Basis-Datenschicht innerhalb der Loss-RLE-Bericht-Blöcke einschließen.
-
So
seien beispielsweise die Daten der wenigstens einen Streaming-Session
ein MPEG-Stream
und umfasst die Basis-Datenschicht I-Frames und die wenigstens eine
Verbesserungsschicht umfasse P-Frames und/oder B-Frames. In diesem
Beispiel kann der Client sicherstellen, dass über I-Frames berichtet wird,
während über P-Frames
und/oder B-Frames, die einen geringeren Einfluss auf die wahrgenommene
QoS des Streams des Clients haben, nur berichtet wird, wenn dies
innerhalb der durch die Session-Beschreibungsinformationen eingestellten
Session-Einschränkungen
möglich
ist.
-
In
dieser Hinsicht kann der Client bestimmen, ob ein verlorengegangenes
Datenpaket Daten der Basis-Datenschicht umfasst, die auf bereits
bei dem Client empfangenen Datenpaketen basieren.
-
Eine
weitere Möglichkeit
zum Verringern der Größe der Anzahl
von Loss-RLE-Bericht-Blöcken gemäß einer
weiteren Variation der Ausführungsform
ist das Ausdünnen
des Loss-RLE-Bericht-Blockes oder der Loss-RLE-Bericht-Blöcke.
-
Bei
einer weiteren Variation der Ausführungsform ist es des Weiteren
abzusehen, dass die Größe der Anzahl
von Loss-RLE-Bericht-Blöcken
durch Verringern der Anzahl von in dem RTCP-Feedback-Paket berichteten
Loss-RLE-Bericht-Blöcken
verringert wird.
-
Idealerweise
ermöglicht
in einer weiteren Ausführungsform
der Erfindung die Anzahl von Loss-RLE-Bericht-Blöcken, die zu dem RTCP-Feedback-Paket
zu addieren sind, minimale Bericht-Redundanz der verlorengegangenen
Pakete.
-
Darüber hinaus
ist in einer weiteren Ausführungsform
der Erfindung abzusehen, dass ein MIME-Parameter der Streaming-Session
die Paket-Rate anzeigt. Dieser Parameter kann beispielsweise beim
Schätzen der
durchschnittlichen Anzahl der Pakete einer Streaming-Session, die
innerhalb eines RTCP-Berichtintervalles berichtet werden müssen, nützlich sein.
-
In
einer weiteren Ausführungsform
der Erfindung kann der Client auf Basis der Sequenznummern von bei
dem Client empfangenen Datenpaketen bestimmen, welche Pakete der
Streaming-Session verlorengegangen sind.
-
Eine
weitere Ausführungsform
der Erfindung betrifft einen Client in einem Mobil-Kommunikationssystem,
das RTCP-Feedback-Nachrichten für
Datenpakete wenigstens einer Streaming-Session von einem Client zu
einem Streaming-Server sendet. Erneut wird die wenigstens eine Streaming-Session
unter Verwendung eines RTP-Protokolls sowie des RTCP-Protokolls
bereitgestellt, und eine RTCP-Bandbreite, die ein Bruchteil der verfügbaren Bandbreite
der Streaming-Session ist, wird den RTCP-Feedback-Nachrichten zugewiesen.
Der Client gemäß dieser
Ausführungsform
der Erfindung kann einen Empfänger
zum Empfangen von Session-Beschreibungsinformationen umfassen, wobei
die Session-Beschreibungsinformationen die RTCP-Bandbreite für die RTCP-Feedback-Nachrichten,
eine minimale Anzahl von Sendewiederholungen, die innerhalb der
Client-Buffer-Zeit zu ermöglichen
ist, eine minimale Bericht-Redundanz für verlorengegangene Datenpakete
der wenigstens einen Streaming-Session sowie die Client-Buffer-Zeit anzeigen,
des Weiteren kann er eine Verarbeitungseinrichtung umfassen, die
zum Bestimmen der maximalen Anzahl von Sendewiederholungen für ein auf
Basis der Client-Buffer-Zeit und eines RTCP-Berichtintervalls bereitstellbares
Datenpaket, wobei das RTCP-Berichtintervall von einer durchschnittlichen
Größe von RTCP-Feedback-Nachrichten und der
dem Client zugewiesenen RTCP-Bandbreite abhängt, und zum Bestimmen dient,
ob die maximale Anzahl von Sendewiederholungen größer ist
als oder genauso groß wie
die minimale Anzahl von Sendewiederholungen.
-
Die
Verarbeitungseinrichtung kann darüber hinaus dafür eingerichtet
sein, einem RTCP-Feedback-Paket
zum Anfordern der Sendewiederholung verlorengegangener Datenpakete
eine Anzahl von General-NACK-Bericht-Blöcken hinzuzufügen, wobei
die Anzahl von General-NACK-Bericht-Blöcken, die zu dem RTCP-Feedback-Paket
hinzugefügt
ist, die minimale Anzahl von Sendewiederholungen der verlorengegangenen
Datenpakete innerhalb der Client-Buffer-Zeit ermöglicht, und sie kann zum Bestimmen
der maximalen Größe von RTCP-Feedback-Nachrichten
eingerichtet sein, die unter Berücksichtigung
der zugewiesenen RTCP-Bandbreite, der Client-Buffer-Zeit sowie der
minimalen Anzahl von Sendewiederholungen zulässig ist, wenn die maximale
Anzahl von Sendewiederholungen größer ist als oder genauso groß wie die
minimale Anzahl von Sendewiederholungen.
-
Die
Verarbeitungseinrichtung kann darüber hinaus dafür eingerichtet
sein, eine resultierende durchschnittliche Größe von RTCP-Feedback-Nachrichten
auf Basis der durch schnittlichen Größe zuvor gesendeter RTCP-Feedback-Nachrichten
und der Größe des RTCP-Paketes,
das die Anzahl von General-NACK-Bericht-Blöcken umfasst, zu bestimmen,
und dem RTCP-Feedback-Paket zum Berichten der verlorengegangenen
Datenpakete eine Anzahl von Loss-RLE-Bericht-Blöcken hinzuzufügen, wenn
die Größe des resultierenden
RTCP-Feedback-Paketes die maximale Größe von RTCP-Feedback-Nachrichten nicht übersteigt.
-
Der
Client kann darüber
hinaus einen Sender zum Senden des RTCP-Feedback-Paketes als einer RTCP-Feedback-Nachricht
zu dem Streaming-Server umfassen.
-
Eine
weitere Ausführungsform
betrifft den Client und umfasst darüber hinaus eine Einrichtung,
die dafür
eingerichtet ist, das Verfahren gemäß einer der verschiedenen Ausführungsformen
wie oben beschrieben und von ihren Variationen durchzuführen.
-
Darüber hinaus
betrifft eine weitere Ausführungsform
der Erfindung ein computerlesbares Medium zum Speichern von Befehlen,
die, wenn sie von einem Prozessor eines Clients in einem Mobil-Kommunikationssystem
ausgeführt
werden, den Client veranlassen, RTCP-Feedback-Nachrichten für Datenpakete
wenigstens einer Streaming-Session von einem Client für einen
Streaming-Server bereitzustellen. Erneut wird die wenigstens eine
Streaming-Session unter Verwendung eines RTP-Protokolls sowie des
RTCP-Protokolls
bereitgestellt, und eine RTCP-Bandbreite, die ein Bruchteil der
verfügbaren
Bandbreite der Streaming-Session ist, wird den RTCP-Feedback-Nachrichten
zugewiesen.
-
Der
Client kann veranlasst werden, RTCP-Feedback-Nachrichten für Datenpakete
wenigstens einer Streaming-Session von einem Client für einen
Streaming-Server bereitzustellen, indem Session-Beschreibungsinformationen
an dem Client empfangen werden, in denen die Session-Beschreibungsinformationen
die RTCP-Bandbreite für
die RTCP-Feedback-Nachrichten für
die RTCP-Feedback-Nachrichten, eine minimale Anzahl von Sendewiederholungen,
die innerhalb der Client-Buffer-Zeit zu ermöglichen ist, eine minimale
Bericht-Redundanz für
verlorengegangene Datenpakete der wenigstens einen Streaming-Session
sowie die Client-Buffer-Zeit anzeigen, indem die maximale Anzahl
von Sendewiederholungen für
ein Datenpaket auf Basis der Client-Buffer-Zeit und eines RTCP-Berichtintervalls
bestimmt wird, wobei das RTCP-Berichtintervall von einer durchschnittlichen
Größe von RTCP-Feedback-Nachrichten
und der dem Client zugewiesenen RTCP-Bandbreite abhängt, indem
bestimmt wird, ob die maximale Anzahl von Sendewiederholungen größer ist
als oder genauso groß wie
die minimale Anzahl von Sendewiederholungen.
-
Ist
das Letztgenannte der Fall, kann die Verarbeitungseinrichtung den
Client veranlassen, einem RTCP-Feedback-Paket zum Anfordern der
Sendewiederholung verlorengegangener Datenpakete eine Anzahl von
General-NACK-Bericht-Blöcken
hinzuzufügen,
wobei die Anzahl von General-NACK-Bericht-Blöcken, die zu dem RTCP-Feedback-Paket hinzugefügt wurde,
die minimale Anzahl von Sendewiederholungen der verlorengegangenen
Datenpakete innerhalb der Client-Buffer-Zeit ermöglicht, um die maximale Größe von RTCP-Feedback-Nachrichten
zu bestimmen, die unter Berücksichtigung
der zugewiesenen RTCP-Bandbreite, der Client-Buffer-Zeit sowie der
minimalen Anzahl von Sendewiederholungen zulässig ist, um eine resultierende
durchschnittliche Größe von RTCP-Feedback-Nachrichten
auf Basis der durchschnittlichen Größe zuvor gesendeter RTCP-Feedback-Nachrichten
und der Größe des RTCP-Paketes,
das die Anzahl von General-NACK-Bericht-Blöcken umfasst, zu bestimmen,
um dem RTCP-Feedback-Paket
zum Berichten der verlorengegangenen Datenpakete eine Anzahl von
Loss-RLE-Bericht-Blöcken hinzuzufügen, wenn
die Größe des resultierenden
RTCP-Feedback-Paketes
die maximale Größe von RTCP-Feedback-Nachrichten
nicht übersteigt,
und zum Senden des RTCP-Feedback-Paketes als eine RTCP-Feedback-Nachricht
von dem Client zu dem Streaming-Server.
-
Das
computerlesbare Medium gemäß einer
weiteren Ausführungsform
der Erfindung speichert darüber
hinaus Befehle, die, wenn sie durch den Prozessor des Clients ausgeführt werden,
den Client veranlassen, das Verfahren gemäß einer der verschiedenen Ausführungsformen
der Erfindung wie oben beschrieben und ihrer Variationen durchzuführen.
-
Eine
weitere Ausführungsform
der Erfindung betrifft ein System, das einen Streaming-Server umfasst, der
einem Client wenigstens eine Streaming-Session bereitstellt, wobei
die wenigstens eine Streaming-Session unter Verwendung eines RTP-Protokolls
sowie des RTCP-Protokolls bereitgestellt wird, und einen Client gemäß einer
der Ausführungsformen
der oben genannten Erfindung.
-
Kurze Beschreibung
der Figuren
-
Im
Folgenden wird die Erfindung ausführlicher und in Bezug auf die
angehängten
Figuren und Zeichnungen beschrieben. Gleiche oder entsprechende
Einzelheiten in den Figuren sind mit gleichen Referenznummern gekennzeichnet.
-
1 stellt
einen Überblick
einer Streaming-Umgebung gemäß einer
Ausführungsform
der Erfindung dar,
-
2 stellt
die Beziehung zwischen der Client-Buffer-Zeit, dem RTCP-Berichtszeitraum
und einer minimalen Zeitdauer dar, die für das Bereitstellen einer Zielstufe
von Sendewiederholungen gemäß einer
Ausführungsform
der Erfindung erforderlich ist,
-
3 stellt
die Zeitplanung einer Anzahl aufeinander folgender Sendewiederholungs-Anforderungen und
Sendewiederholungen in einer Streaming-Umgebung gemäß einer
beispielhaften Ausführungsform
der Erfindung dar,
-
4 stellt
die ersten Schritte eines Verfahrens zum Bereitstellen von RTCP-Feedback während einer Streaming-Session
gemäß einer
Ausführungsform
der Erfindung dar, und
-
die 5 und 6 zeigen
weitere Schritte des Verfahrens zum Bereitstellen von RTCP-Feedback gemäß unterschiedlichen
Ausführungsformen
der Erfindung, wobei die dargestellten Schritte nach den in 4 gezeigten
Schritten durchgeführt
werden.
-
Ausführliche
Beschreibung
-
1 stellt
einen Überblick
einer Streaming-Umgebung gemäß einer
Ausführungsform
der Erfindung dar. Ein Streaming-Server 100 kann einen
Streaming-Dienst in Form einer oder mehrerer Sessions dem Client 101 oder
dem mobilen Endgerät über ein
drahtloses Zugangsnetz bereitstellen. In dem Beispiel wird der paketvermittelte
Streaming-Dienst von einem UMTS-Netzwerk bereitgestellt, das ein
Kernnetz 103 (Core Network – CN) umfasst, und ein UMTS-Funkzugriffsnetz 104 (UMTS
radio access network – UTRAN) stellt
den paketvermittelten Streaming-Dienst bereit, der gemäß den Anforderungen
wie in dem Dokument 3GPP TS 26.234 definiert, betrieben werden kann.
Zum Verbinden des Kernnetzes 103 mit einem paketvermittelten Netzwerk
wie beispielsweise dem Internet kann das Kernnetz einen Gateway-GPRS-Support-Node 105 (gateway
GPRS support node – GGSN)
sowie einen Bereitstellungs-GPRS-Support-Node 106 (serving
GPRS support node – SGSN)
umfassen. Die Bestandteile des Kernnetzes können mit dem UTRAN 104 verbunden
sein, das wenigstens einen Funkzugangscontroller 107 (radio
access controller – RNC)
und wenigstens einen Node B umfasst, der mit einem RNC verbunden
ist. Die Daten der Streaming-Media können einem mobilen Client 101 über eine
drahtlose Verbindung bereitgestellt werden.
-
Es
ist ein Aspekt der Erfindung, RLE-Bericht-Blöcke zum Berichten von Verlusten
in unterschiedlichen RTP-Sendewiederholungs-Implementierungen effizient
zu nutzen. Derartige Implementierungen unterscheiden sich typischerweise
bei den Funktionalitäten,
die Server und Client durchführen,
bei den Informationen, die beide zum Planen/Anfordern von Sendewiederholungen
nutzen, sowie hinsichtlich des Wissens, das beide über die
Netzwerkbedingungen (Überlastung,
Paketverlust, Verbindungseigenschaften) besitzen. Die 3GPP-PSS-Streaming-Dienste
definieren Session-Beschreibungsattribute,
die zum Verfügbarmachen
von Informationen zwischen kommunizierenden Mitgliedern des Netzwerkes
genutzt werden können
oder auch nicht.
-
Für alle RTP-Sendewiederholungs-Implementierungen
können
dasselbe Anfangsszenario sowie gleiche Anforderungen angenommen
werden: Der Client sollte redundant berichten, da der RTCP-Transport
unzuverlässig
ist. Darüber
hinaus sollte der Client wenigstens über den Zeitraum zwischen dem
aktuellen Bericht und dem letzten Bericht berichten, das heißt, er sollte
minimales Empfänger-Berichten
garantieren.
-
Die
Berichthäufigkeit
sollte ausreichend hoch sein, um eine rechtzeitige Sendewiederholung
zu ermöglichen,
das heißt,
um eine minimale Anzahl von Sendewiederholungen für jedes
RTP-Paket zu garantieren. Demgemäß kann der
Client seine Berichthäufigkeit,
die Bericht-Block-Größe sowie
redundantes Berichten begrenzen, um die durch den Server signalisierte
RTCP-Bandbreite zu erfüllen.
-
Da
einige dieser Anforderungen hoch sind und es möglicherweise nicht möglich ist,
sie gleichzeitig in jedem Szenario zu erfüllen, kann der Client den Grad
des redundanten Berichtens, die Berichthäufigkeit sowie die Anzahl berichteter
RTP-Pakete für
die gegebenen Bedingungen optimieren.
-
Beispielsweise
(und unter der Voraussetzung, dass der Anteil der RTCP-Bandbreite
sowie die Client-Buffer-Zeit redundantes Berichten ermöglichen)
könnte
dies bedeuten, dass der Client in einer einfachen Implementierung
eine Sendewiederholung für
und Berichte über
alle verlorengegangen Pakete zwischen dem aktuellen RTCP-Bericht
und dem letzten RTCP-Bericht anfordert und dazu General-NACK-Bericht-Blöcke beziehungsweise
Loss-RLE-Bericht-Blöcke
nutzt, den Grad des redundanten Berichtens über verlorengegangene und empfangene
Pakete auf einen vernünftigen
Wert setzt und die RTCP-Berichthäufigkeit
so hoch wie möglich
hält, um
ein Maximum rechtzeitiger Sendewiederholungen zu ermöglichen.
Es muss angemerkt werden, dass RTP-Pakete auf der Abwärtsstrecke
(Server zu Client) mehrmals verlorengehen können und daher mehrfache Sendewiederholungen
erfordern.
-
Sollte
diese einfache Implementierung der Anforderung nicht genügen, die
Berichthäufigkeit,
die Größe der Bericht-Blöcke sowie
redundantes Berichten zu begrenzen, um der signalisierten RTCP-Bandbreite
zu genügen,
kann der Client zunächst
versuchen, die Größe der Loss-RLE-Bericht-Blöcke durch
Lauflängencodierung
zu verringern.
-
Ein
Loss-RLE-Bericht-Block ermöglicht
ausführliches
Berichten über
den Empfang individueller Pakete sowie über Verlustereignisse. Derartige
Berichte können
beispielsweise für
eine Multicast-Ableitung von Netzwerk-Eigenschaften (multicast inference
of network characteristics – MINC)
genutzt werden. Da eine Boole'sche
Spur verlorengegangener und empfangener RTP-Pakete potenziell lang
ist, kann es dieser Blocktyp ermöglichen,
dass die Spur durch Lauflängencodierung
komprimiert wird. Wird die Lauflängencodierung
genutzt, wird die zu verschlüsselnde
Spur analysiert und „Läufe" identischer Ereignisse
werden summiert, um die Gesamtgröße des Loss-RLE-Bericht-Blocks
zu verringern.
-
Anschließend kann
der Client die Anzahl berichteter RTP-Pakete pro Loss-RLE-Bericht-Block verringern.
Es wird darauf hingewiesen, dass die verringerte Anzahl von durch
einen einzelnen Bericht-Block berichteten Paketen einen verringerten
Grad des redundan ten Berichtens bewirkt.
-
Um
die Anzahl von Paketen zu verringern, über die durch einen Loss-RLE-Bericht-Block
berichtet wird, können
Verlustereignis-Berichte mit einem Mechanismus systematisch aus
der Spur fallen gelassen werden, der Ausdünnen genannt wird. Der Ausdünnungs-Mechanismus kann
durch Auswählen
eines Ausdünnungs-Wertes
T implementiert werden, der genutzt werden kann, um eine Untergruppe
von Paketen innerhalb des Bereiches der Sequenznummern auszuwählen, beispielsweise
diejenigen Pakete mit Sequenznummern, die Vielfache von 2T sind.
Paketempfangs- und Verlust-Berichte gelten nur für diese Pakete. T kann zum
Beispiel zwischen 0 und 15 liegen. Ist T gleich null, wird über jedes
Paket in dem Bereich der Sequenznummern berichtet. Ist T gleich
fünfzehn,
wird über
eins von 32.768 Paketen berichtet.
-
Angenommen,
die eben beschriebene Spur beginnt bei Sequenznummer 13.821. Die
letzte Sequenznummer in der Spur ist 13.865. Wenn die Spur mit einem
Ausdünnungswert
von T = 2 ausgedünnt
werden soll, wird über
jede vierte Sequenznummer berichtet: 13.824, 13.828, 13.832, 13.836,
13.840, 13.844, 13.848, 13.852, 13.856, 13.860, 13.864.
-
Eine
weitere Möglichkeit,
die Anzahl berichteter Pakete zu verringern, besteht darin, nur
diejenigen Pakete zu berichten, die unter die neuesten Pakete fallen.
-
Sind
alle diese Maßnahmen
nicht hilfreich und gibt es eine strenge Anforderung für eine minimale
Anzahl von Sendewiederholungs-Anforderungen (General-NACK-Bericht-Block (oder -Blöcke)) vor
dem Ablauf der Client-Buffer-Zeit, kann der Client die Session mit
einer erweiterten RTCP-Bandbreite neu starten, um der geforderten
minimalen Anzahl von Sendewiederholungen zu genügen und/oder er kann die Client-Buffer-Zeit erhöhen (weitere
Einzelheiten siehe unten).
-
Für die weitere
Diskussion der Ideen, die der Erfindung zugrunde liegen, werden
die Beziehungen zwischen RTCP-Bandbreite, Client-Buffer-Zeit, RTCP-Berichtintervall
und dergleichen in Bezug auf 3 diskutiert. 3 stellt
einen Überblick
einer Streaming-Umgebung gemäß einer
Ausführungsform
der Erfindung dar. In der Figur wird die Zeitlinie einer Anzahl
aufeinander folgender Sendewiederholungs-Anforderungen und Sendewiederholungen
dargestellt. Es wird angenommen, dass die erste Übertragung des RTP-Paketes
(SN = 0) sowie die erste und die zweite Sendewiederholung verlorengegangen
sind.
-
Der
Sender (beispielsweise der Streaming-Server) stellt dem Empfänger (Client)
ein RTP-Daten-Paket bereit. Die zu der Verzögerung T1 beitragenden
Parameter sind die einfache Verzögerung
von dem Sender zu dem Empfänger über ein
Netzwerk oder mehrere Netzwerke, das heißt, die physikalische Verzögerung,
die Sendeverzögerung
an der Funkschnittstelle und die Verzögerung, die durch Jitter zwischen
den ankommenden Paketen hervorgerufen wird, der durch Netzwarteschlangen,
Umstellen und dergleichen hervorgerufen wird: T1 =
physikalische Verzögerung
+ Sendeverzögerung
+ Jitter durch Verzögerung
zwischen ankommenden Paketen (1)oder
genauer:
-
-
Unter
der Voraussetzung, dass die erste Übertragung des Paketes verlorengegangen
ist, gibt T2 das Zeitintervall zwischen
der theoretischen Ankunft des Paketes und dem Zeitpunkt an, zu dem
der Empfänger ein
Feedback bereitstellt, das anzeigt, dass das Paket den Sender nicht
erreicht hat.
-
Somit
setzt sich T2 aus der Zeit zusammen, die
erforderlich ist, um den Paketverlust (Paketverlust-Feststellungszeit)
an dem Client festzustellen und der durchschnittlichen Zeit bis
zu dem nächsten
Feedback-Bericht von dem Client: T2 = Paketverlust-Feststellungszeit
+ durchschnittliche Zeit bis zum nächsten Feedback-Bericht (3)
-
Die
Paketverlust-Feststellungszeit hängt
davon ab, ob gelegentlich einzelne Pakete ver lorengegangen sind
(Einzelverluste) oder ob Paketverluste gebündelt auftreten (Burstverluste).
In dem ersten Fall sollte die Paketverlust-Feststellungszeit gleich
dem Jitter durch Verzögerung
zwischen ankommenden Paketen sein, der an dem Empfänger auftritt.
In dem zweiten Fall muss der Buffer-Zeit zum Bestimmen des tatsächlichen Wertes
eine zusätzliche
Wachzeit hinzugefügt
werden. Diese Wachzeit kann als der durchschnittliche Verlustburst
definiert werden und trägt
der Tatsache Rechnung, dass es länger
dauert, bis Burstverluste entdeckt werden.
-
Üblicherweise
sind Verlustereignisse einheitlich verteilt, so dass die durchschnittliche
Zeit bis zu dem nächsten
Feedback-Bericht üblicherweise
die Hälfte
des RTCP-Berichtintervalles
beträgt: durchschnittliche Zeit bis
zum nächsten
Feedback-Bericht = ½·RTCP-Berichtintervall (4)
-
Die
Verzögerung
des Feedback-Berichtes T3 kann im Wesentlichen
genauso wie die Verzögerung
T1 berechnet werden. T3 =
physikalische Verzögerung
+ Sendeverzögerung
+ Jitter durch Verzögerung
zwischen ankommenden Paketen (5)oder
genauer:
-
-
Schließlich wird
die Verarbeitungszeit der Sendewiederholung an dem Sender mit T4 dargestellt, sie umfasst die Zeit, die
von dem Sender benötigt
wird, um zu entscheiden, welche Pakete erneut zu senden sind (Feedbackverarbeitungs-Zeit)
und die Wartezeit an dem Sender, das heißt, die Zeit, während der
die erneut zu sendenden Pakete in der Sende(wiederholungs-)Warteschlange
des Senders bleiben, bevor sie tatsächlich gesendet werden. T4 =
Feedbackverarbeitungs-Zeit + Wartezeit (7)
-
Es
muss angemerkt werden, dass T1 + T2 + T3 der Roundtrip-Zeit
(RTT) entspricht: RTT
= T1 + T2 + T3 (8)
-
Die
RTT ist typischerweise kleiner als das RTCP-Berichtintervall. Anderenfalls
würde übermäßiges Berichten
auftreten, da der Empfänger
Feedback senden würde,
ohne zunächst
die Sendewiederholung von Paketen abzuwarten. Darüber hinaus
fällt die
Summe der RTT plus die Feedbackverarbeitungs-Zeit gleichermaßen typischerweise
in das RTCP-Berichtintervall, da der Server üblicherweise eine definierte
Sendewiederholungs-Bandbreite
garantieren muss und somit diese Zeit nicht wesentlich ansteigt.
-
Eine
weitere wichtige „Variable" einer RTP-Session,
die die bereitstellbare Bericht-Redundanz
beeinflusst, ist die bereits oben genannte Client-Buffer-Zeit. Die
Client-Buffer-Zeit
kann im Allgemeinen als die Zeitspanne definiert werden, in der
ein bestimmtes Datenpaket in einem Speicher des Empfängers zwischengespeichert
wird, bevor es an den Benutzer „ausgegeben" wird. So kann beispielsweise
für eine
Video-Streaming-Session
die Client-Buffer-Zeit als die Zeitspanne des Speicherns eines Datenpaketes
in dem Speicher (Buffer) des Empfängers verstanden werden, bevor
der Inhalt des Datenpaketes dem Benutzer angezeigt wird.
-
Die
Anzahl der Sendewiederholungen, die in einer RTP-Session bereitgestellt
werden können,
bevor ein Paket dem Benutzer bereitgestellt wird, kann wie folgt
spezifiziert werden:
-
-
Die
Funktion „Integer()" extrahiert den ganzzahligen
Wert aus dem Ergebnis der Division. Das RTCP-Berichtintervall (für Aufwärtsstrecken-Übertragungen)
wird durch folgende Gleichung definiert:
-
-
In
dieser Gleichung ist die aktuelle RTCP-Paket-Größe gleich der Größe des nächsten zu
sendenden RTCP-Feedbacks.
-
Eine
Vereinfachung der oben genannten Rechnungen kann sein, dass nur
Nicht-Burst-Verluste,
also einmalige Verluste von Paketen, in der Definition von T2 berücksichtigt
werden, das heißt T2 =
Jitter durch Verzögerung
zwischen ankommenden Paketen (12)
-
Da
T1 + T2 + T3 + T4 an dem Client
möglicherweise
nicht immer verfügbar
ist, kann für
diese Summe eine konservative Näherung
genutzt werden, wie in 3 dargestellt (es ist darauf
hinzuweisen, dass eine minimale Anzahl von Sendewiederholungen von
3 nur zu Beispielzwecken genutzt wird). So kann beispielsweise der
RTCP-Berichtintervall-Wert
eine grobe Schätzung
für diese
Summe und eine konservative Buffer-Zeit client_buffer_zeit' darstellen, die
wie folgt definiert werden kann:
client_buffer_zeit' = client_buffer_zeit – rtcp_bericht_intervall
-
Die
konservative Client-Buffer-Zeit client_buffer_zeit' kann darüber hinaus
als die Buffer-Zeit
zum Sicherstellen der minimalen Anzahl erforderlicher Sendewiederholungen
min_anz_swdhl verstanden werden. Dies gilt selbstverständlich nur,
so lange der Wert T1 + T2 +
T3 + T4 kleiner
ist als das RTCP-Berichtintervall, was typischerweise der Fall ist,
da ansonsten der Client vor dem Senden des Feedbacks eine mögliche Sendewiederholung
nicht abwarten würde.
Dies soll durch den Server oder den Inhaltsersteller sichergestellt
werden, der dafür
verantwortlich ist, die Session-Beschreibungsinformationen mit SDP
oder ähnlichen
Protokollen zu kompilieren.
-
Gemäß einer
Ausführungsform
der Erfindung kann die Berechnung der Anzahl möglicher Sendewiederholungen
(siehe Gleichung 9) auf folgende Gleichung vereinfacht werden:
-
-
Selbstverständlich kann
darüber
hinaus auch die genauere Rechnung aus Gleichung 9 genutzt werden.
Die Gleichung 13 ist jedoch möglicherweise
leichter zu implementieren. In der ersten Phase eines PSS-Streaming-Dienstes
fordert der Client eine Beschreibung über Einzelheiten einer von
einem bestimmten Server angebotenen Session an. Als Reaktion auf
die Anforderung sendet der Server die Session-Beschreibung. Unter
Anderem werden dem Client folgende Parameter durch die Session-Beschreibung
bekannt gemacht:
MIME-Type des für die Media-Session genutzten
Codecs: zum Beispiel H263, AMR, MPEG4 und dergleichen.
-
Anteil
der RTCP-Bandbreite, client_rtcp_bandbreite (Bit pro Sekunde) für die Empfänger-Berichte. Der Standardanteil
der Bandbreite für
Unicast-Streaming-Anwendungen wie beispielsweise die von der PSS-Spezifizierung
abgedeckten beträgt
50% der Gesamt-RTCP-Bandbreite
sowohl für
den Sender als auch für
den Empfänger.
Andere Werte können
unter Nutzung der Vorschriften von RFC 3556 explizit spezifiziert
werden. Die Gesamt-RTCP-Bandbreite beträgt üblicherweise 5% der gesamten
Session-Bandbreite.
-
Optional
MIME-Type-Parameter, die den Codec beschreiben. Diese Parameter
können
genutzt werden, um andere Werte des Streams wie beispielsweise die
Paketrate (Anzahl der Pakete pro Sekunde) zu berechnen.
-
Optional
die maximale RTCP-Paket-Größe, die
ein Client nutzen kann. Derzeit ist es innerhalb des PSS-Systems
möglich,
die RTP-Paket-Größe (nicht
die RTCP-Paket-Größe) eines
Servers zu begrenzen. Ähnliche
Beschränkungen
sind in der Zukunft für
RTCP-Bericht-Pakete
möglich.
-
Darüber hinaus
sind dem Client gemäß einer
Ausführungsform
der Erfindung die folgenden zusätzlichen
Parameter bekannt:
Die minimale Anzahl von Sendewiederholungen,
min_anz_swdhl, wird von dem Server empfohlen. Der Server kann vorschlagen,
dass der Client eine minimale Anzahl von Sendewiederholungen für jedes
Paket garantiert. Der Grund hierfür kann sein, dass dem Dienstanbieter
der Paketverlust auf der Verbindung bekannt ist. Wie oben angegeben,
müssen
Sendewiederholungen in PSS-Streaming-Diensten durch General-NACK-Bericht-Blöcke in dem
Feedback ausgelöst
werden.
-
Die
Bericht-Redundanz, bericht_redundanz, wird (darüber hinaus) von dem Server
empfohlen. Diese Menge zeigt an, wie oft ein Paket mit den Loss-RLE-Bericht-Blöcken berichtet
wird. Für
Dienstprovider ist es wichtig, die erzielte Leistungsfähigkeit
der Verbindung zu kennen (welche Pakete angekommen sind oder nicht)
und wie viele Sendewiederholungen höchstens benötigt werden, um dem Client
die Pakete bereitzustellen. Dies ist darüber hinaus für die Abrechnung
wichtig, wenn Clients nur für
die jeweils von ihnen genutzte Dienstgüte zahlen müssen.
-
Die
Client-Buffer-Zeit, client_buffer_zeit (in Sekunden gemessen), die
aus den Session-Parametern abgeleitet
werden kann wie in den folgenden Absätzen beschrieben.
-
In
Anbetracht der Client-Buffer-Zeit gibt es zwei mögliche Szenarien:
Die
erste Möglichkeit
besteht darin, dass der Client die Bitratenanpassung wie in dem
3GPP-PSS-System definiert, nicht unterstützt.
-
In
diesem Fall kann der Wert des Parameters client_buffer_zeit gleich
der ersten Buffer- Zeit
ausgewählt
werden, das heißt,
die Zeit, nach der der Client beginnt, die Pakete zum Session-Beginn
aus dem Buffer auszulesen.
-
Die
zweite Möglichkeit
besteht darin, dass der Client die Bitratenanpassung unterstützt wie
in dem 3GPP-PSS-System definiert. In diesem Fall sind für den Client
folgende Parameter verfügbar:
Die
Buffer-Größe, buffer_größe, die
in dem Header „3GPP-Adaptation" signalisiert wird.
Dieser Parameter sollte einem Empfangs- und De-Jitter-Buffer entsprechen,
der diese bestimmte Menge Platz für vollständige RTP-Pakete einschließlich des
RTP-Headers besitzt. Die spezifizierte Größe des Buffers kann darüber hinaus jedweden
Platz für
Prä-Decodierer-Buffer
enthalten, der für
diese Medien genutzt wird. Dieser Parameter entspricht somit einer
maximalen Größe von Session-Daten
(RTP-Paketen), die der Client zu jedem beliebigen Zeitpunkt der
Session verfügbar
haben kann. Üblicherweise
wird dieser Parameter nicht zum Bestimmen eines Wertes für die Client-Buffer-Zeit
genutzt.
-
Die
Zielschutz-Zeit, zielschutz_zeit, die dem Client in dem Header „3GPP-Adaptation" (Parameter „Ziel-Zeit") signalisiert wird.
Dieser Parameter kennzeichnet den anvisierten minimalen Buffer-Füllstand,
mit anderen Worten, die gewünschte
Menge von Wiedergabezeit bei dem Client (in Millisekunden), um eine
unterbrechungsfreie Wiedergabe zu garantieren und es dem Server
zu ermöglichen,
die Übertragungsrate
anzupassen, falls nötig.
Gemäß einer
Ausführungsform
der Erfindung wird dieser Parameter als die Client-Buffer-Zeit, client_buffer_zeit,
genutzt.
-
Sobald
der Client die Session-Beschreibungsinformationen empfangen hat,
kann der Client berechnen, ob der signalisierte Anteil der RTCP-Bandbreite
(client_rtcp_bandbreite) und der intendierte Wert des Parameters
client_buffer_zeit für
den jeweiligen Media-Stream ausgewählt wurde, so dass das Berichten
von Paketverlusten möglich
ist. Zusätzlich
kann er darüber
hinaus berechnen, ob die gewünschte
Bericht-Redundanz wie von dem Parameter bericht_redundanz und der
von dem Parameter min_anz_swdhl angezeigten, angeforderten minimalen
Anzahl von Sendewiederholungen angezeigt, bereitgestellt werden
kann, wenn der Anteil der RTCP-Bandbreite und die Client-Buffer-Zeit
berücksichtigt
werden.
-
Es
muss noch einmal darauf hingewiesen werden, dass sich die Bericht-Redundanz
auf die bereitgestellte Netzüberwachung,
Abrechnung und ähnliche
Elemente (Loss-RLE-Bericht-Blöcke) bezieht,
während die
minimale Anzahl der bereitzustellenden Sendewie derholungen auf dem
Feedback von General-NACKs basiert, wie bereits umrissen.
-
Gemäß einer
Ausführungsform
wird angenommen, dass der Buffer des Clients ein Zeitzählwerk auf den
Wert des Parameters client_buffer_zeit Sekunden für jedes
Paket einstellt. Kann ein Paket nicht innerhalb der genannten Zeitspanne
empfangen werden, läuft
das Zeitzählwerk
ab und das Paket kann nicht mehr länger für die Sendewiederholung angefordert
werden (das heißt,
es kann in einer weiteren General-NACK-Mitteilung nicht eingeschlossen
werden).
-
Darüber hinaus
kann angenommen werden, dass RTCP-Berichte (die die vorher gesendeten
General-NACK-Bericht-Blöcke
und Loss-RLE-Bericht-Blöcke
enthalten) in einem Sende-Buffer bei dem Client gespeichert werden.
Die Größe dieses
Zwischenspeichers kann beispielsweise entsprechend des Wertes für den Parameter
server_buffer_zeit (in Sekunden) eingestellt sein. Darüber hinaus
sollte dieser Buffer groß genug sein,
um die gesendeten RTCP-Pakete zu speichern, je nachdem, wie diese
von dem im Folgenden beschriebenen Verfahren benötigt werden.
-
Die
folgenden Passagen beschreiben einen beispielhaften Algorithmus
gemäß einer
Ausführungsform der
Erfindung, der die in RFC 3550, Anhang A beschriebenen Standard-RTP-Algorithmen
ergänzt.
Im Gegensatz zu den Standard-RTP-Algorithmen ermöglicht es die Erfindung gemäß diesem
Algorithmus, für
das Konfigurieren einer PSS-konformen
Session die Parameter min_anz_swdhl und bericht_redundanz zu berücksichtigen.
Dieser Algorithmus hilft dem Client dabei, herauszufinden, wie groß General-NACK und der Loss-RLE-Bericht
sind, die für
folgende Abläufe
benötigt
werden:
Ermöglichen
der maximalen Anzahl von Paket-Sendewiederholungen für jedes
Paket oder Durchsetzen einer minimalen Anzahl von Sendewiederholungen,
min_anz_swdhl, innerhalb der Client-Buffer-Zeit,
Bereitstellen
von Bericht-Redundanz, wie von dem Parameter bericht_redundanz eingestellt
(wenn möglich),
während der
gegebenen RTCP-Bandbreite für
Empfänger-Berichte
und den Fähigkeiten
des Client-Buffers entsprochen wird.
-
Die
folgenden beispielhaften Schritte können durch den Client für jeden
RTCP- Empfänger-Bericht durchgeführt werden,
der durch den Client gesendet wird, beginnend mit dem ersten RTCP-Paket.
-
Schritt
1. Nach einem ersten Wartezeitraum von 1 Sekunde, wie von RTP/AVPF
festgelegt, kann der Client Paket-Sendewiederholungen in einer neuen
General-NACK-Mitteilung
anfordern. Von dem Blickwinkel der Implementierung aus betrachtet,
ist dieser Schritt eine Suchoperation, da jeder Client, der eine
Sendewiederholung gemäß dem oben
genannten Dokument Internet Draft von Rey et al. implementiert,
eine Liste noch ausstehender Anforderungen führen sollte.
-
Eine
beispielhafte Liste könnte
aus zwei Spalten bestehen: Eine enthält die Sequenznummer SN und die
andere enthält
einen Bitschalter, der anzeigt, ob das Paket mit der bestimmten
SN empfangen oder nicht empfangen wurde, das heißt, „0" bedeutet nicht empfangen, „1" bedeutet empfangen.
Die in dieser Liste enthaltenen, nicht empfangenen Pakete werden
in dem NACK eingeschlossen. Es ist darauf hinzuweisen, das die nicht
empfangenen Pakete nach Ablauf der Client-Buffer-Zeit (client_buffer_zeit)
für das
jeweilige Paket aus dieser Liste entfernt werden.
-
Schritt
2. Der zweite Schritt besteht darin, die maximale Anzahl von Sendewiederholungen (max_anz_swdhl)
für die
in den General-NACK-Bericht-Blöcken
für die
jeweilige RTCP-Bandbreite, client_rtcp_bandbreite, berichteten Pakete
zu berechnen. Da die Pakete, deren Sendewiederholung noch aussteht,
die minimale Reihe von Informationen sind, die jedes Sendewiederholungs-Paket
umfassen sollte, um eine minimale Anzahl von Sendewiederholungen
(min_anz_swdhl) durchzusetzen, kann die maximale Anzahl von Sendewiederholungen
berechnet werden, indem der Wert des Parameters client_buffer_zeit' durch den aktuellen
Wert des RTCP-Berichtintervalles, rtcp_bericht_intervall, dividiert
wird:
-
-
Es
muss angemerkt werden, dass diese Berechnung die in Gleichung (13)
oben dargestellte Vereinfachung umfasst. Der Parameter RTCP-Berichtintervall,
rtcp_bericht_intervall, befindet sich üblicherweise im Bestand von
jedem RTP-Client und Server als Teil der RTP-Basis-Algorithmen.
-
Die
durchschnittliche RTCP-Paket-Größe, durchschn_rtcp_paket_größeNACK, kann berechnet werden als (siehe darüber hinaus
Gleichung 11 oben):
-
-
Die
aktuelle RTCP-Paket-Größe (in Byte),
das heißt,
die Paket-Größe der nächsten Feedback-Nachricht,
wenn sie einen General-NACK-Bericht-Block umfasst (jedoch keinen
Loss-RLE-Bericht-Block), kann wie folgt berechnet werden: aktuelle_rtcp_paket_größeNACK = K + (Step(n, 17))·4 (16)wobei Step()
die mathematische Schrittfunktion ist, die n und die Konstante 17
als Parameter nutzt. 17 ist die Anzahl der Pakete, die in einem
einzigen General-NACK-Bericht-Block
angefordert werden kann. Es ist selbstverständlich möglich, eine andere Konstante
als 17 als einen Parameter für
die Schrittfunktion zu nutzen, wenn mehr/weniger als 17 Pakete durch
einen einzigen General-NACK-Bericht-Block angefordert werden. Für mehrere
Werte von n ist:
Step(n, 17) =
0 wenn n <= 0;
1 wenn
1 <= n <= 17;
2 wenn
1·17
+ 1 <= n <= 2·17;
3
wenn 2·17
+ 1 <= n <= 3·17
und
so weiter.
-
K
ist eine Konstante, die die feststehenden Felder in einem IP-Paket
nachweist, das RTCP-Empfänger-Mitteilungen
mit wenigstens einer General-NACK-Mitteilung enthält.
-
Hat
beispielsweise das Paket eine Standardzusammensetzung von einem
Empfänger-Bericht (Receiver
Report – RR)
mit 32 Byte plus einem SDES-Element (mit CNAME) mit 12 Byte und
ohne Verschlüsselungs-Header
oder profilspezifische Erweiterungen, belaufen sich die feststehenden
Felder auf IP-Header + UDP-Header + RTCP-Header + 1 RR + 1 SDES-Element
(CNAME) + NACK-feststehende-Felder, das heißt 20 + 8 + 8 + 24 + 12 + 12
= 84 Byte.
-
Enthält das Paket
profilspezifische Erweiterungen oder andere SDES-Elemente wie beispielsweise eine
Telefonnummer, E-Mail oder andere RTCP-Bericht-Blöcke wie
beispielsweise ein BYE-Paket oder ein anwendungsspezifisches Paket
(application-specific packet – APP),
müssen
die feststehenden Felder zu dieser Konstante K addiert werden. Dasselbe
gilt für
K' unten.
-
Ist
die berechnete maximale Anzahl von Sendewiederholungen (Gleichung
14), max_anz_swdhl, größer als
eins (> 1), so bedeutet
dies, dass verlorengegangene Pakete die Möglichkeit haben, bei einer
Sendewiederholung oder mehreren Sendewiederholungen zu einem späteren Zeitpunkt
empfangen zu werden.
-
Typischerweise
kann es erforderlich sein, dass der Client eine minimale Anzahl
von Sendewiederholungen, min_anz_swdhl, einhält. Ist dies nicht möglich, das
heißt,
max_anz_swdhl < min_anz_swdhl,
kann der Client entscheiden, mit einer geringeren Anzahl von Sendewiederholungen
fortzusetzen oder die Session neu zu initiieren oder andere Einstellungen
zu wählen
(zum Beispiel eine Codec-Konfiguration, die weniger Buffer-Zeit
beansprucht, durch Auswählen
einer höheren
RTCP-Bandbreite, eines besser geschützten Streams, so dass min_anz_swdhl
kleiner ist, und dergleichen), da es nicht möglich ist, die erforderliche
minimale Anzahl von Sendewiederholungen innerhalb der Einschränkungen
bereitzustellen, die durch den Anteil der RTCP-Bandbreite sowie
die Client-Buffer-Zeit vorgegeben sind.
-
Mit
anderen Worten, wenn eine minimale Anzahl von Sendewiederholungen
durch den Client erforderlich ist, was gemäß den oben genannten Rechnungen
erfüllt
werden kann, ist es möglich,
dem Feedback Daten hinzuzufügen,
bis die maximale Paket-Größe (siehe
unten) erreicht ist. Anderenfalls sind die RTCP-Pakete zu groß und Sendewiederholungen
können
nicht so oft wie erforderlich angefordert werden.
-
Die
maximale Größe des RTCP-Paketes,
max_rtcp_paket_größe, die
das Anfordern ei ner Anzahl von Sendewiederholungen, min_anz_swdhl,
eines Paketes ermöglicht,
kann wie folgt berechnet werden:
-
-
Es
ist darauf hinzuweisen, dass die Gleichung 17 für jeden Wert von min_anz_swdhl
definiert ist, da der letztere Parameter immer größer als
1 ist. Anderenfalls würde
es nicht sinnvoll sein, Sendewiederholungen zu nutzen, wie von Rey
et al. in dem oben genannten Dokument Internet Draft vorgeschlagen.
-
Schritt
3. Vorausgesetzt, dass der Client in der Lage ist, min_anz_swdhl
durchzusetzen, und vorausgesetzt, dass max_anz_swdhl > min anz swdhl ist,
besteht der nächste
Schritt darin, die Feedback-Mitteilungen mit Loss-RLE-Bericht-Blöcken zu
füllen
(zusätzlich
zu General-NACKs zum Anfordern der Sendewiederholungen), bis die
max_rtcp_paket_größe, wie
mit Gleichung 17 berechnet, erreicht wurde. Mit anderen Worten,
die Differenz zwischen max_rtcp_paket_größe und aktuelle_rtcp_paket_größeNACK ist gleich der Datenmenge, die zu dem
aktuellen RTCP-Paket addiert werden kann, ohne dabei die Anforderungen
für eine
minimale Anzahl von Sendewiederholungen, min_anz_swdhl, zu verletzen: nutzdaten_spanne = max_rtcp_paket_größe – aktuelle_rtcp_paket_größeNACK (18)
-
Ähnlich wie
in dem oben genannten Fall (siehe Gleichung 16) ist die allgemeine
Formel zum Berechnen der RTCP-Paket-Größe einschließlich IP-
und UDP-Headern für
RTCP mit General-NACK-Mitteilungen und Loss-RLE-Berichten als einer
Funktion von n wie folgt: aktuelle_rtcp_paket_größe = K' + (Step(n, 17) + Step'(n', 30))·4 (19)wobei Step'() dieselbe Funktion
ist wie oben und Step() die mathematische Schrittfunktion ist, die
n und die Konstante 30 als Parameter nutzt. Es ist darauf hinzuweisen,
dass in Gleichung 19 angenommen wird, dass wenigstens ein Loss-RLE-Bericht-Block
in dem Feedback enthalten ist, anderenfalls kann die Gleichung 16 zum
Berechnen der aktuellen RTCP-Paket-Größe genutzt werden. Der Parameter
30 ist die Anzahl der Pakete, über
die in einem einzigen Loss-RLE-Bericht-Block berichtet werden kann.
Es ist selbst verständlich
möglich,
eine andere Konstante als 30 als einen Parameter für die Schrittfunktion
zu nutzen, wenn mehr/weniger als 30 Pakete durch einen einzigen
RLE-Bericht-Block
angefordert werden können.
Für mehrere
Werte von n' ist:
Step'(n', 30) =
0 wenn
n' <= 0;
1 wenn
1 <= n' <= 1·30;
2 wenn 1·30 + 1 <= n' <= 2·30;
3 wenn 2·30 + 1 <= n' <= 3·30;
und so weiter.
-
Es
ist anzumerken, dass n und n' schrittweise
ansteigen. Der Grund hierfür
liegt darin, dass die RTCP-Berichte 32-Bit-ausgerichtet sind und
ein ganzes 4-Byte-Wort addiert wird, wenn die Anzahl der zu berichtenden
Pakete ein Vielfaches von 17 oder 30 überschreitet.
-
In
Gleichung 19 ist K' 6
Byte größer als
K, das für
die oben genannte Gleichung 16 definiert wurde, da (wenigstens)
ein in der (aktuellen) RTCP-Feedback-Nachricht enthaltener Loss-RLE-Bericht-Block
als Nächstes
gesendet werden soll.
-
Muss
der Client einen bestimmten Wert für den Parameter bericht_redundanz
einhalten, kann dieser Bericht vergangene Loss-RLE-Bericht-Blöcke, wie
durch diesen Wert definiert, enthalten. So bedeutet zum Beispiel
ein Wert von 2 des Parameters redundanz_wert, dass derselbe Loss-RLE-Bericht
in zwei aufeinander folgenden RTCP-Berichten gesendet wird. Beträgt der Wert
drei, ist derselbe Loss-RLE-Bericht-Block in drei aufeinander folgenden
RTCP-Paketen enthalten, und so weiter. Mit anderen Worten, wenn
die Bericht-Redundanz auf 2 eingestellt ist, sollte ein einziger
RTCP-Bericht (das heißt,
die darin enthaltenen RLE-Bericht-Blöcke) über die vergangenen zwei RTCP-Berichtintervalle
berichten, wenn die Bericht-Redundanz auf 3 eingestellt ist, sollte über die
vergangenen drei RTCP-Berichtintervalle berichtet werden, und so
weiter. Hierfür
kann es erforderlich sein, dass der Client eine Liste (das heißt, ein
zweispaltiges Array) empfangener und nicht empfangener Pakete einschließlich solcher
Pakete führt,
die abgelaufen sein können.
Dies unterscheidet sich von dem Inhalt des Buffers des Clients,
der nur Pakete umfasst, die noch nicht abgelaufen sind.
-
Schritt
4. Es kann darüber
hinaus vorkommen, dass das Einschließen der zum Bereitstellen der
erforderlichen Bericht-Redundanz erforderlichen Anzahl von Loss-RLE-Bericht-Blöcken, die
zu der nächsten RTCP-Feedback-Nachricht
hinzugefügt
werden müssen
(zusätzlich
zu einem General-NACK-Bericht-Block oder General-NACK-Bericht-Blöcken), die
zulässige
maximale RTCP-Paket-Größe, max_rtcp_paket_größe, übersteigt.
In diesem Fall kann der Client versuchen, die Größe des Loss-RLE-Bericht-Blockes oder der Loss-RLE-Bericht-Blöcke durch
Lauflängencodierung
zu verringern. Darüber
hinaus können
weitere Optionen wie beispielsweise das Ausdünnen wie oben beschrieben zum
Verringern der Paket-Größe genutzt
werden. Wird jedoch das Ausdünnen
in Betracht gezogen, verringert sich dadurch die Bericht-Redundanz.
-
Sind
diese Mechanismen nicht ausreichend, um die Größe der RLE-Bericht-Blöcke in ausreichendem Maße zu verringern
und die erforderliche Bericht-Redundanz zu garantieren, kann der
Client beschließen,
diesem Wert bericht_redundanz nicht zu entsprechen, und trotzdem
mit dem Senden fortfahren. Alternativ kann er die Session neu initiieren
und eine größere Client-Buffer-Zeit
oder eine Codec-Konfiguration mit geringerer Bitrate auswählen.
-
Schritt
5. Schließlich
werden die restlichen variablen Aktualisierungsverfahren und die
Standardverfahren in den Standard-Algorithmen, wie durch RFC 3550,
Anhang A festgelegt, wie beispielsweise durchschn rtcp_paket_größe und rtcp_bericht_intervall
auf die Standard-Weise berechnet:
-
-
Immer
dann, wenn ein RTCP-Paket gesendet wird, können die Schritte 1 bis 5 wiederholt
werden. Alternativ dazu kann der Client auch entscheiden, diese
Schritte nur bei Änderungen
der Fähigkeiten
des Clients und insbesondere bei Änderungen der Client-Buffer-Zeit oder
der Client-RTCP-Bandbreite zu iterieren.
-
Nachdem
der Client die Feedback-Nachricht gesendet hat, kann er die verschiedenen
Parameter der Session gemäß den in
RFC 3550 umrissenen Vorgaben aktualisieren. So kann der Client beispielsweise
die durchschnittliche RTCP-Paket-Größe erneut berechnen, er kann
das daraus resultierende RTCP-Berichtintervall erneut berechnen,
er kann den Inhalt des Sende-Buffers aktualisieren und er kann Berechnungen
für das nächste zu
sendende RTCP-Feedback starten.
-
In
einer weiteren Ausführungsform
kann die Größe des Loss-RLE-Bericht-Blockes
weiter verringert werden, indem der Client den Wert bericht_redundanz
verringert. In dieser Situation ergibt sich jedoch die Frage, ob
der Client trotzdem einen vernünftigen
Grad für
das redundante Berichten erzielen kann.
-
Das
Verringern der Bericht-Redundanz kann in Implementierungen möglich sein,
die eine Messung der Paketverlustrate in der Verbindung ermöglichen.
Die Paketverlustrate kann beispielsweise aus RTCP-Berichten von
dem Sender geschätzt
werden. Alternativ oder zusätzlich
dazu kann der Client aus dem Verbindungs-Einrichtungsverfahren ein
Apriori-Wissen über
die Verbindungs-Dienstgüte
besitzen. Ist also die Paketverlustrate einer bestimmten Verbindung
zu dem Client niedrig/hoch, kann der Grad des redundanten Berichtens
weiter verringert/erhöht
werden, denn je niedriger/höher
die Paketverlustrate ist, desto wahrscheinlicher/unwahrscheinlicher
ist es, dass das Feedback des Clients an dem Sender empfangen wird,
wenn ein unzuverlässiges
Transportprotokoll genutzt wird.
-
Ein
weiteres Verfahren zum Verringern der Größe der Loss-RLE-Bericht-Blöcke neben
denen, die in dem Dokument Internet Draft von Friedman et al. spezifiziert
werden, kann beispielsweise auf der Schätzung der Wichtigkeit einzelner
Pakete basieren. So haben beispielsweise bei progressiven Codierungstechnologien, zum
Beispiel bei MPEG4, Pakete unterschiedliche Prioritäten. Weniger
wichtige Pakete, beispielsweise P-Frames, können somit in dem Bericht ausgelassen
werden.
-
Alternativ
oder zusätzlich
dazu können
die Dienstgüte
der aktuellen Anwendungsschicht sowie die Dienstgüte der Verbindungsschicht
zum Verringern der Größe der Loss-RLE-Bericht-Blöcke berücksichtigt werden.
Ist zum Beispiel die Dienstgüte
der aktuellen Anwendungsschicht ausreichend hoch und/oder ist die Dienstgüte der Verbindungsschicht
niedrig (das heißt, Überlastung
der Verbindung), kann der Client entscheiden, das Berichten für einige
verlorengegangene Pakete auszulassen. So implementiert beispielsweise
der MPEG4-Codec erweiterte Ausfallsicherheitsmaßnahmen für Paketverluste. In einigen
Fällen
und abhängig vom
Inhalt des Streams ist es durchaus möglich, dass mehrere Pakete
auf der Verbindung verlorengegangen sind, die Qualität des Bildes
durch diese Verluste jedoch nicht beeinträchtigt wird; die Auswirkungen
sind insbesondere dann minimal, wenn B-Frames verlorengegangen sind,
und die Kosten einer Sendewiederholung des Paketes können größer sein,
und somit kann die Anwendung entscheiden, das Paket ausfallen zu
lassen.
-
Die
Erfindung besitzt folgende Vorteile für 3GPP-PSS-Unicast-Streaming-Dienste.
Zunächst
stellt sie dem 3GPP-PSS-System zusätzliche Mechanismen für Streaming-Server
und Clients bereit, um die RTCP-Empfänger-Berichte mit General-NACKs
und RLE-Bericht-Blöcken zu
konstruieren. Unter der Annahme, dass der Client den Wert client_buffer_zeit
und den Wert client_rtcp_bandbreite kennt, ermöglicht das Verfahren das Spezifizieren
der Größe der Berichte,
um eine minimale Anzahl von Sendewiederholungen, min_anz_swdhl,
und einen bestimmten Wert für
den Parameter bericht_redundanz bereitzustellen, wie oft die Berichte
gesendet werden sollen und wie viele Pakete sie abdecken.
-
Wie
oben ausgeführt,
ist die Bericht-Redundanz wichtig für Abrechnungsanwendungen und
für die Netzüberwachung,
insbesondere hinsichtlich der Leistungsfähigkeit von Sendewiederholungen,
das heißt,
wie oft Pakete erneut gesendet werden, ehe sie (erfolgreich) durch
den Client empfangen werden.
-
Des
Weiteren definiert die Erfindung ein System zum Spezifizieren eines
breiten Spektrums von Client-Konfigurationen, so dass sowohl ein
einfacher Client als auch ein Client mit umfangreicher Ausstattung
eingerichtet werden können,
abhängig
davon, welche Informationen an dem Client verfügbar sind und wie effizient die
Loss-RLE-Bericht-Kompression
sein soll. Darüber
hinaus stellen einige Ausführungsformen
der Erfindung zusätzliche
Verfahren zum Verringern der Größe des RTCP-Feedbacks
bereit.
-
Im
Folgenden werden in Bezug auf die 4, 5 und 6 unterschiedliche
und spezifischere beispielhafte Ausführungsformen der Erfindung
beschrieben.
-
4 stellt
die ersten Schritte eines Verfahrens zum Bereitstellen von RTCP-Feedback
während
einer Streaming-Session gemäß einer
Ausführungsform
der Erfindung dar. Nach dem Ablaufen des aktuellen RTCP-Berichtintervalls
bereitet der Client das Senden des nächsten RTCP-Feedbacks an den
Server vor. Zunächst
(in den Schritten 401 bis 404) kann der Client
bestimmen, ob die eingestellten Session-Parameter es ermöglichen
sicherzustellen, dass die erforderliche minimale Anzahl von Sendewiederholungen (min_anz_swdhl)
gesendet werden kann. Zu diesem Zweck kann der Client in Schritt 401 die
Größe des aktuellen
RTCP-Paketes (nächstes
zu sendendes RTCP-Paket) bestimmen, wobei angenommen wird, dass
es nur den General-NACK-Bericht-Block oder die General-NACK-Bericht-Blöcke enthält, der
notwendig ist oder die notwendig sind, um die minimale Anzahl von
Sendewiederholungen sicherzustellen, die für die Session konfiguriert
wurden. Wie oben beschrieben (siehe Gleichung 16), hängt die
Größe des aktuellen
RTCP-Paketes von der Anzahl der zu berichtenden Pakete ab.
-
Auf
Basis dieses berechneten Wertes (aktuelle_rtcp_paket_größeNACK) sowie der durchschnittlichen Größe vorheriger
RTCP-Feedback-Nachrichten (gesendet_rtcp_paket_größe) kann
die durchschnittliche RTCP-Paket-Größe (durchschn_rtcp_paket_größeNACK) in Schritt 402 mit der oben
aufgeführten
Gleichung 15 bestimmt werden. Anschließend wird in Schritt 403 die
maximale innerhalb der Client-Buffer-Zeit
freizugebende Anzahl von Sendewiederholungen (max_anz_swdhl) berechnet
(siehe Gleichung 14).
-
Auf
Basis dieser Berechnungen kann der Client in Schritt 404 bestimmen,
ob die angeforderte minimale Anzahl minimaler Sendewiederholungen
(min_anz_swdhl) freigegeben werden kann oder nicht. Wenn nicht,
kann der Client in Schritt 405 die Session mit einer anderen
Reihe von Session-Parametern wie oben beschrieben rekonfigurieren
oder neu starten.
-
Falls
max_anz_swdhl > min_anz_swdhl
ist, wurden die Session-Parameter Client-Buffer-Zeit, Anteil der RTCP-Bandbreite und
die minimale Anzahl von Sendewiederholungen so ausgewählt, dass
der Client innerhalb dieser einschränkenden Parameter betrieben
werden kann. In einem nächsten
Schritt 406 kann der Client daher den zum Bereitstellen
einer minimalen Anzahl von Sendewiederholungen notwendigen General-NACK-Bericht-Block oder die dazu
notwendigen General-NACK-Bericht-Blöcke der aktuellen Feedback-Nachricht
hinzufügen.
Ist kein (zusätzliches)
Berichten mit Loss-RLE-Bericht-Blöcken für die Session
erforderlich (siehe Schritt 407), kann der Client in Schritt 408 mit
dem Senden der aktuellen Feedback-Nachricht, die nur einen General-NACK-Bericht-Block oder mehrere
General-NACK-Bericht-Blöcke
enthält,
an den Server fortfahren.
-
Ist
für die
Session (redundantes) Berichten über
Paketverlust zwingend erforderlich, kann der Client anschließend bestimmen,
ob die aktuelle Feedback-Nachricht ausreichend Kapazität besitzt,
um nicht nur den General-NACK-Bericht-Block oder General-NACK-Bericht-Blöcke zum
Sicherstellen der minimalen Anzahl von Sendewiederholungen zu umfassen,
sondern darüber
hinaus auch die Anzahl R von Loss-RLE-Bericht-Blöcken,
die zum Sicherstellen des redundanten Berichtens über den
Paketverlust erforderlich sind.
-
Zu
diesem Zweck kann der Client anschließend in Schritt 409 die
maximale Größe der RTCP-Feedback-Nachrichten
bestimmen, die das Bereitstellen einer minimalen Anzahl von Sendewiederholungen
ermöglichen
(siehe Gleichung 17). Wie oben aufgeführt, ist die maximale RTCP-Paket-Größe, max_rtcp_paket_größe, ein
Maß, das
die durchschnittlich zulässige
Größe von Mitteilungen
zum Bereitstellen von Feedback anzeigt, wenn eine minimale Anzahl
von Sendewiederholungen sichergestellt wird.
-
Da
bekannt ist, dass max_anz_swdhl > min_anz_swdhl
ist (siehe Schritt 404), ist es darüber hinaus klar, dass die maximale
RTCP-Paket-Größe gleich
groß ist
wie die durchschnittliche RTCP-Paket-Größe einschließlich des
General-NACK-Bericht-Blockes oder der General-NACK-Bericht-Blöcke oder
größer als
diese.
-
In
Schritt 410 bestimmt der Client die in dem aktuellen RTCP-Paket
verbleibende Nutzdaten-Spanne. Mit anderen Worten, der Client bestimmt,
wie viel Byte (nutzdaten_spanne) dem aktuellen RTCP-Paket, das bereits
den General-NACK-Bericht-Block oder die General-NACK-Bericht-Blöcke umfasst,
darüber
hinaus hinzugefügt
werden können,
ohne dabei die maximal zulässige
(durchschnittliche) Größe des RTCP-Feedbacks zu verletzen.
-
Allgemein
sollen die nun folgenden nächsten
Schritte in dem in den 5 und 6 gezeigten
Ablaufdiagramm als Beispiele verstanden werden, die darstellen,
wie der verbleibende Platz (nutzdaten_spanne) innerhalb einer aktuellen
RTCP-Feedback-Nachricht
mit einem Loss-RLE-Bericht-Block oder mit Loss-RLE-Bericht-Blöcken gefüllt werden
kann, um ein (minimales) redundantes Berichten sicherzustellen,
sofern dies überhaupt
möglich
ist. Wie im Folgenden ausführlicher
beschrieben wird, kann es in einigen Fällen unmöglich sein, eine minimale Anzahl
redundanter Berichte über
verlorengegangene Pakete zu ermöglichen. In
dieser Situation kann es jedoch trotzdem wünschenswert sein, wenigstens
einen bestimmten Grad (redundanten) Berichtens bereitzustellen,
anstatt überhaupt
keinen Bericht bereitzustellen.
-
In
einem nächsten
Schritt 501 (5) kann der Client eine Anzahl
R von Loss-RLE-Bericht-Blöcken aufbauen,
die zum Ermöglichen
der angeforderten minimalen Bericht-Redundanz notwendig wären. Da
die Größe der Loss-RLE-Bericht-Blöcke zu groß sein kann,
um sie in die Nutzdaten-Spanne einzupassen, kann der Client eine
Lauflängenkompression
der Loss-RLE-Bericht-Blöcke
durchführen,
wie in Schritt 502 dargestellt. Es ist darauf hinzuweisen,
dass dieser Schritt optional ist. Anschließend wird die Größe des R
(komprimierten) Loss-RLE-Bericht-Blockes in Schritt 503 bestimmt
und der Wert wird in Schritt 504 mit der Nutzdaten-Spanne
verglichen, um zu bestimmen, ob alle R Loss-RLE-Bericht-Blöcke in die aktuelle RTCP-Feedback-Nachricht
hineinpassen, ohne dass dabei die maximal zulässige (durchschnittliche) RTCP-Paket-Größe verletzt
würde,
durch die eine angeforderte minimale Anzahl von Sendewiederholungen
ermöglicht
wird.
-
Ist
dies der Fall, werden die R (komprimierten) Loss-RLE-Bericht-Blöcke in Schritt 505 zu
der Feedback-Nachricht hinzugefügt,
anschließend überträgt in Schritt 506 der
Client eine RTCP-Feedback-Nachricht, die eine Anzahl von General-NACK-Bericht-Blöcken sowie
eine Anzahl (R) von Loss-RLE-Bericht-Blöcken umfasst. In diesem Fall
kann der Client sicherstellen, dass die minimale Anzahl von Sendewiederholungen
ermöglicht
ist und darüber
hinaus eine minimale Bericht-Redundanz bereitgestellt werden kann.
-
Ist
jedoch die Größe der R
(komprimierten) Loss-RLE-Bericht-Blöcke in Schritt 504 größer als
die Nutzdaten-Spanne, kann der Client versuchen, wenigstens einen
Teil des Berichtens über
verlorengegangene Pakete bereitzustellen. Zu diesem Zweck kann der
Client mit Schritt 507 fortsetzen und die Anzahl von in
dem aktuellen Feedback einzuschließenden Loss-RLE-Bericht-Blöcken verringern,
bis die verbleibende Anzahl (komprimierter) Loss-RLE-Bericht-Blöcke in Schritt 509 in
die Nutzdaten-Spanne der aktuellen RTCP-Feedback-Nachricht hineinpasst.
So kann der Client beispielsweise nacheinander (siehe Schritte 507, 508, 509, 511)
Bericht-Blöcke
zum Berichten der „ältesten" Pakete auslassen,
da diese bereits in früheren
Berichten berichtet worden sein könnten. Eine weitere Möglichkeit
kann es sein, Ausdünnen
durchzuführen,
bis die Größe der Loss-RLE-Bericht-Blöcke unter
die Nutzdaten-Spanne absinkt. Darüber hinaus kann der Client
auch die Wichtigkeit der berichteten Pakete berücksichtigen, wie oben bereits
beschrieben. Eine weitere Alternative kann das Kombinieren dieser
Mechanismen nach Bedarf sein.
-
In
dieser Hinsicht stellt 6 weitere Schritte des Ausbildens
einer RTCP-Feedback- Nachricht
gemäß einer
anderen Ausführungsform
der Erfindung dar. Die Schritte, die gleich den Schritten aus 5 sind,
haben gleiche Referenznummern zugewiesen bekommen, ihre Beschreibungen
werden der Kürze
wegen im Folgenden ausgelassen.
-
Die
in 6 gezeigten Schritte ermöglichen das Kombinieren des
Ausdünnens
und anderer Mechanismen zum Verringern der Größe der Loss-RLE-Bericht-Blöcke. Es
muss darauf hingewiesen werden, dass die Entscheidung darüber, ob
das Ausdünnen
angewendet werden kann (siehe Schritt 603), auf der Dienstgüte (QoS)
basieren kann, die aktuell auf der Abwärtsstrecke zu dem Client verfügbar ist
(siehe Schritte 601 und 602).
-
So
können
beispielsweise die berechneten Werte der Felder „Bruchteil verlorengegangen" innerhalb eines
Sender- und/oder Empfänger-Bericht-Blockes
der RTCP-Feedback-Nachrichten
(siehe RFC 3500, Abschnitt 6.4) evaluiert und als eine Anzeige der
vorliegenden QoS auf der Aufwärtsstrecke
beziehungsweise auf der Abwärtsstrecke
herangezogen werden. Alternativ können darüber hinaus explizit verhandelte
QoS-Maßnahmen
von dem Mobil-Kommunikationssystem bereitgestellt werden. Ist beispielsweise
die angezeigte QoS auf der Aufwärtsstrecke
hoch, so kann dies bedeuten, dass es wahrscheinlich ist, dass das
RTCP-Feedback des Client nicht durch Senden mit einem unzuverlässigen Transportprotokoll
verlorengegangen ist. Somit kann der Client entscheiden, dass eine
geringere Bericht-Redundanz als die durch den Server konfigurierte
ausreichend ist. In diesem Fall kann der Client entscheiden, Ausdünnen auf
die Loss-RLE-Bericht-Blöcke anzuwenden.
Somit ähnelt
der Schritt 605 dem Schritt 505 in 5 mit
der Ausnahme, dass der Client eine minimale Bericht-Redundanz nicht
mehr garantieren kann, wenn Ausdünnen
angewendet wurde.
-
In
einer weiteren Ausführungsform
der Erfindung kann der Client sogar entscheiden, die minimale Anzahl
von Sendewiederholungen auf Basis der verfügbaren QoS zu verringern. In
diesem Fall kann der Client in Betracht ziehen, nicht alle General-NACK-Bericht-Blöcke in das
Feedback einzuschließen,
sondern nur über die
letzten, neuesten Pakete auf eine Weise zu berichten, die der oben
für die
Schritte 507, 508, 509 und 511 in 5 beschriebenen ähnelt.
-
Eine
weitere Ausführungsform
der Erfindung betrifft die Implementierung der oben beschriebenen
verschiedenen Ausführungsformen
der Erfindung. Es wird festgestellt, dass die verschiedenen oben
genannten Verfahren sowie die verschiedenen logischen Blöcke der
oben beschriebenen Figuren mit Rechenvorrichtungen (Prozessoren)
wie beispiels weise Allzweckprozessoren, digitalen Signalprozessoren
(DSP), anwendungsspezifischen integrierten Schaltungen (ASIC), feldprogrammierbaren
Gate-Arrays (FPGA) oder anderen programmierbaren logischen Vorrichtungen
implementiert und durchgeführt
werden können.
Die verschiedenen Ausführungsformen
der Erfindung können
darüber
hinaus durch eine Kombination dieser Vorrichtungen durchgeführt oder
ausgeführt
werden.
-
Darüber hinaus
können
die verschiedenen Ausführungsformen
der Erfindung, Variationen davon und Lösungen für eine Zeitplanung unter Berücksichtigung
der QoS ebenfalls durch Software-Module implementiert werden, die
von einem Prozessor oder direkt in einer Hardware ausgeführt werden.
Darüber
hinaus kann eine Kombination von Software-Modulen und einer Hardware-Implementierung
möglich
sein. Die Software-Module können
auf jeder Art von computerlesbaren Speichermedien wie beispielsweise
RAM, EPROM, EEPROM, Flash-Speichern, Registerspeichern, Festplatten,
CD-ROM, DVD und dergleichen gespeichert sein.
