Performance analysis of al fec raptor code over 3 gpp embms network

IJRET: International Journal of Research in Engineering and Technology ISSN: 2319-1163
__________________________________________________________________________________________
Volume: 02 Issue: 04 | Apr-2013, Available @ http://www.ijret.org 601
PERFORMANCE ANALYSIS OF AL-FEC RAPTOR CODE OVER 3GPP
EMBMS NETWORK
Avani U Pandya1
, Sameer D Trapasiya2
, Santhi S Chinnam3
1
M.E. Research Scholar, 2
Assistant Professor, Department of Electronics & Communication Engineering,
G .H. Patel College of Engineering & Technology.,Gujarat,India,
3
Telecom Engineer, 4G RAN & Device Validation, Rancore Technologies Pvt Ltd, Mumbai, India,
avani.pandya03@gmail.com, sameertrapasiya@gmail.com, swaroop419@gmail.com
Abstract
Long Term Evolution (LTE) is the current standard for mobile networks based on Third Generation Partnership Project. LTE includes
enhanced multimedia broadcast and multicast services (MBMS), also called as Evolved multimedia broadcast and multicast services
(eMBMS) where the same content is transmitted to multiple users in one specific area. eMBMS is a new function defined in 3GPP
Release 8 specification that supports the delivery of content and streaming to group users into LTE mobile networks. In LTE an
important point of demanding multimedia services is to improve the robustness against packet losses. In this direction, in order to
support effective point-to-multipoint download and streaming delivery, 3GPP has included an Application Layer Forward Error
Correction (AL-FEC) scheme in the standard eMBMS. The standard AL-FEC system is based on systematic, fountain Raptor codes.
Raptor coding is very useful in case of packet loss during transmission as it recover all data back from insufficient data at receiver
terminal .In our work, in response to the emergence of an enhanced AL-FEC scheme, a raptor code has been implemented and
performance is evaluated and the simulation results are obtained.
Index Terms: long term evolution; multimedia broadcast multicast services; forward error correction; raptor codes
-----------------------------------------------------------------------***-----------------------------------------------------------------------
1. INTRODUCTION
Nowadays there is a significant demand for multimedia
services over wireless networks due to the explosive growth of
the multimedia internet applications and dramatic increase in
mobile wireless access. It is, therefore, foreseen that the
wireless systems will have to support applications with
increased complexity and tighter performance requirements,
such as real-time video streaming. Furthermore, it is expected
that popular content is streamed not just to a single user, but to
multiple users attempting to access the same content at the
same time. This is addressed by standardization bodies
through introduction of a point-to-multipoint service -
enhanced Multimedia Broadcast Multicast Service (eMBMS),
a resource-efficient transmission scheme targeting
simultaneous distribution of multimedia content to many user
devices within a serving area, over a single set of Core
Network and Radio resources. So, Multimedia Broadcast and
Multicast Service (MBMS) has been standardized as a key
feature in Third Generation Partnership Project(3GPP)
systems to broadcast and multicast multimedia content to
multiple mobile subscribers via MBMS radio bearer service.
MBMS is a point-to-multipoint (PTM) Standard, whose
further evolvement and enrichment attracts nowadays
widespread interest.
Long Term Evolution (LTE) has been designed to support
only packet-switched services. Long Term Evolution (LTE)
provides both the transmission mode single-cell MBMS,
MBMS services which are transmitted in a single cell and
multi-cellular evolved MBMS transmission mode, providing
synchronous MBMS transmission from multiple cells , also
known as multicast / broadcast single frequency network
mode of transmission. To transmit the same data to multiple
recipients allows network resources to be shared. MBMS
extends the existing architecture with the introduction of
3GPP MBMS bearer service and MBMS user services.
MBMS user services are constructed above the MBMS bearer
service. For the delivery of MBMS-based services, 3GPP
defines three functional layers. The first layer, called Bearers,
provides a mechanism to data transmission over IP. Bearers
based on point-to-multipoint data transmission (MBMS
bearers), which can be used in conjunction with point-to-point
transmission. The second layer is called delivery method
which offers two modes of content delivery: download method
of discrete objects and the streaming method providing
continuous media. Delivery also provides reliability with FEC.
The third layer (User Service/Application) enables
applications to the end-user and allows him to activate or
deactivate the service.
Generally an MBMS session includes the following three
phases.
1. User Service Discovery phase: MBMS services are
advertised to the end user using 2-way point-to-point TCP-IP-

