5G QoS End-to-End: RAN → Transport → Core → Interconnect

5G QoS End-to-End ist in der Praxis der Unterschied zwischen „5G ist schnell“ und „5G ist verlässlich“. Viele Projekte starten mit der Annahme, dass die Funkseite (RAN) den größten Einfluss auf Qualität hat. Tatsächlich entstehen SLA-Verletzungen jedoch oft an ganz anderen Stellen: im Transportnetz (Backhaul/Midhaul), in virtualisierten Core-Funktionen (UPF/Firewall/Service-Chaining), oder am Interconnect in Richtung Internet, Cloud oder Partnernetze. End-to-End bedeutet deshalb: QoS ist eine durchgängige Kette von Service-Intents und technischen Übersetzungen – von der RAN-Scheduling-Logik über 5QI/QFI im Core, über DSCP/MPLS/CoS im Transport bis hin zu den Policies an Interconnects und Peering-Punkten. Wenn nur ein Glied dieser Kette fehlt oder inkonsistent ist, wird aus einem Low-Latency-Flow schnell ein Best-Effort-Flow, oder ein eMBB-Slice flutet Premium-Queues und verdrängt Echtzeit. Dieser Artikel erklärt, wie 5G QoS End-to-End technisch zusammenhängt (RAN → Transport → Core → Interconnect), wo die typischen Bruchstellen liegen, wie Sie Mapping und Isolation sauber umsetzen und welche Messpunkte und Metriken Sie benötigen, um QoS über Domänengrenzen hinweg belastbar nachzuweisen.

End-to-End-Logik: QoS ist ein Intent, der mehrfach übersetzt wird

In 5G beginnt QoS als Service-Intent: „Dieser Flow braucht geringe Latenz und hohe Zuverlässigkeit“ oder „Dieser Flow ist throughput-orientiert“. In der 5G-Architektur wird dieser Intent über 5QI (QoS-Klasse) und QFI (Flow-ID) operationalisiert. Im Transportnetz existieren 5QI/QFI jedoch nicht als native Queue-Mechanismen; dort sind DSCP/PHB, MPLS Traffic Class, CoS und Queue-Profile maßgeblich. Am Interconnect (z. B. Internet, Cloud, Partner) gelten wieder andere Realitäten: DSCP wird oft neutralisiert oder nur in bestimmten Produkten respektiert. End-to-End QoS ist daher ein kontrollierter Übersetzungsprozess, nicht „einmal DSCP setzen und fertig“.

• RAN: Radio Scheduling, Priorität und Ressourcenzuteilung für QoS Flows.
• Core: QoS Flows (QFI) und Klassen (5QI) definieren Behandlung in der User Plane.
• Transport: Übersetzung in DSCP/MPLS TC/CoS und Scheduling/Shaping an Engpässen.
• Interconnect: letzte Domäne, in der QoS-Intents häufig „verwässern“ – daher klare Edge-Strategien nötig.

RAN QoS: Wo 5G-Qualität startet – aber nicht endet

Die RAN ist die erste Domäne, in der QoS spürbar wird, weil Funk ein geteiltes Medium ist. Hier entscheiden Scheduling, MCS/PHY-Raten, HARQ/Retransmissions, Zelllast, Interferenz und Mobilität über Latenz und Jitter. 5G QoS bedeutet auf RAN-Seite: QoS Flows werden priorisiert, und je nach Serviceklasse werden Ressourcen anders zugeteilt. In der Praxis ist wichtig, dass RAN-QoS nicht als „Garantie“ missverstanden wird. Funk kann priorisieren, aber er kann keine Überlast wegzaubern, wenn Zellkapazität oder Funkbedingungen schlecht sind.

• Cell Load: hohe Auslastung erhöht Scheduling-Delay, auch bei priorisierten Flows.
• Mobility: Handovers und wechselnde Funkbedingungen erzeugen Jitter-Spikes.
• Reliability Mechanisms: Retransmissions verbessern Zuverlässigkeit, können aber Latenz erhöhen.
• QoS Flow Handling: unterschiedliche Flow-Typen (Echtzeit vs. Daten) werden differenziert behandelt.

Transport QoS: Der häufigste Ort für SLA-Verletzungen

Im Transportnetz entstehen QoS-Probleme am häufigsten, weil hier viele Funkstandorte und Services auf wenige Uplinks und Aggregationslinks zusammenlaufen. Backhaul und Midhaul sind oft oversubscribed, und Microbursts entstehen durch Aggregation, Encapsulation und Traffic-Mix. Wenn Transport-QoS nicht sauber umgesetzt ist, werden Latenzbudgets nicht eingehalten – selbst wenn die RAN priorisiert. Entscheidend ist: Transport-QoS ist egress-getrieben. Congestion entsteht beim Senden, daher müssen Policies am richtigen Egress-Interface sitzen und mit Shaping arbeiten, damit Queueing in kontrollierten Queues stattfindet.

