Anwenden · 2.7
Identitäten, Dienstanmeldung und Functional Alias
Zeit: etwa 9–12 Minuten einschliesslich Aufgabe; Schätzung
Leitfrage: Wie wird eine betriebliche Funktion erreicht, wenn Personen und Geräte wechseln?
Lernziel: Du trennst Netzidentität, Dienstzugang und betriebliche Zuordnung.
Voraussetzungen: Die vorausgehenden Lektionen bis 2.6; insbesondere die dort erklärte Fallakte.
Bekanntes Gerät, berechtigter Nutzer, aktuelle Rolle
In 1.2 hatten Lea und Amir je ein eigenes erreichbares Endgerät; der Ruf an die Funktion erreichte noch Leas Gerät. Nun nehmen wir diesen Wechsel im Pilotaufbau vor. Drei Zuordnungen müssen auseinandergehalten werden.
Eine Identität bezeichnet einen Teilnehmer oder eine Funktion im jeweiligen Systemkontext. Die Netzteilnehmeridentität erlaubt die Zuordnung zum Mobilfunkzugang. Die Dienstnutzeridentität bezeichnet den Nutzer im Kommunikationsdienst. Die Funktionsidentität beschreibt die betriebliche Rolle, unter der der Nutzer erreichbar sein soll. Keine dieser Angaben beantwortet allein alle anderen Fragen.
Ein Functional Alias ist eine funktionale Bezeichnung im MC-/FRMCS-Kontext. Er ermöglicht, einen Kommunikationspartner über eine betriebliche Funktion statt nur über eine dauerhaft personenbezogene Zielangabe anzusprechen. Die Zuordnung zum berechtigten Nutzer muss aktiv und gültig sein. [S05, S06, Abschnitte 11.6 und 21.3]
Die SIM beziehungsweise das zugehörige Teilnehmerprofil unterstützt die Identifizierung für den Netzzugang. Es enthält die dafür vorgesehenen Teilnehmer- und Sicherheitsinformationen, nicht automatisch die aktuelle betriebliche Rolle. Daraus folgt nicht automatisch, dass Amir die aktuelle Lokführerrolle übernommen hat. Geräteübergabe und Rollenübergabe sind verschiedene Vorgänge. Das Teilnehmerprofil beschreibt den Netzzugang; es ist nicht das physische Gerät. In dieser Lektion verfolgen wir die Zuordnung zwischen Netzzugang, Dienstnutzer und Funktion.
Der Lebenszyklus einer Zuordnung
Ein Lebenszyklus beschreibt hier die Zustände vom Anlegen bis zum Beenden einer Zuordnung. Für die Talbahn betrachten wir vier Lehrzustände:
| Zustand | Zu klärende Aussage |
|---|---|
| Vorher | Lea ist für die betrachtete Funktion zugeordnet |
| Übernahme angefordert | Amir beantragt die Rolle; daraus folgt noch kein bestätigter Wechsel |
| Neue Zuordnung bestätigt | Das System hat den vorgesehenen Wechsel nach den festgelegten Regeln angenommen |
| Nachher | Neue Funktionsrufe erreichen Amir; Leas bisherige Zuordnung ist entsprechend beendet |
Diese Tabelle ist kein vorgeschriebenes Protokoll. Sie macht den Nachweisbedarf sichtbar. Was bei doppelter Anmeldung, Verbindungsverlust oder verspäteter Bestätigung geschieht, muss konkret festgelegt werden.
Funktion und Ort getrennt halten
«Lokführer Zug 1234» beschreibt eine Funktion. «Zuständige Stelle für diesen Abschnitt» bezieht zusätzlich eine örtliche Zuständigkeit ein. Eine Standortinformation muss nach Regeln einem Ziel zugeordnet werden; sie entscheidet nicht selbst über betriebliche Verantwortung.
Beim Interworking mit GSM-R müssen die vorgesehenen Identitäten über die Systemgrenze abgebildet werden. Eine richtige Namensanzeige beweist noch keinen richtigen Rückruf oder Gruppenbeitritt. Deshalb wird das Verhalten in beiden Richtungen geprüft. [S11]
Die Dienstanmeldung vor dem Rollenruf
Die Registrierung im Mobilfunknetz, die SIP-Registrierung und die MC-Dienstautorisierung sind eigene Vorgänge. Im Dienstanmeldeverfahren werden Identität geprüft, ein geeignetes Profil verwendet und die erlaubten MC-Dienste autorisiert. Ein Access Token ist ein technischer Berechtigungsnachweis mit begrenztem Geltungsbereich; es ist weder eine Zugnummer noch eine betriebliche Rolle. Die Service-Spezifikation beschreibt die vorbereitenden Schritte und die dienstbezogene Autorisierung. [S09, Abschnitt 6.1]
Ein abgelaufener Nachweis kann neue Dienstnutzung verhindern, obwohl ein Gerät weiterhin im Funknetz registriert ist. Die Talbahn protokolliert daher je Zustand Zeitpunkt, Identität und zuständige Funktion. Erst auf dieser Grundlage wird die Rolle «Lokführer Zug 1234» dem vorgesehenen Dienstnutzer zugeordnet. Eine Rollenübergabe darf die unabhängige Prüfung der Dienstberechtigung nicht ersetzen.
Prüfe dein Verständnis
Nach Amirs Rollenübernahme erreichen Rufe weiterhin Lea. Welche Information brauchst du vor einer Ursachenfestlegung? Formuliere einen positiven und einen konfliktbezogenen Testfall.
Musterantwort
Benötigt werden der angeforderte und bestätigte Zuordnungszustand mit Zeitbezug, die tatsächlich verwendete Zielauflösung und die vereinbarten Konfliktregeln. Positiv: Nach bestätigtem Wechsel erreicht Niko Amir über die Funktion. Konfliktfall: Eine zweite gleichzeitige Übernahme wird nach der festgelegten Regel behandelt und dem Nutzer eindeutig angezeigt. Ohne diese Regel lässt sich kein konkretes Sollverhalten erfinden.
Zusätzliche Anwendung
Das Gerät bleibt im Netz registriert, der Dienstzugang wird abgelehnt. Welcher zusätzliche Zustand ist zu prüfen?
Musterantwort
Dienstidentität, Profil und MC-Dienstautorisierung werden getrennt von der Netzanmeldung geprüft. Auch ein abgelaufener Berechtigungsnachweis ist als Hypothese zu untersuchen.
Das nimmst du mit
- Netz-, Dienst- und Funktionsidentität sind verschieden.
- Eine Rollenübernahme braucht bestätigte Zustände und Konfliktregeln.
- Sichtbare Namen ersetzen keine Verhaltensprüfung.
Deine Talbahn-Fallakte
Erweitere den Rollenwechselfall aus 1.3 um Zustände und Nachweisbedarf. Bewahre das noch offene Konfliktverhalten.
Quellen
S05 · UIC FRMCS FRS FU-7120
Version: 2.1.0, 29.04.2025 · Geprüft: 2026-10-11
Bezug: Funktionale Anforderungen, Identitäten, Functional Alias, Sprach- und Gefahrenkommunikation.
Geltungsgrenze: Lehrgrundlage, kein Beleg für vollständige Produktunterstützung.
Verwendet in: 1.2, 1.3, 1.6, 2.7, 2.8, 2.15, 2.20, 3.2
S06 · UIC FRMCS SRS AT-7800
Version: 2.1.0, 30.04.2025 · Geprüft: 2026-10-11
Bezug: Systemanforderungen, Architektur, Dienst-/Transportzusammenspiel und Mobilität. Functional Alias: 11.6/21.3; Sprachprofile: 24.2.3.3 und 24.3.3.2–4; TSCTRL: 6.4.1.3.
Geltungsgrenze: Projektbaseline muss konkrete anwendbare Teile festlegen.
Verwendet in: 1.3, 2.4, 2.7, 2.9, 2.11, 2.13, 2.15, 2.16, 2.17, 2.18, 2.19, 3.2, 3.3, 3.16
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
S11 · ETSI TS 103 792: FRMCS/GSM-R Interworking
ETSI TS 103 792: FRMCS/GSM-R Interworking
Version: 1.1.1, Januar 2026 · Geprüft: 2026-10-11
Bezug: Interworking-Architektur und definierte Funktionsvermittlung.
Geltungsgrenze: Unterstützung pro Funktion und Kombination nachweisen; keine universelle ETCS-Übersetzung.
Verwendet in: 1.10, 2.7, 2.20, 2.22
Dein Fortschritt wird in diesem Browser auf diesem Gerät gespeichert.