End-to-end Acknowledgement of Geocastin Vehicular Networks

Marco Slot, Vinny CahillTrinity College Dublin

School of Computer Science and Statistics

Distributed Systems Group

{slotm,vinny.cahill}@scss.tcd.ie

Abstract—Vehicular networks suffer from fundamental relia-bility problems, which preclude basing safety-critical decisionson the expected outcome of communication. To enable safe,distributed decision making, reliable feedback on the success ofcommunication is of critical importance. In this paper, we addressthe problem of end-to-end acknowledgement of geocast, in orderto allow an application to know to which vehicles its geocastmessages were successfully transmitted. Acknowledgements aregathered in a wave of fixed velocity to obtain results with apredictable delay. Acknowledgements are aggregated into largermessages and aggregators are selected using consistent hashingto increase the probability of acknowledgements from differentvehicles being forwarded to the same aggregator. The source isfound using a combination of a sink tree towards its originalposition, which is overlaid on the road network, and positionupdates by the source. We show that the algorithm is effectiveunder various traffic conditions on a simulated highway.

I. INTRODUCTION

The combination of (partially) automated vehicles with

vehicular networks holds a promise of self-controlling, self-

optimizing traffic [1]. Vehicles can use communication to

learn of each other’s sensing perspective and intentions, and

coordinate their behaviour in a distributed fashion. Unfortu-

nately, current vehicular communication protocols only offer

probabilistic delivery guarantees and neglect the provision of

deterministic reliability required by such group motion controlapplications [23]. A sender of a message cannot draw any

conclusions about the reaction of potential receivers, unless it

has a guarantee that its message arrived.

If a sender receives application-level acknowledgements, it

knows which vehicles have received its message. At this point,

the sender can rely on the receivers to fulfil any duties that

are part of the protocol upon receiving the message. When the

sender does not receive an acknowledgement, it does not know

whether or not its message was received and should anticipate

either possibility. The use of positive acknowledgement allows

the sender to take responsibility for dealing with potential

communication failures or success, rather than relying on

the likelihood of reception. While simply acknowledging a

message is a straightforward technique, it becomes substan-

tially more complicated when considering more sophisticated

communication primitives and the practical problems that arise

in vehicular networks.

Group motion control applications interact with a continu-

ously changing set of vehicles in a surrounding area. A suitable

primitive to communicate with these vehicles is geocast, a vari-

ant of multicast that addresses all vehicles in a specified area.

Geocast can be implemented without any control messages or

upfront knowledge about the receivers [9] and is well-suited

for vehicular networks [15]. A desirable outcome of geocast

is for all vehicles in the delivery area at a specified time

to receive the message. A group motion control application

requiring deterministic reliability will have to confirm whether

this has happened. To do so, two additional components are

required to complement a geocast protocol: a membershipservice that can reliably tell the application the identifiers of

the vehicles that were in the delivery area at a given time,

and an acknowledgement protocol to gather acknowledgements

to a geocast from all the vehicles in the delivery area. We

have addressed the issue of reliable membership in prior

work [18], which we briefly summarize in the next section.

In this paper, we address the issue of acknowledging geocast.

When combining these techniques, applications can reliably

confirm whether a geocast succeeded.

Acknowledging a geocast requires every receiver to send

a separate response. To deliver the acknowledgements to the

source, the acknowledgements may have to be forwarded over

several hops, causing significant overhead. We reduce the

number of messages by aggregating acknowledgements into

larger messages. The effectiveness of this technique relies on

vehicles picking common acknowledgement aggregators. To

do so, we apply consistent hashing [11] to the unique identifier

of the message and the identifiers of nodes in a neighbourhoodview to select an aggregator. This will, with high probability,

cause vehicles to select the same aggregators for the same

stream of acknowledgements. The participants on a vehicular

network drive on roads, causing the network to have long, thin

branches over which forwarding can be described as a wave.

Using a distributed computation, aggregators delay forwarding

of acknowledgements to create a wave of fixed velocity in

which acknowledgements are passed towards the source and

aggregated at each intermediate step.

In the remainder of the paper, we will describe the details of

this approach to gathering acknowledgements to geocast in a

vehicular network. In the evaluation, we show that it can scale

to high densities, significantly reduces overhead compared to

forwarding individual acknowledgements, and achieves a high

success rate.

2011 IEEE Vehicular Networking Conference (VNC)

978-1-4673-0047-6/11/$26.00 ©2011 IEEE 131

II. RELIABLE GEOCAST MEMBERSHIP

In prior work, we have developed a membership service

for geocast in vehicular networks that is a hybrid between

a communication and a sensing system [17], [18]. It has

the ability to recognize vehicles through communication, and

the absence of other vehicles through sensors, thus avoiding

pitfalls in drawing conclusions from the absence of messages

or the potentially faulty recognition of objects from sensor

information. To achieve this, and deal with the issue of

time, we developed a novel representation for the membership

information that is provided to the application. The mem-

bership service provides membership tuples (denoted M) to

