If you have not had a chance to catch the June issue of Communications Magazine, check out the article penned by John Downey, of Cisco Systems, and I on “the critical upstream areas that one should be aware of when getting ready to deploy or already deploying DOCSIS 3.0.”
The shortened version of this article can be found on CT’s website HERE. The full version should be made available on this blog soon.
The first part of this article (in CT’s March 2009 issue) discussed downstream potential issues, while this one focuses on the potential issues associated with upstream deployments. In particular, this article covers the critical upstream areas that one should be aware of when getting ready to deploy or already deploying DOCSIS 3.0.
This article will focus more specifically on DOCSIS 3.0 issues that will occur as you are deploying DOCSIS 3.0 or post -deployment.
This is the first of a new series of Tutorials focused on the Data Over Cable Service Interface Specifications (DOCSIS) version 3.0. I will make the assumption that you are familiar with the DOCSIS 1.x / 2.0 standards or have already reviewed my DOCSIS Basics Tutorial as I will be using many terms without explanation since they were previously covered.
The DOCSIS 3.0 specification is an extension of the DOCSIS 1.x and 2.0 specification which dramatically increases the data throughput by adding a technology known as channel bonding to the DOCSIS downstream and upstream, adding increased security, adding support for IPv6, and substantially improving the back-office management support (MIBs, SNMP, IPDR, etc.) for DOCSIS. Each of these topics will covered in much greater detail in this DOCSIS 3.0 tutorial in multiple posts yet to come.
Before we dive into bits, bytes and protocol, first we will discus some hardware. During the evolution of DOCSIS 3.0 there were a number of interesting interim steps along the way, shall we say building blocks, to arrive at a full blown D3.0 CMTSs. This left us with two fundamentally different system architectures in production by CMTS vendors, Integrated and Modular CMTSs. It is important to understand these “architectures” from a purchasing, operational and deployment standpoint as they have different requirements in some cases, some are better than others depending on the system layout.
In this article I am going to further explore the M-CMTS in order to describe two import elements of DOCSIS 3.0 network, the edge-Quadrature Amplitude Modulator or EQAM and the DOCSIS Timing Interface Specification Server or DOCSIS Timing Server. Before I cover these components I will show how they are integrated with the M-CMTS architecture.
In my article on DOCSIS 3.0 M-CMTS architecture, I talked about the distributed nature of the CMTS with an M-CMTS core (the CPU of the system), a DOCSIS Timing Server, and an edge Quadrature Amplitude Modulator (EQAM). I am going to cover the EQAM in detail in this article because in the past couple of years, EQAM (also spelled eQAM) has rapidly become part of our vocabulary but its operation and value often go unappreciated. Further, in order to fully understand DOCSIS 3.0 operation, downstream channel bonding, and possible issue which may arise, a thorough understanding of the eQAM is critical.
Before DOCSIS 3.0 and before modular CMTS architectures, a CMTS existed in one chassis. Life was much simpler for everyone. Inside the chassis existed a 10.24 MHz clock or oscillator. This was a master time keeper that kept event in synchronization with every other event. Timing is very important in communications networks, especially when dealing with microsecond timing calculations necessary for DOCSIS transport – remember the “tick” (6.25 usec). This article is going to address the DOCSIS Timing Interface Specification (DTI) and DTI time servers that have arisen due to the distributed architectures in M-CMTSs and DOCSIS 3.0 CMTSs. In these architectures, it is possible to have the CMTS core in say the headend, with the eQAM and upstream receivers in remote hubsites. Suddenly the single 10.24 MHz clock keeping the system in synchronization is no longer an option. Three separate, free running 10.24 MHz clocks would also not work because they would not be in phase and would likely not be exactly running at the same frequency, causing the entire system to out of synchronization – there would packet collisions and lost data and VoIP packets all over the place. It would be chaos! So the smart folks at Cablelabs put together the DTI specification to resolve these issues. Here are some of the details.
Now that we have established the two primary architectures available in DOCSIS 3.0, I-CMTS and M-CMTS (thought hybrids do exist), and the hardware components of these architectures, it is time to delve into the protocol of the DOCSIS specifications that make up DOCSIS 3.0. There are five primary specifications that I will be drawing upon from here on out listed below and located in my document library and also on the CableLabs website.
Downstream Channel Bonding is perhaps the ball bearings of DOCSIS 3.0, enabling subscriber data speeds in excess of 160 Mbps (4 times that of previous DOCSIS versions). While conceptually simple, the principle of combining multiple downstream DOCSIS channels together to carry the same user data must have tight constraints in order to preserve the integrity of the data and have the data arrive at the correct subscriber’s device and in sequence. This article will cover both the physical layer aspects and DOCSIS protocol aspects that enable channel bonding.
The focus of this article will be on the mechanics of upstream channel bonding and how it works more from a DOCSIS protocol perspective. Much more detailed information can be found in the DOCSIS 3.0 MULPIv3.0 document located in the Library, but this will provide a high level overview for the layman who is curious about the basics. First lets understand that it is the cable modem that is doing the channel bonding, remember in the upstream the cable modem transmits data to the CMTS. Per DOCSIS 3.0, the CM can bond from one to four channels in the upstream as coordinated by the CMTS. The CM is always under control by the CMTS.
Everyone is familiar with Internet Protocol version 4 (IPv4) addresses. You probably even set them up in your home network, such as 192.168.1.1 IPv4 is described in IETF publication RFC 791 (September 1981), which replaced the previous version RFC 760, dating back to January 1980. So its safe to say that IPv4 has been around for some time and serving us quite well. New in DOCSIS 3.0 has support for IPv6. Why do we need this new version? IPv6 has a vastly larger address space than IPv4. This results from the use of a 128-bit address, whereas IPv4 uses only 32 bits. Believe it or not, major cable operators are running out IP address. This is due to more customers, not just for cable modems, but also for set top boxes and VoIP eMTAs. Further, deployed in cable networks are IP devices such as power supplies with embedded cable modems for monitoring voltage, temperature, current and more. All networks are getting more IP devices requiring more and more IP addresses, so the 2128 addresses allocated in IPv4 are no longer sufficient and we turn to the 3.4×1038 addresses provided in IPv6.
If you have been upgraded to DOCSIS 3.0 and were issued a cable modem from your cable provider, you are probably paying a monthly fee for that device. I have always been a strong advocate of owning my own cable modems because it likely pay for itself over the two or three years you own it.
This is the speak you need to know when talking DOCSIS 3.0 to any DOCSIS Engineer or specialist. It is important that you learn the full name, in many cases the acronym and also what value the particular terminology plays in a DOCSIS 3.0 network as it will likely be crucial in troubleshooting tough-to-diagnose DOCSIS impairments.
A recent question from a reader provided an interesting response – the answer: maximum transmit power is 52.2 dBmV for DOCSIS 3.0 cable modems under certain conditions. The answer is very simple. They were transmitting at their maximum transmit level. That being in a 16-QAM modulation with four bonded upstream channels.
The following article just released by Broadband Technology Report was written by Carl Weinschenk. A number of us from the industry contributed to Carl’s piece, but it is a nice high-level summary article on the status of DOCSIS 3.0. Below you will find a snippet of the article with a link to the BTR website
Partial Service is a new term encountered in the DOCSIS 3.0 MULPI specification and realized in field deployments of DOCSIS 3.0 cable modems using upstream bonding. This was a topic that I touched on in this years SCTE Cable-Tec Expo, but will explore in greater detail in this article. Partial service can be considered a feature because the cable modem will stay online even when one or more upstream transmit channels goes offline.
“Impaired Service” in which case one or more bonded upstream channels are impacted by upstream RF impairments while other bonded channels are not. Since subscriber data is striped (that is broken into pieces and spread across each upstream channel and then re-assembled by the CMTS), some of the data will be lost or have errors while other data will not. Subscribers will most likely notice an impaired condition as upstream data rates slow down due to TCP/IP transmissions and/or VoIP, gaming, teleconferencing and other real-time applications will be noticeably impacted.
bradyvolpe.com is Stephen Fry proof thanks to caching by WP Super Cache
