The HFC network architecture wasn’t conceived with the ubiquitous delivery of Internet protocol (IP) services in mind, but because of its wide bandwidth and physical layer flexibility, it has emerged as a preeminent IP delivery infrastructure worldwide. Although traditional Web browsing is the largest IP application, converged services (data, voice and video) will become more prevalent via managed networks. HFC network architects will capitalize on new IP transport methods to achieve the goal of providing fair and efficient utilization of the HFC network’s "fat pipe" for multiple simultaneous services.

High-speed packet data

Communications engineers discovered decades ago that most data traffic is "bursty." (That is, the information rate is not constant as a function of time.) The use of connection-oriented techniques was very inefficient because valuable bandwidth was tied up when no information was present, but data was sent regardless. New techniques evolved that were "connectionless" in nature and relied on "packetized" techniques that broke the bursty continuous data streams into small concentrated segments.

Ethernet interfaces, along with IP and its associated transmission control protocol (TCP), now hold the top spot in packet data communications applications. However, what may be surprising is the continual evolution of the Internet packet data transport protocols.

In particular, end users are continually demanding higher data throughputs and lower latencies for their Web-based applications. This ever-increasing trend has led to many fundamental changes within the multilayered TCP/IP protocol stack that drives the Internet, and the development continues at a rapid pace. Even as these advancements take hold, it’s important to understand the basic functions of TCP/IP.

Congestion control

Because efficient modern data networks are connectionless, users compete for time slots in a multiplexed stream to transmit and receive their data. Therefore, there always exists a potential for traffic requests that exceed the available bandwidth. When this occurs, network congestion is the result. TCP congestion control is one of the key functions that ultimately determines the performance of a particular data session.

In general, if any network element experiences congestion (overloading of its storage buffers), that network element can drop one or more of the passing packets. The detection of a dropped packet by a destination device will cause it to transmit a negative acknowledgement back to the source of the transmission. This negative acknowledgement (or the absence of any acknowledgements within a given timeout interval) will trigger a temporary decrease in the source’s packet generation rate.

TCP congestion control is achieved by maintaining a window (of size W) at the source, indicating the total number of bytes that can be transmitted toward the destination without receiving an acknowledgement. After transmitting W bytes, the source host must cease transmissions until a positive acknowledgement arrives.

The resulting throughput for many TCP "connections" is roughly given by W/RTT (see Figure 1 ), where W is the average window size, and RTT is the connection’s round-trip time. A detailed description of the complex algorithms that determine W and RTT is beyond the scope of this article. However a TCP connection’s throughput typically will be maximized if:

* Bit-rates associated with the connection on all of the links in the path are high.

* The number of network elements subject to congestion is low.

* The round-trip time is low.

Maximizing throughput

A system operator can ensure that these conditions are met in several ways. First, the deployment of advanced quality of service (QoS) and intelligent bandwidth management/load balancing techniques provided by some next-generation cable modem termination systems (CMTSs) will help ensure that the first condition is met. Second, the assignment of more bandwidth per subscriber also will help ensure that the first condition is met.

This bandwidth increase can be accomplished by supplying more upstream/downstream channels to each fiber node and by using higher bit-rate channels, such as those provided by the new Data Over Cable Service Interface Specification (DOCSIS) 2.0 modulation formats. Third, the proper placement of Web cache servers within the service provider’s network can help guarantee that the second and third conditions are met. Combinations of all of these approaches will help ensure that the high-speed data transport requirements meet the demands of HFC data subscribers well into the future.

The combination of robust IP data transmission protocols, with their ability to route packets separately to their correct destination under dynamic network conditions, and DOCSIS 1.1, with its support for enhanced QoS, is a boon for cable operators. For the first time, they have a tool that allows them to deploy high-bandwidth services that produce a guaranteed user experience to their subscribers. PacketCable is the project conducted by CableLabs and its member companies to define interface specifications used by the vendor community to develop equipment capable of providing these advanced IP services over HFC networks that conform to the DOCSIS 1.1 specification.

