Monitoring

DOCSIS has gone through several major versions since the original 1997 specification, and each one changed what actually needs monitoring. Most day-to-day monitoring - signal levels, error rates, registration status - comes from one foundational MIB, DOCS-IF-MIB, which covers every DOCSIS-compliant modem and CMTS the same way regardless of manufacturer. But it doesn't cover everything a modern device does on its own - each major version past 2.0 added physical-layer capability substantial enough to need an additional MIB, and knowing which version a device speaks determines which of the MIBs in this guide actually apply to it:

• DOCSIS 1.0 (1997) - the original. Single-carrier QAM in both directions, TDMA upstream scheduling, no meaningful QoS. The DOCS-IF-MIB objects covered throughout this guide work against a 1.0 device.
• DOCSIS 1.1 - added real QoS (service flows, the objects behind docsIfQosProfileTable) so latency-sensitive traffic like VoIP could get differentiated treatment, plus Baseline Privacy for link encryption. No new physical-layer monitoring needs.
• DOCSIS 2.0 - added S-CDMA as a second upstream access method alongside TDMA, wider 6.4 MHz upstream channels, and higher upstream modulation orders (up to 128-QAM with trellis coding in S-CDMA mode). Still one channel at a time; still fully covered by DOCS-IF-MIB.
• DOCSIS 3.0 - the first version that actually requires a second MIB. Its headline feature, channel bonding, lets a modem use several downstream and upstream channels simultaneously as one logical pipe (up to roughly 340 Mbit/s downstream, 120 Mbit/s upstream when bonding multiple 6-8 MHz channels). DOCS-IF-MIB's tables have no concept of "this modem has more than one active channel of the same type" - that's what DOCS-IF3-MIB exists to add, covered below. DOCSIS 3.0 also added IPv6 support and AES encryption, neither of which changes RF-layer monitoring.
• DOCSIS 3.1 (2013) - a much bigger jump than any prior version. Single-carrier QAM is replaced with OFDM downstream and OFDMA upstream: instead of one wide signal per channel, the spectrum is divided into thousands of narrow, independently-modulated subcarriers, in channels up to 192 MHz downstream and 96 MHz upstream - versus 6-8 MHz and 6.4 MHz respectively for everything before it. Modulation orders go up to 4096-QAM mandatory (8192/16384-QAM optional) downstream, and LDPC/BCH forward error correction replaces the older Reed-Solomon FEC. None of DOCS-IF-MIB or DOCS-IF3-MIB's tables understand a subcarrier, a modulation profile, or an OFDM control channel - DOCS-IF31-MIB exists specifically to monitor what's genuinely new here, covered in depth further below.
• DOCSIS 4.0 (spec finalized 2017) - extends 3.1 to use the full cable plant spectrum (up to roughly 1.8 GHz) simultaneously in both directions, enabling symmetrical multi-gigabit service, while staying backward compatible with 3.1. Monitoring-wise it builds on DOCS-IF31-MIB's OFDM/OFDMA model rather than replacing it.

Downstream signal quality

These come from docsIfDownstreamChannelTable and docsIfSignalQualityTable, both indexed by ifIndex - the physical or logical interface, not the modem as a whole, so a modem or CMTS with more than one active channel has one row per channel.

• docsIfDownChannelPower (1.3.6.1.2.1.10.127.1.1.1.1.6) - at the CM, the received downstream power level; at the CMTS, its own operational transmit power. In tenths of a dBmV, so a raw value of -4 displays as -0.4 dBmV. A CM's receive power drifting toward either edge of the modem's supported range - too low, or too high from an over-amplified line - is one of the earliest signs of a plant problem worth catching before it causes visible service issues.
• docsIfSigQSignalNoise (1.3.6.1.2.1.10.127.1.1.4.1.5) - at the CM, downstream Signal/Noise ratio; at the CMTS, the average upstream SNR across all modems on that channel. Also in tenths of a dB (a raw 378 is 37.8 dB). Higher is better; a downstream SNR sagging over time on an otherwise stable line is a classic early indicator of plant degradation, often before error counters climb enough to be obvious on their own.

Upstream signal: two different vantage points on the same link

Upstream is where the CM-vs-CMTS split matters most, because the two sides don't just report the same number from different angles - they measure genuinely different things, and comparing them is itself a diagnostic technique.

