An Opportunistic Data Backup System for Mobile Ad Hoc Networks · To bridge this gap, we propose a...

An Opportunistic Data Backup System for Mobile Ad HocNetworks∗

Roy Friedman David SainzComputer Science Department

TechnionHaifa 32000, Israel

{roy,dsainz}@cs.technion.ac.il

Aline Carneiro VianaINRIA Saclay - Ile de France

[email protected]

May 29, 2012

Abstract

This report describes the design and implementation of an opportunistic data backup system formobile phones. It enables backing up files in devices that are encountered on a regular basis. Thedesign of the system is modular, and includes mechanisms for detecting and identifying regular wirelessencounters as well as file accesses. Based on these, the system decides which file should be replicatedand to which other devices. The system also includes a recovery mechanism that enables restoring amissing file as well as the entire set of files, e.g., in case the device’s storage unit got damaged, orthe phone was destroyed or got stolen. The work is calibrated and validated using publicly availableencounter traces.

1 Introduction

Mobile phones are quickly becoming the most prevalent computing and communication devices. As the ca-pabilities of mobile phones improve as well as our reliance on them, backing up the data stored on the phonebecomes vital. Evidently, a growing number of people use cloud storage backup services like Dropbox. Yet,such cloud based backup requires reliable high bandwidth connectivity to the Internet. This assumption,however, in not practical in many places. Specifically, in many developed countries cellular operators do nothave the capacity needed to support the bandwidth that they promise to all users [1, 2]. Moreover, in manydeveloping countries mobile phones enjoy extremely high penetration rates, while broadband Internet accessis very scarce, and the situation is not likely to change dramatically in the near future. As an example, inSeptember 2011 it was reported that the penetration rates of mobile phones in Africa as a whole was above65%, increasing almost 20% each year for the past five years [3]. Yet, the country with the highest rate ofbroadband access is South Africa with 6%, followed by Morocco at 2.5%.1

To bridge this gap, we propose a modular opportunistic mobile ad-hoc storage system. The main goalof such an opportunistic replication system is to provide secure backup storage of personal files of usersin mobile devices of other users that are encountered with regularity. The idea is to exploit the inherent

∗This work was partially supported by ISF grant 1247/091The total number of Internet users is higher, thanks to Internet Cafes and low bandwidth connections, but even with these it is

still well below 15% is most African countries.

1

Technion - Computer Science Department - Technical Report CS-2012-05 - 2012

encounter behavior of user mobility and to leverage on it. In particular, it is well known that the movementof humans is not random and it is a manifestation of their behavior and intentions [4, 5]. The design ofour backup service is inspired by such studies about the characteristics of users movement along with thecorresponding contact-based interactions among users.

Our backup storage process mainly targets personal files, as such files are usually the most importantones to a user, and also tolerate some recovery delay. Files are replicated and transferred directly betweenwireless devices carried by users in an opportunistic ad hoc fashion and during their daily activities, withoutany assumption about pre-existing infrastructures. That way, in the event of files loss, these files can beretrieved back from pairwise frequently encountered devices that store their replicas. This is both for asingle file as well as loss of the entire device’s storage system, e.g., due to hardware failure, loss of thephysical device, etc.

The replication process needs to find a good balance between placing enough replicas of the files so theycan be easily retrieved when needed, and avoiding the saturation of the storage space in the devices whilealso avoiding clogging the network. To that end, our system includes a novel File Assignment protocolthat decides on replicas placement based on the access pattern of a given file as well as on the frequencyand dependability of the encounters with various users’ devices. The architecture of our system and itsbasic interaction are explained in Section 3 and the file assignment protocol is presented in Section 4. Asdescribed in Section 5, we study the behavior of the protocol and calibrate its parameters by performingsimulations that feed publicly available real-world encounters traces: from the MIT Reality Mining project[6] and the Dartmouth College [7] traces.

The protocol for identifying which files need to be replicated and when, as well as the retrieval of lostfiles and recovery from a complete system crash appear in Section 6. These are partially based on a fieldtest we have conducted.

Finally, we have evaluated our entire system, currently implemented for the Android OS, by a simulatorthat feeds the real-world encounter traces mentioned before into the real code. As reported in Section 7, thevast majority of the nodes are able to replicate and retrieve their files within a reasonable delay. In particular,nodes that fail to do so are almost entirely secluded nodes, which seldom meet others. In contrast, “sociallyactive” users can always retrieve their files.

2 Related Work

A recent trend is to implement storage as an Internet/cloud service. Such a service is offered by a collectionof servers. Typically, user data is automatically transferred back and forth to the cloud storage service, whichguarantees its distribution over the cloud servers. Examples of cloud storage systems include: DropBox [8],SkyDrive [9], or Amazon S3 [10]. They provide large amounts of storage space, but they require broadbandInternet connection, whereas our system does not.

P2P storage is another viable and attractive alternative to both traditional storage methods as well ascloud storage services. Contrary to the latter, P2P storage systems typically depend on group membersthat are part of a peer network to trade local resources (disk space, network bandwidth) for data storage,using P2P technologies [11, 12, 13]. In some P2P storage approaches, peer selection is based on social linksbetween people: a group of friends, family, or colleagues decide to setup a peer network and use each other’sresources. Yet, P2P storage also requires fast Internet connectivity.

[14] and [15] propose replicating personal files in Personal Clouds, which are formed by the devicessurrounding a user. The replicas can be stored in some of the devices of the Personal Cloud, but thereis no particular selection (e.g., frequently encountered, stable contacts, etc.) of any device from the user.

2


In particular, similar to our system, in [15], pairwise connectivity that naturally occurs among the devices(e.g., via Wi-fi, Bluetooth or USB) is exploited. Nevertheless, once such household devices are identified(devices that are periodically wirelessly connected due to common work or home locations), data replicationis performed via a broadband connection through the Internet.

Some distributed file systems that supports disconnected operation include, e.g., Coda [16], Ficus [17],BlueFS [18], and Bayou [19]. Such file systems also embed file replication functionalities. However, theirmain purpose is to offer replication as a means to increase availability in shared accesses. Instead, oursystem replicates data for durability and takes advantage of pairwise encounters.

Hara [20] and Bellavista et al. [21] propose several techniques for replica allocation in mobile devices,but the approach is different from the replication perspective taken by us. In [20] and [21] the allocationtechniques focus on locating data items in a way that is best accessible by all interested participants.

Soriano et al. [22] propose replication techniques for mobile ad-hoc networks, also from the perspectiveof shared objects and general availability improvement.

As we deal with intermittently connected devices, our system can be seen as a user-aided service fordelay tolerant networks (DTNs). Opportunistic networking and measurement of various aspects of humansociety have been previously combined to provide networking services for DTNs. Such services range frommulti-hop forwarding [23, 24] to data offloading [25], where opportunistic communication is used to routedata to destinations or to alleviate data traffic in cellular networks. Instead, our system provides a distributed,robust, and free storage service for these environments.

Community detection research focus on algorithms that process a general connectivity network in acentralized way [26] [27] or in a distributed manner, where each node infers its own community. Hui et al.[28] propose 3 algorithms for distributed community detection, some of which use the notions of JaccardIndex [29] and Ego-Centrality [30]. However, our approach is purely centered in the node’s ego-network.In our system, the nodes do not need to know information about other nodes’ communities. Our work alsoallows the creation of several communities for a single node, computed in a distributed way.

3 Solution Overview

Our system is modular, based primarily on three modules plus a group communication framework, as illus-trated in Figure 1. Any of the modules can be substituted or expanded in order to adapt them to differentprotocols and communication mechanisms. The group communication framework provides reliable groupmulticast and unicast communication as well as a discovery mechanism capable of detecting the arrival anddeparture of nodes in the area. This communication module is in charge of passing node discovery events tothe system, as well as transferring the files and messages to other nodes.

Next, is the File Exchange module. It is in charge of the file management and transportation. It splitsfiles into chunks (if needed due to their large size), and uses the Communication Module to send them toother peers. When receiving files, this module can reassemble chunks back into a file, or simply store themas backup for other peers.

The File Assignment module selects the best candidates to replicate data on. For this, we take advantageof the inherent cycled mobility (i.e., regular visited locations and encountered nodes) of each user and itscorresponding connectivity pattern, and transform some of these repeated encounters into backing up nodesfor the user. As stated in [4], human behavior tends to have a spatio-temporal pattern, repeating locations andtimes of day and showing some degree of regularity. Therefore, our system analyzes the daily encountersof each user in order to identify regularly encountered and suitable backup nodes. From mobility patternsand wireless interactions of users, we establish an undirected encounters graph G(V,E) representing the

3


Figure 1: System Architecture

connectivity network of users, where V is the set of encountered nodes and E is the set of ties among them.The core of our work revolves around how to create and maintain E, as elaborated in Section 4. Since theFile Assignment module monitors discoveries and departures of nodes, it can also notify the File Monitorwhen a specified node is discovered, and can even report a list of nodes that are active (did not leave) at agiven moment.

Inside this module, encountered node is assigned a rating number, named replication confidence, whichindicates how trustworthy that node is in terms of safely keeping and retrieving data. This metric is used bythe File Assignment module to select the candidates for replication. The calculation method of this metricand the mechanism to infer the encounters graph itself are explained in the next section.

The File Monitor controls the replication itself. As its name suggests, it monitors the use of the filesin the device in order to know which files to replicate and when. The module keeps track of the creationand deletion of files, as well as their modifications. When it deems necessary (normally when a certaintime has passed since the last modification, or a number of modifications), the File Monitor selects a filefor replication and accesses the File Assignment module to get a list of the best candidates for storing thebackups. If the file is large, multiple nodes are requested to accommodate all its chunks. The chunks aretypically shared in a Round Robin fashion among the nodes. If some nodes fail to replicate, then those nodesare skipped. The File Exchange module returns to the File Monitor module information about which nodeaccepted which chunk. Upon an unsuccessful replication, the File Monitor will attempt to replicate againusing a different node.

The File Monitor keeps track of which nodes have a replica of each file, and each time a file is success-fully replicated, this information is updated. Whenever a file is lost in the file system, the system marks itas pending and starts the recovery process for that file. It asks the File Assignment module for the currentlyonline nodes, and if any file chunk is stored in any online node, then the File Monitor sends a request tothe File Exchange module to retrieve it. When all chunks are recovered, the file is put together. However,it may happen that not all chunks are accessible, in which case the File Monitor sends a request to the File

4


Assignment module with the list of nodes that have the chunks that were not retrieved. The File Assignmentmodule will then send an event back to the File Monitor once any of these nodes appears nearby. Afterthis event, the File Monitor will contact the File Exchange module again to keep recovering the rest of thechunks. Once the file is successfully recovered, the File Monitor will inform the File Assignment module tostop sending the events previously described.

To protect users’ files and privacy, our system encrypts the files or chunks using standard cryptographictechniques [31].

The following sections further describe the File Assignment and File Monitor modules, as they imple-ment most of the interesting functionality of the system.

4 The File Assignment Protocol

As previously mentioned, the file assignment protocol generates a list of suitable nodes for replication alongwith their replication confidence. This factor is based on a connectivity network that is discovered byanalyzing node encounters over the lifetime of the system.

In order to make the problem manageable, time is divided into time frames, with a duration of H hours(a parameter) each. The total number of time frames M is given by M = ω × 24

H , where ω is a parameterindicating the number of days in which it is desired to keep track of different time frames. This numberis typically 7 days (a week). These M time frames repeat in cycles, e.g., when a cycle is one week long(ω = 7), the time frame corresponding to Monday morning repeats once a week for the duration of thesystem execution.

We also use the concept of a logical location. Logical locations are a combination of a group of nodesthat meet and the given time frame where they have met. Thus, two different physical locations with thesame group of nodes (e.g. team workers moving from their office to their usual place for the coffee break)will be a single logical location for the system. For the logical locations, the different groups of nodes aremore important than the place where they spend their time together. Within the system, logical locations areautonomously tracked at each node. The shift from one logical location to another is also monitored by oursystem.

Calculating logical locations enables nodes to identify the set of nodes that appear regularly in a giventime frame. Nodes seen more often in different logical locations are more accessible than nodes seen onlyduring a single time frame. These logical locations are also a way of clustering different groups of peoplethat meet over time. Files can be thus replicated in each logical location, thereby raising the availabilityof the file at any given moment of the day. The goal is to balance between the desire to replicate a file asmuch as possible for higher availability and the need to avoid saturating the storage space and network byover-replicating.

In the rest of this section, we elaborate on the building blocks for realizing the encounters-based replicaassignment protocol and how they fit in the file assignment protocol.

4.1 Building the encounters graph

Representing the groups of nodes encountered by each user is done by calculating an encounters graphGk(V k, Ek) with the different nodes the user k encounters. Hence, the set V k contains all nodes encoun-tered by the user k throughout the system’s execution, and Ek is the set of links between them.

In order to figure out the logical locations, it is necessary to know which nodes are met by a user at eachtime frame. Hence, the File Assignment protocol also builds per user k a network for each time frame j,

5


Node:Id: NumberTime: Number\\number of contactsNContacts: Number\\time persistenceTPersistence: NumberFamiliarity: Number\\node replication confidenceRFactor: Number

\\all spotted nodesAllNodes: Vector\\one vector of nodes per time frameNodesFrame[]: Vector of Vectors\\one community per time frameCommunitiesFrame[]: Vector of Vectors

Upon detecting contact with node N:if(N ∈ AllNodes)

AllNodes + {N};if(N ∈ NodesFrame[ currentTimeFrame])

NodesFrame[currentTimeFrame]+{N};N.numberContacts ++;

Time event indicates the arrival of a new time frame:foreach Node N in NodesFrame[lastTimeFrame] begin

N.Time += Time of contact;if( N ∈ NodesFrame[now])

NewNode: Node;NewNode.id = N.id;NodesFrame[now]+{NewNode};NewNode.NContacts ++;

elseOldNode = getNode(N.id, NodesFrame[now]);OldNode.NContacts++;

end ifend foreachcalculateCommunity(lastTimeFrame);

Node N leaves:N.Time += Time of contact;

Time for community analysis arrives:foreach integer frame in timeFrames begin

