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.
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.
If you have followed the "DOCSIS and Cable Modems - How it works" tutorials this far, congratulations! You now have a basic foundation of how DOCSIS networks operate and the ability to pick up the DOCSIS specification and read and comprehend it - this is hard to do for the novice. If you are just finding this blog for the first time, then I recommend that you go to the DOCSIS Tutorial Series and start at the beginning before proceeding.
DOCSIS 1.0 enabled data over coax with a "best effort" service using a data request-grant methodology. DOCSIS 1.1 and subsequent specifications added guaranteed Quality of Service (QoS) by providing Unsolicited Grant Synchronization (UGS) which means that a cable modem does not have to send a data request in order to receive a bandwidth grant from the CMTS. The new UGS service is an enabling technology which has allowed cable operators to successfully deploy the highly revenue generating Voice-over-IP (VoIP) services. In the following sections I will illustrate the differences between best-effort (request-grant) and QoS (UGS) services.
Just as a picture is worth a thousand words, so is a complete Upstream Channel Descriptor (UCD) as seen by a cable modem. This message, sent every two seconds by the the CMTS, contains an enourmous amount of valuable information that every cable modem on a DOCSIS network needs to know in order to communicate. Often undervalued, the UCD is a virtual Hitchiker's Guide to the DOCSIS network! So without any further ado, let me show you an example of a full UCD message and then explain its contents further
In this blog I am going to focus on VoIP packet loss, which is just one of the three (3) primary types of VoIP impairments that are present in a DOCSIS network. I will cover many RF and IP terms in this blog that I have not discussed in my previous tutorials, not to worry! This terminology is all fodder for future blogs. :-) To review, the three fundamental impairments which impact call quality of VoIP communications are as follows: * Packet Loss – The complete or partial loss of a packet containing actual voice payload. * Delay – The time a packet takes to traverse the space between the source and destination of a voice call. The space is comprised of both the physical distance the data must travel in addition to the active network routing and switching elements, which contribute additional delay. * Jitter – The variance of inter-packet arrival time from one transmitted packet to the next sequential packet.
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.
