Upstream FEC Errors and SNR as Ways to Ensure

Data Quality and Throughput

Document ID: 49780

Introduction
Signal−to−Noise Ratio
How to Obtain SNR and CNR Readings
How to View the Noise Floor
Upstream Carriers in Zero−Span
Forward Error Correction
How to Obtain FEC Counters through SNMP
Per−Modem FEC Counters
Upstream Packet Counters
Conclusion
Appendix
Upstream Correctable FEC Percentage
Upstream Uncorrectable FEC Percentage
Upstream SNR
Example of How to Pull OIDs for Per−Modem FEC Counters on an MC28U or 5x20
Linecard
Related Information

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
interleavingwhich helps with this type of upstream (US) impairmentbut it is not available on 1.x cable
modems (CMs).

Without question, the cable networks 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 systems (CMTSs) 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 CMTSs SNR estimate is not
the same thing as the CNR that one measures with a spectrum analyzer.

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

Signal−to−Noise Ratio
The uBRs 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
vendors 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 standardcould 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 errorseither correctable or uncorrectable FEC errorsshould 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

• FECBlksThe total number of FEC blocks (both good and bad) received by all the upstream ports
associated with a given downstream.
• UnCorFECBlksThe 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.
• CorFECBlksThe 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 FECalso 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:

• Cx = docsIfSigQUnerroreds at time x
• Ecx = docsIfSigQCorrecteds at time x
• Eux = docsIfSigQUncorrectables at time x

% Correctable = [(Ec1 E c0)/ [(Eu1 E u0) + (Ec1 E c0) + (C1 C 0)]] * 100

% Uncorrectable = [(Eu1 E u0)/ [(Eu1 E u0) + (Ec1 E c0) + (C1 C 0)]] * 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 CMTSs 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:

• broadcastsReceived broadcast frames.

• multicastsReceived multicast frames.
• unicastsReceived unicast frames.
• discardsOnly increments on the MC5x20S linecard. Lists packets discarded because of various
error conditions that are specific to the card, not to the actual frame.
• errorsThe 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 protocolNumber 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 inputTotal of broadcasts, multicasts, and unicasts.
• uncorrectableTotal 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.
• noiseFor 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.
• microreflectionsNumber 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 Ciscos 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 chips 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 CM1000refer 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 = [(Ec1 E c0)/ [(Eu1 E u0) + (Ec1 E c0) + (C1 C 0)]] * 100

• C = docsIfSigQUnerroreds
• Ec = docsIfSigQCorrecteds
• Eu = 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 = [(Eu1 E u0)/ [(Eu1 E u0) + (Ec1 E c0) + (C1 C 0)]] * 100

• C = docsIfSigQUnerroreds
• Ec = docsIfSigQCorrecteds
• Eu = 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 modems Codeword counters, you first need to get two pieces of information:

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

• The modems 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

Contacts & Feedback | Help | Site Map

© 2007 − 2008 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of
Cisco Systems, Inc.

Updated: Oct 04, 2005 Document ID: 49780