measurementDeltaTime: the age of every object in a CPM

The last note was about where. This one is about when.

An object a CPM hands you is a measurement of the road as it was, some milliseconds ago. A car measured 200 ms ago while closing on you at 15 m/s has closed the gap by three metres by the time you read the message. Draw it where the coordinates say and you have drawn the past. The CPM declares how far in the past. That field is easy to ignore, and a value of zero is ambiguous.

Every object carries its own age

There is one clock in a CPM. The management container holds a reference time, a TimestampIts counting TAI milliseconds since 2004. Every CPM of one generation event carries the same value. Positions are measured against it, and so is time.

Each perceived object declares its own measurementDeltaTime, a mandatory signed value from −2048 to 2047 ms. It gives the gap between that shared reference time and the instant the object’s state was measured. A negative value, the ordinary case, means the state is from before the reference. That convention lives in the Common Data Dictionary, TS 102 894-2, in the field description of measurementDeltaTime, and not in the service specification.

The field is per-object, and that is the part worth holding on to. Two objects in the same message can be dated hundreds of milliseconds apart, each stamped with when its own sensor last saw it.

The specification says what the number contains. It shall include any processing time of a sensor or data-fusion system (clause 7.1.8.2). That figure excludes transmission delay. It is the object’s real age at the point the message was built, measurement pipeline and all.

Other things in a CPM carry a date too. A Perception Region shall include its own measurementDeltaTime, same field and same type, and a perception region is how a CPM asserts that a stretch of road is unoccupied. A stale object is one wrong observation. A stale perception region asserts that an area holds nothing worth avoiding, and there is no object downstream for a plausibility check to catch.

Where the age comes from

That pipeline is where the age accumulates. A perceived object is not read straight off a sensor; it is the output of a chain, and every link adds latency.

Raw sensor data goes into low-level fusion, then into a high-level fusion stage that predicts each track forward to a common time, associates it with new detections, and merges them. TR 103 562 lays this out. A sender that ships already-fused objects hands the receiver a track to fuse again, stacking a second filter on the first. The report calls these filter cascades. It also notes that redundancy-mitigation rules hold an object back until re-sending it pays, which adds more age before the object ever reaches the air. On top of that, Annex F sets default generation intervals of 100 ms to 1 s, with 50 ms recommended for some roadside cases. The object you receive can be old in a way no single link explains.

The standard also allows prediction, which pulls the other way. Clause 6.1.2.3 lets a sender predict Type-B objects to the next generation event and, if the prediction says they would need sending then, include them now. What travels is “the latest available kinematic and attitude state”. This is where an implementation slips. The prediction decides whether the object is included, and never becomes the payload. Ship the predicted state instead, with a delta still computed against the old measurement, and every such object arrives mis-dated.

Read the timestamp, or read the past

This is manageable because the sender declares when it measured. The asymmetry is stark. Every kinematic component in a CPM shall carry a 95 % confidence, and the timestamp that dates all of them carries none. If the sender stamps measurementDeltaTime honestly, the receiver can add it to the reference time, find the true moment of measurement, and predict the object forward to now before acting on it. The age becomes a number you correct for, and stops being an error you inherit.

Skip it, or leave the field at zero because the pipeline never measured it, and the object simply appears at the reference time it was never at. Every consumer downstream then reasons about a stale position, and at road speeds a fraction of a second separates a clear lane from a collision warning. The timestamp is half of what makes the position usable.

Three deltas that do not mean what they say

A near-zero delta looks like a station with a fast pipeline. Three different situations produce one, and the receiver cannot tell them apart.

1. The sender never measured. The field is mandatory and the type carries no unavailable code. A pipeline that never measured its own latency emits 0, a legal and plausible value.
2. The sender predicted honestly. A station that follows the fusion rule and predicts its tracks to the reference time reports a delta near zero, and it is right to. The age has not gone anywhere. It has turned into prediction error, and no CPM field carries that.
3. The pipeline really is fast. The small value is genuine, and it looks exactly like the other two.

