M a s t e r T h e s i s

Transkript

1 Fachhochschule Köln Cologne University of Applied Sciences 07 Fakultät für Informations-, Medien- und Elektrotechnik, Studiengang Information Engineering Institut Nachrichtentechnik Labor für Datennetze M a s t e r T h e s i s Thema: Evaluation eines IPTV Monitoringsystems auf Basis von Android Student : Dipl.-Ing. Stephan Küffner Matrikelnummer: Referent : Prof. Dr.-Ing. Andreas Grebe Korreferent : Prof. Dr. rer. nat. Carsten Vogt Abgabedatum : 15. August 2011

2 Hiermit versichere ich, dass ich diese Master Thesis selbständig angefertigt und keine anderen als die angegebenen und bei Zitaten kenntlich gemachten Quellen und Hilfsmittel benutzt habe. Stephan Küffner

3 Stephan Küner Inhaltsverzeichnis Inhaltsverzeichnis 1. Danksagung 6 2. Vorwort 7 3. Ziel dieser Master Thesis 8 4. Grundlagen IPTV Codec Container Qualitätsbetrachtung von Video Quality of Service Quality of Experience Verfahren zur Bestimmung der Qualität SmartVideo Systemansatz Vorstellung Analyse des Messkopfes Messungen Zustandsdiagramm Threads Aufnehmende Parameter Android Architektur eines QoS/QoE Sensors Systemarchitektur Activities Sicherheitskonzept Erweiterte Administratorenrechte SDK vs. NDK Software Development Kit Native Development Kit Vergleich

4 Inhaltsverzeichnis 7. Evaluation Spezikation der Analysetiefe Abgeleitete Werte Empfehlung Abschätzung der Videoparameter H Empfehlung Architekturkonzepte für einen QoS/QoE Sensor Ausgeschlossene Varianten Standard SDK API Sockets Standard NDK API Implementierung Entwicklungsumgebung Zu implementierende Features Software Design Klassendiagramm Programmstrukturen und Abläufe Verzeichnisstruktur Grasche Oberäche SmartVideo Probe Programmablaufplan Ansteuerung Ausgabe Test und Verikation Messungen Funktion- und Ergebnistest Geschwindigkeitstest Fazit Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Inhaltsverzeichnis der CD Literaturverzeichnis 92 Inhaltsverzeichnis 4

5 Inhaltsverzeichnis A. Appendix 94 A.1. Kongurationsdatei probe.conf A.2. Logdatei Logging.log A.3. Programmablaufpläne SmartVideo Messkopf A.4. Aufnehmende Parameter A.4.1. Statische Messdaten A.4.2. Dynamische Messdaten A.4.3. Abgeleitete Daten A.5. Screenshots der Graken in der InspectionGraphicsActivity A.6. Code-Beispiele A.6.1. Performance Test-Programm SDK vs. NDK Inhaltsverzeichnis 5

6 1 Danksagung 1. Danksagung An dieser Stelle möchte ich mich besonders bei meinen Eltern und meiner Freundin bedanken, die mich während des Masterstudiums und besonders in der Phase meiner Master Thesis unterstützt haben. Vielen Dank für eure Geduld mit mir. Besonderen Dank Einen besonderen Dank an Prof. Dr.-Ing. Andreas Grebe und Prof. Dr. Carsten Vogt, die durch ihre Betreuung und ihre Hilfe diese Master Thesis erst ermöglicht haben. 6

7 2 Vorwort 2. Vorwort Im Zeitalter moderner Netzwerkinfrastrukturen und einer Konvergenz zum Next-Generation- Network (NGN)[24] oder auch ALL-IP-Network [1], werden altbekannte Dienste wie lineares Fernsehen, welches bisher über Kabel, Satellit oder Terrestrisch per Broadcast von den Sendeanstalten ausgestrahlt wurden, auf neue Übertragungsmedien portiert. Die gängigste Bezeichnung von Fernsehen, das über das Internet ausgestrahlt bzw. empfangen wird, ist Internet Protocol Television (IPTV). Mit IPTV wird im Allgemeinen die digitale Übertragung von Audiound Videosignalen mittels einer Breitbandinternetverbindung bezeichnet. Durch die Breitbandinternetverbindung (DSL) ist eine echte Interaktion mit dem Verbraucher möglich, die neue Anwendungsgebiete und Dienste, wie zum Beispiel Video-On-Demand (VoD) realisieren lässt. Zeitgleich zeichnet sich ein Trend ab, dass Endbenutzer im Internet exzessiv Plattformen wie YouTube und Vimeo als Videoportale nutzen, um den täglichen Konsum von Videomaterial nachzugehen. Auch die Entwicklung von Mobilfunktechnologien hat in den letzten Jahren enorm an Bedeutung gewonnen, sodass auch SmartPhone durch ihren technologischen Fortschritt immer mehr in der Lage sind, Video-Streaming-Dienste mobil zu nutzen. Diese multimedialen Angebote stellen groÿe Herausforderungen an die Übertragungsnetze, denn die Nutzung dieser Dienste im Mobilfunk wird oft durch den stark fehlerbehafteten Übertragungsweg gestört, wodurch die Zufriedenheit des Endbenutzers negativ beeinusst wird. Um die Ende-zu-Ende Dienstgüte zu ermitteln, müssen Netzwerk- und Video-Parameter analysiert werden, wobei die Analyse der aktuellen Video Qualität meistens sehr aufwendig und kostenintensiv ist. 7

8 3 Ziel dieser Master Thesis 3. Ziel dieser Master Thesis Im Rahmen des vom Bundesministerium für Bildung und Forschung geförderten Forschungsprojektes SmartVideo wird ein kostengünstiges Verfahren zur Qualitätsbestimmung von IPbasierten Videoströmen wie IPTV oder Video-on-Demand (VoD) entwickelt. Das IPTV Monitoring System dient zur Bestimmung der Qualität an Breitbandanschlüssen (DSL) und basiert auf ressourcenschonenden Messköpfen, die als verteiltes Messsystem eingesetzt werden können. Um die Qualität einer Videoübertragung auf einem mobilen Endgerät zu erfassen, ist eine Software nötig, die Netzwerk- und Videoparameter analysiert und eine Bewertung des Videos vornimmt. Ziel dieser Master Thesis ist es, einen QoS/QoE Monitoring Sensor (Messkopf) auf Basis eines Android SmartPhone innerhalb der SmartVideo Architektur zu entwickeln. Der Sensor soll spezische Parameter aufnehmen und eine erste Abschätzung der Qualität des Videos vornehmen. Es werden verschiedene Messverfahren evaluiert und die Android Architektur dabei untersucht, um ein geeignetes Konzept für eine Implementierung zu nden. 8

9 4 Grundlagen 4. Grundlagen Aufgrund verschiedener Implementierungen von Diensten rund um das Thema Video Streaming werden in diesem Kapitel die Grundlagen über IPTV und die Qualitätsbetrachtung von Video näher erläutert. Dabei werden technische Aspekte aufgegrien und gegenübergestellt IPTV IPTV (Internet Protocol Television) ist eine Variante von Internet-Video-Streaming. Generell ist damit die Bereitstellung aus Übertragung von Videomaterial über das Internet gemeint. Bei IPTV werden digitale TV-Inhalte (Live-Fernsehen) einem geschlossenen, dem ISP 1 bekannten Kundenkreis zugänglich gemacht. Dabei garantieren die ISPs den Kunden eine fest denierte Dienstgüte (QoS/QoE). Für den Begri IPTV gibt es keine exakte Denition, die gängigste Interpretation beschreibt die Funktion des Dienstes: IPTV bezeichnet die Übertragung von digitalen TV-Inhalten über ein geschlossenes Netzwerk des Internetproviders mit dem Transportprotokoll IP (Internet Protocol).[27] Zusätzlich muss bei IPTV noch die Aktualität des Content dierenziert werden. Dabei ist zu unterscheide zwischen den Varianten: Live-Streaming Live- bzw. Echtzeit-Fernsehen. Programme und Übertragungsverzögerung sind ähnlich dem klassischen Übertragungsweg per Satellit, Kabel oder auch Terrestrisch. On-Demand-Streaming Benutzerbezogene Dienste wie Video on Demand (VoD) und Mediatheken. Die Architektur und Protokolle für die Übertragung von beiden Streaming-Gruppen (Live, on-demand) werden unter anderem in den Dokumenten TR [11], TS [12] und in Papern[28] der Gremien ETSI und IEEE deniert. Die Übertragungsart für IPTV ist standardmäÿig Multicast, wobei für Video-on-Demand üblicherweise Unicast-Verbindungen genutzt werden. 1 ISP - Internet Service Provider - Telekom, Vodafone, Alice 9

10 4 Grundlagen Bei beiden Varianten können die Videodaten (H.264) wie folgt gekapselt werden. Abbildung 4.1.: Typische Kapselung von IPTV Videodaten in IP Aufbau Grundsätzlich besteht der Aufbau eines IPTV Dienstes aus drei Komponenten. Einem Headend für die Video Codierung, dem eigentlichen Transport-Netz des Providers (Core-IP-Netz) und dem Access Netz, das bis zum Benutzer reicht. Abbildung 4.2.: Allgemeine IPTV Streaming-Plattform Architektur In dem Headend des Providers wird zunächst das lineare Fernsehen (Broadcast-TV) vom Satellit, Terrestrisch oder per Kabelanschluss eingespeist. Dort wird das Signal passend für IPTV mit Codecs wie zum Beispiel MPEG-2 oder H.264 transcodiert und schlieÿlich in das Core-Netz des Providers mittels Multicast eingespeist. Über das Core-Netz werden die IPTV- Streams zu den Knotenpunkten im Netz verteilt. Der Empfang erfolgt über eine Set-Top-Box (STB) des Anbieters, die in der Regel an ein IAD (Integrated Access Device - DSL-Modem) 4.1 IPTV 10

11 4 Grundlagen angeschlossen wird. Ein IPTV-Kunde kann sich mittels seiner STB über die IAD mit Hilfe dem IGMP-Protokoll an der IPTV-Gruppe anmelden und den Video-Stream anfordern. Der jeweilige Video-Stream wird dann im Access Netz über Router, Switche und dem DSLAM bis zum Kunden freigeschaltet. Die Set-Top-Box decodiert den Video-Stream und zeigt das reine Videomaterial auf einem TV-Gerät an. Gängige Systeme Die drei führenden Telekommunikationsunternehmen, die auch Triple-Play 2 Angebote im Portfolio haben sind die Telekom, Vodafone und Alice. Sie alle bieten IPTV-Dienste an, welche sich hauptsächlich in Funktionen und Features unterscheiden. Die Hardware wird von allen Anbietern mitgeliefert und beinhaltet, abgesehen vom Splitter, NTBA (bei ISDN) und dem DSL- Modem, einen Media Receiver, der auf die IPTV-Plattform zugeschnitten ist. Die Telekom 3 setzt Mediaroom 2.0 von Microsoft als IPTV-Plattform ein. Dabei sind mehrere Mediaroom- Server im Backbone-Netz verteilt, die für die Auslieferung von IPTV zuständig sind. Vodafone (damals Arcor) setzte zu Beginn auf der IPTV-Plattform von Alcatel-Lucent auf. Mit dem Kauf von Arcor durch Vodafone und dem Relaunch des TV-Angebotes Vodafone-TV 2011 wurde die Plattform durch NDS Komponenten ersetzt. NDS, bekannt durch das Verschlüsselungssystem Videoguard bei Premiere (heute Sky), übernimmt die Systemintegration und das Management 4 der Plattform. Bei dem Provider Alice basieren IPTV-Plattform und dazugehörige Netzinfrastruktur auf dem System von Alcatel-Lucent 5. Für die Signalaufbereitung im Headend ist der Technikpartner Harmonic zuständig. Der Support für die STBs wird vom Produzenten Sagem übernommen. Alle Anbieter bieten seit letztem Jahr ihre Programme sowohl in Standard Denition (SD, 576i), als auch in High Denition (HD, 1080i) an. Dabei treten Datenraten bei unterschiedlichen Programmkanälen ab 2 MBit/s in SD-Qualität und ab 5 MBit/s in HD-Qualität auf. Der Durchschnitt liegt, aufgrund der Informationen die übertragen werden sollen und der Stärke der Komprimierung, bei circa 3 MBit/s bei SD-Qualität und 6 MBit/s bei HD-Qualität. Durch die HD Angebote werden die Triple-Play Dienste mit Ausnahme von Vodafone nur ab einer DSL-Bandbreite von 16 Mbit/s zugelassen. 2 Triple-Play - Internet, Telefon, TV über einen DSL-Anschluss 3 Quelle: 4 Quelle: 5 Quelle: IPTV 11

12 4 Grundlagen Im folgenden werden die Informationen zu den einzelnen Provider in einem IPTV Systemvergleich zusammengefasst. IPTV Provider Systemvergleich Telekom Vodafone Alice Markteinführung System Microsoft TV IPTV Alcatel-Lucent (07-09) Alcatel-Lucent Vodafone-TV NDS (ab 2010) Kapselung IP/UDP/RTP IP/UDP IP/UDP Hardware Media Receiver 300 NDS Sagem ITAD84 Media Receiver 301 (Sagemcom ST-7105) Sagem ITAD83 Media Receiver 303 Datenrate SD ca. 3,7 MBit/s ca. 3,16 MBit/s ca. 2,5 MBit/s Datenrate HD ca. 5-8 MBit/s ca. 5-8 MBit/s ca MBit/s Video-on-Demand ja ja ja Access-Netz ADSL+ (16M) ADSL+ (6M), (16M) ADSL+ (16M) VDSL 25, 50 VDSL 50 VDSL 10, 50 Tabelle 4.1.: Systemvergleich der führenden Telekommunikationsunternehmen zu IPTV Codec Wie in den vorherigen Kapitel beschrieben, müssen die Videodaten, die vom Satellit oder von den Sendeanstalten kommen, für IPTV transcodiert werden. Das Transcoding beschreibt das Umrechnen von, in diesem Fall, Bildinformationen eines Videos mit einem speziellen Algorithmus zur Bildkompression, dem sogenannten Video-Codec. Ein Videostream, der vom Satellit oder einer Sendeanstalten kommt, weist eine zu hohe Datenrate auf, die nicht ezient gestreamt werden kann. Ein Video-Codec encodiert ein Video und reduziert die Datenrate erheblich, indem redundante Informationen gelöscht werden. Die codierten Daten werden bis zum Benutzer gestreamt und dort wieder decodiert. Durch das Decodieren werden die Bilddaten wieder rekonstruiert. Beim Codieren werden nicht alle Informationen einen Bildes gespeichert, sondern nur deren Dierenz zu vorherigen und nachfolgenden Bildern. Der Ursprung liegt im JPEG-Standard, der verlustbehaftete Mechanismen zur Bildkompression beschreibt. Wie dieser basieren die meisten Codecs auf einer DCT (Diskrete Cosinus Transformation) oder einer Integer-Transformation in Kombination mit einer Konvertierung und anschlieÿenden Quantisierung. 4.1 IPTV 12

13 4 Grundlagen Der erste Schritt des Codierers ist die Konvertierung des Videos. Dabei wird das Video zunächst in seine Einzelbilder zerlegt und in einen Farbraum (Farbmodell). Die gängigsten Farbmodelle sind: 1. YCgCo Farbraum-Modell für H.264, einem der gängigsten Codecs für Videokomprimierung[27]. Das gesamte Bild wird dabei in das Helligkeit-Farbigkeit-Modell umgewandelt, das durch die Luminanz Y, die Abweichung Chrominanz C von Grau zu Grün (Cg) und Grau zu Orange (Co) beschrieben wird. 2. YCbCr Ähnlich dem Farbraum-Modell für H.264, jedoch beschrieben durch die Chrominanz von Grau zu Blau (Cb) und Grau zu Rot (Cr). Wird überwiegend verwendet für DVB, MPEG und DVD-Video. 3. CMYK Subtraktives Farbgrundmodell für Bildverarbeitung, Desktop Publishing und Druck. Basierend auf den Farbanteilen Cyan (C), Magenta (M), Yellow (Y) und Schwarz (K, Keyvalue), die übereinander gelegt das Bild ergeben. 4. RGB Additives Farbgrundmodell für Computersysteme, Monitore und Webdesign. Farbzusammensetzung der Grundfarben Rot (R), Grün (G) und Blau (B). Durch mischen der Grundfarben werden auf Basis der Dreifarbentheorie alle Farbwerte erreicht und damit ein Bild in allen Farben deniert. Nach einer Rasterung des Bildes zu Blöcken unterschiedlicher Pixelgröÿen (4x4, 8x4, 4x8, 8x8, 16x8, 8x16, 16x16) werden die Informationen als Vektor, bestehend aus Koezienten, interpretiert. Um an die Koezienten zu gelangen, müssen die Pixelwerte der Blöcke abhängig vom Codec errechnet bzw. gewichtet werden. Mit nachstehender Formel erhält man eine Matrix mit Koezienten aus den Pixelwerten der einzelnen Blöcke des Bildes. d m,n = 1 4 c m c n 7 i=0 7 j=0 ( ) ( ) (2i + 1)mπ (2j + 1)nπ a ij cos cos Nach der Umrechnung der Werte in die Frequenzbereiche zeichnen sich groÿe Flächen in niederfrequente und feine Details in hochfrequente Bereiche ab. An dieser Stelle nutzt man die Schwächen des menschlichen Auges und ltert die hohen Frequenzen heraus, die nicht wahrgenommen werden können. Die daraus resultierenden Koezienten, die nicht Null sind, werden durch Division durch eine Ganzzahl quantisiert. Damit eine stärkere Komprimierung erreicht werden kann, muss eine groÿe Ganzzahl als Divident eingesetzt werden, sodass noch mehr Koezienten gegen Null streben. Dieses geht jedoch zu Lasten der Bildqualität. 4.1 IPTV 13

14 4 Grundlagen Die Standard-Codecs für Videostreaming sind MPEG-4/AVC H.264 und MPEG-2, da sie einen hohen Verbreitungsgrad aufweisen und von zahlreichen unterschiedlichen Plattformen unterstützt werden[27]. MPEG-2 ist der de facto Standard für Videomaterial im Bereich Fernsehübertragung (DVB-T, DVB-S, DVB-C) und DVD-Medien. Entstanden 1994 etablierte er sich durch hohe Ezienz und geringe Datenrate. Abgelöst wurde dieser Codec 2007 vom Nachfolger MPEG-4/AVC (Advanced Video Coding) H.264 der sich zum neuen internationalen Standard durchsetzte. Er besitzt eine dreimal gröÿere Ezienz als sein Vorgänger und ermöglicht nochmals eine bessere Qualität bei geringerer Datenrate. Video Codecs H.264 MPEG-2 Entstanden Einsatzbereich IPTV, Blu-Ray DVD DVB-T2,-S2,-C2 DVB-T,-S,-C Auösung Min Mbit/s Mbit/s Auösung Max 960 Mbit/s 300 Mbit/s Bildtypen I-,P-,B-,SI-,SP-Slices I-,P-,B-Frames Transformation DCT, Integertransformation DCT Tabelle 4.2.: Gegenüberstellung der Codecs H.264 und MPEG-2 Es gibt darüber hinaus noch eine Vielzahl von verschiedenen Codecs für unterschiedliche Einsatzbereiche. Flash ist unter anderem mit dem von On2-Technologies entwickeltem VP6-Codec ausgestattet, dessen Codierqualität für Kurzlme ausreichend ist und der Standard von Video- Portalen wie Youtube darstellt. Der Suchmaschinenanbieter Google entwickelte Ende 2009 das WebM-Projekt und stellte den Videocodec VP8, welcher ebenfalls von On2-Technologies entwickelt wurde, unter eine quelloene Lizenz. Dieser behauptet sich auch auf dem Markt für Streaming-Anwendungen, ist jedoch nicht weit verbreitet Container Wie im vorherigen Kapitel beschrieben, werden Videodaten mit Hilfe eines Codecs komprimiert. Allerdings bestehen Videos nicht nur aus Bildmaterial, sondern auch aus Audio-Daten und zusätzlichen Informationen zum Video. Diese Informationen müssen ezient in einer Datenstruktur abgelegt sein, damit das Video sowohl abgespielt, als auch über das Netzwerk gestreamt werden kann. Die sogenannten Container kapseln alle Informationen ezient in einer Datenstruktur als Datei. Dabei werden die unterschiedlichen Inhalte innerhalb des Containers gruppiert und mit Header Informationen (Kopfdaten) abgelegt. 4.1 IPTV 14

15 4 Grundlagen Ein typischer Container für Videoinhalte stellt der AVI-Container für MPEG-2 oder auch der MP4-Container für MPEG-4/AVC H.264 dar. Diese beiden Container fassen verschiedene Inhalte in einer Datei zusammen. Es werden diverse Header Informationen zum Video hinzugefügt, damit eine Abspielsoftware das Video anzeigen kann. Der eigentliche Inhalt, die Video und Audiodaten, werden in der Regel gemultiplext abgelegt. Abbildung 4.3.: Schemata der AVI- und MP4-Container im Vergleich Ein Abspielen des Videos bei der Übertragung des Containers über das Netzwerk ist nur dann möglich, wenn der Container als Datei komplett übertragen wird, da wichtige Information zum decodieren sich unter Umständen am Ende des Containers benden. Da je nach Dateigröÿe das nicht möglich ist, müssen die Videodaten in einen, für die Netzwerkübertragung geeigneten, Container gekapselt werden. Der Container für Video-Streaming in einem IP-Netz ist, wie in Abbildung 4.1 zu sehen, MPEG-TS. MPEG-TS (MPEG Transport Stream - ISO/IEC ) dient als Transportprotokoll für Audio, Video und Daten. Es wird gekapselt in Ethernet, IP, UDP und eventuell RTP und beinhaltet die gemultiplexten Daten aus den Objekten movi (MPEG-2) und mdat (H.264) [16][17]. MPEG-TS Pakete sind 188 Byte 6 groÿ und enthalten einen 4 Byte groÿen Standard-Header. Es können aufgrund der MTU Gröÿe für Ethernet- Rahmen, in der Regel 1500 Byte, maximal sieben MPEG-TS Pakete in einem Ethernet-Rahmen verschickt werden. 6 Eine Paketlänge von 188 Byte stammt aus der Zeit der ATM Systeme 4.1 IPTV 15

