See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4220368

Raptor codes for reliable download delivery in wireless broadcast systems

Conference Paper · February 2006

DOI: 10.1109/CCNC.2006.1593014 · Source: IEEE Xplore

CITATIONS READS
158 396

5 authors, including:

Michael Luby Mark Watson

BitRipple Inc. Netflix
242 PUBLICATIONS   24,708 CITATIONS    18 PUBLICATIONS   1,643 CITATIONS   

SEE PROFILE SEE PROFILE

Tiago Gasiba Thomas Stockhammer

Siemens Qualcomm
36 PUBLICATIONS   661 CITATIONS    162 PUBLICATIONS   5,691 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Approximation algorithms View project

Randomized algorithms View project

All content following this page was uploaded by Wen Xu on 27 August 2018.

The user has requested enhancement of the downloaded file.

 This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE CCNC 2006 proceedings.
Raptor Codes for Reliable Download Delivery
in Wireless Broadcast Systems
Michael Luby, Mark Watson
Digital Fountain, Fremont, CA, USA
Abstract— In this work we address reliable file delivery over
mobile broadcast networks, concentrating on the Raptor codes as
specified for Multimedia Broadcast/Multicast Services (MBMS)
within 3GPP. We start by describing Luby-Transform (LT)
codes, which are the first practical fountain codes. Then, using
a natural and easy to understand linear algebra notation, we
describe Raptor codes as a powerful extension of LT codes. We
provide some insight into the Raptor code structure and some
guidelines for implementation of encoders and decoders. Finally,
some selected simulations verify the good performance of file
distribution with Raptor codes as specified in 3GPP. References
to a complete set of simulation results are also provided.
I. I NTRODUCTION
Reliable delivery of large files to many users over unreliable
and bandwidth-constraint networks is a challenging task. The
necessity to supply mobile and heterogeneous users with large
chunks of data is more desired than ever in many different
application scenarios. Examples include the delivery of mul-
timedia files to many clients, e.g. sport news, newspapers,
software updates to mobile clients such as handhelds and cars,
or the distribution of location-dependent information in highly
populated areas, e.g. airports, sports stadiums, etc.
It has been recognized that broadcast networks must be used
for the distribution of such content. Due to the high penetration
of IP-based applications, IP-based broadcast services are most
attractive. The reliable multicast transmission (RMT) group
within the IETF has defined protocols which allow to deliver
files to many users. The most popular is the File Delivery
over Unidirectional Transport (FLUTE) protocol [1] which is
particularly suited to multicast networks. To support mobile
wireless users basically two approaches are considered: 1)
traditional point-to-point cellular networks are extended with
multicast and broadcast mode. For example, IP-based bearers
in EGPRS and UMTS are used for one-to-many distribution
as specified in the Multimedia Broadcast/Multicast Service
(MBMS) [2]. 2) traditional broadcast systems such as Digital
Video Broadcast (DVB) are equipped with IP-based datacast
services [3].
For file delivery, the FLUTE protocol [1] provides capabili-
ties, among others, to map files to so-called source symbols as
well as to produce and signal additional repair symbols by the
applications of a forward error correction code (FEC). Among
the different candidate FEC codes being considered for MBMS
download delivery, Raptor codes as initially introduced by
Shokrollahi in [4] have been selected due to their extraordinary
performance. Some of the attractive Raptor code properties
1-4244-0086-4/06/$20.00 ©2006 IEEE.
Tiago Gasiba, Thomas Stockhammer, Wen Xu
Siemens AG - Mobile Phones, Munich, Germany
include linear time encoding (independent of the quantity of
repair data generated), linear time decoding (independent of
the amount of loss), very close to ideal code performance
under any channel loss conditions, and the ability to efficiently
support a large range of file sizes.
3GPP has therefore mandated the support of a decoding
algorithm of Raptor codes [2] for terminals participating in the
MBMS service. Furthermore, DVB has also decided to inte-
grate application layer FEC based on Raptor codes in their ter-
minals for IP-Datacast services [3]. Although a description of
the encoding algorithm as well as sample decoding algorithm
are available in [2, Annex B], some background information on
the specification of encoding as well as decoding algorithms
seems to be highly desirable1 . We introduce the codes along
with their coding structure. Along the way, a simple linear
algebraic notation will be gradually introduced, starting from
the well-known Luby-Transform (LT) code. Guidelines on
efficient implementation of encoding and decoding algorithms
and selected simulation results are provided. References to
detailed descriptions and simulation results in 3GPP and DVB
documents2 are provided.
II. F ILE D ELIVERY IN M OBILE B ROADCAST N ETWORKS
Multimedia delivery sessions in wireless broadcast networks
in general consist of three phases: 1) an initial phase in which
the service is announced and setup by the network and the
users discover the service; 2) a data transmission phase where
original source data as well as redundancy data is broadcast;
3) a post-delivery file repair phase where individual users are
served to complete the recovery of their file. In this work
we specifically focus on phase 2) of the delivery session.
Appropriate actions for phase 3) are for example discussed
in [6].
To deliver a file3 in a broadcast session, FLUTE provides
mechanisms to signal and map the properties of a file to
Asynchronous Layered Coding (ALC) [7] protocol such that
receivers can assign these parameters to the received files. The
file is partitioned in one or several so-called source blocks
which are futher split into k so-called source symbols, each
1 Executables for Raptor encoding and decoding are available, for distribu-
tion details see [5].
2 All 3GPP documents can be publically accessed at http://www.3gpp.org,
DVB documents can be accessed through http://www.dvb.org.
3 For simplicity we continue with the notion of a file in the following though
the ALC/LCT concept uses the more general terminology transport object.
192
of length T except for the last one, which can be smaller.
Both parameters T and k are signaled in the session setup
and are fixed for one session. For each source block, additional
repair symbols can be generated by applying an FEC, e.g. a
Raptor code. Each encoding symbol, i.e. source and repair
symbols, gets assigned a unique encoding symbol ID (ESI)
which identifies the symbol. Then each symbol individually,
or a concatenation of G consecutive encoding symbols, are
transmitted in a single ALC packet, whereby source block
number as well as ESI of the first encoding symbol in the
packet are present in the ALC header. ALC packets itself
are then encapsulated in UDP/IP packets and packet-switched
protocol stacks in 3GPP networks are used to distribute the
encoding symbols over MBMS bearers. The MBMS bearers
in UTRAN and GERAN re-use existing infrastructure and pro-
tocols are only slightly modified to support point-to-multipoint
transmission. Similarly, within DVB-h existing IP datacast
bearers are used for dissemination of files.
Receivers collect correctly received ALC packets, and with
the information available in the packet header and the file
session setup, the structure of the source block can be
recovered. If no more encoding symbols belonging to the
actual source block are expected to be received, the channel
decoder, e.g. the Raptor decoder, attempts to recover the source
block from all received data. Obviously, due to heterogeneous
receiving conditions, the amount as well as the set of received
encoding symbols differs among the receivers. Nevertheless,
with exploitation of the repair data, most receivers should be
able to recover the source block. In the unlucky case that
recovery fails, a post-delivery repair phase might still allow
to recover the source block.
III. S YSTEMATIC R APTOR C ODES FOR W IRELESS
B ROADCAST
Raptor codes have been introduced in by Shokrollahi in
2003 [4]. A fully specified version of Raptor codes has been
recently approved [8], [2, Annex B] as a mean to efficiently
disseminate data over a broadcast network. They provide
improved system reliability, while also offering a large degree
of freedom in parameter choice. Raptor is a fountain code, i.e.,
as many encoding symbols as desired can be generated by the
encoder on-the-fly from the source symbols of a source block
of data. The decoder is able to recover the source block from
any set of encoding symbols only slightly more in number than
the number of source symbols. Hence, it operates very closely
to an ideal erasure code which would require only exactly the
number of source symbols for recovery.
Raptor codes can be approached from different angles.
On the one hand they might be viewed as systematic block
code specified by a generator matrix, on the other hand the
initial idea of random fountain codes is also inherent. In the
following description we will use both descriptions to provide
as much insight as possible into structure, encoding, and
decoding of Raptor codes. The code as specified for MBMS
is a systematic fountain code producing n encoding symbols
E. The code can be viewed as the concatenation of several
193
codes as shown in Fig. 1. The most-inner code is a non-
systematic LT code with L input symbols F, which provides
the fountain property of the Raptor code. The non-systematic
Raptor code is constructed by not encoding source symbols
with the LT code, but intermediate symbols generated by some
outer high-rate block code, i.e. F are itself code symbols
generated by some code with k input symbols D. Finally,
a systematic realization of the code is obtained by applying
some pre-processing to the k source symbols C such that
the input symbols D to the non-systematic Raptor code are
obtained. The details of each processing step are explained in
the remainder of this section, details on specific parameters
can be found in [2, Annex B].
Fig. 1. Conceptual block diagram of systematic raptor encoding.
A. LT-Codes
LT codes [9] are the first practical implementation of foun-
tain codes, i.e., a channel code in which as many random and
independent encoding symbols as needed can be generated,
thus making the code rate arbitrarily close to zero. This
means that a very large number n of encoding symbols
can be produced from a finite set of source symbols L [9].
For each ESI i, the encoding symbol Ei is computed by
randomly xor’ing source symbols F. This is done by using
a random number generator that outputs γi random integers
uniformly distributed between 0 and L − 1. The set of such
numbers is henceforth referred to as Ψi . The encoding symbol
degree γi is a random number itself with a given probability
density function. For the standard LT code, the robust-soliton
distribution is used (see [9], [10]). With F representing the
symbols entering the LT encoder, and E the encoding symbols
being produced by the LT encoder, the encoding symbols Ei
for i = 1, . . . , n are generated as
Xγi
Ei = ⊕ FΨi (λ) , (1)
P
λ=1
where ⊕ represents the xor operator. Note that the decoder
has to be aware not only of encoding symbol Ei , but also of
the Ψi to make use of the received encoding symbol. This
can be accomplished by either transmitting this information
explicitly, or more elegantly, by applying the same random
generator at both entities and using the ESI i as the seed of
the random generator.
 Let us define Γi as a row vector with γi ones at positions
