Voicer over IP: The Move Back Into The Baseband

Back in 2011 I ran a post titled "Voice over IP – The Move Away from the Baseband" describing how Over-The-Top Voice over IP clients such as Skype do not run in the modem baseband chip as traditional circuit switched voice today but rather on the application processor as an application of Android or another mobile operating system. At the time there were no indications in the public domain that Voice over LTE (VoLTE) clients supporting future network operator voice services would be any different, hence the post's "move away" title. This would have a rather significant impact on operating systems such as Android, iOS, etc., as the integrated voice application ("the dialer") would have to become aware of:

• IMS and VoLTE
• The interworking between VoLTE and traditional circuit switched (CS) voice
• It would have to handle mid-call handovers from VoLTE to CS when leaving the LTE coverage area.

Gone would be the days of just sending a couple of straight forward commands to the modem chip to establish a voice call, to end it and to have a couple of simple commands to manage supplementary services such as call forwarding settings and conference calls. But now it seems things are looking different:

In recent posts on the ST-Ericsson technology blog they describe an approach in which the core of VoLTE, the IMS client and the VoLTE application itself do not run on the application processor but are back in the modem baseband chip. From the information given there I take it that this is not just a concept but something they are serious about to commercialize. The core of that post is around the IMS client in the modem being an IMS B2BUA (Back to Back User Agent, more on this later) but there are a number of other fundamental technical details that are worth thinking about as well:

To have the IMS Client and VoLTE IMS application in the modem baseband chip means that no longer does that chip only transparently move IP packets to and from that application processor. Instead it needs to have a full IP protocol stack of its own now as well. The PDF linked in the ST-Ericsson post above shows how the 3GPP concept of having an IMS signaling APN (Access Point Name) with an IP address that can be separate from the APN and the IP address used for transparent Internet access is handled by the modem based IP stack and the IMS client first. The modem IMS client then forwards the processed signaling to either the VoLTE client, also running on the modem chip or to an IMS client app running on the application processor.

The link to the application processor is necessary as VoLTE may not be the only IMS app running on a device. The RCS-e service that is currently worked on is an example of an IMS app running on the application processor. No special IMS API is required for the IMS app (such as an RCS-e client) on the application processor to communicate with the IMS client (the IMS B2BUA) on the modem as everything is based on an IP connection and the B2BUA concept. 

And in case you have been wondering what a B2BUA is in IMS: Basically the B2BUA sits between an IMS app such as the VoLTE or RCS-e app and the IMS server in the network. Instead of the apps communicating directly with the IMS server in the network, the apps communicate with the B2BUA. The B2BUA then modifies and forwards the messages on the app's behalf. Wikipedia has some further details.

So while all of this sounds a bit complicated it actually makes a couple of things a lot easier. First, it allows to run several IMS client apps simultaneously on one device that all share a single IMS session towards the network managed by the B2BUA in the modem chip. And second, the VoLTE app has moved back into the baseband. That means that all of the complexity of managing the duality of CS voice outside of LTE coverage and using VoLTE while an LTE covered area are hidden away from Android and other mobile operating systems. Also, mid-call handovers between VoLTE and the circuit switched network (IMS Centralized Service, SR-VCC) can be made transparently from the point of view of the user operating system. In other words, the "dialer" app of Android, iOS, etc. can continue to use the same commands as in a CS only device and never notices a difference.