> 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/integrated.md).

# Integrated

An integrated deployment puts the whole gNB inside the access point. The AP performs the Central Unit, Distributed Unit and Radio Unit functions itself, and connects to Onyx Edge over ordinary backhaul. Onyx Edge provides the 5G Core.

This is the simplest Onyx architecture. There is no fronthaul, no Fronthaul Multiplexer, and no timing distribution to design.

## What it looks like

<figure><img src="https://2839344875-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcsOm7izkwc75UBmow1N0%2Fuploads%2FHFmm5Dv9CLLC3sNw1Ens%2Farch-integrated.svg?alt=media" alt="Integrated architecture: the gNB AP performs CU, DU and RU, connecting to Onyx Edge over ordinary backhaul. Each AP is its own cell."><figcaption><p>The AP is the whole gNB. Onyx Edge provides the Core, and each AP is its own cell.</p></figcaption></figure>

Each AP is a complete base station and its own cell. A device moving between two APs performs a normal inter-cell handover.

## Access points

Every model in the `5g-gnb` hardware family is an integrated base station. Their specification sheets describe them as *integrated base station (gNB)*, and their network port is labeled **Backhaul**, not Fronthaul, which is the quickest way to tell the two families apart.

| Model            | Placement | MIMO | Power per port | Bands               |
| ---------------- | --------- | ---- | -------------- | ------------------- |
| **G227**         | Indoor    | 2T2R | 250 mW         | n48, n78            |
| **G430**         | Indoor    | 4T4R | 250 mW         | n48, n78            |
| **G228**         | Outdoor   | 2T2R | 250 mW         | n48, n77, n78       |
| **G238-n78H-DC** | Outdoor   | 2T2R | 3 W            | n78 (3600–3800 MHz) |
| **G243-n48**     | Outdoor   | 2T2R | 5 W            | n48                 |
| **G243-n78H-AC** | Outdoor   | 2T2R | 10 W           | n78 (3600–3800 MHz) |
| **G244-n48**     | Outdoor   | 2T2R | 5 W            | n48                 |
| **G443**         | Outdoor   | 4T4R | 5 W            | n48, n78            |

For full specifications see [Onyx Hardware](https://docs.gxc.io/hw/onyx-hardware/gxc-5g-and-lte-hardware).

{% hint style="info" %}
**NOTE**: Select outdoor models also act as Mesh APs, serving as gateway nodes for Mesh Node wireless backhaul. This is currently supported on the G228 and the G244.
{% endhint %}

{% hint style="info" %}
**These are a per-cell choice, not a per-site one.** An integrated AP can sit on the same network as RU-based cells. It brings its own CU and DU and attaches to the Core on Onyx Edge, so a site can run an integrated AP in one area and a Distributed or Super Cell deployment in another.
{% endhint %}

{% hint style="info" %}
**LTE works this way too, and only this way.** The models above are the 5G gNB family. Every Onyx LTE access point is also a complete base station with the RAN stack onboard: the G100 and G101, the G229 and G249, and the G501. Because GXC builds no LTE Radio Unit and no LTE fronthaul, Integrated is the only shape an LTE cell takes.
{% endhint %}

## Choose this when

* The site needs a small number of APs, and each one can cover its area on its own.
* Cell boundaries fall somewhere devices do not routinely cross while holding a session, so handover is acceptable.
* Cabling is constrained. Backhaul is ordinary IP transport, so it is far more forgiving than fronthaul on distance, media and timing.
* You want the shortest path to a working network, or a pilot that will grow later.

## Choose something else when

* Devices move continuously across the coverage area and cannot tolerate a handover gap. AGVs, live video contribution and full-duplex intercom all fail here. Use [Super Cell](/plan-your-network/architecture/super-cell.md) instead.
* Many radios must serve one large space as a single cell.
* You need the RF flexibility of separating the radio from the baseband, for example feeding a DAS head end.

## What it costs

|                  |                                                                          |
| ---------------- | ------------------------------------------------------------------------ |
| **Hardware**     | Integrated gNB APs · Onyx Edge (Core)                                    |
| **Not required** | FHM, fronthaul fiber, PTP/SyncE timing distribution                      |
| **Transport**    | Standard IP backhaul to each AP, over CAT6, fiber or a wireless mesh hop |

Because there is no FHM and no fronthaul, this is the lowest-cost and lowest-complexity option per site, and the easiest to extend one AP at a time.

## Design considerations

**Plan for handover at the boundaries.** Each AP is its own cell. Work out where cell edges land relative to how people and machines actually move, and confirm any latency-sensitive workload can absorb the interruption.

**Capacity is per AP.** There is no pooling across APs. Size each one against the devices in its own coverage area.

**Backhaul is not fronthaul.** The AP needs enough backhaul for its user traffic, but none of the latency and timing discipline that eCPRI fronthaul demands.

***

## Related

* [Distributed](/plan-your-network/architecture/distributed.md): separating the radio from the baseband
* [Super Cell](/plan-your-network/architecture/super-cell.md): many radios behaving as one cell
* [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/integrated.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.