the application containing a set of vehicle identifiers M , area

A, and time T , which has the following constraints on the

positions Pi of all vehicles i:

M(M,A, T )↔ (Pi in A at T → i ∈M).

The constraint implies that M must be a superset of the

vehicles that are located in area A at time T . The membership

service can expand M or contract A to deal with uncertainty.

In [18], we show an implementation of the membership service

that generates a tuple for a single vehicle by determining the

area around it that is is empty using its own radar sensor. The

resulting tuple is decayed to deal with the passage of time

(i.e., shrinking A to account for unknown vehicles entering

A at maximum velocity), and subsequently merged to form

tuples with multiple members that cover larger areas. The

membership service implements a distributed protocol to form

these tuples and provide them to local applications.

Due to the unlikelihood of completely failing to see an

obstruction the size of a vehicle on a fine-grained (laser)

radar, the membership service can reliably avoid creating

false negatives: vehicles that are in A at time T , but not

in M . However, vehicles in M that are not in A at time T(false positives) can exist. With the passage of time, vehicles

can have left the area without notification by the time the

membership tuple is used. The constraint on tuples explicitly

allows this to enable reasoning about time without requiring

additional information. Because M is a superset, the sender of

the geocast can still confirm that all vehicles in A at time Treceived its message by obtaining acknowledgements from all

vehicles in M . Receivers that were actually outside A at time

T could indicate this as part of the acknowledgement, but this

is left to higher-layer protocols and may not yet be known if

the reception time lies before T .

The combination of membership with acknowledgements

gives the sender of a geocast the ability to reliably confirm

(in hindsight) that all vehicles that were in the delivery area

at a given time received the message, if the delivery area lies

within A and it received acknowledgements from all vehicles

in M .

III. GATHERING ACKNOWLEDGEMENTS

Gathering acknowledgements from a geocast requires sev-

eral problems to be addressed. The acknowledgements should

be aggregated to reduce the message overhead. Aggregators

need to delay forwarding to gather acknowledgements from

vehicles downstream of the source. Particularly in high density

networks, the number of aggregators should be minimized.

Finally, the aggregators need to know in which direction to

forward the acknowledgements in order to reach the source.

In this section, we describe a protocol that addresses each of

these problems.

We do not specifically address the problem of geocasting

and are not dependent on a particular geocast implementation.

For the remainder of this section, we assume a geocast has

been started and will be forwarded until a specified expiration

time. The geocast message contains the start time, expiration

time, source identifier, the starting position of the source, and

the delivery area. When a vehicle receives a geocast and is

present in the delivery area, the network layer forwards the

message and delivers it to the application. The application pro-

cesses the message and acknowledges it to the network layer.

The network layer keeps state on the geocast and participates

in the acknowledgement gathering protocol described below

until the expiration time.

A. Beaconing protocol

To participate in the acknowledgement gathering protocol,

vehicles need to beacon their identifier, position and current

time to their neighbours at a regular interval. Positions are

represented as an offset value on a road segment, described in

the next section. Vehicles use received beacons to maintain a

neighbourhood view, which contains the vehicles thought to

be reachable in a single hop. If no beacon is received from

a vehicle for two beaconing intervals, the vehicle is removed

from the view.

B. Delivery area format

The topology of a vehicular network consists of branches

that represent the roads on which the vehicles drive. Forward-

ing a geocast message over such a branch can be described as

a wave, which moves from the start of the branch to the end,

and may split into multiple independent waves at junctions.

The area on the road network reached by a geocast can be

represented as a tree formation, in which the source is the

root, junctions are the nodes, the roads on which the vehicle

drive are edges, and the boundaries of the delivery area of the

geocast are the leafs.

The way we represent the delivery area is given in Fig. 1(a).

The road network is represented as a graph of connectors

(nodes) and road segments (edges) and known to all participat-

ing vehicles. An area can be specified by a set of boundaries

that seal off part of the road network. This allows for a very

compact representation in transmissions, requiring only a road

segment identifier and an offset value for every boundary. It

also provides a more natural way of addressing areas on the

road than geometric shapes.

When a vehicle receives a geocast, it converts the delivery

area to a sink tree representation that will be used to forward

acknowledgements back to the source. First, the boundaries are

converted to a graph using breadth-first search from one of the

132

(a) (b)

Fig. 1. Topological representation of the delivery area. (a) Wire format usingboundaries on a network of road segments and connectors. (b) Internal formatusing sink tree towards source S. Also shows the furthest border of vehiclea where f(S, a) is the distance of the border from S

boundaries to find the other boundaries, including all visited

edges (road segments) and nodes (connectors) in the graph.

The graph can be converted to a sink tree (directed shortest

path tree) as shown in Figure 1(b). First, the edge on which the

source is located is split at the position of the source (included

in the message). Then, Dijkstra’s shortest path algorithm is

applied to compute the shortest path to the source for each

node using the lengths of the road segments as costs. Every

edge is given a direction, pointing to the node with the lowest

distance to the source. Finally, the algorithm constructs a tree

