Raptor Overview for ICNC 30Jan2012 Distribute

7/28/2019 Raptor Overview for ICNC 30Jan2012 Distribute

1/60

Raptor codes

Application Layer FECMichael Luby

J anuary 30, 2012ICNC


2/60

Digital media delivery challenges today

Reliable and efficient content delivery is increasingly important Video streaming

Multimedia content delivery

High value need for efficient streaming and content delivery

methods across all networks (wireless and wired) and device types(servers, laptops, handhelds, etc.)

Content providers require consistent high quality-of-service (QOS)across all their distribution methods, delivered economically

Mobile and multimedia content delivery are booming

Content delivery over 3G, 4G, Wi-Fi increasing dramatically Broadcast over eMBMS is a potential emerging market

Some applications require complex synchronization betweendifferent networks to support multi-path data delivery


3/60

The Mobile Video Challenge

The mobile video landscape

Mobile Internet use is dramaticallyexpanding

Video traffic is growingexponentially & is a large fraction ofthe usage

The challenges

Mobile users expect high qualityvideo experience

Network operators need to offerquality experience affordably

Source:Cisco White Paper:

Cisco Visual Networking Index:Global Mobile Data

Traffic ForecastUpdate, 2009-2014

Figure 2

66%

mobile

video by

2014

39 times

growth of

mobile

data


4/60

Raptor technologycomplements traditional error coding

Erasure CodingProtects against Data Lost

in Transmission

Error CodingProtects against

Data Corruption

Vast majority of current use of FECProbably what youre familiar with

Typically applied at layers 1 or 2

Usually performed in hardware

PHY-FEC (physical layer FEC)

Commercial application relatively newApplied above layer 2

Complement to Error Coding

Typically performed in software

AL-FEC (application layer FEC)

Forward Error Correction

Technology


5/60

Packet transmission

Packet header

Packet payload

Stream of packets

Received corrupted packet

Can identify received packet payloads from packet headers

Received corrupted packet is discarded


6/60

Source data

Source data

Erasure encode

Erasure decode

Transmit (losses possible in reception)

Erasure Codes and AL-FEC

Packetize

Depacketize

Sender

Receiver


7/60

AL-FEC and PHY-FEC are complementary

Time

PHY-FECCorrect or discard corrupted packet data over small block

Fixed time diversity

Fixed amount of protection

AL-FEC

Packet loss protection over small to large blockFlexible time diversity

Flexible amount of protection

Flexible time diversity from sub-second to hours

Fixed time diversity e.g., < 1 second


8/60

AL-FEC and PHY-FEC working together

PHY-FEC corrects noise and interference

AL-FEC interleaves and corrects erasures

Longer block length (interleavers) better performance

PHY-FECworks

PHY-FEC

fails

16QAM

CR = 1/3

5.3 Mbit/s

p=14%

Source block Repair

AL-FEC

Decoding

Source blockAL-FEC

CR = 0.8

4.3 Mbit/s

p=0%


9/60

Erasure Coding Approaches

Reed-Solomon codes (1960, Reed and Solomon) Based on fini te fields Systematic (strongly systematic) Has zero reception overhead

Quadratic time in block size encoding and decoding (in practice)


10/60


LDPC codes (1960, Gallager) Based on regular random graphs Systematic (but not strongly systematic) Incurs a significant relative reception overhead for all block sizes Linear time in block size encoding and decoding


11/60


Tornado codes (1997, Luby et. al.) Based on irregular random graphs (the first irregular LDPC codes) Systematic (but not strongly systematic)Approaches zero relative reception overhead as block size grows

Linear time in block size encoding and decoding

2002 IEEE Information Theory Society paper award for design and

analysis of irregular LDPC error-correcting codes


12/60


LT codes (1998, Luby)The first practical fountain code Simpler irregular graph structure than Tornado Non-systematic Approaches zero relative reception overhead with growing block size Almost linear time in block size encoding and decoding 2009 ACM SIGCOMM Test of Time Award fountain code approach

to reliable distribution of bulk data outstanding paper whosecontents are still a vibrant and useful contribution today


