QoS-Referenzarchitektur für Telcos: Beispiel-Design für Voice & Video end-to-end

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.

Related Articles