CM-STATUS messaging improved: why and how?

The CM-STATUS feature is of significant value in DOCSIS 3.x networks. However, originally it was designed in a way it was not 100% reliable. A specification addition in March 2014 changed this messaging facility and it was further fine-tuned in August 2014. This blog post provides an overview on why and how.

CM-STATUS messages are DOCSIS protocol messages which provide indispensable information about specific events impacting the system. In certain cases where the CM detects a failure that the CMTS cannot detect directly, the CM will report the event to the CMTS through a CM-STATUS message. In other cases, the CM can provide valuable additional information. An example event the modem may report is the loss of  a downstream channel. Another example is that the CM detects the removal of a CPE device on its CPE interface. A full list of all CM-STATUS events can be found in the DOCSIS MULPI specification.

Originally the CM-STATUS messages were unacknowledged messages, which resulted in the messages being inherently unreliable. As such, the CM would never have certainty about the effectiveness of the CM-STATUS messages that it had sent.

This unreliability became an issue at the time when certain features began to rely on this message. For example, CM-STATUS feedback is critical in ensuring graceful service degradation when modems need to fall back to partial service operation (which happens when one or more channels are rendered unusable). It is important that the CM can notify the CMTS of such events as quickly as possible as the CMTS is expected to take appropriate action to correct the situation.

To ensure that the CM-STATUS message does reach the CMTS (also in noisy conditions), there was until recently no other option than sending the message numerous times, over and over again. This could be done by using the setting “Maximum Number of Repeated CM-STATUS Reports”. Automatically the question arises “what is an intelligent value for this”?  A few times? Unlimited? Hard to tell. Needless to say, using an unacknowledged message in combination with a potential noisy communication path was an inefficient and unreliable method. The following figure illustrates this legacy CM-STATUS behaviour.

In order to meet the demand for higher reliability, the mechanism has been improved by introducing a “CM-STATUS-ACK” message. As illustrated below, the new message flow is easy: when the CMTS receives a CM-STATUS message from the CM, it must acknowledge it by replying with a CM-STATUS-ACK message.  And when the CM receives a CM-STATUS-ACK message from the CMTS, the CM must immediately cease notifying the event.

Note that Cable Modems and CMTSs will only use this feature if they agree upon it at registration time. Typically, the CMTS first needs to be configured to use the feature. Else, the legacy behavior will be used (using “repeated reports”).

Are your Cable Modems and CMTSes playing nicely together on partial service reporting? If not, you may consider checking for CM-STATUS and CM-STATUS-ACK support. Support is mandatory for all products submitted for certification since August 2014 (ECW56, CW110).

• Category: Cable Modem, Certification Testing, CMTS, DOCSIS