---
title: Presentation Frequenties
url: https://share.jotbird.com/breezy-resilient-wren
updated_at: 2026-10-22T18:37:08.158771+00:00
---

# Shareable Summary — IRSE Presentation on FRMCS and the Role of Frequentis

**Audience:** Radio Communications / ALTO COMMS Team  
**Prepared for:** Frederic Jacques  
**Consolidation date:** October 22, 2026  
**Status:** Working document for internal sharing

> **Important — Scope and traceability**  
> This document consolidates the information discussed in the presentation summary and follow-up exchanges concerning the IRSE presentation on FRMCS. Any item described as originating from the presentation should be checked against the original transcript or presentation material before being used as a requirement, design decision, or approved project position. Additional explanatory material is clearly identified as such.

---

## 1. Executive Summary

The presentation explains that **FRMCS** is intended to succeed **GSM-R** through an architecture that clearly separates data transport, mission-critical communication services, and railway applications. **5G** primarily provides IP transport. Railway operational functions, including group calls, priority, preemption, and mission-critical voice, data, and video, are provided by the **MCX** service layer. The architecture also includes **IMS** for session management and railway applications such as dispatch functions.

Migration does not consist of immediately replacing GSM-R with FRMCS. The two environments will need to coexist during a transition period. An **Interworking Function** is therefore required to maintain communication continuity and consistency, particularly for emergency calls. An onboard gateway approach was also discussed to allow train applications to operate across both environments during the transition.

**Frequentis** was presented mainly as a supplier in the operational communications layer, including **MCX services**, **dispatch solutions**, and control-center systems. Frequentis was not presented as the supplier of the 5G RAN itself.

The presentation also addressed spectrum, mainly from the perspectives of migration and RF coverage. Using spectrum around **1,900 MHz** may facilitate coexistence with GSM-R, but it affects radio range and the number of sites required compared with a solution around **900 MHz**. The presentation was not a detailed spectrum-availability study and did not address the Canadian regulatory context.

Finally, artificial intelligence was discussed near the end of the presentation as a possible enabler for operating and maintaining a cloud-native infrastructure, including testing, diagnostics, automation, and potentially self-healing. This discussion should not be interpreted as a confirmed FRMCS requirement.

---

## 2. FRMCS Architecture Presented

### 2.1 Simplified Functional View

```text
Railway applications
(dispatch, operational functions, train-to-ground applications)
                         |
                         v
MCX services
(voice, data, video, group calls, priority, preemption,
location-dependent services)
                         |
                         v
IMS
(session establishment and management)
                         |
                         v
5G IP transport
(RAN, mobile core, and connectivity)
```

### 2.2 Essential Message

- **5G alone is not the railway communications system.**
- 5G provides **IP transport**.
- **IMS** supports session management.
- **MCX** provides mission-critical communication functions.
- Railway applications and dispatch systems use these services for railway operations.

### 2.3 Careful Mapping to ALTO/RADS

For the ALTO context, the presentation supports the following conceptual separation:

| Layer | Functional role | Interpretation for ALTO/RADS |
|---|---|---|
| Transport | Radio and core-network IP connectivity | A RADS transport component, without equating RADS with the RAN alone |
| IMS | Session management | A service function to be integrated into the overall architecture |
| MCX | Mission-critical communications | Critical operational-services layer |
| Dispatch / applications | Controller interaction and railway applications | Control-center functions and associated applications |

> This mapping is an **engineering interpretation**, not an approved ALTO architecture or supplier allocation.

---

## 3. Role of Frequentis

### 3.1 Main Positioning

According to the presentation, Frequentis is primarily positioned in:

- operational communications for control centers;
- **MCX** solutions;
- **dispatch** functions and consoles;
- integration of railway communication services;
- participation in FRMCS standardization activities;
- software architectures that may be deployed on cloud-native infrastructure.

### 3.2 What Frequentis Was Not Presented as Providing

In this discussion, Frequentis was not presented as:

- the 5G mobile network operator;
- the complete RAN supplier;
- merely a manufacturer of onboard radios;
- the spectrum owner.

### 3.3 Specific Items Mentioned

- Frequentis was described as providing controller or signaler terminal systems in GSM-R environments.
- The presentation referenced approximately **800 terminals in the United Kingdom**.
- Frequentis was described as working on FRMCS MCX and dispatch solutions.
- A trial with **ÖBB, Austrian Railways**, involving MCX and IMS on cloud-native infrastructure was mentioned.

### 3.4 Summary Statement

> **Frequentis is primarily a supplier of the FRMCS operational communication service layer, particularly MCX and dispatch/control-center solutions, relying on the 5G transport network rather than supplying the complete RAN itself.**

---

## 4. Location and Railway Communications

Location was presented as an important FRMCS function. Certain functions, including railway emergency calls and functional addressing, must be able to automatically identify the relevant trains and controllers based on their positions.

Mechanisms discussed included:

