Why Connectivity on Trains Is Still So Poor

Anyone who travels regularly by train will recognise the experience. The phone shows a mobile signal, sometimes even 5G, but webpages refuse to load, video calls freeze and messages remain stuck sending. Switching to the train’s Wi-Fi may not help either. The device connects to the access point, but there is little or no usable internet behind it.

Providing reliable connectivity on a moving train is much harder than providing coverage to a home, office or even a vehicle on a road. A railway combines weak and inconsistent outdoor coverage, a radio-unfriendly metal carriage, high-speed mobility, frequent handovers, difficult terrain and hundreds of passengers competing for limited capacity.

Recent measurement studies confirm how serious the problem remains.

An Ofcom-commissioned study measured mobile and on-board Wi-Fi performance across 50 journeys on 24 railway lines in Great Britain during February and March 2026. Its “Good Performance” threshold required at least 5 Mbit/s download, 1.5 Mbit/s upload and latency of no more than 50 milliseconds in the same test cycle.

The best-performing mobile network met that threshold only 42% of the time. The other three networks achieved between 17% and 21%. On-board Wi-Fi met the threshold just 1% of the time. Ofcom also found that latency was often the factor that caused a test to fail, even when download and upload speeds appeared adequate.

While this is a UK study, the problem is by no means unique to the UK. Ookla’s Q2 2025 comparison of train Wi-Fi across Europe and Asia found enormous differences between countries. Sweden achieved a median download speed of 64.58 Mbit/s, followed by Switzerland at 29.79 Mbit/s. At the other end of the scale, the UK achieved 1.09 Mbit/s and the Netherlands just 0.41 Mbit/s. The gap between the strongest and weakest markets was as much as 158 times.

The variation is important because it demonstrates that poor connectivity is not an unavoidable consequence of travelling by train. The engineering challenges are common, but the results depend heavily on how rail connectivity is planned, funded and operated.

Mobile networks are normally designed around where people live, work and spend most of their time. Sites are positioned and optimised to serve towns, cities, business areas and roads. Railway lines frequently pass through rural areas, cuttings, forests, valleys and other places where there may be little commercial demand beyond the passengers moving through.

A train may therefore spend much of its journey travelling along the edge of several mobile cells rather than through a strong, continuous coverage layer designed for the railway. A conventional mobile coverage map may show service in the surrounding area without accurately representing the signal available inside a carriage moving along the track.

Even where the outdoor signal is usable, it still needs to enter the train.

Modern rolling stock contains metal bodywork, foil-backed insulation and energy-efficient glazing. Low-emissivity windows often contain thin metallic coatings that reduce heat transfer but also reflect or absorb radio signals. The signal available outside the train can consequently be far stronger than the one reaching a passenger’s phone.

The uplink can be even more difficult. A mobile base station has relatively high transmit power, large antennas and sophisticated radio processing. A smartphone has limited power and a very small internal antenna. The phone must transmit back through the same coated windows and carriage structure that weakened the incoming signal.

This can explain why a passenger appears to have a reasonable signal or acceptable download speed but still struggles with video calls, file uploads, cloud applications and voice over IP.

Speed adds another layer of complexity. A phone or on-board communications gateway must continually measure nearby cells and hand the connection from one to another. At high speed, the device remains within each cell for less time and radio conditions can change significantly between a measurement and the handover itself.

Short interruptions may be almost invisible to a background download, but they can freeze a video call, interrupt a conversation or cause an application session to time out. Tunnels, deep cuttings, hills, buildings and vegetation can create additional sudden changes in signal quality.

Capacity is also shared. A single train can bring hundreds of connected devices into a mobile cell at almost the same moment. That cell may also serve a station, surrounding homes, businesses, road users and another train travelling in the opposite direction. During busy periods, this concentrated demand can increase latency, reduce throughput and create packet loss.

On-board Wi-Fi does not bypass all these challenges.

The passenger’s device connects to an access point inside the train, but the traffic must then pass through an on-board gateway and roof-mounted antennas before reaching an external network. Most train Wi-Fi therefore depends on the same public mobile coverage that passengers may already be struggling to use directly.

A strong Wi-Fi icon only confirms that the passenger has a good connection to the access point. It says nothing about the quality or capacity of the train-to-ground backhaul.

