Another thing that can affect roaming is whether the STA is busy, i.e. running traffic. This next test changes the Pal roam settings back to -70 threshold and -60 target, but this time starts a TCP/IP iperf3 stream, limited to 5 Mbps, right after the STA associates. The stream runs until the connection is broken, which happens when Pal roams and gets a new IP address. This really shouldn't happen and appears to be due to some interaction between Pal and Orbi that hasn't yet been tracked down.
Roaming test - Pal w/ -70 threshold w/ traffic
This roam actually appears smoother than the first example, which was done with the same Pal settings, but without traffic. The partial Pal log below shows roam scanning starts right when Pal hits -70 RSSI. Traffic ("Throughput" column), however, stops when the IP address changes (I think the lone 11 Mbps log entry is a glitch). The capture log shows a pattern of disassociations and 11v BSS Transition Management Requests similar to those shown in the first roam example.
Pal log - roam w/ traffic
So far, we've set Pal's band preference to Auto, which causes it to connect to the strongest signal when roaming. Our last experiment sets Pal's roaming band preference to 5 GHz, while leaving roam threshold at -70 dBm and roam target at -60 dBm. The roam plot would seem to indicate band preference doesn't ensure Pal always connects to 5 GHz.
Roaming test - Pal w/ -70 threshold, 5 GHz band preferrence, no traffic
The first part of the Pal log shows connection to the Orbi router's 5 GHz radio. Then a roam scan starting right when the roam threshold of -70 is hit results in a move to the 2.4 GHz radio on the same AP. But even though the move to 2.4 GHz puts RSSI above the roam threshold, Pal almost immediately starts scanning again @ 83.6. It finally moves to the Orbi satellite 5 GHz radio (08:02:8e:9f:3a:f9) 93.2 seconds into the run.
Pal log -roam with 5 GHz band preference
The packet capture shows Orbi and Pal battling between where each one thinks Pal belongs. Orbi first kicks Pal from the router's 5 GHz radio (Netgear_9f:39:c8), but it connects right back. No disassociation, deauth or 11v BSS Transition Requests are involved when Pal moves to Orbi router's 2.4 GHz radio at the 75.1 second mark. But Orbi tries to kick it right off with a disassociation @ 75.5. Orbi finally makes its own decision to move, disassociating from Orbi router's 2.4 GHz radio @ 91.7 and immediately connecting to Orbi satellite 5 GHz (08:02:8e:9f:3a:f9).
Packet capture - Pal 5 GHz band preference
I don't know why Orbi satellite immediately tries to kick Pal off @ 92.1. But Pal reconnects immediately, staying put for 90 seconds before Pal moves back to Orbi router's 2.4 GHz radio (0e:02:8e:9f:39:c5) @ 184.3, which immediately disassociates Pal, which immediately reconnects in response.
Packet capture - Pal 5 GHz band preference - more
Note the first time Orbi attempts to band steer pal via 11v is 192 seconds into the run, recommending a move back to Orbi router's 5 GHz radio. The takeaway from this experiment is that a band "preference" is only that, not a guarantee.
So given the same conditions, is a device's roaming behavior always the same? Well, in real life, it would be impossible to duplicate the exact conditions from roam to roam. Device signal levels, RF environment including neighboring networks and traffic levels are constantly changing, all of which can affect roaming behavior.
Even under conditions as controlled as I can make them, roaming behavior can vary widely from run to run. The plot below (sorry for the eye chart) combines three runs, all with Pal roaming threshold set to -70 dB, roaming target set to -60 dBm and traffic running at the start of each run. Roam 2 takes the prize for most device transitions, six in all. Actually, there were seven connection changes during the run if you count the first one—a band steer from Channel 6 to 40 not shown. This is why the run starts around 20 seconds later than the other two.
Roaming test - Pal w/ -70 threshold w/ traffic - three runs
I know I said we'd also look at roams using Windows and Android STAs, but that will have to wait for next time!