by recursively visiting all nodes starting at the source. Edges

pointing towards the current node are added as children, with

additional nodes added to close open-ended edges.

The sink tree is computed in the same way by all vehicles

participating in the geocast. It is used to find the direction in

which the source of the geocast lies, and to determine whether

and when to forward acknowledgements.

C. Acknowledgement wave

The process of gathering acknowledgements is organized

by each vehicle regularly evaluating a simple wave conditionand forwarding the acknowledgements it received, including

its own, once the condition holds. The parameters of the

wave condition are relative to the vehicle evaluating it. The

condition triggers early for vehicles near the border of the

delivery area, and later for vehicles nearer the source, creating

waves of forwarding from the borders to the source in which

each forwarder can aggregate downstream acknowledgements

with its own. From a distance, the protocol can be seen as a

ring containing all acknowledgements that gradually contracts

towards the source.

The wave condition models an abstract wave of constant

velocity that travels from the furthest border in the sink tree

representation of the delivery area to the source. The furthest

border is relative to the vehicle evaluating the condition and

found by searching the leaf with the greatest distance in the

sink tree below the position of the vehicle. The distance of this

leaf to source s, relative to a vehicle i, is denoted f(s, i). Its

value needs to be re-evaluated whenever the vehicle drives

onto another branch of the sink tree. This logic is key to

merging waves from different branches, since vehicles will

always wait for the wave from the longest branch.

The waves have a fixed target velocity (wave velocity or

vack), which is chosen by the application and included in

the geocast message and thus known to all participants. The

application can choose a high vack if it needs responses

quickly, or a low vack to improve aggregation and minimize

the number of messages. The protocol needs to allow some

time before the waves start, which is based on the velocity

of the geocast. To this end, the protocol uses a conservative

estimate of the velocity of the geocast vgeocast, which allows

it to compute the time since the furthest wave started as

tnow−(tstart+f(s,i)

vgeocast). During this time, acknowledgements

are passed inwards at the wave velocity vack and reach a

certain distance. Subtracting this distance from f(s, i) gives

the distance of the wave from the source. As soon as this

distance is less than or equal to the distance of the vehicle to

the source d(s, i) the acknowledgements are forwarded. The

formal definition of the wave condition is as follows:

d(s, i) ≥ f(s, i)− vack.(tnow − tstart − f(s, i)

vgeocast)

d(s, i) : distance of source start position to vehicle i

f(s.i) : distance of source start position to the furthest

border of the delivery area downstream of i

tnow : current time

tstart : start time of the geocast

vgeocast : conservative estimate of geocast wave velocity

vack : configured acknowledgement wave velocity

After a vehicle i receives a geocast, it regularly re-evaluates

the wave condition to reflect changes in time and position.

Re-evaluating makes the protocol robust to movement of

the vehicle, since that may cause the condition to trigger

later or sooner, but the protocol remains the same. Before

the wave condition holds, the vehicle receives and collects

acknowledgements from other vehicles. When the wave con-

dition holds, the vehicle sends a message containing received

acknowledgements and its own to an upstream aggregator

chosen from its neighbourhood view using MAC-layer unicast.

We describe the selection of an aggregator in the next section.

If the source is in the neighbourhood view it is always selected

as the aggregator.

When no upstream vehicle is available to select as an

aggregator because a network partition occurs, forwarding is

delayed until one becomes available. The wave condition does

continue to trigger at upstream nodes on the other side of the

partition, which will start forwarding and aggregating their

own acknowledgements. When connectivity is restored, the

downstream acknowledgements will be forwarded to nodes

for which the wave condition has already triggered and are

forwarded immediately upon reception until they have caught

up with the ongoing wave.

133

If traffic is dense, the wave will be triggered by many nearby

vehicles at nearly the same time causing channel contention.

For individual acknowledgements (before aggregation), we

therefore take a slightly different approach as an optimization

to the main protocol. When a vehicle first receives a geocast

it estimates when the wave condition will trigger and starts a

timer to forward the acknowledgement to an aggregator at a

random time before the wave. The point in time at which to

forward is obtained by rewriting the wave condition as follows:

twave = U [0, 1].(tstart +f(s, i)

vgeocast+

f(s, i)− d(s, i)

vack)

twave : time at which the wave condition is

expected to hold at reception time

U [0, 1] : uniform random number between 0 and 1

The timer will cause the acknowledgements to be passed

to aggregators before the wave comes back. This allows

transmissions to be spread out over a relatively long period,

rather than be forwarded simultaneously. If the wave con-

dition holds before the timer expires, the timer is cancelled

and acknowledgements are forwarded according to the wave

condition. If a vehicle receives an acknowledgement before its

timer expires it also cancels its timer.

D. Choosing aggregators

When the wave condition holds or the timer expires, a

vehicle participating in the protocol needs to choose an

aggregator to which to forward its acknowledgement(s). If

the source of the geocast is in the neighbourhood view of

the vehicle, the acknowledgements will be forwarded directly

