Time Synchronization

Time Synchronization
News & Tutorials from Meinberg
  • PTP / IEEE 1588
  • NTP
  • Configuration Guidelines
  • Industry Applications
  • Security
Home » Industry Applications » GNSS as a Time Transfer System – The Global Timing Backbone

GNSS as a Time Transfer System – The Global Timing Backbone

November 10, 2025 by Sani Sarcevic Leave a Comment

Global Navigation Satellite Systems (GNSS) are widely recognised for enabling positioning and navigation. But did you know that GNSS, in fact, transmits the time, while your location is actually calculated based on it? One of their most critical functions is precision time distribution. Over the past three decades, GNSS systems have become the primary global infrastructure for disseminating accurate time, superseding other methods for most civilian users. Precise and traceable time dissemination is essential in telecommunications, power grids, finance, UTC realisation, and national defence. Today, GNSS is used not only for navigation but also as a globally available time transfer system.
Before proceeding, it is important to clarify a common terminology issue: UTC ≠ GNSS ≠ GPS.

As discussed in the previous post, the international reference timescale is UTC. GPS and other GNSS system times are sometimes conflated with UTC. However, these systems are not a source of time, but rather a method for UTC dissemination. This distinction is critical in applications requiring traceability to UTC. Almost all commercial applications use UTC as a timescale, not GPS.
There are four main GNSS constellations with global coverage: Galileo (European), GPS (United States), GLONASS (Russia) and BeiDou (China). Another common confusion: the correct term for all of these systems is GNSS, while GPS is just one representative of these systems. While each of them has its specifics, here is the overview of common key segments.

Space Segment

GNSS constellations operate satellites in Medium Earth Orbit (MEO), typically at altitudes between 19,000 km and 23,500 km. Onboard atomic clocks provide precise timing, with satellites continuously broadcasting navigation messages containing timing and orbital data. These clocks are steered towards the reference time of the corresponding GNSS. The following table summarises the space segment, including the number of satellites, orbital altitude, onboard clocks, and the time reference for each constellation.

ConstellationNumber of Satellites (2025)Orbit AltitudeClocks OnboardSystem Time Scale
GPS≈ 31 operational~20,180 km [1],[3]Rb, some CsGPS Time (steered to UTC(USNO))
Galileo≈ 28 operational~23,222 km [2],[4]PHM + RbGST (steered to multiple EU UTC(k))
GLONASS≈ 23 active~19,100 km [6]Rb + CsGLONASS Time (steered to UTC(SU))
BeiDou≈ 45 satellites~21,500 km [7]RbBDT (steered to UTC(CN))

As can be seen, GPS, GLONASS, and BeiDou primarily rely on Rubidium atomic clocks, with their system times steered to the respective national UTC realisations maintained by the owner countries. Galileo is the only fully civilian GNSS, owned and operated by the European Union. Its satellites are equipped with highly stable Passive Hydrogen Masers (PHM), and the system timescale is steered toward UTC through comparisons with several European National Metrology Institutes (NMIs). Typically, all four constellations tend to align their system time within <10 ns with respect to UTC, but without guarantee. The actual relations of UTC with the predictions of GNSS broadcast are available in the BIPM’s Circular-T report [8].

See also  GNSS Spoofing and how to mitigate it

Ground Segment & Time Scales

An earth-based ground segment of GNSS is responsible for: monitoring satellite clocks, estimating and predicting clock drift, steering the system timescale, uplink of navigation message and clock correction parameters. Each GNSS constellation maintains its own timescale, tied to or steered toward a national UTC(k) or combination of several UTC(k).

SystemTime ScaleReference time
GPSGPS TimeSteered to UTC(USNO), US
GalileoGalileo System TimeSteered to multiple UTC(k): PTB (Germany), OP (France), NPL (UK)
GLONASSGLONASS TimeSteered to UTC(SU), Russia
BeiDouBeiDou Time (BDT)Steered to UTC(CN), China

The ground segment tracks satellite signals using dozens of globally distributed monitoring stations. Clock phase differences are estimated and corrections uploaded to each satellite, ensuring coherence between the space and ground segments.

