Geo-DMP: A DTN-Based Mobile Prototype for Geospatial Data Retrieval

Abstract

Geospatial information is gaining immense interest and importance as we enter the era of highly developed transportation and communication. Despite the proliferation of cellular network and WiFi, on some occasions, users still face barriers to accessing geospatial data. In this paper, we design and implement a distributed prototype system with a delay/disruption tolerant network (DTN), named Geo-DMP, for cooperatively and opportunistically sharing and exchanging named geospatial contents in a device-to-device fashion. First of all, we construct a lightweight “content agent” module to bridge the gap between the application layer and the underlying DTN protocol stack. Afterwards, to profile the mobility history of users in practical geospatial environments, we present a map segmentation scheme based on road network and administrative subdivision information. Subsequently, we associate the regional movement history information with the content retrieval process to devise a hierarchical and region-oriented DTN routing scheme for both requests and responses. Finally, we conduct extensive experiments with real-world trajectories and complete implementations on the emulation platform composed of virtual machines. The experiments corroborate that Geo-DMP has the capability of successfully retrieving geospatial contents for users for most of the time under mobile circumstances with episodic connectivity. Moreover, en-route caches can be efficiently exploited to provision contents from multiple sources with less network resource consumption and shorter user-perceived latencies.

1. Introduction

The advancements and achievements in mobile computing have profoundly revolutionized contemporary society. Over the past decade, versatile yet affordable commodity portable devices have exhibited burgeoning growth worldwide, especially in emerging markets, as illustrated in Figure 1 [1]. Liberating users from desktop computers and wired connections, they make almost all applications pervasively available, so, unsurprisingly, they have been inextricably intertwined with people’s daily routine activities [2].

For the majority of mobile users, applications that provide geospatial information often appear in their must-have app list [3]. Such substantial demand is largely resulted from the “motorized mobility” (i.e., travel by car, bus, train or aircraft) and highly-developed transportation system [4] in modern life. People have more opportunities to reach far and strange places and face sophisticated surroundings moulded by fast-paced urbanization [5]. Under these circumstances, instant geospatial information may be of great help.

Along with the high value and importance of geospatial information being widely realized and the coming of the web 2.0 era, users are not only data consumers but also actively participate in the contribution of geospatial content. Such progression is conceptualized by scholars as “Geospatial Crowdsourcing” [6] or “Volunteered Geographic Information” [7]. Compared to conventional collection methods, in this case, expensive deployment and maintenance cost of sensory instruments can be saved, broader spatio-temporal coverage can be achieved, and more timely, detailed, and diversified data can be gathered. As it is a consensus that a significant portion of data generated in human day-to-day life is annotated with locational attributes [8,9], with the aid of innumerable volunteers and a plethora of programmable sensors embedded inside mobile devices, we will gain further insights into the ambient environment from more perspectives, ranging from road traffic forecasting [10], culture heritage conservation [11], meteorological or climatological statistics [12], and environmental monitoring [13], to name just a few.

However, currently, most geospatial-related applications are dependent on a centralized network infrastructure. Although lately, cellular network (3G/4G) and Wi-Fi are almost omnipresent, it still cannot be taken granted that they are always available for use. Firstly, natural catastrophes may incapacitate communication infrastructures and cause long-lasting outages [14,15]. Secondly, in some densely populated situations, such as live concerts, sports matches, or large exhibitions, a burst of mobile clients may overload the cellular network and deteriorate network performance [16,17]. Thirdly, a limited and costly data traffic budget, particularly in underdeveloped and developing countries, as revealed in Figure 2 [18,19], and the time-dependent pricing (TDP) strategies [20] cast influence on the attitude of subscribers towards data usage. Users possibly prefer to conserve a data quota or not enough data volume is left at the moment they need to access geospatial information. Lastly, although ever-growing Wi-Fi hotspots are deployed [21], looking for openly accessible ones is still no easy task, even in metropolitan areas [22]. Most discoverable access points are password-protected, and some enforce an authentication or registration via portals. Even if a user on-the-move is lucky enough to find a free usable AP, it is unable to serve persistent connections for him due to its finite radio coverage [23].

With all that in mind, it is quite reasonable that an alternative infrastructure-free method of acquiring and exchanging geospatial content is worth investigating. As a matter of fact, many past scholarly works have well documented feasibility proofs and practical means towards this goal. Above all, it is confirmed that users show a willingness to bear more patience on time-insensitive contents [24,25]. In addition, multiple built-in short-range radio interfaces offer a novel way for mobile users to transmit contents between their devices directly. This device-to-device (D2D) [26] communication paradigm alleviates the reliance on infrastructures. Furthermore, as in decentralized wireless scenarios, by virtue of the intrinsic mobility and confined communication range of mobile devices, the absence of contemporaneous end-to-end path is commonplace, which contradicts classical network protocols. Delay/disruption tolerant networking (DTN) [27] enhances the resilience and reliability of transmissions in these challenging environments with the “store–carry–forward” paradigm. By taking advantage of the ephemeral pairwise encounter chances, heterogeneous underlying physical networks and local storage resources, data can asynchronously traverse a network via multi-hop relays.

Consequently, it can be envisaged that the fusion of D2D, DTN and spatial-related information would be particularly advantageous in two respects: One is being able to fetch contents that are infrequently changed and not in urgent need across long delay from distant places with classical DTN capabilities, such as maps or geotagged photos [28]. The other is, thanks to such decentralized communication mechanism, some real-time or emergent information could be announced or exchanged among nearby neighbors before it is reported to the supervisor, so it can be made known and dealt with as soon as possible. Some examples are evacuation guidance [29], warning for accident prevention [30], and updates of real-time traffic states [31], among others.

At the same time, it should be admitted that research on DTN is obviously biased. A voluminous literature focuses on strategies (routing, caching, congestion control, incentive encouragement, etc.), while only a small fraction of research work is devoted to actual deployment and application. As a result, there is still a long way to go to fully exploit the potential of DTN in a real-world setting. Filling this gap between theoretical and empirical sides of DTN is one of the chief motivations of our research.

In our former work [32], we have implemented a wireless prototype system, named GeoTile, for geospatial data acquisition through connected multi-hop relay nodes. We thoroughly studied to what extent in-network caches could benefit the end-user and overall performance. In this paper, through the integration with DTN, persistent connections between nodes can be extended to intermittent ones. We also proceed to explore the supportive mechanisms for providing better adaptability to mobile contexts. The principal objective of this work is to present a complementary method for mobile users to obtain or exchange geospatial data under exceptional cases, e.g., when other wireless networks are unavailable at the moment or events of great urgency have just happened. This would similarly be profitable for crowd-sourcing applications, as participants do not have to constantly keep contact with a central server and it is more friendly and convenient to interchange gathered data amongst themselves.

