Docsis 20 getting to know


DOCSIS 2.0:
Getting to Know the New Kid on the Block
Tom Cloonan
CTO- ARRIS Broadband

Introduction

With the introduction of every new technology, vendors and their customers are typically filled
with many different emotions. Some are elated by the promise of the new technology, while
others are unimpressed by the surrounding marketing hype. Some are confused by the proposed
benefits of the technology, while others are fearful of what it may imply about their past
decisions and future directions. Many questions abound…

- “Do I really need this new technology?”
- “Will this technology really work as promised?”
- “When will the technology really show up in products that can be deployed?”
- “Is this technology compatible with the equipment that I purchased in the past?”
- “Should I hold off on all future equipment purchases until this technology matures?”
- “Will there be a technology following this new one that will obsolete the new one?”

With all of this confusion, making decisions surrounding new technologies is, at best, a
challenging task in today’s world.

DOCSIS 2.0 is a new technology that seems to be suffering from all of the aforementioned
confusion. The DOCSIS 2.0 specification (first released in by CableLabs in December 2001)
contains several changes to previous Cable Data specifications, and in the matter of a few
months, these changes have already created complications and confusions for many vendors,
system operators, subscribers and investors.

This paper will attempt to answer some of the confusing questions surrounding DOCSIS 2.0. It will
try to cut through the hype and identify some of the true benefits of DOCSIS 2.0, while un-masking
some of the misconceptions surrounding the technology. The goal is to help those that are associated
with the Cable Data space to make intelligent decisions and profitable plans as the Cable industry
moves forward in its quest to be THE provider of broadband services to the world.

www.arrisi.com Page 1 of 36 Version 2.0 October 15, 2002
From North America, Call Toll Free: 1-866-36-ARRIS • Outside of North America: +1-678-473-2000
All contents are Copyright © 2002 ARRIS International, Inc. All rights reserved.


DOCSIS 2.0: Getting to Know the New Kid on the Block

Background and History
The introduction of Cable Data service to Cable Television subscribers is one of the most successful
deployment stories in the history of the Internet. In a matter of a few years, Multiple System Operators
(MSOs) transformed themselves from being providers of entertainment video into being the most
popular providers of both entertainment video and affordable, broadband data services for most of the
residential subscribers in North America. Similar deployments outside of North America are allowing
MSOs throughout the world to duplicate that accomplishment.

Part of the success behind that accomplishment must be attributed to the establishment of standards
for the delivery of Cable Data service, because the existence of standards allowed multiple vendors to
develop interoperable equipment, and the resulting competition and the creation of a volume chip
market ultimately led to price reductions that were directly seen by the subscribers.

The first standard (known as the Data-Over-Cable Service Interface Specification 1.0 or DOCSIS 1.0)
was initiated by work in the Multimedia Cable Network System (MCNS) consortium in January 1996,
and the Interim specifications became available in the spring of 1997. Preliminary versions of the
DOCSIS 1.0 Physical (PHY) and Media Access Control (MAC) layer chipsets (which were being
developed in parallel with the specifications) became available in the summer of 1997. Equipment
manufacturers for both subscriber Cable Modems (CMs) and headend Cable Modem Termination
Systems (CMTSs) began designs using the DOCSIS 1.0 PHY and MAC layer chipsets in the same
timeframe. Interoperability testing occurred throughout 1997 and 1998, and actual CableLabs
Certification Wave testing began in June 1998. The first DOCSIS 1.0 certifications (for CMs) and
qualifications (for CMTSs) occurred in March 1999, ending a 2-year process from specification
availability to certification/qualification of the resulting DOCSIS 1.0 equipment. Rapid deployment of
DOCSIS 1.0 equipment began in 1999, and the pace of deployment has increased ever since. (Note:
The success of DOCSIS deployment sometimes masks the fact that the Cable industry has only been
delivering DOCSIS equipment to subscribers for about two-and-a-half years, i.e. as a technology, it is
still in its formative years and will continue to evolve and improve as technological advancements
become available.)

The second standard (DOCSIS 1.1) was released as an Interim specification in March 1999. It is
interesting to note that the availability of the DOCSIS 1.1 specification coincides with the first
certification/qualification of DOCSIS 1.0 equipment. In the early days of DOCSIS 1.1 equipment
development, many vendors (especially CMTS vendors) planned to add simple software upgrades to
their DOCSIS 1.0 equipment to create DOCSIS 1.1 equipment. However, implementing the DOCSIS
1.1 features inside of legacy DOCSIS 1.0 hardware proved to be extremely challenging. In addition,
the arrival of the DOCSIS 1.1 era also marked the beginnings of a new class of CMTS equipment that
came to be known as “Carrier Class CMTSs” or “Next-gen CMTSs.” This new generation of
equipment introduced many novel features outside of the scope of the DOCSIS 1.1 specification, such
as scalability, reliability, enhanced observability, and wire-speed performance. Many of these features
were being added in preparation for future telephony-over-IP services that would be offered over the
hybrid fiber/coax (HFC) plant. As a result, many equipment vendors had to add many new elements
to their previous designs, so the development stage took longer than originally expected. In addition,



many vendors came to realize that the DOCSIS 1.1 specification itself was much more complicated
than a simple point release on the DOCSIS 1.0 specification (as the 1.1 numbering would imply). As a
result, the development of DOCSIS 1.1 equipment and the development of corresponding testing
programs at CableLabs also took longer than originally expected. Interoperability testing occurred
throughout 2000 and 2001, and the first DOCSIS 1.1 certifications (for CMs) and qualifications (for
CMTSs) occurred in September 2001, ending a two-and-a-half year process from DOCSIS 1.1
specification availability to the certification/qualification of equipment. DOCSIS 1.1 equipment
deployments began in the fourth quarter of 2001, but the deployment rates were initially hampered by
a slowed economy and by the small number of vendors that had successfully achieved
certification/qualification for the very complicated DOCSIS 1.1 specification. However, the
deployment rates were beginning to show some acceleration in first half of 2002.

The third standard (DOCSIS 2.0) was released as an Interim specification in December 2001. This
release occurred three months after the first DOCSIS 1.1 equipment was certified/qualified. Looking
into the future of DOCSIS 2.0 development is difficult at this point in time, but the current DOCSIS
2.0 program plan at CableLabs calls for interoperability testing to occur in second quarter of 2002, and
it calls for Certification Waves to begin in third quarter of 2002. [1] These ambitious plans may be
achievable, but past experience indicates that other DOCSIS specifications required from two to two-
and-a-half years between specification availability and the first certifications/qualifications of
equipment. Even if those typical schedules are compressed during the development of DOCSIS 2.0, it
may still take well into 2003 before a large number of equipment vendors are producing full DOCSIS
2.0-certified/qualified equipment. Some equipment vendors may opt to deliver equipment with
DOCSIS 2.0 features earlier than others, but to provide delivery on an expedited schedule, the
delivered equipment may have to initially sacrifice many of the “next-gen” features that are now
expected by the MSOs. Other equipment vendors may opt to deliver subsets of the DOCSIS 2.0
features (such as ATDMA only) in phased releases throughout the next two years.

DOCSIS text text
DOCSIS
1.0 Spec 1.0 Cert

DOCSIS text text
DOCSIS
1.1 Spec 1.1 Cert

DOCSIS DOCSIS
text text text

2.0 Spec 2.0 Cert ?

1997 1998 1999 2000 2001 2002 2003 time

Figure 1 - DOCSIS Time-line

The time-lines for the various DOCSIS developments are shown in Figure 1.



Feature Evolutions Leading up to DOCSIS 2.0
In order to understand the reasons for adding DOCSIS 2.0 features to the list of features already
provided in the DOCSIS 1.0 and DOCSIS 1.1 specifications, it is important to understand the features
that already exist in the preceding specifications. Particular attention must be paid to the MAC and
PHY layers in the preceding specifications. It is also important to understand the motives and goals
behind each of the preceding specifications.

Each of the DOCSIS specifications augmented the features of the previous specification with new
feature sets that provided more Cable Data functionality to the system operators and their subscribers.
In this section, the primary features contained in each of the preceding DOCSIS specifications will be
outlined.

DOCSIS 1.0 Features
The DOCSIS 1.0 specification can be viewed as the starting point for all present and future Cable
Data services. The principle focus of the DOCSIS 1.0 specification was to create a means of
transporting IP data bi-directionally across the existing HFC plant between subscriber devices and the
Internet. The defined transport architecture had to be compatible with the existing video delivery
services that were already resident on the HFC plant.

The DOCSIS 1.0 specification can be viewed as the starting point for all present and future Cable
Data services. It defines the fundamental mechanisms for moving data up and down the HFC plant,
and it also defines the way that different sub-systems will interact with one another in a fully deployed
Cable Data network. The DOCSIS 1.0 specification defines basic vanilla, “Best Effort” data transport
between the subscriber and the Internet. As a result, it represents the baseline Cable Data architecture
for the Cable industry. This baseline architecture is illustrated in Figure 2 with the two key
components (the CMTS and the Cable Modem) highlighted in yellow.




Telephony
PSTN
Gateway

Video 1 Optical
CMTS
Dwnstream 50-860
Video 2 Transceivers
RF MHz
Headend
Mod Downstream Combiner
Backbone Router Network Data E/O Fiber
Network
Interface Node
Upstream Upstream O/E Fiber
Demod Pairs
Data Splitter &
5-42
Filter
MHz
Bank HFC

