Frame Relay Applications: Voice over Frame Relay - Page 2

By Cisco Press | Posted Feb 5, 2002
Page 2 of 3   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Voice Coders-Decoders (Codecs)
The issue with packetized voice is the ability of the sending and receiving voice codecs (coders-decoders) to be able to clock against each other to ensure the synchronization of the data flow. Two of the more common Voice over X (VoX) implementations are Voice over Frame Relay (VoFr) and Voice over ATM (VoATM). The reason for ATM's popularity in the VoX arena is that ATM utilizes fixed cell lengths of 53 bytes, enabling the sending and receiving codecs to clock against each other in synchronicity, ensuring the seamless flow of the voice traffic.

Frame Relay frames operate in a similar fashion to ATM (packet-switching versus cell-switching). However, one of the significant differences with regard to voice traffic is that Frame Relay frames are of variable length, up to 4096 bytes, making it difficult for the sending and receiving codecs to clock against each other because the "start" and "stop" flags appear at seemingly random intervals.

Several VoFr, or Voice FRAD (VFRAD), vendors are on the market today, each with its own workaround to the variable frame length issue. Each workaround is similar in that the sending codec limits the payload size of the transmitted frame, usually to 2000 bytes, or 2 kilobytes (KB). By utilizing this fixed length, the sending and receiving codecs can now clock against each other because the receiving codec now knows when the "stop" flag will appear, enabling a more seamless voice conversation.

VoFr Quality
A direct correlation exists between the quality of voice and the compression algorithm used. This quality is measured with something called the mean opinion score (MOS). Table 15-15 compares these different compression algorithms and their respective MOS.

Table 15-15: Voice Compression Mean Opinion Scores

Encoding
Compression
Mean
Opinion
Score
Native
Bit Rate
kbps
Voice
Quality
BWDTMFDualCompCPU
Music
on
Hold
G.711 PCM 4.1 64 A D A A A A
G.726 ADPCM 3.85 32 B C B B B B
G.728 LD-CELP 3.61 16 C B B C C C
G.729 CS-ACELP 3.92 8 A A B B C C
G.729a CS-ACELP 3.7 8 B A C C B D
G.723.1 3.65 5.3 C A C D C D

It is considered efficient to send compressed voice over data circuits, initially over point-to-point leased lines and more recently over Frame Relay. Because of this, it is natural for enterprise users to consider supporting voice service across an existing, or planned, Frame Relay WAN.

Generally, VoFr implementations utilize CIR/DE to prioritize voice over data traffic across the VC. To do this effectively, the proper amount of CIR bandwidth needs to be determined prior to implementation. The formula used to determine this is as follows:

FRLCIR = ((VOXMODULE X MODULEBANDWIDTH) + VOXBUFFER)
VOXBUFFER = ((VOXMODULE X MODULEBANDWIDTH) X 20%)
where VOXMODULE is the number of VoFr modules; MODULEBANDWIDTH is the amount of bandwidth per voice module, and VOXBUFFER is the amount of additional buffer space on the VC for the voice traffic.

For example, assume a FRAD with a 4-port voice module, utilizing G.728 compression (16 kbps). The CIR required to support the VoFr service is determined by the previous formulae:

FRLCIR = ((4 X 16) + 12.8) = 76.8 kbps
VOXBUFFER = ((4 X 16 kbps) 4 20%) = 12.8 kbps
The minimum amount of CIR required to support this configuration is 76.8 kbps. Typically, a network provider provisions CIR in multiples of 16 kbps or 64 kbps; therefore, the minimum CIR to support the voice traffic here would be 80 kbps. This is for voice traffic only; it is reasonable to expect to add incremental CIR to support data traffic requirements as well across the VC.

VoFR, as with all VoX, is subjected to and unforgiving of quality issues, most notably delay and jitter.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter