CCDA 640-864 Official Cert Guide - Chapter 14 Summary

Traditional Voice Architectures

Erlangs

An Erlang is a theoretical unit of measurement used to define the trunking (voice path) utilization in a voice application or environment. Erlangs values are used in Erlang form aggregate trunk usage for a system and do not apply to any specific trunk or call. The hour used for the Erlang calculation should be the busiest hour (peak hour) in the day.

If a group of users makes/receives 20 calls in the average busiest hour and each call lasts and average of 10 minutes, the Erlangs are calculated as follows:

20 calls per hour * 10 minutes per call = 200 minutes per hour

Traffic volume = (200 minutes per hour) / (60 minutes per hour) = 3.33 Erlangs

There are three common Erlang models:

• Erlang B is a formula that estimates the amount of trunking capacity required given an Erlang value (busy-hour traffic) and a desired Grade of Service (also known as blocking percentage). It is the most common model used. Extending the previous example, 3.33 Erlangs (BHT) and a GoS of 1 percent results in an Erlang B value of nine trunks required. An Erlang B calculator can be found at www.erlang.com/calculator/erlb./
• Extended Erlang B adds a “retry” percentage to the Erlang B model. It assumes that some blocked or failed calls will be reattempted, and therefore additional load is added.
• Erlang C queues excess calls instead of blocking them. This model is used to calculate the number of agents required in a call center environment. It is based on measurements of handling time, expected call volumes, and the amount of time a caller spends with an agent. This model is used in call centers where calls are queued for service.

Centum Call Second

A call second is equivalent to a single call lasting 1 second. A Centum call second (CCS) represents one call occupying a channel for 100 seconds. It is the equivalent of 1/36th of an Erlang. In other words, 36 CCS equals 1 Erlang (3600 seconds). The typical range is around 6 to 12 CCS per port.

Busy Hour

The busy hour is the specific hour within a 24-hour period in which the highest traffic load occurs. Most calls are placed and are of longer durations during this hour. It is also called peak hour.

Busy-Hour Traffic

Busy-hour traffic (BHT) is the amount of voice traffic that occurs in the busy hour, expressed in Erlangs. It is calculated by multiplying the average call duration by the number of calls in the hour and then dividing that by 3600.

For example, if 300 calls occurred during the busy hour, with an average duration of 150 seconds, the BHT is calculated as follows:

BHT = (150 seconds * 300 calls per hour) / (3600 seconds per hour)

BHT = 12.5 Erlangs

Blocking Probability

In voice environments, it is nearly impossible or at least cost-ineffective to provision capacity so that no calls are ever blocked. Therefore, planning for a target GoS is an important aspect in voice networks. The term blocking refers to those calls that cannot be completed due to capacity constraints, usually during peak periods or call spikes.

The blocking probability is the probability that a call will be blocked. Blocking probability is described as a percentage of calls. For example, a blocking probability of 0.02 means that 2 percent of the calls will be blocked, or 20 per every 1000 calls.

Converged Multiservice Networks

IPT Design

Bandwidth

VoIP calls need to meet bandwidth and delay parameters. The amount of bandwidth required depends on the codec used, the Layer 2 protocol, and whether voice-activity detection (VAD) is enabled. For the purpose of call control, you can use the following bandwidth requirements (minimum values) for VoIP design:

■ G.729 calls use 26 kbps.

■ G.711 calls use 80 kbps.

When you’re designing for VoIP networks, the total bandwidth for voice, data, and video should not exceed 75 percent sustained of the provisioned link capacity during peak times. Best practice is to provision/plan for no more than one-third of any links for the priority queue/real time traffic. Use the following formula to provision interface speeds:

Link capacity = [required bandwidth for voice] + [required bandwidth for video] + [re-

quired bandwidth for data]

The remaining bandwidth is used by routing, multicast, and management protocols.

VAD

As we listen and pause between sentences, typical voice conversations can contain up to

60 percent silence in each direction. In circuit-switched telephone networks, all voice calls use fixed-bandwidth 64-kbps links regardless of how much of the conversation is speech and how much is silence. In multiservice networks, all conversation and silence is packetized. Using VAD, you can suppress packets of silence. Silence suppression at the source IP telephone or VoIP gateway increases the number of calls or data volumes that can be carried over the links, more effectively utilizing network bandwidth. Bandwidth savings are at least 35 percent in conservative estimates. VAD is enabled by default for all VoIP calls. In real-world practice, is it suggested that VAD be avoided because it creates quality issues and breaks applications such as fax and modem transmissions.

Notice that for G.729 bandwidth is reduced from 26.4 kbps to 17.2 kbps with VAD and to 7.3 kbps with VAD and cRTP enabled.

Calculating Voice Bandwidth

The CCDA test expects the designer to be able to calculate some basic voice bandwidth estimates. Use the following assumptions when calculating voice bandwidth:

• IP/UDP/RTP header uses 40 bytes.
• cRTP reduces the IP/UDP/RTP header to 2 or 4 bytes.
• The WAN Layer 2 header adds 6 bytes on a point-to-point circuit.
• Voice packet size = (Layer 2 header) + (IP/UDP/RTP header) + (voice payload)
• Voice packet per second (pps) = codec bit rate/voice payloadsize.
• Voice bandwidth (bps) = (voice packet size) * (pps).

As an example, calculate the WAN bandwidth used at a site that will have 10 concurrent

G.729 calls with cRTP and a default voice payload of 20 bytes.

