> For the complete documentation index, see [llms.txt](https://docs.gxc.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gxc.io/plan-your-network/capacity.md). # 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 %} ## Set Capacity & Application Inputs 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 %} ## Review Estimated APs 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 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 ``` 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** | SA | DL | UL | Traffic Profile | | --- | --- | --- | ---------------------- | | SA1 | 70% | 30% | Balanced traffic | | SA2 | 85% | 15% | Downlink-heavy traffic | | SA6 | 60% | 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. | Combination | Channel 1 | Channel 2 | Effective BW | Use Case | | ----------- | --------- | --------- | ------------- | ------------------------------------------------------------------------- | | 2×20 MHz | 20 | 20 | 40 equivalent | Maximum capacity: use when two 20 MHz grants are available | | 2×10 MHz | 10 | 10 | 20 equivalent | Two narrower grants bonded: same total as a single 20 MHz channel | | 20+10 MHz | 20 | 10 | 30 equivalent | Asymmetric 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 synchronization | {% 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 synchronization | {% 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 | n/a | 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*](/introduction.md#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*](/plan-your-network/coverage.md) 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.gxc.io/plan-your-network/capacity.md?ask=&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.