exercise 5 forward error correction using reed · pdf file© festo didactic 39867-00 107...

© Festo Didactic 39867-00 107

When you have completed this exercise, you will be familiar with the concept of forward error correction (FEC). You will also be able to demonstrate how FEC can be achieved using Reed-Solomon codes.

The Discussion of this Exercise covers the following points:

Introduction to Error Control

Error Detection

Error Correction

Forward Error Correction

FEC using Reed-Solomon Codes

Reed-Solomon Error Correction in ADSL Applications

Total Data Rate versus Aggregate Data Rate

Introduction to Error Control

When data is transmitted, there may be errors in the data recovered at the receiver because noise, interference, and other perturbations present in the transmission medium impair the transmitted signal. These errors would render any data transmission system useless unless some error control is performed to manage the errors. The error control schemes used in most data transmission systems generally include the following two functions: error detection and error correction. Whatever means is used to implement error control, it always involves adding extra information to the data to be transmitted, thereby decreasing the net data rate of a transmission system. In other words, error control improves the reliability of a data transmission system at the expense of the net data rate achieved with this system.

Error Detection

The purpose of error detection is to automatically detect errors happening during data transmission. Error detection is usually performed by systematically checking the data recovered in the receiver at regular intervals to detect whether or not transmission errors occurred during the corresponding intervals.

Forward Error Correction Using Reed-Solomon Codes

Exercise 5

EXERCISE OBJECTIVE

DISCUSSION OUTLINE

DISCUSSION

Exercise 5 – Forward Error Correction Using Reed-Solomon Codes Discussion

108 © Festo Didactic 39867-00

Several methods can be used to check the integrity of the data recovered at the receiver. One of the simplest ways to implement error detection is to use parity bits. In brief, the data to be transmitted is separated into blocks of bits, the number of ones (1) in each block is counted, and a parity bit is added to each data block to indicate whether the number of bits in the block is odd or even. At the receiver, the number of ones in each data block received is counted to determine the parity bit. When the parity bit determined by the receiver differs from the parity bit included in the data block, this reveals that there is one or several bits in error in the received data block, and that some action has to be taken to manage the situation. Note that using parity bits to implement error detection has one major weakness – no error is detected when an even number of bits in a data block have errors. This is because the parity bit has the same value even if there is no error or an even number of errors in a data block.

In ADSL, CRC codes are used to implement error detection. Using CRC codes is more complex than using parity bits, but ensures highly reliable error detection. In brief, the ATU transmitter calculates a CRC code using the data transmitted during a superframe. Similarly, the ATU receiver calculates the CRC code using the data received during this superframe. Then, at the beginning of the next superframe, the ATU transmitter includes the CRC code it calculated with the data transmitted during the previous superframe. At the other end of the transmission path, the ATU receiver recovers the CRC code transmitted by the ATU transmitter and compares its value with the value of the CRC code it has calculated with the data received during the previous superframe. When both CRC values differ, this reveals that one or several errors occurred during the transmission of this superframe. The previous exercise of this manual covers error detection using CRC codes in detail.

Error Correction

Error detection reveals when errors occur during a data transmission. However, it does not allow these errors to be corrected unless an error correction function is added to the error control scheme.

One simple way of providing an error control scheme with error correction is to use an Automatic Repeat Request (ARQ) function in conjunction with an error detection function. In brief, the transmitter separates the data to be transmitted into blocks (e.g., superframes) and adds error detection information to each block before transmission. At the other end of the transmission path, the receiver uses the error detection information included in each data block received to determine whether or not transmission errors occurred in a block. If so, the receiver requests (via a return communication channel) the transmitter to resend the corrupted data block until it is received without any error.

Error correction using the error detection and ARQ functions together is efficient as long as data blocks are received with errors only occasionally. When noise and interference increase in the data transmission path, more and more data blocks are received with errors. This increases the number of requests to resend a data block, thereby rapidly decreasing the effective data transmission rate. At a certain point, the effective data transmission rate becomes so low that this means of implementing error correction is ineffective. In this case, one must resort to other techniques, such as forward error correction (FEC) and data interleaving (this technique is covered in the next exercise of this manual), to ensure reliable data transmission.

