GNSS and time synchronisation in V2X — position, timing and trust.
A V2X message is a claim about where a vehicle was and when. Satellite positioning — a global navigation satellite system, or GNSS — supplies both halves of that claim, and in Cellular Vehicle-to-Everything (C-V2X) it also supplies the timing the PC5 radio needs to share the channel at all.
This guide stays at the standards level: what a GNSS receiver provides, which clocks have to agree, how 3GPP sidelink synchronisation falls back when satellites are lost, how SAE J2735 and ETSI messages carry time and confidence, why IEEE 1609.2 security depends on time without GNSS being a security guarantee, and how to test all of it.
Every V2X message is a claim about where and when.
A Basic Safety Message or a Cooperative Awareness Message says, in effect, this vehicle was here, moving this way, at this instant. A receiver uses that to decide whether a threat is real: it projects the sender's path against its own, and it needs both positions to be expressed in the same frame and both instants on the same clock. A position that is two seconds old at highway speed is more than fifty metres stale. A timestamp that disagrees with the receiver's clock by the same two seconds makes the same message look either fresh or expired depending on the direction of the error.
C-V2X adds a third dependency that DSRC does not have. The PC5 sidelink divides the channel into subframes and sub-channels, and devices choose transmission resources by sensing which ones their neighbours are using. That only works if every device agrees where each subframe starts. Satellite time is the usual common reference, so in C-V2X the radio itself depends on GNSS time, not only the application. How that compares with 802.11p.
| Dependency | What uses it | What goes wrong without it |
|---|---|---|
| Position | The message payload; the receiver's threat assessment; geographic relevance checks | Warnings for the wrong lane, the wrong approach or a vehicle that is not there |
| Time of the measurement | Message timestamps; path history and prediction; ordering of received messages | A receiver cannot tell how old the state it is acting on actually is |
| Radio timing | PC5 subframe alignment and sensing-based resource selection | Transmissions straddle subframe boundaries, interference rises and reception falls for everyone nearby |
| Security time | Signed-message generation time; certificate validity periods; replay checks | Valid messages rejected, or expired and replayed ones accepted |
Four outputs, and the quality figures that come with them.
- Position — latitude, longitude and height, with an estimate of its own uncertainty. The uncertainty matters as much as the fix: it is what the message's confidence fields are filled from.
- Velocity and heading — from a single-antenna receiver, heading is derived from motion over ground, which means it degrades as the vehicle slows and is meaningless when it is stationary.
- Time — the receiver solves for its own clock offset as part of every fix, so it knows GNSS system time and can report UTC, applying the current leap-second offset that the satellites broadcast.
- A timing pulse — most receivers can output a pulse, typically once per second, whose edge marks the top of a second. Software reads which second from the receiver's messages; the pulse says exactly when it began. Together they are what a host uses to discipline its system clock far more tightly than message timestamps alone allow.
Two cautions recur in every integration. A receiver's quoted accuracy is a figure for stated conditions — open sky, a given signal level, a stated statistic such as CEP 50% — and not a moving-vehicle result in a city. And time is only as good as the path that carries it into the host: a precise pulse that reaches the operating system through a loaded USB serial link can arrive late and late by a varying amount.
Three clocks that must agree, and one that must not drift.
| Clock | Synchronised to | Defined or used by |
|---|---|---|
| PC5 sidelink timing | A synchronisation reference: GNSS, a base station, or another device acting as a synchronisation reference | 3GPP TS 36.331 (configuration and reference selection), TS 36.211 (sidelink synchronisation signals and broadcast channel), TS 36.213 (sidelink procedures) |
| Host system clock | Normally GNSS time via the receiver's messages and timing pulse | The operating system and every process that stamps a message or checks a certificate |
| Message timestamps | The host clock, at the instant the reported state was valid | SAE J2735 secMark; ETSI generationDeltaTime; IEEE 1609.2 generationTime |
| Security time base | The same host clock | IEEE 1609.2 and ETSI TS 103 097 generation-time and certificate-validity checks |
Sidelink synchronisation in 3GPP Release 14 and 15. LTE-V2X made GNSS a first-class synchronisation reference for the sidelink. A device that receives GNSS reliably can take its sidelink frame and subframe timing directly from UTC, with no network involved. A device that cannot — in a tunnel, a car park, a dense canyon — can instead synchronise to another device that transmits sidelink synchronisation signals because it is itself synchronised, directly or through a chain, to GNSS. Where a network is present it can configure whether GNSS or the base station takes priority as the reference. The candidate ordering and the selection procedure are specified in TS 36.331; the physical synchronisation signals and the sidelink broadcast channel that carry the reference are in TS 36.211. Release 15 enhanced LTE-V2X in other respects and kept this synchronisation framework.
The point to carry away: a C-V2X device out of GNSS coverage is not necessarily off the air, but it has become dependent on its neighbours' timing, and it inherits whatever errors they carry.
When the state was true, not when the packet left.
Both message families timestamp the state, and both carry the position's uncertainty alongside the position. The message sets in full.
| Field | Message | What it means |
|---|---|---|
secMark | SAE J2735 BSM core data | Milliseconds within the current UTC minute; values above 59,999 cover a leap second. The receiver reconstructs the full time from its own clock, which only works if the two clocks agree |
| Positional accuracy | SAE J2735 BSM core data | An error ellipse — semi-major and semi-minor axes and orientation — for the reported position |
generationDeltaTime | ETSI CAM, EN 302 637-2 | The time of the reference position, as milliseconds since the start of 2004 taken modulo 65,536 — again only meaningful against a synchronised receiver clock |
| Position confidence ellipse, heading and speed confidence | ETSI CAM | The sender's own statement of how far to trust each value |
generationTime | IEEE 1609.2 / ETSI TS 103 097 signed data header | A 64-bit microsecond timestamp inside the signed envelope, so it cannot be altered without breaking the signature |
The implication for message generation is direct. Stamp the message when the GNSS solution was valid, not when the application got round to building it, and fill the confidence fields from the receiver's own error estimate rather than a constant. A sender that reports a tight ellipse it does not have is giving every receiver a reason to act on bad data — and giving misbehaviour detection a reason to distrust it.
A valid signature on a lie about time is still a valid signature.
V2X message security under IEEE 1609.2 and its European profile ETSI TS 103 097 leans on time in three places. The signed header carries the generation time. Every certificate has a validity period, and a receiver must decide whether the signer's certificate was valid at that generation time. And relevance and replay checks compare the generation time against the receiver's own clock to reject messages that are too old, too far in the future, or seen before.
Every one of those checks trusts the receiver's clock, and on a vehicle that clock usually comes from GNSS. So:
- GNSS time is an input to security, not a security mechanism. Open-service GNSS signals are not authenticated by default, so a receiver can be spoofed into a false position or a false time, or jammed into having neither. Signal authentication services where available, multi-constellation cross-checks and detection features in the receiver reduce the risk; none removes it.
- A shifted clock fails both ways. Pushed forward, a station can reject current certificates and fresh messages; pushed back, it can accept a recorded message or an expired certificate. Bounding how fast the system clock is allowed to move, and refusing a GNSS time that disagrees sharply with the free-running clock, are common defences.
- Authentication is not truthfulness. A correctly signed message from a spoofed sender carries a false position under a valid signature. That is the gap misbehaviour detection exists to close.
Degrade honestly: keep timing, widen the error, say so in the message.
| Mechanism | What it does | What it does not do |
|---|---|---|
| Synchronisation-source fallback | Moves the sidelink to a base station or a synchronised neighbouring device, per the 3GPP reference-selection rules | Provide position, or guarantee a reference exists — an isolated device with no GNSS has none |
| Clock holdover | Keeps the local oscillator running on its last disciplined frequency so time stays usable for a while | Stay accurate indefinitely; drift grows with time and temperature, at a rate set by the oscillator, not by the standard |
| Dead reckoning | Propagates position from the last fix using inertial and wheel-speed data | Stay bounded — error grows with distance and time, and it needs a validated fusion engine, not just the sensors |
| Confidence fields | Let the sender report the growing uncertainty so receivers can weigh it | Help if the sender does not update them as the solution degrades |
Profiles differ on what a station should do when the position is no longer good enough — stop transmitting, or continue for a bounded period with the degraded state labelled as such. Which applies is a deployment-profile decision, and it should be written down before the first field test rather than discovered during it.
The vehicle measures where it is. The roadside unit is told.
| On-board unit (moving) | Roadside unit (fixed) | |
|---|---|---|
| Position source | Live GNSS solution, possibly fused with inertial and vehicle data | Usually a surveyed installation position, configured at commissioning; MAP geometry is referenced to it |
| Time source | GNSS, with the sidelink fallbacks above | GNSS, ideally with a clear sky view chosen at installation; may also take network time for its backhaul |
| Main GNSS risk | Multipath, tunnels and canyons, high dynamics | Long-term exposure to jamming or spoofing at a known location, and a configured position that is wrong |
| Why it matters | Its own messages and its threat assessment | Its signal timing messages and, where it acts as a sidelink synchronisation reference, the timing nearby devices fall back on |
Test the failure, not just the fix.
- GNSS simulation. A constellation simulator feeds a receiver a scripted sky — a route, a tunnel, a loss of satellites — so the same scenario can be repeated exactly.
- Record and replay. Recording real signals or receiver output on a drive and replaying it against the stack separates receiver behaviour from application behaviour.
- Time-offset injection. Deliberately offsetting one station's clock, by milliseconds and by hours, shows whether timestamps, sidelink reception, generation-time checks and certificate validity behave as the profile intends.
- Outage and recovery. Remove GNSS for a defined interval and confirm the confidence fields widen, the fallback engages and the recovery does not step the clock in a way that breaks security checks.
- Leap seconds and epochs. Check the handling at a minute boundary and across a leap-second insertion; several fields count from an epoch and wrap.
For where these fit in a test programme, see test and certification and developer tools.
What is published, and what is not yet.
Both AmbiOBU and AmbiRSU pair a 5.9 GHz C-V2X PC5 subsystem at 3GPP Release 14 with a u-blox MAX-M10S GNSS receiver: a u-blox M10 standard-precision module receiving GPS/QZSS, Galileo, GLONASS and BeiDou on their L1-band signals, which produces position, velocity, heading and time. u-blox lists RF interference and jamming detection and spoofing detection and reporting among the module's features — detection and reporting, not immunity. The positioning baseline has no RTK and no dead-reckoning or GNSS/inertial fusion engine.
Maturity, stated plainly. How the PC5 subsystem selects its synchronisation reference, how receiver time reaches the system clock and the message timestamps, and how either platform behaves through a GNSS outage are not published, and no timing, synchronisation or holdover performance is claimed for either. That integration has not yet been evidenced with a live receiver attached. Both platforms are development platforms: not certified, not homologated and not type-approved, and no environmental qualification is claimed for the standard configurations.
The documents this page rests on.
Publisher pages and archives. Some documents are paywalled; the identifiers are stable either way. What to read, and what it costs →
- 3GPP TS 36.331 — E-UTRA RRC: sidelink synchronisation configuration and reference selection, including GNSS.
- 3GPP TS 36.211 — E-UTRA physical channels: the sidelink synchronisation signals and broadcast channel.
- 3GPP TS 36.213 — E-UTRA physical layer procedures, including sidelink.
- IEEE 1609.2 — security services: signed-data header, generation time, certificate validity.
- ETSI TS 103 097 — the European security header and certificate profile of IEEE 1609.2.
- SAE J2735 — message set dictionary: BSM core data,
secMark, positional accuracy. - ETSI EN 302 637-2 — Cooperative Awareness basic service:
generationDeltaTimeand reference-position confidence.
Questions this page answers.
Why does C-V2X need GNSS time?
Because the PC5 sidelink shares the channel by dividing it into subframes and letting each device pick resources its neighbours are not using. That only works if every device agrees where each subframe starts, and GNSS time is the usual common reference. 3GPP also allows a base station, or a neighbouring device that is itself synchronised, to act as the reference when GNSS is unavailable.
What happens to a C-V2X device in a tunnel?
It loses its direct GNSS reference and can synchronise to another device that transmits sidelink synchronisation signals, or to a base station if one is configured as the reference. Its position is a separate problem: without GNSS it needs dead reckoning, and it should report the growing uncertainty in its messages' confidence fields.
Is GNSS time secure enough for V2X security checks?
Not on its own. IEEE 1609.2 generation-time, certificate-validity and replay checks all trust the receiver's clock, and open-service GNSS can be spoofed or jammed. Receiver-level detection, signal authentication where available, multi-constellation cross-checks and limits on how fast the system clock may move reduce the risk; none of them makes GNSS a security guarantee.
Which message fields carry time and position quality?
In SAE J2735, the BSM core data carries secMark, milliseconds within the UTC minute, and a positional-accuracy ellipse. In ETSI, the CAM carries generationDeltaTime and confidence values for position, heading and speed. The IEEE 1609.2 signed envelope adds its own generationTime.
Do AmbiOBU and AmbiRSU publish GNSS timing performance?
No. Both carry a u-blox MAX-M10S standard-precision GNSS receiver alongside a 5.9 GHz C-V2X PC5 subsystem, but no timing, synchronisation or holdover performance is published or claimed for either platform, and neither has a dead-reckoning engine in its baseline. What is published, and what is not.
Last updated 2026-10-01 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: v2x@ambimat.com