Upstream FEC Errors and SNR as Ways to Ensure Data Quality and Throughput

Introduction

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).

The DOCSIS standard includes recommended parameters for both downstream and upstream cable TV RF performance. Specifically, Section 2.3.2 of the radio frequency interference (RFI) specification, Assumed Upstream RF Channel Transmission Characteristics,€ states this:

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.

Signal-to-Noise Ratio

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.

How to Obtain SNR and CNR Readings

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.

For S cards:

ubr7246# show controller cable6/0 upstream 0

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
 Cable6/0 Upstream 0 is up
  Frequency 21.810 MHz, Channel Width 3.2 MHz, 16-QAM Symbol Rate 2.560 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement - 38 dB

For C cards or S cards without spectrum groups assigned:

ubr7246vxr# show controller cable3/0 upstream 0

Load for five secs: 10%/1%; one minute: 7%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
 Cable3/0 Upstream 0 is up
  Frequency 25.392 MHz, Channel Width 3.200 MHz, QPSK Symbol Rate 2.560 Msps
  Spectrum Group is overridden
  BroadCom SNR_estimate for good packets - 26.8480 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2035

It is recommended that you keep the US level set at the default of 0 dBmV and use external attenuators to force modems to transmit at higher levels, if necessary.

ubr7246# show cable modem phy

MAC Address    I/F     Sid USPwr  USSNR  Timing MicrReflec DSPwr DSSNR Mode
                          (dBmV)  (dB)   Offset (dBc)     (dBmV) (dB)
0002.8a8c.6462 C6/0/U0  9  46.07  35.42  2063   31        -1.05  39.05  tdma
000b.06a0.7116 C6/0/U0  10 48.07  36.12  2037   46         0.05  41.00  atdma

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:

snmp-server manager
snmp-server community public ro
cable modem remote-query 3 public

Three seconds was used for a quick response, which may not be recommended in a heavily loaded CMTS. The default read-only community string in most modems is public.

Note: Disregard the microreflection entry, because this is for DS and is limited by the accuracy of the CM vendor's implementation.

ubr7246# show cable modem 000b.06a0.7116 cnr

MAC Address    IP Address      I/F      MAC     Prim  snr/cnr
                                        State   Sid   (dB)
000b.06a0.7116 10.200.100.158  C6/0/U0  online  10     38

This command lists SNR when using a C card. When an S card is used and spectrum groups are assigned, CNR is reported. The show cable modem mac-address verbose command works as well.

How to View the Noise Floor

S cards also allow you to view the noise floor with this command:

ubr7246-2# show controller cable6/0 upstream 0 spectrum ?

  <5-55>              start frequency in MHz
  <5000-55000>        start frequency in KHz
  <5000000-55000000>  start frequency in Hz
  A.B.C.D             IP address of the modem
  H.H.H               MAC address of the modem

Adding the modem IP or MAC address to the command shows the modem burst power and channel width.

ubr7246-2# show controller cable6/0 upstream 0 spectrum 5 55 ?

  <1-50>  resolution frequency in MHz

ubr7246-2# show controller cable6/0 upstream 0 spectrum 5 55 3

