OID for checking upstream OFDMA snr? | docsis.org

You are here

OID for checking upstream OFDMA snr?

3 posts / 0 new
Last post
OldDocsisGuy
OID for checking upstream OFDMA snr?

We are starting to implement OFDMA across our cbr-8's. We are running 9.17.06.01z1 image.
issuing the command:
sh controllers upstream-cable 0/0/0 us-channel 12 displays this towards the end of the output:

Mapped to connector 0 and receiver 100
Bind to Cable0/0/0 US2
US phy MER(SNR)_estimate for good packets - 44.0 dB <<<-----------looking for this oid
Spectrum Group is unassigned
Nominal Input Power Level 20 dBmV

I know the power level is wrong, this is our lab... the level is ok for now.

Cisco tells us to use these:

docsIf31CmtsCmUsOfdmaChannelMeanRxMer .1.3.6.1.4.1.4491.2.1.28.1.4.1.2.
docsIf31CmtsCmUsOfdmaChannelStdDevRxMer .1.3.6.1.4.1.4491.2.1.28.1.4.1.3.

which shows modem specific OFDMA info, not what we are looking for.

Sigh, I need to retire..
Old Docsis Guy

kwesibrunee
Disclaimer, I work for Casa

Disclaimer, I work for Casa

OFDMA MER is a little tricky:

The cli output is a real-time average over a short time frame (milliseconds - seconds) on received subcarriers (minislots), Cable Labs did not define a SNMP mib that displays this information. At Casa, we added it to docsIf3CmtsCmUsStatusSignalNoise with an index of the OFDMA channel, but this is not technically correct per the spec, but at least it gives you somewhere to read it via SNMP.

This number is a little deceiving though, as it only can show you MER on Signals received over that time frame. For example, in a 96 MHz (94.8 MHz usable) OFDMA channel there are 1,896 subcarriers (50 kHz spacing) if only 30% of those subcarriers are being used during the time frame the CLI command is over, you will only have RxMER for those 30% of subcarriers, though you won't know from the CLI what subcarriers this is for.

The only real way to get average RxMER across the whole channel and display it would be to use the docsPnmCmtsUsOfdmaRxMerTable values, by triggering a RxMER measurement on all the modems on the channel, upload all the files to tftp, decode all the files and get the values, then store the values in a DB and run an average over the whole set of modems for every subcarrier. Then run an average over all subcarriers in the channel to finally get a single value.

On casa we have a command show interface ofdma 12/1.0 mer which simplifies this into a single command that takes a few seconds, and breaks down the results by Minislot. But even this is not available via SNMP.

The SNMP OIDs you have are the correct ones for the modem and channel, but they are on long running averages, Cable Labs was vague when they wrote the specification, and did not specify exactly how many samples define sufficient. Also the number and frequency of the probes determines how often the running update is modified, so the running average can be a moving target.

Here is the blurb from the spec (emphasis mine)

9.4.8 Upstream Receive Modulation Error Ratio (RxMER) per Subcarrier
This item provides measurements of the upstream receive modulation error ratio (RxMER) for each subcarrier. The CMTS measures the RxMER using an upstream probe, which is not subject to symbol errors as data subcarriers would be. The probes used for RxMER measurement are typically distinct from the probes used for pre-equalization adjustment. For the purposes of this measurement, RxMER is defined as the ratio of the average power of the ideal BPSK constellation to the average error-vector power. The error vector is the difference between the equalized received probe value and the known correct probe value.
The CMTS MUST be capable of providing measurements of RxMER for all active subcarriers for any single specified user in a specified OFDMA upstream channel, using probe symbols. A sufficient number of upstream probe symbols should be used for a reliable estimate of RxMER.

Casa has defined sufficient number of upstream probe symbols to be 255. And we control how often these probes are sent and the value calculated with ofdma probe interval in minutes 1-10080.

This has a drastic effect on this meanRxMER value.

255 samples at a 1-minute interval = 255 * 1 or 255 mins or 255/60 or 4.25 hours
255 samples at a 10-minute interval = 255 * 10 or 2550 mins or 2550/60 or 42.5 Hours or 1.77 Days
255 samples at default 30-minute interval = 255 * 30 = 7650 mins or 7650/60 or 127.5 hours or 5.3125 days
255 samples at max 10080-minute interval = 255 * 10080 = 2570400 mins or 2570400/60 = 42840 hours = 1785 days = 59.5 Months = ~ 5 years

so depending on the ofdma probe interval, the meanRxMER value can be a running average over the last 4.25 hours to the last 5 years. I suspect everyone will be most interested in an interval from 1-10 mins.

One of the issues we found at Casa is, modems which cannot use the channel because of low MER are generally missed when using the real-time cli value, because if you are not looking at the realtime value exactly when a modem is trying to register/recover from partial service, you miss the low values from that modem and only see the high values for working modems transmitting during the window you are looking at. If you look at the long-time average however, you will see the values as it only records probes which occur at registration and a pre-determined probe interval, so if you have a modem with low MER it really shines on the per modem per channel average over time.

You can gather all the MeanRxMER values from all modems on an channel and average them to get a per channel over a time period value, and short of the PNM method is the only relatively simple way to do it.

You will need to find out from Cisco, what constitutes sufficient upstream probe symbols, and how often Probes are occurring to determine what length of time the running average is for.

OldDocsisGuy
Certainly a different animal!

Thanks for that information, it is a tremendous help! I've since gotten a 'DOCS-IF31-MIB for Dummies' document:
https://www.circitor.fr/Mibs/Html/D/DOCS-IF31-MIB.php
and searched for ofdma and it has yielded several excellent explanations for what I'm looking for, and even stuff I MAY be interested in once I get something concrete for the ofdma stuff.
Thanks again!

ODG

Log in or register to post comments