Galileo System Time (GST) is generated at two Ground Control Centres (Oberpfaffenhofen, Germany and Fucino, Italy). GST is continuously compared to UTC realisations from PTB, OP, and NPL, then steered to maintain GST close to UTC. Regular offset parameters are broadcast in Galileo navigation messages. GPS, conversely, steers GPS Time to UTC(USNO), publishing the current offset to UTC in the ICD-SPS broadcast.

Receiver – calculating time and position

A GNSS receiver tracks signals from multiple satellites, extracting the navigation message and raw measurements. The travel time of the signal from the satellite to the receiver is used to calculate a “pseudorange,” which is a raw estimate of the distance to the satellite. To determine a receiver’s PVT solution (Position, Velocity, Time), four primary unknowns must be solved for: the 3D position (latitude, longitude, and altitude) and the receiver’s clock bias. A minimum of four satellites is required to create enough equations to solve for these four unknowns and provide a PVT solution. Least-squares (LSQ) algorithms or Kalman filters are commonly used by GNSS chipsets to process the pseudorange data.

The following information is the result of this calculation:

  • Time – The difference between the receiver’s internal clock and the time of the GNSS constellation (clock bias) is used to synchronise the receiver’s clock
  • Position – The receiver’s location in 3D space
  • Velocity – The receiver’s speed and direction of movement, derived from the Doppler shift of the satellite signals.

Signal Propagation & Timing Error Sources

As GNSS signals travel from satellites in MEO orbit to receivers on the Earth’s surface, they are subject to a variety of error sources that directly affect timing accuracy. When time transfer is required at the nanosecond level, understanding and mitigating these effects is essential.

The measured pseudorange P at a GNSS receiver can be expressed as:

P = ρ + c · (δt_rx – δt_sv) + I + T + M + ε

where:

  • ρ = geometric distance between satellite and receiver
  • c = speed of light
  • δt_rx = receiver clock offset to the respective satellite
  • δt_sv = satellite clock offset to the respective GNSS system time
  • I = ionospheric delay
  • T = tropospheric delay
  • M = multipath error (signal reflections)
  • ε = measurement noise and other residual errors
See also  HSR and PRP: redundant Layer 2 networks

The following table summarises the main error sources and their typical magnitudes in timing applications:

Error SourceDescriptionTypical MagnitudeMitigation
Ionospheric delayFrequency-dependent delay due to free electrons in the ionosphereUp to 10–50 nsDual-frequency ionosphere-free combinations, ionospheric models
Tropospheric delayNon-dispersive delay caused by neutral atmosphere2–15 nsModeling , real-time meteorological data
MultipathReflections from nearby surfaces alter path length<5 ns but environment-dependentAntenna design, site selection, multipath-resistant processing
Satellite clock errorResidual offset after onboard clock correction<2 ns (after broadcast corrections)Precise clock products, monitoring
Ephemeris/orbit errorInaccuracies in satellite orbit data<5 nsPrecise ephemerides (IGS)
Receiver noiseThermal and hardware-induced noise<1 nsHigh-quality oscillators, advanced tracking loops

Accurate GNSS-based time transfer critically depends on the precise calibration of all delays along the signal path. These include receiver internal delays, antenna delays, and signal propagation time through connecting cables. A typical 50 Ω coaxial cable introduces a delay of about 4–5 ns per meter, depending on the cable type and its velocity factor (the ratio of signal speed in the cable to the speed of light). Uncalibrated receivers can introduce additional error of several tens to several hundred ns. Therefore, proper calibration is crucial to achieve the accuracy stated here.

Time Transfer Techniques

GNSS enables both: one-way time dissemination to end applications and scientific-grade clock comparison between distant clocks. End-user real-time UTC estimation depends on receiver design, number of constellations, number of frequencies, antenna location, local oscillator quality, and calibration of delays.

When used to receive timing information in real-time applications, calibrated stand-alone GNSS timing receivers usually achieve 10–20 ns (1σ) uncertainty when dual-frequency and multi-constellation signals are used. When combined with post-processing techniques (e.g., precise point positioning, PPP) or real-time correction services, they can reduce these errors significantly, and even reach sub-nanosecond performance in controlled conditions.

