kyago whitepaper v 7.41 de · whitepaper version 7.41 12 von 88 somit können daten erhoben werden,...

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


3 von 88

5. Highspeed Internet ............................................................... 28

Messserver beim Anbieter oder zafaco ......................................28

Daten-Referenz-System bei zafaco ...........................................28

Messclient ...........................................................................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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


kyago Benchmarking


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


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)


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.


kyago Benchmarking


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


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.



6.4 Test Case Websites

DNS Lookup Time (Websites)


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


46 von 88


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


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


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


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


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


50 von 88

Abbildung 32: Messung der Website Session Duration

kyago Benchmarking


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.



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


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


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


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.


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


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


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


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


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


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


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


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


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


63 von 88


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


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


65 von 88

Zapping Time (IPTV)


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


66 von 88

Fast Zapping Response Time (IPTV)



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


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


Number Zapping Response Time (IPTV)



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


68 von 88

Abbildung 43: Messung der IPTV Number Zapping Time

Number Zapping Failure Ratio (IPTV)



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


69 von 88

EPG Zapping Time (IPTV)


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


70 von 88

EPG Zapping Failure Ratio (IPTV)



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


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


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


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


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


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


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


76 von 88

Abbildung 48: Grafischer Consumer Benchmarking Voice Report

kyago Benchmarking


77 von 88

Abbildung 49: Grafischer Consumer Benchmarking Data Report

kyago Benchmarking


78 von 88

Abbildung 50: Grafischer Consumer Benchmarking Web Services Report

kyago Benchmarking


79 von 88

Abbildung 51: Grafischer Consumer Benchmarking Photobook Services Report

kyago Benchmarking


80 von 88

Abbildung 52: Grafischer WebTV Benchmarking Report

kyago Benchmarking


81 von 88

Abbildung 53: Grafischer IPTV Benchmarking Report

kyago Benchmarking


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


83 von 88

Abbildung 55: Alarmierung via E-Mail

kyago Benchmarking


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


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


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


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


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

[email protected]

© 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.

kyago whitepaper v 7.41 de · whitepaper version 7.41 12 von 88 somit können daten erhoben werden,...

Documents