to the source. If it is not, the vehicle needs to choose an

aggregator in such a way that other vehicles are likely to

choose the same aggregator for the same geocast, and that

the acknowledgements make progress towards the source.

Our approach is based on the consistent hashing tech-

nique [11]. The consistent hashing function c(m,V ) → qmaps a geocast message identifier m and view (set of vehicles)

V to a vehicle q ∈ V . The function we use is similar to

that of Chord [20]. Every geocast message carries a sequence

number and the unique identifier of the source, which together

give the message a unique identifier. When a receiver sends an

acknowledgement and the source is not in its neighbourhood

view, it computes a uniform hash of the message identifier

and the identifiers of the vehicles from its neighbourhood

view whose positions lie upstream in the sink tree. The hash

values are placed on a numeric ring. The first hash of a

vehicle identifier encountered from the hash of the message

identifier in the clock-wise (additive) direction is chosen as

the aggregator for the acknowledgements of the message.

It is important that the selected aggregator a lies upstream

of the forwarding vehicle b. Otherwise, a could select b as

an aggregator and a forwarding loop could be created. If a

vehicle could have moved at maximum velocity to become a

downstream node since sending its last beacon, it should not

be considered as an aggregator. If no aggregator is available

0

0.2

0.4

0.6

0.8

1

15 20 25 30 35 40 45 50 55 60

Pro

bab

ilit

yof

aggre

gat

ion

Traffic density (cars/km)

Fig. 2. Expected probability of agregation between the acknowledgements ofconsecutive forwarders with r = 80m and a uniform distribution of vehicles.

in the direction of the source, the algorithm is re-evaluated as

soon as the sensed position or neighbourhood view is updated.

The benefit of using consistent hashing is that, even with

inconsistent neighbourhood views, other nodes will select

the same aggregator with high probability. This allows the

aggregator to bundle multiple acknowledgements into a single

message and avoid the overhead of forwarding each of them

individually.

We give a basic model of the probability that aggregation

occurs between the acknowledgements of a vehicle q1 and

those of the next vehicle for which the wave condition will

hold q2 for a geocast message m. To simplify, we consider

a uniform distribution of the inter-vehicle distance and do

not consider the loss or delay of beacons in the model.

The expected number of reachable upstream vehicles can be

described as rρ, where r is the radio range, and ρ is the density

of vehicles. The upstream neighbours of q1 and q2 are in sets

V1 and V2, respectively. The probability of aggregation is the

probability that either c(m,V1)→ q2 or c(m,V1) = c(m,V2).The probability of the former is 1

rρ , because of the uniformity

of the hash function. In the alternative case, q1 selects a vehicle

upstream of q2, which must be in V2. The probability of

aggregation is then the probability that there is a vehicle in V2,

outside the range of q1, whose identifier hash lies in between

h(m) and the hash of the identifier of the vehicle selected by

q1, which is 1 − 1rρ . This leads to the following function of

probability, plotted in Figure 2:

1

rρ+ (1− 1

rρ)2 where ρ ≥ 1

r

For a radio range of 80m, the probability of aggregation

between the acknowledgements of consecutive forwarders is

at least 75% for all densities.

E. Handling source mobility

By the time the acknowledgements arrive at the starting

position of the source, it may no longer be in range. Our

approach to dealing with the mobility of the source is to let

it periodically send an unacknowledged geocast containing its

position and a timestamp to the vehicles between its current

position and its starting position. A vehicle that receives this

134

Beacon frequency 2HzVISSIM Road length 7.5kmVISSIM Number of lanes 2-3VISSIM Desired speed 100km/hOPNET Modulation OFDMOPNET Transmission frequency 5.9GHzOPNET Transmission power 10mW (Class B)OPNET Coordination function HCFOPNET Channel bandwidth 6Mbpsp-IVG ε 0.5p-IVG tmax 200ms

TABLE ISIMULATION CONFIGURATION PARAMETERS

position update uses it instead of the starting position to

compute the sink tree and the wave condition.

Vehicles directly in front of the source can receive position

updates from the source itself. When the wave condition holds,

the acknowledgements can be forwarded directly to the source.

Acknowledgements coming from behind the source will come

across a vehicle that has received a position update when

arriving at the starting position. Vehicles continue to forward

the acknowledgements towards the source according to the

updated wave condition. Loss of some update messages is

acceptable, as long as the majority of aggregators forward

towards the source.

IV. EVALUATION

We evaluated our implementation of the acknowledgement

aggregation scheme in an integrated simulation environment

that connects VISSIM (PTV, version 5.20) for traffic simula-

tion with OPNET (OPNET Technologies, version 16.0A) for

network simulation. Both simulators are mature, commercial

products and have been subject of extensive studies [5], [8],

[13], [4]. Our environment allows vehicles controlled through

VISSIM to communicate with each other over an ad-hoc

802.11p network simulated in OPNET.

A. Simulation environment

Our simulation environment is the same as the one used

in [18]. The geocast and acknowledgement protocols are im-