Two types of parity can be

used: even parity or odd

parity. With even parity, the

parity bit is set to 1 when

the number of bits in a block

is odd (to make the total

number of ones in this block

an even number). Con-

versely, with odd parity, the

parity bit is set to 1 when

the number of bits in a block

is even (to make the total

number of ones in this block

an odd number).

In ADSL, error detection

with CRC codes is used but

no ARQ function is imple-

mented to ask retransmis-

sion of a data block when

errors are detected. In

place, ADSL uses FEC to

ensure reliable data trans-

mission.



Forward Error Correction

Forward error correction (FEC), also referred to as forward-acting error correction, is an advanced type of error correction function that does not require retransmission of corrupted data blocks. In brief, FEC adds extra information to the data to be transmitted. This extra information provides a certain level of data redundancy that allows errors in the data recovered at the receiver to be automatically detected and corrected (within certain limits). FEC is separated into two main categories: block-coding FEC and convolutional-coding FEC.

Block-coding FEC separates the data to be transmitted into blocks and adds extra information (data redundancy) to each block to form codewords, which are often simply referred to as codes. At the receiver, the extra information included in each codeword received is used to automatically detect and correct transmission errors that may affect the data contained in this codeword. Reed-Solomon codes are widely used to implement block-coding FEC, notably in ADSL applications. FEC using Reed-Solomon codes, as used in ADSL applications, is discussed later in this discussion.

Convolutional-coding FEC applies a convolutional encoding algorithm, working at the bit level, to the data to be transmitted. In brief, the convolutional coding converts the data to be transmitted into coded data that includes extra information (data redundancy) for error detection and correction purposes. The coded data transmitted is thus longer than the original data to be transmitted because of the extra information added. At the receiver, a decoding algorithm, also working at the bit level, recovers the original data and automatically detects and corrects errors that may have occurred during transmission. Convolutional-coding FEC can be used together with block-coding FEC in ADSL applications to obtain a powerful error control scheme. Convolutional-coding FEC, as used in ADSL applications, is discussed later in this manual.

FEC using Reed-Solomon Codes

Reed-Solomon codes can be used to encode data blocks in such a way that if certain elements (e.g. bytes) in a block are received with errors after transmission through a communication channel, it is possible to correct the errors directly in the receiver without having to request the transmitter to resend the corrupted data block. As long as a sufficient number of elements in a block are received without errors, the data redundancy provided by the Reed-Solomon codes ensures complete corrections of all errors in this block.

The number N of elements in a block of Reed-Solomon encoded data depends on the number m of bits in each element of the block, and is calculated using the following equation:

N = 2m 1

The codewords resulting

from block-coding FEC are

said to be systematic be-

cause they contain the orig-

inal data to be transmitted,

without any modification.

The coded data that results

from convolutional-coding

FEC can be either system-

atic or non-systematic. This

depends on whether or not

the original data to be

transmitted is integrally in-

cluded in the coded data.

The use of Reed-Solomon

codes to implement FEC is

commonly called Reed-

Solomon error correction.



Therefore, when 8-bit elements (bytes) are used, each Reed-Solomon encoded data block contains 255 elements. This value of N is very common in digital communications system due to the prevalence of byte-oriented computer systems. The N elements in a Reed-Solomon encoded data block are divided into K elements that are the original data itself, plus R redundant check elements that result from the Reed-Solomon code computation (i.e., the Reed-Solomon encoding). This translates into the following equation:

N = K + R

The redundant check elements included in each Reed-Solomon encoded data block contains the extra information required to automatically detect and correct errors in this block at reception. The properties of Reed-Solomon codes are such that the maximum number of erroneous elements in a data block that can be corrected is equal to half the number R of redundant check elements. For instance, when R equals 8, up to 4 erroneous elements can be corrected, regardless of the number of bits in error within these elements. This particular feature of Reed-Solomon codes makes them especially efficient in correcting errors that occur in bursts. Burst errors occurring during data transmissions generally cause several consecutive bits to be in error. This does not matter to Reed-Solomon error correction because any erroneous element counts as a single error no matter what the number of bits in error in this element.

