Woher wissen Sie, dass Ihr Netzwerk die Sprache per SIP auch korrekt vermittelt? Ihr Telefonsystem wurde aktualisiert. Es nutzt jetzt das SIP-Trunking, Damit ist man bei der neuesten Generation von Telefonfunktionen angekommen und jeder ist glücklich. Aber ein paar Probleme machen immer wieder auf sich aufmerksam und erinnern Sie daran, dass nicht alles reibungslos funktioniert. Woher weiß ich, wo die Ursachen dieser Probleme liegen? Ist etwa das Netzwerk an diesen Problemen schuld?
Mittlerweile sollten wir alle Faktoren kennen, die zu einer Reduzierung der Sprachqualität führen: Latenz, Jitter und Paketverluste. Außer in einigen Ausnahmefällen (beispielsweise bei der Kommunikation über Satellitenstrecken) sollte die Verzögerung immer in einem niedrigen Bereich sein und maximal 100 bis 200 Millisekunden betragen. Der Jitter sollte ebenfalls niedrig sein. Natürlich führen große Lasten bzw. lange Warteschlangen in den Koppelkomponenten (Switches, Router, usw.) zu Überlastungen und zu nicht unerheblichem Jitter in den Übermittlungspfaden. Die Paketverluste sind ebenfalls ein wichtiger Indikator für Netzprobleme. Füllen sich die Warteschlangen in den Netzkomponenten durch Überlastungen, gehen meist auch Pakete beim Pufferüberlauf verloren.
Woher wissen wir, dass unser Netzwerk reibungslos läuft? Woher wissen wir, dass die Probleme bei der Sprachübermittlung durch andere Faktoren als unser Netzwerk verursacht werden? Ohne eine entsprechende Überwachung des Netzwerks lassen sich diese Fragen nicht qualifiziert beantworten.
Sichtbarkeit im Netzwerk
Im Idealfall überwacht das Netzwerk-Monitoring-System alle Schnittstellen in den Netzpfaden, über die die Sprache übermittelt wird. Das bedeutet, dass das Netzwerk-Monitoring-System korrekt konfiguriert sein muss, um alle Schnittstellen zu erfassen. In der Praxis findet man jedoch immer wieder Implementierungen vor, dessen Einsatzbereich aufgrund der Kosten begrenzt ist. Daher sollte man sich nicht wundern, wenn ein solches System nicht alle Netzwerkschnittstellen überwacht und daher kein vollständiges Bild der aktuellen Situation liefert.
Ich nutze zur Fehleranalyse immer zuerst die in den Netzwerkkomponenten integrierten Funktionen. Hierzu gehören beispielsweise die Aufzeichnungen von Schnittstellenfehlern (zu kurze und zu lange Pakete, verloren gegangene Pakete, usw.). Über die Interface-Statistiken lassen sich Fehler auf Netzwerkschnittstellen oder der daran angeschlossenen Übertragungsmedien (beispielsweise eine verschmutzte optische Verbindung oder eine gestörte WAN-Verbindung) schnell finden. Paketverluste treten auf, wenn die Puffer einer Netzwerkschnittstelle überlaufen. Staus am Ausgang eines Geräts treten deutlich häufiger auf als Staus am Eingang eines Geräts. In der Regel sollte man bei allen Schnittstellen, die mehr als 0,0001% (1×10-5) Paketverlust aufweisen schnell handeln und die Fehler beseitigen.
Ich untersuche bei meinen Analysen auch immer die Anrufdatensätze bzw. Traces und suche dabei nach Anrufen, die einen mittleren Mean-Opinion-Score (MOS) aufweisen. Die MOS-Werte errechnen sich in der Praxis aus den ermittelten Werten für Latenz, Jitter und Paketverlusten.
Auch ist die genaue Untersuchung des gesamten Kommunikationspfads nützlich. Ich finde immer wieder Situationen vor, in denen der gesamte Kommunikationspfad (Endgerät zu Endgerät) zu einer schlechten Sprach- bzw. Video-Qualität beiträgt. Der ideale Lösungsweg besteht sicher darin ein entsprechendes Test-System an den Enden der echten Netzwerkpfade zu installieren und anschließend die notwendigen Messungen vorzunehmen. Leider hält die Praxis nicht immer mit der idealen Welt stand. Bei Messungen am echten System würde man sicher sehr schnell feststellen, welche Komponente fehlerhaft ist bzw. welcher der Datenpfade ein Problem aufweist.
In der Praxis sind viele Netzwerke zu groß, um einzelne Elemente eingehend analysieren zu können. Aus diesem Grund nutze ich Netzmanagement-Reporting-Systeme, die mir die gewünschten Testergebnisse als Top-N-Berichte darstellen. Damit lassen sich schnell die schlimmsten Probleme identifizieren. Ich überprüfe die Top-N-Berichte auf bestimmte Gemeinsamkeiten. Ist an einem Problem beispielsweise eine gemeinsame Infrastruktur beteiligt? Ist an dem Problem immer eine bestimmte Seite beteiligt? Lässt sich ein Top-N-Problem mit einer Schnittstelle aus dem Bericht der Top-N-Paketverluste korrelieren? Die Verwendung von Netzmanagement-Reporting-Tools zur Identifizierung von Problemen ist sehr effizient.
Kontrolle der Sprachqualität im Netzwerk
Die Sprachqualität im Netzwerk lässt sich auf mehrere Arten überprüfen. Die Überwachung der Servicequalität ( Quality of Service; QoS) gehört zu den am häufigsten genutzten Mechanismen. Ich überprüfe beispielsweise die aktuellen QoS-Bandbreitendefinitionen, indem ich die Anzahl der gleichzeitigen Anrufe mit der für VoIP benötigten Bandbreite (G.711 = 100 KBit/s) multipliziere. Dieser Wert (eventuell auch noch zusätzlich Reserve) wird anschließend die Netzkonfiguration für das jeweilige VoIP-VLAN auf den Netzkomponenten konfiguriert. Das Problem dieses Ansatzes besteht jedoch darin, dass sich nach der ersten Konfiguration immer sofort die Anforderungen ändern. Die Bandbreitensteigerung kann zwar mit einer gewissen Reserve abgefangen werden, aber zu viel Reserve bedeutet eine Verschwendung von ungenutzter Bandbreite. Also müssen die vorhandenen Administratoren das Problem verstehen und regelmäßig die notwendigen Änderungen in Einrichtungen an der für von VoIP bzw. UC bereitgestellten Netzwerk-Bandbreite vornehmen.
Ein zweiter Kontrollmechanismus basiert auf der Call-Admission-Control (CAC). Dieser Steuerungsmechanismus legt das maximale Anrufvolumen im VoIP-System fest und ist somit ein Indikator für die zugeteilte Bandbreite. Wird der konfigurierte Höchstwert erreicht, dann muss der Anrufcontroller den Administrator automatisch warnen.
Überprüfen des Quality of Experience (QoE)
Ich bin ein Verfechter einer aktiven Überprüfung der Kommunikationspfade. Auf Basis einer Ende-zu-Ende-Überprüfung lässt sich die sogenannte Qualität of Experience (QoE) objektiv messen. Quality of Experience (QoE) bezeichnet ein subjektives Maß eines Nutzers zur Beurteilung von Liefer- oder Dienstleistungen. Es befasst sich allgemein mit einem Angebot aus der Sicht des Nutzers. Der Begriff „QoE“ hat eine gewisse Ähnlichkeit mit dem ursprünglich für die Beurteilung von Telekommunikationsdienste entwickelten Mean-Opinion-Score (MOS). Beim MOS steht der Nutzer und dessen subjektive Qualitätsbeurteilung einer Übertragungsstrecke (Ende zu Ende) im Mittelpunkt. Damit soll jedoch nicht gesagt werden, dass wir die technischen Metriken zur Qualitätsbeurteilung in Zukunft nicht mehr benötigen. Diese sind unbedingt erforderlich. Der QoE baut auf einer Kombination von technischen Kennzahlen und den subjektiven Erfahrungen der Nutzer auf.
Natürlich ist das Netzwerk nicht allein für den QoE verantwortlich. Die QoE bezieht auch die Endgeräte in die Qualitätsbeurteilung mit ein. Das Netzwerk ist das System über das in der Regel alle Dienstleistungen und Anwendung (VoIP- und Unified-Communications) abgewickelt werden. Aus diesem Grund ergeben sich aus der Einbeziehung von QoE in die Gesamtbetrachtung der Systemleistung eine Reihe von Messkriterien zur Optimierung der Netze unter Einbeziehung der subjektiven Nutzeraspekte.
Einschlägige Untersuchungen haben ergeben, dass sich in der Praxis der QoE auf Messdaten, wie beispielsweise Verfügbarkeit, Mean-Time-to-Repair (MTTR) und Mean-Time-Between-Failures (MTBF), fokussiert. Die Praxis beweist jedoch, dass die Nutzer eine Verschlechterung der Reaktionszeiten eher bemerken als die Verbesserung der Netz- oder Systemverfügbarkeit. Die Ursachen hierfür sind in der menschlichen Psychologie zu suchen und haben wenig mit den Systemparametern des Netzwerks zu tun. Die Nutzer wissen, dass beim Ausfall eines Netzes oder Rechners die IT-Abteilung alle Anstrengungen unternimmt, dass diese Systeme in Kürze wieder ordnungsgemäß funktionieren. Eine Verschlechterung der Reaktionszeit eines Systems oder des Netzes zeigen sich die Nutzer jedoch skeptisch, ob die von der IT-Abteilung ergriffenen Verbesserungsmaßnahmen ihre erhoffte Wirkung zeigen werden. Darüber hinaus beeinträchtigt eine sich verschlechternde Reaktionszeit das Nutzerverhalten weit länger als ein Ausfall eines Netzwerks oder Systems, so dass die Wahrnehmung des betreffenden Problems über eine andere Qualität verfügt.
Die Verschlechterung der Reaktionszeit ist den Nutzern lästig und lässt sich nicht oder nur sehr rudimentär in technischen Parametern ausdrücken. Die Darstellung der durchschnittlichen Reaktionszeit pro Tag, Woche oder Monat haben für den Nutzer keine Bedeutung. Variabel lange Reaktionszeiten, auch bei einem objektiv schnellen Gesamtdurchschnitt, wirken sich in der Regel auf die Nutzerakzeptanz weit negativer aus, als kontinuierlich langsame Reaktionszeiten. Spikes und kurzzeitige Peaks hinterlassen innerhalb von kürzester Zeit ein ungutes Gefühl über die Leistungsfähigkeit des Systems beim Benutzer. Diese Auswirkungen geben dem IT-Manager jedoch hilfreiche Hinweise zur Ursachenforschung.
Der QoE beschreibt somit annäherungsweise die Realität der Anwender und bezieht sich auf die menschliche Erfahrung und deren subjektive Beurteilung eines Dienstes oder einer Dienstleistung. Der QoS bezieht sich auf die Konzepte, Parameter und Methoden, die die Wechselwirkungen zwischen Endgeräten bzw. Anwendungen und den Netzressourcen beschreibt. Aus diesem Grund stehen sich die zwei Begriffe auf den ersten Blick diametral entgegen. Bei der Bewertung von QoE in Bezug auf die Reaktionszeit wird man sehr schnell die Rolle und den Nutzen von synthetisch ermittelten Statistikwerten diskutieren. Die fundamentale Wahrheit lautet in diesem Fall jedoch, dass beide Betrachtungsweisen sinnvoll sind. Synthetische Tests werden aktiv durchgeführt und stellen Informationen zur Beurteilung von SLA-Anforderungen zur Verfügung. In diesem Fall lässt sich aus dem Informationsmaterial objektiv ableiten, wenn eine vereinbarte Verfügbarkeit eines Dienstes nicht mehr gegeben ist. Hierzu ist der Quality of Experience nicht fähig.
Viele synthetische Tests liefern Diagnostikwerte und orientieren sich an einer bestimmten Art eines Transaktionsverhaltens. Das von den synthetischen Tests erhobene Zahlenmaterial wird in der Regel über ein bestimmtes Zeitintervall gesammelt. Aus diesem Grund kann es vorkommen, dass bestimmte Probleme innerhalb des gewählten Zeitrahmens nicht sichtbar werden. Hinzu kommt, dass der IT-Manager die Überwachungsfunktionen auf sein Netzwerk individuell anpassen muss. Da die modernen Systeme in der Lage sind, alle möglichen Parameter zu sammeln und daraus die entsprechenden Statistikdaten zu erzeugen, hängt deren Ergebnis von der Granularität der gewonnen Informationen ab. In der Praxis verändern sich die Netzwerke und Rechnersysteme jedoch ständig, sodass die erforderlichen Messparameter dynamisch an die Realität angepasst werden müssten. Dazu hat der IT-Manager normalerweise nicht die Zeit und das erforderliche Wissen. Aus diesem Grund müssen in einem funktionierenden System, sowohl die objektiven wie auch die benutzerorientierten subjektiven Kriterien, beobachtet und miteinander in Bezug gesetzt werden.
Test der aktiven Pfade
Die meiner Meinung nach beste Form des aktiven Tests von Übertragungspfaden umfasst eine den kompletten Zyklus eines Anrufs. Hierzu gehört die Leistungsmessung beim Anrufaufbau. Dabei werden vom Testsystem reale Anrufe (auf Basis genormter Gespräche) durchgeführt und alle Abweichungen von den Normen dokumentiert und bewertet.
Das Messverfahren Perceptual-Objective-Listening-Quality-Analysis (POLQA) ist der Nachfolger des PESQ-Algorithmus. Das neue Messverfahren basiert auf dem Standard ITU-T P.863. Der neue Algorithmus wurde zur Qualitätsprüfung von Sprachverbindungen entwickelt und eignet sich sowohl für die schmalbandige (300 – 3.400 Hz) als auch für die breitbandige (50 – 14.000 Hz) Untersuchung der übermittelten Sprachsignale.
Durch die Einbeziehung von Netzübergängen und Sprachcodeumsetzungen lassen sich die Ursachen für die im Netz entstandenen Übertragungsprobleme ermitteln:
- Schlechte Verbindungen als Verursacher von Paketfehlern im LAN und im WAN: Diese Probleme treten zu bestimmten Tageszeiten aufgrund von hohen Lasten auf. Wird auf einer WAN-Verbindung dieser Fehler kontinuierlich nachgewiesen, kann es sich um einen Duplex-Mismatch handeln.
- Falsch konfigurierte QoS-Parameter: Netzüberlasten treten meist spontan auf und die Paketverluste sind oft auf Pufferüberläufe in den Routern oder Switches zurückzuführen. In den meisten Fällen deuten solche Fehler auf falsch konfigurierte oder fehlende QoS-Mechanismen hin.
- Vorübergehende Netzwerkprobleme: Das Flattern von Link hat oft seine Ursachen in Umschaltproblemen der Routing-Mechanismen (Layer 3) oder in nicht funktionierenden Schleifenunterdrückungsmaßnahmen in den Switches (Layer 2) zu finden. Die Paketverluste entstehen, wenn kein gültiger Pfad zum Transport der Daten zur Verfügung steht.
- Gateway-Probleme: Durch das Umkodieren von Codecs kann es zu einer Verschlechterung der Sprachqualität kommen. In seltenen Fällen führen auch die Überlastung einer Software-basierten MCU oder Probleme mit dem digitalen Signalprozessor (DSP) zu Paketverlusten.
Telekommunikationsnetzwerke bestehen heute aus einer Mischung verschiedenster Techniken, von alten TDM bzw. Analogleitungen angefangen, bis hin zu modernsten VoIP-Strukturen.
Aufgrund dessen hat die Sprachübermittlung von Sender zu Empfänger einen komplexen Weg voller möglicher Hindernisse zurückzulegen. Daraus ergibt sich die Schwierigkeit, dass die Überwachungsmethoden dem jeweils vorliegenden Netz angepasst werden müssen, beispielsweise können IP-Messungen nur IP-Strecken beurteilen, TDM-Messungen nur TDM-Strecken.
Von äußerster Wichtigkeit ist es insbesondere, die End-to-End-Strecken, d.h. von Sender zu Empfänger, zu beurteilen, auch wenn die zu transportierenden Sprachpakete über verschiedene Techniken geleitet werden. Hierbei muss bei jedem Übergang in eine andere Technik eine Wandlung der Sprache erfolgen, damit diese auch im nächsten Medium störungsfrei transportiert werden kann. Diese Wandlungen sind schwierig zu messen, da sie in einem Gateway vorgenommen werden.
PESQ bzw. die Weiterentwicklung POLQA sind weltweit anerkannte ITU-Standards zur Messung der Sprachqualität anhand einer Referenzdatei. Diese Messungen sind in der Lage, die obengenannten Schwierigkeiten zu berücksichtigen und alle Netzübergänge in einer Verbindung mit zu berücksichtigen. Bei einer Sprachreferenz, die vom Sender zum Empfänger gesendet wird, werden alle in der Strecke vorkommenden Komponenten verwendet. Die Auswirkungen der jeweiligen Strecken auf die zu transportierende Sprachpakete werden beim Empfänger aufgezeichnet und können somit mit der Referenz verglichen werden. In der Praxis wird bei einer solchen Messung das Sprachsignal beim Empfänger „geloopt“, also gespiegelt, um auch den Rückkanal messen zu können.
Durch die aktive Simulation von Gesprächen werden Fehler an den Netzübergängen und auch in den Sprachdaten erkannt. Diese gemessene Ende-zu-Ende-Qualität spiegelt die Wahrnehmung des Endanwenders (Quality of Experience) wider.
#Netzpalaver
