SyncE, PTP, grandmaster clocks, and the timing failures that cause mass call drops and handover failures

1. What Is Synchronisation — And Why 5G Is More Demanding Than LTE

Every 5G base station must be synchronised. Not approximately — precisely. For TDD (Time Division Duplex) operation, which covers the vast majority of 5G NR deployments in the GCC, all gNBs must transmit and receive in exactly the same time slots. When they do not, downlink transmissions from one cell bleed into uplink receive windows of adjacent cells. This is called base station-to-base station interference, and it degrades network performance across entire regions — not just individual sites.

The synchronisation requirement for 5G TDD is a phase alignment of less than 1.5 microseconds between adjacent cells. To put that in perspective, light travels 450 metres in 1.5 microseconds. This is a hardware-level precision requirement that the entire transport network must support, from the grandmaster clock in the data centre all the way to the RU on the tower.

LTE FDD did not have this problem — frequency division allows simultaneous transmit and receive without phase alignment. 5G TDD changed the game. Synchronisation moved from a nice-to-have to a network-critical function that transport architects must design and operate with the same rigour as routing and QoS.

2. Real Network Architecture — The Timing Distribution Chain

From GPS to RU: Every Node in the Chain

Node	Role	Protocol	Accuracy Requirement
GNSS / GPS Receiver	Primary time source — absolute time reference	GPS/PPS — feeds Grandmaster	< 100 ns (GNSS disciplined)
Grandmaster Clock (GM)	Distributes time via PTP to all downstream nodes	IEEE 1588v2 PTP — ITU-T G.8275.1	< 100 ns from GNSS
Boundary Clock (BC)	Terminates PTP from GM, re-originates to downstream	PTP slave toward GM, master toward downstream	< 1 µs accumulated error
Transparent Clock (TC)	Passes PTP through, corrects for transit delay	PTP with correction field update	Minimal — adds correction only
SyncE-enabled switch/router	Frequency synchronisation — locks to Ethernet symbol clock	ITU-T G.8261 / G.8262	Frequency: ±4.6 ppb
RU / DU	End consumer of timing — applies phase alignment to radio	PTP slave — typically G.8275.1 profile	< 1.5 µs from adjacent cell

The key distinction between SyncE and PTP is what they provide: SyncE delivers frequency synchronisation — the clock ticks at the right rate. PTP delivers phase and time synchronisation — the clock ticks at the right rate AND is aligned to absolute UTC time. 5G TDD requires both. SyncE provides the stable frequency reference, PTP rides on top to deliver phase alignment.

Full Timing Support vs Partial Timing Support

ITU-T G.8275.1 defines Full Timing Support (FTS) — every node in the transport path is PTP-aware and acts as a Boundary Clock or Transparent Clock. This is the recommended architecture for 5G TDD. It provides the best accuracy because every transit node corrects for its own forwarding delay.

G.8275.2 defines Partial Timing Support (PTS) — PTP passes through non-PTP-aware nodes as regular UDP traffic. This introduces packet delay variation (PDV) because routers apply variable queuing delays to PTP packets. PTS requires careful link design and is only viable with very short transport chains and low utilisation links.

Field Note: In a GCC operator with a mix of new and legacy aggregation switches, we often see a hybrid: FTS on the fronthaul and upper midhaul segments (where latency budget is tightest), and PTS on the backhaul segment to the core. This works if PDV on the backhaul segment is well-controlled — but it requires explicit measurement, not assumption.

3. Step-by-Step Real Flow — Timing Distribution in Oman

Step 1 — GNSS Receiver at Core DC

A GNSS receiver (GPS/GLONASS) at the Muscat Core DC acquires satellite signals and disciplines a local oscillator to absolute UTC time with accuracy better than 100ns. This feeds the Grandmaster Clock, which becomes the authoritative time source for the entire network.

Step 2 — Grandmaster Distributes PTP

The GM originates IEEE 1588v2 PTP Announce and Sync messages on its downstream ports toward the aggregation PE routers. Each Sync message carries a precise timestamp. The downstream Boundary Clocks use the two-step timestamp mechanism to calculate their offset from the GM and correct their local clocks.

Step 3 — Boundary Clocks at PE Routers

The aggregation PE routers at Seeb, Ruwi, and Barka act as Boundary Clocks. They terminate the PTP session from the GM, lock their local clocks to the received time, and re-originate PTP sessions toward the access layer switches and ultimately the DU/RU. Each BC introduces some residual time error — typically 50-200ns per hop on well-configured hardware.