Briefly speaking, the highlights of the work in this paper are as follows. Firstly, we propose a distributed system aimed at geospatial content sharing in opportunistic environments. Secondly, to characterize the mobility of users and embody it in a more concise representation, we introduce a multi-layer map partition scheme that combines road network and administrative information. Thirdly, we design an exploratory hierarchical DTN routing protocol to associate the bundle forwarding process with the history of movement knowledge based on realistic geospatial regions. Finally, to validate whether the system works properly and evaluate system performance, we run experiments on a virtual machine (VM)-based emulation platform.

The outline of the remainder of the paper is as follows. In Section 2 we begin with an overview of relevant academic studies. Next, we will sequentially delineate each point of the main work stated above in Section 3. After that, the evaluation results of the system on the emulation platform are presented and analyzed in Section 4. We end the paper with the conclusions and prospects for future work in Section 5.

2. Literature Review

Concerning the content acquisition process performed by nodes with dynamic mobility and sporadic connectivity, several questions should be considered: How can we make ordinary users able to convey their needs to DTN-aware nodes? Given that they can interact, how can we explicitly identify and find desired contents in distributed cached resources? When these contents can be discovered somewhere, how can we efficiently retrieve them back to the requesters in real-world scenarios? In this section, we will present a review and discussion revolving around these three research topics.

2.1. Bridging DTN with HTTP-Based Services

From the dawn of scholarly pursuits on DTN onwards, how to make this emergent technique apply to existing application-level services has been one of the foremost concerns [33]. Because HTTP is deemed to be the foundation for interaction of a large portion of such kinds of services [34], breaking the isolation between HTTP and bundle protocol is of prime importance. To this end, Ref. [35] summarizes three candidate methods from an architectural viewpoint, namely end-to-end, proxy-based, and gateway-based. The first one refers to the case that both client and server sides have DTN deployed, hence no extra interpreters are needed. The second one, while, similarly, both sides are DTN-aware, a proxy node resides ahead of a cluster of servers, which makes servers transparent to requesters and facilitates content aggregation and load balancing. In the last case, as opposed to the above two methods, the DTN deployment is migrated from client and server nodes to dedicated gateway nodes attached to them.

As the practices of these design thoughts, Ref. [36] proposes an “end-to-end” solution for client browsing in the form of web-based applications over DTN. The web-apps can be automatically installed or removed in accordance with the surroundings of users. However, in this way, too much burden is imposed on the end-device: Not only should native DTN support be built-in, but also a local web server needs to be deployed. Ref. [37] employs the option of “proxy-based” and hotspot nodes are delegated to retrieve contents for end-users from remote servers. Ref. [38] follows the “gateway-based” structure to make the contents inside DTN accessible to users who are not DTN-aware by leveraging shared access points as gateway nodes. Taken together, in this work, we adopt the “gateway-based” approach, for reasons that, firstly, from the perspective of implementation the least effort is required for modification on existing functionalities of clients and servers; secondly, little knowledge about DTN is requisite for users; thirdly, the isolation of DTN makes the system more general-purpose, extensible, and flexible. Although the basic idea of our work bears some resemblance to [38], in our design, the gateway nodes are not specialized APs, but ordinary human-carried or vehicle-mounted devices instead. Apart from the three typical models, aiming at rendering support for a wider range of applications with a unified bottom layer, Ref. [39,40,41] conceive middleware platforms. Nevertheless, their heterogeneous and non-compatible designs complicate the reproduction and deployment. Developers should conform to given API specifications in order to fit the applications onto them.

2.2. Named Content Retrieval

Indisputably, an evolution has taken place in the way of network usage, as several recent reports [42,43] suggest that data traffic is overwhelmingly dominated by digitized contents. Such a new trend indicates that, instead of “end-to-end” conversations, now users are more concerned with obtaining desired contents efficiently.

Disappointingly, Internet-related protocols are not really good at this aspect: The “link rot” problem [44,45] often causes inaccessibility, and target host-centric requests result in repeated transmissions and significant waste on bandwidth [46]. Though remedial measures such as content distribution network (CDN) and peer-to-peer (P2P) overlays have been proposed, these patching methods inevitably introduce extra complexity and unexpected problems, as the high financial cost for content publishers and maintenance cost for service providers in CDN [47]; and a massive amount of cross-ISP traffic which is contradictory to policies of ISPs in P2P [48].

This is what prompts the academic communities to reconsider clean-slate content-centric designs for the next generation of inter-networking. Among all proposals, information-centric networking (ICN) [49] is a representative solution that attracts much attention. Unlike conventional IP-based networking, ICN natively privileges contents and their unique names to serve the purpose of efficient dissemination and reduction on network load.

Interestingly, despite some dissimilarities in applicable scenarios, DTN shares many commonalities with ICN in respect of in-network caching, late-binding technique, hop-by-hop transport, and asynchronous interaction model. Therefore, it is plausible to borrow the main ideas of ICN to tackle with the inefficiency of content acquisition and resource utilization in DTN. Lately, several research works attempt to directly extend ICN approaches to DTN [50,51,52,53]. However, such migration is neither effortless nor seamless. For one thing, studies of ICN are still in its nascent stage and lots of problems remain unsolved. For another, it should be noticed that ICN and DTN have essential architectural differences.

To gain the synergy with less investment, the Delay-Tolerant Networking Research Group (DTNRG) proposes the bundle protocol query (BPQ) mechanism [54]. BPQ enables content naming as well as name-based matching, caching, and routing. More importantly, it is compatible with antecedent DTN standards, which means modifications on the basic framework can be minimized and existing works in DTN still have their values. Even though BPQ is often mentioned in past papers [55,56,57,58], it is not fully exploited in research work. As far as we know, only two papers put BPQ into practice: in [59], BPQ is adopted to mingle the protocol stack of DTN and named data networking (NDN) [60]. Ref. [61] presents an architecture for offloading contents that are bulky and do not have a tight delivery deadline from cellular network to local DTN network, in which BPQ works for content lookup among DTN nodes. To further explore the possibilities of BPQ, in this paper, we apply BPQ to the dissemination of geospatial data. Additionally, location indicators are incorporated in BPQ-enabled bundles to supplement more information for routing decisions.

2.3. Map-Based Region Partitioning for Content Dissemination

It is known that mobility is a predominant feature of DTN networking. The uncertain and fragmented network topology is a major obstacle for telling exactly how and where to get in touch with a given node when necessary in a distributed environment. Fortunately, implicit in the movement of people is the periodicity and regularity to a certain degree, both in social [62] and geographical [63] aspects. In other words, people have the propensity to meet a group of persons and go to a collection of places more often.

Motivated by these findings, in spite of the scarcity of a real-time global knowledge of a network, scholars have attempted to make progress in making DTN more effective and meaningful by extrapolating future behaviors from historical knowledge of social relationships [64] or spatial movements [65]. In this paper, we are more interested in geographical rather than topological relations among nodes. It goes without saying that precisely capturing the mobility pattern of nodes will greatly contribute to the accuracy of routing strategies.