- use of **GNSS**;
- a cell-based fallback mechanism;
- use of location to select the appropriate participants in an operational communication.

### Key Consideration

Location should not be understood as merely a mapping function. It contributes to correctly routing operational and emergency communications to the appropriate users.

---

## 5. Migration from GSM-R to FRMCS

### 5.1 Required Coexistence

A central message of the presentation was that GSM-R and FRMCS will need to coexist during migration. Two fully independent parallel networks would not be sufficient because certain communications must remain consistent end to end throughout the transition.

### 5.2 Interworking Function

An **Interworking Function** is intended to provide interoperability between GSM-R and FRMCS, particularly for:

- emergency communications;
- calls involving users operating on different technologies;
- service continuity during migration.

### 5.3 Onboard Gateway

An onboard gateway approach was discussed to allow train applications to operate with both environments during the transition.

### 5.4 Engineering Consequence

Migration should be treated as a complete transition architecture covering:

- service interworking;
- application compatibility;
- onboard functions;
- management of critical calls;
- spectrum availability;
- the phased deployment strategy.

---

## 6. Spectrum Availability and RF Coverage

These issues are related, but they are not the same engineering problem.

### 6.1 Spectrum Availability

**Engineering question:** Are usable frequencies available for FRMCS when they are needed?

Associated topics include:

- available frequency bands;
- amount of spectrum available;
- current occupancy by GSM-R or other services;
- GSM-R and FRMCS coexistence;
- ability to progressively release or reuse spectrum;
- regulatory allocation and licensing conditions.

**Short formulation:**  
> Spectrum availability = “Do we have enough usable spectrum, in the right band, at the right time?”

### 6.2 RF Coverage

**Engineering question:** With the available frequency, how many sites and what infrastructure are required to cover the railway corridor?

Associated topics include:

- propagation loss;
- site range;
- continuous coverage;
- tunnels and challenging environments;
- site density and spacing;
- availability and quality of railway communications.

**Short formulation:**  
> RF coverage = “With the available spectrum, what infrastructure is required to achieve the required coverage and quality?”

### 6.3 Items Discussed in the Presentation

- GSM-R/FRMCS coexistence was associated with using FRMCS spectrum around **1,900 MHz**.
- A band or trial around **900 MHz** in Germany was also discussed.
- During the question-and-answer session, the higher frequency was linked to a potential requirement for several thousand new sites.
- A figure of **4,000 to 5,000 new sites** was mentioned in the discussion associated with using approximately 1,900 MHz instead of 900 MHz.

### 6.4 What the Presentation Did Not Demonstrate

The presentation did not provide a structured study covering:

- the actual amount of FRMCS spectrum available;
- required bandwidth compared with available bandwidth;
- national allocation mechanisms;
- spectrum availability in Canada;
- spectrum sharing with commercial operators;
- regulatory feasibility for ALTO.

### 6.5 Conclusion for ALTO/RADS

> The presentation recognizes spectrum as a major migration and RF-design constraint. It illustrates the tradeoff among coexistence, frequency band, radio range, and site density, but it is not a spectrum-availability study applicable to Canada or ALTO.

---

## 7. Artificial Intelligence and Cloud-Native Infrastructure

### 7.1 Topic Discussed at the End of the Presentation

AI was discussed during the question-and-answer session, but it was not a primary theme of the presentation.

Potential uses discussed included:

- managing the complexity of cloud-native infrastructure;
- test automation;
- diagnostics;
- maintenance support;
- orchestration;
- possible self-healing mechanisms;
- centralizing functions in a private cloud.

### 7.2 Interpretation Limit

These items should not be classified as:

- FRMCS requirements;
- mandatory MCX functions;
- approved architecture decisions;
- confirmed ALTO capabilities.

### 7.3 Recommended Classification

> **Technology opportunity / O&M topic for further investigation:** Potential use of AI for diagnostics, automation, testing, and management of cloud-native FRMCS infrastructure. It was not presented as an FRMCS requirement.

---

## 8. Main Questions and Answers to Retain

| Topic | Underlying question | Answer or key message |
|---|---|---|
| Role of 5G | Does 5G directly provide railway communications? | No. It primarily provides IP transport; operational services are delivered by MCX and railway applications. |
| Migration | Can GSM-R simply be replaced by FRMCS? | No. A coexistence period and interworking are required. |
| Emergency calls | How are communications maintained between technologies during transition? | Through an Interworking Function and a coherent migration architecture. |
| Location | Why is location important? | It helps automatically identify the trains and controllers relevant to certain communications. |
| Frequentis | Where does the company fit in the architecture? | Primarily in MCX, dispatch, control-center, and operational communication functions. |
| Spectrum | Was spectrum availability addressed? | Yes, indirectly through coexistence and frequency-band considerations, but not through a detailed regulatory study. |
| Coverage | Why might more sites be required? | A higher frequency, particularly around 1,900 MHz compared with 900 MHz, reduces range and may increase site density. |
| AI | Is AI an FRMCS function? | No. It was discussed as a possible automation and maintenance capability in a cloud-native environment. |

