> 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/getting-started.md). # Getting Started ## Introduction As connectivity becomes core infrastructure, enterprises are increasingly adopting private Long-Term Evolution (LTE) and Fifth Generation (5G) networks that are robust and secure enough to meet their operational requirements for coverage, capacity, mobility, reliability, and access control—capabilities that enterprise Wi-Fi was not designed to deliver at industrial scale. GXC's Onyx™ platform provides a flexible, scalable, and secure foundation for private LTE and 5G deployments across a wide range of indoor and outdoor enterprise environments. It brings coverage, capacity, mobility, reliability, and access control together in a single, integrated system—providing the connectivity infrastructure that modern enterprises need. ### What this Guide Covers This guide provides a practical framework for designing Onyx-powered private cellular networks, guiding you from *“I have a site and a use case”* to a preliminary network design suitable for developing a quote and Bill of Materials (BoM). ### Who This Guide Is For This guide is intended for customer technical teams designing their own deployments and for GXC partners developing customer proposals. ### What You'll Get By the end of this guide, you'll have: * **A radio plan** — The number of radios required, the appropriate radio type, and their recommended placement. * **A network design** — The required infrastructure—Onyx Edge servers, fronthaul, backhaul, switches, and the overall deployment architecture. * **A Bill of Materials (BoM)** — The BoM that you can use to request a quote or build a customer proposal. ### Onyx ROM AP Calculator At each step, the guide walks you through the [*Onyx Rough Order of Magnitude (ROM) AP Calculator*](https://www.gxc.io/rom-ap-calculator/)—a live tool that turns your deployment requirements into design recommendations. This guide also explains the manual methods and reference data behind those results, enabling you to validate the recommendations and develop them into a complete preliminary design and BoM.

Figure: Onyx ROM AP Calculator Interface

{% hint style="info" %} **NOTE**: The calculator's estimates — like the rules of thumb they're built on — are a reliable starting point, not a substitute for an RF survey at sites with significant clutter, height variation, challenging propagation conditions, or strict coverage SLAs. For projects requiring a detailed RF design, GXC offers RF design as a service. {% endhint %} ### What to Bring Before you begin, gather the following information. Each item maps directly to one of the [*ROM Calculator's*](https://www.gxc.io/rom-ap-calculator/) three input panels.
Bring thisROM Calculator Panel / Fields

Your Site

  • Size
  • Indoor/outdoor split
  • Terrain
  • Obstructions
  • Ceiling heights
  • Zones with different coverage needs

Site & Coverage

  • Deployment Type
  • Environment
  • Clutter Level
  • Total Site Area

Your Use Cases

  • Voice
  • Video
  • Industrial automation
  • Internet of Things (IoT)
  • Surveillance
  • Telemetry
  • Broadcast
  • Other operational applications

Capacity & Application

  • Primary Use Case
  • Latency Requirement

Your Devices

  • Types
  • Capabilities
  • Expected concurrency
  • Bandwidth needs

Capacity & Application

  • Downlink / User
  • Uplink / User

Site & Coverage

  • UL Device Class

Your Scale

  • Expected users/devices
  • Peak concurrency

Capacity & Application

  • Concurrent Devices
  • Device Mobility

Your Spectrum and Backhaul

  • CBRS
  • n77/n78 or other regional bands
  • Existing wired connectivity

Capacity & Application

  • Technology
  • Channel BW

Site & Coverage

  • Region
  • AP Power Class

Planning Parameters

  • Backhaul / Cabling

Your Design Preferences

  • How conservative your estimate should be
  • How much growth/overlap margin to plan for

Planning Parameters

  • Planning Stance
  • Overlap / Growth Buffer
### Before you Begin New to private cellular terminology or concepts? * [*GXC Glossary*](https://docs.gxc.io/introduction/introduction/glossary) — Learn common private cellular and Onyx terminology. * [*Private 5G Spectrum and Regulations*](https://docs.gxc.io/introduction/introduction/private-5g-spectrum-and-regulations) — Understand supported spectrum bands and regulatory considerations. * [*Introduction to GXC Onyx*](https://docs.gxc.io/introduction/introduction/quickstart) — Review the overall Onyx platform architecture and components. * [*Onyx Hardware*](https://docs.gxc.io/hw/onyx-hardware/gxc-5g-and-lte-hardware) — Learn about supported Onyx Edge gateways, Access Points (APs), antennas, and related hardware. * [*Security and Compliance*](https://docs.gxc.io/introduction/introduction/security-and-compliance) — Review security features, compliance certifications, and applicable regulatory requirements. * [*Use Cases*](https://docs.gxc.io/introduction/introduction/use-cases) — Explore real-world customer deployments, including the 2025 Australian Grand Prix deployment. ### Where this Guide is Going Network design follows four steps, in this order:

Capacity → Coverage → Architecture → Accessories

Capacity sets a floor, Coverage sets a ceiling, Architecture resolves where you land between them, and Accessories completes the system.
## Step 1 - Capacity Capacity planning determines how much wireless throughput the deployment must support and how many cells are required to meet that demand.
Why Capacity Comes First? Capacity is the foundation of the network design. Getting the capacity requirement wrong can lead to an inappropriate technology or architecture choice resulting in an under- or over-sized deployment. Because Onyx LTE and 5G use distinct hardware platforms, technology selection should be considered early in the design. Coverage, Architecture, and Accessories then build on the capacity requirement established here. This is why the ROM AP Calculator asks for the application-level inputs early in the workflow and why its Technology Assessment should be considered alongside the calculated capacity requirement.
### Do this in the Calculator {% stepper %} {% step %} In the **Capacity & Application** panel, set: * **Technology** — 4G / LTE or 5G NR * **Channel BW** — (Only for 5G NR) 20 / 40 / 100 MHz * **Primary Use Case** — The category that best represents the dominant application (General Enterprise / Voice & Data, IoT/Telemetry & Sensors, Video Surveillance & Broadcast, Logistics/AGVs & Automated Vehicles, Machine Vision & Real-time Control, AR/VR & High-bandwidth Immersive) * **Latency Requirement** — Not Sensitive / Moderate / <30 ms (LTE delivers >50 ms; 5G NR delivers <30 ms) * **Downlink / User** — <3 / 3–50 / >50 Mbps * **Uplink / User** — <1 / 1–10 / >10 Mbps * **Concurrent Devices** — <25 / 25–100 / 100+ * **Device Mobility** — Fixed / Mobile / Continuous

Figure: ROM Calculator - Capacity & Application Panel

The calculator uses these inputs to estimate traffic demand and determine the capacity-driven AP count. {% endstep %} {% step %} In the **Estimated APs** panel, review: * **Capacity estimate: *****n***** APs (DL needs *****X***** · UL needs *****Y*****)** — The estimated AP count and the calculated downlink and uplink requirements. The larger of *X* and *Y* is your capacity-driven cell count, and the calculator identifies the binding direction, such as "UL-limited".

