Bandwidth Cost of Wireless VoIP

One of the reasons put forth by wireless carriers for why they prohibit VoIP on their networks is that it is a bandwidth hog. This is not true. Compare codecs typically employed by SIP-based VoIP services (e.g. G.723) and those for standard cell phone telephony (AMR) and this truth is immediately evident. The thing is, if you are unfamiliar with the technologies involved their complaint can sound legitimate.

There are differences between VoIP and standard mobile telephony that are worthy of comparison, once you get past the false raw bandwidth argument. Let's take a brief tour of some of these.

First, the bandwidth for voice and data are segregated on the radio link. This is very much like the segregation for voice and data on DSL (wired telephony) and DOCSIS (cable telephony), which I covered in an earlier article. The radio voice 'channel' is engineered for voice traffic patterns whereas the data 'channel' is engineered for the more bursty nature of currently-popular services such as web browsing, email, and photo sharing. For most users who do not use smart phones, the total data consumption for (standard) voice is higher than for data. With smart phones, the balance swings in the other direction.

For example, 1,000 minutes of VoIP using G.723, with packet overhead, is in the vicinity of 400 MB (including lots of assumptions, and no reduction for silence suppression), in each direction. A big bugaboo here is that the traffic is equal in both directions, which is different than for most other data applications, and is not accounted for in typical mobile network engineering models. As many people are aware, this is similar to the engineering for DSL and DOCSIS data bandwidth engineering.

There are issues beyond just raw bandwidth usage, especially upstream, that are in the mix. I talked about some of this in my Controlling The Phone series. First, let's consider the idea of using a common VoIP base for all telephony on mobile phones, including telephone service from the carrier itself. One technical advantage is that the currently-segregated voice and data bandwidth can be combined. The negative (technical) consequences include loss of service quality assurance since data traffic load is out of the carrier's direct control; additional work in the network would be needed to manage traffic priority, including the use of DPI (deep packet inspection).

A second technical problem is that VoIP, at present, must be implemented in software. Unlike the current firmware implementations, with its dedicated and optimized chips, software VoIP is expensive with regard to power consumption and is, generally, vulnerable to the security and privacy risks associated with all computer systems and applications. Until these issues are dealt with (and there is a demand for the chips that would include a stable version of VoIP software in firmware on dedicated chips), VoIP on mobile phones is merely a niche for enthusiasts using smart phones since the carriers will not migrate to VoIP.

Further, there is the matter that if the carriers migrate to VoIP they lose the argument for prohibiting and blocking competitive VoIP services. This would inevitably require them to compete on a equal basis with everyone else with a VoIP solution. Obviously this is not in their immediate interest.

It may be some time before we see a seamless VoIP experience on mobile phones. When we do, I expect that the fact that it is VoIP will disappear since it is ultimately just technology. The mass market is not the realm of technophiles, but rather people that simply want a phone that is reliable and does what they want.