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

Anwenden · 2.22

Abschlussfall: drei Kommunikationswege

Zeit: etwa 7–10 Minuten einschliesslich Aufgabe; Schätzung

Leitfrage: Kannst du drei Kommunikationswege samt Fehlerfällen erklären?

Lernziel: Du erklärst drei vollständige Kommunikationswege samt Fehlerzuordnung.

Voraussetzungen: Die vorausgehenden Lektionen bis 2.21; insbesondere die dort erklärte Fallakte.

Drei Wege, ein gemeinsames Verständnis

Die Talbahn bereitet einen Integrationsversuch vor. Lea fährt FRMCS-Zug 1234; Niko arbeitet am Dispatcher Terminal. Für den gemischten Sprachfall fährt Amir ausdrücklich GSM-R-Zug 5678. Das separate FRMCS-Testgerät aus dem MCPTT-Lehrablauf ist in diesem Versuch nicht Amirs Fahrzeugausrüstung. Eine Diagnoseanwendung überträgt zusätzlich Fahrzeugdaten. Alle Angaben beschreiben einen fiktiven Lehrfall.

Die Aufgabe verbindet die zuvor erklärten Funktionen. Für jeden Weg werden Ausgangspunkt, Gegenstelle, Anwendungsanbindung, Dienst, Transport und Erfolgskriterium benötigt. Eine Architekturzeichnung allein reicht nicht: Du ergänzt, wie die Kommunikation vorbereitet, aufgebaut, benutzt und beendet wird.

Dein Auftrag

Erstelle drei kommentierte Wege: einen FRMCS-Sprachruf zwischen Lea und Niko, einen Datenfall zwischen Fahrzeug- und Streckenanwendung sowie einen gemischten Ruf mit Amir über die IWF. Kennzeichne bei jedem Steuerung und Nutzdaten. Beschreibe anschliessend einen Fehler: Dienstautorisierung fehlt, Gegenanwendung lehnt ab oder IWF fällt aus. Weise die Fehler jeweils dem passenden Weg zu.

Musterlösung

Beim Sprachruf sind Netz- und Dienstzugang vorbereitet. Die gewählte Sprachanwendung nutzt ihre MCPTT-Client-Funktionen. SIP-basierte Steuerung unterstützt den Aufbau; dienstspezifische Funktionen bestimmen Teilnahme und Sprechrecht. Medien müssen bis zur richtigen Audioausgabe gelangen. Fehlende Dienstautorisierung wird nicht durch einen erfolgreichen Funkzugang behoben.

Beim Datenfall nutzen wir die lose gekoppelte H2H-Variante. Die Fahrzeuganwendung fordert ihre Sitzung an. MCData und die streckenseitige Anbindung verbinden die vorgesehenen Partner. Lehnt die Gegenanwendung ab, ist dies ein anderer Befund als Paketverlust nach erfolgreichem Aufbau. Die Anwendungsgrenze, das Gateway und der Dienst erhalten getrennte Beobachtungen.

Beim gemischten Ruf wird die IWF nur für ihren nachgewiesenen Funktionsumfang eingeplant. Identitäten, Rufverhalten, Sprechsteuerung, Medien und Priorität benötigen eine passende Abbildung. Ein IWF-Ausfall kann den systemübergreifenden Weg unterbrechen, obwohl FRMCS-interne Kommunikation weiter funktioniert. Ein Ersatzverfahren wird nur dann genannt, wenn Ausrüstung, Berechtigung und freigegebener Ablauf bestehen.

Für keinen Weg genügt das Etikett «FRMCS vorhanden». Die Talbahn benötigt die Kombination aus Anwendungsprofil, Implementierung und beobachtbarem Ergebnis. [S07; S09; S11; S42]

Selbstbewertung

Bewerte sechs Kriterien mit jeweils 0 Punkten für fehlend/falsch, 1 für teilweise und 2 für nachvollziehbar: richtige Partner; Anwendungsanbindung; Dienstzustände; Trennung Steuerung/Nutzdaten; Fehlerzuordnung; passender Nachweis. Maximal sind 12 Punkte möglich. Für den Übergang zu Stufe 3 sind mindestens 10 Punkte sinnvoll. Unabhängig davon müssen Dienst und Transport getrennt bleiben und die IWF darf nicht als universeller Funktionskonverter dargestellt werden.

Das nimmst du mit

Du kannst nun eine Kommunikation durch die Architektur verfolgen und Beobachtungen den richtigen Funktionen zuordnen. Stufe 3 verwendet dieses Verständnis für Projektentscheidungen.

Deine Talbahn-Fallakte

Bewahre die drei Wege als Referenz auf. Ergänze offene technische Fragen ausdrücklich; ersetze sie nicht durch angenommene Produkteigenschaften.

Quellen

  • S07 · ETSI TS 103 764: FRMCS System Architecture

    ETSI TS 103 764: FRMCS System Architecture

    Version: 1.1.1, Januar 2026 · Geprüft: 2026-10-11

    Bezug: Architekturabschnitte: FRMCS-Systemgrenze, Service und Transport, nutzende Anwendungen.

    Geltungsgrenze: Grafiken im Lehrgang sind eigene Vereinfachungen, keine normativen Referenzbilder.

    Verwendet in: 1.3, 1.5, 1.8, 1.9, 1.10, 2.1, 2.22

  • 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

  • S42 · ETSI TS 103 765-4: Trackside functions and interfaces

    ETSI TS 103 765-4: Trackside functions and interfaces

    Version: 1.1.1 (2026-01) · Geprüft: 2026-10-11

    Bezug: Abschnitte 4–6: Trackside Gateway, Kontext und Verfahren.

    Geltungsgrenze: Benannte Lehrausgabe; keine pauschale Produkt- oder Projektfreigabe.

    Verwendet in: 2.1, 2.9, 2.12, 2.22, 3.3, 3.5

Gemeinsames Quellenregister

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

Ende dieser StufeStufenübersichtWeiter mit Stufe 3: Gestalten →