Figure 65 illustrates Reed-Solomon error correction in the context of a byte-oriented data transmission system. At the transmitter, blocks of data to be transmitted that contain K bytes each are input to the Reed-Solomon encoder. The encoder computes R redundant check bytes for each block of data to be transmitted, and appends these check bytes to the original data to be transmitted to form a Reed-Solomon encoded data block of N bytes. At the receiver, the Reed-Solomon decoder uses the R redundant check bytes in each Reed-Solomon encoded data block to detect and correct any error that occurred during transmission. The decoder then discards the R redundant check bytes leaving only the recovered data blocks free of errors.

Figure 65. Reed-Solomon error correction.

Reed-Solomon codes are

commonly denoted as a

function of N and K. For in-

stance a (255, 223) Reed-

Solomon code is one that

works on data blocks of

255 elements, 223 of these

elements being original data

and the remaining

32 elements being redun-

dant check elements.

The higher the number R of

redundant check elements,

the greater the error-

correction capability of a

Reed-Solomon code, and

thus, the reliability of a data

transmission system.



Reed-Solomon Error Correction in ADSL Applications

Reed-Solomon error correction is used in ADSL applications to improve the reliability of data transmission. Since ADSL is a byte-oriented data transmission system, each byte in a data frame becomes an element of the Reed-Solomon encoded data blocks. In ADSL applications, Reed-Solomon error correction is performed on a data frame basis, i.e., once every data frame. This implies that each ADSL data frame contains a complete Reed-Solomon encoded data block. More specifically, each ADSL data frame contains K bytes of data to be transmitted and R redundant check bytes, for a total number N of bytes equal to K + R. Since the number N of bytes per ADSL data frame is strictly dependent on the total number of bits allocated to tones and that the number R of redundant check bytes is determined at the initialization of the DSL, it is the number K of data bytes per ADSL frame that is adjusted to meet the above requirement.

Since ADSL is a byte-oriented data transmission system, the number m of bits per elements is 8, thereby leading to Reed-Solomon encoded data blocks that should contain a number N of 255 8-bit elements (bytes). However, the number of bytes in each ADSL data frame is generally less than 255. This problem is solved within Reed-Solomon encoders and decoders by adding a certain number of data bytes containing 00h to the K bytes of data and R redundant check bytes so that N is equal to 255. This technique is often referred to as shortening because it results in shortened Reed-Solomon codes. For instance, shortened (144,128) Reed-Solomon codes are obtained when 111 bytes containing 00h are added to complete each data block.

According to ITU-T Recommendation G.992.1, the number R of redundant check bytes in ADSL applications can be set to any one of the following values: 0 (no Reed-Solomon error correction), 2, 4, 6, 8, 10, 12, 14, and 16. However, due to technical constraints, R can only be set to 0 or 2 (by turning the Reed Solomon Encoder/Decoder on and off) in our ADSL application. Therefore, the Reed-Solomon error correction in our ADSL application can correct one data byte received with errors per data frame.

Figure 66 shows an example of the data at the input and output (DP3 and DP4 respectively) of the Reed-Solomon Encoder of the ATU-R Transmitter in our ADSL application. In this example, the number N of bytes per data frame is 18. Sixteen bytes of data to be transmitted are input to the Reed-Solomon Encoder every ADSL data frame. The Reed-Solomon Encoder computes two redundant check bytes and adds them after the 16 bytes of data to be transmitted. This results in shortened (18, 16) Reed-Solomon codes.

Note that Reed-Solomon

error correction is per-

formed on a data frame ba-

sis as long as data inter-

leaving is not used. Data

interleaving is discussed

later in this manual.



Figure 66. Data at the input and output of the Reed-Solomon Encoder of the ATU-R Transmitter in our ADSL application.

