What to demand from your wireless vendor
A checklist for controls engineers who must specify wireless without being RF people, with nine demands, why each matters, and how to make the vendor prove it on your floor.
On this page9 sections
- Worst-case roam time, measured on your client under your security
- A plan for DFS
- A channel and power plan, and a rule for automatic changes
- Change control for firmware and configuration
- QoS marking preserved end to end
- Traffic separation
- A survey that sees moving metal, racking, inventory, and finished product
- Validation with the real vehicles at speed
- Logging that can prove what happened
You do not have to be an RF engineer to specify wireless. You have to ask for numbers the vendor must prove on your floor, with your vehicles, in production conditions.
Each demand below says why it matters and how to check the answer. Put them in the specification, where they are binding, not in a kickoff meeting.
Worst-case roam time, measured on your client under your security
Why it matters. The client decides when and how to roam. One industrial design guide says it directly: the client device decides to roam, and fast roaming only works if the client supports the chosen method. A roam time measured on a laptop tells you about the laptop.
Averages hide the problem. The same guide notes that latency grows with the number of nodes on a channel while the average may not change significantly, and that a very small percentage of packets can be delayed enough to be unusable. A classic measurement study of 802.11b handoffs found large variation from one handoff to the next, and between client cards from different vendors. Your application’s timeout does not care about the average.
Security changes the roam. Fast secure roaming skips the EAP exchange that a full 802.1X authentication needs. NIST notes that roaming may require different security controls to reduce the transition time. A roam measured with open or pre-shared key security says nothing about your 802.1X or WPA3 network.
Field note. Required roam time depends on what is connected and whether safety runs over wireless, such as CIP Safety. Safety over wireless needs very low roam times to avoid safety timeouts.
How to verify. Require the maximum gap, not the mean. It must be measured on the production vehicle radio and firmware, with the production security configuration, across every roam on complete routes. Compare it with the shortest loss-of-comms timer on that vehicle.
A plan for DFS
Why it matters. Channels in the 5.25 to 5.35 GHz and 5.47 to 5.725 GHz bands1 carry radar detection rules. After a detection, the access point must stop transmitting on that channel within 10 seconds and stay off it for at least 30 minutes. Before it may use a DFS channel, it must listen for 60 seconds. One industrial design guide advises avoiding DFS channels 52 to 144 for industrial control2.
How to verify. Ask which channels in the plan are DFS channels, and why. Ask what the access point and the vehicle clients do after a detection, and where they go. Require every radar event in the logs, with time, channel, and access point.
A channel and power plan, and a rule for automatic changes
Why it matters. Wireless systems commonly adjust channels and power on their own. One industrial design guide recommends dynamic channel assignment, which adjusts channels over time, but says a restart of it should not be performed without change management approval where real-time applications run. NIST notes that many wireless systems employ automatic power control, and that more transmit power is not necessarily an improvement.
A channel change on a radio moves every client on that radio. If it happens mid-shift, your vehicles take that roam in production.
How to verify. Get the channel plan and the power plan in writing. Ask whether automatic changes run during production, when they run, and who approves them. Require a log of every change.
Change control for firmware and configuration
Why it matters. NIST’s guide to industrial wireless deployments recommends checking for updates but not installing them automatically. It calls for testing in a controlled environment, configuration management with roll-back, and an approved deployment plan, because an update to a factory system could result in downtime.
How to verify. Ask for the update process in writing: where updates are tested, how roll-back works, and how maintenance windows line up with your production schedule. Ask whether any setting can reach the floor outside a window, including from a cloud management portal.
QoS marking preserved end to end
Why it matters. The access point picks the wireless priority for each packet from its marking. One industrial design guide states that control traffic is assigned a wireless QoS category based on the QoS marking in the data packets. Strip or rewrite the marking anywhere on the path, and control traffic waits in line with everything else.
The mapping has traps. The IETF found that the common practice of copying the top three DSCP bits into the 802.11 priority misaligns several traffic classes3. It also says access points must not derive upstream DSCP from priority markings set by wireless clients, and notes that tunnels between access points and controllers can re-mark traffic.
Field note. You have to know everything on the air so control and safety traffic are prioritized over large transfers and updates.
How to verify. Capture control traffic in both directions, on the wire and over the air. Confirm that the DSCP on the wire and the priority on the air match the design at every hop.
Traffic separation
Why it matters. NIST recommends placing wireless devices in a separate network segment, with access points creating independent segments behind a boundary protection device. Airtime needs separating too. One design guide advises allocating channels exclusively to industrial control and not sharing spectrum with applications under different management.
How to verify. Ask for a map of SSIDs, VLANs, and channels that shows which traffic shares which channel. A separate VLAN on the same channel still shares the airtime.
A survey that sees moving metal, racking, inventory, and finished product
Why it matters. Your plant is not the empty building the survey saw. NIST notes that steel reflects RF while concrete absorbs it, that stacking or moving materials through wireless links must be monitored, and that the physical factory environment can be very dynamic. It warns that a heat map should not be the single indicator, and that a strong signal is not a definitive indicator of quality where reflections dominate. One AMR maker requires full Wi-Fi coverage throughout the travel path of all robots, and warns that shelves and other obstacles can easily degrade or cut the signal.
How to verify. Ask how the survey accounts for full and empty racking, finished product staged on the floor, and equipment that moves. Require measurements along every vehicle path, not just in open aisles. Ask what triggers a resurvey. NIST’s answer is that changes to the factory should go through change management that includes the impact on wireless.
Validation with the real vehicles at speed
Why it matters. NIST recommends validating performance with the physical equipment rather than trying to predict it, testing with the existing level of traffic and while the plant is in operation, and letting the system run for a period of time.
Speed turns time into distance. One heavy-payload AMR is rated for a maximum speed of 2.0 m/s4. At that speed, every second of outage is 2 meters traveled, and the vehicle crosses cell edges faster than a test cart pushed by hand.
How to verify. Write the acceptance test into the contract. Use production vehicles at their top operating speed, on real routes, with the full fleet and normal plant traffic running, for long enough to catch the rare roam and not just the typical one. Pass or fail on the worst-case gap against the vehicle’s shortest timer.
Logging that can prove what happened
Why it matters. When a vehicle stops, three systems each hold part of the story: the wireless network, the vehicle, and the fleet manager. NIST says time synchronization is what makes event and log correlation possible, and that a common time should be used across all OT devices. Vehicle interfaces allow for it. A VDA 5050 robot can declare its NTP servers in its factsheet.
How to verify. Take a timestamp from a real drop. Ask the vendor to produce, on one clock, the client’s association, roam, and disconnect events from the wireless side, the vehicle’s own log, and the fleet manager’s record. If they cannot be lined up, nobody can prove what happened.
If the vendor shows you the average, you are buying the average. Demand the worst case.
About this page
Built from 9 sources: 3 standards bodies and labs, 1 regulator or government source, 1 protocol owner or alliance, 1 research paper or thesis and 3 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. "What to demand from your wireless vendor." OT Wireless, published October 5, 2026. https://otwireless.com/guides/what-to-demand-from-your-wireless-vendor/
APA 7
Rutter, B. (2026, October 5). What to demand from your wireless vendor. OT Wireless. https://otwireless.com/guides/what-to-demand-from-your-wireless-vendor/
BibTeX
@misc{rutter2026whattodemandfromyourwirelessvendor,
author = {Rutter, Ben},
title = {{What to demand from your wireless vendor}},
year = {2026},
howpublished = {\url{https://otwireless.com/guides/what-to-demand-from-your-wireless-vendor/}},
organization = {OT Wireless},
}