• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
LESSON LEARNED FROM IMPLEMENTING
 

LESSON LEARNED FROM IMPLEMENTING

on

  • 733 views

 

Statistics

Views

Total Views
733
Views on SlideShare
733
Embed Views
0

Actions

Likes
1
Downloads
31
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    LESSON LEARNED FROM IMPLEMENTING LESSON LEARNED FROM IMPLEMENTING Document Transcript

    • THE EVOLUTION TO IPTV OVER DOCSIS® 3.0 AND MODULAR-CMTS Howard Abramson, Director Advanced Engineering Roger Slyk, Director Product Marketing BigBand Networks INTRODUCTION While DOCSIS 3.0 provides cable operators with the necessary bandwidth enhancement, multicasting and other tools to enable the delivery of IPTV over the cable HFC network, it is an M-CMTS (modular cable modem termination system) architecture that allows DOCSIS 3.0 to be delivered in a scalable and economical manner. This paper discusses the trends leading to the development and eventual deployment of IPTV over DOCSIS and then goes on to explain what parts of the CableLabs® DOCSIS 3.0 specification are particularly targeted towards services such as IPTV, and how these capabilities are applicable in an IPTV solution. The authors also describe how the M- CMTS specification enables cable operators to smoothly transition to IPTV services with the lowest possible costs. Employing an M-CMTS architecture provides the following advantages: • Optimization of bandwidth used between traditional video (including broadcast, PPV, VoD and switched broadcast) and smooth expansions to broader implementations of IPTV; • Significant reductions in capital equipment costs and operational costs; • Seamless transition from DOCSIS 2.0 to full DOCSIS 3.0 functionality; • Ability to expand capacity without requiring node splits, rewiring or wholesale replacement of existing hardware; • Flexible allocations of upstream and downstream bandwidth. After describing the details of M-CMTS, the authors examine PSP (packet streaming protocol) and D-MPT (DOCSIS MPEG protocol transport), two possible universal Edge QAM protocols for M-CMTS, contrast the advantages of each and provide a recommendation for deployments today. TRENDS FOR VIDEO TODAY It is an unavoidable fact that consumers are blurring the line between “lean-back” consumption of TV-based entertainment and “lean-forward” multimedia activities on their personal computers. A rich array of innovative technologies provide cable operators with the opportunity to expand program line-ups to include hundreds of high definition channels, increasingly personalized content and advertising that more closely matches the interests of viewers. The ability to offer any media to anyone, at any time, anywhere is moving from a concept to a reality. 1
    • Figure 1: Bandwidth-intensive services require increases in network capacity Recognizing that IP provides benefits spanning greater service flexibility and openness, cable operators are looking towards technologies that boost network capacity for IP- based traffic. One of the attributes required to support increases in IP-based applications is bandwidth. However, not only are higher speeds required in downstream directions, applications such as peer-to-peer file swapping require flexible allocations of upstream to downstream capacity ratios. As will be explained later in this paper, traditional I-CMTS (integrated cable modem termination systems) designs are unsuitable for this role. Most I-CMTS solutions available today only support the combination of a single shared downstream channel, associated with four to six independent upstream channels, within a service group. Although the DOCSIS protocol defines more flexible downstream and upstream channel associations, early requirements for symmetrical bandwidth and capabilities of early DOCSIS silicon has resulted in limited combining ratios. Even though significant investment was made in DOCSIS 2.0 by the industry to improve noise mitigation and increase bandwidth capacity in the upstream frequency spectrum (up to 30 Mbps per channel), the unspoken truth has been that this capacity either goes unused or results in under-utilized upstream CMTS receivers. In fact, the improvements in DOCSIS 2.0 upstreams create such an imbalance between upstream and downstream capacity that real networks are prevented from capitalizing on DOCSIS 2.0 improvements. While the existing problem and future DOCSIS 3.0 requirements may be solved using integrated CMTS devices, the imperative of offering IPTV services demands a more modular and flexible approach to expanding upstream and downstream capacity. Fortunately, opportunities exist for an expansion of CMTS capacity by adoption of M- CMTS architectures. This type of platform physically separates once-integrated CMTS functionality for best-of-breed performance. In an M-CMTS architecture, the function of adding DOCSIS information to IP packets that are being transmitted to the user is still the responsibility of the CMTS (called the “CMTS Core” in this model), while responsibility for 2
    • changing the packets to more closely resemble television signals is moved to a separate Edge QAM chassis. M-CMTS DOCSIS 3.0 CMTS Core Channel Bonding Modem Edge QAM Broadband speeds GigE GigE > 100 Mb/s to IP Network Upstream paths Broadband speeds > 25 Mb/s “Legacy” DOCSIS 1.x or 2.0 Modems Figure 2: M-CMTS with disaggregated CMTS Core and Edge QAM functionality M-CMTS also addresses the limitation of fixed allocations of downstream and upstream capacity. Increasingly an issue for cable operators faced with the need to accommodate asymmetrical traffic patterns such as streaming video, and symmetrical ones like VoIP (voice over IP), fixed configurations restrict performance, and can lead to operating costs. Fortunately, M-CMTS platforms can provide cable operators the flexibility to assign all capacity to downstream traffic, upstream traffic, or any ratio in between. DEFINING THE REQUIREMENTS FOR THE DELIVERY OF IPTV What is IPTV? In broad terms it is a cable service delivered to an end user over an edge network capable of transporting IP. It could be a traditional video service that an operator offers today such as a linear TV program, a video clip from an Internet source like Google’s YouTube, a PPV (Pay Per View) episode, and so on. In general IPTV will exhibit some, or all, of the following characteristics: • An expansion of programming choices by broadening the universe of content to include “long tail” content economically delivered using switched broadcast, richer on-demand choices, and video obtained from the Internet; • Bundled video, voice and data services delivered over IP connections; • Increasing personalization of content that includes addressable advertising, customized new bulletins, music networks, and more; • Time-shifting and device-shifting, and place-shifting as appropriate; Based on the characteristics above, the IPTV ecosystem is becoming both large and complex, and needs to address important services such as content management, content encoding, advertising, billing systems, digital rights management and more. 3
    • This paper focuses on the last mile network architecture which comprises the “plumbing” technologies for the successful implementation of IPTV. The basic functions provided over the last mile are invisible to subscribers. Rather than providing services that users directly interact with (e.g. selection of a PPV movie) the last mile network provides the necessary functionality to enable various IPTV features and services. This is much like the difference between obtaining television service today over cable versus satellite. This last mile delivery is not critical to the viewer, and the television viewing experience is intended to be essentially the same on both technologies. Before describing the various functions that the cable network needs to support for successful IPTV delivery, let’s outline some of the key requirements and assumptions that are associated with the migration to IPTV and the subscriber viewing habits. These requirements and assumptions drive the functions of the last mile network. Firstly, it is widely accepted that the move to IPTV will not be an instantaneous and revolutionary change. Instead, the change will be deliberate and evolutionary. The existing infrastructure and installed base of subscriber set top boxes demands that the existing methods for video delivery over the HFC network will be in use for some time. Secondly, subscriber behaviour while consuming video content will be augmented and enhanced by personalization and time-shifting technologies, but will not be changed completely. Specifically, there will still be a tremendous demand for broadcast video content which is consumed by a large percentage of the subscriber population at specific times of the day. For social and psychological reasons, people will still want to watch various programming without delays and pauses, including highly popular programming, sporting events, and news shows. Thirdly, while broadcast content will remain popular, the “long tail” effect of an increasingly large amount of content available through the cable provider and over the internet, coupled with time-shifting and network personal video recording technologies, will drive the need to support narrowly focused programming down to the level of one subscriber. This narrowcast viewing behaviour will grow over time. Fourthly, current trends and old habits will die hard. The trend towards subscriber demand and availability of high definition content will continue its rapid growth. And, although subscribers will be provided with enhanced program guide tools including powerful content search capabilities similar to the search tools provided by Google and Yahoo!, channel surfing will remain a dominant method of locating content for a large segment of the subscriber population. Instant channel change will remain something that subscribers simply expect to have available to support this style of content searching. While there are many other assumptions of viewer behaviour that can be made, the above four assumptions are sufficient to describe the requirements for the last mile and how equipment based on DOCSIS 3.0 and M-CMTS meet these requirements. Last Mile Requirements Based on the subscriber behaviour and transition assumptions described above, the following paragraphs outline the key requirements of the last mile network which in a cable HFC last mile network are met with the features provided by DOCSIS 3.0 and M- 4
    • CMTS. • Evolutionary transition to IPTV – the last mile network must support coexistence between the existing video infrastructure and legacy cable modem devices so as to achieve an evolutionary transition to IPTV services. As with previous versions, DOCSIS 3.0 uses downstream QAM (Quadrature Amplitude Modulation) to remain fully compatible with the existing infrastructure for video delivery over HFC. In addition, DOCSIS 3.0 specifically provides backwards compatibility for the tens of millions of cable modems in operation today. Further, by leveraging the M-CMTS specifications, DOCSIS 3.0 borrows from the requirements defined there to further enhance the RF operation of DOCSIS for better downstream performance and per- channel isolation. • Broadcast services and channel surfing habits – IP Multicast is a requirement if broadcast content, or content that is viewed simultaneously by many subscribers, is to be supported efficiently. IP Multicast allows content to be delivered to multiple devices at the same time. Dramatic bandwidth savings can be achieved by employing IP Multicast. Rather than sending the same 4 Mbit/sec video content separately to 50 users, consuming 200 Mbits of bandwidth, if all 50 users are viewing the same broadcast content, only 4 Mbits/sec will be consumed. DOCSIS 3.0 provides a complete overhaul of the support for IP Multicast over the HFC to readily support these types of services. While IP multicast does save considerable bandwidth, there is still a need for significantly increased bandwidth over what can be provided to a single cable modem in today’s high-speed HFC solutions. There are three factors conspiring to drive this need for more bandwidth. These are the combination of having hundreds of channels of broadcast content, the delivery of this content to potentially hundreds of homes each with multiple TVs or other multimedia devices (including DVRs), and the need to support instant channel change for channel surfing. The large number of homes, each with several multimedia devices, creates demand for perhaps as many as fifty or more broadcast video streams to be watched simultaneously. Additionally, due to the instant channel change requirements of those who are channel surfing, this content must be available without cable modems having to re-acquire different channels. In other words, the easiest and most straight forward method to solve these problems is to provide a “fatter pipe” to the cable modem and simply use IP Multicast techniques to change channels instantly. Downstream channel bonding was added as a key capability in the DOCSIS 3.0 suite of functionality to achieve this. • Support for HD content – since HD video requires more bandwidth supporting increased amounts of HD content means flexibility in growing the size of the pipe to the cable modem in the home. DOCSIS 3.0 downstream channel bonding also provides for this flexible growth in the number of downstream channels, each supporting up to 40 Mbits/sec (50 Mbits/sec in Europe), which can be bonded together to form bigger pipes. • Growing the number of devices in the network – DOCSIS 3.0 also provides for expanded IP address space to address the need to service a much larger population of devices. Today’s set top boxes do not have IP addresses – they do not support 5
    • While the previous paragraphs clearly describe how the features specified by DOCSIS 3.0 are specifically targeted to address the needs of applications such as IPTV, the authors contend that DOCSIS 3.0 is insufficient, by itself, to enable a viable deployment of IPTV services over the HFC network. Only when used in conjunction with M-CMTS solutions can IPTV truly reach its potential as a viable business for the cable industry. M-CMTS AUGMENTS DOCSIS 3.0 FOR IPTV An M-CMTS architecture works synergistically with DOCSIS 3.0 to enable a viable, deployable IPTV solution for cable. Some of the key features provided by M-CMTS include: • Optimization of bandwidth use between traditional video (including broadcast, PPV, VoD and switched broadcast) and a smooth transition to increased use of IPTV over time; • Significant reductions in capital equipment and operational costs; • A Smooth transition from DOCSIS 2.0 to DOCSIS 3.0 features provided by the CMTS equipment in the headend; • The ability to expand capacity without requiring node splits, rewiring or wholesale replacement of existing, proven hardware; • Enables flexible allocations of upstream and downstream bandwidth. One tremendous advantage of the M-CMTS solution is the ability to share key equipment between traditional video distribution and IPTV over DOCSIS. Today, hubs are filled with large numbers of Edge QAM devices which enable the transmission of video signals into the HFC plant. A universal Edge QAM can support both the traditional video transmission as well as the transmission of IP data over DOCSIS. This capability is commonly referred to as QAM sharing. As more and more video content is distributed over IPTV the ability to easily, and automatically, move QAM bandwidth from traditional video to IPTV will be critical to the smooth long-term transition to IPTV. For example, at a time of day when many subscribers want to watch video on-demand, QAM bandwidth can be assigned to predominantly support that service type; at another time capacity can be re-assigned to switched video services or data traffic. Another key advantage of an M-CMTS are improved economics. Edge QAMs now coming to market provide extremely high density and reliability. Along with this density is a fast and continuous reduction in the cost of a QAM, the basic unit of measure for providing bandwidth over HFC. This reduction in cost derives from the economies of scale achievable today when the vast majority of QAMs in use are for traditional video delivery. In a typical head end installation today, only 1% of the QAMs are devoted to the delivery of IP, while the remainder are devoted to the delivery of traditional video. IPTV will change this ratio dramatically over time. The ability to both leverage the economies of 6
    • the traditional video Edge QAM as well as smoothly transition these Edge QAMs from traditional video to IPTV is critical to the business success of IPTV over cable. A detailed description of the M-CMTS architecture, and key considerations for its deployment, are provided in the next section. M-CMTS: THE SECRET SAUCE What makes an M-CMTS better suited to supporting changing consumer viewing habits and changes network traffic requirements? Given demands for IPTV and DOCSIS 3.0 and the need to simultaneously support legacy DOCSIS 1.x and 2.0 CMs (cable modems), it is appropriate to provide a brief review of general DOCSIS and CMTS operation. A discussion of DOCSIS 3.0 bonding and multicast operations is provided given their importance to providing IPTV transport services. This is followed by a summary of M-CMTS operation with a focus on general CMTS and M-CMTS operation required for wide scale deployment of IPTV and DOCSIS 3.0 services. First of all it is important to recognize that DOCSIS is a broadband networking protocol with independent forward (downstream) and reverse (upstream) paths. As such, the CMTS acts as the traffic cop, managing MAC (media access and control) in each direction. In the downstream, the problem is very similar to other Ethernet based switching and routing models, and is modelled as a broadcast domain. The upstream is a reservation-based protocol in which CMs (cable modems) contend for access that is prioritized according to rules controlled and communicated by the CMTS. In I-CMTS devices the lower cost downstream bandwidth is tied to the more expensive upstream processing. In I-CMTS devices, the lower cost downstream operations are physically tied to the more expensive upstream processing. In many solutions, the upstream and downstream are processed on the same card if not within the same silicon. Tying the upstream MAC/PHY to the downstream MAC/PHY drives deployable plant combining ratios (i.e., upstream and downstream channel combining to the subscriber network) that are economically and mechanically practical to deploy with an I-CMTS. As will be shown, M-CMTS breaks this relationship and affords a more flexible and scaleable approach that can leverage alternative uses for the downstream PHY. The following description is provided to help the reader appreciate the value, elegance, and cost efficiency afforded by partitioning the I-CMTS into specific M-CMTS device responsibilities. It focuses on key areas of M-CMTS operation that are different from the traditional I-CMTS model. M-CMTS System Description An M-CMTS architecture is comprised of the same logical components as an I-CMTS, however, each component is placed into devices in the network best suited for each operation. The following diagram outlines the various components of the M-CMTS which partitions these components into separate devices, and potentially geographically disparate locations. A new set of specifications has been defined by the MSO and DOCSIS vendor community to address each of the new interfaces noted on this diagram. 7
    • Timing Signal Generator (DTI) Downstream Ext Downstream Radio PHY (DEPI) Freq Interface (DRFI) GigE to GigE WAN upstream Edge Cable M-CMTS QAM Modem Core Figure 3: Modular CMTS Reference Architecture Although provisions exist for further separation of the upstream physical receivers from this architecture, the primary focus for the M-CMTS at this time is to decouple the downstream PHY from the Upstream PHY and DOCSIS MAC. The relevant differences, shown in the diagram above, between I-CMTS and M-CMTS solutions can be summarized as follows. • M-CMTS Core – originally referred to as the packet shelf, this device provides all of the DOCSIS MAC control and data forwarding to and from the NSI. Although current M-CMTS specifications include integrated upstream receivers, it is expected that this tight coupling will eventually migrate to be a stand-alone function that feeds a centralized DOCSIS packet shelf. • EQAM – provides downstream modulation of DOCSIS, VOD and switched digital video streams. This device is based on the original equipment designed for digital video distribution using Gigabit Ethernet input(s) and multiple QAM Modulator and RF upconvertered outputs to the HFC. The output is commonly referred to as QAM which for DOCSIS is the downstream channel. • Timing Signal Generator – also referred to as the DTI (DOCSIS Timing Interface) server, this device coordinates the understanding of time for the CMTS Core’s, Upstream PHY & MAC logic, and EdgeQAM. • DEPI – this is the protocol that forms the connection between the M-CMTS Core and EQAM. DOCSIS MAC packets, those that normally would be transmitted directly onto the QAM by the I-CMTS, are transmitted over a Gigabit Ethernet connection using a form of the L2TPv3 tunnelling protocol. The DEPI (Downstream External PHY Interface) protocol serves to provide the pseudo-wire establishment & management of sessions (each session represents a single downstream QAM) as well as the tunnel in 8
    • which DOCSIS MAC frames are sent through the EQAM to the HFC QAM and CM network. • DRFI – this interface defines RF requirements in the downstream direction for both I- CMTS, M-CMTS, and VOD EQAM devices. One of the major differences between the DRFI (Downstream Radio Frequency Interface) specification and the original DOCSIS RFI specifications are characteristics required to produce multiple downstream channels on a single physical port. Universal EQAM Operation As was described earlier, the EQAM has become the downstream access point for all things digital in the MSO network. This includes support for traditional VOD, switched broadcast and now DOCSIS. DTI is added to permit the timing requirements presented earlier for DOCSIS. Output from the EQAM looks very much as it does today, made up of MPEG-encoded VOD, switched video, or DOCSIS and follows requirements specified by the new DRFI requirements. With this configuration, migration to the all IP delivery model becomes a very practical solution. Figure 4 highlights the multiplicity of services that can be supported by UEQ (Universal Edge QAMs). IP Vid Universal backbone eo Voi Edge QAM ce Dat a o ide Stored VoIP ev Liv video Switched Time-shifted video TV Figure 4: Universal Edge QAMs improve utilization of network infrastructures Eventually, it is envisioned that all services will be distributed over DOCSIS. Until such time, simply sharing the same equipment between existing services affords operators economies of scale and efficiencies not possible with disparate I-CMTS and independent EQAM devices. Downstream Channel Bonding With the DOCSIS 3.0 comes the ability to associate or bond multiple downstream QAMs into a single virtual channel, thus multiplying the capacity available to each DOCSIS 3.0 capable CM. This increased capacity not only provides much higher peak throughput but 9
    • general statistical gains required for IPTV services. It is not the intent of this paper to describe all the benefits and requirements of DOCSIS 3.0 channel bonding operation. However what is discussed is how M-CMTS provides a very flexible approach to extending channel bonded downstream services. Edge M-CMTS Core QAM QAM Channel Bonding QAM Channel Group HFC Plant Bonding QAM Channel Group QAM Channel Edge QAM Figure 5: Bonding Services Model The beauty of the model shown in Figure 5, is that the EQAM is transparent to the bonding operation. None of the complexity or state associated with the DOCSIS control plane or downstream MAC need be known by the EQAM device. Not only can operators add QAMs as needed, but this approach has the ancillary benefit of deploying less complicated downstream devices with independent failure groups. Failure of the more complicated MAC is independent from the downstream PHY. This assists in extending the carrier grade availability properties expected for a DOCSIS network. With the I-CMTS model, downstream QAM failures are tightly coupled to the integrated nature of all other components within the chassis that might cause failure. Multicast Services Model DOCSIS 3.0 extends the original IP Multicast over DOCSIS service model. DOCSIS 3.0 Multicast extensions bring a number of new capabilities that are beyond the scope of this discussion. The salient point to this discussion is the dependence for IP Multicast over bonded downstream channels to provide broadcast or linear video services over DOCSIS first as a supplement to and later as a replacement to existing digital video services. Replacing existing broadcast video with IPTV over DOCSIS requires a tremendous number of QAMs that are best suited to the M-CMTS EQAM device. Anatomy of the M-CMTS Most of the answers to producing a viable M-CMTS and DOCSIS 3.0 system are provided in the specifications produced by CableLabs. Key specifications and protocol elements were summarized above. However, there are subtle elements of these specifications that warrant attention to gain the most from IPTV and DOCSIS 3.0 deployments utilizing M-CMTS architectures. It is hoped that this description helps to prevent confusion about M-CMTS and the ease in which it can be implemented and 10
    • deployed. When designed with these considerations in mind, the existence of a DEPI network and EQAM are transparent to CM and subscriber connectivity and Quality of Service. To appreciate the choices in designing an M-CMTS system, this section describes elements within the CMTS architecture that are relevant to enabling independent and scaleable expansion of downstream and upstream channel combining for DOCSIS 1.x/2.0 and 3.0 CMs to support IPTV. This will help to appreciate the primary changes required to support true DOCSIS services with M-CMTS. Making the CM to CMTS Connection In the DOCSIS protocol, the CMTS is responsible for transmitting messages that are used to establish CM connectivity to the CMTS. These messages include timestamp SYNC, UCD (Upstream Channel Descriptor), and the upstream bandwidth allocation MAP. DOCSIS 3.0 adds the MDD (MAC Domain Descriptor) message that is also used to establish an understanding of the plant topology available to the CM for bonded channel operation. There are, of course, other MAC Management control messages exchanged between the CMTS and the CM. The relevance for discussing these specific messages is in their ability to i) simultaneously support DOCSIS 1.x/2.0 CMs and 3.0 CMs on the same channels and ii) the ability of the CMTS to properly load balance DOCSIS 3.0 CMs. The absence or partial implementation of these messages defines what is termed a secondary downstream channel that is, at best, useful for best effort bonded subscriber data. A primary downstream channel is a DOCSIS QAM in which all CMs can range, register and be controlled by the CMTS. The following diagram illustrates these relationships. DOCSIS 3.0 Channel Bonding M-CMTS Modems DATA VoIP IPTV EQAM Primary Channel DOCSIS 1.x/2.0 Modems Figure 6: DOCSIS 3.0 Secondary Downstream Channel Operation A primary downstream channel can support legacy DOCSIS 1.x and 2.0 CMs at the same time it supports DOCSIS 3.0 bonded CMs. The yellow line in figure 6 represents the timestamp SYNC message, used by all CMs to obtain system timing, UCDs, used to describe available upstream channel parameters, MAPs, used to describe bandwidth allocation on the upstream, and MDDs, used to describe the plant topology and associated characteristics of the MAC Domain. The other colored lines represent secondary downstream channels that are only useful for transporting bonded subscriber 11
    • data for DOCSIS 3.0 CMs. Restricting CMs to a single or small set of primary downstream channels limits the CMTS’ ability to load balance DOCSIS 3.0 CMs between available QAMs because all CMs must remain connected to the primary downstream channel. Similarly, all DOCSIS 1.x and 2.0 CMs only have the single primary downstream channel available. The effect is that all CMs in the network stack up on the primary downstream channel. In contrast, defining and implementing all downstream channels as primary permits any CM to remain connected to any downstream in the network. This is shown in figure 7. DOCSIS 3.0 Channel Bonding Modems DATA VoIP IPTV EQAM Primary Channels DOCSIS 1.x/2.0 Modems Figure 7: DOCSIS 3.0 Primary Downstream Channel Operation In this diagram, the legacy DOCSIS 1.x and 2.0 CMs can be spread across the available downstream channels. Similarly, the DOCSIS 3.0 CMs can remain connected to and be balanced across any of the QAMs. The effect is much higher utilization and more complete load balancing. Given the dearth of downstream frequency, particularly in the North American market, this is an important consideration for the selection of DOCSIS 3.0 capable CMTS equipment. What is also important to recognize is that an M-CMTS system that produces primary downstream channels permits operators to leverage their existing install base of legacy DOCSIS 1.x and 2.0 CMs. This is accomplished by spreading existing subscribers over more available QAMs. For example, the common plant combining ratio of one downstream QAM to four upstream channels, can be easily modified to three to four downstream QAMs and four upstream channels. This concept is shown in figure 8. Core EQAM 3 to 4 QAMs 4 U/S Channels Figure 8: MCMTS Expands Service Group Combining Capability 12
    • What should be obvious is that each of the previous diagrams are identical when primary downstream channels are employed, thus providing operators with a clear migration path from where they are today to where they need to be to provide IPTV and other DOCSIS 3.0 services. Providing Full QoS with an M-CMTS Given the utility of M-CMTS the only remaining topic to consider for providing full DOCSIS 3.0 and IPTV services in combination with MPEG-TS video, is QoS (Quality-of-Service). The following diagram establishes the points in the M-CMTS system that must consider service quality. Video over MPEG-TS 2 4 IPTV Data NSI CIN VoIP EQAM M-CMTS Core 3 1 1 Figure 9: Multi-service model The first point in the network to consider QoS is the NSI (Network Side Interface) of the CMTS. This is no different than the I-CMTS model. QoS on the NSI is established using IETF and IEEE standards for differentiating services on Ethernet-like networks. This includes diffserv and/or IEEE 802.1p into and out of the CMTS. The second point in the network to establish and retain QoS is the M-CMTS Core itself. In general, policies negotiated between the CM and CMTS are managed by the Core. These QoS policies, or service flow rules, remain the same as those originally defined by DOCSIS 1.1. In I- CMTS systems this QoS is established directly between the HFC-side, facing the CM network, for both the upstream and downstream RF. In M-CMTS, the upstream path remains the same as with I-CMTS. Downstream QoS for M-CMTS extends the DOCSIS 1.1 service flow model through the DEPI network and into the EQAM. The third and fourth points in the M-CMTS DEPI include the intervening CIN (Committed Information Network) and the EQAM itself. These last three points of QoS enforcement are what distinguish the two modes of DEPI encapsulation. There are two modes of DEPI encapsulation. The first mode of DEPI encapsulation is known as D-MPT (DOCSIS MPT) and is based on MPEG transport used for VoD and switched digital video services. D-MPT is effectively a single stream of DOCSIS encapsulated data that has been pre-formatted into 188 byte MPEG frames and encapsulated into IP or UDP L2TPv3 DEPI packets used to tunnel the DOCSIS downstream from the M-CMTS Core to the EQAM. In many respects, D-MPT looks very much like the output from an I-CMTS MAC that has been encapsulated in IP or UDP 13
    • L2TPv3 frames. In this mode, the entire DOCSIS stream, including MAC Management and subscriber data are transported as a non-differentiated stream from the M-CMTS Core through the DEPI CIN to the EQAM. Upon arrival to the EQAM, D-MPT frames are modulated onto the RF QAM. In contrast, the second mode of DEPI encapsulation is known as the PSP (Packet Streaming Protocol) which permits differentiating between eight separate levels of flow priority when transported from the M-CMTS Core through the intervening CIN and into the EQAM. These two modes are shown with respect to edge QAM operation in Figure 10. M-CMTS Core DOSCIS Signaling EQAM Voice over IP IPTV CIN Best Effort Data With D-MPT P1 With PSP P1 P2 P3 P8… Figure 10: CIN and Internal EQAM QOS From this figure it should be clear that PSP mode provides much more granularity for differentiating higher priority data from lower priority data. In the case of DOCSIS and IPTV, it is critical to ensure signalling information (i.e., MAPs, UCDs, etc.) be transported as the higher priority frames, followed by VoIP, IPTV, etc., with best effort data as the lowest priority data. Between the M-CMTS Core and EQAM, the same IETF and IEEE standards used on the NSI can be used to retain the differentiation classified within the M- CMTS Core and extended through the CIN and into the EQAM itself. Following the evolution of the DEPI protocol specification it is clear that D-MPT was meant to be a quick and dirty approach to leveraging legacy EQAMs that are not capable of implementing the more robust PSP mode. PSP is clearly the mode of operation intended to support full QoS expected for DOCSIS 3.0 services. With PSP, classification and QoS applied by the M-CMTS Core is maintained on the CIN and reinforced by the EQAM. Given the tight timing constraints for VoIP and intolerance of video to jitter and packet loss, it is critical that a proper M-CMTS system employ the PSP mode for DEPI transport. Further, mixing of non-DOCSIS video over MPEG and PSP encapsulated DOCSIS is more resilient to latency, jitter and head-of-line blocking common to 14
    • networking and EQAM equipment. CONCLUSION The ability to offer IPTV services is an exciting opportunity that can enables cable operators to increase customer satisfaction and reduce churn, while competing effectively with telecom providers and satellite broadcasters. The authors have described the need for DOCSIS 3.0 features to provide IPTV in the last mile of the cable network, and the corresponding need for an M-CMTS architecture on which to build these capabilities. An explanation as to why PSP mode of DEPI encapsulation has advantages over D-MPT in these environments was provided. An M-CMTS architecture has been shown to be an economical way to turbo-charge the performance of DOCSIS networks today, in addition to providing the features described above. An M-CMTS provides cable operators with the ability to dramatically expand broadband data rates without requiring subscribers to replace their existing cable modems or media terminal adapters. It lowers the cost of delivering bandwidth to a fraction of the current cost per bit, and supports versatile allocations of downstream and upstream bandwidth. Additionally, M-CMTS platforms allow cable operators to begin offering DOCSIS 3.0 features such as downstream channel bonding immediately while smoothly transitioning to full DOCSIS 3.0 functionality over time. By physically separating CMTS functionality for the EQAMs, an M-CMTS offers benefits that integrated designs cannot match. Areas of M-CMTS operation which contribute to these advantages, namely the signaling, timing, management and physical layer interfaces, have been described in this paper. Additionally, separation of the EQAMs fro the CMTS Core introduces opportunities for EQAM capacity to be dynamically shared across video, voice and data services. 15