Query-response geocast for vehicular crowd sensing

ARTICLE IN PRESS

JID: ADHOC

[m3Gdc;June 27, 2015;9:7]

Ad Hoc Networks 000 (2015) 1–15

Contents lists available at ScienceDirect

Ad Hoc Networks journal homepage: www.elsevier.com/locate/adhoc

Query-response geocast for vehicular crowd sensing Julian Timpner∗, Lars Wolf Institute of Operating Systems and Computer Networks, Technische Universität Braunschweig, 38106 Braunschweig, Germany

a r t i c l e

i n f o

Article history: Received 19 November 2014 Revised 29 May 2015 Accepted 8 June 2015 Available online xxx Keywords: Crowd sensing Query response Geocast VANET V2V Routing

a b s t r a c t Modern vehicles are essentially mobile sensor platforms collecting a vast amount of information, which can be shared in vehicular ad hoc networks. A prime example of a resulting vehicular crowd sensing application might be the search for a parking spot in a specific geographic area. The interested vehicle sends a corresponding query into the destination area—a technique known as geocast. As the query originator, however, is likely to have moved relatively far away from the location from where the query was started by the time the response arrives, an efficient routing approach towards the originator is required. In this paper, we extend the Breadcrumb Geocast Routing (BGR), a georouting protocol for vehicular networks that is able to close this functional gap. We introduce several performance improvements. In particular, we focus on further reducing both the delivery delay and network overhead and on the dynamic adaption of breadcrumbs to the street layout, node density and other scenariospecific parameters. Extensive simulations in four different urban scenarios show a significant improvement on BGR, especially in terms of delivery delay, which can be reduced by an average of 24%. Breadcrumb Geocast Routing Version 2 (BGR2) thus not only avoids up to 93% of the traffic overhead of Epidemic, but increases the delivery rate of the underlying georouting protocol significantly from about 48% to almost 100% even in difficult scenarios. In sum, it is shown that BGR2 and breadcrumbs in general are a feasible and efficient approach for the routing of query responses to moving nodes via geocast, enabling a variety of vehicular crowd sensing applications. © 2015 Elsevier B.V. All rights reserved.

1. Introduction It is envisioned that there will be more than one billion connected vehicles roaming the streets by 2020 [1]. With the proliferation of automotive ad hoc communication1 and sophisticated sensor systems, a vast amount of information becomes available to enable a plurality of new cooperative services in Intelligent Transportation System (ITSs), including traffic management, electronic toll collection, safety, and infotainment. While many applications already make use of locally available sensors, e.g., radar for distance warning, only ∗

Corresponding author. Tel.: +49 531 391 3154; fax: +49 531 391 5936. E-mail addresses: [email protected] (J. Timpner), [email protected] (L. Wolf). 1 http://www.car-to-car.org/

few actual applications use sensor information from remote systems. Primarily, vehicular networking research has been focused on developing vehicular safety communication systems. Naturally, the automotive industry and governments worldwide see safety applications (based on a proactive communication model), such as collision avoidance, as an effective means to reduce traffic accidents, fatalities, and, in case of the industry, through advanced driver assistance systems to set themselves apart from competitors [2]. Beyond the initial focus on vehicular safety applications, though, a reactive (i.e., query–response) model indeed allows “exploiting the wisdom of the crowd” [2] by requesting specific information from any number of vehicles even over larger distances. This information may not need to be subject to large-scale dissemination as it might either be of specific interest only or consume both too much bandwidth and processing power in

http://dx.doi.org/10.1016/j.adhoc.2015.06.003 1570-8705/© 2015 Elsevier B.V. All rights reserved.

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC 2

ARTICLE IN PRESS

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

the network, e.g., sharing image data for up-to-date streetview impressions. As these data are not time-critical and since there is often no end-to-end path between two vehicles willing to share data in the first place (due to the highly dynamic structure of vehicular networks, for instance), a Delay/Disruption-Tolerant Network (DTN) following a store-carryforward approach is required. A prime example of a resulting vehicular crowd sensing application might be the search for a parking spot in a specific geographic area. The interested vehicle sends a corresponding query into the (stationary) destination area—a technique known as geocast. As the query originator, however, is likely to have moved relatively far away from the location from where the query was started by the time the response arrives, an efficient routing approach towards the originator is required. Typical approaches are to flood the network or to guess a destination area large enough that it might still include the originator, both of which do not scale well. 1.1. Contributions of this paper This paper builds on previously published work [3]. The prior work presented a novel approach for routing responses to a moving query originator—the BGR protocol. Originators leave a trail of floating content [4] areas, which we refer to as breadcrumbs and which can be used to efficiently forward the response to its destination. As BGR can be used on top of different (existing) georouting mechanisms, it adds an efficient means to address moving originators even to protocols formerly ignoring the problem. In this paper, we significantly extend our previous work summarized in Section 3 by (a) a detailed analysis of room for improvement and deriving multiple new protocol features in Section 4, (b) an expansion of the simulation environment, including twice as many scenarios covering a variety of urban theaters of operation and adopting default settings to better match related work on IEEE 802.11p, as well as (c) an extensive evaluation of the proposed protocol features, both separately and in combination, in Section 5. Finally, we combine the results to derive a proposed update to the protocol as BGR2, which we investigate in comparison with the original BGR as well as several reference protocols, showing major improvements in terms of delivery delay, message overhead, and applicability to various street layouts. Naturally, we extend the investigation of prior work in Section 2 to include the latest state-of-the-art with regard to both vehicular georouting and the new protocol features proposed in this work. 1.2. Outline The remainder of this paper is structured as follows. We begin in Section 2 by studying what other authors have achieved in this field and how it relates to our work. We define relevant concepts and summarize the BGR protocol in Section 3. We propose protocol extensions to improve the performance in Section 4. We describe the extended simulation setup and extensive evaluation results of the proposed features in Section 5. Finally, the paper concludes in Section 6.

2. Related work A plethora of routing protocols exists in the literature. In this paper, we therefore only consider research work focusing on the problem of georouting in the vehicular domain and, in particular, on the problem of routing messages to moving nodes.

2.1. Georouting A recent survey [5] of geocast routing protocols for Vehicular Ad Hoc Networks (VANETs) presents geocast protocols addressing the difficulties of this domain, such as “high mobility, frequent changes in topology, high and frequently variable density, long lifetime of nodes and regular moving patterns” [5]. However, none of the approaches solves the problem of sending replies to moving nodes, since they all require a static destination area [6–8]. Further, the source node has to be part of this area [9], which then becomes unnecessarily large if messages must overcome larger distances. BGR can be used on top of arbitrary geocast protocols, adding this missing capability. Geocast routing protocols in VANETs can further be categorized according to their primary target traffic environment, namely urban and highway. [10] Since BGR’s purpose is to support crowd sensing applications in urban environments, we thus focus on the former group. T-TSG [11] warns vehicles after an accident. It selects forwarding vehicles based on the traffic light situation. Although the dissemination of a warning message in a geographic region is similar to keeping breadcrumb messages alive in their anchor zone, T-TSG focuses on this step and only supports relatively small distances. Coverage-aware Geocast Routing (CAGR) [12] measures vehicles’ coverage capability to only forward messages to those with high delivery probabilities. Obviously, this requires all vehicles to have knowledge about their own trajectory as well as to collect and maintain trajectories of all encountered vehicles in order to compute a coverage graph. Although BGR can use trajectory information, it does not depend on it, as opposed to other works [13–15]. In [15], the authors use the route information from car navigation systems or, if available, the predefined routes (e.g., bus and tram routes) to route messages from vehicles to Roadside Units (RSUs). Vehicles exchange their intended route periodically. Further, the authors address the communication between a vehicle and an RSU, so destinations are fixed and known a priori. Vehicle Density and Load Aware (VLDA) [16] constructs a route based on real-time vehicle density, traffic load, and distance to the destination. Thus, messages are avoided being sent to areas with sparse connectivity and network load is balanced. Similarly, BGR makes use of real-time vehicle density to determine suitable routing parameters. Again, none of the abovementioned protocols takes routing of query responses to a mobile destination into account. Geographic Source Routing (GSR) [17] also proposes a routing strategy for VANETs in city environments. Yet, in order to find a vehicle’s position, it floods the network with a position request. Further, it requires digital map data for optimization purposes. BGR, in contrast, does neither flood the network, nor does it require digital maps.

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC

ARTICLE IN PRESS J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

GeoVANET [18,19] aims to provide a geocast protocol for query processing in vehicular networks. In the proposed protocol queries are disseminated via broadcast. Receiving vehicles then process the query and reply indirectly, i.e., the answer is not routed to the requester directly (whose position is unknown anyway) but to a rendezvous point, referred to as a mailbox. Eventually, the initiator of the query retrieves the responses from the mailbox, either by physically driving to within its communication range or by using the same georouting algorithm as in the step before. The latter, however, requires the vehicle to stop and not to move while the request is pending, which defeats the purpose. Similar to our approach, GeoVANET addresses the problem of routing messages to moving nodes by introducing stationary mailboxes. Additionally, our approach does neither rely on infrastructure nodes nor statically placed mailboxes, which induce the problem of finding suitable locations while the underlying network changes constantly. Another contrast to GeoVANET is that the query is not broadcasted in the network, but instead is directly routed into the relevant destination area. GeoDTN [20] addresses geographic routing in DTNs. It is based on a routing heuristic that relies on a mobility model which is determined by leveraging the past geographic movement patterns of surrounding nodes. To this end, nodes exchange the mobility vectors of their 2-hop neighborhood. The prediction of future connectivity (on which the assumption of the best hop to select is based), is likely to fail if nodes visit areas they have never been before or if there is no location history available. Moreover, the authors do not consider bidirectional communications. The problem of geographic routing with mobile destination nodes has been investigated in the Mobile Ad Hoc Network (MANET) community as well, e.g., in [21]. Yet, MANET routing protocols typically do not take the specific requirements of the vehicular domain, such as high speeds, urban scenarios, etc. into account. Accordingly, protocols such as AODV and OLSR either flood the network at some point or need to maintain routing tables, both of which are unfeasible in highly dynamic vehicular scenarios. Moreover, the authors only deal with an indoor scenario [21]. 2.2. Query processing Existing query-based contant sharing systems such as FleaNet [22] and Roadcast [23] disseminate queries only to one-hop neighbors. The receiving vehicles do not relay the message, but try to provide answers from local information. Hence, the query is only disseminated because of the query originator’s motion. Consequently, the problem of routing query results back to the originating vehicle does not arise. However, it significantly reduces the applicability of the approach, since it is not general enough to process queries over further distances. VITP [24] is an application layer protocol based on HTTP with support for both push and pull communications. The fully distributed ad hoc protocol allows the aggregation of data and only delivering summarized results. VITP-enabled peers in the area of interest cooperatively resolve the query, and return a reply. However, in order to transport the query into its destination area and in turn, transport the response back, any geographic routing can be used. This is similar to BGR routing, which also extends

[m3Gdc;June 27, 2015;9:7] 3

existing georouting protocols. Yet, VITP stipulates to extend the area over which the reply should be broadcasted if the querying node moves too far from the location from where it started the query. BGR, on the contrary, solves this problem more efficiently. However, it adopts VITP’s computation phase for organizing a single response message on the basis of information of multiple nodes inside a geographic area. In comparison, BGR neither requires all nodes to keep routing tables, nor any kind of infrastructure support, nor knowledge about vehicle trajectories or destinations. It therefore provides a versatile and lightweight extension to other geographic routing protocols. As the underlying geocast mechanism is exchangeable, a significant advantage of our approach is that it directly benefits from better or improved georoutings. 3. Background In Section 3.1, relevant concepts and notations are defined. We repeat the concept of breadcrumbs [3], which are based on the floating content [4] approach, in Section 3.2 to facilitate comprehension of the protocol phases in Section 3.3. BGR [3] is a geographic routing protocol that is not only able to send messages towards a destination area, but also to retrieve information from this area by efficiently routing the query responses back to the (moving) originator. 3.1. Definitions BGR is applicable in mobile environments, where vehicles (nodes) are equipped with ad hoc communication technology in order to form a network via Vehicle-to-Vehicle (V2V) communications. Benefits include that no infrastructure installations are necessary and that V2V communications are free of charge as opposed to cellular networks. Nodes may be interested in information that is not time-critical and corresponds to a specific geographic Region of Interest (ROI), such as road conditions (available parking spots, road works, congestion) and roadside services (restaurant menus, gas station prices, etc.). When a node requires such information, it sends a query into the ROI. While nodes in the ROI (the respondents) receive, process, and reply to the request, the query originator moves away from the original querying location, thus complicating the delivery of the responses. BGR addresses this problem by a best-effort strategy to efficiently find the originator. While BGR can be used on top of arbitrary geocast protocols (as explained in Section 3.3.1), we focus on the approach presented in [18] for evaluating BGR. In this approach, vehicles keep a message as long as they are getting closer to the message destination, which geocast inherently assumes to be stationary. Thus, when the distance to the destination increases, they forward the message to a neighbor moving towards it. All nodes are assumed to be able to determine their geographic position, e.g., via GPS. 3.2. Breadcrumbs In existing geocast approaches [7,24], if a query response is to be sent to a moving originator, the destination area has typically to be quite large to ensure that the originator is

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

ARTICLE IN PRESS

JID: ADHOC 4

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

when they leave. As long as they stay in the area, though, they keep a copy. At minimum, breadcrumb messages contain information about the position of the preceding breadcrumb (if there is one), the position of the successive breadcrumb, the IDs of all queries the breadcrumb corresponds to and the anchor parameters P, r, a. A potential problem is when all nodes leave a breadcrumb area, which would disconnect the breadcrumb trail. This is addressed by different strategies in the proposed protocol, as will be explained in Sections 4.1.2 and 4.3. Fig. 1. Breadcrumb structure.

3.3. BGR protocol still located within that area when the response arrives. Especially in a delay-tolerant environment, however, this approach has several disadvantages, since it leads to a high overhead (if many nodes are involved) or high loss of response messages (if the destination area does not include the originator). In this work, the originator leaves a trail of floating content [4] areas to ensure that responses can be routed towards it, even if it has already moved arbitrarily far away from its querying location. In analogy to a famous fairy tail2 , we refer to these floating content areas as breadcrumbs, since they are used to keep track of the originator’s location and facilitate efficient routing decisions. Technically, a breadcrumb is a set of copies of special messages with the same content, which are passed on to each node inside a well-defined and restricted geographic area. Hence, the content is kept alive in that area, independent from the actual nodes that are present there, until a certain condition is met or the message lifetime expires. Breadcrumbs are based on anchor zones, which are defined by an anchor point P, the anchor zone radius r, an availability threshold a and a Time to Live (TTL). Fig. 1 depicts the according zones and parameters. Let h denote the geodesic distance of a node N from anchor point P, which can easily be determined from GPS coordinates. As explained in Section 3.1, we assume that every vehicle is able to determine their geographic position. The distance h determines the probability pf that N forwards its floating content message (in the following referred to as breadcrumb message) to all its neighbors that did not already receive it (which can be efficiently tested using Bloom filters [25])



