Bandwidth DemandBandwidth Demand

In my posts I have been working through a QoS implementation for voice or video conferencing. Last week I talked about Classification, where we assign a priority to traffic streams and mark them so that the network routers know how to handle the traffic. When working with an enterprise, the next step I take in this process is to determine the Bandwidth Demand.

In my posts I have been working through a QoS implementation for voice or video conferencing. Last week I talked about Classification, where we assign a priority to traffic streams and mark them so that the network routers know how to handle the traffic. When working with an enterprise, the next step I take in this process is to determine the Bandwidth Demand.Demand means how much bandwidth will the application want to use. If we are deploying 10,000 telephones, how many calls can we expect on each network link at any given time? And how much IP traffic will this generate? Getting these answers is important, because the link QoS will only allow a fixed amount of high priority bandwidth, and we want to make sure that value is high enough to support the traffic we are planning to create.

The first step for both voice and video is to estimate the number of calls that will occur simultaneously. For voice traffic, there is a well documented process for estimating how many users will be on the phone at the same time, invented by Mr. A.K. Erlang. Take a look at Wikipedia and at www.erlang.com for descriptions, tools and methods. These estmations need to be done for specific WAN links.

Video conferencing calls need a different approach. Desktop-based video may have similar characteristics to the telephone since we use it in a similar ad-hoc manner. But room-based video conferencing is scheduled, and calls usually last from 60 to 90 minutes. A conservative estimate assumes that all the video systems are in use during the busy hours of the day, and thus their total bandwidth must be accomodated. Most telepresence environments are being designed with this assumption because enterprises are finding that those rooms are very heavily used. Remember to make the usage estimates for the busy hour(s), and not just calculate an average over the whole day.

Step 2 is to determine how much bandwidth will be required for each call. For voice calls this usually means just knowing which codec will be used. G.711 consumes about 80 Kbps per call, and G.729 consumes about 31 Kbps per call. Use of header compression on the WAN links can reduce these values, and so should be considered.

Video conferencing endpoints can choose different call rates, which affect the quality of the video image. Standard video conferencing calls range from 128 Kbps to 768 Kbps, high definition (HD) video ranges from 1 Mbps to 4 Mbps and telepresence suites demand as much as 20 Mbps per call. For video I recommend that users look at the quality of the video and determine for themselves what call rate is appropriate for their business, since the bandwidths are so significant and substantial that recurring costs may be incurred to support video bandwidth.

So the total bandwidth demand for each WAN link can now be determined, based on the number of simultaneous calls expected and on the bandwidth needed for each call. These values are a key input into the QoS deployment process, and for video may also be a key input into the budgeting process to ensure the company can support the required bandwidth.