• Engpässe: Cell Site Uplinks, Aggregation, Metro-Edges, DC-Edges.
• Microbursts: kurze Peaks füllen Buffer und erzeugen Jitter, bevor Drops sichtbar werden.
• Shaping: holt Congestion in kontrollierte Queues; ohne Shaping passiert Congestion in unkontrollierten Puffern.
• Per-Class Scheduling: Echtzeitklassen müssen geschützt, aber begrenzt sein (Starvation vermeiden).

Mapping: 5QI/QFI in Transportklassen übersetzen

Da Transportnetze nicht beliebig viele Queues pro Link betreiben, ist eine 1:1-Abbildung jeder 5QI in eine eigene Queue selten sinnvoll. Stattdessen etabliert man ein transportseitiges Klassenmodell (z. B. Low-Latency, Media, Critical Data, Best Effort, Bulk) und mappt 5QI-Gruppen darauf. QFI dient dann in der User Plane zur Flow-Separation, wird aber transportseitig meist nur indirekt sichtbar, indem verschiedene QFI-Gruppen unterschiedliche DSCP/MPLS-TC bekommen. Wichtig ist eine zentrale „Source of Truth“: Mapping-Tabellen müssen über alle Geräte und Hersteller konsistent sein.

• Intent-Konsolidierung: viele 5QI-Werte auf wenige Transportklassen mappen.
• Whitelist-Ansatz: nur definierte Markierungen akzeptieren, alles andere normalisieren.
• Interworking: DSCP ↔ MPLS TC ↔ CoS über Domänengrenzen stabil halten.
• Drift-Prevention: automatisierte Checks für Mapping und Policy-Attachments.

Core QoS: UPF, Service Chaining und die Compute-Realität

Der 5G Core ist nicht nur „Routing“, sondern eine Verarbeitungspipeline: UPFs terminieren User-Plane-Tunnel, setzen Policies um, führen ggf. NAT/Firewalling durch und hängen oft an Service-Chaining-Architekturen (z. B. DPI, Security, Lawful Intercept, Optimizer). In vielen Netzen läuft der Core virtualisiert (VNF/CNF), was zusätzliche QoS-Risiken bringt: CPU Scheduling, vSwitch Queues und Noisy Neighbors können Jitter erzeugen, bevor der Transport überhaupt congested ist. End-to-End QoS muss deshalb auch compute-seitig gedacht werden: deterministische Ressourcen, NUMA-Affinität, ausreichender Crypto-/Session-Headroom und Telemetry auf CPU/Queue-Ebene.

• UPF-Placement: regionale UPFs reduzieren RTT und stabilisieren Echtzeit.
• Service Chains: jede zusätzliche Funktion kann Latenz/Jitter erhöhen (Firewall/DPI/Decryption).
• Virtualisierung: CPU Ready/Throttling und vSwitch Queueing als versteckte Latenzquellen.
• DSCP Preservation: Markierungen dürfen in Tunneln/Chains nicht verloren gehen; Inner->Outer Copy ist entscheidend.

Interconnect QoS: Wo QoS-Intents häufig verwässern

Am Interconnect treffen Sie auf eine harte Realität: Ende-zu-Ende QoS über das öffentliche Internet ist nicht garantiert. Viele Provider neutralisieren DSCP oder behandeln es nur in bestimmten Business-Produkten. Für 5G QoS End-to-End bedeutet das: Sie müssen eine Interconnect-Strategie wählen, die zu Ihren SLOs passt. Für echte Low-Latency-Anforderungen sind kontrollierte Transportprodukte (z. B. private Interconnects, definierte Peering-Setups, MPLS/Ethernet-CoS) oft geeigneter als Best Effort Internet. Wo Internet unvermeidbar ist, ist der wichtigste Hebel häufig die Kontrolle der eigenen Engpässe (Shaping, Queueing, Pfadwahl) sowie die regionale Nähe zu Cloud-Edges.

• Peering/Region: unterschiedliche Pfade und Regionen erzeugen unterschiedliche RTT und Jitter.
• DSCP-Neutralisierung: im Internet oft üblich; QoS wirkt primär innerhalb kontrollierter Domänen.
• Private Interconnects: erhöhen Vorhersagbarkeit und ermöglichen konsistentere Klassenbehandlung.
• Edge-Strategien: lokale Breakouts, regionale UPFs und kontrollierte Egress-Policies reduzieren Latenz.

Slice-Isolation End-to-End: Ohne Hierarchical QoS bleibt Slicing fragil

End-to-End QoS in 5G ist eng mit Slice-Isolation verknüpft. Ein Slice darf nicht unbegrenzt Premium-Ressourcen beanspruchen, sonst verdrängt er andere. Im Transportnetz wird Isolation oft über Hierarchical QoS umgesetzt: Zuerst wird ein Slice (oder eine Slice-Gruppe) in seiner Gesamtbandbreite begrenzt (Shaping), darunter werden Klassen innerhalb des Slices priorisiert. Im Core kann Ähnliches durch Policy und Ressourcenallokation erfolgen. In der RAN existiert Isolation über Scheduling und Funkressourcen. Entscheidend ist, dass die Isolation an den realen Engpässen greift.

