Docsis 20 getting to know

www.arrisi.com 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

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.




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.

1997 1998 1999 2000 2001 2002 2003 time

textDOCSIS1.0 Spec

textDOCSIS1.0 Cert

textDOCSIS1.1 Spec

textDOCSIS1.1 Cert

textDOCSIS2.0 Spec

textDOCSIS

2.0 Cert ?text

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.




CMTS

NetworkInterface

Mod

Video 1

OperationsSupportSystem

Security &Access

Controller

HeadendRouter

LocalServers(DHCP,TFTP,

TOD, etc.)

TelephonyGateway

BackboneNetwork

PSTN

DwnstreamRF

Combiner

Video 2

DownstreamData

Demod UpstreamSplitter &

FilterBank

UpstreamData

O/E

OpticalTransceivers

E/O FiberNode

50-860MHz

5-42MHz

FiberPairs

CoaxialDistribution

Leg

HFC

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

I

11

10

01

00

(a) QPSK symbol mapping (2 bits/symbol)

Q

I

1100

(b) 16QAM symbol mapping (4 bits/symbol)

1110

1101 1111

0110 0100

0111 0101

1001 1011

1000 1010

0011 0001

0010 0000

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 (kHz)

Symbol Rate (ksymbols/sec)

Bit-rate for QPSK (kbps)

Bit-rate for 16QAM (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.

GuardTime

Preamble

MACHeader

PacketData

time

GuardTime

Preamble

MACHeader

PacketData

CM #1Transmission

(16QAM &2.56 Msym/sec)

CM #2Transmission

(QPSK &2.56 Msym/sec)

Codeword Codeword Codeword Codeword

Information(data)

FEC ParityBytes

MinislotPadding

Information(data)

FEC ParityBytes

MinislotPadding

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 Width (kHz)

Symbol Rate R

(ksymbols/sec)

Symbol Rate R

(ksymbols/sec)

Bit-rate for

8QAM (kbps)

Bit-rate for

16QAM (kbps)

Bit-rate for

32QAM (kbps)

Bit-rate for

64QAM (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)).




time (usec)0 50

y(t) 390.625 nsecsignal

freq (MHz)0 5

Y(f)F

(a) TDMA signal

time (usec)0 50

y(t) 50 usecspreadsignal

freq (kHz)0 50

Y(f)F

(b) SCDMA spread signal

time (usec)0 50

y(t) 390.625 nsec chip

freq (MHz)0 5

Y(f)F

(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.

Channel

Source#1 X

Spreadingcode

xT=[-1 +1]

A [-A +A]

Source#2

X

Spreadingcode

yT=[-1 -1]

B [-B -B]

+

[-A-B +A-B]Correlator

Source #1spreading

codexT=[-1 +1]

Output

2A

Modulator

Modulator

Demod

-1+1

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

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.

code 0

code 31

CM #1

code 32

code 63CM #2

code 64

code 95CM #3

code 96

code 127

CM #4 CM #4

CM #2

CM #3

CM #4

frame 1 frame 2 frame 3

time

CM #1

burst intervalw/ 16QAM &

2.56 Msym/sec


2.56 Msym/sec

burst intervalw/ QPSK &

2.56 Msym/sec


2.56 Msym/sec


2.56 Msym/sec

burst intervalw/ QPSK &

2.56 Msym/sec


2.56 Msym/sec


2.56 Msym/sec


2.56 Msym/sec

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 Width (kHz)

Symbol Rate R (ksymbols/sec)

Bit-rate for QPSK (kbps)

Bit-rate for 8QAM

(kbps)

Bit-rate for

16QAM (kbps)

Bit-rate for

32QAM (kbps)

Bit-rate for

64QAM (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 Width (kHz)

Symbol Rate R (ksymbols/sec)

Bit-rate for

QPSK (kbps)

Bit-rate for

8QAM (kbps)

Bit-rate for

16QAM (kbps)

Bit-rate for

32QAM (kbps)

Bit-rate for

64QAM (kbps)

Bit-rate for

128QAM (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.

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

1.0 1.1 2.0

1.0 CM/CMTS pair operates in

1.0 mode only


Either 1.0 mode or1.1 mode


Either 1.0 mode, 1.1 mode or 2.0

mode

CMTS

CM CM/CMTS pair

operates in 1.0 mode only

CM/CMTS pair operates in

1.0 mode only


1.0 mode only


1.0 mode only








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.

time

burstinterval

burstinterval

burstinterval

burstinterval

burstinterval

idle idle

burstinterval

burstinterval

burstinterval burst

interval

burstinterval

idleidle idle

LogicalChannel

A(TDMA/ATDMA)

LogicalChannel

B(SCDMA)

frame 1 frame 2 frame 3 frame 4 frame 5

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.

freq (MHz)

UpstreamSpectrum

3.2 MHzchannel

centered @25 MHz

20 3025

6.4 MHzchannel

centered @25 MHz

wastedspectrum forthe 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

Format Channel

BW (MHz) Symbol Rate (Msym/sec)

Raw Data Rate (Mbps)

Minimum 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.

CMTS Blade

Dwn

Up

Up

Up

Up

Up

Up

Up

Up

FiberNode #1

RCVR#1

42 MHz

FiberNode #2

RCVR#2

42 MHz

FiberNode #3

RCVR#3

42 MHz

FiberNode #4

RCVR#4

42 MHz

FiberNode #5

RCVR#5

42 MHz

FiberNode #6

RCVR#6

42 MHz

FiberNode #7

RCVR#7

42 MHz

FiberNode #8

RCVR#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.




CMTS Blade

Dwn

Up

Up

Up

Up

Up

Up

Up

Up

FiberNode #1

RCVR#1

42 MHz

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

http://www.imedia.com/

http://www.arrisi.com/

Docsis 20 getting to know

Technology

Transcript of Docsis 20 getting to know