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 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.

RNR reports are in the beacons and nOversight extracts them from the scan log. As can be seen, the beacon on each channel of a multi-channel SSID will have an RNR.

It is worth noting that in this case there is only 1 known network so there is no deprioritization and the standalone 6GHz network is selected.

Had there been a 6GHz network whch also had a counterpart (same SSID on a different channel), that network would have been selected according to normal selection rules and no deprioritization would occur.

Wait, What… 6GHz Deprioritization?

If there is no deprioritization when there is only 1 known network, what happens in the alternative cases?

Firtly, remember - this is next part is about standalone 6GHz networks which are NOT recommended by Apple.

The test case here is to save a standalone 6GHz network and a 5GHz network and capture the state machine after power cycling the Wi-Fi radio.

What you see is that it scans optimised channels including the RNR substitute for the saved 6GHz network. It needs to find a live RNR on one of those channels to proceed to scan the standalone 6GHz channels.

If the standalone 6GHz network s scanned and is the most favourable (in this case it has the highest RSSI), all 6GHz networks are deprioritized and the scan process starts again but uses the cache as much as it can. 

And what about the alternative cases?

Case 1: A suitable non-6GHz alternative. If, when excluding the 6GHz networks, there is a suitable alternative which the device can connect to - it is selected for connection and that is that.

Case 2: No suitable non-6GHz alternative, standalone 6GHz is the best choice. If there is no good alternative, it returns to the primary auto-join state machine and continues through the process until it gets to the standalone 6GHz state. If it gets there (meaning there was no captive network available), it will consider the standalone 6GHz network and if it meets the required criteria (e.g. RSSI) then it will connect. So yes, it does seem that a captive network on 5GHz will be higher priority than a standalone 6GHz network. This is an area for more testing.

Case 3: No suitable non-6GHz alternative and the standalone 6GHz network is now degraded. In this case the state machine will fail to join at the standalone 6GHz state and transition to the Low RSSI Networks state. It seems like the logic would be to accept a lower RSSI network as a last resort however I have never seen a connection happen from this state. So this is another  topic for future research.

This is what it looks like if the LOW RSSI state is entered - we know that -88dBm RSSI is not good enough to connect, even in this state.

So that is what we know so far.

It seems like the general rule to get your 6GHz network connected are as follows

• As mentioned in previous blogs, use the same SSID on another band and ensure RNR reports are available
• If you must provide a standalone 6GHz network
  
  
  • Ensure you have a network providing an RNR report for your standalone 6GHz network. Note: There are changes between iPadOS 16.1 and 16.2 beta which seem to be changing the logic here so we are looking at this carefully.
  • Do not have other non-6GHz SSIDs available which are suitable for connection otherwise standalone 6GHz networks will be deprioritised and not connected
  • Do not have non-6GHz captive networks available as they are also higher priority
  • Ensure your 6GHz power is suitably high (nominally better than -70dBm)

When setting up your network, you can easily check if you have it right by using nOversight to check how an iPad scans and connects. You can do this live by connecting your iPad to a Mac and allowing nOversight to consume the logs in real time as you walk around (carrying both). You can also just take the iPad out and test and when finished, capture the sysdiagnose log and share it with nOversight. The easiest way to guide through that process is to download the nOversight app onto your iPad from the App Store.

I hope you have found this useful and I look forward to hearing people’s own experiences. This is a first look at the Wi-Fi 6E related logs of the new iPad and no doubt there is still a lot to learn and watch as Apple make future updates.