VoLTE and Net Neutrality

Existing mobile voice technologies on 2G and 3G networks are considered "circuit switched" that is when you make a call a dedicated "circuit" is setup between the two handsets or out of the mobile network. In the new paradigm on 4G or LTE networks all voice calls will instead use "packet switched" technology, that is there will be no dedicated channel established. Instead voice is simply processed as another type of data carried over IP. In order to guarantee the quality of the call, there is a negotiation before the call is established on the network, and the packets are given differential treatment. This in effect emulates the qualities of a "circuit" so that the calling experience is good.

Net Neutrality is the idea that all traffic should be treated equally by the network with no preferential treatment. Thus under strict interpretation VoLTE calls violate the ideals of net neutrality. This violation is necessary due to real time characteristics of voice traffic. A 500 ms delay when loading a webpage or checking your Facebook or Twitter feeds doesn't really impact the user experience. This is not the same for a voice call, a half second delay seriously impacts the quality and variable delay or jitter has an even more severe impact. VoLTE has not really been discussed deeply in relation to neutrality, most likely this is because of the existing voice status quo on mobile networks.

Thus there are several implications of the above on mobile networks.
1. Not all data can or should be treated equally by networks.
2. An LTE network needs the facilities to negotiate differential packet treatment on a per session basis. That is a policy enforcement and control infrastructure.

Therefore in order to maintain a semblance of neutrality in the network carriers should be required to expose network policies controls to third parties and allow them to negotiate differential treatment. Rather than a burden or impediment to the role out of VoLTE this should be seen as an additional monetisation strategy for carriers. In effect exposing these policies allows the carrier to provide a "smart" pipe. A naive view would simply allow third parties to leverage this for differential voice processing, e.g. a FaceTime or Skype call could have the same network transit guarantee as a "traditional" mobile call. Of course you may have to pay for the privileged negating some of the benefits of these over the top services. On the other hand a more enlightened view would be that these policy controls etc. should be extended to other real time session based services such as video and data streaming services. For that matter is there any reason that it couldn't be extended to all data types.

Furthermore, there is no need that the policies only be applied for service and revenue uplift. Could that not also be used for selective service degradation. Mobile application ready for an update? Why not set it as a low priority background download, pausing for high priority services and being charged at a lower rate. Of course, such an offering would clearly violate net neutrality, but it is a model that people are used to in the form of off peak electricity charges.

This then means that the mobile carrier is no longer providing a dump bit pipe and a voice channel, but rather they are providing a smarter pipe. Thus the carriers have the potential to generate additional revenues, while also delivering a better end user experience. A large part of the infrastructure required to deliver such services is already being put in place to support the roll out of VoLTE, however additional thought needs to be paid to real time network policy control, billing and user notification and control. Obviously, there would also need to be an investment in user education.

WebRTC Codecs and Transcoding

It now seems that Opus and VP8/9 have been chosen as the codecs of choice for WebRTC. Inevitably when there is a debate about voice or video codecs there is also a debate about trans-coding and support for the chosen codecs. My basic view on this is if there is a need to trans-code then, then there is a fundamental flaw in the system design. Unfortunately, it is not practical or easy to eliminate trans-coding and it is an evil that will remain in our lives. However the need for it can be greatly reduced. In particular if the codecs are good (i.e. wideband for audio with good performance under adverse network conditions) then endpoint vendors will start to support them. This is why we have seen vendors implement support for Microsoft's Real Time Audio (RTA) codec.

This is why I was happy to read the latest post from Bloggeek on the Opus trans-coding challenge talking about how Audiocodes is adding Opus support. I expect that we will also see similar announcements from Polycom and other endpoint vendors over the short term. The sooner the eco-system gets updated to support Opus end to end the better off we will be.

Of course, it would be nice to see alignment between VoLTE codecs and WebRTC however I don't think that will happen any time soon meaning that we will need AMR to Opus trans-coding resources.


P.S. I know I haven't posted in a long time, I am planning to get more regular posts happening, however I make no promises.