ZebIQ Technology

// INSIGHTS

High-density WiFi for 5,000 simultaneous devices

6 min read

Five thousand devices in one hall is not a bandwidth problem. It is an airtime problem. Most venue WiFi in India and the UAE is sized for a hundred people checking email, then described as capable of holding a full expo floor. It is not. We design temporary high-density networks around channel reuse, measured spectrum and client count per radio, then bond multiple uplinks so one fibre fault does not end the day.

The load nobody plans for

A trade expo in a convention centre does not generate 5,000 steady streams. It generates bursts. Doors open at 10:00 and 3,000 phones associate within twenty minutes. Registration scanners, badge printers, lead-capture apps and card machines all wake at the same time. Every associated device consumes airtime whether or not anyone is touching it, because probe requests, beacons and management frames go out at the lowest supported rate unless you stop them.

Airtime, not throughput, is the constraint. A single 802.11ax radio on a 20MHz channel holds roughly 45 to 60 active clients before latency climbs past the point where a POS terminal feels broken. Beyond that the fix is more radios on non-overlapping channels, not a bigger internet pipe. Halls with a 1 Gbps leased line still deliver unusable WiFi when eleven access points sit on channel 6 at full transmit power.

India and the UAE each permit their own usable set of 5GHz channels, and in both cases 20MHz channel width in a dense hall beats 40MHz. Wider channels look better on a datasheet and perform worse in a room with 72 APs. 6GHz helps where client hardware supports it, but in a typical Indian expo crowd assume under a fifth of handsets can use it and plan 5GHz as the workhorse.

Why the numbers matter

60-90 APs
typical count for a 5,000-device hall at 20MHz channel width
45-60
clients per radio we design to before adding capacity
INR 7-15 lakh
indicative three-day build for a hall this size, bandwidth excluded

Design constraints we start from

Spectrum before hardware

We sweep the hall with a spectrum analyser before quoting, with in-house WiFi, the neighbouring hall and every LED wall powered on. Video walls, wireless mics and rogue personal hotspots routinely occupy more 2.4GHz airtime than the audience does.

Minimum basic rate raised

We disable 1, 2, 5.5 and 11 Mbps and set the minimum basic rate to 12 or 24 Mbps. Management traffic stops crawling, and distant clients re-associate with a nearer AP instead of clinging to a weak one.

Subnets sized for the peak

Five thousand devices do not fit in a /24. We run a /21 or /22 per zone with DHCP leases cut to 30 to 60 minutes, so addresses recycle as the crowd moves between halls.

VLANs that cannot poison each other

Production, POS, guest, AV and signage sit on separate VLANs, with client isolation on guest and QoS ahead of payment traffic. A visitor laptop scanning the subnet should never reach a badge printer or a card terminal.

Site survey to show day

  1. Predictive model, then walk the floor

    We build a predictive RF model from the floor plan, then walk the empty hall with a survey rig. Stall structures, metal trusses and glass partitions move real coverage by several metres.

  2. Mount, downtilt, aim

    APs go on truss or stands at four to six metres with deliberate downtilt, and patch or directional antennas at the hall edges. CAT6 runs stay under 90m; anything longer becomes a fibre run to a local switch.

  3. Load test with real traffic

    The day before doors we simulate association storms and run registration, POS and signage under load. Power levels, band steering and per-SSID limits get tuned from measured data, not from vendor defaults.

  4. Staff the desk, watch the dashboard

    An on-site IT desk holds spare APs, injectors, patch leads and a bonded cellular fallback. We watch per-radio client counts and channel utilisation live and rebalance during the day.

What usually goes wrong

Captive portals. They are the most common single cause of a hall that feels broken. Every device that wakes gets redirected, the portal becomes a bottleneck, iOS and Android captive-network assistants hammer it, and a queue of 200 people at registration turns into a support line. For an event this size we recommend an open or PSK SSID with no portal. If sponsorship demands a splash page, we serve it from a LAN-origin box with local DNS so it never depends on the WAN.

The rest of the failures are physical and boring. Power: a DG set changeover of six to eight seconds drops every unprotected switch, so PoE switches sit on UPS with at least 20 minutes of runtime. Heat: an access point in a sealed enclosure in a 45C hall throttles or reboots. Cable: someone drives a forklift over an unramped run during stall build and severs a backbone at 07:00. Bandwidth: venues in India and hotel or exhibition-centre properties in the UAE often hold an in-house ISP monopoly, and last-mile fibre lead times of three to six weeks are normal. That is why we bond a second and third link on different carriers instead of trusting one.

Common questions

Can the venue's existing WiFi handle 5,000 devices?

Almost never at the density an expo actually creates. In-house networks are designed for hotel guests or office staff, with APs mounted for coverage rather than capacity, and the venue will rarely rewrite its channel plan for your three days. We normally overlay a temporary network on our own SSIDs and channels, and coordinate with the in-house team so the two do not fight for spectrum.

Do we need per-user bandwidth caps?

Yes, but modest ones. Caps of 2 to 4 Mbps per client on the guest SSID stop a handful of large downloads from consuming a radio without making the network feel slow. The bigger win is airtime fairness, which stops one old 802.11n phone from holding a radio for the same data a Wi-Fi 6 phone moves in a fraction of the time.

What happens if the internet link fails entirely?

Registration, check-in, signage and lead capture should not depend on the WAN. We build offline-first PWAs that keep running with the database, the storage bucket and the whole cloud deployment switched off, using content packages bundled into an immutable hashed release. LAN-origin QR codes resolve through local DNS. The bonded uplink then only has to carry what genuinely needs internet, such as payment authorisation and streaming.