__________________________________________________________________________________________
based communication or 1-way point-to-multipoint UDP-IP-
based transmission.
2. Delivery phase: Multimedia content is delivered (either
streaming or download mode) using 1-way point-to-
multipoint UDP-IP transmission.
3. Phase after delivery: A user can report on the quality of
the content received or request a repair service files (if the
download delivery method) using 2-way point-to-point TCP-
IP communication.
During the delivery, a UDP packet can be eliminated by the
physical layer, if bit errors cannot be corrected, and can be lost
due to, for example, network congestion or hardware failure.
As there is no feedback channel in the delivery phase of
eMBMS, ARQ-based protocols cannot be used as those ARQ
receivers use a feedback channel to the sender for requesting a
retransmission of lost packets.
Another approach is to use Forward Error Correction (FEC)
Codes. In order to analyze the performance of Forward Error
Correcting (FEC) algorithms, we need to define a channel
model. Binary Erasure Channel (BEC) was first introduced by
Peter Elias of MIT in 1955[2]. It has been considered as too
theoretic to draw attention, until the last few years when
Internet became popular. Binary Erasure channel is defined as
“a symbol either arrives to the destination, without any error
or is erased and never received”. Therefore, the receiver has
no idea about the bit transmitted with a certain probability p,
and this is exactly sure of the bit transmitted with a probability
1-p. According to Shannon, BEC capacity is 1-p, which means
that the size of the alphabet of 2k, where k is the number of
bits in the alphabet, no more than (1 - p) k bits/ symbols can
be communicated reliably to the binary erasure channel.
Automatic Repeat Request (ARQ) schemes have so long been
used as a classical approach to solve the reliable
communication problem [3]. In addition, any feedback from
the receiver to the sender will not increase the channel
capacity and reliable communication must be possible at this
rate. ARQ works well for point-to-point transmission and has
also been an effective tool for reliable point-to-multipoint
transmission. However, when the number of receivers
increases, ARQ reveals its limits. A major limitation is the
problem of feedback implosion that occurs when too many
receivers are transmitting to the sender. Another problem is
that, for a loss rate of data packets, and a set of receivers
experiencing losses, the probability that each data packet must
be retransmitted rapidly approaching unity as the number of
receivers becomes large. In other words, a high average
number of transmissions required per packet. However, an
excessive number of feedbacks are used in the case of erasures
the wasting of bandwidth, network overload and intolerable
delays occur.
Forward Error Correction (FEC) codes exist as Reed-Solomon
codes, which can recover the K source symbols from the
coded symbols of all K and N the total number of symbols
transmitted. However, the rate R = K/N should be determined
in accordance with the erasure probability p, before
transmission. If p changes or p is less or greater than expected,
it will cause problems at the decoder side or will result in a
lower transmission rate achievable. Another disadvantage of
fixed powerful FEC codes is the high cost of decoding and
encoding, for example, the Reed-Solomon codes have an
encoding cost of K (N-K)log2N [4].
Next is Low density parity check codes which were invented
by Gallager in the 1960s. For each destination node, the sum
of the values of its neighboring variable nodes must be zero.
They consist of sparse generator matrices with reduced costs
decoding when accompanied by Belief Propagation (BP).
Some of these codes are very close to Shannon limit.
However, they do not have a fast encoding algorithm, even if
some approaches have been proposed, often running in linear
time. The use of a code block, it is necessary to estimate the
probability p of the BEC and adjust the encoder with this
amount of redundancy.
Tornado codes have been developed for this purpose as an
extension of LDPC codes with reduced complexity of
encoding [5]. They can manage the rate adjustment, but not
yet effective especially when the channel is subject to frequent
changes.
Fountain Codes are a new class of codes designed and ideally
suited for reliable transmission of data over an erasure channel
with unknown erasure probability [6]. A fountain code has
properties similar to a water Fountain which can be thought as
an infinite supply of water drops. Anyone who wants to collect
the water drops holds a bucket under the fountain. When
enough water is collected, the bucket is removed. Similarly
with a digital source, a client gets encoded packets from one
or more servers and packages once enough are obtained, the
client can reconstruct the original file, which packets are
obtained should not matter. They are rate-less in the sense that
for a given message, the encoder can produce potentially
infinite number of output symbols. Output symbols can be bits
or more general bit sequences. However, random linear
Fountain Codes have encoding complexity of O (N2) and
decoding complexity of O (N 3) which makes them
impractical for nowadays applications.
Luby Transform (LT) codes have been proposed by Michael
Luby [7] to reduce the encoding and decoding complexity of
random linear Fountain Codes while maintaining the small
overhead. With a good choice of degree distribution, i.e. the
distributions of the edges in the Tanner graph, LT codes can
come arbitrarily close to channel capacity with certain decoder
reliability and logarithmically increasing encoding and
decoding costs. In order to reduce the complexity even more,
we can decrease the reliability of the decoder. Thus, we would
have a reduced degree distribution resulting linear time
encoding and decoding complexity. However, the decoder