Notice from Figure 66 that Reed-Solomon encoding takes place before the data to be transmitted enters the Constellation Encoder. Conversely, in the ATU receiver, Reed-Solomon decoding is performed after the Constellation Decoder has reconstituted the data contained in the received ADSL signal, as can be observed in Figure 67. Notice that the Reed-Solomon Decoder discards the redundant check bytes once it has performed the error detection and correction. This explains why the number of bytes per data frame at the Reed-Solomon Decoder output is less (2 bytes less) than that at its input.

Figure 67. Data at the input and output of the Reed-Solomon Decoder of the ATU-C Receiver in our ADSL application.

The mathematics behind Reed-Solomon error correction is quite advanced and beyond the scope of this manual. However, as with CRC calculation used for error detection in ADSL applications, a polynomial is used in the computation related to Reed-Solomon error correction. The following polynomial of degree 8 should be used according to ITU-T Recommendation G.992.1:

x8 + x4 + x3 + x2 + 1

Note that the above polynomial is identical to the one stated in ITU-T Recommendation G.992.1 for the error detection CRC calculation.

Exercise 5 – Forward Error Correction Using Reed-Solomon Codes Procedure Outline



The aggregate data rate is the data rate which results from the user data transmission and the necessary system overhead (CRC code for error detection, OAM functions, EOC channel, AOC channel, and synchronization of the bearer channels), according to ITU-T Recommendation G.992.1. Similarly, the Total Data Rate results from the user data transmission, the necessary system overhead, and the transmission of the redundant data added for FEC purposes. When no FEC is used, the Total Data Rate and the Aggregate Data Rate are equal. However, when Reed-Solomon error-correction is used, the Net Data Rate is higher than the Aggregate Data Rate, the difference being dependent on the number R of redundant check bytes added every data frame. For instance, when 4 redundant check bytes are computed every data frame, the difference between the Net Data Rate and the Aggregate Data Rate is 128 kbit/s (32 bits x 4 kbaud = 128 kbit/s). This difference doubles when both the fast data buffer and the interleaved data buffer are used at the same time because redundant check bytes are calculated for each data buffer.

The Procedure is divided into the following sections:

Equipment Setup and Connections

Reed-Solomon Encoding of the Transmitted Data

Reed-Solomon Error Correction


Equipment Setup and Connections

1. Turn on the RTM Power Supply and the RTM and make sure the RTM power LED is lit.

2. Turn on the host computer. Make sure that the system has been installed and configured as described in the Communications Technologies Training System User Guide.

3. Start the LVCT software.

In the Application Selection dialog box, choose ADSL and click OK. This begins a new session with all settings set to their default values and with all faults deactivated. The System Diagram appears showing the ATU-R Transmitter and the ATU-C Receiver.

4. Make the Default external connections shown on the System Diagram tab of the ADSL application. For details of connections to the Reconfigurable Training Module, refer to the RTM Connections tab of the software.

Reed-Solomon Encoding of the Transmitted Data

5. Turn the Scrambler off by changing the Scrambler / Descrambler setting to Off in the ADSL Settings table.

PROCEDURE OUTLINE

PROCEDURE

Exercise 5 – Forward Error Correction Using Reed-Solomon Codes Procedure


Display the block diagram of the ATU-R Transmitter by clicking the corresponding tab in the ADSL application.

Display the Bit/Tone Table of the ATU-R Transmitter. Observe that the total number of bits allocated to tones is 96. This corresponds to 12 bytes per data frame. Close the Bit/Tone Table.

Use the Pan and Zoom commands to display the portion of the ATU-R Transmitter shown in Figure 68, which includes the Reed-Solomon Encoder.

Figure 68. Portion of the ATU-R Transmitter block diagram showing the Reed-Solomon Encoder.

6. Select the Frame Step mode by clicking the Frame Step button ( ) in the ADSL application toolbar.

Double click DP2 in the ATU-R Transmitter block diagram to open the corresponding data point window. This window displays the data bytes that are extracted from the Tx Data Table every data frame.

Click the Frame Step button twice to transmit two more data frames, while observing the data displayed in the DP2 window. Notice that a string of 12 data bytes is extracted from the Tx Data Table every data frame. This corresponds to the total number of bits (96) allocated to tones.