16 4 Grundlagen Der 4 Byte groÿe Standard-Header sieht wie folgt aus: SYNC-Byte 0x TError Payload Prio PID PID TSC AFC Zähler MPEG-TS kann durchaus noch weitere Header enthalten, die durch Flags signalisiert werden. Ein Beispiel hierfür ist das Feld AFC (2 Byte) - Adaptation Field Control - das bei den Binärwerten 10 und 11 einen weiteren Header signalisiert. Diese zusätzlichen Header sind optional und werden hier als Payload betrachtet. Werden keine zusätzlichen Header signalisiert, beinhaltet das MPEG-TS Paket bis zu 184 Byte Nutzdaten des Typs Video, Audio oder Daten. Wie im vorherigen Abschnitt erläutert, werden die Daten bei einem MPEG-2 codierten Video aus dem Objekt movi extrahiert und als Payload verpackt. Zusätzliche Informationen über das Bild (Frame), wie zum Beispiel der Type (I-,P-,B-Frame), Zeitstempel und Codec werden als MPEG Picture Header vorangestellt. Bei einem H.264 codierten Video sind die Daten losgelöst in einem VCL 7 innerhalb des mdat-objektes abgelegt, um eine maximale Flexibilität und Vielfältigkeit an Einsatzbereichen zu ermöglichen. Sollen die Videodaten in dem Container gestreamt werden, muss der VCL (mdat-objekt) in die nach ISO/IEC [15] standardisierten Network Abstraction Layer (NAL) Units gepackt werden. Die NAL Units liefern Headerinformationen für das Video und die Netzwerkübertragung gleichermaÿen. Ein typischer Aufbau eines NAL-Header sieht wie folgt aus: 1 Bit 3 Bit 8 Bit F NRI Type F beschreibt das Forbidden_zero_bit, NRI (NAL Reference Indicator) gibt an, ob eine fragmentierte oder referenzierte NAL vorliegt und der Inhalt der NAL-Unit wird mit dem Feld Type signalisiert. Der NAL enthält wiederum sogenannte Header-Informationen wie SPS 8 und PPS 9. Die wichtigste Eigenschaft des NAL ist seine vielseitige Verwendungsmöglichkeit, durch die er VCL-Inhalte unterschiedlichen Übertragungsschichten (Transport Layers - Ethernet, DVB) zugänglich machen kann. [15] 7 VCL - Video Coding Layer - Enthält Video, Audio und Dateninformationen 8 SPS - Sequenz Parameter Set - Deniert eine Reihe von aufeinanderfolgenden codierten Bildern 9 PPS - Picture Parameter Set - Deniert, wie einzelne unabhängige Bilder dekodiert werden 4.1 IPTV 16

17 4 Grundlagen 4.2. Qualitätsbetrachtung von Video Ein Video, das sowohl über den klassischen Übertragungsweg als auch über IP-Techniken ausgeliefert wird, lässt sich solange zufriedenstellend betrachten, wie keine Störungen auftreten. Bei NGN Anschlüssen und den neuen Triple-Play-Angeboten der Internet Service Provider (ISP), müssen Video, Telefon und Internetverbindungen über die gleiche DSL-Leitung transportiert werden. Treten dabei Störungen auf, mindern diese Fehler die Qualität des Dienstes. Dabei stellt ein Groÿteil des reinen IP-Netzes nicht das Problem dar, sondern vielmehr das Access-Netz (DSL - Last-Mile, 3G/4G - Funkverbindung) bis zum Benutzer. Die häugsten Probleme bei den Zugangstechniken sind Paketverlust, Verzögerungen und Verzögerungsschwankungen, hervorgerufen durch instabile Verbindungen, wie zum Beispiel eine unzureichende Netzverbindung (Funkloch) im Mobilfunk. Provider haben die Möglichkeit sich verschiedene Mechanismen zur Sicherstellung der Qualität nutzbar zu machen. Quality of Service (QoS), auch Dienstgüteverfahren genannt, ist ein Oberbegri für die Aufrechterhaltung der Qualität von verschiedenen Diensten. Dieser gilt auch für unterschiedliche Datenübertragungsarten und beschreibt die Art, Echtzeitdienste wie VoIP und IPTV bevorzugt zu übertragen. Mit einer Analyse der QoS-Parameter, durch das Betrachten von Paketverlustraten oder Verzögerungen bei der Paketvermittlung, sind die Diensteanbieter bzw. Provider in der Lage mit Systemen wie PSS (Packet Switched Streaming Service) oder MBMS (Multimedia Broadcast Streaming Service) eine bestimmte Qualität für IP- Videostreaming sicherzustellen [6]. Diese Art der messtechnischen Auswertung der Quality-of-Service ist eine rein objektive Analyse und gibt lediglich den Sachverhalt im Netz wieder. Eine weitere Möglichkeit zur Abschätzung der Qualität wird durch den Endanwender ermöglicht. Dabei wird die Quality-of- Experience als Dienstgütemaÿ für das subjektives Empnden herangezogen. In den folgenden Abschnitten werden die QoS- und QoE-Parameter für IP-Netze genauer betrachtet Quality of Service Die Dienstgüte (Qos) beschreibt die Qualität einer Datenübertragung. Diese hängt von vielen verschiedenen Parametern ab. Unterschiedliche Dienste stellen unterschiedliche Anforderungen an ein Transportnetz. Für die Realisierung eines qualitativ zufriedenstellenden Dienstes müssen zum Beispiel die im Folgenden erläuterten Parameter unterhalb eines für den jeweiligen Dienst akzeptablen Bereichs liegen. Zum Beispiel sollte der Paketverlust (Packetloss) für Video-Streaming einen maximalen Wert von 0,5 Prozent nicht überschreiten, um signikante Störungen zu vermeiden. 4.2 Qualitätsbetrachtung von Video 17

18 4 Grundlagen Bandwidth Allocation Die für das Erbringen eines Dienstes notwendige Kapazitätsauslastung wird durch den Dienst vorgegeben. Je nach Anwendung kann die Auslastung unterschiedlich hoch sein. Die Kapazitätsauslastung ist beispielsweise bei einem VoIP-Gespräch wesentlich niedriger als beim Übertragen eines Full-HD Videos oder einem Dateidownload. Die beteiligten Netzelemente müssen diese Auslastung ohne Verluste transportieren können. Delay Die Laufzeit ist die Summe aller Verzögerungen auf der Übertragungsstrecke. Durch die Länge der an einer Datenübertragung beteiligten Leitungslängen gibt es eine Grundlaufzeit RTT 10 für jedes Paket. Auf diese Mindestlaufzeit addieren sich weitere Zeiten, die das Delay erhöhen. Bei steigender Last kann die Verarbeitungsdauer in Netzelementen zusätzlich ansteigen. Jitter Verzögerungsschwankungen innerhalb des Paketabstands werden als Jitter bezeichnet. Diese Schwankungen können durch Varianzen der Laufzeit entstehen. Packetloss Paketverluste werden durch Überlastsituationen und bei einer fehlerhaften Übertragung (Bitfehler, Packet Error) verursacht. Natürlich gibt es zur QoS-Bestimmung noch weitere Parameter, wie die Analyse der Endezu-Ende Prioritätssteuerung im Netz und die generelle Verfügbarkeit eines Dienstes, die sich positiv auf die Qualität des zu untersuchenden Dienstes auswirken kann. Die Standardisierer ITU-T und 3GPP haben im Bereich Festnetz und Mobilfunk eine Reihe von Qualitätsklassen deniert, mit denen es möglich ist, Videostreams oder auch VoIP-Verkehr zu priorisieren, um Verzögerungsschwankungen und Paketverluste zu minimieren. Im folgenden sind für den Mobilfunk von der 3GPP die QoS-Klassen deniert[2]: QoS-Klassen im Mobilfunk (NGMN) 1 Conversational Für direkte Kommunikation (Telefonie, Video-Konferenzen) 2 Streaming Verteildienste mit Mindestbandbreite (IPTV) 3 Interactive Nutzung interaktiver Dienste 4 Background Datentransfer mit geringer Fehlerrate Tabelle 4.3.: QoS-Klassen für die Priorisierung von Paketen im Mobilfunk (NGMN) Die Streaming-Klasse stellt für Videodienste wie IPTV eine geeignete Klasse dar.[5] 10 RTT - Round Trip Time - Absolute Zeit für das Verschicken eines Paketes bis zum Empfang der Antwort von der Gegenstelle 4.2 Qualitätsbetrachtung von Video 18

19 Master Thesis Dipl.-Ing. Stephan Kü ner 4 Grundlagen Quality of Experience Die Quality-of-Experience basiert auf dem subjektivem Emp nden von Nutzern, da eine reine Bewertung des Videomaterials anhand der QoS-Parameter das Qualitätsemp nden nicht im ausreichenden Maÿe wiedergibt. Deutlich wird dies beim Vergleich einer VoIP-Übertragung mit einem Video Streaming. Wird nur der Paketverlust bei VoIP betrachtet, wird klar, das bei einer Fehlerrate von 1% Prozent die VoIP-Kommunikation das subjektive Emp nden nicht mindert[3]. Bei Videostreaming hingegen hat die resultierenden Störungen des Bildes massive Einwirkungen. Deutlich wird die Auswirkung des Paketverlusts bei Betrachtung der folgenden Abbildungen. Abbildung 4.4.: H.264 Full HD bei 0% Prozent Abbildung 4.5.: H.264 Full HD bei 1% Prozent Paketverlust. Quelle: [5] Paketverlust. Quelle: [5] Abbildung 4.4 zeigt ein Bild eines Videos, welches bei optimalen Bedingungen gestreamt wurde. Die Datenrate dieses Videos beträgt 6 MBit/s und ist in MPEG-4/AVC H.264 in der Au ösung 1920x1080 (Full-HD) codiert. Abbildung 4.5 zeigt dagegen das gleiche Bild bei 1% Prozent Paketverlust mit deutlichen Bildstörungen wie Block- und Schlierenbildungen. Wesentlich für die wahrgenommene Qualität eines Videos ist neben der Stärke der Bildstörung auch der Fehler beim Dekodieren des Videos und die daraus resultierende Dauer der Fehlersituation Verfahren zur Bestimmung der Qualität Die für die Videoqualität entscheidenden Parameter lassen sich in verschiedene Kategorien einteilen. Eine groÿe Gewichtung bei der Bestimmung der Videoqualität haben Parameter der Netzwerkebene bzw. Transportschicht. Zusätzlich werden noch die Videoparameter mit einbezogen, da sie einen Aufschluss über die Art des Video und den Inhalt der Pakete geben und einen erheblichen Ein uss auf die Videoqualität haben. Wie im vorherigen Abschnitt beschrieben, sind typische QoS-Parameter auf der Netzwerkebene Paketverlust und Jitter. Beim Jitter, der die Verzögerungsschwankung der Pakete darstellt, 4.2 Qualitätsbetrachtung von Video 19

20 4 Grundlagen führen groÿe Schwankungen zu Paketverlust, da die Informationen vom Decoder nicht mehr verwendet und verworfen werden. Bei einem reinen Paketverlust gehen Daten des Videos verloren. Durch Aufzeichnen der empfangenen Pakete und z.b. Analyse der Sequenznummern kann ein Paketverlust detektiert werden. Sinnvoll ist es zudem an dieser Stelle Art und Dauer des Paketverlusts zu untersuchen, da ein einzelnes verlorenes Paket weniger Auswirkungen hat als eine Reihe von fehlenden Paketen (Burstloss). Sind alle möglichen Parameter analysiert, kann eine erste Bewertung der Qualität vorgenommen werden. Um weitere und genauere Ergebnisse zu erhalten, muss an dieser Stelle eine Betrachtung des Videomaterials mit einbezogen werden. Dabei lassen sich drei grundlegende Methoden unterscheiden: Full-Reference Reduced-Reference Non-Reference Full-Reference Abbildung 4.6.: Full-Reference-Verfahren (FR) Grundsätzlich gehört der Full-Reference-Ansatz (FR) zu den objektiven Metriken zur Analyse von Videodaten. Dabei basiert der Full-Reference-Ansatz auf dem Vergleich zwischen einem originalen Video, das ungestört vorliegen muss (Referenz) und einem gemessenen Video, welches Störungen enthalten kann. Eine gängige Berechnungsvariante für den FR-Ansatz ist der PSNR (Peak-Signal-to-Noise Ratio). Dabei wird üblicherweise ein Pixel-zu-Pixel Vergleich durchgeführt und Dierenzen gebildet. Je Gröÿer die Dierenz, desto fehlerbehafteter ist das gestörte Bild zum Referenzbild. Dieses Verfahren schützt allerdings nicht vor Wahrnehmungsverzerrungen und kann Abweichungen zum subjektiven Wahrnehmen nicht berücksichtigen. 4.2 Qualitätsbetrachtung von Video 20

21 4 Grundlagen Etwas genauer ist das SSIM-Verfahren (Structual Similarity), welches die Bilddaten in Luminanz, Kontrast und Struktur aufsplittet und mit dem Referenzsignal vergleicht. Aufgrund ihrer Berechnungen des Bildmaterials müssen vorher die Daten dekodiert werden, damit sie anschlieÿend analysiert werden können. Ein pixelweiser Vergleich der Bildinformationen erfordert einen sehr hohen Rechenaufwand. Zudem muss zusätzlich bei jeder Messung am Messpunkt das Referenzsignal vorhanden sein, damit eine Live-Messung durchgeführt werden kann. Da ein Referenzsignal in den meisten Fällen nicht verfügbar ist, ist der FR-Ansatz somit überwiegend für den punktuellen Einsatz ausgelegt.[6][23] Ein bekannter Algorithmus zur Bestimmung der Qualität von Video stammt von Opticom. Standardisiert wurde PEVQ er von der ITU-T im Dokument J.247 Objective Perceptual Multimedia Video Quality Measurement in the Presence of a Full-Reference [19] und dient als Stand der Dinge im Bereich Full-Reference Messungen. Die Firmen Opticom und JDSU bieten in ihren Produkten PEXQ (Opticom) und IP-Video Test (JDSU) eine Videoanalyse an, die auf dem Algorithmus PEVQ basiert, jedoch keine Live-Messungen bzw. Live-Monitoring ermöglicht. Ein Beispiel eines Full-Reference basierten Video Analyse Tools der Firma AccepTV zeigt die folgende Abbildung. Sie zeigt das Tool VQA2 im Messmodus, wobei auf der linken Seite das Referenzbild und auf der rechten Seite das zu messende Bild zusehen ist. Abbildung 4.7.: Beispiel des Full-Reference Analyse-Tools Video Quality Analyser der Firma AccepTV. (Quelle: AccepTV - VQA2) 4.2 Qualitätsbetrachtung von Video 21

22 4 Grundlagen Reduced-Reference Abbildung 4.8.: Reduced-Reference-Verfahren (RR) Der Reduced-Reference-Ansatz (RR) ist dem FR-Ansatz ähnlich. Er unterscheidet sich von ihm darin, das nur Teilinformationen des Referenzbildes benötigt werden. Die daraus gewonnenen Informationen werden mit dem zu messenden Bild verglichen und damit eine Qualitätsbewertung vorgenommen. Ein Beispiel für eine Implementierung des RR-Ansatzes zeigt das National Telecommunications and Information Administration (NTIA) mit dem General Video Quality Model (General VQM) und dem 10kbit/s RR-Model. Das General VQM ist das von der VQEG (Video Quality Expert Group) für Tests standardisierte Full-Reference Messsystem, das im Fall des RR- Ansatzes nur Full-Reference Teilinformationen mit einer Datenrate von 10 kbit/s erhält. Die daraus resultierenden Messungen weichen nur gering von denen einer FR-Messung ab, erlauben aber die Möglichkeit von Live-Monitoring Szenarien. [14] Non-Reference Abbildung 4.9.: Non-Reference-Verfahren (NR) 4.2 Qualitätsbetrachtung von Video 22

23 4 Grundlagen Das letzte Verfahren ist der Non-Reference-Ansatz (NR) zur Bestimmung der Quality-of- Experience von Video. Bei diesem Verfahren wird auf den Vergleich mit fehlerfreiem Bildmaterial verzichtet und eine Abschätzung der Qualität durch Evaluation einer Deep Packet Inspection und Vergleich mit verizierten Messungen vorgenommen. Bei einer Deep Packet Inspection werden ähnlich dem Verfahren zu Bestimmung der QoS die Parameter aus dem Video extrahiert. Dabei werden in erster Linie die Parameter des MPEG- Transport Stream analysiert. Anschlieÿend werden die Daten aus dem Video-Header herangezogen. Für die im MPEG-TS Header vorhanden Parameter wird im ETSI-Standard TR [10] eine Gewichtung der Parameter nach ihrer Wichtigkeit dokumentiert. Man unterscheidet drei Prioritätsstufen, die für eine Analyse des Videos maÿgeblich sind: 1. First Priority Parameter der First Priority sind für die Dekodierbarkeit des Videos notwendig. Anhand dieser Parameter wird festgelegt, ob genügend Informationen zur Verfügung stehen, um das Video zu synchronisieren, zu dekodieren und anschlieÿend anzuzeigen. Ein Beispiel aus dieser Prioritätsstufe ist der PAT_Error. Er beschreibt die Anzahl der Fehler, wenn eine PAT (Programm Association Table) nicht korrekt gesendet wurde. Erfasst wird auch, wenn eine PAT nicht alle 0,5 Sekunden eintrit. 2. Second Priority Parameter der Second Priority werden für eine Überwachung des Videostroms benötigt. Diese Informationen sind für die Steuerpakete mit PTS und PCR. Diese sollen in regelmäÿigen Abständen empfangen werden, sind aber nur bedingt notwendig. Tritt ein Fehler auf, wird er in dieser Prioritätsstufe erfasst. 3. Third Priority Parameter der Third Priority decken anwendungsbezogene Parameter ab. Diese Informationen sind pro Anwendung spezisch zu betrachten. Ein Beispiel dieser Prioritätsstufe ist der Fehlerzähler beim Überlauf des Abspielpuers einer Videoabspielsoftware. Zusätzlich werden auch Parameter wie Bildtyp (I-,P-,B-Slice), Auösung und Codec aus dem Bildmaterial ausgelesen, um weitere Informationen über das Video zu erhalten. Diese Parameter, welche die Videoeigenschaften beschreiben, in Kombination mit subjektiven Messverfahren nach BT.500 [21] ermöglichen die Generierung eines qualitativen Messergebnisses zur Qualitätseinschätzung [6]. Diese Messergebnisse lassen sich in einer Skala von 1 bis 5 durch einen Mean Opinion Score (MOS) repräsentieren. Der Mean Opinion Score gehört unter anderem zu den subjektiven Metriken. 4.2 Qualitätsbetrachtung von Video 23

24 4 Grundlagen Vergleichsanalyse In der nachstehenden Tabelle sind die gängigsten IPTV-Monitoring Systeme zu den Verfahren Full-Reference, Reduced-Reference und Non-Reference einander gegenüber gestellt. Die PEVQ basierenden Systeme im Bereich Full-Reference haben, was deren Aussagekraft der Messergebnisse betrit einen Vorteil, da PEVQ standardisiert ist. Untereinander sind diese Systeme bei der Bewertung der Qualität identisch. Bei den Non-Reference Verfahren wird deutlich, je weniger Informationen über das Referenzsignal zur Verfügung stehen, desto ungenauer können die Messergebnisse werden. Bei einem Non-Reference Verfahren lassen sich zusätzlich Funktionen wie zum Beispiel ein Live- Monitoring oder verteilte und ferngesteuerte Messköpfe realisieren, die vielfältige Einsatzmöglichkeiten darbieten und weitere Randbedingungen zur Messung liefern können. In erster Linie werden QoS-Parameter betrachtet, jedoch lassen sich, wie im vorherigen Abschnitt beschrieben, diese Messergebnisse aber gegen subjektive Messungen nach BT.500 veri- ziert um eine genauere Einschätzung der Qualität zu erhalten. 4.2 Qualitätsbetrachtung von Video 24

25 4 Grundlagen Pro und Contra Full-Reference, Reduced-Reference und Non-Reference Produkt Ansatz Pro Contra PEXQ (Opticom) FR - Exakte - kein Live-Monitoring PEVQ Fehlerbestimmung - Hohe Rechenleistung IP Video Test (JDSU) - Standardisiert - Hohe Kosten VQLab (Semaca) - Dekodieren des Videos diversifeye (Shenick) erforderlich General VQM (NTIA) RR - Relative genaue - Hohe Kosten PEVQ Fehlerbestimmung - Dekodieren des Videos (besser als NR) erforderlich - Standardisiert TestCenter (Spirent) NR - Netzwerk Tests - Kein Live-Monitoring V-Faktor - Messungen ungenauer als FR und RR - Hohe Kosten VQS (Telchemy) NR - Live-Messungen - Messungen ungenauer WatchiTV WT-600 V-Faktor - Geringe Ressourcen als FR und RR (AnaCise Technology) - Analyse der Parameter - kein BT.500 nach TR Verteilte ferngesteuerte Messköpfe SmartVideo (FH-Köln) NR - Geringe Ressourcen - Messungen ungenauer - Live-Messungen als FR und RR - Netzwerk Tests - Analyse der Parameter nach TR BT.500 Verizierung - Verteilte ferngesteuerte Messköpfe Tabelle 4.4.: Vergleich der einzelnen Referenz-Verfahren 4.2 Qualitätsbetrachtung von Video 25

26 5 SmartVideo Systemansatz 5. SmartVideo Systemansatz 5.1. Vorstellung Im Forschungsprojekt SmartVideo wird eine prototypische Implementierung eines ächendeckenden Messsystem zur Analyse der subjektiven Qualität von Videos entwickelt[4]. Es arbeitet nach dem Non-Reference-Verfahren (NR), da es kein Referenzmaterial zu Analyse benötigt und bietet somit kosten- und ressourcenschonende Messköpfe, die vom Backbone- oder Core- bis hin zum Access-Netz im kompletten Netzwerk verteilt werden können. Diese Messköpfe detektieren die gestreamten Videos und bestimmen die Qualität nach objektiven und subjektiven Gesichtspunkten. Aus den Messergebnissen wird ein Mean Opinion Score (MOS) bestimmt, der die Faktoren einer Quality-of-Experience nach ITU-T G.1080[20] und dem DSL Forum TR 126[9] berücksichtigt. Abbildung 5.1.: Aufbau des SmartVideo Messsystem mit 2 Messköpfen 26

27 5 SmartVideo Systemansatz Das Messsystem ist im Kern überwiegend in C++ geschrieben und besteht aus vier Komponenten: Probe (Messkopf) Der Messkopf ist als Multithreading Light Weight Probe konzipiert worden und soll einen kosten- und ressourcenschonenden Flächeneinsatz ermöglichen. Das Kernkonzept ist eine transparente Netzwerkbrücke, die den kompletten Netzwerkverkehr an der Netzwerkkarte, angefangen von der OSI-Schicht Layer 2, aufzeichnet und eine Analyse der Paketdaten bis hin zur Applikationsschicht durchführt (Deep-Packet-Inspection - DPI). Bei einer Messung werden die einzelnen Pakete getaggt und anschlieÿend analysiert. Der Probe kann sowohl als Endpunkt als auch als Netzwerkbrücke im Netz arbeiten. Die Paketdaten sind Rohdaten, die unverändert vom Messkopf angenommen und OSI-Schicht für OSI-Schicht geparst werden. Dabei werden denierte Datenstrukturen (Header-Strukturen) auf die Daten angewendet um die Informationen zu extrahieren. Sind alle messtechnisch notwendigen Parameter extrahiert worden, werden die Daten verdichtet in einer CSV-Datei (Comma Separated Value) im lokalen Dateisystem abgelegt. Ein Verdichten der Daten wird erreicht, indem sich wiederholende Informationen nicht permanent speichert werden, sondern nur sich ändernde Daten. Eine Analyse der Qualität der Video-Streams ndet an dieser Stelle nicht statt. Daemon Der Daemon wurde für die Weiterverarbeitung der Messdaten, das Einsammeln der CSV- Dateien der Messköpfe und Übertragen der Informationen in eine einheitliche Datenbank, konzipiert. Das Einsammeln der CSV-Dateien geschieht über gesicherte bzw verschlüsselte SSH- Verbindungen, die auf dem System des Daemons lokal ins Dateisystem eingehangen 1 werden. Mit dem ächendeckenden Einsatz von Messköpfen ist ein steigender Aufwand für das Einsammeln der Daten verbunden. Innerhalb des Daemons wird daher ein Round-Robin-Verfahren mit einem Algorithmus zum Pollen der Messköpfe zur Lastsenkung angewendet. Eine Analyse der Qualität der Video-Streams ndet an dieser Stelle auch nicht statt. Managementsystem Das Managementsystem ist ein datenbankbasiertes Webfrontend zur Auswertung und Analyse der vom Messkopf gesammelten Daten. Das Managementsystem dient der Konguration und Steuerung der Messköpfe. Des Weiteren kann zusätzlich noch eine erste Auswertung der Daten durchgeführt werden. Diese Auswertung liefert eine Abschätzung der Quality-of-Service 1 Persistent gemounteter Remote-Ordner mit Hilfe der SSH-Fuse Bibliothek 5.1 Vorstellung 27

