Comparing GSM-R and FRMCS: requirements, technology and migration

The core of the transition: GSM-R implements railway functions with GSM technology and railway-specific extensions. FRMCS separates communication services and transport more clearly and, in the European target architecture, uses 5G together with mission-critical services. The success of the migration shows in whether operational procedures keep working reliably during parallel operation. ^{[1] [2] [3]}

EIRENE, GSM-R and FRMCS: what is being compared?

EIRENE is not merely a concept; it comprises functional and system requirement specifications for GSM-R. GSM-R is the GSM-based railway communication system. FRMCS, the Future Railway Mobile Communication System, is its successor with its own specifications. A clean comparison therefore sets requirements against requirements and systems against systems. ^{[1] [2] [10]}

FRS stands for Functional Requirements Specification, SRS for System Requirements Specification. Both are requirements documents: the SRS is not yet a concrete vendor implementation. Requirements are also distributed differently across the document families; identical chapter numbers do not imply matching content. ^{[1] [7] [11]}

Important: GSM-R is not fundamentally "without IP". The EIRENE specifications already take IP-based core networks and circuit- and packet-switched ETCS data transmission into account. The move to FRMCS goes beyond introducing IP. ^[1]

1. FRS versus FRS: what must railway communication deliver?

The following table maps the 14 selected EIRENE operational functions to the FRMCS FRS. Basis: EIRENE FRS 8.1.0 and FRMCS FRS 2.1.0. B01–B14 are editorial IDs, not normative requirement numbers. ^{[5] [10]}

Reading key: V3 denotes requirements planned for Version 3, Vx later versions. M means mandatory, O optional, each within the stated scope. The labels apply to individual requirements; a table row is not a blanket conformance assessment. "Continued" refers to the operational purpose, not to identical procedures or product availability. ^[10]

Four operational procedures for in-depth migration review

For project work we recommend the following review priorities. The questions are professional derivations, not additional normative requirements:

• B06 – Broadcast call: Who may speak, who only listens, and how do participants of both systems behave?
• B09 – Shunting: Which link assurance is needed, how are interruptions indicated, and what applies in mixed operation?
• B11 – Train staff: Which specific calls are required, and which released specification and solution cover them?
• B14 – Controller handover: Are identities, responsibilities, incoming calls and ongoing calls handed over completely and correctly?

The mapping does not replace a requirement-by-requirement mapping. For acceptance, every required function must be checked with its detailed requirements, exceptions and evidence.

2. SRS and technical standards: how are the functions implemented?

This level links EIRENE SRS and FRMCS SRS with the supplementary technical standards. The table is a technical synthesis, not an exclusive SRS-to-SRS comparison. It shows why an unchanged operational task still requires new integration work. ^{[3] [4] [6] [7]}

MCPTT stands for Mission Critical Push-to-Talk. MCData refers to mission-critical data services. 5QI characterises quality of service in the 5G system; ARP supports decisions on resource allocation and pre-emption. ^{[3] [4]}

3. GSM-R versus FRMCS: what changes in the overall system?

ETSI distinguishes two strata within the FRMCS system: the Service Stratum and the Transport Stratum. Railway applications sit above them in the Railway Application Stratum and are conceptually outside the FRMCS system itself. ^[2] (clause 4.2.1)

The planning consequences in the table are professional derivations from the architecture. The separation of strata can support separate procurement. It does not, however, guarantee arbitrary interchangeability of components or suppliers.

Integration also changes on the vehicle: the on-board FRMCS specification describes functions and interfaces for connecting applications and radio modules. A migration project must therefore assess the vehicle network, installation, antennas and redundancy together. ^[8]

Which documents complement the FRS/SRS comparison?

FRS and SRS are the starting point. Interfaces, vehicle equipment and migration require further documents. The selection depends on the use case under consideration.

Migration: three proofs for viable mixed operation

A working FRMCS network alone does not resolve every transition question. For project planning it is advisable to treat three tasks separately:

ETSI provides a dedicated reference point for interworking with GSM-R; TS 103 792 specifies the interworking. The engineering recommendation that follows: an existing Interworking Function must be checked for every required service; its existence alone does not prove a seamless transition. ^[3] (clause 4.2) ^[14]

Practical checklist for decision-makers and engineers

The following list is a planning recommendation, not a complete normative test catalogue:

• Functional reachability: Is the right driver reached after registration or a crew change?
• Emergency communication: Does an emergency call reach all intended participants in mixed operation?
• Overload: Are prioritised services given precedence along the entire connection?
• System boundaries: What happens to ongoing calls and ETCS data at the transition?
• Faults: Which functions remain available, and what information do operators receive?
• Recovery: Are identities, groups and connections re-established correctly after a fault?

Specification status and schedule: keep milestones apart

The requirements comparison uses EIRENE FRS 8.1.0 and SRS 16.1.0 as well as FRMCS FRS/SRS 2.1.0. The linked interface and ETSI documents complement it. This is an editorial comparison basis, not a consistent conformance or authorisation set. For development and regulatory milestones, the central milestone dataset of this website applies. Additionally: ERTMS Work Plan 2026, page 67. ^[9]

[[FRMCS\_MILESTONES]]

The work plan identifies schedule risks. These figures are planning states, not guaranteed delivery dates and not a Europe-wide switchover date. ^[9]

Frequently asked questions about GSM-R and FRMCS

Is EIRENE the concept and GSM-R the implementation?

Simplified, yes, but EIRENE contains concrete functional and system requirements. For a clean comparison, EIRENE FRS and SRS are set against FRMCS FRS and SRS; at system level we compare GSM-R and FRMCS. ^{[1] [10]}

Is FRMCS simply GSM-R with 5G?

Beyond radio technology, the change also covers communication services, identity functions and application interfaces. FRMCS explicitly separates service and transport. The core operational tasks remain the reference point for implementation and acceptance. ^[2]

Is a SIP/IMS-capable control centre enough for FRMCS?

Support for SIP or IMS alone does not prove full FRMCS compatibility. The required MC services, railway-specific functions and interfaces must also be demonstrated. This conclusion follows from the scope of the specified Service Stratum. ^[3]

Does FRMCS replace the ETCS train control system?

FRMCS provides communication for railway applications. ETCS remains an application that depends on it. During migration, the ETCS equipment concerned and its communication connection must match. ^{[2] [7]}

What belongs in procurement now

Recommended review scheme: operational function → GSM-R requirement reference → FRMCS requirement reference → technical change → migration consequence → acceptance evidence. Dropped requirements, additional requirements and still-open specification points must also become visible. This article provides orientation for that, but does not replace a complete requirements register.

For robust procurement, every supplier should state, for each required operational function, the supported specification version, the interfaces, the behaviour in mixed operation and the tests passed. Responsibilities for integration, fault resolution and overall availability also belong in project planning. This turns the label "FRMCS-ready" into a verifiable performance commitment.

Sources and classification

Technical statements are based on the following primary sources. The checklist and procurement notes are professional recommendations derived from them. No statement about the conformance of any specific product is derived from a specification.