• docsIfCmStatusTxPower (1.3.6.1.2.1.10.127.1.2.2.1.3) - queried on the CM, the modem's own operational transmit power for its upstream channel. A modem's TX power creeping upward over weeks or months is a strong, early signal that it's compensating for increasing line loss - a loosening connector, water ingress, a degrading tap - well before that loss becomes severe enough to cause outright drops.
• docsIfCmtsCmStatusRxPower (1.3.6.1.2.1.10.127.1.3.3.1.6) - queried on the CMTS, the receive power for a specific modem's upstream signal as the headend actually measured it, not as the modem reports sending it. Comparing what a modem claims to transmit against what the CMTS actually receives for that same modem can surface a mismatch pointing at a plant issue between the two - amplifier gain drift, a bad splice - rather than a fault in the modem itself.
• docsIfCmtsCmStatusSignalNoise (1.3.6.1.2.1.10.127.1.3.3.1.13) - upstream SNR for one specific modem, as measured by the CMTS. Don't confuse this with docsIfSigQSignalNoise queried on a CMTS, which is the channel-wide average across every modem sharing that upstream - this one is per-modem, and is the more useful of the two when chasing a single subscriber's complaint rather than assessing overall plant health.

FEC codeword counters: catching degradation before it's an outage

Forward Error Correction runs continuously on every DOCSIS channel, and a healthy line still has a steady trickle of correctable errors - that's FEC doing its job, not a problem on its own. What matters is the trend and the ratio, not the raw presence of non-zero counters.

• docsIfSigQUnerroreds / docsIfSigQCorrecteds / docsIfSigQUncorrectables (.1.1.4.1.2 / .3 / .4) - codewords received without error, with correctable errors, and with uncorrectable errors, on the channel queried. Correcteds rising as a share of total codewords is the early warning; Uncorrectables represent actual data loss requiring a retransmission, and a sustained rise there is a real, user-visible problem rather than a leading indicator of one.
• docsIfCmtsCmStatusUnerroreds / Correcteds / Uncorrectables (.1.3.3.1.10 / .11 / .12) - the same three counters, but scoped to one specific modem as seen by the CMTS, rather than an entire channel's worth of traffic from every modem sharing it. This is the one to poll when a single subscriber is reporting problems on a channel that otherwise looks fine in aggregate.
• All six have 64-bit Ext-prefixed counterparts (docsIfSigQExtUnerroreds and so on) for channels busy enough that the 32-bit versions wrap inconveniently often - the same counter-wraparound consideration that applies to any high-traffic interface counter.

Registration and connectivity status

A modem's connectivity state is a single enumerated value - but the CM-side and CMTS-side versions of that enum are defined separately, with different numbering, despite the similar names. Comparing the raw integer between the two without checking each one's own enumeration is a real, easy mistake.

• docsIfCmStatusValue (1.3.6.1.2.1.10.127.1.2.2.1.1) - the modem's own view of its registration state, walking through notReady, rangingComplete, ipComplete, registrationComplete, and further states before landing on operational(12) - a fully-registered, in-service modem.
• docsIfCmtsCmStatusValue (1.3.6.1.2.1.10.127.1.3.3.1.9) - the CMTS's own view of that same modem, using a shorter, separately-numbered enum where operational is value 8, not 12. A monitoring check written against one table's numbering and pointed at the other will silently misreport modem status rather than failing loudly - worth double-checking which table an integration is actually reading from.
• docsIfCmStatusResets / docsIfCmStatusLostSyncs (.1.2.2.1.4 / .5) - how many times the modem has reset or initialized its interface, and how many times it's lost downstream sync. Both should be near-zero on a stable connection; either climbing steadily points at instability worth investigating rather than a one-off event.
• docsIfCmStatusT3Timeouts (1.3.6.1.2.1.10.127.1.2.2.1.12) - how many times the modem's ranging-response timer (T3) has expired. Repeated T3 timeouts mean the modem is struggling to complete ranging with the CMTS at all, which usually points at an upstream plant problem severe enough to threaten the connection outright, rather than the more gradual degradation the signal-quality figures above tend to catch first.

The CMTS's fleet-wide view: docsIfCmtsCmStatusTable

