> For the complete documentation index, see [llms.txt](https://docs.gxc.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gxc.io/docs/application-notes/4g-and-5g-timing-and-synchronization.md).

# 4G & 5G Timing and Synchronization

Which box holds the clock depends on where the RAN stack runs. That one rule decides whether you need GPS antennas at every radio, a PTP grandmaster, or neither.

## Introduction

TDD networks carry downlink and uplink on the same frequency and separate them in time. Every radio sharing a band has to agree on when each slot begins. Radios that disagree will transmit while a neighbor is listening, and the result is interference that presents as poor coverage, low throughput and dropped sessions. Adding radios or power makes it worse.

Synchronization is what holds that agreement. For any deployment there are two questions, and the first one is already answered by the architecture.

## Synchronization follows the RAN stack

The box running the RAN stack is the box that needs a time reference. Where that box sits is the architecture decision, so the timing design falls out of it.

|                 | RAN stack runs | What you synchronize | Radio has its own GPS        |
| --------------- | -------------- | -------------------- | ---------------------------- |
| **Integrated**  | in the AP      | every AP             | yes, a GPS port on each unit |
| **Distributed** | on Onyx Edge   | the Onyx Edge        | no                           |
| **Super Cell**  | on Onyx Edge   | the Onyx Edge        | no                           |

### Integrated: each radio holds its own reference

Every 4G AP and every 5G gNB carries a GPS port and supports IEEE 1588v2 PTP. Because the AP contains the full stack, it needs the reference locally, and it can take it either way.

The choice is usually decided by the sky, not by accuracy. An outdoor AP on a mast or a rooftop can mount a GPS antenna and use it. An AP in a warehouse ceiling or a basement cannot see satellites at all, so PTP from a grandmaster on the local network is the better option indoors, and often the only one.

### Distributed and Super Cell: the server holds the reference

An O-RAN Radio Unit has no GPS receiver, indoor or outdoor. It takes PTP and SyncE from Onyx Edge across the fronthaul, and it holds no independent reference of its own.

Onyx Edge takes its own reference from a GPS receiver, then acts as the PTP clock source for every RU attached to it. Where a site already runs a timing distribution network, the Edge can take its reference from an upstream grandmaster instead. Contact GXC to confirm the profile before designing around it.

Where an FHM is present, it relays the same timing rather than terminating it. The FHM is a 1588v2 transparent clock, so it forwards PTP and corrects for the delay it adds in passing. A Super Cell timing chain therefore runs Onyx Edge, then FHM, then RU, with one reference at the head of it.

This is a further reason fronthaul is fiber in practice: it carries timing as well as traffic. See [Architecture](https://docs.gxc.io/plan-your-network/architecture).

## When synchronization is required

A single radio with nothing nearby to interfere with has nothing to agree with, and can run on its internal oscillator.

The moment a second radio can reach the first, they need a common reference. Treat radios as co-located if they share a site and a band, or if their coverage overlaps at all. A Super Cell is the clearest case: every RU in it transmits the same cell, so they are a single radio as far as a device is concerned and must be aligned to the sample.

{% hint style="warning" %}
**Free Running is the default on 4G APs.** It is correct for one isolated radio and wrong for every site with a second one. On a multi-radio site it has to be changed deliberately, and a site that works during a single-AP pilot can degrade when the second AP is added.
{% endhint %}

## The three sources

| Source           | Where the time comes from                       | Use it when                                               |
| ---------------- | ----------------------------------------------- | --------------------------------------------------------- |
| **GPS**          | satellites, UTC-traceable                       | the box holding the stack can see the sky                 |
| **PTP**          | a grandmaster on the local network, IEEE 1588v2 | it cannot see the sky, or a timing network already exists |
| **Free Running** | the box's internal oscillator                   | a single isolated radio, with nothing on the band nearby  |

Free Running means slightly different things on each platform. A 4G AP disciplines its internal clock from an NTP server. Onyx Edge runs its oscillator with no external reference at all. NTP corrects long-term drift but delivers accuracy in milliseconds, while TDD slot alignment needs it in microseconds, so neither arrangement substitutes for GPS or PTP where radios share a band.

### Holdover

If GPS is lost, the oscillator keeps running at its last known rate and drifts away from its neighbors. Alignment degrades gradually rather than failing at once, so the symptom is interference that worsens over time rather than an outage.

For planning, treat roughly ten minutes as the window in which alignment stays usable, and design the GPS feed so that outages are shorter than that. A radio that rides out a brief antenna fault is normal; one that spends hours in holdover will interfere with its neighbors.

## Configuring it

### 4G, per access point

Set **Sync Mode** on each AP. See [Manage Access Points](https://docs.gxc.io/docs/network-configuration-and-operations-guides/4g-onyx-portal-4.x-operations/manage-equipment/manage-access-points).

* **Free Running**, **GPS** or **PTP**. The default is Free Running.
* Selecting PTP adds **PTP Transport**, either Ethernet or UDP. The default is Ethernet.

{% hint style="info" %}
**PTP on 4G is qualified for Ethernet transport in Single Carrier mode only.** It is not qualified with PTP over UDP, nor with Dual Carrier or Carrier Aggregation. A dual-carrier site that needs synchronization should plan on GPS.
{% endhint %}

### 5G, at the Onyx Edge

Set **Timing Source** on the Onyx Edge. See [Manage Onyx Edge](https://docs.gxc.io/docs/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations/manage-equipment/manage-onyx-edge).

* **GPS** for any site with more than one cell. A GPS antenna with clear sky visibility is required at the Edge.
* **Free Running** only for an isolated single-cell deployment.

Attached RUs take their timing from the Edge and need no setting of their own.

## Testing and Validation

* [ ] **Sync Status** reads green in Onyx Portal for every Onyx Edge, AP and FHM
* [ ] On 5G, confirm **SyncE State** and **GPS State** on the Onyx Edge status panel
* [ ] Every AP on a multi-radio site reads a source other than Free Running
* [ ] GPS antennas have clear sky visibility from their final mounted position, not from where they were tested
* [ ] On a PTP design, the grandmaster is reachable from every AP that depends on it, and its own reference is confirmed
* [ ] Throughput measured at a cell edge between two co-located radios, which is where a timing fault shows up first
* [ ] Alarm routing confirmed for loss of synchronization, so holdover is noticed while it is still holding

## Best Practices

**Decide timing with the architecture, not after it.** The RAN stack location determines what needs a reference, so the choice is made once the architecture is set. Treating it as a commissioning detail is what produces late GPS antenna orders and roof access requests.

**Survey sky visibility during the RF survey.** A GPS antenna needs a clear view from its mounted position. Establishing that at the same time as the RF measurements costs nothing; establishing it afterward can mean a second visit.

**Indoors, plan for PTP.** Ceiling and basement positions rarely support GPS. A grandmaster on the local network serves every indoor AP, and one grandmaster covers many of them.

**Check synchronization when adding the second radio.** A single-AP pilot runs correctly on Free Running. The fault appears when the site grows, and it looks like an RF problem rather than a timing one.

## Related Documentation

* [Architecture](https://docs.gxc.io/plan-your-network/architecture) : where the RAN stack runs for each of the three modes
* [5G Handovers](https://docs.gxc.io/docs/application-notes/5g-handovers) : mobility between cells, which assumes aligned neighbors
* [5G AP Deployment Modes](https://docs.gxc.io/docs/application-notes/5g-ap-deployment-modes) : carrier and port configurations referenced above
* [Glossary](https://docs.gxc.io/glossary) : PTP, SyncE, GNSS and S-plane definitions

## Contact GXC

To get in touch with GXC, please visit <https://gxc.io/contact-us/>.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.gxc.io/docs/application-notes/4g-and-5g-timing-and-synchronization.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.