> 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/plan-your-network/architecture/distributed.md).
# Distributed
A distributed deployment splits the gNB. The Central Unit and Distributed Unit run on Onyx Edge; the access point contains only the Radio Unit. The two connect over eCPRI fronthaul using the O-RAN 7.2x functional split.
Onyx Edge therefore hosts the 5G Core, the CU and the DU together in one appliance, with the radios pushed out to where coverage is needed.
## What it looks like
CU and DU on Onyx Edge, RU in the AP, joined by eCPRI fronthaul. Each RU is still its own cell.
Each RU is still its own cell. A device crossing between two RUs performs a handover, exactly as in an integrated deployment. Removing that handover is what [Super Cell](/plan-your-network/architecture/super-cell.md) adds, by putting an FHM in this same path.
## Radio units
Every model in the `5g-access-points` hardware family is an O-RAN RU. Their specification sheets describe them as *O-RAN compliant Access Point*, Option 7-2a Category A, and their network port is labeled **Fronthaul**.
| Model | Placement | MIMO | Bands |
| ------------ | --------- | ---- | --------------------- |
| **G105** | Indoor | 4T4R | n48, n78 (n77 future) |
| **G505** | Outdoor | 4T4R | n48, n78 |
| **G506** | Outdoor | 4T4R | n77, n78 |
| **G509-n26** | Outdoor | 2T2R | n26 (FDD) |
| **G509-n28** | Outdoor | 2T2R | n28 (FDD) |
| **G509-n41** | Outdoor | 4T4R | n41 |
| **G509-n79** | Outdoor | 4T4R | n79 |
The G509 family is the route to bands outside mid-band TDD. n26 and n28 are FDD and sub-GHz, so they propagate considerably further at correspondingly narrower channel bandwidths. See [Private 5G Spectrum](/private-5g-spectrum.md).
{% hint style="info" %}
**These are a per-cell choice, not a per-site one.** Distributed cells can share a network with integrated gNB APs. The RUs use the CU and DU on Onyx Edge; an integrated AP brings its own and attaches to the same Core. Both appear in the same Onyx Portal.
{% endhint %}
## Choose this when
* You need a band the integrated gNB family does not cover, particularly n26, n28, n41 or n79.
* Radios must sit where baseband cannot, for example distributed around a plant while the Edge stays in a comms room.
* The deployment will grow into [Super Cell](/plan-your-network/architecture/super-cell.md). Distributed is the foundation it builds on, so starting here avoids replacing hardware later.
* You are feeding a DAS head end, which takes RF from the radio layer.
## Choose something else when
* One or two APs would cover the site and cabling is awkward. Fronthaul is stricter than backhaul, so [Integrated](/plan-your-network/architecture/integrated.md) is simpler.
* Devices cross RU boundaries mid-session. Distributed alone still hands over; add an FHM and use [Super Cell](/plan-your-network/architecture/super-cell.md).
## What it costs
| | |
| ------------- | --------------------------------------------------------------------------------------------- |
| **Hardware** | Onyx RUs ยท Onyx Edge (Core + CU + DU) |
| **Transport** | eCPRI fronthaul, 10 Gbps SFP+ per RU. Fiber in practice: copper reaches only as far as a rack |
| **Timing** | IEEE 1588v2 PTP and SyncE across the fronthaul |
Fronthaul is the real constraint. It carries far more than user traffic and is sensitive to latency and timing, so it dictates cable type, distance and switching in a way ordinary backhaul does not.
## Design considerations
**Fronthaul sets where radios can go.** Plan cable routes before finalizing radio positions, not after. This is the most common source of late redesign.
**Timing is part of the design.** PTP and SyncE must reach every RU. TDD depends on frame alignment, and a radio that loses timing does not serve traffic.
**Boundaries still exist.** Splitting the gNB does not remove handover. Each RU remains its own cell until an FHM combines them.
**One Edge, many radios.** CU and DU are centralized, so capacity and policy are managed in one place rather than per AP.
***
## Related
* [Super Cell](/plan-your-network/architecture/super-cell.md): add an FHM and this becomes one logical cell
* [Integrated](/plan-your-network/architecture/integrated.md): when the AP can be the whole gNB
* [5G Onyx Architecture Solution Brief](https://docs.gxc.io/docs/solution-briefs/5g-onyx-architecture-solution-brief)
---
# 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/plan-your-network/architecture/distributed.md?ask=&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.
