QoS für 5G VoNR (Voice over New Radio) ist eine der wichtigsten Voraussetzungen, damit Sprachdienste im 5G-Standalone-Netz (5G SA) nicht nur „funktionieren“, sondern sich in Qualität und Zuverlässigkeit auch gegenüber VoLTE behaupten. VoNR ist im Kern eine IMS-basierte Sprachsession, die über den 5G-Core und die 5G-RAN transportiert wird – mit strengen Anforderungen an Latenz, Jitter, Paketverlust und vor allem an Stabilität bei Funklast, Handover und wechselnden Funkbedingungen. Anders als bei klassischen Datenservices reicht es nicht, „genug Bandbreite“ bereitzustellen: Sprachpakete sind klein, aber extrem empfindlich gegenüber Verzögerungsschwankungen und Drop-Clustern. Gleichzeitig bringt 5G neue Mechanismen und Stellhebel ins Spiel: 5QI/QFI-Flow-basiertes QoS, GBR-Profile, QoS Flow Mapping über PDU Sessions, Network Slicing, Service Based Architecture (SBA) im Core sowie Cloud-native Deployments mit CNFs, bei denen Compute- und Datapath-Jitter plötzlich genauso relevant werden wie Linkauslastung. Ein professionelles QoS-Design für 5G VoNR verbindet daher Funk-, Transport- und Core-Domäne zu einem End-to-End-Ansatz: saubere QoS-Flows (5QI), konsistentes Mapping auf DSCP/CoS/MPLS-TC im Backhaul, Burst-Handling (Shaping statt Policing-Drops), stabile Scheduler-Profile (LLQ mit Limit für Audio), Trust Boundaries an Übergängen und Monitoring, das Sprachqualität über KPIs wie MOS/R-Faktor, Jitter, Loss und Setup Times sichtbar macht. Dieser Artikel erklärt die Anforderungen und zeigt praxisnah, wie Sie VoNR-QoS im Telco-Netz umsetzen – von gNB über Mobile Backhaul bis zum 5G Core und IMS.
VoNR in einem Satz: IMS-Voice über 5G SA mit QoS Flow statt EPS Bearer
Bei VoLTE wurde Sprachqualität im LTE/EPC-Kontext über EPS Bearer und QCI abgesichert. VoNR im 5G-Standalone-Netz nutzt hingegen QoS Flows mit 5QI (5G QoS Identifier) und QFI (QoS Flow Identifier) innerhalb einer PDU Session. Für QoS bedeutet das:
- QoS wird granularer: mehrere Flows pro PDU Session, differenziert nach Dienst (Audio, Signaling, ggf. Video).
- End-to-End Mapping ist Pflicht: 5QI/QFI müssen im Transportnetz auf DSCP/CoS/MPLS-TC abgebildet werden, sonst verliert der Backhaul die Priorität.
- GBR/Non-GBR: Sprachflows werden typischerweise mit garantierter Bitrate (GBR) betrieben, um Stabilität unter Last zu sichern.
Das zentrale Ziel bleibt gleich: Audio muss minimal warten, kaum jitteren und praktisch nicht gedroppt werden – auch wenn Datenlast im Netz hoch ist.
Qualitätsanforderungen für VoNR: Latenz, Jitter, Paketverlust und Stabilität
Sprachqualität wird nicht durch „Peak Bandbreite“ bestimmt, sondern durch Zeit- und Verlustverhalten. Für VoNR sind die folgenden Ziele besonders wichtig:
- Geringe Ende-zu-Ende-Latenz: hohe Latenz verschlechtert die Gesprächsinteraktion und erhöht Echo-Risiko.
- Niedriger Jitter: Schwankungen führen dazu, dass der Jitter-Buffer leerläuft oder aggressiv nachregeln muss.
- Sehr geringer Paketverlust: einzelne Drops sind hörbar, Drop-Cluster besonders schädlich.
- Stabilität bei Handover: kurze Unterbrechungen oder Reordering-Spitzen dürfen nicht zu Audioaussetzern führen.
In 5G kommt hinzu: Funkbedingungen wechseln schneller, und der Transportpfad kann durch Slicing/TE dynamischer werden. QoS muss diese Dynamik abfedern, nicht verstärken.
VoNR-Architektur: Wo QoS technisch „greift“
Ein End-to-End-VoNR-Pfad umfasst typischerweise folgende Domänen:
- UE (Endgerät): erzeugt Sprachpakete, nutzt Codec/Jitter-Buffer und meldet Qualitätswerte indirekt über IMS/Analytics.
- gNB / RAN: Funk-Scheduler priorisiert QoS Flows (QFI), setzt Funkressourcen und steuert Handover.
- Mobile Backhaul / Transport: Ethernet/IP/MPLS/SR – hier entscheidet Queueing, Shaping, Burst-Handling.
- 5G Core (UPF): User Plane Function stellt QoS Flows bereit, policed/markiert und setzt Pfade/Anchor.
- IMS (SBC, P-CSCF, S-CSCF): Signaling, Session-Steuerung, Media-Anker/Relays, ggf. Transcoding.
QoS kann in jeder dieser Domänen scheitern. Deshalb ist VoNR-QoS immer ein „Systemdesign“, kein einzelner Router-Policy-Schnipsel.
5QI und QFI: Die QoS-Sprache von 5G verstehen
Im 5G SA wird QoS über 5QI-Klassen beschrieben. Diese Klassen definieren Eigenschaften wie Priorität, Paketverzögerungsbudget und Verlusttoleranz. Der QFI identifiziert den konkreten Flow im Datenpfad. In der Praxis bedeutet das:
- Audio-Flow: erhält eine 5QI, die für Voice optimiert ist (geringes Delay-Budget, hohe Priorität, geringe Loss-Toleranz).
- IMS-Signaling: kann einen separaten Flow/Klasse erhalten, hoch priorisiert, aber nicht identisch zu Audio.
- Andere Dienste: Daten, Video, Messaging laufen in separaten Flows, um Voice nicht zu stören.
Der Schlüssel für Telco-Netze ist: Diese 5G-QoS-Information muss im Transportnetz sichtbar werden, sonst kann der Backhaul nicht korrekt priorisieren.
Mapping-Strategie: 5QI/QFI auf DSCP, 802.1p CoS und MPLS-TC abbilden
Mobile Backhaul und Metro/Access sind häufig Ethernet-basiert (802.1p CoS), der Core oft MPLS/SR (MPLS-TC/EXP). Deshalb benötigen Sie eine konsistente Mapping-Kette:
- UPF/gNB Edge: QoS Flow wird auf eine IP/Transport-Markierung gemappt (z. B. DSCP für Voice, DSCP für Control).
- Ethernet-Segmente: DSCP wird in 802.1p PCP/CoS übersetzt, wenn L2-Queuing dominiert.
- MPLS/SR-Core: DSCP wird in MPLS-TC/EXP gemappt, damit der Core nach Klassen queued.
Best Practice ist ein kompaktes Klassenmodell: Voice Audio bekommt die strengste Echtzeitklasse (LLQ mit Limit), IMS-Control eine Control-Klasse, Daten/Best Effort und Background getrennt. So bleibt das Mapping stabil und operativ beherrschbar.
LLQ im Backhaul: Echtzeit ja, aber immer begrenzt
Im Transportnetz wird Voice typischerweise in einer Low Latency Queue (LLQ) bedient. Das reduziert Queueing Delay und Jitter. Gleichzeitig ist LLQ im Providerbetrieb riskant, wenn sie unlimitiert ist.
- LLQ nur für Audio: VoNR Media (RTP/SRTP) – nicht für Video, nicht für generellen „Premium“-Traffic.
- Limit setzen: verhindert Starvation anderer Klassen und schützt gegen Fehlmarkierung.
- Kleine Queue-Limits: verhindert, dass die Echtzeitklasse selbst Bufferbloat erzeugt.
Ein operativer Grundsatz, der in VoNR-Netzen sehr gut funktioniert: Drops in der Voice-Klasse sind ein Incident. Voice darf nicht „normal droppen“ wie Best Effort.
Shaping vs. Policing im Mobile Backhaul: Bursts sind der Normalfall
Backhaul-Links sind häufig rate-limitiert (Microwave, Aggregations-Uplinks, Access-Profile). In solchen Umgebungen sind Microbursts der Hauptgrund für sporadische Sprachstörungen. Harte Policer erzeugen Drop-Cluster – besonders schädlich für Audio.
- Shaping: glättet Bursts, reduziert Drop-Cluster, stabilisiert Jitter – besonders am Egress rate-limitierter Links.
- Policing: wichtig zur Governance, aber Voice sollte so dimensioniert sein, dass Policing praktisch nie dropt.
- Remarking: Überschuss besser herabstufen (bei Daten/Video) als hart droppen; bei Voice ist Überschuss ein Design- oder Missmarkierungsproblem.
Für VoNR ist Shaping im Backhaul oft der wichtigste Stabilitätshebel, weil es die Burst-Dynamik entschärft, bevor sie in hörbare Aussetzer umschlägt.
Funklast und RAN-Scheduler: QoS endet nicht am IP-Backhaul
Selbst perfektes Transport-QoS hilft wenig, wenn die RAN unter hoher Last die Sprachflows nicht stabil bedient. Im RAN ist die Priorisierung der QoS Flows und die Ressourcenreservierung für Voice entscheidend. Typische Risikofaktoren:
- Lastspitzen: viele gleichzeitige UEs, Video-Uploads, Busy Hour in Zellen.
- Handover-Frequenz: schnelle Zellwechsel können kurzfristige Unterbrechungen und Reordering erzeugen.
- Scheduler-Konfiguration: Voice-Flow muss echte Priorität und ausreichende Ressourcen erhalten, ohne das Netz unfair zu machen.
Ein sauberes VoNR-QoS-Design koppelt RAN-Policies mit Transport-Policies: Der Flow muss überall als Voice erkennbar sein und überall bevorzugt behandelt werden.
Network Slicing: VoNR als Slice oder als Flow?
5G ermöglicht Slicing. Für VoNR ist in der Praxis entscheidend, ob Voice als eigener Slice betrieben wird oder als priorisierter Flow innerhalb eines gemeinsamen Slice. Beide Ansätze können funktionieren, aber die Anforderungen bleiben gleich:
- Slice-basierte Trennung: klare Isolation, bessere Planbarkeit, aber höherer Betriebsaufwand und mehr Komplexität im Transport.
- Flow-basierte Priorisierung: weniger Komplexität, gute Skalierung, solange die QoS Flows sauber profiliert und gemappt sind.
Wichtig ist: Slicing ersetzt kein Queueing/Mapping. Auch ein Slice benötigt korrekte DSCP/CoS/TC-Übersetzungen und sauberes Engpass-Design.
IMS und SBC im VoNR-Kontext: Signaling und Media sauber behandeln
VoNR nutzt IMS. Damit gelten klassische IMS-QoS-Regeln weiterhin:
- Signaling vs. Media trennen: SIP/Control in eine Control-Klasse, Media in die Voice-Klasse.
- SBC als Trust Boundary: Medien werden oft geankert, DSCP kann neu gesetzt werden; Markierungen sollten kontrolliert und produktkonform sein.
- Security-Kette berücksichtigen: Firewalls/NAT/VPN dürfen DSCP nicht neutralisieren; sonst verliert der Medienpfad Priorität.
In cloud-nativen IMS-Deployments kommt zusätzlich Compute-Jitter hinzu: CPU-Throttling oder Overload kann Audioqualität verschlechtern, selbst wenn das Transportnetz sauber ist.
Dual-Stack und IPv6: QoS muss für v4 und v6 gleich funktionieren
Viele 5G-Core-Deployments sind IPv6-first oder dual-stack. Ein typischer VoNR-Stolperstein ist, dass QoS-Policies nur für IPv4 vollständig umgesetzt sind. Für VoNR gilt daher:
- Identische Klassifizierung: DSCP/Traffic Class in IPv6 genauso matchen wie in IPv4.
- Identische Mapping-Tabellen: DSCP->CoS und DSCP->TC müssen für v4 und v6 gleich sein.
- Monitoring getrennt sichtbar: v4/v6-Voice-Performance getrennt auswerten, um Drift zu erkennen.
Wenn VoNR „nur manchmal“ schlecht ist, lohnt ein Blick, ob Pfade oder Policies zwischen v4 und v6 unterschiedlich sind.
Typische Fehler bei VoNR-QoS – und wie sie sich zeigen
- Voice knackt trotz QoS: Microbursts, fehlendes Shaping, Policer-Drops oder zu enge LLQ-Limits im Backhaul.
- QoS-Loch im Transport: 5QI/QFI wird nicht sauber auf DSCP/CoS/TC gemappt; Core/Metro behandelt Voice als Best Effort.
- Premium-Inflation: zu viel Traffic in Voice-Klasse (fehlende Trust Boundary), LLQ verliert Wirkung.
- Handover-bedingte Aussetzer: RAN-Scheduler und Transportpfade nicht stabil; Reordering und kurze Unterbrechungen.
- Cloud-Overload: IMS/SBC/CNFs unter CPU-Pressure, Jitter entsteht im Datapath, nicht auf dem Link.
Diese Fehler lassen sich meist über Queue-Drops, Queueing Delay, Policer-Hits und servicebezogene KPIs (MOS/R-Faktor, Setup Times) schnell eingrenzen.
Monitoring und KPIs: VoNR-Qualität operativ absichern
VoNR-QoS ist nur dann stabil betreibbar, wenn Sie Netz- und Service-KPIs zusammen betrachten:
- Netz-KPIs pro Klasse: Queue-Drops, Queue-Depth/Queueing Delay, Policer-Hits, Traffic pro Klasse (Voice/Control/Data).
- RAN-KPIs: Funklast, Scheduling-Statistiken, Handover-Events, Retransmissions auf Funkebene.
- Service-KPIs: MOS/R-Faktor, RTP Jitter/Loss aus RTCP, Call Setup Time, Call Drop Rate.
Ein praxistauglicher Betriebssatz für VoNR lautet: Drops in der Voice-Klasse sind ein Incident – und Policer-Hits auf Voice sind ein Design- oder Markierungsproblem.
Praxis-Blueprint: QoS für 5G VoNR im Telco-Netz umsetzen
- QoS Flows sauber definieren: Voice Audio als eigener QoS Flow mit voice-optimierter 5QI, Signaling separat.
- Mapping standardisieren: 5QI/QFI → DSCP → CoS (Access/Metro) → MPLS-TC (Core), konsistent end-to-end.
- LLQ nur für Audio: strict priority mit Limit, kleine Queue-Limits, Voice darf nicht inflationieren.
- Shaping an Engpässen: besonders im Mobile Backhaul (rate-limitiert), Microbursts glätten, Drop-Cluster vermeiden.
- Policing vorsichtig: Voice-Budgets realistisch dimensionieren, Drops auf Voice vermeiden, Überschuss in Datenklassen behandeln.
- Trust Boundary setzen: Markierungen nur aus kontrollierten Quellen akzeptieren, normalisieren und profilieren.
- RAN und Transport koppeln: Scheduler-Policies und Transport-QoS müssen zusammenpassen, sonst entstehen Handover-/Lastprobleme.
- Cloud-Ressourcen absichern: IMS/SBC/CNFs mit garantierten Ressourcen betreiben, um Compute-Jitter zu vermeiden.
- Monitoring operationalisieren: Queue-Drops/Delay, RAN-Last, MOS/R-Faktor, Setup Times, getrennt nach v4/v6.
Häufige Fragen zu QoS für 5G VoNR
Ist VoNR automatisch besser als VoLTE?
Nicht automatisch. VoNR kann sehr gute Qualität liefern, aber nur wenn 5QI/QFI korrekt in Transportklassen gemappt werden und Engpässe (Backhaul, Aggregation, Cloud-Datapaths) sauber designt sind. Ohne sauberes Mapping und Burst-Handling kann VoNR sogar empfindlicher wirken.
Was ist der wichtigste QoS-Hebel im Mobile Backhaul?
Shaping an rate-limitierten Links, kombiniert mit einer kleinen, limitierten LLQ für Voice. Das reduziert Microburst-bedingte Drop-Cluster und stabilisiert Jitter, ohne andere Klassen zu verhungern.
Warum knackt VoNR manchmal nur bei Busy Hour?
Weil VoNR unter hoher Last an Engpässen in Congestion läuft: Funklast, Backhaul-Rate-Limits, Aggregationsuplinks oder UPF/SBC-CPU können Bursts und Drops erzeugen. Wenn Voice-Drops oder Queueing Delay in der Voice-Klasse steigen, ist das ein Hinweis auf fehlendes Burst-Handling, zu enge Profile oder Mapping-Lücken.