Posted iniot

Connected Vehicle V2X: Reference Architecture (2026)

No Comments
Connected Vehicle V2X: Reference Architecture (2026)

Connected Vehicle V2X: Reference Architecture (2026)

Last Updated: 2026-05-18

For most of the last decade, a connected vehicle V2X architecture meant arguing about which radio to bet on. DSRC and IEEE 802.11p had a head start, working pilots, and an installed base in Japan and parts of Europe; C-V2X had 3GPP momentum, a clear 5G roadmap, and Qualcomm’s chipset volume. The fight ended in slow motion. The FCC’s November 2020 order (FCC-20-164) reallocated the lower 45 MHz of the 5.9 GHz band away from DSRC and gave the upper 30 MHz to C-V2X, and the May 2024 waivers cleared the path for production C-V2X deployments. Europe kept ITS-G5 alive at ETSI but the centre of gravity shifted, and by 2026 essentially every new OEM program, RSU vendor, and SCMS provider is shipping C-V2X first. That clears the air to talk about the actual hard problem — what a real connected vehicle V2X architecture looks like end to end, and how its pieces fit together under production constraints. This post is the reference architecture: vehicle node, RSU, MEC edge, cloud control plane, the C-V2X air interface, the SCMS PKI, and the telemetry pipeline that feeds the fleet twin. By the end you should be able to draw it, defend the trade-offs, and pick a phased rollout that actually ships.

What Connected Vehicle V2X Means in 2026

A connected vehicle V2X architecture is the layered set of radios, software, security infrastructure, and backend pipelines that lets a vehicle exchange safety-relevant messages with other vehicles (V2V), roadside infrastructure (V2I), vulnerable road users (V2P), and the network/cloud (V2N) — all under sub-100-millisecond latency budgets and a hard cryptographic trust model. The 2026 reference is C-V2X over 5.9 GHz, anchored on 3GPP Releases 14 and 16, with day-1 safety messages defined by SAE J2735 (Basic Safety Message, MAP, SPaT, RTCM corrections) in North America and ETSI EN 302 637 CAM/DENM in Europe, signed by certificates issued under IEEE 1609.2 and the CAMP-derived SCMS PKI.

The stack runs on two radio interfaces: PC5 sidelink for direct V2V and V2I at the corner, and Uu uplink for V2N traffic that goes back to the cellular network. PC5 is the safety-critical path — it works without network coverage, gives deterministic 10 Hz BSM broadcasts, and supports the 100 ms target latency for collision-avoidance. Uu is the throughput path — it carries OTA updates, telemetry, HD-map tiles, and traffic-management commands.

Three things distinguish a connected vehicle V2X architecture from a generic IoT telemetry stack:

  1. The radio is the architecture. Unlike enterprise IoT where you can swap LoRa for NB-IoT without rewriting the stack, V2X applications are written against PC5 sidelink semantics — broadcast, congestion-controlled, latency-bounded, and resource-pool managed. Switching to a different radio means re-writing day-1 applications.
  2. Identity is pseudonymous and rotating. A connected vehicle does not have one identity. It has a pool of short-lived pseudonym certificates that rotate every few minutes to defeat tracking, while still being revocable through a misbehavior authority. That changes how you log, debug, and analyze fleet data.
  3. Latency floor is set by physics, not budget. A 30 m/s vehicle covers nearly a metre in 33 ms. End-to-end message latency for forward-collision warning has to be under ~100 ms or the warning is too late. That number constrains the entire backhaul, MEC placement, and application design — and is why edge computing is not optional for serious V2X.

Once you accept those three constraints, the rest of the architecture follows. The remainder of this post is about how the layers lay out.

Reference Architecture

The 2026 reference for a connected vehicle V2X architecture is a four-tier stack: vehicle node, roadside infrastructure, MEC edge, and cloud control plane, glued together by C-V2X PC5 at the air, cellular Uu for backhaul, and IEEE 1609.2 signed messages for trust. Each tier has a tight contract with the next, and the whole pipeline is sized to deliver the day-1 safety applications inside their latency budgets.

