The other day I ran a post on the behavior of the SIP VoIP implementation of my Nokia N95 and that I was quite surprised to see it sending keep-alives to the network every 30 seconds. While this is normal and necessary to keep the NAT firewall open, it does have an impact on battery life, especially if a cellular network is used for the connection. The impact of such keep-alives is also considerable on the network once the number of devices using such always-on applications rise. Each cell usually serves 2000 devices at a time. Now imagine 2000 devices sending a keep-alive every 30 seconds via the same cell…
Bob Hinden of Nokia recently gave a presentation on the issue at the recent Google IPv6 conference and you can find the video of his presentation on YouTube. He made two interesting points for me here:
- With IPv4 and NAT, it’s not only SIP VoIP that sends keep-alives but also push eMail clients, VPN and Instant Messengers. So he’s right, the problem gets even worse.
- With IPv6 the NAT problem goes away as there are plenty of addresses and NAT is no longer required. Hence, IPv6 capable always-on applications can live without the keep-alives and ‘silence returns’ to the idle time.
Good points! Until we arrive at this state, however, it’s not even a good idea in most scenarios to use a public IPv4 address while you are mobile. Take a look at this blog post I wrote some time ago on how peer to peer applications of others drain my battery because of IPv4 address reassignments. I don’t know a lot about IPv6 yet but this should not happen with IPv6 anymore because I will not be assigned an IP address that was previously used by someone else!? Comments as always welcome.
P.S. Thanks to afr who made me aware of the video in Jaiku who heard it from Constantine 🙂
Interesting…
I’m not sure this periodic polling has any usefulness in a 3GPP network, in which the IP address and NATing is managed by the GGSN.
However, when at home, I would rather keep my NAT active – as a way to filter the thousands of TCP Syn attempts I receive every day…
Hello Pierre,
Good points!
I guess that requires a client that checks whether a NAT is in place (that’s what STUN does at the beginning anyway) and acts accordingly. It will be interesting to see if IPv6 has the same issue with TCP Syn requests as IPv4, which, I think, are mostly form p2p clients (see the following link: http://mobilesociety.typepad.com/mobile_life/2007/05/how_file_sharin.html). With IPv6, you should always have the same IP address, hence, fewer TCP Syn requests.
Cheers,
Martin
Its great that IPV6 doesn’t effect battery life of mobile phones.But still depends on the mobile you are using because Nokia handsets have normally very good battery back up.
I did many detailed analysis on the TCP Syn that arrive on my home ADSL box (which has
a permanent IP address).
Very shortly said, here is what typically happens:
– I receive 20000 attempts during a 40h test
– 95% of the attempts are issued from the same IP class B plan as mine
– more than 60% are sent over the well known Windows networking TCP ports (135;
139 and 445)
I suspect this to result from the numerous infected PC spread all over the
world…
I don’t see why this should be different with IPv6. The notion of port is still
there, and the address space – although being much larger – is also segmented.
I don’t think this is enough to reduce the drain on the battery. I can envision a world of IPv6 where NATs are still there simply for protection purposes.
Talking to some handset vendors, I understood that the main issue is having the IP stack active at all times, listening to the network. As these stacks usually reside on the application side (not implemented on the modem level), they are eating a lot of CPU cycles on each and every packet running around.
You should also take into account presence notification from buddies (and then the question how many buddies you have becomes an issue).
I think it’s a matter of time – once processors become optimized for battery life (which is the case nowadays) and software stack design will take IP into consideration on the modem level – it will be a solved issue. It has nothing to do with IPv4/IPv6.
Hi Tsahi,
Thanks for your comment! Excellent blog on your side, I’ve added it to my list of blogs to read.
Concerning the IP stack activity it seems to me this is not much of a problem anymore today. I use the Nokia N95 SIP VoIP client over Wifi usually around the clock even though the phone constantly interacts with the STUN server and the SIP Proxy to keep the UDP ports open the battery easily lasts a full day. I haven’t checked what the maximum time would be as I recharge the phone at night per default anyway. So I think the main issue both on the device and on the 4G cellular network side will be the frequent active state of the mobile. If all mobiles are connected all the time and transmit/receive packets there are many contexts to be administered in the base stations and lots of signaling messages for bandwidth assignments etc. are flying around for nothing.
Cheers,
Martin