To operate a high speed data (HSD) network over a hybrid fiber/coaxial (HFC) cable plant requires a significant level of quality control to ensure data integrity and the highest level of data throughput. The two generally accepted means by which cable operators can measure data quality is by monitoring either the bit error rate (BER) or the packet error rate (PER).

The Data Over Cable Service Interface Specification (DOCSIS) outlines requirements that each cable operator must maintain in order to reliably transport IP data traffic. An important feature of DOCSIS addresses the need to protect IP data against radio frequency (RF) noise impairments. The feature DOCSIS uses to help maintain IP data integrity over HFC cable plants is Reed-Solomon Forward Error Correction (FEC) encoding.

Essentially, FEC encoding protects IP data and DOCSIS Management messages against symbol errors caused by noise and other impairments. The unique feature of FEC is that it can detect symbol errors and also correct them. Thus, DOCSIS specifies that all IP data that is transmitted over a HFC plant should pass through a Reed-Solomon encoder, where extra parity bytes are added to data frames to ensure that they are “error-protected” and less prone to impairments.

Note: FEC does not work very well if the errors are created by impulse noise which creates many errors in succession. Impulse-noise-induced errors are addressed on the downstream with the use of interleaving to make errors appear spread out, which FEC is effective at fixing. DOCSIS 2.0 has added upstream interleaving—which helps with this type of upstream (US) impairment—but it is not available on 1.x cable modems (CMs).

Without question, the cable network’s return path or upstream is particularly vulnerable to noise and related impairments. Such noise can be impulse, ingress noise, thermal noise, laser clipping, and so forth. Without FEC encoding, the chances of a packet being dropped because of bit errors are considerable. FEC errors on a cable plant are not the only quality measure. There are other variables that must be considered, such as carrier-to-noise ratio (CNR).

Carrier-to-interference plus ingress (the sum of noise, distortion, common-path distortion and cross-modulation and the sum of discrete and broadband ingress signals, impulse noise excluded) ratio [will not be] less than 25 dB.

In other words, the DOCSIS minimum recommended US CNR is 25 dB. For the purpose of this document, CNR is defined as the carrier-to-noise ratio before it reaches the demodulator chip (RF domain), as measured by a spectrum analyzer. Conversely, SNR is defined as the signal-to-noise ratio from the cable modem termination system’s (CMTS’s) US receiver chip after the carrier has been demodulated to give a pure baseband, signal-to-noise ratio.

Thus, when one looks at the SNR reading on a Cisco uBR7246 and sees a number like 30 dB, it is easy to assume that the upstream appears to meet or even exceed DOCSIS and that things in the RF world are fine. This is not always the case, however. DOCSIS does not specify SNR, and the CMTS’s SNR estimate is not the same thing as the CNR that one measures with a spectrum analyzer.

This document discusses the uBR’s upstream SNR estimated calculation and also the uBR’s FEC counters and shows why these two variables should be constantly evaluated to ensure HSD quality over HFC environments.

The uBR’s SNR estimate can sometimes be misleading, and should be considered only a starting point when it comes to checking the integrity of the upstream RF spectrum. The SNR reading on the uBR MC16C linecard is provided by the US chip, but the reading is not necessarily a reliable indicator of “real-world” RF impairments, such as impulsive type noise, discrete ingress, and so forth. That is not to say that the US SNR reading is not accurate. In environments with few impairments on the upstream (for example, impulse noise, ingress, common path distortion, and so forth), the US SNR estimate numerically tracks CNR within less than a couple of decibels, when the CNR is in the 15 to 25 dB range. It is accurate with additive white gaussian noise (AWGN) as the only impairment; in the real world, however, the accuracy of these numbers can vary. This depends on the nature of the impairments and better reflects modulation error ratio (MER) rather than CNR.

This section shows a few examples of how to obtain the upstream SNR estimate from the Cisco uBR7200 and uBR10K (also see the Appendix). All command-line interface (CLI) commands and command outputs are taken from Cisco IOS® Software Release 12.2(15)BC2a, unless otherwise specified.

Note that an “S card” refers to a cable linecard with built-in hardware spectrum analysis capabilities, whereas a “C card” refers to a cable linecard without this capability. Under certain settings, the S card reports CNR instead of SNR, because it has built-in hardware to perform spectrum analysis functions.

Tip: When gathering the output of Cisco IOS Software CLI commands for the purposes of troubleshooting or for forwarding to Cisco Technical Support, remember to enable terminal exec prompt timestamp, so that each line of CLI command output is accompanied by a timestamp and by the current CPU load on the CMTS.

Tip: The phy command can be used to report SNR even if CNR is reported in the show controllers command. This is especially useful because SNR is reported after ingress cancellation is performed and CNR is reported before ingress cancellation.

Note: The SNR is listed per modem in EC code with show cable modem detail.

The phy command also lists other physical layer attributes if remote-query is configured. These three lines of code can be entered to activate remote-query:

That output shows the noise under the carrier and at other frequencies.

In addition to the CLI, SNMP-based Network Management tools such as Cisco Broadband Troubleshooter (CBT) can be used to display the US spectrum and other attributes. Also, CiscoWorks can be used to monitor the SNR as reported by cable linecards using the docsiIfSigQSignalNoise object:

DOCS-IF-MIBdocsIfSigQSignalNoise .1.3.6.1.2.1.10.127.1.1.4.1.5
Signal/Noise ratio as perceived for this channel.
At the CM, describes the Signal/Noise of the downstream
channel. At the CMTS, describes the average Signal/Noise
of the upstream channel.

Note: Individual CM SNR readings are only available on the MC5x20S and MC28U linecards. These new linecards incorporate ingress cancellation that may improve performance but can give misleading SNR readings. The SNR readings are after ingress cancellation; so, if ingress cancellation mathematically removes the ingress, then SNR could report much better than the actual carrier-to-interference ratio.

Note: When using spectrum groups on an S card, the show controllers command randomly selects CNR readings from all the CMs on that US, which could be slightly different, giving the appearance of an unstable US port or CNR.

A mode worth using in a spectrum analyzer is the zero-span mode. This is the time domain mode where the display is amplitude versus time rather than amplitude versus frequency. This mode is very beneficial when viewing data traffic that is bursty in nature. Figure 1 shows a spectrum analyzer in zero-span (time domain) while looking at the upstream traffic from a CM.

Figure 1 – Zero-Span Display on a Spectrum Analyzer

Data packets can be seen in Figure 1, along with modem requests and impulse noise. This is very useful for measuring average digital levels and observing noise and ingress, as seen in Figure 2.

Zero-span can also be used to see if packets are colliding with each other from bad timing or poor headend splitter or combiner isolation. A packet intended for one CMTS upstream port is “leaking” onto another upstream. Refer to the white papers and documents listed in the Related Information