Figure 1: End-to-end V2X reference architecture — vehicle, roadside, MEC, and cloud with C-V2X PC5 and Uu interfaces.

The data flow on the safety path is short: a sensor or vehicle-bus signal becomes a Basic Safety Message inside the ITS stack, the message is signed by the on-board HSM with the current pseudonym certificate, the C-V2X modem broadcasts it on PC5 every 100 ms, and any vehicle or RSU within radio range that needs it consumes it. The data flow on the management path is longer: telemetry from the same vehicle goes up on Uu to a MEC node for local fusion and on to the cloud for the fleet twin, fleet analytics, and OTA. The certificate plane is orthogonal — the SCMS Manager talks to the vehicle through both planes to enroll, refresh pseudonyms, and distribute revocation.

Vehicle Node — OBU, HSM, ITS Stack

The vehicle node is built around an On-Board Unit (OBU), which can be a discrete telematics box or — increasingly — a function on the vehicle’s central compute platform. Inside the OBU you have four things: the C-V2X modem (typically Qualcomm 9150C-V2X, Autotalks CRATON2, or Marvell’s V2X-ready cellular platforms), the ITS protocol stack (SAE J2735 in NA, ETSI ITS-G5 in EU), a Hardware Security Module that holds the enrollment certificate and the active pseudonym certificate pool, and the V2X applications themselves (BSM transmitter, CAM/DENM handler, SPaT/MAP consumer).

The OBU sits on the in-vehicle network — CAN-FD, FlexRay, or automotive Ethernet — and pulls speed, heading, brake state, yaw rate, and a few other signals out of the vehicle bus. It tags them with a GNSS+IMU position, packs them into a J2735 BSM or ETSI CAM at 10 Hz, signs them with the active pseudonym certificate, and pushes them to the modem for PC5 broadcast. The modem does its own physics — congestion control, distributed scheduling on Mode 4 or Mode 2 (NR sidelink), and power management — without the application stack having to care.

RSU and Signal Controller

Roadside Units sit at intersections, on overhead gantries, and at work zones. They have the same C-V2X modem as the vehicle, a wired or wireless backhaul, and a controller-side connection to the traffic signal cabinet over NTCIP 1202 or a vendor-specific protocol. Their job is to broadcast SPaT (signal phase and timing) and MAP (intersection geometry) messages outbound, ingest BSMs and DENMs inbound, and forward whatever the MEC needs through the backhaul. Modern RSUs from Cohda, Kapsch, Yunex, and Commsignia all run a Linux-based ITS stack and a 1609.x WAVE service stack, and most ship with TLS-terminated management out of the box.

MEC Edge and Cloud Control Plane

MEC nodes — co-located at the cellular operator’s edge or in a 5G campus deployment — run application servers defined under ETSI MEC and 3GPP TS 23.501. Local breakout from the UPF lets traffic from a vehicle’s Uu link reach the MEC application in single-digit milliseconds, which is where the latency-sensitive V2N services (cooperative perception fusion, intersection movement assist, hazard relays) actually live. The MEC also caches HD-map tiles and pre-computed signal plans for the local geography.

The cloud control plane is where fleet-scale concerns live: the telematics service provider (TSP), the fleet digital twin, the analytics and ML training stack, the SCMS Manager itself, and the OTA orchestration. Nothing on the safety path goes here, but everything that matters for medium- and long-term operation does. We cover the data side of this in the unified namespace architecture HiveMQ Sparkplug B 2026 post, since the same Sparkplug B and topic-hierarchy ideas apply to a connected fleet.

The narrow contract between layers is what keeps a million-vehicle deployment debuggable. PC5 carries signed J2735/ETSI payloads only. Uu carries everything else. SCMS owns the certificate lifecycle. MEC owns local fusion. Cloud owns long-term state. Cross those boundaries and the system stops being analyzable.

C-V2X Air Interface and Cellular Integration

