Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Router Charts

Click for Router Charts

Router Ranker

Click for Router Ranker

NAS Charts

Click for NAS Charts

NAS Ranker

Click for NAS Ranker

More Tools

Click for More Tools

Wireless Features

SmallNetBuilder Roaming Testbed

SmallNetBuilder Roaming Testbed


How To Fix Wi-Fi Roaming tried to explain the whys and wherefores of Wi-Fi roaming. The key intended takeaway was that the wireless device, not the AP/router/mesh point, is the biggest factor in how a device moves between APs.

But Wi-Fi marketeers continue to promise "seamless" roaming and frustrated Wi-Fi users continue to believe them, especially when vendors promise their products use special techniques to bend Wi-Fi devices to their will.

So since I always say that data should do the talking, I'm going to show, in detail, how different devices can have entirely different roaming behavior with the same Wi-Fi system.

Note: This article will use access point or AP to refer to the devices creating your Wi-Fi network. This includes wireless routers, mesh nodes, Wi-Fi systems, Wi-Fi extenders, etc. In the end, they all meet the definition of an access point, i.e. a network device that enables Wi-Fi devices to connect to a wired network.

STA (station) will be used to refer to wireless client devices.

The Players

I decided to use a NETGEAR AC2200 Orbi "mini" (RBK40) for this experiment because I had it on hand and because it supports 802.11k and v roaming assistance standards. So if devices also support either or both these standards, Orbi should be able to help them on their roaming journey. The Router and Satellite backhaul was via Ethernet.

NETGEAR RBK40 Orbi ("mini") AC2200 Wi-Fi System

NETGEAR RBK40 Orbi ("mini") AC2200 Wi-Fi System

For devices, I chose octoScope's Pal-245 partner device, a Windows 10 computer with embedded Wi-Fi adapter and an Android tablet.

With most devices, roaming behavior is a closely guarded secret; no so with the Pal. The Pal-245 provides a STA with known and controllable roaming behavior. Virtually every aspect of its Wi-Fi functions can be controlled, including # of streams, MCS rate and 802.11 mode (a/b/g/n/ac).

For roaming, threshold RSSI (when to roam), band preference and target threshold RSSI can all be controlled (they are outlined in red below). The only thing I couldn't do was disable its 802.11v support (it doesn't support 11k or r).

octoScope Pal-245 controls

octoScope Pal-245 controls

The Lenovo M600 computer with Intel Wireless-AC 8260 internal adapter running Windows 10 Pro 64 bit with latest driver for the adapter were chosen because Microsoft says Windows 10 supports 802.11k,v and r (depending on device driver support, of course) and Intel says the AC-8260 supports 802.11k,v and r.

Intel adapter 802.11k,v,r support (partial list)

Intel adapter 802.11k,v,r support (partial list)

Finally, the Samsung Galaxy Tab A 8" (2017 version - SM-T380) was chosen because it was found to support 802.11k and v by packet inspection, even though neither is specified (of course). In fact, while the tablet is dual-band, it supports 802.11n (and only 1x1, too).

The Test

I used the octoScope based Wi-Fi System Revision 1 testbed for the tests, configured as shown below. Note the Pal-24 and Pal-5 were not used as STAs. Instead, each was set to its packet capture mode to grab control and management frames only, i.e. no data frames.

Each Pal was set to a channel used by Orbi and the capture files were merged before analysis.The Pals and test computer were all synchronized via NTP to ensure proper sequencing of the merged capture files. As noted earlier, the Orbi router and satellite used Ethernet for backhaul.

Roaming test setup

Roaming test setup

All Pals and the Windows STA connected via cable directly to the RF splitter. But the Samsung tablet had to be placed in an octoBox RF chamber and connected over the air (OTA) via antenna. So its signal levels were generally lower.

The roaming test itself was controlled by a Python script to run this sequence:

  1. Set Attenuator 1 to 0 dB, Attenuator 2 to a larger value. This ensures STA will connect to the Router.
  2. Start packet capture
  3. Associate STA to Orbi Router
  4. Start traffic between AP and STA (optional)
  5. Roam device to Orbi Satellite by increasing Atten1 and decreasing Atten 2
  6. Continue to monitor connection for awhile after roam to check for post roam band-steering or other changes
  7. Reverse roam from Satellite to Router by decreasing Atten1 and increasing Atten 2
  8. Monitor post roam as above
  9. Stop traffic
  10. Stop packet capture and save

As noted, running traffic during roaming was not done in each test run. When traffic was present, it came from running a single TCP/IP iperf3 stream from AP to STA, rate-limited to 5 Mbps. The script attempted to restart iperf3 between the post-roam and monitor periods and before the reverse roam start. However, it was not always successful.

In addition to the pcap capture file, a CSV log file was also created. At each attenuator step, the following was logged for Windows or Android:

  • Timestamp
  • STA status (associated, scanning, etc.)
  • IP address
  • Associated BSSID
  • Channel or frequency
  • RSSI (dBm) for Android / Signal % for Windows
  • Link Rate
  • Atten 1 value
  • Atten 2 value

Windows data came from connecting via SSH, running netsh commands and parsing the results. Android data was obtained via a custom app I had developed, which pulled information from the WiFiInfo class in the object. The data was then downloaded in JSON format via HTTP. Both the Windows and Android status data retrievals were made over the device's WiFi connection. Since the connection could temporarily drop during the roam, the script was designed to poll the device until it retrieved data.

Pal's log file captured more data:

  • Timestamp
  • IP address
  • STA status (associated, scanning, etc.)
  • Associated BSSID
  • Channel or frequency
  • RSSI
  • Tx Link Rate
  • Rx Link Rate
  • Roam status
  • Roam scan channel
  • Channel congestion
  • Throughput
  • Atten 1 value
  • Atten 2 value

This data was retrieved in JSON format via Pal's Ethernet control connection.

More Wireless

Wi-Fi System Tools
Check out our Wi-Fi System Charts, Ranker and Finder!

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Over In The Forums

FlexQoS Version 1.1.0 - Released 13-Dec-2020 NEW:Replaced total data transferred pie charts and Bandwidth Util bars with running rate line charts. Av...
Update 2020/12/31 ( 386 rc2-10 - Google Drive This version includesZenWiFi XT8, XD4, CT8GT series: GT-AX1...
Continuation of the first thread which covered beta 1 through 3.Beta 4 is now available. Changes since Beta 3:Code: 6adb157bea asd: disable asd on al...
I've read some recommendations saying enabling Airtime Fairness helps devices maintain faster speeds. I've also read that it can cause stability probl...
I have a pair of RT_66U B1 in a AiMesh pair. Mesh Router192.168.1.18 Mesh NodeWhen I try to access the GUI at it seems to redi...

Don't Miss These

  • 1
  • 2
  • 3