Reliable Multimedia Broadcast in Cellular Systems ......sports replay, file sharing •...

Technische Universität München (TUM)

Lehrstuhl für Nachrichtentechnik (LNT)

Prof. Dr.-Ing. Joachim Hagenauer

Reliable Multimedia Broadcast in Cellular Systems

H. Jenkac, JASS, St. Petersburg, 4/2005


H. Jenkac, JASS, St. Petersburg, 4/2005- 1 -

Hrvoje Jenkac

Joint Advanced Student School (JASS) 2005

30.03.05 – 10.04.05St. Petersburg, Russia

Reliable Multimedia Broadcast in

Cellular Systems:

Retransmission

and

Fountain Coding Strategies

Reliable Multimedia Broadcast in

Cellular Systems:

Retransmission

and

Fountain Coding Strategies








• MBMS: Motivation and Overview

• Unacknowledged Broadcast Strategies

• Acknowledged Broadcast Strategies

• H. 264 Video over MBMS

• Fountain Coding: The Turbo Fountain

OutlineOutline








• Multimedia Broadcast and Multicast Services (MBMS)

Traffic telematics, weather information, news broadcast,music streaming (web radio) , video concert,

sports replay, file sharing

• Standardization is still ongoing

• All subscribers receive the same content

• Efficient data delivery (common resources)

• Reuse of existing physical layer functionalities

• Sufficient Quality of Service (QoS)

Motivation - Broadcast Services Motivation - Broadcast Services








UnicastUnicast

ContentServer

BTS

MS








Broadcast / Multicast Broadcast / Multicast

ContentServer

BTS

MS

RTP/UDP/IP








Packet Broadcast Packet Broadcast

P1P2P3P4P5

P4

P3

P2

P1

• MSs listen to the same frequency / timeslot / code

• Data transmission downlink only








Dynamics depends on• Receiver velocity• Frequency

Receive Power = 1/T ∫( . )2 dt








time in seconds

C/I

in d

B

Fading Processes Fading Processes

• losses• errors

• losses• errors








Traditional GPRS Protocol Stack Traditional GPRS Protocol Stack

Encoded block Encoded block

Convolutional Encoding Convolutional Encoding

LLC frame

RLC SDUsegment

RLC SDUsegment

RLC SDUsegment

RLC SDUsegment

RLC SDUsegment

RLC dataBH CRC tail RLC dataBH CRC tail RLC dataBH CRC tail

Burst Burst Burst Burst Burst Burst Burst Burst

physic

al la

yer

RLC

/MA

C layer

IP / UDP / RTP headerFH FCS

LLC

layer

ok err

xx

NAL unitx

statistical representation of RLC-SDU segments

statistical representation of RLC-SDU segments








GPRS PerformanceGPRS Performance

50 bytesCS 4

36 bytesCS 3

30 bytesCS 2

20 bytesCS 1

Payload

size

Coding

Scheme

• Performance shown for

1 timeslot

• Packet length S=500

bytes

• Combination of max. 6

timeslots possible

• RLC payload sizes:

CS1 CS2 CS3 CS4

17.5dB

15.0dB

10.0dB

7.5dB

GERAN working assumtion:

required QoS for most multimedia

codecs

Impacts to the broadcast scenario:

� Different loss characteristics for different

receivers

� Worst user C/I=7.5 dB should be supported

Impacts to the broadcast scenario:

� Different loss characteristics for different

receivers

� Worst user C/I=7.5 dB should be supported








IP over Wireless IP over Wireless

PayloadHeader

x xPacket Erasure ChannelPacket Erasure Channel

PayloadHeader x

Tra

nsm

itte

r (B

TS

)R

ece

iver

(MS

)

Segment Segment Segment Segment

Segment Segment SegmentSegment








Packet Erasure Channel Packet Erasure Channel

packet

(segment)

correct reception

erasure

correct reception

erasure

correct reception

erasure

correct reception

erasure

11 p−

1p

21 p−

