Next-Generation CMTS Architecture

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

White Paper

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

Introduction
This whitepaper provides an overview of the network transitions required to support converged services. It outlines emerging architectures, with a particular focus on the needs of distribution hub and headend locations. It discusses how Cable Modem Termination System (CMTS) architectures are evolving, and presents a solutions approach to network evolution that allows operators to ensure cost-effective migration and the accelerated introduction of new high-bandwidth services.

Video: Driving the Network Transition

It is no surprise that the world is going IP Everywhere. Cable data services are delivered over IP, voice services are now being deployed over IP, and video will eventually be delivered over IP. Services and applications are converging, and operators will need to assign increasingly more bandwidth and optimize it for digital services. This requires increased flexibility for adjusting to the evolution of traffic patterns, since different services will drive different requirements. Data traffic requires the ability to handle bursty traffic flows but is typically tolerant of packet loss, latency, and jitter. Voice requires constant low bandwidth but imposes strict packet loss, latency, and jitter requirements and it demands higher availability levels. Video imposes the greatest demands of all in that it requires dramatically higher bandwidth levels to be provided within strict loss, latency and jitter budgets. The symmetry of application traffic also changes. While Voice over IP (VoIP) is largely symmetric with roughly equal bandwidth demands on upstream and downstream traffic, both data and video services are asymmetric, with much greater demands on downstream capacity than upstream. But even this can be in flux, since peer-to-peer applications such as music or content sharing can be asymmetric, with heavier demands on upstream bandwidth. Cable operators are now entering the third phase of service convergence as they increasingly add video services to existing data and voice offerings. The current HFC network has been designed for efficiently delivering broadcast video service, but service delivery requirements are rapidly evolving. A significant percentage of traffic will shift from broadcast video to per-user streams as deployment of network Video on Demand (VOD) services enables consumers to move to a user-controlled viewing paradigm, my content at my convenience. This trend will be further accelerated as customers use PCs, Digital Video Recorders (DVRs), and other client devices to capture, store, and share voice, data, and video content for consumption on multiple devices connected using Home Area Networks (HANs). Voice and data convergence is now largely understood by cable operators. Video traffic requirements are not as clearly defined, but it is clear that traffic is stream -based and sensitive to packet loss, jitter, and latency. While a voice call may consume 100 kilobits per call and a data session might consume a megabit of bandwidth, video can consume one-to-four megabits per stream for MPEG 2 or MPEG 4 video, with highdefinition streams requiring seven-to-ten megabits even with MPEG4 compression. To more efficiently deliver video services and more effectively compete with satellite video providers, operators must be able to efficiently implement per-stream traffic engineering and deliver lower-cost bandwidth. They must be able to support stream -based flows that are sensitive to packet loss, jitter, and latency, and they must be able to efficiently accommodate the as ymmetric nature of video streams. In the short term the transition to per-user video streams is largely taking place in the MPEG domain. The VOD and PVR services are being delivered to conventional set-top boxes via an MPEG 2 transport stream multiplex. Over the longer-term, more of the video content will be delivered over an end-to-end IP infrastructure directly to televisions and PCs in the home. Although the immediate challenge is to transition MPEG video onto the existing network so it can be profitably delivered with voice and data services, the infrastructure deployed must be capable of evolving into this all IP network.

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

Evolving Architectures for the IP Headend

