Optimizing Wi-Fi 6E networks for Apple Devices

Written By Ben Toner

The new iPad Pro marks a milestone for Apple as the first Apple device to support of Wi-Fi 6E, utilising the relatively new 6GHz band. This is a significant step, but in true Apple style, the implementation is one which sets out to protect the user experience by way of battery consumption, device responsiveness and best network selection. So how do you go about optimizing Wi-Fi 6E networks for Apple Devices?

In this blog, we lift the lid on the network selection algorithms Apple are using and reveal how it navigates all the available networks to make a selection choice. If you want to know how to setup your Wi-Fi network to be favoured by Apple devices and ensure you get the most out of your new 6GHz capability, then read on.

Huge thanks to Jiri Brecha and Cisco for the loan of a Catalyst 9136 without which I could not have done this testing

Wi-Fi 6E and Apple’s advice

Apple recently updated their Wi-Fi network configuration advice to inform us against setting up a different network for each band. According to Apple, the optimal Wi-Fi network will use a single SSID across all bands - 2.4, 5 and 6 GHz.

Jiri Brecha has put the iPad through its paces and demonstrated how standalone 6GHz networks are simply not connected. Jiri shows how the iPad needs to see an RNR (Reduced Neighbour Report) from a beacon on either 2.4 or 5GHz to know which 6GHz channels to scan and potentially connect.

So we know that any desire to use 6GHz with an iPad requires a multi-band implementation where a 2.4 or 5GHz channel is active and contains an RNR report for the 6GHz network in its beacon. But we can go further with this… by exploring the device logs and looking at the auto-join behaviour of the operating system, we can learn a lot more about the internal selection algorithms and make sure our implementations are the best they can be.

Device logs can often reveal a lot of helpful internal device logic. nOversight is a tool which ingests Apple device logs from iPhones and iPads and presents us with connectivity information which includes network selection and roaming logic. We’ve used the newly released version 4.1 to teach us about the latest Wi-Fi 6E logic.

nOversight tools

nOversight mobile & Desktop tools

The iOS auto-join sequence

iOS devices choose the Wi-Fi network to which they should connect using the auto-join framework - a process by which iOS optimally searches through the available networks to quickly discover and select the best Wi-Fi network out there. But what is ”best”? To understand that we need to explore the logs (this is one of those scenarios where the logic is completely internal to the device and will not be seen on a packet capture).

To get us started, lets look at the basic auto-join framework. It is a state machine which broadly follows the following sequence in order of preference and will stop as soon as it finds a suitable network. The state names broadly speak for themselves (but I don’t really know what a Target Network is yet). If there is no suitable network in one of these states, it will move on to the next and try to use the cached scan results where possible and only scan new channels if needed.

States are:

Target Networks —> Non-Captive Networks —> Captive Networks —> Standalone 6GHz —> Low-RSSI Networks

Within each of these states, there are sub states which sets up prioritised scans; first looking for channels it thinks should be around for the networks it has saved (it also performs an online lookup for SSIDs and Channels previously seen in the current location area). If nothing is found, it checks for hidden SSIDs and then expands the search to a wider set of channels.

The following extract from nOversight shows a typical good flow through the state machine where there is a non-captive network suitable for connection.

Scanning for 6GHz networks

So how has 6GHz scanning been added into the mix?  We know from other blogs that the iPad has been observed to only scan 6GHz when following an RNR.

The detail behind this is yet another state machine embedded within the auto-join sequence and it goes something like this.

  • Check the 6GHz scanning setting. This always comes back with the message “Scanning 6GHz channels is not enabled, skipping 6GHz channels” and as it stands today, there is nothing which I’ve found which can change this. (This might change in the future though)

  • For any saved 6GHz networks, it substitutes the 6GHz channel with the RNR channel and adds it to the scan list - this is where it originally learnt of the 6GHz channel in the first place.

  • Capture all RNR reports from the scan (which does not include the 6GHz networks - just the previously known RNR substitutes)

  • Followup scan. If one of the scanned channels has an RNR in the beacon the device will perform what it terms a “followup scan” on the 6GHz channels in those live RNRs just captured.

  • Find a match. If the followup scan succeeds and the 6GHz network is within acceptable limits (RSSI mostly) the network will be joined

As you can see in this screen capture from nOversight, the simplest transition through the state machine to scan and connect a 6GHz network completed in 880ms from Wi-Fi power on.

Ben Toner