Incoding theory,fountain codes (also known asrateless erasure codes) are a class oferasure codes with the property that a potentially limitlesssequence ofencoding symbols can be generated from a given set of source symbols such that the original source symbols can ideally be recovered from any subset of the encoding symbols of size equal to or only slightly larger than the number of source symbols. The termfountain orrateless refers to the fact that these codes do not exhibit a fixedcode rate.
A fountain code is optimal if the originalk source symbols can be recovered from anyk successfully received encoding symbols (i.e., excluding those that were erased). Fountain codes are known that have efficient encoding and decodingalgorithms and that allow the recovery of the originalk source symbols from anyk’ of the encoding symbols with high probability, wherek’ is just slightly larger thank.
LT codes were the first practical realization of fountain codes.Raptor codes andonline codes were subsequently introduced, and achieve linear time encoding and decodingcomplexity through a pre-coding stage of the input symbols.Triangular network coding achieve linear encoding and decoding using non-linear encoding, and decoding using the back-substitution method.
Fountain codes are flexibly applicable at a fixedcode rate, or where a fixed code rate cannot be determined a priori, and where efficient encoding and decoding of large amounts of data is required.
One example is that of adata carousel, where some large file is continuously broadcast to a set of receivers.[1] Using a fixed-rate erasure code, a receiver missing a source symbol (due to a transmission error) faces thecoupon collector's problem: it must successfully receive an encoding symbol which it does not already have. This problem becomes much more apparent when using a traditional short-length erasure code, as the file must be split into several blocks, each being separately encoded: the receiver must now collect the required number of missing encoding symbols foreach block. Using a fountain code, it suffices for a receiver to retrieveany subset of encoding symbols of size slightly larger than the set of source symbols. (In practice, the broadcast is typically scheduled for a fixed period of time by an operator based on characteristics of the network and receivers and desired delivery reliability, and thus the fountain code is used at a code rate that is determined dynamically at the time when the file is scheduled to be broadcast.)
Another application is that ofhybrid ARQ inreliable multicast scenarios: parity information that is requested by a receiver can potentially be useful forall receivers in the multicast group.
Raptor codes are the most efficient fountain codes at this time,[2] having very efficient linear time encoding and decoding algorithms, and requiring only a small constant number ofXOR operations per generated symbol for both encoding and decoding.[3]IETF RFC 5053 specifies in detail asystematic Raptor code, which has been adopted into multiple standards beyond the IETF, such as within the3GPPMBMS standard for broadcast file delivery and streaming services, theDVB-HIPDC standard for delivering IP services overDVB networks, andDVB-IPTV for delivering commercial TV services over an IP network. This code can be used with up to 8,192 source symbols in a source block, and a total of up to 65,536 encoded symbols generated for a source block. This code has an average relative reception overhead of 0.2% when applied to source blocks with 1,000 source symbols, and has a relative reception overhead of less than 2% with probability 99.9999%.[4] The relative reception overhead is defined as the extra encoding data required beyond the length of the source data to recover the original source data, measured as a percentage of the size of the source data. For example, if the relative reception overhead is 0.2%, then this means that source data of size 1 megabyte can be recovered from 1.002 megabytes of encoding data.
A more advanced Raptor code with greater flexibility and improved reception overhead, called RaptorQ, has been specified inIETF RFC 6330. The specified RaptorQ code can be used with up to 56,403 source symbols in a source block, and a total of up to 16,777,216 encoded symbols generated for a source block. This code is able to recover a source block from any set of encoded symbols equal to the number of source symbols in the source block with high probability, and in rare cases from slightly more than the number of source symbols in the source block. The RaptorQ code is an integral part of the ROUTE instantiation specified in ATSC A-331 (ATSC 3.0)
Erasure codes are used in data storage applications due to massive savings on the number of storage units for a given level of redundancy and reliability. The requirements of erasure code design for data storage, particularly for distributed storage applications, might be quite different relative to communication or data streaming scenarios. One of the requirements of coding for data storage systems is the systematic form, i.e., the original message symbols are part of the coded symbols.[citation needed]Systematic form enables reading off the message symbols without decoding from a storage unit. In addition, since the bandwidth and communication load between storage nodes can be a bottleneck, codes that allow minimum communication are very beneficial particularly when a node fails and a system reconstruction is needed to achieve the initial level of redundancy. In that respect, fountain codes are expected to allow efficient repair process in case of a failure: When a single encoded symbol is lost, it should not require too much communication and computation among other encoded symbols in order to resurrect the lost symbol. In fact, repair latency might sometimes be more important than storage space savings. Repairable fountain codes[5] are projected to address fountain code design objectives for storage systems. A detailed survey about fountain codes and their applications can be found at.[6]
A different approach to distributed storage using fountain codes has been proposed in Liquid Cloud Storage.[7][8]Liquid Cloud Storage is based on using a large erasure code such as the RaptorQ code specified inIETF RFC 6330 (which provides significantly better data protection than other systems), using a background repair process (which significantly reduces the repair bandwidth requirements compared to other systems), and using a stream data organization (which allows fast access to data even when not all encoded symbols are available).
{{cite web}}: CS1 maint: multiple names: authors list (link){{cite journal}}: CS1 maint: multiple names: authors list (link){{citation}}: CS1 maint: multiple names: authors list (link).{{citation}}: CS1 maint: multiple names: authors list (link).