Quality of Experience (QoE)

Quality of Experience (QoE) adressiert den Sachverhalt, dass einzig die Wahrnehmung der VoIP-Qualität durch den Benutzer das Maß aller Dinge ist.

Die Entwicklung hat uns zahlreiche, sehr unterschiedliche Verfahren für die messtechnische QoE-Bestimmung, wie z.B. MOS, PESQ, E-Model, RTCP beschert.

Die nachfolgende kurze Übersicht gewährt einen Blick hinter die Kulissen der Standards, um so etwas mehr Transparenz in den Dschungel der Fachbegriffe bringen. Erstaunlicherweise zeigen einige der etablierten Standards teils erhebliche Einschränkungen oder sind -gemäß eigener Definition- für Mess-Zwecke überhaupt nicht geeignet.

Hier kann lediglich die Sensibilität in Bezug auf Mess-Verfahren erhöhen werden – welche Verantwortung für die Gültigkeit von Mess-Ergebnissen und die damit zusammen hängende Stabilität des VoIP-Betriebes jemand übernehmen will (und kann), muss er letztlich selbst entscheiden ...

MOS (Mean Opinion Score)

MOS (ITU-T P.800) ist ein subjektives Verfahren, dessen Grundlagen in die Zeiten der klassischen Telefonie zurückreichen. Hier wurde einer Anzahl von Probanden ein Sprachsample mit dem Ziel präsentiert, die Bewertung an Hand einer Skala von 1 (sehr schlecht) bis 5 (sehr gut) vorzunehmen. Der Mittelwert der Meinung aller Probanden ergab dann den MOS-Wert. Mittlerweile ist das Verfahren natürlich automatisiert und läuft auf PCs ab.

VoIP-Qualität ist ein ähnlich komplexer Sachverhalt wie das Wetter, so dass die Zusammenfassung unterschiedlichster Parameter zu einem singulären Score fragwürdig ist. Nicht nur, dass die Schwankungen der jeweiligen Parameter in einer VoIP-Umgebung auf ganz unterschiedliche Ursachen zurückzuführen sind, die Parameter selbst besitzen auch einen sehr individuellen Informationsgehalt. Dieser geht bei MOS komplett verloren.

Mindestens ebenso kritisch zu hinterfragen sind die für MOS verwendeten Eingangsdaten (RTCP, PESQ, R-Factor, etc.), welche in den nachfolgenden Absätzen besprochen werden.

MOS-Werte sind daher definitiv nicht für die praktische Fehlersuche geeignet. Gleiches gilt hinsichtlich der Eignung für VoIP-Readiness Checks, mit denen ja die Praxistauglichkeit von IP-Netzwerken nachgewiesen werden soll. Daran ändert auch die scheinbare Genauigkeit von MOS-Werten mit zwei Nachkommastellen einiger Tools nichts.

PESQ (Perceptual Evaluation of Speech Quality)

PESQ (ITU-T P.862) vergleicht standardisierte, wenige Sekunden lange Sprachproben vor und nach der Übertragung. Dabei ist das Ergebnis u.a. von den verwendeten Sprachproben (Stimmlagen, Sprache) abhängig. Das Verfahren konsumiert hemmungslos wertvolle Rechenleistung, so dass in einigen Anwendungsfällen DSPs verwendet werden müssen. PESQ-Werte lassen sich in MOS umrechnen.

Es ist ein ausgezeichnetes Verfahren, um z.B. die Güte neuer Codecs für IP-Phones zu bestimmen. Der Nutzen von PESQ bei der Fehlersuche in realen VoIP-Umgebungen ist jedoch schwer erkennbar, da die Sprachinformation der VoIP-Gespräche vor Übertragung für Vergleichszwecke natürlich nicht zur Verfügung stehen.

Daher findet dieses Verfahren auch nur stichprobenartig und unter Benutzung künstlicher Testgespräche Anwendung. Wie sich zeigt ein weiterer Fauxpas, da so die realen Lastverhältnisse verändert, und die Erkennung der 25-30% von Fehlern des VoIP-Systems bereits von vornherein ausgeschlossen werden. Außerdem haben Messungen, welche nur wenige Sekunden dauern, für reale VoIP-Umgebungen ohnehin keine praktische Relevanz.