if (calculateOverlap(CommunitiesFrame[frame],CommunitiesFrame[nextFrame]) ≥ ε)Merge Communities;Merge Time Frames;

end ifend foreach

Figure 2: Events pseudocode for node eligibility

6


\\File Monitor requests a node list for\\data replication in current time frame:getCandidates()begin\\List of candidatescandidates: Vector;\\Global time persistencecalculateTimePersistence();foreach Node N in CommunitiesFrame[now] begin

newNode = GetNode (N.id, AllNodes);newNode.Familiarity = newNode.TPersistence*TFramesFound(newNode);newNode.Rfactor = (newNode.Familiarity)/(cent(newNode));candidates = candidates + {newNode};

end foreachOrder candidates by means of a Russian roulette using a probabilitydistribution based on the replication confidenceorderedCandidates = russianRoulette(candidates);return orderedCandidates;

end

Figure 3: Pseudocode of the node eligibility function

creating the graph Gkj (V

kj , E

kj ) where V k

j is the set of nodes encountered by k during time frame j and Ekj

are the links between this user and its encountered nodes. These per-frame encounters graphs Gkj (V

kj , E

kj )

are used to deduce the logical locations, whereas the general weighted encounters graph Gk(V k, Ek) areused to store the replication confidence, which is a general metric rather than a per-frame indicator.

The connectivity network detection is a continuous process since at any time new nodes can be discov-ered and hence added to the graphs. After having enough information about encounters (typically a week,after going through all time frames), the logical locations can be calculated. This is based on first calculatinga metric called time persistence for each node a user encounters in each time frame, as explained below.

4.2 Extracting time persistence (T ki )

Time persistence captures the portion of time a user is in the vicinity of another node Ni in time framej. It is highly valuable for replication, as the more time a user spends with a node, the chances of beingable to access data from it increase. This metric T k

ij is calculated for each node i in each time frame j,with respect to a user k. Time persistence is the combination of contact duration and contact frequencywith a node i. Duration (Dk

ij) is a proportion of time in which there has been direct contact of user k withnode i in time frame j. Frequency (F k

ij) is the number of cycles in which node i has been present in timeframe j, relative to the number of cycles the user k has been present in that time frame. Duration andfrequency are parameterized with different weights α and β to give different importance to each of them:T kij = α ×Dk

ij + β × F kij , for Dk

ij = seenk(i,j)

Okij

and F kij = presentk(i,j)

Pkij

, where α + β = 1, 0 ≤ Dij ≤1, 0 ≤ Fij ≤ 1.

The function seenk(i, j) is the amount of contact time of user k with node i for time frame j. Note thatwhen this contact takes place again at the same time frame j in a different cycle (e.g., in the next Mondayfrom 8am to 12pm if ω = 7 days and H = 4 hours), this value keeps accumulating. Ok

ij is the total timein which the user k has been active in time frame j since the first encounter with node i. The functionpresentk(i, j) is the number of cycles node i met user k in time frame j (e.g., presentk(i, j) = 4 ifthey met every Monday from 8am to 12pm during a month, for ω = 7 days and H = 4 hours). This amount

7


of time accumulates whenever time frame j takes place again in a new cycle. P kij is the number of cycles in

which the user k was present in time frame j since the first encounter with node i.This per-frame and per-user time persistence is relative to a node i inside the graph of a time frame. The

global time persistence T ki for a node i in the general graph Gk(V k, Ek) is calculated by T k

i =∑M

j=1 Tkij

M ,where M is the current number of time frames given in Section 4.

Frequency and contact duration are dynamic, since they are relative to the total amount of time spentactive by the user. It means that they change over time if there is a change in the contact behavior with nodeNi in time frame j. For example, high values of frequency and duration at a given time frame would bereduced to near zero if contact with node Ni stops in the time frame j (either Ni or the user stop appearingat time frame j). Thus, the global metric Ti will be consequently reduced.

4.3 Extracting logical persistence (Lki )

Calculating logical locations is performed by an iterative process. It starts by assuming a different logicallocation in each of the M time frames. The process then tries to extract per user k and time frame j acommunity Ck

j from the graph Gkj (V

kj , E

kj ). This community consists of the group of nodes that in time

frame j have a regular and consistent encounter pattern with the user k. This groups is determined as thenodes whose time persistence T k

i surpasses a given threshold ρ.Note that the goal of using time persistence for accepting a node into a community Ck

j of a time framej is to identify the nodes that are consistently met by the user during that time frame, thus discarding shortand random encounters.

The communities, as described so far, are created under the assumption that each H hours there wouldbe a potentially different community to belong to. In reality, it is expected that the different communitiesexpand through several time frames (the nodes around a user can still be the same at time frames i and i+1),causing community overlap. Therefore, the next step is trying to identify overlaps between communities andif this overlap is significant, merge such overlapping communities into one. In order to calculate the overlapbetween communities Ck

1 and Ck2 , the Jaccard Index [29] is used: |Ck

1

∩Ck

2 ||Ck

1

∪Ck

2 |≥ ε, where ε is a merging

threshold that parameterizes the level of acceptance of different nodes in different time frames. Once themerging process occurs, the time frames also merge, covering the time span of both communities; thecorresponding encounters graphs are also merged and nodes’ time persistence is recalculated as well.

Notice that the communities that are checked for overlap do not have to be adjacent in time. This has thepurpose of detecting logical locations that are not continuous over time (for example, users can stay at homesurrounded by family during the morning and then again at night). Merges cease once the overlap betweencommunities becomes marginal.

Once communities are calculated and merged, each of them is considered a separate logical location.The location persistence Lk

i is then computed, which counts the number of logical locations in which theuser k has encountered node i. This metric adds information about whether or not a node will be encounteredin multiple logical locations. This is different from the concept of frequency F k

ij since frequency counts thenumber of cycles a node is seen within the same time frame.

The process is repeated periodically, typically at the end of each M frames cycle time period, in orderto adapt to changes and adjust the logical locations and communities accordingly.

8


calculateCommunity(timeframe)begin

CommunitiesFrame[timeframe] = ∅;foreach Node N in NodesFrame[timeframe] begin

N.TPersistence = α N.TimeTimeOnline

+ βN.NContactsDaysOnline

;if (N.TPersistence ≥ ρ)

CommunitiesFrame[timeframe]+{N};end if

end foreachend

calculateOverlap(communityX, communityY)begin

return |communityX∩

communityY ||communityX

∪communityY | ;

end

calculateTimePersistence()begin

foreach Node N in AllNodes beginN.TPersistence = 0;foreach integer frame in timeFrames begin

if(N ∈ NodesFrame[frame])OldNode = GetNode (N.id, NodesFrame[frame]);N.TPersistence += OldNode.TPersistence;

end ifend foreachN.TPersistence = N.TPersistence/NumTimeFrames;

end foreachend

Figure 4: Code of the functions for node eligibility

4.4 Calculating the replication confidence RCk(i)

All nodes belonging to the current logical location of the user are plausible candidates for replicating theuser’s files. Yet, at hinted before, the replication confidence helps rank among them. It is the mixture of twodifferent metrics that are also calculated: familiarity and ego-centrality.