Receiver ConfigurationTypical Time UncertaintyReferences
Single-frequency GPS L1 only100–200 ns[5]
Dual-frequency GPS30–50 ns[5]
Multi-constellation dual-frequency (GPS+Galileo)10–30 ns[5], [4]
PPP post-processed or real-time corrected<1 ns[9], [3]

Except for receiving timing information, one of the most powerful applications of GNSS is enabling comparisons between distant atomic clocks, separated by hundreds or even thousands of kilometres. By observing signals from the satellites, laboratories can compare their local realisations of UTC with several nanoseconds of precision. The most established time transfer methods include the common-view technique, the all-in-view approach, and more advanced strategies such as precise point positioning (PPP). Their characteristics are summarised in the following table.

MethodPrincipleTypical AccuracyNotes
Common-View (CV)Both stations observe the same satellite simultaneously; subtracting satellite clock error yields receiver clock offset≤ 10 ns (1σ) with dual-frequency GPS (L1+L2) [11]Requires simultaneous visibility of the same satellite
All-in-View (AIV)Each station uses all satellites in view, averaging minimise multipath and noise~1 ns Allan deviation over long averaging times (post-processed) [11]More robust than CV; improved coverage and stability
Precise Point Positioning (PPP)Uses precise orbit and clock products (e.g., from IGS) in post-processingSub-nanosecond accuracy over long averaging times [12]The current BIPM standard for TAI links, requires external correction products

Jamming, Spoofing, and Mitigation

Despite their precision and global reach, GNSS signals are inherently weak when they arrive at the Earth’s surface — typically around -130 dBm. This makes them highly susceptible to intentional or unintentional interference. Two of the most critical threats are jamming and spoofing.

See also  Performance Level Options for the Meinberg HPS100 card

Jamming occurs when a stronger signal in the GNSS frequency band overwhelms the legitimate satellite signals, rendering them unusable. This can be caused by intentional attacks with low-cost radio frequency transmitters, military actions, or unintentionally by malfunctioning electronics and nearby communication equipment. Even short-duration jamming can result in a complete loss of synchronisation in time-critical systems.

Spoofing is a more sophisticated threat in which counterfeit GNSS signals are broadcast to mislead the receiver into computing false time or position solutions. Unlike jamming, which causes denial of service, spoofing can lead to plausible but incorrect time synchronisation — potentially more dangerous, as it may go undetected for extended periods.

Mitigation strategies include:

  • Multi-constellation, multi-frequency reception, enabling cross-checks across independent signals.
  • Antenna directional designs to suppress interference, or use of multiple distant antennas.
  • Signal quality monitoring to detect anomalies in power, timing, or structure.
  • Authentication features, such as Galileo’s Navigation Message Authentication (NMA) [10], Meinberg Trusted Source Mode, and upcoming GPS civil authentication (currently not available, 2025).
  • External validation services, providing trusted corrections and anomaly detection.
  • Choosing an adequate holdover oscillator

Together, these measures create a layered defence, ensuring GNSS-based timing remains robust even under interference.

GNSS indoor

GNSS signals are extremely weak when received on Earth and are therefore easily attenuated below the minimal required level when indoors. As a result, GNSS timing receivers typically require outdoor antennas with a clear view of the sky. For indoor applications, solutions such as GNSS repeaters, distributed antenna systems, or indoor positioning technologies are used to deliver satellite signals into otherwise shielded environments. Emerging services, such as those offered by “iPosi“, utilise hybrid methods that combine GNSS with terrestrial signals to provide indoor timing and positioning, extending GNSS coverage into environments where direct satellite reception is not feasible.

Meinberg solutions

Meinberg receivers and time servers are widely used in critical infrastructure. By combining multi-frequency, multi-constellation GNSS receivers, authenticated correction services, and high-quality local oscillators, they maintain resilient, traceable access to UTC around the globe. In addition, AtomiChron® is a third-party NMA (Navigation Message Authentication) subscription service operated by Fugro N.V. It ensures that the timing signals received by users can be cryptographically validated, significantly reducing the risk of spoofing. Meinberg’s IMS-GXL183 module supports this service as well as the OSNMA mechanism for Galileo.

