Effizientes Echtzeit Media-on-Demand Verfahren in IP- Netzwerken

Transkript

1 Effizientes Echtzeit Media-on-Demand Verfahren in IP- Netzwerken Dipl.-Ing. Harald Gebhard, Lehrstuhl für Kommunikationstechnik, Universität Dortmund Kurzfassung Im Zuge neuer Entwicklungen der Internet-Zugangstechnologien wird sich der bisherige Flaschenhals der Übertragung vom Netzwerkzugang hin zu den Kernnetzen (Backbones) und den Datenservern verschieben. Die Nutzer werden mit ihrem schnellen Internet-Zugang vermehrt auf breitbandige Dienste Multimedia Streaming Applikationen zugreifen, und die involvierten Server massiv belasten. Ein Media-on-Demand (MoD) System bestehend aus Server, Netzwerk und Empfängern steht allgemein vor dem Problem, die am Server vorhandenen Ressourcen (I/O-Kapazität und Netzwerkbandbreite) möglichst effizient auf alle Empfängeranfragen aufzuteilen. Die derzeit im Internet meist verwendeten Unicast Systeme müssen wegen ihrer mangelnden Skalierbarkeit auf eine maximale Anfragerate dimensioniert werden, wenn für den Empfänger unliebsame Dienstausfälle vermieden werden sollen. Das in diesem Beitrag vorgestellte Interactive Segment Patching (ISP) verwendet IP-Multicast Gruppenkommunikation, um die mangelnde Skalierbarkeit von Unicast MoD Systemen zu verbessern. Dabei wird den Empfängern neben der Wahl des Startpunktes des Media-Objektes auch volle interaktive Funktionalität (Pause, schneller Vor/ Rücklauf) ermöglicht. Das ISP System ist gegenüber anderen, in der Literatur beschriebenen Systemen leicht implementierbar. Simulationen zeigen, dass ISP im Vergleich zu konventionellen Unicast MoD Systemen bei hohen Anfrageraten eine Reduzierung der Ressourcenbelastung der Media-Server um bis zu 94% bewirken kann. 1 Einleitung Schmalbandige multimediale Echtzeitübertragungen (Streaming) gewinnen im Internet mehr und mehr an Bedeutung. Es gibt kaum eine Rundfunkstation, die ihre Inhalte nicht parallel zu den klassischen Übertragungswegen auch Live oder On-Demand über das Internet anbietet. Der Trend zu neuen Netz-Zugangstechnologien wie xdsl (Digital Subscriber Line) oder Kabelmodems für HFC-Netze (Hybrid Fiber Coax) ermöglicht in naher Zukunft einer Vielzahl von Benutzern einen breitbandigen Internetzugang. Die neuen Breitbandnutzer werden mit ihrem schnellen Zugang auch breitbandige Dienste Multimedia Streaming Applikationen nutzen, was bei weiterer Verwendung der bisher üblichen Unicast Kommunikation (Punkt-zu-Punkt) vermehrt zu Belastungen der Backbone-Netzwerke und der Multimedia Server führen wird. Bei Live Übertragungen können IP-Multicast- Technologien (Punkt-zu-Multipunkt) eine kostengünstige Möglichkeit sein, diesem neuen Engpass zu begegnen. Ermöglicht man dem Nutzer, neben dem "Was" auch das "Wann" der Übertragung zu wählen (Media on Demand), und darüber hinaus die interaktive Funktionalitäten eines Videorekorders (VCR) wie Pause, schneller Vor- und Rücklauf zu nutzen, so scheint man um einen dedizierten Datenstrom pro Nutzer (Unicast) nicht umhin zu kommen. Das in diesem Beitrag vorgestellte Interactive Segment Patching basiert auf einer modifizierten Form der erstmals von Hua vorgestellten Idee des Patchings [1]. Dabei wird ein Echtzeit Media-Objekt in Segmente fester Länge aufgeteilt, und über teilbare (Multicast) oder nicht teilbare (Unicast) logische Kanäle ü- bertragen. Das Verfahren basiert darauf, dass bei später kommenden Anfragen für dasselbe Objekt kein dedizierter Unicast-Datenstrom aufgebaut wird. Vielmehr teilt sich der spätere Empfänger die gerade gesendeten Segmente der vorherigen Anfrage, und speichert diese lokal zwischen. Parallel werden die "verpassten" Segmente neu angefordert. Diese können wiederum von späteren Anfragen genutzt werden. Wichtig ist, dass der Empfänger keine große Wartezeit vor dem Beginn des Abspielens eines Objektes erfährt. Da der Empfänger durch die Pufferung die Möglichkeit der lokalen Zwischenspeicherung haben muss (Festplatte), sind in dem vorgestellten Verfahren Stop, Pause und schneller Rücklauf möglich. Darüber hinaus wird ein schneller Vorlauf mit Hilfe eines kurzzeitig dedizierten Unicast-Datenstromes ermöglicht. Der Beitrag gliedert sich wie folgt: Zunächst wird auf die Grundlagen von Echtzeit Media-on-Demand Systeme eingegangen, und aus der Literatur bekannte Lö-

