MicroCast: Cooperative Video Streaming

using Cellular and D2D Connections

Anh Le, Member, IEEE, Lorenzo Keller, Hulya Seferoglu, Member, IEEE,

Blerim Cici, Christina Fragouli, Member, IEEE, and Athina Markopoulou, Senior

Member, IEEE

Abstract

We consider a group of mobile users, within proximity of each other, who are interested in watching

the same online video at roughly the same time. The common practice today is that each user downloads

the video independently on her mobile device using her own cellular connection, which wastes access

bandwidth and may also lead to poor video quality. We propose a novel cooperative system where each

mobile device uses simultaneously two network interfaces: (i) the cellular to connect to the video server and

download parts of the video and (ii) WiFi to connect locally to all other devices in the group and exchange

those parts. Devices cooperate to efficiently utilize all network resources and are able to adapt to varying

wireless network conditions. In the local WiFi network, we exploit overhearing, and we further combine it

with network coding. The end result is savings in cellular bandwidth and improved user experience (faster

download) by a factor on the order up to the group size.

We follow a complete approach, from theory to practice. First, we formulate the problem using a

network utility maximization (NUM) framework, decompose the problem, and provide a distributed solution.

Then, based on the structure of the NUM solution, we design a modular system called MicroCast and we

implement it as an Android application. We provide both simulation results of the NUM solution and

experimental evaluation of MicroCast on a testbed consisting of Android phones. We demonstrate that the

proposed approach brings significant performance benefits without battery penalty.

Index Terms

Video Streaming, Cellular Networks, WiFi, Mobile Devices, Smartphones, Network Coding.

A. Le, B. Cici, and A. Markopoulou are with University of California, Irvine. Emails: {anh.le, bcici,athina}@uci.edu. L. Keller is with EPFL. Email: lorenzo.keller@epfl.ch. H. Seferoglu is with MIT. Email:hseferog@mit.edu. C. Fragouli is with EPFL and UCLA. Email: christina.fragouli@epfl.ch

arX

iv:1

405.

3622

v1 [

cs.N

I] 1

4 M

ay 2

014

I. INTRODUCTION

Mobile video is already a big part of today’s cellular traffic and is expected to grow much faster

than other traffic. Indeed, cellular traffic is growing exponentially (tripling every year), with the

share of video traffic increasing from 50% now to an expected 66% by 2015 [1]. Credit Suisse

reported that in 2012, 23% of base stations globally have utilization rates of more than 80–85%

in busy hours, up from 20% in 2011 [2]. This dramatic increase in demand poses a challenge on

the cellular networks, which are already struggling to provide good services to their subscribers.

For example, the data rate of a cellular connection may fluctuate over time (e.g., throughout the

day); the service loss rate can be as high as 50% [3]; and coverage can be spotty depending on the

location and user mobility.

Within this important problem space of mobile video, we focus on a particular setting, which

we refer to as the “micro setting”: we consider a group of mobile users, within proximity of each

other, who are interested in watching the same online video via their cellular links at roughly the

same time, as depicted in Fig 1(a). This is a common scenario in practice and examples include the

following. A group of friends may want to share and watch together a video clip from YouTube,

Netflix, or DailyMotion. In fact, 50% of YouTube male viewer, who are between 18 and 34 years

of age, watch YouTube clips together with friends in person [4]. Friends may want to watch a live

soccer match together on their mobile devices while at a remote location, such as a camping or

skiing site, where some of the mobile devices may have poor connection. Family members may

want to watch the same movie at the same time but each using their own mobile device, e.g., while

on a train or in a car. A group of students may want to watch the video of a lecture from an online

education system while sitting together and using several mobile devices1.

The default practice today for streaming the same video to a group of users, within proximity

of each other, is that each mobile device downloads the video independently from the server using

their own cellular connection. This approach has several issues. From a user’s perspective, the

video download rate is limited by the individual cellular link rates, which may not be sufficient or

stable enough to provide high video quality. From a cellular provider’s perspective, downloading the

same content multiple times in the same cell is a waste of precious access bandwidth. Furthermore,

many nearby users downloading the same content may lead to cell congestion, which eventually

translates to poor user experience as well. What would be desirable from both a user’s and a

1We note that a special case of this scenario is when the video is stored locally on one of the devices (as opposed to online onthe server) and the user wants to share it with the other members. Our analysis and implementation are generic enough to addressthis specific and popular scenario.

(a) (b)

Fig. 1. (a) “Micro” Setting and MicroCast. A group of mobile device users, within proximity of each other, is interested inwatching the same video at roughly the same time. Each mobile device connects to a video source, e.g., YouTube, Netflix, orDailyMotion, using its cellular (3G or 4G) connection. The base stations may be the same or different for different users, dependingon the provider they use. Each mobile device can receive packets from the source as well as from other devices in the neighborhoodthrough device-to-device WiFi links. (b) System model used in the analysis (Section IV): the x’s are the rates; the C’s are thecapacities; and the p’s are the loss probabilities.

provider’s perspectives would be the ability to use the aggregate cellular bandwidth in an efficient

way so as to satisfy all users. The “micro” setting has some inherent characteristics that make

it naturally amenable to cooperation, e.g., users are engaging in a group activity and are within

proximity of each other, thus can establish device-to-device links.

In this paper, we leverage device-to-device connections between all mobile devices and we

cooperatively download the video so as to effectively“bundle up” the cellular links in the group.

More specifically, each mobile device uses simultaneously two network interfaces: (i) the cellular to

connect to the video server and download parts of the video and (ii) the WiFi to connect to the rest

of the group and exchange those parts. In the local WiFi network, we exploit overhearing and further

combine it with network coding to effectively use WiFi resources. Devices cooperate to efficiently

utilize all network resources and are able to adapt to varying wireless network conditions. As a

result, the common video download rate can be up to the aggregate of the cellular links of all mobile

devices in the group. This benefits both the end-user, who enjoys higher rate and faster download

by a factor up to the group size, and the cellular provider who avoids redundant downloads and

saves its access bandwidth by the same factor.

More specifically, we take the following steps. First, we formulate the problem using a network

utility maximization (NUM) framework, decompose the problem, and provide a distributed solution.

Then, based on the structure of the NUM solution, we design a system called MicroCast2, and we

2Micro indicates locality: there is a small number of users and they are all within proximity of each other. Cast indicates amulticast traffic scenario: all users in the group are interested in the same content sent by a single source, and that we utilize WiFibroadcast.

implement a prototype on the Android platform. Fig. 1 (a) illustrates the micro setting, and Fig. 2(a)

depicts the MicroCast architecture. MicroCast consists of three main components: MicroDownload,

a simple yet effective scheduler that decides which parts of the video each mobile device should

download, adaptive to their cellular rates; MicroNC-P2, an efficient all-to-all dissemination scheme

that exploits WiFi overhearing and network coding; and MicroBroadcast, a networking module that

provide pseudo-broadcast capability over WiFi. To the best of our knowledge, MicroBroadcast is

the first networking module to fully exploit the potential of wireless broadcast on Android systems.

We evaluate the proposed system through both simulations of the NUM solution and experimen-

tation by implementing MicroCast on a testbed consisting of a number of Android phones. The

evaluation results demonstrate that there are significant performance benefits (in terms of decreased

download time and increased per-user download rate) compared to alternative approaches, without

significant battery cost. A video demonstration and supporting materials can be found on the project

website [5].

The structure of the rest of the paper is as follows. In Section II, we review related work. In

Section III, we present the problem setup and the system overview. In Section IV, we provide the

NUM formulation, solution, and interpretation. In Section V, we present the design and implemen-

tation of MicroCast. In Section VI, we provide the performance evaluation. Section VII concludes

the paper.

II. RELATED WORK

This work combines ideas from network coding, network utility maximization, and cooperation

for video streaming. In this section, we discuss the most relevant literature from these areas.

Cooperative Mobile/Wireless Systems. When several users are interested in the same content,

and they are in proximity of each other, they may be able to use device-to-device connections,

e.g., WiFi or Bluetooth, to get the content in a cooperative and/or opportunistic way. Opportunistic

device-to-device communication is often used for the purpose of offloading the cellular network.

For instance, [6], [7], and [8] consider a scenario in which device-to-device and cellular connections

are used to disseminate the content, considering the social ties and geographical proximity. Instead

of offloading cellular networks, our goal is to use cellular and local connectivity so as to allow

each user to enjoy the aggregate downlink rate.

Cooperation among mobile devices for content dissemination or in delay tolerant networking,

possibly taking into account social ties, has been studied extensively [9], [10]. However, dissemi-

nation of content stored on a mobile device is only a special case of our framework, which uses

only the local links, but not the cellular downlinks. More importantly, we focus on and exploit

single-hop broadcast transmissions, as opposed to multi-hop communication that exploits mobility

(at the expense of delay, which is crucial in our setting) but ignores broadcast.

The idea of using multiple interfaces of mobile devices has been explored before but not in the

same way as in this work. For example, [11] exploits cellular and WiFi interfaces simultaneously to

create multiple paths to mobile devices. [12] uses concurrent WiFi connections from multiple WiFi

hot-spots. [13] and [14] exploit the diversity of multiple interfaces on the same device to achieve

better connectivity. In contrast, we use the cellular connections of multiple mobile devices to improve

the download rate and jointly utilize the local connections. [15] and [16] address the same problem

using a similar approach but only use unicast communication among peers, as opposed to broadcast

used in our work. Thanks to broadcast, even when the local WiFi is congested, and cooperation

via unicast is not possible, our scheme may still be able to exploit the benefit of cooperation.

Network Coding in Cooperative, Wireless, and Peer-to-Peer (P2P) Systems. Cellular and WiFi

links suffer from packet loss due to noise or congestion. One possible solution to this problem is

to have several devices in a close proximity help each other with retransmissions of lost packets.

Network coding is particularly beneficial as it can make each retransmission maximally useful to all

nodes. Rate-distortion optimized network coding for cooperative video system repair in wireless P2P

networks is considered in [17]. Wireless video broadcasting with P2P error recovery is proposed in

[18]. An efficient scheduling approach with network coding for wireless local repair is introduced in

[19]. The work in [20], [21] and [22] proposes systems where there are a base station broadcasting

packets and a group of smartphone users helping each other to correct errors. Note that base station

broadcasting is not implemented in current cellular systems. In contrast, we consider unicast between

a base station and a mobile device. In [23], a cooperative video streaming system is implemented