New architectures and new solutions are required to allow broadband cable operators to successfully manage these transitions. Cable operators need to partner closely with CMTS vendors to ensure that these platforms evolve to support emerging requirements. The trends are becoming clear. More individual video streams must be delivered and this drives up the number of QAM streams required on the HFC network. In order to support viable cost points for these services, lower-cost edge QAMs must be provided and operators also need the ability to share these QAMs across multiple service offerings. To support rapidly changing service requirements and provide agility to accommodate uncertain acceptance rates of video and other high-speed services, operators also need the flexibility to separately scale upstream and downstream capacity. Cable operators want to benefit from increased network flexibility and enhanced reconfiguration options on CMTS platforms, and they want next-generation platforms to reduce the complexity of combining RF channels. The economics demand backwards -compatibility and coexistence with existing infrastructure, including currently deployed CMTS platforms as well as the millions of cable modems and set-top boxes in the homes of existing subscribers. CMTS architectures are evolving, and operators need to carefully evaluate vendor migration paths. Operators naturally want to extend the life of deployed equipment and increase the Return-on-Investment (ROI) of existing network assets, but they also want a clear migration path for evolving CMTS functionality for the IP headend. As operators seek an efficient migration path to all-IP networks, the headend becomes a crucial transition point. The evolution of CMTS functionality is crucial as operators transition toward end-to-end digital networks so they can reclaim bandwidth and not have to go through additional network rebuilds. The ability to leverage industry standards and the economics and efficiencies of IP become major advantages as CMTS architectures are changing to accommodate emerging video services. During this time of transition, it is important to select proven CMTS platforms that offer the ability to efficiently meet todays service requirements while also providing flexible migration paths to accommodate the evolving needs of the IP headend.

Understanding the Decoupled CMTS

In todays product architectures, traditional CMTS functions are largely deployed in integrated systems that offer the reliability and manageability demanded by real-time services. But as networks evolve toward endto-end digital services and as operators increasingly support increased demand for video and other demanding servicesCMTS architectures are evolving to provide increased modularity and flexibility. This architectural concept is often referred to in the industry as a decoupled CMTS, since major functions of traditional CMTS platforms are decoupled into logical components. While there are many advantages to containing these functions in a single system chassis, there are also advantages to decoupling them to provide greater deployment flexibility. The following are the five major elements of a decoupled CMTS: ? ? ? ? ? Gigabit Ethernet Switch Matrix Upstream Receiver PHY Downstream Edge QAM Media Access Control (MAC) Domain Manager Forwarder

By briefly exploring the functions of each of these modules and their interworking, one can understand architectural tradeoffs and deployment alternatives. While the definition of these logical elements is still evolvingand some functions may move from one element to anotherthe functions of a CMTS will be allocated among these elements to support greater flexibility for next-generation platforms.

Motorola Broadband Communications Sector

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

Figure 1 Decoupled CMTS

Upstream Receiver PHY Regional IP network Forwarder Gigabit Ethernet Switch Matrix Downstream Edge QAM MAC Domain Manager HFC network

Gigabit Ethernet Switch Matrix

The Gigabit Ethernet Switch Matrix is a dumb, high-speed switch that provides the fabric for the decoupled CMTS architecture. Its function is to provide flexible interconnection for the other CMTS components in as transparent a manner as possible. It does not implement any of the intelligence in the system and for the purposes of this description can be considered as a set of dump pipes connecting the other modules. In order to achieve the required transparency it must support line-rate switching with minimum latency to enable the effective delivery of real-time services. The Gigabit Ethernet Switch Matrix requires redundancy to support high availability of voice, data, and video services.

Upstream Receiver PHY

The Upstream Receiver PHY receives packets transmitted from cable modems and converts them into Ethernet format for transmission on the headend Gigabit Ethernet Switch Matrix. To achieve this, it implements the RF front-end receiver functions and demodulates the upstream QAM and QPSK RF signal bursts received from the cable modems into packets. It sends the data packets to the Forwarder and the DOCSIS control packets to the MAC Domain Manager via the switch fabric. The Upstream Receiver PHY must also implement physical level functions required by the DOCSIS ranging process. For these control packets it collects timing, frequency offset, and power information that it forwards to the MAC Domain Manager. It then implements the ranging protocol and applies necessary offset parameters to compensate for signal delay.

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

The Upstream Receiver PHY supports spectrum management and captures metrics on the physical layer signaling attributes. It takes the measurements, records the data, and forwards this information to the MAC Domain Manager where the complex spectrum management logic runs and where the analysis is performed.

Downstream Edge QAM