2p

31 p−

3p

1 Mp−

Mp

MS 1

MS 2

MS 3

MS M

• statistically

independent

packet erasures

• erasure (loss) probability pm

• pm depends on C/I of

MSs and packet size








Transmission Bearer Transmission Bearer

• Unacknowledged Bearer

• best effort delivery

• FEC only

• low delay

• Acknowledged Bearer

• reliable

• lost packets are retransmitted or incremental

redundancy (IR)

• persistent / non-persistent

• increased delay / reduced throughput













OutlineOutline








Unacknowledged Bearer Unacknowledged Bearer

Packet Source

Segmentation

Segmentation

PECPEC

SegmentationReassemblyReassembly

PECPEC

Packet SourcePacket

SourcePacket

SourcePacket Sink









Packet Source

Segmentation

Segmentation

PECPEC


PECPEC

Packet SourcePacket

SourcePacket

Source

FECFECFECFEC

FEC

Packet Sink









Packet Source

Segmentation

Segmentation

PECPEC


PECPEC

Packet SourcePacket

SourcePacket

SourcePacket Sink

FECFECFECFEC

FEC








Simple Solutions Simple Solutions

• Repetition of IP packets

• Located in the BM-SC (Broadcast Multicast Service Center)

• No impact on physical layer

• Fast deployment

• Low complexity

• No changes to BTS

• Repetition of Link Layer Packets

• Located in the RAN

• No impact on the physical layer

• Low complexity

• Small changes at RAN required








BM-SC RepetitionBM-SC Repetition

( )1 1MS

LS mP p

= − −

Ps residual IP-packet error rate

pm segment loss probability

S IP-packet size [byte]

L segment size

8 LZ

T M

⋅=

⋅

SD M T

L

= ⋅

IP Packet

IP Packet IP Packet

IP Packet

IP Packet IP Packet

IP Packet IP Packet

M times repetition M times repetition

Segment Segment Segment Segment Segment Segment Segment Segment Segment Segment Segment Segment Segment Se

M times repetition of media packets

Residual IP-packet error rate: Maximum throughput:Delay:

D delay

M number of repetitions

T packet (transmission) rate [1/s]

S

L








Link Layer Packet RepetitionLink Layer Packet Repetition

( )1 1S

M LSP p = − − 8 LZ

T M

⋅=

⋅

SD M T

L

= ⋅

IP Packet

Segment Segment Segment Segment

Segment Segment Segment Segment Segment Segment Segment Segment Segment Segment Segment Segment

L

S




L segment size

Residual IP-packet error rate: Maximum throughput:Delay:

D delay



IP Packet IP Packet IP Packet








Performance Results RepetitionPerformance Results Repetition

0 1 2 3 4 5 6 7 8 9 1010

−4

10−3

10−2

10−1

100

RLC−SDU error rate vs. throughput for TU03, CS4, C/I=7.5 dB, FH=1, and S=500.

Throughput in kbit/s

RLC

−S

DU

err

or

rate

BM−SC CS1RLC CS1BM−SC CS2RLC CS2BM−SC CS3RLC CS3BM−SC CS4RLC CS4

0 1 2 3 4 5 6 7 8 9 1010

−4

10−3

10−2

10−1

100

RLC−SDU error rate vs. throughput for TU03, CS4, C/I=7.5 dB, FH=1, and S=500.

Throughput in kbit/s

RL

C−

SD

U e

rro

r ra

te

BM−SC CS1RLC CS1BM−SC CS2RLC CS2BM−SC CS3RLC CS3BM−SC CS4RLC CS4

RLC frame repetition

IP packet repetition

Combination of 6 timeslots max. throughput approximately 12 kbit/s

Better coding strategies exist than repetition redundancy!

Better coding strategies exist than repetition redundancy!








Video over PECVideo over PEC

0% packet loss

1% packet loss10% packet loss

0.1% packet loss

• 900 frames QCIF (176 x 144)

• H264 encoded

