What a Time Hub is at the edge (and what it is not)

Time Hub owns “time source + oscillator holdover”; boundary clocks and switches own “time propagation through packet forwarding.” A practical ownership check is simple: if PPS/ToD/PTP are self-consistent at the Time Hub outputs but downstream nodes disagree, the fault typically lies in the network propagation path (not inside the Time Hub).

• “GNSS is locked, so time must be perfect.” Lock is not a quality guarantee. The system still needs measurable limits on time error, phase steps during reference switching, and holdover drift.
• “PTP jitter is always the GM.” Without checking 1PPS/ToD/PTP consistency at the GM outputs, packet-domain symptoms are misleading.
• “A good oscillator fixes everything.” The oscillator helps only if the servo bandwidth and jitter-cleaning chain are designed to avoid injecting reference noise.

To be operationally useful at edge sites, a Time Hub should provide a small set of remotely verifiable signals and counters: (1) time error / offset estimates, (2) oscillator control word / frequency offset, (3) GNSS quality indicators, (4) PLL lock states, and (5) event logs for holdover entry/exit and phase-step detection. These signals allow time quality to be proven without physical access.

Ports, references, outputs, and a verifiable three-chain model

A Time Hub architecture should be read as a measurable system, not a pretty diagram. The most useful framing is to split the box into three chains that can be independently validated: reference chain (GNSS/external reference quality), oscillator chain (local stability and steering), and distribution chain (jitter cleaning + fanout + port consistency). Each chain has a small set of test points that tell whether the chain is healthy.

• Purpose: decide whether GNSS/external reference is trustworthy enough to steer the oscillator.
• Core outputs: lock state, reference quality score, detected phase steps or anomalies.
• What can go wrong: “locked but noisy” GNSS, multipath-induced wander, intermittent 1PPS integrity.

• Purpose: provide short-term stability and bounded drift when the reference is degraded or absent.
• Core observables: frequency offset estimate, control word/DAC value, temperature, aging trend.
• What can go wrong: servo hunting, too-wide loop injecting reference noise, poor thermal behavior.

• Purpose: shape phase noise via jitter-cleaning PLL and distribute stable clocks to outputs and timestamp domain.
• Core observables: PLL lock, additive jitter budget, per-port offset consistency (PPS/ToD/PTP).
• What can go wrong: fanout additive jitter, supply-noise coupling, port delay mismatches causing fixed offsets.

The key architectural deliverable is a clean separation of responsibilities: reference chain decides confidence, oscillator chain carries stability, and distribution chain preserves and replicates it. When these three chains are observable, field incidents become diagnosable without on-site instrumentation.

GNSS, external 1PPS/10MHz/ToD, and reference qualification

Multi-constellation and dual-frequency GNSS help not by “more satellites” as a marketing line, but by changing failure modes that dominate edge deployments:

• Obstruction tolerance: when one sky view is blocked, usable satellites remain, reducing lock-drop frequency and unnecessary holdover entries.
• Multipath resilience (lower wander): dual-frequency reduces slow, low-frequency position/time wander that can drive the disciplining loop to chase noise.
• Faster convergence after reboot/outage: edge nodes reboot more often than core facilities; recovery time directly affects “time-available” windows and alarm policy.

External 1PPS, 10MHz, and ToD inputs serve three edge-useful roles:

• Backup reference: a stable upstream can keep the oscillator steered when GNSS becomes intermittent.
• Hierarchy / cascading: a site can follow a local “time tree” where one hub provides reference to others.
• Cross-validation: GNSS and external reference can be compared continuously; disagreement is a strong signal for qualification and event logging.

Qualification converts raw “lock” signals into an operational decision. A robust implementation combines three categories of features into a quality score and uses enter/exit thresholds (hysteresis) to prevent rapid toggling:

• GNSS features: lock status, satellite health indicators, SNR trend, detected anomalies (e.g., sudden phase jumps), short-term time-error noise level.
• External features: 1PPS integrity (missing/extra pulses), 10MHz stability, ToD second-boundary continuity.
• Consistency features: GNSS↔External phase delta stability; slow drift vs sudden step; sustained disagreement beyond a window.

A phase step happens when the active reference changes faster than the oscillator/time counter can be brought into alignment. Three practical causes dominate:

• Pre-existing offset: GNSS and external references are not phase-aligned (fixed offset or slow drift), so switching “reveals” the difference.
• Alignment strategy: an abrupt step forces immediate alignment; a controlled slew ramps phase/frequency to avoid discontinuities.
• Path delay mismatch: different input paths (or port calibration differences) shift the effective phase unless the same delay model is applied.