plemented as a library that is loaded by VISSIM, and connects

to a server controlling OPNET. VISSIM recomputes the states

of all vehicles in time-steps of 0.1 simulation seconds. We

replicate these states in OPNET. Because OPNET is a discrete

event simulator, it can have events in between the time-steps of

VISSIM. A scheduler executes all pending events in OPNET

and the acknowledgement protocol in the appropriate order

at the start of a VISSIM iteration. To deal with the lack

of intermediate state updates from VISSIM, we extrapolate

the pose and velocity of the last state update to predict the

new position. We treat the extrapolated position as the actual

position used for sensor and network simulation. The largest

error between the VISSIM state and the extrapolated state was

14cm in our experiments with a median of 1mm. Such small

differences have negligible effects on the overall results.

Entry rate Average density Label2× 800 cars/hour 27.5 cars/km VL2× 1600 cars/hour 49.8 cars/km L2× 2400 cars/hour 82.5 cars/km H2× 3200 cars/hour 101.1 cars/km VH

TABLE IIHIGHWAY DENSITIES IN EXPERIMENTS

We set the simulation parameters in OPNET to be in

line with those of 802.11p [10], shown in Table I. We also

implemented the probabilistic channel model by Cheng et

al. [2], taking the motorway parameters from Grau et al. [6],

both of which derive from real-world experiments. This leads

to a radio range of 70 − 80m. In VISSIM, we use the built-

in Wiedemann car-following model [22] and the standard

settings.

B. p-IVGOur acknowledgement aggregation scheme can work with

many different geocast protocols. For the purpose of the eval-

uation, we choose a specific, state-of-the-art geocast protocol

for vehicular networks: p-IVG [9]. The benefit of p-IVG is

that it can forward efficiently and adapt to the traffic density,

giving it a dependable velocity. It uses a beaconing service

that is identical to that of the acknowledgement protocol. We

give a brief description of the protocol.p-IVG uses a beaconing protocol to derive the density from

the size of a neighbourhood view. When receiving a message

that the node has not seen before, then with probability

1/density it will start a timer with delay δforward, based

on a uniform random number between 0 and a function of the

distance to the sender d, the radio range r and a maximum

defer time δmax:

δforward = δmax ∗ U [0, 1− min(r, d)ε

rε]

The value of ε can be used to control a trade-off between

forwarding quickly and reducing redundancy and collisions;

the authors of p-IVG recommend ε = 0.5. The value of dcan be obtained by comparing the current position to the

position of the forwarder contained in the message. In our

implementation, we estimate the radio range r by taking the

maximum distance to another node observed from messages or

beaconing. A vehicle forwards a geocast message if its timer

expires and it did not receive the same message from another

downstream vehicle.The effect of the random timer is that a far away vehicle

is likely to quickly rebroadcast the message, while nearby

vehicles will still broadcast the message if no far away vehicle

forwards it. This gives p-IVG a high expected velocity, with

occasional delays if only nearby forwarders are available.

Since every node within radio range is an eligible forwarder,

a p-IVG wave is unlikely to die out as long as the network

is connected. Nodes in between forwarders will be able to

receive messages at least twice, adding to the reception rate.

C. ExperimentWe simulate a two-way, 7.5km section of the M50 highway

in Dublin using a map obtained from the Open Street Map

135

project [7]. The east-west direction (south side) has two entries

and the west-east direction (north side) has two exits. We vary

the entry rate between 800 and 3200 vehicles per hour in

both directions. On the south side, 10% of traffic comes from

the entries. This configuration leads to the densities given in

Table II, which gives the densities for the full highway (4-

6 lanes). Density is the main parameter in our experiments

because of the challenging conditions created by protocols

having to operate in both sparse and dense networks. We will

refer back to these densities by their label.

A vehicle generates a geocast message whenever a lane

change occurs in VISSIM. We choose the lane change as

a natural traffic event which may, in the future, involve

communication. To select a delivery area, we use an algorithm

that moves the boundaries 500m outwards over the road

network from the current position of the source, to reach other

vehicles that may be close in the upcoming 0-15 seconds.

The expiration time is chosen to be 5 seconds into the future,

allowing sufficient time for the waves to come back to the

source and some additional time to deal with source mobility

and late acknowledgements. The geocast message contains a

generic payload of 500 bytes. The two sides of the highway are

not connected and forwarding outside of the delivery area is

not part of the protocol. Thus, vehicles driving in the opposite

direction only cause background traffic.

We perform the experiment in runs of 1 hour of simulation

time. Data gathering begins after 5 minutes to allow the

highway to fill.

D. Results

We centre our evaluation around three claims. First is the

legitimacy of using consistent hashing and the wave condition

to aggregate acknowledgements as a way of minimizing the

number of messages. Second, we show that the velocity of

consistent hashing-based acknowledgement forwarding can be

conservatively estimated. This is an important property, be-

cause it validates our approach of returning acknowledgements

in a wave of fixed velocity. Finally, we show that the approach