The PacketCable suite is important for two key attributes. It describes in detail how to deliver a telephony service using a carrier-based IP architecture; and it prescribes detailed interface specifications that allow vendors to produce interoperable equipment.

The PacketCable 1.x specifications cover virtually all aspects of delivering a primary residential telephony service using packetized voice techniques (VoIP). These functions include provisioning subscriber devices, signaling, managing call flows, providing interoperation with the public switched telephone network (PSTN), billing, announcement services, lawful surveillance, security, QoS and many others. The working definition of a "primary" telephony service means that the service is sufficiently reliable to meet the subscriber’s expectation of high availability. Primary telephony also specifically includes service assurance during power failure at the customer’s premises and PSTN access to emergency services.

In the PacketCable architecture (see Figure 2) , calls are managed by one or more call management servers (CMSs), which act similarly to central office switches in the ordinary twisted-pair telephony network. They also are responsible for setting up and tearing down calls, implementing features such as call-waiting, and controlling other devices so that calls are properly routed and managed with the necessary quality, billing and security. In the subscriber’s home, phones plug into a multimedia terminal adapter (MTA), which communicates (using IP) with the local CMS, and with the MTA of the other party on the call.

Assuring quality

Because one of the stated goals of PacketCable is to guarantee high-quality phone calls, PacketCable must provide a mechanism to ensure that phone conversations, which consist of advanced encryption standard (AES)-encrypted IP packets routed between MTAs, are delivered end-to-end with guarantees on their latency and jitter. On the HFC net, this requires the use of a DOCSIS 1.1 feature called dynamic service flows, which is not present on DOCSIS 1.0 systems. This in turn means that an MTA has embedded within it a DOCSIS 1.1 (or 2.0) cable modem, and requires that the HFC plant that carries the telephony traffic must be serviced by a DOCSIS 1.1 (or 2.0) CMTS.

At the start and end of each call, the CMS and CMTS send special PacketCable event messages to a record-keeping server, which is situated between the PacketCable network and the operator’s choice of billing service. This allows the operator to have real-time access to detailed subscriber call records and ensures that subscribers cannot receive services fraudulently.

PacketCable multimedia

The delivery of Internet data and managed network telephony traffic are not the only applications for IP services over HFC access networks. The emergence of multimedia applications has created dozens of new potential services ranging from video-on-demand to interactive gaming to remote control and telemetry.

Like VoIP, most popular multimedia applications are sensitive to transmission delay and jitter degradations. New applications that utilize broadband networks will present unique bandwidth, QoS and latency requirements that must be anticipated and managed. Today’s DOCSIS 1.0 service model, based on best-effort data delivery, results in an inconsistent online experience that varies in quality, because it is dependent on bandwidth availability and network congestion. A viable multimedia network must be able to reserve resources and deliver bandwidth on demand as service requirements dictate.

The PacketCable multimedia initiative defines an IP-based standards platform for delivering QoS-enhanced multimedia services over DOCSIS 1.1 access networks. This platform expands on the core capabilities of PacketCable 1.x to support a wide range of IP-based services beyond telephony. Although the PacketCable multimedia specs are based upon PacketCable 1.x, the complete VoIP infrastructure defined in PacketCable 1.x is not a prerequisite for deploying multimedia services. Operators may choose initially to deploy either voice or multimedia services, with the assurance that both specification regimes will seamlessly integrate and interoperate if they are deployed together on the same network.

Client devices in the PacketCable multimedia architecture are connected directly to the cable access network from within the home. They may be standalone devices or may contain an embedded DOCSIS 1.1 cable modem, and, therefore, are considered untrusted network elements. Untrusted network elements require some form of authentication of the user and application by the operator’s network.

Types of clients

To provide architectural flexibility while standardizing the QoS and policy interfaces of PacketCable multimedia, three major classes of clients have been designated. These client classes may be distinguished by differences in QoS signaling capabilities and control in the client-server architecture.

