kyago Whitepaper - zafaco · Schnittstellen inklusive SIP-Trunking. In Abhängigkeit der Messkampagne (Consumer, Business, Video etc.) kommt ein Mix der oben genannten Anschlusstechnologien

kyago Whitepaper Die Multi Play- und Benchmarking Plattform

Autor:

zafaco GmbH

zafaco GmbH

Taxetstraße 66

85737 Ismaning

Ismaning, 11. Mai 2016

Version 6.6

kyago

Whitepaper Version 6.6

2 von 90

Inhalt

1 Management Summary ................................................................. 6

Kontinuierlicher Benchmark ........................................................... 6

Kundensicht im Fokus ................................................................... 6

Realitätsnahe Simulation ............................................................... 7

Time to Market ............................................................................ 7

Eckdaten des Benchmarks ............................................................. 7

Prinzipien aus der Benchmarking-Praxis ........................................... 8

Zusätzlicher Kundennutzen ............................................................ 8

zafaco GmbH Unternehmensinformationen ....................................... 9

zafaco GmbH Ansprechpartner ....................................................... 9

Copyright / Haftungsbeschränkung ................................................. 9

2 Die Multi Play- und Benchmarking Plattform .................................... 10

Speziell zugeschnittene Hardware und Software .............................. 10

Verschiedene Anschlusstechnologien ............................................. 10

Ad-hoc-Messungen ..................................................................... 10

Routine-Messungen .................................................................... 11

Standorte ................................................................................. 12

Anbieter ................................................................................... 13

Gesamtübersicht der Produkte und Anbieter ................................... 14

Gesamtübersicht der IADs und Firmware ....................................... 15

3 Technisches Umsetzung .............................................................. 16

4 Ende-zu-Ende Sprachqualitätsmessungen ........................................ 18

Gesamtübersicht der Verkehrsbeziehungen für

Sprachqualitätsmessungen .......................................................... 19

Gesamtübersicht Qualitätskennwerte der Sprachmessungen ............. 20

Call Setup Duration ..................................................................... 20

Call Setup Failure Ratio ............................................................... 21

Connect Setup Duration .............................................................. 22

kyago


3 von 90

Connect Setup Failure Ratio ......................................................... 22

Call Failure Ratio ........................................................................ 23

Call Drop Ratio .......................................................................... 23

MOS LQO ................................................................................. 24

Sprachqualitätsmessung mit parallelem Up- und Download ................ 26

Speech Delay............................................................................. 28

Multitone Errors ........................................................................ 29

Multitone Failure Ratio ................................................................ 30

5 Fax ...................................................................................... 31

Gesamtübersicht Qualitätskennwerte der Faxmessungen .................. 31

Fax Setup Duration ..................................................................... 33

Fax Transmission Duration ........................................................... 34

Fax Failure Ratio ........................................................................ 35

6 Highspeed Internet ..................................................................... 36

Messserver beim Anbieter oder zafaco .......................................... 36

Daten-Referenz-System bei zafaco ................................................. 36

Messclient ................................................................................ 37

Gesamtübersicht Qualitätskennwerte der Datenmessungen ............... 37

PING Average Time .................................................................... 37

PING Packets Missing ................................................................. 38

PING Packet Errors .................................................................... 38

PING Failure Ratio ...................................................................... 38

HTTP Download Response Time ................................................... 39

HTTP Download Throughput ......................................................... 39

HTTP Download Throughput < x % of Bandwidth .............................. 41

HTTP Download Failure Ratio ....................................................... 41

Loadtest HTTP Download with parallel HTTP Upload ......................... 41

HTTP Upload Response Time ....................................................... 43

HTTP Upload Throughput ............................................................. 43

HTTP Upload Throughput < x % of Bandwidth .................................. 44

kyago


4 von 90

HTTP Upload Failure Ratio ........................................................... 44

Loadtest HTTP Upload with parallel HTTP Download ......................... 45

7 Web Services ............................................................................ 46

Gesamtübersicht Qualitätskennwerte der Web Services Messungen ... 48

DNS Lookup Time ...................................................................... 48

DNS Lookup Failure Ratio ............................................................ 49

HTTP Response Time (Kepler) ...................................................... 49

HTTP Session Duration (Kepler) .................................................... 50

HTTP Download Failure Ratio (Kepler) ............................................ 51

Website Response Time (Top 5 in 6 categories) .............................. 52

Website DOM Duration (Top 5 in 6 categories) ............................... 52

Website Load Duration (Top 5 in 6 categories) ............................... 53

Website Session Duration (Top 5 in 6 categories) ........................... 54

Website Download Failure Ratio (Top 5 in 6 categories) ................... 55

PING Average Time (Gaming Server) .............................................. 56

PING Packets Missing (Gaming Server) .......................................... 56

PING Packet Errors (Gaming Server) ............................................. 57

PING Failure Ratio (Gaming Server) ............................................... 57

8 Cloud Storages .......................................................................... 58

DNS Lookup Time ...................................................................... 59

DNS Lookup Failure Ratio ............................................................ 59

HTTP Download Response Time (Cloud Storage) .............................. 59

HTTP Download Throughput (Cloud Storage) ................................... 60

HTTP Download Failure Ratio (Cloud Storage) .................................. 61

HTTP Upload Response Time (Cloud Storage).................................. 61

HTTP Upload Throughput (Cloud Storage) ....................................... 62

HTTP Upload Failure Ratio (Cloud Storage) ..................................... 63

9 Video ...................................................................................... 64

Gesamtübersicht Qualitätskennwerte der Videomessungen ............... 64

kyago


5 von 90

9.1 IPTV ............................................................................... 65

IPTV STB Startup Response Time ................................................. 65

IPTV STB Startup Time ................................................................ 65

IPTV STB Startup Failure Ratio ..................................................... 66

IPTV Zapping Response Time ....................................................... 66

IPTV Zapping Time ..................................................................... 67

IPTV Zapping Failure Ratio ........................................................... 67

IPTV Bitrate Video/Other/Total .................................................... 68

IPTV Packet Loss ....................................................................... 68

IPTV Continuity Error Video/Audio ................................................. 68

IPTV I-/P-/B-Slices ..................................................................... 68

IPTV Video Quality Score ............................................................. 68

9.2 WebTV ............................................................................ 70

WebTV Video Response Time ....................................................... 71

WebTV Initial Buffering Time ........................................................ 71

WebTV Rebuffering Events........................................................... 72

WebTV Rebuffering Time ............................................................. 72

WebTV Video Sequence Duration .................................................. 72

WebTV Playback Sequence Duration ............................................. 72

WebTV Video Bitrate Meta .......................................................... 72

WebTV MOS ............................................................................. 72

WebTV Failure Ratio ................................................................... 75

10 Reporting ................................................................................. 76

11 Monitoring und Alarm-Interface .................................................... 84

12 Glossar .................................................................................... 86

kyago


6 von 90

1 Management Summary

In der zunehmend komplexen Welt der Informations- und Telekommunikationstechnologie ist die Kenntnis um die eigene Servicequalität ein entscheidender Faktor im Kampf um Marktanteile und Kundenzufriedenheit. Die hohen Erwartungen der Endbenutzer sowie die Einführung immer neuer, konvergierender Dienste und Technologien sind eine Herausforderung für alle Anbieter von ITK-Technologien.

Infolge dessen streben Unternehmen weltweit eine höhere Wettbewerbsfähigkeit an. Eines der wesentlichen Ziele stellt dabei die Steigerung der Qualität von Produkten und Prozessen dar. Eine Positionsbestimmung erfolgt in der Regel durch eine Orientierung am besten Mitwettbewerber. Ziel ist es, mit der Konkurrenz gleichzuziehen und aus der Beseitigung vorhandener Schwachstellen Vorteile zu erreichen.

Kontinuierlicher Benchmark

Im Rahmen eines kontinuierlichen Benchmarks bietet die zafaco GmbH seinen Kunden eine Plattform zur Überprüfung der messtechnisch erfassbaren Servicequalität und somit zur Sicherung und Optimierung von

Qualitätsaspekten in konvergenten Netzen an.

Die Basis hierzu ist die stetig wachsende NGN-Benchmark-Datenbank mit Qualitätskennzahlen der führenden DSL-, Kabel-, Mobilfunk- und VoIP-Anbieter. Mit den zur eigenständigen Nutzung überlassenen Ergebnissen versetzen wir unsere Kunden in die Lage, ihre Produkte und Dienstleistungen nachhaltig und langfristig zu verbessern. Daraus resultiert eine gesteigerte Kundenzufriedenheit und dieses führt

wiederum zu einer nachhaltigen Unternehmenswertsteigerung.

Kundensicht im Fokus

Das Erfassen der Servicequalität muss so authentisch wie möglich die Sicht der Kunden widerspiegeln, um auf die Kundenzufriedenheit schließen zu können. Kunden nehmen die Qualität eines Dienstes als Ganzes wahr. Dabei wird netzinternen, technologischen Aspekten weniger Beachtung geschenkt. Ob herkömmlich über vermittelte Netze oder paketorientierte Netze, ob analoge, digitale oder mobile

Anschlusstechniken: Der Kunde vergleicht Qualität und Preis.

Neben der technologischen Entwicklung steigt die Komplexität der Netze zusätzlich durch die zunehmende Anzahl von Netzübergängen. In einer solchen Konfiguration ist die vom Kunden erlebte Ende-zu-Ende Qualität nicht mehr alleine Sache eines einzigen Betreibers, sondern spiegelt die

Gesamtleistung aller beteiligten Netzbetreiber wider.

kyago


7 von 90

Realitätsnahe Simulation

Um eine realitätsnahe Simulation des Kunden durchführen zu können, gehört ein realitätsnaher Mix aus den einzelnen Services mit den entsprechenden Applikations-Protokollen und ebenso die Simulation eines typischen Anwenderprofils inklusive der notwendigen Authentifizierung, die ein Benutzer durchläuft, bevor das Netz einen gewünschten Service

bereitstellt.

Time to Market

Neue Dienste und Dienstleistungen müssen sehr schnell zu möglichst geringen Kosten und in der von den Endkunden erwarteten Qualität am Markt eingeführt werden. Eine permanente Überwachung der wichtigsten Funktionen und Qualitätsparameter ist notwendig, um sofort Maßnahmen bei Fehlfunktionen einleiten zu können. Der personelle und finanzielle

Aufwand für die Überwachung muss minimal gehalten werden.

Eckdaten des Benchmarks

Realitätsnahe Simulation

Alle führenden DSL-, Kabel-, Mobilfunk- und VoIP-Anbieter im Test

Nahezu 52 Millionen Testverbindungen pro Jahr, davon

- knapp 11 Millionen Sprachverbindungen

- mehr als 32 Millionen Daten- und Internetverbindungen

- annähernd 9 Millionen Videoverbindungen

Analyse von über 110 Qualitätskennwerten

Über 600 Mess-Schnittstellen an verschiedenen Standorten in

Deutschland verteilt

kyago


8 von 90

Prinzipien aus der Benchmarking-Praxis

Benchmarking als Managementmethode ist das Lernen von Organisationen und Unternehmen anhand von Best Practices und der angepassten Übertragung dieser besten Vorgehensweisen auf eigene Unternehmensprozesse. Das Ziel hierbei ist, es in einzelnen Unternehmensbereichen, oder in der Gesamtheit besser zu werden und die Wettbewerbsfähigkeit mit den vergleichsweise besten Methoden und Verfahren zu erhöhen.

Die wichtigsten Aspekte des Benchmarking sind:

Identifizierung und Lernen von anderen Unternehmen und

Organisationen

Orientierung an den besten Vorgehensweisen („Best Practice“) einer

Industrie

Einsatz von Benchmarking als Werkzeug bzw.

Managementinstrument

Nutzung von Benchmarking als Bestandteil eines dynamischen

Prozesses zur kontinuierlichen und nachhaltigen Verbesserung

