My ideal 802.11 phone

This is an idea that’s been percolating for a while, but Dameon’s recent rant about how VoIP hardware is boring has triggered two responses.

One is that I have started explaining what I do with VoIP to the rest of the world as, “I have become my own telco.” If I want a service, I can define and implement it myself, without needing to wait for a big market to develop and catch the eye of the telco. (I did this recently to make Asterisk handle incoming telephone calls in a time-aware fashion for my international travels.)

But, more on point, I’m also excited by the proliferation of wireless LAN phones. The dual-mode phone is a way of communicating traditionally (with the cell side of the device) as well as with services that I can define myself (with the 802.11 side). Unfortunately, most of the phones on the market are hardly interesting. Here’s my “hit list” of features that you have to implement to make me pay attention:

  1. WPA(2). This shouldn’t even be hard at this point. We’ve worked out all of the kinks from these protocols, and there are multiple open-source implementations. There is no excuse for bringing any wireless LAN device to market that doesn’t support good security in 2007.
  2. WMM. Last year at Interop, I was able to demonstrate that WMM can give you voice quality, even with significant background traffic. There are plenty of reference designs from hardware vendors that do WMM. Selecting only WMM phones drops you to just eight Wi-Fi Certified devices.
  3. PMK caching. This is an under-appreciated feature that was part of the 802.11i amendment. It’s a way of saving master keys to cut down on roaming times. Combined with the “opportunistic” version that establishes master keys on APs before it’s needed, you can get some impressive handoff times between APs, and you’re hard pressed to hear a difference.
  4. U-APSD. This is an acronym for Unscheduled Automatic Power Save Delivery. Anybody who’s used an early 802.11 phone has undoubtedly noticed that the battery life is, to put it nicely, awful. U-APSD works keep the 802.11 radio powered down when it’s not used, so that almost all of the 802.11 radio (and power) usage is devoted to transmitting voice. Anecdotally, it can extend battery life by 50-100%, but there are so few implementations I can’t speak from a wealth of data.

Naturally, even after you get to the end of this list, there’s a lot more that can be done, but it’s relatively small potatoes compared to the big four. There are some further quality of service parameters that can be used to help an 802.11 phone in a big network select the right AP to go to, and there are some features that help further smooth out handoffs. To be honest, there are so few phones that can get to #2 on the list that I’m not worried about writing up #5 through #10.

One Response to “My ideal 802.11 phone”

  1. […] On February 12, I went to check up on the status of the OpenMoko project. With my likely disappointment on the iPhone, I’ve been looking for a replacement for my aging four-year-old Nokia 6600. Based on my set of ideal features for an 802.11 phone, I’ve been looking seriously at the Nokia E series, but they are quite expensive. The recent announcement of the “i” models in the E series lineup (E61i, etc) has shifted my allegiance slightly. I’ve been working with an E series, but it has limited battery life and a flaky SIP stack. My thoughts increasingly turn towards OpenMoko, since it would embrace SIP and open telephony in a way that is still alien to the telcos and their big suppliers. Unfortunately, the project has been delayed a short while. There are good reasons for this, namely that the team is dedicated to having a completely open system from hardware specs up through the toolchain before finally getting to the phone software itself. All commendable, but it doesn’t make it sting any less. […]

Leave a Reply