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

Apply · 2.19

Service domains and service continuity

Time: about 7–10 minutes including the task; estimate

Guiding question: What changes during transport- and service-domain transitions?

Learning objective: You follow transport- and service-domain transitions using separate states.

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

A train changes more than radio cells

Train 1234 reaches a neighbouring railway's territory. Radio connectivity may already exist in the new network while service use is still in another state. A transport domain comprises the responsible transport functions. A service domain comprises operated service functions. Distinguish them even when one operator provides both.

The Home Service Domain is the service user's home association. A Foreign Service Domain is another service domain requiring additional procedures for the intended use. “Serving” identifies the currently serving domain. These are state and responsibility terms, not geographic synonyms for a country. [S06; S09, clauses 6.1 and 6.4]

Transport and service readiness are tracked separately; the application assesses its communication.
G15 · Original simplified teaching diagram. Transport and service readiness are tracked separately; the application assesses its communication.

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

Examine the transition in separate steps

First the intended transport becomes usable in the target. Next determine whether the affected application's service user migrates to the target service domain or continues to be served by its home domain. The decision follows the application profile. An available radio path does not make that decision automatically.

The SRS distinguishes application types for this purpose. For the cases described as interoperable infrastructure-manager applications, assignment to the target service domain matters. Other categories have different rules, or rules still open or marked for later scope in the selected edition. A blanket claim that “all applications always migrate” would therefore be wrong. Edition-specific requirement markings remain part of the evidence. [S06, clause 10.1.3.3]

An available service user is not a continued call

Following authorisation in the target, check ongoing communication, new communication and application notifications separately. Service continuity describes the required behaviour during transition. It cannot be inferred solely from successful registration. The Talbahn case observes interruption start, restored data flow and usable application state.

An ongoing voice call and a data session may require different recovery procedures. An application must not infer “all functions ready” solely from “transport available”. Old mappings must also be handled deliberately so that new calls do not reach an obsolete service instance.

Check your understanding

A cross-border test demonstrates successful network registration and a new call. What claim about the ongoing data case remains unproven?

Model answer

Its handling during transition, correct service-domain association and complete application recovery remain unproven. The test needs starting state, application profile, ongoing session and observed interruption. A new call tests a different case.

What to remember

Transport transition, service-user migration and communication continuity are separate state transitions. Their interaction depends on the application profile.

Your Talbahn case file

Create a before/during/after table for voice and data. Record transport domain, service domain, authorisation and application state separately.

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

Shared source register

Your progress is stored in this browser on this device.