Zusätzlicher Kundennutzen

Durch die Multi Play- und Benchmarking Plattform können weitere

Mehrwerte für Kunden in den folgenden Bereichen geschaffen werden:

Wettbewerbs Benchmark

Website Monitoring

Technologie, Applikations-und E-Commerce Performance

SLA Management

Last- und Stresstests

Netz- und Wirksamkeitsanalysen

Messung von Mindestqualitätsstandards für Regulierungsbehörden

Prüfung der Abrechnungsgenauigkeit

TÜV-Zertifizierungen

Von den Statistik-, Monitoring- und Analysedaten der Multi Play- und Benchmarking Plattform profitieren verschiedene Abteilungen eines

Kunden:

kyago


9 von 90

Statistik: Management, Planung, Marketing, Qualitätssicherung

Monitoring: Qualitätsmanagement, Netzbetrieb

Analyse: Netzbetrieb, Kundendienst

zafaco GmbH Unternehmensinformationen

Elefanten sind intelligente Tiere, die ihrer Umgebung sehr viel Aufmerksamkeit schenken und über sehr gut entwickelte Sinnesorgane verfügen. Bei zafaco rücken Sie als Kunde ins Zentrum der Aufmerksamkeit. Um Lösungen für Ihre Anforderungen in den Geschäftsbereichen Benchmarking, Business Service Management und Business Intelligence zu entwickeln, setzen wir wie der Elefant auf unsere

Sinnesorgane. Wir hören genauer zu und sehen genauer hin.

Technologische und fachliche Kompetenz sowie das konsequente Servicestreben und unser individuelles Problembewusstsein für unsere Kunden macht zafaco bei der Lösung Ihrer individuellen ITK-Probleme

dabei immer zur ersten Wahl.

Die zafaco GmbH arbeitet in einem eingespielten Netzwerk aus spezialisierten und professionellen Partnern, mit denen bereits zahlreiche Projekte erfolgreich realisiert worden sind.

zafaco GmbH Ansprechpartner

Ihre Fragen zu diesem Dokument, dessen Inhalt, Struktur oder Geltungsbereich sind uns willkommen.

Christoph Sudhues Gründer und geschäftsführender Gesellschafter

[email protected]

zafaco GmbH, Taxetstraße 66, 85737 Ismaning

www.zafaco.de

Copyright / Haftungsbeschränkung

Das dargestellte Wissen unterliegt dem geistigen Urheberrecht der zafaco GmbH. Der Wortlaut dieses Dokuments darf daher nicht in irgendeiner Form (Druck, Fotokopie oder andere Verfahren) ohne

schriftliche Genehmigung reproduziert oder weiterverarbeitet werden.

Trotz größter Sorgfalt und vielfältiger Qualitätssicherungen können bei entsprechend komplexen Ausarbeitungen Fehler auftreten. Die zafaco GmbH übernimmt daher keine juristische Verantwortung oder irgendeine

Haftung für eventuelle fehlerhafte Angaben und deren Folgen.

kyago


10 von 90

2 Die Multi Play- und Benchmarking Plattform

Beim zafaco Benchmarking kommt kyago zum Einsatz – die mehrfach ausgezeichnete Lösung zur Sicherung und Optimierung von

Qualitätsaspekten in konvergenten Netzen.

Die Messdaten werden nach den von dem Broadband Forum (TR 126), dem Deutsches Institut für Normung (DIN 66274), dem Europäischen Institut für Telekommunikationsnormen (ETSI EG 202 057, TS 103 222 und TR 101 290), der International Telecommunication Union (ITU P.863, T.22 und J.247), der Internet Engineering Task Force (IETF RFC3350 und RFC 3357) und dem World Wide Web Consortium (W3C)

definierten Empfehlungen erhoben.

Die Multi Play- und Benchmarking Plattform wurde mit konzeptioneller Unterstützung von realisiert.

Speziell zugeschnittene Hardware und Software

Für die Multi Play- und Benchmarking Plattform kommt leistungsfähige, auf diesen Einsatzzweck speziell zugeschnittene Hardware und Software zum Einsatz, die ein hohes Maß an Flexibilität und Zukunftssicherheit

ermöglicht.

Verschiedene Anschlusstechnologien

Das Spektrum möglicher Anwendungen umfasst Messungen auf analogen (a/b) und digitalen (ISDN S0, ISDN S2M) Leitungen, auf Luftschnittstellen (GSM, GPRS, UMTS, LTE) und auf LAN/WAN-Schnittstellen inklusive SIP-Trunking.

In Abhängigkeit der Messkampagne (Consumer, Business, Video etc.) kommt ein Mix der oben genannten Anschlusstechnologien zum Einsatz.

Somit können Daten erhoben werden, die in einer realen, gemischten Umgebung relevant sind. Dieser Ansatz gewährleistet eine Beurteilung der Servicequalität aus Kundensicht, denn alle in einer Ende-zu-Ende Verbindung beteiligten Systemkomponenten werden in den Test mit

einbezogen.

Ad-hoc-Messungen

Häufig ist es notwendig, bei einem Verdacht auf Probleme im Netz oder bei einer Häufung von Fehlern, vertiefte Messungen für die Analyse unter Berücksichtigung der genauen Umstände durchzuführen. In diesem Fall lassen sich gezielt Kampagnen kurzer Dauer definieren oder einzelne

Prüfverbindungen direkt am Bildschirm verfolgen.

kyago


11 von 90

Abbildung 1: Übersicht der Funktionen der Multi Play- und Benchmarking Plattform

Routine-Messungen

Um die Vorteile von Prüfverbindungen sinnvoll und ökonomisch nutzen zu können, braucht es eine Reihe von automatischen, computergestützten Mechanismen. Routinearbeiten sollen den Benutzer nicht belasten. Nur in Fällen, wo Fachwissen und Erfahrung wirklich gebraucht werden, soll der Spezialist eingeschaltet werden. Wir haben diese Anforderungen im

Konzept berücksichtigt.

Netzweite Untersuchungen lassen sich per Mausklick definieren, ausführen und auswerten. Die Messeinheiten arbeiten autonom ohne dass eine Bedienung vor Ort notwendig ist. Alle periodischen Aktivitäten werden vom zentralen Server automatisch gesteuert, manuelle können

bequem vom Arbeitsplatz im Büro ausgeführt werden.

Die Routine-Messungen lassen sich auf einfache Art definieren und werden ohne weitere Aufsicht ausgeführt. Der Benutzer erhält die Ergebnisse in Form von Reports und in übersichtlichen,

graphischen Dashboards.

kyago


12 von 90

Gilt es Qualitätsziele zu überwachen, können Routine-Messungen mit Schwellwerten versehen und überwacht werden. In diesem Fall spricht man von Monitoring. Erfüllt eine Prüfverbindung die Anforderungen nicht, wird der Benutzer sofort durch Alerts informiert und es stehen ihm für

diese Verbindung detaillierte Resultate zur Verfügung.

Standorte

kyago, die Multi Play- und Benchmarking Plattform, setzt sich aus Messeinheiten zusammen, die über 43 Standorte in Deutschland verteilt sind. Zum Aufbau gehören auch mehrere zentrale Server-Systeme, u.a. eine Business Intelligence Plattform, ein Data Warehouse und das Management System inklusive eines Systems zur Bewertung der Video-, Audio- und Sprachqualität.

Abbildung 2: Standorte der Multi Play- und Benchmarking Plattform

kyago


13 von 90

Die Verteilung der Standorte orientiert sich an folgenden Überlegungen:

Abdeckung mindestens aller einstelligen Vorwahlbereiche

Ermöglichung der Verfügbarkeit einer hohen Anzahl von Anbietern

an einem Standort durch Platzierung in größeren Städten

Anbieter

An den Standorten werden Produkte der folgenden Anbieter – sofern verfügbar und in Abhängigkeit der Messkampagne (Consumer, Business,

Video etc.) - genutzt:

Abbildung 3: Anbieter, die in Abhängigkeit der Messkampagne (Consumer, Business,

Video etc.) zum Einsatz kommen

kyago


14 von 90

Gesamtübersicht der Produkte und Anbieter

Tabelle 1: Gesamtübersicht der Produkte und Anbieter an den Standorten Teil 1

kyago


15 von 90

Tabelle 2: Gesamtübersicht der Produkte und Anbieter an den Standorten Teil 2

Gesamtübersicht der IADs und Firmware

Tabelle 3: Gesamtübersicht der IADs und Firmware nach Anbieter Consumer

kyago


16 von 90

3 Technisches Umsetzung

Die Messeinheiten (MU - Measurement Unit) der Multi Play- und Benchmarking Plattform bestehen aus speziell auf diesen Einsatzzweck

zugeschnittener Hard- und Software.

Die Steuerung und Wartung der Messeinheiten erfolgt von den Standorten der zafaco GmbH. Die Ergebnisse aller Messungen werden zentral am Münchener Standort der zafaco GmbH in einem Data Warehouse gesammelt und für das Reporting aufbereitet. Sämtliche für die Steuerung und Wartung der Einheiten und für die Übertragung der Messdaten und Messergebnisse erforderlichen Verbindungen werden

über VPNs realisiert.

Die Produkte der Anbieter sind inkl. der von den Anbietern gelieferten IADs oder Routern an den jeweiligen Standorten installiert. Die Messeinheiten an diesen Standorten führen über diese Produkte diverse Messungen wie Sprachqualitätsmessungen, Faxmessungen, Highspeed Internet Messungen, Web und Cloud Services Messungen und

Videoqualitätsmessungen in Abhängigkeit der Messkampagne durch.

Abbildung 4: Schematischer Aufbau der Multi Play- und Benchmarking Plattform

Für Sprachqualitätsmessungen sind zusätzlich als Gegenstelle ISDN Anschlüsse der Deutschen Telekom vorhanden, die ebenso auf den Messeinheiten aufgeschaltet sind. Weiterhin werden auch analoge Anschlüsse der Deutschen Telekom genutzt, die als Gegenstelle für

kyago


17 von 90

Faxmessungen dienen. Durch die Konfiguration des Messablaufs ist sichergestellt, dass immer zwischen zwei unterschiedlichen Standorten

gemessen wird.

Weitere Messeinheiten sind mit Mobilfunk Modulen und SIM-Multiplexern, die eine hohe Flexibilität in der Nutzung der SIM Karten der Anbieter ermöglichen, ausgestattet, um Sprachqualitätsmessungen von

und zu GSM/UMTS/LTE zu realisieren.

Abbildung 5: Beispielhafter Aufbau der kyago Plattform an einem Standort

kyago


18 von 90

4 Ende-zu-Ende Sprachqualitätsmessungen

Ende-zu-Ende Sprachqualitätsmessungen werden zwischen den an den Standorten in Deutschland verteilten Messeinheiten durchgeführt. Dazu werden Verbindungen über Endkundenschnittstellen aufgebaut. Das heißt, dass die Messeinheiten jeweils über ISDN, Analog oder SIP eines vom jeweiligen Anbieter unterstützen IADs oder Router die Verbindungen aufbauen bzw. entgegennehmen. Das IAD wandelt hierbei die über ISDN oder Analog initiierten Verbindungen in VoIP beziehungsweise die entgegengenommen VoIP Verbindungen in ISDN oder Analog um. Als Gegenstellen dieser Messungen dienen zusätzlich auch die ISDN-Anschlüsse der Deutschen Telekom sowie die GSM/UMTS/LTE Module mit den SIM-Karten der Anbieter.

Parallel zu diesen Messungen werden zusätzlich Ende-zu-Ende Sprachqualitätsmessungen als Referenzmessungen von ISDN zu ISDN der Deutschen Telekom ausgeführt. Diese Referenzmessungen (ISDN zu ISDN) dienen dazu, die gemessenen QoE Parameter von VoIP direkt mit

herkömmlicher, leitungsvermittelter Telefonie vergleichbar zu machen.

