al-fec and mbms servicesplanete.inrialpes.fr/.../comm_mobiles_2011-12_part3_2p.pdf ·...

[email protected] Inria Rhône-Alpes

Février 2012

AL-FEC and MBMS services

1

! Part 1

Application-Level FEC codes http://openfec.org

2

Outline 1.  the erasure channel 2.  AL-FEC codes 3.  a few AL-FEC codes and their performances 4.  IETF standards for the use of AL-FEC

3

The erasure channel ! erasure channel ! definition:

! BSC (binary symmetric) and AWGN channels…

! the integrity assumption is a strong hypothesis ! a received symbol is 100% guaranteed error free

! largely simplifies decoding: ! belief propagation decoding ! iterative decoding ! maximum likelihood decoding ! Gaussian elimination ! more details to come…

4

0 0

1 1

erased! a symbol either arrives to the destination, without any error… … or is erased and never received

The erasure channel… (cont’) ! where do we find erasure channels? ! the Internet is intrinsically an erasure channel

! an IP datagram is either received or erased ! usually caused by a router congestion, or a routing error

! because of Ethernet CRC or TCP/UDP/IP checksum verifications ! when the underlying layers failed to recover/identify errors,

the “packet” is eventually discarded by higher layers checks ! certain MAC layers can ask for retransmissions, but it's

usually not the case

5

The erasure channel… (cont’) ! where do we find erasure channels… (cont) ! due to an intermittent connection model

! caused by the environment (obstacle in wireless comm.) •  a mobile terminals receives a subset of the packets sent"

! caused by the application (e.g., if it crashes) •  packets sent during the off-period are lost"

! these situations are easily recovered with point-to-point connections

•  TCP will do the job if the disconnection is short"•  if a new connection is needed, itʼs sufficient to remember

where the download stopped and ask the sender to continue from that point"

! …but it’s quite different if the content is broadcast/multicast •  the same content is sent to 100,000s of receivers!"

6

The erasure channel… (cont’) ! where do we find erasure channels… (cont) ! with distributed storage of a content (e.g., a file), when

a storage point fails ! RAID disks ! network-wide distributed storage, where a client selects a

subset of the storage node, each of them having a chunk of the content (source or repair data)

7

Quite different from PHY-layer FEC ! completely different assumptions!

! information bits coming from the upper layers, once encoded, form a codeword, i.e., a set of bits that is part of the set of valid words for this code

8

PHY channel

introduces errors

(sometimes erasures)

PHY-level FEC

information bits (e.g. 8 bits)

<1,0,0,1,1,0,1,1>

codeword (e.g. 12 bits)

<1,0,0,1,1,0,1,1|0,1,0,0>

PHY-level FEC

information bits <1,0,0,1,1,0,1,1>

erroneous codeword <1,0,0,0,1,1,1,1,0,1,0,0>

information bits

coded bits

FEC encoding

FEC decoding


9

AL-FEC codes ! definitions:

! AL-FEC are codes for the erasure channel ! k source symbols, n encoding symbols after FEC

encoding ! we say it's a (n; k) code, with dimension k and length n

! code rate:

! close to 1" "! little/no redundancy"! close to 0" "! high amount of redundancy"

! examples: •  code_rate = 0.5 means that there are as many redundancy

symbols as source symbols"•  code_rate = 2/3 means that n=k/2, i.e. we add 50% of

redundancy"10

!

code_ rate =kn

=before_encodingafter _encoding

AL-FEC codes… (cont’) ! let's consider the example of a (9; 5) code

11

ENCO

DIN

G

DEC

OD

ING

source object decoded object

n-k=4 repair symbols

k=5 source symbols

n=9 encoding symbols

e.g., UDP/IP datagram

erasure channel

AL-FEC codes… (cont’) ! definition: ! the symbol is the unit of data manipulated by the AL-

FEC codec ! usually a symbol is carried in a UDP/IP datagram "⇒ either received or erased"

! sometimes there are several symbols per UDP/IP datagram

! let's keep it simple from now on… one symbol per packet

12

AL-FEC codes… (cont’) ! definition: ! systematic codes are codes for which the k source

symbols are part of the n encoding symbols •  see previous example…