Meanwhile, simply recording a large quantity of raw GPS coordinates will incur excessive storage consumption and intensive computation to learn the regularity behind moving traces, which is unfavorable as nodes in DTN are typically resource-constrained. One viable solution is region-based methods. By dividing the whole area into a series of subregions, the position of a node can thus be represented by the subarea it currently lies in, and further, the moving process of a node can be simplified as a discrete sequence of subregions. Whereas various ways to generate subregions are presented in existing works, including breaking into regular shapes [66,67,68,69], geometric partitioning [70,71], and artificial clustering [72,73], etc., an apparent shortcoming is that none of them are in line with actual environments, as they neglect natural boundaries such as roads, rails, rivers, outer periphery of buildings, among others. Especially for most used grid-based methods, although it is easier to control the area size, code the area, and maintain the hierarchy information, some researchers point out that the determination of the size, position, and orientation of grids is arbitrary [74], and the fixed-size unit is not sufficient to reflect the density of users and their activities [75]. As a result, macroscopically, the methods above all fall short in portraying the “activity space” [76], which refers to areas that are delimited by the course of daily routines of people, and microscopically, actions of moving across boundaries become less meaningful, as one may produce crossings simply by wandering around his home or workplace.

For the sake of making more solid associations between daily spatiotemporal activities of inhabitants and the segmentation of subregions, small-scale boundaries with administrative properties, for instance, census tracts, postal code areas, or voting precincts are seemingly better choices. They are not merely reasonable approximations to sociological structures like residential neighborhoods, street blocks, and communities [77,78], but exhibit demographic and socioeconomic characteristics as well [79,80]. As more researchers realize the advantages of such methods, recent years have witnessed their wide adoption by multidisciplinary studies, such as criminology [81], public health [82,83], municipal planning [84], and so forth. Many cases [85,86,87] have proved that region-based methods can outperform grid-based methods.

Hopefully, such methods will be analogously beneficial to research in the field of mobile computing. Instructed by this idea, we attempt to devise a multi-level map partitioning scheme based on the road network and administrative boundaries. We expect that it will lay a concrete foundation for future protocol or application design. More specifically, predictive routing based on analysis of historical trajectories, or geocasting [88,89] which aims to route specific messages (e.g., promotional campaigns or emergency notifications) to target locations.

Map segmentation according to the road network of large cities also appeared in [90,91] as the basis of their works. Ref. [91] divides the map recursively into multiple levels by road hierarchy, but this is not enough to reflect administrative features. In our method, we will make an effort to align the segmentation result with administrative subdivisions. Ref. [90] extracts the road skeleton by image processing techniques, with the sacrifice of metadata describing properties of vector objects. By contrast, segmentation of our method is purely through processing on vector data, and metadata can be preserved for future use.

3. Geo-DMP Mobile System

In this section, we will elaborate on each constituent part of our work in the succeeding subsections, respectively. Specifically, we start with introducing the framework of Geo-DMP. Thereafter, the workflow and mechanism of delay-tolerant content retrieval are described in detail. Next, we present the method of partitioning map into regions by taking administrative boundaries into consideration, along with the usefulness of segmented regions in the design of routing protocol.

3.1. System Framework

As illustrated in Figure 3, the framework of Geo-DMP consists of three main modules: content agent, DTN stack, and map adaptor. The content agent is our own implementation to realize the “gateway-based model”. It is deployed on gateway nodes and interacts with DTN on behalf of application and thereby makes DTN transparent to the user. The heart of the content agent is the proxy module. It is implemented with anyproxy [92], an open-sourced javascript-written proxy tool. With the main feature of anyproxy, which is to intercept the incoming HTTP requests and construct new HTTP responses, we developed the transformation between HTTP messages and DTN bundles, as well as the utilization of local caches. Preceding received contents are stored in local cache both for immediate provision for recurring local requests and responding to requests from other nodes in the near future.

The DTN stack we use in our work is DTN2 [93]. DTN2 is an open-sourced reference implementation of the full protocol stack of DTN, consistent with RFC documents [94,95,96] and developed by DTNRG in C++.

As a promising proposal, the code implementation of the BPQ mechanism is also incorporated in the latest version of DTN2. We benefit from this work and employ it for content naming and matching. Two data structures form the core of the BPQ definition: BPQ block and BPQ Cache. BPQ block is an extension block in the bundle header. It mainly records the name of content and specifies the type of bundle so as to support content naming and pub/sub communication model. To distinguish the bundles with BPQ block from the normal bundles, two distinct bundle types are newly defined: query and response. As their names suggest, the former one conveys what content the requester wants, while the latter one carries the content back to the requester. As this block is not mandatory, BPQ-enabled bundles can co-exist with normal bundles and can be routed according to endpoint ID as usual, hence, the compatibility is guaranteed.

BPQ Cache manages content resources that BPQ can take advantage of, that is, it contains all information of response bundles. It should be noted that although the query bundle is also a member of the BPQ-enabled bundle, it is not included in BPQ Cache as it does not have any payload data. Moreover, the normal bundle is excluded from the BPQ Cache, too. This is because its payload does not have a name, so it could not be used by BPQ.

DTN Daemon is the pivot of DTN2, which serves as a central controller and scheduler. It is responsible for handling all incoming events and dispatching jobs to other dedicated components. Bundle List is the place that maintains all local bundles, including normal bundles and BPQ-enabled bundles. In other words, BPQ Cache is a subset of Bundle List.

The “Trace Reader” and “Link Emulator” are two modules that involve emulation. The former one emulates the GPS of the mobile node. Upon the request of location, it reports the GPS coordinates from a pre-generated trace file. This module can be substituted with a real GPS receiver when the implementation is ported to actual devices, leaving other parts in the upper layers unchanged. The latter one controls the establishments and disconnections of links. Periodically, the real-time location is derived from the trace reader and broadcast in a beacon packet. When receiving a beacon packet from another node, the link emulator records the distance between them to the table named “Neighbor Distances”. With this table, the local node can judge whether it resides in the preset communication range with the source of an incoming normal packet, and drop it or make it pass accordingly. As this module works on the network layer in Linux kernel space, the filtration is transparent to DTN.

To make generalized BPQ-based content retrieval adapt better to realistic map-based scenarios, we present the map adaptor module. It is comprised of a local database of map segmentation results and an interface. At fixed time intervals, DTN requests region information by issuing a query to the interface. The interface reads the current GPS coordinates from the trace reader or GPS module, inquires the database with the coordinates, and returns the regions in which the node is located now. Then, DTN saves this regional information to the “Movement History Maintanence” module for future uses of making routing decisions locally and exchanging movement knowledge upon contacting other nodes. The creation process of the map segmentation database will be given in Section 3.3.

3.2. The Workflow of Geo-DMP

After a systematic overview of the framework, by elaborating on the conversion and handling of different types of data units that occurred during the content retrieval procedure, we show the working mechanism of Geo-DMP.

3.2.1. On the Perspective of Transformations between HTTP Messages and DTN Bundles

In this part, we concentrate on interactions on the gateway nodes that connect DTN-aware nodes with the client and server. As the process of contacting with the server side should be made clear, here we do not consider the situation of discovering replicas at intermediate DTN nodes. The entire procedure can be divided into four phases, as shown in Figure 4.

Phase 1: HTTP Request to DTN Query (Client Side)

The proxy at the Terminal Gateway (hereafter TG) keeps listening to HTTP requests and intercepts those asking for geospatial contents in light of predefined rules. Then it resolves the type and name of requested data from the URL, and checks whether this content is already available locally. If yes, it will return the content to the client instantly without resorting to DTN. Otherwise, a new query bundle is created with parameters of destination EID, destination regions, and content name. After that, the proxy invokes the DTN API to inject this bundle into the DTN network.

Phase 2: DTN Request to HTTP Request (Server Side)

Through multi-hop relaying of DTN nodes, when the query bundle arrives at the Server Gateway (hereafter SG), DTN extracts the content name from the BPQ block and hands it to the proxy module. The proxy then asks the back-end server for that content with a newly generated HTTP request.

Phase 3: HTTP Response to DTN Response (Server Side)

After processing inside the server (which is described in our previous paper [32]), the HTTP response is generated and returned to the SG. The proxy at SG unpacks the HTTP response and calls the DTN API to publish this content into the DTN network. Afterwards, this content is used to satisfy the awaiting query bundle and create the corresponding response bundle.

Phase 4: DTN Response to HTTP Response (Client Side)

Eventually, when the response bundle is routed back to the TG, DTN reads the content name from the BPQ block and informs the proxy that the content is ready. Thereupon, the proxy goes to fetch the content, stores the payload to the local cache, makes a new HTTP response, and finishes the procedure by returning it to the client.

3.2.2. On the Perspective of Handling Incoming BPQ-Enabled Bundles

Next, we take a closer look at what operations are performed inside intermediate DTN nodes and how BPQ works for content discovery during the multi-hop relay of BPQ-enabled bundles. Depending on different types of incoming bundle, the internal process can be discussed in three situations.

1. Upon Receipt of Newly Generated Query

When the DTN Daemon takes out one event indicating the arrival of a bundle from the event queue, the first step is to recognize the type and source of the bundle. The bundle will be identified as a query bundle when a BPQ Block is found in the bundle header and the value of the type field is “query”. If the source EID is identical to that of the local node, it means this bundle is newly generated locally. As the creation of the query bundle only happens after the proxy fails to find the requested content at the local cache, this bundle cannot be satisfied at the moment. So it will be kept in the Bundle List to wait to be routed to other nodes or matched with incoming contents. This process is illustrated in Figure 5.

2. Upon Receipt of Extrinsic Query

When a received bundle is recognized as a query bundle from another node (i.e., its source EID is different from the local one), DTN Daemon will attempt to satisfy it after putting it into the Bundle List. Firstly, DTN Daemon gives the content name specified in the query bundle to the BPQ module. Secondly, the BPQ module matches this name with items in BPQ Cache to see if the desired content is locally cached. Thirdly, if found, the content body is replicated and assembled with information for the bundle header as a new response bundle, then it is pushed to the BPQ Cache and Bundle List. Whether this response bundle is forwarded to the current neighbor is subject to the decision of the routing protocol. Since the query bundle has accomplished its task of finding the content, it will be removed from the Bundle List. Figure 6 depicts this process where the green arrows represent the steps after the successful matching.

3. Upon Receipt of Extrinsic Response

After the identification, if the received bundle is a response bundle from another node, it will be stored in the Bundle List and BPQ Cache at first. Subsequently, the BPQ module will check whether this new content can be used to satisfy local awaiting queries. Successful matches will generate corresponding new response bundles. Again, these response bundles are pushed to the BPQ Cache and Bundle List while the satisfied query bundles are removed. The routing protocol then selectively forwards some of these response bundle to the neighbor in contact. This process can be seen in Figure 7.

3.3. The Development of the Map Adaptor Module

Next, we will present the production process of another key component of the framework, the map adaptor. In a nutshell, we partition the vector map into three nested layers with proper region size as well as in compliance with typical typology in sociology studies [97]: blocks, communities, and subdistricts. We then transform them into a compact and portable database for mobile devices. Haidian District, which is one of the most developed and active places in central Beijing, is selected as our study area. Our proposal is entirely implemented with public vector data and non-commercial software. The raw vector data we use are the excerpt dataset of Beijing from OSM [98].

1. Road Network

To begin with, we extract the road skeleton as the basis of the segmentation since it can represent the most meaningful borders of the city. We imported the raw data into a PostgreSQL [99] database with the support of PostGIS [100] (a geospatial extension to PostgreSQL) and picked six main road categories by their labels to compose the rough road network. They are motorway, trunk, primary, secondary, tertiary, and residential, respectively. Other road types are excluded as they are excessively detailed. The result is as shown in Figure 8.

2. Polygonization

Polygonization is the process whereby we can derive region polygons from road lines. The main idea of the method we take [101] is that, since the input line objects are elementary units for computing polygon objects, short and small lines will favor the construction of more and precise polygons. Therefore, road lines are broken into the smallest fragments (each fragment contains only two points) as the raw materials for the polygonize function provided by Shapely [102], a python package for computational geometry. As we can observe from Figure 9, after the polygonization, all the objects become enclosed polygons, and lines that cannot form polygons are removed.

3. Blocks

As can be seen from the output of the preceding step, as the by-products of polygonization, a number of undesired tiny cells are generated, and some of them are even too small to be discernible. To resolve this problem, we calculate the area of all polygon objects and filter the tiny ones out (less than 0.01 km${}^2$ as the general criterion). Then we merge them with the larger polygon that encompasses or adjoins them. The basic rules of merging operations are: (1) Regularity: In the premise of not damaging the main road lines, if one tiny polygon touches with multiple bigger ones, we will choose the way which makes the shape of merged polygon as regular and simple as possible. (2) Symmetry: To deal with tiny polygons that are generated around parallel roads or intersections, we will refer to the central line of the road or the central axis of interaction and merge them with the bigger polygons on the same side. (3) Consistency: If a merging operation is done, it will become the reference for the rest along the same road or direction, to make the overall merged boundaries continuous and smooth. These operations are done in QGIS [103], a free and open-source, yet powerful GIS suite. Upon the completion of merging, block regions are derived (Figure 10), which are regions of the finest granularity.

4. Subdistricts and Communities

Because we expect that our map segmentation method can reflect administrative features, employing existing administrative boundaries will be the ideal choice. However, the districts, whose boundaries are off-the-shelf from the OSM vector data, are oversized for capturing the mobility of users. So administrative subdivisions on a smaller scale are desired. However, unlike some other countries, in accordance with laws and regulations of China, boundaries smaller than districts are not released officially. To address this issue, with the associated information of streets and subdistricts [104], we approximately determine the borders of subdistrict regions through joining the block polygons (Figure 11).