The single most important architectural fact about C-V2X is that it has two complementary radio interfaces and you almost always use both. Mixing them up — or trying to do V2V over Uu, or telemetry over PC5 — is one of the most common rookie mistakes in a connected vehicle V2X architecture review.

Figure 2: C-V2X PC5 sidelink and Uu uplink interfaces with 5G NR core and MEC local breakout.

PC5 sidelink is direct vehicle-to-vehicle or vehicle-to-roadside on the 5.9 GHz ITS band (5905-5925 MHz in the US after FCC-20-164, similar allocations elsewhere). It works without any cellular network coverage — the modems schedule resources autonomously using Mode 4 (3GPP Release 14, LTE-PC5) or Mode 2 (Release 16, NR-PC5). Modulation is SC-FDMA on Rel-14 and OFDM on Rel-16, the resource pool is structured in subframes and subchannels, and congestion control is handled by the Distributed Congestion Control (DCC) layer or NR equivalent. Range is typically 300-1000 m line-of-sight, less in dense urban canyons. Latency is consistently under 20 ms end-to-end when congestion is not pathological.

Uu uplink is the standard cellular interface — LTE-V2X for legacy networks, 5G NR-V2X for new deployments. The vehicle’s modem registers with the gNodeB (or eNodeB), traffic goes through the 5G Core’s UPF, and a Network Exposure Function (NEF) allows operator-side MEC applications to subscribe to subscriber-aware events. Local breakout — where the UPF routes a subset of traffic out to a MEC host instead of back through the operator core — is what gets V2N latency under 50 ms. Without local breakout you are at 100-200 ms round-trip to a public cloud region, which is too slow for most cooperative-perception applications.

The third piece is the 5G Core itself. The 5GC’s service-based architecture lets V2X applications register for specific QoS Flow Identifiers (QFIs) with guaranteed bit rate, low latency, and ultra-reliability profiles. Network slicing — under 3GPP TS 23.501 — gives you a dedicated V2X slice with reserved resources, isolated from consumer mobile traffic that might otherwise starve the safety messages during a stadium event. 5GAA’s papers on URLLC for V2X (5gaa.org) are the canonical references for how operators size these slices.

A few honest things to call out:

The DSRC vs C-V2X 2026 debate is settled in regulation but not in installed base. Some jurisdictions still have working DSRC deployments — Japan’s ETC2.0 and parts of the EU under ETSI ITS-G5 — and migration plans run multiple years. Hybrid OBUs that speak both radios exist (Cohda MK6, Commsignia ITS-CC) and are a real bridge for fleets that operate cross-border. The 5GAA’s position papers and ETSI’s TR 103 723 cover the coexistence and migration scenarios in detail.

Throughput is not the metric to optimize. A BSM is roughly 300-400 bytes signed. At 10 Hz that is ~30 kbps per vehicle. The pain point is not bandwidth, it is collision and congestion when a hundred vehicles within range all broadcast at the same time. DCC and the NR-PC5 congestion-aware scheduling matter much more than peak data rate.

NR sidelink (Release 16 and onward) brings the features that make cooperative driving real: groupcast, unicast, HARQ, and CSI feedback. They are necessary for Day-3 platooning and cooperative maneuvers; they are over-engineering for Day-1 awareness. Most production deployments in 2026 ship LTE-PC5 baseline with NR-PC5 as an upgrade path, since the chipset volume is on LTE and the safety apps work fine over it.

Security PKI: SCMS and CAMP

The hardest thing about a connected vehicle V2X architecture is not the radios — it is the trust model. Every BSM, CAM, DENM, SPaT, and MAP message has to be signed by a certificate the receiver can validate in single-digit milliseconds, without phoning home, while preserving the driver’s location privacy, while still being revocable if the vehicle is compromised. That set of requirements is what produced the Security Credential Management System (SCMS), originally specified by the CAMP consortium under USDOT funding and now standardized in IEEE 1609.2.1.