! preferred to non-systematic codes •  without loss, no decoding is needed which saves processing •  a receiver that does not implement the FEC code can still use

source symbols (backward compatibility)

13

AL-FEC codes… (cont’) ! AL-FEC codes ! usually implemented in higher communication layers

(rather than in the PHY layer), e.g.: ! within the application ! within the transport system (between RTP and UDP for

streaming flows, in FLUTE/ALC for filecasting applications) ! within the MAC layer (e.g., in DVB-H/MPE-FEC, or in DVB-SH/

MPE-IFEC)

! hence their name “Application Level-FEC” (AL-FEC) ! also called “Upper Layer-FEC” (UL-FEC) by those who work

at the PHY layer

14

AL-FEC codes… (cont’) ! they differ from PHY-layer FEC codes (1) ! PHY codes:

! correct bit errors, and if not possible detect the errors

! AL-FEC: ! recover from symbol erasures

! with AL-FEC codes, a symbol can be: ! a bit ! a byte (e.g., in DVB-H/MPE-FEC frames) ! a UDP or IP datagram (e.g., 1460 byte long) ! a file chunk (e.g., 1 MByte long)

15

AL-FEC codes… (cont’) ! does the symbol nature make any difference?"

! in the following figure…

! symbols, sent over the channel individually (e.g., in a UDP/IP datagram) are represented vertically

! but we can also look horizontally and identify codewords

16

{bits of position “i” in all symbols} ! ith codeword

AL-FEC codes… (cont’) ! exemple (at a receiver):

! LDPC code, 8,000 bit long (1 KB) symbols

17

source symbol!

source symbol!

erased symbol!

erased symbol!

source symbol!

repair symbol!

repair symbol!

erased symbol!

repair symbol!

erased symbol!

bit 0!bit 1!bit 2!bit 3!bit 4!bit 5!bit 6!bit 7!bit 8!bit 9!

bit 10!bit 11!

bit 7999!…!

codeword for bit index 0!

codeword for bit index 7999!

a 8000-bit long symbol (or packet)!

