Optimizing the DOCSIS Upstream

By Brady S. Volpe

Data-Over-Cable Service Interface Specifications (DOCSIS) version 3.1 offers a host of exciting possibilities and realities for cable operators. I have covered many of these topics in previous articles but the one thing that cannot be overlooked is the basics. It doesn’t matter how great these new technologies are if you do not pay attention to the foundation. It’s not any different than a house. If your foundation isn’t solid who cares if you have the best theater system in it. It can crumble under foot if the foundation is not any good.

As an industry we are fortunate to have new technologies such as DOCSIS 3.1 at our disposal to support the ever-increasing demand of subscriber traffic growth. However, many operators are still using single carrier quadrature amplitude modulation (SC-QAM) channels in the return path either due to budget constraints or just for simplicity. This means return path optimization is necessary in order to increase return speeds, keep modems online and improve subscriber quality of experience (QoE) as well as to ensure the DOCSIS 3.1 downstream is working optimally. This “back-to-basics” article covers some of the fundamentals DOCSIS experts should be putting into practice in order to ensure their upstreams are optimized.

Pre-equalization

At the top of my list is making sure that pre-equalization is enabled on every return port of your cable modem termination system (CMTS). We enable pre-equalization because it allows the CMTS and modems to overcome many upstream impairments simply by sending updates to modems so that they can predistort their radio frequency (RF) transmissions to adapt for the RF impairments. The CMTS sends correction signals to each cable modem during station maintenance in the form of a range response (RNG-RSP) message – [see section 6.4.6 of the DOCSIS 3.1 MUPLI Specification for details on station maintenance]. With pre-equalization enabled, a cable modem’s pre-equalizer can compensate for significant upstream group delay and micro-reflections in the return path.

What we believe: pre-equalization has been enabled on the CMTS and every cable modem. The reality: often times some upstream ports are overlooked and pre-eq is not enabled AND more frequently other configurations are not correctly enabled causing modems to have pre-eq disabled or improperly working.

Here are four must do items for ensuring pre-equalization is working in the upstream:

• All modems must be DOCSIS 2.0 or higher (preferably DOCSIS 3.0 or higher for optimal load balancing and channel utilization)
• Upstream must be using mixed mode TDMA/A-TDMA or preferably A-TDMA only

If the upstream is configured for TDMA then cable modems will operate in DOCSIS 1.x mode, which has limited or no support for pre-equalization in modern modems

• Config files sent to cable modems must have DOCSIS 1.1 QoS parameters enabled

Legacy DOCSIS 1.0 QoS config files are sometimes not updated to reflect DOCSIS 1.1 QoS configurations leaving the advanced features in DOCSIS 2.0, 3.0 and 3.1 modems deactivated

• Finally, ensure that pre-equalization is enabled on each upstream port of the CMTS—this can sometimes be overlooked, especially when activating new ports or adding new line cards

Upstream Modulation Profiles

The next recommended optimization that can improve upstream data throughput is a robust upstream modulation profile (mod-profile). What makes for a robust upstream mod-profile? It depends on the amount or return path ingress in the system, which in turn impacts the upstream modulation error ratio (MER). Upstream MER is often displayed as “SNR” on some CMTSs and monitoring systems, however this is really just MER and not an actual signal-to-noise ratio (SNR) measurement. It is important to understand this because MER is a much more accurate measurement of the digital information contained in an RF modulated signal once it has been demodulated back to baseband.

It is generally recommended to stick to one of three upstream modulation profiles: quadrature phase shift keying (QPSK), 16-QAM or 64-QAM. While DOCSIS provides for other modulation levels, such as 32-QAM, the tradeoff between faster data rates and higher MER requirements in going from 16-QAM to 32-QAM is simply not justified. A more valuable approach would be to double the bandwidth of the upstream DOCSIS channel, resulting in doubling the data rate.

Figure 1 provides a quick reference for each DOCSIS upstream modulation type (QPSK through 64-QAM) with its upstream bandwidth options (1.6 MHz to 6.4 MHz). Beside each bandwidth value are two columns, one for gross (or raw) throughput and one for net throughput. The gross throughput is given as this is the CMTS utilization while the net throughput is what is available to the subscribers.

Next we will see how these modulations are applied in modulation profiles.

In an upstream modulation profile, each type of transmission a modem makes can be assigned a different modulation type. Here is a sample modulation profile which is very commonly found in many systems:

The above modulation profile has three major problems, but with some minor adjustments can yield substantial improvements on the return path. These improvements will result in noticeable quality of experience to your subscribers, assuming your return path is experiencing the typical impairments most hybrid fiber/coax (HFC) networks do.

Here are the obvious problems in case you don’t see them:

1. Station maintenance (initial and station entries, the second and third rows) are set to QPSK. The CMTS uses station maintenance to bring the modem online and perform updates to the modem transmit power, frequency, timing offset and pre-equalization based on the signal quality of the station maintenance message, which is now using QPSK modulation. The CMTS also determines if the upstream should or should not stay online based on this signaling and reports MER on it. QPSK is a very robust modulation and the cable modem will stay online down to a MER of around 12 dB. The subscriber data (shown in a-short and a-long) is transmitting at 64-QAM (64-QAM). The CMTS could report, via station maintenance that the modem looks just fine due to robust QPSK, while no subscriber data is passing at 64-QAM (a modulation that requires a minimum operational 27 dB MER).
2. Cable operator provided voice traffic is sent over a-ugs at 64-QAM. Again, 64-QAM is a high order modulation which is susceptible to impairments. Voice traffic uses a real-time protocol called user datagram protocol (UDP), which has no ability to re-transmit lost voice packets. Using a high order modulation means that it is very likely your subscribers will complain about broken up voice calls or robo-voice or even dropped calls.
3. The modulations using 64-QAM are not taking advantage of dynamic interleaving. Dynamic interleaving, indicated by qpsk0 in the next to last column which is currently showing qpsk1, allows the interleaver depth to be chosen dynamically to achieve optimum burst robustness. Interleaving multiplies the effectiveness of forward error correction (FEC) by aggregating multiple codewords in a block and changing the order in which bytes are transmitted through a shuffling or interleaving process of the codeword bytes so that a burst in time does not predominantly impact a single codeword. Instead, the impact is spread among all the codewords contained in a block, thereby providing enhanced protection.

The following modulation profile fixes the three critical issues in the first modulation profile:

Problem #1 was addressed simply by changing the initial and station interval usage codes (IUCs) from QPSK to 16-QAM.

Ideally, we would like to set station maintenance to the same modulation as the user traffic (a-short and a-long), but chipset vendors have not enabled this level of support. The higher order modulation of 16-QAM does give us a much better approximation of MER than QPSK did. Further, 16-QAM requires around 18 dB MER (vs 12 dB MER for QPSK) in order for the modem to stay online. This is much closer to the 27 dB MER required for 64-QAM. While subscriber traffic could still be dropping due to low MER, our station maintenance messaging is more closely aligned with our subscriber traffic.

Problem #2 has been addressed by reducing the modulation of voice traffic (a-ugs) from 64-QAM to 16-QAM.

224 a-ugs 16qam 64 no 0x9 0xE8 0x152 0 22 yes yes 0 qpsk1 no

Now cable operator managed subscriber voice traffic will be much more resilient to upstream impairments and the MER reported by station maintenance will be identical to the voice traffic IUC. If upstream voice traffic is still being impaired this IUC’s modulation could be dropped to QPSK, but at the expense of increased latency.

Problem #3 was addressed by adding dynamic interleaving to the a-short and a-long IUCs. This is visible where qpsk1 was changed to qpsk0.

You may have noticed that I also changed the request IUC to 16-QAM. There was some debate as to whether data request messages should stay at a robust QPSK or be increased to 16-QAM; the request message is very short and occurs when a modem asks the CMTS for bandwidth to send data. The request period is contention-based, meaning that there is a short window when all modems send their request message. If two modems send the request message at the same time a collision occurs which causes the request messages to be lost and a contention back-off algorithm is used to try to prevent future collisions. The point of this is that by using 16-QAM the message duration is shorter, requiring less time in the contention window resulting in less contentions. Hence, by using 16-QAM for request messages, we find that the probability of the request getting through without a collision increases, resulting in increased data rates.

Bottom Line

If you are not paying attention to optimizing the technologies you currently have in use, you are not getting the biggest bang for your dollar bill (dB). As an industry we are very focused on increasing downstream speeds to support subscriber demands, especially for over-the-top video. We must keep in mind that downstream data requires a solid upstream path due to transmission control protocol (TCP) acknowledgements. Additionally, subscribers rely on a solid upstream for two-way voice and video communications whether provided by the cable operator or other over-the-top services such as Skype, FaceTime, Hangouts, etc. No matter what technology we are using we must ensure that we are paying attention to the details, which allow us to get the best performance out of the technology at hand.

---

Brady S. Volpe

brady.volpe@volpefirm.com

Brady Volpe is Founder of The Volpe Firm, Inc and Nimble This LLC. He has over 25 years of broadband cable and telecommunications industry experience specializing in RF, DOCSIS, PNM, and Internet Protocol. Mr. Volpe has been providing a wide range of troubleshooting, design solutions, services and seminars for cable operators and broadband companies specializing in DOCSIS, System Design, PNM, and Troubleshooting. He is a highly respected published speaker, both domestically and internationally. He also hosts a popular industry YouTube and Podcast – “Get Your Tech On“.  Mr. Volpe holds a BSEE and a MSEE.

---