p f (h) =

1 F (h) 0

if h ≤ r if r < h ≤ a otherwise,

(1)

where F(h) with {h ∈ R : r < h ≤ a} is defined as

F (h) =

h−r . a−r

(2)

Consequently, the probability that a node discards a breadcrumb message from its storage, pd (h), is also depending on the distance h distance

pd (h) = 1 − p f (h).

(3)

This means that nodes outside of the breadcrumb area do not store breadcrumb information, but instead discard it 2 “Hansel and Gretel”, published by The Brothers Grimm in 1812, leave a trail of breadcrumbs while walking in the forest in order to find their way back home.

The protocol is divided into the following three phases. In the query phase, the originator sends a query from its current location into the destination area. This phase ends when any node in the destination area has received the query. In the response phase, the response from a node inside the destination area (e.g., chosen by the VITP protocol) reaches the querying location. In the tracking phase the response is forwarded along a trail of breadcrumbs until it has reached the originator. If, at any point in time, the TTL of the query or the response expires, the corresponding phase ends, and no subsequent phase is entered. The three phases are shown in Fig. 2. During all phases, each node broadcasts small 1-hop status messages, called beacons, for neighborhood discovery and location detection of neighboring nodes. In the following, the different phases are explained in detail. 3.3.1. Query phase When a vehicle requires information from a remote location, it sends a query message from its current location into the ROI, which is defined by a geographic center coordinate and a radius which determines the distance of the outline of the area to the center. To this end, traditional geocast [18] approaches are used. Fig. 2a depicts this phase. Note that the querying vehicle’s position is outside of the ROI, as regular geocast approaches without breadcrumbs would suffice otherwise. Immediately after transmitting the message, the originator sets up a breadcrumb message mi as described in Section 3.2 which will then be used to establish a breadcrumb i (i.e., a floating content area). Yet, the breadcrumb i is not dropped (the position in which the breadcrumb is dropped determines its anchor point, as depicted in Fig. 1) right away. Instead (and as depicted in Fig. 3), mi is (1) stored while the originator (2) moves along its path until (3a) the breadcrumb distribution strategy triggers another breadcrumb message mi+1 to be set up. Now, (3b) the stored breadcrumb message mi is updated with the position of the new breadcrumb i + 1 (which is to be dropped at the vehicle’s new current position). Because the originator already moved on and away from the anchor point of the old breadcrumb i, the stored breadcrumb message mi is geocasted to its anchor point and (4) breadcrumb i is established in the destination area. This process repeats as the originator moves along its path. The originator stops dropping breadcrumbs once it has received the response to its query or the maximum waiting time has been exceeded. In the latter case, the request is considered to be failed and the breadcrumb information

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC

ARTICLE IN PRESS J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

[m3Gdc;June 27, 2015;9:7] 5

Fig. 2. BGR phases.

Fig. 3. Creation and delayed dropping process of breadcrumbs.

is deleted. This delayed creation process has several advantages. First, it is ensured that a breadcrumb always has the correct information about its successor. Second, if the originator does not move away from the querying position, no breadcrumb is necessary and none will be dropped. Naturally, the question of where the next breadcrumb should be dropped arises. Since a problem similar to finding the optimal position was shown to be NP-hard [26], BGR drops breadcrumbs periodically after the originator has covered a certain (parameterizable) distance from the last breadcrumb or the querying location. This work, however, considers other dropping strategies as well, which Section 4.2.1 discusses in detail. Depending on the inter-breadcrumb distance, two special cases are possible. If only one breadcrumb (n = 1) has been dropped, this strategy is similar to Mobile IP [27], where a home agent’s address (location in our case) is known and can therefore be used to send and forward messages to a mobile node. In the second special case, multiple spatially-overlapping breadcrumbs (n → ∞) have been dropped. This effectively leads to a single extended geocast region, which is similar to existing approaches that choose arbitrarily large destination areas to reach nodes with unknown locations [7,24]. Yet, in comparison the breadcrumb approach would still be more efficient, since the destination area would be elongated along the actual vehicle path, as opposed to a circular extension in all directions. Anyway, we expect the general case in which the number n of breadcrumbs is 1 < n  ∞ to be more reliable and efficient, since a smaller number of nodes is involved in the transmission of a response. Hence, we focus on this case. The influence of breadcrumb parameters, such as size, number and distance on the success of message transmissions are evaluated in Section 5.3.

3.3.2. Response phase The response phase, as depicted in Fig. 2b, starts when the message has reached (the first node in) the ROI. Inside the ROI, the nodes respond to the message and merge their results into one message that contains all answers to the initial request. This can be achieved by adopting VITP [24], in which the response message is sent once a return condition is satisfied. It is sent (following the same geocast procedure as in the Query Phase) to the initial breadcrumb at the querying location. 3.3.3. Tracking phase Once a response has reached any breadcrumb that holds information about the originator of the corresponding query, the Tracking Phase (see Fig. 2c) begins. Any breadcrumb node receiving such a response message will replace the current destination area (which is the current breadcrumb) of the response message with the position of the successive breadcrumb. The node will then use a random backoff timer before trying to forward the response, thus minimizing the number of nodes forwarding the same message. Accordingly, the response is forwarded from the breadcrumb to its successor using a traditional geocast strategy. To be more precise, the response is forwarded to (and by) nodes that move between successive breadcrumbs. The breadcrumbs themselves are stationary, and vehicles are only part of a specific breadcrumb as long as they are in the corresponding area (see Fig. 1). As described in Section 3.2, vehicles that enter a breadcrumb area receive the breadcrumb information by vehicles that already are in that area, and delete this information once they leave the area. This forwarding continues along the trail of breadcrumbs, until the originator has received the response, as depicted in

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC 6

ARTICLE IN PRESS

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

Fig. 2c. After a node in a breadcrumb area has forwarded the response, the nodes of that particular breadcrumb can delete both the response and the tracking information. Thus, the breadcrumb disappears after forwarding the response (or at the latest, when the breadcrumb’s TTL is exceeded). If, however, all nodes move away from the breadcrumb area before the response has been forwarded, the breadcrumb information is lost. It is worth noting that it is not always necessary to pass through the entire trail of breadcrumbs, as each breadcrumb does not depend on its predecessor, but all successors. Consequently, whenever breadcrumb i receives a corresponding response, it will forward the message to breadcrumb i + 1; breadcrumbs < i will not be involved. Thus, a certain degree of resilience against a disconnected breadcrumb trail is introduced. Enhanced strategies to cope with this challenge, such as restoring or shortening a disconnected trail, are proposed in Section 4. 4. BGR2 Prior work [3] shows that BGR avoids up to 97% of the traffic overhead of Epidemic and PRoPHET, while increasing the delivery rate of an existing georouting protocol significantly from about 31% to almost 100%. It turns out that the breadcrumb size has the greatest impact on the performance of BGR, making it a key parameter for the trade-off between network traffic and delivery probability. The evaluation results show that BGR is a feasible approach for the routing of query responses to moving nodes via geocast. Yet, in this section, we identify room for improvement and explore several optimizations to the original protocol, especially to provide shorter end-to-end delays and more robustness in the challenging vehicular environment. Finally, the goal is to combine the most promising optimizations to derive an updated protocol BGR2, which we investigate in comparison with the original BGR as well as with several reference protocols in the next section. 4.1. Delivery delay The median delivery delay of BGR is about 2–3 times as high as the theoretical minimum achieved by Epidemic routing. In order to decrease the delay, we propose the following modifications. 4.1.1. Truncating trails One can assume that a high number of hops increases the overall delivery delay, as each hop implies additional processing, storing, etc. Thus, in order to decrease the hop count, the query originator sends a “truncate” message back along the trail of breadcrumbs. Thus, the “next hop” position of each breadcrumb can be updated, either to skip certain breadcrumbs, as shown in Fig. 4a, or to forward messages directly to the last known position of the querying vehicle (resembling a Mobile IP approach, see Fig. 4b). Consequently, the number of hops required to reach the query originator should be reduced. Note that the truncate message travels in the opposite direction of a response: the former is forwarded away from the originator, while the latter is forwarded towards it, as depicted in Fig. 4c. This is implemented by having each