An engineering-grade objective is written as a bounded event rather than a vague promise: define a maximum allowed phase step at switchover (e.g., tens of nanoseconds in a single chassis context), enforce it with a slew limiter, and record every event with timestamp and magnitude so field behavior is provable.

• Time-domain: measure 1PPS phase difference before/after switch with a time-interval counter; repeat switches and report max + percentile.
• Continuity: validate ToD second boundary does not jump backward; confirm time counter monotonicity across events.
• Evidence: log reference quality score, switch reason, holdover entry/exit, and measured phase-step magnitude.

OCXO vs CSAC: paying for holdover (and what to measure)

Holdover is the period where exported time is maintained by the local oscillator when the active reference is degraded or unavailable. The engineering target is expressed as bounded time error growth over a defined window (minutes to hours), with telemetry that supports remote verification. Without this, “GNSS outage” becomes an unpredictable service event.

• Phase noise / integrated jitter: influences short-window time-error noise and how clean the distribution chain can be.
• Allan deviation (ADEV): predicts stability across time scales and is the best bridge between oscillator physics and holdover behavior.
• Temperature sensitivity: directly shapes drift in real enclosures; thermal dynamics often dominate beyond the first seconds.
• Aging: drives long-term frequency offset trends; it matters when recalibration opportunities are rare.
• Warm-up / stabilization: defines “time-available after power-up,” critical for edge reboot events.

OCXO commonly wins on cost and integration simplicity but is more sensitive to enclosure thermal dynamics and aging behavior. CSAC typically offers stronger long-window stability per watt within a compact module, which can materially improve holdover in unattended edge sites—at the expense of higher cost and integration requirements. The correct answer depends on the required holdover window and the allowable drift budget.

ADEV is most useful when read as a “time-scale map.” Three windows explain most observed behavior:

• τ ≈ 1 s: short-term noise dominance (phase noise / loop disturbances) → drives fast jitter and short-window offset variation.
• τ ≈ 10 s: mid-term wander (thermal control dynamics, reference noise coupling) → drives slow oscillations and servo “hunting” risk.
• τ ≈ 100 s: longer-term drift (temperature trend + aging emergence) → drives minutes-scale holdover error growth.

The longer the required holdover window, the more the selection should weight the longer-τ region and enclosure thermal behavior.

How GNSS steers the oscillator without hunting

A practical GNSSDO-style disciplining loop can be read as a signal chain with clear test points: phase detector/TDC produces a phase error, a loop filter shapes the response, a DAC/EFC applies correction to an OCXO/CSAC, and a monitor logs time error and control effort. When these observables are missing, tuning becomes guesswork.

• TP1: time/phase error (e.g., 1PPS vs internal time counter) — proves convergence and steady-state noise.
• TP2: control word / DAC value — exposes loop effort, saturation, and slow thermal/aging trends.
• TP3: oscillator output (10MHz/clock domain) — validates what the distribution chain receives.

Bandwidth is the dominant trade-off knob. A wider loop responds faster to reference changes, but is more likely to pull GNSS measurement noise into the output. A narrower loop protects short-term stability by leaning on the oscillator, but may converge slowly and correct long-term drift later than operations prefer.

• Too wide: steady-state time error becomes “hairy” (high-frequency noise), and periodic oscillations can appear if phase margin is weak.
• Too narrow: recovery after cold start or reference restoration is slow, and holdover exit takes longer to return to a tight error band.

What gets cleaned, what leaks through, and how to prove it

• In-band: output tracks the input reference (good when the input is clean, risky when the input is noisy in that band).
• Out-of-band: output tracks the PLL’s VCO/clock source (beneficial if the local source is cleaner than the input at high offsets).
• Implication: PLL bandwidth selection decides what portion of input jitter is passed vs rejected.

Even with a good cleaner, distribution can dominate the final result at multi-port edge hubs:

• Additive jitter accumulation: each fanout stage adds noise; cascaded buffers can set the jitter floor at the ports.
• Mux/switchover disturbance: clock muxing and redundancy switching can introduce short transients if not carefully bounded and logged.
• Supply-noise coupling: buffer and PLL sensitive nodes convert rail ripple into phase modulation, especially under changing loads/thermal states.
• Crosstalk/isolation: adjacent clock nets and poor return paths can inject deterministic spurs and widen integrated jitter.

The fastest way to prove “cleaning” vs “leakage” is a consistent three-point measurement plan:

• TP-IN: at the PLL input (reference-in)
• TP-OUT: at the PLL output (cleaned clock)
• TP-PORT: at a representative output after fanout/mux (port-out)

Compare phase-noise shape and integrated jitter across the same integration band. If TP-OUT improves but TP-PORT worsens, the clock tree is the culprit (additive jitter or coupling). If TP-IN is already noisy and the PLL bandwidth overlaps that region, “cleaning” will appear limited by design.