2 sungsansätze werden diskutiert. Danach folgt die Beschreibung des in diesem Vortrag vorgestellten Interactive Segment Patching Systems mit allen Elementen, Algorithmen und Protokollen. Der Beitrag endet mit der Vorstellung von Simulationsergebnissen und einer kurzen Zusammenfassung. 2 Echtzeit Media-on-Demand Auf Echtzeitübertragung basierende Internet- Anwendungen übertragen im Unterschied zum konventionellen Burst oder Bulk Datenverkehr (z.b. Terminal Emulation oder ) des klassischen Internets ihre Daten in einem festen zeitlichen Raster. Der daraus folgende Strom von Internetpaketen beansprucht abhängig vom übertragenen Medium, den verwendeten Quellencodierverfahren und der geforderten Qualität für das Netzwerk unterschiedliche mittlere Datenraten pro Datenstrom. Diese können beispielsweise von 16 Kbit/s für Audio über Mbit/s Video bis hin zu 100 Mbit/s pro Datenstrom für Virtual Reality reichen. Herkömmliche Rundfunkübertragungen werden im Internet unabhängig von der verwendeten Kommunikationsform (Unicast oder Multicast) als Live- Streaming bezeichnet. Dabei hat ein Nutzer die Möglichkeit, einen laufenden Datenstrom anzufordern und den Inhalt zu konsumieren. Ermöglicht man dem Nutzer darüber hinaus, den Beginn der Übertragung des Objektes zu wählen, so wird dies als Media-on- Demand bezeichnet [2]. Allen MoD Systemen ist gemein, dass die hardwarebedingten Ressourcen des Media-Servers (I/O- Kapazität und Netzwerkbandbreite) eine maximale Anzahl parallel ausspielbarer Datenströme bedingen, und diese Datenströme nach unterschiedlichen Algorithmen aufgeteilt werden müssen. Dabei wird eine Unicast, Multicast und Broadcast-Kommunikation in IP-Netzwerken auf eine IP-Unicast bzw. IP-Multicast Übertragung abgebildet, wobei Broadcast eine IP- Multicast Übertragung an alle dem MoD System angeschlossenen Empfänger ist. Existierende Systeme, welche die verfügbaren Ressourcen direkt auf die Nutzer aufteilen, werden dabei in der Literatur allgemein als nutzerbasiert (User- Centered) bezeichnet [3]. Darunter fallen im Internet alle Verfahren, die einen dedizierten Datenstrom pro Nutzer (Unicast) bereitstellen. Hingegen werden bei den datenbasierten Verfahren (Data-Centered) die verfügbaren Ressourcen auf ein Media-Objekt verteilt. Dabei werden bei den serverseitig initiierten Karussellverfahren (Server-Push) die verfügbaren Ressourcen in K logische Kanäle aufgeteilt, und im einfachsten Fall zeitversetzt übertragen [4]. Alle komplexeren Karussellverfahren, die bei gleicher Datenrate am Ser- Server, gegenüber dem zeitversetzten Abspielen die Wartezeit (Zugriffszeit) zum Beginn eines Media- Objektes deutlich reduzieren, setzen einen empfängerseitigen Datenspeicher voraus (Prefetching). Sie leiten sich zum einen von Viswanathans und Imielinskis Pyramid Broadcasting Protocol [5] ab. Dabei wird ein Media-Objekt in Segmente zunehmender Länge aufgeteilt [6, 7, 8], welche über die unterschiedlichen K Kanäle übertragen werden. Zum anderen werden in dem von Juhn und Tseng entwickelten Harmonic Broadcast Protocol [9] Media- Objekte in Segmente gleicher Dauer, aber unterschiedlicher Datenrate ( Abspielrate) über die verfügbaren K Kanäle übertragen. In beiden Verfahren muss bei den Empfängern parallel auf alle K Kanäle zugegriffen, und später zu verwendende Daten lokal zwischengespeichert werden. Der verwendete Algorithmus sorgt dafür, dass bei den Empfängern zu jedem Zeitpunkt genügend aktuelle Daten im lokalen Speicher vorliegen. Ein Vergleich Bandbreite vs. Zugriffszeit der unterschiedlichen Verfahren kann Pâris [10] entnommen werden. Neben den unidirektionalen Server-Push Systemen können datenbasierte Verfahren auch von den Empfängern initiiert sein (Client-Pull). Dabei werden im Unterschied zu den Push Systemen nur dann Datenströme übertragen, wenn diese von einem Empfänger auch konsumiert werden. In Batching MoD Systemen werden Anfragen von Empfängern für ein bestimmtes Media-Objekt zu einer Gruppe zusammengefasst, und per Multicast übertragen. Dabei werden unterschiedliche Strategien in [11, 12, 13, 14] beschreiben. Das von Hua vorgeschlagene Patching [1, 15] und dessen weiterentwickelte Varianten [3, 16, 17, 18] beruht ebenfalls darauf, dass für jede Anfrage sofort ein dedizierter Datenstrom bereitgestellt wird. Zusätzlich muss der Empfänger die Möglichkeit haben, einen zweiten Datenstrom parallel zu empfangen, und diesen lokal zwischenzuspeichern. Wird bei einer Empfängeranfrage für ein Media-Objekt am Server festgestellt, dass eine Übertragung bereits läuft, so wird dem Empfänger der Beginn des Objektes bit- bzw. bildgenau dediziert übertragen, während er aber zeitgleich den Datenstrom der laufenden Multicastübertragung empfangen und zwischenspeichern kann. Verbesserte Serveralgorithmen definieren abhängig von Empfängerspeicher und der aktuellen Zugriffsrate eine Schwelle, nach der eine neue Multicastübertragung begonnen wird [19]. Die datenbasierten und serverinitiierten MoD Verfahren (Karusselle) eignen sich wegen der hohen Empfängerbandbreiten (auf alle K Kanäle muss parallel zugegriffen werden) vor allem für den Einsatz über eine Satellitenverbindung. Der nutzerbasierte Ansatz (Unicast) stellt zwar nur relativ wenige Anforderungen an die Implementierung