Fig. 4. Truncating a breadcrumb trail.

breadcrumb store not only the position of its successor, but also of its predecessor. Potentially, though, the breadcrumb trail can have become disconnected, as explained in Section 3.3.3, making it impossible for the message to follow the trail to its beginning and, similarly, for a response to reach the originator. However, the originator can easily store all previous dropping locations and include these in the truncate message, which can then be forwarded to all breadcrumb locations even if the trail is disconnected. Further, it allows restoring a disconnected trail as explained in Section 4.3. A truncate message is sent every time a new breadcrumb is dropped. 4.1.2. Response fan-out Another option to shorten the delivery delay is for responding vehicles to not only send a response to the initial breadcrumb, but to fan out responses to multiple, adequate locations along the expected path of the moving originator, as depicted in Fig. 5. To this end, the query and response phases, as described in Section 3.3, would be modified accordingly, such that the querying vehicle appends its estimated path to the query, whereupon the respondent uses this information to determine additional destination areas to send the response to. In practice, the vehicle can estimate the path if the driver has entered his destination into the navigation system or by using context information (such as driving history, time, location). As the destination and trajectory information are not always available, though, BGR2 uses a more robust approach as described in the following. As stated above (see Section 3.3.3), responses are not required to pass through the entire trail of breadcrumbs, as each breadcrumb does not depend on its predecessor, but all successors. Consequently, whenever breadcrumb i receives

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

ARTICLE IN PRESS

JID: ADHOC

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

Fig. 5. Fanning out responses.

Fig. 6. Dropping breadcrumbs at locations with an above-average node density.

a corresponding response, it will forward the message to breadcrumb i + 1; breadcrumbs < i will not be involved and the delay can be reduced. Fanning out responses assumes that breadcrumbs will be available at the additional destination areas. As finding optimal dropping positions is NP-hard [26], this cannot be ensured in practice, which is why additional responses are sent to intersections while vehicles will preferably drop breadcrumbs at intersections as well, increasing the probability of responses hitting the breadcrumb trail. 4.2. Dynamic breadcrumb parameters It was previously shown [3] that the breadcrumb size s and the inter-breadcrumb distance d have a great impact on the performance of BGR, making them key parameters for the trade-off between network traffic and delivery probability. Yet, determining the optimal breadcrumb parameters is not trivial. If poorly chosen, breadcrumbs can get lost easily and responses cannot be delivered. In BGR, a static design decision was made, which worked well in the regular street layout of the San Francisco scenario, while being suboptimal in the more organic Helsinki scenario. It turns out that scenario characteristics, such as street layout, node density, etc. have a significant impact on the best breadcrumb parameters. Hence, they should be adapted dynamically. 4.2.1. Dynamic location Instead of dropping breadcrumbs in regular intervals, breadcrumbs can be dropped at locations with a high traffic density as shown in Fig. 6 increasing the probability of being kept available for a longer period. The originator determines the current traffic density φ as the number of communication partners in 1-hop range and calculates a moving average λφ of the previous nφ data (i.e., λφ is of order nφ ). We define di as the distance to the last dropped breadcrumb.

7

A new breadcrumb will be dropped if the current traffic density φ is larger than this average λφ times a factor ξ φ that is yet to be determined, see Eq. (4). At the same time, a minimum and a maximum distance dmin and dmax , respectively, between breadcrumbs have to be defined, to prevent overlapping or unfeasibly long distances. Thus, breadcrumbs will not be dropped if di < dmin , independent from φ , but will be dropped at the latest when di ≥ dmax , see Eq. (5). Because of this dynamic dropping process, predicting exact breadcrumb locations becomes infeasible, complicating further improvements such as fanning out responses as described in Section 4.1.2. Consequently, breadcrumbs are additionally dropped at intersections, with the required number of neighboring vehicles being lower (but still larger than the average, as defined by the factor ξ xing ), see Eq. (6). In sum, breadcrumbs are dropped if any of the following equations is true:

(dmin < di < dmax ) ∧ (φ > λφ · ξφ ),

(4)

di ≥ dmax ,

(5)

or

(dmin < di < dmax ) ∧ (φ > λφ · ξxing ) ∧ intersection(x), (6) where ξ xing < ξ φ and intersection(x) is true if the originator’s current location x is an intersection. 4.2.2. Dynamic size Similar to the dropping location, the breadcrumb size can be dynamically adapted to the node density, such that fewer vehicles result in a larger breadcrumb and vice versa. As described in the original paper [3], we set s = a = 2r. Depending on which Eqs. (4)–(6) is true, the default breadcrumb size s0 is increased by a specific factor ξ a/b



s=

s0 · ξ a s0 · ξ b

if dmin < di < dmax if di ≥ dmax

(7)

In practice, s0 · ξ a/b means a = a0 · ξa/b and r = r0 · ξa/b . 4.3. Disconnected trails As mentioned in Section 3.3.3, the breadcrumb trail can get disconnected, if all vehicles (or other potential nodes) leave a breadcrumb area. Several improvements that are introduced in this work either mitigate the effects of a disconnected trail or try to avoid it in the first place, such as truncating a trail (see Section 4.1.1) or dynamically adapting breadcrumb parameters (see Section 4.2), respectively. As an additional measure, however, lost breadcrumbs can be restored. To this end, the “truncate” message in Section 4.1.1 can be re-used, as it is already being forwarded backwards along the trail. Whenever it reaches a breadcrumb area, in which no vehicles with the original breadcrumb information are left (because at some point no vehicle remained in the area at all), it restores a breadcrumb, linking it with the correct successor and predecessor and thus restoring the trail.

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC 8

ARTICLE IN PRESS

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

Fig. 7. Road networks of San Francisco and Helsinki.

In addition to sending an update whenever a new breadcrumb is dropped (as explained in Section 4.1.1), the combined “truncate/restore” message can also be sent periodically, which is useful in case the originator does not move for a longer period (and thus does not drop new breadcrumbs). 4.4. Early resource release In the original BGR design, messages are kept alive until their TTL expires. Even after a query has been responded to, all related breadcrumbs and (potential) additional copies of the response consume network resources. If the querying vehicle anticipates no further responses from this particular area, these resources can be released to relieve the network. Hence, a “delete” message is sent backwards along the breadcrumb trail, similar to an update message in Section 4.1.1. Nodes receiving the delete message will release all associated resources, i.e. breadcrumbs, cached responses, etc. 5. Evaluation