Local
Coaxial
Servers Operations Security &
(DHCP, Support Access Distribution
TFTP, System Controller Leg
TOD, etc.)

Distribution Hub or Headend

Cable Modem

CPE (PC)

Figure 2 - Baseline Cable Data Architecture

The DOCSIS 1.0 specification was the successful mix of compromise proposals from several different
vendors, system operators and Internet Service Providers. The members of the MCNS consortium
determined the final content of the DOCSIS 1.0 specification. After much debate, the MCNS
consortium decided that the DOCSIS 1.0 specification should include means of providing all of the
following features:

1) Uniform and consistent service as seen by any subscriber
2) Open, non-proprietary operations that permit equipment from multiple vendors to interoperate
3) CMs with low power consumption (4-10 W) that could ultimately be sold in a retail market
with no user-configurable parameters
4) Asymmetric transport of data with more downstream bandwidth than upstream bandwidth to
match the asymmetric data flows of most Internet applications of the time (i.e. Web surfing)
5) Efficient downstream transport of data encapsulated in MPEG streams with 27-36 Mbps of
total user bandwidth carried in a single 6 MHz-wide channel inside of the typical HFC
downstream spectrum (88-860 MHz center frequencies)
6) Support for either 64QAM (30.341646 Mbps) and 256QAM (42.884296 Mbps) operation in
the downstream channel
7) Flexible, robust upstream transport of data with 0.32-10.24 Mbps of total bandwidth carried in
a single 0.2-3.2 MHz channel inside of the typical HFC upstream spectrum (5-42 MHz center
frequencies)
8) Simple security measures that provide assurances of privacy for data transported over the
shared HFC plant




9) Simple network management of equipment via the Simple Network Management Protocol
(SNMP)
10) Remote software upgrades for improvements

While detailed analysis of all of the features in the DOCSIS 1.0 specification is beyond the scope of
this paper, a glance at some details behind the upstream PHY and MAC layers will undoubtedly prove
beneficial.

The DOCSIS 1.0 upstream MAC assumes that Frequency-Division Multiplexing and Time-Division
Multiple Access (FDM/TDMA) techniques will be used to coordinate the activity of all of the
attached CMs on the shared upstream resource. This implies that multiple upstream channels will
typically be squeezed into the single 5-42 MHz upstream spectrum, but each CM will be assigned to a
single, particular upstream channel frequency (using FDM techniques). However, multiple CMs can
be assigned to the same upstream channel, so each CM that needs to transmit data up the HFC plant
must request bandwidth, and the CMTS will dynamically assign it a burst interval (time-slot) during
which it can send its data without interfering with the other CMs on that particular upstream channel.
Thus, many CMs time-share the bandwidth on a single upstream channel (using TDMA techniques).

The DOCSIS 1.0 PHY specification permitted the use of either 4-point Quadrature Phase Shift
Keying modulation (QPSK) or 16-point Quadrature Amplitude Modulation (16QAM) to encode the
signal bits into RF symbols for upstream transmission on the HFC plant. QPSK encodes two bits
within each symbol, while the more efficient 16QAM encodes four bits in each symbol (Figure 3).
The modulation format can be changed for each of the burst intervals.

Q Q
0111 0101 1101 1111
01 11
0110 0100 1100 1110

I 0010 0000 1000 1010 I

00 10
0011 0001 1001 1011

(a) QPSK symbol mapping (b) 16QAM symbol mapping
(2 bits/symbol) (4 bits/symbol)

Figure 3 - Signal constellations for QPSK and 16QAM




Each upstream channel connecting CMs to a CMTS must be centered in the 5-42 MHz portion of
the HFC spectrum, but different channels will typically be set on different center frequencies. In
addition, each channel must be assigned one of five different spectral widths. The assigned
spectral width will determine the upstream symbol rate permitted on the particular channel, and
the symbol rate combined with the modulation format (QPSK or 16QAM) will determine the
upstream bit-rate on the channel. Table 1 below indicates the various combinations of upstream
channel parameters permitted by the DOCSIS 1.0 specification.

Channel Width Symbol Rate Bit-rate for QPSK Bit-rate for 16QAM
(kHz) (ksymbols/sec) (kbps) (kbps)
200 160 320 640
400 320 640 1,280
800 640 1,280 2,560
1,600 1,280 2,560 5,120
3,200 2,560 5,120 10,240
Table 1 - DOCSIS 1.0 Upstream Channel Parameters

(Note: All upstream transmissions from a CM to a CMTS use a 25% Square Root Raised Cosine for
Symbol Shaping which yields the symbol rate numbers shown in Table 1).
The bit-rate associated with an upstream channel is closely tied to two fundamental characteristics of
the channel: the symbol rate (R) and the modulation format. The modulation order (M) is defined as
the number of points in the signal constellation, and the channel bit-rate is therefore given by
R*log2(M). Thus, an increase in the upstream channel bit-rate requires one or more of the following
changes:
1) an increase in the upstream symbol rate R
2) an increase in the spectral efficiency (modulation order M) of the modulation format.
Unfortunately, this increase in upstream channel bit-rate cannot be accomplished without paying a
price. The price is the resulting increase in required HFC plant signal-to-noise ratios that are required
to produce acceptable bit-error-rate levels for higher symbol rates and higher-order modulation
formats. For example, the points in the 16QAM signal constellation are more closely packed than the
points in the QPSK signal constellation (see Figure 3). Thus, the bit-rate benefits of 16QAM do not
come for free, because 16QAM requires a higher signal-to-noise ratio for acceptable bit-error-rate
levels than QPSK. In a similar vein, higher symbol rates result in less time for symbol sampling, so
errors due to noise are also more likely to occur in high symbol-rate signals than in low symbol-rate
signals. In addition, higher symbol rates use a wider portion of the upstream spectrum. In addition to
being a precious resource that may or may not be available, this wider portion of the spectrum also
permits more noise power to be coupled into the channel (producing lower signal-to-noise ratios). As
a result, HFC plants with even moderate levels of noise may produce high bit error rates when using
16QAM or high symbol rates, so many system operators are forced to by-pass the bandwidth benefits
of 16QAM and high symbol rates and they are forced to use QPSK at lower symbol rates (1,280
ksymbols/sec is common). As a result, many system operators are limited to raw bit-rates of (1.28
Msymbols/sec)x(2 bits/symbol for QPSK)=2.56 Mbps on their upstream channels.




TDMA (Time-Division Multiple Access) technology permits multiple users (CMs) to share the
bandwidth within an upstream channel by allowing each of the users to transmit by themselves within
a unique burst interval (time slot). These burst intervals can be variable in length. There are two
fundamental types of burst intervals that can be specified by the CMTS for upstream traffic transport-
contention burst intervals and non-contention burst intervals. Defining the burst interval duration,
defining the burst interval type (contention or non-contention), and defining the CM associated with
each non-contention burst interval are some of the fundamental tasks performed by the CMTS
operating in a TDMA mode of operation.

Contention burst intervals define windows of time that can be shared by all CMs in a CSMA-like
fashion. As would be expected, date corruption due to collisions can occur during contention burst
intervals, because multiple CMs can be simultaneously transmitting in a single burst interval window.
When this occurs, standard back-off and re-transmission techniques are employed.

Non-contention burst intervals define a window of time during which a particular, pre-assigned CM
can transmit upstream data. Intelligent scheduling algorithms in the CMTS are used to assign a unique
CM to a particular burst interval. The results of the scheduling algorithm are communicated to all
CMs through MAPs that are periodically (once every 1-10 msec) injected into the downstream
channels going from the CMTS to the CMs.

CM #1 CM #2
Transmission Transmission
(16QAM & (QPSK &
2.56 Msym/sec) 2.56 Msym/sec)

Packet Packet
Data Data
Guard MAC Guard MAC
Time Header Codeword Codeword Time Header Codeword Codeword

Preamble Preamble
Information FEC Parity Minislot Information FEC Parity Minislot
(data) Bytes Padding (data) Bytes Padding

time

Figure 4 - Temporal sequencing of consecutive upstream burst intervals




The temporal sequencing of consecutive burst intervals is illustrated in Figure 4. Note that every burst
interval on a particular upstream channel must use the same symbol rate, but each burst interval can
use a different modulation format. The user data is transmitted within the codeword regions of the
packet data field.

As noted in Figure 4, there are several required fields in the transmitted data stream that constitute
overhead. These include the guard time (used to separate the end of one CM’s transmission and the
start of another CM’s transmission), the preamble (used by the receiver to phase lock onto the arriving
data from a new CM transmission), the MAC header (used to identify the source and/or the type of the
data transmission), the Forward-Error Correction (FEC) parity bytes (used to correct random errors
that might occur due to noise within the packet data), and the Minislot padding (used to extend the
burst interval to a Minislot boundary). Under normal operating conditions, the overhead can account
for 5-30% of the channel bandwidth depending on the settings that are used.

Typically, the required guard time period between two successive burst interval transmissions will be
a function of symbol rate. Typical numbers might be eight symbol periods for 160 ksymbol/sec to 640
ksymbol/sec rates, and sixteen symbol periods for 1.28 Msymbol/sec to 5.12 ksymbol/sec rates.

