Train-to-Train Communication: The Future or a Fantasy?

Every five years or so, an industry conference paper proposes that direct train-to-train (T2T) communication is the next architectural step beyond Communications-Based Train Control (CBTC). The idea is straightforward in concept: instead of routing every position report and every Movement Authority through a wayside Zone Controller, trains exchange position and intent directly with the trains around them, and each train computes its own safe distance to its neighbors. Proponents point to the latency savings (one network hop instead of two), the architectural elegance (no wayside computer), and the analogy to vehicle-to-vehicle (V2V) systems in automotive. Skeptics point to the safety case (a SIL 4 distributed-consensus system has never been certified in transit), the spectrum problem (where is the bandwidth?), and the operational reality (Zone Controllers do more than calculate Movement Authorities). This article walks through both sides of the argument and identifies the operating profiles where T2T might actually be competitive.

The proposal in concrete terms

Train-to-train communication, as proposed for transit signaling, replaces the wayside-mediated Movement Authority loop with a direct exchange. In the conventional CBTC architecture (covered in The Movement Authority Concept: How a CBTC Train Decides How Far to Go), each train reports its position to the Zone Controller every 500 milliseconds to 1 second; the Zone Controller computes safe spacing across all trains in its territory and issues Movement Authorities back. The round-trip is two radio hops plus the Zone Controller’s compute cycle.

In the T2T architecture, each train broadcasts position, speed, and intent to all trains within radio range; each train independently computes its safe distance to the train ahead based on the broadcasts it receives; each train enforces its own braking curve. There is no Zone Controller in the safety loop. Coordination with switches, signals, and PSDs still requires wayside infrastructure, but the train-spacing computation is distributed.

The European Train Control System (ETCS) has explored a version of this concept under the label “Hybrid Level 3” or “Moving Block on Mainline,” with at least one revenue-service trial. The transit-CBTC analog has been discussed in industry workshops for at least a decade without revenue deployment.

The case for T2T: latency and architectural simplicity

The latency argument is the most often cited. A conventional CBTC Movement Authority loop is, in round numbers, 1.5 to 3 seconds end to end (covered in End-to-End Latency in CBTC: Where the Milliseconds Go). Train A reports its position at time t; the wayside ZC receives the report, computes the implications for Train B’s safe distance, and transmits an updated Movement Authority to Train B; Train B receives the MA and acts on it. The two-hop round-trip plus ZC compute is the dominant latency contribution.

T2T cuts this in half. Train A broadcasts its position; Train B receives it directly and computes the safe distance on its own VOBC. The single-hop latency is roughly 250 to 500 milliseconds end to end, depending on the radio and the message-rate budget. Reducing the latency from 1.5 to 3 seconds to 250 to 500 milliseconds removes the largest single contributor to safety headway. The theoretical headway floor on a busy urban metro could shift from about 90 seconds toward 70 seconds.

The architectural argument is that the Zone Controller becomes optional. A line that previously required 5 to 8 Zone Controllers (each with its hot-standby pair, equipment room, and HVAC) might require only one or two coordination computers handling switches and PSDs. The capital savings and the operational simplification are substantial.

The procurement argument is that T2T might enable open standards in a way that wayside-mediated CBTC has resisted. If trains exchange position and intent over a defined T2T protocol, in principle a multi-vendor fleet could interoperate on the same line.

The case against: the safety case is hard

The safety-case argument is where T2T is most contested. SIL 4 functions in CBTC today are implemented in concentrated, certifiable, hot-standby computers (the Zone Controller and the VOBC). The certification effort is substantial but bounded; the safety logic resides in code that can be formally verified, regression-tested, and audited.

T2T moves the safety logic into a distributed consensus protocol. Each train depends on the broadcasts of every other train within range. If Train C broadcasts a corrupted position, Train B’s safety computation is wrong. If two trains disagree about which is ahead, the safety logic must converge to a consistent answer in bounded time. If a train fails to broadcast, every other train must detect the absence and adjust. These are well-studied problems in distributed systems, but they are unfamiliar to railway safety regulators and they push the safety boundary into territory that has no precedent in transit revenue service.