Where timestamps are made trustworthy (inside the grandmaster)

A grandmaster can create timestamps at different points of its internal packet-processing chain. The key is not the name of the block, but how much internal uncertainty remains between the timestamp point and the physical egress/ingress boundary.

• MAC timestamp: integrated and convenient; relies on a well-defined internal path to keep repeatability.
• PHY timestamp: closer to the line side; reduces uncertainty from internal buffering paths.
• Dedicated timestamp unit (TSU): separates time capture from general logic and makes the evidence chain easier to audit.

Trustworthy timing requires that ToD (time-of-day), PTP time, and 1PPS describe the same second boundary. A robust grandmaster uses 1PPS as the boundary anchor, a high-resolution time counter for sub-second time, and performs a second-boundary consistency check so “seconds” never drift apart silently.

• 1PPS alignment: defines the second tick; used to validate counter rollover/epoch behavior.
• Time counter: provides fine time within the second; must remain stable and measurable.
• Second-boundary check: ToD second update and 1PPS boundary must match within a small window and be logged when violated.

• TP-PPS: observe 1PPS vs internal counter boundary behavior (rollover, alignment).
• TP-PTP: compare hardware timestamp time to the same internal time counter at capture time.
• TP-ToD: verify ToD seconds transition matches the 1PPS boundary and never “double-ticks” or skips silently.

Staying sane when GNSS dies: bounded drift and smooth recovery

• Entry gate: reference quality below threshold for a sustained window, loss-of-lock, or anomaly/jump detection triggers a mode change.
• Drift budget: define maximum allowed time-error growth rate and absolute error envelope over time.
• During holdover: monitor time-error trend, frequency offset, temperature, and control word drift to explain behavior remotely.

When reference returns, the grandmaster may have accumulated an offset. Forcing a hard step can break continuity for consumers. A controlled slew limits the phase/frequency correction rate and provides an auditable recovery path: recovery mode, slew rate, and completion condition should be visible in telemetry and event logs.

Writing switchover as a state machine prevents ambiguous behavior. Each state should have explicit entry conditions, key observables, and alarm severity so field behavior is predictable and auditable.

What must be logged to prove time quality

• Time Quality (effects): time error/offset, RMS/p95/max over a fixed window, phase step events (magnitude + direction).
• Frequency & Control (causes): freq offset/drift, OCXO/CSAC control word (and percent-to-rail), disciplining mode/state.
• Reference Health (inputs): GNSS lock state, quality indicators (e.g., C/N0, SV count), reacquire counters.
• Clock Chain Health (path): PLL lock (jitter cleaner/clock tree), key-point temperature and temperature rate.

Event logs must support root-cause reconstruction: which signal degraded first, how drift evolved, and whether recovery stayed smooth. This requires both ordering (monotonic event sequencing) and context (state/source before and after).

• Ordering: monotonically increasing event sequence plus a monotonic timestamp alongside ToD.
• Correlation: state_before/state_after, source_before/source_after, and a compact cause code.
• Quantification: phase step magnitude, recovery mode (slew/step), and predicted drift budget at entry to holdover.

How to test a Time Hub like an engineer

• Phase noise / jitter: measure oscillator and post-cleaner behavior using consistent integration bandwidth.
• ADEV (stability vs τ): capture short/medium/long τ regions to understand dominant noise regimes.
• Time error & PPS alignment: verify 1PPS boundary alignment and second-boundary consistency over fixed windows.
• Thermal drift: temperature chamber sweep, record temp rate vs time-error drift to build a correlation map.
• GNSS obscuration test: controlled signal degradation/occlusion to verify state transitions, alarms, and holdover entry behavior.

System testing focuses on what downstream devices can observe, not on their internal forwarding or timestamp models. The goal is consistency: when the time hub changes state or produces a controlled disturbance, downstream observed offset should change in a predictable, correlated way.

• Correlation window: align time hub event logs with downstream offset/alarms over the same time window.
• Controlled disturbance: trigger a known transition (degraded/holdover/recovery-slew) and verify downstream visibility.
• Consistency metrics: compare p95/max observed offset and step-event coincidence with time hub evidence logs.

• GNSS outage drill: verify holdover entry delay, alarm level, and drift stays inside the declared budget.
• Switchover drill: test redundant source selection and ensure reasons/magnitudes are logged.
• Recovery drill: confirm recovery uses slew (no phase hit) and produces a clean completion event.
• Log audit: pick a random interval and reconstruct “what happened first” using event_seq + context snapshots.

Quick drift intuition for acceptance budgeting: 1 ppm ≈ 1000 ns/s. So drift_ns ≈ ppm × T_seconds × 1e3; for ppb, drift_ns ≈ ppb × T_seconds.