28 5 SmartVideo Systemansatz im zu messenden Netzwerk. Tiefer gehende Auswertungen, gerade im Bereich Deep Packet Inspection werden in einer Statistik zusammengefasst. Das Verizieren der gesammelten Daten nach ITU-R BT.500 [21] mit der im Forschungsprojekt erstellten Wissensdatenbank ist möglich. Eine Bestimmung der Quality-of-Experience ist mit der Berechnung eines Mean Opinion Score (MOS) nach ITU-T P.800 [18] durchzuführen. Abbildung 5.2.: SmartVideo Managementsystem Analysesystem Für eine genauere Auswertung eines Video-Streams steht das Analysesystem zur Verfügung. Das in Java programmierte System bedient sich der zur Verfügung stehenden Daten aus der Datenbank des Managementsystems. Mit Hilfe der erfassten Daten und weiterer Randbedingungen (Umfeldparameter wie Anschlussleitung, Bildschirmgröÿe des Endgeräts, etc.) wird mittels eines denierten Algorithmus eine Quality-of-Experience bestimmt und als Video Mean Opinion Score (V-MOS) ausgegeben. 5.1 Vorstellung 28

29 5 SmartVideo Systemansatz Abbildung 5.3.: SmartVideo Analysesystem 5.1 Vorstellung 29

30 5 SmartVideo Systemansatz 5.2. Analyse des Messkopfes Ziel dieser Master Thesis ist es, einen QoS/QoE Monitoring Sensor auf Basis eines Android SmartPhone zu entwickeln, der sich vollständig in das SmartVideo System integriert. Dazu muss zunächst analysiert werden, welche Funktionen der momentan aktuelle Messkopf (Stand Juli Version 0.8) hat, und wie dieser aufgebaut ist Messungen Der Messkopf läuft als Hintergrundprozess wartend auf dem System. Eine Messung wird initialisiert, indem eine Datei mit dem Namen probe.conf auf dem Messkopf im Verzeichnis /tmp/sv_probe/ erstellt wird, die folgende Parameter enthalten muss. 1 #General S e t t i n g s 2 #Measurement ID 3 i d=9e d 9 d e e f d 0 7 f c b d b 4 f f a c b 4 5 #Serialnumber Probe 6 s e r i a l =9M5CUEYV 7 8 #Input I n t e r f a c e 9 i n t e r f a c e=eth #Duration of the Measurement in [ us ]. 0 = endless 12 running_time = #IP Adresse f o r Delay Timing 15 delay_host = #Buffer f o r reordering RTP 18 b u f f e r _ s i z e = #Verbose Level 1 >less, oo >more 21 v e r b o s e _ l e v e l= #Layer 24 #Parameter on Layer t r a n s p o r t _ l a y e r= #Parameter on Layer a p p l i c a t i o n _ l a y e r =1 Listing 5.1: Kongurations-Datei probe.conf des Messkopfes für eine Messungen In dieser Kongurationsdatei werden die Grundeinstellungen für eine Messung vorgenommen. Zu diesen Parametern zählen unter anderem die Messdauer, die Netzwerkschnittstelle und die Angabe der Aufzeichnungstiefe für eine Messung. Der Parameter, der sich von Messung zu Messung ändern muss, ist die ID. Dieser Parameter dient zur eindeutigen Identizierung einer Messung. Sobald die Datei in dem vorgegeben Verzeichnis vorhanden ist, wechselt der Messkopf den Zustand von wartend über initialisieren zu messen. Im nächsten Abschnitt werden die Zustände des Messkopfes analysiert. 5.2 Analyse des Messkopfes 30

31 5 SmartVideo Systemansatz Zustandsdiagramm Der Messkopf hat insgesamt vier Zustände, in die er bei verschiedenen Events wechselt. Programmtechnisch sind das die Zustände 0 bis 3. State 0 & Default Wartezustand des Messkopf bis zum Start einer Messung. State 1 Initialisieren aller nötigen Parameter, Aufbau des Sockets zur Netzwerkkarte, Aktivierung der Prioritätssteuerung für den Messkopf und Umschalten der Netzwerkkarte in den Promiscuous-Mode State 2 Zurücksetzen des Messkopfes, Löschen von Parametern, Ändern der Priorisierung des Messkopfes auf den Standard-Wert und Löschen des Sockets State 3 Zustand während einer Messung. Aufzeichnen von Rohdaten, die über den Socket an den Messkopf gelangen und Speichern der Daten zur Weiterverarbeitung. Der Messkopf durchläuft bei einer Messung die Zustände in der Reihenfolge (Wartezustand - Initialisieren - Messen - Zurücksetzen - Wartezustand). Abbildung 5.4.: Zustandsdiagramm des Messkopfes - Version Analyse des Messkopfes 31

32 5 SmartVideo Systemansatz Threads Damit der Messkopf die verschiedenen Zustände realisieren und mehrere Aufgaben gleichzeitig abarbeiten kann, besteht der Messkopf aus fünf Threads. Diesen Threads sind unterschiedlichen Aufgaben zugeordnet, damit alle Netzwerkpakete korrekt erfasst und ausgewertet werden können. Für die Steuerung des Messkopfes aus allen Lagen heraus, ist der Thread probecontrol zuständig. Er kontrolliert den Messkopf. Die Splittung in mehrere Threads dient unter anderem dazu, zeitkritische Aufgaben von ressourcen-intensiven Berechungen zu trennen, damit keine Messfehler entstehen. Die nachstehende Tabelle zeigt die fünf Threads und ihre Aufgabe im Programm. Bedeutung der einzelnen Threads Thread Main networkanalysis probecontrol contentswitch mpeg4deepinspection Beschreibung Aufzeichnen der Roh-Paket-Daten von der Netzwerkkarte und Speichern in einer Queue für die Weiterverarbeitung. Erfassen der Daten inklusive des aktuellen Ankunftszeitstempels und der Paketlänge. Parsen und Ausgeben (Terminal und CSV-Datei) der Header aus den Layer Ethernet bis hin zum Layer MPEG-TS Prüfen ob Mess- und Stoppdateien vorhanden sind, Zeit- und Messdauersteuerung, Triggerung des Main-Thread zur Initialisierung von Messungen Reordering der Paketdaten und gegebenfalls Ansteuern der DPI- Threads, wenn eine DPI gefordert ist. Zusammenführen der NAL-Units und Extrahieren der Header NAL, SPS und PPS um weitere Informationen über das Video zu erhalten Tabelle 5.1.: Auistung der Namen und Bedeutung der einzelnen Threads des SmartVideo Messkopfes Die Threads probecontrol und Main werden aufgrund ihrer zeitkritischen Aufgaben zusätzlich vom Scheduler des Betriebssystems priorisiert behandelt. Die restlichen Threads führen Berechnungen aus und brauchen keine bevorzugte Behandlung. Die Sequenzdiagramme der einzelen Threads sind im Appendix ab A.3 zunden. Auf den Programmablaufplan wird im Kapitel 8 Implementierung genauer eingegangen. 5.2 Analyse des Messkopfes 32

33 5 SmartVideo Systemansatz Aufnehmende Parameter Der SmartVideo Messkopf erfasst eine Vielzahl von Parametern aus den Headern der einzelnen OSI Schichten. Diese werden unterteilt in sich widerholende und sich stetig ändernde Parameter eines IPTV-Streams. Die gesammelten Daten werden anschlieÿend in CSV-Dateien gespeichert und im Verzeichnis /tmp/sv_probe/les/ abgelegt. Die durch das SmartVideo Messsystem ermittelten Daten lassen sich in drei Kategorien einteilen. Statische Messdaten Die Statischen Messdaten sind sich wiederholende Parameter, die zu Beginn einer Messung einmalig als Ergebnis in die erste CSV Datei gespeichert werden. Beispiele hierfür sind die Hash-ID, die sich nur pro Stream ändert, oder eine MAC-Adresse, die in einem Netz immer identisch ist. Dynamische Messdaten Die dynamischen Messdaten sind paketbezogen und enthalten Informationen der Header, die sich stetig ändern, wie zum Beispiel Zeitstempel, Checksummen und Zähler (Counter). Beispiele für die dynamischen Messdaten sind die Identikationsnummer im IP-Header, oder auch die Sequenz Nummer im RTP-Header, die sich pro Netzwerkpaket ändern und meistens fortlaufend nummeriert sind. Abgeleitete Messdaten Die abgeleiteten Messdaten sind unter anderem berechnete Parameter für die Bestimmung des Jitters und Paketverlust. Des Weiteren werden Video Parameter gesammelt und die dynamischen Messdaten komprimiert aufgeführt. Beispiele für diese Art Daten stellen die Paketverlustrate sowie der Continuity Counter Error dar. Die vollständige Liste aller möglichen Parameter die der Messkopf aufzeichnen und das Messsystem berechnen kann, bendet sich im Appendix A.4.1, A.4.2 und A Analyse des Messkopfes 33

34 6 Android Architektur eines QoS/QoE Sensors 6. Android Architektur eines QoS/QoE Sensors Android ist ein von Google und der Open Handset Alliance 1 initiiertes quelloenes Betriebssystem für SmartPhones und mobile Endgeräte jeglicher Art. Es werden verschiedene Architekturen unterstützt, die gängigsten sind ARM- und x86-systeme, die überwiegend in eingebetteten Systemen (Embedded Systems) verwendet werden. Das erste Android SmartPhone wurde von HTC 2 im Oktober 2008 entwickelt und unter dem Namen G1 auf den Markt gebracht. Darüber hinaus wird eine Android SDK (Software Development Kit) und eine Android NDK (Native Development Kit) zur Verfügung gestellt, die Tools und APIs (Application Programming Interfaces) bereit hält. Mit ihnen können Entwickler Apps auf der Android Plattform unter Verwendung von Java (SDK) oder C/C++ (NDK) als Programmiersprache erstellen Systemarchitektur Ein Android System ist in fünf verschiedene Ebenen aufgeteilt. Den Kern des Betriebssystem stellt ein Linux Kernel in der Version 2.6 (Android 3.0 Honeycomb ) dar. Dieser dient als Abstraktionsschicht zur Hardware und verfügt über die Speicher- und Prozessverwaltung. Zusätzlich beinhaltet dieser die Treiber zur Netzwerk-, Grak- und Soundkarte, damit das Betriebssystem diese ansteuern kann. Als nächste Ebene folgen die sogenannten Android Native Libraries, welche in den Programmiersprachen C/C++ geschrieben sind und von Systemkomponenten in höheren Ebenen verwendet werden. Da grundsätzlich Java als Programmiersprache eingesetzt wird, wird das Java Native Interface verwendet, eine Schnittstelle, die den gegenseitigen Zugri auf Bibliotheken über die Grenzen von Programmiersprachen hinweg erlaubt. Die nächsthöhere Ebene ist die Android Runtime mit einem weiteren wichtigen Bestandteil von Android, der von Google selbst entwickelten virtuellen Maschine Dalvik. Die Dalvik Virtual Machine (DVM) ist der Java Virtual Machine (JVM) von Oracle ähnlich, jedoch bestehen Unterschiede, die die Ezienz auf Mobiltelefonen steigern. Die DVM optimiert den Energieverbrauch und die Arbeitsspeicheranforderung. Java Klassen werden in.dex Dateien 1 OHA - ein Konsortium von 80 Firmen zur Schaung von oenen Standards für Mobilgeräte 2 HTC - Chinesischer SmartPhone Hersteller 34

35 6 Android Architektur eines QoS/QoE Sensors zusammengefasst, wobei Informationsredundanzen detektiert und ausgelassen werden, was eine stark reduzierte Gröÿe der Anwendungen zur Folge hat. Weiterhin besitzt die DVM einen angepassten Garbage Collector und wurde dafür konzipiert, parallel ausgeführt zu werden. Dies ist insofern wichtig, als dass jede Android Anwendung mit einer eigenen Instanz der DVM ausgeführt wird. Die DVM ist im Gegensatz zur JVM keine Stackmaschine, sondern eine Registermaschine. Damit ist die DVM für ARM Prozessoren performant und ressourcenschonend ausgelegt. Man nähert sich hier bewusst der Prozessorarchitektur an und verzichtet auf die Portierbarkeit um einen Zeitgewinn bei der Ausführung zu erzielen. Google erhot sich zudem durch die Verwendung einer Registermaschine 30 Prozent weniger Prozessoroperationen. Die obersten zwei Ebenen bilden das Application Framework und der Application Layer. Das Application Framework ist vollständig in Java implementiert und unterteilt sich in verschiedene Manager. Dabei sind die Manager für unterschiedliche Aufgaben zuständig. Darunter gehören Aufgaben wie das Verwalten von Lebenszyklen der Programme, Bereitstellen von Diensten zur Kommunikation zwischen Programmen und dem View System, welches Anzeigeelemente wie Textfelder, Buttons oder Hinweise in der Statusleiste zur Verfügung stellt. Das Application Framework gibt als Programmiergerüst eine Anwendungsarchitektur vor, welche von den Programmen im Application Layer umgesetzt werden muss. Im Application Layer werden alle Programme, die direkt mit dem Benutzer interagieren (zum Beispiel Webbrowser, Wetteranzeige und Spiele) ausgeführt. Abbildung 6.1.: Android Architektur (Quelle: Android Developer)[7] 6.1 Systemarchitektur 35

36 6 Android Architektur eines QoS/QoE Sensors Wie im vorherigen Abschnitt beschrieben, wird jede Anwendung mit einer eigenen Instanz der Dalvik Virtual Machine ausgeführt und bendet sich im Applications Framework, wo sie von dem Fenster- und Ressourcenmanager kontrolliert wird. Es gibt vier verschiedene Arten von Anwendungstypen: 1. Activities 2. Services 3. Broadcast Receiver 4. Content Provider Eine Activity ist der gängigste Anwendungstyp. Dieser wird vom Benutzer direkt wahrgenommen, da er als einziger Anwendungstyp auf der Benutzeroberäche sichtbar ist und mit dem Benutzer interagieren kann. Activities können sich gegenseitig aufrufen und einander Werte übergeben. Für den Benutzer ist das Wechseln der Activity wie ein Fensterwechsel mit neuem Inhalt. Der Anwendungstyp Services arbeitet zumeist im Hintergrund und dient dazu, lang laufende Operationen durchzuführen die keine Benutzer Aktionen erfordern. Eine weitere Variante von im Hintergrund laufenden Prozessen stellt der Broadcast Receiver dar. Er agiert nur dann, wenn ein expliziter Aufruf aus einem Programm getätigt worden ist, jedoch systemweit. Das bedeutet, dass jedes Programm auf diese Funktionalität zugreifen kann, sobald der Broadcast Receiver registriert ist. Beim letzten Anwendungstyp handelt es sich um eine einheitliche Speicherverwaltung für Nutzdaten, mit der Anwendungen ihre Daten austauschen können. Wurde eine Anwendung programmiert, kann diese kompiliert werden und auf dem Android System ausgeführt werden. Beim Erstellen einer Anwendung wird der Java/C/C++ Code in Bytecode zu Dex-Dateien (Dalvik Executable) kompiliert und zusätzlich mit Bildern und Layout-Dateien (XML) in einer APK-Datei (Android Package) verpackt. Die APK-Datei muss auf das Android System transferiert werden, danach lässt sie sich einfach installieren Activities Activities bilden den Mittelpunkt einer Android Anwendung, wenn es darum geht dem Benutzer eine Interaktion zu ermöglichen. Üblicherweise ist eine Activity wie ein main()-aufruf bzw. Programmstart für eine andere Programmiersprache (C/C++ etc.) und stellt das eigentliche Programm dar. Sie dient dazu, mit dem Benutzer zu interagieren und Befehle und Eingaben entgegen zu nehmen. Jede Activity wird in dem sogenannten Activity Stack 3 verwaltet, der verschiedene Stufen der Activity steuert. Ist eine Activity aktiv, wird sie als Running gekennzeichnet und an den Anfang des Stacks gelegt. Activities, die am Anfang des Stacks liegen sind automatisch für den Benutzer sichtbar. Es gibt verschiedene Zustände (States) die eine Activity 3 Activity Stack - Virtueller Stapel im Speicher für die Verwaltung von Anwendungen 6.2 Activities 36

37 6 Android Architektur eines QoS/QoE Sensors annehmen kann, jedoch existiert immer nur eine Activity mit dem Zustand Running. In der nachfolgenden Abbildung sind alle möglichen States in einem Diagramm aufgelistet. Des Weiteren wird ersichtlich, von welchem Zustand in welchen Zustand eine Activity wechseln kann und wie deren Funktionsaufruf lautet. Abbildung 6.2.: Android Activity Lifecycle (Quelle: Android Developer - Activity) Grundsätzlich wird eine Activity mit der oncreate-methode erstellt. Danach wird sie mit den Methoden onstart und onresume in den Zustand Running gesetzt. Verliert die Anwendung den Focus oder wird sie beendet, wechselt die Activity mit onpause und onstop den Zustand. Im Zustand Stopped liegt die Anwendung im Hintergrund und kann mit onrestart wieder aktiviert 6.2 Activities 37

38 6 Android Architektur eines QoS/QoE Sensors werden. Je nach verfügbaren Ressourcen kann das System gestoppte Activity mit ondestroy beenden oder komplett aus dem Speicher löschen (killed). Zwischen dem Abschnitt onresume() und onpause() ist eine Anwendung als sichtbar deniert. Zwischen den Methoden oncreate() und ondestroy() existiert sie nur und liegt im Hintergrund, ansonsten ist sie nicht vorhanden. Aus dem oben abgebildeten Diagramm lassen sich die folgenden Zustände herauslesen. Abbildung 6.3.: Activity States Wichtig ist an dieser Stelle, das beim Wechseln der Zustände grundsätzlich dafür gesorgt werden muss, das die benutzerspezischen Daten (Eingabefelder, Slider-Werte), die während der Programmbedienung eingegeben worden sind, separat gespeichert werden müssen, da diese ansonsten verloren gehen. Der Zeitpunkt, wann eine Anwendung von der Dalvik Virtual Machine zwanghaft beendet wird, kann nicht beeinusst werden Sicherheitskonzept Das Sicherheitskonzept des Android Systems verfügt über eine Vielzahl von unterschiedlichen Mechanismen zur Sicherung der Daten und Abschottung des Systems. Einige Mechanismen bringt der Linux Kernel und das dem zugrunde gelegten Rechtesystem mit sich, andere wiederum müssen von Programmentwicklern implementiert bzw. aktiviert werden. Android ist ein privilegien-separiertes Betriebssystem, das jede Anwendung mit eigenen Rechten behandelt. Des Weiteren isoliert Linux standardmäÿig alle Anwendungen gegeneinander und vom System ab, sodass grundsätzlich keine Anwendung per Default Befehle ausführen kann, die Anwendungen oder das System beeinussen könnten. Dieses Verhalten betrit auch das Schreiben und Lesen von benutzerbezogenen Dateien, Zugri auf das Netzwerk oder die Hardware generell. Diese Mechanismen sind betriebssystem- und framework-weit ausgelegt und betreen nicht nur eine Instanz des Systems. Der Kernel ist für das Sandboxing zuständig, der die einzelnen Prozesse separiert und steuert. Die DVM ist nicht Bestandteil des Sicherheitskonzeptes, sodass sie in der Lage ist jeglichen Code (Java oder Native C/C++) auszuführen. Dafür müssen einzelne Rechte innerhalb eines Programms durch eine Manifest-Datei angefordert werden. [8] 6.3 Sicherheitskonzept 38

39 6 Android Architektur eines QoS/QoE Sensors Bei dem gesamten Sicherheitskonzept wird in drei Gruppen dierenziert, die wie folgt Bestandteile der Sicherung des Systems sind: Sicherheitsmechanismen unter Android - Gruppierung Gruppe System Programme Hardware Mechanismus Benutzer ID (UID) / Gruppen ID (GID) Dateizugri Partitionen Digitale Signaturen Benutzerberechtigungen (Manifest) Programmverkapselung Sperre (Code, Muster, SIM) Tabelle 6.1.: Auistung aller bekannten Sicherheitsmechanismen bei einem Android System In den folgenden Abschnitten werden die einzelnen Mechanismen erläutert und aufgezeigt, wie diese erweitert werden können. Benutzer ID (UID) / Gruppen ID (GID) Die heutigen Betriebssysteme sind Mehrplatzsysteme, die mit Benutzeraccounts unterschiedliche Rechte auf dem System genieÿen. Bei einem Android System wird jedem Programm ein eigener Benutzeraccount zugeteilt, mit dessen Rechten es ausgeführt wird. Demnach besitzt jedes Programm eine eindeutige Identikationsnummer, die im System als UserID (UID) geführt wird. Für eine bessere Lesbarkeit wird diese Nummer auf einen Benutzernamen gemappt. Zusätzlich wird im Betriebssystem zur gröberen Rechteverwaltung die Möglichkeit geschaen, Benutzeraccounts in Gruppen einzuteilen. Diese Gruppen ermöglichen Anwendungen Zugri auf Ressourcen anderer Anwendungen, wenn diese sich in der selben Gruppe benden. Ähnlich der UserID ist auch die GroupID (GID) eine eindeutige Identikationsnummer. Mit dem Befehl id kann man sich die UID und GID des aktuellen Benutzers auf dem System anzeigen lassen. Ein Beispiel zeigt die folgenden Ausgabe auf einem Android System für den Benutzer root und für eine App: uid=0(root) gid=0(root) uid=10064(app_64) gid=10064(app_64) Der folgende exemplarische Auszug aus dem Befehl ps zeigt, dass jedes App einen eigenen Benutzer (USER) hat (Unterer Teil - ab Zeile 18). Ausnahmen sind hier Kernel Threads (Oberer Teil - Zeile 2-5), die alle als Benutzer root laufen müssen. Auÿerdem sind einige Dienste 6.3 Sicherheitskonzept 39