Zur Ermittlung der Ende-zu-Ende Sprachqualität der jeweiligen Verbindungen werden Standard ITU-T Sprachproben männlicher und weiblicher Stimmen mehrfach in beide Kommunikationsrichtungen übertragen und im anschließenden automatisierten Bewertungsverfahren mit den Originalen verglichen. Die Bewertung der Sprachqualität erfolgt nach dem ITU-T Standard P.863 (POLQA), die Durchführung der Sprachqualitätsmessungen richtet sich nach dem Leitfaden ETSI EG 202 057 - Part 1- 4.

Das gleichzeitige Telefonieren und Übertragen von Daten durch Up- und Downloads und/oder IPTV, ist ein weiteres Nutzungsszenario der Produkte. Daher wurden Sprachqualitätsmessungen mit parallelem Up- und Download in die Messungen aufgenommen. Dadurch werden Informationen über eine ggf. vorgenommene Priorisierung der

Sprachdaten bei voller Auslastung der Bandbreite geliefert.

kyago


19 von 90

Gesamtübersicht der Verkehrsbeziehungen für

Sprachqualitätsmessungen

Folgende Verkehrsbeziehungen sind für Sprachqualitätsmessungen

möglich:

Tabelle 4: Mögliche Verkehrsbeziehungen für Sprachqualitätsmessungen

kyago


20 von 90

Gesamtübersicht Qualitätskennwerte der Sprachmessungen

Folgende Messwerte werden im Rahmen der Sprachqualitätsmessungen

erhoben:

Tabelle 5: Übersicht Qualitätskennwerte der Sprachmessungen

Call Setup Duration

Zur Ermittlung der Verbindungsaufbauzeit wird die Zeit in Sekunden vom Absenden der DSS1 SETUP Nachricht durch die „A“-Seite (Rufnummer + „Sending Complete“ Information) bis zum Eintreffen der DSS1 CONNECT

Nachricht auf der „A“-Seite gemessen (siehe grüner Pfeil in Abbildung 6).

kyago


21 von 90

Abbildung 6: Messung der Call Setup Duration

Call Setup Failure Ratio

Die Call Setup Failure Ratio gibt das Verhältnis von fehlerhaften Verbindungsaufbauversuchen zu den insgesamt initiierten Verbindungen in Prozent wieder.

Verbindungsaufbauversuche, die innerhalb von 10 Sekunden nach dem Absenden der DSS1 SETUP Nachricht nicht durch die DSS1 CONNECT

Nachricht bestätigt wurden, werden als nicht erfolgreich gewertet.

kyago


22 von 90

Connect Setup Duration

Zur Ermittlung der Verbindungsaufbauzeit wird die Zeit in Sekunden vom Absenden der SIP INVITE Nachricht durch die „A“-Seite bis zum Eintreffen der SIP 200 OK Nachricht auf der „A“-Seite gemessen (siehe grüner Pfeil in Abbildung 7).

Abbildung 7: Messung der Connect Setup Duration

Connect Setup Failure Ratio

Die Connect Setup Failure Ratio gibt das Verhältnis von fehlerhaften Verbindungsaufbauversuchen zu den insgesamt initiierten Verbindungen

in Prozent wieder.

Verbindungsaufbauversuche, die innerhalb von 10 Sekunden nach dem Absenden der SIP INVITE Nachricht nicht durch die SIP 200 OK

Nachricht bestätigt wurden, werden als nicht erfolgreich gewertet.

kyago


23 von 90

Call Failure Ratio

Die Call Failure Ratio gibt das Verhältnis von fehlerhaften Gesprächen zu

den insgesamt initiierten Verbindungen in Prozent wieder.

Ein Gespräch beginnt bei der Technologie ISDN z.B. mit dem Absenden der DSS1 SETUP Nachricht und gilt als erfolgreich, wenn das Ende durch eine DSS1 DISCONNECT Nachricht des Anrufers ("A"-Seite) eingeleitet wurde (siehe grüner Pfeil in Abbildung 8).

Abbildung 8: Ermittlung der Call Failure Ratio

Call Drop Ratio

Der Messwert Call Drop Ratio gibt das Verhältnis von abgebrochenen Gesprächen zu den insgesamt initiierten Verbindungen in Prozent wieder.

Ein Gespräch beginnt bei der Technologie ISDN z.B. mit dem Absenden der DSS1 SETUP Nachricht und gilt als abgebrochen, wenn das Ende nicht durch eine DSS1 DISCONNECT Nachricht des Anrufers ("A"-Seite)

kyago


24 von 90

eingeleitet wurde. In diesem Fall signalisiert das Netzwerk beiden Gesprächspartnern mit der DSS1 RELEASE Nachricht das Ende der

Verbindung (siehe grüner Pfeil in Abbildung 9).

Abbildung 9: Ermittlung der Call Drop Ratio

MOS LQO

Zur Bewertung der Ende-zu-Ende Sprachqualität einer Telefonverbindung werden ca. acht Sekunden lange Standard ITU-T Sprachproben weiblicher und männlicher Stimmen sequenziell zwischen Anrufer („A“-Seite) und

Gerufenem („B“-Seite) übertragen.

In Abbildung 10 ist der Ablauf einer Sprachqualitätsmessung exemplarisch für eine Verbindung von VoIP zu ISDN vereinfacht dargestellt. Dieser Ablauf gilt für alle Verbindungen ohne parallele

Datenlast entsprechend der oben genannten Verkehrsbeziehungen.

kyago


25 von 90

Abbildung 10: Messung der Sprachqualität

Es werden zwei bidirektionale sequentielle Sprachübertragungen

durchgeführt.

Wie in Abbildung 10 zu sehen ist, wird in den folgenden Darstellungen eine Sprachprobe, die von „A“ nach „B“ gesendet und auf der „B“-Seite aufgezeichnet wurde, mit „AB“ bezeichnet. Eine Sprachprobe, die auf der

„A“-Seite aufgezeichnet wurde, wird mit „BA“ gekennzeichnet.

Die Bewertung der Qualität der aufgezeichneten Sprachproben erfolgt durch den ITU-T Standard P.863 (POLQA). Die jeweiligen Originale der verwendeten Sprachproben werden hierzu an der mit „Input Reference“ gekennzeichneten Stelle in den POLQA Algorithmus gegeben (siehe Abbildung 11). Die zu bewertenden aufgezeichneten Sprachproben werden an der mit „Degraded Output“ gekennzeichneten Stelle in den Algorithmus gegeben. Der POLQA Algorithmus führt eine Reihe von Anpassungs-, Ausgleichs- und Synchronisationsoperationen durch und ermittelt ausgehend vom implementierten Psycho-Akustischen Modell einen Sprachqualitätswert, der letztendlich auf die MOS Skala abgebildet

kyago


26 von 90

und als MOS LQO Wert ausgegeben wird. Die MOS Skala reicht von 0 (schlecht) bis zu 4.75 (am besten) im Super-Wideband Mode, welcher

bei den Messungen zum Einsatz kommt.

Abbildung 11: Vereinfachte Darstellung des POLQA Algorithmus

[Quelle: Whitepaper OPTICOM GmbH]

Sprachqualitätsmessung mit parallelem Up- und Download

Der Ablauf einer Sprachqualitätsmessung mit parallelem Up- und Download zur Auslastung der vollen Bandbreite der Produkte ist in der folgenden Abbildung 12 exemplarisch dargestellt. Hierzu wird der Upload/Download mindestens fünf Sekunden vor der Sprachqualitätsmessung aufgebaut. Weitere 5 Sekunden nach dem Start der Sprachqualitätsmessung wird der Download/Upload gestartet. Der Upload und Download wird erst nach dem Ende der Sprachqualitätsmessung gestoppt, um eine volle Auslastung der Bandbreite während der Messung zu gewährleisten. Bei Verbindungen zwischen NGN Anschlüssen in der Messkampagne Consumer werden 2

Verbindungen parallel aufgebaut.

kyago


27 von 90

Abbildung 12: Messung der Sprachqualität mit paralleler Datenlast

Das in Abbildung 12 dargestellte Verfahren für die Sprachqualitäts-messung mit parallelem Up- und Download gilt auch in der gleichen Weise für die Erfassung aller in diesem Kapitel dargestellten Sprachqualitätskennwerte, d.h. jeder dieser Messwerte wird jeweils mit

und ohne parallelem Up- und Download (Datenlast) ermittelt.

kyago


28 von 90

Speech Delay

Der Messwert wird mit Hilfe des POLQA Algorithmus durch den Vergleich der ca. acht Sekunden lange Standard ITU-T Referenz-Sprachprobe mit den nach Übertragung aufgezeichneten Sprachproben ermittelt. Hierbei wird eine aufgezeichnete Sprachprobe fragmentweise mit der Referenz-Sprachprobe verglichen und für jedes dieser Sprachfragmente ein Speech Delay-Wert errechnet. Aus diesen Einzelwerten wird wiederum ein Durchschnittswert gebildet, der damit die mittlere Sprachlaufzeit der gesamten Sprachprobe in Millisekunden darstellt (siehe Abbildung 13).

Zur Ermittlung dieses Messwertes wird eine hohe Zeitsynchronität der beteiligten Messeinheiten benötigt. Diese Synchronität wird über das NTP gewährleistet, dessen Genauigkeit zusätzlich durch statische und

dynamische Korrekturmechanismen erhöht wird.

Abbildung 13: Messung des Speech Delays

kyago


29 von 90

Multitone Errors

Zur Bewertung der Übertragungsqualität von Tonwahlzeichen einer Telefonverbindung werden sequentiell 12 unterschiedliche Töne innerhalb eines Audiofiles zwischen Anrufer ("A"-Seite) und Gerufenem ("B"-Seite) übertragen. Damit wird beispielweise ein Datenaustausch von Notruftelefonen, Zugriffe auf Babytelefonen oder Callthrough-Funktionalitäten simuliert, da dort diese Tonwahlzeichen zum

Datenaustausch in bestehenden Verbindungen verwendet werden.

Die aktuell verwendete Ton-Sequenz besteht aus den Tönen "15948#703260", welche innerhalb eines Audiofiles gesendet werden, d.h. mit 100 ms Tondauer und 500 ms Pausendauer. Die Messung wird im Anschluss an die Sprachqualitätsmessung durch eine bidirektionale

sequentielle Ton-Übertragung durchgeführt.

Abbildung 14: Messung der Übertragungsqualität von Tönen

kyago


30 von 90

Wie in Abbildung 14 zu sehen ist, wird eine Ton-Sequenz von "A" nach "B" gesendet, von der "B"-Seite aufgenommen und mit "AB" bezeichnet. Eine Ton-Sequenz, die auf der "A"-Seite aufgezeichnet wurde, wird mit "BA" gekennzeichnet. Die Töne werden als eine Audiodateien im Sprachkanal abgespielt, d.h. die Töne werden nicht im

Signalisierungskanal übertragen.

Die Erkennung und Analyse der aufgezeichneten Ton-Sequenz erfolgt durch den Vergleich der aufgenommenen Audiodatei mit der

Referenzdatei, in der die erwartete Ton-Folge enthalten ist.

Der Messwert Multitone Errors gibt das Verhältnis von fehlerbehafteten

Tönen zu den insgesamt gesendeten Tönen in Prozent an.

Ein Ton wird als fehlerhaft bewertet, wenn der aufgezeichnete mit dem

erwarteten Ton nicht vollständig übereinstimmt.

Multitone Failure Ratio

Das Verhältnis der fehlerbehafteten Ton-Sequenzen zu den insgesamt gesendeten Ton-Sequenzen stellt die Multitone Failure Ratio in Prozent dar.

Bei nicht vollständiger Übereinstimmung der Anzahl und Reihenfolge der aufgezeichneten mit der erwarteten Ton- Folge wird die Ton Sequenz als

fehlerhaft bewertet.

kyago


31 von 90

5 Fax

Gesamtübersicht Qualitätskennwerte der Faxmessungen