__________________________________________________________________________________________
cannot decode all the input symbols with the lower degree
distribution for the same overhead constraint. Therefore,
utilizing an erasure correcting pre-code would then correct the
erasures arising from the weakened decoder. If the pre-code is
a linear time block code, like an LDPC code, Raptor Codes
provide marvelous encoding and decoding speeds while
providing near optimal performance for the BEC [8].
Raptor codes are an extension of the other part of LT codes
combined with a system of pre-coding. The design and degree
distribution pre-coding is the heart of Raptor codes. Instead,
the media data is protected using the application layer FEC
with Raptor codes. To systematically increase the reliability of
the transmission, an application layer FEC code can be used.
The rest of this paper is organized as follows: in Section II we
provide an overview of the 3GPP AL-FEC eMBMS delivery
framework and Section III presents a detailed description of
the examined AL-FEC scheme. In Section IV we present the
simulation environment and the conducted experimental
results. Finally, in Section V we draw our conclusions and we
describe some possible future steps.
2. EMBMS PROTOCOL STACK
2.1 3GPP AL-FEC eMBMS DELIVERY
The 3GPP standard multicast services, MBMS mentioned [1],
is a service of point-to-multipoint way in which data is
transmitted from a single source to a group of several mobile
terminals in an area of specific service. 3GPP defines two
delivery methods namely, downloading and streaming.
eMBMS user plane stack of these delivery methods is
illustrated in Fig. 1.
1) MBMS Streaming Delivery Protocols Stack: The purpose of
the MBMS streaming delivery method is to deliver continuous
multimedia data (i.e. speech, audio, video) over an MBMS
bearer. MBMS makes use of the most advanced multimedia
codecs such as H.264 for video applications and enhanced
Advanced Audio Coding (AAC) for audio applications. Real-
time transport protocol (RTP) is the transport protocol for
MBMS streaming delivery. RTP provides means for sending
real-time or streaming data over user datagram protocol
(UDP), the resulting UDP flows are mapped to MBMS IP
multicast bearers. Then IP packets are processed in the Packet
Data Convergence Protocol (PDCP) layer where for example
header compression might be applied. In the Radio Link
Control (RLC) the resulting PDCP- Protocol Data Units
(PDUs), generally of arbitrary length, are mapped to fixed
length RLC-PDUs. The RLC layer operates in
unacknowledged mode as feedback links on the radio access
network are not available for point-to-multipoint bearers. The
RLC layer is responsible for mapping IP packets to RLC
SDUs.Functions provided at the RLC layer are for example
segmentation and reassembly, concatenation, padding,
sequence numbering, reordering and out-of-sequence and
duplication detection. The Medium Access Control (MAC)
layer maps and multiplexes the RLC PDUs to the transport
channel and selects the transport format depending on the
instantaneous source rate. The MAC layer and physical layer
appropriately adapt the RLC-PDU to the expected
transmission conditions by applying, among others; channel
coding, power and resource assignment, and modulation. [1]
2).MBMS Download (File) Delivery Protocols Stack: MBMS
download delivery method aims to distribute discrete objects
(e.g. files) by means of a MBMS download session. Download
method uses the File deLivery over Unidirectional Transport
(FLUTE) protocol when delivering content over MBMS
bearers. FLUTE is built on top of the Asynchronous Layered
Coding (ALC) protocol instantiation. ALC combines the
Layered Coding Transport (LCT) building block and the FEC
building block to provide reliable asynchronous delivery of
content to an unlimited number of concurrent receivers from a
single sender. A detailed description of the FLUTE building
block structure can be found in [1]. Thereafter, FLUTE is
carried over UDP/IP, and is independent of the IP version and
is forwarded to the Packet Data Convergence Protocol (PDCP)
layer. The packets are then sent to the Radio Link Control
(RLC) layer. The RLC Layer functions in unacknowledged
mode. The RLC layer is responsible for mapping IP packets to
RLC SDUs. The Media Access Control (MAC) Layer adds a
16 bit header to form a PDU, which is then sent in a transport
block on the physical layer.
APPLICATIONS
Streaming Delivery
Video, Audio
Etc.
RTP Payload Format
SRTP RTP/RTCP
Download Delivery
File, Image etc.
FEC Streaming Frame work
(AL-FEC)
FLUTE (AL-FEC)
UDP
IP Multicast
PDCP
RLC (Segmentaion)
MAC
Phy-FEC Phy Layer
Resource/Power
allocation
Figure 1: eMBMS protocol stack
3. AL-FEC Scheme
In this section we provide a detailed description of the 3GPP
standardized Raptor code.
3.1 RAPTOR CODES
Raptor codes were introduced in [9]. The use of Raptor codes
in the application layer of eMBMS was introduced to 3GPP