Everything CMTS-side covered above lives in one table, docsIfCmtsCmStatusTable (1.3.6.1.2.1.10.127.1.3.3) - and it's worth understanding as a table, not just a source for individual OIDs. It's indexed by docsIfCmtsCmStatusIndex, an index the CMTS assigns per connected modem, not by ifIndex - meaning a single walk of this table returns a row for every modem currently on that CMTS, each with its MAC address, which downstream and upstream channel it's using, its registration state, and every signal-quality and error figure covered in this guide, all in one pass. This is the practical reason a CMTS operator's monitoring setup looks different from an individual installer checking one modem: polling this single table is how a NOC dashboard showing "every modem on this CMTS and its current health" actually gets built, rather than polling each modem's own IP address one at a time. The table also carries docsIfCmtsCmStatusInetAddress/InetAddressType for each modem's IP - the older, IPv4-only docsIfCmtsCmStatusIpAddress column still exists but is deprecated in favor of these.

DOCS-IF3-MIB: monitoring bonded channels (DOCSIS 3.0)

Unlike DOCS-IF-MIB, DOCS-IF3-MIB isn't a standard, IETF-registered MIB - it lives under CableLabs' own enterprise number, at 1.3.6.1.4.1.4491.2.1.20, since DOCSIS 3.0's channel bonding was specified faster than the IETF standards process could keep up with. Its job, in the module's own words, is "primarily channel bonding, interface topology and enhanced signal quality monitoring."

• docsIf3CmStatusTable (1.3.6.1.4.1.4491.2.1.20.1.1) - explicitly described as providing "CM connectivity status information of the CM previously available in the SNMP table docsIfCmStatusTable" - the bonded-aware replacement for the whole-modem status object covered earlier. docsIf3CmStatusValue is its own enum too, and - worth flagging given the gotcha already covered above - uses yet another numbering: operational is 8 here, matching the CMTS-side enum's numbering coincidentally rather than the CM-side docsIfCmStatusValue's 12.
• docsIf3CmStatusUsTable (1.3.6.1.4.1.4491.2.1.20.1.2) - one row per bonded upstream channel, rather than the single value DOCS-IF-MIB's docsIfCmStatusTxPower gives you. docsIf3CmStatusUsTxPower is the same measurement, per channel - meaningful on a bonded modem because different upstream channels in the same bonding group can legitimately run at different transmit power levels, and a problem isolated to just one of them is easy to miss if you're only checking an aggregate or a single channel.
• docsIf3CmtsCmRegStatusTable - the CMTS-side, per-modem registration and bonding-group status table, playing the same fleet-wide role for bonded modems that docsIfCmtsCmStatusTable plays for single-channel ones. Other DOCSIS 3.0/3.1 MIBs (including DOCS-IF31-MIB below) index against this table's docsIf3CmtsCmRegStatusId rather than duplicating modem identification themselves.

The practical takeaway: on a bonded modem, a single-channel figure from DOCS-IF-MIB - like the one docsIfCmStatusTxPower instance - may not represent the modem's real condition at all if it's actually running four or eight bonded channels. DOCS-IF3-MIB's per-channel tables are what a bonded-aware monitoring setup actually needs to poll.

DOCS-IF31-MIB: monitoring OFDM and OFDMA (DOCSIS 3.1)

DOCS-IF31-MIB lives further under the same CableLabs branch, at 1.3.6.1.4.1.4491.2.1.28, and covers the genuinely new physical-layer concepts DOCSIS 3.1 introduced. Three ideas are worth understanding before the specific OIDs make sense.

Profiles, not one modulation per channel. Every device on a bonded SC-QAM channel uses the same modulation - if the channel is configured for 256-QAM, every modem on it gets 256-QAM, whether its signal quality could actually support more or less. An OFDM channel instead supports up to 16 simultaneous "profiles," each a different modulation scheme, and the CMTS assigns each modem to whichever profile its measured signal quality can actually sustain - a modem with excellent signal gets a higher-order, faster profile; a modem with marginal signal gets a lower-order, more robust one; both share the same physical channel. docsIf31CmtsCmRegStatusDsProfileIdList and docsIf31CmtsCmRegStatusUsProfileIucList, on DOCS-IF3-MIB's CMTS-side registration table, report which specific profiles a given modem is currently using.