The Downstream Edge QAM takes DOCSIS IP traffic flows from the Forwarder and MAC Domain Manager modules and converts them to RF for transport to subscriber homes. It receives DOCSIS packets from the Forwarder or the MAC Domain Manager that are encapsulated within Ethernet packets. These packets contain a control header that tells the Downstream Edge QAM the appropriate interface port to which the packet should be directed. It implements the DOCSIS transmission convergence function to map the DOCSIS packets into an MPEG transport stream and adds the timing information to the DOCSIS header as required. It then combines the DOCSIS MPEG streams with video MPEG streams received directly by the Downstream Edge QAM from VOD servers. The MPEG data is then modulated into QAM signals, upconverted to the appropriate frequency and transmitted onto the HFC plant. If wideband downstream channels are required (e.g. to a business customer) the Downstream Edge QAM supports inverse multiplexing, allowing the operator to aggregate multiple channels for transmission to a single cable modem.

MAC Domain Manager

The MAC Domain Manager handles the control protocols for the DOCSIS cable modems. It implements the DOCSIS MAC-layer protocols including: ? Initial and periodic ranging. The MAC Domain Manager responds to the ranging requests as cable modems join the network. It uses data from the Upstream Receiver PHY to determine the timing, power, and frequency adjustments needed for optimum performance. Periodic maintenance intervals are scheduled for all active modems to ensure performance is maintained as network conditions change. Registration. The MAC Domain Manager processes the registration requests from cable modems, including authorization of QoS parameters requested. Dynamic Service Changes (DSx). The MAC Domain Manager processes the DOCSIS 1.1 MAC messages to enable additions, deletions, and changes to QoS-enabled service flows to support changing service requirements. Upstream scheduling. The MAC Domain Manager creates the DOCSIS MAP messages used to tell the cable modems when they can transmit. It schedules the upstream traffic based on the QoS parameters required for each service flow. BPI+. The MAC Domain Manager runs the Basic Privacy Interface (BPI) protocol, which is used to update the encryption keys used for encryption of data between the CMTS and the cable modem. It does not perform the actual data encryption but passes the key information to the Forwarder and to the cable modems. DCC & UCC. The MAC Domain Manager supports Dynamic Channel Change (DCC) and Upstream Channel Change (UCC) for load balancing modems across different upstream and downstream channels. It must keep track of which cable modems are on which CMTS port interfaces, which becomes more complex in a decoupled CMTS architecture because of the greater flexibility to allocate upstream and downstream resources.

? ?

Forwarder
The Forwarder is responsible for routing traffic between the HFC network and the regional IP network. It differs from the Gigabit Ethernet Switch Matrix in that it makes intelligent forwarding decisions based on network policy and packet content rather than providing local inter module links.

Motorola Broadband Communications Sector

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

In the downstream direction, the Forwarder takes the DOCSIS traffic from the regional network and sends it to the correct edge QAM. It creates the DOCSIS packet headers and implements Packet Header Suppression (PHS) according to rules provided by the MAC Domain Manager. While the MAC Domain Manager runs the control protocol for DOCSIS encryption, the Forwarder actually encrypts the packets. The packets received from the network are mapped to the appropriate Quality of Service (QoS) flow on the downstream and then scheduled for transmission to the edge QAM according to policies associated with each flow. In the upstream direction it receives packets from the Upstream Receiver PHY, removes the DOCSIS encryption using the BPI keys obtained from the MAC Domain Manager, expands any packet headers that the cable modems compressed, and forwards the packets out to the network. All packets pass through the Forwarder, which enforces forwarding rules and policies. These include Access Control Lists (ACLs) to perform filtering, packet dropping, and rate shaping and also implement Quality of Service (QoS) controls. The forwarding decisions may be based on Layer 2 and or Layer 3 models. The Forwarder will run the appropriate IP routing or spanning tree protocols to populate the forwarding database in either case. The Forwarder will also support ancillary DOCSIS protocols such as DOCSIS Set-Top Gateway (DSG) and PacketCable Multimedia (PCMM). It maps the set-top box control traffic received from the network into the appropriate the DSG tunnels. In a PCMM network, the Forwarder will receive information from a central Policy Server using the Common Open Policy Services (COPS) protocol, and it will use this information to setup filters and implement upstream and downstream QoS control.

Figure 2 Downstream Packet Flow

Forwarder

Gigabit Ethernet Switch matrix

