Voice over IP – The Move Away from the Baseband

There is one thing, all current mobile Voice over IP approaches have in common, be they VoLTE, VoLGA or Over-the-Top VoIP applications such as Skype:

Traditional mobile voice services are an integral part of the baseband radio chip and in the case of Android, for example, the user interface that runs on the application processor as part of the operating system communicates with the baseband radio chip with AT commands to establish and tear down a voice call. In other words there's not much to do for the operating system itself except for issuing a couple of commands. All the rest is done in the baseband chip, including voice processing and handovers between different radio access technologies such as UMTS and GSM.

As soon as any VoIP technology is used, and that's what they have in common, all these things move up from the baseband processor to the application processor and the operating system. What stays in the baseband is the handover management between different cells of the same radio technology and, for some VoIP variants if implemented, the enforcement of quality of service.

This means that there is a fundamental shift in who delivers the software for making voice calls on mobile devices in the future. Today it's the baseband chip vendor. For VoIP, it's going to be a third party from a network operator's point of view. Google, Microsoft and others will push ahead with their own voice services that will run over IP, no matter what kind of transfer network is used. This way, those VoIP services are likely to be implemented tightly into the operating system. For mobile network operator VoIP it's likely to be external companies that will offer plug-ins for popular smartphone operating systems. Easily done with Android, as can be seen for example with GAN clients from Kineto today. But what about smartphones that are not bought via a newtork operator, will they have those "plug-ins' as well? And how about closed operating systems such as those from Apple and Microsoft?

This also means that there is a catch for over the top VoIP solutions that are completely transport network independent: They will topple over as soon as the device has to select a 2G network which can't transport the IP packets anymore. Also, it might take a while for handover procedures between LTE and UMTS to mature and be quick enough to keep the the interruption time in acceptable limits. The only thing that helps is to make LTE (or UMTS) as ubiquitous as GSM. Not impossible but I don't see it happening in the next couple of years.

Network operators supplied VoIP solutions have one big advantage, though: They can interact directly with the network over the network signaling layer. This is coordinated in the baseband chip and the network operator's VoIP server and thus, VoIP calls can be handed over to circuit switched channels once the only option to continue the call is a 2G network. However, that's far from being trivial as it requires a very tight integration of the VoIP service (i.e. the IMS) with the current circuit switched MSC architecture. For details see my post from back in 2008 on IMS Centralized Services.

Also not to be underestimated are the potentially higher power requirements of running everything in software and using a transport network that is optimized for high speed data. I wonder how that compares to processing a voice call in a dedicated hardware unit as it is done today and using a transport network (GSM) that is highly optimized, also from a power consumption point of view, for transporting voice frames. For some users, this is perhaps less of a problem as they are now substituting voice calls for other forms of communication such as instant messaging, Facebook, Twitter, etc. and hence have a reduced need for mobile voice. But the number of voice minutes per person per month doesn't seem to fall, so I wouldn't bet on this issue just going away like this.

All things mentioned are not insurmountable but it will take a lot of dedication and effort to tackle them.