The preamble field is programmable, and its length can range from zero to 128 bytes. The preamble
field period will be a function of symbol rate, modulation format, and channel noise levels. Typical
numbers might be eight bytes for QPSK at 160 ksymbol/sec to 640 ksymbol/sec rates, twelve bytes
for QPSK at 1.28 Msymbol/sec to 5.12 ksymbol/sec rates, sixteen bytes for 16QAM at 160
ksymbol/sec to 640 ksymbol/sec rates, and twenty-four bytes for 16QAM at 1.28 Msymbol/sec to
5.12 ksymbol/sec rates.

For data packets, the MAC header field will typically be a fixed length of six or eight bytes (although
extended MAC headers of up to 246 bytes can also be used).

In an upstream channel, errors can often occur that are due to burst noise. This type of noise typically
corrupts a small numbers of bytes in the transmitted data block. In an attempt to combat these errors, a
Reed-Solomon Forward-Error Correction (RS-FEC) scheme can be used in the DOCSIS 1.0
specification. This scheme segments the data into multiple codewords and adds correcting parity bytes
related to the data within the codeword. The use of Forward-Error Correction introduces a bandwidth
penalty due to the overhead of the correcting parity bytes. The Forward-Error Correction algorithm
used in DOCSIS 1.0 permits the correction of up to ten errored bytes within a codeword, and the
number of parity bytes actually used for Forward-Error Correction is programmable.

For example, assume that it is desired that the Forward-Error Correction algorithm be capable of
correcting T errored bytes within a codeword. Thus, 2T parity bytes must be added within each
codeword. Assume that there are k information bytes stored within each codeword. Then for a data
block of length L bytes, there will be ceil(L/k) codewords created. The parity bytes are at the end of
each codeword region. Typical values might be k=40 to 220 information bytes and T=4 to 10
correctable bytes. Selection of these values must ensure a balance between the required error
correction given the channel noise and the resulting overhead of the additional Forward-Error
Correction parity bytes.



Minislot padding is added to extend burst intervals to minislot boundaries, and will often add an
average of eight to sixteen bytes.

It is important to realize that an upstream TDMA channel works by permitting multiple CMs to share
the channel. CMs must take turns using the upstream burst intervals, and the CMTS is responsible for
scheduling the CMs appropriately. At any moment in time, useful transmission is occurring if and
only if one and only one CM is transmitting in the upstream channel. If the channel supports a raw bit-
rate of 2.56 Mbps, then a particular CM that is assigned the channel for a particular burst interval will
be the sole owner of that bandwidth and have access to all of the 2.56 Mbps transfer rate during the
duration of that burst interval. For example, if a particular CM is assigned a 1 msec burst interval on
that 2.56 Mbps upstream channel, then the CM is capable of transferring up to (2.56 Mbps)x(1
msec)/(8 bits/byte)=320 bytes in its burst interval (ignoring the overhead required for guard time,
preamble, MAC Header, and Forward-Error Correction parity bytes). If on average, a particular CM is
granted ten percent of the burst intervals on a 2.56 Mbps upstream channel, then that CM will have
access to roughly 256 kbps of bandwidth in the upstream channel (ignoring the overhead required for
guard time, preamble, MAC Header, and Forward-Error Correction parity bytes).

DOCSIS 1.1 Features
For all of its success, DOCSIS 1.0 was, for the most part, providing plain vanilla, Best-Effort
broadband data transport between subscribers and the Internet. As the forward-looking thinkers
among the DOCSIS architects began to visualize the future, they realized that there would be a
definite need for some improvements over the original DOCSIS 1.0 feature set. These needs led to the
DOCSIS 1.1specification.

DOCSIS 1.1 had several fundamental goals:

1) Add an 8-tap, symbol-spaced linear pre-equalizer to CMs to improve the upstream
channel’s ability to correctly receive signals in the presence of micro-reflections and
other HFC plant distortions
2) Remain backwards compatible with DOCSIS 1.0
3) Add Quality of Service (QoS) features to DOCSIS 1.0 to ensure that Voice over IP
(i.e. PacketCable) could be provided in the near future
4) Add Quality of Service (QoS) features to DOCSIS 1.0 to ensure that tiered data
services and other delay-sensitive applications could be supported in the near future
5) Add the ability to classify packets from one cable modem into different QoS service
flows with different performance levels
6) Improve the HFC bandwidth efficiencies through the use of fragmentation,
concatenation, and payload header suppression (especially for the smaller, jitter-
intolerant VoIP packets)
7) Add SNMPv3 capabilities to guarantee secure network management
8) Add CM authentication to the security mechanisms to guard against theft of service
9) Add improvements to the key and encryption processes to provide improved privacy
for data transported across the shared HFC
10) Add standardized methods for IP multicast support



11) Add IP filtering capabilities to permit the establishment of subscriber-dependent
firewalls
12) Augment the existing set of counts and statistics with new counts and MIBs that are
useful for performance monitoring and billing

While all of these goals are beneficial, most system operators have concentrated on the benefits of
QoS. Many clever QoS tools and features were added to the DOCSIS 1.1 specification that could be
used to create and manage advanced data, voice, and video services that were simultaneously flowing
across the same CMTS, the same HFC plant, and the same CM. Most of these tools manipulate the
settings of a “service flow.” A service flow can be defined as a set of packets flowing through the
CMTS or CM that share some unique, identifiable set of parameters (classifiers). Typically, all of the
packets within a service flow have a common source point and destination point within the Internet.
Associated with each service flow is a service level definition defining how a packet within that par-
ticular service flow should be treated by the network element. If an MSO provides these service level
definitions to their subscribers in the form of a service contract, the resulting contract is often defined
as a Service Level Agreement. Proper use of QoS and Service Level Agreements is likely to generate
many new services and many new sources of revenue for system operators.
For some operators, the first of these new revenue-generating services is likely to be Voice over IP
telephony service. The goal is to offer primary or secondary phone line service to their existing video
subscribers in a bundled package. CableLabs has developed the PacketCable specification to define
the architecture for Voice over IP telephony service in an MSO environment. This specification
defines the manner in which IP-based telephone calls are set up and torn down over the HFC plant,
and all of the approaches assume the existence of DOCSIS 1.1 QoS features within the network.

Another new revenue-generating service is tiered data service. This approach to marketing
acknowledges the fact that many existing cable TV subscribers are not willing to sign up for the data
service at a high price. The theory is that a tiered data service with low-priority subscribers paying less
(ex: $25 per month) and high-priority subscribers paying slightly more (ex: $40 per month) will
produce higher overall revenues than a single tier service offering at $40 per month. High-end
subscribers will still get their expected service levels, because their traffic is treated with higher
precedence than the low-end subscribers. Under most operating conditions, low-end subscribers will
experience much better throughput levels than they are currently experiencing with their dial-up
services. As a result, everybody is happy, and the MSO experiences higher revenues.

Many MSOs expect to bundle all of the DOCSIS 1.1-enabled services (video, voice, and data) into a
single package deal that is priced to lure subscribers away from their existing telephony service
providers, DSL providers, and dial-up Internet Service Providers.




The DOCSIS 2.0 Specification
From the discussions above, it should be apparent that the DOCSIS 1.0 specification laid the basic
foundations for simple data transport across the HFC plant and concentrated primarily on the
definition of a suitable set of PHY and MAC layer protocols to guarantee that data would be
efficiently transmitted across the cable. The DOCSIS 1.1 specification shifted the focus of the work to
QoS and other higher-level features that permitted advanced services to be mixed and offered over the
HFC plant.

In 2001, the architects of the DOCSIS 2.0 specification created a new specification in response to the
growing demand for more upstream bandwidth on the cable. These demands emerged as peer-to-peer
applications (such as interactive gaming, MP3 file exchanges, voice over IP telephony, etc.) and
business-to-business applications (such as T1 replacements) began to appear on the HFC plant. These
new applications demanded a more symmetrical transport of data than the asymmetrical applications
(i.e. Web surfing) that dominated the Internet in the past. In addition, upstream noise, HFC plant
impairments, and many legacy service offerings (such as previously-installed proprietary data
services, set-top box transmissions, constant bit rate (CBR) Cable Telephony services, etc.) were
consuming much of the available upstream bandwidth on the cable. (Note: Node splitting is one
technique that can help circumvent these problems, because it effectively decreases the number of
subscribers sharing an upstream spectrum. However, the costs associated with node splitting
oftentimes make this approach undesirable.)

To accommodate these new upstream bandwidth demands, the DOCSIS 2.0 specification shifted the
focus back to the PHY and MAC layer protocols in an attempt to augment the existing foundation
with some new and improved (and more complicated) modulation techniques. In particular, the
DOCSIS 2.0 specification focused on changes to the upstream PHY and MAC layers. Before
considering the actual benefits of these changes, it will prove beneficial to consider the original goals
behind the DOCSIS 2.0 specification. These included:

1) Remain backwards compatible with DOCSIS 1.0 and DOCSIS 1.1
2) Provide the ability to support more symmetrical data transport
3) Increase the capacity in each upstream channel
4) Increase the spectral efficiency (bps/Hz) of the upstream spectrum
5) Provide for more noise immunity within the upstream channels
6) Correct any problems/oversights found in the DOCSIS 1.1 specification

