Network Bandwidth Bandwidth Requirements Estimator

This estimator turns a shared-network traffic profile into a recommended bandwidth requirement. It starts with the number of users, the expected bandwidth per active user, and the percentage likely to be active at once, then adds allowances for protocol overhead and capacity reserve.

The result is useful for early sizing of internet access, WAN links, office uplinks, or other shared connections before application-specific monitoring data is available. Because real traffic is bursty and applications have different upstream and downstream needs, the estimate is best used as a transparent planning baseline that can later be refined with measured utilization.

Traffic and capacity inputs

Mbps
%
%
%
Result
Recommended shared bandwidth
Concurrent active users
Payload demand
Demand with overhead
Recommended bandwidth

1. Enter the user count

Start with the population expected to share the network connection.

2. Estimate active-user demand

Enter the Mbps needed by one active user during the planning period.

3. Set concurrency

Enter the percentage of total users likely to be active at the same time during a busy period.

4. Add engineering allowances

Use overhead for traffic beyond application payload and reserve for capacity you want to keep available for bursts or growth.

5. Review the recommendation

Check the recommended Mbps alongside active-user count and the intermediate demand figures so you can validate the assumptions.

The estimate starts with simultaneous payload demand, adds protocol overhead, and then increases the link size so the chosen reserve remains unused under the modeled load.

Active users = U × C Payload demand = Active users × P Demand with overhead = Payload demand × (1 + O) Recommended bandwidth = Demand with overhead ÷ (1 − R)

U is total users, C is expected concurrency as a decimal, P is Mbps per active user, O is protocol overhead as a decimal, and R is capacity reserve as a decimal.

The calculation assumes these users can be represented by one average active-user rate. For network, asymmetric traffic, provider contention, burst behavior, or application-specific requirements may require separate upstream and downstream models.

What the result means

Use the result as a planning estimate based on the values entered. Compare it with measured performance or system-specific engineering limits before making a deployment decision.

Changing any input updates the result automatically; Reset restores the example defaults shown on this page.

Given: 220 users, 5 Mbps per active user, 42% concurrency, 10% overhead, and 25% reserve.

Calculation: Active users = 220 × 0.42 = 92.4. Payload demand = 92.4 × 5 = 462.00 Mbps. With overhead = 462.00 × 1.10 = 508.20 Mbps. Recommended bandwidth = 508.20 ÷ 0.75 = 677.60 Mbps.

Result: Plan for about 677.60 Mbps (0.678 Gbps) under these assumptions.

Why divide by one minus the reserve percentage?

The reserve is the portion of the final link that should remain unused. Dividing by the usable fraction sizes the total link so modeled demand occupies only the non-reserved share.

Should concurrency be based on registered users or active sessions?

Base total users on the population that can generate traffic during the same planning window, then use concurrency to estimate how many are active at once. Avoid counting dormant accounts that cannot realistically be online during that period.

How should I choose per-user Mbps?

Use application requirements or measured busy-period throughput for a representative active user. If workloads differ significantly, model separate user groups instead of relying on one broad average.

Does the estimate include upload and download separately?

No. It produces one aggregate bandwidth figure from the rate you enter. If upstream and downstream demand differ materially, run separate calculations for each direction.

When should I add more reserve?

For network, extra reserve may be appropriate when traffic is bursty, demand is growing, service rates fluctuate, or exceeding a threshold would noticeably affect performance. The reserve is a planning choice, not a universal standard.