Zusammenfassung

  • draft-ietf-radext-epcs-00 definiert drei RADIUS-Attribute für EPCS-Fähigkeit, regulatorischen Geltungsbereich, Berechtigung und Prioritätsstufe; der Text ist weiterhin ein Internet-Draft.
  • Ein Access-Accept belegt die Entscheidung des AAA-Servers, nicht die Aktivierungsanforderung des Access Points, die Annahme durch das Endgerät, zugeteilte Funkzeit oder den Anwendungserfolg.
  • Belastbare Betriebsführung verbindet getrennte Belege von externer Autorität und Teilnehmerkonto über Assoziation, RADIUS, Geräteverhandlung und Paketbehandlung bis zum Ergebnis.

In einem kabelgebundenen Kontrollsystem lässt sich eine Prioritätszahl leicht mit einer Warteschlange verbinden. Im WLAN teilt sich dieselbe Entscheidung auf mindestens zwei Sender auf: Access Point und Station. Schon deshalb kann eine erfolgreiche Autorisierung nicht gleichzeitig der Nachweis ihrer Ausführung sein.

Der von RADEXT im September 2026 angenommene Entwurf setzt den Anfang außerhalb des Netzzugangs. Eine externe Stelle erteilt die Berechtigung nach einem regulatorischen Regime. Der Dienstanbieter führt sie im Teilnehmerdatensatz. Der WLAN-Anbieter spiegelt den relevanten Zustand in sein AAA-System. Über Passpoint und eine Roaming Consortium Organization Identifier kann der Nutzer ein Netz auswählen, sich assoziieren und per EAP die für RADIUS relevante Identität herstellen.

Erst dann folgt der Austausch. Diese Reihenfolge schützt vor einer verbreiteten Verwechslung: Das Attribut erzeugt keine Berechtigung, sondern überträgt eine vorangegangene Entscheidung. Ein veralteter Datensatz, eine falsche Realm-Zuordnung oder ein unzutreffender Standort können dennoch ein syntaktisch korrektes Paket erzeugen. Das Serverprotokoll belegt die Antwort; Autoritätsreferenz, Gültigkeit und Rechtsraum belegen ihre Grundlage.

EPCS-Capable-Indication kann im Access-Request erscheinen und hat 32 Bit. Wert 0 erklärt, dass der NAS Priorität unabhängig von der EPCS-Fähigkeit des Geräts bereitstellen kann. Ein nichtfähiges Gerät erhält möglicherweise nur Downlink-Behandlung, ein fähiges Gerät Up- und Downlink. Wert 1 beschränkt Priorität auf EPCS-fähige Geräte; Flüsse eines nichtfähigen Geräts werden nicht bevorzugt. Beide Werte beschreiben Fähigkeit, nicht beobachtete Ausführung.

Die Richtungsabhängigkeit ist technisch folgenreich. Den Downlink plant der Access Point. Für den Uplink muss die Station ihr Verhalten mittragen. Deshalb kann nach der AAA-Entscheidung noch eine EPCS-Aktivierungsanforderung des AP oder Controllers und eine Antwort der Station nötig sein. Eine fehlende, abgelehnte oder anders interpretierte Anforderung ändert nicht den AAA-Beleg, wohl aber die Wirkung auf dem Funkkanal.

EPCS-Regulatory-Info kommt im Access-Accept zurück und bezeichnet Land sowie gegebenenfalls Untereinheit nach ISO 3166-1 und 3166-2. Der Rechtsraum bleibt damit an die Entscheidung gebunden. Das Feld bestätigt jedoch weder Quelle noch Aktualität des Standorts. Beim Roaming kann dieselbe Identität unter eine andere Regel fallen. Standortbeleg und Beobachtungszeit gehören deshalb zum Datensatz.

Die Anwesenheit von EPCS-Subscription-Info sagt, dass der authentisierte Nutzer für EPCS berechtigt ist. Der 32-Bit-Wert trägt die vom Regime verwaltete Prioritätsstufe. Wie daraus Klassifizierung, Queue-Auswahl oder Funkplanung entsteht, bleibt ausdrücklich herstellerspezifisch und außerhalb des Entwurfs. Gleiche Attribute können daher unterschiedliche Laufzeitwirkungen haben.

Offen bleibt außerdem, welche Pakete zur berechtigten Kommunikation gehören. Sämtlichen Verkehr eines Teilnehmers zu bevorzugen wäre eine weitreichendere Regel als ausgewählte Flüsse zu erkennen. Controller und AP müssen klassifizieren, der Scheduler muss die beabsichtigte Behandlung umsetzen, nachgelagerte Netze müssen sie erhalten oder übersetzen, und der Dienst muss antworten. Priorität verändert Reihenfolge, schafft aber weder Spektrum noch Backhaul- oder Serverkapazität.

Ein belastbarer Nachweis umfasst daher: externe Autorisierung und Gültigkeitsfenster; Teilnehmer und Realm; Station, AP und Controller; Assoziationszeit; Roaming-Konsortium und civic location; exakte Attribute von Anfrage und Antwort; Regime und Stufe; Aktivierungsanforderung und Geräteantwort; Klassifikationsregel; Queue und Markierung; Funkzeit, Wiederholungen und Latenz; Weitergabe im übrigen Netz; Anwendungsergebnis. Eine Lücke bleibt eine Lücke.

Der Transport ist nur ein Abschnitt. Außerhalb eines sicheren Netzes verlangt der Entwurf IPsec, TLS oder DTLS für RADIUS. Das schützt Gegenstellen und Übertragung. Es validiert nicht den Teilnehmerdatensatz, den Standort, die Klassifikation oder die Aktion des Schedulers. Ein geschützter Kanal kann eine falsche Aussage unverändert transportieren.

Öffentliche Erläuterungen der US-amerikanischen Wireless Priority Service markieren eine hilfreiche, aber nicht normative Grenze. CISA beschreibt höhere Abschlusswahrscheinlichkeit bei Überlast, keine Verdrängung laufender Gespräche und keinen Ausschluss der Öffentlichkeit; Roaming kann den Nutzen mindern. Das sind Eigenschaften eines betriebenen Programms, keine automatisch geltenden Anforderungen dieses Entwurfs. Sie zeigen dennoch: Bevorzugung ist keine Garantie.

Auch der Standardisierungsstatus bleibt begrenzt. RADEXT hat die Arbeit angenommen, und sie zielt auf Standards Track. Revision 00 steht aber bei I-D Exists. Eine Arbeitsgruppenannahme ist weder IETF-Endkonsens noch RFC, Produktinteroperabilität oder Nachweis eines realen Netzes.

Der Entwurf schafft sinnvollerweise ein Mindestvokabular für bislang proprietäre Übergaben. Im Sinne von Heng Lu koordiniert eine minimale Anfangsspezifikation gemeinsame Schnittstellen, ohne spätere lokale Entscheidungen zu zentralisieren. RADIUS kann Fähigkeit, Rechtsraum, Recht und Stufe tragen. Laufender Code muss die anschließende Wirkung belegen.

Quellen