Site icon bintorosoft.com

QoS-Tests vor dem Rollout: Abnahmeplan für Voice & Video

Red Snapper

QoS-Tests vor dem Rollout sind der Moment, in dem aus einem QoS-Design ein belastbarer Service wird – oder eben nicht. Gerade Voice und Video sind unforgiving: Ein einzelnes QoS-Loch an einer Netzgrenze, ein falsches DSCP↔CoS↔TC-Mapping, ein zu hart eingestellter Policer oder eine fehlende Shaping-Stufe kann dazu führen, dass Sprache knackt, Silben fehlen oder Videokonferenzen ruckeln, obwohl „QoS doch konfiguriert ist“. Deshalb braucht es vor dem Go-live einen strukturierten Abnahmeplan, der nicht nur Konfigurationen prüft, sondern die Wirkung unter realistischen Bedingungen verifiziert: end-to-end, segmentiert (Access–Metro–Core–NNI), pro Serviceklasse (Voice/EF, Video/AF, Signaling/Control, Best Effort) und mit Messmethoden, die Perzentile und Sekundenpeaks sichtbar machen. Ein professioneller Abnahmeplan beantwortet drei Fragen eindeutig: Greifen die Klassen wirklich (Classify-Hits)? Sind die Pfade und Engpässe so dimensioniert, dass Echtzeit auch in Busy Hour stabil bleibt (Queueing Delay, Drops, Shaper/Policer Events)? Und ist die Nutzerqualität nachweisbar gut (MOS/R-Faktor, RTP Jitter/Loss, Video Freeze/Bitrate Switching)? Dieser Artikel liefert einen praxistauglichen Test- und Abnahmeplan für Telcos und größere Netze, inklusive Testfällen, Messkriterien, Akzeptanzschwellen als Richtwerte sowie typischen Fallstricken, die Sie vor dem Rollout unbedingt finden sollten.

Warum ein Abnahmeplan für QoS mehr ist als ein „Ping-Test“

Viele Rollouts scheitern, weil man „Connectivity“ mit „Quality“ verwechselt. Ping und Traceroute zeigen, dass ein Pfad existiert. Sie zeigen nicht, ob Voice in EF/LLQ wirklich bevorzugt wird, ob Video in AF stabile Throughput-Fenster bekommt oder ob Bufferbloat im Upstream Jitter erzeugt. QoS-Abnahme muss daher drei Ebenen abdecken:

Ein Abnahmeplan muss deshalb messbar, reproduzierbar und lastnah sein – sonst ist er keine Abnahme, sondern eine Hoffnung.

Vorbereitung: Testumfang, Rollen und Abnahmekriterien definieren

Bevor Sie Tests starten, definieren Sie die Abnahme als Vertrag zwischen Engineering, Betrieb und ggf. Kunde/Produkt:

Wichtig: Akzeptanzkriterien sollten Perzentile und Peaks berücksichtigen. Ein „Durchschnitt“ reicht für Echtzeit nicht.

Testarchitektur: End-to-End messen und gleichzeitig segmentieren

Ein häufiger Fehler ist reine End-to-End-Messung. Dann wissen Sie zwar, dass es schlecht ist, aber nicht wo. Der Abnahmeplan sollte immer beides enthalten:

Segmentierung ist nicht nur Troubleshooting, sondern Abnahme: Sie prüfen, ob jedes Netzsegment seine Qualitätsbudgets einhält.

Messmethoden: Passive Telemetrie, aktive Probes und Service-KPIs kombinieren

Eine belastbare Abnahme nutzt mindestens zwei Perspektiven, idealerweise drei:

Die Kombination ist entscheidend: Probes finden den Effekt (Pfadqualität), Telemetrie erklärt die Ursache (Queue/Policer), Service-KPIs bestätigen die Nutzerwirkung.

Testfallgruppe 1: Markierung, Trust Boundary und Mapping verifizieren

Bevor Sie Lasttests machen, müssen Sie sicherstellen, dass Traffic korrekt markiert und klassifiziert wird. Diese Tests sind Pflicht, weil Mapping-Löcher später jede QoS-Wirkung zerstören.

Akzeptanzrichtwert: Klassen müssen plausible Classify-Hits zeigen, und es darf keine unerklärlichen DSCP-„Nullungen“ entlang des Pfads geben.

Testfallgruppe 2: Klassifizierung und Policy-Hits (Greifen die Klassen wirklich?)

Viele QoS-Probleme sind keine Queue-Probleme, sondern Match-Probleme. Deshalb ist „Hit-Verifikation“ ein eigener Abnahmeschritt:

Akzeptanzrichtwert: Keine Echtzeitklasse darf „0 Hits“ haben, wenn der synthetische Testtraffic gezielt in diese Klasse markiert wurde.

Testfallgruppe 3: Delay-, Jitter- und Loss-Abnahme pro Klasse (Active Probes)