Figure 3: SCMS certificate flow — enrollment, pseudonym issuance, misbehavior reporting, CRL distribution.

The SCMS is a multi-CA hierarchy with explicit privacy roles. The interesting authorities are:

  • Enrollment CA issues a long-lived enrollment certificate to each device, bound to a unique device identity proved by an HSM-resident key pair.
  • Pseudonym CA issues short-lived pseudonym certificates — typically 20 per week, each valid for one week with rotating use — that the OBU uses to sign actual BSMs. None of the pseudonyms contain identifying information; they are linked only inside the SCMS through a butterfly-key derivation scheme that splits knowledge across two Linkage Authorities.
  • Linkage Authorities (LA1, LA2) each hold half of the secret that maps a pseudonym back to an enrollment identity. Neither LA on its own can identify a vehicle; both together, plus a Misbehavior Authority order, can.
  • Misbehavior Authority receives misbehavior reports (from other vehicles, RSUs, or MEC analytics), correlates them, and when warranted issues a revocation that goes onto the CRL. The CRL is then distributed to all relying parties through RSUs and Uu.
  • Registration Authority brokers all requests between the OBU and the back-end CAs, providing blinding so the issuing CAs cannot trivially link pseudonyms back to a device.

The flow in practice: a new OBU runs secure boot, presents its HSM-backed key pair to the RA, gets an enrollment certificate, then requests a batch of pseudonyms (blinded so the PCA cannot tie them to the device). It signs every BSM with the current pseudonym, rotating to the next every five minutes or so, and every week pulls down the next batch. When a peer or RSU sees implausible BSMs — speed jumps, position teleports, conflicting heading — it files a misbehavior report. The MA correlates reports, asks both LAs to deanonymize, and revokes either the offending pseudonym or the underlying enrollment identity.

The honest take is that SCMS is mature but operationally heavy. Running a production SCMS yourself — even with the open-source SCMS Manager from Integrity Security Services or OnBoard Security’s commercial stack — means standing up the multi-CA infrastructure, the misbehavior pipeline, the CRL distribution, and the cross-jurisdiction trust list management. Most OEMs and city programs use a hosted SCMS provider (Greenhills, ISS, OnBoard, NIRA Dynamics, and the regional CAMP operators in Europe). The trust list problem is real: a vehicle that drives across a border has to know which other SCMS roots it should trust, and the IEEE 1609.2.1 trust-list management is still in active deployment.

The cryptography itself is straightforward — ECDSA over P-256 for signatures, AES-128-CCM for the data, and butterfly key expansion for the privacy story. The hard part is the lifecycle: how many pseudonyms, how often you rotate, how big the CRL grows, how you distribute it inside the latency budget. A 100-million-vehicle CRL is a problem most architectures have not yet had to solve at scale; the bet is that bloom-filter prefilters and partitioned CRLs scale better than the naive design.

Telemetry Pipelines and Backend Architecture

Once you have the radio working and the trust model in place, the next thing that consumes engineering hours is the connected car telemetry pipeline. The vehicle is producing tens of kilobits per second of structured data — BSMs, vehicle-bus signals, perception summaries, diagnostic-trouble-codes — and most of it has to go somewhere reliable, queryable, and durable enough to retrain a model on.

Figure 4: Telemetry pipeline architecture — vehicle store-and-forward through MQTT/Kafka to time-series and analytics stores.

The 2026 reference pipeline has six clean stages. At the vehicle, the telematics box buffers messages into a local RocksDB or SQLite store-and-forward queue, so a tunnel or a dead cell does not lose data. From the buffer, the OBU pushes messages over MQTT 5 — increasingly using Sparkplug B for its strong topic conventions and birth/death lifecycle — to an MQTT broker, with HiveMQ and EMQX being the broker workhorses in production fleets. The broker fronts an edge Kafka cluster (or KRaft-mode Kafka) running at the MEC, which gives backpressure, tiered storage, and a clean fan-out boundary. A stream processor — Flink, Kafka Streams, or RisingWave depending on the team — aggregates, dedupes, and joins vehicle messages with road context. Aggregated outputs land in a backend Kafka cluster, partitioned by a hash of VIN so a single vehicle’s data is processed in order on one partition. From there it forks: time-series data goes to InfluxDB or TimescaleDB for dashboards and operations, raw event archives go to S3 or equivalent object storage for ML training and replay, and feature pipelines populate a feature store for the next perception or behaviour model.