E-Model (R-Factor)

Beim E-Model (ITU-T G.107) handelt es sich um ein Planungstool, das auf einer 100-teiligen Skala einen sog. R-Factor für die Sprachqualität kalkuliert. Erwartungsgemäß lässt sich auch der R-Factor (über eine nichtlineare Kennlinie) in MOS überführen. Zur Ermittlung des R-Factor werden jedoch ca. 20 sehr diffizile Parameter benötigt, von denen sich kaum einer in der täglichen Praxis messtechnisch ermitteln lässt. Dem Planer werden daher Vorzugswerte mit einem zugehörigen Wertebereich (teils über mehrere Zehnerpotenzen) an die Hand gegeben – so dass er entsprechende Annahmen treffen kann.

Was hat das E-Model also mit der Messung der VoIP-Qualität zu tun ? Die Antwort liegt klar auf der Hand. Das hindert Hersteller von Messtools allerdings nicht, in Netzwerkmessungen einen R-Factor mit zwei Nachkommastellen zu bestimmen und anschließend in MOS umzurechnen. Über die Vergleichbarkeit und Reproduzierbarkeit von R-Factoren verschiedener Tools kann angesichts der hohen Anzahl angenommener Eingangswerte und ihres Wertebereiches nur spekuliert werden.

RTCP (Realtime Transport Control Protocol)

RTCP ist vom IETF gemeinsam mit dem, zur Übertragung von Sprache verwendeten RTP im RFC 3550 standardisiert worden. Es hat die Aufgabe, die Qualität der ansonsten ungesicherten (UDP) Verbindung eines VoIP-Gespräches zu kontrollieren. Dazu erzeugt der empfangende VoIP-Endpunkt i.d.R. alle 5 Sekunden einen sog. RTCP-Report, den er als Feedback an den sendenden VoIP-Endpunkt zurück schickt. Die Intention hierbei ist, dem sendenden VoIP-Endpunkt bei schlechter Empfangsqualität die Möglichkeit zu geben, seine Sendeparameter mit dem Ziel der Qualitätsverbesserung zu modifizieren.

Zu diesem Zweck berechnet der empfangende VoIP-Endpunkt Werte für die Parameter Jitter, Delay (Roundtrip-Delay) und Packet Loss, welche dann zu Bestandteilen der RTCP-Reports werden. Natürlich müssen bei der Bestimmung der Parameter -nicht zuletzt wegen der verfügbaren CPU-Ressourcen in den Endpunkten- zwangsläufig teils erhebliche Kompromisse eingegangen werden.

In der Praxis sind jedoch kaum VoIP-Endpoints zu finden, die RTCP-Reports für ein adaptives Verhalten nutzen. Statt dessen werden die RTCP-Reports trotz nachweislicher Nicht-Eignung (oft noch unter Bezug auf den „Vorgänger“ RFC 1889) gerne von Mess-Tools verwendet, um Aussagen über die VoIP-Qualität zu machen.

Im Kapitel 6.4.4 des RFC 3550 ist klar zu lesen, dass die dort spezifizierten Jitter-Werte nicht für Mess-Zwecke geeignet sind. Das ist in der Formel für die Jitter-Berechnung begründet und lässt sich sehr leicht theoretisch nachvollziehen. Messungen in realen Projekten bestätigen ebenfalls – bei tatsächlich guter VoIP-Qualität können schlechte RTCP-Reports entstehen und umgekehrt. Leider ist auch jede andere beliebige gut-schlecht Kombination möglich. Ähnlich sieht es mit den Werten für Packet Loss aus. Nur dem Berechnungs-Algorithmus für das Roundtrip-Delay kann Gültigkeit bescheinigt werden. Daran ändern leider auch die neueren XR-Reports nach RFC 3611 nichts. Bei Secure-RTP (RFC 3711) ist es für RTCP-basierte Tools dann ohnehin vorbei – die RTCP-Reports sind dort verschlüsselt.

Fazit: die Verwendung von Standards allein ist noch kein Gütekriterium, wenn diese für den beabsichtigten Verwendungszweck nicht geeignet sind. Bei „nach RFC 1889“ bzw. „nach RFC 3550“ berechneten Parametern ist also höchste Vorsicht geboten !