40 6 Android Architektur eines QoS/QoE Sensors (Mittlerer Teil - Zeile 7-16) Systemdienste (z.b. Zygote - Zuständig für das Starten von Apps), die ebenfalls als Benutzer root agieren müssen. 1 USER PID PPID VSIZE RSS WCHAN PC NAME 2 root c00ce53c 0000 d2ac S / i n i t 3 r o o t c0076d1c S kthreadd 4 r o o t c0067e S k s o f t i r q d /0 5 root c0094db S watchdog /0 6 7 system c022390c afd0dc1c S / system / bin / servicemanager 8 r o o t f f f f f f f f a f d 0 e 2 8 c S / system / bin / vold 9 r o o t f f f f f f f f a f d 0 e 2 8 c S / system / bin / netd 10 root c023348c afd0e5ac S / system / bin / debuggerd 11 r a d i o f f f f f f f f a f d 0 e 2 8 c S / system / bin / r i l d 12 bluetooth c00ce53c afd0ea5c S / system / bin /dbus daemon 13 r o o t c02c2034 afd0d97c S / system / bin / i n s t a l l d 14 keystore c023348c afd0e5ac S / system / bin / keystore 15 media f f f f f f f f afd0dc1c S / system / bin / mediaserver 16 r o o t c 0 0 c e 5 3 c afd0dd44 S z y g o t e system f f f f f f f f afd0dc1c S system_server 19 radio f f f f f f f f afd0ebd8 S com. android. phone 20 app_ f f f f f f f f afd0ebd8 S com. htc. bg 21 app_ f f f f f f f f afd0ebd8 S com. google. process. gapps 22 app_ f f f f f f f f afd0ebd8 S android. p r o c e s s. acore 23 app_ f f f f f f f f afd0ebd8 S com. smartvideo. probe Listing 6.1: Ausgabe des Prozess Status mit dem Linux Befehl ps auf einem Android System Dateizugri Jede Datei auf einem Linuxsystem unterliegt einem Rechtesystem, das es ermöglicht einzelne Rechte zu vergeben. Es wird festgelegt, wem die Datei gehört und wer Operationen (lesen, schreiben, ausführen) mit dieser durchführen darf. Die Attribute Lesen (r), Schreiben (w) und Ausführen (x) sind jeweils für die UID, GID und Others anwendbar und können einzeln gesetzt werden. Ausschlieÿlich die Benutzer system und root können auf Systemdaten zugreifen, wohingegen Benutzer mit normalen UserIDs, die Programmen zugeordnet sind, nur auf die eigenen Programmdaten Zugri haben. Im nachstehenden Ausschnitt wird eine typische Verzeichnisstruktur auf einem Android System im Anwendungsordner /data/data/ mit den Rechten für jeden Ordner dargestellt. 1 PERMISSIONS USERID GROUPID DATE PROGRAM 2 drwxr x x app_64 app_ : 29 com. smartvideo. probe 3 drwxr x x app_80 app_ : 35 com. noshufou. android. su 4 drwxr x x app_90 app_ : 56 sv. measurementsystem 5 drwxr x x app_75 app_ : 15 com. googlecode. droidwall. f r e e Listing 6.2: Ausgabe der Verzeichnisstruktur zum Anzeigen der Datei- und Ordner-Rechte 6.3 Sicherheitskonzept 40

41 6 Android Architektur eines QoS/QoE Sensors Partitionen Unter Android werden Daten je nach Klassizierung in unterschiedlichen Ordnern gespeichert und diese wiederum in verschiedene Partitionen ausgelagert. Dieses ist insofern eine weitere Sicherheitsmaÿnahme, als dass den Partitionen zusätzliche Regeln zugeschrieben werden können. /data Hier werden die Anwendungsdaten mit den jeweiligen Benutzer Berechtigungen gespeichert. Das ist die einzige Systempartition, die beschreibbar ist. /system Diese Partition enthält Dateien des Betriebssystems. Für den Benutzer und die Anwendungen ist diese Partition nur lesbar. Gespeichert werden Systembibliotheken und Dateien, die der Regelung der laufenden Programme dienen. /sdcard Die SD-Karte wird mit der Option no-exec eingehangen, das heiÿt, dass Programme von diesem Datenträger nicht ausgeführt werden können. Dabei wird die SD-Karte, um eine hohe Kompatibilität zu gewährleisten, von Android-Geräten mit dem weit verbreiteten Dateisystem FAT32 formatiert. Dieses Dateisystem besitzt jedoch keine Dateiberechtigungen. Demnach können alle Anwendungen auf diese Daten zugreifen. Digitale Signaturen Ein Programmarchiv (APK) muss, um es installieren zu können, digital signiert sein. Man hat bei Android auf eine zentrale Vergabestelle der Signaturen verzichtet. Jeder Entwickler kann sein Zertikat selbst erstellen und damit seine Software signieren. Software in der Entwicklung wird mit einem sogenannten Debug-Zertikat signiert, bei einer Veröentlichung der Software im Android Market, wird ein selbst erstelltes Zertikat nur für die Veröentlichung generiert. Demnach trit eine digitale Signatur unter Android nur eine Aussage über die Echtheit des Ursprungs einer Datei. Möchte man als Entwickler Dienste von Google nutzen, so muss das Zertikat von Google gegengezeichnet und in der Software aktiviert werden. Damit erhält man Zugri auf Dienste wie z.b. Google Maps. Benutzerberechtigungen (Manifest) Jede Applikation, die auf einem Android-Gerät installiert werden soll, muss eine Datei mit dem Namen AndroidManifest.xml im Rootordner enthalten. In dieser Datei werden die benötigten Zugrie auf Gerätefunktionen deklariert und die einzelnen Programmkomponenten beschrieben. 6.3 Sicherheitskonzept 41

42 6 Android Architektur eines QoS/QoE Sensors Android bietet über 100 vordenierte Rechte, sogenannte Permissions an welche ein Programm explizit während der Installation anfordern muss. Ein Taschenlampenprogramm benötigt beispielsweise, um ordnungsgemäÿ zu funktionieren, die Permission Flashlight. Die Anforderung der Permissions wird in der AndroidManifest.xml aufgeführt und sieht wie folgt aus: <uses-permission android:name="android.permission.flashlight" /> Jeder Permission wird ein Protection-Level zugeordnet, mit dem bestimmt wird, wie kritisch ihre Freigabe ist. Man unterscheidet folgende Attribute: normal Rechte, von denen keine besonderen Gefahren für Gerät oder Anwender ausgehen, zum Beispiel: FLASHLIGHT dangerous Rechte, die ein hohes Risiko darstellen, da sie entweder hohe Kosten verursachen können oder Zugang zu sensiblen, privaten Daten ermöglichen. Zum Beispiel: SEND_SMS signature Freigabe erfolgt nur an die Programme, die mit der selben digitalen Signatur gekennzeichnet sind. Programme desselben Herausgeber können so kommunizieren. signature-or-system Spezielle Variante des signature-attributs, welches jedoch zusätzlich an Programme vergeben werden darf, die in Android werksseitig enthalten sind. Während der Installation wird dem Benutzer eine nach der Wichtigkeit der Attribute sortierte Liste angezeigt. Dieser muss er explizit zustimmen. Eine vergebene Permission ist permanent gültig und konsequent. Sie kann bis zur Deinstallation des Programms nicht mehr geändert werden. Dabei geht Android hier nach dem Alles-oder-nichts-Prinzip vor. Entweder stimmt der Anwender den angeforderten Permissions komplett zu oder bricht die Installation ab. Dies führt dazu, dass Benutzer die Anfragen ohne eine genauere Untersuchung bestätigen, falls das Programm verwendet werden soll. 6.3 Sicherheitskonzept 42

43 6 Android Architektur eines QoS/QoE Sensors Abbildung 6.4.: Einholen der Rechte beim Benutzer bei der Installation einer Android App Programmverkapselung Programme können Aufgaben an andere Programme, genauer gesagt ihre Komponenten, weiterleiten. Dabei können sie diese entweder direkt adressieren oder sie verwenden den Android Activity Manager, der einen sogenannten Intent 4 an eine Komponente weiterreicht. Die Möglichkeiten, auf welchen Intent eine Komponente reagiert, werden mit einem Intent Filter in der AndroidManifest.xml beschrieben. Dieses System wird als Inter-Component Communication (ICC) bezeichnet. Die ICC ist eine Art der Zugriskontrolle. Jede Komponente besitzt ein Zugrisetikett, welches bestimmt, wem diese Komponente zugänglich ist. Die von den Entwicklern denierten Zugrisrechte bilden die Einstiegspunkte für jeweilige Anwendungen. Dabei spielt der Ursprung der aufrufenden Komponente keine Rolle, auch Komponenten einer anderen Anwendungen kann der Zugri erlaubt oder untersagt werden. Mit diesem strengen Prinzip der Kapselung wird verhindert, dass Programme sich gegenseitig manipulieren und auf private Anwendungsdaten oder Funktionen zugreifen. 4 Intent - Programm-Aufruf innerhalb einer Activity 6.3 Sicherheitskonzept 43

44 6 Android Architektur eines QoS/QoE Sensors Sperre (Code, Muster, SIM) Um vor unautorisiertem physischen Zugri zum Gerät zu schützen, beherrscht Android, wie die meisten Mobiltelefone und SmartPhone, eine Bildschirm- oder SIM-Sperre. Die SIM-Sperre fordert bei jedem aktivieren der SIM-Karte die PIN (Personal Identikations Number) an. Wird diese falsch eingegeben, wird die SIM-Karte gesperrt und es können keine Telefonate, SMS oder Internet-Dienste (ausgenommen WLAN) benutzt werden. Bei der Code- oder Muster- Sperre handelt es sich um eine Bildschirm-Sperre, die das Gerät komplett blockiert, wenn keine korrekte Eingabe erfolgt Erweiterte Administratorenrechte Beim Android Betriebssystem laufen, wie in den vorherigen Abschnitten beschrieben, einige Systemprozesse als Root oder auch Administratorenrechte. Der Kernel benötigt für die Ansteuerung der Hardware mit Hilfe von Treibern sogenannte Root-Rechte. Ohne diese Rechte ist er nicht in der Lage, Systembefehle abzusetzen und ordnungsgemäÿ zu funktionieren. Standardmäÿig werden alle Anwendungen als normaler Benutzer mit minimalen Rechten ausgeführt und sind nicht in der Lage, erweiterte Administratorenrechte zu erlangen. Um Systemfunktionen (z.b. Anwendungen installieren) zu nutzen, gibt es Hilfsprozesse und Standalone-Programme, die mit API-Aufrufen (Application Programming Interface) benutzt werden können. Diese führen dann die gewünschte Aktion aus, da diese abhängig vom Hilfsprozess als Benutzer Root laufen. Ein Beispiel hierfür ist der Installations-Prozess installd, der zu den Standard Prozessen eines Android System gehört. USER PID PPID VSIZE RSS WCHAN PC NAME root c02c2034 afd0d97c S /system/bin/installd Der Prozess kann nur angestoÿen werden und man hat keinen Einuss auf die Funktion des Prozesses. Diese Art der Kapselung von Systemaufrufen und Funktionen dient dem Schutz des Systems, damit es nicht beschädigt wird. Grundsätzlich ist das Android System für den Vollzugri gesperrt und nur über die Oberäche (GUI) bedienbar. In manchen Fällen ist es jedoch unabdingbar, selbst Hilfsprozesse zu entwickeln, die gewünschte Funktionen als root ausführen. Dafür gibt es zwei Möglichkeiten. 1. init.rc Datei im Hauptverzeichnis des Android Betriebssystems. Wird vom Init-Prozess beim Booten ausgeführt. Der Init-Prozess arbeitet als Root mit der PID 1. Alle von ihm ausgeführten Befehle können als Root arbeiten. 6.3 Sicherheitskonzept 44

45 6 Android Architektur eines QoS/QoE Sensors 2. su Ein Linux Hilfsprogramm, mit dem man in der Lage ist, den Benutzerkontext zu wechseln. SU (Substitute User identity) ermöglicht es unter anderem von einer beliebigen UserID auf die UserID 0 zu wechseln. Damit werden alle maximal möglichen Rechte auf dem System erlangt. Jedoch ist diese Funktion mit Vorsicht zu genieÿen, da ein Lösch-Befehl einer Systemanwendung nicht mehr rückgängig gemacht werden kann. Ein zu entwickelndes Programm, das mit Root-Rechten ausgeführt werden soll, kann auf zwei verschiedene Arten erreicht werden. Zum Einen kann es durch den Init-Prozess während des Startvorgangs ausgeführt werden, zum Anderen kann es mit Hilfe des su-befehls während der Laufzeit gestartet werden. In einer standardmäÿigen Ausführung des Android Betriebssystems auf einem SmartPhone ist zum Einen die Datei init.rc als normaler Benutzer nicht beschreibbar. Es können demnach keine Änderungen vorgenommen werden. Zum Anderen ist das Programm su nicht auf dem System vorhanden und müsste installiert werden, was jedoch verweigert wird. Folglich kann der Nutzer keine Administratorenrechte erlangen, es sei denn er entsperrt das Gerät durch das sogenannte Rooten. Das Rooten erönet die Möglichkeit, Anwendungen als Hilfsprozesse zu entwickeln, die dann beim Bootvorgang oder während der Laufzeit erweiterte Administratorenrechte erlangen. Eine reine GUI-Anwendung kann keine erweiterten Administratorenrechte durch das Rooten bekommen. Rooten Durch das Rooten wird das Dateisystem entsperrt, in dem das Programm su installiert wird. Darüber hinaus wird ein zusätzliches App mit dem Namen SuperUser zur Benutzeroberäche hinzugefügrt, das eine komfortable Steuerung bzw. ein Erlauben oder Verweigern von Root- Rechten gestattet. Das Rooten basiert darauf auf der Nutzung eines Fehlverhaltens des Linux Kernels oder einer Systemfunktion in den Bibliotheken. Dieses Ausnutzen von Fehlverhalten wird Exploit 5 genannt. Ein gängiger Exploit ist das Auslösen eines Puerüberlaufs bei der Bearbeitung von Daten im Speicher durch den Kernel. Dabei wird zusätzlicher Code in den Speicher geschrieben, der dann durch das Fehlverhalten ausgeführt wird. Da der Kernel bekanntlich Adminstratorenrechte hat, wird der Code als Root bearbeitet. Wurde ein Fehlverhalten des Kernels gefunden und ein Exploit mit dem passenden Code erstellt und erfolgreich ausgeführt, kann ein Programm wie su installiert werden. Das Android System ist nach diesem Vorgang entsperrt und oen für jegliche Android-spezische Software. 5 Exploit - Eine Befehlsfolge, die Sicherheitslücken und Fehlfunktionen von Hilfs- oder Anwendungsprogrammen ausnutzt 6.3 Sicherheitskonzept 45

46 6 Android Architektur eines QoS/QoE Sensors Bekannte Root-Programme für verschiedenen SmartPhones und Android Versionen sind: revoked 3 SuperOneClick Diese Art des Rootens wird zukünftig an Bedeutung verlieren, da namhafte Hersteller von SmartPhone wie HTC angekündigt haben, ihre Bootloader 6 zu önen [13]. Damit lassen sich über den Bootloader sogenannte Recovery-Menüs installieren, die wiederum das Installieren von Software Paketen (Firmware CynanogenMod und Programme su) auf Systemebene zulassen. Das Ausnutzen von Fehlern im Kernel oder Betriebssystem über einen Exploit ist dann nicht mehr zwingend nötig SDK vs. NDK Software Development Kit Das von Google entwickelte Software Development Kit für Android ist ein Framework zur Entwicklung von Android Apps basierend auf der Programmiersprache Java. Es existiert seit der Android Version 1.1 (API Level 2) als installierbares Kit. Dieses Kit besteht aus folgenden verschiedenen Bestandteilen: Android Bibliotheken Treiber Emulator Compiler (dx) Debugging Tools Dokumentation Beispielcode Herstellerspezische Add-ons Zusätzlich gibt es noch Plug-Ins, mit denen man das SDK in die Entwicklungsumgebung Eclipse einbinden kann. Das SDK ist in der aktuellen Version für Android 3.1 (API Level 12 - Stand August 2011) für Windows, Mac OS X und Linux verfügbar. 6 Bootloader - Spezielles Programm zum Laden der Firmware und Starten des Betriebssystems 6.4 SDK vs. NDK 46

47 6 Android Architektur eines QoS/QoE Sensors Ein einfaches Beispiel unter Eclipse für eine App, die eine Ausgabe auf dem Bildschirm macht, sieht wie folgt aus: 1 package com. smartvideo. example ; 2 import android. app. Activity ; 3 import android. os. Bundle ; 4 import android. widget. TextView ; 5 public c l a s s example extends Activity 6 { 8 public void oncreate ( Bundle savedinstancestate ) 9 { 10 super. oncreate ( savedinstancestate ) ; 11 TextView tv = new TextView ( t h i s ) ; 12 tv. s e t T e x t ( "Das i s t e i n B e i s p i e l " ) ; 13 setcontentview ( tv ) ; 14 } 15 } Listing 6.3: Beispielcode der Datei example.java des SDK Native Development Kit Das Android Native Development Kit ist ein mit dem Android Software Development Kit vergleichbares Framework, mit dem Entwickler Teile ihrer Anwendungen in nativen Codesprachen wie C und C++ schreiben können. Das NDK funktioniert allerdings nur in Verbindung mit dem Android SDK und ist in der aktuellen Version Revision 6 (Stand August 2011) für Windows, Mac OS X und Linux erhältlich. Es enthält Tools und Build-Dateien zum Erzeugen nativer Code-Bibliotheken aus C- und C++-Sourcen, die sich in Anwendungspakete einbetten lassen. Das Kit eignet sich primär für ARM Processor Instruction Set-Architekturen und unterstützt darüber hinaus Header für Linux Bibliotheken, wie libc, libm, libz, liblog und das Java Native Interface (JNI), welches eine Kommunikation zwischen Java und C/C++ erlaubt. Standardmäÿig werden Anwendungen der NDK in Bibliotheken umgewandelt und von der eigentlichen App über das JNI aufgerufen und benutzt. Eine JNI Bibliothek läuft als Prozess innerhalb der Dalvik mit den benutzer- bzw. applikationsbezogenen Berechtigungen und kann, kontrolliert von der Dalvik, C-Code ausführen. Zusammengefasst sind die Bestandteile der NDK folgende: Android Native Bibliotheken Tools für C/C++ Compiler (ndk-build) Dokumentation Beispielcode 6.4 SDK vs. NDK 47

48 6 Android Architektur eines QoS/QoE Sensors Ein einfaches Beispiel für ein NDK-Programm unter Android besteht aus zwei Dateien, die notwendig sind um das NDK-Projekt zu kompilieren: 1. example.[c/cpp] 2. Android.mk Die beiden Dateien müssen folgende Struktur aufweisen. In der Datei example.[c/cpp] wird das eigentliche Programm erstellt. Die Funktion main bildet den Einstiegspunkt für die Anwendung. Die Android.mk stellt Anweisungen für den Compiler bereit. Mit diesen Informationen ist der Compiler in der Lage ein Binärprogramm zu erzeugen. 1 #i n c l u d e <s t d i o. h> 2 #i n c l u d e <s t r i n g. h> 3 4 i n t main ( i n t argc, c o n s t char argv [ ] ) 5 { 6 p r i n t f ( "Das i s t e i n B e i s p i e l " ) ; 7 r e t u r n 0 ; 8 } Listing 6.4: Inhalt der Datei example.c des NDK 1 LOCAL_PATH := $ ( c a l l my d i r ) 2 3 include $ (CLEAR_VARS) 4 5 LOCAL_LDLIBS := l l o g 6 7 LOCAL_MODULE := example 8 LOCAL_SRC_FILES := example. c 9 10 include $ (BUILD_EXECUTABLE) Listing 6.5: Inhalt der Datei Android.mk des NDK Wird das Beispiel mit dem NDK-Compiler kompiliert, erhält man ein auf Android und ARM lauähiges Binärprogramm. Das Programm muss auf ein SmartPhone übertragen werden. Von dort aus kann es über ADB 7 ausführen werden. Eine Ausgabe auf dem Bildschirm des Smart- Phone ist nur dann möglich, wenn das Java Native Interface (JNI) benutzt und eine passende Schnittstelle in der SDK implementiert wird. Die Standard Ausgabe ist ansonsten die Konsole der ADB-Shell Vergleich Zwischen den beiden Development Kits gibt es feine Unterschiede, die auf die Entwicklung eines Programms starken Einuss haben können. Abgesehen von der Programmiersprache ist ein Geschwindigkeitsvorteil um den Faktor 2 bis 3 bei der NDK auszumachen. Es relativiert 7 ADB - Android Debug Bridge - Terminal Programm für den Zugri auf ein Android Gerät 6.4 SDK vs. NDK 48

49 6 Android Architektur eines QoS/QoE Sensors sich diese Angabe jedoch insofern, als dass mit der NDK keine komplette App programmiert werden kann. Somit werden üblicherweise nur kleine und rechenintensive Teile auslagert, die dann performanter abgearbeitet werden. Bei der Ressourcensteuerung wird bei einem Android Betriebssystem alles über die Dalvik VM verwaltet. In der Programmierung unter Java werden Ressourcen dynamisch angelegt und bei Nichtgebrauch wieder freigegeben (Garbage Collection - GC). Unter der NDK werde Objekte auch dynamisch angelegt, jedoch muss aufgrund von C/C++ dieser Speicher wieder manuell freigegeben (free, delete) werden. Grundsätzlich werden alle mit der SDK in Java geschriebenen Programme über die Oberäche gestartet. Die Programme der NDK hingegen werden bei der JNI-Schnittstelle über die App gestartet und bei Standalone Programmen über eine Linux Shell. In der nachfolgenden Tabelle sind die wichtigsten Unterschiede zwischen der SDK und NDK aufgeführt. Vergleichstabelle SDK und NDK Software Development Kit Native Development Kit Sprache Java C/C++ Berechtigungen Benutzerbezogen Benutzerbezogen (Ausnahmen beim Rooten) Performance Sekunden 7.99 Sekunden Ressourcen Allokation Dynamisch Dynamisch möglich Ressourcen Freigabe Dynamisch (GC) JNI - Dynamisch (GC) Shell - Manuell (free, delete) Raw Sockets nein nein (Ausnahmen beim Rooten) Aufrufbar über GUI JNI, Shell Laufzeitumgebung Dalvik Dalvik (JNI), Shell (Linux) Dauer der Ausführung eines Test-Programm mit 1 Mio. Objekt-Allokationen inkl. Freigeben des Speichers [42][45] Tabelle 6.2.: Vergleich der Eigenschaften und Funktionen von SDK und NDK 6.4 SDK vs. NDK 49

50 7 Evaluation 7. Evaluation Ein Messsystem, das für den mobilen Einsatz auf einem SmartPhone gedacht ist, kann nur auf begrenzte Ressourcen zurückgreifen. Die zur Verfügung stehenden Ressourcen werden vom gesamten System genutzt. Vor diesem Hintergrund betrachtet, muss ein Messsystem implementiert werden, das diesen Ressourcen gerecht wird. Weiterhin muss eine Qualitätsbewertung möglichst nah beim Empfänger durchgeführt werden. Ein Messverfahren nach dem Non-Reference- Ansatz, wie in Kapitel beschrieben, soll in dieser Master Thesis als QoS/QoE Monitoring Sensor auf einem Android SmartPhone implementiert werden. Ein ächendeckender Einsatz ähnlich dem SmartVideo Messkopf soll möglich sein. Eine typisches Szenario für ein verteiltes mobiles Sensor-Netzwerk stellt die Abbildung 7.1 dar. [6] Abbildung 7.1.: Technische Implementierung eines verteilten Sensor-Netzes mit SmartPhone Tests und Performanceanalysen haben gezeigt, das moderne SmartPhone und Embedded Systems für diese Art von Sensoren geeignet sind [26] und eine Implementierung durchgeführt werden kann. In diesem Kapitel wird evaluiert, welche Parameter von dem Sensor aufgenommen werden müssen und welche Architekturansätze für die Implementierung eines Sensors zur Verfügung stehen. Dabei wird das Augenmerk in erster Linie auf die Entwicklung eines Messkopfes als On-Body-Sensor auf einem SmartPhone gelegt. 50

