EFFICIENT COMMUNICATION FOR MOBILE DEVICES IN THE NEW ERA

EFFICIENT COMMUNICATION FOR MOBILE DEVICES IN THE NEW ERA

a cloud-assisted approach to provide a set of advanced file operations, such as encryption, decryption and compression, on smartphones. Furthermore, by utilizing the on-board Near Field Communication(NFC) module, we develop an algorithm to securely share the files between mobile devices. For the services of real-time video streaming, we propose approaches that identify a user's status by analyzing the accelerometer data and then, dynamically adjust the buffer mechanism to save network bandwidth on smartphones.
The proposed communication models and enhanced applications have been intensively evaluated with both experiments and simulations. Compared to the prior work, this dissertation has identified a few important problems for the efficient communication on mobile devices and provided novel solutions to improve the performance.

Research Problems and Challenges
In this section, we identify the research problems and challenges for each of the three representative mobile service categories.

Location-based Services
Location-based services for mobile devices have attracted a large volume of users [1][2][3][4][5][6]. The current location-based services, however, are still built upon the client-server architecture which incurs some unavoidable issues. Let us consider an example where a department store in a mall tries to deliver a flyer file to a nearby shopper. In the current architecture, the following steps are required: (1) the store hosts the file on its server; (2) the user has to install the store's applications; (3) the user connects to the Internet in the mall and reports his location to the store's server; (4) the server delivers the flyer file to the user. This process involves a few representative drawbacks that an Ad-Hoc network can help address. First, a user cannot discover nearby data or information (step 2). He has to register for each and every service he is interested in. With an Ad-Hoc network, the user can browse or receive all the unknown services nearby as long as they transfer information on a common channel (such as WiFi). Second, step 3 and step 4 require the Internet connection which may not be always available, e.g., subway stations, crowded and congested areas, and the areas with infrastructure failures. Not to mention that when the store and user are close to each other, the data transfer going through the Internet may not be necessary and could incur additional costs to the user. Third, step 3 requires an accurate indoor localization scheme.
After investigating the problems of current client-server architecture, we argue that Ad-Hoc network model is a complementary alternative that can effectively help solve all the above issues. With an Ad-Hoc network, be able to hear the signals from the store is a best evidence that the user is close to the store. Therefore, constructing a mobile Ad-Hoc network (MANET) with hop-by-hop communication to carry local data traffic is desirable in practice.
However, the current routing protocols used in MANETs suffer from two major problems. First, it is costly and inefficient to establish a path from the source to destination. Traditional MANET routing protocols either pay a high cost for maintaining routing tables or flood a request message in the entire network for on-demand path discovery. Both categories require a large number of messages to be delivered for establishing a path. The second problem resides in the path recovery protocol which is usually triggered by an observed failure and proceeded by repeating the path establishment process. In practice, however, this recovery process is slow.

Cloud-storage Services
The cloud related services has been widely deployed in many applications, such as edge computing [7][8][9], deep learning [10][11][12], big data processing [13][14][15], resource management [16,17]. In this field, we consider the mobile application of cloud-storage service, which is a recent emerging technology for mobile devices. Representative products include iCloud [18], Dropbox [19], Box.com [20], Google Drive [21], and etc. [22,23]. Basically, each user holds a certain remote storage space in cloud and can access the files from different devices through the Internet. Synchronization and file consistence are guaranteed in these cloud-storage services. When smartphones become popular, it is ineluctable for users to couple cloud storage service with their smartphones. However, users and developers have encountered specific challenges due to the limitations of smartphones. First, the storage capacity of a smartphone is limited compared to regular desktops and laptops. Second, the network bandwidth of the cellular network is limited. At this point, major U.S. mobile networks carriers rarely provide unlimited data plans and the service scalability is limited by fundamental constraints. Finally, energy consumption is a critical issue for smartphone users.
With the above constraints in mind, most existing smartphone applications for cloud-storage service follow one important design principle of not keeping local copies of the files stored in cloud because smartphones may not have sufficient space to hold all the files, and downloading those files consumes a lot of bandwidth and battery power. Instead, only meta data is kept on smartphones by default. Though this design is efficient, it limits the capabilities of the applications. Some file operations that can be easily done with local copies become extremely hard, if not impossible, for smartphone users, e.g., compressing files and transferring files to another user.

Real-time Video Streaming Services
Streaming video is another popular service for smartphone users. Most of the popular stream video providers such as Youtube, Netflix, and Hulu have developed mobile applications to serve their clients. However, designing mobile applications for video streaming faces new challenges that do not exist in traditional wired Internet. One of the most critical issues is the network connection. Compared to the wired network users, a mobile user's network bandwidth is much limited. All the common connections for mobile users such as WiFi, 3G, and 4G have significantly lower throughput and the link qualities are heavily affected by environmental factors such as obstacles and distance to infrastructure nodes. In addition, user mobility is another unique feature for mobile users. When a user is mobile, the wireless link quality could be highly dynamic and a user can be temporarily disconnected in a certain region. Along with the movement, a user could also trigger the handoff protocol to switch the associated infrastructure node. All these dynamics in a wireless network serving mobile users make the design of streaming video mobile applications more challenging. Video streaming is a real-time service and extremely sensitive to the change of network conditions. Any network jitter or delay could pause the playback of the video clip. In addition, network cost is another issue that should be considered when developing a mobile app for streaming videos. On one hand, end-users may want to consume bandwidth as little as possible when watching the video because the video delivery may incur a cost, e.g., 3G or 4G, and additional energy consumption.
On the other hand, more importantly, the service providers may want to save the network bandwidth cost while serving the end-users.
A rule of thumb to achieve is to deliver only the necessary video data to the users.
With mobile users, it is more feasible to manage to achieve this goal because the mobile streaming video applications are usually developed by the service providers.
Compared to the means of accessing online video in the traditional network, e.g., via a general web browser, mobile streaming applications enable the service providers with more flexible functions to manage the data delivery from the source server to the end users. However, how to identify the changes of link quality and to predict the trend the changes of a mobile user remains a challenge.

Dissertation Contributions
To address the above research problems, this dissertation designs, develops and evaluates several novel communication models and enhanced applications. In the rest of this section, we briefly discuss the each of the three representative mobile service categories and summarize the contributions in each field.
Location-based services: In this field, our objective is to use MANETs to provide an alternative network architecture to the infrastructure-based client-server communication model. With this target in mind, we make the following contributions in this dissertation.
(1) We propose long-range radio assisted communication model(LAAR [24,25]) for regular data transmission where a long-range, low cost, and low rate radio is integrated into smartphones to assist regular radio interfaces such as WiFi and Bluetooth. LAAR uses the long-range radio to carry out small management data packets to improve the routing protocols. Specifically, we develop new schemes to improve the efficiency of the path establishment and path recovery process in the on-demand Ad-Hoc routing protocols.
(2) For local message dissemination, we build a system upon a new communication model, called passive broadcast (PASA [26]). It is a connectionless and receiver-initialized model where each node periodically scans other nodes in the communication range and obtains their data if available. The representative carriers of PASA in reality include Bluetooth and WiFi-Direct, both of which define a mandatary 'peer discovery' function to fetch basic information about nearby devices. This function can be easily extended to implement passive broadcast mechanism without modifying the existing network protocol stack.
(3) Based on PASA, we build a Mobile Message Board (MMB [27]), a location-based service for smartphone users to post and share messages in a certain area. Our algorithm design focuses on the message management on each phone considering its own schedule of turning the wireless device on and off. We present algorithms for two different cases to maximize the availability of the messages. Cloud-storage services: Our basic idea to enhance cloud-storage services is to launch a cloud instance to assist users to accomplish advanced file operations.
By using the resources of the instance, smartphone users will significantly reduce the bandwidth consumption for file operations. To implement this idea, we develop Skyfiles [28] system for smartphone users to manage their files in cloud storage with more capabilities. The main contributions of Skyfiles lie as follows.
(1) It extends the available file operations for mobile devices to a more enriched set of operations including downloading, compressing, encrypting, and converting operations.
(2) It includes a protocol for two smartphone users to transfer files from one's cloud storage space to the other's cloud storage.
(3) It includes secure solutions for all the above operations to use shared cloud instances, i.e., instances created by other users.
Real-time video streaming services: In this category, we target on improving video prefetch/buffer mechanism that is commonly used in video streaming services.
We develop an efficient and dynamic video buffer control scheme named (DAB [29]) that tries to keep a smooth playback with minimum data delivered to the user by adjusting the buffer size. DAB contains the following contributions.
(1) It takes the mobility of smartphone users into consideration and combines the signal strength as well as accelerometer measurements to dynamically adjust the buffer size.
(2) It is implemented on Android smartphones to play Youtube videos and evaluated with real users' mobility traces.

Dissertation Organization
The rest of this dissertation is organized as follows. In Chapter 2 and 3, we investigate two new efficient Ad-Hoc communication models for smartphones as well as a suite of new techniques to significantly improve the efficiency. Both models target on reducing the cost of route establishment and maintenance, while one model is for bulk data communication and the other model is for short message dissemination.
Specifically, we present LAAR for bulk data communication in Chapter 2 and discuss the details in protocol design, system implementation and performance evaluation.
Chapter 3 presents PASA for short message dissemination and discusses the system model, problem formulation, parameter optimization and performance evaluation. In Chapter 4, we propose MMB system for nearby smartphone users to share messages with each other based on PASA communication model. MMB provides an alternative to traditional infrastructure-based client-server architecture for location-based services. Skyfiles is proposed in Chapter 5 to improve the cloud-storage services by utilizing a cloud instance. Chapter 6 is our work of DAB that enhances the real-time video streaming services. Finally, we conclude the dissertation in Chapter 7. CHAPTER 3

LONG-RANGE RADIO ASSISTED AD-HOC NETWORKS
In this chapter, we study smartphone-based Ad-Hoc networks to support applications that require interactions and communications in the proximity. It is motivated by the fact that location plays an extremely important role in mobile applications.
With an Ad-Hoc network, hearing the signals from the other users or service providers is the best evidence that the user is close to the each other. Therefore, constructing a mobile Ad-Hoc network (MANET) with hop-by-hop communication to carry local data traffic is desirable in practice. However, the current routing protocols used in MANETs suffer from two major problems. First, it is costly and inefficient to establish a path from the source to destination. Traditional MANET routing protocols either pay a high cost for maintaining routing tables or flood a request message in the entire network for on-demand path discovery. Both categories require a large number of messages to be delivered for establishing a path. The second problem resides in the path recovery protocol which is usually triggered by an observed failure and proceeds by repeating the path establishment process. In practice, however, this recovery process is slow. routingtable To address the problems, we investigate a new long-range radio assisted Ad-Hoc communication model for smartphones as well as a suite of new techniques to significantly improve the performance of path establishment and recovery. We have prototyped this model on commercial Android phones by integrating additional longrange radio chips. Specifically, we adopt XE1205 [30] which features low cost (<$30), low power (10 ∼ 20mA current), and a communication range of 1.6 miles. However, as a tradeoff, its data rate is low (tens of bps) unsuitable for bulk data transmission.
We propose to use this additional radio channel for control and management messages while data communication is still carried by WiFi or Bluetooth.

