> 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/deploy-your-first-network.md).
# Deploy Your First Network
This page covers the ground between a validated design and a network carrying real traffic. It is a map, not a manual — each stage links to the operations guide that documents it in full.
Read it end to end before you begin. Several stages have prerequisites that are painful to discover late.
{% hint style="info" %}
**NOTE**: This page assumes you have a design and hardware on site. If you are still sizing the network, start with [*Plan Your Network*](/plan-your-network.md). If you are still deciding whether private cellular fits, start with [*Is Onyx Right for You?*](broken://pages/554f53a74347337006e86a848ba9aa386fc1e457).
{% endhint %}
## Before you start
Have these settled. Each one blocks a later stage.
| Prerequisite | Why it blocks |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Spectrum access confirmed** | On CBRS, radios cannot transmit until the SAS authorises them. Outside the US, a local licence must be in hand. |
| **CPI arranged** (CBRS only) | A Certified Professional Installer must verify and sign each radio's installation record. Certification is held by an individual — line one up before installation day, not after. |
| **Site prepared** | Rack space, power, and cooling for Onyx Edge. Fronthaul cabling to every radio location. Mounting, and for outdoor units enclosures, grounding, and surge protection. |
| **Onyx Portal account activated** | Portal access requires account activation and MFA enrolment. |
| **Networking mode decided** | NAT or Bridge determines how Onyx integrates with your LAN. Changing it later means reconfiguring the network. |
| **SIMs on hand** | Devices cannot attach without provisioned credentials. |
| **Device compatibility verified** | Confirm your actual device population supports your band against [*End Devices*](https://docs.gxc.io/devices). |
### Decide NAT or Bridge now
This choice shapes everything downstream, so make it deliberately.
**NAT mode** — Onyx Edge acts as a secure gateway between the private RAN and your enterprise network. It assigns device IP addresses from a local pool, and NAT on the N6 interface means your LAN sees only the Onyx Edge address. Devices, APs, and FHMs are not directly reachable from the enterprise network. Choose this for strong isolation and simple IP management, where you do not need to reach individual devices.
**Bridge (APN-on-VLAN) mode** — Onyx Edge bridges device traffic directly into enterprise VLANs with no NAT. Each APN maps to a dedicated VLAN, your own DHCP assigns device addresses, and devices appear as native enterprise devices with full visibility and policy control. The N6 interface becomes a VLAN trunk. Choose this for deep integration with existing enterprise routing, security, and management tooling.
Bridge mode is also what makes per-device-group segmentation possible, so if network segmentation matters to your security posture, it is the stronger choice. See [*4G & 5G Onyx Networking Modes*](https://docs.gxc.io/application-notes/4g-and-5g-onyx-networking-modes).
## The sequence
Work through these in order. Each stage depends on the one before it.
{% stepper %}
{% step %}
### Get into the Portal
Activate your Onyx Portal user account, install an authenticator app, and complete MFA enrolment. Store your MFA backup codes somewhere you will still be able to reach them if you lose the device.
Where your organisation uses an identity provider, the Portal supports SSO instead — see [*4G & 5G Onyx Portal Integration with Customer IdP*](https://docs.gxc.io/application-notes/4g-and-5g-onyx-portal-integration-with-customer-idp).
→ [*Onyx Portal Login and Navigation*](https://docs.gxc.io/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations/onyx-portal-login-and-navigation)
{% endstep %}
{% step %}
### Install the hardware
Rack and power the Onyx Edge. Mount radios at the locations your coverage plan specifies and run fronthaul to each. Where an FHM is in the design, cable the RUs to it and the FHM to the Edge.
Record the exact installed position of every radio as you go — geographic coordinates, height above ground level, azimuth, downtilt, and antenna gain. On CBRS these are the values the CPI certifies and the SAS registers, and they must match physical reality. Capturing them during installation is far easier than deriving them afterwards.
→ Per-model installation guides under [*Onyx Hardware*](https://docs.gxc.io/hw/onyx-hardware/gxc-5g-and-lte-hardware)
{% endstep %}
{% step %}
### Create the venue
A venue represents the physical site. Create it first — equipment is placed within it.
Upload and calibrate floor plans while you are here. Calibration is what makes equipment positions and coverage visualisation meaningful later, and it is quick to do now and tedious to retrofit.
→ [*Manage Venues*](https://docs.gxc.io/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations/manage-venues)
{% endstep %}
{% step %}
### Create the network
Create the network under the correct customer account, then configure Core and RAN parameters — including the networking mode you decided above.
{% hint style="warning" %}
**NOTE**: Network creation requires GXC Administrator, Partner Administrator, or Super Administrator privileges, and networks can only be created under customer accounts. Confirm you have the right role and the right account selected before you start.
{% endhint %}
→ [*Manage Networks*](https://docs.gxc.io/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations/manage-networks)
{% endstep %}
{% step %}
### Add the equipment
Register the Onyx Edge, then the APs, then the FHM and any Mesh Nodes. Place each on the venue floor plan as you add it.
→ [*Manage Equipment*](https://docs.gxc.io/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations/manage-equipment)
{% endstep %}
{% step %}
### Register with the SAS — CBRS only
Radios on CBRS cannot transmit until the SAS authorises them. The full workflow runs: CPI account setup, deployment creation in the SAS portal, CBSD records for each radio, CPI signing, SAS parameter configuration in the Onyx Portal, then grant verification.
Onyx handles SAS communication through an integrated Domain Proxy, so you manage this from the Portal rather than radio by radio. Large or DAS deployments can use bulk registration.
Expect this stage to take longer than the others. It involves an external portal, a credentialed individual, and a regulator's system.
→ [*4G & 5G Onyx CBRS SAS Registration*](https://docs.gxc.io/application-notes/4g-and-5g-onyx-cbrs-sas-registration)
{% endstep %}
{% step %}
### Create subscriber groups, then subscribers
Groups come first — a subscriber account is assigned to a group, and the group carries the QoS and policy that applies to its devices.
Define groups along the lines your workloads actually need. Cameras, handhelds, AGVs, and laptops have genuinely different requirements, and separating them here is what lets you police them independently later. Collapsing everything into one group is the most common day-one mistake, and it removes your ability to protect critical traffic under load.
Then create subscriber accounts and provision SIMs. Bulk assignment is available for larger fleets. Enable IMEI verification where the device population is known — it binds each SIM to authorised hardware and blocks SIM-swap attacks.
→ [*Manage Subscribers*](https://docs.gxc.io/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations/manage-subscribers)
{% endstep %}
{% step %}
### Attach a device and verify
Insert a provisioned SIM, confirm the device attaches and gets an address, and run a subscriber speed test from the Portal.
Then verify the network rather than the single device:
* **Coverage** — walk the site and check signal at the planned worst-case points, not just near the radios.
* **Uplink under load** — for most workloads the uplink binds first. Test it with several devices active, not one.
* **Mobility** — move a device across the full coverage area while a session is open. On a Shared Cell deployment there should be no handover interruption at all.
* **Alerts** — confirm alerts are configured and reaching someone.
→ [*Manage Alerts*](https://docs.gxc.io/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations/manage-alerts) · [*Analytics*](https://docs.gxc.io/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations/analytics)
{% endstep %}
{% step %}
### Apply QoS
With traffic flowing, map each workload to the right 3GPP 5QI so applications share spectrum without competing. This is what keeps a control loop responsive while a firmware download runs.
Give bulk traffic — firmware, backups — a low-priority non-GBR class and a schedule. Left unclassified, it will contend with production traffic at the worst moment.
[*Network Requirements at a Glance*](https://docs.gxc.io/use-cases/network-requirements-at-a-glance) lists throughput, latency, and 5QI mapping for ten common workflows, and is the fastest way to get this right.
→ [*Manage Traffic*](https://docs.gxc.io/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations/manage-traffic)
{% endstep %}
{% endstepper %}
## Before you call it done
* **Security posture reviewed** — segmentation applied, firewall policy in place, RBAC roles assigned, MFA enforced. See [*Security and Compliance*](/security-and-compliance.md).
* **Log export configured**, if your compliance regime needs retention beyond the Portal's 60 days.
* **Alerts routed** to someone who will act on them.
* **An owner named.** A private network is infrastructure. Subscriber lifecycle, firmware updates, alert response, and — on CBRS — the SAS relationship all need a person.
## Related reading
* [*5G Onyx Portal 4.x Operations*](/docs/network-configuration-and-operations-guides/5g-onyx-portal-4.x-operations.md) — the complete 5G operations guide
* [*4G Onyx Portal 4.x Operations*](/docs/network-configuration-and-operations-guides/4g-onyx-portal-4.x-operations.md) — the LTE equivalent
* [*4G Onyx Edge On-Premises 4.x Installation and Operations*](/docs/network-configuration-and-operations-guides/4g-onyx-edge-on-premises-4.x-installation-and-operations.md) — Edge software installation and upgrade
* [*5G Onyx Portal 4.x Alerts Reference*](https://docs.gxc.io/docs/network-configuration-and-operations-guides/5g-onyx-portal-4.x-alerts-reference) — every alert and what it means
## Contact GXC
To get in touch with GXC, please visit .
---
# 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/deploy-your-first-network.md?ask=&goal=
```
`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.