RSU

Roadside unit

Definition

RSU (Road Side Unit), a roadside unit deployed at intersections and road segments, interacts with the cloud platform via 4G/5G modules, supporting V2X, ITS vehicle-road collaboration applications.

Functions and Architecture

The RSU is roadside infrastructure for vehicle-road coordination, integrating C-V2X (PC5 direct communication) and cellular communication (4G/5G Uu). C-V2X is used for low-latency direct connection with the onboard OBU, broadcasting traffic light status, traffic events, road conditions, etc.; the cellular module is used for communication with the cloud platform and the ITS center, receiving configuration instructions and reporting aggregated data. RSUs can also interface with signal controllers, vehicle detectors, cameras, and other roadside devices, aggregating multi-source data for unified broadcasting or uploading.

Communication modules required

RSUs are deployed on outdoor poles and require industrial-grade, wide-temperature, and lightning protection design. 4G/5G modules handle the backhaul link and need to support high bandwidth, low latency (5G preferred), and stable long connections. Some RSUs adopt dual-module redundancy to enhance reliability. The modules connect to the RSU main control via Ethernet or PCIe, supporting enterprise network requirements such as multiple APNs and VPNs.

Use Cases

V2X applications include intersection collision warning, blind spot alert, green wave speed guidance, and protection for vulnerable road users; ITS applications include traffic flow collection, event detection, and information dissemination. RSUs, OBUs, and cloud platforms form a "vehicle–road–cloud" collaborative architecture, with communication modules being the key components connecting the roadside to the cloud.

Engineering Practice Supplement

Cross-team collaboration for 'RSU': Hardware provides impedance and power budget, RF provides spurious signals and sensitivity margin, embedded tracks the thread model and storage lifespan, and cloud sets SLA and rate limits. For scenarios like NB-IoT, the business model needs to match wake-up cycles, packet length, and downlink capacity; for automotive and mobile scenarios, session retention during handover and roaming needs to be considered. At project closure, conduct a 'red team' style review: check if behaviors are defined for weak networks, power loss, expired certificates, clock jumps, and full storage.

The following are additional tips related to cellular IoT project delivery: it is recommended to keep screen recordings of typical scenarios, screenshots of key indicators, and summaries of masked packet captures during the acceptance phase; in the mass production phase, change records should be kept for software and hardware versions, calibration parameters, and key component batches to facilitate problem attribution, customer audits, and long-term maintenance. When payment or personal information is involved, also check whether log masking and key rotation strategies are executable.

Splitting Direct Broadcast from the Backhaul Tunnel

A roadside unit stands at an intersection or along a road. Toward vehicles it uses a direct air interface to broadcast signal-phase, events, and speed limits. A vehicle can receive them without going through the core network. Toward the center it uses cellular or a wire to send up what detectors and cameras have already aggregated, and to receive configuration. The two links do not share a delay budget. The direct broadcast has to keep up with the intersection cycle. Backhaul can be statistics and logs on the order of seconds. The cellular module belongs to the backhaul. It does not replace the direct radio. Treating backhaul delay as how quickly a vehicle can receive the signal state misreads a late configuration from the center as weak direct-link performance. Equipment on the pole also has to meet wide temperature, lightning protection, and continuous power. The communication figure is only one of those items.

The conditions of use are that the direct antenna and the backhaul antenna are assessed separately, that power and grounding come before service turn-up, and that the clock can follow the intersection controller. Configuration should travel through an authenticated tunnel. An engineering port must not be exposed on the public network. Dual modules, or wire plus cellular, are a backup only when the switchover rule is written down: when to switch, whether the broadcast continues during the switch, and whether the center will receive two copies of one event.

How a Failed Pole Clock Affects Event Broadcasts

Time sync is the item most often skipped. If a signal color or an event carries a wrong timestamp, the vehicle drops it or associates it incorrectly, while the backhaul log still shows a successful send. The second miss is to put the camera's raw stream and the broadcast configuration on one default bearer. When the link is busy the configuration cannot get out, and the direct radio keeps broadcasting an old phase. The third is lightning ground and cabinet ground left unseparated. After a storm the module port is damaged, and the monitor only shows offline. On a single link, a cellular outage must not stop the local direct broadcast. Otherwise the intersection loses roadside information until backhaul returns.

The service types of direct messages are in V2X. If configuration on the backhaul must take priority over video upload, the network has to schedule by flow for real; see QoS and service flows. Marking priority only in the application is not enough.

Commissioning checks should split two indications: whether the direct broadcast is still going out, and whether backhaul is connected to the center. When backhaul drops, the intersection should not go blind if the local side can still broadcast the last valid phase. If a backhaul loss also stops the direct radio, a cellular fault grows into a loss of vehicle-road information. Loss of time sync needs its own alarm, because the send counter is still increasing and send-success alone lets a bad timestamp through. It should be possible to see whether configuration or video is occupying the backhaul. When configuration cannot get out, limit the video first. Do not raise module retries until the air interface is full. Lightning and power faults should be reported as device events, not disguised as registration failure. During a dual-path switch, the center must be able to recognize a duplicate event rather than treat it as two incidents. Keep these states locally on the pole and send them up together when backhaul returns, so the center does not compute statistics from an old phase during the gap. When the direct broadcast is still running and backhaul is already down, the center display should show the age of the data, not the signal color of the last frame as if it were the current phase. Once that age exceeds the intersection cycle, the center should stop using the frame to compute green ratios.

Related Terms

Return communication modules terminology