Increase iPhones’ battery life by removing unnecessary IPv6 multicast Router Advertisements

I came across a new RFC 7772: “Reducing Energy Consumption of Router Advertisements”. I want to share my learnings after reading this RFC.

Internet Engineering Task Force (IETF) Logo, captured on Wikipedia.

I intentionally mentioned “iPhone” at the subject to have your attention. Actually, the whole discussion applies to any mobile devices with limited battery capacity, such as smart phones and tablet computers.

It is quite obvious mobile devices will consume more power while awake than asleep. The question is how serious this problem is?



The problem

Although the authors of this RFC did not mention how they got these numbers, I believe the numbers must be typical and derived from actual lab measurements.

While asleep, a mobile device would consume 5 mA of current. While awake, it would consume 40 times more on the other hand. That is 200 mA.

A single Router Advertisement (RA) will wake up the target mobile device. A single multicast RA to all hosts will wake up ALL the mobile devices attached to the same subnet.

Remember, the power capacity of mobile devices are so limited. The more power consumption we can save, the more battery time we will have for every mobile devices attached to the same IPv6 subnet.


Reasonable RA frequency: 7 RAs per hour

Here I want to emphasize on the word “reasonable”. To keep IPv6 working, we do need RAs to push and refresh network information to mobile devices. If nothing changed at the network, why keep sending so many unnecessary RAs just to wake mobile devices up and waste battery capacity?

Here is a reasonable goal: 2% of idle power consumption.

Assume we want to achieve the goal: we do not want RAs to consume more than 2% of idle (sleeping) power consumption of every mobile device. After some calculations, we know the reasonable frequency for RAs is no more than 7 RAs per hour.


Here is the calculation.

A typical wakeup high power consumption surge mentioned in this RFC would last for 250 ms. That is, the wakeup power consumption is triggered by single RA is:

{The battery capacity consumed for single RA wakeup in mAH} = 200 mA x 250ms/1 hour = 200 x 250/3,600,000 = 0.0138888… ~= 0.014 mAH.

To calculate the idle (asleep) power consumption, I assume the device keeps asleep for the whole hour. This is the total budget for me to meet.

{2% of idle (asleep) power consumption of battery capacity for an hour in mAH} = 2% x 5mA x 1 Hour = 0.02x5x1 mAH = 0.1 mAH.

{Reasonable number of wakeups without exceeding the budget} = 0.1 / 0.014 ~= 7


I have to be honest I did not expect this number to be this small. The default IPv6 RA interval is 200 seconds on Cisco IOS routers. That is equivalent to 18 RAs per hour. I believe configuring the interval to roughly 600 seconds would be a better idea.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-book/ipv6-i3.html#wp3911380069

The default interval between IPv6 RA transmissions is 200 seconds.

Note: the lifetime of each RA should be 5 to 10 times of this interval. This is also mentioned in this RFC as roughly 45~90 minutes.


Recommendations at network side

I will just focus on the network side.

To implement the recommendations of Section 5.1.1 and 5.1.2 of this RFC, I found one interesting command on Cisco’s web site.

The command is:

interface E0/0
 ipv6 nd ra solicited unicast

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-book/ipv6-i3.html#wp5031733970

Large networks with a high concentration of mobile devices might experience like battery depletion, when solicited Router Advertisement messages are multicast . Use the ipv6 nd ra solicited unicast to unicast solicited Router Advertisement messages extend battery life of mobile device in the network.

Most of the IPv6 end devices could send out Router Solicitation even when their own link-local addresses are not determined yet. In that case, the replying RAs to such Router Solicitations would become destined to multicast address of all hosts. After enabling this feature, the router would ignore all such Router Solicitations. End devices can still get their global IPv6 prefix because after determination of their own link-local addresses, they can send out RS again and at this moment the router will respond to them because these RSs are sourced with unicast addresses.

For stable network, we should keep the RA interval as large as possible to save more power on mobile devices. Here is a sample configuration on Cisco IOS Routers.

interface ethernet 0/0
  ipv6 nd ra interval 600
  ipv6 nd ra lifetime 2700

Here I use 45 minutes (2700 seconds) as a reasonable RA lifetime.

We should consider increasing the frequency ONLY when we are changing network topology or renumbering address. For most of the time, we should keep below 7 RAs per hour as reasonable configuration.

Zhuifen Station (追分車站) (Google Maps). Taichung City, Taiwan.

One more thing…

Increasing RA frequency indeed helps to push network changes much faster to all end devices. For devices without battery capacity concerns such as desktop computers, this advantage would outweigh the power consumption.

My personal suggestion is we should put limited battery capacity mobile devices in separate IPv6 subnets, and enable only to such subnets with the recommendations discussed in this post.