---

## 9. Additional Information for the Team

> **This section is supplemental analysis, not a direct summary of the presentation.**

### 9.1 Recommended Information Classification

| Category | Items |
|---|---|
| Presented information | Layered architecture, role of 5G transport, MCX, IMS, GSM-R/FRMCS coexistence, location, and the general role of Frequentis |
| Examples or illustrations | ÖBB trial, terminals in the United Kingdom, 900/1,900 MHz discussion, and the estimated number of sites |
| Items to confirm | Exact figures, exact bands, trial conditions, scope of the onboard gateway, and exact functions of the Interworking Function |
| Not directly applicable to ALTO without further study | Canadian regulatory availability, spectrum selection, number of sites, supplier allocation, cloud architecture, and use of AI |

### 9.2 Questions to Pursue for ALTO/RADS

1. What approved ALTO architecture separates transport, IMS, MCX, and railway applications?
2. Which dispatch and control-center functions fall within the RADS scope?
3. What migration strategy is relevant if ALTO does not initially deploy GSM-R?
4. Which bands are actually accessible and licensable in Canada for mission-critical railway communications?
5. Which coverage, availability, latency, priority, and preemption KPIs must be traced in the SRS?
6. How will functional location be provided, verified, and degraded if GNSS is unavailable?
7. Which interfaces are required with NETS, rolling stock, OCC/BOCC, dispatch consoles, and railway applications?
8. Should Frequentis be treated as a market reference, a potential consultation participant, or only as a supplier example? Any allocation remains to be confirmed.
9. Which cloud-native elements are acceptable under ALTO cybersecurity, sovereignty, availability, and operational requirements?
10. Should AI remain a future O&M opportunity, separate from baseline FRMCS requirements?

### 9.3 Potential Impact on ALTO Deliverables

- **BoD:** Present the layered architecture and functional boundaries without selecting a supplier.
- **SFD:** Describe communication, location, priority, preemption, group, and emergency functions.
- **SRS:** Convert only approved needs into verifiable requirements.
- **SSD/SDD:** Detail interfaces among transport, IMS, MCX, dispatch, applications, and rolling stock.
- **SBS:** Retain “ID TBD” until the official allocation is reconciled.
- **Interface register:** Include the first hop to NETS and interfaces with rolling stock and control centers.
- **Assumption Log:** Separately document spectrum, migration, location, and cloud assumptions.
- **Risk Register:** Address spectrum availability, site density, coexistence, vendor lock-in, cybersecurity, and solution maturity.

---

## 10. Key Messages for the Team

1. **FRMCS is a railway service architecture, not simply a 5G network.**
2. **MCX provides critical functions above the IP transport layer.**
3. **Location is essential to certain operational and emergency communications.**
4. **GSM-R/FRMCS migration requires interworking, not only two parallel networks.**
5. **Frequentis is positioned mainly in MCX, dispatch, and control-center solutions.**
6. **Spectrum availability and RF coverage are distinct engineering problems.**
7. **A higher frequency may facilitate coexistence but increase required site density.**
8. **The presentation does not validate Canadian spectrum, the number of ALTO sites, or a supplier selection.**
9. **AI was discussed as an operations and maintenance opportunity, not as an FRMCS requirement.**
10. **Any application to ALTO must be clearly classified as a fact, assumption, open point, or recommendation.**

---

## 11. Glossary

| Acronym | Definition |
|---|---|
| FRMCS | Future Railway Mobile Communication System |
| GSM-R | Global System for Mobile Communications – Railway |
| MCX | Mission Critical Services, a general term covering mission-critical push-to-talk, data, and video services |
| IMS | IP Multimedia Subsystem |
| RAN | Radio Access Network |
| GNSS | Global Navigation Satellite System |
| OCC | Operational Control Center |
| BOCC | Backup Operational Control Center |
| O&M | Operations and Maintenance |
| RADS | Operations Radio System, according to current ALTO working terminology |
| NETS | Telecom Network System, the first-level transport interface in the ALTO architecture |

---

## 12. Limitations and Required Validation

Before external distribution or incorporation into a project deliverable:

- verify figures and wording against the complete transcript;
- confirm the exact presentation title, presenter name, and date;
- confirm the precise references for the ÖBB trial;
- confirm the context of the 900 MHz and 1,900 MHz bands;
- confirm the 4,000-to-5,000-site figure and its geographic scope;
- clearly distinguish the presenter’s statements from participant questions or assumptions;
- do not convert this information into ALTO requirements without an approved project source.

---

## 13. Consolidation Source

- Copilot discussion of October 22, 2026, concerning the IRSE presentation summary, FRMCS, Frequentis, spectrum, RF coverage, and AI.
- Meeting summary and follow-up exchanges previously retrieved in the discussion.