Figure: ROM Calculator - Estimated APs Panel

* **Technology Assessment** — Indicates whether the selected technology is a good fit, with the reasoning behind the recommendation.

Figure: ROM Calculator - Technology Assessment Panel

{% endstep %} {% endstepper %} #### Understanding the Methodology The Calculator performs the capacity calculation automatically. This section explains the methodology so that you can validate the recommendation and adapt it when the deployment does not fit the Calculator's generic application categories. The Calculator's built-in capacity estimate applies a 0.65 concurrency factor to the device count in your selected Concurrent Devices bucket before computing throughput demand — it never evaluates 100% of devices as simultaneously active. The manual method below (Application Profile → Total Throughput Demand) does not apply this factor, because it uses your own per-application peak-concurrency figures directly — a number you've already defined as "simultaneously active during peak operating conditions." This is intentional as the manual method is more precise when you know your actual peak concurrency, while the Calculator's 0.65 factor is a generic estimate for when you don't. {% hint style="info" %} **NOTE:** The Calculator provides a planning estimate. It does not replace a detailed capacity or RF design when application requirements, device behavior, spectrum availability, or site conditions require more detailed analysis. {% endhint %} {% stepper %} {% step %} Determine the Application Profile. The application profile is an inventory of the devices and applications that will use the network. For each device category, capture: * **Application** — What does the device or application do? Examples include Automated Guided Vehicle (AGV) navigation, video surveillance, handheld scanning, voice, and Supervisory Control and Data Acquisition (SCADA). * **Peak concurrent devices** — How many devices of that type are expected to be simultaneously active during peak operating conditions?

NOTE: Size the network for the expected peak operating workload, not simply the total number of deployed devices or the average traffic level. Identify how many devices are expected to be active simultaneously and what traffic each application generates during the peak operating condition.

* **Downlink requirement** — How much data does the application receive? * **Uplink requirement** — How much data does the application transmit? * **Latency requirement** — How sensitive is the application to network delay? * **Mobility** — Is the device stationary, pedestrian, or vehicle-mounted?
Why Application Profiling Comes First? Not all devices place the same demands on the network. A handheld barcode scanner may use only a small amount of bandwidth, while a 4K surveillance camera can generate a continuous high-volume uplink stream. Similarly, an AGV performing real-time navigation may have more demanding latency requirements than a sensor that periodically reports a measurement. Understanding the complete application profile provides the baseline for calculating network capacity and determining the required AP density.
**Application Traffic Classes** {% hint style="info" %} **NOTE:** The following ranges provide general planning guidance for classifying application traffic. They are illustrative ranges, not guaranteed application requirements. {% endhint %} | Class | Examples | Typical Range | | -------- | ---------------------------------------------------- | ------------------ | | Light | Voice, messaging, telemetry | 100–300 kbps | | Moderate | IoT, monitoring systems, standard video applications | 500 kbps – 3 Mbps | | Heavy | AR/VR, machine vision, real-time video analytics | 10 Mbps or greater | {% hint style="info" %} **NOTE:** Actual bandwidth depends on application design, concurrency, video resolution, frame rate, compression, operational workload, and device behavior. Use application-specific requirements whenever they are available. {% endhint %} **ROM Calculator Bandwidth Tiers** The Calculator uses broader planning buckets than the application traffic ranges above. These DL and UL values are what the calculator maps to your Downlink/User and Uplink/User selections. | Class | Examples | DL | UL | | ------------ | ------------------------------------------ | ------- | -------- | | Light / Low | Voice, messaging, telemetry | 2 Mbps | 0.5 Mbps | | Moderate | IoT, monitoring, standard video | 20 Mbps | 5 Mbps | | Heavy / High | AR/VR, machine vision, real-time analytics | 75 Mbps | 25 Mbps | {% hint style="info" %} **NOTE**: The Calculator applies a 0.65 concurrency factor to the device count used in its capacity calculation. Do not independently apply an additional concurrency reduction when interpreting the Calculator's estimate. For deployments where the expected traffic profile does not map well to the Calculator's generic tiers, validate the result using the application-specific calculation described below. {% endhint %} {% endstep %} {% step %} Calculate the Total Throughput Demand. 1. Calculate the aggregate throughput requirement for the defined peak operating condition.\ \ For each device category:
``` Total DL demand = active devices × DL bandwidth per device Total UL demand = active devices × UL bandwidth per device ``` 2. Sum the results across all device categories. \ Calculate downlink and uplink independently because enterprise applications rarely generate equal traffic in both directions. \ The result is the peak throughput requirement that the network must support during the defined peak operating condition. {% hint style="info" %} **NOTE:** Capacity planning should use the expected peak concurrent workload rather than average utilization. Designing only for average traffic can result in insufficient capacity during normal operational peaks. {% endhint %} {% endstep %} {% step %} Select the Technology and Architecture. With the peak throughput requirement established, compare it against the capabilities of the Onyx LTE and 5G platforms. Technology selection should consider: Peak downlink throughput, peak uplink throughput, application latency requirements, device capabilities, spectrum availability, MIMO capability, expected device concurrency, mobility requirements, capacity-driven cell count, deployment architecture, and future operational requirements. Cell capacity is determined from the LTE or 5G SA TDD tables below (frame format × bandwidth × MIMO): ``` APs_cap = max(⌈TotalDL ÷ CellDL⌉, ⌈TotalUL ÷ CellUL⌉) ``` **LTE or 5G?** In many deployments, technology selection needs to be made early because GXC Onyx LTE and 5G use distinct hardware platforms. **LTE vs 5G At a Glance** | | LTE | 5G | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Latency Characteristics | Suitable for moderate-latency enterprise applications (>50 ms) | Supports lower-latency and real-time workloads (<30 ms) | | Typical Use Cases | General enterprise connectivity, telemetry, IoT | Real-time analytics, robotics, machine vision, broadcast video | | Estimated Peak AP Throughput | \~40 Mbps @ 20 MHz (general baseline); \~105 Mbps/cell at 20 MHz for the default Config1 configuration (up to 96 RRC users) — see the table below for the full range by configuration | Up to 300+ Mbps with 4×4 MIMO @ 40 MHz, depending on deployment conditions | | Channel BW options in calculator | Fixed (2×20 MHz CA reference) | 20 / 40 / 100 MHz, selectable | {% hint style="info" %} **NOTE:** Actual throughput and latency depend on spectrum allocation, RF conditions, antenna configuration, device capability, mobility, interference, and overall deployment design. Use the measured throughput tables in this guide as planning references rather than guaranteed production performance. {% endhint %} **LTE and 5G Hardware Considerations** GXC Onyx LTE and 5G use distinct hardware platforms. Selecting the appropriate technology is therefore an important early design decision. If an existing LTE deployment later requires 5G capability, a supported 5G architecture may be available for specific configurations. This is not a standard LTE-to-5G migration model. {% endstep %} {% endstepper %} ### LTE Capacity This section provides guidance for understanding LTE capacity on the Onyx platform.
LTE Capacity Overview LTE capacity planning determines how much traffic the network can support and how many cells are required to meet the expected peak demand. LTE Time Division Duplex (TDD) shares the available radio spectrum between downlink and uplink transmission. Capacity therefore depends not only on channel bandwidth and MIMO configuration, but also on how radio resources are divided between the two directions. For LTE deployments, capacity planning should consider: * Peak downlink throughput * Peak uplink throughput * Traffic direction and application behavior * TDD Subframe Assignment (SA) * Channel bandwidth * MIMO configuration * Modulation * Carrier Aggregation (CA), where supported * Device capability * RF conditions * Expected peak device concurrency The goal is to select an LTE configuration that provides sufficient capacity in both directions while avoiding unnecessary cell deployment.
Select the LTE TDD Subframe Assignment LTE Time Division Duplex (TDD) uses the same frequency channel for downlink and uplink traffic. The network alternates between the two directions, allocating a defined portion of radio resources to each. The Subframe Assignment (SA) determines this DL/UL allocation. Think of the radio channel as a road shared by traffic moving in two directions. Allocating more time to one direction increases capacity in that direction, but leaves less capacity available for the other. **Why Does it Matter?** Choosing the appropriate SA profile is an important part of LTE capacity planning. For example, a surveillance deployment may continuously transmit video from cameras to a recording system. Selecting a heavily downlink-oriented SA profile for such a deployment would allocate insufficient airtime to uplink traffic. **Available SA Profiles**
SADLULTraffic Profile
SA170%30%Balanced traffic
SA285%15%Downlink-heavy traffic
SA660%40%Uplink-heavy traffic
**Choosing an SA Profile Rule of Thumb** * **Balanced traffic** — General enterprise connectivity, tablets, laptops, and mixed IoT → Consider **SA1** as the starting point. * **Primarily downlink traffic** — Streaming video, software updates, command delivery, and content distribution → Consider **SA2**. * **Primarily uplink traffic** — Cameras, sensors, AGVs, telemetry, and industrial monitoring → Consider **SA6**. For example, a surveillance deployment may continuously transmit video from cameras to a recording or monitoring system. A heavily downlink-oriented SA would allocate insufficient airtime to this uplink traffic. These recommendations are starting points — the final selection should be based on the calculated application traffic profile. | Application | Recommended SA | | ---------------------------------------------- | -------------------- | | CPE routers serving broadband traffic | SA2 — DL-heavy | | Video streaming to displays or signage | SA2 — DL-heavy | | Handheld scanners downloading work orders | SA2 — primarily DL | | Mixed enterprise — tablets, laptops, light IoT | SA1 — balanced | | Push-to-talk voice with data | SA1 — balanced | | Video surveillance cameras | SA6 — UL-heavy | | Dense sensor/telemetry networks | SA6 — UL-heavy | | AGVs or robots reporting position and status | SA6 — UL-heavy | | Unknown or mixed traffic profile | SA1 — starting point | {% hint style="info" %} **NOTE:** Every GXC AP operating on the same frequency channel must use the same SA configuration. SA is therefore a network-level design decision rather than an individual device setting. {% endhint %}
Understand LTE Throughput The following throughput tables provide measured peak throughput values observed during controlled GXC testing. Use these values as planning references, not guaranteed production throughput. Actual performance depends on RF signal quality, spectrum availability, interference, channel bandwidth, MIMO configuration, modulation, device capability, AP density, user concurrency, mobility, and environmental conditions.

