Triple-Play-Messverfahren

Netzwerktests für Triple-Play

Am Ende zählt, was hinten rauskommt

Group C: Voice over IP-Performance

Ein Telefonanruf, der das Internet-Protokoll nutzt, belegt die Verbindung nahezu gleichermaßen in beide Richtungen. (©Smartmedia PresSservice)

Dieser Test simuliert einen VoIP-Anruf über ein WLAN, das bereits mit der maximalen Bandbeite ausgelastet ist. Dazu wird die Verbindung zum jeweiligen Messort mit jeder TCP-Datenmenge beschickt, die in den vorausgegangenen TCP-Messungen als Maximalwert ermittelt wurde. Die Herausforderung für den betroffenen Access-Point ist, trotzdem Verzögerungen oder gar Datenverlust bei den Voice-over-IP-Daten zu verhindern. Wenn die VoIP-Qualität, die sich als MOS-Wert ausdrückt, unabhängig von der am jeweiligen Messort verfügbaren Bandbreite ist, funktioniert ein QoS-Mechanismus wirklich.

Test C1: Der zeitliche Verlauf des Mean Opinon Score (MOS). Werte über 3,7 sind gut.

Skript	Ergebnis
C1	ein VoIP-Datenstrom down mit 64 kBit/s ein VoIP-Datenstrom up mit 64 kBit/s eine TCP Verbindung upstream mit 256 kBit/s eine TCP-Verbindung downstream mit maximaler Datenrate

Tabelle: IxChariot-Skripte, Gruppe C.

Gruppe D: UDP/RTP-Transfer

Bei allen vorhergehenden Tests werden erhebliche Mengen an Daten in beide Richtungen geschickt. Bei den Tests der Gruppe D gehen RTP/UDP-Streams vom Access-Point zum Client. Der WLAN-Traffic, der vom Client ausgeht reduziert sich dabei um die ACK-Datenpakete im WLAN-Transportlevel.

Ziel dieses Tests ist zu ermitteln, inwieweit das Pärchen aus Access-Point und Client mit Traffic-Überlastung umgehen kann. Dieser Test hilft Mechanismen zu erkennen, die ein "Verstopfen" des Datenpuffers vermeiden helfen. Das Real time Protokoll (RTP), das oberhalb des UDP-Protokolls arbeitet, kennt weder Bestätigung von Datenpaketen (Acknowledge) noch Mechanismen zur Regulierung der Geschwindigkeit des Datenstroms (Xon/Xoff). Dennoch lassen sich über den Zeitstempel Laufzeit-Veränderungen, Schwankungen und Fehler in der Paket-Reihenfolge feststellen.

In diesem Beispiel fallen die Paket-Verluste niedriger aus, als erwartet – Zeichen für einen Mechanismus zur Datenfluss-Kontrolle auf der kabelgebundenen Seite. (©Smartmedia PresSservice)

Der tatsächliche Datendurchsatz ist weit unter dem Maximum von 100 Mbps. (©Smartmedia PresSservice)

Skript	Ergebnis
D1	ein RTP/UDP-Stream mit 100 MBit/s
D2	zwei RTP/UDP-Streams mit jeweils 100 MBit/s

Tabelle: IxChariot-Skripte der Gruppe D. (©Smartmedia PresSservice)

Group E: Streaming-Video-Performance

Dieser Test ermittelt die Qualität von Videoübertragungen in Standard- und HDTV-Qualität. Der Client verwendet dieselben Buffering- und Wiederherstellungs-Mechanismen wie andere, reale Video-Streaming-Clients. Ein Paket gilt hierbei als verloren, wenn es nicht rechtzeitig zur Übermittlung an das Display ankommt. Eventuelle Fehler in der Paket-Reihenfolge werden mit Standard-RTP-Mechanismen abgefangen. Bis zu 0,05 Prozent verlorene Pakete fallen normalerweise nicht auf, da sie von den Wiederherstellungs-Mechanismen von MPEG ausgeglichen werden.

HDTV-Stream mit schlechter Qualität: Verluste von mehr als 100 Datagrammen am Stück verursachen sichtbare Aussetzer. (©Smartmedia PresSservice)

Skript	Ergebnis
E1	ein IP-TV-Stream vom Access-Point zum Client über RTP mit einer Datenrate von 3;75 Mbps
E2	ein HD-TV-Stream vom Access-Point zum Client über RTP mit einer Datenrate von 20 Mbps

Gruppe Z: Aufwärmen

WLAN-Access-Points brauchen nach dem Start eine "Warmlaufphase" um sich an die vorhandenen Gegebenheiten anzupassen Dies ist nur mit einer aktiven Datenübertragung möglich. Etwa 10 bis 20 Sekunden vergehen, bis bei voller Datenrate die optimale Konfiguration ermittelt ist, bei der die Daten mit maximaler Geschwindigkeit übertragen werden können.

Um zu verhindern, dass diese Aufwärmphase sich auf die Ergebnisse des Tests auswirkt, beginnt jede Messung mit einer 20-sekündigen TCP-Übertragung mit maximalem Durchsatz. Die Messergebnisse des AufwärmSkripts werden verworfen.