> 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.

Settle whether that class describes your situation before spending 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 the alternatives

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

### Wi-Fi

<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, so far less contention you cannot control. Most Onyx deployments run on CBRS GAA, where there is no license to buy and no auction to enter. Much of Europe and Asia issues a local site license for a small administrative fee.</td></tr><tr><td><strong>Radios for the same area</strong></td><td>One AP per 1,500 to 2,000 sq ft in dense racking. For high-bay warehousing, 28 to 50 APs per 100,000 sq ft.</td><td>About 7,000 sq ft per AP in the same conditions, so 13 to 15 per 100,000 sq ft, and 5 to 6 where racking is lighter. The gap widens sharply outdoors, where one radio can cover around 300,000 sq ft.</td></tr><tr><td><strong>Skills and operations</strong></td><td>Familiar to any IT team.</td><td>RF planning and SIM lifecycle management are new to most IT teams. This is the real adoption cost, and it is effort rather than hardware.</td></tr></tbody></table>

Fewer radios is where the money is. A radio count that is two to three times lower indoors also means that much less cabling, switching, PoE budget, mounting and commissioning labor, and that gap compounds outdoors, where Wi-Fi needs power and backhaul carried to every access point across open ground. The costs that remain are the skills to plan it and the discipline to manage SIMs, which is why the honest summary is that private cellular usually costs less to build and more to learn.

{% 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 %}

### Public cellular

A carrier SIM in every device avoids all of the above: no spectrum to acquire, no RF planning, no SIM estate of your own, and it works the moment the device powers on.

It stops working where the carrier has not built. Inside a warehouse, down a pit, in a basement, or across a site that was never commercially worth covering, you get whatever the macro network happens to deliver, and there is no mechanism to improve it. Priority is not yours either: an operational handset competes with every consumer phone on the same cell, and the busiest moments on a public network are usually the busiest moments on site.

Traffic also leaves. It goes to the carrier core and comes back, so an application running ten meters from the device is reached by a round trip through someone else's network. Per-device data charges then scale with the fleet rather than with the infrastructure.

Public cellular suits a small number of devices spread across a wide area, where coverage already exists and nothing is latency-critical. It does not suit a dense site, a controlled process, or traffic that has to stay local.

### Satellite

Satellite answers a different question. One terminal is a route to the internet, not coverage across a site, and the two are often confused because both are described as connectivity.

[Starlink](https://docs.gxc.io/docs/application-notes/satellite-backhaul-with-starlink) and its equivalents give a remote site a working WAN in an afternoon. They do not serve hundreds of devices, do not reach beyond the terminal, and offer a latency and jitter profile nobody can engineer against. The uplink is also the narrow direction, typically 20 to 44 Mbps against 135 to 310 down, while private 5G sites are usually uplink-heavy.

So satellite and private cellular are not competing choices. A remote site generally needs both: satellite for the route off site, private 5G for everything that happens on it, and local breakout keeping the second off the first.

### What each is for

|                      |                                                          |
| -------------------- | -------------------------------------------------------- |
| **Wi-Fi**            | capacity in a room, for devices that stay in it          |
| **Public cellular**  | a few devices over a wide area that is already covered   |
| **Satellite**        | a route to the internet where no fiber reaches           |
| **Private cellular** | coverage, capacity and control across a site you operate |

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