Saturday, 2 August 2008

LTE, IMS and Voice calls!

Picked this up from Martin's Blog. One of the things that has been left undefined are the end user applications. Unlike GSM and 3G+ where AMR RAB's has been defined for CS voice calls, there is no provision in LTE. In fact we know that CS domain is completely absent and only IP based PS domain is present. It has been assumed that IMS will be de-facto present along with LTE and the architecture rightly defines so but there is nothing stopping LTE being deployed without IMS. The following is from Martin's Blog:

LTE requires the IP Multimedia Subsystem (IMS) for voice calls. So what will happen to LTE if IMS doesn't take off? I know, many in the industry believe even asking such a question is close to heresy but who can promisse today that IMS will be a success?

The trouble with IMS and to some extent with mobile VoIP is not that it's a young technology, standardization has been going on for many years and books about it are going into their third edition. However, there are still no IMS systems out there today that have come out of the trial phase, and I have yet to see a mobile device with an IMS client which is nicely integrated and simply works. Also, the IMS standard is getting more complicated by the day which doesn't make life easier. Another main issue with VoIP and consequently IMS is power consumption. I use VoIP over Wifi a lot on my Nokia N95 and can nicely observe how the phone slightly heats up during a long phone call. Also the non-IMS but SIP compliant Nokia VoIP client in the phone, which by the way is nicely integrated, sends keep alive messages to the SIP server in the network several times a minute. This is necessary mainly due to Network Address Translation (NAT). While this doesn't require a lot of power over Wifi, power consumption skyrockets as soon as I configure VoIP for use over 3G. I can almost watch the power level of the battery drop as the network now constantly keeps a communication channel open to the device. So there are two problems here: VoIP calls cause a much higher processor load during a call, i.e. the VoIP talk time is much shorter than the 2G or 3G talk time and the standby time is significantly reduced. Add to that the missing handover capability to 2G and 3G networks (yes, I know there is VCC in theory) and you have a prefect package for a very bad user experience.

So the big question is if all of these things can be fixed, say over the next 5 years!? I have my doubts... If not, then LTE has a big problem. Will network operators accept running GSM or HSPA alongside LTE until the problems are fixed? The choice is this and accepting that LTE is for Internet access and some niche VoIP applications on devices such as notebooks or to decide sticking to HSPA(+) until things are fixed.

In case LTE is deployed and LTE - IMS devices are not ready it's likely that a device can't be attached to several radio networks simultaneously. So how do you inform a device attached to LTE about an incoming voice call? It looks like the people in standards bodies are looking at different solutions:
  • Send a paging message for an incoming circuit switched voice call via LTE to the device. You can do this on the IP layer or on the radio network signalling layer. The device them switches radio technologies and accepts the call.
  • Some people have started thinking about extending LTE with a circuit switching emulation.
This could be handled on the lower layers of the protocol stack and the software on top would not notice if the call uses GSM, UMTS or LTE. This one is easier said than done because I don't think this concept will fly without a seamless handover to a 2G or 3G network. If such a solution ever gets into mobile phones, it would make life for IMS even harder. Who would need it then?

Are there any other initiatives I have missed so far to fix the LTE voice issue?

Dean Bubley in his Disruptive Wireless Blog has interesting analysis on this topic as well:

My view is that operators should either work with Skype, Truphone, fring et al – or compete head-to-head with them using their own pre-standard mobile VoIP implementations. I still believe this is a good route to VoIPo3G, especially for operators that are already moving to VoIP in their fixed networks, or which are early deployers of IMS or other IP-NGN architectures. Blocking VoIP it not a viable option in competitive markets - as evidenced by the increasing trend towards openness that's been seen in recent weeks.

But interestingly, another ‘flavour’ of mobile VoIPo3G is now emerging as an alternative for mobile operators – Circuit Switched Voice over HSPA, as an early specification within 3GPP’s Release 8 generation of standards. This was just starting to evolve seriously when I published the report in November, and is mentioned in the comments on this post of mine. And it now seems to be moving fast. In the last week, two of the largest ‘'movers and shakers' in mobile technology - from both handset and network sides - have talked up this approach to me unprompted. And I’m in agreement that it’s undoubtedly going to be important.

