mpc-based delay-aware fountain codes for real-time video ... · include google’s project loon and...

10
2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information. This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet of Things Journal 1 MPC-based Delay-Aware Fountain Codes for Real-Time Video Communication Kairan Sun, Student Member, IEEE, Huazi Zhang, Member, IEEE, Dapeng Wu, Fellow, IEEE, and Hongcheng Zhuang Abstract—With the prevalence of smart mobile devices and surveillance cameras, the traffic load within the Internet of Things (IoT) has shifted away from non-multimedia data to multimedia traffics, particularly, the video content. However, the explosive demand for real-time video communication over wireless networks in IoT is constantly challenging both video coding and communication research communities. The state-of- the-art answer to this challenge is sliding-window-based Delay- Aware Fountain (DAF) codes, which combine the channel- adaptive feature in rateless coding and the delay-aware feature in video coding. However, the high computational cost and large delay make it impractical for real-time streaming. To address this issue, we integrate the Model Predictive Control (MPC) technique into DAF codes, so the complexity is lowered to an affordable level so that real-time video encoding is supported. Two schemes are developed in this paper: (i) DAF-S, the small-horizon DAF codes, and (ii) DAF-O, the MPC-based DAF using video bit rate prediction. The advantages of both designs are validated through theoretical analysis and comprehensive experiments. The results of simulation experiments show that the decoding ratio of DAF-S is close to the global optimum in DAF codes, and higher than the other existing schemes; DAF-O outperforms the state-of-the-art real-time video communication algorithms. Index Terms—Wireless networks, Fountain codes, Video com- munication, Model predictive control. I. I NTRODUCTION Internet of Things (IoT) has witnessed the explosive growth of video traffic over the recent decade, especially after the prevalence of smart mobile devices and surveillance cameras. At the same time, IoT nowadays relies more and more on wireless networks. The most ambitious on-going projects include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies wirelessly, making it ubiquitous around the globe. Because IoT devices with video-based applications provide the high accuracy and convenience that no simple sensor in the past can provide, innovative applications of real-time video communication over wireless networks could touch people’s lives in profound and different ways. For example, it can K. Sun is with Department of Electrical and Computer Engineering, University of Florida, Gainesville, FL 32611, USA. D. Wu is with Department of Electrical and Computer Engineering, University of Florida, Gainesville, FL 32611, USA, and Beihang University, Beijing, China. H. Zhang and H. Zhuang are with Huawei Technologies Co., Ltd. F zone Bantian, Longgang District,Shenzhen 518129, P.R.China. Correspondence author: Dapeng Wu, email: [email protected]. This work was supported in part by NSF ECCS-1509212 and NSFC 61529101 and 61231013. Copyright (c) 2012 IEEE. Personal use of this material is permitted. However, permission to use this material for any other purposes must be obtained from the IEEE by sending a request to [email protected]. enable the first responders to evaluate the severity of an emergency situation before they arrive on the scene through the real-time video provided by the caller’s smart phone. The municipal governments can also monitor the road traffic on real-time through the cameras mounted on the drones that fly over wherever the traffic jams. Current research directions on IoT mainly focus on the sensing and actuating capabilities and networking techniques. However, with the dramatic growth of video service quality (720p, 1080p, 4K), the challenges posed by video communi- cations over wireless networks between IoT devices should be given more consideration. In order to deal with the stochastic loss in a wireless network, the Forward Error Correction (FEC) codes are devel- oped. One important class of FEC codes are fountain codes [1], such as Luby transform (LT) code [2] and Raptor code [3]. With fountain codes, encoded packets are generated from a given set of native packets, such that the original file can ideally be recovered as long as the number of the received packets is equal to or only slightly larger than the number of native packets. For example, given a file consisting of a sufficiently large number of native packets k, with the latest generation of fountain codes, the RaptorQ codes [4], the chance of decoding failure is less than 1% upon receiving k packets, and less than one in a million upon receiving k +2 packets [5]. The major advantage of fountain codes is ratelessness, i.e., the coding rate can automatically adapt to the wireless condition without demanding acknowledgments (ACKs) or retransmissions. However, traditional fountain codes are designed for file transfer rather than video streaming. Under the current foun- tain codes paradigm, the users cannot start to watch it until the whole video file is successfully decoded. In order to accommodate fountain codes to video streaming, several window-based fountain codes have been proposed. In terms of window structure, (i) block coding [6], [7] divides the video file into fixed-length data blocks and separately sends them using fountain codes; (ii) sliding window [8]–[10] segments the video into overlapping windows, encodes them with fountain codes, and decodes them jointly; (iii) expanding window [11], [12] expands the previous window to include new packets. In the above three schemes, the block size is fixed in block coding, virtually extended in sliding window, and keep growing in expanding window. It is noteworthy that the window-based fountain codes will inevitably introduce extra play delay, due to window size and decoding time. As pointed out in [10], the window-based

Upload: others

Post on 13-Jul-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

1

MPC-based Delay-Aware Fountain Codesfor Real-Time Video Communication

Kairan Sun, Student Member, IEEE, Huazi Zhang, Member, IEEE,Dapeng Wu, Fellow, IEEE, and Hongcheng Zhuang

Abstract—With the prevalence of smart mobile devices andsurveillance cameras, the traffic load within the Internet ofThings (IoT) has shifted away from non-multimedia data tomultimedia traffics, particularly, the video content. However,the explosive demand for real-time video communication overwireless networks in IoT is constantly challenging both videocoding and communication research communities. The state-of-the-art answer to this challenge is sliding-window-based Delay-Aware Fountain (DAF) codes, which combine the channel-adaptive feature in rateless coding and the delay-aware featurein video coding. However, the high computational cost and largedelay make it impractical for real-time streaming. To address thisissue, we integrate the Model Predictive Control (MPC) techniqueinto DAF codes, so the complexity is lowered to an affordablelevel so that real-time video encoding is supported. Two schemesare developed in this paper: (i) DAF-S, the small-horizon DAFcodes, and (ii) DAF-O, the MPC-based DAF using video bit rateprediction. The advantages of both designs are validated throughtheoretical analysis and comprehensive experiments. The resultsof simulation experiments show that the decoding ratio of DAF-Sis close to the global optimum in DAF codes, and higher than theother existing schemes; DAF-O outperforms the state-of-the-artreal-time video communication algorithms.

Index Terms—Wireless networks, Fountain codes, Video com-munication, Model predictive control.

I. INTRODUCTION

Internet of Things (IoT) has witnessed the explosive growthof video traffic over the recent decade, especially after theprevalence of smart mobile devices and surveillance cameras.At the same time, IoT nowadays relies more and more onwireless networks. The most ambitious on-going projectsinclude Google’s Project Loon and Facebook Aquila, whichare both to try to beam the Internet down from the skieswirelessly, making it ubiquitous around the globe.

Because IoT devices with video-based applications providethe high accuracy and convenience that no simple sensor inthe past can provide, innovative applications of real-time videocommunication over wireless networks could touch people’slives in profound and different ways. For example, it can

K. Sun is with Department of Electrical and Computer Engineering,University of Florida, Gainesville, FL 32611, USA.

D. Wu is with Department of Electrical and Computer Engineering,University of Florida, Gainesville, FL 32611, USA, and Beihang University,Beijing, China.

H. Zhang and H. Zhuang are with Huawei Technologies Co., Ltd. F zoneBantian, Longgang District,Shenzhen 518129, P.R.China.

Correspondence author: Dapeng Wu, email: [email protected]. This work wassupported in part by NSF ECCS-1509212 and NSFC 61529101 and 61231013.

Copyright (c) 2012 IEEE. Personal use of this material is permitted.However, permission to use this material for any other purposes must beobtained from the IEEE by sending a request to [email protected].

enable the first responders to evaluate the severity of anemergency situation before they arrive on the scene throughthe real-time video provided by the caller’s smart phone. Themunicipal governments can also monitor the road traffic onreal-time through the cameras mounted on the drones that flyover wherever the traffic jams.

Current research directions on IoT mainly focus on thesensing and actuating capabilities and networking techniques.However, with the dramatic growth of video service quality(720p, 1080p, 4K), the challenges posed by video communi-cations over wireless networks between IoT devices should begiven more consideration.

In order to deal with the stochastic loss in a wirelessnetwork, the Forward Error Correction (FEC) codes are devel-oped. One important class of FEC codes are fountain codes[1], such as Luby transform (LT) code [2] and Raptor code[3]. With fountain codes, encoded packets are generated froma given set of native packets, such that the original file canideally be recovered as long as the number of the receivedpackets is equal to or only slightly larger than the numberof native packets. For example, given a file consisting of asufficiently large number of native packets k, with the latestgeneration of fountain codes, the RaptorQ codes [4], thechance of decoding failure is less than 1% upon receivingk packets, and less than one in a million upon receivingk + 2 packets [5]. The major advantage of fountain codesis ratelessness, i.e., the coding rate can automatically adapt tothe wireless condition without demanding acknowledgments(ACKs) or retransmissions.

However, traditional fountain codes are designed for filetransfer rather than video streaming. Under the current foun-tain codes paradigm, the users cannot start to watch it untilthe whole video file is successfully decoded.

In order to accommodate fountain codes to video streaming,several window-based fountain codes have been proposed. Interms of window structure, (i) block coding [6], [7] dividesthe video file into fixed-length data blocks and separatelysends them using fountain codes; (ii) sliding window [8]–[10]segments the video into overlapping windows, encodes themwith fountain codes, and decodes them jointly; (iii) expandingwindow [11], [12] expands the previous window to includenew packets. In the above three schemes, the block size isfixed in block coding, virtually extended in sliding window,and keep growing in expanding window.

It is noteworthy that the window-based fountain codes willinevitably introduce extra play delay, due to window size anddecoding time. As pointed out in [10], the window-based

Page 2: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

2

fountain codes for video streaming trade delay for higherdecoding performance. The reason is that larger block sizeintroduces longer delay, but also provides higher coding gainat the same time [13].

In fact, different video streaming applications have differentlevels of delay tolerance. Some applications are very delay-sensitive, such as real-time video chat, cloud gaming, etc., allof which are characterized by bi-directional communication[14]. Some uni-directional applications, on the other hand,have a loose tolerance on end-to-end delay, such as TVbroadcasting, Internet live streams. The others, such as thestreaming of pre-recorded content, are the least sensitive todelay.

Delay-Aware Fountain (DAF) codes are the state of the artproposed in [10]. Different from the other sliding windowfountain codes schemes, DAF codes do not treat the slidingwindows as homogeneous. By adaptively selecting the windowlength and optimally adjusting the sampling pattern accordingto the ongoing video bit rate, DAF codes deliver significantlyhigher video decoding ratio than existing schemes. Moredetails of DAF codes will be introduced in Section II-A asthe foundation of this work.

However, the high-complexity global optimization processof DAF codes may prevent its applications in delay-sensitivevideo communication. As a result, it is the focus of this paperto reduce complexity while maintaining relatively high codingperformance.

The main tool used here is Model Predictive Control (MPC).MPC has developed considerably over the recent years. As anadvanced method of process control, it has been successfullyused in the control process of chemical plants, oil refineries,power plants, etc. [15]. Besides, there are also some successfulapplications in academia, ranging from energy management[16] to automatic vehicle control [17]. Despite the popular-ity in automatic control community, MPC was never usedin the domain of multimedia communication until recently.We notice that MPC is used in bit rate adaption for videostreaming over HTTP in [18]. The contributions of this paperare summarized below.

1) MPC is combined with DAF codes to maximize videostreaming performance, while maintaining low com-plexity. In MPC, actions are optimized according to astate sequence over a horizon. Based on that idea, twoschemes are developed in our work, i.e., DAF-S andDAF-O.

2) DAF-S optimally adjusts the sampling pattern for foun-tain codes according to the ongoing video bit rate, soas to deliver a consistent video watching experience.The computational complexity is affordable becausethe objective function is minimized over a limit-sizedhorizon, which does not grow with the video length.

3) The online algorithm of DAF-O is proposed based onthe prediction of future bit rate. The decoding ratiois significantly higher than the existing online videocommunication schemes.

The paper is organized as follows. Section II introduces twofundamental techniques that will be used in this work: DAF

codes and MPC. Section III proposes our schemes and demon-strates the analytical results. Section IV presents the simulationresults of real-time video communication. Section V concludesthe paper.

II. RELATED WORK

In this section, we will introduce the Delay-Aware Fountain(DAF) codes proposed by Sun et al. in [10] and the ModelPredictive Control (MPC), which are the foundations of thiswork.

First of all, the important notations that will be used in thisarticle are listed in Table I.

TABLE I: Definitions of the notations.

Notation Unit DefinitionT frame Video length. Total number of frames

in the video sequence.R byte/second Data rate.C N/A Code rate.W frame Sliding window size.TDelay frame Tolerable delay from the video being

generated to it being played.s (t) packet Number of native packets in the

tth frame. Its vector form is s =[s(1) s(2) · · ·

].

a (t) N/A Slope factor for the tth slidingwindow. Its vector form is a =[a(1) a(2) · · ·

].

H frame Horizon length.ASP (t) N/A Accumulated sampling probability. It

is the total probability accumulatedon every packet in frame t throughall the sliding windows covering thatframe.

A. Delay-aware fountain codes

As mentioned in Section I, DAF codes [10] are novel delay-aware fountain codes for streaming high quality video overlossy wireless network. DAF codes deeply integrates channelcoding and video coding. It consists of two techniques: time-based sliding window and optimal window-wise samplingstrategy.

1) Time-based sliding window: The basic idea of DAFcodes is to segment the video file into overlapping windows,and then encode and send them consecutively with fountaincodes. While the non-overlapping block coding scheme hasa relatively small block size, the overlap between slidingwindows allows the decoded packets in a previous window tohelp the decoding of future windows. By doing so, the blocksize is virtually extended.

In order to maximize block size, the window size W in DAFcodes is defined by the maximum tolerable latency TDelay(in the unit of time or number of frames), instead of a fixednumber of packets. Therefore this technique is named time-based sliding window. In the rest of this article, we callthe window covering the frames of [t, t+W − 1] as the tth

window.In [10], the step size between two consecutive windows

is ∆t. For simplicity, in this work, we set ∆t = 1. This isbecause both the video length T and window size W are

Page 3: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

3

defined to be integral multiples of ∆t, if ∆t > 1, all theparameters can be down-sampled by a factor of ∆t, and allformulas still hold.

2) Optimal window-wise sampling strategy: Within eachwindow, the fountain codes algorithm randomly chooses thenative packets and combines them into a coded packet, ac-cording to degree distribution and sampling probability [2].Because the windows are overlapping, the total samplingprobability of a frame is related to all the windows that coversit, as shown in (1).

ASP (t) =∑

ω∈all windows cover frame t

pω (t) , (1)

where pω (t) denotes the average sampling probability of eachpacket in frame t within the window ω. So, ASP (t) denotesthe total probability accumulated on every packet in frame tthrough all the sliding windows covering that frame.

ASP, or accumulated sampling probability, is a very impor-tant metric in DAF codes, which will be frequently referred toin the rest of this article. The final objective of DAF codes isto minimize the variance of ASP, because the higher efficiencyof fountain codes is achieved by a more stable sampling rate.

However, with the time-based sliding window, even if thesampling distribution of every window is uniform, the overallASP may still be nonuniform. As a result, the samplingprobabilities in each window need to be adjusted in order toobtain a uniform overall ASP.

A proper representation of the sampling distribution is re-quired. Storing the entire sampling distribution in each packetheader (per-frame description) would be impractical due toboth communication and computation overhead. Alternatively,the slope-only description is proposed: the distribution isapproximated by a linear function defined by the slope factora. The slope factor is a real number ranging from −1 (forminga backward triangular distribution) to 1 (forming a forwardtriangular distribution). When a = 0, it represents a uniformdistribution.

Given bit rates s and slope factors a, the resulting ASP foreach frame can be computed by (2).

ASPs,a (t) = Bs (t) · a +Ds (t), (2)

where “·” denotes the dot product of the two vectors of(T −W + 1) elements, and

Bs (t) =[Bs (t, 1) Bs (t, 2) · · ·Bs (t, T −W + 1)

];

Bs (t, i) =

2·pkts(i,t−i+1)−s(t)

pkts(i,W )2− 1

pkts(i,W ) ,

if i ∈ [t−W + 1, t];0, otherwise;

Ds (t) =t∑

t0=t−W+1

1

pkts (t0,W );

pkts (t, k) =

t+k−1∑i=t

s (i) .

(3)

Given the total number of frames T , the window size W ,and number of packets in each frame s (t), DAF codes want

to find a set of slope factors a, for which the variance ofthe sampling probabilities of all packets attains its minimumvalue. The optimization problem is defined in (4).

arg mina

T−W+1∑t=W

(ASPs,a (t)−ASPs,a

)2,

s.t. −1 ≤ at ≤ 1, ∀t,(4)

where ASPs,a = 1T−2W+2

∑T−W+1t=W ASPs,a (t).

Based on the aforementioned two techniques, two schemesare developed: DAF and the low-complexity version DAF-L.

3) In-time decoding ratio: As pointed out in [10], a packetdecoded after its playback time is useless. This application-specific feature is captured by a new metric called in-timedecoding ratio (IDR), which only counts the “in-time” de-coded packets within the current window. This is in contrastto the file decoding ratio (FDR) which counts all the decodedpackets after a coding session completes.

It has been shown in [10] that DAF and DAF-L schemesyield much higher IDR than the existing schemes, such as[7]–[9], [11], [12] and TCP.

4) Disadvantages: Although DAF and DAF-L can improvethe quality of video streaming over lossy wireless network,there are three major drawbacks:• The decoding performance of DAF-L is relatively low.

Although its performance is higher than other delay-aware schemes, there is still a notable gap between DAFand DAF-L (10% maximum in decoding ratio). That isbecause DAF-L does not use the window-wise samplingdistribution optimization as in DAF. In exchange, DAF-Lis a low-complexity and online algorithm.

• DAF suffers from high computational complexity. Theglobal optimization function of DAF brings the com-plexity of O

(T 3). Since the computational scale grows

cubically with the video length T , it is not a practicalalgorithm for long videos.

• DAF is an offline scheme. Because the bit rate informa-tion of all frames is required to perform the optimization,the whole video file must be available before encoded byfountain codes. Therefore, it cannot be used on real-timevideo communication applications.

B. Model predictive control

The term Model Predictive Control (MPC) does not desig-nate a specific control strategy, but a wide range of method-ologies which make an explicit use of a process model toobtain the control signal by minimizing an objective function[15]. The methodology of all the MPC-based controllers ischaracterized by the following steps:

1) At each time τ , the process model is explicitly usedto get the output at a future time horizon H . Thesepredictions yτ (τ + k)1 for k = 1...H depend on theknown values (history inputs and outputs) up to timeτ and the future control signals, which are those to beoptimized.

1This notation indicates the value of the variable at the time τ + k iscalculated at time τ .

Page 4: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

4

�������������� ��������

����

������������������������

��������������

��������������������������������

� ����������������������� ������������ ����������������������

����������������

�������������������������������� ������ ��������������

��� �������������������! �"

Fig. 1: A flowchart of MPC-based delay-aware fountain codes.

2) The control sequence uτ (τ + k), k = 0...H − 1 iscalculated by minimizing the objective function. Theminimization function usually takes the form of aquadratic function of the error between the predictionand the target value.

3) The first action uτ (τ) from the calculated control se-quence is sent to the process whilst the other controlactions are rejected. Then, the next sampling instanty (τ + 1) will be known, and step 1 will be repeated withthis new value, and the next control action uτ+1 (τ + 1)is calculated, which in principle will be different touτ (τ + 1) because of the new information available.

The algorithm is iteratively executed each time a new instantis sampled. All various MPC algorithms only differ with eachother in the horizon length, predictive model and the objectivefunction to be minimized. Note that it is in general not aglobally optimal algorithm, since the control decisions aremade only based on the history values and the prediction ofa finite future horizon.

III. MPC-BASED OPTIMAL CONTROL FOR DAF CODES

In order to extend the application of DAF codes to real-time video communication, we are looking for a method toclose the gap between DAF-L and DAF: an online optimiza-tion algorithm with a lower computational complexity thanDAF, but higher performance than DAF-L. Meanwhile, MPCprovides a locally optimal online solution to any objective-function-minimizing process control problem, which gives usan inspiration for the solution to our problems.

A. MPC-based DAF codes: the non-predictive version

We propose a novel scheme that combines MPC and DAFcodes to impose a finite horizon to the optimization process ofDAF codes, in order to overcome its disadvantages describedin Section II-A. We call the proposed scheme as DAF-S, whereS stands for small horizon. A general flowchart of DAF-S isshown in Fig. 1. The text on the top of each block describes theprocedure in MPC. The text in the parentheses below explainsits function in DAF-S. We will go into the details later.

In this part, we focus on the localization of the optimizationproblem, so we temporarily assume that we know the full bitrate information of a video sequence. As a result, DAF-S iscan only be used in the coding of pre-recorded video. We willdiscuss the prediction of bit rate and other practical problemsfor online algorithm later in this section.

1) Horizon: Denote τ as the index of current time (alsothe index of current sliding window). Since the window sizeis W , the frame that was newly added to the encoding bufferis the (τ +W − 1)

th one.In order to determine what slope to use in the τ th window,

we may calculate the best set of slopes over a future horizonbased on both the known ASP in the past and the predictedASP in the future, then take the first slope as the one usedin encoding the τ th window. We denote the length of thehorizon as H , so the range of windows involved in our slopeoptimization is [τ, τ +H − 1].

We hope to clarify the difference between window size Wand horizon length H here. The two concepts are confusable,since both of them are spans of frames, and with both valuesincreasing, the performance and computational complexity ofthe controller tend to be higher. In fact, they are independentparameters that serve different purposes. W is typically chosenin accordance with the longest tolerable end-to-end delay. Itis specified by the user, so it is an input value that does notchange in a communication session. On the other hand, His a parameter to balance the computational complexity anddesired performance. It is chosen by the application accordingto the computing power, network condition, quality demand,etc. The extreme case would be H equals to 1, with whichonly one slope is calculated, the algorithm reduces to a greedyalgorithm; if H equals to T − τ + 1, thus all the frames in thefuture are considered in order to obtain each slope, it becomesthe same as the globally optimal algorithm of DAF.

2) Objective function: Our target is similar to the globaloptimization problem in (4), which is minimizing the vari-ance of ASP. With a finite horizon imposed, the objectivefunction is limited to a local range. Because the slopes inthe horizon [τ, τ +H − 1] can affect the ASP of the framesin [τ, τ +H +W − 2], the objective function is the varianceover that range as in (5).

J =τ+H+W−2∑

t=τ

(Ps,aHτ

(t)−Ps,aHτ

)2, (5)

where aHτ denotes the H-length slope vector for the windowsstarting from τ . P denotes the vector of ASP in the range of[τ, τ +H +W − 2], including both past and predictive values.The calculation of P will be discussed in the following part.Ps,aHτ

is the average value over P.3) Process model: The process model plays a decisive role

in a MPC controller. The chosen model must be capable ofcapturing the process dynamics so as to precisely predict thefuture outputs. Different from the problems in most industrialcontrol scenarios, in DAF codes, if the bit rate vector s isgiven, the mapping between control sequences (slope vector)and the predicted output (future ASP) is deterministic:

ASP (s,a) =[ASPs,a(1) ASPs,a(2) · · ·ASPs,a(l)

], (6)

where s is a bit rate vector, and a is a slope vector. ASPs,a(t)is defined in (2). Vector length l is equal to the length of a.In the calculation of ASP, s needs to contain W − 1 moreelements than a.

Page 5: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

5

Although ASP model is deterministic if we know all the bitrates s and slope parameters a in the future, the process modelis no longer deterministic when a finite horizon is imposed.

For the current window τ , the ASP in the range of objectivefunction in (5) consists of three parts, all of which are(H +W − 1)-length vectors representing a part of ASP withinthe range of [τ, τ +H +W − 2]. Some of the componentsonly have a part of non-zero elements in that range, whichwill be pointed out later.• Pinit: the initial ASP that already sampled by previous

windows.Non-zero range: [τ, τ +W − 2].

Pinit = ASP(s2W−2τ−W+1,a

W−1τ−W+1

), (7)

where the index notation in slt and alt means the elementsin these two vectors are the tth to (t+ l − 1)

th elementsfrom vectors s and a, respectively. Because Pinit iscomputed based on known s and previous selections ofa, it has no variable parameter.

• P: the range where ASP are affected by the currentlyoptimized slopes within the horizon.Non-zero range: [τ, τ +H +W − 2].

Ps,aHτ= ASP

(sH+W−1τ ,aHτ

), (8)

where aHτ is the H-length slope vector to be optimizedas in (5).

• P: the range where ASP will be affected by the slopesout of the horizon range in the future.Non-zero range: [τ +H, τ +H +W − 2].

Ps = ASP(s2W−2τ+H , aW−1τ+H

), (9)

where a denotes the prediction of future slopes. Sincethe optimal choices of the slopes in this part will also beaffected by the slopes in the further future, in order tolimit the length of horizon, we shall make a predictionwithout full knowledge about further frames. This isthe part that may bring error. Fortunately, because theselection of slopes of frames from further away will haveless impact on current optimal slope choice, a simple andsafe prediction is enough. In this work, we simply use anall-zero vector as a = 0, assuming all the windows inthat range will use uniform distributions. In that case,we can eliminate the variable parameter a. The future bitrates up to time τ +H+2W −3 are still needed as inputparameters.

The result is a combination of the three components:

Ps,aHτ= Pinit + Ps,aHτ

+ Ps. (10)

We plug (6) - (10) into the objective function (5) and solvethe optimization function (11).

arg minaHτ

J =τ+H+W−2∑

t=τ

(Ps,aHτ

(t)−Ps,aHτ

)2,

s.t. −1 ≤ at ≤ 1, ∀t.(11)

After solving the optimal aHτ , only the first element aτ (τ)is chosen to encode the τ th window.

4) Complexity: For each window τ , the optimal slope (11)can be solved by Karush-Kuhn-Tucker (KKT) conditions.Because there are H variables to optimize and 2H conditionsfor KKT conditions, the optimization process yields a systemof equations with 3H equations. If we omit constant factors,the solution involves the generation of a parameter matrixof H × H and the computation of its inverse matrix. Thealgorithm will be executed iteratively for each window forT times. As a result, the total computational complexity isO(T ×H3

). Since H � T and H does not increase with

video length, it can be considered as a linear complexityalgorithm for time T . Comparatively, DAF-S has a much lowercomplexity than O

(T 3)

of DAF.

B. Online algorithm with bit rate prediction

From (8) and (9), we know that in order to optimize theslopes in horizon H , we must know the bit rates in H+2W−3frames ahead of current time τ , or H +W − 2 frames aheadof the last known (a.k.a. the (τ +W − 1)

th) frame. However,in live-stream videos, we do not know the future bit ratesbeforehand. As a result, in order to make DAF-S works onreal-time video communications, we need to make a predictionon future bit rates, and the length of prediction is H+W −2.

Admittedly, a more accurate prediction of video bit ratewill help MPC optimization to obtain better control sequences.Therefore, using advanced algorithms, such as [19]–[23] mayimprove the coding result. A survey of video frame sizeforecasting algorithms can be found in [24]. Nevertheless,since video bit rate is a stochastic process, we can never expecta perfect prediction. Since our work does not focus on bit rateprediction algorithms, a simple linear formula (12) is adaptedto predict the future bit rates. A similar formula is used in[25] and yields good results.

st+1 = (1− α) st + αst, (12)

where st denotes the bit rate of the frame newly added to theDAF encoder, and st+1 denotes the prediction for the futureframes. α ∈ (0, 1] controls the weight of new frame in theprediction of bit rate. We fix it to 0.75 so our algorithm canget good average performances in our implementations.

Since (12) is not accurate enough to perform the frame-by-frame prediction, only a level of future bit rate is obtained.We replace all the elements of s in (10) which exceed thelast known frame with the predicted bit rate st+1. We call theonline MPC-based DAF codes algorithm as DAF-O.

When it comes to computational complexity, in our work,the prediction of bit rate in DAF-O is only O (1), so the onlinealgorithm does not increase the total computational complexityin DAF-S.

C. Optimization results and evaluations

In this part, we show some examples of optimization resultsobtained by different schemes, and analyze the resulting ASP.

Page 6: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

6

��������� ��� �� �� � ���

��������

������

��

���

���

(a) Bit rate for foreman.

��������� ��� �� �� � ���

��������

����

(b) DAF-O optimization.

��������� ��� �� �� � ���

��������

����

(c) DAF-S optimization.

��������� ��� �� �� � ���

��������

����

(d) DAF optimization.

Fig. 2: (a) Bit rate for foreman; and the optimized samplingdistributions for each window using: (b) DAF-O; (c) DAF-S;(d) DAF.

Frame no.

50 100 150 200 250

AS

P

0.7

0.8

0.9

1

1.1

1.2

1.3

1.4

1.5

DAF-L (var: 0.044)

DAF-O (var: 0.029)

DAF- (var: 0.019)

DAF (var: 0.0094)

Fig. 3: Resulting ASP using different DAF-based schemes forforeman.

1) ASP results comparison: Fig. 2a shows the bit rates forCIF video sequence foreman coded with H.264/AVC standard.Fig. 2b-d present the optimization results using DAF-O, DAF-S and DAF respectively, with W = 30 and H = 10. In Fig. 2b-d, each slope line represents a sampling distribution within awindow. Since ∆t = 1, there should be a window for every[t, t+W − 1] span. Because there are too many windows tobe clearly shown in one figure, only a fraction of the windowsis presented here.

We can observe that (i) the first W − 1 slopes in DAF-S(Fig. 2c) and DAF-O (Fig. 2b) are uniform distributions. Thatis because there are not enough past ASP to calculate Pinitin that range (see (7)), so the slopes in that range are set to 0as a warm-up period; (ii) the latter part of DAF-S in is verysimilar to that in the globally optimal result of DAF in Fig. 2d,whilst DAF-O is not, because of its lack of information aboutthe future bit rates.

Fig. 3 shows the resulting ASP using the optimized slopesfrom Fig. 2b-d (including DAF-L, which uses all uniformdistributions). The numbers following scheme names in thelegend are corresponding variations of ASP, and there isDAF < DAF-S < DAF-O < DAF-L.

2) Measuring the quality of ASP: Although we use varianceof ASP as the objective function in (5), it is not an effectivemetric to measure the quality of the resulting ASP in foun-tain codes. For example, if obtained sampling distributionsgenerate very low ASP, even if the variance is low, they arenot desirable. Besides, the performance of obtained sampling

normalized code rate (c)

0 0.2 0.4 0.6 0.8 1

AS

P c

ove

rag

e r

atio

((c

))

0

0.2

0.4

0.6

0.8

1

DAF-L

DAF-O

DAF-

DAF

Block

Fig. 4: The coverage ratios of the resulting ASP obtained bydifferent schemes for foreman.

distribution may vary under different code rates. Therefore, weintroduce a new metric to measure the quality of ASP, calledASP coverage ratio, denoted as ρ as in (13).

ρP (c) =

∑Tt=1

[Pt ≥ 1

c

]T

, (13)

where [·] is an Iverson bracket notation, which is defined tobe 1 if the condition in square brackets is satisfied, and 0otherwise. ρ (c) gives the ratio of frames whose ASP surpasses1/c. It is a monotonically increasing function, and its outputvalues are in the range of [0, 1]: if c < 1/Pmax, the outputvalue is 0; if c ≥ 1/Pmin, the output value is 1 (where Pmaxand Pmin denote the maximum and minimum values in Prespectively).

It is a good metric to measure the quality of ASP inthis case for the following reasons. ASP reflects the averageaccumulated sampling probability for a frame, so, under thesame code rate, greater ASP of a frame indicates higherprobability for it to be sampled than others. It also means,in order to be sampled into at least one coded packet, a framewith higher ASP expects lower code rate, and ASP is inverselyproportional to expected code rate. Therefore, if the ASP of aframe is higher than the reciprocal of code rate 1/c, that frameis likely to be sampled in coded packets under code rate c,thus it has the chance to be decoded on the receiver side.As a result, ρ (c) represents the ratio of frames that could bedecoded under code rate c.

Fig. 4 shows the coverage ratio curves of ASP from Fig. 3and block coding. c is normalized to the range of [0, 1]. Theresult justifies the gains brought by the proposed DAF codes:when c is greater than 60% of 1/Pmin, the ASP coverage ratiosare over 60% and there is DAF ≥ DAF-S ≥ DAF-O ≥DAF-L. That means in terms of the ratio of possible decodedframes within that code rate range, DAF outperforms DAF-S,DAF-S outperforms DAF-O, and DAF-O outperforms DAF-L.

Conversely, the relationships of ρ are inversed when c <50%. However, since in those scenarios the code rates are toolow that the decoding ratios are below 50% and the videocan hardly be viewed for all schemes, they are not the casesusers concern about. In other words, the proposed DAF codessacrifice the performance when the code rate is extremely low,

Page 7: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

7

for better performance when the code rate is in a moderatelyhigh range.

It should be noted that, this metric does not fully representthe actual decoding ratio in video communication. It onlyconsiders the sampling probability, but (i) it does not implywhen the frames are decoded, so it does not represent in-timedecoding ratio (IDR); (ii) it does not consider the factors offountain codes, such as degree distribution, codeword length,etc. That is the reason why the ρ curve of block coding doesnot look significantly worse than DAF-L in Fig. 4, whilethe IDR results of block coding is far inferior to any otherschemes, as we will see in the next section.

IV. EXPERIMENTAL RESULTS

A. Simulator Setup

The encoding/decoding parts of our implementation gener-ally follow the DAF framework in [10]. Most of the changesare made to the Video Preprocessing Module, where the noveloptimization algorithm is implemented.

We conduct the simulation experiments on Common OpenResearch Emulator (CORE) [26] and Extendable Mobile Ad-hoc Network Emulator (EMANE) [27]. The working environ-ment is set up on Oracler VM VirtualBox virtual machines.

