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
Your progress is stored in this browser on this device.