Anwenden · 2.19
Service-Domänen und Dienstkontinuität
Zeit: etwa 7–10 Minuten einschliesslich Aufgabe; Schätzung
Leitfrage: Was ändert sich beim Transport- und Service-Domänenwechsel?
Lernziel: Du verfolgst Transport- und Service-Domänenwechsel mit getrennten Zuständen.
Voraussetzungen: Die vorausgehenden Lektionen bis 2.18; insbesondere die dort erklärte Fallakte.
Ein Zug wechselt mehr als Funkzellen
Zug 1234 erreicht das Gebiet einer Nachbarbahn. Die Funkverbindung kann bereits im neuen Netz stehen, während die Dienstnutzung noch einen anderen Zustand hat. Eine Transport-Domäne umfasst die zuständigen Transportfunktionen. Eine Service-Domäne umfasst betriebene Dienstfunktionen. Beide müssen unterschieden werden, auch wenn ein Betreiber beides bereitstellt.
Die Home Service Domain ist die Heimzuordnung des Dienstnutzers. Eine Foreign Service Domain ist eine fremde Dienstdomäne, in der die vorgesehene Dienstnutzung zusätzliche Verfahren benötigt. «Serving» benennt die aktuell bedienende Domäne. Das sind Zustands- und Zuständigkeitsbegriffe, keine geographischen Synonyme für ein Land. [S06; S09, Abschnitte 6.1 und 6.4]
Den Übergang in getrennten Schritten betrachten
Zuerst wird der vorgesehene Transport im Ziel nutzbar. Dann muss für die betroffene Anwendung geklärt sein, ob ihr Dienstnutzer in die Ziel-Service-Domäne wechselt oder weiterhin von seiner Heimdomäne bedient wird. Die Entscheidung folgt dem Anwendungsprofil. Ein bestehender Funkpfad legt sie nicht automatisch fest.
Die SRS unterscheidet für diesen Zweck verschiedene Anwendungstypen. Für die dort als interoperable Infrastrukturbetreiber-Anwendungen beschriebenen Fälle ist die Zuordnung zur Ziel-Service-Domäne relevant. Andere Kategorien haben andere oder in der betrachteten Ausgabe noch offene beziehungsweise spätere Regeln. Eine allgemeine Zusage «alle Anwendungen migrieren immer» wäre deshalb falsch. Die Kennzeichnungen der jeweiligen Fassung bleiben Teil des Nachweises. [S06, Abschnitt 10.1.3.3]
Ein vorhandener Dienstnutzer ist noch kein fortgesetzter Ruf
Nach der Autorisierung im Ziel sind laufende Kommunikation, neue Kommunikation und die Information an die Anwendung getrennt zu prüfen. Dienstkontinuität beschreibt das benötigte Verhalten des Austauschs während des Übergangs. Sie kann nicht allein aus erfolgreicher Registrierung abgeleitet werden. Für den Talbahn-Fall werden Beginn der Unterbrechung, wiederhergestellter Datenfluss und nutzbarer Anwendungszustand beobachtet.
Ein laufender Sprachruf und eine Datensitzung können unterschiedliche Wiederherstellungsverfahren benötigen. Die Anwendung darf deshalb nicht allein aus «Transport verfügbar» auf «alle Funktionen bereit» schliessen. Ebenso sind alte Zuordnungen kontrolliert zu behandeln, damit neue Rufe nicht zu einer veralteten Dienstinstanz gelangen.
Prüfe dein Verständnis
Ein grenzüberschreitender Test zeigt eine erfolgreiche Netzanmeldung und einen neuen Ruf. Welche Aussage über den laufenden Datenfall ist damit noch nicht belegt?
Musterantwort
Nicht belegt sind seine Behandlung während des Übergangs, die richtige Service-Domänenzuordnung und der vollständige Wiederanlauf der Anwendung. Der Test muss Startzustand, Anwendungsprofil, laufende Sitzung und die beobachtete Unterbrechung enthalten. Ein neuer Ruf prüft einen anderen Fall.
Das nimmst du mit
Transportwechsel, Dienstnutzerwechsel und Kommunikationskontinuität sind eigene Zustandsübergänge. Ihr Zusammenspiel hängt vom Anwendungsprofil ab.
Deine Talbahn-Fallakte
Erstelle eine Vorher-/Während-/Nachher-Tabelle für Sprache und Daten. Trage Transport-Domäne, Service-Domäne, Berechtigung und Anwendungszustand getrennt ein.
Quellen
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
Dein Fortschritt wird in diesem Browser auf diesem Gerät gespeichert.