Step 4 — SyncE on the Access Segment

The access switches and transport links between PE and DU run SyncE alongside PTP. SyncE locks the Ethernet physical layer clock to the upstream reference, providing a clean frequency reference. This ensures that even if PTP packets experience momentary queuing delays, the frequency base remains stable and PTP recovery is faster.

Step 5 — RU Acquires Phase Lock

The RU runs a PTP slave clock. It receives Sync messages from the DU (which may relay PTP) or directly from the access BC. It calculates its time offset, adjusts its local oscillator, and achieves phase lock within the required 1.5 µs budget. The 5G radio frame timing is now aligned with all other cells in the network.

Key insight: The total phase error budget of 1.5 µs must be shared across the entire chain from GM to RU. With 5-7 hops, each hop can contribute no more than 200-300 ns. Any single misconfigured BC or high-PDV link segment can consume the entire budget alone.

4. Practical Example — Timing Failure Causing Call Drops

An operator in the GCC reports widespread handover failures and call drops at multiple sites in a district, not a single site. RAN performance dashboards show increased DL interference and rising PDCCH errors. Individual site checks find nothing wrong with the radio configuration. The issue is eventually traced to timing.

Symptom	Root Cause	How Detected
Mass handover failures across 12 sites	Boundary Clock at Seeb PE lost PTP lock after software upgrade — BC entered holdover mode	PTP clock state monitoring: BC showed HOLDOVER for 4 hours
Holdover degradation	Local oscillator in BC drifted 2.1 µs over 4 hours — exceeded 1.5 µs budget	Time error (TE) monitoring showed TE > 1500 ns at DU level
TDD interference spike	Adjacent cells lost phase alignment — DL/UL slot collision	RAN interference reports showed self-interference pattern
Resolution	PTP session restored after manual BC restart — GNSS reference re-acquired	TE returned to < 200 ns, interference eliminated within 2 minutes

The critical failure point was the absence of real-time Time Error monitoring. The BC entered holdover silently. No alarm was generated. By the time RAN performance degraded visibly, the timing error had been accumulating for 4 hours across all sites served by that BC.

5. Key Parameters and Configurations

Parameter	Standard / Requirement	Typical Configured Value	Impact if Out of Spec
End-to-end Time Error (TE)	ITU-T G.8271.1: < 1.5 µs at RU	Target: < 500 ns for margin	TDD interference, handover failures, HARQ timing errors
Packet Delay Variation (PDV)	G.8271.2: < 1 µs for PTS networks	Measure on live path with TWAMP or PTP probe	High PDV = BC cannot correct accurately = TE accumulation
SyncE SSM quality level	G.8264: QL-PRC for GM-derived signal	QL-PRC on GM output, QL-EEC1 on access switches	Wrong QL = clock cascades to wrong source, frequency error
PTP profile	G.8275.1 (FTS) or G.8275.2 (PTS)	G.8275.1 on all fronthaul/midhaul segments	G.8275.2 on high-utilisation links causes excessive PDV
BC holdover specification	G.8273.2 Class C: < 50 ns drift in 1000s	Use Class C or better BCs on all aggregation hubs	Class A/B BCs drift too fast in holdover — 1.5 µs exceeded quickly
BMCA (Best Master Clock Algo)	IEEE 1588 BMCA — clock class, accuracy, priority	GM: clock class 6, priority1 128; BC: class 135 in holdover	Wrong priority = incorrect GM election, suboptimal clock source

6. Common Issues in the Field

• GNSS signal loss at GM — caused by antenna obstruction, cable damage, or RF interference. GM enters holdover mode. If holdover oscillator quality is poor (OCXO vs TCXO), phase error accumulates rapidly. Deploy dual GM with automatic switchover and monitor GNSS lock status continuously.
• Asymmetric path delay — PTP assumes the forward and return paths have equal delay. If PTP Sync packets travel on a different physical path than Delay_Request packets (e.g. different fibre routes in a ring), the calculated offset is wrong. This is particularly common in ring topologies with asymmetric fibre lengths. Requires asymmetry correction configuration on BCs.
• PTP packets queued with data traffic — if transport switches do not apply priority queuing to PTP packets (DSCP CS6 or EtherType 0x88F7 for L2 PTP), they get queued with data traffic. Under congestion, PTP packets experience variable delay — high PDV — and BC accuracy degrades.
• Mixed PTP-aware and non-PTP-aware nodes — a legacy switch in the transport chain that does not support BC or TC passes PTP as regular UDP. The variable forwarding delay it introduces accumulates as PDV. The BC downstream sees degraded input and cannot achieve the required accuracy.
• Holdover alarms not monitored — this is the most dangerous operational gap. A BC in holdover mode continues to distribute timing and appears functional. Without active monitoring of PTP clock state and TE, the degradation is invisible until RAN performance collapses.
• SyncE SSM misconfiguration — Synchronisation Status Messages tell downstream nodes about clock quality. If SSM is disabled or misconfigured, a switch may lock to a low-quality clock source (e.g. a free-running oscillator) and propagate frequency error downstream.

