A Cloud-Assisted Energy-Efficient Video Streaming System for Smartphones

Transcription

1 A Cloud-Assisted Energy-Efficient Video Streaming System for Smartphones Mohammad Reza Zakerinasab, Mea Wang Department of Computer Science University of Calgary {mrzakeri, Abstract Due to the increasing deployment of 3G/4G technologies and the growing computing power of modern smartphones, video streaming is one of the most popular applications on these devices. In this paper, we propose an energy-efficient multimedia streaming system for smartphones. This system simultaneously utilizes two communication channels: cellular links carrying streaming content from the media Cloud to smartphones and WiFi links enabling cooperation among smartphones. There are three key contributions. First, the system copes with the variable loss rate and bandwidth fluctuation, common problems in wireless communication, by taking advantage of a novel two-level coding scheme. Second, the system reduces energy consumption due to network coding operations, by utilizing the copious computing resources in the Cloud. Consequently, XORonly network coding is sufficient for sharing among smartphones. Third, we propose a light-weight distributed scheduling algorithm to manage collaboration and content sharing among the neighbouring nodes. The proposed local dissemination scheme, along with the proposed two-level coding scheme, outperforms state-ofthe-art streaming systems in cellular networks. Our experimental results show that our proposed system saves up to 73% of battery usage on each phone compared to the current streaming mechanism over a 3G network. In addition, the system is capable to support higher quality streaming and decrease the streaming delay. I. INTRODUCTION Due to the increasing deployment of 3G/4G technologies and the growing computing power of modern smartphones, video streaming is one of the most popular applications on these devices. Cisco reported that video streaming constitutes approximately 5% of the current cellular network traffic, and is expected to reach 66% by 217 [1]. However, the variable loss rate and bandwidth fluctuation in cellular networks pose challenges to video streaming, as such systems are very sensitive to delays and losses. On one hand, we can improve the signals in cellular networks. On the other hand, we can utilize short-range links such as WiFi and bluetooth to increase the overall link capacity around individual smartphones. In this paper, we are interested in the latter approach. The utilization of short-range links leads to higher data rate and shorter delays, essential performance metrics for multimedia streaming. Furthermore, according to [2], such an arrangement also improves the energy efficiency on smartphones, as the energy per bit ratio of short-range links is less than that of cellular links. Fig. 1 depicts an overview of a collaborative multimedia streaming system for smartphones. The multimedia content is made available by the source, nowadays mostly powered by the Cloud, and is streamed to smartphones through cellular networks. Devices that are within each other s WiFi/Bluetooth Fig. 1. Video Source Downlinks (3G/4G/LTE) Cooperation Links (WiFi, Bluetooth) An overview of a collaborative streaming system for smartphones signal range may be considered as a group. Assuming all devices are cooperative, they can form a data swarming session to share their received content over WiFi/Bluetooth connections. Such a way of combining different wireless communication channels was initially proposed in [3], [4]. The benefit of doing so is to increase the receiving throughput of each device, while reducing the stress in the cellular network. In this paper, we seek to reduce the energy consumed by multimedia streaming on smartphones by utilizing multiple wireless communication channels as described above. Without loss of generality, we resort to 3G as our cellular network technology and WiFi as our short-range communication. We will focus on the interactions among smartphones within a single WiFi network, as the design will be same for each WiFi network. There are two main challenges in designing an energy-efficient collaborative video streaming system. First, all wireless connections are subject to channel fading and have considerably higher loss rates than wired connections. For each lost packet, a retransmission has to be performed, if the conventional forward error correction (FEC) cannot recover the corrupted bits of a packet. Many coding techniques have been proposed to cope with such losses, without imposing additional delays or retransmissions. In particular, network coding (NC), to be briefly reviewed in Sec. II, is known for its advantage in maximizing the gain of each retransmission [5], [6] in wireless communication, as it allows any retransmitted packet to be used to recover any lost packet. Second, the effectiveness of bandwidth utilization, in such a collaborative network of smartphones, is subject to segment scheduling among various links. Towards efficient bandwidth

2 utilization, Keller et. al [7] proposed the MicroCast system, in which one specific phone manages the scheduling of segment transmission on all other phones in the network. The design principle is to avoid using 3G links as much as possible, and to encourage data swarming within the WiFi network. Although MicroCast achieves good streaming rates by utilizing both 3G and WiFi channels, as well as the overhearing feature in wireless communication, it suffers from two main deficiencies. First, the scheduling algorithm is a centralized algorithm that introduces unnecessary messaging and management overhead. Second, it is not energy efficient as it imposes unnecessary computation burden on the phones due to the large field size used in NC operations. In this paper, we address these challenges and propose an energy-efficient cloud-assisted streaming system for smartphones. The energy saving is achieved through a two-level systematic NC and transmission scheme. At the top level, the multimedia content is streamed from the Cloud hosting the video source to a WiFi group formed by smartphones. At the bottom level, received content is shared among smartphones within a WiFi network. The content is transmitted in both verbatim form and coded form in Galois Field GF(2). Furthermore, to manage collaboration and content sharing in the WiFi network, we propose a light-weight distributed scheduling algorithm. We verify the design through a simulator that is driven by the energy profile of a Samsung Galaxy phone. Our experimental results show that our proposed system saves up to 73% of battery usage on each phone compared to the current streaming mechanism over the 3G network. The remainder of this paper is organized as follows. Sec. II reviews existing proposals on combining multiple wireless channels, and the use of NC in such systems. Sec. III presents our two-level NC and transmission scheme, followed by the proposed distributed scheduling algorithm. The performance evaluation is presented in Sec. IV. Finally, Sec. V concludes the paper. II. RELATED WORKS A. Cooperation in Mobile/Wireless Systems The idea of utilizing WiFi communication among cooperative smartphones was originally proposed in [3], in which unicast connections over WiFi are used to locally distribute data. The main motivation for utilizing opportunistic communication over local-short range links, e.g., Bluetooth and WiFi, in mobile devices is to offload the cellular traffic, while maintaining short delays [4], [8], [9]. For example, a system may stream video segments over WiFi and share error recovery code over Bluetooth [1], or schedule transmission over multiple WiFi hotspots [11] to receive one flow of data. Furthermore, in [12], [13], mobile phone users use social relationships along with the geographical proximity to disseminate information stored on the devices through WiFi instead of cellular link, which is a special case of the problem covered in this paper. In [14], [15], the same idea has been extended to simultaneous Internet connections over cellular and WiFi channels. Similarly, by exploiting multiple cellular and WiFi connections, digital content may be delivered to mobile devices over multiple paths [16]. In this paper, we share the similar vision on utilizing both the cellular networks and WiFi communication opportunities to improve the quality of multimedia streaming on smartphone devices while conserving energy. More specifically, different parts of the video are streamed to different smartphones over cellular network, and then the smartphones that are within each others WiFi range exchange received data with each other. The use of WiFi communication greatly reduces the traffic over cellular networks, and our energy analysis indicates that transmitting over WiFi networks is more than five times energy efficient than transmitting over 3G links. Our main goal is to allow each user to enjoy the aggregated downlink for an energy conserving, continuous, high bitrate, and short delayed multimedia streaming. More similar to our work, Stiemerling et. al suggested to aggregated bandwidth in the cellular network and the local WiFi network to provide higher downlink bitrate for all nodes [17]. However, they use multi-hop peer-to-peer unicast communication, which introduces additional delay to the streaming session and limits the potential saving in terms of energy consumption. In contrast, we utilize single-hop unicast transmissions and the overhearing nature of wireless communication. Single hop unicast transmission can be managed using Wi-Fi Direct [18], a new standard that allows smartphones to create peer-to-peer connections without the need for a wireless access point. The connected devices can transfer data between each other while maintaining their connection to the Internet. In WiFi Direct, one of the phones play the role of a software access point, centrally managing the WiFi network. The feasibility to utilize overhearing in a cooperative wireless system has been exemplified in [7], [19], in which one of the phones serves as the access point and centrally manages the local WiFi network and schedules the video download among the cooperating nodes. However, we believe that such a design imposes unnecessary messaging and management overhead due to the centralized scheduling algorithm. Furthermore, the proposed system in [7], [19] poses non-negligible extra energy usage for the managing phone. In this paper we address these issues by proposing a light-weight distributed scheduling algorithm along with simple, yet effective, collaboration policies for the cooperating nodes. B. Network Coding for Cooperation in Mobile Networks Network coding offers a simple yet effective loss recovery mechanism, with minimum communication overhead. Network coding (NC) was originally proposed in the field of information theory for achieving optimal communication throughput [2]. As a derivation of erasure codes, the information to be disseminated is divided into k small blocks that are linearly combined to form m k coded blocks. The information is then transmitted in the network as coded blocks. All encoding are performed in GF(2 x ) to keep the block size the same. The bigger the field size, the more unique coded blocks can be generated. Unlike other erasure codes, information in their coded form can be inferred, decoded, and recoded by any node along the path from the source to the destination. The intended receiver may retrieve any k linearly independent coded blocks from the network to reconstruct the original information. Random linear NC (RLNC), proposed in [21], produces coded blocks by randomly generating the coding coefficients in GF(2 x ). If

3 a sufficiently large field size is used, with high probability any k coded blocks are linearly independent. The tradeoff here is that the encoding and decoding processes are CPU intensive. Due to the flexibility of RLNC [22], practical applications of NC in wireless systems have been widely researched in the past decade, including a practical coding scheme in unicast wireless mesh networks [23], error recovery in wireless P2P video broadcasting [1], and an efficient scheduling algorithm for NC in wireless local repair [24]. With the growing processing power of smartphones and tablets, several attempts have been made to implement NC on mobile devices. In [5], the performance of NC on mobile devices is evaluated in terms of throughput, delay and energy consumption. This work is extended in [25] to transfer pictures from one source device to neighboring devices over WiFi. In [26], RLNC is implemented on the iphone platform, and the throughput and battery consumption is measured for a video streaming task. Furthermore, the iphone implementation is extended to stream a video from one server device to a group of devices within the server s proximity [27], [28]. Similarly, in [29], a cooperative video streaming system for mobile devices (PDAs) is implemented and evaluated. More recently, Vingelmann et. al proposed to use NC among a group of cooperating smartphones to error correct the content downloaded from the cellular network [6]. Along the same direction, Keller et. al proposed MicroCast, a multimedia streaming system for smartphones that utilizes NC and the overhearing feature in WiFi network to encourage smartphones to exchange streaming content received from the cellular network [7]. This design effectively reduces the traffic in the cellular network and improves the system throughput. However, due to the overhearing feature and the small number of smartphones in the WiFi network, the use of NC in GF(256) is an overkill. It not only drains the battery on each smartphone, but also introduces delays in receiving the content. We share the same design principle as Microcast [7], i.e., avoiding the use of 3G links as much as possible by encouraing data swarming within the WiFi network. However, in contrast to Microcast, we propose a two-level NC coding scheme, in which the encoding process is offloaded to the Cloud and very minimum encoding is performed on the smartphones. Furthermore, I also simplify the scheduling algorithm within the WiFi network and make it distributed. As a results, we show that our proposed solution uses up to 73% less battery on each smartphone compared to the current streaming mechanism over the 3G network. III. AN ENERGY-EFFICIENT STREAMING SYSTEM In this section, we propose our energy-efficient streaming system for smartphones, hereafter referred to as nodes. In this system, the energy saving is achieved through utilizing a two-level systematic NC scheme and the computing power of the Cloud. Without making any assumption regarding the video codec used to generate the video stream, our system schedules the transmission at the segment level. Each video segment represents a small duration (say 1 second) of the video playback. In a live streaming session, all nodes share the same window of interest, i.e., the same set of segments. The remaining of this section explains the two levels of NC, the transmission scheme, and the scheduling algorithm in detail. Video Source NC Coder { Request segment s i k blocks + ϵc coded blocks in GF(256) : Node (Seed) Reconstruct s i, } code ϵ w blocks in GF(2) : k blocks + ϵ w coded blocks in GF(2) Other nodes Fig. 2. Streaming segment i from the Cloud to all collaborative nodes in the proposed transmission scheme A. General transmission scheme As the focus of this paper is not to provide an optimal transmission scheme, we assume a simple pull based streaming scheme, as shown in Fig. 2. Based on a scheduling algorithm, nodes explicitly request segments that are due for playback soon from the video source, which is located in the Cloud. As transmissions over 3G links consume more energy than transmissions over WiFi links, to conserve battery lifetime, nodes ideally should collectively download a single copy of the video and exchange segments with each other over WiFi links. The scheduling algorithm will be detailed in Sec. III-C. Upon receiving a request, video source passes the segment to a network coding engine in the Cloud, hereafter called NC coder. NC coder serves the segment using systematic code in Galois Field GF(256) to minimize the transmission overhead and also the need for encoding and decoding at both the sender side (the NC coder) and the receiver side (smartphones), respectively. We assume that the link between the video source and the NC coders is a high throughput and low delay link. More detail is provided in Sec. III-B1. On the receiver side, the node can reconstruct the video segment as soon as k linearly independent blocks are received over the 3G network. In a live streaming session, all nodes play roughly the same segment and are interested in receiving the same set of segments that are due for playback in the immediate future. Hence, nodes form a swarming session, in which they exchange received segments with each other over the WiFi network. To cope with losses in this network, each segment is served in both verbatim form and coded form. Similar to the NC coder, a node divides a segment into k blocks of the same size and serves the segment using systematic code. However, to minimize the encoding and decoding cost, the coding operations are performed in GF(2). Receivers of the segment only need to perform the decoding process if the first k blocks received are not all verbatim blocks. More detail is provided in Sec. III-B2. B. Two-Level Coding Scheme Overall, nodes collaboratively request different segments from the Cloud and exchange with each other in the WiFi

4 network. A video segment is delivered in two phases. In the first phase, blocks of the segment are transmitted in both verbatim form and coded form in GF(256) over the 3G network. In the second phase, the node which receives sufficient blocks of this segment decodes the segment and then serves blocks of this segment in both verbatim form and coded form in GF(2) over the WiFi network. 1) Top level: coding in the Cloud: We assume that the video stream is generated by the video source at rate v bps, and is simultaneously interested by a group of m cooperating smartphones N = {N 1,N 2,,N m }. Each node N i 2N has a cellular connection with download capacity C i bps and packet loss rate l i from the cellular towers. We assume that these connections have the required error correction mechanism in place, i.e., the 3G wireless channels are erasure channels. Furthermore, we assume that the cellular towers manage the wireless interference to provide nodes with interferencefree connections. Consequently, we can assume that there are N parallel connections from the cooperating nodes to the NC coders in the Cloud. To ensure a complete data swarming in the WiFi network, a complete copy of the video must be streamed from the Cloud through the 3G network, i.e., E X P i (1 + l i )F (1) i=1, where E is the set of 3G links carrying the video stream, P i is the total number of bytes transmitted on each link, F is the the video file size, and l i is the loss rate of each link. Upon receiving a request for segment s j from node N i 2 N, the NC coder divides segment s j into k j original block of the same size and serves n j = k j + c systematic coded blocks over the wireless downlink to the node. The value of c is determined by the loss rate l i. In general, the expected number of blocks sent over a 3G link for a segment s j is: E[n j ] = k j + c (2) = k j + E[l i] 1 E[l i ] k j, where E[l i ] is the expected loss rate from the NC coder to a node N i. For example, if the loss rate is.2, there should be 1.25 k blocks served by the source in order to ensure at least k blocks are received. The first k blocks are served in their original form, and the additional.25 k blocks will be served in coded form in order to recover any lost during the transmission of the 1.25 k blocks. To generate coded blocks, the NC coder produces each coded block as a linear combination of the k original blocks using random coefficients from a finite field GF(2 x ). Since each link i has a different loss rate apple l i apple 1 and the link quality varies over time, the NC coder may have to generate and send different number of coded blocks for each segment. To better utilize the bandwidth in 3G network, the coding is performed in a larger field of GF(256) to ensure that with high probably the redundant coded blocks received by a node are linearly independent. A node stops receiving and reconstructs the video segment as soon as k j = k j + c linearly independent blocks are received over the 3G network, where apple kj apple k j is the number of original blocks received and apple c apple c is the number of coded blocks received. Since RLNC is based on Reed-Solomon code, a maximum distance separable code, the need for explicit retransmission of a lost packet is eliminated as all transmitted blocks are equally important and useful in decoding the original segment. 2) Bottom level: coding in WiFi: Now, segment i is considered in the WiFi network. The node that receives this segment, hereafter referred to as the seed for the segment, is now responsible for disseminating the segments to other nodes in the WiFi network. In MicroCast [7], the seed sends coded blocks produced in GF(256) to all nodes in the WiFi network by utilizing the overhearing feature. If a node does not receive enough coded blocks for decoding a segment, it explicitly requests the seed to serve more coded blocks of the segment. We note that this system requires all nodes to perform the encoding and decoding operations in GF (256). However, since the system is taking advantage of the overhearing feature in the WiFi network, and the network is formed by nearby nodes, the loss rate is expected to be much lower than the cellular network. Our experiment on the Galaxy Nexus phone indicates that encoding and decoding in GF(256) for every GB of data consume 5.6% and 3.6% of the battery, respectively. Given the size of the WiFi network and the lower loss rate, we believe that NC in GF(2) is sufficient. For this reason, we argue that it is not necessary to perform NC in GF(256) in the WiFi network. In our system, a seed of a segment s j first reconstructs the original segment. The seed then sends the k j blocks from the segment over the WiFi network without encoding them. Nodes that successfully receive these k j blocks can reconstruct the segment without performing any decoding. Due to channel losses, some nodes may not receive the k j original blocks, and they may miss different blocks. Reconciling the missing blocks for each node will be costly and requires a direct communication between the node and the seed. Instead, the seed produces and sends w coded blocks in addition to the k j original blocks. The coded blocks at this level are produced by simply XORing a random subset of the k j blocks, i.e., encoding in GF(2). The value of w is determined by the loss rate l w in the WiFi network. Hence, the expected number of blocks sent in a WiFi network for a segment s j is: E[m j ] = k j + w (3) = k j + E[l w] 1 E[l w ] k j, where E[l w ] is the expected loss rate in the WiFi network. Here, we assume that an algorithm for estimating the loss rate is in place. After a timeout period, if a node still does not have sufficient blocks to reconstruct the original segment, it will ask the seed to send more coded blocks. Overall, with the two-level NC and transmission scheme, the encoding process is offloaded to the Cloud, and the decoding process will take place just for the lost blocks of each segment once in GF(256) at the seed and once in GF(2) at the other nodes. From our experiment on the Galaxy Nexus phone, both encoding and decoding in GF(2) for every GB of data consume approximately.6% of the battery, which is