From the above list, a few noticeable elements are excluded from the specification. First, DOCSIS 2.0
does not provide any capacity enhancements for the downstream channel. (Note: Some chipset
vendors are providing proprietary solutions with advanced downstream improvements such as
1024QAM embedded within their DOCSIS 2.0 chipsets.) In addition, DOCSIS 2.0 does not provide
its capabilities with the promise of a simple software upgrade to DOCSIS 1.1 equipment. The
equipment requires new DOCSIS 2.0-capable hardware if the new features are to be enabled.




Comparing the list of DOCSIS 2.0 goals with the goals listed for DOCSIS 1.0 and DOCSIS 1.1, it is
the opinion of the authors that the changes associated with DOCSIS 2.0 are less impacting than the
changes associated with DOCSIS 1.0 or DOCSIS 1.1. The delta between DOCSIS 1.0 and DOCSIS
1.1 impacts a large amount of the operations and provisioning work carried out by MSOs, whereas the
delta between DOCSIS 1.1 and DOCSIS 2.0 basically affects the physical transport of bits on the
cable. In fact, most of the changes for DOCSIS 2.0 will appear in the PHY and MAC layer chip-sets
in the CM that place the modulated waveforms on the upstream cable and in the PHY and MAC layer
chip-sets in the CMTS that extract the modulated waveforms from the upstream cable. Nevertheless,
these DOCSIS 2.0 modulation changes do require new hardware and software (for CMs and CMTSs).
In addition, the changes are likely to have an impact on the permitted subscriber services and the
planned HFC plant architectures in the future. As a result, it is advantageous to examine these changes
in some level of detail.

TDMA (as briefly described in an earlier section) is the catch all phrase defining the upstream
modulation technique used for DOCSIS 1.0 and DOCSIS 1.1. In DOCSIS 2.0, two new modulation
techniques have been proposed as improvements over the earlier TDMA scheme. These new
modulation techniques are known as Advanced Time-Division Multiple Access (ATDMA) and
Synchronous Code-Division Multiple Access (SCDMA). DOCSIS 2.0 requires that the CMTS and
the CM support all three of these modulation techniques (TDMA, ATDMA, and SCDMA).

It will be shown that the TDMA/ATDMA approaches are quite different from the SCDMA approach.
In particular, one can draw some good analogies between these technologies and common
communication forums. For example, it will be shown that TDMA/ATDMA are similar to the
communication forum used in conference presentations. In particular, each speaker takes control of
the podium for a specific period of time, and they must speak rapidly to communicate their
information before relinquishing the podium to the next speaker (who must repeat the process).
SCDMA, on the other hand, is similar to a party where many conversations are occurring in parallel,
but the speaker and listener of each conversation are only “tuned in” to their information exchange,
and the other conversations merely create background noise. To make the analogy even more correct,
assume that each of the many conversations at the party is being spoken in a different language so that
the other conversations are not even understood by the two people in a particular conversation.

Whether employing ATDMA or SCDMA, most of the changes specified by the DOCSIS 2.0
specification can be sub-divided into two fundamental areas of concern: upstream noise mitigation
improvements and upstream bandwidth improvements. The following sections will explore the details
of ATDMA and SCDMA, and they will also highlight the noise mitigation improvements and the
upstream bandwidth improvements provided by each of the technologies.




Characteristics of Advanced Time-Division Multiple Access (ATDMA)
In general, the DOCSIS 2.0 ATDMA scheme is very similar to the DOCSIS 1.X TDMA scheme, but
ATDMA includes some important enhancements.

As their names would imply, both TDMA and ATDMA are Time-Division Multiple Access
technologies that permit multiple users (CMs) to share the bandwidth within an upstream channel by
allowing each of the users to transmit by themselves within a unique burst interval (time slot). This is
why TDMA and ATDMA transmissions use the bandwidth in a manner similar to the way in which
speakers share the podium in a conference: one speaker at a time.

In both the TDMA and the ATMDA case, burst intervals can be variable in length, and both
contention burst intervals and non-contention burst intervals can be specified by the CMTS for
upstream traffic transport. The temporal sequencing of consecutive burst intervals illustrated in
Figure 4 can be applied to the ATDMA space as well as the TDMA space.

Let us now explore the improvements enabled by the ATDMA approach specified within DOCSIS
2.0.

Upstream Bandwidth Improvements Provided by ATDMA

The ATDMA specification provides many new techniques that will enable MSOs to operate upstream
channels with higher throughputs (assuming the noise mitigation techniques described below will
permit the higher throughput operation in the presence of the channel noise). Several mechanisms
were added to the ATDMA specification to permit this improved operation:

1) Three new upstream channel modulation formats were added by ATDMA. These include 8-
point QAM (8QAM), 32-point QAM (32QAM), and 64-point QAM (64QAM). The
modulation format can be changed for each of the burst intervals.
2) A higher symbol rate of 5.12 Msymbol/sec was added by ATDMA.
3) The preamble can be transmitted with higher power to permit synchronization to occur more
rapidly. This may permit the use of shorter preambles, which will eliminate some of the
overhead associated with ATDMA transmission. This results in more bandwidth available for
the transmission of user traffic.
4) The maximum preamble length was increased to 1536 bits to aid in channel synchronization
when using the higher 6.4 MHz channels. (Note: DOCSIS 1.X limited the preamble length to
1024 bits).




Channel Symbol Rate Symbol Rate Bit-rate Bit-rate Bit-rate Bit-rate
Width R R for for for for
(kHz) (ksymbols/sec) (ksymbols/sec) 8QAM 16QAM 32QAM 64QAM
(kbps) (kbps) (kbps) (kbps)
200 160 320 480 640 800 960
400 320 640 960 1,280 1,600 1,920
800 640 1,280 1,920 2,560 3,200 3,840
1,600 1,280 2,560 3,840 5,120 6,400 7,680
3,200 2,560 5,120 7,680 10,240 12,800 15,360
6,400 5,120 10,240 15,360 20,480 25,600 30,720

Table 2 - ATDMA Upstream Channel Parameters

Table 2 indicates the various combinations of upstream channel parameters permitted by the ATDMA
specification.

Upstream Noise Mitigation Improvements Provided by ATDMA
The ATDMA specification provides many new techniques that will enable MSOs to operate upstream
channels within noisy environments. These include:

1) The maximum number of Reed-Solomon Forward-Error Correction parity bytes within each
codeword was increased so that up to sixteen errored bytes could be corrected. This increases
the overall immunity of the transmission to lengthy burst errors at the expense of added
overhead for the parity bytes. (Note: DOCSIS 1.X only permitted up to ten errored bytes to be
corrected.)
2) The number of taps within the CM-based linear pre-equalizer was increased so that up to 24
symbol-spaced taps could be programmed. As a result, micro-reflections with even more
delay can be suppressed. In addition, the shorter symbol spacings that result from the use of
5.12 Msymbol/sec channels in DOCSIS 2.0 can also be more readily accommodated. In
addition, most vendors have greatly enhanced their algorithms for pre-equalizer training.
(Note: DOCSIS 1.X only permitted up to eight symbol-spaced taps to be programmed.)
3) Vendor-specific (proprietary) ingress noise cancellation techniques based on advanced digital
signal processing have also been added to the CMTS receivers by all of the DOCSIS 2.0
chipset vendors. These techniques identify common noise types found in the upstream
channel and attempt to intelligently filter them out of the ATDMA data stream.




4) The bytes within multiple codewords are interleaved (mixed) so that bytes from a single
codeword are no longer transmitted consecutively within the upstream channel. As a result, a
burst error whose duration spans multiple bytes will corrupt only a few bytes from each of the
codewords instead of corrupting many bytes from a single codeword. This increases the
overall immunity of the transmission to lengthy burst errors, because the Reed-Solomon
Forward-Error Correction techniques can easily correct errors if the number of errored bytes
per codeword is kept to a minimum. (Note: DOCSIS 1.X transmitted the bytes for a single
codeword consecutively, so a lengthy burst error could corrupt many bytes within a single
codeword and make it difficult for the Forward-Error Correction techniques to correct all of
the byte errors).
In general, all of these noise mitigation techniques should aid the upstream transmission of
signals in the presence of many different types of channel noise, including Additive White
Gaussian Noise (AWGN), impulse noise, burst noise, and micro-reflections.




Characteristics of Synchronous Code-Division Multiple Access
(SCDMA)
Whereas the DOCSIS 2.0 ATDMA scheme and the DOCSIS 1.X TDMA scheme are somewhat
similar in basic structure and operation, the DOCSIS 2.0 Synchronous Code-Division Multiple Access
(SCDMA) scheme is a member of an entirely different genre of transmission techniques. As stated
earlier, SCDMA uses the bandwidth in a manner similar to the way in which people at a party can
have many different parallel conversations in different languages and not interfere with one another.
SCDMA transmission has been described as a “spread-spectrum” technology or a “spread-time”
technology. Neither of these terms truly describes the clever set of tricks that are used in SCDMA. Let
us attempt to describe how SCDMA actually operates (at a high level).

