kyago whitepaper v 7.41 de · whitepaper version 7.41 12 von 88 somit können daten erhoben werden,...
TRANSCRIPT
kyago Whitepaper
Die Multi Play und Benchmarking
Plattform
Ismaning, 07.06.2020 Version 7.41
© zafaco GmbH Vervielfältigung und Nachdruck – auch auszugsweise – nur nach vorheriger schriftlicher Genehmigung.
kyago Benchmarking
Whitepaper Version 7.41
2 von 88
Inhalt
1. Management Summary ........................................................... 7
Kontinuierlicher Benchmark ..................................................... 7
Kundensicht im Fokus ............................................................. 7
Realitätsnahe Simulation ......................................................... 8
Time to Market ...................................................................... 8
Eckdaten des Benchmarks ....................................................... 8
Prinzipien aus der Benchmarking-Praxis ..................................... 9
Zusätzlicher Kundennutzen ...................................................... 9
2. Die Multi Play- und Benchmarking Plattform ........................ 11
Speziell zugeschnittene Hardware und Software .........................11
Verschiedene Anschlusstechnologien ........................................11
Ad-hoc-Messungen ................................................................12
Routine-Messungen ...............................................................13
3. Technische Umsetzung ......................................................... 14
4. Ende-zu-Ende Sprachqualitätsmessungen ............................ 16
Gesamtübersicht Qualitätskennwerte ........................................17
Call Setup Duration ...............................................................17
Call Setup Failure Ratio ..........................................................18
Connect Setup Duration .........................................................19
Connect Setup Failure Ratio ....................................................19
Call Drop Ratio .....................................................................20
Call Failure Ratio ...................................................................21
MOS LQO ............................................................................21
Sprachqualitätsmessung mit parallelem Up- und Download ..........23
Speech Delay .......................................................................25
Multitone Errors ....................................................................26
Multitone Failure Ratio ...........................................................27
kyago Benchmarking
Whitepaper Version 7.41
3 von 88
5. Highspeed Internet ............................................................... 28
Messserver beim Anbieter oder zafaco ......................................28
Daten-Referenz-System bei zafaco ...........................................28
Messclient ...........................................................................29
Gesamtübersicht Qualitätskennwerte ........................................29
5.1 Test Case PING ....................................................................30
PING Average Time ...............................................................30
PING Packets Missing.............................................................30
PING Packet Errors ................................................................30
PING Failure Ratio .................................................................31
5.2 Test Case Download ..............................................................31
HTTP Download Response Time ...............................................31
HTTP Download Throughput ....................................................32
HTTP Download Throughput < x % of Bandwidth ........................33
HTTP Download Failure Ratio...................................................33
Loadtest HTTP Download with parallel HTTP Upload and Voice .......34
5.3 Test Case Upload ..................................................................35
HTTP Upload Response Time ...................................................35
HTTP Upload Throughput ........................................................36
HTTP Upload Throughput < x % of Bandwidth ............................37
HTTP Upload Failure Ratio ......................................................37
Loadtest HTTP Upload with parallel HTTP Download and Voice .......37
6. Web Services ......................................................................... 39
Gesamtübersicht Qualitätskennwerte ........................................40
6.1 Test Case DNS .....................................................................41
DNS Lookup Time .................................................................41
DNS Lookup Failure Ratio .......................................................41
6.2 Test Case Gaming .................................................................42
PING Average Time (Gaming) .................................................42
PING Packets Missing (Gaming) ...............................................42
kyago Benchmarking
Whitepaper Version 7.41
4 von 88
PING Packet Errors (Gaming) ..................................................42
PING Failure Ratio (Gaming) ...................................................43
6.3 Test Case Webhosting............................................................43
DNS Lookup Time (Webhosting) ..............................................43
DNS Lookup Failure Ratio (Webhosting) ....................................44
HTTP Response Time (Webhosting) ..........................................44
HTTP Session Duration (Webhosting) ........................................44
HTTP Download Failure Ratio (Webhosting) ...............................45
6.4 Test Case Websites ...............................................................45
DNS Lookup Time (Websites) ..................................................45
DNS Lookup Failure Ratio (Websites) ........................................46
Website Response Time (Websites) ..........................................46
Website DOM Duration (Websites) ...........................................47
Website Load Duration (Websites) ...........................................48
Website Session Duration (Websites)........................................49
Website Download Failure Ratio (Websites) ...............................51
6.5 Test Case Photobook .............................................................51
HTTP Upload Duration (Photobook) ..........................................51
HTTP Upload Throughput (Photobook) ......................................51
HTTP Upload Failure Ratio (Photobook) .....................................52
7. WebTV ................................................................................... 53
Gesamtübersicht Qualitätskennwerte ........................................54
YouTube (YT) Video Response Time..........................................54
YouTube (YT) Video Response Time Failure Ratio ........................55
Video Response Time (WebTV) ................................................56
Initial Buffering Time (WebTV) ................................................57
Rebuffering Events (WebTV) ...................................................57
Rebuffering Time (WebTV) ......................................................57
Video Sequence Duration (WebTV) ...........................................57
Playback Sequence Duration (WebTV) ......................................57
kyago Benchmarking
Whitepaper Version 7.41
5 von 88
Video Bitrate Meta (WebTV) ....................................................57
MOS (WebTV) ......................................................................58
MOS Initial (WebTV) ..............................................................60
MOS Stable (WebTV) .............................................................60
MOS Degradation (WebTV) .....................................................61
Failure Ratio (WebTV) ............................................................61
8. IPTV ..................................................................................... 62
Gesamtübersicht Qualitätskennwerte ........................................63
STB Startup Response Time (IPTV) ..........................................63
STB Startup Time (IPTV) ........................................................63
STB Startup Failure Ratio (IPTV) ..............................................64
Zapping Response Time (IPTV) ................................................64
Zapping Time (IPTV) .............................................................65
Zapping Failure Ratio (IPTV) ...................................................65
Fast Zapping Response Time (IPTV) .........................................66
Fast Zapping Time (IPTV) .......................................................66
Fast Zapping Failure Ratio (IPTV) .............................................67
Number Zapping Response Time (IPTV) ....................................67
Number Zapping Time (IPTV) ..................................................67
Number Zapping Failure Ratio (IPTV)........................................68
EPG Zapping Response Time (IPTV) .........................................68
EPG Zapping Time (IPTV) .......................................................69
EPG Zapping Failure Ratio (IPTV) .............................................70
Bitrate Video/Other/Total (IPTV) ..............................................70
Packet Loss (IPTV) ................................................................70
Continuity Error Video/Audio (IPTV) .........................................70
I-/P-/B-Slices (IPTV) .............................................................70
Video Quality Score (IPTV) .....................................................70
Video MOS (IPTV) .................................................................71
kyago Benchmarking
Whitepaper Version 7.41
6 von 88
One IPTV Stream with parallel Dataload and Voice ......................73
Two IPTV Streams with parallel Dataload and Voice ....................73
9. Reporting .............................................................................. 75
10. Monitoring und Alarm-Interface ........................................... 82
11. Glossar .................................................................................. 84
12. Impressum ............................................................................ 88
kyago Benchmarking
Whitepaper Version 7.41
7 von 88
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 Glasfaser-, 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.
kyago Benchmarking
Whitepaper Version 7.41
8 von 88
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.
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 Glasfaser-, DSL-, Kabel-, Mobilfunk- und VoIP-
Anbieter im Test
• Nahezu 108 Millionen Testverbindungen pro Jahr, davon
- knapp 8 Millionen Sprachverbindungen
- mehr als 93 Millionen Daten- und Internetverbindungen
- annähernd 7 Millionen Videoverbindungen
• Analyse von über 110 Qualitätskennwerten
kyago Benchmarking
Whitepaper Version 7.41
9 von 88
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 Benchmarkings 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
kyago Benchmarking
Whitepaper Version 7.41
10 von 88
Von den Statistik-, Monitoring- und Analysedaten der Multi Play- und
Benchmarking Plattform profitieren verschiedene Abteilungen eines Kunden:
Statistik
• Management
• Planung
• Marketing
• Qualitätssicherung
Monitoring
• Qualitätsmanagement
• Netzbetrieb
Analyse
• Netzbetrieb
• Kundendienst
kyago Benchmarking
Whitepaper Version 7.41
11 von 88
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 der BEREC (BoR (17) 178), 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, J.247 und P.1204), der Internet Engineering Task
Force (IETF RFC 3350 und RFC 3357) und dem World Wide Web Consortium (W3C) definierten Empfehlungen erhoben.
Zum Aufbau von kyago, der Multi Play- und Benchmarking
Plattform, gehören 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.
Weitere Details zum Aufbau werden in den länderspezifischen Dokumenten “Informationen zum Setup“ beschrieben.
Die Multi Play- und Benchmarking Plattform wurde realisiert mit konzeptioneller Unterstützung von .
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.
kyago Benchmarking
Whitepaper Version 7.41
12 von 88
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.
Abbildung 1: Übersicht der Funktionen der Multi Play- und Benchmarking
Plattform
kyago Benchmarking
Whitepaper Version 7.41
13 von 88
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.
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.
kyago Benchmarking
Whitepaper Version 7.41
14 von 88
3. Technische 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 2: 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.
kyago Benchmarking
Whitepaper Version 7.41
15 von 88
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 3: Beispielhafter Aufbau der kyago Plattform an einem Standort
kyago Benchmarking
Whitepaper Version 7.41
16 von 88
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 UMTS/LTE Module mit den SIM-Karten der Mobilfunknetzanbieter Telefónica O2, Telekom und Vodafone.
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.
Die Ende-zu-Ende Sprachqualität wird bei jeder Verbindung mittels
HD Voice über S0 gemessen. Dabei handelt es sich um den Breitbandsprachdienst ‚7 kHz audio-coding within 64 kbit/s, basierend auf dem Codec G.722.
Falls eine Verbindung nicht über G.722 realisiert werden kann, wird diese mit der Rückfalllösung G.711 aufgebaut.
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 Benchmarking
Whitepaper Version 7.41
17 von 88
Gesamtübersicht Qualitätskennwerte
Folgende Messwerte werden im Rahmen der
Sprachqualitätsmessungen erhoben:
Abbildung 4: Ü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 5).
Bei analogen Anschlüssen wird das Post Dialling Delay verwendet
und als Call Setup Duration ausgewiesen. Zur Ermittlung des Post Dialling Delays wird die Zeit zwischen dem Ende der Wahl durch die „A“-Seite und dem Empfang des zugehörigen Klingeltons oder In-
Band-Information auf der „A“-Seite gemessen.
Bei Verbindungen zum Mobilfunk wird das Delay von 2 Sekunden bei der Verbindungsaufbauzeit (Call Setup Duration), welches von dem
Modem auf der Mobilfunkseite erzeugt wird, von der Verbindungsaufbauzeit zu Mobilfunk abgezogen.
1. 1.
2. 2.
3. 3.
4. 4.
5. 5.
6. 6.
7. 7.
8. 8.
9. 9.
10. 10.
Call Setup Failure Ratio [%] Call Setup Failure Ratio [%]
Overview of quality benchmarks for voice quality measurements
Voice pure Voice with Upload and Download
Call Setup Duration [s] Call Setup Duration [s]
Call Failure Ratio [%] Call Failure Ratio [%]
MOS LQO [1-5] MOS LQO [1-5]
Connect Setup Duration [s] Connect Setup Duration [s]
Connect Setup Failure Ratio [%] Connect Setup Failure Ratio [%]
Call Drop Ratio [%] Call Drop Ratio [%]
Speech Delay [ms] Speech Delay [ms]
Multitone Errors [%] Multitone Errors [%]
Multitone Failure Ratio [%] Multitone Failure Ratio [%]
kyago Benchmarking
Whitepaper Version 7.41
18 von 88
Abbildung 5: 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 Benchmarking
Whitepaper Version 7.41
19 von 88
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 6).
Abbildung 6: 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 Benchmarking
Whitepaper Version 7.41
20 von 88
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) 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 7).
Abbildung 7: Ermittlung der Call Drop Ratio
kyago Benchmarking
Whitepaper Version 7.41
21 von 88
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
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.
kyago Benchmarking
Whitepaper Version 7.41
22 von 88
In Abbildung 9 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.
Abbildung 9: Messung der Sprachqualität
Es werden zwei bidirektionale sequentielle Sprachübertragungen durchgeführt.
Wie in Abbildung 9 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.
kyago Benchmarking
Whitepaper Version 7.41
23 von 88
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 10). 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 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 10: 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 11 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.
kyago Benchmarking
Whitepaper Version 7.41
24 von 88
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.
Abbildung 11: Messung der Sprachqualität mit paralleler Datenlast
Das in Abbildung 11 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 Benchmarking
Whitepaper Version 7.41
25 von 88
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 12).
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 12: Messung des Speech Delays
kyago Benchmarking
Whitepaper Version 7.41
26 von 88
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 13: Messung der Übertragungsqualität von Tönen
kyago Benchmarking
Whitepaper Version 7.41
27 von 88
Wie in Abbildung 13 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
Audiodateie 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 Benchmarking
Whitepaper Version 7.41
28 von 88
5. 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.
kyago Benchmarking
Whitepaper Version 7.41
29 von 88
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.
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
Abbildung 14: Ü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.
1. 1.
2. HTTP Download Throughput [kbit/s] 2. HTTP Download Throughput [kbit/s]
3. 3.
4. 4.
1. 1.
2. 2.
3. 3.
4. 4.
1.
2. PING Packets Missing [%]
3. PING Packet Errors [%]
4.
Overview of quality benchmarks for data quality measurements
Download pure Download with parallel Upload and Voice
HTTP Download Response Time [ms] HTTP Download Response Time [ms]
PING Failure Ratio [%]
PING
HTTP Download Failure Ratio [%]
HTTP Upload Throughput < x % of Bandwidth [%] HTTP Upload Throughput < x % of Bandwidth [%]
HTTP Upload Failure Ratio [%] HTTP Upload Failure Ratio [%]
Upload pure Upload with parallel Download and Voice
HTTP Upload Response Time [ms] HTTP Upload Response Time [ms]
HTTP Upload Throughput [kbit/s] HTTP Upload Throughput [kbit/s]
HTTP Download Throughput < x % of Bandwidth [%] HTTP Download Throughput < x % of Bandwidth [%]
HTTP Download Failure Ratio [%]
PING Average Time [ms]
kyago Benchmarking
Whitepaper Version 7.41
30 von 88
5.1 Test Case PING
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.
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 15).
Mit dem Wert PING Average Time wird die mittlere Antwortzeit aller
PING Times einer PING Messung in Millisekunden dargestellt.
Abbildung 15: 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.
kyago Benchmarking
Whitepaper Version 7.41
31 von 88
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.
5.2 Test Case Download
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 TCP Paketes vergeht (siehe grüner Pfeil in Abbildung 16).
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 16: Messung der HTTP Response Time
kyago Benchmarking
Whitepaper Version 7.41
32 von 88
HTTP Download Throughput
Um eine realitätsnahe Nutzungssituation abzubilden, wird das von
Endkunden 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 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 17) wird der HTTP Download Throughput und damit die
zur Verfügung stehende Download-Datenübertragungsrate in Mbit/s berechnet.
kyago Benchmarking
Whitepaper Version 7.41
33 von 88
Abbildung 17: Messung des HTTP Download Throughputs
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.
kyago Benchmarking
Whitepaper Version 7.41
34 von 88
Loadtest HTTP Download with parallel HTTP Upload and Voice
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 18).
Abbildung 18: Messung des HTTP Download Throughputs mit parallelem HTTP
Upload und Voice
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.
kyago Benchmarking
Whitepaper Version 7.41
35 von 88
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.
5.3 Test Case Upload
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 TCP vergeht (siehe
grüner Pfeil in Abbildung 19).
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 19: Messung der HTTP Upload Response Time
kyago Benchmarking
Whitepaper Version 7.41
36 von 88
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 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 20) 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 20: Messung des HTTP Upload Throughputs
kyago Benchmarking
Whitepaper Version 7.41
37 von 88
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.
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 and Voice
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 21).
Abbildung 21: Messung des HTTP Upload Throughputs mit parallelem HTTP
Download und Voice
kyago Benchmarking
Whitepaper Version 7.41
38 von 88
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 Benchmarking
Whitepaper Version 7.41
39 von 88
6. Web Services
Auch bei hohen Besucherzahlen und zeitlich begrenzten Verkaufsaktionen erwarten Kunden eine optimale Performance. Unzufriedene Kunden entstehen durch lange Ladezeiten, stockende
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 sowohl
leistungsorientierte QoS-Messungen wie DNS Auflösungszeiten und Antwortzeiten zu Gaming Servern, als auch anwenderorientierte QoE-Messungen wie Kepler, Website Ladezeiten und
Uploadmessungen zu unterschiedlichen Fotobuch-Anbietern gemessen.
DNS als eines der meistgenutzten Internetdienste wird aus Sicht des
Anwenders meist unbemerkt angewendet. Da dieser Dienst für die Interaktion aber fundamental ist und eine Laufzeitverzögerung sich auf eine hohe Anzahl von Internetdiensten auswirkt, wird diese
Messung als eigenständiger Test durchgeführt.
Eine Vielzahl von Online-Spielen setzen eine überdurchschnittliche Laufzeitperformance voraus, um als Spieler im interaktiven
Spielgeschehen mit den Mitspielern auf Augenhöhe spielen zu können.
Bei den anwenderorientierten QoE-Messungen erfolgt ein
Webseitenabruf über einen Browser. Es werden standardisierte Testseiten (ETSI Kepler reference page) von nationalen und internationalen Webhosting-Anbietern abgerufen und auf
Transportlayer-Ebene gemessen.
Des Weiteren erfolgt eine Messung von unterschiedlichen, häufig genutzten Webseiten auf Applikationslayer-Ebene. Zur Ermittlung
der Qualitätskennwerte werden die beiden nach Marktanteilen führenden Browser in Deutschland (Firefox und Chrome) verwendet. Bei der Ermittlung der Messwerte von Webseitenaufrufen werden
wesentliche Teile der nach W3C "Navigation Timing" standardisierten Triggerpunkte verwendet.
Weiterhin werden Analysen von Uploadmessungen zu
unterschiedlichen Fotobuch-Anbietern auf Applikationslayer-Ebene durchgeführt. Fotobücher erfreuen sich immer größerer Beliebtheit.
kyago Benchmarking
Whitepaper Version 7.41
40 von 88
Neben der Qualität des Endproduktes, ist auch die Verfügbarkeit der
Onlinefotoservices ein wichtiges Kriterium der Nutzerzufriedenheit.
Im Rahmen der DNS-Messung werden zu jeder Stunde 40 DNS Requests versendet und die Antwortzeit zu diesen Anfragen
gemessen. Die DNS Anfragen werden rekursiv an den DNS Service des Home Routers (IAD/CPE/Router) gestellt, der diese Anfrage an den vom Anbieter hinterlegten DNS Server weiterleitet.
Um DNS-Caching-Mechanismen weitestgehend auszuschließen und Messungen zu den DNS Servern im Anbieternetz zu forcieren, werden jede Stunde wechselnd 40 DNS Requests aus einer Liste der
Deutschen Top 1000 Alexa Liste ausgewählt. Die Liste der Top 1000 URLs wird einmal pro Woche neu bestimmt und täglich in eine zufällige Reihenfolge sortiert.
Gesamtübersicht Qualitätskennwerte
Abbildung 22: Übersicht Qualitätskennwerte der Web Services Messungen
1. 1.
2. 2.
3. 3.
4. 4.
5. 5.
6.
7.
1. 1.
2. 2.
3. PING Packet Errors [%] 3.
4.
1.
2.
DNS Lookup Failure Ratio [%] DNS Lookup Failure Ratio [%]
Overview of quality benchmarks for web services measurements
Websites Webhosting
DNS Lookup Time [ms] DNS Lookup Time [ms]
Website Response Time [ms] HTTP Response Time [ms]
Gaming Photobook
PING Average Time [ms] HTTP Upload Duration [s]
Website Session Duration [s]
Website Download Failure Ratio [%]
Website DOM Duration [s] HTTP Session Duration [s]
Website Load Duration [ms] HTTP Download Failure Ratio [%]
DNS Lookup Failure Ratio [%]
PING Packets Missing [%] HTTP Upload Throughput [kbit/s]
HTTP UL Failure Ratio [%]
DNS
DNS Lookup Time [ms]
PING Failure Ratio [%]
kyago Benchmarking
Whitepaper Version 7.41
41 von 88
6.1 Test Case DNS
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 auf Anwendungsebene 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 23). 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 23: 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.
kyago Benchmarking
Whitepaper Version 7.41
42 von 88
6.2 Test Case Gaming
PING Average Time (Gaming)
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 24).
Mit dem Wert PING Average Time wird die mittlere Antwortzeit aller
PING Times einer PING Messung in Millisekunden dargestellt.
Abbildung 24: Messung der PING Time
PING Packets Missing (Gaming)
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 (Gaming)
Der Messwert PING Packet Errors gibt das Verhältnis von fehlerbehafteten ICMP Echo Replys zu den insgesamt erhaltenen ICMP Echo Replys in Prozent an.
kyago Benchmarking
Whitepaper Version 7.41
43 von 88
PING Failure Ratio (Gaming)
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.
6.3 Test Case Webhosting
DNS Lookup Time (Webhosting)
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 auf Anwendungsebene 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 25). 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 25: Messung der DNS Lookup Time
kyago Benchmarking
Whitepaper Version 7.41
44 von 88
DNS Lookup Failure Ratio (Webhosting)
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 (Webhosting)
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 Packets der HTTP Response (First TCP Packet) vergeht (siehe grüner Pfeil in Abbildung 26).
Abbildung 26: Messung der HTTP Response Time zur standardisierten Testseite
HTTP Session Duration (Webhosting)
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 (Final HTTP 200 OK) vergeht (siehe grüner Pfeil in Abbildung 27).
kyago Benchmarking
Whitepaper Version 7.41
45 von 88
Abbildung 27: Messung der HTTP Session Duration zur standardisierten Testseite
HTTP Download Failure Ratio (Webhosting)
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.
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.
6.4 Test Case Websites
DNS Lookup Time (Websites)
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 auf Anwendungsebene 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 28). 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 Benchmarking
Whitepaper Version 7.41
46 von 88
Abbildung 28: Messung der DNS Lookup Time
DNS Lookup Failure Ratio (Websites)
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.
Website Response Time (Websites)
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).
kyago Benchmarking
Whitepaper Version 7.41
47 von 88
Abbildung 29: Messung der Website Response Time
Website DOM Duration (Websites)
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 auf Anwendungsebene vom Initiieren 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 (siehe grüner Pfeil in Abbildung 30).
kyago Benchmarking
Whitepaper Version 7.41
48 von 88
Abbildung 30: Messung der Website DOM Duration
Website Load Duration (Websites)
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 auf Anwendungsebene vom Initiieren 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 (siehe grüner Pfeil in Abbildung 31).
kyago Benchmarking
Whitepaper Version 7.41
49 von 88
Abbildung 31: Messung der Website Load Duration
Website Session Duration (Websites)
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 auf Anwendungsebene vom Initiieren 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 Benchmarking
Whitepaper Version 7.41
50 von 88
Abbildung 32: Messung der Website Session Duration
kyago Benchmarking
Whitepaper Version 7.41
51 von 88
Website Download Failure Ratio (Websites)
Ist der HTTP Download einer Website fehlerhaft oder überschreitet
die Website Response Time 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.
6.5 Test Case Photobook
Fotobücher erfreuen sich immer größerer Beliebtheit. Neben der Qualität des Endproduktes, ist auch die Verfügbarkeit der
Onlinefotoservices ein wichtiges Kriterium der Nutzerzufriedenheit.
Mit der Benchmarking Plattform werden Analysen auf Applikationsebene (Firefox mit Plug-in) von Uploadmessungen zu
den jeweiligen Fotoservices 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.
HTTP Upload Duration (Photobook)
Die HTTP Upload Duration beschreibt die durchschnittliche Ladezeit pro Bild, wobei mehrere Bilder innerhalb von 30 Sekunden
hochgeladen werden. Die Upload Duration eines einzelnen Uploads wird als die Zeit vom Senden des HTTP POST bis zum Erhalt des HTTP 200 OK erfasst.
HTTP Upload Throughput (Photobook)
Um ein realitätsnahes Nutzungsszenario abzubilden, wird das von den Fotobuch Anbietern eingesetzte HTTPS Protokoll eingesetzt. Die Kommunikation mit den Anbietern erfolgt über einen Webbrowser.
Zu den Fotoservices wird eine im PNG-Format vorliegende Bild Datei mehrfach übertragen. Das PNG Format verhindert die Nutzung von Kompressionsalgorithmen der Webseiten vor dem Versenden der
Datei an die Services. So wird stets die vollständige Bilddatenmenge übertragen.
Die Datenübertragung endet mit der vollständigen Übermittlung der
Referenzdatei (siehe grüner Pfeil in Abbildung 33), wobei diese in einem Zeitraum von 30 Sekunden stetig wiederholt wird.
kyago Benchmarking
Whitepaper Version 7.41
52 von 88
Der HTTP Upload Throughput ergibt sich aus der Datenmenge einer
Bilddatei und der für die Übertragung durchschnittlichen Dauer eines Bilduploads innerhalb der 30 sekündigen Wiederholung. Diese wird als Upload-Datenübertragungsrate in Mbit/s wiedergegeben.
Abbildung 33: Messung des HTTP Upload Throughput (Fotobuch)
HTTP Upload Failure Ratio (Photobook)
Wird innerhalb von 30 Sekunden keine Bilddatei vollständig von der
Messeinheit an den Fotobuchservice übertragen, 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 Benchmarking
Whitepaper Version 7.41
53 von 88
7. WebTV
Der weltweite Video Traffic wird 2022 bis zu 82 % des Endkunden Traffic ausmachen. Deutlich über die Hälfe hiervon wird durch Internet Video Portale wie YouTube, Amazon Prime, Netflix, Sky
oder Mediatheken verursacht (Quelle: Cisco Visual Network Index, 02.2019).
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
unterschiedlichen Video Content Provider durch. Für den Abruf eines Videos kommt entweder ein Chrome oder Firefox Webbrowser mit entsprechenden Plug-Ins zur Betrachtung aller wesentlichen
Bestandteile des zu testenden Videos zum Einsatz.
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 neusten Perceptual Evaluation of Streaming Video Quality (PEVQ-S) Verfahren der OPTICOM statt,
die als Neuerung neben H.265 auch VP9, sowie UHD-Auflösungen unterstützt.
Dieses PEVQ-S 2020 Verfahren wurde jüngst im Rahmen der
aktuellen internationalen Standardisierung von Experten unabhängig validiert und konnte sich unter acht getesteten Verfahren mit dem geringsten mittleren Fehler als aussichtsreichster Kandidat für den
neuen ITU-T Standard P.1204 qualifizieren.
Im Rahmen der YouTube (YT) Video Response Time Messungen werden jede Stunde zehn Videos in einem Google Chrome Browser
abgerufen und die Antwortzeit einer HTTP Initialisierung des Video-Elements gemessen.
kyago Benchmarking
Whitepaper Version 7.41
54 von 88
Um Caching-Mechanismen weitestgehend zu vermeiden, werden zu
jeder Stunde zehn wechselnde Videos aus einer täglich neu generierten Liste abgerufen. Für diese Liste werden einmal pro Tag die insgesamt 500 beliebesten Videos aus zehn Kategorien des Video
Portals YouTube abgefragt und in eine zufällige Reihenfolge geordent. In jeder Stunde wird ein Video je Kategorie abgerufen.
Gesamtübersicht Qualitätskennwerte
Zur Bestimmung der WebTV Qualität der am Markt verfügbaren
Produkte werden folgende Messwerte erhoben:
Abbildung 34: Übersicht Qualitätskennwerte der WebTV Messungen
YouTube (YT) Video Response Time
Mit diesem Messwert wird die Antwortzeit einer HTTP Initialisierung des Video-Elementes in Millisekunden gemessen.
Die YouTube (YT) 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 35).
1. 8.
2. 9.
3. 10. MOS [1-5]
4. 11. MOS Initial [1-5]
5. 12. MOS Stable [1-5]
6. 13. MOS Degradation [0-4]
7. 14. Failure Ratio [%]
Overview of quality benchmarks for video quality measurements
WebTV
YT Video Response Time [ms] Playback Sequence Duration [ms]
YT Video Response Time Failure Ratio [%] Video Bitrate Meta [Mbit/s]
Rebuffering Events [#]
Rebuffering Time [ms]
Video Sequence Duration [ms]
Video Response Time [ms]
Initial Buffering Time [s]
kyago Benchmarking
Whitepaper Version 7.41
55 von 88
Abbildung 35: Messung der YT Video Response Time
YouTube (YT) Video Response Time Failure Ratio
Ist der Videoabruf fehlerhaft oder überschreitet die Video Respone
Time 100 Millisekunden, so wird der Dienst als nicht erfolgreich gewertet.
Das Verhältnis von nicht erfolgreich durchgeführten Video
Downloads zu insgesamt initiierten Video Downloads stellt die YouTube (YT) Video Response Failure Ratio in Prozent dar.
kyago Benchmarking
Whitepaper Version 7.41
56 von 88
Video Response Time (WebTV)
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 36).
Abbildung 36: Messung der WebTV Video Response Duration
kyago Benchmarking
Whitepaper Version 7.41
57 von 88
Initial Buffering Time (WebTV)
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 Schnittstellen ermittelt oder durch ein Video Player Model des PEVQ-S simuliert.
Rebuffering Events (WebTV)
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.
Rebuffering Time (WebTV)
Der Messwert WebTV Rebuffering Time gibt die Standbilddauer aller
Standbild Events einer Übertagung in Millisekunden wieder.
Video Sequence Duration (WebTV)
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.
Playback Sequence Duration (WebTV)
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.
Video Bitrate Meta (WebTV)
Dieser Wert gibt die mittlere Bitrate in Mbit/s des zu diesem Betrachtungsintervall gehörenden Videostreams an.
kyago Benchmarking
Whitepaper Version 7.41
58 von 88
MOS (WebTV)
Das eingesetzte PEVQ-S Messverfahren erlaubt die Bewertung der
Videoqualität auf einer 5-Punkte MOS-Skala unter Berücksichtigung der subjektiven menschlichen Wahrnehmung mit hoher Genauigkeit.
Der von der Erlanger OPTICOM GmbH entwickelte Software-
Algorithmus ist dabei in seiner Komplexität skalierbar, je nachdem welche Detailinformationen beim jeweiligen Streaming-Service zur Analyse herangezogen werden können.
Im aufwändigsten, aber auch genauesten, hochauflösenden Modus wird der gesamte dekodierte Bildinhalt mit den Bildpunkten des Originalvideos verglichen.
Häufig jedoch verwenden Streaming-Dienste verschlüsselte Übertragungsverfahren und das vom Player wiedergegebene Bildsignal steht nicht für die Analyse zur Verfügung. In diesem Fall
basiert eine PEVQ-S Messung auf leicht zugänglichen Bitstrominformationen, die der Player zur Wiedergabe benötigt, wie z.B. Bildauflösung, verwendetes Videocodier-Verfahren und die
jeweilige Bitrate.
Abbildung 37: PEVQ-S Block Diagramm: OTT Netz (oben), PEVQ-S Bausteine
(Mitte) und PEVQ-S Ergebnisse (unten) / (Quelle: Whitepaper OPTICOM GmbH]
kyago Benchmarking
Whitepaper Version 7.41
59 von 88
Ebenfalls lässt sich das Abspielverhalten des Players messen, z.B.
wie häufig und wie lange dieser Daten aus dem Netz nachladen muss und ob es dabei zu eingefrorenen Bildsequenzen kommt.
Unzählige Kombinationen aus diesen Parametern wurden von
OPTICOM in Videotests bereits ausgewertet, so dass für jeden Video-Codec allein durch Auslesen aller Parameter aus dem Bitstrom die Qualität auch ohne Bildpunktanalyse schon recht genau
vorhergesagt werden kann.
Voraussetzung für einen derartigen Algorithmus, auch parameterbasiertes oder Bitstrom-Messverfahren genannt, ist aber,
dass er auf die verwendeten Codecs abgeglichen ist.
Die neueste PEVQ-S Version unterstützt als Neuerung neben H.265 auch VP9 sowie UHD-Auflösungen.
PEVQ-S 2020 wurde jüngst im Rahmen der aktuellen internationalen Standardisierung von Experten unabhängig validiert und konnte sich unter acht getesteten Verfahren mit dem geringsten mittleren Fehler
als aussichtsreichster Kandidat für den neuen ITU-T Standard P.1204 qualifizieren.
Der Algorithmus ermittelt in Intervallen von 4 Sekunden einen MOS.
Der Mittelwert aller MOS Ergebnisse stellt den endgültigen MOS einer Messung dar.
kyago Benchmarking
Whitepaper Version 7.41
60 von 88
Abbildung 38: Messung des WebTV Video Quality & Video Performance Indicators
MOS Initial (WebTV)
Die Betrachtung der Video Qualität innerhalb der ersten
20 Sekunden eines Video-Streams wird durch den MOS Initial bewertet. Dieser spiegelt das Verhalten der Video-Übertragung zu Beginn eines Streams wider und betrachtet somit das Verhalten des
Video-Players bei der Ermittlung der adaptiven Kanalabschätzung und die Anpassung der Streaming-Qualität an die individuellen Gegebenheiten.
MOS Stable (WebTV)
Die Abbildung einer Langzeitbetrachtung der Video Qualität, ohne die zu Beginn einer Übertragung entstehenden Kanalanpassungen, wird durch den MOS Stable ausgewiesen. Der Wert beinhaltet die
Video-Qualität nach Abschluss der initialen Phase von 20 Sekunden bis zum Ende der Video-Analyse.
kyago Benchmarking
Whitepaper Version 7.41
61 von 88
MOS Degradation (WebTV)
Der Wert MOS Degradation zeigt die Differenz zwischen dem
Erreichten und dem für dieses Video bestmöglichen MOS Wert an.
Failure Ratio (WebTV)
Ist der Videoabruf fehlerhaft oder überschreitet 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 Benchmarking
Whitepaper Version 7.41
62 von 88
8. 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 fließen in die Qualitätsbewertung ebenso ein.
kyago Benchmarking
Whitepaper Version 7.41
63 von 88
Gesamtübersicht Qualitätskennwerte
Zur Bestimmung der IPTV Qualität der am Markt verfügbaren
Produkte werden folgende Messwerte erhoben:
Abbildung 39: Übersicht Qualitätskennwerte der IPTV Messungen
STB Startup Response Time (IPTV)
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.
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.
STB Startup Time (IPTV)
Mit diesem Messwert wird die Zeit in Sekunden gemessen, die eine Set-Top-Box für das Starten aus dem Standby-Betrieb benötigt.
STB Startup Time ist im Kontext dieses Dokumentes als die Zeit
definiert, die vom Absenden des Fernbedienung-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 40).
1. 12.
2. 13.
3. 14.
4. 15.
5. 16.
6. 17. Packet Loss [%]
7. 18. Continuity Error Video [#]
8. 19. I-/P-/B-Slices [%]
9. 20. Video Quality Score [1-5]
10. 21. Video MOS [1-5]
11.
Zapping Failure Ratio [%]
Overview of quality benchmarks for video quality measurements
IPTV
STB Startup Response Time [ms] Number Zapping Failure Ratio [%]
STB Startup Time [s] EPG Zapping Response Time [ms]
Bitrate Video/Other/Total [Mbit/s]
STB Startup Failure Ratio [%] EPG Zapping Time [ms]
Zapping Response Time [ms] EPG Zapping Failure Ratio [%]
Zapping Time [ms]
Fast Zapping Response Time [ms]
Fast Zapping Time [ms]
Fast Zapping Failure Ratio [%]
Number Zapping Response Time [ms]
Number Zapping Time [ms]
kyago Benchmarking
Whitepaper Version 7.41
64 von 88
Abbildung 40: Messung der IPTV STB Startup Time
STB Startup Failure Ratio (IPTV)
Wenn während des Tests die in Abbildung 40 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 Startup Failure Ratio in Prozent dar.
Zapping Response Time (IPTV)
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.
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 Benchmarking
Whitepaper Version 7.41
65 von 88
Zapping Time (IPTV)
Mit diesem Messwert wird die Zeit in Millisekunden gemessen, die
für einen Kanalwechsel benötigt wird.
Zapping Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des Fernbedienung-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 41).
Abbildung 41: Messung der IPTV Zapping Time
Zapping Failure Ratio (IPTV)
Wenn während des Tests die in Abbildung 41 definierten Triggerpunkte nicht erkannt werden, wird der Kanalwechsel als nicht
erfolgreich gewertet. Das Verhältnis von nicht erfolgreich durchgeführten Kanalwechseln zu insgesamt initiierten Kanalwechseln stellt die Zapping Failure Ratio in Prozent dar.
kyago Benchmarking
Whitepaper Version 7.41
66 von 88
Fast Zapping Response Time (IPTV)
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.
Fast 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.
Fast Zapping Time (IPTV)
Mit diesem Messwert wird die Zeit in Millisekunden gemessen, die für einen Kanalwechsel benötigt wird. Der Kanalwechsel wird mit
dem Fernbedienung-Code "P+ (Programm +) initiiert. Fast Zapping Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des Fernbedienung-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 42).
Abbildung 42: Messung der IPTV Fast Zapping Time
kyago Benchmarking
Whitepaper Version 7.41
67 von 88
Fast Zapping Failure Ratio (IPTV)
Wenn während des Tests die definierten Triggerpunkte nicht erkannt
werden, wird der Kanalwechsel als nicht erfolgreich gewertet.
Das Verhältnis von nicht erfolgreich durchgeführten Kanalwechseln zu insgesamt initiierten Kanalwechseln stellt die Fast Zapping Failure
Ratio in Prozent dar.
Number Zapping Response Time (IPTV)
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.
Number 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.
Number Zapping Time (IPTV)
Mit diesem Messwert wird die Zeit in Millisekunden gemessen, die für einen Kanalwechsel benötigt wird. Der Kanalwechsel wird mit den Fernbedienung-Codes "Taste 3" und "Ok" initiiert. Der zeitliche
Abstand zwischen den Fernbedienung-Codes beträgt 500 Millisekunden.
Number Zapping Time ist im Kontext dieses Dokumentes als die Zeit
definiert, die vom Absenden des letzten Fernbedienung-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 43).
kyago Benchmarking
Whitepaper Version 7.41
68 von 88
Abbildung 43: Messung der IPTV Number Zapping Time
Number Zapping Failure Ratio (IPTV)
Wenn während des Tests die definierten Triggerpunkte nicht erkannt
werden, wird der Kanalwechsel als nicht erfolgreich gewertet.
Das Verhältnis von nicht erfolgreich durchgeführten Kanalwechseln zu insgesamt initiierten Kanalwechseln stellt die Number Zapping
Failure Ratio in Prozent dar.
EPG Zapping Response Time (IPTV)
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.
EPG 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 Benchmarking
Whitepaper Version 7.41
69 von 88
EPG Zapping Time (IPTV)
Mit diesem Messwert wird die Zeit in Millisekunden gemessen, die
für einen Kanalwechsel benötigt wird. Der Kanalwechsel wird mit den Fernbedienung-Codes "EPG", "Pfeil Runter" und "OK" initiiert. Der zeitliche Abstand zwischen den Fernbedienung-Codes beträgt
500 Millisekunden.
EPG Zapping Time ist im Kontext dieses Dokumentes als die Zeit definiert, die vom Absenden des letzten Fernbedienung-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 44).
Abbildung 44: Messung der IPTV EPG Zapping Time
kyago Benchmarking
Whitepaper Version 7.41
70 von 88
EPG Zapping Failure Ratio (IPTV)
Wenn während des Tests die definierten Triggerpunkte nicht erkannt
werden, wird der Kanalwechsel als nicht erfolgreich gewertet.
Das Verhältnis von nicht erfolgreich durchgeführten Kanalwechseln zu insgesamt initiierten Kanalwechseln stellt die EPG Zapping Failure
Ratio in Prozent dar.
Bitrate Video/Other/Total (IPTV)
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.
Packet Loss (IPTV)
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.
Continuity Error Video/Audio (IPTV)
Der IPTV Continuity Error wird aus dem Continuity Counter des MPEG-TS Header errechnet und pro detektierten Stream
festgehalten.
I-/P-/B-Slices (IPTV)
Die Anzahl der IPTV I-/P-/B-Slices werden aus dem H.264 Video-Stream erfasst und in Ihrer prozentualen Häufigkeit dargestellt.
Video Quality Score (IPTV)
Bei dem IPTV Video Quality Score werden von der Messeinheit IPTV Streams erkannt und die jeweiligen IP Pakete einem Stream
zugeordnet. Eine Messung dauert 40 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.
kyago Benchmarking
Whitepaper Version 7.41
71 von 88
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 45).
Abbildung 45: Messung der Video Qualität
Video MOS (IPTV)
Bei dem IPTV Video MOS werden von der Messeinheit IPTV Streams erkannt, diese IPTV Streams basieren auf adaptive Streaming (MPEG DASH). Je nach IPTV Anbieter werden unterschiedliche
Streaming Systeme genutzt.
Hierbei kommen typischerweise der MPEG Video Container mit einer H.264, H.265 oder HEVC/VP9 Codierung und unterschiedlichen
Audio Codecs zum Einsatz.
kyago Benchmarking
Whitepaper Version 7.41
72 von 88
Die Qualitätsanalyse findet nach dem Perceptual Evaluation of
Streaming Video Quality (PEVQ-S) Verfahren der OPTICOM statt. Dieses beruht auf dem Standard ITU-T Req P.1204.
PEVQ-S bewertet den Stream in einem Non-Reference (NR) Ansatz.
Dieser bewertet neben den Video-Paramtern, wie die genutzte Adaptive Bitrate, Auflösung, Framerate etc., auch die Inhaltskoplexität des Streams. Die Inhaltskomplexität wird je nach
verwendetem Digital Rights Management (DRM) erhoben.
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) Wert als Mean Opinion Score (MOS), der zwischen 1
(schlecht) und 5 (sehr gut), liegt abgeleitet. Der Algorithmus ermittelt in Intervallen von 4 Sekunden einen MOS (sieheAbbildung 46).
Abbildung 46: Messung des IPTV Video MOS
kyago Benchmarking
Whitepaper Version 7.41
73 von 88
One IPTV Stream with parallel Dataload and Voice
Die Qualitätskennwerte des TestCase IPTV werden zusätzlich mit
parallelem HTTP Up- und Download sowie parallele Voice-Verbindungen zur Auslastung der vollen Bandbreite messtechnisch erfasst.
Hierbei gilt, dass die Störgrößen HTTP Up- und Download im Abstand von 10 Sekunden gestartet werden. Anschließend wird die Messgröße IPTV hinzugefügt und nach fünf Sekunden die Voice-
Verbindungen initiiert. In der Messkampagne Consumer werden zwischen NGN Anschlüssen 2 Verbindungen parallel aufgebaut. Die Störgrößen (Last) werden erst nach dem Ende der IPTV Messung
gestoppt, um eine volle Auslastung der Bandbreite während der Messung zu gewährleisten.
Ausschließlich die Qualitätskennwerte der IPTV Messung mit STB,
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
paralleler Last 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.
Die Qualitätskennwerte für IPTV sind identisch zu dem Szenario
ohne Last.
Two IPTV Streams with parallel Dataload and Voice
Die Qualitätskennwerte des TestCase IPTVx2 werden zusätzlich mit
parallelem IPTV Stream, HTTP Up- und Download sowie parallele Voice-Verbindungen zur Auslastung der vollen Bandbreite messtechnisch erfasst.
Hierbei gilt, dass die Störgrößen HTTP Up- und Download und einem IPTV Stream (Last) im Abstand von 10 Sekunden gestartet werden. Anschließend wird die Messgröße IPTV hinzugefügt und nach fünf
Sekunden die Voice-Verbindungen initiiert. In der Messkampagne Consumer werden zwischen NGN Anschlüssen 2 Verbindungen parallel aufgebaut. Die Störgrößen (Last) werden erst nach dem
Ende der IPTV Messung gestoppt, um eine volle Auslastung der Bandbreite während der Messung zu gewährleisten.
Ausschließlich die Qualitätskennwerte der zweiten IPTV Messung mit
STB, des HTTP Downloads und der Sprachqualitätsmessung fließen als Messgröße in die Bewertung ein.
kyago Benchmarking
Whitepaper Version 7.41
74 von 88
Alle Qualitätskennwerte bis auf die HTTP Response Time werden
nach den gleichen Verfahren wie ohne paralleler Last 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.
Die Qualitätskennwerte für IPTV sind identisch zu dem Szenario
ohne Last.
kyago Benchmarking
Whitepaper Version 7.41
75 von 88
9. 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 47 bis Abbildung 53).
Ü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.
Abbildung 47: Tabellarischer Consumer Benchmarking Voice Report
kyago Benchmarking
Whitepaper Version 7.41
76 von 88
Abbildung 48: Grafischer Consumer Benchmarking Voice Report
kyago Benchmarking
Whitepaper Version 7.41
77 von 88
Abbildung 49: Grafischer Consumer Benchmarking Data Report
kyago Benchmarking
Whitepaper Version 7.41
78 von 88
Abbildung 50: Grafischer Consumer Benchmarking Web Services Report
kyago Benchmarking
Whitepaper Version 7.41
79 von 88
Abbildung 51: Grafischer Consumer Benchmarking Photobook Services Report
kyago Benchmarking
Whitepaper Version 7.41
80 von 88
Abbildung 52: Grafischer WebTV Benchmarking Report
kyago Benchmarking
Whitepaper Version 7.41
81 von 88
Abbildung 53: Grafischer IPTV Benchmarking Report
kyago Benchmarking
Whitepaper Version 7.41
82 von 88
10. 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 54 und Abbildung 55). 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-, Daten- und
IPTV-Messungen
Abbildung 54: Monitoring Plattform
kyago Benchmarking
Whitepaper Version 7.41
83 von 88
Abbildung 55: Alarmierung via E-Mail
kyago Benchmarking
Whitepaper Version 7.41
84 von 88
11. 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
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
kyago Benchmarking
Whitepaper Version 7.41
85 von 88
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
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
kyago Benchmarking
Whitepaper Version 7.41
86 von 88
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
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
kyago Benchmarking
Whitepaper Version 7.41
87 von 88
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
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
kyago Benchmarking
Whitepaper Version 7.41
88 von 88
12. Impressum
Die Erarbeitung des vorliegenden Whitepapers erfolgte durch den Unterzeichner, der für die technische Richtigkeit garantiert. Ihre Fragen zu diesem Dokument, dessen Inhalt, Struktur oder
Geltungsbereich sind uns willkommen.
Ansprechpartner:
Christoph Sudhues Gründer und geschäftsführender Gesellschafter
zafaco GmbH Münchener Str. 101/39 85737 Ismaning
Deutschland Tel. +49 89 820308 200
© zafaco GmbH
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.