Folgende Messwerte werden im Rahmen der Faxqualitätsmessungen

erhoben:

Tabelle 6: Übersicht Qualitätskennwerte der Faxmessungen

Zur Ermittlung der Ende-zu-Ende Faxqualität der jeweiligen Verbindung wird eine Testseite (ITU-T.22 Test chart No.4 – siehe Abbildung 15) mittels T.30 Protokoll und V.17 in einer Kommunikationsrichtung übertragen und im anschließenden automatisierten Bewertungsverfahren mit dem Original verglichen (siehe Abbildung 16).

Abbildung 15: ITU-T.22 Test chart No.4

kyago


32 von 90

Abbildung 16: Messung der Faxübertragungsqualität

kyago


33 von 90

Fax Setup Duration

Zur Ermittlung der Fax Verbindungsaufbauzeit wird die Zeit in Sekunden vom Absenden der Wahlinformation durch die „A“-Seite bis zum Start der Übertragung der Fax Seite auf der „A“-Seite gemessen (siehe grüner Pfeil in Abbildung 17).

Abbildung 17: Messung der Fax Setup Duration

kyago


34 von 90

Fax Transmission Duration

Mit diesem Messwert wird die Übertragungsdauer einer Fax Seite in

Sekunden gemessen.

Die Fax Übertragungsdauer ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Start der Übertragung der Fax Seite durch die „A“-Seite bis zur vollständigen Übertragung der Fax Seite auf der „A“-Seite vergeht (siehe grüner Pfeil in Abbildung 18).

Abbildung 18: Messung der Fax Transmission Duration

kyago


35 von 90

Fax Failure Ratio

Die Fax Failure Ratio gibt das Verhältnis von fehlerhaften Faxübertragungen zu den insgesamt initiierten Faxübertragungen in

Prozent wieder.

Eine Faxübertragung wird als fehlerhaft bewertet, wenn der Faxverbindungsaufbau oder die Faxübertragung nicht erfolgreich ist, oder Faxverbindungsaufbau und Faxübertragung nicht innerhalb von 180

Sekunden abgeschlossen wurden.

kyago


36 von 90

6 Highspeed Internet

Zur Bewertung der Highspeed Internet Verbindungsqualität der Produkte werden verschiedene Messungen durchgeführt. Die verfügbare Up- und Downstream Bandbreite wird durch standardisierte Up- und Downloadmessungen (ETSI EG 202 057 - Part 4 und TS 103 222) bestimmt, die zu Messservern oder Daten-Referenz-Systemen erfolgen. Diese Messungen werden zusätzlich auch bei zeitgleichem Up- oder Download durchgeführt, um das Verhalten der Produkte bei zeitgleicher

Auslastung der Bandbreite zu ermitteln.

Das zafaco Messkonzept zur Bewertung der Highspeed Internet Verbindungsqualität besteht aus Messsystem und Messverfahren. Dabei bezeichnet das Messsystem die Kombination aus Messstelle (Messclient) und Gegenmessstelle (Messserver/Daten-Referenz-System) und das Messverfahren den technischen Messprozess.

Messserver/Daten-Referenz-System und Messclient kommunizieren miteinander und bilden das Messkonzept für Namensauflösung, Laufzeit-,

Download- und Upload Messungen.

Messserver beim Anbieter oder zafaco

Die Messserver Applikation kann zentral als auch dezentral eingesetzt werden und managet die Ressourcen für die Messungen auf den Messservern. Sie dienen als Gegenstelle für Messungen von einem Messclient. Die Messserver stellen ihre Dienste als UDP oder TCP Verbindungen auf Port 80 oder 8080 zur Verfügung.

Daten-Referenz-System bei zafaco

Das Daten-Referenz-System besteht aus Messservern und Load Balancer. Dieses System gewährleistet eine ausreichende Performance über die gesamte Messdauer. Etwaige Performance-Engpässe einzelner Messserver werden detektiert. Die Messclient-Applikation reagiert

selbstständig mit der Wahl eines geeigneten Messservers.

Der Load Balancer des Daten-Referenz-Systems besteht aus zwei Komponenten. Zum einen aus dem DNS System, das bei mehreren Messservern eine Verteilung der Messclient Anfragen auf alle verfügbaren Messservern nach dem Round-Robin Verfahren durchführt. Zum anderen aus einer Systemüberwachung, die CPU, Speicher, Systembelastung (Load) und die aktuelle Datenrate auf der Netzwerkschnittstelle analysiert. Durch die Systemüberwachung ist gewährleistet, dass eine Überlast des Daten-Referenz-Systems während der Messung ausgeschlossen ist und jeder Messclient genügend

Ressourcen für die Messung bereitgestellt bekommt.

kyago


37 von 90

Messclient

Der Messclient kommuniziert aktiv mit dem Messserver/Daten-Referenz-System, indem dieser im Falle des Messservers/Daten-Referenz-Systems freie Ressourcen abfragt, eine Authentifizierung des Messclients gegenüber dem Messserver/Daten-Referenz-System

vornimmt und anschließend die Messungen initiiert.

Der Messclient ist sowohl als Java Applet, Android und iOS Applikation

wie auch als C++ Software verfügbar.

Gesamtübersicht Qualitätskennwerte der Datenmessungen

Tabelle 7: Übersicht Qualitätskennwerte der Datenmessungen

Bei den Datenlast-Tests gilt, dass die Störgröße (Last) mindestens fünf Sekunden vor dem Start der Messgrößen aufgebaut und erst nach Beendigung der Messung abgebaut wird. Ausschließlich die

Qualitätskennwerte der Messgröße fließen in die Ergebnisse ein.

PING Average Time

Eine PING Messung besteht im Kontext dieses Dokumentes aus 10 hintereinander im Abstand von jeweils einer Sekunde ausgeführten ICMP Echo Requests mit einem Timeout von 1 Sekunde für jeden ICMP Echo

Request zum Messserver/Daten-Referenz-System.

http://de.wikipedia.org/wiki/Internet_Control_Message_Protocol


kyago


38 von 90

Der Messwert PING Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden eines ICMP Echo Request bis zum Eintreffen

des ICMP Echo Reply vergeht (siehe grüner Pfeil in Abbildung 19).

Mit dem Wert PING Average Time wird die mittlere Antwortzeit aller PING Times einer PING Messung in Millisekunden dargestellt.

Abbildung 19: Messung der PING Time

PING Packets Missing

Der Messwert PING Packets Missing gibt das Verhältnis von nicht empfangenen ICMP Echo Replys zu den insgesamt initiierten ICMP Echo Requests in Prozent an. Ein ICMP Echo Reply gilt als nicht empfangen, wenn er nicht innerhalb des Timeouts von 1 Sekunde auf ein ICMP Echo

Request eintrifft.

PING Packet Errors

Der Messwert PING Packet Errors gibt das Verhältnis von fehlerbehafteten ICMP Echo Replys zu den insgesamt erhaltenen ICMP

Echo Replys in Prozent an.

PING Failure Ratio

