FRMCS end-to-end architecture

A call and a data packet through the same system

Lea drives train 1234 and speaks to Niko in the control centre. At the same time, an on-board application needs to exchange data with a trackside application. Both use FRMCS, but their endpoints and service procedures differ. An end-to-end architecture explains these complete relationships. It shows functions and interfaces, not necessarily a count of physical devices.

An interface defines how two functions exchange information. A reference point names the architectural boundary between them. OBAPP is the on-board application reference point; TSAPP is the trackside application reference point. Later lessons examine them technically. Here, they identify where railway applications use FRMCS functions. [S07; S10]

Read the architecture in two directions

Horizontally, the map follows the train, infrastructure and remote endpoint. Vertically, it separates the application, communication services and transport. The service stratum organises communication services. The transport stratum carries their control traffic and user data. An MCX client is software that uses a Mission-Critical service; the associated server functions process its requests. A gateway function provides application integration here, without becoming the ETCS or ATO application itself.

Open diagram at full size (SVG, new tab) G09

This is a functional map. Radio access connects on-board equipment to the mobile network. The core network has separate connection-control and packet-forwarding functions. The service platform sits logically above them: it is neither part of the radio base station nor an additional packet-forwarding function. [S07; S08; S09]

In this data example, the railway application is loosely coupled. It uses the connection provided by the FRMCS equipment, where the required MCX client functions reside. The application does not provide these functions itself here. Lesson 2.6 explains the coupling variants further.

MCPTT (Mission Critical Push To Talk) is the voice service considered here, with controlled permission to speak. MCData denotes Mission-Critical data services. Both belong to the MCX family. A Radio Block Centre (RBC), in contrast, is a trackside ETCS entity processing train-protection information, not a general FRMCS gateway function.

Follow the voice path

Lea requests a call. Her client sends control information to the responsible service functions. They handle the session and intended participants. Once Lea is allowed to speak, voice packets travel to the recipients through the established media path. The SIP Core supports session control; SIP is the signalling protocol used for it. The SIP Core is not automatically a transit point for every voice packet. The service lesson explains this division of work in more detail.

Niko's workstation processes the received media and plays audio. A successful response to a call request and audible speech are therefore separate observations. The course explicitly selects a control-centre integration using TSAPP; the dispatcher lesson distinguishes other specified integration variants.

Follow the data path

The data application requests a connection to its counterpart. In our loosely coupled teaching case, FRMCS components perform the MCData client procedures. MCData denotes Mission-Critical data services. The trackside gateway function integrates the remote application and notifies it of incoming sessions or state changes. Only after successful establishment can the application verify its required data exchange. [S09; S42]

Service control and the actual data path must remain separately readable. The diagram must not imply a single serial chain of “application – IMS – MCX – radio”. Responsibility for interpreting a message also remains with the railway application: a delivered packet is not yet a valid ETCS movement authority.

Check your understanding

A supplier draws all packets through the SIP Core and labels the Trackside Gateway “RBC”. What two corrections are required? Where would you measure if a session exists but the remote application receives no data?

Model answer

Separate session control from the user-data path; participation of the SIP Core does not imply that all media passes through it. The gateway integrates the trackside application but does not perform its ETCS function. First verify assignment to the correct session, then capture data before and after FRMCS application integration and at the remote application. Comparable observations are needed to isolate the fault.

What to remember

An end-to-end architecture explains partners, functions, interfaces and paths. Control traffic and user data may traverse different logical functions.

Your Talbahn case file

Draw two colour-coded paths on the architecture map: voice and data. Mark the application boundaries and the observation that demonstrates usable communication for each.