Familiarity: Famk(i) of a node captures how commonly a significant contact between user k and nodei occurs. It is calculated by Famk(i) = T k

i × Lki , where T k

i and Lki are the time persistence and location

persistence defined above.

Ego-Centrality [30]: Cenk(i) captures the betweenness centrality [32] of a node i with respect to theuser k calculated from the ego-network [33] (formed by the node itself, its direct neighbors, and all the linksbetween them). Betweenness centrality measures the number of shortest paths that includes a given node,indicating how central for other nodes it is. Intuitively, nodes with high betweenness centrality eventuallyacquire more single-hop neighbors. It is known from complex network studies [34] that nodes become 1-hopneighbors more often with those who have more common links with their current neighbors. Further, highbetweenness centrality implies that the node is in the data paths of many nodes. Hence, highly central nodesare usually busy and popular candidates. This can be a bad thing for replication, as both the storage andbandwidth of these nodes are likely to be overloaded. Consequently, we lower the replication confidenceof nodes with high ego-centrality. To calculate this metric from the encounters graph, a binary association

9


Data set Dartmouth MITConsidered period Jan.-Mar. 2004 Oct.-Nov. 2004Resulting active nb. of nodes 2,648 92Wireless interface WiFi Bluetooth

Table 1: Details on the considered information of each data set.

matrix A that captures only directly encountered nodes is used. This centrality is a global metric that does nottake into account logical locations, so the graph Gk(V k, Ek) is used for this calculation. The betweennesscentrality Cenk(i) of a node i with respect to the user k is calculated by the sum of the reciprocals of theentries of A2[1−A][30].

Thus, we set:RCk(i) =

