DOCSIS outlines requirements that each cable operator must maintain in order to reliably transport IP data traffic over a hybrid fiber / coaxial (HFC) cable plant. An important feature of DOCSIS addresses the need to protect IP data against radio frequency (RF) noise impairments.
DOCSIS outlines requirements that each cable operator must maintain in order to reliably transport IP data traffic over a hybrid fiber / coaxial (HFC) cable plant. An important feature of DOCSIS addresses the need to protect IP data against radio frequency (RF) noise impairments.
DOCSIS outlines requirements that each cable operator must maintain in order to reliably transport IP data traffic over a hybrid fiber / coaxial (HFC) cable plant. An important feature of DOCSIS addresses the need to protect IP data against radio frequency (RF) noise impairments.
DOCSIS outlines requirements that each cable operator must maintain in order to reliably transport IP data traffic over a hybrid fiber / coaxial (HFC) cable plant. An important feature of DOCSIS addresses the need to protect IP data against radio frequency (RF) noise impairments.
Document ID: 49780 Contents Introduction SignaltoNoise Ratio How to Obtain SNR and CNR Readings How to View the Noise Floor Upstream Carriers in ZeroSpan Forward Error Correction How to Obtain FEC Counters through SNMP PerModem FEC Counters Upstream Packet Counters Conclusion Appendix Upstream Correctable FEC Percentage Upstream Uncorrectable FEC Percentage Upstream SNR Example of How to Pull OIDs for PerModem 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 ReedSolomon 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 ReedSolomon encoder, where extra parity bytes are added to data frames to ensure that they are errorprotectedand 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. Impulsenoiseinduced 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 carriertonoise 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: Carriertointerference plus ingress (the sum of noise, distortion, commonpath distortion and crossmodulation 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 carriertonoise ratio before it reaches the demodulator chip (RF domain), as measured by a spectrum analyzer. Conversely, SNR is defined as the signaltonoise ratio from the cable modem termination systems (CMTSs) US receiver chip after the carrier has been demodulated to give a pure baseband, signaltonoise 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. SignaltoNoise 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 realworldRF 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 commandline interface (CLI) commands and command outputs are taken from Cisco IOS Software Release 12.2(15)BC2a, unless otherwise specified. Note that an S cardrefers to a cable linecard with builtin hardware spectrum analysis capabilities, whereas a C cardrefers to a cable linecard without this capability. Under certain settings, the S card reports CNR instead of SNR, because it has builtin 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, 16QAM 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 remotequery is configured. These three lines of code can be entered to activate remotequery: snmpserver manager snmpserver community public ro cable modem remotequery 3 public Three seconds was used for a quick response, which may not be recommended in a heavily loaded CMTS. The default readonly 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 macaddress verbose command works as well. How to View the Noise Floor S cards also allow you to view the noise floor with this command: ubr72462# show controller cable6/0 upstream 0 spectrum ? <555> start frequency in MHz <500055000> start frequency in KHz <500000055000000> 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. ubr72462# show controller cable6/0 upstream 0 spectrum 5 55 ? <150> resolution frequency in MHz ubr72462# show controller cable6/0 upstream 0 spectrum 5 55 3 Spect DATA(@0x61359914) for u0: 500055000KHz(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, SNMPbased 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: DOCSIFMIB 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 carriertointerference 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 ZeroSpan A mode worth using in a spectrum analyzer is the zerospan 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 zerospan (time domain) while looking at the upstream traffic from a CM. Figure 1 ZeroSpan 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 ZeroSpan Measurement of Upstream Digitally Modulated Carrier Amplitude Zerospan 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 leakingonto 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 zerospan 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 ReedSolomon 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 perupstream 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 powercycled 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 steadystate 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 DOCSIFMIB SNMP MIB file are used to collect and analyze FEC errors (unerrored, corrected, and uncorrectable FECalso see the Appendix): DOCSIFMIB 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 1 C 0 )]] * 100 % Uncorrectable = [(E u1 E u0 )/ [(E u1 E u0 ) + (E c1 E c0 ) + (C 1 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. PerModem 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 2T 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 sidnumber 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. ubr72462# 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 Queueindicator 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. ubr72462# 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 perCM FEC errors by polling the MIBs and using the multirouter 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 BCM3210based 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 requestopportunities. Collisions in request/dataslots (these types of slots do not occur on Cisco CMTSs). Damaged frames received during bandwidth requestopportunities. Damaged frames received during request/dataslots. The number of damaged ranging requests heard. For JIBbased 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 BCM3210based cards like the MC16C and MC28C, this is the number of damaged frames received in bandwidth requestor rangingintervals. This makes this number a subset of the numbers in errors. Damaged frames received during bandwidth requestopportunities Damaged frames received during request/dataslots. The number of damaged ranging requests heard. For JIBbased 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 leakingonto 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 Tbytes 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 inchannel noise at fairly high levels. Upstream RF problems of an impulsive nature can be confirmed using thirdparty 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 = [(E c1 E c0 )/ [(E u1 E u0 ) + (E c1 E c0 ) + (C 1 C 0 )]] * 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 DOCSIFMIB 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 1 C 0 )]] * 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 realtimeservices, 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 DOCSIFMIB 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 signaltonoise 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 16QAM), 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 DOCSIFMIB docsIfSigQSignalNoise .1.3.6.1.2.1.10.127.1.1.4.1.5 SignaltoNoise ratio as perceived for this channel. At the CM, describes the SignaltoNoise of the downstream channel. At the CMTS, describes the average SignaltoNoise of the upstream channel. Example of How to Pull OIDs for PerModem 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 RFC1213MIB::ifDescr.10 = STRING: "Cable6/0" ! ifIndex of cable 6/0 is "10". RFC1213MIB::ifDescr.36 = STRING: "Cable6/0upstream0" RFC1213MIB::ifDescr.37 = STRING: "Cable6/0upstream1" RFC1213MIB::ifDescr.38 = STRING: "Cable6/0upstream2" RFC1213MIB::ifDescr.39 = STRING: "Cable6/0upstream3" RFC1213MIB::ifDescr.40 = STRING: "Cable6/0downstream" 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 DOCSIFMIB::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 DOCSIFMIB::docsIfCmtsCmStatusUnerroreds.983090 = Counter32: 8165 Note: The Unerroreds counter has incremented somewhat in the time since you issued the show interface cable command.
Uncorrected Codewords Received (docsIfCmtsCmStatusUncorrectables) % snmpget cpublic 172.18.73.167 docsIfCmtsCmStatusUncorrectables.983090 DOCSIFMIB::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 2012 2013 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc. Updated: Oct 04, 2005 Document ID: 49780