Ψi . Then, (1) can be written in a more compact form as Ei =
Γi · F. Furthermore, we define the generator matrix of the LT
code taking into account the consecutive4 ESI i = 1, 2, . . . , n
as: £ ¤T
GLT (1, 2, . . . , n) , ΓT1 ΓT2 · · · ΓTn . (2)
With the definition in (2), the complete encoding operation
can be expressed as
£ ¤T
E[1:n] = E1T E2T · · · EnT = GLT (1, 2, . . . , n) · F. (3)
Assume now that the decoder has available only a subset of Fig. 2. Pre-coding stage in Raptor codes.
the originally encoded symbols due to any reasons, e.g. symbol
losses on the channel. The ESIs of the received encoding
symbols are i1 , i2 , · · · , ir , where r ≤ n is the number of symbols for the subsequent inner LT code which operates
available encoding symbols E0 , {Ei1 , Ei2 , · · · , Eir }. Let in the same way as a conventional LT code and therefore
us define an equivalent generator matrix GLT (i1 , i2 , . . . , ir ) as maintains the fountain property producing n Raptor encod-
ing symbols. Note, however, that the degree distribution is
£ ¤T changed for the Raptor codes. The encoding symbols E[1:n]
GLT (i1 , i2 , . . . , ir ) , ΓTi1 ΓTi2 · · · ΓTir . (4)
are obtained as
Then it is obvious that the task of the LT-decoder is equivalent £ ¤T
to solving a system of linear equations, namely E[1:n] = GLT (1, 2, · · · , n) · DT DTP . (7)
£ ¤T
GLT (i1 , i2 , . . . , ir ) · F ≡ EiT1 EiT2 · · · EiTr . (5) (6) and (7) can conveniently be represented as:
· ¸ · ¸
Solving (5) can be done with Gaussian elimination, but the D 0
A(1, 2, · · · , n) · = , (8)
complexity of this method might be rather high. Computa- DP E[1:n]
tionally more efficient is a message passing algorithm for whereby the so-called encoding matrix A is defined as
which it has been shown in [9] that a decoding complexity · ¸
of O(L log(L)) is achieved. GP Is
A(1, 2, · · · , n) , , (9)
The performance of fountain codes can in general be mea- GLT (1, . . . , n)
sured by the inefficiency of the code describing the average and Is is the s × s identity matrix. Note that the encoding
amount of additional symbols required for successful decoding matrix A does not represent a generator matrix, but provides
when compared with an ideal code, which is about 0.1 × L a set of constraints for both, the pre-encoding step as well as
for the LT codes [9], i.e. about 10% extra symbols are needed the inner LT code. From the encoding point of view, the non-
for full recovery. The high decoding complexity for large L systematic Raptor encoder only needs to execute the additional
as well as the relatively high inefficiency has stimulated to the step of computing the pre-coding symbols. Then, a set of n
development of new fountain codes. consecutive encoding symbols E[1:n] is obtained according to
B. Non-systematic Raptor Codes (7).
Again assume now that at the decoder only a subset of the
Raptor codes [4] can be encoded and decoded in time linear
encoding symbols is available, indicated by the set of ESIs
in k and achieve a performance superior to LT codes. The
i1 , i2 , · · · , ir . Decoding of the Raptor code is performed based
new idea is the introduction of an outer pre-coding stage by
on the decoding matrix A(i1 , i2 , · · · , ir ) defined as
applying a fixed length systematic block code, whereby the · ¸
non-systematic part of the generator matrix is denoted by an GP Is
A(i1 , i2 , · · · , ir ) , . (10)
s × k-matrix GP . This code produces L = k + s pre-coding GLT (i1 , i2 , . . . , ir )
symbols with s denoting the number of parity symbols, as
Similar to the LT-decoder, the decoder for the Raptor code
shown in Fig. 2. Let D be the k input symbols entering
is again equivalent to solving a system of linear equations,
the non-systematic Raptor code. Then the pre-coding parity
namely
symbols DP are obtained as
£ ¤T
DP = GP · D. (6) A(i1 , i2 , . . . , ir ) · F ≡ 0T EiT1 EiT2 · · · EiTr , (11)
where 0 is the s × T -zero matrix, and realizing that the first k
£TheT setT ¤Tof pre-coding symbols, F, is then given by
D DP . These pre-coding symbols now serve as source pre-coding symbols correspond to the intermediate symbols:

4 Note that in general the ESIs of generated encoding symbols need neither F[1:k] = D. (12)
start from one nor must they be consecutive. However, to simplify the
presentation and because of the practical relevance we only consider encoders It is important that the outer pre-coding as well as the degree
producing consecutive ESIs. The generalization is trivial. distribution of the Raptor code is appropriately selected for

194
good code performance. Actually, for the code as specified in
MBMS [8], [2, Annex B], the pre-coding stage itself consists
of two serially concatenated codes, whereby both the outer and
inner pre-codes represent LDPC-like codes with quasi-regular
generator matrix structure (constant number of ones per row
and per column). For this Raptor code, the inefficiency is about
2 symbols and is almost independent of the number of input
symbols, k.
Furthermore, it is interesting that the decoding matrix
A(i1 , i2 , · · · , ir ) is a generalization of the encoding matrix
as defined in (9) as the indices are no more consecutive, but
only the received indices are taken into account. Therefore,
we refer in the remainder to any matrix including the code
constraints of an arbitrary ESI set i as code constraint matrix
and denote it as A(i).
C. Systematic Raptor Encoding
It has been recognized that for many applications the direct
access to the original data is beneficial, allowing receivers not
being capable to exploit the redundancy packets to still par-
ticipate in a session by only using the data packets containing
original source data. Systematic codes provide this property as
all source symbols appear in the encoding symbols. However,
as the LT code is a non-systematic code due to its construction
and the inner code of the Raptor code is also an LT-code, both
codes are initially non-systematic. In the following we briefly
show how non-systematic Raptor codes can be transformed
into a systematic code [4], [11].
As already mentioned any fountain code can be viewed as
regular linear block code being represented by a generator
matrix. It is also well-known from coding theory [12] that
the properties of a code are determined by the code words,
but not by the encoding rule, i.e. the mapping of information
words to code words. Therefore, to obtain a systematic code,
it is necessary to find an appropriate mapping of information
words to code words such that the first k code word symbols
Ei correspond to the first source symbols Ci , i.e.
∀i=1,...,k Ei ≡ Ci , (13)
where C represents the source symbol vector, and Ci the i’th
source symbol. Assume that the generator matrix of the non-
systematic Raptor code for the first k symbols is denoted by
the k × k-matrix Gk such that E[1:k] = Gk · D. Then, to
guarantee (13) it is sufficient to multiply C with the inverse of
(−1)
Gk , denoted as Gk such that the overall generator matrix
of the systematic code provides the identity matrix for the
first k positions. Obviously, this property can only be fulfilled
if Gk can be inverted, which is equivalent to the case that
the matrix has full rank k. By the definition of a systematic
index specifying some appropriate initialization for the random
generators, the Raptor code in MBMS is designed such that
for any k = 4, . . . , 8192 this property is fulfilled.
In Fig. 1 the structure of a systematic Raptor code is shown
(−1)
which can be represented by a serial concatenation of Gk ,
the pre-code GP , and the LT code GLT . Using the fact that
195
E[1:k] = C, i.e. equation (13), and equations (6) and (7), we
obtain: · ¸
I
Gk = GLT (1, . . . , k) · k . (14)
GP
Once this matrix has been computed, the source symbols can
be easily transformed into intermediate symbols D as D =
(−1)
Gk · C.
IV. I MPLEMENTATION G UIDELINES FOR S YSTEMATIC
R APTOR E NCODING AND D ECODING
A straightforward implementation would construct and in-
vert Gk and apply non-systematic Raptor encoding as shown
in Fig. 1. However, since the construction of Gk , its inverse
Gk
(−1)
and the direct computation of Gk
(−1)
· C can be very
inefficient, a different encoding procedure has been proposed
in [8]. It is suggested that encoding can be done using a
specific code constraint matrix, namely the encoding matrix
as defined in (9) for n = k, i.e. A(1, 2, · · · , n = k).
The intermediate symbols D no longer need to be explicitly
computed, and the pre-coding symbols F are then obtained
by:
£ ¤T
A(1, . . . , k) · F ≡ 0T CT . (15)
Note that, the intermediate symbols D are inherently obtained
from C as they are part of it according to (12). Also note that
the constraints in (15) is equivalent to the Raptor decoding
process as introduced in (8). The resulting symbols D now
serve as input symbols for the non-systematic Raptor code.
The code constraints in (15) are also visualized in Fig. 3,
where (13) has been taken into account.
Fig. 3. Constraints processing in Raptor code.
For practical implementations of MBMS Raptor decoding
algorithms, it is also proposed to neither use suboptimal mes-
sage passing algorithms nor standard Gaussian elimination on
the inner code. The most straightforward approach to Raptor
decoding would be to invert each step in Fig. 1. However,
this is in general not feasible as explained in the following:
Consider that the receiver has received exactly k encoding
symbols. The equivalent LT encoder generator matrix in (4)
would have dimensions k × L, and since k < L, this is an
under-determined system of equations. However, the source
symbols of the LT encoder are in general not independent,
but they have constraints imposed by the pre-code. The true
number of degrees of freedom in the pre-coding symbols is
k. It is thus possible to solve this system of equations, by
applying the code constraint matrix rather than operating on
individual generator matrices. More details will elaborated in
the following leading to a surprisingly simple implementation
of both, the Raptor encoder and the decoder.
The components of a practical encoder and decoder im-
plementation for a systematic Raptor code, integrated in a
communication environment, is shown in Fig. 4. It is immedi-
ately observed that both, the encoder and the decoder perform
two basic operations, namely 1) code constraint processing
and 2) LT-encoding. With the preliminaries explained in
section III the functions of each of each of these components
as well as the overall encoding and decoding operations will
be immediately obvious.
The LT-encoding component operates as in section III-A, in
particular it implements (1). Within the Raptor encoder, this
component operates on the pre-coding symbols F to produce
the Raptor encoding symbols E[1:n] . If the k intermediate
symbols D can be reconstructed at the receiver, the LT-encoder
is also sufficient as the last step of the Raptor decoder to obtain
the source symbols C. The connection is verified by (13).
The code constraint processor is a fundamental component
necessary to understand Raptor encoding and decoding. Based
on an arbitrary set of encoding symbols {Ei } along with the
corresponding symbol ESIs i, it allows to computes the pre-
coding symbols F according to (11), if the set of ESIs is such
that the code constraint matrix A(i) has full rank L. At the
encoder side the set of ESIs is i = {1, . . . , k} and the code
constraint processor basically solves (15). At the decoder side,
the set of ESIs i = {i1 , . . . , ir } corresponds to the received
symbols and the component is equivalent to the solution
of (11). Once more, due to the fact that the code is systematic,
supplying the source symbols as encoding symbols, along with
the ESIs from 1 to k, the block can be used at the encoder
side. The code constraint processor, which is identical to the
Fig. 4. A practical implementation of a Raptor code
solution of (11) is the key component in terms of complexity
196
in the encoding process. This operation basically requires a
matrix inversion of the code constraint matrix A(i) which
could be accomplished by a standard Gaussian elimination.
The Raptor executables described in [5] provide a straight-
forward implementation of the above. For reasonable settings
of k = 1000, T = 32 and symbol loss rate of 10%,
using an Intel XeonTM -3.2GHz, the Raptor decoder executable
described in [5] achieves decoding bit rates in the order of
12 to 19 Mbit/s, and in the order of 130 to 178 Mbit/s for
T = 512. However, due to the specific properties of the matrix,
namely the fact that its inverse is sparse, a much more efficient
implementation of the code constraint processor is possible by
applying a so-called decoding schedule as proposed in [8].
V. S ELECTED S IMULATION R ESULTS
A. 3GPP MBMS Download Delivery
During the standardization phase of MBMS, 3GPP ex-
tensively tested different alternatives to provide reliability
for download delivery in 3GPP systems. As legacy systems
should be re-used as much as possible, the introduction of
an application layer FEC, i.e., on top of IP, has been consid-
ered to be most appropriate. Only some minor modifications
in the radio access networks (RAN) have been performed.
Simulation guidelines have been proposed in 3GPP documents
S4-040348, S4-AHP247, and S4-AHP252 taking into account
specific properties such as segmentation and reassembly of
IP-packets in underlying protocols of GERAN and UTRAN
systems. The necessary overhead, i.e. the number of repair
symbols divided by the number of source symbols, strongly
depends on the loss rate p of RLC-PDUs on the underlying
radio access network.
Figure 5 shows the decoding failure probability versus
FEC overhead when transmitting a 3MByte file encoded with
Raptor code over a MBMS UTRAN bearer at different RLC-
PDU loss rates p compared to an ideal erasure code. The
recommended parameter settings according to [2] and S4-
AHP247 have been used. It is obvious from the results that
the Raptor codes perform basically as good as ideal codes for
all RLC-PDU loss rates. It is worth to note that the encoding
symbol loss rates in general is higher than the RLC-PDU loss
rates as the mapping of IP-packets to RLC-PDU is in general
not aligned. For detailed simulation results we refer to S4-
050330 and S4-050332. In addition, in document S4-05424
some additional background and justification for the selection
of Raptor codes has been provided.
B. DVB-h CBMS File Delivery
In DVB-h IP datacast protocols the content delivery protocol
specification [3] also forsees the use of Raptor codes for
file delivery applications. To verify the suitability of such
solution, simulation conditions have been agreed to verify the
performance application layer FEC, especially in comparison
to the already available Multi-Protocol Encapsulation (MPE)
FEC. Therefore, system simulations have been specified [13]
including transport stream error traces. The comparison of AL-
FEC with and without MPE-FEC has been carried. For this

