Final case: three communication paths

Three paths, one shared understanding

Talbahn is preparing an integration trial. Lea drives FRMCS train 1234; Niko works at the dispatcher terminal. For the mixed voice case, Amir explicitly drives GSM-R train 5678. The separate FRMCS test device from the MCPTT example is not his vehicle equipment in this trial. A diagnostic application also transfers vehicle data. All details belong to a fictional teaching case.

This task connects the previously explained functions. Each path needs an origin, counterpart, application integration, service, transport and success criterion. An architecture diagram alone is insufficient: explain how communication is prepared, established, used and terminated.

Your task

Create three annotated paths: an FRMCS voice call between Lea and Niko, a data case between on-board and trackside applications, and a mixed call with Amir through the IWF. Mark control and user data for each. Then describe a failure: missing service authorisation, rejection by the remote application, or IWF failure. Assign each failure to its appropriate path.

Model solution

For voice, network and service access are prepared. The selected voice application uses its MCPTT client functions. SIP-based control supports establishment; service-specific functions determine participation and floor. Media must reach the correct audio output. Successful radio access does not repair missing service authorisation.

For data, we use the loosely coupled H2H variant. The on-board application requests its session. MCData and trackside integration connect the intended partners. Rejection by the remote application is different from packet loss after successful establishment. Application boundary, gateway and service receive separate observations.

For the mixed call, only the IWF's demonstrated functionality is assumed. Identities, call behaviour, floor control, media and priority need suitable mappings. IWF failure may interrupt the cross-system path while internal FRMCS communication still works. An alternative procedure is proposed only if equipment, permission and an approved procedure exist.

“FRMCS installed” is insufficient for every path. Talbahn needs a combination of application profile, implementation and observable result. [S07; S09; S11; S42]

Self-assessment

Score six criteria with 0 for missing/incorrect, 1 for partial and 2 for explained: correct partners; application integration; service states; control/user-data separation; failure assignment; appropriate evidence. The maximum is 12 points. At least 10 is a useful threshold for level 3. Regardless of score, keep service and transport separate and do not present the IWF as a universal function converter.

What to remember

You can now follow communication through the architecture and assign observations to the correct functions. Level 3 uses this understanding for project decisions.

Your Talbahn case file

Retain the three paths as references. Record open technical questions explicitly rather than replacing them with assumed product capabilities.