> 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/is-onyx-right-for-you.md).

# Is Onyx Right For You?

Private Cellular is not a better Wi-Fi. It is a different tool, with a different cost profile and a different set of obligations, and it wins decisively on a specific class of problem while being poor value on others.

This page helps you decide whether that class describes your situation — before you spend time sizing a network in [*Plan Your Network*](/plan-your-network.md).

## The short version

Private cellular earns its place when **one or more of these is true**:

* Coverage has to be **uniform** across a large or awkward space — a warehouse with moving racking, a campus with outdoor gaps, a facility whose RF environment changes as inventory moves.
* Devices **move continuously** and cannot tolerate a connection gap while roaming.
* The **uplink** is the demanding direction — cameras, sensors, inspection capture, video contribution.
* Latency has a **hard ceiling** that must hold under load, not on average.
* Access must be controlled by **credentials you issue and revoke**, with traffic that never leaves your site.
* The environment is **hostile to Wi-Fi** — metal, dense racking, concrete, RF congestion, long distances.

If none of these apply, well-designed enterprise Wi-Fi is usually cheaper and entirely adequate. That is a legitimate answer.

## Against Wi-Fi

The honest comparison is not "which is better" but "where does each stop working".

<table><thead><tr><th width="200"></th><th>Wi-Fi</th><th>Private cellular</th></tr></thead><tbody><tr><td><strong>Mobility</strong></td><td>Roaming between APs interrupts the connection. Usually invisible for browsing; fatal for an AGV control loop or a live video feed.</td><td>Handover is managed by the network. With Onyx Shared Cell, devices moving inside the coverage area see one cell and perform no handover at all.</td></tr><tr><td><strong>Coverage per radio</strong></td><td>Shorter range, more APs, more co-channel interference to plan around.</td><td>Longer range at comparable power; substantially longer on sub-GHz bands.</td></tr><tr><td><strong>Determinism</strong></td><td>Contention-based. Throughput and latency degrade as the medium gets busy — no reservation mechanism.</td><td>Scheduled. QoS is enforced per flow via 3GPP 5QI, so a control loop and a bulk download coexist without competing.</td></tr><tr><td><strong>Uplink</strong></td><td>Optimized for downlink-heavy consumer traffic.</td><td>TDD split is configurable — Onyx supports up to 63% uplink (<code>DSUUU</code>) for camera- and sensor-heavy sites.</td></tr><tr><td><strong>Access control</strong></td><td>Shared credentials, certificates, or a captive portal.</td><td>SIM/eSIM credentials you provision and revoke centrally. No password to leak.</td></tr><tr><td><strong>Spectrum</strong></td><td>Unlicensed and shared with everyone nearby.</td><td>Licensed, coordinated, or shared-with-priority. Far less contention you cannot control.</td></tr><tr><td><strong>Cost and effort</strong></td><td>Lower. Familiar to any IT team.</td><td>Higher. Requires spectrum access, SIM management, and RF planning.</td></tr></tbody></table>

{% hint style="info" %}
**NOTE**: These are not mutually exclusive. A common pattern is Wi-Fi for general office and guest traffic, private cellular for the operational workloads that Wi-Fi cannot hold — with both running in the same building.
{% endhint %}

## LTE or 5G

Onyx runs both, on **distinct hardware platforms**. This makes technology selection an early decision rather than a late one — it changes the bill of materials, not just a configuration.

|                        | **Onyx LTE**                                                              | **Onyx 5G**                                                    |
| ---------------------- | ------------------------------------------------------------------------- | -------------------------------------------------------------- |
| **Latency**            | Suitable above \~50 ms                                                    | Supports real-time workloads below 30 ms                       |
| **Typical workloads**  | General enterprise connectivity, telemetry, IoT                           | Real-time analytics, robotics, machine vision, broadcast video |
| **Peak AP throughput** | \~40 Mbps @ 20 MHz baseline; \~105 Mbps/cell at 20 MHz in default Config1 | 300+ Mbps with 4×4 MIMO @ 40 MHz, deployment dependent         |
| **Channel bandwidth**  | Up to 40 MHz with Carrier Aggregation; 20 MHz per cell in Dual Carrier    | 20, 40, 50, 100 MHz (band and RU dependent)                    |
| **Devices per AP**     | Up to 96 (SC); 96 + 96 (DC)                                               | Up to 128 (SC)                                                 |
| **Bands**              | B48 (CBRS), B1, B3                                                        | n48, n77, n78, n41, n79, n28, n26                              |
| **Shared Cell**        | DAS-based coverage extension                                              | FHM-based — up to 8 RUs per FHM, up to 64 RUs as one cell      |