Single/Dual Carrier Peak Expected Throughput (Mbps)

MIMO ConfigDir/ModSA1 10MHzSA1 20MHzSA2 10MHzSA2 20MHzSA6 10MHzSA6 20MHz
DL 2TDL-256QAM4896661313978
DL 1TDL-256QAM244833662039
UL 1TUL-64QAM14297141836

Carrier Aggregation Peak Expected Throughput (Mbps)

MIMO ConfigDir/ModSA1 2×20MHzSA1 2×10MHzSA1 20+10MHzSA2 2×20MHzSA2 2×10MHzSA2 20+10MHzSA6 2×20MHzSA6 2×10MHzSA6 20+10MHz
DL 2TDL-256QAM1929614426213119715778118
DL 1TDL-256QAM9648721316698783959
UL 1TUL-64QAM582943291422723654
{% hint style="warning" %} **IMPORTANT:** These values represent measured performance under controlled conditions. They should not be interpreted as guaranteed per-user throughput or as a substitute for detailed RF and capacity engineering. {% endhint %}
Understand MIMO, Modulation, and Channel Width **MIMO Configuration** MIMO refers to the number of spatial streams used simultaneously for data transmission or reception. Higher-order MIMO can increase throughput when supported by the AP, client device, antenna configuration, and RF conditions. | Configuration | Description | Typical Devices | | ------------- | --------------------------------------------- | --------------------------------------------------------------------- | | DL 2T (2×2) | Two simultaneous downlink streams from the AP | Supported by many enterprise devices and CPEs | | DL 1T (1×1) | One downlink stream from the AP | Basic devices or deployments where higher-order MIMO is not available | | UL 1T (1×1) | One uplink stream to the AP | Common LTE UL configuration | **Modulation** Modulation determines how much data can be transmitted in each radio signal. Higher-order modulations can carry more bits per transmission, but requires better RF conditions. **Channel Width** The *Single/Dual Carrier* table's column headers (10 MHz, 20 MHz) represent the spectrum allocated to the deployment. Wider channels generally provide greater throughput capacity when the additional spectrum is available and supported by the deployment.
Consider Carrier Aggregation CA combines multiple LTE carriers to provide additional usable spectrum capacity to supported devices. For example, two 20 MHz carriers can provide an aggregate 40 MHz spectrum allocation.
CombinationChannel 1Channel 2Effective BWUse Case
2×20 MHz202040 equivalentMaximum capacity — use when two 20 MHz grants are available
2×10 MHz101020 equivalentTwo narrower grants bonded — same total as a single 20 MHz channel
20+10 MHz201030 equivalentAsymmetric CA — useful when one wider and one narrower grant are available
{% hint style="info" %} **NOTE:** CA can increase available capacity when multiple supported carriers are available. Before including CA in the capacity design, verify spectrum availability, device support, AP and network configuration, and applicable deployment constraints. {% endhint %}
LTE Capacity Design Considerations * Use measured throughput values as planning references rather than theoretical maximums. * Select the SA profile based on the dominant traffic direction. * Use wider channel bandwidths where additional spectrum is available and additional capacity is required. * Validate RF quality before relying on higher-order MIMO or modulation. * Design AP density around expected peak operational demand rather than average utilization. * Carefully evaluate uplink requirements for surveillance, telemetry, industrial automation, and sensor-heavy environments. * Consider CA where additional spectrum is available and supported by the deployment. * Validate device capabilities when determining realistic throughput. The resulting LTE capacity design should establish the capacity-driven cell count before coverage and architecture are finalized.
### 5G Capacity This section provides guidance for understanding 5G capacity on the Onyx platform.
5G Capacity Overview 5G capacity planning determines how much traffic the network can support and how many cells are required to meet the expected peak demand. 5G NR TDD uses the same spectrum for downlink and uplink transmission. The network therefore uses a slot pattern to determine how radio resources are allocated between the two directions. For 5G deployments, capacity planning should consider: * Peak downlink throughput * Peak uplink throughput * Traffic direction and application behavior * TDD slot pattern * Channel bandwidth * MIMO configuration * Modulation * Device capability * RF conditions * Expected peak device concurrency * Mobility and operational requirements {% hint style="info" %} **NOTE:** The throughput values in this section are based on measured performance during controlled GXC field and laboratory testing using CBRS and mid-band 5G spectrum configurations. Actual performance varies with spectrum availability, RF conditions, interference, device capability, MIMO configuration, mobility, environmental obstructions, AP density, user concurrency, and overall deployment design. {% endhint %}
Select the 5G TDD Slot Pattern 5G TDD uses the same spectrum for uplink and downlink transmission. A slot pattern determines how radio resources are distributed between the two directions. * **Downlink traffic** moves from the network to devices, such as tablets, AR headsets, and handheld devices. * **Uplink traffic** moves from devices to the network, such as cameras, sensors, robots, scanners, and telemetry systems. A deployment with many cameras, sensors, or robots may require greater uplink allocation. A deployment dominated by video delivery, software downloads, or AR content may require greater downlink allocation. **5-Slot Patterns** Provides simplified scheduling behavior and predictable traffic allocation. | Pattern | DL/UL Distribution | Recommended Deployment Environment | | ------- | ------------------ | ----------------------------------------------------------------------------- | | DDDSU | 74% DL / 23% UL | Downlink-heavy applications including content delivery and media distribution | | DDSUU | 54% DL / 43% UL | Balanced enterprise traffic and mixed-use environments | | DSUUU | 34% DL / 63% UL | Uplink-heavy environments including surveillance and telemetry workloads | **10-Slot Patterns** Provides finer control over downlink and uplink resource allocation, for mixed enterprise workloads. | Pattern | DL/UL Distribution | Recommended Deployment Environment | | ---------- | ------------------ | -------------------------------------------------------------------------------------- | | DDDDDDDSUU | 77% DL / 21% UL | Downlink-heavy applications such as video delivery, AR/VR, and content distribution | | DSUUUUDSUU | 25% DL / 72% UL | Mixed enterprise traffic including handheld devices, laptops, and general connectivity | | DDSUUUUUUU | 20% DL / 77% UL | Uplink-heavy environments such as surveillance, telemetry, and industrial sensors | {% hint style="info" %} **NOTE:** The DL and UL percentages represent the approximate allocation of data-carrying resources. They do not necessarily sum to 100% because TDD frame structures also include special and other non-DL/UL resources. {% endhint %} **Choosing Between 5-Slot and 10-Slot Patterns** Consider dominant traffic direction, aggregate throughput requirement, scheduling behavior, latency requirements, synchronization and coexistence requirements, and operational simplicity.
Choose a Slot Pattern by Traffic Profile **Heavy Downlink Applications** Examples include video delivery, AR/VR, content distribution, and software distribution. Both DDDSU and DDDDDDDSUU allocate the majority of airtime to downlink. | Pattern | Split | Best when | | -------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------ | | DDDSU (5-slot) | 74% DL / 23% UL | Simpler scheduling preferred, predictable DL delivery, no coexistence constraint, lower operational complexity | | DDDDDDDSUU (10-slot) | 77% DL / 21% UL | Maximum DL throughput ceiling required, fine-grained DL/UL balancing needed, adjacent networks require 10-slot synchronization | {% hint style="info" %} **NOTE:** DDDSU is the recommended starting point for most Heavy DL deployments. DDDDDDDSUU delivers marginally higher DL capacity and is the right choice when squeezing maximum downlink throughput from available spectrum is the priority. {% endhint %} **Mixed-Use Applications** Examples include general enterprise connectivity, handheld devices, laptops, balanced industrial workloads. | Pattern | Split | Best When | | -------------------- | --------------- | --------------------------------------------------------------------------------------------------------------- | | DDSUU (5-slot) | 54% DL / 43% UL | Balanced enterprise environment, operational simplicity preferred, predictable traffic allocation | | DSUUUUDSUU (10-slot) | 25% DL / 72% UL | Greater flexibility needed to tune DL/UL balance dynamically, adjacent networks require 10-slot synchronisation | {% hint style="info" %} **NOTE:** DDSUU is the recommended starting point for most Mixed Use deployments. DSUUUUDSUU provides more fine-grained control over the DL/UL balance and suits environments where traffic patterns vary significantly across shifts or operational periods. {% endhint %} **Heavy Uplink Applications** Examples include surveillance cameras, telemetry sensors, AGVs, and industrial monitoring. Both DSUUU and DDSUUUUUUU allocate the majority of airtime to uplink. | Pattern | Split | Best when | | -------------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------- | | DSUUU (5-slot) | 34% DL / 63% UL | Many devices uploading frequently, low-latency UL response needed, high device concurrency, operational simplicity preferred | | DDSUUUUUUU (10-slot) | 20% DL / 77% UL | Maximum raw UL throughput ceiling required, sustained bulk continuous uploads, adjacent networks require 10-slot synchronisation | {% hint style="info" %} **NOTE:** For most Heavy UL deployments, DSUUU is the recommended starting point — more frequent uplink scheduling opportunities reduce per-device queuing delay, which matters with high concurrent device activity. DDSUUUUUUU delivers a higher aggregate UL throughput ceiling and is the right choice when bulk continuous upload capacity is the priority and latency tolerance is higher. {% endhint %}
Understand 5G Throughput The following throughput tables provide measured peak throughput values observed during controlled GXC testing. {% hint style="warning" %} **IMPORTANT:** Use these values as deployment planning references, not guaranteed per-user throughput in a shared production environment. Actual performance varies with RF quality, channel bandwidth, MIMO configuration, modulation, device capability, AP density, user concurrency, mobility, and environmental conditions. {% endhint %} **Peak Expected Throughput (Mbps) — 10-Slot Patterns**

