Upstream FEC Errors and SNR as Ways to EnsureData Quality and Throughput

Document ID: 49780

IntroductionSignal−to−Noise RatioHow to Obtain SNR and CNR ReadingsHow to View the Noise FloorUpstream Carriers in Zero−SpanForward Error CorrectionHow to Obtain FEC Counters through SNMPPer−Modem FEC CountersUpstream Packet CountersConclusionAppendix 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 5x20LinecardRelated Information

Introduction

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

The Data Over Cable Service Interface Specification (DOCSIS) outlines requirements that each cable operatormust maintain in order to reliably transport IP data traffic. An important feature of DOCSIS addresses theneed to protect IP data against radio frequency (RF) noise impairments. The feature DOCSIS uses to helpmaintain 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 causedby noise and other impairments. The unique feature of FEC is that it can detect symbol errors and also correctthem. Thus, DOCSIS specifies that all IP data that is transmitted over a HFC plant should pass through aReed−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 insuccession. Impulse−noise−induced errors are addressed on the downstream with the use of interleaving tomake errors appear spread out, which FEC is effective at fixing. DOCSIS 2.0 has added upstreaminterleaving�which helps with this type of upstream (US) impairment�but it is not available on 1.x cablemodems (CMs).

Without question, the cable network�s return path or upstream is particularly vulnerable to noise and relatedimpairments. Such noise can be impulse, ingress noise, thermal noise, laser clipping, and so forth. WithoutFEC encoding, the chances of a packet being dropped because of bit errors are considerable. FEC errors on acable 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 RFperformance. Specifically, Section 2.3.2 of the radio frequency interference (RFI) specification, �AssumedUpstream RF Channel Transmission Characteristics,� states this:

Carrier−to−interference plus ingress (the sum of noise,distortion, common−path distortion and cross−modulation andthe sum of discrete and broadband ingress signals, impulse noiseexcluded) 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 measuredby a spectrum analyzer. Conversely, SNR is defined as the signal−to−noise ratio from the cable modemtermination system�s (CMTS�s) US receiver chip after the carrier has been demodulated to give a purebaseband, 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 toassume 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 notthe 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 countersand shows why these two variables should be constantly evaluated to ensure HSD quality over HFCenvironments.

Signal−to−Noise Ratio

The uBR�s SNR estimate can sometimes be misleading, and should be considered only a starting point whenit comes to checking the integrity of the upstream RF spectrum. The SNR reading on the uBR MC16Clinecard is provided by the US chip, but the reading is not necessarily a reliable indicator of �real−world� RFimpairments, such as impulsive type noise, discrete ingress, and so forth. That is not to say that the US SNRreading 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 thana couple of decibels, when the CNR is in the 15 to 25 dB range. It is accurate with additive white gaussiannoise (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 thanCNR.

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 anduBR10K (also see the Appendix). All command−line interface (CLI) commands and command outputs aretaken 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 reportsCNR 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 orfor forwarding to Cisco Technical Support, remember to enable terminal exec prompt timestamp, so thateach 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 toforce 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 tdma000b.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 controllerscommand. This is especially useful because SNR is reported after ingress cancellation is performed and CNRis 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 linesof code can be entered to activate remote−query:

snmp−server managersnmp−server community public rocable 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 CMvendor�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 Chart5000 : −608000 : −23 ****************11000: −45 *****14000: −46 *****17000: −5520000: −6023000: −6026000: −5529000: −18 *******************32000: −6035000: −6038000: −6041000: −5544000: −45 *****47000: −6050000: −6053000: −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 monitorthe 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 newlinecards incorporate ingress cancellation that may improve performance but can give misleading SNRreadings. The SNR readings are after ingress cancellation; so, if ingress cancellation mathematically removesthe 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 CNRreadings from all the CMs on that US, which could be slightly different, giving the appearance of an unstableUS 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 thedisplay is amplitude versus time rather than amplitude versus frequency. This mode is very beneficial whenviewing 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 formeasuring 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 headendsplitter or combiner isolation. A packet intended for one CMTS upstream port is �leaking� onto anotherupstream. 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 thezero−span measurement procedure.

Virtually all of the RF impairments mentioned so far in this document can degrade upstream performance andmanifest themselves as poor data throughput without necessarily being reflected as low SNR. Observinguncorrectable FEC errors (analogous to poor BER and PER)�even though the SNR appears to be above theminimum DOCSIS standard�could point to other transient issues that need to be addressed. There could alsobe 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 toallow 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 everoccur. When uncorrectable FEC errors do exist, however, the effects can be severe and can be caused by anynumber of different factors. This is a list of known events which could introduce uncorrectable FEC errors onthe 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 2004Interface Cable3/0Hardware 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 portsassociated with a given downstream.

•

UnCorFECBlks�The total number of FEC blocks received by all the upstream ports associated witha given downstream that were so corrupted by noise or ingress that they could not be corrected orrecovered by the FEC algorithm.

•

CorFECBlks�The total number of FEC blocks received by all the upstream ports associated with agiven downstream that were slightly corrupted by noise or ingress and that could be corrected andrecovered by the FEC algorithm.

•

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

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

A percentage can be estimated by taking UnCorrFECBlks / FECBlks × 100. The FECBlks counter is thetotal FEC Blocks sent, whether good or bad. This output is for the whole MAC domain (all USs). It is best tolook 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 showcable hop command to view correctable or uncorrectable FEC errors per upstream port, but not the total FECblocks.

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 2004Upstream Port Poll Missed Min Missed Hop Hop Corr UncorrPort Status Rate Poll Poll Poll Thres Period FEC FEC (ms) Count Sample Pcnt Pcnt (sec) Errors ErrorsCable6/0/U0 21.810 MHz 1000 0 10 0% 75% 15 2664305 3404

Cable6/0/U1 admindown 1000 * * * frequency not set * * * 0 0Cable6/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 theshow controllers counter. The controller counters may only be cleared if the CMTS is reloaded or theinterface 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 mostlikely cause poor upstream data throughput. Before events get to this critical stage, however, there arepredictors and indications that upstream performance is deteriorating. Correctable FEC errors serve as anindicator that upstream data throughput is degrading and serve as a warning sign that future uncorrectableFEC errors are possible.

Tip: If the Uncorr counter increments much faster than the Corr counter, then the problem could be relatedto impulse noise. If the Corr counter is incrementing as fast (or faster than) the Uncorr counter, then it isprobably 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 FECerrors (unerrored, corrected, and uncorrectable FEC�also see the Appendix):

DOCS−IF−MIBdocsIfSigQUnerroreds .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 CMTSis 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 knownas FEC data blocks) received on this US, including all CWs, whether or not they were part of frames destinedfor 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. Youmight 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 + 18ethernet header} + (guardband)

