See Brady Volpe at the Great Valleys Meeting Group May 15th, in Blacksburg, VA to discuss DOCSIS 3.0 Troubleshooting, Implementation and Planning. Great Valleys Meeting Group is a SCTE Chapter - serving Central, Southwest Virginia and Edinburg. Our meeting location will be the Holiday Inn in Blacksburg. The Holiday Inn in Blacksburg is offering an SCTE discount. When you reserve the room use the code CTE
If you missed the SCTE Cable-Tec 2011, I am making available my presentation and white paper on Advanced Troubleshooting in a DOCSIS 3.0 Plant. Each speaker had only 20 minutes to cover topics that could easily last hours, so the presentations are understandably brief. Below you will find my presentation in "Slideshare" for online viewing as well as a fully downloadable PowerPoint version. The PowerPoint version also has reader notes attached at the bottom of each slide which you may find useful. In addition, the animations work a little better in the downloadable version.
Press Release The Volpe Firm offering solutions, services and products for the broadband telecommunications industry The Volpe Firm gets Seal of Approval from Clients Alpharetta, GA November 14, 2011: The Volpe Firm offers solutions, services and products for the broadband communications industry with a focus in DOCSIS, data, video, and VoIP communications. We provide everything from specialized DOCSIS 3.0 seminars and or tailored DOCSIS training to high level hardware architecture engineering design and system troubleshooting. The Volpe Firm, with 30 years of combined telecommunications experience, specializes in DOCSIS,
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.
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.
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.
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.
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 this blog I am going to digress for a moment from my standard DOCSIS 101 tutorial and spend a little time on DOCSIS troubleshooting basics, especially with respect to Voice-over-Internet Protocol (VoIP). I am doing this as due to many offline questions specific to this topic. Don't worry, though I may start to inter-mix some troubleshooting blogs now and again, just check the DOCSIS 101 page to stay on top of the latest DOCSIS tutorial blogs.