3 und die Empfänger, aber die serverseitige Ressourcenbelastung steigt linear mit den Anfragen an. Ein solches System muss deshalb, um Dienstausfälle für Empfänger zu vermeiden, auf maximal mögliche Anfragen ausgelegt sein, auch wenn dieser Fall im Mittel nur sehr selten eintritt (z.b. Samstag; Prime Time). Bei den vom Empfänger initiierten und datenbasierten Verfahren bietet Patching einen guten Kompromiss zwischen senderseitiger Skalierbarkeit und den Anforderungen an die Empfänger. Die Ressourcenbelastung bei den Servern liegt zwar bei sehr hohen Anfrageraten deutlich über denen der Karussellverfahren, aber je nach Algorithmus deutlich unter denen des nutzerbasierten Ansatzes (Unicast). gegenseitig nicht beeinflussen, wird nur die Übertragung eines Objektes betrachtet. Bei Systemen mit mehreren Objekten wird für eine Gesamtbetrachtung die mittlere Ressourcenbelastung addiert. 3.1 Definitionen Wir verwenden für alle Systembetrachtungen ein diskretes Zeitmodel mit einer Auflösung von einer Sekunde. Alle Anfragen innerhalb einer Sekunde werden somit von dem System zu einer Anfrage zusammengefasst. Folgende grundlegenden Parameter werden für ISP benötigt: 3 Interactive Segment Patching t t i t Si N S S k C j K R λ aktuelle Zeit [s] Startzeit für den Empfänger i [s], mit i=1,2,3,.. Wiederaufnahmezeitpunkt einer Übertragung nach Vorspulen für den Empfänger i [s] Länge eines Media-Objektes [s] Länge der Segmente [s] k-tes Segment, mit k=1,2,3,.. j-ter logischer Kanal, mit j=1,2,3,.. Maximale Anzahl von Segmenten eines Media-Objektes Maximale Anzahl von parallel empfangbaren Datenströmen beim Empfänger [s] Anfragerate für ein Media-Objekt [Anfragen/s] Dabei wird ein Media-Objekt der Länge N in K-1 Segmente der Länge S und N = S ( K 1) + S ' S = Int N K S' = S + N mod K dem letzten Segment S' mit Rest zerlegt. Bild 1 Interactive Segment Patching Beim Interactive Segment Patching (ISP) wird ein Media-Objekt in Segmente fester Länge aufgeteilt, und über teilbare (Multicast) und nicht teilbare (Unicast) logische Kanäle übertragen. Die Segmente werden dann bei den Empfängern wieder zu einem fortlaufenden Medienstrom zusammengesetzt. Dazu müssen die Empfänger lokal über ausreichend Puffer (Festplatte), und über eine ausreichende Netzwerkanbindung um mindestens zwei oder mehr Datenströme parallel empfangen zu können verfügen. Fordert, wie in Bild 1 dargestellt, Empfänger 2 zeitlich nach Empfänger 1 dasselbe Media-Objekt an, so greift Empfänger 2 einerseits ab Segment 3 auf die noch vollständig zu übertragenden Segmente zu, andererseits werden direkt nach der Anforderung die fehlenden Segmente 1 und 2 über einen weiteren teilbaren Kanal in Echtzeit übertragen. Durch den im Empfänger vorausgesetzten Speicher sind in dem vorgestellten Verfahren Pause und schneller Rücklauf möglich. Für nicht bereits lokal verfügbare Daten wird vor allem im Falle des schnellen Vorlauf ein kurzzeitig dedizierten Unicast-Datenstromes übertragen. Da sich unterschiedliche Media-Objekte an einem Server 3.2 Algorithmus Mit den Definitionen aus Absatz 3.1 können wir nun den ISP Algorithmus formulieren: Wenn noch keine Instanz des angeforderten Media-Objektes übertragen wird, werden beginnend mit t 1 alle Segmente S 1 bis S K eines Objektes seriell ausgespielt. Wenn ein späterer Empfänger i zum Zeitpunkt t t i > 1 auf dasselbe Objekt zugreift, werden die Segmente S 1 bis S J mit

