# What is FRMCS? Explained for decision-makers and engineers Canonical: https://frmcs.org/knowledge/was-ist-frmcs-en Last reviewed: 2026-10-02 Status: editorial reference page (static legacy content, no stored approval record) Last material update: 2026-10-03 — Roadmap section aligned with the milestone dataset: V3p (Nov 2026, planned), V3 (Dec 2027, target), CCS TSI 2028 (UIC target) replacing the earlier “CCS TSI 2027” statement. ## Short answer FRMCS stands for Future Railway Mobile Communication System and is the successor to today's railway radio system GSM-R. It provides the communication foundation for digital railway operation: for operational voice communication, data transmission for train control, and other railway applications. To do this, FRMCS combines modern mobile technology with communication services specifically tailored to railway operation. [1] ## FRMCS explained for decision-makers ### Why does the railway need FRMCS? Railway undertakings need to reliably connect trains, control centres and staff. Today, many railways use GSM-R, a technology based on the 2G mobile generation. However, GSM-R is reaching its long-term technological and economic limits. UIC expects the end of vendor support around 2035. At the same time, the need to exchange data between vehicles and trackside systems is growing. FRMCS is intended to secure continuity of operational communication and enable further digitalisation. 2035 is not a globally uniform switch-off date. The actual transition must be planned per network and vehicle fleet. [1] ### What does FRMCS enable? FRMCS provides communication services for various railway applications. These include voice, data and, in principle, video. The architecture is designed to treat these applications according to their respective requirements for transmission quality and priority. Operationally critical communication requires different conditions than less time-critical data transmission. [2] An illustrative example: a train transmits operational data while the driver speaks with the control centre. If emergency communication is added, the overall system must take its particular requirements into account. In addition to radio coverage, the right participants, authorisations and priorities are therefore decisive. Such functions belong to the service layer of FRMCS. [2] ### What does the introduction mean for a railway undertaking? From a management perspective, FRMCS should be planned as a multi-year change programme for infrastructure, vehicles and operations. This classification follows from the scope of the migration: it affects, among other things, trackside networks, vehicle equipment, control centres, existing applications and their interaction. Coordination with ETCS renewals as well as testing and approval procedures also belongs to introduction planning. [3] This results in four central planning questions: - **Scope:** Which lines, vehicles and applications are converted, and in what order? - **Transition:** How is operation maintained during the coexistence of GSM-R and FRMCS? - **Responsibility:** Who is responsible for communication quality across the entire chain from vehicle to control centre? - **Investment:** How are network renewal, vehicle conversion and application modernisation coordinated with one another? Economic benefit should accordingly be assessed in two parts: the necessary replacement of old technology and the additional benefit of new applications. More network capacity alone does not yet create operational added value; suitable applications and processes are needed for that. ## FRMCS explained for engineers ### Architecture: applications, services and transport The central architectural principle is the separation of communication services and data transport. This is intended to allow network technology and services to evolve as independently as possible from railway applications. - **Railway Application Stratum** – performs the railway function itself and uses FRMCS for communication. Examples: voice application, ETCS, ATO. - **Service Stratum** – provides communication services and associated control functions. Examples: mission-critical services, identities, groups and sessions. - **Transport Stratum** – provides the data connection and its transmission quality. Examples: 5G radio access, 5G Core, mobility and QoS. According to ETSI, railway applications lie outside the actual FRMCS system architecture. FRMCS comprises transport and services. ETCS uses the communication performance of FRMCS; its train control function remains a separate application. [2] ### Transport Stratum: 5G as the technical foundation The specified FRMCS radio access is based on 5G New Radio, complemented by the 5G Core. Key functions include: - **gNodeB:** radio access for terminals. - **AMF:** registration and mobility management. - **SMF:** management of PDU sessions. - **UPF:** forwarding of user data. - **PCF:** control of policies and Quality of Service. Application data is transported via PDU sessions and associated QoS flows. The requirements of the services must also be taken into account in the radio access and the underlying IP network. An existing 5G connection alone therefore does not yet demonstrate sufficient quality for a specific railway application. [2] ### Service Stratum: MCX and SIP/IMS The service layer builds on 3GPP's Mission-Critical framework, known as MCX. The service family includes: - **MCPTT** (Mission Critical Push To Talk): critical voice communication. - **MCData** (Mission Critical Data): critical data communication. - **MCVideo** (Mission Critical Video): critical video communication. This service family describes the technical framework. Which functions are supported in a specific FRMCS version and installation must be checked against the respective specification and implementation. Interoperability between different vendors is examined, among other things, in ETSI's FRMCS Plugtests. [2] The Service Stratum also includes SIP/IMS-based signalling, identity and key management, as well as functions for managing configurations and functional aliases. A functional alias enables addressing via an operational function – for example a train function – instead of exclusively via a fixed device identity. The 5G Core and the SIP/IMS Core perform different tasks: the 5G Core organises network access and transport; the SIP/IMS Core supports signalling at the service layer. [2] ### Quality must fit together across all layers A priority at the application layer must be translated into the appropriate service and transport parameters. For this, FRMCS envisages coupling the service layer with the policy control of the 5G Core, among other things via N5 or Rx. Technically, different mechanisms need to be distinguished: 5QI describes QoS characteristics of a flow; Allocation and Retention Priority (ARP) influences, among other things, the admission and, where applicable, pre-emption of resources. For design purposes, what counts is the coordinated behaviour of the entire connection under load and during mobility. [2] ### Migration: GSM-R and FRMCS must work together During the introduction, both systems will temporarily exist side by side. For their cooperation, ETSI specifies Interworking Functions (IWF). They mediate between different communication mechanisms and support defined cross-system procedures. Interworking is therefore an independent integration task. Which voice and operational functions work across the system boundary must be specifically defined and tested; a gateway alone does not prove complete functional equivalence. [2] ## How far along is FRMCS? As of 2026-10-03. FRMCS is being specified and validated step by step. According to the latest editorial roadmap, the preliminary V3p release is planned for 2026-11 [4]; the ERA-aligned V3 "FRMCS 1st Edition" is a target for 2027-12 [4]. ERA plans its recommendation with the FRMCS specifications within a corridor of 2027-12 to 2028-09 [5]; legal incorporation into the CCS TSI is a UIC target for 2028 [6]. Specification release, ERA recommendation, legal incorporation and national rollout are separate steps; all dates named are plans, not achieved milestones. MORANE-2 is intended to contribute to validation through laboratory and field tests. This planning must not be equated with an already completed nationwide rollout. For technical projects, this means: a requirement such as "FRMCS-compatible" is too imprecise. Procurement and acceptance should specify the concrete specification versions, supported functions, interfaces and operational scenarios to be demonstrated. ## Sources 1. [FU-7100 – FRMCS User Requirements Specification](https://img1.uic.org/IMG/pdf/fu-7100-5.0_0.pdf) — UIC, 5.0.0 (19 Feb 2020) 2. [ETSI TS 103 764 — System Architecture](https://www.etsi.org/deliver/etsi_ts/103700_103799/103764/01.01.01_60/ts_103764v010101p.pdf) — ETSI TC RT, v1.1.1 3. [CCS TSI Appendix A – mandatory specifications (ETCS B4 R1, GSM-R B1 MR1, FRMCS B0)](https://www.era.europa.eu/era-folder/1-ccs-tsi-appendix-mandatory-specifications-etcs-b4-r1-rmr-gsm-r-b1-mr1-frmcs-b0-ato-b1) — ERA 4. [FRMCS Mega Meeting – Aligning the next steps](https://img8.uic.org/com/enews/article/frmcs-mega-meeting-aligning-the-next-steps) — UIC 5. [Consolidated Annual Activity Report (CAAR) 2025 – Annex to MB Decision n° 400](https://www.era.europa.eu/sites/default/files/2026-06/decision%20n%C2%B0%20400%20-%20caar%202025%20-%20annex.pdf) — ERA 6. [ATWG reaches a milestone with its 100th UIC FRMCS meeting](https://img8.uic.org/com/enews/article/atwg-reaches-a-milestone-with-its-100th-uic-frmcs-meeting) — UIC ## Cite as What is FRMCS? Explained for decision-makers and engineers. FRMCS Atlas. https://frmcs.org/knowledge/was-ist-frmcs-en (last material update 2026-10-02) > FRMCS Atlas is a personal editorial project by Ante Samardzic (employed by Frequentis), not an official Frequentis, UIC, ETSI or ERA publication or endorsement. Claims are source-linked; review status is stated per page — database articles pass a stored quality review and human approval of the exact version, legacy static pages are marked as such.