QoS für Voice & Video im Telekommunikationsnetz ist kein einzelnes Feature, sondern ein durchgängiges Referenzframework aus Klassenmodell, Markierungsdisziplin, Engpasskontrolle, Interconnect-Policies und messbarer QoE. In Carrier-Umgebungen entsteht Qualität nicht dadurch, dass „irgendwo eine Priority-Queue“ existiert, sondern dadurch, dass Echtzeitpfade end-to-end deterministisch bleiben: vom Endgerät über RAN und User Plane, durch Transport und Core, bis hin zu IMS/Service-Edges und Carrier Interconnects. Dabei sind Voice und Video technisch unterschiedlich: Voice ist extrem jitter- und loss-sensitiv und benötigt eine kleine, stark geschützte Low-Latency-Behandlung. Video ist variabler, oft ABR-getrieben (Adaptive Bitrate) und benötigt eine hohe Priorität mit klaren Limits, damit es Voice nicht verdrängt. Zusätzlich kommen Telco-spezifische Anforderungen hinzu: Multi-Service-Aggregation, HQoS pro Subscriber/Service/Slice, Schutzumschaltungen (FRR), Multi-Vendor-Interop, Missbrauchsschutz gegen falsches Marking und ein Betrieb, der Qualität in KPIs und Evidence Packs nachweisen kann. Dieses Referenzframework beschreibt, wie Sie QoS für Voice & Video im Telekommunikationsnetz konsistent designen, implementieren und betreiben – mit Fokus auf Experten-Gates, skalierbare Policies und eine Beweiskette aus Telemetry, Counters und QoE.
Referenzframework: Die sechs Ebenen von Carrier-Grade QoS
Ein belastbares Framework lässt sich in sechs Ebenen gliedern. Jede Ebene ist notwendig, keine ist allein ausreichend. Der Vorteil dieser Struktur: Sie können Designs reviewen, Audits durchführen und Troubleshooting systematisch durchführen, ohne sich in Vendor-Syntax zu verlieren.
- Service-Intent: Welche QoE-Ziele gelten für Voice und Video (Delay/Jitter/Loss, Setup-Zeit, MOS/Freeze-Rate)?
- Traffic-Klassen: Welche logischen Klassen existieren, und was gehört hinein (Audio, Video, Signalisierung, Best Effort, Bulk)?
- Markierung und Trust: Wo wird markiert, wo wird trusted, wo wird normalisiert (Missmarking/Missbrauch verhindern)?
- Engpasskontrolle: Wo entstehen Congestion Domains, wo sitzt Shaping, wie werden Queues dimensioniert?
- Interworking & Interconnect: DSCP/CoS/MPLS-TC/5QI-Mapping, Provider-Übergaben, Policer-Profile.
- Observability & Lifecycle: Telemetry, Counter Reports, QoE-Korrelation, Tests, Canary, Rezertifizierung.
Domänenmodell: RAN → Transport → Core → Service Edge → Interconnect
Telco-QoS ist domänenübergreifend. Ein Experte betrachtet deshalb nicht „ein Gerät“, sondern Pfade. Voice/Video sind End-to-End-Dienste, deren Qualität durch die schlechteste Congestion Domain bestimmt wird. Für das Framework empfiehlt sich ein explizites Domänenmodell, das sowohl technische Mechaniken als auch Ownership abbildet.
- RAN: Scheduling und Ressourcenallokation; Funk ist ein geteiltes Medium, QoS ist airtime-/resource-getrieben.
- Transport (Backhaul/Midhaul/Metro/Core): IP/MPLS/SR/Ethernet mit Queues, Shaping, HQoS, FRR; hier entstehen viele Engpässe durch Aggregation.
- User Plane/Core: UPF/PGW/SGW-nahe Pfade, Service Chaining, ggf. Virtualisierung; CPU/vSwitch kann Jitter erzeugen.
- Service Edge/IMS: SBC, Media Anchors, Transcoding, Recording, Lawful Intercept; PPS- und Crypto-Headroom sind oft limitierend.
- Interconnect: Peering/Transit/IPX/Partnernetze; Markierungsrealität und Policer-Profile sind produktabhängig.
Klassenmodell für Voice & Video: robust, klein, skalierbar
Carrier-Grade QoS gewinnt durch wenige, robuste Klassen mit klarer Semantik. Zu viele Klassen erhöhen Drift-Risiko und erschweren TE, Monitoring und Compliance. Ein praxistaugliches Modell für Voice & Video umfasst typischerweise fünf bis sechs Klassen, die sich in RAN-/Core-/Transport-/Interconnect-Domänen abbilden lassen.
- VOICE/AUDIO: RTP/SRTP Audio, VoLTE/VoNR Medien; streng priorisiert, klein, begrenzt.
- VIDEO/MEDIA: interaktives Video, UCaaS/RTC Medien, ggf. Screenshare (optional separierbar); hohe Priorität, limitiert.
- SIGNAL/CONTROL: SIP/IMS Signalisierung, DTLS/ICE, Steuerflüsse; stabil, geringe Bandbreite, hohe Bedeutung.
- CRITICAL DATA: geschäfts- oder netzkritische Daten (optional), bevorzugt aber nicht strict.
- BEST EFFORT: Standarddatenverkehr.
- BULK/BACKGROUND: Updates, Backups, große Transfers; gedrosselt, opferbar.
Markierungs- und Interworking-Framework: DSCP, CoS, MPLS TC, WMM, 5QI
Der Kern jeder QoS-Architektur ist eine Source-of-Truth-Mapping-Tabelle, die Markierungen domänenübergreifend konsistent macht. In Telco-Umgebungen treffen häufig mehrere Markierungswelten aufeinander: 5QI/QFI in 5G, DSCP im IP, MPLS Traffic Class im Backbone, CoS an Ethernet-Übergaben, WMM im WLAN. Ein Referenzframework verlangt daher eine eindeutige Übersetzungskette pro Domänengrenze und klare Regeln, welche Markierung maßgeblich ist.
- Domänenübergang RAN/Core → Transport: QoS Flow/5QI/QFI bzw. QCI wird in DSCP/MPLS-TC übersetzt (Intent-zu-Klasse, nicht 1:1 jedes Identifier).
- IP ↔ MPLS: DSCP wird konsistent in MPLS-TC gemappt und zurück; keine „Klassen-Sprünge“ im Core.
- Ethernet-Übergaben: CoS wird nur in definierter Whitelist akzeptiert; sonst Normalisierung.
- WLAN (falls VoWLAN): DSCP→WMM muss Voice in WMM Voice und Video in WMM Video abbilden.
Trust Boundary und Missbrauchsschutz: Provider-Realität abbilden
Telco-Netze müssen Marking-Missbrauch verhindern, sonst werden Premiumklassen wertlos. Gleichzeitig darf zu aggressive Normalisierung echte Echtzeit beschädigen. Das Framework definiert daher Trust Boundaries an den richtigen Stellen: an kontrollierten Service Edges (SBC/UPF), an Provider-UNIs/NNIs, an Access-Edges und an Interconnects. Trusted wird nur, was kontrolliert ist. Alles andere wird auf ein erlaubtes Set umgeschrieben.
- Whitelist-Markierung: nur definierte DSCP/TC/CoS-Werte werden akzeptiert und weitergegeben.
- Re-Marking statt Blind-Trust: Markierungen werden deterministisch gesetzt (z. B. anhand Service/VRF/Slice), nicht zufällig gelöscht.
- Premium-Guardrails: Premiumklassen sind begrenzt; Überbuchung führt zu Re-Marking oder kontrollierten Drops außerhalb von Voice.
- Default/Unmatched Monitoring: Drift wird sichtbar gemacht, bevor QoE leidet.
Congestion Domains: QoS dort, wo Bandbreite knapp wird
Im Telco-Netz entstehen Engpässe selten im „großen Core“, sondern in Aggregationen, PoP-Uplinks, Access-Edges, Interconnects und in Service Chains. Das Framework fordert deshalb explizite Congestion Domains: definierte Orte, an denen Queueing entstehen darf und gemessen wird. QoS ohne Congestion-Domain-Modell ist nicht deterministisch, weil Congestion sonst in Black-Box-Buffern (CPE/Provider/ASIC-Pools) entsteht.
- Backhaul/Midhaul Aggregation: viele Sites auf wenige Uplinks; Microbursts sind typisch.
- Metro/PoP-Uplinks: Übergänge Metro→Core/DC sind häufige Engpässe, besonders im Schutzfall.
- Interconnect/Peering: Kapazitätsgrenzen und Produktprofile (CIR/PIR) bestimmen Drops/Delay.
- Service Edge: SBC/Firewall/DPI kann Processing-Engpass sein (PPS/CPU/Crypto).
Shaping-Strategie: Congestion kontrollieren, nicht nur priorisieren
Shaping ist in Carrier-Grade Designs ein Pflichtbaustein, weil es Congestion in kontrollierte Queues holt. Ohne Shaping entstehen Delay-Spitzen und Drops häufig außerhalb der eigenen Steuerbarkeit. Das Framework empfiehlt Shaping an Übergaben und Engpässen, insbesondere vor Policern und an Egress-Links mit variabler Realrate. Wichtig ist Realrate-Shaping inklusive Overhead (Tunnels, VLAN, PPPoE, Encapsulation), sonst wandert Congestion wieder in unerwünschte Puffer.
- Pre-Policer Shaping: vor rate-limited Hand-offs shapen, um Policer Drops zu vermeiden.
- Realrate statt Vertragsrate: Shaper knapp unter effektiver Nutzrate; Overhead explizit einrechnen.
- Hierarchisches Shaping: Service/Slice/Subscriber-Level begrenzen, darunter Klassen priorisieren (HQoS).
Queueing und Scheduling: Voice schützen, Video führen
Die Scheduling-Regeln im Framework sind bewusst konservativ: Voice/Audio ist strikt priorisiert, aber begrenzt. Video/Media ist hoch priorisiert, aber nicht unlimitiert. Control/Signal erhält Schutz, damit Setup und Steuerung nicht kollabieren. Bulk wird gedrosselt, damit es Peaks nicht in Echtzeitklassen drückt. Diese Regeln sind herstellerunabhängig und lassen sich in den meisten Plattformen als Intent umsetzen.
- Strict Priority nur für Voice: klein dimensioniert und mit Ceiling versehen, um Starvation zu verhindern.
- Video als High Priority mit Limits: Mindest-/Max-Anteile definieren; Video niemals in die Voice-LLQ.
- Signal/Control separat: geringe Bandbreite, hohe Wichtigkeit; stabil hält es Call Setup und Reconnects.
- BE/Bulk Drop-Strategie: Best Effort und Bulk tragen Degradation; Echtzeit bleibt geschützt.
HQoS Patterns: Subscriber-, Service- und Slice-Isolation
In Telco-Netzen ist HQoS oft der entscheidende Unterschied zwischen „QoS pro Link“ und „QoS als Service“. HQoS ermöglicht Isolation: Ein einzelner Subscriber, ein Slice oder ein Service darf nicht die Premiumklassen für alle dominieren. Das Framework sieht daher Hierarchien vor: oben ein Budget pro Subscriber/Service/Slice, darunter die Klassen. So bleibt QoS fair und planbar, auch wenn viele Kunden gleichzeitig aktiv sind.
- Per-Subscriber HQoS: Gesamtbudget pro Anschluss, darunter Voice/Video/BE/Bulk; schützt andere Subscriber.
- Per-Service HQoS: z. B. IMS/Voice-Service separiert von eMBB/Internet; verhindert Verdrängung.
- Per-Slice HQoS (5G): Slice-Level Shaping plus Class-Level Scheduling; Mapping von 5QI-Gruppen auf Transportklassen.
Class-aware Traffic Engineering: Pfade sind Teil von QoS
QoS regelt, wie Pakete bei Engpässen behandelt werden. TE regelt, welche Engpässe überhaupt geteilt werden. Ein Expertenframework kombiniert beides: Echtzeitklassen sollen Pfade mit niedriger Latenz und geringer Varianz bevorzugen, Bulk darf auf „günstigere“ oder längere Pfade ausweichen. In SR/MPLS/ECMP-Umgebungen ist das besonders relevant, weil Pfadwechsel und FRR die QoS-Wirkung sonst unvorhersehbar machen.
- Latency-/Jitter-aware Pfadwahl: Echtzeit meidet Links mit hoher Queue Delay 99p.
- Congestion Avoidance: TE berücksichtigt per-class Telemetry (Drops/Delay) statt nur Linkutilization.
- Failure-Mode Konsistenz: Schutzpfade müssen dieselbe QoS-Semantik und Queue-Profile tragen.
IMS/Service Edge Spezifika: SBC, Transcoding, Recording, Media Anchors
Voice & Video im Telco-Netz ist oft service-gekoppelt: SBCs terminieren Sessions, Media wird geankert, Transcoding oder Recording erzeugt zusätzliche Flows und PPS. Diese Komponenten sind QoS-kritisch, weil sie als Engpass wirken können, ohne dass Linkauslastung hoch ist. Das Framework fordert daher: Echtzeitpfade in Service Chains kurz halten, Processing-Headroom planen, DSCP Preservation/Re-Marking deterministisch definieren und Telemetry vor/nach diesen Knoten bereitstellen.
- PPS-Headroom: kleine Pakete (RTP) erzeugen hohe PPS; Kapazitätsplanung darf nicht nur Mbit/s betrachten.
- Crypto-/Session-Scale: SRTP/TLS/DTLS und stateful Processing können Jitter erzeugen.
- Zusatzflows: Recording/Transcoding/Analytics müssen in Klassenmodell und HQoS berücksichtigt werden.
Interconnect-Framework: Produktprofile, Policer und Beweisbarkeit
An Interconnects entscheidet sich, ob QoS-Intents über Domänen hinweg wirken. Das Framework trennt klar zwischen Best Effort (oft DSCP-neutralisiert) und QoS-fähigen Produkten (z. B. Carrier Ethernet/MPLS/IPX mit definierten Klassen). Für QoS-fähige Übergaben sind Policer-Profile üblich, deshalb ist pre-police Shaping entscheidend. Außerdem muss die Evidence-Strategie klar sein: per-class Counters und Drop Reasons am Übergabepunkt sind die wichtigsten Beweise gegenüber Partnern.
- Vertragliche Klassen: definieren, welche Markierungen/Klassen akzeptiert werden und welche CIR/PIR gelten.
- Pre-Policer Shaping: schützt Premiumklassen vor harten Policer Drops.
- Interconnect Monitoring: per-class Delay/Drops/Reasons als SLA- und Troubleshooting-Evidence.
Observability: QoS muss in Peaks bewiesen werden
Carrier-Grade QoE entsteht nicht durch Durchschnittswerte, sondern durch Kontrolle von Peaks. Das Framework verlangt daher Perzentile (95p/99p) für Queue Delay, Peak Queue Depth als Microburst-Indikator und Drop Reasons zur schnellen Root Cause. Ergänzend müssen QoE-KPIs verfügbar sein: RTP Jitter/Loss, MOS-Trends, Setup Times, Video Freeze/Downshift (bei ABR). Entscheidend ist die Korrelation: QoE kippt selten ohne ein mechanisches Signal, wenn die Messpunkte richtig gewählt sind.
- Queue Delay 99p: Voice und Video an Congestion Domains (Egress) als Frühwarnsignal.
- Per-Class Drops: Drops in Voice/Low-Latency sind Incident; Drops in BE/Bulk sind Kontext.
- Drop Reasons: Tail Drop vs. Policer vs. Buffer Exhaustion vs. Policy Drop.
- Shaper Headroom: zeigt, ob Kapazität dauerhaft knapp ist oder nur peak-bedingt.
- QoE KPIs: RTP/RTCP Jitter/Loss/MOS, Call Setup Times, Video QoE Events (Freeze/Downshift).
Validation: Lab-Tests, Congestion-Proofs und Failure-Mode Checks
Ein Expertenframework ist nur dann operationalisierbar, wenn es getestet werden kann. Das gilt besonders für Änderungen an Mapping-Tabellen, Shaper-Raten, TE-Policies oder Interconnect-Profilen. Das Framework fordert deshalb eine minimalistische, aber harte Validation-Suite: mechanische Checks (Mapping/Attachment/DSCP Preservation), Congestion-Proof (Bulk saturiert Engpass, Voice bleibt stabil) und Failure-Mode Tests (FRR/Reroute), die sicherstellen, dass QoS im Schutzfall nicht regressiert.
- Mechanik: Classifier-Hits, DSCP/TC Interworking, Default/Unmatched, Policy Attachment am richtigen Egress.
- Congestion-Proof: Voice Loss nahe 0, Voice Delay/Jitter bleibt stabil, Video degradiert kontrolliert.
- Failure-Mode: Pfadwechsel darf QoS-Semantik nicht ändern; Delay/Drops dürfen nicht steigen.
Lifecycle und Standards: Templates, Review-Gates, Canary, Rezertifizierung
Carrier-Grade QoS ist Prozessdisziplin. Das Framework verlangt daher: standardisierte Templates nach Rollen, einheitliches Naming, Review-Gates als „Never-Event“-Filter (z. B. Policer auf Voice, unlimitierte LLQ, Video in Voice-Queue), progressive Rollouts (Canary) und regelmäßige Rezertifizierung. Damit wird QoS drift-resistent und auditfähig.
- Templates: Rollenprofile (Access/Aggregation/Metro/Core/Edge/Interconnect), versioniert.
- Review-Gates: Congestion Domains, Shaping, Mapping, Trust Boundary, Scheduling-Limits, Overlay/DSCP Copy.
- Canary: progressive Ausweitung mit Stop-Regeln (Voice Drops, Policer Drops, Delay 99p).
- Rezertifizierung: periodisch oder change-getrieben; Evidence Packs aus Config Exports und Counter Reports.
Experten-Checkliste als Referenz: Was in jedem Telco-QoS-Design explizit sein muss
- Service-Intent: definierte QoE-Ziele für Voice und Video (inkl. Perzentile und Peak-Zeitfenster).
- Klassenmodell: wenige Klassen mit klarer Semantik; Audio strikt geschützt, Video geführt und limitiert.
- Mapping-Source-of-Truth: DSCP/CoS/WMM/MPLS-TC/5QI Interworking, versioniert und drift-geprüft.
- Trust Boundary: Whitelist/Re-Marking, Missmarking-Schutz, Default/Unmatched Monitoring.
- Shaping Points: Realrate-Shaping, pre-police Shaping an Übergaben, HQoS-Hierarchien.
- Queueing/Scheduling: Voice strict (begrenzt), Video high-priority (limitiert), Control separat, Bulk gedrosselt.
- TE/Resilienz: class-aware Pfadwahl, FRR-Konsistenz, Failure-Mode Validierung.
- Service Edge: SBC/IMS/Media-Funktionen als Engpässe behandeln (PPS/CPU/Crypto), DSCP Handling deterministisch.
- Interconnect: Produktprofile, Policer/Shape-Strategie, per-class Evidence am Übergabepunkt.
- Observability: Queue Delay/Depth 99p, Per-Class Drops, Drop Reasons, Shaper-Headroom plus QoE-Korrelation.
