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

Transcription

1 Broadcas(ng Video in Dense g Networks Using Applica(on FEC and Mul(cast Last update: Dr James Martin School of Computing Clemson University Clemson, SC Dr James Westall School of Computing Clemson University Clemson, SC Rahul Amin ECE Department Clemson University Clemson, SC 1

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, move towards mul( modal devices, availability of infrastructure Of par(cular interest are sports and entertainment venues has supported large events since the early 1990 s. Many studies point out the deficiencies of b 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 society is evolving. Satellite to mobile devices early form of the concept NASCAR events provide handheld device video using Sprint s licensed spectrum (now considered outdated Wireless carriers recognize the need to support crowd spots one way is to offload applica(on data onto WiFi. Economic models are being invented.. 2

3 Problem Statement 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 efficient coding feasible on hand held 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 sedngs? 2. Develop a dynamic algorithm that keeps the system opera(ng so as it can provide predictable levels of service quality. In the research presented in this talk we address problem #1 3

4 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 Our work assumes an ideal, modern coder such as one based on Raptor codes (we assume the receiver overhead that can provide a balance between computa(onal complexity and APFEC effec(veness is 0) 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/2 as N goes to infinity If (1 r)<p, then p >p 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 1 r is larger than p In addi(on, a larger block size offers beler correc(on capability, however this causes packet delay to grow which requires a larger playout buffer which increases the channel zapping (me Given that p is likely to change over (me, the op(mal system adapts based on current condi(ons 4

5 Simula(on Model Monitor Server Node MBL Monitor flow Monitor Station Artificial packet loss Background Traffic Nodes Unicast background traffic (DS or US) Background Traffic Nodes Wired Server Node 1Gbps, prop delay: varied router 1Gbps,.5ms prop delay AP 6 Mbps basic rate 54 Mbps Distance between AP and ALL wireless nodes is either 10 M or 60 M AP FEC Source #1 Unicast Flow 1 Unicast Flow 2 Multicast Flow 1 Node 1- Video session traced AP FEC Source #2 Multicast Flow 2 Streaming Server Node Wireless Nodes with receive side APFEC, playback buffer, and viewer

6 Performance Metrics Es(mate the level of correlated loss More specifically, the MBL es(mates the 1/r parameter assuming the loss process can be modeled by a twostate GE model APFEC Effec(veness 6

7 Performance Metrics Latency: The average one way, end to end latency of UDP packets sent by the video server corresponding to a stream. The metric can be specific to one stream or the average of mul(ple streams Ar(fact assessment: all based on a trace of packets delivered to the streaming viewer (i.e., aner APFEC). The trace is divided into intervals of fixed (me dura(on (e.g., 20 seconds). 1. Loss Tolerance Ar(fact (LTA): The loss rate is computed for each interval. An ar(fact occurs each (me the loss rate of an interval exceeds a threshold (e.g., 2%). The LTA es(mates the number of intervals that are in error per hour. 2. Minimum Throughput Ar(fact (MTA): The arrival rate of the stream under observa(on is computed for each interval. An ar(fact occurs each (me the throughput observed in an interval is less than a threshold (e.g., 75% of the long term video encoding rate). The MTA es(mates the number of intervals that are in error per hour. 3. Playback Buffer Deple(on Ar(fact (PBDA): Provides a measure of sustained throughput loss that is with respect to the size of the playback buffer. For (me scales of mul(ple intervals, we es(mate the amount of (me a playback buffer can support the outage. Once depleted, we assume a channel zap amount of (me to fill the buffer. The PBDA assesses how frequently this occurs. 4. Channel Zapping Time: the amount of (me it takes to fill the playback buffer. 7

8 a. Bernoulli loss model c. Bernoulli loss model b. GE loss model (1/r = 25 packets) d. GE loss model Baseline Analysis 8

9 a. 5 Multicast Flows c. 5 Multicast Flows b. 1 Multicast Flow d. 1 Multicast Flow Baseline Analysis

10 a. Channel Zapping Time (seconds) b. Average Packet Latency (seconds) 10 Baseline Analysis 10

11 a. APFEC Effectiveness: Vary Block Size c. Raw Loss Rate: Vary Block Size b. APFEC Effectiveness: Vary Redundancy (N=640) d. Mean Packet Latency: Vary Block Size Baseline Analysis (fixed loss rate) 11

12 a. Shadowing Model (30 meters) c. Ricean Model (30 meters) b. Ricean Model (60 meters) d. Ricean Model (50 meters) Impact of channel models 12

13 Conclusions If the goal is to support hundreds of mul(cast viewers in dense deployments, the crucial factors: Bandwidth alloca(on of basic rate to data rate (there s a fairness issue here.) Adap(ve FEC / Video distribu(on system challenging as mul(cast is involved Very difficult to assess how the network is behaving. Best way is to (e the assessment to the resource alloca(on plane. Ideas for going forward 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 with 3G/4G to increase the reliability. Next steps Con(nue developing a mul(cast streaming assessment/predic(on tool based on measured data it provides guidance on the best choice of (N,k). Need MBL data points from a large scale crowd spot Develop the adapta(on algorithm 13

14 What have we missed??? Adapt analysis so that correla(on is quan(fied in units of (me rather than packets Interleaving (not sure if it s required.depends on the extent of the correlated loss) n the network will benefit from the improved RF capabili(es. Other aspects of n that help? Any relevant IETF or IEEE work? 14