Nokia Drops VoIP Support from new N Series?

As reported at GigaOm this weekend, apparently Nokia has dropped support for its VoIP applications on some new N series products going forward.

What appears to have happened is that some, but not all, of Nokia’s embedded SIP/VoIP stack has been removed. Some view this as an opportunity for more third party VoIP developers to jump in and innovate. Others view this as Nokia capitulating to the demands of mobile operators who see third-party VoIP apps cannibalizing high-margin international voice traffic.

Regardless, it re-opens the discussion about Nokia supporting a UMA client in the N and potentially E series devices. Nokia is the largest supplier of Wi-Fi-enabled devices today, and the lack of support for UMA in their N series products continues to be puzzling.

Capabilities such as ‘internet offload’, a dynamic routing capability in the handset which sends (for example) GSM voice traffic through the UMA tunnel but routes third party SIP/VoIP traffic directly to the internet, make it even easier for Nokia to support UMA and SIP/VoIP concurrently.

RAN Gateway wins again

I have spent some time considering the pros and cons of the new 3GPP HNB femtocell architecture. It’s too early to call it a standard, but for now, the basic building blocks are in place for putting the spec together.

One of the fundamental building blocks of the HNB effort is a ‘RAN Gateway’ style architecture. In this case, the RAN gateway network element sits ‘parallel’ to an RNC or BSC, and connects into the mobile core network via existing, well defined circuit interfaces (Iu-CS) and packet interfaces (Iu-PS).

Operators evaluating femtocells and femto architectures immediately grasped the benefits of using a RAN gateway approach:

• All existing circuit and packet services are supported through the femtocell access network as they are supported through the macro RAN network. This is because the RAN gateway uses the same service interfaces as the RNC.
• A ‘RAN’ gateway is located in the RAN, with a clear demark point into the mobile core network. For operators, they did not need to change the MSC or the service core in any dramatic fashion.

For all the rhetoric and posturing around the benefits of SIP and IMS, operators quickly understood that the most pragmatic approach for femtocell service delivery was through a RAN gateway architecture. In fact, one of the things that the proposals from Huawei, NSN, Alcatel/Lucent and Kineto/NEC/Motorola (ie UMA/GAN) all had in common was a RAN gateway.

From a UMA perspective, one important outcome of the HNB specification is a validation of the RAN gateway architecture operators and vendors alike.

UMA/GAN is, of course, the original RAN gateway architecture.

I harken back to the early days of dual-mode handsets (DMH). The debate raged: IMS/SIP/VCC vs UMA/GAN. It’s taken 3 years for this to sort itself out in the market. Today, it’s clear that UMA/GAN and the RAN gateway architecture is the (only?) choice.

In the last 12 months, the debate started again, this time for femtocells. But just as quickly, a winner was declared: RAN gateway for HNB (a la GAN).

"This is like deja vu all over again"

Three years ago, when the concept of dual-mode handsets was just getting started, technology battle lines were drawn. There were two camps for providing seamless mobility in dual-mode handsets.

On one side was the ‘pragmatic’ UMA approach: UMA leverages the operators existing network elements and connects to the mobile core as a RAN gateway through standard interfaces.

The other side was a combination of IMS, SIP and VCC.

Constant battles were fought pitting UMA versus IMS (a RAN technology versus a ‘journey’ to an all IP core network); UMA versus SIP (a RAN technology against a session layer signaling protocol); and UMA versus VCC (a 3GPP standard RAN technology for mobile operators against a still-incomplete, almost-standard for fixed operators to connect the SIP core to the GSM mobile core).

In the end, UMA prevailed. It provides full-service transparency, security and scalability with a modest impact on the mobile core. If a mobile operator wants to roll out dual-mode service today, UMA is the only way.

As we enter 2008, a similar battle is shaping up around femtocells. The protocol for connecting the femtocell to the mobile core network has been divided into two camps.

On one side are the more pragmatic “Iu-over-IP” approaches. UMA, the only 3GPP standard Iu-over-IP approach, is leading the charge, but there are vendor specific approaches from Nokia/Siemens, ip.Access and others.

On the other side is some combination of IMS and SIP…again. Some have even erroneously thrown in VCC as a way to connect a femtocell to a mobile core.

As Yogi Berra famously said, “This is like déjà vu all over again!”

Will the SIP/IMS team be successful this time? It may be too early to say, but there are powerful forces behind the push for Iu-over-IP/UMA. Mobile operators do not want to burden the femtocell business case with new SIP/VoIP infrastructure. Many are drawn to the service transparency and relative simplicity of an Iu-over-IP/UMA approach. In the end, UMA is a proven, deployable technology.

2008 will be the year the two approaches duke it out. But if history is any indication, ‘pragmatic’ wins every time.

TI Changes Horses

As reported by Unstrung Wednesday, Telecom Italia (TI) has shelved its UMA-based Unica service offer in favor of a ‘home grown’ SIP-based solution.

