Ist Ihr Netzwerk bereit für Voice, Video und Unified Communications? Qualitativ hochwertige Lieferung für Voice-, Video- und UC-Dienste kommt nicht von allein. Um Spitzenleistungen zu gewährleisten, ist es wichtig, die Umsetzung zu planen, einschließlich: Stammdatenerfassung der gegenwärtigen Netzwerkleistung, Validierung der Anbieter-SLAs, Messung der Datenverkehr-Schwellenwerte, Validierung der QoS-Einstellungen und Lösung von zugrunde liegenden Problemen, bevor sie die Benutzer beeinträchtigen.

Eine Netzwerkbewertung zur Vorbereitung von Voice-, Video- und UC-Datenverkehr erfordert mehr als Durchsatztests und Kapazitätsplanung auf dem Netzwerk. Beispielsweise generieren die meisten VoIP-Anrufe unter 100 Kbit/s pro Anruf, daher prüft ein Test, ob das Netzwerk End-to-End einen hohen Durchsatz aufrecht erhalten kann, nicht die speziellen Anforderungen von Voice. Statt dessen haben Metriken wie Paketverlust, Jitter und Netzwerkverzögerung erhebliche Auswirkungen auf die Qualität und müssen während der Netzwerkbewertung geprüft werden. Normaler Netzwerkverkehr konkurriert mit diesen Diensten um Bandbreite und Priorität und erfordert eine solide QoS-Konfiguration über das gesamte Netzwerk. Testen und Validieren von QoS-Einstellungen bei simuliertem Datenverkehr sollte ein Teil der Netzwerk-Beurteilung sein.

Sobald das Netzwerk auf Probleme geprüft wurde, die die Leistung von Voice und Video beeinträchtigen, sollte eine VoIP-Prüfung, die Datenverkehr-Streams simuliert, ausgeführt und die Netzwerkfähigkeit komplett ausgewertet werden. Dieser Test bringt auch andere unerwartete Probleme zutage, die sich auf diese Dienste auswirken, bevor sie bereitgestellt werden. Diese Einschätzung gilt im Prinzip ebenfalls für Video und UC und können angepasst werden, um diese Dienste zu simulieren.

Für diese Aufgabe benötigen die Techniker ein Tool (z. B. das OptiView XG), das die Datenverkehrsbelastung von mehreren Voice- und Video-Streams zu entfernten Endpunkten im gesamten Netzwerk simulieren und gleichzeitig die Verkehrsleistung in Bezug auf Verlust, Verzögerung, Jitter und Durchsatz messen kann. Der Test sollte die tatsächliche Leistung des Test-Datenverkehrs mit konfigurierten Schwellenwerten vergleichen, um eine einfache Erfolgs-/Fehlschlag-Ergebniszusammenfassung bereitzustellen. Entsprechende Schwellenwerte können mit Hilfe der VoIP-Systemanbieter ermittelt werden, die normalerweise empfohlene Metriken für optimale System-Performance und Anruf-Qualität angeben.

Das Testen der Netzwerkbereitschaft für Voice und Video unterscheidet sich vom Standard-Durchsatztest auf dem Netzwerk. Jeder Aufruf generiert eine relativ geringe Menge an Bandbreite, je nach verwendetem Codec. Die nachfolgende Tabelle gibt die ungefähre verwendete Ethernet-Bandbreite für jedes Codec und die Anzahl der gleichzeitigen Anrufe an.

Anhand des Performance-Prüftools wird ein Datenverkehrs-Stream konfiguriert, der diese Größenordnungen an Anruflasten simuliert. Der Datenverkehr kann mit einer Paketgröße von etwa 200 Bytes konfiguriert werden, was genau einem echten RTP-Paket entspricht. Im Test können Einstellungen für QoS konfiguriert werden, die dann lokale Geräte und Service-Provider-Infrastruktur validieren und sicherstellen, dass sie durchgehend korrekt gehandhabt werden.

Neben der Simulation von RTP-Streams sollten zusätzliche Datenverkehrs-Streams durch den Leistungstest aufgelegt werden, um Verbindungsaufbau-Datenverkehr zu simulieren. Wenn Paketverlust während des Verbindungsaufbaus auftritt, wird der Aufruf u. U. überhaupt nicht erstellt. Die Schwellenwerte in diesem einzelnen Strom des Tests können so konfiguriert werden, dass sie eine höhere Verlustempfindlichkeit aufweisen. Ein dritter Strom sollte konfiguriert werden, um Hintergrund-Benutzerdatenverkehr zu simulieren, und damit das Netzwerk auf normale Verwendungsniveaus zu bringen. Dadurch wird ein realistischeres Verkehrsaufkommen zur Messung der simulierten Voice- und Video-Streams erreicht. Das Prüfen auf diese Art gibt den Ingenieuren ein klares Bild, wie der wahre Applikations-Datenverkehr ablaufen wird, sobald die Anwendung bereitgestellt wird, während gleichzeitig Probleme aufgezeigt werden, die Leistung beeinträchtigen könnten.