Timing & Synchronization in O-RAN

1. Introduction

The Open Radio Access Network (O-RAN) architecture is revolutionizing the telecom industry by enabling vendor-neutral and flexible network deployments. However, one of the most critical aspects of O-RAN is timing and synchronization, which ensures smooth and efficient communication between different network elements, particularly between the O-RAN Distributed Unit (O-DU) and O-RAN Radio Unit (O-RU).

Synchronization is essential for maintaining network performance, avoiding interference, and ensuring seamless handovers in 4G and 5G networks.

2. Why is Synchronization Critical in O-RAN?

a) Avoiding Interference in TDD Networks

• Time Division Duplex (TDD) systems rely on precise timing to separate uplink and downlink transmissions.

• A timing mismatch can lead to cross-link interference, affecting network quality.

b) Seamless Handover and Mobility Support

• Mobile users rely on smooth transitions between cells.

• Poor synchronization can cause call drops and data packet loss.

c) Fronthaul Delay Management

• O-RAN uses an Ethernet-based fronthaul, which introduces packet delay variation (PDV).

• Precise synchronization helps mitigate timing drifts due to transport network fluctuations.

d) Multi-Vendor Interoperability

• O-RAN allows components from different vendors to work together.

• Consistent and standardized timing mechanisms ensure seamless operation across vendors.

3. O-RAN Synchronization Architectures (LLS-C1, C2, C3, C4)

O-RAN Working Group 4 (WG4) defines multiple Low Layer Split (LLS) synchronization architectures:

LLS-C1: Synchronization from O-DU

• Primary Sync Source: O-DU

• How it Works: In this configuration the DU performs as a PTP Boundary Clock (BC) sourcing the Timing signal from the GM and then directly connected to the RU to synchronize it.

LLS-C2: O-DU Sync + GNSS Backup

• Primary Sync Source: O-DU

• Backup Sync Source: GNSS/GPS at O-RU

• How it Works: Like LLS-C1 topology, in this configuration the DU performs as a PTP BC for distributing the network Timing towards the RU. One or more PTP switches are allowed to be installed in between. These fronthaul PTP switches may function as Telecom Boundary Clocks as specified by ITU-T G.8273.2. Transparent Clock (TC) switches are also allowed as BC replacement as long as they comply with G.8271.1. The allowed number of switches is limited by total frequency and time error contributions introdued by all switches in the chain as specified in Annex H of the O-RAN.WG4.CUS. This topology requires the support of PTP on all elements on path. 

 LLS-C3: Independent Sync Network

• Primary Sync Source: IEEE 1588 PTP Grandmaster or SyncE

• How it Works: O-RU gets synchronization from an independent network, not from O-DU. Network timing distribution from a PTP Grandmaster located within the fronthaul network, between DU sites and RUs remote sites. One or more PTP switches are allowed in the fronthaul network. This widely adopted topology benefits the most from introducing an integrated PTP Grandmaster and PTP Switch, which provides the ideal solution for fronthaul timing and transport.

 LLS-C4: Hybrid (O-DU + Sync Network)

• Primary Sync Source: O-DU

• Backup Sync Source: Independent sync network (PTP/SyncE)

• How it Works: O-RU can synchronize with either O-DU or an external sync network. In cases where the fronthaul transport network is partially or in full is not upgradable to meeting the target performance at the RU as specified G.8271.1, a local Timing source option (typically GNSS) is allowed.

4. Timing Protocols Used in O-RAN

To ensure synchronization, O-RAN relies on various industry-standard timing protocols:

a)    Precision Time Protocol (PTP) - IEEE 1588v2

• PTP is a packet-based time synchronization protocol that provides nanosecond-level accuracy over Ethernet and IP networks. It is commonly used in O-RAN, 5G.

·       Key Features

o   High precision (sub-microsecond to nanosecond accuracy).

o   Works over Ethernet, IP, and MPLS networks.

o   Uses a Master-Slave architecture.

o   Supports hardware timestamping for enhanced accuracy.

·       PTP Clock Types

o   PTP defines several clock types that participate in synchronization:

Clock Type	Function
Grandmaster Clock (GM)	Primary time source in a PTP network. Distributes time to all other clocks.
Boundary Clock (BC)	Connects multiple PTP domains and forwards synchronization while compensating for delays.
Transparent Clock (TC)	Measures and corrects delays in network switches to improve synchronization.
Ordinary Clock (OC)	Endpoints (e.g., O-DU, O-RU) that synchronize to a Grandmaster or BC.

PTP Synchronization Mechanism

PTP synchronization happens through message exchanges:

1. Sync Message → Grandmaster sends time information to the slave clock.

2. Follow-up Message → Provides more accurate timestamps if hardware timestamping is used.

If your hardware supports PTP:

o   The exchange is called a one-step message exchange, and we only send a sync message that contains the T1 value

If PTP is done in software:

o   PTP uses a two-step message exchange because of additional delays.

o   This means that after the sync message, we send a follow-up message immediately, including the T1 value.

o   The T1 value won’t be in the sync message.

o   The follow-up message means, “The sync message you just received was sent at the time specified in the T1 value”.

3. Delay Request Message → Slave clock measures round-trip delay.

4. Delay Response Message → Master clock responds with delay measurement.

5. Correction Mechanism → Slave clock adjusts timing based on delay calculations.

Here are the two formulas to calculate these two values:

delay = ((t2 - t1) + (t4 - t3)) / 2

offset = ((t2 - t1) - (t4 - t3)) / 2

In above example, delay = 1sec, offset=10 sec

PTP Profiles Used in Telecom Networks

o   ITU-T G.8275.1 (Full Timing Support Profile) → Requires PTP-aware network devices (Boundary and Transparent Clocks).

o   ITU-T G.8275.2 (Partial Timing Support Profile) → Works over networks that don’t fully support PTP.

Advantages of PTP

§  High accuracy for mobile networks (±1.5 µs).

§   Can work over Ethernet/IP-based fronthaul networks.

§   Scalable across distributed O-RAN architectures.

a)      Synchronous Ethernet (SyncE)

SyncE is an Ethernet-based frequency synchronization technology that ensures all devices in a network operate on a common frequency. Unlike PTP, which synchronizes time, SyncE only synchronizes frequency.

Key Features

Provides highly stable frequency synchronization over Ethernet.Uses physical-layer synchronization (instead of packets like PTP).Works seamlessly with PTP to improve overall synchronization accuracy.

How SyncE Works?

1. Clock Distribution → A master clock (e.g., PRC – Primary Reference Clock) injects a stable frequency into the network.

2. Ethernet PHY Layer Transmission → SyncE propagates this frequency across network switches and routers.

3. Recovered Clock → End devices recover the clock frequency and stay synchronized.

SyncE Components

Component	Function
EEC (Ethernet Equipment Clock)	Maintains and distributes frequency synchronization.
SSM (Synchronization Status Message)	Ensures proper selection of the best clock source.
PRC (Primary Reference Clock)	High-accuracy clock that provides the initial frequency reference.

ITU-T Recommendations for SyncE

o   G.8262 → Defines SyncE architecture and performance requirements.

o   G.8264 → Defines Ethernet Synchronization Messaging Channel (ESMC) for clock selection.

o   G.781 → Specifies the Synchronization Network Architecture.

Advantages of SyncE

o   Provides very stable and low-jitter frequency synchronization.

o    Works alongside PTP to improve O-RAN timing accuracy.

o    Supports long-term holdover, preventing network timing failures.

b)    Global Navigation Satellite System (GNSS)

• Used as a backup synchronization source in LLS-C2 and LLS-C4.

• Provides absolute time synchronization.

Why Are Both PTP and SyncE Needed?

Requirement	SyncE	PTP (IEEE 1588v2)
Frequency Synchronization	Yes	Yes (indirectly)
Time Synchronization	No	Yes
Phase Synchronization	No	Yes
Layer of Operation	Physical (Layer 1)	Network (Layer 2/3)
Accuracy	±16 ppb	±1.5 µs
Effect of Network Load	No impact	Affected by network delays

 5. Network Setup for SyncE and PTP Synchronization

Components Involved:

·       Grandmaster Clock (PTP GM): Provides the master time reference.