From this description, we obtain the following:

• G.729 codec is used: 8 kbps codec bit rate.
• cRTP = 2-byte IP/UDP/RTP header.
• Default voice payload= 20 bytes * (8 bits/bytes) = 160 bits.
• WAN header = 6 bytes
• Voice packet size = 6 bytes + 2 bytes + 20 bytes = 28 bytes * (8 bits/byte) = 224 bits.
• PPS = 8 kbps / 160 bits = 8000/160 = 50 pps.
• BW per call = 224 (bits/packet) * 50 (pps) = 11200 bps = 11.2 kbps.
• BW for 10 calls = 11.2kbps * 10 = 112 kbps.

Here is a second example: Calculate the WAN bandwidth used by a G.711 calls with no

cRTP and a default voice payload.

From this description, we obtain the following:

• G.711 codec is used: 64 kbps codec bit rate
• IP/UDP/RTP header = 40 bytes
• Default voice payload= 160 bytes * (8 bits/bytes) = 1280 bits

• WAN header = 6 bytes
• Voice packet size = 6 bytes + 40 bytes + 160 bytes = 206 bytes * (8 bits/byte) =

1648 bits

• PPS = 64 kbps / 1280 bits = 64,000/1280 = 50 pps
• BW per call = 1648 (bits/packet) * 50 (pps) = 82400 bps = 82.4 kbps

Cisco has developed a tool, available on its website, which you can use to obtain accurate estimates for IPT design. The tool is the Voice Codec Bandwidth Calculator, and it is available at http://tools.cisco.com/Support/VBC/do/CodecCalc1.do.

Delay Components in VoIP Networks

The ITU’s G.114 recommendation specifies that the one-way delay between endpoints should not exceed 150 ms to be acceptable, commercial voice quality. In private networks, somewhat longer delays might be acceptable for economic reasons. The ITU G.114 recommendation specifies that 151-ms to 400-ms one-way delay might be acceptable provided that organizations are aware that the transmission time will affect the quality of user applications. One-way delays of above 400 ms are unacceptable for general network planning purposes.

Delay components are one of two major types: fixed delay and variable delay.

• Propagation delay
• Processing delay (and packetization)
• Serialization delay

Propagation delay is how long it takes a packet to travel between two points. It is based on the distance between the two endpoints. You cannot overcome this delay component. The speed of light is the theoretical limit. A reasonable planning figure is approximately 10 ms per 1000 miles, or 6 ms per 1000 m (6 ms per km). This figure allows for media degradation and devices internal to the transport network. Propagation delay is noticeable on satellite links.

Processing delay includes coding, compression, decoding, and decompression delays.

G.729 has a delay of 15 ms, and G.711 PCM has a delay of 0.75 ms. The delay created by

packetization is also a processing delay. Packetization delay occurs in the process of waiting for a number of digital voice samples before sending out a packet. Packetization delay is the time taken to fill a packet payload with encoded/compressed speech. This delay is a function of the sample block size required by the coder and the number of blocks placed in a single frame.

Serialization delay is how long it takes to place bits on the circuit. Faster circuits have less serialization delay. Serialization delay is calculated with the following formula:

Serialization delay = frame size in bits / link bandwidth in bps

A 1500-byte packet takes (1500 * 8) / 64,000 = 187 ms of serialization delay on a 64 Kbps circuit. If the circuit is increased to 512 kbps, the serialization delay changes to (1500 * 8) / 512,000 = 23.4 ms. Data-link fragmentation using link fragmentation and interleaving (LFI) or FRF.12 mechanisms reduces the serialization delay by reducing the size of the larger data packets. This arrangement reduces the delay experienced by voice packets as data packet fragments are serialized and voice packets are interleaved between the fragments. A reasonable design goal is to keep the serialization delay experienced by the largest packets or fragments on the order of 10 ms at any interface.

Var iable delays are

• Queuing delay
• Jitter buffer delay

As packets cross a network, they pass through several devices. At every output port of these devices, it is possible that other voice and data traffic is sharing the link. Queuing transmission on a link. It is the sum of the serialization delays of all the packets scheduled ahead of delayed packets. LFI is used as a solution for queuing delay issues. LFI is covered in the next section.

Packets might not arrive at a constant rate because they take different paths and have perhaps experienced congestion in the network. This variable delay is called jitter. The receiving end uses dejitter buffers to smooth out the variable delay of received VoIP packets. Dejitter buffers change the variable delay to fixed delay.

As the traffic load on a network increases, both the probability of delay and the length of the probable delay increase. The actual queuing delay depends on the number of queues, queue lengths, and queue algorithms. Queuing effects in VoIP networks are covered in the next section.

IPT Design Recommendations

The following are some best-practice recommendations when implementing IPT:

• Use separate VLANs and IP subnets for IP phones and data to provide ease of management and simplified QoS configuration.
• Use private IP addresses for IP phones subnets to allow for more security to voice devices.
• Place CallManager and Unity servers on filtered VLAN/IP subnets in the server access in the data center.
• Use IEEE 802.1Q trunking and 802.1P to allow for prioritization at Layer 2.
• Extend QoS trust boundaries to voice devices but not to PCs and other data devices.
• In the access layer, use multiple egress queues to provide priority queuing of RTP voice streams.
• Use DSCP for classification and marking.
• Use LLQ on WAN links.
• Use LFI on WAN links less than 768 kbps.
• Use CAC to avoid oversubscription of circuits.