CMTS Architecture :: I-CMTS vs. M-CMTS

How did we get to different CMTS architecture (s).  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 CMTS architecture(s) in production by CMTS vendors, Integrated and Modular CMTSs.  It is important to understand these “CMTS architecture(s)” 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.

Integrated CMTS (I-CMTS)

A DOCSIS Integrated CMTS architecture, or I-CMTS, is one that we are more accustomed to based upon DOCSIS 1.x and 2.0 architectures. That is a pizza box or chassis-based CMTS whereby all components necessary for DOCSIS 3.0 operation are integrated. The first CMTS vendor to gain full DOCSIS 3.0 qualification was CASA Systems, who provides a complete DOCSIS 3.0 CMTS and edge QAM (eQAM) [eQAMs will be described in a later blog] in a 1RU platform. The benefits of the I-CMTS architecture are its ease of deployment and lowered cost since all components are integrated. Seemingly there should be fewer points of failure since cabling and interfaces between external components are eliminated.

The I-CMTS can be found in Arris CMTSs.  A strength of this architecture is the all-one solution, minimizing the amount of RF and IP combining in the headend, potentially reducing the number of points of failure.  Though some of the weaknesses may arguably density and the inability to remotely locate DOCSIS DTI time sources [to be defined in more detail later] in hub sites, however these are fine selling points which I will leave to the Sales Engineers much more qualified to defend their products than I.

Modular CMTS (M-CMTS)

A DOCSIS Modular CMTS, or M-CMTS, is one in which DOCSIS 3.0 channel bonding is achieved by using a conventional CMTS and extending it with an eQAM, DOCSIS DTI time source, and Gigabit Ethernet (GigE) interfaces. The conventional CMTS line card provides a Local or Primary downstream, which contains all of the DOCSIS MAC layer protocol information necessary for DOCSIS-to-cable modem communication. The basics of this information contain timing Sync messages, Upstream Channel Descriptors (UCDs), Upstream Bandwidth Allocation Map (MAP) messages, Ranging messages, etc. The CMTS line card also provides the inputs for the upstream channels returning from the cable modems, which are then bound by the CMTS. The CMTS will usually have a specialized interface on it with a GigE connector that communicates directly with an eQAM. The eQAM provides the additional downstream bonded channels transmitted to the cable modems. Extremely accurate timing is maintained between the CMTS and the eQAM via a DOCSIS DTI timing reference. The eQAM and the CMTS can be remotely located and multiple DTI timers used and synchronized via GPS to ensure stable clock references. This enables the eQAMs to be located in hub sites where local video distribution is occurring while the CMTS remains at the headend or visa-versa. The modularity of the M-CMTS architecture is extremely advantageous in large systems. eQAMs can be re-purposed for DOCSIS or video as demand calls. The system scales well from four bonded channels, to eight and more as necessary.

Challenges that come with the M-CMTS architecture are on both the RF and IP fronts. In the RF realm, there is a vast amount of RF combining that must occur between the CMTS and the eQAM. At a minimum, headends / hubsites will require significant re-cabling. During this time, one must consider the potential for isolation issues that may occur between different downstreams and upstreams as combining is created for different node combinations. Isolation issues which occur at the source will not be resolvable at the subscriber premise.

In the IP realm, multiple potential failures are introduced with M-CMTS architecture. GigE interfaces are introduced between the CMTS to the eQAM, the CMTS to the back office, and the DTI timers to both the CMTS and the eQAMs. One should ensure that each interface has a redundancy and that the redundant path is fully tested under load prior to any live network failure. Often has been the case where a redundant path has been in place, but has never been tested. When the redundant path was actually exercised it failed to operate or failed to operate at full line rates.  Again, the details of M-CMTS architecture advantages are best left to Sales Engineers and I recommend that you see your vendor for specific recommendations.  For all Salesmen and Sales Engineers, please take my comments lightly, your welcome to send me your recommendations, but I have both I-CMTS and M-CMTS architectures and like them equally.

Read more tutorials

Upcoming events can be seen under Broadband Events. Previous events can be seen under the blog.

  • If you watch on youtube please hit the subscribe button!
  • Let us know what you think and remember to share!  
  • You can find slides at the bottom of the page and some on slideshare.  
  • Find out about events or articles by following us on TwitterLinkedIn or Facebook too.

Also available on iTunes, Google Podcasts, Spotifyvurbl see podcasts “get your tech on”.

Spotify  Vurbl