Everything between { and } is added up, cut into CWs based on the modulation profile, then 2×T is added toeach CW. So technically, if the specific codeword that holds the SID is dropped, how can the CMTSdistinguish from which modem it was sent? One way to achieve this is to use the CMTS�s scheduler, whichknows 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−numbercounter 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 2004Sid : 10Request polls issued : 0BWReqs {Cont,Pigg,RPoll,Other} : 1, 527835, 0, 0No grant buf BW request drops : 0Rate exceeded BW request drops : 0Grants issued : 1787705Packets received : 959478Bytes received : 1308727992Fragment reassembly completed : 0Fragment reassembly incomplete : 0Concatenated packets received : 0Queue−indicator bit statistics : 0 set, 0 grantedGood Codewords rx : 7412780Corrected Codewords rx : 186Uncorrectable Codewords rx : 11Concatenated headers received : 416309Fragmentation headers received : 1670285Fragmentation 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 2004Upstream Port Poll Missed Min Missed Hop Hop Corr UncorrPort Status Rate Poll Poll Poll Thres Period FEC FEC (ms) Count Sample Pcnt Pcnt (sec) Errors ErrorsCable6/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 probablybecause 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−routertraffic grapher (MRTG) or other software such as Cisco BT. This could be used to see if particular modemshave poor group delay, microreflections, and so forth. This would be something that only affects a specificmodem.

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 2004Cable5/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 variouserror 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 valuecounts are for BCM3210−based cards like the MC16C and MC28C:

The number of allocated upstream slots where the preamble and Unique Word were notreceived 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 withmalformed 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 inshow 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 damagedframes received in bandwidth �request� or �ranging� intervals. This makes this number a subset ofthe 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 initialranging request collisions and bandwidth request collisions. So, an incrementing noise counter does notalways mean that there is a problem. It might just mean that the customer has a lot of modems trying to comeonline or has modems trying to make more transmissions (leading to more of the collisions mentioned). Thenoise counter is actually a subset of the errors counter because noise includes the last threecomponents of the errors counter.

Conclusion

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

The presence of uncorrectable FEC errors is a good measure when noise gets to an intolerable levelor when packets are colliding with each other from bad timing or poor headend splitter or combinerisolation. With regard to the latter, a packet intended for one CMTS upstream port is �leaking� ontoanother 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 notresult in packet drops or poor voice quality, as long as there are no accompanying uncorrectable FECerrors.

•

Increasing the FEC T−bytes in the US modulation profile may help up to a certain point, but itdepends 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 ofuncorrectable FEC errors is high enough, then voice quality issues are experienced, whereas IP data mightonly be minimally affected.

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

Figure 3 highlights an example of a US experiencing low SNR at the same time that it is experiencinguncorrectable and correctable FEC errors, emphasizing the close relationship between these two parameterswhen 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 graphindicates poor SNR readings at the same instance in time. A quick check of the upstream digitally modulatedcarrier on a spectrum analyzer (such as an Agilent HP8591C) would probably show in−channel noise at fairlyhigh 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 measureupstream block error rate (similar to BER). This would verify that an RF problem likely exists, even when theUS 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 theRF is alright. A little research with appropriate test equipment might be required to determine exactly what isgoing on in the RF domain. The odds are pretty good that the RF spectrum is not as clean as was firstassumed.

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 notthey 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 thatinterface. It is suggested that this ratio be below 5% of all input CWs.

Detailed Info

DOCS−IF−MIBdocsIfSigQUnerroreds .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 notthey 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 numberof 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 theloss is burst or random.

Detailed Info

DOCS−IF−MIBdocsIfSigQUnerroreds .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 upstreamchannel.

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 upstreammodulation 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−MIBdocsIfSigQSignalNoise .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 anMC28U 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 Enb0005.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 : 50Good Codewords rx : 7580Corrected Codewords rx : 0Uncorrectable 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 canfind 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 showinterface 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 ofCisco Systems, Inc.

Updated: Oct 04, 2005 Document ID: 49780