ETSI TS 103 324 (CPM): from study to standard

A vehicle sees a pedestrian its neighbour cannot. Collective perception is the idea that it should say so: share the detection, on the air, so the pedestrian exists in everyone’s model of the junction and not just in one car’s sensor.

That idea took three and a half years to go from a question to a rule. The question was written down in December 2019, in ETSI TR 103 562 V2.1.1, Analysis of the Collective Perception Service. The rule arrived in June 2023, in ETSI TS 103 324 V2.1.1, Collective Perception Service; Release 2. One is a report and one is a specification, and the distance between them is where most of the interesting decisions live.

A report is not a standard

The word on each cover is doing real work. TR 103 562 is a Technical Report: informative, exploratory, allowed to reason out loud. Its job was to establish whether sharing sensor detections is worth it at all — what it buys in awareness, and what it costs on a channel that is already carrying everyone’s awareness beacons. A great deal of the report is load modelling, because the failure mode of collective perception is not that it fails but that it works so well every car drowns the channel describing the same three cars.

TS 103 324 is a Technical Specification: normative, testable, written in the ETSI modal-verb grammar where shall is a conformance obligation and should is not. It does not re-argue whether collective perception is a good idea. It takes the report’s conclusions as settled and answers the next question: given that stations are going to do this, exactly what goes on the wire, and when.

Reading them in order is the cheapest way to understand the standard, because the specification rarely explains its own constraints. When TS 103 324 tells you to throttle how often an object may be re-sent, the reasoning for that throttle is back in the report.

The message is the smaller half of the service

The specification separates two things that are easy to conflate. There is the Collective Perception Service (CPS), the facilities-layer behaviour, and there is the Collective Perception Message (CPM), the bytes it emits. In TS 103 324 they are not even the same clause:

• Clause 6, CPM dissemination. The service. When to generate a message, which detected objects to include, how to keep the channel from saturating.
• Clause 7, CPM specification. The message. The container tree, the fields, the ASN.1.

Most first implementations start at clause 7, because a format is concrete and a message can be decoded and admired. But a decoder that parses every field correctly still has not implemented collective perception. The part that decides what to send, the part the report spent years justifying, is clause 6, and it is the harder half.

Five containers, and a frame that is always there

Open the message and the top level is deliberately dull. A CPM is a header, a mandatory management container, and then a list of typed containers:

originatingVehicleContainer   CpmContainerId ::= 1
originatingRsuContainer       CpmContainerId ::= 2
sensorInformationContainer    CpmContainerId ::= 3
perceptionRegionContainer     CpmContainerId ::= 4
perceivedObjectContainer      CpmContainerId ::= 5

The management container is not one of the five; it is always present, and it carries the two things every other container is interpreted against: a reference time and a reference position. Everything a CPM says about an object is said relative to those. Hold that thought; it is the subject of the next note.

The five typed containers each make a different kind of claim:

Container	ID	What it asserts
Originating Vehicle	1	The sending vehicle’s own state, needed to interpret everything else
Originating RSU	2	The same, for a roadside unit in place of a vehicle
Sensor Information	3	What sensors the station has and what each can see
Perception Region	4	The area the station currently perceives, including where it sees nothing
Perceived Object	5	An individual detected object: position, motion, class, quality

Three details are worth knowing before you write a parser, and only the first lives in the ASN.1. The container list holds up to eight entries, more than the five types, because a station may send several sensor-information or perception-region containers. The ASN.1 forbids the two originating containers from appearing together, and clause 7.1.1 requires one of them in prose. That same clause also requires a Perceived Object Container, so the smallest message the ASN.1 admits carries two containers and the smallest conformant one carries three.

The Perception Region container is easy to overlook. Reporting where a station sees nothing is not padding: an empty region is a positive statement that a patch of road is clear, which is different from having no information about it. Free-space is data.

The rules that decide what goes in a CPM

Clause 6 is the service, and it is mostly about restraint. A vehicle with a good sensor suite can perceive dozens of objects; putting all of them in every message at 10 Hz is exactly the channel collapse TR 103 562 warned about. So the specification defines, in order:

• Generation events — the triggers that cause a CPM to be assembled at all.
• Inclusion management, separately for the Sensor Information container and for Perceived Objects — the rules that decide whether a given object has changed enough, or is important enough, to be worth sending now.
• An object utility function and perception-region-based assembly — ways of ranking what to include when not everything fits.
• Rate control, pinned down in normative Annex D (Frequency and Content Management) and illustrated in informative Annex E (Object Inclusion Rate Control).

This is why the CPM is quasi-periodic. The management container advertises a planned rate range, but a newly appeared object, or one that has moved far enough since it was last described, can force a message out ahead of schedule. The message cadence follows the object dynamics, with no fixed clock behind it, which is a different mental model from CAM and one that trips up anyone who assumes a fixed beacon interval.

Two places this gets hard in production

The structure above is clean on paper. Two of its consequences are not.

The first is reference frames. Every perceived object is described relative to the sending station’s reference position, so the sender’s own positioning error is inherited by every object it reports. Get the reference wrong by a metre and you have moved twenty pedestrians by a metre, in unison.

The second is object age. A perceived object is a measurement with a history: detected by a sensor, fused, encoded, transmitted, received, fused again. TS 103 324 gives the Perceived Object container explicit machinery for time and for age (clause 7.1.8, Object ID and time management and Object dimensions and age) precisely because, without it, a receiver draws the object where it was, not where it is. The next two notes take these one at a time.

Read the sources yourself

Both documents are public. If you are implementing, TS 103 324 V2.1.1 is the normative text and the only one that settles conformance disputes; its Annex A carries the ASN.1, and Annex B points to the forge, where the containers are documented in readable form if the tree is hard to hold in your head. Read TR 103 562 V2.1.1 alongside it: that is where clause 6’s constraints get their justification, and it will stop you from reading a deliberate rule as an oversight.

For where the CPM sits among the other C-ITS messages, the five-minute message-set tour puts it in context, and the Release 1 to Release 2 map places TS 103 324 among the documents that landed with it. The stacks and decoders used to read real CPMs off the wire are in resources.