Spect DATA(@0x61359914) for u0: 5000-55000KHz(resolution 3000KHz, sid 0:
Freq(KHz) dBmV Chart
5000 :    -60
8000 :    -23  ****************
11000:    -45  *****
14000:    -46  *****
17000:    -55
20000:    -60
23000:    -60
26000:    -55
29000:    -18  *******************
32000:    -60
35000:    -60
38000:    -60
41000:    -55
44000:    -45  *****
47000:    -60
50000:    -60
53000:    -41  *******

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-MIB
docsIfSigQSignalNoise	.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.

Upstream Carriers in Zero-Span

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.

Figure 2 - Zero-Span Measurement of Upstream Digitally Modulated Carrier Amplitude

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 section of this document. Refer to Connecting the Cisco uBR7200 Series Router to the Cable Headend for a description of the zero-span measurement procedure.

Virtually all of the RF impairments mentioned so far in this document can degrade upstream performance and manifest themselves as poor data throughput without necessarily being reflected as low SNR. Observing uncorrectable FEC errors (analogous to poor BER and PER)—even though the SNR appears to be above the minimum DOCSIS standard—could point to other transient issues that need to be addressed. There could also be a rogue CM causing errors and a poor SNR reading for all the other CMs on the same US. In this case, CNR as measured on a spectrum analyzer would look fine, but the CMTS would report otherwise.

Forward Error Correction

Recall that Reed-Solomon FEC encoding is used to add redundant parity bytes to data packets, in order to allow the detection and correction of burst errors introduced by the cable plant.

In an ideal world, measurable bit errors—either correctable or uncorrectable FEC errors—should rarely ever occur. When uncorrectable FEC errors do exist, however, the effects can be severe and can be caused by any number of different factors. This is a list of known events which could introduce uncorrectable FEC errors on the upstream and which should be considered when troubleshooting FEC errors:

• sweep transmitter interference

• amplifier overload (compression, which is a form of clipping)

• laser clipping

• impulsive noise or ingress interference

• loose or intermittent connections

• poor upstream combiner or splitter isolation

• faulty modems

There are two methods with which one can collect FEC information:

• CLI

• SNMP object identifier (OID) polling

This is an example of how to collect FEC information using the CLI (also see the Appendix):

ubr7246vxr# show controller cable3/0

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Interface Cable3/0
Hardware is MC16C

!--- Output suppressed.

 Slots 937882 NoUWCollNoEngy 82 FECorHCS 4 HCS 4
 Req 1160824263 ReqColl 350 ReqNoise 96 ReqNoEnergy 1160264889
 ReqData 0 ReqDataColl 0 ReqDataNoise 0 ReqDataNoEnergy 0
 Rng 609652 RngColl 0 RngNoise 76
 FECBlks 1638751 UnCorFECBlks 7 CorFECBlks 4
     

• FECBlks—The total number of FEC blocks (both good and bad) received by all the upstream ports associated with a given downstream.

• UnCorFECBlks—The total number of FEC blocks received by all the upstream ports associated with a given downstream that were so corrupted by noise or ingress that they could not be corrected or recovered by the FEC algorithm.

• CorFECBlks—The total number of FEC blocks received by all the upstream ports associated with a given downstream that were slightly corrupted by noise or ingress and that could be corrected and recovered by the FEC algorithm.

Station maintenance bursts increment the FECBlks counter by approximately 2 per x seconds, where x is the minimum polling interval (as displayed in the show cable hop command) divided by 1000. Remote query also increments this counter, as does initial maintenance when modems come online. Because initial maintenance occurs during contention time, there could be collisions and subsequent uncorrectable FEC errors.

Tip: Be sure modems are not ranging or coming online before assuming the US is unstable just because the uncorrectable FEC counters are incrementing. Also, the NoUwCollNoEngy value might increase if there are modems with timing issues. Unique Word is specific to BRCM, not DOCSIS, and is the last few bytes of the preamble.

A percentage can be estimated by taking UnCorrFECBlks / FECBlks × 100. The FECBlks counter is the total FEC Blocks sent, whether good or bad. This output is for the whole MAC domain (all USs). It is best to look at the counters between a set time period to see the delta.

Note: One disadvantage of collecting FEC information using the CLI is that the UnCorFECBlks, CorFECBlks, and total FECBlks are not separated out per upstream.

In order to look at per-upstream FEC information, you should use SNMP OIDs. You can also use the show cable hop command to view correctable or uncorrectable FEC errors per upstream port, but not the total FEC blocks.

ubr7246# show cable hop

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Upstream    Port       Poll Missed Min    Missed Hop   Hop    Corr    Uncorr
Port        Status     Rate Poll   Poll   Poll   Thres Period FEC     FEC
                       (ms) Count  Sample Pcnt   Pcnt  (sec)  Errors  Errors
Cable6/0/U0 21.810 MHz 1000 0      10     0%     75%   15     2664305 3404
Cable6/0/U1 admindown  1000 * * *   frequency not set   * * * 0       0
Cable6/0/U2 10.000 MHz 1000 * * *set to fixed frequency * * * 0       0
     

Note: The clear counters command only clears the show interface and show cable hop counters, but not the show controllers counter. The controller counters may only be cleared if the CMTS is reloaded or the interface is power-cycled with this command:

ubr# cable power off slot/card

     

For emphasis, it is worth repeating that uncorrectable FEC errors result in dropped packets and will most likely cause poor upstream data throughput. Before events get to this critical stage, however, there are predictors and indications that upstream performance is deteriorating. Correctable FEC errors serve as an indicator that upstream data throughput is degrading and serve as a warning sign that future uncorrectable FEC errors are possible.

Tip: If the Uncorr counter increments much faster than the Corr counter, then the problem could be related to impulse noise. If the Corr counter is incrementing as fast (or faster than) the Uncorr counter, then it is probably related to AWGN or it is a steady-state ingress problem like citizen band (CB), shortwave radio, common path distortion (CPD), and so forth.

How to Obtain FEC Counters through SNMP

These three SNMP OIDs from the DOCS-IF-MIB SNMP MIB file are used to collect and analyze FEC errors (unerrored, corrected, and uncorrectable FEC—also see the Appendix):

DOCS-IF-MIB
docsIfSigQUnerroreds       .1.3.6.1.2.1.10.127.1.1.4.1.2
      Codewords received on this channel without error.
      This includes all codewords, whether or not they
      were part of frames destined for this device.

docsIfSigQCorrecteds       .1.3.6.1.2.1.10.127.1.1.4.1.3
      Codewords received on this channel with correctable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

docsIfSigQUncorrectables   .1.3.6.1.2.1.10.127.1.1.4.1.4
      Codewords received on this channel with uncorrectable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

Because those three MIBs are absolute values (based on the total number of FEC data blocks that the CMTS is receiving), calculating the percentage provides a better picture of actual upstream throughput performance. These formulas should be used:

• C_x = docsIfSigQUnerroreds at time x

• E_cx = docsIfSigQCorrecteds at time x

• E_ux = docsIfSigQUncorrectables at time x

% Correctable = [(E_c1 – E_c0)/ [(E_u1 – E_u0) + (E_c1 – E_c0) + (C₁ – C₀)]] * 100

% Uncorrectable = [(E_u1 – E_u0)/ [(E_u1 – E_u0) + (E_c1 – E_c0) + (C₁ – C₀)]] * 100

Note: Uncorrectables plus unerroreds plus correcteds equal the total number of codewords (CWs; also known as FEC data blocks) received on this US, including all CWs, whether or not they were part of frames destined for the CMTS. The size of a CW is determined by the modulation profile.

Per-Modem FEC Counters

If a US packet is dropped, it increments an Uncorr FEC counter. This occurs in the physical layer. You might ask how the CMTS distinguishes a dropped packet, if it does not have a chance to see the Service ID (SID) or source address (layer 2). However, the CM SID is included in the DOCSIS header.

Example of a US burst:

(preamble) + {(docsis hdr = 6 bytes) + (BPI+, docsis extended hdr = 4 to 7 bytes) + 1500 ethernet + 18 ethernet header} + (guardband)

Everything between { and } is added up, cut into CWs based on the modulation profile, then 2×T is added to each CW. So technically, if the specific codeword that holds the SID is dropped, how can the CMTS distinguish from which modem it was sent? One way to achieve this is to use the CMTS’s scheduler, which knows the time when certain packets would be arriving from specific modems.

You can display the FEC values listed per modem using the show interface cableport/slot sid sid-number counter verbose command. You can also retrieve them through SNMP using these OIDs:

• Good Codewords Received (docsIfCmtsCmStatusUnerroreds)

• Corrected Codewords Received (docsIfCmtsCmStatusCorrecteds)

• Uncorrected Codewords Received (docsIfCmtsCmStatusUncorrectables)

Note: This is currently only relevant for the MC28U and MC5x20 linecards.

ubr7246-2# show interface cable6/0 sid 10 counter verbose

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Sid                            : 10
Request polls issued           : 0
BWReqs {Cont,Pigg,RPoll,Other} : 1, 527835, 0, 0
No grant buf BW request drops  : 0
Rate exceeded BW request drops : 0
Grants issued                  : 1787705
Packets received               : 959478
Bytes received                 : 1308727992
Fragment reassembly completed  : 0
Fragment reassembly incomplete : 0
Concatenated packets received  : 0
Queue-indicator bit statistics : 0 set, 0 granted
Good Codewords rx              : 7412780
Corrected Codewords rx         : 186
Uncorrectable Codewords rx     : 11
Concatenated headers received  : 416309
Fragmentation headers received : 1670285
Fragmentation headers discarded: 17

This is specific to this modem and the counters update approximately every 10 seconds.

ubr7246-2# show cable hop cable6/0

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Upstream      Port       Poll Missed Min    Missed Hop   Hop    Corr    Uncorr
Port          Status     Rate Poll   Poll  Poll   Thres Period  FEC     FEC
                         (ms) Count  Sample Pcnt   Pcnt  (sec)  Errors  Errors
Cable6/0/U0   23.870 MHz 1000 0      10     0%     75%   15     186     12
     

Notice that the show cable hop command is reporting one more Uncorr FEC errors. This is probably because a CW was dropped that happened to belong to another modem.

It would be interesting to see a graph of per-CM FEC errors by polling the MIBs and using the multi-router traffic grapher (MRTG) or other software such as Cisco BT. This could be used to see if particular modems have poor group delay, microreflections, and so forth. This would be something that only affects a specific modem.

Upstream Packet Counters

Another command that lists errors is the show interface cable5/1/0 upstream command. This is packets, which are different from FEC CWs. A packet could consist of many CWs.

ubr10k# show interface cable5/1/0 upstream

Load for five secs: 4%/0%; one minute: 5%; five minutes: 5%
Time source is NTP, 03:53:43.488 UTC Mon Jan 26 2004
Cable5/1/0: Upstream 0 is up
     Received 48 broadcasts, 0 multicasts, 14923 unicasts
     0 discards, 32971 errors, 0 unknown protocol
     14971 packets input, 72 uncorrectable
     4 noise, 0 microreflections
     Total Modems On This Upstream Channel: 12 (12 active)

These are the definitions of terms:

• broadcasts—Received broadcast frames.

• multicasts—Received multicast frames.

• unicasts—Received unicast frames.

• discards—Only increments on the MC5x20S linecard. Lists packets discarded because of various error conditions that are specific to the card, not to the actual frame.

• errors—The total of a whole range of errors, many of which do not matter. The errors that this value counts are for BCM3210-based cards like the MC16C and MC28C:

  • The number of allocated upstream slots where the preamble and Unique Word were not received properly.

  • The number of uncorrectable frames received.

  • Collisions in the bandwidth “request” opportunities.

  • Collisions in “request/data” slots (these types of slots do not occur on Cisco CMTSs).

  • Damaged frames received during bandwidth “request” opportunities.

  • Damaged frames received during “request/data” slots.

  • The number of damaged ranging requests heard.

  For JIB-based linecards like the MC5x20 and MC28U:

  • Upstream errored frames that, for some reason, are not classified as header check sequence (HCS) or cyclic redundancy check (CRC) errored.

  • Upstream frames with HCS problems.

  • Upstream frames with CRC errors.

  • Uncorrectable CWs received.

  • Collisions in the bandwidth request IUC.

• unknown protocol—Number of frames received that were not IP, Address Resolution Protocol (ARP), or Point to Point Protocol over Ethernet (PPPoE). This counter also includes frames with malformed DOCSIS headers or invalid header options.

• packets input—Total of broadcasts, multicasts, and unicasts.

• uncorrectable—Total number of frames that had at least one uncorrectable FEC CW within them. This field shows N/A for the MC5x20 and 28U. Use the Uncorr FEC Errors column in show cable hop output instead, to get an idea about uncorrectable errors.

• noise—For BCM3210-based cards like the MC16C and MC28C, this is the number of damaged frames received in bandwidth “request” or “ranging” intervals. This makes this number a subset of the numbers in errors.

  • Damaged frames received during bandwidth “request” opportunities

  • Damaged frames received during “request/data” slots.

  • The number of damaged ranging requests heard.

  For JIB-based cards like the MC5x20 this counter does not increment at all.

• microreflections—Number of microreflections; always set to 0.

The errors and noise counters do not just count corrupted frames; they also count things like initial ranging request collisions and bandwidth request collisions. So, an incrementing noise counter does not always mean that there is a problem. It might just mean that the customer has a lot of modems trying to come online or has modems trying to make more transmissions (leading to more of the collisions mentioned). The noise counter is actually a subset of the errors counter because noise includes the last three components of the errors counter.

Conclusion

Through experience and lab testing done by Cisco’s Advance Services and Rapid Response group, these are a few observations regarding FEC and poor upstream performance:

• The presence of uncorrectable FEC errors is a good measure when noise gets to an intolerable level or when packets are colliding with each other from bad timing or poor headend splitter or combiner isolation. With regard to the latter, a packet intended for one CMTS upstream port is “leaking” onto another upstream because of the poor isolation.

• A large increase in uncorrectable FEC errors results in voice quality issues.

• Correctable FEC errors are seen as the level of noise is increased. Correctable FEC errors do not result in packet drops or poor voice quality, as long as there are no accompanying uncorrectable FEC errors.

• Increasing the FEC T-bytes in the US modulation profile may help up to a certain point, but it depends on the noise source. Seven to ten percent FEC coverage seems optimal.

From the previous observations, it is clear that polling the CMTS for the uncorrectable FEC errors is valuable. Voice over IP (VoIP) over cable is particularly sensitive to uncorrectable FEC errors. If the percentage of uncorrectable FEC errors is high enough, then voice quality issues are experienced, whereas IP data might only be minimally affected.

Finally, if the US chip’s SNR reading is misleading when fast transient RF impairments are introduced (as stated earlier) but uncorrectable FEC errors are still occurring, troubleshooting the problem can get considerably more complex.

Figure 3 highlights an example of a US experiencing low SNR at the same time that it is experiencing uncorrectable and correctable FEC errors, emphasizing the close relationship between these two parameters when measuring upstream performance.

Figure 3 – SNR and FEC Errors Over Time

 

The first graph displays the uncorrectable and correctable FEC error percentage, while the bottom graph indicates poor SNR readings at the same instance in time. A quick check of the upstream digitally modulated carrier on a spectrum analyzer (such as an Agilent HP8591C) would probably show in-channel noise at fairly high levels. Upstream RF problems of an impulsive nature can be confirmed using third-party test equipment (such as Hukk CM1000—refer to the Sunrise Telecom Web Site—or Acterna DSAM) that can measure upstream block error rate (similar to BER). This would verify that an RF problem likely exists, even when the US SNR reading appears to be good.

The bottom line is that if the US SNR reading appears to be good then do not automatically assume that the RF is alright. A little research with appropriate test equipment might be required to determine exactly what is going on in the RF domain. The odds are pretty good that the RF spectrum is not as clean as was first assumed.

Appendix

This section details the upstream parameters to monitor.

Upstream Correctable FEC Percentage

Description

Percentage of CWs received on this channel with uncorrectable errors. This includes all CWs, whether or not they were part of frames destined for this device.

Formula

%Correctable = [(E_c1 – E_c0)/ [(E_u1 – E_u0) + (E_c1 – E_c0) + (C₁ – C₀)]] * 100

• C = docsIfSigQUnerroreds

• E_c = docsIfSigQCorrecteds

• E_u = docsIfSigQUncorrectables

Net Rule

Values >2.5% of received packets are highlighted yellow.

Values >=5% of received packets are bold red.

Net Info

Percentage of input CWs with correctable FEC errors, relative to the total number of CWs received on that interface. It is suggested that this ratio be below 5% of all input CWs.

Detailed Info

DOCS-IF-MIB
docsIfSigQUnerroreds       .1.3.6.1.2.1.10.127.1.1.4.1.2
      Codewords received on this channel without error.
      This includes all codewords, whether or not they
      were part of frames destined for this device.

docsIfSigQCorrecteds       .1.3.6.1.2.1.10.127.1.1.4.1.3
      Codewords received on this channel with correctable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

docsIfSigQUncorrectables   .1.3.6.1.2.1.10.127.1.1.4.1.4
      Codewords received on this channel with uncorrectable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

Upstream Uncorrectable FEC Percentage

Description

Percentage of CWs received on this channel with uncorrectable errors. This includes all CWs, whether or not they were part of frames destined for this device.

Formula

%Uncorrectable = [(E_u1 – E_u0)/ [(E_u1 – E_u0) + (E_c1 – E_c0) + (C₁ – C₀)]] * 100

• C = docsIfSigQUnerroreds

• E_c = docsIfSigQCorrecteds

• E_u = docsIfSigQUncorrectables

Net Rule

Values >0.5% of received CWs are highlighted yellow.

Values >=1% of received CWs are bold red.

Net Info

Drops percentage for input CWs shows the percentage of CWs dropped on input, relative to the total number of CWs received on that interface. It is suggested that this ratio be below 0.5% of all input CWs.

Note: Specific “real-time” services, such as VoIP, may require more stringent monitoring. A 1% uncorrectable FEC value might still be sufficient packet loss to cause voice quality issues, depending on if the loss is burst or random.

Detailed Info

DOCS-IF-MIB
docsIfSigQUnerroreds       .1.3.6.1.2.1.10.127.1.1.4.1.2
      Codewords received on this channel without error.
      This includes all codewords, whether or not they
      were part of frames destined for this device.

docsIfSigQCorrecteds       .1.3.6.1.2.1.10.127.1.1.4.1.3
      Codewords received on this channel with correctable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

docsIfSigQUncorrectables   .1.3.6.1.2.1.10.127.1.1.4.1.4
      Codewords received on this channel with uncorrectable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

Upstream SNR

Description

SNR as perceived for this channel. At the CMTS, describes the average signal-to-noise of the upstream channel.

Formula

SNR = docsIfSigQSignalNoise / 10

Net Rule

Values <27 dB are highlighted yellow.

Values <23 dB are bold red.

Net Info

DOCSIS specifies a minimum CNR (digitally equivalent to SNR) of 25 dB. Depending on the upstream modulation profile configured (QPSK or 16-QAM), the minimum SNR of 25 dB may need to be increased.

Detailed Info

ubr7246vxr# show controller cable3/0 upstream 0

 Cable3/0 Upstream 0 is up
  Frequency 25.392 MHz, Channel Width 3.200 MHz, QPSK Symbol Rate 2.560 Msps
  Spectrum Group is overridden
  BroadCom SNR_estimate for good packets - 26.8480 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2035
  
DOCS-IF-MIB
docsIfSigQSignalNoise      .1.3.6.1.2.1.10.127.1.1.4.1.5
      Signal-to-Noise ratio as perceived for this channel.
      At the CM, describes the Signal-to-Noise of the downstream
      channel.  At the CMTS, describes the average Signal-to-Noise
      of the upstream channel.

Example of How to Pull OIDs for Per-Modem FEC Counters on an MC28U or 5x20 Linecard

ubr7246# show cable modem 10.200.100.115

MAC Address    IP Address    I/F        MAC    Prim  RxPwr   Timing  Num  BPI
                                        State  Sid   (dBmV)  Offset  CPE  Enb
0005.5e25.bdfd 10.200.100.115  C6/0/U0  online 50     0.50   2077    0    N

ubr7246# show interface cable 6/0 sid 50 counters verbose | incl Sid|Codeword

Sid                            : 50
Good Codewords rx              : 7580
Corrected Codewords rx         : 0
Uncorrectable Codewords rx     : 2

In order to find this modem’s Codeword counters, you first need to get two pieces of information:

• The SNMP Interface Index of the cable 6/0 interface.

• The modem’s docsIfCmtsServiceNewCmStatusIndex.

Find the ifIndex of cable 6/0 with this command:

% snmpwalk -cpublic 172.18.73.167 ifDescr | grep Cable6/0

RFC1213-MIB::ifDescr.10 = STRING: "Cable6/0"

!--- ifIndex of cable 6/0 is "10".

RFC1213-MIB::ifDescr.36 = STRING: "Cable6/0-upstream0"
RFC1213-MIB::ifDescr.37 = STRING: "Cable6/0-upstream1"
RFC1213-MIB::ifDescr.38 = STRING: "Cable6/0-upstream2"
RFC1213-MIB::ifDescr.39 = STRING: "Cable6/0-upstream3"
RFC1213-MIB::ifDescr.40 = STRING: "Cable6/0-downstream"

Find the docsIfCmtsServiceNewCmStatusIndex of modem with SID 50 on interface with ifIndex 10 (cable 6/0) with this command:

% snmpwalk -cpublic 172.18.73.167 docsIfCmtsServiceNewCmStatusIndex.10.50

DOCS-IF-MIB::docsIfCmtsServiceNewCmStatusIndex.10.50 = INTEGER: 983090
     

Now that you have the docsIfCmtsServiceNewCmStatusIndex of the modem (983090), you can find these FEC counters:

• Good Codewords Received (docsIfCmtsCmStatusUnerroreds)

  % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUnerroreds.983090
  
  DOCS-IF-MIB::docsIfCmtsCmStatusUnerroreds.983090 = Counter32: 8165
           

  Note: The Unerroreds counter has incremented somewhat in the time since you issued the show interface cable command.

• Corrected Codewords Received (docsIfCmtsCmStatusCorrecteds)

  % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusCorrecteds.983090
  
  DOCS-IF-MIB::docsIfCmtsCmStatusCorrecteds.983090 = Counter32: 0
           

• Uncorrected Codewords Received (docsIfCmtsCmStatusUncorrectables)

  % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUncorrectables.983090
  
  DOCS-IF-MIB::docsIfCmtsCmStatusUncorrectables.983090 = Counter32: 2
           

Related Information

• Understanding Data Throughput in a DOCSIS World
• Upstream Modulation Profiles for Cable Linecards
• DOCSIS Radio Frequency Interface Specification
• Broadband Cable Technology Support
• Technical Support - Cisco Systems