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

Design · 3.5

Testing data services and application integration

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

Guiding question: How do you isolate a data fault between service and application?

Learning objective: You investigate a data fault at service, gateway and application boundaries.

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

The session is active, but the application receives nothing

The train's diagnostic application reports “data session active”. Packets are visible at the Trackside Gateway, but the maintenance process receives no new vehicle values. We use the loosely coupled H2H connection from 2.9 and 2.12. This is a data case; voice Floor Control is not an appropriate first hypothesis.

A measurement point is a defined observation boundary. A correlation attribute links observations of the same activity, for example a session identifier together with time and partners. Packet addresses alone may be insufficient because of tunnelling or address translation. Talbahn therefore defines how to follow the data session across boundaries before the trial. [S09, clause 6.2.2; S42, clause 6.3]

Interpret a fictional event trace

The following entries are teaching-case observations, not normative timing limits.

Order Observation Evidential limit
A On-board application's session request accepted Not yet complete application evidence
B Remote application accepted establishment No promise covering all subsequent data
C User data captured at the Trackside Gateway input Local forwarding still unproven
D Data observed at an old local destination address Suggests an outdated mapping
E New maintenance process reports no data Consistent with the hypothesis, but not proof by itself

The first hypothesis is that an old address or context mapping remained effective after an application restart. Talbahn compares application context, local address and session association before and after the restart. It also checks that captures cover the same session and direction. An incorrect filter could otherwise suggest a technical fault falsely.

Choose a discriminating test

A useful next test distinguishes competing explanations. Talbahn observes forwarding immediately at the current application boundary. If the correct data arrives, investigate application processing. If it arrives at the old address, examine cleanup and reconstruction of the mapping. If the gateway itself has no matching data, investigate the preceding path again.

After a change, previously working procedures are tested again. This regression test checks whether the change has introduced a fault elsewhere.

The correction is then tested with another restart. Manually repairing the address once while omitting the failure scenario is insufficient. Session termination and rejected re-establishment also belong in regression when the same state functions were changed.

Check your understanding

A colleague proposes increasing radio power first. Why is that not the most direct next step here, and what would support the outdated-mapping hypothesis?

Model answer

User data has already been observed at the trackside gateway; the notable finding is the old local destination address. Check context and forwarding first. A consistent association of the same session with the old address after restart would support the hypothesis. The cause remains provisional until tested specifically.

What to remember

Data diagnosis connects service states, packet paths and application context. An active-session indication is not complete data or functional evidence.

Your Talbahn case file

Add observation boundaries, correlation attributes, hypothesis, discriminating test and repetition of the original failure scenario.

Sources

  • 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

  • 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) · Checked: 2026-10-11

    Scope: Clauses 4–6: Trackside Gateway, context and procedures.

    Limitations: Named teaching edition; no blanket product or project approval.

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

Shared source register

Your progress is stored in this browser on this device.