We use CORE to emulate the topology of the virtualnetwork and the relay nodes. Two VMs are connected to thevirtual network as a source (or encoder/sender) node runningthe client application, and a destination (or decoder/receiver)node running the server application. A video is streamed fromclient to server using different schemes.

EMANE is used for emulation of IEEE 802.11b on PHYand MAC layer of each wireless node. Because of the forwarderror correction (FEC) nature of fountain codes, we disablethe retransmission mechanism of 802.11b for all fountain-code-based schemes. The adaptive rate selection mechanism of802.11b is also disabled. Ad-hoc On-Demand Distance Vector(AODV) protocol is used for routing.

A lot experiments are done under different scenarios in [10],e.g. single/multiple hops, with/without node mobility, etc. Asconcluded in that paper, the performance of DAF only relieson the end-to-end packet loss rate. As a result, consideringthe scope of this work and the limitation of space, we onlyconduct the experiments in single hop transmission scenariowhile controlling the packet loss rate of the link.

There are two nodes in the network: a source node and adestination node. The communication path from the sourceto the destination has one hop. The distance between thetwo nodes is carefully set so that the packets with 1024-bytepayload will experience a 10% loss rate.

B. Performance Evaluation

We implement eight schemes for comparisons, which areabbreviated as follows:

1) DAF: the full optimization version of delay-aware foun-tain codes in [10].

2) DAF-S: the MPC-based DAF codes as proposed inSection III-A.

3) DAF-O: the online version of MPC-based DAF codes asproposed in Section III-B.

4) DAF-L: it is the non-optimized version of DAF codes.All the windows use uniform distributions.

5) S-LT: the sliding window LT code from [8].6) Block: the block coding for fountain codes.7) Expand: this is the expanding window scheme of [11].8) TCP: this scheme uses TCP protocol to stream video.

In order to add delay awareness, the video file is alsosegmented into the blocks like in “Block” scheme, butthey are sent using TCP.

All the seven fountain-code-based schemes use the follow-ing parameter setting: the packet size P = 1024 bytes; fordegree distribution, let δ = 0.02, c = 0.4 (as defined in [2,Definition 11]). For TCP scheme, the maximum data rate islimited to the same amount as required by the fountain-code-based schemes for the sake of fairness.

Several benchmark CIF test sequences, provided by [28],are used for our evaluation. They are coded into H.264/AVCformat using x264 [29], encapsulated into ISO MP4 files usingMP4Box [30], and streamified by mp4trace tool from EvalVidtool-set [31]. The coding structure is IPPP, which contains onlyone I-frame (the first frame) and no B-frame, and all the restare P-frames. All the delays shown in the experiments are inthe unit of seconds. Denote by C and TDelay the code rateand the tolerable delay, respectively.

We conduct 20 experiments for each setting with differentrandom seeds, and take the median value of them as theperformance measure. The in-time decoding ratio (IDR)results are presented since it is a better metric in live videocommunication than file decoding ratio.

1) Evaluate the effect of horizon length: In this case, wecompare the performance of four DAF-based schemes. ForDAF-S and DAF-O, we set H to 1, 5, 10, 15 and 20 to observethe influence of horizon length.

Fig. 5 shows the IDR curves of the DAF-based schemesfor foreman. Because there are two dimensions of variables,we obtain the IDR curves vs. C when fixing TDelay = 1.2 sin Fig. 5a, and also obtain the IDR curves vs. TDelay whenfixing C = 0.77 in Fig. 5b. Results of DAF-S and DAF-O are plotted with green dashed lines and red dotted linesrespectfully. The different horizon lengths H are indicated bythe width of lines and the brightness of colors: the thicker anddarker lines indicate larger H , and the thinner and lighter linesindicate smaller H .

The numerical results of them when fixing both delayTDelay = 1.2 s and code rate C = 0.8 for foreman are shownin Table II.

From the results above, we have the following observations:• The decoding ratio of all the schemes is an increasing

function of TDelay , and also a decreasing function ofC. That means larger delay and lower code rate lead tohigher overall performance, which meets our expectation.

• Among the DAF-based schemes, the performance of DAFis the highest, while DAF-L is the lowest. The resultsof DAF-S and DAF-O are generally between those ofDAF and DAF-L. The relationships of decoding ratios isconsistent with the ASP coverage ratios as seen in Fig. 4.

Page 8: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

8

Code Rate

0.65 0.7 0.75 0.8 0.85

IDR

0.7

0.75

0.8

0.85

0.9

0.95

1

Delay = 1.1667 s

DAF

DAF-L

DAF-O (H=20,15,10,5,1)

DAF- (H=20,15,10,5,1)

(a) Fix TDelay = 1.2 s.

Delay (s)

0.8 1 1.2 1.4

IDR

0.7

0.75

0.8

0.85

0.9

0.95

1

Code Rate = 0.765

DAF

DAF-L

DAF-O (H=20,15,10,5,1)

DAF- (H=20,15,10,5,1)

(b) Fix C = 0.77.

Fig. 5: Comparisons of IDR curves for foreman when fixing(a) delay TDelay = 1.2 s; (b) Code rate C = 0.77. Variousvalues of H are chosen for MPC-O and MPC-M.

TABLE II: IDR comparisons of DAF-based schemes usingdifferent horizon lengths.

Scheme H IDRDAF N/A 93.71%

20 90.16%15 88.45%

DAF-S 10 87.80%5 86.15%1 80.86%

20 85.29%15 83.81%

DAF-O 10 87.03%5 82.88%1 68.00%

DAF-L N/A 76.52%

• In general, DAF-S outperforms DAF-O under the samehorizon length. That is because DAF-S can be deemed asDAF-O with prefect bit rate prediction. As a result, thegap between DAF and DAF-S is only caused by local bitrate knowledge, while the performance drop from DAFto DAF-O comes from both limited horizon length andinaccuracy of bit rate prediction.

• For DAF-S, the decoding ratio gets higher with theincreasing horizon length. However, since the computa-tional complexity increases cubically with H , an extralarge H is not affordable.

• For DAF-O, longer horizon length does not guaranteebetter performance. In the example of Table II, the highestIDR of DAF-O is achieved when H = 10, but not H =20. The reason is that in DAF-O, the long-term bit rateprediction will become inaccurate. Due to accumulatedlong-term prediction error, the performance of DAF-Owill reduce when the prediction length increases.

• When H = 1, the performance of DAF-O is significantlylower than other H values. That is because it is deductedto a greedy algorithm, and the decision is only based onthe history ASP.

2) Compare with the existing schemes: In this case, wecompare the proposed schemes with the existing video stream-ing algorithms. To strike a good balance between complexityand performance, we use H = 10 for MPC-O and MPC-M.

First, we want to show IDR comparisons of the onlinewindow-based fountain codes schemes: DAF-O, DAF-L, S-LT, expanding window and block coding. We choose all thecombinations of TDelay ∈ [0.6, 1.5] and C ∈ [0.6, 0.9] to con-

Fig. 6: Resulting IDR surfaces of online window-basedfountain codes schemes for foreman.

duct the experiments on foreman. There are two dimensionsof variables, so the results of each scheme form a surface ofIDR. Fig. 6 shows five surfaces of the online schemes.

The numerical results obtained by more schemes for moresequences are shown in Table III.

TABLE III: IDR comparisons of proposed schemes andexisting video streaming algorithms.

Code DelaySequence Rate (s) Scheme IDR

DAF 96.72%DAF-S 96.39%DAF-O 95.87%

foreman 0.72 1 DAF-L 92.62%S-LT 76.65%Expand 59.90%Block 35.05%TCP 72.74%DAF 95.78%DAF-S 95.05%DAF-O 94.76%

coastguard 0.72 0.7 DAF-L 94.13%S-LT 70.97%Expand 47.72%Block 32.58%TCP 65.45%DAF 91.30%DAF-S 91.08%DAF-O 90.48%

mobile 0.86 1.3 DAF-L 89.14%S-LT 79.79%Expand 50.42%Block 13.21%TCP 76.43%

From the results above, we have the following observations:

• Among all the schemes, DAF has the highest perfor-mance, followed by DAF-S, both of which are offlinealgorithms. Considering the computational complexity ofDAF-S is orders of magnitude lower than DAF, DAF-Sis a more practical offline algorithm.

• Among all the online schemes, DAF-O has the highestperformance, followed by DAF-L. As shown in Fig. 6,the surface of DAF-O is almost always higher than anyother scheme.

Page 9: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

9

• If C is too high or TDelay is too small, the performanceof DAF-L may be lower than DAF. The result accordswith the ASP coverage ratio in Fig. 4 when c is small,but it is not a very typical scenario since all of them aretoo low to be properly watched.

• The performance of TCP is relatively low. The reasonis that TCP is not suitable for wireless channels wherepacket loss rate is high [32]. Its congestion controlmechanism does not help the performance.

• Block coding scheme performs the lowest among allschemes, although its ASP coverage ratio is not very lowcompared to others. The reason is that the blocks aretoo small and non-overlapping, so the coding overhead isvery large [13].

V. CONCLUSIONS

In this work, we proposed an advanced channel codingalgorithm for real-time video communication over lossy wire-less network in IoT based on DAF codes. We developed twoschemes in this paper. DAF-S is small-horizon version of DAF,and its computational complexity is orders of magnitude lowerthan DAF. MPC-O is MPC-based online version of DAF thatcan be used in real-time video communication applications.The simulation results show that the decoding ratios of bothschemes are much higher than the state-of-the-art delay-awareschemes in a variety of settings.

REFERENCES

[1] J. W. Byers, M. Luby, and M. Mitzenmacher, “A digital fountainapproach to asynchronous reliable multicast,” IEEE Journal on SelectedAreas in Communications, vol. 20, no. 8, pp. 1528–1540, 2002.

[2] M. Luby, “LT codes,” in 2013 IEEE 54th Annual Symposium onFoundations of Computer Science. IEEE Computer Society, 2002, pp.271–271.

[3] A. Shokrollahi, “Raptor codes,” IEEE Transactions on InformationTheory, vol. 52, no. 6, pp. 2551–2567, 2006.

[4] M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, and L. Minder,“RaptorQ forward error correction scheme for object delivery (RFC6330),” IETF Request For Comments, 2011. [Online]. Available:http://www.rfc-editor.org/rfc/rfc6330.txt

[5] Q. Huang, K. Sun, X. Li, and D. O. Wu, “Just FUN: A joint foun-tain coding and network coding approach to loss-tolerant informationspreading,” in Proceedings of the 15th ACM international symposiumon Mobile ad hoc networking and computing. ACM, 2014, pp. 83–92.

[6] J.-P. Wagner, J. Chakareski, and P. Frossard, “Streaming of scalablevideo from multiple servers using rateless codes,” in IEEE InternationalConference on Multimedia and Expo, 2006. IEEE, 2006, pp. 1501–1504.

[7] S. Ahmad, R. Hamzaoui, and M. M. Al-Akaidi, “Unequal error protec-tion using fountain codes with applications to video communication,”IEEE Transactions on Multimedia, vol. 13, no. 1, pp. 92–101, 2011.

[8] M. C. Bogino, P. Cataldi, M. Grangetto, E. Magli, and G. Olmo,“Sliding-window digital fountain codes for streaming of multimediacontents,” in IEEE International Symposium on Circuits and Systems,2007. ISCAS 2007. IEEE, 2007, pp. 3467–3470.

[9] P. Cataldi, M. Grangetto, T. Tillo, E. Magli, and G. Olmo, “Sliding-window raptor codes for efficient scalable wireless video broadcastingwith unequal loss protection,” IEEE Transactions on Image Processing,vol. 19, no. 6, pp. 1491–1503, 2010.

[10] K. Sun, H. Zhang, and D. Wu, “Delay-aware fountain codes for videostreaming with optimal sampling strategy,” CoRR, vol. abs/1605.03236,2016. [Online]. Available: http://arxiv.org/abs/1605.03236

[11] D. Sejdinovic, D. Vukobratovic, A. Doufexi, V. Senk, and R. J.Piechocki, “Expanding window fountain codes for unequal error pro-tection,” IEEE Transactions on Communications, vol. 57, no. 9, pp.2510–2516, 2009.

[12] D. Vukobratovic, V. Stankovic, D. Sejdinovic, L. Stankovic, andZ. Xiong, “Scalable video multicast using expanding window fountaincodes,” IEEE Transactions on Multimedia, vol. 11, no. 6, pp. 1094–1104,2009.

[13] G. Liva, E. Paolini, and M. Chiani, “Performance versus overhead forfountain codes over Fq,” IEEE Communications Letters, vol. 14, no. 2,pp. 178–180, 2010.

[14] K. Sun and D. Wu, “Video rate control strategies for cloud gaming,”Journal of Visual Communication and Image Representation, vol. 30,pp. 234–241, 2015.

[15] E. F. Camacho and C. B. Alba, Model predictive control. SpringerScience & Business Media, 2013.

[16] H. Borhan, A. Vahidi, A. M. Phillips, M. L. Kuang, I. V. Kolmanovsky,and S. D. Cairano, “MPC-based energy management of a power-split hybrid electric vehicle,” IEEE Transactions on Control SystemsTechnology, vol. 20, no. 3, pp. 593–603, 2012.

[17] P. Falcone, H. Eric Tseng, F. Borrelli, J. Asgari, and D. Hrovat, “MPC-based yaw and lateral stabilisation via active front steering and braking,”Vehicle System Dynamics, vol. 46, no. S1, pp. 611–628, 2008.

[18] X. Yin, A. Jindal, V. Sekar, and B. Sinopoli, “A control-theoreticapproach for dynamic adaptive video streaming over HTTP,” in Pro-ceedings of the 2015 ACM Conference on Special Interest Group onData Communication. ACM, 2015, pp. 325–338.

[19] A. Abdennour, “Short-term MPEG-4 video traffic prediction usingANFIS,” International Journal of Network Management, vol. 15, no. 6,pp. 377–392, 2005.