13/60

Erasure codes with a rate

Source data

Erasure encode

Encoded data

Code rate = size of source data / size of encoded data

For non-fountain codes, for a fixed source data size Erasure code design is specifically for a given code rate Each code rate uses a different erasure code design

Particular encoded symbols are generated differently for different code rate Number of encoded symbols that can be generated is fixed by the design


14/60

Generate as much encoding as desired Recover source from the minimal possible encoding

It doesnt matter what is received or lost

It only matters that enough is received

What is a fountain code?


15/60

Erasure codes without a rate fountain codes

Source data

Erasure encode

Encoded data

Fountain codes have no predetermined rate

For fountain codes, for a fixed source data size Erasure code design is extendable to provide any code rate All code rates use the same extendable erasure code design

Particular encoded symbols are generated independently of one another Number of encoded symbols that can be generated on the fly is

unconstrained


16/60


Raptor codes (2001, Shokrollahi, et. al.) Based on LT codes Systematic (strongly systematic) Fountain codes Approaches zero relative reception overhead as block size grows Excellent recovery properties for all block sizes

Linear time in block size encoding and decoding 2007 IEEE Comm. Society/Information Theory Society paper

award Raptor codes


17/60

Raptor codes in standards

Raptor codes (IETF RFC 5053) Systematic fountain codes Linear time encoding and decoding Standardized 3GPP MBMS, DVB-H IPDC Good recovery properties like a random code over GF(2) Good flexibility

Up to 8,192 source symbols Up to 65,384 source + repair symbols

RaptorQ codes (IETF RFC 6330) Systematic fountain codes Linear time encoding and decoding Proposal to all future standards (IEEE P2200, 3GPP eMBMS, ) Great recovery properties like a random code over GF(256) Great flexibility

Up to 56,403 source symbols Up to 16,777,216 source + repair symbols (essentially unlimited)


18/60

How Raptor codes work

Raptor codes are fountain codes

Can efficiently generate as much encoding as desired, on the fly

Doesnt matter what is received or lost, only matters that enough is received

Can dynamically change the number of repair packets based on loss level

Raptor codes are systematic codes

Source code is part of the encoding

Raptor codes are used in an application specific manner

For content delivery encode the entire file as a block or a set of sub-

blocks if receiver memory is limited For streaming encode blocks of the stream

Also can be used at MAC layer to protect all data


19/60

Source

blockB C EDA

LT encoding

Degree Prob

1 0.01

0.5020.173

0.084

Degree Distribution


20/60

Source

block

Insert header, and send

XOR source

symbols

Choose degree = 2

Choose 2 random

source symbols

B C EDA

B+D

LT encoding

Degree Prob

1 0.01

0.5020.173

0.084

Degree Distribution


21/60

Source

blockB C EDA

Choose degree = 1

Choose 1 random

source symbol

Copy source

symbol

C

LT encoding


Degree Prob

1 0.01

0.5020.173

0.084

Degree Distribution


22/60

Source

block


XOR source

symbols

Choose 4 random

source symbols

B C EDA

B+C+D+E

LT encoding

Degree Prob

1 0.01

0.5020.173

0.084

Degree Distribution

Choose degree = 4


23/60

Source Block (unknown)

Collect enough encoded symbols and set up graph

between encoded symbols and source symbols to be decoded

Belief propagation decoding


24/60

Identify encoded symbol with one unrecovered neighbor

STOP if none exists

Source Block



25/60

Unrecovered source symbol value is the value of all recovered neighbors

XORed into the encoded symbol value

B Source Block



26/60


STOP if none exists

B Source Block



27/60



B H Source Block



28/60


STOP if none exists

B H Source Block



29/60



B HD Source Block



30/60

B HD EA GFC Source Block (recovered)


h i l i di f d


31/60

Some technical ingredients of Raptor codes

Ingredient (first code that incorporated ingredient)

LT code (Raptor RFC 5053)

Pre-coding (Raptor RFC 5053)

Inactivation decoding (Raptor RFC 5053)