A few things matter more than they look:

The shape of the topic hierarchy is load-bearing. A flat topic per vehicle does not scale; a Sparkplug-B-style spBv1.0/<group>/DDATA/<edge>/<device> with a deterministic group structure — region, fleet, role — is what lets you partition Kafka cleanly downstream. The same lesson the industrial-IoT side learned the hard way; see our unified namespace architecture HiveMQ Sparkplug B 2026 deep dive for the rationale.

QoS is not a knob you set once. The safety path is PC5 broadcast — QoS does not apply. The telemetry path runs MQTT QoS 1 by default; QoS 2 is almost never worth the round-trip cost over a cellular link. Critical command paths (remote-disable, OTA fingerprint check) use QoS 1 with idempotent handlers on both sides.

Idempotency is the property that lets you survive everything else. Vehicle messages will be replayed, duplicated, and reordered — by the broker on reconnect, by Kafka on rebalance, by the store-and-forward buffer when the radio comes back. Every consumer downstream has to be idempotent on the message ID, or your fleet metrics drift in ways no one can debug.

Pseudonym rotation interacts with the pipeline in unobvious ways. The vehicle’s signing identity rotates every few minutes, but its telemetry identity (the TSP-side device ID) is stable. You have to keep those two namespaces separate; mixing them up either leaks identity over the safety plane or breaks long-running aggregations on the telemetry plane. Most production stacks have a small internal mapper that lets engineering tooling join the two under controlled access.

The digital twin sits at the top of the pipeline. It is fed by the same Kafka stream that drives dashboards and ML, but it runs the production V2X stack against the live and replayed data — exactly the way an AV program runs shadow-mode replay against its planner. The traffic-management agency on the public side, and the OEM on the fleet side, both keep a continuously-updated twin and use it to test new signal plans, new RSU placements, and new application versions before they reach a real vehicle. The same architectural pattern we cover in the autonomous vehicle stack reference architecture 2026 post applies here — shadow before production.

End-to-End Deployment Blueprint

A connected vehicle V2X deployment is not a single project. It is a phased program with regulatory, infrastructure, and software milestones spread over years, and the right architecture decision early-on is what determines whether Phase 2 ships on schedule.

Figure 5: V2X deployment blueprint — four phases from foundation through regional federation and digital twin.

Phase 0 — Foundation (0 to 3 months). Confirm spectrum and regulatory posture. In the US that means leaning on FCC-20-164 and the 2024 C-V2X waivers; in the EU it means aligning with the C-Roads platform and member-state allocations; in Asia it means engaging the local authority early because allocations vary substantially. Pick the C-V2X chipset (Qualcomm 9150C-V2X is the default, Autotalks CRATON2 a credible alternative, Marvell’s V2X-ready Cellular platforms emerging). Pick the SCMS provider — running it yourself only makes sense for the largest OEM or national programs. Stand up the development SCMS and the development backend. None of this involves vehicles yet.

Phase 1 — Pilot Corridor (3 to 9 months). Pick one corridor — typically 5 to 20 intersections — and deploy RSUs from a known vendor (Cohda, Commsignia, Kapsch, Yunex, or Siemens, depending on geography). Retrofit 10 to 50 vehicles with OBUs. Stand up an MEC node at the operator edge or in a private 5G campus. Ship the day-1 safety apps: SPaT-driven signal phase awareness, Red Light Violation Warning (RLVW), Intersection Movement Assist (IMA). The point of Phase 1 is not coverage — it is to validate the entire architecture under production constraints and to surface every operational gap before you have a hundred RSUs to fix.

