iPhone 6 Roaming Behavior and Optimization
Available Languages
Contents
iPhone 6 Roaming Behavior and Optimization
Executive and Recommendations Summary
IOS 8 devices try to roam when their associated BSSID signal falls below –70 dBm RSSI. The IOS 8 devices then scan all channels (without 802.11k) or the target channels communicated by their current AP (with 802.11k enabled), and roam to another AP if its signal is 8 dB better (IOS 8 device in active communication) or 12 dB better (IOS 8 device in idle) than the current AP.
Roaming performances are critical for VoWifi and business-critical real-time business applications. Efficient roaming time is 50 ms. Without 802.11k enabled, dual-band SSIDs, and standard AP density, the total loss of connection for an IOS 8 device can reach 5 seconds for each roam. With 802.11k enabled, higher AP density (AP every 2500 sqft or every 240 sqm), and network designed with 5 GHz, the roaming performances can reach sub-second.
When designing wireless networks for real-time application performances, plan for 5 Mbps per user and 12 – 14 users per AP. Make 5 GHz and 802.11k as part of your design criteria for mobile devices.
Context
Mid November 2014, Apple support published a reference document explaining how IOS8-based devices roam (http://support.apple.com/en-us/HT6463). This blog entry is based on this reference document, but with added lab + real network measurements (to distinguish good intents from practical behaviors in real world).
The roaming behavior is similar for iPhone 6, iPhone 6 plus, iPhone 5c, iPhone 5s, iPad Air, and iPad mini with retina. The probing behavior also depends on the chipset used in the phone. You will see general behavior parameters determined by the OS, but also small timer variations between models determined by the chipset and its driver. For example, does the phone probe once or several times per “probe burst”, how many milliseconds between the probe requests in a given burst, and so on. This document focuses on the general behavior, but the timers shown were measured on iPhone 6, using a Broadcom BCM4339 chipset. The behavior was tested on IOS 8.1.
How Often Does My iPhone 6 Scan?
When you are NOT associated to any SSID, and your screen is off (for example, your phone is in your pocket), your phone will check the surroundings at regular intervals for SSID by sending probe requests. The phone will scan more often if you move (that is, the signal from APs vary, see the When Does My iPhone Roam? section, as the behavior is similar). So let us assume the worst case scenario, you are not moving.
If your cellular data is unavailable and Location (Settings > Privacy > Location Services) is disabled, your phone alternatively uses its real MAC address and a locally administered address. The idea is to temporarily hide your real MAC address for privacy purposes. In that case, the phone sends a burst of probe requests with the real MAC address. The phone then stays silent for a “random interval” (in the order of 140 seconds), before sending between one and six probes with a locally administered address, at 135 or 270 second interval. The phone then stays silent for another random interval (up to 10 minutes) before going back to the real MAC address and restarting the cycle. The phone picks a new locally administered address when switching between real and locally administered addresses.
An example of the behavior is illustrated in the following figure. The horizontal axis represents the capture time in second (capture was taken over 8.5 hours, or 30 K seconds). The vertical axis represents the interval between two consecutive probe requests. The blue values are probes using the real MAC address, and the red values represent probes using a locally administered address. For example, at 5000 second, 322 seconds after the last probe request using a locally administered address, the phone sends a probe request using the real MAC address (blue dot at [5000,322]). After 20 milliseconds, the phone sends a second probe using the real MAC address (point that seems to be at [5000,0], but is in fact at [5000.02, 322.02]). The phone then stays silent for 135 seconds before sending a probe using a locally administered address. The phone then sends two more probes at 135 seconds interval, then two more probes at 270 seconds interval, and stays silent for 204 seconds before sending a probe with the real MAC address.
Notice that some capture and collision artifacts wrongly show locally administered address probes at large intervals (beyond 270 seconds).
The locally administered address is not used anymore as soon as you associate to a WLAN or if cellular data or Location are enabled. In these cases, the phone will scan your target SSID at 90 seconds interval (or the broadcast, if you are not associated), in a form of "maintenance mode". This supposes that the AP signal is stable and screen is off (for example, your phone is in your pocket while you sit at the shopping mall food court).
If you start using your phone (actively using the Wi-Fi connection), the phone stops probing, as it uses the AP beacon messages and data frames to assess the AP signal level. The iPhone 6 (with the BCM chipset) still sends a 'reflex probe" to your SSID every 30 minutes. Other models may have a slightly different behavior. The IOS 8 component does not ask the phone to probe.
When Does My iPhone Roam?
The iPhone 6 does not use the accelerometer to determine that you are moving, and the AP signal needs to be checked. It relies solely on the AP signals to the phone to determine if roaming is needed. The threshold is –70 dBm. This means that as long as the AP signal (beacons and data frames) is stronger than –70 dBm, the phone does not try to scan more actively or roam.
As soon as the AP RSSI, as read by the phone driver, falls below –70 dBm for more than one second, the phone decides that the current AP is unusable and decides to roam, which triggers scanning.
At this point, several possibilities exist:
You configured your network to use 802.11k. This feature allows the AP to send a list of neighboring APs to the phone upon request. In that case, the phone checks the best six APs, and scans their channels.
For example, your current AP is on channel 36, and the reported APs are on channels 40 (–68 dBm), 44 (–76 dBm), 48 (–72 dBm), 52 (–78 dBm), 56 (–59 dBm), 60 (–75 dBm), 149 (–74 dBm), 153 (–70 dBm), 157 (–71 dBm) and 161 (–63 dBm). The phone finds that the best six APs are on channels 40, 48, 56, 153, 157 and 161, and sends probe requests for the target SSID to these channels.
Be careful, these signals are reported as heard by the AP, not as heard by the phone. Also, the iPhone 6 asks for the list of neighbor APs when entering the cell (right after association), not when roaming. So, the list may not be the latest (see the Impact on Your Design section about design recommendations).
You did NOT configure your network to use 802.11k. In this case, the phone scans all channels (this can be 11 or 13 channels in 2.4 GHz, and up to 13 channels in 5 GHz). The phone scans UNII1, UNII2, and UNII3. The phone can also check UNII2-e, but only passively. The phone scans UNII2-e every 6 scanning cycle. This is because this band is protected by 802.11h, and the phone has to listen passively (no active scanning) until it hears an AP. So, detecting APs in UNII2-e can take more than a minute. Even scanning the other channels takes time. Expect several seconds for this process. It takes of course longer if the phone is actively communicating on the AP current channel, because the phone has to find an interval where no data is expected to jump to the target channel to scan. If the phone is not communicating, scanning is faster.
In both cases 1 and 2, the phone scans and looks for a better AP to jump to. Notice that the phone does not try to stay in the same band, it can jump from 2.4 GHz to 5 GHz or vice versa, even on the same AP. The roaming algorithm compares the BSSIDs that were detected (that is, the unique MAC address of each radio offering the target SSID name) to the current AP BSSID signal level. Then, the roaming decision depends on if you are actively using the Wi-Fi network (traffic to and from the phone) or not (phone is idle or screen off, in your pocket). If you are not using the Wi-Fi connection, the phone will only jump if another AP offers a signal really better than the current one. It needs to be at least 12 dB better. If the new AP signal is at least that much better, your phone roams. If no detected radio has a signal 12 dB or more better than your current AP, the phone stays on the current AP, but keeps scanning at 90 second intervals until it finds a better BSSID (12 dB better than the current AP BSSID) or until the current AP signal gets back above -70 dBm.
If you are using the Wi-Fi connection, things are more pressing. The phone determined that –70 dBm was a poor signal and is ready to jump earlier. It will roam to a new radio if the BSSID is 8 dB or more better than the current AP. For example, if your AP radio signal dropped is to –72 dBm, and the phone detects BSSIDs for the same SSID name at - 61 dBm, -63 dBm and -69 dBm. In case if you are actively using the Wi-Fi, the phone accepts to roam to the BSSID at –61 dBm and to the BSSID at –63 dBm. Because, they are 8 dB or more better than the current AP (11 dB and 9 dB better respectively). The phone does not roam to the BSSID at –69 dBm, because it is only 3 dB better than the current AP. Having two choices, the phone chooses the BSSID with best signal, and roams to the BSSID at –61 dBm.
If no BSSID is detected at 8 dB better than the current AP, the phone stays on the current AP, but keeps scanning at 90 seconds intervals (one probe request followed by a second probe request 10 millisecond later) until it finds a better BSSID (12 dB better than the current AP BSSID) or until the current AP signal gets back above –70 dBm. The following graph shows this behavior with an iPhone 6 on an active Wi-Fi connection, maintained far from its AP (signal at around –75 dBm) without alternate AP to jump to.
Impact on Your Design
This IOS 8 probing and roaming behavior has several important influence on your wireless network design.
Enabling 802.11k
Roaming with an IOS 8 device is more efficient if you implement 802.11k than if you do not implement 802.11k. This is because the scanning time is shorter with 802.11k. In the following example, an iPhone was moved back and forth between two APs. The APs were far enough from each other that the iPhone would cross the –70 dBm edge while moving from one AP to the other.
Both APs had the same SSID enabled, available on both 2.4 GHz and 5 GHz. Power was set to 3 on 5 GHz, and 5 on 2.4 GHz, making the 2.4 GHz cell about only 30% larger than the 5 GHz cell.
Without 802.11k enabled, roaming times are long. Moving back and forth three times between APs show multiple roams (more than the expected six roams). This is because the iPhone jumps from 5 GHz to 2.4 Ghz, then back to 5 when getting close to the next AP. The average roaming time (time between the last packet acknowledged to or from the phone on one AP and the first packet to or from the phone on the next AP) was close to 5 seconds. This means, on average, your phone loses its connection (no communication) for close to 5 seconds when roaming.
With 802.11k enabled, the average roaming time is down to about 1 second. These performances can be increased to reach sub-second with the recommendations below.
Configuring the Band
Enabling 802.11k increases roaming efficiency, but does NOT limit the iPhone to one band. By default, 802.11k provides information about neighboring APs only on the client band. In other words, if your iPhone is associated to the BSSID on 5 GHz, the AP will provide information about neighboring APs in the 5 GHz band, not in the 2.4 GHz band. But this does not mean that the iPhone will stay on the 5 GHz band.
When an SSID is available on both bands at "good signal level" (more than -70 dBm RSSI), the iPhone will associate in priority to the 5 GHz radio. However, at equal AP power, at any point of the cell, the 2.4 GHz signal is commonly about 7 dB higher than the 5 GHz signal. This variation is due to common mechanical differences in antenna characteristics for each band, and equally affects most clients. It is not due to the access point.
The result is that when the iPhone is associated to the 5 GHz radio, it moves away and reaches the –70 dBm boundary for 5 GHz, the signal from the same AP in 2.4 GHz is commonly detected as –63 dBm. This is a theoretical difference. In real field deployments, the measurement accuracy is typically 4 dB. This means, if the AP signal is –63 dBm, the client will report a signal that can be anything between –67 dBm and –59 dBm, depending on the client exact position in space and RF variations.
When it associates to the access point, at regular intervals during the connection, the phone requests a list of neighboring APs from the AP, using 802.11k action frames. As the phone is associated to 5 GHz, the AP only provides neighbor BSSIDs in 5 GHz. When the iPhone reaches the –70 dBm boundary on 5 GHz, it uses the 802.11k neighbor list to only scan the 5 GHz channels mentioned in the list. However, the iPhone also scans 2.4 GHz, without a list to work from. Two cases can occur:
The phone finds a neighboring BSSID on 5 GHz at good signal level (8 dB better than the previous AP if the phone is actively communicating), and possibly a neighboring AP on 2.4 GHz at good signal level. In that case, the phone roams to the BSSID on 5 GHz (the phone prefers 5 GHz when offered the choice).
The phone finds a neighboring BSSID on 5 GHz, but its signal is not 8 dB better than the current AP (because the overlap between cells is small, or because the phone reports a lower signal because of detection imprecision). The phone also finds a neighboring BSSID on 2.4 GHz. Because of the combination of "signal typically 7 dB higher in 2.4 GHz", and "4 dB signal measurement imprecision", the phone is likely to see the 2.4 GHz BSSID as a better candidate than the 5 GHz BSSID, causing the phone to roam from 5 GHz to 2.4 GHz. When moving closer to the next AP, during the next scan cycle, the phone may see the 5 GHz BSSID as "good", and jump back to the preferred band, 5 GHz. This phenomenon generates additional roams with potential communication disruptions.
The recommendation is to limit the SSID to 5 GHz if possible. When doing so, make sure that the overlap between your cells allows for good roaming conditions from the phone perspective. This means, at the point where the first AP signal reaches –70 dBm, the next AP signal should be –62 dBm or better. This results in designing your cell edge at about –66 dBm or better. Setting your cell edge at better signal allows for better performances. This prevents the 4 dB measurement imprecision to result in conditions where the phone reaches what it detects as the –70 dBm edge, in a location where the phone does not detect the next AP at –62 dBm yet.
If your design implies enabling the SSID on both the 2.4 GHz and 5 GHz radios, enable the 'dual band' option of 802.11k, thus allowing the AP to report neighboring AP both in 2.4 GHz and 5 GHz. This helps the phone to speed up its next AP discovery time. However, keep in mind that this process will result in more frequent roams, as the phone is likely to roam from 5 GHz to 2.4 GHz first, then back to 5 GHz as the iPhone moves closer to the next AP.
If your design implies enabling the SSID on both the 2.4 GHz and 5 GHz radios, 802.11k is enabled, and if the overlap between the 5 GHz cells is satisfactory (cell at –66 dBm or better, no coverage gaps between cells), enable BandSelect. This feature allows the APs to delay their responses in 2.4 GHz, thus allowing more time for the phone to detect the SSID in 5 GHz and roam, before receiving a reply in 2.4 GHz.
Tuning Your Network Design for IOS 8 Roaming Performances
Designing your network to offer optimal roaming conditions to IOS 8 devices implies creating several conditions:
Design your network for 802.11a. Set the SSID to 802.11a-only, and enable 802.11k to optimize next AP discovery time.
Create RF conditions that match the IOS 8 device logic. When your device gets to a point in the cell where the AP signal falls below –70 dBm, the next AP should be heard at –62 dBm or better. This implies deploying a high performance network, with one AP for every 2500 sqft (250 sqm) area on average. The AP power should be set to a value comparable to IOS 8 devices average power for the 5 GHz band. A good value is 10 to 11 dBm for networks targeted at phones (tablets have higher transmit power capabilities), or power level 3 for the A regulatory domain. The IOS 8 roaming logic implies creating a cell edge at higher level than usual VoWiFI recommendations.
As much as possible, try to design roaming paths that are efficient. In the following example, APs are positioned strategically to take advantage of the environment and build AP neighborhood based on the roaming path. When the iPhone 6 moves from position A to position B, APs 1 and 2 can be heard. However, AP A does not hear AP 3. As a consequence, when the iPhone 6 requests a list of neighbors from AP 1, AP 1 provides AP 2 information, but not AP 3. This allows the iPhone 6 to only get a limited list of channels to scan, and to discover AP 2 easily. These conditions cannot always be created, but try to design your network so that the IOS 8 device always learn from its current AP the channel of the next AP users are likely to associate to while roaming. If possible, limit the number of APs that can be heard from each AP, so that each AP “802.11k neighborhood” only contains APs that are on the roaming path.
By creating these conditions, you can considerably decrease the roaming time of an IOS 8 device. In the following example, APs were placed as per the example above, and the iPhone 6 was moved from the upper left corner (position A) to the bottom right corner of the corridor, and back. The roaming times are around 50 milliseconds (counted as delay from the last frame from the iPhone 6 on one channel, to the first frame from the iPhone 6 on the next channel, after scanning and reassociation to the next AP).
50 milliseconds roaming times are compatible with real time applications.
However, this example network was built with IOS 8 roaming in mind. Unless you are deploying a new network, you may not be able to design these ideal conditions. In all cases, keep in mind that the IOS 8 roaming algorithm logic may be summarized as follows: "associate to 5 GHz if you can. Stay there until the signal gets bad, and then move to another BSSID if it is really better". This type of algorithm, commonly categorized as "generation 2" (partly sticky), is typically designed for non-real-time applications, with a roaming frequency expected to be low. It is not designed for real-time applications and frequent roaming. Building your cell design as recommended above will help to improve the roaming performances. However, these performances are unlikely to equate those of devices implementing generation 3 to generation 5 roaming algorithms, unless you can follow strictly the recommendations above. Do not recommend to your customers to use IOS 8 for business-critical real-time applications if frequent roaming is expected, and if the network was not optimized specifically to offer efficient roaming performances.
Copyright © 2014, Cisco Systems, Inc. All rights reserved.
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)