Issue 91                September 2014

How SDN Can Multiply VoIP Channel Capacity

by William Flanagan, Publisher

Pull out a fresh napkin or turn over that envelope: we're going to compare the bandwidth requirements for voice connections on public networks. First is the legacy PSTN based on time division multiplexing (TDM). The other is what may be its replacement, the all-IP infrastructure where voice, video, data, and texting converge--VoIP for short.

We'll assume the calculation for TDM is well known: a constant 64 kbit/s in both directions.

For VoIP, start with today's routing procedures, add IPv6, and encapsulate in Ethernet for access to the WAN. We'll ignore PPoE (Point to Point Protocol over Ethernet) headers; while still used for some Internet access, it likely will disappear. Then we'll compare bandwidth use in a traditional routed network to the potential bandwidth per channel on an SDN.

VoIP may not be as inevitable as death, but it is surely in the 'taxes' range. People who designed, built, and operated TDM switches and multiplexers are almost all retired (present company excluded). You can't get parts to continue building the old designs and nobody will invest in R&D for a new TDM switch. So get used to VoIP.

Fans of IP often celebrate that IP is more efficient than TDM transmission, granting bandwidth on demand and only when needed.  The question for today's exercise, however, is how many voice connections will a pipe of a given size (and cost) carry.  For examples, what is the capacity of a dedicated access link from a SIP trunking provider, or a long distance connection between countries.

The Table below summarizes some rules of thumb and engineering practices.  The numbers reflect voice channels on a T-1 access link, but extrapolate to larger pipes.  Note that a voice TDM link behaves the same up to 100% utilization.  For packet transmission good practice keeps throughput to something less than the link capacity, 80% here.  To give each party on a call equal opportunity to speak, and to avoid the possible confusion of doubling the bandwidth of a connection, we'll specify full duplex Ethernet.

VoIP today carries several headers on each packet. Looking long-term, we use IPv6 in the calculations.

Real Time Protocol (12 bytes) + UDP (8) + IPv6 (40) + Ethernet (28) = 88 bytes per packet

Many VoIP systems create one packet every 10 ms: 

                       100 packet/s x 88 bytes/packet x 8 bits/byte = 70.4 kbit/s for the headers.

Encoded voice most often is 64 kbit/s PCM. Look ahead to High Definition voice at 32 kbit/s and the total remains more than 100 kbit/s per voice channel. Compressing voice information to 8 kbit/s (in use by some carriers) drops the minimum requirement to 79 kbit/s. Each byte of voice payload needs multiple bytes of headers.

Most of those headers are used by routing protocols and switches in a discovery protocol to find hosts. There could be more headers for additional features: virtual LANs, LAN emulation services, authentication, IP security, etc. At least one vendor has used the longer TCP header in place of UDP. Some networks could add an aggregation header to define busy routes shared by many connections.

Enter Software Defined Network (SDN) technology that calculates routes in a central server, not in each packet handler (router or switch). If the SDN controller instructs each device how to handle packets, the way a Label Distribution Protocol sets up forwarding tables based on labels, then all the IP, UDP, RTP, and other addresses contribute nothing to how the packet finds its way through the network. Only the label matters.

To save bandwidth, start at the entry point of the network.  There replace all the IP-related headers on a packet with a token, very much like the MPLS label. The addresses associated with the token are added back to packets at the exit point from the network.

The Frame Relay Forum worked out most of the packet formats for voice and signaling 15 years ago in the implementation agreement (FRF-11)) for voice over FR, but routing remained proprietary to each vendor. The IA needs a few tweaks but it boasts some interesting features.

As the GPS says, "Recalculating" the bandwidth for a 6-byte label:

6 bytes x 100 frames/s x 8 bits/byte = 4.8 kbit/s

For HD voice compare 37 kbit/s vs. 103 kbit/s.  FRF-11 defined a format to put payloads from multiple channels in one packet.  That saves a little in the headers but seriously cuts the packets per second burden on switches.

With centralized SDN call setup, the packet handlers don't need any information beyond how to handle a packet with a given token. The exit device restores headers to the packet as it leaves the network.

If you want to get a jump start on saving bandwidth--the SDN way--I can point you to sources for well proven VoFR protocol stacks.  They have some bonus features that makes packet handlers much more productive.

This approach looks in some ways like header compression, MPLS, and Frame Relay.  But we'll think up a new name for it as historically we have for every change in network technology.

NOTE: a patent application filed in the US covers portions of the technology described.

Flanagan Consulting Can Help You

    We understand not only the technology of networks, but also
    the surrounding business processes:  procurement, bid
    preparation/analysis, statements of work, financial analysis,
    consensus building around a solution, white papers, and product
    Find out more:   call +1.703.242.8381  or email

Flanagan Consulting Supports Litigation Professionals
    Several associates are experienced in analysis of patents, trademarks,
    contracts, and other intellectual property related to IT and communications.
    We have assisted attorneys preparing claims, depositions, and testimony.
    Queries to +1.703.855.0191.

Advertise Here... reach over 2700 interesting people in Telecom and IT networks.
    For details, call the Publisher at +1.703.855.0191

Responses to ViewsLetter and Subscriptions
    Mail is welcome when addressed to
    You may unsubscribe at any time here.

Special thanks for supporting ViewsLetter to,
    your best source for communications tutorials and white papers.

Flanagan Consulting

Creative Network Solutions
From Desktop to Data Center

3800 Concorde Parkway, Suite 1500, Chantilly, Virginia 20151 USA
Ph:  +1.703.242.8381    Fx:  +1.703.242.8391
Flanagan Consulting is a Service Mark of W. A. Flanagan, Inc.

"Beware of false knowledge; it is more dangerous than ignorance."
                                       --George Bernard Shaw