• QP=37, 48 kbit/s

• What is the required residual error rate?

• Each Video Frame is mapped to one IP-packet

• 10 frames/s

• 1 I-frame/s








Outer RS-Coding Outer RS-Coding

IP Packet

Segment Segment Segment

IP Packet IP Packet

k n-k

Segment Segment Segment Segment SegmentSegment Se

IP Packet

Segment Segment Segment Segment Segment SegmentSegment Segment Segment Segment SegmentSegment Se

Segment Segment Segment

byte-wise Reed-Solomon codingbyte-wise Reed-Solomon codingbyte-wise Reed-Solomon codingbyte-wise Reed-Solomon codingbyte-wise Reed-Solomon codingbyte-wise Reed-Solomon coding








Properties of Reed-Solomon Codes Properties of Reed-Solomon Codes

• systematic shortened Reed-Solomon codes defined over GF(2q),

where q is the number of bits per symbol (usually q=8).

• The code is specified by its overall symbol length n and its

information symbol length k, the rate is k/n.

• Any n ≤ 2q-1 and any k ≤ n can be chosen.

• (n,k,q)-RS codes have the following property:

As long as the number of lost symbols (erasures) within one

code word is smaller or equal than n-k, the entire k

information symbols can be reconstructed.








Outer RS-Coding Outer RS-Coding

( )S1

11

nn ii

m mi n k

np i p p

in−

= − +

= − ∑

/S 1 (1 )

S LsP p= − −

8k L MZ

n T

⋅ ⋅= ⋅

( )( )1D n k n Tγ β= + − + +S

Lα

=

1

k

αβ

− =

( )1 modkγ α= −

Symbol (segment) erasure probability after RS decoding:

Residual IP-packet loss rate:

Throughput:

Delay:




L segment size

D delay



k/n code rate




L segment size

D delay



k/n code rate








Performance of Outer RS CodingPerformance of Outer RS Coding

throughput gain

[Jenkac, Stockhammer, Liebl, Xu, 2004]








Performance of Outer RS CodingPerformance of Outer RS Coding

0 500 1000 15000

1000

2000

3000

4000

5000

6000

7000

8000Delay versus RLC−SDU size S

RLC−SDU size S in bytes

De

lay D

in

ms

RLC/MAC rep. CS1, M=5Outer Coding, CS1, n=16, k=8Outer Coding, CS1 n=128, k=98














OutlineOutline








Acknowledged Bearer Acknowledged Bearer

Packet Source

Segmentation

Segmentation

PECPEC


PECPEC

Packet SourcePacket

SourcePacket

SourcePacket Sink








Acknowledged Bearer Acknowledged Bearer

Packet Source

Segmentation

Segmentation

PECPEC


PECPEC

Packet SourcePacket

SourcePacket

SourcePacket Sink

ARQARQARQARQ

ARQ

Feedback








Packet Broadcast Packet Broadcast

P1P2P3P4P5

P4

P3

P2

P1

• p-t-M broadcast

• common frequency / time slot / code

• packet losses (PEC)

• different users lose different packets

• Reliable broadcast bearer (ARQ)

• Feedback to transmitter required

• Reliable broadcast bearer (ARQ)

• Feedback to transmitter required








Feedback Channel Feedback Channel

• Ideal feedback scenario

• Separate feedback channels for each receiver

• ACK/NACK indication

• Packet labeling

• Restricted feedback scenario

• Common Feedback Channel

• Only NACK indication

• No packet label information








Common Feedback Channel Common Feedback Channel

• Base station recognizes that at least one of the terminals

needs a retransmission (power measurement)

• As p-t-M retransmissions are performed, it is not of interest

for BS which terminal needs retransmission

• Base station recognizes that at least one of the terminals

needs a retransmission (power measurement)

• As p-t-M retransmissions are performed, it is not of interest

for BS which terminal needs retransmission

Packet reception failed:

• terminals send NAK using a common frequency and time

slotin uplink

