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


  1. Ben, do you have the source of where Andrew found the information on Apples' recommendation?


  2. Regarding the comment - "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 just wanted to clarify one thing - Data Null (PM=1) and Data Null (PM=0) should not be considered precise markers of when Phone is asleep or awake. They are really the markers for when Phone is asking the AP to start/stop buffering unicast data. A phone could very well be awake in between to receive the MCAST/BCAST traffic. A Data Null (PM=0) needs to sent only when Phone wants AP to start delivering any buffered unicast data.

    But In general , I agree with core message here which is IPhone sleeps for a longer interval to save battery at the cost of missing some of the BCAST/MCAST traffic

    1. Absolutely, Kumar. Still, I would say that it is unlikely that Apple is keeping iPhone Wi-Fi radios awake in between Null data frames. Why lose all of that battery life?

  3. So, current issues with iPhone and other iOS devices with newer versions continue. I set DTIM at 3 and phones still dropped Internet (although still connected to network and getting DHCP). Tried it all the way to 125 and connectivity is better, but will eventually drop again. There has to be a magic number where the timing between the iOS sleep and the ACK request are in sync. Anyone figured this out yet?

    1. Depending on the app you need to run, keeping iPhones connected can be more complicated than adjusting the DTIM.

  4. Wonderful blog found to be very impressive to come across such an awesome blog. I should really appreciate the blogger for the efforts they have put in to develop such an amazing content for all the curious readers who are very keen of being updated across every corner. Ultimately, this is an awesome experience for the readers. Anyways, thanks a lot and keep sharing the content in future too.

    data science institute in bangalore

  5. I am glad to discover this page. I have to thank you for the time I spent on this especially great reading !! I really liked each part and also bookmarked you for new information on your site.
    Data Science Training in Chennai

  6. Interesting post. I Have Been wondering about this issue, so thanks for posting. Pretty cool post.It 's really very nice and Useful post.Thanks
    digital marketing courses in hyderabad with placement

  7. i am glad to discover this page : i have to thank you for the time i spent on this especially great reading !! i really liked each part and also bookmarked you for new information on your site.
    artificial intelligence training in chennai

  8. Stupendous blog huge applause to the blogger and hoping you to come up with such an extraordinary content in future. Surely, this post will inspire many aspirants who are very keen in gaining the knowledge. Expecting many more contents with lot more curiosity further.

    data science course in faridabad

  9. I want to leave a little comment to support and wish you the best of luck.we wish you the best of luck in all your blogging enedevors.
    data science training in chennai

  10. Thanks for posting the best information and the blog is very important.data science course in Lucknow

  11. I am glad to discover this page. I have to thank you for the time I spent on this especially great reading !! I really liked each part and also bookmarked you for new information on your site.
    Data Science Course Syllabus

  12. Always i used to read smaller articles or reviews that also clear their motive, and that is also happening with this paragraph which I am reading here.휴게텔

  13. i always used mobile before going to sleep its more dangerous for eys weakness
    OBD2 Apps for iPhone

  14. I want to leave a little comment to support and wish you the best of luck.we wish you the best of luck in all your blogging enedevors.
    aws training in hyderabad

  15. Looking forward to reading more. Great blog post. Really Great.Mulberry silk bedding

  16. It is essential whilst you pick to shop for personal label dietary supplements which you make certain your dealer now no longer simplest offers this service, however has their very own group of expert and skilled designers available to make certain you get the very best first-rate labels.white label supplement manufacturer


Post a Comment

Popular posts from this blog

Why Are You Slowing Down My WiFi, Apple? To Make Things Better?

Why You Should Stop Disabling Low Wi-Fi Rates, Illustrated