Legacy on-board equipment can make the problem worse. Ookla found that nearly two in five train Wi-Fi connections across the European markets studied still used Wi-Fi 4, while around 22% used the lower-capacity and more interference-prone 2.4 GHz band. Newer Wi-Fi generations and 5 GHz can improve performance within the carriage, but Ookla concluded that the external backhaul is generally the dominant bottleneck.

Simply adding 5G is not a complete answer either. 5G can provide more spectrum, greater capacity, improved latency and better radio efficiency. Ofcom found that 5G Standalone produced a substantial improvement where it was available, but its availability along the measured routes was inconsistent.

The railway still needs continuous outdoor coverage. The signal still needs to enter the train, capacity is still shared, handovers still need to work and the on-board equipment and backhaul must support the service. A 5G icon does not guarantee that every link in this chain is performing well.

There are several possible solutions, but none solves the whole problem independently.

The conventional mobile network can be improved by adding sites near railway coverage gaps, aiming antenna sectors along the track, using lower-frequency spectrum for reach and penetration, and adding capacity around busy stations and corridors.

Where conventional macro coverage is insufficient, dedicated trackside networks can provide closely spaced sites, directional antennas, engineered tunnel coverage and high-capacity fibre or microwave backhaul. This changes the planning objective from serving nearby towns and roads to serving the railway itself.

Trains can use high-performance roof-mounted antennas connected to intelligent on-board gateways. These systems can combine connections from multiple mobile operators and dynamically switch or bond links as conditions change. Genuine diversity is greatest where the operators use independent infrastructure rather than sharing the same underlying radio network.

Laser-treated, RF-permeable windows provide another approach. Fine patterns are removed from the metallic window coating, allowing more of the outdoor mobile signal to enter while retaining much of the window’s thermal performance. Tests cited by Ookla reported losses of approximately 20 to 30 dB from conventional coated windows, and Deutsche Bahn has announced a large-scale programme to treat tens of thousands of windows.

This is a passive solution that can benefit passengers using different networks and frequency bands. However, it only improves signal entry. It cannot create outdoor coverage or additional network capacity.

Active systems such as repeaters, distributed antenna systems and on-board small cells can bring mobile service directly into the carriage. These systems must be carefully engineered and coordinated with the mobile operators.

There is also an interesting interaction between repeaters and RF-permeable windows. A repeater requires sufficient isolation between its external donor antenna and the service antennas inside the train. If more of the amplified indoor signal escapes through treated windows and reaches the donor antenna, it can reduce isolation and create feedback, gain reduction or oscillation. Repeaters and treated windows can coexist, but they need to be designed and tested as one RF system.

For passenger Wi-Fi, the likely long-term architecture is a hybrid one. Modern Wi-Fi 6 or Wi-Fi 7 access points inside the carriage can connect to an intelligent gateway combining multiple cellular operators, dedicated trackside networks, station connectivity and low Earth orbit satellite backhaul.

LEO satellite systems such as Starlink and OneWeb are increasingly being considered as complementary links, particularly on rural and lightly served routes. They are not replacements for terrestrial connectivity because tunnels, deep cuttings, buildings and vegetation can obstruct the view of the sky. Rail-certified terminals must also meet demanding requirements for vibration, weather protection, power and electromagnetic compatibility. The most resilient approach is therefore to combine satellite and terrestrial links rather than depend entirely on either one.

Ultimately, there is no single fix for poor connectivity on trains. Reliable service requires the complete chain to work together: Railway-specific outdoor coverage + signal entry into the carriage + on-board distribution + sufficient backhaul + reliable mobility + capacity management + commercial coordination

Improving only one layer can leave another layer as the bottleneck. The train operator, rail infrastructure owner, mobile operators, rolling-stock manufacturer, connectivity provider, regulator and government all control different parts of the solution.

The video below explores these challenges and possible solutions in more detail.

Finally, for anyone working on passenger connectivity, train-to-ground communications or trackside infrastructure, TrainComms 2026 takes place in London on 18 and 19 November. The conference brings together train operators, rail infrastructure organisations, mobile and satellite connectivity providers, equipment vendors and other specialists to discuss on-board Wi-Fi, trackside wireless networks and emerging LEO satellite solutions. I will be attending again this year, so please do say hello if you are there. 

Related Posts: 