• BS receives superposed signal

Packet reception succeeded:

• terminals do not send anything

• Feedback similar to On-Off-Keying

modulation

superposition








BORMAC Feedback ModelBORMAC Feedback Modelf2(t)fM (t)f1(t) F (t)�Binary OR Multiple Access Channel (BORMAC)

• fm(t)=1⇒ receiver m indicates nack

• fm(t)=0⇒ receiver m indicates ack

•Fm(t)=1⇒ at least one receiver indicated nack

• fm(t)=0⇒ no receiver indicated nack








p-t-p Retransmissions p-t-p Retransmissions

P3

P3P4

P2

P1P2P3P4P5

P4

P3

P2

P1

• After the broadcast session M

p-t-p sessions are initiated

• lost packets are requested by the

terminals (ideal feedback scenario)

• p-t-p transmission to each

separate terminal

• each requested packet is utilizing

one frequency and time slot

• parallel transmission to terminals

possible

4 channel accesses required4 channel accesses required








p-t-M Retransmissions p-t-M Retransmissions

P1P2P3P4P5

P4

P3

P2

P1

• lost packets are indicated by

the terminals

• p-t-M re-broadcast to the

terminals

• terminals listen to one

frequency / time slot / code

• identical frames requested by

several terminals only occupy

one radio resource

3 channel accesses required3 channel accesses required

P2

P3

P3P4

P2

P4








1 1 1

1

1 1 101 11

0

101 1

1100

0 10 01 00110

11 1 11 110 1 01 10 010 1 111 0 1 00

XOR

Transmission to user 1

1 01 10 010 1 1?? ? ? ?? 1 0 11001 0

11 1 11 110 1 01 10 010 1 1 0 0 1 0

Message 1 Message 2 Message 3

11 1 11 1101 1

Transmission to user 2

1 0 11001 0

11 1 11 110 1 01 10 010 1 1 0 0 1 0

11 1 11 1101 1 1 1?? ? ? ?? 1 111 0 1 00

NACK








p-t-M ARQ with IR p-t-M ARQ with IR

R1

R1

R2

R2

P1P2P3P4P5

P4

P3

P2

P1

• Incorrect code words are

indicated by terminals

• p-t-M transmission to the

terminals (terminals listen to

one frequency / time slot /

code)

• Incremental redundancy

packets are sent,

• Outer code can recover lost

packets

• Only 2 channel accesses required

• Reduced feedback frequency

• Only 2 channel accesses required

• Reduced feedback frequency








IR with Reed-Solomon Codes IR with Reed-Solomon Codes

Information k symbols Redundancy n-k symbolsChannel

Coding

Puncturing: Puncturing

p symbols

Transmission

(like puncturing):

Decoding 1 failed

→ NAK and IR

Decoding 2 failed

→ NAK and IR

Decoding 3 succ.

→ ACK

Channel

losses








Performance of p-t-M-IR ARQ Performance of p-t-M-IR ARQ

• T is random variable – denoting the number of required

packet broadcasts to deliver data to all users (correctly)

• We are interested in the expected value E{T}

Throughput derivation:

T

1

{ } Pr{ }n

t

E T t T t=

= ⋅ =∑

t








Performance of p-t-M-IRPerformance of p-t-M-IR

( ) ( )

( )

1

1 1 11

0 0

1

0

{ } Pr{ }

11 1 1 1

11 1 1 1

n

t

n k ki it i t i

m m m m

m mt k i i

ki j i

m m

m i

E T t T t

t tt p p p p

i i

j jn p p

i i

=

− − −− − −

= = =

−−

=

= ⋅ =

− = ⋅ − − − − − +

− + − − − − −

∑

∑ ∑ ∑∏ ∏

∑∏ ( )1 1

1

0

1n k

i j i

m m

mj k i

p p− −

− −

= =

− ∑ ∑∏

{ }k

ZE T

=

Throughput: Residual segment error rate:

( ),1

11

nn xx

res m m m

x n k

np x p p

xn

−

= − +

= − ∑









0 5 10 15 20 25 30 35 40 45 501

2

3

4

5

6

7

8

number of users M

thro

ughput in

kbit/s

Throughput vs. number of users M, iFH, 7.5 dB, k=12

p−t−p CS1 R=1p−t−M CS1 R=1p−t−M IR CS1 r=1p−t−p CS1 R=2p−t−M CS1 R=2p−t−M IR CS1 r=2p−t−p CS1 R=10p−t−M CS1 R=10p−t−M IR CS1 r=10

p-t-p retransmissions

p-t-M retransmissions

p-t-M-IR ARQ










0 200 400 600 800 1000 1200 1400 1600 1800 20000

1

2

3

4

5

6

7

8

number of users M

thro

ughput in

kbit/s

Throughput vs. number of users M, iFH, 7.5 dB, k=12

p−t−p CS1 R=1p−t−M CS1 R=1p−t−M IR CS1 r=1p−t−p CS1 R=2p−t−M CS1 R=2p−t−M IR CS1 r=2p−t−p CS1 R=10p−t−M CS1 R=10p−t−M IR CS1 r=10

p−t−M IR (r=1, r=2, r=10)









0 1 2 3 4 5 6 7 8 9 1010

−10

10−9

10−8

10−7

10−6

10−5

10−4

10−3

10−2

10−1

100

Residual RLC frame error rate 7.5 dB, k=12

number of retransmissions R / average number of redundancy packets r

RL

C f

ram

e e

rro

r ra

te

p−t−p CS1p−t−M CS1p−t−M IR CS1

p-t-p retransmissions

p-t-M retransmissions

p-t-M-IR ARQ









Performance 10 dB Performance 10 dB GERAN parameters:

• CS1 (L=20 byte)

• C/I = 10 dB (p=0.03)

• 1 time-slot









Residual IP-Loss Rate Residual IP-Loss Rate GERAN parameters:

• CS1 (L=20 byte)

• C/I = 7.5 dB (p=0.2)

• 1 time-slot









Conclusions: Transmission BearersConclusions: Transmission Bearers• Only FEC with Reed-Solomon Codes is suitable to define

an appropriate unacknowledged mode bearer for

broadcast in cellular environments.

• For reliable services feedback from the receivers to the

transmitter is required.

• ARQ combined with incremental redundancy performs

excellent in broadcast environment with feedback.

• Degeneration of p-t-M-IR ARQ with increasing number of

users is minimal compared to other schemes.

• Current work: Closer investigation of the common

feedback channel













OutlineOutline








� World cup 2006 in Germany: “A time to make friends”

� But how can we provide football to everyone, on the road, in or nearby the stadium, etc.?

� The idea: A video broadcast service on top of existing cellular systems, name it:

� Multimedia Broadcast and Multicast Services

� How can video transmission be accomplished in this scenario?

� Use the best available video coder H.264/AVC

� Use GSM/GERAN with no or little modifications

� Adaptation of the video application!

�What is the achievable Video Quality?

Motivation Video over MBMSMotivation Video over MBMS








H.264/AVC and NALH.264/AVC and NALH.264 Conceptual Layering

Transport Layer

Network AbstractionLayer Encoder

Network AbstractionLayer Decoder

H.264 to

H.320

H.264 to

MPEG-2

Systems

H.264 to

H.324/MH.264 to

RTP/IP

H.264 to

ISO

file format

NAL Decoder InterfaceNAL Encoder Interface

Wireless Networks

VCL-NAL Interface

Video Coding LayerEncoder

Video Coding LayerDecoder

Wired NetworksBroadcast Networks

Video Coding LayerEncoder

Video Coding LayerDecoder

slices

NAL units








� GPRS parameters:

� TU03 (3km/h pedestrian user)

� Fixed coding scheme CS1

� combination of 6 downlink time-slots, 48 kbit/s max. throughput

� H.264/AVC parameters:

� static parameters for all simulations:

� Foreman (QCIF), 7.5 fps

� I-frames every 10 sec

� no B-frames (IPPPP…)

� variable parameters:

Parameters – Experimental Setup Parameters – Experimental Setup

Expected loss rate in RaDiOMacroblock Mode Selection

PNALU

Max. NAL unit length (slice length)

NNALU

Header overhead (RTP/UDP/IP)

Total bit-rate including headers

HRv








� Video encoding without channel aware macroblock selection (only I-frames every 10 sec)

� GPRS system unmodified, broadcast mode

� Performance at C/I=7.5dB (worst user to be supported)

Non-optimized approach Non-optimized approach

0%

PNALU

= frame size

NNALU

40 bytes48000 bit/s

HRv

0%

PNALU

50 bytes

NNALU

40 bytes48000 bit/s

HRv








Optimized H.264 over GPRS Optimized H.264 over GPRS � Video encoding optimized on

packet loss rate of worst user to be supported in the cell (C/I = 7.5 dB)

� rate-distortion optimization

� GPRS system unmodified

40%

PNALU

50 bytes

NNALU

40 bytes48000 bit/s

HRv

40%

PNALU

50 bytes

NNALU

40 bytes48000 bit/s

HRv

Worst user to b

e supported

=> => ModificationsModifications

to GSM GPRSto GSM GPRS

areare necessarynecessary forfor

sufficientsufficient QoSQoS of of

videovideo









H.264 over UNAK-MBMS H.264 over UNAK-MBMS � UNACK bearer for MBMS based

on RS coding on RLC layer

� Reduction of loss rate:

37875

bit/s

36000

bit/s

48000

bit/s

throughput

0.02%

(128,101)

0.03%

(64,48)

11%RLC/MAC block loss rate @ 7.5dB

no coding (GPRS)

(n,k)-RS code

0%

PNALU

300 bytes

NNALU

40 bytes36000 bit/s

HRv

40%

PNALU

50 bytes

NNALU

40 bytes48000 bit/s

HRv⇒⇒ RelativelyRelatively lowlow

complexitycomplexity

⇒⇒ Little Little changeschangesin in thethe systemsystem

⇒⇒ reasonablereasonablequalityquality









H.264 over ACK-MBMSH.264 over ACK-MBMS� ACK bearer with feedback and

retransmissions

� No. of users infl. throughput

0%

PNALU

300 bytes

NNALU

40 bytes36000 bit/s

HRv

0%

PNALU

=frame size

NNALU

40 bytes36000 bit/s

HRv

39300 bit/s

40500 bit/s

Throughput,

k=128

0%

U=50

0%

U=10

RLC/MAC block

loss rate @ 7.5dB

No. of users

⇒⇒ HigherHighercomplexitycomplexity

⇒⇒ SignificantSignificantchangeschanges areare

necessarynecessary

⇒⇒ Good Good qualityquality









� RTP/UDP/IP header H=40 bytes

� Compressed RTP/UDP/IP header H=5 bytes on average

� More bitrate for error resilience features and video coding

� PSNR results outperform system without HC, but only slight

� Robust header compression was assumed

Header Compression (HC) Header Compression (HC)

⇒⇒ Slight improvements with HC.Slight improvements with HC.









� In UNACK and ACK mode increase in C/I did not results in increased PSNR performance.

� Support of worst case user results in fixing the code rate.

� Outer coding provides flexibility to adapt coding rate:

� relaxed worst case user

assumption

� change in user topology

� increased throughput

� Significant gains

Adaptation to User Topology Adaptation to User Topology

0%

PNALU

=frame size

NNALU

40 bytes70848 bit/s

HRv









� The traditional GPRS in combination with non-optimized

and optimized H264/AVC cannot provide sufficient QoS.

� Modification at wireless network required.

� Enormous gains in PSNR and perceptual quality with RS outer coding and optimized video.

� Header compression slightly improves system

performance.

� Exploitation of feedback (ACK) does not provide huge