108.78 km of roads. As is common in U.S. cities, the structure of the road network is for the most part rectangular shaped with two parks in the center of the scenario. Fig. 7a shows the layout of the used map. 5.1.2. Helsinki (HEL) For the second scenario, the downtown area around the city center of Helsinki, Finland is used. The area is 14.67 km2 in size and includes 119.2 km of Helsinki’s road network. As in the San Francisco scenario, all roads are assumed to be bidirectional. Fig. 7b shows the layout of the simulated road network, based on [28]. 5.1.3. Manhattan (MAN) The Manhattan scenario covers 5.76 km2 and includes a 135.05 km road network. Its checkered layout resembles the San Francisco scenario, but with a block size about twice as large (Fig. 8).

In this section, we first present the simulation environment, such as scenarios used and default values. Then, the improvements presented in Section 4 are analyzed both separately and in combination. These results are used to define an optimized BGR version, namely BGR2.

5.1.4. Tokyo (TKY) The fourth scenario is Tokyo, Japan. Its road network has no recognizable system and thus resembles the Helsinki scenario. Since BGR did not perform as well in the latter, this scenario allows us to investigate whether non-checkered layouts generally are less eligible use cases. Tokyo covers 4.83 km2 and 131.48 km of road network.

5.1. Scenarios

5.2. Simulation setup

To investigate the impact of scenario characteristics, such as street layout and node density, on the performance of the proposed protocol, we introduce two new scenarios in addition to the those used in the original paper (San Francisco, Helsinki) [3].

In the following sections, the proposed protocol features described in Section 4 are evaluated. The general goal is to keep as many of the interesting properties of the original BGR as possible, for instance a low message overhead. In general, the default values as specified in Table 1 are used. Vehicles have a transmission range of 100 m, as opposed to 25 m in the original paper [3], which better matches related work on IEEE 802.11p [29–31]. To ensure comparability to conventional geocast routing algorithms, that do not consider a response to a specific request, and to avoid effects that are caused by parts of the protocol other than the routing decisions and mechanisms, only the routing of responses

5.1.1. San Francisco (SF) The San Francisco, CA scenario3 covers the area around the (Lower) Pacific Heights neighborhood and Marina District. The area is approximately 5.39 km2 in size and includes 3

http://www.tm.kit.edu/˜mayer/osm2wkt/

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

ARTICLE IN PRESS

JID: ADHOC

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

9

Fig. 8. Road networks of Manhattan and Tokyo.

Fig. 9. Impact of dynamic breadcrumb size. Different performance metrics plotted against (ξ a , ξ b ). (ξa , ξb ) = (1, 1) corresponds to the original BGR.

Table 1 Default settings. Setting

Value

# nodes SF/HEL/MAN/TKY Time between new messages Response delay Transmission range Randomly moving cars Simulated period Transmission rate Time to live (request) Driving speed Buffer size

1850 / 2000 / 2296 / 2235 120–360 s 480 s 100 m 17 vehicles/km 12 s 22 Mbit/s 60 min 18–54 km/h 500 MB

to the requesting car is investigated. Therefore, the queries themselves are immediately and always successfully transmitted into their destination area, and one respondent has already been elected (using VITP) to forward the response to the originator. However, in order to take the transmission and the processing time of the query into account, a random “response delay” is applied, before a response is initiated. Without loss of generality, this reduces the simulation’s overhead and allows it to focus on the evaluation of the breadcrumb approach for routing responses to a moving originator. Further, only currently driving cars initiate queries (as opposed to parking vehicles). Thereby, each newly created query causes breadcrumbs to be dropped by the originator. Messages are created at random nodes from the scenario area with a random waiting time before each new message creation. To ensure comparability between the different

scenarios, the average number of vehicles per road kilome ter is 17 vehicles/km, which is based on real-world traffic data [32] of Braunschweig, Germany during morning rush hour. In later sections, however, the traffic density is varied to study its impact on protocol performance. 5.3. Dynamic breadcrumb parameters To increase the breadcrumb availability and thus the delivery rate, the size and distance parameters are determined dynamically as described in Section 4.2. To this end, default values for both parameters s0 and dstatic are determined in precursory simulations. Subsequently, the parameters for the dynamic adaption process are determined, namely the factors ξ a and ξ b by which s0 (or, to be more precise, both r and a) is increased depending on the dropping condition, as defined in Eq. (7), and the factor ξ φ by which the traffic density φ must exceed the average density λφ to trigger a drop, according to Eq. (4). Lastly, the impact of the order nφ of the moving average λφ is investigated. 5.3.1. Default breadcrumbs We first run simulations with the original BGR version to determine reasonable default values for s0 , dstatic , dmin , and dmax . Due to space constraints and since these results do not directly relate to the main contribution of this paper, we only sum up the results as follows. For s0 , sizes between 100 m and 300 m have been evaluated, while values for dstatic have ranged between 200 m and

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC 10

ARTICLE IN PRESS

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

Fig. 10. Impact of dynamic breadcrumb distance. Different performance metrics plotted against ξ φ .

Fig. 11. Impact of the order nφ (the number of previous breadcrumb locations) of the moving average λφ .

600 m. While larger breadcrumbs are kept available longer (since more vehicles share the information) and reduce the delivery delay, they also increase the network overhead significantly, as was already shown before [3]. Thus, we derive the standard size s0 from the communication range of 100 m, i.e., s0 = a = 100 m (and accordingly r = 50 m), as any two nodes within this radius are thus within 1-hop range from each other. This balances the overhead and the delivery performance. Accordingly, the smaller the distance, the larger the overhead and the better the delivery performance. The standard distance dstatic is thus set to 400 m, dmin = 200 m and dmax = 400 m. Further, the following values showed promising results in the precursory simulations and will thus be used in Section 5.3.2 through Section 5.3.4, unless otherwise stated: (ξa , ξb ) = (1, 2), ξφ = 3.0, nφ = 4.

5.3.2. Dynamic size Fig. 9 shows the impact of increasing the breadcrumb size s0 by the factor ξ a or ξ b according to Eq. (7). Increasing either ξ a or ξ b improves both delivery delay and breadcrumb availability as this results in larger breadcrumbs that include more vehicles, but at the expense of a considerably increased network overhead. For instance, (ξa , ξb ) = (2, 4) results in 2–3 times as many messages in the network, compared to the standard size s0 , i.e., (1, 1). In contrast, the overhead only rises from 28% to 40% if (ξ a , ξ b ) is changed from (1, 1) to (1, 2). The delivery rate and the hop count remain unchanged. The most promising results with regard to delivery delay and availability are delivered by the values (2, 4). Yet, its increase in network overhead is significant, which is why we set (ξ a , ξ b ) to (1, 2) for the following simulations. As (ξa , ξb ) = (2, 4), s0 = 100 corresponds to (ξa , ξb ) = (1, 2), s0 = 200, we will re-evaluate larger breadcrumb sizes in Section 5.7 after evaluating overhead-saving improvements in the following sections.

5.3.3. Dynamic distance ξ φ is the factor by which the traffic density φ must exceed the average density λφ to trigger a drop, according to Eq. (4). Fig. 10 shows its impact on the protocol performance. A larger ξ φ results in more messages in the network, as shown by Fig. 10a, since a large ξ φ requires more vehicles be present for dropping breadcrumbs. The overhead increase, however, is negligible. Similarly, ξ φ has no clear impact on the delivery delay, as shown by Fig. 10c. It turns out, though, that the breadcrumb availability does benefit from larger ξ φ , increasing from 70% to 85% and from 90% to almost 100%, depending on the scenario (see Fig. 10b). Since values larger than 3.0 seem to negatively affect the delivery rate (not depicted), we set ξφ = 3.0 for the following evaluations, since it has no apparent disadvantages, but increases the availability by about 10% in both scenarios. 5.3.4. Order of moving average Fig. 11 shows the impact of the order nφ of the moving average λφ (i.e., φ at the previous nφ breadcrumb locations) that is used to determine suitable dropping locations (see Eq. (4)). It turns out that the order has very little influence overall, although the availability can be increased from about 75% (nφ = 2) to 90% (nφ = 8) in Helsinki. Fig. 11c shows another interesting effect: nφ = 2 leads to a decrease in the delivery delay (about 7% in Helsinki), compared with larger nφ . Despite the relatively humble improvement, we set nφ = 2 for following simulations, as a decrease of the delivery delay is more relevant than a slightly higher availability which can also be achieved by other means. 5.4. Truncating and restoring trails In order to reduce the delivery delay, breadcrumb trails can be truncated as described in Section 4.1.1. The following two truncating options have been evaluated, which can both be combined with restore messages, as described in Section 4.3:

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC

ARTICLE IN PRESS

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

11

Fig. 12. Impact of truncating/restoring breadcrumb trails. Plotted against: truncate option / restore option, with df = direct forwarding, ml = maximum length, r = restore. –/– corresponds to the original BGR.

• Each breadcrumb forwards responses directly to the last known position of the querying vehicle, see Fig. 4b. In the following, this option is referred to as df (direct forwarding). • When the trail reaches a maximum length nmax , every other breadcrumb is skipped, see Fig. 4a. In the following, this option is referred to as ml (maximum length). Since the evaluation of different nmax did not show a significant impact, we arbitrarily choose nmax = 10 which corresponds well with average trail lengths.

Fanning out responses to multiple, adequate locations along the expected path of the originator promises a decrease in the delivery delay. As described in Section 4.1.2, responses will be sent to intersections with a given minimum distance

Fig. 12 shows the impact of all combinations on the protocol performance. df marginally reduces the overhead in the network (see Fig. 12a) since a response encounters fewer breadcrumbs and is thusly replicated in fewer geographical areas. The impact on the delivery delay, however, varies with the scenario: in Helsinki and Tokyo a slight decrease can be observed, while the scenarios with a checkered layout even suffer from a marginal increase, as shown by Fig. 12c. ml has no significant impact on the overhead or the delay. In the Helsinki scenario, which suffered from the worst delay in the first place, both options, however, achieve a reduction by 20 s. Interestingly, neither option has a significant impact on the hop count (which is why it is not depicted here). This shows that the majority of hops does not derive from the forwarding along the breadcrumb trail, but from the underlying georouting approach. Fig. 12b shows that the restore option r leads to a significant increase from 70% to 85% and 90% in the breadcrumb availability in Helsinki (with options df and ml, respectively). In San Francisco and Manhattan the availability in part reaches 100%. In Tokyo, the availability is always 100%

dfan between them. According to Eq. (6), ξxing < ξφ . Thus, we set ξxing = 2 for all following simulations with the fan-out option enabled. Fig. 13 shows the impact of different dfan . As expected, multiple responses (that are being geocasted to and spread in their destination area) significantly add to the network traffic. A distance of only 200 m between the destination areas can even reach values comparable to Epidemic. A larger distance decreases the network traffic, of course, and with 600 m the traffic is only about twice as high as in the case of a single response, see Fig. 13a. This extra traffic, however, also buys a significant decrease in delivery delay as shown by Fig. 13b. The time savings constitute 67–124 s (on average 29%) and 29–96 s (on average 21%) in case of 200 m and 600 m, respectively. The fanning-out also decreases the hop count (see Fig. 13d) continuously throughout all scenarios, whereas smaller distances result in lower hop counts. Another benefit is shown in Fig. 13c. Independent from the actual distance, sending multiple responses increases the delivery rate from 84% to 94% in Helsinki.

(not depicted). Other metrics are not noteworthily influenced by the restore option r.

5.5. Response fan-out

!

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC

ARTICLE IN PRESS

12

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

Fig. 13. Impact of fanning out responses as a function of the minimum distance dfan between intersections. “Single” indicates that only one response was sent, which corresponds to the original BGR.

5.6. Early resource release In order to further mitigate network traffic, delete messages are used to release allocated resources early, i.e., before the expiration of associated TTLs. Fig. 14 shows the impact of delete messages in combination with several of the abovementioned options, such as fanning out responses and truncating trails. In particular, ml/r (truncating the trail with a maximum length of 10 and the restore option) from Section 5.4 is used, as it turned out to provide both better delivery delays and breadcrumb availability while hardly increasing the overall network traffic. The figure shows that the early release option d (delete) significantly decreases the overall network traffic, partly by more than 50%. This decrease is mostly independent from the other options and does not impinge on other metrics. Consequently, early resource release has distinct and invariable benefits. For instance, it compensates the additional overhead of responses fanned out at a minimum distance of 600 m. As a consequence, this combination achieves a smaller delay with almost no additional overhead (compared with only a single response). 5.7. Traffic density and larger breadcrumbs In this section we further investigate the feasibility of BGR in scenarios with a lower traffic density. In Fig. 15 we thus compare the previously used density of 17 vehicles/km with 8.5 vehicles/km. Additionally, we investigate the impact of larger default breadcrumb sizes (and accordingly larger interbreadcrumb distances) as Section 5.3.2 has indicated a posi-

Fig. 14. Impact of early resource release. Network overhead plotted against following options: truncate option / dfan / delete option, with ml = maximum length, d = delete. –/–/– corresponds to the original BGR.

tive correlation. We also provide direct comparison with the original BGR (with a static size of 200 m and a static distance of 400 m), marked as “200 m/400 m/...”. Further, based on the abovementioned results of this section, the following options have been activated: • (ξa , ξb ) = (1, 2), ξφ = 3.0, nφ = 2 • ml/r/d, i.e., truncating/restoring trails with nmax = 10 and releasing resources early • Fanned out responses with d f an = 600 m Fig. 15 shows that larger breadcrumbs and a simultaneous increase of the dropping interval generally provide better results, in terms of both delivery delay (see Fig. 15b) and delivery rate (see Fig. 15c) throughout all scenarios. In most scenarios even the network traffic drops with larger sizes, namely up to 33% in case of a traffic density of 17 vehicles/km,

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC

ARTICLE IN PRESS J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

[m3Gdc;June 27, 2015;9:7] 13

Fig. 15. Impact of traffic density and different breadcrumb sizes. Plotted against: s0 / dstatic (or dmin − dmax ) / φ . 200 m/400 m/x corresponds to the original BGR.

Fig. 16. Comparison with BGR2.

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC 14

ARTICLE IN PRESS

[m3Gdc;June 27, 2015;9:7]

J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

