DOCSIS Adaptive Pre-Equalization and Impulse Noise
Part II of the Cliff-Hanger
***POST UPDATE — Updates to Mod Profile Below ***
In part I of this article I discussed adaptive pre-equalization in DOCSIS cable modems and how it can compensate for many upstream impairments such as frequency response, group delay and micro-reflections. I also left off with a cliff-hanger, which is also the title of the article; impulse noise has an impact on adaptive pre-equalization, but how and what is it? I’ll cover what impulse noise is and why and how it impacts adaptive pre-equalization. Further, in working with a colleague of mine, we have a recommended solution of how to make your DOCSIS networks more immune to this potential issue. So read on.
Impulse Noise
The definition of impulse noise as described by CableLabs:
Noise that is bursty in nature, characterized by non-overlapping transient disturbances. May be repetitive. Generally of short duration–from about 1 microsecond to a few tens of microseconds–with a fast risetime and moderately fast falltime. Seeing the time-domain picture of impulse noise above, you can get some idea of what impulse noise looks like. It is very bursty and short-lived. It is often hard to see on a spectrum analyzer unless it is set to “peak hold”. Impulse noise often comes from the electro-mechanical interference of heavy machinery and household appliances such as hair dryers. So while it can get into an RF plant near an industrial part it can also enter from every home connected to the plant. Further, because the electrical equipment must be running to generate impulse noise, it is an impairment that can come and go depending on the time of day.
Impulse Noise and Adaptive Pre-Equalization
To understand how impulse noise can impact adaptive pre-equalization in DOCSIS cable modems let’s first review how the CMTS sets the equalization parameters in the cable modem. During station maintenance, which occurs typically every 20 seconds for each cable modem, the cable modem sends a RNG-REQ message. The CMTS evaluates the signal quality of the RNG-REQ and sends back equalizer coefficients in the corresponding RNG-RSP message to the cable modem. This is the station maintenance process, also further detailed in the Station Maintenance article.
If impulse noise exists in the RF plant and a pulse happens to hit the RNG-REQ message as it is in route to the CMTS, this will result on the CMTS making bad equalizer coefficient adjustments based on the signal quality of an erroneous message. The cable modem will receive the bad equalizer coefficients, adjust its equalizer accordingly and pre-distort its transmitter to compensate for an impairment in the RF plant that does not exist. Now when the cable modem’s signal reaches the CMTS and no impulse noise is present, the CMTS may have difficulty demodulating the subscriber data if at all.
This scenario has been duplicated at one major MSO, CableLabs and in my lab. The results from the testing in my lab follows:
The upstream channels consisted of a bonding group of four 64-QAM, 3.2 MHz DOCSIS channels. No other impairments were present in the plant as this was a test environment. The upstream channels can be seen in figure below, which already had the impulse noise injected, they are so infrequent it is difficult to see.
64-QAM 3.2 MHz DOCSIS Bonded Upstream Channels
The impulse noise was generated by a piece of electronic equipment (specifically a Dewalt industrial drill) with three wraps of #18AWG wire wrapped around it. The wire was used to inductively pick up the impulse noise generated by the brushes in the AC motor of the drill. The wire was directly connected to an F-connector, passed through a 19 MHz bandpass filter with a 3 MHz passband and into a step attenuator. This allowed the impulse noise to gradually be increased just until it had minor impact on the cable modem signals being transmitted.
With adaptive pre-equalization ‘on’ all upstream channels, impulse noise is applied to upstream channel U0 centered at 19 MHz. TCP/IP traffic was generated on the upstream at a rate of approximately 25 Mbps. When the impulse noise was applied, the traffic dropped intermittently to lower levels as shown on the figure below:
In the case of the figure above, the drop was down to roughly 10 Mbps, which is more than a 50% decrease. The packet generator showed a large amount of re-transmitted packets and the CMTS was also showing high levels of un-correctable codeword errors. These are indications that some thing was wrong with the bursts of data that the cable modem was transmitting to the CMTS. For some reason the CMTS was not able to demodulate the data.
It was time to look at the cable modem’s MER (CMTS SNR) on the upstream before and after the data slow-down occurred. Below is a screen shot from the CMTS command line interface (CLI), which shows what is occurring:
Degraded Cable Modem MER (SNR) Due to Impulse Noise Impacting Pre-EQ
Just as predicted when traffic is being transmitted at 25 Mbps, the cable modem MER (SNR) is 36.12 dB. However when the traffic takes a substantial drop to 10 Mbps, the corresponding cable modem has an MER (SNR) of 26.72 dB. This is close to the edge of a CMTSs ability to demodulate a 64-QAM signal and is the result of the lower traffic rate. The cable modem will stay in this state until the next station maintenance cycle when it sends a RNG-REQ message, which is typically 20 seconds. Also note that only one cable modem was impacted (MAC address 0026.2482.9dc4). There were two other cable modems online that were not impacted because their RNG-REQ arrived at the CMTS without being hit by impulse noise – this time. On subsequent tests every cable modem was eventually impacted.
The Prevention
I had been sharing my test results with John Downey of Cisco as he was interested in the results of this testing. We discussed and tried a number of different methods to harden the DOCSIS network against this impairment. Some worked better than others, but ultimately his proposal of enabling upstream dynamic interleaving did the trick.
When upstream dynamic interleaving is set, the interleaver depth is 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.
Enabling upstream dynamic interleaving is performed in the CMTS by changing a one to a zero in a couple of lines of the modulation profile as follows.
The old modulation profile looked like this:
cable modulation-profile 224 initial 5 34 0 48 16qam scrambler 152 no-diff 98 fixed qpsk1 1 2048
cable modulation-profile 224 station 5 34 0 48 16qam scrambler 152 no-diff 98 fixed qpsk1 1 2048
cable modulation-profile 224 a-short 6 76 6 22 64qam scrambler 152 no-diff 64 shortened qpsk1 1 2048
cable modulation-profile 224 a-long 9 232 0 22 64qam scrambler 152 no-diff 64 shortened qpsk1 1 2048
cable modulation-profile 224 a-ugs 9 232 0 22 64qam scrambler 152 no-diff 64 shortened qpsk1 1 2048
The modified profile with the changes in red looked like this:
*** Update – This works better if the “Initial” and “Station” maintenance profiles have a longer preamble, so note the changes shown. The old lines are lined out with the new modulation profile updated underneath. ***
cable modulation-profile 224 initial 5 34 0 48 16qam scrambler 152 no-diff 98 fixed qpsk1 1 2048
cable modulation-profile 224 station 5 34 0 48 16qam scrambler 152 no-diff 98 fixed qpsk1 1 2048
cable modulation-profile 224 a-short 6 76 6 22 64qam scrambler 152 no-diff 384 shortened qpsk1 0 2048
cable modulation-profile 224 a-long 9 232 0 22 64qam scrambler 152 no-diff 384 shortened qpsk1 0 2048
cable modulation-profile 224 a-ugs 9 232 0 22 64qam scrambler 152 no-diff 64 shortened qpsk1 1 2048
cable modulation-profile 224 initial 5 34 0 48 16qam scrambler 152 no-diff 384 fixed qpsk1 1 2048
cable modulation-profile 224 station 5 34 0 48 16qam scrambler 152 no-diff 384 fixed qpsk1 1 2048
cable modulation-profile 224 a-short 6 76 6 22 64qam scrambler 152 no-diff 64 shortened qpsk1 0 2048
cable modulation-profile 224 a-long 9 232 0 22 64qam scrambler 152 no-diff 64 shortened qpsk1 0 2048
cable modulation-profile 224 a-ugs 9 232 0 22 64qam scrambler 152 no-diff 64 shortened qpsk1 1 2048
Note that the preamble on the a-short and a-long Initial Maintenance and Station Maintenance bursts was also increased from 98 symbols to 384 symbols. This was done to provide a longer training sequence for the CMTS to demodulate the bursts in the presence of impulse noise.
While the changes are seemingly very minor, the impact in the lab environment was substantial. I was able to increase the impulse noise levels even further without data transmission loss or MER degradation in the cable modem. It is important to note that I have only tested this configuration on a Cisco CMTS and with Motorola and Thomson DOCSIS 3.0 cable modems, so I cannot guarantee equivalent performance with other CMTS vendors.
Further, John Downey has confirmed that he was faced with a live scenario shortly after I shared the test results with him. He implemented the modulation profile configuration settings that worked in the lab and found that they had an equal improvement in resolving the customer issues as seen in the field with nearly identical impairments. So it was good to see the lab testing replicated and proven in a live field environment. Plus it resolved a complex customer issue, making the customer happy.
I do encourage everyone to use adaptive pre-equalization and then consider implementing the updated modulation profile discussed in this article. These two actions will go a long way to making your DOCSIS networks more resilient to network impairments and improving network availability.
Upcoming events can be seen under Broadband Events. Previous events can be seen under the blog.
- If you watch on youtube please hit the subscribe button!
- Let us know what you think and remember to share!
- You can find slides at the bottom of the page and some on slideshare.
- Find out about events or articles by following us on Twitter, LinkedIn or Facebook too.
Also available on iTunes, Google Podcasts, Spotify, vurbl see podcasts “get your tech on”.
Hello, very interesting articles. Just had a few questions though. In part II you mentioned “This is close to the edge of a CMTSs ability to demodulate a 64-QAM…” What is that level? ~24dB ?
Also what negative impacts would increasing the preamble from 64 symbols to 384 symbols have on the network? Being that modems would have to transmit more packets to transfer the same amount of data prior to the change, How much impact on the capacity side would this have? Although I suppose that depends how many modems are on the upstream…
Lastly, this seems very helpful for the HFC returns. Could you think of any “gotcha’s” by making the change? I’m sort of thinking about this like a short cut. “If it’s so much better, why isn’t it the way”
-Thanks! As always your articles are informative
Hi Tom,
The cliff for 64-QAM is 23 dB MER. That is where all symbols are effectively un-recoverable. The CMTS indicated that the modem was running over 3dB above that cliff. One would think this would give head room, but we could not see the complex pre-distortion that had been applied to the signal transmitted by the modem. We know that MER is not always a perfect indication of a good signal, but in this case it showed there was a 10 dB drop in the quality of the signal on a plant with nothing but impulse noise in addition to a sudden drop of traffic.
You are correct to make the assumption that increasing preamble length will have an impact on MAC overhead primarily in the time slot allocation. With a high volume of cable modems, we are probably talking well less than 1% (swag), which is quickly made up for by re-transmitting lost traffic if the change is not made. The ideal scenario is, as always, eliminate all sources of impulse noise from your network, then this all become irrelevant, but I want to be practical.
I worked closely with John Downey from Cisco on the proposed solution. I do consider him to be an authority in this area and especially on Cisco CMTSs. The results of this testing in the lab and then in the field are suggesting this should be “the way” moving forward. The reason this has not been proposed as best practices in the past was because adequate lab testing with a valid solution had not been conducted. If a better solution is identified and proposed, then this solution will be superseded as are all matters in science and engineering.
-Brady
Very informative article Brady, thank you. I do have one question; How effective would this modulation profile update be when faced with powerline-noise RFI ingress? We routinely deal with this issue. Also, what steps do you recommend to a cable operator to help locate and communicate these issues to the power company?
Thanks again for the great article(s)!
Hi Lorne,
This depends on how the ingress is getting in. If harmonics are directly coupled and modulating the DOCSIS carriers (i.e Hum mod), then I don’t believe this will have any improvement. If on the other hand, the ingress is showing up as impulse noise, it should help. Can you describe the impairment you are seeing? I have seen power-line noise show up in a number of different ways depending upon the specific conditions.
-Brady
Brady,
I take it the interleaving we are talking about here, is along the same lines of using interleaving in the downstream?
When this was tested in the lab, what affect did it have on latency and jitter? From what I’ve read, and tested, you end up having to decide on how far you wish to go with the trade off of robustness to impairments (upstream and downstream), against that of increased latency. Up till now, latency has never really figured in most MSO’s thinking, as it’s all been about the “fat pipe” to the customer.But with the likes of MW3 and BF3, especially MW3 and the P2P anti-lag mechanisim in the game, latency for cable customers (gamers) is becoming more and more of an issue.Well, this side of the pond it is!
To me, there’s no such thing as a free lunch in DOCSIS networks-for every upside, there’s a downside somewhere. Is latency a discussion point you find on your travels?
cheers
Hi Stewart,
Really good question. You are correct about downstream interleaving. In video, using long interleaver depths effectively buffers the video on the front end in order to create a very robust transport stream. This makes for a very poor DOCSIS network, however due to the long delay (latency) suffered on the downstream. Best practices usually prevent this from being an issue.
The DOCSIS 3.0 PHY defines interleaving in the upstream to ensure latency is not impacted. This is primarily due to the packet framing in the cable modem chipset, which occurs much faster than the REQ-MAP cycle of best effort service and is also built into any QoS TLV parameters.
There are three modes for Interleaving in the DOCSIS upstream. 1) no interleaving, 2) fixed-mode interleaving and 3) dynamic-mode interleaving. In fixed-mode, the interleaving depth of the last interleaving block of a packet may be a small one, resulting in a low impulse noise robustness. Dynamic mode improves upon this by ensuring that every packet has approximately the same depth to achieve nearly optimal burst impulse noise robustness. In theory, dynamic mode should stabilize self-induced jitter in the cable modem due to interleaving, but again the interleave time is inconsequential at the ASIC speed in comparison to the rest of the DOCSIS network. Further, interleave depths of fixed-mode and dynamic-mode are never as deep as those used in the downstream.
As for latency in general, it is always a point of concern when it comes to VoIP and gaming. Latency usually occurs in two cases: 1) over-utilization of the DOCSIS network (upstream or downstream) and/or 2) on the IP network due to over-utilization or routing issues (i.e. congestion).
-Brady
-Brady
It seems that you are performing these tests where multiple or bonded upstream frequencies are present. Would the change in interleaving be beneficial in single upstream frequency or non bonded upstream environments? Thanks.
Hi Jason,
You will see the same improvement if your CMTS and DOCSIS cable modems support Dynamic Interleave mode, which I believe was introduced into the DOCSIS 2.0 specification. Forgive me for not going back and confirming it in DOCSIS 1.1. But with DOCSIS 1.1 cable modems, I would recommend not using adaptive pre-equalization because cable modem manufactures widely varied in their placement of the center equalizer tap. Also, DOCSIS 1.1 cable modems only had 8 equalizer taps while DOCSIS 2.0 and 3.0 cable modems have 24 equalizer taps. This means they have 3 times the amount of equalizer sample locations over which they can make adjustments and correct for upstream impairments.
So in summary, yes to your question. A single upstream should work just as well with these recommendations as four bonded upstreams assuming they all have DOCSIS 2.0 or 3.0 cable modems and DOCSIS 2.0 or 3.0 CMTS.
-Brady
Some key points:
1. 64-QAM will break aroubnd 23 dB as Brady mentioned. Look at sh cab hop a few imes to see if corr and uncorr FEC are incrementing.
2. If uncorr FEC incrementing much faster than corr FEC, it’s probably impulse noise.
3. Higher preamble on IM and SM bursts does not add much at all to overhead since these bursts are infrequent.
4. Pre-eq not on by default because not supported with D1.0 CMs and D1.1 only support 8-tap eq while D2.0/3.0 support 24-tap equalizer, which is very necessary with 6.4 MHz ch width and running above say 33 MHz center freq.
5. Pre-eq taps can be retrieved from CM, but not from CMTS. The CMTS knows deltas and not actuals.
6. US interleave not on by default since we’re not sure how all CMs will react.
7. I believe CM built-in time offset “slop” is enough to compensate for added delay from US interleave and have not seen any changes to time offsets or map advance calculations.
Hey Brady,
Nice article! I was just curious to what you had for your “request” settings as it’s not listed above.
thanks,
Hi Carlos,
I continue to optimize modulation profiles based on field testing and work with Cisco. I find that different CMTSs and IOS versions also impact the specific parameters that I put into a mod-profile. So I would not recommend a request setting for you without having access to your CMTS.
-Brady
This is a great article !
I have one question,
In your updated version of the modulation profiles, you wrote these two lines :
cable modulation-profile 224 a-short 6 76 6 22 64qam scrambler 152 no-diff 152 shortened qpsk1 0 2048
cable modulation-profile 224 a-long 9 232 0 22 64qam scrambler 152 no-diff 152 shortened qpsk1 0 2048
Is the “152 no-diff 152” a typo?
Should it be “152 no-diff 64” ?
Hi Michael,
You are correct, it should have said 152 no-diff 64. Also check out https://volpefirm.com/intx-the-internet-television-expo-review/
Hi,
Please i would like to know what coding scheme was used to generate the 64 qam signal.
Hi Irene,
It is a Gray coding scheme for all modulation formats in DOCSIS. See https://en.wikipedia.org/wiki/Gray_code for more information on why the Gray code schema is used. In general it helps reduce error between adjacent symbols.
-Brady