RxMER per subcarrier - the single biggest new diagnostic capability. Older signal-quality monitoring gives one SNR figure for an entire channel. An OFDM channel has thousands of individual subcarriers (commonly around 7,600 on a full-width downstream channel), and DOCSIS 3.1 defines Receive Modulation Error Ratio (RxMER) per subcarrier - one MER reading for every single subcarrier, not an average. Plotted, this looks like a spectrum analyzer trace rather than a single number, and it can reveal exactly where in the spectrum a problem sits - a narrowband ingress source or a suck-out from a bad splitter shows up as a localized dip at specific subcarriers, invisible to a single channel-wide average that stays acceptable overall. 39 dB MER is the practical minimum for reliable 4096-QAM per the DOCSIS PHY spec - subcarriers dipping below that threshold are effectively capping what modulation the CMTS can safely assign there.

• docsIf31CmtsCmUsOfdmaChannelMeanRxMer (1.3.6.1.4.1.4491.2.1.28.1.4.1.2) - the mean RxMER across all active subcarriers on one OFDMA upstream channel, for one specific modem, as measured by the CMTS. The practical summary figure when full per-subcarrier data isn't needed.
• docsIf31CmtsCmUsOfdmaChannelStdDevRxMer (1.3.6.1.4.1.4491.2.1.28.1.4.1.3) - the standard deviation alongside it. A high standard deviation with an acceptable mean is itself a signal: it means quality is uneven across the spectrum rather than uniformly mediocre, pointing at localized interference worth chasing with full per-subcarrier data rather than a broad plant issue.
• docsIf31CmtsCmUsOfdmaChannelRxPower (1.3.6.1.4.1.4491.2.1.28.1.4.1.1) - the OFDMA equivalent of docsIfCmtsCmStatusRxPower, normalized to a 1.6 MHz reference bandwidth so it's comparable regardless of the channel's actual width.

PLC and NCP: the OFDM channel's own control channel. An OFDM downstream channel carries a narrow embedded control channel, the PHY Link Channel (PLC), which is how the CMTS tells a modem the channel's physical properties and which profiles are available at all - if the PLC itself is unreliable, the modem can't learn what profiles exist, regardless of how good the data subcarriers look. Separately, Next Codeword Pointer (NCP) fields carry the per-symbol map telling a modem where its own data actually is within each OFDM symbol.

• docsIf31CmDsOfdmChanPlcTotalCodewords / docsIf31CmDsOfdmChanPlcUnreliableCodewords (.1.9.1.13 / .14) - PLC codewords received and how many failed. A rising PLC failure rate is a more severe finding than an ordinary data-subcarrier error, since it threatens the modem's ability to use the channel at all, not just its throughput on it.
• docsIf31CmDsOfdmChanNcpTotalFields / docsIf31CmDsOfdmChanNcpFieldCrcFailures (.1.9.1.15 / .16) - NCP fields received and CRC failures among them. A modem that can't reliably read NCP effectively can't find its own data even on an otherwise healthy channel.

Codeword counters are tracked per profile, not just per channel. Since different modems on the same OFDM channel can be on different profiles with genuinely different error characteristics, a single channel-wide error count would hide that. docsIf31CmtsCmDsOfdmProfileTotalCodewords / CorrectedCodewords / UnreliableCodewords (under docsIf31CmtsCmDsOfdmProfileStatusTable) and their OFDMA-upstream counterpart docsIf31CmtsCmUsOfdmaProfileTotalCodewords and siblings (under docsIf31CmtsCmUsOfdmaProfileStatusTable) give error counts scoped to one specific modem's specific profile on one specific channel - the right level of detail for "is this modem's current profile assignment actually working," as distinct from "is this channel healthy overall."

Partial service: a new state between fully up and fully down. A bonded, multi-channel modem can lose some channels while keeping others - reduced capacity rather than an outright outage, a state prior DOCSIS versions had no real vocabulary for. docsIf31CmtsCmRegStatusPartialSvcState (1.3.6.1.4.1.4491.2.1.28.1.3.1.9) reports which direction is affected - none, partialSvcDsOnlyImpaired, partialSvcUsOnlyImpaired, or partialSvcDsAndUsImpaired - and the corresponding CurPartialSvcReasonCode objects on the per-channel OFDM/OFDMA status tables report why (commonly lostFecLock, meaning the channel stopped decoding cleanly, or secondaryChanMddTimeout). A modem reporting partial service is still online and still worth investigating - full-service figures alone won't show a degraded-but-functioning bonding group.