• Connectivity Technology Blog: Boosting 5G Coverage with Transparent Antennas and Shared Infrastructure
• The 3G4G Blog: A Different Approach for Mobile Network Densification
• Connectivity Technology Blog: Seamless 5G Connectivity Across Germany on Deutsche Bahn
• The 3G4G Blog: The Digital Railway supported by FRMCS
• Telecoms Infrastructure Blog: London Underground Mobile Network Infrastructure
• Telecoms Infrastructure Blog: Bringing Connectivity to Underground Rail Network
• Connectivity Technology Blog: Futuristic Glass Antenna by NTT Docomo and AGC 

From 3GPP MPS to Wi-Fi 7 EPCS

Back in January 2011, I wrote about Enhanced Multimedia Priority Service, or eMPS, in 3GPP Release 10. At the time, the focus was on extending priority treatment beyond basic voice calls to packet data and multimedia sessions over LTE and EPC.

The basic requirement has not changed. During a major incident, commercial communication networks may become heavily congested at exactly the time when certain authorised users most need to communicate. These users may include government personnel, emergency management officials and others assigned National Security or Emergency Preparedness, NS/EP, responsibilities.

3GPP addresses this through Multimedia Priority Service, or MPS, specified in TS 22.153. MPS is not a separate radio system and it should not be confused with public emergency calling. It is a mechanism that gives authorised Service Users priority treatment on commercial networks, increasing the probability that their voice, video or data communications can be successfully established and maintained during congestion.

In my original post, I explained that this required more than simply prioritising user-plane packets. End-to-end priority could involve NAS and AS signalling establishment, session establishment, resource allocation in the radio and core networks and treatment of the media bearers themselves.

Fifteen years later, the interesting development is that this idea is expanding beyond the traditional cellular access network.

The challenge is easy to understand. An authorised priority user may have an MPS subscription with a mobile operator, but that user may be inside a building, transport hub, stadium, campus or other environment where connectivity is provided over Wi-Fi. Even where cellular coverage exists, the device may already be using Wi-Fi because of local coverage, capacity or policy.

The question is therefore no longer just how to prioritise an NS/EP user in LTE or 5G. It is how priority authorisation can follow the user across different access technologies.

There are actually two related but different technical developments taking place.

The first is within 3GPP itself. In Release 19, a change to TS 22.153 added explicit MPS requirements for situations where a UE is using a 3GPP radio access technology, such as NR or E-UTRA, and non-3GPP WLAN access connected to the same EPC or 5GC. The associated work item is MPS_WLAN, or MPS when access to EPC/5GC is WLAN.

This is important, but it is still primarily a 3GPP system view. The WLAN is acting as non-3GPP access towards the mobile core.

The second development goes further. Wi-Fi 7 introduces Emergency Preparedness Communications Service, or EPCS, functionality that can provide preferred or prioritised channel access to authorised users. This means that priority treatment can also be applied on the Wi-Fi access network itself.

This creates a different architectural problem.

Wi-Fi can define how the Access Point, AP, and Station, STA, support prioritised channel access, but the Wi-Fi network still needs to know whether the user is genuinely authorised to receive that treatment.

The network therefore needs to determine whether the user is authenticated, whether the user is authorised for Priority Services, what priority level has been assigned, whether that authorisation is valid in the relevant regulatory jurisdiction and whether the network and device support the required EPCS capabilities.

This is the gap that the current IETF work is attempting to address.

The latest version at the time of writing is draft-gundavelli-radepcs-02, titled RADIUS attributes for National Security and Emergency Preparedness Service. It is an active Internet-Draft and work in progress rather than an approved IETF standard. The draft describes RADIUS extensions for authorising EPCS users so that they can receive preferential access to Wi-Fi network resources during congestion.

The proposed architecture reuses mechanisms already widely deployed for managed and roaming Wi-Fi, including Passpoint, EAP and RADIUS.

A user is first authorised for Priority Services by an appropriate Authorising Entity. The service provider receives this authorisation and stores the relevant priority information against the subscriber profile. Where the service provider is also a cellular operator and Wi-Fi Identity Provider, the priority service subscription information can be mirrored into the Wi-Fi AAA system.

The overall architecture and signalling flow are shown below.

The first part of the process is network discovery. An EPCS-enabled Wi-Fi network advertises an EPCS Roaming Consortium, while the authorised user's device contains a corresponding Passpoint profile. The device can discover the relevant roaming information and select the network using normal Passpoint mechanisms.