As a starting point, consider a baseline 3.2 MHz-wide upstream channel that is capable of transporting
a DOCSIS 1.X TDMA signal using 16QAM. Using TDMA technology, a single cable modem can
transmit in the upstream channel in a given burst interval. The transmission produces a sequential
stream of 16QAM symbols, and each symbol has a period of 390.625 nsec. The permitted symbol rate
in the channel is 2.56 Msymbol/sec, and the resulting bit-rate (with four bits per symbol) is 10.24
Mbps.

Now assume that we want to use the same 3.2 MHz-wide channel to transmit a stream of 16QAM
symbols using SCDMA transmission instead of TDMA transmission. From a high-level point-of-
view, SCDMA modifies the original symbol-stream using two clever tricks. The first trick is known as
symbol spreading. Symbol spreading requires that each symbol be stretched (or spread) in time by a
factor of 128, so a single spread symbol would have a period of (390.625 nsec)*(128)=50 usec. The
permitted symbol rate for this single SCDMA symbol stream in the channel is 20 ksymbol/sec, and
the resulting bit-rate (with four bits per symbol) is 80 kbps (which is 1/128th of the bit-rate for the
TDMA symbol stream carried in the same 3.2 MHz-wide channel).

The longer symbol period in SCDMA transmission is known as the “spreading interval.” Using
Fourier Analysis techniques, it can be shown that these spread symbols consume only 1/128th of the
spectral bandwidth that is used by the shorter-period TDMA symbols (see Figure 5(a) and Figure
5(b)).




y(t) 390.625 nsec Y(f)
signal F

0 50 time (usec) 0 5 freq (MHz)
(a) TDMA signal

y(t) 50 usec Y(f)
spread F
signal

0 50 time (usec) 0 50 freq (kHz)
(b) SCDMA spread signal

y(t) 390.625 nsec chip Y(f)
F

0 50 time (usec) 0 5 freq (MHz)
(c) SCDMA-encoded signal
Figure 5 - Signals and Fourier transforms of signals

The second clever trick used by SCDMA is to re-use the entire spectrum within the channel (since the
spectral bandwidth of the spread symbol is only 1/128th of the spectrum in the original TDMA signal).
SCDMA accomplishes this by multiplying each spread symbol by a spreading code containing a
unique string of 128 code symbols. Each code symbol must be assigned either a +1 value or a –1
value, and these code symbols are typically called “chips.” Since 128 code symbols (or chips) must
fill the entire 50 usec spreading interval, the chip duration is (50 usec)/128 =390.625 nsec. It is
important to note that the SCDMA chip duration is identical to the period of the symbols used in the
original TDMA case, so the resulting SCDMA chip rate is identical to the original TDMA symbol
rate. Fourier Analysis techniques can be employed to show that the bandwidth utilized by the stream
of SCDMA-encoded spread symbols is practically the same as the bandwidth utilized by the original
TDMA symbol stream (see Figure 5(a) and Figure 5(c)).

The receiver (de-spreader) for an SCDMA transmission system is actually a matched filter or
correlator that correlates the received data stream with the spreading code associated with the
desired transmitter.

There are many different spreading codes (combinations of +1 and –1 chips) that can be
specified. If a particular sequence of +1 and –1 chips associated with one spreading code are
used to fill the elements of a column vector x and if a different sequence of +1 and –1 chips
associated with a second spreading code are used to fill the elements of a second column vector
y, then employing a simple concept from linear algebra, the two vectors are said to be orthogonal



if the inner product of the two vectors is zero (xTy=0). The selection of orthogonal spreading
codes provides a major benefit, because symbol streams from many different sources (cable
modems) can be SCDMA-encoded using different spreading codes and they can then be
combined on the same upstream channel. It can be shown that any one of the source symbol
streams can be recovered from the resulting aggregated mix of symbol streams if the spreading
codes from each source are orthogonal to one another. The receiver at the CMTS can “tune” to a
symbol stream from a particular source using the unique spreading code associated with that
particular source. The recovery of a particular symbol stream from the aggregated mix of symbol
streams is accomplished by multiplying the aggregated mix of symbol streams by the unique
spreading code associated with the source and summing the terms to produce a weighted version
of the desired symbol stream at the receiver. This process is known as “de-spreading” the
transmitted symbol stream, and it essentially calculates the inner product of the combined
streams (Ax+By) and the spreading code for the desired source. For example, x would be used to
de-spread symbols from source #1. The result of this inner product calculation is (Ax+By)Tx =
AxTx+ByTx = AxTx+0 = A*|x|2, which is a weighted version of the original spread symbol A.
All of these operations are illustrated in Figure 6.

Source
A [-A +A]
#1
X

Spreading
code Modulator
xT=[-1 +1]
+
Spreading
code Modulator
yT=[-1 -1]

Channel
X
Source
#2 B [-B -B]

[-A-B +A-B] -1
+1 =2A

[-A-B +A-B] 2A
Demod Correlator
Source #1 Output
spreading
code
xT=[-1 +1]
Figure 6 - Typical SCDMA channel with two sources




It should be apparent that de-spreading works only if x and y are orthogonal. If the spreading codes
from different transmitters are not phase aligned, then orthogonality between the spreading codes is
sacrificed, and the recovery of the original spread symbols becomes prone to errors. Thus, the transmit
clocks within the SCDMA sources (cable modems) must maintain a high degree of accuracy to
maintain adequate chip-level phase alignment and modulator carrier phase alignment. This
necessitates synchronous operation within SCDMA transmitters. The required SCDMA cable modem
ranging accuracy must be approximately +/- 0.01 of the nominal symbol period, which ensures that
the spreading codes from different cable modems remain fairly well synchronized.
In DOCSIS 2.0 SCDMA operation, up to 128 simultaneous symbol streams (with different
spreading codes) can be driven by many different cable modems. A burst from a single cable
modem may be transmitted on two or more spreading codes within a frame, so up to 64 cable
modems could be simultaneously transmitting in a frame. The CMTS mapping algorithm
controls which combinations of cable modems are transmitting on a frame-by-frame basis. This
mapping algorithm is responsible for changing the number of spreading codes assigned to each
cable modem, and it can also change the frame size, so the algorithm can maintain tight control
over the amount of bandwidth assigned to each cable modem (see Figure 7). The intelligence
within the mapping algorithm will ultimately determine the efficiency and fairness of the
SCDMA transport scheme.

burst interval burst interval burst interval burst interval
w/ 16QAM & w/ QPSK & w/ QPSK & w/ 8QAM &
2.56 Msym/sec 2.56 Msym/sec 2.56 Msym/sec 2.56 Msym/sec

burst interval burst interval burst interval burst interval
w/ 8QAM & w/ 32QAM & w/ 64QAM & w/ 8QAM &
2.56 Msym/sec 2.56 Msym/sec 2.56 Msym/sec 2.56 Msym/sec

frame 1 frame 2 frame 3
code 127 burst interval
w/ 64QAM &
CM #4 CM #4 CM #4 2.56 Msym/sec
code 96
code 95
CM #3 CM #3
code 64

code 63
CM #2 CM #2
code 32
code 31

CM #1 CM #1

code 0

time
Figure 7 - Example of multiple CMs using different spreading codes




Upstream Bandwidth Improvements Provided by SCDMA

SCDMA provides many new techniques that will enable MSOs to operate upstream channels
with higher throughputs. [2] SCDMA can use all of the bandwidth improvement techniques
defined for ATDMA. In addition, SCDMA may permit shorter preambles due to the use of
synchronous transmission. SCDMA also offers another modulation format known as 128-point
QAM or 128QAM. This format can only be enabled when a particular noise mitigation technique
known as Trellis-Coded Modulation (TCM) is being used. 128QAM with TCM provides the
same bit-rate performance as64QAM without TCM.

Channel Symbol Rate R Bit-rate for Bit-rate Bit-rate Bit-rate Bit-rate
Width (ksymbols/sec) QPSK for 8QAM for for for
(kHz) (kbps) (kbps) 16QAM 32QAM 64QAM
(kbps) (kbps) (kbps)
1,600 1,280 2,560 3,840 5,120 6,400 7,680
3,200 2,560 5,120 7,680 10,240 12,800 15,360
6,400 5,120 10,240 15,360 20,480 25,600 30,720

Table 3- SCDMA Upstream Channel Parameters (without TCM enabled)

Table 3 indicates the various combinations of upstream channel parameters permitted by the SCDMA
specification when Trellis-Coded Modulation (TCM) is not enabled. Table 4 indicates the various
combinations of upstream channel parameters permitted by the SCDMA specification when Trellis
Coded Modulation is enabled. It should be noted that the three lowest symbol rates (160
ksymbols/sec, 320 ksymbols/sec, and 640 ksymbols/sec) that are permitted by TDMA and ATDMA
operation are not permitted by SCDMA operation. Note also that with TCM enabled (Table 4), one of
the bits in each symbol is borrowed for use as the TCM code bit.

Channel Symbol Rate R Bit-rate Bit-rate Bit-rate Bit-rate Bit-rate Bit-rate
Width (ksymbols/sec) for for for for for for
(kHz) QPSK 8QAM 16QAM 32QAM 64QAM 128QAM
(kbps) (kbps) (kbps) (kbps) (kbps) (kbps)
1,600 1,280 1,280 2,560 3,840 5,120 6,400 7,680
3,200 2,560 2,560 5,120 7,680 10,240 12,800 15,360
6,400 5,120 5,120 10,240 15,360 20,480 25,600 30,720

