The FRMCS map

One exchange, three questions

Lea reports a delay to Niko. We know the participants and the transmission path. Now we organise the tasks in an architecture. An architecture describes important parts of a system and their relationships. Initially, it is an organisation of functions, not a shopping list.

The application fulfils the operational purpose. Here, the operational voice application supports Lea's report to Niko. Niko assesses its content for controlling train movements; the network does not decide what operational conclusion he draws.

The communication service provides the form of exchange. For example, it enables a voice conversation and supports its establishment and execution. The same service can be used for different operational purposes.

Transport carries the data. This includes radio access and further network functions. Usable transport is necessary, but is not sufficient to select the correct conversation partner or establish that person's permission.

Layers and the system boundary

FRMCS organises such tasks into layers, called strata. A stratum groups related functions. The Service Stratum comprises communication services and associated functions. It organises the services needed for the exchange. The Transport Stratum carries their traffic. It provides the underlying transmission. In the ETSI architecture used here, the railway applications using FRMCS are outside the FRMCS system boundary. [S07]

An end-to-end view follows the exchange from a defined starting point to the required result at the other end. It therefore includes the applications when their usable outcome is being assessed.

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

The diagram consequently shows three perspectives, but only two strata inside the FRMCS boundary. Railway applications remain part of the complete path between the communication partners. For Lea's conversation to succeed, application, service and transport must work together.

An interface describes agreed rules for connection and exchange between parts. If Talbahn changes the radio transport, the application purpose and conversation type should remain available. Whether this succeeds also depends on compatible interfaces and performance conditions.

Why the separation helps

This separation makes changes easier to assess specifically. A recipient-selection problem requires a different investigation from a missing radio connection. Similarly, new transport does not automatically require a new operational application. However, interchangeability does not follow without suitable integration and tests.

GSM-R also has distinguishable functions. FRMCS is not the first structured network; it uses a different architecture with explicit separation of service and transport. [S02, S07]

Check your understanding

Talbahn renews radio access. Lea must still be able to report a delay to Niko. Identify application, service and transport. Why is testing necessary despite the unchanged purpose, and where are railway applications in the diagram?

Model answer

The purpose is the operational report, the service is the voice conversation, and transport is the data transmission over radio and further network functions. A transport part changes. Interfaces and performance can still affect the conversation, so the complete required exchange is tested. The railway applications lie outside the illustrated FRMCS system boundary but remain part of end-to-end testing.

What to remember

• Purpose, form of exchange and transmission are different perspectives.
• Here FRMCS comprises service and transport; railway applications use the system.
• Architectural layers do not prescribe a number of physical devices.

Your Talbahn case file

Assign the conversation and measurement transfer to the three perspectives. For measurements, use “required data exchange” for now without assuming a particular service.