Enter concurrent users
Use the number of users expected to be actively generating traffic at the same peak period, not total registered subscribers.Estimate per-user throughput
Enter an average service demand in Mbps for an active user during that peak.Apply a peak multiplier
Increase base demand to account for short bursts or uncertainty; 1.00 means no peak uplift.Choose maximum utilization
Set the fraction of planned capacity that peak-adjusted traffic is allowed to consume.Review required capacity
Compare the resulting Mbps target with both the small-cell radio capacity and its transport or backhaul connection.
5G Small Cell Bandwidth Requirements Estimator
The 5G Small Cell Bandwidth Requirements Estimator calculates the aggregate throughput a small cell should be able to deliver for a specified number of simultaneously active users. It starts with average per-user traffic, applies a peak-load multiplier for bursts, and then divides by a target utilization level so the resulting capacity includes operational headroom.
This estimate can support early-stage backhaul, transport, and cell-capacity planning for indoor venues, campuses, dense urban zones, and enterprise deployments. It is intentionally technology-neutral with respect to spectrum and modulation: radio conditions, scheduler efficiency, duplexing, spectrum width, MIMO layers, and vendor implementation determine whether the required application throughput can actually be achieved over the air. Use the result as a service-demand target to compare against radio and transport designs.
5G small cell bandwidth inputs
Mbps
×
%
Result
—
required aggregate capacity
Base user demand—
Peak-adjusted demand—
Capacity headroom—
Base demand = Concurrent users × Average throughput per active userPeak-adjusted demand = Base demand × Peak traffic multiplierRequired capacity = Peak-adjusted demand ÷ (Target utilization ÷ 100)
Where:
- Concurrent users — simultaneously active users
- Average throughput per active user — mean service demand in Mbps during activity
- Peak traffic multiplier — dimensionless burst or uncertainty factor of 1.0 or higher
- Target utilization — maximum planned share of capacity used by the peak-adjusted demand
Assumptions: The model sizes aggregate service throughput and does not calculate spectral efficiency or radio resource blocks. Uplink and downlink should be modeled separately if their capacity constraints differ materially.
What the result means
The main result is the aggregate Mbps capacity needed so peak-adjusted user demand stays at or below the selected utilization ceiling.
Radio feasibility depends on spectrum, signal conditions, interference, scheduler behavior, device capabilities, and vendor configuration.
Given:
- 150 concurrent users
- 6 Mbps average per user
- Peak multiplier: 1.4×
- Target utilization: 75%
Calculation:
Base demand = 150 × 6 = 900 Mbps
Peak demand = 900 × 1.4 = 1,260 Mbps
Required capacity = 1,260 ÷ 0.75 = 1,680 Mbps
Result: 1,680 Mbps required capacity
Interpretation: A design delivering 1.68 Gbps of usable aggregate capacity would keep the peak-adjusted 1.26 Gbps demand at 75% utilization.
Why divide by the utilization target?
Dividing by utilization builds capacity above the expected peak demand. For example, a 75% target means the peak-adjusted demand should occupy no more than three quarters of the planned capacity.
Should I include all attached phones in the user count?
Use simultaneously active users for this throughput model. Idle or lightly signaling devices can be numerous without consuming the same data-plane capacity as actively transferring users.
What is a reasonable peak traffic multiplier?
Use a factor based on measured burstiness or a planning scenario rather than a universal default. A value of 1.0 adds no burst allowance, while larger values explicitly increase the peak demand assumption.
Does the result tell me how much spectrum I need?
No. It gives an application-throughput target. Translating that target into spectrum requires assumptions about spectral efficiency, duplexing, MIMO, radio conditions, and implementation.
Can I use the result for backhaul sizing?
Yes, as a starting service-demand target. Backhaul design may need additional allowance for protocol overhead, redundancy, control traffic, growth, and traffic from multiple cells.