The hardest specific problem is broadcast integrity under Byzantine conditions. Conventional CBTC defends against false position reports because the Zone Controller cross-checks reports against trajectory plausibility, against neighbors’ reports, and against wayside detection (where present). In T2T, the cross-check is the same in concept but distributed across receivers, each of which must independently catch a malformed broadcast without coordination. The EN 50159 message-layer protections (sequence numbers, timestamps, MACs, CRCs) defeat naive corruption and replay, but the Byzantine case — a train that broadcasts plausible-looking false data — is a research problem.

A second specific problem is fail-silent behavior. If a train’s onboard transmitter fails silently, conventional CBTC catches it within the 3- to 5-second timeout because the Zone Controller stops receiving heartbeats. In T2T, multiple receivers must independently detect the silence and converge on a response — the train must be excluded from the spacing calculation, but exclusion must not propagate to inadvertent loss of safety from the silent train’s perspective. The protocol has to handle the silent-failure case without introducing new failure modes.

The case against: spectrum and density

The spectrum argument is harder and rarely discussed in promotional materials. Conventional CBTC uses Wi-Fi access points spaced 150 to 350 meters apart, with each train communicating to one access point at a time. The spectrum reuse is high because each cell is small and each cell handles one or two trains.

T2T requires broadcasts that reach every train within braking distance. On a busy metro at 80 km/h, braking distance is 250 to 350 meters. The broadcast range therefore needs to be at least 500 meters to reach the train ahead and the train behind. Now consider a peak operation with 30-second headways and 200-meter trains: there are five to seven trains within mutual broadcast range at any moment. Each is broadcasting at, say, 4 Hz with 200-byte messages. The aggregate spectrum demand goes up by roughly an order of magnitude versus the corresponding wayside-mediated case.

The 5 GHz spectrum used by current CBTC is congested in dense urban environments. Adding T2T broadcasts on the same spectrum is feasible but tight; it leaves no room for growth. Moving T2T to a different spectrum (LTE-V2X sidelinks, dedicated 5G NR-V2X) is technically possible but introduces a regulatory dependency on FCC spectrum allocation that has no current rail-specific assignment.

The case against: the Zone Controller does more than calculate MAs

The Zone Controller’s job is not only to compute Movement Authorities. It also coordinates with the Electronic Interlocking, manages zone-boundary handover, supervises switch routes, integrates with the SCADA and ATS, and provides the central choke point for safety-message validation. Removing the Zone Controller from the train-spacing path does not remove these other responsibilities; it scatters them across the train fleet (impractical) or pushes them to a thin “coordination computer” that ends up looking suspiciously like a Zone Controller without the train-spacing function.

A practical T2T architecture therefore retains a wayside computer for switches, signals, PSDs, and ATS coordination — and the architectural simplification is smaller than the marketing suggests. The capital savings come from removing the redundant wayside ATP function, not from removing all wayside computing.

Aspect	Conventional CBTC	Train-to-Train (T2T)
Latency	1.5 to 3 seconds	250 to 500 milliseconds
Architecture	Zone Controller required	Zone Controller optional
Spectrum Demand	Low	High
Safety Case	Centralized SIL 4	Distributed consensus SIL 4
Operational Profile	Existing heavy-rail metros	Single-line driverless metros, long-distance regional rail
Wayside Infrastructure	Required for all functions	Required for switches, signals, PSDs

The operating profiles where T2T might actually win

T2T is not categorically a fantasy. The interesting question is the operating profile where the latency advantage outweighs the safety-case difficulty.

