Definition

forward error correction (FEC)

What is forward error correction (FEC)?

Forward error correction (FEC) is a method for obtaining error control in data transmission in which the source (transmitter) sends redundant data and the destination (receiver) recognizes only the portion of the data that contains no apparent errors. When FEC is used in data transmissions, the receiver can detect and correct a limited number of errors. If there are too many errors, the sender must retransmit the packets that contain the errors.

FEC does not require handshaking between the source and the destination, which means that the two systems do not need to establish a connection before data can be transmitted. This makes it possible to broadcast data to multiple destinations simultaneously from a single source. In addition, FEC's ability to correct errors means that less data needs to be retransmitted, reducing bandwidth and power consumption.

Because of its error-correcting capabilities, FEC is commonly implemented when transmitting data over noisy or unreliable communication channels, making it suitable for both wired and wireless communications. For example, FEC provides an efficient solution for streaming video content or supporting cellular networks. It can also be used by modems and routers, support cable and optic communications, and facilitate one-way data transmissions.

How does forward error correction work?

In the simplest form of FEC, the transmitter sends each character multiple times to provide a safeguard against lost or corrupted data. The receiver compares the character instances and, if there are discrepancies, uses a "majority rules" system to recover the data. For example, the transmitted data might include the capital letter W, which has a binary value of 01010111. If the transmitter were to send the W byte three times, the receiver would compare the bits in each byte instance to determine which bits are accurate, as shown in Figure 1.

diagram showing how forward error correction works
Figure 1. FEC uses a

In this case, there are two errors in the data when it arrives at the receiver. The fifth bit in the second character instance is different from the other two bits in that position, and the second bit in the third instance is different from the other two in its position. For each bit position, the receiver compares the bits. If all three are the same, that value is considered the correct bit. If one value is different from the other two, the two majority values are considered the correct bit.

The exact process used for FEC-based communications varies from one system to the next. At a high level, however, they generally follow a similar approach. The transmitter uses some type of encoder to add the necessary parity data to the original data, and the receiver uses some type of decoder to extract the original data from the transmitted data while correcting errors in the process. Figure 2 provides a simplified overview of how this works.

diagram showing how forward error correction (FEC) encoding/decoding works
Figure 2: A simplified view of how FEC encoding and decoding works.

Error-coding codes used in forward error correction

The communication and storage industries use a variety of error-correcting codes when implementing FEC on their systems. Some of the more common codes include the following:

  • Bose-Chaudhuri-Hocquenghem (BCH). This is a large class of random error-correcting cyclic codes constructed from polynomial expressions. The codes are relatively easy to implement in either hardware or software as well as simple to encode and decode using algebraic methodologies.
  • Hamming. This is a common type of error-correcting code that is used for both transmitted and stored data, including data on NAND flash storage. Hamming code is a type of block code. The data is broken into blocks, and parity information is added to each block. Hamming code can detect one-bit and two-bit errors, but it can only correct one-bit errors. The code is often used when consistency is more important than transmission efficiency.
  • Low-density parity check (LDPC). This is a class of linear error-correcting block codes often used for noisy data channels. LDPC codes are considered highly efficient and are deployed for both wired and wireless communication. In fact, LDPC is now part of the DOCSIS 3.1 specification, which has helped to improve its overall performance. LDPC uses a low-density parity-check matrix to describe the code.
  • Reed-Solomon (RS). This is a popular type of error-correcting code used for a wide range of storage and communication systems, including disk players, digital TVs, cell phones, high-speed modems and communication satellites. Like Hamming code, RS code is a block code, except it is non-binary, so codewords are defined in multi-bit symbols. RS code can detect and correct multi-bit errors as well as one-bit errors.
  • Turbo. This is a class of advanced, high-performing error-correcting codes often used for long-distance optical transmission systems. Turbo code is a type of convolutional code, which means it works with bit or symbol streams of arbitrary lengths (unlike block codes). Turbo code uses two encoders on the transmitter, along with an interleaver that prepares the data for the second encoder. Likewise, the receiver uses two decoders and an interleaver to extract the data and correct errors.

These are but a few of the many types of error-correcting codes that can be used for FEC-based communications. Organizations deploying FEC should use whatever approach works best for their circumstances. However, they should keep in mind one important guideline: The transmitter and receiver must use the same FEC type and follow the same rules when encoding and decoding data. Only then can they be certain that the decoder is properly identifying and correcting errors.

See how to check for packet loss to manage call quality, and explore if Is there an alternative to error correction and detection codes.

This was last updated in August 2023

Continue Reading About forward error correction (FEC)

Dig Deeper on Mobile infrastructure