Jetzt kommt die eigentliche Qualitätsmessung. Wichtig: Pro Klasse testen, nicht nur Best Effort. Ein praxisnaher Ansatz ist, pro Klasse einen kleinen, konstanten Probe-Stream zu senden.

Voice-Probe (EF) – dienstnaher Test

Video-Probe (AF) – bursttolerante Abnahme

Control-Probe

BE-Probe als Referenz

Testfallgruppe 4: Queueing- und Drop-Verhalten am Engpass (Passive Telemetrie)

Active Probes zeigen den Effekt. Telemetrie zeigt die Ursache. Für die Abnahme ist entscheidend, dass die Mechanik am Engpass wie geplant arbeitet:

Akzeptanzrichtwert: EF-Drops = 0. Wenn EF dropt, ist entweder Kapazität, Governance oder Limitierung falsch. Das ist kein „Tuning-Thema“, sondern ein Abnahmefehler.

Testfallgruppe 5: Lasttests – Overbooking, Microbursts und Busy-Hour-Simulation

QoS muss unter Last funktionieren. Ein Rollout ohne Lasttest ist bei Telco-Umgebungen riskant, weil viele Probleme erst in Busy Hour sichtbar werden. Lasttests sollten realistische Muster abbilden:

Akzeptanzrichtwert: Premium bleibt stabil, BE degradiert kontrolliert. „Kontrolliert“ bedeutet: keine extremen Delay-Peaks durch Bufferbloat und keine unkontrollierten Drop-Cluster, die sich auf Premium auswirken.

Testfallgruppe 6: Failover und Umschaltverhalten (FRR, Ring, ECMP-Rehash)

Viele Qualitätsprobleme treten nicht im Normalbetrieb auf, sondern bei Ereignissen: Link Down, Ring-Protect, FRR, Rehashing. Ein Abnahmeplan für Voice & Video sollte mindestens einen Umschalt-Test enthalten:

Akzeptanzrichtwert: Kurze, geringe Beeinträchtigung ist tolerierbar, aber EF-Drops sollten auch während Umschaltung möglichst bei 0 bleiben. Wenn Umschaltungen regelmäßig hörbare Aussetzer erzeugen, ist das Design nicht rollout-reif.

Testfallgruppe 7: Service-Abnahme mit echten Clients (UC/VoIP/Video)

Synthetische Tests sind stark, aber echte Clients sind die Realität. Eine Abnahme sollte daher einen kontrollierten „User Journey“-Test enthalten:

Ziel ist, dass die QoS-Mechanik nicht nur „schön“ aussieht, sondern dass die Nutzerqualität nachvollziehbar stabil ist – besonders unter gleichzeitiger Last.

Akzeptanzkriterien als Richtwerte: Was ist „gut genug“?

Jedes Netz hat eigene SLAs, daher sind absolute Zahlen immer kontextabhängig. Trotzdem sind klare Richtwerte hilfreich, um Diskussionen zu vermeiden. Für die Abnahme sollten Sie intern Grenzwerte definieren wie:

Wichtig: Nutzen Sie Perzentile und Sekundenfenster. Ein „durchschnittlich“ guter Wert ist für Echtzeit nicht ausreichend.

Dokumentation und Abnahmeprotokoll: Was am Ende vorliegen muss

Ein Abnahmeplan ist erst vollständig, wenn die Ergebnisse dokumentiert sind – nicht als „Text“, sondern als wiederholbares Protokoll:

So wird aus „wir haben getestet“ ein auditierbarer Nachweis – und die Abnahme lässt sich später bei Änderungen wiederholen.

Typische Fallstricke bei QoS-Abnahmen

Praxis-Blueprint: Abnahmeplan für Voice & Video vor dem Rollout

Häufige Fragen zur QoS-Abnahme

Reichen synthetische Tests aus, oder brauche ich echte Calls?

Synthetische Tests sind ideal, um Klassenwirkung und Pfadqualität reproduzierbar zu messen. Echte Calls sind wichtig, um die Nutzerwirkung (MOS, Jitter-Buffer-Verhalten, Video Freeze) zu bestätigen. Für eine belastbare Abnahme sollten beide enthalten sein.

Warum ist „EF-Drops = 0“ so ein harter Abnahmepunkt?

Weil Drops in der Voiceklasse unmittelbar hörbar sind und meist auf grundlegende Probleme hinweisen: Kapazität im Engpass, Premium-Inflation, falsches LLQ-Limit oder Policer-Drops. Wenn EF dropt, ist das Design oder die Governanceannahme verletzt.

Wie verhindere ich, dass die Abnahme gut aussieht, aber nach dem Rollout in Busy Hour Probleme auftreten?

Indem Sie Busy-Hour-ähnliche Lastmuster testen oder zumindest gezielt Microburst- und Uplink-Stress-Tests durchführen und die Verifikation auf Perzentile und Sekundenfenster ausrichten. Zusätzlich sollten Canary-Rollouts mit klaren Post-Change-Verifikationschecks in der nächsten Busy Hour Bestandteil des Rolloutprozesses sein.

Exit mobile version