QoS für 5G Slicing: Mapping von 5QI/QFI zu Transport QoS

QoS für 5G Slicing ist in Telco- und Enterprise-5G-Projekten ein zentrales Design-Thema, weil ein „Slice“ nur dann einen echten Mehrwert liefert, wenn die zugesicherte Servicequalität (Latenz, Jitter, Paketverlust, Priorität) nicht an der Funkstrecke endet. In 5G wird die Servicequalität im Core und im Funk über 5QI (5G QoS Identifier) und QFI (QoS Flow Identifier) modelliert. Im Transportnetz (Backhaul, Midhaul, fronthaul-nahe Segmente, Datacenter-Fabric, IP/MPLS/SR, Ethernet) arbeitet QoS dagegen mit anderen Abstraktionen: DSCP/PHB, MPLS EXP/TC, VLAN CoS (802.1p), Queue-Profile, Shaper/Policer und Bandbreiten-Reservierungen. Die Herausforderung lautet daher: Wie mappt man 5QI/QFI sauber auf Transport QoS, sodass ein URLLC- oder Low-Latency-Flow nicht in Best Effort landet, ein eMBB-Slice nicht unbegrenzt „Premium“ beansprucht und der Transport die Slice-Isolation wirklich unterstützt? Dieser Artikel erklärt praxisnah, wie 5QI und QFI in der 5G-Architektur wirken, wo das Mapping technisch passiert, welche QoS-Klassen im Transport sinnvoll sind und wie Sie Messpunkte und Betriebsmetriken definieren, um Slice-QoS im Livebetrieb belastbar nachzuweisen.

5G Slicing in einem Satz: Logische Netze mit eigenen QoS- und Policy-Eigenschaften

Network Slicing teilt ein physisches 5G-Netz in mehrere logische Netze (Slices), die unterschiedliche Serviceanforderungen bedienen können: klassisches Mobile Broadband (eMBB) mit hoher Datenrate, massive IoT (mMTC) mit vielen Geräten und meist geringer Bandbreite, oder URLLC-nahe Anwendungen mit strengen Latenz- und Zuverlässigkeitsanforderungen. In der Praxis ist „Slicing“ weniger Magie als saubere Policy- und QoS-Isolation: separierte Ressourcen, priorisierte Behandlung, definierte Bandbreitenprofile und eine kontrollierte Ausbreitung dieser Eigenschaften über Funk, Core und Transport.

• Slice-Isolation: ein Slice soll andere Slices nicht verdrängen, weder im Funk noch im Transport.
• Service-Intent: pro Slice definierte Ziele für Latenz, Jitter, Loss, Verfügbarkeit, Throughput.
• End-to-End: QoS muss über RAN, Core und Transport konsistent abgebildet werden.

5QI, QFI und QoS Flows: Die 5G-QoS-Währung

In 5G ist die kleinste QoS-Einheit typischerweise der QoS Flow. Ein Endgerät (UE) kann mehrere QoS Flows gleichzeitig haben, etwa für Sprach-/Medienverkehr, Signalisierung und Daten. Der QoS Flow wird im Core identifiziert und in Richtung RAN transportiert; auf der Luftschnittstelle wird er in geeignete Bearer/Radio-Ressourcen umgesetzt. Dabei spielen zwei Begriffe eine Schlüsselrolle:

• 5QI: ein Identifier, der QoS-Charakteristika beschreibt (z. B. Priorität, Verzögerungsbudget, Paketfehlerrate) und damit die „Verhaltensklasse“ eines Flows vorgibt.
• QFI: ein Identifier, der den konkreten QoS Flow markiert, damit Netzkomponenten ihn wiedererkennen und passend behandeln können.

Wichtig ist: 5QI ist eher die Serviceklasse, QFI die Instanz. Mehrere Flows können unterschiedliche QFIs haben, aber denselben 5QI nutzen – oder in komplexen Designs auch unterschiedliche 5QIs innerhalb eines Slices. Das bedeutet für Transport QoS: Sie müssen nicht zwingend jeden QFI in eine eigene Transportklasse mappen. Häufig ist ein Mapping pro QoS-Kategorie ausreichend, solange Sie Bandbreiten- und Prioritätsmodelle sauber begrenzen.

