We have all heard the stories of how well DOCSIS 3.1 is working. Perhaps your system has been involved in one of these stories too. One thing is true, DOCSIS 3.1 is working really well — even better than we had anticipated. Here is why DOCSIS 3.1 is working really well — it is all about forward error correction (FEC). [For the purpose of this article we will only discuss error correction in the downstream]

Reed Solomon forward error correction (RS-FEC) has been used in all previous generations of DOCSIS. I’ve previously covered RS-FEC and how it works here (https://volpefirm.com/docsis-codeword-errors/). RS-FEC has served DOCSIS very well, but advances in silicon technology enable us to take advantage of more powerful error correction techniques now, which provide significantly better data transmission robustness.

DOCSIS 3.1 has a major update in forward error correction moving from RS-FEC to a concatenated Bose, Ray-Chaudhuri, Hocquenghem (BCH) and low-density parity check (LDPC) or for short, BCH-LDPC FEC. Try saying that 10 times really fast.

BCH is an outer encoding and LDPC is an inner encoding. This means that the CMTS encodes the data to be sent with BCH FEC first and then a second layer of protection using LDPC FEC. When the cable modem receives the data frame it has to first decode the LDPC and then the BCH. Let’s think of this as a box of chocolates, where BCH is the small foil wrapper around each individual chocolate and LDPC is the box protecting all of the chocolates inside. Together BCH and LDPC are providing two layers of protection around our data frame (the chocolates). Most importantly we just want to make sure that the chocolates are okay before we eat them, or the data frame is okay before we pass it on. For example, if something is wrong and the box (the LDPC codeword) is crushed, we would assume the chocolates inside could be damaged also. However, due to BCH the data frame could still be intact or recoverable. Once we open the box we see the BCH as the foil wrappers protecting the chocolates. If the BCH  is okay, then the chocolates are okay. If the BCH is bad, then we have bad chocolates and an uncorrectable codeword error.

Currently we are collecting field data, and technicians are seeing correctable and uncorrectable codewords coming from LDPC and BCH FEC in DOCSIS 3.1 modems or field meters. However, an interesting phenomenon has occurred where it is very common to see up to 100% correctable LDPC codeword errors and zero uncorrectable BCH codeword errors. In a pre-DOCSIS 3.1 Reed-Solomon FEC environment this would be a big concern, because having so many correctable codeword errors is usually an indicator that uncorrectable codeword errors are immediately upon us. Not so in DOCSIS 3.1. In fact, it is very common to have up to 100% correctable LDPC codeword errors with zero uncorrectable BCH codeword errors. This is because LDPC is quite good at fixing errors and we see the accumulation of errors. In the box of chocolates analogy, consider the box to be very resilient, as is LDPC.

Once the cable modem is done decoding LDPC it moves on to BCH — our wrapper on the chocolate. If the final wrapper is good, we get no uncorrectable codeword errors. If there are problems, then we get uncorrectable errors. It is the uncorrectable codeword errors that we must concern ourselves with as these are subscriber impacting. Again, let’s reinforce: in DOCSIS 3.1 it’s okay to have very high levels of correctable codeword errors as long as uncorrectable codewords are non-existent or less than 1%. Once uncorrectable codeword errors increase the CMTS should reduce the modulation order.

Real-World Data

Let’s look at some real-world data to better help illustrate these points.

To read the whole article please go to BroadBand Library