can successfully return acknowledgements from receivers most

of the time.

1) Aggregation and overhead: The purpose of using con-

sistent hashing and a delayed forwarding wave is to minimize

the number of messages required to acknowledge all receivers.

The minimum number of messages required to acknowledge a

receiver is 1. We assume the overhead of adding the identifier

of a vehicle to an acknowledgement is negligible compared to

sending a separate message.

Figure 3 shows the average number of acknowledgement

messages that were transmitted per delivered acknowledge-

ment for the case with a wave velocity of 300m/s, and a

wave of infinite velocity, in which case acknowledgements

are forwarded immediately and no intermediate aggregation

occurs. The latter case is comparable to DPGP [24]. At the

lowest density, the range of the geocast is poor and most

receivers are within a single hop from the source, meaning

there is little multi-hop forwarding overhead regardless of the

0

0.5

1

1.5

2

2.5

3

0 20 40 60 80 100 120

Mes

sag

estr

ansm

itte

dp

erA

CK

Highway density (cars/km)

unbounded ACK wave (DPGP)regular (300m/s) ACK wave

optimal

Fig. 3. Number of messages transmitted per delivered ACK for acknowl-edgement waves with unbounded wave velocity (no intermediate aggregation,comparable to DPGP), and 300m/s wave velocity

0

500

1000

1500

2000

2500

VL L H VH

Wav

evel

oci

ty(m

/s)

unb. wavereg. wave

p-IVG300m/s

Fig. 4. Velocity of forwarding for acknowledgement waves with unboundedand regular (300m/s) wave velocity, and velocity of p-IVG forwarding, forvarious densities.

wave velocity. At higher densities, the number of messages

per delivered acknowledgement remains stable when using ag-

gregation. Without aggregation, there is significant forwarding

overhead at higher densities and aggregation reduces it by up

to 50%. The main reason that it is not completely optimal

is that temporary partitions can stall forwarding and cause

downstream acknowledgements to arrive after a vehicle has

forwarded its own acknowledgements.

2) Communication velocity: In the previous experiment, we

used a wave velocity (vack and vgeocast) of 300m/s. The reason

we have chosen this velocity, apart from a slight round number

bias, is that we have found it to be a reasonable lower bound

on the forwarding velocity of acknowledgements and p-IVG.

If we again set the wave velocity to infinity, removing any

artificial delays in acknowledgement forwarding, we find the

(inf. wave) velocities shown in Figure 4. The forwarding ve-

locity is defined as the distance to the furthest receiver divided

by the time between the receiver sending an acknowledgement

and the source receiving it. In nearly all cases, the velocity is

above 300m/s, as is that of p-IVG on the outgoing path. This

means a wave velocity of 300m/s or lower maximizes aggre-

136

Density Ack. receivers Fully Ack. geocastsVL 98.2% 93.6%L 97.5% 89.9%H 91.7% 60.7%VH 90.7% 53.4%

TABLE IIIACKNOWLEDGEMENT SUCCESS RATE PER RECEIVER AND PER GEOCAST

FOR VARIOUS DENSITIES

gation. This result partly depends on the radio range and the

background traffic. However, since our simulation generates

a large amount of traffic, uses a conservative channel model,

and the highest density approaches traffic jam conditions, we

expect a wave velocity of 300m/s to be sufficient for most

configurations.

Figure 4 also shows the forwarding velocity when actually

using a wave velocity of 300m/s (reg. wave). The reason that

the average forwarding velocity is lower than the wave velocity

is due to temporary partitions that cause forwarding to pause

until connectivity is restored, which occurs more frequently

when density is low. The result is that acknowledgements

might arrive slightly later than expected, but since the geocast

is actually faster than the wave velocity these effects largely

cancel each other out. Another effect is that aggregation is

slightly suboptimal, as seen in Figure 3.

3) Success rate: The goal of the geocast is to reach all

vehicles in the area. Clearly, only receivers can acknowledge

the message and the number of acknowledgements returned

by the protocol is therefore dependent on the connectivity of

the network and the reception rate of the geocast protocol.

Table III shows the fraction of acknowledged receivers (excl.

non-receivers) and the fraction of geocasts for which an

acknowledgement was received from every receiver. Figure 5

shows the number of acknowledged receivers and other re-

ceivers as a fraction of the number of vehicles in the delivery

area (incl. non-receivers) at the expiration time. The choice

of measuring the number of vehicles at the expiration time is

somewhat arbitrary. Since the length of the delivery area and

the entry rate are constant, the expected number of vehicles

in the delivery area remains more or less the same.

Table III shows that the average number of acknowledge-

ments as a fraction of the number of receivers is over 90% for

all densities, showing the protocol is successful at returning

acknowledgements from most receivers. At higher densities,

the law of large numbers does lower the fraction of fully

acknowledged geocasts since it becomes much more likely

that a few receivers will fail to respond.

Figure 5 shows that the fraction of receivers reached using

p-IVG is quite poor at low densities. This is due to the average

distance between cars in the same direction being close to the