After the device associates with the Wi-Fi network, EAP authentication is performed and the AP or Wireless LAN Controller forwards the authentication exchange towards the Identity Provider using RADIUS.

This is where the proposed new RADIUS attributes become important.

EPCS-Capable-Indication allows the Wi-Fi Network Access Server to tell the RADIUS server that it supports EPCS. The capability information can also indicate whether priority treatment is possible only when the user device itself supports EPCS, or whether some treatment, such as downlink prioritisation, may still be possible for a non-EPCS device.

EPCS-Regulatory-Info provides information about the regulatory regime under which priority service is being authorised. This may contain an ISO 3166-1 country code or ISO 3166-2 subdivision code. This matters because priority authorisation and priority levels may be specific to a particular country or jurisdiction.

EPCS-Subscription-Info indicates that the authenticated user is authorised to receive Priority Services and carries the priority level associated with the user's subscription. The priority levels themselves are administered according to the relevant regulatory regime.

The important point is that the Wi-Fi network does not independently decide that a user should receive priority.

The authorisation originates from an external authority and is linked to an authenticated identity or subscription.

Authentication and priority authorisation are therefore separate. Successfully authenticating to a Wi-Fi network does not automatically make someone an EPCS user.

Once the AAA system confirms that the user is authorised, the AP/WLC can enable EPCS Priority Access for the device. Where both the network and device support EPCS, uplink and downlink traffic can receive priority treatment. Depending on the capabilities of the network, downlink traffic may still be prioritised even when the device itself does not support EPCS. The exact mechanism used by the network to prioritise the traffic is vendor-specific and outside the scope of the current IETF draft.

There are several interesting aspects to this architecture.

First, the solution uses the existing Wi-Fi roaming framework rather than creating an entirely separate emergency network discovery and authentication mechanism. Passpoint supports automatic discovery and network selection, EAP handles authentication and RADIUS carries the EPCS authorisation information.

Second, location and regulatory information become part of the authorisation process. A user authorised for a particular level of priority in one jurisdiction may not necessarily be entitled to the same treatment everywhere.

Third, the network needs to separate a user's normal access credentials from their entitlement to Priority Services. An ordinary subscriber, an authenticated Wi-Fi user and an authorised EPCS user may all use the same access network but receive very different treatment during congestion.

Finally, this is not simply a matter of giving some packets a higher priority marking.

Real end-to-end priority may involve access to the Wi-Fi medium, AP queues, backhaul networks, interconnected networks and application traffic. The IETF draft identifies authentication, authorisation, traffic identification and prioritisation as separate requirements. Where networks interconnect, priority indicators may also need to be passed securely to downstream networks.

It is also worth stressing the difference between Priority Services and emergency calling.

An ordinary user attempting to call 999, 112 or 911 is not automatically an NS/EP Priority Service user. Emergency calling is about allowing the public to reach emergency services, potentially even when normal cellular coverage or credentials are unavailable.

MPS and EPCS are different. They are intended for authorised users or organisations that have been assigned priority privileges so their communications have a greater probability of success during congestion.

The Wireless Broadband Alliance has been working on both areas through its Mission Critical and Emergency Services programme. Its work covers emergency calling over Wi-Fi, cellular emergency calling over OpenRoaming and NS/EP priority communications. For the priority case, the focus is on using Wi-Fi, Passpoint and roaming mechanisms to extend capabilities traditionally associated with cellular networks.

For me, the interesting part is how the boundaries between cellular and Wi-Fi continue to blur.

3GPP MPS started from the assumption that priority treatment had to be provided across the cellular system, from access signalling through to core network resources and application sessions. 3GPP has now added explicit requirements for MPS when 3GPP and WLAN accesses connect to the same EPC or 5GC.

At the same time, Wi-Fi 7 provides EPCS mechanisms for prioritised channel access, while Passpoint and the proposed RADIUS extensions provide a possible way to discover the service, authenticate the user and transfer priority authorisation into the Wi-Fi network.

The result is not a replacement for cellular MPS, and it is not simply Wi-Fi QoS.

It is the beginning of a more access-independent model in which an authorised user's priority status could potentially follow them across cellular and Wi-Fi networks, with each access technology applying the appropriate mechanisms within its own domain.

That is a much more interesting evolution than simply adding another priority bit to the network.