Single-line driverless metros at very tight headways. A driverless metro line operating at 75-second headways has the largest latency-to-headway ratio in current transit operations. The 30 to 50 percent latency reduction T2T offers translates directly into headway capacity. The single-vendor, single-line scope simplifies the safety case because the distributed consensus problem is bounded by the known fleet.

Long-distance regional rail with sparse train density. The opposite end of the density spectrum. With trains 5 to 10 kilometers apart, broadcast range is constrained by physical reach rather than by spectrum congestion, and the wayside-infrastructure cost of conventional CBTC is large because zone equipment rooms must be sited at frequent intervals across rural geography. T2T removes that infrastructure and the latency penalty is unimportant because headways are minutes, not seconds.

Specialized applications: yards, depots, and maintenance facilities with low-speed, variable-density operations. T2T-style direct messaging between maintenance vehicles and trains under operator control is, in some procurement scope, already implemented as a low-SIL operations protocol. Extending this to revenue service is a smaller jump than greenfield T2T on a metro.

The applications T2T is least likely to win are exactly the applications conventional CBTC dominates: existing US heavy-rail metros at 90- to 120-second headways with mixed legacy and modern fleets. The retrofit cost, the multi-vendor problem, and the safety-case unfamiliarity stack against T2T in the segment where the current installed base is concentrated.

Practical takeaways

• Train-to-train communication is technically real, has at least one revenue ETCS Hybrid Level 3 trial, and offers a 30 to 50 percent reduction in safety-message latency by removing one network hop from the Movement Authority loop.
• The safety case is the binding constraint. Distributed consensus protocols at SIL 4 are unfamiliar to transit regulators; Byzantine broadcast integrity and fail-silent detection are research problems with no certified transit precedent as of 2026.
• The spectrum demand of T2T grows roughly by an order of magnitude over wayside-mediated CBTC at peak metro density, requiring either spectrum-management discipline or a move to dedicated V2X spectrum that has no current rail allocation.
• The architectural simplification is smaller than promotional materials suggest. Switches, signals, PSDs, and ATS coordination still require a wayside computer; T2T removes the wayside ATP function but not all wayside computing.
• The operating profiles where T2T is most likely to win are single-line driverless metros at very tight headways and long-distance regional rail with sparse train density. The US heavy-rail metro retrofit market — the largest CBTC market — is the profile T2T is least likely to displace.

Where to go next

This post is a 10-minute engineer’s evaluation. The full treatment of CBTC architecture, communication systems, and where T2T fits in the technology roadmap lives in Communications-Based Train Control (Volume 1 on Amazon). Download the Chapter 6 slides (free PDF).

For the conventional wayside-mediated MA loop T2T proposes to replace, see The Movement Authority Concept: How a CBTC Train Decides How Far to Go. For the latency budget that quantifies the T2T advantage, see End-to-End Latency in CBTC: Where the Milliseconds Go. For the European hybrid analog, see CBTC vs ETCS: A Side-by-Side for US Engineers.

Sources

• Wang, C. (2026). Communications-Based Train Control, Volume 1: Foundations & Technical Architecture. Independent. ISBN 979-8-258-54295-3. — Chapter 3, “CBTC System Architecture Overview”; Chapter 6, “Communication Systems.”
• IEEE Standards Association. IEEE Std 1474.1: Communications-Based Train Control (CBTC) Performance and Functional Requirements.
• International Union of Railways. ERTMS / ETCS Level 3 — Hybrid Concept Description. uic.org
• European Union Agency for Railways. ERTMS Level 3 Trial Reports. era.europa.eu
• 3GPP. Release 16 NR-V2X: Sidelink Communications. 3gpp.org
• IEEE Standards Association. IEEE 1609 series: Wireless Access in Vehicular Environments (WAVE).
• Federal Transit Administration. State Safety Oversight Program. transit.dot.gov/regulations-and-guidance/safety/state-safety-oversight
• CENELEC. EN 50159: Railway applications — Communication, signalling and processing systems — Safety-related communication in transmission systems.