51 7 Evaluation 7.1. Spezikation der Analysetiefe Ein Messkopf, der möglichst viele Parameter aus einer Messung oder aus einem Netzwerkpaket herauslesen soll, kann nicht nur Anwendungsdaten analysieren, sondern muss, um ein optimales Ergebnis zu erlangen, alle Parameter aufnehmen, die zur Verfügung stehen. An dieser Stelle gilt es zu spezizieren, ab welcher Netzwerkschicht des ISO/OSI Modells eine Analyse stattnden soll und welche Parameter benötigt werden. Auÿerdem gilt es zu überprüfen, ob es möglich ist, einzelne Parameter oder Netzwerkschichten nicht mit aufzuzeichnen zugunsten der Performance des Android SmartPhone. Zur einfacheren Spezikation wird ein Mapping vom ISO/OSI Modell zum TCP/IP Modell vorgenommen. Abbildung 7.2.: Vergleich und Mapping zwischen ISO/OSI Schichtenmodel und TCP/IP Schichtenmodel (Quelle: Learn-Networking) Zum Anfang wird für jede Schicht des TCP/IP Modells eine Zuordnung der einzelnen Header durchgeführt, die in einem Netzwerkpaket enthalten sind. 1. Network Access Layer - Ethernet Header Der Ethernet Header ist der erste zur Verfügung stehende Header in der Verarbeitung des Paketes. Die Daten aus dem Header umfassen unter anderem die MAC-Adresse der Gegenstelle, die eigene MAC-Adresse und die Payload Signalisierung. Interessante Informationen stellt das VLAN-Tag in diesem Header dar. Wenn diese Tag vorhanden ist, lässt es auf einen Priorisierung der Pakete zurückschlieÿen. 2. Internet Layer - IP Header Für die Ende-zu-Ende Kommunikation ist der Internet Layer zuständig, der das IP- 7.1 Spezikation der Analysetiefe 51

52 7 Evaluation Protokoll enthält. Der IP Header ist für eine Analyse sehr interessant, da dort das ToS 1 - Feld vorhanden ist, das eine Klassizierung in unterschiedliche Qualitätsstufen zulässt. Es beinhaltet das DSCP 2 -Feld, welches eine Priorisierung und damit Anhebung der Dienstgüte ermöglicht. Auÿerdem ist das Identication-Feld zur Detektion von Paketverlust sehr wichtig. 3. Transport Layer - TCP/UDP/RTP Header Beim Transport Layer sind die Header der Protokolle TCP/UDP/RTP für eine Analyse verfügbar. Bei einer üblichen Kapselung wie in Abbildung 4.1 beschrieben, sind die Daten des UDP Header für eine Qualitätsbewertung nicht relevant. Die Daten des RTP Header geben jedoch Aufschluss darüber, ob die Daten synchron sind (RTP-Timestamp) oder Paketverluste aufgetreten sind. Wird TCP verwendet, können in diesem Header unter anderem Sequenznummern erfasst und damit an dieser Stelle zusätzlich Paketverluste detektiert werden. 4. Application Layer - MPEG-TS, H.264 Header der Applikation Schicht geben genaue Informationen über den Inhalt der Daten bzw. des Videos wieder. Im MPEG-TS Header wird signalisiert, welche Art von Video oder Audio enthalten ist. Wenn Daten oder Pakete verloren gegangen sind, kann man auf deren Inhalt und Relevanz zurückschlieÿen. Dazu kommen noch Zähler, ähnlich dem Continuity Counter, mit dem man eine Vertauschung oder Verlust von Paketen erkennen kann. Ein komplettes Netzwerkpaket, mit allen Headern ab dem Network Access Layer aufwärts, stellt die maximale Analysetiefe dar. Darüber hinaus ist es möglich, während der Analyse eines Paketes weitere Daten zu berechnen, die eine Aussagekraft haben. Diese abgeleiteten Werte werden im nächsten Abschnitt beschrieben Abgeleitete Werte Unter dem Begri abgeleitete Werte werden Daten zusammengefasst, die nicht in den Rohdaten eines Netzwerkpaketes enthalten sind. Darunter fällt zum Beispiel die Gröÿe des zu analysierenden Paketes. Mit der Gesamtpaketlänge und den Ankunftszeiten (Timestamp) des Paketes lässt sich die Datenrate des zu messenden Streams errechnen. Weiterhin lassen sich mit dem RTP-Timestamp und der Ankunftszeit des Paketes Verzögerungen (Delay) und Verzögerungsschwankungen (Jitter) berechnen. 1 ToS - Type-of-Service - Das Feld für die Priorisierung von IP-Datenpaketen 2 DSCP - Dierentiated Services Code Point - Schema zur Klassizierung der Dienstgüte von IP-Paketen 7.1 Spezikation der Analysetiefe 52

53 7 Evaluation Empfehlung Aufgrund der Tatsache, das ein Android SmartPhone mit begrenzten Ressourcen auskommen muss, wird für die Spezikation der Analysetiefe ein Resümee gezogen. Um bei einer Live- Messung Ressourcen zu sparen und keine unnötigen Berechnungen zu tätigen, ist es sinnvoll nur die Header des Paktes inklusive des Ankunftszeitstempels und der Paketgröÿe aufzuzeichnen. Alle weiteren Daten lassen sich in einem separaten Auswertungsschritt nachträglich berechnen. Das Überspringen von Headerinformation spart keine Ressourcen ein, da durch die Verkapselung der Header festgestellt werden muss, welcher Inhalt vorliegt. Bei diesem Vorgang können alle Informationen des Headers direkt aufgenommen werden Abschätzung der Videoparameter Bei den Videoparameter gilt es zu evaluieren, welche Informationen aus den Paketdaten des Video extrahiert werden können ohne das eigentliche Video zu dekodieren. Bei der Spezikation der Analysetiefe werden die Anwendungsdaten mit angegeben. Zu den Videodaten bzw. dem Transport von Videomaterial gehört der MPEG-TS Header. Die darin enthaltenen Daten geben Aufschluss über das übertragene Video und den verwendeten Codec sowie zum Beispiel den Abspielzeitpunkt des jeweiligen Paketes anhand der Program Clock Rate (PCR). Die Parameter der First Priority im ETSI-Standard TR [10] dienen der Dekordierbarkeit des Videos und geben einen ersten Anhaltspunkt für die Abschätzung der Parameter, die ein Video beeinussen können H.264 Ein Video, das H.264 codiert vorliegt und über ein Netzwerk gestreamt wird, ist nach dem MPEG-4/H.264 AVC Standard der ITU-T [15] in NAL-Units (Network Abstraction Layer) gekapselt. Einer der ersten Parameter, die nach der Rekonstruktion der NAL untersucht werden kann, ist der NAL Reference Indicator. Dies erlaubt die Aussage darüber, ob vorausgegangene oder nachfolgende Bilder auf diese NAL verweisen. Ein zweiter möglicher Parameter einer NAL ist das Feld Type. An dieser Stelle wird ein sogenannter IDR signalisiert. Insbesondere die Häugkeit ist für eine Videoanalyse interessant, da in der Regel bei jedem IDR ein I-Slice gesendet wird und damit Qualitätseinbuÿen durch vorherige Paketverluste kompensiert werden können. 7.2 Abschätzung der Videoparameter 53

54 7 Evaluation SPS Ein Header innerhalb der NAL-Unit stellt das Sequence Parameter Set dar. Mit dem SPS werden Informationen übertragen, die für eine Reihe von Bildern (Frames) einer Sequenz gedacht sind. Diese Informationen werden am Anfang der Sequenz übermittelt und beginnen in der Regel mit einem IDR. Nützliche Informationen aus diesem Set sind zum Beispiel die Bildgröÿe (Auösung), Prole und Level für das Video. PPS Ein weiterer Header ist das Picture Parameter Set. Durch das PPS werden bildbezogene Informationen übermittelt, die für das aktuelle Bild gültig sind. Da ein Bild aus mehreren Slices bestehen kann, muss ein PPS grundsätzlich vor allen Video Daten gesendet werden. Welcher Entropy-Kodierungsmodus verwendet wird oder ob bei einem übertragenen P-Slice oder B-Slice auf die Weighted Prediction zurückgegrien wird, ist Inhalt des PPS. Diese Daten sind für den Codec relevant, da solche Informationen zum dekodieren benötigt werden, lassen jedoch kaum eine Abschätzung des Videos zu. Slice Header Die Auswertung des Slice Headers liefert Informationen über das aktuell anzuzeigende Slice. Eine Kenngröÿe aus diesem Header ist der slice_type, der den Typ des Slice deniert. Es wird zwischen I-, P-, B-, SP- und SI-Slice unterschieden. Die Häugkeit von I-Slices gegenüber P- und B-Slices ist eine nützliche Information über die Kompressionsrate und gibt einen Aufschluss über die Wahrscheinlichkeit von Qualitätseinbuÿen bei Paketverlust Empfehlung Bei der Analyse von Videodaten sind die Informationen aus den Header von MPEG-TS und H.264 wichtige Parameter zur Abschätzung der Qualität. Die Daten aus dem MPEG-TS Header müssen aufgenommen werden, um eine Analyse des Inhalts durchführen zu können. Bei den H.264 Header Informationen ist es sinnvoll, nur auf die nötigsten Parameter zuzugreifen, da aufgrund der geringen Ressourcen eine vollständige Erfassung der Daten zu Performance Problemen führen [26]. Werden Daten aus dem H.264 Header erfasst, werden diese Parameter nach ihrer Wichtigkeit eingestuft. 7.2 Abschätzung der Videoparameter 54

55 7 Evaluation Die Priorisierung sieht wie folgt aus. H.264 Header Nr. Header Priorität 1. NAL - Network Abstraction Layer Stufe 2 2. SPS - Sequence Parameter Set Stufe 1 3. PPS - Picture Parameter Set Stufe 3 4. Slice Header Stufe 2 Tabelle 7.1.: Priorisierung der H.264 Header Eine Aufzeichnung des SPS Header liefert die meisten Daten zum Video. Der NAL und der Slice Header sind von besonderer Bedeutung, wenn Bildreferenzierungen und -Typen benötigt werden. Der PPS liefert am wenigsten Informationen zur direkten statistischen Auswertung, da dieser Header, wie im vorherigen Abschnitt beschrieben, überwiegend Parameter für den Codec bereit hält Architekturkonzepte für einen QoS/QoE Sensor Für die Entwicklung und Implementierung eines QoS/QoE Sensors, der die Funktionalität des SmartVideo Messkopfes aufweist, muss zuerst evaluiert werden, wie an die geforderten Parameter auf dem Android Betriebssystem gelangt werden kann. Es gibt verschiedene Ansätze, an Netzwerkdaten bei der Übertragung von IP-Video zu gelangen. Zusätzlich zur Machbarkeit muss abgeschätzt werden, wie hoch der Implementierungsaufwand gegenüber dem Nutzen ist. Die realisierbaren Ansätze auf einem Android SmartPhone sind folgende: Datenerfassung mit der Standard SDK API Sockets Direkt-Zugri RTP Sockets als Proxy-Implementierung Standard NDK API Raw-Socket Im Folgenden werden die realisierbaren Ansätze untersucht, um herauszunden, ob ein gewünschtes Ergebnis zu erreichen ist Ausgeschlossene Varianten Neben den hier aufgeführten Varianten, Netzwerkverkehr zu erfassen, existieren prinzipiell zwei weitere. Beide basieren auf der Verwendung eines Netzwerksniers. Ein Snier zeichnet 7.3 Architekturkonzepte für einen QoS/QoE Sensor 55

56 7 Evaluation Roh-Daten von der Netzwerkschnittstelle auf und speichert diese in einem binären Format. Eine Möglichkeit, an diese Rohdaten zu gelangen, bedient sich der App Shark. Diese steht im Android Market zur Verfügung. Nach Installation und der Möglichkeit Root-Befehle auf dem SmartPhone auszuführen, können Live-Messungen durchgeführt werden. Die Daten werden jedoch ausschlieÿlich in PCAP-Dateien auf der internen SD-Karte abgelegt. Eine Live-Analyse der Paketdaten ist nicht möglich, die PCAP-Dateien müssen für eine Analyse aufwendig eingelesen und verarbeitet werden. Je nach Messdauer existiert nicht genügend Arbeitsspeicher um die gesamte Datei einzulesen und im Ganzen zu untersuchen. Eine zweite Variante ist die Verwendung der Bibliothek libpcap, die unter anderem auch vom App Shark für Android und Wireshark für PCs verwendet wird. Die Bibliothek ist eine performante, in C programmierte Schnittstelle, um Paketdaten von der Netzwerkkarte auszulesen. Eine Portierung ist aufgrund der Gröÿe der Bibliothek und der aufwendigen Anbindung an die JNI-Schnittstelle von Android nicht geeignet, zumal das Ergebnis ebenfalls ein PCAP-ähnliches Format ist Standard SDK API Das Android Software Development Kit bietet Funktionen und Klassen an, um Daten innerhalb des Android System zu beschaen oder anzuzeigen. Dabei ist es möglich, Video- und Audio-Daten mit Hilfe von bereitgestellten Handlern zu benutzen oder die Daten an Applikationen (Mediaplayer) weiter zu reichen. Direkt-Zugri Bei einem Direkt-Zugri auf einen Stream wird die Streaming-Adresse (URL) des Servers benötigt. Diese setzt sich zusammen aus der IP-Adresse des Server und dem Port, sowie vorangestellt dem Streaming-Protokoll. Das SmartPhone fordert das Video über vorgegebene API- Aufrufe beim Streaming Server an, der wiederum das Video zurückschickt. Im folgenden Beispiel wird der Programmcode einer Activity unter Android gezeigt, die eine Instanz des Mediaplayers initialisiert, die geparste URL übergeben bekommt und anschlieÿend den Mediaplayer startet. 1 VideoView videoview = ( VideoView ) findviewbyid (R. id. VideoView ) ; 2 MediaController mediacontroller = new MediaController ( t h i s ) ; 3 mediacontroller. setanchorview ( videoview ) ; 4 5 Uri v i d e o = Uri. p a r s e ( " r t p : / / : " ) ; 6 videoview. s e t M e d i a C o n t r o l l e r ( m e d i a C o n t r o l l e r ) ; 7 videoview. setvideouri ( video ) ; 8 videoview. s t a r t ( ) ; Listing 7.1: Beispielcode für das Abspielen eines Video von einer RTP-Streaming URL 7.3 Architekturkonzepte für einen QoS/QoE Sensor 56

57 7 Evaluation Interne Handler übernehmen die Steuerung des Videos, sowie die Dekodierung. Der Mediaplayer ist in der Lage, das Video auf dem SmartPhone darzustellen. Möglichkeiten und Grenzen Die Möglichkeiten bei der Verwendung des Software Development Kits sind begrenzt. Man kann Videos abspielen und stoppen, die Quelle frei wählen und in der Regel zwischen zwei Streaming-Protokollen (UDP, RTP) entscheiden. Der Vorteil ist, dass mit wenig Aufwand ein gestreamtes Video auf einem Android SmartPhone darstellen werden kann. Die dahinter stehende API des Software Development Kit erstellt im Hintergrund neue Instanzen und initialisiert die nötigen Sockets. Der Nachteil dabei ist, dass ein Eingri in die Socket-Kommunikation, um an die übertragenen Daten zu gelangen und diese zu analysieren, nicht möglich ist Sockets Damit der Zugri auf die Nutzdaten des Videos ermöglicht wird, kann die Socket Erstellung selbst initiieren werden. Die Java-API bieten die Möglichkeit, IP sowie auch TCP/UDP und RTP Sockets zu erstellen. Zunächst wird ein Socket zwischen einem Server und einem Client aufgebaut. Als Beispiel soll an dieser Stelle ein Socket für das RTP-Protokoll dienen. In einem ersten Nachrichtenaustausch nach dem Initialisieren des Sockets muss der Client den Server informieren, dass ein Video gestreamt werden soll. Ist der Datenaustausch abgeschlossen, muss vom Streaming Server das Video in möglichst gleich groÿe Datenpakete der maximalen Gröÿe von 1500 Byte (MTU Gröÿe) aufgesplittet werden. In der Regel übernimmt diese Aufgabe ein Streaming Server wie zum Beispiel der Darwin Streaming Server. Dieser kann das Video, wie in Kapitel 4.1 beschrieben, in MPEG-TS kapseln und mit einer Paketgröÿe von in der Regel 1374 Byte verschicken. Abbildung 7.3.: Client-Server Aufbau mit Sockets Am SmartPhone werden die empfangenen Daten wieder zusammengesetzt, um diese dann weiterverarbeiten zu können. Ein mögliches Konzept mit RTP Sockets ist die Verwendung eines Proxy. Dieses Konzept wird im nächsten Abschnitt genauer untersucht. 7.3 Architekturkonzepte für einen QoS/QoE Sensor 57

58 7 Evaluation RTP Sockets als Proxy-Implementierung Das Konzept basiert auf einem Proxy zwischen dem Mediaplayer (Ziel) auf dem SmartPhone und einem Streaming Server (Quelle) mit Hilfe von RTP Sockets. Die Datenkommunikation und Signalisierung wird über die Protokolle RTP, RTCP bzw. RTSP abgewickelt. Abbildung 7.4.: Proxy Implementierung - Forschungsschwerpunkt VMA - Mark Hümeyer Der Mediaplayer richtet seine Anfrage an die Zwischenstation (Proxy), welche die Anfrage manipuliert an den Streaming Server weiterleitet. Die Manipulation der Anfrage begrenzt sich auf das Austauschen der Zieladresse und des Zielport. Die vorhandene IP-Adresse und der Port wird durch die IP-Adresse und den Port des Proxy Interface geändert. Der Streaming Server sendet das Video nach Vorgabe der manipulierten Anfrage an den Proxy zurück. Die Kommunikation zwischen dem Proxy und dem Mediaplayer läuft über eine interne Verbindung (Localhost) auf dem SmartPhone ab. Bei dieser Variante des Streamings sind die Video-Daten üblicherweise in RTP gekapselt. Der Proxy hat nun die Möglichkeit, durch Abgreifen der Daten eine Analyse vorzunehmen und relevante Daten zu speichern. Die eigentlichen Video-Daten werden nach der Analyse unverändert an den Mediaplayer durchgereicht, sodass der Mediaplayer die Video-Daten dekodieren und anzeigen kann. Da dieses Konzept auf RTP-Sockets aufbaut, kann eine maximale Analysetiefe bis zur RTP-Schicht stattnden. Weitere Informationen der darunterliegenden Netzwerkschichten lassen keine Analyse zu. In der Diplomarbeit von Marc Hümeyer Entwicklung eines Messsystems zur Analyse von H.264 Videostreams unter Android[22] wurde eine Implementierung als Proxy mit RTP-Sockets realisiert. Der für diese Master Thesis wichtige Abschnitt ist nicht die Auswertung der Daten aus dem Video-Stream, sondern das Erfassen und Analysieren von Daten aus den RTP-Sockets. Analyse der Architektur Die Activities dienen zur Darstellung der Oberäche und nehmen die URL für die Kommunikation mit dem Streaming Server an. Ein Streaming Handler dient als Schnittstelle zum Proxy 7.3 Architekturkonzepte für einen QoS/QoE Sensor 58

59 7 Evaluation und verbindet die Proxy-Instanz mit dem Streaming Server und dem Player. Jeder einzelne Protokoll Handler für RTP, RTCP und RTSP ist in der Lage, Protokolle auszuwerten und die Daten aufzubereiten. Die Nutzdaten der einzelnen Pakete können unter Verwendung weiterer Funktionen analysiert werden. Eine stark gekürzte Variante des Klassendiagramms mit den wichtige Elementen für diese Master Thesis ist in der folgenden Abbildung zu nden. Abbildung 7.5.: Gekürztes Klassendiagramm der Proxy Implementierung Möglichkeiten und Grenzen Der RTP-Socket aus der Proxy-Implementierung liefert die Paketdaten inklusive des RTP- Header, der vom Betriebssystem vorverarbeitet worden ist. Die Daten aus dem RTP-Header, wie Timestamp oder Sequenznummer, sind durch Zugri auf RTP-Header Strukturen erreichbar. Anschlieÿend können diese Daten für Analysezwecke verwendet werden. Die darunterliegenden Protokolle, wie UDP oder IP, wurden vom Betriebssystem verarbeitet und entfernt. Aus einem RTP-Socket können keine Informationen dieser Protokolle bezogen werden. Bei den Anwendungsdaten aus dem Paket sind weitere Analysen möglich, sodass das in RTP gekapselte MPEG-TS Paket mit eigenen Routinen ausgewertet werden kann. Auÿerdem gelangt man bei der Auswertung des MPEG-TS Paketes an die H.264 Video-Daten um Bildtyp, Codec oder Auösung des Videos zu ermitteln. Diese Implementierung kann jedoch für diese Master Thesis nicht herangezogen werden, da bei IPTV nicht sichergestellt werden kann, das grundsätzlich über RTP gestreamt wird. Zusätzlich sollte an dieser Stelle erwähnt werden, das der Nutzer in der Regel keinen Zugri oder Einuss auf einen Streaming Server oder auf das Video hat. Auÿerdem ist eine Analyse der Header unterhalb von RTP nicht möglich. Eine Erweiterung der Sockets, z.b. durch Hinzufügen von UDP Handler, für die Unterstützung von UDP ist nicht sinnvoll, da es keine ausreichende Unterstützung für die Weiterverarbeitung der UDP-Pakete beim Mediaplayer unter der Android SDK gibt. 7.3 Architekturkonzepte für einen QoS/QoE Sensor 59

60 7 Evaluation Standard NDK API Die letzte Implementierungsvariante für einen QoS/QoE Sensor ist der Zugri über das Native Development Kit von Android. Das NDK bietet, anders als die SDK durch Java, mehr Schnittstellen zum System, ohne zusätzlich Bibliotheken aufbauen zu müssen. Viele Schnittstellen, darunter Raw-Sockets, bringt der Kernel des Android Betriebssystems standardmäÿig mit. Diese gehören zu den System-Bibliotheken von C/C++ und sind zum vollständigen Erfassen von Netzwerkpaketen konzipiert. Abbildung 7.6.: Socket Mapping Raw-Sockets setzen, wie in der Abbildung 7.6 gezeigt, auf dem Network Access Layer auf und ermöglichen einen Zugri auf Daten der Schicht 2 (Ethernet) des ISO/OSI Modells. Raw- Sockets sind im wesentlichen Sockets, die unter der SDK ebenfalls verfügbar sind, jedoch mit Einschränkungen. Im Folgenden eine Tabelle mit den wesentlichen Unterschieden von Raw- Sockets der SDK und NDK. Raw-Socket Bibliotheken Funktion SDK NDK Bibliothek RockSaw (Java) sys/socket.h (Linux) Betriebssystem alle Plattformen Android (Linux) Rechte benötigt Root Rechte benötigt Root-Rechte Layer 3 (IP) 2 (Ethernet) (Linux) 4 (TCP/UDP) Tabelle 7.2.: Gegenüberstellung der SDK und NDK im Bezug auf Raw-Sockets 7.3 Architekturkonzepte für einen QoS/QoE Sensor 60