The article goes on to say that TI is re-launching Unica using a SIP client available on one phone, the Nokia E65. Ironic since the UMA-based Unica service was thought to have a ‘limited availability of handsets.’

The new service is part of TI’s quad-play push. My Italian is a bit rusty, but after reviewing the web site, I believe that subscribers of the new Unica service must have TI Mobile (TIM) GSM service, as well as TI’s fixed-line VoIP service Alice.

The new Unica service is about putting Alice on the E65 device.

It’s not the same

I believe this is a key element that was overlooked in the article and in TI’s decision. UMA-Unica and SIP-Unica are actually very different services.

The UMA version of Unica was about delivering mobile services over IP and broadband -- make the mobile service work better and cost less when the subscriber is indoors and connected via Wi-Fi. UMA is a mobile centric service for fixed-mobile substitution.

The SIP version of Unica is about putting a fixed-line VoIP service (Alice) on a handset. The subscriber ends up with two services on one phone. One is the traditional GSM service; the second makes the E65 behave like an in-home cordless phone for the Alice service. You won't find this service marketed on the Telecom Italia Mobile site, it's only on adsl.alice.it.

In the end, the SIP-Unica service has no technical barrier to entry. Any user can download any SIP client onto any E65 device. TI has chosen to package this up into a service. This is the same business model as Truephone. From a regulatory perspective, any operator (actually any person) can provide the same service.

It’s clear the UMA and SIP versions are different services and will appeal to subscribers with different needs. The UMA-Unica comes from the mobile division, the SIP-Unica from the fixed division.

The bigger question is: what type of demand is there for a mobile phone with a fixed-line VoIP client? We all remember how successful T-One was.

A final thought

It’s clear UMA technically works and operators are deploying it successfully (Orange, T-Mobile, Telia,…). The problems with the UMA-Unica were not technology based. The issues with Unica were internal. Those watching the mobile market saw countless articles this year about TI’s unfortunate political struggles.

Changing the underlying technologies of the Unica service won’t solve the politics. In fact, putting the fixed division’s service on the mobile division’s device is likely to make things even more contentious.

What do you think?

Sonus Touts VCC

Vaughn O’Grady, editor of the GSM>3G Vision newsletter, published an interview today with Andy Odgers, vice president of wireless technologies with Sonus. The article is titled “Networks: the VCC version.”

I believe this was in response to an interview Vaughn and I did some weeks back which was (surprise, surprise) very UMA-centric. To be fair and balanced, Vaughn interviewed the ‘other side’, Sonus, who touted VCC as the path to convergence.

As readers of this blog know, I predicted that 2007 was the year that the industry would realize the short comings of VCC and begin to turn against it. UMA is the clear technology choice for mobile operators, whereas fixed operators, who have invested in SIP VoIP switches, are the only operators to potentially benefit from VCC.

Yet VCC has three major short comings:

- There is no data session continuity. As the title clearly states, it’s about VOICE call continuity. Start a streaming data session when on Wi-Fi, walk out the front door, and the session drops. Excellent.

- There is no support for supplemental mobile services. I can’t imagine that SMS wouldn’t be carried forward, but capabilities like MMS, ring tone downloads, over the air updates, or any other mobile application beyond voice is not supported. Again, the name clearly states VOICE CALL continuity, no continuity for anything other than voice calls.

- VCC is still not a standard. I honestly don’t know why this is. UMA went from proposal to the 3GPP in September 2004 to ratification in Release 6 in April 2005. VCC was introduced at least 2 years ago and it’s still not completed.

Perhaps Bridgeport, one of the biggest early VCC supports, was the proverbial canary in the coal mine. They shifted away from dual-mode and VCC more than a year ago. Their industry venture MobileIgnite is, for all intents and purposes, dead. Something is definitely not right in VCC land.

Yet Sonus has recently decided that VCC is the path forward for the mobile network.

I think the misunderstanding about UMA is common for people from the SIP world. He suggests that because networks are moving to IP and that “...as handsets become SIP-enabled – which they are supposed to be in the IMS model, eventually – you’ve solved your [mobility] problem.”

For some reason, simply saying “SIP” immediately implies mobility.

UMA is a RAN technology, akin to 3G. SIP, of course, is NOT a RAN technology. In fact, SIP has no knowledge of the actual transport layer. So why would putting SIP on a handset suddenly make it capable of moving from the 3G network to a Wi-Fi network? It wouldn’t.

In fact, it’s UMA that will keep SIP blissfully unaware of the underlying transport (Wi-Fi, 3G, GSM,...) and free from that complex mobility issue. Put a SIP client on a UMA handset and SIP gets full mobility between networks today, not “...eventually...”.

But I think it’s this comment that really highlights the issue:

“UMA is an interim that has no future; it doesn’t really fit in with an IP core.”

UMA is the structural foundation for mobile operators to use broadband and IP as *the* low cost RAN technology for service delivery in the home and office. It is the future.

Suggesting that a RAN technology like UMA doesn’t fit with an IP core is like suggesting that 3G doesn’t fit with an IP core. It comes down to a lack of understanding.

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.