Anwenden · 2.10
Priorität und Ende-zu-Ende-QoS
Zeit: etwa 10–13 Minuten einschliesslich Aufgabe; Schätzung
Leitfrage: Wie wird aus «dieser Ruf ist wichtig» eine prüfbare Behandlung im Netz?
Lernziel: Du verbindest Dienstpriorität mit Transportbehandlung und einem Lastversuch.
Voraussetzungen: Die vorausgehenden Lektionen bis 2.9; insbesondere die dort erklärte Fallakte.
Ein wichtiger Ruf trifft auf ein belastetes Netz
Lea ruft Niko im FRMCS-Piloten. Gleichzeitig überträgt ein Fahrzeug Messdateien. Beide Anwendungen benutzen Übertragungsressourcen, doch verspätete Sprache stört das Gespräch, während eine Datei häufig etwas länger warten kann. «Sprache zuerst» ist deshalb ein betrieblicher Wunsch. Damit das Netz daraus ein bestimmtes Verhalten ableiten kann, braucht es Regeln für die jeweiligen Datenströme.
Quality of Service (QoS) bezeichnet die gesteuerte Behandlung von Verkehr hinsichtlich Eigenschaften wie Verzögerung, Verlustrate und verfügbarer Datenrate. QoS ist kein Gütesiegel für die ganze Verbindung. Es beschreibt Mechanismen und vereinbarte Eigenschaften innerhalb bestimmter Grenzen.
Drei Entscheidungen auseinanderhalten
Im 5G-System wird Verkehr in QoS Flows behandelt. Ein solcher Flow ist eine Gruppe von Datenpaketen, die dieselbe QoS-Behandlung erhalten soll. Die Anwendung muss deshalb passend auf die Behandlung im Transport abgebildet werden; das Wort «Notfall» in der Benutzeroberfläche allein verändert noch keine Netzressource.
Der 5G QoS Identifier (5QI) verweist auf QoS-Eigenschaften eines Flows. Dazu gehören beispielsweise eine Prioritätsstufe für die Paketbehandlung und Vorgaben für Verzögerung und Fehlerrate. Standardisierte und dynamisch zugewiesene 5QI sind zu unterscheiden; ein einzelner Zahlenwert ist ohne Anwendungsprofil kein vollständiges FRMCS-Konzept.
Allocation and Retention Priority (ARP) steuert dagegen Entscheidungen über Zulassung und Beibehaltung eines Flows bei Ressourcenknappheit. ARP umfasst auch, ob ein Flow andere verdrängen darf oder selbst verdrängt werden kann. ARP ist somit nicht der Parameter, der jedes einzelne Sprachpaket in der Warteschlange priorisiert. [S13]
| Frage der Talbahn | Passender Blick |
|---|---|
| Wie werden bereits zugelassene Pakete behandelt? | QoS-Eigenschaften, unter anderem über 5QI |
| Darf bei Knappheit ein neuer Flow zugelassen werden? | ARP und verfügbare Ressourcen |
| Darf bestehender Verkehr dafür weichen? | Verdrängungsregeln und ARP-Eigenschaften |
| Erreicht die Sprache Niko rechtzeitig? | Ende-zu-Ende-Messung einschliesslich Dienst und Endgeräten |
Reservierte Rate ist keine vollständige Zusage
Guaranteed Bit Rate (GBR) bezeichnet eine QoS-Ressourcenart mit vereinbarten garantierten Bitratenparametern. Für Non-GBR besteht diese Art von garantierter Bitrate nicht. Die zugehörigen Flows werden nach den für sie festgelegten QoS-Regeln behandelt, ohne diese GBR-Zusage. Auch GBR ersetzt weder Funkversorgung noch eine vollständige Betrachtung von Anwendung, Dienst, Netz und Endgerät. Unterbrechungen oder ein überlasteter Dienstserver verschwinden nicht durch die Bezeichnung.
Pre-emption, auf Deutsch Verdrängung, bedeutet, dass bestehende Ressourcennutzung zugunsten höher berechtigter Nutzung eingeschränkt oder beendet werden kann. Ob und wie das geschieht, ist festzulegen. Die Talbahn darf daraus nicht ohne Weiteres ableiten, dass jede laufende Kommunikation unterbrochen werden soll.
Ein Network Slice ist ein logisch abgegrenzter Netzbereich mit bestimmten Eigenschaften. Er kann helfen, Verkehr und Zuständigkeiten zu trennen. Gemeinsame Funkstandorte, Energieversorgung oder Rechenressourcen bleiben aber mögliche gemeinsame Engpässe. Auch ein Slice ist deshalb kein Nachweis für die Qualität des Gruppenrufs.
Aus der Aussage wird ein Versuch
Für die Fallakte verlangt die Talbahn einen Versuch mit gleichzeitigem Sprach- und Messverkehr. Sie legt vorab Last, Messgrenzen, erwartete Behandlung und Fehlerbedingungen fest. Der Nachweis muss die Zuordnung zwischen Dienstpriorität und Transportregeln einschliessen. Eine erfolgreiche Messung ohne konkurrierende Last beantwortet die Ausgangsfrage nicht.
Die Verbindung zwischen Dienstwunsch und Transportbehandlung
Die Anwendung fordert einen bestimmten Kommunikationszweck beziehungsweise eine Kategorie an. Die Dienstseite verarbeitet diese Angabe nach ihrem Profil und signalisiert die benötigte Behandlung. Erst die passende Transport-Policy setzt diese Anforderung auf zulässige QoS-Ressourcen um. Policy bezeichnet die Regeln, nach denen das Netz Ressourcen und Behandlung zuordnet. Es gibt deshalb keine allgemeine Gleichung «angeforderte Priorität = 5QI».
Die ETSI-Serviceausgabe beschreibt die Signalisierung der angeforderten Priorität; die 5G-Systemarchitektur erklärt die Transportmechanismen. Die Talbahn zeichnet die Übergabe zwischen beiden ein und prüft die implementierte Zuordnung. [S09, Abschnitt 6.2.5; S13]
Im Versuch konkurriert ein Sprachruf mit Diagnoseverkehr. Beobachtet werden die Anforderung an der Anwendung, die dienstseitige Einstufung, die zugeordnete Transportbehandlung und das Ergebnis bei beiden Anwendungen. So lässt sich unterscheiden, ob eine falsche Konfiguration, eine abgelehnte Ressourcenzuteilung oder ein anderer Engpass die Wirkung erklärt.
Prüfe dein Verständnis
Ein Anbieter zeigt einen GBR-Flow und erklärt damit den Notruf als nachgewiesen. Welche drei Ergänzungen verlangst du?
Musterantwort
Ich verlange erstens die Zuordnung der Dienstanforderung zu 5QI, ARP und Verdrängungsregeln. Zweitens brauche ich die betrachteten Grenzen und die Behandlung bei Ressourcenknappheit. Drittens fordere ich einen Ende-zu-Ende-Test unter definierter Last, einschliesslich Dienst, Endgeräten und Ausfallbedingungen. GBR allein belegt diese Punkte nicht.
Das nimmst du mit
Paketbehandlung, Zulassung und tatsächliche Dienstqualität sind verschiedene Prüfgegenstände.
Deine Talbahn-Fallakte
Ergänze für den Gruppenruf die Zuordnung von Dienstpriorität, QoS-Behandlung und Zulassung. Beschreibe einen Lastfall und das zu beobachtende Ergebnis.
Quellen
S09 · ETSI TS 103 765-2: FRMCS Service Stratum
ETSI TS 103 765-2: FRMCS Service Stratum
Version: 1.1.1, Januar 2026 · Geprüft: 2026-10-11
Bezug: Dienstarchitektur; Begriffsdefinition SIP Core; Registrierung und MC-Dienste.
Geltungsgrenze: IMS und SIP nicht gleichsetzen; Architektur erlaubt die spezifizierten SIP-Core-Alternativen.
Verwendet in: 1.9, 2.1, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 2.10, 2.14, 2.19, 2.22, 3.5, 3.16
S13 · 3GPP TS 23.501, veröffentlicht als ETSI TS 123 501
3GPP TS 23.501, veröffentlicht als ETSI TS 123 501
Version: 16.14.0, September 2022 · Geprüft: 2026-10-11
Bezug: Abschnitt 5.7: QoS Flow, 5QI, ARP, GBR und Non-GBR.
Geltungsgrenze: Explizite Begriffsreferenz, nicht als neueste Ausgabe oder vollständige FRMCS-Projektbaseline verwendet.
Verwendet in: 2.2, 2.3, 2.10, 2.18
Dein Fortschritt wird in diesem Browser auf diesem Gerät gespeichert.