{Famk(i)

Cenk(i)if Cenk(i) > 0

Famk(i) otherwise.(1)

As mentioned before, it is desirable to replicate each piece of data in each of the calculated logicallocations, selecting one or more members in each of them for the replication. Hence, the list of candidatesis based on the current logical location, giving only a list of nodes that are active and present in it.

5 Parameters Tunning

In order to tune the mechanisms introduced above, we have simulated their behavior under different sets ofparameters and by feeding two real world data-sets into a real Java implementation. At the following, theconsidered real world data-sets describing user encounters in different network campus environments areintroduced. We then describe the used parameter sets and discuss the obtained results.

5.1 Data sets

The data sets include traces of students and staff mobility in a campus: at Dartmouth College [7] and at MIT(collected for the Reality Mining Project) [6]. These traces provide information about nodes’ encounters aswell as their date, time, and encounter duration. This is used by the simulator to build a flow of discovery anddeparture events with appropriate order and timing. Those events are fed to the system through the discoverymechanism interface, so the system can automatically build the encounters graphs while keeping track of thetime frames. The simulator advances its own internal time as new time stamps of events arrive, managingthe time frames accordingly. Table 5.1 lists the considered duration of the data sets and the correspondingnumber of active nodes.

Dartmouth Dartmouth includes SNMP logs from the WiFi access points across the Dartmouth Collegecampus from April 2001 to June 2004. To generate user-to-user wireless contacts from the data set, weconsidered 2 months of measurements and follow the popular consideration in the literature that devicesassociated to the same AP at the same time are assumed to be in contact [35]. The traces cover a largeamount of nodes from which we discarded the ones of negligible appearance during the chosen time period.Discarding the nodes that appear 1000 times or less during the chosen months, we ended up with 2,648nodes. This may appear to be very drastic, yet a closer examination of the traces shows that this is quitereasonable. The encounter duration follows a power law distribution. Most of the contacts have a durationof a few seconds. Hence, a trace between node Ni and Nn may appear dozens of times within a single hour.

10


Figure 5: Dartmouth accumulated contact duration

Figure 5 shows the accumulated contact duration percentage of the Dartmouth traces. The x axis representsdifferent contact durations and the y axis represents the accumulated percentage of traces of that duration.As can be seen, 50 percent of the traces last up to 30 seconds. For such contact duration, there can be 2880contacts between Ni and Nn in a single day.

MIT These traces include Bluetooth encounters of phones, phone calls and cell tower information. Wechose the Bluetooth encounters since we believe that due to their shorter coverage range, they depict encoun-ters more accurately than cell tower information or any other information in the data set. For the study, wechose a time period of 2 months, from October to November. The data set is made with traces of 97 users,92 of which are present in the chosen period of time, but given that they encounter also external Bluetoothphones, the total amount of nodes in the time period is 2890.

5.2 Simulator setup

Several simulations have been performed with variations of the parameters described in section 4. We havefixed ω to be 7, corresponding to a one week period. The weights α and β, which calibrate the values ofT kij for time persistence (see Section 4.2), are set to α = 0.8 and β = 0.2. These weights were deemed

appropriate empirically. Different values either make β too small to have an impact in the equation, or toobig, since it controls the frequency Fij and this number can easily be equal to 1, hence it needs to have asmaller impact than Dij .

The value of ρ becomes more permissive as it approaches 0 (accept anyone no matter their locationpersistence) and more strict as it approaches 1 (accept only those who the user has seen 100 percent of theonline time in the time frame). It has been measured from 0.1 to 0.8 in increments of 0.1. Values below 0.1,or even 0.1 may be too permissive, as it would mean accepting in the logical locations people that do nothave enough consistent contact with the ego-node. They would therefore be fickle and not reliable enough.High values over 0.8 would accept only nodes that are almost constantly in contact with the ego-node in alltime frames.

The value of ε indicates how much overlapping is required in order to merge 2 logical locations. Valuesvery close to 0 merge any location and values close to 1 will merge locations only if they contain exactly thesame nodes. This parameter has been measured with the values 0.2, 0.4 and 0.6.

11


Parameter name Definition Simulated values Selected valuesH Time frame (TF) duration in hours 4 and 6 6ω Number of days 7 (a week) 7α Calibration of contact duration 0.8 0.8β Calibration of contact frequency 0.2 0.2ρ Time persistence threshold from 0.1 to 0.8 in increments of 0.1 0.4 (for Dartmouth) and 0.2 (for MIT)ε Merging threshold 0.2, 0.4 and 0.6 0.5 (for Dartmouth) and 0.6 (for MIT)l Replication level 2 and 3 2 and 3

Table 2: Simulation Parameters

(a) H=4 hours, MIT (b) H=6 hours, MIT

(c) H=4 hours, Dartmouth (d) H=6 hours, Dartmouth

Figure 6: Evolution of the logical location number over time

5.3 Simulation outcomes

During the simulations, we have observed that while smaller time frames result in a higher number of logicallocations, the behavior and evolution over time is the same in all traces for both durations. Figure 6 showsthe average number of logical locations over the simulation time for different values of ε. The flat part ofthe lines corresponds to the period of the simulations where no merges have taken place yet.

We have also collected information about the average number of logical locations that have at least onemember (that is, logical locations where there is significant contact with nodes in order to send replicas). Werefer to those logical locations as significant. Figure 7 shows the average logical location number for MITand Dartmouth, while varying the values of the variables that may affect the number of logical locations (εand ρ). As can be seen, the difference between a duration of 4 hours and 6 hours is very small. Thus, for therest of the paper we set H = 6 hours.

The size of logical locations is depicted in Figure 8. It shows how size becomes much smaller as ρ

12


(a) (b)

Figure 7: Average number of significant logical locations, with different values of parameters, for the Dart-mouth and MIT traces

becomes more strict. For Dartmouth, it appears that values of ρ between 0.4 or 0.5 obtain a good balancebalance between the logical location size and the predictability in which nodes appear in it.

On the other hand, for the MIT traces, there is not a big affluence of nodes met, and the size shrinksrapidly. The parameter ρ = 0.2 seems to be the most appropriate. As previously mentioned, a value ofρ = 0.1 is deemed in the limit of permissiveness, whereas ρ = 0.3 starts having a small number of nodes.The simulation for MIT is more sensitive to ρ, since it is formed by contacts that are not as continuous asin Dartmouth. Both size and number of locations decrease faster, since the time during which nodes are leftinside a time frame is smaller, and restrictive values quickly shuffle away nodes from the logical locations.

To summarize, it can be observed as well that for middle to high values of ε, the number of logicallocations is smaller for MIT, and it does not diverge too much from the result of the other MIT simulationsfor different values of ε. It suggests that being too strict on ε does not affect much the encounters graph.Nodes seem to mingle in a less heterogeneous fashion in terms of appearances in different time frames: εseems to typically reach high values, so diminishing its threshold does not result in a much different numberof logical locations. For less heterogeneous traces like MIT, small values of ρ seem to be appropriate,whereas the value of ε, seems to have a moderate impact. In the Dartmouth traces, increasing ε resultsin more logical locations, although the size of such locations will diminish, as seen in figure 8. Values ofε = 0.4 or ε = 0.5 are deemed to attain a good balance, having enough nodes inside logical locations, whilealso keeping the number of logical locations large enough.

6 File Replication and Recovery

The File Monitor uses both the File Assignment and the File Exchange modules in order to coordinate filereplication and recovery (Figure 1). To facilitate these activities, the File Monitor needs to be constantlyaware of the status of the file system, and also needs to be able to choose which files to replicate and whenthey should be replicated. These decisions are based on an analysis of file accesses that we have obtainedfrom a field test with users and their mobile devices. In this experiment, we have acquired real traces ofaccesses to files from the participants’ mobile phones.

13


(a) (b)

Figure 8: Average size of logical locations

File type Number of files avg # file per userApplication specific 2879 719Images 1773 443Audio 246 61.5PDF 1 0.2

Table 3: File types in the file access traces

6.1 Analyzing file access patterns

The test for the file access analysis is based on 5 Android users from 4 countries (Israel, Spain, UnitedKingdom and France) and collects all their file accesses during a period of 15 days2. We have written anapplication that monitors all changes made to the file system and registers them into an internal database.The application was installed in the users’ phones and was run in the background during the total period.All file paths were hashed in order to protect the users’ privacy. This hash added a salt made with unique idnumbers of their personal devices to make it stronger. However, the file extension was left in clear text, inorder to be able to categorize file accesses by file type.

With every change in the file system, the application registered a new trace, adding the hashed file path,the size of the file, the time stamp of the change and its type (creation, deletion, modification and access).With that information, we analyzed the type of files that users access the most on their mobile device, alongwith the frequency of use.

The traces collect access information of a total of 4899 files. Table 3 shows the different file types found.Most of the traces belong to application-specific types, and the rest of the files belong to media, either audioor image types. The traces have only collected one PDF file.

The average size of the files is 1.69MB, suggesting that the files stored in phones are typically small.Large videos files were not found; maybe all significant video is streamed. This seems to confirm theviability of a opportunistic backup system for phones. Having relatively small files enables keeping multiplereplicas without storage saturation.

We have also analyzed files with respect to their access and modification pattern. Table 4 shows themodification and access lifespan for the different kinds of files found. This modification and access lifespan

2Additional users are currently running our collection software.

14


AVG modification AVG accessFile type % of files modified lifespan lifespanApplication specific 95% 10.96 hours 22.43 hoursImages 40% 21.79 hours 322.8 hoursAudio 4% 0.02 hours 343.68 hours

Table 4: File access and modification lifespan.

represent the amount of time after the creation of the file (or the first trace registered of it) in which there havebeen modifications or accesses, respectively. The table also shows how many files of that type registeredmodifications in the traces after creation. As can be seen, audio and image files are accessed during the entireperiod, but they are modified only during the first hours. Less than half of the images incurred modifications,and a very low percentage of audio files were changed. For images, this modification lifespan may also bealtered by the behavior of specific programs. We have registered some modification events to image files themoment the image gallery applications open them, possibly accessing them in order to create the thumbnailfile. This could mean that users may copy pictures or take them with the cameras of their devices, and lateropen them for the first time in the image galleries, 21.79 hours later on average. Notice that applicationspecific files have a high rate of modification, but usually they are modified only during the first hours aftercreation. The access lifespan is however very short.

6.2 Exploring File Candidates for Replication

Inside the system, a process called file scan identifies files that need replication by listening to differentfile system events. Every time a change is made in a file inside the device (e.g., creation, deletion, accessor modification), this process receives an event, and registers that change inside its internal database. Theevents of creation and deletion of files are used to keep track of the currently existing files in the storage.

Upon the arrival of an event, the file scan registers the change in the file system, and analyzes theparticular file related to the event, determining whether or not to mark it for replication. This assessmentis based on the analyzed file usage patterns described in the previous section. It usually implies looking atthe size and extension of the file and classifying it into two main categories: files that are not likely to bemodified again, and files that may be modified several times after being created. The former category is safeto replicate as soon as it is detected, so those files are marked for replication inside the internal database. Forthe latter category, the modification events are closely followed. The files that were modified at least one dayago, are marked again for replication, in order to store the recent modifications. Modifications during onesingle day are taken into account, but without reacting immediately, as several “hot” files might be modifiedseveral times (e.g., a text file saved several times during a day) and therefore need some time to stabilize. Ifa file is modified every day and never reaches a stable status, it is marked for replication once a day.

6.3 Replication

Replication of marked files is performed by the file replicator process. This process tries to replicate eachmarked file in every significant logical location. The number of replicas of each file or chunk in each logicallocation is controlled by the replication level parameter, named l.

File replication is mainly triggered upon changing the current logical location. It keeps an internaldatabase of how each file was replicated: in which logical locations and to which replication level. Uponthe arrival of a new logical location, the process extracts from the internal database information about the

15


Name Description TriggeredIndex file File containing a backup of the internal database. -File polling Polling mechanism to ensure a replica still exists in a

node.Time scheduled.

Time to deletion θ Time threshold after which, if no polling has been re-ceived, a replica of some other node is deleted.

-

Replication level Amount of copies of a replica in a logical location. -Tracking request Order given to the File Assignment module to give a

notification when a node becomes active.-

Global recovery request Request to neighbors to give information about thereplicas of the ego-node that they have stored.

-

Sticky request Electronic sticky note left in neighbors in order to re-trieve the index file when it is lost.

-

Sticky request holder A node holding a sticky request of somebody else. -File Scan process Process that identifies files suitable for replication. Upon receiving a file system event, and time

scheduled in order to periodically assess themodification times of files.

File Replicator process Replicates files that the file scan process has markedfor replication.

When the current logical location changes.

Control routine Checks that all files registered in the internal databaseexist in the storage.

Time scheduled.

Recovery process Retrieves lost files. Triggered by the control routine when fileloss is detected.

Self-recovery Process Retrieves from all encountered neighbors informationabout the replicas of the ego-node’s files (using globalrecovery requests) and stores them back into the inter-nal database.

Triggered when the index file is absent ordamaged, until it is found. Repeated peri-odically (in rounds).

Sticky recovery process Tries to recover the index file by means of publishingelectronic sticky notes (sticky requests).

Activated when the self-recovery processfails to retrieve the index file in the firstround.

Table 5: Main concepts of the File Recovery

16


files that have not reached the desired replication level in that logical location. Then, for each such file, itcalls the File Assignment module for a list of suitable candidates. With that list, the process invokes theFile Exchange module in order to replicate, in a round robin fashion, the file chunks in the candidates. TheFile Exchange returns information about the success of the operation, in which case the replication level isincreased for that particular file in the current logical location, and its replication information is updated inthe database. This process is repeated for each file until reaching the desired replication level. If the filereplication level cannot be achieved in a given time frame, further attempts will be made when the systementers the same time frame on its next cycle.

6.4 Files Lost and Found

Inside the File Monitor, there is a control routine, scheduled periodically, A periodically scheduled controlroutine is implemented, whose role is to ensure that every file in the internal database exists physically inthe file system. If any loss is detected, a recovery process is activated.

Figure 9: Flowchart of the recovery process

Figure 9 shows a flow chart of this process. The recovery process queries the internal database for thenodes where replicas of the missing file have been placed. Then, the File Assignment module is accessedin order to determine which nodes are currently active. With that information, the process contacts the FileExchange module to retrieve the file chunks from the nodes. If all chunks are found and recovered, thefile is reconstructed. However, if a chunk cannot be recovered, e.g., its replicas are currently unavailable,the recovery process contacts the File Assignment module again with a tracking request for the nodes thatare not active and have chunks not yet recovered. The File Assignment module must then notify the FileMonitor whenever these nodes do become active. Once any of these nodes becomes active, the recoveryprocess receives an event from the File Assignment module, and contacts the File Exchange module onceagain to recover more chunks from these nodes. When the file is successfully retrieved, this process contactsthe File Assignment module once more in order to stop tracking nodes.

17


Figure 10: Flowchart of the sticky recovery process

6.5 Expiration date

Obviously, some devices may occasionally disappear (e.g., a person moved away). This may cause a replicato be lost, or having a node storing chunks of files that would never be claimed. To overcome this, a nodeperiodically polls all the neighbors that have replicas of its files. For each replicated chunk, it asks for thevalue of a random byte and contrasts the values with the real file. This action is taken as a means of sanitycheck, but it also serves to notify the queried node that there is still interest in the replica. Whenever areplica is not queried for a period of time θ (usually two weeks), the corresponding chunk is deleted fromits local file system.

6.6 Total system recovery

The discussion so far assumed the existence of a local database. However, this database may also be lost,either due to memory corruption, or when the phone is replaced, damaged, or stolen. In order to preventirrevocable information loss, the internal database is periodically dumped into a file. We refer to this fileas the index file. This file has a predefined unique name and a specific unique id number. Hence, even in

18


case of complete information loss, the system will still be able to know which file id contains the databaseinformation.

If the system detects a damaged, absent or simply unaccessible database, it starts a self-recovery mecha-nism, which includes recovering all possibly lost files along with its own internal database. First, the systemidentifies all surrounding active nodes. To each one of them, it will send a global recovery request to re-trieve information about all the files of the user that the nodes have. This information is added again intothe internal database, so the recovery process can begin. If the self-recovery mechanism manages to recoverthe index file, the internal database is restored up to the point of the last backup, and the normal recoveryprocess continues.

Otherwise, the system starts an additional mechanism called sticky recovery, to accelerate the recoveryof the index file. Similarly to electronic sticky notes [36], the sticky recovery publishes information insidelogical locations. Basically, the sticky recovery mechanism tries to publish a sticky note, or sticky request,with the id of the user and a request to retrieve its lost index file. This note will be placed in neighbors, andwill remain there until the index file is found. The goal is to leave the request in popular neighbors, so whenother nodes contact them, they can receive a notification of a sticky recovery being posted. Popular nodesare likely to be in touch with many other neighbors, and hence notify them of the sticky request, increasingthe chances of recovery.

When a node receives a sticky request, it registers it, becoming a sticky request holder, and starts notify-ing its existence to every node that it discovers. When a node receives a notification about a sticky request,it checks whether it has the referred file. If the file is found, it is sent to the sticky request holder, whichwill in turn deactivate the sticky request. The index file is typically small, so the chance of overloading thestorage of popular nodes with it is small. The sticky request holder send a notification back to the node thatcreated the sticky request as soon as it is detected active in the area, which will in turn retrieve the file. Theremaining sticky requests are then deactivated when the corresponding nodes are found.

When needed, the sticky recovery mechanism is initiated by the system on each entry into a new logicallocation. The sticky request is sent to the most popular nodes. In order to identify them, the centralityCenk(i) of each node i of the user k is analyzed. Notice that while Cenk(i) has a negative impact whenreplicating, for sticky recovery it has a very positive connotation, as nodes that stand on the way of morenodes increase the chances of spreading sticky requests.

7 Replication and Recovery Validation

7.1 The Recovery Simulator

As in the File Assignment simulator described above, the basis of the simulation is the Dartmouth and MITtraces. The recovery simulator wraps around the File Assignment simulator, complementing it to simulatethe whole system working together. The events from the traces are introduced to the discovery interface. Therecovery simulator also uses the File Exchange module to emulate file replications and retrievals. The tracesand their time stamps control and emulate the flow of time inside the system. Figure 11 shows the elementsof the entire recovery simulator. The network is emulated, as there is no real contact or file exchange withother nodes.

As can be seen in Figure 11, the recovery simulator receives directly the information of the traces, andis in charge of collecting the time stamps and advance time and time frames. After processing each trace,it passes it to the File Assignment simulator, which works the same way as described in previous sections.Artificial network latencies and storage access times are also simulated, to cause replication and recovery

19


Figure 11: Elements of the recovery simulator

Data Set Nodes with Full Rep. Nodes with Zero Rep. TotalDartMouth 93 7 100MIT 80 12 92

Table 6: Replicated files.

attempt failures.As a means of comparison, another version of the simulator was built. This simulator spreads out

replicas to randomly chosen nodes in an unplanned manner. Later on, the recovery process is started just asin the original simulator. The goal here is to compare this random replication strategy with our opportunisticstorage system.

7.2 Simulator Setup

We have run the simulator with replication levels of 2 and 3. As mentioned before, this parameter determinesthe availability of a replica in a logical location. We have not experimented with a replication level of 1since regardless of its efficiency, it is not deemed reasonable to rely only on one node for replication. Higherreplication levels are possible, but as our experiments have indicated, do not contribute any noticeableavailability beyond a replication level of 3.

The values of ρ and ε are configured separately for each data set with the values determined in theanalysis of Section 5, that is ρ = 0.4 and ε = 0.5 for Dartmouth, and ρ = 0.2 for MIT. Table 2 details thevalues used. The number of files to replicate and then recover is 10, each of them is formed by a randomnumber of chunks, from 1 to 3. Each chunk has a size of 500KB. There is a waiting time of one week beforethe start of the replication process, and another week between the replication and the start of the recovery.The simulator is run either until the end of the trace events, or until all files are successfully recovered.

20


In the Dartmouth data set, we have chosen the 100 most active nodes. This way, we discard nodeswithout enough activity to build a relevant connectivity network in several logical locations. Since the MITtraces have a set of 92 nodes present in the chosen time period, all of them were selected. As the traces fromMIT are extracted from Bluetooth encounters, and they depend on finding discoverable Bluetooth devicesand Bluetooth itself being active, some nodes do not have enough activity during the time period. Someof them do not appear at all during days, weeks or even a month. Moreover, in general, the hours of daywhere nodes are active are not continuous, and the amount of time present in each time frame can be short.However, ignoring nodes that are not very active in the MIT list would reduce the sample significantly,and this way the MIT simulation can also be used to assess the behavior of the system in the presence ofirregular, non continuous nodes. The recovery rates of non-steady nodes is expected to be low, but it is agood way to examine how the steady nodes react to the presence of fickle neighbors.

The random simulation is run with a replication level of 2 and with a replication level of 3. To strengthenthis simulation, we make sure the replication always succeeds, i.e., all nodes manage to replicate all fileswith the desired replication level.

In the experiments for Index File recovery, the simulator is run twice per node, one time with both theGlobal Recovery requests and the Sticky Recovery and the other with only the Sticky Recovery.

7.3 Simulation outcomes

After the initial period where the list of candidates per logical location is generated per each user’s file andchunks, the replication process starts, and is left running for one week to give enough time for the nodes tohave replicas in all relevant logical locations. Table 6 shows the amount of nodes that managed to replicatefiles in the simulation. The table represents the nodes that replicated files in relevant logical locations,reaching their designated replication level. As can be seen, most nodes manage to replicate all their files.Those that do not attain the replication level, replicate zero files. This effect can happen due to the lackof activity, or irregularity of appearance times of nodes. Having either zero or 100% of replication successsuggests that those nodes with no replication did not have much activity themselves at the time of replicationin the simulation. Figure 12 depicts the total amount of contact time of each node during the simulation, aswell as the contact time during the replication process only. Contact time refers to the total sum of time spentin contact with each node. The figure also shows the amount of files that the node was able to recover. Inthis figure, it can be seen that nodes with little or no contact time (especially during the replication process)do not manage to recover files, whereas nodes with higher contact times achieve a 100% ratio of recovery.The nodes that did not recover files, typically have a very small amount of contact time during replication.It suggests that the recovery fails due to a lack of connectivity during the replication phase. It can as wellbe observed that MIT nodes have a larger number of zero replications, as anticipated. However, the rate ofsuccess is still high, even in the presence of neighbors that do no appear regularly.

Figure 13 shows the average success rate of the recovery (retrieval) of files for the nodes that managedto replicate their files in the Dartmouth and MIT data sets as a function of the simulation time in hours.Each graph has four lines: one representing a simulation with replication level of 2, another with replicationlevel of 3, and another two lines with the random replication simulations, one with replication level of 2and the other with replication level of 3. In the Dartmouth case, our scheme manages to reach 90% of fileretrieval in 13 hours, whereas the best random strategy takes 159 hours (6.6 days) for attaining the sameresults. Moreover, after 5 hours, the retrieval percentage reaches 70%, and after 7 hours it goes up to 80%(Figure 14 shows a detailed view of the curve evolution in the first hours of the simulation). For MIT, onlyafter 82 hours (about 3 days and 10 hours) we get a recovery rate of 60%, and 86 hours (3 days and 14hours) are required to achieve 70% of success. This is due to the previously mentioned general discontinuity

21


(a) MIT traces (b) Dartmouth traces

Figure 12: Distribution of contact time and files recovered amongst nodes.

(a) MIT traces (b) Dartmouth traces

Figure 13: Percentage of recovered files as a function of the simulation time (Rep level 2 and Rep level 3completely overlap).

in the appearance of nodes throughout the hours of the day. Nodes stop appearing for hours in the traces,which results in more empty logical locations, during which it is not possible to retrieve files. For the timeframes in which they appear in the traces, the duration of activity may not be long, leaving a smaller chanceof encountering nodes again at exactly those minutes. However, though taking more time, nodes eventuallyretrieve all their files. Trying to attain good recovery rates at earlier times for discontinuous traces like MITis left for future research.

In all simulations, our scheme greatly outperformed the random strategy. As shown in the graphs, therandom strategy attains significantly lower recovery success rates and also at much later times. Also, forour scheme there is no significant difference between replication levels of 2 and 3 for any of the data sets.It suggests that the system does not need many copies of the replicas in order to perform efficiently, andnetwork and node saturation can be avoided.

Figure 15 shows the recovery times for the Index File per node, where only those nodes who replicatedand retrieved the Index File appear (73 nodes in MIT and 94 in DM). The reason for failing to retrieve theIndex File is the same that prevented file recovery in the previous recovery simulation: being “secluded”. Ascan be seen, the Index File is retrieved typically in less than 4 hours for Dartmouth using the Global Recovery+ Sticky recovery approach. The MIT simulation is slower in retrieving the Index File, as expected. Thefigure also shows how using the Sticky Recovery alone performs worse than using the combined strategy,which suggests that most of the times the file is retrieved thanks to the Global Recovery request. Since thesystem stores replicas in the nodes expected to be directly encountered with regularity, nodes find the Index

22


Figure 14: Detailed view of the Dartmouth recovery success, for the first 40 hours of simulation; X axisreflects hours passed and Y axis shows the average percentage of files recovered (Rep level 2 and Rep level3 completely overlap)

Figure 15: Time to retrieve the Index File using the Sticky Recovery alone and the Sticky Recovery alongwith the Global Recovery.

File directly before the Sticky request holders do. However, the Sticky Recovery is still a very useful tool insituations where nodes cannot afford such an aggressive technique as the Global Recovery, e.g., for batteryreasons.

Figure 16 shows the energy consumption in a file transfer used for replicating a file of 240 kb. The energyhas been measured running the application on 2 real Android phones: Samsung Galaxy S and SamsungGalaxy S2. The section of increased energy consumption corresponds to the file transfer, whereas the partthat measures lower energy corresponds to the portion of time in which the application is running but nofile transfer takes place. The average values of energy for the file transfer are 1241 mW (a consumptionincrement of 603 mW) for Samsung Galaxy S2 and 911 mW (a consumption increment of 776 mW) forSamsung Galaxy S.

8 Summary and Outlook

We have reported on an opportunistic backup storage system for mobile phones, in which files are stored indevices that are encountered on a regular basis. We presented our opportunistic storage system, as well asthe mechanisms and protocols we have developed for it. We have shown using real-world traces, run againstour real implementation code, that our system can serve as a viable backup storage system in places whereregular high bandwidth Internet access does not exist. Also, our own experimental data collection aboutmobile phones file access patterns also supports the viability of our solution.

Looking ahead, we intend to use the analysis of file access patterns to develop a priority based replicationstrategy. That is, our goal is to be able to automatically identify important files based on their access pattern.

23


(a) Samsung Galaxy S (b) Samsung Galaxy S2

Figure 16: Energy consumption in a Wi-Fi file transfer for replication.

Such files would be replicated more aggressively and would be retrieved more eagerly. In the general case,these policies would self adapt based on the file priority, which is deduced from file’s access pattern.

References[1] “Customers Angered as iPhones Overload AT&T,” www.nytimes.com/2009/09/03/technology/companies/03att.html, 2009.

[2] “Mobile operators heading for big losses,” news.accuracast.com/, 2011.

[3] “Africa’s mobile phone industry ’booming’,” http://www.bbc.co.uk/news/world-africa-15659983, November 2011.

[4] M. C. Gonzalez, C. A. Hidalgo, and A.-L. Barabasi, “Understanding individual human mobility patterns,” Nature, vol. 453,pp. 779–782, 2008.

[5] C. Boldrini, M. Conti, and A. Passarella, “The sociable traveller: human traveling patterns in social-based mobility,” in Proc.of ACM MoviWac, 2009.

[6] N. Eagle and A. Pentland, “Reality mining: sensing complex social systems,” Springer Personal Ubiquitous Comput., vol. 10,pp. 255–268, 2006.

[7] D. Kotz, T. Henderson, I. Abyzov, and J. Yeo, “CRAWDAD data set dartmouth/campus (v. 2009-09-09),”http://crawdad.cs.dartmouth.edu/dartmouth/campus, 2009.

[8] “Dropbox. www.dropbox.com,” www.dropbox.com.

[9] J. Westfall and J. Westfall, “Using windows live services,” in Windows Phone 7 Made Simple. A press, 2011.

[10] “Amazon simple storage service (s3),” aws.amazon.com/s3/.

[11] S. Androutsellis-Theotokis and D. Spinellis, “A survey of peer-to-peer content distribution technologies,” ACM ComputingSurveys, vol. 36, pp. 335–371, 2004.

[12] L. P. Cox, C. D. Murray, and B. D. Noble, “Pastiche: Making backup cheap and easy,” in Proc. of OSDI, Dec. 2002.

[13] A. A. et al., “Farsite: Federated, available, and reliable storage for an incompletely trusted environment,” in Proc. of OSDI,Dec. 2002.

[14] J. D. and R. O., “Flexible replication for personal clouds,” Master’s thesis, ETH, Zurich, Switzerland, 2010.

[15] A. Post, J. Navarro, P. Kuznetsov, and P. Druschel, “Autonomous storage management for personal devices with podbase,” inProc. of USENIX, Jun. 2011.

[16] J. J. Kistler and M. Satyanarayanan, “Disconnected operation in the coda file system,” ACM Trans. Comput. Syst., vol. 10, pp.3–25, 1992.

[17] G. Popek, R. Guy, J. Page, T.W., and J. Heidemann, “Replication in ficus distributed file systems,” in Management of Repli-cated Data, 1990. Proceedings., Workshop on the, nov 1990, pp. 5 –10.

[18] E. B. Nightingale and J. Flinn, “Energy-efficiency and storage flexibility in the blue file system,” in Proc. of the 6th conferenceon Symposium on Opearting Systems Design & Implementation - Volume 6, 2004, pp. 25–25.

[19] D. B. Terry, M. M. Theimer, K. Petersen, A. J. Demers, M. J. Spreitzer, and C. H. Hauser, “Managing update conflicts inbayou, a weakly connected replicated storage system,” SIGOPS Oper. Syst. Rev., vol. 29, pp. 172–182, 1995.

24


[20] T. Hara, “Effective replica allocation in ad hoc networks for improving data accessibility,” in Proc. of IEEE INFOCOM 2001,vol. 3, 2001, pp. 1568–1576.

[21] P. Bellavista, A. Corradi, and E. Magistretti, “Redman: A decentralized middleware solution for cooperative replication indense manets,” in Proc. IEEE PERCOMW, 2005, pp. 158–162.

[22] G. Soriano and Y. Urano, “Replication with state using the self-organizing map neural network,” in Advanced CommunicationTechnology (ICACT), 2011 13th International Conference on, Feb. 2011, pp. 383 –388.

[23] P. Hui, J. Crowcroft, and E. Yoneki, “BUBBLE Rap: Social-based forwarding in delay tolerant networks,” in Proc. of ACMMobiHoc, 2008.

[24] E. M. Daly and M. Haahr, “Social network analysis for routing in disconnected delay-tolerant manets,” in Proc. of ACMMobiHoc, 2007.

[25] M. V. Barbera, J. Stefa, A. C. Viana, M. D. Amorim, and M. Boc, “Data offloading through vip delegation,” Proc. of DCOSS,2011.

[26] M. E. J. Newman, “Modularity and community structure in networks,” Proc. of the National Academy of Sciences, vol. 103,no. 23, pp. 8577–8582, Jun. 2006.

[27] L. Danon, A. Dıaz-Guilera, J. Duch, and A. Arenas, “Comparing community structure identification,” Journal of StatisticalMechanics: Theory and Experiment, vol. 2005, no. 09, p. P09008, Sep. 2005.

[28] P. Hui, E. Yoneki, S. Y. Chan, and J. Crowcroft, “Distributed community detection in delay tolerant networks,” in Proc.MobiArch, 2007, pp. 1–8.

[29] P. Jaccard, “Etude comparative de la distribution florale dans une portion des Alpes et des Jura,” Bulletin del la SocieteVaudoise des Sciences Naturelles, vol. 37, pp. 547–579, 1901.

[30] P. V and Marsden, “Egocentric and sociocentric measures of network centrality,” Social Networks, vol. 24, no. 4, pp. 407 –422, 2002.

[31] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography. CRC Press, 1997.

[32] L. C. Freeman, “A set of measures of centrality based upon betweenness,” Sociometry, vol. 40, no. 1, pp. 35–41, 1977.

[33] E. M. Daly and M. Haahr, “Social network analysis for routing in disconnected delay-tolerant manets,” in Proc. of ACMMobiHoc, 2007.

[34] D. Liben-Nowell and J. Kleinberg, “The link-prediction problem for social networks,” JASIST, vol. 58, no. 7, pp. 1019–1031,2007.

[35] A. Chaintreau, P. Hui, J. Crowcroft, C. Diot, R. Gass, and J. Scott, “Impact of human mobility on the design of opportunisticforwarding algorithms,” IEEE TMC, vol. 6, no. 6, pp. 600–620, 2007.

[36] P. Mistry and P. Maes, “Intelligent sticky notes that can be searched, located and can send reminders and messages,” in Proc.of IUI, 2008.

25


An Opportunistic Data Backup System for Mobile Ad Hoc Networks · To bridge this gap, we propose a...

Documents

Transcript of An Opportunistic Data Backup System for Mobile Ad Hoc Networks · To bridge this gap, we propose a...