QoS und LTE/5G Bearer sind in Mobilfunknetzen untrennbar miteinander verbunden, weil Sprach- und Videodienste nicht allein durch „mehr Bandbreite“ stabil werden, sondern durch korrekt definierte Dienstklassen mit garantierten Verzögerungs- und Verlustzielen. Während in IP-Netzen QoS meist über DSCP (Differentiated Services Code Point) signalisiert wird, arbeiten LTE und 5G mit eigenen QoS-Konzepten: In LTE/EPC sind das EPS Bearer mit QCI (QoS Class Identifier), in 5G-SA sind es QoS Flows mit 5QI (5G QoS Identifier) und QFI (QoS Flow Identifier). Genau an dieser Schnittstelle entstehen in der Praxis viele Qualitätsprobleme: DSCP-Markierungen aus dem Enterprise-LAN kommen im Mobilfunknetz nicht an, werden am Übergang „genullt“, oder sie werden falsch auf QCI/5QI gemappt. Die Folge ist typisch: VoLTE/VoNR knackt in der Busy Hour, Videokonferenzen pendeln in der Qualität, Mission-Critical-Apps verlieren ihre Latenzgarantien, und das Troubleshooting wird schwierig, weil man auf IP-Seite „korrekte Markierungen“ sieht, die Funkseite aber andere Prioritäten setzt. Ein professionelles Design setzt daher auf End-to-End-Kohärenz: DSCP-Klassen im IP-Transport müssen systematisch in QCI/5QI-Klassen übersetzt werden (und umgekehrt), inklusive Trust Boundary, Profilierung und sauberem Mapping über Backhaul, Metro und Core. Dieser Artikel erklärt die Grundlagen, typische Mapping-Strategien und Designregeln, damit DSCP zu QCI/5QI nicht nur „irgendwie“ passt, sondern operativ stabil und SLA-fähig wird.
Warum DSCP und QCI/5QI überhaupt gemappt werden müssen
DSCP ist ein IP-Header-Feld und damit im klassischen IP-Transport sichtbar. LTE und 5G priorisieren jedoch nicht primär nach DSCP, sondern nach ihren eigenen QoS-Parametern im Mobilfunkprotokoll-Stack. Sobald Traffic vom IP-Netz in ein Mobilfunknetz übergeht (oder umgekehrt), gibt es zwei „QoS-Sprachen“. Ohne Übersetzung kommt es zu einem Bruch der Service-Semantik.
- IP/WAN-Sicht: Klassen wie EF (Voice), AF (Video) oder Best Effort werden über DSCP markiert und in Queues umgesetzt.
- LTE-Sicht: Bearer mit QCI definieren Priorität, Delay-Budget und Verlusttoleranz.
- 5G-Sicht: QoS Flows mit 5QI/QFI definieren Eigenschaften pro Flow, oft granularer als LTE.
Das Mapping ist die Brücke: Es stellt sicher, dass ein „Voice-Paket“ aus dem IP-Netz auch im Funk als Voice behandelt wird und nicht in einer generischen Datenklasse landet.
LTE/EPC-Grundlagen: EPS Bearer, QCI und ARP
In LTE werden Dienste über EPS Bearer transportiert. Ein Bearer ist dabei ein logischer Transportkanal mit definierten QoS-Eigenschaften. Der QCI beschreibt das Verhalten (z. B. Priorität und Delay-Budget). Zusätzlich spielt ARP (Allocation and Retention Priority) eine Rolle, wenn Ressourcen knapp sind.
- Default Bearer: wird beim Attach/PDN Connectivity aufgebaut, trägt typischerweise Best-Effort-Daten.
- Dedicated Bearer: wird für spezielle Dienste hinzugefügt, z. B. VoLTE mit eigenen QoS-Eigenschaften.
- QCI: Klasse, die u. a. Priorität, Verzögerungsbudget und Verlusttoleranz beschreibt.
- GBR vs. Non-GBR: garantiert vs. nicht garantiert (wichtig für Voice und kritische Dienste).
- ARP: entscheidet bei Überlast, welche Bearer bevorzugt aufgebaut/erhalten werden.
Für QoS-Planung ist entscheidend: Voice bekommt in LTE typischerweise einen Dedicated Bearer mit einer „Voice-geeigneten“ QCI und (je nach Design) GBR, während Internetdaten im Default Bearer bleiben.
5G-SA-Grundlagen: QoS Flow, 5QI und QFI
Im 5G-Standalone-Netz ist QoS granularer: Innerhalb einer PDU Session können mehrere QoS Flows existieren, identifiziert über QFI. Die Eigenschaften werden über 5QI beschrieben. Das ermöglicht feinere Differenzierung (z. B. Audio vs. Video vs. Signaling) innerhalb derselben Session.
- PDU Session: logische Verbindung für IP-Dienste (oder Ethernet/Unstructured in speziellen Fällen).
- QoS Flow: Fluss mit definiertem QoS-Verhalten innerhalb der PDU Session.
- 5QI: definiert standardisierte oder dynamische QoS-Charakteristika (Delay-Budget, Priorität, Loss-Toleranz).
- QFI: Identifikator des Flows im User Plane, wichtig für gNB-Scheduler und Transportzuordnung.
- GBR / Non-GBR / Delay-Critical GBR: verschiedene Servicearten, besonders relevant für VoNR und URLLC-nahe Profile.
Für End-to-End-QoS heißt das: DSCP-Klassen sollten nicht nur „irgendwie“ auf eine 5QI fallen, sondern konsistent pro Diensttyp (Voice Audio, Control, interaktives Video, Best Effort) in passende Flows gemappt werden.
Die Mapping-Idee: DSCP beschreibt Absicht, QCI/5QI beschreibt Funk- und Core-Behandlung
Ein sauberes Mapping beginnt mit einem Klassenmodell, das in beiden Welten Sinn ergibt. DSCP sollte nicht zu viele Klassen haben (operativ schwer), QCI/5QI sollte nicht „überladen“ werden (RAN/Policy-Komplexität). Eine praxistaugliche Zielarchitektur ist daher: wenige, klare Serviceklassen mit eindeutiger Semantik.
- Voice Audio: extrem jitter- und loss-sensibel, niedrige Delay-Budgets, hohe Priorität, oft GBR.
- Signaling/Control: volumenarm, aber wichtig für Setup und Stabilität; hohe Priorität, meist Non-GBR, aber robust.
- Interaktives Video: bandbreitenstärker, burstig, toleriert mehr Delay als Audio, braucht stabile Throughput-Fenster; meist Non-GBR mit garantierten Anteilen oder spezifischen Policies.
- Best Effort: Datenverkehr ohne SLA.
- Background: Updates/Backups, niedrig priorisiert.
Die Übersetzung lautet dann: DSCP-Klasse → (Policy/PCF) → QCI/5QI/QFI → RAN-Scheduling und Transport-Queuing.
Trust Boundary im Mobilfunkkontext: DSCP nicht blind übernehmen
In Provider- und Mobilfunknetzen ist die Trust Boundary besonders wichtig. Wenn ein beliebiges Endgerät DSCP EF setzen könnte, würde es sich „Voice-Priorität“ erschleichen. Deshalb übernehmen Mobilfunknetze DSCP-Markierungen in der Regel nicht blind, sondern setzen QoS über Policies (PCRF in LTE, PCF in 5G) und Service-Profile.
- Untrusted UE: DSCP wird ignoriert oder normalisiert; QoS wird netzseitig pro Service zugewiesen.
- Managed Enterprise Access: bei bestimmten Business-Angeboten kann DSCP aus dem Enterprise-LAN als Input dienen, aber nur innerhalb definierter Profile.
- Conditional Trust: Markierungen werden akzeptiert, aber nur für Whitelist-Klassen und innerhalb profilierter Budgets; Überschuss wird herabgestuft.
Für Design und Betrieb bedeutet das: DSCP→QCI/5QI ist selten eine 1:1-„Durchleitung“, sondern meist ein kontrolliertes Mapping an einer Netzgrenze (UPF/PGW, Enterprise APN/DNN, MEC-Edge, N3IWF/Trusted WLAN Gateway).
Wo das Mapping technisch passiert: Policy und User Plane
In LTE und 5G gibt es typische Orte, an denen das DSCP↔QCI/5QI-Mapping umgesetzt wird. Je nach Architektur kann das anders aussehen, aber die Prinzipien sind ähnlich:
- LTE/EPC: Service-Policies (PCRF/PCF-ähnlich) steuern Dedicated Bearer; PGW/S-GW/EnodeB setzen Bearer-QoS. DSCP-Markierungen können am UE, am Enterprise-Gateway oder am PGW neu gesetzt werden.
- 5G Core: PCF erstellt QoS-Rules; SMF/UPF setzen QoS Flows und markieren/klassifizieren Traffic. gNB nutzt QFI/5QI für Scheduling.
- WLAN-Interworking (VoWiFi): bei Trusted/Untrusted WLAN (z. B. ePDG/IKEv2 in LTE, N3IWF in 5G) entscheidet die Tunnel-/Gateway-Schicht, welche Markierungen in den Transport übernommen werden.
Wichtig ist dabei: Selbst wenn DSCP im Paket steht, priorisiert die RAN primär nach QCI/5QI. DSCP ist für IP-Transportsegmente (Backhaul, Metro, Core) relevant. Daher muss das Mapping an den Übergängen explizit und konsistent sein.
Ein praktisches Mapping-Template: Von DSCP-Klassen zu Mobilfunk-QoS
Ein bewährter Ansatz ist, DSCP in wenige „Servicegruppen“ zu normalisieren und diese dann auf passende Bearer/Flows zu mappen. In der Praxis sieht das oft so aus:
- DSCP EF: Voice Audio → Voice-taugliche QCI/5QI (niedriges Delay-Budget, hohe Priorität, oft GBR) → eigene Bearer/Flow.
- DSCP für Control: Signaling/Control → Control-taugliche QCI/5QI (hoch priorisiert, meist Non-GBR) → eigener Flow oder mit klarer Policy.
- DSCP AF für Video: interaktives Video → Video-taugliche QCI/5QI (höheres Delay-Budget, aber stabiler Durchsatz) → gewichtete Behandlung, kein strict priority.
- DSCP 0: Best Effort → Default Bearer/Default Flow.
Der konkrete QCI/5QI-Wert ist weniger wichtig als die korrekte Semantik: Voice muss als Voice behandelt werden, Video darf Voice nicht verdrängen, Control muss stabil bleiben, und Best Effort bleibt fair.
Backhaul-Realität: QCI/5QI allein reicht nicht, Transport-Queues müssen passen
Ein häufiger Irrtum ist: „Wenn der Bearer richtig ist, ist QoS erledigt.“ In Wirklichkeit kann die RAN perfekt priorisieren, aber wenn der Mobile Backhaul oder der IP/MPLS-Core falsch queued oder falsch shaped, entsteht trotzdem Jitter und Loss. Daher ist das DSCP-Mapping im Transportnetz entscheidend.
- gNB/eNodeB-Backhaul: muss Voice/Control/Video in passende Transportklassen übersetzen (DSCP/CoS/MPLS-TC).
- Metro-Aggregation: darf keine QoS-Löcher haben (z. B. PCP-Mapping fehlt, falsche Queue-Gewichte).
- Core: MPLS-TC/EXP oder SR-Traffic-Class muss konsistent auf die Klassen wirken.
Best Practice ist eine End-to-End-Mapping-Kette: QCI/5QI → DSCP → (CoS/PCP) → (MPLS-TC) → Scheduling/Queues an jedem Engpass.
Shaping vs. Policing im Mobilfunktransport: Warum Voice bei falschen Profilen knackt
Mobilfunknetze haben viele rate-limitierte Segmente (Microwave, Aggregationsuplinks, peering-nahe Ports). Dort sind Microbursts normal. Harte Policer erzeugen Drop-Cluster, und Drop-Cluster ruinieren Voice.
- Shaping: glättet Bursts am Egress, reduziert Drop-Cluster, stabilisiert Jitter – besonders wichtig für Voice-Flows.
- Policing: als Governance notwendig, aber Voice sollte so dimensioniert sein, dass Policing praktisch nicht dropt.
- LLQ mit Limit: im Transport für Voice geeignet, aber begrenzt, um Premium-Inflation zu verhindern.
Wenn VoLTE/VoNR „nur in Busy Hour“ knackt, ist die Ursache häufig nicht die Funkzelle allein, sondern ein Transportengpass mit Burst-Drops oder Bufferbloat.
VoLTE vs. VoNR: Was sich am Mapping ändert
VoLTE (LTE/EPC) und VoNR (5G SA) nutzen beide IMS, aber die QoS-Mechanik unterscheidet sich: QCI/EPS Bearer vs. 5QI/QoS Flows. Für das Mapping bedeutet das:
- VoLTE: typischerweise Dedicated Bearer für Voice Media, separate Behandlung für Signaling/Control.
- VoNR: QoS Flow(s) innerhalb einer PDU Session, oft granularer; Voice Audio als eigener Flow, ggf. weitere Flows für Control.
- Transport bleibt ähnlich: in beiden Fällen müssen Voice und Control in DSCP/CoS/MPLS-TC übersetzt werden, um im Backhaul korrekt zu wirken.
Operational ist VoNR häufig anspruchsvoller, weil Cloud-native Core-Komponenten und Flow-Granularität mehr Mappingpunkte und mehr potenzielle Fehlstellen erzeugen.
Häufige Fehler beim DSCP↔QCI/5QI-Mapping
- DSCP wird am Rand genullt: Enterprise markiert EF, aber am Gateway wird alles auf DSCP 0 gesetzt – Transport priorisiert nicht.
- Falsche Semantik: Video wird wie Voice behandelt (zu hohe Priorität) oder Voice landet in einer generischen Datenklasse.
- Mapping-Loch im Transport: DSCP ist gesetzt, aber PCP/CoS oder MPLS-TC ist falsch – ein Segment behandelt Voice als Best Effort.
- Kein Trust Boundary: zu viele Flows werden als Premium akzeptiert; Premium-Inflation entsteht, LLQ wird überfüllt.
- Policer-Drops auf Echtzeit: Voice-Pakete werden in Clustern gedroppt, MOS fällt.
- IPv6/Dual-Stack inkonsistent: IPv4 wird korrekt klassifiziert, IPv6 Traffic Class nicht – Voice über v6 läuft falsch.
Monitoring und Nachweis: Wie Sie prüfen, ob Mapping wirklich funktioniert
Ohne Messbarkeit bleibt Mapping ein Ratespiel. Ein belastbares Betriebsmodell betrachtet daher sowohl Funk-/Core-Sicht als auch IP-Transport-Sicht:
- Transport-KPIs pro Klasse: Queue-Drops, Queueing Delay/Perzentile, Policer-Hits, Traffic pro DSCP/CoS/MPLS-TC.
- RAN-KPIs: Scheduling-Statistiken, Funklast, Handover-Events, Retransmissions.
- Service-KPIs: MOS/R-Faktor, RTP Jitter/Loss (z. B. aus RTCP), Call Setup Time, Drop Rate.
Ein praxistauglicher Leitsatz lautet: Drops in der Voice-Klasse sind ein Incident – unabhängig davon, ob sie im Funk, im Backhaul oder im Core entstehen. Zusätzlich ist eine dauerhaft hohe Premium-Auslastung ein Warnsignal für Fehlklassifizierung oder fehlende Profilierung.
Praxis-Blueprint: So bauen Sie ein stabiles DSCP→QCI/5QI-Mapping
- Klassenmodell vereinheitlichen: wenige, klare Serviceklassen (Voice, Control, Video, Best Effort, Background).
- Trust Boundary definieren: DSCP nicht blind übernehmen; Whitelist und Conditional Trust mit Profilen.
- Mappingtabellen festlegen: DSCP↔QCI/5QI und DSCP↔CoS↔MPLS-TC konsistent dokumentieren und umsetzen.
- Voice strikt, aber begrenzt: LLQ für Audio mit Limit, kleine Queue-Limits, keine Premium-Inflation.
- Shaping an Engpässen: besonders im Mobile Backhaul und vor Rate-Limits; Bursts glätten, Drop-Cluster vermeiden.
- Video gewichtet behandeln: keine strict priority, sondern garantierte Anteile und stabile Throughput-Fenster.
- Dual-Stack berücksichtigen: IPv4 DSCP und IPv6 Traffic Class identisch behandeln.
- Monitoring operationalisieren: Drops/Delay pro Klasse, Policer-Hits, Premium-Auslastung, MOS/R-Faktor als Standard-Dashboards.
Häufige Fragen zum Mapping von DSCP zu QCI/5QI
Kann ein Enterprise-DSCP-Wert direkt eine QCI/5QI im Mobilfunk erzwingen?
In der Regel nicht direkt, weil Mobilfunknetze DSCP aus Sicherheits- und Fairnessgründen nicht blind trusten. Stattdessen wird QoS über netzseitige Policies und Serviceprofile zugewiesen. In Managed- oder Business-Angeboten kann DSCP als Input dienen, aber nur innerhalb definierter Whitelists und Profile.
Warum reicht es nicht, nur im Funk richtig zu priorisieren?
Weil viele Qualitätsprobleme im Transport entstehen: Microbursts, rate-limitierte Backhaul-Links, Bufferbloat und Policer-Drops erzeugen Jitter und Loss, die Voice sofort schädigen. Deshalb muss QCI/5QI im Backhaul in DSCP/CoS/MPLS-TC übersetzt werden, damit die richtigen Queues an Engpässen greifen.
Was ist der häufigste Grund für „VoLTE/VoNR knackt trotz QoS“?
Meist ein Mapping- oder Profilierungsproblem: Voice landet in einer falschen Transportklasse, Outer-Header-Markierung fehlt bei Tunneln, oder harte Policer droppen in Bursts. Die schnellsten Indikatoren sind Queue-Drops und Queueing Delay in der Voice-Klasse sowie Policer-Hits auf Voice.