-Receives packet from regional network -Applies access control lists -Routes to edge QAM -Creates DOCSIS header -Implement PHS -Encrypts -Adds to QoS flow -Schedules according to QoS -Encapsulates packet in Ethernet frame -Transmits to Downstream Edge QAM via switch

Downstream Edge QAM

-Receives packet from switch -Removes Ethernet encapsulation -Routes to RF port -Adds MPEG framing -Fixes DOCSIS timing as required -Multiplexes data with VOD MPEG stream -Implements QAM modulation -Performs Upconversion -Transmits to HFC

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

Figure 3 Upstream Packet Flow

Upstream Receiver PHY

-Receives packet from HFC -Demodulates -Makes any required PHY-layer measurements -Encapsulates packet in Ethernet frame -Transmits to Forwarder via switch

Gigabit Ethernet Switch Matrix

Forwarder

-Receives packet from switch -Removes Ethernet encapsulation -Decrypts -Expands header -Applies access control lists -Applies rate limiting -Routes to network -Transmits to network

Addressing Architectural Concerns

As in any architectural evolution, there are issues that must be addressed and managed. By analyzing issues and potential tradeoffs, it is possible to fine-tune the architecture and understand the advantages and disadvantages of various alternatives. The decoupled approach has benefits in terms of flexibility and the potential for lower costs, but it does incur penalties, which should also be considered prior to deployment. As CMTS architectures evolve, it is critical that these platforms must move forward to support real-time IP services. Subscribers are becoming accustomed to high-quality service and are less likely to accept besteffort services in the future, so top among the architectural issues to address are: ? ? ? ? ? ? Performance QoS Management Reliability Standards -Based Migration CAPEX versus OPEX

Performance
In a decoupled CMTS architecture, performance will be addressed in different ways by various vendors. In current-generation architectures, all CMTS functions are within a single chassis, which provides greater timing control. But in a decoupled architecture with multiple elements, timing is a major challenge. Sophisticated timing and scheduling is essential for ensuring acceptable performance of voice and video services. As traffic flows move between multiple standalone devices instead of across a shared backplanethe risk of latency becomes more pronounced.

Motorola Broadband Communications Sector

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

QOS
In an integrated system, it is to be expected that all the components will operate in unison to implement QoS. Similarly, in a decoupled system all components must cooperate to provide the level of QoS required for a given packet. QoS can only be provided if all components work in unison but can be destroyed by any single element in the forwarding path. Thus, in the downstream direction the Forwarder will schedule packets for transmission based on their QoS parameters and deliver them to the Gigabit Ethernet Switch Matrix at the correct time. Neither the switch nor the Downstream Edge QAM can drop, reorder, or jitter packets if QoS is to be maintained. Similarly, on the upstream the Forwarder will schedule packet transmissions from cable modems based on QoS demands and the Upstream Receiver PHY and Gigabit Ethernet Switch Matrix must deliver the packets to the Forwarder without drop, reorder, or jitter.

Management
While a modular, stackable approach may result in a lower-cost implementation, this approach can lead to operational issues, including: ? ? ? ? Cabling and deployment complexity The manageability and interoperability challenges of controlling multiple devices instead of a single system Ensuring high-availability and redundancy of all elements Managing software upgrades for multiple platforms from multiple vendors while ensuring compatibility

Reliability
With a decoupled CMTS architecture, operators must ensure that each element offers the reliability necessary for voice and video services. This includes ensuring redundancy of elements and having the flexible management and provis ioning tools necessary to ensure uptime of each element and prevent service downtime. Rapid failure detection and service restoration becomes more difficult in a multi platform, multi vendor environment.

Standards-Based Migration
Central to the decoupled CMTS architecture is the reliance on industry standards to ensure interoperability of multiple devices and services. Operators must ensure that their vendors offer standards -based solutions that are compliant with DOCSIS and PacketCable specifications and IP standards.

CAPEX versus OPEX

While the stackable approach reduces initial deployment costs, it inevitably results in higher operating expenses. Operators are therefore faced with whether to focus on reduced Capital Expenses (CAPEX) or lower ongoing Operational Expenses (OPEX). The system-versus -stackable architectural solution can also be viewed as a decision of whether to deploy the telco-class redundancy of a chassis -based solution, or the IP data-class redundancy of a stackable approach. Each operator must review its business goals and select the appropriate solution.

