The traditional scheme for transferring data across an erasure channel depends on continuous two-way communication.
Certain networks, such as ones used for cellular wireless broadcasting, do not have a feedback channel. Applications on these networks still require reliability. Fountain codes in general, and LT codes in particular, get around this problem by adopting an essentially one-way communication protocol.
As mentioned above, the RaptorQ code specified in IETF RFC 6330 outperforms an LT code in practice.
The encoding process begins by dividing the uncoded message into n blocks of roughly equal length. Encoded packets are then produced with the help of a pseudorandom number generator.
This process continues until the receiver signals that the message has been received and successfully decoded.
The decoding process uses the "exclusive or" operation to retrieve the encoded message.
This decoding procedure works because A ⊕ {\displaystyle \oplus } A = 0 for any bit string A. After d − 1 distinct blocks have been exclusive-ored into a packet of degree d, the original unencoded content of the unmatched block is all that remains. In symbols we have
Several variations of the encoding and decoding processes described above are possible. For instance, instead of prefixing each packet with a list of the actual message block indices {i1, i2, ..., id}, the encoder might simply send a short "key" which served as the seed for the pseudorandom number generator (PRNG) or index table used to construct the list of indices. Since the receiver equipped with the same RNG or index table can reliably recreate the "random" list of indices from this seed, the decoding process can be completed successfully. Alternatively, by combining a simple LT code of low average degree with a robust error-correcting code, a raptor code can be constructed that will outperform an optimized LT code in practice.3
There is only one parameter that can be used to optimize a straight LT code: the degree distribution function (described as a pseudorandom number generator for the degree d in the LT encoding section above). In practice the other "random" numbers (the list of indices { i1, i2, ..., id } ) are invariably taken from a uniform distribution on [0, n), where n is the number of blocks into which the message has been divided.4
Luby himself5 discussed the "ideal soliton distribution" defined by
This degree distribution theoretically minimizes the expected number of redundant code words that will be sent before the decoding process can be completed. However the ideal soliton distribution does not work well in practice because any fluctuation around the expected behavior makes it likely that at some step in the decoding process there will be no available packet of (reduced) degree 1 so decoding will fail. Furthermore, some of the original blocks will not be xor-ed into any of the transmission packets. Therefore, in practice, a modified distribution, the "robust soliton distribution", is substituted for the ideal distribution. The effect of the modification is, generally, to produce more packets of very small degree (around 1) and fewer packets of degree greater than 1, except for a spike of packets at a fairly large quantity chosen to ensure that all original blocks will be included in some packet.6
M.Luby, "LT Codes", The 43rd Annual IEEE Symposium on Foundations of Computer Science, 2002. https://ieeexplore.ieee.org/document/1181950/;jsessionid=758EBC54886BB9A881D8EDFB3E71FBF4?arnumber=1181950 ↩
The exclusive or (XOR) operation, symbolized by ⊕, has the very useful property that A ⊕ A = 0, where A is an arbitrary string of bits. /wiki/Bit ↩
Fountain codes, by D.J.C. MacKay, first published in IEEE Proc.-Commun., Vol. 152, No. 6, December 2005. http://switzernet.com/people/emin-gabrielyan/060112-capillary-references/ref/MacKay05.pdf ↩
Optimizing the Degree Distribution of LT Codes with an Importance Sampling Approach, by Esa Hyytiä, Tuomas Tirronen, and Jorma Virtamo (2006). http://www.netlab.tkk.fi/tutkimus/abi/publ/lt-resim-2006.pdf ↩