[SensorNetArch] Meeting Minutes: 9/27

[Rodrigo Fonseca]

> I think that using FEC may be good for certain situations and not for 
> others. The problem with FEC is that it expands the payload thus 
> increasing power consumption, and may not be necessary if the links 
> are of high quality. On the other hand if the links are really lossy 
> then FEC may not be sufficient to recover the long packet. I'm not 
> sure if anyone's done something like Reed-Solomon, but the computation 
> costs may also be significant.

Sukun implemented Reed Solomon code for the mica motes for our paper. 
Some interesting facts:
    *We use systematic codes, meaning that the original message is sent 
as part of the "encoded" set of packets => if no packets are lost, 
decoding is free
    *Operations are carried out either with fast XOR operations for 
additions. Multiplication is done with lookups on log and exp tables, 
and additions.
    *Encoding is done with no extra memory involved: the original 
packets are sent out, and the other redundant packets are computed on 
the fly and sent out
    *Both encoding and decoding can be performed faster than the time to 
send a packet, meaning it is practical to do it on the fly.
    *Code is available in the tinyos repository

Of course, this is not a good solution always. If the loss pattern is 
such that the average loss rate is small, but bursty, you will (i) waste 
bandwidth in the periods in which you get all packets through, and (ii) 
waste encoding effort in a burst that is longer that what the code 
allows for. In this case you loose all the data. So, erasure coding will 
only help if the networking stack below it can make the loss pattern 
amenable to FEC. Link level retransmissions and fast reaction to route 
changes are important in that regard.

Rodrigo