SUBSCRIBE TO TMCnet
TMCnet - World's Largest Communications and Technology Community
 
TMCnet.com

Solving Cable Telephony Bandwidth Blues

BY LINDEN DeCARMO

Contrary to public perception, cable networks do not have infinite bandwidth. In reality, they contain serious bottlenecks that can cripple telephony applications. In this article, we'll explore the architecture of cable networks, reveal their limitations for cable telephony, and explore how the PacketCable standard proposes to solve these bandwidth issues.

Evolving Architecture
Cable companies, also known as Multi-Service Operators (MSOs), have invested billions of dollars in deploying coaxial (or coax) networks. Unfortunately, coax is overwhelmed by the transportation demands of packet-based multimedia content. Therefore, cable companies have been migrating to Hybrid Fiber Coaxial (HFC). HFC is called a hybrid since portions of the network remain coax, while performance-critical sections use higher-capacity fiber.

MSOs chose HFC because it has greater bandwidth, is more reliable than coax, and most importantly, does not require that consumers' homes be rewired. While HFC has significant advantages for multimedia transport, the way it is deployed in cable environments can be problematic for telephony applications.

To reduce cost and complexity, MSOs use shared bandwidth for their HFC networks. Shared bandwidth networks transport a fixed quantity of data that cannot be adjusted as more devices are added to the network. Therefore, the performance of these networks is inversely related to the number of network users (a greater number of users must battle over fixed bandwidth).

Cable networks also operate in broadcast mode: packets transmitted on HFC are broadcast (or simultaneously made visible) to all computers on the network. Consequently, broadcast networks require an arbitration scheme since only one device should broadcast at a time. If there is no arbitration, two or more devices may try to simultaneously transmit a packet (this is known as a collision). Network administrators dread collisions because they degrade performance by requiring retransmission of the affected packets.

Figure 1. HFC uses broadcasts to transport data.
Only one device at a time can broadcast a packet.

The Ultimate Supervisor
The combination of shared bandwidth and broadcast transportation makes cable HFC networks vulnerable to hackers. Therefore, access to the network is controlled by a Cable Modem Termination System (CMTS).

Figure 2. The CMTS controls access to the HFC network.

The CMTS's responsibilities include time slot enforcement, bandwidth allocation, and Quality of Service (QoS) management. To prevent transmission collisions, the CMTS allocates a time slot to each network device. During this time slot, only the assigned network device can transmit data.

Figure 3. Time slots help prevent cable network devices
from exceeding their bandwidth.

Time slots also enable the CMTS to perform bandwidth management. Each time slot defines the maximum amount of data that can be transmitted during a specific time period. Any attempt to broadcast data outside the authorized time slot will be rejected by the CMTS. Thus, by controlling the size and frequency of a device's time slots, the CMTS is able to constrain the maximum amount of data that device is able to transport.

A third task for a CMTS is enforcing network QoS. QoS describes the techniques used to ensure that packets reliably traverse a network. For instance, the CMTS may reduce the time slots allocated for lower-priority (or best effort) data to ensure that higher-priority QoS traffic (such as voice) arrives safely.

Telephony Is Demanding!
Cable companies are anxious to offer local telephone service over Internet Protocol (IP). To compete in this market, they must be able to match the reliability and audio quality offered by existing local phone companies. Consequently, dropped or lost audio packets are unacceptable. To be viable, cable telephony solutions must overcome the shared bandwidth limitations of IP-based HFC networks.

To avert these restrictions, PacketCable, the organization responsible for standardizing packet-based multimedia in cable networks, has enhanced the CMTS with additional multimedia-related QoS features.

For instance, a telephony-aware CMTS has APIs to control multimedia QoS attributes and to reserve and commit bandwidth. One QoS attribute is the number of sessions (or streams) dedicated to a single user. If a user exceeds the number of simultaneous streams that have been paid for, the CMTS may refuse to guarantee QoS for subsequent calls.

Another QoS attribute is the priority (or service level) associated with each multimedia stream. If the CMTS cannot provide the desired QoS priority, it notifies the requesting application before audio is transmitted. The program, in turn, can play a warning message and then a busy tone (the tone sequence may vary between MSOs). Without this feature, users would have to experience audio breakup before the application could detect problems.

Bandwidth reservation instructs the CMTS to reserve a specified number of time slots for audio transmission. However, these slots may be re-used for lower-priority data packets until the bandwidth commitment phase. Consequently, reservation does not influence network data flow. By contrast, bandwidth commitment affects HFC traffic since it only permits audio packets to flow through the committed portion of a CMTS.

Telephony Police
In a previous TMCnet.com article, "Fat Or Thin? Choosing The Best Client For Cable Telephony," I noted that PacketCable has chosen the Network-based Call Signaling (NCS) model for its initial cable telephony deployments. NCS places simple endpoints known as Multimedia Terminal Adapters (MTAs) in consumers' homes. These devices are controlled by an intelligent network entity called a Call Management Server (CMS).

The CMS uses the Common Open Policy Service (COPS) protocol to manipulate "gates" on the CMTS. A gate in PacketCable terminology represents a data roadblock -- these gates must be opened before data can flow through the CMTS.

By default, all gates are closed. When the user dials a phone number, the MTA transmits the digits to the CMS. The CMS analyzes these digits and determines the IP address of the MTA that the user wishes to call. It then creates a gate on the CMTS by requesting a specific QoS level from the CMTS. The CMS then causes the remote MTA to start ringing.

Once the gate is created, the calling MTA is responsible for reserving the bandwidth necessary to complete the call. When the calling party picks up the phone, the remote MTA requests that the CMTS commit the bandwidth (see below). After the conversation is over, the MTA issues a message to the CMTS to close the gate and free the time slots.

Figure 4. The MTA is responsible for reserving and
committing bandwidth on the CMTS.

The Future
So far, we've concentrated on cable telephony QoS. However, these QoS principles are equally applicable to video conferencing, gaming, or other multimedia services. Unfortunately, these services may degrade network throughput since they siphon bandwidth from lower-priority applications. Therefore, MSOs should quantify the performance impact of a new QoS-based feature before it is deployed.

Although cable networks are capable of transporting large quantities of data, they have weaknesses when used for telephony. Two of the most notable limitations are shared bandwidth and broadcast communication. The CMTS circumvents these limitations by allocating bandwidth, enforcing bandwidth caps, and providing QoS to high priority applications.

The importance of the CMTS will increase as it expands its role from data monitor to QoS enforcer. After this transition is complete, HFC networks will be a robust platform for cable telephony.

Linden deCarmo is a senior software engineer at NetSpeak Corporation where he develops advanced call agent software. He can be reached via e-mail at lindend@netspeak.com. A pioneer in Voice over IP (VoIP) network and infrastructure management solutions, NetSpeak is a leading developer and marketer of advanced telephony software for IP networks. NetSpeak's protocol-independent iTEL software architecture, designed to meet the rapidly evolving business needs of its Service Provider and Enterprise customers, delivers efficient management of network resources and enables cost-effective introduction of new VoIP applications.







Technology Marketing Corporation

800 Connecticut Ave, 1st Floor East, Norwalk, CT 06854 USA
Ph: 800-243-6002, 203-852-6800
Fx: 203-866-3326

General comments: tmc@tmcnet.com.
Comments about this site: webmaster@tmcnet.com.

STAY CURRENT YOUR WAY

© 2013 Technology Marketing Corporation. All rights reserved.