·       O-DU (Distributed Unit): Acts as a PTP Boundary Clock (BC) and SyncE source.

·       Fronthaul Transport Network: Supports both SyncE and PTP-aware switches (Boundary Clocks or Transparent Clocks).

·       O-RU (Radio Unit): Acts as a PTP slave and SyncE client.

Synchronization Flow:

1. Grandmaster Clock (GM) distributes time and frequency to the O-DU.

2. O-DU forwards SyncE (for frequency) and PTP (for time/phase) to the O-RU.

3. O-RU synchronizes its clock based on received SyncE and PTP signals.

Example Configuration of PTP (IEEE 1588v2) on O-DU

Assuming a Linux-based O-DU (with ptp4l and phc2sys), the following commands configure PTP:

bash

CopyEdit

# Enable PTP Hardware Clock (PHC) on Network Interface (e.g., eth0)

sudo ethtool -T eth0 

# Configure ptp4l as a Boundary Clock (BC) to distribute time to O-RU

sudo ptp4l -i eth0 -m -f /etc/ptp4l.conf --step_threshold=1.0

# Synchronize the system clock with PTP

sudo phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 0 -m

PTP Configuration File (/etc/ptp4l.conf):

ini

CopyEdit

[global]

# General Configuration

twoStepFlag 1

logAnnounceInterval 1

logSyncInterval 0

logMinPdelayReqInterval -2

syncReceiptTimeout 3

delayAsymmetry 0

# PTP Profile

gmCapable 0

priority1 128

priority2 128

domainNumber 24

This configuration sets up O-DU as a PTP Boundary Clock (BC) to forward time to O-RU.

Example Configuration of SyncE on O-DU

SyncE is configured on the Ethernet interface (e.g., eth0) using hardware timestamping.

bash

CopyEdit

# Enable SyncE on Ethernet interface

sudo ethtool --set-phy-tunable eth0 sync-e on

# Configure clock source for SyncE

echo "eth0" | sudo tee /sys/class/net/eth0/device/clock_source

# Verify SyncE status

sudo ethtool -m eth0

This ensures that SyncE frequency synchronization is propagated from O-DU to O-RU.

Example Configuration of PTP & SyncE on O-RU

O-RU must be configured as a PTP slave and SyncE client to receive synchronization.

bash

CopyEdit

# Run ptp4l in Slave mode to sync with O-DU

sudo ptp4l -i eth0 -m -s -f /etc/ptp4l-slave.conf

# Sync system clock with PTP

sudo phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 0 -m

# Enable SyncE on O-RU Ethernet interface

sudo ethtool --set-phy-tunable eth0 sync-e on

PTP Slave Configuration File (/etc/ptp4l-slave.conf):

ini

CopyEdit

[global]

twoStepFlag 1

clockClass 255

priority1 255

priority2 255

domainNumber 24

This ensures O-RU receives PTP time synchronization from O-DU and SyncE frequency synchronization.

6. Best Practices for O-RAN Synchronization Deployment

1. Choose the right topology:

·       Small-scale deployments → LLS-C1

·       Reliable sync with backup → LLS-C2

·       High-precision networks → LLS-C3 or C4

2. Use boundary clocks and transparent clocks to reduce synchronization errors over Ethernet transport.

3. Implement GNSS as a backup source to prevent sync failures.

4. Monitor synchronization metrics continuously to detect and correct drifts.

7. Conclusion

Timing and synchronization are fundamental to O-RAN networks, ensuring efficient and stable 5G performance. Depending on deployment needs, different synchronization architectures (LLS-C1 to C4) can be used, leveraging technologies like IEEE 1588 PTP, SyncE, and GNSS.

Choosing the right synchronization strategy and implementing best practices will enable telecom operators to build high-performance, reliable, and scalable O-RAN networks.

References:

1. O-RAN Synchronization Configurations, https://www.fibrolan.com/PTP-Switch

2. Introduction to Precision Time Protocol (PTP), https://networklessons.com/cisco/ccnp-encor-350-401/introduction-to-precision-time-protocol-ptp

3. O-RAN Control, User and Synchronization Plane Specification, https://specifications.o-ran.org/specifications