10-slot · DDDDDDDSUU (77% DL / 21% UL) — Heavy Downlink

MIMO ConfigDir/Mod10MHz20MHz40MHz50MHz100MHz
DL 4TDL-256QAM1242635466851370
DL 2TDL-256QAM63135280351703
DL 1TDL-256QAM3269144180361
UL 2TUL-256QAM15316481161
UL 2TUL-64QAM12245164125
UL 1TUL-256QAM716324080
UL 1TUL-64QAM612253262

10-slot · DSUUUUDSUU (25% DL / 72% UL) — Mixed Use

MIMO ConfigDir/Mod10MHz20MHz40MHz50MHz100MHz
DL 4TDL-256QAM55117243305609
DL 2TDL-256QAM2860124156312
DL 1TDL-256QAM14316480160
UL 2TUL-256QAM4391189237471
UL 2TUL-64QAM3472149187365
UL 1TUL-256QAM214695119236
UL 1TUL-64QAM17367493183

10-slot · DDSUUUUUUU (20% DL / 77% UL) — Heavy Uplink

MIMO ConfigDir/Mod10MHz20MHz40MHz50MHz100MHz
DL 4TDL-256QAM4492192241482
DL 2TDL-256QAM224798124247
DL 1TDL-256QAM11245163127
UL 2TUL-256QAM49103215270536
UL 2TUL-64QAM3881169212415
UL 1TUL-256QAM2452107135268
UL 1TUL-64QAM194185106208
**Peak Expected Throughput (Mbps) — 5-Slot Patterns**

