Bending the Rules – Voice Over Frame Relay

he first line of The Frame Relay Primer reads: "Frame Relay is a data protocol." Simple, straight forward, direct, and DATA ONLY ... and yet, voice communications can successfully use the Frame Relay network as its transport architecture. But, this extraordinary feat does require some hardware/software jiggery-pokery to "make the impossible happen".

What would be the motivation to combine mission-critical data and urgent voice over a data network? By combining data and voice traffic, dedicated voice networks and/or long distance charges are eliminated. So the benefits of reduced communications cost, one consolidated network, and one management / monitoring point provide the compelling reasons to investigate this phenomenon. But how, you ask, is it done? Well ... Figure 1: Voice Over Frame Relay

Remember, the basic elements of data transfer over Frame Relay:

It's a network access protocol. High-bandwidth, multi-purpose Cell Relay, ATM, networked IP, and so on are the 'inner-cloud' transport mechanisms.
It relies on the end-user devices to provide the error correction.
It adeptly handles serial (SDLC) and LAN (IP) protocols with ease.
It's available in multiples of 56 Kbps.
It supports variable-sized packets -- up to 4,096 bytes.

Now, remember the requirements for quality voice transfer:

Voice requires a high speed transport mechanism. ATM and Cell Relay are positioned as the all-purpose data/voice/video communications infrastructure of the future.
Data error correction procedures must not be implemented for voice communications - it will only delay and garble the voice transmission.
Voice must be prioritized over other communications - delay is 'tolerated' in a data transmission but is not acceptable for voice communications.
Non-compressed voice requires 64 Kbps - Compression techniques will reduce the amount of bandwidth required. 'Packetized' voice requires small, fixed packets for delivery consistency and efficiency.

Initially, Frame Relay did not appear to be suitable for quality voice transmission, but this was where the Frame Relay Access Device (FRAD) manufacturers got busy. They recognized by tweaking some of data's rules, Frame Relay could become a contender in the voice transport business. After all, Frame Relay uses a high-speed inner network (Cell Relay, ATM) which is ideal for voice communications. Frame Relay does not "error correct", another crucial element to quality voice transmissions. And, Frame Relay can assign 'more bandwidth' as voice/data transmissions require. But, there was still work to do ... Figure 2: Voice Over Frame Relay

The first rule that FRAD manufacturers tweaked was that voice takes the priority over any and all data transmissions. No exceptions. This prioritization ensures a "smooth" flow to a voice conversation, which is not interrupted by a late-breaking credit authorization, e-mail or database query.

The second rule demanded a "mechanism" that provides for data transmission during a voice conversation. Voice Compression and Digital Speech Interpolation techniques provided that "mechanism". Voice Compression compressed incoming 64 Kbps voice channels to 8, 9.6, 16 (or other) Kbps, thus allowing a 56 Kbps Frame Relay connection "room" or its data transmissions. In addition, Digital Speech Interpolation provided additional bandwidth efficiency during those "silent periods" in a voice conversation by allocating bandwidth (to the data side) when no speech is present.

Realizing that voice communications also demand consistency, FRAD manufacturers adjusted Frame Relay's variable packet size flexibility (remember - up to 4,096 bytes) to a small, fixed packet of 40 - 60 bytes, similar in size to an ATM cell.

With these principles in mind, the operation of a data and voice transmission over Frame Relay become magic. For example:

Your "consolidated" data/voice Frame network is, at present, only transmitting data queries and responses, and using Frame Relay's variable packet sizes to accommodate their own idiosyncrasies.
A voice telephone, at one of your Frame sites, goes 'off-hook'. The FRAD (Frame Relay Access Device) initiates an X.25 call setup and routing path determination, based on the initial information provided by your internal phone system, and connects to the destination.
The calling (and answering) FRAD changes its variable packet functionality to small, fixed packets for ALL communications, voice and data.
The calling (and answering) FRAD prioritizes the voice communications over current data transmissions. The FRAD initiates Voice Compression techniques and compresses the incoming 64 Kbps voice channel to the selected compression rate.
The voice conversation starts. Data is transmitted at a lesser priority than voice, in small, fixed packets, regardless of the data's actual byte size.
The voice conversation terminates; the telephone goes "on-hook". The call setup/routing path is terminated, and everything is returned to data-normal.
- The calling (and answering) FRAD adopts variable packet functionality (up to 4,096 bytes).
- Voice 'queues' are no longer prioritized (due to no voice data being present).
- Voice Compression and Digital Speech Interpolation are 'bypassed'.

And so it continues as voice communications initiate and terminate on the Frame Relay network. Figure 3: Voice Over Frame Relay

However, there are always questions and concerns to every great idea. Manufacturers' implementations of voice over Frame vary a good deal. Ensure that the voice quality is sufficient for your internal staff, clients, suppliers - whoever is destined as its primary user. Also, be aware that there are never any free rides. There is a cost of implementation for voice over Frame, in bandwidth, hardware and software. Is this cost greater than the hard / soft costs currently incurred for your site's voice communications? Your current voice implementation, whether it's E&M, FXS or any other voice technique, must have compatibility to your FRAD - ensure it's on the FRAD support list. And remember, during congestion, Frame Relay trashes data - which will be either true data or your voice communications.

However, voice over Frame can provide true efficiencies and network consolidation for those that wish to venture past the "data only" sign. The voice Frame technologies are proven; the economies (or lack thereof) are the primary driving factors in this implementation. T < G