Usable concurrency: browsing 40–60, video 15–25, scanners 30–50
Full bars but slow means capacity, not power — densify instead
Re-test during the real peak after go-live
01 Concurrency by traffic type (rule of thumb)
| Traffic type | Usable concurrency per AP | Notes |
|---|---|---|
| Web and light office work | 40–60 | Dual-band units with clients spread across channels |
| Video, streaming, meetings | 15–25 | Sustained throughput saturates airtime |
| Scanners, POS, PDAs | 30–50 | Small payloads but frequent requests — watch roaming |
| Classrooms, exam halls | 25–40 | Synchronised behaviour needs rate limiting and scheduling |
These are planning starting points, not guarantees — verify with a site survey and pilot.
02 Four variables that decide capacity
- Band steering: push clients to 5GHz by disabling low rates and enabling 802.11k/v.
- Whether peaks are synchronised: if everyone does the same thing at once, design to the low figure.
- Per-client throughput: one 4K stream can consume 25 Mbps, so size by bandwidth, not by device count.
- Roaming overhead: with many clients and few APs, handover signalling itself consumes airtime.
03 Cell radius and AP density
Prefer more APs at lower power over few APs at high power. Lowering power and densifying reduces clients per AP, improves channel reuse and makes roaming natural; a single high-power AP instead produces the classic "full bars, no speed" experience.
Questions
Q1 Why is it slow with full signal?
Coverage is fine but capacity is not: too many clients on one AP saturate the airtime. Densify and lower power rather than turning power up.
Q2 How do I verify capacity?
Test during the actual peak: concurrent clients, per-client throughput, loss and retries. Pilot one floor or zone first.
Related knowledge
Send room counts and expected concurrency and we will suggest AP density.