Go To Sleep, Go To Sleep, Go To Sleep Little iPhone

In some circles, Apple Wi-Fi devices are knows to have problems with lost connections.  iPhones and iPads will unexpectedly miss incoming calls, have delays in receiving push notifications and even be forced to reauthenticate.

There is a solution to Apple devices' connection problems, and as with most "device problems", the fix resides on the infrastructure.  The DTIM setting needs to be increased.  (Apple recommends a setting of 3 or higher.)  Here's why:

Some Apple Wi-Fi connection problems stem from Apple iOS devices' use of 802.11 power management.  To understand what Apple devices are doing with power management, one must first understand how 802.11 power management works.

Let's start with unicast data.  The 802.11 standard allows devices' Wi-Fi radios to enter the Doze state in order to conserve battery life.  Wi-Fi radios in the Doze state are unable to receive data from the AP, so APs buffer all unicast data that has a destination MAC address of a device that's in the Doze state.

This works just fine on Apple iOS devices, as my seen in a capture of my iPhone 6S:

Broadcast and multicast data is different from unicast data.  APs send broadcasts and multicasts once for the entire basic service set (BSS, which means all of the devices that are connected to any single SSID on any single AP).  

The 802.11 standard handles the transmission of broadcasts and multicasts to sleeping device radios by giving devices a timer for waking up.  This timer is called the DTIM (delivery traffic indication message).  Every AP beacon indicates how much time is expected to elapse before the next DTIM.  Immediately after sending a DTIM, the AP will send all broadcasts and multicasts that have been held in the AP's buffer.  Devices have the option of waking their Wi-Fi radios in time to receive the DTIM and the broadcast & multicast data that follows.  Devices can then go back to sleep after receiving broadcasts and multicasts.

The problem, at least as Apple sees it, is that battery life is more important than broadcast/multicast latency.  Apple doesn't want iOS devices to have to wake up for every DTIM because waking requires more power than sleeping.  If an iPhone's Wi-Fi radio wakes up ten times per second, that drains more of the iPhone's battery than if the radio wakes up three times per second.

Apple has chosen to preserve battery life for iOS devices by waking up less often, but there is a cost.  If an AP sends DTIMs and empties its buffer of broadcasts & multicasts more often than an iPhone wakes up, then the iPhone will miss some broadcast and multicast traffic.  

You can see my iPhone 6S missing broadcasts & multicasts in Wireshark.  

Here's my iPhone's wake/sleep pattern:

Before my iPhone goes to sleep, it sends a Null Data frame to the AP.  Wireshark labeled this frame number 18392.  When my iPhone wakes up, it sends another Null Data frame to the AP.  The wake-up frame was labeled by Wireshark as number 18494.  (I filtered out everything except for Null Data frames for the screenshot above.)

While my iPhone was sleeping, the AP sent out a broadcast:

Notice how the broadcast is labeled by Wireshark as number 18493.  My phone indicated that it was awake with frame 18494.  So, my phone probably* missed that broadcast.

(*I say "probably" because it's impossible to tell the exact microsecond that my phone stopped sleeping.  It's possible that my phone woke up and then waited to send a Null Data frame telling the AP that it was awake.  It wouldn't make any sense for a Wi-Fi device to wait to tell the AP that it's awake, but it's possible.)

All of this is red meat to the Wi-Fi community's populace of device-blamers (of which I am most certainly not a member).  If you love blaming your bad Wi-Fi on devices, feel free to print out this blog and frame it.  The AP is explicitly telling the iPhone when DTIMs (followed by broadcasts and multicasts) will be transmitted, as seen here:

Every single Beacon with a DTIM count of 0 is a DTIM Beacon.  Every Beacon with a DTIM count of 1 is telling my iPhone that the next Beacon will be a DTIM Beacon.  The iPhone 6S surely sees all of this, but it decides to sleep through broadcasts and multicasts anyway.

I look at the iPhone's sleep patterns a different way.  I love long battery life.  (Because I think that users love long battery life.)  If Apple wants to have iPhone sleep through DTIMs -- which is permitted in the 802.11 Standard, mind you -- then I say let them do it.  We, as Wi-Fi folks, need to adjust our infrastructure to allow these iPhones to maximize battery life without missing too many broadcasts and multicasts.

If you want to minimize the likelihood of iOS devices missing broadcast and multicast data, you can raise the DTIM setting on your APs.  Apple recommends a DTIM setting of at least 3 (thanks to Andrew Von Nagy of Revolution Wi-Fi for tipping me off to that on Twitter), which would give devices the ability to sleep for up to 300 kilo-microseconds without missing and broadcast or multicast data.  Raising the DTIM setting could prevent users from experiencing missed Wi-Fi calls, repeated re-authentications and other known connection issues on Apple iOS devices.

***

If you like my blog, you can support it by shopping through my Amazon link.  You can also donate Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU 

Twitter: @Ben_SniffWiFi

ben at sniffwifi dot com