O-RAN Fronthaul Sync: How Open RAN Networks Get Their Time

Why O-RAN cares about timing in a particular way

Open RAN (O-RAN Alliance specifications) decomposes the traditional monolithic mobile base station into separate components — most importantly the radio unit (O-RU) at the cell site and the distributed unit (O-DU) at a centralised compute location, connected by an open fronthaul interface. This architectural split, which is the central premise of Open RAN's vendor-disaggregation pitch, places new constraints on the timing fabric. The O-RU and O-DU must agree on time precisely enough to coordinate the radio waveform, but they no longer share a single physical chassis with a common clock.

The O-RAN Alliance has defined four sync configurations (variously called "sync architectures" or "LLS configurations") that describe different ways to deliver time to the O-RU. Each makes different assumptions about where the primary reference time clock lives, whether the fronthaul transport network is PTP-aware, and which devices participate in the PTP timing path. Choosing between them is one of the most consequential architectural decisions in any Open RAN deployment.

The four LLS sync configurations

The four configurations are conventionally numbered LLS-C1, LLS-C2, LLS-C3 and LLS-C4. They differ in where the PRTC is placed and whether the fronthaul transport network actively participates in the PTP timing chain.

LLS-C3: the dominant production architecture

LLS-C3 is what most large-scale Open RAN deployments actually look like in 2026. A small number of grandmasters at central reference sites distribute time downstream via PTP G.8275.1 across the operator's fronthaul transport network, through a chain of PTP-aware boundary clocks, ultimately reaching the O-DU and then the O-RU.

The advantages are operational. A single grandmaster fleet covers many cell sites, GNSS hardening is concentrated at a small number of central locations, and the observability surface lives in one place. Failover is centralised: when one PRTC degrades, the BMCA at every downstream boundary clock automatically switches to a backup PRTC without any per-site intervention.

The disadvantage is transport-network dependency. LLS-C3 only works if every device on the path between the central PRTC and the O-RU is PTP-aware (G.8275.1 boundary clock or transparent clock) and configured consistently. This is feasible in greenfield 5G builds but very hard in brownfield deployments where the transport network was built for IP backhaul, not for timing distribution. Operators going LLS-C3 in a brownfield environment should expect a significant transport-side upgrade project before the timing fabric is fit for purpose.

LLS-C4: when transport just can't carry PTP

LLS-C4 places a GNSS-disciplined grandmaster directly at the O-RU site, eliminating any dependency on the fronthaul transport network's PTP capability. This is the right answer when the transport network is owned by a third party, or when the network was built before PTP was a requirement and can't be upgraded economically. It is also the right answer for genuinely isolated sites — remote locations where the operational simplicity of "just put a GNSS receiver on the roof" outweighs the cost of the additional hardware.

The trade-offs are real. Every cell site now has its own GNSS receiver, which means every cell site is independently exposed to local GNSS environmental issues — antenna access, multipath, jamming, ionospheric scintillation. Hardening 1,000 cell sites against GNSS denial is operationally heavier than hardening 5 central PRTC sites. The capex per site is higher, the observability surface is distributed, and incident response is harder because each site fails independently.

LLS-C4 also still requires the cell site grandmaster to deliver PTP to the O-RU over a short local link, which means even an LLS-C4 deployment needs at least one PTP hop and the corresponding configuration discipline. "Distributed PRTC" does not mean "no PTP."

Where TimeBeat fits in O-RAN sync

TimeBeat hardware (Open Time Appliance, Open TimeCard) supports both centralised LLS-C2/C3 and distributed LLS-C4 architectures, with G.8275.1 as the default profile and the right BMCA defaults out of the box. Our Sync Insight platform is specifically designed to give Open RAN operators the end-to-end observability of the PTP timing chain that LLS-C3 deployments depend on — every boundary clock, every grandmaster, every phase offset, in one dashboard.

We are also active in the O-RAN Alliance technical working groups defining the next generation of fronthaul timing requirements, and we contribute to the linuxptp and OCP TAP open-source projects that the timing stack is built on. Open hardware, open standards, open tooling — Open RAN deserves nothing less.