The EU and US V2X stacks share one number space

Treatments of cooperative ITS tend to open with a split. Europe standardised one way, the United States another, and the two produced incompatible stacks. The spectrum story supports that reading. FCC 24-123 clause 60 starts a two-year clock on DSRC operations from the date the rules appear in the Federal Register, and new licences issued after the effective date authorise only C-V2X. Europe never ran that transition.

Read the message schemas and the service identifiers instead, and the split becomes harder to locate. One field is literally shared. Several supposed contrasts turn out to sit at a different level than the usual summary puts them. What does differ is specific, and it shows up in how many fields a sender is obliged to fill and in what each corpus is willing to say about its own uncertainty.

One number space, spent before cooperative ITS existed

TS 102 860 exists to manage ITS application identifiers, and its introduction reads as a genealogy. CEN TC 278 published EN 12834 in 2002 with a DSRC application class identifier of ASN.1 type DSRCApplicationEntityID, allocating 16 classes, of which the two most prominent on the market were 0 for “System” and 1 for “Electronic Fee Collection”. ISO TC 204 WG 15 mirrored the work in ISO 15628 and allocated three more. The ServiceID of ISO 29281 then, in the words of the document, “recognizes the work done so far at CEN TC278 WG9 and ISO TC204 WG15, adopting the already allocated numbers”.

The WAVE standards joined that lineage. The same clause records that the IEEE work of 2006 “maintained and continued DSRCApplicationEntityID of ISO TC204 WG15”, identifying services through a Provider Service Identifier. Four years later the two bodies merged the definitions outright:

In 2010, the original definition of PSID was revised by IEEE 1609 WG in cooperation with ETSI TC ITS STF 404 such that the PSID field contains the ITS Application Identifier (ITS-AID) applying unaligned PER as specified in the present document.

So the numbering is one space with two names, and the oldest allocations bind both. Clause 4.2.3 states the consequence plainly, that for new assignments “these values in the range of 0 to 31 already assigned by CEN and ISO are no more available”. A tolling standard from 2002 reserved the cheapest end of an identifier space that a WAVE station reads today.

The registry bears it out. TS 102 965 holds every ITS-AID assigned to ETSI ITS, and the lowest is 36, requested in January 2015 for the cooperative awareness service. Collective perception holds 639 and vulnerable road user awareness 638, both two octets, both applied for in January 2020. Automated vehicle marshalling got 71 in April 2024, a one-octet value that happened to still be free nine years after the first batch.

Two numbers to deliver a message, or one

Shared numbering does not mean shared plumbing, and this is where a real difference sits. A European station needs two independent values to handle an incoming message, and they live in separate registries maintained in separate documents.

The port side is settled by TS 103 248, whose Table 1 gives 2001 to cooperative awareness and 2009 to collective perception. The authorisation side is the appPermissions field of the certificate, a sequence of PsidSsp where Psid ::= INTEGER (0..MAX) holds the ITS-AID. The full census of what travels on which port has its own post; the point here is that the port carries no authorisation meaning and the ITS-AID carries no routing meaning, so the two can drift apart in an implementation without either value looking wrong.

A WAVE station reads the PSID from the WSM header and finds the same value in the certificate. Clause 8.1.4 of IEEE Std 1609.3-2016 requires the p-encoded form of IEEE Std 1609.12 everywhere the identifier appears, which is the variable-length encoding that keeps the low allocations cheap. Coupling the two roles removes a failure mode and removes a degree of freedom with it.

Where each body put the flexibility

The familiar claim is that the American safety message is rigid and the European one extensible. Counted at the level of the periodic payload, neither is extensible, and the real difference is how much a sender is obliged to say.

BSMcoreData is 14 fields with no OPTIONAL among them and no extension marker. A transmitter populates the count, the temporary identifier, the sub-second mark, latitude, longitude, elevation, positional accuracy, transmission state, speed, heading, steering wheel angle, a four-way acceleration set, brake status and vehicle size, every time. The type lives in the shared J2735-Common module, so the intersection-collision and cooperative-control messages reuse the same block.

The CAM high-frequency container is 16 fields, 7 of them optional, and it also has no extension marker. Nine values are obligatory and the rest, including steering wheel angle, lateral and vertical acceleration and the performance class, are at the sender’s discretion.