__________________________________________________________________________________________
aiming to improve service robustness against packet losses.
Raptor codes are fountain codes, meaning that 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.
Raptor codes are one of the first known classes of fountain
codes with linear encoding and decoding time [9]. The
systematic Raptor Encoder is used to generate repair symbols
from a source block that consists of K source symbols [10].In
preparation of the encoding; a certain amount of data is
collected within a FEC source block. The data of a source
block are further divided into k source symbols of a fixed
symbol size. The decoder is able to recover the whole source
block from any set of encoding symbols only slightly more in
number than the source symbols. The Raptor code specified
for MBMS is a systematic code producing n encoding symbols
E from k < n source symbols C, so as the original source
symbols are within the stream of the transmitted symbols. This
code can be viewed as the concatenation of several codes. The
most inner code is a non-systematic Luby-Transform (LT)
code [7] with l input symbols F, which provides the fountain
property of the Raptor codes. This non-systematic Raptor code
is not constructed by encoding the source symbols with the LT
code, but by encoding the intermediate symbols generated by
some outer high-rate block code. This means that the outer
high rate block code generates the F intermediate symbols
using 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 [11]. Considering the
performance of Raptor codes the most typical comparison is
that to an ideal fountain code. An ideal fountain code can
produce from any number k of source symbols any number m
of repair symbols with the property that any combination of k
of the k+m encoding symbols is sufficient for the recovery of
the k source symbols. That is the point of the most important
differentiation between an ideal fountain code and the
standardized Raptor code. While an ideal code has zero
reception overhead i.e., the number of received symbols
needed to decode the source symbols is exactly the number of
source symbols, the Raptor code has a performance close to
that property. The performance of an AL-FEC code can be
described by the decoding failure probability of the code. The
study presented in [12] describes the decoding failure
probability of Raptor code as a function of the source block
size and the received symbols. In fact, the inefficiency of the
Raptor code can accurately be modeled by (1) [12]
1 if
( , )
0.85 0.567 ifRf n k
n k
p n k
n k

 
  (1)