4 ti J = Int +1 S auf einem weiteren teilbaren Kanal neu übertragen. Die Segmente S J+1 bis S K werden von der laufenden Übertragung empfangen. Kann ein Empfänger parallel auf mehr als 2 logische Kanäle zugreifen, so können ihm abhängig vom Zeitpunkt der Anfrage und den laufenden Übertragungen neben den Anfangssegmenten S 1 bis S J weitere, nicht vollständig von einer laufenden Übertragung empfangbare Segmente fehlen, die dann zeitlich richtig zusätzlich übertragen werden müssen. Wenn ein Empfänger i durch interaktives Vorspulen an den Zeitpunkt t Si springt, so wird das Segment S L+1 mit tsi L = Int S beginnen mit dem Zeitversatz t = tsi ( L S ) über einen nicht teilbaren logischen Kanal übertragen, und S L+2 bis S K werden, falls vorhanden, von einer laufenden Übertragung empfangen oder zeitlich richtig auf einem weiteren teilbaren Kanal in Echtzeit übertragen. Durch das Vorspulen überflüssig gewordene Übertragungen werden, falls nicht von weiteren Empfängern geteilt, vom System abgebrochen. 4 Implementierung Das ISP System entspricht in wesentlichen Teilen den Systemkomponenten eines Virtuellen Internet- Rundfunk-Systems [20, 21, 22], und erfordert in IP- Netzwerken im Vergleich zu konventionellen Unicast Media-on-Demand Systemen neben etwas mehr Aufwand in der Softwareimplementierung (Server, Empfänger, Protokolle) beim Empfänger eine ausreichende Netzwerkanbindung und ausreichend lokalen Speicher (maximal mögliche Größe eines empfangbaren Media- Objektes). Darüber hinaus muss das System in einem IP-Multicast fähigen IP-Netzwerk betrieben werden. Durch die effektivere Nutzung der Serverressourcen steht dem Mehraufwand eine deutliche Reduzierung der Ressourcenbelastung beim Server (Hardwarekosten), und eine deutlich verbesserte Skalierbarkeit des Gesamtsystems gegenüber. Das vorgeschlagene System basiert auf den im Internet etablierten Protokollen Real Time Transport Protocol (RTP) [23] für die Datenübertragung und dem Real Time Streaming Protocol (RTSP) [24] in Verbindung mit dem erweiterten Session Description Protocol (SDP) [25] zur Sitzungssteuerung. Es wird keine zusätzliche Hardware (Splitter und Cache-Server) im Netzwerk benötigt. 4.2 ISP-Server Der ISP-Server besteht neben einer Kommunikationsschnittstelle (RTSP) zu den Empfängern, und einem Scheduler zur Umsetzung des in Abschnitt 3.2 beschriebenen Algorithmus aus einer Streaming Unit. Dabei können die Kommunikationsschnittstellen, der Scheduler und die Streaming Unit auf einem oder auf unterschiedlichen Rechnersystemen installiert sein. Ähnlich konventionellen MoD Systemen liegen die Segmente der Media-Objekte bereits quellencodiert (z.b. MPEG-1,2,4) auf der Festplatte des Servers vor. Der Scheduler steuert die Streaming Unit, und hat somit einen genauen Überblick, welches Segment S k auf welchem logischen Kanal C j zu welcher Zeit t gestartet wird. Liegt der Kommunikationsschnittstelle zum Zeitpunkt t i die Anfrage von Empfänger i vor, so errechnet der Scheduler für jede Anfrage eine Sendebeschreibung, nach der die Segmente S k über die logischen Kanäle C j durch die Streaming Unit übertragen werden. Darüber hinaus wird für jeden Empfänger i ein eindeutiger RTSP Session Identifier erstellt. Im Unterschied zu konventionellen RTSP Unicast/Multicast Sitzungen [24] wird der RTSP Transport Header dynamisch, und gemäß [25] als SDP Beschreibung zum Zeitpunkt t i der Aktion Play des Empfängers erzeugt. E->M: SETUP rtsp://video.com/v1 RTSP/1.0 Bandwidth: M->E: RTSP/1.0 OK E->M: PLAY rtsp://video.com/v1 RTSP/1.0 M->E: RTSP/1.0 OK Transport: a=cstream m=video RTP/AVP 31 c=in IP /15 a=mcit: m=video RTP/AVP 31 a=mcit: m=video RTP/AVP 31 a=mcit:

5 Empfänger E fordert im obigen vereinfachten Beispiel einer RTSP Kommunikation ein Video beim Media- Server M an. Der Empfänger übermittelt die aktuelle Netzwerkanbindung (hier 3 Mbit/s) an den Server, womit dieser eine der verfügbaren Empfängerbandbreite angepasste Sitzungsbeschreibung errechnen kann (hier R=2). Der Media-Server M gibt auf die Anfrage die Session ID für Empfänger E zurück. Mit dieser ID kann der Empfänger zur Zeit t i beim Media-Server das Ereignis Play auslösen. Der Server errechnet nun die zum Zeitpunkt t i + t M gehörende Sitzungsbeschreibung, und überträgt diese an den Empfänger. Mit der Berücksichtigung von t M wird verhindert, dass der Empfänger, bedingt durch das Multicast-Routing 1, Pakete verliert. Zusätzlich kann der Scheduler während der Laufzeit hohe Ressourcenbelastungen erkennen, und nacheinander eintreffende Anfragen zu einer Gruppe zusammenfassen. Damit kann einerseits dynamisch in die Ressourcenbelastungen des Media-Servers eingegriffen werden, andererseits verlängert sich aber die Wartezeit der Empfänger je nach verwendetem Zeitfenster. 4.3 Empfänger Die benötigte Empfängersoftware entspricht weitgehend der des Virtuellen Rundfunks. Der Empfänger ist in der Lage, anhand der über die RTSP- Kommunikation erhaltene SDP Informationen, die zur Übertragung der eigentlichen Media-Daten entsprechenden Unicast/Multicast Netzwerkverbindungen herzustellen. Nach dem Aufbau der Netzwerkverbindungen werden die RTP/RTCP-Datenströme von den verschiedenen logischen Kanälen empfangen, und daraus ein zusammenhängender Gesamtdatenstrom erzeugt, der über einen Decoder ausgespielt wird. Eine ausführlichere Beschreibung kann aus [20, 21, 22] entnommen werden. 4.4 Interaktive Funktionen Das System ermöglicht die Funktionen: Pause Zurückspulen Vorspulen Dabei wirkt sich dank des ausreichend großen lokalen Speichers Pause und ein einmaliges Zurückspulen nicht auf den Media-Server aus. Hingegen bewirkt der in Abschnitt 3.2 behandelte Fall des interaktiven Vor- 1 IP-Multicast benötigt aufgrund seiner Struktur eine gewisse Zeit, bis angeschlossene Empfänger einer Multicast-Gruppe beitreten können (Join/Leave Latency). Gängige Werte sind in der Praxis je nach Anzahl der benötigter Netzwerkknoten (Hops) 2-4 Sekunden. spulens eine neue Anfrage. Der Scheduler errechnet eine neue Sende- und Sitzungsbeschreibung, die an den Empfänger übertragen wird. Empfänger E spult in nachfolgendem vereinfachten Beispiel aus Abschnitt 4.2 im Media-Objekt an die Stelle t Si =10 Minuten vor. E->M: PLAY rtsp://video.com/v1 RTSP/1.0 Transport: client_port= Range: smpte=0:10:00 M->E: RTSP/1.0 OK Range: smpte=0:10:00 Transport: a=cstream m=video RTP/AVP 31 c=in IP /15 a=mcit: m=video RTP/AVP 31 a=mcit: m=video RTP/AVP 31 a=mcit: Das erste Segment wird im Unterschied zu 4.1 ab der Stelle t Si über eine Unicast-Verbindung an den Empfänger E geschickt. Damit wird das Problem der IP- Multicast Join/Leave Latency umgangen. Springt ein Empfänger bei wiederholtem Vor- und Zurückspulen an eine Stelle zurück, deren vollständiges Segment nicht lokal gespeichert ist, so wird dieser Fall von dem System wie interaktives Vorspulen behandelt. 5 Simulationsergebnisse Die folgenden Abschnitte widmen sich ersten Simulationen des ISP Systems. Dabei wird jeweils ein Simulationszeitraum von vier Stunden (Prime Time) untersucht. Die Anfragen genügten dabei einer Gleichverteilung mit einer mittleren Anfragerate λ, welche für das ISP den schlechtsten Fall, aber für Unicast-MoD den besten Fall darstellt. Die Länge des Media- Objektes entspricht der durchschnittlichen Länge eines Spielfilmes (90 Minuten). Die anderen Parameter die Anfragerate λ, die Länge der einzelnen Segmente S und die am Empfänger verfügbare Bandbreite R wurden variiert. Dabei werden alle Anfragen innerhalb einer Sekunde zusammengefasst und es wird ausschließlich der Bandbreitenbedarf für das eigentliche Streaming beobachtet. Die RTSP- Kommunikation bzw. IP-Multicast Protokollverkehr wird aufgrund ihrer sehr niedrigen Datenmenge in den Simulationen vernachlässigt.