5 much more power efficient than that in GF(256) on each node. In this system, to disseminate a segment s j to all smartphones, there are E[n j ] E[m j ] very close to the minimum transmission required to deliver a segment to all nodes, i.e., n j +m j, where n j is the number of blocks sent over a 3G link with the minimum loss rate, and m j is the number of blocks shared in a WiFi network with the minimum loss rate. C. Distributed Scheduling Algorithm In MicroCast [7], each node requests video segments from the Cloud according to the segment assignment that is centrally managed by a specific node. If any node failed to retrieve a particular segment, this node will be informed and reassign the download task to another node. However, given the overhearing feature in wireless communication, the segment download scheduling can be managed in a distributed fashion among the nodes in the WiFi network. Here, we propose such a distributed algorithm to coordinate the segment downloads. Each node randomly picks a missing segment s j in the shared window of interest, with preference toward segments that are due for playback immediately. Before pulling segment s j from the Cloud, the node either broadcasts a message or unicasts the message to a random node in the WiFi network. Upon receiving or overhearing the message, all nodes will avoid scheduling segment i for transmission. As soon as the node that initiated the transmission completely received the segment, it informs other nodes with another message. If such a message is not received or overheard within a timeout period, all nodes will treat segment i as a regular missing segment and proceed with regular segment transmission scheduling. This distributed algorithm not only coordinates all nodes to collectively download a copy of the video over time, but also allows load balancing among the nodes. The nodes with longer battery lifetime or better 3G connections can be more active in pulling segments from the Cloud, while nodes with low battery or poor 3G connections can benefit from the data swarming in the WiFi network. However, this is based on the assumption that all nodes are cooperative, and are not selfish or malicious in any form. The proposed distributed scheduling algorithm is presented in Alg. 1. In this algorithm, the Schedule() function decides whether a node should retrieve a segment from the Cloud. The decision may be based on different criteria, such as bandwidth utilization, fair share among nodes, or remaining battery lifetime. For this reason, we propose three variations of the Schedule() function. The performance of these variations and their impacts on the system is discussed in Sec. IV. 1) Aggressive Collaboration: In this variation, nodes aggressively collaborate with each other to download video segments, i.e., nodes download from the 3G link whenever possible. The bandwidth of the downlink at each node determines how many segments a node will download from the Cloud. On average, the download share of each node can be characterized as in Eqn. 4. r i,d r i,d + r i,w ' C i P j2s C j (4) Algorithm 1 Distributed Scheduling Algorithm on node N i Require: S: segment list from the window of interest Require: S M : list of missing segments, initially equals to S Require: S Q : list of segments requested by nodes in WiFi Require: SCHEDULE(): schedules a segment transmission from the Cloud 1: while streaming do 2: if SCHEDULE() == true then 3: Select a segment s j from S M 4: Announce download s j 5: Move s j from S M to S Q 6: Download s j from the Cloud 7: end if 8: if s j received then 9: Remove s j from S Q 1: if received from 3G then 11: Send s j to WiFi 12: end if 13: end if 14: if timeout s j then 15: Announce missing s j 16: Move s j from S Q to S M 17: end if 18: m: an announcement received or overheard 19: if m == downloaded s j then 2: Move s j from S M to S Q 21: else if m == missing s j then 22: Move s j from S Q to S M 23: end if 24: end while, where r i,d is the number of segments retrieved using a 3G downlink, r i,w is the number of segments received or overheard over the WiFi network, C i is the 3G downlink capacity of node N i, and S Nis the set of collaborating nodes that have C i >. 2) Equal Collaboration: In this variation, fairness is enforced among nodes, i.e., each node downloads the same amount of video content from the Cloud. The contribution of a node is determined by number of nodes with 3G connections to the Cloud. On average, the download share of each node can be characterized as in Eqn. 4. For each node N i 2N the Schedule() function returns true if the following condition holds: r i,d apple 1 (5) r i,d + r i,w N C, where N C is the number of collaborating nodes that have C i >. Assuming that nodes can overhear messages in the WiFi network, every node can have a close estimation on the number of nodes in the network. 3) Battery-Centric Collaboration: In this variation, the objective is to maximize the overall battery lifetime in the system. In other words, nodes with relatively low battery level