as depicted by Fig. 15a. With lower traffic densities, however, larger breadcrumbs lead to an increase in the network overhead. In sum, though, breadcrumb sizes of 200 m in an interval of 400–600 m seem beneficial compared to smaller sizes. 5.8. BGR2 In this section, we facilitate the results from the previous sections and combine the most promising options to a new protocol version, BGR2. In particular, this includes: • s0 = 200 m, (ξa , ξb ) = (1, 2), ξφ = 3.0, nφ = 2 • ml/r/d, i.e., truncating/restoring trails with nmax = 10 and releasing resources early • Fanned out responses with d f an = 600 m In Fig. 16 we compare BGR2 with the original BGR (static breadcrumb size of 200 m and static distance of 400 m) and the reference routing protocols GeoRouting, Epidemic and Spray&Wait. Depending on the scenario, BGR2 can significantly decrease the message overhead compared to BGR, as shown in Fig. 16a. In Manhattan, for instance, this decrease amounts for about 43%. Compared to Epidemic, BGR2 still avoids up to 93% (see Tokyo scenario) of the traffic overhead. While BGR’s breadcrumb availability in the SF, MAN, and TKY scenarios is already 100%, BGR2 is able to achieve 100% in the difficult HEL scenario as well (not depicted). This shows that BGR2, by virtue of its dynamic breadcrumb adaption, successfully adapts to diverse street layouts and node densities, making it a versatile routing approach. The delivery delay, a shortcoming of BGR, is significantly improved on by BGR2, resulting in a 5–32% (on average 24%) decrease, as shown by Fig. 16b. From Fig. 16c it becomes clear that BGR2 is also very well applicable in scenarios difficult for BGR, as it further increases the delivery rate in the HEL scenario by more than 10% to about 93%. Hence, BGR2 boosts the delivery rate of the underlying GeoRouting from 48% (Helsinki) to almost 100% in virtually every evaluated scenario. BGR2 achieves these excellent results by using even fewer hops than Epidemic (in HEL, SF, MAN), as Fig. 16d shows. 6. Conclusion In this paper, we extend the Breadcrumb Geocast Routing (BGR), a georouting protocol for vehicular networks. BGR not only enables network nodes to route queries into a geographic area, but to route the response back to a moving originator, for which only the initial querying location is known. For this purpose, breadcrumbs are introduced which are a set of messages dynamically kept available for a defined period at specific locations along the path of the originator in order to forward responses. We introduce several performance improvements. In particular, we focus on further reducing both the delivery delay and network overhead and on the dynamic adaption of breadcrumbs to the street layout, node density and other scenario-specific parameters. The dynamic adaption process is based on the collection of traffic density information to determine suitable dropping locations and breadcrumb sizes. The various improvements have been evaluated both separately and in combination to define an optimized BGR2. To this end, extensive simulations in four different urban

scenarios have been conducted. In the evaluation, the performance of BGR2 was compared to reference routing protocols such as Epidemic, Spray&Wait and the original BGR. Results show a significant improvement on BGR, especially in terms of delivery delay, which can be reduced by an average of 24%. BGR2 thus not only avoids up to 93% of the traffic overhead of Epidemic, but increases the delivery rate of underlying georouting protocols significantly from about 48% to almost 100% even in difficult scenarios. It achieves these excellent results by using even fewer hops than Epidemic, thus saving network resources such as buffer space. In sum, it has been shown that BGR2 and breadcrumbs in general are a feasible and efficient approach for the routing of query responses to moving nodes via geocast. Since vehicle trajectories are not always available, BGR2 does not use them. As they can be easily integrated with the breadcrumb approach (as described in Section 4.1.2), though, future work may facilitate this information in order to further reduce delivery delays. The impact of physical layer influences could be an interesting subject as well. Acknowledgment This project has received funding from the European Union’s Seventh Framework Programme (FP7/2007-2013) under Grant Agreement Number [269916, V-Charge]. We would like to thank Mario Wozenilek and Nico Brüttner for their support. References [1] E. Brancaccio, Towards a true cooperative ITS, in: Proceedings of the 3rd ETSI TC ITS Workshop, Venice, Italy, 2011. [2] F. Bai, B. Krishnamachari, Exploiting the wisdom of the crowd: localized, distributed information-centric VANETs, IEEE Commun. Mag. 48 (5) (2010) 138–146, doi:10.1109/MCOM.2010.5458375. [3] J. Timpner, M. Wozenilek, L. Wolf, Breadcrumb routing: queryreponse geocast for mobile originators in vehicular networks, in: Proceedings of the IEEE Conference on Vehicular Networking (VNC), IEEE, Paderborn, Germany, 2014, pp. 49–56. . [4] J. Ott, E. Hyytia, P. Lassila, T. Vaegs, J. Kangasharju, Floating content: information sharing in urban areas, in: Proceedings of the IEEE International Conference on Pervasive Computing and Communications (PerCom), IEEE, Seattle, WA, 2011, pp. 136–146, doi:10.1109/PERCOM.2011.5767578. [5] S. Allal, S. Boudjit, Geocast routing protocols for VANETs: survey and guidelines, in: Proceedings of the Sixth International Conference on Innovations in Mobile and Internet Services in Ubiq. Comp., IEEE, Palermo, Italy, 2012, pp. 323–328, doi:10.1109/IMIS.2012.133. [6] C. Maihofer, R. Eberhardt, Geocast in vehicular environments: caching and transmission range control for improved efficiency, in: Proceedings of the IEEE Symposium on Intelligent Vehicles (IV ’04), IEEE, Parma, Italy, 2004, pp. 951–956, doi:10.1109/IVS.2004.1336514. [7] C. Maihöfer, T. Leinmüller, E. Schoch, Abiding geocast: time-stable geocast for Ad Hoc networks, in: Proceedings of the 2nd ACM International Workshop on Vehicular Ad Hoc Networks (VANET ’05), ACM Press, Cologne, Germany, 2005, pp. 20–29, doi:10.1145/1080754.1080758. [8] H. Joshi, M. Sichitiu, M. Kihl, Distributed robust geocast multicast routing for inter-vehicle communication, in: Proceedings of the 1st WEIRD Workshop on WiMax, Wireless and Mobility (in conjunction with 5th International Conference on Wired/Wireless Internet Communications), 2007, pp. 9–21. [9] A. Bachir, A. Benslimane, A multicast protocol in Ad hoc networks inter-vehicle geocast, in: Proceedings of the Conference on Vehicular Technology (VTC Spring), volume 4, IEEE, 2003, pp. 2456–2460, doi:10.1109/VETECS.2003.1208832. [10] O. Kaiwartya, S. Kumar, Geocast routing: recent advances and future challenges in vehicular Adhoc Networks, in: Proceedings of the International Conference on Signal Processing and Integrated Networks (SPIN), IEEE, Noida, India, 2014, pp. 291–296, doi:10.1109/SPIN.2014.6776965.

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003

JID: ADHOC

ARTICLE IN PRESS J. Timpner, L. Wolf / Ad Hoc Networks 000 (2015) 1–15

