Is ETSI CAM still EN 302 637-2?

EN 302 637-2 is the Release 1 CAM. The current Release 2 service is TS 103 900, which specifies extensions to the Release 1 format. TS 103 900 states the compatibility in one direction: Release 1 implementations can receive and decode a Release 2 CAM and use the Release 1 content without understanding the Release 2 additions. The normative document a new deployment cites has a different number.

What is new in C-ITS Release 2?

Two services with no Release 1 equivalent: CPM, the Collective Perception Message (TS 103 324), and VAM, the VRU Awareness Message (TS 103 300-3), plus a standard misbehaviour reporting service (TS 103 759). Release 2 also reorganised GeoNetworking into the TS 103 836 multi-part family, specified multi-channel operation across layers (TS 103 696, TS 103 697, TS 103 141, TS 103 695), and took security, PKI and the common data dictionary through a major version bump under their existing numbers (TS 103 097, TS 102 941, TS 102 894-2).

How do I tell if an ETSI ITS document is superseded?

Check two things in the deliverable itself: the version and the title. Every Release 2 deliverable carries a version 2.Y.Z and ends its title with Release 2, a rule ETSI states in TS 103 898. The document number is a poor guide, because Release 2 documents are spread across several ranges. Then confirm the status on the ETSI deliverables portal: a document can stay published for reference while a different deliverable is the one to implement.

ETSI C-ITS, Release 1 to Release 2: a standards map

Which ETSI document is current for each C-ITS layer and message, and which one it replaced. A Release 1 to Release 2 map, with version numbers.

Most public writing about V2X still names Release 1 documents. A tutorial cites EN 302 637-2 for the cooperative awareness message, an integration guide points at EN 302 636-4-1 for GeoNetworking, a slide deck lists the ITS station architecture as EN 302 665. None of those is wrong, exactly. They are the first generation of a corpus that was renumbered, and not into any single block: the current documents are scattered across several ranges, cited side by side with the old ones, and it is genuinely hard to tell from the outside which document a fresh deployment should be reading.

This is a map. It puts each C-ITS function next to its Release 1 document, its Release 2 document and the current version, so the renumbering stops being a puzzle you solve one specification at a time.

How ETSI organises the corpus

The first generation of Cooperative ITS standards clusters in the EN 302 6xx range: the architecture, the access layer, GeoNetworking, the basic transport protocol, and the first CAM and DENM services. These are the documents most readers met first, and most of them are still published.

Release 2 did not edit those documents in place. It issued new deliverables, mostly in the TS 103 8xx and TS 103 9xx ranges, with TS 104 0xx holding mostly conformance test suites: TS 104 018-3 is the abstract test suite for the VRU service specified in TS 103 300-3. A few functions kept their old number and simply gained a version 2, but the headline services moved. CAM went from an EN to a TS. GeoNetworking was broken into a multi-part TS 103 836 family. Collective perception and VRU awareness, which had no first-generation document at all, appeared as brand new specifications.

Those ranges are a useful sketch and a poor rule. Release 2 also lives in EN 303 7xx for the two access layers, in 103 3xx and 103 7xx for collective perception, VRU awareness, infrastructure services and misbehaviour reporting, and, within the 102 6xx to 103 0xx ranges, for the four documents there that kept their original number through a major version bump. Sort by number and ten of the sixteen rows below land in the wrong pile.

ETSI states the real test inside the documents themselves. TS 103 898 lists it in four lines: every Release 2 deliverable carries a version 2.Y.Z; the title ends in “Release 2”; a non-specific reference points at the latest Release 2 version of that document; and a Release 2 specification published as 2.0.0 “includes the same normative provisions as the latest version of the same Technical Specification in Release 1”.

So the generation is in the title, and the number never carries it. Check the title suffix first: the version alone misleads, because EN 302 636-5-1 is a Release 1 document sitting at v2.2.1.

The map, Release 1 to Release 2

Each row is one function, the document that carried it in Release 1, the document that carries it now, and the current Release 2 version.

Function	Release 1	Release 2	Current version
Station architecture	`EN 302 665`	`TS 103 898`	v2.0.0
Access layer, ITS-G5	`EN 302 663`	`EN 303 797`	v2.1.1
Access layer, LTE-V2X / NR-V2X	`EN 303 613`	`EN 303 798`	v2.1.1
GeoNetworking	`EN 302 636-4-1`	`TS 103 836-4-1`	v2.2.1
Basic Transport Protocol	`EN 302 636-5-1`	`TS 103 836-5-1`	v2.1.1
Cooperative awareness (CAM)	`EN 302 637-2`	`TS 103 900`	v2.3.1
Decentralized notification (DENM)	`EN 302 637-3`	`TS 103 831`	v2.3.1
Local Dynamic Map	`EN 302 895`	`TS 103 938`	v2.0.0
Basic Set of Applications	`TR 102 638` (v1)	`TR 102 638` (v2)	v2.1.1
Message security & certificates	`TS 103 097` (v1)	`TS 103 097` (v2)	v2.2.1
Trust & privacy management (PKI)	`TS 102 941` (v1)	`TS 102 941` (v2)	v2.2.1
Common Data Dictionary	`TS 102 894-2` (v1)	`TS 102 894-2` (v2)	v2.4.1
Collective perception (CPM)	— (study: `TR 103 562`)	`TS 103 324`	v2.1.1
VRU awareness (VAM)	—	`TS 103 300-3`	v2.3.1
Infrastructure services (SPATEM/MAPEM/IVIM/SREM/SSEM/RTCMEM)	`TS 103 301` (v1)	`TS 103 301` (v2)	v2.3.1
Misbehaviour reporting	—	`TS 103 759`	v2.2.1

