Kompendium Medieninformatik: Mediennetze (X.media.press)

Roland Schmitz · Roland Kiefer Johannes Maucher · Jan Schulze Thomas Suchy Kompendium Medieninformatik Mediennetze Mit...

Author: Roland Schmitz | Roland Kiefer | Johannes Maucher | Jan Schulze | Thomas Suchy

61 downloads 1861 Views 6MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD

Roland Schmitz · Roland Kiefer Johannes Maucher · Jan Schulze Thomas Suchy

Kompendium Medieninformatik Mediennetze Mit 106 Abbildungen und 11 Tabellen

123

Roland Schmitz Roland Kiefer Johannes Maucher Jan Schulze Thomas Suchy Hochschule der Medien Nobelstr. 10 70569 Stuttgart [email protected] www.medieninformatik.hdm-stuttgart.de

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar. ISSN 1439-3107 ISBN-10 3-540-30224-7 Springer Berlin Heidelberg New York ISBN-13 978-3-540-30224-7 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz und Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3100 YL – 5 4 3 2 1 0

Einleitung

„The medium is the message“ – treffender und kürzer, als es Herbert Marshall McLuhan in den 60er Jahren des letzten Jahrhunderts auf den Punkt gebracht hat, kann man die wechselseitige Beziehung zwischen dem Inhalt einer Kommunikation und ihrer Präsentationsform auch heute nicht beschreiben. Versucht man davon ausgehend, den zu Grunde liegenden Sachverhalt etwas präziser zu fassen, so stellt man fest: Die Techniken zur Erzeugung, zum Transport, zur Speicherung und zur Darstellung einer Botschaft sind ebenso entscheidend für ihre Wahrnehmung, wie ihr eigentlicher Inhalt. Damit wird klar, was der viel benutzte (und strapazierte) Begriff der „Medien“ eigentlich bedeutet: Medien sind dem Wortsinn nach „Vermittler“. Sie dienen der Speicherung, Darstellung und Übermittlung von Informationen. Im heutigen Sprachgebrauch meint man mit Medien aber häufig auch die Informationen selbst und unterscheidet nicht deutlich zwischen der Information und ihrem Träger. Die übertragenen Informationen können in unterschiedlich strukturierter Form und Codierung vorliegen. Eine Strukturierung in Medien kann auf unterschiedliche Arten herbeigeführt werden, etwa mittels ergänzender Informationen, so genannter Metadaten, oder durch Eingliederung in eine Ordnungsstruktur, etwa eine hierarchische Gruppierung. Die Medieninformatik beschäftigt sich speziell mit digitalen Medien, das sind zum einen digital (also in Form von Bits) codierte Arten von Informationen, zum anderen die Träger dieser Informationen. Die Art der Codierung, das heißt die Vorschrift, wie die ursprünglichen Informationen in Bitform darzustellen sind (und wie umgekehrt die Bits als Information zu interpretieren sind) bestimmt über den Medientyp, wie zum Beispiel Text, Dokument, Bild, Audio, Video. Die Digitalisierung stellt dabei einen entscheidenden Schritt dar: Durch sie wird es möglich, die Informationen von ihrem physikalischen Träger zu trennen. Diese Trennung trägt maßgeblich zur immer weiter wachsenden Mobilität unserer Kommunikation und unseres Arbeitslebens

Einleitung

Medien

Medieninformatik

■ ■ ■

V

Das Buch

VI

■ ■ ■

insgesamt bei. Die Informatik stellt hierfür die theoretischen Grundlagen und Methoden der Informationsverarbeitung auf Rechnersystemen zur Verfügung. Die Medieninformatik zeigt, wie diese Methoden speziell auf digitale Medien anzuwenden sind. Damit prägt die Medieninformatik unseren Alltag, weil sie letztlich darüber mitentscheidet, was und wie viel aus der täglichen Informationsflut in unseren Köpfen ankommt. Die Beherrschung ihrer Konzepte und Techniken ist für unser aller Zukunft maßgebend. Aus diesem Grund versteht sich die Medieninformatik auch nicht nur als rein technische Disziplin, sondern umfasst auch gestalterische, psychologische und ökonomische Aspekte. Diese Vielfalt spiegelt sich auch in den unterschiedlichen Inhalten der vielen verschiedenen, an deutschen Hochschulen angebotenen Studiengängen mit dem Namen „Medieninformatik“ wider. Das „Kompendium der Medieninformatik“ befasst sich vor allem mit den technischen Aspekten der Medieninformatik und bildet damit den Schwerpunkt der Lehrinhalte im Studienbereich Medieninformatik an der Hochschule der Medien in Stuttgart ab. Trotz dieses Schwerpunkts auf den Informatik-Aspekten der Medieninformatik unterscheidet sich das Kompendium der Medieninformatik inhaltlich deutlich von klassischen Lehrbüchern der Informatik. Die Grundlagen der Informatik werden nur insoweit behandelt, als sich durch die Anwendung auf Mediendaten neue und spezifische Gesichtspunkte ergeben. In allen anderen Fällen gehen wir davon aus, dass der Leser mit den Grundlagen der Informatik bereits vertraut ist. Zielgruppen dieses Buches sind somit Studenten der Informatik und Medieninformatik im Hauptstudium sowie Praktiker, die bereits Erfahrung mit den Anwendungen der Informatik in der Industrie gesammelt haben und sich nun speziell über Anwendungen in den Medien informieren wollen. Der vorliegende erste Teil des Kompendiums der Medieninformatik beschäftigt sich mit „Mediennetzen“. Damit sind die Techniken gemeint, die beim Transport von Informationen durch unterschiedliche Netze zum Einsatz kommen. Es geht also um die „Verpackung“ und den Transport digitalisierter Informationen. Kompressionsverfahren, Mediensicherheit, Multimedianetze und Mobile Netze sind hier die Stichworte. Darauf aufsetzend behandeln wir in einem zweiten Teil des Kompendiums Aspekte der praktischen Informatik und ihre Anwendung in der Medientechnik, wie die Entwicklung von Multimedia-Anwendungen, die Grundlagen der Computergrafik, Theorie und Praxis von Mediendatenbanken. Hinzu kommen einige ausgewählte Anwendungen der Medieninformatik wie die Content-Related-Technologien, mit denen mediale Informationen in möglichst effizienter Weise organisiert, strukturiert und an die richtigen Empfänger verteilt werden können.

Einleitung

Wir begleiten in diesen beiden Teilen also die digitalen Mediendaten auf ihrem Weg von der Erzeugung und Kodierung über ihren Transport durch drahtgebundene oder drahtlose Netze bis hin zum Endnutzer und decken damit eine ganze Wertschöpfungskette ab. Die Autoren des Kompendiums sind allesamt ausgewiesene Experten ihres Fachs und stehen (oder standen) in aktiver Lehrtätigkeit an der Hochschule der Medien Stuttgart. Die Inhalte des Kompendiums basieren auf Lehrveranstaltungen, die von den Autoren im Rahmen der Studiengänge Medieninformatik (Bachelor/Master) und Information Systems (Bachelor/Master) gehalten werden. Wir danken unseren Studenten für zahlreiche wertvolle Kommentare und Verbesserungsvorschläge zu diesen Lehrveranstaltungen. Ohne diese Anregungen wäre dieses Buch nicht realisierbar gewesen.

Einleitung

■ ■ ■

VII

Inhaltsverzeichnis

1

Kompressionsverfahren für Video und Audio.............................. 1 1.1 Einführung in die Informationstheorie ................................. 2 1.2 Grundlagen der Datenkompression....................................... 4 1.3 Elementare Verarbeitungsschritte.......................................... 5 1.3.1 Unterabtastung und Quantisierung............................ 6 1.3.2 Entropiecodierung ........................................................ 8 1.3.3 Prädiktion..................................................................... 11 1.3.4 Signaltransformationen.............................................. 12 1.4 Medienspezifische Verarbeitungsschritte ........................... 17 1.4.1 Interframe-Kompression ........................................... 17 1.4.2 Psychoakustische Kompression................................ 20 1.5 Codecs im Überblick............................................................... 23 1.5.1 Video-Codecs............................................................... 24 1.5.2 Audio-Codecs .............................................................. 27 1.6 Die Standards JPEG und JPEG 2000 ..................................... 29 1.6.1 JPEG .............................................................................. 29 1.6.2 JPEG 2000 und Motion JPEG 2000 ............................ 35 1.7 Videokompression mit MPEG .............................................. 38 1.7.1 MPEG-1......................................................................... 39 1.7.2 MPEG-2......................................................................... 44 1.7.3 MPEG-4......................................................................... 50 1.8 Audiokompression mit MPEG.............................................. 60 1.8.1 MPEG-1 Audio............................................................. 61 1.8.2 MPEG-4 Audio Lossless Coding................................ 67 1.9 Verfahren der Sprachkompression ...................................... 70 1.9.1 Signalformcodierer ..................................................... 71 1.9.2 Parametrische Codecs................................................. 73 1.9.3 Hybride Codecs ........................................................... 74 Literatur ............................................................................................. 78

Inhaltsverzeichnis

■ ■ ■

IX

X

■ ■ ■

2

Mediensicherheit ............................................................................. 83 2.1 Einführung .............................................................................. 84 2.1.1 Sicherheitsanforderungen für Digitale Medien...... 84 2.1.2 Sicherheitsmechanismen........................................... 85 2.2 Digitale Wasserzeichen.......................................................... 92 2.2.1 Anwendungsgebiete für Digitale Wasserzeichen ... 93 2.2.2 Einbettungstechniken ................................................ 97 2.2.3 Angriffe ...................................................................... 106 2.3 DRM-Systeme ....................................................................... 108 2.3.1 Komponenten von DRM-Systemen ....................... 109 2.3.2 Mobile DRM-Systeme .............................................. 112 2.3.3 Angriffe auf DRM-Systeme ..................................... 116 2.3.4 Kommerzielle DRM-Systeme.................................. 117 2.3.5 Ökonomische und Rechtliche Aspekte.................. 121 2.4 Ausblick ................................................................................. 123 Literatur........................................................................................... 124

3

Multimedia-Netze.......................................................................... 3.1 Einführung ............................................................................ 3.2 Multimedia-Transportnetze................................................ 3.2.1 Einleitung................................................................... 3.2.2 High-Speed in Metronetzen .................................... 3.2.3 High-Speed im Weitverkehrsnetz .......................... 3.3 Quality of Service (QoS) ...................................................... 3.3.1 Einführung................................................................. 3.3.2 Problemstellungen und Lösungsansätze............... 3.3.3 ATM-QoS................................................................... 3.3.4 IP-QoS in Weitverkehrsnetzen ............................... 3.4 Next Generation Networks NGN........................................ 3.4.1 Einleitung................................................................... 3.4.2 Voice-over-IP ............................................................ 3.4.3 IP Next Generation – IPv6....................................... 3.4.4 Multicast..................................................................... 3.4.5 Fazit ............................................................................ Literatur...........................................................................................

127 127 129 129 130 133 143 143 145 148 151 156 156 159 176 180 181 181

4

Mobile Multimedia........................................................................ 4.1 Begriffsbestimmungen......................................................... 4.2 Dienste und Architekturen zukünftiger mobiler Multimedia Netze ................................................................. 4.2.1 Mobilität und Multimedia – Anforderungen........ 4.2.2 Mobile Netze der Gegenwart................................... 4.2.3 Architektur zukünftiger mobiler All-IP Netze am Beispiel des UMTS Release 5 ............................

183 185

Inhaltsverzeichnis

186 186 190 202

4.3 Entwicklung Mobiler Multimedia-Anwendungen............ 208 4.3.1 Mobile Multimedia Endgeräte................................. 209 4.3.2 Mobile Multimedia Software-Plattformen............. 213 4.3.3 Mobile Multimedia Datenformate .......................... 272 Literatur ........................................................................................... 280 Autorenverzeichnis ................................................................................. 285 Index.......................................................................................................... 287

Inhaltsverzeichnis

■ ■ ■

XI

Abkürzungen

3GPP 3GPP2 AAC AAL AAZ ABR AC-3 ACELP ADM ADPCM AIS ALS AMR AMR-WB APS ASF ATM AU AUG AVC AVI BAB BBC B-Frame CBR CDV CDVT CELP CER CIDR CLP CLR CRC CS CS-ACELP CVR DAB DBR DCC DCI

3rd Generation Partnership Project 3rd Generation Partnership Project 2 Advanced Audio Coding ATM Adaption Layer Advanced Audio Zip Available Bit Rate Audio Coding 3 Algebraic Code Excited Linear Prediction Add Drop Multiplexer Adaptive Differential Pulse Code Modulation Alarm Indication Signal Audio Lossless Coding Adaptive Multirate Adaptive Multirate Wideband Automatic Protection Switching Advanced Streaming/Systems Format Asynchronous Transfer Mode Administrative Unit Administrative Unit Group Advanced Video Coding Audio Video Interleave Binary Alpha Block British Broadcasting Company Bidirectionally predicted Frame Constant Bit Rate Cell Delay Variation Cell Delay Variation Tolerance Code Excited Linear Prediction Cell Error Ratio Classless Inter Domain Routing Cell Loss Priority Cell Loss Ratio Cyclic Redundancy Check Call Server Conjugate Structure Algebraic Code Excited Linear Prediction Cell Delay Variation Digital Audio Broadcast Deterministic Bit Rate Digital Compact Cassette Digital Cinema Initiatives

Abkürzungen

■ ■ ■

XIII

DCT DECT DiffServ DRM DS DSCP DSCP DVB-S DVB-T DVD DVMRP E-ADPCM ECC EDGE EFR ENUM ES FFT FIR FR FWT GFC GFP GOP GPRS GS GSM HD HILN HR HVXC IDCT IEC IETF I-Frame IIR IIS IMS IMS IntServ IP ISDN ISO ITU ITU JBIG JPEG JVT LAN LCAS LD-CELP LDP LER

XIV

■ ■ ■

Abkürzungen

Diskrete Kosinustransformation Digital Enhanced Cordless Telecommunications Differentiated Services Digital Radio Mondiale Differentiated Services Differentiated Services Code Point DiffServ Code Point Digital Video Broadcast Satellite (MPEG-2) Digital Video Broadcast Terrestrial Digital Versatile Disc Distance Vector Multicast Routing Protocol Enhanced Adaptive Differential Pulse Code Modulation Embedded Communication Channel Enhanced Data Rates for GSM Evolution Enhanced Full Rate TElephone NUmber Mapping Elementary Stream Fast Fourier Transform Finite Impulse Response Full Rate Fast Wavelet Transform Generic Flow Control Generic Frame Procedure Group Of Pictures General Packet Radio Services Guaranteed Service Global System for Mobile Communications High Definition Harmonic and Individual Lines and Noise Half Rate Harmonic Vector Excitation Coding Inverse DCT International Electrotechnical Commission Internet Engineering Task Force Intra-Frame Infinite Impulse Response Fraunhofer Institut für integrierte Schaltungen IP Multimedia Subsystem IP Multimedia System Integrated Services Internet Protocol Integrated Services Digital Network International Organization for Standardization International Telecommunications Union Internation Telecommunication Union Joint Bi-Level Image Group Joint Photographic Experts Group Joint Video Team Local Area Network Link Capaciyt Adjustment Scheme Low-Delay Code Excited Linear Prediction Label Distribution Protocol Label Edge Router

LPAC LPC LSR MA MAC MAN MCU MDCT MELPe MGC MJPEG 2000 MJPEG MMD MMS MOS MOS MP3 MPEG MPEG-LA MPLS MP-MLQ MSOH MTU NAL NAPT NAPTR NGN OAM OSPF PCM PCR PCR PDH P-Frame PHB PHB PIM PNS POH PVC QoS RFC RPE-LTP RPR RSOH RSVP RSVP RTCP RTP RTP RTSP SAR SB-ADPCM

Lossless Predictive Audio Coding Linear Prediction Coefficients Label Switch Router Monkey's Audio Media Access Control Metropolitan Area Network Multipoint Control Unit Modified DCT Enhanced Mixed Excitation Linear Prediction Media Gateway Controller Motion JPEG 2000 Motion JPEG Multimedia Domain Multimedia Messaging Service Mean Opinion Score Mean Opinion Score MPEG Audio Layer III Moving Picture Experts Group MPEG Licensing Authority Multiprotocol Label Switching Multipulse Maximum Likelihood Quantization Multiplexer Section Overhead Maximum Transmission Unit Network Abstraction Layer Naming Authority Pointer Records Naming Authority Pointer Records Next Generation Network Operation, Administration and Management Open Shortest Path First Pulse Code Modulation Peak Cell Rate Peak Cell Rate Plesiochronous Digital Hierarchy Predicted Frame Per-hop-behaviour Per Hob Behaviour Protocol Independant Multicast Perceptual Noise Substitution Path Overhead Permanent Virtual Channel Quality of Service Request for Comment Regular Pulse Excitation with Long-Term Prediction Resilient Packet Ring Regenerator Section Overhead Resource Reservation Protocol Resource Reservation Protocol Real Time Transmission Control Protocol Real-Time Transport Protocol Real-Time-Protocol Real Time Streaming Protocol Segmentation and Reassemblation Subband Adaptive Differential Pulse Code Modulation

Abkürzungen

■ ■ ■

XV

SDDS SDH SDP SIP SIP SMPTE SOH SONET STANAG STM STS SVC TCP TMN TOS TU TUG UAC UAS UBR UBR UDP VBR VBR VC VC-1 VCAT VCL VLAN VMR VMR-WB VO VOL VOP VPN VQEG VRML VS VSELP WAN WM WMA WMV

XVI

■ ■ ■

Abkürzungen

Sony Dynamic Digital Sound Synchronous Digital Hierarchy Session Description Protocol Session Initiation Protocol Session Initiation Protocol Society of Motion Picture Engineers Section Overhead Synchronous Optical Network Standardization Agreement Synchronous Transfer Module Synchronous Transport Signal Switched Virtual Channel T ransmission Control Protocol Telecommunications Management Network Type of Service Tributary Unit Group Tributary Unit Group User Agent Client User Agent Server Unspecified Bit Rate Unspecified Bit Rate User Datagram Protocol Variable Bit Rate Variable Bit Rate Virtual Container Video Coding 1 Virtual Concatenation Video Coding Layer Virtual LAN Variable Multirate Variable Multirate Wideband Video Object Video Object Layer Video Object Plane Virtual Private Network Video Quality Experts Group Virtual Reality Modeling Language Visual Sequence Vector Sum Excited Linear Prediction Wide Area Network Windows Media schnelle Wavelet-Transformation Audio Windows Media Video

1 Kompressionsverfahren für Video und Audio Jan Schulz

Kontinuierliche Medien wie Audio- und Videosequenzen stellen in Bezug auf erforderliche Datenrate und benötigten Speicherplatz hohe Anforderungen an die verarbeitenden Systeme. Beispielsweise besitzt eine unkomprimierte Bildsequenz mit der Auflösung von 640 u 480 Pixeln bei einer Bildrate von 25 Bildern pro Sekunde und einer Farbtiefe von 8 Bit pro RGB-Kanal eine Datenrate von:

Motivation für Datenkompression

640 480 25 Hz 8 Bit/Kanal 3 Kanäle = 184.320.000 Bit/s | 184 MBit/s.

10 Minuten einer solchen Bildsequenz benötigen Speicherplatz im zweistelligen Gigabyte-Bereich. Um also Audio- und Videosequenzen übertragen, verarbeiten und speichern zu können, ist der Einsatz effizienter Kompressionsverfahren fast immer unverzichtbar. Dies gilt für den klassischen Fernsehbereich ebenso wie z. B. für die Wachstumsbranche der Mobilen Multimediadienste (vgl. Kap. 4). Unter der Sammelbezeichnung High Definition Television (HDTV) starten derzeit immer mehr Fernsehprogramme in höherer Auflösung, während Auflösung in der Mobilfunkbranche aufgrund der Größe der Endgeräte nur ein untergeordnetes Kriterium darstellt. Hier steht – mehr noch als bei HDTV – die Datenrate im Blickpunkt, die bei der ersten UMTS-Version z. B. bis zu 384 kBit/s beträgt. HDTV-Programme benötigen dagegen mit etwa 15 MBit/s (DVB-S) weitaus höhere Datenraten. Diese ausgeprägten Unterschiede beginnen mit der Annäherung von Kommunikations- und Unterhaltungsbranche auf dem Konsumentenmarkt zu schwinden, was sich auch bei neuen Verfahren der Datenkompression widerspiegelt. Während frühere Kompressionsstandards wie z. B. MPEG-1 stark auf einen bestimmten Einsatzzweck zugeschnitten wurden, sind neuere Standards wie bspw. H.264/AVC viel flexibler einsetzbar und werden in beiden oben genannten Branchen verwendet. Trotz aller Annäherung bei der Auslieferung von Medieninhalten hat die Film- und Fernsehbranche jedoch nach wie vor Bedarf an

1 Kompressionsverfahren für Video und Audio

Annäherung von Fernseh- und Kommunikationsbranche auf dem Konsumentenmarkt

Bleibender Bedarf an hoher Qualität

■ ■ ■

1

Inhalte des Kapitels

Verfahren, mit denen Produktionen möglichst ohne Informationsverluste komprimiert werden können. Dies ist z. B. an den Fidelity Range Extensions ersichtlich, welche H.264/AVC u. A. um eine Möglichkeit ergänzen, die volle Farbinformation des Videomaterials zu erhalten. Im Folgenden werden zunächst einige Konzepte der Informationstheorie und Begriffe aus dem Bereich der Datenkompression erläutert, bevor in Kap. 1.3 grundlegende Verarbeitungsschritte dargestellt werden, die sich in vielen Kompressionsverfahren wieder finden. Mit Interframe- und psychoakustischer Kompression werden in Kap. 1.4 zwei Verfahren für die Video- bzw. Audiokompression beleuchtet, welche medienspezifische Besonderheiten ausnutzen und in Kombination mit anderen Verarbeitungsschritten die Kompressionsrate stark erhöhen können. Kapitel 1.5 gibt einen Überblick über zahlreiche Kompressionsverfahren für Audio- und Videodaten, wobei insbesondere Standards der ITU und der MPEG-Gruppe betrachtet werden. Nachdem in Kap. 1.6 die JPEG-Kompression als Ausgangspunkt zahlreicher Verfahren zur Videokompression erläutert wurde, behandelt Kap. 1.7 ausführlich die Videokompression nach MPEG. Anhand von MPEG-1 wird hierbei die grundlegende Funktionsweise der MPEG-Standards dargestellt, so dass in den weiteren Unterkapiteln zu MPEG-2 und MPEG-4 darauf aufgebaut werden kann. Kapitel 1.8 widmet sich der Audiokompression und stellt mit MPEG-1 und MPEG-4 ALS Verfahren vor, denen zwei unterschiedliche Funktionsweisen zu Grunde liegen. Während MPEG-1 Audio ein psychoakustisches Modell verwendet, basiert MPEG-4 ALS im Wesentlichen auf Prädiktion. Als Spezialfall der Audiokompression wird in Kap. 1.9 abschließend die Sprachkompression erläutert. Weitere Informationen hierzu finden sich auch in Kap. 3.

1.1 Einführung in die Informationstheorie Informationstheorie

gedächtnislose Nachrichtenquelle

2

■ ■ ■

Die Informationstheorie wurde durch Shannon begründet, der die Übertragung von Zeichen zwischen Nachrichtenquelle und Nachrichtensenke betrachtete und daraus mathematische Methoden entwickelte, um Information quantitativ zu bestimmen [Shn48]. Erkenntnisse der Informationstheorie werden u. A. bei Entropiecodierungen (Kap. 1.3.2) eingesetzt, die Nachrichten möglichst kompakt darstellen und so Datenkompression erzielen. Im Folgenden werden diskrete gedächtnislose Nachrichtenquellen mit endlichem Alphabet betrachtet, die in der Informationstheorie einen Spezialfall darstellen. Eine solche Quelle versendet zu diskreten


Zeitpunkten t = 0, 1, ... die Symbole eines endlichen Alphabets A. Die Wahrscheinlichkeit für das Auftreten eines Zeichens z A zum Zeitpunkt t hängt dabei nicht vom Zeitpunkt t und nicht von den Zeichen ab, die zu den vergangenen Zeitpunkten 0, ..., t–1 gesendet wurden. Gedächtnislose Quellen sind in der Realität selten zu finden, da hier häufig Abhängigkeiten zwischen einzelnen Quellsymbolen bestehen. Sie genügen jedoch, um grundlegende Konzepte und Begriffe der Informationstheorie zu erläutern, wie sie im Weiteren benötigt werden. Für eine Verallgemeinerung der Konzepte sei z. B. auf [Gra98] verwiesen. Der Informationsgehalt I(z) eines Zeichens z A, das von einer diskreten gedächtnislosen Nachrichtenquelle mit endlichem Alphabet erzeugt wird, berechnet sich aus der Wahrscheinlichkeit, mit der die Nachrichtenquelle das Zeichen z produziert: I(z) log 2

Informationsgehalt

1 [bit] W(z)

Mit abnehmender Auftrittswahrscheinlichkeit eines Zeichens steigt folglich sein Informationsgehalt. Tritt mit W(z) = 1 stets dasselbe Zeichen auf, so ist sein Informationsgehalt gleich 0. Betrachtet man eine Symbolfolge z0, z1, ..., zn, so lässt sich der mittlere Informationsgehalt dieser Folge berechnen, der auch als Entropie erster Ordnung bezeichnet wird. Unter der Voraussetzung, dass die Elemente der Zeichenfolge statistisch nicht voneinander abhängen, ergibt sich diese Entropie H aus der Summe der gewichteten Informationsgehalte der Einzelelemente:

Entropie

n

H

¦ W ( z i ) I ( z i ) [bit/Symbol]

i 0

Den höchsten Wert hat die Entropie demnach bei einer Gleichverteilung der Symbole. Je stärker sich die Auftrittswahrscheinlichkeiten um einen bestimmten Wert konzentrieren, desto geringer ist die Entropie. Ist die gesamte Symbolfolge z0, z1, ..., zn schon im Voraus bekannt, so entspricht die Auftrittswahrscheinlichkeit eines Zeichens der relativen Häufigkeit des Zeichens in der Symbolfolge. Bei der Audio- und Videokompression ist dies jedoch selten der Fall, und die Wahrscheinlichkeiten müssen geschätzt werden. Wenn man die Elemente einer Zeichenfolge auf binäre Codewörter abbildet, wird die mittlere Codelänge interessant. Ist li die Länge des Codeworts, mit dem das Zeichen zi codiert wird, errechnet sich die mittlere CodelängeCli aus der Summe gewichteter Codewortlängen: li

mittlere Codelänge

n

¦ W ( zi ) li [Bit/Symbol]

i 0

1.1 Einführung in die Informationstheorie

■ ■ ■

3

Codierungsredundanz

Die Differenz zwischen Entropie und mittlerer Codelänge wird Codierungsredundanz genannt. Shannon zeigte, dass immer ein Code existiert, dessen mittlere Codelänge kleiner als H+1 ist. Hohe Redundanz ist bei der Datenkompression kontraproduktiv. Kompressionsverfahren zielen daher unter anderem auf die Minimierung der Codierungsredundanz ab. Bei Nachrichten bzw. Symbolfolgen, die im Rahmen der Audiokompression betrachtet werden, handelt es sich um diskrete Samples eines digitalen Tonsignals. Bei Bilddaten sind es die Helligkeits- oder Farbwerte von Pixeln, die bei sequenzieller Betrachtung der Zeilen ebenfalls diskrete Symbolfolgen darstellen. Daher werden die Begriffe Zeichenfolge, Symbolfolge, Signal und Nachricht im Folgenden synonym verwendet.

1.2 Grundlagen der Datenkompression Quellencodierung

verlustfreie und verlustbehaftete Kompression

symmetrische und asymmetrische Kompression

4

■ ■ ■

Datenkompression ist eine Form der Codierung, welche die Symbolfolgen einer Nachrichtenquelle möglichst Platz sparend abspeichert. Codierung zum Zwecke der Datenkompression wird häufig auch als Quellencodierung bezeichnet, um sie von Kanalcodierungen bei der Datenübertragung und kryptographischen Codierungen im Bereich der Datensicherheit abzugrenzen. Im Folgenden wird diese Unterscheidung nicht mehr getroffen, und der Begriff Codierung ist immer als Quellencodierung zu verstehen. Mit verlustfreien und verlustbehafteten Verfahren lassen sich zwei grundlegende Arten der Datenkompression bzw. Quellencodierung unterscheiden. Die verlustfreie Kompression verwirft ausschließlich redundante Informationen und ist daher voll reversibel. Durch Redundanzreduktion verlustfrei komprimierte Informationen können fehlerfrei wiederhergestellt werden. Die verlustbehaftete Kompression nimmt dagegen den Verlust von irrelevanten Informationen in Kauf. Während sich Redundanz eindeutig definieren lässt, ist Irrelevanz stark subjektiv geprägt. Irrelevant sind jene Informationen, die den Empfänger nicht interessieren oder nicht von ihm wahrgenommen werden können. Die Irrelevanzreduktion ist irreversibel. Einmal verworfene Informationen lassen sich nicht wieder zurückgewinnen. Ein weiteres Kriterium für die Klassifizierung von Kompressionsverfahren erhält man, indem der zeitliche bzw. rechnerische Aufwand für die Kompression AK mit dem Aufwand für die Dekompression AD in Beziehung gesetzt wird. Ist der Aufwand identisch, spricht man von symmetrischer Kompression. Dagegen handelt es sich um asymmetrische Kompression, wenn AK > AD ist. Bei der Kompression von Audio-


und Videodaten ist häufig ein geringer Aufwand bei der Decodierung erwünscht, da diese für eine flüssige Wiedergabe des Mediums in Echtzeit erfolgen muss. Verfahren für die Audio- und Videokompression sind daher zumeist asymmetrischer Natur. Ein Algorithmus oder Schaltkreis, der eine Codierung oder Datenkompression vornimmt, wird als Coder oder Encoder bezeichnet. Umgekehrt macht ein Decoder die Kompression wieder rückgängig. Spricht man von einem Kompressionsverfahren als Ganzes, so verwendet man den zusammengesetzten Begriff Codec. Als Maß für die quantitative Bewertung eines Kompressionsverfahrens kann die Kompressionsrate herangezogen werden, bei der die ursprüngliche Datenmenge zur komprimierten Datenmenge ins Verhältnis gesetzt wird. Durch Irrelevanzreduktion lassen sich weitaus höhere Kompressionsraten erzielen als mit Verfahren, die ausschließlich auf Redundanzreduktion beruhen. Die Kompressionsrate als rein objektives Kriterium ist bei der verlustbehafteten Irrelevanzreduktion nur bedingt aussagekräftig. Daher unterscheidet man bei der Bewertung von verlustbehafteten Kompressionsverfahren häufig zwischen objektiver und subjektiver Qualität. Als einfaches Kriterium für die Beurteilung der subjektiven Qualität hat sich der Mean Opinion Score (MOS) etabliert, der aus dem Bereich der telefonischen Sprachübertragung stammt. Für dieses Einsatzgebiet existieren Empfehlungen der International Telecommunication Union (ITU), einem internationalen Zusammenschluss zur Koordination von Entwicklungen im Telekommunikations- und Fernsehbereich. Der MOS wird durch Versuchspersonen ermittelt, die anhand einer fünfstufigen Skala qualitative Bewertungen zu unterschiedlich komprimierten Signalen abgeben. Im einfachsten Fall wird anschließend der arithmetische Mittelwert dieser Bewertungen gebildet [ITU96d] [ITU03b]. Die Ermittlung der subjektiv empfundenen Qualität durch Versuchspersonen ist ein aufwändiges Verfahren. Daher wurde im Videobereich die Video Quality Experts Group (VQEG) ins Leben gerufen, die sich mit der Standardisierung objektiver Messmethoden zur Bewertung subjektiver Qualität bei Videokompressionsverfahren befasst.

Coder/Encoder, Decoder, Codec

Kompressionsrate

objektive und subjektive Qualität, Mean Opinion Score (MOS)

Video Quality Experts Group (VQEG)

1.3 Elementare Verarbeitungsschritte Bei der Audio- und Videokompression verwendet man Verfahren, die sequentiell verschiedene grundlegende Verarbeitungsschritte durchführen, um besonders hohe Kompressionsraten zu erzielen. Meist entstehen dadurch hybride Methoden, die Irrelevanz- und Redundanzreduktion kombinieren.

1.3 Elementare Verarbeitungsschritte

hybride Kompressionsverfahren

■ ■ ■

5

1.3.1

Unterabtastung und Quantisierung Unterabtastung

Abtasttheorem, Aliasfrequenz

Chrominanz und Luminanz, YCrCb-Farbraum

Durch Unterabtastung lässt sich die Datenrate eines Signals auf einfache Weise reduzieren. Bei digitalen Signalen wird dabei eine bestimmte Anzahl der diskreten Signalwerte (engl.: Samples) verworfen, und nur jeder n-te Wert mit n = 2, 3, ... wird beibehalten. Dies resultiert in einer Reduktion der Datenrate um den Faktor 1/n. Die verworfenen Samples lassen sich nicht fehlerfrei wiederherstellen, weshalb es sich hierbei um einen verlustbehafteten Vorgang handelt. Durch die Unterabtastung können bei der Rekonstruktion des Signals Aliasfrequenzen entstehen, die sich in Videosignalen beispielsweise durch störende Muster äußern. Diese Aliasfrequenzen treten nach dem fundamentalen nachrichtentheoretischen Abtasttheorem [Kot33][Shn48] immer dann auf, wenn die Frequenz der diskreten Signalwerte fa durch die Unterabtastung kleiner wird als die doppelte Bandbreite des Signals. Um die Entstehung von Aliasfrequenzen zu verhindern, kann das Signal vor der Unterabtastung einer Bandpassfilterung mit der Grenzfrequenz fg = fa/2n [Hz] unterzogen werden. Bei digitalem Video findet man häufig eine Unterabtastung der Farbinformation (Chrominanz), da diese vom menschlichen Auge schlechter aufgelöst werden kann als Helligkeitsinformation (Luminanz). Um Luminanz und Chrominanz zu trennen, werden die Videobilder in den YCrCb-Farbraum konvertiert. Dieser ist in der ITUEmpfehlung BT.601 [ITU95a] für digitale Fernsehstudiotechnik definiert und wird aus den RGB-Kanälen durch folgende Produktmatrix gewonnen: §Y · ¨ ¸ ¨ Cr ¸ ¨ Cb ¸ © ¹

4:2:2-Subsampling

6

■ ■ ■

0 ,587 0 ,114 · § R · § 0 ,299 ¸ ¨ ¸ ¨ 0 , 500 0 , 419 0 ,081¸ ¨ G ¸ ¨ ¨ 0 ,169 0 ,331 0 ,500 ¸ ¨ B ¸ ¹ © ¹ ©

In dieser weitgehend historisch bedingten Formel wird die Luminanz von der Y-Komponente, und die Chrominanz von den Komponenten Cr und Cb repräsentiert. Bei einer Unterabtastung der Chrominanz nach BT.601 werden für die Komponenten Cr und Cb jeweils nur halb so viele Pixelwerte aufgewendet wie für die Luminanz, was als 4:2:2-Subsampling bekannt ist. Noch geringer ist die Abtastung der CrCb-Komponenten bei der Kompression nach dem MPEG-1Standard (Kap. 1.7.1), wo 4:2:0-Subsampling zum Einsatz kommt (Abb. 1.1).


Abb. 1.1: 4:2:2- und 4:2:0-Subsampling

Quantisierung ist eine weitere, sehr einfache Methode der Datenreduktion. Anstatt einzelne Samples zu verwerfen, wird hierbei die Genauigkeit reduziert, mit der sie abgespeichert werden. Man unterscheidet in skalare Quantisierung und Vektorquantisierung. Die skalare Quantisierung ordnet jedem Signalwert einen quantisierten Wert aus einer endlichen Wertemenge zu. Die Zuordnung erfolgt dabei im einfachsten Fall linear auf Basis eines Rasters mit Intervallen fester Länge. Alle Samples innerhalb eines bestimmten Intervalls werden dabei auf denselben quantisierten Wert abgebildet, wodurch verlustbehaftete Datenkompression entsteht. Anstelle eines festen Rasters können auch unterschiedliche Intervallbreiten gewählt werden, um bestimmte Werte stärker zu quantisieren als andere. Dies kann beispielsweise Sinn machen, wenn sich dadurch Einschränkungen der menschlichen Wahrnehmung ausnutzen lassen und wird als nichtlineare Quantisierung bezeichnet. Die Intervallbreiten bei nichtlinearer Quantisierung werden in Form von sog. Quantisierungskennlinien festgelegt. Die Vektorquantisierung berücksichtigt n Signalwerte gleichzeitig, die als Vektor des n-dimensionalen Raums aufgefasst werden. Wie die skalare Quantisierung stellt auch die Vektorquantisierung einen verlustbehafteten Vorgang dar. Ein Vektorquantisierer der Dimension n und Größe s bildet Eingabevektoren auf eine endliche Menge C ab, die aus s Ausgabevektoren besteht. Für die Wahl der Ausgabevektoren aus C können verschiedene Kriterien herangezogen werden. Im einfachsten Fall kommt das euklidische Abstandsmaß der Vektoren zum Einsatz. Die Menge C der Ausgabevektoren wird als Codebuch bezeichnet. Die größte Herausforderung bei der Vektorquantisierung ist die Wahl eines geeigneten Codebuchs. Dieses muss in einer Trainingsphase mit Hilfe


Quantisierung

skalare Quantisierung, nichtlineare Quantisierung

Vektorquantisierung, Codebuch

■ ■ ■

7

Vektorquantisierung in der Videokompression

charakteristischer Signalvektoren optimiert und so an typische Signalstatistiken angepasst werden. Ein verbreiteter Algorithmus zur Codebuch-Erstellung ist der LBG-Algorithmus [LBG80]. Vektorquantisierung in der Videokompression teilt Einzelbilder in quadratische Blöcke auf, wobei gleichartige Blöcke durch einen generischen Block aus einem Codebuch ersetzt werden. Der Einsatz von Vektorquantisierung in Codecs wie Sorensen oder Cinepak trug in den neunziger Jahren zur Verbreitung von digitalem Video auf Heimcomputern bei [WNW94]. Ein Audio-Codec auf Basis von Vektorquantisierung ist z. B. SoundVQ, der unter der Bezeichnung TwinVQ entwickelt [IMM95] und inzwischen als Teil von MPEG-4 Audio standardisiert wurde (Kap. 1.8).

1.3.2

Entropiecodierung Entropiecodierungen nutzen die statistische Verteilung von Symbolen innerhalb einer Zeichenkette aus. So lässt sich die mittlere Codelänge der Entropie annähern und damit die Codierungsredundanz mindern. Da Entropiecodierungen ausschließlich redundante Informationen verwerfen, arbeiten sie verlustfrei. 1.3.2.1 Huffman-Codierung

grafische Ermittlung

Die Huffman-Codierung [Huf52] geht davon aus, dass die einzelnen Symbole einer Nachricht statistisch unabhängig voneinander sind, und codiert diese separat. Symbole, die eine hohe Auftrittswahrscheinlichkeit besitzen, werden mit kürzeren Codes abgespeichert als Werte mit geringer Auftrittswahrscheinlichkeit. Um eine Huffman-Codierung auf grafische Weise zu ermitteln, werden die Quellsymbole als Codebäume mit einem Knoten betrachtet. In jedem Knoten wird die Auftrittswahrscheinlichkeit des jeweiligen Symbols eingetragen. Die verschiedenen Knoten werden dann wie folgt zu einem einzelnen Baum zusammengefügt: 1. Die zwei Knoten mit der geringsten Auftrittswahrscheinlichkeit werden zu einem neuen Knoten zusammengefasst. 2. Dem neu entstandenen Knoten wird die Summe der beiden Auftrittswahrscheinlichkeiten zugewiesen. 3. Die neu entstandenen Zweige erhalten als Beschriftung 0 bzw. 1. 4. Man beginnt von vorne, wenn die Wurzel des Baumes mit der Auftrittswahrscheinlichkeit 1 noch nicht erreicht ist.

8

■ ■ ■


Abb. 1.2: Grafische Entwicklung einer Huffman-Codierung

Ausgehend von den Blattknoten kann am Ende das Codewort für jedes Symbol abgelesen werden. Die grafische Entwicklung einer Huffman-Codierung für die Zeichenkette mississippi ist in Abb. 1.2 dargestellt. Die Huffman-Codierung besitzt eine Entropie von 1,82 bit/ Symbol und eine mittlere Codelänge von 1,91 Bit/Symbol. Die Codierungsredundanz ist demnach nahe null. Dabei wurde jedoch nicht berücksichtigt, dass der Codebaum für die Decodierung bekannt sein muss und daher zusätzlich abgespeichert wird. Da die Huffman-Codierung einzelne Symbole codiert, und diese immer durch eine ganzzahlige Folge von Bits dargestellt werden müssen, ist die Codierung nicht in allen Fällen optimal. Eine Codierungsredundanz von 0 Bits wird nur dann erreicht, wenn der Informationsgehalt eines Symbols und die zugeordnete Codelänge übereinstimmen. Dies ist der Fall, wenn die Auftrittswahrscheinlichkeiten der Bedin-n gung W(zi) = 2i mit n = 1, 2, 3, ... genügen. Ein Vorteil der HuffmanCodierung ist, dass sie einfach implementiert werden kann, und es sich nur um ein geringfügig asymmetrisches Verfahren handelt.

Eigenschaften

1.3.2.2 Arithmetische Codierung

Die arithmetische Codierung rückt von der separaten Symbolcodierung ab und erzeugt einen einzigen Code für die gesamte Nachricht. So wird Redundanz auch dort effizient vermindert, wo sich eine Huffman-Codierung als ungünstig erweisen würde. Trotzdem lässt sich die arithmetische Codierung sequentiell durch Abarbeiten einzelner Symbole ermitteln. Wie die Huffman-Codierung geht die arithmetische Codierung davon aus, dass die Nachrichtensymbole statistisch unabhängig voneinander sind. Das Funktionsprinzip der arithmetischen Codierung ist es, die gesamte Zeichenfolge z0, z1, ... zn durch eine rationale Zahl aus dem Einheitsintervall [0,1) zu codieren. Dies geschieht wie folgt:


Funktionsprinzip

■ ■ ■

9

1. Das Einheitsintervall [0,1) wird ausgewählt. 2. Das aktuell gewählte Intervall wird so in Teilintervalle eingeteilt, dass die Größen der Teilintervalle mit den Auftrittswahrscheinlichkeiten W(zi) der Symbole z0, z1, ... zn korrespondieren. 3. Das Teilintervall, das dem aktuellen zu codierenden Symbol zi entspricht, wird ausgewählt. 4. Ist zi das letzte Symbol der Zeichenfolge, so kann diese durch eine beliebige Zahl aus dem Teilintervall codiert werden. Ansonsten setzt man bei Schritt 2 fort. Beispiel

Das beschriebene Verfahren wird in Abb. 1.3 am Beispiel der Zeichenfolge abac mit den Auftrittswahrscheinlichkeiten W(a) = 0,5 sowie W(b) = W(c) = 0,25 dargestellt. Die Zeichenkette kann in diesem Fall durch eine Zahl aus [0.296875, 0.31275) codiert werden. Die Decodierung wendet das eben beschriebene Verfahren rückwärts an und muss daher nicht explizit erläutert werden.

Abb. 1.3: Arithmetische Codierung der Zeichenkette abac

Entstehung

10

■ ■ ■

Die theoretische Grundlage der arithmetischen Codierung wurde durch [Shn48] gelegt. Trotz des relativ einfachen Prinzips scheiterte eine algorithmische Umsetzung lange Zeit an der endlichen Genauigkeit von Fließkommazahlen auf Computern. Mit zunehmender Nachrichtenlänge werden die Teilintervalle sehr klein und können mit endlicher Fließkomma-Genauigkeit u. U. nicht mehr eindeutig unterschieden werden. Schließlich gelang der Nachweis, dass bestimmte endlich lange Zahlendarstellungen noch die benötigte Unterscheidbarkeit bieten. Einer der ersten Algorithmen für die technische Umsetzung der arithmetischen Codierung wurde von IBM veröffentlicht [RiL79].


1.3.3

Prädiktion Die Prädiktion zieht vorhergegangene und damit bekannte Symbole einer Nachricht heran, um Voraussagen über unbekannte Folgesymbole treffen zu können. Dies ist sinnvoll, da zwischen benachbarten Symbolen einer Nachricht häufig Abhängigkeiten bestehen. So ist in der deutschen Sprache beispielsweise eine hohe Korrelation zwischen den Buchstaben Q und U zu finden. Auch die Pixel eines Bildes können korrelieren, wenn sie demselben abgebildeten Objekt zugeordnet sind. Die Prädiktion stammt ursprünglich aus dem Bereich der Sprachverarbeitung, wo sie zur Kompression und Spracherkennung verwendet wird [AtS67]. Die Abweichung zwischen vorausgesagtem Prädiktionswert und tatsächlich auftretendem Folgesymbol wird als Prädiktionsfehler bzw. Residuum bezeichnet. Seien ǆ(n) ein Prädiktionswert und s(n) das tatsächlich auftretende Folgesymbol, so ist der Prädiktionsfehler e(n) = s(n) – ǆ(n). Mit Hilfe von Prädiktionsfehlern lassen sich Nachrichten eindeutig decodieren, indem der Decoder ebenfalls Prädiktionswerte errechnet und diese durch Addition der Prädiktionsfehler korrigiert. Durch die Symbolkorrelation bedingt, entsteht bei der Prädiktion eine starke Ungleichverteilung der Prädiktionsfehler, was wiederum eine geringere Entropie bedeutet. Daher ist die Prädiktion ein Verarbeitungsschritt, welcher die Bedingungen für eine nachfolgende Entropiecodierung verbessert. Die Prädiktion von Folgesymbolen erfolgt im einfachsten Fall als lineare Prädiktion durch das unmittelbar vorhergehende Symbol. Dieses kann entweder direkt verwendet oder vorher einer Gewichtung unterzogen werden. Der Gewichtungsfaktor wird als Prädiktorkoeffizient ak bezeichnet und muss meist fortlaufend an das Signal angepasst werden. Wenn mehr als ein Vorgängersymbol zur Prädiktion herangezogen wird, so handelt es sich um eine Prädiktion höherer Ordnung. Dies kann z. B. bei der Prädiktion von Bildinhalten sinnvoll sein, da sich ein Bildpixel genauer vorhersagen lässt, wenn mehrere umliegende Pixel, das sog. Template, berücksichtigt werden. Die lineare Prädiktion p-ter Ordnung erfolgt mit p Prädiktorkoeffizienten ak, die auch als Linear Prediction Coefficients (LPC) bezeichnet werden. Der Prädiktionswert ǆ(n) errechnet sich dann aus p vorangegangenen Symbolen als FIR-Filter nach: ˆs( n )

Prädiktionsfehler bzw. Residuum

lineare Prädiktion

Linear Prediction Coefficients (LPC)

p

¦ ak s( n k )

k 1


■ ■ ■

11

Analyse- und Synthesefilter

AR-Modellierung

Es muss folglich ein FIR-Filter mit den Filterkoeffizienten ak entwickelt werden, das die zukünftigen Symbole möglichst gut auf Basis vergangener Symbole vorhersagen kann. Dieses Filter wird Analyseoder Prädiktionsfilter genannt, während das korrespondierende Gegenstück des Decoders als Synthese- oder LPC-Filter bezeichnet wird. Gibt man das Prädiktionsfehler-Signal, das vom Analysefilter errechnet wurde, unverändert in das Synthesefilter hinein, so kann das ursprüngliche Signal ohne Fehler rekonstruiert werden. Eine etwas andere, wenn auch verwandte Aufgabe stellt sich mit der AR-Modellierung auf dem Gebiet der parametrischen Sprachkompression (Kap. 1.9.2). Dort wird ein Synthese-Filter gesucht, das ein stationäres Anregungssignal, wie z. B. ein weißes Rauschen, möglichst gut an das zu codierende Sprachsignal annähert. Zwischen linearer Prädiktion und AR-Modellierung besteht ein sehr enger Zusammenhang, der in [KaK02] ausführlich erläutert wird. Prinzipiell arbeitet die Prädiktion verlustfrei, sofern die errechneten Prädiktionsfehler nicht quantisiert werden. Quantisierung bietet sich an, wenn die Prädiktionsfehler rational sind, was eine weitere Verarbeitung erschweren würde. In vielen Verfahren zur Bildkompression wird die Prädiktion nicht direkt auf Bildpunkte angewendet. Statt dessen wird das Bild zunächst in eine Repräsentation überführt, die sich besser für den Einsatz einer prädiktiven Codierung eignet. Dies geschieht bspw. durch Signaltransformationen, die im Folgenden erläutert werden.

1.3.4

Signaltransformationen Wie die Prädiktion zielen auch Signaltransformationen darauf ab, die Korrelation zwischen Nachrichtensymbolen zu verringern, und so die Effizienz nachfolgender Verarbeitungsschritte zu steigern. Um eine anschaulichere Darstellung zu ermöglichen, liegen den folgenden Erläuterungen Bilddaten zugrunde. Signaltransformationen sind jedoch nicht auf solche Daten beschränkt. 1.3.4.1 Diskrete Kosinustransformation Die diskrete Kosinustransformation (DCT) als Sonderfall der Fouriertransformation existiert in verschiedenen Ausprägungen, die von [Wan84] erstmals in vier Transformationstypen eingeteilt wurden. Bei der Bilddatenkompression wird die DCT-II nach [ANR74] verwendet. Die DCT-II und die zugehörige inverse Transformation werden im Folgenden nur noch als DCT bzw. IDCT bezeichnet. Die DCT zur

12

■ ■ ■


Transformation zweidimensionaler Bilder wird auf quadratische Teilbereiche des Bildes angewendet und arbeitet auf Basis einzelner Bildpixel. Bei einem quadratischen Bildausschnitt von N u N Pixeln wird jedes Pixel f(x,y) wie folgt transformiert: F( u ,v )

N 1N 1 2 ª( 2 x 1 ) u S º ª( 2 y 1 ) v S º C u C v ¦ ¦ f ( x , y ) cos « cos « » » N 2N 2N ¬ ¼ ¬ ¼ x 0y 0

Die IDCT ist: f ( x, y )

2 N 1N 1 ª( 2 x 1 ) u S º ª( 2 y 1 ) v S º ¦ ¦ Cu Cv F ( u , v ) cos « » cos « » N u 0v 0 2N 2N ¬ ¼ ¬ ¼

Dabei gilt für die beiden Gleichungen: Cu

1 für u 0 ° und Cv ® 2 °¯ 1 für u z 0

1 für v 0 ° ® 2 °¯ 1 für v z 0

Die DCT transformiert das Bildsignal vom Orts- in den Frequenzbereich und zerlegt es dazu in Kosinus-Basisfunktionen unterschiedlicher Frequenz. Jeder Bildausschnitt mit N u N Pixeln resultiert in N u N Koeffizienten, die als zweidimensionale Frequenzangaben interpretiert werden können. Hohe Frequenzen repräsentieren im Ortsbereich feine Bildstrukturen, niedrige Frequenzen dagegen homogene Flächen. In Abb. 1.4 ist der Ausschnitt eines Graustufenbildes zu sehen. Es handelt sich dabei um einen Bildbereich aus 8 u 8 Pixeln, wie er z. B. auch vom JPEG-Standard verwendet wird (Kap. 1.6.1). Das Graustufenbild ist mit 8 Bit pro Pixel quantisiert, weshalb die einzelnen Pixel Graustufenwerte von 0 bis 255 besitzen können.

Orts- und Frequenzbereich

Beispiel

Abb. 1.4: Quadratischer Pixelblock eines Graustufenbildes


■ ■ ■

13

Abb. 1.5: DCT-Koeffizienten eines Pixelblocks

DC-Koeffizient und AC-Koeffizienten

Weiterverarbeitung durch Entropieund Lauflängencodierung

14

■ ■ ■

Abbildung 1.5 zeigt die gerundeten DCT-Koeffizienten des transformierten Pixelblocks. In Anlehnung an die englischen Bezeichnungen für Gleich- und Wechselstrom lassen sich die Koeffizienten in einen DC-Koeffizient und 63 AC-Koeffizienten unterscheiden. Der DC-Koeffizient, der häufig auch als Gleichanteil bezeichnet wird, entspricht dem Anteil der Frequenz 0 Hz in beiden Bildachsen und repräsentiert den mittleren Farbton bzw. Grauwert des 8 u 8 Pixelblocks. Die AC-Koeffizienten entsprechen Frequenzen größer 0 Hz in horizontaler und vertikaler Richtung. So entspricht der Koeffizient AC7 beispielsweise der höchsten Frequenz, die im Pixelblock innerhalb der horizontalen Bildachse auftritt. Im Ortsbereich ist dies das dichtest mögliche Muster senkrechter Streifen innerhalb des Pixelblocks. Da viele Bilder hauptsächlich aus flächigen Bereichen und nur zu einem geringen Teil aus scharfen Kanten bestehen, werden DCT-Koeffizienten, die höhere Frequenzen repräsentieren, sehr häufig niedrige Werte annehmen, wie auch in Abb. 1.5 beispielhaft zu erkennen ist. Die DCT-Koeffizienten sind also oft ungleich verteilt, und weisen somit eine geringe Entropie auf. Dies machen sich Verfahren zur Bild- und Videokompression zu Nutze und unterziehen die Koeffizienten einer nachfolgenden Entropiecodierung. Indem die Koeffizienten zuvor quantisiert werden, lässt sich die Kompression weiter optimieren. Durch die Quantisierung nehmen viele der kleineren Koeffizienten den Wert 0 an und können durch eine Lauflängencodierung zusammengefasst werden. DCT-Koeffizienten können durch die IDCT theoretisch ohne Informationsverluste in die ursprünglichen Graustufenwerte zurück transformiert werden. In der Praxis lassen sich DCT und IDCT jedoch nur annähernd genau berechnen und die diskrete Kosinustransformation ist verlustbehaftet.


1.3.4.2 Wavelet-Transformation

Obwohl ein erstes Wavelet schon sehr früh im Rahmen der HaarTransformation [Haa10] beschrieben wurde, entstand eine zusammenhängende Wavelet-Theorie erst in den 80er Jahren, nachdem Grossmann u. Morlet [GrM84] den Wavelets ihren Namen gegeben und eine genauere Beschäftigung mit dem Thema ausgelöst hatten. Wie die DCT wandelt die Wavelet-Transformation das Bildsignal in den Frequenzbereich. Anstelle einer Kosinusfunktion werden dabei jedoch die Wavelets einer Wavelet-Familie als Transformationskern verwendet. Diese Wavelets erhält man durch einfache Modifikationen eines Mutter-Wavelets, von denen einige in Abb. 1.6 zu sehen sind. Das Haar-Wavelet ist sehr einfach aufgebaut und besitzt nur eingeschränkte Funktionalität, da es u. A. nicht differenzierbar ist. Aufgrund ihrer mathematischen Eigenschaften werden in der Signalverarbeitung oft Daubechies-Wavelets [Dau88] eingesetzt. Diese Wavelets lassen sich nicht funktionsanalytisch darstellen, sondern werden iterativ erzeugt. Durch die Wahlmöglichkeit eines Mutter-Wavelets und durch die Verwendung verschiedener Wavelets einer Wavelet-Familie ist die Wavelet-Transformation flexibler als die DCT mit ihrer festgelegten Basisfunktion. Mutter-Wavelets können durch Verschiebungen auf der Abszisse und durch Skalierungen modifiziert werden. Durch Dehnung des Wavelets lassen sich stationäre Signalabschnitte erfassen, für die man eine gute Frequenzauflösung erhält, während sich gestauchte Wavelets mit hoher Frequenz für wechselhafte Signalabschnitte eignen, in denen eine gute zeitliche bzw. örtliche Auflösung gewünscht ist. Wavelets ermöglichen demnach eine Kombination aus Frequenzanalyse und zeitlicher bzw. örtlicher Analyse. Funktionswerte von Wavelets sind außerhalb eines engen Intervalls 0, während Kosinusfunktionen unendlich periodisch verlaufen. Durch diesen kompakten Träger wirken Wavelets immer nur auf einen Teilbereich des Bild- oder Tonsignals, und eine Aufteilung in Blöcke, wie z. B. bei der DCT, ist nicht mehr erforderlich.

Funktionsprinzip, Wavelet-Arten

Modifikation von Mutter-Wavelets

Abb. 1.6: Wavelets


■ ■ ■

15

Multiskalen-Analyse

schnelle Wavelet-Transformation (FWT)

Beispiel

Die Multiskalen-Analyse [Mal89] führt eine Skalierungsfunktion als Basis der Wavelet-Familie ein und ermöglicht so eine effiziente algorithmische Umsetzung der Transformation. Diese wird als schnelle Wavelet-Transformation (FWT) bezeichnet und lässt sich als Kombination spezieller Hoch- und Tiefpass-Filter auffassen. In der Bilddatenkompression wird die FWT meist nacheinander auf die Zeilen und Spalten des Bildes angewendet. Zunächst werden die Zeilen des Ausgangsbildes transformiert. Durch den TiefpassFilter erhält man eine geglättete, unscharfe Version des Bildes, der Hochpass resultiert in feinen Detailinformationen. Zusätzlich wird die Bildauflösung durch Subsampling reduziert, indem jedes zweite Pixel verworfen wird. Derselbe Vorgang wird nun auf die Spalten angewendet, wodurch man insgesamt vier verkleinerte Versionen des Ausgangsbildes erhält. Die Bildversion, deren Spalten und Zeilen Tiefpass-gefiltert wurden, kann nun mehrere Male auf dieselbe Weise weiterverarbeitet werden, wobei in jedem Verarbeitungsschritt vier weitere verkleinerte Bildversionen entstehen. Die drei anderen Bildversionen enthalten Detailinformationen, die mit senkrechten, waagerechten bzw. diagonalen Kanten innerhalb des Bildinhaltes korrespondieren. Durch die schrittweise Verarbeitung durch Filter erhält man eine unscharfe Repräsentation des Originalbildes in sehr geringer Auflösung, sowie mehrere Bilder mit Detailinformationen in unterschiedlichen Auflösungen. In Abb. 1.7 ist dies anhand der ersten zwei Verarbeitungsschritte mit einem Haar-Wavelet zu sehen. Bei der Dekompression wird die gering aufgelöste Bildrepräsentation sukzessive durch die Detailinforma-

Abb. 1.7: Zwei Verarbeitungsschritte der schnellen Wavelet-Transformation

16

■ ■ ■


tionen angereichert, was als hierarchische Kompression bezeichnet wird. Hierarchische Kompression ist auch schon im JPEG-Standard (Kap. 1.6.1) als spezieller Modus verfügbar, allerdings auf Basis einer DCT. Die Dekompression des Bildes muss nicht komplett erfolgen, sondern kann gestoppt werden, wenn eine ausreichend hohe Auflösung erreicht wurde. Die Wavelet-Transformation kann in der Bildverarbeitung anstelle der DCT eingesetzt werden, wodurch sich die eingangs geschilderten Vorteile der Wavelets nutzen lassen. Wie bei der DCT werden die resultierenden Koeffizienten durch eine Quantisierung und Entropiecodierung weiterverarbeitet. Die FWT ist bei Wahl eines geeigneten Wavelets und zugehöriger Skalierungsfunktion ein verlustfreier Vorgang. Trotz des Subsamplings lässt sich das Bild ohne Informationsverlust rekonstruieren. Erst durch eine entsprechende Quantisierung wird die Wavelet-Kompression zum verlustbehafteten Vorgang.

Eigenschaften

1.4 Medienspezifische Verarbeitungsschritte Neben elementaren Verarbeitungsschritten, die sich für die Datenkompression sehr vielseitig einsetzen lassen, existieren auch medienspezifische Verarbeitungsschritte, bei denen die Charakteristiken bestimmter Medientypen ausgenutzt werden.

1.4.1

Interframe-Kompression Bei der Kompression von Videodaten lassen sich besonders hohe Kompressionsraten erzielen, wenn zusätzlich zu örtlichen Redundanzen innerhalb eines Einzelbildes auch zeitliche Redundanzen zwischen aufeinander folgenden Bildern berücksichtigt werden. In vielen Fällen sind Folgebilder einer Videosequenz sehr ähnlich, da sich von Bild zu Bild nur begrenzte Bereiche unterscheiden. Werden auch zeitliche Redundanzen für die Kompression ausgenutzt, so spricht man von Interframe-Kompression. Im Gegensatz dazu verarbeitet die Intraframe-Kompression einzelne Videobilder separat und berücksichtigt somit nur örtliche Redundanz. Ein möglicher Ansatz für die Interframe-Kompression ließe sich realisieren, indem die Prädiktion nach Kap. 1.3.3 um eine Dimension für die Zeit erweitert wird. Um jedoch exaktere zeitliche Vorhersagen zu erhalten, werden Bewegungen innerhalb des Bildinhalts abgeschätzt. Dabei beschränkt man sich in der Regel auf translatorische

1.4 Medienspezifische Verarbeitungsschritte

Interframe- und IntraframeKompression

■ ■ ■

17

Bewegungsschätzung

Blockmatching, Bewegungsvektoren

Bewegungen und verzichtet auf die Prädiktion von Rotationen, Skalierungen, Verzerrungen usw. Im einfachsten Fall werden bei der Bewegungsschätzung ausschließlich Luminanzwerte von Pixeln betrachtet, und Voraussagen über die Bewegung erfolgen ohne Berücksichtigung einer Semantik. Die Bedeutung der Bildinhalte spielt also keine Rolle, und es wird ausschließlich die Ähnlichkeit unterschiedlicher Bildausschnitte bewertet. Ein solches Verfahren kommt bspw. für die MPEG-1-Kompression (Kap. 1.7.1) zum Einsatz, verarbeitet dort quadratische Pixelblöcke und wird als Blockmatching bezeichnet. Das Funktionsprinzip basiert auf einer Publikation von [RoZ72] und wird im Folgenden näher erläutert. Zunächst wird die Y-Komponente des Originalbilds in Makroblöcke aus 16 u 16 Pixeln zerlegt. Diese Blockgröße resultiert aus einem Kompromiss zwischen exakter Bewegungsschätzung durch möglichst kleine Blöcke und geringem Codierungsaufwand durch eine möglichst geringe Block-Anzahl. Da die CrCb-Komponenten meist geringer aufgelöst sind als die Y-Komponente, werden sie nicht für die Bewegungsschätzung herangezogen. Für jeden Makroblock muss nun ein korrespondierender Block im Folgebild gefunden werden, dessen Bildinhalt möglichst genau übereinstimmt. Dazu empfiehlt der MPEG-1-Standard verschiedene Suchstrategien, die jedoch nicht verbindlich sind. Hersteller von Encodern besitzen so die Freiheit, individuelle Optimierungen bei der Blocksuche einzusetzen. Für die Beurteilung der Übereinstimmung von Blöcken können unterschiedliche Abstandsmaße verwendet werden, wie z. B. die mittlere absolute Differenz. Die Positionen der gefundenen Blöcke werden als zweidimensionale Bewegungsvektoren abgespeichert. Diese geben an, wie die ursprünglichen Blöcke verschoben werden müssen, um an die Positionen der korrespondierenden Blöcke im Folgebild zu gelangen (Abb. 1.8). Vektoren für die Chrominanzkanäle werden unter Berücksichtigung des Subsamplings aus den Bewegungsvektoren der Y-Komponente errechnet.

Abb. 1.8: Funktionsprinzip der vorwärtsgerichteten Prädiktion

18

■ ■ ■


Bewegungsvektoren werden bei MPEG-1 durch lineare Interpolation mit einer Genauigkeit von ½ Pixel ermittelt. Es ist jedoch auch eine einfache, ganzzahlige Pixelgenauigkeit erlaubt. Der Wertebereich der Vektoren-Elemente ist eingeschränkt, wobei je nach Verschiebungsgenauigkeit zwei verschiedene Wertebereiche definiert sind. Vektoren, die über die Bildränder hinauszeigen, sind unzulässig. Nachdem durch die Bewegungsschätzung alle Vektoren errechnet wurden, erzeugt die Bewegungskompensation ein Prädiktionsbild. Dazu werden alle Makroblöcke des Originalbilds so verschoben, wie von Bewegungsvektoren vorgegeben. Man erhält dadurch ein Prädiktionsbild, das mosaikartig aus Blöcken zusammengesetzt ist. Der Unterschied zwischen diesem Prädiktionsbild und dem Originalbild wird als Prädiktionsfehler codiert. Abbildung 1.9 zeigt zwei aufeinander folgende Videobilder, in denen der Regler des abgebildeten Mischpults nach oben bewegt wird. Darunter sind Prädiktionsbild und Prädiktionsfehlerbild zu sehen.

Bewegungskompensation

Beispiel

Abb. 1.9: Vorwärtsgerichtete Prädiktion am Beispiel

Das oben geschilderte Blockmatching wird als vorwärtsgerichtete Prädiktion bezeichnet, da ein zeitlich folgendes Bild vorhergesagt wird. Vorwärtsgerichtete Prädiktion kann jedoch nicht immer erfolgreich sein, da in Folgebildern häufig neue Elemente auftauchen, die in vorhergehenden Bildern verdeckt waren oder sich außerhalb des Bildrahmens befanden. Daher setzt MPEG-1 zusätzlich bidirektionale Prädiktion ein, wobei die Bewegungsschätzung auch im vorhergehenden Bild nach ähnlichen Blöcken sucht. So ergeben sich für jeden Makroblock zwei Bewegungsvektoren, von denen derjenige in den


vorwärtsgerichtete und bidirektionale Prädiktion

■ ■ ■

19

Korrelation bei benachbarten Makroblöcken

Datenstrom eincodiert wird, der den kleineren Prädiktionsfehler erzeugt. Als weitere Variante können auch beide Vektoren im Datenstrom verwendet werden, wobei der Decoder zur Prädiktion einen Mittelwert der Vektoren heranzieht. Da die Blockstruktur des Blockmatchings nur in den seltensten Fällen mit der Struktur von Bildinhalten übereinstimmt, sind immer relativ große Prädiktionsfehler zu erwarten. Dies gilt auch für Bewegungen, die sich nicht durch das Verschieben von Blöcken erfassen lassen, wie z. B. Veränderungen der Lichtverhältnisse oder Skalierungen. Trotzdem ist Blockmatching ein relativ leistungsfähiges Verfahren und lässt sich einfach implementieren. Insgesamt können Bewegungsvektoren bis zu 40% der gesamten Information eines komprimierten Video-Datenstroms ausmachen [ChP89]. Darüber hinaus sind die Vektoren benachbarter Makroblöcke stark korreliert. So stimmen insbesondere bei Kameraschwenks viele der Vektoren weitgehend überein. Daher ist auch für die Codierung der Vektoren der Einsatz von Prädiktion sinnvoll. Für MPEG-1 verwendet man bspw. eine einfache Delta-Codierung und sagt Bewegungsvektoren für die bidirektionale Prädiktion nur aus Vektoren derselben Richtung vorher.

1.4.2

Psychoakustische Kompression psychoakustisches Modell, Perceptual Coder

MP3

Schalldruckpegel

20

■ ■ ■

Unter psychoakustischer Kompression versteht man die verlustbehaftete Kompression von Audiodaten mit Hilfe eines psychoakustischen Modells. Ein solches Modell beschreibt Grenzen des menschlichen Gehörs und ermöglicht dadurch effektive Irrelevanzreduktion. Da sie das subjektive Hörempfinden betreffen, lassen sich psychoakustische Modelle nur durch umfangreiche Testreihen mit Versuchspersonen empirisch ermitteln. Encoder, die ein psychoakustisches Modell verwenden, werden als Perceptual Coder bezeichnet. Weltweite Bekanntheit erlangte die Kompression unter Einsatz eines psychoakustischen Modells durch MP3, das am Erlanger Fraunhofer Institut für Integrierte Schaltungen (IIS) entwickelt wurde [BrS94]. MP3 ist Teil des internationalen Standards MPEG-1 (Kap. 1.7.1) für die Kompression von Video- und Audiodaten. Im MPEG-1-Standard werden 3 Audio-Layer definiert, die sich bezüglich Komplexität und Kompressionsleistung unterscheiden. MP3 bezeichnet Audiodateien, die gemäß Layer III codiert sind. Psychoakustische Modelle nutzen mit Simultanverdeckung und zeitabhängiger Verdeckung zwei Eigenschaften des menschlichen Gehörs, die im Folgenden nach [ZwF99] dargestellt werden. Der


Schalldruckpegel Lp eines Schallereignisses mit dem Schalldruck p1 -5 ergibt sich, indem p1 zum Bezugsschalldruck p0 = 2 10 [Pa] ins Verhältnis gesetzt, und das Resultat nach folgender Formel logarithmiert und gewichtet wird: Lp

20 lg

p1 [Pa] p0

Zeichnet man den benötigten Schalldruckpegel, um einen Sinuston T gerade wahrzunehmen, als Funktion der Frequenz von T auf, so erhält man die Ruhehörschwelle. Schallereignisse unterhalb der Ruhehörschwelle sind für das menschliche Gehör nicht wahrnehmbar und können daher durch Irrelevanzreduktion eliminiert werden. Das Gehör weist nicht für alle Frequenzen die gleiche Empfindlichkeit auf, sondern ist für Frequenzen von 2 bis 5 kHz am sensibelsten. Demnach ist die wahrgenommene Lautstärke und damit auch die Ruhehörschwelle nicht nur vom Schalldruckpegel sondern auch von der Frequenz des Schalls abhängig (Abb. 1.10). Die Simultanverdeckung betrifft Verdeckungseffekte durch stationäre Schallereignisse, die zeitgleich auftretende Signalkomponenten mit gleicher und abweichender Frequenz verdecken. Solche verdeckenden Schallereignisse werden als Maskierer bezeichnet. Verdeckungseffekte lassen sich als Anhebung der Ruhehörschwelle für die verdeckten Komponenten interpretieren (Abb. 1.11). Simultan verdeckende Maskierer bewirken folglich, dass die Hörschwelle für andere, zeitgleiche Schallereignisse angehoben wird. Fallen Schallereignisse dabei nur teilweise unter die Hörschwelle, so handelt es sich um Teilverdeckung, die zur Lautstärkereduktion der teilverdeckten Signalkomponente führt.

Ruhehörschwelle

Simultanverdeckung, Maskierer

Abb. 1.10: Ruhehörschwelle des menschlichen Gehörs


■ ■ ■

21

Abb. 1.11: Simultanverdeckung

zeitliche Verdeckung

Quantisierungsrauschen

22

■ ■ ■

Zeitliche Verdeckungseffekte betreffen zeitlich aufeinander folgende Schallereignisse von kurzer Dauer und können in Vor- und Nachverdeckung unterschieden werden. Nachverdeckung besagt, dass das Gehör nach einem maskierenden Schallereignis eine Zeit von etwa 150 ms benötigt, bis sich die Ruhehörschwelle wieder normalisiert hat. Es kommt dabei zu Verdeckungseffekten, obwohl der Maskierer physikalisch nicht mehr existiert, da bereits angeregte Nervenzellen weniger sensitiv reagieren als ruhende Zellen. Vorverdeckung wirkt sich aus, bevor der Maskierer auftritt, was logisch vielleicht schwerer zu fassen ist. Vorverdeckung entsteht, da das Gehör eine begrenzte zeitliche Auflösung besitzt, und ein unvollständig verarbeitetes Schallereignis von der nachfolgenden Signalkomponente verdeckt wird. Perceptual Coder quantisieren Audiosignale sehr grob, so dass das rekonstruierte Signal dem ursprünglichen Signalverlauf nur noch schlecht folgen kann. Dadurch entsteht mit dem sog. Quantisierungsrauschen ein rauschartiges Störgeräusch, das vom Audiosignal moduliert wird und sich folglich mit dem Signalverlauf ändert. Im Vergleich zu konstantem Hintergrundrauschen wird Quantisierungsrauschen subjektiv als besonders störend empfunden. Die beschriebenen Verdeckungseffekte werden nun genutzt, um dieses Quantisierungsrauschen geschickt zu maskieren. So können teilweise sehr grobe Quantisierungsstufen eingesetzt und dadurch hohe Kompressionsraten erzielt werden. Bei der psychoakustischen Kompression handelt es sich also im Wesentlichen um variable Quantisierung, die durch ein psychoakustisches Modell gesteuert und als Rauschformung bezeichnet wird. Durch Versuchsreihen wurde ermittelt, dass der Schneckengang des Innenohrs (lat.: Cochlea) Schallereignisse in Teilbänder zerlegt, und das Gehör nur ein eingeschränktes Auflösungsvermögen für Frequenzen besitzt. Das Auflösungsvermögen ist nicht linear, sondern beträgt in den tiefen Frequenzen etwa 50 Hz und verschlechtert sich


mit zunehmender Frequenz bis etwa 4 kHz. Dabei ist es keinesfalls so, dass Frequenzen innerhalb eines Teilbands nicht unterschieden werden können. Die Hörschwelle für Quantisierungsrauschen kann jedoch separat für jedes Teilband ermittelt werden und hängt nur von Schallereignissen innerhalb des Teilbands ab. Die Teilbänder des menschlichen Gehörs werden als kritische Frequenzgruppen bezeichnet. Alle psychoakustischen Kompressionsverfahren zerlegen das Eingangssignal in Frequenzbänder und bestimmen die Quantisierung mit Hilfe des psychoakustischen Modells für jedes Subband separat. Die quantisierten Koeffizienten werden abschließend meist einer Lauflängen- und Huffman-Codierung unterzogen. Audiodaten, die mit einem Perceptual Coder komprimiert wurden, eignen sich nicht für die Nachbearbeitung. Eine Veränderung der Klangcharakteristik, z. B. durch Anpassung von Höhen oder Bässen, verändert nachträglich auch die Entscheidungsgrundlage des psychoakustischen Modells, wodurch das Quantisierungsrauschen wieder hörbar werden kann.

Nachbearbeitung

1.5 Codecs im Überblick Die Joint Photographic Experts Group (JPEG), die Moving Picture Experts Group (MPEG) und die ITU sind prominente Gremien im Bereich der Mediendaten-Kompression. Die JPEG-Gruppe entwickelte mit dem gleichnamigen JPEG-Format einen der ersten Standards [ISO94] [ITU92b] für die Standbildkompression, dessen grundlegende Verarbeitungsschritte auch in Video-Kompressionsverfahren der ITU und MPEG-Gruppe verwendet werden. Während die ITU Video- und Audiokompression getrennt betrachtet, definiert die MPEG-Gruppe Methoden, um Audio- und Videodaten in einem einzigen Datenstrom unterzubringen. Da die ITU hauptsächlich im Telekommunikationsbereich tätig ist, sind ihre Empfehlungen traditionell durch Anwendungen wie Bildtelefonie und Videokonferenzen motiviert. Die MPEG-Gruppe, deren Verfahren durch die International Organization for Standardization und International Electrotechnical Commission (ISO/IEC) standardisiert werden, hat ihren Schwerpunkt stärker in den Bereichen Unterhaltungselektronik und Fernsehen. Während man diese zwei Lager anhand der ersten Veröffentlichungen noch relativ gut unterscheiden konnte, sind neuere Kompressionsverfahren der beiden Gremien sehr universell einsetzbar. Um patentrechtlichen Schwierigkeiten bei der Implementierung der MPEG-Standards entgegenzutreten, wurde die MPEG Licensing Authority (MPEG-LA) gegründet, die mit der Lizenzierung der Stan-

1.5 Codecs im Überblick

Standardisierungsgremien

MPEG-Gruppe und ITU im Vergleich

MPEG Licensing Authority (MPEG-LA)

■ ■ ■

23

dards und der Abwehr übertriebener oder unberechtigter Forderungen befasst ist. Firmen, die patentierte Algorithmen einbringen, stellen diese in einem Patentpool zur Verfügung. Der Pool wird von der MPEG-LA genutzt, um MPEG zu Konditionen zu lizenzieren, die eine wirtschaftliche Nutzung und schnelle Verbreitung der Standards fördern.

1.5.1

Video-Codecs Überblick zu Video-Codecs

In Abb. 1.12 ist die Entwicklung der ITU- und MPEG-Verfahren, sowie von Apples Quicktime und Microsofts Windows Media zu sehen. Die Verfahren von ITU und MPEG sind nicht unabhängig voneinander

Abb. 1.12: Entwicklung von Kompressionsverfahren und Medienarchitekturen

24

■ ■ ■


entstanden, sondern hatten teilweise beträchtlichen Einfluss aufeinander. Der ITU-Codec H.261 [ITU93] gilt als erster praktisch eingesetzter Video-Codec und wurde bei der Entwicklung des internationalen Standards MPEG-1 [ISO93a] berücksichtigt, der das Audioformat MP3 etablierte. Der Nachfolger MPEG-2 [ISO00] entstand zu großen Teilen als Kooperation zwischen ITU und MPEG-Gruppe – die ITU-Empfehlung H.262 [ITU95b] und die Videokompression nach MPEG-2 sind identisch. Daraufhin arbeitete die ITU wieder einige Zeit an eigenen Verfahren und veröffentlichte insgesamt drei Versionen des Codecs H.263 [ITU05a]. Die MPEG-Gruppe plante zeitgleich MPEG-3. Allerdings stellte sich heraus, dass sich die Verfahren von MPEG-2 soweit optimieren ließen, dass die anvisierten Verbesserungen durch MPEG3 auch im Rahmen des Standards MPEG-2 erreicht werden konnten. Daher wurde die Entwicklung von MPEG-3 nicht abgeschlossen. Der nächste MPEG-Standard trägt die Bezeichnung MPEG-4 [ISO04a] und konnte stark von den beiden ersten Versionen des H.263-Codecs der ITU profitieren. Bei der Konzeption des Dateiformats für MPEG-4 wurde das Dateiformat von Quicktime als Basis herangezogen. Im Rahmen des Joint Video Teams (JVT) entstand 2001 wieder eine Zusammenarbeit von ITU und MPEG-Gruppe. Das Resultat war der ITUCodec H.264 [ITU05b], der als Advanced Video Coding (AVC) in MPEG-4 übernommen wurde. Zu jedem Kompressionsverfahren existiert eine Vielzahl kommerzieller Umsetzungen. Bekannte MPEG-4-Implementierungen sind bspw. DivX und sein freies GNU-Pendant XviD. Ein Software-Codec nach H.264/AVC wird u. A. vom deutschen Hersteller MainConcept angeboten. Auch Apple hat den H.264-Codec in Quicktime integriert, und verwendet dabei den Video Codec 3 der Firma Sorensen. Apple entwickelte mit Quicktime schon sehr früh eine konsistente, proprietäre Medienarchitektur, die eine Vielzahl von Kompressionsverfahren in Form unterschiedlicher Codecs bzw. Decoder integriert. Quicktime umfasst ein Container-Dateiformat, in dem Mediendaten abgelegt werden können, die mit unterschiedlichen Kompressionsverfahren codiert wurden, eine Abspielsoftware mit Bearbeitungsfunktionalität, sowie umfangreiche Streaming-Tools und ein API. Im Rahmen von Apple-Programmen wie Final Cut und DVD Studio Pro hat sich QuickTime als professionelles Produkt im Medienbereich etabliert. Die Entstehung von Microsofts Windows Media ist schwieriger nachzuzeichnen als die Entwicklung von Quicktime. Mit der Softwareschnittstelle Video for Windows war es in den Anfangszeiten von Windows erstmals möglich, einfache Mediendateien im AVI-Format abzuspielen und Videos zu codieren. Wie das Dateiformat von Quicktime ist das AVI-Format ein Container, der Mediendaten enthalten kann, die mit unterschiedlichen Codecs komprimiert wurden. Die


Quicktime

Windows Media

■ ■ ■

25

hybride Video-Codecs

26

■ ■ ■

Abkürzung AVI steht für Audio Video Interleave und bezeichnet eine überlappende Art der Speicherung von Audio- und Videodaten, die eine einfache Synchronisation von Bild und Ton ermöglicht. Mit der Entstehung von MPEG wurden Schwächen des AVI-Formats deutlich, da es sich u. A. nicht für die Speicherung von MPEG-Datenströmen eignet. Darüber hinaus können im AVI-Format keine zeitlichen Timecode-Informationen integriert werden. Microsoft gab AVI daher zugunsten des Advanced Streaming Formats (ASF) auf, und entwickelte das SDK ActiveMovie. Durch ActiveMovie und das Container-Format ASF unterstützte Windows nun auch MPEG und das QuicktimeFormat. Wenig später begann Microsoft, ActiveMovie schrittweise in sein DirectX zu integrieren und führte die neue Bezeichnung DirectShow ein. Das Advanced Streaming Format erfuhr eine Umbenennung zu Advanced Systems Format, wobei jedoch dieselbe Abkürzung beibehalten wurde. Im Laufe der Zeit kamen weitere Elemente zu ASF hinzu, wie z. B. ein Digital Rights Management. Diese Komponenten werden in ihrer Gesamtheit als Windows Media Plattform bezeichnet. Die Plattform umfasst mit Windows Media Video und Audio (WMV/WMA) auch Microsoft-eigene, proprietäre Codecs für die Audio- und Videokompression, die im Container-Format ASF untergebracht werden können. Eine Erweiterung des WMV-Codecs in der Version 9 (WMV9) unterstützt hoch auflösendes Video in High Definition und ist auch als WMV HD bekannt. Um im Fernsehgeschäft Fuß zu fassen, veröffentlichte Microsoft den Decoder und die Bitstromsyntax des vormals proprietären WMV9 und konnte die Society of Motion Picture and Television Engineers (SMPTE) für sich gewinnen. Nun plant die SMPTE, WMV9 unter der Bezeichnung VC-1 als ersten eigenen Standard für die Videokompression zu veröffentlichen. Der VC-1 ist neben H.264 und MPEG-2 auch auf den konkurrierenden, hoch auflösenden DVD-Nachfolgern HD-DVD und Blu-ray Disc vertreten. VC-1 ist etwas einfacher aufgebaut als H.264, scheint im Hinblick auf die Bildqualität aber vergleichbare Ergebnisse zu erzielen [Die05]. Die große Mehrzahl der bisher veröffentlichten Video-Codecs von ITU und MPEG sind hybride Codecs, die Signaltransformationen und Prädiktion kombinieren. Die Codierung der Einzelbilder erfolgt dabei in der Regel durch eine DCT quadratischer Pixelblöcke, die von der Standbildkompression mit JPEG übernommen wurde (Abb. 1.12). Für die Reduktion zeitlicher Redundanz kommt Interframe-Kompression auf Basis von Blockmatching und Prädiktion zum Einsatz. Ausnahme ist hier Motion JPEG (MJPEG), das Einzelbilder separat mit dem JPEG-Verfahren komprimiert, ohne zusätzliche Prädiktion zu verwenden. Ebenso besitzt der JPEG-Nachfolger JPEG 2000 [ISO04c] eine Sonderstellung, da er auf Wavelet-Transformation basiert. Wie


MJPEG codiert auch MJPEG 2000 ausschließlich separate Einzelbilder und verwendet keine Interframe-Kompression. Die Bilddaten-Kompression mit Wavelets ist nicht anfällig für blockartige Störungen (Blockartefakte), welche durch die Transformation einzelner Pixelblöcke entstehen können. Inzwischen herrscht weitgehende Übereinstimmung, dass sich im Bereich der StandbildKompression mit Wavelets eine bessere Bildqualität und höhere Kompressionsraten erzielen lassen als mit der DCT [XRO99]. Im Bereich der Videokompression konnte sich die Wavelet-Transformation dagegen noch nicht eindeutig gegenüber den blockbasierten Verfahren durchsetzen. Dies zeigt sich am deutlichsten daran, dass ITU und MPEG mit dem relativ neuen H.264/AVC noch immer auf eine blockbasierte Transformation setzen. Durch die Wahl flexibler Blockgrößen und Filteralgorithmen können Blockartefakte bei H.264/AVC weitgehend unterdrückt werden. Abseits der Gremien von ITU und MPEG gibt es inzwischen etliche Implementierungen von Wavelet-Codecs für die Videokompression. So veröffentlichte die British Broadcasting Corporation den Open-Source-Codec BBC Dirac [BDS05]. Ein verbreiteter kommerzieller Codec ist MotionWavelets von Aware.

Wavelet-Kompression und blockbasierte Verarbeitung

1.5.2

Audio-Codecs Audio-Codecs können in Codecs für die Sprachkompression und generische Codecs, die sich für beliebiges Audiomaterial einsetzen lassen, unterschieden werden. Im Bereich der Sprachkompression lassen sich mit Signalformcodierern, parametrischen und hybriden Verfahren wiederum drei Untergruppen identifizieren. Signalformcodierer zielen darauf ab, die Signalverläufe auf Basis einzelner Samples zu codieren und die ursprüngliche Signalform möglichst gut zu repräsentieren. Sie arbeiten gänzlich unabhängig vom Signalinhalt und sind daher für jede Art von Audiodaten geeignet. Der Einsatz des Signalform-Verfahrens ist nur für Bitraten von 32 kbit/s an aufwärts sinnvoll, da die Qualitätseinbußen bei geringeren Datenraten schnell groß werden [Chu03]. Zu den Signalformcodierern zählen u. A. die ITU-Codecs G.711 [ITU88a], G.722 [ITU88b], G.726 [ITU90a] und G.727 [ITU90b], die fast alle einfache prädiktive Techniken verwenden. Parametrische Codecs zerlegen das Audiosignal in Signalkomponenten, die sich durch Modelle beschreiben lassen. In Form von Modellparametern können diese dann kompakt codiert werden. Parametrische Verfahren erzielen hohe Kompressionsraten, sind aber im Gegensatz zu Signalformcodierern nur für bestimmte Signalarten


Sprachkompression

Signalformcodierer

Parametrische Codecs

■ ■ ■

27

Hybride Codecs

universelle Audiokompression

28

■ ■ ■

geeignet. Typische Datenraten parametrischer Verfahren sind 2 bis 5 kbit/s. Eine Erhöhung der Bitrate führt nicht zu qualitativ besseren Ergebnissen, weil die jeweiligen Modelle bestimmte Grenzen besitzen. Ein parametrisches Verfahren wird vom Codec des NATO Standardization Agreements STANAG 4591 [NC302] beschrieben. Für die zivile Kommunikation werden parametrische Verfahren aufgrund der geringen Sprachgüte nicht eingesetzt. Hybride Codecs kombinieren parametrische Elemente und Signalformcodierung und kommen für die Sprachkompression am häufigsten zum Einsatz. Bei hohen Bitraten zeigen sie das Verhalten eines Signalformcodierers, bei niedrigen Datenraten das eines parametrischen Codecs [Chu03]. Viele dieser Codecs basieren auf Code Excited Linear Prediction (CELP), einer Kombination aus linearer Kurz- und Langzeit-Prädiktion mit einem Codebuch. So standardisiert MPEG-4 bspw. einen CELP-Codec für die Sprachkompression [ISO04a]. Auch die ITU-Sprachcodecs G.723.1 [ITU96b], G.728 [ITU92a] und G.729 [ITU96c] sowie verschiedene Codecs des 3GPP für die Mobilkommunikation basieren auf CELP. Im Bereich der universell einsetzbaren Audiokompression findet man meist Signalformcodierer. Verlustbehaftete Kompression erfolgt auf Basis eines psychoakustischen Modells, wie es erstmals mit der Audiokompression von MPEG-1 eingeführt wurde. Die Verarbeitungsschritte von MPEG-1 wurden mit den Folgestandards MPEG-2 und MPEG-4 zwar stark optimiert und durch prädiktive Techniken ergänzt – das grundlegende Funktionsprinzip blieb jedoch bestehen. Auch viele proprietäre Formate setzen ähnlich wie MPEG-1 Audio auf psychoakustische Kompression, so z. B. das Mehrkanal-fähige Audio Coding Nr. 3 (AC-3) der Dolby Laboratories, das als Dolby Digital auf der DVD und bei digitalem Kinoton anzutreffen ist. Ein weiteres Format für Kinoton ist SDDS (Sony Dynamic Digital Sound), das auf dem ATRACVerfahren von Sony beruht. Auch ATRAC verarbeitet einzelne Subbänder durch ein psychoakustisches Modell und wird zudem für Sonys MiniDisc verwendet. Verlustfreie generische Audio-Kompression wird in der Regel durch prädiktive Techniken realisiert. Auf diesem Gebiet entstanden zunächst unterschiedliche freie und kommerzielle AudioCodecs, wie z. B. Apple Lossless, OptimFROG oder Monkey's Audio. Letzteres ist ein Open-Source-Codec, der sehr gute Kompressionsraten erzielt. Inzwischen ist MPEG jedoch dabei, die verlustfreie AudioKompression u. A. als Audio Lossless Coding (ALS) auch in MPEG-4 zu standardisieren. Mit Harmonic and Individual Lines and Noise (HILN) standardisiert MPEG-4 einen parametrischen Audio-Codec, der universell einsetzbar ist [ISO04a]. Er verarbeitet Audiomaterial mit einer Samplingrate von bis zu 8 kHz und codiert Audiomaterial mit 6 bis 16 kbit/s.


1.6 Die Standards JPEG und JPEG 2000 Der JPEG-Standard sowie seine Nachfolger JPEG-LS und JPEG 2000 wurden primär für die Kompression von Standbildern entwickelt. Bei JPEG und JPEG 2000 existieren jedoch auch korrespondierende Varianten für die Video-Kompression, die durch den Namenszusatz Motion gekennzeichnet sind. Während es aufgrund eines fehlenden Standards viele unterschiedliche Umsetzungen von Motion JPEG gibt, wurde die Motion-Variante des Nachfolgers JPEG 2000 gleich von Beginn an mit in den Standard integriert. JPEG-LS [ISO99][ITU98] wurde entwickelt, weil die verlustfreien Kompressionsmöglichkeiten von JPEG hinsichtlich Kompressionsrate und Geschwindigkeit hinter dem Stand der Technik zurückgeblieben waren. Da auch JPEG2000 verlustfrei komprimieren kann, ist die Bedeutung von JPEG-LS heute relativ gering. Tabelle 1.1 gibt einen Überblick über die JPEG-Standards. Die Familie der JPEG-Standards wurde von der namensgebenden Joint Photographic Experts Group konzipiert, einem Zusammenschluss aus Experten der ISO/IEC und der heutigen ITU. Die Bemühungen der Arbeitsgruppe resultierten jeweils in Empfehlungen der ITU sowie in einem internationalen ISO/IEC-Standard mit identischem Wortlaut. Im Folgenden werden nur JPEG und JPEG 2000 näher betrachtet. Eine Übersicht zu JPEG-LS findet sich z. B. bei [Wei00]. Bezeichnung

Einsatz für

ISO/IEC

ITU

JPEG

Standbilder

10918-1

T.81

Motion JPEG

Bildsequenzen

–

–

JPEG-LS

Standbilder

14495-1

T.87

JPEG 2000

Standbilder

15444-1

T.800

Motion JPEG 2000

Bildsequenzen

15444-3

T.802

JPEG-LS

Joint Photographic Experts Group

Tabelle 1.1: JPEG-Standards

1.6.1

JPEG JPEG unterscheidet verschiedene Arbeitsmethoden, von denen die meisten verlustbehaftet sind, da sie Redundanz- und Irrelevanzreduktion kombinieren. Alle Arbeitsmethoden operieren auf einzelnen Bildkanälen, wobei die Kanäle sequentiell oder verschachtelt verarbeitet werden können.

1.6 Die Standards JPEG und JPEG 2000

Arbeitsmethoden

■ ■ ■

29

Verarbeitung einzelner Kanäle

Die einzelnen Kanäle werden im Standard nicht explizit unterschieden, so dass bspw. ein Graustufenkanal genauso verarbeitet werden könnte wie der Rotkanal eines RGB-Bilds. Die meisten JPEGImplementierungen konvertieren die RBG-Kanäle jedoch zunächst in den YCrCb-Farbraum und verarbeiten die CrCb-Kanäle mit den Chrominanzinformationen anders als den Y-Kanal mit den Helligkeitsabstufungen. Dies ist möglich, da der Standard die Details einiger Operationen nicht direkt spezifiziert, sondern der jeweiligen Implementierung überlässt. Zusätzlich erfolgt vor der Verarbeitung meist eine Chrominanz-Unterabtastung. Obwohl inzwischen sehr leistungsfähige Folgestandards verfügbar sind, ist das JPEG-Verfahren noch weit verbreitet. Lediglich auf speziellen Anwendungsgebieten, wie z. B. in der medizinischen Bildverarbeitung, konnten sich Nachfolger durchsetzen. 1.6.1.1 Die Arbeitsmethode Baseline

Blockbildung

Quantisierung

30

■ ■ ■

Baseline ist die JPEG-Arbeitsmethode mit der geringsten Komplexität und verarbeitet ausschließlich Bilder mit einer Farbtiefe von 8 Bit pro Kanal. Für ein breites Anwendungsspektrum erzielt sie jedoch ausreichend gute Ergebnisse und muss von allen verlustbehafteten JPEGCodecs implementiert werden. Die Baseline-Methode zerlegt die Bildkanäle zunächst in quadratische Blöcke von N u N Pixeln mit N = 8. Danach erfolgt eine IndexverN-1 schiebung der Pixelwerte, indem jeder Wert um 2 reduziert wird. Die Pixelblöcke werden nun nacheinander einer DCT unterzogen, wie in Kap. 1.3.4.1 beschrieben. Durch die vorhergehende Indexverschiebung wurde verhindert, dass dabei zu große DC-Koeffizienten entstehen. Die 64 Koeffizienten jedes Blocks werden skalar quantisiert, wobei unterschiedliche Quantisierungswerte zum Einsatz kommen. Dazu gibt der JPEG-Standard eine unverbindliche Empfehlung und unterscheidet Quantisierungstabellen für Luminanz und Chrominanz (Abb. 1.13). Die empfohlenen Tabellen bilden DC-Koeffizienten und niedrige AC-Koeffizienten auf kleine Quantisierungsintervalle ab, während hochfrequente AC-Koeffizienten gröber quantisiert werden. Dies ist sinnvoll, da sich Informationsverluste in den feinen Bildstrukturen weniger störend auswirken als bei homogenen Strukturen. Die grobe Quantisierung der hochfrequenten Koeffizienten reduziert viele AC-Koeffizienten auf 0, was sich im weiteren Verlauf als nützlich erweisen wird. Um die ursprünglichen Koeffizienten später wieder rekonstruieren zu können, muss die verwendete Quantisierungstabelle in jedem Fall gespeichert werden.


Abb. 1.13: Quantisierungstabellen für Luminanz und Chrominanz

Abbildung 1.14 zeigt anhand des Pixelblocks aus Kap. 1.3.4.1 alle bisher beschriebenen Verarbeitungsschritte, wobei DCT-Koeffizienten gerundet dargestellt sind und mit der empfohlenen Tabelle für die Luminanz quantisiert wurden.

Beispiel

Abb. 1.14: Verarbeitung eines Pixelblocks bei der Codierung


■ ■ ■

31

Entropiecodierung

Verarbeitung von DC- und AC-Koeffizienten

Die Quantisierung ist derjenige Verarbeitungsschritt, mit dem sich Informationsverluste bei der Kompression am einfachsten beeinflussen lassen. Die Quantisierungstabellen sind daher der beste Ansatzpunkt für die Parametrisierung des Codecs. Bietet eine Implementierung die Möglichkeit, Einfluss auf die Kompressionsrate bzw. Bildqualität zu nehmen, so werden dabei meist die Quantisierungstabellen modifiziert. Nicht nur die Quantisierung macht das Baseline-Verfahren verlustbehaftet. Auch die DCT und IDCT können im Rahmen der StandardVorgaben in Encoder und Decoder unterschiedlich implementiert sein, was dann ebenfalls zum Informationsverlust führt. Die DC- und AC-Koeffizienten werden im Folgenden unabhängig voneinander verarbeitet. Benachbarte DC-Koeffizienten besitzen meist ähnliche Werte, da sich der mittlere Grauwert der Pixelblöcke bei vielen Bildern nur langsam ändert. Diese Korrelation macht man sich zu Nutze und wendet eine prädiktive Codierung an, um die Entropie zu verringern. Die Prädiktion erfolgt direkt durch den vorhergehenden Wert ohne Gewichtung, und die DC-Koeffizienten werden in Rasterscan-Reihenfolge von links nach rechts und von oben nach unten verarbeitet. Die Prädiktionsfehler werden anschließend durch eine HuffmanCodierung entropiecodiert. Da der Wertebereich der Prädiktionsfehler sehr groß sein kann, geht man dabei in zwei Schritten vor. Zunächst werden die Prädiktionsfehler grob in 12 Kategorien eingeteilt. Innerhalb der Kategorien werden die Prädiktionsfehler dann genauer beziffert. Analog zu den Quantisierungstabellen muss der Decoder den Codebaum der Huffman-Codierung kennen, weshalb er in jedem Fall abgespeichert wird. Vor der Weiterverarbeitung der 63 AC-Koeffizienten jedes Pixelblocks werden diese im Zickzack ausgelesen und dadurch nach Ortsfrequenzen sortiert (Abb. 1.15). Es entsteht ein eindimensionaler Vektor, bei dem die hochfrequenten Koeffizienten, von denen zuvor

Abb. 1.15: Zickzack-Anordnung der AC-Koeffizienten

32

■ ■ ■


einige zu 0 quantisiert wurden, am Ende platziert sind. Die Vektorelemente e z 0 werden nun nacheinander mit 8 Bits dargestellt, wobei eine Kombination aus Lauflängen-Angabe und Kategorisierung wie bei den DC-Koeffizienten zum Einsatz kommt. Für die Decodierung werden die beschriebenen Schritte der Codierung in umgekehrter Reihenfolge durchgeführt. Zunächst werden die Entropiecodierungen der DC- und AC-Koeffizienten decodiert. Die DC-Koeffizienten müssen durch Addition der Prädiktionsfehler und die AC-Koeffizienten durch eine inverse Lauflängencodierung zurück gewonnen werden. Mit Hilfe der zusätzlich abgespeicherten Quantisierungstabellen macht der Encoder die Quantisierung rückgängig, bevor im letzten Schritt die IDCT ausgeführt wird.

Decodierung

1.6.1.2 Weitere Arbeitsmethoden

Neben der oben beschriebenen Baseline-Methode sieht der JPEGStandard mit der erweiterten DCT-basierten, der verlustfreien und der hierarchischen Arbeitsmethode drei zusätzliche Codierungsmöglichkeiten vor. Die erweiterte DCT-basierte Arbeitsmethode ähnelt der BaselineMethode sehr stark und unterscheidet sich nur in einigen wenigen Parametern. So können anstelle von 8-Bit-Kanälen auch Kanäle mit Bittiefen von 12 Bit verarbeitet werden. Während die Baseline-Arbeitsmethode jeweils 2 verschiedene Huffman-Codetabellen für AC- und DC-Koeffizienten vorsieht, erlaubt die erweiterte Methode je 4 Codetabellen. Anstelle der Huffman-Codierung kann auch eine arithmetische Codierung zum Einsatz kommen. Den größten Unterschied macht die progressive Verarbeitung aus, die bei der erweiterten Arbeitsmethode als Alternative gewählt werden kann. Dabei werden in mehreren Durchläufen jeweils nur einige Koeffizienten der Bildblöcke codiert. Dies hat bei geringen Übertragungsraten den Vorteil, dass der Decoder schon sehr früh eine grobe Bildversion darstellen kann, auch wenn noch nicht alle Bilddaten übertragen wurden. Die verlustfreie Arbeitsmethode verwendet keine DCT sondern codiert die Pixelwerte des Bildes direkt durch eine Prädiktion höherer Ordnung. Dabei kommen maximal drei Pixelwerte als sog. Template für die Prädiktion zum Einsatz. Die drei Pixel sind so gewählt, dass sie bei zeilenweiser Abtastung des Bildes vor dem vorherzusagenden Pixel liegen, und daher schon zuvor decodiert wurden. Die Prädiktionsvorschrift wird für jeden Kanal separat aus einem Set von sieben verschiedenen Regeln gewählt (Abb. 1.16). Die Prädiktionsfehler können arithmetisch codiert oder einer Huffman-Codierung unterzogen


erweiterte DCT-basierte Arbeitsmethode

verlustfreie Arbeitsmethode, Template

■ ■ ■

33

Abb. 1.16: Prädiktionsvorschriften der verlustfreien Arbeitsmethode

hierarchische Arbeitsmethode, Bildpyramide

34

■ ■ ■

werden. Die Bittiefe der einzelnen Kanäle kann 2 bis 16 Bit betragen. Eine progressive Verarbeitung ist nicht möglich. Die verlustfreie Arbeitsmethode wird nur sehr selten eingesetzt, da mit JPEG-LS sehr bald eine weitaus leistungsfähigere Möglichkeit für die verlustfreie Kompression standardisiert wurde. Die hierarchische Arbeitsmethode kann verwendet werden, um mehrere Versionen desselben Bildes in unterschiedlichen Auflösungen zu speichern. Das ursprüngliche Bild wird dabei durch Unterabtastung schrittweise in der Auflösung reduziert, wobei sich die horizontalen bzw. vertikalen Bildauflösungen um den Faktor 2 oder Vielfache davon unterscheiden müssen. Man hat es also ähnlich wie bei der WaveletKompression mit einer Bildpyramide aus verschiedenen Auflösungen zu tun. Die Bildversion mit der geringsten Auflösung wird entweder mit einer der DCT-basierten Arbeitsmethoden oder mit der verlustfreien Arbeitsmethode gespeichert. Danach wird dieses Bild durch bilineare Interpolation um den Faktor 2 vergrößert und als Prädiktor für das Bild mit der nächst höheren Auflösung verwendet. Die resultierenden Prädiktionsfehler werden wiederum DCT-basiert oder verlustfrei komprimiert, wobei jedoch kleine Abwandlungen an den Arbeitsmethoden zu berücksichtigen sind. So wird bspw. vor Anwendung der DCT keine Indexverschiebung vorgenommen, da die Prädiktionsfehler naturgemäß kleinere Werte besitzen als die unveränderten Pixel. Mit Hilfe der Prädiktionsfehler wird das vorausgesagte Bild korrigiert, bevor es wiederum vergrößert und selbst als Prädiktor herangezogen wird. Dies wird fortgeführt, bis die ursprüngliche Auflösung des Ausgangsbildes erreicht wurde. Die hierarchische Arbeitsmethode ist per se überall dort geeignet, wo kleine Vorschaubilder angezeigt werden sollen. Trotz ihrer interessanten Möglichkeiten ist sie nicht sehr weit verbreitet, da sie bei gleicher Bildqualität geringere Kompressionsraten erzielt als die anderen JPEGMethoden. Die Codiereffizienz für hierarchische JPEGs aus vier Ebenen ist gegenüber der Baseline-Methode etwa 20% geringer [HaP96].


1.6.1.3 Motion JPEG

Motion JPEG (MJPEG) ist ein Kompressionsverfahren für Videodaten, das Einzelbilder einer Videosequenz separat und unabhängig voneinander mit dem JPEG-Verfahren komprimiert. Obwohl sich diese Nutzung schon früh abzeichnete [Wal91], wurde bis heute kein entsprechender Standard veröffentlicht. Zahlreiche Hersteller, wie z. B. MainConcept, Pegasus Imaging oder Morgan Multimedia, entwickelten deshalb ihre eigenen MJPEG-Codecs, die untereinander nicht unbedingt kompatibel sind. Unter maßgeblicher Beteiligung von Matrox und Microsoft versuchte das Open Digital Media Consortium einen MJPEG-Standard für die Windows-Plattform zu etablieren. Mit OpenDML [ODM96] wurde daher 1995 eine Erweiterung für das AVI-Dateiformat beschrieben. Microsoft integrierte OpenDML in ActiveMovie, seine damalige Konkurrenz-Technologie zu Quicktime. Allerdings zogen nicht alle Hersteller nach, und Microsoft wandte sich dem Active Streaming Format (ASF) zu, das AVI schließlich verdrängte. Apples Quicktime-Architektur bietet drei verschiedene Ausführungen von MJPEG. Dies sind Photo-JPEG sowie MJPEG-A und -B. Während Photo-JPEG nur Vollbilder codieren kann, unterstützen MJPEG-A und -B auch das fernsehtypische Interlace-Format, bei dem sich Einzelbilder aus zwei Halbbildern zusammensetzen (Kap. 1.7.2.1). Photo-JPEG setzt ein 4:2:0-Subsampling ein, wogegen die MJPEG-Varianten von Quicktime 4:2:2-Subsampling verwenden. MJPEG-A und -B unterscheiden sich nur bezüglich ihrer Kompatibilität mit Capture-Karten unterschiedlicher Hersteller, qualitative Unterschiede bestehen nicht. Zusätzlich zu den eigenen MJPEG-Ausführungen unterstützt Quicktime seit der Version 3 von 1998 auch AVI-Dateien und die OpenDMLErweiterung. MJPEG ist ein Verfahren für die Intraframe-Kompression, da Einzelbilder unabhängig voneinander verarbeitet werden. Videos, die mit Intraframe-Methoden komprimiert wurden, lassen sich bei der digitalen Videobearbeitung bildgenau schneiden, da jedes Bild eigenständig ist, und nicht von Informationen in den Nachbarbildern abhängt. Daher wird MJPEG häufig dann verwendet, wenn eine spätere Bearbeitung des Videomaterials möglich bleiben soll.

OpenDML

MJPEG in Quicktime

Nachbearbeitung

1.6.2 JPEG 2000 und Motion JPEG 2000 Die jüngste Veröffentlichung der JPEG-Gruppe ist der JPEG 2000Standard, der auf Wavelet-Transformationen beruht. Wie bei JPEG


■ ■ ■

35

Digital Cinema System Specification

weitere Eigenschaften von JPEG 2000

Transformationsarten

36

■ ■ ■

existiert mit MJPEG 2000 eine Motion-Variante, die ausschließlich Intraframe-Kompression verwendet. Im Gegensatz zu MJPEG ist MJPEG 2000 jedoch als Teil von JPEG 2000 standardisiert, so dass keine Inkompatibilitäten zwischen unterschiedlichen MJPEG 2000Codecs entstehen werden. Durch die Wavelet-Transformation ist JPEG 2000 skalierbar und die Dekompression kann sich progressiv der verfügbaren Übertragungsbandbreite bzw. benötigten Auflösung anpassen. Dies wird z. B. auch von der Digital Cinema System Specification [DCI05] genutzt, die Motion JPEG 2000 als Kompressionsverfahren im Bereich digitaler Kinoprojektion vorsieht. Die Spezifikation wird von der Digital Cinema Initiatives (DCI) herausgegeben, einem Industrie-Konsortium, dem u. A. große Hollywood-Studios wie Warner Brothers, Sony Pictures und Disney angehören. Mit 2K und 4K schreibt die DCI-Spezifikation zwei verschiedene Auflösungen vor, wobei die Abkürzungen die horizontale Auflösung bezeichnen: 2K-Material ist mit 2048 u 1080 Pixeln im HDTV-Bereich angesiedelt. 4-K-Material bringt es auf eine Auflösung von 4096 u 2160 Pixeln. Ein 2K-Decoder, der mit 4-K-Material konfrontiert wird, kann das Kinobild in seiner benötigten Auflösung decodieren und die restlichen Informationen ignorieren. Bei JPEG 2000 kann durch die Verwendung von Wavelet-Transformationen auf eine Unterteilung des Bilds in Blöcke verzichtet werden, weshalb es auch für einfache Liniengrafiken geeignet ist, wo sich bei hohen Kompressionsraten und JPEG-Kompression schnell störende Blockartefakte bemerkbar machen würden. Darüber hinaus kann JPEG 2000 für zweifarbige Bilder mit einer Farbtiefe von 1 Bit verwendet werden. Die maximale Farbtiefe pro Bildkanal sind 32 Bit, die ma32 ximale Auflösung pro Bilddimension sind 2 -1 Pixel. Wie JPEG verarbeitet JPEG 2000 alle Bildkanäle einzeln und unabhängig voneinander. Als Farbformat ist sowohl YCrCb als auch RGB erlaubt. Ein Subsampling der Chrominanz wird allerdings nicht empfohlen, da die Wavelet-Transformation dies schon implizit unterstützt. Der MJPEG2000-Standard für die Videocodierung erkennt dagegen an, dass die unkomprimierten Videodaten typischerweise schon im YCrCb-Format mit Subsampling der Chrominanz vorliegen, und schreibt daher vor, dass MJPEG-2000-Encoder auch solches Material verarbeiten müssen. Der erste Teil des JPEG-2000-Standards definiert zwei verschiedene Wavelet-Transformationen, von denen die eine verlustbehaftet ist. Die andere erzeugt Integer-Koeffizienten und ist reversibel. Eine genaue Erörterung der beiden Transformationen findet sich bei [UnB03]. Teil zwei des JPEG-Standards etabliert sog. Extensions, die beliebige, benutzerdefinierte Wavelet-Transformationen erlauben. Vor der WaveletTransformation erfolgt ähnlich wie bei JPEG eine Indexverschiebung. Die Transformation kann auf das ganze Bild angewendet werden,


wodurch die Entstehung von Blockartefakten verhindert wird. Um den Speicherbedarf bei Codierung und Decodierung zu verringern, ist es jedoch auch möglich, jeden Kanal in Kacheln gleicher Größe aufzuteilen, die von dann an völlig separat weiterverarbeitet werden. Die Wavelet-Koeffizienten besitzen eine geringe Entropie, da sich die relevante Information um bestimmte Werte konzentriert. Durch zusätzliche Quantisierung, die nur nach der verlustbehafteten WaveletTransformation Sinn macht, wird der Informationsgehalt der vorwiegend kleinen Koeffizienten zusätzlich verringert. Für jedes Subband der Wavelet-Transformation kann eine eigene Quantisierungsschrittweite festgelegt werden. So können z. B. die Detailkoeffizienten gröber quantisiert werden als die Koeffizienten mit den niederfrequenten Anteilen. Nach Transformation und optionaler Quantisierung erfolgt abschließend eine Aufbereitung der Koeffizienten und arithmetische Entropie-Codierung. Dieser Schritt basiert auf dem Embedded Block Coding with Optimized Truncation (EBCOT) von [Tau00], das u. A. die progressive Verfeinerung der Bildqualität beim Decodieren ermöglicht. Weitere verbreitete Verfahren mit ähnlicher Funktionalität sind der EZW-Algorithmus [Shp93], der bei MPEG-4 für die Standbildkompression verwendet wird, sowie der Algorithmus SPHIT [SaP96]. Im Gegensatz zu EZW und SPHIT werden bei EBCOT einzelne Koeffizientenblöcke verarbeitet und unabhängig voneinander codiert, was den Speicherbedarf einer Implementierung reduziert. Koeffizientenblöcke unterschiedlicher Subbänder und Zerlegungsstufen, die zu selben Bildinhalt beitragen, können zu sog. Precincts zusammengefasst werden, und erlauben in gewissen Grenzen einen wahlfreien, örtlichen Zugriff auf die codierten Bilddaten. Eine interessante Neuerung von JPEG200 ist die Codierung mit einer Region of Interest (ROI). Diese erlaubt es, bestimmte Bildbereiche mit mehr Bits und damit höherer Qualität zu codieren. Darüber hinaus werden diese Bildinformationen so abgespeichert, dass sie bei Übermittlung und Decodierung vor den übrigen Bildbereichen verfügbar sind. JPEG 2000 und MJPEG 2000 definieren beide ein eigenes Dateiformat. Das JPEG 2000-Format mit der Dateiendung jp2 erlaubt das Einbetten von Metadaten, die z. B. das Farbformat oder CopyrightInformationen beinhalten können. Das Dateiformat von MJPEG 2000 mit der Endung mj2 ist größtenteils mit dem MPEG-4-Dateiformat identisch. Daher unterstützt MJPEG 2000 wie MPEG-4 mehrere Videoebenen und Shapes bzw. Alpha-Kanäle (vgl. Kap. 1.7.3.2). Auch die Integration von Audiodaten ist möglich. Sind mehrere Medienspuren in einer MJPEG-Datei enthalten, so wird die Synchronisation durch Interleaving gewährleistet.


Quantisierung

Entropie-Codierung, EBCOT, EZW, SPITH

Region of Interest

Dateiformat

■ ■ ■

37

1.7

Videokompression mit MPEG MPEG-1 und MPEG-2

MPEG-4

MPEG-7 und MPEG-21

Gegenstand der Standardisierung

Tabelle 1.2: MPEG-Standards im Überblick

38

■ ■ ■

Die Moving Picture Experts Group (MPEG) wurde 1988 gegründet und veröffentlichte mit MPEG-1 und MPEG-2 internationale Standards für die Kompression von Audio- und Videodaten. Während MPEG-1 für geringe Bitraten konzipiert wurde und z. B. auf CD-ROM und VideoCD Verwendung findet, waren bei MPEG-2 von Beginn an weitaus höhere Datenraten vorgesehen. Anwendungsgebiete von MPEG-2 sind u. A. die DVD und das digitale Fernsehen. Der MPEG-4-Standard befasst sich ebenfalls mit Methoden der Audio- und Videokompression und erzielt bei vergleichbarer Qualität höhere Kompressionsraten als seine Vorgänger. Da dies von der MPEG-Gruppe jedoch nicht als ausreichender Grund für einen neuen Standard aufgefasst wurde [PeK95], bietet MPEG-4 über die reine Kompression hinaus noch viele zusätzliche Funktionalitäten und ist als weit gefasster Multimedia-Standard angelegt. In jüngerer Zeit gehen die Standardisierungsbemühungen der MPEG-Gruppe gänzlich über die Datenkompression hinaus. So entstand 2002 der internationale Standard MPEG-7 [ISO02], der die Beschreibung multimedialer Inhalte durch XML-Metadaten organisiert. MPEG-21 [ISO04d] beschäftigt sich als sog. Multimedia-Framework mit der Infrastruktur für Produktion, Verbreitung und Konsum von Medieninhalten. In Tabelle 1.2 sind die genannten MPEG-Standards und ihre Einsatzgebiete im Überblick aufgeführt. Die MPEG-Standards definieren ausschließlich die komprimierten Datenströme und den Decoder. Die Implementierung des Encoders ist dagegen nicht standardisiert, so dass die Hersteller hier ausreichend Spielraum für eigene Optimierungen und Weiterentwicklungen besitzen. Vorgabe ist lediglich, dass die Encoder standardkonforme Datenströme erzeugen müssen, die von standardkonformen Decodern verarbeitet werden können. In den folgenden Kapiteln werden Codierungsverfahren erläutert, die zu solchen Datenströmen führen. Die Decodierung wird jeweils durch umgekehrte Abarbeitung der Codierungsschritte realisiert, und muss daher nicht explizit beschrieben werden. Bezeichnung

Einsatzgebiet

ISO/IEC

MPEG-1 MPEG-2 MPEG-4 MPEG-7 MPEG-21

CD-ROM, Video-CD, ... DVD, digitales Fernsehen, ... Multimedia, digitales Fernsehen, ... XML-Metadaten für Medieninhalte Infrastruktur-Framework

11172 13818 14496 15938 21000


1.7.1 MPEG-1 Der MPEG-1-Standard besitzt den genauen Titel Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s und setzt sich aus 5 Teilen zusammen (Tabelle 1.3). Teil des MPEG-1-Standards

ISO/IEC

Part 1: Systems Part 2: Video Part 3: Audio Part 4: Compliance Testing Part 5: Software Simulation

11172-1 11172-2 11172-3 11172-4 11172-5

Die Kompression von Audio- bzw. Videodaten wird in Teil 2 bzw. 3 definiert. Das Resultat der Kompression sind Bitströme, die entweder Audio- oder Videodaten enthalten können und als Elementary Streams (ES) bezeichnet werden. Durch den Vorgang des Multiplexings, der im Systems-Teil beschrieben wird, lassen sich ES zusammen mit Informationen für ihre zeitliche Synchronisation in einen einzigen Transport Stream verpacken. Die beiden letzten Teile des Standards sind mit praktischen Fragen der Implementierung befasst. Das Compliance Testing beschäftigt sich mit dem Entwurf von Testverfahren, im letzten Teil des Standards finden sich komplette Referenzimplementierungen für die Kompression sowie für MPEG Systems. Wie die Bezeichnung des Standards schon zeigt, zielt MPEG-1 auf die Kompression mit geringer Datenrate bis etwa 1,5 MBit ab. Daher werden bestimmte Rahmenbedingungen für das Videomaterial genannt, mit denen solche Bitraten erreichbar sind. Werden die Rahmenbedingungen eingehalten, ergibt sich nach der Kompression eine Bitrate von rund 1,2 MBit/s für den Video ES. Viele MPEG-1-Implementierungen beschränken sich tatsächlich auf Bitraten dieser Größenordnung. Allerdings ist der Standard sehr flexibel und akzeptiert explizit auch Datenraten über 1,5 MBit/s und abweichende VideoParameter, wie z. B. Auflösungen bis zu 4096 u 4096 Pixel. Für die Videokompression wird eine maximale Bildauflösung von 352 u 288 Pixel empfohlen, was annähernd der halben Auflösung eines Fernsehbildes entspricht und als CIF (Common Intermediate Format) bezeichnet wird. Da diese Auflösung horizontal und vertikal ein Vielfaches von 16 ist, müssen bei der Blockbildung keine zusätzlichen Pixel eingefügt werden. Die Makroblöcke zur Bewegungskompensation messen 16 u 16 Pixel, Blöcke für die DCT dagegen 8 u 8 Pixel. MPEG-1 akzeptiert ausschließlich Videodaten, die im YCrCb-Format

1.7 Videokompression mit MPEG

Tabelle 1.3: MPEG-1-Standard im Überblick

Elementary Streams und Transport Stream

Rahmenbedingungen für das Videomaterial

■ ■ ■

39

vorliegen, und setzt ein 4:2:0-Subsampling der Chrominanz voraus. Alle Bildkanäle werden einzeln verarbeitet, und die maximale Farbtiefe pro Kanal beträgt 8 Bit. Mit einer erlaubten Bildrate von 24 bis 60 Bilder pro Sekunde werden sowohl Film als auch die Fernsehformate PAL und NTSC abgedeckt. 1.7.1.1 Funktionsprinzip

Blockschaltbild

Die MPEG-1-Kompression nutzt in weiten Teilen ähnliche Verarbeitungsschritte wie das JPEG-Verfahren und codiert in regelmäßigem Abstand jeweils ein Videobild mit Intraframe-Kompression. Bei den verbleibenden Videobildern wird Interframe-Kompression eingesetzt, die auf vorwärtsgerichteter und bidirektionaler Prädiktion basiert. Die hierfür nötige Bewegungskompensation erfolgt durch Blockmatching (Kap. 1.4.1). Abbildung 1.17 zeigt ein Blockschaltbild mit den wichtigsten Verarbeitungs-Komponenten eines MPEG-Encoders. Wie bereits erwähnt, standardisiert MPEG keine Encoder, weshalb Implementierungen auch anders realisiert sein können. Die Intraframe-Einheit des Encoders besteht aus DCT, skalarer Quantisierung und anschließender Lauflängen- bzw. Entropiecodierung (1). Die resultierende Bitrate wird während des Codiervorgangs ständig überprüft und durch dynamische Abstimmung der Quantisierung an die gewünschte Datenrate angepasst (2).

Abb. 1.17: Blockschaltbild eines typischen MPEG-Encoders

40

■ ■ ■


Für die Interframe-Kompression muss die Quantisierung rückgängig gemacht und die inverse DCT berechnet werden. So erhält der Encoder dieselben Makroblöcke wie später ein Decoder. Die einzelnen Blöcke werden zu einem vollständigen Bild zusammengesetzt, welches zwischengespeichert wird, damit es als Referenz für die folgenden Bilder herangezogen werden kann (3). Die Bewegungsschätzung vergleicht das aktuelle Bild mit dem Referenzbild und errechnet Bewegungsvektoren (4). Aus diesen Vektoren und dem Referenzbild wird von der Bewegungskompensation (5) ein Prädiktionsbild generiert. Die Unterschiede zwischen aktuellem Bild und Prädiktionsbild werden als Prädiktionsfehler komprimiert. Am Ende schreibt der Encoder die Bewegungsvektoren und codierten Intraframes in einen ES (6). Der Schalter (7) steuert, ob für das aktuelle Videobild Intraframeoder Interframe-Kompression zum Einsatz kommt. Wird ein Videobild von der Intraframe-Einheit des Encoders komprimiert, so bezeichnet man das Bild als I-Frame. Ein komprimiertes Bild der InterframeEinheit heißt P-Frame oder B-Frame, je nachdem, ob bei der Kompression vorwärtsgerichtete oder bidirektionale Prädiktion verwendet wurde.

Bewegungsschätzung

Arten von Frames

1.7.1.2 Bildgruppen

Die kleinste unabhängig decodierbare Einheit eines Video ES ist die geschlossene Bildgruppe (engl. Group of Pictures, GOP), die aus mindestens einem I-Frame und theoretisch aus beliebig vielen B- und P-Frames besteht. Die Struktur der GOPs hat Einfluss auf die Abspieleigenschaften des ES. So ist der wahlfreie, direkte Zugriff auf bestimmte Einzelbilder einfacher zu realisieren, wenn kurze GOPs verwendet werden und die I-Frames dadurch häufiger auftreten. Sehr kurze GOPs wirken sich allerdings negativ auf die Kompressionsrate aus, da hohe Kompression nur mit einer größeren Anzahl von prädiktiven Frames erreicht wird. Viele MPEG-Encoder erlauben es nur innerhalb enger Grenzen, die GOP-Struktur individuell einzustellen. Meist sind einige sinnvolle GOP-Muster vorgegeben, zwischen denen der Anwender auswählen kann. Eine typische GOP-Struktur verwendet alle halbe Sekunde ein IFrame und setzt nur zwei aufeinander folgende B-Frames ein. So ergibt sich unter Berücksichtigung der Bildfrequenz des europäischen PAL-Fernsehens von 25 Bildern pro Sekunde eine GOP-Struktur wie in Abb. 1.18 dargestellt.


Group of Pictures (GOP)

typische GOP-Struktur

■ ■ ■

41

Abb. 1.18: Typische GOP-Struktur

Anzeigereihenfolge und Übertragungsreihenfolge

geschlossene und offene GOPs

Die Pfeile geben Abhängigkeiten von vorhergehenden oder folgenden Bildern an. Da B-Frames von nachfolgenden I- oder P-Frames abhängen, müssen diese vor den B-Frames decodiert werden. Daraus folgt, dass zur Anzeigereihenfolge einer Bildfolge immer auch eine Übertragungsreihenfolge (Abb. 1.19) gehört. Diese wird bereits im Encoder hergestellt, damit ein Decoder die Bilder in der benötigten Reihenfolge erhält. Die I- und P-Frames müssen vom Decoder zwischengespeichert werden, bis alle abhängigen B-Frames decodiert wurden. Da die B-Frames selbst nicht Basis für die Bewegungskompensation sind, können sie stärker komprimiert werden, ohne dass sich dadurch bedingte Fehler bei der Rekonstruktion in andere Frames fortpflanzen. Bei der GOP in Abb. 1.18 handelt es sich um eine geschlossene Bildgruppe, da alle B-Frames von I- oder P-Frames umrahmt werden. Der MPEG-Standard erlaubt jedoch auch offene GOPs, die auf ein B-Frame enden oder mit einem solchen Frame beginnen. Diese GOPs können nur unter Zuhilfenahme des folgenden I-Frames oder eines vorhergehenden I- oder P-Frames decodiert werden. Die GOP-Struktur innerhalb eines ES muss nicht immer konstant bleiben. Auch wenn dem Encoder eine Struktur vorgegeben wird, so kann er davon abweichen, um zusätzliche I-Frames einzufügen. Dies ist z. B. bei Szenenwechseln innerhalb des Videoinhalts sinnvoll, wo die Bewegungskompensation keine effiziente Kompression ermöglicht. Auch GOPs, die nur aus einem Frame bestehen, sind zulässig. Dieses Frame muss dann allerdings ein I-Frame sein. Ein ES, der

Abb. 1.19: Übertragungsreihenfolge einer typischen GOP

42

■ ■ ■


ausschließlich solche GOPs verwendet, ist strukturell mit den Motion-Varianten der JPEG-Verfahren vergleichbar. 1.7.1.3 Kompression der Einzelframes

Wie schon erwähnt, nutzt MPEG-1 zur Kompression der I-Frames ähnliche Verarbeitungsschritte wie das JPEG-Verfahren: Das Bild wird in Blöcke aus 8 u 8 Pixeln aufgeteilt, die durch eine DCT transformiert und dann skalar quantisiert werden. Für die Quantisierung wird eine Standard-Quantisierungstabelle vorgegeben, die bei speziellen Bedürfnissen jedoch angepasst werden kann. Lediglich der Quantisierungswert des DC-Koeffizienten ist mit 8 fest vorgeschrieben. Für jeden Makroblock innerhalb des Frames kann eine neue Quantisierungstabelle verwendet werden. Bei der Decodierung wird demnach immer die Information benötigt, ob die Tabelle des vorhergehenden Makroblocks eingesetzt oder ob eine neue Tabelle geladen wird. Die DC-Koeffizienten werden analog zum JPEG-Verfahren prädiktiv codiert. Anstatt die DCT-Blöcke des Luminanz-Kanals aber von links nach rechts und von oben nach unten abzuarbeiten, wird ihre Codierungsreihenfolge von den Makroblöcken beeinflusst. Bei den DCT-Blöcken der Chrominanz bleibt die Codierungsreihenfolge gegenüber JPEG unverändert. Durch das 4:2:0-Subsampling ist hier pro Makroblock nur ein DCT-Block enthalten (Abb. 1.20). Die AC-Koeffizienten der Pixelblöcke werden durch das ZickzackVerfahren der JPEG-Kompression umsortiert. Die folgende Codierung unterscheidet sich etwas von der JPEG-Codierung, da die Koeffizienten nicht in Kategorien eingeteilt werden. Sie lassen sich demnach direkt durch eine Kombination aus Lauflänge und Koeffizientenwert codieren, wofür eine Huffman-Codierung zum Einsatz kommt. Die Codierung der P- und B-Frames ist etwas komplexer als die Verarbeitung der I-Frames, da für jeden Makroblock viele Codierungsmöglichkeiten existieren. Der MPEG-Standard schlägt vor, nacheinander

Kompression der I-Frames

Codierung der P- und B-Frames

Abb. 1.20: Reihenfolge der DC-Koeffizienten bei der Prädiktion


■ ■ ■

43

Intra-codierte Makroblocks

Inter-codierte Makroblöcke

Slices

eine Reihe von Entscheidungen zu treffen, um die Codierung jedes Makroblocks mit akzeptablem Aufwand zu ermitteln. Dazu gehört u. A. die Entscheidung, ob bei P-Frames tatsächlich ein Bewegungsvektor zu übertragen ist, oder ob ein Nullvektor ausreicht, der natürlich nicht übertragen werden muss. In einem weiteren Schritt können Bewegungs- bzw. Nullvektoren noch zugunsten einer Intra-Codierung verworfen werden. Dies ist dann sinnvoll, wenn der Einsatz von Bewegungskompensation nicht zu einer befriedigenden Prädiktion führt, weil z. B. neue Objekte im Bildbereich erschienen sind. In einem solchen Fall kann es sein, dass die Codierung von Bewegungsvektor und Prädiktionsfehler mehr Bits benötigt als eine Intra-Codierung des Makroblocks. Bei B-Frames muss für jeden Makroblock zusätzlich ermittelt werden, welche Art der Prädiktion zum Einsatz kommen soll. War bereits der vorhergehende Makroblock Inter-codiert, kann versucht werden, denselben Bewegungsvektor wieder zu verwenden. Die Verarbeitung von Intra-codierten Makroblocks erfolgt wie bei den I-Frames durch DCT, Quantisierung, Sortierung und HuffmanCodierung. Einen Unterschied macht die Codierung der DC-Koeffizienten. Falls der vorhergehende Block Inter-codiert wurde, wird hier der Wert 128 angenommen. Bei den Inter-codierten Blöcken sind ebenfalls Besonderheiten zu berücksichtigen. Die Blöcke mit den Prädiktionsfehlern werden zunächst wie gewohnt einer DCT unterzogen. Während die DCT-Koeffizienten unveränderter Bildblöcke nach ihrer Wichtigkeit für die menschliche Wahrnehmung unterschieden werden konnten, ist eine solche Unterscheidung im Falle von Prädiktionsfehlern nicht mehr sinnvoll möglich. Daher werden die Koeffizienten alle identisch quantisiert. Auch eine separate, prädiktive Verarbeitung der DC-Koeffizienten entfällt, da bei Prädiktionsfehlern keine Korrelation zwischen DC-Koeffizienten ausgenutzt werden kann. Alle Arten von Frames sind außer in Makroblocks auch in sog. Slices unterteilt. Dies geschieht jedoch nicht, um die Codierungseffizienz zu verbessern, sondern dient der Robustheit gegenüber Fehlern im Datenstrom. Der Beginn eines Slices im ES wird durch einen Slice Header gekennzeichnet. Bemerkt der Decoder Datenfehler innerhalb des Slices, springt er zum folgenden Slice Header und kann mit den verbleibenden Teilen des Frames fortfahren.

1.7.2 MPEG-2 Der MPEG-2-Standard trägt den Titel Generic coding of moving pictures and associated audio information. Durch den generischen Ansatz unterstützt MPEG-2 ein breiteres Anwendungsspektrum als MPEG-1,

44

■ ■ ■


das primär für geringe Bitraten konzipiert wurde. Wie bei MPEG-1 werden in den ersten Teilen des Standards die Audio- und Videokompression, das Multiplexing sowie Testverfahren beschrieben. Darüber hinaus besteht der internationale Standard jedoch aus weiteren Teilen, die sich u. A. mit der Übertragung von MPEG-2 Transport Streams in Netzwerken und der Steuerung digitaler Speichermedien beschäftigen. Wie schon erwähnt, kommt MPEG-2 u. A. bei der DVD-Video zum Einsatz. Das Videomaterial der DVD besitzt eine Auflösung von 720 u 576 Pixeln und eine typische Datenrate von 4 bis 7 Mbit/s. Beim terrestrisch übertragenen digitalen Fernsehen (Digital Video Broadcasting Terrestrial, DVB-T) wird ebenfalls MPEG-2 mit einer Auflösung von 720 u 576 Pixeln verwendet. Die Datenrate beträgt hier 12 Mbit/s für mehrere gebündelt übertragene Fernsehkanäle. Die ma14 14 ximale Auflösung für MPEG-2-Video beträgt 2 u 2 Pixel, was natürlich auch zu einer entsprechend hohen Datenrate führt und nur theoretische Bedeutung besitzt. Als höchste sinnvoll nutzbare Auflösung werden im Standard 1920 u 1152 Pixel mit einer Datenrate von maximal 80 Mbit/s empfohlen, womit man sich im Bereich des HDTV befindet. Diese Beispiele verdeutlichen, dass MPEG-2 um einiges vielseitiger eingesetzt wird als der MPEG-1-Standard, und einen Schwerpunkt auf dem Rundfunk- und Fernseh-Sektor besitzt. MPEG-2-kompatible Encoder müssen auch Bitströme decodieren können, die dem MPEG-1-Standard entsprechen. In vielerlei Hinsicht ist MPEG-1 also eine Untermenge von MPEG-2. Allerdings findet sich nicht für jedes Detail im MPEG-1-Standard ein äquivalentes Konzept bei MPEG-2. Alle Bitfolgen eines MPEG-1-Stroms, die keine Entsprechung bei MPEG-2 besitzen, werden von MPEG-2-Decodern ignoriert.

Einsatzgebiete

Kompatibilität mit MPEG-1

1.7.2.1 Grundlegende Unterschiede zu MPEG-1

MPEG-2 und MPEG-1 unterscheiden sich formal in einigen Codierungsparametern und bezüglich verschiedener Restriktionen, denen das Videomaterial unterworfen ist. Die grundlegenden Verarbeitungsschritte sind jedoch weitgehend identisch. MPEG-2 nutzt ebenfalls Interframe-Kompression, die auf Bewegungskompensation durch Blockmatching basiert. Auch die Kompression der einzelnen Frametypen ähnelt MPEG-1, und die maximale Farbtiefe pro Kanal beträgt 8 Bit. Im Folgenden werden daher nur die wichtigsten Unterschiede von MPEG-2 skizziert. Im Gegensatz zu MPEG-1 akzeptiert MPEG-2 auch Videomaterial mit 4:2:2-Subsampling, sowie mit voller Auflösung der Chrominanz im 4:4:4-Format. Beim 4:2:0-Subsampling liegen die ChrominanzSamples anders als bei MPEG-1 (Abb. 1.21). Durch die veränderte


Subsampling

■ ■ ■

45

Abb. 1.21: 4:2:0-Subsampling von MPEG-1 und MPEG-2

Halbbilder, Interlacing

Folgen der Halbbildzerlegung

Sample-Position lassen sich insbesondere Formatkonvertierungen einfacher implementieren. Ein großer Unterschied zu MPEG-1 ist die Unterstützung von Bildern, die im Zeilensprungverfahren vorliegen. Dabei handelt es sich um eine fernsehspezifische Technik, die Einzelbilder jeweils in Form von zwei Halbbildern aufzeichnet, und im Englischen als Interlacing bezeichnet wird. Die Aufzeichnung erfolgt dabei zeilenweise, so dass z. B. alle ungeraden und alle geraden Bildzeilen jeweils ein Halbbild mit halber vertikaler Auflösung ergeben (Abb. 1.22). Am Fernsehbildschirm werden die Halbbilder nacheinander angezeigt, wobei jede zweite Zeile übersprungen wird. So wird die zeitliche Bildauflösung künstlich verdoppelt, und die Fernsehbilder scheinen weniger zu flimmern. Während Halbbild-Video bei MPEG-1 vor der Kompression zunächst in progressives Video, also Vollbilder, umgerechnet werden musste, unterstützt MPEG-2 das Halbbild-Video direkt. Die Zerlegung in Halbbilder ist bei vielen Operationen zu berücksichtigen und führt dazu, dass in zahlreichen Fällen alternative Verar-

Abb. 1.22: Zerlegung eines Vollbilds in Halbbilder

46

■ ■ ■


Abb. 1.23: Verarbeitung von Makroblöcken im Halbbild- und Vollbild-Modus

beitungsschritte vorgesehen werden müssen. So können z. B. I-Frames nicht nur aus einem Vollbild oder aus zwei I-Halbbildern bestehen, sondern auch aus einem I- und einem P-Halbbild. Letzteres wird dabei aus dem zugehörigen I-Halbbild vorhergesagt. Die Entscheidung, ob Halbbilder oder Vollbilder komprimiert werden, kann von Bild zu Bild neu getroffen werden. Die Codierung von Vollbildern wird typischerweise bei Szenen mit wenig Bewegung eingesetzt, während bei schnellen Bewegungen oft auf Halbbilder zurückgegriffen wird. Die DCT transformiert wie bei MPEG-1 Blöcke aus 8 u 8 Pixeln. Je nachdem, womit sich beim vorliegenden Material höhere Kompressionsraten erzielen lassen, werden Blöcke verschachtelt oder progressiv verarbeitet. Die Wahl des Verarbeitungsmodus beeinflusst, wie Makroblöcke vor Einsatz der DCT in Teilblöcke zerlegt werden. Mögliche Zerlegungsarten sind in Abb. 1.23 zu sehen. Die Zerlegung eines Bildes in Halbbilder führt zu höheren DCTKoeffizienten auf der vertikalen Achse. Daher stellt MPEG-2 eine alternative Sortierreihenfolge für die AC-Koeffizienten zur Verfügung, bei der die Koeffizienten der vertikalen Frequenzen an früherer Stelle berücksichtigt werden (Abb. 1.24).

Verarbeitung von Makroblöcken

Abb. 1.24: Alternative Sortierreihenfolge für die AC-Koeffizienten


■ ■ ■

47

Weitere Unterschiede zu MPEG-1 treten bei Quantisierungstabellen auf. So können z. B. die DC-Koeffizienten nicht nur mit dem Quantisierungswert 8, sondern auch mit den Werten 4, 2 und 1 quantisiert werden. Die Slices der Makroblöcke dürfen sich nicht mehr über mehrere Zeilen erstrecken. Die Genauigkeit für die Bewegungsvektoren ist auf ½ Pixel festgelegt, und darf nicht mehr auf Integer-Werte reduziert werden. 1.7.2.2 Profile und Levels

Profile

Main Profile, 4:2:2 Profile

Tabelle 1.4: Merkmale der MPEG-2-Profile

48

■ ■ ■

Da MPEG-2 als generischer Standard unterschiedlichen Anwendungszwecken genügen soll, wurden Profile eingeführt. Diese definieren Untermengen des Standards und sollen den Austausch von MPEG-2 Bitströmen zwischen verschiedenen Anwendungen erleichtern. Darüber hinaus bieten Profile eine Möglichkeit für die Industrie, kostengünstige MPEG-2-Implementierungen zu liefern. Während die Implementierung von Anwendungen, die den gesamten Standard unterstützen, sehr aufwändig ist, lassen sich Anwendungen einfacher implementieren, wenn nur ein bestimmtes Profil berücksichtigt werden muss. Insgesamt spezifiziert der Standard 5 Profile (Tabelle 1.4), die sich u. A. durch unterstützte Bildtypen und Subsampling-Arten unterscheiden. Die Profile bauen hierarchisch aufeinander auf, d. h. das Simple Profile ist z. B. eine Untermenge des Main Profiles. Das Main Profile wird bisher am häufigsten eingesetzt, so z. B. auch bei der DVD. Ein weiteres, zusätzliches Profil wurde von der Society of Motion Picture and Television Engineers (SMPTE) definiert. Dieses sog. 4:2:2 Profile [SMP98] wurde für die speziellen Bedürfnisse der digitalen Fernsehstudiotechnik entwickelt, ist aber nicht Teil des eigentlichen MPEG-Standards, und erlaubt Datenraten bis zu 300 MBit/s. Der Name 4:2:2 Profile mag etwas irreführend sein, da auch schon das High Profile des MPEG-Standards ein 4:2:2-Subsampling bietet. Aus Tabelle 1.4 ist ersichtlich, dass keines der Profile ein 4:4:4-Format ohne Subsampling verwendet, obwohl dies nach dem MPEG-2-Standard erlaubt wäre. Profil

Subsampling

Bildtypen

Skalierbarkeit

Simple Main SNR Spatial High

4:2:0 4:2:0 4:2:0 4:2:0 4:2:0, 4:2:2

I, P I, B, P I, B, P I, B, P I, B, P

keine keine SNR SNR, örtlich SNR, örtlich


Alle Profile oberhalb des Main Profiles unterstützen Skalierbarkeit des Videostroms. Dabei handelt es sich um eine weitere Neuerung von MPEG-2, die mit der hierarchischen Codierung bei JPEG vergleichbar ist. Skalierbare Bitströme bestehen aus einer grundlegenden Videoebene, die jeder Decoder verarbeiten muss. Darüber hinaus können jedoch zusätzliche Ebenen vorhanden sein, die Inhalte des Bitstroms qualitativ aufwerten oder eine höhere örtliche Auflösung bereitstellen. Beim SNR Profile unterscheiden sich Videoebenen in ihrem SignalRauschabstand (engl.: signal to noise ratio) und besitzen somit verschiedene Bildqualität. Eine denkbare Einsatzmöglichkeit für dieses Profil ist ein Bitstrom mit zwei qualitativ unterschiedlichen Videoebenen für herkömmliche oder großformatige Anzeigegeräte. Das Spatial und High Profile bieten über die qualitative Skalierung hinaus auch eine Skalierung der örtlichen Auflösung an. Zusätzlich zu den Profilen werden vom MPEG-Standard 4 sog. Levels definiert, die sich mit den Profilen kombinieren lassen. Tabelle 1.5 gibt an, welche Kombinationen aus Profilen und Levels vom Standard empfohlen werden. Solche Kombinationen werden formal mit Hilfe des @-Zeichens ausgedrückt, wie z. B. bei Main Profile@Main Level, abgekürzt MP@ML. Level Profil Simple Main SNR Spatial High

Low

Main

High-1440

High

u u

u u u

u

u

u u

u

u

Skalierbarkeit des Videostroms

SNR Profile, Spatial Profile, High Profile

Levels

Tabelle 1.5: Empfohlene Kombinationen aus Profilen und Levels

Während die Profile angeben, welche syntaktischen Parameter im Datenstrom erlaubt sind, spezifizieren Levels Beschränkungen für diese Parameter. So werden in Levels z. B. die maximale Bitrate und Auflösung oder die Bildwiederholrate vorgeschrieben. Zusätzlich werden feingranulare Parameter für bestimmte Verarbeitungsschritte definiert, wie z. B. die Wertebereiche der Bewegungsvektoren. Die Level-Bezeichnung High-1440 ist durch die maximale horizontale Auflösung von 1440 Pixeln bedingt. Einige wichtige Parameter verschiedener Levels des Main Profiles sind in Tabelle 1.6 aufgeführt. Parameter

MP@HL

MP@H-14

MP@ML

MP@LL

Auflösung Bildrate Bitrate

1920 u 1152 60 Bilder/s 80 Mbit/s

1440 u 1152 60 Bilder/s 60 Mbit/s

720 u 576 30 Bilder/s 15 Mbit/s

352 u 288 30 Bilder/s 4 Mbit/s


Tabelle 1.6: Level-Parameter des Main Profiles

■ ■ ■

49

Wie die Profile bauen Levels hierarchisch aufeinander auf und sind somit abwärtskompatibel zueinander. Ein Decoder, der SNR@MLDatenströme verarbeiten kann, muss auch mit MP@ML, MP@LL und SP@ML zurecht kommen. Die höheren Levels des Main Profiles, also H-14@MP und H@MP, müssen nicht unterstützt werden. Die einzige Ausnahme ist bei Decodern für SP@ML-Ströme zu finden, die auch das höher liegende MP@LL akzeptieren müssen.

1.7.3 MPEG-4 MPEG-4 trägt der zunehmenden Annäherung von Computertechnik, Unterhaltung und Telekommunikation Rechnung, und definiert etliche neue Methoden für die Verarbeitung und Verbreitung digitaler Medien. Der Standard bietet demnach einiges mehr als effiziente Kompressionsmethoden und unterstützt die Konvergenz multimedialer Dienste auf vielfältige Weise. Der lineare Charakter von Audiound Videodaten, der vorhergehende MPEG-Standards kennzeichnete, wird von nichtlinearen Interaktionsmöglichkeiten abgelöst, die u. A. durch objektbasierte Codierung der Audio- und Videodaten ermöglicht werden. Diese Abkehr von der herkömmlichen Herangehensweise spiegelt sich auch in der vollen Bezeichnung des Standards, Coding of Audio-Visual Objects, wieder. 1.7.3.1 Grundlagen von MPEG-4 audiovisuelle Objekte

Aufbau einer MPEG-4-Szene

50

■ ■ ■

Audiovisuelle Objekte bei MPEG-4 können in natürliche und synthetische Objekte eingeteilt werden. Natürliche Objekte lassen sich durch Ton- oder Videoaufnahmen gewinnen, während synthetische Objekte maschinell erzeugt werden. Zu den synthetischen Medienobjekten gehören Computergrafiken und künstlich erzeugte Klänge. Die audiovisuellen Objekte können zweidimensional sein, wie z. B. herkömmliches Video, oder dreidimensional, wie z. B. Surround-Ton oder 3DAnimationen. Die Medienobjekte sind hierarchisch in einer audiovisuellen Szene angeordnet. Diese Szene wird mit einer Beschreibungssprache definiert, die auf der Virtual Reality Modeling Language (VRML) [ISO97] basiert. Innerhalb der Szene werden Medienobjekte durch ObjektDeskriptoren repräsentiert, welche die Verbindungen zwischen Szenenbeschreibung und den audiovisuellen Datenströmen herstellen (Abb. 1.25). Als Grundlage für das MPEG-4-Dateiformat dient Quicktime, das jedoch noch stark erweitert wurde.


Abb. 1.25: Schematischer Aufbau einer MPEG-4-Szene

Während der Entwicklung von MPEG-4 wurden als relevanteste Funktionalitäten 8 Kernpunkte definiert [PeK95], die auch den fertigen Standard gut charakterisieren. Entsprechend den genannten konvergenten Bereichen lassen sich diese Kernpunkte in die drei Kategorien universeller Zugriff, Kompressionseffizienz und inhaltsbasierte Interaktivität einteilen (Abb. 1.26). In der Kategorie inhaltsbasierte Interaktivität finden sich die meisten der Kernpunkte wieder, was die Positionierung von MPEG-4 als interaktiven Multimedia-Standard verdeutlicht. Werkzeuge für inhaltsbasierte Zugriffe auf Multimediadaten sollen das Indexieren, Verlinken, Abfragen, Übertragen und Löschen der Daten ermöglichen. In dieser Anforderung spiegeln sich die Charakteristiken des Nachfolgestandards MPEG-7 schon sehr stark wieder. Die inhaltsbasierte Manipulation erlaubt es, Audio- und Bilddaten ohne erneute Kompression

Kategorie inhaltsbasierte Interaktivität

Abb. 1.26: Funktionale Kernpunkte von MPEG-4


■ ■ ■

51

Kategorie Kompressionseffizienz

Kategorie universeller Zugriff

zu modifizieren. Während bei MPEG-2 beispielsweise Texteinblendungen fest in den Datenstrom eincodiert werden, können diese nun als separates Objekt ein- und ausgeblendet werden. Die hybride Codierung stellt unterschiedliche Verarbeitungsmethoden für natürliche und synthetisch erzeugte Mediendaten zur Verfügung und erlaubt die flexible Kombination dieser unterschiedlichen Daten. Der verbesserte zeitliche Zugriff bezieht sich auf effiziente Möglichkeiten für den wahlfreien Zugriff auf einzelne Medienobjekte des Datenstroms. In der Kategorie Kompressionseffizienz findet man Punkte, welche die Einordnung von MPEG-4 als Standard für die Datenkompression rechtfertigen und als Weiterentwicklung von MPEG-2 angesehen werden können. Hier ist natürlich zunächst die verbesserte Kompressionsleistung gegenüber MPEG-2 zu nennen, auf die im folgenden Unterkapitel genauer eingegangen wird. Die Codierung paralleler Datenströme zielt auf die Unterstützung von Stereoskopie und Multikamera-Darstellungen ab. Die Kategorie universeller Zugriff scheint zunächst den bereits behandelten Forderungen nach inhaltsbasiertem und wahlfreiem Multimediazugriff zu ähneln und ist daher vielleicht etwas unglücklich gewählt. Die MPEG-Gruppe versteht darunter jedoch im Wesentlichen die verbesserte Benutzbarkeit von Multimediadaten in vernetzten Umgebungen. Die Robustheit in fehleranfälligen Umgebungen ist besonders für die Übertragung im mobilen Anwendungsbereich relevant. Die inhaltsbasierte Skalierbarkeit bezieht sich zunächst einmal auf örtliche und zeitliche Auflösung. Darüber hinaus kann durch Priorisierung einzelner Medienobjekte auch semantische Skalierbarkeit realisiert werden. Je nach Übertragungsleistung des Netzwerks ist demnach eine feine Skalierbarkeit der Inhalte in vielerlei Hinsicht möglich. 1.7.3.2 MPEG-4 Visual

Aufbau von Videosequenzen

52

■ ■ ■

Die Kompression von visuellen Mediendaten ist als MPEG-4 Visual in Teil 2 des Standards definiert und wurde stark vom ITU-Codec H.263 beeinflusst. MPEG-4 Visual ermöglicht neben der Videocodierung auch die Standbild-Kompression auf Basis von Wavelet-Transformationen, was der Standard als Visual Texture Coding bezeichnet. Zusätzlich werden Möglichkeiten für die Kompression von dreidimensionalen Gitternetzen und von Animationsparametern für menschliche 3D-Modelle zur Verfügung gestellt. Videosequenzen werden in MPEG-4 als Video Objects (VOs) bezeichnet. Übergeordnet ist die Visual Sequence (VS), die mehrere VOs beinhalten kann. Innerhalb einzelner VOs können wiederum mehrere


Video-Ebenen (Video Object Layers, VOLs) vorhanden sein. Diese zeigen entweder inhaltlich unterschiedliche Bilder oder ermöglichen Skalierbarkeit durch identische Inhalte in unterschiedlicher Auflösung. Ein einzelner Frame wird als Video Object Plane (VOP) bezeichnet. Sowohl Videos als auch Standbilder müssen kein rechteckiges Format mehr besitzen, sondern dürfen beliebige Formen aufweisen. Dies lässt sich durch einen zusätzlichen VOL realisieren, der als Shape bezeichnet wird. Im einfachsten Fall haben Shapes eine Farbtiefe von 1 Bit und definieren durch schwarze und weiße Pixel die Form des VOs (Abb. 1.27). Für Transparenzen innerhalb des VOs können Shapes mit einer Farbtiefe von 8 Bits verwendet werden, was 256 unterschiedliche Transparenzstufen ermöglicht. Im Bereich der Videobearbeitung und Fernsehtechnik sind Shapes unter der Bezeichnung Alpha-Kanal eine altbekannte Möglichkeit, um bspw. Personen vor anderen Hintergründen zu platzieren. Wie MPEG-2 erlaubt MPEG-4 die Verwendung von Halbbildmaterial und definiert 19 Profile und 7 Levels. Das sog. Simple Visual Profile komprimiert bspw. nur rechteckige VOLs und wird durch das Simple Scalable Visual Profile um Shape-Unterstützung ergänzt. Beide Profile eignen sich besonders für die Übertragung in drahtlosen Netzen der Generationen 2.5 und 3. Die von MPEG-4 unterstützte Farbtiefe pro Kanal sind 4 bis 12 Bits bei Farbbildern und 8 Bits bei Graustufenbildern. Die Kompressionsverfahren sind für Bitraten von etwa 64 Kbit/s bis 4 Mbit/s optimiert. Chrominanz wird im Format 4:2:0 verarbeitet, wobei die CrCb-Samples wie bei MPEG-2 positioniert sind. Gegenüber MPEG-2 wird durch Verbesserung der bekannten Verarbeitungsschritte eine höhere Kompressionsleistung erreicht. So können Makroblöcke aus 16 u 16 Pixeln bei Bedarf in vier Unterblöcke aus 8 u 8 Pixeln unterteilt werden, für die ebenfalls Bewegungskompensation zum Einsatz kommt. Dadurch lassen sich mehr Bewegungsvektoren berechnen und Prädiktionsfehler verringern. Bewegungsvektoren dürfen auch über den Bildrand hinausreichen, was bei den

Shapes

Profile und Levels

höhere Kompressionsleistung

Abb. 1.27: Zusammenhang von Bild- und Shapeinformation


■ ■ ■

53

globale Bewegungsvektoren

Prädiktionsmodus Direct Mode

Kompression binärer Shapes

Binary Alpha Blocks, kontextbasierte arithmetische Codierung

54

■ ■ ■

Vorgänger-Standards nicht erlaubt war. Durch die optional wählbare höhere Genauigkeit der Bewegungsvektoren von ¼ Pixel werden Prädiktionsfehler zusätzlich reduziert. Die DCT wird unverändert auf Basis von Blöcken aus je 8 u 8 Pixeln durchgeführt. Globale Bewegungsvektoren bieten die Möglichkeit, Kamerabewegungen wie bspw. Schwenks direkt zu berücksichtigen. Anstelle von Bewegungsvektoren für einzelne Makroblöcke lassen sich nun bis zu vier Bewegungsvektoren für das gesamte Bild ermitteln. Zusätzlich werden die Startpunkte der Bewegungsvektoren innerhalb des Referenzbildes abgespeichert. Für jeden Makroblock kann entweder der lokale Bewegungsvektor des Makroblocks verwendet oder zwischen den globalen Vektoren interpoliert werden. Dabei erfolgt die Interpolation für jedes Pixel des Makroblocks separat. Die bidirektionale Prädiktion wird um einen Prädiktionsmodus ergänzt, der als Direct Mode bezeichnet wird. Bei diesem Direct Mode werden die Vektoren für vorwärts- bzw. rückwärtsgerichtete Prädiktion nicht durch Blockmatching gewonnen, sondern aus dem Vektor des folgenden bzw. zurückliegenden Referenzbilds ermittelt. Dazu wird die zeitliche Entfernung des entsprechenden I- oder P-VOPs hinzugezogen, und der Vektor unter der Annahme linearer Bewegung zwischen den Referenzbildern interpoliert. Auch für die Intra-Kompression werden einige Neuerungen gegenüber MPEG-2 eingeführt. So gibt es u. A. neue Quantisierungstabellen und einen weiteren Modus für die Sortierung der AC-Koeffizienten. Dieser ergänzt die alternative Sortierreihenfolge von MPEG-2, so dass nun auch horizontale Frequenzen bevorzugt berücksichtigt werden können. Etwas genauer soll im Folgenden noch die Kompression von beliebig geformten VOs mit Hilfe von binären Shapes beschrieben werden. Auch die Verarbeitung von Shapes erfolgt in Form von Makroblöcken aus 16 u 16 Pixeln, die mit den Makroblöcken der eigentlichen Bildinformation im selben Raster liegen. Wie für die Bildinformationen kann für die Codierung von Shapes Intraframe- oder InterframeKompression eingesetzt werden. Die Makroblöcke von Shapes werden als Binary Alpha Blocks (BABs) bezeichnet und können in drei Arten unterschieden werden. Liegt ein BAB komplett außerhalb des VOPs, so ist er transparent. Dies wird durch einen entsprechenden Code vermerkt, und weitere Daten müssen nicht berücksichtigt werden. Im umgekehrten Fall, wenn der BAB komplett innerhalb des VOPs liegt, ist der Makroblock mit den korrespondierenden Bildinformationen zu codieren. Handelt es sich um einen BAB aus dem Grenzbereich eines VOP, so definiert er sowohl transparente Pixel als auch Pixel, die innerhalb eines VOPs liegen. In diesem Fall wird jedes Pixel des Makroblocks einzeln mit


Abb. 1.28: Kontextermittlung für die arithmetische Codierung

Hilfe einer kontext-basierten arithmetischen Codierung verarbeitet. Dieses Verfahren wurde vom JBIG-Standard [ISO93b] übernommen, der sich mit der Kompression von Bildern mit geringen Farbtiefen befasst. Für jedes Pixel x eines Makroblocks aus dem Grenzbereich wird zunächst ein Kontext ermittelt, wobei zwischen Intraframe- und Interframe-Kompression unterschieden wird. Den Kontext erhält man mit Hilfe eines Templates aus örtlich und zeitlich umliegenden Pixeln gemäß Abb. 1.28. Im Fall von Intraframe-Kompression werden 10 örtlich umliegende Pixel berücksichtigt, die jeweils entweder schwarz (Wert 0) oder weiß (Wert 1) sein können. Der Kontext für das Pixel x in Abb. 1.28 lautet 10 demnach 0011100001. Insgesamt können mit den 10 Pixeln 2 = 1024 verschiedene Kontexte unterschieden werden. Anhand des Kontexts wird nun die Wahrscheinlichkeit ermittelt, dass der Wert des Pixels x gleich 0 ist. Dazu kommt eine Tabelle zum Einsatz, der empirisch gewonnene Daten zugrunde liegen, und die sowohl Encoder als auch Decoder bekannt ist (Tabelle 1.7). Die Tabelle ordnet jedem Kontext einen Kontext-Wert c zwischen 1 und 65535 zu. Die Wahrscheinlichkeit, dass das Pixel x den Wert 0 besitzt, erhält man aus der Division von c mit 65535. Für das Template in Abb. 1.28 ergibt sich auf diese Weise W(0) = 0,5. Die Wahrscheinlichkeit W(0) und das Pixel x sind nun Eingabewerte für den kontextbasierten arithmetischen Encoder, der ein schwarzes Pixel x mit dem Teilintervall [0,W(0)) und ein weißes Pixel x mit dem Teilintervall [W(0), 1) codiert. Kontext-Nr.

Kontext

Kontext-Wert c

W(0)

0 1 ... 225 ... 1023

0000000000 0000000001 ... 0011100001 ... 1111111111

65267 16468 ... 32768 ... 235

65267/65535 = 0,9959 16468/65535 = 0,2513 ... 32768/65535 = 0,5000 ... 235/65535 = 0,0036


Tabelle 1.7: empirisch gewonnene Wahrscheinlichkeiten

■ ■ ■

55

Bewegungskompensation

Werden die Pixel eines BABs aus dem Grenzbereich Interframecodiert, so setzt sich der Kontext aus vier umliegenden Pixeln und sechs Pixeln aus einem Referenzbild (I- oder P-VOP) zusammen, wobei das Pixel x im aktuellen BAB und das Pixel c6 im BAB des Referenzbildes zunächst an gleicher Stelle liegen. Für den BAB des Referenzbildes wird dann jedoch Bewegungskompensation verwendet. Diese ist unabhängig vom VOP mit den Bildinhalten, und ein BAB kann im Gegensatz zu den herkömmlichen Makroblöcken nicht weiter unterteilt werden. Die Genauigkeit der Bewegungsvektoren ist auf 1 Pixel beschränkt, so dass das ReferenzTemplate nur um ganze Pixel verschoben werden kann. Eine weitere Besonderheit ist, dass bei B-VOPs der Shapes keine bidirektionale Prädiktion eingesetzt wird. Statt dessen wird vorwärtsbzw. rückwärtsgerichtete Prädiktion verwendet, je nachdem welches Referenzbild zeitlich näher liegt. Auch die Interframe-Kompression nutzt die kontext-basierte arithmetische Codierung, die jedoch nur 512 verschiedene Kontexte berücksichtigt und auch eine abweichende Wahrscheinlichkeits-Tabelle verwendet. Die arithmetische Codierung arbeitet verlustfrei. Soll ein BAB verlustbehaftet codiert werden, so geschieht dies durch Reduktion der Auflösung und Interpolation bei der Decodierung. 1.7.3.3 Advanced Video Coding

Entstehung und Einsatzgebiete

Advanced Video Coding (AVC) wurde durch das Joint Video Team von ITU und ISO/IEC erarbeitet. Die Entwicklung des Kompressionsverfahrens begann schon 1998, als die ITU sich das Ziel setzte, einen Codec zu schaffen, der die Effizienz bestehender Verfahren um das Doppelte übertreffen sollte. Ende 2001 beschlossen ITU und die MPEG-Gruppe, ihre Kompetenzen zu vereinen, was 2003 in der ersten Veröffentlichung des Codecs und schließlich in der Standardisierung als Teil 10 des MPEG-Standards resultierte. In Nomenklatur der ITU wird AVC als H.264 geführt, weshalb man den Codec oft auch als H.264/AVC bezeichnet. Bei der Entwicklung von AVC wurde ein breites Spektrum an möglichen Einsatzgebieten anvisiert [Wie03]: x Ausstrahlung und Verbreitung über Kabelfernsehen und Satelliten, über Kabelmodems und DSL sowie über terrestrischen Rundfunk x Speicherung auf optischen und magnetischen Speichermedien mit seriellem oder wahlfreiem Zugriff x Dialogdienste über Modems, ISDN, DSL, LAN, kabellose und Mobilfunk-Netze oder über Kombinationen davon

56

■ ■ ■


x Abrufdienste (Video-on-Demand und Streaming) über ISDN, Kabelmodems, DSL, LAN, kabellose Netze usw. x Multimedia Messaging Services (MMS) über ISDN, DSL, LAN und kabellose und Mobilfunk-Netze Gemäß den gesetzten Entwicklungszielen ist AVC heute sowohl in Bereichen zu finden, in denen qualitativ hochwertiges Video benötigt wird, als auch dort, wo die Minimierung der Datenrate als primäres Ziel gilt. So ist AVC neben MPEG-2 und Microsofts VC-1 auf den konkurrierenden, hoch auflösenden DVD-Nachfolgern HD-DVD und Blu-ray Disc vertreten und erlaubt die Video-Codierung in HDTVAuflösung von 1920 u 1080 Pixeln mit Datenraten im Bereich von 8 Mbit/s. Bei Handhelds ist AVC für die IP-basierte Übertragung von Videomaterial im Rahmen des Digital Video Broadcast vorgesehen. Auf Betreiben von Nokia und Ericsson wurde AVC im Jahre 2004 vom 3rd Generation Partnership Project (3GPP) für das Dateiformat 3GP übernommen. Bei 3GPP handelt es sich um einen Zusammenschluss mehrerer Standardisierungs-Gremien aus der TelekommunikationsBranche. Typische Datenraten von AVC für das 3GP-Format sind 50200 Kbit/s. Die Funktionalität des AVC-Verfahrens wurde trotz der vielfältigen Einsatzmöglichkeiten stark gegenüber MPEG-4 verringert, und stellt in gewisser Weise eine Rückkehr zu einfachen Kompressionsstandards dar, wie die erfolgreichen Vorläufer von MPEG-4 es sind. AVC beschränkt sich ganz auf die Codierung rechteckiger Videoinhalte, die als Halbbilder oder Vollbilder vorliegen können. Die Verarbeitung von Shapes, Standbildern oder 3D-Objekten ist nicht Teil des Standards. AVC wurde von Grund auf eigenständig entwickelt und ist zu keiner der früheren MPEG-Versionen kompatibel. Die geringere Komplexität wird auch bei der Betrachtung von Levels und Profilen deutlich. Während für MPEG-4 Visual 19 Profile und 7 Levels definiert wurden, kennt AVC mit Baseline, Main und Extended lediglich drei Profile. Wie die anderen MPEG-Standards definiert auch AVC nur die komprimierten Datenströme und den Decoder. Die Datenströme bestehen aus zwei konzeptionellen Schichten, dem Video Coding Layer (VCL) und dem Network Abstraction Layer (NAL). Der VCL realisiert die eigentliche Videokompression und erzeugt die Bitfolgen der komprimierten Makroblock-Slices. Diese werden in NAL Units aus mehreren Bytes eingebettet. Dabei handelt es sich um ein generisches Format, das eine einfache Abbildung auf Paket- und Bitstromorientierte Transportschichten erlaubt. So lassen sich AVC-Daten beispielsweise mit RTP/IP oder mit MPEG-2 Systems übermitteln. Auch Speichermedien mit wahlfreiem oder sequentiellem Zugriff werden unterstützt.


Reduktion von Komplexität

Aufbau der Datenströme

■ ■ ■

57

Fidelity Range Extensions

Sub-Makroblöcke

Langzeit-Prädiktion

gewichtete Prädiktion

Der ursprüngliche AVC-Standard sieht Videomaterial in 8 Bit Farbtiefe vor. Chrominanz wird im 4:2:0-Format verarbeitet, wobei die CrCb-Samples wie bei MPEG-2 und MPEG-4 positioniert sind. Um u. A. auch höhere Farbauflösungen wie 4:2:2 und 4:4:4 verarbeiten zu können, wurden die Fidelity Range Extensions vorgeschlagen, die kurz vor der Standardisierung stehen [ISO04b]. Die Extensions unterstützen auch Farbtiefen bis 12 Bit sowie höhere Auflösungen und Datenraten und werden besonders von der Fernseh- und Unterhaltungsbranche begrüßt [STL04]. Durch die Fidelity Range Extensions erhält AVC 4 zusätzliche Profile, die gemeinsam als High Profiles bekannt sind. Auch AVC ist wie seine Vorgänger ein hybrider, blockbasierter Codec mit Bewegungskompensation und definiert keine grundlegend neuen Verarbeitungsschritte. Die bessere Kompressionsleistung resultiert aus der Summe vieler kleiner Verfeinerungen an den einzelnen Verarbeitungsschritten [Wie03]. Eine Vielzahl der Neuerungen zielt auf eine genauere Prädiktion ab. So ist eine flexible, hierarchische Aufteilung des Bildes in Makroblöcke für die Bewegungskompensation möglich. Die grundlegenden Makroblockgrößen sind 16 u 16, 16 u 8, 8 u 16 und 8 u 8 Pixel. Die Unterteilung in 8 u 8 Pixel resultiert in sog. Sub-Makroblöcken, die jeweils weiter aufgeteilt werden können. Dabei sind analog zu den grundlegenden Makroblockgrößen Blöcke aus 8 u 4, 4 u 8 und 4 u 4 Pixel erlaubt. In Abb. 1.29 ist eine solche Bild-Unterteilung beispielhaft dargestellt. Die Bewegungsvektoren für die Makroblöcke werden nun stets mit einer Genauigkeit von ¼ Pixel errechnet. Ein weiteres Mittel zur Verbesserung der Prädiktionsleistung ist die Langzeit-Prädiktion. Während die vorwärtsgerichtete Prädiktion bisher nur auf einem Referenzbild basierte, wird nun eine größere Anzahl an Referenzbildern gespeichert. So kann dasjenige Referenzbild für die Prädiktion herangezogen werden, mit dem sich die geringsten Prädiktionsfehler ergeben. Auch für die bidirektionale Prädiktion kann auf mehrere Referenzbilder zurückgegriffen werden. Durch gewichtete Prädiktion kann das Prädiktionsbild, das sich aus den bewegungskompensierten Makroblöcken zusammensetzt, gewich-

Abb. 1.29: Mögliche Aufteilung in Makroblöcke

58

■ ■ ■


tet und um bestimmte Werte versetzt werden, was sich besonders bei Überblendungen im Videomaterial bezahlt macht. Bei allen blockbasierten Video-Codecs können Block-Artefakte entstehen, die sich als störende Blockbildungen im komprimierten Videomaterial bemerkbar machen. Daher wurden schon im Standard MPEG-4 Visual verschiedene Filter definiert, mit denen ein Decoder Block-Artefakte nachträglich verringern kann. Während diese Filter jedoch am Ende der Verarbeitungskette auf das decodierte Bild angewendet wurden, integriert AVC den Deblocking-Filter schon früher. Der Filter wird auf das Prädiktionsbild angewendet, was ebenfalls dazu beiträgt, Prädiktionsfehler zu verringern. Während B-Frames in früheren Standards nicht selbst als Basis für die Prädiktion herangezogen werden konnten, ist dies bei AVC nun erlaubt. So wird bei der Implementierung des Encoders größere Flexibilität eingeräumt. Weitere neue Freiheiten auf Seite des Encoders ergeben sich dadurch, dass keine feste Beziehung zwischen Anzeigereihenfolge und Übertragungsreihenfolge einer Bildfolge mehr definiert wird. So kann der Encoder Bilder nahezu in beliebiger Reihenfolge anordnen. Neben den Verarbeitungsschritten, die speziell auf die Prädiktion abzielen, wurden auch die restlichen Kompressionsschritte optimiert. So wird keine DCT mehr eingesetzt, sondern eine Integer-Transformation, die auf Basis von 4 u 4 Pixeln arbeitet. Diese Blockgröße korrespondiert mit der kleinsten Makroblockgröße für die Prädiktion. Wenn nötig, kann die Blockgröße für tieffrequente Chrominanzinformation durch eine hierarchische Transformation auf 8 u 8 Pixel erhöht werden. Dasselbe gilt für Luminanzinformation, bei denen auch Blockgrößen von 16 u 16 Pixeln erreicht werden können. Die Integer-Transformation ist exakt umkehrbar und lässt sich effizienter berechnen als die DCT. DCT und IDCT konnten im Rahmen der MPEG-Vorgaben in Encoder und Decoder unterschiedlich implementiert sein, wodurch dasselbe Videomaterial von unterschiedlichen Decodern unterschiedlich decodiert wurde. Bei AVC wird dagegen von jedem Standard-konformen Decoder dasselbe Bild erzeugt. Durch die veränderte Transformation musste auch die nachfolgende Entropiecodierung speziell angepasst werden. Als Verarbeitungsschritte werden eine kontext-basierte Huffman-Codierung und eine kontext-basierte arithmetische Codierung unterstützt. Weitere Verbesserungen betreffen nicht die Kompression, sondern die Übertragung, und erhöhen dort speziell die Robustheit gegenüber Datenverlusten. So sind nun wieder sehr flexible Gruppierungen der Makroblöcke zu Slices möglich, was eine Rückbesinnung auf die Konzepte von MPEG-1 bedeutet. Slices können in beliebiger Reihenfolge angeordnet werden und müssen nicht die Rasterzeilen-Reihenfolge


Deblocking-Filter

weitere Verbesserungen der Prädiktion

Integer-Transformation

Robustheit gegenüber Datenverlusten

■ ■ ■

59

Slice Groups

SI- und SP-Frames

früherer Standards von links nach rechts und von oben nach unten einhalten. Darüber hinaus können Slices flexibel zu Slice Groups zusammengefasst werden, die auch untereinander verschränkt sein dürfen. Dabei werden fünf Standardmuster für Slice Groups vorgegeben, es ist jedoch auch eine völlig freie Zuordnung von Slices zu Slice Groups möglich. Trotz Verschränkung werden die Makroblöcke einer Slice Group alle an einem Stück codiert. Gehen nun Blöcke einer Slice Group verloren, so können diese z. B. durch Interpolation aus den anderen Slice Groups ersetzt werden. Encoder können Bilder oder Teile von Bildern redundant codieren, so dass bei Informationsverlust der Rückgriff auf die redundanten Daten möglich ist. Meist ist dabei nicht die gesamte ursprüngliche Information redundant vorhanden, sondern lediglich qualitativ schlechtere Versionen. Mit SI-Frames und SP-Frames werden spezielle Bildtypen eingeführt, die u. A. das Umschalten zwischen unterschiedlichen Videostreams vereinfachen. So kann ein Decoder bei variierender Verbindungsgeschwindigkeit leicht zwischen unterschiedlich komprimierten Versionen eines Videos wechseln.

1.8 Audiokompression mit MPEG

MPEG-2 Audio

60

■ ■ ■

Obwohl bei digitalen Audiosignalen weitaus geringere Datenmengen anfallen als bei digitalem Video, kann auch hier selten auf Kompression verzichtet werden. In diesem Kapitel werden mit MPEG-1 Audio, das durch MP3 bekannt ist, und MPEG-4 Audio Lossless Coding zwei sehr unterschiedliche Verfahren für die Kompression von Audiodaten vorgestellt. MPEG-1 Audio verwendet ein psychoakustisches Modell und arbeitet verlustbehaftet. MPEG-4 Audio Lossless Coding befindet sich derzeit noch in der Standardisierungsphase und ist ein verlustfreies Verfahren, das weitgehend auf Prädiktion basiert. Für MPEG-1 Audio existieren inzwischen viele Alternativen, die bei gleicher Qualität höhere Kompressionsraten erzielen. Mit dem Nachfolger MPEG-2 Audio kamen zunächst nur Erweiterungen für geringe Sampling- und Bitraten hinzu. Zusätzlich wird durch MPEG-2 Audio die Kompression von 5.1-Mehrkanalton mit fünf vollwertigen Kanälen und einem Kanal für tiefe Frequenzen unterstützt. Alle diese Erweiterungen sind zu MPEG-1 Audio abwärtskompatibel. Im Falle von Mehrkanalton werden die Kanäle so auf Stereo heruntergemischt, dass sie in einem MPEG-1-kompatiblen Datenstrom transportiert werden können. MPEG-1-Decoder verwenden dann diese Stereospur, während MPEG-2-Decoder den ursprünglichen Mehrkanalton rekonstruieren


können. Informationen für die Rekonstruktion können ebenfalls im Datenstrom untergebracht oder separat übermittelt werden. Außer für die Mehrkanalunterstützung definiert MPEG-2 gegenüber MPEG-1 keine grundlegend neuen Verarbeitungsschritte, sondern nimmt nur kleine Änderungen an der Bitstrom-Syntax sowie an den psychoakustischen Modellen vor, um den neuen Sampling- und Bitraten gerecht zu werden. Diese spärlichen Neuerungen gewährleisten zwar die Abwärtskompatibilität, bieten jedoch auch wenig Raum, um die Kompressionsleistung nennenswert zu verbessern. Daher wurde Advanced Audio Coding (AAC) als Teil 7 des MPEG-2-Standards veröffentlicht, das nicht mehr abwärtskompatibel ist. Auch wenn AAC ebenfalls keine grundlegend neuen Verarbeitungsschritte einführt, wird die Kompressionsrate durch viele kleine Ergänzungen und Optimierungen um bis zu 30% verbessert [Bra99]. So werden Frequenzen z. B. mit höherer Auflösung verarbeitet und der Einsatz von Prädiktion ist optional ebenfalls möglich. MPEG-4 bietet wie auch schon für die Videokompression eine breite Palette an unterschiedlichen Kompressionsverfahren, und zielt im Besonderen darauf ab, auch die Codierung mit geringen Bitraten unter 64 kbit/s zu verbessern [HeG00]. Teile des Standards beschäftigen sich speziell mit der Kompression von Sprache. Sowohl für Sprachsignale als auch für Musik werden zusätzlich parametrische Codierverfahren standardisiert. Die universell einsetzbare Audiokompression von MPEG-4 baut auf AAC auf, und wird daher auch als MPEG-4 AAC bezeichnet. Eine Ergänzung zu AAC ist Perceptual Noise Substitution (PNS), bei dem rauschartige Signalkomponenten durch eine parametrische Repräsentation ersetzt werden. LangzeitPrädiktion (vgl. Kap. 1.8.2) ermöglicht die Berücksichtigung von Redundanz, die durch periodische Signalkomponenten bedingt ist. Mit TwinVQ (vgl. Kap. 1.3.1) wird die herkömmliche Quantisierung durch eine optionale Vektorquantisierung ergänzt. Weitere neue Eigenschaften von MPEG-4 AAC sind eine verbesserte Fehlertoleranz und die Möglichkeit, skalierbar zu komprimieren.

MPEG-2 Advanced Audio Coding (AAC)

MPEG-4 Audio

1.8.1 MPEG-1 Audio MPEG-1 Audio unterstützt die Kompression von Audiodaten mit Samplingraten von 32, 44,1 und 48 kHz und definiert 3 Audio-Layer, die sich bezüglich ihrer Komplexität und Kompressionsleistung unterscheiden. Für die ersten beiden Layer liefert MPEG-1 Beispiel-Implementierungen psychoakustischer Modelle (vgl. Kap. 1.4.2), die im Encoder verwendet werden können. Datenraten und Einsatzmöglichkeiten der Layer werden im folgenden Abschnitt nach [Pan95] umrissen.


■ ■ ■

61

Tabelle 1.8: Datenraten der drei Layer von MPEG-1 Audio

Gegenstand der Standardisierung

minimale Datenrate optimale Datenrate maximale Datenrate

Layer I

Layer II

Layer III

32 kbit/s >128 kbit/s 448 kbit/s

32 kbit/s ~128 kbit/s 384 kbit/s

32 kbit/s ~64 kbit/s 320 kbit/s

Kompression nach dem Layer I wurde u. A. für die Digital Compact Cassette (DCC) von Philips eingesetzt, die jedoch mit dem Aufkommen der CD-R eingestellt wurde. Layer I ist einfach aufgebaut und eignet sich besonders für Bitraten von 128 kbit/s an aufwärts. Layer II ist für Bitraten um 128 kbit/s optimiert, und Layer III für geringe Bitraten um 64 kbit/s. Für jeden Layer sind 14 verschiedene, feste Bitraten vorgegeben. Der Standard erlaubt es aber auch, die Bitrate für jeden Layer frei einzustellen. In Layer I und II sind die Bitraten stets konstant, Layer III erlaubt dagegen auch variable Bitraten. Wird die Bitrate allerdings frei definiert, so ist sie auch hier konstant und kann nicht variieren. In Tabelle 1.8 findet sich ein Überblick zu den Bitraten der drei Layer. Einsatzgebiete des Layers II sind die Video-CD und der digitale Radio-Rundfunk (Digital Audio Broadcast, DAB). Layer III bietet qualitativ die besten Resultate und ist landläufig unter der Bezeichnung MP3 bekannt. Wie die MPEG-Verfahren für die Kompression von Videodaten schreibt MPEG-1 Audio nur die Syntax für den komprimierten Datenstrom und den Decoder vor. So bleiben auf Seite des Encoders viele Möglichkeiten zur Optimierung offen. Dies gilt im Besonderen natürlich auch für psychoakustische Modelle, welche maßgeblich die Qualität eines Encoders bestimmen [Bra99]. 1.8.1.1 Funktionsprinzip

Layer III

62

■ ■ ■

In Abb. 1.30 ist das Funktionsprinzip eines Layer III Audio Coders zu sehen. Das Audiosignal wird zunächst durch eine Filterbank in 32 Subbänder gleicher Breite zerlegt, um der eingeschränkten Frequenzauflösung des menschlichen Gehörs Rechnung zu tragen. Die Subbänder können nicht exakt voneinander abgegrenzt werden, sondern überlappen sich gegenseitig. Somit können sich Maskierer auch auf zwei aneinander angrenzende Subbänder auswirken. Bei der Wahl von 32 Subbändern gleicher Breite handelt es sich um eine sehr grobe Annäherung, da die kritischen Frequenzgruppen des Gehörs unterschiedliche Breiten besitzen (Kap. 1.4.2). Daher ist bei Layer-IIIEncodern zusätzlich eine modifizierte diskrete Kosinustransformation (MDCT) nachgelagert, die jedes Subband in weitere 18 feinere Bänder


Abb. 1.30: Funktionsprinzip des MPEG-1 Audio Layer III

zerlegt. Durch die feinere Frequenzauflösung kann das Quantisierungsrauschen genauer an die Hörschwelle angenähert werden. Die MDCT wird auf Blöcke zeitlich aufeinander folgender Samples angewendet, wobei sich die Blöcke gegenseitig zu 50% überlappen. Als Blocklängen kommen 12 bzw. 36 Samples zum Einsatz. Die Wahl unterschiedlicher Blocklängen wirkt der Tatsache entgegen, dass die zeitlichen Signalinformationen bei der Transformation in den Frequenzbereich verloren gehen. So wird für wechselhafte Signalabschnitte, in denen eine genauere zeitliche Auflösung gewünscht wird, die kürzere Blocklänge aus 12 Samples eingesetzt. Blöcke aus 36 Samples werden dagegen für stationäre Signalabschnitte herangezogen, um dort eine höhere Frequenzauflösung zu erhalten. In den Layers I und II fehlt die MDCT, so dass u. U. mehrere kritische Frequenzgruppen auf ein Subband abgebildet werden. Dies gilt insbesondere für niedrige Frequenzen, da die Frequenzgruppen dort besonders schmal sind. In solchen Fällen bestimmt die Frequenzgruppe mit der geringsten Maskierungskapazität die Quantisierung des gesamten Subbands. Die Filterbank-Zerlegung ist ein irreversibler Vorgang, der sich nicht ohne Verluste wieder rückgängig machen lässt. Auftretende Fehler sind jedoch sehr gering. Die MDCT und zugehörige inverse Transformation arbeiten verlustfrei. Die Beispiel-Implementierungen der psychoakustischen Modelle im MPEG-Standard verwenden nicht die Signal-Repräsentation nach Filterbank bzw. MDCT für die Ermittlung der optimalen Quantisierung. Insbesondere die Layers I und II bieten durch die fehlende MDCT keine ausreichend genaue Frequenzauflösung. Daher nehmen die Modelle eine separate Transformation des ursprünglichen Audiosignals in den Frequenzbereich vor, was durch eine schnelle Fouriertransformation (FFT) erfolgt. Je nach psychoakustischem Modell und Layer werden dabei 512 oder 1024 aufeinander folgende Samples transformiert. Durch die Transformation von Sampleblöcken bleibt zeitliche Signalinformation wie bei der MDCT innerhalb gewisser Grenzen erhalten. So resultiert aus einer Samplingfrequenz von 44,1 kHz und einer Blocklänge von 512 Samples z. B. eine zeitliche Auflösung von etwa 11,6 ms.


Blockbildung

Layers I und II

psychoakustische Modelle

■ ■ ■

63

Maskierungsschwelle

Quantisierung in Layer III

Verstärkungsfaktoren

Huffman-Codierung

64

■ ■ ■

Auf Basis der Zeit-Frequenzrepräsentation des Audio-Signals bestimmt das psychoakustische Modell die Maskierungsschwelle für das Quantisierungsrauschen. Dabei werden Frequenzen nach kritischen Frequenzgruppen sortiert und gruppenweise verarbeitet. Für maskierende Signalkomponenten wird die Maskierungskapazität innerhalb der jeweiligen Frequenzgruppe und mögliche Auswirkungen des Maskierers auf umliegende Frequenzgruppen ermittelt. Darüber hinaus wird die Ruhehörschwelle berücksichtigt, um bestimmte Signalkomponenten evtl. komplett zu eliminieren. Für die MDCT wählt das psychoakustische Modell in Abhängigkeit von der Signalcharakteristik zusätzlich die Blocklänge aus. Quantisierung und Codierung der MDCT-Koeffizienten werden im Folgenden für Layer III dargestellt. In den anderen Layers ist die Quantisierung etwas einfacher, und eine Codierung der quantisierten Koeffizienten wird dort nicht vorgenommen. Die Quantisierung der MDCT-Koeffizienten erfolgt in Layer III nichtlinear, so dass kleine Koeffizienten feiner quantisiert werden, während für große Koeffizienten eine gröbere Quantisierung gewählt wird. Dadurch erfolgt schon eine einfache Rauschformung mit stärkerem Rauschen bei Signalteilen, die durch große Koeffizienten repräsentiert werden. Da große Koeffizienten aus hohen Signalamplituden resultieren, wird das Rauschen dabei meist gut überdeckt. Praktisch realisiert wird die Quantisierung in der Regel durch zwei verschachtelte Schleifen, innerhalb derer Verstärkungs- und Skalenfaktoren ermittelt werden [Bra99]. Die Verstärkungsfaktoren beeinflussen für jeden Datenblock die Schrittbreite der Quantisierung. Diese hat wiederum direkten Einfluss auf die resultierende Datenrate, weshalb die Schleife zur Bestimmung des Verstärkungsfaktors als Rate Loop bezeichnet wird. Im Rate Loop werden die quantisierten Werte eines Sampleblocks mit einer Huffman-Codierung codiert, die häufiger auftretenden Werten kurze Codewörter zuweist. Ist die resultierende Datenrate nach der Codierung zu hoch, wird der Verstärkungsfaktor angehoben und der Block damit gröber quantisiert. Dies wird so lange wiederholt, bis nach der Huffman-Codierung die gewünschte Datenrate vorliegt. Für die Huffman-Codierung werden die 576 Koeffizienten jedes Blocks zunächst umsortiert, was im einfachsten Fall aufsteigend nach Frequenzen erfolgt. Während bei den tiefen Frequenzen große MDCTKoeffizienten auftreten, finden sich bei hohen Frequenzen viele Nullkoeffizienten. Analog zur Koeffizienten-Sortierung in der Bilddatenkompression zielt man demnach darauf ab, Nullkoeffizienten zu gruppieren und effizient durch eine Lauflängencodierung zu erfassen. Die sortierten Koeffizienten werden in drei Regionen unterteilt. Die erste Region enthält alle Nullkoeffizienten bis zum ersten Koeffizienten ungleich 0,


die einer Lauflängencodierung unterzogen werden. Für die zweite und dritte Region ist eine Auswahl separater Tabellen mit Huffman-Codes verfügbar, die speziell an die typische Signalstatistik dieser Bereiche angepasst sind. In einer zweiten Schleife wird anhand des psychoakustischen Modells überprüft, ob durch die Quantisierung des Rate Loops ein Rauschen entstanden ist, das über der Hörschwelle liegt. Ist dies der Fall, werden die Koeffizienten des betroffenen Subbands durch einen Skalenfaktor angehoben. Da diese Anhebung in einer höheren Amplitude der Signalkomponenten resultiert, wird der Signal-Rausch-Abstand bei einem weiteren Quantisierungs-Durchlauf des Rate Loops verbessert. Da höhere Amplituden gleichzeitig jedoch mehr Bits für die Codierung benötigen, bedeutet eine Anhebung durch den Skalenfaktor implizit auch eine Umverteilung der Bitallokation unter den einzelnen Subbändern. Die verfügbare Bitrate wird dadurch so auf die Subbänder verteilt, dass Quantisierungsrauschen dort entsteht, wo es am ehesten vom psychoakustischen Modell toleriert wird. Aufgrund ihrer rauschformenden Eigenschaft wird die Schleife zur Bestimmung der Skalenfaktoren als Noise Control Loop bezeichnet. Rate Loop und Noise Control Loop werden wechselseitig durchgeführt, wobei der Rate Loop immer dann ausgeführt wird, wenn im Noise Control Loop Skalenfaktoren angepasst wurden. Der Rate Loop wird demnach vom Noise Control Loop aus aufgerufen. Durch diese Implementierung können u. U. Endlosschleifen entstehen, weshalb im Encoder auch geeignete Abbruchkriterien zu implementieren sind. Die Anhebung einzelner Subbänder muss im Decoder natürlich wieder rückgängig gemacht werden, weshalb Skalen- und Verstärkungsfaktoren zusammen mit den Nutzdaten in den Datenstrom geschrieben werden. Obwohl sich die Skalenfaktoren für eine DeltaCodierung anbieten, werden sie nicht codiert, sondern direkt übertragen. Erst von MPEG-2 AAC an werden die Skalenfaktoren durch eine Delta-Codierung verarbeitet. Bei der Formatierung des Datenstroms kann optional eine spätere Fehlererkennung durch Einfügen von CRC-Werten ermöglicht werden. Zusätzlich lassen sich sog. Ancillary-Daten eincodieren, die Metainformationen über das Audiomaterial enthalten. Diese auch als ID3-Tag bekannten Informationen können von Abspielgeräten angezeigt werden und lassen sich beliebig editieren.

Skalenfaktoren

ID3-Tags

1.8.1.2 Codierung von Stereosignalen

Stereophone Wahrnehmung, also die zweidimensionale Lokalisation einer sog. Phantomschallquelle zwischen linkem und rechtem Laut-


stereophone Wahrnehmung

■ ■ ■

65

Abb. 1.31: Lokalisation der Phantomschallquelle bei stereophoner Wiedergabe

Binaural Masking Level Difference

Joint Stereo Modus

66

■ ■ ■

sprecher, wird durch zwei Faktoren bestimmt (Abb. 1.31). Zum einen beeinflusst die jeweilige Lautstärke des rechten bzw. linken Audiosignals die örtliche Wahrnehmung der Phantomschallquelle. Zum anderen tragen Laufzeitunterschiede der Schallwellen von den Lautsprechern zum Zuhörer dazu bei, die Phantomschallquelle eher links oder eher rechts zu orten. Für die stereophone Aufnahme existieren unterschiedliche Verfahren, die jeweils den einen oder anderen Faktor stärker berücksichtigen [Dic97]. MPEG-1 Audio unterstützt sowohl Mono- als auch Zweikanal-Ton. Zweikanal-Ton kann aus zwei unabhängigen Einzel- oder Stereokanälen bestehen, was jeweils durch separate Codierung der Kanäle realisiert wird. Da die Kanäle einzeln codiert werden, ist auch das Quantisierungsrauschen der Kanäle unabhängig voneinander und scheint bei stereofoner Wiedergabe nicht aus Richtung der Phantomschallquelle zu kommen. So kann das Quantisierungsrauschen wahrnehmbar werden, auch wenn es in den einzelnen Kanälen nicht hörbar ist. Der Effekt, dass Geräusche sich gegenseitig weniger verdecken, wenn sie stereofon aus unterschiedlichen Richtungen kommen, wird Binaural Masking Level Difference (BMLD) genannt [ZwF99]. Die BMLD spielt auch im Zusammenhang mit dem Cocktailparty-Effekt eine Rolle, der sich speziell auf Sprache in lauter Umgebung konzentriert. Hier zeigt sich ebenfalls, dass stereofones Hören die Verständlichkeit des Sprachsignals in Anwesenheit von Störgeräuschen stark verbessert. Militärpiloten in Kampfflugzeugen erhalten Sprachnachrichten über Kopfhörer, die Signale für das eine Ohr gegenüber den Signalen für das andere Ohr um 180° in der Phase drehen. Durch diese künstlich erzeugte Laufzeitdifferenz können die Nachrichten trotz des Fluggeräuschs gut verstanden werden [Aro92]. Bei der Ermittlung der Maskierungsschwelle für die separate Codierung von Stereokanälen muss die BMLD mit berücksichtigt werden. Neben der separaten Codierung zweier Kanäle existiert ein Joint Stereo Modus, bei dem Korrelationen zwischen den Stereokanälen für


die Kompression berücksichtigt werden. Joint Stereo dient MPEG-1 Audio als Oberbegriff für zwei unterschiedliche Arten der StereoCodierung, namentlich Intensity Stereo und MS-Stereo. Codierung als Intensity Stereo macht sich die psychoakustische Eigenschaft des Gehörs zu Nutze, eine eingeschränkte Stereo-Wahrnehmung für Frequenzen über 2 kHz zu besitzen. Ab dieser Frequenz wird die Stereo-Lokalisation innerhalb kritischer Frequenzgruppen wenig von Laufzeitdifferenzen sondern fast nur noch von Lautstärkeunterschieden des rechten bzw. linken Audiosignals beeinflusst. Daher addiert Intensity Stereo die Stereoinformation beider Kanäle in hochfrequenten Subbändern zu einem Summensignal. Je nach gewünschter Kompressionsrate lassen sich dabei 16 bis 28 von insgesamt 32 korrespondierenden Subbändern zusammenfassen. Mit Hilfe zusätzlicher Skalierungsfaktoren kann der Decoder aus dem Summensignal wieder zwei unterschiedliche Signale errechnen, die sich jedoch nur noch in der Signalintensität und nicht mehr in der Laufzeit unterscheiden. Die MS-Stereo-Codierung errechnet für bestimmte Frequenzgruppen aus dem linken und rechten Stereokanal durch Summen- bzw. Differenzbildung ein Mitten- bzw. Seitensignal. Je stärker die Phantomschallquelle in der Mitte der beiden Kanäle lokalisiert ist, desto stärker lässt sich das Seitensignal komprimieren. Dies liegt daran, dass die Unterschiede zwischen linkem und rechtem Kanal dann gering sind, und diese Redundanz durch Differenzbildung effizient verringert wird. Die Umwandlung in Mitten- und Seitensignal kann vom Decoder ohne Informationsverlust wieder rückgängig gemacht werden. Für sich alleine betrachtet stellt MS-Stereo-Codierung demnach eine verlustfreie Redundanzreduktion dar. Allerdings erlaubt MS-Stereo eine gröbere Quantisierung als die separate Codierung einzelner Kanäle, da sich die BMLD durch die kombinierte Codierung weniger stark auswirkt. Während Joint Stereo in Layer I und II immer als Intensity Stereo realisiert wird, kann das Verfahren in Layer III adaptiv zwischen Intensity und MS Stereo wechseln. Der Begriff Joint Stereo ist sehr gebräuchlich und wird auch im Zusammenhang mit anderen Kompressionsverfahren verwendet, wobei er nicht unbedingt dieselben Realisationsformen von Stereo-Codierung bezeichnet.

Intensity Stereo

MS-Stereo

1.8.2 MPEG-4 Audio Lossless Coding Während sich die verlustfreie Bilddatenkompression mit JPEG-LS und JPEG-2000 schon seit längerer Zeit in speziellen Anwendungsbereichen etabliert hat, befinden sich entsprechende Verfahren für Audio derzeit noch in der Standardisierungsphase. Durch Audio Lossless


■ ■ ■

67

Lossless Predictive Audio Coder (LPAC), Advanced Audio Zip (AAZ)

adaptive prädiktive Codierung

Frame- und Blockbildung

68

■ ■ ■

Coding (ALS) nach [LMH05] soll MPEG-4 um ein Verfahren für die verlustfreie Audiokompression ergänzt werden. ALS ist Nachfolger des Lossless Predictive Audio Coder (LPAC), der an der Technischen Universität Berlin entwickelt wurde. LPAC konnte sich bei einer Evaluation der MPEG-Arbeitsgruppe gegenüber Verfahren von Microsoft, Real Networks und dem Fraunhofer IIS durchsetzen und wurde als Basis für die weitere Entwicklung ausgewählt [Lie04]. Da ALS ausschließlich verlustfrei komprimiert und keine Skalierungseigenschaften aufweist, soll MPEG-4 mit Advanced Audio Zip (AAZ) durch ein zusätzliches Verfahren komplettiert werden, das von verlustbehaftet bis verlustfrei skalierbar ist [YLR04]. Entwickelt wurde AAZ am Institute for Infocomm Research, einer staatlichen Forschungseinrichtung in Singapur. 16 ALS unterstützt 2 Kanäle, die beliebige Abtastraten besitzen und mit maximal 32 Bit quantisiert sein dürfen. Wie sein Vorgänger LPAC verwendet ALS adaptive prädiktive Codierung als wichtigsten Verarbeitungsschritt, um die Korrelation der Signalwerte zu verringern und die Bedingungen für eine anschließende Entropiecodierung zu verbessern. Adaptiv ist die Prädiktion sowohl bezüglich der Werte der Prädiktorkoeffizienten, als auch bezüglich der Ordnung des Prädiktors, also der berücksichtigten Samplezahl. Bei der Prädiktion unterstützt ALS rückwärts- oder vorwärtsgerichtete Varianten, die jeweils unterschiedliche Anforderungen an den Decoder stellen. Die rückwärtsgerichtete Prädiktion erfolgt auf Basis bereits decodierter Werte, und berücksichtigt somit nur die zeitlich zurückliegende Signalcharakteristik. Dies hat den Nachteil, dass meist größere Prädiktionsfehler entstehen. Darüber hinaus müssen Decoder dieselben prädiktiven Schritte ausführen wie Encoder, wodurch Decoder-Implementierungen entsprechend aufwändig sind. Ein Vorteil der rückwärtsgerichteten Prädiktion ist, dass der Decoder keine zusätzlichen Informationen benötigt. Die vorwärtsgerichtete Adaption erfolgt nicht ausschließlich auf Basis bereits decodierter Werte, sondern berücksichtigt teilweise auch die zeitlich voraus liegende Signalstatistik. Dazu müssen dem Decoder zusätzliche Informationen in Form von Filterkoeffizienten (LPC) bereitgestellt werden, die neben den Prädiktionsfehlern zu übermitteln sind. Dadurch ist der Aufwand für die Decodierung geringer, weil der Decoder selbst keine Prädiktion mehr vornehmen muss, sondern die übermittelten Filterkoeffizienten verwenden kann. Nachteilig wirkt sich auf die Kompressionsrate aus, dass insgesamt mehr Information übermittelt werden muss. Für die Verarbeitung wird das Audiosignal in Frames und Blöcke unterteilt. Die Frames bestehen aus einer konstanten Anzahl von N Samples, wobei N an die Samplingfrequenz der Audiodatei angepasst


Abb. 1.32: Mögliche Aufteilungen in Frames bei der Verarbeitung

werden kann. Typische Framelängen sind 2048 Samples bei 48 kHz und 4096 Samples bei 96 KHz, was beides einer Dauer von etwa 43 ms entspricht. Jeder Frame kann in max. 32 Blöcke unterteilt werden, und für jeden Block lassen sich die Ordnung des Prädiktors und die Filterkoeffizienten neu bestimmen. Als Blocklängen sind Kombinationen aus N, N/2, N/4, N/8, N/16 und N/32 Samples erlaubt, die nahezu beliebig variiert werden dürfen. Die einzige Vorgabe besagt, dass die Unterteilung hierarchisch erfolgen muss, so dass jeder Block sich aus der Unterteilung eines übergeordneten Blocks doppelter Länge ergibt. Dies ist in Abb. 1.32 dargestellt, wobei die Unterteilungen mit den grau markierten Blöcken nicht zulässig sind. Indem die Ordnung des Prädiktors auf Blockebene angepasst wird, können bei stationären Schallereignissen längere Blöcke und ein Prädiktor höherer Ordnung verwendet werden. Dabei werden die Prädiktionsfehler mit steigender Ordnung des Prädiktors geringer, da unter Berücksichtigung mehrerer Signalwerte genauere Vorhersagen möglich sind. Bei der vorwärtsgerichteten Adaption nimmt mit der Ordnung des Prädiktors jedoch auch die Anzahl der zu übermittelnden Prädiktorkoeffizienten zu, was wiederum in einer geringeren Kompressionsrate resultiert. Es ist also die Aufgabe des Encoders, den besten Kompromiss zwischen beiden Extremen zu finden. Bei wechselhaften Schallereignissen ist es sinnvoll, nur wenige Samples für die Prädiktion heranzuziehen. Die Aufteilung des Audiosignals in Blöcke erfolgt durch den Encoder und ist daher – wie bei allen MPEGVerfahren üblich – nicht standardisiert. Die beschriebene Prädiktion wird noch durch eine Langzeit-Prädiktion ergänzt, die speziell auf die Dekorrelation von zeitlich weit auseinander liegenden Signalwerten abzielt, und u. A. auch bei der Sprachcodierung für den Mobilfunk-Standard GSM oder bei der verlustbehafteten Audiokompression MPEG-4 AAC eingesetzt wird. Korrelation zeitlich weit auseinander liegender Samples kann z. B. durch harmonische Grundfrequenzen von Musikinstrumenten bedingt sein. Instrumente erzeugen Klänge, die aus einer periodischen Grundfrequenz und einer Reihe von Obertönen bestehen. Die Grundfrequenz bewegt sich bei vielen Instrumenten im Bereich von 50– 250 Hz, während Frequenzen der Obertöne ganzzahlige Vielfache der Grundfrequenz betragen [Dic97]. Die Schwingungsdauer einer Grund-


Langzeit-Prädiktion

■ ■ ■

69

Kompressionsraten von ALS und Monkey's Audio

frequenz von 220 Hz wird bei einer Samplingfrequenz von 48 KHz auf 218 Samples abgebildet, bei 192 kHz sind es schon 872 Samples. Um die resultierende Sample-Korrelation zu berücksichtigen, wird ein Prädiktor entsprechender Ordnung benötigt. Durch vorwärts-adaptive Prädiktoren dieser Größenordnung wird jedoch die Kompressionsrate beeinträchtigt, da aus den oben geschilderten Gründen eine große Anzahl an zusätzlichen Prädiktorkoeffizienten übermittelt werden muss. Daher kann der Encoder bei Prädiktoren hoher Ordnung eine erneute Prädiktion auf die Prädiktionsfehler anwenden und so die Kompressionseffizienz zusätzlich verbessern. ALS kann durch Prädiktion mit anschließender Entropiecodierung nur geringere Kompressionsraten erreichen als eine verlustbehaftete Codierung auf Basis eines psychoakustischen Modells. Durch feine Optimierung der prädiktiven Schritte lassen sich jedoch auch mit ALS Kompressionsraten von 50% und mehr realisieren. Bei der Entwicklung von ALS wurde der Codec unter anderem auch mit Monkey's Audio (MA) verglichen [Lie03]. Bei MA handelt es sich um einen freien Open-Source-Codec, der frühere ALS-Versionen teilweise in der Kompressionsrate überbot. Der Encoder von MA besaß darüber hinaus eine um die Hälfte geringere Komplexität. Allerdings ist die Implementierung von Encoder und Decoder bei MA ungefähr gleich aufwändig, während ein Decoder bei ALS wesentlich einfacher aufgebaut ist. Auch steht zu vermuten, dass ALS durch die MPEG-Gruppe soweit optimiert werden konnte, dass er bei einem erneuten Vergleich inzwischen in vielen Punkten besser abschneiden würde als MA.

1.9 Verfahren der Sprachkompression

Verzögerung bei der Übertragung

70

■ ■ ■

Sprachkompressions-Verfahren, die im ISDN-Festnetz, in Mobilfunknetzen oder bei Voice over IP verwendet werden, berücksichtigen die Charakteristika menschlicher Sprache und sind für EchtzeitGesprächssituationen mit besonderen Anforderungen an die Codierungsverzögerung optimiert. Diese besitzt beträchtlichen Einfluss auf die Kommunikationssituation und kann im ungünstigsten Fall zu einer empfindlichen Störung des Gesprächsflusses führen. Es existiert eine Empfehlung der ITU [ITU96a], wie auftretende Verzögerungszeiten bei Sprachübertragungen in Telefonnetzen zu klassifizieren und zu bewerten sind. Diese Empfehlung besagt, dass eine Ende-zu-Ende-Verzögerung von bis zu 150 ms für die meisten Anwendungen akzeptabel ist, während 150 ms und mehr nur noch unter bestimmten Bedingungen erträglich sind.


Allen Verfahren für die Sprachkompression ist gemein, dass sie eine geringere Samplingrate beim Ausgangsmaterial voraussetzen als generische Verfahren für die Audiokompression. Die stimmhaften Anteile der menschliche Sprache entstehen durch teilweise resonatorische Verstärkung des im Kehlkopf erzeugten Anregungssignals innerhalb des Mund- und Nasenraums, der auch als Vokaltrakt bezeichnet wird. Die verstärkten Frequenzbereiche werden als Formanten bezeichnet. Zur Verständlichkeit der Sprache tragen vor allem die beiden untersten Formanten F1 und F2 bei, die ungefähr zwischen 200 und 3500 Hz zu finden sind [Dic97]. Das zu codierende Sprachsignal wird daher vor der Digitalisierung entsprechend bandbegrenzt, wodurch unter Berücksichtigung des Abtasttheorems (Kap. 1.3.1) eine Samplingrate von 8 kHz für die Abtastung ausreicht. Quantisiert wird in der Regel mit 8 Bit. Codecs, die mit einer Samplingrate von 8 kHz arbeiten, decken das sog. Telephone Band von 300 Hz bis 3,4 kHz ab. Inzwischen existiert auch Bedarf für Wideband-Codecs, die eine Samplingrate von 16 kHz verwenden und dadurch eine höhere Bandbreite von 50 Hz bis 7 kHz erfassen.

Samplingrate, Formanten

Quantisierung

1.9.1 Signalformcodierer Verbreitete Signalformcodierer im Bereich der Sprachkompression sind die ITU-Codecs G.711, G.722, G.726 und G.727. Mit Ausnahme des Wideband-Codecs G.722 verwenden diese Verfahren alle eine Samplingrate von 8 kHz. Die Codierungsverzögerung beträgt etwa 2 ms, die MOS-Werte liegen im Bereich von 3,8 bis 4,5. Tabelle 1.9 zeigt die Codecs und ihre Datenraten im Überblick. G.711 ist ein sehr einfacher Codec, der einen MOS-Wert von 4,5 erzielt, und häufig als Referenz für die qualitative Bewertung anderer Sprachcodecs herangezogen wird. Datenkompression entsteht bei G.711 ausschließlich durch Digitalisierung, die auf Pulse Code Modulation (PCM) basiert. Die Quantisierung erfolgt nichtlinear mit 8 Bit, was im Zusammenhang mit der Samplingrate von 8 kHz zur Datenrate von 64 kbit/s führt. Für die Quantisierung werden mit A-Law und P-Law zwei unterschiedliche Quantisierungskennlinien definiert, die Bezeichnung Codierungsart

Datenrate (kbit/s)

ITU G.711 ITU G.722

64 64 (56, 48)

ITU G.726 ITU G.727

Pulse Code Modulation (PCM) Subband Adaptive Differential PCM (SB-ADPCM) Adaptive Differential PCM (ADPCM) Embedded ADPCM (E-ADPCM)

G.711 (A-Law und P-Law)

Tabelle 1.9: Signalformcodierer für die Sprachkompression

40, 32, 24, 16 40, 32, 24, 16


■ ■ ■

71

G.726 (ADPCM)

G.727 (embedded ADPCM)

G.722 (SB-ADPCM)

72

■ ■ ■

beide logarithmisch arbeiten, so dass kleine Signalwerte feiner quantisiert werden und das Quantisierungsrauschen bei leisen Pegeln geringer ist. Während P-Law in Nordamerika und Japan eingesetzt wird, findet A-Law in weiten Teilen der restlichen Welt Verwendung. G.711 wird sehr vielseitig eingesetzt und eignet sich bspw. für die IPTelefonie und als Audio-Codec für die Kombination mit dem Videokonferenz-Codec H.261. G.726 löst seine Vorgänger-Empfehlung G.721 und deren Erweiterung G.723 ab, die inzwischen beide von der ITU zurückgezogen wurden. Das Verfahren erwartet wie fast alle Sprachcodecs G.711konforme PCM-Signale und codiert nur die Differenz des jeweiligen Signalwerts zu einem Prädiktionswert, welcher dabei rückwärtsadaptiv angepasst wird. Es handelt sich folglich um eine adaptive Prädiktion auf Basis von PCM-Werten, die auch als Adaptive Differential Pulse Code Modulation (ADPCM) bezeichnet wird. Die Quantisierung der Prädiktionsfehler erfolgt mit 2, 3, 4 oder 5 Bits, wodurch der Codec Bitraten von 16, 24, 32 oder 40 kbit/s erzielt – am gebräuchlichsten ist dabei die Quantisierung mit 4 Bits. G.726 ist unter anderem bei der DECT-Telefonie sowie der IP-Telefonie zu finden. Der Codec G.727, eine Erweiterung von G.726, verwendet eine Embedded ADPCM und quantisiert die Prädiktionsfehler ebenfalls mit 2, 3, 4 oder 5 Bits. Allerdings liegen die Quantisierungsstufen, auf die das Signal abgebildet wird, bei jeder Bitanzahl genau übereinander. So liegen die vier Stufen bei der Quantisierung mit 2 Bits genau auf 4 der 9 Stufen, die bei der Quantisierung mit 3 Bits verfügbar sind. Bei dieser als embedded bezeichneten Art der Quantisierung wird die gröbere Quantisierung durch sog. Core Bits repräsentiert, während sog. Enhancement Bits die feineren Quantisierungsinformationen enthalten. Enhancement Bits können folglich mit einer geringeren Priorität übertragen werden als Core Bits, da ihr Verlust nur eine Qualitätsminderung der Sprachdaten bedeutet. Auch lassen sich Enhancement Bits bei der Übertragung absichtlich verwerfen, um so einer Überlastung des Netzwerks entgegenzuwirken. Dazu spezifiziert die ITU das Packetized Voice Protocol, welches diese Funktionalität unterstützt [ITU90c]. Bits können an jeder Stelle der Übertragung verworfen werden, ohne dass Sender und Empfänger dies koordinieren müssen. Der ITU-Codec G.722 erwartet im Gegensatz zu den bisher betrachteten Signalformcodierern eine Samplingrate von 16 kHz und zählt daher zu den Wideband-Verfahren, die den Bereich von 50 bis 7000 Hz abdecken. Das Signal wird durch einen Quadrature Mirror Filter in zwei getrennte Bänder zerlegt, die Bandbreiten von je 4 kHz besitzen und mit dem Faktor 2 unterabgetastet sind. Die beiden Teilbänder werden jeweils durch eine ADPCM verarbeitet, wobei die Prädiktionsfehler im oberen Teilband mit 2 Bits quantisiert werden. Die Quantisierung im


unteren Band ist embedded und kann 4, 5 oder 6 Bits betragen, wodurch das Audiomaterial mit den Datenraten 48, 56 und 64 kbit/s codiert werden kann. Bei den ersten beiden Datenraten lassen sich 16 bzw. 8 kbit/s für Zusatzdaten nutzen, da der Codec stets eine Gesamtdatenrate von 64 kbit/s erzeugt. Obwohl G.722 bereits 1988 veröffentlicht wurde, besitzt er trotz geringer Komplexität gute Sprachqualität und wird z. B. mit dem Videokonferenz-Standard H.323 verwendet [Gib05].

1.9.2 Parametrische Codecs Parametrische Codecs basieren auf Modellen und zerlegen Audioinformationen in Signalkomponenten, die sich anhand von Modellparametern beschreiben lassen. Dabei wird die Annahme getroffen, dass Sprachsignale in sehr kurzen Intervallen stationär sind, und die meisten Modellparameter in diesen Intervallen konstant bleiben. Deshalb werden die Sprachsignale typischerweise in Frames von 10 bis 40 ms verarbeitet, die sich nicht überlappen. Ein Überblick zu gebräuchlichen Modellen und zur parametrischen Codierung findet sich bei [Pur99]. Sehr häufig wird ein Quelle-FilterModell herangezogen, wie es erstmals von [Fan60] vorgeschlagen wurde. Quelle-Filter-Modelle beschreiben die Spracherzeugung anhand eines Ton- bzw. Rauschgenerators und anhand eines Prädiktionsfilters. In Abb. 1.33 ist ein einfaches Quelle-Filter-Modell zu sehen. Der Tongenerator erzeugt ein periodisches Anregungssignal, wie es den stimmhaften Anteilen eines Sprachsignals zugrunde liegt. Analog erzeugt der Rauschgenerator ein rauschartiges Anregungssignal, welches die stimmlosen Komponenten repräsentiert. Zwischen beiden Generatoren wird durch einen Schalter hart gewechselt, das Modell sieht folglich keine gemischten Anregungssignale vor. Das Anregungssignal kann verstärkt werden, um lauten und leisen Signalanteilen Rechnung zu tragen, und wird durch das Filter geformt, welches die Funktion des Vokaltrakts übernimmt. Wird das dargestellte Quelle-Filter-Modell für die Sprachkompression verwendet, so müssen pro Frame nur die folgenden Modellparameter übertragen werden:

Quelle-Filter-Modell

Anregungssignal, Sprachparameter

Abb. 1.33: Modell der Spracherzeugung


■ ■ ■

73

x x x x

MELPe

stimmhaftes oder stimmloses Anregungssignal bei stimmhafter Anregung: Frequenz des Anregungssignals Signalenergie des Anregungssignals LPC-Filterkoeffizienten

Der Encoder ermittelt die LPC-Koeffizienten derart, dass sich das Sprachsignal im betrachteten Frame durch die Filterung möglichst genau an das Anregungssignal (Rauschen oder Impulsfolge) annähert. Im Gegensatz zur linearen Prädiktion, bei der ein Filter entwickelt wird, das zukünftige Samples vorhersagt, wird hier also ein Filter entwickelt, mit dem der Decoder das Anregungssignal formen und so das Sprachsignal erzeugen kann. Je mehr Prädiktorkoeffizienten ermittelt wurden, desto genauer wird sich das Signal synthetisieren lassen. In der Regel verwendet man 10 bis 20 Koeffizienten, wodurch man ausreichend verständliche Sprache erhält. Da nur wenige Parameter übertragen werden müssen, erzielen parametrische Kompressionsverfahren sehr geringe Datenraten im Bereich weniger kbit/s. Einschränkungen oder Vereinfachungen, die durch das Modell vorgenommen werden, haben jedoch Einfluss auf die Sprachqualität. So stellt z. B. die Reduktion auf nur zwei unterschiedliche Anregungssignale, die nicht in gemischter Form auftreten können, eine starke Vereinfachung der tatsächlichen Gegebenheiten der Sprachentstehung dar. Durch Hintergrundgeräusche kann ein Encoder darüber hinaus sehr leicht dazu gebracht werden, stimmhafte Signale fälschlicherweise als stimmlos zu identifizieren. Der militärisch verwendete Enhanced Mixed Excitation Linear Prediction Codec (MELPe), der im NATO Standardization Agreements STANAG 4591 beschrieben wird, verwendet ein gemischtes Anregungssignal, bei dem das rauschhafte Signal die hochfrequenten und das stimmhafte Signal die tieffrequenten Bereiche des Synthesefilters anregt. Der Codec unterstützt drei Bitraten von 600 bit/s, 1200 kbit/s und 2400 kbit/s. Sein MOS liegt etwa bei 3,2 und damit unter dem Grenzwert von 3,5, bis zu dem Sprache noch als natürlich eingestuft wird.

1.9.3 Hybride Codecs 3GPP

74

■ ■ ■

Neben Veröffentlichungen der ITU und MPEG-Gruppe sind unter den hybriden Codecs besonders die Sprachkompressionsstandards des 3GPP hervorzuheben, die im Mobilfunkbereich Einsatz finden. In Tabelle 1.10 werden verbreitete Hybrid-Codecs im Überblick dargestellt. Die Mehrzahl der aufgeführten Codecs des 3GPP (series 06) kommen bei GSM und seinen Erweiterungen GPRS und EDGE vor Release 4 zum


Einsatz. Verschiedene Releases werden vom 3GPP parallel geführt, um neuen Bedürfnissen des Markts schnell gerecht zu werden, Entwicklern aber dennoch stabile Zielplattformen anbieten zu können. Die Mehrzahl hybrider Codecs für die Sprachkompression basiert auf Code Excited Linear Prediction (CELP). Anhand Tabelle 1.10 ist zu erkennen, dass CELP in verschiedenen Variationen existiert. Das Funktionsprinzip der CELP-Codecs ähnelt parametrischen Verfahren, allerdings wird durch Vektorquantisierung die Verwendung eines genaueren Anregungssignals ermöglicht. Dazu sucht der Encoder aus einem Codebuch ein passendes Signal aus, und übermittelt dessen ID an den Decoder. Dieser verfügt über ein identisches Codebuch, und wählt anhand der ID eine gespeicherte Signalform, die als Anregungssignal für die Sprachsynthese des aktuellen Frames verwendet wird. Der ITU-Codec G.728 ist ein CELP-Codec mit sehr geringer Codierungsverzögerung. Dies wird u. A. durch Reduktion der Framelänge auf 20 Samples erreicht, so dass wenig Information gepuffert werden muss. Um trotzdem eine akzeptable Prädiktion zu erreichen, setzt man einen Prädiktor der Ordnung 50 ein. G.728 erzielt einen MOS von 3,9 und damit qualitativ gute Resultate. Beim Standard TS 06.20 des 3GPP [3GP00a] kommt Vector Sum Excitation Linear Prediction (VSELP) zum Einsatz. Dabei handelt es sich um eine CELP-Abwandlung, bei der das Anregungssignal eine gewichtete Summe von Einträgen verschiedener Codebücher ist. Bezeichnung

Codierungsart

Datenrate (kbit/s)

ITU G.722.1 ITU G.722.2

MDCT 32, 24 ACELP (AMR-WB) 23.85, 23.05, 19.85, 18.25, 15.85, 14.25, 12.65, 8.85, 6.60 (Adaptive Multirate) ITU G.723.1 ACELP/MP-MLQ 5.3/6.3 ITU G.728 LD-CELP 16 ITU G.729 CS-ACELP 8 (11.8/6.4) 3GPP TS 06.10 RPE-LTP (FR) 13 (Full Rate) 3GPP TS 06.20 VSELP (HR) 5.6 (Half Rate) 3GPP TS 06.60 ACELP (EFR) 13 (Enhanced Full Rate) 3GPP TS 06.90 ACELP (AMR) 12.2, 10.2, 7.95, 7.40, 6.70, 5.90, 5.15, 4.75 (Adaptive Multirate, AMR) 3GPP TS 26.190 ACELP (AMR-WB) 23.85, 23.05, 19.85, 18.25, 15.85, 14.25, 12.65, 8.85, 6.60 (Adaptive Multirate) 3GPP2 C.S0052-A ACELP (VMR-WB) Rate Set I: 8.55, 4.0, 2.0, 0.8; Rate Set II: 13.3, 6.2, 2.7, 1.0 (Variable Multirate) MPEG-4 CELP 3.85–23.8 MPEG-4 HVXC 4, 2


Code Excited Linear Prediction (CELP)

G.728 (LD-CELP)

TS 06.20 (VSELP)

Tabelle 1.10: Hybride Codecs für die Sprachkompression

■ ■ ■

75

G.723.1, G.729, TS 06.60 (ACELP)

TS 06.90 AMR-WB (ACELP)

G.723.1 (ACELP/MP-MLQ), TS 06.10 (RPE)

G.722.1 (MDCT)

76

■ ■ ■

Algebraic CELP-Varianten, die von den Codecs ITU G.723.1 und G.729, sowie bei TS 06.60 [3GP00b] verwendet werden, haben das Ziel, den Speicherplatz für das Codebuch zu verringern, indem Einträge nach einfachen algebraischen Regeln zusammengesetzt werden. Der ITU-Codec G.729 verwendet zusätzlich Vektorquantisierung für die Verstärkungs-Parameter der Codebucheinträge. Da das Verfahren nicht speziell auf geringe Codierungsverzögerung abzielt, ist es von geringerer Komplexität als G.728, erzielt mit einem MOS von 4,1 jedoch qualitativ vergleichbare Resultate. Der 3GPP-Standard TS 06.90 [3GP00c] definiert einen Adaptive Multirate (AMR) Codec, der es erlaubt, dynamisch zwischen verschiedenen Bitraten zu wechseln. Der Codec verwendet ACELP als Kompressionsverfahren, und verfügt über einen Voice Activity Detector, der Sprechpausen identifiziert. Für UMTS wurde mit 3GPP 26.190 [3GP05] eine Wideband-Variante spezifiziert, die Datenraten bis max. 23,85 kbit/s vorsieht. Die ITU führt denselben Codec als G.722.2 [ITU03a]. Unter der Bezeichnung Variable Rate Multimode Wideband (VMR-WB) wurde von 3GPP2 für cdma2000 ein Multirate-Codec [3G205] standardisiert, der auf demselben Kernalgorithmus wie AMRWB basiert, und einen Kompatibilitätsmodus für AMR-WB besitzt. Bei G.723.1 handelt es sich um einen Codec für zwei verschiedene Bitraten, bei dem die nichtperiodischen Komponenten des Anregungssignals auf zwei unterschiedliche Weisen erzeugt werden können. Durch ein Algebraic CELP-Verfahren wird so eine Bitrate von 5,3 kbit/s erreicht. Alternativ kann Multipulse Maximum Likelihood Quantization (MP-MLQ) gewählt werden, was in 6.3 kbit/s resultiert. Bei den Multipulse-Verfahren besteht das Anregungssignal aus einer beschränkten Anzahl von Pulsen, deren Amplituden und zeitliche Abstände in jedem Frame vom Encoder ermittelt und mit in den Datenstrom codiert werden. Es handelt sich hierbei also um einen Mittelweg zwischen rein parametrischen Verfahren mit regelmäßigem und daher sehr ungenauem Anregungssignal und CELP-Codecs, die das Anregungssignal exakter beschreiben. Eine weitere Möglichkeit ist es, das Anregungssignal durch eine Pulsfolge mit regelmäßigen Intervallen zu beschreiben, was als Regular Pulse Excitation (RPE) bezeichnet wird. Dabei müssen nur Pulsamplituden und die Position des ersten Pulses übertragen werden. Ein RPE-Verfahren kommt beim 3GPP-Codec TS 06.10 [3GP01] zusammen mit Langzeit-Prädiktion zum Einsatz. In ITU G.722.1 [ITU99] wird ein Wideband-Codec beschrieben, der eine Abtastrate von 16 kHz akzeptiert und somit eine Sprachbandbreite von 7 kHz abdeckt. Da das Verfahren auf einer Signaltransformation beruht, ist es mit gewissen Einschränkungen auch für andere Audiosignale als Sprache geeignet. Bei der Transformation handelt es sich


wie bei MP3 um eine MDCT, die auf überlappende Blöcke angewendet wird. Durch MPEG-4 wird neben einem CELP-Codec auch das Harmonic Vector Excitation Coding (HVXC) standardisiert, das ebenfalls auf linearer Prädiktion beruht. Es nutzt eine Abtastrate von 8 kHz und erzielt trotz geringer Bitraten von 2 oder 4 kbit/s eine gute Sprachqualität. Der HVXC-Codec ist sehr rechenintensiv und wird neben AAC und CELP u. A. beim Digital Radio Mondiale (DRM) eingesetzt, der Alternative zum Digital Audio Broadcast (DAB). Rein stimmlose Sprachanteile werden bei HVXC codebuchbasiert verarbeitet, wofür Einträge mit weißem Rauschen und Einträge mit verschiedenen Amplitudenverläufen existieren, wie bspw. von laut nach leise. Die Kombination dieser beiden Arten von Codebucheinträgen ermöglicht schon im Modus mit einer Bitrate von 2 kbit/s eine relativ genaue Rekonstruktion des stimmlosen Anregungssignals. Für den Modus mit 4 kbit/s wird eine zweite, identisch aufgebaute Codebuchkombination verwendet, um die Differenz zwischen dem ursprünglichen Anregungssignal und der Repräsentation des Modus mit 2 kbit/s zu codieren. Für Sprachanteile mit stimmhaften Beimengungen wird durch eine Fouriertransformation die spektrale Hülle ermittelt und durch Vektorquantisierung codiert. Zusammen mit der harmonischen Grundfrequenz dient sie dem Decoder dann als sehr exaktes stimmhaftes Anregungssignal. HVXC bietet die Möglichkeit, mit variabler Bitrate zu codieren. Hierbei wird im Falle stimmlos erkannter Sprachanteile nochmals eine zweite, genauere Erkennung durchgeführt, die Hintergrundgeräusche von tatsächlich stimmloser Sprache unterscheiden soll. Werden Hintergrundgeräusche erkannt, wird die Bitrate reduziert. Zur weiteren Funktionalität von HVXC zählt die Manipulation von Tonhöhe und Sprechgeschwindigkeit. Da stimmhafte Anteile des Sprachsignals durch Grundfrequenz und spektrale Hülle beschrieben werden, kann die Tonhöhe durch Veränderung der Grundfrequenz manipuliert werden, ohne die Sprachverständlichkeit zu beeinflussen. Für die Veränderung der Sprechgeschwindigkeit besitzt der Decoder die Möglichkeit, Sprachparameter zu interpolieren. Um Fehlerrobustheit zu erzielen, werden einzelne Frames bei allen Audio-Codecs des Standards MPEG-4 nach Wichtigkeit gruppiert und sortiert, was als Bitstream Reordering bezeichnet wird. Dies ermöglicht es, die Frames unterschiedlich gut mit Informationen für die Fehlererkennung und/oder Fehlerbehebung zu versehen.


MPEG-4 (HVXC)

stimmlose und stimmhafte Sprachanteile

variable Bitrate

Manipulation von Tonhöhe und Sprechgeschwindigkeit

Fehlerrobustheit

■ ■ ■

77

Literatur [3GP00a] 3GPP TS 06.20, V. 8.0.1: Half Rate Speech Transcoding. 3rd Generation Partnership Project, 2000. [3GP00b] 3GPP TS 06.60, V. 8.0.1: Enhanced Full Rate (EFR) Speech Transcoding. 3rd Generation Partnership Project, 2000. [3GP00c] 3GPP TS 06.90, V. 7.2.1: Adaptive Multi-Rate (AMR) Speech Transcoding. 3rd Generation Partnership Project, 2000. [3GP01] 3GPP TS 06.10, V. 8.2.0: Full Rate Speech Transcoding. 3rd Generation Partnership Project, 2001. [3GP05] 3GPP TS 26.190, V. 6.1.1: Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; Transcoding functions. 3rd Generation Partnership Project, 2005. [3G205] 3GPP2 C.S0052-A, V. 1.0: Source-Controlled Variable-Rate Multimode Wideband Speech Codec (VMR-WB). 3rd Generation Partnership Project, 2005. [ANR74] Ahmed, N. et al.: Discrete Cosine Transform. IEEE Transactions on Computers, 23(1):90–93, 1974. [Aro92] Arons, B.: A review of the cocktail party effect. Journal of the American Voice I/O Society, 12(1):35–50, 1992. [AtS67] Atal, B., Schroeder, M: Predictive coding of speech signals. Proceedings of the IEEE Conference on Speech Communication and Processing, pp. 360–361, 1967. [BDS05] Borer, T. et al.: Dirac Video Compression. BBC R&D Whitepaper WHP 124. British Broadcasting Corporation, 2005. [BrS94] Brandenburg, K., Stoll, G.: ISO-MPEG-1 Audio: A Generic Standard for Coding of High-Quality Digital Audio. Journal of the Audio Engineering Society, 42(10):780–792, 1994. [Bra99] Brandenburg, K.: MP3 and AAC explained. Proceedings of the AES 17th International Conference on High Quality Audio Coding, pp. 99–111, 1999. [ChP89] Choi, W., Park, R.-H.: Motion vector coding with conditional transmission. Signal Processing, 18(3):259–269, 1989. [Chu03] Chu, W.: Speech Coding Algorithms – Foundation and Evolution of Standardized Coders. Hoboken: Wiley 2003. [Dau88] Daubechies, I.: Orthonormal bases of compactly supported wavelets. Communications on Pure and Applied Mathematics, 41:909–996, 1988. [DCI05] DCI – Digital Cinema Initiatives: Digital Cinema System Specification, Vers. 1.0, 2005. [Dic97] Dickreiter, M.: Handbuch der Tonstudiotechnik – Band 1. Sechste, verbesserte Auflage. München: K.H. Saur 1997. [Die05] Diepold, K.: SMTPE VC-1 und MPEG-4 AVC im Vergleich. Digital Production, 4:88–91, 2005. [Fan60] Fant, G.: Acoustic Theory of Speech Production. Den Haag: Mouton 1960. [Gib05] Gibson, J.: Speech Coding Methods, Standards and Applications. IEEE Circuits and Systems, 5(4):30–49, 2005. [Gra98] Gray, R.: Entropy and Information Theory. Heidelberg: Springer 1998.

78

■ ■ ■


[GrM84] Grossmann, A., Morlet, J.: Decomposition of Hardy functions into square integrable wavelets of constant shape. SIAM Journal of Mathematical Analysis, 15(4):723–736, 1984. [Haa10] Haar, A.: Zur Theorie der orthogonalen Funktionensysteme. In: Mathematische Annalen, 69:331–371, 1910. [HaP96] Han, J., Polyzos, G.: Networking Applications of the Hierarchical Mode of the JPEG Standard. IEEE Proceedings of the International Phoenix Conference on Computers and Communications, pp. 58–64, 1996. [HeG00] Herre, J., Grill, B.; Overview of MPEG-4 audio and its applications in mobile communications. Proceedings of the 5th International Conference on Signal Processing, 1:11–20, 2000. [Huf52] Huffman, D.: A Method for the Construction of Minimum Redundancy Codes. Proceedings of the Institute of Radio Engineers (IRE), 40: 1098–1101, 1952. [ISO93a] ISO/IEC JTC 1/SC 29 11172: Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s. ISO/IEC Joint Technical Committee 1/Subcommittee 29, 1993. [ISO93b] ISO/IEC JTC 1/SC 29 11544: Coded representation of picture and audio information – Progressive bi-level image compression. ISO/IEC Joint Technical Committee 1/Subcommittee 29, 1993. [ISO94] ISO/IEC JTC 1/SC 29 10918: Digital compression and coding of continuous-tone still images. ISO/IEC Joint Technical Committee 1/Subcommittee 29, 1994. [ISO97] ISO/IEC JTC 1/SC 24 14772: The Virtual Reality Modeling Language. ISO/IEC Joint Technical Committee 1/Subcommittee 24, 1997. [ISO99] ISO/IEC JTC 1/SC 29 14495: Lossless and near-lossless compression of continuous-tone still images. ISO/IEC Joint Technical Committee 1/Subcommittee 29, 1999. [ISO00] ISO/IEC JTC 1/SC 29 13818: Generic coding of moving pictures and associated audio information. ISO/IEC Joint Technical Committee 1/Subcommittee 29, 2000. [ISO02] ISO/IEC JTC 1/SC 29 15938: Multimedia content description interface. ISO/IEC Joint Technical Committee 1/Subcommittee 29, 2002. [ISO04a] ISO/IEC JTC 1/SC 29 14496: Coding of audio-visual objects. ISO/IEC Joint Technical Committee 1/Subcommittee 29, 2004. [ISO04b] ISO/IEC JTC 1/SC 29 14496-4/FDAmd 9: AVC fidelity range extensions conformance. ISO/IEC Joint Technical Committee 1/Subcommittee 29, 2004. [ISO04c] ISO/IEC JTC 1/SC 29 15444: Information technology – JPEG 2000 image coding system. ISO/IEC Joint Technical Committee 1/Subcommittee 29, 2004. [ISO04d] ISO/IEC JTC 1/SC 29 21000: Multimedia framework (MPEG-21). ISO/IEC Joint Technical Committee 1/Subcommittee 29, 2004. [ITU88a] ITU-T Recommendation G.711: Pulse code modulation (PCM) of voice frequencies. ITU Telecommunication Standardization Sector, 1988. [ITU88b] ITU-T Recommendation G.722: 7 kHz audio-coding within 64 kbit/s. ITU Telecommunication Standardization Sector, 1988.

Literatur

■ ■ ■

79

[ITU90a] ITU-T Recommendation G.726: 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM). ITU Telecommunication Standardization Sector, 1990. [ITU90b] ITU-T Recommendation G.727: 5-, 4-, 3- and 2-bit/sample embedded adaptive differential pulse code modulation (ADPCM). ITU Telecommunication Standardization Sector, 1990. [ITU90c] ITU-T Recommendation G.764: Voice Packetization – Packetized Voice Protocol. ITU Telecommunication Standardization Sector, 1990. [ITU92a] ITU-T Recommendation G.728: Coding of speech at 16 kbit/s using lowdelay code excited linear prediction. ITU Telecommunication Standardization Sector, 1992. [ITU92b] ITU-T Recommendation T.81: Digital Compression and Coding of continuous-tone still images – Requirements and Guidelines. ITU Telecommunication Standardization Sector, 1992. [ITU93] ITU-T Recommendation H.261: Video codec for audiovisual services at p x 64 kbit/s. ITU Telecommunication Standardization Sector, 1993. [ITU95a] ITU-R Recommendation BT.601: Studio Encoding Parameters of Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect Rations. ITU Radiocommunication Standardization Sector, 1995. [ITU95b] ITU-T Recommendation H.262: Generic Coding of Moving Pictures and associated Audio: Video. ITU Telecommunication Standardization Sector, 1995. [ITU96a] ITU-T Recommendation G.114: General Characteristics of International Telephone Connections and International Telephone Circuits: One-Way Transmission Time. ITU Telecommunication Standardization Sector, 1996. [ITU96b] ITU-T Recommendation G.723.1: Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s. ITU Telecommunication Standardization Sector, 1996. [ITU96c] ITU-T Recommendation G.729: Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP). ITU Telecommunication Standardization Sector, 1996. [ITU96d] ITU-T Recommendation P.800: Methods of subjective determination of transmission quality. ITU Telecommunication Standardization Sector, 1996. [ITU98] ITU-T Recommendation T.87: Lossless and near-lossless compression of continuous-tone still images – Baseline. ITU Telecommunication Standardization Sector, 1998. [ITU99] ITU-T Recommendation G.722.1: Coding at 24 and 32 kbit/s for handsfree operation in systems with low frame loss. ITU Telecommunication Standardization Sector, 1999. [ITU03a] ITU-T Recommendation G.722.2: Wideband coding of speech at around 16 kbit/s using Adaptive Multi-Rate Wideband (AMR-WB). ITU Telecommunication Standardization Sector, 2003. [ITU03b] ITU-T Recommendation P.800.1: Mean Opinion Score (MOS) technology. ITU Telecommunication Standardization Sector, 2003. [ITU05a] ITU-T Recommendation H.263: Video coding for low bit rate communication. ITU Telecommunication Standardization Sector, 2005.

80

■ ■ ■


[ITU05b] ITU-T Recommendation H.264: Advanced video coding for generic audiovisual services. ITU Telecommunication Standardization Sector, 2005. [IMM95] Iwakami, N. et al.: High-Quality Audio-Coding at Less Than 64 kbit/s by Using Transform-Domain Weighted Interleave Vector Quantization (TWINVQ). Proceedings of the IEEE International Conference on Acoustics, Speech, and Signal Processing, 5:3095–3098, 1995. [KaK02] Kammeyer, K. und Kroschel, K.: Digitale Signalverarbeitung – Filterung und Spektralanalyse mit MATLAB-Übungen. Fünfte Auflage. Wiesbaden: Teubner 2002. [Kot33] Kotel’nikov, V.: On the transmission capacity of "ether" and wire in electrocommunications. Izd. Red. Upr. Svyazzi RKKA, 1933. [Lie03] Liebchen, T.: MPEG-4 Lossless Coding for High-Definition Audio. Audio Engineering Society (AES) Convention Paper 5872 – Preprint, 2003. [Lie04] Liebchen, T.: An Introduction to MPEG-4 Audio Lossless Coding. Proceedings of the IEEE International Conference on Acoustics, Speech, and Signal Processing, 3:1012–1015, 2004. [LMH05] Liebchen et al.: The MPEG-4 Audio Lossless Coding (ALS) Standard Technology and Applications. Audio Engineering Society (AES) Convention Paper 6589 – Preprint, 2005. [LBG80] Linde, Y. et al.: An Algorithm for Vector Quantizer Design. IEEE Transactions on Communications, 28(1):84–95, 1980. [Mal89] Mallat, S.: A Theory for Multiresolution Signal Decomposition: The Wavelet Representation. IEEE Transactions on Pattern Analysis and Machine Intelligence, 11(7):674–693, 1989. [NC302] NC3A Technical Note TN-881: Future NATO Narrow Band Voice Coder Selection. NATO Consultation, Command and Control Agency, 2002. [ODM96] OpenDML AVI M-JPEG File Format Subcommittee: OpenDML AVI File Format Extensions, Version 1.02, 1996. [Pan95] Pan, D.: A Tutorial on MPEG/Audio Compression. IEEE Multimedia Journal, 2(2):60–74, 1995. [PeK95] Pereira, F, Koenen, R.: Very low bitrate audiovisual applications. Signal Processing: Image Communication, 9(1):55–77, 1996. [Pur99] Purnhagen, H.: Advances in Parametric Audio Coding. Proceedings of the IEEE Workshop on Applications of Signal Processing to Audio and Acoustics, pp. 31–34, 1999. [RiL79] Rissanen, J., Langdon, G.: Arithmetic Coding. IBM Journal of Research and Development, 23(2):149–162, 1979. [RoZ72] Rocca, F., Zanoletti, S.: Bandwidth reduction via movement compensation on a model of the random video process. IEEE Transactions on Communications, 20(5):960–965, 1972. [SaP96] Said A., Pearlman, W.: A new, fast, and efficient image codec based on set partitioning in hierarchical trees. IEEE Transactions on Circuits and Systems for Video Technology, 6(3):243–249, 1996. [Shn48] Shannon, C.E.: A mathematical theory of communication. Bell System Technical Journal, 27:379–423; 623–656, 1948. [Shp93] Shapiro, J.: Embedded image coding using zerotrees of wavelet coefficients. IEEE Transactions on Signal Processing, 41(12):3445–3462, 1993.

Literatur

■ ■ ■

81

[SMP98] SMPTE 308M: SMPTE Standard for Television – MPEG-2 4:2:2 Profile at High Level. Society of Motion Picture and Television Engineers, 1998. [STL04] Sullivan, G. et al.: The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions. Proceedings of the International Society for Optical Engineering, 5558:53–74, 2004. [Tau00] Taubman, D.: High performance scalable image compression with EBCOT. IEEE Transactions on Image Processing, 9(7):1158–1170, 2000. [UnB03] Unser, M., Blu, T.: Mathematical Properties of the JPEG2000 Wavelet Filters. IEEE Transaction on Image Processing, 12(9):1080–1090, 2003. [Wal91] Wallace, G.: The JPEG still picture compression standard. Communications of the ACM, 34(4):32–44, 1991. [WNW94] Wang, S. et al.: Vector-quantization-based video codes for softwareonly playback on personal computers. Multimedia Systems, 2:191–203, 1994. [Wan84] Wang, Z.: Fast Algorithms for the Discrete W Transform and for the Discrete Fourier Transform. IEEE Transactions on Acoustics, Speech, and Signal Processing, 32:803–816, 1984. [Wei00] Weinberger, M.: The LOCO-I Lossless Image Compression Algorithm: Principles and Standardization into JPEG-LS. IEEE Transaction on Image Processing, 9(8):1309–1324, 2000. [Wie03] Wiegand, T.: Overview of the H.264/AVC Video Coding Standard. IEEE Transaction on Circuits and Systems for Video Technology, 13(7): 560–576, 2003. [XRO99] Xiong, Z. et al.: A Comparative Study of DCT- and Wavelet-Based Image Coding. IEEE Transactions on Circuits and Systems for Video Technology, 9(5):692–695, 1999. [YLR04] Yu, R. et al.: A Scalable Lossy to Lossless Audio Coder for MPEG-4 Lossless Audio Coding. Proceedings of the IEEE International Conference on Acoustics, Speech, and Signal Processing, 3:1004–1007, 2004. [ZwF99] Zwicker, E., Fastl, H.: Psychoacoustics: Facts and Models. Zweite, aktualisierte Auflage. Berlin u. Heidelberg: Springer 1999.

82

■ ■ ■


2 Mediensicherheit Roland Schmitz

Digitale Mediendaten können sehr einfach und ohne Einbußen an Informationsgehalt oder Qualität kopiert und weitergegeben werden. Diese Eigenschaften digitaler Medien stellen einen deutlichen qualitativen Unterschied zu Medien in analoger Form dar und bilden mittlerweile–zumindest nach Ansicht der Musik vertreibenden Industrie– ein ernsthaftes Hemmnis für einen profitablen Handel mit digitalen Inhalten. Ebenso einfach wie das Kopieren und die Weitergabe ist die Manipulation digitaler Inhalte, z. B. von Bildern, mit Hilfe geeigneter Bearbeitungsprogramme, ohne dass diese Manipulationen bemerkt oder nachgewiesen werden können. Dieses Kapitel zeigt technische Möglichkeiten auf, die mit dem Handel mit digitalen Medien verbundenen Problemkreise zu adressieren. Diese Möglichkeiten umfassen zum Einen so genannte Digitale Wasserzeichen, also Daten, die in nicht wahrnehmbarer Weise in die digitalen Medien eingebracht werden, und unter Anderem zum Urheberschutz dienen sollen, und zum Anderen so genannte Digital Rights Management (DRM)-Systeme, welche die Nutzung der Medien auf einen authorisierten Personenkreis mit wohl definierten Rechten einschränken. Beide Technologien ergänzen einander: Digitale Wasserzeichen können als der Teil eines DRM-Systems angesehen werden, der dann zum Einsatz kommt, wenn die Medien beim Kunden angekommen sind. Im Folgenden stellen wir die grundsätzlichen Prinzipien bei der technischen Realisierung solcher Systeme dar, während die ebenfalls hochinteressanten ökonomischen und rechtlichen Aspekte von DRMSystemen und digitalen Wasserzeichen nur kurz gestreift werden. Eine umfassendere Darstellung der Thematik „Mediensicherheit und DRMSysteme“ findet der interessierte Leser in [FK] und in [Bec].

2 Mediensicherheit

■ ■ ■

83

2.1 Einführung Wir beginnen mit den speziellen Sicherheitsanforderungen, die sich für digitale Medien stellen, und den Sicherheitsmechanismen, die für diese Anforderungen zur Verfügung stehen. Grundsätzlich stellen natürlich digitale Mediendaten nichts anderes als eine Abfolge von Bits dar, die zum Abspielen nur geeignet dekodiert werden muss, so dass sich die Anforderungen und Mechanismen im Prinzip nicht von denen für „normale“ Daten unterscheiden. Es gibt jedoch aufgrund der speziellen Struktur digitaler Medien einige Besonderheiten zu beachten, auf die wir im Folgenden eingehen.

2.1.1 Sicherheitsanforderungen für Digitale Medien 2.1.1.1 Vertraulichkeit Die Anforderung der Vertraulichkeit bedeutet für digitale Medien, dass diese nur für einen dazu authorisierten Personenkreis lesbar bzw. nutzbar sein sollten. Dabei ist zu beachten, dass der Kreis der authorisierten Nutzer eventuell sehr groß sein kann, wie es etwa beim Pay-TV der Fall ist. Zudem können die Datenmengen bei digitalen Medien sehr groß werden, was bei der Auswahl geeigneter Mechanismen zu beachten ist. 2.1.1.2 Integritätsschutz

Legitime Modifikationen der Mediendaten

84

■ ■ ■

Daten, die in digitaler Form über ein offenes Netz verschickt werden, können von jedem, der Zugriff auf das Netz hat, verändert werden. Es ist prinzipiell unmöglich, solche Veränderungen zu verhindern, wenn man nicht das Netz als solches vor physikalischem Zugriff schützen will. Ziel der Anforderung des Integritätsschutzes ist daher nicht, Veränderungen als solche zu verhindern, sondern diese für den legitimen Empfänger einer Nachricht erkennbar zu machen. Bei digitalen Medien stellt sich das zusätzliche Problem, dass gewisse Modifikationen an den Quelldaten wie Kompression, Umkodierung oder Reskalierung durchaus gewünscht sein können, und zumindest nicht als „Angriff“ eingestuft werden sollten. Mechanismen zum Integritätsschutz für digitale Medien müssen diese Problematik berücksichtigen.

2 Mediensicherheit

2.1.1.3 Nachweis des Datenursprungs In einem kommerziellen Umfeld, in dem digitale Inhalte verkauft und weiter gegeben werden, ist der Nachweis des Datenursprungs von besonderer Bedeutung. Kunden können somit sicher sein, dass die Inhalte, für die sie bezahlt haben, aus der richtigen Quelle stammen. Auf der anderen Seite erhalten die Urheber digitaler Inhalte bzw. Rechteinhaber die Möglichkeit, bei eventuellen Streitigkeiten ihr Urheberrecht nachzuweisen und entsprechende Ansprüche geltend zu machen. 2.1.1.4 Nachweis der Identität Eng verwandt mit dem Nachweis des Datenursprungs ist der Nachweis einer behaupteten Identität (meist als Authentifikation bezeichnet). Authentifikationsmechanismen spielen in allen Bereichen der Internet-Sicherheit und des E-Commerce eine große Rolle. Der Anwendungsfall des Verkaufs digitaler Medien unterscheidet sich nicht wesentlich vom Verkauf anderer Güter über das Internet: Die Identität von Kunden und Anbietern muss auf sichere Art und Weise verifiziert werden können, um dem Kunden die Sicherheit zu geben, seine sensitiven persönlichen Daten, wie zum Beispiel seine Kreditkartennummer, an die richtige Stelle zu übermitteln, und um den Bezahlvorgang einleiten zu können. Hat der Kunde bereits gezahlt, ist ebenfalls ein Authentifikationsvorgang notwendig, um sicher zu stellen, dass das Medien- bzw. Rechteobjekt (s. 2.3.1.2) an den richtigen Kunden geliefert wird.

2.1.2 Sicherheitsmechanismen 2.1.2.1 Verschlüsselungsalgorithmen Ein guter Verschlüsselungsalgorithmus transformiert die Inputdaten in einer Art und Weise, dass der Output keinerlei Rückschlüsse auf die Struktur der Inputdaten zulässt. Wie wir weiter unten noch sehen werden, lassen sich Verschlüsselungsalgorithmen bei richtiger Anwendung nicht nur für die Herstellung von Vertraulichkeit nutzen, sondern auch für andere Sicherheitsdienste wie zum Beispiel den Integritätsschutz. Zum Algorithmus selbst, dessen Spezifikation immer

2.1 Einführung

Algorithmus und Schlüssel

■ ■ ■

85

öffentlich zugänglich sein sollte, muss immer ein Geheimnis, der so genannte Schlüssel hinzukommen. Algorithmus und Schlüssel zusammen werden auf die zu schützenden Daten angewandt und bewirken den angestrebten Sicherheitsdienst, beispielsweise Vertraulichkeit der Daten. Man könnte auch sagen, dass der Schlüssel den Algorithmus parametrisiert. Die folgende Formel zeigt, wie Chiffretext C und Klartext M bei Verwendung des Schlüssels K und des Verschlüsselungsalgorithmus E voneinander abhängen:

C

Symmetrische Verschlüsselungsverfahren

EK ( M )

Die Begriffe „kryptografischer Algorithmus“ und „geheimer Schlüssel“ gehören also zusammen, sind aber dennoch deutlich voneinander zu unterscheiden. Je nachdem, ob Sender und Empfänger zum Ver- und Entschlüsseln der Daten den gleichen Schlüssel oder unterschiedliche Schlüssel verwenden, spricht man von symmetrischen oder asymmetrischen Verfahren. Bei symmetrischen Verfahren dient der gleiche Schlüssel K zum Ver- wie auch zum Entschlüsseln, es gilt also:

M

1

EK (C )

DK (C )

-1

Asymmetrische Verschlüsselungsverfahren

Dabei steht EK für die Umkehrfunktion der Verschlüsselungsfunktion, die bei symmetrischen Verfahren der Entschlüsselungsoperation DK entspricht. Bei asymmetrischen Verfahren besitzt jeder Teilnehmer ein eigenes Schlüsselpaar (PK, SK). Dabei dient der Public Key PK zum Verschlüsseln von Nachrichten für diesen Teilnehmer, der Secret Key (oder Private Key) SK dient zum Entschlüsseln. Im asymmetrischen Fall gilt also:

C

Hybride Verschlüsselungsverfahren

86

■ ■ ■

EPK Bob ( M ), M

DSK Bob (C ) ,

wobei Bob der Empfänger der verschlüsselten Nachricht sein soll. Der Public Key jedes Teilnehmers wird veröffentlicht, der Secret Key wird von jedem Teilnehmer geheim gehalten (und ist sonst niemandem bekannt). Für den Leser, der am inneren Aufbau symmetrischer und asymmetrischer Algorithmen und den mathematischen Prinzipien, die hinter ihrer Konstruktion stehen, interessiert ist, existieren mittlerweile eine ganze Reihe hervorragender Bücher: [MOV], [Schn], [Beu] sind nur einige Beispiele. Die beiden Klassen von Algorithmen ergänzen sich gegenseitig sehr gut: Während symmetrische Algorithmen gut geeignet sind, große Datenmengen schnell und effizient zu verschlüsseln, ist der Einsatz asymmetrischer Verfahren wesentlich aufwändiger. Sie lösen dafür jedoch ein Grundproblem, das mit dem Einsatz symmetrischen

2 Mediensicherheit

Verfahren zwangsläufig einhergeht, nämlich das des Schlüsseltauschs, also der Frage: Woher bekommen die Kommunikationspartner ihr gemeinsames Geheimnis K auf sichere Art und Weise? Verfügt man über ein asymmetrisches Verfahren, so ist dieses Problem prinzipiell gelöst: Einer der Partner (in der Literatur für gewöhnlich Alice genannt) veröffentlicht seinen öffentlichen Schlüssel, beispielsweise auf einem Webserver. Wer auch immer in der Folge mit Alice kommunizieren will, muss sich nur diesen öffentlichen Schlüssel besorgen, etwa ihn sich von einem Server herunterladen und kann in der Folge einen symmetrischen Schlüssel erzeugen, ihn mit dem Public Key von Alice verschlüsseln und an Alice schicken. Somit verfügen beide über ein gemeinsames Geheimnis und können in der Folge einen symmetrischen Algorithmus für ihre weitere Kommunikation verwenden. Verfahren, die auf diese Weise funktionieren, werden auch hybride Verfahren genannt. Allerdings muss bei der Nutzung asymmetrischer Verfahren dafür Sorge getragen werden, dass die Bindung zwischen öffentlichem Schlüssel und seinem Inhaber nicht verloren geht. Anderenfalls könnte ein Angreifer Alices Public Key durch seinen eigenen ersetzen und in der Folge die für Alice bestimmten Nachrichten lesen. Dieses Problem wird mit Hilfe so genannter Zertifikate (s. unten) gelöst. Die bisherigen Überlegungen zu Verschlüsselungs-Algorithmen sind für jede Art von digitalen Daten gültig, für digitale Mediendaten ergeben sich einige Zusatzaspekte: Üblicherweise erfordert ein Verbzw. Entschlüsselungsalgorithmus die korrekte und unveränderte Eingabe aller Inputbits. Werden aufgrund von Übertragungsfehlern, Umkodierungen, etc. einige Bits auf dem Transportweg verändert, ist keine korrekte Entschlüsselung mehr möglich. Obwohl moderne Verschlüsselungsalgorithmen sehr schnell sind, kann bei großen Datenmengen, wie sie zum Beispiel beim Streaming von Filmen auftreten, auch der Performanceverlust durch die Ver- und Entschlüsselung zum Problem werden. Um beide Probleme lösen zu können, sind in der Vergangenheit so genannte Partial Encryption Schemes ([Kun], [QN]) vorgeschlagen worden (andere Autoren wie [UP] sprechen auch von Selective Encryption). Hierbei werden nicht alle Mediendaten verschlüsselt, sondern nur für die Dekompression besonders relevante Teile wie Bewegungsvektoren, Header-Informationen oder DCT-Koeffizienten. Zur eigentlichen Verschlüsselung werden wohl bekannte Blockchiffen wie DES oder AES (siehe dazu [MOV] oder [Schn]) eingesetzt.

Partielle Verschlüsselung für Mediendaten

Beispiel 1: Verschlüsselung von MPEG-1-Videos nach [Kun] Im MPEG-1 Standard werden die Einzelframes ähnlich wie beim JPEG-Verfahren komprimiert, zusätzlich werden die Abhängigkeiten

2.1 Einführung

■ ■ ■

87

der Frames untereinander ausgenutzt (s. Kap. 1.7). Das Verfahren von Kunkelmann verschlüsselt nicht den gesamten MPEG-Strom, sondern nur die ersten n DCT-Koeffizienten jedes Frames (egal ob I-, B- oder P-Frame), wie sie durch die Encodierung nach JPEG entstehen. Durch geeignete Wahl des Parameters n kann zwischen dem gewünschten Grad der Vertraulichkeit und Performance abgewogen werden. Wie Experimente zeigen, führt ein Wert von n = 10 bereits zu einem relativ hohen Level an Vertraulichkeit, wobei aber nur 40% der gesamten Datenmenge tatsächlich verschlüsselt werden. Kompression und Verschlüsselung

Verschlüsselung von Videodaten im Pay-TV

Generell sollten zu verschlüsselnde Daten vor der Verschlüsselung komprimiert werden. Dies gilt in besonderem Maße für Videodaten, da durch die Kompression ebenfalls der Peformanceverlust durch die Verschlüsselung abgemildert wird. Ein anderer Weg zur Performanceverbesserung besteht im Einsatz so genannter Soft Encryption Systems. Damit sind einfache Verschlüsselungsalgorithmen mit abgeschwächten Sicherheitseigenschaften gemeint, die dafür aber gegenüber traditionellen Chiffren Schnelligkeitsvorteile bieten. Beispiel 2: VideoCrypt ([UP], S. 115) Das VideoCrypt System wurde in der Vergangenheit von britischen Pay-TV Sendern eingesetzt. Dabei werden die horizontalen Bildzeilen jeweils an einer geheim gehaltenen Stelle aufgetrennt und die beiden Halbzeilen miteinander vertauscht. Es handelt sich also um eine einfache Permutation der Bildinformationen, die für den Spezialisten mit relativ geringem Aufwand zu brechen ist. Trotzdem überwiegt in diesem Anwendungsfeld der Geschwindigkeitsvorteil, den diese einfache Permutationschiffre bietet. 2.1.2.2 Steganografie Im Umfeld der Mediensicherheit spielen auch Techniken der Steganografie eine gewisse Rolle. Die Steganografie hat ebenfalls die Vertraulichkeit von Informationen zum Ziel; allerdings werden hier nicht die Informationen selbst unkenntlich gemacht, sondern die bloße Existenz einer Nachricht soll geheim gehalten werden. Dies geschieht, indem man die zu übertragende Nachricht in „unsichtbarer“ Weise in eine Träger-Nachricht einbettet. Sollen Nachrichten in nicht-wahrnehmbarer Weise in Mediendaten eingebettet werden, müssen hierzu so genannte Wahrnehmungsmodelle heran gezogen werden, in denen die Wahrnehmung des menschlichen Auges bzw. Ohrs formal modelliert werden. Des Weiteren müssen die eingebetteten Nachrichten Umkodierungen und Kom-

88

■ ■ ■

2 Mediensicherheit

pressionen unbeschadet überstehen. Da auch Digitale Wasserzeichen nicht wahrnehmbar sein sollen, werden zum Einbetten von Digitalen Wasserzeichen normalerweise auch steganografische Verfahren angewandt. Man beachte jedoch, dass die bloße Existenz eines Digitalen Wasserzeichens in gewissen Mediendaten im Allgemeinen kein Geheimnis darstellt, sondern der Öffentlichkeit bekannt ist. Die Sicherheitsziele digitaler Wasserzeichen und steganografischer Verfahren unterscheiden sich also im Normalfall voneinander. Wie wir unten aber sehen werden, trägt die Geheimhaltung der Existenz eines Wasserzeichens auch wesentlich zu dessen Sicherheit bei. 2.1.2.3 Hashfunktionen und Message Authentication Codes Eine Hashfunktion ist eine Funktion H, die eine beliebig lange Nachricht M auf einen String fester Länge abbildet. Für unsere Zwecke ist diese einfache Definition jedoch nicht ausreichend. Da wir Hashfunktionen unter anderem zum Integritätsschutz verwenden wollen, benötigen wir solche Hashfunktionen, die einen „repräsentativen Fingerabdruck“ der Nachricht M liefern. Das bedeutet insbesondere, dass sich bei jeder zufälligen oder auch absichtlichen Änderung von M auch der Hashwert von M ändern sollte. Diese Forderung ist natürlich nicht vollständig einzuhalten. Da der Hashwert im Normalfall eine geringere Bitlänge besitzt als der Input, ist die Existenz verschiedener Dokumente mit gleichem Hashwert unausweichlich (so genannte Kollisionen). Wir fordern jedoch, dass es für einen Angreifer schwierig sein soll, solche Kollisionen bewusst zu erzeugen (so genannte Kollisionsresistenz). Aus Gründen, die gleich noch klar werden, fordern wir des Weiteren, dass es ebenso schwierig sein soll, aus dem Hashwert H(M) einer Nachricht M auf die Nachricht M selbst zu schließen (so genannte One-Way-Eigenschaft). Kollisionsresistente Hashfunktionen, die die One-Way-Eigenschaft besitzen, nennt man kryptografische Hashfunktionen. Die Anwendung einer kryptografischen Hashfunktion allein bewirkt jedoch noch keinen Integritätsschutz. Ein Angreifer könnte die Nachricht in der gewünschten Weise abändern und im Anschluss die Hashfunktion auf die veränderte Nachricht anwenden. Deshalb muss zusätzlich noch ein geheimer Schlüssel ins Spiel kommen: Ein Message Authentication Code (MAC) zu einer Nachricht M ist ein Datensatz, der mit Hilfe einer kryptografischen Hashfunktion H und eines (symmetrischen) Schlüssels K gebildet wird und an M angehängt wird. Üblicherweise wird zur Bildung des MAC zunächst die Nachricht M mit Hilfe von K modifiziert und dann die Hashfunktion auf das Resultat angewendet.

2.1 Einführung

■ ■ ■

89

Kennt der Empfänger von M den geheimen Schlüssel K, so kann er selbst einen MAC über die empfangene Nachricht bilden und mit dem erhaltenen MAC vergleichen. Stimmen beide überein, so ist für den Empfänger klar, dass: x die Nachricht M auf dem Transportweg nicht verändert wurde, und x die Nachricht von jemandem stammt, der den Schlüssel K kennt. Somit lassen sich mit Hilfe von MACs die Anforderungen des Integritätsschutzes und der Verifikation des Datenursprungs erfüllen. Wir gehen an dieser Stelle nicht auf die verschiedenen Möglichkeiten, einen MAC zu bilden, ein und verweisen den Leser hierzu (und auch zu weiteren Details über Hashfunktionen) wiederum auf die im Abschnitt zu Verschlüsselungsalgorithmen angeführte Literatur. Die Anwendung von MACs auf digitale Medien stößt auf das gleiche Problem, wie bereits auch das Verschlüsseln von Mediendaten: Es kann nicht garantiert werden, dass die Mediendaten Bit für Bit so beim Empfänger ankommen, wie sie produziert wurden. Im Kontext digitaler Medien ist aber zumeist gar kein bitgenauer Integritätsschutz gefordert, sondern nur ein inhaltsbasierter Integritätsschutz, der nur auf solche Änderungen reagiert, die den Inhalt der gesendeten Mediendaten betreffen, nicht aber auf solche, die nur das Format betreffen. Es liegt deshalb nahe, die MAC–Bildung nur auf solche Daten zu beziehen, die die Semantik der Mediendaten beschreiben. Verfahren hierzu für digitale Bilder nutzen die DCT-Koeffizienten [CMB] für die höchsten Frequenzen oder gewisse Metadaten, die die Ränder wesentlicher Bildkomponenten beschreiben (vgl. [Ditt]). Ein weiteres Problem besteht in der Tatsache, dass die gängigen Formate für digitale Medien keine Datenfelder für MACInformationen beinhalten. Somit müssen für den Transport der MACDaten zusammen mit den Mediendaten neue Formate geschaffen werden oder aber die MAC-Daten in die Mediendaten selbst eingebettet werden.

Message Authentication Codes dienen zum Integritätsschutz

2.1.2.4 Digitale Signaturen Die eben behandelten MACs beruhen auf symmetrischen Schlüsseln. Verwendet man stattdessen asymmetrische Verfahren, ergibt sich aufgrund der Tatsache, dass hier der Secret Key immer nur einer einzigen Person bekannt ist, ein weiterer interessanter Aspekt: Durch das Verschlüsseln eines Dokuments M mit ihrem Secret Key erzeugt Alice einen Bitstring, den nur sie allein erzeugen kann und der in untrennbarer Weise von dem signierten Dokument abhängig ist. Der mit einem symmetrischen Verfahren gebildete MAC über ein Dokument besitzt

90

■ ■ ■

2 Mediensicherheit

zwar vergleichbare Eigenschaften, hat aber den Nachteil, dass er immer von mindestens zwei Personen erzeugt werden kann, nämlich all denen, die den symmetrischen Schlüssel K kennen. Im Gegensatz dazu kann eine Digitale Signatur immer nur von einer einzigen Person erzeugt werden (sie ist damit nicht abstreitbar) und stellt somit ein digitales Analogon zu einer handschriftlichen Signatur dar. Bei Erhalt eines von Alice digital signierten Dokuments M kann Bob verifizieren, ob die Signatur tatsächlich von Alice stammt und ob M auf dem Weg zu ihm verändert worden ist, indem er auf die Signatur Alices Public Key anwendet und die Verschlüsselung somit wieder rückgängig macht. Digitale Signaturen eignen sich somit ebenfalls hervorragend zum Nachweis des Datenursprungs, zur Authentifikation und zum Integritätsschutz von Nachrichten. Üblicherweise wird bei einer digitalen Signatur aus Effizienzgründen nicht das gesamte Dokument mit dem Private Key des Signierers verschlüsselt, sondern nur ein repräsentativer Fingerabdruck des zu signierenden Dokuments, der mit Hilfe einer kryptografischen Hashfunktion erstellt wird. Zusammengefasst nimmt die Signatur von Alice unter dem Dokument M also folgende Form an:

sig Alice ( M )

Digitale Signaturen sind nicht abstreitbar.

ESK Alice ( H ( M ))

wobei H für eine kryptografische Hashfunktion steht. Für die Anwendung digitaler Signaturen auf digitale Mediendaten gelten die gleichen Anmerkungen wie schon bei den MACs. Für die Beantwortung der Frage, ob zur Verifikation des Datenursprungs eher symmetrische MACs oder asymmetrische digitale Signaturen verwendet werden sollten, spielen funktionale Aspekte (wird die Nichtabstreitbarkeit tatsächlich benötigt?) und Performanceaspekte (die Erstellung digitaler Signaturen und das damit verbundene Schlüsselmanagement ist deutlich aufwändiger als bei MACs) eine Rolle. 2.1.2.5 Zertifikate Eine digitale Signatur kann von jedem verifiziert werden, der den dazu gehörigen Public Key kennt. Sie bestätigt unter anderem, dass das unterschriebene Dokument vom Signierer stammt und nicht verändert worden ist. Aufgrund dieser Eigenschaften werden digitale Signaturen auch zur Lösung des oben angesprochenen Problems der Bindung eines öffentlichen Schlüssels an eine bestimmte Identität eingesetzt: Alice kann sich mit ihrem Public Key an eine vertrauenswürdige Stelle (Trusted Third Party, TTP) wenden und ihre Identität zusammen dem Public Key durch die TTP digital signieren lassen. Somit entsteht ein Dokument, das die Bindung eines bestimmten Pub-

2.1 Einführung

■ ■ ■

91

lic Key an eine Identität durch eine vertrauenswürdige Stelle bestätigt und dessen Echtheit von jedem verifizierbar ist. Ein solches Dokument wird als Zertifikat bezeichnet. Das Management öffentlicher Schlüssel mit Hilfe von Zertifikaten durch eine TTP (in diesem Zusammenhang auch als Certification Authority, CA bezeichnet) ist immer mit einem gewissen Aufwand verbunden: Die Teilnehmer müssen registriert und ihre Identität verifiziert werden. Die Zertifikate müssen für die Öffentlichkeit über einfache Suchschnittstellen verfügbar gemacht werden und zur späteren Verifikation von digitalen Signaturen über lange Zeiträume archiviert werden. Schließlich muss es auch die Möglichkeit geben, Zertifikate zurück zu ziehen bzw. zu sperren, zum Beispiel beim Verlust eines privaten Schlüssels oder bei Erlöschen einer Firma. Auch die Information hierüber muss allen Teilnehmern des Systems auf sichere Weise zugänglich gemacht werden. Dies geschieht entweder über von der CA digital signierte Listen (so genannte Certificate Revocation Lists, CRL) oder über ein speziell zu diesem Zweck entworfenes Protokoll (Online Certificate Status Protocol, OCSP). Die gesamte zum Management öffentlicher Schlüssel benötigte Infrastruktur wird auch als Public Key Infrastructure (PKI) bezeichnet. 2.1.2.6 Digitale Wasserzeichen In digitalen Wasserzeichen kommen viele der oben diskutierten Sicherheitsmechanismen zusammen. Wir haben bereits angesprochen, dass für MACs oder Digitale Signaturen in den gängigen Medienformaten keine Datenfelder vorgesehen sind. Durch Einbettungstechniken, wie sie bei Digitalen Wasserzeichen eingesetzt werden, können diese Daten aber direkt in die Mediendaten eingebracht werden. Je nach Einsatzzweck des Wasserzeichens können auch weitere Daten eingebracht werden, entweder in verschlüsselter Form oder im Klartext. Im folgenden Abschnitt werden wir uns deshalb den Anwendungsbereichen und Einbettungstechniken für Digitale Wasserzeichen genauer widmen.

2.2 Digitale Wasserzeichen Hält man einen 20 € Schein gegen das Licht, so erkennt man links auf der unbedruckten Fläche eine verkleinerte, vereinfachte Version der auf dem Schein abgebildeten gotischen Kirchenfenster und darunter die Zahl 20. Dieses Wasserzeichen wird während des Produktionspro-

92

■ ■ ■

2 Mediensicherheit

zesses in das Papier des Scheins eingebracht und soll die Echtheit des Scheins garantieren sowie eine Fälschung, etwa durch einfaches Kopieren, unmöglich machen. Bereits seit dem 13. Jahrhundert kennzeichnen Papiermühlen ihre Erzeugnisse mit Wasserzeichen, um dadurch Herkunft und Qualität des Papiers zu dokumentieren. Etwas Ähnliches wird durch digitale Wasserzeichen versucht: Hier werden Daten in digitaler Form nach der Produktion in die Medien eingebracht, normalerweise allerdings im Gegensatz zu papierbasierten Wasserzeichen in nicht wahrnehmbarer Weise. Ihr Vorhandensein kann nur mit Hilfe geeigneter Software und Kenntnis eines geheimen Schlüssels geprüft werden und soll sicherstellen, dass die Mediendaten aus einer bestimmten Quelle stammen und nicht verändert worden sind. Zur Illustration sehen wir in Abb. 2.1 ein Original1 bild, daneben das mit einem Wasserzeichen markierte Original , und ganz rechts das Differenzbild von Original und markiertem Bild.

Abb. 2.1: Original, markiertes Original und Differenzbild

2.2.1 Anwendungsgebiete für Digitale Wasserzeichen 2.2.1.1 Identifikation des Datenursprungs Nehmen wir an, die Nachwuchsband Newcomers bietet einige ihrer Songs kostenlos zum Download im Internet an. Um ihren Bekanntheitsgrad und Wiedererkennungswert zu erhöhen, bettet die Band zusätzliche Informationen über sich im Klartext über ein Digitales Wasserzeichens in die Audiodaten ein. Insbesondere wird auch ein Link auf die Webseite der Band eingebettet. Unterstützt die zum Abspielen der Songs genutzte Software das Erkennen von Wasserzeichen, können dem Nutzer automatisch die eingebetteten Informationen 1

Das Original wurde mit einem derzeit von Herrn Hujian Liu am Fraunhofer Institut für Integrierte Publikationssysteme (IPSI) entwickelten Algorithmus markiert. Der Autor dankt Herrn Liu herzlich für seine Unterstützung.

2.2 Digitale Wasserzeichen

■ ■ ■

93

über die Band angezeigt werden und auf Wunsch die Webseite angezeigt werden. In diesem Anwendungsszenario profitieren also beide Seiten, Urheber und Konsumenten, von der Einbettung gewisser Metadaten über ein Wasserzeichen. Voraussetzung dafür ist eine weite Verbreitung von Abspiel-Software bzw. –Geräten, die die eingebetteten Wasserzeichen detektieren können. 2.2.1.2 Nachweis des Datenursprungs Robuste Wasserzeichen

Eine gänzlich andere Problemstellung ergibt sich, wenn wir auf die Urheberschaft in digitalen Medien nicht nur hinweisen, sondern diese tatsächlich auch nachweisen wollen. Ein solches Wasserzeichen darf sich weder von Unbefugten erzeugen, noch durch Manipulationen des Originals wie etwa Konvertierung der markierten Datei in andere Audio- oder Bildformate, Kompression etc. entfernen lassen. Man nennt solche Wasserzeichen robust. Als einzubettende Daten für den Nachweis des Copyrights bietet sich etwa eine Notiz in der Form „© by Alice, 1/2006“ an, zusammen mit einem Hashwert der Originaldaten zum Nachweis, das Alice das Original tatsächlich zur Verfügung steht. Diese Daten sollten vor dem Einbringen verschlüsselt werden, um einem Angreifer, der das Wasserzeichen entfernen möchte, keinerlei Informationen über die in dem markierten Medium zu suchenden Daten zu geben. 2.2.1.3 Kopierschutz Die Band Established bietet auf ihrer Webseite kostenpflichtige Songs zum Download an. Wie kann verhindert werden, dass ein User, der einmal für einen Song bezahlt hat, diesen nun auf eigene Rechnung kopiert und weiter verkauft? Eine nahe liegende Lösung besteht im Einbringen eines Wasserzeichens in die Audiodaten mit der Nachricht „Do Not Copy“. Entdeckt ein Kopiergerät dieses Wasserzeichen, könnte es sich weigern, den Kopiervorgang auszuführen. Dieses Vorgehen hat jedoch den Nachteil, dass man sämtliche Kopiergeräte mit entsprechenden Detektoren ausstatten müsste, die aber faktisch die Funktionalität der Geräte einschränken. Somit besteht kein großer Anreiz für die Hersteller von Kopiergeräten, solche Detektoren in ihre Geräte einzubauen. Anders verhält es sich natürlich, wenn die Mediendaten vom Rechteinhaber in einem speziellen Format ausgeliefert werden, das nur von speziellen, ebenfalls vom Rechteinhaber hergestellten Geräten bzw. Software interpretiert werden kann. In diesem

94

■ ■ ■

2 Mediensicherheit

Fall bleibt die Frage, ob solche erzwungenen Kopplungen von Mediendaten an spezielle Abspielgeräte vom Verbraucher angenommen werden. 2.2.1.4 Transaction Tracking Lässt sich das unbefugte Kopieren von Mediendaten nicht verhindern, so kann zumindest versucht werden, denjenigen, der eine illegale Kopie erstellt hat, ausfindig zu machen. Dies geschieht mittels Transaction Tracking Watermarks, bei denen für jeden User, der legal eine Kopie des Originals erwirbt, ein individuelles Wasserzeichen eingebracht wird, um so bei Auftauchen einer illegalen Kopie den Schuldigen identifizieren zu können. Beispiele für Wasserzeichen dieses Typs findet man bei [BS] und [DBS]. 2.2.1.5 Integritätsschutz Durch das Einbetten eines MAC oder einer digitalen Signatur, welche über die originalen Mediendaten gebildet werden, lässt sich ein Integritätsschutz erzielen, der jedes einzelne Bit der Quelldaten mit einbezieht. Wie bereits erwähnt, ist dieser bitgenaue Schutz in den meisten Fällen nicht erwünscht. Es gibt jedoch hochsensible Bereiche, in denen gerade die Bitgenauigkeit des Integritätsschutzes gefragt ist. Man betrachte zum Beispiel den Fall einer Ärztin, die ein von ihr erstelltes computertomographisches Bild per E-Mail an einen Kollegen schickt und auch kleinste Bitfehler bei der Übertragung ausschließen möchte. Sie hat nun die Möglichkeit, zunächst eine digitale Signatur über die Quelldaten zu erstellen und diese mittels eines robusten Wasserzeichens einzubetten. Der empfangende Arzt kann auch bei Änderungen auf dem Transport das Wasserzeichen und mit ihm die Signatur zwar extrahieren, die Verifikation der Signatur wird jedoch aufgrund der Änderungen in den Quelldaten scheitern. Diese Variante besitzt zusätzlich die Eigenschaft der Verifikation des Datenursprungs. Möchte man keine digitale Signatur verwenden, besteht eine weitere Möglichkeit in der Nutzung eines nicht robusten, so genannten fragilen Wasserzeichens. Solche Wasserzeichen sollen auch nach kleinsten Änderungen in den Quelldaten nicht mehr detektierbar sein. In diesem Fall ist also das Fehlen des Wasserzeichens ein Hinweis auf unerwünschte Änderungen.


Fragile Wasserzeichen

■ ■ ■

95

2.2.1.6 Inhaltsbezogener Integritätsschutz

Inhaltsfragile Wasserzeichen

Ein inhaltsbezogener Integritätsschutz, der zwar inhaltsrelevante Änderungen wie das Wegretuschieren einer Person in einem Bild an den Mediendaten kenntlich macht, nicht aber auf Umformatierung, Kompression etc. reagiert, lässt sich ebenfalls auf verschiedene Weisen durch digitale Wasserzeichen realisieren. Eine bereits angedeutete Möglichkeit besteht in einem MAC oder einer digitalen Signatur, die über Metadaten, die den Inhalt der Mediendaten beschreiben, jedoch nicht über die Mediendaten selbst gebildet werden (so genannte inhaltsbasierte Signatur). Dieser MAC bzw. diese Signatur wird dann durch ein robustes Verfahren (s. 2.2.2.4) so als Wasserzeichen eingebettet, dass es die erwähnten Transformationen unbeschadet übersteht. Die Signatur kann jedoch nur bei nicht inhaltlich relevanten Änderungen verifiziert werden, anderenfalls schlägt die Verifikation fehl. Ein Beispiel für diese Vorgehensweise findet man in [Dit]. Hier werden aus Bildern die Kanten der abgebildeten Gegenstände extrahiert und in einen Merkmalsvektor umgesetzt, der dann digital signiert wird. Allerdings haben die auf MACs bzw. digitalen Signaturen basierenden Verfahren den Nachteil, dass sie nur das Vorhandensein einer inhaltlichen Modifikation anzeigen können, nicht jedoch, wo diese stattgefunden hat. Eine andere Möglichkeit besteht in so genannten inhaltsfragilen (oder auch semifragilen) Wasserzeichen. Diese können nur dann detektiert werden, falls keine inhaltsrelevanten Transformationen mit den Daten durchgeführt werden, anderenfalls werden sie zerstört. Neuere Verfahren wie in [Fri] oder [DTS] können dabei auch den Ort einer Manipulation kenntlich machen (s. Abb. 2.2)

Abb. 2.2: Detektion einer Bildmodifikation mittels eines digitalen Wasserzeichens (Abbildung entnommen aus [TZFS])

2.2.1.7 Einbringen von Metainformationen Metainformationen wie Bild- bzw. Szenenbeschreibungen oder handelnde Personen lassen sich in Form eines Wasserzeichens in Bildoder Videodaten einbetten. Diese Metainformationen können dazu

96

■ ■ ■

2 Mediensicherheit

genutzt werden, zum Beispiel in einer großen Bilddatenbank effizient nach dem gewünschten Inhalt zu suchen.

2.2.2 Einbettungstechniken 2.2.2.1 Kommunikationstheoretisches Basismodell Wir beginnen mit einem möglichst allgemeinen Modell des Einbettungsprozesses und klären dabei einige wesentliche Begrifflichkeiten. Wir möchten also in unser Medium einen gewissen Bitstring m einbetten. Dieser Bitstring m kann eine Nachricht im Klartext repräsentieren („Do Not Copy“), ein MAC, eine Digitale Signatur oder eine verschlüsselte Nachricht sein. Die originalen Mediendaten werden als Cover Work C0 bezeichnet. Um m in das Cover Work einbetten zu können, muss m zunächst auf dasselbe Format wie das Cover Work gebracht werden. Das ist unter anderem die Aufgabe des Watermark Encoders. Wollen wir m also in ein Einzelbild einbetten, steht am Ende des Encodierungsprozesses ein zweidimensionales Muster von Pixeln mit den gleichen Ausmaßen wie das Cover Work. Das Resultat des Encodierungsprozesses ist das Added Pattern wa. Meist nutzt der Watermark Encoder für den Codierungsprozess eine Geheiminformation, den Watermark Key wk. Der Watermark Key ist nicht zu verwechseln mit einem eventuell zur Erzeugung des einzubettenden Bitstrings m verwendeten Cipher Key K. Das Encodieren ist der entscheidende Teil des gesamten Einbettungsprozesses. Die Nutzung des Watermark Keys soll unbefugtes Auslesen und/oder Entfernen des Wasserzeichens verhindern. Des Weiteren entscheiden die Art der Encodierung und ein Parameter D, der die Stärke des einzubringenden Wasserzeichens angibt, über die Robustheit des Wasserzeichens. Bei der Wahl des Stärkeparameters ist zwischen einer möglichen Verschlechterung der Medienqualität durch das Einbringen eines stärkeren Wasserzeichens und einer höheren Robustheit des Wasserzeichens abzuwägen. Mögliche Alternativen bei der Codierung sind die Nutzung eines Fehler korrigierenden Codes, um gegen Übertragungsfehler besser geschützt zu sein, oder – im Fall eines Video-Wasserzeichens – eine über die Laufzeit des Videos verteilte Wiederholung des ursprünglichen Bitstrings m. Das eigentliche Einbetten des Added Pattern in das Cover Work besteht in einer vergleichsweise simplen Operation. Im Fall eines Wasserzeichens für Einzelbilder werden die Farbintensitäten für die drei Farbkanäle Blau, Gelb und Rot der einzelnen Pixel von Cover Work


■ ■ ■

97

Abb. 2.3: Modell des Einbettungsprozesses nach [CMB]

und Added Pattern addiert. Für Audiodaten können beispielsweise die Signalintensitäten von Cover Work und Added Pattern addiert werden. Nach dem Einbetten des Added Pattern wird aus dem Cover Work C0 das Watermarked Work CW : CW = C0 + wa. Abbildung 2.3 zeigt den gesamten Einbettungsprozess noch einmal in der Übersicht. Beim Transport des markierten Cover Work CW zu den Nutzern der Mediendaten kann es zu Übertragungsfehlern und Umkodierungen kommen. Auch böswillige Versuche eines Angreifers, das Wasserzeichen zu entfernen, kann man durch Übertragungsfehler, genauer gesagt durch die Addition von Störungen N zu CW modellieren. Dadurch kommt beim Empfänger ein modifiziertes markiertes Original CWN an: CWN = CW + N Möchte man nach dem Transport feststellen, ob ein Wasserzeichen vorhanden ist oder nicht, nutzt man einen so genannten Detektor, der im Wesentlichen die beim Einbetten des Wasserzeichens ausgeführten Schritte wieder rückgängig macht. Je nachdem, ob dem Detektor das ungekennzeichnete Original C0 zur Verfügung steht oder nicht, spricht man von einem informierten bzw. blinden Detektor. Wurde zum Einbetten des Wasserzeichens ein Watermark Key verwendet, muss auch der Detektor über den Watermark Key verfügen. Abbildung 2.4 zeigt einen blinden Detektor. Man beachte, dass der Output mN nicht notwendigerweise mit dem ursprünglichen Input m übereinstimmen muss. Im Gegensatz zum Szenario bei Nutzung eines blinden Detektors wird bei einem informierten Detektor zunächst das Cover Work C0 von dem empfangenen CWN subtrahiert. Als Ergebnis erhält der Detektor

98

■ ■ ■

2 Mediensicherheit

Abb. 2.4: Blinder Detektor

also ein eventuell gestörtes Added Pattern wa + N. Aufgrund der Tatsache, dass der Detektor bei einem informierten Verfahren das Original immer mit sich führen muss, sind die Einsatzmöglichkeiten informierter Verfahren aber eher begrenzt. 2.2.2.2 Einfache Beispiele Zur Illustration des obigen Modells betrachten wir drei einfache Beispiele, davon zwei für Einzelbilder, das andere für Audiodaten. Beispiel 3 (s. [CMB], System 1) In diesem einfachen Beispiel wird ein einziges Bit b in ein Schwarzweiß-Bild eingebettet. Dazu wird zunächst mit Hilfe des Watermark Key und eines Pseudozufallsgenerators ein Referenzbild wr mit denselben Ausmaßen wie das Cover Work C0 erzeugt. Das Added Pattern wa ergibt sich dann aus:

wa

D wr falls b ® ¯D wr falls b

1 0

Zum Einbetten werden die Grauwerte des Added Pattern und des Cover Work pixelweise addiert. Berücksichtigt man weitere Störungen S auf dem Transportweg, kommt beim Empfänger also das gestörte Bild C = C0 + wa + S an. Um in C das eingebettete Referenzbild „blind“, das heißt ohne Kenntnis des Cover Work detektieren zu können, bildet der Detektor die lineare Korrelation von C und dem Referenzbild wr:

LC (C , wr )

1 C wr N

1 N

¦ C (i, j )w (i, j ) r

i, j


■ ■ ■

99

Dabei stehen N für die Gesamtzahl der Pixel und C(i,j) bzw. wr(i,j) für die Grauwerte der Pixel an der Position (i,j). Fasst man C und wr als N-dimensionale Vektoren mit den Grauwerten der Pixel als Komponenten auf, so bezeichnet die lineare Korrelation von C und wr das Skalarprodukt der beiden Vektoren, dividiert durch N. Wegen C = C0 + wa + S gilt somit:

LC (C , wr )

1 (C0 wr wa wr S wr ) N

Geht man davon aus, dass die Grauwerte sowohl von C0 als auch von wr und S einer Gauß-Verteilung folgen, so sind die Größen C0¸wr und S¸wr mit hoher Wahrscheinlichkeit betragsmäßig sehr klein. Die lineare Korrelation wird also dominiert durch den Anteil:

1 wa wr N

rD wr wr

2

rD ¦ wr (i, j ) . i, j

Liegt also der Wert für die lineare Korrelation von C und wr über einem bestimmten positiven Schwellwert U, so kann man mit hoher Wahrscheinlichkeit davon ausgehen, dass b = 1 eingebettet wurde, ist sie kleiner als -U, wurde b = 0 eingebettet. Zwischen diesen beiden Werten ist keine Aussage möglich, d. h. das Bild wird als „nicht markiert“ eingestuft. Die Robustheit des Verfahrens gegenüber Störungen lässt sich durch die zwei Parameter B und U beeinflussen: Je größer B, desto größer wird auch die lineare Korrelation und umso wahrscheinlicher ist ein korrektes Detektieren des eingebrachten Bits, aber umso stärker natürlich auch die Veränderung des originalen Cover Work. Je größer der Schwellwert U, umso unwahrscheinlicher wird eine fehlerhafte Detektion eines Bits, d. h. die Anzahl von so genannten False Positives sinkt. Auf der anderen Seite führt ein großes U zu einer höheren Rate von markierten Cover Works, die als nicht markiert erkannt werden: Die Anzahl der False Negatives steigt. Beispiel 4 (s. [KJB]) Zum Markieren eines Farbbildes werden in diesem Verfahren seine Pixel in die drei Farbkanäle Blau, Gelb und Rot aufgespaltet. Da Änderungen am Blaukanal am wenigsten vom menschlichen Auge wahrgenommen werden, werden die Wasserzeichenbits dort eingebracht. Der Watermark Key dient als initialer Input zu einem Pseudozufallsgenerator, der eine Pixelposition (i,j) bestimmt. Nun erzeugt der Embedder ein Added Pattern wa mit den gleichen Ausmaßen wie das Cover Work und dem Wert

Bij ( wa ) D Lij (2b 1)

100

■ ■ ■

2 Mediensicherheit

für den Blaukanal an der Stelle (i,j). Dabei steht b für das einzubringende Bit und Lij für die Helligkeit des Originalbildes an der Stelle (i,j). Alle anderen Farbwerte werden auf Null gesetzt. Somit wird durch die Markierung mit dem Wasserzeichenbit b der Blaukanal des Cover Work wie folgt abgeändert:

Bijneu

Bij D Lij (2b 1) .

Um die Wasserzeichenbits ohne Kenntnis des Cover Work auslesen zu können, bildet der Detektor den Durchschnittswert der Blauwerte der Pixel des markierten Bildes in einer Kreuznachbarschaft der Größe c um die Stelle (i,j) herum:

Bij

c 1 § c neu neu · . Bi k , j ¦ Bineu ¦ , k j 2 Bij ¸ ¨ 4c © k c k c ¹

Da anzunehmen ist, dass die Blauwerte der die Stelle (i,j) umgebenden Pixel im Cover Work alle ungefähr ähnliche Werte haben, deutet eine Abweichung des Durchschnitts Bij von Bijneu nach unten darauf hin, dass Bijneu gegenüber Bij vergrößert wurde, also ein positives Bit eingebracht wurde. Ist hingegen der Durchschnittswert der umgebenden Blauwerte größer als Bijneu , wurde wahrscheinlich ein Nullbit kodiert. Um die Robustheit des Verfahrens zu erhöhen, kann das Bit mehrfach an unterschiedlichen Stellen des Cover Work eingebracht werden. Trotzdem ist das Verfahren anfällig gegen geometrische Transformationen des markierten Bildes und Austausch benachbarter Pixel. Beispiel 5 (s. [Kim]) Als Beispiel eines einfachen Wasserzeichen-Verfahrens für Audiodaten betrachten wir das Quantisierungsverfahren von Kim. Der Encoder wählt zunächst, gesteuert durch den Watermark Key, bestimmte zeitliche Positionen ti in der Audiodatei aus. Besteht die einzubettende Nachricht m aus n Bit bi, werden n Positionen ausgewählt. An diesen Stellen wird die Signalenergie x(ti) bestimmt. Die Signalenergien x(ti) werden durch das Einbetten der Wasserzeichenbits auf neue Werte y(ti) abgebildet:

y (ti )

q ( x(ti ),D ) D / 4 falls bi ® ¯q ( x(ti ),D ) D / 4 falls bi

1 0

Dabei ist q eine Quantisierungsfunktion, die die Signalenergien x(ti) auf ganzzahlige Werte abbildet:

q( x(t ),D ) i

ª x (t ) º « i » D ¬« D ¼»


■ ■ ■

101

Dabei bedeutet [ ] das Runden auf die nächstgelegene ganze Zahl. Die sich bei dieser Prozedur ergebenden Funktionswerte sind ganze Zahlen im Abstand des Parameters D. Sie werden als „Anker“ bezeichnet. Das Markieren bildet also die Signalenergie des Originals zunächst auf einen der Anker ab und verschiebt ihn dann um einen Betrag von D/4 nach oben oder unten, je nach einzubettendem Bit. Der Detektionsprozess kommt ohne die Original-Audiodatei aus. Dazu werden zunächst die Signalenergien y(ti) an den durch den Watermark Key vorgegebenen Stellen bestimmt und mit den vorab berechneten Ankerwerten verglichen. Ist zi der zu dem Wert y(ti) nächstgelegene Anker, so ergeben sich die eingebetteten Bits bi aus:

bi

1 falls 0 y (ti ) zi D / 4 ® ¯ 0 falls D / 4 y zi 0

Werden der markierten Datei Störgeräusche hinzugefügt, deren Signalstärke an den Stellen ti den Wert D/4 übersteigt, können die Wasserzeichenbits vom Detektor missinterpretiert werden. Auf der anderen Seite darf natürlich D nicht zu groß gewählt werden, da sonst das Wasserzeichen die Audioqualität zu stark beeinträchtigen würde. 2.2.2.3 Codierung längerer Nachrichten In den ersten beiden der obigen Beispiele wurde jeweils nur ein einziges Bit eingebettet. Das dritte Verfahren hingegen erlaubte das Einbringen mehrerer Bits zu verschiedenen Zeitpunkten. Das Prinzip, eine aus mehreren Symbolen bestehende Nachricht zu unterschiedlichen Zeiten über den gleichen Kanal zu transferieren, wird als Time Division Multiplexing bezeichnet. Ebenso ließe sich Beispiel 2 einfach zum Transport längerer Nachrichten erweitern, indem die Nachrichtenbits einzeln in unterschiedlichen Segmenten des Cover Work eingebettet werden. Somit würden unterschiedliche räumliche Abschnitte des gleichen Kanals zum Transport mehrerer Symbole genutzt: Dieses Verfahren heißt Space Division Multiplexing. Eine weitere Möglichkeit, die sowohl für Audio- als auch Videodaten in Betracht kommt, besteht im Frequency Division Multiplexing, also im Verteilen der Bits der Nachricht auf unterschiedliche Frequenzbänder, in denen dann das Einbetten der Bits separat erfolgt. Beim Code Division Multiplexing wird die Nachricht zunächst in Symbole (z. B. ASCII Zeichen) aufgeteilt, die durch verschiedene Bitfolgen (so genannte Codes) repräsentiert werden. Erfolgt die Detektion des Wasserzeichens wie in Beispiel 1 durch lineare Korrelation der empfangenen Daten mit einem Referenz-Muster wr, so lässt sich die Tatsache ausnutzen, dass bei geeigneter Codierung die Codes für

102

■ ■ ■

2 Mediensicherheit

einzelne Symbole zueinander orthogonal sind, ihr Skalarprodukt also Null ergibt. Die Codes der einzelnen Symbole lassen sich nun simultan in das Cover Work einbetten, indem man zusätzlich zu den eigentlichen Symbolen si noch deren Position j innerhalb der Nachricht m kodiert. Die Symbole sij (d. h. Symbol si an der Stelle j) lassen sich detektieren, indem das empfangene Signal nacheinander mit den Referenzmustern wr,ij für die Symbole sij korreliert wird. Um die Wahrscheinlichkeit zu erhöhen, dass der Detektor trotz eventueller Störungen die korrekte Nachricht m ausgibt, kann die Nachricht vor dem Einbetten mit einem Fehler korrigierenden Code (Error Correcting Code (ECC)) versehen werden. Diese sorgen dafür, dass mögliche Bitfehler in der empfangenen Nachricht entdeckt und auch korrigiert werden können, allerdings um den Preis, dass die maximale Länge der einzubettenden Nachrichten geringer wird. 2.2.2.4 Robustes Einbetten Robustheit stellt eine wichtige Anforderung an digitale Wasserzeichen dar. Man versteht darunter die Detektierbarkeit des Wasserzeichens, auch nachdem das markierte Cover Work gewissen Transformation, Störungen oder auch Angriffen ausgesetzt wurde. Intuitiv ist klar, dass die Anforderung der Robustheit der Anforderung der Nicht-Wahrnehmbarkeit widerspricht. Das „ideale“ robuste Wasserzeichen ist nicht wahrnehmbar und bleibt auch in manipulierten Mediendaten so lange detektierbar, bis eine Transformation den Wert des markierten Cover Work völlig zunichte macht. In der Praxis ist jedoch immer ein Kompromiss gefragt zwischen den zwei gegenläufigen Anforderungen. In manchen Anwendungsfällen wird die Nicht-Wahrnehmbarkeit zugunsten der Robustheit auch komplett aufgegeben ([Min], vgl. Abb. 2.5). Eine offensichtliche Möglichkeit, die Robustheit eines Wasserzeichens zu erhöhen, besteht im so genannten redundanten Einbetten, also dem mehrfachen Einbetten eines Wasserzeichens. „Mehrfach“ kann je nach zu markierendem Cover Work räumlich, zeitlich oder über unterschiedliche Frequenzen verteilt bedeuten. Dadurch bleibt das Wasserzeichen auch bei einfachem Abschneiden von Bild- oder Musikteilen bzw. Filtern von Frequenzbändern präsent. Überträgt man den Ansatz des redundanten Einbettens in verschiedene Frequenzbänder auf das Einbetten via Code Division Multiplexing, kommt man zum so genannten Spread-Spectrum-Coding: Dabei werden die einzubettenden Codewörter auf mehr Bits verteilt, als zur reinen Informationsübertragung nötig wäre (so genanntes Spreading bzw. Spreizen). Die 27 ASCII Zeichen beispielsweise könnten auf 512 Bit lange Codewörter aufgespreizt werden, die mittels des


■ ■ ■

103

Abb. 2.5: Seite einer Bibel aus der vatikanischen Bibliothek mit sichtbarem Wasserzeichen

Watermark Key durch einen Pseudozufallsgenerator erzeugt wurden. Diese Vorgehensweise bietet mehrere Vorteile: Zum einen verteilen sich die Änderungen durch die eingebrachten Wasserzeichensymbole gleichmäßig über 512 einzubringende Bit, wodurch die Wahrnehmbarkeit des Wasserzeichens insgesamt herab gesetzt wird. Zum anderen erhöht sich die Robustheit des Wasserzeichens, da sich eventuelle Störungen nur auf die Detektion einzelner Bits auswirken werden. Auch wenn einzelne Bits gestört beim Detektor ankommen sollten, sorgt die Tatsache, dass pseudozufällig erzeugte Bitfolgen mit hoher Wahrscheinlichkeit nahezu orthogonal sind, bei der Detektion durch Korrelation dafür, dass die kodierten Zeichen korrekt erkannt werden können. Zudem wird das Aufspüren und eventuell Entfernen des Wasserzeichens durch einen Angreifer wesentlich erschwert. Schließlich kann beim Einbetten die Wirkung bestimmter, wahrscheinlicher Transformationen, wie etwa die Kompression eines Bildes nach JPEG, berücksichtigt werden. Dazu begibt man sich in den Bereich, in dem die betreffende Transformation arbeitet und bettet die einzubringenden Bits direkt in die sich nach der Transformation ergebenden Koeffizienten ein. Hierzu zwei Beispiele, die robust gegen JPEG bzw. JPEG2000-Kompression sind:

104

■ ■ ■

2 Mediensicherheit

Beispiel 6 (s. [CKLS]) Cox et al. betten ein Wasserzeichen der Länge n in die N betragsmäßig größten Koeffizienten der Transformations-Matrix der Bildpixel nach einer Diskreten-Kosinus-Transformation (s. Kap. 1.3.4.1) ein, indem sie zunächst n der N Koeffizienten pseudozufällig (d. h. gesteuert durch den Watermark Key) auswählen. Die Zahl n ist ein Maß für den Grad der Spreizung des Wasserzeichens X. Es wird durch n normalverteilte reelle Zufallszahlen xi dargestellt. Sind ui die ausgewählten Koeffizienten, so lauten die neuen DCT Koeffizienten nach dem Einbetten

vi

ui D xi

Die Detektion geschieht hier mittels eines informierten Detektors, also unter Kenntnis des Originals. Der Detektor bestimmt zunächst * das gestörte Wasserzeichen X und berechnet dann ein Ähnlichkeitsmaß

sim( X , X * )

X* X X*X*

Liegt dieses Maß über einem bestimmten Schwellwert, gilt das Wasserzeichen X als detektiert. Dieses Maß besitzt eine besonders geringe Rate an False Positives und eignet sich daher gut zum Copyright Nachweis. Die Tatsache, dass gerade die größten DCTKoeffizienten durch das Wasserzeichen modifiziert werden, bedeutet, dass das Wasserzeichen im Bildraum in feinen Bildstrukturen zu finden ist. Ein Versuch, das Wasserzeichen ohne Kenntnis des Watermark Key zu entfernen, sollte daher in einem unbrauchbaren Bild resultieren. Beispiel 7 (s. [GrEb]) Um gegen JPEG2000 Kompression robust zu sein, wird bei diesem Verfahren wird im Wavelet-Bereich gearbeitet. Sind bi die n Wasserzeichen Bits (wobei hier bi {-1,1} gilt), ni gewisse pseudozufällig erzeugte Zahlen mit Mittelwert 0, und wi die quantisierten Wavelet-Koeffizienten der JPEG2000 Transformation, so erhält man die markierten Koeffizienten durch

wi'

wi D bi ni

Die Detektion der einzelnen Wasserzeichenbits erfolgt (ohne Kenntnis des Originals) durch Bilden eines separaten Korrelationswertes für jedes Bit. Das Wasserzeichen ist robust gegen übliche Kompressionsverfahren, kann aber durch geometrische Transformationen im Bildbereich entfernt werden.


■ ■ ■

105

2.2.3 Angriffe In diesem Abschnitt diskutieren wir die drei wichtigsten Angriffstypen, denen digitale Wasserzeichen ausgesetzt sind. Grundsätzlich muss man feststellen, dass ein genereller Schutz für digitale Wasserzeichen aufgrund der Vielzahl möglicher Transformationen, die ein Angreifer mit einem markierten Original durchführen kann, nur sehr schwer zu erreichen ist. In der Praxis muss daher bei der Auswahl eines Verfahrens abgewogen werden zwischen dem Wert der zu schützenden Originaldaten, dem Einsatzbereich des Wasserzeichens und den damit verbundenen Sicherheitsanforderungen sowie dem Aufwand, den ein potenzieller Angreifer treiben müsste, um das Wasserzeichen zu attackieren. 2.2.3.1 Unbefugtes Einbetten Bei dieser Attacke gelingt es dem Angreifer, ein eigenes Wasserzeichen in ein Cover Work einzubetten, obwohl er dazu nicht berechtigt ist. Dies ist besonders kritisch bei Copyright-Anwendungen: Der Angreifer kann nach dem unbefugten Einbetten behaupten, er selbst halte das Copyright auf das Original. Grundsätzlich wird das unbefugte Einbetten durch die Verwendung eines Spread-Spectrum-Verfahrens unter Steuerung eines Watermark Keys erschwert. Gelänge es dem Angreifer aber, sich den Watermark Key zu verschaffen, wäre er in der Lage, eigene Wasserzeichen einzubetten. Dieser Angriff lässt sich aber verhindern, indem die einzubettende Nachricht vor dem Einbetten mit einem Cipher Key zusätzlich verschlüsselt wird. Dadurch kann der Angreifer zwar Nachrichten einbetten, aber kann keine authentische Nachricht zum Einbetten erzeugen. Schwieriger ist ein verwandter Angriff abzuwehren, bei dem ein Angreifer sich eine gültige Nachricht bzw. ein gültiges Added Pattern wa aus einem anderen markierten Cover Work beschafft, etwa indem er sich das unmarkierte Original C0 besorgt und die Differenz mit dem markierten Cover Work bildet:

wa CW C0 Dieses Added Pattern könnte nun auch in ein anderes Cover Work eingebettet werden (so genannte Copy Attack). Die Abwehr gegen diesen Angriff besteht darin, die einzubettende Nachricht nicht nur kryptografisch abzusichern, sondern auch vom Cover Work, in das eingebettet werden soll, abhängig zu machen. Dadurch gelingt eine Kopplung des Cover Work mit dem Added Pattern und die Copy

106

■ ■ ■

2 Mediensicherheit

Attack wird unmöglich gemacht. Eine einfache digitale Signatur der Quelldaten des Cover Work ist jedoch als Added Pattern nicht geeignet, da die Quelldaten durch erlaubte Transformation verändert werden könnten, so dass auch in diesem Anwendungsfall auf inhaltsbasierte Signaturen (s. 2.2.1.6) zurückgegriffen werden sollte. 2.2.3.2 Unbefugtes Detektieren des Wasserzeichens In dieser Angriffskategorie ist zu unterscheiden, ob über ein Wasserzeichen sensitive Informationen transportiert werden sollen oder ob schon die bloße Tatsache, dass die Daten markiert sind, geheim gehalten werden soll. Sind die im Wasserzeichen enthaltenen Informationen geheim (wie etwa bei Transaction Tracking Watermarks, die Informationen über Kunden enthalten), können sie vor dem Einbetten verschlüsselt und so für einen Angreifer unkenntlich gemacht werden. Aber auch das bloße Testen darauf, ob ein Wasserzeichen in Mediendaten enthalten ist, kann einem Angreifer wertvolle Informationen liefern (s. unten). Diese Art von Angriff lässt sich mit kryptografischen Mitteln nicht verhindern, zumal in vielen Anwendungsfällen wie der Copy Control (s. 2.2.1.3) dem Angreifer tatsächlich ein Detektor in Form eines Abspiel- oder Kopiergeräts zur Verfügung steht. 2.2.3.3 Unbefugtes Entfernen des Wasserzeichens Idealerweise hat das unbefugte Entfernen eines eingebrachten Wasserzeichens auch die Zerstörung bzw. das Unbrauchbar machen der Mediendaten zur Folge. Das bedeutet, durch das „gewaltsame“ Entfernen des Wasserzeichens werden die markierten Mediendaten in einem abstrakten Media Space sehr weit von den Originaldaten entfernt. Wie wir gesehen haben, kann man diesem Ziel durch robuste Einbettungstechniken, insbesondere Spread Spectrum Coding, näher kommen. Das Ziel eines Angreifers ist es hingegen, Mediendaten zu konstruieren, die kein Wasserzeichen mehr enthalten und die dem Original sehr ähnlich sehen. Im Falle von Transaction Watermarks bestehen beispielsweise viele Kopien des Originals mit unterschiedlichen Wasserzeichen. Arbeiten nun die Eigentümer verschiedener markierter Cover Works zusammen, so lässt sich mit Hilfe der unterschiedlichen markierten Daten durch Differenz- und Durchschnittsbildung das Original C0 abschätzen (so genannte Collusion Attack). Steht dem Angreifer ein Detektor zur Verfügung, wird eine sehr allgemeine Form des Angriffs auf Wasserzeichen möglich, die so


■ ■ ■

107

Abb. 2.6: Oracle Attack (nach [Pet]) Im Kreis um das unmarkierte Original C0 befinden sich alle zu C0 ähnlichen Mediendaten von akzeptabler Qualität. Der Detektor teilt den Kreis in zwei Regionen, in denen das Wasserzeichen detektiert bzw. nicht detektiert werden kann. Ziel des Angreifers ist es, die Startdaten I0 sukzessive durch kleine Änderungen in den linken Teil des Kreises zu transferieren.

genannte Oracle Attack: Der Angreifer konstruiert zunächst Mediendaten I0 im passenden Format, die zwar weit entfernt vom Original sind, dafür aber kein Wasserzeichen enthalten. Davon ausgehend führt er mit Hilfe des Detektors nach dem „Trial and Error“-Prinzip eine Folge kleiner Veränderungen durch, die ihn sukzessive immer näher an das Original heranbringen, jedoch nicht zur Folge haben, dass das Wasserzeichen detektiert wird, bis das Ergebnis In eine zufrieden stellende Qualität besitzt (s. Abb. 2.6). Geht es zum Beispiel um ein Bild, können die Helligkeits- und Farbwerte von I0 Pixel für Pixel leicht abgeändert werden, bis das Ergebnis akzeptabel ist. 2.2.3.4 Stirmark Stirmark [Pet2] ist ein frei erhältliches Tool zur Durchführung automatischer Robustheits-Tests für Wasserzeichen in digitalen Bildern. Es unterwirft das Input-Bild kleinen, zufälligen Verschiebungen und Verzerrungen, die für das menschliche Auge nicht erkennbar sind, aber dafür sorgen können, dass ein eingebrachtes Wasserzeichen nicht mehr detektierbar ist. Mittlerweile existiert auch eine StirmarkVersion für Audiodaten (s. [DiLa]).

2.3 DRM-Systeme Digital Rights Management Systeme haben zum Ziel, die mit der Erzeugung und dem Vertrieb digitaler Mediendaten verbundenen Rechte, wie sie vom Inhaber der Daten formuliert werden, in einer

108

■ ■ ■

2 Mediensicherheit

standardisierten Form zu präsentieren, sie an die Mediendaten zu binden und ihre Durchsetzung zu ermöglichen. Solche Systeme werden in der Öffentlichkeit zurzeit kontrovers diskutiert: Den einen erscheinen sie als Instrumente zur willkürlichen Einschränkung der Nutzungsrechte an einem einmal erworbenen Gut, den anderen als einziges Mittel, Kreativität weiterhin angemessen zu entlohnen und dabei am scheinbar unbegrenzten Potenzial des Internet zum Vertrieb digitaler Güter teilzuhaben. Ziel der folgenden Kapitel ist es nicht, für eine der beiden Seiten Partei zu nehmen, sondern die technischen Grundlagen von DRM-Systemen zu verdeutlichen und dem Leser so zu ermöglichen, sich ein eigenes Urteil zu bilden.

2.3.1 Komponenten von DRM-Systemen DRM-Systeme sind im Moment noch sehr wenig standardisiert (mit der Ausnahme mobiler DRM-Systeme, s. 2.3.2), sondern werden von einzelnen Firmen weiter entwickelt, die ihrerseits nur sehr wenig über die im Detail eingesetzten Verfahren veröffentlichen. Trotzdem besitzen alle DRM-Systeme eine relativ einheitliche Struktur mit ähnlichen Komponenten. 2.3.1.1 Sichere Mediencontainer Die Mediendaten werden auf einem Content-Server zum Download bereitgehalten. Vor dem Transport zu den Kunden werden sie eventuell komprimiert und danach mit den in 2.1.2.1 angesprochenen symmetrischen Verfahren verschlüsselt. Neben den verschlüsselten Quelldaten finden sich auf dem Server auch Metadaten zum leichteren Auffinden der Daten sowie eine URL, die auf einen Lizenzserver verweist. Dort kann sich der Kunde nach voran gegangener Authentifizierung ein Rechteobjekt laden, welches neben den mit dem Erwerb der Mediendaten verbundenen Rechten auch den Schlüssel enthält, mit dem die Quelldaten verschlüsselt sind. Natürlich muss auch dieser Schlüssel vertraulich übermittelt werden. Dies kann über den Public Key des Kunden passieren (sofern dieser ein Zertifikat besitzt) oder aber über einen verschlüsselten Kanal vom Kunden zum Lizenzserver, wie ihn zum Beispiel das Sicherheitsprotokoll SSL/TLS (siehe hierzu zum Beispiel [Bl], Kap. 7.3) bereitstellt.

2.3 DRM-Systeme

■ ■ ■

109

2.3.1.2 Aussagen über Rechte Die mit dem Erwerb digitaler Mediendaten verbundenen Rechte drücken aus, wer das Recht hat, die Daten zu nutzen, und in welcher Form bzw. wie oft die Daten kopiert und weiter gegeben werden dürfen. Sie werden vom Lizenzserver in einem so genannten Rechteobjekt (Rights Object) zusammengefasst und stehen für authentifzierte Nutzer zum (in der Regel kostenpflichtigen) Download bereit. Die Aussagen über die Nutzungsrechte im Rechteobjekt müssen maschinenlesbar sein, und zwar nach Möglichkeit auch für Geräte unterschiedlicher Hersteller. Zu diesem Zweck wird eine Rights Expression Language (REL) definiert. Das Spektrum reicht von einem einfachen Satz gesetzter bzw. nicht gesetzter Flags bis hin zu komplexen XML-basierten Dokumenten, die selbst wiederum vom Rechteinhaber digital signiert sein können, wodurch verhindert wird, dass Kunden die ihnen zugestandenen Rechte modifizieren. Die im Moment am wichtigsten erscheinenden Standards im Bereich der RELs sind beide XML-basiert: Zum einen die Open Digital Rights Language (ODRL, siehe [Ian]) und zum anderen die von Microsoft und Xerox entwickelte eXtensible Rights Markup Language (XRML, siehe [XRM]). So ist zum Beispiel der Windows Media Player von Microsoft in der Lage, XRML-Dateien zu interpretieren (siehe auch Abb. 2.7). Abb. 2.7: Nutzungsrechte eines geschützten Musikstücks im Windows Media Player

110

■ ■ ■

2 Mediensicherheit

2.3.1.3 Metadaten Metadaten dienen zur eindeutigen Identifizierung der Mediendaten sowie zur Beschreibung ihrer Inhalte. Beides wird im Klartext auf dem Content-Server bereitgehalten und ermöglicht den Kunden das einfachere Auffinden der gewünschten Inhalte, während der Anbieter die Identifikationsdaten mit in das Rechteobjekt aufnehmen und so das Medienobjekt an das Rechteobjekt koppeln kann. 2.3.1.4 Identifikations- und Authentifikationssysteme Diese Systeme bilden einen wesentlichen Bestandteil eines jeden E-Commerce-Systems. Sie dienen dazu, die Identität von Kunden zu verifizieren und somit nach der Bestellung den Bezahlvorgang einleiten zu können. Der Kunde kann über die Authentifikation beim Lizenzserver nachweisen, dass er die Berechtigung hat, ein Rechteobjekt zu laden ist. Daneben hat der Kunde auch die Möglichkeit, über einen entsprechenden Mechanismus die Identität eines Content-Servers verifizieren zu können. Aus technischer Sicht werden serverseitig zumeist Zertifikate und digitale Signaturen zur Authentifizierung eingesetzt, während die Kunden sich zumeist über Username und Passwort authentifizieren. Natürlich muss hierbei vorab ein sicherer Kanal via SSL/TLS zwischen Server und Kunde etabliert werden. 2.3.1.5 Digitale Wasserzeichen Werden digitale Wasserzeichen im Rahmen eines DRM-Systems eingesetzt, müssen sie vom Rechteinhaber in die Mediendaten eingebracht werden, bevor sie an die Kunden geliefert werden. Der Kunde erhält also nicht die Originaldaten, sondern ein markiertes Cover Work. Wasserzeichen kommen in dem Moment ins Spiel, wenn dem Kunden die Mediendaten in unverschlüsselter Form vorliegen. Es gibt dann keine Möglichkeiten mehr, eventuelle Nutzungsbeschränkungen durchzusetzen oder die unbefugte Weitergabe der Daten zu verhindern, es sei dann, diese Beschränkungen wären Teil der Daten selbst. Denkbar wäre der Einsatz von Wasserzeichen sowohl zum Kopierschutz als auch zum Nachweis der Urheberschaft und zum Transaction Tracking. Bis auf wenige Ausnahmen gibt es in diesem Bereich aber keine gesicherten Informationen durch die Industrie.

2.3 DRM-Systeme

■ ■ ■

111

2.3.1.6 Bezahlsysteme Bezahlsysteme stellen die Verbindung her zwischen dem Content Server, bei dem der Kunde bestellt hat, und einem dem Kunden gehörenden Konto, zum Beispiel bei einer Kreditkartenfirma, über das die Bezahlung der Mediendaten abgewickelt werden kann. Nach wie vor stellt die Bezahlung über Kreditkarten die im Internet vorherrschende Methode dar, obwohl sie einige Nachteile mit sich bringt. So lohnt sich der Aufwand nur bei Beträgen, die zumindest die Ein-Euro-Grenze überschreiten. Zudem muss bei den heute eingesetzten Systemen der Kunde seine Kreditkartennummer an den Content Server übermitteln, was zusätzliche Sicherheitsrisiken in sich birgt: Zwar geschieht die Übermittelung der Nummer in der Regel über einen gesicherten Kanal, jedoch ist nicht klar, wie sorgfältig der Server nach der Übermittelung mit den Daten umgeht. Trotzdem haben sich alternative Bezahlsysteme für das Internet wie die von D. Chaum entwickelten digitalen Münzen [Cha] bislang nicht durchsetzen können, obwohl die technischen Voraussetzungen durchaus vorhanden sind. Etwas anders gelagert ist die Situation bei mobilen DRM-Systemen (siehe unten). Hierbei hat der Kunde immer auch einen Vertrag mit einem Mobilfunkanbieter, dem er bei der Abrechnung seiner Gesprächsdaten vertraut. Die Abrechnung mobil erworbener Mediendaten könnte deshalb in diesem Fall einfach über den Mobilfunkanbieter erfolgen, sofern ein entsprechender Vertrag zwischen dem Rechteinhaber und dem Mobilfunkbetreiber vorliegt.

2.3.2 Mobile DRM-Systeme Wie in Kap. 4 dargelegt wird, haben sich die Mobilfunknetze in den letzten Jahren von einem reinen Netz für Sprachtelefonie immer mehr hin zu einem universellen Datennetzwerk entwickelt. Insbesondere die modernen GPRS- bzw. UMTS-Mobilfunknetze bieten mittlerweile eine ihren Nutzern eine Bandbreite an, die es möglich macht, auch hochqualitative Medienobjekte über die so genannte Luftschnittstelle auf die mobilen Endgeräte zu transferieren. Aus diesem Grund sind die diskutierten DRM-Technologien auch und gerade für mobile Netze und Endgeräte relevant. Die gerade beschriebenen Basiskomponenten von DRM-Systemen lassen sich am Beispiel der gerade veröffentlichten Version 2.0 der DRM Architecture der Open Mobile Alliance (OMA) gut nachvollziehen, da wir hier mit einem der wenigen veröffentlichten DRM-Systeme

112

■ ■ ■

2 Mediensicherheit

zu tun haben. Zunächst aber wollen wir deutlich machen, in welcher Hinsicht sich mobile DRM-Systeme von DRM-Systemen im Allgemeinen unterscheiden. 2.3.2.1 Spezielle Aspekte mobiler DRM-Systeme Die Anforderungen an ein mobiles DRM System sind im Prinzip die gleichen, wie sie auch an ein Internet-basiertes System gestellt werden, bei dem der Desktop-PC das dominierende Endgerät darstellt: Sicherer Transport der Mediendaten zum Kunden, Schutz des Copyright und Durchsetzung der Einschränkungen, die mit dem Erwerb der Mediendaten verbunden sind. Trotzdem gibt es einige Aspekte, die mobile DRM-Systeme von DRM-Systemen im Allgemeinen unterscheiden: x Verlust eines Endgeräts Ein mobiles Endgerät geht sehr viel leichter verloren bzw. kann leichter gestohlen werden als ein Desktop-PC. Ein mobiles DRMSystem muss dies berücksichtigen, besonders bei der Speicherung der Authentifikationsdaten der Kunden auf dem Endgerät: Ein Dieb bzw. Finder sollte nicht in der Lage sein, auf Kosten des Kunden weitere Medienobjekte zu bestellen. x Enge Kopplung der Endgeräte mit dem Betriebssystem Typischerweise besteht zwischen Hardware und Betriebssystem eines mobilen Endgeräts ein enger Zusammenhang, da beides aus der Hand eines Herstellers kommt. Es ist daher für einen Hersteller leichter, sein Betriebssystem und seine Hardware auf die Belange eines DRM-Systems abzustimmen. x Super-Distribution Die Nutzer mobiler Endgeräte kommen häufiger miteinander in direkten Kontakt als Nutzer des drahtgebundenen Internet. Die heutigen mobilen Endgeräte bieten diverse Möglichkeiten zum spontanen, drahtlosen Datenaustausch, etwa über Bluetooth oder Infrarot. Unter Super-Distribution versteht man die Möglichkeit, ein einmal erworbenes Medienobjekt direkt von einem zum anderen Nutzer weiter zu geben, wodurch der Content-Server entlastet wird. Trotzdem sollte das DRM-System dem Rechteinhaber die Möglichkeit geben, die Kontrolle über das Medienobjekt behalten zu können. x Authentifikation Die Teilnehmer eines Mobilfunknetzes sind durch eine voran gegangene Anmeldung und Authentifikation dem Netz bekannt. Diese Tatsache kann sich ein mobiles DRM-System zu Nutze machen. Im Gegensatz dazu bleiben Nutzer des Internet zumeist anonym.

2.3 DRM-Systeme

■ ■ ■

113

x Interoperabilität Die oben beschriebene Super-Distribution von Inhalten von Endgerät zu Endgerät und die Forderung, den mobilen Nutzern einen möglichst transparentem Wechsel des besuchten Netzes zu ermöglichen, führt zu einer sehr weit reichenden Anforderung nach Interoperabilität eines mobilen DRM-Systems für verschiedene Endgerätetypen und über Netzgrenzen hinweg. Aus diesem Grund ist es nicht verwunderlich, dass gerade im mobilen Sektor die DRMStandardisierung am weitesten fortgeschritten ist. 2.3.2.2 Die DRM-Architektur der Open Mobile Alliance (OMA) Die Open Mobile Alliance (OMA) stellt einen Zusammenschluss von über 250 Firmen dar, der sich die Spezifikation offener Standards für mobile Dienste zur Aufgabe gemacht hat. Im September 2005 hat sie die zweite Version ihrer DRM-Architektur veröffentlicht [OMA], die wir nun vorstellen. Abbildung 2.8 zeigt die wesentlichen Akteure in einem mobilen DRM-System. Als DRM Agents werden in diesem Szenario die Bestandteile eines mobilen Endgeräts bezeichnet, die mit dem Management der Rechte für die Medienobjekte befasst sind. DRM Agents gelten als vertrauenswürdige Plattformen. Jeder DRM Agent sowie Content Issuer und Rights Issuer besitzen ein asymmetrisches Schlüsselpaar mit den dazu gehörigen Zertifikaten. Im Falle der Agents könnte der Hersteller der Endgeräte als CA (s. 2.1.2.5) auftreten und das Schlüsselpaar und Zertifikat bereits bei der Auslieferung auf dem Gerät speichern, aber Abb. 2.8: Funktionale Architektur des Mobile DRM Standards (aus [OMA])

114

■ ■ ■

2 Mediensicherheit

auch der nachträgliche Erwerb eines Zertifikats ist möglich. Der menschliche Nutzer eines DRM Agents entscheidet sich bei einem Besuch beim Server des Content Issuer für den Erwerb gewisser Mediendaten, zum Beispiel einen Musiktitel. Daraufhin lädt er sich ein geschütztes Medienobjekts (DRM Content Format, DCF) vom Content Server herunter. Die Mediendaten im DCF sind mit einem symmetrischen Schlüssel (Content Encyption Key, CEK) verschlüsselt. Darüber hinaus enthält das DCF einen Verweis auf den Rechteverwalter sowie eine Inhaltsbeschreibung der Daten im Klartext. Um die Daten nutzen zu können, muss sich der DRM Agent nach dem Download des DCF ein Rechte-Objekt (Rights Object, RO) vom Rechteverwalter besorgen. Hierfür wurde ein separates Protokoll, das Rights Object Acquisition Protocol (ROAP) von der OMA spezifiziert. Im Laufe dieses Protokolls tauschen DRM Agent und Rights Issuer ihre Zertifikate aus. In der Folge findet eine gegenseitige Authentifizierung von DRM Agent und Rights Issuer mit Hilfe ihrer jeweiligen Secret Keys statt. Das Rights Object ist ein vom Rights Issuer digital signiertes, XMLbasiertes Dokument. Genauer gesagt, ist es in der OMA DRM Rights Expression Language [OMAR] abgefasst, welche wiederum auf der bereits erwähnten Open Digital Rights Language basiert. Neben den eigentlichen Nutzungsrechten, die sich in Permissions (zum Beispiel „Display“ oder „Execute“) und Constraints (zum Beispiel „Display only 10 Times“) aufgliedern, enthält das Rights Object auch den zum Abspielen nötigen Content Encryption Key, allerdings auch wiederum verschlüsselt, und zwar mit dem Rights Encryption Key (REK). Der Rights Issuer verschlüsselt den Rights Encryption Key nach erfolgreicher Authentifizierung mit dem Public Key des Agents und sendet das Ergebnis zusammen mit dem Rights Object dem Agent zu. Möchte der Agent nun die erworbenen Mediendaten nutzen, so entschlüsselt er zunächst mit Hilfe seines Private Key den Rights Encryption Key und kann danach auch den Content Encryption Key entschlüsseln. OMA-DRM-konforme Endgeräte speichern CEK, REK oder die Quelldaten der Medienobjekte niemals im Klartext, sondern führen die nötigen Entschlüsselungen jeweils bei Bedarf durch. Bei jedem Abspielvorgang wird also der Zugriff auf das Rechteobjekt notwendig, was die Durchsetzung der darin enthaltenen Constraints ermöglicht. Da DCF und Rights Object beide kryptografisch geschützt sind, können sie ohne weiteres auf externen Speichermedien archiviert werden, ohne dass Nutzungsrechte verletzt werden. Möchte nun ein Nutzer sein geschütztes Medienobjekt an einen anderen DRM Agent weitergeben, so ist dies ebenfalls problemlos möglich. Allerdings muss der empfangende Agent sich anschließend sein eigenes Rights Object beim Rights Issuer besorgen (und bezahlen), da

2.3 DRM-Systeme

Funktionale Rollen in der mobilen DRM-Architektur

Geschützte Container

Aussagen über Rechte Identifikation und Authentifikation

Super-Distribution

■ ■ ■

115

Domänen

Bezahlsysteme

der CEK bzw. REK mit dem Public Key des sendenden Agent geschützt sind. Rights Objects sind also an einen bestimmten DRM Agent, das heißt, an ein bestimmtes Endgerät, gebunden. Möchte ein Nutzer die erworbenen Daten auf mehreren Endgeräten (Handys, PDAs) nutzen, so besteht die Möglichkeit, diese verschiedenen Endgeräte in einer so genannten Domain zusammen zu fassen. Dazu müssen sich die betreffenden Endgeräte beim Rights Issuer als Domäne registrieren lassen und bekommen daraufhin einen symmetrischen Domänen-spezifischen Schlüssel KD zugewiesen, zur Übertragung natürlich wiederum verpackt in ihrem jeweiligen Public Key. Der REK in einem Rights Object für eine Domäne ist mit KD verschlüsselt. Da alle Geräte einer Domäne KD kennen, ist auch für alle Geräte der Domäne der REK und damit auch der CEK entschlüsselbar. Es ist also ausreichend, wenn ein einziges Gerät der Domäne den Container und das dazu gehörige Rechteobjekt lädt und dann beides an alle Agents der Domäne weiter gibt. Die Spezifikation der OMA macht keinerlei Vorgaben hinsichtlich des eigentlichen Bezahlvorgangs. Die Art der Abwicklung bleibt also den jeweiligen Rechteinhabern überlassen.

2.3.3 Angriffe auf DRM-Systeme Wie oben beschrieben, liegen die geschützten Mediendaten zunächst in verschlüsselter Form auf dem PC des Kunden vor. Um sie abspielen zu können, entschlüsselt die Player-Software zunächst mit Hilfe des Schlüssels im dazu gehörigen Rechteobjekts die Mediendaten und sendet sie dann im Klartext zum Treiber der Sound- bzw. Videokarte. Ein offensichtlicher Angriff besteht also darin, die Player-Software so zu modifizieren, dass der verwendete Schlüssel im Klartext zugänglich wird und somit das Medienobjekt in ungeschützter Form vorliegt. Einfacher ist es, die Klartextdaten auf ihrem Weg zum Treiber abzuhören und auf die Festplatte zu schreiben Entsprechende CrackingTools existieren sowohl für Audio- als auch für Videodaten (s. [HW]). Mittlerweile wird der betreffende Kanal zumindest für Audiodaten durch Microsofts Windows Media Rights Manager aber verschlüsselt. Somit bleibt als letzter Angriffspunkt noch der Weg vom Kartentreiber zur Karte selbst: Um hier an die Audiodaten zu gelangen, muss ein Angreifer eine „virtuelle Soundkarte“ kreieren und dem Treiber vorgaukeln, dies sei die authentische Soundkarte. Ein Angriff dieser Art lässt sich nur verhindern, indem sich die originale Soundkarte gegenüber dem Treiber authentifiziert und danach ein verschlüsselter

116

■ ■ ■

2 Mediensicherheit

Kanal aufgebaut zwischen beiden aufgebaut wird. Dazu müssen die Soundkarte und die Treibersoftware entsprechend zertifiziert sein. Eine durchgängige Zertifizierung von Systemsoft- und Hardware auf Kunden-PCs ist auch das Ziel von Microsofts Next Generation Secure Computing Base (NGSCB), früher auch „Palladium“ genannt. Durch eine vollständige Zertifizierung der gesamten zum Verarbeiten von DRM-geschützten Mediendaten benutzten Software wäre auch ein Angriff auf die verwendeten Schlüssel nicht mehr möglich. Obwohl dies nicht von Microsoft bestätigt wird, liegt die Vermutung nahe, dass NGSCB unter anderem dem Zweck dienen soll, Schlupflöcher für die beschriebenen Angriffe auf DRM-Systeme zu schließen.

2.3.4 Kommerzielle DRM-Systeme Im Folgenden stellen wir die in einigen bekannten kommerziellen Download-Portalen verwendete DRM-Technologie kurz vor. Dabei beschränken wir uns auf die momentan wichtigsten Anwendungsfälle Audiodaten und eBooks. Je nach Betreiber des Portals werden dabei interessante ökonomische Verknüpfungen zwischen zu verwendender Software, Abspielgeräten und Bezahlsystemen deutlich. 2.3.4.1 musicload musicload.de ist ein vom größten deutschen Internet-Provider T-Online betriebenes, deutschsprachiges Portal zum kostenpflichtigen Download von Musiktiteln, Alben oder speziellen Kompilationen. Nach einer Umfrage der Hamburger Online-Forscher Fittkau & Maaß ist musicload.de mit ca. 1,4 Millionen Downloads pro Monat das in Deutschland am häufigsten genutzte Download-Portal. Derzeit bietet musicload ca. 500000 Musiktitel zum Download an. Zur Anmeldung gibt der Kunde über einen via SSL abgesicherten Kanal Name, Adresse, E-Mail-Adresse sowie Zahlungsinformationen an. Die Zahlung kann sowohl über Kreditkarte als auch über alternative Modelle wie die T-Online Rechnung (falls der Kunde auch T-Online Kunde ist) oder auch T-Pay (Zahlung über die Telefonrechnung der Telekom) erfolgen. Für spätere Anmeldung wählt der Kunde noch einen Usernamen und ein Passwort. Als DRM-System verwendet musicload den Windows Media Rights Manager (WMRM) von Microsoft. Als Abspielsoftware auf dem PC muss der Windows Media Player (ab Version 9) genutzt werden. Der Download selbst kann nur über den Microsoft Internet Explorer

2.3 DRM-Systeme

■ ■ ■

117

Abb.2.9: Schlüsselverteilung im Windows Media Rights Manager ( s. [MS])

erfolgen. Nutzer von Betriebssystemen wie Mac OS oder Linux können somit nicht bei musicload einkaufen. Beim Download erhält der Kunde ein verschlüsseltes WMA-File mit einem Link auf den zuständigen Lizenzserver und einer KeyID, die auf den verwendeten Schlüssel verweist. Danach kontaktiert der Internet-Explorer den Lizenzserver und fordert eine Lizenz für das Medienobjekt an, auf welches die KeyID verweist (s. Abb. 2.9). Bei der Lizenz handelt es sich um ein Rechteobjekt im XRMLFormat, welches neben den mit dem Erwerb verbundenen Rechten auch den zum Entschlüsseln des WMA-Files erforderlichen Schlüssel enthält. Dieser ist mit einem Public Key verschlüsselt, der vom Lizenzserver für jedes Endgerät des Kunden separat erzeugt wird. Da nur bis zu drei Lizenzen pro Download erzeugt werden, kann der Kunde seinen Content nur auf bis zu drei Endgeräten nutzen. Die Übertragung auf mobile Player und das (bis zu 10malige) Brennen auf CD ist ebenfalls möglich, jedoch unterstützen nicht alle Player (insbesondere auch nicht Apples iPod) die verwendete DRM-Technologie. 2.3.4.2 Apple iTunes Der Name „iTunes“ steht sowohl für ein Download-Portal als auch für eine von Apple entwickelte Player-Software, die beim Portal kostenlos herunter geladen werden kann und auf allen gängigen Betriebssystemen einsetzbar ist. Das Portal bietet neben 2 Millionen Musiktiteln

118

■ ■ ■

2 Mediensicherheit

auch 1000 Musikvideos und 12000 Hörbücher. Es ist nicht über einen der gängigen Internet-Browser zugänglich, sondern nur über die iTunes-Software, die Browser- und Abspielfunktionalität in sich vereint. Bei der Registrierung im Portal wird aus der E-Mail Adresse des Kunden eine so genannte AppleID erzeugt, die, zusammen mit dem vom Kunden gewählten Passwort, auch zur Anmeldung für andere, von Apple betriebene Dienste genutzt werden kann. Pro Nutzeraccount, das heißt, für jede AppleID, können bis zu sechs PCs und ein Apple iPod als mobiles Abspielgerät registriert werden. Beim Download des geschützten Content (das verwendete Format heißt M4P für MPEG-4 protected) wird der verwendete symmetrische Schlüssel in einen gerätespezifischen Public Key verpackt und dem geschützten Content hinzu gefügt. Ein eigenes Rechteobjekt wie im Window Media Rights Manager gibt es nicht. Durch die Bindung der Public Keys an ein bestimmtes Endgerät und einen bestimmten Account wird aber die unkontrollierte Weitergabe an andere Nutzer verhindert. Die Bezahlung erfolgt im Normalfall über Kreditkarte. Allerdings sind auch andere Bezahlmodelle möglich, beispielsweise ein über einen bestehenden Account gefülltes „Taschengeldkonto“ für einen anderen Nutzer. Wie der Name schon andeutet, wurde diese Möglichkeit wahrscheinlich eingeführt, um auch noch nicht volljährigen Kunden das Einkaufen bei iTunes zu ermöglichen. Aus ökonomischer Sicht fällt auf, dass sowohl Einzeltitel als auch Alben im Normalfall bei iTunes um ca. 30% günstiger zu erwerben sind als bei musicload. Teilweise liegen die Preise auch unter dem Ladenpreis. Wahrscheinlich handelt es sich hierbei um eine indirekte Subventionierung des iPod, da durch das verwendete proprietäre Datenformat andere mobile Player ausgeschlossen sind. 2.3.4.3 eBooks.com Dieses Portal für elektronische Bücher ist nach eigener Aussage „The world’s leading source of eBooks“ und bietet ca. 52000 hauptsächlich englischsprachige Titel an. Das Haupteinsatzfeld für eBooks liegt im wesentlichen im Bereich der Handheld-PCs. Die Bezahlung der Titel erfolgt ausschließlich über Kreditkarten. Beim Kauf kann meistens zwischen drei unterschiedlichen Datenformaten ausgewählt werden, die sich hauptsächlich dadurch unterscheiden, auf welchen mobilen Plattformen sie gelesen werden können. So können geschützte PDF-Dateien nur auf Geräten mit PalmOS gelesen werden, für PocketPCs ist der Microsoft Reader oder der MobiPocket Reader erforderlich (s. Abb. 2.10).

2.3 DRM-Systeme

■ ■ ■

119

Abb. 2.10: Unterstützte eBook-Formate bei ebook.com

Im Folgenden konzentrieren wir uns auf den Download geschützter Adobe PDF-Dateien. Der verwendete Mechanismus ist dem des Windows Media Rights Managers sehr ähnlich: Zu dem geschützten eBook gehört zusätzlich ein Rechteobjekt in Form einer so genannten ETD Datei, die die vom Verlag vergebenen Nutzungsrechte nebst dem zur Entschlüsselung notwendigen symmetrischen Schlüssel in Form einer XML-Datei enthält. Der Adobe Reader kann diese XML-Datei interpretieren und daraufhin beispielsweise den Ausdruck der Datei verweigern. Um den Adobe Reader tatsächlich für eine DRM-geschützte PDFDatei nutzen zu können, muss er zunächst dafür „aktiviert“ werden. Im Rahmen der Aktivierung authentifiziert sich der Kunde als rechtmäßiger Eigentümer des eBooks und gibt gleichzeitig an, auf welchem Endgerät er das eBook nutzen möchte. Dazu wird eine Verbindung zu einem von Adobe betriebenen Server hergestellt und dort die geschützte Datei an den Reader auf einem bestimmten Endgerät gekoppelt. Der zur Entschlüsselung des geschützten PDF-Files benötigte Schlüssel wird dann vom Adobe Server mit einem Endgerätespezifischen Public Key verschlüsselt und im Rahmen der ETD-Datei an den Reader weiter gereicht. Für die Aktivierung ist zusätzlich eine Authentifikation des Nutzers mit Username (so genannte „AdobeID“) und Passwort beim AdobeServer erforderlich, Diese werden einmalig im Zuge erstmaligen Aktivierung eines Adobe-Readers vereinbart (s. Abb. 2.11). Alternativ kann die Authentifikation auch mit Hilfe des webbasierten Authentifikationsdienstes Microsoft Passport erfolgen. Das Adobe Format erlaubt für ein eBook nur die Erstellung von bis zu drei Lizenzen. Ein eBook im geschützten PDF-Format kann also nur auf bis zu drei Endgeräten gelesen werden.

120

■ ■ ■

2 Mediensicherheit

Abb. 2.11: Aktivierung des Adobe Readers via AdobeID und Passwort

2.3.5 Ökonomische und Rechtliche Aspekte Bei einer Gesamtbewertung von DRM-Systemen reicht der Blick allein auf die technischen Aspekte nicht aus. Ökonomische und rechtliche Aspekte gehören zu den wichtigsten Treibern dieser neuen Technologie und werden ihre Zukunft entscheidend mitbestimmen. 2.3.5.1 Marktpotenzial Auf den ersten Blick erscheint der ökonomische Nutzen von DRM Systemen offensichtlich: Sie ermöglichen den Verkauf medialer Inhalte über das Internet, ohne dabei die Möglichkeit aus der Hand zu geben, die Weitergabe der Inhalte zu kontrollieren. Die Gegner von DRM-Systemen argumentieren jedoch, dass durch die Möglichkeit des kostenlosen Downloads und der Weitergabe in Tauschbörsen auch eine Werbeplattform für die Erzeuger der Inhalte besteht. Vielen Internet-Nutzern jedoch ist die Idee eines kostenpflichtigen Downloads an sich schon fremd, und umso weniger sind sie mit den mit DRMSystemen einher gehenden, weiteren Einschränkungen ihrer Nutzungsrechte einverstanden. So könnte es passieren, dass sich diese Nutzer ganz von den bestehenden Vertriebskanälen abwenden. Leider gibt es in diesem Umfeld nur sehr wenige wirklich verlässliche Umsatzzahlen. Unbestritten erscheint jedoch, dass mit der breiten Verfügbarkeit breitbandiger Internet-Anschlüsse in den letzten Jahren vor allem die Verkäufe von CD-Singles rapide eingebrochen sind. Portale zum legalen, kostenpflichtigen Download von Musik aus dem Internet wie die oben beschriebenen musicload.de oder iTunes scheinen hier, auch durch massive Werbemaßnahmen, langsam Abhilfe zu

2.3 DRM-Systeme

■ ■ ■

121

schaffen. Trotzdem erscheint der Download-Markt für digitale Musik im Moment noch weit weg von seinem eigentlichen Potenzial. Der Verkauf von e-Books über das Internet befindet sich noch in der Anfangsphase und bildet im Moment, verglichen mit dem klassischen Buchverkauf, noch einen Nischenmarkt. Es muss abgewartet werden, inwieweit sich e-Books auf dem Markt werden etablieren können, was nicht zuletzt auch von der Entwicklung bei den verwendeten mobilen Endgeräten, also PDAs, Handys u. A. abhängt. Ebenfalls noch in den Kinderschuhen steckend, aber (nicht zuletzt durch die Existenz eines offenen Standards für mobiles DRM) mit wesentlich größerem Potenzial ausgestattet, präsentiert sich das mobile Umfeld. Durch die Entwicklung immer leistungsfähigerer Endgeräte, gekoppelt mit der fortschreitenden Weiterentwicklung der Mobilfunknetze, können hier große Umsatzchancen für Mobile Content Provider prognostiziert werden. 2.3.5.2 Urheberrecht Bei der Meinungsbildung über DRM-Systeme und ihrer Bewertung dürfen auch die rechtlichen Aspekte nicht außer Acht gelassen werden: Wer sich eine vom Urheber nicht autorisierte Kopie etwa eines Musikstücks aus dem Internet lädt, muss wissen, dass er sich keineswegs in einer rechtlichen Grauzone aufhält, sondern tatsächlich eine rechtswidrige Handlung begeht, da er damit gegen das Urheberrecht verstößt. DRM-Systeme können somit sogar ein Stück Rechtssicherheit für den Kunden schaffen, da bei diesen Kopien klar ist, dass sie authorisiert sind und der Download legal ist. Inwieweit die Nutzungsbeschränkungen bei einer legal erworbenen Kopie mit dem geltenden Recht vereinbar sind, muss im Einzelfall entschieden werden: Nach geltender Rechtslage in Deutschland dürfen von einer Musik-CD (anders als bei einer Software-CD) bis zu sieben Kopien erstellt werden (sofern dafür kein Kopierschutzmechanismus umgangen werden muss), allerdings dürfen diese nicht weiter verkauft werden. 2.3.5.3 Datenschutz Die Kunden eines DRM-Systems geben eine große Menge an Daten an den Betreiber des DRM-Systems weiter – zum Teil wissentlich, zum Teil auch unwissentlich (vgl. hierzu [GP]). Über die anfängliche Registrierung und den Bezahlvorgang ist der Kunde für den Betreiber vollständig identifizierbar und das Erstellen eines Kundenprofils mit den bevorzugten Inhalten ohne weiteres möglich. Weitere Verknüpfungs-

122

■ ■ ■

2 Mediensicherheit

möglichkeiten ergeben sich, wenn der Bezahlvorgang zum Beispiel in Verbindung mit einem Bonusprogramm erfolgt, das auch für den Einkauf anderer Güter eingesetzt wird. Darüber hinaus hinterlässt der Kunde weitere Datenspuren, etwa in Form des verwendeten Betriebssystems, Browsers, etc. Laut [GP] werden von aktuellen DRM Systemen mehr Daten erhoben, als zur bloßen Abwicklung der Transaktion nötig wäre. Auch wenn diese Daten – zumindest in Deutschland – nicht ohne Zustimmung der Betroffenen weiter gegeben werden dürfen, sollten sich Kunden von DRM-Systemen darüber bewusst sein, dass sie auch durch die Nutzung eines DRM-Systems einen Teil ihrer Privatsphäre preisgeben. Auf der anderen Seite kann ein transparenter Umgang mit dem Kundendaten und ein offener Dialog zwischen Betreibern und Kunden über das Problem des Datenschutzes das Vertrauen und die Akzeptanz dieser Systeme weiter erhöhen.

2.4 Ausblick Wie die vorangehenden Seiten gezeigt haben, sind viele der technischen Probleme der Mediensicherheit noch nicht vollständig gelöst, vor allem was digitale Wasserzeichen angeht. Manche Autoren wie F. Petitcolas sprechen in diesem Zusammenhang sogar von einer „Illusion of progress“, welche durch die große Zahl an Veröffentlichungen in diesem Bereich erzeugt wird, und bezweifeln die prinzipielle Lösbarkeit der anstehenden Probleme. Man sollte jedoch in diesem Zusammenhang nicht vergessen, dass bei Digitalen Wasserzeichen, anders als bei klassischen Anwendungsfeldern der IT-Security, auch eine nicht ganz perfekte Sicherheit ausreichend sein kann: Gelingt es beispielsweise 0,1% der Kunden eines Anbieters, der digitale Bilder im Internet zum Download anbietet, mit hohem technischen Aufwand die Wasserzeichen in den Bildern zu entfernen, kann dies für den Anbieter eine durchaus noch akzeptable Quote sein. Gerade bei digitalen Wasserzeichen ist also je nach Einsatzgebiet eine sorgfältige Kosten/Nutzen Analyse gefragt. Bei DRM-Systemen hingegen fehlt in erster Linie die Kundenakzeptanz. Das Verhältnis von Kunden und Anbietern von durch DRMSysteme geschützten Daten scheint geprägt von gegenseitigem Misstrauen. Gefragt sind hier vor allem auf Anbieterseite eine größere Transparenz bei den eingesetzten Verfahren und eine größeres Vertrauen in den Kunden. Auf Kundenseite fehlt zum Teil noch die Einsicht in die Notwendigkeit des Schutzes des Urheberrechts und der für die Erstellung von Content nötigen Investitionen. Alternative Ansätze zu den diskutierten DRM-Systemen wie das PotatoSystem [Pot], das

2.4 Ausblick

■ ■ ■

123

ganz auf restriktive DRM-Maßnahmen (also die Verhinderung illegalen Nutzerverhaltens) verzichtet und stattdessen legales Nutzerverhalten belohnt, scheinen bislang nur Nischenmärkte abseits des „Mainstream“ bedienen zu können. Mit einem weiteren Fortschreiten der öffentlichen Diskussion über DRM-Systeme könnten aber auch solche neuartigen Ansätze für ein größeres Publikum interessant werden.

Literatur [Bec] [Beu] [Bl] [BS] [Cha] [CKLS]

[CMB] [DiLa] [Dit] [DBS]

[DTS]

[FK] [Fri]

[GP]

[GrEb]

124

■ ■ ■

E. Becker et al. (Ed.): Digital Rights Management–Technological, Economic, Legal and Political Aspects, Springer-Verlag 2003 A. Beutelspacher, H. B. Neumann, T. Schwarzpaul: Kryptografie in Theorie und Praxis, Vieweg 2005 R. Bless et al.: Sichere Netzwerkkommunikation, Springer-Verlag 2005 D. Boneh, J. Shaw: Collision–Secure Fingerprinting for Digital Data. Proc. CRYPTO 95, Vol. 963 of LNCS, pp. 452–465, Springer-Verlag 1995 D. Chaum: Blind Signatures for Untraceable Payments. Proc. CRYPTO 82, pp. 199203, Plenum Press 1983 I. J. Cox, J. Kilian, T. Leighton, T. Shamoon: A Secure, Robust Watermark for Multimedia, Proc. First International Workshop on Information Hiding, Vol. 1174 of LNCS, pp. 251–263, Springer-Verlag 1996 I. J. Cox, M. L. Miller, J. A. Bloom: Digital Watermarking, Academic Press 2002 J. Dittmann, A. Lang: StirMark Benchmark for Audio, https://amsl-smb.cs.uni-magdeburg.de/smfa//allgemeines.php J. Dittmann: Digitale Wasserzeichen–Grundlagen, Verfahren, Anwendungsgebiete, Springer-Verlag 2000 J. Dittmann, A. Behr, M. Stabenau et al.: Combining digital watermarks and collision–secure fingerprints for digital images, Proceedings of SPIE Conference on Security and Watermarking of Multimedia Contents, San Jose, USA, 1999. Y. Dai, S. Thiemert, M. Steinebach: Feature-based watermarking scheme for MPEG-I/II video authentication. Proceedings of SPIE Conference on Security, Steganography, and Watermarking of Multimedia Contents VI, San Jose, USA, 2004 B. Fuhrt, D. Kirovski (Ed.): Multimedia Security Handbook, CRC Press 2004. J. Fridrich: Security of fragile authentication watermarks with localization. Proceedings of SPIE Conference on Security and Watermarking of Multimedia Contents IV, San Jose, USA, 2002 R. Grimm, S. Puchta: Datenspuren bei der Nutzung von Digital Rights Mangement Systemen, Datenschutz und Datensicherheit (DuD) 30 (2006), Nr. 2, pp. 74–79. R. Grosbois, T. Ebrahimi: Watermarking in the JPEG 2000 Domain, JPEG 2000 domain, Proc. IEEE Workshop on Multimedia signal processing, pp. 35, 2001.

2 Mediensicherheit

[HW]

T. Hauser, C. Wenz: DRM Under Attack: Weaknesses in Existing Systems, in: [Bec], pp. 206–223. [Ian] R. Iannella: Open Digital Rights Language (ODRL), Version 1.1, http://www.w3.org/TR/odrl/ [Kim] H. J. Kim: Audio Watermarking Techniques, Pacific Rim Workshop on Digital Steganography, Kyushu Institute of Technology, Kitakyushu, Japan, July, 2003. [KJB] M. Kutter, F. Jordan, F. Bossen: Digital Signature of Color Images using Amplitude Modulation, Proceedings of SPIE Conference on Storage and Retrieval for Image and Video Databases, Vol. 3022, pp. 518–526, San Jose, USA, 1997 [Kun] T. Kunkelmann: Sicherheit für Videodaten, Vieweg-Verlag 1998 [Min] F. C. Mintzer et al., Toward on-line, worldwide access to Vatican Library materials, IBM Journal of Research and Development, Vol. 40, No. 2 (1996) [MOV] A. J. Menezes, P. van Oorschot, S. Vanstone: Handbook of Applied Cryptography, CRC Press 1997 [MS] http://www.microsoft.com/windows/windowsmedia/howto/articles/ drmarchitecture.aspx [OMA] Open Mobile Alliance, DRM Architecture, Candidate Version 2.0, September 2005, http://www.openmobilealliance.org/release_program/drm_v2_0.html [OMAR] OMA DRM Rights Expression Language, Candidate Version 2.0, September 2005, http://www.openmobilealliance.org/release_program/drm_v2_0.html [Pet] F. Petitcolas: Digital Watermarking, in: [Bec], pp.81–92. [Pet2] F. Petitcolas: Stirmark Benchmark 4.0, http://www.petitcolas.net/fabien/watermarking/stirmark/ [Pot] PotatoSystem Homepage;, http://www.potatosystem.com /info/ger/ [QN] L. Qiao, K. Nahrstedt: Comparison of MPEG Encryption Algorithms, IEEE Journal on Computer Graphics and Applications, Special Issue on Data Security in Image Communication and Networks, Vol. 22, No. 4 (1998), pp. 437–448. [Schn] B. Schneier: Applied Cryptography, Wiley 1996 [TZFS] S. Thiemert, S. Zmudinski, L. Croce Ferri, M. Steinebach: Digitale Wasserzeichen zum Integritätsschutz von Multimediadaten, in: "Education, Research and New Media–Chances and Challenges for Science", 10. IuK-Frühjahrstagung, 2004 [UP] A. Uhl, A. Pommer: Image and Video Encryption, Springer-Verlag 2005 [XRM] eXtensible Rights Markup Language Version 2.0, http://www.xrml.org

2.4 Ausblick

■ ■ ■

125

3 Multimedia-Netze Roland Kiefer

3.1 Einführung Das Internet als Echtzeit-Transportnetz für bandbreitehungrige Multimedia-Applikationen? Das Internet als Ersatz für das klassische Telefonnetz? Das Internet als zukünftige Konkurrenz zum Kabel- oder Satellitenfernsehen („IP-TV“)? Das Internet als die vielbeschworene Multimedia-Plattform mit nur einem Netzkonzept für alle Dienste? Dass solche Szenarien noch Mitte der 90-er Jahre vielfach belächelt und als realitätsferne Visionen abgestempelt wurden, lag an dem grundlegenden Transportkonzept des Internets, das eine denkbar schlechte Ausgangsbasis für Echtzeit-Applikationen wie die Übertragung von Sprache oder Video bietet. Das Telefonnetz wurde für die Sprachübertragung konzipiert, alle Varianten der Datennetze für die reine Datenübertragung. Das Ziel aller Bemühungen: ein Netz mit einer einheitlichen Infrastruktur für alle Dienste, das so genannte konvergente Netz. Das Internet als paketvermitteltes „best-effort“-Netz war ursprünglich für die asynchrone Übertragung von Daten gedacht. Es leidet konzeptionell darunter, dass die Laufzeiten weder absolut noch relativ zuverlässig vorhersagbar sind. Die Datenpakete einer Ende-Ende-Verbindung können unterschiedliche Wege durch das Netz nehmen. Aber auch bei gleichem Weg der einzelnen Pakete sind die Verarbeitungszeiten innerhalb der Router und damit die EndeEnde-Laufzeit nicht konstant. Jedes einzelne Paket enthält die Adressierungsinformationen, die in jedem Router ausgelesen und weiterverarbeitet werden müssen. Die Transportströme der einzelnen Applikationen teilen sich somit die begrenzten Ressourcen nicht nur zwischen, sondern auch innerhalb der Netzkoppelelemente. Ein solches Netz ist für Applikationen, die auf Echtzeit-Transport angewiesen sind, ohne zusätzliche Maßnahmen nicht geeignet. Die Ressourcen des klassischen Telefonnetzes, das zu immer höheren Bandbreiten bis in den Gigabit-Bereich hin entwickelt wurde,

3.1 Einführung

Paketvermittlung

■ ■ ■

127

Leitungsvermittlung

128

■ ■ ■

werden die nach dem grundlegend anderen Prinzip der Leitungsvermittlung zugeteilt und verwaltet. Der leitungsvermittelte Ansatz stellt den jeweiligen Applikationen oder verbundenen Netzen auf die Bandbreiteanforderung zugeschnittene und für die Dauer der Verbindung exklusiv reservierte Überragungskapazität zur Verfügung. Alle Pakete eines Streams fließen über den gleichen Weg, die Laufzeit ist während der gesamten Verbindungsphase konstant, die Vermittlungsressourcen fest reserviert und die Dienstequalität (Quality of Service) exzellent. Weder ist eine nennenswerte Zwischenpufferung erforderlich, noch muss die Paketlänge angepasst werden. Die Exklusivität der Reservierung wird bis zum finalen Verbindungsabbau auch dann aufrechterhalten, wenn die angeforderten und zugewiesenen Ressourcen temporär nicht benötigt werden. Dies ist beispielsweise bei den Gesprächspausen innerhalb eines Telefonats der Fall oder bei Applikationen, die schwankende Bandbreiten erzeugen. Diese Verschwendung des wertvollen Rohstoffs Bandbreite ist der Knackpunkt, an dem das leitungsvermittelte Konzept zugunsten des paketvermittelten Ansatzes deutlich an Punkten verliert. Ein Paketnetz darf deutlich überbucht werden, die Summe aller Spitzenlasten aller Sender darf durchaus die zur Verfügung stehende Gesamtbandbreite überschreiten. Statistisch ist es sehr unwahrscheinlich, dass alle Sender zur gleichen Zeit mit ihrer maximalen Datenrate senden. Wie Untersuchungen von Internet-Providern zeigen, verliert die Aufsummierung des Datenverkehrs aller zu einem bestimmten Zeitpunkt angeschlossenen Teilnehmer den für Internetverkehr typischen burstartigen Charakter und zeigt einen geradförmigen Verlauf. Das schlechtere Konzept des paketvermittelten Ansatzes macht angesichts der Marktgegebenheiten das Rennen – nichts ungewöhnliches und aus anderen Bereichen sehr wohl bekannt. Allerdings muss den beschriebenen Schwächen des paketvermittelten Ansatzes durch zusätzliche Maßnahmen gegengesteuert werden, um eine akzeptable Dienstequalität zu erreichen. Neue Applikationen wie Web-basierte Datenbanken, Voice-overIP, Multimedia-e-Commerce oder das Streaming multimedialer Inhalte haben den Charakter des Internets innerhalb weniger Jahre grundlegend verändert. Der Siegeszug des World Wide Web (WWW) zu einem konvergenten Netz ist nicht mehr aufzuhalten. In den Anfangszeiten des Internet, in denen wir uns historisch gesehen immer noch befinden, ist die wirtschaftliche und technisch sinnvolle Konvergenz der Netze auf Basis des Internet-Protokolls das zentrale Thema.

3 Multimedia-Netze

Mit dem Schlagwort der Netzkonvergenz sind viele Fragestellungen verbunden: x Auf welchen Transporttechnologien werden die High-Speed-Netze der Zukunft basieren? Kapitel 3.2 nimmt hierzu Stellung. x Wie differenzieren die Netze am besten zwischen nicht zeitkritischen Daten und Diensten, die eine Echtzeitbeziehung zwischen Sender und Empfänger erfordern? Kapitel 3.3 widmet sich der Netzarchitektur zur Sicherstellung einer gewünschten QoS. x Wie kann das klassische leitungsvermittelte Netz in das paketvermittelte Internet überführt werden. Kapitel 3.4 gibt einen Ausblick in Architektur und Dienste des Next Generation Network (NGN), stellt die Grundzüge der Referenzapplikation Voice-over-IP vor und diskutiert mit IPv6 und Multicast zwei zentrale Ansätze des zukünftigen Internet In diesem Kapitel lassen wir die Lokalen Netze außer Betracht. Aufgrund der klaren Besitzverhältnisse sind Anpassungen der Netzarchitektur an neue Applikationen (zum Beispiel Streaming oder Voiceover-IP) in einem LAN viel leichter umzusetzen als in einem WAN. Nachfolgend aufgezeigte Problemstellungen sind im LAN deutlich einfacher lösbar.

3.2 Multimedia-Transportnetze 3.2.1 Einleitung Die Netzinfrastruktur in Weitverkehrs (WAN)- und Metronetzen (MAN)–die Datenschläuche für Telefonie und (Internet)-Daten–basiert heute im wesentlichen auf zwei Schlüssel-Technologien zum IPTransport: x im WAN auf der der Synchronen Digitalen Hierarchie SDH (zunehmend seltener in Kombination mit dem Asynchronen Transfer Modus ATM) x im MAN ebenfalls auf SDH, aber auch auf Ethernet, speziell in den Varianten Gigabit und 10 Gigabit. Ethernet tastet sich aus dem LAN ins MAN vor und konkurriert dort mit den etablierter SDH-MANRingen Die Access-Technologien wie die vielen Varianten der DSL-Familie, ISDN, UMTS, WIMAX oder auch wiederum Ethernet werden hier nicht weiter betrachtet. Abbildung 3.1 zeigt die heutige Netzlandschaft im Überblick.

3.2 Multimedia-Transportnetze

■ ■ ■

129

Abb. 3.1: wichtige Netztechnologien in LAN, MAN und WAN

3.2.2 High-Speed in Metronetzen

Ethernet vs. SDH

130

■ ■ ■

In Metronetzen konkurriert das eher unzuverlässige Ethernet seit wenigen Jahren mit der außerordentlich zuverlässigen SDH-Technologie. Dieser Konkurrenzkampf ist auch unter dem Gesichtspunkt der Netzevolution spannend. Das Rückgrat lokaler Netze ist heute mit überwältigender Mehrheit Ethernet in Geschwindigkeitsvarianten von 10/100 Mbit/s bis 10 Gbit/s. Ethernet bewährt sich im LAN als einfach zu wartende und kostengünstige Technologie durchgängig zur Anbindung von Arbeitsplatzrechnern, High-End-Servern und auch im Backbone-Bereich. Die Anbindung an das Backbone-Netz eines City-Carriers erfolgt im Allgemeinen über Mietleitungen deutlich niedrigerer Geschwindigkeit. Der Hemmschuh ist dabei vor allem, dass die Ethernet-Signale in eine andere Transport-Technologie umgesetzt werden müssen. Die Promoter des Ethernet-Marsches in Richtung WAN sprechen von der „first mile“, die es zu überbrücken gilt. Ein unter Marketinggesichtspunkten geschickt gewählter Begriff, der die „last mile“-Diskussion der letzten Jahre um die beste Access-Technologie aus Sicht der WANBetreiber aufgreift. Die LAN-LAN-Kopplung größerer Unternehmensnetzwerke innerhalb des MAN wird sinnvollerweise so dimensioniert, dass zumindest

3 Multimedia-Netze

die Durchschnittsbelastung des Backbones ohne größeren Flaschenhals übertragen werden kann. Eine aufgrund dieser Überlegung sinnvolle Bandbreite von beispielsweise 155 Mbit/s (STM-1, vgl. Kap. 3.2.3.1) anzumieten, scheitert jedoch vielfach an den extrem hohen Kosten. Also begnügt man sich mit kostengünstigeren Mietleitungen niedrigerer Kapazität und optimiert, d. h. reduziert die Datenzugangspolitik am Übergang zum Access-Netzwerk. Der sehr unerfreuliche Flaschenhals bleibt jedoch bestehen. Optimistischer stellt sich die Situation dar, wenn die LAN-Technologie Ethernet auch im Access-Bereich zum WAN Verwendung findet. Der direkte Transport der Ethernet-Pakete–evtl. noch im Zusammenspiel mit dem später beschriebenen WDM-Verfahren – ist eine ausgezeichnete Alternative mit beeindruckenden Perspektiven. Der direkte Transport der IP-Pakete vom LAN ins WAN kann bei einer Punkt-zu-Punkt-Verbindung zweier Unternehmensstandorte ohne IP-Routing bewerkstelligt werden. Geswitchte Netze sind somit relativ einfach auch über größere Entfernungen realisierbar. Der hohe Invest in Router entfällt, die Virtuellen LANs (VLAN) können einfach erweitert werden, geografisch weit entfernte Stadtteile, Vororte oder Nachbarstädte können so verbunden werden wie heute benachbarte Firmengebäude. Zugangsmultiplexer entfallen und die Signale werden nur noch über Add-Drop-Multiplexer eingespeist und entnommen. Erklärtes Ziel vieler Service-Provider ist es, Ethernet-basierte Lösungen in großem Maßstab in Metro-Netzen einzuführen („MANEthernet“). Verteilte Standorte eines Unternehmens können mittels Tunneling und VLAN-Zuordnung transparent gekoppelt werden. Aus Sicht der Kunden der Service Provider erscheint das gesamte Netz als Layer-2-Domäne. Das Metro-Ethernet-Forum ([METR]) hat Ethernet-Dienstklassen definiert, um typische Bandbreiteprofile für Ethernet-Services zuverlässig garantieren und optimiert transportieren zu können („CarrierEthernet„). Hierzu werden ähnlich wie bei Frame Relay Werte für die durchschnittliche Bitrate und zulässige Belastungsspitzen definiert und klassifiziert, mit deren Hilfe kundenspezifische Verkehrsprofile optimiert auf das Netz abgebildet werden können. Die Standardisierung von 10 Gigabit-Ethernet im Jahre 2002 hat die Möglichkeiten von Ethernet stark erweitert. 10G-Ethernet: Evolution oder Revolution? Obwohl 10G-Ethernet (abgekürzt 10GBASE-x, wobei x als Platzhalter für die diversen Varianten steht) nur nach einer simple Evolution in der Geschwindigkeit aussieht, wird es die Netzlandschaft nicht nur im LAN, sondern auch im Access und MAN/WAN-Bereich revolutionär verändern.


„Carrier-Ethernet“

10G-Ethernet

■ ■ ■

131

Die wesentlichen Charakteristika im Überblick: x Das grundlegende CSMA/CD-Zugriffsverfahren wird nicht mehr unterstützt, es sind ausschließlich Voll-Duplex-Verbindungen zulässig. x Die Standardisierung für die Übertragung auf Kupferkabeln hoher Güte ist in Arbeit (10 GBase-T). Die Übertragung solch hoher Datenraten ist nur mit ausgeklügelten mehrstufigen Codierverfahren möglich. x minimale und maximale Länge des Ethernet-Rahmens sind unverändert übernommen worden. x Das Rahmenformat wird ebenso beibehalten wie die LinkAggregation (Port-Trunking) zur Verknüpfung mehrerer Verbindungen zu einem logischen Kanal höherer Geschwindigkeit x 10G-Ethernet unterstützt sternförmige Netzwerktopologien mit Punkt-zu-Punkt-Verbindungen. Die Arbeitsgruppe 802.3ae (die High Speed Study Group) definiert– strategisch geschickt–auf der Physical Layer von 10G-Ethernet auch ein SDH/SONET-Interface mit einer etwas geringeren Bitrate. Dies ist ein Frontalangriff auf die Domäne von SDH/SONET speziell in den Netzen von lokalen Service-Providern und City-Carriern. Deren Geschäftsmodell basiert überwiegend auf der Vermietung von Festverbindungen mit definierten Standard-Bandbreiten oder auf der Bereitstellung von Glasfasern (dark fiber). Das SDH/SONET-kompatible 10G-Interface bietet sich auch an, weil 10G-Ethernet recht nahe an der SDH-Bitrate eines STM-64-von 9,953280 Gbit/s liegt. Die Anpassung der physikalischen Geschwindigkeit auf die MAC-Geschwindigkeit erfolgt durch „künstliche Verlangsamung“, indem der bei Ethernet unverzichtbare Inter-Frame-Gap (IFG) zwischen zwei Rahmen zeitlich vergrößert wird. Dazu ermittelt der MAC-Controller die aktuelle Ethernet-Paketlänge und passt den IFG dynamisch an. Den ausfallsicheren Glasfaserringstrukturen der SDH stellt Ethernet die Resilient Packet Rings (RPR)-Technologie entgegen (ITU-T 802.17). RPR-Ringe zeichnen sich insbesondere durch die Fähigkeit aus, im Falle eines Leitungsbruchs innerhalb von Millisekunden den IP-Datenfluss wieder herzustellen. SDH beherrscht dies bereits seit langen Jahren. Jeder Knoten im RPR-Ring, der üblicherweise als Doppelring installiert wird, kennt alle weiteren Ringknoten und kann auf Änderungen der Topologie dynamisch reagieren. Abbildung 3.2 zeigt den Einsatz von Ethernet im MAN. Bandbreitenintensive Applikationen stellen extreme Anforderungen an die Netzinfrastruktur bzw. werden ohne Ausbau der Bandbreite-Kapazitäten gar nicht durchsetzungsfähig sein.

10G-Ethernet: kompatibel zu SDH

132

■ ■ ■

3 Multimedia-Netze

Triple Play

Um ihre Netze bei steigenden Anforderungen an Bandbreite und Dienstqualität zukunftstauglich und gleichzeitig kostengünstig weiter zu entwickeln, sind viele Netzbetreiber gezwungen, ihre Betriebskosten deutlich zu reduzieren. Dies spricht für den weiteren Ausbau der Netze auf Basis von Ethernet mit dem Fernziel, ein „All-IP-Netz“ zu schaffen. Die Provider setzen für die Zukunft auf „Triple Play„, das heißt sie bieten Telefonie-, Internet- und Multimedia-Lösungen aus einer Hand über einen Netzzugang–und hoffen mit neuen Angeboten auf steigenden Medienhunger ihrer Kunden. Telefonleitungen, über die Übertragungsraten von bis zu 50 Mbit/s (VDSL) fließen werden, sind Bestandteil dieser Infrastruktur. Der „digitale Alltag“ hält Einzug – und liefert genügend Diskussionsstoff über die Auswirkungen auf gesellschaftliche Entwicklungen.

Abb. 3.2: Ethernet-Ringe im MAN

3.2.3 High-Speed im Weitverkehrsnetz 3.2.3.1 Einführung in die SDH Seit Beginn der sechziger Jahre basierten die Weitverkehrsverbindungen im wesentlichen auf der Plesiochronen Digitalen Hierarchie (PDH) mit den Hierarchiestufen bei 2/ 8/ 34 und 140 Mbit/s („europäischer Standard“, E1, E2, E3 und E4) bzw. 1,5/ 6,3 und 45 Mbit/s („nordamerikanischer Standard“, T1,T2 und T3). Einer der größten Nachteile: es ist


■ ■ ■

133

Container, POH,SOH

134

■ ■ ■

relativ umständlich und unwirtschaftlich, einen 64 kbit/s-Teilnehmerkanal (ISDN) aus einem 140-Mbit/s-Signal gezielt „herauszufischen“. Das Signal muss komplett aufgebrochen werden, durchläuft alle Multiplexerstufen und wird dann wiederum neu gemultiplext. In der Synchronen Digitalen Hierarchie SDH ist hingegen eine direkte Entnahme der einzelnen Zubringersignale möglich. Zudem ist der aufgrund des plesiochronen Funktionsprinzips erforderliche Stopfprozess beim Multiplexen mehrerer Zubringer bei höheren Bitraten nur mit großem Aufwand realisierbar und für höchste Bitratenanforderungen nicht geeignet. SDH und das insbesondere in Nordamerika verbreitete SONET (Synchronous Optical Network) sind mit kleinen Abstrichen kompatibel zueinander und auf den für interkontinentale Verbindungen maßgeblichen höheren Hierarchien fast identisch. Die SDH wandelt das starre Übertragungsnetz auf Hardware-Basis in flexible, softwaregestütze Systeme. SDH-basierende Netzkomponenten übernehmen einen deutlichen Teil der Netzintelligenz, so dass sich ein wirklich dynamisches Netz entwickeln kann. In den „Verladebahnhöfen“ der SDH, den Cross-Connects, wird die zu transportierende „Ware“ (= Payload) in größere oder kleinere Container standardisierter Größe (= Virtueller Container) gesteckt (= Mapping) und bei Bedarf mehrere Container in eine noch größere Einheit verpackt (= Tributary Unit Group). Informationen über Art und Größe des Containers begleiten ihn über den gesamten Transportpfad (= Path Overhead, POH), eventuelle Bitfehler während des Transports werden erkannt und den Systemkomponenten mitgeteilt, so dass der Netzbetreiber jederzeit die Qualität der Übertragung beurteilen kann. Der POH erlaubt es beispielsweise, Übertragungsfehler abschnittsweise zu erkennen, den korrekten Weg des Nutzsignals zu überprüfen und die Art der Daten innerhalb des Containers anzuzeigen. Desweiteren sorgt der POH dafür, dass im Falle extremer Fehlersituationen, das Netz auf einen Ersatzweg für den betroffenen Container umschaltet. Ein Teil des Rahmens wird dazu verwendet, nur abschnittsweise gültige Informationen zwischen SDH-Netzknoten zu übertragen (Section Overhead, SOH). Zusätzlich zur Überwachung von Fehlern und Qualitätslimits überträgt der SOH Schaltbefehle (z. B. Um- oder Neukonfiguration) des Netzmanagement und meldet Fehlverhalten an das Netzmanagement weiter. Abbildung 3.3 zeigt den Aufbau des Synchronen Transport Moduls STM-1.

3 Multimedia-Netze

Der STM-1-Rahmen wird üblicherweise in der bildlichen Darstellung mit 9 Zeilen zu je 270 Byte strukturiert. Jedes Byte an einem Kreuzungspunkt von Zeile und Spalte wird pro Sekunde 8000 Mal ausgelesen und besitzt somit eine Übertragungskapazität von 64 Kbit/s, die Kompatibilität zum herkömmlichen ISDN ist sichergestellt. Die STM-1-Bitrate berechnet sich aus diesen Angaben zu 155,52 Mbit/s Abbildung 3.4 erläutert das Pointer-Prinzip der SDH.


Abb. 3.3: Aufbau des SDH-Transportmoduls (STM-1)

Abb. 3.4: Pointer in der SDH

■ ■ ■

135

AU- und TU-Pointer

Der AU-Pointer (= Zeiger) zeigt auf den Beginn des größten Containers (High-Order-Container) und erlaubt ihm, sich innerhalb des Transportmoduls in weiten Grenzen frei zu bewegen. Der Vorteil: der Nutzlast-Container ist vom übergeordneten Transportrahmen entkoppelt und kann dadurch sehr flexibel entnommen und in den SDHSystemen neu verschaltet werden. Aufwändige Pufferspeicher zur Zwischenspeicherung entfallen. Der Tributary-Unit-Pointer (TU-Pointer) verweist auf den Platz innerhalb des Moduls, den der Low-OrderContainer niedrigerer Bitrate aktuell einnimmt. Im Falle extremer Störungen der Übertragung kann das Synchrone Transportmodul automatisch und unterbrechungsfrei und ohne Eingriff des übergeordneten Netzmangements auf einen vordefinierten Ersatzweg umgeschaltet werden. Diese Art des Schutzmechanismus durch Umschaltung auf fest reservierte Reservekapazitäten wird auch als Path- oder Section-Protection bezeichnet. Im Gegensatz dazu stehen die Restoration-Verfahren. Sie implementieren Schutzmechanismen, die erst beim Auftreten eines Fehlers freie Backup-Ressourcen suchen und den Verkehr entsprechend umleiten. 3.2.3.2 Höhere SDH-Hierarchien Die höheren SDH-Hierarchien werden durch einfaches byteweises Multiplexen von 4, 16 oder 64 STM-1-Modulen gebildet. Dadurch ergeben sich die Hierarchiestufen x x x x

Concatenation

136

■ ■ ■

STM-4 mit 622 Mbit/s STM-16 mit 2488 Mbit/s STM-64 mit 9953 Mbit/s STM-256 mit 398131 Mbit/s

Nutzlasten, deren Kapazität 140 Mbit/s überschreitet (z. B. 10 Gigabit-Ethernet oder HDTV-Übertragung höchster Qualität) können durch Verknüpfung mehrerer Container übertragen werden. Dabei werden die Nutzdaten in aufeinander folgende Rahmen geschrieben, so dass die Nutzlast einen einzelnen großen Container „sieht“. Die Container werden in einer verketteten Struktur als schneller Datenkanal mit einer um den Verkettungsfaktor erhöhten Transportkapazität zusammengefasst. Für diesen Modus hat sich die Bezeichnung STM-Nc (c = concatenated) durchgesetzt. Die später beschriebene „New SDH“ erweitert dieses Konzept. Die wesentlichen Bausteine eines SDH-Netzes sind Cross-Connects, Add/Drop-Multiplexer und Regeneratoren. Cross-Connects erlauben

3 Multimedia-Netze

die beliebige Verschaltung, Bildung und Auflösung von Transportcontainern höherer oder niedrigerer Hierarchie. Add-/Drop-Multiplexer sind an der Kundenschnittstelle angesiedelt. Die Übertragung der STM-Module erfolgt im allgemeinen optisch oder bis STM-4 auch per Richtfunk. 3.2.3.3 SONET In der synchronen Welt existieren zwei Standards: SDH und das Synchronous Optical Network (SONET). Sie sind mit kleinen Abstrichen kompatibel zueinander und auf den für interkontinentale Verbindungen maßgeblichen höheren Hierarchien fast identisch. Dies erleichtert den Übergang zwischen den unterschiedlichen weltweiten Rahmenformaten erheblich. Die SONET-Bitrate der ersten Hierarchiestufe liegt bei 51 Mbit/s und entspricht der SDH-Bezeichnung STM-0. Das Einsatzgebiet von STM-0 ist überwiegend der Digitale Richtfunk. Abbildung 3.5 vergleicht die Nomenklatur von SONET und SDH. Router mit SDH-Interface werden häufig entsprechend der SONETTerminologie bezeichnet [KIEF1]. Abb. 3.5: SDH und SONET im Vergleich

3.2.3.4 Taktung in SDH-Netzen Alle Cross-Connects werden von einer zentralen Taktquelle mit einem hochstabilen Takt mit einer Frequenzgenauigkeit von mindestens 1 10-11 versorgt. Die Primär-Referenzquellen basieren z. B. auf einem Cäsium-Normal und/oder der Anbindung an das satellitengestützte Global Positioning System (GPS). Größere Netzbetreiber verfügen über ein eigenes Taktversorgungsnetz, kleinere Betreiber beziehen ihren Takt über gemietete Standleitungen von ihren Konkurrenten.


Master-Slave-Taktung

■ ■ ■

137

Abb. 3.6: Taktverteilung in einem SDH-Netz

Die Taktverteilung erfolgt idealerweise per direkter Anbindung an den Zentraltakt, in der Praxis aus Kostengründen jedoch über eine Baumstruktur (Abb. 3.6, Master-Slave-Taktung), die Taktsignale können dabei über die vorhandene physikalische Infrastruktur wie Datensignale transportiert werden. 3.2.3.5 New SDH Die SDH wurde ursprünglich für Verbindungen mit statischen Bandbreiten entwickelt. Die Stärke der SDH, einem Dienst eine konstante Bandbreite bei ebenso konstanter Laufzeit zur Verfügung zu stellen ist dann die größte Schwäche, wenn paketbasierte Transporttechnologien über SDH übertragen werden sollen. Zwar kann die SDH einzelne Container fester Bandbreite miteinander verknüpfen, da beispielsweise die Datenraten von Ethernet und die der SDH vollkommen unterschiedliche Werte aufweisen, kann beim Füllen der Container mit Ethernet-Signalen ein Grossteil der Bandbreite nicht genutzt werden. Dies verhindert ein effizientes Interworking mit der LAN-Welt. Unterschiedliche Ansätze diverser Hersteller, diese Problematik zu lösen, haben nie marktrelevante Überzeugungskraft erreichen können. Die noch nicht durchgängig implementierten Ansätze der „New SDH“, auch Next Generation SDH (NG-SDH) genannt, definieren Mechanismen, die der SDH eine deutlich höhere Flexibilität ermöglichen. Die Plattform „New SDH“ ist durch drei Elemente bestimmt: x GFP: Generic Framing Procedure x VCAT: Virtual Concatenation x LCAS: Link Capacity Adjustment Scheme

138

■ ■ ■

3 Multimedia-Netze

Abb. 3.7: Einsatzmöglichkeiten von VCAT

GFP kapselt und verpackt unterschiedliche Rahmenformate effizient in SDH-Container. GFP ist nicht nur optimiert für Ethernetover-SDH (EoSDH), sondern berücksichtigt auch beispielsweise die Belange der Storage Area Networks (SAN), insbesondere im Hinblick auf niedrige Verzögerungszeiten. Die variable Länge des GFPRahmens erlaubt es den Providern, ihren Kunden feingranulare Bitraten anzubieten. So kann beispielsweise ein Unternehmen mit einer Gigabit-Ethernet-Anbindung eine Bandbreite von 300 Mbit/s beziehen. Der Carrier kann dadurch seine Bandbreiteressourcen viel effizienter nutzen und seinen Kunden innovative Dienste anbieten. VCAT (Abb. 3.7) ermöglicht es, eine gewünschte Anzahl von LowOrder oder High-Order-Container miteinander zu verketten. So ist für 10 Gigabit/s-Ethernet eine SDH-kompatible Schnittstelle standardisiert, die für die verkettete nahtlose Übertragung von 64 Containern mit jeweils etwa 150 Mbit/s Nutzlastanteil vorgesehen ist. Dieses VC-4-64c-Interface erleichtert den Übergang vom LAN oder MAN ins SDH-WAN erheblich. LCAS ist eng mit VCAT verbunden und erlaubt die Aktivierung und Deaktivierung einzelner VC innerhalb einer VC-Group. Die Netzelemente an beiden Enden einer Übertragungsstrecke, die eine dynamisch veränderbare Bandbreite benötigt, aktivieren bzw. deaktivieren mit Hilfe von LCAS Containereinheiten und ermöglichen so die flexible Adaption an die gewünschte Bandbreite. Das LCAS-Protokoll arbeitet quasi unterbrechungsfrei und schaltet innerhalb von maximal 50 Millisekunden um. Dadurch kann das Bandbreitereservoir, das ein Carrier seinem Kunden zur Verfügung stellt, zu bestimmten Zeiten dynamisch erhöht oder erniedrigt werden. Die LCAS-Informationen werden im High-Order-Container (Byte H4) bzw. im Low-OrderContainer (Byte K4) in bis zu 4096 aufeinander folgenden Rahmen sequentiell übertragen. [HELV] informiert ausführlich über die Einzelheiten der Protokollabläufe.


GFP

VCAT

LCAS

■ ■ ■

139

3.2.3.6 DWDM und Optische Netze Der deutsche Internet-Traffic über Peering-Knotenpunkt DE-CIX in Frankfurt hat sich 2005 innerhalb eines Jahres mehr als verdoppelt und erreicht Mitte 2006 Werte von nahezu 60 Gbit/s, exklusive des Verkehrsanteils der Deutschen Telekom AG. Stets aktualisierte Werte stellt [DECI] bereit. Die Prognosen über das Verkehrswachstum sind schwierig, unter anderem deshalb, weil die Marktakzeptanz von innovativen bandbreiteintensiven Diensten wie IPTV nur sehr schwer einschätzbar ist. Das Verfahren des Dense Wavelength Division Multiplexing (DWDM) erhöht das Transportvolumen über eine einzelne Glasfaser, an den Enden der Faser werden die riesigen Datenmengen jedoch konventionell, das heißt elektrisch weiterverarbeitet. Die rein auf elektronischen Schaltkreisen basierte Weiterverarbeitung der Signale stößt jedoch in wenigen Jahren an ihre physikalischen Grenzen. Der Ausweg aus dieser technologischen Sackgasse liegt in der Weiterentwicklung und Implementierung von optischen Netzknoten und Koppelelementen als Bausteine von Optischen Netzen. Grundlegendes hierzu findet sich zum Beispiel in [KIEF4] DWDM Ohne DWDM hätte das Wachstum des Internet in den letzten Jahren nicht bewerkstelligt werden können. Das Prinzip von DWDM ist einfach und in seiner Grundidee nicht sonderlich innovativ: unterschiedliche standardisierte Wellenlängen bzw. Frequenzen innerhalb eines festgelegten Frequenzbandes werden zur Übertragung der Nutzinformationen verwendet. DWDM erhöht die Kapazität neu verlegter oder auch bereits installierter Glasfaserleitungen um ein Vielfaches, ohne die bestehende Kabelinfrastruktur zu verändern. Dies wird dadurch erreicht, dass innerhalb eines optischen Fensters mehrere unabhängige Kanäle übertragen werden. Sind die Abstände der einzelnen Kanäle sehr gering, spricht man von DWDM (Dense Wavelength Division Multiplexing). Abbildung 3.8 zeigt das Prinzip. Bei DWDM werden innerhalb des dritten optischen Fensters zwischen 1520 und 1570 nm (entsprechend 191 bis 197 THz) mehrere optische Trägerfrequenzen – sozusagen unterschiedliche „Farben“ – mit dem zu übertragenden Signal moduliert. Die hohe Trägerfrequenz des Lichtes erlaubt das Aufmodulieren von Datenbandbreiten im Gigabit-Bereich. Bei einem typischen Kanalabstand von 0,8 nm (entsprechend 100 GHz) können 40 Kanäle auf einer Glasfaser übertragen werden, ein Abstand von 0,2 nm erhöht die Zahl der möglichen Kanäle auf

140

■ ■ ■

3 Multimedia-Netze

Abb. 3.8: Dämpfungsverlauf über der Wellenlänge mit DWDM im dritten optischen Fenster

bis zu 160. Ein DWDM-System fasst die einzelnen Farben zu einem „Daten-Regenbogen“ zusammen und überträgt sie auf einer Glasfaser. Die Trennung der einzelnen Signale erfolgt optisch mithilfe eines Prismas. Die ITU-T-Empfehlung G.692 definiert die entsprechenden Kanalraster. Der Vorteil liegt nicht nur in der inflationären Erhöhung der Übertragungskapazität, die auf einer Faser transportiert werden kann. Da sich die einzelnen Lichtsignale nicht gegenseitig beeinflussen, können gleichzeitig unterschiedliche Übertragungstechnologien mit verschiedenen Bandbreiten übertragen werden. Unabhängig von Aussehen und Format des Signals stellt DWDM jeweils einen eigenen optischen Transportkanal hoher und höchster Bandbreite zur Verfügung–ein eklatanter Vorteil, der innovative Applikationen und Dienstangebote der Netzbetreiber ermöglichen wird („Multi-Service-Netz“ im Rahmen des Next Generation Network NGN). Optische Netze Forschungen auf dem Gebiet der Photonik haben in den letzten Jahre die Grundlagen für Systemkomponenten geschaffen, die eine optische Weiterverarbeitung der Signale erlauben. Vorstellbar wäre in diesem Zusammenhang, dass in einem optischen Netz der Durchgangsverkehr und die Verkehrsströme, die weiter


■ ■ ■

141

Abb. 3.9: Optische Spiegel, dreidimensionales MEMS (Micro-Electromechanical System), Quelle: Lucent

aufgelöst und geroutet werden müssen, auf unterschiedlichen Wellenlängen transportiert werden. Optische Cross-Connects mit MEMS (Micro-Electromechanical System) als Basis gehörten zu den ersten marktreifen Produkten. Mikroskopisch kleine Spiegel ermöglichen die Umleitung eines Strahls in eine andere Glasfaser. Die Spiegel werden elektrostatisch oder durch Piezokristalle bewegt [NET]. Neben Optischen Schaltfeldern werden in Optischen Netzen auch nachfolgende Bausteine verbreitet: x Laser und Laserdioden x Wellenlängenselektoren: Faser-Bragg-Gitter, Dielektrische Filter oder Arrayed Waveguide Grating (AWG) ermöglichen es, aus einem DWDM-Strahl gezielt einzelne Wellenlängen auszukoppeln x Wellenlängenkonverter: sie setzen an Verzweigungspunkten eine ankommende Welle bestimmter Frequenz in einen anderen spektralen Wert um x Optische Verstärker: EDFA-Verstärker (Erbium Doped Fiber Amplifier), deren Funktionsprinzip auf den besonderen Eigenschaften von mit Erbium stark dotiertem Silizium beruht x Optische Dämpfungsglieder: zur gezielten Abschwächung eines Signals Tiefergehende Erläuterungen zur Funktion der Bauelemente bietet [KIEF2].

142

■ ■ ■

3 Multimedia-Netze

3.3 Quality of Service (QoS) 3.3.1 Einführung Anwendungen sind nach Abb. 3.10 klassifizierbar. Abb. 3.10: Klassifizierung in Echtzeit- und elastische Anwendungen

Traditionelle Datenanwendungen wie FTP gehören zu den elastischen Anwendungen. Die Daten werden durch längere oder schwankende Verzögerungszeiten nicht unbrauchbar. Intolerante Echtzeitanwendungen reagieren allergisch auf zu hohe Verzögerungen und verwerfen zu spät eintreffende Pakete. Intolerante Anwendungen wie zum Beispiel die Sprachübertragung, können auch ratenadaptiv reagieren, indem sie bei schlechter Netzqualität ihren Bandbreitebedarf reduzieren. E-Commerce oder SAP R/3-Anwendungen erfordern relativ wenig Bandbreiteressourcen, reagieren jedoch sensibel auf zu lange Verzögerungszeiten. In einem Best-Effort-Internet werden Applikationen weder auf ihre technischen Anforderungen noch auf ihre businessrelevanten Bedürfnisse priorisiert. Multimedia-Echtzeit-Applikationen erfordern zunächst einmal zusätzliche Bandbreite. Als Konsequenz investierten die Carrier weltweit massiv in ihre Transportnetze, in der Regel unter Einsatz der beschriebenen DWDM-Technologie. Ein Netz in dem die hohe Verfügbarkeit von Bandbreite die einzig tragende Säule ist wird früher oder später unweigerlich an seine Grenzen stoßen. Echtzeitapplikationen und Datentransfers mit hohen Volumina kämpfen nicht

3.3 Quality of Service (QoS)

■ ■ ■

143

Dienstgüte und QoS

144

■ ■ ■

nur um verfügbare Bandbreite, sondern konkurrieren auch innerhalb der Router-Warteschlangen um einen Sendeplatz. Die Konsequenz: eine Verkehrssteuerung anhand Verkehrsregeln durchzuführen wird unabdingbar, um eine anwendungsadäquate Dienstgüte zu erzielen. Leider existiert keine einheitliche Definition des Begriffs Dienstgüte oder Quality of Service. Manche Ansätze–zum Beispiel die Definition der ITU–berücksichtigen nicht nur quantifizierbare technische Parameter sondern unter anderem auch die Bedienbarkeit der für die Übertragung eingesetzten Endgeräte. In diesem Beitrag wird Dienstgüte oder Quality-of-Service (QoS) als Oberbegriff für alle Verfahren verwendet, die den Datenfluss in Netzen so beeinflussen, dass ein Dienst oder eine Applikation in einer bestimmten Qualität beim Empfänger ankommt. QoS erfordert eine Ende-zu-Ende-Sicht, eine ausreichende oder eingeschränkte Dienstgüte kann nur vom Empfänger festgestellt werden. Er wird eine schlechte Qualität oder mangelhafte Zuverlässigkeit der Übertragung bemängeln, oder sich über zu hohe Antwortzeiten beklagen. Selbstredend betrifft eine Dienstgüte auf Applikationsebene bzw. der Anwendungsschicht (OSI-Modell) alle darunter liegenden Schichten, da die tieferen Schichten jeweils als Dienstleister für die jeweils höhere Schicht fungiert. Da das Internet als Verbund von vernetzten Autonomen Systemen AS unterschiedlicher konkurrierender Betreiber keiner definierten Übertragungspolitik unterliegt, wird es domänenübergreifend nicht zuverlässig möglich sein, eine durchgängige QoS zu implementieren. Lediglich die Bildung von QoS-Domänen mit dedizierter QoS-Policy ist möglich. Aufgrund der Uneinheitlichkeit der technischen Voraussetzungen ist eine befriedigende Ende-Ende-QoS nur dann erreichbar, wenn die unterschiedlichen Verfahren zur Realisierung von QoS, die in den einzelnen Domänen eingesetzt werden, ineinander überführbar sind (QoS-Mapping). QoS sichert dem Anwender einer Applikation oder einer Protokollschicht (!) einen bestimmten Dienst in einer bestimmten messtechnisch erfassbaren, aber oft nur subjektiv beurteilten Qualität zu. Der vielleicht etwas ungewohnte Bezug auf eine Protokollschicht ist deshalb erforderlich, weil die einzelnen Protokolle der einzelnen OSISchichten unterschiedliche und ergänzende Beiträge zur QoS leisten können. Beispielsweise kann für die Übertragung von Voice-over-IP eine Priorisierung auf der IP-Ebene durchgeführt, aber nicht EndeEnde garantiert werden. Ergänzend sorgt das Real-Time-Protokoll in Verbindung mit entsprechend dimensionierten Pufferspeichern im Empfänger dafür, dass ein Ausgleich zeitlich schwankender Paketstreams erfolgt. Netz-QoS wird somit ergänzt um eine QoS-Maßnahme zwischen den Endpunkten einer Kommunikation.

3 Multimedia-Netze

Service Level Agreement Im Zusammenhang mit QoS wird auch der Begriff Service Level Agreement (SLA) verwendet. Ein SLA ermöglicht eine dienstspezifische Dienstequalität, die vertraglich zugesichert und überwacht wird. Das „Siemens Lexikon der Datenkommunikation“ [SIEM] definiert SLA wie folgt: „Ein Service Level Agreement (SLA) ist eine bilaterale, juristische Übereinkunft zwischen Netzwerk-Provider und Kunde, in der die vertraglichen Vereinbarungen zur Qualität der Leistungen spezifiziert sind. Zu den wesentlichen Aspekten einer solchen Qualitätsvereinbarung, in denen die Netz- und Service-Parameter festgelegt sind, gehören die Bandbreite, die Verfügbarkeit, die Netzkapazität und die Netzqualität. Neben den genannten technischen Parametern spielen die Güte der Dienstleistung, die Technik und Messtechnik, mit der die Dienstleistungen erbracht werden, die Ausfall-, Reaktions- und Entstörzeiten, die Servicequalität beeinflussende Faktoren, eine Rolle.“ Class of Service QoS darf nicht mit der primär in Lokalen Netzen eingesetzten Class of Service (CoS) verwechselt werden. CoS ist ein einfacher Ansatz, der ähnlich geartete Verkehrsströme zu einer gemeinschaftlichen Klasse zusammenfasst. Einer Klasse wird eine definierte Dienstgüte zur Verfügung gestellt, allerdings ohne weitere Garantien oder Szenarien, wie das Netz mit Überlast umgehen soll. Schlüsselfunktionen zur Implementierung von QoS in einem Netz oder in Teilen eines Netzes sind x ein ausreichend hohes Maß an Netzressourcen (nicht nur von Bandbreite!) x eine hohe Verfügbarkeit dieser Ressourcen x die Möglichkeit, diese Ressourcen intelligent zu managen

3.3.2 Problemstellungen und Lösungsansätze Abbildung 3.11 zeigt das grundlegende Konzept des paketvermittelten garantiefreien Internet und die dadurch konzeptbedingten Störungen des Datenflusses. Vor allem Echtzeit-Anwendungen stellen zusätzlich zu ihrem häufig hohen Bedarf an zugesicherter Bandbreite weitere Anforderungen an die Transportnetze: die absolute Laufzeit und Laufzeitschwankungen dürfen nur niedrige Werte aufweisen und zueinander gehörende, aber unabhängig voneinander transportierte Streams (Audio-Videostream bei Videokonferenz)müssen im Empfänger wieder miteinander synchronisierbar sein (Lippensynchronisation).


■ ■ ■

145

Abb. 3.11: Ursachen für schlechte Dienstqualität im Internet

Beispiele für die Dienstqualität bestimmende Parameter, die unabhängig von der Art und Weise der QoS-Garantie, in einem Netz über die Qualität entscheiden, sind: Dienstgüteparameter

Realisierung von QoS

146

■ ■ ■

x Minimale Verfügbarkeit x Bandbreite: durchschnittliche und maximale Datenrate (incl. zeitlicher Verteilung) x Maximal tolerierbare Verlustrate von Paketen x Maximale Laufzeit zwischen zwei Bezugspunkten (Ende-Ende-Verzögerung) x Maximal zulässige Schwankungen der Latenzzeit zwischen zwei Bezugspunkten Die QoS-Parameter sind nicht unabhängig voneinander, beispielsweise ist die Ende-Ende-Verzögerung mit der zur Verfügung stehenden Bandbreite korreliert. Speziell Backbone-Provider werben mit einer Netzverfügbarkeit von 99,999%. Die für den Kunden viel wesentlichere Ende-Ende-Verfügbarkeit incl. allen Komponenten und Netzabschnitten liegt aber immer noch deutlich darunter. Ein wesentliches Kriterium für die Eignung eines Netzes zur Übertragung von Sprache ist die Ende-Ende-Verzögerung. Sie sollte, um in etwa ISDN-Qualität bzgl. der Netzlaufzeit zu erreichen, den Wert von 150 ms nicht überschreiten (ITU-T G.114). Latenzzeiten über 400 ms sind absolut inakzeptabel, weil sich die Kommunikationspartner dann gegenseitig „ins Wort fallen“. Zur Umsetzung von QoS in den Netzen werden komplexe Mechanismen zur Paketkennzeichnung, Warteschlangen-Management in Routern und Verkehrspriorisierung eingesetzt. Die Verarbeitung der Pakete eines Streams innerhalb der Router ist primär von der Routerperformance, der Verbindungsbandbreite zu den nachfolgenden Routern und der aktuellen Anzahl und Größe der ankommenden Datenpakete abhängig. Ohne besonderen Maßnahmen

3 Multimedia-Netze

werden die Pakete in einer Warteschlange aufgereiht und nach dem Prinzip „first in-first out“ geroutet. Diverse Ansätze beschäftigen sich mit der Optimierung des Routing durch Priorisierung einzelner Pakete innerhalb der Warteschlangen. Diese Queuing-Techniken unterscheiden sich dadurch, wie sie Warteschlangen in Stausituationen abbauen (Beispiele: class-based oder flow-based weighted fair queueing, priority queueing, custom queueing). Näheres hierzu unter [QUEU]. Die in diesem Beitrag diskutierten Ansätze zur Realisierung von QoS im WAN-Transportnetz lassen sich in zwei grundlegende Klassen unterteilen: x Reservierung und Management von Netzressourcen (Verkehrssteuerung): die Zulassung eines Dienstes oder einer Anwendung setzt freie Kapazitäten voraus. Mit Hilfe eines Signalisierungsprotokolls teilt die Applikation ihre Anforderungen mit und erhält eine Bestätigung vom Netz. Beispiel: Integrated Services (IntServ) mit dem Resource Reservation Protocol (RSVP) oder der Asynchrone Transfer Modus (ATM). Das Multiprotocol Label Switching (MPLS) ergänzt die Pakete um eine zusätzliche Kennung (Label) und leitet die Pakete durch die nachfolgende Auswertung dieser Labels weiter. x Priorisierung von Paketen: der Datenverkehr wird dabei über spezielle Angaben im ProtokollHeader durch den Anwender, die Applikation oder das Netzprotokoll initiiert. Mit steigender Priorität sind beispielsweise ein höherer Durchsatz oder geringere Verzögerungen möglich. Allerdings sind die QoS-Eigenschaften eines Streams dabei von der übrigen aktuellen Verkehrmenge und deren Verkehrsprofil abhängig, die mit gleicher oder höherer Priorität auf dem gleichen Streckenabschnitt unterwegs ist. Beispiel: Differentiated Services (DiffServ). Die QoS-Maßnahmen lassen sich einzelnen Verkehrsflüssen oder aggregierten Verkehrsflüssen durch Klassenbildung zuordnen. Ansätze, die sich auf die Sicherstellung der QoS durch Ende-EndeMassnahmen beziehen, sind nur ohne minimale QoS-Garantien des Transportnetzes wenig erfolgversprechend. Zu den Protokollen, bei denen durch gezielte Maßnahmen QoS-Schwächen des Transportnetzes zumindest zum Teil korrigiert werden können, gehört beispielsweise das Real-Time-Protocol RTP (Kap. 3.4.2.5). Es ist in der Lage, Laufzeitschwankungen des Transportnetzes durch Pufferung auszugleichen bzw. in Verbindung mit Realtime-TCP (RTCP), im Bedarfsfall eine geringere Sendebitrate durchzusetzen. Das bekannte TCP-Windowing kann bei TCP-basierter Übertragung ebenfalls dazu beitragen, eine Ende-Ende-Lastkontrolle umzusetzen. Maßnahmen der Verkehrssteuerung und der Datenpriorisierung in IP-Paketnetzen werden gewöhnlich als IP-QoS („Layer-3-QoS“) be-


■ ■ ■

147

zeichnet. Eine Alternative (oder Ergänzung) zur Sicherstellung von QoS auf der OSI-Ebene 2 ist der Einsatz des leitungsvermittelten Asynchronen Transfer Modus (ATM-QoS). Generell sind Layer-3Massnahmen deutlich rechen- und zeitintensiver als Maßnahmen auf der Ebene 2. Für die Routing-Entscheidung selbst genügt es natürlich, lediglich die IP-Adressen auszuwerten. Allerdings müssen bestimmte Felder innerhalb der IP-Pakete neu berechnet werden, im ungünstigsten Fall ist Fragmentierung erforderlich, so dass das Paket fast komplett umgebaut werden muss. Einen brauchbaren Mittelweg zwischen Layer-2-und Layer-3-Massnahmen stellt MPLS dar (Kap. 3.4.3.3).

3.3.3 ATM-QoS Der Asynchrone Transfer Modus–ursprünglich als Breitband-ISDN konzipiert – hat sein ursprüngliches Ziel, sich als einheitliche Technologie in LAN und WAN zu platzieren und die Netzkonvergenz dadurch voranzutreiben, deutlich verfehlt. Dies lag einerseits an der Komplexität und den hohen Infrastrukturkosten, andererseits aber auch an dem bereits beschriebenen Siegszug von Ethernet. Allerdings sind die im ATM inhärent definierten und nicht wie bei IP-QoS nachträglich aufgepfropften QoS-Möglichkeiten sehr souverän und bilden ein stabiles Fundament, um umfassende Ende-Ende-QoS Garantien für die unterschiedlichsten Verkehrsprofile zu garantieren. ATM spielt aktuell im UMTS-Umfeld eine wesentliche Rolle, in anderen Einsatzfeldern wird ATM nach und nach durch Alternativen wie dem später beschriebenen MPLS ersetzt. Die wichtigsten Eigenschaften von ATM im Überblick: x ATM arbeitet verbindungsorientiert und paketvermittelt. Alle Pakete, die auch als Zellen bezeichnet werden, haben eine feste Länge und durchlaufen exakt den gleichen Weg durch das Netz. Die ATMZellen haben eine feste Länge von 53 Byte (davon bilden 5 Byte den Zellkopf). Dies ermöglicht eine einfache Verarbeitung der Zellen in den Vermittlungseinheiten und reduziert die Komplexität der parallelen Verarbeitung. x ATM kann mit beliebigen Sendebitraten umgehen. Variable QuellBitraten führen zu variablen ATM-Zellströmen, in den Pausen können Zellen anderer Quellen übertragen werden. x ATM nutzt die vorhandene Infrastruktur. ATM-Zellströme werden beispielsweise im WAN über die übliche SDH-Infrastruktur übertragen. Ist zu einem bestimmten Zeitpunkt keine Zelle zum Transport von Nutzlast vorhanden, wird eine Leerzelle übertragen.

148

■ ■ ■

3 Multimedia-Netze

Abb. 3.12: Aufbau einer ATM-Zelle am NNI

Während des Verbindungsaufbaus werden Betriebsmittel vom Netz angefordert. Nur wenn diese Forderungen vom Netz erfüllt werden können, kommt eine Verbindung zustande. Das große Plus von ATM ist die hohe Effizienz bei der Nutzung vorhandener Bandbreiteressourcen. ATM ist auch ohne QoS-Maßnahmen vorteilhaft einsetzbar, entfaltet seine Stärken aber insbesondere im QoS-Kontext. Aufgrund der geringen Zellengröße müssen Pakete eines anderen Protokolls zum Transport über ATM in mehrere Zellen aufgeteilt werden (Segmentierung) und beim Verlassen des ATM-Netzes wieder zusammengesetzt werden (Reassemblierung). Den Aufbau der Zelle am Network-Node-Interface (NNI), also innerhalb eines Netzes, zeigt Abb. 3.12. VPI (Virtual Path Identifier): Der VPI fasst mehrere virtuelle Kanäle (VC) in Richtung eines Ziels zusammen. Multimedia-Ströme eines Senders zu einem Empfänger können somit durch Auswertung des übergeordneten Pfades weitergeleitet werden.

Elemente der ATM-Zelle

VCI (Virtual Channel Identifier): Der VCI kennzeichnet jeweils einen Verbindungsabschnitt zwischen Vermittlungsstellen und zwischen Vermittlungsstelle und Teilnehmer. PTI (Payload Type Identifier): Das Feld kennzeichnet die Art der Informationsfelddaten. Es wird zwischen Netz(management), Steuerdaten und Nutzinformationen unterschieden. CLP (Cell Loss Priority): Der Inhalt des Feldes entscheidet darüber, ob eine Zelle im Falle eines Übertragungsengpasses bevorzugt gelöscht wird oder nicht. HEC (Header Error Control): Der HEC ermöglicht die Synchronisation auf den Zellbeginn und erlaubt die Fehlerdetektion und im Falle von Einzelfehlern im Zellkopf auch deren Korrektur


■ ■ ■

149

Abb. 3.13: Channel- und Path-Identifier

Dienstkategorien

VPI und VCI werden beim Verbindungsaufbau durch die Vermittlungsstellen vergeben. Die VPI/VCI-Kennung kennzeichnet alle Zellen, die zu einer bestimmten Verbindung gehören (Abb. 3.13). Die Verbindungsbeziehungen im ATM-Netz werden als virtuell bezeichnet, da sie nicht physikalisch bestehen, sondern nur in Form von Routing-Tabellen in den Vermittlungsstellen. Die Lenkung der Zellen durch das Netz erfolgt aufgrund der Informationen in den VPI/VCIFeldern. Diese Kennzeichnung gilt dabei jeweils nur für einen Verbindungsabschnitt. Statt alle einzelnen Datenströme einer MultimediaVerbindung einzeln zu routen, genügt es, einen einzigen VPI-Wert auszuwerten. Die nachfolgenden ATM-Dienstekategorien des ATM-Forums berücksichtigen die typische Verkehrscharakteristik unterschiedlicher Quellsignale. Jeder Dienstklasse sind Bandbreiteressourcen und Dienstgüten durch Spezifizierung der Verkehrsparameter zugeordnet. Die Umsetzung der über die Dienstkategorien definierten Anforderungen an das Netz erfolgt über Verkehrsparameter (Bandbreite, Laufzeit, maximal zulässige Bitfehlerhäufigkeit etc.). Nicht alle Parameter werden für jede Dienstklasse benötigt. x CBR (Constant Bit Rate): mit Echtzeitanforderungen x VBR (Realtime Varaible Bitrate): unterteilt in realtime (rt-VBR) und non-realtime VBR x UBR (Unspecified Bit Rate): entspricht der „best-effort” –Übertragung des heutigen Internet ohne Garantien x ABR (Available Bit Rate): die Bandbreite wird vom Netz je nach Verfügbarkeit dynamisch zugewiesen, ideal für burstartigen, zeitund fehlerunkritischen LAN-Verkehr. ATM-QoS-Maßnahmen sind optimiert für reine ATM-Netze. Im Zusammenspiel mit IP wird die Umsetzung von QoS deutlich komplexer, weil sich eventuelle QoS-Merkmale von IP nur aufwändig und kostenintensiv auf ATM abbilden lassen.

150

■ ■ ■

3 Multimedia-Netze

3.3.4 IP-QoS in Weitverkehrsnetzen In den letzten Jahren wurde durch die Entwicklung diverser Protokolle und Algorithmen die Basis für die heutigen IP-QoS-Strategien gelegt. Grundlegend für QoS ist, dass zusammenhängende Datenflüsse erkannt und zugeordnet werden können. Eines der grundlegenden Ziel beim Entwurf von IP-QoS war die Transparenz: Datenpakete, die einen Weg über nicht QoS-fähige Router nehmen, werden „normal“ weitervermittelt. Dabei kann zwar die Dienstgüte verloren gehen, das Paket selber jedoch findet seinen Weg zum Empfänger. QoS ist aufgrund der Struktur des Internet in der Regel zuverlässig nur in begrenzten Bereichen realisierbar, zum Beispiel innerhalb eines Autonomen Systems. Das Interworking von „QoS-Inseln“ ist Thema zahlreicher Forschungsarbeiten. Nachfolgend betrachten wir drei Wege, um QoS in einem „IP-besteffort-Netz“ zu garantieren. Weitere Ansätze wie zum Beispiel das Management von Warteschlangen in Routern werden hier nicht betrachtet. x Integrated Services (Intserv) x Differentiated Services (DiffServ) x Multiprotocol-Label-Switching (MPLS) 3.3.4.1 Integrated Services (Intserv) Das IntServ-Konzept, das bereits 1994 vorgeschlagen wurde, orientiert sich an den Dienstklassen von ATM und versucht, die Idee der Dienstklassifizierung des verbindungsorientierten ATM auf die verbindungslose IP-Welt zu übertragen. Mit Hilfe des Resource-Reservation-Protocol (RSVP) teilt der Sender den gewünschten Empfängern die für seine Kommunikationsabsicht erforderlichen QoS-Verkehrsparameter mit (zum Beispiel Bandbreite, Pufferspeicher, maximal zulässiger Jitter). Alle RSVP-fähigen Router werten diese Nachrichten aus und erstellen einen Statusbericht, der auch die Adressen der vorangegangenen Router enthält. Der Absender der Nachricht ist somit für das Netz zweifelsfrei identifizierbar. RSVP überprüft während der Übertragung periodisch die Anforderung. Unterbleibt die „Refresh“-Nachricht als Bestätigung, wird die Reservierung gekündigt. IntServ verwendet – wie auch ATM – abgestufte QoS-Level und definiert Parameter, die entsprechenden Verkehrsfluss beschreiben. Beispiel hierzu: Bucket Rate (mittlerer Verkehrsfluss), Bucket Depth (maximal zulässige Burst-Größe), Maximum Packet Size (maximale Paketgröße).


RSVP

■ ■ ■

151

IntServ-Dienstklassen

Von den durch die IETF definierten fünf Dienstklassen haben nur zwei Bedeutung erlangt: „Guaranteed QoS“ und „Controlled Load Network Element Service“. Während für die erste Klasse das Netz eine feste Bandbreite reservieren und eine maximale Laufzeit und keinerlei Paketverlust garantieren muss. Der Controlled Load Service bemüht sich die Ressourcen so zu reservieren, dass in etwa die Dienstgüte vorhanden ist, die das Netz unter geringer Last bieten würde, der best effort-Charakter des Netzes selbst bleibt jedoch erhalten. RSVP bezieht sich auf einzelne Verkehrsflüsse. Im Backbone-Bereich kumulieren sich in einem RSVP-Router eine hohe Anzahl von RSVPgesteuerten Verbindungen und damit die Menge an zu verwaltenden Zustandsinformationen. Es ist nicht sichergestellt, dass der Router alle Verbindungen ausreichend schnell bearbeiten kann. IntServ ist in großen Netzen deshalb schlecht skalierbar. Dadurch können nicht vorhersagbare Engpässe entstehen. Zudem ist die für die Ressourcenreservierung einer Verbindung (RSVP) benötigte Zeit nicht unerheblich. Die insgesamt wenig überzeugenden Erfahrungen mit IntServ haben dazu geführt, dass die deutlich besser skalierbare Alternative der Differentiated Services Einzug in die Netze gehalten hat. 3.3.4.2 Differentiated Services (DiffServ)

Per-Hob-Behaviour

152

■ ■ ■

DiffServ reserviert Ressourcen für aggregierte, nicht für einzelne Datenströme. Während bei IntServ vorhandene Ressourcen explizit angefordert, reserviert und verwaltet werden, wird der Datenverkehr mit DiffServ lediglich differenziert priorisiert, indem er definierten Qualitätsklassen zugeordnet wird. Router können DiffServ IP-Pakete direkt auswerten, ohne die rechenintensive Auswertung von Statustabellen, in denen jede einzelne Verbindung verzeichnet ist. DiffServ vertraut unter Verzicht auf Signalisierung in gewisser Weise der Elastizität und Anpassungsfähigkeit von Datenströmen, zum Beispiel auf die Flusskontrolle von TCP. Die Applikation oder das Netzelement fordert eine bestimmte Qualitätsstufe an, indem sie die IP-Pakete entsprechend markiert und damit den einzelnen Knoten vorgibt, wie sie die Pakete behandeln sollen. Diese Vorgabe wird auch als Per-Hob-Behaviour (PHB) bezeichnet, da sie für jeden Router gilt, der das Paket bearbeitet. Die Pakete werden beim Eintritt in das DiffServ-fähige Netz (DiffServ-Domäne) vom so genannten Edge-Router überprüft, die entsprechende QoS-Klasse festgelegt und die Pakete wie später beschrieben markiert (Abb. 3.14). Pakete, die der gleichen Klasse angehören, werden zu Verkehrsströmen zusammengefasst. Im einfachsten Fall kann die Klassifizierung beispielsweise aufgrund der Layer-4-Ports erfolgen.

3 Multimedia-Netze

Abb. 3.14: DiffServ-Funktionsprinzip

Zusätzlich definiert DiffServ einen Satz von Regeln für jede Dienstklasse, die bestimmen, wie mit den Paketen innerhalb des Netzes zu verfahren ist. Diese Regeln stellen sicher, dass Dienstparameter für den aggregierten Stream innerhalb des gesamten DiffServ-Netzteils beachtet werden. Da bei DiffServ Routing-Entscheidungen per Paket und nicht per Sitzung getroffen werden ist eine Vorabreservierung von Bandbreite nicht erforderlich. Nur die Edge Router übernehmen die komplexe Zuordnung der Priorisierung, die Router innerhalb der DiffServ-Domäne werten lediglich die Paketmarkierung aus. DiffServ verwendet zur Markierung der Pakete das in IPv4 vorhandene Feld Type of Service (TOS), das zwar integraler Bestandteil des IP-Protokolls ist, jedoch nur in den wenigsten Fällen genutzt wurde (Abb. 3.15). In der DiffServ-Implementierung wird dieses Feld als DiffServ Code Point (DSCP) bezeichnet und wird in seinen Funktionen auch im IPv6 als Traffic Class eingesetzt (vgl. Kap. 3.4.3). Das DSCP-Feld kann mit einer Länge von 6 Bit 64 Klassen markieren, von denen die IETF acht Standard-Klassen definiert hat. Abb. 3.15: Redefinition des TOS-Feldes von IPv4


■ ■ ■

153

Der DSCP ist aufgeteilt in den Class Selector (Auswahl einer Klasse) und die Drop Precedence (Behandlung des Pakets innerhalb der Klasse). Für jede der Klassen existiert ein wohldefiniertes PHB definiert. Bei einer DiffServ-Verbindung über die Netzgrenzen von ISPs hinweg, muss die Dienstklasse beim Betreten eines neuen Netzes auch neu festgelegt werden (vgl. hierzu [ORLA]). 3.3.4.3 Multiprotocol-Label-Switching (MPLS) MPLS arbeitet nach der Devise „Switching statt Routing“ und erhöht dadurch signifikant die Performance eines Netzes. Die Idee hinter MPLS orientiert sich an ATM: ein Signalisierungsprotokoll baut einen Pfad vom Sender zum Empfänger auf. Die Sendepakete werden um eine lokal gültige Kennung, das so genannte Label, ergänzt. Die Entscheidung über den Weg trifft ein Router nicht mehr anhand der Ziel-IP-Adresse, sondern auf Basis dieses Labels. Damit entfällt die rechenintensive Auswertung des IP-Headers. Eine MPLS-Infrastruktur gilt mittlerweile als Alleskönner, ist recht universell ausgelegt und deckt sowohl Traffic Engineering und Dienstgüteklassen-Zuordnung ab. MPLS ist kompatibel zu den Layer-2-Technologien wie ATM, SDH und Ethernet und damit universell einsetzbar. Im OSI-Modell ist MPLS zwischen Schicht 2 und 3 angesiedelt, alle erforderlichen Informationen werden in einem MPLS-spezifischen Header zwischen den Protokollen der Ebenen 2 und 3 übertragen (MPLS-Shim-Header). Die MPLS-Label können nicht nur Informationen zur eigentlichen Weiterleitung enthalten, sondern auch Angaben zu Diensten, Portnummern oder applikationsspezifischen Details. Die Labels sind so gestrickt, dass sie alle in der Praxis wesentlichen Kombinationen von die Dienstgüte bestimmenden Parametern abdecken. Nur die Router am Rande einer MPLS-Domäne (Label Edge Router, LER) fügen die Labels hinzu und entfernen sie auch wieder. Die Router innerhalb einer Domäne (Label Switch Router, LSR) sind von rechenintensiven Aufgaben befreit und leiten die per Label markierten Pakete einer Verbindung anhand vordefinierter Wege durch das MPLS-fähige Netz (Abb. 3.16). Mehrere hierarchisch geschachtelte Labels ermöglichen es, MPLS-Informationen über mehrere Domänen hinweg weiterzuleiten (Labelstack). Dazu wird jeweils nur das erste Label berücksichtigt. Für die Zuweisung der MPLS-Labels existieren diverse Ansätze, die zum Teil auch die jeweilige Herstellerphilosophie widerspiegeln. Im einfachsten Fall orientiert sich die Label-Erzeugung strikt an der in den Routing-Tabellen enthaltenen aktuellen Route zu einem Ziel. Jeder definierten Route wird ein festes Label zugewiesen. Prinzipiell

154

■ ■ ■

3 Multimedia-Netze

kann die Label-Zuweisung auch durch ein Signalisierungsprotokoll wie RSVP durchgeführt werden. Beide Möglichkeiten trennen den eigentlichen Verkehrsfluss von der Label-Erzeugung. Die dritte Möglichkeit: der LSR kann die Labelerzeugung durch Analyse des Datenverkehrs und der zugehörigen Flows selbst gestalten und verwalten. Das Label Distribution Protocol (LDP) kommuniziert zwischen Edge-Routern (LER) und Core-Routern (LSR) innerhalb der MPLSDomäne und teilt den LSR die aktuell gültigen Labels mit. Jeder einzelne LSR-Router verfügt nun über eine Tabelle, die ein Label definiert, das bis zum nächsten „Hop“, also dem nachfolgenden Router, gültig ist und dort umgewertet wird (Label-Swapping). Das Label muss somit nicht jeweils zeitintensiv neu berechnet, sondern nur abgerufen werden. Gelangt nun ein Paket in die konfigurierte MPLSDomäne, bestimmt der Edge-Router (Label Edge Router, LER) die erforderlichen QoS-Eigenschaften und ergänzt das Paket um ein entsprechendes Label. Verkehrsströme einer Klasse (Forward Equivalence Class) werden zusammengefasst und innerhalb des Netzes gleich behandelt. Ein LSR innerhalb der Domäne verändert das Label entsprechend seiner Tabelle und leitet das Paket zum nächsten LSR weiter. Der LER am Ausgang der Domäne entfernt das Label. Wenn zusätzlich zu MPLS auch ATM verwendet wird, kann der MPLS-Header entfallen, die Label-Information wird dann direkt im


Abb. 3.16: MPLS-Funktionsprinzip

Label Distribution Protocol

■ ■ ■

155

VPLS

GMPLS

VCI/VPI übertragen. Der vorkonfigurierte Weg von MPLS erinnert an die Virtual Channels von ATM, MPLS skaliert jedoch deutlich besser als ATM und ist insgesamt einfacher und kostengünstiger. MPLS öffnet Carriern und Service Providern den Weg, eine zukunftssichere Plattform für eine Multiservice-Architektur mit neuen Diensten und differenzierten Dienstmerkmalen anbieten zu können. Zudem unterstützt MPLS die weit verbreiteten Virtual Private Networks (VPN) und kann für VPN-Tunnels definierte Qualität garantieren. Letzteres ist eine der Voraussetzungen, um die klassischen Standleitungen (2 Mbit/s, E1) durch IP-basierte VPN-Tunnels zu ersetzen. In diesem Kontext gewinnen Virtual Private LAN Services (VPLS) zunehmend an Bedeutung. VPLS definiert eine Klasse von VPN, die eine standortübergreifende Verbindung innerhalb einer Layer-2-Domäne über eine IP/MPLS-Infrastruktur ermöglichen. Weitere Informationen zu MPLS finden sich unter [MPLS1] und [MPLS2]. Das Interworking der verschiedenen Netzkonzepte und – technologien mit MPLS beschreibt beispielsweise [ORLA]. Generalized Multiprotocol Label Switching (GMPLS) Kaum hat MPLS angefangen, in den Netzen Fuß zu fassen, schon steht der nächst Evolutionsschritt an. GMPLS soll als Weiterentwicklung von MPLS eine noch höhere Flexibilität ermöglichen und auch die optischen Transportnetze (ITU-T G.709) stärker berücksichtigen. In GMPLS-Netzen können optische Wellenlängen dynamisch angefordert und zugeteilt werden.

3.4 Next Generation Networks NGN 3.4.1 Einleitung Die Übertragung von IP-Daten erfolgt heute über die beschriebene Infrastruktur, die primär für die Übertragung von Sprache oder Festverbindungen konstanter Übertragungskapazität konzipiert wurde (TDM-Telekommunikationsnetz). Der wachsenden Bedeutung von IP wurde dieses Netz dadurch gerecht, dass Netzwerk-Zwischenschichten dienstebezogen implementiert wurden (zum Beispiel ATM oder MPLS). Dieses mehrschichtige Netz ist komplex und nur aufwändig wartbar und administrierbar. Das NGN und damit eng verbunden die Next Generation Services heben die enge Kopplung zwischen Diensten und ihren Transportnetzen auf. Das NGN wird sich in den kommenden Jahren schrittweise

156

■ ■ ■

3 Multimedia-Netze

zur Plattform für die multimediale Kommunikation der Zukunft entwickeln (Multimedia-NGN). Trotz der etwas unspezifischen Definitionsvielfalt in Bezug auf den Begriff NGN zeichnen sich die Grundzüge und Ziele des NGN immer deutlicher ab: x Das NGN arbeitet paketvermittelt–und arbeitet somit deutlich effizienter als die leitungsorientierte Zeitmultiplex-Übertragung. Letztere verfügt allerdings über herausragende prinzipbedingte QoSEigenschaften. Der einheitliche Integrationsfaktor wird das Internet Protokoll IP sein (IPv4 mit gleitender Migration zu IPv6) x Unabdingbare Voraussetzung für ein NGN ist eine durchgängige Ende-Ende-QoS über breitbandige Transportverbindungen. Multicast-Verkehrsströme können effizient geroutet und verteilt werden. x Der Transport der Nutzdaten (Transport Layer) erfolgt getrennt von der Bereitstellung von Diensten (Service Layer) und der Dienstsignalisierung (Control Layer). x Vorhandene Infrastrukturen und Netze können im Sinne des Investitionsschutzes integriert werden (offene Schnittstellen), die Interoperabilität wird gewährleistet sein. Bandbreiteressourcen stehen hochflexibel und ohne Ausfallzeiten zur Verfügung. x Mobilität ist eine der zentralen Anforderungen an ein NGN, multimediale Inhalte werden für mobile Nutzer verfügbar sein.

Grundzüge des NGN

In den heutigen Netzen werden Dienste unter Rücksichtnahme auf das für den Dienst verwendete Netz so entwickelt, dass das Anschluss- und Transportnetz in der Lage ist, den Dienst zufriedenstellend zu übertragen. Die Geschäftsmodelle der Carrier zielen entweder auf die Versorgung bestimmter Kundengruppen oder sie sind Spezialisten für eine Dienstleistung wie Telefonie, Internetzugang oder TVÜbertragung. In einem NGN ist ein Dienst eine Anwendung, die frei entwickelt werden kann und ohne prinzipielle Einschränkungen vom Netz übertragen und gemanaged werden kann. Die Architektur des NGN ist durchgängig dienstorientiert statt sich an den Fähigkeiten des Transportnetzes anpassen zu müssen (Abb. 3.17). Inbesondere der Ansatz des NGN ist revolutionär, statt getrennten Netzen und Protokollen für die einzelnen Dienste (vertikale Struktur) die Dienste vom eigentlichen Netz zu trennen (horizontale Struktur). Einer der zentralen Vorzüge des NGN ist, dass der Einzug der „Computerwelt“ in die Telekommunikation aufgrund der offenen, relativ frei programmierbaren Plattformen eine Fülle von neuen und innovativen Dienstangeboten ermöglichen wird. Eine zentrale Rolle in einem NGN werden auch personalisierte Dienste spielen. Die strikte Trennung der verschiedenen Funktionen ermöglicht es, die einzelnen

Bisher: dienstspezifische Netze

3.4 Next Generation Networks NGN

NGN: dienstneutrale Netze

■ ■ ■

157

Abb. 3.17: Trennung von Dienst- und Transportebene

Softswitch

158

■ ■ ■

Aufgabenblöcke technologisch und wirtschaftlich unabhängig voneinander zu optimieren. Auch die Wertschöpfungskette wird sich durch dieses Struktur deutlich verändern und diversifizieren (Service-Provider, Content-Provider, Portal-Betreiber etc.) Allerdings gewinnt auch die Thematik der Internet-Sicherheit in einem NGN deutlich an Gewicht (Beispiele: Spoofing, Denial-of-Service-Angriffe, Spam over Internet-Telephony (Spit). Das NGN wird sich schrittweise im Rahmen der Konvergenz der Netze entwickeln. Abbildung 3.18 zeigt die konvergente Netzwerkarchitektur eines NGN. „All-IP“ bedeutet in diesem Zusammenhang den konsequenten Einsatz des IP-Protokolls auf Applikations-, Kontroll-, Management- und Transportebene. Das breitbandige IP-Backbone verantwortet den Ende-Ende-Transport der Applikationsdatendaten mit zugesicherter QoS. Die Anbindung konventioneller Netze erfolgt mit Hilfe von skalierbaren Media Gateways für die Nutzdaten und Signalling Gateways für die Signalisierungsinformationen. Die Gateways werden von einem Call Server (CS) bzw. Media Gateway Controller (MGC) gesteuert und verwaltet. CS und MGC werden auch als Softswitch bezeichnet. Media Gateways ersetzen die Vermittlungsstellen des klassischen Telefonnetzes. Das IP-Multimedia-System (IMS, vgl. Kap. 4) konzeptionell designed für 3G-Mobilfunknetze, ist die konsequente Weiterentwicklung der Mobilfunknetze zu einer NGN-Architektur. Die Echtzeitübertragung von Multimediadaten mit beliebiger Kommunikationsbeziehung zwischen Sender- und Empfängern, ist eine der elementaren Anforderungen an ein NGN. Im NGN werden die später diskutierten Protokolle SIP und IPv6 ebenso eine zentrale Rolle spielen wie die Fähigkeit des Netzes, die Multicast-Übertragung zu ermöglichen. Die nachfolgenden Kapitel nehmen sich dieser Themen an.

3 Multimedia-Netze

Abb. 3.18: Architektur eines NGN (vereinfacht)

3.4.2 Voice-over-IP 3.4.2.1 Einführung Voice-over-IP, gehört neben IPTV zu den prominentesten Vertretern zukünftiger Multimedia-Applikationen. Bei der klassischen TDM-Übertragung (Time Division Multiplexing) werden die codierten Sprachproben an einem zentralen Koppelpunkt (Digitalvermittlung) zusammengeführt und dort über die weitere Wegführung entschieden. Internet-basierte Sprachübertragung trennt–gemäß dem NGN-Konzept–die Signalisierungsebene von der Transportebene und leitet Pakete deutlich effizienter zum Ziel. Die diversen Standards zur Übertragung von VoIP definieren die Codecs, die Signalisierungsabläufe, die Funktionen der Übertragungs- und Endgeräte und die Transportprotokolle. Als Mutter aller VoIP-Standards gilt H.323, der 1996 von der ITU in der ersten Fassung verabschiedet wurde und die Übertragung multi-


■ ■ ■

159

medialer Daten über verbindungslose Netze beschreibt. Zur Signalisierung in VoIP-Netzen etabliert sich aktuell das von der IETF standardisierte Session Initiation Protocol (SIP), das auch im IMS (UMTS Release 5) eine tragende Rolle übernehmen wird. Die Marktakzeptanz von H.323 ist bei der reinen IP-Telefonie stark abnehmend. Die später beschriebenen Protokolle zum eigentlichen Transport der Echtzeitdaten (zum Beispiel das Real-Time-Protocol RTP) oder die empfohlenen Codecs sind in beiden Standards gleich. 3.4.2.2 Sprachkomprimierung Die traditionelle Sprachübertragung (klassische PCM-Technik, Kap. 1.9.1) erfordert eine über der Zeit konstante Bandbreite von 64 kbit/s (ITU-T-Standard G.711). Bereits mit den ersten Mobilfunksytemen wurden neue Voice-Codecs eingeführt, die für Voice-over-IP erweitert und verbessert wurden. Jede Technologie zur Kompression muss den Kompromiss zwischen gewünschter Sprachqualität und erforderlicher Bandbreite neu austarieren. Moderne Sprachcodecs codieren Sprache mit akzeptabler Qualität mit nur wenigen Kilobit/s. Als Referenz- und Zielwert gilt die Sprachqualität, die heutige (ISDN)Telefonnetze ermöglichen. Die Wahl eines Codecs ist primär von der zur Verfügung stehenden Bandbreite abhängig. Im LAN kann der Administrator Bandbreite relativ einfach und zuverlässig zuteilen, im WAN fällt dies ungleich schwerer. Die diversen Verfahren zur Sprachkomprimierung lassen sich in drei Gruppen unterteilen, die in Kap. 1.9 detailliert erläutert sind und hier unter dem Gesichtspunkt des konkreten Einsatzes bei Voiceover-IP beschrieben werden. x Signalformkodierer: die Signalform wird abgetastet, die Werte digitalisiert und entsprechend kodiert. Der Standard G.711 gehört zu dieser Gruppe. x Parametrische Kodierer: nicht der zeitliche Signalverlauf des Signals wird herangezogen, sondern das Signal wird durch die Übertragung von Signalparametern beschrieben. Parametrische Kodierung benötigt deutlich mehr Rechenzeit als die Signalformkodierung. Da die so komprimierte Sprache künstlich klingt, werden parametrische Kodierer in der Praxis nicht verwendet x Hybride Verfahren: sie basieren auf der Abtastung der Signalform und fassen aufeinanderfolgende Abtastwerte nach dem Prinzip der parametrischen Kodierung zusammen. Die resultierende Sprachqualität erreicht bei Bitraten von bis wenigen kBit/s bis zu 16 kBit/s akzeptable Werte. Bei Voice-over-IP werden neben dem Signalform-Codec G.711 ausnahmslos hybride Codecs eingesetzt.

160

■ ■ ■

3 Multimedia-Netze

ITUMOSSpezifikation Wert

Übertragungs- Delay Kommentar rate (kbps) (ms)

G.711 G.728

4,4 3,6

64 16

G.723

3,6 ..4,0 5,3/6,3

30

G.729

3,7..3,9

10

8

0,125 0,63

Tabelle 3.1 Audio-Codecs und ihr MOS-Wert (Auswahl)

ISDN- Sprachqualität Sprachqualität entspicht ungefähr G.711 Hinreichend gute Sprachqualität Lange Verzögerung Weniger Delay u. bessere Sprachqualität als G.723

Wann ist eine Sprachqualität „gut“, wann ist sie „schlecht“? Hierzu existieren objektive und subjektive Kriterien. Die objektive Bewertung basiert auf reproduzierbaren Messungen der Parameter von Stör(signalen). Ein subjektiver Bewertungsmaßstab ist die Kategorisierung der Sprachqualität durch eine genügend hohe Anzahl von Versuchspersonen anhand der MOS-Werte (Mean Opinion Score). Der MOS-Wert ist eine dimensionslose Zahl zwischen 1 und 5, wobei der Wert „eins“ eine mangelhafte Sprachqualität repräsentiert, bei der die Verständigung nicht mehr möglich ist, der Wert von „fünf“ steht für eine exzellente Übertragungsqualität, bei der das codierte Signal die Qualität des Originalsignals aufweist. Die im ISDN übliche 64 kBit/s-Kodierung erreicht auf der MOS-Skala einen Wert von 4,4. Tabelle 3.1 stellt die wichtigsten VoIP-Codecs mit ihren MOS-Werten zusammen. Beim Verfahren der Puls-Code-Modulation (ITU-Standard G.711) wird die Signalform nach Bandbegrenzung des Signals auf 4 KHz mit 8 KHz abgetastet und nichtlinear mit 8 Bit kodiert. Zwischen den alle 125 Æs gewonnenen Abtastwerten werden Abtastproben weiterer Sprachsignale übertragen (Zeitmultiplex). Der Standard G.711 ist der kleinste gemeinsame Nenner der VoIP-Kommunikation, der von allen IP-Telefonen unterstützt werden muss. In Lokalen Netzen verwenden VoIP-Phones in der Regel die 64 kbit/s-Kodierung gemäß G.711, bei der WAN-Kommunikation sind in vielen Fällen stärker komprimierende Codecs erforderlich. Hybride Codecs teilen den Signalverlauf in einzelne Zeitsegmente auf, tasten sie ab und analysieren und codieren die Abtastwerte einer Gruppe. Der Codec kann auch versuchen, die Abtastwerte aus dem typischen Verlauf der Sprache vorherzusagen und die Parameter für die Vorhersage zu übertragen. Alternative Hybride Verfahren teilen den gesamten Frequenzbereich in mehrere Teilbereiche auf, die unabhängig voneinander und mit unterschiedlichen Bitraten kodiert werden. Der dazu erforderliche Rechenprozess kann die Latenzzeit signifikant erhöhen. Dieser Umstand kann bei einer WAN-VoIP-Kommunikation


MOS-Wert

Signalform-Codecs

Hybride Codecs

■ ■ ■

161

zu kritischen Gesamtlaufzeiten führen. Der in Kap. 1.9.3 beschriebene CELP-Codierer G.728 fasst bei Einsatz in der Sprachkommunikation typischerweise 5 Abtastwerte à 8 Bit (40 Bit) zusammen und komprimiert sie auf 10 Bit, so dass die Bitrate mit 16 Kbit/s nur ein Viertel der unkomprimierten 64 kBit/s- Sprachkodierung beträgt. Noch stärker komprimierende Varianten der CELP-Kodierung (G723.1) reduzieren die Bitrate auf 5,3 kBit/s. Die daraus resultierende Rechenzeit des Coders liegt im Mittel bei etwa 60 Millisekunden und ist damit grenzwertig hoch. Einige Codecs reduzieren die Datenrate zusätzlich dadurch, dass der Empfänger über Sprechpausen mit Hilfe einer speziellen Codierung informiert wird, ohne dass die Sprechpause selbst übertragen wird. Dass man beim leitungsvermittelten Telefonieren die eigene Stimme im Hörer wahrnimmt, wirkt sich bei nicht allzu hohen Echoverzögerungen (kleiner ca. 25 Millisekunden) eher beruhigend als störend aus. Bei Voice-over-IP übernehmen digitale Signalprozessoren (DSP) die Aufgabe der klassischen Echo-Canceler. Dazu wird das originale Sprachprofil für einen kurzen Zeitraum zwischengespeichert und das Echo des Originalsignals vom Empfangssignal subtrahiert. Das vom herkömmlichen Telefonieren bekannte „Hintergrundrauschen“ können die Signalprozessoren ebenfalls unterdrücken. Erfahrungen zeigen jedoch, dass fehlendes Rauschen viele Teilnehmer eher verunsichert, da sie es als Verbindungsabbruch interpretieren. Einige VoIPEndgeräte können deshalb ein „comfort-noice„ erzeugen. 3.4.2.3 Architektur des H.323-Standards H.323 ist ein umfangreicher „Umbrella-Standard“, der viele einzelne Standards und Protokolle umfasst, die alle Abläufe von der Verarbeitung (Codierung, Übertragung) der Multimedia-Daten, der Signalisierung, dem Verbindungsmanagement bis zum Interworking unterschiedlicher Netzwerke detailliert regeln (Abb. 3.19). Nähere Informationen zu H.323 finden sich in [BADA] oder [NÖLL]. Abb. 3.19: Elemente des Standards H.323 (vereinfacht)

162

■ ■ ■

3 Multimedia-Netze

H.323 definiert in seinen Unterstandards x die Signalisierung und Verbindungssteuerung: Registrierung, Administration und Status (RAS) zwischen zwei Endgeräten oder zwischen Endgerät und Gatekeeper x die Anrufsignalisierung: Kontroll–und Steuerinformationen für einen geregelten Nachrichtenaustausch x die Steuerung der logischen Verbindungen und der Flusskontrolle zwischen Endgeräten x den Datentransport mit Hilfe des Real-Time-Protocol RTP und desser Begleiter Real-Time-TCP (RTCP) x die Audio- und Video-Codecs x die Sicherheitsmaßnahmen x Zusatzdienste für die IP-Telefonie (Rufweiterleitung, Rückruf…) Während die Signalisierung gesichert über TCP übertragen wird, erfolgt der eigentliche Datentransport ungesichert durch das UDPProtokoll. H.323 definiert vier Komponenten für die Übertragung von VoIP (Abb. 3.20, nach [KIEF3]). Zwei Terminals können auch ohne weitere Elemente direkt Kontakt miteinander aufnehmen. x Terminal: Endgerät für die Audio-, Video- oder Datenkommunikation x Gatekeeper: Adressierungs- und Verbindungsmanagement, Überwachungsaufgaben, Zuteilung der Bandbreite x Gateway: Protokoll-Konverter zwischen LAN und WAN x Multipoint Control Unit MCU: Konferenzschaltungen mit mehr als zwei Terminals


Abb. 3.20: H.323-Elemente

■ ■ ■

163

Die einzelnen Funktionseinheiten können in anderen Netzwerkkomponenten integriert sein. So ist es durchaus möglich, dass ein Router im Netz als VoIP-Gateway arbeitet, die MCU Bestandteil des Gatekeepers ist oder dass alle Komponenten in einem einzigen Gerät implementiert sind. VoIP-Terminal Terminals können in Hardware („Hardphone“) oder Software („Softphone“) als Sprach- oder Videoterminals ausgeführt sein. Zu den bekanntesten H.323-Softphones gehört Microsoft- Netmeeting. Hardphones unterscheiden sich äußerlich kaum von „normalen“ Telefonen, ihr Innenleben basiert jedoch auf IP statt auf ISDN. Unabhängig von der Ausführung als Hard-oder Softphone besticht VoIP durch die Möglichkeit, bei Bedarf und entsprechender Implementierung innerhalb des Netzes in weitem Rahmen ortsunabhängig erreichbar zu sein und auf individuelle Telefoneinstellungen zugreifen zu können. Zwei Endgeräte können prinzipiell auch ohne den nachfolgend beschriebenen Gatekeeper Kontakt zueinander aufnehmen. Abbildung 3.21 vermittelt einen Überblick zu dem Ablauf und den eingesetzten Protokollen, wenn zwei Endgeräte ohne Gatekeeper direkten Kontakt zueinander aufnehmen. Die beiden Terminals sprechen sich gegenseitig über Sockets an, teilen über einen gesicherten TCP-Kanal mit, über welche Eigenschaften sie verfügen (terminal capability) und richten einen bidirektionalen Abb. 3.21: Direkter H.323-Verbindungsaufbau zwischen zwei Terminals ohne Gatekeeper

164

■ ■ ■

3 Multimedia-Netze

logischen TCP-Steuerkanal ein. Die eigentlichen Echtzeitdaten (Payload) werden per UDP mit Hilfe des später beschriebenen Real-TimeProtocols RTP übertragen. Die H.323-Signalisierungselemente sind im Unterstandard H.225 beschrieben und basieren auf dem ISDN-DKanal-Protokoll (Q.931). Gatekeeper Ein Gatekeeper ist in einem VoIP-Netz nicht obligatorisch, in einem Netz mit mehreren Teilnehmern aber unverzichtbar. In sehr kleinen VoIP-Netzen obliegt den einzelnen Terminals die Verwaltung der Telefonnummern und IP-Adressen. Der Gatekeeper ist innerhalb des LAN für die Verwaltung der Terminals verantwortlich und beantwortet alle Fragen, die mit der Adressierung, Authentifizierung und der Autorisierung von Teilnehmern zusammenhängen. Endgeräte und Gatekeeper kommunizieren über das RAS-Protokoll (Registration, Admission, Status, H.225) miteinander. Dazu werden kurze Protokollelemente wie RegistrationRequest (RRQ), AdmissionRequest (ARQ) und InfoRequest IRQ ausgetauscht und entsprechend bestätigt. Zur Rufkontrolle wird das Protokoll H.225.0 eingesetzt, das die typischen Nachrichtenelemente der ISDN-Signalisierung (Q.931) verwendet. Die grundlegenden Aufgaben eines Gatekeepers sind: x Übersetzung von symbolischen Adressen in IP-Adressen x Verwaltung der Gesamtbandbreite innerhalb des Netzes (Begrenzung der Anzahl gleichzeitig möglicher Gespräche bzw. Ablehnung eines Gesprächswunsches) x Zuweisung der gewünschten bzw. möglichen Ressourcen zu den Endgeräten x Gebührenerfassung x Routing-Funktionen (bei Bedarf) x Zugangskontrolle und Authentifizierung Der zuständige Gatekeeper wird über die IP-Adresse den Terminals fest zugeordnet oder dynamisch per Multicast-Suche erkundet. In größeren Netzen werden mehrere Gatekeeper eingesetzt (GatekeeperZone), die das gesamte VoIP-LAN in einzelne logische H.323-Zonen strukturieren, die von der physikalischen Netzwerktopologie unabhängig sind. VoIP-Gateway Das optionale VoIP-Gateway, auch Media-Gateway genannt, bildet die physikalische und logische Schnittstelle zwischen einem VoIP-LAN und einem Netz oder Netzteil, der mit konventioneller Telefontechnik arbeitet. Dies kann ein WAN sein oder ein Teilnetz innerhalb eines


■ ■ ■

165

Unternehmens. Zu den wesentlichen Aufgaben eines Gateways gehören die Umsetzung der synchronen WAN-TDM-Kommunikationsströme in asynchrone IP-Pakete, die Umwandlung in ein passendes CodecFormat und die Kontrolle und Steuerung der Verbindungen und der Echtzeitströme zum Gateway des aktuell verbundenen VoIP-Netzes. Ist keine WAN-Anbindung erforderlich, kann das Gateway entfallen. VoIP-Gateways kommunizieren untereinander mit Hilfe der Protokolle MGCP (Media Gateway Control Protocol) und Megaco, die an dieser Stelle nicht näher beleuchtet werden. Multipoint Control Unit MCU Eine MCU unterstützt Punkt-zu-Mehrpunkt-Verbindungen für Sprache und Video im Rahmen einer Konferenzschaltung. Der MCUController verhandelt mit allen Teilnehmern über die verwendeten Protokolle. Der optionale Multipoint-Prozessor (MP) ermöglicht es, Konferenzen mit an die Endgeräte individuell angepassten Bitraten und Codecs durchzuführen. H.323 leidet neben seiner Komplexität vor allem daran, dass ihm der Standardisierungs-Spagat zwischen der leitungsvermittelten ISDN-Welt und der verbindungslosen IP-Welt in einigen Punkten nur unzureichend gelingt. Zudem schöpft er nicht alle Potentiale der IP-basierten Kommunikation aus. Für die Signalisierung – nicht den Transport der Echtzeitdaten – gewinnt die Alternative SIP, zunehmend an Bedeutung. 3.4.2.4 Session Initiation Protocol (SIP) SIP orientiert sich im Gegensatz zu H.323 in keinster Weise an den Kommunikationsabläufen in herkömmlichen Telefonnetzen, sondern setzt konsequent auf den Internet-Standard-Protokollen wie HTTP auf. Das verbindungsorientierte SIP, das von der IETF spezifiziert wurde (RFC 2543, RFC 3261), ist ein Protokoll, das interaktive Multimedia-Sessions zwischen zwei oder mehreren Teilnehmern mit Hilfe einfacher ASCI-Nachrichten (Plaintext-Messages) einrichten, verwalten und abbauen kann. SIP ist keineswegs nur auf den VoIP-Einsatz beschränkt, sondern wird in zukünftigen Multimedia-Netzen eine der tragenden Protokollsäulen sein. SIP ist eng an die Struktur von IP-Applikationen angelehnt und wird als das Konvergenzprotokoll angesehen, mit dessen Hilfe die nahtlose Migration unterschiedlichster Services in IP-Umgebungen gelingen soll. Im Gegensatz zu H.323, das viele Hilfsprotokolle zur Sitzungssteuerung einsetzt, greift SIP nur auf das Session Description Protocol (SDP) zurück.

166

■ ■ ■

3 Multimedia-Netze

Das SDP überträgt zu Beginn der Kommunikation eine Liste der zu übertragenden Medien und den zugehörigen Quellcodecs, der Empfänger wählt ohne weitere Abstimmung mit dem Sender einen passenden Codec aus. SIP übernimmt fünf unverzichtbare Aufgaben: x Bestimmung der Endgeräte, um die gewünschten Teilnehmer zu erreichen x Überprüfung, ob der gewünschte Teilnehmer an der Kommunikation teilnehmen will oder kann x Auswahl von Kompressionsverfahren und Medium x Festlegung und Einrichtung der Parameter für die einzurichtende Sitzung x Management einer Sitzung und dynamische Änderung von Sitzungsparametern (zum Beispiel Umstecken des Endgeräts)

Session Description Protocol SDP

Aufgaben von SIP

SIP-Transaktionen arbeiten nach dem bekannten Client-ServerPrinzip. Wie in der Internet-Kommunikation üblich, bezeichnet SIP den Anrufer konsequenterweise als Client und den Angerufenen als Server, die SIP-Protokollelemente (SIP-Requests und SIP-Responses) selbst sind textbasiert und der Syntax des bekannten http-Protokolls sehr ähnlich. Abbildung 3.22 zeigt die wesentlichen Elemente einer SIP-Architektur. Abb. 3.22: SIP-Architektur

User Agent UA: Ein UA ist ein SIP-Telefon (HW oder SW) mit einem UA-Client (UAC, Initialisieren einer Sitzung) und einem UA-Server (UAS, nimmt Anforderungen des UAC entgegen). Die Funktionen eines UAC bzw. UAS kann je nach Anforderung der Transaktion jedes SIP-Netzelement übernehmen, zum Beispiel auch ein SIP-Proxy-Server. In Spezialfällen,


User Agent

■ ■ ■

167

in denen die IP-Adresse bekannt ist, können zwei Endgeräte direkt Kontakt zueinander aufnehmen. In der Regel wird jedoch mit Hilfe nachfolgend beschriebener spezialisierter Server (RFC 3261) sichergestellt, dass ein Teilnehmer (weltweit) eindeutig auch dann adressierbar ist, wenn er sich temporär in einem anderen Netz aufhält und die IPAdresse nicht bekannt ist. Proxy-Server: Proxies empfangen und bearbeiten Nachrichten stellvertretend für einen Client bzw. Server. SIP-Proxies arbeiten zustandslos (stateless) oder zustandsbehaftet (stateful). In der Regel wird die SIP-Kommunikation zwischen UAC und UAS über einen SIP-Proxy mit Routingfunktionalität stattfinden. Er prüft zunächst, bei welchem Registrar der gewünschte Teilnehmer eingetragen bzw. angemeldet ist. Der Registrar teilt ihm dann die aktuelle IP-Adresse des Ziels mit. Je nach Konfiguration kann der Proxy die Session-Kontrolle auch wieder an den ursprünglichen SIP-UA übergeben. Im Gegensatz zu einem „stateless proxy“ arbeitet ein „stateful proxy“ als UAC bzw. UAS, interpretiert die SIP-Nachrichten und erzeugt bei Bedarf eigene Meldungen. Redirect-Server: Er übernimmt die Weiterleitung von Nachrichten (SIP-Request) zu anderen Zielpunkten. So kann er beispielsweise dem anfragenden User Agent oder Proxy die Mobilfunknummer eines Teilnehmers mitteilen, wenn dieser Teilnehmer aktuell auf seinem SIP-Festnetzanschluss nicht erreichbar ist. Registrar-Server

Registrar-Server: Der Standort oder auch die öffentliche IP-Adresse eines UA kann sich ständig verändern. Damit er trotzdem erreichbar bleibt ist ein Registrar-Server vonnöten. Der Registrar bildet die SIP-Adresse auf die aktuell gültige IP-Adresse ab, so dass SIP-Teilnehmer jederzeit unter ihrer SIP-URL erreichbar sind. Mehreren UA können bei gleicher Nutzerkennung mehrere IP-Adressen zugeordnet werden, so dass ein Anruf an allen Standorten signalisiert werden kann.

Location-Server

Location-Server: Er verfügt in enger Zusammenarbeit mit dem Registrar-Server über Informationen bzgl. des momentanen Aufenthaltsortes eines Teilnehmers. Er kann Anwender zurückverfolgen und URL-Bindings ermitteln, die dem Ziel aktuell „näher“ liegen. Zu jedem Zeitpunkt ist dem Location-Server bekannt, wie ein Teilnehmer aktuell erreicht werden kann, eventuelle Weiterleitungsadressen teilt er dem anfragenden Client mit. Im Gegensatz zum SIP-Registrar erlaubt er es, registrierte Benutzer anhand ihrer SIP-Adresse zu suchen.

168

■ ■ ■

3 Multimedia-Netze

Die beschriebenen Server-Varianten sind als logische Einheiten zu sehen (SW-Module), so dass durchaus mehrere Funktionen in einem Server realisiert sein können. In einer einfachen SIP-Kommunikationsinfrastruktur innerhalb eines LAN werden Proxy-, Registrarund Location-Server typischerweise gemeinsam auf einem Rechner installiert. Die SIP-Adressierung funktioniert analog zu Web-Anwendungen mit Hilfe einer SIP-URI oder SIP-URL (Uniform Resource Identifier bzw. Locator). Beispiele hierzu: x sip:[email protected] bzw. x sip:[email protected] x sip:[email protected]. Die statische Zuordnung einer SIP-URI ist möglich (feste IP-Adresse), so dass eine weltweite Erreichbarkeit sichergestellt werden kann. Eine Auflösung der Alias-Namen in IP-Transportadressen erfolgt per DNS. Da SIP mittels SIP-Gateway auch mit dem traditionellen leitungsvermittelten Telefonnetz zusammenarbeitet, kann der User-Teil durchaus eine Telefonnummer enthalten Die Kommunikation zwischen den Netzelementen geschieht mit Hilfe von SIP-Request und SIP-Response-Nachrichten. Die RequestNachrichten, auch Methods genannt, sind: Invite, ACK, Cancel, Bye, Register und Options. Eine Invite-Nachricht beschreibt die gewünschte Session mit Hilfe des Session Description Protocol (SDP). Einen einfachen Ablauf (direkte UAC-UAS-Kommunikation ohne weitere Serverfunktionalität zeigt Abb. 3.23. Abb. 3.23: einfacher SIP-Ablauf zwischen UAC und UAS


■ ■ ■

169

Abb. 3.24: SIP-Proxy und SIP-Redirect-Server

SIP-Probleme

170

■ ■ ■

Ein SIP-Request wird mit einem Response-Code beantwortet, der über den laufenden oder erfolgreichen Verbindungsversuch informiert (Code 100199 bzw. 200299) oder Meldungen (3xy6xy), die sich auf fehlerhafte Umleitung, Client-bzw. Serverfehler oder allgemeine Fehler beziehen. Abbildung 3.24 (nach [KIEF3]) zeigt den prinzipiellen Ablauf bei Einsatz eines Proxy-bzw. Redirect-Servers. Die meisten Anbieter für die WAN-VoIP-Telefonie favorisieren mittlerweile SIP gegenüber H.323. Da sich die Philosophie von H.323 stark am herkömmlichen Telefonnetz orientiert, während SIP Internet-orientiert arbeitet, werden viele zukünftige web-basierte Applikationen den Einsatz von SIP favorisieren. Allerdings ist SIP aktuell im praktischen Einsatz nicht so problemlos, wie es vielleicht erscheinen mag. Die diversen SIP-Implementierungen der einzelnen Hersteller sind noch nicht durchgängig zueinander kompatibel, nicht alle Fragestellungen im Zusammenhang mit SIP sind in den entsprechenden RFCs beantwortet.

3 Multimedia-Netze

Die komfortablen Leistungsmerkmale herkömmlicher Telefonanlagen lassen sich nicht ohne weiteres auf SIP-basierte Anlagen abbilden, zusätzlicher Telefonie-Komfort ist teilweise nur mit erheblichen Aufwand realisierbar. Der Grund liegt in der direkten Kommunikationsbeziehung zweier Endgeräte, nachdem der Verbindungsaufbau abgeschlossen wurde. Dadurch kann ein SIP-Server beispielsweise das Ende eines Gesprächs nur durch direktes Nachfragen (Polling) bei den Endgeräten erkennen. Ein von einem dritten Endgerät angefordertes und vom SIP-Server verwaltetes Dienstmerkmal wie „Rückruf bei Besetzt“ ist somit nur aufwändig implementierbar. Die Sicherheitsproblematik beim Einsatz von SIP kann nicht überbewertet werden. Viele Firmen führen VoIP ohne angemessene Sicherheitsarchitektur ein, bzw. ohne die vorhandenen Sicherheitsmassnahmen an die Erfordernisse von VoIP zu adaptieren. Hier sind Ansätze wie der verstärkte Einsatz von Virtual Private Networks (VPN), die Integration von VoIP in die Datenapplikationen oder der Einsatz von SIP-Secure (SIPS) erforderlich. Die dynamisch vergebenen UDP-Ports erschweren das Zusammenspiel der VoIP-Kommunikation mit Firewalls bzw. NAT-Routern. Hier müssen die Firewalls lernen, für VoIP benötigte Ports trotz einer eventuellen Verschlüsselung zu erkennen und temporär freizuschalten. Zudem muss eine NAT-Firewall eine gerade aufgebaute SIP-Session mit den unmittelbar folgenden RTP-Paketen als logisch zusammenhängende Verbindung erkennen können. Diverse Lösungsansätze für diese Problematik sind in Diskussion (STUN-Server, Simple Traversal of UDP through NAT). Die beinahe reibungslose Integration der Sprachkommunikation in die IP-Welt bedingt auch die Bedrohung von VoIP durch eine Vielzahl von IPAngriffsformen. Als äußerst unschöne Begleiterscheinungen seien an dieser Stelle exemplarisch Denial-of-Service-Angriffe, SIP-Spam, Spoofing, SIP-Registration- oder Call-Hijacking genannt. Um die Sicherheit von VoIP weiter zu entwickeln wurde 2005 von namhaften Herstellern, Carriern und Universitäten die Voice over IP Security Alliance (VOIPSA) gegründet [VOIP]. Sie will das Bewusstsein für VoIP-Sicherheitsfragen schärfen und konkrete Empfehlungen für die Weiterentwicklung der VoIP-Sicherheit aussprechen.

VoIP-Sicherheit

3.4.2.5 Multimedia-Transport: Real-Time-Transport-Protocol RTP Ende-Ende-Protokolle der Ebene 4 (TCP und UDP) sind für die Echtzeitkommunikation wie die Übertragung von Multimediadaten nicht geeignet: UDP stellt lediglich die Zustellung an einen bestimmten Port sicher, verfügt aber über keinerlei Mechanismen, während der


■ ■ ■

171

RTCP

Übertragung auftretende Probleme zu lösen. TCP scheidet für die Echtzeitkommunikation aufgrund der verzögerungsintensiven Bestätigungsprozeduren aus. Zudem verfügen weder TCP noch UDP über eine explizite Möglichkeit, Multicast zu übertragen. Der Real-TimeSpezialist RTP ist ein tragfähiger Lösungsansatz für die multimediale Echtzeitkommunikation. RTP besitzt keine QoS-steigernden Eigenschaften, liefert aber ein stabiles Grundgerüst, um Multimediasignale – nicht nur VoIP – zwischen den Endgeräten einer Punkt-zu-(Mehr) Punkt-Beziehung zuverlässig auszutauschen. Wie bewerkstelligt RTP diese Aufgabe? Haben sich Endgeräte mit Hilfe der in den vorangegangenen Kapiteln beschriebene Signalisierung gefunden und über die Art der auszutauschenden Daten verständigt, wird eine RTP-Session aufgebaut. In der Regel arbeitet RTP hierzu mit seinem „Leibwächter“ RTCP (RTP Control Protocol) zusammen, der eine RTP-Session mit Kontroll- und Statusinformationen kontinuierlich überwacht und regelmäßige Berichte über die Empfangsqualität und die Ressourcen des Empfängers liefert. Die Portnummer wird beim Initiieren der Verbindung frei verhandelt, RTCP nutzt die um den Wert Eins erhöhte RTPPortnummer. Im Falle der gleichzeitigen Übertragung von Bild und Ton wird jeweils ein Portpaar für die einzelnen Audio- und Videoströme generiert. Die logische Zuordnung und Verknüpfung beim Empfänger erfolgt über eine eindeutige Teilnehmerkennung, die per RTCP übertragen wird. Die RTP/RTCP-Kanäle werden in UDP-Pakete eingepackt und hoffnungsvoll dem leider garantiefreien IP anvertraut. RTP muss nicht immer zwingend mit RTCP verknüpft sein. Beispielweise kann im Falle eines für den Nutzer kostenfreien AudioDienstes über das Internet auf RTCP verzichtet werden. Grundlegende Funktionsmerkmale von RTP/RTCP sind: x Kennzeichnung und Synchronisierung der Sende- und Empfangspakete mit Hilfe von Zeitstempeln und eindeutiger Teilnehmerkennungen (canonical name). Trotz schwankenden Verarbeitungszeiten der Pakete während des Transports können die ursprünglichen Zeitabstände des Senders reproduziert und die Streams eindeutig zugeordnet werden. Somit können Jittereffekte zumindest auf ein akzeptables Maß reduziert werden. x Zuordnung eindeutiger Sequenznummern. Der Identifikator wird zufällig aber in Bezug auf die Sitzung eindeutig gewählt und ermöglicht es, eine eventuelle Vertauschung der Reihenfolge der Pakete zu detektieren x Kennzeichnung des Payload-Typs (verwendeter Audio- oder Videocodec)

172

■ ■ ■

3 Multimedia-Netze

x Adaption an variable Dienstqualitäten. RTP ist nicht bekannt, über welche Qualitätsmerkmale (im einfachsten Fall die Bandbreite) der Übertragungsweg verfügt. RTCP liefert dem Sender ein Feedback in Form von periodischen Statistiken über die Empfangsqualität, die es den Kommunikationspartnern ermöglichen, die laufende Session zu optimieren (Senderate, Kompressionsverfahren). x Unterstützung von Multicast-Sitzungen (Videokonferenzen). RTCP liefert in diesem Fall zusätzlich Metainformationen (Name, Kennung, Standort…), um neue oder ausgetretene Sitzungsteilnehmer zu erkennen. RTCP-Pakete werden den Sitzungsteilnehmern per Multicast zugestellt. Während der RTP-Verkehr von der Zahl der Empfänger unabhängig ist, steigt der RTCP-Verkehr mit zunehmender Anzahl der Sitzungsteilnehmer. Die Skalierbarkeit von RTCP ist nicht überzeugend, der Standard sieht einen RTCP-Anteil von 5% an der für die Sitzung zur Verfügung stehenden Bandbreite vor. Mindestens 25% dieser Bandbreite soll für die Übertragung von Sendeberichten eingesetzt werden. Im Fall von Bandbreiteengpässen oder vielen parallelen Sitzungen wird die Zahl der RTCP-Pakete pro Sitzung dynamisch reduziert. Bei Bedarf können mehrere RTP-Ströme mit Hilfe eines RTPMixers zu einem Stream zusammengefasst werden. Dies ist beispielsweise dann sinnvoll, wenn mehrere VoIP-Gespräche über eine WANStandleitung transportiert werden sollen. Ein RTP-Translator ist insbesondere erforderlich, um beispielsweise die Bandbreite oder den Codec anzupassen. Ein Firewall-Translator kann Firewalls überbrücken, die Multicast-Pakete blocken. Dazu werden die Multicast-Pakete in einen Unicast-Tunnel gepackt und durch die Firewall durchgeschleust.. Eine unverschlüsselte RTP-Übertragung zwischen Endgeräten ist potentiell unsicher und kann nach erfolgreichem physikalischen Zugang mit frei verfügbaren Tools mitgeschnitten und dekodiert werden. Der Einsatz des Secure-Real-Time-Transport-Protocol (SRTP), das in der RFC 3711 beschrieben ist, authentifiziert Nachrichten und sorgt für die Vertraulichkeit–allerdings um den Preis einer erhöhten Rechenzeit. Da dadurch die Gesamtlatenzzeit kritische Werte annehmen kann, ist der Einsatz von SRTP nicht unproblematisch. 3.4.2.6 RTSP (Real Time Streaming Protocol) Der Vollständigkeit halber sei das Protokoll RTSP erwähnt. RTSP ist eine Art „Fernbedienung“ für die Steuerung von Multimedia-Strömen. Dazu wird zwischen dem Multimedia-Server und dem Client


■ ■ ■

173

Abb. 3.25: Zusammenspiel von RTP, RTCP und RTSP

eine eindeutig identifizierbare Session aufgebaut. Innerhalb der Session kann RTSP nun mit Hilfe kurzer Commands den Ablauf der Multimedia-Sitzung steuern und zum Beispiel den Stream anhalten. Die Rolle von RTSP für die Übertragung von Multimediaströmen ist in etwa vergleichbar mit der Aufgabe von HTTP bei der Übertragung von HTML-Seiten. Abbildung 3.25 fasst die Aufgaben und das Zusammenspiel von RTP, RTCP und RTSP zusammen. 3.4.2.7 Bandbreiteanforderung für Voice-over-IP Abbildung 3.26 zeigt ein typisches IP-Sprachpaket wie es in einem LAN zwischen zwei Ethernet-Stationen übertragen wird. Die Größe der Payload ist primär durch den gewählten Codec bestimmt. In unserem Rechenbeispiel gehen wir davon aus, dass die Header der Protokolle RTP, IP und Ethernet jeweils nur die Minimalgröße aufweisen. Die Sprachproben sollen nach G.711 codiert sein (64 kBit/s) und der Codec alle 20 ms Pakete der Länge 160 Byte generieren. Abb. 3.26: Berechnung der Bandbreite einer VoIP-Verbindung

174

■ ■ ■

3 Multimedia-Netze

Die erforderliche Kapazität einer Verbindung liegt in der Größenordnung von 180 KBit/s, eine Bitrate, die die 100 MBit/s-Anbindung eines Clients im LAN mit Leichtigkeit bewerkstelligen kann. Im Falle knapper WAN-Bandbreiteressourcen für eine Session kann die Bitrate der VoIP-Verbindung weiter reduziert werden. Hierzu bieten sich alternativ oder ergänzend ein Codec mit geringerer Bitrate an, die Unterdrückung von Sprechpausen oder die Aktivierung der HeaderKomprimierung. 3.4.2.8 ENUM ENUM (TElephone NUmber Mapping, oder auch Electronic NUMbering) ist ein Standard (RFC 3761), der die Konvergenz von IP-Endgeräten und Endgeräten der klassischen Telekommunikation zu einem paketbasierten Kommunikationsnetz vorantreiben wird, indem verstreute „IP-Inseln“ zu einem einheitlichen Netz zusammengeführt werden. ENUM wandelt eine weltweit eindeutige Telefonnummer im international eingeführten E.164-Format der ITU in ein Domainformat (DNS) um. ENUM ermöglicht es, die übliche Telefonnummer für aktuelle und zukünftige Internetdienste zu nutzen und ist damit ein wichtiger Baustein im Rahmen der Netzkonvergenz. Die Rufnummer 89232167 in Stuttgart (0711) besitzt im E.164-Format die international gültige Schreibweise:

ENUM-Nummernformat

+ 49-711-120-4665. Im ENUM-Format wird hieraus die Kennung 7.6.1.2.3.2.9.8.1.1.7.9.4.e164.arpa. ARPA ist eine Top-Level-Domain, e164.arpa die entsprechende second-level-domain und kann von allen Root-Servern erreicht werden. Die Nameserver verfügen über Einträge, die sich auf die Adressen der einzelnen Kommunikationsgeräte beziehen (Telefon, Handy, e-Mail, Videoterminal…). Anwender können die rückgemeldeten DNSEinträge beispielsweise zeitlich priorisieren, so dass zu bestimmten Zeiten das Handy klingelt oder die Erreichbarkeit per FAX propagiert wird. „Eine Nummer für alle Dienste“ ist dabei das Ziel.


■ ■ ■

175

ENUM setzt sogenannte Naming Authority Pointer Records (NAPTR) ein. Per DNS wird zu einer entsprechenden Nummer ein NAPTR-Eintrag aufgerufen, der unter anderem detaillierte Informationen zu den aktuellen Kommunikationsmöglichkeiten des gewünschten Teilnehmers enthält. Da ENUM-DNS-Einträge zwangsläufig auch Daten und Informationen aus der Privatsphäre enthalten und potentielle Angreifer Kommunikationsflüsse per DNS-Spoofing umleiten oder attackieren können, spielt auch bei ENUM die Sicherheit eine große Rolle. Hier sind einige Fragestellungen nur ansatzweise oder unzureichend gelöst [ENUM].

3.4.3 IP Next Generation – IPv6 Das vielbeschworene IPv6, auch treffenderweise als IPng bezeichnet (IP next generation) ist das Protokoll, das die Migration und Konvergenz des Internets zu einer einheitlichen Technologie-Plattform für Multimedia-Anwendungen vorantreiben wird. IPv6 wird echte IPMobilität ermöglichen, Streaming konsequent unterstützen, die Sicherheit der Übertragung erhöhen und Routing deutlich effizienter gestalten. Auch die Einführung von IPv6 unterliegt seit seiner grundlegenden Verabschiedung durch die IETF im Jahre 1994 dem typischen HenneEi-Problem. Das Hauptargument, dass IPv4 nicht mehr genügend freie Adressen bieten kann, hat in vielen Fällen durch den Einsatz von NAT und Proxy-Servern an Bedeutung verloren und den Druck für eine schnelle Migration zu IPv6 vermindert. Alle Carrier experimentieren im Core-Bereich der Transportnetze mit IPv6, innovative und risikofreudige Provider bieten IPv6 sogar an der Netzschnittstelle zum Kunden an. UMTS wird mit der Einführung des IMS (IP Multimedia System) die Notwendigkeit, IPv6 einzuführen, auch von der Endgeräteseite aus vorantreiben. Der Trend, in (mobilen) Endgeräten beide IP-Protokollstacks zu implementieren, ist unverkennbar. Die Standard-Betriebssysteme unterstützen IPv6 bereits seit einigen Jahren. Für einen echten Durchbruch von IPv6 mangelt es aber immer noch vor allem an durchgängig kompatibler Hardware. Insbesondere in Asien hat IPv6 deutlich an Boden gewonnen. Hier ist der Mangel an IPv4-Adressen besonders eklatant und treibt die Implementierung von IPv6 voran. Den IP-Transport der Zukunft bewerkstelligt IPv6 recht elegant (Abb. 3.27).

176

■ ■ ■

3 Multimedia-Netze

Abb. 3.27: Aufbau des Protokolls IPv6

Die grundlegenden Charakteristika von IPv6 sind: x 128 Bit große Adressen (statt 32 Bit bei IPv4) ermöglichen Adressräume, die selbst für visionäre Applikationen ausreichen werden. Die zukünftige Vielzahl an intelligenten Endgeräten im persönlichen Umfeld des Menschen können damit über IP angesprochen werden. x Der Header von IPv6 hat immer eine konstante Länge von 40 Byte und transportiert auf das Paket und den zugehörigen Stream bezogene Basisinformationen. Zusätzliche Aufgaben und Funktionen werden durch eine verkettete Liste von Extension-Headern umgesetzt, die in der erforderlichen Anzahl in einer definierten Reihenfolge (RFC 2460) an den Basisheader angehängt sind und sequentiell aufeinander folgen. Beispiele für Extension-Header sind: – Hop-by-Hop-Option – Routing-Header – Authentication Header – Destination Options Header – Fragment Header x Ein Flow-Label kennzeichnet alle zusammengehörigen Pakete beispielsweise einer Audio- oder Videoverbindung. Alle Pakete eines Flows weisen identische Quell- und Ziel-Sockets auf und werden anhand des Flow-Labels weitergeleitet.


■ ■ ■

177

x Das Feld Traffic-Class ermöglicht die Zuordnung eines Pakets zu einer bestimmten Qualitätsklasse, aktuell werden dort die DiffServZuordnungen eingesetzt. Die Zielrichtung dieser Maßnahmen: die Routing-Entscheidung muss effizienter und schneller erfolgen bzw. muss sichergestellt sein, dass eine dienstabhängige Routingentscheidung getroffen werden kann. x Sowohl die zeitund ressourcenaufwändige Prüfsummenbildungund auswertung als auch die Paketfragmentierung durch die Router entfällt. Letztere ist nur in Ausnahmefällen unter Zuhilfenahme des Fragment Headers erlaubt. Um die Fragmentierung während des Transports durch das Internet zu vermeiden, erkunden die Endgeräte die maximal zulässige Paketlänge mittels der Path MTU Discovery und passen die Paketlänge entsprechend an. x IPsecure (IPsec), bisher als separates Protokoll im Einsatz, ist integraler Bestandteil von IPv6.

IPv6-Adressen

IPv6 schafft den Begriff der Broadcast-Adressierung ab und definiert ihn als Spezialfall der Multicast-Adressierung um. Multicast-Techniken sind deutlich einfacher implementierbar. Neu ist die Anycast-Adressierung, die eine Gruppe von definierten Adressen anspricht, die einem oder mehreren Interfaces zugeordnet sind. Ein Router kann dadurch beispielsweise aufgrund von Statusinformationen der Server entscheiden, an welchen der Server einer Anycast-Gruppe er ein Paket weiterleitet. Das Ziel der Anycast-Adressierung ist es, die Gesamtlast auf mehrere Knoten zu verteilen und gleichzeitig redundante Strukturen zu schaffen ([IPV6]). Selbst wenn die Endgeräte der Zukunft mit IP-Adressen verschwenderisch umgehen sollten, wird der überaus mächtige Adressraum von IPv6 (128 Bit-Adressen) auch in fernster Zukunft genügend Adressen bereitstellen können. Ein Interface kann mehrere IPv6-Adressen besitzen, wobei beliebige Kombinationen von Unicast-, Multicast- und Anycast-Adressen zulässig sind. Die letzten 64 Bit einer IPv6-Adresse identifizieren ein Interface, die ersten 64 Bit werden variabel verwendet. Zur Zeit sind erst etwa 15% des gesamten Adressraums zugewiesen (RFC 3513). Eine IPv6-Adresse besteht aus den drei Teilen Routingpräfix, Subnet-ID und Interface- ID (Abb. 3.28).

Abb. 3.28: Aufbau von IPv6-Adressen

178

■ ■ ■

3 Multimedia-Netze

Das Globale Routing-Präfix identifiziert den Adressbereich, der von den bekannten Registry Services (in Europa RIPE) an Internet Service Provider und große Organisationen vergeben wird (RFC 3177). IPv6 verwendet ausnahmslos die von der klassenlosen IPv4-Adressierung (CIDR) bekannte Präfix-Schreibweise (zum Beispiel FE90/12, vgl. RFC 3513). Die für IPv4 typischen Subnetzmasken entfallen. Reservierte nur lokal gültige Adressen (Link-Local-Adressen) und Neighbor Discovery ermöglichen es IP-Empfängern, sich selbständig zu erkennen und ohne Router oder DHCP-Server zueinander Kontakt aufnehmen zu können. Die MAC-Adresse genügt einem IPv6-Gerät zur Berechnung der Link-Local-Adresse, anhand derer es innerhalb der Domäne installierte Router ausfindig machen kann. Die Unique-Local-Adressen (RFC 4193) ersetzen die reservierten privaten Adressen von IPv4, die ursprüngliche eingeführte Bezeichnung der Site-Local-Adresse wird nicht mehr verwendet. Zur effizienteren Darstellung von IPv6-Adressen wird die hexadezimale Schreibweise herangezogen. Zur Vereinfachung der Schreibweise können führende Nullen pro Block entfallen und pro Adresse aufeinanderfolgende Nullblöcke durch einen Doppelpunkt ersetzt werden. Ein Beispiel:

IPv6-Adressdarstellung

FE90:0000:0000:0000:0000:0347:FD22:0001 wird zu FE90::347:FD22:1 Spezielle Adressen unterstützen die Migration zu IPv6 (RFC 3513, IPv4-compatible-IPv6-Adresse bzw. IPv4-mapped-IPv6). Das bekannte Internet Control Message Protocol ICMP wurde als ICMPv6 um einige Funktionen–beispielsweise die Neighbor Discovery–erweitert. Standard-Protokolle wie DHCP, aber auch die Routing-Protokolle werden ebenfalls in einer IPv6-kompatiblen Version eingesetzt werden. DNS-Server müssen zukünftig auch IPv6-Einträge verwalten. Insbesondere die Anforderungen an die Mobilität von IP-Geräten werden weiter steigen. Das Protokoll Mobile IPv6 erlaubt die Mobilität von IP-Geräten in verschiedenen Netzwerken, ohne dass eine bestehende Verbindung unterbrochen wird [HAGE]. In der langjährigen Übergangsphase zu einem reinen IPv6-Netz werden sich immer weiter ausbreitende „IPv6-Inseln“ entstehen, innerhalb derer IPv4-Pakete durch diverse Tunneling-Verfahren transportiert werden können. [MUN] informiert zu Migrationsaspekten von IPv6.


■ ■ ■

179

3.4.4 Multicast Multicast ermöglicht die gleichzeitige Übertragung eines Datenpakets zu mehreren Empfängern und nutzt dadurch die Bandbreite des Transportnetzes deutlich besser aus. Erste Versuche mit einer Multicast-Kommunikation fanden im Mbone (Multicast-Backbone) bereits zu Beginn der 90-er Jahre statt. Das Grundprinzip ist einfach: über eine virtuelle Baumstruktur werden die Sendedaten zu allen autorisierten Mitgliedern einer Gruppe verteilt. Nur an den Knoten, an denen Äste mit aktiven Gruppenmitgliedern angeschlossen sind, werden die Daten vervielfacht. Multicast-fähige Inseln im Internet werden über Unicast-Tunnel miteinander verbunden. Viele zukünftige Applikationen können ohne effiziente Multicast-Infrastruktur nicht mehr wirtschaftlich übertragen werden. Die Einsatzgebiete von Multicast sind vielfältig. Videokonferenzen, TV-Verteildienste (IP-TV) oder gemeinsame Bearbeitung von Multimedia-Dokumenten durch eine verteilte Gruppe. Zwingende Voraussetzung für eine Gruppenkommunikation und einen effizienten Verteildienst sind: x Multicast-Adressen zur Adressierung einer Gruppe von Endgeräten x Protokolle, die es ermöglichen, einer Multicast-Gruppe beizutreten bzw. sie zu verlassen x Multicast-fähige Router und Multicast-Routing-Protokolle Im IPv4 ist der Class D-Adressbereich von 224.0.0.0 bis 239.255.255.255 für Multicast reserviert, in IPv6 beginnt jede Multicast-Adresse mit FF00::/8. Um die Reichweite eines Multicast-Pakets gezielt einzuschränken und endloses Kreisen von Multicast-Paketen zu verhindern, wird der TTL-Wert des IP-Pakets herangezogen. Je nach Wahl des TTL-Wertes ist die Reichweite auf ein Subnetz, eine Domäne, eine Region oder einen Kontinent begrenzbar. Die Steuerung der Zugehörigkeit zu einer Multicast-Gruppe erfolgt mittels des Protokolls IGMP (RFC 2236). Wesentliche Multicast-Routing-Protokolle sind das antiquierte DVMRP (Distance Vector Multicast Routing Protocol), das MulticastOSPF (Open Shortest Path First) und das Protocol Independant Multicast (PIM). In Deutschland sind in den kommenden Jahren hohe Investitionen der Carrier erforderlich, um eine effiziente Multicast-Infrastruktur für neue Dienste bereitzustellen.

180

■ ■ ■

3 Multimedia-Netze

3.4.5 Fazit Das NGN wird Basis für eine Vielzahl neuer Applikationen und Dienste sein. Im Gegensatz zu heutigen Netzen, die sich primär als intelligenter Datenspediteur verstehen, arbeitet das NGN konsequent diensteorientiert. Für ein tragfähiges Ende-Ende-NGN muss die Konvergenz auf drei Ebenen erfolgen: x Konvergenz der Netzwerke x Konvergenz der Dienste und Applikationen x Konvergenz der Endgeräte Der Technologiemix spielt im NGN eine untergeordnete Rolle. Die Landschaft der technischen Kommunikation wird in Bezug auf die Zugangsnetze an Heterogenität noch zunehmen. Das NGN muss dafür sorgen, dass trotz dieser komplexen Vielfalt ein sinnvolles gut skalierbares Gesamtsystem besteht, das multimediale Dienste unabhängig vom Zugangsnetz zuverlässig und sicher bei hoher Qualität bereitstellt. IP wird als Mittler zwischen Ende-Ende-Applikationen und Transportnetzen insbesondere als IPv6 eine tragende Rolle spielen. Desweiteren wird die Multicast-Fähigkeit des Internet Next Generation entscheidend dazu beitragen, dass ein universell einsetzbares Netz entstehen kann. Aufgrund der offenen Standards wird das NGN einen deutlichen Mehrwert gegenüber den bisherigen Netzen bieten. Desweiteren wird die Personalisierung von Inhalten und Angeboten charakteristisch für das NGN sein. Gewünschte Dienste und Inhalte können beliebig zusammengestellt und zu Kommunikationsgruppen gebündelt werden, die auch mobil verfügbar sind. Die klassischen Wertschöpfungsketten werden sich drastisch verändern.

Literatur [BADA] [DECI] [ENUM] [HAGE] [HELV] [IPV6] [KIEF1] [KIEF2]

A. Badach: Voice over IP–Die Technik, Hanser Fachbuchverlag, 2005 www.de-cix.net/stats www.enum-center.de S.Hagen: IPv6, Sunny Edition (2004) H. van Helvoort: Next Generation SDH/SONET, Wiley&Sons (2004) www.ipv6forum.com/ R. Kiefer: Test solutions for digital networks, Hüthig, 1998 R. Kiefer, P.Winterling: DWDM, SDH & Co, Hüthig, 2002


■ ■ ■

181

[KIEF3]

R. Kiefer, M. Reif: Voice-over-IP-Projekte in Lokalen Netzen, expertVerlag, 2006 [KIEF4] R. Kiefer, P.Winterling: Optische Netze, c’t 2/2003, Heise-Verlag [METR] www.metroethernetforum.org [MPLS1] www.mplsrc.com [MPLS2] www.mfaforum.org [MUN] Y.Mun, H.Lee: Understanding IPv6, Springer-Verlag, 2005 [NET] N.Hahn, Optik löst Elektronik ab, NET 5/06 [NÖLL] J. Nölle, Voice over IP, vde-Verlag, 2005 [ORLA] H.Orlamünder: Paket-basierte Kommunikationsprotokolle, Hüthig, 2003 [QUEU www.openbsd.org/faq/pf/de/queueing.html [RECH] J. Rech: Ethernet, dpunkt-Verlag, Heidelberg, 2002 [SIEG] G.Siegmund: Next Generation Networks, Hüthig, 2003 [SIEM] www.networks.siemens.de/solutionprovider/online lexikon/ [TRIC] U.Trick, F.Weber: SIP, TCP/IP und Telekommunikationsnetze, Oldenbourg-Verlag, 2005 [VOIP] www.voipsa.org [RFC] Alle im Kapitel erwähnten RFC sind abrufbar unter http://www.rfc-editor.org/

182

■ ■ ■

3 Multimedia-Netze

4 Mobile Multimedia Johannes Maucher, Thomas Suchy

Die Mobilkommunikationssysteme der zweiten Generation bescherten der Mobilfunkbranche in den vergangenen Jahren zuvor nicht erwartete Umsatzsteigerungen. Inzwischen (Stand Oktober 2005) werden Mobiltelefone weltweit von mehr als 2 Milliarden Menschen benutzt. Die höchsten Zuwachsraten verzeichnen derzeit Regionen mit noch relativ geringer Mobilfunkdichte wie China, Indien, Osteuropa, Lateinamerika und Afrika. In den meisten westeuropäischen Ländern sowie in den Vereinigten Staaten liegt die Marktsättigung bei nahezu 100%. Trotzdem rechnet die Mobilfunkbranche auch in diesen Regionen mit weiter wachsenden Märkten. Dieser Optimismus gründet auf den Annahmen, dass erstens der Zugang zu mobilen Diensten erweitert und verbessert wird und zweitens neue Dienste entwickelt, angeboten und genutzt werden. Sowohl der umfassendere und komfortablere Zugang zu Diensten als auch die Bereitstellung neuer Dienste erfordert zum Teil grundlegend neue Konzepte, Architekturen und Funktionalitäten der Netze und Endgeräte. Zukünftige Mobilfunksysteme sollen den Nutzern die Zusammenstellung eines individuellen Dienstportfolios aus einem reichhaltigen Angebot ermöglichen. Ein ausreichender Schutz von Teilnehmeridentität, Dienstnutzung und Datenübertragung sowie transparente und einheitliche Abrechnungsmodelle sind wesentliche Voraussetzungen für die Akzeptanz und Nutzung neuer mobiler Dienste. Andererseits müssen die neuen Netztechnologien sowohl herkömmlichen als auch neuen Unternehmensformen der Mobilfunkbranche die Möglichkeit zur Erschließung lukrativer Geschäftsmodelle und Umsatzströme bieten. Dies soll insbesondere durch modulare Systemarchitekturen mit sauber getrennten Funktionalitäten, die über offene Schnittstellen zugänglich sind, realisiert werden. Auf Seite der mobilen Endgeräte müssen neue Übertragungstechnologien integriert und sinnvolle Anwendungen erstellt werden, um die angebotenen Dienste der Netzbetreiber auch dem Nutzer nahe zu bringen. Hier sind zum einen die Gerätehersteller gefordert, die neuen Technologien hardware- und softwareseitig in ihren Geräten zu

4 Mobile Multimedia

Mobilfunkbranche im Wachstum

Neue Technologien müssen integriert werden

■ ■ ■

183

Abb. 4.1: Überblick Mobile Multimedia

Inhalt des Kapitels Mobile Multimedia

184

■ ■ ■

implementieren, zum anderen Software-Drittanbieter, die dem Endanwender die Nutzung dieser Dienste durch Entwicklung sinnvoller Anwendungen ermöglichen. Multimedia-Anwendungen stellen hier besondere Anforderungen sowohl an die Netze als auch an die Endgeräte. In diesem Kapitel wird ein Überblick über die wesentlichen Komponenten gegeben, die im Bereich Mobile Multimedia zusammenspielen (s. Abb. 4.1). Im ersten Unterkapitel werden neue aussichtsreiche Dienste, vornehmlich aus dem Bereich Mobile Multimedia, vorgestellt und deren Anforderungen an Netzwerkarchitektur und Funktion analysiert. Ausgehend von der Beschreibung und Bewertung des gegenwärtigen Stands der Technik werden die sich zum Teil schon im Standardisierungsprozess befindlichen zukünftigen Konzepte beschrieben und hinsichtlich ihrer Erfüllung der zuvor beschriebenen Anforderungen überprüft. Die Anwendungsentwicklung für mobile Endgeräte stellt spezielle Anforderungen an den Entwickler. In einem weiteren Teil dieses Kapitels werden die Besonderheiten der Software-Entwicklung für mobile Geräte beschrieben. Neben einem Überblick über die Hardware mobiler

4 Mobile Multimedia

Endgeräte werden die wichtigsten multimediafähigen Betriebssysteme und Software-Plattformen eingehend betrachtet. Darin enthalten sind einführende Hintergrundinformationen, Ausführungen über die Werkzeuge und Programmiersprachen, sowie Betrachtungen bezüglich der jeweiligen Multimediafähigkeiten. Am Ende folgen einige Ausführungen über wichtige Datenformate, die im Bereich mobile Multimedia eingesetzt werden.

4.1 Begriffsbestimmungen Mobile Multimedia betrifft die unterschiedlichsten Gebiete, sowohl im wissenschaftlichen wie auch im alltäglichen Bereich. Daher scheint es sinnvoll, einige Begriffe zunächst so zu bestimmen, wie sie in diesem Kapitel verstanden werden sollen. „Mobile“, zu deutsch „beweglich“, wird immer im Zusammenhang mit Netzen, Diensten, Endgeräten, Anwendungen verwendet. Es ist nicht ganz offensichtlich, wie beispielsweise der abstrakte Begriff „Netz“ mit der beschreibenden Eigenschaft „beweglich“ in Einklang zu bringen ist. Was versteht man also unter „mobil“ in den unterschiedlichen Zusammenhängen? Gemeinsam ist, dass die Eigenschaft der Mobilität bei der Implementierung berücksichtigt werden muss, diese den Unterschied zur Implementierung für nichtmobile Systeme darstellt. Im Hinblick auf mobile Netze bedeutet dies unter anderem, dass diese in der Lage sein müssen, die Mobilität des Nutzers zu unterstützen – eine Verbindung darf z. B. nicht abbrechen, wenn der Nutzer in seinem Auto unterwegs ist und per Mobiltelefon mit einem Geschäftspartner kommuniziert. Weitere Mobilitätstypen hinsichtlich der mobilen Netze sind in Kap. 4.2.1 beschrieben. Im Hinblick auf mobile Endgeräte erfordert „Mobilität“ andere Eigenschaften. Ob ein Endgerät als mobiles Endgerät bezeichnet werden kann ist offensichtlich eine Frage der Größe und des Gewichts: 1 mobiles Endgerät muss von einem einzelnen Menschen ohne Aufwand bewegt werden können. Dazu kommt, dass ein mobiles Gerät zumindest eine gewisse Zeit lang vom Stromnetz unabhängig sein muss. Daraus ergeben sich einige Besonderheiten in Bezug auf Hard- und Software, sowie Anwendungsentwicklung für mobile Endgeräte. Diese Besonderheiten werden in Kap. 4.3 beschrieben. Der Begriff „Multimedia“ erfuhr in den letzten Jahren einen inflationären Gebrauch – Werbeprospekte und Fernsehclips sind voll davon. Doch was soll in diesem Kapitel darunter verstanden werden? Multimedia setzt sich wiederum aus zwei weiteren für sich zu definierenden

4.1 Begriffsbestimmungen

„Mobile“: Eigenschaft der Mobilität muss bei der Implementierung berücksichtigt sein.

„Multimedia“: Kombination mehrerer Medien

■ ■ ■

185

„Mobile Multimedia“

Begriffen zusammen: „Multi“ steht für „mehrere“, „Media“ für „Medien“. Die Kombination mehrerer Medien also. Kombiniert man nun diese Begriffsbestimmungen mit der Definition von „Medien“ aus der Einleitung zu diesem Buch, so wird unter „Mobile Multimedia“ die Kombination mehrerer Überträger und Container zur Darstellung und Speicherung von Informationen verstanden, bei deren Implementierung die Eigenschaft der Mobilität berücksichtigt ist. In diesem weiten Feld sollen in diesem Kapitel multimediafähige mobile Netze sowie die Anwendungsentwicklung für multimediafähige mobile Endgeräte betrachtet werden.

4.2 Dienste und Architekturen zukünftiger mobiler Multimedia Netze 4.2.1 Mobilität und Multimedia – Anforderungen

Früher: Getrennte Netze für Sprachund Datendienste

186

■ ■ ■

Mobilfunknetze der Generation 2 (GSM), 2.5 (GPRS) und 3 (UMTS) werden auch heute noch vorwiegend für Sprachtelephonie benutzt. Für den Zugang zu hochratigen Datendiensten werden Festnetze wie z. B. DSL oder auch Drahtlosnetze wie WLAN oder WiMAX benutzt. Die zellularen Mobilfunknetze erlauben ein hohes Maß an Mobilität, so kann z. B. eine Sprachverbindung unterbrechungslos aufrechterhalten bleiben, auch wenn sich der Teilnehmer mit hoher Geschwindigkeit über mehrere Zellgrenzen hinweg bewegt. Hohe Teilnehmergeschwindigkeiten implizieren jedoch sehr ungünstige Ausbreitungsbedingungen der elektromagnetischen Signale im Mobilfunkkanal und damit eine starke Einschränkung der über den Kanal realisierbaren Datenraten. Andererseits können drahtlose Zugangsnetze, die eine sehr hohe Datenrate ermöglichen nur bedingte Teilnehmermobilität gewähren. Früher wurden Mobilfunknetze nahezu ausschließlich für Sprachtelephonie und niederratige Datendienste wie SMS benutzt. Aufgrund der hohen Echtzeitanforderungen von Sprachdiensten wurden die Netze entsprechend leitungsvermittelt realisiert. Andererseits unterlagen die von breitbandigen Netzen bereit zu stellenden Dienste geringen Echtzeitanforderungen und konnten damit packetvermittelt realisiert werden. Über das Internetprotokoll können heute nahezu alle paketvermittelten Netze zu einem globalen Supernetz zusammengeschlossen werden. Neben dieser integrierenden Funktion bietet die Internetprotokollfamilie vor allem auch einen gemeinsamen Standard, der eine Bereitstellung von paketvermittelten Datendiensten der verschiedensten Art unabhängig vom jeweiligen Zugangsnetz ermöglicht.

4 Mobile Multimedia

Die Entwicklung von Anwendungen und Diensten kann damit von der Übertragungstechnik getrennt werden Grundlage für die Entstehung einer breit gefächerten IT Branche und unzähligen GeschäftsmodellVarianten. Getrennt vom sämtliche Datennetze integrierenden Internet existieren und wachsen die Mobilfunknetze der zweiten Generation (2G) parallel und unabhängig. Die konträren Anforderungen der über Breitbanddatennetze und Kommunikationsnetze bereitzustellenden Dienste verlangten völlig unterschiedliche Vermittlungs- und Routingtypen. Lange Zeit galt die Bereitstellung derart unterschiedlicher Dienste über ein gemeinsames Netz als nicht realisierbar. Insbesondere gibt es in Mobilfunknetzen der zweiten Generation keine Trennung zwischen Anwendungs- und Dienstebene einerseits und Transport- und Zugangsebene andererseits. Eine zukünftige Integration von Kommunikations- und Breitbanddatennetzen in einem einzigen globalen IP-basierten Netz ist Ziel vieler Forschungs- und Entwicklungsaktivitäten seit Anfang der 90er Jahre. Ein solches integrierendes Netz soll einerseits der IT- und Telekommunikationsbranche eine weitere Steigerung ihrer Umsätze bescheren. Andererseits soll den Nutzern eine noch breitere Dienstpalette angeboten und ein sicherer, komfortabler und globaler Zugriff auf ein personalisiertes Dienstportfolio unabhängig vom Ort und vom Typ des Zugangsnetz ermöglicht werden. Die zukünftigen Dienste lassen sich nahezu ausschließlich unter dem Begriff Mobile Multimediadienste zusammenfassen. Bezüglich der Dienstnutzung stellen neben nutzerfreundlichem Zugriff und Bedienung (Usability), Sicherheit, Abrechnung, Qualität und Verfügbarkeit insbesondere mobilitätsbezogene Funktionen eine große Herausforderung an das zukünftige All-IP Netz dar. Die Anforderungen, die sich aus der neuen Dienstklasse Mobile Multimedia und aus den mobilitätsbezogenen Wünschen ergeben werden im Folgenden erläutert. Mobilitätstypen und ihre Anforderungen: Unter Endgerätemobilität versteht man die Fähigkeit eines Netzes mit einem sich beliebig bewegenden Endgerät unterbrechungslos in Verbindung zu bleiben, auch wenn sich aufgrund der Bewegung die für die Versorgung zuständigen Netzwerkinstanzen ändern. Die Beibehaltung der Verbindung muss sowohl im Stand-By Zustand des Endgeräts als auch im Zustand einer aktiven Verbindung gewährleistet sein. In gegenwärtigen Mobilfunknetzen wird diese Form der Mobilität durch Handover-, Location Update- und Roaming Prozeduren bereits ermöglicht. Unter Personenbezogener Mobilität versteht man die Möglichkeit auf Standarddienste überall und unabhängig vom Zugangsnetz und

4.2 Dienste und Architekturen zukünftiger mobiler Multimedia Netze

Die Vision: Das inegrierende All-IP Netz

Mobilität der Endgeräte

Mobilität der Teilnehmer

■ ■ ■

187

Mobilität der Dienste

Endgerät zugreifen zu können. Denkbar ist hier z. B. VoIP-Telephonie über Schnurlos-, Mobil- oder Festnetze. Der Nutzer bewegt sich zwischen verschiedenen Zugangstechnologien, wobei auch ein Wechsel innerhalb einer Sitzung möglich sein soll. In diesem Fall spricht man von Sitzungsmobilität. Trotz der vielfältigen Zugangsarten soll aber ein Nutzer nur eine persönliche Identifikationsnummer besitzen unter der er weltweit erreicht werden kann. Eventuell kann auch die Vergabe von rollenspezifischen Nummern, z. B. für die Trennung von privaten und geschäftlichen Verbindungen erforderlich sein. Hinsichtlich der Personenbezogenen Mobilität ist außerdem ein transparentes und einheitliches Abrechnungssystem von Bedeutung. Das heißt auch wenn der Nutzer von verschiedenen Zugangsnetzen einer Vielzahl von Providern auf seine Dienste zugreift, sollte er stets nur an einen Dienstanbieter gebunden sein und nur diesem gegenüber zahlungspflichtig sein. Hierfür sind natürlich auch entsprechende Systeme zur Entgeltaufteilung zwischen den Anbietern notwendig. Ferner müssen Funktionalitäten für die Lokalisierung, Autorisierung, Authentifizierung, Schutz der Persönlichkeit und Teilnehmerprofile netzübergreifend implementiert werden. Personenbezogene Mobilität allein bezieht sich auf Standarddienste, die dem Nutzer am jeweiligen Netzzugangspunkt angeboten werden. Hingegen adressiert die so genannte Dienstmobilität die Nutzung aller aus dem Heimatnetz abonnierten Dienste. Dem Nutzer soll also nicht nur das Dienstangebot des besuchten Netzes sondern das im Heimatnetz abonnierte Angebot zur Verfügung stehen, und zwar in der gewohnten Form, die einem vorkonfigurierten Dienstnutzungsprofil entspricht. In einem solchen Profil kann zum Beispiel eine endgeräteabhängige Nutzeroberfläche oder die Menüsprache definiert sein. Dienstmobilität in Kombination mit Personenbezogener Mobilität wird in der UMTS Standardisierung mit Personal Service Environment bezeichnet. In UMTS werden diese zwei Formen der Mobilität bereits unabhängig von der Zugangstechnologie berücksichtigt. In den Standards der 2G Mobilfunksysteme hingegen ist Personenbezogene Mobilität und Dienstmobilität nur auf das Mobilfunknetz bezogen definiert. Multimedia Anforderungen: Multimediaanwendungen wie z. B. Sprach- und Video-konferenzen, kombinierter Web- und Kommunikationszugriff, Mobile Video, Location Based Services gelten als die Träger weiter steigender Umsätze in der IT- und Telekommunikationsbranche. Wesentliche Voraussetzung für die Nachfrage, Annahme und Nutzung solcher Dienste ist ihre jederzeitige, ortsungebundene und qualitativ hochwertige Bereitstellung. Hierin besteht auch eine

188

■ ■ ■

4 Mobile Multimedia

hohe technische Herausforderung, denn Multimediaanwendungen erfordern allgemein x x x x x x

die Integration von Echtzeit und Nicht-Echtzeit Diensten hohe Datenraten verschiedene QoS Verbindungstypen über einen Kanal die Möglichkeit mehrere parallele Sitzungen aufzusetzen dynamische Modifikation der Medientypen während einer Sitzung Interaktionen zwischen den zu einer Sitzung gehörenden Medientypen (z. B. Web-initiated voice call) x die Unterstützung vielfältiger Anwendungsprotokolle

Anforderungen an die 3GPP Mobile Multimedia Plattform: Die Standardisierung von GSM, GPRS und UMTS unterliegt der 3GPP (3rd Generation Partnership Project). Mit dem UMTS Release 5 setzte sich die 3GPP das ehrgeizige Ziel eine vollständige Lösung für die Bereitstellung von IP-basierten mobilen Multimediadiensten über UMTS zu definieren. Die zentralen Anforderungen an ein solches System wurden in [3gp05] wie folgt festgelegt. Die für eine IP-Multimedia Sitzung garantierte Dienstqualität (QoS) muss bei der Initialisierung einer Sitzung und während ihrem Verlauf zwischen Anwender und Netzwerkoperator verhandelbar sein. Dabei ist zu beachten, dass die einzelnen Medienkomponenten innerhalb einer Multimedia Sitzung unterschiedliche QoS-Anforderungen stellen. Es muss möglich sein QoS pro Medienkomponente festzulegen. Für die Gewährleistung von Interoperabilität wird eine relativ umfassende Menge von Medienkomponenten definiert, die in jedem Fall von allen standardkonformen Komponenten unterstützt werden müssen. Innerhalb einer IP Multimedia Sitzung sollen sich mehr als nur eine Multimedia Anwendungen befinden können. Dem Netzwerkoperator muss es möglich sein Strategien für den Zugang zu IP-Multimediadiensten zu implementieren. Im Fall des Roaming müssen zwischen den beteiligten Netzwerkoperatoren Diensteigenschaften und Dienstqualität in automatisierter Form ausgehandelt und festgelegt werden können. Ein Teilnehmer in einem Fremdnetz soll sowohl die Dienste seines Heimatnetzes als auch die im Fremdnetz angebotenen Dienste nutzen können. Eine zentrale Anforderung stellt die Gewährleistung von Zugriffsunabhängigkeit dar. Das heißt die Menge der dem Teilnehmer zur Verfügung stehenden Dienste, hängt nicht davon ab, wie dieser gerade auf das IP-Netz zugreift, z. B. über UMTS, WLAN oder DSL. Das 3GPP IP Multimedia Subsystem muss an andere leitungsund paketvermittelte Telefon- und Datennetze angeschlossen werden können und mit diesen derart interagieren, dass Dienste netzübergreifend realisiert werden können. Außerdem soll das abonnierte


Anforderungen der Multimediadienste

QoS, Interoperabilität, vielfältige Zugangsarten

■ ■ ■

189

Adressierung

Echtzeitdienste über paketvermittelte Netze

Dienstportfolio über verschiedene Endgeräte zugänglich sein. Der Teilnehmer sollte dann entweder über eine einzige oder über mehrere öffentliche Identifikationsnummern auf den unterschiedlichen Endgeräten erreichbar sein. Der Teilnehmer sollte auch in der Lage sein IP Multimedia Sitzungen an andere Adressen und Endgeräte weiter- bzw. umzuleiten. Für die Adressierung sollte sowohl der Telekommunikations(E.164) als auch der Internetadresspool (IPv6) benutzt werden können. Die gegenwärtige Präsenz von potentiellen Sitzungspartnern sollte den Sitzungs-Initiatoren durch Abfrage von entsprechenden Presence Servern zugänglich sein. Erstmalig soll im UMTS Release 5 Sprache nicht mehr leitungsvermittelt übertragen werden. Sowohl Daten- als auch Sprachdienste werden über ein gemeinsames All-IP Netz transportiert. Entsprechend unterliegt die Sprachübertragung der Anforderung, dass ihre Qualität mindestens die Übertragungsqualität leitungsvermittelter Netze erreichen muss. Die Multimedia Anwendungen selbst werden nicht von 3GPP standardisiert. Auf die 3GPP IP Multimedia Plattform sollte jedoch von allen kommerziell verfügbaren Anwendungen zugegriffen werden können. Insbesondere müssen die Anwendungen in der Lage sein während der Initialisierung ihre Eigenschaften und Parameter auszutauschen, z. B. den anzuwendenden Video-Codec.

4.2.2 Mobile Netze der Gegenwart Abbildung 4.2 veranschaulicht die Evolution der Mobilfunknetze von GSM hin zu einem All-IP basierten UMTS Netz. Das GSM Radiozugriffsnetz bietet nur niederratige leitungsvermittelte Datenkanäle über die Luftschnittstelle. Das GSM Kernnetz ist ein rein leitungsvermitteltes Netz. Beide Eigenschaften sind auf den primären GSM Dienst, nämlich leitungsvermittelte Sprache zugeschnitten. Mit dem enormen Anstieg der Nutzung IP-basierter Datendienste während der 90er Jahre und dem Wunsch diese auch über mobile Endgeräte zugänglich zu machen stiess das GSM Netz an seine Grenzen. Die mangelhafte Eignung von GSM für mobile Datendienste wird besonders anhand der enttäuschenden Nutzung des mobilen Internetzugangs über das Wireless Application Protocoll (WAP): Im leitungsvermittelten Netz dauert der Auf- und Abbau von Verbindungen sehr lange und die geringe Datenrate auf den Kanälen der Luftschnittstelle bedingt nicht-akzeptable Downloadzeiten. Außerdem konnte im leitungsvermittelten Netz nur zeitabhängig abgerechnet werden, was zu

190

■ ■ ■

4 Mobile Multimedia

Abb. 4.2: Evolution der Mobilfunknetze IP Multimedia Paketvermittelte Datendienste Anschluss an Internet

Dienste

Leitungsvermittelter Sprachdienst

Kernnetz

All IP Transportnetz + IP Multimedia Paketvermitteltes (PS) Netz Subsystem (Signalisierung) Leitungsvermitteltes (CS) Netz

Radiozugriffsnetz

GSM GSM

GSM/ GPRS

UMTS Radio Access Network UMTS Rel. 99 / Rel. 4

UMTS Rel. 5

unverhältnismäßig hohen Kosten insbesondere für burstartige Anwendungen wie z. B. Webbrowsing führte. Mit GPRS wurde neben dem leitungsvermittelten GSM Kernnetz ein paketvermitteltes Kernnetz implementiert. Kurze Zugriffszeiten auf einen vielen Teilnehmern gemeinsam zur Verfügung stehenden und ständig aufgebauten Kanal, die Möglichkeit volumenabhängiger Abrechnungsmodelle und eine um den Faktor vier erhöhte Datenrate erlauben nun einen zwar eingeschränkten, jedoch akzeptablen mobilen Zugriff auf Datendienste. Zu beachten ist, dass in GPRS eine höhere Datenrate trotz weiterer Verwendung des GSM Radionetz erzielt wird. Ermöglicht wird dies durch eine bis zu vierfache Bündelung von GSM Radiokanälen. Mit der ersten UMTS Version (Release 99) ein völlig neues CDMAbasiertes Radionetz eingeführt. Damit sind über die Luftschnittstelle Datenraten von bis zu 384 kBit/s möglich im Vergleich zu 53.4 kBit/s in GPRS. Das Kernnetz des Release 99 ist identisch mit dem GPRS Kernnetz. Es besteht also aus einer leitungsvermittelten (CS) und einer paketvermittelten (PS) Domäne. Mit dem für 2006 erwarteten UMTS Release 5 soll nun der komfortable und umfassende Zugriff auf jede Art von mobilen Multimediadiensten ermöglicht werden. Hierzu wird anstelle der zwei parallelen Domänen des Kernnetzes nur noch ein, ausschliesslich auf IP-Technologie basierendes Kernnetz realisiert. Sowohl der Nutzdatentransport als auch die gesamte Signalisierung folgen den IP-Konzepten.


■ ■ ■

191

Wesentlicher Bestandteil des All-IP Kernnetz ist die SIP-basierte Signalisierungs- und Kontrollfunktionalität. Diese ist im neu definierten IP Multimedia Subsystem (IMS) realisiert. Im Folgenden wird die Evolution der Architektur von GSM hin zum All-IP Mobilfunknetz in UMTS Release 5 vorgestellt. Ziel ist ein Verständnis der wesentlichen Komponenten und Funktionalitäten des IP-Multimedia Subsystems zu vermitteln. Die Funktionalitäten des IMS bilden die Grundlage eines zukünftigen netzübergreifenden, zugangs-unabhängigen und personenbezogenen Zugriffs auf Multimediadienste. 4.2.2.1 Architektur des GSM Netzes Abbildung 4.3 zeigt die Komponenten der GSM Architektur. Sie besteht aus einem Radiozugriffsnetz (Radio Access Network) und einem Kernnetz (Core Network). Im Radiozugriffsnetz sind die Mobilstationen (MS) über Funk mit den Basisstationen (BTS für Basestation Transceiver) verbunden. Im Radiozugriffsnetz kommen GSM spezifische Protokolle zum Einsatz. Im leitungsvermittelten GSM Kernnetz kommen angepasste ISDN Protokolle für die Übertragung von Nutzund Signalisierungsdaten in Einsatz. Die dargestellten Komponenten werden im Folgenden erläutert. Die Mobilstation (MS): In GSM wurde erstmals das Konzept einer Zweiteilung von Mobilstationen (MS) in x Endgerät und x Subscriber Identity Module (SIM)

Abb. 4.3: Komponenten der GSM Architektur

GSM Radiozugriffsnetz

GSM Kernnetz (ISDN Verbindungen) MSC

BSC M S

EIR BTS BSC

M S BTS M S

■ ■ ■

MSC

GMSC

VLR HLR/ AUC

Signalisierung Signalisierung und Daten

192

PSTN/ other PLMN

VLR

4 Mobile Multimedia

eingeführt. Das Endgerät wiederum enthält immer einen GSM-spezifischen Mobilteil, der auch Mobile Termination (MT) genannt wird, und optional ein über einen Adapter angeschlossenes externes Terminal Equipment (TE). Z. B. kann an ein GSM-Sprachtelefon (MT) über die serielle Schnittstelle und einen entsprechenden Adapter ein Notebook (TE) angeschlossen werden. Die SIM Card enthält die teilnehmerspezifischen Daten. Durch die auf der SIM gespeicherten Informationen identifiziert das Netz den Teilnehmer. Erst durch das Einlegen der SIM in das MT kann dieses für den Zugriff auf Mobilfunkdienste benutzt werden. Auf welche Dienste tatsächlich zugegriffen werden darf, ist aus den in der SIM Card gespeicherten Daten ersichtlich. Die SIM Card personalisiert das MT. Eine normierte Schnittstelle zwischen SIM und MT erlaubt prinzipiell den Zugriff auf Mobilfunkdienste unabhängig von der verwendeten Netztechnologie. Dadurch kann z. B. ein Reisender auf das Mobilfunknetz in einem anderen Land zugreifen, auch wenn diesem Netz eine andere Technologie zugrunde liegt. Neben dieser Trennung von Teilnehmer- und Endgerät kommen der SIM folgende Funktionalitäten zu: Speicherung von permanenten Daten x für die Authentisierung und Verschlüsselung x IMSI (International Mobile Subscriber Identity) x PIN (Personal Identification Number) und PUK (PIN Unblocking Key) x SIM-Kartentyp und SIM-Seriennummer Speicherung von temporären Daten, wie z. B. x Aufenthaltsort-Information x TMSI (Temporäre IMSI) x Temporäre Schlüssel x Nachbarzellen Die SIM kann vor dem Zugriff nichtberechtigter Personen durch die PIN geschützt werden. Basestation Transceiver System (BTS): Mobilstationen sind über Funkkanäle mit den Basisstationen der festen Infrastruktur verbunden. In GSM werden die Basisstationen Base Station Transceiver System (BTS) genannt. Eine BTS mit omnidirektionaler Sende/-Empfangsantenne bildet zusammen mit allen Mobilstationen in ihrem Abdeckungsbereich eine


■ ■ ■

193

Funkzelle. Heute, werden die GSM Basisstationen meist mit sektorisierten Sende/-Empfangsantennen ausgestattet. Ein einzelnes Antennensegment versorgt dabei meist einen Sektor von 120°. In diesem Fall versteht man unter dem Begriff Zelle einen Sektor. Eine BTS kann also mehrere Zellen versorgen. Basisstationen können nicht selbständig die Benutzung ihrer Resourcen (Kanäle) verwalten. Ferner verfügen sie nicht über Aufenthaltsort-Information der Teilnehmern, d. h. sie können nicht selbständig Verbindungen routen. Ihre Aufgabe beschränkt sich im Wesentlichen auf die Demodulation und Decodierung von empfangenen Funksignalen und deren Umwandlung und Weiterleitung an den zuständigen Basisstation Controller (BSC) über feste Leitungen. In umgekehrter Richtung empfangen Basisstationen Nachrichten des BSC, die an eine MS innerhalb ihres Abdeckungsbereiches bestimmt sind, codieren und modulieren diese und senden das entsprechende Hochfrequenz (HF)-Signal an die dedizierte MS. Basestation Controller (BSC): Ein BSC kontrolliert mehrere an ihn angeschlossene Basisstationen. Insbesondere verwaltet der BSC die Nutzung der Radiokanäle aller ihm zugeordneten Basisstationen. Dazu gehört u. A. die Zuweisung und der Abbau von Radiokanälen und die Kontrolle und Steuerung des Handover, d. h. der Übergabe einer sich an der Zellgrenze bewegenden MS von einer BTS zur nächsten. Mobile Switching Center (MSC): Jede BSC wiederum ist mit einem Mobile Switching Center (MSC) verbunden. Eine MSC kontrolliert in der Regel mehr als eine BSC. Den MSCs obliegt die Vermittlungsfunktion im Mobilfunknetz (Leitungs-vermittlung). Zusätzlich zu den aus der Festnetztelefonie bekannten Vermittlungsfunktionen müssen die MSCs über aktuelle Aufenthaltsdaten der Mobilteilnehmer verfügen und abhängig von diesen den Aufbau- und Abbau der entsprechenden Funkkanäle veranlassen. Den MSCs kommt daher auch eine entscheidende Rolle im Handover Prozess bei. Die MSC ist ferner verantwortlich für die Authentisierung der Teilnehmer und die Aufzeichnung von Verbindungsdaten für die Gebührenerhebung. Für die Bewältigung dieser Aufgaben greifen die MSCs auf die Datenbanken Home Location Register (HLR), Visting Location Register (VLR), Authentification Centre (AUC), und Equipment Indication Register (EIR) zu. Gateway Mobile Switching Center (GMSC): Ein spezieller MSC, das Gateway MSC (GMSC) bildet die Schnittstelle von und zu externen Netzen wie dem Telefonfestnetz (Public Switched Telephone Network (PSTN)), Paket Daten Netzen (PDN), oder anderen nationalen und internationalen Mobilfunknetzen. Aus externen Netzen ankommende

194

■ ■ ■

4 Mobile Multimedia

Rufe werden vom GMSC unter Zuhilfenahme der im HLR gespeicherten Teilnehmerdaten an die entsprechenden Aufenthaltsorte der Teilnehmer geroutet. Für an- und abgehende Rufe wird in der im GMSC implementierten Interworking Function (IWF) die entsprechende Protokolltransformation durchgeführt. Home Location Register (HLR): Je ein HLR ist einem GMSC zugeordnet. Im HLR sind die Identifikations- und Dienstzugriffsdaten für alle, einem GMSC zugeordneten Teilnehmer, gespeichert. Dazu gehören permanente Daten wie x x x x

die IMSI die Telefonnummer der geheime Schlüssel zur Authentifizierung des Teilnehmers eine Liste der abbonierten Dienste und Zusatzdienste

sowie folgende temporäre Daten: x der aktuelle Aufenthaltsort des Teilnehmers und das zuständige Visiting Location Register (VLR) x aktuelle Call-Forwarding Nummern x temporäre Daten zur Datenverschlüsselung und Authentifikation. Die Aufdatierung der temporären Daten, z. B. des TeilnehmerAufenthaltsortes wird vom GMSC durchgeführt. Visiting Location Register (VLR): Je ein VLR ist einem MSC zugeordnet. Es enthält Daten über alle Teilnehmer, die sich gerade im Verwaltungsgebiet des MSC befinden. Dazu gehören permanente Daten, die vom HLR in das aktuell zuständige VLR zum Zweck des schnellen Zugriffs kopiert wurden. Zu den temporären Daten im VLR gehört z. B. die TMSI. Authentification Centre (AUC): Das Authentification Center ist dem HLR zugeordnet. Es ist für die Erzeugung und Speicherung der geheimen Schlüssel aller im HLR registrierten Teilnehmer zuständig. Die relevanten Daten zur Erzeugung der geheimen Schlüssel werden vor ihrer Ausgabe an den Teilnehmer auch auf die SIM Card geschrieben. Beim Verbindungsaufbau erfragt das jeweilig zuständige MSC die Verschlüsselungsinformation vom AUC um die Teilnehmer-Authentifizierung und anschließende Verschlüsselung durchzuführen. Equipment Identity Register (EIR): Das EIR enthält nicht Daten der Teilnehmer, sondern Daten zur Identifikation der Endgeräte. Gespeichert werden die Seriennummern der Geräte (International Mobile


■ ■ ■

195

Station Equipment Identity (IMEI)). Damit kann zum Beispiel der Verbindungsaufnahme-Versuch über ein gestohlenes Endgerät erkannt und blockiert oder der aktuelle Release der auf den Endgeräten befindlichen Software bestimmt werden. 4.2.2.2 Architektur des GPRS Netzes In GPRS wurde parallel zum leitungsvermittelten Netz ein paketvermitteltes Netz implementiert. Den leitungsvermittelten Teil, der auch weiterhin vornehmlich für laufzeitkritische Dienste wie Sprachtelephonie benutzt wird, nennt man die Circuit Switched (CS) Domäne, des neuen paketvermittelten Teil des Kernnetzes nennt man die Packet Switched (PS) Domäne. Über die PS Domäne wird die Anbindung an Datennetze (PDN für Public Data Network) wie z. B. Internet und Intranet realisiert. Die paketvermittelte (PS) Domäne mit ihren neuen Komponenten Serving GPRS Support Node (SGSN) und Gateway GPRS Support Node (GGSN) sind in Abb. 4.4 dargestellt. Wie die Abbildung zeigt benutzen CS- und PS-Domäne das gleiche GSM Radiozugriffsnetz. Jeder BSC ist sowohl mit einem SGSN als auch mit einem MSC verbunden. Die Komponenten der PS Domäne sind über ein IP-Netz verbunden. Die Verwendung von IP als Transportprotokoll erlaubt eine flexible Verwendung der darunter liegenden Übertragungsprotokolle.

Abb. 4.4: Komponenten der GPRS Architektur

GSM Radiozugriffsnetz MSC BSC M S

Leitungsvermittelte (CS) Domäne des Kernnetz PSTN/ other PLMN

VLR EIR

PCU BTS BSC

M S

PCU BTS

MSC

GMSC

VLR

M S

HLR/ AUC

SGSN Signalisierung Signalisierung und Daten

SGSN Paketvermittelte (PS) Domäne des Kernnetz

196

■ ■ ■

4 Mobile Multimedia

GGSN PDN (Internet/ Intranet)

Das IP-Protokoll der PS-Domäne setzt meist auf ATM (Asynchronous Transfer Mode) über optischen STM (Synchronous Transport Module)-Verbindungen auf. Serving GPRS Support Node (SGSN): Dem Mobile Switching Centre (MSC) in der CS Domäne entspricht der SGSN in der PS Domäne. Die funktionalen Aufgaben des SGSN in der PS Domäne entsprechen in etwa den Aufgaben des MSC im CS Teil und werden im Folgenden beschrieben: Routing: Da sich der SGSN im paketvermittelten Netz befindet, spricht man jetzt nicht mehr von Vermittlung, sondern von Routing (oder Weiterleitung). Der SGSN nimmt aus dem RAN ankommende Pakete auf und leitet sie entsprechend der im Paket eingetragenen Adresse über das CN weiter zu den entsprechenden externen Paketdatennetzen. Umgekehrt nimmt er über das CN ankommende Pakete für Teilnehmer in seinem Verwaltungsgebiet auf und leitet sie an die entsprechenden Komponenten des RAN, über die der im Paket eingetragene Adressat erreichbar ist. Verwaltung der Teilnehmerdaten: Teilnehmerspezifische Daten wie Identifikationsnummern, Abonnierte Dienste, Aufenthaltsortinformation, Abrechnungsmodelle sind in GPRS wie schon in GSM im HLR und VLR gespeichert. Der SGSN greift auf diese Daten zu und aktualisiert sie bei Bedarf. Erzeugen von Daten für die Abrechnung: Der SGSN erzeugt verschiedene Typen von Call Detail Records (CDRs), mithilfe derer eine Abrechnung in Abhängigkeit vom aktuellen Aufenthaltsort, vom benutzten Dienst und vom übertragenen Datenvolumen erstellt werden kann. Die CDRs werden im aktuell zuständigen SGSN erzeugt und gesammelt. Außerdem werden sie auch im GGSN des Heimatnetzes gespeichert. Authentifizierung und Verschlüsselung: Die im SGSN ablaufenden Prozeduren für die Authentifizierung und Verschlüsselung sind weitgehend identisch mit den entsprechenden GSM Prozeduren im MSC. Resource Management: Der SGSN initiiert und verwaltet die Kanäle die für paketvermittelte Dienste im RAN und CN benötigt werden. Mobility Management: Der SGSN steuert und kontrolliert die Registration (Einbuchung) und das Abmelden der Teilnehmer beim Netz. Er ist für die Aktualisierung der aufenthaltsortspezifischen Daten aller Teilnehmer in seinem Verwaltungsgebiet verantwortlich. Session Management: Der SGSN steuert den Aufbau von Datenverbindungen, der auch als PDP (Packet Data Protocoll) Context Activation bezeichnet wird. Während der PDP Context Activation weist der SGSN dem Mobilteilnehmer eine IP Adresse zu. Außerdem enthält der PDP Context den Namen und die Adresse der für den Sitzungstyp


■ ■ ■

197

zuständigen Access Point (Anschluss ans externe Netz) und die Adresse des zugehörigen GGSN. Des weiteren unterstützt der SGSN die Bereitstellung von SMS Diensten und aufenthaltsortabhängigen Diensten (Location Based Services). Gateway GPRS Support Node (GGSN): Über den GGSN wird der paketvermittelte Teil des GPRS CN mit dem Internet oder anderen externen Datennetzen (z. B. direkte Verbindung vom GGSN zum Intranet einer Firma) verbunden. Aus Sicht der externen Netze ist ein GGSN ein IP-Router. Der GGSN ist in die Aktivierung des PDP Context mit eingebunden, indem er z. B. für die Vergabe der IP-Adresse verantwortlich ist. Die IP Adresse kann entweder dynamisch (DHCP) oder statisch vom GGSN zugewiesen werden. Im PDP Context wird auch der Access Point Name (APN) des gewünschten Dienstes spezifiziert. Ein GGSN ist über eine Vielzahl unterschiedlicher APs zu den Diensten externer Netze verbunden. Z. B. gibt es für jedes angeschlossene Intranet je einen AP. Eine weitere wichtige Funktion des GGSN ist das Routing von aus externen Datennetzen ankommenden Paketen zu dem SGSN, in dessen Verwaltungsgebiet sich die adressierte MS gerade befindet. Hierzu greift der GGSN auf die Einträge im HLR zu. Während einer Internetverbindung kann der zuständige GGSN nicht wechseln. Die Internet Router im externen Netz sehen für eine Verbindung immer die gleiche Ziel-IP Adresse des GGSN. Um die Mobilität der Teilnehmer müssen sie sich also nicht kümmern. Dies wäre auch gar nicht möglich, da die IP-Router alle Pakete einer Verbindung an die selbe Adresse schicken müssen, weil sie ihre Routingtabellen nicht ändern können. Border Gateway (BG): Border Gateways können zur Kommunikation und Verkehrslenkung zwischen Mobilfunknetzen eingesetzt werden. Befindet sich eine Mobilstation in einem fremden Netz, so benötigt der GGSN des besuchten Netzes Informationen aus dem Heimatnetz, die der entsprechende Heim-GGSN bereitstellen kann, z. B. Teilnehmereinträge aus dem HLR. Auch Datenpakete, die über den HeimGGSN empfangen bzw. versendet werden müssen, werden über die BGs zum bzw. vom GGSN des besuchten Netzes geleitet. Neben der Verkehrslenkung können BGs auch erweiterte Sicherheitsmechanismen wie IPsec bereitstellen. Ein BG besteht im Wesentlichen aus einem oder mehreren Routern. Optional enthält es darüber hinaus eine Firewall und einen externen Domain Name Server (DNS). Paket Control Unit (PCU): Im Gegensatz zu den bisher beschriebenen GPRS-Komponenten ist die Paket Control Unit (PCU) nicht Teil des

198

■ ■ ■

4 Mobile Multimedia

CN sondern befindet sich auf Höhe des Base Station Controller (BSC) im Radio Access Network. Der BSC stellt für leitungsvermittelte Dienste dedizierte ISDN Kanäle zum MSC bereit. Für paketvermittelte Dienste sind solche dedizierten Kanäle ungeeignet. Deshalb wurde in GPRS der PCU eingeführt. Er ist als eine Ergänzung des BSC für paketvermittelte Prozeduren zu verstehen. Zu den Aufgaben des PCU gehören u. A. die Vergabe von Übertragungskapazität auf den gemeinsam benutzten Kanälen, sowie Flusskontrolle und Priorisierung der unterschiedlichen Datenströme. Mobilstation (MS): Für GPRS sind drei verschiedene Klassen von Mobilstationen definiert: x Endgeräte der Klasse C können entweder nur im leitungsvermittelten Teil (CS) oder nur im paketvermittelten Teil (PS) des Netzes angemeldet sein. x Endgeräte der Klasse B können in beiden Netzteilen gleichzeitig angemeldet sein. Jedoch ist es nicht möglich während eines Telefongesprächs Daten zu senden oder zu empfangen. Falls während einer Datenübertragung eine Telefonverbindung aufgebaut wird, so wird der Datenverkehr für die Dauer des Gesprächs angehalten, jedoch ohne dass dabei der Datenkanal abgebaut wird. Des Weiteren ist es nur bedingt möglich während einer Datenverbindung einen Anruf oder eine SMS anzunehmen, da während einer Datenübertragung das Endgerät nur in Übertragungspausen gepaged werden kann. x Die Endgeräte der Klasse A können ebenfalls gleichzeitig im CS- und PS-Teil angemeldet sein. Mit den Geräten dieser Klasse kann jedoch während einer Datenübertragung über den PS-Teil gleichzeitig ein Telefongespräch über den CS Netzbereich geführt werden. Die meisten derzeit handelsüblichen GPRS Endgeräte gehören zu dieser Klasse. 4.2.2.3 Architektur des UMTS Release 99 Netzes Mit Release 99 wird der 3GPP Standard, der den ersten UMTS-Netzen zugrunde liegt bezeichnet. Die Struktur der Release-99-Architektur unterscheidet sich nicht wesentlich von der GPRS-Architektur. Insbesondere wurde durch die Verwendung des GPRS-Kernnetz, also einer leitungsund einer paketvermittelten Domäne, die Migration hin zu UMTS erleichtert. Wie in GPRS werden über die leitungsvermittelte Domäne Echtzeitdienste wie Sprache, über die paketvermittelte Domäne laufzeitunkritische Datendienste realisiert. Im Radiozugriffs-


■ ■ ■

199

netzwerk werden in UMTS die Mobilstationen als User Equipments (UEs), die Basisstationen als Node-Bs und die Basisstation-Controller als Radio Network Controller (RNC) bezeichnet. Das Radiozugriffsnetzwerk als Ganzes wird in UMTS mit UTRAN (UMTS Terrestrial Radio Access Network) bezeichnet. Neben der neuen Namensgebung ist auch die im UTRAN eingesetzte Technologie völlig neu. Sie basiert auf dem in der Luftschnittstelle verwendeten WCDMA (Wideband Code Division Multiple Access) Kanalzuteilungs- und Übertragungsverfahren. Mit diesem Verfahren werden die Radiokanäle nicht wie in GSM durch disjunkte Frequenzbänder und Zeitschlitze voneinander getrennt. Stattdessen steht jedem Kanal das gesamte Spektrum fortlaufend zur Verfügung. Die Kanaltrennung erfolgt durch orthogonale und quasi-orthogonale Codes. Die neue Technologie im Radiozugriffsnetz bietet höhere Datenraten und verbesserte QoS-Konzepte, damit soll dem Wunsch nach der Bereitstellung einer breiten Palette unterschiedlicher Dienste mit jeweils individuellen Dienstgüteanforderungen Rechnung getragen werden. 4.2.2.4 Architektur des UMTS Release 4 Netzes Mit dem UMTS Release 4 wird im leitungsvermittelten Teil des Kernnetzes eine Aufteilung in eine Kontroll- und eine Transportebene eingeführt, ein grundlegendes Konzept der so genannten Next Gegeneration Networks (NGN). MSC Kontrollfunktionalität wie etwa die Rufsteuerung und das Mobilitätsmangagement ist nun im MSC Server, die Transportfunktionalität im CS Media Gateway (CS-MGW) realisiert. Durch diese Trennung können Kontrollfunktionen und TransportAbb. 4.5: UMTS Release 4 Architektur

Kontrollebene der CS Domäne MSC GMSC Server Server GSM Radio Access Network

Transportebene der CS Domäne CS-MGW

UMTS Radio Access Network

PS Domäne (wie in GPRS) SGSN


200

■ ■ ■

4 Mobile Multimedia

CS-MGW

GGSN

protokolle weitgehend unabhängig voneinander eingesetzt und weiterentwickelt werden. So ist z. B. ein die Kontrollebene nicht beeinflussender Austausch der 64 kBit/s ISDN Transportverbindungen durch ATM- oder gar IP-Verbindungen möglich. Release 4 lässt also prinzipiell IP-Transport auch in der CS Domäne zu, jedoch bleiben die Signalisierungsverbindungen in der Kontrollebene nach wie vor leitungsvermittelt. 4.2.2.5 Fazit: Möglichkeiten und Einschränkungen der mobilen Netze bis UMTS Release 4 GSM als erster internationaler Standard führte die Mobilkommunikation in den 90er Jahren in den Massenmarkt und bescherte der Mobilfunkbranche global unvorhergesehene und immer noch steigende Umsatzflüsse. GSM wurde für mobile Sprachdienste entwickelt und stellt diese mit guter Qualität bereit. Mit der enorm wachsenden Nutzung des Internets, entstand der Wunsch auch Datendienste mobil zugänglich zu machen. GSM war hierfür nur bedingt geeignet. Die Weiterentwicklung GPRS erweiterte GSM mit IP-Technologie und schuf damit die Basis für die Bereitstellung mobiler paketvermittelter Datendienste. Mit dem UMTS Release 99 gelang es höhere Datenraten über die Luftschnittstelle zu realisieren und ein flexibleres Dienstangebot zu ermöglichen. Neue Dienste wie mobile Videotelefonie oder mobiles TV sind seither realisiert. Mit dem UMTS Release 4 können erstmals auch laufzeitkritische Dienste wie Sprache über IP-Technologie übertragen werden. Jedoch besteht auch in Release 4 immer noch eine Zweiteilung des Kernnetzes in eine leitungsvermittelte und eine paketvermittelte Domäne. Zumindest die Signalisierung von laufzeitkritischen Diensten läuft in Release 4 noch über leitungsvermittelte Protokolle. Die wesentlichen Nachteile dieser Aufteilung in zwei weitgehend voneinander getrennte Domänen sind: x Relativ hohe Installations- und Betriebskosten durch den notwendigen Aufbau und Betrieb von zwei getrennten Kernnetzen mit völlig unterschiedlichen Komponenten. x Die Bereitstellung umfassender Multimedia Dienste, in denen Echtzeit- und nicht laufzeitkritische Dienste synchron integriert und bereitgestellt werden müssen, ist nicht möglich, da diese Komponenten über die Transportkanäle der nicht miteinander kooperierenden Kernnetze realisiert werden. Diese Nachteile sollen durch den UMTS Release 5 ausgeschaltet werden. Dort wird die Zweiteilung des Kernnetzes aufgehoben und sowohl


■ ■ ■

201

Signalisierungs- als auch Nutzdaten über ein gemeinsames All-IP Netz übertragen.

4.2.3 Architektur zukünftiger mobiler All-IP Netze am Beispiel des UMTS Release 5

Abb. 4.6: IP-basierte Netzarchitektur des UMTS Release 5 Application/ Service

Control

AS

HSS

SSF

SLF

PDF

Den in Abschnitt 4.2.1 beschriebenen Anforderungen an die All-IP basierte Mobile Multimedia Plattform soll das in Abb. 4.6 dargestellte Architektur-Konzept des zukünftigen 3GPP Netz (UMTS Release 5) gerecht werden. Wobei sich dieses Konzept nicht ausschließlich auf UMTS bezieht, sondern auch die Schnittstellen für die Einbindung anderer Zugangsnetze wie z. B. WLAN oder WiMax berücksichtigt. Wesentliches Merkmal dieses Konzeptes ist die saubere Trennung zwischen Zugriffs-, Transport-, Kontroll-, und Anwendungsebene. Die verschiedenen Ebenen sind über offene Schnittstellen miteinander verbunden. Ein derartiger Architekturentwurf wurde schon in frühen Studien [Ets99] der ETSI (European Telecommunication Standardisation Institute) zur Gestaltung eines zukünftigen globalen und mobilen

SCP

SCS

MRF

PS

CSCF

RSGW TSGW

MGCF

IP-Backbone

Transport

MGW SGSN GGSN

Access

BGCF

PSTN ISDN GSM

Internet / Intranet IGSN

ISP

Access Gateways

HSPA, UMTS EDGE GPRS

WiMAX

Satellite

Portal

Content

Other Fixed and Wireless

WLAN

AS: SSF: SCP: SCS: PS:

Application Server Service Switching Function Service Content Provider Service Capability Server Presence Server

202

■ ■ ■

HSS: SLF: PCF: MRF: CSCF:

Home Subscriber Service Subscription Locator Function Policy Control Function Media Resource Function Call State Control Function

4 Mobile Multimedia

BGCF: MGCF: T-SGW: R-SGW: MGW: IGSN:

Breakout Gateway Control Function Media Gateway Control Function Transport Signaling Gateway Roaming Signaling Gateway Media Gateway Internet Gateway Support Node

Multimedia Netzes als essentiell zugrunde gelegt. Realisiert wird das Konzept im Release 5 der 3GPP UMTS Spezifikation. Der Roll-Out von Release 5 Netzen wird ab Ende 2006 erwartet. In der Anwendungs- und Dienstebene befinden sich die DienstPlattformen. Mögliche Plattformen sind der Application Server (AS), eine IP-Multimedia Service Switching Function (SSF), die Open Service Architecture Service Content Provision (SCP), der Service Capability Server (SCS) und der Presence Server (PS). Die Dienstplattformen bilden die Laufzeitumgebungen für Dienste und können je nach Dienst die Rolle eines SIP-Proxy, SIP User Agent oder SIP Back-toBack User Agent übernehmen. Die ASS sind über SIP-Schnittstellen mit dem IP-Multimedia-Subsystem verbunden. Die Kontrollebene wird IP-Multimedia Subsystem (IMS) genannt. Sie ist zugangsunabhängig, kann also sowohl für mobile als auch für feste Netzanschlüsse verwendet werden. Aufgabe des IMS ist die Kommunikationssteuerung. Die 3GPP hat hierfür das Session Initiation Protocol (SIP) der IETF und das IPv6 vorgeschrieben. Das Dienstangebot wird unabhängig von Kommunikationssteuerung, Zugriff und Transport auf generischen Dienstplattformen in der Applikations- und Dienstebene bereitgestellt. Damit wird eine netzwerkübergreifende Nutzung der abonnierten Dienste ermöglicht. 4.2.3.1 Komponenten des IP Multimedia Subsystems Die Komponenten des IP Multimedia Subsystems (IMS) sind in Abb. 4.7 grau hinterlegt. Home Subscriber Service (HSS): Das HSS ist die zentrale Datenbank, in der sämtliche Teilnehmerdaten gespeichert sind. Abhängig von der Anzahl der Teilnehmer, der Organisation des Netzes und der Kapazität AS HSS

P-CSCF

Mobilstation UMTS Radio Access

SGSN

GGSN

I-CSCF

S-CSCF

BGCF

PDF MRFC MRFP


SLF

Abb. 4.7: Komponenten und Schnittstellen des IMS

IMS-MGW

MGCF/ SGW PSTN/ 2G PLMN

PDN (IP Network)


■ ■ ■

203

der Datenbank und deren Anschlüsse kann ein Heimatnetz ein oder mehrere HSSs enthalten. Die im HSS gespeicherte Teilnehmerinformation kann wie folgt unterteilt werden: x Adressen und Nummern, die der eindeutigen Identifikation eines Teilnehmers dienen. x Sicherheitsrelevante Information für die Authentifizierung und Autorisierung des Teilnehmers sowie für die Verschlüsselung sämtlicher Daten. Die entsprechenden Schlüssel werden im HSS erzeugt und gespeichert. x Information über den aktuellen Aufenthaltsort des Teilnehmers über die Grenzen der verschiedenen Transportnetze hinweg x Daten, die das individuelle Teilnehmerprofil definieren Im HSS sind die bereits in GSM enthaltenen Datenbanken Home Location Register (HLR) und Authentification Centre (AUC) integriert. Die HSS enthält demnach Funktionalitäten, die vom HLR/AUC der leitungsvermittelten und der paketvermittelten Domäne bereitgestellt werden müssen (s. Abb. 4.7). Darüber hinaus aber auch Funktionalität, die für die Unterstützung von IP Multimedia Sitzungskontrolle erforderlich und damit unabhängig vom Zugriffsnetz ist. Subscription Locator Function (SLF): Falls sich mehr als ein logischer HSS im Heimatnetz befindet, hält der SLF die Information in welchem HSS die Daten jedes Teilnehmers gespeichert sind. Diese SLF Information wird vom I-CSCF während der SIP-Registrierung bzw. vom Application Server abgefragt. Call State Control Function (CSCF): Die CSCF ist der SIP-Server für die Kommunikationssteuerung von Multimediasitzungen zu denen als Spezialfall auch der Sprachdienst gezählt wird. Die CSCF kann die Rollen x Serving-CSCF (S-CSCF) x Proxy-CSCF (P-CSCF) 1 x Interrogating -CSCF (I-CSCF) einnehmen. Grundlegendes Prinzip ist die Bedingung, dass der Zugriff auf alle Dienste, die vom Heimatnetzwerk bereitgestellt werden, von einer im Heimatnetzwerk befindlichen Instanz aus kontrolliert und gesteuert werden. Diese Funktion übernimmt immer die im Heimatnetz ansässige S-CSCF. Die P-CSCF hingegen ist dem GPRS/UMTS Zugangsnetz des aktuell zuständigen GGSN zugeordnet. Das kann sowohl der GGSN des Heimatnetzes als auch der GGSN eines besuchten Netzes 1

204

■ ■ ■

Interrogation = Abhören

4 Mobile Multimedia

sein. Falls sich die P-CSCF nicht im Heimatnetz befindet, stellt die ICSCF die vorderste Komponente des IMS im Heimatnetz dar, die Registrierungsanfragen aus dem fremden Netz entgegennimmt. Mithilfe des I-CSCF wird die Netzwerkstruktur des Heimatnetzes vor den angebundenen Fremdnetzen verborgen. Die Dienstplattformen, auf die von der S-CSCF zugegriffen werden, können sich entweder innerhalb oder außerhalb des Heimatnetzwerkes befinden. Für die Mobilstation (MS) ist stets die P-CSCF der vorderste Kontaktpunkt innerhalb des IMS. Die P-CSCF nimmt Anfragen der Mobilstation entgegen und behandelt diese entweder intern oder leitet sie weiter. SIP Registrierungsanfragen werden von der P-CSCF an die I-CSCF weitergereicht. Nach erfolgreicher Registrierung wird der P-CSCF u. A. die Adresse des SIP-Servers (der S-CSCF) mitgeteilt an den die P-CSCF die folgenden SIP Nachrichten weiterreicht. Die P-CSCF muss in der Lage sein SIP Nachrichten von und zu der Mobilstation zu komprimieren und zu dekomprimieren und eine sichere IPSec Verbindung zur Mobilstation aufzubauen und aufrechtzuerhalten. Für die Einbeziehung der P-CSCF in den Authentifizierungsprozess wurden entsprechende SIP-Erweiterungen spezifiziert. Die P-CSCF übernimmt auch die Rolle einer Zwischeninstanz zwischen Anwendungen im Endgerät des Benutzers, z. B. Web-Browser und einer netzseitigen Dienstplattform, z. B. einem Web-Server. In dieser Funktion kann die P-CSCF z. B. als Firewall oder als kontrollierender Zugriffsfilter dienen. In der P-CSCF werden außerdem die Call Detail Records (CDRs) generiert. Diese enthalten alle für die Abrechnung relevanten Dienst- und Resourcennutzungsdaten. Falls sich die P-CSCF nicht im Heimatnetz befindet, werden die CDRs auch im I-CSCF erzeugt. Der gesamte Verlauf einer Sitzung wird von der P-CSCF mitverfolgt und kann teilweise von dieser koordiniert und gesteuert werden. 2 Als zentraler User Agent hat der S-CSCF direkten Zugriff auf eine oder mehrere Dienstplattformen (z. B. Application Server). Er steuert Multimediasitzungen. Während der zur SIP Registrierung gehörenden S-CSCF-Assignment Prozedur wird das Teilnehmerprofil vom HSS in eine lokale Datenbank der S-CSCF geladen. Der S-CSCF obliegt die Verhandlung und Auswahl der Ende-zu-Ende Dienstgüteparameter. Im Fall von Anrufen aus dem leitungsvermittelten Telefonnetz führt die S-CSCF ENUM-DNS Abfragen für die Adressübersetzung von E.164 UMTS Nummern in SIP-URIs durch. Die S-CSCF nimmt Registrierungsanfragen entgegen und lehnt Teilnehmer ab, für die der Zugriff auf IMS Dienste gesperrt ist. SIP-Anfragen oder SIP-Antworten werden von der S-CSCF bedarfsabhängig an die I-CSCF des eigenen 2

Für Notrufe und Location Based Services kann auch die P-CSCF die Rolle des User Agent übernemen.


■ ■ ■

205

oder eines Fremdnetzes weitergeleitet. Falls sich einer der Teilnehmer im leitungsvermittelten GSM Netz oder Telefonfestnetz befindet werden die SIP-Anfrage/Antworten an das BGCF weiter-geleitet. Policy Description Function (PDF): Die PDF wird entweder als logische Komponente innerhalb des P-CSCF oder als separater physikalischer Knoten realisiert. Die Funktion ist für die Zulassungskontrolle und die Zuweisung von Resourcen im paketvermittelten Transportnetz zuständig. Unter Anwendung der vom Netzwerkoperator definierten Regeln teilt die PDF für einen Dienst mit gegebenen QoS Anforderungen entsprechende Übertragungskapazität zu. Die Zuteilung erfolgt dabei auch in Abhängigkeit von den aktuell verfügbaren Kapazitäten. Die PDF selbst ist nur für die Zuteilung von Resourcen zuständig. Die Ausführung obliegt der Policy Enforcement Function (PEF) im GGSN. Breakout Gateway Control Function (BGCF): Die BGCF stellt den Übergang des IMS in ein öffentliches, leitungsvermitteltes Telefonnetz (PSTN für Public Switched Telephone Network) oder in die leitungsvermittelte (CS für Circuit Switched) Domäne eines Mobilfunknetzes dar. Auf Anfrage des S-CSCF bestimmt die BGCF das leitungsvermittelte Netz, in dem sich der adressierte Teilnehmer befindet. Handelt es sich dabei um dasselbe Netz, in dem sich auch die BGCF befindet, so wählt die BGCF eine Media Gateway Control Function (MGCF), die dann für den SIP-Nachrichtenaustausch mit der PSTN/CS Komponente verantwortlich ist. Andernfalls leitet die BGCF die SIP-Signalisierungs-nachrichten der Sitzung an die BGCF im Fremdnetz weiter. Dieses Weiterreichen an die externe BGCF kann optional auch indirekt über das I-CSCF laufen. Damit bleibt die Netzstruktur des Fremdnetzes nach außen verborgen. Darüber hinaus werden auch in der BGCF CDRs für die Abrechnung generiert. Media Resource Function (MRF): Die MRF besteht aus den Teilen MRF Controller (MRFC) und MRF Processor (MRFP). Der MRFC steuert die Medienstrom-Resourcen im MRFP. Hierzu muss er u. A. in der Lage sein die von der S-CSCF ankommenden Informationen zu interpretieren. Zu den vom MRFP bereitgestellten Resourcen für Medienströme gehören Mittel für die Unterstützung x des Abspielens von Medienströmen x des Multiplexing von mehreren Medienströmen x des Transcoding zwischen Audio- bzw. Video-Codecs x von Interaktionen mit dem Teilnehmer, z. B. das Erkennen und Erzeugen von DTMF (Dual-Tone Multi-Frequency) Signalen oder die Ankündigung von Multimediaströmen.

206

■ ■ ■

4 Mobile Multimedia

x von Multimediakonferenzschaltungen durch die Regelung des Zugriffs auf gemeinsam benutzte Resourcen x der Spracherkennung IMS Media Gateway (IMS-MGW): Im IMS-MGW werden Multimediadiensten aus bestehenden Netzen mit den IMS Diensten zusammengebracht. Im IMS-MGW terminieren die Transportkanäle von paket- und leitungsvermittelten Netzen. Protokolle, Codecs und Formatierungen werden im IMS-MGW entsprechend konvertiert. Darüber hinaus können auch die Nutzdaten aufbereitet werden, z. B. Echokompensation für Sprachübertragung. Über das IMS-MGW können vielfältige Multimediadienste aus Netzen wie UMTS-CS (leitungsvermittelte UMTS Domäne), PSTN, ISDN, oder LANs mit dem IMS verbunden werden. Media Gateway Control Function/Signalling Gateway (MGCF/SGW): Die oben beschriebene Verbindung von Multimediadiensten aus herkömmlichen Netzen mit den Diensten des IMS im IMS-MGW wird von der MGCF gesteuert. Das MGCF entscheidet also z. B. über notwendige Transcodierungen, Formatanpassungen und Nutzdatenaufbereitung. Im MGCF findet u. A. die Umwandlung von ISDN Signalisierungsnachrichten (ISUP für ISDN User Part Protocoll) in SIP-Nachrichten statt. Bei ankommenden Rufen aus einem externen Netz wählt das MGCF die zuständige CSCF Instanz aus. Das SGW ist für die Konvertierung der Signalisierungsprotokolle auf Transport-ebene zuständig. 4.2.3.2 Potential des IMS in UMTS Release 5 In [3gp05b] sind die Prozeduren des IMS definiert. Hierzu gehören u. a. x Sitzungsbezogene Prozeduren, wie z. B. die Initiierung, die Kontrolle oder das Beenden einer Sitzung x Anwendungsbezogene Prozeduren, wie z. B. die Nutzerdatenverwaltung oder der Download von Nutzerdaten x Aufenthaltsortbezogene Prozeduren wie z. B. das Ein- und Ausbuchen oder die Aufenthaltsortabfrage x Mobilitätsbezogene Prozeduren: IMS unterstützt personenbezogene Mobilität und Dienstmobilität. Endgerätemobilität bleibt jedoch vor dem IMS verborgen. Sie ist ausschließlich im Transportnetz implementiert. x Transportbezogene Prozeduren, wie z. B. das Aushandeln und die Einstellung von Ende-zu-Ende QoS Parametern


■ ■ ■

207

IMS unterstützt das Aufsetzen mehrerer paralleler Sitzungen, die unterschiedlichste Medien synchron oder asynchron integrieren. Damit ist die Grundlage für die Bereitstellung mobiler multimedialer Dienste geschaffen. In herkömmlichen Telekommunikationsnetzen sind die bereitgestellten Dienste eng mit den Übertragungskomponenten und den Endgeräten verwoben. Mit IMS ist diese Abhängigkeit aufgehoben, das heißt ein Operator kann multimediale Mehrwertdienste unabhängig vom zugrunde liegenden Transportnetz und von den benutzten Endgeräten netzwerkübergreifend und personenbezogen anbieten. Durch den IMS Zugriff über offene Schnittstellen, können neue Dienste ohne detailliertes Netzwissen entwickelt und in Form neuer bzw. erweiterter Application Server angeschlossen werden.

4.3 Entwicklung Mobiler Multimedia-Anwendungen Besonderheiten bei der Entwicklung mobiler Anwendungen

208

■ ■ ■

Im Gegensatz zur Entwicklung klassischer PC-Software muss bei der Softwareentwicklung mobiler Anwendungen stets der Faktor der Mobilität mit allen seinen Eigenschaften bedacht werden. Im Folgenden sollen einige Herausforderungen genannt werden, die speziell für die Entwicklung mobiler Anwendungen gelten. Bei der Bestimmung der nichtfunktionalen Anforderungen beispielsweise muss das besondere User Interface mit kleinen Displays und oft begrenzten Eingabemöglichkeiten berücksichtigt werden, beim Design einer Anwendung auf die beschränkte Bandbreite oder gar instabile Verbindung der Client-Server-Kommunikation geachtet werden. Je mehr Komplexität auf das Endgerät verlagert wird, desto weniger Bandbreite wird benötigt. Die Anwendung muss dann jedoch sehr sorgfältig auf dem Endgerät getestet werden, genauer gesagt auf jeder der möglichen Plattformen, was den Entwicklungsaufwand enorm ansteigen lassen kann. Für die Unit-Tests muss beachtet werden, dass die Software auf dem Emulator und dem Endgerät oft unterschiedlich reagiert. Nur der Test auf dem tatsächlichen Endgerät bringt ein sicheres Ergebnis und auch hier kann es Unterschiede geben je nach Firmware-Version des Gerätes. Bezüglich Deployment gibt es unterschiedliche Möglichkeiten. Für unabhängige Drittanbieter ist dies in der Regel der Download der Anwendung über das Internet durch den Nutzer. Ist die Software auf dem Endgerät installiert und trotz Tests noch fehlerhaft oder soll sie um Funktionalitäten erweitert werden, so sollte eine Update-Möglichkeit gegeben sein. Die Wartung der Software ist jedoch schwierig. Einmal installiert, besteht meist keine Verbindung zu einem Server mit Versionskontrolle mehr.

4 Mobile Multimedia

Zum Teil können die klassischen Werkzeuge erweitert werden, um die neuen Gegebenheiten bei sich bewegenden Endgeräten abbilden zu können. In [Bfa05] beispielsweise findet sich ein Vorschlag für die Erweiterung des UML-Standards für mobile Anwendungsentwicklung, basierend auf [Nun01]. Auch [Kna05] bieten einen ähnlichen Ansatz. „Multimedia“ stellt zusätzliche Anforderungen an Netze und Endgeräte, hauptsächlich begründet durch den oft hohen Datendurchsatz, aber auch aufgrund der Hardwareanforderungen an das Endgerät bei der Speicherung und Darstellung der MultimediaInhalte. Bezüglich Speicherplatz und Prozessorleistung sind mobile Geräte ihren Desktop-Äquivalenten meist weit unterlegen. Ein wichtiger Aspekt für den Entwickler von mobilen MultimediaAnwendungen besteht folglich darin, dass er im Vergleich zur klassischen Anwendungsentwicklung sehr viel mehr auf die Hardware achten muss. Die Ressourcen sind begrenzt und die Portierung der Anwendung auf die vielen unterschiedlichen Betriebssysteme und Plattformen ist oft sehr zeitaufwändig, nicht zuletzt aufgrund z. T. fehlerhafter Implementierungen der Endgeräte. Der Einsatz plattformunabhägiger Programmierung ist oft nicht möglich, da man sich diese mit nicht akzeptablen Einschränkungen der Funktionalität erkaufen müsste. Die Anforderungen und Funktionen der gegenwärtigen und zukünftigen mobilen Netze wurden in Kap. 4.2 abgedeckt. Dieses Teilkapitel soll eine Einordnung der möglichen Alternativen bei der Entwicklung mobiler Multimedia-Anwendung in Bezug auf die Implementierung auf den Endgeräten ermöglichen und widmet sich daher vor allem den unterschiedlichen Betriebssystemen und Plattformen.

Erweiterung der klassischen Werkzeuge

Hardwarenahe Entwicklung

4.3.1 Mobile Multimedia Endgeräte „Mobil“ heißt „beweglich“. Mobilität ist vor allem eine Frage von Größe, Gewicht und Unabhängigkeit bezüglich Stromversorgung und drahtgebundenen Verbindungen. Unter mobilen Endgeräten werden im folgenden Geräte verstanden, die diesen Anforderungen gerecht werden. Sie sind portabel, besitzen eine eigene Hardware mit entsprechender Stromversorgung und ein für multimediale Anwendungen geeignetes Betriebssystem. Abbildung 4.8 zeigt die unterschiedlichsten multimediafähigen mobilen Endgerätegruppen. Die für dieses Kapitel interessanten Geräte sind diejenigen, die auch von unabhängigen Software-Drittanbietern durch eigene Anwendungen erweitert werden können. Hierzu zählen Laptops, Tablet PCs, PDAs/MDAs und Smartphones.

4.3 Entwicklung Mobiler Multimedia-Anwendungen

■ ■ ■

209

Abb. 4.8: Mobile Multimedia Endgeräte

Laptops sind für die weiteren Ausführungen uninteressant. Sie sind aufgrund der im Vergleich zu beispielsweise Smartphones geringen Akkulaufzeiten nur bedingt portabel. Zum anderen stellen sie bezüglich der Hardwarefähigkeiten kaum einen Unterschied zu nichtmobilen Desktop-Rechnern dar. Eher exotische Vertreter wie Tablet-PCs oder SimPads spielen für den Massenmarkt keine große Rolle und sollen daher ebenso nicht weiter betrachtet werden. Die mobilen Endgeräte, die hier betrachtet werden, verfügen über sehr begrenzte Ressourcen. Sie müssen transportabel sein, also möglichst klein und leicht. Trotzdem sollten sie möglichst lange mit ihrem Akku betrieben werden können. Aus welchen Komponenten setzt sich ein mobiles Endgerät zusammen, damit es diesen Anforderungen gerecht werden kann? Der grundsätzliche Aufbau ist immer sehr ähnlich. In den nächsten Absätzen soll ein kurzer Blick auf die einzelnen Hardwarekomponenten geworfen werden. 4.3.1.1 Prozessoren CPU

RISC-Prozessoren

210

■ ■ ■

Die Hardware mobiler Endgeräte ist auf Embedded-Systeme und deren Einschränkungen ausgerichtet. Das heißt für den Hersteller insbesondere, dass er auf die Stromressourcen achten muss. Das Herz eines jeden Rechensystems stellt die CPU (Central Processing Unit), der Prozessor, dar. Da die Prozessoren bei mobilen Endgeräten neben dem Display den größten Teil der Energie verbrauchen, sind die eingesetzten CPUs langsamer getaktet als die von Desktop-Systemen. Die Taktzahlen liegen zwischen etwa 20 und 250 MHz bei Smartphones und bis ca. 600 MHz bei PDAs (Stand Anfang 2006). Ein großer Unterschied liegt

4 Mobile Multimedia

in der Prozessor-Architektur. Meist werden RISC (Reduced Instruction Set Computer)-Prozessoren eingesetzt, also Prozessoren mit kleinen und einfachen Instruktionssets. Die einzelnen Instruktionen benötigen bei der RISC-Architektur alle ungefähr gleich viel Zeit zur Ausführung. RISC-Prozessoren sind kostengünstiger und im Verhältnis zu ihrer Taktzahl sehr performant. Sie zeichnen sich durch ihre stromsparende Arbeitsweise aus, was sie für Embedded-Systeme prädestiniert. Zu den RISC-Prozessoren zählen die ARM/StrongARM (Advanced oder Acorn Risc Machines)-Prozessoren, sowie die XScale-Prozessoren von Intel, eine Weiterentwicklung der StrongARM-Prozessoren. XScale-Prozessoren befinden sich z. B. in den PDAs Dell Axim X50v, Palm Zire, Sharp Zaurus oder den Acer n50-Modellen, sowie in portablen Videoplayern oder Portable Media Centres. ARM-Prozessoren findet man in vielen Mobiltelefonen und den meisten Smartphones. MIPS (Microprocessor without interlocked pipeline stages) sind ebenfalls RISC-Prozessoren, ebenso die PowerPC-Architektur (Motorola) und OMAP (Open Multimedia Application Platform)-Prozessoren von Texas Instruments. Die Sony Playstation 2 und manche CompaqPDAs werden von Prozessoren mit MIPS-Architektur betrieben, OMAP-Prozessoren von Texas Instruments finden sich beispielsweise in einigen Palm Tungsten-Geräten [Pal06] oder auch in Geräten der Firma HTC. 4.3.1.2 Speicher Speicher auf mobilen Endgeräten muss vor allem robust und in den Dimensionen klein sein. Das Betriebssystem, Anwendungen sowie notwendigerweise persistente Daten wie PIM (Personal Information Management)-Eingaben des Benutzers sollten in nicht-flüchtigem Speicher abgelegt sein, da die Energiezufuhr durch den Akku begrenzt ist und jederzeit unterbrochen werden kann. Aufgrund dieser Anforderungen werden keine mechanisch anfälligen Speichermedien eingesetzt. Da die typischen RAM-Speicherbausteine keine persistenten Daten halten können, kommen meist Flash-Speichermedien zum Einsatz. Flash-Speicher ist eine Form des EEPROM (Electrically Erasable Programmable Read-Only Memory). Das heißt, dass die Speicherbereiche wiederbeschreibbar sind und kein Strom benötigt wird, um die Daten zu halten. Flash-Speicher wird in den meisten mobilen Endgeräten auf zwei Arten genutzt: Zum einen für die festen Bestandteile des Betriebssystems und für zusätzlich installierte Programme und Benutzerdaten, zum anderen als Laufzeit-


Anforderungen

Flash-Speicher

■ ■ ■

211

Speicher für Heap oder Stack. Die System-Programme werden auch direkt im Flash-Speicher ausgeführt und nicht erst über einen bootstrap-loader in flüchtiges RAM geladen, wie dies bei DesktopRechnern üblich ist. In Smartphones wird in der Regel nur nichtflüchtiger Flash-ROM eingesetzt, bei PDAs hingegen findet auch flüchtiger Speicher seinen Einsatz, was bei Leerlaufen des Akkus zu Speicherverlust führen kann [Lüd05]. Die Größe des Speichers mobiler Endgeräte reicht von wenigen KB bis zu mehreren MB und wächst aufgrund der technischen Weiterentwicklung immer weiter an. Oft können Geräte durch externe Speichermedien wie CF (Compact Flash)- oder SD (Secure Digital)-Karten erweitert werden. Diese externen Speicherkarten haben recht gute Leseeigenschaften bis über 1 MB/sec und mit um 150 ns akzeptable Zugriffszeiten. Sie sind rund 100.000 Mal wiederbeschreibbar. Im Vergleich zu einer Festplatte bieten sie neben ihrer geringen Größe und mechanischen Robustheit den Vorteil, dass sie wesentlich weniger Strom verbrauchen. Eine Festplatte benötigt mindestens 250 mA, eine Speicherkarte nur etwa ein Fünftel hiervon. [Leh03] 4.3.1.3 Ein-/Ausgabe Zwei Arten der Komponenten

Benutzer-Schnittstellen

212

■ ■ ■

Die Ein- und Ausgabemöglichkeiten bei mobilen Endgeräten können in zwei Kategorien eingeteilt werden. Zum einen die Komponenten, die als Schnittstelle zum Benutzer fungieren, zum anderen Komponenten, die Datenaustausch mit anderen Geräten ermöglichen. Die wichtigsten Ein- und Ausgabemöglichkeiten gegenüber dem Benutzer sind zweifellos Display, Tastatur und die Audiokomponenten Mikrofon und Lautsprecher. Weitere Fähigkeiten wie der Vibrationsalarm sollen hier nicht weiter betrachtet werden. Mobile Geräte verfügen über Displays, die immer mehr Pixel in immer besserer Farbtiefe darstellen können. Aufgrund der Anforderungen der Mobilität jedoch reichen diese nicht an Displays von DesktopRechnern heran. Sie dienen oft als Touchscreen, was ohne zusätzlichen Platzbedarf ein Mehr an Möglichkeiten bietet, auch Handschrifterkennung funktioniert mittlerweile sehr zuverlässig und kann als Alternative zu einer Tastatur verwendet werden. Eine Ausgabe der Inhalte unter Einsatz eines kleinen eingebauten Projektors könnte in Zukunft weitere Möglichkeiten eröffnen, ist momentan jedoch noch nicht verfügbar. Tastaturen gibt es, je nach Gerät, in unterschiedlichen Ausführungen. Von nur wenigen Tasten bei touchscreenfähigen Smartphones bis hin zu umfangreichen QWERTZ/QWERTY-genormten Tastaturen bei informationszentrischen Geräten.

4 Mobile Multimedia

Mobile Geräte können selten alle notwendigen Informationen vorhalten, müssen diese oft von außen beziehen und daher kommunizieren. Hierzu stehen zahlreiche Technologien zur Verfügung. Die installierten Anwendungen und das Betriebssystem können über spezielle Schnittstellen auf die Hardware zugreifen und so mit externen stationären oder nichtstationären Gegengeräten Daten austauschen. Zur Sprachtelefonie-Schnittstelle kommen heute zahlreiche Kommunikationsmöglichkeiten hinzu: GPRS, UMTS, Infrarot, WLAN oder Bluetooth. Entwickelt sich ein neuer Standard bei den mobilen Netzen, sollte dieser von den Endgeräten auch genutzt werden können. Hierzu kann dann beispielsweise ein neuer Funktransmittor-Chip integriert und in das Betriebssystem eingebunden werden. Doch die Komponenten zur Kommunikation mit der „Außenwelt“ benötigen Strom − einer der Gründe, warum in mobilen Endgeräten mit begrenzten Ressourcen die Bluetooth-Technologie z. B. recht häufig integriert ist, das schnellere WLAN hingegen noch eher selten: Bluetooth-Komponenten verbrauchen weniger Energie. Der Energieverbrauch des Bluetooth-Transmitters liegt bei der Service Discovery bei ca. 200 mW, sonst bei ca. 100 mW. Der Energieverbrauch bei WLAN-Kommunikaion hingegen kann auf bis zu 3000 mW ansteigen. [Ang03]

Kommunikationsschnittstellen

4.3.1.4 Stromversorgung Naturgemäß besitzen mobile Endgeräte eine mehr oder weniger große Stromquelle. In den meisten Geräten finden sich Lithium-Ionen- oder Lithium-Polymer-Stromversorger. Obwohl die Akkumulatoren immer kleiner und leistungsfähiger werden, stellt dieses Bauteil in mobilen Endgeräten immer noch das Einzelteil mit dem größten Gewicht dar.

4.3.2 Mobile Multimedia Software-Plattformen Mobile Multimedia erfordert nicht zwingend eine drahtlose Netzverbindung. Ein Handyspiel beispielsweise fällt sehr wohl in den Bereich mobile Multimedia-Anwendung, kann aber vollkommen „offline“ gespielt werden, falls das mobile Endgerät die erforderlichen Soft- und Hardwareanforderungen erfüllt. Ein Multiplayer-Spiel erfordert hingegen eine stabile Verbindung zu einem Server. Hier existieren also zusätzlich Anforderungen an das übermittelnde Netz und den Server. Andere Anwendungen wiederum stellen kaum Anforderungen an das Endgerät. Bei einer WAP-Anwendung beispielsweise genügt auf Seite


Netzwerke und Mobile Multimedia

■ ■ ■

213

Einteilung anhand der Komplexität der Client-Software

Viele unterschiedliche Plattformen

214

■ ■ ■

des Endgeräts ein standardkonform implementierter WAP-Browser, um dem Nutzer die Seiten korrekt darzustellen. Anhand dieser Beispiele kann man erkennen, wie unterschiedlich die Entwicklung von mobilen Multimedia-Anwendungen sein kann. Da immer eine mehr oder weniger aufwändige Implementierung auf Seite des mobilen Endgeräts erforderlich ist − nicht zwingend auf dem Server − kann man mobile Anwendungen anhand der softwareseitigen Komplexität des Clients auf dem mobilen Endgerät einteilen: x Client-Server-Anwendung mit Thin Client: Eine dauerhafte und stabile Verbindung zu einem (stationären) Server ist notwendig. Dieser Ansatz entspricht dem klassischen Web-Modell: Für die unterschiedlichen clientseitigen Betriebssysteme werden nach vorgegebenen Spezifikationen passende Browser implementiert, die dann Markup-Code laden und rendern. Der Anwendungsentwickler braucht sich nicht um die Umgebung kümmern, auf der dieser Thin Client läuft. WAP und die dazugehörige WML-Sprache sind ein Beispiel hierfür. x Client-Server-Anwendung mit Thick Client: Eine Kommunikation mit einem (stationären) Server ist notwendig, auf dem mobilen Endgerät ist jedoch Software mit komplexer Logik implementiert. Die Anwendung auf dem mobilen Endgerät kann eine vollwertige Applikation sein, die nur zeitweise Verbindung zum Server aufbauen muss. Für Vorgänge, die nicht zentral synchronisiert werden müssen, werden die entsprechenden Daten auf dem Endgerät gespeichert. Ein mobiler Stadtinformationsdienst, der z. B. vor Ort über Bluetooth Videos von einem lokalen Provider lädt, würde als Thick Client-Anwendung realisiert. x Stand-alone-Anwendung: Wie Thick Client, nur mit dem Unterschied, dass keine Netzwerkanbindung notwendig ist. Viele der ersten Palm-Anwendungen konnten beispielsweise nur über das Cradle an den Palm übertragen werden und liefen dann ohne Netzwerkanbindung. Ein Handyspiel ohne Netzwerkabhängigkeit ist ebenso eine Stand-Alone-Anwendung. [Bfa05] Abbildung 4.9 gibt einen Überblick über die Betriebssysteme und Plattformen, die in diesem Kapitel behandelt werden und weist auf, wer die Implementierung vornimmt. Die Herausforderung bei der Entwicklung von Anwendungen bestehen zum einen in den begrenzten Ressourcen auf dem Client, besonders aber auch in der großen Anzahl an unterschiedlichen Plattformen für mobile Endgeräte. Da die Einzelteile für ein mobiles Endgerät im Vergleich eher kostengünstig erworben und zusammengestellt werden können, tummeln sich auf dem Markt wesentlich

4 Mobile Multimedia

Abb. 4.9: Übersicht über Betriebssysteme und Plattformen

mehr Anbieter, die sich auf spezielle Anwendungen fokussieren, verglichen mit dem PC-Markt. Aus diesem Grunde entwickelten sich auch mehr Betriebssysteme und Plattformen als im klassischen Desktop-Bereich. Wie soll man also für all diese Plattformen entwickeln können? Es gibt Software-Lösungen, bei denen − wie z. B. bei Symbian OS − die einzelnen Gerätehersteller die notwendigen Werkzeuge zur Verfügung stellen, damit Anwendungen für ihre Geräte entwickelt werden können. J2ME löst das Problem mit Hilfe der Java Virtual Machine, die auf den unterschiedlichen Endgeräten den Java-Bytecode umsetzt. Flash-Lite-Anwendungen können auf dem Endgerät ebenfalls mit Hilfe eines speziellen Players ausgeführt werden. Alternativ dazu existieren Hardware-Lösungen: Hersteller wie Qualcomm stellen eine Entwicklungsumgebung zur Verfügung, die direkt auf der Hardware aufsetzt (BREW, s.u.). Die meisten Entwicklungsumgebungen und Frameworks der großen Softwarefirmen heutzutage sind für Softwareentwicklung für nichtmobile Systeme geschrieben worden. Je näher die Werkzeuge an der Hardware ansetzen (z. B. der Compiler), desto eher sind sie auch für mobile Anwendungsentwicklung geeignet. So entwickelt sich derzeit ein neuer Markt rund um die Softwareentwicklung für mobile Systeme [Bfa05]. Die großen Softwarehäuser bemühen sich, ihre bekannten IDEs (Integrated Development Kits) so anzupassen, dass mit ihnen für möglichst viele Endgeräte entwickelt werden kann. Auch hinsichtlich der Programmiersprachen bestehen teils erhebliche Unterschiede bei der Anwendungsentwicklung für den mobilen Bereich. Um den Anforderungen der begrenzten Ressourcen gerecht zu werden, wurden zum einen neue Programmiersprachen entwickelt, wie z. B. OPL (Open Programming Language) für Symbian OS, zum anderen wurden etablierte Sprachen modifiziert (z. B. J2ME, s.u.) und


Entwicklungsumgebungen

Programmiersprachen

■ ■ ■

215

Look-and-Feel

216

■ ■ ■

neue Konzepte entwickelt (z. B. Active Objects unter C++ for Symbian). Auch manche Design Patterns, die sich in der objektorientierten Programmierung bewährt haben, sollten im mobilen Bereich aufgrund der Einschränkungen nicht eingesetzt werden. Bei einem Design mit übersichtlicher Kapselung in Klassen beispielsweise werden viele Objekte erzeugt, was Performanz und Speicher verbraucht. Bei mobilen Anwendungen muss hier ein Schritt zurück gegangen und möglichst wenig Objekte erzeugt, diese dann aber wieder verwendet werden. Derzeit werden viele Geräte in C- oder C++-ähnlichen Sprachen programmiert. Eine alternative Programmierweise ist das plattformunabhängige Java. Das Prinzip „write once, run everywhere“ klingt sehr vielversprechend. Auf mobilen Endgeräten laufen aufgrund des begrenzten Speichers jedoch meist keine Java Virtual Machines mit vollem Funktionsumfang. Der komfortable Garbage-Collection-Mechanismus bei J2SE beispielsweise wird nur eingeschränkt unterstützt. Zusätzliche Einarbeitung ist daher notwendig, was leider durch z. T. schlechte oder gar fehlerhafte Dokumentation erschwert wird. Auch fehlerhafte Implementierungen der Gerätehersteller führen oft dazu, dass das Prinzip der Plattformunabhängigkeit nicht gegeben ist. Der Markt der mobilen Endgeräte zeichnet sich durch große Dynamik aus, der Lebenszyklus eines Mobiltelefons ist bedingt durch die schnelle technologische Weiterentwicklung recht kurz. Dies führt dazu, dass mobile Endgeräte oft nicht ausgereift sind und das manuelle Testen direkt auf dem Endgerät unumgänglich ist. Die Betriebssysteme werden von den Geräteherstellern oft nicht nur hinsichtlich Gerätetreiber und Hardware modifiziert, sondern auch das Look-and-Feel wird verändert, um sich von den Mitbewerbern zu differenzieren. Eigene Styleguides werden herausgegeben, eigene Konzepte der Benutzerführung entwickelt, an die sich der Anwendungsentwickler halten soll. Dies führt zu einer recht unübersichtlichen Anzahl an SDK (Software Development Kit)-, UI (User Interface)- und Emulator-Versionen, die dann in ebenso zahlreiche IDEs eingebunden werden. In diesem Kapitel sollen die Besonderheiten der Anwendungsentwicklung für mobile Endgeräte mit speziellem Fokus auf multimediageeignete Betriebssysteme und Plattformen erläutert werden. Dabei werden zunächst einführende Hintergrundinformationen geliefert, anschließend die Architektur erklärt. Ebenso wird auf die jeweiligen Entwicklungsumgebungen eingegangen. Nach Ausführungen über Programmiersprachen und evtl. -konzepte werden noch die jeweiligen Multimediafähigkeiten betrachtet.

4 Mobile Multimedia

4.3.2.1 Nicht erweiterbare Betriebssysteme Wie oben bereits erwähnt, gibt es für mobile Endgeräte eine Vielzahl von Betriebssystemen, was auch daran liegt, dass diese zu den Embedded-Systemen zählen. Diese zeichnen sich u. a. dadurch aus, dass sie ein speziell für sie zugeschnittenes Betriebssystem haben. Heute ist es meist günstiger, selbst einfache Funktionen mit einem Prozessor und Software zu kontrollieren als eine eigene Schaltung zu entwickeln [Kal05]. So auch bei den kostengünstigen low-end Mobiltelefonen, die allenfalls noch eine Java Virtual Machine enthalten, um Java-Anwendungen ausführen zu können. Nokia, der weltweit größte Hersteller von Mobiltelefonen, verfolgt dieses Konzept mit dem NOS (Nokia Operating System), das hauptsächlich auf den Mobiltelefonen der Series 40 eingesetzt wird [Nok06]. Ein weiteres Beispiel ist das Betriebssystem der Firma Enea: Das OSE RTOS (Real-Time Operating System) ist für viele unterschiedliche Prozessorarchitekturen erhältlich (ARM/StrongARM, MIPS, PowerPC, OMAP, …) und wird von Herstellern mobiler Engeräte als Lizenznehmer in ihren Geräten implementiert. Zwar gibt es auch für diese Plattformen Entwicklungsumgebungen mit Emulatoren, eigene komplexe Anwendungen kann man jedoch nicht entwickeln. Nokia hat z. B. für ihre Series 40-Geräte ein SDK (das Mobile Internet Toolkit) herausgebracht, mit dem man WML, XHTML und MMS-Inhalte testen kann. Diese nicht erweiterbaren Betriebssysteme sollen hier nicht näher betrachtet werden. 4.3.2.2 Symbian OS Die Ursprünge des Betriebssystems Symbian OS sind auf das von der Firma Psion Computers entwickelte Betriebssystem SIBO zurückzuführen („Sixteen Bit Organizer“ oder „Single-Board“ – je nach hardware- oder softwarenaher Betrachtung). Psion brachte im Jahre 1991 die „Series 3“ auf den Markt, dessen Display bereits die halbe VGAAuflösung erreichte. Die SIBO-Geräte waren sehr erfolgreich, unter anderem da sie sehr stromsparend waren, leistungsfähige Anwendungen beinhalteten und einfach mit anderen Geräten wie z. B. PCs kommunizieren konnten. Aufgrund der Nachteile, die ein in C programmiertes 16-Bit-Betriebssystems mit sich bringt, entschied sich Psion jedoch, ein neues Betriebssystem zu entwickeln, welches 1997 unter dem Namen „EPOC“ (für „Epoche“) erstmals auf Psions „5mx“ einge-


■ ■ ■

217

setzt wurde. Für die Weiterentwicklung von EPOC wurde 1998 die unabhängige Firma „Symbian“ gegründet, an der sich neben Psion die vier größten Mobiltelefonhersteller Nokia, Ericsson, Motorola und Panasonic beteiligten. Motorola hat mittlerweile seine Anteile verkauft und ist nunmehr Lizenznehmer. Im Februar 2004 verkaufte auch Psion seine Anteile, welche unter den übrigen Eigentümern verteilt wurden. Nokia, der weltweit größte Hersteller von Mobiltelefonen, hält nun 47,9% der Anteile, hat sich also klar zu Symbian OS bekannt [Sym06]. Symbian befindet sich mittlerweile in der Version 9.2 (Stand Januar 2006) und läuft im Gegensatz zu einigen Mitkonkurrenten sehr stabil. Die Flexibilität der Benutzeroberfläche ist eines der Schlüsselkonzepte von Symbian. Je nach Formfaktor und Eingabegeräte können die Gerätehersteller die Benutzerschnittstellen individuell anpassen und ein eigenes Look-and-Feel entwickeln. Hierzu ist Symbian sehr modular aufgebaut, die Funktion ist streng von der Oberfläche getrennt. Symbian stellt die Kern-Frameworks und -Dienste zur Verfügung (s. Abb. 4.10, weiße Komponenten). Diese entsprechen ca. 80% aller APIs (Application Programming Interface). Der Hersteller des Mobiltelefons integriert die für sein Gerät passende Oberfläche (graue Komponenten, zweite Zeile in Abb. 4.10). Uikon stellt ein generisches Framework für die Benutzeroberfläche auf allen Symbian-Geräten dar, das Produkt-User-Interface enthält die Oberflächen-Bibliotheken, die vom Symbian-Lizenznehmer für spezifische Gerätemodelle entwickelt werden. Das Aussehen wie Farben oder Größe der OberflächenKontrollelemente werden in der Product LAF (Look-and-Feel)-Bibliothek vom Lizenznehmer festgelegt. Die Komponenten basieren auf dem UI Control Framework, das die grundlegenden abstrakten Konzepte der User-Schnittstellen definiert und auf der Application Architecture-Komponente, die das abstrakte Application Framework (s. u.) beschreibt. Die SDKs der Lizenznehmer stellen der Anwendung dann das passende User Interface der entsprechenden Plattform zur Verfügung. Symbian OS ist ein sehr erfolgreiches und weit verbreitetes Betriebssystem, Architektur und Programmierung sollen hier daher eingehender betrachtet werden.

Abb. 4.10: UI-Komponenten unter Symbian OS

Architektur Abbildung 4.11 gibt eine Übersicht über die Software-Architektur der Symbian OS Version 9:

218

■ ■ ■

4 Mobile Multimedia

Kernel und Hardware Integration Die unterste Ebene beinhaltet mit Kernel und Gerätetreiber die Grundlegensten und wichtigsten Komponenten. Sie stellt eine Abstraktionsebene dar, so dass die Portierung auf unterschiedliche Hardware erleichtert wird. Diese Basis soll Robustheit, Performanz und effizientes Power Management sicherstellen. Der Kernel in Symbian wurde speziell auf die Anforderungen eines Betriebssystems für ein Mobiltelefon angepasst. Um ihn möglichst klein, effektiv und flexibel gegenüber der Peripherie zu halten, ist er in Form eines Mikrokernels realisiert, das heißt nur die allerwichtigsten Funktionen sind im Kernel implementiert. Er läuft nativ auf ARMProzessoren. Der Kernel läuft als einziges Programm im PrivilegienModus und hat direkten Zugriff auf die Hardware. Ihm kommen daher die Aufgaben der Verwaltung von Prozessen und Threads (Implementierung der Warteschlangen-Politik), Interprozesskommunikation, Speicherverwaltung und Power Management zu. Die User Library bildet die Schnittstelle zwischen dem Kernel und der restlichen Software und ist somit die unterste Ebene im nichtprivilegierten User-Modus. Neben den Kerneldiensten stellt die unterste Ebene Gerätetreiber und/oder Software-Controller für die seriellen Schnittstellen, Infrarot, USB, LCD, Keyboard und Ethernet zur Verfügung, ebenso Verweise auf die Multimedia-Gerätetreiber.


Abb. 4.11: Software-Architektur von Symbian OS v9

■ ■ ■

219

Base Services Die Basisdienste stellen das Programmierframework für alle anderen Symbian OS Komponenten zur Verfügung, so z. B. low-level-Bibliotheken wie Cryptographie, Datenbank-Engine oder auch Fileserver mit Zugriff auf internen und externen Speicher. OS Services Symbian OS beinhaltet verschiedenste Systemdienste. So stellt z. B. das Multimedia Framework (MMF) ein leichtgewichtiges MultithreadingFramework für Multimediadaten zur Verfügung, enthält beispielsweise Funktionalitäten für Audio-/Video Aufnahme oder – Wiedergabe, während das Media Device Framework eine Hardware-Abstraktionsebene für Audio, Video, MIDI und Sprache darstellt. Das Sicherheits-Subsystem sorgt für die Sicherheit und Integrität von Daten. Über Serial&Shortlink-Dienste wird Point-to-Point Kommunikation mit anderen Geräten unterstützt – über Bluetooth, seriell, USB oder Infrarot. Für Wide Area Networks unterstützt Symbian OS im Netzwerk-Dienste-Subsystem verschiedenste Kommunikationsprotokolle über eine Socketschnittstelle. Grafikdienste verwalten den Zugriff auf das Display, Keyboard, Stifteingabe, Schriftarten. Um Synchronisation und Backups mit dem PC zu ermöglichen, wird ein Toolkit zur Verfügung gestellt, auf dem dann die einzelnen Gerätehersteller aufbauen können, um eine geeignete Lösungen für ihr Gerät zu implementieren. Application Services Die Ebene der Anwendungsdienste enthält mit PIM-Engine, dem Messaging- und dem Datensynchronisations-Subsystem die Kernanwendungen von Symbian OS. Auf diesen Diensten können Lizenznehmer dann aufbauen. User Interface Framework Symbian OS unterstützt durch sein Design eine große Variation an Benutzeroberflächen. Das Application Framework stellt eine mächtige Umgebung für Symbian OS Lizenznehmer zur Verfügung, um differenzierte Nutzeroberflächen zu erstellen und gleichzeitig Kompatibilität für Anwendungsentwickler zu gewährleisten. Für die Entwicklung dieser unterschiedlichen Benutzeroberflächen stellt das UI Toolkit den Entwicklern generische Werkzeuge zur Verfügung. Java Symbian’s Java Virtual Machine wurde für mobile Endgeräte und mobile Anwendungen optimiert. Zum einen wird dadurch Kompatibilität

220

■ ■ ■

4 Mobile Multimedia

mit für mobile Endgeräte geschriebene Java-Anwendungen gewährleistet, zum anderen erlaubt Symbian OS Java-Programmen, auf viele Funktionen eines Symbian-Gerätes zuzugreifen. Symbian OS ermöglicht J2ME-Programmen neben MIDP 2 und CLDC 1.1 z. B. auch den Einsatz von Bluetooth (JSR-82) oder 3D-Grafik (JSR-184). Entwicklungsumgebung Wie oben bereits erwähnt, existieren, basierend auf den unterschiedlichen Betriebssystemversionen des Symbian OS-Grundsystems, unterschiedliche Plattformen. Symbian teilte diese Varianten in drei Gerätefamilien ein: Pearl, Crystal und Quartz. Daran angelehnt entwickelten sich einige GUI (Graphical User Interface)-Varianten. Abb. 4.12: GUI-Varianten für Symbian OS

Pearl-Geräte sind sprachzentrische Geräte. Ihre Tastatur hat den Umfang einer typischen Mobiltelefontastatur, sie sind daher auf EinHand-Bedienung ausgelegt. Desweiteren enthalten diese Geräte erweiterte Informations-Funktionen, wie z. B. einen Browser oder Werkzeuge zur Adressverwaltung. Nokia setzt das Pearl-Design auf ihren Series 60-Geräten ein. Geräte der Crystal-Familie haben eine vollständige Tastatur und sind eher informationszentrische Geräte mit Telefonfunktion. Nokia hat mit der Communicator-Serie bereits sehr früh Geräte auf den Markt gebracht, die dieses Referenzdesign verwendeten. Die Series 80 (früher Communicator)-Serie verfügt über einen großen Funktionsumfang und hat teilweise auch WLAN integriert. Quartz-Geräte zeichnen sich hauptsächlich durch ihr touchscreenfähiges Display aus. Sie sind auch eher informationszentrische Geräte mit Telefonfunktion, enthalten aber keine vollwertige Tastatur wie das Crystal-Design. Sony Ericsson beispielsweise setzt auf seinen Touchscreen-Geräten P800/P900/P910 dieses Referenzdesign ein und nennt die dazu passende GUI-Variante „UIQ“ (User Interface Quartz). Für die Weiterentwicklung dieses User Interfaces wurde die gleichnamige Firma gegründet. UIQ gibt es mittlerweile in der Version 3.0 [Uiq06].


Pearl

Crystal

Quartz

■ ■ ■

221

Erstellung von Symbian-Anwendungen

Eine GUI-Variante, die diese drei Referenzdesigns noch erweitert, wurde von Nokia mit Series 90 geschaffen. Der Prototyp 7210 wurde nicht weiter entwickelt, das Nachfolger-Gerät 7710 ist dank seines großen Displays und Touchscreen besonders für MultimediaAnwendungen geeignet. Für den unabhängigen Softwareentwickler ist es zunächst wichtig, die GUI-Variante festzulegen, sowie die Betriebssystem-Version, für die entwickelt werden soll. So kann man meist schon die notwendige SDK-Version herausfinden. Diese wird in der Regel vom Hersteller kostenlos zur Verfügung gestellt. Die SDKs beinhalten die notwendigen Werkzeuge, um Symbian OS-Anwendungen auf dem PC zu emulieren und für die Zielplattform zu bauen, sowie Beispielanwendungen und Dokumentation. Weitere Informationen hierzu finden sich unter [Sym06b]. Der Build-Prozess unter Symbian ist recht komplex (s. Abb. 4.13) und es erfordert viele Schritte und symbianspezifische Dateien, bis am Ende eine lauffähige Anwendung auf das Endgerät übertragen werden kann. Um komfortabel mit den zahlreichen SDK-Tools arbeiten zu können, werden diese in der Regel in eine (meist kommerzielle) Entwicklungsumgebung integriert. Hier bieten die großen Softwarehersteller passende Umgebungen an, wobei nicht für jede Plattform mit jeder IDE programmiert werden kann. Für UIQ beispielsweise wird meist das Produkt „Codewarrior“ von Metrowerks genutzt, für die NokiaGeräte der unterschiedlichen Serien kann auch Microsoft’s Visual Studio eingesetzt werden. Auch Borland ist mit passenden Produkten am Markt vertreten. Nokia bietet unter dem Namen „Carbide“ eine

Abb. 4.13: Build-Prozess unter Symbian OSv6

222

■ ■ ■

4 Mobile Multimedia

neue Serie von Werkzeugen an. Mit carbide.vs steht ein Plugin zur Verfügung, mit dem Series 60 und Series 80-Programmierung unter Microsoft Visual Studio vereinfacht wird. Mit mehreren Versionen der „Carbide.c++“- Entwicklungsumgebungen bietet Nokia z. T. kostenlose Werkzeuge zur Symbian-Programmierung an, die auf der freien Entwicklungsumgebung Eclipse basieren. [Nok06]. Emulatoren sind in allen SDKs enthalten, On-Device-Debugging hingegen bietet bisher nur Metrowerks Codewarrior (Stand April 2006). Allerdings ist dieses auch eher instabil, so dass viel manuelles Testen auf dem Endgerät (u. U. unter Einsatz eines Error Loggers) notwendig ist. Programmierung unter Symbian OS Es gibt zahlreiche Sprachen, in denen für Symbian OS programmiert werden kann: C/C++, Java, PersonalJava, OPL, Visual Basic, Python, Simkin, Perl, … Allerdings existieren nicht für jede Sprache entsprechende Compiler für alle Zielplattformen, Series 60-Geräte können beispielsweise nicht mit PersonalJava programmiert werden. Die am häufigsten eingesetzte Sprache ist C++. Mit C++ unterliegt der Programmierer keinen Einschränkungen einer Runtime Engine wie bei Java oder OPL und es gibt auch entsprechend gute Unterstützung durch Entwicklungsumgebungen. Symbian OS selbst ist in C++ geschrieben, diese Programmiersprache bietet daher den größtmöglichen Zugriff auf das Betriebssystem und die beste Performanz bezüglich Speicherbedarf und Ausführungsgeschwindigkeit. Bestimmte Programmtypen wie Server oder Gerätetreiber können nur in C++ geschrieben werden. Die Programmierung unter Symbian OS bietet einige interessante Konzepte, auf die hier kurz eingegangen werden soll. Anschließend folgt ein Codebeispiel, um einen Einstieg in die Programmierung in C++ for Symbian zu ermöglichen.

C++ for Symbian

Konzepte der SymbianProgrammierung

Threads, Prozesse und Speicher Threads und Prozesse werden vom Kernel mit präemptivem Multitasking verwaltet, bei gleichpriorisierten Threads greift das RoundRobin-Verfahren (auf einem ARM-Prozessor z. B. mit 64 Hz). Da Prozess-Switching viel Rechenleistung erfordert und Symbian OS viel Gebrauch von internen Servern wie Fileserver/Windowsserver macht, sind manche Server, die eng zusammen arbeiten, in einem einzigen Prozess zusammengefasst. So laufen beispielsweise alle wichtigen Kommunikations-Server (Seriell-, Socket-, Telefon-Server, etc.) in einem gemeinsamen Prozess ab. Symbian-Geräte verfügen über Flash-Speicher. Systemprogramme und Betriebssystem liegen im ROM, werden fix adressiert und dort


■ ■ ■

223

auch direkt ausgeführt. Weitere Programme, Laufzeitspeicher, dynamisch geladene Bibliotheken etc. werden im RAM virtuell adressiert, wobei die MMU (Memory Management Unit) den RAM in 4 KB-große Teile einteilt.

Active Objects In anspruchsvollen Anwendungen müssen oft Hintergrundaufgaben erledigt oder asynchrone Anfragen bearbeitet werden. Damit Anwendungen und Server, die in einem einzigen Thread ablaufen, dennoch effektiv arbeiten können, hat Symbian auf ein gutes Event HandlingSystem Wert gelegt, das auf Active Objects aufgebaut ist. Alle Threads in Symbian sind eigentlich Event-Handler mit einem so genannten „Active Scheduler“ pro Thread. Dieser hat ein oder mehrere Active Objects. Man kann sich den Active Scheduler auch als Mini-Kernel vorstellen und ein Active Object als Mini-Thread. Active Objects sind wie Threads auch prioritätenbasiert, jedoch innerhalb eines ThreadKontextes nicht präemptiv (s. Abb. 4.14). In Symbian OS wird Multitasking vorzugsweise durch Active Objects verwirklicht und nicht durch Multithreading. Prozesse benötigen daher typischerweise nur einen einzigen Thread. Durch Active Objects gewinnt der Anwendungsentwickler sehr an Bequemlichkeit, da er auf Verfahren wie Mutexes, Semaphoren, kritischen Sektionen, etc. um sich gegen Eingriffe anderer Active Objects im eigenen Thread zu schützen, verzichten kann. Active Objects werden vom Kernel unterstützt und bieten eine interessante und ressourcenschonende Lösung für ein eventbasiertes Multitasking. [Suc04] Abb. 4.14: Scheduling bei Active Objects

224

■ ■ ■

4 Mobile Multimedia

Deskriptoren Für die Verarbeitung von Strings und Binärdaten gibt es unter Symbian OS ein neues Konzept. Strings können auf zwei unterschiedliche Weisen angelegt werden. Zum einen als so genannte „Literals“. Diese werden fest in den Binär-Programmcode eingebaut. Zum anderen können Strings auch als so genannte „Deskriptoren“ angelegt werden. Neu ist das Konzept deshalb, weil Deskriptoren für Strings und Binärdaten gleichermaßen eingesetzt werden. Deskriptoren sind komfortabler als die Stringverarbeitung in C, erlauben aber im Gegensatz zu Java die volle Kontrolle über den Speicherverbrauch. [Tas00] Application Framework Symbian gibt in seinem Application Framework vor, dass für die Erstellung einer Anwendung mit grafischer Oberfläche Instanzen von mindestens vier Klassen erzeugt werden müssen. Hierbei wird streng das Model-View-Controller Design Pattern eingehalten, das Darstellung, Logik und Datenhaltung voneinander trennt. So ist zum einen Übersichtlichkeit gewährleistet und zum anderen soll die Portierung auf andere Systeme erleichtert werden. Ressourcendateien Wie andere Betriebssysteme auch, verwendet Symbian OS Ressourcen-Dateien, um z. B. GUI-Elemente wie Dialogfenster, Menüs definieren. Auch Texte, die zur Laufzeit von der Anwendung geladen werden können, können als Ressource mit eigener ID definiert werden. Texte können so getrennt von der Anwendungslogik verändert werden, was für mehrsprachige Anwendungen recht komfortabel ist. Die Ressourcen-Datei in Symbian wird von einem eigenen Ressourcencompiler erstellt und kann auch getrennt von der eigentlichen Anwendung auf das Zielgerät übertragen werden. Codebeispiel Wählt der Anwender im Smartphone eine Anwendung aus, so wird ein kleines Programm namens apprun.exe aufgerufen, das dann einen neuen Prozess startet und die Anwendung als DLL in ihren Kontext lädt. Hierbei wird als Einstiegspunkt die globale Methode E32DLL aufgerufen. ...

GLDEF_C TInt E32Dll(TDllReason /*aReason*/) { return KErrNone; } EXPORT_C CApaApplication* NewApplication() { return new CHelloWorldApplication; } CApaDocument* CHelloWorldApplication::CreateDocumentL() { return new (ELeave) CHelloWorldDocument(*this); } ...


■ ■ ■

225

CHelloWorldDocument::CHelloWorldDocument(CEikApplication& aApp) : CEikDocument(aApp) {} CEikAppUi* CHelloWorldDocument::CreateAppUiL() { return new (ELeave) CHelloWorldAppUi; } void CHelloWorldAppUi::ConstructL(void) { ... iAppContainer = new (ELeave) CHelloWorldContainer; ... } CHelloWorldAppUi::~CHelloWorldAppUi() { ... } void CHelloWorldAppUi::HandleCommandL(TInt aCommand) { switch (aCommand) { case EEikCmdFileOpen: { CAknInformationNote* note = new (ELeave) CAknInformationNote; note->ExecuteLD(_L("Hello world!")); break; } case EAknSoftkeyBack: case EEikCmdExit: { Exit(); break; } default: break; } } void CHelloWorldContainer::ConstructL(const TRect& aRect) { CreateWindowL(); iLabel = new (ELeave) CEikLabel; iLabel->SetContainerWindowL( *this ); iLabel->SetTextL( _L("Example View") ); ... } CHelloWorldContainer::~CHelloWorldContainer() { ... } ...

Danach ruft das Framework die Funktion NewApplication() auf, wodurch eine Instanz der Application-Klasse erzeugt wird und anschließend die Funktion AppDllUid() des neuen ApplicationObjektes, um die UID der Anwendung abzufragen. So kann geprüft werden, ob das Programm nicht bereits läuft. Dann wird die Methode CreateDocumentL() aufgerufen. Eine Instanz der DocumentKlasse wird erzeugt, die für die Datenhaltung zuständig ist (entspricht dem „Model“ im Model-View-Controller Design Pattern). In der Methode CreateAppUiL() der Document-Klasse schließlich wird eine Instanz der ApplicationUI-Klasse erzeugt. Diese stellt die zentrale Klasse der Anwendung dar und ist für die Anwendungslogik zuständig (Controller). Hier werden in der Funktion HandleCommandL() z. B. Events abgehandelt, die vom Nutzer bei Auswahl eines Menüpunktes ausgelöst werden. Die ApplicationUI-Klasse erzeugt einen oder mehrere Views, die die Darstellung gegenüber dem Nutzer übernehmen. Bei Series 60-Geräten geschieht dies über einen Container, der dann wiederum die einzelnen Views erzeugt, bei der Programmierung unter UIQ werden die Views direkt von der ApplicationUI-Klasse angelegt. [Ger04]

226

■ ■ ■

4 Mobile Multimedia

Multimedia unter Symbian OS Die älteren Symbian OS Versionen (6.0 und 7.0) verwenden einen Medienserver für die Erstellung von Multimedia-Anwendungen, was aber einige Nachteile bei hohen Anforderungen wie z. B. Videostreaming mit sich bringt. Der Medienserver arbeitet in einem einzigen Thread mit mehreren (nicht präemptiv verwalteten) Active Objects, die in dem Serverprozess laufen. Mit Symbian OS v7.0s wurde das so genannte Multimedia-Framework (MMF) eingeführt. So können die verschiedenen Codecs vom Gerätehersteller sowie von Anwendungsentwicklern auch als Plugins eingebunden werden. Der größte Unterschied zwischen Medienserver und dem MMF ist die Verwendung von Multithreading. Das MMF startet im Kontext des Client-Prozesses je einen Server- und Client-Thread für jedes Plugin. So laufen alle MMF-Threads im selben Prozess, was das aufwändige Kontext-Switching zwischen unterschiedlichen Prozessen vermeidet. Außerdem kann nun Interthread-Kommunikation anstelle Interprozess-Kommunikation genutzt werden. Abbildung 4.15 zeigt die Funktionsweise des MMF. Die clientseitigen APIs (links oben) stellen den Anwendungen den Zugang zu den Plugins zur Verfügung. Das Controller Framework startet das passende Plugin und ist für die Kommunikation zwischen Anwendung und Plugin zuständig. „ECom“ ist hierbei das Symbian-eigene generische ClientServer-Framework, über das Plugins instantiiert, verwaltet und zerstört werden können und entspricht der COM-Architektur unter Windows OS. Die darunter liegenden eigentlichen Multimedia Plugins sind schließlich für die Datenverarbeitung zuständig. Das Sound Device, oft auch als DevSound bezeichnet, bietet Zugang zur Audio-Hardware und

Medienserver

Multimedia Framework

Abb. 4.15: Das Multimedia Framework unter Symbian OS v7s


■ ■ ■

227

Abb. 4.16: Multimedia-Komponenten unter Symbian OS

wählt und lädt z. B. hardwarebeschleunigte Codecs, wobei die ZugriffsPriorität in der Ebene „Audio Policy“ geregelt wird. Das Sound Device kann anstatt über das MMF auch direkt von Anwendungen angesprochen werden, was z. B. bei Handy-Spielen eingesetzt wird. Werden gleichzeitig mehrere Anfragen gestellt, so regelt die Audio Policy den Zugriff und entscheidet, welche Anwendung auf die Hardware zugreifen darf oder ob zwei Töne gemischt werden können. Eine AudioWiedergabe muss beispielsweise durch einen Klingelton präemptiv unterbrochen werden, wenn ein Anruf registriert wird. Die Hardware Device API schließlich dient als low-level-Schnittstelle zur AudioHardware und abstrahiert die Hardware-Komponenten des Gerätes. Dies sind z. B. Lautsprecher, Mikrofon oder weitere Prozessoren wie DSPs (Digital Signal Processor) zur hardware-unterstützten Codierung/Decodierung. [Nok06b] Abbildung 4.16 gibt eine Übersicht über die weiteren MultimediaKomponenten unter Symbian OS v9.0. Die Umwandlung von Standard-Bild-Formaten in die symbianspezifischen Formate und zurück ist in einer separaten Komponente gekapselt, der ICL (Image Conversion Library). Windows Server oder GDI (Graphics Device Interface) für das 2D-Rendering finden sich in weiteren Komponenten wieder. Neu in Version 9 sind auch einige zusätzliche 3D APIs wie z. B. Unterstützung von OpenGL ES (Open Graphics Library for Embedded Systems, s. u.). [Sym06] 4.3.2.3 Windows CE/Windows Mobile Die Marktdominanz, die Microsoft im Bereich der Desktop-PCs erreicht hat, hat der Software-Riese im Bereich mobile Endgeräte bei weitem nicht. Die anfänglich von Microsoft für diesen Markt entwickelten Betriebssystem-Versionen waren oft langsam und instabil. Microsoft hatte kein von Grund auf neues Betriebsystem entwickelt, das wie z. B. Symbian OS ausschließlich auf diesen spezialisierten Bereich abgestimmt war, sondern bediente sich der desktopbasierten Windows-Familie. Daher rühren wohl auch einige Stabilitäts- und Performance-Probleme, da auf mobilen Endgeräten naturgemäß weniger Speicher und Prozessorleistung zur Verfügung stehen als bei

228

■ ■ ■

4 Mobile Multimedia

Desktop-Systemen. Auch Echtzeitanforderungen sind schwieriger zu realisieren. Die neuen Windows CE-Versionen hingegen wurden laut eigenen Aussagen komplett neu entwickelt und erfüllen die Anforderungen 95% aller Echtzeitanwendungen [Hal05]. Zwischen 1996 und 2004 entstanden viele unterschiedliche Versionen von Windows-Plattformen für mobile Endgeräte, deren Namensgebung einige Verwirrung verursachte (s. Abb. 4.17). Nun hat sich Microsoft vorerst auf die Dachmarke Windows Mobile festgelegt. Alle Windows Mobile-Geräte basieren auf einer Version des Betriebssystems Windows CE. Windows CE wird im Gegensatz zu vielen anderen WindowsBetriebssystemen nicht direkt an den Endkunden verkauft. Microsoft stellt lediglich einen gewissen Satz an Funktionalitäten zur Verfügung und die Hersteller passen das System dann an ihr spezifisches Gerät an. Hierfür können sie den von Microsoft bereitgestellten Platform Builder verwenden, mit dem die gerätespezifischen Eigenschaften eingebunden werden [Bol06]. Mit der Version Windows Mobile 5, basierend auf Windows CE 5.0.1, unternimmt Microsoft den erneuten Versuch, den boomenden Markt der PDAs und Mobiltelefone für sich zu erobern. Zum einen erhofft sich Microsoft einen positiven Effekt seiner allseits bekannten Marke und Bedienphilosophie, zum anderen bedient sich der Konzern Konzepte der Konkurrenz oder bildet Allianzen. So greift Microsoft mit seiner neuen Direct-Push-Technologie nun auch einen Markt an, der bisher BlackBerry (s.u.) vorbehalten war. Dank der neuen Messaging-Architektur können nun Nachrichten direkt auf das mobile Endgerät geschickt werden. Um von dem KnowHow der im PDA-Bereich immer noch stark vertretenen Firma Palm zu profitieren, bildet Microsoft nun auch eine strategische Allianz mit Palm. Palm im Gegenzug lizenziert das Betriebssystem Windows Mobile 5 für eine Reihe seiner Treo-Geräte [Mic05]. Windows Mobile 5 wird zum einen für Pocket PCs, zum anderen für Smartphones angeboten. Die beiden Varianten unterscheiden sich von der generalisierteren Windows CE-Plattform z. B. in der Art des Anwendungs-Lebenszyklus. So laufen Anwendungen auf diesen zwei Plattformen z. B. immer im Hintergrund weiter, so dass der Anwender schnell zwischen den Anwendungen wechseln kann, es gibt keinen Close-Button.


Abb. 4.17: Windows-Familie für mobile Endgeräte

Viele unterschiedliche WindowsVersionen

Windows Mobile 5

■ ■ ■

229

Architektur Abbildung 4.18 zeigt die Architektur von Windows CE 5.0. Windows CE ist ein 32-Bit multitaskingfähiges Betriebssystem. Der Kernel von unterstützt bis zu 32 Prozesse, die Thread-Synchronisation ist gleich wie bei den anderen Windows-Versionen. [Han03] Bezüglich der Speicherverwaltung verhält sich Windows CE ähnlich wie auch Symbian OS: Das Betriebssystem und eingebaute Anwendungen werden direkt im ROM ausgeführt, zusätzlich installierte Applikationen im RAM. Eine MMU regelt das Mapping von virtuellen Speicheradressen auf physikalische. Unter Windows CE 5.0 wird ca. 1 GB des Adressraumes fest in 33 so genannte Slots eingeteilt. Diese entsprechen den 32 parallel möglichen Prozessen mit je 32 MB Speicher, wobei ein Slot für den gegenwärtig aktiven Prozess reserviert ist. 2 GB sind dem Kernel zugeteilt, der Rest ist Shared Memory. Ab Version Windows CE 6 soll der Kernel bis zu 32.000 Prozesse parallel verwalten und jedem einen virtuellen Adressraum von 2 GByte zur Verfügung zu stellen können [Hei06]. Abb. 4.18: Architektur Windows CE 5.0

Zwei IDEs von Microsoft

230

■ ■ ■

Entwicklungsumgebung Um für die unterschiedlichen Plattformen entwickeln zu können, bietet Microsoft entsprechende Entwicklungsumgebungen und SDKs an. Die SDKs stellen den Entwicklern das passende Subset der Win32 API zur Verfügung. Außerdem wurden neue Features wie Unterstützung des Touchscreen entwickelt, um den neuen Anforderungen

4 Mobile Multimedia

gerecht zu werden. Die MFC (Microsoft Foundation Classes, sehr populäre C++ Klassenbibliotheken) wurden auch modifiziert und auf Windows CE portiert, um die grafische Oberflächenprogrammierung zu vereinfachen. [Han03] Microsoft stellt zwei IDEs zur Verfügung, um Software für mobile Endgeräte zu entwickeln: x eMbedded Visual C++: unterstützt viele Prozessorarchitekturen (ARM, MIPS, Hitachi, x86) und liefert neben einem Subset der Win32 API auch ein Subset der MFC und ATL (Active Template Library, für die ActiveX-Programmierung)-Bibliotheken, sowie einige spezielle Klassen. Mit eMbedded Visual C++ kann man beispielsweise für die Smartphone 2003-Plattform entwickeln. x Microsoft Visual Studio: In den neuen Versionen kann man sowohl nativ in C/C++ als auch mit managed code-Programmiersprachen entwickeln. Microsoft integriert hierfür Application Wizards für Win32-, MFC (Microsoft Foundation Classes)- oder ATL-Projekte. Der Entwickler kann nun auch managed- und native-Projekte kombinieren. [Wil05] MS Visual Studio 2005 ist der Nachfolger von eMbedded Visual C++ und das Werkzeug der Wahl für Windows Mobile 5-Entwicklung. Hier kann auch das .NET Compact Framework eingesetzt werden (s.u.), das schon in mehreren Versionen vorliegt. Für die Erstellung von Anwendungen für Windows Mobile 5.0 Smartphone bzw. Pocket PC-Anwendungen muss nur das entsprechende SDK eingebunden werden. Wichtig erscheint im Zusammenhang mit der Entwicklung für mobile Endgeräte, dass das MS Visual Studio 2005 einen echten ARMEmulator integriert. Dieser nutzt die gleichen Instruktionen und Treiber und hat das gleiche Speicher-Layout wie ein ARM-Gerät. Entwickler nativen Codes profitieren davon, dass der Emulator die gleichen Binärdateien nutzt wie das Endgerät und somit ein Kompiliervorgang gespart werden kann.

MS Visual Studio 2005

Programmierung Abbildung 4.19 gibt einen Überblick über die beiden Möglichkeiten, wie für Windows-Betriebssystem entwickelt werden kann und stellt diese der Entwicklung mit einer Virtual Machine wie unter Java gegenüber. Für Windows CE kann grundsätzlich auf zwei Arten entwickelt werden: Zum einen unter Nutzung der low-level Schnittstelle Win32 API nativ in C/C++, zum anderen unter Nutzung des .NET Compact Framework „managed“ in C#/Visual Basic. Alle Windows Mobile 5-Geräte haben das .NET Compact Framework 1.0 mit Service Pack 2 installiert, die Version 2.0 kann teilweise nachinstalliert werden.


■ ■ ■

231

Abb. 4.19: Übersicht Frameworks

Native Programmierung mit der WIN32 API Die Programmierung ist in den Grundzügen gleich wie die Programmierung für Windows 98/NT/2000. Anwendungen mit hohen Ansprüchen an die Performance werden heute immer noch häufig in C/C++ und nicht beispielsweise in Visual Basic programmiert. ... const TCHAR* g_szAppWndClass = TEXT("HelloApp"); LRESULT OnCreate(HWND hwnd, CREATESTRUCT* lParam) { // create the menu bar ... // get message text if(0 == LoadString(g_hInst, IDS_HELLO_MESSAGE, g_szMessage, ARRAYSIZE(g_szMessage))) { // string could not be loaded - creation of windows failed return(-1); } return(0); // continue creation of the window } LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wp, LPARAM lp) { ... switch(msg) { case WM_CREATE: lResult = OnCreate(hwnd, (CREATESTRUCT*)lp); break; case WM_COMMAND: ... break; ... DoDefault: default: lResult = DefWindowProc(hwnd, msg, wp, lp); break; } return(lResult); } HRESULT ActivatePreviousInstance(const TCHAR* pszClass, const TCHAR* pszTitle, BOOL* pfActivated) { ... } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow) { ... // register main window's class ... // create main window hwndMain = CreateWindow(g_szAppWndClass, szAppTitle, ...); ... // get messages loop while(GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return msg.wParam; }

232

■ ■ ■

4 Mobile Multimedia

Abb. 4.20: Architektur .NET Compact Framework

Windows CE ist stark eventbasiert aufgebaut: Es erhält Nachrichten, interpretiert diese und bearbeitet sie. Die Funktion WinMain() ist der Einstiegspunkt der Anwendung. In der Regel erzeugt diese Funktion zunächst ein Window. In der WinMain()-Funktion wird dann in einer Schleife die Message Queue abgefragt und über das System an die Callback-Funktion WndProc weitergeleitet, in der die Nachricht dann bearbeitet wird oder zur Standard Window-Bearbeitung an das System zurückgegeben wird (mit DefWindowProc). .NET Compact Framework Das .NET Compact Framework ist eine hardwareunabhängige Laufzeitumgebung für Anwendungen für mobile Endgeräte. Es stellt ein Subset der .NET Framework Klassenbibliothek dar mit einigen zusätzlichen Klassen, die hier exklusiv enthalten sind. Für das .NET Compact Framework kann in Visual C# .NET oder Visual Basic .NET programmiert werden. Es besteht grundsätzlich aus zwei Komponenten: der Common Language Runtime (CLR) und der .NET Compact Framework Klassenbibliothek. Die CLR wurde von Grund auf speziell für das Compact Framework aufgebaut und stellt eine Laufzeitumgebung für managed code zur Verfügung. Sie ist zuständig für Kerndienste wie z. B. Speicherverwaltung, Thread-Verwaltung, Sicherheit, Code-Verifizierung und –Kompilierung, sowie für weitere Systemdienste. Zur Code-Kompilierung nutzt sie Just-In-Time-(JIT)-Kompilierung, so dass der managed code in der nativen Maschinensprache des jeweiligen Endgeräts laufen kann. Die .NET Compact Framework Klassenbibliothek ist eine Sammlung wieder verwendbarer Klassen, die eng mit der CLR zusammenarbeiten. Wenn das Compact Framework auch die komplette Architektur des .NET Frameworks mit CLR und Ausführung von managed code übernommen hat, mussten dennoch einige Einschränkungen eingeführt werden gegenüber der wesentlich mehr Ressourcen beanspruchenden Desktop-Variante. So wurden fast alle überladenen Methoden entfernt, um die Größe des .NET Compact Frameworks zu minimieren. Außerdem wurden Funktionalitäten weggestrichen, die im mobilen


Subset des .NET Frameworks

Common Language Runtime

Einschränkungen

■ ■ ■

233

Versionen

Vorteile

Ablauf

Bereich eher unwichtig sind (z. B. Drucker-Unterstützung). Auch bezüglich XML-Verwendung wurden einige Funktionalitäten eingeschränkt, so ist die XML-Komponente XSLT nicht im Compact Framework enthalten. Auch das .NET Compact Framework liegt mittlerweile in mehreren Versionen vor. Version 2.0 bzw. die Service Packs für Version 1.0 führten einige Verbesserungen ein, vor allem im Bereich Performanz und Ressourcenverwaltung. Auch die Einbindung nativer Bibliotheken und von COM (Component Object Model)-Objekten wurde vereinfacht. Im Bereich User Interface wurden einige Funktionen eingeführt, die den Umgang mit rotierbaren Oberflächen und Keyboard-Einbindung vereinfachen, im Bereich Datenverarbeitung wurden Klassen zur Arbeit mit XML Schema eingeführt. Die Kommunikations-Klassen beinhalten nun ein high-level Interface für den Zugriff auf den seriellen Port, sowie IPv6-Unterstützung. Auch im Bereich Sicherheit/Kryptographie und Thread-Programmierung wurden einige Verbesserungen eingeführt. [Msd06]

Programmierung mit managed code Managed code wird von einer hardwareunabhängigen Laufzeitumgebung auf den unterschiedlichen Geräten mit eingeschränkten Ressourcen ausgeführt: Pocket PCs, Mobiltelefone, Set-Top-Boxen, … Der Vorteil von managed code liegt darin, dass dieser von der Laufzeitumgebung verifiziert wird. So werden bei managed code beispielsweise Probleme mit Zeigern minimiert, außerdem wird eine starke Typensicherheit unterstützt und es entstehen keine Speicherlöcher. Managed code wird zunächst in eine Kombination von MSIL (Microsoft Intermediate Language) und Metadaten kompiliert. Diese wird dann in einer ausführbaren so genannten Pre Execution Environment-Datei zusammengefasst, die dann auf Geräten laufen kann, die das .NET Compact Framework installiert haben. Wird diese Datei gestartet, wird die Intermediate Language mit JIT-Compilation in nativen Code kompiliert. Dies geschieht mit Hilfe zweier DLLs: mscoree.dll (nativer code, der managed code lädt) und mscorlib.dll (managed code: base class library, die Laufzeit-Bibliothek). Als Ergebnis dieser verschiedenen Vorgänge werden alle .NET Framework Komponenten als nativer code ausgeführt. Codebeispiel in C# Datei: Form1.Designer.cs namespace CSharpPocketPCApplication { partial class Form1 { …

234

■ ■ ■

4 Mobile Multimedia

private System.ComponentModel.IContainer components = null; private System.Windows.Forms.MainMenu mainMenu1; … …

#region Windows Form Designer generated code private void InitializeComponent() { this.mainMenu1 = new System.Windows.Forms.MainMenu(); this.menuItem1 = new System.Windows.Forms.MenuItem(); this.SuspendLayout(); this.mainMenu1.MenuItems.Add(this.menuItem1);

this.menuItem1.Text = "Exit"; this.menuItem1.Click += new System.EventHandler (this.menuItem1_Click); // // Form1 // this.AutoScaleDimensions = new System.Drawing.SizeF(96F, 96F); this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Dpi; this.AutoScroll = true; this.ClientSize = new System.Drawing.Size(240, 268); this.Menu = this.mainMenu1; this.Name = "Form1"; this.Text = "Form1"; this.MouseUp += new System.Windows.Forms.MouseEventHandler(this.Form1_MouseUp); this.MouseMove += new System.Windows.Forms.MouseEventHandler(this.Form1_MouseMove); this.MouseDown += new System.Windows.Forms.MouseEventHandler(this.Form1_MouseDown); this.Load += new System.EventHandler(this.Form1_Load); this.ResumeLayout(false); } #endregion

}

}

private System.Windows.Forms.MenuItem menuItem1;

Datei: Form1.cs: using using using using using using using

System; System.Collections.Generic; System.ComponentModel; System.Data; System.Drawing; System.Text; System.Windows.Forms;

namespace CSharpPocketPCApplication { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e)


■ ■ ■

235

{ }

// variable initialisation when form is loaded

private void menuItem1_Click(object sender, EventArgs e) { // Exit-Button this.Close(); } private void Form1_MouseDown(object sender, MouseEventArgs e) { // things to do in case of mouse down event } private void Form1_MouseMove(object sender, MouseEventArgs e) { // things to do in case of mouse move event } private void Form1_MouseUp(object sender, MouseEventArgs e) { things to do in case of mouse up event } }

}

Bei der Entwicklung von C#-Programmen im Microsoft Visual Studio kann sehr grafisch gearbeitet werden. Das obige Codebeispiel zeigt den z. T. generierten Code eines einfachen C#-Programmes für Pocket PC 5.0. In der InitializeComponent()- Methode werden von der Entwicklungsumgebung automatisch Menüpunkte etc. initialisiert und der Event-Handler eingerichtet. In der Form1-Klasse werden dann die einzelnen Events abgehandelt wie z. B. beim Laden der Form oder Mouse-Events. Multimediaunterstützung für Endanwender und Softwareentwickler

Direct3D Mobile Direct3D Mobile ist eine API zur Unterstützung hardwarebeschleunigter 3D-Grafik-Anwendungen auf mobilen Endgeräten. Sie kann

3D-Grafik auf mobilen Endgeräten

236

Multimedia und Windows CE/Windows Mobile Microsoft war von Anfang an bestrebt, gute Multimediaunterstützung zu bieten. Dies wurde gegenüber dem Endanwender z. B. mit Hilfe des Windows Media Players 10 realisiert, der seit der Version Windows Mobile 5 standardmäßig integriert ist und zahlreiche Codecs abspielen kann. Dem Softwareentwickler bietet Windows CE einige z. T. aus dem Windows-Desktop-Bereich bekannte APIs, um ihm ansprechende Multimediaprogrammierung zu ermöglichen. Neben einer DVD Video API für DVD-Wiedergabe oder der Waveform Audio API mit Audio Compression Manager scheinen vor allem die Grafik APIs interessant, die an die Anforderungen von Embedded-Systemen angepasst wurden [Msd06b]:

■ ■ ■

4 Mobile Multimedia

eingesetzt werden, um Spiele, Navigationssysteme, CAD-Anwendungen oder aber auch ansprechende GUIs zu entwickeln. Die API basiert hauptsächlich auf der Desktop-Variante Direct3D 8, integriert aber auch einige Elemente der 9er Version. Um den Footprint klein zu halten, wurden alle 3D-Funktionalitäten weg gelassen, die auf der limitierten Hardware der mobilen Endgeräte ohnehin nicht zur Verfügung stehen. Mit Hilfe der Schnittstellen der Direct3D-Bibliothek definiert der Softwareentwickler 2D- und 3D-Primitive wie Punkte, Linien, Dreiecke der Ansammlungen von Dreiecken. Dann wird festgelegt, wie diese Primitive gezeichnet werden sollen, sie werden in einen Bildpuffer geschrieben und schließlich dem Anwender dargestellt. In einer Anwendung werden typischer Weise geometrische Beschreibungen (Modelle) der darzustellenden Grafik eingesetzt. Diese Modelle werden dann positioniert, skaliert und rotiert, um eine 3D-Umgebung zu simulieren. Um den 3D-Eindruck zu verstärken, können Texturen und Beleuchtungseffekte eingesetzt werden. Die Ausgabe wird anhand der Rendering Pipeline berechnet und dann Bild für Bild dargestellt. Direct3D Mobile ist implementiert in der D3dm.dll. Verwendet eine Anwendung die darin enthaltene Datei D3dm.lib, so wird die DLL bei Prozesserzeugung automatisch in den Kontext der Anwendung geladen. Eine Anwendung benachrichtigt die Direct3D Mobile Middleware durch Aufruf der Methode IDirect3DMobileDevice::BeginScene, dass sie bereit ist, eine Szene zu erstellen. Während die Anwendung diese Szene definiert, schreibt Direct3D Mobile die Zeichenbefehle in einen Befehlspuffer. Mit Aufruf von IDirect3DMobileDevice::EndScene wird die Szene in die Rendering-Warteschlange gestellt. Erst bei explizitem Aufruf der Methode IDirect3DMobileDevice::PresentScene wird die Verarbeitung des Puffers durch den Treiber ausgelöst und die Szene auf dem Display dargestellt.

DirectShow DirectShow ist, wie Direct3D Mobile, ein Implementierungsderivat der Desktop API für mobile Geräte und ermöglicht als Middleware die Aufnahme und Wiedergabe von Medien. Da immer mehr mobile Geräte Kameras integriert haben, wurde in DirectShow auch eine Camera API eingeführt, mit der Kamera-Hardware angesprochen werden kann. Mit dieser API kann der Entwickler nun Bilder und Videos in seine Anwendung integrieren, programmierbar in nativer und managed-Programmiersprache. DirectShow verwendet seriell geschaltete Filter, um MultimediaDaten zu verwalten und in verschiedene Ausgabetypen zu übersetzen. Die API selbst stellt keine Mediencodecs zur Verfügung, diese sind je nach Design des Betriebssystems auf dem einzelnen Endgerät verfügbar. Die Codecs können dann per DirectShow in verschiedenen


Aufnahme und Wiedergabe von Medien

■ ■ ■

237

Formaten wiedergegeben werden: ASF (Advanced Streaming Format), MPEG (Motion Picture Experts Group), AVI (Audio-Video Interleaved), MP3 (MPEG Audio Layer-3), WAV (Waveform Audio) oder WMA/WMV (Windows Media Audio und -Video). DirectShow erkennt Hardware zur Video- und Audiobeschleunigung, unterstützt aber auch Systeme ohne diese Beschleunigungshardware. 2D-Grafik

DirectDraw DirectDraw unterstützt den Entwickler durch beschleunigtes 2D-Rendering und ermöglicht volle Kontrolle über z. B. schnelle Videowiedergabe. DirectDraw ist eine spezielle Implementierung der DirectDraw API für Desktop-Rechner und ersetzt die Game API (GAPI). Auch hier wurde, ausgehend von der Desktop-Version DirectDraw 4, die Version für den Einsatz im Embedded-Systeme-Bereich um einige Fähigkeiten erweitert, andere Funktionen wurden speziell auf diesen Bereich zugeschnitten. So kann sie im Unterschied zur desktopbasierten Variante z. B. den Displaymodus nicht ändern, kann also nur in dem Modus arbeiten, der von dem Windows CE-Gerät gesetzt ist. Bei Geräten mit mehreren Bildschirmen kann DirectDraw nur mit dem primären Anzeigegerät arbeiten, die anderen werden von der GDISchnittstelle kontrolliert. DirectDraw und Bildschirmrotation schließen sich ebenfalls gegenseitig aus. Mit DirectDraw ermöglicht Microsoft eine weitaus effizientere und schnellere Grafikprogrammierung für grafikintensive Anwendungen als dies mit GDI möglich wäre. Während der Laufzeit kann die Leistung an die Hardwarefähigkeiten des Gerätes angepasst werden. DirectDraw nutzt mögliche Hardwarebeschleunigung und setzt Software-Simulation ein, wenn diese nicht gegeben ist. DirectDraw kann sowohl System- wie auch der Grafikspeicher allokieren und manipulieren. Es ist eine low-level API und wird intern z. B. auch von Direct3D Mobile für die Verwaltung von Surface und Texture Maps eingesetzt. 4.3.2.4 BREW BREW (Binary Runtime Environment for Wireless) ist ein hardwareorientierter Ansatz für die Entwicklung mobiler Anwendungen. Die BREW Solution, entwickelt von der Firma Qualcomm, besteht im Wesentlichen aus zwei Komponenten. Zum einen, auf Anbieterseite, das Brew Delivery System: Hier werden die Anwendungen getestet, zentral verwaltet, verteilt und schließlich mit Kunden und Entwicklern abgerechnet. Hierauf soll im Folgenden nicht näher eingegangen werden.

238

■ ■ ■

4 Mobile Multimedia

Zum anderen die BREW Client-Software. Diese kann als ein Satz APIs angesehen werden, mit dem Software für BREW-Geräte entwickelt werden kann. Die Software unterstützt GSM/GPRS, UMTS und CDMA. BREW ist fest in die Endgeräte eingebaut. Für den Anwendungsentwickler bedeutet dies zum einen, dass er sehr hardwarenah programmieren muss, zum anderen müssen erstellte Anwendungen von Qualcomm signiert werden. Die Preisfestsetzung ist für den Entwickler ebenfalls nicht frei und geschieht Zusammenarbeit mit Qualcomm. [Qua06] Architektur BREW bringt, zusätzlich zu den Client APIs, einen Application Manager mit, über den der Nutzer BREW-Anwendungen auf das Gerät nachladen kann. Der Gerätehersteller erhält diesen Application Manager mit Source Code geliefert, um ihn an seine Geräte anpassen zu können. Da BREW sehr wenig Speicher auf dem Endgerät benötigt, läuft das System auf fast allen Geräten. Diese Reduktion hat jedoch auch einige Einschränkungen zur Folge. Z. B. können (wie in J2ME und CLDC, s.u.) keine Fließkommazahlen verwendet werden. Diese funktionieren zwar auf dem Emulator, da dieser in der WindowsUmgebung abläuft, nicht aber auf dem Endgerät. Für den Entwickler bringt die Erstellung von BREW-Applikationen zusätzliche Schritte im Vergleich zu anderen Plattformen mit sich. Um Anwendungen digital signieren zu können, benötigt man zunächst ein Verisign-Zertifikat der Klasse 3, mit dem man sich dann als BREWEntwickler registrieren lassen kann. Jede BREW-Anwendung erhält eine eindeutige Class-ID von Qualcomm. Unit-Tests können zwar mit einem BREW-Gerät durchgeführt werden, danach muss die Software jedoch nochmals zu einem Test-Labor von Qualcomm geschickt werden, welches diese prüft und freigibt. Die Auslieferung der Anwendung erfolgt dann über den virtuellen BREW-Market-Place, in Zusammenarbeit mit Qualcomm und den Telekommunikationspartnern. Sie wird dem Endkunden OTA

Application Manager

Erstellung und Vertrieb von BREWAnwendungen

Abb. 4.21: BREW-Architektur [Qua06b]


■ ■ ■

239

(Over-The-Air) zur Verfügung gestellt und die Abrechnung erfolgt automatisch über das BREW Billing System. Für den Kunden besteht der Vorteil dieses Systems darin, dass die Software von einer zentralen Instanz knontrolliert wird und er so nur geprüfte Anwendungen ausgeliefert bekommt. [Qua06]

BREW-SDK

Abb. 22: BREW Entwicklungsumgebung

Entwicklungsumgebung Software für BREW-Geräte kann mit dem frei verfügbaren BREWSDK entwickelt werden. Bei Installation des BREW-SDK integrieren sich ein Application Wizard, eine Werkzeugleiste und ein BREWCompiler in das MS Visual Studio, so dass erste BREW-Anwendungen recht einfach und schnell erstellt werden können. Unter BREW ist, in Verbindung mit dem IDebugger, auch On-target debugging möglich. Das SDK setzt sich aus einer Vielzahl an Werkzeugen zusammen.

Jedes BREW-Anwendungsmodul muss eine MIF-Datei enthalten, die mit dem MIF-Editor erstellt werden kann. Ein recht mächtiges Tool ist der BREW Simulator in Verbindung mit dem GeräteKonfigurator. Der Emulator kann entsprechend dem Endgerät frei konfiguriert werden und so neben Tastatureinstellungen z. B. auch die Güte der Netzwerkverbindung geändert werden. Ressourcen in BREW umfassen Bilder, Texte (mehrsprachig), Dialoge und Look-and-Feel Komponenten. Um diese verändern zu können, wird ein RessourcenEditor mitgeliefert. Daneben existieren weitere Werkzeuge, mit denen Bilder und Ton in BREW-spezifische Formate und wieder zurück gewandelt werden können, sowie der nötige „Application Signer“, mit dem die Anwendung authentifiziert und signiert werden kann.

240

■ ■ ■

4 Mobile Multimedia

Die fertige BREW-Anwendung ist ein Paket aus der MIF-Datei, Ressourcen-Dateien mit der Endung .bar, der Signatur und dem eigentlichen Modul. Programmierung BREW-Anwendungen können in C/C++ oder in Java entwickelt werden, basierend auf einer MIDP 2.0 KVM (Kilo Virtual Machine, s.u.). Die Entwicklung von Anwendungen auf Basis von J2ME mit dem MIDP 2.0-Profil wird später beschrieben. Vorteile der C/C++-Programmierung sind die Geschwindigkeit und der hardwarenahe Zugriff auf Basisfunktionalitäten, daher soll hier kurz darauf eingegangen werden. Jedes BREW-Anwendungsmodul wird als eigene ausführbare DLL entwickelt. Ein Modul kann mehrere Applets enthalten und muss eine korrespondierende MIF-Datei haben. Die MIF-Datei enthält neben Icon und Titel der Anwendung auch Informationen über den Inhalt, über extern freigegebene Klassen, Applet-Privilegien, etc. [Qua06]. Den einzelnen Anwendungen können dabei Prioritäten zugewiesen werden.

BREW-Anwendungen in C/C++ oder Java

int AEEClsCreateInstance(AEECLSID ClsId, IShell * pIShell, IModule * pMod, void ** ppObj) { *ppObj = NULL; if(AEEApplet_New( sizeof(AEEApplet), ..., (AEEHANDLER)HelloWorld_HandleEvent, ... )) return(AEE_SUCCESS); return (EFAILED); } static boolean HelloWorld_HandleEvent(AEEApplet * pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam) { AECHAR szText[] = {'H','e','l','l','o',' ','W','o', 'r', 'l', 'd', '\0'}; switch (eCode){ case EVT_APP_START: IDISPLAY_DrawText(pMe->m_pIDisplay, ..., szText, ...); IDISPLAY_Update (pMe->m_pIDisplay); return(TRUE); case EVT_APP_STOP: return(TRUE); default: break; } return(FALSE);

}

Die Programmierung unter BREW ist stark eventbasiert. [Bfa05] Einstiegspunkt in die Anwendung ist die Funktion AEEClsCreateInstance (AEE steht für Application Execution Environment). Innerhalb dieser Funktion wird dann mit AEEApplet_New ein neues Applet erzeugt. Events werden in einer Klasse namens AEEHANDLER über einen Callback-Mechanismus abgehandelt. Multimedia unter BREW Die Multimedia-Unterstützung unter BREW ist abhängig vom Endgerät. Über die BREW API werden mp3, real-time Streaming PCM und


■ ■ ■

241

QCP-Formate (PureVoice), G.711, sowie Videodarstellung (MPEG4) unterstützt. Eingebaute Kameras können angesprochen werden und auch Video-Aufnahme im MPEG4-Format sind möglich [Qua06].

Versionen

4.3.2.5 Palm OS Das Betriebssystem Palm OS wurde von der gleichnamigen Firma entwickelt. Die ausgelagerte Firma PalmSource übernahm die Weiterentwicklung des Betriebssystems und wurde im Herbst 2005 von dem japanischen Unternehmen Access aufgekauft. Palm strebt nun an, ein eigenes PDA-Betriebssystem für ihre Treo-Smartphones auf LinuxBasis zu entwickeln [Lüd06]. Außerdem bildet Palm Allianzen mit Microsoft [Mic05] und lizenziert auch das Betriebssystem Windows 5 für eine Reihe seiner Treo-Geräte. Dies ist wohl auch eine Reaktion auf den großen Erfolg von BlackBerry aus Kanada, das mit seiner Push-Technologie bisher einzigartig war, nun jedoch von Microsoft angegriffen wird. Das Palm-eigene Betriebssystem wird daher wohl in absehbarer Zukunft nicht mehr weiterentwickelt werden. Dennoch sind Palm-Geräte noch sehr verbreitet, daher soll auf das Betriebssystem im Folgenden näher eingegangen werden. Frühere Palm OS-Versionen (v1–v4) liefen auf der Motorola 68000er Prozessorfamilie, weshalb die Anwendungen auch als 68K-Anwendungen bezeichnet werden. Die beiden neuen Betriebssystemversionen Palm OS Garnet (Palm OS v5.4) und Cobalt (Palm OS v6.x) wurden für Handheld-Geräte mit ARM-Prozessoren entwickelt. Palm OS Garnet vereint Programmiercode der Palm OS Versionen 5.2 und 5.3 und bietet darüber hinaus einige Verbesserungen, wie z. B. einen neuen Bluetooth Connection Manager. Palm OS Cobalt hingegen ist komplett neu geschrieben, hat folglich auch eine neue Betriebssystem-Architektur. Sowohl Garnet als auch Cobalt sind abwärtskombatibel zu 68K-Anwendungen. Dies wird durch die so genannte PACE (Portable Applications Compatibility Environment)-Umgebung realisiert. PACE emuliert die 68K-Prozessor-Familie, so dass auch die älteren Anwendungen auf den neueren ARM-Geräten funktionieren [Pal06]. Architektur Palm OS Cobalt ist in verschiedenen Schichten aufgebaut und legt im Vergleich zu den Vorgänger-Versionen mehr Wert auf Kommunikations- und Multimedia-Komponenten. Der Mikrokernel (s. Abb. 4.23) ist multithreading- und multitaskingfähig. Das neue Kommunikations-Framework enthält einen Connection Manager und Bluetooth Manager. Sowohl Lizenznehmer als auch Entwickler haben unter Palm OS Cobalt einfachen Zugriff auf Konfiguration und Administration der Kommunikationsdienste.

242

■ ■ ■

4 Mobile Multimedia

Abb. 4.23: Architektur Palm OS Cobalt

Palm OS Cobalt kann bis zu jeweils 256 MB RAM bzw. ROM verwalten. Der RAM-Speicher unter Palm OS wird in zwei logische Bereiche aufgeteilt: Dynamische Heaps und Storage Heaps. Dynamischer Heap wird vom Memory Manager verwaltet, Storage Heap und ROM vom Database Manager. Jeder Prozess unter Palm OS hat einen eigenen dynamischen Heap, der ihm als Arbeitsspeicher für temporäre Speicherallokationen dient. RAM, der nicht als dynamischer Heap reserviert ist, wird als Storage Heap für nichtvolatile Daten genutzt und entspricht somit der Festplatte bei Desktop-Systemen. Typischerweise arbeitet man mit Storage Heaps, indem man Datensätze verändert. Daten im internen Speicher von Palm OS-Geräten werden nicht wie bei traditionellen Dateisystemen abgelegt, sondern in so genannten „Records“, die wiederum in „Databases“ gruppiert werden. Eine „Database“ entspricht im klassischen Sinne einer Datei. Um Speicherplatz zu sparen, werden diese Datenbanken auch direkt an ihrem Speicherort verändert, ohne sie vorher ins RAM laden zu müssen. Der Data Manager stellt eine Abstraktionsebene dar, über die Entwickler auf Daten zugreifen können. Somit wirken sich zukünftige Änderungen des Datenbankformats nicht auf die Funktionalität der Anwendungen aus. Der Data Manager ermöglicht außerdem die Erzeugung sicherer, zugangsgeschützter Datenbanken. Auf den Data Manager setzt eine Filestreaming API auf, die aber nur von Anwendungen genutzt wird, die große Datenmengen bearbeiten müssen. Der Virtual File System Manager wurde eingeführt, um externe Speichermedien zu unterstützen und stellt eine konsistente Schnittstelle zu den unterschiedlichen Medien zur Verfügung. Palm OS kennt im Unterschied zu anderen Betriebssystemen standardmäßig nur drei Dateiformate: PDB-Dateien (Palm Database),


Dynamische Heaps und Storage Heaps

Data Manager

Dateiformate

■ ■ ■

243

PRC-Dateien (Palm Resource) und PQA-Dateien (Palm Query Application). Über Zusatzsoftware können weitere Dateien lesbar gemacht werden (z. B. pdf-Dateien etc.). PDB-Dateien werden üblicherweise genutzt, um Daten einer Anwendung zu speichern. PRC-Dateien sind von der Struktur her identisch zu PDB-Dateien, enthalten jedoch andere Arten von Daten (Ressourcen statt Records). Palm OS Anwendungen beispielsweise sind PDB-Dateien. Sie enthalten Code-Ressourcen ebenso wie Nutzerinterface-Ressourcen-Elemente. Die genaue Definition eines Records oder einer Ressource obliegt der jeweiligen Anwendung. Auch Dateiname und -endung einer Database sind nicht entscheidend, sondern lediglich die im Header gespeicherten Informationen. PQA-Dateien werden für Datentransfer mit dem PC genutzt. [Pal06], [Leh03] Entwicklungsumgebung Die Kernplattform von Palm OS umfasst mit „68K“ und „Palm OS Protein“ zwei Entwicklungsumgebungen. Je nach benötigten Funktionen und angestrebter Kompatibilität kann der Entwickler wählen, ob er 68K- oder Protein-Anwendungen programmieren möchte. Hierfür bietet Palm auf seiner Website das Palm OS Developer Kit zum freien Download an, welches auf der Oberfläche der weit verbreiteten Freeware-IDE „Eclipse“ beruht, so dass sich viele Entwickler auf Anhieb zurechtfinden. Mit dem SDK werden unterschiedliche Compiler mitgeliefert. Der GNU 68K Compiler „m68K-palmos-gcc.exe“ wird für die Erstellung von 68K-Applikationen eingesetzt, der GNU x86 Compiler „i686-pc-cygwin-gcc-3.3.1.exe“ für den Simulator und der Palm OS Protein C/C++ Compiler „pacc.exe“ für Protein-Anwendungen für das Zielgerät. Programmierung Existierende Java MIDlets (s.u.) sind ohne Anpassung (abgesehen von anderer Packetierung) auf Palm-Geräten lauffähig, Palm lizenziert hierfür IBM's WebSphere Micro Environment für seine Geräte. Die meisten Palm OS-Programme sind jedoch in C geschrieben, daher soll hier kurz hierauf eingegangen werden. Der Einstiegspunkt für Palm OS Anwendungen ist die Funktion PilotMain(), ähnlich der main()-Funktion in Java. Diese PilotMain()-Funktion reagiert auf den so genannten „LaunchCode“, mit dem die Anwendung gestartet wird. Je nach Launch-Code wird die Anwendung mit grafischer Benutzeroberfläche oder auf andere Weise gestartet. Soll z. B. in einer globalen Suche nach einem Namen in allen existierenden Datenbanken gesucht werden, genügt es dem Betriebssystem, die Anwendung im Hintergrund zu starten, um Ressourcen zu sparen.

244

■ ■ ■

4 Mobile Multimedia

... uint32_t PilotMain(uint16_t cmd, MemPtr cmdPBP, uint16_t launchFlags){ if(sysAppLaunchCmdNormalLaunch == cmd) { FrmGotoForm(gAppDB, MainForm); doEventLoop(); } return errNone; } static void doEventLoop(void) { status_t error; EventType event; do { // while events EvtGetEvent(&event, evtWaitForever); if(SysHandleEvent(&event)) continue; if(MenuHandleEvent(0, &event, &error)) continue; if(AppHandleEvent(&event)) continue; FrmDispatchEvent(&event); } while(event.eType != appStopEvent); } static Boolean AppHandleEvent(EventType* pEvent) { uint16_t formId; FormType *pForm; if (pEvent->eType == frmLoadEvent) { // Load the form resource and init ... switch (formId) { case MainForm: FrmSetEventHandler(pForm, MainFormHandleEvent); break; default: ErrFatalDisplay("Invalid Form Load Event"); break; } return true; } return false; } static Boolean MainFormHandleEvent(EventPtr event) { ... if(event->eType == frmOpenEvent) { //init window ... fHandled=true; } if(event->eType == ctlSelectEvent) { //set new form title ... FrmSetTitle(pForm, text); } return fHandled; }

Palm OS Anwendungen sind stark eventbasiert. Die Events werden mit einer Loop-Funktion abgefragt, die solange aktiv ist wie auch das Programm. Je nach Event-Typ (System-/Menu-/Application-Event) wird das Ereignis dann an unterschiedlichen Stellen weiterverarbeitet. Palm-Anwendungen werden automatisch beendet, wenn der Benutzer zu einem anderen Programm wechselt. Um auch aus 68K-Anwendungen heraus ARM-nativ programmieren zu können, können ARM-Subroutinen geschrieben und aus der 68K-Anwendung heraus gerufen werden. Hierbei sind einige technische Unterschiede zwischen den Motorola-Prozessoren und der ARMFamilie zu berücksichtigen. So speichern z. B. erstere Integer-Werte im Big-Endian-Format, letztere hingegen nutzen hierfür das LittleEndian-Format. Für die Umwandlung werden spezielle Methoden angeboten. [Wil04]


■ ■ ■

245

Abb. 4.24: Multimedia-Library unter Palm OS

Multimedia In Bezug auf die Multimedia-Fähigkeiten ist Palm OS anderen Betriebssystemen ein wenig unterlegen. Dies war auch nie der Anspruch, da Palm seinen Kunden in erster Linie ermöglichen wollte, auf einfache Art und Weise Termine verwalten zu können und das Betriebssystem von Anfang an nicht primär auf Multimedia-Anwendungen auslegte. Multimedia unter Palm OS wird durch zwei APIs unterstützt. Der Sound Manager bietet zum einen die Möglichkeit, monophone (Square-)Töne zu generieren (z. B. für System-Hinweistöne), zum anderen Stereo-Sounds unterschiedlicher Formate aufzunehmen oder abzuspielen. Die interessantere Alternative für Multimedia-Anwendungen unter Palm OS bietet die so genannte Multimedia Library (s. Abb. 4.24). Sie bietet eine Standard-Schnittstelle, um auf Multimedia-Inhalte zugreifen zu können. Diese Inhalte können vom lokalen Speicher des Gerätes, von einer Netzwerk-Verbindung oder von angeschlossener Hardware wie Kamera oder Mikrofon stammen. Hierzu nutzt sie den Movie Server, der dann die notwendigen Sessions initiiert und verwaltet. Der Movie Server läuft innerhalb der System-Prozesse und stellt alle Multimedia-Funktionalität zur Verfügung. Die Sessions laufen meist im Hintergrund ab, wobei mehrere Komponenten simultan auf Sessions zugreifen können. Standardmäßig werden unter Palm OS ADPCM/PCM, MP3, MPEG1 and MPEG4 unterstützt, über die Multimedia Library können jedoch keine neuen Formate oder Codecs geschrieben oder integriert werden. [Bey04] 4.3.2.6 BlackBerry OS Research In Motion (RIM) ist eine erfolgreiche kanadische Firma, die eigene Endgeräte verwendet und mit dem Betriebssystem BlackBerry OS ausstattet. BlackBerry setzt stark auf die Synchronisation von Daten zwischen Endgerät und Server und ist auf Geschäftskunden ausgerichtet, die ständig aktuell über Termine und eMails informiert sein müssen. BlackBerrys Erfolg ist maßgeblich auf den Einsatz einer PushTechnologie zurückzuführen, die den Kunden ermöglicht, ihre Termine, Adressen etc. immer aktuell zu halten. Die Geräte selbst können mit Java-Anwendungen erweitert werden. RIM bietet ihren Dienst auf zwei sehr ähnliche Arten an: BlackBerry Built-In und BlackBerry Connect. Beide greifen verschlüsselt über das Internet auf den BlackBerry Enterprise Server zu, der dann die Daten wie Addressen etc. zur Verfügung stellt. BlackBerry bietet dies auch für Symbian OS und Windows-basierte Geräte an, auch Palm hat

246

■ ■ ■

4 Mobile Multimedia

eine Zusammenarbeit mit RIM angekündigt [Rim06]. Die Built-InGeräte haben die BlackBerry-eigenen Anwendungen für eMail, Browsing, Kalender und Adressbuch integriert und ihr Zugriff kann im Gegensatz zu den Connected-Geräten auch auf Unternehmensdaten ausgeweitet werden. Der (Geschäfts-) Kunde zahlt Lizenzgebühr an seinen Service Provider (in Deutschland z. B. Base, E-Plus, O2, Orange, T-Mobile, Vodafone, …) und muss natürlich die Geräte kaufen. RIM wiederum lässt sich die Nutzung des BlackBerry Enterprise Servers bezahlen, den die Firma zentral betreibt. Architektur BlackBerry bietet grundsätzlich zwei Ansätze, um Anwendungen für BlackBerry OS zu konzipieren. Der Thin Client-Ansatz sieht vor, mit einem speziellen CDK (Content Development Kit) Inhalte zu erstellen, auf die dann per integriertem Browser zugegriffen werden kann. Die Dateien, die mit diesem CDK erstellt werden nennen sich pmeDateien. Diese pme-Dateien können auch dazu verwendet werden, um Multimediainhalte offline im Browser anzuzeigen (Stand-alone). Der zweite Ansatz entspricht dem Thick Client-Ansatz: Der Anwendungsentwickler kann komplexe Java-Anwendungen erstellen, durch RIM signieren lassen und ausliefern. So sind Offline-Funktionalität und lokale Datenspeicherung möglich. Alle Software, die für BlackBerry-Geräte geschrieben wird, wird in Java geschrieben.


Abb. 4.25: Architektur BlackBerry System

■ ■ ■

247

Entwicklungsumgebung BlackBerry stellt mit der frei zum Download angebotenen JDE (Java Development Environment) eine komplette Umgebung für Entwicklung und Testen von Anwendungen zur Verfügung: Editor, Builder, Debugger sowie integrierte Geräte- und Netzwerksimulationswerkzeuge sind darin enthalten. Um Anwendungen für die javabasierten BlackBerry Endgeräte zu kompilieren, muss diese BlackBerry JDE grundsätzlich verwendet werden. Die Entwicklung entspricht hier der MIDP-Entwicklung mit zusätzlichen APIs von RIM. Um Speicher und Rechenleistung des BlackBerry-Gerätes zu minimieren, wird der Code, wie in der CLDC-Sezifikation (s.u.) vorgesehen, bereits auf dem Entwicklungsrechner präverifiziert. Die BlackBerry JDE führt diese Präverifizierung der Quelldateien automatisch durch, kompiliert die Anwendung und packt sie in eine so genannte .cod-Datei. Diese wird dann auf das BlackBerry-Gerät übertragen. Die BlackBerry Java-Umgebung unterstützt echtes Multithreading für laufende Anwendungen, so können Events an mehrere parallel laufende Anwendungen gebroadcastet werden und Hintergrundprozesse sind möglich.

BlackBerry-Anwendungen in Java

Programmierung Java-Anwendungen für BlackBerry-Geräte werden unter Einsatz der BlackBerry JDE geschrieben. Die Geräte unterstützen einerseits die J2ME-definierte CLDC und das MIDP, andererseits die RIM BlackBerry J2ME-Erweiterungen, die als zusätzliche APIs zur Verfügung stehen. MIDP 2.0 wird erst ab BlackBerry-Geräten der Version 4.0 mit 16 MB oder mehr an Flash-Speicher unterstützt, davor nur MIDP 1.0 [Rim05] Abb. 4.26: Übersicht Java-Umgebung unter BlackBerry

Application Manager

248

■ ■ ■

Bei Start des BlackBerry-Gerätes lädt die VM einen Application Manager, der alle Java-Anwendungen verwaltet. Er fungiert auch als zentraler Verteiler für Betriebssystem-Events. Empfängt der Application Manager einen Event, so kopiert er diesen in die entsprechenden Warteschlangen der Anwendungen. So können die Events speziellen

4 Mobile Multimedia

Programmen zugewiesen werden. Nutzer-Eingabe-Events können beispielsweise explizit an die Anwendung weitergeleitet werden, die gerade im Vordergrund ist. Die JVM auf den BlackBerry-Geräten unterstützt maximal 48 gleichzeitig laufende Prozesse. Für die Unterstützung der Mehrsprachigkeit setzt die BlackBerry JDE einen eingebauten Ressourcen-Mechanismus ein. Dieser ermöglicht es, dynamisch unterschiedliche Sprachen zu laden und die Anwendung an spezielle Regionen anzupassen, ohne den Code ändern zu müssen. So können Übersetzungsvorgänge wesentlich vereinfacht werden und dem Nutzer werden alle Texte in der von ihm eingestellten Sprache angezeigt.

Ressourcen

... public class HelloWorld extends UiApplication { public static void main(String[] args) { HelloWorld theApp = new HelloWorld(); //To make the application enter the event thread and start //processing messages, we invoke the enterEventDispatcher method theApp.enterEventDispatcher(); } public HelloWorld() { //Push the main screen instance onto the UI stack for rendering. pushScreen(new HelloWorldScreen()); } } final class HelloWorldScreen extends MainScreen implements HelloWorldResResource { private static ResourceBundle _resources = ResourceBundle.getBundle(BUNDLE_ID, BUNDLE_NAME); public HelloWorldScreen() { super(DEFAULT_MENU | DEFAULT_CLOSE); setTitle(new LabelField(_resources.getString(HELLOWORLD_TITLE), LabelField.ELLIPSIS | LabelField.USE_ALL_WIDTH)); add(new RichTextField(_resources.getString(HELLOWORLD_CONTENTSTRING))); } public boolean onClose() { Dialog.alert(_resources.getString(HELLOWORLD_EXITSTRING)); System.exit(0); return true; }

}

public boolean keyChar(char key, int status, int time) { boolean retval = false; switch (key) { case Characters.ESCAPE: onClose(); retval = true; break; } return retval; }

Anwendungen mit Benutzeroberfläche erben von der RIM-Klasse UiApplication. Diese stellt Methoden zur Verfügung, mit denen Anwendungen Event Listener registrieren, Threads und UIKomponenten verwalten können. Anwendungen ohne Benutzeroberfläche erben von der RIM-Klasse Application.


■ ■ ■

249

BlackBerry-Anwendungen starten mit der main()-Funktion. Bei Start ruft der Hauptthread die Funktion enterEventDispatcher(), um die Bearbeitung von Ereignissen zu initiieren. Der Hauptthread ist neben der Bearbeitung von Events aus der Anwendungswarteschlange auch für das Zeichnen auf das Display zuständig.

J2ME

BlackBerry APIs

Multimedia Multimedia-Unterstützung ist nicht das primäre Ziel der BlackBerryAnwendung. Dennoch bietet BlackBerry hierfür zahlreiche Möglichkeiten. Zum einen können die APIs der J2ME eingesetzt werden, bei den neueren Geräten das MIDP 2.0-Profil und die Mobile Media API JSR-135 (s.u.). So werden z. B. wave oder mp3-Dateien unterstützt. Zum anderen können Anwendungen über die APIs der BlackBerryeigenen Media Engine auf einfache Art auf Medieninhalte zugreifen und diese abspielen. Die Dateien können lokal oder vom Netzwerk geladen werden. MediaPlayer player = new MediaPlayer(); MediaManager manager = new MediaManager(); try { Object media = manager.createMedia(“http://webserver/mediaFile.pme”); player.setMedia(media); } catch (IOException ioe) { } catch (MediaException me) { System.out.println(“Error during media loading: “); System.out.println(me.getCode()); System.out.println(me.getMessage()); } add((Field)player.getUI()); try { player.start(); } catch(MediaException me) { System.out.println(“Error occured during media playback: “); System.out.println(me.getCode()); System.out.println(me.getMessage()); }

Content Development Kit

250

■ ■ ■

Medieninhalte können auch nach dem Thin Client-Ansatz über den Browser zugänglich gemacht werden. Um pme-Inhalte zu erstellen, muss das Plazmik Content Development Kit für BlackBerry verwendet werden, das ebenfalls frei zur Verfügung gestellt wird [Pla06]. Dieses enthält einen Composer, mit dem man Inhalte für den BlackBerry-Browser erstellen kann. Der Composer arbeitet, ähnlich wie Macromedia Flash auch, mit Zeitleisten und Ebenen. Neben dem Import von diversen Imageformaten können auch Macromedia Flash swf-Dateien und SVG-Dateien (Scalable Vector Graphics, s.u.) in das BlackBerry-eigene pme-Format konvertiert werden. So kann man Flashinhalte, die man bereits fürs Web erstellt hat, weiter nutzen, einiges an Fine-Tuning-Arbeit vorausgesetzt. Getestet wird der Inhalt mit dem integrierten Emulator. Die binäre Datei, eventuell gepackt mit begleitenden Ton- oder Bilddateien in einem

4 Mobile Multimedia

einzelnen pmb-file, kann dann auf BlackBerry-Geräte übertragen und über den Browser wiedergegeben werden. 4.3.2.7 Embedded Linux Das Betriebssystem Linux selbst war für ältere mobile Endgeräte aufgrund des begrenzten RAM und ROM einfach zu groß. Deshalb haben viele Hersteller eigene linuxbasierte Betriebssysteme entwickelt und dabei entweder Teile des Linux-Kernel neben einem eigenen Kernel verwendet oder aber einen komplett eigenen Kernel geschrieben, der die benötigten Schnittstellen für Linux-Applikationen bereitstellt (z. B. Lynx). Nachdem RAM und ROM für mobile Engeräte immer billiger wurde und die Geräte mit entsprechend schnellen CPUs ausgerüstet wurden, kamen die ersten Linux-PDAs und -Smartphones auf den Markt. Mittlerweile existieren mit MobiLinux, Koan, Sysgo, FSMLAbs, LynuxWorks, Wind River Systems, Green Hills Software, Qtopia OS (Trolltech) etc. zahlreiche Varianten des Linux OS für den Markt der mobilen Endgeräte. Embedded Linux gewinnt zunehmend an Bedeutung, ist jedoch im mobilen Bereich in Europa noch eher schwach vertreten. PDAs mit Embedded Linux als Betriebssystem sind beispielsweise der Sharp Zaurus oder auch einige Compaq-Geräte. Mobiltelefone mit Linux werden z. B. von Motorola, NEC, Panasonic oder Samsung gefertigt. Ein großer Vorteil von Linux gegenüber Betriebssystem wie Windows Mobile oder Palm OS sind die wegfallenden Lizenzkosten. Es ist ein sehr stabiles, modernes Betriebssystem mit geschütztem und virtuellem Speicher, Multitasking- und Multiuser-Fähigkeit und ist für die unterschiedlichsten Hardwareplattformen verfügbar (x86, ARM, Motorola/IBM Power PC, NEC MIPS). Linux wird von einer weltweiten Entwicklergemeinde ständig weiter entwickelt. Der GNU C-Compiler, der in jeder Linux-Distribution enthalten ist, läuft auf vielen unterschiedlichen Plattformen (Linux, Solaris, Windows) und ermöglicht für Embedded Linux-Distributionen typischerweise eine CrossDevelopment-Umgebung. Seit Kernel Version 2.4 können auch FlashROMs angesprochen werden, wodurch Linux zunehmend für den mobilen Bereich interessant wird. Auch das Power Management wurde mit Kernel Version 2.4 stark verbessert. [Leh03] Ein Nachteil von Embedded Linux hingegen ist die noch nicht so weit entwickelte Benutzeroberfläche. Hier muss noch viel Entwicklungsarbeit geleistet werden, um wirklich ansprechende Geräte zu fertigen. [Ret04]


Vor- und Nachteile

■ ■ ■

251

Anforderungen an das Endgerät

4.3.2.8 SavaJe SavaJe wurde von dem gleichnamigen Unternehmen aus Massachusetts entwickelt. Mehrere Netzbetreiber haben im Juni 2004 eine offene Allianz für ein standardisiertes Betriebssystem auf mobilen Endgeräten (Open Mobile Terminal Platform Alliance) gegründet und wollten damit ein Zeichen gegen den geschlossenen Markt von Symbian OS und Windows Mobile OS setzen. Zu den Initiatoren gehören Vodafone, France Telecom, Orange, Deutsche Telekom und T-Mobile, O2, Telefonica Moviles, Telecom Italia und NTT DoCoMo. Als strategische Partner haben die SavaJe-Entwickler Intel, Texas Instruments und ARM mit ins Boot geholt. Das native Java-Betriebssystem wurde bereits auf einem HP iPAQ demonstriert [Qua06]. Im Dezember 2005 kündigte SavaJe Technologies Inc. ein von dem Unternehmen Group Sense PDA Limited hergestelltes SavaJe-Mobiltelefon an, das im Mai 2006 auf der JavaOne Konferenz vorgestellt wurde. Das Gerät namens „Jasper20“ beruht auf der SavaJe OS Version 2.5 und unterstützt CDC und JSR-209. [Sav06] Aufgrund der hohen Anforderungen an das mobile Endgerät ist SavaJe für leistungsfähigere Geräte gedacht und benötigt deutlich schnellere Prozessoren und mehr RAM als die meisten anderen mobilen Betriebssysteme. SavaJe XP belegt 12 MB ROM und benötigt einen StrongARM-Prozessor (SA1100/1110) mit mindestens 190 MHz sowie 32 MB RAM. [Sav06b] Der große Footprint stellt den großen Nachteil gegenüber anderen Betriebssystemen dar. SavaJe stellt viele Anwendungen standardmäßig zur Verfügung. Messaging, Browser (HTML, WAP, XHTML), Multimedia-Anwendungen für Bild- und Videoaufnahmen, Videoplayer, Kameraunterstützung, PIM für Kontakte, Kalender, Aufgaben, Synchronisation mit PC sind bereits ebenso integriert wie ein Set von Sicherheitsfunktionen wie Zertifikate und Verschlüsselung. Die grafische Oberfläche kann von den Geräteherstellern für ihre Geräte angepasst werden. Die Vorteile von SavaJe sind die Anpassungsfähigkeit der „user experience“, sowie Java SE als Programmiersprache, was einen großen Pool an Entwicklern anspricht. LG hat sich als erster der großen Mobiltelefonherstellern zu einer Allianz mit SavaJe bereit erklärt. [Ret04] Architektur SavaJe ist ein 32-Bit Multitasking- und Multithreading-Betriebssystem. Kernel, Gerätetreiber, die JVM, das Grafik- und Medienframework und der komplette low-level code sind in C oder C++ geschrieben, der Rest der Plattform in Java. Das Betriebssystem ist auf Java ausgerichtet, daher wird Java-Code sehr effizient ausgeführt. SavaJe benötigt keine Translation- und Portability-Layers – die Java Virtual

252

■ ■ ■

4 Mobile Multimedia

Machine ist hier weniger „virtuell“ als auf anderen mobilen Betriebssystemen, auf denen eine JVM läuft. Momentan existieren erste Referenzimplementierungen für die Chipsets OMAP (Texas Instruments) und die Intel XScale-Chipsets, die Umsetzung für ARM-Prozessoren ist ebenso denkbar. Entwicklungsumgebung/Programmierung SavaJe OS bringt Java SE-Funktionalität auf mobile Endgeräte. Für die Entwicklung grafischer Oberflächen können die Java Swing-Komponenten eingesetzt werden, um ein einheitliches Look-and-Feel für System-Anwendungen und Software von Drittanbietern wie MIDlets und Xlets zu erreichen. Für den Entwickler stellt SavaJe OS ein umfangreiches Set an Java APIs bereit. Es unterstützt Java 2 Standard Edition APIs, Packages und Classes, inklusive Swing, Java 2D, AWT, Full Java 2 Security, JDBC, Jini, RMI und CORBA. Multimedia SavaJe unterstützt neben den üblichen Bildformaten einige Audiound Videoformate, so auch MIDI, AAC, AMR-NB, mp3, mp4-Video und avi. Natürlich unterstützt SavaJe die JSR-135 (Mobile Media API), JSR 184 (Mobile 3D Graphics API) und zukünftig JSR-209 (Advanced Graphics). [Sav06] 4.3.2.9 J2ME – Java 2 Micro Edition Die Programmiersprache Java bietet heutzutage die wohl portabelste Umgebung der kommerziellen Software-Entwicklung. Der Erfolg von Java ist neben der großen Anzahl von JVMs für fast alle Betriebssysteme vor allem auch auf die koordinierte Weiterentwicklung der Sprache und der APIs über die Java Community zurückzuführen. Während nicht alle Hersteller von PDAs eine lauffähige JVM für ihre Geräte anbieten, sind mittlerweile fast alle Mobiltelefone über JavaAnwendungen erweiterbar, je nach Ressourcen mit mehr oder weniger Funktionsumfang. Im Gegensatz zu SavaJe (s.o.) existieren jedoch einige Unterschiede zur klassischen Java-Programmierung. Architektur Es existieren drei große Kategorien von Java APIs und Virtual Machines: J2EE, J2SE und J2ME (s. Abb. 4.27). Java’s Standard-VM benötigt auf der Mehrzahl der mobilen Geräte weitaus zu viel Speicher und Rechenleistung, auch werden hier gar nicht alle Bibliotheken benötigt. Aus diesem Grunde wurde speziell für ressourcenbegrenzte Endgeräte die J2ME-Spezifikation entwickelt. Um den unterschiedlichen Gerätegruppen gerecht zu werden, wurden in J2ME spezielle Konfigurationen und Profile eingeführt. Diese legen Sprachen-Subsets fest und


J2EE, J2SE und J2ME

■ ■ ■

253

Abb. 4.27: Übersicht Java

Konfigurationen

berücksichtigen so die speziellen Eigenschaften dieser Geräte wie geringe Prozessorleistung, begrenzter Speicher oder kleine Displays. Die Konfiguration beschreibt den minimalen Funktionsumfang einer Geräteklasse wie z. B. PDAs, die dazu passende Virtual Machine und die passenden APIs. Für jede Konfiguration gibt es verschiedene Profile, die die Konfiguration dann zu einer vollständigen Laufzeitumgebung erweitern. Momentan existieren zwei Konfigurationen: x CDC (Connected Device Configuration, JSR-36 bzw. JSR-218): Für leistungsfähige mobile Endgeräte gedacht, wie Set-Top-Boxen, mobile Computer in Autos, etc. mit Speicherplatz zwischen 2 und 16 MB. Die CDC enthält nahezu alle J2SE-Klassen und arbeitet mit der Standard-JVM. Auf diese Konfiguration soll daher im Folgenden nicht näher eingegangen werden. x CLDC (Connected Limited Device Configuration, JSR-30 bwz. JSR139): CLDC ist ein Subset von CDC und für Mobiltelefone, PDAs und andere kleine Consumer-Geräte mit Speicher zwischen 32 und 512 KB konzipiert. Die auf diesen Geräten verwendete Virtual Machine heißt KVM (Kilo-Virtual-Machine).

KVM

254

■ ■ ■

Die KVM ist in C geschrieben und benötigt zwischen 40 und 80 KB, je nach Endgerät. Sie stellt bei weitem nicht alle Funktionen der Standard-JVM zur Verfügung. So werden in CLDC 1.0 keine Fließkommazahlen erlaubt, JNI oder Thread-Gruppen werden ebenso wenig unterstützt wie automatische Garbage-Collection durch finalization oder schwache Referenzen. Klassen können auch nur von der KVM selbst und nicht, wie bei J2SE, über einen ClassLoader geladen werden.

4 Mobile Multimedia

Die Klassenverifizierung wird nicht zur Laufzeit auf dem mobilen Endgerät durch die JVM vorgenommen, sondern schon auf dem Entwicklungsrechner von einem so genannten Preverifier. Das MIDP-Profil ist derzeit das einzige weit verbreitete Profil für CLDC 1.0 (JSR-30), das PDAP (Personal Digital Assistant Profile) hat sich nicht durchgesetzt. MIDP 1.0 setzt bei den Geräten bestimmte Eingeschaften voraus: x Displaygröße von ca. 96 x 24 Pixel, 1 Bit Farbtiefe x Mind. 128 KB nichtflüchtiger Speicher (mind. 8 KB für Anwendungsdaten, mind. 32 KB für Java Runtime Speicher) x Drahtlosverbindung zum Netzwerk x Telefontastatur als Eingabemöglichkeit (ITU-T konform oder QWERTY) oder Touchscreen x Verwaltung des so genannten MIDlet-Lifycycles (Installation, Starten, Pausieren, Beenden der Java-Anwendung) durch eine Application Management Software [Fre03], [Sun06] J2ME-Anwendungen werden als so genannte MIDlets auf das Endgerät geladen und laufen dort aus Sicherheitsgründen in einer „Sandbox“. Da aber die J2ME CLDC-Spezifikation ein wesentlich einfacheres Sandbox-Sicherheitsmodell vorsieht als der J2SE-Standard, hat ein MIDlet nur auf einen vordefinierten Satz an Klassen und Bibliotheken Zugriff wie die CLDC/MIDP/J2ME-Pakete, sowie herstellerspezifische Zusatzklassen wie z. B. das Nokia User Interface. Die VM nutzt auf dem Gerät auch nur native Funktionen, die für sie notwendig sind. Um dieses Sicherheitsmodell zu untermauern, kann der in der VM enthaltene ClassLoader auch nur diese definierten Klassen oder die AnwendungsJAR (das MIDlet) laden. Der ClassLoader kann auch nicht wie in J2SE überschrieben oder rekonfiguriert werden. Die JNI (Java Native Interface) API wird daher nicht auch unterstützt: native Bibliotheken können nicht via System.loadLibrary geladen werden. Eine komfortable Besonderheit von J2ME stellt das GCF (Generic Connection Framework) dar: Über ein abstraktes Interface können auf einfache Weise Verbindungen wie z. B. Sockets oder http-Requests aufgebaut werden. Bei bestimmten Betriebssystemen (z.B Symbian OS oder Windows Mobile OS) kann das GCF Framework auch dazu eingesetzt werden, das Sicherheits-Prinzip bewusst zu umgehen. Über das GCF kann eine lokale Verbindung zum localhost (127.0.0.1) aufgebaut werden. Läuft neben der JVM in einem zweiten Prozess auf dem Endgerät ein Server, so kann dieser Anfragen der Java-Anwendung entgegennehmen und auch gerätespezifische Funktionen aufrufen. So verliert man zwar die Plattformunabhängigkeit, dies ist u. U. hingegen leichter zu akzeptieren als das Umschreiben des kompletten


Profile

Sicherheit von J2ME Anwendungen

Generic Connection Framework

■ ■ ■

255

Record Store

Abb. 4.28: MIDlet-Build-Prozess

Deployment

256

■ ■ ■

Quellcodes in eine andere Programmiersprache, nur weil eine benötigte gerätespezifische Funktion unter Java nicht unterstützt wird. Persistente Speicherung von Daten kann unter J2ME nur über den Record Store verwirklicht werden: Daten werden als Bytestream in einzelnen Records abgelegt und können über ihre Record-ID wieder zugänglich gemacht werden. Unter MIDP 2.0 kann ein MIDlet im Gegensatz zu MIDP 1.0 auch auf Daten des Record Store anderer MIDlets zugreifen, wenn diese dies erlauben. Entwicklungsumgebung Die Erstellung von Java-Anwendungen für mobile Endgeräte umfasst im Wesentlichen folgende Schritte:

Als Compiler wird der Standard-Java-Compiler verwendet. Wie oben bereits erwähnt, muss der Bytecode vor dem Übertragen auf das Endgerät noch präverifiziert werden. Das hat den Vorteil, dass ein Teil der Arbeit auf den leistungsfähigeren Entwicklungsrechner verlagert wird. Um den Quellcode zu komprimieren, kann ein Obfuscator eingesetzt werden, der alle Kommentare eliminiert und Methoden-, Variablen- und Klassennamen auf wenige Buchstaben verkürzt. So kann die Größe der JAR-Datei bis zu 20% kleiner werden. Zum Deployment sind noch weitere Dateien notwendig, z. B. die MANIFEST-Datei, in der u. A. Informationen über das verwendete Profil und die verwendete Konfiguration stehen. Die JAD-Datei enthält die gleichen Informationen wie die MANIFEST-Datei, zusätzlich aber noch die Größe der JAR-Datei und die URL, über die das MIDlet bezogen werden kann. Dies ist sinnvoll, da die JAD-Datei beim OTA-Provisioning, d. h. wenn der Client das MIDlet über ein Netz herunterlädt, zuerst geladen wird. So ist dem Client die Größe der

4 Mobile Multimedia

JAR-Datei, sowie die auf dem Endgerät erwarteten Voraussetzungen bereits vor dem Download der in der Regel wesentlich größeren JARDatei bekannt. Das von SUN entwickelte Wireless Toolkit (WTK) war das erste weit verbreitete Werkzeug, um die J2ME-Software-Entwicklung zu automatisieren. Es stellt neben dem Preverifier auch Emulatoren bereit. Da der Editor jedoch nicht sonderlich komfortabel ist, wird das WTK meist über ein Plugin in die frei erhältliche IDE Eclipse eingebunden. Nokia hat einige Versionen des Nokia Development Kit entwickelt, die in verschiedene IDEs (u. A. Eclipse oder Borland) eingebunden werden können und auch ohne das WTK die Möglichkeit bieten, MIDlets zu schreiben, zu debuggen und zu deployen. Auch die Carbide-Serie wurde um eine Entwicklungsumgebung für J2MEAnwendungen erweitert: carbide.j. Leider ist das Prinzip „Write once, run everywhere“ im Bereich von J2ME nur mit Vorsicht zu genießen. Für das Testen der Anwendungen stellen Software- oder Gerätehersteller meist Emulatoren bereit, die das Endgerät jedoch selten optimal abbilden. Leider führte auch die Definition der Konfigurationen und Profile nicht zum gewünschten Erfolg der Plattformunabhängigkeit. Anwendungen führen auf Mobiltelefonen unterschiedlicher Hersteller, die laut Herstellerangaben die gleichen Profile unterstützen, zu unterschiedlichen Ergebnissen. Der Start einer Anwendung kann im einen Fall zu einem lauffähigen Handyspiel führen, im anderen Fall zu einem falsch dargestellten Bild ohne Interaktionsmöglichkeit. Offensichtlich wird bei der Implementierung der JVM oft nicht korrekt gearbeitet, was aufwändiges Testen auf den speziellen Zielgeräten notwendig macht. Doch neben der nur bedingt gültigen Plattformunabhängigkeit aufgrund fehlerhafter Implementierungen der Gerätehersteller gibt es noch weitere Nachteile. So sind MIDlets in ihrer Größe recht beschränkt und laufen insgesamt eher langsam. Der Record Store stellt ebenso kein brauchbares System zur persistenten Speicherung größerer Datenmengen dar. Doch J2ME entwickelt sich ständig weiter. Während das MIDP 1.0-Profil z. B. nur sehr eingeschränkte Funktionen bot, setzt sich MIDP 2.0 zunehmend durch und unterstützt mehr Multimedia-Fähigkeiten und Spieleprogrammierung. Der Vorteil von J2ME liegt klar in der weiten Verbreitung.

Werkzeuge zur J2ME-Entwicklung

Vor- und Nachteile

Programmierung Die Programmierung entspricht von der Syntax her der J2SE-Programmierung. Natürlich steht nur ein sehr eingeschränkter Befehlssatz zur Verfügung und einige Pakete wurden speziell für die Micro Edition entwickelt.


■ ■ ■

257

Application Lifecycle

Eine J2ME-Anwendung erbt immer von der Klasse MIDlet und muss für den Lebenszyklus der Anwendung bestimmte Methoden implementieren: import javax.microedition.midlet.MIDlet; import javax.microedition.lcdui.*; public final class MeinMIDlet extends MIDlet { private Display display; public MeinMIDlet() { ... } // Konstruktor public void startApp() { display = Display.getDisplay(this); Form text = new Form("Hallo MIDlet!"); display.setCurrent(text); } protected void destroyApp(boolean unconditional) { ... } protected void pauseApp(){ ... }

}

Die Methode startApp() setzt das MIDlet vom Pause-Zustand in den aktiven Zustand, kann also während der Laufzeit der Anwendung mehrfach aufgerufen werden. Die Grundinitialisierung sollte folglich im Konstruktor erfolgt sein. Mit der Methode pauseApp() kann das MIDlet seine Threads pausieren. destroyApp() kann aus aktivem oder Pause-Zustand heraus gerufen werden. Hier sollte das MIDlet alle Ressourcen freigeben, bevor es dann terminiert. Die grafische Oberfläche unter J2ME kann auf zwei Weisen gestaltet werden. Die Screens machen über die high-level-UI einfache GUI-Programmierung möglich. Sie werden für einfache Textausgabe, Formulare, Listen oder Hinweise eingesetzt. Für aufwändigere Grafik wie z. B. bei der Spieleprogrammierung kann mit dem Canvas das low-level-Userinteface eingesetzt werden. Hier bietet MIDP 2.0 (JSR-118) zusätzlich die Klasse GameCanvas mit einem integrierten off-screen Grafikpuffer an, sowie weitere Klassen wie Layer oder Sprite, um Spieleprogrammierung zu vereinfachen. Java Special Requests

258

■ ■ ■

Multimedia Die Leistungsfähigkeit der High-End Mobiltelefone oder Smartphones nimmt stetig zu. Somit könnten auch immer komplexere J2MEAnwendungen entwickelt werden. Um die vorhandenen Hardware-Ressourcen besser zu nutzen, wurde zum einen das MIDP-Profil wie bereits erwähnt weiterentwickelt und MIDP 1.0 (JSR-37) um wichtige Multimedia-Pakete wie javax.microedition.lcdui.games (Sprites etc.) und javax.microedition.lcdui.media (Audio und Video-Player)

4 Mobile Multimedia

erweitert. Die MIDP 2.0 Media API ist aber immer noch eher für Geräte mit weniger Ressourcen gedacht und bietet auch keine Video- oder Grafikfunktionen. Zum anderen definiert die Java Community über den JSR (Java Specification Request)-Prozess optionale J2ME APIs, die auf CLDC/ MIDP aufsetzen. Unter diesen optionalen Paketen sind auch viele Erweiterungen, die die Multimedia-Fähigkeit betreffen. Im mobile Multimedia-Bereich scheinen folgende bereits festgelegte bzw. zukünftige JSRs insbesondere interessant: x JSR-135 (Mobile Media API): Kontrollmöglichkeiten für Audio und Video. Die JSR-135 ist ein Superset der MIDP 2.0 Media API. x JSR-178 (Mobile Game API): zur einheitlichen Unterstützung von spieletypischen Geräteeigenschaften wie Vibrator, Sound und Grafik x JSR-184 (Mobile 3D Graphics): 3D-Rendering, Nebel, Texturiering, Kameraeinstellungen x JSR 226 (Scalable 2D Vector Graphic): API zur Darstellung von SVGT (Scalable Vector Graphics – Tiny) Grafiken und Animationen x JSR-234 (Advanced Multimedia Supplements: z. B. Audio Effekte wie Reverb, Equalizer, Radio-Integration (baut auf JSR-135 auf) Auch Flash-Inhalte (s.u.) können unter J2ME eingebunden werden [Jfl06]. Allerdings ist die externe Java API „jFlash“, als open-sourceProjekt angelegt, noch in den Anfängen. Die JSRs werden nach und nach von den Herstellern in ihren Geräten integriert. Dies geschieht leider nicht so schnell und fehlerlos, wie es sich der Anwendungsentwickler wünscht und hieraus ergeben sich wieder weitere Diversifikationen zwischen den unterschiedlichen Geräten. Der Prozess ist jedoch sicher ein Schritt in die richtige Richtung, um doch relativ schnell neu zur Verfügung stehende Ressourcen der leistungsfähigen Geräte in der Anwendungsentwicklung einsetzen zu können. 4.3.2.10 Flash Lite Seit vielen Jahren hat sich Macromedia Flash als Standard für vektorbasierte 2D-Animationen im Internet etabliert. Obwohl z. T. auch entsprechende open source-Projekte existieren, werden die Inhalte meist mit dem kostenpflichtigen Autorentool Macromedia Flash erstellt. Macromedia wurde mittlerweile von Adobe aufgekauft und Adobe hat die Weiterentwicklung der Flash-Produktreihe zugesichert. Der Funktionsumfang des Tools ist im Laufe der Zeit immer weiter gewachsen, mittlerweile können dank der in Flash integrierten objekt-


■ ■ ■

259

Flash Player

Flash Lite

Markt für Flash Lite

260

■ ■ ■

orientiertem Actionscript-Programmiersprache komplexe interaktive Anwendungen erstellt werden. Um Plattformunabhägigkeit zu erreichen, verfolgt Adobe den gleichen Ansatz wie J2ME: Auf dem Endgerät muss eine entsprechende Laufzeitumgebung installiert sein, damit die proprietären swf-Dateien lauffähig sind. Der Nachteil hierbei ist, dass dieser Player (wie die JVM bei Java auch) Ressourcen auf dem Endgerät beansprucht und somit die Anforderungen entsprechend steigen. Der Flash Player wird im Desktop-Bereich kostenfrei angeboten. Auch für einige PDAs (Microsoft-Betriebssystem ab Pocket PC 2002, s.o. und Sony Clie-Geräte) kann er kostenfrei heruntergeladen und installiert werden. Der Flash Player für PDAs unterscheidet sich nicht wesentlich von der Desktop-Version, daher soll hier nicht näher darauf eingegangen werden. Mit Flash Lite hat Macromedia eine Umgebung für die im Verhältnis zu PDAs meist ressourcenschwächeren Mobiltelefone geschaffen. Inhalte können mit der Professional-Version des Flash-Autorentools erstellt werden, auf dem Endgerät muss der entsprechende Flash Lite Player installiert sein. Flash Lite ist zurzeit in Europa noch selten standardmäßig in Mobiltelefonen integriert, kann aber z. T. kostenpflichtig nachinstalliert werden. Momentan ist Flash Lite eher auf Spiele, kleine Animationen und Rapid Prototyping ausgerichtet und hat noch viele Einschränkungen. Es existieren mehrere Versionen: Flash Lite 1.x beruht auf dem Flash Player 4, Flash Lite 2.0 auf Flash Player 7. In der Version Flash Lite 2.0 werden, anders als bei den Vorgängerversionen, persistente Daten und das objektorientierte ActionScript 2 unterstützt, viele Systemfunktionalitäten wie z. B. der Zugriff auf Bluetooth auf dem Endgerät sind jedoch auch hier nicht möglich. Es bleibt abzuwarten, wie gut sich Flash Lite durchsetzen kann. Da grafische interaktive Anwendungen mit dem Autorentool recht schnell erstellt werden können und hier auch eine sehr große Entwicklergemeinde besteht, scheint einem Markterfolg nicht viel entgegen zu stehen. Macromedia bzw. Adobe bildet einige wichtige Allianzen, um den Flash Lite Player als neue Plattform im Bereich der mobilen Endgeräte zu etablieren, so integriert Macromedia sein Flash-Authoringtool in die BREW-Entwicklungsumgebung. Bisher unterstützte Qualcomm bei den multimedialen Handyanwendungen ausschließlich das konkurrierende Grafikformat SVG-T. Auch Nokia und Samsung wollen den Flash Lite Player in ihre Geräte integrieren, ebenso T-Mobile [Ins06]. Flash Lite läuft z. B. bereits auf dem iRiver U10 [Ado06]. Außer auf Mobiltelefonen kann der Flash Player auch auf anderen Plattformen implementiert werden, so z. B. auf Set-Top-Boxen oder elektronischen Musikinstrumenten [Lyn05].

4 Mobile Multimedia

Architektur Macromedia Flash Lite ist eine schlanke Version des Flash Players, ausgelegt für Mobiltelefone. Sie integriert sich in das Betriebssystem, bietet Netzwerkunterstützung für die dynamische Datenanbindung von Anwendungen und nutzt Hardware-Codecs, sofern diese verfügbar sind. Flash Lite kann für verschiedene Zwecke verwendet werden, für komplexe Anwendungen, Spiele oder auch für die Gestaltung der eigentlichen Benutzeroberfläche. Die Medienwiedergabefunktion von Flash Lite beruht auf dem Rendering-Hauptmodul des Flash Players und unterstützt Vektorgrafiken, Bitmaps, Verläufe und framebasierte Animationen (s. Abb. 4.29). Um die Anzeige XML-basierter Vektorgrafiken zu unterstützen, ist SVG-T in Flash Lite als Option verfügbar. Über ActionScript kann auf bestimmte Systemfunktionen wie z. B. Tastendruck, SMS-Versand, Telefonanruffunktionen etc. zugegriffen werden. Es können auch gerätespezifische Eigenschaften wie z. B. Netzwerkeigenschaften, die Geräteplattform oder Akkustatus abgefragt werden. Auf recht einfache Weise, vergleichbar mit GCF unter J2ME, unterstützt Flash Lite auch den Zugriff auf Netzwerke z. B. per httpRequest. Als Schriftarten können entweder systemeigene oder eingebettete Schriften verwendet werden. Die Audiofähigkeiten umfassen den Zugriff auf die Gerätesounds und das Streaming von Audiodaten. Der Flash Lite-Programmcode belegt auf einem Endgerät mit ARMProzessor 280 KB Speicher, weitere 117 KB werden für die SVG-TUnterstützung (Scalable Vector Graphics – Tiny) benötigt. Macromedia empfiehlt als technische Anforderungen mindestens 1 MB ROM, 50 MIPS, 2 MB RAM und einen 32-Bit-Datenbus. [Lyn05] Abb. 4.29: Architektur Flash Lite 2 [Ado06]


■ ■ ■

261

Autorentool Macromedia Flash

ActionScript

Entwicklungsumgebung Das Autorentool Macromedia Flash ist, wenn auch einige freie Werkzeuge am Markt zur Verfügung stehen, das Werkzeug der Wahl für die Entwicklung von Flash Lite-Anwendungen. Diese können hier erstellt und gedebuggt werden, Emulatoren für die unterschiedlichsten Geräte und GUI-Versionen sind ebenfalls enthalten und werden per Software-Update ständig erweitert. Da Macromedia Flash ursprünglich für 2D-Animationen eingesetzt wurde, ist das Werkzeug sehr grafisch orientiert. Die Bedienphilosophie gestaltet sich daher anders als die der bisher vorgestellten Programmierumgebungen. Macromedia Flash arbeitet mit einer Zeitleiste und Frames, in die Programmiercode eingebettet werden kann. Der Programmiercode kann weiterhin auch auf Objekte gelegt werden. ActionScript ist seit Version 2 komplett objektorientiert und ermöglicht damit komfortable und komplexe Programmierung. Ein Nachteil dieser Philosophie liegt darin, dass es keinen zentralen Editor gibt und sich die Programmierlogik auf sehr viele Objekte verteilen kann. Diese sind selten alle sichtbar, worunter die Übersichtlichkeit entsprechend leidet. Ist die Anwendung unter Einsatz des Debuggers und Emulators entwickelt, so wird sie als swf-Datei exportiert und kann auf das Endgerät übertragen werden. Programmierung ActionScript selbst besitzt einen übersichtlichen Befehlssatz und ist recht schnell und intuitiv erlernbar. Der Aufbau einer Verbindung beispielsweise geschieht ähnlich wie mit dem GCF unter Java, der Zugriff auf die Messaging-Funktion ist ebenfalls sehr intuitiv. Der Event wird einem Button zugewiesen und der ActionScript-Befehl zum Versenden einer SMS beispielsweise lautet dann lediglich: on(release) { getURL(„sms:01234/56789?body=SMS mit FlashLite”) }

Multimedia Flash war von Anfang an stark Multimedia-orientiert mit Fokus auf Grafikanimation, so dass in das Autorentool viele Formate eingebunden werden können. Während die Video-Fähigkeit unter Flash Player 1.x noch emuliert werden musste, werden ab Flash Player 2.0 auch .3gp und mpeg-4-Dateien unterstützt. Flash Lite unterstützt den W3C Standard SVG-T (s.u.). Ab Version Flash Lite 2 ist es auch möglich, zusätzliche Multimedia-Daten von einer URL oder dem Gerät in die Anwendung zu laden, so dass nicht alles in die swf-Datei gepackt werden muss.

262

■ ■ ■

4 Mobile Multimedia

4.3.2.11 OpenGL ES Neben Direct3D (s.o.) gibt es mit OpenGL noch einen anderen weit verbreiteten Standard, um anspruchsvolle 3D-Umgebungen zu schaffen. OpenGL ist im Vergleich zu seinem Microsoft-Konkurrenten eine offene plattformübergreifende API, die von der Khronos-Gruppe standardisiert wurde. Die Khronos-Gruppe wurde im Jahre 2000 von führenden Mitgliedern im Bereich Computergrafik (u. A. 3DLabs, ATI, nVidia, Intel und Discreet) gegründet mit dem Ziel, offene Standard APIs für die Erstellung und das Abspielen von rich media auf einer großen Anzahl von Plattformen und Geräten zu entwickeln. So wurde, analog zu dem Microsoft-Derivat Direct3D Mobile, auch eine leichtgewichtige Variante von OpenGL für Embedded-Systeme standardisiert: OpenGL ES (Open Graphics Library Embedded Systems). Gegenwärtig standardisiert die Khronos-Gruppe mit OpenSL ES auch noch eine interessante offene Sound API für Embedded-Systeme, die Entwicklern von mobilen Anwendungen und Spielen eine große Palette an high-level Audio APIs zur Verfügung stellen soll. [Khr06] Der OpenGL ES-Standard besteht aus klar definierten Subsets der Desktop API und stellt so eine flexible low-level Schnittstelle dar zwischen Softwareanwendungen und 2D/3D-Grafikhardware oder – Engines. Die Portierung bereits bestehender Anwendungen auf mobile Endgeräte wird daher einfacher, Neuprogrammierung findet in der gewohnten OpenGL-Umgebung statt. Die Landschaft der EmbeddedSysteme variiert stark bezüglich Prozessorgeschwindigkeit und Speicher. OpenGL ES kommt dieser Anforderung entgegen, da die API einen sehr kleinen Footprint hat mit minimalen Anforderung an Speicherplatz, nur wenig Instruktions-/Datenverkehr verursacht und sowohl Integerwerte wie auch Fließkomma-Werte unterstützt. Unter OpenGL ES können Aufrufe hardwarebeschleunigter und softwarebeschleunigter Funktionen kombiniert werden, so dass eine programmierte 3D-Engine nahtlos dazu übergehen kann, bei hochwertigeren Geräten auch Hardware-Beschleunigung einzusetzen. Neue HardwareInnovationen können recht schnell und problemlos, dennoch aber auf kontrollierte Weise, über den OpenGL Erweiterungsmechanismus durch die API verfügbar gemacht werden. So können andere Organisationen (zumeist Hersteller von Grafikkarten) auch proprietäre Erweiterungen definieren.

Das OpenGL ES Framework Das Framework besteht aus mehreren Komponenten. Zum einen enthält die OpenGL ES-Spezifikation die Definition von Profilen, zum anderen einen Erweiterungs-Mechanismus über Extensions.


OpenSL ES

OpenGL ES Eigenschaften

Profile und Extensions

■ ■ ■

263

Abb. 4.30: EGL

OpenGL ES-Profile enthalten zum einen ein Subset der OpenGL API, zum anderen OpenGL ES-spezifische Erweiterungen. Sie teilen sich mit den Desktop-OpenGL-Profilen eine ähnliche Processing Pipeline, Befehlsstruktur und den gleichen OpenGL Namespace. Jede Profil-Definition enthält eine profilspezifische Header-Datei und eine Link-/Runtime-Bibliothek, die die Befehle und Tokens des Profils definieren. Zur Laufzeit kann eine Anwendung dann über eine OpenGL Versions-string-Abfrage feststellen, welches Profil gerade läuft. Momentan sind in der Spezifikation lediglich zwei Profile definiert: das „Common Profile“ und das „Safety Critical Profile“. Ersteres ist für Consumer-Unterhaltung und Handsets, Mobiltelefone, Spielekonsolen Set-Top-Boxen, etc. gedacht und stellt trotz kleinem Footprint umfangreiche 3D-Funktionen wie z. B. Texture-mapping zur Verfügung, ist also gut geeignet als Spieleplattform für mobile Endgeräte. Letzteres wurde an die sicherheitskritischen Anforderungen im Bereich Luftund Raumfahrt, Industrie, Medizin, Militär und Automobil angepasst. Hier wurde Wert gelegt auf Verlässlichkeit, Echtzeitanforderungen und Zertifizierung, daher bietet dieses Profil nur eingeschränkte Funktionen für Texturen oder Alpha-/Blend-Funktionen. OpenGL ES-SC 1.0 ist die standardierte API für das Safety critical profile. OpenGL ES-Implementierungen können über die so genannten Extensions um neue Features erweitert werden. Jede Erweiterung wird derart beschnitten, dass es mit dem Befehls-Subset eines Profils übereinstimmt und kann diesem dann als so genannte „core addition“ oder als „mandatory oder optional extension“ hinzugefügt werden. Die neben Profilen und Extensions dritte Komponente des OpenGL ES Frameworks ist eine plattformunabhängige Schnittstellen-Ebene namens „EGL“. EGL (die Spezifikation liegt in Version 1.1 und 1.2 vor) ist eine allgemeine Schnittstelle zwischen Khronos-Render APIs wie z. B. eben OpenGL oder auch OpenVG und dem darunter liegenden nativen Bertriebssystem (s. Abb. 4.30). EGL erledigt die Initialisierung des Rendersystems und stellt Mechanismen zur Erstellung von Render-Oberflächen (windows, pbuffers, pixmaps) zur Verfügung, auf die dann wiederum OpenGL ES oder OpenVG als Client APIs aufsetzen und Grafikkontexte für higher-level Client-Anwendungen erstellen und zeichnen können. So kann das Zeichnen von Grafik zwischen Client APIs und nativen Render APIs wie z. B. XLib oder GDI synchronisiert werden.

OpenGL ES Versionen Momentan existieren zwei wichtige Versionen von OpenGL ES: OpenGL ES 1.x und OpenGL ES 2.x. Die Versionen 1.x sind gedacht für nichtprogrammierbare Hardware (fixed function hardware).

264

■ ■ ■

4 Mobile Multimedia

Abb. 4.31: Rendering Pipeline OpenGL ES 1.x

Hierbei basiert die Version 1.0 auf dem OpenGL 1.3-Standard und die Version 1.1 auf der Desktop-Variante OpenGL 1.5. OpenGL ES 1.0 fokussiert Software-Beschleunigung für Embedded-Systeme, während OpenGL ES 1.1 voll rückwärtskompatibel ist und erweiterte Funktionen für Hardware-Grafikbeschleunigung, verbesserte Bildqualität und Performanz bietet. Abb. 4.32: Rendering Pipeline OpenGL ES 2.0

OpenGL ES 2.x hingegen ist nicht mehr voll kompatibel zu den 1erVersionen und wurde relativ zum OpenGL 2.0 Standard definiert. Diese API bietet Funktionen für eine programmierbare 3D GrafikPipeline mit der Möglichkeit, Shader- und Programm-Objekte zu erzeugen. Mit OpenGL ES 2.x kann auch die OpenGL Shader-Sprache verwendet werden, um Vertex- und Fragment-Shader zu programmieren.

OpenGL ES Implementierungen Sowohl Profile wie EGL können für Prozessoren optimiert werden. Nokia hat dies beispielsweise für ARM-Prozessoren umgesetzt und OpenGL ES in die Series 60 Plattform (2nd Edition, Feature Pack 2) auf Symbian OS integriert. OpenGL ES und EGL werden gepackt in einer Datei (libGLES_cm.dll) mit dem Common Profile zur Verfügung gestellt. [Bra04] Daneben existieren zahlreiche Implementierungen für weitere Plattformen wie z. B. Sony’s Playstations, einige Microsoft Pocket PCGeräte, Linux MontaVista OS ARMv6 auf TI’s OMAP2420, diverse Linux ARMv4-Varianten oder auch BREW. [Khr06]


Optimierung

■ ■ ■

265

Thin Client

Marktentwicklung

266

■ ■ ■

4.3.2.12 Mobile Web Die meisten der oben beschriebenen Plattformen gehen von einer eher hohen Komplexität der Anwendung auf dem mobilen Endgerät aus und entsprechen daher Thick Client-Anwendungen. Im Folgenden sollen Techniken für klassische Thin Client-Anwendungen beschrieben werden. Um multimediale Inhalte abrufen und darstellen zu können, benötigt man oft nur einen gut implementierten Browser. Mit Mobiltelefonen und deren kleinen Displays mit z. T. eingeschränkter Farbwiedergabe ist es jedoch selten möglich, einigermaßen akzeptabel normale HTML-Seiten ansehen zu können. Daher wurde der WAP (Wireless Application Protocol)-Standard eingeführt. WAP ist eine Spezifikation von Kommunikationsprotokollen zur Standardisierung der Zugriffsart von Mobilen Endgeräten auf Internetinhalte (WWW, E-Mail, etc.). WML (Wireless Markup Language) wird benutzt, um Seiten zu erzeugen, welche mittels WAP übermittelt werden. WAP Das Aufrufen einer HTML-Seite mit einem mobilen Endgerät bringt oft Darstellungsprobleme mit sich. HTML-Seiten sind für große Displays und schnelle Datenverbindungen konzipiert. In die Seiten können auch Inhalte integriert werden, für deren Darstellung der Browser auf Client-Seite durch Plugins erweitert werden muss. Alle diese Voraussetzungen sind mit den Einschränkungen von mobilen Anwendungen nicht vereinbar. Viele proprietäre Lösungen wie das Skalieren von Bildern auf dem Proxy, Inhaltstransformationen der darzustellenden Dokumente (z. B. pdf) in einfachen Text, Inhaltsextraktion/semantische Kompression oder der Einsatz spezieller Sprachen wie HDML (Handheld Device Markup Language) oder Protokolle wie HDTP (Handheld Device Transport Protocol) führten zu keinem befriedigenden Ergebnis. [Sch03]. Um die Entwicklung vieler inkompatibler Insellösungen zu vermeiden, gründeten Ericsson, Motorola, Nokia und Unwired Planet im Jahre 1997 das WAP Forum. Im April 1998 veröffentlichte dieses Forum mit WAP 1.0 seine ersten Spezifikationen, weitere Versionen folgten. Seit Mitte 2002 hat die OMA (Open Mobile Alliance) die weitere Standardisierung vom WAP-Forum übernommen. Die hier spezifizierten Standards sind die Basis für die meisten Installationen auf WAP-fähigen mobilen Endgeräten. Obwohl WAP das am meisten verbreitete Framework im mobilen Bereich darstellt, blieb der Standard weit hinter den gehegten Erwartungen zurück. WAP ist nicht grundsätzlich auf einen Trägerdienst festgelegt, anfangs stand jedoch nur das langsame und für den Endanwender teure GSM-Netz zur Verfügung – wohl ein Grund, weshalb es sich nicht etablierte (im Gegensatz zu dem ähnlichen Service i-mode in Japan). Ab 2002

4 Mobile Multimedia

wurde auf den ersten Endgeräten der weiterentwickelte Standard WAP 2.0 implementiert (standardisiert im Juli 2001). [Sch03], [Oma06]

Architektur WAP 1.x definiert ein eigenes Set von Kommunikationsprotokollen, die, an das ISO OSI Referenzmodell angelehnt, von Transport- (WDP-Wireless Datagram Protocol) bis Anwendungsebene (WAE-Wireless Application Environment) alle Ebenen mit eigenen Protokollen umsetzen (s. Abb. 4.33). Für genauere Erläuterungen sei auf [Sch03] und [Oma06] verwiesen. Abb. 4.33: Architektur und Protokolle WAP 1.x

Abbildung 4.34 zeigt den Aufbau der Architektur von WAP 2.0. WAP 2.0 unterstützt die WAP 1.x-Protokolle, erweitert diese jedoch um Internet-Technologien wie IP, TCP, TLS oder http. Das WAE (WAP Application Environment), das sich dem Nutzer gegenüber in Form des WAP-Browsers darstellt, basiert nun auf xHTML (extensible Hypertext Markup Language), mit dem dazugehörigen Mobile Profile (xHTML-MP). xHTML-MP ist ein striktes Subset von xHTML 1.1 und wurde von der OMA als ein spezielles Profil für mobile Endgeräte spezifiert. In der Spezifikation legt die OMA fest, wie sich xHTMLMP-konforme Geräte verhalten sollen. xHTML-MP basiert im Wesentlichen auf xHTML Basic, erweitert dieses Profil jedoch um einige Funktionen wie z. B. zusätzliche Darstellungselemente, Unterstützung von Scripting und internen Style Sheets. [Oma06b] Eine Neuerung in WAP 2.0 ist auch, dass kein Gateway mehr benötigt wird, das die WAP-spezifischen Anfragen in Internet-Formate umwandeln muss, sondern lediglich ein WAP-Proxy, der die Anfragen an einen Webserver weiterleitet. WAP 2.0 führte weiterhin einen Push-Dienst ein, mit dem ein Server eine Sitzung mit einem Client initiieren und z. B. Nachrichten oder eMails an diesen schicken kann. Als Trägernetze werden auch bei WAP 2.0 (ähnlich wie bei WAP 1.x) viele unterschiedliche Träger unterstützt. Heute wird in GSM-Netzen vornehmlich GPRS verwendet, Netze der dritten Generation (s.o.) werden direkte IP-Dienste anbieten.


WAP 2.0

Bearer

■ ■ ■

267

Abb. 4.34: Architektur WAP 2.0 [Sch03]

Transport

Transfer

Session

Die Transportdienste bieten verbindungsorientierte Verbindungen (z. B. mit den Mobile-TCP-Protokoll, s. [Sch03]) oder verbindungslose (z. B. WDP) Ende-zu-Ende-Verbindung. Auf Ebene der Transferdienste werden Hypermedia-Transferprotokolle für das Web-Browsing eingesetzt. Auch der MMS (Multimedia Messaging Service) ist auf dieser Ebene eingeordnet. MMS ist die Multimedia-Version des rein textbasierten SMS (Short Messaging Service) und unterstützt die asynchrone Übertragung verschiedener Medientypen wie Text, JPEG, AMR-codierte Audiosignale oder Videodaten. Die typischerweise 30 - 100 KB großen MMS-Nachrichten enthalten in der Regel eine die Inhalte beschreibende SMIL-Datei. Auf Ebene der Sitzungsdienste finden sich interessante Neuerungen des WAP 2.0-Standards: Das CC/PP (Composite-Capabilities/Preference Profiles)-Rahmenwerk kann für die Aushandlung von Gerätefähigkeiten genutzt werden. Dies schließt Informationen über einen Client, Server und Proxy mit ein und erlaubt auch die Anpassung von Inhalten. Über den Push-OTA-Dienst können z. B. Nachrichten, Verkehrsmeldungen oder Börsendaten übermittelt werden.

Entwicklungsumgebung Das WAE (Wireless Application Environment) gibt vor, wie der WAPClient auf dem mobilen Endgerät, also z. B. der WAP-Browser, die erhaltenen Daten gegenüber dem Nutzer darstellen soll. Hierzu spezifiziert das WAE unter anderem folgende Komponenten:

268

■ ■ ■

4 Mobile Multimedia

x WML: WML ist eine für Drahtloskommunikation optimierte Sprache. Sie basiert auf XML, daher definiert jedes WML-Dokument in der DTD (Document Type Definition) die Elemente, die in WML genutzt werden können. WML-Dokumente enthalten mindestens ein „deck“, vergleichbar einer HTML-Seite. Anders als bei HTMLSeiten kann ein Deck mehrere Bereiche möglicher Nutzer-Interaktion enthalten, so genannte „cards“. Jede Card enthält Informationen in Form von Texten, Bildern, Tabellen oder Eingabeformulare und bietet Navigationsmöglichkeiten zwischen Cards und Decks, ähnlich den Hyperlinks bei HTML. x WBXML (WAP Binary XML): WBXML ist eine Kodierungsspezifikation, um die zu übertragende Datenmenge von WML-Dokumenten zu reduzieren. So wandelt das WAP-Gateway den String href=“http:// beispielsweise in den Wert 4B um, das Schlüsselwort SELECT wird als Byte 37 abgebildet [Sch03] x WMLScript: WMLScript ist eine Javascript-ähnliche Sprache, über die z. B. lokal Nutzereingaben validiert werden können, bevor diese über das Netzwerk übertragen werden. Über WMLScript können eigene Funktionen oder auch vom WAP-Forum definierte Standard-Libraries [Wml06] im WML-Dokument verwendet werden. WMLS-Dateien müssen kompiliert werden (von Hand über einen WMLScript-Compiler oder automatisch durch das Gateway). Die Funktionen können dann in der WML-Datei aufgerufen werden.

Programmierung Für viele ist WAP-Programmierung gleichbedeutend mit WML-Seiten-Programmierung. Was bei http HTML ist, ist bei WAP WML. JavaScript bei Webprogrammierung entspricht WMLScript bei WAP. Um WAP-Anwendungen zu erstellen, können für die Erstellung der eigentlichen wml oder wmls-Dateien einfache Texteditoren verwendet oder auf andere kostenfreie Werkzeuge zurückgegriffen werden. Beispiel für eine wml-Datei: reverse.wml

WML und WMLScript

Kompendium Medieninformatik: Mediennetze (X.media.press)

Kompendium Medieninformatik: Medienpraxis (X.Media.Press)

Kompendium Medieninformatik: Medienpraxis GERMAN

Kompendium Informationsdesign

Trojaner Kompendium

C# Kompendium

Druckluft-Kompendium

Hardware Kompendium

Trojaner Kompendium

C# Kompendium

Kompendium Katekismus Gerejakatolik

Adobe InDesign CS Kompendium

Java 2 Kompendium GERMAN

Kompendium Ajaran Sosial Gereja

Leczenie w neurologii: kompendium

CSS Praxisbuch. Kompendium

Access 2000 Kompendium

Das PC Handbuch. Kompendium

Kompendium Praktische Psychiatrie

Kompendium Multimediales Lernen GERMAN

Windows XP Professional Kompendium

Kompendium der Innovationsforschung

Access-VBA Kompendium

Kompendium der Psychiatrischen Pharmakotherapie

Kompendium pädiatrische Diabetologie

Kompendium E-Learning (X.media.press)

Windows 2000 Server - Kompendium

Kompendium der neurologischen Pharmakotherapie

ASP. Kompendium programisty

Kompendium der Psychiatrischen Pharmakotherapie

Kompendium der Tracheotomie

Kompendium Medieninformatik: Mediennetze (X.media.press)

Kompendium Medieninformatik: Medienpraxis (X.Media.Press)

Kompendium Medieninformatik: Medienpraxis GERMAN

Kompendium Informationsdesign

Trojaner Kompendium

C# Kompendium

Druckluft-Kompendium

Hardware Kompendium

Trojaner Kompendium

C# Kompendium

Kompendium Katekismus Gerejakatolik

Adobe InDesign CS Kompendium

Java 2 Kompendium GERMAN

Kompendium Ajaran Sosial Gereja

Leczenie w neurologii: kompendium

CSS Praxisbuch. Kompendium

Access 2000 Kompendium

Das PC Handbuch. Kompendium

Kompendium Praktische Psychiatrie

Kompendium Multimediales Lernen GERMAN

Windows XP Professional Kompendium

Kompendium der Innovationsforschung

Access-VBA Kompendium

Kompendium der Psychiatrischen Pharmakotherapie

Kompendium pädiatrische Diabetologie

Kompendium E-Learning (X.media.press)

Windows 2000 Server - Kompendium

Kompendium der neurologischen Pharmakotherapie

ASP. Kompendium programisty

Kompendium der Psychiatrischen Pharmakotherapie

Kompendium der Tracheotomie

Recommend Documents