REC

Railway Emergency Communication

Services →
Introduced in Rel-16

REC is a 3GPP service enabling reliable, high-priority emergency communication for railway operations between train crews, control centers, and emergency responders.

Category
Services
Introduced
Rel-16
Where
Services
Specifications
2 specs
REC Description Purpose Related Classification Detected Changes Specifications

Description

Railway Emergency Communication (REC) is a standardized service within 3GPP that leverages cellular networks, primarily 5G, to provide mission-critical communication for railway systems. It is designed to meet the stringent reliability, availability, and latency requirements of railway operations, particularly during emergencies. The architecture integrates with existing railway communication systems and the 3GPP core network, utilizing network slicing and priority mechanisms to guarantee service quality. Key components include the User Equipment (UE) on trains, the Radio Access Network (RAN), and the 5G Core Network (5GC), which together facilitate secure and immediate communication channels.

REC operates by establishing dedicated communication sessions with high priority and pre-emption capabilities over public or private 5G networks. It employs Quality of Service (QoS) mechanisms to ensure low latency and high reliability for emergency calls and data transmissions. The service supports group communication, enabling coordinated responses among multiple parties such as train drivers, control center operators, and emergency services. It also incorporates location-based services to provide accurate positioning of trains, which is crucial during incident management.

The role of REC in the network is to provide a standardized, interoperable solution for railway emergency communications, replacing or augmenting legacy systems like GSM-R. It ensures that critical information can be exchanged swiftly and reliably, supporting functions such as emergency braking notifications, incident reporting, and evacuation coordination. By leveraging 5G advancements, REC enhances situational awareness and response times, contributing to overall railway safety and operational resilience.

Purpose & Motivation

REC was created to address the limitations of existing railway communication systems, such as GSM-R, which lack the bandwidth, low latency, and advanced features required for modern railway operations. The increasing complexity of railway networks, including high-speed trains and automated systems, necessitated a more robust and future-proof emergency communication solution. 3GPP introduced REC to leverage the capabilities of 5G technology, providing enhanced reliability, capacity, and service integration for critical railway communications.

The primary problem REC solves is ensuring uninterrupted and high-priority communication during emergencies, where delays or failures could lead to severe safety incidents. It provides a standardized framework that ensures interoperability across different railway operators and regions, facilitating seamless communication in cross-border scenarios. Historical context includes the evolution from analog systems to digital GSM-R, and now to IP-based 5G systems, driven by the need for higher data rates, lower latency, and support for new applications like video surveillance and real-time data analytics.

REC also addresses the growing demand for integrating railway communications with public safety networks, enabling coordinated responses with external emergency services. By utilizing network slicing, REC can create virtual dedicated networks for railway operations, ensuring resource isolation and guaranteed performance even during network congestion. This approach future-proofs railway communications, supporting emerging technologies such as autonomous trains and predictive maintenance.

Classification

Part ofMCX
Related approachesGSM-R

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (4 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-18 1 change

In Release 18, the main enhancement for the Railway Emergency Communication (REC) function is the introduction of "MCX Service Ad hoc Group Communication as an alternative capability" to support it. This provides a new standardized method, alongside existing procedures, for establishing the optional voice and/or data communication phase following a mandatory alert. The update ensures FRMCS systems can continue to support the core REC purposes of alerting drivers and enabling subsequent communications, while also coordinating with overlapping GSM-R networks about ongoing emergencies.

  • Adding MCX Service Ad hoc Group Communication as alternative capability to support Railway Emergency Communication TS 22.989CR0012
Rel-19 3 changes

In Release 19, the REC function was enhanced and its related use cases were cleaned up. The updates clarified procedures for interoperability with GSM-R systems, specifying that an FRMCS system must update a GSM-R system about an ongoing railway emergency alert when they cover the same area. Furthermore, the specifications were refined regarding the mandatory alert phase and the optional subsequent communication phase, as well as the provision of REC-related information to the train-borne recorder via a dedicated interface.

  • Enhancement and clean-up of Railway Emergency Communication related use cases TS 22.989CR16
  • Enhancement of Railway Emergency Communication TS 22.989CR0022
  • Clean-up of Railway Emergency Communication related use cases TS 22.989CR0026

Explore further

Broader topics and technologies where REC plays a role.

Defining Specifications

3GPP specifications that define or reference REC, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 22.889 vh40 FRMCS Study; Stage 1 Rel-17
TR 22.989 vk30 FRMCS Analysis and Requirements Rel-20
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.