UniFi has always supported roaming according to base 802.11 standards. However with Zero-Handoff Roaming enabled, clients can freely roam between UAPs without incurring any latency penalty as a result of the roam. The basic premise is Zero-Handoff enabled UAPs appear as a single AP from the perspective of the client, thus eliminating disconnection.
Zero-Handoff Roaming is available starting with v3.x.
When Zero-Handoff is disabled, a UAP doesn't do anything to assist or influence the station's roaming decision. In testing (v2.x) using WPA-PSK, UniFi developers sent flood pings from the laptop to a PC on the wired side, with the following results:
- From the last ping to the original AP until association completion to the new AP is 45-155ms
- From the last ping to the original AP until the first ping to the new AP is ~1s
For most internet applications (i.e. web-browsing), mobile activity would be seamless. For VoIP, observable delays may be noticed.
Seamless roaming as described by IEEE 802.11r (fast BSS transition) is AP-assisted client roaming. Some vendors require software-solutions for assisting in a fast-handoff solution.
ZH Roaming & Implementation
Zero Handoff Roaming works with any type of 802.11a/g/n client. However, all UAPs in the ZH-Enabled WLAN Group must be on the same layer-2 network (same subnet) and use the same wireless channel (e.g., Channel 1). Listed below are a few things to expect / avoid when deploying ZH-enabled UAPs.
RSSI readings of the AP arriving at the client may appear sporadic. In a non-Zero Handoff scenario where a client is associated to an AP with an RSSI of -75 and "sees" another AP in the same service set at -50 RSSI. The client decides to associate to the other AP. WIth Zero-Handoff Roam, the client sees the same SSID from both APs and may report differing RSSI values (first -75, then -50, back to -74, -51, -75, -49, etc.). Although this can be confusing from the perspective of the client, recall that with ZH-Roaming, the APs themselves handle roaming, not the client.