In (1), pfR(n,k) denotes the decoding failure probability of the
Raptor code if the source block size is k symbols and n
encoding symbols have been received. Failure probability
decreases exponentially when the number of received
encoding symbols increases. Moreover, a crucial point for the
robustness of an AL-FEC protected delivery session is the
transmission overhead. The transmission overhead is defined
as the amount of redundant information divided by the amount
of source data and is equal to the fraction (N-K) /K in terms of
percentage. In this fraction, N denotes the number of
transmitted packets and K denotes the number of the source
packets.
1) 3GPP Raptor Encoding Process: Raptor codes [10] are
serially concatenated codes with a pre-code as the outer code
and the LT code [1] as the inner code. Pre-code itself is also a
serially concatenated code, which uses an LDPC code and a
code with dense parity (Gray code) check matrix as the outer
code and the inner code, respectively. For Raptor Encoder
source object is divided into Z>=1 number of source blocks.
Each source block has K source symbols of size T bytes each.
Each source block is encoded independently from the next
Block. The source block construction is specified in 3GPP
26.346 [1]. The systematic Raptor codes generate encoding
symbols which contain K source symbols plus repair symbols.
In this systematic Raptor code, K original input symbols are
first encoded to L=K+S+H intermediate symbols by precode.
Here, S and H are the amount of redundancy added by the
outer and the inner codes of the pre-code, respectively. And
then, we can generate any number of encoding symbols as
needed with those intermediate symbols. The intermediate
symbols are related to the source symbols by a set of source
symbol triples. The encoding process is to produce repair
symbols by bit-wise XORing specific source symbols. The
whole process is divided in following steps.
Step 1:- The first step in encoding can be performed by
generating an LxL encoding matrix, A to calculate L
intermediate symbols as [10].
GLDPC Is 0SXH
GHALF IH
GLTGLT
S
K
K S H
H
(-1)
Pre_Code Matrix
GLT(1...N)
GLT(1...K)
LT Encoder
LT Decoder
Systematic GF(2) Raptor Encoder
L
GLDPC Is 0SXH
GHALF IH
GLTGLT
S
N
K S H
H
(-1)
Pre_Code Matrix
Systematic GF(2) Raptor Decoder
Channel
L
C
CK
N
K
K
D
Figure 2: Block diagram of Raptor encoder and decoder

__________________________________________________________________________________________
C = A-1
D (2)
Where, C represents column vector of the L intermediate
symbols, D represents column vector of S+H zero symbols
followed by the K source symbols.
The precode matrix A consists of several submatrices as
shown in figure 2. In this matrix A, the top S+H rows
represent the constraints of the pre-code on C, and the bottom
K rows, each corresponding to a source symbol of D,
represent the generator matrix of the LT code. (GLDPC)S x K
and (HHa1f) H x (S + K) correspond to a LDPC check matrix
and a high dense parity check matrix, respectively. I_S be the
S x S identity matrix I_H be the H x H identity matrix 0_SxH
be the S x H zero matrix and (GLT) KxL is a LT encoding
matrix. (GLDPC)S X K and (HHa1f) H X (S+ K) are known
on the both encoder and decoder side.
Step 2:-The second encoding step is to generate the repair
symbols from L intermediate symbols using LT encoding
process as LTEnc[K,C[0],C[1],…,C[L-1],(d,a,b)] [10] where
(d, a, b) represents triples for each symbol.
At the end of step 2 final transmitted streams are generated.
2) 3GPP Raptor Decoding Process: The N received
symbols are input to the decoder where
N = K + R – Ls (3)
Where K defines the no. of source symbols, R defines the
repair symbols and Ls represent loss symbols.
Matrix A of (M x L) can be formed similar to the encoding
process using received N symbols [10] where
M = S+H+N (4)
Where S is LDPC symbols, H Half Symbols and N received
symbols respectively. The matrix, A is a bit matrix that
satisfies A x C = E using matrix multiplication in GF (2).
Intermediate symbols C can then be decoded if the bit matrix
A is square (L x L) and invertible. Since the number of
received encoding symbols, N > K in most cases, so following
steps should be taken for decoding.
Step 1:- The first step in decoding is to convert (M x L)
matrix A to an (L x L) matrix using Gaussian Elimination
method [10].
Improved Gaussian elimination, consisting of row/column
exchange and row Ex-OR, is used in the 3GPP Raptor
decoding algorithm. In the decoding process, the original
matrix A will be converted into an identity matrix. Besides,
vector C and D change concurrently. Let （N ≥ K） be the
number of received encoding symbols and M=S+H+N. The
vector D=(D[0],… ,D[M-1]) is the column vector of M
symbols with values known to the receiver, where D[0]，…
,D[S+H-1] are zero-valued symbols that correspond to LDPC
and Half symbols, D[S+H]， … ,D[M-1] are the received
encoding symbols for the source symbols. When the original
matrix A is converted into identity matrix successfully, we can
get the intermediate symbols from D.
Before Gaussian elimination, we assume C[0]=0 ，
C[1]=1，… ，C[L-1]=L-1 and D[0]=0，D[1]=1，…
，D[M-1]=M-1 .initially. In the process of Gaussian
elimination, the vectors C and D change concurrently with the
changes of matrix A. The process abides by the rules as
follows:
 If the row i of A is exclusive-ORed into row i', then