6 5.1 Optimale Segment-Länge kleinem λ bringen lange Segmente Vorteile, da in einem großen Zeitraum mehr Anfragen "gesammelt" werden können. Steigt λ an, so wird der Anteil, der durch das erste Segment erzeugt wird größer. Bei sehr hohem λ überwiegt der Anteil dieser Grundbelastung, so dass kleinere Segment-Längen vorteilhaft sind. 5.2 ISP vs. Unicast-MoD Bild 2 Optimale Segment-Länge, λ=20 Bild 4 ISP vs. Unicast λ=20, R=2 Bild 3 Optimale Segment-Länge, λ=625 Die Anzahl der Segmente, in die ein Objekt zerlegt wird, hat einen Einfluss auf die durchschnittlich beanspruchten Ressourcen am MoD-Server. Je nach λ kann die optimale Segment-Länge variieren. Bild 2 und 3 zeigen exemplarisch die Variation der durchschnittlichen Server-Bandbreite, abhängig von der gewählten Segment-Länge. Die Empfänger sind in der Lage, entweder zwei (R=2) oder drei Datenströme (R=3) parallel zu empfangen. Bei einer relativ geringen Anfragerate von λ=20 Anfragen pro Stunde (Bild 2) ist eine größere Segment-Länge optimal, während bei großer Anfragerate kleinere Segment-Längen die optimale Zerlegung des Videos darstellen (Bild 3). Dieser Zusammenhang wird deutlich, wenn man die Anteile betrachtet, aus denen sich die Belastung des Servers zusammensetzt. Bei einem oder mehreren zeitgleichen Anfragen muss für einen augenblicklichen Beginn grundsätzlich das erste Segment des Media- Objektes sofort übertragen werden. Das heißt, dass alle späteren Empfänger dieses Segmentes auf jeden Fall verpasst haben, und dieses neu übertragen werden muss. Daraus folgt eine gewisse Grundbelastung des Media-Servers. Jetzt zu schließen, dass eine möglichst kleine Segment-Länge von Vorteil ist, wird durch die Simulationsergebnisse widerlegt. Die Anzahl der neuen Anfragen, die während der Dauer eines Segmentes eintreffen, ist bei langen Segmenten im statistischen Mittel größer als bei kurzen. Daraus folgt, dass sich eine größere Anzahl von Empfängern alle folgenden Segmente teilen kann. Bei Bild 5 ISP vs. Unicast λ=625, R=2 In einer weiteren Untersuchung wurde versucht, die erzielbare Reduktion der serverseitigen Ressourcen von ISP im Vergleich zum Unicast-MoD abzuschätzen. Bild 4 zeigt den zeitlichen Verlauf der Serverbelastung im Vergleich zwischen Unicast und ISP (R=2). Die Segment-Länge wurde gemäß Abschnitt 5.1 auf ihr Optimum eingestellt. Es wird angenommen, dass zum Zeitpunkt t=t 0 keinerlei Datenverkehr über die Netzwerkanbindung des Servers stattfindet. Aus diesem Grund kann man zu Beginn der Simulation einen Anstieg der Bandbreitenauslastung erkennen. Trotz der ungünstigen Verteilung der Anfragen (Gleichverteilung) führt wie in Bild 4 dargestellt ISP gegenüber der herkömmlichen Unicast-Übertragung schon bei relativ geringem λ zu einer deutlichen Reduzierung der am Server benötigten Ressourcen. Die Bandbreitenersparnis steigert sich mit der Anzahl der Anfragen erheblich (Bild 5). Für λ=625 traten bei Unicast am Server maximal 900 Datenströme auf wobei für R=2 maximal 76 (Bild 5) bzw. für R=3 maximal 52 Datenströme parallel auftraten.