[20] A. D. Doulamis, N. D. Doulamis, and S. D. Kollias, “An adaptableneural-network model for recursive nonlinear traffic prediction andmodeling of MPEG video sources,” IEEE Transactions on NeuralNetworks, vol. 14, no. 1, pp. 150–166, 2003.

[21] A. Bhattacharya, A. G. Parlos, and A. F. Atiya, “Prediction of MPEG-coded video source traffic using recurrent neural networks,” IEEETransactions on Signal Processing, vol. 51, no. 8, pp. 2177–2190, 2003.

[22] K. Y. Lee, M. Kim, H.-S. Jang, and K.-S. Cho, “Accurate prediction ofreal-time MPEG-4 variable bit rate video traffic,” ETRI journal, vol. 29,no. 6, pp. 823–825, 2007.

[23] K. Sun and B. Yan, “Efficient P-frame complexity estimation for framelayer rate control of H.264/AVC,” in 18th IEEE International Conferenceon Image Processing (ICIP), 2011. IEEE, 2011, pp. 1669–1672.

[24] R. J. Haddad, M. P. McGarry, and P. Seeling, “Video bandwidthforecasting,” IEEE Communications Surveys & Tutorials, vol. 15, no. 4,pp. 1803–1818, 2013.

[25] A. M. Adas, “Using adaptive linear prediction to support real-time VBRvideo under RCBR network service model,” IEEE/ACM Transactions onNetworking, vol. 6, no. 5, pp. 635–644, 1998.

[26] J. Ahrenholz, “Comparison of core network emulation platforms,”in MILITARY COMMUNICATIONS CONFERENCE, 2010-MILCOM2010. IEEE, 2010, pp. 166–171.

[27] U.S. Naval Research Laboratory, Networks and Communication SystemsBranch. The extendable mobile ad-hoc network emulator (EMANE).[Online]. Available: http://www.nrl.navy.mil/itd/ncs/products/emane

[28] P. Seeling and M. Reisslein, “Video transport evaluation withH.264 video traces,” IEEE Communications Surveys and Tutori-als, vol. 14, no. 4, pp. 1142–1165, 2012, Traces available attrace.eas.asu.edu.

[29] x264 team. x264. [Online]. Available:http://www.videolan.org/developers/x264.html

[30] GPAC project. MP4Box. [Online]. Available: http://gpac.wp.mines-telecom.fr/mp4box/

[31] J. Klaue, B. Rathke, and A. Wolisz, “Evalvid–a framework for videotransmission and quality evaluation,” in Computer Performance Evalu-ation. Modelling Techniques and Tools. Springer, 2003, pp. 255–272.

[32] G. Holland and N. Vaidya, “Analysis of TCP performance over mobilead hoc networks,” Wireless Networks, vol. 8, no. 2/3, pp. 275–288, 2002.

Page 10: MPC-based Delay-Aware Fountain Codes for Real-Time Video ... · include Google’s Project Loon and Facebook Aquila, which are both to try to beam the Internet down from the skies

2327-4662 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2016.2577520, IEEE Internet ofThings Journal

10

Kairan Sun (S’12) received his B.S. degree inComputer Science from Fudan University, Shanghai,China in 2012, and M.S. in Electrical Engineeringfrom University of Florida, Gainesville, FL, in 2016.He is now a Ph.D. candidate in Department ofElectrical and Computer Engineering, University ofFlorida. He is a student member of IEEE SPS.

He is a research assistant in Multimedia Commu-nications and Networking Lab supervised by Prof.Dapeng Oliver Wu. His research interests includenetwork coding, digital image and video processing

and machine learning.

Huazi Zhang (S’11–M’13) received the B.S. andPh.D. degrees in electrical engineering from Zhe-jiang University, Hangzhou, China, in 2008 and2013, respectively. From 2011 to 2013, he workedas a visiting scholar in the Department of Electricaland Computer Engineering, NC State University,Raleigh, NC. Since 2013, he has been working atNanyang Technological University and Universityof Florida as a research associate. His researchinterests include OFDM and MIMO systems, codingtechniques, clustering and compressive sensing. His

recent interests are mobile networking, big data and Internet of Things.

Dapeng Wu (S’98–M’04–SM06–F’13) receivedB.E. in Electrical Engineering from Huazhong Uni-versity of Science and Technology, Wuhan, China,in 1990, M.E. in Electrical Engineering from Bei-jing University of Posts and Telecommunications,Beijing, China, in 1997, and Ph.D. in Electricaland Computer Engineering from Carnegie MellonUniversity, Pittsburgh, PA, in 2003.

He is a professor at the Department of Electricaland Computer Engineering, University of Florida,Gainesville, FL. His research interests are in the

areas of networking, communications, signal processing, computer vision,machine learning, smart grid, and information and network security. Hereceived University of Florida Research Foundation Professorship Award in2009, AFOSR Young Investigator Program (YIP) Award in 2009, ONR YoungInvestigator Program (YIP) Award in 2008, NSF CAREER award in 2007, theIEEE Circuits and Systems for Video Technology (CSVT) Transactions BestPaper Award for Year 2001, and the Best Paper Awards in IEEE GLOBECOM2011 and International Conference on Quality of Service in HeterogeneousWired/Wireless Networks (QShine) 2006.

Currently, he serves on the editorial board of IEEE Transactions onSignal and Information Processing over Networks, and IEEE Signal Pro-cessing Magazine. He is the founder of IEEE Transactions on NetworkScience and Engineering. He was the founding Editor-in-Chief of Journalof Advances in Multimedia between 2006 and 2008, and an AssociateEditor for IEEE Transactions on Circuits and Systems for Video Technology,IEEE Transactions on Wireless Communications and IEEE Transactions onVehicular Technology. He is also a guest-editor for IEEE Journal on SelectedAreas in Communications (JSAC), Special Issue on Cross-layer OptimizedWireless Multimedia Communications. He has served as Technical ProgramCommittee (TPC) Chair for IEEE INFOCOM 2012, and TPC chair for IEEEInternational Conference on Communications (ICC 2008), Signal Processingfor Communications Symposium, and as a member of executive committeeand/or technical program committee of over 80 conferences. He was electedas a Distinguished Lecturer by IEEE Vehicular Technology Society in 2016.He has served as Chair for the Award Committee, and Chair of Mobileand wireless multimedia Interest Group (MobIG), Technical Committee onMultimedia Communications, IEEE Communications Society. He was anelected member of Multimedia Signal Processing Technical Committee, IEEESignal Processing Society from Jan. 1, 2009 to Dec. 31, 2012. He is an IEEEFellow.

Hongcheng Zhuang received the B.S. degree inelectronic engineering from Jilin University, China,in 1996 and the M.S. degree in communication& information system and the Ph.D. degree in ra-dio physics from SUN YAT-SEN University, China,in 2002. He joined Huawei Technologies in 2002and led standard research projects and long-termresearch projects in wireless communications since2005. His research interests include cellular sys-tems and WLAN networks, particularly system &protocol design, intelligent optimization and radio

resource management.