Warum das Mapping auf Transport QoS zwingend ist

Viele 5G-Slicing-Projekte scheitern in der Wahrnehmung daran, dass die Funkseite zwar priorisiert, aber der Transport die Flows wieder „mischt“. Das passiert besonders leicht in überbuchten Access- und Aggregationsbereichen oder auf IP/MPLS-Backbones mit starken Traffic-Peaks. Wenn ein Low-Latency-Flow und ein großer eMBB-Flow im selben Best-Effort-Queueing landen, ist die Latenz nicht mehr planbar. Umgekehrt kann ein unkontrolliertes Premium-Mapping dazu führen, dass eMBB oder sogar Bulk-Traffic die Premium-Queues füllt und damit URLLC/Voice verdrängt.

• Transport-Engpässe: Congestion entsteht typischerweise an Uplinks, Aggregationen und Edge-Übergängen.
• Queueing entscheidet: Latenz- und Jitter-Budgets werden meist durch Queueing verletzt, nicht durch reine Propagation.
• Fairness und Isolation: ein Slice braucht Begrenzungen (Shaping/Policing), damit es andere nicht verdrängt.

Wo das Mapping technisch passiert: N3/N9, UPF und Transport Edge

Das Mapping von 5QI/QFI auf Transport-QoS wird typischerweise in der User Plane umgesetzt, häufig an oder nahe der UPF (User Plane Function) sowie an Transport-Edges, die die User Plane tragen. Praktisch gibt es mehrere Ebenen, auf denen Markierungen/Classes gesetzt oder übersetzt werden können:

• UPF-nahe Markierung: QoS Flows werden bei Eintritt in das IP-Transportnetz mit DSCP (oder MPLS TC/EXP) markiert.
• Transport Edge Enforcement: Router/Switches am Übergang normalisieren Markierungen (Trust Boundary) und setzen Queueing-/Shaping-Policies.
• Unterwegs im Backbone: Core-Policies schedulen anhand DSCP/MPLS TC; idealerweise ohne Re-Marking, aber mit konsistenter Queue-Zuordnung.

Für ein robustes Design ist eine klare Trust Boundary entscheidend: In Telco-Netzen wird DSCP selten „blind“ vertraut. Stattdessen werden definierte Markierungen akzeptiert (Whitelist) und alles andere normalisiert. Genau das schützt Slices vor Missbrauch und verhindert Drift zwischen Domänen.

Mapping-Strategie: Nicht 1:1, sondern „Intent-zu-Klasse“

In 5G können theoretisch viele 5QI-Werte auftreten. Im Transportnetz ist es jedoch unpraktisch, für jede 5QI eine eigene Queue zu bauen. Besser ist eine Intent-basierte Konsolidierung: Sie definieren wenige Transportklassen, die die relevanten QoS-Eigenschaften abbilden, und mappen 5QI-Gruppen auf diese Klassen. Dabei gilt: Je strenger die Anforderungen (Latenz/Jitter), desto eher braucht der Flow eine höher priorisierte, stärker geschützte Klasse – aber immer begrenzt, um Starvation zu vermeiden.

• Low-Latency / Echtzeit: sehr geringe Latenztoleranz, kleine Queue, striktes Scheduling, harte Guardrails.
• Interaktives Video/Media: hohe Priorität, aber begrenzt; darf nicht die Echtzeitklasse fluten.
• Business-Critical Data: bevorzugt, aber nicht strict; schützt wichtige Anwendungen ohne Echtzeitversprechen.
• Best Effort: Standardklasse; trägt normale Datenlast.
• Bulk/Background: gedrosselt, um Peaks abzufangen (Updates, Backups, große Transfers).

DSCP, MPLS TC/EXP und CoS: Die Transport-Bausteine für Slice-QoS

