Friday, April 20, 2007

N95 with SIP


There has been a flurry of articles about Nokia’s new N95 unit and the subsequent removal of the SIP client by operators supporting the device.

Then finally, as if through devines intervention, word is out that there is a work-around to this tragedy. See the article titled “VoIP Resurrected on the Nokia N95”).

All this leads one to wonder, is it all that surprising? Is it surprising that an operator who supports and likely subsidizes the device isn’t that excited to have a client which can be used to bypass their core service? And just as bizarre, did operators really think they could keep SIP off the N95?

But I think the real interesting story has yet to be written.

The follow on story I’m interested to read is the results of all this fervor 6 months from now. How much use does that SIP client actually receive? Do consumers really want/use two services on their phones?

Presumably some number of these subscribers will hack their N95s and load up a shiny new SIP client. Now subscribers will be able to place SIP/VoIP calls when on Wi-Fi. Fantastic! At this point, the device does not support UMA, so those calls will drop when the user walks out the door of the home/office. Excellent.

As an additional benefit, the Wi-Fi radio will have to be turned on manually and the user will have to start/launch the SIP client. I can’t comment on whether the SIP client can access the phone’s existing address book, I would hope so, but it’s not clear yet.

The final advantage is that when in Wi-Fi, the GSM/3G radio needs to stay on (or calls to your GSM number go to voicemail). Excellent, both Wi-Fi and 3G (or GSM) radios drawing power. Don’t walk too far from a power source.

Is this really what users want? Do they want two services on a phone (SIP/VoIP and standard 3G/GSM) with two phone numbers? Do they want Wi-Fi to be something they need to consciously enable to use, or do they want the phone to stay always best connected?

So perhaps we can set up a follow-on article. We can talk to N95 users and see how much use that SIP client receives. Or how often Wi-Fi actually gets turned on, or how the performance is impacted by having two radios on simultaneously?

It’s unfortunate the N95 doesn’t support UMA (yet?!?!), it could really take advantage of Wi-Fi in a way that’s useful for consumers and operators alike.

UMA-enabled Femtocells?

A common question I get is “when femtocells arrive, won’t they displace UMA?” First off, what is generally meant by this is not ‘...displace UMA’ but more accurately ‘...displace dual-mode handset services.’ UMA, as we all know, is a generic IP access technology that can be used to implement a dual-mode handset (DMH) service with cellular/Wi-Fi phones but it’s not actually tied specifically to Wi-Fi.

However, as a generic IP access technology for mobile services, UMA actually plays a key role in a mass-market femtocell solution.

As the operators begin to plan for a robust deployment with hundreds of thousands of femtocell access points into the network, some stringent requirements have emerged:

- An industry recognized, well defined standard such than any femto AP can be interoperable with any core network controller

- “Internet grade” security to run over the public broadband network

- A high-capacity, scalable controller to support thousands of concurrent connections

- The ability to support “consumer” behaviors of unplugging access points, moving access points, plugging in access points where they don’t belong (different countries)

- A protocol which supports a retail femtocell distribution model such that each AP is “standard” out of the box and can self-configure/attach to the network

- And it goes without saying: cost-effective core network controller solution that will not throw the business case out of whack.

Initially, many suppliers jumped to the conclusion that the existing protocol (known as “Iu-B”) which runs between the radios (or “node-b”) and the controller (or RNC) in a macro UMTS network would be sufficient.

But after digging in a bit, it’s pretty well understood that Iu-b was designed to meet a different set of deployment requirements. Iu-b was architected to support a handful of extremely high capacity radio connected over private, secure, managed links.

This is nearly the exact opposite of a femtocell deployment, with many thousands of low capacity (in terms of concurrent calls) radios, all connected over un-managed and un-secured IP networks.

UMA however, was designed for just such a deployment scenario. UMA offers a well defined, robust protocol with a secure connection to the mobile core. In a DMH deployment, UMA supports hundreds of thousands of devices with relatively low concurrent capacity, quite similar to the femtocell usage model. As a well defined standard, femtocell technology suppliers such as UbiquiSys and others can develop UMA-enabled products which interoperate with UMA controllers from Motorola, Nokia, Ericsson and Alcatel.

As operators begin to leverage the public internet and broadband IP to deliver mobile services, UMA will be used for more applications beyond DHM and femtocells. UMA is truly becoming the ‘Universal’ Mobile Access protocol.