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:
- Semantik: Markierungen und Klassifizierung stimmen (DSCP/CoS/MPLS-TC, Trust Boundary, Remarking).
- Mechanik: Scheduler/Queues/Shaping/Policing verhalten sich wie geplant (Queueing Delay, Drops, Limits, Weights).
- Wirkung: Die Dienstqualität ist messbar gut (MOS, Jitter, Loss, Video-QoE) – auch unter Last und bei Ereignissen (Failover, ECMP-Rehash).
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:
- Scope: Welche Services werden abgenommen (VoIP/IMS, UC-Video, IPTV, WebRTC, SIP/Signaling)? Welche Standorte/PoPs/Peering-Edges?
- Messpunkte: Wo wird gemessen (Access Edge, Aggregation/Metro, Core, NNI/Peering, Zielnetz/Cloud Edge)?
- Testfenster: Lab/Preprod, Off-Peak, Busy Hour, geplante Failover-Events.
- Owner: Wer führt Tests aus, wer bewertet, wer entscheidet Go/No-Go?
- Akzeptanzkriterien: Welche Schwellen sind Mindestanforderung, welche sind Zielwerte?
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:
- End-to-End: Nutzererlebnis von A nach B (z. B. Standort → SBC/IMS → Ziel).
- Segmenttests: Access→Metro, Metro→Core, Core→NNI, NNI→Zielnetz, um Budgetverletzungen zu lokalisieren.
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:
- Active Probing: synthetische Messpakete (UDP/TWAMP/ähnlich) pro Klasse, um Delay/Jitter/Loss unabhängig vom Realtraffic zu messen.
- Passive QoS-Telemetrie: Queueing Delay/Depth, Drops pro Klasse, Policer/Shaper Events, Classify-Hits und DSCP-Verteilungen.
- Service-KPIs: MOS/R-Faktor, RTCP-Jitter/Loss, Video Freeze Events, Call Setup Times – die Nutzerrealität.
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.
- DSCP-Integrität: Ingress vs. Egress DSCP-Verteilung prüfen – bleibt EF/AF/Control erhalten?
- CoS/802.1p: In Metro/Access prüfen, ob PCP korrekt gesetzt und gemappt wird.
- MPLS-TC/EXP: im Core prüfen, ob DSCP→TC und TC→Queue konsistent ist und am Egress korrekt zurückgemappt wird.
- Inner/Outer: bei VPN/Tunneln prüfen, ob Outer-DSCP korrekt gesetzt wird und Underlay-QoS wirkt.
- Trust Boundary: prüfen, ob Kundenmarkierungen korrekt behandelt werden (Whitelist/Remarking) und Premium-Inflation verhindert wird.
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:
- Classify-Hits pro Klasse: Voice/EF, Video/AF, Control, BE müssen Treffer zeigen, wenn entsprechender Traffic gesendet wird.
- IPv4/IPv6 Parität: Policies müssen für IPv6 Traffic Class genauso greifen wie für IPv4 DSCP.
- Signaling vs. Media: SIP/Control und RTP/Media sollten sauber getrennt priorisiert werden, sofern das Design das vorsieht.
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
- Profil: UDP-Probe mit voice-ähnlichem Paketabstand (z. B. 20 ms) und kleiner Paketgröße, DSCP EF.
- Messgrößen: One-Way Delay (wenn möglich), sonst RTT + Segmentierung; Jitter; Loss; Perzentile.
- Akzeptanzrichtwerte: sehr niedrige Loss-Rate, keine Loss-Cluster; Jitter stabil; 95/99-Perzentile im Rahmen des internen Budgets.
Video-Probe (AF) – bursttolerante Abnahme
- Profil: AF-markierte UDP-Probe oder synthetischer Video-ähnlicher Stream mit moderatem Durchsatzfenster; optional mit Bursts (Keyframe-Simulation).
- Messgrößen: Loss-Cluster, Jitter-Perzentile, Durchsatzstabilität (Fenster), Queueing Indikatoren.
- Akzeptanzrichtwerte: keine starken Drop-Cluster, stabile Perzentile; degradierendes Verhalten darf auftreten, aber kontrolliert und ohne Voice zu beeinträchtigen.
Control-Probe
- Profil: kleine Pakete, hoher Prioritäts-DSCP, niedrige Rate.
- Messgrößen: Delay-Spitzen und Verlust in Congestion-Situationen.
- Akzeptanzrichtwerte: Control darf nicht verhungern, besonders nicht während Lasttests und Umschaltereignissen.
BE-Probe als Referenz
- Profil: BE-markiert, um zu sehen, wie stark Best Effort bei Congestion degradiert.
- Ziel: sicherstellen, dass Premiumklassen geschützt sind und BE nicht Bufferbloat erzeugt (kontrollierte Queue-Limits).
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:
- Queueing Delay pro Klasse: 95/99-Perzentile und Peaks während Tests.
- Drops pro Klasse: EF-Drops sind No-Go; Video-Drop-Cluster müssen erklärbar und innerhalb des Designs sein.
- Scheduler Share: bekommt Video/BE die geplanten Gewichte, verhungert BE nicht dauerhaft?
- Shaper-Queueing: Shaping aktiv und korrekt dimensioniert; kein Dauerstau, der Premium spürbar erhöht.
- Policer Events: Exceed/Drop/Remarking – insbesondere Policer-Drops auf Echtzeit sind kritisch.
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:
- BE-Fülllast: Best Effort bis nahe Engpass, um die QoS-Schutzwirkung zu prüfen.
- Video-Bursts: burstiges Muster (z. B. kurze Durchsatzspitzen), um Drop-Cluster-Risiko zu testen.
- Uplink-Stress: Upstream ist häufig kritischer; testen Sie explizit uplinkseitige Congestion und Bufferbloat.
- Multi-Flow: mehrere parallele Streams, um Hashing/ECMP/LAG-Hotspots sichtbar zu machen.
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:
- Geplanter Link-Fail: kontrolliertes Umschalten, während EF/AF-Probes laufen.
- Messgrößen: Loss-Cluster während Umschaltung, Delay/Jitter Peaks, Reordering-Indikatoren.
- Telemetrie: Drops pro Klasse und Queueing Delay Peaks korrelieren.
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:
- VoIP-Calls: mehrere Calls parallel, inklusive Hold/Resume, DTMF, Codec-Wechsel (falls relevant).
- Videokonferenz: HD/Full-HD, Screen Sharing, Kamera an/aus, Teilnehmerwechsel.
- Messung: RTCP Jitter/Loss, MOS/R-Faktor, Freeze Events, Bitrate Switching, Setup Times.
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:
- Voice: EF-Drops = 0; Jitter stabil; keine Loss-Cluster; MOS/R-Faktor innerhalb definierter Mindestwerte.
- Video: keine massiven Drop-Cluster; Freeze Events selten; Bitrate Switching nicht dauerhaft; stabile Throughput-Fenster.
- Control: Setup Times stabil; keine Verhungersymptome in Congestion.
- BE: kontrollierte Degradation; keine extremen Delay-Peaks durch Bufferbloat.
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:
- Testmatrix: welche Tests, welche Pfade/Segmente, welche Klassen.
- Messdaten: Perzentile, Peaks, Drops, Classify-Hits, DSCP-Verteilungen.
- Abweichungen: klare Liste, ob sie akzeptiert, mitigiert oder als Blocker klassifiziert sind.
- Go/No-Go Kriterien: vordefiniert, nachvollziehbar, nicht „nach Gefühl“.
- Rollback-Plan: falls nach Rollout unerwartete Drift oder Busy-Hour-Probleme auftreten.
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
- Nur Off-Peak getestet: Busy-Hour-Probleme bleiben unsichtbar.
- Nur End-to-End getestet: Segmentverletzer werden nicht gefunden.
- Keine Klassenprobes: es wird nur BE getestet, während Voice/Video-Mappings ungetestet bleiben.
- Falsche Annahmen über DSCP: DSCP wird an Grenzen neutralisiert; QoS-Loch bleibt unerkannt.
- Zu grobe Messintervalle: Microbursts und Sekundenpeaks verschwinden in Mittelwerten.
- Keine Telemetrie-Korrelation: man sieht Symptome, aber nicht die Ursache (Queue/Policer).
Praxis-Blueprint: Abnahmeplan für Voice & Video vor dem Rollout
- Schritt 1: Scope und Pfade definieren, Messpunkte festlegen, Busy-Hour-Fenster bestimmen.
- Schritt 2: Markierung, Trust Boundary und Mappings end-to-end verifizieren (DSCP/CoS/TC, Inner/Outer).
- Schritt 3: Klassen-Hits testen (synthetisch pro Klasse), IPv4/IPv6 Parität prüfen.
- Schritt 4: Active Probes pro Klasse messen (EF/AF/Control/BE) mit Perzentilen und Sekundenfenstern.
- Schritt 5: Telemetrie am Engpass auswerten (Queueing Delay/Drops, Shaper/Policer Events, Scheduler Share).
- Schritt 6: Last- und Bursttests durchführen, insbesondere Upstream-Stress und Microburst-Muster.
- Schritt 7: Failover-/Umschalttests (FRR/Ring/ECMP-Rehash) mit laufenden Probes.
- Schritt 8: Real-Client Tests (VoIP/UC/Video) mit Service-KPIs und Korrelation zur QoS-Telemetrie.
- Schritt 9: Abnahmeprotokoll erstellen, Go/No-Go nach definierten Kriterien, Rollback-Plan finalisieren.
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.
