Cable operators, having worked through many of the technical challenges faced in providing Internet service, are looking to the future by turning their efforts to the delivery of a new suite of integrated Internet services, using that same cable spectrum.
Certainly voice services are a part of this strategy. Currently, operators are delivering circuit-switched based services over cable networks. But, the real gem in an operators eyes is the rollout of voice services that run over Internet protocol (IP) connections, which also deliver interactive gaming and video services.
So how do we get there? The answer lies in reworking system architectures in order to support toll-quality voice-over-IP (VoIP) services over cable links. This two-part article will explore the underlying technologies necessary to provide toll quality IP cable telephony solutions. The first part of this two-part series will discuss the key components of a voice over cable (VoCable) designs. Following this, the second part will focus on quality of service (QoS) mechanisms established for IP telephony and will describe how some of the key components are optimized for deployment in Cable IP Telephony applications.
Replicating the interface
Of course, for any VoCable system to be successful, it must first provide the same type of interaction that end users have grown accustomed to with current POTS systems. To replicate the users traditional interface with the PSTN, tone generation and detection functions are necessary. Dialed digits must be accurately collected and replayed at the receiving end to successfully execute a call.
Tone generation/detection is not only necessary at the beginning of the call. Due to voicemail and calling card functions, tone generation/detection must be handled mid-call as well. Therefore the VoIP processing must also support the ability to successfully transmit dual-tone multi-frequency (DTMF) tones in-band, however vocoders with compression may distort these tones. To account for these distortions, designers may have to turn to advanced techniques such as IETF request for comment RFC2833 when passing tones in conjunction with the use of low bit rate vocoders.
The ability to detect and properly switch processing for fax and data modem signals is also a requirement, as all types of telephony currently available on the PSTN must be supported. Because the VoCable application is targeted for residential locations, the provision for hearing impaired services, in compliance with the ITU V.18 recommendation, should also be supported. Correspondingly, a tone generation function is necessary to provide depressed tone playback and call progress tones.
Approaching Echo
Combating problems with echo cancellation has been key to VoIP adoption in the traditional telco world. As VoIP moves to the cable world, cable operators must take their lessons from the telco operators and learn how to adopt robust echo cancellation techniques to meet the demands of cable networks.
Echo is present in conventional POTS networks, and the PSTN employs echo cancellers throughout the system. Line echo is caused when a connection involves conversion between a four line to a two-line telephony hybrid. Echo is generated toward the packet network from the telephone network.
PSTN specifications dictate that echo cancellation functionality is necessary when the delay exceeds 50 ms. However, because the IP network portion of the VoCable solution almost always adds more than 50 ms of round trip delay, line echo cancellation is essential when VoCable solutions interface to the PSTN.
The echo canceller compares the voice data received from the packet network with voice data being transmitted to the packet network. The echo from the telephone network is removed by a digital filter on the transmit path into the packet network.
The echo cancellation tail length, that is the length of echo cancellation processing, varies amongst different VoIP applications. The tail length requirement is determined by the distance between the gateway equipment (cable modem) and the 4 to 2 line hybrid. Typically this length ranges from an 8-ms tail size for residential/SOHO applications to 32-ms, and up to even 128-ms tail sizes for carrier applications.
Since most phone calls established via cable modems will at some point terminate to PSTN equipment, line echo cancellation is required. For most cable modems, an 8-ms echo cancellation tail length requirement has been determined. As a minimum quality benchmark, the echo cancellation functionality should be compliant to ITU G.165 and G.168 standards, which define performance requirements.
Voice Encoding
While handling echo is key in VoCable development, it is only one problem that designers face. Converting 1s and 0s into data packets is a relatively easy to handle. When voice enters the picture, things get more difficult.
In a VoCable design voice encoding functionality is necessary to convert the analog signal to voice packets. This encoding often includes compression as well for network bandwidth optimization. In addition to G.711 PCM encoding, cable telephony requires voice compression for efficient bandwidth utilization.
While the cable telephony feature suite is similar to that used in other VoIP implementations deployed today, there are a few features unique to the cable environment. As a consumer product, the minimum channel density requirement is two channels of a single low bit rate codec (G.728 or G.729E) and a G.711 channel. However, four channels total (for future scalability) is highly recommended.
While the G.728 and G.729E vocoders are not prevalent in current VoCable systems today, they offer benefits to a cable network in addition to bandwidth reduction. The G.728 vocoder offers the potential for low packetization delay by the use of 2.5 ms voice frame sizes. The G.729E vocoder offers a higher fidelity audio.
Detecting Voice
Voice activity detection (VAD) and related silence suppression, whether incorporated in the codec or as an external software function, should also be supported as a configurable (enable/disable) feature in VoCable designs. The VAD monitors the received signal for voice activity. When no activity is detected for a specific period of time, the software prevents packetization and subsequent transmission of silence. This function also measures the idle noise characteristics of the telephony interface. Noise measurements are relayed to the receiving gateway, or cable modem. [Note: Comfort noise generation (CNG) must also be supported.]
In addition to VAD, some cable modem systems support the use of fax relay techniques. The use of fax relay offers bandwidth reduction and a more robust, reliable means of connecting fax over IP calls, and is therefore highly recommended.
Fax relay functionality involves demodulation of the facsimile scan data, encapsulation into IP packets, and subsequent demodulation of the fax IP packets at the receiving gateway. This requires support of the T.30 fax protocol implemented between the fax machine and the VoIP gateway, as well as T.38 fax IP packet encapsulation for IP transmission.
Modem interfaces
Cable modems interface to traditional telephony equipment through FXS signaling to a pulse code modulation (PCM) interface. This interface receives PCM samples from the digital interface (either a T1/E1 framer for a network gateway, or a CODEC interface for an analog interface) and forwards them to the appropriate functions, such as those described above. Conversely, the interface forwards processed PCM samples received from the DSP processes to the digital interface. The PCM interface performs continuous re-sampling of output samples to avoid sample slips.
When voice and fax samples have been processed, they must be packetized. Like a lot of VoIP solutions, cable IP Telephony systems employ the real-time packet (RTP) packets. On the receive side a voice playout unit is necessary to buffer received voice packets and forward them to the vocoder for playout to the user. This playout unit also serves as a jitter buffer manager to queue several packets, avoiding packet under-run or over-run.
Understanding MGCP, Security
While there are a plethora of network protocols in deployment and test today for VoIP systems, the VoCable providers have converged on a variant of the media gateway control protocol (MGCP) for call control between voice enabled cable modems and media gateways.
Under CableLabs auspices, the PacketCable' suite of specifications has optimized this master/client MGCP protocol for the cable network-based signaling paradigm, providing an end-to-end call signaling model. This effectively dictates that MGCP executes out of the RISC processor in the cable modem. The call signaling functionality works in tandem with the voice processing, security, dynamic QoS (DQOS), provisioning and DOCSIS functionality.
While most systems today are based on MGCP, not all systems use security features . Since telephony services are operating on a shared network, security features should be employed. This level of security, however, entails encryption of the voice data as well as the call setup functions.
The cable modem functionality plays a role in providing system level security, enabling residential voice customers with equal to or better privacy than the PSTN currently offers, as well as providing defense against attacks on the voice enabled cable modem and network services. The cable modems major security features are voice encryption, currently defined by advanced encryption system (AES) algorithm and call signaling encryption supported by IP security specification (IPSec). The voice packets are decoded by the media gateway in the system and the call signaling packets are decoded by the MGCP call agent in the system.
Implementing the features
Figure 1 depicts the implementation of the features described above. The features described above are typically implemented in software, distributed between a digital signal processor (DSP) and a RISC processor. All of these features are integrated, both at the media terminal portion of the cable modem and at the telephony gateway.
Additional key hardware components needed to make a VoCable system come to life include the analog interface to a POTS phone (typically a CODEC and SLIC), the cable modem media access control (MAC) and physical layer (PHY) circuitry, RF front end tuner circuitry, an Ethernet interface for data connectivity, memory, and in some cases, a home networking interface. Figure 2 depicts these additional features in a network interface card design.
That wraps up part 1 of this primer on building VoIP Functionality into cable modem equipment. In part 2, we will focus on quality of service (QoS) mechanisms established for IP telephony and will describe how some of the key components described in this article are optimized for deployment VoCable system architectures.
Debbie Greenstreet is the Product Management Directorfor Telogy Networks, a Texas Instruments company. She holds a BSEE from the University of Virginia and has done graduate work in computer engineering. Debbie can be reached at dgreenstreet@telogy.com .