Subsequently, to form a hierarchy, we should construct another level between the block layer and the subdistrict layer. Likewise, we produce such level via joining the block regions. For the sake of better practical significance, the joining operations abide by the following principles: (1) The size of these regions should be in the middle of the blocks and the subdistricts; (2) they should keep the subordination relationship with the upper subdistrict boundaries; (3) contiguous block regions that have empirical social ties should be joined together as a priority. The result of the new layer is shown in Figure 12. The scale of this layer can be analogous to the communities. As it can be seen from the statistics in

Table 1. The statistics of map segmentation.

Layer	Number of Regions	Area Size (km${}^2$)
subdistricts	29	10.238 ± 10.97
communities	155	1.965 ± 1.002
blocks	435	0.708 ± 0.882

, the three layers are well differentiated in terms of size and form a reasonable hierarchy. Roughly speaking, each subdistrict contains about 3–5 communities and one community contains about 3–4 blocks, which conforms to the actual situation to a large extent. Moreover, as the aim of the map segmentation is to serve content retrieval, we hope that it would support the multi-hop relay progress as well. Since the community layer is at the intermediate level, it should be capable of reflecting some invariability, i.e., accommodating movements and data exchange happened in a small range. Given that the typical communication range of nodes in VANET can be up to 300–500 m [105], the diameter of derived community regions is approximately 2–3 km, so 4–5 hops of forwarding are possible inside one community region at least, which we think is appropriate. Up to this point, the generation of hierarchical map segmentation is finished.

5. Naming

Only with a simple naming convention can regions be easily and uniquely identified in practical use. Meanwhile, it should also be hierarchically appropriate to make this naming consistent with the three-layer map segmentation. We make use of the administrative division codes for statistical use [106] (ADC), published by the National Bureau of Statistics of China, as the foundation for naming. As Figure 13 demonstrates, the ADC of a subdistrict region is a 12-digit number. Following this naming pattern, we append two digits to the subdistrict names for community names, and two more digits to the community names for block names. The general order of the encoding is from west to east and north to south. To be more specific, the region at the northwest corner is labeled as number one. Then we sequentially designate serial numbers to the regions along the horizontal direction until reaching the east border. Then the next number is given to the region which lies adjacent to region number one in the south, and so forth. In this way, the hierarchical relationship is implicitly involved in names. The name of a region in the upper level can be inferred directly from the names of smaller regions it covers.

6. Local Database

To support the access of regional information continuously with real-time GPS coordinates under the offline mode, we develop a local database based on SQLite [107] and Spatialite [108] (an extension to SQLite with advanced spatial capabilities). The database is a compact single file of only about 5 MB. Regardless of the platform, as soon as one node is configured with SQLite and Spatialite, the file can be copied to the node and it is ready for use. We have tested the access performance on Intel Galileo board (Intel Quark SoC X1000 400 MHz, 256M DRAM) and it only takes about 0.25 s for one query. This database is combined with the map interface as the map adaptor module. The overall picture of the steps stated above is shown in Figure 14.

3.4. The Routing Scheme Based on Map Segmentation and Movement History

Based on the map segmentation presented in the previous section, we designed a straightforward routing scheme, yet it is adequate for validation and testing purposes.

The design is partly inherited from our former work [109], which takes advantages of square regions to capture the movement patterns of people and take them as a basis to predict contact chances in the near future. Since we primarily focus on the retrieval of spatial-related contents, which are commonly location-dependent, a node that is more probable to pass the target location can be regarded as a better carrier, so we will keep going along this direction.

Compared with [109], while preserving the basic idea, we make major changes on three aspects:

• We use realistic administrative regions originated from map segmentation instead of simple square regions to characterize the movement of nodes.
• The emphasis of routing design is transited from EID-based (identifier of nodes) to region-based as we do not intend to contact certain nodes, but to expect to acquire demanded contents along the path to certain locations.
• Besides regular bundles, we also support BPQ-enabled request and response bundles to achieve bi-directional, name-based, and on-demand content retrieval.

Accompanying the movement, the node obtains its current GPS position at a periodic interval of 5 s. By querying its position through the map interface, regions where the node lies are obtained. Thereby, we project the detailed trajectory onto a sequence of subregions, which is more friendly for comparison and maintenance. The local recorded history of passed regions is not merely for self use. Upon a link establishment, two nodes will exchange this information in the form of a normal bundle. A node can only learn the history regions of its direct one-hop neighbors, and such knowledge of a certain neighbor will be updated to the latest state only when that neighbor is encountered again.

Correspondingly, we add new fields indicating the source and target regions of the bundle in the bundle header. As we partition the map into multiple layers with different granularities, the region on every layer that encompasses the given location is recorded. The source regions are those from which the bundle originates. To be more specific, for query bundles, they are where the request is issued, while for a response bundle, they are where the successful content matching happens. Beyond use in forwarding, this information can reflect the spatial distribution of content supply and demand to some degree. On the other side, regions for which the bundle is destined are target regions. Potential candidates of target regions include, but are not limited to: publicly known locations of road side unit (RSU), possible regions where contents could be found indicated by received response bundles, or locations that are highly correlated with the demanded contents (e.g., updates on traffic or weather condition, or photographs and short videos from the scene of an incident). With designated target regions and collected regional movement history, the routing strategy will make efforts to take bundles to gradually approach their destinations by selecting the next hops that have get closer to the finer target regions.

With the movement trajectories represented by a sequence of regions, the mobility pattern can be learned. However, how to accurately identify the regularity of mobile nodes is also a sophisticated research problem. There are numerous works that investigate this problem with respect to frequency, recency, or optimality, etc. Due to its complexity, this problem is beyond the scope of this paper. Here we put an emphasis on showing the ability of Geo-DMP on the support of region-based routing strategy. If a better mobility pattern can be derived via analysis of history regions, it can be applied to Geo-DMP as well. So we presume that all of the moving nodes have strong regularity, i.e., they move along their predefined routes back and forth just like buses or trams. Based on this premise, the history regions across which a node has moved are limited and the node will certainly revisit these regions at least several times.

As mentioned earlier, an outstanding feature of the administrative subdivision method is that it can surround the daily activities of people’s lives, i.e., one will stay or move about within one single region for a long stretch of time. Therefore, it is reasonable that we make the assumption that the requester will not leave the community region where it sends out the query bundles. As a result, once a query bundle triggers the generation of a response bundle, the target regions of this response bundle can be set to the source regions of that query bundle. With reference to the target regions of the query bundle, as the query bundle is probably satisfied by intermediate caches during the forwarding process, they are not meant for the place to which it must be delivered but just suggest where the demanded content could definitely be found as a last resort. Here they are set to the location where the RSU resides. How to intelligently determine the appropriate target regions by DTN itself is another of our intriguing research problems.

For the sake of brevity, in the following description of routing strategy, the forwarding process of a query bundle is taken as the example. The same goes for a new response bundle. The query bundles are forwarded in a single-copy fashion. We suppose that a query bundle B is created on node $N_a$, whose destination regions are $r_1/r_2/r_3$ in a top-down view where the subscript indicates the level. $N_a$ makes its decision on whether it should forward bundle B to one of its neighbors according to Algorithm 1. For a concise expression of the algorithm, we denote $R=\{r_i|i=1,2,3\}$, and $N_c$ as the current best candidate node for next hop and its initial state is set to local node $N_a$. Then each neighbor $N_i$ is compared concerning the relation between visited regions and target regions. The comparison result can be categorized into several cases:

Case I: Neither $N_c$ nor $N_i$ has visited any regions in R (lines 9–16)

We notice that, within a period of time after the creation of bundles, the source node may scarcely be able to meet eligible next hop due to the long distance away from the target regions or because most nodes have not accumulated enough knowledge about their movement pattern at the early stage of the experiment. To mitigate the influence of this cold-start problem, the first task is to make bundles start to move towards the right direction as soon as possible. So in this case, we measure the distance between the regions they have been to ($V_c$ and $V_i$) and the smallest target region $r_3$. The distance between two regions is defined as the straight-line distance between the two centroids of them. As the purpose of these measurements is to roughly determine which one is more likely to move on the right direction, a small number of simple calculations is enough. If one node has traveled across many regions already, calculations can be confined to history regions in a single layer. Such elasticity is easy to achieve according to the length of region ID. The $N_i$ will become new $N_c$ if it has the minimum distance.

Case II: Either $N_c$ or $N_i$ has visited the region(s) in R (lines 17–20)

In this case, one side has evidence that it has been to at least one region in R while the other side does not. Thus, obviously the one whose known trajectory goes through the target regions should be selected as the bundle keeper as it is more likely that it will bring the bundle there.

Case III: Both $N_c$ and $N_i$ have visited the region(s) in R (lines 21–29)

To decide which node has superiority over the other one when both of them declare that they have been to the region(s) in R, we follow the principle that, intuitively, the node that has reached the target region on a deeper level can be expected to get closer to the content. According to the result of the intersection of $V_c$ and $V_i$ with R, if $V_i$ overlaps R to a greater depth than $V_c$, $N_i$ is qualified as the next best candidate. By this means, the bundle will gradually approach the destination.

Algorithm 1 The routing scheme based on map segmentation and movement history

1: $N_c\leftarrow N_a$ 2: for each node $N_i$ that has an active connection with $N_a$ do 3:  if $N_i$ is the destination of B then 4:   deliver B to $N_i$ 5:   break 6:  end if 7:  $V_c\leftarrow getVisitedRegions(N_c)$ 8:  $V_i\leftarrow getVisitedRegions(N_i)$ 9:  if $(V_c\cap R=⌀and{V}_i\cap R=⌀)$ then 10:   $d_c\leftarrow computeShortestDistance(r_3,V_c)$ 11:   $d_i\leftarrow computeShortestDistance(r_3,V_i)$ 12:   if $d_i<d_c$ then 13:    $N_c\leftarrow N_i$ 14:   else 15:    continue 16:   end if 17:  else if $(V_c\cap R\ne ⌀and{V}_i\cap R=⌀)$ then 18:   continue 19:  else if $(V_c\cap R=⌀and{V}_i\cap R\ne ⌀)$ then 20:   $N_c\leftarrow N_i$ 21:  else if $(V_c\cap R\ne ⌀and{V}_i\cap R\ne ⌀)$ then 22:   $l_c\leftarrow maximumlwhere{r}_l\in V_c\cap R$ 23:   $l_i\leftarrow maximumlwhere{r}_l\in V_i\cap R$ 24:   if $l_c<l_i$ then 25:    $N_c\leftarrow N_i$ 26:   else 27:    continue 28:   end if 29:  end if 30: end for 31: if$N_c\ne N_a$then 32:  forward B to $N_c$ 33: end if

4. Experimental Validation and Evaluation

4.1. Emulation Platform

DTN-related experimentation has been a long-standing challenging task, largely owing to the fact that conditions like short-lived contacts and multi-hop transmissions are too costly to provide in laboratory environments. As a hybrid approach between virtual simulation and physical testbed, emulations are viable for indoor spaces and its support for real codes can yield more convincing results. An emerging trend in emulation is that virtual nodes gain ever-growing attention and widespread adoption for their better scalability and deployability. In this paper, we propose a decentralized and lightweight emulation platform based on virtual machines (VM), as VM with a standalone kernel and network protocol stack offers the capability to thoroughly examine the implementation and a higher degree of fidelity [110] compared to the kernel-based containers.

Unlike the majority of works on emulation which assign a dedicated central controller to govern the evolution of network topology [111,112,113], inspired by several works in ad-hoc networking [114], we leverage the “Link Emulator” module to make each node automatically manage its own links and hence it becomes an autonomous entity in the experiment progress. Only a simple document that records positions is necessary for a node to virtually move accordingly.

Each node is instantiated as a VM running an Ubuntu distribution. All nodes are interconnected via LAN. To settle the time synchronization problem, a “starting pistol” node is set up to launch the initialization script and time adjustment with an NTP server on every DTN node almost simultaneously with “Parallel SSH” [115] tool. Afterwards, this node will not intervene in the experimental process and other DTN nodes will behave independently.

4.2. Validation in Simple Scenarios

We first present several experiments in simple scenarios to validate the feasibility and usability of the implementation. The movement of nodes is orchestrated to create the planned contact chances. The contents requested are vector map tiles and in future we will support more types of informative geographical data that can be overlaid on maps.

4.2.1. Validation of Delay-Tolerant Multi-Hop Content Retrieval

Figure 15 illustrates the scenario for experiments in this part. We took a portion of a bus route at the northwest of the third ring road of Beijing from the OSM dataset (osmid: 2094880) as the track. Four nodes participate in these experiments: two mobile nodes plus two stationary nodes. The mobility pattern of these nodes is listed in

Table 2. The movement pattern for experiments in Section 4.2.1.

	Node	Node 1	Node 2	Node 3	Node 4
Time
0–30 s		Stationary at A	Stationary at C	Stationary at C	Stationary at E
30–230 s		Stationary at A	Moving from C towards B	Moving from C towards D	Stationary at E
230–430 s		Stationary at A	Moving from B towards C	Moving from D towards C	Stationary at E
430–630 s		Stationary at A	Moving from C towards B	Moving from C towards D	Stationary at E
630–830 s		Stationary at A	Moving from B towards C	Moving from D towards C	Stationary at E
830–1030 s		Stationary at A	Moving from C towards B	Moving from C towards D	Stationary at E

. Thirty seconds at the very beginning are reserved for the initialization of nodes and the creation of query bundles. Node 1 acts as the requester and Node 4 is the RSU. They stay motionlessly at point A and E, respectively. Point C is the rendezvous point of Nodes 2 and 3. Node 2 moves between points B and C, while Node 3 moves between points C and D. The communication range is set to 300 m. Next, we conduct experiments in three situations with different distributions of the requested contents.

1. No Intermediate Cached Contents

In this experiment, there are no cached contents on Nodes 2 and 3. All contents have to be retrieved from Node 4. The time sequence of transmission events is shown in Figure 16. The descriptions of the process are as follows:

• Before 30 s: Initially, Node 1 generates a series of query bundles whose source regions are those where it resides, namely $R_1$, $R_2$, and $R_3$, and target regions are those where Node 4 resides, namely $T_1$, $T_2$, and $T_3$.
• About 200 s: Shortly after that, when Node 2 passes by Node 1, according to the routing strategy, because Node 2 comes from $T_1$ while Node 1 falls outside all target regions, these queries are transferred to Node 2.
• About 400 s: Then Node 2 moves to point C and meets Node 3 there. As Node 3 has been to $T_3$ which is the target region on a deeper level than $T_1$, the only target region visited by Node 2, so Node 3 succeeds Node 2 to become the carrier of the queries.
• About 600 s: Node 3 continues to carry the queries until it reaches $T_3$ and delivers them to Node 4. When corresponding response bundles are generated at Node 4, since neither of Node 3 and Node 4 has visited any of their target regions, i.e., $R_1$, $R_2$, and $R_3$, they compare the minimum distance between their history regions and $R_3$. As can be observed from Figure 15, for Node 3 this value is the distance between $M_3$ and $R_3$. It is shorter than that of Node 4, which is the distance between $T_1$ and $R_3$. As a result, Node 3 obtains all contents from Node 4 and turns around to point C.
• About 800 s: When Node 3 gets in touch with Node 2 again at point C, because Node 2 has moved across $R_3$ while Node 3 has no chances to any of the target regions of response bundles, the contents are forwarded to Node 2.
• About 1000 s: Finally, on Node 2’s path returning to B, the responses are successfully delivered to Node 1.

This experiment proves that the system works properly on regular opportunistic multi-hop content retrieval from the data source. In the following two situations, the reasons why forwardings can happen under instructions of the routing scheme will not be explained repeatedly because they share the same mobility pattern.

2. Full Intermediate Cached Contents

In this experiment, we aim to ascertain if caches at a nearby place could be utilized. All contents requested by Node 1 are cached at Node 3 in advance. According to the temporal results in Figure 17, after the first round of movement of Node 2 between point B and C (about 400 s), all queries can be satisfied at Node 3. Consequently, responses are delivered to the requester in less time and fewer hops (about 600 s), which coincides with our expectation.

3. Partial Intermediate Cached Contents

This experiment is a combination of the two situations above: partial contents are cached at Node 3, while the remainders could only be found at Node 4. Referring to Figure 18, we describe the interactions between nodes as follows:

• About 200 s: Firstly, Node 2 takes all query bundles from Node 1.
• About 400 s: Node 2 and Node 3 come together at point C. Node 3 matches some queries from Node 2 with its local cached contents and gives the responses back to Node 2, then it carries the unfulfilled queries towards the RSU. Node 2 goes back to point B with those response bundles.
• About 600 s: Node 2 brings the first batch of responses back to Node 1. Almost at the same time, Node 3 gets the rest of the requested contents from Node 4.
• About 800 s: Node 2 and Node 3 meet at point C again. At this time the rest of the responses are unloaded from Node 3 to Node 2.
• About 1000 s: Finally, the second batch of responses are delivered to Node 1.

This experiment verifies that a number of queries issued at one time can be satisfied by different content sources, and responses are supported to be returned to the requester separately.

4.2.2. Validation of Delay-Tolerant Client Visualization

As confirmed in the previous part, contents can return from multiple sources at different times. The next question is, from the standpoint of the user, whether they can be collectively and correctly visualized in the browser across a prolonged time duration. Recall that as one advantage of gateway-based implementation, the terminal is not required to be aware of the DTN and only a little adjustment is enough for our purpose. In our implementation, through tuning the parameter of response timeout of the browser, the responses returned at a later time will not be dropped.

In this experiment, we imagine that a user without network access is in need of a map of his surroundings. The map data is retrieved from several other nodes in the form of vector tiles which are data units that we propose in our former work [32]. Seven nodes take part in and their contacts are prearranged. Node 1 acts the requester and Node 7 is as the RSU. In order to achieve the effect of queries being satisfied by multiple sources, we put one-third of the requested contents on Node 2 and one-third on Node 3 in advance, assuming that they have received these contents beforehand. The remaining one-third has to be fetched from Node 7. The bundle exchanges are shown in Figure 19. To make the result more clear, the details of each batch of returned contents are summarized in

Table 3. Summary of returned contents in validation of delay tolerant client visualization.

Batches	Return Time	Route
#1	about 10 min	Query: $N1\to N2$ Response: $N2\to N1$
#2	about 65 min	Query: $N1\to N2\to N3$ Response: $N3\to N2\to N1$
#3	about 115 min	Query: $N1\to N2\to N3\to N4\to N7$ Response: $N7\to N4\to N5\to N6\to N1$

. As we can see from the screenshots of the browser in Figure 20, the vector map incrementally becomes complete. This verifies that the client-side can support delay-tolerant content retrieval and visualization.

4.3. Experiments in Comprehensive Scenarios

In this section, we discuss the extensive experiments on Geo-DMP in a more realistic and comprehensive scenario. An approximate square area of 3 km${}^2$ near Zhongguancun, Haidian District is selected as the movement range of nodes. Ten nodes participate in the experiments, whose traces are excerpted from T-drive [116], a dataset that contains real-world trajectories of taxis. Nodes move along their own path repeatedly for two rounds in each experiment execution and their contacts are not planned beforehand. The one-way travel time ranges from 20 to 40 min. We create different conditions for every group of experiments by replacing all the traces of nodes. The movement range and one example set of traces are given in Figure 21.

First, we evaluate the performance of Geo-DMP when only a single content source is available. Node 1 acts as the user and Node 10 is the RSU, while others are relay nodes. According to the variation of the communication range and whether nodes have knowledge of their own movements in advance, four cases in one group of experiments are given in

Table 4. The cases with different conditions.

	Communication Range	With Movement Knowledge at the Initial State
Case A	300 m	No
Case B	300 m	Yes
Case C	600 m	No
Case D	600 m	Yes

. We ran 10 groups of experiments altogether.

4.3.1. Without Intermediate Cached Contents