61 7 Evaluation Es wird deutlich, das Raw-Sockets bei der SDK nicht direkt möglich sind, sondern erst mit dem Hinzufügen der Bibliothek RockSaw zur Verfügung stehen. Weiterhin werden für beide Varianten erweiterte Administratorenrechte erforderlich, die allerdings bei der SDK durch die Java Abstraktionsschicht nur ein Socket auf Layer 3 (IP) oder höher zulassen und durch die GUI nicht möglich sind. Ein Socket auf Layer 2 (Ethernet) wird nur durch die NDK realisiert und liefert die gewünschten Netzwerkpakete. Eine Implementierung mit Raw-Sockets für Android wird im nächsten Abschnitt genauer erläutert. Raw-Socket Implementierung Mit Raw-Sockets ist das Programm in der Lage, Netzwerkpakete zu empfangen, welche vom Betriebssystem nicht verarbeitet wurden und inklusive aller Header an die Applikation weitergegeben werden. Das Anlegen eines solchen Socket unter C/C++ für das Android System lässt sich anhand des nächsten Codeausschnittes erklären. 1 //Open Socket 2 sock = socket (PF_PACKET, SOCK_RAW, htons (ETH_P_ALL) ) ; 3 i f ( sock == 1 ) 4 { 5 cout<<" Error : Could not c r e a t i n g s o c k e t "<<e n d l ; 6 e x i t ( 1 ) ; 7 } 8 9 //Check I n t e r f a c e Name 10 memset(& i f i n f o, 0, s i z e o f ( i f i n f o ) ) ; 11 s t r c p y ( i f i n f o. ifr_name, i n t e r f a c e. c_str ( ) ) ; 12 i f ( i o c t l ( sock, SIOCGIFINDEX, & i f i n f o )== 1) 13 { 14 cout<<" Error : [ Function : e_open ( ) ] IOCTL > SIOCGIFINDEX No such device "<<endl ; 15 e x i t ( 1 ) ; 16 } // Parameterset f o r Socket 19 memset(& s o c k i n f o, 0, s i z e o f ( s o c k i n f o ) ) ; 20 s o c k i n f o. s l l _ f a m i l y = PF_PACKET; 21 s o c k i n f o. s l l _ p r o t o c o l = htons (ETH_P_ALL) ; 22 s o c k i n f o. s l l _ i f i n d e x = i f i n f o. i f r _ i f i n d e x ; //Bind Socket to I n t e r f a c e 25 i f ( bind ( sock, ( s t r u c t sockaddr )&s o c k i n f o, s i z e o f ( s o c k i n f o ) )== 1) 26 { 27 cout<<" Error : Could not bind s o c k e t to i n t e r f a c e "<<e n d l ; 28 e x i t ( 1 ) ; 29 } Listing 7.2: Beispielcode für die Implementierung eines RAW-Socket in C/C++ unter Android NDK Am Anfang wird zuerst ein Socket mit der Funktion socket() geönet. Dort wird die Paketklasse PF_PACKET angegeben, die ein Packet Interface auf Geräte-Level (Treiber-Ebene) ermöglicht. SOCK_RAW ist die Art des Sockets, hier der sogenannte Raw-Socket. Eine Alternative an dieser Stelle ist der Eintrag SOCK_DGRAM, der einen Socket ab Layer 3 (IP) 7.3 Architekturkonzepte für einen QoS/QoE Sensor 61

62 7 Evaluation deklariert. Die Informationen ETH_P_ALL weisen an, Header ab Layer 2 mit allen Optionen und Feldern die vorhanden sind, durch zureichen. [25] Im mittleren Abschnitt des Codebeispiels wird das Interface auf Existenz geprüft und initialisiert. Danach wird das Interface ebenfalls auf die Paketklasse PF_PACKET eingestellt, damit es anschlieÿend mit dem Socket verbunden werden kann (letzter Abschnitt). Ist der Socket erstellt, kann mit der C/C++ Funktion recvfrom() jedes Paket einzeln aus dem Puer des Treibers ausgelesen werden. Aufbau und Architektur Aufgrund der erforderlichen Administratorenrechte ist es nur möglich, die gewünschte Funktionalität in zwei Teilen zu implementieren und die Anwendung zu splitten. Der erste Teil beschäftigt sich mit der Oberäche der App und kann ausschlieÿlich mit eingeschränkten Rechten aufgerufen werden. Der zweite Teil arbeitet als Hilfsprozess (SmartVideo Probe) mit Root- Rechten um die Netzwerkdaten mit Hilfe von Raw-Sockets aufzuzeichnen. Bei der Abbildung 7.7 wird der Aufbau schematisch dargestellt. Der Streaming Server streamt Video Daten in einem beliebigen Format für IPTV an das SmartPhone und der SmartVideo Probe kann eine Analyse der Netzwerkdaten vornehmen. Die Pakete werden vorverdichtet in einer CSV-Datei gespeichert, sodass anschlieÿend eine weitere Analyse über die Android App durchgeführt werden kann. Abbildung 7.7.: Architektur eines QoS/QoE Monitoring Sensor Dieses Konzept ist ein passiver Sensor, denn es ndet keine Interaktion zwischen der Android App und dem Streaming Server statt. 7.3 Architekturkonzepte für einen QoS/QoE Sensor 62

63 7 Evaluation Möglichkeiten und Grenzen Mit dieser Variante für einen Messkopf als QoS/QoE Sensor kann eine ausreichende Analysetiefe erreicht werden, wie sie in Abschnitt 7.1 evaluiert worden ist. Es lassen sich Netzwerkdaten ab Layer 2 (Ethernet) mit Raw-Sockets abgreifen. Alle Header müssen mit eigenen Strukturen geparst und der jeweilige Payload an die nächste Funktion übergeben werden. Passende Strukturen für die Header Ethernet und IP gehören zu den Standard Bibliotheken unter Android und Linux. Alle anderen Header müssen auf eigene Implementierungen der Strukturen zurückgreifen. Der SmartVideo Probe kann als Prozess im System permanent laufen oder bei Bedarf gestartet werden. Mit einer Zeitsteuerung sind Intervall-Messungen realisierbar, mit denen sich Ressourcen einsparen lassen. 7.3 Architekturkonzepte für einen QoS/QoE Sensor 63

64 8 Implementierung 8. Implementierung In diesem Kapitel wird das Konzept des QoS/QoE Monitoring Sensors, wie er im Kapitel 7 beschrieben ist, implementiert. Dabei wird auf die Variante mit der Standard NDK API und den Raw-Sockets zurückgegrien, da diese sich als geeignete Möglichkeit der Implementierung herausgestellt hat. In den nächsten Abschnitten wird auf die Entwicklungsumgebung, Features und das Software Design genauer eingegangen, sowie auf einzelne Abläufe und Sequenzen, die zur Verdeutlichung der Umsetzung wichtig sind. Weiterhin wird die entwickelte Android App vorgestellt und das Konzept der graschen Oberäche erläutert. Am Ende dieses Kapitels benden sind Testergebnisse und Verikationen der App und von den Messungen Entwicklungsumgebung Als Basis der Entwicklungsumgebung dient das HTC Desire mit der Android Version (Gingerbread). Das Android SmartPhone besitzt einen 1GHz ARM Prozessor und verfügt über 768 MB RAM Arbeitsspeicher. Das Android Betriebssystem Gingerbread liegt als CustomRom CynanogenMod CM7 (7.0.3) mit der Su-Binärdatei in der Version vor. Das Android SDK liegt zum Zeitpunkt der Entwicklung in der Revision 12 und das NDK in der Revision 5c vor. Als Softwareentwicklungsumgebung wird auf das Betriebssystem Kubuntu (Natty Narwal) mit installiertem Eclipse Galileo (Version 3.5.2) und dem Android Development Tool (ADT) zurückgegrien Zu implementierende Features Wie aus dem Kapitel 7 Evaluation hervorgegangen ist, wird die Android App in zwei Teilanwendungen gesplittet. Der eigentliche Messkopf wird unter dem Android NDK implementiert. Bei der Benutzeroberäche wird auf das Android SDK zurückgegrien. Damit die beiden Anwendung miteinander kommunizieren können, bzw. zwischen Ihnen Daten ausgetauscht werden können, muss eine Schnittstelle deniert werden. 64

65 8 Implementierung Von diesem Punkt betrachtet, lässt sich folgendes gekürztes Lastenheft generieren: Android App SmartVideo Probe for Android Entwicklung einer Raw-Socket Anwendung mit dem Android NDK (sv_probe) Entwicklung einer Ansteuerung der Anwendung sv_probe Erfassen der messspezischen Parameter durch den Benutzer (z.b Messdauer) Speichern der Messdaten auf dem SmartPhone (CSV) Darstellen der gesammelten Messungen Darstellen der Messdaten pro Messung Grasche Darstellung der QoS-Parameter (Datenrate, Paketverlust, usw.) Loggen möglicher Zustände Anzeige von Statusinformationen Der erste Schritt zur Entwicklung der Anwendung mit dem Android NDK besteht aus der Umwandlung Linux-spezischer Funktionen des Embedded Systems in Android-spezischer Funktionen für den SmartVideo Messkopf auf dem SmartPhone[26]. Die Ansteuerung des Messkopfes wird durch Konsolen Parameter als Übergabewerte und über eine Kongurationsdatei realisiert. Die Parametrisierung erfolgt durch eine Implementierung eines graschen Interfaces. Die Messdaten werden in einer einzelnen CSV-Datei pro Messung abgelegt. Auf die Eigenschaften und Funktionen wird zu einem späteren Zeitpunkt in diesem Kapitel eingegangen. Zunächst wird das Software Design der Android App beschrieben Software Design Das Software Design ist von wichtiger Bedeutung bei der Umsetzung verschiedener Funktionen und trägt entscheidend zur Qualität der realisierten Implementierung bei. Aufgrund der Komplexität der Anwendung muss darauf geachtet werden, dass der Code der Software übersichtlich und funktional bleibt. Weiterhin wurde bei der Implementierung auf die Vermeidung von redundantem Code Rücksicht genommen, da oft wiederholende Funktionen und Aufgaben bei der Verarbeitung von Messdaten entstehen. Im Folgenden wird auf das Klassendiagramm der Software eingegangen und deren Aufbau erläutert. 8.3 Software Design 65

66 8 Implementierung Klassendiagramm Abbildung 8.1.: Klassendiagramm SmartVideo Probe for Android 8.3 Software Design 66

67 8 Implementierung Die Kernklasse der gesamten Implementierung ist die CoreLib-Klasse. Sie bündelt verschiedene Attribute und Methoden und stellt sie allen Activities zur Verfügung. Die Attribute dieser Klasse werden als quasi globale Variablen behandelt. Grundsätzliche Funktionen sind Dateioperationen, wie zum Beispiel Kopieren, Einlesen und Prüfen von Dateien. Auÿerdem werden Check-Routinen von dieser Klasse übernommen, da von verschiedenen Stellen der Anwendung Überprüfungen von Einstellungen durchgeführt werden müssen. Unter diese Check-Routinen fällt unter anderem die Überwachung der SD-Karte (ob diese vorhanden und beschreibbar ist). Das Erstellen von Skripten für die Konsole des Android Systems und das anschlieÿende Anstoÿen einer Messungen durch den sv_probe wird ebenfalls in dieser Klasse behandelt. Zusätzlich enthält die Klasse noch weitere Unterklassen, um Methoden zu kapseln. Diese sind: ScriptRunner Generisches Abhandeln von Skripten auf der Konsole. Die Klasse SkriptRunner ist in der Lage, eine Shell zu starten und Befehle als Root oder als normaler Benutzer auszuführen. Hauptsächlich dient er dazu, Skripte auszuführen. Settings Methoden zur Vereinfachung der Speicherung von Daten (Preferences) über die Android eigene Schnittstelle. GeoLoc Handler-Klasse zur Bestimmung der Position und Umwandeln der Informationen für Google Maps. Enthält auch die Klasse, um das Overlay auf der Karte darzustellen und somit die Position anzuzeigen. Die Kernklasse zur Berechnung der Daten ist die InspectionLib. Sie übernimmt Berechnungen und wird durch die Activity InspectionActivity gesteuert. Bestandteil dieser Klasse sind die Unterklassen constantdata und variabledata, die die eigentlichen Messwerte berechnen. Sind die Messwerte berechnet, werden von der Activity die Tabs zur Anzeige der Messwerte geladen. Dabei greifen die Activities auf die Arrays der Klasse InspectionLib zu, um erneutes Berechnen nach dem Wechsel einer Activity zu vermeiden. Die beiden Klassen View und InspectionActivity sind die beiden Grundelemente der dargestellten Oberäche, da die Anwendung wegen der Übersichtlichkeit in Tabs strukturiert ist und die einzelnen Screens in Tabs hinein geladen werden. Die LogActivity und der BroadcastReceiver sind eigenständige Programmteile und behandeln das gesamte Logging-System der Anwendung. Die LogActivity ist zum Anzeigen der Einträge auf dem SmartPhone zuständig. Der BroadcastReceiver übernimmt als Service alle Intents und speichert sie persistent auf die SD-Karte. 8.3 Software Design 67

68 8 Implementierung Programmstrukturen und Abläufe Sequenzdiagramm Um eine Messung zu starten, müssen zunächst Prüfungen und Test durchlafen werden, bevor Benutzereingaben getätigt werden können. Es kann sonst der Fall eintreten, das Parameter nicht vorliegen und ein Fehlerverhalten oder ein nicht funktionieren der Anwendung ausgelöst wird. Die Funktionen (mit Ausnahme einer Messung) sind, insofern eine SD-Karte vorhanden ist, uneingeschränkt und direkt nutzbar. Bei einer Messung hingegen müssen vorher die nötigen Einstellungen getätigt werden, um sie durchführen zu können. Abbildung 8.2.: Sequenzdiagramm vom Start der App bis zur Messung Die Abbildung 8.2 zeigt das Sequenzdiagramm ab dem Start der Android App, bis zum Anstoÿen einer Messung. Dabei ist ersichtlich, das bis zu den Benutzereingaben nur Einstellungen und Dateien der Anwendung überprüft werden. Geprüft wird unter anderem, ob ein GPS Signal 8.3 Software Design 68

69 8 Implementierung verfügbar ist, ob die Preferences korrekt sind, eine Seriennummer vergeben worden ist und die Binärdateien vorhanden sind. In der Activity MeasurementActivity werden Benutzereingaben entgegengenommen. Dabei werden, wie in der Abbildung 8.5 zu sehen, die Parameter aus der probe.conf vom Benutzer eingestellt. In der Eingabemaske kann zum Schluss die Kongurationsdatei gespeichert werden, sodass das Submenü aus der Activity View für eine Messung freigeschaltet wird. Durch Anstoÿen einer Messung wird ein Hintergrund Thread initiiert, der den Messkopf initialisiert und ein Skript zur Ausführung von externen Programmen als Root angelegt. Anschlieÿend wird mit Hilfe der ScriptRunner-Klasse eine Laufzeitumgebung mit den Rechten als Root gestartet. Innerhalb dieser Laufzeitumgebung wird das Skript ausgeführt und der sv_probe gestartet. Dieser liest die probe.conf ein und kann mit der Messung letztendlich beginnen. Programmablaufplan Der Programmablaufplan stellt die Initialisierungsphase des App aus dem Sequenzdiagramm genauer dar. Als erste Funktion wird eine Überprüfung des GPS-Sensors durchgeführt. Ist dieser aktiv, wird versucht eine exakte Positionsbestimmung zu erlangen. Anschlieÿend werden die Preferences auf Richtigkeit und Vollständigkeit getestet. Zu diesen Einstellungen gehört auch die Seriennummer des Messkopfes. Die Seriennummer muss zur eindeutigen Identikation des Messkopfes immer vorhanden sein, sollte das nicht der Fall sein (Neuinstallation), wird über die Testroutine eine Seriennummer angelegt. Die meisten Funktionen der App sind abhängig davon, ob eine externe Speicherkarte vorhanden ist. Dazu wird überprüft, ob eine Speicherkarte im SmartPhone existiert. Ist eine vorhanden, wird kontrolliert, ob sie beschreibbar ist. Erst durch diese Routine werden alle Funktionen freigeschaltet. Die nächste Prüfung betrit den Zugang zum SmartPhone. Es wird überprüft, ob Root- Befehle ausführbar sind und das Programm su im System vorhanden ist. Als letzte Überprüfungsroutine werden die Binärdateien busybox 1 und sv_probe installiert, insofern diese noch nicht vorhanden sind. Die Funktionen Get Available Interfaces und Generate Measurement ID gehören zu der Activity MeasurementActivity und werden bei jedem Aufruf dieses Tabs durchgeführt. Dabei überprüft die erste Funktion die momentan aktiven und verbundenen Interfaces auf dem Smart- Phone. Die Liste der zur Verfügung stehenden Interfaces wird als sogenannter Spinner 2 dem Benutzer dargestellt. Die Measurement ID ist eine sich laufend ändernde MD5-Checksumme des aktuellen Unix-Zeitstempels, um eine möglichst eindeutige Kennung der Messung zuordnen zu können. Beide Werte werden direkt in die Kongurationsdatei probe.conf eingetragen. 1 Busybox - Ein unter der GPL stehendes Terminal Programm mit den meistgenutzten UNIX Befehlen in einer Datei 2 Spinner - Eine Art Auswahlmenü als Overlay über die Activity 8.3 Software Design 69

70 8 Implementierung Abbildung 8.3.: Programmablaufplan vom Start der App bis zu den Benutzereingaben 8.4. Verzeichnisstruktur Für die Android App gibt es zwei Verzeichnisstrukturen im Dateisystem auf dem Smart- Phone, die für die Ausführung der App nötig sind. Es wird zwischen intern und extern unterschieden. Intern Der interne Bereich ist der Ordner, in dem die App jegliche Daten und Dateien für die eigene Verwendung ablegt. Darunter fallen auch Kongurationsdateien und Datenbankdateien. Der Ordner bendet sich auf dem SmartPhone unter /data/data/[app]. Der interne Bereich der App ist für keinen anderen Benutzer und keine andere App einsehbar, da er mit eigenen Benutzerrechten für diese App belegt ist. Um eine ordnungsgemäÿe Funktion sicherzustellen, müssen für die App folgende Ordner und Dateien vorliegen: 8.4 Verzeichnisstruktur 70

71 8 Implementierung com.smartvideo.probe/ cache/ les/ lib/ busybox smartvideo_probe.sh sv_probe shared_prefs/ com.smartvideo.probe_preferences.xml SmartvideoProbe.xml Der Ordner cache dient zum Zwischenlagern von Skripten und Binärdateien. In der Implementierung liegen hier die Dateien busybox und sv_probe. Letztere stellt das Kernmodul des QoS/QoE Monitoring Sensors dar. Das Skript smartvideo_probe.sh dient zur Ausführung der sv_probe, da mit diesem Skript und busybox die Root-Rechte für sv_probe ermöglicht werden. Im Unterverzeichnis shared_prefs lagern die Kongurationsdateien für die Android App. Dort werden persistent die Einstellungen im XML-Format gespeichert. Extern Als externer Bereich wird der Ordner /Probe auf der SD-Karte deklariert, da die SD-Karte ein externer Datenträger im System ist. Die Daten in diesem Ordner sind für die korrekte Ausführung der App nötig. Ist keine SD-Karte oder die folgende Verzeichnisstruktur nicht vorhanden, kann die App zwar ausgeführt werden, jedoch ist der Funktionsumfang stark minimiert. Probe measurement _ csv logging.log probe.conf Die probe.conf beinhaltet die Einstellungen für eine Messung und ist notwendig um eine Messung zu initiieren. Der Aufbau der Kongurationsdatei ist im Anhang A.1 beispielhaft aufgeführt. Die Logging-Datei ist zentraler Bestandteil des Logging-System in der App. Ist die Datei nicht vorhanden, wird das Logging ausgeschaltet. Die eigentlichen Messdaten aus den Messungen werden im Unterverzeichnis measurement abgelegt. Der Aufbau des Dateinamen ist: [Unix Zeitstempel]_[Mess_ID].csv. In der Datei benden sich die Messwerte komma-separiert. 8.4 Verzeichnisstruktur 71

72 8 Implementierung 8.5. Grasche Oberäche Die grasche Oberäche ist in verschiedene Activities aufgeteilt. Die folgende Abbildung zeigt alle Activities der App SmartVideo Probe for Android und deren Struktur innerhalb des Programms. Abbildung 8.4.: Programmstruktur und Auistung aller Activities der App SmartVideo Probe for Android Probe Beim Programmstart wird zunächst die Activity Probe gestartet. Diese enthält hauptsächlich als Thread ausgelagert den Code für die Darstellung eines Splashscreens während des Startvorgangs der App. Zusätzlich werden im Hintergrund weitere Operationen und Überprüfungen zur Initialisierung der App durchgeführt. Eine Überprüfung der GPS Einstellungen, wie sie im Abschnitt beschrieben wurde, wird an dieser Stelle vorgenommen. Im Hintergrund wird automatisch die Activity View geladen. View Die Activity View ist zentraler Bestandteil der App. Sie verwaltet die Tabs mit den Activities MeasurementActivity, DatabaseActivity, MapsActivity und LogActivity, die zur eigentlichen Darstellung der Informationen innerhalb der App dienen. In der View werden alle Systeminformationen überprüft und Einstellungen abgefragt. Auÿerdem beinhaltet View den Thread 8.5 Grasche Oberäche 72

73 8 Implementierung für die Steuerung der Messungen und verwaltet die Einstellungen für das Submenü des Smart- Phone. Ist die Kongurationsdatei probe.conf vorhanden und das darin angegebene Interface momentan aktiv, wird der Eintrag des Submenüs für den Start einer Messung freigeschaltet. Im Folgenden gezeigt sind die Screenshots der Tabs zur Veranschaulichung. Abbildung 8.5.: MeasurementActivity Abbildung 8.6.: DatabaseActivity Abbildung 8.7.: MapsActivity Abbildung 8.8.: LogActivity 8.5 Grasche Oberäche 73

74 8 Implementierung MeasurementActivity Die MeasurementActivity ist das Interface zur Erstellung der Datei probe.conf. In dieser Activity werden alle Einstellungen abgefragt und auf Plausibilität überprüft. Zu den automatisch generierten Einstellungen gehören die Seriennummer der App, die GPS-Positionsdaten und eine Liste mit aktuell verfügbaren Netzwerkschnittstellen. Sind alle Parameter eingestellt, kann mit dem Butten Save am Ende des Bildschirms die Kongurationsdatei angelegt werden. DatabaseActivity Wurden Messungen aufgezeichnet, sind diese im externen Verzeichnis /Probe/measurement auf der SD-Karte gespeichert. Dieses Verzeichnis wird geparst und alle Messungen nach ihrer Erstellungszeit dargestellt. Dabei wird die eindeutige Mess-ID vorangestellt und die Gröÿe der Messung ausgerechnet. MapsActivity Die MapsActivity dient zur Darstellung der eigenen Position und ist mit dem Kartendienst von Google verknüpft. Durch die Geo-Location des GPS Empfängers wird die Position ermittelt und anschlieÿend mit einem Karten-Overlay auf der Karte angezeigt. LogActivity Zum Anzeigen aller Logging-Einträge, die im System erfasst worden sind, dient die LogActivity. Sie parst alle Logging-Einträge der Datei logging.log und zeigt diese in einer aufbereiteten Darstellung an. Der Inhalt der Datei logging.log ist im Anhang A.2 als Auschnitt einer geloggten Messung aufgeführt. InspectionActivity Ähnlich wie die Activity View verhält sich die Activity InspectionActivity. Sie verwaltet die Tabs der Activities InspectionConfActivity, InspectionConstActivity, InspectionVarActivity und InspectionGraphicsActivity. Diese Tabs stellen die Messergebnisse grasch aufbereitet in den Kategorien Konguration, statische Parameter, variable Parameter und Diagramme dar. Des Weiteren bildet sie das Kernmodul der Berechnung aller benötigten Parameter. Auf der folgenden Seite werden die vorhandenen Tabs dieser Activity dargestellt. 8.5 Grasche Oberäche 74

