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
Many of us have been there before – one or more cable modems stuck in one of numerous “init()” conditions – how do we interpret these messages and what do we do? A recent reader wrote in and had just this problem. DOCSIS cable modems going offline and getting stuck in “R1″ or “R2″ condition, also known
Interesting post from fellow DOCSIS technologist on CMTS vs. EOC (Ethernet over Coax). Check out the post and his blog.
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.
With IPv6 on the way in a number of MSO (Multi-System Operator) networks, I have received numerous questions lately about how home devices such as routers and PCs attached to DOCSIS cable modems will get their IP addresses. Will cable operators suddenly start issuing IPv6 IP addresses to their customers? Will you as a subscriber need to upgrade your equipment to support IPv6? Or does the cable modem act as a Network Address Translation (NAT) device and hand-out IP address to each device attached to it? These are some very good questions and the answers are addressed in the DOCSIS specification as I will outline.
This is a handy summary of the various timeout errors you will find in a DOCSIS network. T3 and T4 timeouts are described in much more detail elswhere in this blog, however this post provides a high level overview of the various timeouts as a reference.
Every now and then you find a very useful URL. If you are a Cisco CMTS user then you find some of the undocumented commands on this site usefull:
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.
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 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.
bradyvolpe.com is Stephen Fry proof thanks to caching by WP Super Cache
