Eine QoS-Referenzarchitektur für Telcos ist dann wertvoll, wenn sie zwei Dinge gleichzeitig liefert: erstens ein klares, wiederholbares Beispiel-Design für Voice & Video end-to-end – von Access bis Core – und zweitens Regeln, die in der Realität funktionieren, also in Busy Hour, bei Failover, bei Vendor-Mixing und über Domänenübergänge hinweg. In der Praxis scheitert QoS selten am „Fehlen“ von Features, sondern an Inkonsistenzen: DSCP wird am Edge gesetzt, aber im Metro falsch in 802.1p gemappt. MPLS-TC/EXP wird im Core anders interpretiert als im Aggregationsnetz. Ein Tunnel (IPsec/SD-WAN/Overlay) verliert die Markierungen im Outer-Header, sodass das Underlay Echtzeit wie Best Effort behandelt. Oder die LLQ ist unlimitiert und wird durch Fehlmarkierung aufgeblasen – am Ende knackt Voice trotz Priorisierung. Eine Referenzarchitektur muss daher bewusst einfach sein, mit wenigen Klassen, klaren Trust Boundaries, standardisierten Mappings und messbaren Zielwerten. Genau das leistet dieses Beispiel: Es beschreibt ein praxistaugliches Telco-QoS-Design für Voice & Video, das sich über FTTH/DSL/HFC, Metro/Ethernet-Aggregation, IP/MPLS- oder SR-Core, Peering/Interconnect und Service-Edges (IMS/SBC, UC/Video) konsistent umsetzen lässt. Sie erhalten ein Klassenmodell, Beispiel-Mappings, Designregeln für Queueing/Shaping/Policing, sowie einen Abnahme- und Monitoring-Ansatz, um nachzuweisen, dass die Klassen wirklich greifen.
Architekturüberblick: Domänen und Engpässe im Telco-End-to-End-Pfad
Ein typischer Telco-Pfad für Voice & Video besteht aus mehreren Domänen, die jeweils eigene QoS-Mechaniken und Engpässe haben. Die Referenzarchitektur betrachtet folgende Rollen:
- Kundenkante (CPE/Access Edge): erste Trust Boundary, häufig rate-limitiert, Bufferbloat-Risiko im Upstream.
- Access (FTTH/DSL/HFC/Mobile Backhaul): Profilierung pro Kunde, Shared Medium, oft der erste harte Engpass.
- Metro/Aggregation (Ethernet, EVPN): Traffic-Aggregation, Mikrobursts, CoS/PCP-Queueing typisch.
- Core (IP/MPLS oder Segment Routing): TC/EXP-Queueing, große Kapazitäten, aber kritische NNI-/Core-Links.
- Service Edge: IMS/VoLTE/SBC, UC-Gateways, Media Relays, ggf. SASE/Firewall-Ketten.
- NNI/Peering/Interconnect: potenzielle Congestion-Zone, Markierungsneutralisierung möglich, klare Messgrenzen nötig.
Eine robuste QoS-Architektur priorisiert nicht „überall gleich“, sondern setzt dort an, wo Congestion entsteht: typischerweise am Egress der Engpass-Interfaces in Access/Metro/NNI und an rate-limitierten Übergängen.
Klassenmodell: Wenige Klassen, klare Semantik
Für Voice & Video end-to-end reichen in den meisten Telco-Designs vier bis fünf Klassen. Das reduziert Drift, erleichtert Mappings und macht Abnahme messbar:
- Voice Real-Time: Audio-Medien (RTP/SRTP), maximale Priorität über LLQ, aber immer mit hartem Limit.
- Control/Signaling: SIP/IMS-Signaling, DNS/AAA/Steuertraffic, hoch priorisiert gewichtet, keine LLQ nötig.
- Interactive Video: Video Calls/WebRTC/UC, gewichtet, bursttolerant, keine strict priority.
- Best Effort: Standarddatenverkehr.
- Background (optional): Updates/Backups, bewusst niedriger priorisiert.
Wichtig: Voice und Video dürfen nicht in einer gemeinsamen unlimitierten Priority-Queue landen. Video ist burstig und kann Voice verdrängen, wenn die Governance fehlt.
Markierungsstrategie: DSCP als „Sprache“, CoS und MPLS-TC als Transport
Die Referenzarchitektur nutzt DiffServ/DSCP als übergeordnete Semantik und mappt diese Semantik konsistent in L2 und MPLS/SR:
- IP-Ebene: DSCP ist die primäre Servicekennzeichnung (Voice, Control, Video, BE).
- Ethernet-Ebene: 802.1p CoS/PCP transportiert Priorität im Metro/Access (VLAN/Trunks).
- MPLS/SR-Ebene: MPLS Traffic Class (TC/EXP) transportiert QoS im Label-Switched Core.
Der wichtigste Grundsatz lautet: Jede Domäne darf intern andere Mechaniken nutzen, aber die Semantik muss end-to-end gleich bleiben. Deshalb braucht es feste Mappingtabellen.
Beispiel-Mapping: DSCP ↔ CoS/PCP ↔ MPLS-TC
Das folgende Beispiel zeigt ein konsistentes Mappingkonzept. Die konkreten Werte können je nach Anbieterstandard variieren; entscheidend ist die Konsistenz über alle Rollen.
- Voice Real-Time: DSCP EF → PCP hoch → MPLS-TC hoch
- Control/Signaling: DSCP CS/AF für Control → PCP mittel-hoch → MPLS-TC mittel-hoch
- Interactive Video: DSCP AF für Video → PCP mittel → MPLS-TC mittel
- Best Effort: DSCP BE → PCP niedrig → MPLS-TC niedrig
- Background: DSCP CS1/Low → PCP sehr niedrig → MPLS-TC sehr niedrig
Zusatzregel für Overlays/Tunnel (IPsec/SD-WAN/VXLAN): Der Outer-Header muss die passende Klasse tragen, sonst sieht das Underlay nur Best Effort. Inner/Outer-Strategie ist daher Teil der Referenzarchitektur.
Trust Boundary und Remarking: Premium-Inflation verhindern
End-to-end QoS ist im Telco-Betrieb nur stabil, wenn Markierungen kontrolliert sind. Deshalb wird die Trust Boundary in der Referenzarchitektur explizit an die Netzgrenze gelegt:
- Untrusted Default: Kundenseitige DSCP-Werte werden nicht blind übernommen.
- Conditional Trust: Markierungen werden akzeptiert, aber nur für definierte Werte und innerhalb profilierter Budgets pro Kunde/Service.
- Remarking statt Drops: Überschuss in Video/BE wird bevorzugt remarkt (z. B. Video→BE), statt hart gedroppt.
- Voice-Governance: EF/Voice wird nur aus kontrollierten Quellen zugelassen (Managed CPE, SBC/IMS, definierte Policies).
Diese Governance ist der wichtigste Schutz, damit LLQ für Voice nicht zur „Premium-Falle“ wird.
Queueing-Design: Scheduler, LLQ, Gewichte und Zeitbudgets
Die Referenzarchitektur setzt auf ein klares Scheduler-Modell, das in jeder Domäne gleich interpretiert werden kann:
- Voice: LLQ (strict priority) mit hartem Limit, sehr kleines Queueing-Zeitbudget.
- Control: gewichtete Klasse mit hoher Priorität, kleine Queue-Limits.
- Video: gewichtete Klasse, moderates Queueing-Zeitbudget, um Bursts abzufangen.
- BE/Background: fairer Scheduler, kontrollierte Queue-Limits, um Bufferbloat zu vermeiden.
Statt Buffergrößen „nach Gefühl“ zu setzen, wird empfohlen, Queue-Limits in Zeit zu denken. Eine einfache Näherung für die Dimensionierung:
QueueBytes≈ RateBytesPerSec×QueueDelaySec
So lassen sich Voice-Queues bewusst klein halten (Jitterarmut) und Video-Queues moderat (Bursttoleranz), ohne in plattformabhängigen Byte-Fetisch zu geraten.
Shaping als Baseline: Bufferbloat und Mikrobursts beherrschen
Ein zentraler Baustein der Referenzarchitektur ist Shaping an rate-limitierten Übergängen. Das betrifft vor allem Access-Uplinks und NNI/Interconnects sowie Übergänge zu CPE/Modem/ONT:
- Egress-Shaping knapp unter Profilrate: verlagert Warteschlangen in den kontrollierbaren Knoten statt in unkontrollierte Puffer.
- Priorisierung im Shaper: Voice bleibt low-latency, Control geschützt, Video stabil, BE degradiert kontrolliert.
- Mikroburst-Glättung: Shaping reduziert Drop-Cluster, die Video-Keyframes und RTP empfindlich treffen.
Ohne Shaping treten viele QoS-Probleme trotz korrekter Markierung auf, weil Delay-Spitzen durch Bufferbloat entstehen. Deshalb ist Shaping in der Referenzarchitektur nicht optional, sondern Baseline.
Policing-Strategie: Profile durchsetzen ohne Echtzeit zu zerstören
Policing ist im Telco-Betrieb wichtig, um Tarife und Fairness durchzusetzen. Für Voice & Video muss Policing jedoch vorsichtig eingesetzt werden:
- Voice nicht hart policen: Drops in Voice sind hörbar; besser sind Trust Boundary + LLQ-Limit.
- Video-Überschuss remarken: statt harte Drops, die Freezes verursachen, Überschuss in eine niedrigere Klasse degradieren.
- Burstfenster realistisch: zu kleine Token-Buckets erzeugen Drop-Cluster bei Bursts und führen zu „sporadischen“ Problemen.
Damit bleibt QoS planbar: Überschuss wird kontrolliert degradiert, Echtzeit bleibt geschützt.
Domänenspezifische Umsetzung: Access
Im Access werden die wichtigsten Qualitätsgrundlagen gelegt. Die Referenzarchitektur empfiehlt:
- Per-Subscriber Profile: CIR/PIR pro Kunde und pro Klasse, damit Multi-Tenant-Fairness gewährleistet bleibt.
- Trust Boundary am Edge: Markierungen nur conditional trust oder am Provider-Edge setzen.
- Upstream-Shaping: besonders wichtig, weil Upstream häufig der Engpass ist.
- Voice/Control schützen: LLQ/High-Weight an den Engpass-Egresses, nicht nur „irgendwo im Netz“.
Domänenspezifische Umsetzung: Metro/Aggregation
Metro-Netze aggregieren viele Kundenströme. Hier entstehen Mikrobursts und CoS-Queueing ist häufig die operative Realität:
- CoS/PCP konsistent: DSCP↔PCP Mapping muss überall identisch sein.
- Queue-Budgets: Voice klein, Video moderat, BE kontrolliert – Bufferbloat vermeiden.
- LAG/ECMP Hotspots: per-member Telemetrie und Hashing-Disziplin, damit einzelne Links nicht droppen.
Domänenspezifische Umsetzung: IP/MPLS- oder SR-Core
Im Core ist Kapazität oft größer, aber QoS ist trotzdem relevant, insbesondere an NNI und in Schutzfällen:
- MPLS-TC-Queueing: TC/EXP wird konsistent gemappt, damit Klassen im Core stabil bleiben.
- Control schützen: Routing- und Steuerverkehr darf nicht verhungern; Convergence beeinflusst Echtzeit indirekt.
- Failover-QoS: Backup-Pfade müssen QoS-semantisch identisch sein; sonst führt FRR zu QoE-Knick.
Service Edge und Media-Pfade: SBC/IMS/WebRTC korrekt einbinden
Voice & Video enden oft an Service-Edges: IMS/SBC, Media Relays oder WebRTC-SFUs. Die Referenzarchitektur betont:
- Signaling vs. Media getrennt: unterschiedliche QoS-Budgets und Klassen.
- Markierungserhalt: NAT/Firewall/SBC dürfen DSCP nicht „nullen“; sonst bricht End-to-End-QoS.
- Compute-Determinismus: wenn CNFs/Kubernetes beteiligt sind, CPU/NUMA/NIC-Queueing beachten, damit kein Compute-Jitter entsteht.
NNI/Peering: Kapazität und Messgrenzen als Teil der Referenzarchitektur
Viele QoE-Probleme entstehen nicht im Core, sondern an Übergaben. Deshalb gehört in eine Telco-QoS-Referenzarchitektur:
- Headroom-Regeln: NNI-Ports nicht dauerhaft „auf Kante“ fahren, QoS ersetzt keine Kapazität.
- Konservativer Trust: Markierungen von außen nicht blind übernehmen.
- Klare SLA-Messpunkte: definieren, wo QoS-Kriterien gelten (UNI/NNI) und wie gemessen wird.
Abnahmeplan: Nachweis, dass Voice & Video end-to-end stabil sind
Eine Referenzarchitektur ist nur glaubwürdig, wenn sie testbar ist. Ein pragmatischer Abnahmeplan umfasst:
- Markierungs- und Mappingtest: DSCP/PCP/TC end-to-end, inklusive IPv6 und Tunnel Outer/Inner.
- Classify-Hits: pro Knoten prüfen, ob die Klassen wirklich matchen.
- Engpass-Test: BE-Fülllast plus Voice-/Video-Probes, um Queueing Delay 95/99 und Drops pro Klasse zu messen.
- Failover-Test: Umschalten (FRR/Link-Event) ohne EF-Drops, keine massiven Jitterpeaks.
- Service-KPI-Test: MOS/R-Faktor, RTP-Jitter/Loss, Video-Freezes (wo möglich) als Nutzerindikatoren.
Wichtig ist, in Sekundenfenstern zu messen und Perzentile zu betrachten, weil kurze Peaks die Nutzerqualität dominieren.
Monitoring-Baseline: Die „Golden Signals“ für Telco-QoS
Im Betrieb sollten Sie wenige, aber aussagekräftige Signale standardisieren:
- EF/Voice Drops: als Incident-Signal.
- Queueing Delay 95/99: pro Klasse an Engpässen.
- DSCP/PCP/TC-Verteilungen: Drift und Premium-Inflation erkennen.
- Shaper/Policer Events: Überlast, Fehlprofile oder Burst-Probleme sichtbar machen.
- Service-KPIs: MOS/R-Faktor, RTP-Jitter/Loss, Video-QoE-Indikatoren.
Mit dieser Baseline wird die Referenzarchitektur nicht nur „implementiert“, sondern dauerhaft verifizierbar.
Typische Stolperfallen und wie das Beispiel-Design sie vermeidet
- LLQ ohne Limit: wird durch harte Limits und Trust Boundaries verhindert.
- Video in Priority Queue: wird durch getrennte Video-Klasse mit Gewichtung vermieden.
- Bufferbloat: wird durch Shaping an rate-limitierten Übergängen und Zeitbudgets für Queues reduziert.
- Mapping-Drift: wird durch zentrale Tabellen und rollenbasierte Templates minimiert.
- Tunnel macht Underlay blind: wird durch Inner/Outer-Markierungsregeln adressiert.
Referenzarchitektur in einem Satz: So sieht das Beispiel-Design aus
Ein schlankes 4–5-Klassenmodell (Voice LLQ mit Limit, Control hoch gewichtet, Video gewichtet, BE/Background), eine harte Trust Boundary am Edge mit Conditional Trust und Remarking, konsistente DSCP↔PCP↔TC-Mappings über Access/Metro/Core, Shaping an allen rate-limitierten Engpässen sowie ein Abnahme- und Monitoring-Set aus Perzentilen, Classify-Hits und Service-KPIs – das ist der Kern einer QoS-Referenzarchitektur für Telcos, die Voice & Video end-to-end stabil durch das Netz bringt.