MIB Viewer

Spectrum Analyzer

Last updated September 10, 2026

A CMTS's upstream receiver is already sampling RF spectrum on every active channel - some vendors expose that capability directly over SNMP, letting a management station request a capture and read back amplitude-versus-frequency data without any separate spectrum analyzer hardware. This isn't part of the DOCSIS specification itself, so there's no shared, cross-vendor MIB for it - each CMTS vendor built their own, with genuinely different data models. This guide covers three: Cisco, Casa, and Arris. It stays at the OID and data-model level - what each object configures, what triggers a capture, and how the results come back - rather than any particular implementation of it.

All three follow the same rough shape despite their differences, and the same two SNMP operations doing the work: configure the capture (which channel, what frequency range, what resolution) and trigger it, both done with a series of SNMP SET operations against the objects below - then, once the capture has run, pull the results back with an SNMP walk (or a plain get, for a single scalar). Where they genuinely diverge is that last read - what "the results" actually look like coming back over SNMP.

Cisco: CISCO-CABLE-SPECTRUM-MIB

Cisco's spectrum objects live under CISCO-CABLE-SPECTRUM-MIB, at 1.3.6.1.4.1.9.9.114. The MIB's own description frames this as a fault-management tool as much as a diagnostic one: it exists so a CMTS can sense upstream plant impairments and let an operator correlate them with modems "flapping" on and off - a spectrum capture is often what an operator reaches for right after noticing a flap pattern, not as a routine poll. The objects below are all set with SNMP SET requests, building up one row of the request table before the sweep actually runs - there's nothing to read back until that's done.

  • ccsSpectrumRequestIfIndex (1.3.6.1.4.1.9.9.114.1.2.1.1.2) - the ifIndex of the upstream channel to capture.
  • ccsSpectrumRequestLowFreq / ccsSpectrumRequestUpperFreq (.1.2.1.1.4 / .5) - the frequency range to sweep, in KHz. The underlying type allows roughly 5,000-85,000 KHz, covering North American, European, and DOCSIS 3.0-extended upstream plans.
  • ccsSpectrumRequestResolution (1.3.6.1.4.1.9.9.114.1.2.1.1.6) - the resolution bandwidth of each measurement bin. A finer resolution gives a more detailed trace at the cost of a slower sweep.
  • ccsSpectrumRequestOperation (1.3.6.1.4.1.9.9.114.1.2.1.1.7) - controls the actual test; this is the object that starts a sweep once the rest of the row is configured.
  • ccsSpectrumRequestStatus (1.3.6.1.4.1.9.9.114.1.2.1.1.11) - a standard RowStatus column. A request is a row in this table like any RowStatus-controlled table elsewhere in SNMP: created (commonly via createAndWait, value 5) so the frequency, resolution, and interface columns can be set first, then moved to active (value 1) to commit it.

Results: ccsSpectrumDataPower (1.3.6.1.4.1.9.9.114.1.2.2.1.2) is a separate table from the request row above, and it's the pre-processed kind of result: one row per frequency bin, each row's own OID instance encoding the measured frequency (in KHz) that bin corresponds to, with the value itself being the measured power in dBmV. An SNMP walk of this table, start to finish - reading each instance's own index alongside its value - returns a complete amplitude-versus-frequency trace, with no separate decoding step needed.

Casa: CASA-SPECTRUM-MIB

Casa's spectrum objects are defined in CASA-SPECTRUM-MIB, under enterprise 20858 (Casa Systems), at 1.3.6.1.4.1.20858.10.56. The shape is close to Cisco's - a configuration row, a trigger, a results table - but with real differences in the specifics worth not assuming carry over. As with Cisco, every object below is written with an SNMP SET; nothing here is read.

  • casaSpectrumMeasurementIfIndex (1.3.6.1.4.1.20858.10.56.1.1.1.2) - the upstream channel's ifIndex, same role as Cisco's equivalent.
  • casaSpectrumMeasurementChannelWidth (1.3.6.1.4.1.20858.10.56.1.1.1.3) - the resolution setting, but encoded as a small integer code rather than a direct frequency value the way Cisco's resolution object is - the mapping from code to actual bandwidth is Casa's own and worth confirming against that specific platform's documentation rather than assumed from another vendor's convention.
  • casaSpectrumMeasurementRowStatus (1.3.6.1.4.1.20858.10.56.1.1.1.5) - the same RowStatus pattern as Cisco. One practical difference worth building into a multi-vendor tool: it's worth explicitly destroying (6) any existing row for the same index before creating a new one, rather than assuming the table is empty - a stale row left over from a previous request can otherwise block a new one from being created.