gains for video delivery compared to UNACK mode.

� Flexible coding allows adaptation to changing user

topology. Additional gains in video quality can be

achieved.

Conclusions: H.264 over MBMSConclusions: H.264 over MBMS













OutlineOutline








Broadcast without FeedbackBroadcast without Feedback

ContentServer

BTS

MS

Download and Play Service

� No feedback channels

� Asynchronous data access








Asynchronous Data Access Asynchronous Data Access

� Users enter asynchronously into serving area

� All users get same content (e.g. location based information like traffic control or restaurant information)

Scenario: Highway with many expected users








Fountain CodesFountain Codes� Information message u of finite size k symbols

� Fountain encoder produces an infinite number (n→∞) of code symbols x = F (u)

� Infinite redundancy: “rateless”

� Ideal Fountain code (erasure channel):

� No restriction on number of information symbols k

(large messages can be encoded without separation)

� MDS property: Any k out of n→∞ are sufficient to reconstruct the information message

� Never-ending redundancy like never ending water in a fountain.

Information k symbols Redundancy (n-k)→∞

[Bayers, Luby, Mitzenmacher, 2002]








Ideal Fountain Code Ideal Fountain Code Continuous broadcast as long as

receivers are present and unsatisfied

Erased packet

RX 1

RX 2

RX 3

RX 4

TX

Parity packetSystematic packet No transmission








Water Fountain vs. Digital Fountain Water Fountain vs. Digital Fountain

Fountain Code

� Person wants to fill up a cup with water

� Many persons can fill a cup with water at same time (broadcast).

� It does not matter which drops fill the cup, but only how many

� Asynchronous start of water reception possible

� Receivers want to receive messages from a transmitter

� Many receivers are able to receive at the same time

� It does not matter which symbols are received, but only how many

� Asynchronous start of download possible








Example: Reed-Solomon Coding Example: Reed-Solomon Coding

Information k symbols Redundancy n-k symbols

max. n-k erasures can be corrected

Information length is restricted to k








Coupon Collector problem Coupon Collector problem


File length 2k


ok

lost

Entire file data can not be reconstructed, though number of erasures is less than 2(n-k).








Generalization:

Ideal erasure fountain code:

Fountain Codes: Formalization Fountain Codes: Formalization

r = [ 1 01 1 1 1 1 1

1

111 1

1 1 1 1 1 1

1

1

1 1 1 1 1 1

1 1 1

1

1 1 1 1

1 1 1 1 1 111

1 0 0 …. ]

0 0 0 …. ]

0 0 0 0

00

0 0

0 0 … … 0

0 …. ]

0 .. ]

