A Comparison of Forward Error Correction Codes in Wireless
Sensors Networks
Matt Fillette, Edward Huang, Anand Joshi, John Krier, Fahad Mirza
Georgia Institute of Technology, School of Electrical and Computer
Engineeringfillette@gatech.edu, ed.huang@gatech.edu, anandkjoshi@gatech.edu,
jkrier3@gatech.edu, fmirza@gatech.edu
Abstract
Forward Error Correction Codes (FEC) have been a
long time been staple in standard wireless
communications. The following paper examines the
feasibility of Forward Error Correction Codes in the
domain of Wireless Sensor Networks where low cost
and energy savings are prioritized. From the
collected data, even though implementing these FECs
would reduce the need for retransmission requests,
they do require more overhead in transmitting the
redundant bits. Thus the value of implementing FECs
may be very dependent on the specific application
and spacing of the sensor nodes.
1. Project Description
Energy savings is one of the primary concerns for
Wireless Sensor Networks. Sensor nodes are often at
locations that are not easily accessible and are
powered with sources that are not easily replaced.
Thus any energy savings are crucial and can be
directly converted to increasing the lifetime of the
network. One novel method to save energy in these
wireless sensor networks is to implement forward
error correction codes (FEC) in packets. FECs are a
system of error control for data transmission where
the sender provides extra redundancy to the payload
so if certain number of bits are received incorrectly,
they can be fixed without a request to retransmit the
entire packet. This project will compare the
computational complexity, error rate, and resulting
energy savings among three different FEC schemes:
(1) Reed-Solomon (2) BCH, and (3) Convolutional
code.
2. Challenges and problems encountered
Turning –off CRC
One of the most difficult problems encountered in
trying to implement Forward Error Correction (FEC)
codes was turning off the Cyclic Redundancy Check
(CRC) at the link layer.
The Kernel of TinyOS uses CRC checksum for
acceptance of packets. Thus only packets that are
entirely error-free are accepted. Packet even with just
a few bits of error is rejected and instead a
retransmission is requested. This provides a huge
problem for implementing FEC code.
If only a few bits are incorrect, FEC codes are
designed to make corrections so that a retransmission
would be avoided. Obviously if a packet with just a
few bit errors are rejected. Then that retransmission
would waste energy unnecessarily. Thus the overall
engineering tradeoff decision is to consider spending
the extra energy to transmit redundant bits and have
less retransmission requests or to save energy initially
but have more retransmissions. In order to turn off the
CRC check at the link layer, the following
modifications were made to the TinyOS Kernel code:
(Whatever you guys actually changed)
4. Implementation of solutions
Getting ‘Printf’ running from sensor nodes
Three different types of FECs are used in this project:
Convolutional Codes, BCH codes and RS codes.
Because Convolutional Codes are the most novel, a
prepackaged open source solution was not available.
Thus the convolutional codes had to be studied the
most in-depth so that the encoder could be
implemented from scratch.
Getting C-code running within NESC
Discuss problems with not getting the C code to run
within NESC, printf, flush packet?
3. System Architecture
There are two modes of operation:
Online mode
In this mode of operation, packets are transmitted by
the mote destined for the SINK, which later on stored
at the SINK for post-experiment analysis. Various
parameters such as ‘Received Signal Strength
Indicator ‘RSSI’, ’Noise floor’, and ‘Distance’ along
with the received packets are stored at the SINK for
analysis. ‘Noise floor’ is obtained by capturing the
RSSI value when there is no transmission takes place.
Various configurations of the codes are experimented
by changing configuration parameters such as input
rate, output rate, constraint-length, distance etc.
Offline mode
In this mode of operation, the received data stored on
the SINK are used to draw the conclusions about the
different configurations. ‘Bit Error Rate’ (BER) is
calculated by comparing the received packet and the
expected one. ‘Signal to Noise Ratio’ (SNR) is
reckoned by the ratio of ‘RSSI’ and ‘Noise floor’.
Later on graphs are generated using the MATLAB to
compare the efficacy of each of the scheme we
implemented.
An underlying assumption about this experiment is
that we are considering a constant payload (or packet)
length. The reason for it is that we are supposed to
compare different FECs instead of effect of packet
size on a FEC scheme itself.
4.a Convolutional Codes
Convolution codes map information bits to code bits
by convolving a sequence of information bits with
‘Generator sequences’. The encoding function
convolves the newly arrived information bits with the
previously stored bits in the state registers instead of
generating the output using new information bits
only. They are mindful of received bits in the
previous stage (or step) of time.
Convolution codes can be decoded either by ‘soft’ or
‘hard’ decoding. By using soft decision decoding,
their performance can be increased very close to the
available channel capacity. Decoding of convolution
codes is performed by using ‘Viterbi’-like decoding
algorithms, which are used to recover from burst
error patterns in the received bits.
In order to avoid burst errors or errors due to fading
channels, bit interleaving is used. Apart from the
encoding side, the actual complexity lies at the
decoding portion of the transceiver. In fact encoding
is quiet simple but decoding is complex.
Description of Convolution encoding
The structure of a convolution encoder comprises of
‘K’ memory locations (or stages) tied together to
form a linear shift register (LSR). The count of
elements in the register defined as the ‘constraint
length’ or ‘K’ of the encoder. The output of the
encoder comprises of ‘n’ bits. Each convolution
encoder is defined by a rate function which is a ratio
of input bits ‘k’ to the output bits. i.e. k/n. A
generator polynomial ‘G(x)’ is the encoding function
of the code associated with each of the output bits.
The maximum length of the generator polynomial
cannot exceed the length of the LSR. Each ‘1’ in the
‘G(x)’ represents the corresponding bit in register that
contributes towards the output of the bit with which
this ‘G(x)’ associates. There will be ‘n’ (output bits)
number of generator matrices. Modulo 2-addition is
performed to generate output bits [1]. Below is the
diagram of a convolution encoder having constraint
length of ‘3’ and output rate of ‘2’.
10101010
10
Bit
‘0’
Bit
‘1’
Bit
‘2’
Implementation
The programming language used for the
implementation of encoder is ‘C’ and MATLAB is
used for decoding. The encoder takes constraint
length, output rate, length of the packet, and packet to
be encoded as its input parameters. In return it returns
bits equivalent to ‘Len x output rate’. So, there is a
requirement of holding the input packet of size ‘Len’
and output packet of size ‘Len x output-rate’. So in
total we require memory of size ‘Len x
(1+output_rate)’ for holding input and output packet
(encoded packet) all together.
The built-in encoding function of MATLAB is used
for confirming the functionality of the encoder as
well. The encoded packets from our Cimplementation are compared with the encoded
+
Output bit ‘0’
+
Output bit
‘1’
Encoding
The convolution code can be generated by sending
information bits through a linear shift register (LSR).
The generation of code depends on the input bit (or
bits if input rate is > 1), current state of the LSR, &
generator matrix. We have implemented with the
input rate of ‘1’ because at a single node there is only
one source of information. Encoder uses different
generator polynomials depending upon selected
output rates and constraint length. Encoder is
implemented in C-language.
Decoding
The implementation of Viterbi function available in
MATLAB is used for decoding the received packet.
In order to decode the packet, the received payload is
passed to MATLAB’s decoding function, having the
encoding / decoding parameters are set prior to use.
Inputs to decoding function are the received packets
stored at the SINK from sensor.
packets generated from the MATLAB to verify the
encoder’s functionality.
Similarly, the received packets at the SINK are
processed offline using MATLAB to do decoding and
post experiment analysis. Received packets are fed to
MATLAB for decoding and comparison of received
and expected packets reckoned to give BER for that
configuration (rate, constraint length). SNR is also
calculated for contrasting the noise versus received
energy for the configured convolution code.
Parameters
Following parameters are used to test the feasibility
and efficiency of convolution codes for the sensor
network:
(i) Input bits (k)
(ii) Output bits (n)
(iii) Constraint length (K)
(iv) Bit error rate
(v) Energy consumption
The input rate is fixed to ‘1’ i.e. only one input bit is
coming at each cycle but output bits are different
depending upon the output rate. The output bits (or
rate) varied between ‘2’ to ‘3’. The constraint length
of the encoder varied between ‘3’ to ‘9’. Generator
polynomials are used from the book, ‘Digital
Communications’ by Proakis.
Results
Results inferred from the experiment shows that
convolution codes are computationally and memory
intensive. Computation complexity lies at the decoder
(or at the receiving end). If they used in a setup where
decoder is the only SINK, then this code is quite
helpful. Because SINK in most cases are powerful in
both computation and has a large amount of memory.
They give protection against burst errors, fading
channels, and security because the payload comprises
of encoded bits in contrast to ‘un-coded bits + check
bits’ in the block codes, which gives strength against
breach of information security to an extent, but it is
not the topic of interest in most of the sensor network
applications. It can be helpful where such information
security requirements exist. From the transmitted
energy perspective, each of the input bits, the transmit
energy is proportional to the output rate, for example,
for rates 2 or 3, it requires 2 or 3 bits for every other
input bit which incurs twice or thrice the transmission
energy for each transmitted bit. The energy problem
becomes more severe when packet size increases.
4.b BCH Codes
Overview
Bose-Chaudhuri-Hocquenhem (BCH) codes are a
subclass of cyclic codes that are described by their
generator polynomial g(X). These codes are wellknown in the digital communication field because
they utilize algebraic structure to make efficient
decoding algorithms such as the Berlekamp-Massey
algorithm
(463).
Encoding
Encoding with BCH codes requires the use of a
Galois Field (GF). GF (q) exists iff q=pm where ‘p’ is
prime and ‘m’ is a positive integer. A true GF
guarantees that two Galois fields of the same size can
be obtained from each other. This is a key to BCH
forward error correction. Primitive binary BCH, such
as the kind we are using, has block length n = 2m - 1
and can detect/correct‘t’ errors for t<2 m-1 and uses a
GF (2m). The generator polynomial is the lowest
degree
polynomial
over
this
GF (404).
Decoding
The decoding process can be done by any cyclic code
decoder such as the Meggit decoder, though more
efficient algorithms that exploit the BCH algebraic
structure exist (467). The process begins by finding
an error locator polynomial, whose roots will be the
locations of the errors so that they can be corrected.
Implementation
For both the implementation of encoding and
decoding of BCH codes, we utilized open-source
algorithms available on the web.
Parameters
CH codes are defined by their parameters (n,k) where
n is the number of encoded bits and k is the number
of message bits. All other parameters within the
BCH black-box such as the Galois Field order are
defined in terms of these two values. Forward Error
Correction (FEC) code strength can often be thought
of in terms of their code rate n/k. The two code rates
that we have implemented are 1/2 and 1/3.
Reed-Solomon Codes
RS codes are a subset of BCH codes known as nonbinary and are used widely in communication
systems (471). Always defined as 2^m BCH code
with (n,k) = (2^m-1, 2^m-2t-1) where m >= 3 and
1<= t <= 2^(m-1)-1 (472). RS is particularly good for
burst errors (473).