6 will avoid scheduling transmissions on their 3G links, while nodes with relatively longer remaining battery lifetime will stream from the Cloud on behalf of the WiFi network. For each node N i 2N the Schedule() function returns true if the following condition holds: B i e BC (6), where B i is the battery level of node i and B e C is the approximate average of the battery levels among nodes with C i >. This scheduling algorithm requires each node to announce its battery level, which can be piggybacked in any of the announcement messages. IV. PERFORMANCE EVALUATION In this section, we verify the efficiency of the two-level NC and transmission scheme proposed in Sec. III, especially in terms of energy consumption. The default collaboration policy is the aggressive collaboration as described in Sec. III-C1. We begin with profiling the energy usage on an actual Samsung Galaxy Nexus I925 phone. The data from the profile is used to drive our simulation to provide a more accurate energy report on the system. Furthermore, we examine the effectiveness of bandwidth utilization and the streaming quality. We implement the simulator according to the design presented in Fig. 1. In the WiFi network, there are 2 nodes within each other s WiFi signal range. We feed the simulator a high definition version of the first presidential debate of the US 212 election from YouTube. The file size is MB and the playback duration is 5572 seconds, i.e., Mbps streaming rate. The energy efficiency and bandwidth utilization of our proposed scheme are evaluated against two streaming systems. One is the recently proposed RLNC scheme [7], in which original segments are streaming directly from the Cloud, and coded blocks are generated in GF(256) by the nodes and are shared in the WiFi network. This system shares a similar design with ours. It uses WiFi channels to alleviate the streaming demand in the 3G network, and uses NC to improve the streaming throughput in the WiFi network. The other one is the system in which all nodes stream directly from the Cloud over the 3G network. This represents the current approach to video streaming. A. Energy Profiling The Samsung Galaxy Nexus I925 phone is equipped with a dual-core 1.2 GHz processor, 1 GB of memory, and a 175 mah Li-Ion battery. The operating system is Android 4.2 (Jelly Bean). We start each experiment with a fully-charged battery unless otherwise stated. To measure the energy consumed by 3G and WiFi, we turn on only 3G or WiFi, but not both, on the node, and direct the node to download a 1.55 GB Wikipedia 7zip archive file. For WiFi, we also measure the case where the file is uploaded from the phone to another wireless device. The actual power consumption is calculated as the difference between the battery consumed by this download with the battery usage on an idle node (with all devices off) for the same duration. We repeat each experiment three times and report the average here. Table I summarizes the throughput and per GB battery usage (the energy consumed to transfer 1 GB of data). Due to the shorter transmission range in the WiFi network, the throughput is at least three times higher than that in the 3G network. The energy usage by WiFi is at least four times more efficient compared to 3G. The throughput and energy saving justifies the benefits of encouraging data swarming in the WiFi network. TABLE I. THROUGHPUT (MBPS) AND BATTERY USAGE (PER GB) OF WIRELESS CONNECTIONS Throughput Battery Usage 3G, Download % WiFi, Download % WiFi, Upload % The same procedure is performed to measure the power consumed by NC operations in GF(256) and GF(2). The NC operations are implemented using the NCUtils [3] library. The block size is 1 KB and the number of blocks are 32 and 256 for GF(256) and GF(2), respectively. These numbers are chosen to maximize the encoding and decoding throughput as well as the linear independency among any k coded blocks. For GF(2), 16 more coded blocks is generated so that any 256 received blocks are decodable % of the time. The results are summarized in Table II. As expected, NC operations over GF(2) are much more faster and energy efficient due to their linear computational complexity compared to the quadratic complexity of NC operations over GF(256). We do note that although the decoding process has higher computational complexity, but it is not reflected in higher battery usage. This may be due to the different memory usage pattern as reported in [7] as well. TABLE II. THROUGHPUT (MBPS) AND BATTERY USAGE (PER GB) OF NC OPERATIONS Throughput Battery Usage GF(2), Encoding % GF(2), Decoding % GF(256), Encoding % GF(256), Decoding % B. Energy Efficiency Analysis Here, we focus on the average battery usage due to network transmissions and NC operations on a node in different streaming systems. According to Table I the energy consumed by network transmissions highly depends on the type of the network link (i.e., 3G or WiFi) and the loss rate on each link, in all experiments we set the default loss rate in both the 3G and WiFi networks to.1, i.e., l g =.1 and l w =.1, respectively. We assume that the packet loss rates among all links are independent of each other and are identically distributed according to a uniform distribution. We begin the analysis with a decomposition of the battery usage. Fig. 3 presents the percentage of battery consumed by the 3G transmissions, WiFi transmissions, and NC operations, under different streaming systems. As expected, when streaming over 3G, all battery usage is due to 3G transmissions. For RLNC-WiFi and two-level NC, there are two sets of data. The left one is for four-node WiFi network, and the right one is from a seven-node WiFi network. More savings are observed in the larger networks. In the RLNC-WiFi system, although the

