Vivinet Assessor’s Bandwidth Modeling feature acts as a bandwidth calculator to aid in capacity planning. By taking into account a particular link’s capacity and utilization, plus optional VoIP parameters to conserve bandwidth, such as the use of RTP header compression (cRTP), Vivinet Assessor determines whether that link would most likely be capable of carrying high-quality VoIP traffic.
One way to use Bandwidth Modeling is to try out different codecs, which are represented by the various Vivinet Assessor call scripts you can select. For more information, see Section 7.11.2, Reviewing Codec Types. After modeling utilization scenarios with different codecs, you could then run a VoIP Quality assessment that includes call groups using each codec and compare the quality results for each codec.
Vivinet Assessor provides two ways to create models of link capacity and utilization after a VoIP implementation:
creating a modeled link based on a monitored link. Once you run a Utilization assessment, you can use the links whose utilization you monitored to create modeled links. This method provides more information and an accurate link model because it uses a known link name, link type, and real utilization statistics to project bandwidth needs after VoIP traffic is added.
creating a generic modeled link from scratch. A dialog box lets you fill in information to project the necessary link capacity for a VoIP usage scenario. Without utilization information, this link modeling works like a simple bandwidth calculator.
Before you proceed with Bandwidth Modeling, it is helpful to understand some of the concepts used to design this feature. The following topics provide guidance.
When you set up Bandwidth Modeling, you are asked to specify the target utilization for the link you selected. A good rule of thumb is to keep the target link utilization for links that will carry VoIP traffic at 75% of link capacity. However, you may adjust this utilization level lower or higher in specific cases.
Vivinet Assessor rates your link utilization according to the utilization thresholds you set, but it uses defaults of 50% (Good) and 75% (Acceptable) for the Peak Bandwidth Utilization statistic. For more information, see Section 5.2, Determining Assessment Result Ranges.
In the Create Modeled Link dialog box, the default Target Utilization value is equal to 75% of the link’s capacity. For example, 48 kbps on a 64 kbps serial WAN link represents 75% utilization. You might, therefore, want to reduce the Target Utilization data rate to more closely represent average, not peak, utilization.
When you perform Bandwidth Modeling, you can specify the anticipated number of calls to model for a link using two different units: number of simultaneous calls, and Erlangs.
PBX systems can typically generate reports showing call traffic using Erlangs as the units. Named after the Danish telephone engineer A.K. Erlang, the Erlang is a unit of traffic density in a telecommunications system. One Erlang is the equivalent of one call, including call attempts and holding time, in a specific channel for 3600 seconds in an hour. The 3600 seconds need not occur, and generally do not occur, in a contiguous block. An Erlang value of “1” means that the telephone line is 100% busy.
Erlangs are used to show the Busy Hours Traffic, or BHT, a term that refers to link utilization under conditions of stress. If you enter the number of calls to model in Erlangs, Vivinet Assessor also lets you model bandwidth requirements based on the blocking percentage, which refers to calls that cannot be completed. A blocking percentage of 1% indicates that 1 call in 100 is blocked because all lines are busy. This rate can be calculated using Erlang B, A.K. Erlang’s calculation that lets you determine any one of the following three factors if you know or can predict the other two:
Busy Hours Traffic (BHT), or the number of hours of call traffic during the busiest hour of operation. Expressed in Erlangs.
Blocking %, or the percentage of calls that are blocked because insufficient lines are available
Lines, or the number of voice paths in a specified trunk group. Vivinet Assessor assumes this is the number of calls.
Based on your input in the Erlangs field (for BHT) and in the Blocking % field, which defaults to 1%, Vivinet Assessor calculates the amount of bandwidth needed: it finds the number of lines you need for your anticipated traffic on a traditional (PSTN) telephone network and then uses an algorithm to translate the number of lines into the required amount of IP network bandwidth.
The Vivinet Assessor bandwidth calculations take two-way conversations into account, and if there is not quite enough bandwidth for a call, the call capacity on a given link is rounded down.
If your preliminary results from Bandwidth Modeling indicate that you need more bandwidth, you can try a bandwidth-conservation technique. Vivinet Assessor can help you determine whether such a strategy will help you run high-quality VoIP calls over your existing equipment. One such strategy that is tailor-made for VoIP is RTP Header Compression.
RTP Header Compression, or cRTP, is a technique used by routers on WAN links to compress the VoIP packet header. Because the Realtime Transport Protocol (RTP) rides on top of UDP and IP, the header in a typical VoIP RTP packet often exceeds the payload in size. The combined size of the IP, UDP, and RTP headers, 40 bytes, adds a significant amount of overhead to VoIP transmissions. VoIP packets can therefore consume a great deal of bandwidth on lower-capacity WAN links, especially when you consider that VoIP traffic flows in both directions.
Because most of the RTP header is unnecessary and repetitive, it can be largely eliminated by routers when VoIP packets travel over a WAN. Here is an illustration:
When cRTP is activated, the combined headers are compressed to about four bytes. The bandwidth savings can allow you to put more VoIP calls on a given link. But cRTP exacts a trade-off: the compression consumes more router CPU time and adds latency to the VoIP transmission. Therefore, you should only deploy cRTP on links of 512 kbps or more.