In applications where reliance on GNSS as a single point of failure is unacceptable, combined strategies include simultaneous use of GNSS, PTP, as well as local oscillators such as high-performance holdover OCXOs or atomic references (e.g., rubidium, caesium). Meinberg provides resilient solutions, using MRS devices and IMS modules, to ensure continuous, secure, and traceable time, even in the event of GNSS outages.

References

[1] GPS.gov, “GPS Accuracy,” National Coordination Office for Space-Based PNT, 2023.

[2] European Space Agency (ESA) — Galileo System Time, Satellite Clocks, Ground Segment documentation, 2024.

[3] J. Levine, “Time Transfer Using the Global Positioning System,” IEEE Trans. Ultrason., Ferroelectr., Freq. Control, vol. 46, no. 2, pp. 392–398, Mar. 1999.

[4] R. T. Rajan et al., “Multi-constellation GNSS timing: from UTC to Galileo OSNMA,” Proceedings of the EFTF–IFCS Joint Conference, 2023.

[5] NIST, “GPS Time and the World’s Largest Clocks,” NIST Technical Note 1559, 2019.

[6] International GNSS Service (IGS), “IGS Timescale Products and Performance,” IGS Time Series Reports, 2023.

[7] A. Bauch and S. Weyers, “Atomic Clock Ensemble in Space (ACES): Time Transfer and Clock Comparisons,” Metrologia, vol. 42, no. 3, pp. S43–S54, 2005.

[8] BIPM, “Circular T: Monthly report on UTC – UTC(k),” Bureau International des Poids et Mesures, 2025.

[9] D. Piester et al., “GPS-based time transfer: common-view, P3, PPP, and Precise Point Positioning,” Metrologia, vol. 45, pp. 185–198, 2008.

[10] European GNSS Agency (GSA), “Galileo OSNMA (Open Service Navigation Message Authentication) – Technical Description,” v1.1, 2022.

[11] BIPM (2016). GNSS Time Transfer by Common-View and All-in-View Methods. Metrologia, 53, S136–S145.

[12] IGS & BIPM (2021). Precise Point Positioning for Time and Frequency Transfer. Journal of Geodesy, 95:31.

Disclaimer

We strive to ensure that all information published here is accurate and from verifiable sources. However, we cannot always guarantee that all details are up to date. Please, always double-check it when using it for further research.

  • share 
  • share  
  • share 

Related posts:

  1. What Time Is It, Really? – The Science Behind Coordinated Universal Time (UTC)
  2. GNSS jamming and how to mitigate it
  3. GNSS Spoofing and how to mitigate it
  4. IEEE 1952 PNT Resilience Levels: Detecting Adversities
Previous Post - What Time Is It, Really? – The Science Behind Coordinated Universal Time (UTC)

Filed Under: Industry Applications, Time and Frequency Tagged With: GNSS, time, UTC

Discussion Area:

If you enjoyed this post, or have any questions left, feel free to leave a comment or question below.

Share Your Comments & Feedback Cancel reply

PTP Software

  • PTP Track HoundPTP / IEEE 1588 Protocol Analyzer

  • NTP / PTP Simulation Software
  • Meinberg Advertisement

    Categories

    • Authors
    • Configuration Guidelines
    • IEEE 1588
    • IEEE 1952
    • Industry Applications
    • NTP
    • Security
    • Time and Frequency
    • Uncategorized

    External Links

  • NTP Security
    • Site Notice
    • Privacy Policy

    You may also like

    1. What Time Is It, Really? – The Science Behind Coordinated Universal Time (UTC)
    2. GNSS jamming and how to mitigate it
    3. GNSS Spoofing and how to mitigate it
    4. IEEE 1952 PNT Resilience Levels: Detecting Adversities

    © 2025 · Time Synchronization Blog

    MENU
    • PTP / IEEE 1588
    • NTP
    • Configuration Guidelines
    • Industry Applications
    • Security