7 12 3G Traffic WiFi Traffic Network Coding Battery Usage (%) Streaming over 3G RLNC in WiFi (n = 4 & n = 7) Two-Level NC (n = 4 & n = 7) Battery Usage (%) Streaming over 3G RLNC in WiFi Two-Level NC Number of Cooperating Nodes Fig. 3. Average energy consumption break-down for streaming the reference video in two collaborating networks of four and seven nodes using different streaming systems. l g = l w =.1. battery used by 3G transmission is greatly reduced, the energy consumed by NC operations in GF(256) dominates the battery usage on each node. This high amount of energy consumed by NC operations is consistent with the results reported in [7]. With our two-level NC, the bottom-level NC performs XOR-encoding only after sending k original blocks, and a node only needs to decode in GF(2) if it did not receive the k original blocks. Therefore, NC operations consume a very small amount of energy, with a slight tradeoff in WiFi transmission. Overall, two-level NC offers great saving on battery usage. Fig. 4 compares the average battery usage on a node in each of the three systems when varying number of nodes in the system from 1 to 2. When streaming over 3G, the energy consumed by each node remains constant, regardless of the number of nodes nearby. The RLNC-WiFi system consumes more energy when only two nodes are in the WiFi network. In this case, the energy consumed by coding operations in GF(256) is more than the saving brought by data swarming in the WiFi network. Energy saving becomes noticeable when 4 or more nodes are in the system, which is consistent with the observation reported in [7]. In our proposed two-level NC scheme, the data swarming in the WiFi network always leads to energy saving, regardless of the number of nodes in the system; and there are more savings as more nodes join the swarm. The battery usage in the two-level NC system is approximately half of the battery usage in the RLNC-WiFi system. As the network size grows, the two-level NC system conserves up to 73% of the energy compared to the 3G streaming, and up to 52% compared to the RLNC-WiFi system. One concern about coding in GF(2) is the transmission overhead since the coded blocks are more likely to be linearly dependent with each other. Any linearly dependent block will be discarded by the receiver, leading to bandwidth wastage. Since the battery usage we measured is primarily contributed by wireless transmissions, the bandwidth wastage will be reflected in the battery usage. In this experiment, we study the battery usage due to WiFi transmissions in a network consisting of four nodes. We vary the loss rate l w from.1 to.4. According to Fig. 5, the extra transmissions due to higher loss rate causes the battery usage grow at a faster rate. However, since two-level NC greatly reduces the energy Fig. 4. Average energy consumption of streaming the reference video when varying number of collaborating nodes. l g = l w =.1. cost by offloading the encoding process to the Cloud and minimizing coding operations on each node, which is the dominating factor in total energy consumption on a node in the RLNC-WiFi system, the energy saving is still significant, even when the loss rate is as high as.4. Battery Usage (%) Streaming over 3G RLNC in WiFi Two-Level NC WiFi Packet Loss Rate Fig. 5. Average energy consumption of streaming the reference video when varying l w. l g =.1, n =4. C. Time and Throughput Analysis The energy saving may be obvious as the two-level systematic NC and transmission scheme is designed to conserve energy. Since all streaming systems are sensitive to delays, we conduct a time analysis to study the distribution of time among network transmissions and NC operations. As shown in Fig. 6, data swarming over WiFi significantly reduces both the 3G transmission time and the total transmission time. Among the two sets of results, one from a four-node network and one from a seven-node network, noticeable savings in 3G transmissions are observed with increasing WiFi network size, and all other savings are marginal. In the RLNC-WiFi system, the main bottleneck is the computational time due to NC operations. Although progressive decoding [31] can conceal most of the decoding time within the transmission time, the delay introduced by the encoding process is unavoidable and can be the bottleneck of the overall performance. In our proposed two-level NC system, we expect the bottleneck to

