One of the easiest and more accurate ways to measure the amplitude of upstream digitally modulated signals from cable modems is to use a spectrum analyzer in zero span mode. Mark Millet and I coauthored an article about this in the December 2000 issue of Communications Technology: "Upstream Power Measurements: Watts up Doc?" (www.ct-magazine.com/archives/ct/1200/064_upstream.htm). Zero span The zero span method involves measuring the amplitude of the upstream digitally modulated signal’s preamble, which is equal to the signal’s average power. Cable modem termination system (CMTS) upstream burst receiver chips use the preamble for amplitude measurement, too. This is part of the process in which the CMTS commands modems to raise or lower their upstream transmit power as required so that the received level at the CMTS upstream port is the correct value. In a properly operating cable system, a DOCSIS CMTS can maintain the levels of all modems at the input to a given upstream port within a decibel or less of each other, unless the CMTS is configured otherwise. Problems Awhile back, I ran into a situation in which a cable operator was having trouble making zero span measurements on several upstreams. In some cases, it was difficult to see the preamble at all; sometimes it looked distorted, and at times it appeared unstable. When the spectrum analyzer’s sweep rate was changed from 80 �s to around 20 ms, the problem became apparent. There was a 3 dB to 5 dB difference among different modems connected to the same CMTS upstream port. As previously noted, when things are operating properly, the CMTS should be able to keep all levels within a decibel or less of each other. That was clearly not happening here, and it made it next to impossible to accurately measure upstream signal levels using the zero span method. The cause In this particular case, the cable operator had configured the CMTS upstream receive signal level to +8 dBmV. (The default for most CMTSs is 0 dBmV.) There’s nothing wrong with using +8 dBmV—this forces modems to transmit at higher output power, which improves the upstream carrier-to-junk ratio. As a side note, the DOCSIS Radio Frequency Interface Specification states that modems must support upstream transmit levels of +8 to +58 dBmV for quadrature phase shift keying (QPSK) and +8 to +55 dBmV for 16-QAM (quadrature amplitude modulation). Consequences OK, so what might go wrong when changing the CMTS upstream input level from the default setting to a higher value? If some modems were already at or near their maximum upstream transmit power when the CMTS was set to 0 dBmV input, then those same modems will be maxed out and unable to reach the CMTS at the desired higher input level—in this case, +8 dBmV. The CMTS can be configured to operate under this scenario, but I personally don’t like doing it. For one thing, instead of having carrier-to-noise ratios (CNRs) that are more or less the same for all modems (at the CMTS upstream port), CNR will vary among the modems! That may or may not be an issue, depending on what the minimum CNR is. Less serious, and probably more of an annoyance with regard to routine maintenance and operation, the zero span method cannot be relied upon for accurate level measurement when there is significant difference among modem levels on a given upstream. For that matter, neither can the max hold method. The latter will show the approximate amplitude of the highest level modems, but not the lower level modems. Keep in mind that all of these measurements are assumed to be at the CMTS upstream port. The major concern is if some modems are already operating at or near their maximum upstream transmit level when the CMTS is configured at the 0 dBmV default value. When the CMTS input level is changed to something like +8 dBmV, a number of modems will definitely be maxed out and have absolutely no wiggle room for additional output power adjustments. The vast majority of the time when a modem is at or near its maximum transmit power, you can figure on one or more subscriber drop problems causing excessive upstream attenuation for the affected modem. In some instances, the problem may be related to excessive upstream attenuation in the feeder, or maybe even reverse amp misalignment. But most of the time, it’s indicative of something amiss in the drop. Drop woes The usual culprits include a splitter or coupler installed backwards; an outright defective drop passive; the modem connected to the fifth two-way splitter in cascade—in the home’s crawl space, naturally; damaged drop cable or connectors; maybe a high-pass filter that is still in the line; or perhaps a bad faceplate in the tap. All of these fit into what I call the "oops!" category. Possible fixes If you’re contemplating changing the CMTS upstream level from the default setting—or maybe even forcing modems to transmit at higher levels using an external pad on the CMTS upstream port—you should first check to see if any modems are already at or near their maximum transmit power. If you identify some, it’s time for a field visit to find out why and fix the problems. More than likely you’ll uncover a number of drop issues, maybe a system alignment problem or two (regular readers know that I harp incessantly about the need to sweep align the forward and reverse), and probably make a few customers happier by sorting out related issues that had been plaguing, say, digital video or even voice quality. When the at-or-near-maximum modem transmit levels have been fixed, go ahead and tweak the CMTS configuration—or install padding on the upstream ports—to force somewhat higher levels. If it were me, I’d start with a 3 dB hike above default settings and see what happens. The improved carrier-to-junk ratio likely will benefit overall performance, but be careful that upstream levels in the field don’t get too high. You may wind up with upstream laser clipping, another unwanted headache. Ron Hranac is a technical leader, Broadband Network Engineering, for Cisco Systems and senior technology editor for Communications Technology. Reach him at firstname.lastname@example.org.
By webdesign | May 1, 2006 |