• Slice-Level Shaping: begrenzt Gesamttraffic pro Slice am Transport-Edge.
• Class-Level Scheduling: schützt Low-Latency innerhalb des Slice, ohne andere Klassen zu verhungern.
• Missbrauchsschutz: Whitelist-Markierung und Guardrails verhindern „Premium-Flutung“.
• Telemetry: per Slice/Class Utilization und Per-Class Drops zeigen, ob Isolation funktioniert.

Messpunkte und Erfolgsmetriken: So machen Sie End-to-End QoS überprüfbar

End-to-End QoS ist nur so gut wie seine Messbarkeit. Sie brauchen Messpunkte in jeder Domäne, aber mit klarer Priorität auf Engpässe. In der Praxis bewährt sich ein dreistufiges Messmodell: (1) Service-/Flow-KPIs (Jitter/Loss/Delay) als Nutzer- bzw. Anwendungsnähe, (2) Transport-QoS-KPIs (Queue Delay/Depth, Per-Class Drops, Drop Reasons) als Mechaniknachweis, (3) Kapazitäts- und Isolation-KPIs (Shaper-Headroom, Slice Utilization) als Prävention.

• RAN-nahe KPIs: Scheduling-Delay-Indikatoren, Cell Load, Mobility Events als Kontext für Jitter.
• Transport KPIs: Queue Delay/Depth 95p/99p, Per-Class Drops, Drop Reasons an Uplinks/Aggregation.
• Core KPIs: UPF-Throughput/PPS, CPU Ready/Throttling (virtualisiert), Chain-Latenz, Session-Health.
• Interconnect KPIs: RTT/Jitter Trends zu Cloud/Peering, regionale Abweichungen, Failover-Effekte.
• Isolation KPIs: per Slice Bandbreite, Premium-Anteil, Headroom und Guardrail-Events.

Typische End-to-End-Bruchstellen und wie sie aussehen

• RAN gut, Transport schlecht: QoE kippt in Stoßzeiten, Queue Delay/Drops an Aggregationsuplinks steigen.
• Transport gut, Core schlecht: QoE kippt ohne WAN-Queueing; UPF/Firewall zeigt CPU-/Queue-Spikes, Service Chain verursacht Jitter.
• Core gut, Interconnect schlecht: regionale RTT/Jitter-Spitzen, Peering-Änderungen; DSCP im Internet ohne Wirkung.
• Mis-Marking/Drift: Default/Unmatched steigt, Premiumklassen leer; Markierung geht an einem Übergang verloren.
• Policer-Effekte: Loss-Spikes ohne Queue-Wachstum; Drop Reason zeigt Policer, Slice-/Class-Limits zu hart.

Operationalisierung: End-to-End QoS als Lifecycle mit Canary und Regression

Weil 5G QoS über viele Domänen läuft, ist ein Lifecycle-Ansatz besonders wichtig: Lab-Validierung mit kontrollierter Congestion, progressive Canary Rollouts in ausgewählten Sites, Monitoring mit High-Signal Alerts (Queue Delay/Depth, Per-Class Drops, Policer Drops), und regelmäßige Rezertifizierung/Regression Tests nach Releases und Provider-/Peering-Changes. So verhindern Sie, dass QoS-Drift erst sichtbar wird, wenn Kunden es merken.

• Lab: 5QI/QFI->Transport-Mapping testen, Congestion-Proof, Guardrails gegen Missmarking.
• Canary: progressive Ausweitung, Control Group, Stop-Regeln bei Echtzeit-Drops/Delay 99p.
• Monitoring: normalisierte KPIs über RAN/Transport/Core, Top-Offender-Listen und Incident-Timelines.
• Regression: standardisierte Profile und Pass/Fail-Kriterien, vor allem nach Core-/Transport-/Security-Changes.

Pragmatische Leitlinien für 5G QoS End-to-End

• Intent klar definieren: pro Slice/QoS-Kategorie SLOs für Delay/Jitter/Loss festlegen.
• Mapping konsolidieren: 5QI-Gruppen auf wenige Transportklassen mappen; QFI nur dort granular nutzen, wo es nötig ist.
• Trust Boundary setzen: Markierungen nur an definierten Punkten akzeptieren; Whitelist und Normalisierung gegen Drift/Missbrauch.
• Engpässe kontrollieren: Shaping auf Realrate, Queueing in kontrollierten Queues; Microbursts über Peak-Queue-Metriken sichtbar machen.
• Core compute-fähig machen: UPF/Service Chains mit ausreichendem Headroom, deterministische Ressourcen bei Virtualisierung.
• Interconnect realistisch planen: DSCP im Internet nicht als Garantie; private Interconnects und regionale Edges für strenge Anforderungen.
• Nachweis führen: Queue Delay/Depth, Per-Class Drops, Drop Reasons und Flow-KPIs als Beweiskette etablieren.