Storing location-aware data in mobile distributed systems Daniel Urda∗ , Ciprian Dobre∗ , Florin Pop∗ Science Department, University Politehnica of Bucharest, Romania E-mails:
[email protected],
[email protected],
[email protected] ∗ Computer
Abstract—Smart mobile phones have become a common sight and every day new uses are found for them beyond their original scope of allowing voice communication between remote peers. Nevertheless, mobility limits the features a smartphone is able to provide in areas such as storage space and data communication costs. This paper proposes a solution for storing location-aware data in a medium composed of fixed points (workstations), wireless access points and smart-phone applications. The proposed system uses context information (location, neighbors) and techniques specific for opportunistic computing to provide an efficient management of the available data. The paper concentrates on the specific problem of using smart devices to provide a feasible satellite navigation system based on high resolution raster maps. An evaluation of the system’s performance is provided based on a custom simulator. Keywords-Opportunistic Computing, Distributed Systems, Satellite navigation
I. I NTRODUCTION Smarthones represent nowadays one of the fastest growing industry in the developed world. Integrating features such as mobile telephony, messaging, Internet browsing or music playing into a small and relatively cheap hand-held device, they have revolutionized the way we communicate, navigate, organize our activities. Navigation is one particular useful service used by many people nowadays. The iPhone longsuffered from no default turn-by-turn navigation app and only a few good third-party options. Then, Apple released their own version that nearly drowned in criticism. Google came to the rescue with the Google Maps [5], which quickly became a favorite turn-by-turn navigation app. Today the navigation app market is still dominated by Google Maps, with novel strong applications coming not far behind. When you’re visiting an unfamiliar location, Google Maps for mobile is great for getting an idea of how close you are to your destination, where streets and landmarks are in relation to each other, or just for getting “un-lost”. But what if you don’t have a data signal, or you’re abroad and don’t have a data plan? Let’s say later you’re visiting Bordeaux during a trip to France. If you were to open Google Maps for mobile and zoom into Bordeaux without data coverage or wifi, you’d see the image on the left in Figure 1. That’s not particularly useful when you’re trying to find out how close you are to the Cathedrale St. Andre [6]. But Google Maps is great because it caches the map tiles of areas you visit. Also, it provides a brut mode to cache
map tiles to an entire SD card. A little advance planning and “Download map area” can help. But what if you’re on a very limited data plan? This means you cannot afford to use Google Maps anywhere in the city without having to download the maps on-the-fly. And you don’t afford having an entire city cached in the phone memory/SDcard. So far, the only way one could control the amount of cached data tiles would be to manually scroll all over the city using different zoom levels. But is there a better/practical way to do that? In this paper we propose a system designed to provide a practical approach to storing map tiles and other geographical data for city navigation. We present the design considerations and proposed approach, and present results indicating the capability of the system to cope even with limited storage space and non-altruistic devices. The rest of this paper is structured as follows. Section II provides an overview of related work in this area. Section III presents the architecture of the system and implementation design options. Section IV details proposed means to attract users and persuade them to act towards increasing the efficiency of the system. In Section V we present an evaluation of the proposed system, describing assumed conditions and the input data, and the obtained results. Section VI concludes the paper.
Figure 1. Left: Bordeaux with no data or wifi. Right: Bordeaux with downloaded map area [6].
II. R ELATED WORK Except for Google Maps, today there are several navigation applications designed for mobile devices. Waze [17] offers good traffic information based on reports from users. It’s also free of charge. Navigon USA [4] it’s a popular GPS maker Garmin’s addition to the turn-by-turn navigation app pool. It offers live traffic data and maps that can be predownloaded. Still, the pre-downloading of maps can take awhile, but it seems to allow the app to operate much faster than apps that download information on the fly (like Waze). In Garmin North America [3] maps are also built-in to the app download, so once user downloads the application it is already ready to go. Gokivo Navigator [13] is another good free alternative for a navigation app, but it requires to download maps on-the-go (which is a problem for users under a limited data plan). Navfree GPS Live USA [11] is among the few free options that requires map downloads in advance. This isn’t necessarily a downside, as having the data in one’s phone ahead of time can make loading the maps a little bit faster. Such application are great as they offer a valuable on-thego navigation service over mobile devices. However, when people are on limited data plans, don’t have a data signal, or they’re abroad, downloading geographical data can be a problem. The alternative consists in downloading all the data in advance. Such a feature is today supported by the Google Maps’s experimental Labs feature called “pre-cache map area feature” [6] or by MapDroid [12], a popular Android service designed to download the entire map of need prior to the actual use with any navigation app. Unlike these solution, we propose an alternative where people opportunistically download geographical data of interest. In our approach users are working together to handle in a distributed manner the problem of map provisioning. Similarly to our approach, Haggle also seeks to provide a “search-based data dissemination framework for mobile opportunistic communication” [14]. What makes it special is the fact that it concentrates on the distribution of data instead of delivery of data to a destination known a priori. The Haggle system was, in particular, very instructive for the approached domain. Some of the design decisions we have taken in constructing or architecture are indeed inspired from the Haggle experience. The advantages of using social relations between users were also analyzed, again primarily in the context of pointto-point communication. Hui and Crowcroft have shown that a simple label used to mark users’ affiliation can increase delivery rate significantly while keeping costs small [7]. Hui, Yoneki et al. have later devised algorithms to dynamically detect communities in distributed mobile systems [9]. They were able to provide performance within 10% of the static community grouping, however the algorithms presented needed extensive testing and fine-tuning of many parameters
to reach such efficiency, not to mention that they were more computation intensive. Hui and Crowcroft continued this research line, proposing the BUBBLE algorithm that used, besides dynamically computed community information, the centrality of a node to decide forwarding [8]. Thus, messages for another community were directed to nodes with a higher degree-per-unit-of-time, which where empirically determined to have a greater chance of meeting nodes in the destination community. It is important to observe that none of the authors presented in this paragraph have studied the use of social networks in relation to data dissemination similar to the distributed mobile storage we seek to produce. That is they assume that data is on the move most of the time, while what we need is a mechanism to preserve data at a geographical location. Integration of social and context awareness for data dissemination was however studied by Bondini, Conti et al, building over the experience of Haggle [1]. The part of their research interesting to us is the presentation of a theoretical base for the weight of different parameters in the calculation of the opportunity of locally storing a packet of data. Unfortunately, the authors have not included geographic position among the parameters they have studied. III. P ROPOSED IMPLEMENTATION The main service provided by the proposed system is geographic data in the form of high-resolution map tiles. We assume a set of mobile clients (e.g., Android-operated smart-phones) equipped with Bluetooth connectivity and a localization module (GPS is preferred, but Cell localization can also be used instead). Other connectivity means, such as wireless networking (Wi-Fi) or Near Field Communication (NFC) can also be used for better performance. In addition, we assume a server which is capable to serve geographic data to these clients. The system distinguishes between two types of clients. An Active Client navigates towards a certain point, and needs to obtain map tiles in advance corresponding to his/her path to the destination (e.g., a navigator). This client actively seeks map tiles according to its destination. Because it uses a large amount of memory for that, it also has little interest to act as a carrier for unneeded data. The Passive Client can use map data provided by the system to explore points of interest (POIs) near his position (e.g., an application for tourism). This client requires few map tiles (corresponding to certain locations), and can use the rest of its storage space to relay tiles to other clients. Note that a Passive Client can anytime become Active, and vice-versa. In addition, nothing precludes one type of client to communicate with another type. A client can act as both Active and Passive during the same contact: thus, once an Active client gets all data needed from a peer, if connection time and local storage space allow it, it can enter Passive mode to obtain data not directly relevant to his route.
Figure 2. Overview of system architecture. The arrows represent communication. Communication taking place primarily over the 3G network is represented by dashed lines, while transfers taking place primarily over a medium free of direct costs, such as Wi-Fi, are represented by solid lines. Communication exclusively over proximity media (Bluetooth or Wi-Fi) is represented by a double line.
An overview of the proposed architecture can be found in Figure 2. A. Data The data provided by the system consists of highresolution map tiles in raster format. The size of one tile may vary from tens of kilobytes to megabytes. Data is primarily stored on the server, however only some of the clients will access it directly from there. Direct access will primarily happen when the environments permits low cost connections (e.g. through a Wi-Fi access point), and when a needed tile is not found in the mobile system. As we refer to geographical data, each tile is identified by the coordinates of its center (longitude and latitude). To keep track of tiles present in the mobile system, an attribute is used to record the tile availability. While clients or the server may also add other attributes for internal processing, only the tile’s center and availability (henceforth referred to a as a tile’s fingerprint) is used in client-server and inter-client communication. A fingerprint can be packed in only 8 bytes (see Figure 3), being significantly smaller than a tile. B. Server First of all, the server needs to permanently know an approximate availability of each tile in the system. Because only statistics given by direct downloads are not enough, we decided that clients have to regularly inform the server about local tiles availability through an Update Service. As we only need approximate availability, updates to the server need not be very frequent. In addition, only fingerprints of
locally available tiles are sent to the server. This provides for small traffic, acceptable even over network data (3G): about 1KB for every 128 locally stored tiles (not including any communication overhead). The server provides a Routing Service for the Active clients. Thus, it will internally compute an optimal route for an Active client to its destination, and will provide the client with a list of fingerprints for the tiles it needs to navigate to the desired target. As we expect that most interactions with the routing service will be over 3G, the transfer size was purposely kept low (estimated below 10KB). At the moment, we only provide the list of map tiles. In the future we plan to also provide the optimal route itself in vector form (either in a standard way such as KML or simply as a sequence of coordinates) as part of the routing service. As this may imply slightly higher cost, we did not include it in the current architectural prototype. As we do not think clients will define a route by its coordinates, the server should also provide a Search Service, to be used by Active clients in determining the correct destination (i.e. an address, POI, etc). Naturally, the server also has to provide a Download Service that will allow clients to directly download tiles. For Active clients, the selection of tiles will be based primarily on client requests, while for Passive clients the server will decide which tiles the client will get based on overall tiles availability in the system. Thus, besides tiles for the current location (which both type of clients will receive), the server will also push tiles it knows to be rare or not present at all in the mobile system. Tile transfer towards the clients will
Figure 3. Map tile fingerprint. Using smart packing of the elements, only 8 bytes are needed to hold attributes without loss of precision. X represents the geographic latitude, while Y the geographic longitude. A represents availability.
take place primarily over Wi-Fi connection. In exceptional cases (when an urgently needed tile is not available in the mobile part of the system), tile transfer may take place over the 3G network. C. Client We assume each client has a local storage, and can obtain data either from another client, or directly from the server. For each tile, besides the actual data and the tile’s fingerprint, the client also stores several attributes: distance from the current position to the tile’s center (using the Manhattan distance), time of acquisition, time of last distribution of the tile. Communication between clients can only work if clients can detect their neighbors. For this we assume a beacon message is periodically broadcast to neighboring devices. Also, we assume communication with the server will happen mainly over WiFi, but also over the 3G network (for availability updates, routing requests, and only exceptionally for downloading tiles). An ideal tile map for each type of client is presented in Figure 4. 1) Active clients require specific data. The first action an Active client takes after the user sets the desired destination is to inquire the server about the destination. In his reply, the server sends a list of tiles fingerprints, in the order they should be traversed. The order is important, as it helps the client to decide what data to discard when its storage becomes full. In case a Wi-Fi connection is available, all required tiles are directly downloaded. If the storage cannot hold all tiles, the list of tiles to obtain will be decided based on the tile selection algorithm described next. When only a Network Data connection is available, and the list of tiles on the route includes entries that are not present in the mobile system, the client can issue a request for those tiles (this is the exception when tiles can be downloaded over 3G). Still, considering 3G access is almost always available, the acquisition of such tiles will be deferred until the time they are actually needed. This way, the client still has the chance to get those tiles from a peer before it actually uses it.
In what regards inter-client communication, only the initiator type is important, both types of clients replying in the same way to requests. Once a client is found, the Active client sends a list of needed tiles to the peer. The list includes tiles not present in the local store, with the order number beginning with the nearest unavailable tile on the route. In this way, tiles that should have been traversed until this point are not requested . The peer replies with the sublist of nodes available in the local store, and optionally the number of tiles he agrees to share. Based on the selection algorithm, the Active client decides what tiles to request. In the first phase of the Selection algorithm, the average system availability of each tile available on the peer is computed. Then a weighted sum of the tile’s order number and availability is computed, and is used to order the list. If there’s no free space available in the local storage, some tiles must be discarded. If tiles not on the current route are present, they are discarded in the order of oldest distribution time (equivalent to the oldest time the tile was requested by a peer) or highest availability if never distributed. If no such tiles are present, but tiles on the current route that have the order number below the current order number are, they are discarded in the order of the lowest order number. If no such tiles are available either (i.e. we only have tiles that we must cross before we reach the destination), a decision must be taken about the opportunity of dropping existent tiles. The weighted sum of availability and distance is computed for locally available tiles on the current route still not traversed, as well as for the tiles that the peer can provide. Based on this sum, the tiles with the best gain, both locally available and available on the peer, are selected. The least efficient tiles are discarded until the gain can grow no more. 2) Passive clients generally communicate with the server, when no Wi-Fi connection is available, only when updating tiles availability. Based on user preferences, Passive clients may also request tiles representing the current location (when no peer is available). In this way Passive clients have a way to explore things in their proximity. When a Wi-Fi connection becomes available, a Passive client uses the update message to advertise its availability to receive tiles. Based on tiles locally available on the client and the overall availability of the tiles, the server decides which tiles it should push to the client. In our case, the decision is taken such that to minimize transfer size and maximize overall availability. The server can also decide considering the number of times a certain tile has been requested (i.e. included in a route), the location where each tile has been last disseminated, and maybe other parameters. D. Updating availability Data exchange is driven, among others, by a tile’s availability. The server always knows an approximate value of each tile’s availability due to periodic (albeit rare) client updates. However, it is obvious that not all tiles with low
Figure 4. Idealized data maps for a. Active clients and b. Passive clients. White squares represent tiles provided by the system, grey squares represent tiles needed by the clients, while slashed line square are tiles actually available in the local storage of each client. The current location of client is marked by a triangle, while the destination of the Active client is marked with a circle. Active clients seek to obtain in advance tiles covering their route, while Passive clients are only interested in the tile for the current position, and use the rest of the storage to keep valuable (i.e. more rare) tiles.
availability are equally useful for the system, as some areas of the city may present little interest for our users, e.g. primarily industrial areas, or waste disposal facilities. Since the server is able to keep track of such areas by analyzing the routes it provides to Active clients, we consider such information will also be useful in the algorithm we use to push data from the server to a Passive client. Normally, tiles that are not present in the mobile system have the availability value set to zero. To make sure tiles needed by Active clients are prioritized in distribution, we decided to allow negative values for availability (-1 for each tile in the route response to an Active client). When such a tile is distributed by the system (either pushed by the server, or explicitly requested by client), its availability is reset to 1. On server updates, for each client that stores locally the tile, the availability increases. Active clients may also notify the server when they reach their destination, to allow better approximations on the server by removing the client’s route tiles from the requested set. A much more delicate problem is keeping tile availability values on clients up to date with overall system availability. Obviously, it is not feasible to request from server and store locally availability data for all the tiles in the system. Neither is to request such values at the time of every interclient interaction. Hence, we need to initialize these values from the server, and otherwise let the clients compute their own availability values. For Active clients, the values are initialized when the list of tiles on the route is received from the server, as the tile’s fingerprint already contains this value. For Passive clients, the initialization is done whenever the server has the occasion to push data tiles, i.e. over Wi-Fi connection. We expect clients to interact between themselves much more often than directly with the servers. Thus, we also devised a mechanism to allow up to date availability values without interaction with the server. Whenever a client requests a tile from a peer, it also receives the availability values known by that peers (availability is included in the
fingerprint). Both participants in such exchange further increment their local values. In case of passive-to-passive data exchange, each client has access to the all the availability values of its peer. While for tiles not available locally it applies the strategy presented above, the availability of common tiles is computed differently, as the average of the two availability values. IV. E NTICING CLIENTS A. Rewards system As we think it is unrealistic to assume an opportunistic data distribution system will be only composed of altruistic users, we also devised a system that offers points to clients most active in distributing useful data. The need of a mechanism to persuade users to relay content that they have no direct use of was already mentioned in literature [10], albeit we are not aware of any working implementation. In our system, the number of points can be used to enforce a higher quality of service for better-ranked users, e.g. priority in inter-client data exchange. Since keeping records of actual data exchanges would mean either communicating with the server on each inter-client transfer or storing supplementary data on devices (that would have to eventually make their way to the server), we decided that activity will be measured indirectly, by the server, based only on the tiles available on a client on update. Thus, for each tile in local storage with overall availability below the average overall tiles availability, a client gets points depending to how low is the tile availability. To prevent clients from cheating, the server selectively requests a byte at a random position from one of the tiles to check against tile data from the server. A mismatch will result in the loss of all previously accumulated points. Furthermore, to make sure rare tiles are actually exchanged and are not hoarded for points, further points are awarded for the tiles for which availability increased between two server updates. Finally, some points can be given for each update, to increase fidelity to the system
(a minimum time between updates should be enforced to prevent cheating). B. Privacy concerns Considering the location-aware characteristic of our system, users may worry about the ability of others to track their movements. Past location will not be stored directly on the device; however the list of locally available tiles could indirectly provide such information, especially for Active clients. The fact that the data availability plays an important role in deciding what tiles clients store significantly reduces this risk for Passive clients, but users may need further assurances of their privacy. Therefore, we allow users to decide what data and how much of it is actually exchanged with peers. Thus, the users are able to limit the number of tiles distributed per exchange (but not bellow a reasonable limit), and are able to exclude from tiles advertisement sent to peers certain data (e.g. data acquired before or after a certain date and time). Those with more lax requirements may get bonus points in our rewards system. V. E XPERIMENTAL RESULTS A. Experimental setup and data The evaluation of the proposed system was done using modeling and simulation. We implemented our own Java-based simulator. To better understand how patterns of movement affect the system, a graphical user interface was implemented, by drawing the traces of clients over a real world map. A screen-shot of the GUI during live simulation is presented in Figure 5. In order to provide a scenario which closely resembles real-life, we use as input for the mobility model a real-world GPS traces of vehicles. We use the ‘epfl/mobility’ dataset available from the CRAWDAD community. The dataset, which was previously also been used in research [16], contains over 30 days of GPS traces for 500 vehicles (taxis), and extends over the area of the San Francisco Bay. The dataset also includes fare data, and we decided to use this in the simulation: during a fare, the client is always active, and the route to the destination is determined not by the server, but by the actual trace. Thus, the simulator prepares in advance the coordinates of a real fare, and uses this as input for requests to the server. When no fare is present, the taxi is considered as acting as a passive client. Considering the reduced range of Bluetooth (under 10m), we decided on simulating exclusively cost-free access over Wi-Fi. We chose to use the specification of the 802.11g standard, as it provides a far better range (cca. 90 meters) at reasonable speeds in outdoors environment [2], where our system is supposed to be deployed. As no free data-set of Wi-Fi APs in the area of San Francisco was available, we manually chose a series of location for their placement in the simulation. The selection of the actual locations was based mostly on visual observation of the traces in the
Figure 5. Simulator GUI. Colored dots represent clients. Red lines represent trace of directed movement (periods during which the client is Active), while green lines represent free roaming (periods during which the client is Passive). The time of the simulation, as well as instantaneous possible Wi-Fi connections are presented on the right. Fixed Wireless Access Points are presented as black rectangles.
mobility data-set, also imposing some restrictions (no APs with overlapping range, placements close to public streets, higher density in central areas of the city). Also, the map tiles used are actual map tiles of the area downloaded from OpenStreetMap [15]. The map tiles are geo-referenced, thus the GPS positions in the mobility data-set are adequately aligned to streets. Within the simulation experiments we varied the number of clients that interact between themselves and with the central servers. Two clients collaborate if they are located within 90m, the same distance being used as threshold for client-server communication. As the time interval between two GPS readings varies in the mobility trace from 30 seconds to almost 2 minutes, we decided to use a standard time step of 60 seconds. We considered that each interaction lasted enough for the transfer of 2-5 MB of data. The simulated period was varied for different experiments. The geographic area of a tile was varied between 0.4 and 6 km2 (corresponding to zoom levels 14 through 16 in OpenStreetMap). The size of the local store on the device was varied between 5 and 10 MB. B. Data transfer analysis We first evaluated the amount of communication data. Figure 6 presents the effect of tile size over the transferred data. Devices need fewer tiles to represent the target area as the area of one tile increases. Consequently, less Wi-Fi
contacts with the server are needed to introduce most of the map in the system. For area with high traffic, this means that shortly after the start of simulation, all vehicles in the area were able to use the data without carrier costs. As the tile size decreased, tiles requested from the server became more targeted on the desired route, thus creating less opportunity for distribution of the tiles to other clients.
communicates directly only with the server (whether over 3G or Wi-Fi). In the second scenario, inter-node communication was also allowed. In this case, if two nodes fall within the communication threshold and at least one of them was an active client. In the third scenario, generic inter-peer communication was permitted. In order to provide realistic cost computation, we analyzed the cost per megabyte over network data provided by the major Romanian telephony providers, obtaining an average cost of 0.2 e/MB. No costs were assigned to the Wi-Fi traffic. For simulation, we chose to test the above scenarios for periods of one day, two days, and one week.
Figure 6. Effect of tile size on transfer size. As the area represented by one tile gets smaller, the number of tiles to be retrieved directly from server increases. Note that the ratio is still manageable: under 15% of the tiles, and less than 20% of the total traffic is done on 3G.
Figure 8.
Figure 7. Fairness of the selection algorithm. In a fairly homogenous community, the number of tiles distributed by a client is still generally very close to the number of tiles received.
Figure 7 shows the fairness of the tile exchange algorithm. By using the availability of tiles as the main parameter of the algorithm deciding to transfer on node encounter, we make sure that the number of tiles not actually needed is kept low. Moreover, by directly controlling the passive clients during Wi-Fi encounter, the server can calibrate the stability of the system, by injecting tiles that will be needed by others in the future. C. Cost analysis In order to study the cost benefits provided by our proposed system we varied the amount of inter-node interactions. In the first scenario, we assumed that all peer
Cost of 3G data traffic - total costs for the different scenarios.
As seen in Figure 8, the use of inter-node communication for active nodes provides a 20% reduction in overall costs. Surprisingly, the scenario using general inter-node communication provided inferior results. We assume the cause of this degradation is the unrefined tile exchange between passive nodes. By carefully observing the distribution of tiles in local store, we determined that currently passive clients prefer storing the least available tiles in the system, saturating their own store. Thus, they become unwilling to also store commonly needed tiles, which, while often distributed, are the first to be discarded. More research is needed to balance the exchange algorithm between passive node in order to leverage this. VI. C ONCLUSIONS In this paper we presented a solution for storing locationaware data in a medium composed of fixed points (workstations), wireless access points and smart-phone applications. The proposed system uses context information (location, neighbors) and techniques specific for opportunistic computing to provide an efficient management of the available data. The evaluation of the system’s performance was conducted using a custom simulator. Using social relationships, we actually increase the chances of tiles making their way to clients actually needing it. The rewards system we proposed also favors smoothing of the availability of the different
R EFERENCES [1] C. Boldrini, M. Conti, F. Delmastro, and A. Passarella. Context- and social-aware middleware for opportunistic networks. J. Netw. Comput. Appl., 33(5):525–541, Sept. 2010. [2] B. Corp. Ieee 802.11g - the new mainstream wireless lan standard, 2003. [3] Garmin. Garmin n. america. https://itunes.apple.com/us/app/ garmin-n.-america/id435740864?mt=8. [4] G. W. GmbH. Navigon usa app. https://itunes.apple.com/us/ app/navigon-mobilenavigator-usa/id384680007?mt=8. Figure 9. Cost of 3G data traffic - the ratio between the scenarios implying inter-ode communication and the base scenario.
data chunks, thus it will be able to serve many clients with competing destinations. While we designed the system primarily for serving map tiles during satellite navigation, we have shown that it can easily be extended to work with indoor positioning and generic location-aware data. Simulations over real-world data proved that the system can successfully reduce communications costs in areas with high traffic and a moderate number of clients. One aspect we did not touch in this paper, and which we think to be very important, is security. A mechanism should be provided to assure data integrity (i.e. prevent malevolent clients from flooding the system with fake data), a requirement that is far from simple even in semi-distributed systems such as ours. Different hashing and signing should be studied to determine which provides best integrity with least overhead in tile size. To make sure our awards system is convincing, we are currently investigating the development of mechanisms that clients can use to verify the identity claimed by a peer. Another problem arises if the system is to be used to distribute limited-access data. To allow the system to work at full potential we must allow privileged data to be relayed by unprivileged clients. Thus we also currently investigate solutions to allow data be relayed without compromising its security. All in all, we expect security provision to be a major topic in future developments. VII. ACKNOWLEDGMENT This work was partially supported by project “ERRICEmpowering Romanian Research on Intelligent Information Technologies/FP7-REGPOT-2010-1”, ID: 264207. The work has been co-founded by the Sectoral Operational Programme Human Resources Development 2007-2013 of the Romanian Ministry of Labour, Family and Social Protection through the Financial Agreement POSDRU/89/1.5/S/62557. This work was also supported by project “SideSTEP Scheduling Methods for Dynamic Distributed Systems: a self-* approach” (PN-II-CT-RO-FR-2012-1-0084).
[5] Google. Google maps. http://maps.google.com/help/maps/ helloworld/iphone/index.html. [6] Google. Google official bloh, download map area added to labs in google maps for android. http://googleblog.blogspot. ro/2011/07/download-map-area-added-to-labs-in.html. [7] P. Hui and J. Crowcroft. How small labels create big improvements. In Pervasive Computing and Communications Workshops, 2007. PerCom Workshops ’07. Fifth Annual IEEE International Conference on, pages 65–70, 2007. [8] P. Hui, J. Crowcroft, and E. Yoneki. Bubble rap: Social-based forwarding in delay-tolerant networks. Mobile Computing, IEEE Transactions on, 10(11):1576 –1589, nov. 2011. [9] P. Hui, E. Yoneki, S. Y. Chan, and J. Crowcroft. Distributed community detection in delay tolerant networks. In Proceedings of 2nd ACM/IEEE international workshop on Mobility in the evolving internet architecture, MobiArch ’07, pages 7:1–7:8, New York, NY, USA, 2007. ACM. [10] J. Leguay, A. Lindgren, J. Scott, T. Friedman, and J. Crowcroft. Opportunistic content distribution in an urban setting. In Proceedings of the 2006 SIGCOMM workshop on Challenged networks, CHANTS ’06, pages 205–212, New York, NY, USA, 2006. ACM. [11] G. Ltd. Navfree gps usa. https://itunes.apple.com/us/app/ navfree-gps-live-usa/id405922167?mt=8. [12] MapDroid. Offline maps for the whole planet. https://play. google.com/store/apps/details?id=com.osa.android.mapdroyd. [13] I. Networks In Motion. Gokivo gps navigator. https://itunes.apple.com/us/app/gokivo-gps-navigator-turn/ id319730503?mt=8. [14] E. Nordstr¨om, P. Gunningberg, and C. Rohner. A searchbased network architecture for mobile devices. Department of Information Technology, Uppsala University, Tech. Rep, 3, 2009. [15] OpenStreetMap. Web page. http://www.openstreetmap.org. [16] M. Piorkowski, N. Sarafijanovic-Djukic, and M. Grossglauser. A parsimonious model of mobile partitioned networks with clustering. In Communication Systems and Networks and Workshops, 2009. COMSNETS 2009. First International, pages 1 –10, jan. 2009. [17] WAZE. Waze - social traffic and navigation app. http://www. waze.com/.