Table 4- SCDMA Upstream Channel Parameters (with TCM enabled)




Upstream Noise Mitigation Improvements Provided by SCDMA
SCDMA provides many new techniques that will enable MSOs to operate upstream channels within
noisy environments. SCDMA can use all of the noise mitigation techniques defined for ATDMA. In
addition, SCDMA offers several other noise mitigation techniques to help provide even more
robustness in the presence of impulse noise and burst noise. These other tricks are directly related to
the symbol spreading function, the symbol de-spreading function, and the Trellis-Coded Modulation
function that are unique to the SCDMA specification.

SCDMA symbol spreading can lead to improved noise immunity for specific types of burst noise,
because burst noise is typically found to exist within a short duration of time. As an example, consider
a short noise burst that spans five symbols in the TDMA system of Figure 5(a). In the SDCMA
system of Figure 5(c), that same short noise burst will exist within a single spread symbol, corrupting
only five chips within that single spread symbol. As a result, the short noise burst will potentially
corrupt five symbols in the TDMA system, but it will potentially corrupt only one spread symbol in
the SCDMA system. Simple error correction schemes can be used to permit the single spread symbol
to be corrected in the SCDMA system, whereas slightly more complex error correction schemes must
be used to permit the five symbols to be corrected in the TDMA system.

SCDMA symbol de-spreading can lead to improved noise immunity for specific types of impulse
noise (whose bandwidth is narrow and band-limited). It can be shown that the de-spreading function
effectively spreads the spectrum of impulse noise across a broader spectral range, which effectively
attenuates the amplitude of the noise within the frequency range of the recovered symbol stream. This
creates a higher effective signal-to-noise ratio for the SCDMA signals (when compared to their
counterpart TDMA or ATDMA signals), which leads to lower symbol error rates. This effect is
known as the “processing gain” of SCDMA, and the gain can be shown to be proportional to the
number of chips used in the spreading code. [3]

Trellis-Coded Modulation (TCM) is another technique added to the SCDMA solution that leads to
improved noise immunity. TCM combines the functions of coding and modulation to transmit
information with lower overall error probabilities. It uses a non-obvious approach in which the
number of points within a signal constellation is doubled to make room for coding bits that can
effectively be used for error correction. The doubling of points within a signal constellation would at
first appear to produce higher error rates for a given signal-to-noise ratio, because the points in the
signal constellation are more closely packed. However, the use of a carefully selected bit-level coding
scheme permits many receiver bit errors to be corrected, and the overall impact of error correction
over-rides the negative impact of a more densely packed signal constellation.




Combining DOCSIS 1.0, DOCSIS 1.1, DOCSIS 2.0, TDMA, ATDMA,
and SCDMA
The DOCSIS 2.0 specification recognizes the need for backwards compatibility, coexistence, and
interoperability between the different types of equipment that may be used on a single HFC plant. The
various combinations of CMTS and cable modem functionalities are illustrated in Figure 8, and the
resulting modes of operation for each of these combinations is also shown.

CMTS
1.0 1.1 2.0

CM/CMTS pair CM/CMTS pair CM/CMTS pair
1.0 operates in operates in operates in
1.0 mode only 1.0 mode only 1.0 mode only

CM
1.0 mode only Either 1.0 mode or Either 1.0 mode or
1.1 mode 1.1 mode

1.0 mode only Either 1.0 mode or Either 1.0 mode,
1.1 mode 1.1 mode or 2.0
mode

Figure 8 - CMTS/cable modem interoperability

While the DOCSIS 2.0 specification provides a simple mechanism for allowing DOCSIS 1.0,
DOCSIS 1.1, and DOCSIS 2.0 cable modems and CMTSs to interoperate with one another, the
co-existence of TDMA, ATDMA, and SCDMA is slightly more complicated. One serious
complication in DOCSIS 2.0 arises from the fact that a CMTS operating with TDMA and
ATDMA cable modems must specify time references when granting burst intervals to the cable
modems (see Figure 4), and the transmitting cable modem consumes the entire upstream channel
during its burst interval, precluding the use of channel sharing during any particular burst
interval. On the other hand, a CMTS operating with SCDMA cable modems must specify both



time references and spreading codes when granting burst intervals to cable modems (see Figure
7), and each transmitting cable modem can share the upstream channel with other cable modems
during a frame. As a result of these differences, TDMA/ATDMA cable modems must not be
transmitting during frames when SCDMA cable modems are transmitting, and SCDMA cable
modems must not be transmitting during burst intervals when TDMA/ATDMA cable modems
are transmitting. To simplify the coordination of the different types of transmission schemes
when TDMA/ATDMA cable modems must share a single physical upstream channel with
SCDMA cable modems, the DOCSIS 2.0 specification added a new concept known as a “logical
channel.”

A single physical upstream channel can be sub-divided into multiple logical channels- one for
TDMA/ATDMA and another for SCDMA. Each logical channel is centered on the same center
frequency, but each is essentially independent of the other, because each logical channel has its
own set of MAPs and Upstream Channel Descriptors (UCDs). An example of time-interleaved
TDMA/ATDMA frames and SCDMA frames from two different logical channels is illustrated in
Figure 9. The MAP scheduler within the CMTS is responsible for distributing idle periods to
guarantee that the two logical channels do not overlap in time.

frame 1 frame 2 frame 3 frame 4 frame 5

Logical
Channel
burst burst idle burst burst idle burst
A
interval interval interval interval interval
(TDMA/
ATDMA)

burst
interval burst
Logical interval
Channel idle burst idle idle
B interval
(SCDMA) burst
burst interval
interval

time
Figure 9 - Timing of two logical channels within a physical channel




It should be noted that mixing a high-bandwidth logical channel with a low-bandwidth logical channel
inside of the same physical channel results in inefficient utilization of the upstream spectrum. For
example, consider the mix of a 6.4 MHz DOCSIS 2.0 channel with a 3.2 MHz DOCSIS 1.X channel.
Whenever the low-bandwidth 3.2 MHz channel is transmitting, half of the 6.4 MHz spectrum is
unused (Figure 10). This problem may force system operators to carefully design their HFC plants for
future mixes of DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0 cable modems.

6.4 MHz 3.2 MHz
channel channel
centered @ centered @
25 MHz 25 MHz
Upstream
Spectrum

freq (MHz)
20 25 30

wasted
spectrum for
the 3.2 MHz
channel !

Figure 10 - Potential inefficient bandwidth utilization




Answering The Tough Questions About DOCSIS 2.0 Deployments

Now that the details of DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0 are well understood, how
does a system operator actually use all of these capabilities to deliver advanced data, voice, and
multimedia services to their subscribers? The answer to this question (and others) is dependent
on the details of the particular system, but an attempt can be made to answer some of these
questions in a general sense.

How Much Upstream Bandwidth Can You Really Get With DOCSIS 2.0?
DOCSIS 2.0 offers new 6.4 MHz upstream channels that can run with 64QAM, and each of these
upstream channels can provide a system operator with 30 Mbps of upstream bandwidth. While this is
true on paper, there may be some issues that will be encountered if a system operator attempts to
deploy this capability.

First, consider an example DOCSIS 2.0 CMTS 2x8 blade that supports two downstream
channels and eight upstream channels. In an example HFC architecture, these two downstream
channels might be distributed across eight fiber nodes, and each fiber node would send return
data on one of the eight available upstream channels. There exists a maximum bandwidth of ~40
Mbps (256QAM) on each downstream channel, and the total downstream bandwidth emanating
from a 2x8 CMTS blade would be approximately 2*40Mbps=80 Mbps. A DOCSIS 2.0 2x8
blade would be able to support eight upstream channels, and each upstream channel could
theoretically support ~30 Mbps (5.12 Msymbols/sec at 64QAM). As a result, the total theoretical
upstream bandwidth moving up the cable into a 2x8 blade could be 8*30Mbps=240 Mbps (three
times more bandwidth than the 80 Mbps of downstream bandwidth).

However, from a practical standpoint, a deployment that experiences three times more upstream
bandwidth than downstream bandwidth is highly unlikely. In particular, it is well known that DOCSIS
traffic has been predominantly asymmetrical (with more downstream bandwidth than upstream
bandwidth) in the past due to the nature of Web-surfing traffic. The architects of the DOCSIS 2.0
specification realized that there is a move toward more symmetrical traffic flows in the future with the
advent of interactive gaming and servers located in homes. However, it seems unrealistic to assume
that traffic patterns will reverse their nature and produce an asymmetry in the opposite direction (with
substantially more upstream bandwidth than downstream bandwidth). It can probably be argued that
traffic patterns will more likely approach symmetry (downstream bandwidth equal to upstream
bandwidth) in the foreseeable future. If this is the case, it is unlikely that subscriber applications will
be driving much more than approximately 80 Mbps upstream to the 2x8 blade (since the downstream
bandwidth on a 2x8 blade is limited to 80 Mbps). Thus, it seems unlikely that MSOs will be
ubiquitously deploying DOCSIS 2.0 upstream channels operating at 30 Mbps in the near future.
(Note: The use of 30 Mbps upstream channels seems more likely if the HFC architectures evolve to
the point where a single 40 Mbps downstream channel is directed to one and only one fiber node.
With symmetrical traffic in this futuristic scenario, the use of a single 30 Mbps upstream channel from
the fiber node becomes justified).




