We need Wi-Fi everywhere! People are expecting whole-home coverage and if new features like fancy antennas or beamforming technology don’t cut it, strategically placing additional Wi-Fi gear in a home should increase the coverage area.

However, after setting it all up, these secondary access points, repeaters and other equipment should play nice and act as one big happy network that we can use throughout the home. To help realize this, the Wi-Fi standard provides the Wi-Fi seamless roaming functionality.

Let’s find out the do’s and don’ts in this blogpost.

The Theory

Wi-Fi seamless roaming is the process in which a client device is connected to one access point, finds an access point with better signal quality in ‘the same network’ and jumps to the latter one. Ideally without the user noticing that a switch has happened. All client devices support this seamless roaming feature as it is part of the 802.11 specification. The first catch are the three strict conditions that define ‘the same network’:

  • The SSID, broadcasted by the access points involved, must be identical
  • The complete security configuration (Open/WEP/WPA/WPA2) must be identical
  • The access points must be in bridge mode and their distribution system (or backhaul) must connect to the same IP subnet

When the first two requirements are met, the client device recognises the second access point as being ‘part of the family’. When discovering such a network, the client jumps to it whenever the received signal strength (RSSI) is significantly larger than the one from the access point it is currently connected to. Note that important aspects – when are family networks detected and what is ‘significantly’ better RSSI – are left to client implementation. We’ll get back to this in a second. Also remark that client devices, by spec, automatically assume the third requirement is also met – which is your responsibility to ensure!

If one of the first two requirements is not met, the client device will not roam to another access point as long as it still receives signal from its current access point. The client device can be physically next to a second access point and still not connect to it.

The Clients

Experiments in our Wi-Fi test house showed that the moment when a client device decides to switch from the first access point to a second —’better’— access point differs between different clients.

iOS devices (like iPhones, iPads) for instance start searching for access points with higher signal strength once the signal strength of the current connection drops below a fixed threshold (about -70dBm). Samsung devices (more specifically the Galaxy S range) on the other hand periodically scan for neighboring access points, regardless of the current signal strength. These are allowed design choices and allow a manufacturer to optimize their roaming behavior for specific use cases.

These design choices however are not without impact. For example, we take the scanning frequency of the devices into account when running performance tests in our Wi-Fi test facility as it impacts the throughput.

The picture above shows an actual TCP throughput measurement and clearly shows when the device starts scanning. Because the client must scan on different frequencies for neighboring access points, it notifies the current access point that it will be temporarily unable to receive anything (by pretending it is going into power-save mode). This explains the drop in throughput in the picture above.

The DOs and DON’Ts

So what does this mean in practice? Let’s list a few of the gotchas we’ve stumbled upon during roaming tests in our Wi-Fi test house.

Frequency Band Roaming

Dual Band access points (broadcasting on 2.4 and 5 GHz simultaneous) typically default to the same configuration (SSID/security) on both 2.4 and 5 GHz to allow seamless roaming between both frequency bands. However, when no band steering is applied by the access point, clients tend to stick on the 2.4 GHz band as that one typically has the highest signal strength. For that reason unless band steering is available on the access point, seamless roaming between frequency bands on the same access point is discouraged.

Repeaters

Some wireless repeaters override the source MAC address in forwarded packets to be able to run the WPA/WPA2 security mode. The reason for this is the fact that the security key is typically bound to the MAC address and repeaters only have the security key for their own MAC address. In a roaming situation, the overridden MAC address can confuse the main access points as packets from the client device – that has now roamed to the repeater – suddenly appear with a different source MAC address. Again, seamless roaming is discouraged in this kind of situations unless you have verified that in your specific access point-repeater combination it works.

TKIP versus AES

Within a roaming network, one must ensure that all security settings on the access points are identical. We have seen cases where seamless roaming failed to work with certain client devices when one access point was configured for TKIP/AES while others were configured for AES-only. When connected with the first, TKIP was chosen as the group cipher suite (for broadcast/multicast traffic), but when the client attempts to roam it is denied by the second access because of this proposed group cipher suite.

A nice observation was that the client device automatically returned to its original connection with the first access point once it noticed that roaming to the second access point was not allowed.

Want To Know More?

Start experimenting with multiple access points, their configuration and how your client devices behave on them! Also make sure to subscribe to this blog, as we’ll continue to post our observations on roaming —and other Wi-Fi features— here!

Are you running into specific Wi-Fi roaming problems? Let’s talk!

Reader interactions

One Reply to “Wi-Fi Roaming Gotchas”

  1. Nice article.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.