Adaptive Unicast Live-Streaming in a Mobile-TV Environment ...positron/main.pdf · Adaptive Unicast Live-Streaming in a Mobile-TV Environment (Adaptives Unicast Live-Streaming für

RHEINISCH-WESTFÄLISCHE TECHNISCHE

HOCHSCHULE AACHENLEHRSTUHL FÜR INFORMATIK 4PROF. DR. RER. NAT. OTTO SPANIOL

Adaptive Unicast Live-Streaming in aMobile-TV Environment

(Adaptives Unicast Live-Streamingfür mobiles Fernsehen)

DIPLOMARBEIT

DOMINIK FRIEDRICH

MATRIKELNUMMER: 227416

BETREUUNG: PROF. DR. OTTO SPANIOL

ZWEITGUTACHTER: PROF. DR. MANFRED NAGL

BETREUENDE ASSISTENTEN: STEFAN DIEPOLDER

JAN KRITZNER

Eidesstattliche Versicherung

Hiermit versichere ich an Eides Statt, dass ich die vorliegende Diplomarbeit selbständigund nur unter Benutzung der angegebenen Hilfsmittel angefertigt habe. Alle Stellen,die wörtlich oder sinngemäß aus veröffentlichten Schriften entnommen wurden, sindals solche kenntlich gemacht.

Aachen, 27. Oktober 2006

iii

ABKÜRZUNGSVERZEICHNIS

AIAD . . . . . . . . . . . . . . Additive Increase / Additive Decrease, Seite 47AM . . . . . . . . . . . . . . . . Acknowledged Mode, Seite 16ARQ . . . . . . . . . . . . . . . Automatic Repeat Request, Seite 28AuC . . . . . . . . . . . . . . . . Authentication Center, Seite 11BLER . . . . . . . . . . . . . . . Block Error Rate, Seite 25BMC . . . . . . . . . . . . . . . Block Motion Compensation, Seite 20BSC . . . . . . . . . . . . . . . . Base Station Controller, Seite 10BSS . . . . . . . . . . . . . . . . . Base Station Subsystem, Seite 10BTS . . . . . . . . . . . . . . . . Base Transceiver Station, Seite 10CBR . . . . . . . . . . . . . . . . Constant Bitrate, Seite 21CENELEC . . . . . . . . . . Comité Européen de Normalisation Electrotechnique, Seite 3CIF . . . . . . . . . . . . . . . . . Common Intermediate Format, Seite 4CN . . . . . . . . . . . . . . . . . Core Network, Seite 12CSV . . . . . . . . . . . . . . . . Comma Separated Values, Seite 60DAB . . . . . . . . . . . . . . . Digital Audio Broadcast, Seite 5DMB . . . . . . . . . . . . . . . Digital Multimedia Broadcast, Seite 4DRNC . . . . . . . . . . . . . . Drift Radio Network Controller, Seite 12DVB . . . . . . . . . . . . . . . . Digital Video Broadcast, Seite 3DVB-C . . . . . . . . . . . . . Digital Video Broadcast Cable, Seite 4DVB-H . . . . . . . . . . . . . Digital Video Broadcast Handheld, Seite 3DVB-S . . . . . . . . . . . . . . Digital Video Broadcast Satellite, Seite 4DVB-T . . . . . . . . . . . . . Digital Video Broadcast Terrestrial, Seite 4DVD . . . . . . . . . . . . . . . Digital Versatile Disc, Seite 21EIR . . . . . . . . . . . . . . . . . Equipment Identity Register, Seite 11ES . . . . . . . . . . . . . . . . . . Elementary Stream, Seite 21ETSI . . . . . . . . . . . . . . . . European Telecommunications Standards Institute, Seite 3FDD . . . . . . . . . . . . . . . . Frequency Division Duplex, Seite 14FDM . . . . . . . . . . . . . . . Frequency Division Multiplexing, Seite 12FDMA . . . . . . . . . . . . . Frequency Division Multiple Access, Seite 13FGS . . . . . . . . . . . . . . . . Fine Granularity Scalability, Seite 84FIFO . . . . . . . . . . . . . . . First In / First Out, Seite 53

v

GGSN . . . . . . . . . . . . . . Gateway GPRS Support Node, Seite 11GMSC . . . . . . . . . . . . . . Gateway Mobile Switching Center, Seite 12GOP . . . . . . . . . . . . . . . . Grops of Pictures, Seite 21GPL . . . . . . . . . . . . . . . . General Public License, Seite 41GPRS . . . . . . . . . . . . . . . General Packet Radio Service, Seite 10GUI . . . . . . . . . . . . . . . . Graphical User Interface, Seite 45HLR . . . . . . . . . . . . . . . . Home Location Register, Seite 11HRSN . . . . . . . . . . . . . . Highest Received Sequence Number, Seite 34HSCSD . . . . . . . . . . . . . High Speed Circuit Switched Data, Seite 10HTSN . . . . . . . . . . . . . . Highest Transmitted Sequence Number, Seite 34IEC . . . . . . . . . . . . . . . . . International Electrotechnical Commission, Seite 19ISDB-T . . . . . . . . . . . . . Integrated Service Digital Broadcast Terrestrial, Seite 3ITU . . . . . . . . . . . . . . . . International Telecommunication Union, Seite 61LPSN . . . . . . . . . . . . . . . Last Played Sequence Number, Seite 34MAC . . . . . . . . . . . . . . . Medium Access Control, Seite 15MBMS . . . . . . . . . . . . . . Multimedia Broadcast / Multicast Service, Seite 6MIMD . . . . . . . . . . . . . . Multiplicative Increase / Multiplicative Decrease, Seite 37MOS . . . . . . . . . . . . . . . Mean Opinion Score, Seite 61MPE-FEC . . . . . . . . . . Multi-Protocol Encapsulated Forward Error Correction, Seite 4MPEG . . . . . . . . . . . . . . Moving Picture Expert Group, Seite 19MS . . . . . . . . . . . . . . . . . Mobile Station, Seite 10MSC . . . . . . . . . . . . . . . Mobile Switching Center, Seite 11MSE . . . . . . . . . . . . . . . . Mean Squared Error, Seite 61NGMN . . . . . . . . . . . . . Next Generation Mobile Network, Seite 1NMM . . . . . . . . . . . . . . Network-Integrated Multimedia Middleware, Seite 42NSS . . . . . . . . . . . . . . . . Network Subsystem, Seite 11OBSN . . . . . . . . . . . . . . Oldest Buffer Sequence Number, Seite 33PCU . . . . . . . . . . . . . . . . Packet Control Unit, Seite 10PD . . . . . . . . . . . . . . . . . Playout Delay, Seite 33PDU . . . . . . . . . . . . . . . . Protocol Data Unit, Seite 15PSNR . . . . . . . . . . . . . . Peak Signal to Noise Ratio, Seite 61QoE . . . . . . . . . . . . . . . . Quality of Exceprience, Seite 84QoS . . . . . . . . . . . . . . . . Quality of Service, Seite 84QVGA . . . . . . . . . . . . . Quater Video Graphics Array, Seite 4RF-TRC . . . . . . . . . . . . RTCP Feedback based Transmission Rate Control, Seite 32RFC . . . . . . . . . . . . . . . . Request For Comments, Seite 32RLC . . . . . . . . . . . . . . . . Radio Link Control, Seite 15RNC . . . . . . . . . . . . . . . Radio Network Controller, Seite 12RR . . . . . . . . . . . . . . . . . Receiver Report, Seite 26

vi

RRC . . . . . . . . . . . . . . . . Radio Resource Control, Seite 17RTCP . . . . . . . . . . . . . . . RTP Control Protocol, Seite 26RTP . . . . . . . . . . . . . . . . Real-Time Transport Protocol, Seite 26RTSP . . . . . . . . . . . . . . . Real-Time Streaming Protocol, Seite 43RTT . . . . . . . . . . . . . . . . Round Trip Time, Seite 25S-DMB . . . . . . . . . . . . . Satellite Digital Multimedia Broadcast, Seite 5SAP . . . . . . . . . . . . . . . . Service Access Point, Seite 16SDL . . . . . . . . . . . . . . . . Simple Directmedia Layer, Seite 48SDU . . . . . . . . . . . . . . . . Service Data Unit, Seite 15SGSN . . . . . . . . . . . . . . Serving GPRS Support Node, Seite 11SIP . . . . . . . . . . . . . . . . . Session Initiation Protocol, Seite 43SR . . . . . . . . . . . . . . . . . . Sender Report, Seite 26SRNC . . . . . . . . . . . . . . Serving Radio Network Controller, Seite 12TB . . . . . . . . . . . . . . . . . . Transport Block, Seite 15TBS . . . . . . . . . . . . . . . . Transport Block Set, Seite 15TDD . . . . . . . . . . . . . . . Time Division Duplex, Seite 14TDM . . . . . . . . . . . . . . . Time Division Multiplexing, Seite 12TDMA . . . . . . . . . . . . . Time Division Multiple Access, Seite 13TFRC . . . . . . . . . . . . . . . TCP Friendly Rate Control, Seite 31Tr . . . . . . . . . . . . . . . . . . Transparent Mode, Seite 15TTI . . . . . . . . . . . . . . . . . Transmission Time Interval, Seite 15UM . . . . . . . . . . . . . . . . Unacknowledged Mode, Seite 15UMTS . . . . . . . . . . . . . . Universal Mobile Telecommunication System, Seite 9UTRAN . . . . . . . . . . . . UMTS Terrestrial Radio Access Network, Seite 12VBV . . . . . . . . . . . . . . . . Video Buffering Verifier, Seite 21VLC . . . . . . . . . . . . . . . . VideoLAN Client, Seite 41VLR . . . . . . . . . . . . . . . . Visitor Location Register, Seite 11VoD . . . . . . . . . . . . . . . . Video on Demand, Seite 5WCDMA . . . . . . . . . . . Wideband Code Division Multiple Access, Seite 12

vii

INHALTSVERZEICHNIS

1 Einleitung 1

2 Übertragung von Fernsehinhalten auf mobile Endgeräte 32.1 Digital Video Broadcast Handheld . . . . . . . . . . . . . . . . . . . . . . 32.2 Digital Multimedia Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Next Generation Mobile Network . . . . . . . . . . . . . . . . . . . . . . . 5

3 Das Universal Mobile Telecommunication System 93.1 Funkübertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Physikalische Übertragung . . . . . . . . . . . . . . . . . . . . . . 133.1.2 Medium Access Control . . . . . . . . . . . . . . . . . . . . . . . . 153.1.3 Radio Link Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.4 Vermittlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Videokomprimierung nach dem MPEG-Standard 194.1 Verlustbehaftete Komprimierung . . . . . . . . . . . . . . . . . . . . . . . 194.2 Rate Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Modell und Algorithmen 235.1 Modell des Unicast Live-Streamings über einen UMTS-Link . . . . . . . 23

5.1.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.2 Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.1.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.1.4 Übertragungsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . 265.1.5 Linkbandbreite und Client-Empfangsdatenrate . . . . . . . . . . 275.1.6 Buffer Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.7 Buffer Underruns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 Algorithmen zur Steuerung des Encoders, der Übertragung und derWiedergabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2.1 Einfacher Retransmit Algorithmus . . . . . . . . . . . . . . . . . . 305.2.2 TCP Friendly Rate Control . . . . . . . . . . . . . . . . . . . . . . 315.2.3 RTCP Feedback based Transmission Rate Control . . . . . . . . . 32

ix

Inhaltsverzeichnis

5.2.4 Adaptive Abspielbildrate . . . . . . . . . . . . . . . . . . . . . . . 355.3 Die Simulationsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.3.1 Frameworks und Bibliotheken . . . . . . . . . . . . . . . . . . . . 385.3.2 Flussgraphen in Multimedia-Anwendungen . . . . . . . . . . . . 395.3.3 VideoLAN Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.4 Network-Integrated Multimedia Middleware . . . . . . . . . . . 425.3.5 LiveMedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3.6 Das Qt-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.7 libavcodec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.3.8 mpeg2enc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.3.9 libmpeg2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.10 Simple Directmedia Layer . . . . . . . . . . . . . . . . . . . . . . . 48

5.4 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.4.1 Server-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.4.2 Client-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.4.3 Link-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.4.4 Value-Recorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6 Auswertung und Vergleich 616.1 Messgrößen und Bewertungskriterien . . . . . . . . . . . . . . . . . . . . 616.2 Messszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2.1 Szenario Flat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2.2 Szenario Block Error Rate . . . . . . . . . . . . . . . . . . . . . . . . 676.2.3 Szenario Bitrates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.2.4 Effekt der adaptiven Abspielbildrate . . . . . . . . . . . . . . . . . 736.2.5 Effekt der Bandbreiteninformation durch den Link . . . . . . . . 75

6.3 Versuchsergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7 Zusammenfassung 83

Abbildungsverzeichnis 85

Tabellenverzeichnis 87

Algorithmenverzeichnis 89

Literaturverzeichnis 91

x

1 EINLEITUNG

Im Jahr 2006 rückte das Thema „mobiles Fernsehen“ im Zuge der Fußballweltmeister-schaft in Deutschland in das Interesse der breiten Öffentlichkeit. Begleitet durch einbreites Medienecho sollte das sportliche Großereignis dazu genutzt werden, eine größe-re Anzahl an Kunden für die ersten kommerziellen Angebote zu gewinnen. Es wurdebereits vor mehreren Jahren damit begonnen spezielle Technologien für die Übertra-gung von Fernsehinhalten auf mobile Endgeräte zu entwickeln. In Europa sind diesinsbesondere das Digital Multimedia Broadcasting (DMB) und Digital Video BroadcastHandheld (DVB-H). Beide Systeme bauen auf bereits eingeführten Technologien auf.So handelt es sich bei DMB um eine Erweiterung des Digital Audio Broadcast (DAB).DVB-H ist eine speziell für mobile Endgeräte weiterentwickelte Variante des DigitalVideo Broadcast Terrestrial (DVB-T).

Gemeinsam ist beiden Systemen, dass sie bisher nur in wenigen Ballungsgebietengenutzt werden können. Zusätzlich ist das Angebot an Endgeräten für beide Techno-logien noch sehr gering. Sowohl für DMB, als auch DVB-H werden spezielle, nichtzueinander kompatible Empfangsteile in den Endgeräten benötigt. Derzeit ist nichtabzusehen, welche der beiden Technologien sich durchsetzen wird. Ein Großteil derHersteller von geeigneten Endgeräten führt daher zur Zeit hauptsächlich Prototypenauf Messen.

Im Gegensatz dazu sind für das Abspielen von Videos geeignete Mobiltelefone bereitsheute in hoher Stückzahl verfügbar. Seit geraumer Zeit schon werden Mobiltelefonemit ausreichend großem Farbdisplay und der notwendigen Rechenleistung verkauft.Die Infrastruktur von Mobilfunknetzen erreicht in vielen Industrieländern bereits heu-te eine Flächenabdeckung von nahezu 100%. Während die erreichbare Datenrate bisvor einiger Zeit nicht für ein Live-Streaming mit akzeptabler Bildgröße und -qualitätausreichte, so hat sich dies mit der Einführung der Next Generation Mobile Networks(NGMN) drastisch geändert.

1

1 Einleitung

Das bekannteste Next Generation Mobile Network ist das Universal Mobile Telecom-munication System (UMTS). In einer Vielzahl von Ländern weltweit wurde bereitsvor mehreren Jahren mit der Aufrüstung von Global System for Mobile Communi-cation (GSM) Mobilfunknetzen auf UMTS begonnen. Sowohl bei der Ausstrahlungüber DMB, als auch über DVB-H werden die einzelnen TV-Kanäle mit einer Daten-rate von ca. 300 kBit/s gesendet. Bereits heute sind in UMTS-Netzen Datenraten vonbis zu 2 MBit/s möglich, so dass diese ebenfalls für die Übertragung von Streams invergleichbarer Qualität geeignet sind.

Eine Datenrate von 2 MBit/s ist allerdings derzeit in einem UMTS-Netz nur in sel-tenen Fällen zu erreichen. Im Normalfall ist mit einer Datenrate von ca. 144 kBit/s -384 kBit/s zu rechnen. Befindet sich das Mobiltelefon in Bewegung, zum Beispiel weilder Besitzer mit der Straßenbahn fährt, so kann es zu starken Schwankungen in derverfügbaren Bandbreite kommen. Derzeit werden in solchen Situationen entwedermassive Bildstörungen und eine ruckelnde Wiedergabe in Kauf genommen, oder dieDatenrate des Live-Streams wird pessimistisch auf einen sehr niedrigen Wert festgelegt.Im Rahmen dieser Diplomarbeit sollen nun Algorithmen entwickelt werden, welche esermöglichen, die Datenrate des gesendeten Live-Streams dynamisch an die verfügbareBandbreite anzupassen. Ziel ist es zum einen Bildfehler und eine ruckelnde Wiederga-be zu verhindern. Zum anderen sollen sowohl eine optimale Bildqualität, als auch eineminimale Abspielverzögerung auf dem Endgerät erreicht werden.

Im folgenden Kapitel werden zunächst die schon angesprochenen Technologien fürmobiles Fernsehen noch einmal genauer dargestellt. Im Anschluß daran folgt ein Über-blick über das UMTS-Mobilfunksystem und die Grundlagen der Videokomprimierung.Im fünften Kapitel werden die Eigenschaften der am Live-Streaming beteiligten Kom-ponenten beschrieben. Die für die Untersuchung der neu entwickelten Algorithmengeschriebene Simulationsumgebung wird in dem darauf folgenden Kapitel dargestellt.Abgeschlossen wird diese Arbeit mit der Präsentation und Analyse der gewonnenenVersuchsergebnisse.

2

2 ÜBERTRAGUNG VON FERNSEHINHALTEN

AUF MOBILE ENDGERÄTE

Wenn man derzeit in Europa über das Thema „mobiles Fernsehen“ spricht, so wer-den hauptsächlich zwei Technologien genannt, zum einen Digital Video BroadcastHandheld (DVB-H) und zum anderen Digital Multimedia Broadcast (DMB). DieseTechnologien sind weltweit die Hauptkonkurrenten für die Übertragung von Fern-sehinhalten auf mobile Endgeräte. Daneben existieren noch weitere Systeme. In denUSA wird beispielsweise neben DVB-H auch das von Qualcom entwickelte MediaFLOeingesetzt. In Japan bietet NTT Docomo seit Oktober 2004 mobiles Fernsehen über einMobaHO! genanntes satellitenbasiertes System an. Ebenfalls in Japan wird IntegratedService Digital Broadcast Terrestrial (ISDB-T), ein System ähnlich zu DMB, genutzt. Da-neben existieren noch weitere Systeme, die weltweit am häufigsten eingesetzten sindallerdings DVB-H und DMB. Bei geplanten Netzwerken wird weitgehend auf einendieser beiden Standards gesetzt.

2.1 Digital Video Broadcast Handheld

Bei DVB-H handelt es sich um ein weiteres Mitglied in der Familie der DVB-Standards.Die Digital Video Broadcast-Standards (DVB) wurden im Rahmen des DVB-Projektesentwickelt und über die beiden Normierungsorganisationen European Telecommu-nications Standards Institute (ETSI) und Comité Européen de Normalisation Electro-technique (CENELEC) zu internationalen Standards erhoben. Das DVB-Projekt ist einZusammenschluss von über 270 europäischen Unternehmen. Über europäische Toch-terunternehmen sind auch amerikanische und asiatische Unternehmen an dem DVB-Projekt beteiligt, so dass es sich nicht um ein rein europäisches Projekt handelt.

Die am weitesten verbreiteten DVB-Standards sind DVB-S für die satellitengestützteÜbertragung von Fernseh- und Radioprogrammen und DVB-C für die Übertragungsolcher Inhalte über Breitbandkabel. Diese beiden Standards werden praktisch vonallen europäischen Netzwerkbetreibern für die digitale Rundfunkübertragung einge-setzt. Hinzugekommen ist in den letzten Jahren verstärkt DVB-T, das in Deutschland

3

2 Übertragung von Fernsehinhalten auf mobile Endgeräte

und anderen europäischen Ländern wie zum Beispiel der Schweiz die analoge terrest-rische Fernsehübertragung vollständig ersetzen soll.

Allen drei Standards ist gemein, dass sie den MPEG 2-Standard [18] für die Video-und Audio-Kodierung einsetzen. Für die Übertragung werden mehrere einzelne TV-und Radio-Programme zu einem MPEG-2 Transport Stream (TS) [17] gemultiplext. Dieeinzelnen TV-Programme sind in in der Regel mit einer Bitrate von 5-8 MBit/s kodiert,so dass zum Beispiel auf einen Satelliten-Kanal mit einer Bandbreite von 38 MBit/szwischen 5 und 10 TV-Programme gleichzeitig übertragen werden können.

Im Gegensatz dazu schreibt der DVB-H-Standard [8] den Einsatz des modernen H.264/MPEG 4 AVC [19] Codecs vor, der im Vergleich zu MPEG-2 Encodern eine wesentlichhöhere Kodiereffizienz erreicht [22]. Zusätzlich ist die Auflösung des Videobildes fürDVB-H auf wahlweise QVGA (320x240 Bildpunkte) oder CIF (352x288 Bildpunkte)reduziert. Pro Fernsehprogramm ergibt sich daraus eine Datenrate von ca. 300 kBit/s.Für DVB-H wurde das Übertragungsverfahren von DVB-T übernommen, allerdingsmit einigen speziellen Anpassungen für die Übertragung auf mobile Endgeräte. Umeine ausreichende Empfangsqualität auch in Bewegung und ungüstigem Umfeld zuerreichen, wurde eine zusätzliche Fehlerkorrektur eingeführt [25]. Die Multi-ProtocolEncapsulation Forward Error Correction (MPE-FEC) sichert die gekapselten Daten-pakete zusätzlich zu den schon vorhandenen Fehlerkorrekturmechanismen auf dendarunter liegenden Schichten. Mehrere TV-Programme werden für die Übertragungper DVB-H ebenso wie bei den anderen DVB-Standards zu einem MPEG-2 TS gemulti-plext. Die Pakete der einzelnen TV-Programme werden dabei allerdings so angeordnet,dass die Pakete jedes einzelnen TV-Programms einen definierten zeitlichen Abstandzueinander im TS haben. Durch dieses zeitliche Multplexing, time slicing genannt, istes den Endgeräten möglich die Empfangseinheit zwischen dem Empfang zweier Pa-kete auszuschalten, was zu einer Energieeinsparung von bis zu 25% führt ([50], [6]).

2.2 Digital Multimedia Broadcast

Der DMB-Standard [9] ist eine Erweiterung des Digital Audio Broadcast Standards(DAB). Der DAB-Standard wurde im Rahmen des EU-Projektes „Eureka-147“ entwi-ckelt und wie die DVB-Standards von der europäischen StandardisierungsinstitutionETSI übernommen. DAB wurde entwickelt, um den analogen, terrestrischen Hörfunkdurch eine digitale Alternative bis zum Jahr 2010 zu ersetzen. In Großbritannien istein Radioempfang über DAB nahezu flächendeckend möglich. Dort wurden bereits

4

2.3 Next Generation Mobile Network

ca. 3,5 Mio. DAB-Empfänger verkauft. In Deutschland wird ebenfalls eine hohe Flä-chendeckung von etwa 80% erreicht. Aufgrund von Leistungsbeschränkungen fürDAB-Sender ist ein Empfang innerhalb von Gebäuden in Deutschland nicht überallmöglich. Dieses Problem, sowie ein eingeschränktes Programmangebot haben einegröße Verbreitung bislang verhindert.

Das DMB-System wurde ursprünglich von Bosch gemeinsam mit dem Heinrich-HertzInstitut für Nachrichtentechnik der Fraunhofer Gesellschaft entwickelt. Im asiatischenRaum wurde diese Technologie aufgenommen und weiterentwickelt [26]. Im Jahr 2005wurde die DMB-Spezifikation von der ETSI übernommen und zu einem offiziellenStandard erklärt. Ebenso wie DVB-H wird bei DMB das moderne H.264 Komprimie-rungsverfahren für das Videobild eingesetzt. Wird das QCIF-Bildformat verwendet, soliegt die Datenrate ebenfalls bei ca. 300 kBit/s. Da der ürsprüngliche DAB-Standardbereits mit Hinblick auf mobile Endgeräte entwickelt wurde, konnte das Übertragungs-verfahren für DMB vollständig übernommen werden. Es ist ein Mischbetrieb von DAB-und DMB-Streams auf einem Transponder möglich. Im Gegensatz zu DVB-H sieht dieDMB Spezifikation einen Rückkanal vor so dass beispielsweise interaktive Inhalte mitZuschauerbeteiligung über DMB ausgestrahlt werden können.

In Deutschland und einigen weiteren europäischen Staaten werden über die bestehen-de DAB Infrastruktur bereits Fernsehprogramme im DMB-Format angeboten. Eine we-sentlich höhere Verbreitung hat DMB im asiatischen Raum, insbesondere in Süd-Koreaund seit Anfang 2006 auch in China. In Süd-Korea wird allerdings die satellitengestüz-te Variante S-DMB und nicht die sonst sonst genutzte terrestrische genutzt. Ebensowie für DVB-H ist auch für DMB die Anzahl der kommerziell verfügbaren Endgeräte,insbesondere außerhalb Asiens sehr beschränkt.


Abbildung 2.1 zeigt die Entwicklung der UMTS-Teilnehmerzahlen vom Start der ers-ten UMTS-Netze im Jahr 2002 bis zum Jahr 2005. Innerhalb von nur drei Jahren istdie Teilnehmerzahl von unter einer Million auf über 47 Millionen angestiegen. Einweiterer starker Anstieg der Teilnehmerzahl ist zu erwarten, da die Aufrüstung vielerbestehender GSM-Mobilfunknetze auf UMTS bereits weit fortgeschritten ist. Ebensoist mittlerweile eine Vielzahl von UMTS-Mobilfunktelefonen in große Stückzahl ver-fügbar. Bei der Spezifikation des UMTS-Systems wurden von Beginn an Datendienstemit berücksichtigt. Neben dem Surfen im Internet sollten die UMTS-Netze auch fürMultimedia-Anwendungen wie Video-on-Demand (VoD) oder mobiles Fernsehen ge-nutzt werden.

5

2 Übertragung von Fernsehinhalten auf mobile Endgeräte

Abbildung 2.1: Enwicklung der UMTS-Teilnehmerzahl

Im November 2004 wurde eine Spezifikation [1] für einen Multimedia Broadcast/ Mul-ticast Service (MBMS) für UMTS Netze erarbeitet. Es wird erwartet, dass bis Ende 2008die notwendigen Systeme sowohl für das UMTS Kernnetz, als auch für die Endgeräteverfügbar sind. Bis 2010 sollen dann etwa 30% der UMTS Netzwerke und Endgerätediesen Standard implementiert haben. Über diesen Service sollen dann unter anderemTV-Programme ausgestrahlt werden. Der Datenstrom eines TV-Programms wird imBroadcast-Modus gleichzeitig an alle Teilnehmer in einem definierten Gebiet ausge-strahlt. Im Multicast-Modus müssen die Streams von den Nutzern abonniert werden,bevor sie übertragen werden. Um Resourcen zu sparen, wird der Datenstrom aus demUMTS Kernnetz nur einmal an die jeweiligen Radio Network Subsystems (RNS), diefür die Funkübertragung zu den Endgeräten zuständig sind, übertragen. Diese sendendie Daten auf einem speziellen Kanal gleichzeitig an alle Endgeräte, so dass nur eineder Streambitrate entsprechende Bandbreite zur Übertragung notwendig ist.

6


Empfänger1

Empfänger2

Empfänger3

Broadcast

Sender

Empfänger1

Empfänger2

Empfänger3

Unicast

Netzwerk Netzwerk

Sender

Datenfluss

Abbildung 2.2: Vergleich der Datenübertragung via Unicast und Broadcast

Das UMTS-Netz eignet sich allerdings im Gegensatz zu DVB-H- und DMB-Netzenauch für die Übertragung von TV-Streams im Unicast-Verfahren. Bei diesem wirdzwischen Sender und jedem einzelnen Empfänger eine Punkt-zu-Punkt-Verbindungaufgebaut. Der Sender kann so den TV-Stream zu jedem Empfänger in der passendenDatenrate und Übertragungsgeschwindigkeit senden. Im Broadcast- oder Multicast-Verfahren wird jeder TV-Stream dagegen nur mit einer Datenrate an alle Empfängergesendet. Abbildung 2.2 stellt den Unterschied noch einmal graphisch dar.

Der beschriebene Unicast Ansatz wird bereits heute in UMTS Netzen für das Live-Streaming von On-Demand Diensten genutzt. Dementsprechend wurde das Live-Streaming über einen UMTS Datenkanal mit Hinblick auf diese On-Demand Diensteschon mehrfach untersucht, zum Beispiel in [27], [11] oder [5].

7

3 DAS UNIVERSAL MOBILE

TELECOMMUNICATION SYSTEM

Begonnen hat der öffentliche Mobilfunk in Deutschland im Jahr 1958, als die damaligeBundespost das sogenannte A-Netz eröffnete. Dabei handelte es sich um ein analogesFunknetz, in dem die Teilnehmer nur miteinander im Bereich derselben Sendestationtelefonieren konnten. Die damaligen Endgeräte waren mit einem Gewicht von 16 kgnur für den Einbau in Autos geeignet. Alle Gespräche wurden handvermittelt und dieGesamtanzahl an Teilnehmern war auf 10.000 begrenzt.

Die beiden Nachfolger B-Netz (ab 1972) und C-Netz (ab 1985) waren ebenfalls analogeFunknetze. Neben einer auf 16000 Teilnehmer erhöhten Nutzerzahl konnte im B-Netzjeder Teilnehmer einen anderen Teilnehmer nun direkt anwählen, falls er dessen Stand-ort und somit die entsprechende Vorwahl wusste. Erst das C-Netz brachte zwei heutenicht mehr wegzudenkende Eigenschaften. Zum einen wurde das Roaming eingeführt,so dass jeder Teilnehmer nun über eine feste Nummer erreicht werden konnte. Zumanderen war nun ein Handover der Funkverbindung zwischen zwei Funkstationenmöglich. Zuvor wurde ein Gespräch unterbrochen, wenn ein Teilnehmer den Sendebe-reich der Funkstation verließ, mit der er gerade verbunden war.

Im Jahr 1992 begann dann in Deutschland das Zeitalter des digitalen Mobilfunks mitder Einführung der D-Netze. Diese Mobilfunknetze bauten auf dem seit 1982 ent-wickelten und im Jahr 1989 von der ETSI übernommenen europäischen Mobilfunk-Standard GSM auf. Dieser Standard wurde für Europa für verbindlich erklärt. Dahersind Funktionen wie das Roaming oder ein Handover auch zwischen Mobilfunetzenverschiedener Anbieter und über Landesgrenzen hinweg möglich.

Im Jahr 2000 wurden die Lizenzen für die nächste, dritte Generation von Mobilfun-knetzen nach dem UMTS-Standard versteigert. Der Erlös der Versteigerung von 100Milliarden DM zeigt, welche Hoffnungen in UMTS gesetzt wurden.

Die Einführung von UMTS stellt nicht einen kompletten Technologiewechsel dar, wieer bei dem Übergang vom analogen C-Netz zum digitalen D-Netz stattgefunden hat.UMTS ist stattdessen eine konsequente Weiterentwicklung des GSM-Standards hin

9

3 Das Universal Mobile Telecommunication System

Abbildung 3.1: Struktur eines GSM-Netzes

auf neue Anforderungen wie Multimedia Dienste. So ist UMTS abwärtskompatibel zu„GSM Phase 2+“, einer Erweiterung des ursprünglichen GSM-Standards. Unter ande-rem wurden für die Datenübertragung High Speed Circuit Switched Data (HSCSD)und der General Packet Radio Service (GPRS) eingeführt. Durch die Abwärtskompa-tibilität wird den Mobilfunkbetreibern zum einen ein Schutz ihrer bisher getätigtenInvestitionen in GSM-Netze gesichert, und zum anderen können diese Netze im lau-fenden Betrieb auf UMTS aufgerüstet werden.

In Abbildung 3.1 ist der schematische Aufbau eines GSM-Netzes mit GPRS-Erweite-rung dargestellt. Das gesamte Netzwerk ist in drei Bereiche aufgeteilt. Die Funkübertra-gung zu den Mobiltelefonen, Mobile Station (MS) genannt, wird von dem Base StationSubsystem (BSS) übernommen. Diese besteht wiederum aus den Base Transceiver Stati-on (BTS) genannten Funkstationen und den Base Station Controllern (BSC), welche dieFunkübertragung über einen oder mehrere BTS steuern. Mit der GPRS-Erweiterungsind im BSS noch Packet Control Units (PCU) dazugekommen. Die PCU erweitern dieBSC um die für GPRS-Kommunikation notwendigen Funktionen.

Für die Gesprächsvermittlung innerhalb des GSM-Netzes und in andere Telefonnetzesind die Mobile Switching Center (MSC) zuständig. Jedes MSC ist für einen geografi-schen Teilbereich des gesamten GSM-Netzes zuständig. Die einzelnen MSC sind un-tereinander über Hochgeschwindigkeitsdatenleitungen miteinander verbunden undbilden zusammen das Network Subsystem (NSS). Ebenso bilden die Serving GPRSSupport Nodes (SGSN) zusammen mit den Gateway GPRS Support Nodes (GGSN)

10

Abbildung 3.2: Struktur eines UMTS-Netzes

das GPRS Core Network. Die SGSN sind dabei für das Routing der GPRS-Pakete zuden einzelnen MS zuständig, während die GGSN die Kommunikation mit den ange-bundenen Netzwerken übernehmen.

Um Funktionen wie das Roaming zu ermöglichen, benötigen die MSC den aktuel-len Aufenthaltsort der angerufenen MS. Zu diesem Zweck hat jedes MSC ein VisitorLocation Register (VLR). In diesem wird der aktuelle Aufenthaltsort aller im verwal-teten Gebiet UEs gespeichert. Im Home Location Register (HLR) wiederum sind füralle Kunden des Netzwerbetreibers das VLR, in dessen Bereich er sich befindet, sei-ne Telefonnummer, freigeschalteten Dienste und weitere Informationen gespeichert.Zwei weitere wichtige Datenbanken im NSS sind das Authentication Center (AuC)und das Equipment Identity Register (EIR). Das AuC dient zur Authentisierung desUE gegenüber dem Netzbetreiber. Im EIR werden Nutzer- und Gerätekennnummerngespeichert. Wurde eine MS gestohlen, so kann sie im EIR markiert werden und es istkein Zugriff auf das Mobilfunknetz über diese MS mehr möglich.

Wird ein GSM-Netz auf UMTS umgerüstet, so können die bereits vorhandenen Kompo-nenten des Kernnetzes weiterverwendet werden. Vergleicht man die Abbildung 3.1 desGSM-Netzes mit der Abbildung 3.2 UMTS-Netzes, so erkennt man im wesentlichenzwei Unterschiede. Zum einen wurden die bei GSM getrennten Netze NSS und GPRSCore Network zu einem Core Network (CN) zusammengefasst. Zum anderen wurdedas Gateway Mobile Switching Center (GMSC) neu eingeführt. Das GMSC übernimmtdie Kommunikation mit externen Telefonnetzen, die zuvor in den MSC integriert war.

11


Die wesentliche Neuerung von UMTS gegenüber GSM liegt in der Funkübertragung.Während GSM auf einem 200 kHz breiten Frequenzband mit einer Kombination ausTime Division Multiplexing (TDM) und Frequency Division Multiplexing (FDM) über-trägt, wird bei UMTS ein Wideband Code Division Multiple Access (WCDMA) Ver-fahren mit einem 5 MHz breiten Frequenzband verwendet. Die Endgeräte werdenim UMTS-Sprachgebrauch nun als User Equipment (UE) bezeichnet. Ebenso wurdendie BTS in Node B umbenannt und die Kombination BSC und PCU wird Radio Net-work Controller (RNC) genannt. Der Begriff BSS wurde durch UMTS Terrestrial RadioAccess Network (UTRAN) ersetzt.

In GSM-Netzen musste die Verbindung während eines Handovers zwischen zwei Zel-len für einen Frequenzwechsel unterbrochen werden. Ein UE in einem UMTS-Netzkann dagegen aufgrund der verwendeten CDMA-Technologie parallel Verbindungenzu mehreren Node B aufbauen. Diese Funktion wird Mikrodiversität genannt. Sie er-möglicht auch einen Soft-Handover. Sind an diesem mehrere RNC beteiligt, so werdenalle bestehenden Verbindungen von einem primären RNC verwaltet. Dieser wird alsServing Radio Network Controller (SRNC) bezeichnet und alle anderen als Drift RadioNetwork Controller (DRNC).

3.1 Funkübertragung

Ebenso wie bei GSM-Netzen ist das gesamte Versorgungsgebiet eines UMTS-Netzes ineinzelne Versorgungszellen aufgeteilt. Der UMTS-Standard definiert drei verschiedeneZelltypen, die sich in der Fläche des versorgten Gebietes und erreichbarer Übertra-gungsdatenrate unterscheiden. Für großflächige Gebiete mit geringem Verkehrsauf-kommen (eine niedrige Nutzeranzahl) sind sogenante Makrozellen vorgesehen. Einesolche Zelle kann einen Durchmesser von bis zu 5 Kilometern haben und dient inerster Linie der Grundversorgung. In einer Makrozelle kann eine Datenraten von biszu 144 kBit/s bei einer maximalen Bewegungsgeschwindigkeit des UE von 500 km/herreicht werden. Gebiete mit höherem Verkehrsaufkommen werden in Mikrozellenmit einer Größe von bis zu einem Kilometer eingeteilt. In diesen Versorgungsgebietenkann eine Übertragungsdatenrate von bis zu 384 kBit/s bei einer maximalen Bewe-gungsgeschwindigkeit von 120 km/h erreicht werden. Gebiete mit sehr hohem Ver-kehrsaufkommen können schließlich in Pikozellen aufgeteilt werden, welche einenDurchmessen von bis zu 100 m haben. Beispiele für solche Gebiete sind Messegelände,Sportstadien oder auch Fußgängerzonen in größeren Städten. Die maximale Bewe-gungsgeschwindigkeit in einer solchen Zelle sollte 10 m/s nicht überschreiten, dafür

12


Frequenz

Code

Zeit

Frequenz

Code

Zeit

Frequenz

Code

Zeit

FDMA TDMA CDMA

Abbildung 3.3: Die Funkübertragungsverfahren FDMA, TDMA und CDMA

kann derzeit abhängig von der eingesetzten Technik eine Übertragungsdatenrate vonbis zu 384 kBit/s bis 2 MBit/s erreicht werden.

Die tatsächlich erreichbare Datenrate zwischen RNS und einem UE ist allerdings starkabhängig von dem Standort und der Bewegungsgeschwindigkeit des UE. Die Übertra-gungsparameter können in einem UMTS-Netz frei zwischen UE und RNC ausgehan-delt werden. Zu diesem Zweck überprüfen sowohl RNS, als auch UE ständig die Qua-lität der Funkverbindung und passen die Übertragungsparameter an. Der Protokoll-Stack in einem UTRAN ist nach dem ISO/OSI Referenz Modell [16] aufgebaut.

3.1.1 Physikalische Übertragung

Für die Funkübetragung im UTRAN wird eine Kombination aus Wide Code DivisionMultiple Access zur Trennung der einzelnen Nutzer und Frequency Division Multi-ple Access (FDMA) oder Time Division Multiple Access (TDMA) zur Trennung vonUp- und Downlink eingesetzt. Abbildung 3.3 zeigt die Funktionsweise dieser dreiZugriffsverfahren. FDMA partitioniert den verfügbaren Frequenzraum in einzelnenFrequenzbänder. Diese Frequenzbänder können von verschiedenen Nutzern gleich-zeitig genutzt werden. Jedes Frequenzband kann durchgehend für die Übertragunggenutzt werden, es steht allerdings nur ein Bruchteil der Bandbreite des gesamtenFrequenzraums zur Verfügung.

Wird dagegen TDMA für die Zugriffstrennung genutzt, so steht jedem Benutzer für dieÜbertragung die volle Bandbreite zur Verfügung, allerdings nur für einen definiertenZeitraum. Es werden Zeitschlitze (Slots) einer bestimmten Länge, zum Beispiel 10 ms,definiert, in denen nur einer der Teilnehmer senden darf. Über die Verteilung der Slots

13


TDD 1.900 MHz - 1.920 MHzFDD-Uplink 1.920 MHz - 1.980 MHzTDD 2.010 MHz - 2.025 MHzFDD-Downlink 2.110 MHz - 2.170 MHz

Tabelle 3.1: UMTS Frequenzbereiche

auf die einzelnen Teilnehmer kann deren maximale Übertragungsdatenrate oder dieLatenz der Verbindung beeinflußt werden.

Bei CDMA können alle Teilnehmer zeitgleich und auf der vollen Bandbreite senden.Die Trennung der einzelnen Verbindungen erfolgt anhand orthogonaler Spreizcodes(chipping sequences). Die einzelnen Bits dieser Bitsequenz werden als chips bezeichnet.Die zu übertragenen Daten werden vor dem Senden mit der chipping sequence derjeweiligen Verbindung multipliziert. Die Gegenseite korreliert alle empfangenen Si-gnale in dem genutzten Frequenzspektrum mit dieser chipping sequence und kann sodie gesendeten Daten der Verbindung herausfiltern. Ein großer Vorteil dieses Übertra-gungsverfahrens ist dessen Robustheit gegenüber Interferenzen. Die Gesamtbandbreitewird durch dieses Verfahren nicht erhöht, da für jedes Datenbit die komplette chippingsequence gesendet wird. Je mehr Verbindungen gleichzeitig aktiv sind, umso längermüssen die verwendeten chipping sequences sein. In einem UTRAN wird immer miteiner konstanten chip rate von 3,84 Millionen chips pro Sekunde (Mcps) gesendet, sodass die Übertragungsdatenrate von der Länge der chipping sequence abhängt.

Tabelle 3.1 listet die Frequenzbereiche für den Frequency Division Duplex-Modus(FDD), der Kombination aus WCDMA und FDMA, und den Time Division Duplex-Modus (TDD), der Kombination aus WCDMA und TDMA, auf. Die Frequenzbereichewerden in 5 MHz breite Frequenzstreifen unterteilt, welche jeweils exklusiv von einemUMTS-Netzbetreiber genutzt werden.

Bei dem Einsatz von TDMA zur Trennung von Up- und Downlink kann in einer Pi-kozelle eine Übertragungsdatenrate von bis zu 2 MBit/s erreicht werden. Die dafürnotwendig Technik ist allerdings komplexer und dementsprechend teuerer als dieje-nige für FDMA. In den meisten Gebieten mit UMTS-Versorgung wird daher derzeitFDMA eingesetzt. Gemeinsam ist beiden Verfahren, dass die Datenübertragung miteiner Rahmenlänge von 10 ms erfolgt. Jeder Rahmen ist wiederum in 15 Slots unter-teilt, in dem ein Transport Block (TB) übertragen werden kann. Die TBs werden nichtunabhängig voneinander übertragen, sondern in Transport Block Sets (TBS) zusam-mengefasst. Der zeitliche Abstand zwischen der Übertragung zweier TBS wird alsTransmit Time Interval (TTI) bezeichnet. Alle TB in einem TBS haben die gleiche Länge

14


und verwenden denselben Fehlerschutz. Jedem TBS wird ein Header vorangestellt, derunter anderem die Länge der einzelnen TB, die Länge des gesamten TBS und weitereInformationen wie den verwendeten Fehlerschutz enthält. Die Kommunikation mitder nächst höheren Medium Access Control Schicht erfolgt über Transportkanäle.

3.1.2 Medium Access Control

Die Medium Access Control (MAC) bildet die von der physikalischen Schicht bereit-gestellt Transportkanäle auf logische Kanäle ab. Während die Transportkanäle durchdie Art der Datenübertragung definiert sind, werden die logischen Kanäle durch dieArt der übertragenen Informationen definiert. Die MAC ist daher für das MultiplexenService Data Units (SDU) höherer Schichten auf die Protocol Data Units (PDU) derphysikalischen Übertragungsschicht zuständig. Die Transportformate der einzelnenTransportkanäle werden ebenfalls von der MAC bestimmt.

3.1.3 Radio Link Control

Die Radio Link Control (RLC) bildet zusammen mit der MAC die zweite Schicht (DataLink Layer) des ISO/OSI- Referenzmodells. RLC-Verbindungen können in drei unter-schiedlichen Modi arbeiten. Der Einfachste ist der Transparent Mode (Tr), in welchemdie Pakete einer höhren Schicht falls notwendig in mehrere PDUs segmentiert undbeim Empfang auf der Gegenseite wieder zusammengesetzt werden. Den einzelnenPDUs wird kein Header vorangestellt. Die Zusammengehörigkeit mehrere PDUs zueiner SDU der höheren Schicht ist dadurch definiert, dass nur eine SDU innerhalb einesTTI gesendet wird. Eine Fehlerkorrektur ist in diesem Modus nicht vorhanden. Fehlerinnerhalb einer PDU werden von der Schicht 1 erkannt, so dass fehlerhafte Paketewahlweise markiert oder verworfen werden können.

Im Unacknowledged Mode (UM) werden die einzelnen PDUs mit Sequenznummernversehen. Über diese Sequenznummern kann garantiert werden, dass die PDUs inkorrekter Reihenfolge wieder zu SDUs der höheren Schicht zusammengesetzt wer-den. Zusätzlich können Segmente unterschiedlicher Datenpakete auch zu einer PDUverkettet werden, so dass die verfügbare Bandbreite effektiver genutzt wird. Eine Feh-lerkorrektur bietet auch dieser Modus nicht.

Diese wird im Acknowleged Mode (AM) in Form eines Automatic Repeat Request(ARQ) Algorithmus hinzugefügt. Wie auch im UM werden den einzelnen PDUs Hea-der vorangestellt um Segmentierung von SDUs und insbesondere die Verkettung vonSegmenten zu einer PDU zu unterstützen. Anhand der Sequenznummer können vom

15


Abbildung 3.4: Logische Kanäle der UMTS RLC-Schicht [47]

Empfänger Paketverluste erkannt und die entsprechenden Pakete erneut angefordertwerden. Die Anzahl der Retransmits der einzelnen PDUs ist durch ein Timeout be-grenzt. Wird das Timeout für eine PDU erreicht, so wird die entsprechende SDU wahl-weise verworfen oder markiert. In Abbildung 3.4 ist der Datenfluss zwischen denService Access Points (SAP) der RLC-Schicht auf Sender- und Empfängerseite für diedrei Modi grafisch dargestellt.

16


3.1.4 Vermittlung

Die dritte Schicht in einem UTRAN wird Radio Resource Control (RRC) genannt. Überdiese Schicht fordern die Anwendungen Kommunikationskanäle einer bestimmtenDienstgüte an. Im UMTS Standard sind vier Dienstgüteklassen definiert:

1. Die Konversationsklasse für Echtzeitkommunikation wie die normale Telefonie,Voice over IP Anwendugen (VoIP) oder auch Videotelefonie. Von besondererBedeutung für Anwendungen dieser Klasse ist eine geringe und konstante Über-tragungsverzögerung.

2. Die Streaming-Klasse für Echzeit-Multimedia-Dienste. Ein Beispiel für eine An-wendung dieser Klasse ist das Live-Streaming eines aufgezeichneten Videos. DieÜbertragungsverzögerung ist hierbei nicht von großer Bedeutung und Schwan-kungen können durch entsprechend große Puffer ausgeglichen werden.

3. Die Klasse der interaktiven Anwendungen, wie zum Beispiel das Surfen imInternet. Im Gegensatz zu den beiden vorherigen Klassen ist für diese Anwen-dungen eine möglichst niedriege Bitfehlerrate von hoher Bedeutung.

4. Die Hintergundklasse für das nicht-interaktive Übertragen von Daten wie Emailoder SMS.

Weitere Aufgaben der RRC sind unter anderem die Zellwahl im Idle-Modus, das Han-dover oder das Erstellen von Messwertberichten, welche die RRC der Gegenseite an-fordern kann.

17

4 VIDEOKOMPRIMIERUNG NACH DEM

MPEG-STANDARD

Das Ziel der Videokomprimierung ist es, die Größe des Videostreams stark zu redu-zieren, die sichtbare Bildqualität aber möglichst beizubehalten. Die Moving PictureExpert Group (MPEG) ist eine gemeinsame Arbeitsgruppe der ISO mit der Internatio-nal Electrotechnical Commission (IEC). Sie wurde 1988 gegründet und hat seither dreiStandards für die Videokomprimierung erarbeitet. Da es sich bei diesen drei Standardsvon MPEG-1 über MPEG-2 hin zu MPEG-4 um eine evolutionäre Weiterentwicklunghandelt, bauen alle drei Standards auf den gleichen Grundkonzepten auf.

4.1 Verlustbehaftete Komprimierung

Bei der Komprimierung eines Videostreams nach einem der MPEG-Standards werdenfolgende Techniken kombiniert:

• Farbreduktion bei der Konvertierung in den YUV-Farbraum,

• Diskrete Kosinustransformation mit anschließender Quantisierung,

• Huffman-Kodierung der quantisierten Daten und

• Interframe-Komprimierung mit Motion Compensation.

Der erste Schritt bei der Komprimierung ist die Konvertierung des Ausgangsbildma-terials in den YUV-Farbraum. In diesem Farbraum wird jeder Bildpunkt durch eineLuminanzkomponente (Y) und zwei Chrominanzkomponenten (U und V) dargestellt.Diese Konvertierung ist aus dem RGB-Farbraum verlustlos. Da das menschliche Augewesentlich empfindlicher auf Helligkeitsunterschiede reagiert, als auf Farbunterschie-de, werden nur für die Hälfte oder ein Viertel der Bildpunkte die Chrominanzkompo-nenten gespeichert.

Für die weitere Bearbeitung werden die einzelnen Bilder in 8x8 Bildpunkte große Blö-cke unterteilt. Mittels der diskreten Kosinustransformation werden diese Blöcke in den

19

4 Videokomprimierung nach dem MPEG-Standard

Abbildung 4.1: Beziehung zwischen I-, P- und B-Frames

Frequenzraum überführt. In der Ergebnismatrix werden allerdings nicht die absolu-ten Werte, sondern jeweils die Differenz zum vorhergehenden Wert gespeichert. DieseTransformation ist bei ausreichender Rechengenauigkeit verlustlos, allerdings enthältdie so gewonnene Matrix in den meisten Fällen viele Einträge mit kleinen Werten, sodass sie sich besonders gut mittels der Huffman-Kodierung komprimieren läßt. DieMatrix wird anschließend mit einer Quantisierungsmatrix multipliziert. Vor der Multi-plikation wird die Quantisierungsmatrix zunächst mit einem häufig mquant genanntenFaktor skalar multipliziert. Der Wert von mquant entspricht der Stärke der Quantisie-rung. Durch diese Quantisierung wird die Anzahl gleicher Werte in der 8x8 Matrixerhöht. Schließlich werden die Blöcke mittels der Huffmankodierung komprimiert.Ein nach diesem Verfahren komprimiertes Bild wird intra coded picture, kurz I-Frame,genannt.

Neben den I-Frames werden bei der Interframe Komprimierung noch zwei weitereFrametypen verwendet. Diese sind die predictive coded pictures, genannt P-Frame, unddie bidirectional coded pictures, genannt B-Frame. Bei der Kodierung dieser Frames wirdzusätzlich noch eine Block Motion Compensation (BMC) durchgeführt. Während so-wohl bei MPEG-1, als auch bei MPEG-2 eine feste Blockgröße von 16x16 Bildpunktenverwendet wird, sieht der MPEG-4-Standard zusätzlich die Möglichkeit von 8x8 und4x4 Blöcken vor. Dabei wird für P-Frames der letzte vorhergehende I- oder P-Frame alsReferenz verwendet. Bei B-Frames werden der letzte vorhergehende und der nächstenachfolgende I- oder P-Frame als Referenzen genutzt. P-Frames und B-Frames sind da-her wesentlich kleiner, wobei B-Frames noch kleiner als P-Frames sind. Abbildung 4.1stellt die Referenzierung zwischen den Frametypen graphisch dar.

Die Framefolge eines I-Frame bis zum nächsten wird als Group of Pictures (GOP)bezeichnet. Die Reihenfolge der Frames in der Abbildung entspricht der Abspielrei-

20

4.2 Rate Control

henfolge. Im ausgegebenen Elementary Stream (ES) des Encoders sind diese umsortiert.P-Frames und B-Frames werden erst nach denen von ihnen referenzierten I-Framesund P-Frames in den ES geschrieben. Encoder brauchen deshalb auch einen VideoBuffering Verifier (VBV) Puffer, um die Frames korrekt sortieren zu können.

4.2 Rate Control

Für viele Anwendungen, wie zum Beispiel die Videowiedergabe von Digital VersatileDiscs (DVD), wird eine konstante Streambitrate (CBR) benötigt. Zu diesem Zweckenthalten Encoder eine sogenannte Rate Control, welche den Kodiervorgang steuert. DieFunktionsweise einer solchen Rate Control wird durch die Standards nicht vorgegeben.Parallel zu der Entwicklung des eigentlichen MPEG-2 Standards wurde allerdingsein Test Model genanntes Dokument veröffentlicht, welches unter anderem auch dieBeschreibung einer Rate Control enthält. Abbildung 4.2 zeigt den Aufbau der in derfünften Version des Dokuments [15] beschriebenen Rate Control.

Der Rate Control Komponente werden von außen die Zielbitrate, sowie die Größedes VBV-Puffers und dessen initialer Füllstand übergeben. Anhand der vorgegebenenBitrate wird zunächst die geeignete Bitgröße einer kompletten GOP berechnet. Diesewird wiederum in Zielbitgrößen für die einzelnen Frametypen aufgeteilt. Der eigentli-che Rate Control Algorithmus verwendet diese Werte, sowie den virtuellen Füllstanddes VBV-Puffers und eine Komplexitätsschätzung des zu kodierenden Bildes, um einengeeigneten Wert für mquant zu berechnen. Dieser Wert wird dann als Richtwert für dieQuantisierung der Macroblocks verwendet. Die tatsächliche Bitgröße des kodiertenBildes wird anschließend dem virtuellen Puffer übergeben.

21

4 Videokomprimierung nach dem MPEG-Standard

Abbildung 4.2: Aufbau eines TM5 Rate Controllers

22

5 MODELL UND ALGORITHMEN

In diesem Kapitel wird zunächst ein Modell für das gesamte adaptive Unicast Live-Streaming System entwickelt. Anhand dieses Modells wird das Problem der Übertra-gung von Live-Streams genau beschrieben. Es werden dabei Bezeichner für Parameterund Variablen eingeführt, die auch in den Folgeabschnitten weiter genutzt werden. Imzweiten Abschnitt werden die untersuchten Algorithmen beschrieben.

5.1 Modell des Unicast Live-Streamings über einenUMTS-Link

Für die später in Kapitel 5.3.1 beschriebene Simulationsumgebung soll an dieser Stelledas zugrunde liegende Modell beschrieben werden. Anhand dieses Modells lassensich für die Implementierung und Analyse der Versuchsergebnisse wichtige Aussagenmachen. In den ersten Abschnitten werden daher wichtige Parameter von Server, Netz-werk und Client definiert. Für die einzelnen Felder der RTP- und RTCP-Pakete werdenebenfalls Bezeichner eingeführt. Anschließend werden Eigenschaften des Gesamtsys-tems auf Basis dieses Modells beschrieben.

5.1.1 Server

Der Server besteht aus einem Encoder, der das Videobild in Echtzeit kodiert, einemZwischenpuffer und einer Sendeeinheit, die diesen Bitstrom zum Client überträgt. DerEncoder arbeitet im CBR-Modus. Ihm wird vor der Kodierung jedes Einzelbildes dieEncoderbitrate Se ≤ Semax übergeben. Da es keine Sinn macht, einen Stream mit einerDatenrate größer der Linkbandbreite zu erzeugen, soll Semax = α · Lt, α ≤ 1 gelten,mit der aktuellen Linkbandbreite Lt. Daraufhin erzeugt der Encoder einen Bitstrommit der Bitrate Sst und einer Framerate S f ps, der in den Zwischenpuffer mit der GrößeSbmax geschrieben wird. Der Füllstand dieses Zwischenpuffers wird im folgenden mit Sb

bezeichnet. Aus dem Zwischenpuffer wird der Bitstrom von der Sendeeinheit mit derBitrate St ausgelesen und an den Client gesendet. Je nach verwendetem Rate Control

23

5 Modell und Algorithmen

Semax aktuelle maximale Encoderbitrate (Bit/s)Se aktuelle Encoderbitrate (Bit/s)Sst aktuelle Streambitrate (Bit/s)S f ps aktuelle Streambildrate (Bit/s)Sbmax Puffergröße (Byte)Sb aktueller Pufferfüllstand (Byte)St aktuelle Senderate (Bit/s)Stmax von der Rate Control berechnete maximale Senderate (Bit/s)

Tabelle 5.1: Servervariablen und -konstanten

Algorithmus, berechnet dieser eine maximale Sendebitrate Stmax . In Abbildung 5.1 sindder Datenfluss und Signalisierungen innerhalb des Server noch einmal schematischdargestellt.

5.1.2 Netzwerk

Die Live-Streams sollen der Aufgabenstellung zu Folge über einen UMTS Datenkanalübertragen werden. Nimmt man an, dass der Server sich innerhalb des UMTS Kern-netzes befindet, was hier der Fall sein soll, so wird der Übertragungsweg in zwei Teilegetrennt, zum einen die Übertragung vom Server innerhalb des Kernnetzes bis zumRNS, und zum anderen der anschließenden Funkstrecke bis zum Endgerät. Es wirddavon ausgegangen, dass im Kernnetz keine Überlast auftritt und die Verzögerung Lcn

konstant und vernachlässigbar niedrig ist.

Für die Übertragung verwende der RLC den Acknowleged Mode mit einem sehr hohenTimeout, so dass Paketverluste durch Timeouts bei der Übertragung praktisch nichtauftreten. Für die Übertragung können das Transmit Time Intervall Ltti in Sekunden,

Abbildung 5.1: Schematische Darstellung des Servers

24

5.1 Modell des Unicast Live-Streamings über einen UMTS-Link

Ltti Transmit Time Interval (ms)Lpdu Größe der Protokoll Data Unit (Bit)Lpt Anzahl der PDUs pro TTILt Linkbandbreite (Bit/s)Lbler Block Error RateLto Timout für Retransmit-VersucheLrtt Round Trip Time des UTRAN (ms)Lbmax Puffergröße (Byte)Lb aktueller Pufferfüllstand (Byte)

Tabelle 5.2: Linkvariablen und -konstanten

die Größe der PDU Lpdu in Bit sowie die Anzahl der PDUs Lpt pro TTI eingestellt wer-den. Aus diesen Parametern ergibt sich die Linkbandbreite Lt in kBit/s nach Gleichung5.1.

Lt = Lpdu · Lpt ·1

Ltti. (5.1)

Eine weitere wichtige Größe ist die Block Error Rate (BLER) Lbler, die den Anteil fehler-haft übertragener PDUs beschreibt. Die fehlerhaften PDUs werden im AcknowlegedMode erneut übertragen, so dass für Lbler > 0, die effektive Datenrate der Funkstreckeauf etwa Lt · (1 − Lbler) sinkt und der Jitter in der Übertragungsverzögerung starkansteigt. Schließlich ist noch die Round Trip Time (RTT) Lrtt von Bedeutung.

5.1.3 Client

Der Client modelliert das Endgerät, auf dem der Live-Stream empfangen und abge-spielt wird. Er empfängt den Bitstrom mit einer Bitrate von Cr und schreibt diesen ineinen Zwischenpuffer. Der Zwischenpuffer wird auch im Client durch die beiden Para-meter Puffergröße Cbmax und den aktuellen Füllstand Cb charakterisiert. Zu Beginn derÜbertragung wird dieser für Cpb Sekunden gefüllt (Prebuffering), bevor der Decodergestartet wird. Aus dem Puffer liest der Decoder die Daten mit der Bitrate Cd aus undspielt den Videostream mit einer Bildrate von C f ps ab.

25


Cr aktuelle Empfangsbitrate (Bit/s)C f ps aktuelle Abspielbildrate (Hz)Cbmax Puffergröße (Byte)Cb aktueller Pufferfüllstand (Byte)Cpb Prebufferingzeit (s)

Tabelle 5.3: Clientvariablen und -konstanten

5.1.4 Übertragungsprotokoll

Für die Datenübertragung über den Link soll das RTP-Protokoll [37] eingesetzt werden.Jedes vom Server zum Client verschickte Datenpaket P besitzt daher eine aufsteigendeSequenznummer Psn. Neben den Datenpaketen sendet der Server zusätzlich in einemdefinierten Intervall RTCP-Pakete mit Sender Reports (SR), in denen ein Network TimeProtocol-Timestamp SRntp (NTP) enthalten ist. Der Client verschickt in einem festenIntervall und auf bestimmte Ereignisse hin Pakete nach dem RTP Control Protocol(RTCP) mit einem Receiver Report (RR). Dieser enthält die höchste vom Client emp-fangene Paketsequenznummer RRhrsn und die Anzahl der seit dem letzten RTCP RRverloren gegangenen RTP-Pakete RRpl . Außerdem sind noch der Zeitpunkt RRlsr, zudem der letzte RTCP SR empfangen wurde, und die Differenz RRdlsr zwischen RRlsr

und dem Zeitpunkt, zu dem der RTCP RR versendet wurde, enthalten.

Der RTP-Standard sieht noch weitere Felder in den RTP- und RTCP-Paketen vor. Dadiese aber in den in Abschnitt 5.2 beschriebenen Algorithmen nicht verwendet werden,sind sie hier nicht mit aufgeführt.

Mit den Informationen in den Feldern RRlsr und RRdlsr ist es dem Server möglich, dieaktuelle Round Trip Time auf der Netzwerkverbindung zum Client zu berechnen [37].Die Round Trip Time RTT ergibt sich nach Gleichung 5.2, wobei ta die Ankunftszeit-punkt des Receiver Reports bezeichnet. Um eine aktuelle Round Trip Time berechnen

Psn Sequenznummer des RTP-PaketsSRntp aktueller NTP-TimestampRRhrsn höchste empfangene SequenznummerRRps Anzahl der seit dem letzten Receiver Report verlorenen RTP-PaketeRRlsr Empfangszeitpunkt des letzten Sender ReportsRRdlsr Differenz zwischen RRlsr und Senden des Receiver Reports

Tabelle 5.4: Mit dem Übertragungsprotokoll gesendete Informationen

26


zu können ist es daher wichtig, dass der Server in regelmäßigen Abständen SenderReports an den Client schickt.

RTT = ta − RRlsr − RRdlsr. (5.2)

5.1.5 Linkbandbreite und Client-Empfangsdatenrate

Die aktuelle Linkbandbreite Lt stellt eine feste Obergrenze für die maximale Übertra-gungsrate über den Link dar. Dennoch kann es aus Sicht des Clients vorkommen, dassdie Empfangsdatenrate Cr scheinbar größer als die Linkbandbreite ist. Dieser Effektkann auftreten, wenn Lbler > 0 gilt. In diesem Fall kann es vorkommen, dass einzelnePDUs fehlerhaft übertragen werden und eine erneute Übertragung notwendig ist. Auf-grund der relativ hohen Round Trip Time einer UMTS Funkverbindung dauert es einegewisse Zeit bis die fehlerhaften PDUs erneut übertragen wurden. In diesem Zeitraumwird die Übertragung weitere Pakete allerdings nicht unterbrochen, so dass der Emp-fangspuffer des Clients sich weiter füllt. Da der Acknowleged Mode die Beibehaltungder Paketreihenfolge garantiert, werden diese Daten aber noch nicht an die Anwen-dung weitergeleitet. Ist eine fehlerhafte PDU schließlich korrekt übertragen worden,so werden die Daten zeitgleich an die Anwendung weitergeleitet.

5.1.6 Buffer Overflows

Sowohl der Server, als auch Link und Client enthalten beschränkte Puffer der Grö-ße Bmax. In diese wird jeweils mit einer Bitrate Bin geschrieben, und aus ihnen wird miteiner Bitrate Bout gelesen. Eingangs- und Ausgangsbitrate sind in allen drei Fällen un-abhängig voneinander. Daher kann es zu Buffer Overflows kommen, falls Bin > Bout

für einen ausreichend langen Zeitraum gilt. Da Server, Link und Client bei BufferOverflows die entsprechenden Pakete verwerfen, bedeutet jeder Buffer Overflow Da-tenverlust und somit Bildfehler bei der Anzeige des Live-Streams auf dem Client.

Der Encoder schreibt mit der Datenrate Sst in den Puffer des Servers und die Sendeein-heit liest diesen mit der Datenrate St aus. Dementsprechend kann eine Buffer Overflowdurch eine entsprechende Steuerung der Encoderbitrate Se verhindert werden. Für dieVermeidung von Buffer Overflows im Netzwerk ist die Rate Control im Server zustän-dig, welche die Senderate St des Servers an die effektive Bandbreite des Links anpasst.Für den Clientpuffer läßt sich dagegen, wie im folgenden Abschnitt gezeigt wird, eineMindestgröße angeben, bei der Buffer Overflows nicht auftreten.

27


Minimale Clientpuffergröße

Sei Bl0 der initiale Füllstand des Clientpuffers in Bits zu einem Zeitpunkt t0, Sr diedurchschnittliche Bitrate des sich im Puffer befindlichen Streams und Sw die Bitratedes eingehenden Streams. Der Client liest den Stream aus dem Puffer genau mit derStreambitrate Sr aus. Der Pufferfüllstand steigt genau dann, wenn Sw > Sr gilt. Füreine konstant eingehende Streambitrate Sw lässt sich nach Gleichung 5.3 und vomZeitpunkt t0 ausgehend eine obere Grenze Blmax für den Pufferfüllstand berechnen.Blmax wird nie überschritten, da nur für Bl0 · S−1

r Sekunden Sw > Sr gilt.

Blmax ≤Bl0Sr· Sw. (5.3)

Die eingehende Streambitrate Sw ist in der untersuchten Umgebung nach oben durchdie maximale Linkbitrate Lt begrenzt. Ebenso ist die Streambitrate des MPEG-2 Streamsfür eine gegebene Auflösung nach unten durch einen Wert Sstmin beschränkt. Daher lässtsich der maximal mögliche Clientpufferfüllstand durch die Gleichung 5.4 nach obenabschätzen.

Blmax =Bl0

Sstmin

· St. (5.4)

Blmax hängt daher nur noch von dem initialen Pufferfüllstand Bl0 ab. Da Ssmin die durch-schnittliche Bitrate von Bl0 ist, gilt 5.5, wobei Bt den maximalen Zeitraum darstellt, indem nicht aus dem Puffer gelesen wird. Bt enspricht also dem Pufferungszeitraum imClient zu Beginn einer Übertragung. Aufgrund des in Abschnitt 5.1.5 beschriebenenEffekts kann diese obere Grenze dennoch kurzzeitg überschritten werden, so dass beider Übertragung über einen Link mit Automatic Repeat Request (ARQ) Fehlerkorrek-tur und Beibehaltung der Paketreihenfolge, noch die Linkpuffergröße Lbmax addiertwerden muss. Somit ergibt sich als obere Abschätzung für den Pufferfüllstand undsomit untere Grenze für die Clientpuffergröße Cbmin die Gleichung 5.6.

Bl0 = Bt · Ssmin . (5.5)

Cbmin ≥ Bt · Slmax + Lbmax . (5.6)

28


5.1.7 Buffer Underruns

Ebenso wie die Puffer in Server, Link und Client überlaufen können, können diese auchleerlaufen. Dies ist der Fall, wenn für einen ausreichend langen Zeitraum Bin < Bout

gilt. Sowohl im Server, als auch im Link stellen solche Buffer Underruns kein Problemdar, da diese weder eine Verzögerung noch einen Datenverlust verursachen. Im Clientdagegen sind Buffer Underruns bei der Ausgabe des Videosignals direkt sichtbar undzwar in Form einer ruckelnden Wiedergabe.

Ohne Buffer Underruns gibt der Client den Videostream mit derjenigen Framerate aus,mit der er kodiert wurde (C f ps = S f ps). Für die Ausgabe zweier zu den Zeitpunkten t1

und t2 aufeinander folgender Bilder des Videosignals gilt also t2 = t1 + 1S f ps

. Im Falleeines Buffer Underruns stehen aber zum Zeitpunkt t2 noch nicht alle Daten zur Verfü-gung, um das Bild zu dekodieren. Diese Daten erreichen erst mit einer Verzögerung∆t Sekunden den Client, so dass das Bild frühestens zum Zeitpunkt t3 = t2 + ∆tausgegeben werden kann. Dementsprechend sinkt die aktuelle Framerate auf den nachGleichung 5.7 berechnete Wert.

C f ps =S−1

f ps

∆t + S−1f ps

· S f ps. (5.7)

29


5.2 Algorithmen zur Steuerung des Encoders, der Übertragungund der Wiedergabe

Für die Untersuchungen wurden drei unterschiedliche Rate Control Algorithmen aus-gewählt und implementiert. Als Vertreter der Klasse der ARQ-Algorithmen wurde eineinfacher Retransmit-Algorithmus entwickelt. Es wurde angenommen, dass ein solcherAlgorithmus verlorene Pakete rechtzeitig erneut an den Client senden kann, so dassaus Sicht des Clients kein Paketverlust auftritt. Als zweiter Algorithmus wurde die inRFC 3448 [13] beschriebene gleichungsbasierte TCP Friendly Rate Control (TFRC) aus-gewählt. Bei der TFRC handelt es sich um eine Adaption der TCP Rate Control für dieÜbertragung von Multimediadaten. TFRC ist eines der am häufigsten eingesetzen RateControl Verfahren für die Übertragung von Multimediadaten über verschidenste IP-Netze. Es wurde bereits der Einsatz des TFRC-Algorithmus für Multimediastreamingüber das Internet [23], Wireless LAN Verbindungen [33] und auch UMTS-Datenkanäle[2] untersucht. Schließlich wurde noch ein speziell für das Streaming in Mobilfunknet-zen der dritten Generation entwickelter Algorithmus ausgewählt, die RTCP Feedbackbased Transmission Rate Control (RF-TRC).

Da die drei Rate Control Verfahren sehr unterschiedlich arbeiten, wurde für jeden Al-gorithmus eine eigene Methode zur Steuerung des Encoders entwickelt. Diese werdenim Folgenden als Teil des Rate Control Algorithmus betrachtet. Daraus ergibt sich bei-spielsweise, dass die Kombination aus dem eigentlichen TFRC-Algorithmus und derEncodersteuerung gemeint ist, wenn die Rede vom TFRC-Algorithmus ist.

5.2.1 Einfacher Retransmit Algorithmus

Der Retransmit Algorithmus berechnet nach erkannten Paketverlusten eine neue ma-ximale Senderate Stmax und sendet wenn möglich die verlorenen Pakete erneut. DerAlgorithmus zur Berechnung von Stmax nach Ankunft eines RTCP Receiver Reportsvom Client ist in Algorithmus 1 dargestellt. Dieser Algorithmus berechnet ebenfallsdie Encoderbitrate Se nach Gleichung 5.8 als gleitenden Durchschnitt der maximalenSenderaten. Falls der Client einen Paketverlust meldet, so werden die entsprechendenPakete in die Menge der verlorenen Pakete LP eingefügt, sofern sie noch im Pufferbereits gesendeter Pakete SP des Servers sind. Die Parameter α und β geben an, wieschnell die maximale Senderate gändert werden soll und γ ist ein Dämpfungsfaktorfür die Aktualisierung der Encoderbitrate.

Se = γ · Se + (1− γ) · Stmax . (5.8)

30

5.2 Algorithmen zur Steuerung des Encoders, der Übertragung und der Wiedergabe

Algorithmus 1 Retransmit: Smax nach Empfang eines Receiver Reports RR1: if (RRpl > 0) then2: for all i mit 0 ≤ i < RRpl do3: sni ← RRhrsn − 1 + i4: LP← LP ∪ {sni}5: end for6: Stmax ← α · Stmax

7: else8: Stmax ← β · Stmax

9: end if10: if (Stmax > Su) then11: Stmax ← Su

12: end if13: if (Stmax < Sl) then14: Stmax ← Sl

15: end if

Der Client überprüft bei jedem empfangenen RTP Paket, ob es zu einem Paketverlustgekommen ist und sendet in diesem Fall ein RTCP Receiver Report an den Sender(siehe Algorithmus 2). Falls ausreichend freier Platz im Clientpuffer ist und das Paketrechtzeitig angekommen ist, so wird es an passender Stelle eingefügt.

Algorithmus 2 Retransmit: Empfang eines RTP Pakets auf clientseite1: if ((Cb + Psize ≤ Cbmax) ∧ (sni > snbh)) then2: insert P into client buffer3: hrsn← sni

4: if (sni 6= sni−1 + 1) then5: pl ← sni − sni−1 − 16: send RTCP Packet7: end if8: end if

5.2.2 TCP Friendly Rate Control

Die TCP Friendly Rate Control (TFRC) [13] ist eine gleichungsbasierte Rate Control,welche die TCP-Durchsatzgleichung 5.9 verwendet. Die einzelnen Parameter sind inTabelle 5.2.2 aufgelistet und beschrieben. In der RFC wird empfohlen b = 1 und trto =4 · R zu verwenden. Bei der Verwendung von RTP als Übertragungsprotokoll kann der

31


X Übertragungsrate (Bit/s)s Paketgröße (Byte)R berechnete Round Trip Time (s)p Loss Event Ratetrto TCP-Übertragungstimeout (s)b Anzahl der Pakete die von einem Acknowlege-Paket bestätigt werden

Tabelle 5.5: Parameter der TCP Durchsatzgleichung

Wert für rtt wie in Abschnitt 5.1.4 beschrieben berechnet werden. Als Paketgröße pwird in der Regel einfach der Mittelwert der versendeten Pakete genommen.

X =s

R ·√

2 · b · p3 + (trto · (3 ·

√3 · b · p

8 · p · (1 + 32 · p2))). (5.9)

Schließlich muss die Loss Event Rate p von dem Client nach Algorithmus 5.2.2 be-rechnet und dem Server übermittelt werden. Für diese Berechnung werden die letztenn Loss Intervals I1 bis In benötigt, die den Zeitraum zwischen dem Auftreten zweierLoss Events darstellen. Um festzustellen, ob ein erkannter Paketverlust noch zu demaktuellen Loss Event gehört, oder ein neues Loss Event starten soll, wird die erwarteteAnkunftszeit Tloss des verlorenen Pakets nach Gleichung 5.10 berechnet. Die Werte Sloss,Sbe f ore und Sa f ter sind die Sequenznummern des verlorenen Pakets, sowie des letztenvor und des ersten nach diesem empfangenen Pakets. Tbe f ore und Ta f ter bezeichnen dieentsprechenden Empfangszeitpunkte der Pakete. Ein neues Loss Event wird gestartet,falls gilt Told + R < Tloss mit Told als Empfangszeitpunkt des Pakets, das den letztenLoss Event gestartet hat. Bei jedem Start eines neuen Loss Events wird Tloss− Told vornein die Liste der Loss Intervals eingefügt.

Tloss = Tbe f ore + (Ta f ter − Tbe f ore ·Sloss − Sbe f ore

Sa f ter − Sbe f ore). (5.10)

5.2.3 RTCP Feedback based Transmission Rate Control

Die RTCP Feedback based Transmission Rate Control (RF-TRC)[3] ist eine spezielle für3G Mobilfunknetze entwickelte Rate Control. Sie ist darauf ausgelegt Buffer Overflowssowohl im Netzwerk, als auch im Client vollständig zu verhindern. Um dies zu errei-chen werden Netzwerk- und Clientpuffergröße, sowie die OBSN-Extension für RTCP

32


Algorithmus 3 TFRC: Berechnung der n Loss Event Gewichte1: for i = 0 to n− 1 do2: if (i < n

2 ) then3: wi ← 14: else5: wi ← 1− (i−( n

2−1))n2 +1

6: end if7: end for

benötigt. Die OBSN-Extension ergänzt RTCP Receiver Reports unter anderm um diebeiden Felder Oldest Buffer Sequence Number (OBSN) und Playout Delay (PD). DieGrundidee dieses Algorithmuses ist es, anhand der zur Verfügung stehenden Infor-mationen den Pufferfüllstand von Netzwerk und Client abzuschätzen. Datenpaketewerden nur gesendet, wenn ausreichend Platz in beiden Puffern vorhanden ist.

Es wird angenommen, dass die a-priori Informationen über Netzwerk- und Client-puffergröße entweder allgemein bekannt sind oder zu Beginn einer Übertragung überein geeignetes Protokoll dem Server mitgeteilt werden. Weiterhin speichere der Ser-ver die Sequenznummer htsn des zuletzt versandten RTP-Pakets. Für alle gesendetenund noch relevanten RTP-Pakete wird die Paketgröße Psnsize ebenfalls gesichert. DerNetzwerkpuffer-Füllstand Lb lässt sich somit nach Gleichung 5.11 berechnen.

Algorithmus 4 TFRC: Berechnung der Loss Event Rate p im Client1: Itot0 ← 02: Itot1 ← 03: Wtot ← 04: for i = 0 to n− 1 do5: Itot0 ← Itot0 + Ii · wi

6: Wtot ←Wtot + wi

7: end for8: for i = 1 to n do9: Itot1 ← Itot1 + Ii · wi−1

10: end for11: Itot ← max(Itot0 , Itot1)12: Imean ← Itot

Wtot

13: p← 1Imean

33


Algorithmus 5 TFRC: Berechnung von X nach Erhalt eines RTCP RR1: if (first RTCP Packet) then2: R← rtt3: else4: R← α · R + (1− α) · rtt5: end if6: trto ← 4 · R7: if (p > 0) then8: Xcalc ← s

R·√

2·b· p3 +(trto ·(3·

√3·b· p

8 ·p·(1+32·p2)))

9: X ← max(min(Xcalc, 2 · Xrecv), stmbi

)10: else11: if (tnow − tld ≥ R) then12: X ← max(min(2 · x, 2 · Xrecv), s

tmbi)

13: tld← tnow

14: end if15: end if

Lb =htsn

∑i=hrsn

Psnsize . (5.11)

Um den Clientpuffer-Füllstand abzuschätzen, wird zunächst über die Gleichung 5.12die aktuelle Playout Verzögerung to f f des Clients berechnet. tRR bezeichnet den Ti-mestamp des letzten empfangenen Receiver Reports und tOBSN den Timestamp desPakets mit der Oldest Buffer Sequence Number. Anhand der Gleichung 5.13 wird fürjedes Paket mit der Sequenznummer i der erwartete Abspielzeitpunkt T̄i berechnet.Nach Gleichung 5.14 kann für jeden Zeitpunkt t > tRR die zuletzt abgespielte Sequenz-nummer (LPSN) im Client berechnet werden. Der Clientpufferfüllstand Cb wird nunähnlich dem Netzwerkpufferfüllstand Lb nach Gleichung 5.15 berechnet. Bei dieserBerechnung wird die Highest Transmitted Sequence Number (HTSN) anstelle der zuerwartenden Highest Received Sequence Number ( HRSN) verwendet. So wird auchfür den Fall, dass alle im Netzwerkpuffer enthaltene Pakete gleichzeitig an den Clientübertragen werden, ein Buffer Overflow verhindert.

to f f = tRR + PD− tOBSN . (5.12)

T̄i = Ti + to f f . (5.13)

34


lpsn = max{i|T̄i < t}. (5.14)

Lb =htsn

∑i=lpsn

Pisize . (5.15)

Die Encoderbitrate Se wurde sowohl bei dem Retransmit-, als auch bei dem TFRC-Algorithmus als gleitender Durchschnitt der berechneten maximalen SendebitratenStmax ermittelt. Wird der RF-TRC-Algorithmus eingesetzt, so ist diese Berechnung nichtmehr möglich, da der Wert Stmax nicht ermittelt wird. Dieses Problem wird mittels derneu entwickelten Gleichung 5.16 gelöst. Für die Parameter muss gelten 0 ≤ α, β, γ < 1,α + β + γ = 1 und k ungrade.

Se2 = α · Se1 + β · Stavg + γ · Se1 · (1 + (−2 · ( Sb

Sbmax

− 0.5)k)). (5.16)

Für die Berechnung der neuen Encoderbitrate werden drei Faktoren herangezogen.Diese sind die vorherige Encoderbitrate Se1 , die durchschnittliche Sendebitrate Stavg

und der Serverpufferfüllstand Sb. Die durchschnittliche Sendebitrate wird verwendet,da diese von der Linkbandbreite Lt nach oben begrenzt ist. Sinkt die Linkbandbreite,so sinkt auch die durchschnittliche Sendebitrate. Stavg ist allerdings ebenfalls durchdie Streambitrate Sst nach oben begrenzt. Es gilt also Stavg ≤ min(Sst, Lt). Eine Berech-nung von Se allein auf Basis von Stavg würde demnach die Streambitrate bei sinkenderLinkbandbreite ebenfalls senken. Steigt die Linkbandbreite allerdings wieder, so bleibtStavg durch die aktuelle Streambitrate Sst weiterhin beschränkt. Um die Encoderbitratedennoch wieder anzuheben, wenn die Linkbandbreite steigt, wird der Serverpuffer-füllstand in die Berechnung mit einbezogen. Es wird angenommen, dass die Enco-derbitrate angehoben werden kann, falls der Puffer weniger als die Hälfte gefüllt ist.Dies geschieht im dritten Teil der Gleichung. Ist der Puffer über die Hälfte gefüllt, soberechnet auch dieser Teil eine Senkung der Encoderbitrate, um Buffer Overflows zuverhindern.

5.2.4 Adaptive Abspielbildrate

In [40] und [21] wird die Idee einer adaptiven Abspielbildrate auf Seite des Clientszur Vermeidung von Buffer Underflows untersucht. Entsprechend dieser Idee werdenin der Simulationsumgebung auch zwei unterschiedliche Algorithmen für eine solcheadaptive Abspielbildrate genutzt.

35


Der erste Algorithmus steuert die Abspielbildrate über den aktuellen Clientpufferfüll-stand Cb und die Linkbandbreite Lt. Zunächst wird der optimale Füllstand Cbopt anhandder Prebufferingzeit und der maximalen Encoderbitrate berechnet. Auf Basis diesesoptimalen Werts werden anschließend eine obere Grenze Cbmax und eine untere GrenzeCbmin für den Pufferfüllstand festgelegt. Wenn nun der aktuelle Pufferfüllstand Cbmin un-terschreitet und die aktuelle Abspielbildrate C f ps noch nicht einen vorgegebenen Mini-malwert C f psmin unterschritten hat, wird die Abspielbildrate gesenkt. Analog dazu wirdbeim Überschreiten einer Füllstandsobergrenze Cbmax die Abspielbildrate erhöht, fallssie ein vorgegebenes Maximum C f psmax noch nicht erreicht hat. Gilt Cbmin ≤ Cb ≤ Cbmax ,so wird die Abspielbildrate auf den genauen Wert der Streambildrate S f ps gesetzt. Überdie Parameter α und β werden die untere bzw. obere Füllstandsgrenze festgelegt, abdenen der Algorithmus die Abspielbildrate ändert. Die Parameter γ und δ legen fest,wie schnell die Abspielbildrate gesenkt bzw. erhöht wird.

Algorithmus 6 Erster Algorithmus zur Berechnung von C f ps

1: Cbopt ← Cpb · Semax

2: Cbmin ← α · Cbopt

3: Cbmax ← β · Cbopt

4: if (Cb < Cbmin ) then5: if (C f ps > C f psmin ) then6: C f ps ← (γ · C f ps)7: end if8: else9: if (Cb > Cbmax ) then

10: if (C f ps < C f psmax ) then11: C f ps ← (δ · C f ps)12: end if13: else14: C f ps ← S f ps

15: end if16: end if

36


Während es sich bei Algorithmus 6 um einen Multiplicative Increase / MultiplicativeDecrease (MIMD) Algorithmus handelt, ist der zweite Algorithmus gleichungsbasiert.Dieser verwendet für die Berechnung der Abspielbildrate ebenfalls den aktuellen Puff-erfüllstand Cb und einen nach Gleichung 5.17 berechneten Optimalwert Cbopt . Bei derBerechnung von Cbopt wird die aktuelle durchschnittliche Empfangsdatenrate Cravg ver-wendet. Da diese kurzzeitig die eigentliche Linkbandbreite übersteigen kann (siehe5.1.5), wird für die Berechnung das Minimum der beiden Werte verwendet. Anschlie-ßend wird die neue Abspielbildrate nach Gleichung 5.18 berechnet mit 0 ≤ α ≤ 1,−1 ≤ β ≤ 0 und 0 ≤ γ ≤ 1. Über die Parameter α und β werde in diesem Algorithmusdie obere bzw. untere Abspielbildrate gesteuert und γ ist Dämpfungsfaktor für dieÄnderung der Abspielbildrate.

Cbopt ← Cpb ·min(Lt, Cravg). (5.17)

C f ps ← γ · C f ps + (1− γ) · (1 + (min(max(Cb − Cbopt

Cbopt

, α), β))) · S f ps. (5.18)

Wird ein solcher Algorithmus für eine adaptive Abspielbildrate eingesetzt, so hat diesAuswirkungen auf den maximal möglichen Clientpufferfüllstand. Durch ein Absen-ken der Abspielbildrate wird die Datenrate gesenkt, mit der aus dem Clientpuffergelesen wird. Bei gleichbleibender Empfangsdatenrate füllt sich daher der Puffer desClients. Genau dieser Effekt ist auch erwünscht, um Buffer Underruns und somit eineruckelnde Wiedergabe des Videos zu verhindern. Effektiv wird während des Abspie-lens mit gesenkter Abspielbildrate die Prebufferingzeit erhöht. Somit ändert sich auchdie nach Gleichung 5.4 berechnete minimal notwendige Clientpuffergröße. Einem Buf-fer Overflow wirken die beiden Algorithmen entgegen, indem sie beim Überschreitendes berechneten maximalen Pufferfüllstandes die Abspielbildrate erhöhen. Die genauemaximale Obergrenze für den Pufferfüllstand hängt von dem verwendeten Algorith-mus ab. Ebenso haben die verwendeten Werte für Parameter der Algorithmen einenEinfluss auf den maximalen Clientpufferfüllstand.

37


Abbildung 5.2: Screenshot des Frontends

5.3 Die Simulationsumgebung

In diesem Kapitel werden in einem ersten Abschnitt eine Reihe von Frameworks undBibliotheken vorgestellt. Diese wurden auf ihre Eignung für den Einsatz in der ge-planten Simulationsumgebung hin untersucht. In dem zweiten Abschnitt wird dieletztendlich genutzte Implentierung dann im Detail beschrieben. Abbildung 5.2 zeigteinen Screenshot des Frontends. Das abgespielte Video ist aus technischen Gründendarauf nicht zu erkennen.

5.3.1 Frameworks und Bibliotheken

Zu Beginn der Arbeit wurden unterschiedliche Bibliotheken und Frameworks aufihre Tauglichkeit für die Implementierung der Simulationsumgebung hin untersucht,

38


um den Aufwand für die Implementierung zu minimieren. Diese wurden nach denfolgenden funktionalen Anforderungen ausgewählt:

• Eingebundener Encoder/Decoder für MPEG 2 Video,

• Anzeigen eines Video-Streams,

• Unterstützung des RTP-Protokolls, Server und Client.

Die wichtigste Komponente des Server-Moduls ist der Encoder, der den Live-Streamder verfügbaren Bandbreite entsprechend kodiert. Daher sollte das Framework direkteinen Encoder einbinden und dessen Steuerung während der Übertragung ermögli-chen. Die Möglichkeit, den Video-Stream live anzuzeigen ist insbesondere für die sub-jektive Beurteilung der Qualität von Bedeutung. In Abschnitt 6.1 wird dieser Aspektnoch einmal genauer dargestellt. Schließlich sollte das Framework noch das für dieÜbertragung ausgewählte RTP-Protokoll unterstützen und zwar sowohl server-, alsauch clientseitig.

Neben den drei funktionalen Anforderungen wurden noch nicht-funktionale Kriterienfür die Auswahl aufgestellt. Diese sind:

• Open-Source,

• einfache Modifizierbarkeit,

• gute Dokumentation und

• übersichtlicher Quelltext.

Auf die Verfügbarkeit des Quelltextes wurde besonders hoher Wert gelegt. Zum einenwar zu diesem Zeitpunkt noch nicht absehbar, ob Modifikationen an schon vorhande-nen Komponenten notwendig würden. Zum anderen kann die genaue Implementie-rung einzelnen Komponenten entscheidenen Einfluss auf das Verhalten des gesamtenSystems und somit auf die Messergebnisse haben. Um eine genaue Analyse von Ver-suchsergebnissen zu ermöglichen, muss diese daher bekannt sein. Die Anpassung oderder Austausch vorhandener Komponenten eines Frameworks sollte auch durch dessenDesign direkt überstützt werden.

5.3.2 Flussgraphen in Multimedia-Anwendungen

Ein bei Multimedia-Anwendungen sehr weit verbreitetes Konzept ist das des Flussgra-phen. In solchen Anwendungen werden Daten, wie zum Beispiel Video- oder Audio-Streams, von einer Datenquelle eingelesen. Anschließend durchlaufen diese verschiede-ne Verarbeitungsschritte. Handelt es sich um komprimierte Audio- oder Video-Daten,

39


Abbildung 5.3: Beispiel eines Flussgraphen

so müssen diese zunächst dekomprimiert werden. Anschließend können sie eine Reihevon Filtern durchlaufen, bis sie schließlich über Lautsprecher oder auf dem Bildschirmausgegeben werden. Dieser Datenfluss kann verallgemeinert durch einen gerichtetenGraphen beschrieben werden.

Die Knoten eines solchen Flussgraphen beschreiben dabei die einzelnen Operationen,die auf die Daten angewendet werden. Abbildung 5.3 zeigt einen solchen Flussgraphen.Dieser beschreibt einen einfachen Multimedia-Player, der ein Video mit Ton ausgebenkann. Die Daten werden von einem File Source genannten Knoten aus einer Datei ausge-lesen und an einen Demuxer-Knoten weitergeleitet. Dieser teilt den Datenstrom in einenAudio- und einen Video-Strom.Die beiden Datenströme werden an die entsprechen-den Dekoder-Knoten weitergeleitet. Das dekodierte Audio- und Video-Signal ereichtschließlich die Audio Sink und Video Sink genannten Knoten, welche für die Ausgabezuständig sind. Das Problem, ein Video mit Ton aus einer Datei abzuspielen, wird somittels der Devide-and-Conquer-Strategie auf mehrere einfache Probleme aufgeteilt.

Dieser Ansatz bietet eine hohe Flexibilität bei der Verarbeitung der Daten, da ein sol-cher Flussgraph zur Laufzeit erstellt werden kann. Ebenso lassen sich auf dem Prinzipdes Flussgraphen aufbauende Multimedia-Anwendungen und Frameworks einfach er-weitern. Die hohe Flexibilität führt allerdings auch zu einer steigenden Komplexität beider Implementierung. Werden einzelne Knoten statisch im Quelltext miteinander ver-bunden, so kann zu diesem Zeitpunkt manuell überprüft werden, ob die miteinanderverbundenen Knoten zueinander passen. Soll der Aufbau eines Flussgraphen auto-matisch zur Laufzeit erfolgen, so müssen die einzelnen Knoten bzw. deren Ein- undAusgänge über entsprechende Metadaten verfügen, um die Korrektheit des erzeugtenFlussgraphen zu garantieren.

40


5.3.3 VideoLAN Client

Der VideoLAN Client (VLC) [46] ist ein cross-platform Multimedia-Player mit inte-griertem Streaming-Server. Derzeit werden offiziell Binaries für

• Windows ab Version Windows 2000,

• Mac OS ab Version 10,

• verschiedene Linux Distributionen,

• BeOS und

• Windows CE / PocketPC angeboten.

Über ein Plugin-System unterstützt der VLC eine Vielzahl unterschiedlicher Video-und Audioformate. Als Streaming-Protokoll wird unter anderem auch RTP unterstützt.Obwohl es sich bei dem VLC um eine komplette Anwendung und kein Frameworkhandelt, bietet dieser durch sein Plugin-System eine ähnlich gute Erweiterbarkeit. Zu-sätzlich sind bereits ein funktionsfähiger Streaming-Server und ein Client mit graphi-scher Oberfläche vorhanden.

Die zuvor genannten drei funktionalen Anforderungen werden demnach vom VLCerfüllt. Außerdem ist der Quelltext seit 2001 unter der General Public License (GPL)frei verfügbar, womit auch die die erste nicht-funktionale Anforderung erfüllt ist. Esstellte sich allerdings relativ schnell heraus, dass sich die vorhandene Dokumentationfast ausschließlich an Endnutzer richtet. Die vorhandene Entwicklerdokumentationist in erster Linie auf die Entwicklung neuer Plugins ausgelegt. Bereits vorhandenePlugins sind nur im Quelltext dokumentiert. Die dort zu findenden Kommentare sindallerdings aufgrund ihrere Knappheit eher an Entwickler gerichtet, die sich mit demQuelltext auskennen.

Trotz der fehlenden Entwicklerdokumentation wurde versucht, einen einfachen TrafficShaper als Plugin zu entwickeln. Über diesen sollten der vorhandene Streaming-Servermit dem Video-Player intern verbunden werden. Bei diesem Versuch zeigte sich, dassder Quelltext des VLC seit dem Beginn der Entwicklung im Jahr 1996 sehr komplexgeworden ist, was einen hohen Aufwand für die Modifikation vorhandener Kompo-nenten bedeutet. Zusätzlich wurden noch Fehler in benötigten Modulen entdeckt. Beider weiteren Entwicklung der Simulationsumgebung wurde der VLC daher nicht mehrverwendet.

41


Abbildung 5.4: Verteilter Flussgraph einer NMM Anwendung [44]

5.3.4 Network-Integrated Multimedia Middleware

Die Network-Integrated Multimedia Middleware (NMM) [28] wurde an der Univer-sität des Saarlandes entwickelt. Sie stellt eine netzwerktransparente Softwareschichtbereit, auf deren Basis verteilte Multimedia-Anwendungen entwickelt werden kön-nen.

Die NMM folgt ebenfalls dem Prinzip des Flussgraphen. Die einzelnen Knoten werdenNodes genannt und deren Ein- und Ausgänge als Jacks bezeichnet. Ein Ausgang einesKnoten wird mit einem Eingang eines anderen Knoten über eine Transport Strategyverbunden. Durch die Verwendungen des Strategy Design Pattern können dieselbenKnoten sowohl effizient in einer Anwendung verbunden werden, die auf nur einemHost läuft, als auch über ein Netzwerk, falls die Knoten auf unterschiedlichen Hostslaufen. Derzeit stellt NMM drei Transport Strategies für die Verbindung zweier Nodesüber ein Netzwerk bereit, nämlich

• eine TCP-Strategy,

• eine UDP-Strategy und

• eine RTP-Strategy.

Diese Strategies tunneln die Kommunikation zwischen zwei Nodes über das entspre-chende Protocol. Abbildung 5.4 zeigt einen auf drei Hosts verteilten Flussgraphen.

Sowohl Encoder, als auch Decoder und eine Videoausgabe werden bereits als ferti-ge Nodes mitgeliefert. Über die RTP-Strategy wird außerdem auch die gewünschteUnterstützung für das RTP-Protokoll bereitgestellt, so dass von der NMM alle gefor-derten funktionalen Anforderungen erfüllt werden. Ebenso ist die Anforderung, dass

42


der Quelltext verfügbar sein soll, erfüllt. Mit Hilfe der guten Dokumentation ließ sichrelativ schnell eine verteilte Client-Server-Anwendung entwickeln. In dieser laß derServer ein Video aus einer Datei aus, skalierte es und kodierte es mit einer vorgege-benen Streambitrate neu. Das Video wurde dann über das Netzwerk an den Clientgesendet, welcher das Video auf dem Bildschirm ausgab. In einem nächsten Schrittsollte daraufhin der Encoder-Node so modifiziert werden, dass eine adaptive Steue-rung der Streambitrate möglich würde. Dabei stellte sich heraus, dass der Quelltextschon vorhandener Nodes teilweise sehr schlecht dokumentiert war. Außerdem zeigtesich, dass selbst kleine funktionale Änderungen vorhandener Komponenten aufgrundvon Abhängigkeiten wesentlich aufwändiger waren als erwartet.

5.3.5 LiveMedia

LiveMedia [34] ist ein in C++ geschriebenes Framework für die Erstellung von Multi-media Streaming Anwendungen. Es werden das Real-Time Transport Protocol (RTP),das Real-Time Streaming Protocol (RTSP) [38] und das Session Initiation Protocol (SIP)[14] unterstützt. Für eine Reihe von Video- und Audio-Formaten sind bereits Funktio-nen vorhanden, um den Payload der RTP-Pakete entsprechend der jeweiligen RFCs zuerstellen. Das Design des LiveMedia-Frameworks folgt ebenso wie das der NMM demPrinzip des Flussgraphen. Gesteuert wird die Datenverarbeitung in einer auf diesemFramework basierenden Anwendung über einen TaskScheduler.

Auf Basis des LiveMedia-Frameworks wurde ebenfalls ein Prototyp eines Live-Strea-ming-Servers implementiert. Als Datenquelle wurde ein im Netzwerk verfügbarererMulticast Fernsehstream verwendet. Um diesen zu empfangen wurde eine geeigne-te MediaSource-Klasse entwickelt. Das Videobild wurde in einem Decoder/Encoder-Objekt auf eine festgelgte Bildgröße und Bitrate transkodiert. Sowohl für den Decoder,als auch den Encoder wurde die libavcodec verwendet. Diese wird in Abschnitt 5.3.7vorgestellt. Als Client wurde in diesem Versuchsaufbau der VLC eingesetzt.

Während der Entwicklung des Prototypen wurde festgestellt, dass sich das Designdes LiveMedia-Frameworks nicht für die geplante Simulationsumgebung eignet. Ineiner LiveMedia-Anwendung wird der Datenfluss von der Datensenke, dem RTPSink,gesteuert. Die Daten werden dementsprechende durch den Flussgraphen „gezogen“.Diese Steuerung ist geeignet für das Live-Streaming in On-Demand Anwendungenmit Dateien als Datenquelle. Handelt es sich allerdings bei dem zu sendenen Streamum eine Live-Übertragung, so kann die Geschwindigkeit der Datenquelle nicht durchden Server kontrolliert werden. Die Daten werden in den Flussgraphen der Server-anwendung „hineingeschoben“. Die Datenquelle bestimmt also die Verarbeitungsge-

43


schwindigkeit. Eine Anpassung des LiveMedia-Frameworks wäre nur mit sehr hohemAufwand möglich gewesen, da alle Komponenten auf einen durch die Datensenkegesteuerten Datenfluss ausgerichtet sind. Ebenfalls ein Hinderniss für den Einsatzin der Simulationsumgebung ist die fehlende Multithreading-Tauglichkeit. Aus die-sen Gründen wurde die Implementierung der Simualtionsumgebung auf Basis desLiveMedia-Frameworks nicht weiter verfolgt.

5.3.6 Das Qt-Framework

Bei der Implementierung der Prototypen sowohl auf Basis der NMM, als auch desLiveMedia-Frameworks, hatte sich gezeigt, dass die Verwendung eines Multimedia-Frameworks eine schnelle Implementierung eines On-Demand Streaming-Servers er-möglicht. Anpassungen der dabei verwendeten Komponenten für einen adaptivenLive-Streaming-Server erwiesen sich allerdings als sehr aufwändig. Daher wurde fürdie weitere Entwicklung auf ein Multimedia-Framework verzichtet. Stattdessen wurdedas im folgenden beschriebene Qt-Framework für die Implementierung der einzel-nen Module und des graphischen Frontends verwendet. Sowohl für den Encoder imServer-Modul, als auch für den Decoder und die Videoausgabe wurden entsprechendeexterne Bibliotheken verwendet.

Qt ist ein C++ cross-platform Framework der Firma Trolltech. Auf Basis dieses Frame-works geschriebene Anwendungen lassen sich ohne Modifikationen sowohl für dieWindows-Plattform, als auch für Linux, verschiedene Unix Derivate und Mac OS Xkompilieren. Das Framework wird von Trolltech unter zwei Lizenzen, einer kommerzi-ellen und der GPL angeboten. Tabelle 5.6 listet die wichtigsten enthaltenen Module auf.Während das QtCore-Modul in jede Qt-Anwendung eingebunden werden muss, sowerden die übrigen Module nur genutzt, falls Klassen aus diesen benötigt werden.

Das QtCore-Modul enthält die Klasse QObject. Für alle von dieser Klasse abgeleitetenUnterklassen kann das Qt Meta-Object System genutzt werden. Dieses ist die Basisfür ein weiteres wichtiges Feature, nämlich den Signal-Slot-Mechanismus. Die erstel-len Objekte werden mit Laufzeitinformationen versehen, so dass ein dynamischesProperty-System genutzt werden kann. Die Implementierung des Meta-Object Sys-tems besteht im Qt-Framework aus drei Komponenten. QObject ist Basisklasse für alleKlassen, die das Meta-Object System nutzen. Über das Makro Q_OBJECT werden diegenannten Features aktiviert und ein Präprozessor erweitert den Quelltext der Klassenum notwendigen Code. Dieser Präprozessor wird dementsprechend auch Meta-ObjectCompiler (moc) genannt.

44


QtCore Hauptklassen, welche auch von anderen Modulen genutzt werdenQtGui Komponenten für die Erstellung graphischer ObflächenQtNetwork Klassen für die NetzwerkprogrammierungQtOpenGL Klassen für die OpenGL-ProgrammierungQtSql Klassen zum Zugriff auf Datenbanken via SQLQtSvg Klassen zum Anzeigen von Scalable Vector Graphics (SVG)QtXml Klassen für die XML-Verarbeitung

Tabelle 5.6: Hauptmodule des Qt-Frameworks

Für jede von QObject abgeleitete Klasse kann zur Laufzeit ein Meta-Objekt über dieFunktion metaObject():QMetaObject abgerufen werden. Dieses enthält unter ande-rem Informationen über die in der jeweiligen Klasse enthaltenen Signals und Slots,sowie der Properties.

Insbesondere in Anwendung mit einer graphischen Oberfläche (GUI) wird erst zurLaufzeit entschieden, welche Objekte miteinander kommunizieren. Eine häufig genutz-te Technik in Frameworks ist die Verwendung von Callback-Funktionen. Der Callbackist dabei ein Zeiger auf eine Funktion, die aufgerufen werden soll, wenn ein bestimm-tes Ereignis auftritt. Werden Callbacks verwendet, so kann der Kommunikationsflusszwischen den einzelnen Objekten zur Laufzeit modifiziert werden. Dieser Ansatz hatallerdings auch zwei gewichtige Nachteile. Zum einen sind die Aufrufe der Callback-Funktionen nicht typsicher. Der Compiler kann fehlerhafte Aufrufe nicht erkennen, sodass sich diese erst zur Laufzeit bemerkbar machen. Der anderen Nachteil ist, dassdie Callbacks nur von der Funktion genutzt werden kann, welcher der Zeiger auf dieCallback-Funktion übergeben wurde.

Das Qt-Framework bietet hierfür das Konzept der Signals und Slots. Innerhalb vonauf QObject basierenden Klassen können hierzu die neu definierten Schlüsselwörtersignal, slot und emit genutzt werden. Mittels signal werden in der Klassendeklara-tion Signale definiert, die diese Klasse verschicken kann. Über das Schlüsselwort slotwerden Funktionen einer Klasse als Slots deklariert. Die Klasse QObject enthält einestatische Methode connect(*sender:QObject, *signal:char, *method:char):bool,über die ein Signal eines Objects mit einem Slot eines anderen verbunden werdenkann. Es werden nur Signals mit Slots verbunden, deren Methodensignaturen zuein-ander kompatibel sind. So wird die Typsicherheit der Verbindungen gewährleistet. InAbbildung 5.5 ist dieses Konzept noch einmal graphisch dargestellt.

Mittels des Meta-Object Systems des Qt-Frameworks können Klassenattribute als so-genannte Properties über Standardfunktionen gelesen und geschrieben werden. Ei-

45


Abbildung 5.5: Das Signal-Slot-Konzept des Qt-Frameworks [43]

nige Compilerhersteller bieten eine ähnliche Funktionalität über propritäre Erwei-terungen des C++ Standards. Für das Qt-Property-System wird dagegen das Ma-kro Q_PROPERTY() verwendet, so dass es mit einer Vielzahl von Compilern nutzbarist. Über das Makro wird die Property mit einem Namen versehen, über den aufsie zugegriffen werden kann. Es muss für jede Property eine Get-Funktion angege-ben werden. Für schreibbare Properties wird zusätzlich eine Set-Funktion angege-ben. Auf die so deklarierten Properties kann zur Laufzeit über die in der KlasseQObject definierten Funktionen setProperty (*name:char, &value:QVariant):bool

und property(*name:char):QVariant zugegriffen werden. Die Namen der Propertieseines Objektes können zur Laufzeit über das Meta-Objekt der Klasse ausgelesen wer-den.

5.3.7 libavcodec

Die libavcodec Bibliothek ist die Audio- und Video-Codec Bibliothek des FFmpegProjektes [10]. Sie enthält Decoder für eine Vielzahl von Audio- und Video-Formatenund für weit verbreitete Formate stehen ebenfalls Encoder zur Verfügung. Aufgrundder hohen Anzahl an untersützten Formaten und einer plattformunabhängigen Imple-mentierung wird die libavcodec in den meisten Open-Source Multimedia-Playern undauch in Frameworks wie NMM genutzt. Die Bibliothek wird aktiv durch eine großeEntwicklergemeinde gepflegt und weiterentwickelt. Es werden sowohl neue Encoder

46


und Decoder hinzugefügt, als auch bereits vorhandene optimiert und von Fehlernbereinigt.

Die MPEG-2 Decoder und Encoder dieser Bibliothek wurden in dem Prototyp aufBasis des LiveMedia-Frameworks und der Qt-basierten Implementierung eingesetzt.Sowohl Decoder, als auch Encoder ließen sich problemlos einbinden. Als problema-tisch erwies sich allerdings die Steuerung der Rate Control des Encoders. Diesem läßtsich bei der Initialisierung eine gewünschte Bitrate für den CBR-Modus übergeben,welche allerdings anschließend nicht mehr geändert werden kann. Ein Großteil derbei der Initalisierung übergebenen Parameter wird von dem Encoder in einen privatenDatenbereich kopiert, auf den über das Interface der Bibliothek nicht zugegriffen wer-den kann. Zu den wenigen Encoder-Parametern, welche auch zur Laufzeit geändertwerden können, gehören die Werte qmin und qmax. Diese Parameter beschränken dievon der Rate Control berechneten Quantizer-Werte auf den vorgegebenen Bereich undlassen daher indirekt eine Steuerung der Streambitrate zu.

Auf Basis dieser Steuermöglichkeit der Streambitrate wurde ein Additive Increase /Additive Decrease (AIAD) Algorithmus entwickelt. Die beiden Parameter qmin undqmax wurden von diesem Algorithmus auf Basis des Serverpufferfüllstandes gesteu-ert. Dieser Ansatz der adaptiven Steuerung des Encoders erwies sich allerdings alsnicht geeignet. Die Steuerung der Streambitrate über die Parameter qmin und qmax istsehr ungenau, was zu starken Schwankungen in der Bildqualität führte. Diese wurdendurch die Berechnung der Parameter über den AIAD-Algorithmus auf Basis des Puffer-füllstandes zusätzlich noch verstärkt. Daher wurde der Encoder der libavcodec durchden im folgenden Abschnitt beschriebenen mpeg2enc ersetzt, welcher eine direkteSteuerung der Streambitrate im CBR-Modus zuläßt.

5.3.8 mpeg2enc

Der mpeg2enc ist der MPEG-2 Encoder des MJPEG-Projektes [31]. Es handelt sichdabei um eine Weiterentwicklung des MPEG-2 Referenzencoders. Die ursprünglicheImplementierung in der Programmiersprache C wurde nach C++ portiert. Zusätzlichwurden eine Reihe von Optimierungen vorgenommen, so dass die Kodiergeschwin-digkeit um den Faktor 12 gesteigert werden konnte.

Im Gegensatz zu der libavcodec ist mpeg2enc keine Bibliothek, sondern eine kompletteAnwendung, um YUV-Videos nach MPEG-2 ES zu kodieren. Aufgrund des gut struk-turierten Designs ließ sich der Quelltext des eigentlichen Encoders leicht von dem derumgebenden Anwendung trennen. Dieser wurde anschließend so modifiziert, dasser mittels einer Adapter-Klasse in der Simulationsumgebung genutzt werden kann.

47


Bei der Verwendung des mpeg2enc Encoders kann die Encoderbitrate auch nach derInitialisierung noch gesteuert werden.

5.3.9 libmpeg2

Die libmpeg2 ist eine Open-Source Bibliothek zum Dekodieren von MPEG-1 undMPEG-2 Videostreams. Bei der Entwicklung wurde insbesondere auf die vier Punkte

• Standardkonformität,

• Geschwindigkeit,

• Portabilität und

• Wiederverwendbarkeit

Wert gelegt. Es werden nicht alle MPEG-1 und MPEG-2 Profile unterstützt, sondernnur die am häufigsten eingesetzten Profile „constrained parameters“ für MPEG-1 unddas „main profile“ für MPEG-2. Gleichzeitig mit dem Wechsel des MPEG-2 Encodersvon libavcodec auf mpeg2enc wurde der Decoder auf die libmpeg2 umgestellt.

5.3.10 Simple Directmedia Layer

Die Simple Directmedia Layer (SDL) [39] ist eine cross-platform Bibliothek für den low-level Zugriff auf Ein- und Ausgabegeräte. Insbesondere ermöglicht die SDL auch einenbetriebssystemunabhängigen Zugriff auf hardwarebeschleunigte Funktionen und den2D Framebuffer von Grafikkarten. Die SDL wird häufig in Multimedia- Playern für dieVideoausgabe genutzt, da über sie sogenannte YUV-Overlays genutzt werden können.Diese sind spezielle Bereiche im Speicher der Grafikkarte, in welche die Daten YUV-kodierter Bilder von den Anwendungen geschrieben werden. Die YUV-Daten werdenanschließend hardwarebeschleunigt in den RGB-Farbraum konvertiert und an dereingestellten Position ausgegeben.

5.4 Implementierung

Für die Implementierung wurde zwar keines der Frameworks ausgewählt, sie folgtdennoch dem Flussgraphen-Prinzip. Es wurde zusätzlich besonderer Wert auf dieTrennung von Server-, Link- und Client-Modul gelegt. Diese können sowohl als Kom-ponenten innerhalb der Simulationsumgebung, als auch in Einzelanwendungen aufverschiedenen Rechnern genutzt werden. Um dies zu ermöglichen, kommunizieren

48

5.4 Implementierung

Abbildung 5.6: Komponenten der Simulationsumgebung und deren Verteilung

die Module über Sockets miteinander. Werden die drei Module in der Simulationsum-gebung zusammengefasst, so wird das Loopback-Device des Betriebssystems für dieNetzwerkkommunikation verwendet. Abbildung 5.6 zeigt die Verteilung der einzelnenKomponenten innerhalb der Simulationsumgebung.

Server-Modul : Dieses Modul simuliert den Server. Es besteht besteht aus den dreiKomponenten File Sink, Encoder und Rtp Sink.

Link-Modul : Das Link-Modul simuliert einen UTRAN-Link. Alle Daten, die zwischenServer- und Client-Modul ausgetauscht werden, laufen durch dieses Modul.

Client-Modul : Das Client-Modul besteht aus den Komponenten Rtp Source, Decoderund einem File Sink.

Video Display : Auf dem Video Display werden während eines Simualtionslaufesin Echtzeit das Eingangsvideobild des Servers und das vom Client dekodierteVideobild nebeneinander angezeigt. Es dient zur subjektiven Beurteilung derEmpfangsqualität.

Value Recorder : Der Value Recorder zeichnet während eines Simualtionslaufes diegewünschten Variablenwerte von Server, Link und Client auf. Diese werden imCSV-Format für eine spätere Auswertung in eine Datei geschrieben.

49


Abbildung 5.7: Vereinfachtes Klassendiagramm des Server-Moduls

Script Player : Der Script Player kann zur automatischen Steuerung des Link-Modulsverwendet werden.

5.4.1 Server-Modul

Abbildung 5.7 zeigt ein vereinfachtes Klassendiagramm des Server-Moduls. Klassenund Funktionen, welche nicht direkt für das Live-Streaming von Bedeutung sind, wur-den ausgeblendet. Insbesondere werden die für das Qt-Property-System notwendigenGet- und Set-Methoden nicht dargestellt, da diese die Übersichtlichkeit stark beein-trächtigen.

50

5.4 Implementierung

Wie in den meisten Multimedia-Anwendungen, so wird auch in dem Server-Moduldas Prinzip des Flussgraphen verwendet. Im Gegensatz zu NMM und ähnlich zuder LiveMedia Bibliothek werden nur zwei verschiedene Knotentypen genutzt. DieKlasse Source ist die abstrakte Oberklasse für alle Arten von Datenquellen. Sie istvon der Qt-Thread-Klasse QThread abgeleitet, da Datenquellen ihre Daten aktiv inden Flussgraphen „hineinpumpen“. Unterklasse der Klasse Source sind daher auchdafür zuständig, dass Streams den Flussgraphen mit der korrekten Geschwindigkeit(Framerate bei Videos) durchlaufen.

Der zweite Knotentyp sind die Datensenken, welche Unterklassen der Klasse Sink

sind. Diese implementieren in erster Linie die abstrakte Funktion newData(*data:char,

length:int), über die der Knoten von seinem Vorgänger im Flussgraphen die Datenübergeben bekommt. Alle Zwischenknoten auf einem Pfad zwischen Datenquelle undDatensenke werden ebenfalls als Unterklasse von Sink implementiert.

Das gesamte Server-Modul wird durch das Facade Design Pattern nach außen gekap-selt. Die Klasse Server dient dabei als Facade für den Zugriff auf Statusvariablender einzelnen Komponenten und der Steuerung des Server-Moduls. Statusvariablender Komponenten werden als Qt-Properties der Server-Klasse nach außen sichtbargemacht. Sowohl die Klasse ServerWidget, welche eine grafische Oberfläche für dasServer-Modul bereitstellt, als auch die Klasse ValueRecorder greifen ausschließlich aufKlasse Server zu.

Um die gewünschte Funktion als Live-Streaming-Server zu erbringen, enthält dasServer-Modul drei Komponenten. Als Datenquelle wird die Klasse FileSource verwen-det. Diese Klasse liest einen MPEG 2 Elementary Stream aus eine Datei aus und deko-diert diesen mit einer vorgegebenen Framerate. Als Unterklasse der abstrakten KlasseSink startet die Klasse FileSource einen eigenen Thread für das Einlesen und Deko-dieren des Video-Streams. Innerhalb dieses Threads wird auch der Encoder ausgeführt,der durch die Klasse EncoderAdapter in den Flussgraphen eingebunden wird. Als Ad-apter passt diese Klasse das Interface des verwendeten Encoders an das Sink-Interfacean. Zusätzlich bietet diese Klasse noch die Funktion setBitrate(bitrate:int), überdie die Encoderbitrate eingestellt werden kann. Der Wert für die Encoderbitrate kannjederzeit geändert werden und wird für die Kodierung ab dem nächsten Frame verwen-det. Die Kodierung der Frames erfolgt synchron in der Funktion newData(*data:char,

length:int) welche anschließend den nächsten vom Encoder kodierten Frame an dasRtpSink Objekt weiterleitet. Die für die Messungen eingesetzte Implementierung derFileSource-Klasse ist fest auf eine Framerate von 25 fps eingestellt. Da bei Mobile-TVAnwendungen üblicherweise eine Framerate von 12,5 fps verwendet wird, leitet derEncoder Adapter nur jedes zweite Bild weiter.

51


Die Funktion newData(*data:char, length:int) in der Klasse RtpSink fügt die emp-fangenen Daten nur in den Puffer buffer ein, sofern in diesem ausreichend Platzvorhanden ist. Im Gegensatz zu allen anderen Sink-Klassen ist RtpSink ebenso wiedie Klasse Source von QThread abgeleitet. Die Scheduler-Funktion zum Versenden derRTP-Pakete ist in der Klasse RtpSink implementiert und läuft in einem zweiten Thread,da dessen Senderate laut dem Modell in Abschnitt 5.1.1 unabhängig von der aktuellenStream-Bitrate einstellbar sein soll. Sobald ein RTP-Paket versendet werden soll, wirddie Funktion nextRtpPacket() aufgerufen, welche das Paket aus den Daten im Puf-fer erstellt. Dieses Paket wird dann über den rtpSocket an den Client gesendet undder Scheduler-Thread angehalten, bis das nächste RTP-Paket versendet werden kann.In Algorithmus 7 ist der verwendete Scheduler-Algorithmus dargestellt. Der Wert Ps

ist dabei die Größe des versandten Pakets in Byte und now die aktuelle Uhrzeit inMikrosekunden. Dieser Algorithmus berücksichtigt bei der Berechnung der Wartezeitzwischen dem Versenden zweier RTP-Pakete die Zeit, die zum Erstellen des Paketsbenötigt wird, und gleicht Ungenauigkeiten des Betriebssystem-Schedulers durch denWert a aus.

Algorithmus 7 Scheduler im RTP-Sink1: a← 02: while !shutdown do3: t1 ← now4: P← nextRtpPacket

5: send p6: t2 ← now7: s← 1000000∗8∗Ps

St− (t2 − t1)− a

8: if s > 0 then9: sleep for s microseconds

10: t3 ← now11: a← (t3 − t2)− s12: else13: a← 014: end if15: end while

Die zwei parallel laufenden Threads im Server-Modul greifen beide auf den Pufferbuffer im RTP-Sink zu, so dass die Zugriffe synchronisiert werden müssen. Die KlasseBlockingQueue (nicht in der Abbildung) implementiert einen threadsicheren, begrenz-ten FIFO-Ringpuffer. Die Synchronisierung der Zugriffe erfolgt über zwei Semaphoren.Einer der Semaphoren gibt die Anzahl der freien Bytes im Puffer an, während der

52

5.4 Implementierung

andere die Anzahl der belegten Bytes enthält. Die Methoden put() zum Hinzufügenund take() zum Herausnehmen von Daten sind sowohl blockierend, als auch nicht-blockierend implementiert. Die Funktion newData(*data:char, length:int) der Klas-se RtpSink verwendet die nicht-blockierende put-Funktion. Im Gegensatz dazu nutztdie Funktion nextRtpPacket() die blockierende take()-Funktion, so dass der Scheduler-Thread bei leerem Puffer angehalten wird, bis neue Daten vorhanden sind.

Die serverseitigen Algorithmen aus Abschnitt 5.2 sind in der Klasse RtpSink bzw. de-ren Unterklassen implementiert. Für die RTP-Komponente des Servers wurde dasStrategy Design Pattern mit der Klasse Server als Context und RtpSink als Strategygewählt. So ist es einerseits möglich, schnell und einfach weitere Rate Control Ver-fahren für die Übertragung einzubinden, als auch im laufenden Betrieb zwischenden einzelnen Verfahren zu wechseln. Die RtpSink-Klasse stellt alle grundlegendenFunktionen für die Übertragung eines MPEG-2 Videostreams über RTP zur Verfü-gung. Dies betrifft sowohl das Erstellen und Versenden von RTP-Paketen, als auchdie RTCP-Kommunikation mit dem Client. Die drei Unterklassen RetransmitRtpSink,TfrcRtpSink und RftrcRtpSink erweitern diese Klasse um die entsprechenden RateControl Verfahren.

Die RetransmitRtpSink-Klasse definiert zusätzlich das Hash-Set sentPackets, in demeine vorgegebene Anzahl von bereits gesendeten RTP-Paketen für einen eventuellenRetransmit gespeichert werden. In der Funktion rtcpReceived(packet:RtcpPacket)

ist der Algorithmus 1 implementiert, wobei die Liste retransmitPackets der MengeLP entspricht. Auf diese Liste greift die Funktion nextRtpPacket() zu, die in der KlasseRetransmitRtpSink überschrieben wird. Falls die Liste retransmitPackets nicht leerist, so wird jedes fünfte RTP-Paket aus dieser Liste genommen.

Der serverseitige Teil des TFRC-Algorithmus aus Abschnitt 5.2.2 wir durch die Klas-se TfrcRtpSink bereitgestellt. Die Berechnung der Sendebitrate wird in der neuenFunktion updateSendBitrate() durchgeführt. Diese wird sowohl beim Empfang ei-nes RTCP-Pakets über die Funktion rtcpReceived(packet:RtcpPacket), als auch überden noFeedbackTimer aufgerufen.

Die Implementierungen der beiden vorherigen Rate Control Algorithmen nutzen beideden in der RtpSink definierten Scheduler zum Versenden der RTP-Pakete. Im Gegen-satz dazu wird die Funktion run() in der Klasse RftrcRtpSink mit einem eigenen Sche-duler überschrieben, der nur RTP-Pakete sendet, falls ausreichend Platz im Netzwerk-puffer vorhanden ist. Der Füllstand des Client-Puffers wird bei dieser Implementierungnicht berücksichtigt, da für diesen, wie in Abschnitt 5.1.6 gezeigt, eine obere Grenzeberechnet werden kann. Diese ist niedrig genug, so dass ein entsprechend großer Puf-fer im Client bereitgestellt werden kann. In einer ersten Version des RftrcRtpSink

53


Abbildung 5.8: Vereinfachtes Klassendiagramm des Client-Moduls

wurde zur Berechnung des Netzwerkpufferfüllstandes ein gleitender Durchschnitt derPaketgrößen verwendet. Dies hatte zur Folge, dass Buffer Overflows nicht vollständigverhindert wurden. Daher wurde die FIFO-Liste packetSizes eingeführt, in der diePaketgrößen aller noch nicht vom Client empfangenen Pakete zwischengespeichertwerden.

5.4.2 Client-Modul

Das Client-Modul ist von der Struktur analog zu dem Server-Modul aufgebaut. Ab-bildung 5.8 zeigt das vereinfachte Klassendiagramm des Client-Moduls. Die KlasseClient dient als Facade für das gesamte Modul und es wurde ebenfalls das Strategy De-sign Pattern für die Implementierung der einzelnen Rate Control Algorithmen verwen-

54

5.4 Implementierung

det. Zu jeder RtpSink-Klasse im Server-Modul wurde eine entprechende RtpSource-Klasse im Client-Modul erstellt.

Der Empfang der RTP-Pakete vom Server und das Schreiben dieser Pakete in den Cli-entpuffer buffer wird von der Funktion readRtpSocket() durchgeführt. Diese Funk-tion ist ein Qt-Slot, welcher von der Qt-Event Loop aufgerufen wird, sobald neueRTP-Pakete den Client erreichen. Anhand der Sequenznummern im RTP-Header wirdeine Überprüfung auf Paketverluste durchgeführt und anschließend das Paket seinerSequenznummer entsprechend in den Clientpuffer eingefügt. Danach wird die Ab-spielbildrate über einen der beiden in Abschnitt 5.2.4 beschriebenen Algorithmen neuberechnet.

Die Ausgabe des Videostream findet in einem zweiten Thread, unabhängig vom Emp-fangen der RTP-Pakete, statt. Die run()-Funktion liest mit der berechneten Abspiel-bildrate fps Frames aus dem Puffer buffer aus und gibt anschließend die Daten deskompletten Frames an das DisplaySink und falls gewünscht auch an das FileSink

weiter. Ebenso wie in der RtpSink-Klasse des Server-Moduls, greifen auch in derRtpSource-Klasse zwei parallel laufende Threads auf den Puffer zu. Da für diesendie Klasse QList genutzt wird, welche nicht Thread-sicher ist, wird der SemaphorebufferLevel zur Synchronisierung der Zugriffe verwendet.

Um die Daten eines einzelnen Frames innerhalb des MPEG-2 Elementary Streams zuerkennen, wird die Helferklasse Mpeg2EsStreamParser verwendet. Dieser Parser liestbeim Aufruf der Funktion parse(maxBytes:int) den MPEG-2 ES aus dem Clientpuf-fer in einen internen FIFO-Puffer, bis entwede maxBytes gelesen wurden, oder einMPEG-Header gefunden wurde. Die Funktion getCurrentHeader() gibt den Headerzu Beginn des Teilstücks zurück, das sich gerade im Puffer des Parsers befindet. Überdie Funktion getNextHeader() kann der nächste gefundene Header im ElementaryStream ausgelesen werden. Den aktuellen Inhalt des Parser-Puffers ohne den zuletztgefundenen MPEG-2 ES Header gibt die Funktion getData() zurück. Anschließendwerden diese Daten aus dem Puffer gelöscht, womit der zuletzt gelesen Header amKopf des Puffers steht.

5.4.3 Link-Modul

Die Link-Simulation wurde in Form einer einzelnen Klasse implementiert. Eine Instanzdieser Klasse simuliert die Übertragung über eine UTRAN-Verbindung im Acknow-ledged Mode. In der Simualtionsumgebung wird FDMA zur Trennung von Down-und Uplink verwendet. Für jede der beiden Verbindungen wird eine separate Instanz

55


Abbildung 5.9: Schematischer Aufbau der Linksimulation

der Simulations-Klasse gestartet. Verschiedene IP-Verbindungen in eine Senderich-tung werden ohne Priorisierung gemultiplexed. Abbildung 5.9 zeigt den Datenflussinnerhalb einer Link-Instanz. Für jede IP-Verbindung wird ein Socket geöffnet, überden die Daten vom Sender empfangen werden. Die ankommende Pakete werden derEmpfangsreihenfolge nach in den Linkpuffer geschrieben. Ein Scheduler-Thread liestjeweils das sich am Kopfende der Queue stehende Paket ein und sendet dies zumkorrekten Zeitpunkt an den Empfänger. Dieser Zeitpunkt wird anhand des Empfangs-zeitpunktes des Pakets und dessen Größe durch die in Algorithmus 8 beschriebeneFunktion berechnet. Diese verwendet wiederum die Funktion, die in Algorithmus 10dargestellt ist.

Bei Empfang auf einem der Eingangsports wird den Paketen der Empfangszeitpunktund der Zielport hinzugefügt. Da die Pakete bis zum Weitersenden durch den Sche-duler den Link-Puffer durchlaufen müssen, entspricht der Zeitpunkt der Berechnungdes Sendezeitpunktes nicht dem Empfangszeitpunkt, so dass letzterer gespeichert wer-den muss. Der Zielport wird anhand des Ports bestimmt, über den das jeweilige Paketempfangen wurde. Die Link-Simulation wird nicht transparent in die IP-Verbindungenzwischen Server- und Client-Modul eingebunden. Der Sender sendet daher nicht di-rekt an den Port, auf dem der Empfänger die entsprechende IP-Verbindung empfängt,sondern an den Port, auf dem die Link-Simualtion diese Verbindung empfängt. DieÜbersetzung von Empfangsport auf den korrekten Zielport des Empfängers wird an-hand einer Tabelle im Link-Modul durchgeführt.

Der Funktion getSendTs(s:uint, ta:double) (Teil 1 Algorithmus 8, Teil 2 Algorith-mus 9) werden als Parameter die Größe s des zu sendenden IP-Pakets in Byte undder Empfangszeitpunkt ta in Sekunden übergeben. Für die Berechnung des Sendezeit-punktes te werden zusätzlich noch die in Tabelle 5.7 aufgeführten globalen Variablenverwendet. In Teil 1 der Funktion wird zunächst der Startzeitpunkt tn des nächstenTTI berechnet. Falls das Paket nach diesem Zeitpunkt angekommen ist, so wird in

56

5.4 Implementierung

ts frühest möglicher Sendezeitpunkt des nächsten Pakets (s)tc Sendezeitpunkt der nächsten unvollständigen PDU (s)telast Sendezeitpunkt des letzten Pakets (s)f b freie Bytes im aktuellen TTI

Tabelle 5.7: Globale Variablen der Link-Simulation

Zeile 3 die originale Ankunftszeit ta auf den Startzeitpunkt des ersten nachfolgendenTTI aufgerundet. In diesem Fall findet keine Konkatenation mit dem zuvor versandtenIP-Paket statt. Falls dieses vor dem Startzeitpunkt des nächsten TTI tn, aber nach demÜbertragungszeitpunkt tc der letzten unvollständig PDU ankommt, oder die zuletztgesendete PDU vollständig war, so ist ebenfalls keine Konkatenation möglich. Daherwird mit der Übertragung des IP-Pakets im nächstmöglichen TTI begonnen. Ist eineKonkatenation möglich, so wird die angegebene Größe s des Pakets um den noch frei-en Platz in dem vorhergehenden TTI veringert und der Ankunftszeitpunkt auf denStartzeitpunkt tl des letzten TTI gesetzt. Zusätlich wird die Variable c in Zeile 15 auftrue gesetzt, um zu signalisieren, das eine Konkatenation stattgefunden hat.

Nach Durchlauf des ersten Teils der Funktion getSendTs(s:uint, ta:double) ist dieVariable ta auf den Zeitpunkt gesetzt, zu dem mit der Übertragung der SDU begonnenwird. Falls eine Konkatenation mit der vorherigen SDU möglich war, so ist die Angabeder Paketgröße s auf den noch zu sendenden Teil angepasst. Im zweiten Teil werdenin den Zeilen 1 - 6 zunächst die Anzahl der notwendigen PDUs zum Übertragen derSDU, die Anzahl der notwendigen TTIs und die Anzahl der bei der Übertragungvollständigen TTIs berechnet. Der Wert von ntticompl wird in Zeile 5 um eins erhöht,falls eine Kontaktenation mit der vorherigen SDU stattgefunden hat.

In den Zeile 9 - 13 wird nun anhand der Anzahl der notwendigen PDUs der Emp-fangszeitpunkt te berechnet. Im Falle einer Konkatenation wird te noch um ein TTIerhöht, da der Ankunftszeitpunkt ta im ersten Teil auf den Startzeitpunkt des letztenunvollständigen TTI gesetzt wurde. Da der Acknowledged Mode den Empfang derSDUs in Sendereihenfolge garantiert, wird in Zeile 13 sichergestellt, dass der Emp-fangszeitpunkt der gerade versandten SDU nicht vor dem der zuletzt versandten liegt.Anschließend werden die globalen Variablen auf die nun aktuellen Werte gesetzt.

In Algorithmus 10 ist die zuvor erwähnte Funktion delayTransmitPdus(pdus:uint)

dargestellt. Diese berechnet die benötigte Zeit, um die angegebenen Anzahl von PDUszu übertragen. Im Falle einer Konkatenation von SDUs kann es vorkommen, dass dieFunktion getSendTs(s:uint, ta:double) bei kleinen SDUs eine Anzahl von 0 nochzu versendenden PDUs berechnet. In diesem Fall wird die Übertragung nur durch das

57


Algorithmus 8 Funktion getSendTs(s:uint, ta:double) (Teil 1)1: c←false2: tn←

⌈ts·1000

Ltti

⌉· Ltti

1000

3: tl ←⌊

ts·1000Ltti

⌋· Ltti

1000

4: if (ta > tn) then5: ta←

⌈ta·1000

Ltti

⌉· Ltti

10006: ∆ta← 07: f b← 08: else9: if (ta > tc ∨ f b > 0) then

10: ta← tn11: ∆ta← ts− ta12: f b← 013: else14: ta← tn15: ∆ta← ts− ta16: c←true17: if (s ≥ f b) then18: s← s− f b19: f b← 020: else21: f b← f b− s22: s← 023: end if24: end if25: end if

Warten auf das notwendige Acknowledge Packet des Empfängers verzögert. DieserFall wird in den Zeilen 1-3 berücksichtigt.

Im Normalfall (pdus > 0) wird zunächst die Anzahl f der notwendigen Übertragungs-frames ohne Übertragungsfehler ermittelt. Anschließend wird in der while-Schleifedie Anzahl r der Übertragungsversuche mit Übertragungsfehlern und die Gesamtan-zahl der Übertragungsframes berechnet. Die Übertragung der einzelnen PDUs wird alsBernoulli-Prozess mit p = Lbler simuliert. Die Funktion rand() in Zeile 10 gibt gleich-verteilte Zufallszahlen zwischen 0 und 1 zurück. In der Schleife wird zusätzlich dieAnzahl sr der Versuche berechnet, einen Statusreport im Falle eines Übertragungsfeh-lers zu senden. Diese können ebenfalls mit der Wahrscheinlichkeit Lbler verloren gehen,

58

5.4 Implementierung

Algorithmus 9 Funktion getSendTs(s:uint, ta:double) (Teil 2)

1: pdus←⌈

sLpdu

⌉2: ntti←

⌈pdusLpt

⌉3: ntticompl ←

⌊pdusLpt

⌋4: if (c =true ∧ f b > 0) then5: ntticompl ← ntticompl + 16: end if7: te← ta+ delayTransmitPdus(pdus)

8: if c =true then9: te← te + Ltti

100010: end if11: te← max(te, telast)12: tc← ta + ntticompl · Ltti

100013: f b← f b + (ntti · Lpdu · Lpt)− s)14: ts← ta + ∆ta + (8·s·(1+Lbler)

Lt

15: to ← ta + Lto + Lrtt2

16: if te > to then17: telast ← to18: else19: telast ← te20: end if

return te

so dass die Anzahl der notwendigen Übertragungsversuche für jeden Statusreportgeometrisch verteilt ist.

Im Anschluss an die while-Schleife wird die eigentliche Übertragungsverzögerungd berechnet. Zunächst wird die Verzögerung durch die notwendigen Acknowledge-Pakete ermittelt und anschließend die Übertragungszeit der notwendigen Frames in-klusive Retransmits. Falls bei der Übertragung Paketverluste aufgetreten sind, musszusätzlich noch die Verzögerung durch Statusreports berücksichtigt werden. Dies ge-schieht in den Zeilen 24 - 29.

5.4.4 Value-Recorder

Um eine Auswertung der Simualtionsläufe zu ermöglichen, wurde die ValueRecorder-Klasse entwickelt. Diese nutzt das Qt-Property-System, um die wichtigsten Parameter

59


Algorithmus 10 Funktion delayTransmitPdus(pdus:uint)

1: if pdus = 0 then2: return Lrtt

2 − Ltti

3: end if4: r ← 05: sr ← 06: f ←

⌈pdusLpt

⌉7: while (pdus > 0) do8: pl ← 09: for i = 1 to pdus do

10: if (rand() < Lbler) then11: pl ← pl + 112: end if13: end for14: rp←binDistr(pdus)

15: if (rp > 0) then16: r ← r + 117: f ← f +

⌈rpLpt

⌉18: sr ← geoDistr()

19: end if20: pdus← rp21: end while22: d← (Lrtt − 2 · Ltti) · r+1

223: d← d + f · Ltti

24: if (r > 0) then25: d← d + r ∗ Lrtt

226: if (sr > 1) then27: d← d + (sr− r) · Lrtt

28: end if29: end if30: return d

der drei Module auszulesen. Vor Beginn eines Simulationslaufes werden einer Instanzdieser Klasse Zeiger auf diejenige Objekte übergeben, deren Properties aufgezeichnetwerden sollen. Zusätzlich zu dem Zeiger wird für jedes Objekt eine String-Liste mit denNamen der Properties übergeben, die tatsächlich geschrieben werden sollen. Währendder Aufzeichnung werden dieser Properties dann in einem konfigurierbaren Intervallabgefragt und in eine Comma Separated Values (CSV) Datei geschrieben.

60

6 AUSWERTUNG UND VERGLEICH

Im folgenden Abschnitt werden zunächst die verwendeten Messgrößen beschriebenund deren Auswahl begründet. Anschließend werden die durchgeführten Versuchebeschrieben und deren Ergebnisse analysiert. Abgeschlossen wird dieses Kapitel miteiner zusammenfassenden Bewertung der Ergebnisse.

6.1 Messgrößen und Bewertungskriterien

In [48] beschreiben die Autoren das Problem, die subjektiv empfundene Bildqualitätobjektiv zu messen. Sehr häufig werden die Messgrößen Mean Squared Error (MSE)oder für Videostream auch die Peak Signal to Noise Ratio (PSNR) verwendet. Die-se korrelieren allerdings nicht sehr gut mit der subjektiv wahrgenommen Bildquali-tät, insbesondere bei niedrigen Bitraten (siehe [12] und [29]). Von der InternationalTelecommunication Union (ITU) wurde daher der Mean Opinion Score (MOS) [20]vorgeschlagen. Dieser Wert gibt zwar direkt die von den Zuschauern empfundeneBildqualität wieder, ist aber aufgrund des hohen Aufwands oft nicht einsetzbar. Daherwurden eine Reihe von vorbesserten Messgrößen für die Bildqualität vorgeschlagen,welche auf einer technischen Analyse des Bildmaterials basieren ([30], [49], [4]).

Ein zentrales Problem bei der Übertragung von Live-Streams ist das Auftreten vonBuffer Underruns im Client. Diese führen zu einer ruckelnden Wiedergabe des Video-bildes, was von den meisten Zuschauern als störend empfunden wird (siehe [41]). Diein [24] gemachten Untersuchungen zeigen, dass zusätzlich noch Aspekte wie der Inhaltdes Videos einen Einfluss auf die Qualitätsbeurteilung haben. Je nach Inhalt werdenunterschiedlichen technische Messgrößen eine höhere Bedeutung beigemessen.

Aufgrund der Probleme bei der Reduzierung verschiedener technischer Messgrößenauf eine Messgröße, welche mit dem subjektiven Qualitätsempfinden korreliert, wer-den in dieser Arbeit jeweils vier Messgrößen getrennt betrachtet.

61

6 Auswertung und Vergleich

Diese sind

• die Bitrate des vom Encoder erzeugten Streams,

• der Clientpufferfüllstand,

• die aktuelle Abspielbildrate im Client und

• die Anzahl der aufgetretenen Paketverluste.

Bei allen Versuchen wurde derselbe Encoder und dieselbe Videosequenz verwendet.Daher kann die Streambitrate zur Beurteilung der Encodersteuerung durch die ein-zelnen Algorithmen verwendet werden. Dieser Wert sollte während der gesamtenÜbertragung möglichst nah an der verfügbaren Linkbandbreite sein. Zusammen mitder Anzahl der aufgetretenen Paketverluste gibt die Streambitrate auch einen Hinweisauf die vom Client angezeigte Bildqualität.

Der Clientpufferfüllstand hat darauf keinen direkten Einfluss. Sein Verlauf währendder Übertragung ist allerdings hilfreich für die Analyse der eingesetzten Algorithmen.Dies gilt insbesondere in Verbindung mit der Abspielbildrate. Diese kann zum einendurch Buffer Underruns beinflusst werden, zum anderen aber auch durch die Algo-rithmen für die adaptive Abspielbildrate.

Für alle vier Messgrößen gilt, dass die genauen Werte in den meisten durchgeführtenMessszenarien abhängig von den Zeitpunkten und der Anzahl der Paketverluste sind.Ebenso spielen weitere Faktoren, wie das Scheduling der einzelnen Threads der Si-mualtionsumgebung eine Rolle. Daher werden die genauen Werte bei der Auswertungnicht berücksichtigt. Für die Beurteilung eines Algorithmus sind der Verlauf der Mess-werte und die Relation zu den entsprechenden Messwerten der anderen Algorithmenvon Bedeutung.

6.2 Messszenarien

Messungen mit der Simulationsumgebung wurden anhand definierter Szenarien mitunterschiedlichen Parametereinstellungen durchgeführt. Jede Szenario-Parameter-Kombination wurde mit den drei Rate Control Algorithmen, sowie ohne eingeschal-tete Rate Control durchgeführt. Die Grundeinstellung der Puffergrößen sind für denServer 192 kByte, den Client 224 kByte und für den Link 32 kByte. Der Client beginntmit dem Abspielen des Videos zwei Sekunden nach Erhalt des ersten Datenpakets.Die GOP-Größe ist bei allen Versuchen auf 50 Frames und die Framerate auf 12,5 Hzeingestellt.

62

6.2 Messszenarien

Wenn nicht anders erwähnt, war der zweite Algorithmus für die adaptive Abspiel-bildrate aktiv. Der Wert für die Obergrenze der Encoderbitrate war für alle Algorith-men auf Semax = 0.9 · Lt eingestellt. Die Einstellung der Parameter dieses Algorithmuseswaren α = 0.5, β = −0.5 und γ = 0.5. Die Parameter für den Algorithmus 1 der Re-transmit Rate Control waren auf α = 0.9, β = 1.05 und γ = 0.9 eingestellt. Für dieParameter der Gleichung 5.16 des RF-TRC Algorithmus wurden die Parameter α = 0.5,β = 0.25, γ = 0.25 und k = 3 gewählt. Für die UTRAN-Simualtion im Link-Modulwurden die Einstellungen Ltti = 20 ms, Lpdu = 640 Bit, Lpt = 12 und Lrtt = 120 msverwendet. Alle Versuche dauerten 35 Sekunden, wobei in den ersten 10 Sekundenkeine Parameter verändert wurden.

Präfixe bei Messgrößen wie z.B. k für Kilo sind in dieser Arbeit als SI Präfixe zu in-terpretieren. Der Präfix k bedeutet demnach den Faktor 103 und nicht den sonst imComputer-Umfeld oft verwendeten Faktor 210.

6.2.1 Szenario Flat

In dem Szenario flat wurde das Verhalten der Algorithmen bei konstanter Linkband-breite und konstanter Block Error Rate untersucht. Das Link-Modul war mit den obenaufgeführten Standardwerten konfiguriert, so dass sich eine maximale Linkbandbreitevon 384 kBit/s ergab. Während der gesamten Versuchdauer von 35 Sekunden war dieBlock Error Rate konstant eingestellt. Der Versuch wurde zunächst mit jedem Algo-rithmus bei einer BLER von 0 durchgeführt. Dieser Versuch zeigte das Verhalten derAlgorithmen bei den bestmöglichen Übertragungsbedingungen. Anschließend wurdedieser Versuch mit einer BLER von 0,1 und 0,4 durchgeführt.

Die Ergebnisse für den Versuchslauf mit einer BLER von 0 sind in Abbildung 6.1 dar-gestellt. Der Plot a zeigt den Verlauf der Streambitrate Sst für alle vier Konfigurationen.Der Verlauf der Kurve ist für alle Algorithmen identisch. Die Streambitrate verläuftab Sekunde 7 nahezu konstant bei dem Maximalwert 0, 9 · 384 kBit/s = 345,6 kBit/s.Der Kurvenverlauf steigt zu Beginn nicht senkrecht auf den Maximalwert, da bei derBerechnung der Streambitrate ein gleitender Durchschnittswert verwendet wurde.

Die Plots b und c zeigen den Clientpufferfüllstand und die aktuelle Abspielbildrate.Auf dem Plot c sieht man, dass direkt nach dem Beginn der Wiedergabe die Abspiel-bildrate von dem Sollwert von 12,5 Hz auf über 20 Hz ansteigt und dann wiederzurückkehrt. Ursache für dieses Verhalten ist die adaptive Abspielbildrate. Es war derzweite Algorithmus aktiv, welcher bei der Berechnung des optimalen Pufferfüllstan-des (Gleichung 5.17) auch die durchschnittliche Empfangsdatenrate Cravg einbezieht.Diese war allerdings mit 0 initalisiert, so dass für kurze Zeit dieser Wert weit unter

63


0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35

Str

eam

Bitr

ate

(kbi

t/s)

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35

Clie

nt B

uffe

r Le

vel

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35

Pla

yout

FP

S

Time (s)

c-1

-0.5

0

0.5

1

0 5 10 15 20 25 30 35

Pac

kets

lost

Time (s)

d

no Rate Control Retransmit TFRC RF-TRC

Abbildung 6.1: Szenario Flat, 384 kBit/s Linkbandbreite, Block Error Rate 0

der tatsächlichen Empfangsdatenrate Cr lag. Der optimale Pufferfüllstand Cbopt wurdedementsprechend zu niedrig berechnet und daraufhin zunächst die Abspielbildrateerhöht. Der Effekt der erhöhten Abspielbildrate ist auch auf dem Plot b des Client-pufferfüllstandes zu erkennen. Dieser steigt zunächst auf den erwarteten Wert von2 s·345 kBit/s

8·224 Byte = 0, 38. Sobald der Client mit der Wiedergabe beginnt, sinkt dieser Wertaufgrund der erhöhten Abspielbildrate kurzzeitig ab. Dieser Verlauf der Abspielbildra-te und des Clientpufferfüllstandes ist auch bei allen weiteren Versuchen zu erkennen,bei denen der Algorithmus für die adaptive Abspielbildrate aktiv war.

Erste Unterschiede zwischen den Algorithmen werden bei demselben Versuch miteiner Block Error Rate von 0,3 deutlich. Auffällig ist der Verlauf der Streambitrate fürden TFRC-Algorithmus in Abbildung 6.2. Die Kurven der Streambitraten für die dreianderen Algorithmen verlaufen deckungsgleich zu denen mit einer BLER von 0. DieKurve für den TFRC-Algorithmus dagegen verläuft im Schnitt bei etwa 270 kBit/s,also 75 kBit/s niedriger als zuvor. Zusätzlich schwankt der Kurvenverlauf, währender bei einer BLER von 0 gradlinig verlief. Erklärt wird dieses Verhalten dadurch, dassdie Round Trip Time zum einen gestiegen ist und zum anderen schwankt. Diese wird

64

6.2 Messszenarien

0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35

Str

eam

Bitr

ate

(kbi

t/s)

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35

Clie

nt B

uffe

r Le

vel

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35

Pla

yout

FP

S

Time (s)

c-1

0

1

2

3

4

5

0 5 10 15 20 25 30 35

Pac

kets

lost

Time (s)

d


Abbildung 6.2: Szenario Flat, 384 kBit/s Linkbandbreite, Block Error Rate 0,1

in der TCP-Durchsatzgleichung 5.9 bei der Berechnung der Sendebitrate St des TFRC-Algorithmus verwendet. Aus der Sendebitrate wiederum wird die Encoderbitrate Se

ermittelt, welche direkt die Streambitrate Sst beeinflusst.

Der Clientpufferfüllstand beim Einsatz des TFRC-Algorithmus ist wie auf Plot b zu er-kennen im Schnitt etwas geringer, als der mit den anderen Algorithmen. Dieser ergibtsich aus der weiterhin konstanten Prebufferingzeit von 2 Sekunden und der niedrige-ren Streambitrate. Auffällig auf dem Plot sind die Schwankungen bei allen vier Kurven,die bei einer BLER von 0 noch linear verliefen. Durch die Paketverluste und die dar-aufhin notwendigen Retransmits entsteht ein Jitter in der Übertragungsdatenrate vonLink zu Client. Über den Clientpuffer wird auch die Abspielbildrate durch den Jitterbeeinflusst. Bei einer BLER von 0 sind in Abbildung 6.1 nur sehr geringen Schwan-kungen in der Abspielbildrate auf Plot c zu erkennen. Diese werden im wesentlichendurch das nicht optimale Scheduling des Betriebssystems verursacht. In Abbildung 6.2sind diese Schankungen in der Abspielbildrate schon größer. Dennoch waren dieseSchwankungen noch nicht beim Betrachten des Live-Streams zu bemerken.

65


0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35

Str

eam

Bitr

ate

(kbi

t/s)

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35

Clie

nt B

uffe

r Le

vel

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35

Pla

yout

FP

S

Time (s)

c 0

100

200

300

400

500

600

0 5 10 15 20 25 30 35

Pac

kets

lost

Time (s)

d


Abbildung 6.3: Szenario Flat, 384 kBit/s Linkbandbreite, Block Error Rate 0,4

Das Szenario wurde schließlich noch mit einer Block Error Rate von 0,4 untersucht. Oh-ne den Einsatz einer adaptive Encodersteuerung wird auch in diesem Fall ein Streammit konstant 354 kBit/s erzeugt (siehe Abbildung 6.3 Plot a). Da die durchschnittli-che Senderate des Links auf ca. (1 − 0, 4) · 384kBit/s = 230,4 kBit/s gesunken ist,kommt es zu Buffer Overflows im Link und dementsprechend zu Paketverlusten. Diesist deutlich auf Plot d zu erkennen. Zu Buffer Underruns kommt es ohne adaptiveEncodersteuerung allerdings nur für etwa 5 Sekunden zu Beginn der Wiedergabe. AufPlot b ist zu sehen, dass der Clientpuffer leerläuft und auf Plot c erkennt man, das dieAbspielbildrate bei Sekunde 4 und Sekunde 7 jeweils auf einen Wert von unter 2 Hzabsinkt. Anschließend schwankt die Abspielbildrate um einen Wert von 8 Hz mit stei-gender Tendenz. Diese Schwankungen sind ebenfalls im Pufferfüllstand erkennbar.

Sowohl der Retransmit-Algorithmus, als auch die TFRC senken kurz nach Beginn derWiedergabe im Client die Sendebitrate und somit folglich auch die Streambitrate starkab (Plot a). Hierdurch wird allerdings der Clientpufferfüllstand ebenfalls gesenkt, wasin Verbindung mit dem hohen Jitter in der Empfangsdatenrate des Client zu massi-ven Buffer Underruns führt. Der Verlauf des Clientpufferfüllstands auf Plot b und der

66

6.2 Messszenarien

Abspielbildrate auf Plot c zeigen dies deutlich. Mit der TFRC dauert es bis zur Sekun-de 17, bis die Streambitrate nicht mehr weiter sinkt und daraufhin der Pufferfüllstandsteigt. Anschließend treten keine Bufferunderruns bei der TFRC auf, im Gegensatzzum Retransmit-Algorithmus. Wird dieser verwendet, so wird der Stream bereits abSekunde 12 mit einer akzeptablen Abspielbildrate von 7-10 Hz ausgegeben. Allerdingstreten während der gesamten Übertragung massive Paketverluste auf. Bei einer BlockError Rate von 0,4 sind weder der Retransmit-Algorithmus noch die TFRC in der Lageeine akzeptable Streamwiedergabe zu ermöglichen.

Der einzige Algorithmus, der eine nutzbare Streamwiedergabe ermöglicht, ist der RF-TRC-Algorithmus mit der neu entwickelten Encodersteuerung. Die Streambitrate wirdbereits frühzeitig gesenkt und ändert sich ab Sekunde 10 kaum noch. Auf den Plots bund c ist zu sehen, dass nur im Bereich von Sekunde 5 bis 7 Buffer Underruns auftreten.Anschließend steigen sowohl der Clientpufferfüllstand, als auch die Abspielbildratelangsam an. Für die Wiedergabe des Streams besonders wichtig ist, das während dergesamten Übertragung kein Paketverlust auftritt.

Zusammengefasst lassen die Ergebnisse dieses Versuchs folgende Aussagen zu:

• Der durch eine BLER > 0 verursachte Jitter in der Empfangsdatenrate des Cli-ents macht sich direkt im Clientpufferfüllstand bemerkbar. Über die adaptiveAbspielbildrate werden die Schwankungen im Pufferfüllstand auch auf die Ab-spielbildrate übertragen.

• Da der TFRC-Algorithmus die Round Trip Time auf dem Link mit in die Be-rechnung der Senderate einfließen lässt, reagiert dieser wesentlich stärker aufsteigende Block Error Rates, als die anderen Algorithmen.

• Einzig der RF-TRC-Algorithmus mit der neuen Encodersteuerung ist in der Lagebei einer BLER von 0,4 noch eine akzeptable Wiedergabe des Streams zu ermög-lichen.

6.2.2 Szenario Block Error Rate

In diesem Szenario wird die Reaktion der Algorithmen auf einen Error Burst unter-sucht. Die Dauer des Burst wurde auf 10 Sekunden gesetzt, so dass die veränderteSituation nicht vollständig durch die Puffer kompensiert werden kann. Während desgesamten Szenarios bleibt die eingestellte Linkbandbreite bei 384 kBit/s. Die BlockError Rate ist zu Beginn des Szenarios auf 0 eingestellt. Bei Sekunden 10 wird sie auf0,1 bzw. 0,3 erhöht und anschließend bei Sekunde 20 wieder auf 0 gesenkt.

67


0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Str

eam

Bitr

ate

(kbi

t/s)

BLE

R

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt B

uffe

r Le

vel

BLE

R

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Pla

yout

FP

S

BLE

R

Time (s)

c 0

1

2

3

4

5

6

7

8

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Pac

kets

lost

BLE

R

Time (s)

d

no Rate Control Retransmit TFRC RF-TRC Link BLER

Abbildung 6.4: Szenario Block Error Rate, 384 kBit/s Linkbandbreite, Block Error Rate0,1 bei Sekunde 10–20

In Abbildung 6.4 sind die Messergebnisse für den Fall eines Anstiegs der Block Er-ror Rate auf 0,1 dargestellt. Man erkennt auf Plot a, dass mit Ausnahme des TFRC-Algorithmus alle Algorithmen die Streambitrate auf dem vorgesehenen Maximum hal-ten. Der TFRC Algorithmus reagiert hier, wie zuvor schon festgestellt, auf die erhöhteRound Trip Time und senkt dementsprechend die Streambitrate ab. Der Retransmit-Algorithmus reagiert nicht, da bei diesem Durchlauf kein Paketverlust aufgetreten ist.Mit dem RF-TRC Algorithmus dagegen wird der kurzzeitige Abfall in der maximalenLinkdatenrate widererwartend doch vollständig durch Server- und Netzwerkpufferabgefangen.

Betrachtet man den Clientpufferfüllstand auf Plot b, so zeigt sich wieder dessen Abhän-gigkeit zu der BLER auf dem Link. Während der erhöhten BLER von Sekunde 10 - 20treten kleine Schwankungen im Füllstand des Clientpuffers auf. Der Pufferfüllstandmit dem TRFC-Algorithmus sinkt in dem Zeitraum zusätzlich noch ab. Die Abspiel-zeit des sich im Clientpuffer befindlichen Streams bleibt weiterhin bei 2 Sekunden, dieStreambitrate wurde allerdings gesenkt.

68

6.2 Messszenarien

0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Str

eam

Bitr

ate

(kbi

t/s)

BLE

R

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt B

uffe

r Le

vel

BLE

R

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Pla

yout

FP

S

BLE

R

Time (s)

c 0

20

40

60

80

100

120

140

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Pac

kets

lost

BLE

R

Time (s)

d

no Rate Control Retransmit TFRC RF-TRC Link BLER

Abbildung 6.5: Szenario Block Error Rate, 384 kBit/s Linkbandbreite, Block Error Rate0,3 Sek 10–20

Auf das Absinken des Clienpufferfüllstandes reagiert der Algorithmus für die adap-tive Abspielbildrate. Man erkennt auf Plot c, dass der Verlauf der Kurve der Abspiel-bildrate des TFRC-Algorithmus dem des Clientpufferfüllstandes folgt. Sinkt der Puff-erfüllstand, so wird die Abspielbildrate ebenfalls gesenkt, um wieder den berechnetenoptimalen Pufferfüllstand zu erhalten. Analog dazu verhält es sich bei steigendem Puf-ferfüllstand. Auf Plot b ist zu sehen, dass nach Sekunden 20 der Clientpufferfüllstandmit dem TFRC-Algorithmus sogar über den Normalwert hinaus ansteigt. Begründetist dies durch die adaptive Abspielbildrate. Zwischen Sekunde 10 und 20 wurde dieAbspielbildrate kurzzeitig gesenkt, wodurch sich der Pufferungszeitraum im Client-puffer erhöht. Wird dann wieder mit der anfänglichen Streambitrate gesendet, so steigtder Pufferfüllstand dementsprechend über den Ausgangswert. Durch ein erhöhen derAbspielbildrate wird er dann wieder auf den berechneten Optimalwert gesenkt.

69


Dieser Effekt ist noch wesentlich deutlicher bei einer Block Error Rate von 0,3 in Ab-bildung 6.5 zu sehen. Ebenfalls in der Abbildung zu sehen ist, dass der Clientpuffer-füllstand (Plot b) direkt bei Sekunde 10 abfällt, die Streambitrate (Plot a) aber erste ca.2 Sekunden später gesenkt wird. Während dieses Zeitraums ist der Netzwerkpuffernoch nicht vollständig gefüllt. Erst anschließend kann es zu Buffer Overflows undsomit Paketverlusten kommen.

Während es bei einem Anstieg auf ein BLER von 0,1 es nur ohne Rate Control zu einemPaketverlust kam, treten bei einer BLER von 0,3 mit allen Algorithmen außer dem RF-TRC Paketverluste auf. Mit dem TRFC-Algorithmus geht nur eine geringe Anzahl vonPaketen verloren, da dieser die Streambitrate schnell anpasst. Wesentlich langsamerwird diese durch den Retransmit-Algorithmus gesenkt. Daher treten deutlich mehrPaketverluste über einen längeren Zeitraum auf. Wie schon im Szenario Flat festgestellt,wird durch die hohe Round Trip Time die Effektivität des Retransmit-Algorithmusstark beeinträchtigt.

Als Schlussfolgerung aus diesem Versuch ergibt sich:

• Kleine Anstiege der Block Error Rate werden vom RF-TRC Algorithmus durchServer- und Netzwerkpuffer kompensiert.

• Durch die adaptive Abspielbildrate wird der Pufferungszeitraum im Clientpuffererhöht, so dass der Pufferfüllstand über den Normalwert ansteigen kann.

6.2.3 Szenario Bitrates

In den beiden vorhergehenden Szenarien wurden die Reaktion der Algorithmen aufBlock Error Rates einer bestimmten Höhe bzw. kurzzeitige Anstiege der Block ErrorRate untersucht. Bei einer UMTS Funkverbindung können Sender und Empfänger dieÜbetragungsparameter aushandeln und dadurch die verfügbare Bandbreite und dieBlock Error Rate beeinflussen. Eine Änderung von Übertragungsparametern kann zumBeispiel erfolgen, wenn die gemessene Block Error Rate einen definierten Grenzwertüberschreitet, oder wenn ein weiterer Teilnehmer in derselben Funkzelle aktiv wird.In dem hier untersuchten Szenario wird, analog zur Änderung der Block Error Rateim Szenario Block Error Rate, zwischen Sekunde 10 und 20 die Linkbandbreite halbiert,indem die PDU-Größe von 640 Bit auf 320 Bit gesenkt wird.

Abbildung 6.6 zeigt den Verlauf der Kurven, wenn die Block Error Rate des Linksauf 0 eingestellt ist. Da unabhängig vom eingesetzten Rate Control Algorithmus dieEncoderbitrate auf die eingestellt Linkbandbreite begrenzt wird, ist der Kurvenverlaufmit allen vier Algorithmen nahezu identisch.

70

6.2 Messszenarien

0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Str

eam

Bitr

ate

(kb

it/s)

Link

Ban

dwid

th

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Clie

nt B

uffe

r Le

vel

Link

Ban

dwid

th

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pla

yout

FP

S

Link

Ban

dwid

th

Time (s)

c-1

-0.5

0

0.5

1

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pac

kets

lost

Link

Ban

dwid

th

Time (s)

d

no Rate Control Retransmit TFRC RF-TRC Link Bandwidth

Abbildung 6.6: Szenario Bitrate, Block Error Rate 0

Auf dem Plot c ist deutlich zu sehen, dass nach der Halbierung der Linkbandbrei-te die Abspielbildrate kurzzeitig sehr stark erhöht und danach schnell bis unter denNennwert von 12,5 Hz gesenkt wird. Die Information über die Linkbandbreite wirdebenfalls durch die adaptive Abspielrate genutzt, so dass diese bereits einen neuenoptimalen Clientpufferfüllstand berechnet, während der Puffer noch einen Stream miteiner wesentlich höheren Bitrate enthält. Um den scheinbar zu hohen Pufferfüllstandzu kompensieren wird daher die Abspielbildrate erhöht. Da zu diesem Zeitpunkt be-reits ein Stream mit der halben Bitrate gesendet wird, fällt der Clientpufferfüllstandstark ab und unterschreitet durch die zuvor erhöhte Abspielbildrate sogar bei Sekunde12 den Werte, der sich durch die zwei Sekunden Prebuffering ergibt. Dies hat dann auchdas kurzzeitige Absenken der Abspielbildrate auf unter 12,5 Hz durch die adaptiveAbspielrate zur Folge.

71


0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Str

eam

Bitr

ate

(kbi

t/s)

Link

Ban

dwid

th

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Clie

nt B

uffe

r Le

vel

Link

Ban

dwid

th

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pla

yout

FP

S

Link

Ban

dwid

th

Time (s)

c-50

0

50

100

150

200

250

300

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pac

kets

lost

Link

Ban

dwid

th

Time (s)

d

no Rate Control Retransmit TFRC RF-TRC Link Bandwidth

Abbildung 6.7: Szenario Bitrate, Block Error Rate 0,3

Abbildung 6.7 zeigt daselbe Szenario bei einer Block Error Rate von 0,3. Bis zu Sekun-de 10 entspricht der Verlauf der Streambitrates (Plot a) für alle Rate Control Algorith-men daher in etwa dem Verlauf der Streambitrates im Szenario Flat mit einer BlockError Rate von 0,4 (Abbildung 6.3). Dies gilt ebenfalls für den Clientpufferfüllstand, dieAbspielbildrate und die Anzahl der Paketverluste. Auch im weiteren Versuchsverlaufnach dem Absenken der Linkbandbreite bei Sekunde 10 sind kaum Unterschiede zudem Szenario Flat mit einer Block Error Rate von 0,4 zu erkennen. Ausgenommen hier-von ist zum einen der Verlauf der Streambitrate ohne Rate Control, der dem Verlauf indieses Szenario mit einer Block Error von 0 entspricht. Zum anderen steigt die Stream-bitrate des Retransmit-Algorithmus nach Sekunde 20 kurzzeitig an. Bei Sekunde 20wird die Linkbandbreite wieder auf den Ausgangswert zurückgestellt, was auch demServer mitgeteilt wird. Die Implementierung des Retransmit-Algorithmus setzt darauf-hin die Sendebitrate und somit auch die Encoderbitrate auf den entsprechenden Wert.Die höhere Streambitrate führt allerdings wieder zu Paketverlusten, was auf Plot dbei Sekunde 24 zu erkennen ist. Daraufhin werden Sende- und Streambirate wiedergesenkt.

72

6.2 Messszenarien

Als Erkenntnisse aus diesem Versuch lässt sich festhalten:

• Der Algorithmus für die adaptive Abspielbildrate reagiert zu schnell auf Ände-rungen in der Linkbandbreite und erhöht die Abspielbildrate, obwohl dies nichtnotwendig ist.

• Der Einfluss der Block Error Rate auf das Verhalten der Algorithmen dominiertden Einfluss von Änderungen in der maximalen Linkbandbreite.

6.2.4 Effekt der adaptiven Abspielbildrate

In den bisherigen Versuchen war immer der zweite Algorithmus für die adaptive Ab-spielbildrate aktiv und hat dort unter bestimmten Bedingungen zu unerwünschtenSchwankungen in der Abspielbildrate geführt. Der positive Effekt der adaptiven Ab-spielbildrate wird deutlich, wenn man das Szenario Block Error Rate mit einer BlockError Rate von 0,3 einmal mit und einmal ohne diesen Algorithmus vergleicht. DieAbbildungen 6.8 bis 6.11 zeigen den Verlauf des Clientpuffer-Füllstandes und der Ab-spielbildrate für die einzelnen Rate Control Algorithmen.

Zusätzlich wurden diese Versuche auch mit dem ersten Algorithmus für die adaptiveAbspielgeschwindigkeit durchgeführt. Bei diesem war die Einstellung der ParameterC f psmin = 0, 5 · S f ps, C f psmax = 1, 5 · S f ps, α = 0, 2, β = 1, γ = 0, 9 und δ = 1, 1.

Ohne eine Rate Control schafft es der erste Algorithmus für die adaptive Abspielbildra-te die sonst auftretenden Buffer Underruns zu minimieren, der zweite Algorithmusdiese sogar komplett zu verhindern. Betrachtet man jedoch dazu die in Abbildung 6.5aufgezeichnete Fehlerrate, so hat die adaptive Abspielbildrate zwar einen positivenEffekt, aber die hohe Anzahl an Paketverlusten stellt diesen weit in den Hintergrund.

Die drei Rate Control Algorithmen passen nach einer gewissen Reaktionszeit die Stre-ambitrate an die verfügbare Linkdatenrate an. Das Absenken der Streambitrate senktden durchschnittlichen Clientpufferfüllstand, so das der erhöhte Jitter in der Emp-fangsdatenrate des Clients wesentlich eher zu Buffer Underruns führen kann. In denAbbildungen 6.9, 6.10 und 6.11 erkennt man, dass ohne aktive adaptive Abspielbildrateder Clientpuffer-Füllstand bei allen drei Algorithmen auf 0 absinkt. Durch den erstenAlgorithmus wird dieser Effekt jedoch wenigstens zu einem Teil kompensiert und derEinsatz des zweiten Algrithmus verhindert auch in diesen drei Fällen ein Leerlaufendes Clientpuffers.

Nachdem die Block Error Rate bei Sekunde 20 wieder auf den Wert 0 zurückgesetztwurde, steigt bei allen drei Congestion Control Algorithmen der Clientpuffer-Füllstandmit dem zweiten Algorithmus für die adaptive Abspielbildrate stärker an, als mit dem

73


0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt P

layo

ut F

PS

BLE

R

Time (s)

a

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt B

uffe

r Le

vel

BLE

R

Time (s)

b

without dynFPS with dynFPS 1 with dynFPS 2 Link BLER

Abbildung 6.8: Adaptive Abspielbildrate, keine Rate Control, Block Error Rate 0,3 beiSekunde 10–20

ersten oder ohne adaptive Abspielbildrate. Besonders deutlich wird dies in Kombina-tion mit dem RF-TRC Algorithmus in Abbildung 6.11. Dementsprechend steigt auchdie Abspielbildrate stärker und vor allem für einen längeren Zeitraum an.

Ein weiterer Vorteil der adaptiven Abspielbildrate ist, dass durch das Halten des Puf-ferfüllstandes auf dem Wert, der sich aus der eingestellten Prebufferingzeit und deraktuellen Streambitrate ergibt, der durch den Clientpuffer verursachte Delay nahezukonstant bleibt.

Die Untersuchungsergebnisse dieser Versuche führen also zu folgenden Aussagen:

• Die adaptive Abspielbildrate vermindert die Wahrscheinlichkeit von Buffer Un-derruns im Client.

• Der durch den Clientpuffer verursachte Delay wird nahezu auf der gewähltenPrebufferingzeit gehalten.

74

6.2 Messszenarien

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt P

layo

ut F

PS

BLE

R

Time (s)

a

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt B

uffe

r Le

vel

BLE

R

Time (s)

b


Abbildung 6.9: Adaptive Abspielbildrate, Retransmit, Block Error Rate 0,3 bei Sekunde10–20

6.2.5 Effekt der Bandbreiteninformation durch den Link

Eine der eingesetzten Optimierungen ist, dass sowohl Client, als auch Server überÄnderungen in der Linkbandbreite informiert werden. In diesem Versuch soll nun derEinfluss dieser Optimierung untersucht werden. Hierzu wurde das Szenario Bitrate beieiner Block Error Rate von 0 für alle Rate Control Algorithmen einmal mit und einmalohne die Bandbreiteninformation durchgeführt. Die Parameter des ersten Algorithmusfür die adaptive Abspielgeschwindigkeit waren wie im Versuch 6.2.4 eingestellt.

Zusätzlich wurde der Versuch auch noch ohne eine Rate Control durchgeführt. Das Er-gebnis ist in Abbildung 6.12 dargestellt. Der Verlauf der Streambitrate ist wie erwartet.Ohne die Bandbreiteninformation bleibt diese konstant bei den anfänglich eingestellten345 kBit/s. Mit der Bandbreiteninformation wird die Obergrenze für die Sendebitrateentsprechend der Linkbandbreite geändert und somit auch die Streambitrate selber. Damit der aktiven Optimierung jederzeit höchsten mit 90% der Linkbandbreite gesendetwird und die Block Error Rate bei 0 ist, treten in diesem Fall keine Paketverluste auf.

75


0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt P

layo

ut F

PS

BLE

R

Time (s)

a

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt B

uffe

r Le

vel

BLE

R

Time (s)

b


Abbildung 6.10: Adaptive Abspielbildrate, TFRC, Block Error Rate 0,3 bei Sekunde10–20

Ohne die Optimierung wird zwischen Sekunde 10 und 20 der Stream weiterhin mitder Ausgangsbitrate kodiert. Da die Linkbandbreite halbiert wurde, kommt es zu ei-ner hohen Anzahl von Buffer Overflows im Link und somit zu Paketverlusten. DieVerzögerung beim Anstieg der Paketverluste auf Plot d hat zwei Ursachen. Zum einenwar der Linkpufferfüllstand bis Sekunde 10 nur sehr gering, da die Sendebitrate desServer unter der Linkbitrate und die Block Error Rate bei 0 waren. Daher treten erstnach einer Verzögerung Buffer Overflows im Link auf. Zum anderen werden Paketver-luste vom Client erst beim Auslesen aus dem Clientpuffer erkannt, also mit einer derPrebufferingzeit von 2 Sekunden entsprechenden Verzögerung.

Der Verlauf der Kurve für die Abspielbildrate mit Bandbreiteninformation wurde be-reits in Abschnitt 6.2.4 erklärt. Ohne die Optimierung wird dem Client keine neueLinkbandbreite mitgeteilt und dementsprechend berechnen die Algorithmen für dieadaptive Abspielbildrate im Client nach Sekunde 10 keine neuen optimalen Pufferfüll-stand und die kurze Spitze in bei der Abspielbildrate bleibt aus.

76

6.2 Messszenarien

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt P

layo

ut F

PS

BLE

R

Time (s)

a

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

0.2

0.4

0.6

0.8

1

Clie

nt B

uffe

r Le

vel

BLE

R

Time (s)

b


Abbildung 6.11: Adaptiven Abspielbildrate, RF-TRC, Block Error Rate 0,3 bei Sekunde10–20

Auffällig bei den Versuchsergebnisse für den Retransmit Algorithmus (Abbildung 6.13ist, dass ohne die Bandbreiteninformation die Fehlerrate mit dem zweiten Algorithmuszur adaptiven Steuerung der Abspielbildrate wesentlich geringer ist, als mit dem erstenAlgorithmus. Die Erklärung hierfür ist das Leerlaufen des Clientpuffers bei Sekunde 17mit dem ersten Algorithmus für die adaptive Abspielbildrate. Paketverluste könnendadurch nicht mehr durch ein Retransmit korrigiert werden.

Zusammengenommen bringt dieser Versuch folgende Erkenntnisse:

• Unabhängig von der eingesetzten Rate Control werden durch das Verwenden derBandbreiteninformation Paketverluste durch Änderungen in der Linkbandbreiteverhindert.

• Der Clientpuffer bleibt mit Bitrateninformation nahe dem durch das Prebufferingbestimmten optimalen Füllstand.

77


0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Str

eam

Bitr

ate

(kbi

t/s)

Link

Ban

dwid

th

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Clie

nt B

uffe

r Le

vel

Link

Ban

dwid

th

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pla

yout

FP

S

Link

Ban

dwid

th

Time (s)

c 0

20

40

60

80

100

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pac

kets

lost

Link

Ban

dwid

th

Time (s)

d

without Bandwidth Info, dynFPS 1without Bandwidth Info, dynFPS 2

with Bandwidth Info, dynFPS 2Link Bandwidth

Abbildung 6.12: Bandbreiteninformation, keine Rate Control, halbe Bandbreite bei Se-kunde 10–20

6.3 Versuchsergebnisse

Alle Versuchergebnisse zusammengenommen zeigen, dass das Konzept des adaptivenUnicast Live-Streamings nicht nur möglich ist, sondern auch sehr effektiv auf schwan-kende Datenraten und erhöhten Jitter in der Empfangsdatenrate des Clients reagiert.Insbesondere die Kombination von RF-TRC mit der neu entwickelten Encodersteue-rung und dem zweiten Algorithmus für die adaptive Abspielbildrate liefern sehr guteErgebnisse, während der TFRC Algorithmus die Encoderbitrate unnötig tief senkt. Beieiner hohen Block Error Rate ist der Retransmit-Algorithmus nicht mehr in der Lage,Paketverluste zu verhindern. Beide Algorithmen zur Adaption der Abspielbildratebringen einen nachweisbaren Vorteil gegenüber einer konstanten Abspielbildrate imClient. Die Einbeziehung der aktuellen Linkbandbreite in Algorithmen auf Server- undClientseite verbessert das Gesamtergebnis ebenfalls.

78


0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Str

eam

Bitr

ate

(kbi

t/s)

Link

Ban

dwid

th

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Clie

nt B

uffe

r Le

vel

Link

Ban

dwid

th

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pla

yout

FP

S

Link

Ban

dwid

th

Time (s)

c 0

10

20

30

40

50

60

70

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pac

kets

lost

Link

Ban

dwid

th

Time (s)

d



Abbildung 6.13: Bandbreiteninformation, Retransmit, halbe Bandbreite bei Sekunde10–20

79


0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Str

eam

Bitr

ate

(kbi

t/s)

Link

Ban

dwid

th

Time (s)

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Clie

nt B

uffe

r Le

vel

Link

Ban

dwid

th

Time (s)

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pla

yout

FP

S

Link

Ban

dwid

th

Time (s)

c 0

5

10

15

20

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pac

kets

lost

Link

Ban

dwid

thTime (s)

d



Abbildung 6.14: Bandbreiteninformation, TFRC, halbe Bandbreite bei Sekunde 10–20

80


0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Bitr

ate

(kbi

t/s)

Link

Ban

dwid

th

Time (s)

Stream Bitrate

a 0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Buf

fer

Leve

l

Link

Ban

dwid

th

Time (s)

Client Buffer Level

b

0

5

10

15

20

25

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

FP

S

Link

Ban

dwid

th

Time (s)

Playout FPS

c 0

0.5

1

1.5

2

2.5

3

0 5 10 15 20 25 30 35 0

50

100

150

200

250

300

350

400

Pac

ket L

oss

Link

Ban

dwid

th

Time (s)

Packets lost

d



Abbildung 6.15: Bandbreiteninformation, RF-TRC, halbe Bandbreite bei Sekunde 10–20

81

7 ZUSAMMENFASSUNG

Im Rahmen dieser Arbeit wurde ein System für die adaptive Übertragung eines UnicastLive-Streams über einen UMTS-Datenkanal entwickelt werden. Dieses System solltesowohl die Übertragung, als auch den Videostream selber an die verfügbare Datenratedes Übertragungskanals anpassen. Die durchgeführten Analysen zeigen, dass mittelsoptimierter Algorithmen das erwünschte Ergebnis erreicht werden kann. Selbst bei ei-ner Paketverlustrate von 0,3 wird der Live-Stream noch ruckelfrei und ohne Bildfehlerabgespielt, wohingegen ohne adaptive Steuerung eine normale Wiedergabe nicht mehrmöglich ist.

Von den drei verwendeten Rate Control Algorithmen Retransmit, TFRC und RF-TRChat sich letzterer als besonders gut erwiesen, da er sowohl Paketverluste vollständigverhindert, als auch die verfügbare Bandbreite optimal nutzt. Zusätzlich wurde gezeigt,dass der RF-TRC-Algorithmus für das Live-Streaming vereinfacht werden kann. Die imOriginalalgorithmus verwendete OBSN-RTCP-Erweiterung ist für diese Anwendungnicht notwendig.

Während bei den Algorithmen Retransmit und TFRC die Encoderbitrate als gleitenderDurchschnitt der sich ändernden Sendebitrate ermittelt wurde, ist für den RF-TRCeine spezielle Gleichung zur Berechnung der Encoderbitrate entwickelt worden. Die-se Gleichung berücksichtigt sowohl die durchschnittliche Sendebitrate, als auch denFüllstand des Serverpuffers. Der über diese Gleichung ermittelte Wert für die Enco-derbitrate ist robust gegenüber geringfügigen Schwankungen in der Link-Bandbreite.Dennoch reagiert er schnell und präzise auf große Änderungen, die nicht mehr überdie Puffer in Server und Netzwerk abgefangen werden können.

Unabhängig von dem eingesetzten Rate Control Algorithmus wurde die Encoderbi-trate auf die aktuelle, maximale Linkbandbreite beschränkt. Hierzu wurden in dereingesetzten Simulationsumgebung sowohl dem Server-, als auch Client-Modul dieLinkbandbreite mitgeteilt. Auf Clientseite wird diese Information für die neu entwi-ckelte adaptive Steuerung der Abspielbildrate verwendet, durch die Buffer Underrunsund somit ein Ruckeln der Wiedergabe minimiert oder sogar ganz verhindert werdenkönnen.

83

7 Zusammenfassung

Ausblick

Anhand der Messergebnisse der einzelnen Versuche lassen sich Aussagen über die tech-nische Qualität des vom Client empfangen Videostreams machen. Wie schon zu Beginnder Beschreibung der Versuchsergebnisse dargestellt, lassen sich diese Messergebnissenicht so einfach auf die subjektive Qualitätsbeurteilung von Zuschauern übertragen.Sie beschreiben die technische Dienstqualität (QoS). Für die Akzeptanz eines solchenSystem sind allerding noch weitere Faktoren von Bedeutung. Eine weitere Untersu-chung unter dem Gesichtspunkt der Quality of Experience (QoE) (siehe [42] oder [32])erscheint daher sinnvoll. In diesem Zusammenhang sollte eine Untersuchung ähnlichder in [24] beschriebenen durchgeführt werden.

Das verwendete Link-Modell für die UMTS-Funkstrecke ist relativ einfach. Es wurdenbisher keine Vergleichsuntersuchungen über eine reale UMTS-Funkverbindung durch-geführt, um festzustellen, ob dieses Modell ausreichend genau ist. Ebenso wurde nurdie Übertragung eines einzelnen Streams untersucht. In einem realen UMTS-Funknetzist es allerdings wahrscheinlich, dass mehr als ein Stream innerhalb einer Funkzelleübertragen wird und weitere Kommunikation stattfindet.

Eine offensichtliche Schwäche des untersuchten Ansatzes ist die Verwendung einesvollständigen Encoders pro Nutzer. Insbesondere bei dem Einsatz moderner Kodier-verfahren wie H.264/MPEG-4 AVC ist ein enormer Ressourcenaufwand notwendig,um eine größere Anzahl von Zuschauern zu versorgen. Abhilfe schaffen könnten hierder Einsatz von Transcoding-Techniken [45]. Ebenfalls ressourcensparender wäre derEinsatz von Multi-Layer Encoding [36], wie zum Beispiel Fine Granularity Scalabili-ty (FGS) des MPEG-4-Standards [35]. Über Rate Shaping Verfahren [7] könnte dieserMulti-Layer Stream anschließend effizient an die Bandbreite der einzelnen Zuschauerangepasst werden.

84

ABBILDUNGSVERZEICHNIS

2.1 Enwicklung der UMTS-Teilnehmerzahl . . . . . . . . . . . . . . . . . . . 62.2 Vergleich der Datenübertragung via Unicast und Broadcast . . . . . . . . 7

3.1 Struktur eines GSM-Netzes . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Struktur eines UMTS-Netzes . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Die Funkübertragungsverfahren FDMA, TDMA und CDMA . . . . . . . 133.4 Logische Kanäle der UMTS RLC-Schicht [47] . . . . . . . . . . . . . . . . 16

4.1 Beziehung zwischen I-, P- und B-Frames . . . . . . . . . . . . . . . . . . . 204.2 Aufbau eines TM5 Rate Controllers . . . . . . . . . . . . . . . . . . . . . 22

5.1 Schematische Darstellung des Servers . . . . . . . . . . . . . . . . . . . . 245.2 Screenshot des Frontends . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.3 Beispiel eines Flussgraphen . . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Verteilter Flussgraph einer NMM Anwendung [44] . . . . . . . . . . . . 425.5 Das Signal-Slot-Konzept des Qt-Frameworks [43] . . . . . . . . . . . . . 465.6 Komponenten der Simulationsumgebung und deren Verteilung . . . . . 495.7 Vereinfachtes Klassendiagramm des Server-Moduls . . . . . . . . . . . . 505.8 Vereinfachtes Klassendiagramm des Client-Moduls . . . . . . . . . . . . 545.9 Schematischer Aufbau der Linksimulation . . . . . . . . . . . . . . . . . 56

6.1 Szenario Flat, 384 kBit/s Linkbandbreite, Block Error Rate 0 . . . . . . . 646.2 Szenario Flat, 384 kBit/s Linkbandbreite, Block Error Rate 0,1 . . . . . . 656.3 Szenario Flat, 384 kBit/s Linkbandbreite, Block Error Rate 0,4 . . . . . . 666.4 Szenario Block Error Rate, 384 kBit/s Linkbandbreite, Block Error Rate

0,1 bei Sekunde 10–20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.5 Szenario Block Error Rate, 384 kBit/s Linkbandbreite, Block Error Rate

0,3 Sek 10–20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.6 Szenario Bitrate, Block Error Rate 0 . . . . . . . . . . . . . . . . . . . . . . 716.7 Szenario Bitrate, Block Error Rate 0,3 . . . . . . . . . . . . . . . . . . . . . 726.8 Adaptive Abspielbildrate, keine Rate Control, Block Error Rate 0,3 bei

Sekunde 10–20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

85

Abbildungsverzeichnis

6.9 Adaptive Abspielbildrate, Retransmit, Block Error Rate 0,3 bei Sekunde10–20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.10 Adaptive Abspielbildrate, TFRC, Block Error Rate 0,3 bei Sekunde 10–20 766.11 Adaptiven Abspielbildrate, RF-TRC, Block Error Rate 0,3 bei Sekunde

10–20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.12 Bandbreiteninformation, keine Rate Control, halbe Bandbreite bei Se-

kunde 10–20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.13 Bandbreiteninformation, Retransmit, halbe Bandbreite bei Sekunde 10–20 796.14 Bandbreiteninformation, TFRC, halbe Bandbreite bei Sekunde 10–20 . . 806.15 Bandbreiteninformation, RF-TRC, halbe Bandbreite bei Sekunde 10–20 . 81

86

TABELLENVERZEICHNIS

3.1 UMTS Frequenzbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.1 Servervariablen und -konstanten . . . . . . . . . . . . . . . . . . . . . . . 245.2 Linkvariablen und -konstanten . . . . . . . . . . . . . . . . . . . . . . . . 255.3 Clientvariablen und -konstanten . . . . . . . . . . . . . . . . . . . . . . . 265.4 Mit dem Übertragungsprotokoll gesendete Informationen . . . . . . . . 265.5 Parameter der TCP Durchsatzgleichung . . . . . . . . . . . . . . . . . . . 325.6 Hauptmodule des Qt-Frameworks . . . . . . . . . . . . . . . . . . . . . . 455.7 Globale Variablen der Link-Simulation . . . . . . . . . . . . . . . . . . . . 57

87

ALGORITHMENVERZEICHNIS

1 Retransmit: Smax nach Empfang eines Receiver Reports RR . . . . . . . . 312 Retransmit: Empfang eines RTP Pakets auf clientseite . . . . . . . . . . . 313 TFRC: Berechnung der n Loss Event Gewichte . . . . . . . . . . . . . . . 334 TFRC: Berechnung der Loss Event Rate p im Client . . . . . . . . . . . . 335 TFRC: Berechnung von X nach Erhalt eines RTCP RR . . . . . . . . . . . 346 Erster Algorithmus zur Berechnung von C f ps . . . . . . . . . . . . . . . . 367 Scheduler im RTP-Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 Funktion getSendTs(s:uint, ta:double) (Teil 1) . . . . . . . . . . . . . 589 Funktion getSendTs(s:uint, ta:double) (Teil 2) . . . . . . . . . . . . . 5910 Funktion delayTransmitPdus(pdus:uint) . . . . . . . . . . . . . . . . . 60

89

LITERATURVERZEICHNIS

[1] 3GPP: Multicast Service (MBMS), 3GPP TS 22.146 – Release 6 Services and SystemsAspects. 2004

[2] ALEXIOU, A. ; BOURAS, C. : Rate and Loss Control for Video Transmission overUMTS using Real-Time Protocols. In: 13th IEEE International Symposium on Mo-deling, Analysis, and Simulation of Computer and Telecommunication Systems, 2005, S.333–336

[3] BALDO, N. ; HORN, U. ; KAMPMANN, M. ; HARTUNG, F. : RTCP feedback basedtransmission rate control for 3G wireless multimedia streaming. In: 15th IEEEInternational Symposium on Personal, Indoor and Mobile Radio Communications Bd. 3,2004, S. 1817– 1821

[4] BRANDEN LAMBRECHT, C. van d.: A working spatio-temporal model of the hu-man visual system forimage restoration and quality assessment applications. In:IEEE International Conference on Acoustics, Speech, and Signal Processing Bd. 4, 1996,S. 2291–2294

[5] CUETOS, P. de ; SAPARILLA, D. ; ROSS, K. : Adaptive streaming of stored video ina TCP-friendly context: multiple versions or multiple layers. In: Proceedings of theInternational Packet Video Workshop, 2001

[6] DIEGO BALAGUER, E. de ; FITZEK, F. ; OLSEN, O. ; GADE, M. : PerformanceEvaluation of Power Saving Strategies for DVB–H Services using adaptive MPE–FEC Decoding. In: 16th International Symposium on Personal, Indoor and Mobile RadioCommunications Bd. 4, 2005, S. 2221–2226

[7] ELEFTHERIADIS, A. : Dynamic Rate Shaping of Compressed Digital Video, ColumbiaUniversity, Diss., 1995

[8] ETSI: ETSI EN 302 304: Digital Video Broadcasting (DVB); Transmission System forHandheld Terminals. 2004

[9] ETSI: ETSI TS 102 428: Digital Audio Broadcasting (DAB). 2005

[10] FFMPEG: FFmpeg Multimedia System. http://ffmpeg.mplayerhq.hu. – zuletztbesucht: 2006-10-25

91

Literaturverzeichnis

[11] FORTINO, G. ; FURFARO, A. ; GUERRI, C. ; PAJARES, A. ; PALAU, C. ; RUSSO, W. :A Java-based adaptive media streaming on-demand platform. In: Proceedings ofSCS Euromedia 02, 2002, S. 155–160

[12] Kapitel What’s wrong with mean-squared error? In: GIROD, B. : Digital images andhuman vision. MIT Press Cambridge, MA, USA, 1993, S. 207–220

[13] HANDLEY, M. ; FLOYD, S. ; PADHYE, J. ; WIDMER, J. : TCP FriendlyRate Control (TFRC): Protocol Specification. RFC 3448 (Proposed Standard).http://www.ietf.org/rfc/rfc3448.txt. Version: 2003

[14] HANDLEY, M. AND SCHULZRINNE, H. AND SCHOOLER, E. AND ROSEN-BERG, J. : SIP: Session Initiation Protocol. RFC 2543 (Proposed Standard).http://www.ietf.org/rfc/rfc2543.txt. Version: 1999

[15] ISO/IEC: Test Model 5. April 1993

[16] ISO/IEC: ISO/ IEC 7498-1: Open Systems Interconnection – Basic Reference Model:The Basic Model. Los Alamitos, CA, USA, 1994

[17] ISO/IEC: ISO/IEC 13818-1: Generic Coding of Moving Pictures and Associated Audio:Systems. 1994

[18] ISO/IEC: ISO/IEC 13818-2: Generic Coding of Moving Pictures and Associated Audio:Video . 1994

[19] ISO/IEC: ISO/IEC 14496-10: Coding of audio-visual objects: Advanced Video Coding.2003

[20] ITU: ITU-R BT.500-7: Methodology for the subjective assessment of the quality of televi-sion pictures. 2000

[21] KALMAN, M. ; STEINBACH, E. ; GIROD, B. : Adaptive media playout for low-delayvideo streaming over error-prone channels. In: IEEE Transactions on Circuits andSystems for Video Technology 14 (2004), S. 841–851

[22] KAMACI, N. ; ALTUNBASAK, Y. : Performance comparison of the emerging H. 264video coding standard with the existing standards. In: 2003 International Conferenceon Multimedia, 2003, S. 345–348

[23] KIM, T. : Scalable Video Streaming over the Internet, Georgia Institute of Technology,Diplomarbeit, 2005

[24] KNOCHE, H. ; MCCARTHY, J. : Design requirements for mobile TV. In: Proceedingsof the 7th international conference on Human computer interaction with mobile devices& services, 2005, S. 69–76

[25] KORNFELD, M. : DVB-H-the emerging standard for mobile data communication.In: IEEE International Symposium on Consumer Electronics (2004), S. 193–198

92


[26] LEE, S. ; KWAK, D. : TV in your cell phone: The introduction of digital multimediabroadcasting (DMB) in Korea, 2005

[27] LO, A. ; HEIJENK, G. J. ; NIEMEGEERS, I. G. M. M.: Evaluation of MPEG-4 vi-deo streaming over UMTS/WCDMA dedicated channels. In: Proceedings FirstInternational Conference on Wireless Internet, WICON’05, Budapest, Hungary, 2005, S.182–189

[28] LOHSE, M. : Network-Integrated Multimedia Middleware, Services, and Applications,Department of Computer Science, Saarland University, Germany, Diss., June 2005

[29] MASRY, M. ; HEMAMI, S. S.: An analysis of subjective quality in low bit rate video.In: International Conference on Image Processing, 2001, S. 465–468

[30] MASRY, M. ; HEMAMI, S. S.: Perceived quality metrics for low bit rate compressedvideo. In: International Conference on Image Processing, 2002, S. 49–52

[31] MJPEG: MJPEG Tools. http://mjpeg.sourceforge.net. – zuletzt besucht: 2006-10-25

[32] MOORSEL, A. van: Metrics for the Internet Age: Quality of Experience and Qualityof Business. In: Fifth International Workshop on Performability Modeling of Computerand Communication Systems, 2001, S. 26–31

[33] NAHM, K. ; HELMY, A. ; KUO, C. : On interaction between MAC and transportlayers for media streaming in 802. 11 ad hoc networks. In: Proceedings of TheInternational Society for Optical Engineering Bd. 5600, 2004, S. 99–110

[34] NETWORKS, L. : LiveMedia Framework. http://live555.com/liveMedia. – zuletztbesucht: 2006-10-25

[35] RADHA, H. ; CHEN, M. : The MPEG-4 fine-grained scalable video coding methodfor multimediastreaming over IP. In: IEEE Transactions on Multimedia Bd. 3, 2001,S. 53–68

[36] REJAIE, R. ; HANDLEY, M. ; ESTRIN, D. : Quality adaptation for congestion control-led video playback over the Internet. In: SIGCOMM ’99: Proceedings of the conferenceon Applications, technologies, architectures, and protocols for computer communication,1999, S. 189–200

[37] SCHULZRINNE, H. ; CASNER, S. ; FREDERICK, R. ; JACOBSON, V. : RTP: ATransport Protocol for Real-Time Applications. RFC 3550 (Proposed Standard).http://www.ietf.org/rfc/rfc3550.txt. Version: 2003

[38] SCHULZRINNE, H. ; RAO, A. ; LANPHIER, R. : Real Time Streaming Proto-col. RFC 2326 (Proposed Standard). http://www.ietf.org/rfc/rfc2326.txt.Version: 1998

93


[39] SDL: Simple Directmedia Layer. http://www.libsdl.org. – zuletzt besucht: 2006-10-25

[40] STEINBACH, E. ; FARBER, N. ; GIROD, B. : Adaptive playout for low latency videostreaming. In: International Conference on Image Processing Bd. 1, 2001, S. 962–965

[41] STONE, D. ; JEFFAY, K. : An empirical study of delay jitter management policies.In: Multimedia Systems 2 (1995), Nr. 6, S. 267–279

[42] SUN, J. : Football on Mobile Phones: Algorithms, Architectures and Quality of Expe-rience in Streaming Video, Department of Applied Physics and Electronics, UmeåUniversity, Diplomarbeit, 2006

[43] TROLLTECH ASA: Qt-Framework. http://www.trolltech.com/products/qt. –zuletzt besucht: 2006-10-25

[44] UNIVERSITY, S. : Network-Integrated Multimedia Middleware.http://www.networkmultimedia.org/. – zuletzt besucht: 2006-10-25

[45] VETRO, A. ; SUN, C. : Video transcoding architectures and techniques: an overview.In: Signal Processing Magazine, IEEE 20 (2003), Nr. 2, S. 18–29

[46] VLC: VideoLAN – VLC media player. http://www.videolan.org. – zuletzt besucht:2006-10-25

[47] WALKE, B. : Mobilfunknetze und ihre Protokolle. 1. Grundlagen, GMS [GSM], UMTSund andere zellulare Mobilfunknetze. Teubner, 2000

[48] WANG, Z. ; BOVIK, A. C. ; LU, L. : Why is image quality assessment so difficult?In: IEEE International Conference on Acoustics, Speech, and Signal Processing Bd. 4,2002, S. 3313–3316

[49] WINKLER, S. : A perceptual distortion metric for digital color video. In: Proceedingsof The International Society for Optical Engineering Bd. 3644, 1999, S. 175–184

[50] YANG, X. D. ; SONG, Y. H. ; OWENS, T. J. ; COSMAS, J. ; ITAGAKI, T. : Performanceanalysis of time slicing in DVB-H. In: Joint IST Workshop on Mobile Future, 2004 andthe Symposium on Trends in Communications (2004), S. 183–186

94

Documents

Adaptive Unicast Live-Streaming in a Mobile-TV Environment ...positron/main.pdf · Adaptive Unicast Live-Streaming in a Mobile-TV Environment (Adaptives Unicast Live-Streaming für