Definition
OBU (On-Board Unit) is a V2X communication terminal installed on a vehicle. The OBU is responsible for receiving, sending, and processing V2X messages, including BSM (Basic Safety Message), SPAT (Signal Phase), MAP (Map Data), etc. It can communicate directly with RSU (Roadside Unit) and other vehicle OBUs via PC5, or interact with the cloud and other vehicles through the cellular Uu network.
The OBU typically integrates C-V2X communication modules (LTE-V2X/5G NR-V2X), GNSS positioning (supporting RTK), cellular communication (4G/5G), and other capabilities. IoT SIM cards provide cellular connectivity for the OBU, supporting remote configuration, OTA upgrades, data reporting, high-precision map delivery, cloud collaboration, and more.
Technical Features
The OBU supports direct connection on the 5.9GHz band (PC5) and cellular Uu mode. Integrated with T-Box, ADAS, and high-precision maps, it can support applications like traffic light information push, blind spot warning, and green wave driving. The OBU must meet automotive-grade requirements and adapt to in-vehicle environments (temperature, vibration, electromagnetic compatibility).
Use Cases
OBU Applied to intelligent connected vehicles, smart transportation, smart highways, autonomous driving testing, and Robotaxi. Passenger cars, commercial vehicles, and special vehicles can all be equipped with OBU to achieve V2X functions. SimtoLink provides IoT SIM cards, dedicated APN, data plans, and connected vehicle solutions for OBU units.
Where safety messages stop and the cellular path starts
The IoT SIM in an OBU does not carry the direct safety link between vehicles. Basic safety messages, signal-phase data, and map fragments that travel vehicle-to-vehicle or vehicle-to-road have a millisecond delay budget. That path is not cellular attach, and it does not detour through the core network. The SIM carries a different set of jobs: remote configuration, certificate or profile updates, high-definition map increments, cloud coordination, and operating logs that do not need direct-link delay. The vehicle already has positioning and a direct radio. Cellular is the management plane and a long-range supplement. If the direct radio is off, or there is no roadside peer, the SIM can still be online. Blind-spot warning and signal-light push do not automatically move onto cellular because of that.
Writing SIM online status into the ready condition for a safety function is the easiest design mistake. Ready should follow the direct radio, positioning quality, and time sync, not cellular registration. A failed map or configuration download only means the management plane is down. It should not remove the vehicle from a direct-link application, unless that application explicitly depends on a new map from the cloud. Before a cross-city trip, confirm the SIM's region and roaming policy. Otherwise the vehicle has already entered new roadside coverage while configuration and logs stop at the province boundary. This has nothing to do with on-board diagnostics read from the diagnostic port. Do not share one "online means usable" test between them.
A region policy cuts off cross-city coordination
Another failure is that positioning and SIM policy cannot see each other. High-accuracy positioning is locked, yet the platform still receives no track. Often the SIM is limited to base stations along the test road, or the APN may reach only the test server. Direct messages do not pass through this SIM, so the roadside unit can hear the vehicle while the cloud timeline is broken. Afterwards the direct-link event cannot be aligned with the cloud record. If time sync trusts only cellular network time, the local clock drifts in a tunnel or a roadside shadow, and timestamps in safety messages no longer match the roadside unit.
Upgrades need separate windows. The direct-link stack and the cellular module firmware should not be tied to the same casual reboot. Rebooting the module while driving can drop the management plane, which is acceptable. Rebooting the whole unit drops the current direct session. Acceptance needs at least three stretches of road: a direct exchange inside roadside coverage, cellular only when there is no roadside unit, and whether logs continue after the vehicle crosses the SIM policy boundary. When the three results disagree, change the region and the destination address first. Do not raise the send rate of safety messages.
A broken management plane is not a failed direct link
While driving, cellular can be taken down on purpose while the roadside direct link stays up. If safety messages still exchange, the management plane and the direct plane are separate. If the direct link stops as well, the software has bound the two into one reboot or one ready condition, and that binding has to be undone. Missing cloud logs for that interval is the expected result. After recovery, backfill the management-plane record. Do not replay or resend the safety messages from that time. Their lifetime has passed, and a late copy makes the roadside unit handle them twice.
When the vehicle leaves the SIM's allowed region, configuration and maps may stop updating. The direct application should continue on the map it already has, until the application itself rejects an expired map version. The rejection reason must say the map expired, not that cellular is offline. If a certificate or configuration update fails, keep the last usable configuration so the vehicle does not lose its direct-link identity halfway through an update. Once those three are recorded separately, troubleshooting will not use SIM attach state to explain a vehicle-to-road message.