Basically, CS voice over HSPA takes the ordinary mobile circuit voice service, using ordinary diallers on the phone, and circuit core switches in the network... and tunnels it over an underlying IP bearer. So the application isn't VoIP, but ordinary circuit telephony, but the wireless transport (down in the guts of the phone) is IP.

In other words, it's "Mobile Circuit Telephony over IP"

In fact, we've all heard this concept before. It is an almost direct HSPA equivalent of UMA’s voice over WiFi. In both cases, there are benefits for operator voice calls, derived from the nature of the radio IP bearer: cost in WiFi’s case as it’s unlicenced spectrum, and the efficiencies of new packet transmission techniques in HSUPA and beyond. And in both cases, it’s not necessary for the operator to have already deployed IMS, VCC and so forth – they can reuse their existing core networks, and get away with less messing-around at the handset application layer. [I’m not sure yet whether the IP tunnel uses a similar IPsec approach to UMA, and could use a similar gateway, or if it’s entirely new]. The downside is that this isn’t a next-gen IP voice service in terms of application capability – it’s voice 1.0 transported over network 3.5.

There are also various reasons why I'm more positive on CS over HSPA than I am about WiFi-UMA.

It's a matter of semantics whether you treat CS Voice over HSPA and UMA as 'true' wireless VoIP. Both are using classic circuit signalling, rather than SIP or proprietary protocols like Skype. Neither are as easy to use as "full VoIP" as the basis of innovative applications like voice mashups.

The interesting thing to me is that the industry is starting to polarise into different points of view on this issue. Ericsson remains a staunch MMTel advocate, driven by its desire to push IMS as the main future application layer. But other major players seem to be edging towards a CS over HS worldview, albeit with a hedge around naked-SIP VoIP.

So… taken together, the various types of VoIPo3G are going to be:
  • Over-the-top independent VoIP (Skype, Truphone, IP-PBX etc) with a dedicated client on the handset or PC
  • CS voice over HSPA, using the ordinary circuit voice app plus some lower-level IP ‘plumbing’.
  • IMS MMTel – needing a full IMS client on the device
  • Other IMS or standards-based voice apps like PoC or perhaps a standalone SIP VoIP server plugged into the IMS application layer
  • Standalone operator softswitch-based VoIP connecting to a (probably) SIP client on the handset.
  • Partnerships or mashups of the above.

Messy and diverse, in other words. And all of these have different use cases, different pro’s and con’s, different requirements in terms of user behaviour, cost and so on.

But the bottom line is that with the addition of CS Voice over HSPA, my top-level VoIPo3G predictions are still looking feasible, although some of the fancier web- or application-based VoIP capabilities will be trickier to exploit by the operators choosing that approach.

I have to admit that I havent looked into this area at all and cannot comment on which direction things will move. One thing that I can definitely say from my experience is that the initial movers, if successful, will set the direction for others to follow and may be eventual winners.

3 comments:

Anonymous said...

Interesting analysis. A few points:

- IPv6 would help with NAT of course, removing need for those keepalives and dramatically improving standby time. You'd still have occasional keepalives (maybe every few minutes) so the client and server can clean up if one of them disappears.

- battery life and power usage is something that will gradually improve over time - early circuit switched 3G phones had very short battery life, so improvements within 5 years will be significant.

I don't think CS voice is going to go away completely, but I think it's reasonable to expect most LTE deployments to use IMS voice within 5 years. Much depends on whether operators really push forward on IMS, though - if they decide IMS is too complex and want to retain CS voice, then the vendors will have to deliver that.

Abolfazl said...

I agree, interesting analysis. However, I don't think the power usage of VoIP codecs and IMS signalling are significantly high when compared with other applications that are being used on smart phones. IMS complexity compared to CS also is important but not the main hindering factor.
I believe the main reason is a technical issue. It is more about are mobile operator willing to use VoIP and provide open interfaces for application programming or not. Voice/SMS are best offered in CS and for other applications "naked Internet" seems to work fine. LTE might be able to push some operators. Others will search for ways to reuse CS over LTE.

Anonymous said...

@Abolfazl Whether operators let users to use VoIP applications or not, end users have already been able to make these types of calls by using their internet connection via skype etc. That's why it doesn't make sense for operators to push them to use different alternatives. There's only one way for all vendors and operators. I think IMS voice usage will be unavoidable in the end.