Related Work
Generally, there are two types of routing protocols in MANETs. One type is proactive protocols such as DSDV [31], OSLR [32]. In these protocols, each node maintains one or more tables with routing information to every other node in the network. The other type is on-demand protocol (reactive), such as DSR [33], AODV [34]. In ondemand protocols, the routes are created as required. In this chapter, we mainly focus on the on-demand routing protocol design.
A lot of innovative approaches in this area have been studied to improve the network performance from different aspects. For example, in LQSR [35], the route is selected based on link quality metrics, such as expected transmission count (ETX), per-hop RTT, and per-hop packet pair. However, LQSR only works with static setting and fails to deal with topology changes. Frey et al. [36] focus on geographic routing to overcome topology changes with mobility. Another important aspect is to utilize multiple resources on one node to achieve better performance. For example, [37] attempts to use multi-channel on one node and proposes a hybrid channel assignment strategy. Multiple resources on one device make the routing protocols more flexible.
MR-LQSR [38], AODV-MR [39] and Extended-DSR [40] assumes that each node is equipped with multiple radio interfaces. MR-LQSR uses a new metric named weighted cumulative expected transmission time(WCETT) to provide better route selection. The AODV-MR uses the multi-radio interfaces communication to improve spectrum utilization and reduce interference. Extended-DSR attempts to address limited capacity and poor scalability problem by taking advantage of multi-radio feature.
Our work is closely related to [26,[38][39][40][41][42]. However, in their settings, each node is equipped with multiple 802.11 wireless cards. And they focus on addressing issues of interference and channel allocation. In our case, the two interfaces work on different frequencies. We mainly focus on utilizing the collaborations of these radios to boost the network performance. In our previous work [24], we investigate the route construction and as a following work, we design the whole protocol.

Background and Problem
We target on the routing problem in a MANET where a source node aims to transfer data to a destination node. Each node in our setting is a smartphone and the phone-to-phone Path Cache: Path cache is often included in the MANET routing protocols to avoid unnecessary path establishments. Each node stores the paths from itself to other nodes into a route cache based on the RREQs or RREPs it overhears. In the path establishment, when an RREQ arrives, the node will first check its route cache.
If there exists a path to the destination in the route cache, the node will reply to the source without propagating the RREQ. In this scheme, the validity of the cached paths is crucial to the performance. Because of the node mobility, the cached paths may not be available when the node intends to use them. In the traditional routing protocols, the validity of the cached paths is never checked. When a node attempts to use a cached path and later finds the path is stale, the source will have to re-establish another path.
Path Recovery: Path recovery is another important component in MANET routing protocols. When a node on the path moves out of the transmission range of its neighboring hops, a link is broken and the path recovery protocol will be triggered to establish another path. In typical MANET routing protocols, the node that fails to receive a link layer acknowledge detects the broken link and sends a route error message (RERR) back to the source. The source will first search its route cache for an alternative route to the destination. If no alternative is found, the source initializes a new path establishment process. In addition, any node that receives or overheads an RERR message will delete all the routes in the cache that contain the broken link.
Path recovery inherits the issues we have mentioned for path establishment and path cache.
Our Problem Setting: In this chapter, we aim to develop an efficient MANET routing protocol based on the integration of a long-range radio interface that helps address the above issues. Specifically, we consider a MANET consisting of smartphone nodes and each smartphone is equipped with two heterogeneous wireless interfaces: one is the regular wireless radios such as WiFi and Bluetooth, and the other is a new long-range radio. According to our prototype, the long-range radio has a much longer communication range (up to miles) than WiFi or Bluetooth. Its power consumption is extremely low which is suitable for smartphones. However, the network bandwidth of the long-range radio is significantly lower than the regular radios. More details of the hardware characteristics will be introduced in Section 3.4. In our solution, the long-range radio will be used to broadcast small management packets while the data transfer is still carried by the regular radios in a hop-by-hop fashion. In addition, considering the coverage of the long-range radio, this chapter targets at the local data transfer where the source and destination can directly reach each other over the long-range radio. Our goal in this chapter is to use the new long-range radio assisted communication model to improve the performance of MANET routing protocols.
Specifically, with the new long-range radio interface, we aim to reduce the message flooded in the entire network, decrease the time overhead of establishing or recovering a path.

System Design of LAAR
In this section, we present our solution LAAR which mainly consists of an efficient path establishment protocol and path recovery protocol. In addition, we develop a new route cache management scheme that serves both path establishment and recovery protocols.

Path Establishment
In this subsection, we discuss the motivations and technical details of path establishment in LAAR system.

Motivations
Our design of the path establishment process includes the following two major new techniques.
Bi-directional Route Request Flooding: Traditionally, the route request message (RREQ) is flooded from the source towards the destination. In our problem setting, the source and destination are directly connected over the long-range radio.
Thus, before flooding the RREQ message, the source can use the long-range radio to notify the destination about the upcoming communication session. An then, the destination will participate in this process as well. In out solution, therefore, both the source and destination flood the RREQ message towards each other. When a node receives both request messages implying a path has been established, it can send an announcement message through its long-range radio. The routing table contains at least three columns: the source node ID (SRC), the destination node ID (DST), and an ordered list of node IDs that represent the path to the destination (PATH TO DST). After a path is successfully created, each node in the path will add a new entry in its routing table for this session.

RSSI-guided
In our solution, each node keeps an additional table, called preparation table, to help decide whether the node will participate in a path establishment process.
The structure of a preparation table is illustrated in Fig. 3  When overhearing the three-way handshake messages, every node that is neither source or destination applies the following Algorithm 1. Basically, the preparation table hold the candidate sessions that may be added into the routing table later. When   a node receives an INIT message (lines 3-4), it adds a new entry into the preparation   table recording the new session as well as the RSSI of this message (RS). INIT-ACK   and INIT-FIN messages confirm the awareness of the incoming path establishment  process at the source and destination, and also help enforce the RSSI-guided flooding. When receiving an INIT-ACK message (lines 5-11), the node first searches its   preparation table for the matching session with <src, dst>. If a matching entry E is found, the node will compare the recorded RS value with the RSSI value (R S→D ) in the INIT-ACK message. This entry E will be removed from the preparation table if E.RS< β · R S→D where β ∈ (0, 1) is a threshold depending on the signal prorogation model. This step filters out the nodes that are further away from the source node than the destination. If E.RS≥ β · R S→D , the node will update the entry E by setting E.RD value to be the RSSI of this INIT-ACK message. Similar steps are applied when processing an INIT-FIN message (lines [12][13][14][15][16][17][18] Search the session <msg.src, msg.dst> in the preparation table 14: if there exists an entry E for the session then 15: if E.RSD value is null or E.RD< β· msg.R D→S then 16: Remove this entry E from the preparation

Path Recovery
Path recovery is a critical component in MANETs because of the dynamic network topology caused by user mobility. We develop an efficient path recovery protocol in LAAR with the following two new techniques. Due to the page limit, we omit the detailed pseudo codes for the protocols.
Partial Path Recovery: In the prior work, once a node detects a broken link, the notification will be sent back to the source by an RERR message, and then the source will launch a new path establishment process. Therefore, any single link failure will lead to a complete path establishment process which is not efficient in practice, especially if the broken link is shared by multiple active sessions. An example is shown in Fig. 3.7. In the traditional MANET routing protocols, while node V moves away causing a broken link, node U will send three RERRs to the sources which will further start three path establishment processes.
In our partial path recovery solution, the node who detects the failure will notify the sources with a single RERR over the long-range radio and start path establishment processes with the destinations. Referring to the example in Fig. 3.7, node U will attempt recover the paths from U to D1 and D2. If successful, node U will notify the sources about the recovered paths over the long-range radio. Meanwhile, each source node also sets a timer once receiving an RERR. If the detecting node cannot recover the path to the destinations before the timers expire, the sources will initialize the path establishment process with the destinations.  Proactive Path Recovery: The other new technique we develop is to proactively start path recovery protocol before any link is broken. The basic idea is to detect weak or about-to-break links based on each phone's mobility. Considering smartphones being the mobile nodes in our setting, we particularly use the accelerometer and RSSI measurements to determine if a node is moving away from a path it belongs to. If a node detects high movements or poor RSSIs from its neighbors, it will notify the neighboring nodes about the possible departure. Then a path recovery process will start when the node still carries out the data transfer. Once a new path is established, the neighboring nodes will update their routing tables to bypass the departing node.
In practice, both accelerometer and RSSI readings are dynamic, and may not accurately reflect the user movements. We develop a heuristic algorithm that combines these two measurements to indicate if a node will cause a broken link soon. Algo- Measure the user's moving speed SL 9: if C ≥ τ then 11: C = 0; Start the recovery process; rithm 3 illustrates the detailed process when a packet arrives. Specifically, we define three discrete levels for RSSI values, {GOOD, FAIR, POOR}. While a GOOD RSSI indicates a stable link, a POOR RSSI will trigger a path recovery process. When a FAIR RSSI is received, our solution will start to periodically measure the accelerometer. Our intuition is that a highly mobile user with FAIR RSSIs is likely to cause a broken link. Similar to RSSI measurements, we use three levels, {HIGH, MEDIUM, LOW}, represent a user's moving speed. Our algorithm use a variable C to track the user speed accumulation. According to the speed level, we increase C with heuristic values (line 9, ∆ H > ∆ M > ∆ L ). When C exceeds a threshold τ , the path recovery process will be started.

Route Cache Management
In MANET routing protocols, every node records the known paths in a route cache to avoid the delay of path establishment. For both path establishment and path recovery protocols, route cache plays an important role. When processing an RREQ message, a node will first check its route cache and if a matching path to the destination is found, the node will reply to the source without further flooding the RREQ. However, the paths in the route cache are not verified until the node decides to adopt them. In a MANET, the link conditions are dynamic and the known paths may not be stable. Using stale paths will cause path recovery once a broken link is detected and yield a worse performance than not using the route cache.
In our solution, we address this issue by removing invalid paths in the cache based on the overheard packets. Two types of packets will trigger a cleansing of the route cache. First, if a node receives a broadcast RERR packet over the long-range radio indicating a broken or about-to-break link, it will search its route cache and eliminate all the paths that contain the link specified in the RERR. Second, every node will listen to the active data transmissions over WiFi or Bluetooth from the neighboring nodes even if the packets are not designated to it. By sniffing these packets (e.g., from node j to node k), node i can measure the RSSI and estimate the quality of the link j → i. If the RSSI is in the category POOR, node i will remove all the paths in its cache that contain the link j → i.

Complete Protocol in Path Recovery:
Here is the complete protocol. When the recovery process is initialized by node i, it first checks its path cache to see if there is another route to the destination. If an alternative route is found, node i sends a recovery message that contains the new route back to the source. When the source receives the recovery message, it will use this route for further transmission.
If there is no available route to the destination in the cache, node i will send a route error message to the source, and it will start the path establishment process with the three-way hand-shake protocol with the destination. When a path is successfully established from node i to the destination, node i will re-assemble a complete path from the source to the destination. This new path will be included in a re-assemble reply message which will be sent to the source by node i over the long-range radio.
Upon receiving the route error message from detected node, the source first suspends the transmission. Then, it sets a timer and waits for a re-assemble reply message. If a re-assemble reply message arrives, the source will use the new path for the rest of transmissions. If the timer expires with no re-assemble reply message, the source will start a path establishment process to find a path to the destination.

System Implementation
In this section, we introduce our implementation of LAAR with off-the-shelf devices. In our prototype, we attach a TinyNode [43], which includes a long-range radio transceiver, Xemics XE1205 [30], to an Android smartphone. XE1205 operates on 915Mhz and feature low cost, low power consumption, and a communication range of 1.6 miles. We have integrated the long-range radio into assorted phones including HTC Magic phone, Nexus One phone, and Nexus 4 phone. We use PL2303 [44] USB-to-Serial bridge controller to connect TinyNode and smartphone (through either ExtUSB or MicroUSB port).

Serial Port
TinyNode Smartphone Software support includes programs on both smartphones and the external devices. Fig. 3

Performance Evaluation
In this section, we evaluate LAAR and compare it with the conventional MANET routing protocols. The results are drawn from the experiments on basis of a small scale network and NS2 [46] simulation on basis of a large scale network. Our ma-jor performance metrics are overhead, number of messages transferred, and network throughput.
We compare LAAR with DSR [33], DSR-R0, and AODV-ERS [47]. DSR-R0 is the default implementation of DSR in NS2 and improves DSR with a ring-zero search scheme in the path establishment. Ring-zero search aims to reduce the overhead by firstly sending an RREQ with TTL=0. If the sender and the receiver are direct neighbors, the path would be quickly established. Otherwise, upon a timer expires, the sender will send another RREQ with a regular TTL value. AODV-ERS is an enhanced version of AODV [34] with expanding ring search, where the sender broadcasts the RREQ for multiple rounds each with an incremental TTL value. The process terminates when the destination is reached.
Workloads: We consider brochure dissemination application for our evaluation.
We collect a set of real brochure files for our tests considering the following cases where a MANET could help disseminate the files. Our evaluation uses the sample workload in the following

Experimental Results
First, we build a small scale Ad-Hoc network consisting of 6 Android smartphones equipped with the long-range radio. The phone-to-phone Ad-Hoc mode is supported with WiFi and WiFi-Direct. In our experiments, the smartphones are placed at the fixed positions, i.e., the mobility is not considered. We mainly evaluate the data throughput and the performance of the path establishment protocol. The hop distance between the source and destination ranges from 1 to 5.  In practice, considering the dense user population and possible user content sharing, we expect a short path length for any communication session. In addition to the overall performance, we also evaluate the breakdown overhead and try to answer the following questions.  Can we use the long-range radio for data delivery? The protocol design could be much simplified if the long-range radio can carry out the data transmission. We have conducted the same experiments with direct transmission between two TinyNode devices. The results are shown in Fig. 3.11a. Compared to Fig. 3.10 , the time consumption with the long-range direct link is much higher. Fig. 3.11b further compares the throughput of direct long-range radio link with hop-by-hop transmission along a 5-hop path. In this experiment, we use "iperf" tool to record the throughput every 20 seconds. We observe that hop-by-hop delivery yields a much higher throughput (with a high variance) even over a long path. Overall, we conclude the long-range radio works well for small management packets, but is not suitable for bulk data transmission.

Simulation Results
In addition to experiments, we conduct simulation with NS2 to evaluate LAAR in a large scale network.

Simulation Settings
In the simulation, we consider the brochure dissemination application in a mall.
We run the simulation in following two settings.
• Single store: In this setting, there is only one store trying to send out brochures to the nearby shoppers. We assume that the store periodically broadcasts a short message including a link to the brochure file over the long-range radio.
The users can use the link to fetch the brochure. We assume that N users receive the short message and α ∈ [0, 1] portion of them will be interested in it, i.e., α × N users will download the brochure.
• Multiple stores: In this setting, there are multiple senders in the mall. Similar to the previous setting, the senders first use periodical short messages over the long-range radio to notify the users.
The parameters in NS2 are set as follows. First, we adopt two-ray ground reflection model and constant speed propagation delay model for wireless signal prorogation.
In addition, each node in our LAAR protocol is set with two radios. We modify the NS2 to support two wireless interfaces. The frequency of the long-range radio is set to be 915MHz, and the communication range is configured to be 2500m in receiving (RX) and 3000m in carrier sensing (CS). The other regular radio (short range) is configured to work at 2.4GHz, and the RX and CS ranges are set to be 50m and 100m respectively. For the results shown in this chapter, β is set to 0.9 for the RSSI-guided flooding.
The users in the simulations follow a manhattan grid mobility model [48]

Single Store
In this setting, we choose Nordstrom (case 7) as our sender and conduct the simulations with different values of the parameters N and α. For each particular setting, we randomly generate 100 mobility traces for tests, and present the average values in the following figures.
Path establishment: First, we set N to 200 and 300, and change the value of α to control the total concurrent sessions in the network. The overhead performance of initial path establishment is shown in Fig. 3.12.
In our setting, the average number of neighbors is 23.9 and 34.3 for N = 200 and N = 300 respectively. The dense topology can lead to a serious congestion in the existing routing protocols, for example, as shown in Fig. 3.12b, to construct 9 (3% × 300) concurrent sessions, DSR, DSR-R0 and AODV-ERS uses 514ms, 598ms and 459ms, respectively. However, in LAAR, the overhead of path establishment remains low, because our design reduces the number of messages transferred mitigating the effect of congestion.    Overall throughput: We use throughput as an overall performance metric taking full mobility trace and link breaks into consideration. Since DSR and DSR-R0 use the same path recovery protocol, we do not include DSR-R0 in this test. Instead, to better study the impact of stale routes in the cache, we evaluate a DSR protocol that does not use route cache.
The results are compared in Fig

Multiple Stores
Finally, we test with three stores, Target (case 3), AT&T (case 5) and Nordstrom (case 7) as our senders. Each store tries to disseminate its brochure listed on Table 3.1.
In our configuration, the α for each store's brochure is the same. Thus, the total number of transmissions in the network is 3 × α × N . We collect the throughput from each transmission session and show the average result for each different α value.     We argue that Ad-Hoc network model is a complementary alternative that can effectively help solve all the above issues. In practice, however, creating and maintaining a direct link between two nearby devices which is the building block of an ad-hoc network is costly. For example, both Bluetooth and WiFi-Direct require a slow initial phase of discovering nearby peers and handshaking to establish a connection. It is especially inefficient for transferring a small amount of data. In addition, connected link may bring with it a security risk because one device might be able to access all exposed services on the connected device (e.g., in Bluetooth). In this chapter, we

Related Work
This work is related to prior research on mobile social networks, overlay P2P dissemination, and delay tolerant networks. Information dissemination has become more and more important in mobile social networks, such as [49][50][51], which aim at data dissemination in resource-constrained opportunistic networks, broadcasting from superusers and ferrying messages in intermittently connected mobile networks.
Point&Connect [52] implements pointing gestures of moving one device towards another in order to enable spontaneous device pairing. Musubi [53] provides a decentralized trusted social services on personal mobile devices. And BubbleRap [54] utilizes group membership information to improve standard unicast routing. In [55], the authors propose a gossiping-based approach, where each node forwards a message with some probability, to reduce the overhead of the routing protocols. 7DS [56] is developed to address network disruption problem in mobile networks by providing storecarry-forward communication. However, it only concerns data as store-carry-forward manner for disruption-tolerant applications which is very limited. [57] proposes to use data diffusion to reduce the query delay in DTNs. They use theoretical models to analyze the data diffusion process and compare the performance of the their proposed diffusion schemes in terms of diffusion speed and query delay. In addition, there is other prior work that helps better understand characteristic of DTNs such as [58][59][60][61]. For example, [58] is the rst to study multicast in DTNs from the social network perspective. They study multicast in DTNs with single and multiple data items, investigate the essential difference between multicast and unicast in DTNs, and formulate relay selections for multicast [59] studies human contact-based traces and designs SNAMD scheme that makes use of such information to efficiently deliver multicast messages. The authors in [60] compared the asymptotic performance of Interest-Based forwarding and from both the theoretical and experimental point of view. And SimBet [61] first introduces social network analysis in the context of delay tolerant networks. It uses ego-centric centrality and its social similarity. However, the focus of our problem is based on a different communication model and our objective is different. Passive broadcast is a receiver-initialized connectionless communication based on many-to-one delivery in each scan. Moreover, we target on a distributed and collaborative solution that efficiently disseminate messages in proximity.
One project closely related to our passive broadcast model is called Dythr [62] which lets a phone broadcast a WiFi hotspot with the SSID being the message.
This method actually is from the opposite direction of 'active' delivery as every node frequently injects messages into the wireless channel. In [63], Huang et al. proposed PhoneNet. This method uses a central server to establish links between devices connected to a WiFi network and then allows devices connected on local networks to connect directly. In [64], the authors use Bluetooth service discovery protocol to find common interests between two users. Similar to our proposed work, no connection is established and each user stores the keyword about his interest in Bluetooth service ID. However, this work is for two-user communication while our problem is set in a multiple user environment and our goal is to determine each device's schedules to achieve the efficiency.

System Model
Our target problem in this chapter is to enable nearby smartphone users to share information. In this section, we introduce basic components and sketch of our solution.

Communication Model
Our solution is based on the new passive broadcast communication model, where each sender buffers its broadcast data locally and the receiver initializes the transmission and fetches all available data from nearby nodes. In this model, when having a message to deliver, a node puts it in a buffer, but does not know when the message will be sent. On the other hand, each node periodically scans other nodes in the communication range and obtain the data in their buffers if available, i.e., each scan is a many-to-one communication.
We have implemented this model based on the mandatary 'peer discovery' function in both Bluetooth and WiFi-Direct. In the rest of this chapter, we take Bluetooth as a platform instance to introduce our solution. Basically, we use the field of 'device name' to carry target payload data. When a user intents to send a message, he assigns the message to his phone's Bluetooth device name. When other phones conduct peer discovery, the message will be sent over. The length of device names is usually limited, e.g., a Bluetooth's device name in Android can be up to 248 bytes. A large message can be fragmented to fit in and a phone can periodically change the device name to rotate multiple messages or fragments.

Smartphone Operations and States
Assume there are n smartphone nodes ({p 1 , p 2 , . . . , p n }) and this chapter considers a network model where all the phones are within each other's Bluetooth communication range. There are two basic operations for each smartphone p i , scan and update message. The first operation is the regular peer discovery process while the second one is to change its own device name to a new message. Update message operation can be finished instantly. But scan process has a long overhead. For Bluetooth, according to the standard and our experiments, a scan operation usually takes 10 ∼ 12 seconds to finish. Therefore, we further define two states for each phone: when a phone is conducting scan (peer discovery), it is in scanning phase; otherwise, it is in idle phase. For each message, we define its active period as the duration when the message is available for scanning, i.e., after the message is put on the device name and before it is replaced by the next message. If a phone finishes a complete scan during a message's active period, the message will be surely scanned by the phone.
If the active period starts or ends during a scanning process, the phone has a certain probability to receive the message. We will present detailed analysis later in Section 4.4.
We assume that the scan schedule has been pre-configured by each phone based on its own performance concerns, e.g., power consumption and urgency of getting new messages. We use T i to represent p i 's scan interval which is defined as the interval between the end of the prior scan and the beginning of the next scan, i.e., the length of p i 's idle phase. Additionally, we use U i to indicate the message update interval of p i , i.e., p i changes its device name once every U i time units. Different from T i , U i 's value can be dynamically changed as it does not incur any extra computation overhead or power consumption. Furthermore, we define S as the length of scanning phase, which is a constant for all phones.
In our solution, each phone and each active message has a unique identifier defined as follows: • Phone ID: In this chapter, we use the MAC address as each phone's identity.
When scanning nearby devices, a phone automatically obtains their MAC addresses and is able to recognize these phones later.
• Message ID: Each message can be identified by its owner's MAC address and a local index number. For example, aa:bb:cc:dd:ee:ff.12 represents a message from the phone with a MAC address of aa:bb:cc:dd:ee:ff and its index number on that phone is 12. In our solution, each index number is incremental with new messages and set up to 255 after which it will be reset to 0.

Message Format
In our solution, the device name is divided into two segments, header and payload.
Similar to other network protocol, 'header' field contains control and management data and 'payload' stores the messages being broadcast. The header includes the following fields: • Scan interval T : Each phone p i uses one byte to represent its own scan interval T i in the unit of second.
• Index range of active messages: Each phone uses two bytes to specify the index number range of its active messages. We assume each user apply the policy that only the most recent messages are considered for dissemination, e.g., the most recent 10 messages, and the messages generated in the past 5 hours. •

Message Dissemination with Passive Broadcast
In this section, we present our solution PASA that disseminates local messages based on passive broadcast model. We further provide numerical analysis to derive the optimal parameters for our solution.

Problem Formulation
Recall that we consider all the phones {p 1 , p 2 , . . . , p n } are within each other's communication range. Each phone p i holds k i messages to propagate to other phones.
Assume each smartphone is aware of other phones' scan intervals after an initial scan.
Without loss of generality, we sort all smartphones in the ascending order of their scan intervals, i.e., ∀i, j ∈ [1, n], if i < j, then T i < T j . Let t i represent the time phone p i spends in receiving all the messages. Our objective in this chapter is to The essential goal of our algorithm is to determine the update interval for each phone so that all phones can collaborate to disseminate all messages quickly. Out solution is based on an important property defined in the following Theorem 1.
Theorem 1. If a phone set its update interval to be T n + 2 · S, its message can surely be scanned by all other phones.
Proof. For any phone p i (T i ≤ T n ), apparently there must be a complete scan during a period of T n +2·S. Thus, the message will certainly be scanned by every phone.

Design of PASA
We present a solution with two stages. In the first stage, every phone simply sets U i to be a constant α and rotates its own k i messages. In the second stage, each phone set U i = T n + 2 · S and iteratively update the device name by one of the messages generated by its own or received from the first stage.  First, each phone can identify all the complete phones and incomplete phones, i.e., p i is a complete phone if j M R ij = |M |. Let IP and CP respectively represent the set of incomplete phones and complete phones each phone constructs. Second, each phone knows which messages it has received are needed by other phones. We let each phone p i build a set of candidate messages, indicated by C i , including all the messages that are useful for some other phones and could be put on the device name in the next stage. By definition, each message m j ∈ C i must satisfy M R ij = 1 and h M R hj < n.
In addition, we assume each phone has a different priority value based on the phone ID. Our algorithm will use this priority value to avoid unnecessary duplicate message selections from multiple phones. If a message is chosen by multiple phones, only the one with the highest priority will put it on the device name and the others have to yield and select other messages. Specifically, we assume a pre-defined the function f could convert a phone ID to a numerical value for comparison, i.e., p i has a higher priority than Message update for incomplete phones: In our solution, an incomplete phone applies the following Algorithm 4 in the second stage. Construct its candidate set C i

5:
Sort C i in the ascending order of the number of phones having received the messages, i.e., for each message m j , the value of h M R hj . 6: for i = 1 to |IP | do 7: for each incomplete phone p h ∈ IP do 9: In Algorithm 4, each incomplete phone first identifies all incomplete phones (the set IP ) and sorts them based on their priority values. Additionally, each phone forms the candidate sets of all incomplete phones using the information from M R (Lines 3-6). The candidate messages are also sorted by the number of phones that have received them (Line 5). In our algorithm, therefore, the first message in each candidate set is the most wanted messages. The main message selection process is in Lines 7-12. We use msg i to record the choice of p i . The loop starts from the phone with the highest priority to the one with the lowest priority. Within the loop, each phone picks the first message in the candidate set for updating message in the second stage. Upon a message msg j is selected, all candidate message sets are updated by removing msg j to avoid redundant message selections. Eventually, for a phone p i , msg i will be the message to be put on the device name. The time complexity of Algorithm 4 is bounded by O(n 2 ).
Message update for complete phones: The algorithm for a complete phone to update message is similar to Algorithm 4. Due to the page limit, we omit the pseudo-codes here. Each phone needs to construct the set of all complete phones CP and derive the candidate message set for each of them. An extra step for a complete phone is that it has to execute Algorithm 4 before making its own choice.
All the messages that have been selected by incomplete phones will be eliminated from complete phones' candidate sets. The remaining messages in the candidate set are also sorted according to the number of phones that need them. The same as in Algorithm 4, each phone selects the header message in the sorted list of candidate messages.

Parameter Optimization
In this subsection, we analyze the performance of the solution presented above and derive the optimal value of α. Essentially, we aim to express the objective as a function on α.
Our analysis is based on a general function P(x, y) defined to represent the probability that a phone with scan interval of x can receive a message from another phone with update interval of y. In another word, P(T i , U j ) is the reception probability for p i to receive a message from p j . We will present how to calculate P(x, y) in Section 4.4.
We use the following Theorem to estimate the execution time for each phone to receive all messages, i.e., the value of t i . Theorem 2. The execution time for phone p i to receive all messages is expected to be where kmax is larges value of k i , and let c 1 = is the minimal value that satisfies the following condition, Proof. Let us consider the time point when the last phone finishes its first stage, i.e., the phone with the most messages. Let kmax = max{k i } Each phone p i has missed (1 − P(T i , α)) · i =j k j messages from their owners. However, some phones have broadcast messages in their second stage which guarantees a success delivery at all other nodes. In total, there have been messages in the second stage. We assume they evenly contribute to each phone's collecting process, i.e., each phone obtain at least c 2 n missing messages. For each message m, the probability that it has not been scanned by all the phones when the last phone enters the second stage is Therefore, there are candidate messages that can be put on device names in the second stage. Assume each phone picks a distinct message in the first round of second stage. For a particular message that p i needs, there is a probability of n−1 c 2 to be scanned after the first round. In the second round, the expected number of total candidate messages becomes c 2 − n and each message p i needs has a probability of n−1 c 2 −(n−1) to be collected. This process is repeated until p i obtains all the messages. Therefore, p i is expected to use r rounds in the second stage to collect all messages, such that Since the value of α is upper-bounded by T n + 2 · S, we can enumerate all possible values and derive the best value leading to the minimum i t i according to the above Theorem 2.

Analysis of Message Reception Probability
In this section, we analysis the message reception probability P(x, y) which is a critical building block for deriving the optimal parameters in our solution.
Based on Theorem 1, P(x, y) = 1 if y ≥ x + 2 · S. The following analysis is under the condition of y < x + 2 · S. The message reception probability depends on ont only the two input parameters x and y which indicate the length of scan interval and update interval (the message's active period), but also the schedule of scanning and update processes, i.e, the start points of the phone's (p i ) scanning phase and the message's (m) active period. Therefore, we need to consider several basic possible cases as follows.
• Case A: The active period of m is within p i 's scanning phase. The probability that p i can receive m is y S .  Let δ ∈ [0, S] be the difference between the start of the scanning phase and the end of the active period. The probability that p i can receive m is δ S .
• Case E: The active period of m starts in p i 's idle phase and ends in p i 's next idle phase. In this case the reception probability is 1. Combing these two scanning phases, therefore, the probability that p i can receive m (in at least one of the scanning phases) is • Case G: The active period of m starts in p i 's idle phase and ends in the second consecutive scanning phase. The reception probability is obviously 1.
• Case H: The active period of m starts in p i 's scanning phase and ends in the second consecutive idle phase. The reception probability is also 1.
Proof. We consider a scanning phase followed by a idle phase as a repeating round for phone p i and the message active period could start at any point in this round.
When y ∈ [x + S, x + 2 · S), as shown in Fig. 4.4, we can classify all possible scenarios F above and the difference from the start of the scanning phase ranges from 0 to u = x + 2 · S − y. Therefore, the reception probability is Proof. Let SP 1 and SP 2 be the closest scanning phase before and after the message active period starts, i.e., SP 1 belongs to the round, but SP 2 does not. Under the condition of y < x + S, the message active period could overlap with either SP 1 or SP 2 or both of them. Let δ be the offset of the message active period compared to the start of a round. We derive P(x, y) based on the analysis of the following three cases: (1) The message active period only overlaps with SP 1 , but not SP 2 . This case refers to Case A and Case C and δ ranges from 0 to S + x − y, the message reception probability is min{S−δ,y} S .
(2) The message active period only overlaps with SP 2 , but not SP 1 . This case refers to Case D, Case E and Case G. The message reception probability is δ+y−S−x S when δ ∈ [S, x + 2 · S − y] (Case D). The message reception probability is 1 when The message active period overlaps with both SP 1 and SP 2 . In this case, δ ranges from x + S − y to S. The lengths of the overlaps with SP 1 and SP 2 are S − δ and δ + y − x − S respectively. Referring Case F, the message reception probability is, Therefore, when y ∈ [x, x + S), Theorem 5. When y ∈ (0, x) Proof. The proof is similar to the above proof of Theorem 4. Under the condition of y < x, the message active period could overlap with either SP 1 or SP 2 . Let δ be the offset of the message active period compared to the start of a round. We derive P(x, y) based on the analysis of the following two cases: 1. The message active period only overlaps with SP 1 . This case refers to Case A and Case C and δ ranges from 0 to S + x − y, the message reception probability Therefore, following the above proof of 4, when y < x,

Implementation and Evaluation
In this section, we will first introduce the system implementation of our PASA system and then present the performance evaluation results from both smartphones experiments and simulation.

System Implementation
We choose Android operating system as our development environment, and have implemented PASA on different brands of smartphones, including Asus(Nexus 7), LG(Nexus 4) and Samsung(Galaxy Nexus).   Fig.4.6 show the configure setting and demo of our PASA system. The system mainly performs the following operations: • Input and publish message to Twitter, nearby users or both (Twitter, BLocal and BTwitter on Fig.4.5 correspondingly).
• Set or change configurations.
• Scan the nearby users to receive messages.
• Generate and transmit feedback to inform other users which messages it currently holds.
• View one specific local user's shared message.

Performance Evaluation
In this subsection, we present the performance evaluation on both Android smartphones(small scale) and simulation(large scale). The key of PASA is to, in different configure setups, quickly disseminate and gather local users' messages. Thus, the most important metric is the average complete time among all smartphones in the network.

Experimental Results
We set up a small testbed with 5 Android phones running our program. We consider the following four different scenarios for our evaluation.
• Scenario 1: All smartphones have the same scan interval(T i ) and number of available messages(k i ); • Scenario 2: They have different T i but the same k i ; • Scenario 3: They have different k i but the same T i ; • Scenario 4: Both T i and k are different for them.  and that of the last one is 108s, 66s and 122s for n = 3, 4, 5, respectively. But when α = 40, these three differences become 14s, 18s, 50s. The main reason is that when α is larger, more messages are delivered during the first stage which aligns each phone's progress.

Simulation Results
To evaluate a large scale network, we conduct simulation to test the performance of PASA. Our goal is to study the impact of the number of phones on the system

Summary
This chapter presents PASA, a smartphone Ad-Hoc network based communication model for a local message dissemination system. We present a two-stage protocol for propagate messages and provide in-depth analysis to derive the optimal update     In addition, the client-server architecture does not work for some applications.
For example, one of the major motivating applications in this chapter is the Rogue Access Point detection. We consider in a public area, there might be some maliciously The main challenge is how to select smartphones to host the messages so that the messages can be available in the system as long as possible. Ideally, we hope the messages are always accessible, i.e., when a new user joins the system at any time he can certainly read all the messages. However, when no smartphone keeps its wireless device always on, there is no guarantee of each message's availability. Our goal is to design appropriate strategies for each phone to manage the messages it hosts to maximizing the chance a user can read all the messages.

Related Work
In the research of intermittently connected networks, for example, Delay Tolerant In PASA [26], the authors introduce a new communication model named passive broadcast that utilizes the peer discovery process in P2P techniques to initialize and manage the ad-hoc network. This approach bypasses the real connection between the users by using the device name as an information carrier. The proposed Mobile Message Board (MMB) system takes advantage of the passive broadcast. However, relative to PASA that focuses on spreading the information, the MMB system mainly concerns about extending the activation period of the messages on the board.
One application of the MMB system is rogue access detection. Rogue Access Point is a wireless access point that has either been installed at a public area, like shopping malls and airports, without explicit authorization from a local network administrator, or has been created by a naive user for convenience. Multiple solutions have been proposed to prevent user from Rogue Access Point [66][67][68][69][70]. These solutions attempt to address the Rogue Access Points based on a centralized server that analyzing wireless traffic and reporting suspicious devices. However, those approaches require users to query their servers to check the database or connect to the access point first.
In our scenarios, users may not or very costly have Internet access, for example, in airports while roaming abroad. If users connect to the Rogue Access Point first, they have already exposed to the attackers.

Problem Formulation
In this chapter, we aim to develop a mobile message board (MMB) system without the support of the Internet infrastructure. We define a target area that hosts the message board, such as an airport terminal or a train station, a dining area with several restaurants, and a building with public hotspots. We assume that the users in the target area are within each other's communication range and they collaborate to host a virtualized message board. A user can leave messages on the board that will be shared with other nearby users, but are effective only in this area.

Ad-Hoc Communication Between Phones
Our problem setting and solution are based on the new connectionless communication model, passive broadcast, which has been introduced in [26]. Basically, every node conducts a periodical scan to fetch data from nearby nodes if available. When a node intends to send a message, it puts the message in a local buffer which will be sent to the nearby nodes later during their scanning processes. This communication model requires no connection to be established between any two nodes, thus is extremely efficient for message dissemination.
In this chapter, the connectionless model is implemented based on the mandatary 'peer discovery' function in Bluetooth and WiFi-Direct. Specifically, we apply the field of 'device name' to carry the messages. When sending a message, the user will replace the Bluetooth or WiFi-Direct device name with the target messages. The messages will be delivered to other nearby phones when they conduct peer discovery.
We have prototyped this new model on commercial phones. According to our experiments, it does not affect regular Bluetooth/WiFi-Direct functions. For example, a phone using this message delivery model can still pair with other Bluetooth devices such as a headset or a keyboard.

States And Operations Of Each Phone
According to the working procedure of Bluetooth module on the smartphone, in general, there are two states of each phone, Bluetooth ON and Bluetooth OFF. During the ON state, the users are willing to contribute to the local Mobile Message Board system through the ad-hoc communication with the others devices nearby. However, in the OFF state, the Bluetooth module is turned off to save energy, suggesting it cannot send or receive any messages in the system. In our setting, we assume each user already configures his own states schedule according to the energy budget and other user-specific factors.
The operations of a smartphone in the system includes: initial scan, message update, assignment and delegation.
• Initial scan: Initial scan is the phase when all the users in the system are performing the peer discovery process to collect the parameters from nearby devices such as the state schedules and the limit of message each user can host.
Based on the experiment in [26], the initial scan usually takes approximately 12.8 seconds.
• Message update: The connectionless communication model utilizes the device name. However, the device name usually has a limited length, e.g., a Bluetooth's device name in Android can be up to 248 bytes. Multiple short messages can be merged into one "device name". But a large message will have to be fragmented to fit in and a phone can periodically update the device name to rotate multiple messages or fragments. In our solution, we use a special character string as the prefix to distinguish the device names that adopt our scheme from the regular ones.
• Message assignment: Since each phone has its own states schedule, it is possible that the contributor who wants to share the message in the Mobile Message Board has very limited ON time. In order to yield a longer coverage or availability of a message so that others are more likely to receive it, the message owner will assign it to the other phones nearby that can help disseminate the message. The owner has to analyze each phones' state schedule and compare it with its own schedule to choose the best relay phones.
• Message delegation: This operation is conducted when a phone is leaving the target area of the MMB. It has to choose a set of phones in the system to delegate the active messages that are currently held by itself. This delegation keeps the messages remain active even when the owner and relay phones leave the system. To choose the right delegated phones, it compares the schedule with the current relay phones that hold the same message and others who are available to hold new messages. Message delegation is also used to improve the active length of the messages.

Objective And Constraints
In this chapter, our goal is to develop efficient algorithms for message assignment For each message m j , let c j (t) indicate if the message is active at time t, and w j be its weight indicating its importance or urgency. In addition, we include two threshold parameters: each phone can host at most τ distinct messages, and each message can have up to θ replicas in the system. Therefore, our problem is formulated as follows: The problem is NP-hard (due to the page limit, we omit the proof here.), and in the next section, we'll present our algorithms based on greedy strategy.

Mobile Message Board
In our solution, each user uses its phone's "device name" to carry the messages on the mobile message board (MMB) and enable the communication protocols with other users. Particularly, three categories of data are hosted on the device name: • Payload messages: These messages are posted on the MMB and supposed to be accessible to nearby users.
• Control messages: These messages are part of particular communication protocols developed in our solution.
• Header: The header contains general profile information about the user such as the scanning schedule.
Since the length of the device name is limited, our solution allocates a fixed segment for each category of data. We assume that each user device can host at most θ payload messages with the knowledge of the average length of a message. In addition, each user reserves a certain space to hold one control message (the size of the control message will be introduced later when we present the protocols). The rest of the space on the device name will be allocated to the header information.
The following Fig. 5.1 illustrates an example of the data hosted on the device name.
All the devices participating our protocols will use a special prefix in the beginning of the device name in order to distinguish themselves. The payload messages are listed with their owner and weight information separated by "##". In our solution, each device is identified by two bytes which is the hashed value of its MAC address.
The control message starts with a list of recipients which is followed by the message content. Different from the payload messages, the control messages in our protocols usually are not broadcast messages, but with certain target recipients. Finally, the header contains its ID and the system parameters which include the state schedule and the maximum number of messages it can host. The following Table 5.1 lists the notations we will use in the rest of this chapter. In the following subsections, we present our algorithms in two different cases depending on if a coordinator node exists in the system. u i / m j / w j the i-th user / the j-th message / the weight of m j T i / I i the length of "on" period / "off" period of u i x ij the indicator of whether u i hosts m j y i (t) the indicator of whether u i is on at time t c j (t) the indicator of whether m j is available at time t τ / θ the limit of # of msgs per user / # of replicas per msg AN i the set of accessible neighbors of u i HU n the set of messages that u n currently hosting

With A Coordinator
A coordinator in our system is defined as a node that is aware all other nodes' schedule. In another word, it has successfully scanned all other nodes' information during the initial scan. Specifically, the coordinator recognizes the y i (t) for all u i ∈ U .
When such a coordinator exists in the system, it will be responsible for assigning the messages to each smartphone and maximize the total weights as shown in objective 5.1.
We develop an algorithm 5 for the coordinator to complete the assignment. The basic intuition is to apply greedy strategy to select a subset of nodes to host each message. First, it calculates the least multiple common of all the users' cycle lengths of their schedule and combines all the active messages into a set named msgs (lines 1-2). For every message m j ∈ msgs, it initializes the candidate smartphone set, S j , which contains all the available users, the selected user set, A j , which is empty initially and activation function, F j , that indicates whether the message m j is discoverable in the MMB system (lines [3][4]. The main part of the algorithm is a while loop which will enumerates every message. The loop terminates when all the messages are if c · w j > OP T then 14: OP T = c · w j , i * = i, j * = j

22:
for t = 1 to L LM C do 23: assigned (msgs = φ), or all the phones are fully loaded (S j = φ). The parameters OP T , i * and j * are temporary variables where OP T stores the current optimum for this message m j ; i * is the current selected user id and j * currently message id (lines 5-6). For every candidate in the S j , the coordinator calculates the activation period indicator, c, and the total weight, c × w j . If the c × w j is larger than the current optimum OP T , then it updates the temporary parameters (lines [8][9][10][11][12][13][14]. When m j is assigned to u i , it updates the m j 's selected user set, A j , the counter of currently hosting message, CM * j and the counter of currently hosting users, CU * i (lines [15][16]. The algorithm monitors these two counters CM * j and CU * i to check if they reach the preset thresholds and updates the msgs and S j sets when needed (lines17-21).
Finally, the coordinator refreshes activation function for m j (line 22).

Without A Coordinator
In some scenarios, a coordinator may not exist in the system because of the misalignment of the state schedules among all the nodes. In this subsection, we present a solution for the MMB without a coordinator. Our solution includes two stages: initial assignment and message delegation, with the objective of maximizing the message's active period.
The initial assignment is performed by every message owner. Since the owner may have very limited ON period (according to its state schedule), whenever a user generates a message, it runs through the initial assignment to choose the best holders for it.  if y i (t) = 1 then holders m j = holders m j − u n * 10: while users = φ and CM < θ + 1 do 11: for Every u i in users do 12: for t = 1 to L LM C do 13: if y i (t) = 1 then  16: if OP T * > OP T then 17: OP T = OP T * , DU = u i Without the coordinator's assistance, the owner may fail to choose the best users to host the message due to the limit of accessible neighbors. In this case, after the initial assignment, the selected users keep tracking to see if there is any better user that can hold the message and lengthen the total active time.

Implementation And Evaluation
In this section, we will first introduce the system implementation of our MMB system and then present the performance evaluation results from our experiments and simulation.

System Implementation
In the implementation, we take advantage of the MMB system in the application of warning the Rogue Access Point (RAP) in an airport when users are not able to or very costly to connect to the Internet. In this scenario, users report the RAP by changing their Bluetooth name and publish the information to the MMB. When a user finds a possible RAP, it changes its Bluetooth name to "MMB:Mac:X", where MMB is a prefix that is used to filter out unrelated Bluetooth devices, Mac is the RAP's MAC address and X stands for 1 or 2 which indicates rogue access point or slow speed access point.
We implement the prototype as an Android application for smartphone. However, for off-the-shelf phones, as long as they have Bluetooth modules and can change their namespaces, they can contribute to the system by reporting the suspected access points. Fig. 5.2 is a set of screen shots of the Android application. Upon opening the application, the users need to initiate scanning to discover the nearby MMB warning messages (the left figure of Fig. 5.2). Then, they can start discovering the active nearby Wi-Fi hotspots and the reported access points are clearly marked (the middle figure of Fig. 5.2). When a user attempts to click "connect" button, the warning message will pop up (the right figure of Fig. 5.2).

Environment Settings
In this subsection, we discuss the details of the environment settings in both experiments and simulations.

Experiments
In the experiments, we use 6 Android smartphones that include LG Nexus 4, Nexus 5, Google Nexus 7 and Samsung Galaxy S4. During the experiment, we distribute the smartphones on the desks in our lab which is around 20m 2 to form a fully connected network. The state schedule, T i and I i , is preloaded in each phone. In addition, other user settings, like messages and thresholds, are pre-configured.

Simulations
We use the Crawdad dataset from Dartmouth [71] for the simulation. The particular dataset we use is Sigcomm 2009 trace that contains Bluetooth encounters, opportunistic messaging, and social profiles of 76 users of MobiClique [72] application. Based on the length of encounter time and activity, we filter out the users who only appear in a short period and lack of activities. Then, there are 52 users left whom we consider as the valid clients. We drive the encounter length and number of social messages from the dataset as the parameters. In the simulation, we randomly pick up the users from the valid clients pool. Due to lack of the Bluetooth OFF state data, we assign each user a OFF length randomly so that each user has a state schedule. Finally, the parameters are fed to our simulator to examine the Mobile Message Board system.

Performance Evaluation
In this subsection, we present the evaluation results from both Android smartphones experiments (small scale) and simulation (large scale). We consider the following four different cases for our evaluation.
• Case 1: Only one message generated by one user in the MMB system.
• Case 2: Multiple messages generated by the same user.
• Case 3: One message generated by multiple users.
• Case 4: Multiple messages generated by different users.
The major performance metric we exam is the Activation Rate (AR) for each message. For each m j ∈ M , its activation rate is defined as, where, according to Table 5.1, c(t) is the indicator of whether m j is active at time t and L LM C is the function that returns the least multiple common of all the users' state schedules in the MMB system.

Experimental Results
We manually set the required state schedule and randomly choose the limit number of messages per user in the range from 1 to 3 for each phone as shown in Table 5    Then we focus on the impact of τ which controls the maximum number of messages each user can host. As shown in Table 5.2, τ is randomly selected from 1 to 3. Fig. 5.4 compares the case 4 under the random setting above and the maximum setting that assigns every user the limit of 3 messages. The figure indicates that the maximum τ setting can improve the activation rate. The difference of state schedules results in the improvement since the user with largest ON state portion, user 2, can hold more messages (1 v .s 3 ).

Simulation Results
In the simulation, we use the parameters that derived from the trace. However, it lacks the records of Bluetooth OFF state and messages replicas. Therefore, we randomly pick the OFF state from 5 to 50 and the number of replicas from 1 to 5.  setting, the average activation rate is 0.77 after message initial assignment. The overall activation rate improves to 0.82 in two periods after the delegation.

Summary
This chapter presents a Mobile Message Board (MMB) system for smartphone users to share messages in a target area. Our solution is built on ad-hoc communication model without the support from the Internet. We present algorithms that appropriately manage the messages on each participating phone to maximize the message availability in the system. In addition, we have implemented our solution on off-the-shelf phones. Our evaluation based on experiments and simulation shows that our system is efficient and effective for disseminating messages in the proximity.

CHAPTER 6 SKYFILES: EFFICIENT AND SECURE CLOUD-ASSISTED FILE MANAGEMENT
In this chapter, we develop Skyfiles which is a system for smartphone users to manage their files in the cloud storage. Our basic idea is to launch a cloud instance to assist users to accomplish the file operations. It is motivated by the fact that the cloud instance is inexpesive and sometimes free. For example, Amazon Web Service (AWS) [73] provides 750 free Micro instance hours per month. By using the resources of the instance, smartphone users will significantly reduce the bandwidth consumption for file operations. Skyfile still does not require users to keep local copies of files, but provides advanced and secure operations.

Related Work
In the past few years, cloud computing and storage technology gained increasing attention in mobile applications.In [74], a survey studies offloading computation with the objective of extending smartphone battery life. MAUI [75], Cuckoo [76] and ThinkAir [77] implement an Android framework on top of the existing runtime system. These three systems are easy to deploy because they only need to access to the program source codes, and they do not require modifying the existing operating system. They provide a dynamic runtime system which can, at runtime, decide whether a part of an application is better to be executed locally or remotely.
Besides offloading computation, SmartDiet [78] aims at offloading communicationrelated tasks to cloud in order to save energy of smartphones. The authors of [79] investigate Dropbox users to understand characteristics of personal cloud storage services on mobile device. Their results show possible performance bottlenecks caused by either the current system architecture and the storage protocol. In [80], the authors focus on the impact of virtualization for Dropbox-like cloud storage systems. Another related area in the prior work is to use cloud to enhance mobile device security and privacy. CloudShield [81] presents an efficient anti-malware smartphone patching with a P2P network on the cloud and CloudShield can stop worm spreading between smartphones by using cloud clones. The authors of [82] propose the Confidentiality as a Service (CaaS) paradigm to provide usable confidentiality and integrity for the bulk of users who think the current security mechanisms are too complex or require too much effort for them. In their paradigm, CaaS separates capabilities and requires less trust from cloud or CaaS providers, leverages existing infrastructure and can performs automatic key management. They test CaaS on facebook, dropbox and some popular service providers.

Background
This subsection introduces background information about cloud storage service.
Most of our experiments in this paper are conducted on Dropbox platform. Thus, this section regards Dropbox as a representative service provider and briefly describes the Dropbox architecture and functions for user applications.
As a leading solution in personal cloud storage market, Dropbox provides crossplatform service based on Amazon Simple Storage Service(S3) for both desktop and mobile users. The architecture of Dropbox follows a layered structure. At bottom level, Amazon S3 infrastructure provides a basic interface for storing and retrieving data. The above layer is Dropbox core system which interacts with S3 storage service and serves higher level applications. The top layer is the official Dropbox application and a set of APIs for developers to build third party applications.
To manage third party applications, Dropbox assigns each of them an unique app key and app secret. When a user launches an application, Dropbox server follows the OAuth v1 [83] for authentication. Fig. 6.1 shows the basic authentication process.
When launched by a user, the third party app contacts the Dropbox server to obtain a one time request token and request secret (step 2,3). Then, the app uses them to forma redirect link and present the link to the user(step 4). When accessing this link, the user will be prompted to login his Dropbox account and the Dropbox server will verify the redirect link and the user's login information. After a successful login, the server will return an access token and access secret to the application (step 6), which grants access permissions on the user's data stored on Dropbox.

Basic Solutions
In this section, we present our basic solutions in Skyfiles for supporting cloud file managements for mobile devices. We first describe the framework of Skyfiles and cloud-assisted file operations. Then, we focus on the file transfer between two users' cloud storage in Skyfiles. Our objective is to accomplish file operations with minimum network bandwidth assumption.

Framework And Basic Cloud-assisted Operations
In Skyfiles, each mobile device is associated with a cloud storage account. Similar to other related apps, Skyfiles by default does not keep local copies of the files stored in cloud because of the storage limit and bandwidth consumption. Instead, Skyfiles maintains a shadow file system on the mobile device which includes the meta information of the files stored in cloud. This local file system is built on service provider's APIs and synchronized with the cloud storage.
Skyfiles supports two categories of file operations. The first category is the basic file operations that are commonly available in service providers' APIs such as creating/deleting/renaming a file. The second category is a new set of advance file operations that require assistance from a cloud instance. Skyfiles recognizes the category each operation request from a user belongs to and processes it accordingly. The first category will be handled by regular API function calls. For the second category, Skyfiles will create a cloud instance and then forward the file operation request to the instance for processing. In particular, we have designed the following four cloud-assisted operations in Skyfiles: • Download: This operation allows a user to download files directly to his cloud storage. Given the location of the target files such as URLs, the conventional way of downloading is to first obtain the files on user devices and then synchronize with/upload to the cloud storage. In Skyfiles, the cloud instance will fetch the files and then upload them to the user's cloud storage. Thus the downloading and uploading will not consume mobile device's bandwidth.
• Compress: This operation enables a user to compress existing files or directories stored in cloud. If user devices hold local copies of the target files, the operation can be easily accomplished and the generated compressed file can be uploaded to the cloud storage. In Skyfiles or other similar apps for mobile devices, however, the actual file contents are not available. Thus we design an interface that the user can select the target files based on the local shadow file system with meta data and then the compressing operation is forwarded to a cloud instance for execution. The instance will fetch the specified files from the cloud storage, compress them, and upload the compressed file back to the cloud storage.
• Encrypt: This operation is similar to compress and does not exist in current apps that do not keep local file copies. In Skyfiles, the user can choose the target files and the cipher suite including the cryptographic algorithm and key.
The encryption operation will be sent to a cloud instance. Similarly, the cloud instance will download the target files from the user's cloud storage, encrypt them, and send the ciphertext back to the cloud storage.
• Convert: The last operation is particularly for media files such as pictures and video clips. When a user wants to view a picture stored in cloud, he has to download it to his smartphone. Nowadays, high-resolution picture files could be very large, but a smartphone user may not benefit from it because of the limited screen size. In Skyfiles, therefore, a user can specify an acceptable resolution when viewing a picture and the request will be processed by a cloud instance.
The original picture will be downloaded to the instance and then converted to a smaller file according to the user-specified resolution. Finally, the converted picture is sent to the user.
Overall, we develop the above set of advance file operations for mobile devices which are impossible to achieve without local file copies. In Skyfiles, a cloud instance is launched to assist a user to accomplish these file operations. During the execution of the file operations, the cloud instance will periodically send heartbeat messages to the smartphone to report the progress and status. The smartphones only consumes a small amount of bandwidth for exchanging control messages with the cloud storage server and the cloud instance.

File Transfer Between Users
In this subsection, we present an important feature of Skyfiles which allows file transfer between users. While most cloud storage services allow a user to share files with another user, copying files across different user spaces is not supported. However, file sharing between users cannot substitute file transfer (make a copy). With file sharing, a user's actions on the shared files will affect other users. For example, if a user deletes the shared files, all the other users lose those files too. In this subsection, we consider the file transfer between user spaces illustrated in Fig.6 In Skyfiles, we solve the problem by following the same design principal that utilizes a cloud instance to assist users to transfer files between their cloud storage spaces. Basically, a cloud instance is initialized and plays a role of relay node. It fetches the target files from sender's cloud storage space and then forward them to the receiver's cloud storage. In this means, both sender and receiver's smartphones do  The basic design of using a cloud instance, however, is challenging in practice when no trust has been established between the sender and receiver. The cloud instance can be created by either the sender or receiver. In either case, it is not a secure solution for the party who does not own the instance because the cloud instance will need to obtain the security credentials of cloud storage from both sender and receiver to complete the file transfer. Therefore, the owner of the cloud instance will be able to access the cloud storage space of the other user which could breach data privacy and lead to other malicious operations.
To address the above issue, in Skyfiles, we develop a solution that requires a cloud instance from both sender and receiver. In particular, we implement the following Algorithm 8 to accomplish the file transfer. Assume user U A is trying to send a file F (F can also represent a set of files) to user U B . Let F src be the location of F in U A 's cloud storage and F dst be the destination location that U B will put in his cloud storage. In our protocol description, U A and U B also represent the users' smartphones.
The following Algorithm 8 presents the major steps for file transfer. First, U A starts a cloud instance (I A ) and uploads the security credentials for accessing his cloud storage space to the instance. U A 's request also includes the source file location F src and an intermediate file location U RI F (uniform resource identifier) which indicates where to store F on the instance. The cloud instance will use the security credentials to download the target file F to its local disk. At this point, I A needs to make F accessible to user U B . It first sends U A the intermediate file location U RI F . Then, I A can set F publicly available or create a guest account and set the permissions of F so that only the guest account can access it. In the latter case, the security information for logging as the guest account, such as login password or identity file, needs to be sent back to U A as well. After that, the steps on U A 's side have been completed.
Then, U A needs to notify U B necessary information for accessing F . Since this step of communication includes sensitive information, Skyfiles adopts NFC protocol to securely deliver U RI F and optional login information from U A 's smartphone to U B 's phone. At receiver's side, U B also starts a cloud instance I B which obtains F from I A based on U RI F . Finally, I B uploads F to F dst . Here, both sender and receiver start a cloud instance to behave as their agents. The data transfer of F is between cloud instances and cloud storage servers which does not consume bandwidth of users' smartphones. Meanwhile, the security credentials for accessing cloud storage are only sent to the instance created by the same owner. Thus, in Skyfiles, file transfer between two users' cloud storage is efficient and secure.

Solutions With Shared Cloud Instances
The solutions presented above efficiently enable smartphone users to manage their files on cloud by launching cloud instances for assistance. In practice, however, the following two issues may hinder the deployment of the proposed solutions. First, initializing a cloud instance incurs a significant overhead, e.g., the overhead ranges from 15 seconds to 30 seconds in our experiments in Section6.5. In reality, such a long delay is not suitable for some file operations which require instant response and may negatively affect users experience. The second issue is the cost of launching cloud instances. Although cloud service is inexpensive, frequently starting cloud instances may still increase the cost of users. High cost could be caused by users' misconfiguration and incorrect design of Apps. Users can certainly monitor the usage and charge on their cloud service account to avoid unexpected costs. But it could greatly limit the features of Skyfiles.
In this section, we propose an enhancement for Skyfiles that solves the overhead and cost issues by allowing users to share cloud instances with each other. It is motivated by the fact that cloud service providers charge the instance service at a certain time granularity. For example, AWS, Microsoft Azure [84] and HP Cloud [85] charge the usage of cloud instance at the granularity of an hour. For regular file operations, it is a excessive time period. If a user starts a cloud instance for a file operation, he does not have to terminate the instance when the operation is done.
The instance can be kept running until an additional cost is about to be charged. For example, assume a service provider charges the instance service in the time unit of an hour, when a user starts an instance and finishes his file operations in the first 5 minutes, the instance he started can stay active for another 55 minutes without extra cost for him. During this idle time period, if the instance can serve other users or other file operations from the same user, the overhead and cost will be both reduced.
While benefiting the performance, the design principal of sharing instances among users incurs challenge for security. First, it is risky for a user to upload his security credentials of cloud storage account to other users' cloud instances. The owner of the instance may monitor and catch the security credential, and gain the access to the user's cloud storage space. Second, when open to public, the shared cloud instances may be used by malicious users to launch attacks.
In Skyfiles, we have developed a framework for sharing instances which requires a trusted server. This server maintains a list of available cloud instances for sharing and coordinates the users who request instances and share instances. Skyfiles applies the following two basic policies to address the security concerns. First, an instance is shared in the form of launching a background service and accepting requests from other users, rather than allowing other users to login and execute arbitrary programs.
Second, when using a shared instance, a user does not upload the security credentials of his cloud storage account in plaintext, but in an encrypted format. In this way, the owner of the instance can not gain the access to the tenant user's cloud storage space and any user's privileges on shared instances are limited to the specified file operations.
Specifically, there are three types of entities in our design, a trusted server S, a user U A who wants to conduct file operations on a shared instance, and an available cloud instance I owned by another user U B . The trusted server holds a binary program P that can be running on a shared instance to provide Skyfile services to other users.
Once a user (U B ) decides to share his instance (I), the instance will contact the server and forwards the basic information about I such as operating system, hardware setting, and the time left for sharing. The response from the server is an executable binary P , where a secret key k P is embedded. We assume k P is protected by program obfuscation techniques and I B is not able to derive k P from P . In addition, the server will periodically change k P and re-compile the binary. Upon receiving P , I will execute P as a service and be ready to accept other users' requests. The server, on the other hand, adds I B into the list of available instances for sharing. Finally, each shared instance I can set a scheduled task to automatically shut down the instance before the additional charge is incurred. During the shutdown process, I also notifies the server S which will consequently remove I from the list of available instances for sharing.
I → S: willing to share; S → I: program P embedded with a key k P ; I executes P ; S adds I into the list of available instances Single User Operations: When a user (U A ) requests to use a shared instance to conduct operations on his files on cloud, he needs to first contact the trusted server S.
S will generate a random seed R A for the requesting user and apply a hash function H on k P and R A to generate another key k A , The server then chooses a shared instance from the list to serve U A and it could be an interactive process that involves U A 's opinion. Assume I is selected, the server sends {R A , k A } and the IP address of I back to the user U A . Next, U A will encrypt the security credentials of his cloud storage using key k A and upload the ciphertext and R A to the shared instance I. The security credentials will be decrypted in the execution of P , which takes R A as an input parameter and apply the same hash function H on k P and R A . U A → S: request a shared instance; S → U A : I, R A and k A ; It is possible that multiple users share the same instance in which case the server S will assign different random number R and key k.
File transfer between users: In Skyfiles, two users can also request a shared instance for transferring files between their cloud storages. Following the design in Section 6.3, the sender will initialize the process and request a shared instance from the server. Compared to the single user operations, file transfer requires both sender (U A ) and receiver (U B ) to send the security credentials of their cloud storage account to the shared instance. In addition, the sender needs to notify the receiver the instance assigned by S. The following Algorithm 9 shows the major messages exchanged in our design. We assume that the server holds a pair of public key/private key, indicated by k + S /k − S and the public key is known by U A and U B . , which is a signature of the requesting user's ID and the assigned instance I. U A will upload the encrypted security credentials to I as well as the source file location (F src ) and intermediate file location (U RI F ). Then U A will notify the receiver U B the shared instance I and the location of the target files (U RI F ). This message is attached with the certificate from S so that the receiver can verify the shared instance I is legitimate. Next, the receiver U B sends the server a request with (U A , I). After verifying there exists a shared instance I serving U A , the server will send back R B and k B to U B so that U B can encrypt his security credentials in the same way as U A . Eventually, U B uploads the encrypted security credentials and the intermediate file location (U RI F ) and destination file location (F dst ) to the shared instance I.

Performance Evaluation
In this section, we present the evaluation results of Skyfiles based on experiments.
We have implemented Skyfiles system on Android with Dropbox [19] storage service and tested it on Google Nexus smartphone running Android 4.1. For cloud-assisted operations, we use the service provided by Amazon Web Service (AWS EC2) [73] and all the experiments are conducted on the Micro instance (613 MB memory, up to 2 EC2 Compute Units). The major performance metrics we consider are time overhead and bandwidth consumption. To measure the first metric, we insert System.currentTimeMillis() java function into the Skyfiles codes to catch the timestamps and calculate the time overhead for each step we are interested in. Measuring bandwidth consumption for a file operation is more challenging. In our experiments, we first connect smartphones to a WiFi access point (AP) for Internet access. A Linksys WRT54GL wireless router running DD-WRT [86] serves as the AP in our tests. For a particular file operation, we start a tcpdump [87] session to record all data packets sent from and received by the smartphone. Then, we use a typical analyzer to retrieve the transferred data size from the trace records. To make the measurement more accurate, we additionally set the firewall on the smartphone to block network traffic from all the applications except Skyfiles. For each particular setting, we conduct five independent experiments and the average values are reported in this section.

Basic File Operations
We first present the bandwidth consumption of basic file operations implemented by official Dropbox APIs. In this test, we create a new Dropbox account with a folder "test" containing 1000 text files (22 bytes each). The operations we tested are 1. log into dropbox; 2. create/delete a folder (under the root directory); 3. create/delete/rename a file (under "test"); 4. enter/leave a folder ("test"). APIs need to recursively fetch meta data to synchronize/update the local shadow file system. Creating and deleting an empty folder consumes 7.3K and 3.9K bytes respectively which are the minimum costs among the tested operations. Creating and deleting a text file is similar to the previous case. When tested in the folder "test," it certainly incurs more bandwidth cost (15.5K and 11.2K bytes). The reason is that the folder contains 1000 other files and once a change is made in the folder, Dropbox APIs will re-fetch the list of files in it. Finally, when a user enters the folder and then leave, this operation costs 9.7K bytes bandwidth which is slightly lower than creating/deleting a file. The dominant factor is still fetching the entire file list.

Cloud-assisted Advance File Operations
In this subsection, we evaluate the cloud-assisted file operations in Skyfiles, particularly download and compression. Due to the page limit, we omit the results for encrypt and convert operations. The performance of encrypt operation is similar to that of compress operation. Skyfiles supports these operations with user-created cloud instances and shared instances. The difference on the performance is that using shared instances saves the initial cost (mainly the time overhead) of starting a cloud instance. Therefore, we first present the overhead of starting a cloud instance and then show the performance of these operations under the assumption that a cloud instance has been available. The workload we use for testing includes 4 sets of files: one picture (16M bytes), five pictures (83M bytes), and two video clips (63M and 127M bytes).

File Transfer Between Users
The performance of file transfer is similar to the above advance file operations.
The process is the same as the downloading phase in compress operation followed the uploading phase in download operation, i.e., target files are downloaded by an instance from Dropbox storage (sender's account) and then uploaded back to Dropbox storage (receiver's account). The time overhead and bandwidth consumption are very close to those in advance file operations such as compression and encryption. When

Dynamic And Agile Buffer Control
In this section, we present our solution DAB, a dynamic and agile buffer control algorithm for mobile devices. The basic idea is to dynamically change the buffer size for prefetching streaming videos according to the link quality and user mobility.
The objective is to provide smooth video playback with the minimum bandwidth consumption for downloading video contents.
Essentially, the optimal size of the video buffer on smartphones depends on the video quality and wireless link quality. Video quality indicates the amount of necessary video data for a smooth playback to be prefetched by the player. Apparently, higher quality videos require more data prefetched in the buffer, thus preferring a larger buffer size. Once a video clip is chosen to be player, the quality of the video specifies the minimum requirement of the buffer size, which can be considered as a given parameter for the player. In this chapter, we are focusing on the second factor of wireless link quality while holding the minimum threshold of the buffer size defined by the video quality.
The link quality refers to the network bandwidth capacity for supporting video streaming. We aim to develop an algorithm to accommodate the current link quality by adjusting the buffer size. First of all, all our discussions are for the scenarios where link quality is sufficiently good to support the video rate. The buffer control is ineffective in the application if the link quality is poor because when the video content consumption is faster than the prefetch rate, the buffer will eventually become empty regardless of the buffer size causing a pause of the play. Ideally, the buffer should hold the video data just a little ahead of the current position to guarantee the smooth playback, and then prefetch new contents at the same rate as video rate.
For mobile users, however, it is extremely hard to accurately keep an appropriate buffer size because the link quality is highly dynamic due to signal propagation and user mobility. Mobile device may even be temporarily disconnected (e.g., handoff between APs). Intuitively, for a static user, when the link quality is adequate, i.e., the bandwidth is much higher than the video rate, the buffer size can be set to the minimum requirement specified by the video quality. When the bandwidth is close to the video rate, we may need to buffer some more data considering small

Measurement of Accelerometers
Nowadays, accelerometer is a common sensor on smartphones. The accelerometer sensor can continuously measure the acceleration values on the smartphone in the directions of X (lateral), Y (longitudinal) and Z(vertical). Our solution uses the accelerometer readings as another alternative to detect the movement of a client and further estimates his moving speed to help predict the change of link quality.
Specifically, we develop two schemes to analyze the accelerometer readings. The first one quickly checks if a user is static or moving. And in case the user is moving, our second scheme, which involves more computations, further derives the moving speed of the user.
Detect whether a User is Moving: To detect whether a user is moving, we only consider the average amplitude of the three directions. The faster the user moves, the greater the average amplitude is. We set a threshold τ for the average amplitude to distinguish if a user is static (sitting or standing) or moving (walking or running).  Estimate a User's Moving Speed: In order to set an appropriate size of video cache, it's not enough to just predict whether a user is leaving the access point. We also need to estimate how soon it will happen. Thus once our solution detects a user is moving, it will use accelerometer to estimate the user's moving speed. We define five discreet levels to represent the speed (level 0∼4), where level 4 represents the highest speed and level 0 indicates a static user.
Specifically, the moving speed is proportional to the stride frequency and the length of one step. Let S be the moving speed, F be the stride frequency (steps/sec) and L be the length of one step. Then S can be calculated as S = F · L. We assume that L is nearly a constant and known as a prior knowledge. Then our focus is to calculate the stride frequency based on the accelerometer measurements. In our approach, We continuously detect the average amplitudeĀ of accelerometer every t m represented as C. For example, assume A i and A j represent two consecutive peaks.
The time interval of one step should be C = (j − i) · t m . Then, 1 (j−i)·tm should be the stride frequency F . Once we get the stride frequency of a user, we round it up to the nearest whole number as its corresponding speed level. From the experiments, the stride frequency of a user is seldomly larger than 4 steps/sec. So we set four speed levels for moving users in our algorithm, i.e., the level index indicates the number of steps per second.
Algorithm 10 illustrates the details of deriving the speed level (variable SL) of a user. We use avg to represent the average value of all elements in the list A. In line 2, if avg is less than τ , the user is static and the algorithm return 0 as the value of SL.
Otherwise, we use P and T to represent the sets of indexes of all peaks and troughs respectively. A h and A l represents the temporary highest/lowest values in the list A and I h and I l represent the indexes of them, i.e., A h = A[I h ] and A l = A[I l ]. Lines 4 and 5 update the current highest/lowest value and mark its index. In line 6, the algorithm determines that the trend of values is going down. In this case, the current highest value will be set as a peak and the index I h will be added to P. Similarly, line 7 finds the troughs in the wave and the index of each trough will be added in T . Once we get P and T , lines 8∼13 are to calculate the average time interval of each two consecutive peaks/troughs. Finally, the algorithm derives the average stride frequency and calculate the user's speed level(SL) in line 14. Fig. 7.3 shows the examples of accelerometer readings that lead to different speed levels.

Dynamic and Agile Buffer-control
In this subsection, we present our Dynamic and Agile Buffer-control (DAB) scheme that combines the measurements of RSSIs and accelerometer and adaptively adjust the buffer size on-the-fly. Comparing RSSI and accelerometer readings, we observe if an internal sensor, accelerometer can be accessed any time by any program. Our solution still periodically checks the accelerometer values, but the the interval between two consecutive readings is set to be very small. RSSIs, however, are only available upon the arrivals of packets such as data packets or beacon messages from the APs.
Thus RSSIs are not instantly available when the program needs it and the interval between two consecutive RSSI measurements is larger than the interval that we can set for accelerometer readings, e.g., beacon messages from an AP are broadcast with an interval of 100ms. The third difference between RSSI and accelerometer measurements is that RSSIs more directly reflect the link quality while accelerometer readings only indirectly indicate the link change. RSSIs are the measurement of wireless signals. Despite of unavoidable inaccuracy due to environmental factors and hardware  Considering the above characteristics of RSSI and accelerometer measurements, we develop an algorithm that predict the change of link quality and dynamically adjust the buffer size. Specifically, our main idea is to continuously monitor the accelerometer values (Section 7.2.2) and once a movement is detected, we will further measure the RSSIs (Section 7.2.1). The new buffer size is decided based on both measurements. given the video quality of a clip to be played, let B min be the minimum buffer size required for a smooth play (as discussed in Section 7.2). We use R to represent the set of RSSI indexes (Section 7.2.1) and S to indicate the most recent accelerometer-based speed level (Section 7.2.2). Initially, R is empty and RSSI measurement is disabled.
Our algorithm only continuously accesses the accelerometer and derive the value of S. Once S > 0 (line 2), which indicates a user starts moving, our solution will start to monitor the RSSIs and collect m measurements. The derive RSSI index values are stored in R. In line 5, the algorithm finds the minimum and maximum values in R and stores their indexes in the variable u and v respectively. When u > v, we suppose the link quality is getting better; otherwise (u < v), the link quality is degrading.
In lines 7 and 9, our algorithm adjusts the buffer size correspondingly. We use two parameters α ∈ (0, 1) and β > 1 to define two heuristic functions to change the buffer size. Intuitively, when the link quality is improving (line 7), we should reduce the buffer size towards B min . The reduced amount of buffer size should be proportional to the moving speed (S) and the increase of the RSSI (R[v] − R[u]). In another work, the faster a user moves or the more improvement is on RSSI index, the smaller the resulting buffer size is. Similarly, when the link quality gets worse, our algorithm increases the buffer size considering the moving speed and the gap between the best and worst RSSI indexes. The difference on the exponents of β in line 7 and line 9 is for another design intuition that slowly increases the buffer size and quickly decreases it in the appropriate circumstances. Finally, we also consider the actual usage of the buffer during the video play. Let B u be the size of the actual data stored in the buffer, apparently B u ≤ B. If B u keeps smaller than B, which implies that the utilization of B is not full, our algorithm will reduce the buffer size B. In Algorithm 11, we use 0.9 as a threshold for checking the utilization of the buffer. We use a count variable c to record the number of consecutive occurrences of B u < 0.9 · B. When the value of c exceeds another threshold W , the algorithm will adaptively shrink the buffer size to be 0.9 · B (line 13).

Implementation And Evaluation
In this section, we first introduce the system implementation of our solution and then present the performance evaluation results based on smartphone experiments.

System Implementation And Experiment Setup
We implement our solution DAB on Android platform and deploy it on an assorted set of phones with different manufactures including LG, ASUS, and Samsung. Specifically, in the implementation, we use vitamio [102], an open multimedia framework for android, as our base development platform. Youtube is the video service provider in our experiments. Additionally, to better evaluate our solution, we implement two commonly used buffer mechanisms: Flip-Flop(FF) and Maximum(Max), for comparison. With Flip-Flop mechanism, the video player uses a preset value as the fixed buffer size, such as 10 seconds or 2MB. Whenever the buffer is full, it stops video prefetching. In Maximum buffer mechanism, the player simply keeps downloading data until all the video data has been buffered.
Finally, in order to thoroughly test our application in different network conditions, we attach the android phones to a router running DD-WRT [86], a Linux-based firmware. On DD-WRT, we use tc(traffic control) command to limit the maximum connection speed on certain device. To simulate the mobility, the users continuously move around within the router's communication range, backward and forward.

Performance Evaluation
To measure the smoothness of the playback, the performance metric of our application is defined as total stalling duration equation where C BS i and C P S i are the i-th current-buffered size and current-played size. When C BS i −C P S i = 0, the playback is stalling. The application records those values with an interval of 500ms which is represent by t i in the above equation. By multiplying the interval and the number of recorded stalling cases, we get the total stalling duration which is denoted by ∆ t .
Another objective of our solution is to efficiently use the buffered bytes so that a user can save bandwidth and server can reduce the traffic load. To quantify this target, we define the two parameters E i and R i in Eq. 7.2 and Eq. 7.3, where T i is the recording timestamp of the i-th record, E i is the buffer efficiency at T i and R i is the average buffer redundancy rate from 0 to T i which indicates the extra bandwidth cost on this video and, obviously, the lower the better it is.
In this subsection, we present the evaluation result of our proposed solution. For Algorithm 11, we set α = 0.3 and β = 1.1. For the compared FF method, we set the buffer size as 10 seconds. In our experiments, we use a 115-second Youtube video clip which is 9.38MB as the source. In each test of the three buffer mechanisms, users follow a similar mobility pattern(moving towards and forwards). Particularly, in our proposed solution we maintain a window of 100 consecutive accelerometer readings with an interval of 10ms and if a user movement is detected, we will start to record 5 RSSI readings with an interval of 500ms.
We first test our application under a good connection where the bandwidth on the router is 6MB from service provider. Fig. 7.4a plots the values of C BS i − C P S i which indicate ∆ t by the number of zeros on the x-axis. From the figure, we can observe that all three buffer mechanisms perform well with no stalling (∆ t = 0).  decreases because during this period, the algorithm detects that the user is about to leave the transmission range, and then it allows the player to increase the buffer size in order to prefetch more data. Furthermore, the redundancy rate at the 10th second for DAB, FF and Max, R 10 are 50.7Kb/s, 87.3Kb/s and 206.4Kb/s, respectively. Our solution reduces 33.4% redundancy rate during these 10 seconds. Therefore, in this scenario with a good link connection, our solution DAB can deliver perfect quality of service to user(∆ t = 0), at the meantime, we achieve high efficiency E at beginning of the video which can help user save bandwidth and reduce traffic load at the server side.
Since most users suffer from slow network connection, we also test our application with a maximum downloading speed 200Kb/s. playback. The total stalling duration (∆ t ) for DAB, FF and Max in this scenario are, 4, 12, and 3.5 seconds, respectively. Particularly, FF mechanism stalls 5 times, for 5.5s, 1s, 0.5s, 2s and 3s each time. While DAB and Max mechanism only stalls once for 4s, 3.5s. In this case, our DAB solution and Max perform similarly and much better than FF mechanism. However, considering the average redundancy rate from time 0 to 25, comparing to Max mechanism, our solution DAB reduces it by 59.7%.  The adjusted buffer size does not limit the actual bytes in the buffer. However, from 80-th to 100-th second, the calculated buffer size helps the user reduce buffer size and improve the efficiency.

Conclusion
This chapter presents DAB, a dynamic buffer-control scheme that adaptively adjusts the video buffer size based on the measurement of RSSI and accelerometer. Our solution predicts the change of link quality and correspondingly changes the buffer size to help maintain a smooth playback while minimizing the bandwidth consumption. The experimental results have shown that our solution is superior to typical buffer schemes. orems and proofs, on the message reception probability for parameter optimization.
Additionally, a two-stage protocol guarantees the information to be received by every user in the system. Based on PASA communication model, a mobile message board application has been proposed in Chapter 4 for smartphone users to post and share information within a certain area. We develop algorithms to choose the best message host combinations and maximize the activation rate for each messages.
The second half of the dissertation investigates the other two representative mobile services, cloud-storage services and real-time video streaming services. Skyfiles is introduced in Chapter 5, which focuses on enriching the file operations for cloudstorage services, such as Dropbox and iCloud. It utilizes a cloud instance to assist the advance operations on the files. The direct interactions between cloud instance and cloud-storage service providers significantly reduce the amount of data transmissions on mobile users. To improve real-time video streaming services, we present DAB in Chapter 6. The DAB application takes mobility and signal strength into consideration and dynamically adjusts the buffer size to avoid unnecessary bandwidth cost.

Future Work
The research in this dissertation can be extended in several directions: • In Chapter 2, we present LAAR, which introduces a new long-range radio to smartphones. Through taking advantages of the new hardware, LAAR dramatically boosts the system performance of the Ad-Hoc networks. It would be interesting to adopt the system design to the drone networks, which is another emerging research area with open challenges. • Chapter 5 focuses on the cloud-storage services. Skyfies application uses a cloud instance to provide advance file operations. However, cloud instance has more capabilities than file operations. It can be extended to empower mobile devices by offloading computational-intensive tasks to cloud instance, such as picture stitching tasks for virtual reality and augmented reality.
• DAB is presented in Chapter 6 to dynamically adjust the buffer size for realtime video streaming services. The evaluation in this work only focuses on the user side. However, the design of DAB can also benefit the server side. It could be another direction to investigate the impact of the buffer mechanisms at the server side and develop the algorithms to reduce the server load.