Results: casaSpectrumDataPower (1.3.6.1.4.1.20858.10.56.1.2.1.2) - the same per-bin table model as Cisco's: an SNMP walk of this table returns the whole trace at once, the same principle of "the instance index is the frequency, the value is the amplitude." The one detail worth not assuming carries over unchanged: the frequency encoded in each instance here is in Hz, not KHz - a client built against Cisco's KHz convention and pointed at a Casa CMTS without adjusting for this will plot a trace off by a factor of 1,000.

Arris: ARRIS-CMTS-FFT-MIB

Arris's is the one genuinely different architecture of the three. Its objects are defined in ARRIS-CMTS-FFT-MIB, under 1.3.6.1.4.1.4115.1.4.5.1 (Arris enterprise 4115), and rather than handing back pre-processed (frequency, amplitude) pairs as table rows, it hands back the raw FFT output as a binary blob that the client has to interpret itself. Configuring and arming a capture, same as the other two vendors, is a series of SNMP SET requests against the objects below - nothing is read until dcxFftInProgress clears.

  • dcxFftSize (1.3.6.1.4.1.4115.1.4.5.1.1.1.1.1) - the number of samples in the FFT itself (valid values are 256, 512, 1024, 2048, or 4096) - a different concept from Cisco or Casa's resolution setting, since it directly sets how many frequency bins the result will actually contain rather than a bandwidth-per-bin figure.
  • dcxFftSampleRate (1.3.6.1.4.1.4115.1.4.5.1.1.1.1.2) - selects what feeds the FFT: the raw ADC output, or the ADC output after a down-mixer and half- or quarter-band filter - which in turn determines the overall frequency span the capture covers.
  • dcxFftCentreFrequency (1.3.6.1.4.1.4115.1.4.5.1.1.1.1.3) - only meaningful when dcxFftSampleRate is set to one of the down-mixed modes; it sets the down-mixer's target frequency. Left unset (or ignored) when sampling straight off the full ADC rate, since there's no down-mixer in that path to tune.
  • dcxFftEnable / dcxFftApplyConfig (.1.1.1.1.13 / .14) - arms the FFT feature and then commits the configuration, respectively. ApplyConfig is the object that actually triggers a capture once the rest of the row - size, sample rate, and so on - is set the way it's wanted.
  • dcxFftInProgress (1.3.6.1.4.1.4115.1.4.5.1.1.1.1.15) - a read-only status flag reporting whether a capture is still running. Polling this until it clears is the reliable way to know results are actually ready, rather than assuming any fixed delay is always long enough.

Results: dcxFftPayloadTable / dcxFftPayloadData (1.3.6.1.4.1.4115.1.4.5.1.1.2) is where the architecture genuinely diverges from Cisco and Casa. Each instance of dcxFftPayloadData holds at most 256 bytes - far less than a full capture's worth of samples - so the table is indexed by ifIndex and a separate dcxFftPayloadIndex, splitting one capture's raw output across as many rows as it takes to hold it all. Reading a complete result means an SNMP walk of every payload row for that interface, concatenated in order - not a single get against one OID, and not a SET at all; this stage is pure read.

What comes back, once reassembled, is raw sample data - not amplitude-versus-frequency pairs the way Cisco and Casa's tables are. Turning it into a spectrum trace means the client has to do the work those two vendors' CMTSs already did server-side: decode the raw samples into a magnitude per sample, convert that magnitude to a dB figure, and compute which frequency each sample position actually corresponds to from dcxFftSize and dcxFftSampleRate - none of which is handed back as a ready-made pair the way ccsSpectrumDataPower or casaSpectrumDataPower's instance indexes are. That reconstruction step is the real cost of Arris's approach: more configuration knobs up front, and real signal-processing work on the client side to turn the response into something plottable, where Cisco and Casa hand back something table-shaped and ready to walk.

The shared shape, and where it actually breaks down

All three vendors follow configure-trigger-wait-read, and all three use a per-channel ifIndex as the starting point for "which upstream am I capturing." Past that, a tool built to support all three genuinely needs vendor-specific logic in two places: the units and encoding of the configuration parameters (KHz versus Hz versus a raw sample count; a resolution value versus an integer code), and - the bigger one - what "reading the results" even means. Cisco and Casa give you a table that's already frequency-indexed and ready to plot. Arris gives you a raw sample buffer that has to be walked in full, reassembled, and converted before it looks like the same kind of data at all.