As use of SIP trunking proliferates, IT organizations face the big challenge of calculating bandwidth requirements appropriately, as problems will crop up whether they provision too little or too much bandwidth.
If you provision too much bandwidth, IT won't meet its return-on-investment expectations for SIP trunking and you'll see higher-than-necessary total cost of ownership. On the other hand, too little bandwidth will result in blocked calls, which means more abandoned calls and less productive contact center and help desk agents. This, in turn, might harm the enterprise's reputation for service. This is not desirable, since regaining a good reputation can be difficult and costly.
Penalties for Poor Sizing
If you're designing SIP trunk connections, you have to consider six points to ensure an effective and efficient SIP trunk connection:
• Overdesign wastes money
• Overdesign requires more bandwidth, but does not improve performance
• Overdesign means overspending on SIP licenses, which cannot be returned for credit
• Underdesign blocks calls which reduces revenue and profits • Underdesign frustrates customers
• Underdesign of bandwidth affects call quality
• Overdesign wastes money
• Overdesign requires more bandwidth, but does not improve performance
• Overdesign means overspending on SIP licenses, which cannot be returned for credit
• Underdesign blocks calls which reduces revenue and profits • Underdesign frustrates customers
• Underdesign of bandwidth affects call quality
Determining Trunk Capacity
The process of calculating the required trunk capacity starts with determining the grade of service (GoS), which is the probability of a caller experiencing a busy signal at a call center, enterprise office, or any other location designed to receive 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 necessary to support the number of SIP trunk sessions determined by the Erlang calculations. Trunks in this case are the number of lines/sessions needed to carry the calls.
Erlang B Calculations
As I mentioned, SIP trunking designers should start by using Erlang B calculations to determine the number of trunks required for a call traffic load. Erlang B is essentially the standard in the telephony industry, and often comes into play for call center and help desk scheduling. The formula assumes that an unsuccessful call (the call is blocked, the caller receives a busy signal), is neither queued nor retried but rather is lost forever. The formula also assumes calls arrive independently and randomly of the time since the last call.
Erlang B tends to underestimate the number of sessions required. A variation, the Erlang B Extended formula, factors in retry calls. It can account for 10% to 70% of callers who will immediately retry if their first attempt fails. This formula will produce a slightly greater number of trunks required to carry the call load.
You can use the Erlang B and Erlang B Extended formulas to calculate any one of the following three factors if you know or can predict the other two factors:
• Busy hour traffic, or BHT: the number of calls or traffic load during the busiest hour of operation; also called the Erlang load
• Blocking (busy signal GoS): the percentage, for example 1%, of calls blocked because a line is not available
• Lines: the number of sessions in a trunk group; one session can carry one call at a time
• Busy hour traffic, or BHT: the number of calls or traffic load during the busiest hour of operation; also called the Erlang load
• Blocking (busy signal GoS): the percentage, for example 1%, of calls blocked because a line is not available
• Lines: the number of sessions in a trunk group; one session 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 lower traffic volume. This means that the callers will experience fewer blocked calls (busy signals) and better service the rest of the day. The worst-case performance -- GoS -- is delivered during the busy hour.
Using an Erlang B Calculator
This is how to use the Erlang B calculators. Your 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 0.01 (1% busy), which means that 99% of the calls are answered and do not receive a busy signal. A GoS of 0.001 means that 99.9% of calls do not receive a busy signal. When designing for IVR systems, account for a very high probability -- 99.9% or better -- that the call is not blocked.
Next, you must measure or estimate the traffic load in Erlangs/BHT. One Erlang is equivalent to one session/line busy for one hour. To calculate the Erlang load, you must determine the average length of a call in minutes. You also need to know the number of calls expected during the busiest hour of the day.
The Erlang load (BHT) = CAR X H/60, where:
• Call arrival rate (CAR) is the number of calls arriving during the busy hour
• The average call length or holding (H) time is measured in minutes
• Call arrival rate (CAR) is the number of calls arriving 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 is 100x3/60, or 5.0 Erlangs (BHT)
This is equivalent to five sessions operating 100% of the time, a condition that produces a high number of blocked calls. Therefore the number of sessions must be greater than 5 to provide a better GoS.
With a GoS of 0.01 and an Erlang load of 5 now known, use an Erlang B calculator (such as this one), and enter 5 into the BHT (Erlang load) and 0.01 in the Blocking field. You'll see that 11 sessions are required for this traffic load and GoS. This works out that each session is operating 45% busy. If the design goal for the same network is restricted to 0.001 GOS, i.e., 99.9% of the calls are not blocked, then 14 sessions would be required.
VoIP Bandwidth Calculations
A number of factors come into play when determining bandwidth requirements for a VoIP session: compression technology, packet overhead, and network protocol in use.
The varying designs of packet size, voice compression choice, and header compression can make it difficult to determine the bandwidth for a voice call. Most providers have selected 20 millisecond or 30ms of speech for the payload size. Your SIP trunk provider should be able to give you a table like the one below for use in calculating the bandwidth requirements when using its service.
Your provider's bandwidth requirements may be greater than shown above. A good rule of thumb is to reserve at least 27 Kbps of SIP session bandwidth per call for 8 Kbps G.729 compressed voice. For G.711, reserve at least 83 Kbps of bandwidth per session. Some providers recommend 100 Kbps per session/call.
Do not calculate the required number of sessions with the minimum capacity in mind. Rather, you should always round up to a largernumber of sessions and bandwidth. Traffic estimates are just that, estimates. It is better to increase the bandwidth than to have dissatisfied callers. Experiment with voice quality to ensure you've implemented adequate bandwidth.
I'll be presenting a full discussion of SIP trunking calculation at the Enterprise Connect 2015 conference taking place March 16 to 19 in Orlando. Join me for the session, "Right-Sizing Your SIP Trunking Procurement," on Wednesday, March 18, at 3:45 p.m.
If you haven't yet registered for Enterprise Connect 2015, do so now using the code NJSPEAKER and receive $300 off an event pass.