Phase 2 — City Scale (9 to 24 months). Scale the RSU network to 100 to 500 units covering the major signalized intersections. Move from retrofit OBUs to OEM line-fit on at least one vehicle program — this is where the OEM’s homologation, AUTOSAR Adaptive integration, and supplier base have to be ready. Move SCMS to production, including the misbehavior pipeline and CRL distribution at scale. Ship Day-2 apps: Vulnerable Road User (VRU) protection, work-zone warnings, eco-driving and eco-AD speed coaching. By the end of Phase 2 you should have a stable enough deployment that the operations team is running the system, not the engineering team.

Phase 3 — Regional and Twin (24+ months). Federate multiple cities under shared SCMS trust lists. Stand up a live traffic digital twin that consumes telemetry from every connected vehicle in the region and from every RSU, runs continuous replay against new application versions, and closes the loop back to signal plans and policy. Ship Day-3 apps: cooperative automated driving, platooning, intersection negotiation. This is the phase where V2X stops being a safety feature and starts being a substrate for cooperative mobility.

Two cross-phase concerns matter. Cybersecurity per UNECE WP.29 R155 (CSMS) and software-update management per R156 (SUMS) are not late-binding. They have to be wired into the architecture from Phase 0 — the signed-binary chain, the OTA rollback story, the audit trail. Bolting them on at Phase 2 costs a year. And the safety case under ISO 26262 + ISO 21448 (SOTIF) needs to be threaded through every layer that touches the safety path. The radios, the SCMS, the OBU, and the apps all sit inside the safety envelope — the analytics and the twin do not, but the boundary needs to be drawn explicitly.

Trade-offs, Gotchas, and What Goes Wrong

A connected vehicle V2X architecture fails in characteristic ways, and the failure modes are worth naming honestly. Channel congestion is the first — a hundred vehicles in close proximity all broadcasting BSMs at 10 Hz saturates the resource pool, DCC kicks in and starts thinning broadcasts, and the application layer has to be aware that its peers might be invisible at exactly the moment they matter most. Cooperative-perception applications mitigate this with relayed messages and MEC fusion, but the underlying physics does not go away.

Cross-jurisdiction trust is the second. A vehicle that drives from California to Mexico, or from Germany to Poland, has to know which SCMS roots to trust on each side. IEEE 1609.2.1 trust-list management is specified, but the operational reality is a moving target — and the cost of misconfiguration is a vehicle that silently rejects every signed message it sees.

GNSS denial is the third. Most V2X applications quietly assume meter-level position accuracy. Urban canyons, intentional jamming, and tunnels all break that assumption. Production OBUs combine GNSS with IMU dead-reckoning and increasingly with vision-based localization, but the failure modes during the transition between localization sources are subtle and rarely covered by the day-1 application logic.

SCMS CRL bloat is the fourth. Naïve revocation lists grow linearly with revocations, and a national-scale fleet will produce more revocations than a vehicle can pull down efficiently. Partitioned CRLs and bloom-filter prefilters are the working answers, but they add complexity to the trust path and are not yet universally deployed. Misbehavior reporting itself is the fifth — most pilots ship the reporting side but not the production-grade correlation and adjudication side, which means revocations either do not happen or happen unsafely. And the sixth, the one that catches every program eventually, is the integration cost between V2X and the rest of the vehicle’s electronic architecture — AUTOSAR Adaptive boundaries, in-vehicle Ethernet timing, the OEM’s own gateway and security architecture. None of those are V2X problems on paper, but they are V2X problems on the program plan.

Practical Recommendations