[11] O. Kaiwartya, S. Kumar, R. Kasana, Traffic light based time stable geocast (T-TSG) routing for urban VANETs, in: Procedings of the Sixth International Conference on Contemporary Computing (IC3), IEEE, Noida, India, 2013, pp. 113–117, doi:10.1109/IC3.2013.6612173. [12] R. Jiang, Y. Zhu, Coverage-aware geocast routing in urban vehicular networks, in: Proceedings of the 26th International Symposium Workshops on Parallel and Distributed Processing & PhD Forum, IEEE, Shanghai, China, 2012, pp. 2522–2525, doi:10.1109/IPDPSW.2012.317. [13] U.G. Acer, S. Kalyanaraman, A.A. Abouzeid, DTN routing using explicit and probabilistic routing table states, Wirel. Netw. 17 (5) (2011) 1305– 1321, doi:10.1007/s11276-011-0350-y. [14] J. Jeong, S. Guo, Y. Gu, T. He, D.H. Du, TSF: trajectory-based statistical forwarding for infrastructure-to-vehicle data delivery in vehicular networks, in: Proceedings of the 30th IEEE International Conference on Distributed Computing Systems, IEEE, Genova, Italy, 2010, pp. 557–566, doi:10.1109/ICDCS.2010.24. [15] M. Nakamura, T. Kitani, N. Shibata, K. Yasumoto, M. Ito, A method for improving data delivery efficiency in delay tolerant VANET with scheduled routes of cars, in: Proceedings of the 7th Conferenec on Consumer Communications and Networking (CCNC), IEEE, Las Vegas, NV, 2010, pp. 1009–1013, doi:10.1109/CCNC.2010.5421646. [16] C. Li, C. Zhao, L. Zhu, H. Lin, J. Li, Geographic routing protocol for vehicular ad hoc networks in city scenarios: a proposal and analysis, Int. J. Commun. Syst. (2013), doi:10.1002/dac.2602. [17] C. Lochert, H. Hartenstein, J. Tian, H. Fussler, D. Hermann, M. Mauve, A routing strategy for vehicular Ad Hoc networks in city environments, in: Proceedings of the IEEE Symposium on Intelligent Vehicles (IV ’03), IEEE, Columbus, OH, 2003, pp. 156–161, doi:10.1109/IVS.2003.1212901. [18] T. Delot, N. Mitton, S. Ilarri, T. Hien, Decentralized pull-based information gathering in vehicular networks using GeoVanet, in: Proceedings of the 12th IEEE International Conferenec on Mobile Data Management (MDM ’11), vol 1, IEEE, Lulea, Sweden, 2011a, pp. 174–183, doi:10.1109/MDM.2011.38. [19] T. Delot, N. Mitton, S. Ilarri, T. Hien, GeoVanet: a routing protocol for query processing in vehicular networks, Mob. Inf. Syst. 7 (4) (2011) 329–359, doi:10.3233/MIS-2011-0126. [20] J. Link, D. Schmitz, K. Wehrle, GeoDTN: geographic routing in disruption tolerant networks, in: Proceedings of the IEEE Conference on Global Telecommunications (GLOBECOM ’11), IEEE, Houston, TX, 2011, pp. 2432–2436, doi:10.1109/GLOCOM.2011.6134040. [21] E. Kulla, M. Ikeda, L. Barolli, R. Miho, V. Kolici, Effects of source and destination movement on MANET performance considering OLSR and AODV protocols, in: Proceedings of the 13th International Conference on Network-Based Information Systems, IEEE, Takayama, Japan, 2010, pp. 510–515, doi:10.1109/NBiS.2010.76. [22] U. Lee, J.-S. Park, E. Amir, M. Gerla, FleaNet: a virtual market place on vehicular networks, in: Proceedings of the 3rd International Conferenec on Mobile and Ubiquitous Systems, IEEE, San Jose, CA, 2006, pp. 358– 365, doi:10.1109/MOBIQW.2006.361765. [23] Y. Zhang, J. Zhao, G. Cao, Roadcast: a popularity aware content sharing scheme in VANETs, in: Proceedings of the 29th IEEE International Conference on Distributed Computing Systems, IEEE, Montréal, Canada, 2009, pp. 223–230, doi:10.1109/ICDCS.2009.19. [24] M.D. Dikaiakos, S. Iqbal, T. Nadeem, L. Iftode, VITP : an information transfer protocol for vehicular computing, in: Proceedings of the 2nd ACM International Workshop on Vehicular Ad Hoc Networks (VANET ’05), ACM Press, Cologne, Germany, 2005, pp. 30–39, doi:10.1145/1080754.1080759. [25] M. Mitzenmacher, Compressed bloom filters, IEEE/ACM Trans. Netw. 10 (5) (2002) 604–612, doi:10.1109/TNET.2002.803864.

[m3Gdc;June 27, 2015;9:7] 15

[26] S.S. Chawathe, Inter-vehicle data dissemination in sparse equipped traffic, in: Proceedings of the IEEE Conference on Intelligent Transportation Systems (ITSC ’06), IEEE, Toronto, Canada, 2006, pp. 273–280, doi:10.1109/ITSC.2006.1706754. [27] C. Perkins, IP Mobility Support for IPv4, Revised, Request for Comments, RFC 5944 (Proposed Standard), IETF, Internet Engineering Task Force, 2010, http://www.ietf.org/rfc/rfc5944.txt. [28] A. Keränen, J. Ott, T. Kärkkäinen, The ONE simulator for DTN protocol evaluation, in: Proceedings of the 2nd International Conferenec on Simulation Tools and Techniques (Simutools ’09), ICST, Rome, Italy, 2009, pp. 55:1–55:10, doi:10.4108/ICST.SIMUTOOLS2009.5674. [29] O. Urra, S. Ilarri, T. Delot, E. Mena, Mobile agents in vehicular networks: taking a first ride, Adv. Pract. Appl. Agents Multiagent Syst. 70 (2010) 119–124, doi:10.1007/978-3-642-12384-9_15. [30] E. Kokolaki, M. Karaliopoulos, I. Stavrakakis, Value of information exposed: wireless networking solutions to the parking search problem, in: Proceedings of the 8th International Conference on Wireless OnDemand Network Systems and Services (WONS), IEEE, Bardonecchia, Italy, 2011, pp. 187–194, doi:10.1109/WONS.2011.5720192. [31] H. Higaki, Navigation system based DTN routing in sparse vehicular networks, in: Proceedings of the International Conference on Communications and Information Technology (ICCIT), IEEE, Aqaba, Jordan, 2011, pp. 171–175, doi:10.1109/ICCITECHNOL.2011.5762673. [32] M. Caliskan, D. Graupner, M. Mauve, Decentralized Discovery of Free Parking Places, in: Proc. 3rd Int. Workshop on Vehicular Ad hoc Networks (VANET ’06), ACM Press, Los Angeles, CA, 2006, pp. 30–39, doi:10.1145/1161064.1161070. Julian Timpner received the B.Sc. and M.Sc. degrees in computer science in 2009 and 2012, respectively, from Technische Universität Braunschweig. During his graduate studies, he spent one year at the University of California, San Diego. Since 2012, he works as a research staff member at the Institute of Operating Systems and Computer Networks at Technische Universität Braunschweig, where he is also pursuing the Ph.D. degree. Currently, his research focuses on cooperative vehicular networks, e-mobility and parking management. Lars Wolf received the diploma degree in 1991 and the doctoral degree in 1995, both in computer science. From 1991 to 1996 he worked at IBM’s European Networking Center in Heidelberg, Germany, on multimedia transport, resource management, quality of service, media servers and multimedia applications. In 1996 he joined the Technical University of Darmstadt as assistant professor. There he led a research group working on multimedia networking and quality of service in distributed multimedia systems. Dr. Wolf joined Universität Karlsruhe (TH), Germany, in 1999 where he was associated professor in the computer science department and alternate director of the computer center. Since spring 2002 Lars Wolf is full professor for computer science at the Technische Universität Braunschweig where he is head of the Institute of Operating Systems and Computer Networks. His current research interests include wireless and mobile networking in general, sensor networks, vehicular networks, delay-tolerant networks, and network & system support for mobile systems. Lars Wolf serves on editorial boards of international journals and as chair and member of program committees of many international conferences and workshops.

Please cite this article as: J. Timpner, L. Wolf, Query-response geocast for vehicular crowd sensing, Ad Hoc Networks (2015), http://dx.doi.org/10.1016/j.adhoc.2015.06.003