7. Enable the Reed-Solomon error correction in the ADSL application by setting the Reed-Solomon Encoder / Decoder parameter in the ADSL Settings table to On.

b The Reed-Solomon error correction can also be enabled by clicking the ON/OFF button in the Reed-Solomon Encoder of the ATU-R Transmitter or the Reed-Solomon Decoder of the ATU-C Receiver.

Click the Frame Step button a few times to transmit a few more data frames, while observing the data displayed in the DP2 window. Notice that a string of 10 data bytes is extracted from the Tx Data Table every data frame. Briefly explain why less data bytes (2 data bytes less) are extracted from the Tx Data Table every data frame when Reed-Solomon error correction is enabled.



a Recall that no data bytes are extracted from the Tx Data Table during frame 68, and that one byte in frame 0 is dedicated to the system overhead.

8. Close the DP2 window.

Double click DP3 and DP4 in the ATU-R Transmitter block diagram to open the corresponding data point windows. The DP3 and DP4 windows display the data at the input and output of the Reed-Solomon Encoder, respectively.

Click the Frame Step button a few times to transmit a few more data frames, while observing the data displayed in the DP3 and DP4 windows. Figure 69 shows an example of data at DP3 and DP4.

Figure 69. Data at the input and output of the Reed-Solomon Encoder when the total number of bits allocated to tones is 96.



Describe the relationship between the data at the input and output of the Reed-Solomon Encoder.

What is the type of codes used at the Reed-Solomon Encoder output?

9. Click the Polynomial button in the Reed-Solomon Encoder. This opens a window that displays the polynomial used to perform the calculations related to Reed-Solomon error correction.

Is this polynomial as stated in ITU-T Recommendation G.992.1?

Yes No

Close all open Data Point windows.

Close the window that displays the polynomial used in the Reed-Solomon Encoder and Decoder.

Reed-Solomon Error Correction

10. Display the block diagram of the ATU-C Receiver by clicking the corresponding tab in the ADSL application.

Use the Pan and Zoom commands to display the portion of the ATU-C Receiver shown in Figure 70, which includes the Reed-Solomon Decoder. Notice that a green LED is lit in the Reed-Solomon Decoder. This indicates that the last data frame has been received free of errors.

Figure 70. Portion of the ATU-C Receiver block diagram showing the Reed-Solomon Decoder.



11. Double click DP8 and DP9 in the ATU-C Receiver block diagram to open the corresponding data point windows. The DP8 and DP9 windows display the data at the input and output of the Reed-Solomon Decoder, respectively.

Describe the relationship between the data at the input and output of the Reed-Solomon Decoder.

12. Click the Frame Step button once to receive one more data frame, while observing the Reed-Solomon Decoder and the data displayed in the DP8 and DP9 windows. Notice that the green LED in the Reed-Solomon Decoder remains lit to indicate that the last data frame has been received free of errors.

In the ATU-C Receiver block diagram, click the switch located just before DP8 to open the path between the Deinterleaver and the Reed-Solomon Decoder.

Note the values of the first two data bytes in the DP8 window, in the space below.

Edit the value of the first data byte in the DP8 window so that the least significant bit is inverted, thereby causing a 1-bit error in one byte of this data frame. For example, if the value of the first byte is F2h, the value should be changed to F3h as shown in Figure 71. Click the Record button in the DP8 window to record the new value of the first data byte.

Figure 71. Editing a data byte at the input of the Reed-Solomon Decoder.

Click the Frame Step button once to receive the corrupted data frame, while observing the Reed-Solomon Decoder and the data displayed in the DP8 and DP9 windows.



Describe what happens when the corrupted data frame is received.

13. Edit the value of the first data byte in the DP8 window so that it recovers its original value (value you noted previously in this exercise). Click the Record button in the DP8 window to record the value of the first data byte.

Click the Frame Step button once to receive one more data frame, while observing the Reed-Solomon Decoder and the data displayed in the DP8 and DP9 windows. Notice that the green LED in the Reed-Solomon Decoder lights up to indicate that the last data frame has been received free of errors.

