GNSS clocks and timing services
GNSS clocks provide an accurate satellite-derived time reference for networks and critical systems. edgeTime can help you select, configure and support the right equipment, or deliver it as part of a managed timing service.
GNSS explained
A GNSS clock is a timing device that receives precise time signals from satellite constellations such as GPS, Galileo, GLONASS and BeiDou. It uses these signals to control a local oscillator before distributing accurate time, phase or frequency to connected networks and systems.
Depending on the device, timing can be distributed through PTP, NTP or physical outputs such as 1 PPS and 10 MHz. If satellite reception is temporarily lost, the internal oscillator can maintain timing during a period known as holdover.
Technical reference:
EUSPA – GNSS for timing and synchronisation
01
An antenna receives timing signals from one or more GNSS constellations.
02
The receiver processes the satellite timing data and establishes a local reference.
03
The GNSS reference continually corrects the clock’s internal oscillator to control drift.
04
Accurate time is delivered to connected systems using the required protocols and outputs.
Understanding your options
The terminology can overlap. The right device depends on how timing is received, distributed and used across your network.
GNSS
Receives timing from one or more satellite constellations and controls a local oscillator.
GPS
A satellite-referenced clock that specifically uses GPS, which forms part of GNSS.
NTP
Uses GNSS as its reference and distributes time to connected systems over a network.
PTP
Provides the main timing reference within a PTP domain using GNSS or another trusted source.
The required combination depends on your accuracy, network and equipment requirements.
Not every GNSS clock supports every protocol or output.
Technical references:
IEEE 1588-2019
and
RFC 5905 for NTPv4.
GNSS clock applications
GNSS clocks provide a shared reference for networks and systems that depend on accurate time, phase or frequency.
Supporting frequency and phase synchronisation across core, access and radio networks.
Aligning timestamps, transactions, system logs and events across critical infrastructure.
Synchronising protection, monitoring, measurement and substation systems.
Maintaining alignment across audio, video, timecode and production systems.
Providing consistent timing across distributed operational and PNT-dependent systems.
Supporting automation, testing, measurement and precisely coordinated processes.
Choosing the right solution
The right clock must match how timing will be received, maintained, distributed and managed across your environment.
Define the accuracy required where timing will be consumed.
Confirm the required protocols, profiles and physical outputs.
Set how long timing must remain within specification after GNSS loss.
Consider constellations, frequency bands, antennas, cabling and protection.
Review monitoring, alarms, redundancy, support and lifecycle requirements.
GNSS resilience
GNSS provides an accurate and widely available timing reference, but the signals reaching an antenna can be disrupted, blocked or manipulated.
Interference can prevent the receiver from obtaining a usable satellite signal, forcing the clock to rely on holdover or another reference.
False or manipulated signals can cause a receiver to calculate incorrect time while appearing to remain connected to a valid source.
Antenna faults, damaged cabling, poor installation, environmental conditions or equipment failure can interrupt the reference.
Holdover explained
When GNSS is lost, the clock relies on its internal oscillator. How long it remains within the required accuracy depends on the oscillator, previous disciplining, environmental conditions and the duration of the outage.
Resilience should combine monitoring, suitable holdover, alternative references and tested operational processes.
Further guidance:
UK Government PNT resilience overview
and
ITU guidance on resilient synchronisation networks
.
GNSS clock products and services
edgeTime can help you select and purchase a GNSS clock, configure it around your requirements and provide the testing, monitoring and support needed throughout its lifecycle.
Source a GNSS clock selected around your technical, operational and resilience requirements.
Add ongoing technical support and operational visibility to an existing or newly deployed timing environment.
Use GNSS-referenced timing within a managed service model without owning and operating every part of the infrastructure.
Reference laboratory
Testing can be shaped around the clock, network design and required operational outcomes before equipment reaches the live environment.
Common questions
Clear answers to common questions about GNSS timing, holdover, protocols and resilience.
GPS is one Global Navigation Satellite System. A GNSS clock may support GPS alongside other constellations such as Galileo, GLONASS and BeiDou. The term GPS clock is often used more generally, even when the device supports several constellations.
Yes, a GNSS clock can continue operating from its internal oscillator during holdover. However, the clock will gradually drift. How long it remains within the required accuracy depends on the oscillator, environmental conditions and system design.
NTP is widely supported and suitable for many general IT requirements. PTP is used when greater precision and tighter control over network timing are required. The right protocol depends on the application rather than simply choosing the most precise option.
Read our guide to
PTP vs NTP time synchronisation
.
Multi-constellation reception can improve availability and provide more signals to compare, but it does not remove every risk. Different constellations may still share the same antenna, receiver, cabling and local radio-frequency environment.
edgeTime can review existing GNSS clocks and timing environments to assess configuration, compatibility, monitoring, resilience and support requirements. Recommendations can then be shaped around the equipment and wider network.
