Skip to content
Independent reference on the Future Railway Mobile Communication System

Design · 3.16

Final case: an evidence-based decision paper

Time: about 11–14 minutes including the task; estimate

Guiding question: Which specific next step can you justify with your evidence?

Learning objective: You create a consistent decision paper with a bounded approval scope.

Prerequisites: Previous lessons through 3.15, particularly the case file developed there.

A decision on a limited next step

You are preparing approval of a Talbahn pilot. Lea uses FRMCS train 1234 and Niko the defined dispatcher workstation. Amir drives GSM-R train 5678 in the mixed trial. The pilot covers operational voice and a diagnostic application. ETCS and ATO are assessed as separate integration packages; their operational approval is not inferred from this pilot.

A decision paper states what can be decided, what remains open and which conditions apply. Use the architecture and evidence work from all three levels. The task does not require invented supplier capabilities or blanket V3 claims.

Your task: eight connected elements

Describe the need and participating roles; voice and data architecture; application interfaces; specification baseline and applicability; migration and IWF; test and acceptance criteria; operations and protection; costs and decision. Each element must fit the others. If public access is proposed, for example, its permission, performance, failure testing and costs must also appear in the other elements.

Worked model solution

Need: Niko must reach the intended drivers. The diagnostic application must supply agreed vehicle data. Success is measured through usable speech or processed data.

Architecture: Voice uses the selected VAS profile and its MCPTT client functions. Data uses loose coupling and MCData IPCon. The architecture separates control, media or data, and management dependencies. [S06; S09; S10]

Interfaces: Assign OBAPP and TSAPP to the correct sides. The dispatcher VAS uses the course's selected TSAPP variant; the data case considers the Trackside Gateway and its application context. Unconfirmed RAS functions remain concrete supplier questions.

Baseline: Name document versions and distinguish teaching editions, the legally referenced baseline and product implementation. An expected V3 milestone is not product evidence. Status and timeline

Migration: Approve only the demonstrated IWF scope for Amir. The IWF function matrix covers identities, call behaviour, media, priority and failure cases. Prepare return to the previous approved state.

Tests: Test voice under defined load with speaker changes. For data, test acceptance, rejection, restart and recovery. Public access gets its own load and failure trial. ETCS/ATO approvals remain outside this decision.

Operations and protection: Assign identity, configuration, key, service-monitoring and incident-leadership responsibilities. Investigate common failure causes despite multiple transport paths.

Costs and decision: Compare costs over the same period and functional scope. Include integration and operating costs from 3.15. Approve only the evidenced pilot scope; assign owners, checks and clear completion criteria to outstanding conditions.

Self-assessment

Award 0 per element for missing/incorrect, 1 for plausible but incomplete and 2 for consistent with named evidence. The maximum is 16 points. From 13 points, the paper is well prepared for technical discussion. Regardless of the total, incorrect roles, unjustified conformity claims or untested safety approvals prevent a positive assessment. This is self-assessment, not a certificate or real project acceptance.

What to remember

A sound decision connects actual needs with architecture, requirements, evidence and operations. Open issues are made decidable rather than hidden in wording.

Your Talbahn case file

Finish with “Approved scope”, “Conditions”, “Scope not decided” and “Next evidence”. The case file is now a coherent decision paper.

Sources

  • S06 · UIC FRMCS SRS AT-7800

    UIC FRMCS SRS AT-7800

    Version: 2.1.0, 30 April 2025 · Checked: 2026-10-11

    Scope: System requirements, architecture, service/transport interaction and mobility. Functional Alias: 11.6/21.3; voice profiles: 24.2.3.3 and 24.3.3.2–4; TSCTRL: 6.4.1.3.

    Limitations: The project baseline must specify the applicable parts.

    Used in: 1.3, 2.4, 2.7, 2.9, 2.11, 2.13, 2.15, 2.16, 2.17, 2.18, 2.19, 3.2, 3.3, 3.16

  • S09 · ETSI TS 103 765-2: FRMCS Service Stratum

    ETSI TS 103 765-2: FRMCS Service Stratum

    Version: 1.1.1, January 2026 · Checked: 2026-10-11

    Scope: Service architecture; SIP Core definition; registration and MC services.

    Limitations: Do not equate IMS with SIP; the architecture allows the specified SIP Core alternatives.

    Used 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

  • S10 · UIC FRMCS FFFIS FFFIS-7950

    UIC FRMCS FFFIS FFFIS-7950

    Version: 2.1.0 · Checked: 2026-10-11

    Scope: 5.1/5.2 OBAPP, 5.3/5.4 TSAPP, 5.6 Tight Coupling, 5.7 Loose Coupling; 6.3/6.6/6.7 security references.

    Limitations: Application interfaces, not general operating rules for control centres.

    Used in: 2.1, 2.6, 2.11, 3.2, 3.3, 3.16

Shared source register

Your progress is stored in this browser on this device.

End of this levelLevel overview