Chapter 8
A V2X implementation is judged by one thing: when two vehicles, or a vehicle and a signal controller, exchange a message, the receiver must be able to trust it, decode it and act on it before the situation changes. The WIA-COMM-003 data formats (BSM, CAM, DENM, SPaT, MAP), its four interaction modes (V2V, V2I, V2P, V2N) and its security regime all serve that goal. This chapter turns them into build and acceptance work. It covers which artifacts each product role must deliver, which behaviors can be checked with arithmetic or a fixed message exchange, and where the standard leaves the implementer a decision that must be documented.
The standard describes a layered stack: application, facilities, security, network and transport, access (DSRC based on IEEE 802.11p, or C-V2X) and physical (5.9 GHz radio). The facilities layer generates and parses messages. The security layer wraps every outgoing message in a signed envelope and verifies every incoming one. Both sit above the access layer, so a safety application never touches the radio. An implementer should also keep them separate in code, because the access layer is the part most likely to be swapped between DSRC and C-V2X deployments.
| Role | What it must produce or consume | Main sections in the standard |
|---|---|---|
| On-Board Unit (OBU) | Periodic BSM/CAM broadcast; event-triggered warnings; FCW, IMA and blind spot logic; signing and verification | V2V model, collision avoidance protocols, security |
| Road Side Unit (RSU) | SPaT and MAP broadcast; DENM for work zones; answers to signal requests; relay of V2V messages for range extension | V2I model |
| Certificate back office | Root CA, Enrollment CA and Authorization CA; pseudonym certificate issuance; revocation lists | PKI and privacy |
The V2V model is connectionless: no handshake, no acknowledgment, and every nearby vehicle receives each broadcast. An implementation therefore cannot count on delivery confirmation. Everything the receiver needs to judge a message, including time, position and sender credentials, has to travel inside the message.
The technical core is a short chain: a sender emits state at a rate that depends on how dangerous its situation is, and a receiver converts that state into a time-to-collision and a threat level. Each link can be tested numerically. Most conformance disputes in this area come from small differences in how the links are written.
Position sharing is rate-adaptive. The standard ties the broadcast rate to speed so that bandwidth goes where risk is highest:
| Condition | Update frequency |
|---|---|
| Stationary | 1 Hz |
| Low speed (below 50 km/h) | 2 Hz |
| Medium speed (50–100 km/h) | 5 Hz |
| High speed (above 100 km/h) | 10 Hz |
| Emergency | 20 Hz |
The nominal periodic rate for BSM/CAM transmission is 10 Hz, and the table refines it by speed class. A transmit scheduler can be tested by driving a simulated speed profile and checking that the emitted interval changes when the speed crosses a class boundary.
On the receiving side the standard defines time-to-collision as TTC = (d - L₁ - L₂) / (v₁ - v₂), where d is the distance between vehicles, L₁ and L₂ are the vehicle lengths, and v₁ and v₂ are the speeds. The V2V section maps TTC to four levels: below 1.5 s is CRITICAL (immediate brake), below 2.5 s is HIGH (warning and prepare brake), below 4.0 s is MEDIUM (visual or audio warning), and anything else is LOW (monitoring). The reference forward-collision routine adds two gates before it computes anything. It returns no warning if the heading difference exceeds 45 degrees, and none if the relative speed is zero or negative, meaning the target is pulling away or holding pace.
def forward_collision_warning(ego_vehicle, target_vehicle):
distance = calculate_distance(ego_vehicle.position, target_vehicle.position)
heading_diff = abs(ego_vehicle.heading - target_vehicle.heading)
if heading_diff > 45:
return None # not in collision path
relative_speed = ego_vehicle.speed - target_vehicle.speed
if relative_speed <= 0:
return None # moving away or same speed
ttc = (distance - ego_vehicle.length) / relative_speed
if ttc < 1.5:
return {'level': 'CRITICAL', 'action': 'BRAKE', 'ttc': ttc}
...The protocol-phase FCW class is a second formulation of the same idea. It uses two thresholds (a 2.5 s warning and a 1.5 s critical value, plus a 5.0 m minimum distance) and returns the labels CRITICAL and WARNING. It computes TTC as distance / rel_velocity without subtracting vehicle length, and it also returns a required deceleration from v² / (2d). The two listings differ in label vocabulary and in whether length is deducted. An implementer must therefore choose one formulation, document it, and make sure the human-machine interface and any logged events use consistent names. A test lab will otherwise find the divergence for you.
A worked check shows how the numbers behave. Take an ego vehicle at 25 m/s following a target at 15 m/s, so the closing speed is 10 m/s. At 30 m of separation the simple TTC is 3.0 s. That is MEDIUM in the four-level scheme, and the protocol-phase class stays silent because 3.0 s is above its 2.5 s warning threshold. At 12 m the TTC is 1.2 s, which is CRITICAL in both, and the required deceleration is 100 / 24, about 4.2 m/s². These two cases make good regression vectors: one just above a threshold, one clearly inside it, and a third with relative speed of zero that must return nothing.
The material does not supply market-size data, so this section deals only with the decisions the standard itself forces on the parties involved. Vehicle makers and infrastructure operators depend on each other. A vehicle-side warning that relies on SPaT is useless where no RSU broadcasts it, and an RSU is wasted if few vehicles can verify its signed messages. The standard acknowledges this by ranking deployment sites rather than prescribing blanket coverage.
The ordering follows where V2I applications such as signal timing, preemption and work zone warnings pay off first. A second commercial decision is the access technology. The stack allows DSRC or C-V2X (LTE-V2X and 5G NR-V2X) under the same facilities and security layers. A supplier that keeps message generation and signing independent of the radio can serve either market with one application codebase.
The infrastructure side of the standard maps directly onto operational practice at signalized intersections and roadworks. These applications also carry the most concrete message examples, so they are where an integration test between a vehicle vendor and an RSU vendor is easiest to write.
The RSU broadcasts SPaT (signal phase and timing) and MAP (intersection geometry). The vehicle selects the signal group matching its lane and derives the time remaining. The reference TypeScript computes it as (minEndTime - currentTime) / 1000 and returns the current state (red, yellow or green), the next phase and its time. Because the subtraction mixes message times with the receiver's clock, a vehicle with a drifting clock produces wrong countdowns. Time sources are therefore part of the implementation, not an afterthought.
Green Light Optimal Speed Advisory (GLOSA) builds on that countdown with two rules. If the signal is red and the vehicle would reach the intersection before the red ends, the driver is advised to slow to a computed speed to catch the green. If the signal is green and the vehicle would arrive after the green ends, the driver is told to speed up or prepare to stop. Tests should cover both branches and the boundary where arrival time equals time remaining.
Emergency vehicle preemption is a request and response exchange. The vehicle sends a Signal Request Message (SRM) naming its approach and departure, an estimated arrival and the green time it wants. The controller answers with a Signal Status Message (SSM):
{
"messageType": "SRM",
"requestID": 12345,
"vehicleID": "FIRE-001",
"vehicleType": "fire",
"priority": "emergency",
"route": { "approach": "north", "departure": "south" },
"eta": 15,
"duration": 120
}
{
"messageType": "SSM",
"requestID": 12345,
"status": "granted",
"preemptionTime": 1640000015000,
"duration": 120
}The shared requestID ties the answer to the request, which matters because broadcast radio gives no delivery guarantee. A requester should treat a missing SSM as "not granted" and keep driving as a normal vehicle. The listing shows only granted as a status value, and an implementation should not invent other values without checking the full specification. Work zones use the DENM format with an eventType of roadWorks and a location. This lets an RSU or a temporary roadside unit warn approaching vehicles before the driver can see the cones.
Intersection Movement Assist applies the same reasoning to vehicle-to-vehicle conflicts. Within a 50 m radius of an intersection, the routine predicts each vehicle's path through the MAP geometry and finds the conflict point. It compares the two arrival times and raises a warning if they differ by less than 3.0 s. Threats are sorted by time difference so that the most urgent comes first, and the suggested action is to slow down only when the ego vehicle must yield. MAP data quality therefore directly limits IMA accuracy.
The security regime is where compliance is easiest to demonstrate in concrete terms. The standard builds on established base specifications: SAE J2735 for the BSM, ETSI for the CAM, and IEEE 1609.2 for the certificate format, with ECDSA over P-256 as the signature algorithm. The release-signing and conformance-level machinery that this standard shares with the rest of the WIA series is described elsewhere and is not repeated here. What follows is the V2X-specific acceptance logic.
The certificate hierarchy runs from a Root CA to an Enrollment CA (long-term vehicle certificates) and an Authorization CA (short-term pseudonym certificates). A pseudonym certificate carries a validity period, a circular geographic region, an assurance level and application permissions. Its psid value 0x20 identifies the Basic Safety Message. A signed message wraps the payload with header information, signer information (a certificate or a digest), generation time, generation location and the signature.
The reference verification routine is an ordered checklist, and each failure has its own reason. That makes it a ready-made negative test suite:
| Step | Check | Rejection reason |
|---|---|---|
| 1–2 | Extract the certificate and verify its validity | Invalid certificate |
| 3 | Check the certificate against revocation | Certificate revoked |
| 4 | Verify the ECDSA signature over the payload | Signature verification failed |
| 5 | Compare generation time with the current time (5000 ms window) | Message too old |
| 6 | Confirm the claimed location lies inside the certificate region | Location outside certificate region |
if abs(current_time() - timestamp) > 5000: # 5 seconds
return False, "Message too old"
...
if not is_in_region(claimed_location, cert_region):
return False, "Location outside certificate region"A thorough acceptance plan feeds the receiver one message per failure mode: an expired certificate, a revoked one, a tampered payload, a replayed message and a message signed by a certificate whose region excludes the claimed position. It also includes one fully valid message that must pass. The order of checks matters for performance. Cheap checks such as freshness could in principle run before signature verification, but the standard lists the order above, so an implementation that reorders should show it produces the same accept/reject results.
Privacy is part of conformance because the same fields that make a message trustworthy make a vehicle trackable. Pseudonym certificates change every 5–10 minutes, must not be linkable to one another, and a vehicle carries a pool of 20 or more. The standard defines privacy levels that reduce position precision before broadcast:
| Level | Behavior |
|---|---|
| MAXIMUM | Position is not broadcast |
| HIGH | Latitude and longitude rounded to 3 decimals (about 100 m) |
| MEDIUM | Rounded to 4 decimals (about 10 m) |
| LOW or NONE | Full precision (about 1 cm) |
Privacy zones add further rules: no broadcast within 500 m of a registered home location (or maximum privacy mode), and automatic protection of sensitive places such as hospitals, government buildings and religious sites. Finally, misbehavior detection checks position consistency. A reported position that implies travel beyond the last speed multiplied by elapsed time and a factor of 1.5 is flagged as an anomaly.
Several of these requirements pull against each other, and the standard does not resolve every tension. The implementer should record the decision in the design file so that a reviewer can see it.
The standard already names 5G NR-V2X alongside LTE-V2X, so the radio side is expected to move while the message formats and the signed envelope stay put. Platooning, in which a leader and followers operate as a coordinated unit, depends on the same trust machinery as the safety warnings, because a follower acting on a forged leader message is far more dangerous than one ignoring a missed beacon. Implementations built with a clean separation between access layer, facilities and security will absorb those changes with the least rework.
Implementation under this standard rests on three habits. First, split the work by role: the OBU, the RSU and the certificate back office each have a different set of artifacts, and the signing layer sits between message generation and the radio. Second, turn the standard's arithmetic into test vectors: the speed-dependent broadcast rates, the TTC thresholds, the 45-degree heading gate, the 3.0 s IMA window, the SRM/SSM exchange and the six-step verification with its named rejection reasons. Third, document every place where the text offers two formulations or a trade-off, such as TTC with or without vehicle length, WARNING versus HIGH labels, and privacy versus safety defaults.
What remains after a single node passes these checks is the behavior of many nodes at once, where one vehicle's warning becomes another vehicle's input and the choices above are tested against each other on the road. The coordination protocols that follow, collision avoidance across neighboring vehicles and leader–follower platooning, depend on every node having made those choices consistently.