over personal digital assistants (PDAs) but without network coding. Compared to prior work [18],

[19], [20], [21], [22], [24], where each phone downloads all the data, and the local links are used

for error recovery, our scheme jointly utilizes two interfaces, e.g., 3G and WiFi, for data delivery

and uses network coding over WiFi to help local repair and make scheduling easier.

Network coding has also been applied to P2P networks for content distribution [25], [26], [27]

and live streaming [28], [29]. An excellent review is presented in [30]. We will show that, in the

micro setting, our local cooperation scheme, MicroNC-P2, significantly outperforms state-of-the-art

P2P schemes, including the widely used BitTorrent [31] as well as the network coding-based R2

[28]. This is because MicroNC-P2 is explicitly optimized for the micro setting: it exploits WiFi

overhearing and network coding and avoids unnecessary redundancy.

Network Utility Maximization (NUM) of Coded Systems. The NUM framework is useful

for understanding how different layers and algorithms, such as, flow control, congestion control,

and routing, should be designed and optimized [32], [33]. The NUM framework has been used

in the past to design algorithms when network coding is employed. The problem of establishing

minimum-cost multicast connections over coded wired and wireless networks is considered in [34]

and is extended for end-to-end rate/congestion control over wired coded networks in [35]. A cross-

layer optimization framework including routing and scheduling to maximize throughput over coded

wireless mesh networks for multicast flows is studied in [36]. Linear optimization models for

computing a high-bandwidth routing strategy for media multicast in coded wireless networks are

proposed in [37].

The NUM framework has also been applied to P2P networks with network coding. In [38],

the aggregate application-specific utility is maximized by distributed algorithms on peers, which

are constrained by their uplink capacities. [39] extends [38] by considering node capacities and

constraints on both node upload capacity and node download capacity. In [40], performance bounds

for minimum server load, maximum streaming rate, and minimum tree depth under different peer

selection constraints are derived but without network coding. Optimal bandwidth sharing in multi-

swarm multi-party P2P video-conferencing systems with helpers is considered in [41]. Multi-rate

P2P multi-party conferencing applications, where different receivers in the same group can receive

videos at different rates using, e.g., scalable layered coding, are considered in [42]. The Implicit-

Primal-Dual scheme for flow control in live streaming P2P systems is introduced in [43]. [24], which

is the closest to our work, proposes a scalable video broadcast/multicast scheme that efficiently

integrates scalable video coding, 3G broadcast, and ad-hoc forwarding so as to balance the system-

wide and worst-case video quality of all viewers at 3G cell.

The differences between our work and previous work, at the intersection of NUM and network

coding, are the following: (i) our work utilizes multiple cellular unicast links, which is the case in

practice, while in prior work, e.g., [24], multicast is assumed deployed on the cellular link; (ii) the

NUM formulation in our work takes into account both the cellular links and WiFi transmissions;

and (iii) our work exploits network coding and broadcast over WiFi links.

Network Coding in Practice & Its Implementation. Network coding has been implemented

before on WiFi testbeds. For example, COPE [44] is a well-known practical scheme for one-

hop network coding across unicast sessions in wireless mesh networks. [45] proposes a cooperative

IPTV system with pseudo-broadcast to improve reliability. Medusa [46] considers a scheme in which

multiple unicast flows (video streams) are transmitted from a base station to clients with network

coding. This scheme considers rate adaptation and video packet scheduling jointly. SenseCode [47]

proposes a collection protocols, that utilize network coding and overhearing, for sensor networks.

The practicality of random network coding over iPhones is discussed in [48]. A toolkit to make

network coding practical for system devices, from servers to smartphones, is introduced in [49].

[20] implements network coding on mobile devices and presents the performance in terms of

throughput, delay, and energy consumption. [21] extends [20] for picture transmission. In [50], a

gesture broadcast protocol is designed for concurrent gesture streams in multiple broadcast sessions

over smartphones using inter-session network coding.

To the best of our knowledge, our work is the first to implement network coding and overhearing

on the Android platform. These tasks are much more challenging on Android devices than on

laptops, as explained in Section V. Network coding has been implemented before on other types

of phones [20], [21], [48] as well; however, it has not been combined with overhearing, which is

one of the key ingredients of our system.

Our work in perspective. The particular combination of the three ingredients: cooperation,

network coding, and (pseudo)broadcast on Android-based mobile devices, is optimized in the micro

setting and differentiates this work from previous schemes. The contributions of this work lie in (i)

the NUM formulation and solution of the problem, and (ii) the practical design and implementation

of MicroCast guided by the theoretical analysis. The theory and systems parts were previously

presented in [51] and [52], respectively. This journal paper combines these two parts and explains

their interaction. For example, it explains how the solution of the NUM framework guides the design

of MicroCast, and conversely, how the performance of MicroCast validates the NUM framework’s

solution. Along the way, we showcase key design decisions made to overcome challenges when

translating theoretical results into practical systems.

III. SYSTEM OVERVIEW

We consider the scenario presented in Fig. 1 (a): a group of mobile device users, within proximity

of each other, are interested in downloading and watching the same video at roughly the same

time. We use cooperation among the mobile devices, where each device simultaneously uses two

interfaces: the cellular interface to connect to the server, and the local interface (WiFi) to connect

to all other users in the group. We can use the two connections (cellular and WiFi) on each

device simultaneously and independently, as discussed in Section V-E. Note that cellular and WiFi

connections are used in parallel, but one connects directly to the server (via cellular), while the

other connects to the other mobile devices (via WiFi); we do not use both connections to connect

a user directly to the server through two different paths. Each mobile device downloads segments

of the video from the server and shares these segments with the rest of the group locally. The base

stations may be the same or different for different users, depending on their location and the service

providers they use.

Source and Flows. In our analysis, we consider the system model presented in Fig. 1 (b): the

source transmits a video to a group of mobile devices. This model is a simplified version of Fig. 1

(a) in that the source includes the video source, video proxies, and base stations. This allows us to

focus on the bottlenecks of the system, namely the cellular and the local area WiFi links. The links

between the source and proxies and the links between a proxy and the base stations are typically

high capacity links, thus they are not the bottleneck of our system.

Let N be the set of mobile devices (nodes) in the system. The source transmits a video flow of

rate x to the nodes. The video flow is associated with a utility function, U(x), which we assume

to be a strictly concave function of x.

Cellular Setup. Each node i ∈ N is connected to the video source via a cellular link. The

cellular link rate is Ci and the loss probability is pi. We consider |N | parallel interference-free

links3 connecting the source to each node. In practice, some mobile devices, e.g., node i, may not

have a cellular connection. Our system model and analysis capture this case by setting Ci = 0. We

denote the part of video flow transmitted over a cellular link towards node i to help node j by xi,j ,

and xi,i is the flow rate over the cellular link towards node i for its own usage.

WiFi Setup. Each node i ∈ N is connected to other nodes in the local area through WiFi. The

capacity between nodes i and j is Ci,j , and the loss probability is pi,j . We consider the interference

model in [53]: each node can either transmit or receive through WiFi, and all transmissions in the

range of the receiver are considered interfering. As we consider a group of nodes within proximity

of each other and do not consider multi-hop packet transmissions, any transmission in the local

area interferes with any other transmission, and only one node can transmit at a time.

We consider pseudo-broadcast transmissions over WiFi, where a node i transmits packets to a

node j using unicast transmissions, and each neighboring node overhears and makes use of the

3Since the nodes may connect to different base stations and the interference of cellular links are handled by the base stations, weassume that the downlinks are interference free from our perspective.

overheard packets. Consider a set of nodes J , J ⊆ N . The pseudo-broadcast rate from node i to

all nodes in J , is fi,J . Note that the set of links i–j, j ∈ J , is called a hyperlink. The transmission

rate over link i–j, i.e., from node i to node j, is gi,j . The relationship between gi,j and fi,J is

clarified in Section IV.

Loss Model. In our formulation and analysis, we assume that pi and pi,j are independent and

identically distributed loss probabilities. In practice, the channel model may follow a different (and

most probably non-independent and non-identical) distribution. Our formulations could be extended

to include more general distributions, and our system implementation (described in Section V) does

not require the knowledge of loss probabilities and probability distributions.

Network Coding. We consider network coding employed at each mobile device and not at the

video source. Each mobile device receives video from the source through its cellular link, performs

network coding, and transmit network coded video packets to other mobile devices through WiFi.

In our analysis, we consider that the size of the video file is sufficiently large, i.e., there always

exist packets for transmission. Network coding is performed over the large video file: each coded

packet is a linear combination of all packets in the video file. However, in the implementation,

we use the practical generation-based network coding [54]. Implementation details are provided in

Section V-B.

Cooperation. Several nodes interested in the same video form a single cooperating group4. The

users in a group know and trust each other, as it is the case in the motivating examples we provided

in the introduction. We consider two transmission policies in the local area: pseudo-broadcast and

unicast. (Note that our system implementation in Section V corresponds to the pseudo-broadcast

policy, and our baseline implementation in Section V corresponds to the unicast policy.) In our

setup, each node i maintains one input queue and several output queues each which corresponds

to a neighboring node. In both policies, each node i receives packets from the source or from

its neighbors, stores them in its input queue, and decodes them. The packets received from the

source are also put in the output queues. When a transmission opportunity arises (either using

NUM scheduling policy or a standard MAC protocol such as 802.11), node i transmits a (possibly

coded) packet from an output queue to the corresponding node.

Section IV provides the analysis of the system described above, following a network utility

4 In general, the nodes can join or and leave the group according to some rules. However, in this paper, we consider that all thenodes cooperate to form a single group.

maximization framework. We formulate the problem, provide a distributed solution, and interpret

structural properties of this optimal solution. In Section V, we use the insight from the analysis to

design a system with the components and algorithms mimicking the optimal solution. We implement

it on an Android platform, and we evaluate its performance in VI.

IV. NETWORK UTILITY MAXIMIZATION

As described in Section III, the source transmits video with rate x. For node i ∈ N , we consider

N different rates: xi,1, xi,2, · · · , xi,N , where the rate xi,j, j ∈ N , is the rate of data transmitted

from the source to node i to help node j. Our goal is to maximize the utility U(x), which is a

strictly concave function of the video source rate x. In the rest of this section, we use a network

utility maximization (NUM) framework to formulate this problem for the two cooperation policies:

pseudo-broadcast and unicast transmissions.

A. Formulation

Cooperation Policy: Pseudo-Broadcast. In this policy, we consider the case that pseudo-broadcast

