FRMCS-End-to-End-Architektur

Ein Ruf und ein Datenpaket durch dasselbe System

Lea fährt Zug 1234 und spricht mit Niko in der Leitstelle. Gleichzeitig soll eine Fahrzeuganwendung Daten mit einer streckenseitigen Anwendung austauschen. Beide Vorgänge nutzen FRMCS, haben aber unterschiedliche Endpunkte und Dienstabläufe. Eine End-to-End-Architektur erklärt diese vollständigen Beziehungen. Sie zeigt Funktionen und Schnittstellen, nicht zwingend die Anzahl physischer Geräte.

Eine Schnittstelle legt fest, wie zwei Funktionen Informationen austauschen. Ein Referenzpunkt bezeichnet die in der Architektur benannte Grenze zwischen ihnen. OBAPP ist der fahrzeugseitige Anwendungsbezugspunkt; TSAPP ist sein streckenseitiger Anwendungsbezugspunkt. Die Abkürzungen werden später technisch vertieft. Hier zeigen sie, wo eine Bahnanwendung FRMCS-Funktionen nutzt. [S07; S10]

Die Architektur in zwei Blickrichtungen lesen

Horizontal verfolgt die Karte Fahrzeug, Infrastruktur und Gegenstelle. Vertikal trennt sie die Anwendung, die Kommunikationsdienste und den Transport. Das Service-Stratum organisiert Kommunikationsdienste. Das Transport-Stratum überträgt deren Steuerungs- und Nutzdaten. Ein MCX-Client ist die Software, die einen Mission-Critical-Dienst nutzt; die zugehörigen Serverfunktionen bearbeiten dessen Anfragen. Eine Gateway-Funktion vermittelt hier die Anwendungsanbindung, ohne selbst zur ETCS- oder ATO-Anwendung zu werden.

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

Die Karte ist eine Funktionssicht. Der Funkzugang verbindet die Bordausrüstung mit dem Mobilfunknetz. Im Kernnetz gibt es getrennte Funktionen für Verbindungssteuerung und Paketweiterleitung. Die Dienstplattform liegt funktional darüber: Sie ist kein Bestandteil der Funkbasisstation und keine zusätzliche Paketweiterleitungsfunktion. [S07; S08; S09]

Im folgenden Datenbeispiel ist die Bahnanwendung lose gekoppelt. Sie nutzt die Anbindung der FRMCS-Ausrüstung, in der die benötigten MCX-Client-Funktionen liegen. Die Anwendung stellt diese Funktionen hier nicht selbst bereit. Lektion 2.6 vertieft die Kopplungsvarianten.

MCPTT (Mission Critical Push To Talk) ist der hier betrachtete Sprachdienst mit geregeltem Sprechrecht. MCData bezeichnet die Mission-Critical-Datendienste. Beide gehören zur MCX-Dienstefamilie. Ein Radio Block Centre (RBC) ist dagegen die streckenseitige ETCS-Einrichtung; es verarbeitet Zugbeeinflussungsinformationen und ist keine allgemeine FRMCS-Gateway-Funktion.

Den Sprachweg verfolgen

Lea fordert einen Ruf an. Ihr Client sendet Steuerinformationen an die zuständigen Dienstfunktionen. Diese bearbeiten die Sitzung und die vorgesehenen Teilnehmer. Wenn Lea sprechen darf, werden Sprachpakete über den eingerichteten Medienweg zu den Empfängern übertragen. Der SIP Core unterstützt die Sitzungssteuerung; SIP ist das dafür verwendete Signalisierungsprotokoll. Er ist nicht automatisch eine Durchgangsstation für jedes Sprachpaket. Die Dienstlektion erklärt die Aufgabenteilung genauer.

Nikos Arbeitsplatz verarbeitet die empfangenen Medien und gibt Audio aus. Eine erfolgreiche Antwort auf die Rufanforderung und hörbare Sprache sind deshalb verschiedene Beobachtungen. Wir wählen im Kurs ausdrücklich eine Leitstellenanbindung über TSAPP; andere spezifizierte Anbindungsvarianten werden in der Dispatcher-Lektion abgegrenzt.

Den Datenweg verfolgen

Die Datenanwendung fordert eine Verbindung zu ihrem Gegenüber an. In unserem lose gekoppelten Lehrfall übernehmen die FRMCS-Komponenten die MCData-Client-Verfahren. MCData bezeichnet Mission-Critical-Datendienste. Die streckenseitige Gateway-Funktion bindet die Gegenanwendung an und meldet ihr ankommende Sitzungen beziehungsweise Zustandsänderungen. Erst nach erfolgreichem Aufbau kann die betrachtete Anwendung ihren benötigten Datenaustausch prüfen. [S09; S42]

Die Dienststeuerung und der eigentliche Datenweg müssen getrennt lesbar sein. Aus der Grafik darf deshalb keine einzige serielle Kette «Anwendung – IMS – MCX – Funk» entstehen. Ebenso liegt die fachliche Verarbeitung einer Nachricht weiterhin bei der Bahnanwendung: Ein übermitteltes Paket ist noch keine gültige ETCS-Fahrterlaubnis.

Prüfe dein Verständnis

Ein Anbieter zeichnet alle Pakete durch den SIP Core und nennt den Trackside Gateway «RBC». Welche zwei Korrekturen sind nötig? Wo würdest du messen, wenn die Sitzung besteht, aber die Gegenanwendung keine Daten erhält?

Musterantwort

Sitzungssteuerung und Nutzdatenweg sind zu trennen; aus der Beteiligung des SIP Core folgt kein universeller Medienpfad durch ihn. Der Gateway bindet die streckenseitige Anwendung an, übernimmt aber nicht deren ETCS-Funktion. Ich prüfe zunächst die Zuordnung zur richtigen Sitzung und erfasse Daten vor und nach der FRMCS-Anwendungsanbindung sowie an der Gegenanwendung. Erst vergleichbare Beobachtungen grenzen den Fehler ein.

Das nimmst du mit

Eine End-to-End-Architektur erklärt Partner, Funktionsaufteilung, Schnittstellen und Wege. Steuerungs- und Nutzdaten können unterschiedliche logische Funktionen durchlaufen.

Deine Talbahn-Fallakte

Lege zwei farblich getrennte Wege auf der Architekturkarte an: Sprache und Daten. Markiere für jeden die Anwendungsgrenzen und die Beobachtung, die einen nutzbaren Austausch belegt.