radio range. In these situations, the application should adapt

its requirements by accepting longer delays, which allows

switching to a store-carry-forward protocol [21], or settling

for a smaller delivery area. p-IVG is tailored for dealing with

higher densities.

What the implications are of the success rate and how

problems are best addressed requires further study of the

0

0.2

0.4

0.6

0.8

1

VL

L H VH

Fra

ctio

no

fto

tal

nu

mb

ero

fveh

icle

sin

del

iver

yar

ea AcknowledgedNot acknowledged

Not received

Fig. 5. Success rates for various densities

application domain. The specific range, time bounds, fre-

quency, density, etc. at which the application needs to work

and its ability to cope with different types of failures need

to be weighed against any measures that require additional

overhead. Nonetheless, even for the highest densities the

acknowledgement success rate is promising, and in the future

we will explore further optimizations such as reducing the

beaconing overhead and improving fault-tolerance.

V. RELATED WORK

A survey by Willke et al. [23] classifies the communication

requirements of vehicular applications. Of particular interest

in our work are the group motion control applications that

require deterministic reliability and real-time communication.

The decisions of these applications are safety-critical and the

information and assumptions on which they are based need to

be reliable. If other vehicles are expected to react to a message,

positive acknowledgement and membership are necessary to

confirm reception. One protocol that fulfils these requirements

is RNP [14]. The protocol ensures every vehicle is in at

least one and at most two token rings with its neighbours.

Within a ring, vehicles take turns in transmitting messages and

acknowledging each other’s messages. Election algorithms are

used to manage admission into the ring. A limitation of RNP

is that rings only span a single hop and it is not robust to

membership failures.

The key problem in end-to-end acknowledgement of geocast

or multicast in general is the large number of acknowledge-

ments sent to the source, also known as an ACK implosion.

AckPBSM [16] reduces the overhead of acknowledgements by

appending them to periodic beacons for some period after the

message was received. The nodes responsible for forwarding

and retransmission are chosen using a heuristic to determine

whether they are part of a connected dominating set. However,

acknowledgements are not forwarded over multiple hops.

RTMG [3] only acknowledges arrival of a geocast message in

the delivery area, effectively relaxing the guarantee. FAT [12]

builds and maintains a multicast tree from a source node in

which messages are sent down the tree and acknowledgements

137

up the tree, but only up to a parent which will otherwise

retransmit the message on behalf of the source. The source

can expect improved reception rate, but not rely on delivery.

To our knowledge, DPGP [24] is the only existing protocol

providing full end-to-end acknowledgement of geocast. Unlike

the protocol presented in this paper, DPGP is not robust to high

mobility and does not minimize the number of messages. In

DPGP, a node becomes an aggregator when receiving a geocast

message from outside the delivery area. An aggregator for-

wards the message inside the area and collects acknowledge-

ments from receivers, which unicast their acknowledgements

to the aggregator. After some time, the aggregator combines

the acknowledgements in a single message and forwards it to

the source. When the source is in the delivery area, it is the

only aggregator and DPGP is comparable to the case in our

evaluation in which there is no aggregation.

An alternative way of reducing the effects of an ACK

implosion is to use receiver-initiated communication [19]. A

vehicle that expects to receive a message can reliably detect

a failure when it does not. A negative acknowledgement

can be used to inform the source of the failure and trigger

retransmission, but the source cannot interpret the absence of

the NACK as success, since the NACK itself may not arrive.

In a vehicular network, this model is potentially useful for

communication with fixed road-side infrastructure, but not for

ad-hoc communication when there is no prior expectation.

VI. CONCLUSION

We have introduced a novel scheme for end-to-end acknowl-

edgement of geocasts, using consistent hashing and strate-

gically chosen delays to efficiently aggregate acknowledge-

ments. We have evaluated the protocol and shown it can be

effective under a wide range of traffic densities on a highway.

The acknowledgements can be aggregated in a predictable

fashion with a wave velocity that is largely independent of

density. We believe end-to-end acknowledgement of geocast

in combination with membership will be useful building block

in future cooperative vehicle applications that require a high

degree of determinism and reliability. We further expect the

novel techniques we have developed to have wider application

to efficient, real-time data gathering in vehicular networks.

VII. ACKNOWLEDGEMENT

The work described in this paper was supported by

Science Foundation Ireland (as Research Frontiers award

08/RFP/CMS1470).

REFERENCES

[1] V. Cahill, A. Senart, D. C. Schmidt, S. Weber, A. Harrington, andB. Hughes. The managed motorway: real-time vehicle scheduling: aresearch agenda. In Proceedings of the workshop on Mobile computingsystems and applications, pages 43–48, 2008.

[2] L. Cheng, B. Henty, D. Stancil, F. Bai, and P. Mudalige. Mobile vehicle-to-vehicle narrow-band channel measurement and characterization of the5.9 GHz dedicated short range communication (DSRC) frequency band.IEEE Journal on Selected Areas in Communications, 25(8):1501 –1516,oct. 2007.

