SIP Trunk Bandwidth: How Much?SIP Trunk Bandwidth: How Much?

SIP trunking is financially attractive. But it is important to size your SIP trunking to support the calling services that your enterprise requires

The proliferation of SIP trunking makes the bandwidth calculations for those SIP trunks an issue that the IT organization must resolve. Too much capacity and money is wasted. Too little capacity and calls will be blocked, callers will abandon the call, the enterprise agents will be less productive and the enterprise’s reputation for service may be harmed.

The process of determining the required trunk capacity starts with determining the Grade of Service (GoS), which is the probability of a caller getting busy signal at a call center, enterprise office or any other location designed to receive calls, whether voice or Interactive Voice Response (IVR) calls. This first step uses an Erlang B formula and calculation. The second step is to calculate the bandwidth required to carry the number of SIP trunks/lines determined by the Erlang calculations. Trunks in this case are the number of lines needed to carry the calls.

Erlang Calculations
The number of trunks required for a call traffic load can be calculated using Erlang B calculations. The Erlang formulas were created by Agner Krarup Erlang, and. have been used for about 90 years for telephone network capacity planning. There are several other formulas with slightly different assumptions, but Erlang B continues to be used in the telephony industry.

Erlang B is a formula that can be used in call center scheduling. The formula assumes that an unsuccessful call (the call is blocked, the caller gets a busy signal), is not queued or retried; it is lost forever. The formula also assumes that call attempts arrive following a Poisson distribution, so calls are assumed to arrive independently of the time since the last event.

Because Erlang B doesn't assume calls are retried, it tends to underestimate the number of trunks required. A variation, the Erlang B Extended formula, can account for 10% to 70% of the callers who will immediately retry if their calls do not go through. The Extended formula will produce a slightly greater number of trunks required to carry the call load.

The formulas (Erlang B and Extended) can be used to calculate any one of the following three factors if you know or can predict the other two factors:

* Busy Hour Traffic (BHT): the number of hours of call traffic during the busiest hour of operation, also called the Erlang load. * Blocking (busy signal Grade of Service (GoS)): the percentage, for example 1%, of calls that are blocked because not enough lines are available.

* Lines: the number of lines in a trunk group. One line can carry one call at a time.

The busy hour is the heaviest traffic period during the day. By designing for the busy hour, callers will experience call blocking at the enterprise’s desired rate. Other hours of the day will have less traffic volume. This means that the callers will experience fewer blocked calls (busy signals) the rest of the day. The blocking performance will be better for all the hours outside the busy hour, delivering a better GoS. The worst case performance (GoS) is delivered during the busy hour.

The following is how to use the Erlang B calculators. The first determination is more of a business issue: How often is it acceptable for the caller to get a busy signal? Most calculations start with a GoS of .01 (1% busy) which means that 99% of the calls are answered and do not receive a busy signal. A GoS of .001 means that 99.9% of the calls do not receive a busy signal. The design for Interactive Voice Response (IVR) systems should have a very high probability that the call is not blocked—i.e., 99.9% or better.

Next, the traffic load must be either measured or estimated in Erlangs/BHT. One Erlang is equivalent to one trunk/line busy for one hour. To calculate the Erlang load, the trunk designer must determine the average length of a call in minutes. The number of calls expected during the busiest hour of the day is also necessary. The Erlang load (BHT) = CAR X H/60.

Where: * Call Arrival Rate (CAR) is the number of calls during the busy hour
* The average call length or Holding (H) time is measured in minutes

An example calculation: CAR = 100 calls and H = 3 minutes Erlang load for this situation for 100 X 3/60 or 5.0 Erlangs (BHT)

This is equivalent to 5 trunks operating 100% of the time, a condition that produces a high number of blocked calls. Therefore the number of trunks must be greater than 5 to provide a better GoS. With a GoS of .01 and an Erlang load of 5 now known, go to http://www.ansapoint.com/calculator/erlb/ and enter 5 into the BHT (Erlang load) and enter .01 in the Blocking field. The result is that 11 trunks are required for this traffic load and GoS. This works out that each trunk is operating 45% busy. If the design goal for the same network is tightened to .001 GOS, i.e., 99.9% of the calls are not blocked, then 14 trunks would be required, not 11 trunks.

Now try a CAR of 1,000 calls and H of 3 minutes (Erlang load (BHT) of 1,000 X 3/60 = 50.0) in the same calculator, and the result is 64 trunks/lines. This works out that each trunk is operating 78% busy. Thus, the greater the number of trunks/lines, the more efficient the call center agents and/or IVR.

VoIP Bandwidth Calculations
The bandwidth that is needed for VoIP transmission will depend on a few factors: the compression technology, packet overhead, network protocol in use and whether silence suppression is used.

There are two primary solutions to delivering IP network performance for voice: bandwidth allocation and QoS. QoS is not discussed in this article. How much bandwidth to allocate depends upon:

* Packet size for voice (20 to 320 bytes of digital voice)
* Codec/compression technique (G.711, G.729, G.723.1....)
* Header compression (RTP + UDP + IP), which is optional
* Layer 2 protocol used, i.e., PPP, Frame Relay and Ethernet
* Silence suppression/voice activity detection assumptions

The results of three G.711 and three G.729 calculations are contained in the next table, "Minimum Bandwidth requirements" The table illustrates three points:

* Bandwidth requirements reduce with compression, G.711 vs. G.729.
* Bandwidth requirements reduce when longer packets (i.e., more bytes per packet) are used, which reduces packet overhead and bandwidth requirements.
* Compressing the RTP, UDP and IP headers (cRTP) is most effective when the packet also carries compressed voice (G.729).

Minimum Bandwidth Requirements

The varying designs of packet size, voice compression choice and header compression can make it difficult to determine the bandwidth for a voice call. Many providers have selected 20ms or 30ms of speech for the payload size. The SIP trunk provider should be asked to provide a table like the one above for their service, for use in calculating the bandwidth requirements. The provider's bandwidth requirements may be greater. A good rule of thumb is to reserve at least 27 Kbps of SIP trunk bandwidth per call for 8Kpbs G.729 compressed voice. If G.711 is used, then reserve at least 83 Kbps of bandwidth per call.

Silence suppression assumes that that both parties of a call do not speak at the same time. On average, a voice call can have as much as 70% of silent time. Cisco recommends that the designer assume that silence suppression only reduces the bandwidth requirement by 30%. Cisco also recommends that silence suppression should be used on trunk groups with greater than 24 lines.

First, experiment with the silence suppression turned off. Then turn it on and observe if there is voice quality degradation. The degradation may be more than is acceptable. When music-on-hold is in use, then silence suppression may not work well. The use of fax and PC modems through a SIP trunk may negate the use of silence suppression. Bottom line: Be cautious with the application of silence suppression.

The following table, "Sample SIP Trunk Requirements," illustrates the end result of these calculations. The table assumes that the calls are 5 minutes long, the packets contains 20ms of digitized speech and the Grade of Service (GoS) is .01, which means that 1% of the calls are blocked. The number of calls per hour are shown in the left column matched with the (BHT) or Erlang load. The next column to the right contains the number of SIP trunks necessary to carry the load. All of the bandwidth entries define the minimum bandwidth required. Refer to the "Minimum Bandwidth Requirements" table. The SIP trunk provider may require more than is shown in the table.

Sample SIP Trunk Requirements
(5 minute calls, 20ms packets and GoS of .01)

Several observations can be drawn from the table.:

* As the BHT/Erlang load increases, the number of SIP trunks required increases more slowly. Doubling the call rate from 100 to 200 calls/hour does not double the number of SIP trunks. Only 26 trunks are required, not 32 SIP trunks.

* Moving from G.711 to G.729 reduces the bandwidth requirements by over 60%.

* Using compressed RTP does reduce the bandwidth for G.711, but only by about 19%. This may not be worth the effort.

* Compressed RTP combined with G.729 delivers the lowest SIP trunk bandwidth requirement.

* When compressed RTP with G.729 is compared to uncompressed RTP with G.711, the bandwidth reduction is 85%.

Designers should not calculate the required number of trunks with the minimum number in mind. Always round up to a larger number of trunks. Traffic estimates are just that, estimates. It is better to increase the bandwidth than to have dissatisfied callers. Experiment with voice quality to ensure that adequate bandwidth is implemented.

Every SIP trunk provider appears to support the uncompressed G.711 and most support G.729. However, not every provider may accept compressed RTP packets in all situations. The delivery of compressed RTP may not be supported at the enterprise SIP trunk interface (PBX or IP PBX).

It is very likely that a Session Border Controller (SBC) will be placed between the enterprise and the SIP trunk provider. Investigate the SBC to learn if the SBC can perform the RTP compression and decompression and G.711-to-G.729 transcoding (conversion).

SIP trunking is financially attractive. SIP trunk providers also offer other features like least cost routing and bundled national and international services. SIP trunking cannot be ignored. But it is important to size your SIP trunking to support the calling services that your enterprise requires, and that your customers and other users have become accustomed to with the legacy systems.