Connected vehicle data and traffic signal coordination sit at the intersection of two infrastructure domains that have historically operated independently. On one side: the road-based sensing and signalling layer managed by transport authorities. On the other: the onboard data systems in modern vehicles, which increasingly broadcast position, speed, heading, and intent. When these two layers exchange information in real time, signal controllers gain inputs they've never had before, and the coordination logic changes significantly.
What connected vehicles actually broadcast
Most connected vehicle implementations use a protocol called DSRC (Dedicated Short-Range Communications) at 5.9 GHz, or the newer C-V2X (Cellular Vehicle-to-Everything) standard, which uses LTE or 5G mobile networks as the transport layer. Both carry a Basic Safety Message (BSM), a standardised data packet transmitted up to 10 times per second. Each BSM contains the vehicle's GPS position, speed, heading, acceleration, and brake status. That's enough for a signal controller to calculate time-to-arrival at the stop line with reasonable accuracy.
The practical implication: a controller equipped to receive BSMs doesn't need to infer queue length from a loop detector or a camera. It receives speed and position data directly from every broadcasting vehicle in the approach zone. That shifts queue estimation from a statistical inference to a direct measurement, at least for the fraction of the fleet that is currently connected.
How signal coordination changes with connected inputs
Traditional coordination relies on fixed-time plans or, in more advanced deployments, adaptive signal control that responds to live traffic conditions using roadside sensors. Both methods observe traffic from the outside: a detector senses a vehicle passing over it or entering a detection zone. Connected vehicle data inverts this. The vehicle reports itself to the infrastructure, rather than waiting to be sensed.
This changes two things in coordination logic. First, look-ahead distance increases. A loop detector at 100 metres from the stop line gives the controller roughly 4 to 6 seconds of lead time at urban speeds. A BSM received at 500 metres gives 15 to 20 seconds. That additional time allows the controller to adjust phase timing before the vehicle reaches the intersection, rather than reacting as it arrives. Second, vehicle intent becomes available. Where connected vehicle systems include SPaT (Signal Phase and Timing) broadcasts, the exchange becomes bidirectional: the signal tells the vehicle the current phase state and time-to-change, and the vehicle can respond by adjusting speed to arrive on green. This is called Eco-Approach and Departure (EAD) and it reduces stop-and-go cycling, which is where both fuel use and delay concentrate.
Infrastructure requirements for receiving connected vehicle data
Deploying connected vehicle inputs at a signalised intersection requires more than software. The controller must have a roadside unit (RSU) capable of receiving and decoding DSRC or C-V2X messages. The RSU connects to the signal controller via a data interface, typically Ethernet with a defined message schema. The controller firmware must include logic to parse incoming BSMs, validate position against the approach geometry, and translate vehicle count and speed data into phase timing adjustments.
Beyond the intersection itself, a back-office system is usually needed to manage RSU firmware, monitor data quality, and log connected vehicle events. This is where the data infrastructure requirements grow considerably. The volume of BSMs across even a modest network of 20 intersections can reach hundreds of thousands of records per hour. Traffic signal cabinets that log operational data already manage significant write loads; adding BSM streams to that environment requires storage planning that accounts for both throughput and retention.
The partial penetration problem
Connected vehicle data is only useful for signal coordination if enough vehicles in the approaching stream are broadcasting. This is the penetration rate problem, and it's not trivial. Current estimates for connected vehicle market penetration in Australia sit well below 20% of the active fleet. That means a controller relying solely on BSM inputs for phase decisions would be working from an incomplete picture of the actual queue.
The practical response is hybrid detection: connected vehicle data supplements, rather than replaces, conventional sensing. A controller running adaptive logic might weight loop detector data, radar counts, and BSMs together, assigning confidence scores to each source based on historical accuracy at that location. As penetration rises over the coming decade, the weighting shifts toward connected inputs. But the hybrid architecture is the operational reality for any deployment happening now.
This also affects how engineers think about queue detection at signalised intersections. Connected vehicle inputs give high-resolution position data for vehicles that broadcast, but the non-connected vehicles in the same queue remain invisible to BSM-based logic. Sensor fusion is the only viable answer, which means the roadside sensing layer can't be decommissioned simply because a connected vehicle pilot is running.
SPaT broadcasting and the signal controller's outbound role
Signal Phase and Timing (SPaT) messages are the outbound complement to BSMs. When an RSU broadcasts SPaT data, approaching connected vehicles receive the current phase state, the time remaining in that phase, and the upcoming phase sequence. Navigation systems and onboard driver assistance features can use that data to advise the driver on optimal approach speed or, in automated vehicle applications, to control the vehicle directly.
SPaT broadcasting doesn't require the controller to change any of its internal timing logic. The RSU reads the controller's current state and reformats it as a SPaT message. In that respect, SPaT is easier to deploy than full bidirectional coordination: it adds value to connected vehicles without requiring the controller to process incoming BSMs at all. Many transport authorities have started here, broadcasting SPaT as a read-only data feed, before committing to the more complex inbound processing architecture.
The Australian Government's connected and automated vehicle policy framework identifies SPaT deployment as a near-term infrastructure priority, which is relevant for councils and state transport departments planning signal upgrades over the next few years.
What this means for signal controller procurement
Procurement decisions made now will define whether intersections can participate in connected vehicle coordination for the next 10 to 15 years. Controllers specified without a defined external data interface, or without firmware that supports NTCIP (National Transportation Communications for ITS Protocol) message sets, will require costly hardware replacement rather than a software update when V2X deployment scales.
The checklist isn't long. Controllers should support an Ethernet data port with documented API access, NTCIP-compliant SPaT message formatting, and a processor architecture with headroom for additional message parsing load. RSU compatibility should be confirmed at the controller level, not assumed. And the cabinet itself needs to be sized for an additional RSU power supply and communications module.
The Austroads connected vehicles technical guidance documents, published through the AP-R series, set out the recommended interface specifications in detail. They're the right reference point for any Australian procurement specification that intends to be V2X-ready.
Timing the transition in practice
Transport authorities don't need to wait for fleet penetration to reach a threshold before deploying connected vehicle infrastructure. SPaT broadcasting can start delivering value immediately, both as a service to connected vehicles already on the road and as a data collection exercise that builds the empirical baseline for future coordination tuning. Inbound BSM processing can be activated progressively as controller firmware matures and RSU hardware costs continue to fall.
The intersection that installs an RSU today and broadcasts SPaT data is already part of the connected vehicle ecosystem. It's collecting data, it's verifiable in mapping databases used by connected vehicle manufacturers, and its controller team is learning the operational discipline the technology requires. That position is meaningfully different from an intersection that defers the question until penetration rates make the business case obvious.