[3] S. K. Dhurandher, M. S. Obaidat, and M. Gupta. A novel geocasttechnique with hole detection in underwater sensor networks. ACS/IEEEInternational Conference on Computer Systems and Applications, 0:1–8,may. 2010.

[4] M. Fellendorf and P. Vortisch. Validation of the microscopic traffic flowmodel vissim in different real-world situations. Technical report, PTVAG, 2001.

[5] P. P. Garrido, M. P. Malumbres, and C. T. Calafate. ns-2 vs. opnet:a comparative study of the ieee 802.11e technology on manet envi-ronments. In International ICST conference on Simulation tools andtechniques for communications, networks and systems & workshops,pages 1–10, mar. 2008.

[6] G. Grau, D. Pusceddu, S. Rea, O. Brickley, M. Koubek, and D. Pesch.Vehicle-2-vehicle communication channel evaluation using the cvis plat-form. In International Symposium on Communication Systems Networksand Digital Signal Processing, pages 449 –453, jul. 2010.

[7] M. Haklay and P. Weber. Openstreetmap: User-generated street maps.IEEE Pervasive Computing, 7:12–18, dec. 2008.

[8] H. Hallani, S. Shahrestani, and F. Stootman. Wireless ad-hoc network-ing: Analysis and validation of simulation results. In TENCON, IEEERegion 10, pages 1 –6, nov. 2005.

[9] K. Ibrahim, M. C. Weigle, and M. Abuelela. p-ivg: Probabilisticinter-vehicle geocast for dense vehicular networks. In IEEE VehicularTechnology Conference, Spring, pages 1–5, apr 2009.

[10] IEEE. IEEE standard for information technology–telecommunicationsand information exchange between systems–local and metropolitan areanetworks–specific requirements part 11: Wireless LAN medium accesscontrol (MAC) and physical layer (PHY) specifications amendment 6:Wireless access in vehicular environments. IEEE Std 802.11p-2010,pages 1 –51, 2010.

[11] D. Karger, E. Lehman, T. Leighton, R. Panigrahy, M. Levine, andD. Lewin. Consistent hashing and random trees: distributed cachingprotocols for relieving hot spots on the world wide web. In Proceedingsof ACM symposium on Theory of computing, pages 654–663, 1997.

[12] W. Liao and M.-Y. Jiang. Family ack tree (fat): supporting reliablemulticast in mobile ad hoc networks. IEEE Transactions on VehicularTechnology, 52(6):1675 – 1685, nov. 2003.

[13] N. Lownes and R. Machemehl. Vissim: A multi-parameter sensitivityanalysis. In Winter Simulation Conference, pages 1406 –1413, dec. 2006.

[14] N. F. Maxemchuk, P. Tientrakool, and T. L. Willke. Reliable neigh-borcast. IEEE Transactions on Vehicular Technology, 56(6):3278–3288,nov. 2007.

[15] H. Moustafa and Y. Zhang. Vehicular Networks: Techniques, Standards,and Applications. Auerbach Publications, Boston, MA, USA, 1st edition,2009.

[16] F. Ros, P. Ruiz, and I. Stojmenovic. Reliable and efficient broadcastingin vehicular ad hoc networks. IEEE Vehicular Technology Conference,Spring, pages 1 –5, apr. 2009.

[17] M. Slot, M. Bouroche, and V. Cahill. Membership service specificationsfor safety-critical geocast in vehicular networks. In InternationalSymposium on Communication Systems Networks and Digital SignalProcessing, pages 422 –426, jul. 2010.

[18] M. Slot and V. Cahill. A reliable membership service for vehicularsafety applications. In IEEE Intelligent Vehicles Symposium, jun. 2011.

[19] A. Sobeih, H. Baraka, and A. Fahmy. Remhoc: a reliable multicastprotocol for wireless mobile multihop ad hoc networks. IEEE ConsumerCommunications and Networking Conference, pages 146–151, apr. 2004.

[20] I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. F. Kaashoek,F. Dabek, and H. Balakrishnan. Chord: a scalable peer-to-peer lookupprotocol for internet applications. IEEE/ACM Transactions on Network-ing, 11:17–32, feb. 2003.

[21] O. Tonguz, N. Wisitpongphan, and F. Bai. Dv-cast: A distributedvehicular broadcast protocol for vehicular ad hoc networks. IEEEWireless Communications, 17(2):47 –57, apr. 2010.

[22] R. Wiedemann. Modelling of RTI-elements on multi-lane roads. Ad-vanced Telematics in Road Transport, DG XIII, 1991.

[23] T. L. Willke, P. Tientrakool, and N. F. Maxemchuk. A survey ofinter-vehicle communication protocols and their applications. IEEECommunications Surveys & Tutorials, 11(2):3–20, jun. 2009.

[24] S.-J. Yoon, S.-H. Lee, and Y.-B. Ko. Reliable dual-path geocasting fortactical ad hoc networks. In IEEE Military Communications Conference,pages 1 –7, oct. 2009.

138