Fig. 5. Failure probability vs FEC overhead when transmitting a 3MByte file
encoded with Raptor code over a MBMS UTRAN bearer at different RLC-
PDU loss rates p compared to an ideal erasure code.
purpose, numerous file size, different carrier-to-interference
ratios (C/I), Doppler frequencies and distribution cases, e.g.
simple one-off, carousel data, have been considered. Sum-
marized results can be found in [14]. For file distribution,
resource savings up to 70% are reported or equivalently,
coverage extension of up to 8dB of application layer FEC over
MPE-FEC has been reported. The acquisition time measured
in terms of necessary time slice bursts for 95% recovery
for different C/I, file sizes, Doppler frequencies, and FEC
scenarios is shown in figure 6.
From these figures we can see the expected behaviour of
MPE-FEC - providing the most improvement at the higher
C/I and high Doppler case. The further dramatic improvements
through the use of AL-FEC are then evident across a wider
range of C/I and Doppler points. Finally, we can see that
the combination of high rate MPE-FEC and AL-FEC does
not provide any benefits over AL-FEC alone and in some
cases results in worse performance. In addition, similar results
Fig. 6. Acquisition time measured in terms of necessary time slice bursts
for 95% recovery for different C/I, different file sizes, different Doppler
frequencies, and different FEC scenarios
197
View publication stats
were obtained for file carousels, with coverage improvement
of 4 dB-4.5 dB for a carousel of 50 x 20KB files. This was
achieved using a Fountain Carousel approach in which, rather
than repeating the original file data on each carousel cycle,
different AL-FEC encoded data is provided on each cycle.
This has virtually no impact on the ability of new users joining
the carousel, but dramatically improves the acquisition time in
conditions where packets are lost.
VI. C ONCLUSIONS
File distribution over wireless broadcast networks needs
additional means of reliability. With the adoption and spec-
ification of Raptor codes in 3GPP MBMS a significant step
forward has been made to enable the dissemination of files,
especially large files, to many users in parallel. The flexibility
and the relatively low encoding and decoding complexity
compared to other solutions makes the specified code not
only interesting for MBMS broadcast distribution, but also
for other applications. We hope that this work provides some
further insight in the technology of systematic Raptor codes
as specified in MBMS and will stimulate the application
of these fountain codes to other scenarios such as video
broadcasting over the Internet, peer-to-peer distribution, or any
other applications making use of fountain codes.
ACKNOWLEDGEMENTS
The authors would like to thank Amin Shokrollahi for
providing useful, constructive, and insightful comments on the
manuscript.
R EFERENCES
[1] T. Paila, M. Luby, R. Lehtonen, V. Roca, and R. Walsh, “FLUTE - File
Delivery over Unidirectional Transport,” IETF, RFC3926, Tech. Rep.,
Oct. 2004.
[2] 3GPP TS 26.346 V6.1.0, Technical Specification Group Services and
System Aspects; Multimedia Broadcast/Multicast Service; Protocols and
Codecs, June 2005.
[3] ETSI DVB TM-CBMS1167, IP Datacast over DVB-H: Content Delivery
Protocols, Sept. 2005, draft Technical Specification, http://www.dvb.org.
[4] A. Shokrollahi, “Raptor codes,” Digital Fountain, Tech. Rep. DR2003-
06-001, Jun. 2003.
[5] 3GPP TSG-SA WG4 S4-050372, p-t-p Repair with Raptor codes - Two
options, 3GPP, San Diego, CA, USA, May 2005.
[6] T. Gasiba, T. Stockhammer, and W. Xu, “Reliable download deliv-
ery with raptor codes,” Oct. 2006, submitted for International ITG-
Conference on Source and Channel Coding.
[7] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, and
J. Crowcroft, “Asynchronuous Layered Coding (ALC) Protocol Instan-
tiation,” IETF, RFC3451, Tech. Rep., Dec. 2002.
[8] 3GPP TSG-SA WG4 S4-AHP238, Specification Text for Systematic
Raptor Forward Error Correction, PSM SWG, Sophia Antipolis, France,
Apr. 2005.
[9] M. Luby, “LT codes,” in Proc. 43rd Annual IEEE Symposium on
Foundations of Computer Science, 2002.
[10] C. H. Lawrence, “Limited Randomness LT Codes.” [Online]. Available:
http://citeseer.ist.psu.edu/691419.html
[11] Shokrollahi, A., and Luby, M., “Systematic Encoding and Decoding of
Chain Reaction Codes,” U.S. Patent 6 909 383, June 21, 2005.
[12] S. Lin and D. J. Costello, Jr., Error Control Coding – Fundamentals
and Applications. Prentice-Hall, 1983.
[13] ETSI DVB TM-CBMS1361, Proposal for Simulations for Evaluation of
Application Layer FEC for File Delivery, June 2005.
[14] ETSI DVB TM-CBMS1397, Application layer Forward Error Cor-
rection - Summary of Simulation Results, Aug. 2005, source: Digital
Fountain, Mark Watson.