Wi-Fi and Network Connectivity for Service Robot Fleets, The IT Sign-Off Checklist
At a glance: Most robot deployment delays we see are not robot problems. They are network problems that surface after the hardware lands, when the IT team who owns the wireless infrastructure is asked to approve something nobody specified in advance. This checklist gives you the numbers to argue with: coverage floor, handoff latency, band plan, channel width, packet-loss tolerance and the segmentation rules that let IT say yes.
Why Connectivity Becomes the Blocker
A service robot is a mobile endpoint, and mobility is what makes it hard. A laptop can tolerate a dropped frame. A robot navigating a corridor, receiving task updates and streaming telemetry cannot tolerate a two-second blackout at the wrong moment, because the blackout coincides with the moment it is deciding whether the pallet in front of it is real.
The failure mode is not dramatic. The robot does not usually crash. It stops, waits for the link, re-syncs its map, and resumes. What the facility sees is a robot that is mysteriously slow in one corridor and fine everywhere else, and a utilization figure that quietly drops. By the time anyone connects it to the wireless network, three months of bad numbers have been blamed on the robot.
The fix is a specification agreed before deployment. The sections below are the parameters that matter.
Coverage Floor, Expressed as a Number
The single most useful number to agree is a received signal strength floor in the robot's operating envelope. A design target that reflects what actually works for mobile robots is:
| Parameter | Design target | Why |
|---|---|---|
| RSSI in operating areas | −65 dBm or better | Headroom for interference, humans, and metal shelving that attenuate a marginal link |
| RSSI floor, no area below | −70 dBm | Below this, throughput falls off a cliff and roaming becomes unreliable |
| Signal-to-noise ratio | 25 dB or better | SNR predicts usable throughput better than raw RSSI in noisy industrial spaces |
| Coverage in charging bays | −65 dBm | Docks are often in utility corners, the worst-covered place in the building |
| Coverage in lift cars | −70 dBm | Lift shafts are metal boxes; check them explicitly rather than assuming |
The −65 dBm target is not arbitrary. It is the level at which a typical 5 GHz client retains the modulation rate it needs for stable telemetry while leaving margin for the drop that happens when a robot drives behind a rack.
Roaming, the Handoff That Actually Matters
A robot moving at walking pace crosses an access point boundary every 15 to 40 seconds in a dense office deployment. Each crossing is a handoff, and each handoff is an opportunity to lose the task session.
- Handoff latency target. Under 150 ms end to end. Above 500 ms, task updates start timing out and the robot may treat a comms loss as a fault.
- 802.11r fast roaming. Enable it. Fast BSS transition pre-authenticates the client to the next access point so the handoff does not repeat the full authentication exchange. Without it, handoffs take 300 to 800 ms.
- 802.11k neighbour reports. Enable it so the client knows which access point to move to instead of scanning blind and picking the wrong one.
- 802.11v BSS transition. Optional but useful: it lets the infrastructure suggest a better access point when an AP is overloaded.
- Minimum data rate. Set a floor (typically 12 Mbps on 5 GHz). A client hanging onto a distant AP at 1 Mbps holds airtime hostage and degrades everyone on that channel, robot included.
These four features are the difference between a network that works for laptops and a network that works for things that move continuously. If your wireless controller does not support 802.11r at all, that is a finding to raise before the fleet arrives, not after.
Band Plan, Why 5 GHz Is the Default and Where 2.4 Still Earns Its Place
Robots should run on 5 GHz as the primary band. It has more usable channels, wider channels and far less interference from the microwave ovens, Bluetooth beacons and legacy devices that clog 2.4 GHz. The exception is range: 5 GHz attenuates faster through walls and metal, so some sites need a 2.4 GHz fallback for outlying corridors and outdoor areas.
| Setting | Recommended for robot fleets | Notes |
|---|---|---|
| Primary band | 5 GHz, with 2.4 GHz as fallback SSID | Do not use band steering to force only 5 GHz if coverage has gaps |
| Channel width, 5 GHz | 40 MHz in most areas, 20 MHz in dense or high-interference zones | 80 MHz sounds better and almost never is; it collapses the channel plan and increases co-channel interference |
| Channel width, 2.4 GHz | 20 MHz only, channels 1, 6, 11 | Never 40 MHz on 2.4, it overlaps and hurts everyone |
| AP density | Coverage cells sized for −65 dBm at the edges, not maximum range | More APs at lower power beats fewer APs at high power for roaming |
| Transmit power | Reduced, to balance cell sizes | Maximum power creates large cells, few handoffs and sticky clients |
The AP density rule is the one teams get wrong most often. Turning power up to cover a gap creates an asymmetric cell where the robot clings to a distant AP at low data rate instead of moving to the nearer one. Lower power, more access points, cleaner handoffs.
Packet Loss and Latency Budget
Agree a quality budget with IT in terms of what the robot's traffic can tolerate, not in terms of general network health. Different traffic classes have very different requirements.
| Traffic class | Latency budget | Loss tolerance | Notes |
|---|---|---|---|
| Safety and control commands | < 100 ms | < 0.1% | Should be treated as priority, but never travel over the public internet |
| Navigation map updates | < 500 ms | < 1% | Bursty; the robot buffers, but stale maps cause hesitation |
| Telemetry and status | 1 to 2 s | < 5% | Tolerant, but high loss masks real faults |
| Video for remote assistance | < 200 ms | < 2% | The heaviest consumer; cap resolution before you widen channels for it |
| Firmware and log upload | Best effort | Any | Schedule off-peak; never during operational hours |
The safety-control row deserves emphasis. Anything that stops a robot must be decided on the robot, with a local safety controller, and not depend on a network round trip. A wireless link is a supervisory channel, not a safety channel, and any architecture that treats it otherwise should be questioned in the vendor review.
Segmentation, Giving IT a Reason to Say Yes
IT teams resist robots on the corporate network for good reasons. A fleet of mobile Linux endpoints with OTA update channels is a real attack surface. The way to get approval is to bring a segmentation design that answers the concern.
- Dedicated IoT SSID and VLAN. Robot traffic in its own broadcast domain, separate from corporate endpoints and guest Wi-Fi.
- No client-to-client traffic. Robots talk to the fleet server, not to each other, so peer isolation should be on by default.
- Egress rules, not blanket open internet. Whitelist the fleet management endpoints and the update servers, deny the rest.
- No inbound from the internet. Remote assistance and telemetry should be outbound-initiated or brokered through a tunnel.
- Certificate-based device identity. Each robot authenticates with its own certificate over 802.1X rather than a shared pre-shared key.
- Documented update path. Where firmware comes from, how it is signed, and who approves it.
This pairs directly with the wider security review. The VLAN design is the network layer of the same problem covered in our guide to fleet cybersecurity and data privacy, and it is usually the clause that unblocks a stalled deployment.
The Site Survey You Should Demand
A predictive survey from a floor plan is not enough for robot coverage, because it does not see the steel racking, the wet-floor equipment or the loaded pallets that appear in the actual operating environment. Insist on a passive survey during live hours, before the fleet is delivered.
- Walk the actual robot route at operating speed with a survey tool, not a random empty-space grid, and record RSSI and SNR at the points the robot will occupy, not at head height only.
- Measure the dock and lift car as separate zones. These are the two places coverage is most often assumed and least often true.
- Capture a baseline interference scan on both bands, so a later degradation can be diagnosed against evidence.
- Record handoff behaviour, not just coverage. A walk test that logs how many handoffs exceeded 150 ms is more valuable than a heat map.
- Re-survey after fit-out if racks, partitions or machinery are added, because coverage is only valid for the environment it was measured in.
What to Include in the Vendor Specification
Turn the above into contractual language so responsibility is clear when something works for the laptop fleet and not for the robots.
- State the required RSSI and SNR floors in the actual operating envelope, and make the network the facility's responsibility and the robot's roaming behaviour the vendor's.
- Require the vendor to publish roaming behaviour: which standards the client supports (802.11r/k/v), and how the robot behaves during a handoff.
- Require a stated packet-loss and latency tolerance per traffic class, and a documented degraded-mode behaviour when the link drops.
- Require local safety logic and confirm in writing that no safety-critical stop depends on the wireless link.
- Require the segmentation design in writing so IT can review it as part of procurement rather than as a post-delivery surprise.
Connectivity is unglamorous and it is the single most common reason a technically sound robot deployment underperforms. The network is not a supporting detail of a fleet project, it is a component of it, and it should be specified with the same rigour as the machines. If your project is still at the earlier stage of deciding which machines, our buyer's guide covers the hardware side, and this checklist is what you run alongside it.
The Takeaway
Robots need a wireless network designed for mobility, not a network designed for people sitting still. The four levers are coverage floor, fast roaming, band and channel planning, and segmentation. Each has a number you can specify. Bring those numbers to IT early, insist on a live site survey instead of a predictive one, and put the tolerances in the contract. Do that and the robot stops being the thing blamed for a network problem.
