EDIT: If you are interested in learning more about the Future of Voice, I am running a series of small-group Masterclasses together with Martin Geddes, as well as providing private internal workshops. Email me at information AT disruptive-analysis DOT com for more details
This will surprise a few people: I'm actually quite impressed with the announcement the other day about the OneVoice profile for defining an IMS-based approach to voice on LTE. I've now had a chance to read through the full document.
It essentially de-options a lot of the implementation vagueness and distracting flexibility around using IMS for mobile voice, creating a lowest common denominator "Profile" from the existing standards. It strips away a lot of the unnecessary fripperies and boils it all down to what amounts to the minimum set of requirements for basic telephony to work - if you happen to be an operator bought into the IMS world-view, that is.
Exactly two years ago I published a report on VoIPo3G (which included an analysis of the role of VoIP on LTE, HSPA and EVDO). I wrote "Too much emphasis is placed by 3GPP on unproven ‘multimedia’ telephony concepts rather than ‘plain’ VoIPo3G". More than three years ago I wrote another report on IMS-capable handsets (or the lack thereof) in which I wrote "There is little consensus on the answer to the question "What exactly is an IMS phone?""
Well, this document is an IMS-centric take on "Plain VoIPo3G", and it does go a little further in defining the capabilities of an IMS phone. It makes it very clear that "other media types" like video are not essential, for initial deployment at least. There is not a single mention of the word "presence" in the whole document. It talks about AMR codecs and not the "HD" wideband version AMR-WB.
It appears to have taken a long hard look at the unloved MMTel standard for mobile IMS VoIP and turned it into something more practical. It might even make "bare-bones IMS VoIP" a bit cheaper and easier to implement for some of the operators who are skeptical.
All of which is good. -But the problems it addresses have been obvious for at least 2 years, and this announcement is a start of a process and not its end. This document is just a suggestion, not a standard. It will be forwarded to 3GPP and GSMA and other bodies. It's written on a template that *looks* like a standards document, but for now it's just a helpful suggestion from some interested parties. "this specification defines a common recommended feature set and selects one recommended option when multiple options exist for single functionality"
Hopefully, it will become more widely adopted over time - although it will be interesting to see if any changes are made when other companies have their say. Notable major omissions from the roster of participants are NTT DoCoMo, China Mobile, Huawei, ZTE, LG, Apple, RIM, Motorola, Telecom Italia, T-Mobile, Qualcomm, NEC and quite a few others.
Various other commentators have suggested that this means that OneVoice is "One Ring to Rule Them All" (....and in the darkness bind them), spelling the end for Frodo (aka VoLGA), Gollum (CS Fallback) and all the other hobbit-like contenders for Voice on LTE.
I disagree.
OneVoice is necessary but not sufficient. It makes IMS less painful for mobile voice, but it doesn't make it ideal either. It makes interoperable IMS mobile voice less slow to develop, but it doesn't make it fast. It makes it less cumbersome, but doesn't make it elegant. It makes it less costly, but it doesn't obviously make it profitable. It's an important step, but it isn't the whole journey.
When the OneVoice press release came out, I was at the Telco 2.0 conference listening to Vodafone's Internet Services team discussing 360 and commenting on IMS RCS, saying "it was going in the right direction, but taking too long". They also mentioned they might think about putting a VoIP client into 360 at some point. I initially thought Voda's presence in the press release a bit strange given it seems in no hurry to deploy LTE, but on second thoughts I see no downside for them either: simplifying IMS is either neutral or positive for them, depending on which part of the company you talk to.
Either way, OneVoice isn't going to happen ubiquitously, nor overnight. Handset vendors must be breathing a sigh of relief that they *finally* have bits of a specification to work to for IMS handsets. But it's unlikely to be quick to hit the market or be optimised. And the overall business case for mobile operators to deploy IMS is still not exactly pretty, as it offers no obvious new revenue streams. For fixed IMS, there have at least been some decent arguments around cost-savings. But it's far from clear that the mobile IMS spreadsheets have a similar bottom line benefit.
So there is still likely to be a need for an interim solution for several years - as well as something that works on non-IMS LTE operators' networks. CS fallback is a bit of a train-wreck which nobody seems to like. So I think that VoLGA still makes sense for those wanting to make the most of their circuit-switching assets. And Internet-based voice services like Skype or a future "VodaVoIP" may have appeal for the more 2.0-style operators deploying LTE.
This will surprise a few people: I'm actually quite impressed with the announcement the other day about the OneVoice profile for defining an IMS-based approach to voice on LTE. I've now had a chance to read through the full document.
It essentially de-options a lot of the implementation vagueness and distracting flexibility around using IMS for mobile voice, creating a lowest common denominator "Profile" from the existing standards. It strips away a lot of the unnecessary fripperies and boils it all down to what amounts to the minimum set of requirements for basic telephony to work - if you happen to be an operator bought into the IMS world-view, that is.
Exactly two years ago I published a report on VoIPo3G (which included an analysis of the role of VoIP on LTE, HSPA and EVDO). I wrote "Too much emphasis is placed by 3GPP on unproven ‘multimedia’ telephony concepts rather than ‘plain’ VoIPo3G". More than three years ago I wrote another report on IMS-capable handsets (or the lack thereof) in which I wrote "There is little consensus on the answer to the question "What exactly is an IMS phone?""
Well, this document is an IMS-centric take on "Plain VoIPo3G", and it does go a little further in defining the capabilities of an IMS phone. It makes it very clear that "other media types" like video are not essential, for initial deployment at least. There is not a single mention of the word "presence" in the whole document. It talks about AMR codecs and not the "HD" wideband version AMR-WB.
It appears to have taken a long hard look at the unloved MMTel standard for mobile IMS VoIP and turned it into something more practical. It might even make "bare-bones IMS VoIP" a bit cheaper and easier to implement for some of the operators who are skeptical.
All of which is good. -But the problems it addresses have been obvious for at least 2 years, and this announcement is a start of a process and not its end. This document is just a suggestion, not a standard. It will be forwarded to 3GPP and GSMA and other bodies. It's written on a template that *looks* like a standards document, but for now it's just a helpful suggestion from some interested parties. "this specification defines a common recommended feature set and selects one recommended option when multiple options exist for single functionality"
Hopefully, it will become more widely adopted over time - although it will be interesting to see if any changes are made when other companies have their say. Notable major omissions from the roster of participants are NTT DoCoMo, China Mobile, Huawei, ZTE, LG, Apple, RIM, Motorola, Telecom Italia, T-Mobile, Qualcomm, NEC and quite a few others.
Various other commentators have suggested that this means that OneVoice is "One Ring to Rule Them All" (....and in the darkness bind them), spelling the end for Frodo (aka VoLGA), Gollum (CS Fallback) and all the other hobbit-like contenders for Voice on LTE.
I disagree.
OneVoice is necessary but not sufficient. It makes IMS less painful for mobile voice, but it doesn't make it ideal either. It makes interoperable IMS mobile voice less slow to develop, but it doesn't make it fast. It makes it less cumbersome, but doesn't make it elegant. It makes it less costly, but it doesn't obviously make it profitable. It's an important step, but it isn't the whole journey.
When the OneVoice press release came out, I was at the Telco 2.0 conference listening to Vodafone's Internet Services team discussing 360 and commenting on IMS RCS, saying "it was going in the right direction, but taking too long". They also mentioned they might think about putting a VoIP client into 360 at some point. I initially thought Voda's presence in the press release a bit strange given it seems in no hurry to deploy LTE, but on second thoughts I see no downside for them either: simplifying IMS is either neutral or positive for them, depending on which part of the company you talk to.
Either way, OneVoice isn't going to happen ubiquitously, nor overnight. Handset vendors must be breathing a sigh of relief that they *finally* have bits of a specification to work to for IMS handsets. But it's unlikely to be quick to hit the market or be optimised. And the overall business case for mobile operators to deploy IMS is still not exactly pretty, as it offers no obvious new revenue streams. For fixed IMS, there have at least been some decent arguments around cost-savings. But it's far from clear that the mobile IMS spreadsheets have a similar bottom line benefit.
So there is still likely to be a need for an interim solution for several years - as well as something that works on non-IMS LTE operators' networks. CS fallback is a bit of a train-wreck which nobody seems to like. So I think that VoLGA still makes sense for those wanting to make the most of their circuit-switching assets. And Internet-based voice services like Skype or a future "VodaVoIP" may have appeal for the more 2.0-style operators deploying LTE.
16 comments:
I cannot understand your suggestion that Volga should make sense as an intermediate step. Just as IMS, Volga is VoIP on LTE but with a different control channel.
Considering the non-homogenous LTE deployments that will be the reality for still some years, Volga needs SR-VCC to provide handover to the CS access for a substantial portion of the calls. Otherwise the call drop rate will be unacceptable.
SR-VCC is quite complex and puts requirements on most of the LTE/EPC nodes as well as on the MSC. Admittingly, CSFB has an issue with worst case some 2-3 secs call setup delay but compared to SR-VCC it is a very simple feature.
Also, as the combined mobility management and the SGs interface will be deployed already for SMS to data cards, the incremental step to also send the paging over that interface is very small.
If viewed from another direction, then perhaps your point actually underlines a strength of Volga compared to CSFB: Volga has very similar requirements to VoIMS in the E-UTRAN/EPC (including RTP/IP transport and SR-VCC)and so closely aligns any investment with an operator's longer-term IMS planning. I'm not sure that there is any part of CSFB for which the same statement could be made.
Also, I know 2-3 secs of extra call setup delay doesn't sound like much, but in my experience some operators would rather sell their respective grandmother's into slavery (so to speak) before adding 2-3 seconds onto call setup times compared to the current UTRAN/GERAN case (especially for mobile-to-mobile LTE calling). I think I read VoLGA call setup times should be even lower than UTRAN, which is really how it should be with 4G vs 3G, or even 2G technology, not the other way around.
Besides, operations staff are measured on these KPI's, you know! :-)
2-3 secs looks more like the expected average, not worst-case for CSFB. And double it for an LTE-to-LTE call, I presume?
Making your core services worse for your best customers (ie those buying the first LTE smartphones) is hardly a good strategy for retention.
And I'd love to be a fly on the wall when someone tells Steve Jobs that worsening the user experience of making a phone call, is an acceptable price for higher theoretical-but-unachievable data rates.
Dean
No, 2-3 sec additional call setup is worst case. The expected average should be less.
Do you think the Volga SR-VCC handover to CS should be without disturbance then?
If the LTE coverage is spotty it makes sense to start the call on CS directly. A large portion of the calls will end up there anyhow.
People seem to ignore the fact that early LTE deployments will be data-only in which case SMS-over-SGs will suffice for SMS delivery. Voice services will eventually follow by which time, IMS based VoIP will be ready for commercial deployment. One-Voice initiative will fast-track it.
@Martin: My point is that if you are going to implement SR-VCC for VoIMS anyway, then doing it for Volga 1st is not incremental to the VoIMS plan - it is a necessary condition. Whether it is a complex implementation or not is something that must therefore be addressed by 3GPP for VoIMS mobility anyway. I suspect the same considerations were present in the GERAN to UTRAN transition too (islands of UTRAN) but somehow we managed ...
Perhaps a more immediate issue is that of signaling load. Call setups in GERAN/UTRAN generally have no impact on the HLR. With CSFB, HLR load is directly proportional to the number of CSFB calls made in the network - every single MO or MT call attempt (whether successful or not) requires multiple HLR transactions (according to the CSFB procedures with or without PS Handover). Do you consider that operators have understood the implications of this?
@madmax: I think one of the points that Dean was making in the OP was that there will certainly be operators who will deploy early LTE for data but who will not be ready or able to invest in a full IMS/VoIP network when they need to deliver a voice service, even if products are available at that time.
Those operators will likely need some form of interim solution for voice over LTE.
Martin, Dean's suggestion makes perfect sense, if you don't assume Dean to be an impartial observer in matters related to VoLGA.
Martin
The SR-VCC point is fair, but I'm not convinced that:
(a) *That* many calls will need to fall back to CS from VoLGA. Coverage would need to be pretty patchy for it to happen regularly.
(b) Given that much of the time, 3G-to-2G calls still often drop during handover (and they're not that common anyway)... does it really matter?
In my view, actually the best solution is not to bother with LTE and just stick with HSPA+. But if an operator *must* move to LTE for some reason, then there needs to be a viable option. Nobody I speak to thinks that CSFB is the least bit desirable - and various have disputed the 2-3 sec worst case, which is anyway far from being the only downside.
Personally, I'd rather have an occasional dropped call than a consistently poor call setup time.
Anonymous - amusing. I guess that I could claim to have invented the concept behind VoLGA, so perhaps I feel more positive about it. I remember a slide I had in 2006 titled "Salvaging something from the wreckage of UMA" in which I suggested the notion of "2G over 3G"....
I've also long advocated operators partnering with Skype or other peers to offer best-efforts VoIP on HSPA, prior to LTE deployment.
Dean
Dean, I would say Martin's point about the complexity of SR-VCC is fair if you are considering a full IMS deployment. In reality handover using SR-VCC for the VoLGA case is significantly less complex in comparison to the VoIMS case. In VoLGA, the procedure invokes a CS to CS handover in the core, not a full IMS to CS handover. There is no IMS domain transfer involved, no service continuity to deal with (as the call is previously anchored in the CS domain) and no new features or modifications needed at the MSC. The MSC performs a CS handover between two cells in the UTRAN/GERAN, the MME thinks it is handing over a VoIP PS bearer to the CS domain, just as in the nominal VoIMS case.
In that sense, it enables operators to start with a simpler SR-VCC implementation for handover between the LTE and UTRAN/GERAN some time before they must implement the full network-based transfer functionality with a One Voice VoIMS deployment.
Dean - with your recommendation for operators partnering with Skype, have you seen any good analysis of the resource impacts of Skype over HSPA?
Doug - Nothing to hand, but my expectation has been that any sufficently-large operator would work collaboratively with Skype (or other VoIP players, or inhouse teams) to develop an optimised variant of the software, rather than just using the standard PC or WiFi-oriented version.
The precedent here has been the use by 3, using a CS-based Skype client, using ordinary 3G voice, but which hooks into a VoIP gateway.
I would expect there to be various ways to optimise codec choice, signalling patterns etc. to optimise Skype (or at least improve it) for HSPA utilisation.
All that said, I've got to believe that quite a lot of the 50 million or so PC users with mobile broadband are using Skype - in markets where the MNOs are positioning HSPA head-to-head vs. ADSL it's generally not a realistic proposition to ban its use.
Dean
Dean,
If you consider the aggressive LTE deployments on 700Mhz in US, I guess that the coverage can soon become good enough such that CS handover would not be an issue.
However, for the deployments in Europe and Asia using frequencies above 2GHz, the coverage will be spotty for a long time, in particular indoor. I do not think it makes sense to use VoIP in these scenarios, neither Volga nor IMS. The natural solution would be to use the CS telephony in this case. I.e. to use CSFB.
I do not think that the call setup delay from CSFB will be very disturbing. In many situations it will be a fraction of a second.
If you are rigth though that this is a major concern, there should be simpler ways to solve that than to introduce Volga and SR-VCC. E.g. to introduce dual receivers in the terminal as will be one option for CSFB in CDMA. Then you get no delay at all as the terminal can do the measurements and repond to the paging on CS as usual.
Martin
Any evidence to support your assertion of fractions of a second extra latency?
According to one of the 3GPP submissions I've read:
"Rel-8 CSFB to GERAN/UTRAN adds several seconds compared to 2G and 3G native CS calls – between 2 to 4 additional seconds"
(from SP-090633 by Huawei and China Unicom)
Now obviously I can't validate that separately, so if there's anything contradictory you've seen then I'd be interested in seeing it.
As well as user experience, you may also wish to consider the liability implications of adding 2-4 secs to setup times for emergency calls.
Dean
Dean,
I based my statements from the findings in 3GPP RAN WG2. They claim that fallback to GSM is 1 sec and to 3G 2 sec additional call setup delay. Fractions of a second should occur when you can do a blind handover.
The Huawei contribution SA2 contribution you referenced has obviously a different result.
Anyhow, my aim was not really to assert the performance of CSFB but rather to claim that a "fallback" to CS is the only rational method when you have spotty LTE coverage.
Thus, if Huaweis data is more correct that 3GPP´s, it simply means that it needs to be fixed. One obvious way to do that is the dual receiver method that is used in CDMA. This implies additional complexity in the terminal but if it is ok for CDMA + LTE it should be possible for GSM + LTE as well.
Why IMS allows cost-savings in fixed domain, but not in mobile domain?
Post a Comment