Handheld scanners and tablets
A handheld's operating system, not your access points, decides when it roams and when its radio sleeps, so the network has to be built around the client and the session it carries.
A handheld decides for itself when to roam and when to let its radio sleep. The session it carries has to survive both.
The strongest objection is that a handheld is not control equipment. ODVA’s wireless safety paper says a tablet used for dashboards is more like an IT asset than an OT asset, because losing it will probably not stop the process. That is true for the machine. It is not true for the person holding the device. One terminal emulation vendor notes that losing the connection for a moment when switching from one access point to another is enough to drop the host session. The person holding the scanner waits until it reconnects. Multiply that by every picker on a shift.
A tablet that becomes part of the control system, such as a wireless teach pendant, is a different class of device, and this page leaves it out. Its timeouts belong to the machine builder.
What it carries
Warehouse transactions. Receiving, putaway, picking and counting run as steps on the handheld, each one a transaction with the warehouse management system (WMS). In Microsoft’s warehouse app, for example, one worker’s receipt can create putaway work for another worker, and a pick can be confirmed by scanning a bar code.
Terminal emulation and browser apps. Some hosts reach handhelds through terminal emulation (TE): a live session to a back-end host over Telnet, TN3270 or TN52501, or over SSH. Other apps run in a browser. One TE vendor ships both, a terminal client and an industrial browser, for legacy hosts and modern web applications.
Voice. Push-to-talk group calls can ride multicast. One handheld maker’s push-to-talk client sends group calls as multicast, which each access point transmits once, with no retries, at a fixed rate. Voice-directed picking runs on voice terminals built for hands-free, eyes-free work. Video calls add a third load: Microsoft’s network guidance for Teams asks for QoS or WMM, and rates 5 GHz better suited to real-time media2.
What it needs from the network
A session that outlives the roam. Terminal emulation vendors sell proxies because it often does not. One lists the reasons a host connection drops: the device goes out of Wi-Fi range, enters sleep mode, or loses its connection for a moment when switching from one access point to another. Its proxy holds the host session so the client continues where it left off. Another sells the same idea for devices that may not have a reliable Wi-Fi connection. Those are vendors describing their own products. The failure they describe is real enough to build products around.
Fast roaming that each operating system actually uses. Support differs by platform, and a mismatch costs a full roam:
- Windows uses 802.11k to shorten the list of channels it scans, accepts 802.11v transition requests, and supports 802.11r over 802.1X only, not PSK or open networks3. It falls back to opportunistic key caching, and the radio driver has to support all of it.
- iPhone and iPad support 802.11k, r and v, with fast transition on both PSK and 802.1X4. Without 802.11k, a roam scan of every channel can add several seconds.
- Android leaves the choice of access point within one SSID to the Wi-Fi chip’s firmware roaming, when the device has it. Roaming behavior can differ from one handheld model to the next.
The client roaming matrix and the entries for Windows, Android and iOS and iPadOS list what each supports. The spread is wide. A 2026 bachelor thesis that timed roams by counting lost pings measured 15 to 25 ms on one Android phone using fast transition, about 110 ms on another with it turned off, and over 5 seconds for an iPhone roam on 2.4 GHz5. Those were phones in a lab, with few runs. Measure your own handhelds.
Power save that does not starve the app. Power save trades latency for battery, and the operating system makes the trade. Microsoft says it directly: power save mode reduces power consumption at the cost of increased data transfer latency, and on battery it is expected to stay on unless a low-latency connection such as a VoIP call needs it off. On Windows modern standby platforms, a Wi-Fi device in connected sleep can take up to 300 ms to return to active6, and asks the access point to hold its traffic for 10 beacon intervals. Android lets an app hold a low-latency Wi-Fi lock only while the screen is on and the app is in the foreground. The older lock that kept Wi-Fi out of power save with the screen off was deprecated in API level 347.
Multicast that arrives on time. Once any client on an access point uses power save, the access point buffers all multicast and sends it only after the next DTIM beacon. One handheld maker’s push-to-talk guide asks for a DTIM of 1 or 2 at a 100 ms beacon interval8, which caps that wait at 100 or 200 ms. The mechanism is on multicast and DTIM.
How wireless fails it
Sticky clients. An iPhone or iPad keeps its access point until the signal passes -70 dBm, and then wants a candidate 8 dB stronger while sending or 12 dB stronger while idle. A worker can walk well past the next access point before the device lets go. See sticky client.
Low-latency modes that stop roaming. Android warns that its low-latency lock may reduce scanning, so the device may not roam or switch to the access point with the best signal. An app that holds the lock to protect a call can strand the device on a fading cell.
Sessions that die in sleep or in a slow roam. The host does not know the handheld is asleep or mid-roam. It sees silence. TCP backs off while it waits: each time a retransmission goes unanswered, the sender doubles its retransmission timer, so traffic can stay stalled after the radio is back. A host may close a session it thinks is idle, which is why one TE proxy sends keepalives so the host does not disconnect for inactivity. Android adds two more exits. The same TE vendor notes that Android may drop the host session when the app goes to the background, and a device left on a cart, unplugged and still with the screen off, enters Doze, which suspends network access.
Band steering. Microsoft’s Teams guidance suggests band steering to move dual-band clients to 5 GHz. Steering works by delaying, denying or disconnecting clients, and a handheld mid-transaction pays for each delay. See band steering and load balancing.
Low rates for multicast and beacons. The push-to-talk guide sets the multicast rate low enough for at least 90% reception anywhere in the cell, and warns that any lower wastes airtime and adds co-channel interference. See low data rates and management overhead.
Design implications
Put the session somewhere that does not roam. A session proxy or persistence server between the handheld and the host turns a dropped connection into a reconnect instead of a new login. Ask whether your TE or browser app has one.
Enable fast roaming for the clients you actually have. Turn on 802.11k and 802.11v. Turn on 802.11r where every client on the SSID can use it with your key type; Windows, for example, supports it over 802.1X only. Test each handheld model before the change, because a mismatch turns fast roams into slow ones. See fast roam mismatch and slow roam, full reauthentication.
Set the DTIM for the most delay-sensitive app on the SSID. An access point advertises one DTIM period in its beacons, so every client on that SSID shares it. If push-to-talk shares an SSID with battery-sensitive devices, one of them gives way.
Ask the handheld maker how its apps hold the radio. Find out which power settings, locks or exemptions the TE client, the voice client and the device image use, and what each does to roaming.
Design cells around the client’s thresholds. An iPhone or iPad starts looking at -70 dBm and wants a candidate 8 to 12 dB stronger. So where the current access point fades past -70 dBm, the next one has to read about -62 dBm for a device that is sending, and -58 dBm for one that is idle. Survey with the handheld itself, not only with a survey adapter.
How to validate
Walk the real routes with each model and each OS version. Run the real apps while you walk: a TE session, a push-to-talk group call, a video call. Time every roam with the method in how to measure a roam gap.
Test the idle cases. Leave a device asleep on a cart, then pick it up and scan. Background the TE app, then bring it back. Record whether the session survived each case.
Test multicast at the edge. Run a group call with devices in power save at the far edge of a cell, and listen for lost or late audio.
Confirm the roam method in a capture. A configuration screen says what is enabled. A capture of the authentication and reassociation frames shows what the device used.
Retest after every OS update. Roaming and power behavior live in the operating system and the driver, and both change with updates.
For a handheld, the network passes or fails on one thing the user sees: whether the screen they were on is still there after the walk.
About this page
Built from 16 sources: 2 standards bodies and labs, 1 protocol owner or alliance, 1 research paper or thesis and 12 vendor documents. Researched and drafted with AI assistance. How pages are made
- First published
- Last updated
Change history (1)
- First published
Cite this page
Plain
Ben Rutter. "Handheld scanners and tablets." OT Wireless, published October 8, 2026. https://otwireless.com/applications/handheld-scanners-and-tablets/
APA 7
Rutter, B. (2026, October 8). Handheld scanners and tablets. OT Wireless. https://otwireless.com/applications/handheld-scanners-and-tablets/
BibTeX
@misc{rutter2026handheldscannersandtablets,
author = {Rutter, Ben},
title = {{Handheld scanners and tablets}},
year = {2026},
howpublished = {\url{https://otwireless.com/applications/handheld-scanners-and-tablets/}},
organization = {OT Wireless},
}