If you are designing a connected vehicle V2X architecture in 2026, the decisions worth pre-committing to are:

  • Go C-V2X first. DSRC has a working installed base and serves a real migration role, but every new program should be built on C-V2X with PC5 + Uu and a clear NR-PC5 upgrade path. Hybrid OBUs handle the migration where it matters.
  • Co-locate MEC early. The latency budget for safety-relevant V2N applications closes only if there is a MEC host with UPF local breakout near the corridor. Plan it in Phase 0, not Phase 2.
  • Outsource SCMS unless you are a national program or top-five OEM. The operational cost of running SCMS yourself dwarfs the cost of using a hosted provider, and the security risk of running it badly is higher than the risk of outsourcing.
  • Wire R155 and R156 into the architecture from day one. Cybersecurity Management System and Software Update Management System aren’t optional, and bolting them on later is the most expensive thing you can do.
  • Treat telemetry and the safety plane as two systems. They share the modem and the vehicle, but they have different SLAs, different security models, and different lifecycles. Cross-contaminating them is the most common mistake.
  • Invest in the twin from Phase 1. A continuously-updated traffic digital twin pays for itself the first time you want to ship a new application version without putting it on a live vehicle. The architectural pattern is the same one we describe in vehicle-to-infrastructure V2I communication implementation.
  • Plan the phased rollout in writing. Phase 0 to Phase 3 is a 2-3 year program. The architecture has to support every phase without being rewritten, which means the wrong decision in Phase 0 — wrong chipset, wrong middleware, wrong SCMS — cascades into a re-platforming at Phase 2.

These are not glamorous decisions. They are the decisions that separate V2X programs that ship from V2X programs that don’t.

FAQ

What is connected vehicle V2X architecture?
A connected vehicle V2X architecture is the layered combination of radios (C-V2X PC5 sidelink and Uu cellular), on-board software (the ITS protocol stack and V2X applications), security infrastructure (the SCMS PKI based on IEEE 1609.2 and CAMP), roadside units, MEC edge nodes, and cloud backends that lets vehicles exchange safety-relevant messages with each other (V2V), with infrastructure (V2I), with vulnerable road users (V2P), and with the network (V2N) under sub-100-millisecond latency and a pseudonymous trust model.

Is DSRC or C-V2X the standard in 2026?
C-V2X is the de-facto 2026 standard, particularly after FCC-20-164 reallocated the upper 30 MHz of the 5.9 GHz band in the US to C-V2X and the May 2024 waivers cleared production deployments. Europe maintains ITS-G5 (the ETSI/DSRC equivalent) in parallel under C-Roads, and Japan still has working DSRC-based ETC2.0 deployments, but every new OEM program and most new RSU deployments are C-V2X first. Hybrid OBUs that speak both radios exist for cross-jurisdiction migration.

What is the SCMS in V2X?
The Security Credential Management System (SCMS) is the public-key infrastructure for V2X, originally specified by the CAMP consortium and now standardized in IEEE 1609.2.1. It issues short-lived pseudonym certificates to vehicles for signing Basic Safety Messages, separates identity knowledge between two Linkage Authorities to preserve privacy, and supports revocation through a Misbehavior Authority that issues CRLs. Production SCMS providers include Integrity Security Services, Greenhills, and OnBoard Security, plus regional CAMP operators in Europe.

What’s the difference between PC5 and Uu in C-V2X?
PC5 is the direct sidelink interface used for V2V and V2I communication on the 5.9 GHz ITS band. It works without cellular network coverage, uses autonomous resource selection (Mode 4 on LTE-PC5, Mode 2 on NR-PC5), and delivers sub-20-millisecond latency for safety messages. Uu is the standard cellular uplink to the gNodeB/eNodeB, used for V2N traffic — telemetry, OTA updates, HD-map tiles, traffic-management commands. A production C-V2X OBU uses both interfaces, with safety on PC5 and management on Uu.

Why is MEC important for V2X?
MEC (Multi-access Edge Computing) hosts at the cellular operator’s edge run V2X application servers within single-digit milliseconds of the vehicle, which is what lets V2N cooperative-perception and intersection-management apps meet their latency budgets. Without local breakout from the 5G UPF to the MEC, V2N round-trips go back through the operator core to a public cloud region — typically 100-200 ms, which is too slow for collision-avoidance applications. ETSI MEC and 3GPP TS 23.501 specify the relevant interfaces.

Further Reading

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *