The V2X stack — from vehicle data to a trusted message on the road.
A V2X stack is the layered software, security and radio that turns what a vehicle or roadside unit knows — its position and speed, a hazard, a signal phase — into a standard message, signs it, and broadcasts it over a direct 5.9 GHz link that every nearby road user can verify before acting on it.
Every vehicle-to-everything (V2X) stack has the same layers: applications; a facilities layer that builds the messages (CAM and DENM in Europe, BSM, SPaT and MAP in the US); networking and transport (GeoNetworking and BTP, or IEEE 1609.3 WSMP); a security layer that signs and verifies every message (ETSI TS 103 097 or IEEE 1609.2); and an access layer, today usually the C-V2X PC5 sidelink. Positioning and time feed all of them. The jobs are the same in India, Europe and the United States; the standards that do them are not.
This page sets out the layers, compares the three regional stacks, walks through the security layer step by step, and states what the AmbiV2X Developer Stack does — and does not — provide.
Five layers, and the two that cut across them.
Read it top-down. Each layer has the same job in every region; what changes between India, Europe and the US is which standard fills it. Europe calls the whole arrangement the ITS station architecture (ETSI EN 302 665); the US equivalent is the WAVE architecture of the IEEE 1609 family, with SAE J2735 messages on top.
Applications
The behaviour that uses the messages: collision warning, emergency-brake light, signal-phase advice, roadworks warning. Apps read a local picture of the road, not raw radio frames. The use cases
V2V · V2I · V2PFacilities — the message layer
Builds and parses the standard messages, decides how often to send them, and keeps the Local Dynamic Map of what has been heard. This is where the regions differ most visibly. The message sets
CAM · DENM · CPM · BSM · SPaT · MAPNetworking and transport
Addresses and delivers the message: single-hop broadcast, or geographic forwarding to everything inside an area.
GeoNetworking + BTP · WSMP · IPv6Access — the radio
The physical and link layers. Today that is usually C-V2X PC5, the 3GPP sidelink that carries vehicle-to-vehicle traffic directly with no base station, in the 5.9 GHz band; Europe also runs ITS-G5.
LTE-V2X PC5 · ITS-G5 · NR-V2XSecurity — a vertical
Signs every outgoing message and verifies every incoming one, and manages the certificates that make that possible. It touches every layer above the radio. Walk through it step by step ↓
IEEE 1609.2 · ETSI TS 103 097Positioning, time and management
GNSS position and time feed the message content, the radio's synchronisation and the security checks. Management handles configuration and congestion control. GNSS and time sync
GNSS · PoTi · DCC
A V2X stack is not a C-V2X modem. The modem — the chipset or module — implements only the access layer. The facilities, networking, transport and security layers are software running on the host processor or the modem's application core, and that is the part normally called the V2X stack. Buying a PC5 module gives you a radio; it does not give you a message set, a security envelope or a certificate. What the silicon actually provides
India, Europe and the United States: same layers, different standards.
What fills each layer, region by region. Where the public record does not settle a cell, it says so rather than guessing. Editions are the ones the standards library and the message tables record.
| Layer | India | Europe / ETSI | United States |
|---|---|---|---|
| Direct radio | C-V2X, named by MoRTH for Draft AIS-230. No 3GPP release is named in any public description. | Technology-neutral: ITS-G5 and LTE-V2X PC5 are both permitted. The deployed base is mostly ITS-G5. | C-V2X PC5 only, under FCC 24-123. DSRC operations end 14 December 2026. |
| Spectrum | 5875–5925 MHz earmarked. On-board units licence-exempt in 5875–5905 MHz under G.S.R. 466(E), at 23 dBm/MHz and 33 dBm EIRP. Roadside-unit authorisation awaits TRAI. Spectrum | 5875–5925 MHz for road ITS (Decision (EU) 2020/1426 as amended); 5915–5925 MHz is infrastructure-to-vehicle only. | 5895–5925 MHz, three 10 MHz channels. SAE J3161/1 defines the C-V2X deployment profile. |
| Core vehicle message | Not publicly specified. No message set is attributed to Draft AIS-230 in any public source. | CAM — EN 302 637-2; Release 2 as TS 103 900. Adaptive 1–10 Hz. | BSM — SAE J2735, message ID 20. Nominal 10 Hz. |
| Event messages | Not publicly specified. | DENM — ETSI EN 302 637-3; Release 2 as TS 103 831. | BSM Part II event data; TIM and RSA from the roadside. |
| Signal and map messages | Not publicly specified. | SPATEM and MAPEM — ETSI TS 103 301. | SPaT (ID 19) and MAP (ID 18) — SAE J2735. |
| Sensor sharing | Not publicly specified. | CPM — ETSI TS 103 324. | SDSM (ID 51) — SAE J2735. |
| Networking and transport | Not publicly specified. | GeoNetworking (EN 302 636 series) with the Basic Transport Protocol (BTP). | IEEE 1609.3 WAVE Short Message Protocol (WSMP); IPv6 for non-safety services. |
| Message security | MoRTH describes “cybersecurity and communication-security provisions”. Which mechanisms are required cannot be verified: the draft text is not public. Draft AIS-230 | ETSI TS 103 097 V2.2.1 (March 2026), which profiles IEEE 1609.2-2025. Architecture in TS 102 940. | IEEE 1609.2-2025 secured messages; IEEE 1609.2.1-2026 certificate management. |
| Certificate and trust model | Not decided. No national V2X root CA or PKI operator is designated; TRAI’s recommendations were pending at the last review. India’s licensed CAs issue X.509, which V2X does not use. | CCMS: multiple root CAs on the European Certificate Trust List (ECTL), Enrolment and Authorization Authorities, short-lived authorization tickets (TS 102 941). | SCMS: elector-managed root, separate enrolment, registration and pseudonym CAs, linkage authorities, misbehaviour authority. |
| Device approval | Type approval against AIS-230 once final. Proposed dates: 1 October 2027 for vehicles that choose to fit V2V, 1 October 2028 for all new L, M and N vehicles. Draft, not in force. | No fitment mandate. C2C-CC profiles, C-Roads testing, ETSI Plugtests. | No mandate. OmniAir certification, including IEEE 1609.2.1 security test cases. |
| AmbiV2X status | A region-locked India development build, covered by automated tests. Its values are provisional until AIS-230 is published. No AIS-230 claim of any kind. | European development profile: CAM, DENM, SPATEM, MAPEM, GeoNetworking and BTP implemented and covered by automated tests; CPM partial. A development reference, not conformance-tested. | Engineering demonstration: SAE J2735 BSM from the official ASN.1, over a provisional WSMP subset with demo credentials. Not SCMS, not certified. Detail ↓ |
The India V2X stack: the radio and band are set, the layers above are not yet public.
India’s C-V2X stack is defined from the bottom up, and so far only the bottom is public. The radio is C-V2X over the 5.9 GHz PC5 sidelink. The band is 5875–5925 MHz, and on-board units became licence-exempt in its lower 30 MHz under G.S.R. 466(E) of 10 June 2026. MoRTH’s Draft AIS-230 would set the requirements for factory-fitted on-board units, enforced through vehicle type approval.
Four things are easy to overstate, so they are stated plainly here:
- AIS-230 is a draft. It is referenced by a draft amendment to the Central Motor Vehicles Rules published on 3 August 2026. Nothing in it is required of anyone until a final notification is published. India’s V2X framework
- No message set is attributed to it. Public descriptions name the technology and the band, not CAM, BSM or any other message family, and not a networking layer.
- Its security mechanisms are unverified. It is described as carrying cybersecurity and communication-security provisions. Whether it requires IEEE 1609.2, ETSI TS 103 097 or a national profile cannot be checked from a public source.
- The trust model is open. No national V2X root CA has been designated. The four trust models, and what India could take from each
The practical consequence for an India V2X stack today is architectural. Keep the facilities, networking and security layers swappable above a PC5 radio that already meets the band rules, so that the published standard changes configuration rather than hardware.
The European V2X stack: ETSI ITS, end to end.
The EU V2X stack is the most completely specified of the three, and every ETSI deliverable is free to download. It follows the ETSI ITS station architecture of EN 302 665:
- Facilities. The Cooperative Awareness Message (CAM) is the periodic status broadcast. The Decentralized Environmental Notification Message (DENM) carries hazards. SPATEM and MAPEM carry signal phase and intersection geometry from the roadside, under TS 103 301. The Collective Perception Message (CPM) shares what a station’s sensors detect.
- Networking and transport. GeoNetworking (EN 302 636 series) addresses messages to a geographic area. The Basic Transport Protocol (BTP) multiplexes them to the right facility.
- Security. ETSI TS 103 097 defines the signed-message and certificate formats, profiling IEEE 1609.2. TS 102 941 defines enrolment and authorization. Trust is anchored in the ECTL.
- Access. The standards are radio-agnostic: the identical CAM rides ITS-G5 or LTE-V2X PC5 unchanged.
Europe has no fitment mandate. Deployment runs through the CAR 2 CAR Communication Consortium’s profiles and the C-Roads corridors. The EU position · The ETSI reading order
The US V2X stack: SAE J2735 over IEEE 1609, on C-V2X.
The US stack shares cryptography with Europe and almost nothing else above the radio:
- Messages. SAE J2735 defines the dictionary: the Basic Safety Message (BSM), Signal Phase and Timing (SPaT), MAP, Traveler Information (TIM) and the Sensor Data Sharing Message (SDSM). Performance requirements are set separately, in J2945/1 for DSRC and J3161/1 for C-V2X.
- Networking and transport. IEEE 1609.3 provides the WAVE Short Message Protocol rather than GeoNetworking. There is no geographic routing layer; safety messages are single-hop broadcasts.
- Security. IEEE 1609.2 secures the message directly, and IEEE 1609.2.1 defines how certificates are requested and managed. Trust comes from the Security Credential Management System (SCMS), which separates functions so that no single authority can link a pseudonym certificate to a device.
- Access. C-V2X PC5 in 5895–5925 MHz. DSRC must cease on 14 December 2026.
A US BSM and a European CAM do similar jobs but are not interchangeable on the wire. A device that serves both markets carries two facilities layers, two networking layers and two certificate stores. The US position · SCMS versus CCMS
How the security layer turns a V2X message into something a vehicle can trust.
Vehicles act on messages from strangers, many times a second, with no time and often no network to look anyone up. Eleven steps show how a message proves itself. The diagram follows the text as you scroll; the text is complete on its own. Simplified: where Europe and the US differ, each step says how.
-
01 · Broadcast
Every vehicle talks
Each equipped vehicle broadcasts its position, speed and heading several times a second — up to ten — by radio, to everything within a few hundred metres. On the C-V2X PC5 sidelink there is no network in the path, no pairing and no connection set-up.
CAM in Europe, adaptive 1–10 Hz · BSM in the US, nominal 10 Hz · 5.9 GHz -
02 · Threat
Anyone can transmit
Radio has no caller ID. A cheap software-defined radio at the roadside can broadcast a fake emergency-brake warning. Without proof of origin, every receiver would have to choose between believing it and ignoring everything. The demonstrated attacks
-
03 · Trust anchor
A shared root of trust
A hierarchy of certificate authorities vouches for every station. Each receiver already holds the root certificates it trusts, so it can check any sender offline, with no server to ask.
Europe: the roots listed on the European Certificate Trust List, signed by the Trust List Manager. US: SCMS roots under elector-based management. India: no national V2X root designated yet.
-
04 · Enrolment
Enrolled once, early in its life
An Enrolment Authority registers the station and issues a long-term enrolment credential that identifies it to the PKI. That credential is used only to request operational certificates. It never signs a message on the road.
Typically bootstrapped at or near manufacture; it can be renewed -
05 · Privacy
Anonymous certificates for the road
An Authorization Authority issues a batch of short-lived pseudonym certificates — authorization tickets, in European terms. Each says “a genuine station, allowed to send these message types”, but not which station. The vehicle changes them as it drives, which makes tracking it from its own broadcasts much harder. How pseudonymity works
The issuer does not learn who it issued them to. In Europe the AA has the Enrolment Authority validate the request without seeing the enrolment credential. In the US SCMS, the registration authority, pseudonym CA and linkage authorities split the knowledge so no single component can link a certificate to a device.
-
06 · Key custody
The key stays in the chip
Private keys are generated inside tamper-resistant hardware — a secure element or a V2X hardware security module — and never leave it. Host software hands over a digest and receives a signature, so compromised application software cannot copy the key. Why software key storage fails
On AmbiOBU and AmbiRSU: optional AmbiSEC security integration -
07 · Sign
Sign, attach, broadcast
Each message carries an ECDSA signature — on the widely used NIST P-256 curve, two 32-byte values — and identifies its signer. Usually that is the 8-byte digest (HashedId8) of the signing certificate. The full certificate is attached periodically, typically about once a second, so new neighbours can learn it. Anyone can read the content; changing a single bit breaks the signature.
IEEE 1609.2 · ETSI TS 103 097 · signed, not encryptedThe standards also define Brainpool and 384-bit curves; which ones a deployment accepts is set by its profile. When a full certificate is attached also differs by profile and message type.
-
08 · Verify
Four checks before anything acts on it
- 1The signature matches the certificate’s public key
- 2The certificate chains to a root the receiver already trusts
- 3The generation time is recent and the claimed position is plausible
- 4The certificate’s permissions cover this message type
Each check is quick on suitable hardware. The hard part is volume: a receiver in dense traffic faces hundreds or thousands of signed messages a second, which is why verification throughput drives hardware choice.
-
09 · Reject
Forgeries are dropped
A self-made certificate can produce a mathematically valid signature, but it chains to no trusted root, so Car B discards the message and drives on. Altering a single bit of a genuine message fails the signature check in the same way.
-
10 · Revoke
Misbehaving stations are cut off
Valid credentials do not make a message true: a genuine vehicle can be faulty, spoofed or compromised. Receivers report implausible data to a Misbehaviour Authority, which can stop that station receiving new certificates. Misbehaviour detection
Europe: the enrolment credential is revoked so the AA issues nothing further, and the short-lived tickets already held expire. US: a revocation list carries linkage seeds that let receivers recognise and reject the device’s future pseudonym certificates.
-
11 · Summary
Trust the message, not the sender’s name
No vehicle knows who the others are, and none needs to. Each message carries its own proof: signed by a key that never left protected hardware, certified through a chain to a trusted root, and checked by every receiver.
The standards behind the walkthrough
- ETSI TS 103 900 and EN 302 637-3 — the cooperative-awareness broadcast and hazard notifications
- ETSI TS 102 940 — ITS security architecture; ETSI TS 102 941 — trust and privacy management: enrolment and authorization
- ETSI TS 103 097 — signed-message and certificate formats; IEEE 1609.2-2025 — the base security standard used in the US and profiled by ETSI
- IEEE 1609.2.1 — certificate management for the SCMS; ETSI TS 103 759 — misbehaviour reporting
- EU C-ITS Certificate Policy — how the European authorities and the trust list are run
Free versus paid, and which edition is current: the standards reading order. The certificate structures field by field: V2X PKI.
What the AmbiV2X Developer Stack implements — and what it does not.
The AmbiV2X Developer Stack is the open development and integration environment that comes with the AmbiOBU and AmbiRSU development platforms. It is a developer stack, not a certified production protocol stack. Its protocol library implements the standards layer; the rows below say how far, and every line is a development claim, never a conformance one. Everything listed runs today over a host test transport — over-the-air operation on the PC5 radio is not claimed here.
| Status | What it covers |
|---|---|
| Provided | The development platforms: AmbiOBU and AmbiRSU, each with a 5.9 GHz C-V2X PC5 subsystem at 3GPP Release 14, GNSS, a 9-axis IMU and a separate 4G LTE module for backhaul. On them, an Ubuntu 22.04 LTS and ROS 2 Humble application environment, C++ and Python, with logging, recording and replay examples — delivered according to programme scope. |
| Implemented in the developer stack | Implemented in the AmbiV2X protocol library and covered by automated tests, for the European (ETSI) development profile: CAM generation, using the ETSI generation rules, and parsing; the DENM event lifecycle — trigger, update, cancellation and repetition; SPATEM and MAPEM generation and parsing, with an example receive-side signal-awareness application; GeoNetworking single-hop and geo-broadcast origination; BTP-B; and the ECDSA P-256 signing and verification primitive. A region-locked India development build is tested alongside it; its values are provisional and its composition is not published until AIS-230 is final. |
| Partially implemented / development | CPM encoding and decoding, carrying perceived objects that an external sensor system supplies — nothing yet consumes a received CPM, and AmbiOBU has no perception sensors. A US engineering demonstration: the SAE J2735 BSM encoded and decoded from the official ASN.1, over a provisional IEEE 1609.3 WSMP subset with demonstration credentials — not SCMS, not certified. Optional AmbiSEC integration for protected key storage and cryptographic services. |
| Programme-selected / integration | Over-the-air operation on the target PC5 module. SAE J2735 SPaT, MAP and TIM applications and the full US security profile. The final AIS-230 requirements, once published. Real enrolment and authorization against a programme’s PKI. Each is scoped as integration work for the programme that needs it. |
| Not publicly claimed | The signed-message envelope (ETSI TS 103 097 / IEEE 1609.2) is under development: one IEEE 1609.2 hashing rule is still to be verified against the normative text, so no signing interoperability is claimed. Certificate-lifecycle and PKI integration, misbehaviour reporting, and any Japanese profile are not claimed either. |
| Requires a licensed stack | A conformance-tested commercial protocol stack for a production programme, and real certificates from an authorised PKI operator. Where a programme needs either, Ambimat integrates the stack and credentials the OEM or Tier-1 selects and licenses. The commercial stacks |
| Not offered | A certified production automotive V2X stack. ISO 26262 or Automotive SPICE certification. AIS-230, ETSI, OmniAir or any other conformance certification or type approval. Operation of a root CA or V2X PKI. DSRC / 802.11p products. NR-V2X. |
Developer stack, open source or commercial stack? They answer different questions. A developer stack such as AmbiV2X is for building, instrumenting and testing applications and integrations on real hardware. Open-source stacks such as Vanetza are the fastest way to read a working ETSI implementation. A commercial stack is what a production programme buys when it needs a conformance-tested implementation and a vendor behind it. Plenty of programmes use all three, at different stages.
Each layer, in depth.
ITS station architecture
The ETSI reference model behind the layers above: four layers, two verticals.
Message sets
BSM, CAM, DENM, SPaT, MAP, CPM and VAM, with IDs, editions and rates.
C-V2X
PC5 and Uu, Release 14 to Release 19, and why the sidelink needs no network.
V2X PKI
Enrolment credentials, pseudonym certificates and the EA / AA split, field by field.
AmbiV2X Developer Stack
The ROS 2 development environment for AmbiOBU and AmbiRSU, and what a programme receives with it.
Test and certification
What conformance is assessed against in each region, and who does the assessing.
Building a V2X OBU, RSU or regional protocol integration?
Bring the target region, the message profile and the hardware constraints. Ambimat can take on the device-side architecture, the developer environment, security integration with AmbiSEC, integration of the regional profile or licensed stack your programme selects, and custom OBU and RSU hardware. That work runs as a V2X engineering engagement.
Questions this page answers.
What is a V2X stack?
The set of layers that turns vehicle or roadside data into a signed V2X message on the radio, and back again at the receiver: applications, a facilities (message) layer, networking and transport, a security layer, and the access layer — usually C-V2X PC5 — with positioning and time underneath. The term usually means the software above the radio, since the modem supplies only the access layer.
What is the difference between a V2X stack and a C-V2X modem?
The modem implements the radio: the 3GPP PC5 sidelink physical and link layers. The V2X stack is everything above it — message encoding, networking, transport and message security — plus the certificate handling that security needs. A PC5 module on its own gives you a radio, not an interoperable V2X station.
What layers are in a V2X protocol stack?
Applications; facilities, where CAM, DENM, BSM, SPaT and MAP are built and parsed; networking and transport, such as GeoNetworking with BTP in Europe or WSMP in the US; and access, the radio. Security and management run alongside as verticals that touch every layer, which is how ETSI EN 302 665 draws the ITS station.
What V2X stack is used in India?
The radio and band are set: C-V2X over the 5.9 GHz PC5 sidelink, with on-board units licence-exempt in 5875–5905 MHz under G.S.R. 466(E). The layers above are not yet public. Draft AIS-230 would set on-board unit requirements, but it is a draft, its text is not public, no message set or security profile is attributed to it, and no national V2X root CA has been designated. Draft AIS-230.
How does the European V2X stack differ from the US V2X stack?
Europe uses ETSI ITS: CAM and DENM messages, GeoNetworking and BTP, ETSI TS 103 097 security and a multi-root trust list, over ITS-G5 or LTE-V2X. The US uses SAE J2735 messages such as the BSM, IEEE 1609.3 WSMP, IEEE 1609.2 security and the SCMS, over C-V2X PC5 only. They share cryptography and certificate lineage but are not interoperable above the radio.
Does C-V2X PC5 require a cellular network?
No. PC5 is the direct sidelink between nearby devices. In 3GPP Release 14 Mode 4 a station picks its own transmit resources from a pre-configured pool, with no base station, SIM or subscription. A cellular connection is useful separately — for certificate top-ups, trust-list updates and software — but it is not in the path of a safety message.
What is the difference between CAM and BSM?
Both are the periodic “here I am” broadcast. The European CAM (ETSI TS 103 900) is sent adaptively between 1 and 10 Hz as the vehicle's motion changes, and hazards go in a separate DENM. The US BSM (SAE J2735, ID 20) is nominally sent at 10 Hz, with event data in its optional Part II. Their fields overlap but they are not interchangeable on the wire.
What are DENM, CPM, SPaT and MAP messages?
DENM is the European event message for hazards such as an emergency brake or roadworks. CPM shares objects a station's own sensors detect. SPaT gives each signal's current phase and time to change, and MAP gives the intersection's lane geometry, so a vehicle can tell which signal applies to it; Europe's equivalents are SPATEM and MAPEM.
Where does IEEE 1609.2 fit in a V2X stack?
In the security layer. It defines the signed-message envelope and the certificate format: what is signed, how the signer is identified, and how permissions and validity are encoded. It sits between the message and the networking layer, and it is used directly in the US and, profiled by ETSI TS 103 097, in Europe.
Where does ETSI TS 103 097 fit?
It is Europe's profile of IEEE 1609.2 for ITS: it fixes which 1609.2 options a European station uses for each message type, including signer and certificate rules. V2.2.1, published in March 2026, profiles IEEE 1609.2-2025. Enrolment and authorization flows are a separate document, ETSI TS 102 941.
Does Ambimat provide a production-certified V2X stack?
No. The AmbiV2X Developer Stack is an open development and integration environment for the AmbiOBU and AmbiRSU development platforms. Ambimat does not currently sell a certified production automotive V2X protocol stack, and claims no ISO 26262, Automotive SPICE, AIS-230, ETSI, OmniAir or other conformance certification. Where a production programme needs a conformance-tested stack, Ambimat integrates the one the programme selects.
Can AmbiV2X run on AmbiOBU and AmbiRSU?
Yes — that is what it is for. Both run Ubuntu 22.04 LTS with ROS 2 Humble and the AmbiV2X Developer Stack above a 5.9 GHz C-V2X PC5 subsystem at 3GPP Release 14, with optional AmbiSEC security integration. The AmbiV2X Developer Stack.
Can Ambimat integrate a commercial stack chosen by an OEM or Tier-1?
Yes. Integrating a stack and credentials that the OEM or Tier-1 has selected and licensed is ordinary engineering scope: device-side architecture, the security boundary to a secure element, and bring-up on the target hardware. Certification of the result sits with the stack vendor and an accredited body, not with Ambimat.
Last updated 2026-10-06 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: v2x@ambimat.com