A fourth value is not a zero at all. DeltaTimeMilliSecondSigned clips. -2048 covers everything at or before −2048 ms, 2047 everything past 2046 ms. An object occluded for four seconds encodes like one occluded for 2.1 s, with no overflow flag. That leaves a receiver with two separate rules. Read a delta at either endpoint as unbounded age, and never read a zero as evidence of a synchronous pipeline.

The standard knows the field cannot be audited from inside the message. Clause 5.2 lists “optionally, checking the validity of the information of received CPMs” among the reception sub-functions and points, in a note, at TR 103 460 for the details. That study builds its use cases on CAM and DENM, covering plausibility checks on access-layer measurements and on periodic broadcasts, local security checks, and misbehaviour detection on DENM. None of them is a detector for a declared measurement age.

What the correction assumes

Adding the delta to the reference time and predicting forward is the right move, and it depends on two assumptions.

The first is a shared clock. The reference time is written on the sender’s clock and “now” is read on yours, so the correction is only as good as the offset between them. TS 103 324 does not specify time management itself; it delegates to EN 302 890-2 (PoTi), a normative reference. Under GNSS holdover the delta stays honest while the reference drifts, and your correction becomes a systematic offset applied in the same direction to every object from that station. Every object it sends then carries the same position error, which no per-object plausibility check will flag.

The second is the uncertainty. Moving a state forward without inflating its covariance is not a correction. The confidences and correlation matrices of clause 7.1.8.3 describe the state at the instant of measurement. The standard specifies no process-noise model. A track propagated with its original covariance ends up in roughly the right place, with a covariance that is unrealistically small for where it now claims to be. Two receivers correcting the same CPM will disagree about how much to trust the result. It is also how filter cascades do their damage, by weighting a remote observation more than it has earned.

Two ages, and a sign that flips

The message carries two different notions of age, and they are easy to confuse. measurementDeltaTime is the age of this measurement. It turns positive only when the sender chooses to predict the state to an instant later than the reference time. Clause 7.1.8.2 provides for that: for fused state, the time of measurement shall reference the instant the state was predicted to. It requires no polarity, and in practice the fused case lands before the reference. A positive delta means you are holding somebody else’s forecast. objectAge measures something else. It is optional, runs 0 to 2047 ms, and says how long the track has existed since it was first detected, feeding the object’s perception-quality score. Its scale stops early. The CDD gives 1500 the meaning “observed for more than 1.5s”, and the perception-quality rating of clause 7.1.8.6 stops moving at that same value. That leaves 1501 to 2047 encodable and undefined. The two texts also anchor it differently, the TS to the time of message generation and the CDD to the reference time of the message. Usually the same instant, though neither text guarantees it.

That lifetime resets more often than the wording suggests. On a pseudonym change the sender shall report every detected object as newly detected and shall replace all object identifiers, so objectAge restarts for tracks it has been following for minutes. A receiver feeding objectAge into a trust score watches every object from that station become new at once.

TS 103 324 and TR 103 562 also disagree on the sign, which is what catches anyone porting code between them. TR 103 562 is a Technical Report, listed by TS 103 324 as an informative reference, but several open-source stacks were written against its ASN.1 and inherited its convention. Same idea, opposite polarity, and against a different clock.

	TS 103 324	TR 103 562
Field	measurementDeltaTime	timeOfMeasurement
Range	−2048 to 2047 ms	−1500 to 1500 ms
A negative value is	before the reference time	after the generation time
Anchored to	referenceTime	generationDeltaTime
Status	Release 2 specification	Technical Report

The sign is the visible half. Flip it correctly and every object stays mis-dated by whatever elapsed between the two anchors. The TR ties generationDeltaTime to “the latest disseminating ITS-S position update”, an instant of its own that no sign check will reconcile with the management container.

Read it yourself

The timing model is in TS 103 324 V2.1.1: object time management in clause 7.1.8.2, objectAge in clause 7.1.8.4, its use in perception quality in clause 7.1.8.6, and the DeltaTimeMilliSecondSigned and TimestampIts types in the Common Data Dictionary, TS 102 894-2 V2.1.1. For the pipeline and its filter cascades, TR 103 562 clause 4.2 and its terminology are the source. This closes a short arc on one message: why it exists, the coordinate frame it reports in, and now the clock it reports against. All three sit inside the wider version crossing charted in the Release 1 to Release 2 map.