As seen from Figure 22, except for Case B, in most situations (over 80% on average) we can accomplish the two-way deliveries. As there is no contents cached on intermediate nodes, queries could only be satisfied by RSU after they are brought to their smallest target region. Likewise, only when the responses are routed back to the requester can the deliveries be successful. Hence, the high delivery ratio reveals that the multi-layer segmented regions can appropriately profile the movement of nodes. During the process of bundles approaching their target regions, they can serve as a valuable reference for selecting proper next hops under realistic scenarios. Moreover, in agreement with intuition, the enlargement of communication range contributes to more successful deliveries as many new contact opportunities emerge. All in all, we confirmed that we achieve our goal to design and implement a prototype that supports cooperatively retrieving named geospatial data units across intermittent links and a long time span.

Next, we present an analysis of the decline of delivery ratio when nodes have knowledge of movements in advance. We deem that this decline can be ascribed to the underutilization of the movement history so far. According to our investigation of some delivery failures, if both nodes report that they have visited the smallest target region, the current routing protocol is unable to judge which one is superior. The consequence is, bundles will be forwarded to the one showing up first. But sometimes that intermediate node fails to get in touch with the destination node after it enters the smallest target region. Two reasons may account for this phenomenon. The first one is, due to the limitation of the experimental condition, the amount of nodes and executed experiment sets did not suffice to dilute the impact of the characteristics of the selected trajectories. The second one is that, as the communication range is a variable, it is very likely that there is a mismatch between region size and communication range. When the communication range becomes smaller, this problem will get more severe. That is why the problem looks more evident for case B than case D. We recognize that two nodes coming to the same finest target region and two nodes being able to contact with each other are not absolutely equivalent. Similar to the classical “last mile” problem, although target regions can indicate correct forwarding directions, additional strategies should be conceived for the “last hop” problem.

With respect to hop counts and average delay, as we can see from Figure 23 and Figure 24, case A with smaller communication range and without initial movement knowledge takes the longest latency and the highest forwarding hops to retrieve contents from the RSU. In case C, with a larger communication range, nodes can more easily find an eligible next hop, leading to a decrease of both delay and hop counts. The movement knowledge shows its advantage in case B and D. The average delay of case B reduces to about 50% of that in case A, while the average delay of case D is about 70% of that in case C. The reason for substantial savings in time consumption can be explained by the initial movement knowledge eliminating the need to collect visited regions from scratch. The awareness of the places in the path enables nodes to more easily and quickly find a better, even the best, next hop. Meanwhile, for the same reason, fewer hops of forwarding are required for deliveries in case B and D compared with case A and C.

4.3.2. With Intermediate Cached Contents

In this part, we study the effect of intermediate caches in the content acquisition process. We select six sets of trajectories by which the contents can be delivered successfully in the previous experiments. For each set of trajectories, we initiate the new experiment based on the results of the former one. To put it more clearly, the experiment without intermediate caches is executed prior to the new experiment to bring contents to some nodes in preparation. Except for Node 1, Node 10, and nodes that possess the cached contents, the other nodes will play the role of the requester in turn, in separate executions.

Because in former experiments, contents are mostly forwarded back to the requester in two or three hops, not too many nodes will have cached contents. However, we think that, in reality it is quite common that demanded contents are scattered over surrounding areas. Many factors could be the cause of this: the lower popularity of the contents, the unwillingness of some users to expose their cache to the public, or limited support of BPQ mechanism among DTN nodes.

We categorize the results by where the contents are retrieved from in Figure 25. As it can be seen, when the communication range is 300 m, due to cached contents only existing on a few intermediate nodes, other nodes have rather limited chances to discover them, so a large portion of the requests is still fulfilled by RSU. Despite this, cached nodes can contribute nearly a half of successful retrievals, which implies that Geo-DMP is capable of effectively utilizing a moderate amount of cached contents to markedly reduce the unsuccessful retrievals and promote retrieving contents from nearer locations compared to experiments without caches in Figure 22. With the communication range up to 600 m, we observe that the number of requests fulfilled by caches decreases a little instead. The reason for this is that, as stated before, larger communication range will create more contact opportunities and hence intermediate nodes can more easily contact with better next hops, even the RSU. So there is a tendency that forwardings are preferred to the direction of the RSU and the role of intermediate caches will inevitably be diminished.

To close this section, we sum up the extensive experiments presented above in brief. Firstly, we prove the framework of Geo-DMP works properly and correctly on delay-tolerant content retrieval in a simplistic scenario with different cache distributions. Secondly, with a more realistic scenario and trajectories of nodes, we show that the delivery ability of Geo-DMP is acceptable for most cases, and the movement history information can help to select proper next hops as well as reduce average hops and delays. Thirdly, we discuss the reason behind some delivery failures for potential amelioration of our region-based routing strategy. Finally, we validate that Geo-DMP can leverage a small amount of intermediate caches to have a remarkable positive effect on the overall efficiency.

5. Conclusions and Outlook

In this paper, we present Geo-DMP, a mobile prototype system supporting the sharing and exchanging of geospatial contents in an opportunistic, distributed, and collaborative way. The framework of Geo-DMP consists of a full DTN protocol stack, a “content agent” module, and a “map adaptor” module. DTN and its BPQ mechanism are employed as the foundation for their capabilities of identification, matching, and multi-hop delay-tolerant forwarding of named contents. Then we follow the “gateway-based” communication paradigm to develop the “content agent” module to break the isolation between non-DTN nodes and DTN-aware nodes. To extract the concise mobility pattern of users from their movements for the purpose of routing, we present the “map adaptor” module, which provides real-time regional information based on the product of our proposed multi-scale map segmentation scheme. Next, to accomplish a complete content retrieval process with the framework of Geo-DMP, we explore the design of a pure region-oriented DTN routing scheme which is tailored for real-life spatial environments. The full implementation is thoroughly verified on the emulation platform composed of VMs. Through experiments on real-world trajectories in realistic scenarios, we can conclude that with Geo-DMP, the requests of named spatial contents can be directed to and fulfilled by distant content sources via transient connectivities and cooperation of DTN nodes, and the requester can utilize the responses which are routed back across a long time period. We also find that intermediate cache resources can be efficiently exploited by Geo-DMP to lessen the reliance on content originators, reduce unsuccessful retrievals, and enhance overall delivery performance.

Despite the achievements, we are also conscious that there is still much room for improvement. The potential directions include: large scale experiments with physical embedded devices in real environments; improving the design of routing protocol by better exploiting the knowledge of historical movements and intelligent determination of target regions; and exploring a more programmatic way to automate processing or calibrating the road network and trajectories of nodes.

In addition to the enhancements of the system itself, we will also seek to broaden the applicability scope of Geo-DMP. Two possible ways could be suggested: First, supporting the retrieval of more manifold timely or customized geospatial contents such as emergency event warnings, safety cautions (e.g., road surface anomalies or accident prone road sections), weather updates, or POI (point-of-interest) recommendations; and second, better integration with crowd-sourcing services to assist efficient harvesting and sharing of up-to-date as well as valuable location-aware information around us.