|
Calculating VOIP BandwidthCalculating trunk requirements in the voice world meant determining the call load during the peak hour and using Erlang formulas, or simulation models, to derive the appropriate number of trunks for a given blockage factor or grade of service. In the VOIP world, the total bandwidth required to handle peak hour calling across the IP network must be determined. This newsletter describes a calculation process that can be used to estimate the data network bandwidth required per VOIP call and for the total system. In the late 1800s and early 1900s, two mathematicians developed theories to describe the occurrence and handling of events; this would have a huge impact on telecommunications management, even to this day. Simeon Poisson was responsible for developing a model that described the occurrence of random events, which could be used to predict the number of events that would occur in a given period when these events were not dependent on one another. This is known as the Poisson distribution model and described how random events tend to occur in bunches. Predicting Trunk RequirementsA few years later, Agner Kraruo (A.K.) Erlang used the Poisson distribution model to describe telephone calling demand while developing his theory for predicting the number of telephone trunks required to handle this demand. At that time, A.K. Erlang was working for the Copenhagen Telephone Company in 1908. He developed a formula, called the Erlang-B formula, which predicted the probability that a defined number of calls arriving would be greater than a defined number of available trunks to handle those calls causing blocked calls. In other words, the probability that there would be too many calls for the number of trunks. This probability of blockage formula assumed that the blocked calls went away and didn’t reappear for a long time – this is not completely accurate, but close enough to make the model simple and workable.
The calling load, besides fitting into a Poisson distributed arrival pattern, is defined in terms of the average number of calling minutes measured over an hour. The hour selected is usually the busiest, or peak hour, as the number of trunks require to satisfy that time frame will handle all others even better. To express the load, one could use call-minutes per hour, call-seconds (CS) per hour, hundreds of call-seconds per hour (CCS), or Erlangs. An Erlang is a measure that assumes the base is an hour, or 3600 seconds; for example, 10,000 call-seconds per hour is equivalent to 2.78 Erlangs (10,000 divided by 3600). Erlangs are the input to the Erlang-B model. By running this formula using many combinations of calling traffic (Erlangs) and available trunks, one could produce a set of tables that show the relationship of the call load, probability of blockage, and trunk utilization, as shown by the sample table. Hours First Attempt means peak hour load, with an hour of calling per peak hour being an Erlang. Hours Connected and Hours Overflow defines the traffic that got through and the traffic that did not during this hour. Lines mean the number of trunks available, beginning at two. For many years, engineers used tables like this one contained in a large book of such tables; however, computer programs are readily available today to provide this information in a variety of formats.
There are two other factors to explain in this sample table. One factor shown is called Grade of Service (GOS), a value that must be selected by the designer. GOS is the level of blockage that is acceptable for your system. It is the probability (P) of a call being blocked, expressed as a percentage. Because of the nature of the formula, a GOS level must be stated and 5% - 10% is a commonly used value when determining the number of access trunks required for a PBX, for example. A 5% GOS may also be stated as P05.
This formula can be used to determine the number of trunks required in a two-way system; that is, trunks carrying traffic inbound from the network as well as outbound from the office, or two-way trunks. In this case, the traffic level considered, or Erlangs, would represent the total for both directions. This will provide a good first step of the solution; however, the actual trunk selection method used by switches at each end would have to be considered. The formula will also predict the number of T1 channels required as a T1 channel would equate to a trunk. Later on in his career, A. K. Erlang enhanced his model to show the effects of callers waiting in a queue for an operator, such as being on hold for a call center. This formula, called the Erlang-C model, can be used to determine the number of operators required and the wait time of the caller depending upon the call volume and number of operators available over the average hour being studied. To be reasonably accurate, these probability formulas assume that the call volume is substantial (not 1 or 2 an hour) and that the traffic load’s arrival rate had been operating at that level for some time (not slowly ramping up to that level). The Erlang-C formula, being a queuing formula (for more information on the use of queuing theory in telecommunications see newsletter Applying Queuing Theory to Network Design), assumes that the call duration times are distributed in an exponential manner; that is, they are not constant for each caller and they are not dependent upon the duration of other calls. The message here is that these formulas are based upon certain assumptions that approximate the real world events, so their output is a good approximation of the real system. With this knowledge, they can be employed effectively while being simple to use and cheap. To obtain more accurate results, either for very large systems or for situations that are not the “norm”, computer simulation models should be considered. VOIP Requires an Extra StepVOIP is a different animal. The question in these systems is not how many trunks are needed to handle calls but how much data network bandwidth is required - how many T1 trunks are require? The answer to this question is more complex to determine than it seems. As we all know, the (Telco) standard way to use a digital T1 trunk for voice is to put digitized calls on one of the 24 available multiplexed channels of the T1 - one call per channel. However, VOIP traffic is defined by packets not calls and packets are not identified by channels but by their IP or other address. Let’s first review how this is done and then how to calculate the needed data network capacity or bandwidth. Voice is first converted into a bit stream by a codec, or digitizing mechanism, and placed into data packets. The codec type used determines the basic data rate for the call, which is usually one defined by the ITU-T’s (International Telecommunications Union – Telecommunications standard’s section) G.700 series standards. Which codec type to use depends on the application; for example, calls going around the office on the high-speed LAN would use a high-quality 64K bps basic or broadband codec while calls going over an expensive wide area network would use a slightly lower quality 8K bps codec to keep costs down.
Each packet generated carries protocol overhead bytes along with the voice content bytes, which must be combined to determine the total bandwidth required per call. All packets will carry the IP header (Internet Protocol) field, the UDP header (User Datagram Protocol) field and the RTP header (Real Time Protocol) field, which combined adds 40 bytes to the packet.
The calculation to determine the bandwidth required per call is straight forward, as shown. Here we are assuming that the calls will be going from IP phone to IP phone over the in-house Ethernet LAN. The selected sample size, say 20 ms, determines the number of packets/frames per second that must be generated,50 per second. Each frame will carry the appropriate amount of overhead bytes - 26 using Ethernet plus 40 for other protocols for a total of 66 bytes per frame for a total of 3300 bytes per second of overhead. Converting this to bits (8 bits per byte) yields 26,400 bits per second of bandwidth required to carry just the overhead. To this is added the codec’s voice digitization coding rate (G.711 generates 64k bps) to yield the total bandwidth required of 90.4K bps (26.4k bps plus 64k bps or 90.4k bps) to handle a VOIP call in one direction.
Another common problem is the determination of the access bandwidth required to carry VOIP calls out of the office to the IP carrier’s network. Here the assumption might be the use of the PPP packet, 20 ms samples, and 8K bps codec. This calculation shows a capacity of 27.2K bps would be required in each direction to handle a call.
Incorporating the Erlang FormulaThese calculations provide the bandwidth required for a single VOIP call while it is in progress. The final step is to determine the overall bandwidth required to support all calls during the peak hour. To accomplish this, the standard Erlang-type analysis must be employed; that is, determine the total calling traffic (number of calls times the average length of a call) during the peak hour and then calculate the number of trunks required for a given grade of service, as demonstrated above. Each required trunk using the Erlang formula would represent a continuous talk path available to handle the offered calls at the GOS specified, which in the VOIP world would be represented by the IP bandwidth required to carry a conversation as calculated previuously. For example, if 10 trunks were required to handle a certain call volume at a P05 grade of service, then the bandwidth required to support VOIP to and from the carrier’s IP network at that same GOS (using PPP, 20 ms samples, and 8K bps codecs) would be 272k bps (27.2k bps per call times 10 trunks or continuous paths.). This represents full-duplex bandwidth or the bandwidth required in both directions (272k in each direction). An additional load factor should be added to account for some call signaling/control traffic that may occur during the call. Optimizing the ProcessThis should give you more than enough bandwidth to handle the VOIP traffic; however, there are some adjustments that can be made to this calculation, which depend upon other assumptions or design factors. The bandwidth requirement can be reduced somewhat by two measures. One would be an assumption for the use of silence suppression techniques – if a person is not talking, no packets will be generated. This factor, conservatively, varies between a 20%-35% reduction. Furthermore, header compression could be employed, which would reduce the IP/UDP/RTP header size from 40 bytes to 2 bytes over certain links. The VOIP protocol selection can also influence the overhead and throughtput factors as well; for example, the IAX2 protocol developed for use with the open-source Asterisk IP-PBX software supports multiple call samples in a single packet. Such a technique provides more voice for the same overhead per packet. The bandwidth requirement might be increased as well. This could occur if additional overhead fields are added to the frame and flow control measures are incorporated in the network, such as to support security and quality of service techniques. Similarly, the overhead factor for the IP control field's size will have to be changed when moving from the current IP version 4 protocol to the newer IP version 6 protocol. This will add another level of complexity to the bandwidth prediction process as IP version 6 supports the use of many, optional headers, which will make this field size highly variable in the future. This calculation process also assumes that the call contains only voice content; however, it is possible that tones, music, or video content occur during the call as well. Different content will use different codecs, which can be dynamically adjusted via the signaling protocol and Real Time Control (RTP) protocol mechanisms throughout the call's duration. The Erlang models have been around for a long time, used extensively in telephone systems engineering and are also applicable as part of the tool set for VOIP systems design. The processes described above are very useful for rough capacity prediction, network cost analysis and troubleshooting and can be modified to include other events and traffic types. Further TrainingThese types of tips and insights can be found in all training classes provided by McGuire Consulting. The high quality nature of these courses is based on the many years of work and training experience of the author, Jay D. McGuire. |
The trunk utilization pattern in this table, as described by "Hours Connected Traffic On Lines", assumes that the trunk selection process starts at the first trunk and rolls over to the next trunk down the list until an available one is found. This is the reason the utilization values are distributed in the manner shown. By using the GOS factor and the trunk utilization factors, one can best select the number of trunks to install for a given load as the trunk utilization will show the actual amount of traffic carried, especially for the very last trunk in the selection process.This particular table format is a very useful one because of this utilization factor data.
The amount of digitized voice carried in a packet ranges from 20 ms to 50 ms of voice content, called a sample. This selectable parameter allows the designer to choose between high resolution and high bandwidth (20 ms samples size) or lower resolution and lower bandwidth (50 ms sample size) options. Voice is a real time application, so the number of samples has to add up to one second’s worth per second. Therefore, a 20 ms sample size requires the generation of 50 packets per second and a 50 ms sample size requires generating 20 packets per second.
Here’s the tradeoff: a small voice sample size (20 ms) requires the transmission of more packets, the packets take less delay time to create, and if one is lost there is less impact on the resulting voice quality but a large sample size (50 ms) requires the transmission of fewer packets, takes a longer delay time to create, and if one is lost there is a bigger impact on the resulting voice quality. This translates into bandwidth required versus voice quality.
Additional fields added will depend upon the frame-level (Layer 2 for those who are into data communications architectures) protocols used and any adjunct control fields added. Typically, the voice packet is encapsulated in an Ethernet frame for transport around the office and PPP (Point-to-Point Protocol) frames for transmission out over a WAN link. The Ethernet frame includes 26 bytes for a typical implementation and the PPP adds 8 bytes to the packet. Therefore, the total overhead that is added to the voice content per packet is 528 bits (40 bytes plus 26 bytes times 8 bits per byte) when using Ethernet and 384 bits (40 bytes plus 8 bytes time 8 bits per byte) when using PPP. There is also inter-packet spacing time to consider, but we won’t.