7. Troubleshooting Approach

• Start at the GM — verify GNSS lock status, clock class (should be 6), and PTP session state. A GM in holdover or freerun state is the source of most widespread timing failures.
• Trace the PTP clock chain — on each BC in the chain, verify: clock state (LOCKED/HOLDOVER/FREERUN), upstream master identity, time offset from master, and mean path delay. A BC showing high offset or HOLDOVER state is the break point.
• Measure Time Error at DU — use an external time interval analyser or the DU’s built-in PTP monitoring to measure TE against a GPS reference. This gives the actual end-to-end accuracy at the consumer of timing.
• Measure PDV on the transport path — inject PTP probes or use TWAMP with timestamping to measure packet delay variation between GM and BC, and between BC and DU. PDV above 1 µs on any segment indicates a queuing or routing problem.
• Check SyncE chain integrity — verify SSM quality levels on each link. Use: show synchronization or equivalent CLI. Ensure all links show QL-PRC or QL-EPRTC derived quality. Any link showing QL-DNU (Do Not Use) or QL-SEC indicates a problem.
• Verify PTP packet priority — confirm PTP Sync and Delay_Request packets are in the priority queue on all transport nodes. Check for PTP packet drops in queue statistics during congestion periods.

8. Design Recommendations — Consultant Level

• Deploy dual GNSS-disciplined GMs at geographically separate locations — test automatic switchover quarterly. A single GM failure in a TDD network causes immediate widespread outage. This is non-negotiable for any serious 5G deployment.
• Use Class C or better Boundary Clocks at all aggregation hubs — Class C BCs (ITU-T G.8273.2) maintain < 50ns drift for 1000 seconds in holdover. Class A/B drift too fast for TDD requirements. Specify this in equipment procurement RFPs explicitly.
• Enable PTP packet priority on all transport nodes — map PTP EtherType (0x88F7 for L2) or DSCP CS6 (for L3/UDP PTP) to the strict priority queue on every switch and router in the timing chain.
• Deploy asymmetry correction on ring topologies — measure actual fibre delay asymmetry using a GPS receiver at both ends and configure correction values on BCs. Do not assume symmetric paths in ring networks.
• Implement continuous TE and PDV monitoring — deploy a timing monitoring system that measures TE at the RU or DU level and alerts when TE exceeds 1 µs (giving 500 ns margin before the 1.5 µs limit). Do not rely on router/switch alarms alone.
• Separate PTP traffic onto dedicated VLANs or use G.8275.1 full on-path support — never mix PTP with high-bandwidth data traffic on the same queuing domain without strict priority protection.

9. Summary — Practical Takeaways

Synchronisation is the silent killer of 5G TDD networks. When it fails, the symptoms look like radio problems — interference, handover failures, throughput drops — and the investigation invariably starts in the wrong place. By the time the transport team is involved, hours of service impact have already occurred.

The preventive measures are straightforward: dual GMs, Class C BCs, PTP priority queuing, asymmetry correction, and continuous TE monitoring. Every one of these must be designed in from the start. Retrofitting synchronisation infrastructure into an operational network is painful, expensive, and service-affecting.

Takeaway	Action
1.5 µs phase budget is shared across all hops	Budget per hop: 200-300 ns max — verify with end-to-end TE measurement
Dual GM is mandatory, not optional	Deploy two geographically separate GNSS-disciplined GMs with auto-failover
BC holdover quality determines resilience	Specify Class C (G.8273.2) BCs in all procurement — do not accept Class A/B
PTP packets must be in priority queue	Enable PTP priority on every transport node — verify during acceptance testing
Monitor TE continuously, not reactively	Alert at 1 µs TE — do not wait for RAN KPI degradation to detect timing issues