7 6 Zusammenfassung Es wurde in diesem Beitrag mit dem Interactive Segment Patching ein datenbasiertes Echtzeit Media-on- Demand Verfahren für den Einsatz in IP-Netzwerken vorgestellt, das neben dem augenblicklichen Beginn der Übertragung auch die interaktiven Funktionen Pause und schneller Vor-/ Rücklauf unterstützt. Das Media-Objekt wird dabei in Segmente fester Länge unterteilt und über IP-Multicast- und Unicastverbindungen übertragen. Dazu müssen die Empfänger lokal über ausreichend Puffer (Festplatte) und Netzwerkanbindung verfügen. Die Erfahrungen mit dem Virtuellen Internet- Rundfunk haben gezeigt, dass das vorgeschlagene System ähnlich den Unicast-MoD Verfahren einfach implementierbar ist und in der Praxis robust arbeitet. Erste Untersuchungen bestätigen, dass bei geeigneter Wahl der Segmentlänge eine signifikante Reduzierung der benötigten Serverressourcen erreicht wird. Ein solches System ist im Vergleich zu den in der Praxis meist verwendeten Unicast-MoD Verfahren deutlich unempfindlicher gegen starke Schwankungen in den Anfrageraten. 7 Literatur [1] Hua, A. et al.: Patching: A Multicast Technique for True Video-on-Demand Services, ACM Multimedia, 1998 [2] Schröder, K., Gebhard, H.: Audio-/Video- Streaming über IP (Internet-Protokoll), FKT, Heft , S , ISSN , 2000 [3] L. Gao, D. Towsley: Supplying Instantaneous Video-on-Demand Services Using Controlled Multicast,Proceedings of IEEE Multimedia Computing Systems'99, 1999 [4] Asit Dan, Dinkar Sitaram and Perwez Shahabuddin: Scheduling Policies for an On-Demand Video Server with Batching, IBM Research Division, T. J., 1994 [5] S. Viswanathan, Tomasz Imielinski: Metropolitan Area Video-on-Demand Service Using Pyramid Broadcasting. Multimedia Systems 4(4), 1996, pp [6] Heredia, E. A.: On the Optimal Use of Network Bandwidth for Broadcast Video-On-Demand, Packet Video 99, New York, April, 1999 [7] Aggarwal; Charu, C.; Wolf, J. L.; Yu, P. S.: Design and analysis of permutation-based pyramid broadcasting, Multimedia Systems, Volume 7 Issue 6, pp , 1999 [8] Hua, K. A.; Sheu, S.: Skyscraper Broadcasting: A New Broadcasting Scheme for Metropolitan Video-on-Demand Systems, ACM SIG- COMM'97, 1997, pp [9] Juhn, L.; Tseng, L.: Harmonic broadcasting for video-on-demand service. IEEE Transactions on Broadcasting, 43(3), 1997, pp [10] Pâris, J.-F.; Carter, S. W.; Long, D. D. E.: Efficient Broadcasting Protocols for Video-on- Demand, MASCOTS '98, Montreal, 1998, pp [11] Asit, D. et al.: Dynamic batching policies for an on-demand video server, Multimedia Systems, 1996, pp [12] Dan, A.; Sitaram, D.; Shahabuddin, P.: Scheduling Policies for an On-Demand Video Server with Batching, IBM Research Division, 1994 [13] Aggarwal, C.; Wolf J. L.; Yu, P. S.: "The Maximum Factor Queue Length Batching Scheme for Video-on-Demand Systems", IBM Research report RC 20621, 1996 [14] Sitaram, D.; Dan, A.: Multimedia Servers: Applications, Environments, and Design,: Morgan Kaufmann Publishers, Inc., 1999, pp [15] Cai Y., Hua K. A., and Vu K., Optimizing Patching Performance, Multimedia Computing and Networking 1999, SPIE, 1999 [16] Gao, L.; Towsley, D.: Threshold-Based Multicast for Continuous Media Delivery, IEEE Multimedia Computing and Systems, 1999 [17] Carter, S. W.; Long, D. D. E.: Stream Tapping: a System for Improving Efficiency on a Video-on- Demand Server, UCSC-CRL-97-11, 1997 [18] Carter, S. W.; Long, D. D. E.: Improving Videoon-Demand Server Efficiency Through Stream Tapping, ICCCN 97, Las Vegas, 1997pp [19] Sen, S.; Gao, L.; Rexford, J.; Towsley D.: Optimal Patching Schemes for Efficient Multimedia Streaming, NOSSDAV'99, 1999 [20] Gebhard, H., Lindner, L., Virtual Broadcast - A novel service based on IP Multicast, IEEE Poms2000, Krakau, 2000 [21] Gebhard, H., Kays, R.: Virtueller Rundfunk über das Internet, FKT, Heft , 2001 [22] Gebhard, H., Lindner, L., Virtual Internet Broadcasting, IEEE Communications Magazine, Heft Juni 2001, 2001 [23] Schulzrinne, H. et al.: RTP: A Transport Protocol for Real-Time Applications, RFC 1889, 1999 [24] Schulzrinne, H. et al.: Real Time Streaming Protocol (RTSP), RFC 2326, 1998 [25] Gebhard, H., Schröder, K.: One-to-One TV over IP-Multicast, IEEE Packet Video Workshop, Cagliari, 2000