5-slot · DDDSU (74% DL / 23% UL) — Heavy Downlink

MIMO ConfigDir/Mod10MHz20MHz40MHz50MHz100MHz
DL 4TDL-256QAM1192535266601319
DL 2TDL-256QAM61130270338677
DL 1TDL-256QAM3167138173347
UL 2TUL-256QAM16336986171
UL 2TUL-64QAM12265468150
UL 1TUL-256QAM817344386
UL 1TUL-64QAM613273466

5-slot · DDSUU (54% DL / 43% UL) — Mixed Use

MIMO configDir/Mod10MHz20MHz40MHz50MHz100MHz
DL 4TDL-256QAM87185384482964
DL 2TDL-256QAM4595197247495
DL 1TDL-256QAM2349101127254
UL 2TUL-256QAM2962129162321
UL 2TUL-64QAM2349101127249
UL 1TUL-256QAM15316481161
UL 1TUL-64QAM12245164125

5-slot · DSUUU (34% DL / 63% UL) — Heavy Uplink

MIMO ConfigDir/Mod10MHz20MHz40MHz50MHz100MHz
DL 4TDL-256QAM55117243305609
DL 2TDL-256QAM2860124156312
DL 1TDL-256QAM14316480160
UL 2TUL-256QAM4391189237471
UL 2TUL-64QAM3472149187365
UL 1TUL-256QAM214695119236
UL 1TUL-64QAM17367493183
Understand 5G MIMO, Modulation, and Channel Bandwidth **MIMO Configuration** Higher-order MIMO can increase throughput and spectral efficiency when supported by the AP, client device, antenna configuration, and RF conditions. | Configuration | Description | Typical devices | | ------------- | ---------------------------------------------- | ------------------------------------------------------------ | | DL 4T (4×4) | Four simultaneous downlink streams from the AP | High-end devices, industrial CPEs with four receive antennas | | DL 2T (2×2) | Two simultaneous downlink streams from the AP | Mid-range smartphones, most enterprise CPEs | | DL 1T (1×1) | One downlink stream from the AP | Basic devices, coverage-edge scenarios | | UL 2T (2×2) | Two simultaneous uplink streams to the AP | Most smartphones and standard devices | | UL 1T (1×1) | One uplink stream to the AP | Most smartphones and standard devices | **Modulation** Modulation determines how much data can be transmitted in each radio signal; higher modulation orders carry more bits per transmission but only work well with good signal quality. | Modulation | Condition | | ---------- | --------------------------------------------------------- | | 256-QAM | Close range, strong signal, clear line of sight | | 64-QAM | Moderate range or some obstruction — 75% of 256-QAM speed | **Channel Bandwidth** The channel-width values in the throughput tables represent the spectrum allocated to the deployment. Wider channel bandwidths generally provide greater throughput capacity when additional spectrum is available and supported.
5G Capacity Design Considerations * Use measured throughput values as planning references. * Select the slot pattern based on the dominant traffic direction. * Consider wider channel bandwidths where additional spectrum is available. * Validate RF quality before relying on higher-order MIMO or higher-order modulation. * Design AP density around peak operational demand. * Carefully evaluate uplink requirements for surveillance, telemetry, industrial automation, and sensor-heavy environments. * Consider device capability when determining realistic throughput. * Align the slot pattern, bandwidth, MIMO configuration, modulation, and RF design with the actual deployment requirements. The resulting 5G capacity design should establish the capacity-driven cell count before coverage and architecture are finalized.
Worked Example - Application Profile | Device | Peak Concurrent | DL/Device | UL/Device | Class | | ----------------- | :-------------: | :-------: | :-------: | -------- | | Handheld scanner | 50 | 0.5 Mbps | 0.25 Mbps | Light | | IP camera (1080p) | 30 | — | 4 Mbps | Heavy UL | | Supervisor tablet | 10 | 5 Mbps | 1 Mbps | Moderate | Handheld scanners generally transmit small bursts of data and receive work information. IP cameras continuously transmit video to a recording or monitoring system, creating a significant uplink load. Supervisor tablets receive dashboards and operational information and generate a smaller amount of uplink traffic.
Worked Example - Total Throughput Demand Calculate the aggregate demand for each direction: **Downlink** ``` Handheld scanners: 50 × 0.5 Mbps = 25 Mbps IP cameras: 30 × 0 Mbps = 0 Mbps Supervisor tablets: 10 × 5 Mbps = 50 Mbps (50 × 0.5) + (30 × 0) + (10 × 5) = 25 + 0 + 50 = 75 Mbps DL ``` **Uplink** ``` Handheld scanners: 50 × 0.25 Mbps = 12.5 Mbps IP cameras: 30 × 4 Mbps = 120 Mbps Supervisor tablets: 10 × 1 Mbps = 10 Mbps (50 × 0.25) + (30 × 4) + (10 × 1) = 12.5 + 120 + 10 = 142.5 Mbps UL ``` **Peak throughput requirement: 75 Mbps DL / 142.5 Mbps UL.** The uplink requirement is approximately 1.9× the downlink requirement. The cameras are the dominant uplink load, accounting for 120 of the 142.5 Mbps total UL requirement. **Design Implication** The deployment must be sized to satisfy the uplink requirement, because UL is the binding capacity constraint for this example.
Worked Example - LTE Capacity Scenario **Scenario:** LTE (4G), CBRS (b48), Single Carrier, 40 MHz, Indoor (40 foot ceilings) **DL:** 75 Mbps **UL:** 142.5 Mbps **Binding direction:** UL Because this workload is strongly uplink-dominant, **SA6 (60% DL / 40% UL)** is selected. The selected configuration provides 157 Mbps DL per cell and 72 Mbps UL per cell. **Minimum cells — uplink (binding constraint)** ``` cell(142.5 Mbps UL demand ÷ 72 Mbps UL/cell) = 1.98 cells = 2 cells ``` **Minimum cells — downlink (check)** ``` cell(75 Mbps DL demand ÷ 157 Mbps DL/cell) = 0.47cell = 1 cell ``` **Required Cell Count: 2 cells** The two-cell design delivers 314 Mbps DL capacity, 144 Mbps UL capacity, and 1.5 Mbps UL headroom.
Worked Example - 5G Capacity Scenario **Scenario:** 5G · CBRS (n48) · Single carrier · 40 MHz · Indoor (40 ft ceilings). **DL:** 75 Mbps **UL:** 142.5 Mbps **Binding direction:** UL Because the workload is strongly uplink-dominant, the DDSUUUUUUU 10-slot pattern is selected. For this example, use DL 4T / 256-QAM, UL 2T / 64-QAM, 40 MHz bandwidth, and the DDSUUUUUUU pattern. **Minimum cells — uplink (binding constraint)** ``` cell(142.5 Mbps UL demand ÷ 169 Mbps ULcell) = cell(.84) = 1 cell ``` **Minimum cells — downlink (check)** ``` cell(75 DL demand ÷ 192 DL per cell) = ceil(0.39) = 1 cell ``` **Required Cell Count: 1 cell (uplink-bound)** The resulting measured planning values are 192 Mbps DL per cell and 169 Mbps UL per cell. **142.5 Mbps ÷ 169 Mbps = 0.84 cells → 1 cell** **Required cell count = 1 cell** The single-cell design provides 192 Mbps DL capacity, 169 Mbps UL capacity, and 26.5 Mbps UL headroom.
LTE vs. 5G - Same 20 MHz Channel To isolate the pure LTE-vs-5G difference from the effect of CA, compare both technologies using the same device profile, site, and 20 MHz channel. | | LTE (SA6) | 5G (DDSUUUUUUU) | | -------------------- | ------------------------ | ---------------------------- | | TDD configuration | SA6 — 60% DL / 40% UL | DDSUUUUUUU — 20% DL / 77% UL | | Peak UL per cell | 36 Mbps (UL 1T, 64-QAM) | 103 Mbps (UL 2T, 256-QAM) | | Peak DL per cell | 78 Mbps (DL 2T, 256-QAM) | 92 Mbps (DL 4T, 256-QAM) | | Capacity floor | 4 cells | 2 cells | | UL headroom at floor | 1.5 Mbps (tight) | 63.5 Mbps (comfortable) | | Aggregate backhaul | 456 Mbps | 390 Mbps | | Backhaul requirement | 1 Gbps fiber | 1 Gbps fiber | For this uplink-heavy workload, the 5G configuration provides substantially more uplink capacity per cell. {% hint style="warning" %} **IMPORTANT:** This comparison illustrates the effect of the selected radio configurations for this workload. It should not be interpreted as a universal LTE-versus-5G cell-count rule. {% endhint %}
Capacity Design Output At the end of Step 1, the capacity assessment should establish: * Peak downlink requirement * Peak uplink requirement * Binding traffic direction * Selected technology * Applicable LTE SA or 5G slot pattern * Applicable channel bandwidth * Applicable MIMO and modulation assumptions * Capacity-driven cell count * Preliminary aggregate backhaul requirement These outputs establish the capacity floor for the deployment. The capacity-driven cell count should then be carried into [*Step 2 — Coverage*](#step-2-coverage). The final radio count is determined by the greater of the capacity requirement or coverage requirement.
#### Next Step Next, proceed to [*Step 2 — Coverage*](#step-2-coverage) to determine whether the physical site and propagation environment require additional radios. The final radio count is determined by the greater of the capacity-driven requirement and the coverage-driven requirement. ## Step 2 - Coverage Coverage design answers a different question from capacity: "*How many radios are required to provide usable coverage across the physical site?*" [*Step 1 - Capacity*](#step-1-capacity) established the capacity-driven radio count. Step 2 determines the coverage-driven radio count. Together, these establish the range that the architecture must accommodate. The final radio count is determined by whichever requirement is greater: ``` Final radio count = max(capacity-driven count, coverage-driven count) ``` ### Do this in the Calculator {% stepper %} {% step %} In the **Site & Coverage** panel, set: * **Deployment Type** — Indoor or Outdoor * **Environment** — * Indoor: Open Office/Showroom, Warehouse (Low Racks), Warehouse (Dense Racks) * Outdoor: Open Campus/Yard, Parking Lot/Loading Dock, Industrial Perimeter * **Clutter Level** — (Independent of **Environment**) Low / Medium / High * **UL Device Class** — Handset / External Antenna / CPE * **Region** — US (CBRS) or UK/EU/AU * **Total Site Area** — In sq ft, sq m, or acres

Figure: ROM Calculator — Site & Coverage Panel

{% endstep %} {% step %} In the **Estimated APs** panel, review: * **Coverage estimate** — Shows the number of APs required to provide coverage based on the selected site characteristics. * **sq ft/AP** — Shows the effective coverage baseline and multipliers used by the calculator. For example, the calculator may display a calculation such as: ``` 25,000 × 1 (clutter) × 1.25 (auto) × 1 (stance) ``` This provides visibility into how the calculator arrived at the coverage estimate.
{% hint style="info" %} **NOTE**: In case of segmented sites, the calculator evaluates one Environment / Clutter combination per run. It does not automatically segment a mixed site into different coverage zones. If a site contains a warehouse floor, office area, loading dock, and outdoor yard, evaluate each zone separately and combine the resulting requirements. {% endhint %} {% hint style="warning" %} **IMPORTANT:** Do not treat the entire site as a single coverage zone when different areas have significantly different propagation characteristics, mounting conditions, or operational requirements. {% endhint %} {% endstep %} {% endstepper %} ### **Understanding the Methodology** #### **Gathering Coverage Requirements** Before estimating the radio count, capture the physical and operational characteristics of the site. * **Total area** — Record the total site area and separate indoor and outdoor areas where appropriate. * **Site segmentation** — Identify areas that require separate coverage treatment, such as warehouse floors, mezzanines, loading docks, offices, yards, and outdoor operational areas. * **Indoor/outdoor mix** — Identify the proportion of indoor and outdoor coverage and any transition areas between them. * **Terrain and clutter** — Document conditions that can affect propagation, including open floor areas, racks, machinery, containers, walls, terrain changes, and building-to-building distances. * **Ceiling and mounting height** — Record AP mounting heights and identify significant variations across the site. * **Mobility profile** — Identify how devices move through the coverage area: Stationary devices, pedestrians, forklifts, AGVs, vehicles, or other mobile devices. * **Coverage requirements** — Identify where service is required and the performance expected in each area. {% hint style="warning" %} **Common mistake to avoid**: Do not treat the entire site as a single coverage zone. A warehouse floor, loading dock, office area, and outdoor yard may have very different propagation characteristics, mounting heights, obstructions, device densities, mobility patterns, coverage requirements. Segment the site first, then estimate coverage for each zone. {% endhint %}
Coverage Rules of Thumb The following values provide initial planning estimates for radio count. They are not substitutes for an RF design. Actual radio count depends on frequency, antenna configuration, mounting height, propagation environment, required signal level, interference, mobility, and application requirements. **Indoor Coverage Estimates**
ClutterExampleAvg. HeightCoverage per APAP Density
LowOpen office space, minimal walls, mostly LOS125 ft~25,000 sq ft4 APs
MediumOpen warehouse spaces with low to medium shelves, miscellaneous layout, some partitions80 ft~20,000 sq ft5–6 APs
HighManufacturing floor / Warehouse with dense walls, high metal racks, cold storage, heavy machinery50 ft~7,000 sq ft13–15 APs
**Outdoor Coverage and Capacity Estimates (Omni Antennas)** | Design Intent | Area | Radius | AP Count | Notes | | ----------------- | ----------------- | -------- | --------- | ----------------------------------------------------------------------------------------------------------------- | | Coverage-Oriented | \~1,000,000 sq ft | \~800 ft | \~1 AP | Assumes 47 dBm EIRP, wide-area mobility. Corresponds to "Open Campus / Yard" in the table below. | | Capacity-Oriented | \~300,000 sq ft | \~440 ft | \~3–4 APs | Higher device density, uplink-heavy applications. Corresponds to "Parking Lot / Loading Dock" in the table below. | **Outdoor Range by Directional Antennas (33°–120° Beamwidth)** | Device Class | Range | Conditions | | ------------------- | --------------- | --------------------------------------------------------------------- | | Smartphones/Tablets | 2,500–5,000 ft | Standard beamwidth, Line of Sight (LOS) or near-LOS, RSRP to -110 dBm | | CPE with High-Gain | Up to 12,000 ft | Specialized antennas, optimal alignment, high-SINR, LOS required | **Outdoor Coverage Estimates by Environment** | Environment | Height | Radius | Area | | -------------------------- | -------: | ---------: | ----------------------------- | | Open Campus / Yard | 20–30 ft | 700–800 ft | \~1,000,000 sq ft (coverage) | | Parking Lot / Loading Dock | 12–20 ft | 400–500 ft | \~300,000 sq ft (capacity) | | Industrial Perimeter | 25–35 ft | 500–750 ft | 400,000–800,000 sq ft (mixed) | **Outdoor Coverage Considerations** The estimates above assume omnidirectional external antennas unless otherwise specified. When planning outdoor coverage: * Set AP spacing according to the actual coverage and capacity objectives. * Account for buildings, foliage, machinery, vehicles, containers, and other RF obstructions. * Consider directional antennas where range, uplink performance, or interference control is a priority. * Consider the frequency band and applicable regional regulatory requirements when estimating achievable coverage. * Validate outdoor propagation before finalizing AP and antenna placement. * Consider uplink performance as well as downlink coverage, particularly for surveillance, telemetry, and industrial applications.
#### How the Calculator Estimates Coverage The ROM Calculator starts with a baseline area per AP and applies multipliers based on the deployment characteristics. The coverage formula used by the calculator: ``` APs_cov = ⌈ Area ÷ (Base × Clutter × Auto × Stance) × (1 + Buffer) ⌉ ``` Where: * **Base** = 25,000 / 17,500 / 10,000 sq ft/AP indoors (Coverage / Balanced / Capacity-oriented design intent — auto-derived, scored from Density + DL/UL throughput + Use Case, no manual goal needed), or an outdoor environment baseline × the same intent factor (1.0 / 0.70 / 0.45). * **Clutter** = Low 1.0× · Medium 0.8× · High 0.6×. * **Auto** = `min(DLscale, ULcap)`, where DLscale reflects your Channel BW (US) or AP Power Class (EMEA), and ULcap depends on UL Device Class (Handset 1.1× · Ext. Antenna 1.25× · CPE 1.5×).
RegionFormula
US (5G)DLscale = 10^(10·log10(BW/20)/10) —
20 MHz=1.0×, 40 MHz=2.0×, 100 MHz=5.0×
EMEA (5G)ΔP = 10·log10(P/5W); DLscale = 10^(ΔP/10) — e.g. 40 W ≈ +9 dB
* **Stance** = Your Planning Stance multiplier (Conservative / Prudent / Opportunistic, set in the **Planning Parameters** panel — see [*What to bring*](#what-to-bring)). #### Next Step Next, proceed to [*Step 3 - Architecture*](#step-3-architecture) to determine how the capacity-driven and coverage-driven radio counts come together into a deployable Onyx network. Architecture resolves where you land between the capacity floor established in [*Step 1*](#step-1-capacity) and the coverage ceiling established here — determining the Shared Cell or Multi-Cell configuration, fronthaul topology, Onyx Edge server requirements, switching, and backhaul needed to support the final radio count. ## Step 3 - Architecture Architecture design converts the capacity and coverage requirements into a deployable Onyx network. It determines how the required cells and radios are organized, connected, and deployed across the site. Capacity determines how many cells are required. Coverage determines how many radios are required. Architecture determines how those cells and radios are organized and connected. The architecture should answer: * How many radios and cells are required? * Which Onyx architecture best fits the deployment? * How should the radios be connected? * What fronthaul architecture is required? * How many Onyx Edge servers are required? * What switching is required? * What backhaul is required? * What redundancy or availability requirements apply? * What architecture-specific RF and installation components are required? ### Do this in the Calculator {% stepper %} {% step %} Once Capacity and Coverage inputs are set, review the following cards: * **Architecture Recommendation** — e.g., "5G Multi-Cell (Standard)" or "Shared Cell 1×8," with a short rationale and specs (MIMO, bandwidth, handover behavior).
* **Frame Structure Recommendation** (LTE SA / 5G slot pattern) — Your recommended pattern, starred (\*), alongside the alternatives and their DL:UL ratio and Mbps, so you can see why one was preferred.
* **Shared Cell Configuration Guide** — RUs/cell, resulting cell count, and handoffs for 1×8, 2×4, and 4×2 configurations. This table only appears when Shared Cell itself is the recommended architecture, not when Multi-Cell is recommended and Shared Cell is offered only as an alternative.
**Explore Alternatives is genuinely contextual, not a fixed list.** The suggestions in the sidebar change based on your current inputs — e.g., "Add continuous mobility" only appears for use cases like AGVs; "Switch to 5G NR" only appears while LTE is selected; "What if clutter is higher?" appears once other high-impact levers have already been tried. Use it to pressure-test a design before committing to it. {% endstep %} {% endstepper %} ### **Architecture Options** Depending on the deployment requirements, an Onyx architecture may include one or more of the following approaches: * **Shared Cell** — Shared Cell architectures distribute radio resources across multiple antenna locations and can provide consistent coverage across larger areas. Use Shared Cell where a distributed RF architecture is appropriate for the physical environment and traffic requirements. * **Direct Attach** — Direct-attach architectures connect supported APs directly to the appropriate Onyx Edge infrastructure. This approach can be appropriate for smaller or simpler deployments where a distributed architecture is not required. * **DAS** — DAS integration can be used where RF distribution across multiple areas, floors, or complex building structures is required. * **Mesh** — Mesh-enabled APs can extend the deployment into areas where wired infrastructure is limited or unavailable. Mesh should be evaluated against throughput, latency, reliability, and backhaul requirements before selection. * **Sectorized Outdoor Architecture** — Outdoor deployments may use sector antennas to provide directional coverage, improve range, manage interference, or concentrate capacity where devices are located. {% hint style="info" %} **What the calculator doesn't model:** Multi-floor DAS designs, and whether Mesh is the right call for a specific backhaul-limited zone. These still need the manual guidance below. {% endhint %} **TDD Frame Direction** LTE and 5G TDD configurations allocate radio resources between downlink and uplink traffic. The appropriate configuration depends on the dominant traffic direction established during capacity planning. | Use case | Calculator's stated rule | Actual output (5G, default inputs) | Matches stated rule? | | ------------------------------------ | ------------------------ | ---------------------------------- | -------------------- | | Video Surveillance & Broadcast | UL-dominant → 2D1S7U | **2D1S7U** (38:100, UL-Dominant) | Yes | | Machine Vision & Real-time Control | UL-dominant → DSUUU | **DSUUU** (24:44, UL-Leaning) | Yes (directionally) | | Logistics, AGVs & Automated Vehicles | DL-dominant → DDDSU | **DDDSU** (52:16, DL-Leaning) | Yes | | AR/VR & High-bandwidth Immersive | DL-dominant → DDDSU | **DDDSU** (52:16, DL-Leaning) | Yes | | IoT, Telemetry & Sensors | "Balanced" → DDDSU | **DSUUU** (24:44, UL-Leaning) | **No** | | General Enterprise / Voice & Data | "Balanced" → DDDSU | **DDDSU** (52:16, DL-Leaning) | Yes | **Shared Cell trade-off, per the calculator's Shared Cell Configuration Guide:** | Config | RUs/Cell | Cells | Handoffs | Best for | | ------ | -------: | ----: | -------: | ---------------------------- | | 1×8 | 8 | 1 | 0 | Max mobility · coverage | | 2×4 | 4 | 2 | 1 | Balanced capacity + mobility | | 4×2 | 2 | 4 | ≤3 | Max density · high-traffic | Reconfiguring between these is software-only in Onyx Orchestrator — no hardware changes or redeployment. Start with 1×8 and reconfigure as device density grows. **Indoor Architecture Considerations** For indoor deployments: * Use Shared Cell or DAS architectures where consistent signal distribution is required across multiple areas. * Consider distributed antenna layouts for large open environments with high user mobility. * Use appropriate Shared Cell configurations for high-density user or device environments. * Use DAS where multi-floor facilities or complex building layouts make conventional AP placement impractical. * Optimize AP placement to reduce dead zones and improve mobility and roaming behavior. * Account for racks, machinery, walls, mezzanines, and other RF obstructions. * Validate coverage and capacity across operational areas rather than only along building perimeters. **Outdoor Architecture Considerations** For outdoor deployments: * Use Mesh-enabled APs where wired infrastructure is limited or unavailable. * Use sector antennas where directional coverage, range, capacity, or interference control is required. * Design around physical obstructions such as vehicles, containers, machinery, buildings, and terrain. * Account for mobility patterns across campuses, logistics yards, ports, and industrial sites. * Validate RF propagation across all required operational areas. * Consider uplink performance as well as downlink coverage when positioning outdoor APs and antennas. * Evaluate wireless backhaul capacity and latency when using Mesh. #### Architecture Design Output At the end of Step 3, you should have established: * Required cell count * Required AP/RU count * Selected architecture * Shared Cell configuration, where applicable * Fronthaul topology * Onyx Edge requirements * Switching requirements * Backhaul requirements * Mobility and handover considerations * Redundancy and availability requirements * Architecture-specific RF components This defines how the capacity and coverage requirements will be implemented as a physical and logical Onyx network. #### Next Step Next, proceed to [*Step 4 — Accessories*](#step-4-accessories) to identify the equipment, RF components, installation hardware, and other items required to build the preliminary BoM. ## Step 4 - Accessories This is the final step in the ROM design workflow. Unlike Capacity, Coverage, and Architecture, the ROM AP Calculator does not automate this step. Once the required AP count, coverage approach, and architecture have been established, identify the equipment and installation components required to deploy the system and complete the preliminary BoM. The calculator's Print/PDF export can be used as supporting material for an early quote request, but it is not a parts-level BoM. ### What to Include in the BoM The final BoM should include every component required to deploy and operate the selected architecture. * Network Components — Include the network infrastructure required to connect and operate the cellular system. The exact components depend on the architecture selected in [*Step 3 - Architecture*](#step-3-architecture). * Onyx Edge servers or gateways * Access Points (APs) * Fronthaul Multiplexers (FHMs), where required * Ethernet or fiber switches * SFPs and other optical transceivers * Backhaul connectivity * RF Components — Include the RF components required to provide the planned coverage: * Antennas * Antenna cables * RF connectors * Mounting hardware * Sector antennas, where applicable * DAS components, where applicable For outdoor deployments, also account for the appropriate mounting and environmental requirements. * Subscriber Components — Include the components and information required to provision devices on the network: * SIMs * Subscriber/device inventory * Device-specific connectivity requirements The required subscriber components depend on the device population and deployment model. * Installation Components — Include the physical infrastructure required to install and operate the equipment: * AP mounting hardware * Rack hardware * Fiber cabling * Ethernet cabling * Power requirements * Grounding and surge protection, where required * Outdoor-rated enclosures, where applicable * Outdoor mounting components, where applicable ## Getting a Full Estimate The BoM components above cover the equipment required for a given architecture, but several accessory quantities — antenna and cable counts, FHM requirements, RU/gNodeB configuration, and outdoor-unit accessories — depend heavily on the specific deployment's physical layout and are not produced by the calculator. Adding these manually without confirming they apply to your design can significantly overstate the estimate. For a validated BoM and a formal quote, contact GXC Sales with the outputs from your ROM Calculator session. GXC Sales will confirm the accessory and configuration details — such as tenant/antenna counts, FHM requirements, and RU or outdoor-unit accessories — that apply to your specific deployment. ## Contact GXC Sales To convert the preliminary BoM into a priced, deployment-ready quote, contact [GXC Sales](https://www.gxc.io/contact-us). Sales involvement is especially useful when your design includes an outdoor unit, since outdoor accessories, tenant/antenna counts, and other site-dependent components are best confirmed before final pricing. --- # 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/getting-started.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.