Systematic construction (Raptor RFC 5053) Larger finite fields (RaptorQ RFC 6330)

Permanent inactivations (RaptorQ RFC 6330)


32/60

Raptor codes key properties

Dynamic packet loss protection Fountain codes which means rateless

No limit to number of encoding symbols (n) that can be generated from anynumber of source symbols (k)

Unlimited amount of loss protection possible

No pre provisioning required; everything on-the-fly

Exceptionally computationally efficient Linear complexity (encoding and decoding)

Quadratic complexity for Reed-Solomon IETF RFC 5510

Low transmission and reception overheads Good overhead for Raptor IETF RFC 5053

Essentially zero overhead for RaptorQ IETF RFC 6330

High and variable overhead for LDPC IETF RFC 5170


33/60

Raptor codes fountain flexibility

Send as many repair packets as needed

Source packets Repair packets (moderate loss)

Source packets Repair packets (high loss)

Source packets Repair packets (low loss)


34/60


Server 1 Server 2

Client

Receive X % from Server 1 Receive (100-X) % from Server 2

No communication from client to servers

No communication

between servers

Recovered content

Original contentOriginal content


35/60


Receive X %

from Path 1

Receive (100-X) %

from Path 2

No communication from client to server

Different speeds and loss on each path

ClientRecovered content

ServerOriginal content


36/60

Raptor codes computational complexity

In comparison to other typical alternative FEC technologies, Raptor

codes are an order of magnitude or more less complex

1

10

100

1000

0.0% 2.0% 4.0% 6.0% 8.0% 10.0% 12.0%

maximum packet lossSymbo

loperationsperoutputsymbol

RS encoding (n=255) RS decoding (n=255) Raptor encoding Raptor decoding

Reed-Solomon encoding/decoding

Raptor encoding/decoding


37/60

Raptor codes overhead

Raptor code (IETF RFC 5053)RaptorQ code (IETF RFC 6330)

10-0

10-1

10-2

10-3

10-4

10-5

10-6

0 2 4 6 8 10 12 14 16 18 20 22 24

Number of encoded symbols received beyondK

Probability

decoding

fails

K= number of source symbols in source blockValid for all supported values ofKValid for all loss probabilities: 1% to 99%


38/60

How to deploy Raptor codes

Raptor codes are versatile and simple to deploy Application Layer FEC does not require special hardware

Raptor codes software library is incorporated into the application

Encoding and decoding speeds are more than sufficient for all applications

Same software library for file transfer or data/video streaming applications

Software development kit with well-defined and tested APIs Point-to-point architecture

Encoder and Decoder pair

Same library for client/server, peer-to-peer, or broadcast deployments

Small footprint can be ported to many types of platforms

Encoder and Decoder libraries are less than 100KB each Library does not perform any floating-point operations

No memory allocation or other platform specific functionality

Extremely portable to essentially any platform


39/60

Why Raptor codes are used

Values of Raptor: Enhances user experience video quality and smooth playback

Allows Content Providers to have consistent high QOS across services

Allows applications not otherwise possible due to network limitations

Speeds-up data delivery with variable network conditions

Increases overall system efficiency: less bandwidth, lower power,simpler architecture for application development

Problems Raptor codes can address:

Provides high quality delivery even when packets are lost

Provides reliable delivery even when packets are lost Provides more predictable delivery time when delivery is over multiple

connections


40/60

How organizations are using Raptor codes

Content Delivery

Enterprise sends 30 GB+ database update weekly to 500 sites via satellitebroadcast network

Military broadcasts image data via private mobile communications inforeign countries

Cellular operator broadcasts news flashes and video clips

Navigation service provider broadcasts map updates to fleets of vehicles

Digital cinema distribution over broadcast satellite

Streaming

IPTV deployments in Asia and Europe on set-top boxes Military airborne operations stream live video feeds to ground troops

Ground sensor networks transmit data to central command centers

Point-to-point video conferencing

On-scene digital news video feeds over multiple 3G connections


41/60

Broadcasting content to mobile devices

Satellite orTerrestrialDelivery

Operations andBroadcastCenter

Entertainment,Communications

& NavigationSystems

Multimedia content,navigational content, etc.

Many, manyReceivers


42/60

Common transmission channel for all receivers

No feedback from receivers

Receivers are in various locations with varying conditions

None of the dynamic unicast channel protocols apply

No adjustment of modulation parameters

No adjustment of error-correction scheme

No ARQ of radio packets

No transmission power control

Application-layer unicast reliability protocols not applicable

No HTTP/FTP/TCP for file delivery No HTTP/TCP for streaming

No RTP with retransmit for streaming

Challenges of mobile broadcast


43/60

0

2

4

6

8

10

12

14

16

18

1 5 10 20

file size (MB)

99%d

eliverytime(hours)

DF

RaptorDF

Raptor

DF

Raptordata

carouselDF

Raptor

data

carousel

data

carousel

data

carousel

960 kbps data broadcast

10% packet loss

user availability is random

-- on once each 6 minutes

-- on-time average =15 seconds

-- on-time std dev ~13 seconds

0

2

4

6

8

10

12

14

16

18

1 5 10 20

file size (MB)

99%d

eliverytime(hours)

DF

RaptorDF

Raptor

DF

Raptordata

carouselDF

Raptor

data

carousel

data

carousel

data

carousel

960 kbps data broadcast

10% packet loss

user availability is random

-- on once each 6 minutes

-- on-time average =15 seconds

-- on-time std dev ~13 seconds

Raptor codes versus traditional datacarousel method

Delivery time with Raptorcodes is significantly betterthan data carousel methods


44/60

3GPP eMBMS broadcast file delivery

BMSC

File

eMBMS broadcast service

UE

IETF RMT Broadcast/Multicast File Delivery


45/60

IETF RMT Broadcast/Multicast File Delivery

LCT BBRFC 5651

FEC BBRFC 5052

WEBRC BBRFC 3738

ALC PI

RFC 5775

Reliable object delivery

protocol instantiation

Reliability using FEC codesFramework and packet format Congestion control

FLUTERFC 3926

Unidirectional broadcast/multicast

reliable file delivery

FEC INFO

RFC 3453

BB FRAMERFC 3048

BULK DATARFC 2887

RaptorQRFC 6330

RaptorRFC 5053

FLUTE file delivery


46/60

FLUTE file delivery

Partition file into source blocksFEC encode each source block independently

Place encoded symbols into FLUTE packets and transmit interleaved

FLUTE packet format


47/60

FLUTE packet format

Identifies fileIdentifies source

block of file

Identifies encoded

symbol(s) of source

block

One of more symbols as

identified by TOI, SBN and

ESI

FEC Payload ID


48/60

Unicast repair serviceuses standard HTTP requests

Proposed enhancement to 3GPP eMBMS

BMSC

File

eMBMS broadcast service

UE

HTTP web server


49/60

Hybrid service deployment

Use standard HTTP web servers as repair servers

UEs receive data for file from eMBMS broadcast session UE can determine HTTP byte range requests for missing source

symbols based on FEC OTI and received source symbols

UE makes requests to receive missing source symbols

Amount of HTTP data requested for each source block = source block

size - amount of broadcast data received for that source block

What to broadcast?


50/60

What to broadcast?

Broadcast only repair symbols non-intuitive, but

Simplifies HTTP byte range requests to initial prefixes of blocks Few HTTP byte range requests required for unicast repair

independent of loss patterns

High caching efficiency each UE will have the same request pattern

Easy to deploy hybrid HTTP/broadcast use cases Raptor/RaptorQ decoding very efficient

resource usage dominated by non-FEC decoding operations such as data movementbetween RAM and flash memory

Broadcast only repair symbols


51/60

Broadcast only repair symbols

BMSC

HTTP web

server

File

UE

Broadcast repair symbols only

Red = received broadcast repair symbols

White = missed or lost broadcast symbols

Received broadcast symbols

HTTP web server

Fil ith bl k d b bl k


52/60

All source symbols missing

Request 4 source symbols 0-3

Source block

