Zum Inhalt springen
Unabhängige Referenz zum Future Railway Mobile Communication System

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]

Transport- und Servicebereitschaft werden separat verfolgt; die Anwendung bewertet ihre Kommunikation.
G15 · Eigene vereinfachte Lehrdarstellung. Transport- und Servicebereitschaft werden separat verfolgt; die Anwendung bewertet ihre Kommunikation.

Grafik in voller Grösse öffnen (SVG, neuer Tab) G15

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

    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

Gemeinsames Quellenregister

Dein Fortschritt wird in diesem Browser auf diesem Gerät gespeichert.