Extensibility in both cases sits one level up, through different ASN.1 machinery. BasicSafetyMessage wraps the core block with an optional partII sequence whose members are selected by an Information Object Class, with PartII-Id ::= INTEGER (0..63) and three identifiers registered so far, plus a regional extension and a trailing marker. CamParameters wraps its containers with a marker and a WrappedExtensionContainers field already added after it. The European high-frequency slot is itself a CHOICE with a marker, which is how the roadside variant coexists with the vehicle one, since a CAM from infrastructure selects rsuContainerHighFrequency, and the BSM schema has no corresponding branch at all.

The perceived object, defined twice

Collective perception is the pair least often compared, and the one where the two corpora came closest before separating. SAE J3224 carries a sensor data sharing message that does what the CPM of TS 103 324 does, and both describe detected objects relative to the sender.

The structural choice differs first. Europe put PerceivedObject in the Common Data Dictionary, where any service can import it, and the collective perception module does exactly that. J3224 defines DetectedObjectCommonData inside the message module.

	CPM PerceivedObject	SDSM DetectedObjectCommonData
Defined in	Common Data Dictionary	the message module
Fields	16	18
Mandatory	2	11
Extension marker	yes	yes
Measurement offset	-2048 to 2047 ms	-1500 to 1500 ms
Confidence on that offset	none	mandatory, 40-level enumeration

Two mandatory fields against eleven is the same bet as the one in the periodic messages, reappearing in a service standardised two decades later. A European sender must supply the measurement time and the position; everything else, dimensions, classification, velocity, object age, perception quality, may be absent. An American sender owes type and classification confidence, object identifier, measurement time and its confidence, position and position confidence, speed and speed confidence, heading and heading confidence.

The last row is the one with consequences. MeasurementTimeOffset of -1500 to 1500 ms is the range the earlier European study TR 103 562 used, so the two bodies agreed on that range once. The published European service then took DeltaTimeMilliSecondSigned from the dictionary and inherited -2048 to 2047. That shift, and the change of anchor instant that came with it, is the subject of a separate post.

Alongside the offset, J3224 makes timeConfidence mandatory, drawing on a TimeConfidence enumeration of 40 levels that runs from “unavailable” down past one nanosecond to ten picoseconds, a precision no road message will ever carry and a sign of how generic the dictionary it came from was. The European dictionary defines 24 confidence types, for position, altitude, speed, heading, curvature, yaw rate, steering wheel angle, object dimension, lane position, trajectory interception and more. None of them applies to time. Every kinematic component of a perceived object can state how well it is known, and the instant that dates all of them cannot.

What each corpus drags

Both bodies have been standardising long enough to carry fossils, and the way each carries them is visible in the schema.

The American corpus marks dead fields in place. EmergencyDetails opens with a field named doNotUse whose comment explains that it is “always set to 0 and carries no meaning; legacy field maintained for backward compatibility”. SupplementalVehicleExtensions holds five more of them, numbered doNotUse1 through doNotUse5, retiring a weather report, a weather probe, obstacle detection, a speed profile and a raw GNSS package. The weather report is the one that imported EssPrecipRate, EssSolarRadiation and EssMobileFriction from the roadside equipment dictionary of NTCIP, so the much-cited route from infrastructure telemetry into the vehicle safety message exists and has been closed. ITIScodes, from the phrase list of J2540, stays live and in use for event and hazard descriptions.

The European corpus removes less and hides it better. CenDsrcTollingZone sits at the end of the CAM high-frequency container as an optional field, which puts a tolling-zone notification inside the periodic safety message, carrying the same EN 12834 lineage.

Neither habit is an accident. A corpus whose core block has no extension marker and whose decoders have been in the field for 20 years cannot delete a field without breaking them, so it keeps the slot and labels it. A corpus with wrapped, versioned containers can let an old field decay in place inside an optional one. The fossils are a readout of the extensibility choice two sections up, visible years later.

Read it yourself

The genealogy of the identifier is four paragraphs of TS 102 860, and the assignment list is Table A.1 of TS 102 965. The European schemas are on the ETSI forge with a tag per version, which is where the ASN.1 annexes moved to and the only citable source for a type definition. The Common Data Dictionary holds PerceivedObject and the confidence types, and the CAM module holds the high-frequency container. On the American side the identifier encoding is clause 8.1.4 of IEEE Std 1609.3-2016, the certificate permission types are in IEEE Std 1609.2, and BSMcoreData and DetectedObjectCommonData are in the J2735-Common and J3224 modules of SAE J2735 SEP2024, which is sold under licence. For the credential frameworks that sit under all of this, the OpenSCMS and 1609.2.1 comparison maps the roles against the European ones, and the Release 1 to Release 2 map places the European documents in order.