(unicast + overhearing) is available in the local area. If network coding is used in the local area,

the NUM problem is formulated as follows:

P1: maxx

U(x)

such that 1.∑i∈N

xi,j − x ≥ 0, ∀j ∈ N

2. gi,j − xi,j ≥ 0, ∀i ∈ N , j ∈ N \ {i}

3. xi,j ≤ Ci(1− pi), ∀i ∈ N , j ∈ N

4. gi,j ≤∑J |j∈J

fi,J , ∀i ∈ N , j ∈ N \ {i}

5. fi,J ≤ minj∈J{Ci,j(1− pi,j)} τi,J , ∀i ∈ N , J ∈ H

6.∑i∈N

∑J∈H

τi,J ≤ γ (1)

The first constraint is the flow conservation constraint at the source. It requires that the total received

rate by node j,∑

i∈N xi,j , be larger than the targeted video rate, x. The second constraint is the

flow conservation at the mobile devices. It requires that the outgoing rate from node i to j, gi,j ,

should be larger than or equal to incoming rate, xi,j . The third constraint is the capacity constraint

in the downlink. Note that the third constraint is equivalent to maxj∈N{xi,j} ≤ Ci(1−pi), ∀i ∈ N .

This constraint is sufficient to represent the capacity constraint in the downlink because the content

of flows to help different nodes does not need to be different, i.e., the information content of xi,j

and xi,k, j ∈ N , k ∈ N , could be the same.

The fourth constraint relates the per link transmission rates, gi,j , and the pseudo-broadcast rate,

fi,J . This constraint requires that gi,j should be less than the total of flow rates over all hyperarcs

J that lead from i to j. This relationship reflects the fact that we employ pseudo-broadcast.

The fifth constraint is the capacity constraint in the local area. In this constraint, τi,J is the

percentage of time that the hyperlink {i,J } is used. The pseudo-broadcast rate, fi,J , should be

less than the minimum available capacity from node i to any node j, j ∈ J . This constraint reflects

the fact that network coding is used in the local area. Network coding helps to improve the broadcast

transmission rate. In particular, if network coding is not employed, the fifth constraint should be

fi,J ≤ minj∈J{Ci,j} ·

∏j∈J

(1− pi,j) · τi,J , ∀i ∈ N , J ∈ H . (2)

The reason is that a pseudo-broadcast transmission is only successful if it is successful over all links

from i to j, j ∈ J , when network coding is not used. This is why the product term is used. We

refer to this cooperation policy as Pseudo-Broadcast & No-NC. In contrast, when network coding

is used, each transmission is beneficial to any node that receives it correctly, independently of other

transmissions. Thus, the capacity constraint is improved to minj∈J {Ci,j(1− pi,j)}.The last constraint captures time sharing: time sharing parameters, τi,J , should be summed up

to a provisioning factor, γ, where γ ≤ 1.

Cooperation Policy: Unicast. In this policy, we consider the case that unicast transmissions are

used in the local area (WiFi), and network coding is not employed. The NUM problem is formulated

as follows:

P2: maxx

U(x)

such that 1.∑i∈N

xi,j − x ≥ 0, ∀j ∈ N

2. gi,j − xi,j ≥ 0, ∀i ∈ N , j ∈ N \ {i}

3. xi,j ≤ Ci(1− pi), ∀i ∈ N , j ∈ N

4. gi,j ≤ Ci,j(1− pi,j)τi,j, ∀i ∈ N , j ∈ N \ {i}

5.∑i∈N

∑j∈N\{i}

τi,j ≤ γ (3)

Note that the first three constraints of Eq. (3) are the same as Eq. (1). The fourth constraint is the

capacity constraint in the local area: the transmission rate from node i to j, gi,j , should be less

than the capacity of the link and the percentage of time the link is used for that transmission, τi,j .

The last constraint is the time sharing constraint similar to Eq. (1).

B. Solutions

Solution for P1. Let us first consider the solution for P1 in Eq. (1). By relaxing the first and

second constraints in Eq. (1) via Lagrangian relaxation, we have the following Lagrangian function:

L(x, λ, η) = U(x) +∑j∈N

λj(∑i∈N

xi,j − x) +∑i∈N

∑j∈N\{i}

ηi,j(gi,j − xi,j) , (4)

where λj and ηi,j are Lagrange multipliers. Eq. (4) is expressed as

L(x, λ, η) = U(x) +∑i∈N

∑j∈N

λjxi,j − x∑j∈N

λj +∑i∈N

∑j∈N\{i}

ηi,jgi,j −∑i∈N

∑j∈N\{i}

ηi,jxi,j

= U(x)− x∑j∈N

λj +∑i∈N

∑j∈N

xi,j(λj − ηi,j) +∑i∈N

∑j∈N

ηi,jgi,j . (5)

The Lagrangian function in Eq. (5) is decomposed into several sub-problems, each of which solves

the optimization problem for one variable. We provide the decomposed solution in the following.

Flow Control at the Source: First, we solve the Lagrangian function with respect to x:

x = (U ′)−1(∑j∈N

λj) , (6)

where (U ′)−1 is the inverse function of the derivative of U . This part of the solution is interpreted as

the flow control at the source. Note that λj is the Lagrangian multiplier, and it can be interpreted as

the queue size at the source for packets to be transmitted to node j. (The reason for this interpretation

will be provided later in this section.) By considering λj as the queue size and taking into account

that U(x) is a strictly concave function of x, it could be observed from Eq. (6) that x is inversely

proportional to the sum of the queues for all nodes in a cooperating group. This policy regulates

the amount of traffic that are generated at the source and inserted into the output queues at the

source based on the number of packets in the queues to avoid congestion (or buffer overflows). In

our implementation, the video source, e.g., YouTube server, has its own algorithms to regulate the

generated traffic. Therefore, we do not use this part of the solution in our implementation and rely

on the flow control mechanism of the video source (e.g., TCP) to avoid buffer overflows.

Downlink Rate Control: Second, we solve the Lagrangian function with respect to xi,j:

maxx

∑i∈N

∑j∈N

xi,j(λj − ηi,j)

s.t. xi,j ≤ Ci(1− pi), ∀i ∈ N , j ∈ N (7)

where x is the vector of {xi,j}i,j∈N . Here, the Lagrange multipliers ηi,j can be considered as the

size of the queue at node i for packets that should be transmitted from node i to node j. (The

reason for this interpretation will be provided subsequently.) According to Eq. (7), the transmission

rate, xi,j , should be set to zero if the difference of the queue size at the source for node j, λj , is

less than the queue size at node i for node j, ηi,j . In our implementation, we do not have control

at the source, and information about λj is not available. Nevertheless, if we assume that λj is fixed

for all j (which is a valid assumption, for example, for TCP flows in larger time scale as compared

to TCP’s own clock) then xi,j becomes inversely proportional to the queue size, ηi,j , at node i.

Therefore, if ηi,j is large, xi,j should be small and vice versa. Based on this observation, and also

not to overload queues at the mobile devices, our practical download algorithm implemented in

MicroDownload requests more packets for the mobile devices with small queue sizes, and requests

less packets for the devices with large queue sizes. The details of the algorithm are presented in

Section V-A.

Local Area Rate Control and Scheduling: Third, we solve the Lagrangian function for τi,J . It

could be observed from the fourth and fifth constraints of Eq. (1) that the optimal value of gi,j is∑J |j∈J minj∈J {Ci,j(1 − pi,j)}τi,J . Therefore, the local area rate control and scheduling problem

could be expressed as follows:

maxτ

∑i∈N

∑J∈H

τi,J (∑j∈J

ηi,j minj∈J{Ci,j(1− pi,j)})

s.t.∑i∈N

∑J∈H

τi,J ≤ γ , (8)

where τ is the vector of {τi,J }i∈N ,J⊆N . Eq. (8) determines the percentage of time that a hyperarc

{i,J } is used for transmitting packets. It could be observed from Eq. (8) that the pseudo-broadcast

link {i,J } is activated if the∑

j∈J ηi,j minj∈J {Ci,j(1 − pi,j)} term is larger than that of the

other links. This means that the pseudo-broadcast link, which could transmit more packets, i.e., the

pseudo-broadcast link with the largest∑

j∈J ηi,j , and better capacity, is activated for transmission.

Our practical implementation is based on this idea. In particular, the node having a segment needed

by the largest number of devices, which (broadly) corresponds to∑

j∈J ηi,j , takes the opportunity

and transmits the segment. Specifically, the MicroNC-P2 algorithm pseudo-broadcasts the segment

that is needed by the largest number of devices immediately. More details of MicroNC-P2 are

provided in Section V-B.

Queue Update: The decomposed parts of the Lagrangian, i.e., Eqs. (6), (7), (8) and the Lagrange

multipliers λj and ηi,j can be solved iteratively via sub-gradient algorithms. In particular, λj can

be iteratively solved as follows:

λj(t+ 1) = {λj(t) + βt[x(t)−∑i∈N

xi,j(t)]}+, ∀j ∈ N , (9)

where t is the iteration number, βt is a small constant (step size of the gradient descent algorithm),

and the {}+ operator makes the Lagrange multipliers positive, i.e., {a}+ = max{a, 0}. The Lagrange

multiplier λj is interpreted as the queue size at the source for the packets to be transmitted to node

j because it is updated as the difference between the incoming traffic, x, and the outgoing traffic,∑i∈N xi,j .

Similarly, ηi,j can be solved iteratively as follows:

ηi,j(t+ 1) = {ηi,j(t) + βt[xi,j(t)− gi,j(t)]}+, ∀i ∈ N , j ∈ N . (10)

The Lagrange multiplier ηi,j is interpreted as the queue size at node i for packets to be transmitted

from node i to node j because it is updated as the difference between the incoming rate, xi,j , and

the outgoing rate, gi,j . In the interest of space, we provide the convergence analysis of the solution

in [55].

Solution for P2. Now, let us consider the solution for P2 in Eq. (3). The decomposed solution of

P2 exactly follows Eq. (6) for the flow control at the source, Eq. (7) for the downlink rate control,

and Eq. (9) and Eq. (10) for the queue updates at the source and local nodes, respectively. The only

different part is the local area rate control. Note that the optimal value of gi,j is gi,j = Ci,j(1−pi,j)τi,j .The rate control for Eq. (3) is as follows:

maxτ

∑i∈N

∑j∈N

ηi,jCi,j(1− pi,j)τi,j

s.t.∑i∈N

∑j∈N

τi,j ≤ γ (11)

Similar to Eq. (8), Eq. (11) determines the percentage of time that a link (i, j) is used for transmitting

packets.

(a) Architecture (b) Distributors (c) Downloading (d) Statistics

Fig. 2. The MicroCast Architecture and snapshots from the Graphical User Interface. (a) Architecture and main components ofMicrocast. (b) Choosing a scheme for local cooperation. (c) Visualization of downloading: packets already stored (green), currentlydownloaded from the cellular (blue), from neighbors through WiFi (purple) and missing (red). (d) Measurements of download ratesover different links.

Algorithm 1 MicroDownload Algorithm1: while there are segments to assign do2: Find the device with the smallest backlog3: if the backlog of the device is smaller than K then4: Schedule the device to download the next segment5: else6: Sleep until new feedback is received7: end if8: if feedback from device indicates a failure then9: Schedule the device to download another segment

10: Add the segment that failed to the list of segments11: end if12: end while

V. MICROCAST: DESIGN AND IMPLEMENTATION

In this section, we present MicroCast, the prototype system that we develop on the Android

platform based on the insight gained from the structural properties of the optimal NUM solution.

We developed MicroCast mostly in Java with some parts in C. It currently runs on Android

2.3 and 4.0. Fig. 2 (a) shows the overall architecture of MicroCast and the main components:

Requester, MicroNC-P2, and MicroBroadcast. Additional components include Requester, Storage,

and Graphical User Interface. In the following, we describe each component in detail.

A. MicroDownload

This component is present on all devices in the group but runs only on the one that initiates the

download. It instructs the requesters of all devices which segments of the video to download from

the server. (Recall that a video is divided into multiple segments.) The key idea of MicroDownload

is to assign the next segment to be downloaded to a device which has the smallest backlog, where

the backlog refers to the set of segments previously assigned to this device.

The MicroDownload algorithm is summarized in Alg. 1. MicroDownload has a list of segments

that should be assigned to the devices. Initially, it assigns a fixed number (K) of segments to each

device. The devices try to download one after another the segments that are assigned to them. If a

device downloads a segment successfully, it notifies MicroDownload. Otherwise, it reports failure.

MicroDownload re-assigns the failed segments based on the backlogs. This mechanism ensures that

no segment remains trapped in any device which has a bad cellular connectivity. This mechanism

also adapts segment download to the varying rates and conditions of cellular links. For example, if

a device has a bad cellular connection, the segments being handled by it will be reassigned to other

devices, which hopefully have better connections. However, MicroDownload will still assign some

segments to the device with a bad cellular connection so that it can start downloading immediately

as soon as its connection quality improves.

B. MicroNC-P2

This component is responsible for distributing segments using the local WiFi network, exploiting

the benefits of overhearing and network coding. At a high level, MicroNC-P2 takes advantage of

pseudo-broadcast, i.e., unicast and overhearing, to reduce the number of transmissions. Furthermore,

instead of disseminating plain packets, it disseminates random linear combinations of packets

(network coded packets) of the same segment. This is to maximize the usefulness of overheard

packets [56]. We will provide details on how we implement network coding subsequently. We term

our dissemination scheme MicroNC-P2, where P2 refers to an initial Push and subsequent Pulls,

as explained below.

Our MicroNC-P2 is designed based on traditional pull-based P2P dissemination schemes, such

as BitTorrent. In MicroNC-P2, a segment s is divided into m plain packets. m is also known

as the dimension of the linear space s or the size of a network coding generation. A device, A,

periodically advertises the segments that it currently has to its neighbors. Then, a neighbor, say

device B, requests segments that it does not have based on the advertisement. Upon receiving the

request, A sends the requested segments to B. More specifically,

• When B requests a segment s from A, it takes into account previously overheard coded packets

of segment s. In particular, it explicitly indicates in the request how many additional coded

packets (missing dimensions) it needs to receive to decode s. This reduces the number of

Algorithm 2 MicroNC-P2 Algorithm1: when a new segment s is received2: if s is received by the requester then3: // initial push, m is the dimension of s4: Send m coded packet of s to a neighbor5: end if6: Add s to the list of segments to be advertised7: end when

8: when a packet p is received from A9: if p is an advertisement or notification containing s then

10: // subsequent pulls exploit overhearing11: Request A for the missing dimensions of s12: else if p is a request for d dimensions of s then13: Add this request to the request queue14: else if p is a coded packet of s then15: Progressively decode s using p16: end if17: end when

18: when there is a request for d dimensions of s from A19: // pseudo-broadcast20: if there are other similar requests then21: Let d be largest requested dimension22: Remove these requests from the request queue23: end if24: Send d coded packets of s to A25: end when

coded packets to be sent.

• When A is about to serve a segment s requested by B, it first checks if there are pending

requests for the same segments from other neighbors. If there are, it finds the maximum number

of coded packets requested among these requests. Denote this maximum number by d. If there

is none, d is the number of coded packets requested by B. Afterwards, A serves d coded

packets of segment s to B. The other devices, which need up to d coded packets of s, should

be able to get them through overhearing.

After serving B, A notifies all devices that requested some coded packets of segment s. Upon

receiving the notification, these devices check if they received all the necessary coded packets

to decode s. If not, they send requests for additional coded packets. This is necessary because

overhearing is not guaranteed for all coded packets sent by A and for all devices. Finally, the

(a) Space-Time Diagram of MicroNC-P2 (b) MicroBroadcast

Fig. 3. (a) MicroNC-P2 is the local dissemination schemes that exploits network coding and pseudo-broadcast provided byMicroBroadcast: Coded packets of a just downloaded video segment are initially pushed by pseudo-broadcasting. Then, the neighborsrequest for additional coded packets necessary for decoding. Finally, the recovery takes into account all requests to save bandwidth.(b) MicroBroadcast uses one device as an Access Point. This AP device does not forward packets. A non-AP device pseudo-broadcasts by unicasting to the AP and the rest overhears. MicroBroadcast achieves one transmission per broadcast, which is themost efficient possible.

scheme gives higher priority to requests that are closer to the playback time when serving them.

Overhearing and unicast effectively allow for pseudo-broadcast. The amount of traffic saved by

pseudo-broadcasting segment s depends not only on the quality of the overhearing but also on the

number of requests of segments s from other devices that A processes at the time of broadcasting.

To maximize the traffic savings, we propose an initial push of segment s. Specifically, when A

finishes downloading segment s, it sends m coded packets of s to a randomly selected neighbor

before advertising the segment. (Note that this just downloaded segment is beneficial to all neigh-

bors.) By doing so, A ensures that the initial dissemination of segment s is taken into account

in subsequent requests of segment s (if any) of A’s neighbors. This effectively creates a perfect

synchronization of the reception of the initial requests of segment s. We provide the pseudocode

of MicroNC-P2 distribution algorithm in Alg. 2 and the space-time diagram of MicroNC-P2 in

Fig. 3(a).

Last but not least, in order to address loss of request and notification packets, which could lead to

incomplete segments, MicroNC-P2 includes a recovery thread. This thread periodically re-requests

segments that were requested after a certain amount of time but never received.

Implementing Network Coding. We implement the practical generation-based network coding

[54] over the field GF(28). The video file is divided into multiple segments. A segment represents

a coding generation. Each segment is broken down into m packets, where m is the generation size.

Each packet contains n bytes, and we treat each byte as a symbol in GF(28). We also augment each

packet with the m coding coefficients. Coding coefficients of a coded packet is selected uniformly

at random from GF(28). Each packet can be seen as a vector of length n+m symbols from GF(28).

Let M denote the matrix whose rows are m linearly independent packets (of size n+m) of the

same segment that a device received: M = [E |C], where E is the data matrix of size m× n and

C is the coefficient matrix of size m×m. The original packets of the segment can be recovered by

finding the inverse of C. In particular, C−1 · [E |C] = [B | I], where B is the matrix of size m×n,

whose rows are the original packets, and I is the m×m identity matrix. Inverting C takes Θ(m3)

and multiplying C−1 with [E |C] takes Θ(m2(n+m)) in terms of finite field multiplication. Thus,

the decoding takes Θ(m3 + nm2) in total. Generating m randomly encoded packets can be done

by generating a random coefficient matrix R of size m×m and multiplying R with [B | I]. Thus,

the encoding of a segment also takes Θ(m3 + nm2).

As described above, network coding is a CPU intensive operation. In MicroCast, encoding and

decoding must be performed efficiently, at a rate matching that of the local network dissemina-

tion. Otherwise, CPU risks to become the bottleneck of the video distribution. Therefore, in our

implementation, we explored several ways to optimize the coding speed.

The first method to reduce the CPU usage is to limit the size of the coding generation (m). The

smaller the number of packets in each segment, the smaller the coding complexity. Using smaller

segment sizes, however, reduces the diversity of encoded packets, i.e., packets are less likely to

bring innovative information to their recipients. Second, we seek to optimize our implementation of

network coding. In particular, we test two implementation approaches: pure Java and native code.

In the first implementation, the encoding and decoding operations are performed by code that runs

in the Dalvik virtual machine. In the second approach, the code runs natively on the device CPU

and is invoked through the Java Native Interface. The Java implementation has the advantage of

being portable across different hardware platforms, but it is less efficient than the native version.

In both implementations, we use table lookups to perform finite field multiplication and division,

and we use the bit-by-bit XOR operation to perform addition and subtraction. In Section VI-B, we

provide the evaluation of both of these implementations.

C. MicroBroadcast

This component implements a comprehensive networking stack, which operates on current wire-

less technologies, including WiFi 802.11 and RFCOMM Bluetooth. MicroBroadcast supports uni-

cast, reliable and un-reliable message exchange between the devices over both WiFi and Bluetooth.

It also includes multi-hop routing, network-wide flooding, and peer discovery. The most important

functionality that MicroBroadcast provides is the ability to pseudo-broadcast over WiFi. To the

best of our knowledge, this is the first system that provides this capability on top of WiFi on

Android devices. Depending on the wireless technology used, features of MicroBroadcast are

either implemented using a native mechanism or custom developed. For instance, the Bluetooth

implementation re-uses the native peer discovery mechanism while WiFi devices run a custom peer

discovery protocol.

Implementing High-Rate WiFi Broadcast. Although devices within proximity of each other

can, in principle, overhear all transmissions, high-rate broadcast was not possible with the existing

modes. The unicast mode of 802.11 does not exploit broadcast: it (redundantly) transmits the same

packets to each receiver separately. The broadcast mode of 802.11 has its own disadvantages [46]: (i)

it lacks a back-off mechanism, which may harm the performance of other flows; (ii) its transmission

rate is limited to the minimum (base rate, 1 Mbps); (iii) finally, unlike laptops, it is not always

possible to adapt the broadcast transmission rate on Android devices due to wireless driver and

firmware limitations.

A possible solution is to use pseudo-broadcast, i.e., overhearing, which combines the benefits

of unicast and broadcast. Unicast is used as the transmission mode, but the devices overhear all

transmissions in their neighborhood. Pseudo-broadcast combines the desirable properties of unicast

(high rate, back-off) with overhearing, which makes it attractive. Although it has been implemented

in several frameworks [44], [46], [57], when implementing pseudo-broadcast, we faced several

challenges that are specific to the Android platform.

First, the devices we use do not readily support the promiscuous mode due to the constraints

imposed by the WiFi firmware and drivers. Therefore, we have to update the WiFi drivers of all

the Android 2.3 devices we use, and the firmware in some of them. In particular, we update the

WiFi driver and firmware by installing CyanogenMod 7 ROM [58] (a custom Android firmware) on

the devices after testing various possible firmwares. With the CyanogenMod 7 ROM, promiscuous

mode is available, but only in infrastructure mode (not in ad-hoc mode).

Second, even with the promiscuous mode enabled, Android does not support pseudo-broadcast

mode natively, i.e., it does not pass the overheard packets up to the application layer. We have to

develop our own overhearing API for that purpose “under the hood of Android,” by developing

our own C library and a C binary executable program that runs as a daemon. They also filter out

irrelevant overheard packets (i.e., packets which do not belong to video data that the devices are

interested in) so as not to overload the CPU.

Third, as we mentioned above, this pseudo-broadcast implementation works only in infrastructure

mode but not ad-hoc mode. Using infrastructure mode has a major disadvantage compared to ad-

hoc mode: when a device transmits a packet to another device, the packet has to be relayed by the

access point, which results in double amount of traffic.

To avoid this disadvantage of infrastructure mode as well as to exploit the benefits of overhearing,

we implement a pseudo-ad-hoc mode, which is shown in Fig. 3(b). In this mode, a device is chosen

to act as the access point (AP). In order for a device to transmit packets to other devices, it transmits

them to the AP. These transmissions are overheard opportunistically by the targeted devices. When

the AP device receives a packet, it does not forward it (as it would normally do in the infrastructure

mode), since the other devices should already have received it via overhearing. In this manner, we

are able to enable overhearing (which is only possible in infrastructure mode), while ensuring only

one transmission per packet (which is the case in ad-hoc mode), thus the term pseudo-adhoc mode.

D. Other Components

Requester retrieves segments of the video from the video source. It internally uses components

called producers to retrieve the segments. Our current implementation contains producers for three

types of sources: HTTP, file, and content. The first one (HTTP) loads segments from an HTTP

server using range requests. The second one (file) loads video from locally available files. Finally,

the third one (content) retrieves data using the ContentProvider API of Android (e.g., videos can

be captured with the device camera).

Storage is used to cache the received segments for successive playback. The segments are stored

in the internal flash memory of the device to keep the application memory requirements low. It is

possible to access the segments from the storage either using a Java API, as done by the requester

and MicroNC-P2, or via an embedded HTTP server that we have developed. This second interface

allows us to play the video stream using the native Android media API.

Graphical User Interface (GUI) provides an interface to create video streams, share local videos,

start/stop downloading video files, join existing video streams, and play/pause videos. In addition to

these basic features, the GUI lets users discover and connect to other devices, specify the wireless

interface and algorithm that should be used for the local dissemination, and decide whether the

device should collaborate for video downloading. In addition, it provides live feedback and detailed

statistics during and after experiments. These functionalities of the GUI facilitate field tests. We

provide some screen shots of our GUI in Fig. 2 (b, c, d). Finally, the video can be played while

MicroCast is still downloading; therefore, live streaming is supported.

E. Using Multiple Network Interfaces

Each device needs to use a network interface as downlink (e.g., 3G or WiFi) and another interface

(e.g., WiFi or Bluetooth) for the local cooperation. For the connection to the server, we choose 3G

over WiFi mainly because it provides ubiquitous Internet access. A second reason is that Bluetooth

and WiFi share partially overlapping parts of the spectrum and are often implemented in the same

chip; meanwhile, 3G is usually implemented on a different chip and uses a different part of the

spectrum. This suggests that using WiFi (for the connection to the server) together with Bluetooth

(for the local network) may noticeably decrease the transmission rate, which was indeed the case

during our initial experiments. 3G is independent from both Bluetooth and WiFi, so the combination

of 3G and either WiFi or Bluetooth does not reduce the transmission rate. For the local connection,

we use WiFi instead of Bluetooth because it can support a larger number of connections at higher

rates, and more importantly, Bluetooth does not support broadcast, which was a necessary ingredient

for achieving MicroCast’s benefits.

In practice, the Android connectivity manager imposes additional challenges when 3G is uti-

lized simultaneously with WiFi. In particular, in order to improve the battery life, every time the

WiFi interface is activated, Android turns the 3G interface off. We solve this problem using an

undocumented API that forces routing of packets from the remote server through the 3G interface,

therefore preventing the interface from being shut down.

VI. PERFORMANCE EVALUATION

In this section, we provide simulation results of the NUM solution (Section VI-A) and exper-

imental evaluation of the implemented MicroCast Android prototype (SectionVI-B). We find that

(i) the results obtained from analysis agree with experimental evaluation and (ii) MicroCast brings

significant performance benefits, in terms of common download rate, compared to state-of-the-art

cooperation schemes in the “micro” setting, without significant battery penalty.

A. Simulation of NUM Solution

1) Simulation Setup: First, we simulate our NUM solutions in Matlab. We consider the topology

shown in Fig. 1 (b). The simulation includes 1000 iterations, and each simulation is repeated for

10 different random seeds. At each iteration t, each link (corresponding to cellular or WiFi) is in

the ON or OFF state according to the loss probabilities: pi and pi,j . If a link is on OFF state,

the transmitted packet is considered lost; otherwise, it is considered as successfully delivered. The

utility function employed in our simulations is U(x) = log(x).

1 2 3 4 5 60.8

1

1.2

1.4

1.6

1.8

2

Number of Devices

Ave

rage

Thr

ough

put p

er D

evic

e

Pseudo−BroadcastUnicastPseudo−Broadcast & No−NCNo−Coop

(a) pi,j = 0

1 2 3 4 5 60.8

1

1.2

1.4

1.6

1.8

2

Number of Devices

Ave

rage

Thr

ough

put p

er D

evic

e

Pseudo−BroadcastUnicastPseudo−Broadcast & No−NCNo−Coop

(b) pi,j = 0.2

Fig. 4. Throughput versus number of devices. Parameters: Ci = 1, pi = 0, and Ci,j = 1 for i, j ∈ {1, 2, 3}. These figuresdemonstrate the following points. (1) Throughput Benefit: MicroCast can increase the common throughput by a factor up tothe number of devices: in the beginning it grows linearly with the number of devices, then sublinearly, as the local network startsbecoming the bottleneck. (2) Effect of Broadcast: Local cooperation with broadcast significantly outperform local cooperation withunicast because it alleviates congestion in the local network. (3) Effect of Network Coding: Network Coding, combined withBroadcast, helps when there is loss, by making transmissions more useful.

We compare the following four schemes: Pseudo-Broadcast as a solution of P1 in Section IV;

Pseudo-Broadcast & No-NC as a solution of P1 without network coding, i.e., using Eq. (2) in

P1 instead of the fifth constraint; Unicast as a solution of P2 in Section IV; and No-Coop for a

baseline, which neither employs device-to-device connectivity nor collaboration. (We omit NUM

formulation and solution of No-Coop for brevity.)

2) Simulation Results: Next, we present the throughput results for different scenarios and poli-

cies. We choose some of the simulated scenarios to demonstrate the key points about the perfor-

mance of MicroCast. Additional simulation results can be found in [51].

Effect of Number of Devices. Fig. 4 shows the average throughput versus the number of devices

for the following parameters: Ci = 1, pi = 0, and Ci,j = 1 for i, j ∈ {1, 2, 3}. The average

throughput is calculated over all devices in the system. One can see that the throughput does

not change as the number of devices increases for the No-Coop scheme. This is because there

is no cooperation in the local area, so the number of devices does not affect the throughput. For

Unicast, the throughput increases as the number of devices increases, then reduces. The reason is

that cooperation in the local area helps initially. However, when the number of devices increases,

the local bandwidth is no longer sufficient to support all unicast transmissions, and the unicast

transmissions compete for their share of the local bandwidth. Hence, the overall throughput reduces.

The Pseudo-Broadcast and Pseudo-Broadcast & No-NC schemes achieve the same throughput

0 0.2 0.4 0.6 0.8 10.8

0.9

1

1.1

1.2

1.3

1.4

1.5

1.6

1.7

1.8

pij

Ave

rage

Thr

ough

put p

er D

evic

e

Pseudo−BroadcastUnicastPseudo−Broadcast & No−NCNo−Coop

(a) N = 3

0 0.2 0.4 0.6 0.8 10.8

0.9

1

1.1

1.2

1.3

1.4

1.5

1.6

1.7

1.8

pij

Ave

rage

Thr

ough

put p

er D

evic

e

Pseudo−BroadcastUnicastPseudo−Broadcast & No−NCNo−Coop

(b) N = 4

Fig. 5. Throughput versus local area loss probability. Parameters: (a) Ci = 1, pi = 0, Ci,j = 1, i, j ∈ {1, 2, 3}, and (b)Ci = 1, pi = 0, Ci,j = 1, i, j ∈ {1, 2, 3, 4}. These figures show that when there is local wireless loss, Network Coding combinedwith Broadcast performs much better than other schemes, and the improvement is larger when there are more devices.

levels in Fig. 4(a) (pi,j = 0). Both schemes improve the throughput as the number of devices

increases. The reason is that since the packets are broadcast, each transmitted packet will be

beneficial to more devices when the number of devices increases. Yet, the average throughput

of Pseudo-Broadcast & No-NC reduces after a threshold in Fig. 4(b) (pi,j = 0.2). This is because

when network coding is not employed, each individual packet should be successfully transmitted to

all other nodes in the local area. If it is not successfully delivered, the packet is re-transmitted. This

introduces inefficiency and reduces the average throughput. Meanwhile, Pseudo-Broadcast improves

the throughput as the number of devices increases and does not introduce inefficiency thanks to

network coding, which makes all packets equally beneficial.

Effect of Wireless Loss. Fig. 5 shows the average throughput versus the local area loss probability

(pi,j) for the following parameters: (a) Ci = 1, pi = 0, Ci,j = 1, for i, j ∈ {1, 2, 3}, and (b) Ci = 1,

pi = 0, Ci,j = 1, for i, j ∈ {1, 2, 3, 4}. One can observe that when there is local wireless loss, both

Pseudo-Broadcast and Pseudo-Broadcast & No-NC outperform Unicast. Pseudo-Broadcast has the

best performance thanks to network coding. In addition, the gap between Pseudo-Broadcast and

Pseudo-Broadcast & No-NC increases when the number of devices increases, i.e., when Fig. 5(a)

and Fig. 5(b) are compared. These show the benefit of using network coding and broadcast in the

presence of local wireless loss.

0100200300400500600700800900

1000

0 10 20 30 40 50 60 70 80 90 100

Dow

nloa

d Ra

te (K

bps)

Time (second)

Phone 1

Phone 2

Phone 3

(a) The cellular link rates of three smartphones in the samegeographical area.

0 10 20 30 40 50 60 70 80 90

MicroNC‐P2

Bittorent‐Pull

R2‐Push

Local Traffic Introduced by the Distributors (MB)

(a) Star Topology (b) Clique Topology

(b) The amount of local traffic introduced by four phoneswhen using different distributors.

Fig. 6. (a) Evaluation of MicroDownload: Despite being in close proximity and being connected to the same operator, threephones experience significantly different average download rates and rate variation. This motivates the design of MicroDownloadthat adaptively requests data according to individual phone rates. (b) Evaluation of MicroNC-P2: A 9.93 MB file is downloadedby one of the four phones, and its segments are exchanged among the phones. This figure shows that the amount of local trafficintroduced by MicroNC-P2 is about three times less than other schemes, thanks to Broadcast and Network Coding.

B. Experimental Evaluation of MicroCast

In this part, we perform an experimental evaluation of the system using the Android prototype of

MicroCast. First, we evaluate the performance of key components alone, namely MicroDownload

and MicroNC-P2, and compare their performance to baseline popular alternatives. We then evaluate

the entire MicroCast system as a whole. We show that the proposed system significantly improves the

streaming experience in terms of performance (download time and video rate), without introducing

significant energy cost.

We perform experiments on an Android testbed consisting of seven smartphones: four Samsung

Captivate and three Nexus S. All smartphones have a 1 Ghz Cortex-A8 CPU and 512 MB RAM.

Six of them use Android Gingerbread (2.3) and one (Nexus S) uses Android Ice Scream Sandwich

(4.0) as their operating systems. In all experiments involving network coding, we use the native

coding scheme (described in Section V-B) with generation size m = 25 and packet size n = 900

bytes. The current implementation cannot support more than 7 (or 6) concurrent devices when an

Android 4.0 (or 2.3) device acts as the access point (AP). This is due to the limitation of the soft

AP currently implemented in Android.

MicroDownload Evaluation. Here, we present experimental results that motivate the necessity

of MicroDownload and we show its effectiveness. The setup is the following: we use three Nexus S

connected to the same cellular network provider, and place them within proximity of each other (the

(a) Space-Time Diagram of BitTorrent-Pull (b) Space-Time Diagram of R2-Push

Fig. 7. (a) BitTorrent-Pull: When a phone has downloaded a new segment, it advertises this segment to a neighbor; the neighborthen explicitly requests the segments that it is missing; the phone then sends the requested segments. (b) R2-Push: A phone startspushing coded packets to a neighbor as soon as it receives some packets from either the cellular network or the other neighbors.The pushing stops when a certain number of coded packets has been sent or a brake message is received.

distances among them are approximately 2 cm) in an indoor environment. The phones are placed

in their positions 5 minutes before the experiment to eliminate any possible positive or negative

bias due to mobility.

In our experiment, we disable MicroNC-P2, and we measure the download rates of the smart-

phones over 100 seconds. The results are presented in Fig. 6 (a). The figure shows that despite being

in close proximity and being connected to the same operator, the phones experience significantly

different average download rates. Phone 3 has a very low rate because it uses EDGE. The other two

phones use the same 3G network but still have significantly different download rates. Moreover,

phone 1 experiences significant rate variations. This variability in time and across phones is our

motivation to develop MicroDownload – to adaptively request data according to the rates of the

cellular links, instead of making static decisions, such as, splitting the requests equally among the

phones.

Using these measurements, we can compare the effectiveness of MicroDownload to a simpler

static strategy. We consider a scenario where the three phones download a 750 kB file, and

MicroDownload makes a static decision: each phone requests one third of the file. In this case, phone

3 (considering the same channel realization as in Fig. 6 (a)) is the bottleneck for downloading the

file, and the total download duration is 80 seconds. However, if MicroDownload makes adaptive

requests, as proposed in Section V-A, then phone 3 is not a bottleneck anymore, and the total

download duration is less than 10 seconds. This shows the importance of the adaptive request

mechanism of MicroDownload.

MicroNC-P2 Evaluation. Here, we compare the performance of MicroNC-P2 to a BitTorrent-

based distributor [31] and an R2-based distributor [28]. We refer to these two distributors as

BitTorrent-Pull and R2-Push, respectively. Packets are exchanged locally using UDP. The per-

formance metric of interest is the amount of local network traffic introduced by the phones when

using different distributors to disseminate the same amount of information.

We implement the BitTorrent-Pull scheme based on the description of the BitTorrent protocol

[31]. In particular, our implementation of the protocol supports three main types of messages: (i)

bitfield and have messages, which are used by a phone to advertise the segments to its neighbors;

(ii) request messages, which are used by a phone to request specific segments from its neighbors;

and (iii) piece messages, which contain the actual data. The space-time diagram of BitTorrent-Pull

is provided in Fig. 7(a). Fundamentally, BitTorrent is a pull-based P2P protocol: when a phone

has downloaded a new segment, it advertises this segment to its neighbors. The neighbors then

explicitly request the segments that they are missing. To account for the wireless loss (when using

UDP), we implement a recovery thread which periodically re-requests missing segments.

We implement the R2-Push scheme based on its description in [28]. The R2 protocol was

introduced to exploit the benefit of random network coding and random push. Following [28],

our implementation of R2-Push supports two main types of messages: (i) data messages, which are

random linear combinations of packets belonging to the same segment; and (ii) brake messages,

which are used by phones to inform their neighbors that they successfully received and decoded

specific segments. The purpose of brake messages is to ensure that the neighbors would stop pushing

(unnecessary) linear combinations of the decoded data segments.

The space-time diagram of R2-Push is provided in Fig. 7(b). In contrast to BitTorrent-Pull, with

R2-Push, the phones start pushing linear combinations of packets as soon as they receive them from

either the cellular network or their neighbors. In our implementation, for a particular segment a

phone is downloading, we limit the number of linear combinations that it can push to its neighbors

to the rank of the matrix formed by the received packets plus a fixed amount of redundancy, ∆, to

account for the wireless loss rate.

Fig. 6 (b) shows the total amount of traffic introduced to the local network by four phones

to disseminate a file when the phones are connected using star and clique topologies. In the star

topology, all phones connect to the access point phone. Meanwhile, in the clique topology, all

phones connect to any other phone. In both topologies, all phones overhear all the transmissions

in the group. MicroNC-P2 utilizes pseudo-adhoc as described in Section V-C. The file size is 9.93

MB and is downloaded by a single phone using its 3G connection. The average rate of the 3G

connection is measured at 550 Kbps. The phone that downloads the file is chosen at random. For

0.0

0.5

1.0

1.5

2.0

2.5

1 2 3 4 5 6 7Aver

age

Dow

nloa

d Ra

te (M

bps)

Number of Phones

(a) Average download rate as a functionof number of phones in a non-congestedlocal network.

2 Mbps

2.5 Mbps2.4 Mbps

2.7 Mbps

2.6 Mbps

1.4 Mbps

3.4 Mbps

6.1 Mbps

8.8 Mbps

10.9 Mbps

12.8 Mbps

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7

Amou

nt o

f Loc

al T

raffi

c (M

B)

Number of Phones

MicroCast BitTorent-Pull No-Cooperation

(b) The amount of local traffic intro-duced by all phones in a non-congestedlocal network.

0.0

0.5

1.0

1.5

2.0

2.5

1 2 3 4 5 6 7

Aver

age

Dow

nloa

d Ra

te (M

bps)

Number of Phones

(c) Average download rate as a functionof number of phones when the localnetwork bandwidth is less than 4 Mbps.

Fig. 8. Evaluation of MicroCast. Up to 7 phones, 4 of which have 3G, cooperatively download a 9.93 MB file using differentschemes. Although Fig. (a) shows similar average download rates for both MicroCast and BitTorrent-Pull, Fig. (b) reveals thatBitTorrent-Pull introduces a much larger amount of local traffic, which is detrimental in terms of the average download rate incongested local networks. Indeed, Fig. (c) shows that MicroCast still improves the average download rate up to the total capacityof the 3G links (of four phones) in a congested network, while the download rate of BitTorrent-Pull reduces when there are morethan three phones, due to congestion. Observe that practice agrees with theory: Fig (c) is consistent with the results presented inFig. 4.

R2-Push, we choose ∆ = 3%. The local network can support 20 Mbps UDP traffic, measured using

iperf [59]. This bandwidth is much larger than what is needed to support the traffic introduced by

the phones in both topologies. Since the local network bandwidth is sufficient, each of the phone

receives at the rate similar to the phone which downloads the file through 3G. Each reported number

is averaged over three experiments.

We first observe from Fig. 6 (b) that the amount of traffic introduced by both BitTorrent-Pull

and R2-Push are more than three times higher than that of MicroNC-P2. Intuitively, this is due to

the fact that when using MicroNC-P2, a packet sent by a phone may be beneficial to three phones

instead of one thanks to network coding and overhearing. Fig. 6 (b) also shows that in a clique

topology, R2-Push introduces much more traffic as compared to the star topology. This is because

in a clique topology, a phone may simultaneously receive linear combinations of the same segment

from multiple neighbors. When this happens, it is critical that the neighbors which are sending to

this phone stop pushing linear combinations in a timely manner. This could only be achieved with

a timely arrival of the brake (stop) messages, which is not always possible in the clique topology,

or in a setup where additional traffic is very high. The authors of R2 also observed the problem

and reported it in [29].

In summary, the set of experimental results presented above show that by exploiting network

coding and the broadcast nature of the wireless medium, MicroNC-P2 manages to introduce less

amount of traffic into the local network as compared to BitTorrent-Pull and R2-Push.

MicroCast Evaluation: Throughput. Here, we present the performance evaluation of the entire

MicroCast system. We compare the average download rates of MicroCast to two other schemes: no

cooperation, which we will refer to as No-Cooperation, and the combination of MicroDownload

and BitTorrent-Pull, which we will simply refer to as BitTorrent-Pull. Note that we do not include

R2-Push as a baseline in this section due to its inefficiency in our setup, as explained above.

In our experimental setup, we use up to seven phones. The first four phones have 3G rates

varying from 480 Kbps to 670 Kbps; the rest of the phones do not have 3G connections. Packets

are exchanged locally using UDP. The local network can support up to 20 Mbps UDP traffic.

We use the star topology and pseudo-adhoc for MicroCast, and we use the clique topology for

BitTorrent-Pull. The size of the video file is 9.93 MB. Each value reported is averaged over three

experiments.

Fig. 8 (a) shows the average download rate versus the number of phones. We observe that both

MicroCast and BitTorrent-Pull are able to improve the average download rate up to the total capacity

of the 3G links. Note that MicroCast and BitTorrent-Pull do not provide any improvement for more

than four phones because only four phones have 3G connections. Fig. 8 (b) shows the amount of

local traffic versus the number of phones. Although in Fig. 8 (a) we see similar average download

rates for both MicroCast and BitTorrent-Pull, Fig. 8 (b) shows that BitTorrent-Pull introduces a much

larger amount of local traffic, which increases linearly in the number of phones, when compared

to MicroCast. This behavior of BitTorrent-Pull is detrimental in terms of the average download

rate in congested networks. An important observation is that, as the number of phones increases,

MicroCast’s local traffic does not increase. This indicates that, even when there are many phones,

overheard packets are lost very rarely.

We then update our experimental setup to evaluate the performance of MicroCast and BitTorrent-

Pull in a congested network. In our new setup, the congested network is generated by introducing

16 Mbps background UDP traffic on the same 802.11 channel. (Note that there is also interference

from other sources in the environment which contributes to the background traffic.) Since the local

network can support up to 20 Mbps traffic, the leftover traffic is less than 4 Mbps. Fig. 8 (c)

presents the average download rate versus the number of phones in this setup. We see that the

average download rate of BitTorrent-Pull reduces when we have more than three phones. This is

because BitTorrent-Pull introduces a large amount of local traffic (as illustrated in Fig. 8 (b)), which

leads to congestion. Note that the addition of the fifth, sixth, and seventh phones also increases the

local traffic in BitTorrent-Pull even though they do not have 3G connection. This is because they

still need to receive the file in the local area, which contributes to the local area traffic.

94.00%

95.00%

96.00%

97.00%

98.00%

99.00%

100.00%

0 200 400 600 800 1000 1200

Battery Pe

rcen

tage

Time (second)

No‐Cooperation

MicroNC‐2PNormal

MicroNC‐2PAccess Point

BitTorrent‐PullNormal

BitTorrent‐PullAccess Point

(a) Battery drain when downloading the same file of size95.4 MB using different schemes.

01020304050607080

5 15 25 35 45 55 65

Rate (M

bps)

Number of Packets per Segment

DecodingJava

DecodingNative

EncodingJava

EncodingNative

(b) Coding and decoding throughput as a function of thegeneration size. Each packet is 900-byte long.

Fig. 9. Beyond video throughput. (a) Evaluation of energy consumption: No-Cooperation consumes less battery per unit timebut takes longer to download the file compared to the other. Battery levels of all schemes are similar when the file transmission iscompleted. This demonstrates that employing cooperation, in the long term does not bring any significant battery cost. (b) Evaluationof network coding implementations: Observe that the coding rate is much higher when using the native implementation. The figureshows that it is possible to support high rate network coding on commodity phones – more than sufficient to support current standardvideo streaming rates.

In contrast, Fig. 8 (c) shows that MicroCast still improves the average download rate up to the

total capacity of the 3G links (of four phones) in a congested network. This is because it introduces

only a small amount of local traffic (e.g., even for seven phones, MicroCast only introduces 2.6

Mbps traffic to the local network as in Fig. 8 (b)). It can be observed from Fig. 8 (c) that the average

download rate of MicroCast is more than three times higher than that of No-Cooperation. Also,

the improvement of MicroCast over BitTorrent-Pull in terms of average download rate is as high

as 75% (we observed even more improvement for different setups, e.g., with 18 Mbps background

traffic), which is significant.

The result demonstrated in Fig. 8 (c) is consistent with the simulation results presented in Section

VI-A (Fig. 4). In practice, for the BitTorrent-Pull (and the unicast policy), the point at which adding

an additional device hurts the average download rate depends on a number of factors, mainly how

congested the local network is currently, the cellular rates of the existing devices, and the video

rate. As shown in Fig. 4, the adding of the third device to the group immediately reduces the

average download rate; meanwhile, in Fig. 8 (c), this does not happen until the addition of the

fourth device.

MicroCast Evaluation: Energy Consumption. We compare the energy consumption of Micro-

Cast with the baselines: BitTorrent-Pull and No-Cooperation, when downloading a video file. We

consider a star topology similar to the one above: three phones connect to the fourth one that acts

as the access point (AP). All phones have 3G with rates varying from 450 Kbps to 700 Kbps, and

the size of the video file is 95.4 MB. We use the BatteryManager class of the Android SDK for the

power consumption measurements. Before the experiment, all four phones are fully charged. During

the experiment, the battery states are recorded every 10 seconds. The experiments are repeated three

times, and their average is reported.

Fig. 9 (a) presents the battery state (100% corresponds to the fully charged battery) versus

time. Note that “MicroNC-P2 Access Point” and “BitTorrent-Pull Access Point” show the battery

consumption levels of the phones selected to act as the APs in MicroCast and BitTorrent-Pull,

respectively. Meanwhile, “MicroNC-P2 Normal” and “BitTorrent-Pull Normal” show the battery

consumption levels of phones which are not the APs. It can be observed from Fig. 9 (a) that the

No-Cooperation scheme has less battery consumption compared to MicroCast and BitTorrent-Pull

at any given time within 0 and 600 second. However, the time required to download the video

file when using No-Cooperation is very high (more than two times as compared to MicroCast and

BitTorrent-Pull).

Observing the battery levels of all schemes when the file transmission is completed, one can

see that the battery consumption levels of No-Cooperation, MicroCast, and BitTorrent-Pull are

similar. This demonstrates that employing cooperation, in the long term (to download a video file),

does not bring any significant battery cost. Finally, the phones which act as APs consume more

battery than the other phones. This is expected because the AP phone has to perform additional

tasks (scheduling packets, maintaining connection, etc.). Nevertheless, even in the worst case, for

the AP phone, MicroCast consumed approximately 6% of the battery to download the whole file.

Considering that the phones are downloading a large file (95.4 MB), this battery consumption level

is reasonable. These considerations show that the rate benefit of MicroCast comes at no significant

battery cost.

Network Coding Evaluation. We evaluate the performance of the two implementations of network

coding we developed: native (written in C) and Java-based coding. The two implementations are

described in Section V-B. Fig. 9 (b) shows the decoding and encoding data rates as a function of

the generation size. The slowest encoding rate for the Java implementation is 1 Mbps, while for

the native implementation, it is 8 Mbps. Fig. 9 (b) also shows that coding rate is much higher

when using the native implementation. In conclusion, we find that it is possible to support high

rate network coding on commodity phones, more than sufficient to support current standard video

streaming rates (a standard YouTube 480p video rate is 2.5 Mbps [60]).

VII. CONCLUSION

In this work, we proposed a cooperative system for video streaming to a group of mobile device

users, who are within proximity of each other, and are all interested in viewing the same video at

roughly the same time. The proposed system is grounded on a NUM formulation and its distributed

solution. The system cooperatively uses the network resources on all devices of the group, such

as, cellular and WiFi links, to improve the streaming experience. We evaluate the proposed system

through both simulation and experimentation by implementing a full working prototype on the

Android platform. Evaluation results demonstrate significant performance benefits in terms of

per-user video download rate without significant battery penalty. Additional materials and video

demonstration can be found at [5].

REFERENCES

[1] Cisco, “Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2010 - 2015.” [Online]. Available:

http://goo.gl/9w09D

[2] P. Goldstein, “Credit Suisse report: U.S. wireless networks running at 80% of total capacity.” [Online]. Available:

http://goo.gl/0Yq12

[3] M. Sullivan, “A Day in the Life of 3G.” [Online]. Available: http://goo.gl/3fVvG

[4] Google, “Gen V Research, Men 18 - 34: The on-demand video consumer.” [Online]. Available: http://www.youtube.com/yt/

advertise/medias/pdfs/research-gen-v-men-2.pdf

[5] “Project Page: Wireless Network Coding: From Theory to Practice.” [Online]. Available: http://microcast.calit2.uci.edu

[6] S. Ioannidis, A. Chaintreau, and L. Massoulie, “Optimal and scalable distribution of content updates over a mobile social

network,” in Proc. of IEEE INFOCOM, Apr. 2009, pp. 1422–1430.

[7] B. Han, P. Hui, V. A. Kumar, M. V. Marathe, G. Pei, and A. Srinivasan, “Cellular traffic offloading through opportunistic

communications: a case study,” in Proc. of ACM CHANTS, Sept. 2010, pp. 31–38.

[8] J. Whitbeck, M. Amorim, Y. Lopez, J. Leguay, and V. Conan, “Relieving the wireless infrastructure: When opportunistic

networks meet guaranteed delays,” in Proc. of IEEE(WoWMoM, June 2011, pp. 1–10.

[9] P. Hui, J. Crowcroft, and E. Yoneki, “Bubble rap: social-based forwarding in delay tolerant networks,” in Proc. of ACM

MobiHoc, May 2008, pp. 241–250.

[10] C. Boldrini, M. Conti, and A. Passarella, “Exploiting users’ social relations to forward data in opportunistic networks: The

HiBOp solution,” Pervasive and Mobile Computing, vol. 4, no. 5, pp. 633–657, Oct. 2008.

[11] C. Tsao and R. Sivakumar, “On effectively exploiting multiple wireless interfaces in mobile hosts,” in Proc. of ACM CoNEXT,

Dec. 2009, pp. 337–348.

[12] H. Soroush, P. Gilbert, N. Banerjee, M. D. Corner, B. N. Levine, and L. Cox, “ Spider: improving mobile networking with

concurrent wi-fi connections,” SIGCOMM CCR, vol. 41, no. 4, pp. 402–403, Aug. 2011.

[13] P. Rodriguez, R. Chakravorty, J. Chesterfield, I. Pratt, and S. Banerjee, “MAR: a commuter router infrastructure for the mobile

internet,” in Proc. of ACM MobiSys, June 2004, pp. 217–230.

[14] J. Chesterfield, R. Chakravorty, I. Pratt, S. Banerjee, and P. Rodriguez, “Exploiting diversity to enhance multimedia streaming

over cellular links,” in Proc. of IEEE INFOCOM, Mar. 2005, pp. 2020–2031.

[15] M. Stiemerling and S. Kiesel, “A system for peer-to-peer video streaming in resource constrained mobile environments,” in

Proc. of ACM U-NET, Dec. 2009, pp. 25–30.

[16] G. Ananthanarayanan, V. N. Padmanabhan, L. Ravindranath, and C. A. Thekkath, “COMBINE: leveraging the power of wireless

peers through collaborative downloading,” in Proc. of ACM MobiSys, June 2007, pp. 286–298.

[17] X. Liu, G. Cheung, and C. Chuah, “Rate-distortion optimized network coding for cooperative video stream repair in wireless

peer-to-peer networks,” in Proc. of IEEE WoWMoM, June 2008, pp. 1–6.

[18] S. Li and S. Chan, “BOPPER: wireless video broadcasting with peer-to-peer error recovery,” in Proc. of IEEE ME, July 2007,

pp. 392–395.

[19] J. B. Saleh, D. Qiu, and A. K. Elhakeem, “Performance of an efficient scheduling approach to network coding for wireless

local repair,” Cyber Journals: JSAT, vol. 2, no. 1, pp. 49–58, Jan. 2011.

[20] M. Pedersen and F. Fitzek, “Implementation and performance evaluation of network coding for cooperative mobile devices,”

in Proc. of IEEE ICC, May 2008, pp. 91–96.

[21] M. Pedersen, J. Heide, F. Fitzek, and T. Larsen, “PictureViewer - a mobile application using network coding,” in Proc. of

European Wireless Conference, May 2009, pp. 151–156.

[22] P. Vingelmann, M. Pedersen, F. Fitzek, and J. Heide, “On-the-fly packet error recovery in a cooperative cluster of mobile

devices,” in Proc. of IEEE GLOBECOM, Dec. 2011, pp. 1–6.

[23] M. Ramadan, L. El Zein, and Z. Dawy, “Implementation and evaluation of cooperative video streaming for mobile devices,”

in Proc. of IEEE PIMRC, Sept. 2008, pp. 1–5.

[24] S. Hua, Y. Guo, Y. Liu, H. Liu, and S. Panwar, “Scalable video multicast in hybrid 3G/Ad-Hoc networks,” IEEE Transactions

on Multimedia, vol. 13, no. 2, pp. 402–413, Apr. 2011.

[25] C. Gkantsidis and P. Rodriguez, “Network coding for large scale content distribution,” in Proc. of IEEE INFOCOM, Mar.

2005, pp. 2235–2245.

[26] M. Wang and B. Li, “How practical is network coding?” in Proc. of IEEE IWQoS, June 2006, pp. 274–278.

[27] ——, “Lava: A reality check of network coding in peer-to-peer live streaming,” in Proc. of IEEE INFOCOM, May 2007, pp.

1082–1090.

[28] ——, “R2: Random push with random network coding in live peer-to-peer streaming,” IEEE JSAC, vol. 25, no. 9, pp. 1655–

16 668, Dec. 2007.

[29] Z. Liu, C. Wu, B. Li, and S. Zhao, “UUSee: Large-scale operational on-demand streaming with random network coding,” in

Proc. of IEEE INFOCOM, Mar. 2010, pp. 1–9.

[30] B. Li and D. Niu, “Random network coding in peer-to-peer networks: From theory to practice,” Proceedings of the IEEE,

vol. 99, no. 3, pp. 513–523, Mar. 2011.

[31] B. Cohen, “Incentives build robustness in BitTorrent,” in Proc. of Workshop on Economics of P2P Systems, June 2003.

[32] M. Chiang, T. S. Low, A. R. Calderbank, and J. C. Doyle, “Layering as optimization decomposition: a mathematical theory

of network architectures,” Proceedings of the IEEE, vol. 95, no. 1, pp. 255–312, Jan. 2007.

[33] R. Srikant, The mathematics of Internet congestion control. Birkhauser, 2003.

[34] D. S. Lun, N. Ratnakar, M. Medard, R. Koetter, D. R. Karger, T. Ho, E. Ahmed, and F. Zhao, “Minimum-cost multicast over

coded packet networks,” IEEE Trans. Info Theory, vol. 52, no. 6, pp. 2608–2623, June 2006.

[35] L. Chen, T. Ho, S. Low, M. Chiang, and J. C. Doyle, “Optimization based rate control for multicast with network coding,” in

Proc. of IEEE INFOCOM, May 2007, pp. 1163–1171.

[36] J. Yuan, Z. Li, W. Yu, and B. Li, “A cross-layer optimization framework for multi-hop multicast in wireless mesh networks,”

IEEE JSAC, vol. 24, no. 11, pp. 2092–2103, Nov. 2006.

[37] Z. Li, B. Li, and M. Wang, “Optimization models for streaming in multihop wireless networks,” in Proc. of IEEE ICCCN,

Aug. 2007, pp. 457–463.

[38] M. Chen, M. Ponec, S. Sengupta, J. Li, and P. A. Chou, “Utility maximization in peer-to-peer systems,” in Proc. of ACM

Sigmetrics, June 2008, pp. 169–180.

[39] Z. Shao, S. Y. R. Li, W. Yu, and B. Li, “To code or not to code: rate optimality of network coding versus routing in peer-to-peer

networks,” IEEE Trans. Communications, vol. 59, no. 4, pp. 948–954, Apr. 2011.

[40] S. Liu, R. Z. Shen, W. Jiang, J. Rexford, and M. Chiang, “Performance bounds for peer-assisted live streaming,” in Proc. of

ACM Sigmetrics, June 2008, pp. 313–324.

[41] C. Liang, M. Zhao, and Y. Liu, “Optimal bandwidth sharing in multiswarm multiparty p2p video-conferencing systems,”

IEEE/ACM ToN, vol. 19, no. 6, pp. 1704–1716, Dec. 2011.

[42] M. Ponec, S. Sengupta, M. Chen, J. Li, and P. A. Chou, “Multi-rate peer-to-peer video conferencing: a distributed approach

using scalable coding,” in Proc. of IEEE ICME, June 2009, pp. 1406–1413.

[43] D. C. Tomozei and L. Massoulie, “Flow Control for Cost-Efficient Peer-to-Peer Streaming,” in Proc. of IEEE INFOCOM,

Mar. 2010, pp. 1–9.

[44] S. Katti, H. Rahul, W. Hu, D. Katabi, M. Medard, and J. Crowcroft, “XORs in the air: Practical wireless network coding,”

IEEE/ACM ToN, vol. 16, no. 3, pp. 497–510, June 2008.

[45] Y. Park, C. Jo, S. Yun, and H. Kim, “Multi-Room IPTV delivery through Pseudo-Broadcast over IEEE 802.11 links,” in Proc.

of IEEE VTC, May 2010, pp. 1–5.

[46] S. Sen, N. K. Madabhushi, and S. Banerjee, “Scalable WiFi media delivery through adaptive broadcasts,” in Proc. of USENIX

NSDI, May 2010, pp. 1–13.

[47] L. Keller, E. Atsan, K. Argyraki, and C. Fragouli, “SenseCode: Network coding for reliable sensor networks,” ACM TOSN,

vol. 19, no. 2, pp. 25:1–25:20, Mar. 2013.

[48] H. Shojania and B. Li, “Random network coding on the iPhone: fact or fiction?” in Proc. of NOSSDAV, June 2009, pp. 37–42.

[49] ——, “Tenor: making coding practical from servers to smartphones,” in Proc. of MM, Oct. 2010, pp. 45–54.

[50] Y. Feng, Z. Liu, and B. Li, “GestureFlow: streaming gestures to an audience,” in Proc. of IEEE INFOCOM, Apr. 2011, pp.

748–756.

[51] H. Seferoglu, L. Keller, B. Cici, A. Le, and A. Markopoulou, “Cooperative Video Streaming on Smartphones,” in Proc. of

Allerton, Sept. 2011, pp. 220–227.

[52] L. Keller, A. Le, B. Cici, H. Seferoglu, C. Fragouli, and A. Markopoulou, “MicroCast: Cooperative VideoStreaming on

Smartphones,” in Proc. of ACM MobiSys, June 2012, pp. 57–70.

[53] P. Gupta and P. R. Kumar, “The capacity of wireless networks,” IEEE Trans. Info. Theory, vol. 34, no. 5, pp. 388–404, Mar.

2000.

[54] P. Chou and Y. Wu, “Network coding for the Internet and wireless networks,” IEEE Signal Processing Magazine, vol. 24,

no. 5, pp. 77–85, Sept. 2007.

[55] H. Seferoglu, L. Keller, B. Cici, A. Le, and A. Markopoulou, “Cooperative Video Streaming on Smartphones.” [Online].

Available: http://www.mit.edu/∼hseferog/allerton2011 tech.pdf

[56] C. Fragouli and E. Soljanin, Network Coding Fundamentals. Now Publishers Inc, June 2007.

[57] R. Chandra, S. Karanth, T. Moscibroda, V. Navda, J. Padhye, R. Ramjee, and L. Ravindranath, “DirCast: a practical and

efficient Wi-Fi multicast system,” in Proc. of IEEE ICNP, Oct. 2009, pp. 161–170.

[58] C. Team, “Cyanogen Mod.” [Online]. Available: http://www.cyanogenmod.com

[59] NLANR/DAST, “IPerf.” [Online]. Available: http://sourceforge.net/projects/iperf

[60] YouTube, “Advanced Encoding Settings.” [Online]. Available: http://support.google.com/youtube/bin/answer.py?hl=

en&answer=1722171