A client recently made a comment that's set me thinking. He noted that low bit-rate always-on data -- such as that from presence feeds -- tends to drain mobile handset batteries very quickly.
This is not news. But the significance is slowly dawning on me.
Firstly, a lof of wireless data technology roadmaps focus on increasing speeds. But the industry is likely to be taking a wrong fork in the road here. As Flarion discovered, and Andrew Odlyzko has long espoused, low latency is where it's at. Andrew's long-standing quip is that if you don't care about latency, the postal system and a DVD burner is a great broadband solution available everywhere today. Flarion's wireless technology is capable of sending a single bit in an efficient manner. This is a by-product of their innovative and efficient MAC (media access control) algorithm, which negotiates who gets to shout when. Flarion doesn't assume the purpose of the network is constant bitrate applications over long session.
(Another reason to be suspicious of NGNs, which are also session-centric via expensive centralised proxies, and not presence-centric via P2P connection. Relaying tiddly presence messages is going to consume a lot of expensive CPU time -- one or two orders of magnitude more than call data.)
Presence data is likely to be highly asymmetric. If you have N buddies, and you're all producing the same bit-rate of presence data, you'll have to download N times as much as you send. On the other hand, general network traffic is becoming more symmetric -- think 2-way video, P2P file distribution.
For battery-constrained devices, this suggests an opportunity for vertical integration of the radio access network, handsets and telephony software. You design handsets with some dual-form radio. Part of the radio is in an "always listening" mode, accepting presence data and other low-bitrate trickle feeds. Rather than activating the transmitter to say "sorry, I missed that bit -- could you say it again please", data could be re-transmitted over and over by the mains-powered cell tower. This helps preserve battery life. At some expense, it could even be done at a lower frequency that conserves more power and had wider reach. Kind of a Microsoft SPOT watch blended into a cell phone.
Most presence data is not so vital that a few lost bytes or a minute's delay is critical. And some form of sequence numbering can give the handset an idea it's missing a lot of data, wake up and directly request re-transmission.
This is bad news for companies like Skype who may hope to piggy-back on fast cellular networks. Yes, I've received calls from people using EV-DO and laptops; or airborne Wi-Fi and a Pocket PC. But that's not a mass-market proposition. I suspect that the limiting factor on deploying mobile Skype-like applications isn't network and handset lockdown, but battery life.
It is widely assumed that the future of telephony is purely "mobile". I'm less sure, at least in the medium term. I think that the "nomadic" or "portable" aspect will be very important -- and even fixed telephony isn't yet ready for its coup de grace. What does this mean? Well, your wired desk phone doesn't lack for electrical power. It can offering a richer presence experience -- even always-on webcam images of your cat's basket or whatever you desire. Phones which have a power dock, like your traditional cordless handset, become relatively more attractive. The device offering the worst telephony experience may indeed be your traditional mobile handset. Battery technology is somewhat stagnated as a matter of physics (you're trying to make safe, reliable things with bomb-like energy densities). Perhaps it's time for handset makers to concentrate on improving the recharging experience?
In summary, the IP abstraction is a purely functional one; it takes no account of non-functional requirements. Some of them, like QoS, turn out to be mostly bogus. But some are critital, and pure Internet VoIP solutions may not deliver. If you're a telco looking to fight disintermediation, this is one rock to look under very thoroughly.
Posted by Martin Geddes at 9:01 AMTrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/516