FRMCS will replace GSM-R across Europe’s railways, but readiness requires far more than a radio swap. From backbone infrastructure to baseband architecture, here’s a practical guide to preparing for the transition.
Authors: Karsten Oberle, Railway Business Development Lead Europe, Nokia, and Benoît Leridon, Transportation Market Leader, Network Infrastructure, Nokia.
The ‘Future Railway Mobile Communication System’ (FRMCS) is the next-generation standard for railway communications, unlocking smarter operations, improved customer services and new business opportunities.
Standardisation is progressing through the International Union of Railways (UIC), with the Morane 2 project testing an intermediate release across four major European operators, ahead of the European Railway Agency’s (ERA) Technical Specifications for Interoperability (TSI), expected around 2028.
This is because FRMCS is a transformation of the entire communications architecture, touching every layer of the network stack. The lead times, therefore, are substantial, and some elements can and should be addressed now.
Start with the Transmission Backbone
Take the IP and optical backbone. This fixed network is the foundation everything else will be built on, and trying to roll out FRMCS on top of an unstable or underprepared backbone is a recipe for complexity.
So, what does backbone readiness require? First, IP/MPLS connectivity needs to be in place at every base station site. Second, routers must support the synchronisation demands of 5G. Third, the physical topology of the IP network may need to change: ring sizes in particular will need to match strict 5G synchronisation requirements.
Rethinking RAN
A common misconception in early FRMCS planning is that moving from GSM-R’s 900 MHz band to FRMCS at 1900 MHz (n101) requires doubling the number of radio sites. In most cases, it doesn’t. For operators focused on ETCS signalling and mission-critical voice, existing GSM-R cell sizes can often be reused – provided the original network was designed to support ETCS effectively.
Additional sites come into play when operators introduce higher-throughput use cases. For example, an operator planning for automated train operation (ATO) higher Grade of Automation (including video) will need a denser network than one simply replacing GSM-R. Therefore, the starting point for any radio access network (RAN) planning is to define what the network needs to support. Know this, and the infrastructure requirements follow logically.
Choosing BBU Architecture
Within the RAN, one of the most consequential planning decisions is how to deploy baseband units (BBUs). In a distributed architecture, each radio site has its own BBU, which is straightforward but costly. In a hotel architecture, BBU resources are pooled across multiple sites, typically three to five, connected via fibre. The cost saving is significant: roughly half the number of BBUs compared to a fully distributed setup.
The trade-off is dependency. If a pooled BBU fails, every connected site goes down, potentially leaving up to 20 kilometres of track without coverage. That makes redundancy non-negotiable: a second BBU in a separate location must be ready to take over in the event of failure. With this in place, hotel architecture delivers a stronger balance of cost and resilience, and is the approach most operators are adopting.
Deploying a 5G Core
FRMCS depends on a resilient 5G core designed for the specific requirements of railway operations. Unlike a GSM-R core network, the FRMCS 5G core is cloud-native and can run on an on-premises cloud platform.
It must deliver high throughput and low latency for safety-critical services, while supporting high availability, resilience, security, predictable operational behaviour, and clear testing and rollback procedures. A cloud-native FRMCS core also enables a more flexible operating model: software functions run in containers, with spare capacity built into the platform. Because the core is modular, software-defined and standards-based, updates, security fixes, capacity changes and new railway applications can be managed as part of normal lifecycle operations, without repeated platform replacement or core redesign.
Enhancing Mission-Critical Communications
The 3GPP-defined MCX framework provides standardised, interoperable voice, data and video capabilities for railway operations, with the resilience and prioritisation safety-critical use demands.
Mission-critical push-to-talk (MCPTT) is the 5G evolution of railway’s group voice communications, delivering better audio quality, faster setup and features such as dynamic group management and user prioritisation. Mission-critical data (MCData) carries operational information such as ETCS train control and critical messaging, while mission-critical video (MCVideo) streams real-time video to and from moving trains for applications from CCTV to automated train operations.
Staying Secure
Another important consideration is security, because moving to a 5G IP-based network expands your attack surface.
GSM-R’s time division multiplexing (TDM) foundation offered a degree of natural protection, but FRMCS changes things and operators need a more deliberate security posture from the outset.
The ‘Third Generation Partnership Project’ (3GPP) standard requires IPsec encryption from radio to core, and European regulation is increasingly framing secure rail communications as a matter of national infrastructure protection. But compliance alone isn’t enough.
The more robust approach is zero-trust: limiting an attacker’s ability to enter the network, and using zoning to contain any damage if they do. Every element of the network should contribute to that protection, not just a single measure such as a firewall. For large, complex organisations running legacy applications, this is a significant undertaking, but one that must be addressed at the infrastructure level, not bolted on afterwards.
Don’t Get Ahead of Yourself
When it comes to applications, the temptation is to plan for everything at once. Don’t. The immediate priority is getting ETCS signalling and mission-critical voice operational, because until these are running reliably on FRMCS, GSM-R cannot be switched off step by step.
Once it does, the picture opens up. As GSM-R is decommissioned line by line, the 900MHz spectrum (n100) it occupied becomes available for FRMCS too, adding capacity for higher grades of train automation, driverless services and IoT-based predictive maintenance. The architecture should be designed with this evolution in mind, but operators that try to build for everything from day one risk losing sight of what needs to happen first: start with the critical, prove it works, then build on that.
Managing the Transition
At first, operators will need to run FRMCS and GSM-R simultaneously for a couple of years, but managing two networks in parallel can put real pressure on internal teams, and for some operators, capacity will be a genuine constraint.
The practical approach is to deploy FRMCS without touching the existing GSM-R infrastructure, then decommission it in stages as FRMCS services are proven and stable.
For operators still running GSM-R over an obsolete SDH network, there’s a well-proven migration path to IP/MPLS requiring no changes to the GSM-R infrastructure itself, often as simple as moving cable connections, maintaining connectivity until the last day of operation.
Where internal resources are stretched, managed services can ease the burden, covering planning, deployment and operations, and freeing operators to focus on running their railway.
See the Full Stack at InnoTrans
For operators looking to understand what end-to-end FRMCS readiness looks like in practice, Nokia will present the full stack at InnoTrans 2026. The exhibit is designed as a journey through the complete architecture, opening up conversations about which layers are most relevant to each operator’s programme.
Nokia experts will be on hand throughout the event at Hall 4.1, Stand 360.
