« Telecom Italia's Plans To Upgrades Wireless Backhaul | Main | HSPA+ Background Information »

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451c34f69e200e5518016188833

Listed below are links to weblogs that reference Why IPv6 Will Be Good For Mobile Battery Life:

Comments

PierreL

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...

Martin

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

Mike

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.

PierreL

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.

Tsahi Levent-Levi

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.

Martin

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

The comments to this entry are closed.

My Photo

The Books to this Blog

My Pictures on Flickr

  • www.flickr.com
    martin.sauter's photos More of martin.sauter's photos

Android Cell Logger App

Misc

  • Clicky
    Clicky Web Analytics