THE EVOLUTION TO IPTV OVER DOCSIS® 3.0 AND MODULAR-CMTS
Howard Abramson, Director Advanced Engineering
Roger Slyk, Director Product Marketing
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
• 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.
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
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
changing the packets to more closely resemble television signals is moved to a separate
Edge QAM chassis.
CMTS Core Channel
GigE GigE > 100 Mb/s
> 25 Mb/s
1.x or 2.0
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.
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-
• 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-
• 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
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
• Optimization of bandwidth use between traditional video (including broadcast, PPV,
VoD and switched broadcast) and a smooth transition to increased use of IPTV over
• 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
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
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.
Downstream Ext Downstream Radio
PHY (DEPI) Freq Interface (DRFI)
M-CMTS QAM Modem
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
which DOCSIS MAC frames are sent through the EQAM to the HFC QAM and CM
• 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).
Voi Edge QAM
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
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
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.
M-CMTS Core QAM
Group HFC Plant
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
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
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
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.
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.
3 to 4 QAMs
4 U/S Channels
Figure 8: MCMTS Expands Service Group Combining Capability
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
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
Video over MPEG-TS
Data NSI CIN
M-CMTS Core 3
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
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.
Voice over IP
Best Effort Data
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
networking and EQAM equipment.
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.