In addition, many real-world HFC plants will not even be able to capitalize on the 30 Mbps
DOCSIS 2.0 upstream capability because of several possible HFC plant impediments. For
example, some system operators may not have 6.4 Mhz of contiguous, low-noise bandwidth
available on the upstream cable in which to place a 30 Mbps upstream channel.

Another potential HFC plant impediment may result from the fact that the required signal-to-
noise (SNR) ratios for very high-speed DOCSIS 2.0 operation may be difficult to ensure on
many upstream cables. For example, assume a bit error rate of 10-8 is desired, and assume that
the operator decides to use Reed-Solomon FEC codewords of length 255 with T=16. The
required signal-to-noise ratios (according to one chip vendor) for various DOCSIS 2.0
transmission schemes are illustrated in Table 5. [4] These relatively high signal-to-noise ratio
requirements can be very difficult to guarantee in a live HFC plant.

Technology Modulation Channel Symbol Rate Raw Data Minimum
Format BW (MHz) (Msym/sec) Rate (Mbps) Signal-to-
Noise Ratio
ATDMA 16QAM 3.2 2.56 10.24 15.75
SCDMA 32QAM(TCM) 3.2 2.56 10.24 14.1
ATDMA 64QAM 6.4 5.12 30.72 22
SCDMA 128QAM(TCM) 6.4 5.12 30.72 20.5

Table 5 - Required signal-to-noise ratios for DOCSIS 2.0 transmission

Thus, the ultimate upstream bandwidth that will be used in a particular HFC plant will be
predominantly determined by two factors: the signal-to-noise ratio of the upstream channels and
the demanded upstream-to-downstream bandwidth ratios. In many plants, the signal-to-noise
ratios and the demanded upstream-to-downstream bandwidth ratios may preclude the near-term
use of the higher bandwidth channels offered by DOCSIS 2.0.

How Well Do The Noise Mitigation Techniques Work in DOCSIS 2.0?
Since noise on the upstream channel may greatly limit the applicability of the higher bit-rate
transmission techniques offered by DOCSIS 2.0, one may want to explore the use of the various noise
mitigation techniques supplied by DOCSIS 2.0 in an attempt to circumvent this problem. Many
disagreements exist between different camps regarding the relative merits of the different noise
mitigation techniques associated with ATDMA and SCDMA. A lot of the debate is centered on how
one models the noise in a live HFC plant. For example, what is the “typical” duration of burst noise?
What is its spectral content? Every researcher has a different set of noise models, and the bit-error-rate
results seem to vary depending on the details of the noise model being used. However, all of the noise
mitigation techniques are likely to yield some level of benefit, and the actual benefits realized by a
particular system operator will be highly dependent on the type and amplitude of the noise found in
their plant.




In determining the relative merits of a particular noise mitigation technique, it is important to
recall that many of the techniques can have detrimental effects on the user bandwidth and delay
in the upstream channel. For example, the overhead associated with longer preambles and FEC
parity bytes must always be considered. The delay associated with symbol spreading and
interleaving must also be considered. These are often viewed as hidden costs associated with the
advanced technologies.

Nevertheless, for a particular HFC plant that was limited (by noise) to use lower symbol rates or
less efficient modulation formats with DOCSIS 1.X, the noise mitigation techniques of DOCSIS
2.0 may very well provide the improvements needed to upgrade to the next higher symbol rate or
to a slightly more efficient modulation format. The addition of many new modulation formats
within DOCSIS 2.0 increases the likelihood that a higher-efficiency modulation format can be
utilized.

Are There Any Other Hidden Costs Associated with DOCSIS 2.0?

One limitation of DOCSIS 2.0 is often overlooked when considering mixes of existing DOCSIS 1.X
equipment with DOCSIS 2.0 equipment. DOCSIS 1.0 and DOCSIS 1.1 cable modems cannot be
operated on one of the new 5.12 Msymbol/sec (6.4 MHz) channels, and this may produce a hidden
cost for DOCSIS 2.0 deployment. If DOCSIS 1.X and DOCSIS 2.0 cable modems are to placed on
the same physical channel, system operators must either limit the physical channel bandwidth to the
3.2 MHz limit imposed by DOCSIS 1.X or they must endure the inefficient use of bandwidth
resulting from the mix on a 6.4 MHz channel (see Figure 10). Thus, the mix of DOCSIS 1.0 and
DOCSIS 1.1 cable modems with 5.12 Msymbol/sec DOCSIS 2.0 cable modems on a single HFC
coaxial distribution leg may force system operators to think about using at least two physical upstream
channels to be established between the cable modems and the CMTS. One of these physical channels
would operate at a symbol rate of 2.56 Msymbol/sec or less, and it would be able to transport data for
the DOCSIS 1.0 and DOCSIS 1.1 cable modems. The other physical channel would operate at the
higher symbol rate of 5.12 Msymbol/sec, and it would be able to transport the higher bandwidth data
for the DOCSIS 2.0 cable modems. This two-channel approach separates the cable modems into
separate physical channels and decreases the gain produced by statistical multiplexing. It can also lead
to inefficient utilization of the upstream channel spectrum and the CMTS receivers. To accommodate
this requirement within a DOCSIS 1.0/DOCSIS 1.1/DOCSIS 2.0 mixed environment, system
operators must ensure that their upstream spectra will support adequate bandwidth and that their
CMTS will support an adequate number of upstream receivers in their DOCSIS 2.0 blades.

Another hidden cost associated with DOCSIS 2.0 results from the fact that a mix of TDMA,
ATDMA, and SCDMA cable modems on the same physical upstream channel will require the
channel to be divided into two logical upstream channels (one for TDMA/ATDMA operation
and one for SCDMA operation). This requirement for two logical channels separates the cable
modems into separate groupings and decreases the gain produced by statistical multiplexing of
many cable modems on a single channel.




Is There Anything Else To Worry About?
Although not specifically a part of the DOCSIS 2.0 specification, the next generation of CMTS
blades may have to support more upstream channels to accommodate the channel-splitting
problems identified above for mixes of TDMA DOCSIS 1.X cable modems and 6.4 MHz
DOCSIS 2.0 cable modems. The manner in which a CMTS provides these additional channels
can be important, because some implementations will not work on specific HFC plant designs.

Fiber RCVR CMTS Blade
Node #1 #1

42 MHz
Dwn
Fiber RCVR
Node #2 #2

42 MHz

Fiber RCVR
Node #3 #3
Up
42 MHz

Fiber RCVR Up
Node #4 #4
Up
42 MHz

Fiber RCVR Up
Node #5 #5
Up
42 MHz

Fiber RCVR Up
Node #6 #6
Up
42 MHz

Fiber RCVR Up
Node #7 #7

42 MHz

Fiber RCVR
Node #8 #8

42 MHz

Figure 11 - Example upstream architecture A

In particular, consider the two HFC plant architectures shown in Figure 11 and Figure 12. In
each of these architectures, eight separate physical upstream channels are routed up to the CMTS
blade, but the channels are distributed very differently across the fiber nodes. Some next-
generation CMTS blades will support one of these configurations, but not the other. System
operators must ensure that the CMTS blade will support all of the upstream architectures that
they may be using within their HFC plants. A CMTS blade that allows the flexibility to support
both ends of the spectrum (between Figure 11 and Figure 12) could be useful, because system
operators cannot always predict the particular architectural scenarios that may develop in the
future.




Fiber RCVR CMTS Blade
Node #1 #1

42 MHz
Dwn

Up

Up

Up

Up

Up

Up

Up

Up

Figure 12 - Example upstream architecture B

How Will Mixes of DOCSIS 1.X and DOCSIS 2.0 Equipment Affect Near-
term and Long-term Deployments?
As DOCSIS 2.0 equipment becomes available, each system operator will evolve his or her
network in a different fashion. However, it is likely that a mix of DOCSIS 1.0, DOCSIS 1.1, and
DOCSIS 2.0 cable modems will co-exist for quite a while, with the percentage of DOCSIS 2.0
equipment growing from zero to a large percentage over time.

Early-stage deployments are likely to find DOCSIS 1.X cable modems dominating the mix.
During this time, system operators may not want to exert the energy required to re-architect their
HFC plants to capitalize on all of the DOCSIS 2.0 benefits for the small percentage of deployed
DOCSIS 2.0 modems. As a result, 6.4 MHz channels may not be enabled at first (allowing
DOCSIS 2.0 modems to co-exist in the same physical channels as DOCSIS 1.X modems). Some
may be reluctant to separate their users into two logical channels (due to the loss of statistical
multiplexing), so ATDMA (carried in the same logical channel as the TDMA traffic) is likely to
see more use than SCDMA at first. However, some operators will likely experiment with
SCDMA to compare its noise mitigation capabilities to those of ATDMA.