Das Verhältnis von nicht erfolgreich durchgeführten Ping Messungen zu insgesamt initiierten PING Messungen stellt die PING Failure Ratio in Prozent dar. Eine PING Messungen gilt als nicht erfolgreich, wenn ICMP Echo Replys fehlen, fehlerbehaftet sind (z.B. das Ziel antwortet nicht mit dem gleichen Wert in der "Sequence Number) oder die mittlere

Antwortzeit (PING Average Time) 1 Sekunde überschreitet.










kyago


39 von 90

HTTP Download Response Time

Mit diesem Messwert wird die Antwortzeit einer HTTP Initialisierung im

Download in Millisekunden gemessen.

HTTP Download Response Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des initialen HTTP Requests (GET HTTP) bis zum Eintreffen des ersten HTTP Response Paketes (TCP Packet) vergeht (siehe grüner Pfeil in Abbildung 20).

Zur Ermittlung der verschiedenen HTTP Download-Parameter der Produkte vier parallele HTTP-Datenströme initiiert, die mit ausreichend Daten von dem Messserver/Daten-Referenz-System auf den Messclient

übertragen werden.

Dabei wird pro HTTP-Datenstrom eine HTTP Response Times erfasst und

der Minimalwert aller erfassten HTTP Response Times gewertet.

Abbildung 20: Messung der HTTP Response Time

HTTP Download Throughput

Um eine realitätsnahe Nutzungssituation abzubilden, wird das von End-kunden häufig angewandte Hypertext Transfer Protokoll (HTTP) eingesetzt.

Hierzu werden vier parallele HTTP-Datenströme initiiert, die mit ausreichend Daten von dem Messserver/Daten-Referenz-System auf den Messclient übertragen werden. Dazu wird zur Laufzeit der Messung

kyago


40 von 90

kontinuierlich eine hinreichend große Datenmenge auf dem Messserver/Daten-Referenz-System generiert. Hinreichend groß bedeutet hier, dass auch bei der maximal betrachteten Datenübertragungsrate sichergestellt wird, dass während des gesamten Messzeitraums ein Datentransfer stattfindet und die auf dieser Stecke

maximal mögliche Datenübertragungsrate gemessen werden kann.

Die Datenübertragung aller Datenströme wird nach einer festgelegten Zeit abgebrochen. Bei der Bestimmung des Zeitfensters werden die

Effekte der TCP Congestion Control (Überlaststeuerung) berücksichtigt.

Die HTTP Download Time ergibt sich als Zeit vom Startzeitpunkt des letzten HTTP-Streams inklusive der Berücksichtigung der Effekte der TCP Congestion Control bis zum ersten Abbruchzeitpunkt der parallelen HTTP-Streams des standardisierten HTTP-Downloads. Damit bezeichnet die HTTP Download Time den Zeitraum, während dessen alle parallelen

HTTP-Streams zeitgleich Last erzeugen.

Die Datenmenge, die übertragen wird, berechnet sich aus der Summe der geladenen Daten der einzelnen HTTP-Streams während der HTTP

Download Time.

Aus Datenmenge und HTTP Download Time (siehe grüner Pfeil in Abbildung 21) wird der HTTP Download Throughput und damit die zur Verfügung stehende Download-Datenübertragungsrate in Mbit/s

berechnet.

Abbildung 21: Messung des HTTP Download Throughputs

kyago


41 von 90

HTTP Download Throughput < x % of Bandwidth

Wenn ein HTTP Download x Prozent der in Rechnung gestellten Geschwindigkeit oder vom Anbieter kommunizierten Geschwindigkeit

unterschreitet, wird dieser als reduzierter HTTP Download gewertet.

Der Wert HTTP Download Throughput < x % of Bandwidth gibt das Verhältnis der reduzierten HTTP Downloads zu den insgesamt durchgeführten HTTP Downloads in Prozent an.

HTTP Download Failure Ratio

Sind alle vier HTTP Streams des standardisierten HTTP Downloads fehlerhaft oder überschreitet der Minimalwert der erfassten HTTP Download Response Times 1 Sekunde, so wird der HTTP Download als

nicht erfolgreich gewertet.

Die HTTP Download Failure Ratio gibt das Verhältnis von nicht erfolgreich durchgeführten HTTP Downloads zu den insgesamt initiierten HTTP

Downloads in Prozent wieder.

Loadtest HTTP Download with parallel HTTP Upload

Die Qualitätskennwerte HTTP Download Response Time, HTTP Download Throughput, HTTP Download Throughput < x % of Bandwidth und HTTP Download Failure Ratio werden zusätzlich mit parallelem HTTP Upload zur Auslastung der vollen Bandbreite messtechnisch erfasst (siehe Abbildung

22).

kyago


42 von 90

Abbildung 22: Messung des HTTP Download Throughputs mit parallelem HTTP Upload

Hierbei gilt, dass der HTTP Upload als Störgröße (Last) mindestens fünf Sekunden vor der Sprachqualitätsmessung gestartet wird. Weitere 5 Sekunden nach dem Start der Sprachqualitätsmessung wird der Download gestartet. In der Messkampagne Consumer werden zwischen NGN Anschlüssen 2 Verbindungen parallel aufgebaut. Der Störgröße (Last) wird erst nach dem Ende der Sprachqualitätsmessung gestoppt, um eine volle Auslastung der Bandbreite während der Messung zu gewährleisten.

Ausschließlich die Qualitätskennwerte des HTTP Downloads und der Sprachqualitätsmessung fließen als Messgröße in die Bewertung ein.

Alle Qualitätskennwerte bis auf die HTTP Response Time werden nach den gleichen Verfahren wie ohne parallelen HTTP Upload berechnet. Als HTTP Response Time des standardisierten HTTP Downloads wird hier der Mittelwert der erfassten HTTP Response Times gewertet. Der Timeout des Mittelwerts der erfassten HTTP Download Response Times vergrößert sich auf 5 Sekunden.

kyago


43 von 90

HTTP Upload Response Time

Mit diesem Messwert wird die Antwortzeit einer HTTP Initialisierung im

Upload in Millisekunden gemessen.

HTTP Upload Response Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des initialen HTTP Requests (POST HTTP) bis zum Eintreffen des ersten HTTP Response Paketes (TCP Packet) vergeht (siehe grüner Pfeil in Abbildung 23).

Zur Ermittlung der verschiedenen HTTP Upload-Parameter der Produkte werden vier parallele HTTP-Datenströme initiiert, die mit ausreichend Daten von dem Messserver/Daten-Referenz-System auf den Messclient

übertragen werden.

Dabei wird pro HTTP-Datenstrom eine HTTP Response Times erfasst und

der Minimalwert aller erfassten HTTP Response Times gewertet.

Abbildung 23: Messung der HTTP Upload Response Time

HTTP Upload Throughput

Auch bei der Messung der Datenübertragungsrate im Upload wird das von Endkunden häufig angewandte Hypertext Transfer Protokoll (HTTP) eingesetzt.

Dazu werden vier parallele HTTP-Datenströme initiiert, die mit ausreichend Daten von dem Messclient auf das Messserver/Daten-Referenz-System übertragen werden. Dazu wird zur Laufzeit der Messung kontinuierlich eine hinreichend große Datenmenge auf dem Messclient generiert. Hinreichend groß bedeutet hier, dass auch bei der

kyago


44 von 90

maximal betrachteten Datenübertragungsrate sichergestellt wird, dass während des gesamten Messzeitraums ein Datentransfer stattfindet und die auf dieser Stecke maximal mögliche Datenübertragungsrate gemessen werden kann.

Die HTTP Upload Time (siehe grüner Pfeil in Abbildung 24) ergibt sich als Zeit vom Startzeitpunkt des letzten HTTP-Streams inklusive der Berücksichtigung der Effekte der TCP Congestion Control bis zum ersten Abbruchzeitpunkt der parallelen HTTP-Streams des standardisierten HTTP-Uploads. Damit bezeichnet die HTTP-Upload-Zeit den Zeitraum, während dessen alle parallelen HTTP-Streams zeitgleich Last erzeugen.

Aus Datenmenge und HTTP Upload Zeit wird der HTTP Upload Throughput und damit die zur Verfügung stehende

Datenübertragungsrate im Upload des Produkts in Mbit/s berechnet.

Abbildung 24: Messung des HTTP Upload Throughputs

HTTP Upload Throughput < x % of Bandwidth

Wenn ein HTTP Upload x Prozent der in Rechnung gestellten Geschwindigkeit oder vom Anbieter kommunizierten Geschwindigkeit

unterschreitet, wird dieser als reduzierter HTTP Upload gewertet.

Der Wert HTTP Upload Throughput < x % of Bandwidth gibt das Verhältnis der reduzierten HTTP Uploads zu den insgesamt

durchgeführten HTTP Uploads in Prozent an.

HTTP Upload Failure Ratio

Sind alle vier HTTP Streams des standardisierten HTTP Upload fehlerhaft oder überschreitet der Minimalwert der erfassten HTTP Upload Response Times 1 Sekunde, so wird der HTTP Upload als nicht

erfolgreich gewertet.

kyago


45 von 90

Die HTTP Upload Failure Ratio gibt das Verhältnis von nicht erfolgreich durchgeführten HTTP Uploads zu den insgesamt initiierten HTTP Uploads

in Prozent wieder.

Loadtest HTTP Upload with parallel HTTP Download

Die Qualitätskennwerte HTTP Upload Response Time, HTTP Upload Throughput, HTTP Upload Throughput < x % of Bandwidth und HTTP Upload Failure Ratio werden zusätzlich mit parallelem HTTP Download zur Auslastung der vollen Bandbreite messtechnisch erfasst (siehe Abbildung

25).

Abbildung 25: Messung des HTTP Upload Throughputs mit parallelem HTTP Download

Hierbei gilt, dass der HTTP Download als Störgröße (Last) mindestens fünf Sekunden vor der Sprachqualitätsmessung gestartet. Weitere 5 Sekunden nach dem Start der Sprachqualitätsmessung wird der Upload gestartet. In der Messkampagne Consumer werden zwischen NGN Anschlüssen 2 Verbindungen parallel aufgebaut. Der Störgröße (Last) wird erst nach dem Ende der Sprachqualitätsmessung gestoppt, um eine volle Auslastung der Bandbreite während der Messung zu gewährleisten. Ausschließlich die Qualitätskennwerte des HTTP Uploads und der

Sprachqualitätsmessung fließen als Messgröße in die Bewertung ein.

Alle Qualitätskennwerte werden nach den gleichen Verfahren wie ohne parallelen HTTP Download berechnet. Der Timeout für die HTTP Upload

Response Time vergrößert sich auf 5 Sekunden.

kyago


46 von 90

7 Web Services

Auch bei hohen Besucherzahlen und zeitlich begrenzten Verkaufsaktionen erwarten Kunden eine optimale Performance. Unzufriedene Kunden entstehen durch lange Ladezeiten, stockenden Musik und Videoclips oder nicht erreichbare Websites. Durchschnitts-User warten nicht länger als vier Sekunden auf das vollständige Erscheinen einer Website. 90 Prozent der Internet-Kunden kehren spätestens nach drei fehlgeschlagenen

Zugriffsversuchen einem Online-Shop den Rücken.

Mit der Multi Play- und Benchmarking Plattform werden einerseits Antwortzeitmessungen auf dem Transportlayer zu einer standardisierten Testseite (ETSI Kepler Reference Page) zu den in der Tabelle 8

genannten Webhosting-Anbieter ausgeführt.

Anderseits werden Analysen von Webseitenaufrufen auf Applikationslayer (Firefox mit Plug-in) beim Zugriff zu den Websites aus den unterschiedlichen Kategorien „Nachrichten, Internetportale, Suchmaschinen, Einkaufen, Sport und Business“ der Tabelle 8

durchgeführt.

Zur Ermittlung der Qualitätskennwerte wird ein Firefox Webbrowser, mit entsprechenden Plug-Ins zur Betrachtung aller wesentlichen Bestandteile der zu testenden Webseite, verwendet. Firefox wird aktuell mit über 41% Marktanteil in Deutschland am häufigsten verwendet (Quelle: statista – Marktanteil der führenden Browserfamilien - Stand September 2014).

Die Analysen von Webseitenaufrufen werden als Over-the-Top Messung durchgeführt. Hierbei entstehen keine Beschränkungen bezüglich der vom System bzw. Browser verwendeten Protokolle wie IPv4/v6, HTML 1.x/HTML 2.0 oder der Einsatz von SSL/TLS. Zur Ermittlung der Messwerte werden wesentliche Teile der nach W3C „Navigation Timing“

standardisierten Triggerpunkte verwendet.

Zudem werden Antwortzeitmessungen zu den in der Tabelle 8 genannten Gaming Servern durchgeführt.

kyago


47 von 90

Tabelle 8: Übersicht Webhosting-Anbieter, Gaming Server und Top 5 Webseiten aus 6

Kategorien

kyago


48 von 90

Gesamtübersicht Qualitätskennwerte der Web Services Messungen

Tabelle 9: Übersicht Qualitätskennwerte der Web Services Messungen

DNS Lookup Time

Mit diesem Messwert wird die Auflösungszeit von Hostnamen in IP-

Adressen in Millisekunden gemessen.

DNS Lookup Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden eines DNS Requests (DNS query) zum IAD bis zum Eintreffen der aufgelösten IP-Adresse (DNS query response) vergeht (siehe grüner Pfeil in Abbildung 26). Falls für den angeforderten Hostnamen weitere CNames (sogenannte Aliase) registriert wurden, wird pro CName eine weitere DNS Anfrage versendet. Für die Messung wird

aber nur die erste DNS Antwort ausgewertet.

kyago


49 von 90

Abbildung 26: Messung der DNS Lookup Time

DNS Lookup Failure Ratio

Ist ein DNS Request fehlerhaft oder überschreitet die DNS Lookup Time

1 Sekunde, so wird der DNS Request als nicht erfolgreich gewertet.

Das Verhältnis von nicht erfolgreich durchgeführten DNS Requests zu insgesamt initiierten DNS Requests stellt die DNS Lookup Failure Ratio in

Prozent dar.

HTTP Response Time (Kepler)

Mit diesem Messwert wird die Antwortzeit einer HTTP Initialisierung der

standardisierten Testseite in Millisekunden gemessen.

HTTP Response Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des initialen HTTP Requests (GET HTTP) bis zum Eintreffen der ersten TCP Packet der HTTP Response (TCP Packet) vergeht (siehe grüner Pfeil in Abbildung 27).

kyago


50 von 90

Abbildung 27: Messung der HTTP Response Time zur standardisierten Testseite

HTTP Session Duration (Kepler)

Mit diesem Messwert wird der vollständige Download der

standardisierten Testseite in Sekunden gemessen.

HTTP Session Duration ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des initialen HTTP Requests (GET HTTP) bis zum Eintreffen der letzten HTTP Response (HTTP 200 OK) vergeht (siehe

grüner Pfeil in Abbildung 28).

kyago


51 von 90

Abbildung 28: Messung der HTTP Session Duration zur standardisierten Testseite

HTTP Download Failure Ratio (Kepler)

Ist der HTTP Download der standardisierten Testseite fehlerhaft oder überschreitet die HTTP Response Time 2 Sekunden, so wird der HTTP

Download als nicht erfolgreich gewertet.



kyago


52 von 90

Website Response Time (Top 5 in 6 categories)

Mit diesem Messwert wird die Antwortzeit einer HTTP Initialisierung in

Millisekunden gemessen.

Website Response Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des initialen HTTP Requests (GET HTTP) bis zum Eintreffen der kompletten HTTP Response vergeht (siehe grüner Pfeil in Abbildung 29).

Abbildung 29: Messung der Website Response Time

Website DOM Duration (Top 5 in 6 categories)

Mit diesem Messwert wird der Download und die Verarbeitung aller synchronen Elemente zur Erstellung der Seitenstruktur (HTML, CSS,

JavaScript) in Sekunden gemessen.

Website DOM Duration ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des Webseitenaufrufs im Browser bis zum erhalten und verarbeiten aller Elemente vergeht, die zur Erstellung des Dokumentenobjekts benötigt werden. Der Triggerpunkt ist erreicht, wenn das nach W3C definierte Element „current document readiness“ den

Zustand „complete“ annimmt.

kyago


53 von 90

Abbildung 30: Messung der Website DOM Duration

Website Load Duration (Top 5 in 6 categories)

Mit diesem Messwert wird der Download und die Verarbeitung aller

Elemente in Sekunden gemessen.

Website Load Duration ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des Webseitenaufrufs im Browser bis zum erhalten und verarbeiten aller Elemente vergeht. Hierunter fallen neben den synchronen Elementen der „ready for Presentation Time“ auch alle nachgeladenen Elemente unter anderem asynchrone JavaScripte, Bilder oder Medien. Weiterführende Kommunikationen beispielsweise einer Client/Server Kommunikation durch JavaScripte werden hier nicht berücksichtigt. Der Triggerpunkt ist erreicht, wenn das nach W3C definierte „load event“ erreicht wurde.

kyago


54 von 90

Abbildung 31: Messung der Website Load Duration

Website Session Duration (Top 5 in 6 categories)

Mit diesem Messwert wird der vollständige Download und deren Interaktion mit ihren Gegenstellen (z.B. JavaScript) in Sekunden gemessen.

Website Session Duration ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des Webseitenaufrufs im Browser bis zum Empfang aller HTTP Responses vergeht. Hierin enthalten sind weitere Elemente aus dem Bereich CSS, JavaScript und Medien, mit deren zusätzlichen Client/Server Interaktionen, sowie Elemente von weiteren Webservern und Content Delivery Networks (siehe grüner Pfeil in Abbildung 32).

kyago


55 von 90

Abbildung 32: Messung der Website Session Duration

Website Download Failure Ratio (Top 5 in 6 categories)

Ist der HTTP Download einer Website fehlerhaft oder überschreitet die Website Response Time 1 Sekunde, so wird der HTTP Download als nicht erfolgreich gewertet.

kyago


56 von 90



PING Average Time (Gaming Server)

Eine PING Messung besteht im Kontext dieses Dokumentes aus 10 hintereinander im Abstand von jeweils einer Sekunde ausgeführten ICMP Echo Requests mit einem Timeout von 1 Sekunde für jeden ICMP Echo

Request.

Der Messwert PING Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden eines ICMP Echo Request bis zum Eintreffen

des ICMP Echo Reply vergeht (siehe grüner Pfeil in Abbildung 33).

Mit dem Wert PING Average Time wird die mittlere Antwortzeit aller

PING Times einer PING Messung in Millisekunden dargestellt.

Abbildung 33: Messung der PING Time

PING Packets Missing (Gaming Server)

Der Messwert PING Packets Missing gibt das Verhältnis von nicht empfangenen ICMP Echo Replys zu den insgesamt initiierten ICMP Echo Requests in Prozent an. Ein ICMP Echo Reply gilt als nicht empfangen, wenn er nicht innerhalb des Timeouts von 1 Sekunde auf ein ICMP Echo

Request eintrifft.









kyago


57 von 90

PING Packet Errors (Gaming Server)

Der Messwert PING Packet Errors gibt das Verhältnis von fehlerbehafteten ICMP Echo Replys zu den insgesamt erhaltenen ICMP

Echo Replys in Prozent an.

PING Failure Ratio (Gaming Server)

Das Verhältnis von nicht erfolgreich durchgeführten Ping Messungen zu insgesamt initiierten PING Messungen stellt die PING Failure Ratio in Prozent dar. Eine PING Messunge gilt als nicht erfolgreich, wenn ICMP Echo Replys fehlen, fehlerbehaftet sind (z.B. das Ziel antwortet nicht mit dem gleichen Wert in der "Sequence Number) oder die mittlere

Antwortzeit (PING Average Time) 1 Sekunde überschreitet.




kyago


58 von 90

8 Cloud Storages

Nutzer von Cloud Storage Services erwarten, dass sie jederzeit und von jedem Endgerät Zugang zu Ihren eigenen oder mit Ihnen geteilten Daten haben. Hierfür bieten Cloud Storage Provider neben einer installierbaren Synchronisierungsapplikation auch Weboberflächen an, um einen

geräteunabhängigen Zugriff zu ermöglichen.

Mit der Benchmarking Plattform werden auf Applikationslayer Down- und Upload Messungen (Firefox mit Plug-in) zu den in Tabelle 10 aufgelisteten Cloud Storage Providern durchgeführt.

Zur Ermittlung der Qualitätskennwerte wird ein Firefox Webbrowser, mit entsprechenden Plug-Ins zur Betrachtung aller wesentlichen Bestandteile der zu testenden Webseite, verwendet. Firefox wird aktuell mit über 35% Marktanteil in Deutschland am häufigsten verwendet (Quelle: statista –

Marktanteil der führenden Browserfamilien - Stand November 2015).

Tabelle 10: Übersicht Cloud Storage Provider

Die Analysen von Datei Down- und Uploads werden als Over-the-Top Messung durchgeführt. Hierbei entstehen keine Beschränkungen bezüglich der vom System bzw. Browser verwendeten Protokolle wie IPv4/v6, HTML 1.x/HTML 2.0 oder der Einsatz von SSL/TLS. Zur Ermittlung der Messwerte werden wesentliche Teile der nach W3C

„Navigation Timing“ standardisierten Triggerpunkte verwendet.

Tabelle 11: Übersicht Qualitätskennwerte der Cloud Storage Messungen

kyago


59 von 90

DNS Lookup Time

Mit diesem Messwert wird die Auflösungszeit von Hostnamen in IP-

Adressen in Millisekunden gemessen.

DNS Lookup Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden eines DNS Requests (DNS query) zum IAD bis zum Eintreffen der aufgelösten IP-Adresse (DNS query response) vergeht (siehe grüner Pfeil in Abbildung 34). Falls für den angeforderten Hostnamen weitere CNames (sogenannte Aliase) registriert wurden, wird pro CName eine weitere DNS Anfrage versendet. Für die Messung wird

aber nur die erste DNS Antwort ausgewertet.

Abbildung 34: Messung der DNS Lookup Time

DNS Lookup Failure Ratio

Ist ein DNS Request fehlerhaft oder überschreitet die DNS Lookup Time

1 Sekunde, so wird der DNS Request als nicht erfolgreich gewertet.

Das Verhältnis von nicht erfolgreich durchgeführten DNS Requests zu insgesamt initiierten DNS Requests stellt die DNS Lookup Failure Ratio in

Prozent dar.

HTTP Download Response Time (Cloud Storage)

Mit diesem Messwert wird die Antwortzeit einer HTTP Initialisierung in Millisekunden zu den in Tabelle 10 genannten Cloud Storage Providern

gemessen.

kyago


60 von 90

HTTP Download Response Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des initialen Download HTTP Requests (GET HTTP) bis zum Eintreffen der vollständigen HTTP Response vergeht (siehe grüner Pfeil in Abbildung 35).

Hierin enthalten sind Server-Bearbeitungszeiten für den Zugriff auf ein

Element und die eventuelle Überprüfung von Berechtigungen.

Abbildung 35: Messung der HTTP Download Response Time (Cloud Storage)

HTTP Download Throughput (Cloud Storage)

Um ein realitätsnahes Nutzungsszenario abzubilden, wird das von den Cloud Storage Anbietern eingesetzte HTTP(S) Protokoll genutzt. Die

Kommunikation mit den Anbietern erfolgt über einen Webbrowser.

Von den Cloud Storages werden definierte Referenzdateien abgerufen, die in ihrer Größe an den tariflich vereinbarten Durchsatz des zu testenden Anschlusses angepasst ist. Dies bedeutet im Kontext dieses Dokumentes, dass sichergestellt ist, dass bei idealer Ausnutzung der vertraglich vereinbarten Datenübertragungsrate der Anschluss

mindestens 10 Sekunden lang im Download genutzt wird.

Bis max. Bandbreite Referenzdatei

2 - 2,3 Mbit/s 2.500.000 – 2.875.000 bytes

10 Mbit/s 12.500.000 bytes

16 – 16,2 Mbit/s 20.000.000 – 20.250.000 bytes

Die Datenübertragung endet mit der vollständigen Übermittlung der

Referenzdatei.

kyago


61 von 90

Der HTTP Download Throughput ergibt sich aus der Größe der Referenzdatei und der für die Übertragung benötigten Dauer und wird als

Download-Datenübertragungsrate in Mbit/s wiedergegeben.

Abbildung 36: Messung des HTTP Download Throughput (Cloud Storage)

HTTP Download Failure Ratio (Cloud Storage)

Wird die Referenzdatei nicht innerhalb von 30 Sekunden vollständig vom

Cloud Storage an die Messeinheit übertragen oder überschreitet die

Download Response Time 2 Sekunden, so wird der HTTP Download als

nicht erfolgreich gewertet.

Die HTTP Download Failure Ratio gibt das Verhältnis von nicht erfolgreich

durchgeführten HTTP Downloads zu den insgesamt initiierten HTTP


HTTP Upload Response Time (Cloud Storage)

Mit diesem Messwert wird die Antwortzeit einer HTTP Initialisierung in Millisekunden zu den in Tabelle 10 genannten Cloud Storage Providern

gemessen.

HTTP Upload Response Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des initialen Upload HTTP Requests (POST HTTP, PUT HTTP) bis zum Eintreffen der vollständigen HTTP

Response vergeht (siehe grüner Pfeil in Abbildung 37).

Hierin enthalten sind Server-Bearbeitungszeiten für den Zugriff auf ein

Element und die eventuelle Überprüfung von Berechtigungen.

kyago


62 von 90

Abbildung 37: Messung der HTTP Upload Response Time (Cloud Storage)

HTTP Upload Throughput (Cloud Storage)

Um ein realitätsnahes Nutzungsszenario abzubilden, wird das von den Cloud Storage Anbietern eingesetzte HTTP(S) Protokoll eingesetzt. Die

Kommunikation mit den Anbietern erfolgt über einen Webbrowser.

Zu den Cloud Storages werden definierte Referenzdateien übertragen, die in ihrer Größe an den tariflich vereinbarten Durchsatz des zu testenden Anschlusses angepasst ist. Dies bedeutet im Kontext dieses Dokumentes, dass sichergestellt ist, dass bei idealer Ausnutzung der vertraglich vereinbarten Datenübertragungsrate der Anschluss

mindestens 10 Sekunden lang im Upload genutzt wird.

Bis max Bandbreite Referenzdatei

0,8 - 1,1 Mbit/s 1.000.000 – 1.280.000 bytes

2 – 2,3 Mbit/s 2.500.000 – 2.875.000 bytes

10 Mbit/s 12.500.000 bytes

Die Datenübertragung endet mit der vollständigen Übermittlung der

Referenzdatei.

Der HTTP Upload Throughput ergibt sich aus der Größe der Referenzdatei und der für die Übertragung benötigten Dauer und wird als

Upload-Datenübertragungsrate in Mbit/s wiedergegeben.

kyago


63 von 90

Abbildung 38: Messung des HTTP Upload Throughput (Cloud Storage)

HTTP Upload Failure Ratio (Cloud Storage)

Wird die Referenzdatei nicht innerhalb von 30 Sekunden vollständig von

der Messeinheit an den Cloud Storage übertragen oder überschreitet die

Upload Response Time 2 Sekunden, so wird der HTTP Upload als nicht

erfolgreich gewertet.

Die HTTP Upload Failure Ratio gibt das Verhältnis von nicht erfolgreich

durchgeführten HTTP Uploads zu den insgesamt initiierten HTTP Uploads

in Prozent wieder.

kyago


64 von 90

9 Video

Gesamtübersicht Qualitätskennwerte der Videomessungen

Zur Bestimmung der Video Qualität der am Markt verfügbaren Produkte

werden folgende Messwerte erhoben:

Tabelle 12: Übersicht Qualitätskennwerte der Videomessungen

kyago


65 von 90

9.1 IPTV

In der zunehmend komplexen Welt der Next Generation Video Services ist die Kenntnis um die Servicequalität ein entscheidender Faktor im Kampf um Marktanteile und Kundenzufriedenheit. Genau hier setzten die von der Forschungsgruppe Datennetze der Fachhochschule Köln und der zafaco GmbH entwickelten Qualitätsmesssysteme für IP basierte Audio-

/Video-Dienste an.

Die subjektive und objektive Qualität der Mediendaten wird aus dem aktuellen IP-Datenstrom abgeleitet (Live und non-reference Messungen) und basiert neben der Analyse der Netzparameter und der Dienstgüte (Quality of Service QoS) auch auf einer Analyse des Video Codec Layers mit Hilfe von „deep packet inspection“.

Die Bewertung der Qualität von IPTV Angeboten aus Endkundensicht erfolgt durch Messung von Netzparametern wie Delay, Jitter, Packet-Loss u.a. nach RFC3350 und RFC 3357. Zu der Bewertung werden auch Video-Qualitätsparameter nach ETSI TR 101 290 und Broadband Forum TR-126 sowie MQS-Werte (Media Quality Score) für die Video- und Audio-Signale der übertragenen Streams unter Verwendung der Set-Top-Box und der dazugehörigen Fernbedienung berücksichtigt. Fast-Zapping und Error-Correction Mechanismen nach RFC 5109 oder der Ericsson Mediaroom Platform (vormals Microsoft) fließen in die

Qualitätsbewertung ebenso ein.

IPTV STB Startup Response Time

Mit diesem Messwert wird die Zeit in Millisekunden gemessen, die für die erste Kommunikation zwischen Set Top Box (STB) und IPTV Headend benötigt wird.

IPTV STB Startup Response Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Senden des ersten Paketes der STB bis zum

Empfangen des ersten Paketes des IPTV Headend vergangen ist.

IPTV STB Startup Time

Mit diesem Messwert wird die Zeit in Sekunden gemessen, die eine Set-

Top-Box für das Starten aus dem Standby-Betrieb benötigt.

IPTV STB Startup Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des Infrarot-Codes für das Einschaltsignal an die Set-Top-Box bis zum Eintreffen des ersten Vollbildes des ersten

Kanals. (siehe grüner Pfeil in Abbildung 39).

kyago


66 von 90

Abbildung 39: Messung der IPTV STB Startup Time

IPTV STB Startup Failure Ratio

Wenn während des Tests die in Abbildung 39 definierten Triggerpunkte nicht erkannt werden, wird der STB Startup als nicht erfolgreich gewertet.

Das Verhältnis von nicht erfolgreich durchgeführten Starts der STB zu insgesamt initiierten Starts der STB stellt die STB Failure Ratio in

Prozent dar.

IPTV Zapping Response Time

Mit diesem Messwert wird die Zeit in Millisekunden gemessen, die für die erste Kommunikation zwischen Set Top Box (STB) und IPTV Headend

während eines Kanalwechsels benötigt wird.

IPTV STB Zapping Response Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Senden des ersten Paketes der STB bis zum Empfangen des ersten Paketes des IPTV Headend während eines

Kanalwechsels vergangen ist.

kyago


67 von 90

IPTV Zapping Time

Mit diesem Messwert wird die Zeit in Millisekunden gemessen, die für

einen Kanalwechsel benötigt wird.

IPTV Zapping Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des Infrarot-Codes für einen Kanalwechsel an die Set-Top-Box bis zum Empfang des ersten Vollbildes des angeforderten Kanals vergeht (siehe grüner Pfeil in Abbildung 40).

Abbildung 40: Messung der IPTV Zapping Time

IPTV Zapping Failure Ratio

Wenn während des Tests die in Abbildung 40 definierten Triggerpunkte nicht erkannt werden, wird der Kanalwechsel als nicht erfolgreich

gewertet.

kyago


68 von 90

Das Verhältnis von nicht erfolgreich durchgeführten Kanalwechseln zu insgesamt initiierten Kanalwechseln stellt die Zapping Failure Ratio in

Prozent dar.

IPTV Bitrate Video/Other/Total

Die IPTV Bitrate in Mbit/s ist nach Bitrate für Video, Other und Total aufgeteilt. Die Bitrate Video gibt die durchschnittliche Bitrate des MPEG-TS Video Streams ohne den MPEG-TS Header an. Bitrate Other beinhaltet alle MPEG-TS Audio und Data Streams und gibt die mittlere Bitrate der MPEG-TS Streams ohne die MPET-TS Header an. Bitrate Total ist die durchschnittliche Bitrate des gesamten Video Streams

inklusive aller Protokolle und deren Overheads.

IPTV Packet Loss

Der IPTV Packet Loss definiert die Anzahl der verloren gegangenen IPTV Pakete eines IPTV Streams in Prozent. Dabei werden Korrekturmechanismen berücksichtigt und nur die Pakete ausgewiesen,

die tatsächlich verloren gegangen sind.

IPTV Continuity Error Video/Audio

Der IPTV Continuity Error wird aus dem Continuity Counter des MPEG-TS

Header errechnet und pro detektierten Stream festgehalten.

IPTV I-/P-/B-Slices

Die Anzahl der IPTV I-/P-/B-Slices werden aus dem H.264 Video-Stream

erfasst und in Ihrer prozentualen Häufigkeit dargestellt.

IPTV Video Quality Score

Bei dem IPTV Video Quality Score werden von der Messeinheit IPTV Streams erkannt und die jeweiligen IP Pakete einem Stream zugeordnet. Eine Messung dauert 60 Sekunden und wird in Intervalle a 10 Sekunden zerlegt. Anschließend werden die zerlegten Streams in einem NR-Verfahren analysiert. Hierbei werden sowohl die Empfehlungen nach TR 101 290 als auch die nach TR-126 berücksichtigt.

Zur Ermittlung des Video Quality Score werden die verschiedenen während der Messung ermittelten Parameter in die Gruppen „Network-QoS“, „Video-QoS“ und „relativer und absoluter MQS“ unterteilt. Auf Basis dieser Gruppen wird ein Faktor bestimmt, der durch Mapping auf eine durch eine Wissensdatenbank gespeiste MQS-Scala einen Video Quality

Score mit einem Wertebereich von 1 bis 5 ergibt (siehe Abbildung 41).

kyago


69 von 90

Abbildung 41: Messung der Video Qualität

kyago


70 von 90

9.2 WebTV

Der weltweite Video Traffic wird 2018 bis zu 79% des Endkunden Traffic ausmachen. Über die Hälfe hiervon wird durch Video on Demand Anbieter (VoD) wie YouTube, maxdome, Amazon Prime Instant Video oder Netflix verursacht (Quelle: Cisco Visual Network Index, 06.2014).

Internet Service Provider stellt dies vor eine große Herausforderung, wollen sie ihren Kunden eine exzellente Service Qualität bieten. Sie müssen hierfür nicht nur die Dienstqualität in ihrem eigenen Netz sicherstellen, sondern auch ein besonderes Augenmerk auf die Zuführung des Video Contents über diverse Peerings und Content

Delivery Networks (CDN) sicherstellen.

Der WebTV Test führt Messung im Over-the-Top Ansatz zu den in Tabelle 13 aufgelisteten Video Content Provider durch. Für den Abruf eines Videos kommt bevorzugt ein Firefox Webbrowser, mit entsprechenden Plug-Ins zur Betrachtung aller wesentlichen Bestandteile des zu testenden Videos, zum Einsatz. Einzelne VoD Plattformen setzten DRM Verfahren eine die nicht von Firefox unterstützt werden. In diesem Fall wird ein Google Chrome Webbrowser eingesetzt.

Die Messung werden wenn möglich mittels adaptive Streaming durchgeführt. Je nach VoD Anbieter werden unterschiedliche Streaming Ansätze mittels HTML5 MPEG DASH oder Silverlight angeboten. Hierbei kommt typischerweise der MP4 Video Container mit einer H.264

Codierung und einem MP3, AAC oder OGG Audio Codec zum Einsatz.

Die Qualitätsanalyse findet nach dem Perceptual Evaluation of Streaming Video Quality (PEVQ-S) Verfahren der OPTICOM statt. Dieses beruht auf

dem nach ITU-R Rec. J.247 standardisiertem PEVQ Algorithmus.

Tabelle 13: Übersicht Qualitätskennwerte der WebTV Messungen

kyago


71 von 90

WebTV Video Response Time

Mit diesem Messwert wird die Antwortzeit einer HTTP Initialisierung des

Video-Elementes in Millisekunden gemessen.

WebTV Video Response Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des initialen HTTP Requests (GET HTTP) des Video-Elementes bis zum Eintreffen des ersten HTTP Response Paketes (TCP Packet) vergeht (siehe grüner Pfeil in Abbildung 42).

Abbildung 42: Messung der WebTV Video Response Duration

WebTV Initial Buffering Time

Dieser Messwert gibt die Zeit in Sekunden an, die zwischen dem initialen Buffering Signal des Videoplayers bis zum Starten der Videowiedergabe

vergeht.

Der Video Player startet ohne Nutzerinteraktion nach dem Erreichen eines für ihn definierten Video-Buffer Schwellwertes. Dieser Schwellwert wird i.d.R. durch den Player oder den VoD Anbieter festgelegt. Der Status des Video Players wir entweder direkt durch geeignete

kyago


72 von 90

Schnittstellen ermittelt oder durch ein Video Player Model des PEVQ-S

simuliert.

WebTV Rebuffering Events

Der Messwert WebTV Rebuffering Events gibt die Anzahl der Standbild

Events in einem Video wieder.

Ein Rebuffering Event wird mithilfe der Video Player Schnittstelle ermittelt. Bei fehlender Schnittstelle wird das PEVQ-S Player Model verwendet. Hierbei wird nach Erreichen der Initial Buffering Time die Präsentation gestartet. Fehlen im Verlauf der Präsentationszeit Videoinformationen so wird die Präsentation gestoppt und auf die

benötigten Daten gewartet. Dies stellt ein Rebuffering Event dar.

WebTV Rebuffering Time

Der Messwert WebTV Rebuffering Time gibt die Standbilddauer aller

Standbild Events einer Übertagung in Millisekunden wieder.

WebTV Video Sequence Duration

Die Video Sequence Duration beschreibt die Länge des Videoausschnittes in Sekunden, welcher bei der Analyse der Video Qualität berücksichtigt wurde. Bei einer vollständigen Videoübertragung

entspricht dieser Wert der gesamten Video Länge.

WebTV Playback Sequence Duration

Die Abspieldauer eines Videos innerhalb des Videoplayers wird in der Playback Sequence Duration angegeben. Diese weicht im Falle von Rebuffering Events innerhalb des Videos von der Video Sequence

Duration ab.

WebTV Video Bitrate Meta

Dieser Wert gibt die mittlere Bitrate in Mbit/s des zu diesem

Betrachtungsintervall gehörenden Videostreams an.

WebTV MOS

PEVQ-S besteht aus einem Full Reference (FR) Teil, welcher das abgerufene Video mit einem Referenzvideo vergleicht. Die durch die HTTP Adaptive Bitrate (ABR) entstehenden Qualitätsänderungen werden hiermit berücksichtigt. Des Weiteren werden die dynamischen Qualitätsaspekte wie die Übertragungs- und Präsentationsqualität ermittelt, hierzu zählt u.a. die Initial Buffering Time und die Rebuffering Informationen. Aus den ermittelten Eigenschaften wird ein Quality of Experience (QoE)

kyago


73 von 90

Wert als Mean Opinion Score (MOS) der zwischen 1 (schlecht) und 5

(sehr gut) liegt abgeleitet.

Abbildung 43: PEVQ-S Block Diagramm: OTT Netz (oben), PEVQ-S Bausteine (Mitte) und

PEVQ-S Ergebnisse (unten) / (Quelle: Whitepaper OPTICOM GmbH]

Der Algorithmus ermittelt in Intervallen von 8 Sekunden einen MOS. Der Mittelwert aller MOS Ergebnis stellt den endgültigen MOS einer Messung

dar.

kyago


74 von 90

Abbildung 44: Messung des WebTV Video Quality & Video Performance Indicators

WebTV MOS BQA

Zu jedem Betrachtungsintervall wird eine bestmögliche Videoqualität bestimmt (siehe Abbildung 43 linker Block). Diese ermittelt sich entweder aus dem Quell-Video vor dem Upload in ein VoD System und einem einhergehenden Transcoding in die unterschiedlichen Qualitätsstufen oder es wird das Video in der beste Qualitätsstufe vom

VoD System betrachtet.

WebTV MOS Degradation

Der Wert MOS Degradation zeigt die Differenz zwischen dem Erreichten und dem für dieses Video bestmöglichen MOS Wert an.

kyago


75 von 90

WebTV Failure Ratio

Ist der Videoabruf fehlerhaft oder überschreitet die Video Response Time 1 Sekunde, die Initial Buffering Time 5 Sekunden oder die Rebuffering Time 3 Sekunden, so wird der WebTV Dienst als nicht erfolgreich gewertet.

Das Verhältnis von nicht erfolgreich durchgeführten Video Downloads zu insgesamt initiierten Video Downloads stellt die WebTV Failure Ratio in

Prozent dar.

kyago


76 von 90

10 Reporting

Kunden der Multi Play- und Benchmarking Plattform erhalten einen SSL-gesicherten Zugang zu unserer Business Intelligence Plattform. Zusätzlich bieten wir auch eine Kommunikationsschnittstelle an, über die wir unseren Kunden die Rohdaten der Messergebnisse in Ihre

Systemlandschaften übertragen.

Mit unserem Reporting sind sowohl der Zugriff auf Daten als auch die intuitive Informationsanalyse in einem Produkt verfügbar – damit unsere Kunden die gewonnenen Erkenntnisse auch tatsächlich in effektive Geschäftsentscheidungen einbringen können. Wenige Mausklicks genügen, um die abgerufenen Daten zu analysieren: Die zugrundeliegenden Trends und Ursachen werden sofort ersichtlich (siehe

Abbildung 45 - 52).

Über die einfach zu bedienende Benutzeroberfläche können zum Beispiel Reports im PDF- oder Excel-Format heruntergeladen und anschließend

mit Standard-Tools weiterbearbeitet werden.

kyago


77 von 90

Abbildung 45: Tabellarischer Consumer Benchmarking Voice Report

Abbildung 46: Grafischer Consumer Benchmarking Voice Report

kyago


78 von 90

Abbildung 47: Tabellarischer Consumer Benchmarking Data Report

kyago


79 von 90

Abbildung 48: Grafischer Consumer Benchmarking Data Report

kyago


80 von 90

Abbildung 49: Grafischer Consumer Benchmarking Cloud Services Report

kyago


81 von 90

Abbildung 50: Grafischer Business Benchmarking Voice Report

kyago


82 von 90

Abbildung 51: Grafischer Business Benchmarking Cloud Storage Report

kyago


83 von 90

Abbildung 52: Grafischer WebTV Benchmarking Report

kyago


84 von 90

11 Monitoring und Alarm-Interface

Für Kunden der Multi Play- und Benchmarking Plattform bieten wir als Option einen SSL-gesicherten Zugang zu unserer Monitoring Plattform an. Diese wird durch eine Kommunikation via E-Mail für die Weiterleitung von Alarmen ergänzt (siehe Abbildung 53-54). Folgende Zustände der Multi Play- und Benchmarking Plattform werden überwacht und im Fehlerfall zeitnah per E-Mail übermittelt:

- Erreichbarkeit der Mess-Systeme

- Fehlerrate eines Anschlusses, getrennt für Voice und Daten-Messungen

Abbildung 53: Monitoring Plattform

kyago


85 von 90

Abbildung 54: Alarmierung via E-Mail

kyago


86 von 90

12 Glossar

a/b a/b-Schnittstelle -

Schnittstelle zum Anschluss von analogen Endgeräten

ACK Acknowledgement -

Bestätigung einer Protokollnachricht (z.B. im DSS1- oder

TCP-Protokoll)

CDN Content Delivery Network. -

Ein Content Delivery Network (CDN), oder auch Content

Distribution Network genannt, ist ein Netz lokal verteilter und

über das Internet verbundener Server, mit dem Inhalte –

insbesondere große Mediendateien – ausgeliefert werden

DIN Deutsche Institut für Normung e. V. -

Nationale Normungsorganisation in der Bundesrepublik

Deutschland

DNS Domain Name System -

Hierarchischer Verzeichnisdienst im Internet zur Verwaltung

des Namensraums, d.h. zur Beantwortung von Anfragen zur

Namensauflösung in IP-Adressen

DSL Digital Subscriber Line -

Digitale Breitband-Verbindung für Teilnehmeranschlüsse über

einfache Kupferleitungen des herkömmlichen Telefonnetzes

DSS1 Digital Subscriber Signalling System No. 1 -

Digitales Signalisierungsprotokoll für ISDN, das in einem

Nebenkanal (D-Kanal) übertragen wird (out-of-band signalling)

E-Com. Electronic Commerce -

elektronischer Handel, d.h. vollständig elektronische

Abwicklung der Unternehmensaktivitäten in einem Netz

EPG Electronic Program Guide -

elektronischer Programmführer für das aktuelle Hörfunk-

und Fernsehprogramm

ETSI European Telecommunications Standards Institute -

Gemeinnütziges Institut zur Schaffung von europaweit

einheitlichen Standards im Telekommunikationsbereich

kyago


87 von 90

GPRS General Packet Radio Service -

Paketorientierter Dienst zur Datenübertragung in GSM- und

UMTS-Netzen

GSM Global System for Mobile Communications -

Digitaler Mobilfunkstandard der zweiten Generation als

Nachfolger der analogen Systeme der ersten Generation

HTTP Hypertext Transfer Protocol -

Protokoll der ISO/OSI-Anwendungsschicht zur Übertragung

von Daten über IP-Netze (wird hauptsächlich verwendet, um

Webseiten aus dem World Wide Web (www) zu laden)

IAD Integrated Access Device -

Endgerät, das dem Endkunden in der einfachsten

Ausführung Telefonieschnittstellen und Internetzugriff zur

Verfügung stellt

ICMP Internet Control Message Protocol -

Protokoll zum Austausch von Informations- und

Fehlermeldungen über das Internet-Protokoll

IP Internet Protocol -

Protokoll der ISO/OSI-Vermittlungsschicht zum Austausch

von Daten über Rechnernetze

IPTV Internet Protocol Television -

Gattungsbegriff für audiovisuelle Dienste wie z.B. Fernsehen

und Video, die über IP-basierte Netze übertragen werden

ISDN Integrated Services Digital Network -

Digitaler Festnetzstandard für ein dienstintegrierendes

Telekommunikationsnetz

ITK Informations- und Kommunikationstechnologie -

Sammelbegriff für Technologien im Bereich der Information

und Kommunikation

ITU-T International Telecommunication Union (Telecommunication

Standardization Sector) -

Sonderorganisation der Vereinten Nationen, die sich offiziell

und weltweit mit technischen Aspekten der Telekommunika-

tion beschäftigt

kyago


88 von 90

LAN Local Area Network -

Ein in seiner Ausdehnung begrenztes und somit lokales

Rechnernetz

LTE Long Term Evolution -

Ist eine Bezeichnung für den Mobilfunkstandard der vierten

Generation (4G)

MOS Mean Opinion Score -

Subjektiv wahrgenommene Qualität von Sprache oder

Bildern, abgebildet auf einen Wertebereich von 1

(mangelhaft) bis 5 (ausgezeichnet)

NTBA Network Termination for ISDN Basic rate Access -

Beim Teilnehmer installiertes Netzabschlussgerät für einen

ISDN-Basisanschluss

PEVQ-S Perceptual Evaluation of Streaming Video Quality -

Teststandard zur automatisierten Beurteilung der Streaming

Videoqualität von Übertragungssystemen

PDF Portable Document Format -

Plattformunabhängiges von Adobe Systems entwickeltes

Dateiformat für Dokumente

POLQA Perceptual Objective Listening Quality Analysis -

Teststandard zur automatisierten Beurteilung der Sprach-

qualität von Übertragungssystemen

PING Kein Acronym -

Computerprogramm zur Überprüfung der Erreichbarkeit

eines Hosts in einem IP-Netz

QoE Quality of Experience -

Subjektive Zufriedenheit (Erlebnisqualität) der Nutzer mit der

von ihnen genutzten Anwendung

S0 ISDN Basisanschluss -

Schnittstelle im ISDN zum Anschluss von ISDN-Endgeräten

S2M ISDN Primärmultiplexanschluss -

Schnittstelle im ISDN im Wesentlichen zum Anschluss von

ISDN-Telefonanlagen

kyago


89 von 90

SIM Subscriber Identity Module -

Chipkarte in einem Mobiltelefon zur Identifikation des Nutzers

im GSM- oder UMTS-Netz

SIP Session Initiation Protocol -

Protokoll der ISO/OSI-Anwendungsschicht zum Aufbau und

Steuerung einer Kommunikationssitzung (wird u.a. in der IP-

Telefonie verwendet)

SLA Service Level Agreement -

Vereinbarung über die Dienstgüte eines Dienstleistungs-

vertrages

SSL Secure Sockets Layer -

Hybrides Verschlüsselungsprotokoll der ISO/OSI-Trans-

portschicht zur sicheren Datenübertragung im Internet

SYN Synchronize -

TCP-Nachricht zum Aufbau einer TCP-Verbindung im

Rahmen des TCP- Handshake

TCP Transmission Control Protocol -

Verbindungsorientiertes, paketvermittelndes Protokoll der

ISO/OSI-Transportschicht zur Übertragungssteuerung von

Daten

TLS Transport Layer Security -

Weitläufiger bekannt unter der Vorgängerbezeichnung

Secure Sockets Layer (SSL). Ist ein hybrides

Verschlüsselungsprotokoll zur sicheren Datenübertragung im

Internet. Seit Version 3.0 wird das SSL-Protokoll unter dem

neuen Namen TLS weiterentwickelt und standardisiert,

wobei Version 1.0 von TLS der Version 3.1 von SSL

entspricht

TÜV Technischer Überwachungs-Verein -

Eingetragene Vereine, die technische Sicherheitskontrollen,

insbesondere auch solche, die durch staatliche Gesetze oder

Anordnungen vorgeschrieben sind, auf privatwirtschaftlicher

Basis durchführen

https://de.wikipedia.org/wiki/Hybride_Verschl%C3%BCsselung

https://de.wikipedia.org/wiki/Verschl%C3%BCsselungsprotokoll

https://de.wikipedia.org/wiki/Daten%C3%BCbertragung

https://de.wikipedia.org/wiki/Internet

kyago


90 von 90

UMTS Universal Mobile Telecommunications System -

Digitaler Mobilfunkstandard der dritten Generation, mit dem

deutlich höhere Datenübertragungsraten als mit dem der

zweiten Generation möglich sind

URL Uniform Resource Locator -

Identifikator einer Ressource (Host) und des verwendeten

Netzprotokolls in Computernetzen, über das die Ressource

lokalisiert werden kann (wird häufig als Synonym für

Internetadresse verwendet)

VoD Video on Demand -

Video-on-Demand (Video auf Anforderung) bzw. Abrufvideo

beschreibt die Möglichkeit, digitales Videomaterial auf

Anfrage von einem Anbieter herunterzuladen (Download)

oder über einen Video-Stream direkt mit einer geeigneten

Software anzusehen

VoIP Voice over IP -

Sprachübertragung über IP-basierte Datennetze

W3C World Wide Web Consortium -

Das World Wide Web Consortium (kurz W3C) ist das

Gremium zur Standardisierung der Techniken im World

Wide Web.

WebTV Web Television -

Mit Internetfernsehen (Internet-TV bzw. Web-TV genannt)

wird die Übertragung von Fernsehprogrammen über das

Internet bezeichnet

WAN Wide Area Network -

Ein sich über einen sehr großen geografischen Bereich

ausdehnendes Rechnernetz

Documents

kyago Whitepaper - zafaco · Schnittstellen inklusive SIP-Trunking. In Abhängigkeit der Messkampagne (Consumer, Business, Video etc.) kommt ein Mix der oben genannten Anschlusstechnologien