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

# Super Cell

A Super Cell deployment places a Fronthaul Multiplexer between Onyx Edge and the radio units, so that many RUs broadcast as **one logical cell** under a single DU.

{% hint style="warning" %}
**Super Cell is** [**Distributed**](/plan-your-network/architecture/distributed.md) **with an FHM added.** Same RUs, same CU and DU on Onyx Edge. The FHM makes several RUs share one cell ID. Without it, each RU is its own cell and devices hand over between them.
{% endhint %}

## What it looks like

<figure><img src="https://2839344875-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcsOm7izkwc75UBmow1N0%2Fuploads%2FN5vq6JhPcbe08E8Awjl6%2Farch-super-cell.svg?alt=media" alt="Super Cell architecture: an FHM makes many RUs broadcast as one logical cell, so devices never cross a cell boundary."><figcaption><p>An FHM makes many RUs broadcast as one cell. Devices move across the whole area without a handover.</p></figcaption></figure>

Because every RU broadcasts the same cell, a device moving across the whole coverage area never crosses a cell boundary. There is no handover to perform, and therefore no handover gap.

## Why this matters

Handover is the failure mode behind most problems in mobile industrial workloads. An AGV that loses its supervisory link stops. A camera feed drops frames. A full-duplex intercom path breaks. Super Cell removes the failure mode rather than tuning around it, because there is no boundary to cross.

## Scale

|             |                                                  |
| ----------- | ------------------------------------------------ |
| RUs per FHM | up to **8**                                      |
| Cascaded    | a primary FHM feeding up to **8 secondary FHMs** |
| Maximum     | **64 RUs** operating as a single Shared Cell     |

An RU running Multi-Port Attach still counts as **one** RU against these limits. It presents two 2×2 sectors on one NR Cell, not two RUs, so it occupies a single FHM slot.

## Configuration

Within one FHM group, RUs can be grouped into cells to trade mobility against capacity:

| Config  | RUs per cell | Cells | Handoffs | Best for                            |
| ------- | -----------: | ----: | -------: | ----------------------------------- |
| **1×8** |            8 |     1 |        0 | Maximum mobility and coverage       |
| **2×4** |            4 |     2 |        1 | Balanced capacity and mobility      |
| **4×2** |            2 |     4 |       ≤3 | Maximum density, high-traffic areas |

Reconfiguring between these is software-only in Onyx Orchestrator. No hardware change and no redeployment. Start at 1×8 and move toward 4×2 as device density grows.

{% hint style="info" %}
**These are a per-cell choice, not a per-site one.** A Super Cell can share a network with the other two. The FHM group forms one cell; an integrated AP or a directly attached RU elsewhere on the site forms another. All of them terminate on the same Core, so one SIM works across the lot.
{% endhint %}

## Choose this when

* Devices move continuously and cannot tolerate a connection gap: AGVs and AMRs, live video contribution, wireless intercom, mobile robotics.
* One large space needs uniform coverage from several radios: a warehouse, a factory floor, an airport pier, an outside broadcast compound.
* The RF environment changes as inventory or structures move, making stable cell planning difficult.
* Dense RU deployment would otherwise create inter-cell interference. Sharing one cell removes it.

## Choose something else when

* The site needs only one or two radios. The FHM has nothing to aggregate. Use [Integrated](/plan-your-network/architecture/integrated.md).
* Coverage areas are genuinely separate, with no one moving between them mid-session. Separate cells are simpler and give more aggregate capacity.
* Peak capacity in one small area matters more than mobility. More cells means more total capacity, so multi-cell may serve better.

## What it costs

|               |                                                                                          |
| ------------- | ---------------------------------------------------------------------------------------- |
| **Hardware**  | Onyx RUs · **FHM** (primary, plus secondaries if cascading) · Onyx Edge (Core + CU + DU) |
| **Transport** | eCPRI fronthaul, RU to FHM and FHM to Edge                                               |
| **Timing**    | IEEE 1588v2 PTP and SyncE, distributed through the FHM                                   |

The FHM is the addition over [Distributed](/plan-your-network/architecture/distributed.md). It aggregates fronthaul from the RUs and holds the timing that keeps them coherent as one cell.

## Design considerations

**Capacity is shared, not multiplied.** Eight RUs in one cell extend coverage; they do not give eight times the capacity. The cell's capacity is divided across everything attached to it. Where density matters more than mobility, use more cells.

**Plan RU placement for the workload, not for even coverage.** For uplink-heavy workflows, radios belong where the devices transmit from, not spaced evenly.

**The FHM is in the fronthaul path.** It needs rack space, power and fronthaul to both the Edge and every RU it serves.

**Start at 1×8.** Mobility is the reason to choose Super Cell. Split into more cells only when measured density requires it, and that change is software-only.

***

## Related

* [Distributed](/plan-your-network/architecture/distributed.md): the architecture this builds on
* [5G Onyx Shared Cell / Super Cell Architecture Solution Brief](https://docs.gxc.io/docs/solution-briefs/5g-onyx-shared-cell-super-cell-architecture-solution-brief)
* [Use Case Workflows](https://docs.gxc.io/usecases-workflows): the workloads that depend on handover-free mobility


---

# 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/super-cell.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.