**Choose LTE** when the workload is telemetry, IoT, voice, or general connectivity; latency above 50 ms is acceptable; and CBRS is your spectrum. It is the lower-cost path and entirely sufficient for a large share of enterprise deployments.

**Choose 5G** when you need sub-30 ms latency, uplink-heavy capacity, more than 40 MHz of channel, handover-free mobility across a large floor, or a band other than CBRS.

{% hint style="warning" %}
**NOTE**: Latency requirements are the most common reason a design has to be revisited. If any workload has a hard latency ceiling below 50 ms, that decides the technology — no amount of capacity headroom on LTE will meet it.
{% endhint %}

## What a deployment actually requires

Worth knowing before you commit, not after.

**Spectrum access.** You need a band you are permitted to transmit on. In the US that usually means CBRS, which brings SAS registration, Certified Professional Installer sign-off on every radio, and grants that the SAS can modify or revoke during normal operation. Elsewhere it usually means a local license in n77/n78. See [*Private 5G Spectrum and Regulations*](/private-5g-spectrum.md).

**Devices that support your band.** Not every phone, tablet, or module supports CBRS or your regional band. Check the [*End Devices*](https://docs.gxc.io/devices) compatibility matrix against the actual device population — this is a frequent late surprise, particularly with existing handheld fleets.

**SIM provisioning.** Every device needs a credential, issued and managed through the Onyx Portal. For a fleet of a few hundred handhelds this is a real operational process, not an afterthought.

**Site infrastructure.** Onyx Edge needs rack space, power, and cooling. Radios need cabling — fronthaul over fiber or Ethernet — plus PoE or local power, mounting, and in outdoor deployments enclosures, grounding, and surge protection. Where cabling is genuinely impractical, Mesh Nodes provide wireless backhaul, but they are an exception rather than the default.

**RF planning.** The [*Onyx ROM AP Calculator*](https://www.gxc.io/rom-ap-calculator/) gives a reliable starting estimate. Sites with significant clutter, height variation, difficult propagation, or strict coverage SLAs need a survey. GXC offers RF design as a service.

**Ongoing operation.** Someone owns the Portal: monitoring, alerts, subscriber lifecycle, firmware updates, and — on CBRS — the SAS relationship.

## When it is probably not the right fit

Said plainly, so you do not spend weeks discovering it:

* **A single small office with static users.** Wi-Fi 6/6E does this well for far less.
* **Downlink-dominant general internet access.** You are paying for capability you will not use.
* **No route to spectrum.** Without a band you can transmit on, there is no deployment. Settle this first.
* **A device fleet that cannot support the band**, with no budget to replace it.
* **No one to operate it.** A private network is infrastructure. It needs an owner.

## If it does fit

{% stepper %}
{% step %}

## Introduction

{% content-ref url="/pages/UmOPXP3eSkJOt9LBhZON" %}
[Introduction to GXC Onyx](/introduction.md)
{% endcontent-ref %}
{% endstep %}

{% step %}

## Spectrum and regulations

{% content-ref url="/pages/f1bf111d86c09d920bb9d1837dc0f2404370b929" %}
[Private 5G Spectrum](/private-5g-spectrum.md)
{% endcontent-ref %}
{% endstep %}

{% step %}

## Plan your network

{% content-ref url="/pages/d17dc6876a5d6309a6cbe730c19e8a65af773626" %}
[Plan Your Network](/plan-your-network.md)
{% endcontent-ref %}
{% endstep %}
{% endstepper %}

To see the requirements real workloads produce — throughput, latency, jitter, 5QI mapping, TDD pattern — see [*Use Cases/Workflows*](https://docs.gxc.io/usecases-workflows/). If one of them resembles your situation, it will tell you more about your design than any general guidance here.

## 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.gxc.io/is-onyx-right-for-you.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.