8 be the capacity of the WiFi channel, especially when there are a large number of nodes in the system. Time (sec) G Traffic WiFi Traffic Network Coding 1935 Streaming over 3G RLNC in WiFi (n = 4 & n = 7) Two-Level NC (n = 4 & n = 7) Fig. 6. Video streaming time analysis in two collaborating networks of four and seven nodes using different streaming systems. l g = l w =.1. Given the time savings, we turn our attention to the maximum achievable throughput in each system. The higher the throughput, the better video quality can be supported in the system. To measure the maximum achievable throughput, we turn the streaming system into a file download system. Each node simply downloads the entire video as fast as possible. As shown in Fig. 7, there is no throughput gain when streaming directly from the 3G network when new nodes join the system. In the RLNC-WiFi system, there is a slight increase in the maximum achievable throughput. In sharp contrast, there is a significant increase in our two-level NC system. As more nodes join the system, the total transmission capacity from the Cloud to the nodes over 3G network increases. However, the capacity in the WiFi network is fixed. For this reason, the maximum throughput increase starts to converge when there are four nodes in the system, at which point, the transmission bottleneck switches from the 3G downlinks to the WiFi capacity. Maximum Throughput (Mbps) Max WiFi Download Throughput Max WiFi Upload Throughput Number of Cooperating Nodes Streaming over 3G RLNC in WiFi Two-Level NC Reference Video Bitrate Fig. 7. Maximum achievable throughput by different streaming systems. l g = l w =.1, and n =4. Maximum WiFi throughputs are borrowed from Table I. D. Impact of the Scheduling Algorithm At last, we modify the simulator to analyze the impact of the different segment scheduling policies introduced in Sec. III-C. In this experiment, we considered a WiFi network that consists of seven nodes. Out of these seven nodes, five nodes are connected to the Cloud over different 3G networks, and two nodes have no 3G connections. Among the five 3Genabled nodes, one node has the reference 3G bandwidth (3.8 Mbps), two nodes have 1.5 Mbps 3G downlinks, and two have 1 Mbps downlinks. Due to bandwidth fluctuation in 3G downlinks, the nodes must have their antennas on for a different amount of time to completely receive a segment. To measure the energy consumption rate, we repeat the same profiling scenario as described in Sec. IV-A using the reference Samsung Galaxy phone. Furthermore, to investigate the impact of the battery-centric collaboration policy, the phones are not fully charged. According to [32], to imitate the real world model of the phone charges, we used a normal distribution with µ = 67 and 2 = 1, and selected the battery levels randomly from seven samples generated using R statistical software [33]. Table III summarizes the specification of the heterogeneous nodes. TABLE III. SPECIFICATION OF THE HETEROGENEOUS NODES Node Node 3G Link Battery 3G Battery ID Type (Mbps) Level Usage (per GB) 1 I % 11.49% 2 II % 27.59% 3 II % 28.7% 4 III % 41.38% 5 III % 41.13% 6 IV 55.1% 7 IV 77.9% First, we compare aggressive scheduling and equal collaboration scheduling policies to evaluate the impact of segment scheduling algorithm on the battery usage. According to Eqn. 4, when using aggressive scheduling, the number of segments streamed to each node over 3G links is proportional to the bandwidth capacity on each link, i.e., nodes with faster downlink download more. Similarly, Eqn. 5 implies that in equal collaboration scheduling policy, all nodes with a 3G downlink are expected to download the same number of video segments regardless of their downlink capacity. As depicted in Table IV, although the equal collaboration scheduling tries to achieve an even distribution of energy consumption across all peers, it causes a 7% of increase in system-wide battery usage in both systems, because nodes with slower downlink use the cellular antenna for a longer time and consume more energy to download the segments. However, regardless of the scheduling algorithm in use, our proposed two-level systematic NC and transmission system conserves at least 35% of battery usage system wide, compared to utilizing RLNC over GF(256) in WiFi as suggested in [7]. Finally, we turn our attention to the effect of segment scheduling algorithms on the battery life of the heterogeneous nodes and the maximum duration of video streaming on each node. From Fig. 8, we observe that without considering the energy consumed for video playback on the screen, the aggressive use of 3G downlink drains the battery of the collaborating