75 8 Implementierung Abbildung 8.9.: InspectionConf Activity Abbildung 8.10.: InspectionConst Activity Abbildung 8.11.: InspectionVar Activity Abbildung 8.12.: InspectionGraphics Activity InspectionConfActivity In dieser Activity werden alle Kongurationsparameter zusammengefasst. Zum Einen die Parameter der CSV-Messdatei, wie zum Beispiel der Messzeitpunkt oder die Dateigröÿe. Zum Anderen auch die Parameter der probe.conf. Der einzige kalkulierte Wert ist die Dauer der Berechnung aller QoS-Parameter durch die Analyse der Messdatei auf dem SmartPhone. Wie auf der Abbildung 8.9 werden, durch die geringe Auösung des SmartPhone Displays nicht 8.5 Grasche Oberäche 75

76 8 Implementierung mehr zusehen, die GPS-Positionsdaten angezeigt. Mit dem Submenü, welches durch Betätigen der Menü-Taste des SmartPhone aufgerufen wird, kann sich der Standort zum Zeitpunkt der Messung angezeigt werden lassen. InspectionConstActivity Die konstanten Parameter einer Messung werden in der Activity InspectionConstActivity separiert und nach den einzelnen aufgezeichneten Layern dargestellt. Angefangen mit dem Layer 2 werden nur die Layer angezeigt, die auch detektiert und aufgezeichnet worden sind. In dieser Activity werden Messwerte bis zum MPEG-TS Header tabellarisch aufgeführt. Unter diesen Parametern bendet sich auch der verwendete Video- und Audio-Codec innerhalb des Streams. InspectionVarActivity Bei den sogenannten variablen Messdaten der einzelnen Pakete werden in dieser Activity die statistischen Werte zusammengefasst. Unter den statistischen Werte der variablen Messdaten versteht man zum Beispiel die Anzahl an empfangenen Paketen, die durchschnittliche Paketlänge in Bytes oder die exakte Messdauer. Auÿerdem werden erste QoS-Parameter wie Paketverlust berechnet und eine erste Abschätzung der QoE durch den Mean Opinion Score (MOS) durchgeführt. Dieser MOS spiegelt eine Abschätzung der QoE aufgrund der QoS-Parameter wieder und ist nur ein vorläuger Wert. Eine Verizierung des MOS mit BT.500 Messungen muss anschlieÿend durchgeführt werden. InspectionGraphicsActivity In der letzten Activity innerhalb der Tab-Activity InspectionActivity liegt die InspectionGraphicsActivity. Hier werden Graken zur Verfügung gestellt, die aus den Messdaten mit Hilfe der freien 3 AChartEngine-Bibliothek generiert werden können. Diese Bibliothek wird mit Hilfe der Handler Klasse LineChart angesprochen. Dabei werden die berechneten und in Arrays vorliegenden Werte, wie Datenrate und Paketverlust, in sogenannte Datasets aufbereitet und der Funktion zum Darstellen der Graken aus der Bibliothek übergeben. Die Übergabefunktion der Daten an die AChartEngine-Bibliothek verdeutlicht die folgende Zeile Java-Code. 1 ChartFactory. g e t L i n e C h a r t I n t e n t ( ctx, g e t D a t a s e t ( c h a r t ), getrenderer ( ) ) ; Listing 8.1: Funktionsaufruf zum Zeichnen der Graken mit Hilfe der AChartEngine-Bibliothek 3 AChartEngine steht unter der Apache 2.0 Lizenz (Quelle: AChartEngine) 8.5 Grasche Oberäche 76

77 8 Implementierung Dabei ist ctx der aktuelle Kontext der Android App, mit dem die Grak-Bibliothek den Focus der App erhält. Die Methode getdataset(chart) bereitet die Messdaten für die Bibliothek auf, wobei der Übergabeparameter die aktuelle Grak und dementsprechend den Datensatz angibt. Die letzte Methode getrenderer() gibt die Achsenbeschriftung, Farbe und Skalierung der Graken im Allgemeinen an. Durch den gezeigten Aufruf der Bibliothek und der vorhandenen Datensätze aus den QoS- Analysen lassen sich folgende Graken (Abbildung 8.12) darstellen: Streamrate Darstellung der Datenrate des Streams für die gesamte Messdauer in Intervallen von einer Sekunde. Packetloss Der aufgetretene Paketverlust bei einer Messung pro Sekunde. Jitter Average Die Verzögerungsschwankung der einzelnen Pakete im arithmetischen Mittel berechnet. Jitter RFC3550 Die Verzögerungsschwankung der einzelnen Pakete berechnet nach RFC Interarrival Delay Die Darstellung des Interarrival Delays der empfangenen Pakete. Die Graken sind als Screenshot im Anhang A.5 zu nden. Preferences Der Einstellungsdialog Preferences ist für jegliche systemweite Einstellung zuständig. Erreichbar sind diese Einstellungen durch das Submenü. Alle Parameter werden automatisch vom Android System persistent gespeichert. Die Daten liegen, wie im Abschnitt 8.4 beschrieben, im internen Verzeichnis /data/data/com.smartvideo.probe/shared_prefs und dort in der Datei com.smartvideo.probe_preferences.xml. StatsActivity Bei der StatsActivity handelt es sich um eine Zusammenfassung diverser Informationen rund um das System. Es werden Daten zur CPU, Arbeitsspeicher, Rechteverwaltung und Versionierung der Binärdateien (sv_probe und busybox) angezeigt. Auÿerdem wird der Zustand des externen Verzeichnis überprüft und angezeigt. 8.5 Grasche Oberäche 77

78 8 Implementierung BroadcastReceiver Als komplett alleinstehendes Element arbeitet der BroadcastReceiver global über die gesamte App. Er ist Intent-gesteuert und fungiert als Service im Hintergrund. Alle Methoden, die einen Intent absetzen, der den Filtereigenschaften für den BroadcastReceiver in der Android- Manifest.xml entspricht, starten automatisch den BroadcastReceiver. Dieser übernimmt das gesamte Logging der App und kann systemweit Daten aufnehmen. VideoActivity Diese Activity ist eine Teilportierung der Diplomarbeit von Marc Hümeyer [22] und ist kein Bestandteil dieser Master Thesis. Das Konzept dieser Master Thesis ist es, Messungen von Video Streams durchzuführen, die zum SmartPhone gestreamt werden. Dabei kann der Stream IPTV sein und somit Live-TV Bilder enthalten. Mit dieser Activity lässt sich ein Video von einem Streaming Server (Darwin Streaming Server) anfordern und anzeigen. Dabei beschränkt sich das Angebot auf Video-on-Demand über RTP. Die Portierung umfasst lediglich die RTP-, RTCP- und RTSP-Handler und die Ansteuerung dieser Handler in der entwickelten Activity VideoActivity. Aufrufbar ist die Activity über das Submenü der Activity View. Wie in der folgenden Abbildung zu sehen wurde eine Oberäche für die Master Thesis entwickelt, sodass ein Video ausgewählt und gestartet werden kann. Das Video wird in der oberen Hälfte des Bildschirms angezeigt. Abbildung 8.13.: VideoActivity im Abspielmodus 8.5 Grasche Oberäche 78

79 8 Implementierung 8.6. SmartVideo Probe Der SmartVideo Messkopf wurde im Kapitel 5.2 detailliert betrachtet und im Abschnitt 8.2 wurde bereits kurz auf die implementierende NDK-Anwendung sv_probe eingegangen. In diesem Kapitel wird diese Implementierung genauer beschrieben und darauf eingegangen, wie diese im System umgesetzt wurde Programmablaufplan Abbildung 8.14.: Programmablaufplan der NDK-Anwendung sv_probe 8.6 SmartVideo Probe 79

80 8 Implementierung Der Programmablaufplan des implementierenden sv_probe ähnelt in der Struktur der Embedded Version aus Kapitel 5.2. Es werden nach dem Starten der Anwendung die nötigen globalen Variablen gesetzt. Nach einer Prüfung der Argumente, mit denen die Anwendung gestartet worden ist, kann das Programm in den Deamon-Modus versetzt werden. Deamon-Modus bedeutet, dass das Programm losgelöst von jeglichen Vater-Prozessen (mit Ausnahme des Init-Prozesses) arbeitet und als vollständiger Hintergrundprozess betrachtet werden kann. Der Vorteil ist, dass mit dieser Möglichkeit der Messkopf in der Lage ist, Intervall- oder Dauermessungen durchzuführen und das System nicht blockiert. Ein elementarer Unterschied zu dem Programmablaufplan der Embedded Version stellt das Fehlen folgender Funktionen dar: Promiscuous-Mode Das Setzen der Netzwerkkarte in einen Empfangsmodus, sodass alle Netzwerkpakete empfangen werden können, die sich um Netz benden. Die Funktion wird von der Netzwerkkarte des Android SmartPhone bzw. von den Treibern des Kernel nicht unterstützt. Proc-Values Das Einstellen von Kernel-Parameter für Socket-Anwendungen, damit die Empfangspuer für die Netzwerkkarte mehr Pakete aufnehmen können ohne Paketverlust zu erzeugen. Die Schnittstelle zum Kernel ist mit dieser Funktionalität nicht ausgestattet. Scheduler Das Ändern der Priorität der Anwendung im Scheduler wird von den Funktionen der NDK nicht zur Verfügung gestellt. Damit kann die Anwendung nicht als privilegierter Prozess parallel zum Kernel agieren. Dies hat zufolge, dass bei voller Auslastung des SmartPhone durch andere Anwendungen die Anwendung sv_probe bei Messungen ausgebremst wird. Der letzte Punkt führt zu erheblichen Problemen, da eine ausgebremste Messanwendung falsche oder fehlerhafte Messdaten erzeugt. Tests auf dem SmartPhone haben gezeigt, dass bei einer Messung im Deamon-Modus Paketverluste entstehen können. Dieses Verhalten ist auf zu geringe Systemressourcen zurückzuführen und tritt auf, wenn mindestens eine aktive Anwendung im Vordergrund ausgeführt wird und diese viele Ressourcen benötigt. Der Scheduler im Android System ermöglicht einer App umfangreichen Zugri auf CPU-Ressourcen, sodass für Anwendungen im Hintergrund nur minimale Ressourcen zur Verfügung stehen. Dieses Problem kann nur umgangen werden, wenn die Anwendung sv_probe nicht im Deamon- Modus arbeitet oder sichergestellt werden kann, dass keine andere Anwendung das System blockieren kann. Die erste Lösung ist die am meisten genutzte Variante für Messungen mit dem SmartPhone. 8.6 SmartVideo Probe 80

81 8 Implementierung Ansteuerung Die Anwendung liegt als Binärdatei im internen Verzeichnis /data/data/com.smartvideo.probe/cache. Da es sich um ein konsolen-basiertes Programm handelt, können zur Steuerung der Anwendung zusätzliche Parameter beim Starten der Anwendung übergeben werden. Die folgenden Parameter sind zulässige Argumente für den Messkopf: Argument Bedeutung -d Mit diesem Argument kann der Messkopf dazu veranlasst werden, im Deamon-Modus zu arbeiten. -p Pfadangabe zum Arbeitsverzeichnis. In diesem Verzeichnis muss die Kongurationsdatei probe.conf liegen und es werden die Messdaten dort gespeichert. -c Pfadangabe der Binärdatei busybox, um Shell-Befehle ausführen zu können und die Delay-Messung mit Hilfe von Ping-Tests zu ermöglichen. -s Aktivieren von Logeinträgen. Ist dieser Parameter gesetzt, werden Statusinformationen ausgegeben. -o Ausgabe der Netzwerkpakete auf der Konsole. Funktion wird in dieser Master Thesis nicht verwendet. Tabelle 8.1.: Auistung der Argumente des Messkopfes sv_probe auf der Konsole Darüber hinaus werden zum Starten einer Messungen die Parameter der probe.conf benötigt. Diese muss sich im angegebenen Arbeitsverzeichnis (üblicherweise auf der SD-Karte im externen Verzeichnis /Probe) benden. Ein vollständiges Beispiel dieser Kongurationsdatei, wie sie im Android System angelegt wird, ist im Anhang A.1 zu nden Ausgabe Bei der Ausgabe der Messdaten wird auf CSV-Dateien zurückgegrien. Es wird pro Messung eine CSV-Datei angelegt und diese enthält alle Daten über die Messung, inklusive der vorher benötigten Datei probe.conf. Die Daten sind in drei Bereiche aufgeteilt und werden durch Tags signalisiert. Die Tags beginnen mit dem Steuerzeichen #, gefolgt von der Gruppierung der Daten (conf, const, variable). Ein doppeltes Steuerzeichen gibt die Namen der Parameter an und die darauf folgende Zeile die eigentlichen Werte der Parameter. Bei den variablen Daten werden alle Netzwerkpakete untereinander aufgelistet. Ein Auszug einer CSV-Datei nach einer Messung stellt das Beispiel auf der nächsten Seite dar. 8.6 SmartVideo Probe 81

82 8 Implementierung 1 #c o n f Data : 2 ##id, s e r i a l, i n t e r f a c e, running_time, delay_host, b u f f e r _ s i z e, v e r b o s e _ l e v e l, t r a n s p o r t _ l a y e r,... 3 d3dd1aeae260723cb b999db3a, 8 F2E38, eth0, , , 5 0, 4, 1, 0, #c o n s t a n t Data : 6 ##stream_hash, mtu_size, delay_min, delay_avg, delay_max, mac_src, mac_dst, eth_port, m u l t i c a s t, , , , , , 0 0 : 0 4 : 7 5 : d4 : 7 5 : 8 6, 3 8 : e7 : d8 : d8 : d8 : 6 0, 8 0 0, 0, #v a r i a b l e Data : 10 ##packet_no, packet_length, interface_ status, arrival_time_sec, arrival_time_usec, ip_ ttl, , , 0, , , 6 4, , 0, 0 x1740, 1, , , 0, 0, 0, 9 0, 0, 1, 1 4, , , 0, , , 6 4, , 0, 0 x104a, 1, , , 0, 0, 0, 9 0, 0, 1, 1, , , 0, , , 6 4, , 0, 0 x5287, 1, , , 0, 0, 0, 9 0, 0, 1, 7,... Listing 8.2: Struktur der Messdaten innerhalb der CSV-Datei 8.7. Test und Verikation In diesem Kapitel wird die Android App und ihre wichtigsten Funktionen und Eigenschaften getestet und veriziert Messungen Die Android App besteht aus zwei Programmteilen, wovon der Messkopf mit erweiterten Administratorenrechten im System arbeiten muss. Die folgende Ausgabe zeigt die Prozesstabelle des SmartPhone beim Ausführen der App während diese eine Messung durchführt. Es verdeutlicht, wie die App (PID 3732) mit Hilfe von Su die benötigten Rechte erlangt, indem sie ein Terminal (PID 3798) startet. In diesem Terminal werden die benötigten Administratorenrechte eingeholt. Anschlieÿend wird mit diesen Rechten innerhalb des Terminal das Skript mit Hilfe einer Shell (PID 3799) gestartet. Dieses Skript führt wiederum den Messkopf sv_probe (PID 3804) mit den nötigen Übergabeparametern aus. 1 USER PID PPID VSIZE RSS WCHAN PC NAME 2 app_ f f f f f f f f afd0c5bc com. smartvideo. probe 3 r o o t c a f d 0 c 4 4 c sh 4 root c afd0c44c / system / bin / sh 5 r o o t f f f f f f f f a f d 0 c / data / data /com. smartvideo. probe / cache / sv_probe Listing 8.3: Ausgabe des Befehls ps während einer Messung Ist eine Messung abgeschlossen, indem die Messdauer erreicht worden ist, wird der Messkopf selbständig heruntergefahren und beendet sich automatisch. 8.7 Test und Verikation 82

83 8 Implementierung Funktion- und Ergebnistest Die elementare Aufgabe der Android App ist das Messen und Bewerten von Videos. Für diesen Test wurden Videos über das Netzwerk per RTP gestreamt und mit NetGen 4 manipuliert. Es wurden verschiedene Paketverlustraten eingestellt und mit der Android App gemessen und bewertet. Das Video liegt im Displayformat des SmartPhone vor und ist mit dem H.264 Codec in einer Datenrate von 500 kbit/s codiert. Die Messdauer beträgt 100 Sekunden. Quality-of-Experience (QoE) durch MOS Messung Codec Auösung Messdauer Paketverlust MOS 1 MPEG-4/H x s 0,00% MPEG-4/H x s 0,22% 4,67 3 MPEG-4/H x s 0,45% 4,35 4 MPEG-4/H x s 0,92% 3,77 5 MPEG-4/H x s 1,57% 3,14 6 MPEG-4/H x s 4,09% 1,78 7 MPEG-4/H x s 5,31% 1,07 Tabelle 8.2.: Qualitätsbewertung eines Videos durch die Android App Angefangen bei einem Video ohne jegliche Störungen, wird das Video als Referenz gewertet und erlangt einen MOS mit der Wert 5. Einen MOS von 5 ist in der MOS-Skala der bestmögliche Wert. Es wird deutlich, das schon Paketverlustraten von 0.22% Prozent eine Degradierung des MOS zufolge haben. Die Auswirkung für den Betrachter sind sichtbar, jedoch nicht störend. Je höher der Paketverlust ist, desto geringer ist der MOS und um so unzufriedener ist der Betrachter. Ab einen Grenze von 5% Prozent Paketverlust ist ein H.264 codiertes Video nicht mehr zu betrachten, da die Störungen ein korrektes codieren nicht mehr ermöglichen Geschwindigkeitstest Bei dem Geschwindigkeitstest wird die Performance des SmartPhone analysiert. Die nach einer Live-Messung entstandenen Messdaten müssen für einen Bewertung verarbeitet werden. Das Verarbeiten der Messdaten und die Auswertung der QoS-Parameter kann das SmartPhone an seine Leistungsgrenzen bringen. In der nachfolgenden Tabelle sind VoD-Messungen mit unterschiedlichen Videos (Auösung) und Messdauer aufgeführt. 4 NetGen - Netzwerk Generator - Ein aus dem Forschungsprojekt QoSSIP entwickeltes Tool zur Manipulation von Netzwerkpaketen 8.7 Test und Verikation 83

84 8 Implementierung Performancetest auf dem Android SmartPhone Nr. Videocodec Auösung Messdauer Datenrate Pakete Rechenzeit 1 MPEG-4/H x576 4 s 1,8 Mbit/s 684 1,88 s 2 MPEG-4/H x480 4,66 s 500 kbit/s 219 0,90 s 3 MPEG-4/H x s 6,0 Mbit/s ,17 s 4 MPEG-4/H x s 600 kbit/s ,90 s 5 MPEG-4/H x s 500 kbit/s ,68 s Tabelle 8.3.: Performancetest mit Messungen auf dem SmartPhone Ausschlaggebend für die Berechnungszeit ist nicht die Messdauer, sondern die Datenrate des Videos und die damit verbundene Anzahl an aufgezeichneten Paketen innerhalb der Messdauer. Je mehr Pakete von der CSV-Datei aufgenommen und analysiert werden müssen, desto länger läuft die CPU unter Volllast. Bessere Leitungsdaten liefert ein SmartPhone mit einem höher getaktetem Prozessor oder Dual-Core Technologie. Getestet wurde die Android App auf einem LG Optimus Speed mit 1GHz Dual-Core. Dabei wurde bei der Messung 3 ein Performancezuwachs von 50% Prozent erreicht. 8.7 Test und Verikation 84

85 9 Fazit 9. Fazit Das Ziel dieser Master Thesis ist erreicht worden. Es wurde evaluiert, welches Messverfahren für IPTV das beste Verfahren darstellt und welche Möglichkeiten auf einem Android SmartPhone zu realisieren sind. Aufgrund des Non-Reference-Verfahren wurde der Messkopf des Smart- Video Projekt als Basis herangezogen und Architekturkonzepte für die Implementierung eines QoS/QoE Monitoring Sensors vorgestellt. Es wurde die Analysetiefe für den Sensor speziziert und die Videoparameter in einer Untersuchung abgeschätzt. Die Unterscheidung zwischen den Konzepten Direkt-Zugri, Proxy oder die Erfassung der Daten mit Hilfe der Raw-Sockets wurde auf Machbarkeit geprüft. Dabei stellte sich heraus, dass eine Realisierung des Konzeptes in vollem Umfang nur möglich ist, wenn eine Analyse mit Raw-Sockets durchgeführt wird und das SmartPhone in der Lage ist, Anwendungen mit erweiterten Administratorenrechte zu starten. Anschlieÿend wurde das evaluierte Konzept in einer Android App implementiert und vorgestellt. Tests haben gezeigt, das die entwickelte Implementierung ein zuverlässiges Konzept darstellt, mit dem man Live-, Intervall- und Dauermessungen von Video Streams (IPTV, VoD) durchführen kann. Messungen sind sowohl in WLAN, als auch in UMTS-Netzen möglich. Aufgrund der GPS-Daten zu den Messungen, ist eine geograsche Qualitätsbewertung der Funkzellen denkbar. Die Android App SmartVideo Probe for Android stellt eine erste Qualitätsbewertung von IPTV und Video-Streaming dar. Die aus der Master Thesis resultierenden Messwerte müssen in Zukunft noch mit den Werten einer Wissensdatenbank nach BT.500 korreliert werden, um eine genauere Qualitätsaussage zu erhalten. 85

86 10 Abkürzungsverzeichnis 10. Abkürzungsverzeichnis 3GPP rd Generation Partnership Project ADB Android Debug Bridge AFC Adaptation Field Control API Application Programming Interface AVC Audio Video Coding CSV Comma-Separated Values DCT Discrete Cosine Transformation DPI Deep Packet Inspection DVB Digital Video Broadcast ETSI European Telecommunications Standards Institute FR Full Reference IAD Integrated Access Device IGMP Internet Group Management Protocol IPTV Internet Protocol Television ISP Internet Service Provider ISO/IEC International Organization for Standardization ITU International Telecommunications Union NAL Network Abstraction Layer NDK Native Developer Kit NR Non Reference NTIA National Telecommunications and Information Administration MBMS Multimedia Broadcast Streaming Service PAT Program Asscociation Table PMT Program Map Table PPS Picture Parameter Set PSS Packet Switched Streaming Service QoE Quality of Experience QoS Quality of Service RTT Round-Trip-Time RR Reduced Reference SDK Software Developer Kit 86

