Broadcas(ng Video in Dense 802.11g Networks Using Applica(on FEC and Mul(cast  

Dr James Martin School of Computing Clemson University

Clemson, SC jim.martin@cs.clemson.edu

1

Last update: 5-27-2011

Dr James Westall School of Computing Clemson University

Clemson, SC westall@cs.clemson.edu

Rahul Amin ECE Department

Clemson University Clemson, SC

ramin@clemson.edu

Talk Overview  

•  Introduc(on 

•  Problem Statement 

•  Background 

–  Video Streaming   –  Applica(on Level FEC –  APFEC over Wireless 

•  Research Objec(ves 

•  Methodology 

•  Results and Conclusions •  Next Steps 

•  Appendix 

2

Introducing…crowd spots •  A  crowd spot involves hundreds, thousands, or tens of thousands of 

people (and wireless devices) temporarily grouped together in dense forma(on. 

–  Drivers:   deployment of smartphones, availability of infrastructure 

–  Of par(cular interest are sports and entertainment venues •  802.11 has supported large events since the early 1990’s.  

–  Many studies point out the deficiencies of 802.11b – it does not scale. •  Several works found many handoffs cause service interrup(on without ever moving 

the user (the device connects back to the same AP >50% of the (me in one study) 

•  Crowd spots supported on managed networks  –  NASCAR events provide handheld device video using Sprint’s licensed 

spectrum 

–  Clemson University to get a Distributed Antenna System (in (me for the first football game) 

3

Problem Statement •  Renewed  interest in using 802.11 to support crowd spots 

–  Wireless carriers want to offload broadband traffic onto WiFi 

–  Venue owners would like to use the new medium (increase sales, engage fans)  

•  For this study we focus on sports stadiums and assume the driving applica(on is video –  To scale to hundreds of users per Access Point, mul(cast is required 

•  Recent advances in applica(on level forward error correc(on makes highly efficient coding available to devices 

•  Problem Statement:   1.  What are the limits of this system?  What are the sensi(ve parameters?  How can we 

find the ‘op(mal’ system seengs?  2.  Develop a dynamic algorithm that keeps the system opera(ng so as it can provide 

predictable levels of service quality. 

 In this research presented in this paper, we address problem #1 

4

Background:  Video Streaming •  Preparing the data…. 

1.  Produce Raw Video 2.  Encode into the desired format (MPEG2, MPEG4, H.264) 3.  Place encoded content into the desired container (flash, MPEG2 ts or ps, mp4, quickTime,or 3GPP) 

•  Streaming mechanisms and protocols 1.  UDP mul(cast or unicast based on RTP and RTSP  (note: can think of RTP as a container) 

2.  TCP and HTTP •  HTTP5: The browser must have its own decoder (does not require a player) •  Nellix uses Microsom SilverLight (might be moving to HTTP5?) •  Apple’s IOS and Nellix/Hulu use HTTP live streaming to smartphones: This is NOT progressive 

download and NOT HTTP5 streaming: 

–  Content encoded at different rates and image dimensions using H264 (or something else) 

–  Data chopped into 10 Byte chunks and sent via HTTP –  Viewer can only see the chunks it has‐  en(re content is difficult to save –  System constantly trying to increase or decrease the quality of the content to adapt to 

changing network condi(ons. 

•  Progressive download‐ file is transferred to the client device, however it is rendered early in the transfer. 

•  Streaming models: –  Live, con(nuous stream (linear) 

–  On‐demand, the stream comes from a file and poten(ally can be paused, rewound, forwarded 5

Background: Forward Error Correc(on 

•  Typically described by (N,K).  The source data is broken up into K symbols.  N‐K amount of correc(on data is added.  Code rate is K/N.  

•  An (N,K) allows the code to recover up to N‐K lost symbols.   

–  The FEC effec(veness  depends on the loss process and the choice of N and K 

•  Simple example:  Repe((on Code (5,1) 

–  Symbol size: 5 bits (N),  1 (k) bit of source info sent: 

•  0 ‐> 00000 •  1 ‐> 11111 •  The decode receives 5 bits and counts the # 1s.  If there are 3 or more, it selects 1, 

else 0. •  Very inefficient: coding rate is 1/5 (400%) 

•  Very robust: can correct up to 2 bits errors per block 

6

Forward Error Correc(on •  Coding dates back to Shannon… 

–  He theorized that ECC can support error free transmission approaching the ‘shannon capacity’ of the channel (upper bound of max informa(on that can reliably be sent over a channel subject to a given level of noise) 

•  Reed‐Solomon ‐  used in CD‐ROM/DVDs and many MAC layer protocols (e.g., DOCSIS cable and WiMAX).  –  Erasure code means that when a symbol is dropped the code knows the exact loca(on in 

the sequence.  An ‘error’ is a drop and the  loca(on is unknown. –  Systema(c:  means the original source data (k symbols) are directly sent in the block 

–  NOT computa(onally efficient – requires hardware assist 

•  Newer codes allow a symbol to be a packet.  Raptor codes allow K up to 8K packets where N>K and N< 64K packets.  To address computa(onal complexity as the block size increases,  an allowed probabilis(c failure rate can be added. (1+e)K packets must be received in order of all k packets to arrive. 

7

Modeling Applica(on Based Forward Error Correc(on 

•  For a given APFEC system parameterized by N,k •  The coding rate is k/N,  referred to as r 

•  Let 1‐r represent the redundancy  (N‐k)/N 

•  Let p represent the long term loss rate of the network 

•  Let p’ represent the long term loss rate experienced by the flow AFTER APFEC  

•  Assuming ideal  coding such as Reed‐Solomon (RS) 

•  And if we assume uncorrelated packet loss in the network, we expect: 

–  If (1‐r)>p, then p’ 0 as N goes to infinity 

–  If (1‐r)=p, then p’p as N goes to infinity 

–  If (1‐r)<p, then p’‐>p/2 as N goes to infinity 

•  If we assume correlated packet loss, then it depends on the details of the process (e.g., the intensity and level of correla(on or loss events). –  In general, you want to operate the system so that  r is larger than p…..  

–  In addi(on, a larger block size offers bever correc(on capability, however this causes packet delay to grow 

–  Given that p is likely to change over (me, the op(mal system adapts based on current condi(ons 

8

APFEC over Wireless   

•  Most of the prior work in this area have studied channel models  – Bernoulli error model – Two‐state markov model (Gilbert‐Elliot) 

•  Assessing the effects of correlated loss on FEC – Mean Burst Loss metric  

9

APFEC over Wireless   

•  Mean Burst Loss metric  

10

Methodology •  Extended ns2 to support mul(cast, APFEC, and several performance monitors 

–  Assess level of correlated loss 

•  Fits the parameters of a two‐state markov chain error model 

–  APFEC Effec(veness 

–  Ar(fact assessment 

•  Determines the ability of the system to supply a video player with a minimum level of BW demand but taking into account the impact of large output playback buffer seengs. 

•  In the literature an ar(fact is defined as an outcome‐ a ‘glitch’ observed by the end user in the video rendering that is caused by some sort of distor(on to the received stream.  Example ar(facts include: blurring, blocking, color distor(on, or more commonly with Internet video, a pause as the playback buffer refills. 

11

The Most Famous Ar(fact…. 

12

Stream of UDP packets 

APFEC ‐ coder Video streaming encoder 

Network 

Stream including redundant informa(on 

Video content (avi, mp4) 

1234512345r1 

APFEC ‐decoder 

Stream – possibly lost packets 

1 3 4 5 r1 

1 3 4 52 

Video streaming decoder 

Performance assessment (loss rate, latency, jiver) 

Video quality assessment (PSNR, mean (me between ar(facts) 

Applica(on FEC Model 

13

FEC Send Side 

FEC Rx Side 

CBR traffic generator 

CBR traffic generator 

Simula(on Model 

14

1Gbps, .5ms prop delay

6 Mbps basic rate 54 Mbps- 1 Mbps data rate AP router Wired Server Node

1Gbps, prop delay: varied

Monitor flow (DS and US)

Unicast Flow 1

Monitor Server Node

Distance between AP and ALL wireless nodes is either 10 M or 60 M

AP FEC Source #1

Artificial packet loss Background Traffic Nodes

Monitor Station

Background Traffic Nodes

Unicast background traffic (DS or US)

AP FEC Source #2

Streaming Server Node

Multicast Flow 1

Unicast Flow 2

Multicast Flow 2

Wireless Nodes with AP FEC sink and streaming viewer

Node 1- Video session traced

Methodology 

•  Baseline analysis – Experiments 1‐5 

•  Channel Impairment analysis 

•  Conges(on analysis 

15

Experiment Defini(on: Per Flow Metrics 

16

• Coding rate: describes the FEC parameters as the ratio of k/N • Redundancy: describes the relative amount of redundant data that is added (1-k/N) • Effective loss rate: Receiver’s estimate of loss count / Receiver’s estimate of total amount of data (including FEC) sent • Effectiveness: 1 – (effective loss rate / raw loss rate) • Packet latency: end-to-end latency averaged for all packets in the flow • Packet jitter: end-to-end jitter averaged for all packets in the flow • Throughput: application throughput experienced by the flow • Mean burst loss length (MBL) metric and interloss distance (ILD) metric as defined in the “Forward Error Correction Strategies for Media Streaming Over Wireless Networks” paper (A. Nafaa, et. Al., IEEE COM Magazine, Dec 2007). • Application oriented assessments

• PSNR • Mean Time Between Artifacts

Experiment Defini(on: Simula(on Parameters 

17

• FEC: N, k • Path properties (RF, artificial loss process, path loss, fading effects, channel interference) • Stations: number, location, movement • Workloads

• Background traffic • Traffic under observation

EXP3xy Defini(on 

18

Experiment  FEC parameters  Flows  under observa(on  Background traffic 

Loss process 

311 (#1) Vary blockSize (#1 below), fixed

redundancy 0.20 5 downstream CBR flows (768Kbps, packetsize 1400) none Bernoulli, vary loss (#2

below)

321 (#2)

Vary blockSize (#1 below), fixed redundancy 0.20 5 downstream CBR flows

(768Kbps, packetsize 1400) none Gilbert-Elliot, vary loss (#2

below) by varying state duration (#3 below)

351 (#3,4) Vary blockSize (#1 below), fixed

redundancy 0.20

5 multicast streams (see note 1) (768Kbps, packetsize 1400)

Also ran with 1 stream/1 station none Gilbert-Elliot, vary loss (#2

below) by varying state duration (#3 below)

381 Vary blockSize (#1 below), fixed

redundancy 0.20 5 multicast streams (see note 1)

(768Kbps, packetsize 700) none Gilbert-Elliot, vary loss (#2

below) by varying state duration (#3 below)

361 Vary blockSize (#5 below), fixed

redundancy 0.20

5 downstream CBR flows (768Kbps, packetsize 1400) none

Gilbert-Elliot, fix loss, vary level of correlation (#4

below)

371 #5) Vary blockSize (#5 below), fixed

redundancy 0.20

5 multicast CBR streams (768Kbps, packetsize 1400) none

Gilbert-Elliot, fix loss, vary level of correlation (#4

below) 1.  BlockSizes (N,k) (fixed code rate 0.20): (5,4), (10,8), (20,16), (40,32), (80,64), (160,128) 2.  Long term loss rates: 0.10, 0.12, 0.14, 0.16, 0.18, 0.20 3.  Gilbert-Elliot (varying rates) avg good run length : avg bad run length: (225:25), (182.5:25), (153.5:25), (131.5:25), (113:25), (100:25) 4.  Gilbert-Elliot (fixed loss 0.14, vary run lengths for HUGE correlation: (153.5,25), (460.7,75), (767.9,125), (1075,175), (1382.1,225), (1689.3,275) 5.  BlockSizes (N,k) (fixed code rate 0.20): (20,16), (40,32),(80,64), (160,128), (320,356), (640,512))

Note 1: we configured this two ways. First, with 25 stations, 5 multicast groups, 5 members per group. Second, a single multicast flow with 1 station. These two configurations are referred to as ‘original’ and ‘modified’

a. Bernoulli loss model c. Bernoulli loss model

b. GE loss model d. GE loss model

a. 5 Multicast Flows c. 5 Multicast Flows

b. 1 Multicast Flow d. 1 Multicast Flows

a. Multicast APFEC Effectiveness

c. Multicast Average Packet Latency

b. Multicast MBL Metric

Results and Analysis •  Expected results: 

–  If (1‐r)>p, then p’ 0 as N goes to infinity 

–  If (1‐r)=p, then p’p as N goes to infinity 

–  If (1‐r)<p, then p’‐>p/2 as N goes to infinity •  Observed results confirm this‐ as long as N is large enough, we can expect APFEC to correct some to all 

errors (over a reasonable range of correlated loss) 

•  Need to obtain the ar(fact metric results to assess the impact of large N and large playback buffer sizes. 

22

Conclusions •  What are the limits of this system?  

•  Aggregate management and mul(cast traffic must not exceed x% of the basic rate as it will greatly interfere with unicast.  Therefore, the system can only support a limited number of individual mul(cast streams. There is a fairness issue here that needs to be explored. 

•  How well the system scales in terms of the number of users depends on the ‘chaver’ generated or consumed by the sta(ons.  This aspect of the study is not yet complete. 

•  What are the sensi(ve parameters?   •  The configurable parameters that have the most impact are the encoding rate, the choice of (N,K), 

and the playback buffer size 

•  The loca(on of the sta(ons and underlying propaga(on effects determine performance •  The aspect of the study that explores the choice of modulaAon and coding is not yet complete. 

•  How can we find the ‘op(mal’ system seengs?  –  Star(ng Point: 

•  N‐K should  be larger than 1/MBL •  K should be larger than 1/MILD  

–  Adapta(on: •  Minimize the latency by keeping N small •  Minimize the APFEC effec(veness by increasing N 

–  This needs to be further developed 

23

Conclusions •  Conjecture (need to prove this): the limi(ng factor in dense 802.11 deployments is: 

–  The intensity of loss either due to propaga(on, interference, or network conges(on. •  If this is true, then solu(ons might include: 

–  Priori(ze mul(cast channel access (require the range of unicast DIFS/SIFS delays to be larger than those used for mul(cast transmissions) 

–  Combine 802.11 with 3G/4G to increase the reliability 

24

Appendix 

•  WifiTest Tool 

25

Problem: Finding the Op(mal (N,k) 

•  System parameters that come into play: 

–  Number and loca(on of users 

–  Topology/propaga(on which defines the loss process characteris(cs (mean loss rate, correla(on structure) 

–  Video stream avributes (encoding rate, compression factor, decoder resiliency to loss,  CBR/VBR delivery,  client playback buffer. size 

•  Basic rules  

–  Star(ng Point: 

•  N‐K should  be larger than 1/MBL 

•  K should be larger than 1/MILD  

–  Adapta(on: 

•  Minimize the latency by keeping N small 

•  Minimize the APFEC effec(veness by increasing N 

26

Tool 

•  Sender:  sends a video stream in a manner that emulates a video stream.  Parameters: – Packet size,  sending rate (mean and variability), compression factor (e.g.,  on average the raw stream is compressed by this factor). 

•  Receiver:  receives the stream.  Periodically (or at the end of the test), computes: – Loss rate sta(s(cs, including the distribu(on of loss runs 

– Guidance for op(mal choice of (N,k) 27

WiFi Test Tool •  Results 1:  receiver located 200 feet away from home AP – located outdoors behind a few 

bushes/trees.  Avg loss rate 75% •  Results 2:   receiver located 200 feed away but in less obstructed path. Avg loss rate 6.5%. 

•  Reference point:   The simula(on (using a version of the tool that runs in simula(on) :  Simula(on run is 5 mul(cast sessions with ar(ficial loss ac(ve (experiment 3 in paper 2, see Figure 4):   –  Average loss rate=0.14 (goodRun,lossRun): (153.5,25.0)   

–  (N,k): ( 40,32)   (redundancy : 0.20) 

28

Results 1 (MBL:1.52) 

29

Result 2 (MBL:1.43) 

30

Reference Point: Simula(on Result (MBL 4.22) 

31

Results 1 

32

plotLossMetrics plotLossMetrics: plotFlag:1, oldFileName:wifiTestData.1, newFileName:LMVideoTraceArrived.out procLossMetrics: File size: 37684, Number of samples: 37684, TotalTime:8.090990e+02, field#:5 procLossMetrics: MBLMetric i:189, numerator:12315.000000, sum:8089.000000 SampleSize:37684, Interarrival Times stats: /nMean:21470.622864, median:12116.000000, std:35709.363680, max,min:3110062.000000,min:0.000000 procLossMetrics: total bytes:615750000.000000, total time:809.098952, BW: 6088254.085392 procLossMetrics: Loss process results: /nloss rate:0.754, #drops:12315, lossRate2:0.607, JitterDrops:11 procLossMetrics: Numbergaps:8089, avgGapSize:1.522, avgGapSizeCount:8089, maxLossRun:189, maxGoodRun:61 procLossMetrics: MBLMetric: 1.522 (maxLossRun:189), ILDMetric: 4.805 (maxGoodRun:61) plotLossMetrics: Returned from procLossMetrics: PSR:0.000, TotalLR:0.754, LR2:0.607, CorrCoeff:0.000, MBLM:1.522, MILDM:4.805

Reference Point: Simula(on Result 

33

plotLossMetrics plotLossMetrics: plotFlag:1, oldFileName:wifiTestData.1, newFileName:LMVideoTraceArrived.out procLossMetrics: File size: 21950, Number of samples: 21950, TotalTime:3.004899e+02, field#:5 procLossMetrics: MBLMetric i:37, numerator:3799.000000, sum:899.000000 SampleSize:21950, Interarrival Times stats: /nMean:13689.743098, median:11587.000000, std:14978.364316, max,min:426991.000000,min:0.000000 procLossMetrics: total bytes:5558000.000000, total time:300.489861, BW: 147971.714759 procLossMetrics: Loss process results: /nloss rate:0.148, #drops:3799, lossRate2:0.129, JitterDrops:0 procLossMetrics: Numbergaps:899, avgGapSize:4.226, avgGapSizeCount:899, maxLossRun:37, maxGoodRun:188 procLossMetrics: MBLMetric: 4.226 (maxLossRun:37), ILDMetric:24.729 (maxGoodRun:188) plotLossMetrics: Returned from procLossMetrics: PSR:0.000, TotalLR:0.148, LR2:0.129, CorrCoeff:0.000, MBLM:4.226, MILDM:24.729

Result 2 

34

plotLossMetrics plotLossMetrics: plotFlag:1, oldFileName:wifiTestData.1, newFileName:LMVideoTraceArrived.out procLossMetrics: File size: 46277, Number of samples: 46277, TotalTime:8.094157e+02, field#:5 procLossMetric: total:49998, highestSeqNumber:49998, lossCount:3721, JitterLoss Effect: :0 procLossMetrics: MBLMetric i:143, numerator:3721.000000, sum:2612.000000 SampleSize:46277, Interarrival Times stats: Mean:17490.669555, median:12106.000000, std:24557.829374, max,min:2371746.000000,min:0.000000 procLossMetrics: total bytes:5209400.000000, total time:809.415715, BW: 51488.004529 procLossMetrics: Loss process results: loss rate:-0.000, #drops:3721, lossRate2:0.000, JitterDrops:0 procLossMetrics: Numbergaps:2612, avgGapSize:1.425, avgGapSizeCount:2612, maxLossRun:143, maxGoodRun:200 procLossMetrics: MBLMetric: 1.425 (maxLossRun:143), ILDMetric:18.354 (maxGoodRun:200) plotLossMetrics: Returned from procLossMetrics: PSR:0.000, TotalLR:-0.000, LR2:0.000, CorrCoeff:0.000, MBLM:1.425, MILDM:18.354 >>