DE102006055937A1

DE102006055937A1 - Verfahren zum Übertragen eines Multicast-Streams und eines Streams

Info

Publication number: DE102006055937A1
Application number: DE102006055937A
Authority: DE
Inventors: Sami Okasha; Peter Rossmanith
Original assignee: PETER ROSSMANITH und SAMI OKAS; PROF DR PETER ROSSMANITH und SAMI OKASHA GbR
Current assignee: Mms Mainstream Media Solutions 52074 Aac De GmbH
Priority date: 2006-05-29
Filing date: 2006-11-24
Publication date: 2007-12-06

Abstract

Es werden zahlreiche Erfindungsansätze vorgestellt, um ein schnelles Umschalten, Steuern, Personalisieren und Verschlüsseln von Datenströmen in IP-Netzwerken zu ermöglichen.

Description

Die Erfindung betrifft ein Verfahren zum Übertragen eines Multicast-Streams und ein Verfahren zum Übertragen eines Streams, und zwar jeweils in einem IP-Netzwerk von einem höheren zu einem niedrigeren Gerät.
Allgemein bezieht sich die Erfindung auf eine Technologie für breitbandiges digitales Streaming über IP-Netzwerke. Es werden verschiedene Aspekte der Erfindung beschrieben, welche einzeln und in Kombination eingesetzt werden können.
Herkömmlich gibt es im wesentlichen zwei Arten der Verbreitung von Streams in IP-Netzwerken, nämlich Unicast und Multicast. Unicast ist der direkte Versand eines Datenstroms von einem Server zu genau einem Client. Das bedeutet, dass für jeden Client vom Server ein einzelner, gezielter Datenstrom über das Netz geschickt werden muss. Bei Verwendung der Multicast-Technologie hingegen stellt ein Server allen interessierten Clients gleichzeitig einen Datenstrom zur Verfügung.
Der grundlegende Vorteil von Multicast liegt auf der Hand: Wenn ein Strom für mehrere Empfänger nur einmal im Netz weitergeleitet wird, wird wesentlich weniger Bandbreite beansprucht, also weniger erforderliche Datendurchsatzmenge pro Zeit in einem Netzwerkabschnitt. Bei breit bandigen Anwendungen wie dem Übertragen von Fernsehkanälen, dem sogenannten IP-TV, macht oft erst diese Bandbreitenersparnis eine große Anzahl von Empfängern möglich.
Man nimmt beim Multicast-Versand den Nachteil in Kauf, dass keine individuelle Verbindung zu einem Client mehr besteht. Ein Vorteil einer solchen individuellen Verbindung liegt in der Möglichkeit, die Umschaltzeiten bei einem Kanalwechsel zu verkürzen:
Ein Video-Stream wird auf der Empfängerseite stets gepuffert, um eine ungleichmäßige Ankunft von Daten auszugleichen. Die Größe des Puffers, geteilt durch die Datenrate des Streams, entspricht der Pufferungszeit im Empfangspuffer.
Wenn der Client von einem Stream auf einen anderen Stream umschalten möchte, was beim herkömmlichen Fernsehprogramm einem einfachen Umschalten des Fernsehkanals entspricht, so muss zunächst der Empfangspuffer gefüllt werden, bevor der Client mit der Wiedergabe des Videoinhalts beginnen kann. Die für den Benutzer tatsächlich entstehende Umschaltzeit ist daher die Summe aus der Antwortzeit, also derjenigen Zeit von der Anforderung des neuen Streams bis zum Eintreffen des ersten Datenpakets dieses Films beim Client, ergänzt um die Pufferungszeit, bis der Empfangspuffer gefüllt ist.
Der Erfindung liegt die Aufgabe zugrunde, eine verbesserte Technik zum Umschalten von Datenströmen in IP-Netzwerken zur Verfügung zu stellen.
Nach einem ersten Aspekt der Erfindung löst diese Aufgabe ein Verfahren zum Übertragen eines Multicast-Streams in einem IP-Netzwerk von einem höheren Gerät zu einem niedrigeren Gerät, wobei das höhere Gerät den Stream in einen FIFO-Bereitschafts-Puffer schreibt.
Nach diesem Aspekt der Erfindung ist zumindest im höheren Gerät, also in demjenigen Gerät, von welchem der Stream zum niedrigeren Gerät übertragen wird, ein Puffer vorgesehen, welcher nach dem Prinzip „First In First Out" arbeitet. Dieser Puffer kann sowohl geräteintern vorgesehen sein als auch extern und an das höhere Gerät lediglich angeschlossen. Wesentlich ist, dass der FIFO-Bereitschafts-Puffer mit dem Stream gefüllt wird.
Begrifflich sei erläutert, dass der Bereitschafts-Puffer nicht der Sendepuffer ist. Stream-übertragende Geräte verfügen oft über einen Sendepuffer für die zu übertragenden Daten in einem bestehenden Stream. Ein solcher Puffer ist gerade nicht gemeint, sondern stattdessen ein Puffer, welcher lediglich dafür in Bereitschaft gehalten wird, auf die Anfrage eines neuen niedrigeren Geräts zu reagieren. Die Anfrage eines niedrigeren Geräts nach einem Stream bei einem höheren Gerät wird als „Abonnieren" bezeichnet. Der Bereitschafts-Puffer gemäß dem vorgestellten Aspekt der Erfindung soll – mit einfachen Worten ausgedrückt – für einen neu zu abonnierenden Stream vorbehalten werden.
Vorteilhaft kombiniert der vorgestellte erste Aspekt der Erfindung die Vorteile von Multicast- und Unicast-Übertragung. Im Falle einer individuellen Verbindung hat der Server, also generell das höhere Gerät, die Möglichkeit, den Prozess bis zum Beginn der Wiedergabe auf dem niedrigeren Gerät zu beschleunigen, wenn er den neuen Stream gepuffert hatte. Vor dem eigentlichen, aktuellen Stream kann das höhere Gerät nämlich eine Datenmenge in der Größe des Wiedergabe-Puffers des niedrigeren Geräts versenden, welche aus der unmittelbaren Vergangenheit des neu abonnierten Streams entstammt.
Dies ist besonders einfach, wenn der Bereitschafts-Puffer dieselbe Größe hat wie der Wiedergabe-Puffer. Ansonsten ist eine Konstellation bevorzugt, bei welcher der Bereitschafts-Puffer eine größere Größe hat als der Wiedergabe-Puffer.
Die Übertragung des im Bereitschafts-Puffer gespeicherten Abschnitts des Streams aus der unmittelbaren Vergangenheit sollte bevorzugt mit maximalem Datendurchsatz erfolgen. Die für den Benutzer am Client resultierende Umschaltzeit entspricht zwar nach wie vor der Summe aus der Antwortzeit plus derjenigen Zeit, die zum Füllen des Wiedergabe-Puffers benötigt wird. Dadurch, dass eine Datenmenge in der Größe des Wiedergabe-Puffers aus dem Bereitschafts-Puffer aber mit größtmöglichem Datendurchsatz zunächst angefordert und übertragen wird, wird die Zeit zum Füllen des Wiedergabe-Puffers gegenüber dem herkömmlich be kannten Verfahren deutlich reduziert. Für den Benutzer resultiert dies in einer geringeren Umschaltzeit.
In einer bevorzugten Ausgestaltung des Verfahrens schreibt das höhere Gerät den Stream parallel zu einer Übertragung in den FIFO-Bereitschafts-Puffer. In diesem Falle ist das höhere Gerät also in der Lage, den aktuellen Stream sowohl an bereits abonnierte niedrigere Geräte durchzureichen als auch in einen Bereitschaftspuffer zu schreiben und somit einer neuen Abonnement-Anfrage eines weiteren niedrigeren Geräts schnell gerecht zu werden.
Es ist bevorzugt, wenn das niedrigere Gerät beim Abonnieren des Streams zunächst Inhalt des FIFO-Bereitschafts-Puffers als Stromanfang und anschließend den eigentlichen Stream übertragen erhält. In diesem Falle muss das höhere Gerät lediglich nach dem Versand des Inhalts des Bereitschafts-Puffers bzw. nach dem Füllen des Wiedergabe-Puffers des niedrigeren Geräts die Datenquelle umschalten und den eigentlichen Stream in Echtzeit weitergeben.
Bevorzugt erfolgt die Pufferung und/oder die Übertragung der Streamdaten anhand einer Unterscheidung zwischen Absolutdaten und Relativdaten.
So kann beispielsweise eine Pufferung der Daten so erfolgen, dass Relativdaten nur insoweit vorgehalten werden, als ein zugehöriges Absolutdatum ebenfalls zum Abruf vorgehalten ist. Dies kann insbesondere da durch erreicht werden, dass mit Fortfall eines Absolutdatums aus dem FIFO-Puffer auch zugehörige Relativdaten aus dem FIFO-Puffer gelöscht werden, insbesondere alle Relativdaten bis unmittelbar vor dem nächstfolgenden Absolutdatum.
Alternativ und kumulativ ist es denkbar, dass aus dem Bereitschaftspuffer die vorgehaltenen Daten erst ab einem Absolutdatum an das niedrigere Gerät übertragen werden. Dies wird besonders einfach erreicht, wenn die Absolutdaten vom höheren Gerät oder von einem diesem übergeordneten Gerät eine Markierung erhalten haben.
Die Absolutdaten können im praktischen Einsatz beispielsweise I-Frames eines Videostreams sein, während die Relativdaten B- und P-Frames sein können.
Hierbei erfolgt bevorzugt ein Systemwechsel: Während der Stream-Abschnitt der unmittelbaren Vergangenheit aus dem Bereitschafts-Puffer zum niedrigeren Gerät als Unicast-Stream übertragen werden sollte, schont es die zur Verfügung stehende Bandbreite, wenn mit dem Umschalten auf den eigentlichen Stream die Übertragung als Multicast erfolgt. Nachdem das niedrigere Gerät den Inhalt seines Wiedergabe-Puffers – gefüllt aus dem Bereitschafts-Puffer – wiedergegeben hat, kann es parallel zu etwaigen anderen abonnierten, mit ihm auf einer Höhe stehenden niedrigeren Geräten den Stream vom höheren Gerät als Multicast-Stream empfangen.
Unter Umständen kann es bevorzugt sein, einen Wechsel der Übertragungsart gerade nicht vorzunehmen, sondern entweder sowohl den Streamabschnitt aus dem Bereitschaftspuffer als auch den nachfolgenden eigentlichen Stream über ein Unicastprotokoll zu übertragen oder die Daten stattdessen über ein Multicastprotokoll zu übertragen.
Unter Umständen kann es sich anbieten, sogar einen kurzen Abschnitt des Streams aus dem Bereitschafts-Puffer an das niedrigere Gerät zu übertragen, welcher erst nach der Anforderung des niedrigeren Geräts an das höhere Gerät in den Bereitschafts-Puffer geschrieben wurde. Vom Zeitpunkt der Abonnement-Anfrage des niedrigeren Geräts beim höheren Gerät wird auch bei größtmöglichem Datendurchsatz in der Regel eine gewisse Zeit vergehen, bis der Wiedergabe-Puffer im niedrigeren Gerät gefüllt ist und somit die Wiedergabe beginnen kann. Wenn auf den Zeitpunkt der Abonnement-Anfrage abgestellt wird und die „unmittelbare Vergangenheit", also der Bereitschafts-Pufferinhalt, nur bis zu diesem Zeitpunkt an das niedrigere Gerät übertragen wird, entsteht beim Umschalten auf den Echtzeit-Stream im Multicast-Verfahren eine zeitliche Lücke von der Dauer der Übertragung des Inhalts vom Bereitschafts-Puffer zum Füllen des Wiedergabe-Puffers.
Im Idealfall wird deshalb aus dem – permanent nachgeschriebenen – Bereitschafts-Puffer ein dementsprechend langer Abschnitt des Streams noch zum Wiedergabe-Puffer mit größtmöglicher Durchsatzrate gesendet, bevor endgültig auf den Multicast-Stream umgeschaltet wird.
Es ist von besonderem Vorteil, wenn der Stream-Anfang, also der gespeicherte Abschnitt aus dem Bereitschafts-Puffer, mit einem höheren Datendurchsatz zum niedrigeren Gerät übertragen wird als anschließend der eigentliche Stream. Dadurch wird eine Beschleunigung der Umschaltzeit für die Wahrnehmung des Benutzers erreicht.
Das höhere und/oder das niedrigere Gerät ist bevorzugt ein Multicast-Router und schreibt eine Mehrzahl von Streams in einen FIFO-Bereitschafts-Puffer. Auf diese Weise kann eine Mehrzahl von IP-TV-Kanälen in einen Bereitschafts-Puffer oder in mehrere Bereitschafts-Puffer geschrieben werden, so dass auch bei einer größeren Anzahl von zur Verfügung stehenden Kanälen, also insbesondere Video- oder Audioprogrammen, ein beschleunigtes Umschalten möglich wird.
Dem niedrigeren Gerät ist bevorzugt ein Client nachgeordnet. Bei einer solchen Netztopographie liegt neben einem übergeordneten höheren Gerät, also beispielsweise einem zentralen Server, ein niedrigeres Gerät als Wegpunkt vor, wobei unter dem niedrigeren Gerät der Client folgt.
Es ist jedoch auch vorteilhaft denkbar, dass dasjenige Gerät, welches als Wegpunkt dient, welches also unterhalb des zentralen Servers angeordnet ist, zusätzlich zum zentralen Server oder alternativ zum zentralen Server einen Bereitschafts-Puffer aufweist und in der beschriebenen Weise beschreibt.
Das Speisen eines neu abonnierenden niedrigeren Geräts aus einem Bereitschafts-Puffer ist bei einer Netztopographie mit mehreren Hierarchieebenen bereits auf jeder Ebene einzeln als Erfindung anzusehen, insbesondere aber bei einer Installation auf jeder Ebene oberhalb der Clients.
Nach einem zweiten Aspekt der Erfindung löst die gestellte Aufgabe ein Verfahren zum Übertragen eines Streams in einem IP-Netzwerk von einem höheren Gerät zu einem niedrigeren Gerät, wobei der Stream Absolutdaten und Relativdaten zur Wiedergabe aufweist, und wobei das höhere Gerät einen retranskodierten Stream überträgt
Dies sei zunächst mit einfachen Worten erläutert:
Wenn ein Endgerät einen Kanal wechselt oder sich neu auf einen Kanal abonniert, müsste das Endgerät im Stand der Technik so lange warten, bis im Stream zum nächsten Mal ein Datensatz mit Absolutdaten vorkommt.
Streams werden zur Komprimierung in Absolutdaten und Relativdaten unterteilt. So werden beispielsweise MPEG-2 oder MPEG-4-Ströme mit einer Folge von sogenannten Frames komprimiert.
In diesen Komprimierungsarten gibt es unterschiedliche Frames, die unterschiedliche Informationen tragen. Man unterscheidet im wesentlichen I-Frames, B-Frames und P-Frames. In verständlichen Worten beschrieben ist ein I-Frame ein absolutes, statisches Bild, wohingegen in den B-Frames und P-Frames Relativdaten zu dem absoluten Bild enthalten sind, also Pi xeländerungen ausgehend von dem I-Frame. Somit ist der I-Frame ein Absolutdatum, die B- und P-Frames hingegen sind Relativdaten.
Um die Wiedergabe starten zu können, benötigt das Endgerät einen vollständigen I-Frame. Der zeitliche Abstand zwischen zwei I-Frames in einem Stream beträgt meist zwischen 0,2 und 5 Sekunden. Wenn ein Benutzer am Endgerät auf den nächsten I-Frame mehr als eine Sekunde lang warten muss, empfindet er dies meist als unangenehm.
Der vorgestellte Aspekt der Erfindung verkürzt die Wartezeit, indem auf die Anfrage hin dergestalt umgerechnete Daten übertragen werden, dass ein I-Frame früher als natürlich vorkommend erzeugt und übertragen wird, bevorzugt sofort.
Der Server berechnet auf ein Neuabonnement eines Endgeräts den gerade laufenden Stream also dergestalt um, dass ein Absolutbild, also ein I-Frame, bevorzugt bereits als Startbild berechnet und kodiert wird. Bis zum nächsten natürlich auftretenden I-Frame müssen dann die B-Frames und P-Frames ebenfalls umgerechnet werden, um auf den speziell errechneten Start-I-Frame zu passen.
Da dieser Umrechenvorgang, das sogenannte Retranskodieren, für jede Abonnement-Anfrage einzeln durchgeführt werden muss, wird viel Rechenkapazität im Server gebunden. Nach diesem Vorschlag steigt also zwar der Benutzerkomfort erheblich, es kann bei einer großen Anzahl von Endgeräten und häufigem Umschalten der Endgeräte zwischen den Kanä len jedoch ein beachtlicher Teil der Rechen- und Speicherressourcen im Stream-Server für das ständige Neuberechnen der Daten für die sofortige Initiierung eines Audio-/Video-Stroms absorbiert werden.
Dieses Problem wird gelöst, wenn das höhere Gerät einen retranskodierten Stream-Anfang in einen Zwischenspeicher schreibt und dem niedrigeren Gerät beim Abonnieren des Streams zunächst den zwischengespeicherten Stream-Anfang überträgt.
Dieser bevorzugten Ausgestaltung des zweiten Aspekts der Erfindung liegt die Erkenntnis zugrunde, dass der Server – oder generell das höhere Gerät – einen retranskodierten Abschnitt des laufenden Streams von Vorteil auch ohne vorhandene Abonnement-Anfrage errechnet und in einen Bereitschafts-Zwischenspeicher schreibt.
Im Gegensatz zu den vorstehend beschriebenen Systemen, bei welchen das höhere Gerät passiv auf eine Abonnement-Anfrage eines niedrigeren Geräts reagiert und erst dann mit der Retranskodierung beginnt, wird nach dieser vorgestellten Ausgestaltung des zweiten Aspekts der Erfindung permanent retranskodiert und ein entsprechender Stream in Bereitschaft vorgehalten.
Der Vorteil liegt darin, dass über die permanente Vorberechnung die Rechenkapazität, welche maximal auftreten kann, klar begrenzt ist. Das höhere Gerät erzeugt über die permanente Retranskodierung und Zwi schenspeicherung gewissermaßen eine „Zeitscheibe", welche die Zeitdifferenz zwischen zwei natürlich auftretenden I-Frames im Stream verringert.
Es wird vorgeschlagen, dass dem niedrigeren Gerät der zwischengespeicherte Stream-Anfang als Unicast-Stream zugesendet wird. Mit einem Unicast-Stream kann auf eine Abonnement-Anfrage des niedrigeren Geräts zeitnah und individuell reagiert werden. Das höhere Gerät sendet auf die Abonnement-Anfrage des niedrigeren Geräts bevorzugt aus dem vorhandenen Zwischenspeicher den retranskodierten Stream-Anfang so lange, bis im Stream der nächste I-Frame – bzw. abstrakt: das nächste Absolutdatum – auftaucht. Die Unicast-Verteilung wird somit als Hilfsmittel für das Multicast-System verwendet. Nachdem der nächste I-Frame im Stream aufgetaucht ist, wird die Unicast-Übertragung des retranskodierten Stream-Anfangs beendet, und der ursprüngliche Stream wird im Multicast-Verfahren weiter übertragen.
Es wurde bereits erläutert, dass die Absolutdaten I-Frames sein können und dass die Relativdaten B- und P-Frames sein können. Die Komprimierung in I-Frames, B-Frames und P-Frames ist ein bewährtes Verfahren zum Komprimieren von Audio-/Video-Streams.
Das höhere Gerät retranskodiert bevorzugt den Stream-Anfang aus Daten von einem Zwischenpunkt zwischen zwei Absolutdaten bis zu dem nächstfolgenden Absolutdatum. In dem dargestellten Beispiel eines Audio-/Video-Streams würde das höhere Gerät einen Stream-Anfang durch Retranskodieren errechnen, bis der nächstfolgende I-Frame im Stream auf tritt. Der Zwischenpunkt ist idealerweise zumindest etwa zeitlich in der Mitte zwischen zwei natürlich auftretenden I-Frames angesetzt.
Bei einer bevorzugten Ausgestaltung des Verfahrens errechnet und zwischenspeichert das höhere Gerät zwischen zwei Absolutdaten eine Mehrzahl von retranskodierten Stream-Anfängen, insbesondere mehrere pro Sekunde. Auf diese Weise werden gleich mehrere Zeitscheiben erzeugt, so dass die statistisch zu erwartende Wartezeit eines neu abonnierenden niedrigeren Geräts deutlich verringert ist, nämlich auf nur diejenige Zeit bis zum nächsten retranskodierten Stream-Anfang. Wenn beispielsweise vier Stream-Anfänge durch Retranskodieren zwischen zwei Absolutdaten im ursprünglichen Stream errechnet und zwischengespeichert werden, beträgt die durchschnittliche Wartezeit nicht mehr – wie herkömmlich – die Hälfte der Zeit zwischen zwei natürlich auftretenden Absolutdaten, sondern nur noch ein Fünftel dieser Zeit, also ein Zehntel des zeitlichen Abstands zweier Absolutdaten im ursprünglichen Stream.
So kann beispielsweise an einer zentralen Stelle für jeden zu übertragenden Kanal gemäß einem Auflösungsparameter der entsprechende Datenbestand aus retranskodierten Stream-Anfängen errechnet werden und für ausreichende Zeit im Speicher vorgehalten werden. Der Parameter bestimmt zum einen die statistisch zu erwartende Umschaltverzögerung, zum anderen die benötigte Rechenkapazität.
Wenn der Parameter so eingestellt wird, dass die zeitliche Auflösung der Stream-Anfänge dem natürlichen zeitlichen Abstand zweiter Absolut daten entspricht, wird nur ein Stream an niedrigere Geräte weitergegeben, nämlich der ursprüngliche Stream. Hierfür ist keine Rechenkapazität erforderlich. Wenn der Parameter jedoch so gesetzt wird, dass zahlreiche Stream-Anfänge zwischen zwei natürlich auftretenden Absolutdaten errechnet werden sollen, so sinkt die statistisch zu erwartende Umschaltverzögerung, hingegen steigt die benötigte Rechenkapazität.
Besonders bevorzugt ist es, wenn der Parameter so gesetzt wird, dass die zu erwartende Umschaltverzögerung minimal wird. Bei einem MPEG-Videostrom wäre dies dann der Fall, wenn für jeden Frame zwischen zwei natürlich auftretenden I-Frames, also für jeden P-Frame und für jeden B-Frame, der Datenbestand retranskodiert und zu einem Stream-Anfang umgerechnet und gespeichert wird. Jeder retranskodierte Stream-Anfang enthält infolge der Retranskodierung zunächst einen neu generierten I-Frame, danach B-Frames und P-Frames bis zur nächsten natürlich auftretenden I-Frame.
Durch den künstlich errechneten I-Frame zu Beginn des retranskodierten Streams kann der Datenbestand als Beginn eines beim Empfänger ankommenden Video-Stroms sofort abgespielt werden. So können die Frames in einem MPEG-Videostrom beispielsweise in einer Frequenz von 24 Frames pro Sekunde vorliegen. Entsprechend müsste der zentrale Server – oder generell das höhere Gerät – neben dem ursprünglichen Stream 24 retranskodierte Stream-Anfänge in einem oder mehreren Zwischenspei cher(n) vorhalten. Die zu erwartende Umschaltzeit beim Benutzer wäre allerdings sehr kurz und damit sehr komfortabel.
Es ist unmittelbar ersichtlich, dass die beschriebene Technologie nicht auf MPEG-Videoströme begrenzet ist. Diese sind lediglich als Beispiel aufgeführt.
Das höhere Gerät ist beispielsweise ein zentraler Stream-Server. Bei einer solchen Netztopographie sind die Aufbaukosten des Netzes minimal.
Bevorzugt schreibt ausschließlich oder ebenfalls das niedrigere Gerät retranskodierte Stream-Anfänge in einen Zwischenspeicher. Bei einer solchen Netztopographie sind in den Weg zwischen dem zentralen Stream-Server und dem Endgerät Wegpunkte eingefügt, ab welchen im Unicast-Verfahren personalisierte Stream-Anfänge versendet werden können. Dies erfordert weniger Bandbreite im Netz.
Demgemäß wird vorgeschlagen, dass das höhere Gerät ein Wegpunkt zwischen einem zentralen Stream-Server und einem Client ist, insbesondere ein DSLAM oder ein Router hinter einem Hausanschluss. Bei beiden Alternativen wird die erforderliche Bandbreite so lange wie möglich gering gehalten, weil über Multicast versendet werden kann.
Bei dem vorgestellten System zur Vorberechnung des Datenbestands in Form von Stream-Anfängen in einem Zwischenspeicher kann jeder Audio-/Video-Strom, der von dem System bearbeitet werden soll, einmal an zentraler oder dezentraler Stelle analysiert und dort der Datenbestand be rechnet werden. Das bevorzugte zentrale Stromanalysesystem kann auch Informationen über den Aufbau des jeweiligen Stroms speichern. Insbesondere kann gespeichert werden, wann in den Strömen I-Frames – oder generell: Absolutdaten – vorkommen. Um eine genaue Zeitberechnung vornehmen zu können, muss das System über genaue Zeitangaben verfügen.
Um eine bessere Verteilung des Datenbestands zur schnellen Auslieferung zu ermöglichen, bietet es sich an, abhängig vom Backbone-Netz des Serverproviders, mehrere Pufferebenen einzurichten. Bei einer dergestalt aufgebauten Netztopographie sind an wichtigen Knotenpunkten der Infrastruktur des Service-Providers Pufferungen des Datenbestands installiert. Somit können Engpässe, die bei einer rein zentralen Verteilung auftreten könnten, aufgefangen werden. Die Mindestreaktionszeit des Datenbestands und die Höchstreaktionszeit des Datenbestand gegenüber dem Client werden auf diese Weise begünstigt.
Das vorgeschlagene Verfahren kann so ausgestaltet werden, dass der Multicast-Stream mittels eines Puffers geringfügig verzögert übertragen wird, so dass bei einem Umschalten der Übertragung von retranskodiertem Stream-Anfang zum Multicast-Stream eine Zeitlücke im wesentlichen von der Dauer des Retranskodierens vermieden wird.
Unter speziellen Bedingungen kann es nötig sein, solche zusätzlichen Maßnahmen einzugehen, um zu gewährleisten, dass der Datenbestand des höheren Geräts aus dessen Zwischenspeicher in jedem Fall vor dem ursprünglichen Datenstrom bereitsteht und an das niedrigere Gerät weitergegeben werden kann: Es versteht sich, dass der retranskodierte Stream immer eine geringe zeitliche Verzögerung aufweist, da zum Retranskodieren zunächst der ursprüngliche Stream vorliegen muss, woraufhin sich das Retranskodieren anschließt. Für das Retranskodieren ist eine bestimmte Rechenzeit erforderlich.
Wenn von einem retranskodierten Stream-Anfang aus dem Zwischenspeicher zum ursprünglichen Stream umgeschaltet wird, springt die Wiedergabe beim niedrigeren Gerät bzw. beim Client um die Zeitdauer der Retranskodierungsberechnung. Der Betrachter sieht in diesem Falle eine Lücke.
Dies kann über eine Verzögerung des ursprünglichen Datenstroms ausgeglichen werden. Diese sollte nach Möglichkeit recht klein gehalten werden. Wenn die Verzögerung im Originalstream zu klein ist, entsteht allerdings ebenfalls beim Umschalten vom retranskodierten Stream-Anfang zum Originalstrom die Zeitlücke. Wenn allerdings die Verzögerung zu groß ist, dann sieht der Empfänger beim Umschalten vom retranskodierten Stream-Anfang zum Originalstream eine Wiederholung.
Es kann jedoch eine Steuerung vorgesehen sein, welche die doppelten Daten im Wiedergabe-Puffer erkennt und den Multicast-Stream ohne Wiederholung nahtlos an den retranskodierten Stream-Anfang anschließt.
Im folgenden sei ein erstes Anwendungsbeispiel mit einem Wegpunkt in Gestalt eines Servers am DSLAM geschildert.
Bei Internet Service Providern liegt es nahe, als Wegpunkte beispielsweise dem DSLAM oder einen Server zu wählen, welcher direkt an den DSLAM angeschlossen ist. In diesem Fall kann die Verteilung der Audio-/Video-Daten von der Einspeisung bis zu den Wegpunkten per Multicast oder Unicast erfolgen. Vom Wegpunkt können die Daten individuell per Unicast über den DSLAM an den jeweiligen Empfänger übertragen werden.
Da DSLAMs meist bis zu 4.000 Endkunden versorgen können, kann der Service Provider praktisch uneingeschränkt entscheiden, ob die Datenverteilung oberhalb des DSLAMs per Unicast oder Multicast geschehen soll. Die DSLAMs sind so große Multiplikatoren, dass diese ohne weiteres auch per Unicast versorgt werden könnten, auch wenn davon ausgegangen werden muss, dass bei einer überschaubaren Anzahl an angebotenen Kanälen ohnehin jeder der verfügbaren Kanäle als Folge der großen Anzahl Nachfrager unterhalb am Wegpunkt anliegt.
Bei ausreichender Backplane des DSLAMs, also bei ausreichendem möglichen Datendurchsatz durch den DSLAM, ist ab dem Wegpunkt eine individuelle Versorgung nach dem vorstehend genannten Prinzip möglich.
Diese Methode hat überdies den Vorteil, dass kein Multicast-Routing bis zum Endkunden nötig ist. Multicast-Routing ist nach dem Stand der Technik recht aufwendig. Insbesondere können auch Geräte versorgt werden, die bei dem Endkunden hinter einem Network Address Translation (NAT-)Gerät stehen.
Während das Multicast-Verfahren mit einem push-Verfahren vergleichbar ist, entspricht das Unicast-Verfahren eher einem pull-Verfahren. Deshalb können Router im Unicast-Verfahren auf dem Weg zum Endkunden durchlaufen werden.
Das zentrale Server-System, oder generell das höhere Gerät, muss zu den DSLAMs lediglich eine solche Anzahl Streams senden, welche das Produkt aus der Kanalzahl und der Aufteilungsfeinheitszahl ist. Die Kanalzahl entspricht der Anzahl der Kanäle, die empfangen können werden sollen. Die Aufteilungsfeinheitszahl entspricht derjenigen Anzahl von Stream-Anfängen, welche pro Zeitintervall zwischen zwei natürlich auftretenden Absolut-Frames im Stream eingefügt werden sollen. Wenn also beispielsweise 50 Kanäle empfangbar sein sollen und zu jedem Frame ein Stream-Anfang retranskodiert werden soll, also beispielsweise 24 Stream-Anfänge pro Sekunde bereitgestellt werden sollen, muss lediglich eine Gesamtzahl von 1200 Streams zu den Wegpunkten übertragen werden. Hiervon ist jeder vierundzwanzigste Stream der ursprüngliche Stream eines der 50 Kanäle. Die übrigen Streams sind retranskodierte Streams, die beim Umschalten einen quasi-sofortigen Beginn der Wiedergabe ermöglichen. Diese Anzahl ist recht gering im Vergleich dazu, dass an einem DSLAM ohne weiteres 4.000 Endgeräte oder zumindest 4.000 DSL-Leitungen angeordnet sein können.
Als Alternativen kommen in Betracht, dass der Wegpunkt den benötigten Stream-Anfang als Unicast bei einem übergeordneten Gerät anfordert oder einen entsprechenden Multicast-Stream abonniert. In diesem Falle wird die oberhalb des DSLAMs zur Verfügung stehende Bandbreite geschont, beim Umschalten auf einen Kanal, welcher am DSLAM nicht in Bereitschaft vorgehalten wird, ist jedoch zumindest die Antwortzeit des höheren Geräts auf die Anforderung des DSLAMs abzuwarten.
Im folgenden sei als ein zweites Anwendungsbeispiel eine Konstellation beschrieben, bei welcher ein Router beim Endkunden hinter einem DSLAM als Wegpunkt eingesetzt ist:
Endkunden haben meist einen Router, auf welchem die Hausverkabelung zusammenläuft. Wird der Router oder ein anderes Gerät beim Endkunden als Wegpunkt gewählt, so kann vorteilhaft bis zu diesem Wegpunkt eine multicastfähige Infrastruktur bestehen.
Der Vorteil bei diesem Aufbau ist eine bandbreitenschonende Verteilung. Wenn zwei oder mehr Endgeräte aus dem gleichen Anschluss den gleichen Kanal anfordern, so wird der Kanal dennoch nur einmal über den DSLAM geschickt, da die Verteilung auf die beiden Endgeräte erst ab dem Wegpunkt beim Endkunden geschieht.
Diese Methode hat einige Vorteile, die im folgenden erläutert werden. Sie setzt bevorzugt einen intelligenten Wegpunkt sowie nicht allzu sehr schwankende Antwortzeiten des Wegpunkts zu einem Messstrom voraus. Wenn diese Voraussetzung nicht ohne weiteres erfüllt werden, können sie durch zusätzliche Maßnahmen ausgeglichen werden. Wenn der Provider bestimmte Antwortzeiten garantiert, was in der Regel als Quality of Service („QOS") bezeichnet wird, gestaltet sich die Verteilung recht einfach.
Der Wegpunkt, also in diesem Fall der Router bei dem Endkunden, misst zunächst eine Verzögerung, im folgenden als d bezeichnet. Hierzu nimmt der Wegpunkt zunächst einen Übertragungstest zur Berechnung der Ankunftszeit der I-Frames vor. Dazu kann der Wegpunkt den Aufbau des Stroms analysieren und feststellen, wie groß die Verzögerung d der I-Frames vom Versenden am zentralen Server bis zum Eintreffen beim Wegpunkt ist. Falls die Analyse des Stroms für den Wegpunkt zu aufwendig ist, so kann stattdessen die Verzögerung eines beliebigen anderen Messstroms, also eines beliebigen Datenstroms, gemessen werden, solange sich die berechnete Verzögerung d äquivalent zur Verzögerung der I-Frames ergibt.
Der Verzögerungsparameter d ist kennzeichnend für die Verbreitungsgeschwindigkeit des Datenstroms zum Endkunden und kann von der momentan zur Verfügung stehenden Bandbreite und Antwortzeit abhängen, also schwanken. Sie ist aber unabhängig vom Inhalt des eigentlichen Datenstroms, da lediglich die Verbreitungsgeschwindigkeit gemessen wird.
Anhand der Informationen über den Aufbau und den Zeitpunkt des Vorkommens der I-Frames des zentralen Servers und anhand des Wertes d kann der Wegpunkt für alle Datenströme die Ankunftszeiten der I-Frames mit recht hoher Genauigkeit vorhersagen.
Um robust Schwankungen in der Verbreitungsgeschwindigkeit und damit im Parameter d auffangen zu können, wird die Verzögerung d eines Datenstroms bevorzugt ständig gemessen, sobald ein Datenstrom oder mehrere Datenströme über den Wegpunkt gesendet werden.
Die Informationen über die Übertragungsverzögerung d können vom Wegpunkt und/oder vom Server, also generell von jedem höheren oder niedrigeren Gerät in der Netztopographie, dazu verwendet werden, gezielt einen Stream-Anfang anzufordern, welcher sich nahtlos an den eigentlich zu abonnierenden Multi-Stream umschalten lässt.
Dies lässt sich mit einem dritten Aspekt der Erfindung ausnutzen, gemäß welchem die Aufgabe auch ein Verfahren zum Übertragen eines Multicast-Streams in einem IP-Netzwerk von einem höheren Gerät zu einem niedrigeren Gerät löst, wobei der Stream Absolutdaten und Relativdaten zur Wiedergabe aufweist, und wobei das niedrigere Gerät auf Abonnieranforderung eines nachgeordneten Geräts zunächst einen Stream-Anfang mit einer Dauer anfordert, welche abhängig von einer zu erwarten den Ankunftszeitspanne der nächsten Absolutdaten beim niedrigeren Gerät errechnet wird.
Wird ein Kanal vom Endkunden angefordert, so schickt das Endgerät die (Multicast-)Anfrage an den Wegpunkt. Der Wegpunkt gibt diese Anfrage zunächst jedoch nicht an den übergeordneten Router weiter, sondern verfährt wie folgt:
Wie vorstehend beschrieben, kennt der Wegpunkt durch einfache Berechnung oder Mitteilung des Stromanalysesystems für alle Datenströme die Ankunftszeiten der nächsten Absolutdaten, also beispielsweise der nächsten I-Frames. Er wählt nun die Ankunftszeit des ersten I-Frames, bis zu dessen Ankunftszeit t1 noch mindestens die Zeit k verstreicht.
Dabei ist k ein Zeitparameter, welcher mindestens der Summe aller Prozess- und Netzwerklaufzeiten entspricht, die bis zum frühestmöglichen Abspielbeginn eines I-Frames aus dem gewählten Multicast-Stream vergehen. Es könnte aber auch Gründe geben, k sogar länger zu wählen und damit eine längere Unicast-Übermittlung zu erreichen.
Wenn von der Ankunftszeit der aktuelle Zeitpunkt sowie gegebenenfalls eine meist sehr kurze Unicast-Antwort- und Verarbeitungszeit subtrahiert werden, so ergibt sich die Länge der erforderlichen Abspielzeit des gewünschten Datenbestandes.
Durch die Länge und die Endzeit t1 ist dieser Datenbestand vollständig charakterisiert. Daher kann der Wegpunkt nun diesen Datenbe stand für das sofortige Initialisieren des Datenstroms bei dem Verteilungssystem des zentralen Stromanalysesystems anfordern und diesen zum Endgerät weiterleiten.
Zudem sendet der Wegpunkt zum Zeitpunkt t1 minus d die Multicast-Anfrage für den gewünschten Kanal weiter und sendet diesen Strom im Anschluss an den Datenbestand aus dem Zwischenspeicher an das Endgerät. Für das Endgerät entsteht hierdurch die Illusion eines ununterbrochenen Stroms.
Diese Methode beseitigt viele der Probleme, welche bei Umschaltmethoden nach herkömmlichem Stand der Technik aufkommen, und ermöglicht ein robustes, schnelles Umschalten.
Zum einen wird der Datenbestand für die sofortige Initiierung beispielsweise als Datenpaket per Unicast versendet. Daher geschieht die Übertragung mit der gesamten Bandbreite, also nicht wie bei einer Multicast-Verteilung als Stream. Der Datenbestand kommt also schnell bei dem Wegpunkt und damit bei dem Endgerät an.
Da das Datenpaket mit einem I-Frame beginnt, kann mit dem sofortigen Abspielen unmittelbar angefangen werden. In dieser Hinsicht ist der Vorgang von Seiten der Infrastruktur optimal gelöst.
Zum anderen muss nur minimaler Aufwand im Backbone-Netz des Service Providers betrieben werden. Modifikationen sind lediglich an zentraler Stelle nötig, wobei optional mehrere cache-Ebenen installiert werden können, und wobei optional beim Router des Endkunden ebenfalls Modifikationen nötig sein können.
Ein weiterer Vorteil des vorstehend beschriebenen Systems liegt darin, dass bis auf wenige Steuerinformationen keine zusätzliche Bandbreite für einen erheblich beschleunigten Umschaltvorgang benötigt wird.
Im folgenden sei als ein drittes Anwendungsbeispiel eine Netztopographie beschrieben, bei welcher ein Server am DSLAM als Wegpunkt dient, wobei eine Zusatzverteilung beim Endkunden vorgesehen ist:
Wie vorstehend erläutert wurde, soll zum schnellen Umschalten zwischen zwei Kanälen bei jedem Kanalwechsel ein Unicast-Strom zum Endgerät personalisiert werden. Wenn jedoch davon auszugehen ist, dass beim Endkunden kein Gerät steht, welches leistungsstark genug ist, um jedem Empfangsgerät einen personalisierten Strom zur Verfügung zu stellen, bietet sich eine weitere Möglichkeit an, die Last zu verteilen:
Wie im ersten Anwendungsbeispiel beschrieben, dient ein Server oder der DSLAM selbst als Wegpunkt. Das Endgerät ist nun aber nicht das Anzeigegerät beim Endkunden, sondern ein anderes Gerät, beispielsweise der Router beim Endkunden.
Dieses Gerät leitet die Anfragen jedes Endgerätes des Endkunden weiter an den Wegpunkt. Wenn jedoch zu einem Endgerät der gleiche Kanal gesendet werden soll, welcher schon an ein weiteres Endgerät hinter demselben Router gesendet wird, so sendet der Router an das hinzuge kommene Endgerät zunächst nur das Datenvolumen des vom Wegpunkt erhaltenen personalisierten Stroms. Anschließend dupliziert es den ohnehin schon am Gerät anliegenden Audio-/Video-Datenstrom und sendet diesen parallel an beide Endgeräte. Das personalisierte Datenvolumen ist derjenige Teil des Audi-/Video-Datenstroms, der für eine sofortige Initiierung der Wiedergabe notwendig ist.
Bei diesem Netzaufbau kommt zum ersten Wegpunkt, dem DSLAM oder einem dort angeordneten Server, somit ein zweiter Wegpunkt hinzu, nämlich bevorzugt der zentrale Router beim Endkunden. Dieser zweite Wegpunkt nutzt die an ihm anliegenden Streams soweit möglich doppelt bzw. mehrfach, so dass es unnötig wird, denselben Stream mehrfach parallel zum Endkundenrouter zu senden.
Nach einem vierten Aspekt der Erfindung löst die gestellte Aufgabe ein Verfahren zum Übertragen eines Multicast-Streams in einem IP-Netzwerk von einem höheren Gerät zu einem niedrigeren Gerät, wobei das höhere Gerät zusätzlich zum ursprünglichen Multicast-Stream einen retranskodierten und/oder zeitlich verzögerten Offset-Stream zum Abonnieren bereit hält.
Anstatt für alle – oder je nach Bandbreitenbeschränkung gegebenenfalls nur einige – Einstiegszeitpunkte spezielle Datenbestände herzustellen und an die Wegpunkte zu verbreiten, ist es nach diesem Aspekt auch vorteilhaft, für jeden dieser Einstiegsoffsets jeweils einen Multicast-Stream zu erstellen, in welchem die I-Frames oder allgemein die Startpunkte zeitlich verschoben sind. Dies kann durch einfache Verzögerung erfolgen, jedoch auch durch Retranskodierung.
Der Wegpunkt oder das Empfangsgerät selbst berechnet nun die geschätzte Ankunftszeit eines Multicast-Streams, etwa durch Addition von d auf seine aktuelle Zeit, und wählt dann denjenigen Strom, in welchem möglichst bald nach dieser geschätzten Anfangszeit ein I-Frame erscheinen wird. Diese Information erhält es bevorzugt in einem eigenen Strom niedriger Bandbreite vom Stromanalysesystem.
Nach einem fünften Aspekt der Erfindung löst die Aufgabe ein Verfahren zum Übertragen eines Streams in einem IP-Netzwerk von einem höheren Gerät zu einem niedrigeren Gerät, wobei der Stream zunächst multiplext oder demultiplext als Datenursprung verwendet wird, so dass sich mehrere Teilströme ergeben, woraufhin diese Teilströme übertragen und vom niedrigeren Gerät zusammengesetzt werden.
Auf diese Weise kann durch gezieltes Übertragen der Teilströme beispielsweise eine Verschlüsselung mit einem geringen Datenvolumen erreicht werden.
Die Netztopographie ist bevorzugt so aufgebaut, dass der Stream vom niedrigeren Gerät per Unicast an einen Client übertragen wird.
Das Prinzip, auf welchem der fünfte vorgestellte Aspekt der vorliegenden Erfindung basiert, sei im folgenden in einfachen Worten erläutert:
Der Erfindungsaspekt basiert auf dem Grundgedanken, dass der Gesamtstrom in einen Komponentenstrom und einen Steuerstrom aufgeteilt wird. Der Komponentenstrom wird aus einem oder mehreren Multicast-Strömen zusammengesetzt. Der Steuerstrom ist in den meisten Fällen ein Unicast-Strom. In manchen Fällen kann es ökonomischer sein, den Steuerstrom ebenfalls als Multicast-Strom zu versenden.
Die vorgeschlagene Technologie ermöglicht es, bandbreitensparend individuelle Informationen an viele Teilnehmer zu übertragen, solange die Informationen zumindest Fragmente gemeinsam aufweisen. Hierzu werden drei Anwendungsbeispiele beschrieben. Das erste Beispiel zeigt, wie ein schnelles Umschalten eines Audio-/Video-Stroms erreicht werden kann. Das zweite Beispiel ermöglicht eine bandbreitenschonende personalisierte Verschlüsselung. Das dritte Beispiel zeigt, wie unter Hinzunahme von Priorisierungen eine möglichst durchgehende Audio-/Video-Übertragung erreicht werden kann.
Video-/Audio-Ströme, welche mit allgemein bekannten Komprimierungsverfahren, wie beispielsweise MPEG-2 oder anderen, komprimiert sind, bestehen aus einer Folge von sogenannten Frames. Es gibt verschiedene Frames, die unterschiedliche Informationen tragen. Dies wurde vorstehend bereits erläutert. Die drei unterschiedlichen Frame-Arten werden im Folgenden jeweils als Frame-Familien bezeichnet.
Wenn ein komprimierter Strom dekomprimiert werden soll, müssen zunächst in einem Zwischenspeicher genug Daten gesammelt werden, um den Audio-/Video-Strom zu initiieren. Hierzu wird der Wiedergabepuffer benutzt. Des weiteren muss der Strom vollständig sein. Wenn Frames fehlen, so kommt es zu Bildstörungen, zum Aussetzen der Wiedergabe oder zum Stoppen des Abspielens. Dabei macht sich der Verlust eines I-Frames in der Wiedergabe stärker bemerkbar als der Verlust eines P-Frames oder eines B-Frames.
In dem Verfahren nach dem fünften Aspekt der vorliegenden Erfindung wird das Ursprungssignal zunächst demultiplext, also in die einzelnen Bestandteile aufgeteilt. Diese können beispielsweise Tonbytes und Bildbytes umfassen, aber auch anders aufgeteilt werden. Die einzelnen Teilströme werden über die Infrastruktur übertragen und an geeigneter Stelle des Übertragungswegs zur Empfängergruppe oder erst bei der Empfängergruppe selbst zusammengesetzt.
Wird der Strom auf dem Übertragungsweg zusammengesetzt, so geschieht die weitere Übertragung zur Empfängergruppe bevorzugt per Unicast.
Das ursprüngliche Hauptsignal kann nun in mehreren Varianten gesendet werden. Diese können sich beispielsweise durch die Bitraten unterscheiden. Sie können auch jeweils einzelne Frame-Familien oder eine Kombination aus diesen übertragen.
Im allgemeinen wird der Strom auf der Empfängerseite aus dem Komponentenstrom und dem Steuerstrom zusammengesetzt. Der Kompo nentenstrom weist diejenigen Daten auf, welche an alle Empfänger gerichtet sein sollen, während der Steuerstrom die personalisierten Daten umfassen kann.
Der Komponentenstrom ist nicht personalisiert und kann somit von allen adressierten Empfängern empfangen werden. Eine Kombination aus den Teilströmen im Komponentenstrom muss nicht notwendigerweise das ursprüngliche Hauptsignal ergeben. Vielmehr können wesentliche Daten für die Wiedergabe ausgespart sein. In diesem Falle ist für die Wiedergabe neben dem Komponentenstrom auch der Empfang des Steuerstroms notwendig.
Diejenigen Daten, welche für den Zusammenbau eines vollständigen Stroms fehlen, sowie gegebenenfalls zusätzliche Daten, werden durch den sogenannten Steuerstrom gesendet. Der Steuerstrom ist personalisiert und für eine Gruppe von Empfängern oder einen Empfänger alleine bestimmt.
Somit ist es möglich, dass eine Empfängergruppe einige Ströme per Komponentenstrom empfängt und andere per Steuerstrom, so dass ein Gesamtstrom zusammengesetzt werden kann. Für etwa gewünschte zusätzliche Kommunikation mit dem Empfänger wird, soweit nötig, der Steuerstrom benutzt, beispielsweise als Unicast-Strom.
Eine Empfängergruppe, welche keinen Multicast-Strom empfangen kann, kann ihren kompletten Audio-/Video-Strom über einen Unicast-Steuerstrom empfangen.
Eine solche Empfängergruppe kann beispielsweise hinter einem nicht Multicast-fähigen Router vorhanden sein. Die Empfängergruppe kann alternativ oder kumulativ über den vollständigen Unicast-Steuerstrom bereits die Wiedergabe starten, während die Wartezeit läuft, welche entsteht, während die Empfängergruppe auf den Empfang eines Multistream-Abonnements wartet.
Empfänger, welche Multicast empfangen können, können alle Daten oder nur einen Teil des Stroms über den Komponentenstrom empfangen. Fehlende bzw. weitere Daten werden über den Steuerstrom gesendet.
Je nach beabsichtigter Netztopographie ist es von Vorteil, wenn der Komponentenstrom als Multicast-Stream übertragen wird und/oder wenn der Steuerstrom als Multicast-Stream oder als Unicast-Stream übertragen wird.
In einer bevorzugten Ausgestaltung des Verfahrens wird beim Abonnieren des Streams zunächst ein größerer Anteil absoluter Daten und/oder relativer Daten über einen Steuerstrom übertragen, wobei die Übertragung schließlich den oder die Anteile im Steuerstrom absenkt, wobei sie bevorzugt nur noch absolute Daten im Steuerstrom überträgt.
Hierdurch wird ein schnelles Umschalten des Audio-/Video-Stroms ermöglicht. Dies sei nachfolgend anhand eines Anwendungsbeispiels beschrieben:
Wie bereits erläutert wurde, muss zum Dekomprimieren des Stroms ein gewisser Datenbestand beim Empfänger zwischengespeichert sein, um das Abspielen des Stroms zu initiieren. Die fehlenden Daten werden über den vorhandenen Steuerstrom gesendet. Dabei kann die Datenrate über die Zeit schwanken.
Zu jedem Zeitpunkt wird derjenige Datenbestand gesendet, welcher zum Darstellen des Gesamtstroms fehlt. Insbesondere werden fehlende Frames im Komponentenstrom durch den Steuerstrom gesendet. Der Steuerstrom kann eine variable Bitrate haben. Somit wird zu jedem Zeitpunkt gewährleistet, dass eine sofortige Darstellung des Audio-/Video-Signals möglich ist.
In einem konkreten Ausführungsbeispiel kann der Ursprungsstrom in vier Teilströme aufgeteilt sein. Ein P-Strom enthält alle P-Frames. Ein B-Strom enthält alle B-Frames. Der I1-Strom enthält p % jedes I-Frames. Die verbleibenden (100 minus p) % der I-Frames werden über den I2-Strom übertragen. Die I-Frames werden also jeweils zerlegt in einen Bestandteil, welcher über den I1-Strom läuft, und in einen zweiten Bestandteil, welcher über den I2-Strom läuft.
In diesem Beispiel sind der P-Strom, der B-Strom und der I1-Strom Komponentenstrom, der I2-Strom hingegen ist ein Steuerstrom und kann für jeden Empfänger individuell übertragen werden.
Schaltet der Benutzer am Client auf einen neuen Kanal um, soll also der zerlegte Strom abonniert werden, so wird der eingangs erwähnte Datenbestand für die Initiierung der Wiedergabe über den Steuerstrom zur Empfängergruppe übertragen. Das bedeutet, dass über den Steuerstrom unmittelbar nach der Umschaltanforderung 100 % der P-, B-, I1- und I2-Frames des Datenbestands auf einmal übertragen werden. Über den Steuerstrom werden also alle demultiplexten Teilströme gesendet, so dass sich der vollständige Datenstrom ergibt und die Wiedergabe unmittelbar beginnen kann.
Nach dieser Initialphase wird der Steuerstrom dynamisch auf p % der I-Frame-Daten reduziert, und die P- und B-Frames werden nicht mehr über den Steuerstrom übertragen. Der Komponentenstrom bleibt jedoch unberührt.
Somit reduziert sich die im Unicast-Verfahren zu übertragende Datenmenge, während die im Multicast-Verfahren zu übertragende Datenmenge unverändert bleibt.
In einer vorteilhaften Ausgestaltung des Verfahrens nach dem fünften Aspekt der vorliegenden Erfindung ist der Steuerstrom verschlüsselt oder wird zur Entschlüsselung des Komponentenstroms benötigt.
Eine solche bandbreitenschonende personalisierte Verschlüsselung des Datenstroms sei an einem zweiten Anwendungsbeispiel erläutert:
Das Anwendungsbeispiel basiert auf dem Prinzip, dass der Empfänger einen Großteil der Stream-Daten über den Komponentenstrom zusammensetzt. Die noch fehlenden Daten für einen kompletten Strom, welcher wiedergegeben werden kann, werden über den Steuerstrom übersendet. Der Steuerstrom ist dabei möglicherweise verschlüsselt. Somit kann eine Verschlüsselung über eine Kombination aus allgemein zugänglichem Komponentenstrom und über den personalisierten Steuerstrom gewährleistet werden.
Der Komponentenstrom wird hierbei per Multicast übertragen, der nur geringe Daten umfassende Steuerstrom im Idealfall per Unicast.
In denjenigen Fällen, bei denen mehrere Empfänger den gleichen Steuerstrom empfangen sollen, macht es Sinn, auch diesen per Multicast zu versenden. Somit können verschiedene Empfänger verschlüsselt versorgt werden, obwohl der Komponentenstrom nur einmal gesendet wird. Dadurch wird eine erheblich bessere Skalierung bei Verschlüsselung gewährleistet.
Konkret kann der Ursprungsstrom beispielsweise wieder in vier Teilströme geteilt sein. Der P-Strom und der B-Strom enthalten jeweils alle P- bzw. B-Frames. Der I1-Strom enthält p % jedes I-Frames. Die verbleibenden (100 minus p) % der I-Frames werden über den I2-Strom gesendet. Auch hier sind wieder P-, B- und I1-Strom Komponentenstrom, der I2-Strom hingegen ist Steuerstrom und kann für jeden Empfänger individuell verschlüsselt und übertragen werden.
Insbesondere können Komponentenströme so verschlüsselt werden, dass sie nur mit Hilfe von Schlüsseln aus dem Steuerstrom entschlüsselt werden können, wobei der Steuerstrom seinerseits verschlüsselt sein kann, etwa mit dem öffentlichen Schlüssel eines Teilnehmers.
Die Bandbreite, welche benötigt wird, um n Empfänger mit individueller Verschlüsselung zu versorgen, berechnet sich damit zu der n-fachen Bandbreite des Steuerstroms zuzüglich der einfachen Bandbreite des Komponentenstroms. Bei bisherigen Technologien wurde an Bandbreite das n-Fache des kompletten Stroms benötigt.
Die insgesamt benötigte Bandbreite steigt zwar nach wie vor mit der Anzahl der Empfänger des verschlüsselten Programms n an, jedoch nur als linearer Faktor in Bezug auf den schmalbandigen Steuerstrom, nicht – wie bisher – in Bezug auf den kompletten Strom. Somit liegt die benötigte Bandbreite nach dem hier vorgestellten Verfahren um ein Vielfaches unter derjenigen des klassischen Verfahrens.
Alternativ und kumulativ zum Nutzen des vorgestellten Verfahrens für Verschlüsselung von Streams wird vorgeschlagen, dass die Übertragung anhand einstellbarer Priorisierungen die zur Verfügung stehende Übertragungs- und/oder Rechenkapazität zu Gunsten eines höher priorisierten Teilstroms nutzt.
Dies sei in einem dritten Anwendungsbeispiel erläutert, bei welchem eine Priorisierung von Teilströmen verwendet wird, um eine robustere Wiedergabe zu ermöglichen. Dies basiert auf dem Grundgedanken, wichtigere Teilströme, beispielsweise I-Frames, mit höherer Priorität zu übertragen. Wenn P-, B- und I-Frames auf unterschiedlichen Multicast-Strömen übertragen werden, ist es von Vorteil, wichtigen Frame-Familien wie insbesondere den I-Frames bei der Übertragung höhere Prioritäten zuzuweisen.
Die vorstehenden Verfahren sind weitestgehend kombinierbar. So betreffen sie insbesondere die Beschleunigung des Umschaltens zwischen digitalen Datenströmen durch Pufferung, Aufteilung, Zusammensetzung, Retranskodierung oder Verzögerung, die Aufteilung eines Stroms in mehrere Komponentenströme und einen Steuerstrom, das Zusammensetzen mehrerer unvollständiger Ströme eines Komponentenstroms und eines Steuerstroms zu einem Gesamtstrom, die Bereitstellung personalisierter oder zugriffszeitabhängiger Datenbestände zur Einleitung von Datenströmen, die Bereitstellung zugriffszeitabhängiger Multicast-Ströme, die Pufferung von Stromdaten in Routern, Switches, DSLAMs und ähnlichen Netzwerkkomponenten sowie u.a. das Verwenden von Wegpunkten, um Ströme dezentral zu personalisieren, oder per Unicast weiter zu verbreiten.
Ein Verfahren zum schnellen Umschalten von Multicast-Streams sei nachstehend anhand eines weiteren Beispiels erläutert:
Bei diesem Verfahren wird jeder in die Infrastruktur einzuspeisende Datenstrom mehrfach eingespeist. Die mehrfache Einspeisung hat zum Ziel, dass für jeden Datenstrom mehrere Einstiegspunkte zur Verfügung stehen. Somit wird eine schnellere Initiierung des Abspielens des Datenstroms auf der Clientseite ermöglicht.
Die notwendige Modifikation der Infrastruktur beschränkt sicht dabei auf die Installation eines zentralen Strominitiierungssystems und einer Modifikation der Client-Router oder des Empfangsgeräts, im folgenden Wegpunkt genannt.
Üblicherweise wird der Router vom Internet Service Provider entwickelt, und der Internet Service Provider hat Zugriff auf die Firmware. Es ist also weder eine Modifikation an den DSLAMs noch an irgendeiner anderen Stelle in der Infrastruktur notwendig. Diese Umstände machen dieses System auch zum Nachrüsten in bestehende Systeme sinnvoll.
Zu beachten ist nur die im unkritischen Backbone-Bereich (in der Regel ein Glasfasernetz) des Internet Service Providers benötigte erhöhte Bandbreite. In der heutigen Zeit gehen Netzwerktechniker allerdings davon aus, dass die Kapazität im sogenannten „dark fibre" nahezu unbegrenzt ist.
Alle Ströme, welche in das System eingespeist werden und bei welchen schnelles Umschalten ermöglicht werden soll, werden über das zentrale Stromverarbeitungssystem gesendet. Dieses hat zwei Aufgaben:
Die erste Aufgabe besteht darin, den Strom zu bearbeiten, bevor er ausgesendet wird. Jeder Strom, welcher in das System eingespeist werden soll, wird zunächst zum Stromverarbeitungssystem gesendet. Das System sendet diesen Strom dann per Multicast in mehreren Ausführungen mit verschiedenen Einstiegspunkten, also zeitlich verschobenen I-Frames, über die Infrastruktur zu den Clients. Die Ströme sind entweder so retranskodiert, dass jeder Strom an unterschiedlichen Stellen I-Frames als Einstiegspunkte enthält, oder der Strom wird mit verschiedenen Verzögerungen gesendet. Das Stromverarbeitungssystem sendet Informationen über den Stromaufbau an den Wegpunkt, so dass dieser denjenigen Strom auswählen kann, bei welchem möglichst bald ein I-Frame auftaucht.
Beispielhaft soll der Strom jede Sekunde einen I-Frame enthalten. Jede Sekunde besteht aus 24 Frames. Der Strom wird nun in zwei Ströme retranskodiert. Bei dieser Ausführung des Verfahrens enthält der erste Strom den I-Frame am Anfang jeder Sekunde, der zweite Strom enthält idealerweise den I-Frame in der Mitte jeder Sekunde.
Somit ist im unkritischen Backbone-Bereich im worst case von einer Verdoppelung der Datenbandbreite auszugehen. Der Umschaltvorgang für den Endkunden wird im statistischen Mittel doppelt so schnell. Das Umschalten würde nun infrastrukturbedingt in durchschnittlich 0,5 Sekunden erfolgen können.
Weiterhin kann der Strom auch in mehr als zwei Ströme retranskodiert werden. Wird der Strom beispielsweise in vier Ströme retranskodiert, so ist ein Umschalten in maximal 0,25 Sekunden möglich. Dies kann beliebig weiter verfeinert werden, bis hin zu einer Aufteilung von maximal 24 Strömen für praktisch unmittelbares Umschalten.
Ist ein Zeitversatz nicht entscheidend, so dass manche Empfänger ein geringfügig späteres Signal erhalten dürfen, so kann der Strom statt einer Retranskodierung unterworfen zu werden auch einfach verzögert werden. Dabei wird, um beispielsweise zwei Ströme zu erzeugen, der gleiche Strom ausgesendet, wobei der zweit Strom um 0,5 Sekunden zurückgehalten wird. Bei dem Erzeugen von mehr als zwei Strömen wird analog verfahren.
Die zweite Aufgabe des Stromverarbeitungssystems liegt darin, mit dem Wegpunkt eine eventuelle Verzögerung der Datenübertragung zu berechnen.
Zunächst nimmt der Wegpunkt einen initialen Übertragungstest zur Berechnung der Verzögerung d des Datenstroms vom zentralen Stromverarbeitungssystem zum Wegpunkt vor. Gemessen wird ein beliebiger Messstrom, dessen Verzögerung äquivalent zur Verzögerung der Übertragung der I-Frames eines Datenstroms ist. Die Verzögerung d ist unabhängig vom Inhalt des Datenstroms, da lediglich die Verbreitungsgeschwindigkeit im Netz gemessen wird.
Mit Hilfe der Informationen über den Aufbau und dem Zeitpunkt des Vorkommens der I-Frames des zentralen Stormverarbeitungssystems und dem Parameter d kann der Wegpunkt für alle Datenströme die Ankunftszeiten der I-Frames mit ausreichender Genauigkeit berechnen. Um robuste Schwankungen in der Verbreitungsgeschwindigkeit und damit im Parame ter d auffangen und ausgleichen zu können, wird von einem anliegenden Datenstrom die Verzögerung d ständig gemessen.
Der Wegpunkt ist im einfachsten Fall ein Router, welcher beim Endkunden installiert ist. Die zentrale Aufgabe des Wegpunktes ist es, zu dem vom Endgerät gewünschten Kanal denjenigen Datenstrom zu ermitteln, welcher den zeitlich nächsten Einstiegspunkt enthält. Dieser Datenstrom wird dann unmittelbar zum Endgerät weitergeleitet.
Um den richtigen Datenstrom zu ermitteln, berechnet der Wegpunkt beim Initialisieren des Wegpunkts sowie in periodischen Abständen die Verzögerung d. Dazu muss der Wegpunkt ebenso wie das zentrale Stromverarbeitungssystem über eine genaue Uhrzeit verfügen.
Das vorbeschriebene System lässt sich vollkommen in ein DVB-IPI-kompatibles System integrieren. Dies wird deutlich, wenn der genaue Ablauf analysiert wird:
Der Wegpunkt fungiert als eine Art Manager für IGMP-Anfragen des Endgeräts. Das Endgerät erhält eine Kanalliste über DVB-IPI Service Discovery and Selection (SD&S)S. Diese Kanalliste enthält Informationen darüber, welche Multicast-Gruppe zu welchem Sender gehört. Sobald das Endgerät einen Kanal per IGMP anfordert, wird die Anfrage an den Wegpunkt gesendet.
Der Wegpunkt ermittelt durch Addition der aktuellen Zeit zur Verzögerung d, welcher Strom und damit welche Multicast-Gruppe für ein möglichst schnelles Umschalten benötigt wird. Die Multicast-Gruppe wird abonniert und an das Endgerät weitergesendet.
Somit ist der Wegpunkt für das Endgerät transparent im Sinne des DVB-IPI-Standards Phase I. Dem Endgerät wird vom System praktisch eine normale Multicast-Umgebung vorgetäuscht.
Es sei ausdrücklich darauf hingewiesen, dass DVB-IPI nur als Beispiel dient und dass die vorstehend beschriebenen Verfahrensausgestaltungen ebenso auf jeden anderen Client-Standard übertragen werden können.
Ein weiteres Ausführungsbeispiel, dieses Mal zum ersten vorgestellten Aspekt der Erfindung, wird nachfolgend unter Bezugnahme auf die Zeichnung näher erläutert. Es zeigen
1 schematisch die Funktionsweise eines Multicast-Routers mit einem FIFO-Bereitschaftspuffer und
2 schematisch den Ablauf einer Abonnement-Anforderung mit einer schnellen Übertragung eines Stream-Anfangs.
Der Multicast-Router 1 im Netzwerk 2 puffert jeden Stream 3 in seinem FIFO-Puffer 4. Der Puffer 4 hat die Größe G.
Der Stream 3 wird in durchgehenden Strömen 5, 6, 7 verzögerungsfrei weitergereicht, aber gleichzeitig in einer Kopie 8 in den Puffer 4 geschrieben.
Wenn neben den drei bereits bestehenden Abonnenten 9, 10, 11 ein weiterer Router oder Client (nicht dargestellt) den Stream 3 anfordert, so sendet der Multicast-Router 1 zunächst den Inhalt des Puffers 4 mit voller Datenrate, dann erst den laufenden Stream 3. Dadurch wird die gleiche Beschleunigung wie im Unicast-Verfahren erreicht, aber wesentlich weniger Bandbreite verbraucht.
Zudem ist es für die empfangenden Geräte, meist Router oder Clients, nicht nötig, zwischen verschiedenen Streams umzuschalten, etwa Lead-In-Stream oder Main-Stream. Daher ist die Methode für Empfänger vollständig transparent und kann ohne eine Änderung der Clients implementiert werden.
Die Implementierung kann etwa durch eine Anpassung des Verhaltens der Multicast-Router im Netzwerk erfolgen. Die Multicast-Router müssen dann über einen Speicher der Größe M verfügen, welcher mindestens der n-fachen Größe des für einen Kanal erforderlichen Speichervolumens G entspricht, wobei n die Anzahl der möglichen verschiedenen Streams ist, die gleichzeitig durch den Router gehen können sollen.
Die Puffer werden im First-In-First-Out-Verfahren gefüllt und geleert. Dies bedeutet, dass die Datenelemente in der gleichen Ordnung dem Puffer entnommen werden, wie sie eingefüllt wurden. Wenn der Puffer vollgeschrieben ist, so werden die jeweils ältesten Datenelemente entnommen und gelöscht.
So fordert beispielsweise ein Empfangsgerät 100 (vergleiche 2) einen neuen Stream 150 bei einem Multicast-Router 200 an, welcher ihm am nächsten in der Netztopographie ist. Dieser Router empfängt den Stream 150 selbst noch nicht. Deshalb fragt er bei dem nächsten Router 300 an. Der Router 300 leitet den Stream 150 bereits an andere Geräte 400, 500 weiter und hat einen gerade vergangenen Stream-Abschnitt 151 in seinem Puffer 310 gespeichert.
Auf die Anfrage hin sendet der Router 300 zunächst eine Kopie 152 des Inhalts 151 des Puffers 310 an den Router 200, löscht aber dabei den Puffer 310 nicht (vergleiche die Darstellung bei fortgeschrittener Zeit 900 auf der rechten Seite der 2).
Anschließend schickt er den Stream 150 an den Router 200 ebenso weiter wie an die Geräte 400, 500.
Der Router 200 empfängt die Kopie 152 und anschließend den Stream 150 und sendet beides sofort an den Empfänger 100 weiter, speichert es aber auch in dieser Reihenfolge als Kopie 153 in seinem FIFO-Puffer 210.
Der Empfänger 100 empfängt zunächst die Pufferkopie 152, speichert diese als Kopie 154 in seinen Puffer 110 und kann dann sofort mit der Wiedergabe des gespeicherten Inhalts auf dem Wiedergabegerät 600 beginnen. Der Puffer wird dabei mit dem Stream 150 wieder aufgefüllt.
Es versteht sich im übrigen, dass nicht nur die vorgestellten Verfahren für sich genommen erfinderisch sind, sondern auch ein System, welches die vorgestellten Verfahren einzeln oder in Kombination anwendet, sowie entsprechende Geräte.

Claims

Verfahren zum Übertragen eines Multicast-Streams (150) in einem IP-Netzwerk von einem höheren Gerät (300) zu einem niedrigeren Gerät (200), dadurch gekennzeichnet, dass das höhere Gerät (300) den Stream (150) in einen FIFO-Bereitschaftspuffer (151) schreibt.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das höhere Gerät den Stream parallel zur Übertragung (400, 500) in den FIFO-Bereitschaftspuffer schreibt.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das niedrigere Gerät (200) beim Abonnieren des Streams (150) zunächst Inhalt (151) des FIFO-Bereitschaftspuffers (310) als Stream-Anfang und anschließend den Stream (150) übertragen erhält.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Stream-Anfang mit einem höheren Datendurchsatz zum niedrigeren Gerät übertragen wird als anschließend der Stream.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das höhere und/oder niedrigere Gerät ein Multicast-Router ist und eine Mehrzahl von Streams in einen FIFO-Bereitschaftspuffer schreibt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass dem niedrigeren Gerät ein Client (100) nachgeordnet ist.
Verfahren zum Übertragen eines Streams in einem IP-Netzwerk von einem höheren Gerät zu einem niedrigeren Gerät, wobei der Stream Absolutdaten und Relativdaten zur Wiedergabe aufweist, dadurch gekennzeichnet, dass das höhere Gerät einen retranskodierten Stream überträgt.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass das höhere Gerät einen retranskodierten Stream-Anfang in einen Zwischenspeicher schreibt und dem niedrigeren Gerät beim Abonnieren des Streams zunächst den zwischengespeicherten Stream-Anfang überträgt.
Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass dem niedrigeren Gerät der zwischengespeicherte Stream-Anfang als Unicast-Stream zugesendet wird.
Verfahren nach einem der Ansprüche 7 bis 9, dadurch gekennzeichnet, dass das höhere Gerät den Stream-Anfang aus Daten von einem Zwischenpunkt zwischen zwei Absolutdaten bis zu einem nächstfolgenden Absolutdatum retranskodiert.
Verfahren nach einem der Ansprüche 7 bis 10, dadurch gekennzeichnet, dass die Absolutdaten I-Frames sind und dass die Relativdaten B- und P-Frames sind.
Verfahren nach einem der Ansprüche 7 bis 11, dadurch gekennzeichnet, dass das höhere Gerät zwischen zwei Absolutdaten eine Mehrzahl von retranskodierten Stream-Anfängen errechnet und zwischenspeichert, insbesondere mehrere pro Sekunde.
Verfahren nach einem der Ansprüche 7 bis 12, dadurch gekennzeichnet, dass das höhere Gerät ein zentraler Stream-Server ist.
Verfahren nach einem der Ansprüche 7 bis 13, dadurch gekennzeichnet, dass das niedrigere Gerät retranskodierte Stream-Anfänge in einen Zwischenspeicher schreibt.
Verfahren nach einem der Ansprüche 7 bis 14, dadurch gekennzeichnet, dass das höhere Gerät ein Wegpunkt zwischen einem zentralen Stream-Server und einem Client ist, insbesondere ein DSLAM oder ein Router hinter einem Hausanschluss.
Verfahren nach einem der Ansprüche 7 bis 15, dadurch gekennzeichnet, dass der Multicast-Stream mittels eines Puffers geringfügig verzögert übertragen wird, so dass bei einem Umschalten der Übertragung vom retranskodierten Stream-Anfang zum Multicast-Stream eine Zeitlücke im Wesentlichen von der Dauer des Retranskodierens vermieden wird.
Verfahren zum Übertragen eines Multicast-Streams in einem IP-Netzwerk von einem höheren Gerät zu einem niedrigeren Gerät, wobei der Stream Absolutdaten und Relativdaten zur Wiedergabe aufweist, insbesondere nach einem der Ansprüche 7 bis 15, dadurch gekennzeichnet, dass das niedrigere Gerät auf Abonnieranforderung eines nachgeordneten Geräts zunächst einen Stream-Anfang mit einer Dauer anfordert, welche abhängig von einer zu erwartenden Ankunftszeitspanne der nächsten Absolutdaten beim niedrigeren Gerät errechnet wird.
Verfahren zum Übertragen eines Multicast-Streams in einem IP-Netzwerk von einem höheren Gerät zu einem niedrigeren Gerät, dadurch gekennzeichnet, dass das höhere Gerät zusätzlich zum ursprünglichen Multicast-Stream einen retranskodierten und/oder zeitlich verzögerten Offset-Stream zum Abonnieren bereithält.
Verfahren zum Übertragen eines Streams in einem IP-Netzwerk von einem höheren Gerät zu einem niedrigeren Gerät, dadurch gekennzeichnet, dass der Stream zunächst demultiplext oder demultiplext als Datenursprung verwendet wird, so dass sich mehrere Teilströme ergeben, woraufhin diese Teilströme übertragen und vom niedrigeren Gerät zusammengesetzt werden.
Verfahren nach Anspruch 19, dadurch gekennzeichnet, dass der Stream vom niedrigeren Gerät per Unicast an einen Client übertragen wird.
Verfahren nach einem der Ansprüche 18 bis 20, dadurch gekennzeichnet, dass die Teilströme einen Komponentenstrom und einen Steuerstrom aufweisen.
Verfahren nach Anspruch 21, dadurch gekennzeichnet, dass der Komponentenstrom als Multicast-Stream übertragen wird.
Verfahren nach Anspruch 21 oder 22, dadurch gekennzeichnet, dass der Steuerstrom als Multicast-Stream übertragen wird.
Verfahren nach Anspruch 21 oder 22, dadurch gekennzeichnet, dass der Steuerstrom als Unicast-Stream übertragen wird.
Verfahren nach einem der Ansprüche 19 bis 24, dadurch gekennzeichnet, dass beim Abonnieren des Streams zunächst ein größerer Anteil absoluter Daten und/oder relativer Daten über einen Steuerstrom übertragen wird, wobei die Übertragung schließlich den oder die Anteile im Steuerstrom absenkt, bevorzugt nur noch absolute Daten im Steuerstrom überträgt.
Verfahren nach einem der Ansprüche 19 bis 25, dadurch gekennzeichnet, dass der Steuerstrom verschlüsselt ist oder zur Entschlüsselung des Komponentenstroms benötigt wird.
Verfahren nach einem der Ansprüche 19 bis 26, dadurch gekennzeichnet, dass die Übertragung anhand einstellbarer Priorisierungen die zur Verfügung stehende Übertragung- und/oder Rechenkapazität zu Gunsten eines höher priorisierten Teilstroms nutzt.
Übertragungssystem zum Übertragen eines Streams in einem IP-Netzwerk von einem höheren zu einem oder mehreren niedrigeren Geräten unter Anwendung eines Verfahrens nach einem der vorhergehenden Ansprüche.
Router oder DSLAM zum Einsatz in einem System nach Anspruch 28.
Verfahren zum Umrüsten eines Systems zum Übertragen eines Streams in einem IP-Netzwerk, dadurch gekennzeichnet, dass ein Verfahren nach einem der Ansprüche 1 bis 27 implementiert wird und/oder dass ein Router oder ein DSLAM nach Anspruch 29 implementiert wird.