The first class of clients represents existing generic PC applications that lack specific QoS requirements or signaling capabilities. To service this class of applications, QoS must be managed entirely at the headend for each active client. The second client class is similar to a PacketCable 1.x MTA. This class provides explicit support for QoS, but relies upon policy enforcement mechanisms initiated and managed at the headend. This class of clients represents a transition from the legacy PC class in that a portion of the signaling has migrated from the headend to a client platform.

In the third category of clients, both policy requests and QoS signaling initiate at the client. This creates a distributed end-point control model different from any protocols used on HFC networks today. This type of client is a sophisticated endpoint device that requires precise management of QoS resources to provide converged voice, data and video services. Resource requests are securely authenticated, authorized and managed at the headend.

The PacketCable multimedia specs focus strictly on the delivery of QoS-enabled services over the HFC access network, specifically addressing the technical issues of policy authorization, QoS signaling, resource accounting and security. Application-level details of particular multimedia services, application specific provisioning, signaling and operations support system (OSS) functions required to provide a particular service are the sole responsibility of the application developer.

To facilitate policy enforcement, QoS and security, the interaction of a variety of network elements—including client devices, application managers, policy servers, CMTSs and cable modems—must be prescribed. Application managers reside on the operator’s managed IP network and are responsible for ensuring that clients requesting service are authorized to receive that service. Policy servers also reside on the operator’s managed IP network and are responsible for making QoS-related policy decisions based on pre-defined operator rules. CMTSs in the PacketCable multimedia architecture function as in the PacketCable 1.x framework and are responsible for enforcing QoS policies.

Server roles

In addition to a DOCSIS 1.1 CMTS, which executes the parameter-based QoS policies, the multimedia network architecture consists of servers that are typically structured into the following categories (see Figure 3):

* Application managers and (optional) media servers that host QoS-enabled applications.

* A policy administration framework providing QoS authorization and admission control in support of per-flow network resource management.

* An event messaging subsystem used to monitor and record resource usage information.

* OSSs that handle provisioning, network management and monitoring functions that typically are included in the network architecture. However, these elements are outside the scope of the specifications.

The PacketCable initiatives provide a complete yet configurable framework to launch and grow advanced IP services over HFC networks. Just as the great success in the CableLabs DOCSIS program has proven, operators and vendors alike will benefit from stable standards that create new services, which subscribers will find valuable and operators will find profitable.

D. R. "Doc" Evans is a senior broadband architect with Arris Broadband, based in Boulder, Colo. Email him at N7DR@arrisi.com.

Tom Cloonan is the CTO-Broadband Division, with Arris Broadband, and is based in Lisle, Ill. Email him at tom.cloonan@arrisi.com.

Mike Caldwell is the director of broadband marketing with Arris Broadband, and is based in Suwanee, Ga. Email him at mike.caldwell@arrisi.com.

BOTTOMLINE

IP Service Delivery

The HFC network architecture wasn’t conceived with the ubiquitous delivery of Internet protocol (IP) services in mind. Because of its wide bandwidth and physical layer flexibility, it has emerged as a preeminent IP delivery infrastructure worldwide. Although traditional Web browsing is the largest IP application, converged services (data, voice and video) will become more prevalent via managed networks.

The PacketCable initiatives provide a complete yet configurable framework to launch and grow advanced IP services over HFC networks. Just as the great success in the CableLabs DOCSIS program has proven, operators and vendors alike will benefit from stable standards that create new services, which subscribers will find valuable and operators will find profitable.

The Daily

Subscribe

Acquisitions

RCN , Grande and Wave finalized the previously-announced acquisition of EnTouch Systems . The deal adds 22K customers to their coverage area in

Read the Full Issue
The Skinny is delivered on Tuesday and focuses on the cable profession. You'll stay in the know on the headlines, topics and special issues you value most. Sign Up