Damit ein 5G-QoS-Intent über das Transportnetz wirkt, brauchen Sie ein konsistentes Markierungs- und Queueing-Modell. In IP-Netzen ist DSCP die gängigste Markierung. In MPLS/SR-Backbones wird häufig Traffic Class (TC) beziehungsweise EXP (historisch) genutzt, oft in Kombination mit DSCP-Interworking am Edge. In Ethernet-Abschnitten ist 802.1p/CoS relevant, besonders in Metro-Ethernet-Services oder in Aggregationsdomänen.

• DSCP als End-to-End Marker: Transportklassen werden anhand DSCP in Queues einsortiert.
• MPLS TC/EXP: Backbone-Klassen können aus DSCP abgeleitet oder separat geführt werden.
• CoS für Ethernet-Abschnitte: wichtig, wenn VLAN-Tagging und Provider-UNI/NNI im Spiel sind.

Der kritische Punkt ist Konsistenz: Ein DSCP-Wert muss in allen Transitdomänen in die gleiche beabsichtigte Queue fallen, sonst entstehen „Klassen-Sprünge“. Genau hier ist ein standardisiertes Mapping-Template (Multi-Vendor-fähig) essenziell.

QFI-Granularität: Wann QFI im Transport sichtbar sein muss

In vielen Designs reicht es, 5QI-Gruppen zu markieren, ohne QFI einzeln im Transport zu behandeln. Trotzdem gibt es Fälle, in denen QFI-Granularität sinnvoll ist:

• Feingranulare Slice-Policy: ein Slice enthält mehrere Flow-Typen (z. B. Voice und Video) mit unterschiedlichen Anforderungen.
• SLA-Nachweis: Sie wollen per Flow nachweisen, dass eine bestimmte QoS-Kategorie stabil bleibt.
• Admission/Isolation: Sie wollen innerhalb eines Slices verhindern, dass ein Flow-Typ alles dominiert.

Praktisch wird das oft so gelöst, dass nicht QFI im Transport als eigener Marker existiert, sondern dass QFI in der User Plane in eine Transportklasse übersetzt wird (z. B. „QFI-Gruppe A → DSCP X“, „QFI-Gruppe B → DSCP Y“). Damit bleibt das Transport-QoS-Modell überschaubar und operativ betreibbar.

Slice Isolation im Transport: Hierarchical QoS und per-Slice Shaping

„Slicing“ ohne Isolation ist nur Marketing. Im Transportnetz erreichen Sie Isolation typischerweise über Hierarchical QoS: zuerst wird ein Slice (oder eine Slice-Gruppe) in seiner Gesamtbandbreite begrenzt, darunter werden die Klassen innerhalb des Slices gescheduled. So verhindern Sie, dass ein eMBB-Slice mit hoher Datenrate die Premium-Queues füllt oder dass ein einzelner Slice die gesamte Linkkapazität belegt.

• Slice-Level Shaping: begrenzt die Gesamtbandbreite pro Slice (z. B. pro VRF, Tunnel, VLAN, LSP).
• Class-Level Scheduling: innerhalb des Slice wird Voice/Low-Latency vor Media vor Daten behandelt.
• Guardrails: Policers oder Limits verhindern Missmarking und schützen Echtzeitklassen.

Praktische Engpassorte: Wo Slicing-QoS am häufigsten kippt

In Telco-Transportnetzen sind Engpässe selten im Core-Backbone, sondern an Rändern und Aggregationspunkten. Genau dort muss Ihr Mapping besonders sauber sein.

• Cell Site / Access Aggregation: viele Funkzellen teilen sich Uplinks; Microbursts und Oversubscription sind typisch.
• Datacenter Edge: UPF/SGW/PGW-nahe Bereiche können hohe PPS-Last erzeugen, die Queueing triggert.
• Interconnects: Übergänge zwischen Domänen (Metro → Core, IP → MPLS) sind klassische Mapping-Bruchstellen.
• Security/Service Chaining: VNFs wie Firewalls oder DPI können zusätzliche Latenzpfade schaffen.

Erfolgsmetriken: Wie Sie das Mapping von 5QI/QFI zu Transport QoS nachweisen