Mid-stage deployments will see comparable numbers of DOCSIS 1.X and DOCSIS 2.0 cable
modems on the same HFC plant. If the early-stage experiments with SCDMA prove effective,
some system operators will likely start to use two logical channels: one for SCDMA and the
other for TDMA and ATDMA. Some operators will probably begin experimenting with 6.4 MHz
channels for DOCSIS 2.0 modems.
Late-stage deployments will find DOCSIS 2.0 cable modems dominating the mix. During this
stage, different MSOs are likely to be using very different architectures based on their early-
stage and mid-stage experiences. Some will continue to avoid the use of 6.4 MHz channels,
opting to use several 3.2 MHz channels instead. Other MSOs will have both 6.4 MHz channels
and 3.2 MHz channels placed within the upstream spectrum, with DOCSIS 2.0 modems
connecting to the 6.4 MHz channel and DOCSIS 1.X modems connecting to the 3.2 MHz
channels. There are likely to be different DOCSIS 2.0 camps with different biases. Some MSOs
will prefer ATDMA operation, while other MSOs will prefer SCDMA operation. The choices
are likely to be a function of the types of noise found in their particular HFC plants.

Should MSOs Delay DOCSIS 1.1 Purchases and Wait for DOCSIS 2.0 to
Mature?
Obviously, each individual system operator can only answer this question. The operator must
weigh the expected benefits of DOCSIS 2.0 equipment against the lost revenues from delayed
DOCSIS 1.1 deployment. Several questions must be answered. Are the bandwidth improvements
offered by DOCSIS 2.0 realizable in the operator’s particular HFC plant? Will the noise
mitigation techniques in DOCSIS 2.0 help solve existing problems? Will increased revenues be
achievable this year by deploying DOCSIS 1.1 and providing tiered data services and/or
PacketCable services to the subscribers?
For system operators that are on the fence, some very interesting points should be considered.
First, DOCSIS 1.1 equipment is available and ready for deployment today. In addition, some of
the bandwidth gains offered by DOCSIS 2.0 can be approximated by clever deployments of
DOCSIS 1.1 equipment. For example, consider a system operator with 9.6 MHz of low-noise
upstream spectrum that was set aside for future DOCSIS 2.0 deployment . Assume that 6.4 MHz
was to be used by a physical channel separated into two logical channels for DOCSIS 2.0
ATDMA/SCDMA cable modems, and assume 3.2 MHz was to be used by a second physical
channel for DOCSIS 1.X TDMA cable modems (due to the problem described above). Assume
the signal-to-noise ratio on the plant would have limited all of the cable modems to operate with
the modulation format set to 16QAM. Thus, the bandwidth provided by the 6.4 MHz channel is
20.48 Mbps, the bandwidth provided by the 3.2 MHz channel is 10.24 Mbps, and the total
bandwidth provided by the two physical channels is 30.72 Mbps.
Instead of waiting for DOCSIS 2.0, the system operator could opt for an earlier deployment of
DOCSIS 1.1 equipment, using three 3.2 MHz upstream channels operating with 16QAM. The
total bandwidth is still the same (30.72 Mbps). The lack of noise mitigation techniques should
not matter (since the signal-to-noise ratio on this example plant would only permit 16QAM
operation anyway). One might argue that the use of three TDMA upstream channels decreases
the effectiveness of statistical multiplexing, but the DOCSIS 2.0 design would have had three




channels as well (one physical channel for TDMA, one logical channel for ATDMA, and one
logical channel for SCDMA). Even if the DOCSIS 2.0 design used one physical channel for
TDMA and another physical channel for ATDMA only (i.e., no SCDMA is used), the difference
between the statistical gain for two channels and the statistical gain for three channels is
minimal. Assume that each cable modem has an active session 30% of the time, assume that each
active connection transmits data 10% of the time, and assume that during transmission, each
cable modem consumes 128 kbps of upstream bandwidth. It can be shown that the DOCSIS 1.1
three-channel design can support 5850 cable modems, while the DOCSIS 2.0 two-channel design
can support 6318 cable modems. [5] Thus, DOCSIS 2.0 only provides an 8% increase over
DOCSIS 1.1 in this example, and this small increase may not be worth delaying the deployment
of new revenue-generating services such as PacketCable or tiered-data services.

Will there be a technology following DOCSIS 2.0 that will obsolete it?
DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0 are here to stay, and they are likely to be a part of
cable data systems for years to come. In fact, the prohibitive cost of switching out existing
subscriber cable modems practically guarantees that DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0
cable modems will co-exist on many HFC plants for a very long time.

Nevertheless, other changes are likely to arrive in the future as technologies continue to improve. For
example, many other proposals for DOCSIS improvement were submitted to the DOCSIS 2.0
committees, but these proposals were not included in the current specification release. These features
are likely to be re-submitted in the future, so some or all of these features could conceivably find their
way into a DOCSIS 2.X or DOCSIS 3.X release. Since some of these proposed improvements are
currently available as proprietary solutions within various vendor chipsets and will be available in
CMTSs in the near future, it seems prudent to mention them as examples of future capabilities.

There are many other enhancements that could be added to the upstream PHY and MAC layers.
For example, ATDMA could easily incorporate the use of Trellis-Coded Modulation as well as
the use of 128QAM with Trellis-Coded Modulation. Thus, the noise mitigation benefits of
Trellis-Coded Modulation could be made available to ATDMA cable modems.

In addition, the tight synchronization between the CMTS and the cable modems that is used in
SCDMA transmission could also be incorporated in ATDMA transmissions. This synchronization
could permit the preamble length to be decreased within ATDMA transmissions, which would
eliminate some of the overhead associated with ATDMA data transfers. This would result in more
bandwidth available for the transmission of user traffic.

Newer noise mitigation techniques are also likely to be added in the future to permit DOCSIS
operations even on HFC plants with relatively low signal-to-noise ratios. Another beneficial change
will likely result from more advanced packet overhead compression techniques.




While DOCSIS 2.0 concentrated entirely on improvements in the upstream PHY and MAC
layers, it is very likely that in the future system operators will be able to capitalize on PHY and
MAC layer improvements for the downstream channel as well. Whereas the DOCSIS
downstream is currently limited to two modulation formats (64QAM and 256QAM), future
designs may permit downstream extensions to 512QAM and 1024QAM. With 1024QAM, a
single downstream channel will provide a bit-rate of approximately 50 Mbps, which is much
higher than the ~40 Mbps bit-rate currently provided by a 256QAM channel.




Conclusions
In summary, the DOCSIS 2.0 specification will provide many possible improvements to existing
upstream channel operations. Most of these improvements concentrate on the MAC and PHY
layers, and they address both bandwidth limitation issues and noise mitigation issues. The actual
utility of these improvements will vary depending on the details of a particular operator’s HFC
plant. In particular, the plant signal-to-noise ratio will play a major role in deciding which
DOCSIS 2.0 noise mitigation features can be utilized. Actual equipment availability will likely
occur at the end of 2002 or in 2003, so system operators must carefully evaluate the potential
benefits of DOCSIS 2.0 before deciding on their DOCSIS 1.1/DOCSIS 2.0 deployment
strategies for the next year and a half. For many systems, it can be shown that clever use of
DOCSIS 1.1 capabilities can provide many of the same benefits as DOCSIS 2.0 equipment in the
interim while waiting for DOCSIS 2.0 equipment to become available.




Acknowledgements

The author would like to thank several individuals for helpful input, including Greg Gohman,
Bruce McClelland, Jerry Ryan, Ubaldo Cepeda, Jerry Archambault, Todd Kessler, and Tim
Doiron from ARRIS. In addition, many thanks are due to Newton Antoniuk and Marty Levy
from Imedia, and also to Dan Howard and Ernie Baum from Broadcom. All of them provided
helpful clarification on many complicated topics.




References
[1] R. Yassini “DOCSIS 2.0 Program Overview”, White Paper from CableLabs Web site
(www.cablelabs.com).

[2] ”DOCSIS 2.0 Cable System Design DemystiPHY’d”, Course Notes from Imedia Training
Program (January, 2002).

[3] R. L. Pickholtz, D. L. Schilling, and L. B. Milstein, “Theory of Spread-Spectrum
Communications- A Tutorial,” IEEE Trans. On Communications, Vol. COM-30, No. 5, (May 1982),
pp. 855-883

[4] “DOCSIS 2.0 and Advanced S-CDMA: Maximizing the data return path”, White Paper from
Imedia Web site (www.imedia.com).

[5] C. C. Lee and J. Bertorelle, “System-level capacity and QoS in DOCSIS 1.1 upstream,”
Proceedings, 2002 SCTE Conference on Emerging Technologies (January, 2002), pp. 493-51

ARRIS
11450 Technology Circle
Duluth, Georgia 30097
www.arrisi.com
In North America, Call Toll Free: 1-866-36-ARRIS
Outside North America, Call: +1-678-473-2000

Specifications published here are current as of the date of publication of this document. Because we are continuously improving our
products, ARRIS reserves the right to change specifications without prior notice. At any time, you may verify product specifications
by contacting our headquarters office in Duluth, Georgia. ARRIS International, Inc. views its patent portfolio as an important
corporate asset and vigorously enforces its patents. Products or features contained herein may be covered by one or more U.S. or
foreign patents, registrations or copyrights.

ARRIS is a registered trademark of ARRIS International, Inc. All other brands, names, or trademarks mentioned in this document or
Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between
ARRIS and any other company.

8/02

© 2002 ARRIS International, Inc. All Rights Reserved


Docsis 20 getting to know

More Related Content

Similar to Docsis 20 getting to know

More from herooftit

Recently uploaded

Docsis 20 getting to know