Migrating with Motorola

Partnering with the right CMTS vendor is a critical decision for cable operators evolving their network to support next-generation architectures. Standards and architectural requirements are currently in a state of flux, so it is key to select a vendor that offers not only the proven technology but also the expertise to optimize the use of innovative products to maximize revenue and support new services.

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

Motorola provides cable operators with maximum flexibility for supporting next-generation architectures and services while optimizing the use of existing infrastructure. Motorola offers the expertise in routing, switching, telephony, video, aggregation, and redundancy necessary to enable critical data, voice, and video services. During this time of transition, operators need to partner with equipment providers that can support evolving standards and requirements while ensuring migration of installed equipment. No cable operator can afford to waste investments in already-deployed network assets, so one of the greatest challenges in managing the transition to a next-generation network is to minimize stranded investments. By taking a holistic view of todays revenue demands and tomorrows architectural and service requirements, cable operators can harness the power of existing infrastructure while deploying nextgeneration CMTS platforms and evolving the network to deliver video and other high-speed services. Motorola will offer both system -level solutions and modular elements to provide operators maximum flexibility in migrating CMTS functionality to support video requirements. No one knows today exactly what CMTS architectures will look like in the future, but it is clear that video services are placing demands on the network that must be addressed today while ensuring a flexible longterm migration path to support new architectures and services. Motorola offers the widely deployed, carrierclass BSR 64000 architecture and provides proven expertise in routing, video, telephony, redundancy, and in supporting the end-to-end service requirements of cable operators worldwide.

The BSR 64000 is Evolving to Enable Maximum Architectural Flexibility

Carriers can continue to deploy BSR 64000 platforms while retaining maximum flexibility for deploying decoupled CMTS architectures in the future. Motorola will also continue to offer chassis -based CMTS platforms that provide the integrated administration and management and allow operators to: ? ? ? ? ? Minimize rack space Streamline operations by centralized management Simplify maintenance and upgrades Better support the complex timing requirements of real-time services Ensure carrier-class redundancy of CMTS functions.

The BSR 64000 CMTS/edge router is evolving to support requirements for decoupled CMTS architectures. The first steps in the evolution of the BSR 64000 are the separation of upstream and downstream onto separate modules and the availability of separate QAM modules. This supports scaleable growth according to market requirements, and maximum flexibility for supporting high-bandwidth services. Operators will benefit from higher-density modules and greater flexibility in adding capacity to meet demand. This approach allows operators to reduce port costs while increasing their ability to share QAMs and other equipment on the cable plant. Later, Motorola will offer a decoupled CMTS solution. By offering both system -level, chassis -based solutions as well as card-level, stackable components, Motorola will offer maximum flexibility for evolving the network. Operators can safely deploy additional BSR 64000 systems today while retaining maximum flexibility for supporting evolving architectures in the future, and migrating to an all-digital IP headend. The stackable components will be capable of operating in combination with the BSR 64000. The BSR 64000 chassis will implement the Upstream Receiver PHY, MAC Domain Manager and Forwarder functions using a mix of internal and external (stackable) devices to provide the high-density Downstream Edge QAM function.

Motorola Broadband Communications Sector

Protecting Network Investments While Migrating to Next-Generation CMTS Platforms

Safe and Reliable Migration to the IP Digital Headend

Motorola offers a safe, reliable and flexible migration path with maximum flexibility by offering the choice of chassis bas ed or stackable solutions. The proven and reliable BSR 64000 will continue to evolve to support emerging architectural requirements while ensuring a cost-effective migration path as operators continue to drive down operating costs while increasing revenues from video and other high-performance services. For more information, please visit http://broadband.motorola.com/.

MOTOROLA and the stylized M Logo are registered trademarks of Motorola, Inc. Reg. U.S. Pat. & Tm. Off. All other product or service names are the property of their respective owners. 2004 Motorola, Inc. All rights reserved. Printed in the USA.

MGBI 518958-001