11.1 Intelligent Transportation and V2X Communication
11.1.1 The Intelligent Transportation System Framework
A city sees hundreds of thousands, even millions of trips every day, and every vehicle, every traveler, and every traffic light generates data. The hard part of traffic governance is not a lack of data — it is that the data sits scattered across island systems owned by traffic police, public transit, parking, and meteorology, each speaking a different "language," on different time bases, in different formats. Solving the problem requires a common architectural framework: the layered model of the Intelligent Transportation System (ITS). This model was not invented out of thin air; it draws on international standards such as ISO 14813 and their definition of the Traffic Information and Control System (TICS), ensuring that devices and software from different vendors can converse in a unified semantic space.
The goal of ITS is not to build wider roads, but to make roads "used more intelligently." From the perspective of the IoT architecture, intelligent transportation essentially embeds sensing, communication, computing, and decision-making capabilities into the entire physical world of traffic. The four-layer architecture below unfolds from the bottom up: each layer carries a clear engineering responsibility, and the layers are decoupled from one another through standardized interfaces.
The sensing layer answers the fundamental question of "what is happening on the road." Its devices include geomagnetic loops, microwave radar, LiDAR, cameras, meteorological sensors, and in-vehicle communication units (On-Board Units, OBUs — V2X vehicle terminals that typically integrate a positioning module). In the past these devices mostly ran on their own — cameras only captured traffic violations, loops only counted vehicle flow. In the layered architecture, the sensing layer must do one thing: abstract the physical world's heterogeneous signals into data that upper layers can understand. The same intersection may carry sensors from different suppliers, whose output data structures, sampling frequencies, and coordinate systems differ wildly. The common engineering practice is to deploy protocol adapters in roadside cabinets, converting every communication interface into a unified JSON Schema or Protobuf format. The sensing layer is also responsible for emitting "digital license plate" information — the basis for vehicle-cloud security authentication and billing.
The network layer carries sensing data from the roadside and from vehicles to the backend processing centers. Traffic scenarios place special demands on the network: a vehicle passes a Roadside Unit (RSU) at very high relative speed, and emergency-braking warnings demand millisecond-level response. Mainstream options include Dedicated Short-Range Communication (DSRC), Cellular Vehicle-to-Everything (C-V2X), and fiber or industrial Ethernet for roadside backbone connections. The network layer must also solve heterogeneous protocol interworking: one intersection may simultaneously host a signal controller on a serial port, a roadside unit publishing over MQTT, and floating-car GPS data reported over CoAP. An aggregation gateway sits in the roadside cabinet, handling protocol conversion and local caching so that data is not lost to transient network jitter.
The platform layer is the brain of the entire ITS. In the cloud or an edge data center, it handles massive access management (administering millions of device connections), time-series data storage, real-time stream computing, and archival analysis of historical data. What is easily overlooked at this layer is data governance: sensors from different suppliers use different coordinate systems, time bases, and data formats, and without cleansing and alignment, upper-layer analytics cannot be put to work. The platform layer must also expose standard APIs for data exchange with upstream applications and third-party systems. This echoes the practical principle that "connecting all systems through an open platform ... cross-utilization of data is an essential element of success."
The application layer faces traffic managers, drivers, and the public directly. Typical applications include smart signal control, green-wave guidance, transit signal priority, variable lane management, and parking guidance. Design cannot chase single-point optimization alone; a good application system must be built on global optimization objectives, relying on the platform layer for region-wide traffic situational awareness. The application layer must also plan for transitional compatibility: conventional and non-connected vehicles still depend on physical signals, while connected vehicles can receive digitized signal states and navigation guidance — the two modes run in parallel. Going further, the application layer merges shared cars, buses, bicycles, and other travel modes into a "single trip, single interface" combined-mobility service — precisely the core idea of MaaS (Mobility as a Service).
The four-layer architecture is the vertical "skeleton," but intelligent transportation also needs horizontal coordination — the "vehicle-road-cloud" closed loop. Vehicles upload real-time position and motion state through the connected On-Board Unit (OBU), Roadside Units (RSUs) synchronize signal, speed-limit, and incident information, and the cloud platform performs global scheduling and prediction, sending results back down to vehicles through the roadside network. The intelligent connected vehicle plays a dual role here: it is both a data source and an actuator. Understanding the layered architecture and "vehicle-road-cloud" collaboration lays the groundwork for the discussions that follow — V2X communication technology selection and roadside device deployment.
11.1.2 V2X Communication Technology Selection
If connected vehicles form a nervous system, then V2X (Vehicle-to-Everything) communication is the nerve fiber. Vehicles (V), roadside infrastructure (I), pedestrians (P), and the cloud network (N) must exchange information in real time — the car ahead brakes hard, the signal is about to turn red, a pedestrian suddenly steps into view. Whether these messages arrive at all, and when, depends on the underlying communication technology. Choose wrong, and the system exists in name only.
This section takes apart the two widely debated routes: DSRC and C-V2X. They differ markedly in design philosophy, performance boundaries, and industry ecosystem, so selection must weigh deployment cost and the future evolution path alongside technical specifications.
DSRC: A Mature System Built on IEEE 802.11p
DSRC standardization traces back to the late 1990s, when the U.S. Federal Communications Commission reserved the 5.9 GHz band for intelligent transportation. It inherits Wi-Fi's CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) mechanism but optimizes the physical layer for high-speed mobility. The core standard, IEEE 802.11p, supports high relative speeds in vehicular environments, with communication range typically in the hundreds of meters and end-to-end latency held at the level collision warnings require. The IEEE 1609 series (the WAVE protocol stack) defines the upper-layer protocols: 1609.4 specifies multi-channel operation, letting vehicles switch between channels to receive safety messages (such as the Basic Safety Message, BSM) and handle non-safety applications (such as road-test data download) alike; 1609.2 handles encryption and signatures to guarantee message authenticity and tamper resistance.
DSRC is a technology stack backed by extensive validation. It supports direct V2V broadcasting without an RSU as well as V2I communication between vehicles and RSUs. Its contention-based access can increase collisions and latency in high-density traffic; that is separate from whether an RSU is present. Regulatory choices for the 5.9 GHz band and technology paths differ by country and region, and changes to U.S. spectrum policy must not be described as a single global "DSRC sunset." A new project should first verify local spectrum licensing, roadside infrastructure, and the in-vehicle ecosystem, and then compare DSRC with C-V2X rather than deciding on maturity alone.
C-V2X: Cellular Evolution from LTE to 5G
C-V2X was first defined by 3GPP during the LTE era; its core is the PC5 interface (the sidelink). It reuses LTE's OFDM frame structure with a scheduling mechanism designed specifically for connected vehicles, enabling direct vehicle-to-vehicle and vehicle-to-roadside communication without relaying through a base station. The standardization process defined two complementary modes:
- Mode 3: the cellular network centrally allocates time-frequency resources, suited to dense urban scenarios. The base station can coordinate the transmission times of nearby vehicles to avoid collisions.
- Mode 4: vehicles select resources autonomously. Each vehicle uses a sensing algorithm to find an idle channel within a predefined resource pool, so V2V and V2I communication survives even outside base-station coverage. Mode 4 is precisely the key to direct vehicle-to-road communication: roadside information reaches the vehicle in broadcast form, and establishing communication no longer presupposes the presence of a base station.
Mode 4 is the key difference between C-V2X and DSRC: DSRC's CSMA/CA requires vehicles to sense the channel before transmitting, so the collision probability climbs as vehicle density grows; Mode 4, through resource-pool pre-allocation and sensing algorithms, maintains more stable latency and packet loss at high density.
The later 5G NR releases further reduced latency on the PC5 interface, support higher throughput, and add more flexible scheduling. The PC5 interfaces of LTE-V2X and NR-V2X can coexist in the 5.9 GHz band (dual-mode terminals can support both, but the two are different RATs and not directly compatible), enabling smooth evolution. One point worth clarifying: 5G RedCap (Reduced Capability, finalized in 3GPP Release 17 and entering commercial service in 2023–2024) is not used for direct PC5 communication. It targets mid-rate, cost-sensitive backhaul — roadside camera video and gateway data upload, for example — and serves as a middle option between 4G Cat.4 modules and full-specification 5G modules.
| Dimension | DSRC (IEEE 802.11p) | C-V2X (LTE-V2X / NR-V2X) |
|---|---|---|
| Physical layer | OFDM, Wi-Fi-based CSMA/CA | OFDM, supports centralized and distributed scheduling |
| Standards body | IEEE (802.11p / 1609.x) | 3GPP |
| Communication modes | V2V / V2I (mostly broadcast) | V2V / V2I / V2N / V2P (unicast/multicast/broadcast) |
| Typical range | Hundreds of meters, covering one intersection | Comparable to DSRC, farther in open scenarios |
| End-to-end latency | Typically tens of milliseconds, meeting the <100 ms budget for BSM collision warnings | LTE-V2X PC5 direct link typically 20–50 ms (engineering order of magnitude); NR-V2X targets lower |
| Data rate | Medium rates, carrying safety messages | LTE releases higher; NR releases reach the 100 Mbps class |
| Resource allocation | Contention-based (CSMA/CA) | Centralized (Mode 3) + distributed (Mode 4) |
| Infrastructure dependence | V2V communicates directly; V2I and wide-area coverage require RSUs and other infrastructure | PC5 sidelink supports direct communication without a base station; V2N still depends on the cellular network |
| Evolution | Mature installed ecosystem; new deployments are constrained by regional spectrum policy and the in-vehicle ecosystem | LTE-V2X and NR-V2X continue to evolve, but generations are not inherently interoperable |
| Industry ecosystem | Mainly early EU/US projects | The direction China explicitly promotes, with stronger cross-industry consensus |
Table 11-1: DSRC vs. C-V2X comparison
Note: the latencies in the table are typical engineering order-of-magnitude figures — the end-to-end latency budget for collision-warning services (such as BSM messages) is customarily counted as 100 ms; LTE-V2X PC5 direct links typically run at 20–50 ms, and NR-V2X is designed to go lower.
Communication Modes and Typical Scenarios
V2X communication modes fall into four categories by counterpart:
- V2V (vehicle-to-vehicle): exchanging highly time-critical safety messages such as collision warnings, hard-braking alerts from the car ahead, and blind-spot warnings. Two vehicles must establish communication and negotiate collision avoidance within one hundred milliseconds.
- V2I (vehicle-to-infrastructure): vehicles receive signal states, speed-limit advisories, and variable message sign content. The RSU periodically broadcasts signal phase and timing (SPAT, Signal Phase and Timing) messages; vehicles decode them and estimate the remaining green time.
- V2N (vehicle-to-network): services with looser latency needs — traffic-condition updates, weather forecasts, high-definition map download — usually carried over the 4G/5G Uu interface rather than PC5 directly.
- V2P (vehicle-to-pedestrian): phones or dedicated terminals broadcast position and motion state to protect non-motorized traffic and pedestrians — a challenge for communication capacity, because pedestrian density far exceeds vehicle density.
A sample scenario: a car approaches an intersection. In a DSRC network, an RSU can broadcast SPAT messages periodically; in a C-V2X network, an RSU can likewise broadcast roadside information over PC5. On a suburban road without RSUs, both approaches can support direct vehicle-to-vehicle safety messages: DSRC uses 802.11p contention-based access, while LTE-V2X Mode 4 has vehicles select sidelink resources autonomously. Differences must be assessed against the target density, channel load, device interoperability, and field tests; they cannot be attributed to an assumption that DSRC requires RSU relays.
An Engineering Decision Path for Selection
Selection is not a binary either-or. Real projects must evaluate the following dimensions:
- Spectrum availability: the 5.9 GHz band is allocated differently across countries. If the band has already been assigned to C-V2X locally, deploying DSRC runs into interference or compliance obstacles. Band compatibility is precisely the first-order problem of the transition period: when the legacy and new radio technologies coexist in the same band, spectrum clearing — relinquishing the overlapping assignments — and channel planning must demarcate each side's guard bands, or co-channel interference will degrade the reliability of both systems at once.
- Infrastructure dependence: RSU density mainly affects V2I service coverage; both approaches provide a direct V2V mode that does not depend on an RSU. Selection should separately verify V2V reliability without infrastructure and the roadside services, operations, and certificate system after RSUs are deployed.
- Service evolution expectations: if platooning or remote teleoperation support for advanced autonomous driving is needed within three years, NR-V2X's low latency and higher reliability earn their keep; for basic collision warnings and information services alone, LTE-V2X is fully sufficient.
- Factory fit vs. aftermarket: automakers fitting V2X on the assembly line will choose C-V2X modules; the aftermarket sometimes sticks with DSRC components for cost reasons. Engineering must unify the protocol stack to avoid mixed installations breaking interoperability. One workable approach is a multimode module supporting both DSRC and C-V2X, achieving full compatibility through the transition period.
The comparison table and the decision-path diagram are tools; the real leverage in selection lies in matching business goals against resource realities. Over the past decade the V2X market has seen a tug of war between two philosophies: Europe and the United States once leaned toward DSRC, while China and some Asian markets pivoted quickly to C-V2X from 2018 onward. As NR-V2X draws R&D investment from the world's major communication equipment vendors and automakers, C-V2X has become the de facto mainstream direction. DSRC, however, will persist for years in the installed base of driver-assistance schemes at L2 and below. Engineering teams should understand the differences between the two not only to make the selection, but to face a long road of "old and new systems coexisting in transition." When selecting, beyond technical parameters, you must also assess transition strategy, compliance risk, and ecosystem life cycle, so that the investment does not rapidly depreciate within five years.
11.1.3 A Deployment Example: Roadside Units (RSUs) and On-Board Units (OBUs)
Once the communication technology selection is settled, the next step is running the protocol stack on real hardware. This section uses one example to walk through the hardware composition and installation of RSUs and OBUs, and the interworking workflow that ties them to intersection signals and roadside radar. To avoid confusion with any real city project, the scheme described here does not refer to a specific engineering engagement — but its selection logic and networking approach are typical of the industry.
Case: the demonstration corridor runs about 15 kilometers, six lanes in both directions, covering on- and off-ramps, interchanges, and tunnel portals. The plan allocates 24 RSU deployment sites, each backhauled over fiber. About 200 OBUs are deployed for testing, installed on the buses and taxis operating within the demonstration zone.
RSU Hardware Configuration and Installation
A typical RSU consists of five core modules, each with a clear functional boundary:
- C-V2X communication module: operates in the ITS-dedicated band at 5905–5925 MHz, completing direct vehicle-roadside links over the PC5 interface; production chips and modules are based on Rel-14 LTE-V2X (NR-V2X sidelink is not yet in large-scale commercial use). Transmit power is adjustable; under the default configuration the coverage radius spans roughly 500 to 800 meters.
- GNSS receiver module: supports multiple bands (L1/L5) and accepts RTK differential corrections, with positioning accuracy better than 20 centimeters under ideal conditions.
- Main processing unit: runs the V2X protocol stack and upper-layer application logic. Common industry choices include the ARM Cortex-A72 or an x86 edge-computing module of comparable performance.
- Backhaul communication interface: the primary path is gigabit fiber Ethernet; a 4G/5G cellular module is retained as link backup, mainly for remote operations and data re-transmission.
- Antenna and power system: the V2X antenna is a dual-polarized directional antenna with a horizontal beam width of about 120 degrees. POE or local power supply is supported.
During installation, the RSU is clamped to an L-shaped roadside pole or a gantry beam, 6 to 8 meters above the ground. The antenna faces oncoming traffic with a 5-to-10-degree downtilt, to secure line-of-sight communication quality and reduce multipath interference.
OBU Integration and Functional Modules
OBU hardware is far more compact than an RSU and must work reliably amid vibration, wide temperature ranges, and tight installation space. It comprises the following key submodules:
- C-V2X communication module: provides the PC5 interface, supports a low-power receive mode, and keeps standby current at a low level.
- Automotive-grade GNSS receiver: shares its antenna with the vehicle's original navigation system, requiring no extra opening.
- Microcontroller unit (MCU): handles event-triggered message processing and local decision logic.
- In-vehicle Ethernet and CAN bus interfaces: the OBU reads driving data such as speed, steering angle, and braking status over the CAN 2.0B bus, and connects to the in-vehicle infotainment system or the ADAS domain controller over Ethernet.
- Security chip: physically separate; stores digital certificates and performs message signing and verification.
The OBU draws power from the vehicle's always-on supply (12V or 24V) and is designed with two-stage power management, wake and standby — it wakes automatically when the engine starts or valid data appears on the CAN bus, and enters deep sleep after the engine shuts off.
The Interworking Workflow with Signals and Radar
Data exchange between the RSU and the intersection signal controller is the most fundamental and most valuable scenario class in intelligent transportation. The interworking workflow divides roughly into six steps:
- The signal controller outputs the current phase (red/yellow/green) and countdown seconds over an RS-232/485 serial port, on a fixed refresh cycle.
- The RSU polls the serial port at a fixed interval and parses the data into the agreed lamp-state codes.
- The RSU encodes the lamp state into standard SPAT messages, filled in the national-standard message-set format.
- The RSU broadcasts the SPAT message over the PC5 interface, with an RF coverage radius of about 500 meters.
- The on-board OBU receives and parses the SPAT message and, combining its own GNSS position with vehicle speed from the CAN bus, displays advisory information on the driver's HMI.
- If the vehicle has L3-or-above autonomous driving capability, the OBU can feed the phase and timing information from the SPAT message directly into the path-planning module, to decide whether to accelerate through or decelerate to a stop.
Beyond this, the RSU can also interwork with roadside millimeter-wave radar or radar-camera integrated units. When the radar detects an obstacle ahead or a vehicle stopped abnormally, it sends the target's position and speed to the RSU over Ethernet, and the RSU immediately generates an RSI (Roadside Information) message and broadcasts it to vehicles approaching from behind. From radar sensing to RSU broadcast, end-to-end latency is required to stay within the hundred-millisecond class.
The typical communication flow for the timing sequence above is summarized in Figure 11-2.
Table 11-2: RSU and OBU hardware configuration list
| Component | RSU | OBU |
|---|---|---|
| Main processor | ARM Cortex-A72 (4 cores, 1.8 GHz) or equivalent x86 processor | ARM Cortex-A53 (2 cores, 1.2 GHz) |
| V2X communication module | PC5 interface supported; nominal transmit power 23 dBm | Highly integrated PC5 module |
| GNSS positioning | Multi-frequency receiver with RTK differential support | Single-frequency automotive-grade receiver with SBAS augmentation |
| Backhaul interface | 1× gigabit fiber + 1× 4G/5G cellular module (optional) | None (PC5 communication only) |
| I/O interfaces | RS-232/485 (to signal controller) + 1× gigabit Ethernet (to radar) | CAN 2.0B + 1× gigabit Ethernet (to in-vehicle navigation) |
| Operating temperature | -40°C ~ +85°C | -40°C ~ +85°C |
| Ingress protection | IP65 | IP67 |
| Typical power draw | 15~25 W | 3~5 W (standby < 1 W) |
Note: the figures in the table above are typical values listed for this case; parameters may differ across vendors' equipment and deployment environments, and real projects should defer to the specific device manual.
Engineering Trade-offs in Deployment
From the example's selection we can distill three engineering judgments that run through any RSU/OBU deployment:
First, redundant backhaul design sets the ceiling of availability. Once the primary fiber link breaks, the cellular backup can keep remote management and critical alarms alive at lower bandwidth, but it cannot carry the full uplink data service. Deployment must assess the probability of fiber cuts and the maintenance response time to decide whether to retain local storage for store-and-forward retransmission during outages.
Second, OBU power management directly constrains real-world driving range. On new-energy buses, an OBU that stays awake for long periods drains the vehicle's 12V battery and undermines the vehicle's self-start after sleep. The two-stage power-management design must be jointly commissioned with the whole-vehicle power strategy to fix the wake thresholds and the bus signal characteristics.
Third, a larger RSU coverage radius is not automatically better. Raising transmit power does extend coverage, but it also introduces more severe co-channel interference and long-range multipath reflection. In actual deployments, neighboring RSUs usually keep a certain overlap for handover and redundant coverage, rather than chasing the maximum radiating distance of a single site.
These three judgments are not unique to this example — they recur in most city-scale connected-vehicle projects; only the specific parameter windows and operations strategies differ.
Further Reflections
Deploying RSUs and OBUs is, in essence, binding the roadside infrastructure's "fixed physical world" to the "dynamic information space" that moves with each vehicle. The tighter this binding, the more reliable the upper-layer applications — red-light violation warnings at signals, green-wave speed advisories, coordinated passage through unsignalized intersections. But the binding itself also means operational complexity: as RSU counts leap from dozens on a test corridor to thousands at city scale, operations processes such as device firmware OTA, certificate rotation, and remote fault diagnosis must shift from "manually driven" to "platform driven." The system design involved in that shift is taken up again in the engineering practice of Section 11.5.