File with one source block and no sub-blocksBroadcast only repair symbols

Requested source symbols

0 1 2 4 5 6 7 83 9 10 11

Blue = received broadcast source symbols

Red = received broadcast repair symbols

White = missed or lost broadcast symbols


53/60

Example

File size 20 MB

Packet payload size = 1,024 bytes Encoded as 20 source blocks

Source block size = 1 MB

1,024 source symbols per source block

20,480 source symbols in the file Suppose UE receives 19,000 packets from the broadcast

UE needs to request 1,480 source symbols

This is approximately 1.5 MB of unicast repair data


54/60

Unicast repair requests

Low HTTP request and response overhead & simple request pattern Number of requests = #source blocks independent of loss and pattern of loss

20 HTTP byte range requests for prefixes of the 20 source blocks

High caching efficiency

Different UEs make completely overlapping requests

Pattern of requests from different UEs independent of individual UE losspatterns

Summary of approach and benefits


55/60

Summary of approach and benefits

Hybrid Internet and eMBMS services

Allows using standard HTTP web servers as repair servers Allows advanced hybrid Internet/eMBMS services not otherwise possible

Allows eMBMS to be used as a traffic offload service for Internet content

Allows Internet infrastructure to provide eMBMS unicast repair functionality


56/60

Hostile and challenging conditions

Intermittent connectivity blocking or loss of any particular source Stealth receivers unidirectional reliability

Ad-hoc network moving transmitters and receivers

Multilink reception of different packets over different links

Rapidly and widely varying network conditions

Defense Communications
http://www.fas.org/irp/program/collect/991973a.jpghttp://www.fas.org/irp/program/collect/991973a.jpg


57/60

High QOS Video over Wired or Wireless:Entertainment, Conferencing or Surveillance

over Imperfect

Networks

IP Network over

FTTP, DSL, or

Wireless

Raptor Protected

Steady & Crisp Audio & Video

Loss can exceed 15% or more

Low latency

Low processing overhead

over Imperfect

Networks

IP Network over

FTTP, DSL, or

Wireless

Unprotected Video

Compression compounds

impact of errors

Block errors

Buffering

Video and Audio loss

Airborne Networking Example
http://images.google.com/imgres?imgurl=www.computerpartners.co.uk/images/compaq%20rack.jpg&imgrefurl=http://www.computerpartners.co.uk/hosting.htm&h=255&w=200&prev=/images?q=rack+computer&svnum=30&hl=en&lr=&ie=UTF-8&sa=Nhttp://images.google.com/imgres?imgurl=www.computerpartners.co.uk/images/compaq%20rack.jpg&imgrefurl=http://www.computerpartners.co.uk/hosting.htm&h=255&w=200&prev=/images?q=rack+computer&svnum=30&hl=en&lr=&ie=UTF-8&sa=N


58/60

Avg Loss - T est 4

0

10

20

30

40

50

60

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

%

Airborne Networking Example

Video Streaming Over an Airborne Network

No protection 25% Raptor codes protection

Robust Protection of Streaming Data!


59/60

Raptor codes benefits and advantages

Efficiency Dramatic link margin improvement

Exceptionally fast encoding and decoding algorithms (scalable)

Error-free delivery over any data network and recovering lost data packets withoutrequiring re-transmission from the sender

Good combination of PHY-FEC and AL-FEC optimizes overall efficiency

Flexible - operates ideally in a huge range of network conditions

Multi-link/multi-network architecture High/unknown/variable loss

Large latencies

Intermittent connectivity

Broadcast channels with no back channel

Superior mobile receiver operations

Implemented in host software without any special hardware support Consistent low CPU decoding complexity

Suitable for low cost and low power consumer devices (mobile phones, handhelddevices, etc.)

Provides longer battery life

See www.qualcomm.com/raptorq for more information!
http://www.qualcomm.com/raptorqhttp://www.qualcomm.com/raptorq


60/60

Thank you!

Raptor Overview for ICNC 30Jan2012 Distribute

Documents

Transcript of Raptor Overview for ICNC 30Jan2012 Distribute