9 nodes at the same pace. Phones starts to disappear from the system shortly after 1 hours into the session. While Phones 1, 2 and 4 continue the streaming for another 6 hours, when they leave the system, Phone 5 and the two phones that do not have 3G links cannot maintain a smooth playback as the aggregated bandwidth (1 Mbps) is less then the video bitrate ( Mbps) Phone 1 Phone 2 Phone 3 Phone 4 Phone 5 Battery Level (%) Phone 1 Phone 2 Phone 3 Phone 4 Phone 5 Battery Level (%) Streaming Duration (Hours) Fig. 9. Streaming duration of different phones using equal collaboration scheduling algorithm. l g = l w =.1, n = Streaming Duration (Hours) Fig. 8. Streaming duration of different phones using aggressive collaboration scheduling algorithm. l g = l w =.1, n =5. Unlike the aggressive collaboration scheduling, the equal collaboration scheduling enforces a fair share among nodes regardless of their battery level. Nodes with good 3G downlinks benefit in this variation as they can download video segments in a shorter time period. The less antenna usage leads to less battery consumption. As indicated in Fig. 9, when a node leaves the system, the battery consumption of the remaining nodes increase. This can be clearly observed after 14 hours of video streaming. After all nodes left, Phone 1 must use its 3G downlink for video streaming and broadcast all received segments over WiFi for the nodes with no 3G downlink. The battery-centric scheduling algorithm is expected to increase the streaming duration, as it balances the remaining battery lifetime among participating nodes. The other two schemes do not have any mechanism to conserve battery lifetime on dying nodes. Fig. 1 depicts how the heterogeneous phones with different battery levels collaborate in video streaming session when the battery-centric scheduling algorithm is employed. After 1 hours into the streaming session, all nodes have a similar battery level, as predicted in Eqn. 6, and they continue to collectively download one copy TABLE IV. IMPACT OF SEGMENT SCHEDULING ALGORITHM ON ENERGY CONSUMPTION IN HETEROGENEOUS COOPERATIVE GROUPS RLNC in WiFi Two-Level NC Node Agg. Equal Agg. Equal Type Sched. Sched. Sched. Sched. I 12.1% 8.4% 7.2% 4.6% II 1.7% 11.7% 7.% 7.9% III 1.4% 14.4% 7.% 1.6% IV 5.2% 5.2% 2.3% 2.3% Sum 64.8% 71.1% 39.9% 46.2% of the video segments for another 7 hours. Battery Level (%) Phone 1 Phone 2 Phone 3 Phone 4 Phone Streaming Duration (Hours) Fig. 1. Streaming duration of different phones using battery centric collaboration scheduling algorithm. l g = l w =.1, n =5. V. CONCLUSION In this paper, we proposed a two-level NC and transmission scheme to stream multimedia content to smartphones. At the top level, the Cloud produces coded blocks of video segments using systematic network coding in GF(256) and serves coded blocks to the smartphones. At the bottom level, received content is shared among smartphones within a WiFi network. The content is transmitted in both verbatim form and coded form using systematic network coding in GF(2). In summary, we cope with the variable loss rate and bandwidth fluctuation, common problems in wireless communication, by taking advantage of network coding. Furthermore, we minimize the network coding operations on smartphones by offloading the encoding process to the Cloud and using XOR-only network coding in the WiFi network only when necessary. Finally, we utilize a light-weight distributed scheduling algorithm to eliminate the centralize management for data swarming among the nodes. We verify the proposed system through a simulator

