· 25 May 2026 · 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 actually 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’s actually in the payload. It’s the document we wish had existed when we started building decoders.
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 messages split cleanly into two families.
Periodic awareness messages are sent on a clock, 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” are operational rather than 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: a vruProfile instead of a stationType, 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 rather than 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 one we’ll come back to in a future 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 intersectionID
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 “generic information container” and a “text container”, each with its own deeply nested option set.
We expect IVIM volume 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. We use them daily; they are the source of truth when the prose of the specifications is ambiguous, which is more often than you’d hope.
Comments
Anonymous OK · no email · 5 min edit window.