Versions checked against the ETSI deliverables portal on 2026-09-05. A version column ages the moment it is written, so treat that date as part of the claim.

One row carries a caveat. The Basic Transport Protocol moved into TS 103 836-5-1, whose current version is v2.1.1, below the v2.2.1 that the Release 1 document it replaces still carries. The successor holds the lower version number, so “the Release 2 BTP” and “the most recently revised BTP text” can point at different documents.

Two rows sit at 2.0.0: the architecture (TS 103 898, 2022-07) and the Local Dynamic Map (TS 103 938, 2023-02). TS 103 898 defines that number: a Release 2 specification published as 2.0.0 carries the same normative provisions as the last Release 1 version of the same document. These are short deliverables whose body is the numbering rule and a pointer. The text is settled, and it is the Release 1 text; for those functions the first-generation document is still what you implement against.

The rows above cover the message and protocol stack. The mapping leaves out supporting specifications a deployment also needs, among them TS 102 687 for decentralized congestion control and EN 302 890-2 for position and time. The rule of this post, applied to DCC: TS 102 687 sits at v1.2.1 and the cross-layer TS 103 175 at v1.1.1, so neither has a Release 2 edition. That does not mean congestion is unattended in Release 2. Multi-channel operation adds a layer of decision above it, choosing which channel carries what, and it reads the channel load ratio the access layer already measures: TS 103 697 is explicit that this measurement “is not specific for MCO and therefore not an MCO entity”. So the DCC documents stay in their first generation while the resource-coordination work moves into MCO, and continues in TR 104 073 on radio resource management.

The same function, a different document number. A dashed arrow means there is no Release 1 document at all: collective perception, VRU awareness and misbehaviour reporting are services Release 2 introduced. The architecture row is marked 2.0.0, the version that means the normative text is still the Release 1 one.

What Release 2 genuinely adds

Renumbering is the boring half. The interesting half is the functions that did not exist in the first generation.

Collective perception, TS 103 324. A station broadcasts what its sensors detect, extending the picture beyond its own state. A roadside unit that sees a pedestrian steps in for the vehicle whose view is blocked. Its payload describes objects the sender did not originate, which is why it needs an object age field and a confidence model built for objects the sender did not originate. A CAM has carried per-element confidences since Release 1, but for its own state; the CPM has to describe how well it saw somebody else, when it saw them, and which region it was able to observe at all.

VRU awareness, TS 103 300-3. Pedestrians and cyclists get their own message on the same channel, announcing position and motion the way a vehicle broadcasts a CAM. The design question inverts the vehicle case: how a device announces a vulnerable user without flooding the channel when a crowd crosses a junction.

Misbehaviour reporting, TS 103 759. A standard channel for stations to report senders whose messages look wrong, feeding the trust authority that can revoke a compromised certificate. Release 1 had a security architecture; Release 2 added the reporting loop that lets the system act on what stations observe.

Release 2 also brings multi-channel operation, spreading the services across more than one radio channel so a busy junction does not starve safety messages. The specifications exist and are split by layer: TS 103 696 and TS 103 697 hold the MCO architecture, communication and C-ITS sides, TS 103 141 the facilities-layer function, TS 103 695 the access layer in the 5 GHz band, and the networking part sits in TS 103 836-4-1. The standards are in place; what is thin is deployment and profiling.

Reading a version number

The version and the status carry the information the number does not. Three things are worth knowing.

A Release 1 document can stay published and stop being current. The EN 302 6xx specifications remain downloadable, and for a couple of functions they remain the implementable reference, but for CAM, DENM and GeoNetworking the Release 2 document is the one a new deployment cites. Downloadable and current are different states.

A version number tracks its own document, and the two can fall out of step with the release. The clearest example runs backwards: the Release 1 BTP (EN 302 636-5-1) sits at v2.2.1 while its Release 2 successor (TS 103 836-5-1) sits at v2.1.1. The release is an editorial grouping; the version belongs to the document.

And the document you cite is not always the document you read. A Release 2 deliverable published at 2.0.0 is the current reference for its function, while its normative provisions are the ones in the Release 1 text it points at. The version tells you which document to name; the pointer inside tells you which text to implement. When in doubt, the deliverable status on the ETSI portal settles it; the release name does not.

Read it yourself

Everything above is checkable against published documents. The full deliverable list, with versions and status, is on the ETSI standards portal. The machine-readable schemas for the Release 2 messages, the ASN.1 modules for CAM, DENM, CPM, VAM and the infrastructure services of TS 103 301, live in ETSI’s forge repository.

For what each of the nine core C-ITS message types is and does, the message set tour is the place to start, and the station architecture piece places the layers this map renumbers. Collective perception, the largest genuinely new service in Release 2, has its own path from study to standard.