Brighton – London Rail
Mobile Connectivity Pilot — 2025
Inakalum was commissioned by Ofcom, the UK telecoms regulator, to run a pilot mobile-connectivity survey across the Brighton–London rail corridor. Across 7 days in June–July 2025 we surveyed 44 journeys in both directions, at peak and off-peak times, on Thameslink, Gatwick Express and Southern services. All four UK networks — plus the on-board Wi-Fi — measured simultaneously, every five metres, every five seconds.
- Client
- Ofcom (UK telecoms regulator)
- Survey window
- June – July 2025 (7 days)
- Journeys captured
- 44 (peak & off-peak, both directions)
- Networks measured
- EE · Vodafone · VMO2 · Three · onboard Wi-Fi
- Measurements
- 500,000+ across all four MNOs
The regulator asked the question. We answered it on the train.
Mobile coverage on UK rail is one of the most persistent connectivity files in the country. Operators have published coverage maps for years. The Department for Transport, the train operating companies, Network Rail and Ofcom itself have pushed separate workstreams. None of those workstreams, however, produced a like-for-like, multi-operator, on-train measurement of what passengers actually experienced. Ofcom commissioned Inakalum to do exactly that, on one of the busiest commuter corridors in the UK.
The deliverable was simple: take a NetworkUX kit on a train, in both directions, at peak and off-peak, repeatedly, on every operator, and produce ground-truth data that Ofcom could analyse, share with operators, and build policy around. The work that follows on this page is the public-facing summary of that pilot.
A NetworkUX kit. On 44 train journeys. Both directions.
The NetworkUX kit that already runs in bin lorries for Westminster, Manchester and the Tees Valley is battery-powered, self-contained and portable. The same kit travelled in a backpack on each Brighton–London journey, with no train-side wiring and no impact on Thameslink, Gatwick Express or Southern operations.
4 operators + Wi-Fi, simultaneously
Each NetworkUX kit holds four Samsung Galaxy 5G-compatible devices, each on an unthrottled SIM for one of EE, Vodafone, VMO2 and Three. The same kit measured the onboard Wi-Fi service alongside the mobile operators — like-for-like, identical conditions, every measurement timestamped and geo-referenced.
5 seconds or 5 metres — whichever first
The apps trigger a measurement on whichever happens first: 5 seconds elapsed or 5 metres travelled. At rail speed that produces dense, granular data along every metre of track — not a sparse sample every kilometre.
4 file sizes on every throughput test
Each performance test uploaded and downloaded files of 512 KB, 1 MB, 2 MB and 5 MB. Larger files surface throughput problems that a single small file would miss — and tell you whether the issue is a slow connection or a connection that fails before completing.
44 journeys, 3 train operators, 3 fare classes
Brighton ↔ London Blackfriars (Thameslink), Brighton ↔ London Victoria (Gatwick Express and Southern), with three return journeys per day across seven days. Surveys covered Peak, Off-Peak and Super Off-Peak fare-class windows to capture the full daily load curve.
Two trains on the same track. Two different stories.
A standard coverage map doesn’t fit rail. Two trains can be on the same stretch of track at the same time and have entirely different mobile experiences — one is heading into the morning rush, packed; the other is heading away from it, half-empty. Coverage looks identical from a tower; capacity doesn’t. So we built a Rail Analysis extension to the NetworkUX RAG Polygon tool that lets the data be queried the way trains actually run.
Direction-of-travel filter
Origin and destination stations select journeys by direction. Southbound peak, northbound off-peak, and every other combination are first-class filters.
Fare-class filter
Peak / Off-Peak / Super Off-Peak are the load proxies that actually predict capacity stress on the network. The tool returns results by fare class as readily as by time of day.
Tunnel include/exclude
Tunnels are inherently no-signal zones. The filter lets analysts include them for a complete passenger picture, or exclude them when investigating cell-level performance in open track.
Per-journey selection
Every surveyed journey is in a checkable list with full metadata. Analysts can run queries on a single morning rush-hour journey on Thameslink, or the full 44-journey dataset, without rebuilding the query.
10-metre grid cells
Aggregated polygon visualisations adapt their cell size by zoom level. At the finest scale, 10-metre cells show signal and performance at near-track-level granularity.
Towers & cells overlay
Mobile-mast positions can be overlaid on the maps. Hovering on any signal pin shows the connection to the serving tower. Hovering on any tower shows the spread of measurements served by it — both useful for radio-planning analysis.
Average speeds barely moved at peak. Failure rates exploded.
Across all four UK operators, the data show a small drop in average download and upload speeds between off-peak and peak journeys. The story the chart actually tells is in the third bar: the percentage of failed tests. EE’s failure rate jumped from less than 5% off-peak to over 25% at peak. VMO2, Three and Vodafone all roughly doubled. The averages hide the experience; the failures show what passengers actually feel.
The same chart, read four ways.
Each card pulls the off-peak vs peak numbers for one operator from the chart above. The download and upload differences look modest. The failure-rate column tells you what changed.
“Average speeds barely moved between off-peak and peak. What changed was that EE’s failure rate rose from less than 5% to over 25%. For a passenger, that is the difference between a working journey and a journey where apps just don’t load.” — Inakalum NetworkUX Rail Pilot deliverable, 2025
Brighton to London. Every metre, on every operator.
Vodafone’s signal and performance along the full Brighton–London corridor. The same maps were produced for EE, VMO2 and Three. Reds on the left map are weak signal; reds on the right map are sub-2 Mbps throughput.
What 124,084 signal measurements + 51,754 throughput tests look like.
Three’s dataset gives a sense of the scale. The signal panel shows 5G NSA, 4G, 3G, 2G and No Signal counts with average dBm. The performance panel breaks down by file size — 0.5 MB, 1 MB, 2 MB and 5 MB — with averages, min, max, and timed-out counts.
Onboard Wi-Fi: the fall-back that mostly wasn’t.
The Ofcom brief asked us to measure the onboard Wi-Fi alongside the four mobile operators. Two things stood out. First — on the journeys where Wi-Fi was usable, it was the slowest network on the train by a wide margin and timed out on most large tests. Second — on a third of all surveyed journeys, the Wi-Fi was either never detected or couldn’t be joined at all. The fall-back wasn’t much of a fall-back.
For passengers relying on onboard Wi-Fi when their mobile signal struggled, this wasn’t a redundancy. On most journeys it added a second failed network on top of the first.
A word on tunnels.
Tunnels
Mobile signal in rail tunnels is effectively zero across all four operators, as expected. The Rail Analysis tool can include or exclude tunnels from any query — useful for separating “the cells don’t reach in there” from “the cells reach but the capacity has run out.” Tunnels weren’t a focus of the Ofcom pilot and are excluded from the headline figures above.
Four takeaways for regulators, TOCs and rail-policy teams.
Rail mobile is a capacity problem, not a coverage problem
Across the Brighton–London corridor, coverage was broadly present on all four UK networks. What collapsed at peak was the network’s ability to actually serve the passengers carrying their phones. Coverage-led policy addresses the wrong half of the problem.
Direction of travel is a first-class variable
The two trains passing each other on the same stretch of track at the same time can have completely different mobile experiences. Any rail-mobile dataset that doesn’t separate by direction of travel is mixing two different questions and getting an average of both.
Failure rate is the right metric, not average speed
Average download speed dropped by single-digit percentages at peak. Failure rates rose by factors of two to six. Passenger experience is dominated by whether the connection completes, not by the average speed when it does — and the right policy lever is the failure rate.
The methodology is corridor-ready, not just borough-ready
The same NetworkUX kit and methodology that maps boroughs through bin lorries scales to long-distance rail corridors with no architectural change. Surveying a route is now a matter of putting the kit on a few journeys, not building a bespoke programme.
Same kit, different corridor. Talk to us.
If your remit covers passenger mobile experience — on the railway, on the bus, on the tube, on the tram, on the trunk road, on the cycle network — the same NetworkUX methodology can produce a comparable dataset for your corridor inside a single working week.