10 that is driven by the energy profile of a Samsung Galaxy phone. Our experimental results show that our proposed system saves up to 73% of battery usage on each phone compared to the current streaming mechanism over the 3G network, and up to 52% compared to MicroCast [7]. Due to the efficient use of CPU time, the maximum achievable throughput in our system is approaching the maximum capacity of the WiFi network, i.e., the system is capable to support higher quality streaming. Furthermore, the proposed system provides short delay and long-lasting video streaming by balancing the remaining battery lifetime among a group of cooperating nodes. REFERENCES [1] Cisco Systems, Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, , cisco.com/en/us/solutions/collateral/ns341/ns525/ns537/ns75/ns827/ white-paper-c html. [2] F. H. P. Fitzek, P. Kyritsi, and M. D. Katz, Power Consumption and Spectrum Usage Paradigms in Cooperative Wireless Networks, in Cooperation in Wireless Networks: Principles and Applications, F. H. P. Fitzek and M. D. Katz (Eds.), Springer, pp , 26. [3] G. Ananthanarayanan, V. N. Padmanabhan, L. Ravindranath, and C. A. Thekkath, Combine: Leveraging the Power of Wireless Peers Through Collaborative Downloading, in Proc. of 5 th International Conference on Mobile Systems, Applications, and Services (MobiSys), San Juan, Puerto Rico, June 11-14, 27, pp [4] S. Ioannidis, A. Chaintreau, and L. Massoulie, Optimal and Scalable Distribution of Content Updates Over a Mobile Social Network, in Proc. of 28 th IEEE Conference on Computer Communications (INFOCOM), Rio de Janeiro, Brazil, April 19-25, 29, pp [5] V. Pedersen and F. H. P. Fitzek, Implementation and Performance Evaluation of Network Coding for Cooperative Mobile Devices, in Proc. of IEEE International Conference on Communications (ICC), Beijing, China, May 19-23, 28, pp [6] M. V. Pedersen, F. H. P. Fitzek, and J. Heide, On-the-Fly Packet Error Recovery in a Cooperative Cluster of Mobile Devices, in Proc. of IEEE Global Telecommunications Conference (GLOBECOM), Houston, TX, December 5-9, 211, pp [7] L. Keller, A. Le, B. Cici, H. Seferoglu, C. Fragouli, and A. Markopoulou, MicroCast: Cooperative Video Streaming on Smartphones, in Proc. of 1 th International Conference on Mobile Systems, Applications, and Services (MobiSys), Low Wood Bay, United Kingdom, June 25-29, 212, pp [8] 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 5 th ACM Workshop on Challenged Networks, Chicago, IL, September 2-24, 21, pp [9] 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 International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), Paris, France, June 2-24, 211, pp [1] S. Li and S. H. G. Chan, BOPPER: Wireless Video Broadcasting With Peer-to-Peer Error Recovery, in Proc. of IEEE International Conference on Multimedia and Expo (ICME), Beijing, China, July 2-5, 27, pp [11] H. Soroush, P. Gilbert, N. Banerjee, M. D. Corner, B. N. Levine, and L. Cox, Spider: Improving Mobile Networking with Concurrent Wi- Fi Connections, ACM SIGCOMM Computer Communication Review, vol. 41, no. 4, pp , August 211. [12] P. Hui, J. Crowcroft, and E. Yoneki, Bubble Rap: Social-Based Forwarding in Delay-Tolerant Networks, IEEE Transactions on Mobile Computing, vol. 1, no. 11, pp , November 211. [13] 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. 15, pp , October 28. [14] J. Chesterfield, R. Chakravorty, I. Pratt, S. Banerjee, and P. Rodriguez, Exploiting Diversity to Enhance Multimedia Streaming Over Cellular Links, in Proc. of 24 th IEEE Conference on Computer Communications (INFOCOM), Miami, FL, March 13-17, 25, pp [15] P. Rodriguez, R. Chakravorty, J. Chesterfield, I. Pratt, and S. Banerjee, MAR: A Commuter Router Infrastructure for the Mobile Internet, in Proc. of 2 nd International Conference on Mobile Systems, Applications, and Services (MobiSys), Boston, MA, June 6-9, 24, pp [16] C. L. Tsao and R. Sivakumar, On Effectively Exploiting Multiple Wireless Interfaces in Mobile Hosts, in Proc. of 5 th International Conference on Emerging Networking Experiments and Technologies (CoNEXT), Rome, Italy, December 1-4, 29, pp [17] M. Stiemerling and S. Kiesel, A System for Peer-to-Peer Video Streaming in Resource Constrained Mobile Environments, in Proc. of 1 st ACM Workshop on User-Provided Networking (U-NET), Rome, Italy, December 1-4, 29, pp [18] WiFi Direct, [19] H. Seferoglu, L. Keller, B. Cici, A. Le, and A. Markopoulou, Cooperative Video Streaming on Smartphones, in Proc. of 49 th Annual Allerton Conference on Communication, Control, and Computing, Urbana Champaign, IL, September 28-3, 211, pp [2] R. Ahlswede, N. Cai, S. Y. R. Li, and R. W. Yeung, Network Information Flow, IEEE Transactions on Information Theory, vol. 46, no. 4, pp , July 2. [21] T. Ho, R. Koetter, M. Medard, D. R. Karger, and M. Effros, The Benefits of Coding over Routing in a Randomized Setting, in Proc. of International Symposium on Information Theory (ISIT 23), Yokohama, Japan, June 29 - July 4, 23, p [22] M. Gastpar and M. Vetterli, On the Capacity of Wireless Networks: The Relay Case, in Proc. of 21 st IEEE Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), New York, NY, June 23-27, 22, pp [23] S. Katti, H. Rahul, W. Hu, D. Katabi, M. Mdard, and J. Crowcroft, XORs in the Air: Practical Wireless Network Coding, vol. 36, no. 4, October 26, pp [24] J. B. Saleh, D. Qiu, and A. Elhakeem, Performance of an Efficient Scheduling Approach to Network Coding for Wireless Local Repair, Cyber Journals: Multidisciplinary Journals in Science and Technology, Journal of Selected Areas in Telecommunications (JSAT), pp , January 211. [25] M. V. Pedersen, J. Heide, F. H. Fitzek, and T. Larsen, Pictureviewer: A Mobile Application Using Network Coding, in Proc. of European Wireless Conference, Aalborg, Denmark, May 17-2, 29, pp [26] H. Shojania and B. Li, Random Network Coding on the iphone: Fact or Fiction? in Proc. of 18 th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV), Williamsburg, VA, June 3-5, 29, pp [27] P. Vingelmann, F. H. P. Fitzek, M. V. Pedersen, J. Heide, and H. Charaf, Synchronized Multimedia Streaming on the iphone Platform with Network Coding, IEEE Communications Magazine, vol. 49, no. 6, pp , June 211. [28] P. Vingelmann, M. V. Pedersen, F. H. P. Fitzek, and J. Heide, Multimedia Distribution using Network Coding on the iphone Platform, in Proc. of ACM Multimedia Workshop on Mobile Cloud Media Computing (MCMC), Firenze, Italy, October 25-29, 21, pp [29] M. Ramadan, L. E. Zein, and Z. Dawy, Implementation and Evaluation of Cooperative Video Streaming for Mobile Devices, in Proc. of 19 th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), Cannes, France, September 15-18, 28, pp [3] NCUtils, Network Coding Utilities, [31] M. Wang and B. Li, Lava: A Reality Check of Network Coding in Peer-to-Peer Live Streaming, in Proc. of 26 th IEEE Conference on Computer Communications (INFOCOM), Anchorage, AK, May 6-12, 27, pp [32] D. Ferreira, A. K. Dey, and V. Kostakos, Understanding Human- Smartphone Concerns: A Study of Battery Life, Lecture Notes in Computer Science, Pervasive Computing, vol. 6696, pp , 211. [33] The R Project for Statistical Computing,