87 10 Abkürzungsverzeichnis SPS Sequence Parameter Set STB Set-Top-Box UMTS Universal Mobile Telecommunications System VCL Video Coding Layer VQM Video Quality Model VOD Video on Demand WLAN Wireless Local Area Network XML Extensible Markup Language 87

88 Stephan Küner Abbildungsverzeichnis 11. Abbildungsverzeichnis 4.1. Typische Kapselung von IPTV Videodaten in IP Allgemeine IPTV Streaming-Plattform Architektur Schemata der AVI- und MP4-Container im Vergleich H.264 Full HD bei 0% Prozent Paketverlust. Quelle: [5] H.264 Full HD bei 1% Prozent Paketverlust. Quelle: [5] Full-Reference-Verfahren (FR) Beispiel des Full-Reference Analyse-Tools Video Quality Analyser der Firma AccepTV. (Quelle: AccepTV - VQA2) Reduced-Reference-Verfahren (RR) Non-Reference-Verfahren (NR) Aufbau des SmartVideo Messsystem mit 2 Messköpfen SmartVideo Managementsystem SmartVideo Analysesystem Zustandsdiagramm des Messkopfes - Version Android Architektur (Quelle: Android Developer)[7] Android Activity Lifecycle (Quelle: Android Developer - Activity) Activity States Einholen der Rechte beim Benutzer bei der Installation einer Android App Technische Implementierung eines verteilten Sensor-Netzes mit SmartPhone Vergleich und Mapping zwischen ISO/OSI Schichtenmodel und TCP/IP Schichtenmodel (Quelle: Learn-Networking) Client-Server Aufbau mit Sockets Proxy Implementierung - Forschungsschwerpunkt VMA - Mark Hümeyer Gekürztes Klassendiagramm der Proxy Implementierung Socket Mapping Architektur eines QoS/QoE Monitoring Sensor Klassendiagramm SmartVideo Probe for Android Sequenzdiagramm vom Start der App bis zur Messung

89 Abbildungsverzeichnis 8.3. Programmablaufplan vom Start der App bis zu den Benutzereingaben Programmstruktur und Auistung aller Activities der App SmartVideo Probe for Android MeasurementActivity DatabaseActivity MapsActivity LogActivity InspectionConf Activity InspectionConst Activity InspectionVar Activity InspectionGraphics Activity VideoActivity im Abspielmodus Programmablaufplan der NDK-Anwendung sv_probe A.1. Programmablaufplan Main-Thread A.2. Programmablaufplan networkanalysis-thread A.3. Programmablaufplan probecontrol-thread A.4. Programmablaufplan contentswitch-thread A.5. Grak: Streamrate A.6. Grak: Packetloss A.7. Grak: Jitter Average A.8. Grak: Jitter RFC A.9. Grak: Interarrival Delay Abbildungsverzeichnis 89

90 Stephan Küner Tabellenverzeichnis 12. Tabellenverzeichnis 4.1. Systemvergleich der führenden Telekommunikationsunternehmen zu IPTV Gegenüberstellung der Codecs H.264 und MPEG QoS-Klassen für die Priorisierung von Paketen im Mobilfunk (NGMN) Vergleich der einzelnen Referenz-Verfahren Auistung der Namen und Bedeutung der einzelnen Threads des SmartVideo Messkopfes Auistung aller bekannten Sicherheitsmechanismen bei einem Android System Vergleich der Eigenschaften und Funktionen von SDK und NDK Priorisierung der H.264 Header Gegenüberstellung der SDK und NDK im Bezug auf Raw-Sockets Auistung der Argumente des Messkopfes sv_probe auf der Konsole Qualitätsbewertung eines Videos durch die Android App Performancetest mit Messungen auf dem SmartPhone

91 Stephan Küner 13 Inhaltsverzeichnis der CD 13. Inhaltsverzeichnis der CD» ÏÙÖÞ ÐÚ ÖÞ Ò Die hier angegebenen Internet Quellen benden sich am 15. August 2011 auf dem angegebenen und ÒÐ Ò» zitierten Stand, zusätzlich sind die Quellen als ÉÙ ÐÐ Ò ËØ Ò Ö Ä Ø Ö ØÙÖ Kopie auf der mitgegebenen CD gespeichert und können bei Bedarf nachgeschlagen werden. ÔÔ» Ó» ËÑ ÖØÎ Ó ÈÖÓ ÓÖ Ò ÖÓ ½º¼º Ô Ë Ò ÖØ Èù Ø ÈÖÓ Ö ÑÑÓÖ Ò Ö Èà ËÑ ÖØÎ Ó» Ø» ÈÖÓ ØÓÖ Ò Ö Ä Ö ÈÖÓ Ö ÑÑÓÖ Ò ÖËÓÙÖ Ó Ò» Ó» Ò» ÒÖ Ø Ò Ò» Ó Ó ÙÑ ÒØ Ø ÓÒ¹ ÓÜÝ Ò Ð» Ó ÙÑ ÒØ Ø ÓÒ¹ Ð Ô Ö» ÉÙ ÐÐÓ Æ Ã ÒÛ Ò ÙÒ Ö» Ò ÙÒ Ò Ð ÓØ Ò Ò ÖÓ Å Ò ØºÜÑÐ Î ÖÛ Ò Ø Ê ÓÙÖ Ò¹ Ð Ö ÉÙ ÐÐÓ Ë Ã ÒÛ Ò ÙÒ Ñ» Ò ÖÓ ÈÖÓ Ø Ø Ã Ô Ø Ð» Ì ¹Î ÖÛ Ò Ø Ð Ö Ð Ø Ü» Ì ¹Ä Ø Ü Ø Ò Ì ºÔ Ì ¹È Ì ¹Ä Ø Ü Ù ØÞÔ Ø 91

92 Stephan Küner 14. Literaturverzeichnis 14. Literaturverzeichnis [1] 3GPP. All-IP network (AIPN) feasibility study (Rel. 9) (3GPP TS ). 3rd Generation Partnership Project, December [2] 3GPP. Quality of Service (QoS) concept and architecture (Release 9) (3GPP TS V 9.0.0). 3rd Generation Partnership Project, December [3] A. Grebe, S. Abu Salah, Achim Marikar. Forschungsprojekt QoSSIP, Mai [4] A. Grebe, S. Küner, O. Portugall. Forschungsprojekt SmartVideo, August [5] A. Grebe, S. Küner, O. Portugall. Objektives und Subjektives Qualitätsmonitoring von H.264 IP Videostreams in Mobilfunknetzen. ITG-Fachbericht 223 Mobilkommunikation, Mai [6] A. Grebe, S. Küner, O. Portugall. Evaluierung eines mobilen Sensorsystems zum QoS/QoE Monitoring in NGMN. ITG-Fachbericht 230 Mobilkommunikation, Mai [7] Android Open Source Project. Android Developer, August [8] Android Security and Permissions. security.html. Android Developer, August [9] DSL-Forum. Triple-play Services Quality of Experience (QoE) Requirements (DSL-Forum TR-126). DSL-Forum, Dezember [10] ETSI. Digital Video Broadcasting (DVB) Measurement guidelines for DVB systems (ETSI Technical Report TR V1.2.1). European Telecommunications Standards Institute, Mai [11] ETSI. Architectural Framework for the Delivery of DVB-Services over IP-based Networks (ETSI Technical Report TR V1.1.1). European Telecommunications Standards Institute, April [12] ETSI. Transport of MPEG-2 TS Based DVB Services over IP Based Networks (and associated XML) (ETSI Technical Specication TS V1.4.1). European Telecommunications Standards Institute, August

93 14. Literaturverzeichnis [13] Golem.de. Keine gesperrten Bootloader mehr. Mai [14] Institute for Telecommunication Sciences (ITS), National Telecommunications and Information Administration (NTIA). Low Bandwidth Reduced Reference Video Quality Monitoring System. August [15] ISO/IEC. Information technology - Coding of audio-visual objects - Part 10: Advanced Video Coding (ISO/IEC :2004(E)), Oktober [16] ISO/IEC. Information technology - Coding of audio-visual objects - Part 12: ISO base media le format (ISO/IEC :2008(E)), Oktober [17] ISO/IEC. Information technology - Coding of audio-visual objects - Part 15: Advanced Video Coding (AVC) le format (ISO/IEC :2010(E)), Juni [18] ITU. Methods for Subjective Determination of Transmission Quality, Methods for Objective and Subjective Assessment of Quality (ITU-T P.800). International Telecommunications Union, August [19] ITU. Measurement of the quality of service: Objective perceptual multimedia video quality measurement in the presence of a full reference (ITU-T J.247). International Telecommunications Union, August [20] ITU. Quality of experience requirements for IPTV services (ITU-T G.1080). International Telecommunications Union, Dezember [21] ITU. Methodology for the subjective assessment of the quality of television pictures (ITU-R BT ). International Telecommunications Union, September [22] Marc Hümeyer. Entwicklung eines Messsystems zur Analyse von H.264 Videostreams unter Android. Diplomarbeit Fachhochschule Köln, Juli [23] Multimedia Technologies, IBM, Lab for Image and Video Eng., Dept. of ECE. Full- Reference Video Quality Assessment Considering Structual Distortion and No-Reference Quality Evaluation of MPEG Video. [24] Next Generation Mobile Networks. NGMN Home Page. März [25] Panagiotis Christias. Packet - Linux Programmer's Manual. uk/cgi/man-cgi?packet, Juli [26] S. Küner. Performanceanpassungen des SmartVideo Probe auf ALIX Embedded System alix2d13. Praxissemesterbericht Fachhochschule Köln, Januar [27] S. Küner. Vergleichende Analyse von Container- und Codectypen für IP-Videostreaming in IPTV-, WebTV- und Internet-Dienste. Fachhochschule Köln, Januar [28] Wei Geng, Wu Lenan, Wang Deguo. The Technical Framework of End-to-End Video Transmission System for the IPTV, April Literaturverzeichnis 93

94 A Appendix A. Appendix A.1. Kongurationsdatei probe.conf 1 #General S e t t i n g s 2 #Measurement ID 3 i d=fd4bd3ab8190fb657cbaf d #SerialNumber Probe 6 s e r i a l=jt82h1 7 8 #Input I n t e r f a c e 9 i n t e r f a c e=l o #Duration of the Measurement 12 running_time= #IP Adresse f o r Delay Timing 15 delay_host = #Buffer f o r reordering RTP 18 b u f f e r _ s i z e = #Verbose Level 1 >less, oo >more 21 v e r b o s e _ l e v e l= #Layer 24 #Parameter on Layer t r a n s p o r t _ l a y e r= #Parameter on Layer a p p l i c a t i o n _ l a y e r = #GeoLocation 31 l o n g i t u d e = l a t i t u d e = Listing A.1: Beispiel der Kongurationsdatei probe.conf A.2. Logdatei Logging.log 1 Tue Apr : 4 0 : 0 5 GMT+02: [VIEW] (M) S t a r t i n g SmartVideo Probe 2 Tue Apr 26 14: 40: 41 GMT+02: [ MeasurementActivity ] (V) F i l e ' probe. conf ' written 3 Tue Apr 26 14: 40: 42 GMT+02: [VIEW] (V) Starting measurement with ID : 5a4d9907a 4 Tue Apr 26 14: 40: [SVPROBE] (M) Status : Probe s t a r t e d! 5 Tue Apr : 4 0 : [SVPROBE] (M) S t a r t i n g Thread : probecontrol 6 Tue Apr 26 14: 40: [SVPROBE] (M) Status : Begin Measurement with ID : 5a4d9907a 7 Tue Apr : 4 0 : [SVPROBE] (M) S t a r t i n g Thread : n e t w o r k A n a l y s i s 8 Tue Apr 26 14: 41: [SVPROBE] (M) Status : Stop Measurement with ID : 5a4d9907a 9 Tue Apr : 4 1 : [SVPROBE] (M) End Thread : n e t w o r k A n a l y s i s 10 Tue Apr : 4 1 : [SVPROBE] (M) End Thread : probecontrol Listing A.2: Aufbau der Logdatei logging.log 94

95 A Appendix 1 #!/ system/ bin /sh 2 # 3 # 4 # Fachhochschule Koeln 5 # Cologne University of Applied Sciences 6 # 7 # Fakultaet fuer 8 # Informations, Medien und Elektrotechnik 9 # 10 # Forschungsprojekt SmartVideo 11 # 12 # Authors : 13 # Stephan Kueffner, stephan. kueffner@fh koeln. de 14 # 15 # Webseite : http ://www. smart video. org 16 # 17 # Copyright (C) # 19 # Fachhochschule Koeln Cologne Univerity of Applied Sciences, 20 # www. fh koeln. de / www. qossip. de / www. smart video. org 21 # hereby disclaims a l l copyright i n t e r e s t in the program 22 # `SmartVideo Probe for Android ' ( which makes passes at compilers ) 23 # 24 # BUSYBOX=busybox 27 GREP=grep 28 ECHO=echo 29 SV_PROBE=sv_probe # Try to f i n d busybox 32 i f / data / data /com. smartvideo. probe / cache / sv_probe h >/dev / n u l l 2>/dev / n u l l ; then 33 SV_PROBE=/data / data /com. smartvideo. probe / cache / sv_probe 34 e l i f sv_probe h >/dev / n u l l 2>/dev / n u l l ; then 35 SV_PROBE=sv_probe 36 e l i f / system / xbin / sv_probe h >/dev / n u l l 2>/dev / n u l l ; then 37 SV_PROBE=/system / xbin / sv_probe 38 e l i f / system / bin / sv_probe h >/dev / n u l l 2>/dev / n u l l ; then 39 SV_PROBE=/system / bin / sv_probe 40 f i # Try to f i n d busybox 43 i f / data / data /com. smartvideo. probe / cache / busybox h e l p >/dev / n u l l 2>/dev / n u l l ; then 44 BUSYBOX=/data / data /com. smartvideo. probe / cache / busybox 45 GREP="$BUSYBOX grep " 46 ECHO="$BUSYBOX echo " 47 e l i f busybox h e l p >/dev / n u l l 2>/dev / n u l l ; then 48 BUSYBOX=busybox 49 e l i f / system / xbin / busybox h e l p >/dev / n u l l 2>/dev / n u l l ; then 50 BUSYBOX=/system / xbin / busybox 51 e l i f / system / bin / busybox h e l p >/dev / n u l l 2>/dev / n u l l ; then 52 BUSYBOX=/system / bin / busybox 53 f i # Try to f i n d grep 56 i f! $ECHO 1 $GREP q 1 >/dev / n u l l 2>/dev / n u l l ; then 57 i f $ECHO 1 $BUSYBOX grep q 1 >/dev / n u l l 2>/dev / n u l l ; then 58 GREP="$BUSYBOX grep " 59 f i 60 # Grep i s absolutely required 61 i f! $ECHO 1 $GREP q 1 >/dev / n u l l 2>/dev / n u l l ; then 62 $ECHO The grep command i s required. 63 e x i t 1 64 f i 65 f i 66 #SV_PROBE Command for capturing packets 67 $SV_PROBE s c $BUSYBOX p /mnt/ sdcard / Probe 68 e x i t Listing A.3: Aufbau des Skriptes smartvideo_probe.sh zum Messen mit sv_probe A.2 Logdatei Logging.log 95

96 A Appendix A.3. Programmablaufpläne SmartVideo Messkopf Main-Thread Abbildung A.1.: Programmablaufplan Main-Thread A.3 Programmablaufpläne SmartVideo Messkopf 96

97 A Appendix networkanalysis Abbildung A.2.: Programmablaufplan networkanalysis-thread A.3 Programmablaufpläne SmartVideo Messkopf 97

98 A Appendix probecontrol Abbildung A.3.: Programmablaufplan probecontrol-thread A.3 Programmablaufpläne SmartVideo Messkopf 98

99 A Appendix contentswitch Abbildung A.4.: Programmablaufplan contentswitch-thread A.3 Programmablaufpläne SmartVideo Messkopf 99

100 A Appendix A.4. Aufnehmende Parameter A.4.1. Statische Messdaten Ethernet-Parameter stream_hash mtu_size delay_min delay_avg delay_max mac_src mac_dst eth_port multicast vlan vlan_prio vlan_c vlan_id Beschreibung Eindeutige Stream ID MTU Size des Links (Eth typisch 1500 Byte) Delaymessung PING (Minimal) Delaymessung PING (Average) Delaymessung PING (Maximal) MAC Adresse der letzten Netzwerkkomponente Richtung Quelle MAC Adresse der letzten Netzwerkkomponente Richtung Senke Folgendes Protokoll Stream ist Multicast oder Unicast (IPTV o. VoD) Flag VLAN Trennung/Priorisierung VLAN ID IP-Parameter Beschreibung ip_version IP-Protokoll Version ip_src Quell-Adresse ip_dst Ziel-Adresse ip_proto Folgeprotokoll (6/17) ip_tos Priorisierung mittels Diserv oder Intserv ip_dscp DSCP-Klassen ID Transport-Parameter tcp_src_port tcp_dst_port udp_src_port udp_dst_port rtp_ssrc rtp_payloadtype Beschreibung TCP Port Sender TCP Port Empfänger UDP Port Sender UDP Port Empfänger Synchronisationsquelle Signalisierter Payload A.4 Aufnehmende Parameter 100

101 A Appendix Video-Parameter Beschreibung mpegts_patpid PAT mit PMT ID mpegts_pat_section_ind Multiplex Information mpegts_pat_section_no Multiplex Information mpegts_pat_section_lno Multiplex Information mpegts_pat_programm_no Multiplex Information mpegts_pmtpid PMT mpegts_pmt_section_ind Multiplex Information mpegts_pmt_section_no mpegts_pmt_section_lno mpegts_pmt_programm_info_len mpegts_pmt_descriptor Copyright, Video-,Audio-Codierung, Länderkennung mpgets_pmt_es_typ_1 Videotyp mpgets_pmt_es_pid_1 Stream ID mpgets_pmt_es_len_1 Länge des Descriptoren-Blocks mpgets_pmt_es_des_1 Copyright, Video-,Audio-Codierung, Länderkennung mpgets_pmt_es_typ_x Spaltenanzahl X dynamisch mpgets_pmt_es_pid_x mpgets_pmt_es_len_x mpgets_pmt_es_des_x A.4.2. Dynamische Messdaten Dynamische-Parameter packet_no packet_length interface_status arrival_time_sec arrival_time_usec ip_ttl ip_ident tcp_seq udp_check udp_check_correct rtp_seq rtp_timestamp Beschreibung Laufende Paketnummer Erfasste Paketgröÿe Interface-Status 1 = down, 0 = up Ankunftszeit in Sekunden Ankunftszeit in usekunden IP-Time-to-Live IP-Identication Feld (Fragmentierung) TCP-Sequenznummer UDP-Checksumme UDP-Checksummen Überprüfung RTP-Sequenznummer RTP-Timestamp A.4 Aufnehmende Parameter 101

102 A Appendix Video-Parameter mpegts_tei mpegts_psi mpegts_tp mpegts_pid mpegts_tsc mpegts_afc mpegts_cc mpegts_af_len mpegts_af_disc_ind mpegts_pes_st_id mpegts_pes_len mpegts_pes_h_d_len mpegts_pes_mv_tmp_seqnr mpegts_pes_mv_fr_typ mpegts_pes_ms_hsize mpegts_pes_ms_vsize mpegts_af_t_p_d_len1 mpegts_af_ext_len mpegts_pes_pts mpegts_pes_dts mpegts_pes_ms_aspect mpegts_pes_ms_frate mpegts_pes_ms_bitrate mpegts_af_pcr mpegts_af_pcr_ext mpegts_af_opcr mpegts_af_opcr_ext mpegts_pes_mv_vbv_delay mpegts_pes_ms_buersize Beschreibung Transport-Error-Indikator Payload Start Indikator Transport Priorität MPEG-TS PID des Streams Transport Scrambling Control Adaptation-Feld-Flag zur Signalisierung Continuity-Counter Adaptation-Feld Länge, wenn vorhanden Adaptation-Feld Discontinuity Indikator ID des Packetized-Elementary-Streams Länge des PES-Paket Länge des integrierten Daten-Header im PES-Paket Temporäre Sequenznummer, nur bei MPEG2 Type des Bildes (I-,B-,P-Bild), nur bei MPEG2 Horizontale Auösung des Videos, nur bei MPEG2 Vertikale Auösung des Videos, nur bei MPEG2 Transport Privat Data Flag Länge des Extension-Header PES-Darstellungszeitstempel PES-Dekodierzeitstempel PES Seitenverhältnis, nur bei MPEG2 Bildrate des Videos, nur bei MPEG2 Datenrate des Videostreams, nur bei MPEG2 Adaptation-Feld Programm Referenztakt PCR-Extension Adaptation-Feld Original Programm Referenztakt OPCR-Extension Bildverzögerung, nur bei MPEG2 Gröÿe des Variablen Bildpuer, nur bei MPEG2 A.4.3. Abgeleitete Daten QoS-Parameter id hash Beschreibung Fortlaufende Nummerierung Assoziierte Hash-ID für die jeweilige Messung A.4 Aufnehmende Parameter 102

103 A Appendix QoS-Parameter Beschreibung rst_arrival_sec Startzeitpunkt der Messung in Sekunden rst_arrival_usec Startzeitpunkt der Messung in usekunden nr_of_derived_calculation Anzahl durchgeführter Berechnungen duration Intervall Dauer der Berechnung received_packets Erfasste Paket in dem Intervall loss_ip Verlorengegangene IP-Pakete loss_ip_rtp Verlorengegangene RTP-Pakete loss_counter Zähler verlorengegangener Pakete loss_burst_avg Burst verlorengegangener Pakete Average loss_burst_min Burst verlorengegangener Pakete Minimal loss_burst_max Burst verlorengegangener Pakete Maximal jitter_rfc Jitter Berechung für das Intervall nach RFC3550 jitter_avg Jitter Berechung für das Intervall Average inte_delay Ankunftsverzögerung für das Intervall Average inte_delay_min inte_delay_max Ankunftsverzögerung für das Intervall Maximal bitrate Datenrate des Streams im Intervall Ankunfts Video-Parameter mpegts_pes_ms_hsize mpegts_pes_ms_vsize video_pid video_type audio_pid audio_type i_slice p_slice b_slice h264_prole h264_level h264_picture_width h264_picture_height continuity_count_error_v continuity_count_error_a continuity_count_error_o Beschreibung Horizontale Auösung des Videos, nur bei MPEG2 Vertikale Auösung des Videos, nur bei MPEG2 Video PID des erfassten Streams Video Descriptoren Audio PID des erfassten Streams Audio Descriptoren I-Slice Zähler für das Intervall P-Slice Zähler für das Intervall B-Slice Zähler für das Intervall H.264 Prole Angabe H.264 Level Angabe H.264 vertikale Auösung H.264 horizontale Auösung Fehlerzähler von CC-Video Fehlerzähler von CC-Audio Fehlerzähler von CC-Andere A.4 Aufnehmende Parameter 103

104 A Appendix A.5. Screenshots der Graken in der InspectionGraphicsActivity Abbildung A.5.: Grak: Streamrate Abbildung A.6.: Grak: Packetloss Abbildung A.7.: Grak: Jitter Average Abbildung A.8.: Grak: Jitter RFC3550 Abbildung A.9.: Grak: Interarrival Delay A.5 Screenshots der Graken in der InspectionGraphicsActivity 104