symbol D[d[i]] is exclusive-ORed into symbols
D[d[i']];
 If the row i of A is exchanged with row i', then the
value d[i] is exchanged with the value d [i'];
 If the column j of A is exchanged with column j',
then the value c[j] is exchanged with the value c [j'].
It is clear that C[c[0]]，C[c[1]]，… ，C[c[L-1]] =D[d[0]]，
D[d[1] ]，… ，D[d[L-1] ] at the end of successful decoding.
The process of converting A into identity matrix consists of
four phases:
Phase I:-In the first phase of the Gaussian elimination, the
matrix A is partitioned into submatrices, where I is an identity
matrix i × i, O is a matrix with all values zero, U is a matrix
with u columns. An efficient algorithm, suggested in 3GPP
MBMS standard, is helpful for choosing an appropriate row to
do Gaussian elimination. The algorithm defines a graph
structure of matrix V. Let the columns of V be the set of nodes
and let the rows that have exactly two 1's in V be the set of
edges that connect the associated nodes. We define component
as follows: component in the graph is a set of nodes and edges
such that there is a path between all pairs of nodes, the size of
a component is the number of nodes in the component.
When i+u=L, the first phase ends successfully and the matrix
V disappears. If there are non-zero rows in V can be chosen in
the first phase, we can use the efficient 3GPP standard as
follows:
 Let r represents the minimum integer that at least one
row has exactly r 1's in V. When r ≠ 2, choose a row
with exactly r 1's in V with minimum original degree
among all such rows;
 When r=2, choose any row contained in the
maximum size component [13] of the graph defined
by V.
Then the first row is exchanged with the chosen row of V and
the arbitrary column, contained 1 in the chosen row, is
exchanged with the first column. Besides, the columns
contained remaining (r-1) 1's are exchanged with the last

__________________________________________________________________________________________
columns of V. After that, the chosen rows are exclusive-ORed
into the rows of A below the chosen row that have a 1 in the
first column of V. Accompanied by the process above, i is
increased by 1 and u is increased by (r-1). We carry out the
first phase again until it ends successfully.
Phase II: - In the second phase, the submatrix U is partitioned
into the first i rows, U_upper, and the remaining (M-i) rows,
U_lower. If the rank of U_lower is u, Gaussian elimination is
performed on it, and converts it into a matrix where the first u
row is the identity matrix. Besides, the last (M-L) rows are
discarded.
Phase III & IV: - The task of the third and the fourth phase is
to convert the U_upper into a matrix with all values zero.
Once the Gaussian Elimination is complete the bit matrix, A
becomes {LxL} and invertible. The intermediate symbols C
can then be obtained as
C =A-1D (5)
Here D represents column vector of S+H zero symbols
followed by the N received symbols. The intermediate
symbols, C is then passed to LT decoding to regenerate the K
Source symbols. [10]
4. PERFORMANCE EVALUATION OF RAPTOR
CODES:
It is clear that the key points featuring the performance of an
AL-FEC scheme are the decoding failure performance with
respect to the number of additional symbols received and
further, as a direct consequence of this aspect, the amount of
the transmission redundancy required to confront different
packet losses patterns.
To this direction, firstly we investigate the decoding
performance compared to the reception overhead such a FEC
code requires to successfully recover the protected data.
Figure 3 presents the probability the FEC decoding process to
fail in function to the number of additional symbols received,
i.e., the reception overhead .For each reception overhead, the
results are acquired from 10,000 experimental trials with
symbols erased at random. Comparing the performance of the
standardized Raptor FEC code for K=254 each with case
N1=254(K), N2=127(K/2), N3=93(K/4).
Table -1: Comparison Table for RFC 5053 K=254 for
Latency 3
Sourc
e
Symb
ols
(K)
Repair
Symbols
(N)
Total
Symbols
(K+N)
PbE Encod
ing
Cost
Supp
ort
Pack
et
Loss
254 254(K) 508 0.163
7
50% 49.4
%
254 127(K/2) 381 0.142
0
33.33
%
32.54
%
254 64(K/4) 318 0.121
3
20.12
%
19.18
%
Here Encoding Cost= Repair Symbols /Total Symbols .For
Supporting Packet Loss we are noting all the values for
Reception Overhead 3 (which resembles the latency). So we
have to receive 3 more extra symbols which mean we have to
receive 254+3 = 257 symbols. or N = K case, total 508
symbols we are transmitting. out of which we must receive
257 symbols, hence channel can drop at maximum (508-257 =
251 symbols).so allowable channel loss is Maximum dropped
packets / Total Transmitting symbols = 251/508 = 49.4 %For
N = K/4 case, total 318 symbols we are transmitting. Out of
which we must receive 257 symbols, hence channel can drop
at maximum (318-257 = 61 symbols) so allowable channel
loss is Maximum dropped packets / Total Transmitting
symbols = 61/318 = 19.18 %
For case N=K/4 64 Repair symbols were used which shows
that decoding failure probability also decreases with less
bandwidth utilization
From Table 1 it is clear that for worst channel condition N=K
case is useful as supporting Packet loss is 49.4% and for
N=K/4 case is useful for good channel condition as encoding
cost and PbE are less compared to N=K.

__________________________________________________________________________________________
0 1 2 3 4 5 6 7
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
Reception Overhead
ProbabilityofFailure
RFC5053: K = 254
N1 = K
N2 = K/2
N3 = K/4
Figure 3: FEC decoding failure probability versus
Reception overhead for K=254
Comparing the three plotted curves behavior in fig 3 and fig 4,
we can immediately remark that a Raptor failure probability
decreases exponentially with the growth of the number of
additional FEC symbols.
0 1 2 3 4 5 6 7
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
Reception Overhead
RFC5053: K = 370
N1 = K
N2 = K/2
N3 = K/4
Reception overhead for K=370
0 1 2 3 4 5 6 7
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
Reception Overhead
Theoretical Vs Practical
Theoretical Limit
K = 254
K = 370
Reception overhead for Theoretical Vs Practical
Also as per equation (1) we have plotted curve as shown in fig
5 for theoretical Vs RFC 5053 (practical) which shows that we
are approaching to the theoretical limit and even at some point
we are getting better results than theoretical with lower
decoding failure probability.
CONCLUSION AND FUTURE WORK
In this work we have implemented and then provided an
extensive performance evaluation of AL-FEC based on the
Raptor codes(IETF RFC 5053) provided by Digital Fountain
to provide reliability against packet losses in 3GPP LTE
eMBMS services. We have examined how the Raptor
overhead varies during different network conditions and which
is the optimal overhead that a multicast sender should
introduce to the transmission to achieve successful delivery of
the multimedia content in a PTM manner.
Some future actions that may result from this work may be
possible; consideration is the design and evaluation of an
adaptive algorithm which calculates the optimum FEC
encoding process. This mechanism could be based on a system
of feedback reports on network conditions, as proposed in the
database and reports coding parameters. Finally, recently
appeared AL-FEC RaptorQ scheme, could further enhance the
research field of reliable multicast in mobile networks.
ACKNOWLEDGEMENTS
We would like to thank Yashesh Buch for providing such an
interesting topic. We are also grateful to Harish Padi for
valuable discussions and friendly support.
REFERENCES:
[1] 3GPP TS 26.346 V10.4.0.,” Technical Specification
Group Services and System Aspects: MBMS, Protocols
and codecs”, (Release 10), 2012.
[2] P. Elias. Coding for two noisy channels. in Proc. 3rd
London Symposium on Information Theory, pages 61–76,
1955.
[3] Han Wang, “Hardware Design for LT Coding”, MSc
Thesis,University of Delft, Holland, 2006.
[4] Berlekamp, E.R.: “Algebraic coding theory”, McGraw-
Hill, New York, 1968.
[5] M. Luby, M. Mitzenmacher, A. Shokrollahi, and D.
Spielman, “Efficient erasure correcting codes”, IEEE
Trans. Inf. Theory, vol. 47, no. 2, pp. 569–584, Feb. 2001
[6] David J. C. MacKay, “Fountain Codes”,
Communications, IEEE proceedings vol. 152, no. 6, Dec.
2005, pp. 1062 – 1068.
[7] M. Luby, “LT codes”, Proc. 43rd Ann. IEEE Symp. On
Foundations of Computer Science, Nov. 2002, pp. 271–
282.
[8] A. Shokrollahi, “Raptor Codes”, in Proc. IEEE Int. Symp.
Information Theory, Chicago, IL, Jun. /Jul. 2004, p. 36.

__________________________________________________________________________________________
[9] A. Shokrollahi, “Raptor codes,” Information Theory,
IEEE Transactions on, vol. 52, no. 6, pp. 2551–2567,
June 2006.
[10] M. Luby, A. Shokrollahi, M. Watson, and T.
Stockhammer, “Raptor forward error correction scheme
for object delivery,” September 2007, Internet
Engineering Task Force, RFC 5053. Available at
http://tools.ietf.org/html/rfc5053.
[11] Luby M, Watson M, Gasiba T, Stockhammer T, Xu W.”
Raptor codes for reliable download delivery in wireless
broadcast systems.” In Proc. of CCNC, 2006.
[12] T. Stockhammer, A. Shokrollahi, M. Watson, M. Luby,
and T. Gasiba,“Application Layer Forward Error
Correction for mobile multimedia broadcasting,”
Handbook of Mobile Broadcasting: DVB-H, DMB,
ISDBT and Media Flo, CRC Press, pp. 239–280, 2008.
[13] S. Dasgupta, C. H. Papadimitriou, and U. V. Vazirani, “
Algorithms ,” McGraw-Hill, July 18, 2006
BIOGRAPHIES:
Avani U Pandya has received the B.E (Electronics&
Communication Engineering) degree from North Gujarat
University (Government Engineering College, Modasa) in
2007. She is currently a M.E (Communication) student (4th
semester) in G .H. Patel College of Engineering &
Technology Gujarat from Gujarat Technological University,
India. Her current research interests include 4G LTE eMBMS
Network, Wireless communication
Prof Sameer D Trapasiya is Presently working in
Electronics& Communication Engineering Dept,G .H. Patel
College of Engineering & Technology., Gujarat.He has more
than 6 years of experience in teaching. His current areas of
interest are Cognitive radio, MIMO Communication., Cross
layer optimization, Wireless Sensor Network.
Santhi S Chinnam is Presently Telecom Engineer in 4G RAN
& Device Validation at Rancore Technologies Pvt Ltd, Navi
Mumbai. He has received his Mtech in Communications from
IIT Roorkee

Performance analysis of al fec raptor code over 3 gpp embms network

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (17)

Destaque

Destaque (19)

Semelhante a Performance analysis of al fec raptor code over 3 gpp embms network

Semelhante a Performance analysis of al fec raptor code over 3 gpp embms network (20)

Mais de eSAT Journals

Mais de eSAT Journals (20)

Último

Último (20)

Performance analysis of al fec raptor code over 3 gpp embms network