From the UMA perspective, VCC or Voice Call Continuity, is an emerging specification designed for a fixed line operator to hold on to a mobile call when the phone is operating over Wi-Fi/IP in the home, then transfer the call to the mobile operator when the subscriber leaves the home.
VCC is also touted at the “alternative” to UMA. VCC proponents are quick to point out that the specification will be finalized “shortly” and devices are “coming soon”. Of course UMA is shipping and deployed today and is already the de-facto standard to which any VCC service must measure up.
However, I wanted to take a moment to comment on a piece that came out in Oct 2006 around the IMS World Forum in San Diego.
The piece was released by the IMS Forum, a recognized industry organization leading the charge to drive standards and lead interoperability testing, and gives a view of the challanges of developing the new specification.
Read it here.
I think the piece is interesting because it’s one of the first honest assessments of the state of VCC from the “inside”. It was developed by an organization ostensible focused on helping VCC come to market.
IMS Forum chairman Michael Khalilian comments: “It is well recognized that the handover is a technical challenge for convergence solutions of two drastically different networks, i.e. Wi-Fi SIP and cellular.”
Finally we get an inkling of the enormous task VCC is out to solve, bridging call control between two completely independent and technically different (packet/SIP vs circuit/GSM).
The article “warns of significant hurdles [that] must first be addressed before the opportunity [of VCC] can be realized.”
Tops on the list:
- Supplementary Services. This means everything your phone can do beyond making a call. It includes SMS, MMS, ringtones, games downloads, as well as telephony services like conference calling and 3 way calling. Yes, none of that is supported in VCC today or tomorrow. It all needs to be defined.
Beyond supplemental service support, the article lists:
- the reliance on CAMEL for handover
- dealing with multimedia session mobility
- setting realistic timeframes for rollouts.
There is some real work to be done to get VCC to the same level as UMA.
And this is just a drop in the bucket. On his blog, industry pundit Dean Bubley wrote about the next hurdle facing the IMS world, asking what exactly is an “IMS handset”? It’s not defined and an industry standard is a very long ways off.
It's easy to believe the hype that VCC will be able to magically maintain service transparency and service quality balancing between two completely different and independent networks. Oh and it will all be buttoned up and deployed in less than a year. A realistic VCC service is much farther off than anyone can predict.
4 comments:
Interesting article, yet the phone vendors seem to belive more in SIP than UMA... Why is that?
Ah, interesting question.
To say handset companies "believe" in SIP more than UMA is a bit subjective. Do you hear more about SIP in handsets than you do about UMA in handsets? Yes, definitely.
But frankly, the handset vendors are going to believe in what their customers tell them to believe in. Mobile operators are deploying a lot more UMA than SIP, that's for sure. And there are a lot of UMA phones in the pipeline right now. The next six months will likely see a half dozen new models announced.
There are certainly a lot of fixed operators (looking at VCC) who want to merge their fixed service with mobile. To do this, they need SIP on handsets, and there is a lot of publicity around this aspect of FMC.
But mobile operators, the bread and butter of the GSM community, have hardly any SIP applications (and certainly no VoIP) deployed in the network.
Can you shred some light into the complexity to build a UMA and SIP (with or without VCC) handset?
And anyway, having developed the UMA on the handset once, what stops the handset manufacturers of putting it in the whole serie of terminals having WLAN? (I would expect vendors like Nokia to put it in the whole series 60 range)
I can't offer much on the complexity of the SIP stack. UMA integrated at a low level into the handset OS. Generally the SIP stack sits "above" it and does not have any direct interaction with the UMA stack.
This makes sense because SIP is a higher level connection protocol whereas UMA is a radio access technology.
As for future developments, I'll give you two bits of information:
First, at last year's UMA conference, the reps from Nokia and Motorola both said "now that UMA is a 3GPP standard, it's part of our core software build process and can be added to any dual mode device as required." So I think we will see UMA in dual mode devices as a regular course of business.
Second, the Nokia devices we work with in the office all have a SIP stack running over the UMA stack. This also makes sense. UMA is a RAN service, SIP runs over the RAN, therefore, these technologies are compatible.
Post a Comment