Edit the value of the first data byte in the DP8 window so that the two least significant bits are inverted, thereby causing a 2-bit error in one byte of this data frame. For example, if the value of the first byte is F2h, the value should be changed to F1h. Click the Record button in the DP8 window to record the new value of the first data byte.





Edit the value of the first data byte in the DP8 window so that the four least significant bits are inverted, thereby causing a 4-bit error in one byte of this data frame. For example, if the value of the first byte is F2h, the value should be changed to FDh. Click the Record button in the DP8 window to record the new value of the first data byte.







Edit the value of the first data byte in the DP8 window so that all bits are inverted, thereby causing an 8-bit error in one byte of this data frame. For example, if the value of the first byte is F2h, the value should be changed to 0Dh. Click the Record button in the DP8 window to record the new value of the first data byte.



From what you have observed so far, does Reed-Solomon error correction seem to offer an effective protection against burst errors? Explain briefly.





Edit the value of the first data byte in the DP8 window so that the most significant bit is inverted, thereby causing a 1-bit error in this byte. Do the same for the second byte in the data frame. For example, if the values of the first two bytes are F2h and F3h, the values should be changed to 72h and 73h, respectively, as shown in Figure 72. Click the Record button in the DP8 window to record the new values of the first two data bytes.

Figure 72. Editing two data bytes at the input of the Reed-Solomon Decoder.

17. Click the Frame Step button once to receive the corrupted data frame, while observing the Reed-Solomon Decoder and the data displayed in the DP8 and DP9 windows.


Briefly explain the behavior of the Reed-Solomon Decoder that you observed in this step.

Is the error-correction capability of the Reed-Solomon Decoder as expected?

Yes No



18. Edit the values of the first two data bytes in the DP8 window so that they recover their original values (values you noted previously in this exercise). Click the Record button in the DP8 window to record the values of the first two data bytes.



19. Disable the Reed-Solomon error correction in the ADSL application.

Select the Continuous mode of operation by clicking the Continuous button ( ) in the ADSL application toolbar.

Observe the Performance Display in the ADSL application. Notice that the Net Data Rate is 32 kbit/s lower than the Aggregate Data Rate (352 kbit/s versus 384 kbit/s) because one byte per data frame is dedicated to functions other than user data transmission. Also notice that the Total Data Rate equals the Aggregate Data Rate. Briefly explain why.

20. Enable the Reed-Solomon error correction in the ADSL application while observing the Performance Display.

What is the effect on the various data rates displayed? Briefly explain why.

21. When you have finished using the system, exit the LVCT software and turn off the equipment.

Exercise 5 – Forward Error Correction Using Reed-Solomon Codes Conclusion


In this exercise, you learned that error control is used to improve the reliability of data transmission systems by detecting and correcting errors that may affect the received data. You saw that error detection can be implemented using parity bits or CRC codes. Similarly, you saw that several techniques can be used to implement error correction. You learned that adding an Automatic Repeat Request (ARQ) function to an error detection function is a simple means to implement error detection. You learned that forward error correction (FEC) is an advanced type of error correction that allows errors to be corrected directly in the receiver without having to ask the transmitter to resend data. You saw that FEC is separated into two main categories: block-coding FEC and convolutional-coding FEC. You learned how Reed-Solomon error correction, a type of block-coding FEC, operates. You observed how Reed-Solomon error correction works in an ADSL application, and saw that it is particularly efficient against burst errors.

1. What are the two main functions of the error control scheme in a data transmission system?

2. Briefly explain what forward error correction is.

3. What is the error-correction capability of forward error correction using shortened (112, 80) Reed-Solomon codes? Explain briefly.

CONCLUSION

REVIEW QUESTIONS

Exercise 5 – Forward Error Correction Using Reed-Solomon Codes Review Questions


4. Briefly explain why Reed-Solomon error correction is efficient against burst errors.

5. What is the price to pay for the improved reliability that FEC provides to a data transmission system?

exercise 5 forward error correction using reed · pdf file© festo didactic 39867-00 107...

Documents