AL-FEC codes… (cont’) ! does the symbol nature make any difference (cont')

! e.g., with (binary) LDPC, consider this constraint between 3 source symbols and 1 parity symbol: s3 s10 s12 p8 = 0 ! this relation is valid:

•  for all the bits of same position in the symbols…"•  and all the bytes of same position in the symbols…"•  and all the 32-bit words of same position in the symbols…"

! said differently, all codewords experience the same erasures" ! in practice, with LDPC, we perform XOR operations on 32-

bit/64-bit words for higher computational efficiency ! it can be different with other codes, e.g., Reed-Solomon over

GF(2p), since their elements are in that case p-bits long

18


! small block codes (A.K.A. small dimension codes) ! goal is to reduce memory requirements and encoding/

decoding latency

! AL-FEC: ! use of large block codes (k >> 1) is very meaningful

19

AL-FEC codes… (cont’) ! yes, large block AL-FEC codes are beneficent ! the “coupon collector problem”

! the encoding of a large object with a small-block code requires it be segmented into several blocks, say N

! if a single source packet is missing, the probability a randomly chosen repair symbol recovers the loss is 1/N

•  since a repair symbol is only useful to the block it belongs to"!  if N !, this probability " #

20

block 1 decoded

block 2 decoded

block 3 decoded

block 4 decoded

block 5 decoded

block 6 decoded

block N decoded

randomly chosen repair

symbol ?

missing 1 symb.

AL-FEC codes… (cont’) ! said differently, encoding a large object with a small

block AL-FEC is suboptimal ! even if the AL-FEC is MDS (i.e., ideal)! ! this is the case with Reed-Solomon over GF(28)

•  k ≤ n < 256"

! example: •  with RS and code-rate ½, k=128 source symbols, n-k=128

repair symbols"•  with 1000 byte long symbols, a 10MB object is divided into 79

blocks of size 128 symbols each (except last one)"! LDPC codes are then significantly more efficient than RS in

that case…"•  …even if LDPC codes are not MDS, just because there's a

single block"

21


! use as high a code rate as possible ! goal is to reduce the transmission overhead

! AL-FEC: ! use of small rate codes (high amount of redundancy) is

meaningful

22

AL-FEC codes… (cont’) ! yes, small rate codes are really beneficent! ! imagine a receiver that randomly picks symbols from the

set of available {source symbols; repair symbols} ! this is +/- what happens with intermittent connectivity

! the probability of having duplicates " as the code rate " ! …and so does the download time $

23

randomly choose k (1+!) among n, with possible repetitions • k only a little bit inferior to n ! many repetitions # • k << n (small code rate) ! few repetitions $

set of n source+repair symbols

AL-FEC codes… (cont’) ! and what about rate-less codes? ! it’s the extreme

! an arbitrarily large number of repair symbols can be produced, on-the-fly

! A.K.A. Fountain Codes ! currently: LT codes and Raptor™ codes

! in practice they are “recycling fountain codes” •  large but limited tank, so water recycling is mandatory"

! a better name is “non-predetermined code rate codes” •  there is no a-priori code rate"

! alternative efficient small-rate codes exist ! see GLDPC-Staircase…

24


! usually implemented in hardware

! AL-FEC: ! usually implemented as a software codec ! because they operate in “higher layers” ! this is a key benefit w.r.t. PHY FEC

25

Be careful: codes ! codecs

specifies the way repair symbols are generated

implementation of the encoder and decoder

AL-FEC codes… (cont’) ! a software AL-FEC codec offers a high flexibility ! key code parameters are defined dynamically

! source block size ! code rate ! because the AL-FEC code is generated on-the-fly ! shortening/puncturing become useless

! efficient encoding/decoding of large objects ! because the codec uses the host memory, not the chipset

memory (limited/high costs) ! can be a key criteria in some situations (e.g., DVB-SH)

! taking account of the application requirements is easier ! because the codec is closer to the application ! makes Unequal Error Protection (UEP) simpler

26

AL-FEC codes… (cont’) ! how can we define good AL-FEC codes?

⇒ define performance metrics

! metric 1: erasure recovery capabilities ! it’s the main performance criteria ! measured as the overhead ratio:

•  e.g.: overhead=0.63% means that 0.63% of symbols in

addition to k are needed for decoding to succeed"•  required since many AL-FEC are not MDS (i.e., not ideal)"•  several derivatives: average overhead, 99% margin above

(resp. below) the average, etc."

27

!

decoding_overhead =# _of _ symbols_ required _ for _ decoding

k"1

AL-FEC codes… (cont’) ! metric 2: decoding failure probability = f(loss rate)

! more details than the decoding overhead"! the knee position and curve feet are extremely interesting…"

28

channel loss rate

decoding limit, depending on code rate

decoding impossible (too many losses…)

decoding failure probability

10-3

10-2

10-1

1

GOOD channel

BAD channel

slope should be as vertical as possible…

fall should happen as soon as possible…

decoding OK with

high proba…

AL-FEC codes… (cont’) ! metric 3: decoding failure probability = f(number

of symbols received) ! similar to metric 2 but as a function of the number of

symbols actually received •  the curve is an average over a large number of experiments,

for a given {code rate, loss rate}, since each experiment impacts the identity of the symbols actually received "

29

number of symbols received

decoding limit, depending on block size

decoding impossible

(too few symbols…)

decoding failure probability

10-3

10-2

10-1

1

slope should be as vertical as possible…

fall should happen as soon as possible… decoding

OK with high proba…

k

AL-FEC codes… (cont’) ! metric 4: recovery in case of partial decoding

! how many symbols recovered if decoding not complete?"•  too few symbols have been received (e.g., < k)"

! to the received source symbols we add the recovered source symbols"

•  don't consider the received/recovered repair symbols since they are useless once decoding is stopped"

30

AL-FEC codes… (cont’) ! metric 5: encoding and decoding speed

! to appreciate the algorithmic complexity •  often more reliable than theoretical algorithmic complexity

analyzes"•  theoretical analyzes often neglect such important aspects as

memory access/cache behavior/implementation details/…"! don’t forget that the decoding algorithm impacts the erasure

recovery metric… •  …usually there is an appropriate balance to find"•  some algorithms are faster but lead to lower erasure recovery

capabilities (see later)"! sometimes decoding complexity is the key

•  e.g., lightweight portable device"! sometimes encoding complexity is the key

•  e.g., deep space (autonomous) probe"

31

AL-FEC codes… (cont’) ! metric 6: required memory during encoding and

decoding ! even if RAM is used (rather than chipset memory), it should

be used with caution ! e.g., if data can fit in the CPU L2 cache, itʼs great"

! high impact of the decoding algorithm

32

AL-FEC codes… (cont’) ! performances depend on many parameters: ! block size

! impacts the decoding overhead ! some codes (e.g., LDPC and Raptor) are good asymptotically

but sub-optimal with “small blocks”

! symbol size ! impacts speed and memory requirements

! decoding algorithm ! e.g., iterative decoding is fast, but leads to sub-optimal

overhead results

33

good AL-FEC = good code + good codec


34

So, what do AL-FEC codes look like? ! we’ll, it’s not so different from PHY codes ! we find the same linear block codes

! e.g., Reed-Solomon and LDPC ! plus some specialized small-rate/rate-less codes

! e.g., Raptor/RaptorQ™, GLDPC ! decoding techniques change, but not necessarily the

inner coding techniques

! in the remaining, we’ll quickly introduce: ! LDPC-Staircase

! NB: we won’t introduce Raptor(Q) ™ codes even if largely used in MBMS systems ! far too complex!

35

LDPC codes ! in short ! “Low Density Parity Check” (LDPC)

! linear block codes ! discovered by Gallager in the 60’s ! re-discovered in mid-90s

! currently one of the key FEC techniques ! LDPC are the core of LT and Raptor codes

! original codes were extremely costly to encode ! generator matrix (G) creation requires a matrix inversion

! but high performance, lightweight variants exist

! in the remaining we focus on codes with a binary matrix but non-binary codes exist (coefficients in GF(2x), x > 1)

36

LDPC-Staircase codes ! LDPC-staircase codes (RFC 5170) ! a simple (trivial) parity check matrix structure

! defines a set of linear equations

! A.K.A. “double diagonal” or “Repeat Accumulate” codes ! but the left sub-matrix is fully regular

37

Source symbols Parity symbols

Constraints

0 1 0 1 0 1 0 0 0 0 1 0 0 1 1 1 1 0 0 0 1 1 1 0 0 0 1 1 0 0 0 0 1 1 1 0 0 1 1 0 1 1 1 0 1 0 0 0 1 1

S1 " S4 " S5 " P1 " P2 = 0

S1 S2 S3 S4 S5 P1 P2 P3 P4 P5

N1 “1”s per column

LDPC-Staircase codes… (cont’) ! encoding ! it’s trivial $

! produce repair symbols in sequence: P1, then P2, then P3… ! guaranties a high encoding speed

! example: 1MB object, 1024 symbols of size 1MB each platform: Intel Xeon 5120/1.86GHz/4GB RAM/64-bit Linux

38

k code rate

N1 encoding speed number XOR / k

1024 2/3 5 3.33 Gbps 5.499

1024 2/3 7 2.54 Gbps 7.499

LDPC-Staircase codes… (cont’) ! decoding ! solve a system of binary linear equations ! scheme 1: ITerative decoding (IT) ! scheme 2: Gaussian Elimination (ML, Max. Likelihood)

! recovery capabilities can be made close to ideal codes $ ! … by adjusting the matrix density with the N1 parameter

•  it’s the target number of “1” per column ! the higher N1, the closer to ideal codes $, but the more

complex the decoding # •  find a balance…

! example: 1MB object, k=1024, CR=2/3, N1=5 platform: Intel Xeon 5120/1.86GHz/4GB RAM/64-bit Linux

•  4.3 Gbps (IT) to 1.35 Gbps (ML) decoding speed

39

LDPC-Staircase performances ! for k=1024, code rate=2/3

! these curve give the decoding failure probability as a function of the number of symbols received (i.e. overhead)

•  minimum number of symbols is 1024"•  we see the positive impacts of increasing N1"

40

1e-05

0.0001

0.001

0.01

0.1

1

1020 1030 1040 1050 1060 0

20000

40000

60000

80000

100000

120000

140000

160000

Dec

odin

g fa

ilure

pro

babi

litiy

Num

ber o

f sam

ples

Number of received symbols

Histogram (total of 1000000 iter.)LDPC-Staircase N1=5 CR=2/3 k=1024

1e-05

0.0001

0.001

0.01

0.1

1

1020 1030 1040 1050 1060 0

50000

100000

150000

200000

250000

Dec

odin

g fa

ilure

pro

babi

litiy

Num

ber o

f sam

ples

Number of received symbols

Histogram (total of 1000000 iter.)LDPC-Staircase N1=7 CR=2/3 k=1024

N1 = 7 N1 = 5

Pr = 1 ! cannot be decoded

Pr << 1 ! high decoding probability


41

parameters average overhead

overhead for a failure probability " 10-4

k=1024, N1=5 0.636% with 1046 symbols received (i.e. 2.1% or 22 symbols overhead): Prfail=5.9*10-5

k=1024, N1=7 0.238% with 1039 symbols received (i.e. 1.5% or 15 symbols overhead): Prfail= 8.2*10-5


42

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

14 16 18 20 22 24 26 28 30 32 34

min

/ave

r/max

Bitr

ate

(Mbp

s)

loss percentage

LDPC-Staircase (N1=5) CR=2/3 K=1024 Symb.S=1024 LDPC-Advanced (N1=5) CR=2/3 K=1024 Symb.S=1024

ML required more and more often (bad channel)

IT is sufficient (good channel)

erasure probability on the chanel (%) (theoretical limit: correction possible if loss < 33,3…%)

decoding speed

(Mbps)

LDPC codes… (cont’) ! achievements !  an IETF standard, RFC 5170

! enables interoperable, independent implementations http://www.ietf.org/rfc/rfc5170.txt

!  LDPC-Staircase codes are included in the ISDB-Tmm Japanese standard for mobile multimedia

!  with a good codec they achieve: ! recovery performances close to ideal ! high speed encoding and decoding ! and high flexibility

•  adjust the “recovery capabilities” / “processing load” trade-off

43

LDPC codes performances… (cont’) ! and this is not the end…

! morality

! illustrates the need for:

! high potential codes ! high quality codecs

! both aspects are critical in practice

44

in spite of their simplicity, LDPC-staircase codes feature results close to ideal codes…


45

Use of AL-FEC in IETF standards ! Internet Engineering Task Force ! the place where Internet technology is standardized

! whole TCP/IP protocol stack and much more ! open to everybody

! no fee ! open discussion lists ! open specifications (as Internet-Draft, then as RFC) ! very academic friendly

! remains independent of any specific target use-case ! but technology is often instantiated by other standardization

bodies (e.g., 3GPP, DVB, OMA, etc.)

46

IETF motto: “rough consensus and working code”

Use of AL-FEC in IETF standards… (cont’) ! two IETF groups concerned by AL-FEC: ! AL-FEC for “file” distribution applications

! RMT (reliable multicast transport) IETF WG created in 1999, close to the end… e.g., within FLUTE/ALC (or FCAST/ALC or FCAST/NORM)

! AL-FEC for streaming applications ! FecFrame (FEC Framework) IETF WG created in 2006, now almost closed

47

AL-FEC for “file” delivery (RMT) ! the RMT WG specified ! several “reliable multicast transport protocols”

! ALC massively scalable reliable transport ! NORM ACK/NACK based reliable transport ! FLUTE file delivery on top ALC (INRIA co-author)

! a general framework for the use of AL-FEC ! AL-FEC is a MUST to achieve reliable efficient transfers…

! several AL-FEC schemes ! Null-Code scheme ! Raptor/RaptorQ schemes (Qualcomm) RFC 5053 ! Reed-Solomon (Inria/ISAE joint work) RFC 5510 ! LDPC-Staircase and Triangle (Inria/STM) RFC 5170

48

AL-FEC for “file” delivery (RMT)… (cont’) ! an object (e.g. a file) is often too large to be AL-

FEC encoded at once, as a single block ! split it into several blocks

•  blocks all have almost the same size (the last few ones that may be one symbol smaller)"

! FEC encode each block separately

49

- 4/18 -

1

Figure 2: Constructing FLUTE packets 2

The BM-SC communicates the transport object size, the encoding symbol size and the file size to 3

the receivers within the FLUTE session transmission such that the receiver can also calculate the 4

source block structure in advance of receiving a file. 5

The FLUTE packet is constructed from FLUTE header and payload containing one or more 6

encoding symbols. 7

The distinction between file and transport object is that the file is the object provided to the BM-8

SC and played-out or stored at the MBMS UE. Within the scope of FLUTE sessions, content 9

encoding may be used, for instance to compress the file with gzip for delivery. In the presence of 10

FLUTE session content encoding, the file and the transport object will be different binary 11

objects, and in the absence of content encoding the transport object will be identical to the file. 12

Any symbol calculations (including FEC) are performed on transport objects. 13

2.1.2.3 Download Examples 14

In a typical use case, multimedia files typically in 3GP or MP4 format are distributed through 15

download delivery method. In this case the delivery rate and the media rate may be completely 16

different as no real-time consumption is considered. 17

Table 1 shows some typical examples of file sizes for different types of multimedia content. 18

Table 1 Examples for Download delivery use cases 19

Number File Size Example

1 1 MByte (1 048 576 bytes) AAC encoded audio clip

2 3 MByte (3 145 728 bytes) MP3 audio clip

3 128 MByte (134 217 728) bytes 30 min SD movie coded at 500 kbit/s

4 1.8 GByte (1 887 436 800) bytes 2 hours HD movie coded at 2 MBit/s

2.1.2.4 DASH over download delivery service 20

In another use case as indicated in TS26.346, section 5.6, the download delivery method may be 21

used to distribute DASH formatted content over MBMS. MBMS is designed to serve large 22

receive groups with same content. The MBMS Download Delivery Method is designed to 23

deliver an arbitrary number of (binary) files via MBMS to a large receiver population. MBMS 24

Download defines several methods to increase reliability such as file repair. The download 25

delivery method supports the delivery of media segments and even media presentation 26

descriptions. Media segment URIs are described using the FDT in FLUTE. 27

Constructing FLUTE Packets

=

10110101001010101101101010101001001001010000000000111111111101100101101100101011

10110101001010101101101010101001001001010000000000111111111101100101101100101011

file transportobject

sourceblock(s)

00000

00000

encodingsymbol(s)

11111

11111

Header

FLUTE packet

11111

FLUTE/UDP/IP

packet

Example: AL-FEC within the FLUTE/ALC protocol stack"

AL-FEC for “file” delivery (RMT)… (cont’) ! what do we need to make it work in practice? ! a mechanism for the encoder (sender) to inform the

decoder (receivers) what AL-FEC code is used ! which code? ! which code parameters (k, n, etc.)?

! a mechanism for the sender to identify each symbol ! which object and block does it belong to?

50

the goal of the FEC Object Transmission Information (FEC OTI)

the goal of the FEC Payload Information header (FPI)

Example: LDPC-* for “file” delivery ! e.g, LDPC-staircase/triangle (RFC 5170) specifies: ! FEC Encoding ID: identifies the FEC scheme

! 3 ! LDPC-Staircase codes

! FEC Object Transmission Information: ! information needed to synchronize encoder and decoder ! can be transmitted once if done reliably

51

Ex: LDPC-* for “file” delivery… (cont’) ! a FEC Payload ID

! and all the algorithms needed to produce interoperable codecs ! the matrix creation algorithms ! the PRNG ! the parameter derivation techniques

52

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Block Number | Encoding Symbol ID (20 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Part 2

3GPP-MBMS (Multimedia Broadcast Multicast Service) and similar services

53

Outline 1.  massively scalable delivery 2.  IETF FLUTE/ALC standard for file massively

scalable delivery 3.  IETF FECFRAME for robust streaming 4.  MBMS

54

Introduction ! comment transmettre un contenu très populaire ?

! retransmissions en direct (streaming) ! % les canaux TV sont fait pour !

! et le reste (sites Web, flashs, enregistrements, guides de programmes) ? ! l’UMTS permet à chacun de surfer sur le Web… ! oui, mais à quel prix ?

55

communications point à point

je veux

je veux

Bob veut

Alice veut

serveurs du fournisseur de

contenus

réseau d’accès

Introduction… (cont’) ! avec des communications point-à-point (ex. TCP),

cela coince à plusieurs endroits ! coté serveur

! milliers/millions de clients à traiter individuellement, à qui retransmettre les données manquantes, etc.

! coté réseau d’accès (liaison serveur-Internet) ! débit_par_client = débit_ligne / nb_clients ! avec des millions de clients, ce n’est pas beaucoup et

cela coûte très cher ! ! coté réseau de distribution sans fil

! transmissions hertziennes % médium partagé % transmettre un très grand nombre de fois le même contenu est (1) un gâchis, et (2) impensable avec de gros contenus/grand nombre de clients

56

Introduction… (cont’) ! nouveaux services de diffusion de fichiers ! UMTS : MBMS (Multimedia Broadcast Multicast

Services) ! DVB-H : IP Datacasting

! tous deux fonctionnent en mode point-à-multipoint (multicast, ou diffusion)

! l’information traverse une seule fois un lien donné !

57

je veux

je veux

Bob veut

Alice veut

serveurs du fournisseur de

contenus

communications point à multipoint

réseau d’accès

Introduction… (cont’) ! bénéfices ! coté serveur

! passage à l’échelle massif si l’on utilise la bonne approche de transmission fiable (FLUTE et FEC)

! coté réseau d’accès ! débit_par_client = débit_ligne / nb_contenus_diffusés ! avoir un millions de client ou un seul revient au même

! coté réseau de distribution sans fil ! exploite pleinement les caractéristiques naturelles de

diffusion du réseau hertzien

! les solutions reposent sur IP % protocole fédérateur qui permet une intégration triviale Internet/WiFi/LAN/UMTS/DVB-*/3GPP/…

58

A second example ! …where AL-FEC is used with the MAC layer ! DVB-H/SH systems

! within the MPE-FEC system, for transmission impairment recovery (at MAC layer)

59 a close-up of the application data table

per-row Reed- Solomon encoding



60

FLUTE/ALC ! diffusion de fichiers (au sens large)

! service complémentaire aux transmissions point à point

! repose sur de nouveaux protocoles/briques ! FLUTE % application de transfert de fichiers ! ALC % protocole transport multicast fiable ! AL-FEC % codes correcteurs d’erreurs

! le tout au dessus de UDP/IP ! l’objectif est une transmission totalement fiable

61

! an example where AL-FEC improves both the reliability and the service ! reliable distribution of digital content library to vehicles ! relies on FLUTE/ALC for the file-casting service

62

FEC encoding

multimedia content carrousel

reception… multimedia content

FEC decoding

FLUTE/UDP broadcast transmission to a multicast group

FLUTE/ALC… (cont’)

FLUTE/ALC… (cont’) ! ALC effectue la transmission (transport) ! approche de type « carrousel » (par ex.) ! les contenus sont transmis en boucle, longtemps

! % plusieurs cycles de transmission ! chaque client « pioche » ce qui l’intéresse dans la

session, grâce aux méta-données qui décrivent le contenu disponible

63

carrousel (contenu dynamique)

object 0

object 1

object 2

object 3

object 4

FDT #1

object 0

object 1

object 5

object 3

FDT#2

change

... object 0

FDT#3 November 2003 S M T W T F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

• reçoit les méta-données • décide de garder objet 4

FLUTE/ALC… (cont’) ! FLUTE décrit le contenu transmis ! les méta-données des fichiers de la session sont

rassemblés dans la FDT (File Delivery Table) ! exemple (XML/MIME) :

<?xml version="1.0" encoding="UTF-8"?> <FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fl="http://www.example.com/flute" xsi:schemaLocation="http://www.example.com/flute-fdt.xsd" Expires="2890842807"> <File Content-Location="www.example.com/menu/tracklist.html" TOI="1" Content-Type="text/html"/> <File Content-Location="www.example.com/tracks/track1.mp3" TOI="2" Content-Length="6100" Content-Type="audio/mp3" Content-Encoding="gzip" Content-MD5="Eth76GlkJU45sghK"/> </FDT-Instance>

64



65

AL-FEC for streaming (FECFRAME) ! a generic, flexible framework for the use of AL-FEC

in a streaming protocol stack ! RFC 6363, October 2011, http://tools.ietf.org/rfc/rfc6363.txt

66

Application

FECFRAME Framework

Application

UDP/IP

Application

one or several source + repair flows

Host

Application

FECFRAME Framework

Application

UDP/IP

Application

Host

erasure channel

one or several source + repair flows

AL-FEC for streaming... (cont') ! FECFRAME is:

! independent of the transport protocol (UDP/DCCP/…)

! independent of the real-time framing protocol (RTP…) •  even if RTP is the main target and some techniques rely on it"

! can be backward compatible to receivers not supporting FECFRAME

•  it's a dedicated mode of operation, not the general rule"

! offers multiplexing capabilities •  a single repair flow can protect one or several source flows,

whether they are related or not"

67

AL-FEC for streaming... (cont') ! provides flexible flow composition capabilities

! example (draft-ietf-fecframe-sdp-elements): •  the 3rd FEC framework instance provides several additively

composed repair flows that protect a subset of the source flows…"

____| FEC FRAMEWORK / | INSTANCE / | 3: Repair Flow / SOURCE FLOWS / | FEC FRAMEWORK 0: Source Flow |___/ |------| INSTANCE __| 1: Source Flow | | 4: Repair Flow | | 2: Source Flow | | | FEC FRAMEWORK |__________________________| INSTANCE | 5: Repair Flow | 6: Repair Flow | 7: Repair Flow

68

Rapid technical overview ! general architecture

69

application data unit

source data flow

real-time framing protocol (e.g., RTP)

FECFRAME framework

transport protocol (e.g. UDP)

FEC scheme building block

source symbols

repair symbols

FEC repair packet FEC source packet

one or several transport flows

Rapid technical overview… (cont') ! step 1: assign each flow a unique flow ID (done

once) ! mapping between:

•  source flow (characterized by the {transport protocol, dest port, dest addr} tuple)"

•  FlowID integer (e.g., 8-bit)"! the FlowID is unique for this FECFRAME instance ! required during decoding to assign recovered application

data units to the right source flow

70

Rapid technical overview… (cont') ! step 2: source block creation

1.  accumulate source packets 2.  prepend FlowID and Length, append padding 3.  submit the source block to the codec for encoding

!  step 3: FEC encoding !  as usual, nothing specific

71

Enc Symbol Length (E) < -------------------------------------------------------------- > +----+----+-----------------------+------------------------------+ |F[0]|L[0]| R[0] | Padding[0] | +----+----+----------+------------+------------------------------+ |F[1]|L[1]| R[1] | Padding[1] | +----+----+----------+-------------------------------------------+ |F[2]|L[2]| R[2] | +----+----+----------+-------------------------------------------+

3rd ADU

1st ADU

2nd ADU

Rapid technical overview… (cont') ! step 4: submit the following FEC source/repair

packets to the transport protocol ! for FEC source packet, append an explicit source FPI

•  with Reed-Solomon schemes, the source FEC Payload ID contains a block ID and symbol ID within this block"

! for FEC repair packet, prepend a repair FPI

•  with Reed-Solomon schemes, the repair FEC Payload ID contains a block ID, a symbol ID and a block length "

72

application data unit explicit source FEC payload ID (opt.)

repair symbol repair FEC payload ID

Proposed FEC schemes ! several FEC schemes are proposed ! RTP format for 1-D/2-D interleaved/non interleaved

parity FEC (Cisco) ! a very simple FEC scheme ! recovery capabilities remain limited however

! Reed-Solomon (Inria) ! LDPC-Staircase (Inria) ! Raptor/RaptorQ (Qualcomm)

73



74

The MBMS services ! Multimedia Broadcast Multicast Service (MBMS)

! point to multipoint specifications for 3GPP cellular networks ! heavily relies on IETF standards ! MBMS protocol stack has been reused with minor

modifications by other standards •  DVB-H/SH"•  ISDB-Tmm"

75

The MBMS services… (cont’) ! global view of MBMS protocol stack

76

carousel

IP

UDP

Streaming (RTP)

Download (FLUTE/ALC/AL-FEC)

RTP Payload formats

Codecs (Audio, Video, Speech,

etc.) AV file formats, Binary data, Still

images, Text, etc.

MBMS Bearer(s)

Service Announcement & Metadata (SDP,

XML, etc.)

Application(s)

FEC protection

al-fec and mbms servicesplanete.inrialpes.fr/.../comm_mobiles_2011-12_part3_2p.pdf ·...

Documents