OT Wireless
Search/Menu

Search the field guide, causes, requirements, and glossary

Fleet density beyond channel capacity

Wi-Fi gives every client a chance at the channel, not a slot, so each robot you add stretches the worst-case wait for all of them until a message misses its timeout.

Ben RutterIndustrial network engineer
  • Updated
  • Reviewed
  • 2 min read
  • 5 sources
On this page5 sections
  1. How it presents
  2. Why it happens
  3. How to confirm it
  4. The fix
  5. Prevent it at design time

Is this your problem? It presents like this

  • Drops get more frequent as the fleet grows, with no single change to blame.
  • Worst at peak shift, when the most vehicles are active in the same cells.
  • Channel utilization is high on the affected access points.
  • Average latency looks acceptable while the worst-case latency keeps growing.
  • Many devices across an area are affected, not one model.
Bands
2.4 GHz5 GHz5 GHz DFS
Not sure?
Rank the likely causes from your symptoms

Why it happens

Wi-Fi does not schedule clients; it lets them contend. NIST notes that Wi-Fi uses random access, so channel access is not assured within a deterministic amount of time, and contention grows as devices are added. A vendor validated design for EtherNet/IP over wireless found that more wireless nodes raise maximum latency while average latency may not change significantly. Averages hide the problem. The timeout sees the tail.

Capacity belongs to the channel, not the access point. One enterprise Wi-Fi vendor’s high-density guidance states that adding access points on the same channel with overlapping coverage does not increase capacity. The 2014 validated design set its limit per channel, at 2,200 packets per second for EtherNet/IP traffic1, and tested 4 to 12 workgroup bridges per access point depending on architecture. That design also disabled 802.11n data rates for real-time traffic, so treat its numbers as proof that a limit exists, not as your limit.

More spectrum is the lasting relief. The FCC opened 1,200 MHz in the 6 GHz band2, which it said raises the spectrum available to Wi-Fi by nearly a factor of five, and the Wi-Fi Alliance counts room for 14 more 80 MHz channels or seven more 160 MHz channels3. For a control fleet, the value of 6 GHz is more channels to spread across, not wider ones. Every robot you add spends airtime the others were counting on.

How to confirm it

  1. Chart channel utilization, retries, and client count per access point against time of day and fleet size.
  2. Measure latency percentiles for control messages through the busiest cells, not averages.
  3. Count packets per second per channel and compare with what your application supplier or design guide supports.
  4. Identify which clients and which traffic types use the airtime.
  5. Rule out a single misbehaving client or a bulk transfer before you blame density.

The fix

  • Add channels, not just access points. Spread the fleet across more non-overlapping channels, or move it to 6 GHz where the vehicles support it.
  • Cut the packet rate per vehicle where the application allows it, and remove traffic that does not need the radio.
  • Narrow channels so you have more of them, if the per-client data rate still fits.
  • Mark control traffic so WMM gives it the better odds in contention.

Prevent it at design time

  • Size the network for the fleet you plan to have, with packets per second per channel as the design limit.
  • Test at full fleet size and peak traffic before go-live, and again at each fleet expansion.
  • Keep a channel budget per zone and track utilization against it.

Related causes

Terms on this page

About this page

Built from 5 sources: 1 standards body or lab, 1 regulator or government source, 1 protocol owner or alliance and 2 vendor documents. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made

First published
Last updated
Change history (1)
  • First published
Cite this page

Plain

Ben Rutter. "Fleet density beyond channel capacity." OT Wireless, published October 5, 2026. https://otwireless.com/causes/fleet-density/

APA 7

Rutter, B. (2026, October 5). Fleet density beyond channel capacity. OT Wireless. https://otwireless.com/causes/fleet-density/

BibTeX

@misc{rutter2026fleetdensity,
  author = {Rutter, Ben},
  title = {{Fleet density beyond channel capacity}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/causes/fleet-density/}},
  organization = {OT Wireless},
}