Regular readers will know that I've been a huge skeptic of UMA (Universal Mobile Access) versions of dual-mode WiFi+cellular for more than 4 years. And indeed, the market has shown me to have been correct - apart from moderately-succcessful deployments by Orange in France and T-Mobile in the US, UMA has largely been a failure.
My issues largely related to the original lack of a 3G variant of UMA (until recently, all the services have been 2G+WiFi) and the complexities of creating phone OSs, UIs and applications that had UMA-friendly [ie operator-centric] WiFi running at the same time user-defined WiFi functions. Most UMA applications "hide" the bearer from the application stack, whereas I firmly believe in a connection manager layer that tells apps whether they're using WiFi, cellular etc.
But most of my original objections to UMA do not apply to its recent incarnation (in its 3GPP-approved GAN acronym form, meaning Generic Access Network).
These issues are rather less important for LTE, which is:
a) Using licenced spectrum, so there is no conflicting "private" usage mode like there is for WiFi
b) Desperately needing a standardised voice service
c) Unlikely to be paired with an IMS core except in a handful of cases
d) Timed to arrive at a point in the economic cycle when nobody will want to ditch their core switches & circuit voice apparatus
e) Going to demand that operators simultaneously learn about a new radio network technology - and transition their 80%-of-revenue voice service to packet technology, with all sorts of unknown dependencies and learning curves.
I've written before about the possibility of "tunneling" circuit voice over a packet-based radio connection. Consequently, I'm generally a believer in the new VoLGA concept advanced by T-Mobile and various vendors like Ericsson and Kineto. Apart from the stupid name, obviously, which is one of the most unfortunate acronyms I've seen in years. I'm in two minds whether they should have kept it identified as UMA rather than GAN, given the baggage that would convey, but surely they could have got some branding folk involved? (How about just VoLTE, which would have the added benefit of a pun relating to the volte-face about IMS VoIP?).
Nevertheless UMA-over-LTE has various advantages in my mind, as the network side of UMA already "works" and is quite robust, with well-defined security gateways and testing and so forth. It supports SMS natively. It also doesn't rely on clunky fall-backs to HSPA or GSM, which may require the handset to switch to different frequency bands as well as technologies, and which could interrupt ongoing data applications. It also helps extend the life of the circuit core, which is good news for CFOs, but bad news for the IMS and RCS crews.
One thing which is notable is that all of this is being done outside the 3GPP, which appears to have been dragging its feet for several years over this VoIP+LTE problem. I'd imagine that this more-pragmatic group will try to push for VoLGA to be standardised after deployment, rather than braving the politics in the short term. Martin Sauter has some extra comments here.
(There: I finally said something nice about UMA. There's probably a case study in good analyst relations there somewhere, as Kineto has been very good-humoured about my being a thorn in its side over a prolonged period of time.)
Dean Bubley's Disruptive Wireless: Thought-leading wireless industry analysis
3 comments:
Why bother? LTE will overlap existing 2G and 3G coverage, mainly providing high speed data. It's not needed for voice, but for high usage data devices like laptops and netbooks.
If you're not an IMS fan, then why not keep the voice traffic on 2G/3G. Sell 2G/3G/4G data dongles for those who need the speed/capacity. This will free up 3G capacity in hotspot areas for those smartphones which want to use it.
Assuming that the profile of high volume data is mainly with larger/higher capacity devices like laptops/netbooks, then problem solved without the need to change/swap/upgrade vast numbers of handsets.
Surely it will be a very long time before the whole world has switched to LTE - so networks will want to retain compatibility for inbound roamers with older technology.
Voice over LTE (I also like VoLTE better :-)will certainly make sense from a cost perspective especially for low cost service providers. Not only the CapEx will reduce but they are no longer required to add to costly spectrum positions once capacity reaches a critical level.
From an All-IP vision, which R8 notes so much throughout, it's disappointing to see that something like VoLGA, obviously provided to protect the existing carrier core (more so for the vendors than operators), is gaining any steam at all. Operator's seem to be asking the right questions, but as you noted in your IMS post, are being led astray. The point is that VoIP with Mobility has been around for a while in various forums, predominately the 802.11 space.
However, the call control, clients and mobility pieces are very mature now and would appear to be easily ported to an All-IP LTE network. Just make sure the E2E flows have the network support they need for latency, QoS, etc. Shouldn't be too hard since that is all part of the LTE air improvements and EPC All-IP architecture.
Imagine an ultra-skinny client supported by multiple UE OSs (MS, Sym, Android, etc.), a scalable (larger than IT size obviously)full featured call control system residing on a state-of-the-art virtualized data center design. Say goodbye to the MTSO as we know it and hello to the All-IP, smaller space, more scalable, easier to grow MTSO Data Center of the future.
Embrace the IP ;-) Let CS die a peaceful death. VoLGA and those vendors behind it, while claiming to want to protect the assets of the carriers, are really in it only because they realize without someway to protect that piece of their business, they may find themselves providing nothing more than wireless APs on steroids (eNBs).
Last point, anyone notice that the VoLGA authors have already completed the architecture (Stage 1) and specifications (Stage 2)sections (to the most part), but are now just starting the requirements (Stage 3) portion? Sorry, been doing this more than 20 years and something seems off here. I'd like to think that outlining the requirements first would be necessary in order to determine the best architecture and specifications in order to meet those requirements. Seems a bit backwards to me.
Post a Comment