r = [

r = [

r = [

{ }1: ( )I IF F k−

≡ ∀ ≥x' u x'

1: ( )S S

kF F

C

− ≡ ∀ ≥

x' u x'

x' ≜ Number un-erased and un-punctured symbols

Number of un-punctured symbols x' ≜

Capacity achieving fountain code:








Ideal Fountain Approximations Ideal Fountain Approximations

� Unfortunately, fountain codes with optimal MDS property were notfound yet. Seems infeasible.

� Practical solutions have decoding inefficiency, i.e., k ’=(1+ε)k, with ε->0, symbols on average have to be received.

� Practical Fountain Codes:

� Data Carousel

� Data Carousel coded with RS-codes

� Tornado Codes (LDPC like)

� LT Codes (Luby Transform) (= randomly encoded LDGM Code)

� Raptor Codes (LT Code + accumulating)

� Turbo Fountain (TF)








Turbo Fountain: ConceptTurbo Fountain: Concept

� Infinite redundancy by applying turbo codes

� Ideally, all parity bits are independent

� using many different component codes

� interleave symbols randomly after encoding

� Decoding: exchange of extrinsic information

� Achieve gains by exploiting soft information








Multiple Turbo-FountainMultiple Turbo-Fountain








Parallel TF - EncodingParallel TF - Encoding

� parallel Concatenated Turbo Code produces T(u)

� T(u) randomly interleaved by random interleavers

� produced infinite redundancy

� Interleaved repetition structure

� for practical puncturing behavior sufficient

Parallel Turbo Fountain Encoder F








The Parallel TF - DecodingThe Parallel TF - Decoding

� Distribution of incoming bits

� y’ obtained by Soft Combining

� Decoding decision: Hard decision of the turbo decoder output L(u’)

Parallel Turbo Fountain Decoder F -1








Decoding Multiple Turbo CodesDecoding Multiple Turbo Codes








The Multiple TF - DecodingThe Multiple TF - Decoding

Multiple Turbo Fountain Decoder F -1

L(x’)








Simulation SetupSimulation Setup








Ideal Erasure Based

Fountain Code, R=1

Ideal Erasure Based

Fountain Code, R=1/2

Capacity Achieving

Fountain Code

Parallel TF, R=1

Parallel TF, R=1/2

Simulation ResultsSimulation Results

receiv

er

thro

ughput

ES/N0 in dB

AWGN – K=16000 Bit – L=160 Bit

Multiple TF, R=1

[Jenkac, Hagenauer, Mayer, 2005]








Simulation Results (2)Simulation Results (2)

Ideal Erasure Based

Fountain Code, R=1

Ideal Erasure Based


Ideal Erasure Based

Fountain Code, R=1

Capacity Achieving

Fountain Code

Ideal Erasure Based


Ideal Erasure Based

Fountain Code, R=1

Parallel TF, R=1

Ideal Erasure Based Fountain Code, R=1/2

Capacity Achieving

Fountain Code

Ideal Erasure Based

Fountain Code, R=1

Ideal Erasure Based

Fountain Code, R=1

Ideal Erasure Based


Capacity Achieving

Fountain Code

Parallel TF, R=1

Parallel TF, R=1/2

Ideal Erasure Based

Fountain Code, R=1

Ideal Erasure Based


Capacity Achieving

Fountain Code

Parallel TF, R=1

Parallel TF, R=1/2

Multiple TF, R=1

receiv

er

thro

ughput

ES/N0 in dB

Fast Fading – K=16000 Bit – L=160 Bit










Ideal Erasure Based

Fountain Code, R=1

Ideal Erasure Based

Fountain Code, R=1Ideal Erasure Based


Ideal Erasure Based



Capacity Achieving

Fountain Code

Ideal Erasure Based



Capacity Achieving

Fountain Code

Parallel TF, R=1

Ideal Erasure Based



Capacity Achieving

Fountain Code

Parallel TF, R=1

Parallel TF, R=1/2

Ideal Erasure Based



Capacity Achieving

Fountain Code

Parallel TF, R=1

Multiple TF, R=1

Parallel TF, R=1/2

receiv

er

thro

ughput

ES/N0 in dB

Block Fading – K=16000 Bit – L=160 Bit









Combined Source-Fountain CodingCombined Source-Fountain Coding

Pr{ u = +1} = p

Pr{ u = -1} =1 - p

Source State Information









[Dütsch, Jenkac, Hagenauer, Mayer, 2005]








Simulation Results (5)Simulation Results (5)[Dütsch, Jenkac, Hagenauer, Mayer, 2005]








Conclusions: Turbo-FountainConclusions: Turbo-Fountain

� Fountain codes solve the reliable broadcast problem with

asynchronous data access.

� No feedback channels are required.

� Digital Fountain approximation based on turbo codes :

The Turbo Fountain (TF)

� Significant gains by exploiting soft information.

� Interleaved repetition structure based on a rate 1/3 turbo-code, approximates a digital fountain very well.

� Combined Source-Channel-Fountain Coding.

� Future work: close remaining gap to capacity.








Thank you

for your attention!

Thank you

for your attention!

Date post:	01-Oct-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Reliable Multimedia Broadcast in Cellular Systems ......sports replay, file sharing •...

Documents