Ein gutes Slicing-QoS-Design ist messbar. Dafür brauchen Sie Metriken auf drei Ebenen: (1) QoE/QoS im 5G-Kontext (Flow-Level), (2) Transport-QoS (Queues, Drops, Delay), (3) Slice-Isolation (pro Slice Bandbreite und Fairness). Operativ bewähren sich folgende Messpunkte:

• Per-Class Drops: Drops in der Low-Latency-/Voice-Klasse sind ein harter Alarm; Drops in Best Effort sind interpretierbar.
• Queue Depth/Delay: Frühwarnsignal für Latenzverletzungen, besonders in Echtzeitklassen.
• Shaper-Headroom: zeigt, ob Slice- oder Link-Shaper dauerhaft am Limit sind.
• Class Utilization: Anteil der Premiumklassen pro Slice; Missbrauch und Drift werden sichtbar.
• Flow-Korrelation: QoS Flow KPIs (z. B. Jitter/Loss) zeitlich mit Transport-Queueing korrelieren.

Testing und Validierung: Regression- und Canary-Ansätze für Transport-QoS im 5G Slicing

Da Slicing-QoS viele Komponenten über Domänen hinweg betrifft, sind kontrollierte Tests besonders wichtig. In Lab- und Staging-Umgebungen können Sie Profile je Slice erzeugen: ein Low-Latency-Flow, ein Media-Flow und ein eMBB-Bulk-Flow, und dann Congestion am definierten Bottleneck erzwingen. Erwartung: Low-Latency bleibt stabil, Media degradiert kontrolliert, Best Effort trägt die Einbußen. In Produktion sind Canary-Rollouts sinnvoll, bei denen Sie neue Mapping- oder HQoS-Profile zunächst nur auf wenigen Sites aktivieren und anhand High-Signal KPIs überwachen (Queue Delay/Depth, Per-Class Drops, Slice Utilization).

• Regression Tests: standardisierte Profile, Pass/Fail über Perzentile (Delay/Jitter) und Drops.
• Canary Rollouts: progressive Ausweitung, Guardrails für Echtzeitklassen, schneller Rollback.
• Control Group: Vergleich gegen unveränderte Sites, um Provider-/Lastschwankungen auszuschließen.

Typische Fehlerbilder im Mapping und ihre Root-Cause-Hinweise

• Low-Latency kippt trotz „richtiger“ 5QI: Transport mapping falsch oder Markierung geht in einer Domäne verloren; Classifier-Hits und DSCP-Drift prüfen.
• Premiumklassen dauerhaft voll: Slice-Level Shaping fehlt oder zu hoch; eMBB markiert zu „hoch“; per-slice Utilization und Guardrails prüfen.
• Loss-Spikes ohne Queue-Wachstum: Policers zu aggressiv oder VNF/CPU-Pfad limitierend; Drop Reasons und Policer Counters prüfen.
• Nur bestimmte Sites betroffen: Access-Aggregation oversubscribed oder Mapping-Templates nicht konsistent; Multi-Vendor Drift prüfen.
• Jitter steigt ohne Drops: Bufferbloat durch fehlendes Shaping oder zu große Buffer; Queue Delay 99p prüfen.

Best Practices: Mapping von 5QI/QFI zu Transport QoS stabil und betriebssicher umsetzen

• Intent zuerst: wenige Transportklassen definieren, die die Serviceziele abbilden; 5QI-Gruppen darauf mappen.
• Trust Boundary: Markierungen nur an definierten Punkten akzeptieren; Whitelist und Normalisierung gegen Drift.
• Slice Isolation: Hierarchical QoS mit Slice-Level Shaping und Class-Level Scheduling; Premiumklassen begrenzen.
• Shaping auf Realrate: Engpässe kontrollieren, Congestion in eigenen Queues halten, Overhead berücksichtigen.
• Multi-Vendor Konsistenz: DSCP/MPLS TC/CoS Mapping-Templates standardisieren, Naming vereinheitlichen, Drift automatisiert prüfen.
• High-Signal Monitoring: Queue Delay/Depth, Per-Class Drops, Drop Reasons und Slice Utilization als primäre KPIs.
• Regression und Canary: Änderungen über standardisierte Tests beweisen und progressiv ausrollen, bevor Kundenimpact entsteht.