A Fast Raptor Codes Decoding Strategy for Real-Time Communication Systems
Raptor codes Application Layer FEC - conf-icnc.org overview for ICNC... · • Raptor codes...
Transcript of Raptor codes Application Layer FEC - conf-icnc.org overview for ICNC... · • Raptor codes...
Raptor codes Application Layer FEC
Michael Luby
January 30, 2012 ICNC
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 between different networks to support multi-path data delivery
The Mobile Video Challenge
• The mobile video landscape • Mobile Internet use is dramatically
expanding • Video traffic is growing
exponentially & is a large fraction of the usage
• The challenges • Mobile users expect high quality
video experience • Network operators need to offer
quality experience affordably
Source: Cisco White Paper:
Cisco Visual Networking Index: Global Mobile Data
Traffic Forecast Update, 2009-2014
Figure 2
66% mobile
video by 2014
39 times growth of
mobile data
Raptor technology complements traditional error coding
“Erasure Coding” Protects against Data Lost
in Transmission
“Error Coding” Protects against Data Corruption
• Vast majority of current use of FEC • Probably what you’re familiar with • Typically applied at layers 1 or 2 • Usually performed in hardware • PHY-FEC (physical layer FEC)
• Commercial application relatively new • Applied above layer 2 • Complement to Error Coding • Typically performed in software • AL-FEC (application layer FEC)
Forward Error Correction Technology
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
Source data
Source data
Erasure encode
Erasure decode
Transmit (losses possible in reception)
Erasure Codes and AL-FEC
Packetize
Depacketize
Sender
Receiver
AL-FEC and PHY-FEC are complementary
Time
PHY-FEC Correct or discard corrupted packet data over small block Fixed time diversity Fixed amount of protection
AL-FEC Packet loss protection over small to large block Flexible time diversity Flexible amount of protection
Flexible time diversity – from sub-second to hours
Fixed time diversity – e.g., < 1 second
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-FEC works
PHY-FEC fails
16QAM CR = 1/3
5.3 Mbit/s p=14%
Source block Repair
AL-FEC Decoding
Source block AL-FEC
CR = 0.8 4.3 Mbit/s
p=0%
Erasure Coding Approaches
Reed-Solomon codes (1960, Reed and Solomon) Based on finite fields Systematic (strongly systematic) Has zero reception overhead Quadratic time in block size encoding and decoding (in practice)
Erasure Coding Approaches
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
Erasure Coding Approaches
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
Erasure Coding Approaches
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 whose contents are still a vibrant and useful contribution today
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
Generate as much encoding as desired Recover source from the minimal possible encoding
It doesn’t matter what is received or lost It only matters that enough is received
What is a fountain code?
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
Erasure Coding Approaches
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
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)
How Raptor codes work
• Raptor codes are fountain codes – Can efficiently generate as much encoding as desired, on the fly – Doesn’t 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
Source block B C E D A
LT encoding
Degree Prob
1 0.01
0.50 2
0.17 3
0.08 4
Degree Distribution
Source block
Insert header, and send
XOR source symbols
Choose degree = 2
Choose 2 random source symbols
B C E D A
B+D
LT encoding
Degree Prob
1 0.01
0.50 2
0.17 3
0.08 4
Degree Distribution
Source block B C E D A
Choose degree = 1
Choose 1 random source symbol
Copy source symbol
C
LT encoding
Insert header, and send Degree Prob
1 0.01
0.50 2
0.17 3
0.08 4
Degree Distribution
Source block
Insert header, and send
XOR source symbols
Choose 4 random source symbols
B C E D A
B+C+D+E
LT encoding
Degree Prob
1 0.01
0.50 2
0.17 3
0.08 4
Degree Distribution
Choose degree = 4
Source Block (unknown)
Collect enough encoded symbols and set up graph between encoded symbols and source symbols to be decoded
Belief propagation decoding
Identify encoded symbol with one unrecovered neighbor STOP if none exists
Source Block
Belief propagation decoding
Unrecovered source symbol value is the value of all recovered neighbors XORed into the encoded symbol value
B Source Block
Belief propagation decoding
Identify encoded symbol with one unrecovered neighbor STOP if none exists
B Source Block
Belief propagation decoding
Unrecovered source symbol value is the value of all recovered neighbors XORed into the encoded symbol value
B H Source Block
Belief propagation decoding
Identify encoded symbol with one unrecovered neighbor STOP if none exists
B H Source Block
Belief propagation decoding
Unrecovered source symbol value is the value of all recovered neighbors XORed into the encoded symbol value
B H D Source Block
Belief propagation decoding
B H D E A G F C Source Block (recovered)
Belief propagation decoding
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)
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 any number 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
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)
Raptor codes fountain flexibility
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 content Original content
Raptor codes fountain flexibility
Receive X % from Path 1
Receive (100-X) % from Path 2
No communication from client to server
Different speeds and loss on each path
Client Recovered content
Server Original content
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 loss Sym
bol o
pera
tions
per
out
put s
ymbo
l
RS encoding (n=255) RS decoding (n=255) Raptor encoding Raptor decoding
Reed-Solomon encoding/decoding
Raptor encoding/decoding
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 beyond K
Probability decoding fails
• K = number of source symbols in source block • Valid for all supported values of K • Valid for all loss probabilities: 1% to 99%
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
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
How organizations are using Raptor codes
• Content Delivery – Enterprise sends 30 GB+ database update weekly to 500 sites via satellite
broadcast network – Military broadcasts image data via private mobile communications in
foreign 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
Broadcasting content to mobile devices
Satellite or Terrestrial Delivery
Operations and Broadcast Center
Entertainment,
Communications & Navigation
Systems
Multimedia content, navigational content, etc.
Many, many Receivers
• 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
0
2
4
6
8
10
12
14
16
18
1 5 10 20
file size (MB)
99%
del
iver
y tim
e (h
ours
)
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%
del
iver
y tim
e (h
ours
)
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 data carousel method
Delivery time with Raptor codes is significantly better than data carousel methods
3GPP eMBMS – broadcast file delivery
BMSC
File
eMBMS broadcast service
UE
IETF RMT Broadcast/Multicast File Delivery
LCT BB RFC 5651
FEC BB RFC 5052
WEBRC BB RFC 3738
ALC PI RFC 5775
Reliable object delivery protocol instantiation
Reliability using FEC codes Framework and packet format Congestion control
FLUTE RFC 3926
Unidirectional broadcast/multicast reliable file delivery
FEC INFO RFC 3453
BB FRAME RFC 3048
BULK DATA RFC 2887
RaptorQ RFC 6330
Raptor RFC 5053
FLUTE file delivery
Partition file into source blocks FEC encode each source block independently
Place encoded symbols into FLUTE packets and transmit interleaved
…
FLUTE packet format
Identifies file Identifies 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
Unicast repair service uses standard HTTP requests
Proposed enhancement to 3GPP eMBMS
BMSC
File
eMBMS broadcast service
UE
HTTP web server
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?
• 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 movement between RAM and flash memory
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
All source symbols missing Request 4 source symbols 0-3
Source block
File with one source block and no sub-blocks Broadcast only repair symbols
Requested source symbols
0 1 2 4 5 6 7 8 3 9 10 11
Blue = received broadcast source symbols Red = received broadcast repair symbols White = missed or lost broadcast symbols
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
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 loss
patterns
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
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
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
Avg Loss - Test 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!
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 without
requiring 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, handheld
devices, etc.) – Provides longer battery life
• See www.qualcomm.com/raptorq for more information!
Thank you!