· 25 May 2026 · Updated · 7 min read
ETSI C-ITS message set — a 5-minute tour
What CAM, DENM, CPM, VAM, MAPEM, SPATEM, IVIM, SREM and SSEM are, who emits them, at what rate, and what each one contains.
When you read about cooperative ITS, the same nine acronyms keep coming back. This post is a fast tour through them: what each one is for, who emits it, roughly how often, and what the payload carries.
Nine is the working core. The full count is larger, and the objective census is the BTP port registry, since a message needs an assigned port to travel at all: TS 103 248 V2.5.1 lists 26 well-known ports and 28 distinct message types, from charging and tyre-pressure telemetry to certificate revocation lists and marshalling. The nine below are the ones a cooperative-safety deployment meets first.
The widget below lets you click through them while you read. The numbers and the top-level field lists are pulled from the latest published ETSI specifications (TS 103 900 for CAM, TS 103 831 for DENM, TS 103 324 for CPM, TS 103 300-3 for VAM, TS 103 301 for the rest).
Periodic beacon — position, heading, speed, vehicle dimensions. Every C-ITS station sends one.
Two families: periodic awareness and event-driven
The first thing to internalize is that these nine split cleanly into two families.
Periodic awareness messages repeat whether anything is happening or not. They’re the heartbeat of the network. CAM, VAM and CPM all belong here. A vehicle is alive on the network as long as its CAMs keep arriving on time, and a station that stops emitting CAMs effectively disappears from the cooperative picture even if it’s physically still there.
The cadence is adaptive but bounded. CAM, for example, goes between 1 Hz and 10 Hz depending on speed and heading change — the harder the dynamics, the faster the broadcast. CPM follows similar rules but with object-level triggers on top: a new perceived object can force a CPM out earlier than the next scheduled tick.
Event-driven messages are silent until something happens. DENM is the canonical one: roadworks ahead, slow vehicle, harsh braking detected, animal on the road. SREM, SSEM, IVIM are also event-driven, though their “events” cover operations as well as safety: a tram approaching a junction requesting priority (SREM), the junction reply (SSEM), an in-vehicle sign push (IVIM).
The distinction matters because the failure modes are different. A missing periodic awareness message is detected by absence — the listener notices the beacon stopped. A missing event-driven message can go undetected forever: nobody knows what was never sent.
MAPEM and SPATEM are a pair
The intersection control duo deserves a paragraph. MAPEM is essentially static — it describes the physical and logical geometry of an intersection, the lanes, the connections between lanes, and the signal groups that govern each connection. It’s broadcast at ~1 Hz so that new vehicles entering the range get a copy quickly, but the content barely changes between broadcasts.
SPATEM is the dynamic counterpart. For each signal group defined in the
MAPEM, SPATEM tells you the current colour and the predicted timing of the
next change — typically a minEndTime and maxEndTime window. The
vehicle’s job is to take SPATEM’s signal-group references and look them up
in MAPEM to know which physical lane goes to which destination, then combine
that with the SPATEM phase to compute things like green-light arrival
optimisation (GLOSA) or red-light violation warning.
This decoupling has consequences. If you receive SPATEM but no MAPEM, you know the lights are red somewhere — you just don’t know where. Stacks typically buffer SPATEMs for a few seconds waiting for a matching MAPEM before discarding them.
VAM is CAM for VRUs
VAM is the youngest of the set, standardised in TS 103 300-3. The motivating
problem is that VRUs (pedestrians, cyclists, e-scooters) move with completely
different dynamics from vehicles, and lumping them into the CAM data model
would force overly broad ranges and resolutions. VAM mirrors CAM’s structure
but specialises the fields, restricting stationType to VRU values and adding a profileAndSubprofile, a finer-grained orientation, and most importantly a cluster container
that lets multiple VRUs broadcast as a single bounded group.
The clustering matters because crowded pedestrian areas would otherwise produce a CAM-storm. With clustering, a tour group of 30 walking together appears as one VAM with a bounding-box geometry in place of 30 individual beacons, which the receiver can decompose conservatively if needed.
CPM has a scaling problem
Collective Perception (CPM, TS 103 324) is conceptually the most powerful message in the set: it lets equipped vehicles share sensor detections so non-equipped users become visible to the network. In a sufficiently dense deployment, a pedestrian standing on a corner without any device is still “seen” by every car within 200 m that has an HD camera, because each of those cars publishes a perceived object pointing at her.
The catch is payload size. A CAM is ~200–400 bytes. A CPM can be 300 B if a car is alone in a field, or 2 kB if it’s detecting 20 surrounding objects. The standard tries to control this with redundancy mitigation rules — don’t re-publish an object that’s already in another station’s recent CPMs — but the rules are subtle and implementations vary in how aggressively they apply them. This is a fertile area for interop bugs, and a subject for a later post.
SREM/SSEM: the small ones nobody talks about
These exist for priority management at intersections — emergency vehicles, public transport, dangerous-goods vehicles. SREM is the request (“I need green for movement 4 in 8 seconds”), SSEM is the reply (“acknowledged, priority granted, you’re in queue position 1”). They’re rare in the message mix you see on a typical highway, common at urban junctions in cities that have rolled out priority schemes.
Worth knowing that both are tied to a specific intersection by an IntersectionReferenceID (region plus id) that must match a known MAPEM. So you can’t even parse SREM/SSEM meaningfully
without MAPEM context for the relevant intersection.
IVIM: the variable sign of the future
IVIM (In-Vehicle Information, TS 103 301) is how infrastructure pushes dynamic regulatory and advisory content into vehicles: variable speed limits, dynamic lane allocation, hazard advisories. It’s structurally complex — the message contains a “geographic location container”, a “general IVI container” and a “text container”, each with its own deeply nested option set.
IVIM volume looks set to grow as ISO 14823 (the underlying graphic-symbol code system it references) gets richer and as European agencies start publishing structured RWW (Road Works Warning) profiles. It deserves its own post; this one is just a tour.
Where to go from here
If you’re building a decoder, start with CAM, then DENM, then MAPEM/SPATEM together. CPM and VAM share enough structural DNA with CAM that they’re straightforward once CAM works. IVIM is a different beast — wait until the others are solid before tackling it.
If you’re integrating receive-side, the priority order is usually CAM → MAPEM → SPATEM → DENM → CPM, because the upstream applications (situational awareness, intersection assistance, hazard warning) build on each layer in that order.
The full ASN.1 schemas are available from ETSI’s forge repository. They are the source of truth when the prose of the specifications is ambiguous, which is more often than you’d hope.
This tour describes the set as Release 2 leaves it. Which documents were renamed, renumbered or replaced on the way there is a separate map, and the Release 1 to Release 2 crossing is where a version mismatch usually turns out to have started.
Once the message set is behind you, the next wall is trust: every message here is signed, and the certificate side has conventions of its own. Two starting points — the credential lifecycle in IEEE 1609.2.1, and what the CPOC Protocol’s Annex I requires of certificate names, the kind of detail that costs months when it surfaces late.
The stacks, encoders and simulators for all of the above are catalogued in resources.
Comments
Anonymous OK · no email · 5 min edit window.