1
Gateway Placement and Packet Routing For
Multihop In-Vehicle Internet Access
Hassan Aboubakr Omar, Student Member, IEEE, Weihua Zhuang, Fellow, IEEE, and Li Li, Senior Member, IEEE
Abstract—In-vehicle Internet access is one of the main applications of vehicular ad hoc networks (VANETs), which aims at providing the vehicle
passengers with a low-cost access to the Internet via on-road gateways. This paper introduces a new strategy for deploying Internet gateways on
the roads, together with a novel scheme for data packet routing, in order to allow a vehicle to access the Internet via multihop communications
in a VANET. The gateway placement strategy is to minimize the total cost of gateway deployment, while ensuring that a vehicle can connect
to an Internet gateway (using multihop communications) with a probability greater than a specified threshold. This cost minimization problem is
formulated by using binary integer programming, and applied to a realistic city scenario, consisting of the roads around the University of Waterloo.
To the best of our knowledge, the proposed deployment strategy is the first study to address the probability of multihop connectivity among the
vehicles and the deployed gateways. On the other hand, the developed packet routing scheme is based on a multichannel medium access control
protocol, known as VeMAC [1], [2], using time division multiple access. The performance of this cross-layer design is evaluated for a multichannel
VANET in a highway scenario, mainly in terms of the end-to-end packet delivery delay. The end-to-end delay is calculated by modeling each relay
vehicle as a queueing system, in which the packets are served in batches of no more than a specified maximum batch-size. The proposed gateway
placement and packet routing schemes represent a step toward providing reliable and ubiquitous in-vehicle Internet connectivity.
Index Terms—Gateway placement, packet routing, TDMA, delay analysis, and vehicular ad hoc networks.
F
1 INTRODUCTION
The emerging vehicular ad hoc network (VANET) consists of
a set of vehicles and a set of stationary units along the roads,
known as road-side units (RSUs), all equipped with wireless
communication devices. By employing vehicle-to-vehicle and
vehicle-to-RSU communications, VANETs can realize various
new applications to optimize the vehicle traffic, provide
infotainment to passengers, and enhance the public safety
for drivers and pedestrians. Most of the VANET high pri-
ority safety applications require that each vehicle broadcasts
information related to its current speed, acceleration, heading,
etc., to all the vehicles within its one-hop neighbourhood
[4]. Hence, supporting a reliable one-hop broadcast service
is a main requirement of a medium access control (MAC)
protocol for VANETs. The VeMAC protocol is based on time
division multiple access (TDMA) and is recently proposed to
satisfy the quality-of-service (QoS) requirements of VANET
safety applications [1], [2], [5]–[7]. The protocol is developed
specifically to provide a reliable one-hop broadcast service in
a VANET scenario, while supporting multichannel operation
to comply with the seven dedicated short range communi-
cation (DSRC) channels allocated by the Federal Commu-
nication Commission (FCC) for vehicular communications.
Demonstrated by ns-2 simulations employing mobility traces
of vehicles in a realistic city scenario, it is shown that the
VeMAC protocol significantly outperforms the IEEE 802.11p
standard [8] in satisfying the QoS requirements of periodic
and event-driven safety applications in VANETs [2].
• H. A. Omar and W. Zhuang are with the Center for Wireless Communications,
Department of Electrical and Computer Engineering, University of Waterloo,
200 University Avenue West, Waterloo, Ontario, Canada, N2L 3G1. E-mail:
{h3omar, wzhuang}@uwaterloo.ca
• L. Li is with the Communications Research Center, Ottawa, Ontario, Canada,
K2H 8S2. E-mail: li.li@crc.ca
This work is presented in part in IEEE INFOCOM 2014 [3].
This work was supported by a research grant from the Natural Science and
Engineering Research Council (NSERC) of Canada.
Although safety applications are the key motivation for
VANETs, the applications targeting passenger infotainment
have been gaining significant interests [9]. Infotainment im-
proves the driving experience, makes the trips more enjoy-
able, and may accelerate the deployment of VANETs due to
a small market penetration requirement as compared to that
needed for most of the safety applications [10]. One of the
main infotainment services of VANETs is in-vehicle Internet
access, which allows a vehicle to connect to the Internet by
communicating with Internet gateways deployed along the
road sides [9]. A vehicle can communicate with a gateway ei-
ther directly (when they are within the communication range
of each other) or via multihop communications, i.e., by using
other vehicles to relay packets to/from the gateway. The
first objective of this paper is to develop a new deployment
technique to determine the locations of the Internet gateways
on the roads, and define the maximum number of hops that
a gateway can use to communicate with a certain vehicle.
The proposed technique minimizes the total cost of gateway
deployment, and guarantees that a vehicle can connect to an
Internet gateway with a probability greater than a specified
threshold. The probability that a vehicle can connect to a
certain gateway is the probability of the existence of a net-
work path between them, where the network path consists
of a maximum number of hops that is determined by the
proposed technique for each deployed gateway. To the best of
our knowledge, no previous strategy for gateway placement
has considered the existence of network paths among the
vehicles and the deployed gateways. Since the existence of a
network path mainly depends on the vehicle traffic conditions
in the region where the gateways are deployed, we employ
the cutting-edge microscopic traffic simulator VISSIM [11] to
simulate the vehicle movement in the deployment region. The
proposed strategy is evaluated by considering the gateway
placement on the roads around the University of Waterloo
(UW) campus.
In addition to the deployment strategy of Internet gate-
2
ways, this paper introduces a novel packet routing scheme
which allows a vehicle to discover the existence of an Internet
gateway and to send/receive packets to/from the gateway
via multihop communications. The proposed routing scheme
is designed over the VeMAC protocol to exploit some useful
VeMAC features, such as the knowledge of all the nodes
(vehicles and gateways) which exist in a two-hop neighbour-
hood. This VANET architecture aims at achieving multihop
in-vehicle Internet access by using the routing scheme, while
satisfying the QoS requirements of the safety applications
via the VeMAC protocol. The proposed cross-layer design
between the MAC and network layers is evaluated in a high-
way scenario by studying the end-to-end delay required to
deliver a packet from a vehicle to a gateway through multiple
relay vehicles. The packet queueing at each relay vehicle is
considered in the end-to-end packet delay analysis. Another
performance metric under consideration is the percentage of
time slots per frame occupied by all the vehicles members of
the same two-hop set (THS)
1
, required to limit the average
packet delay to below a certain threshold at each vehicle.
Numerical results are presented to study the effect of different
parameters, including the vehicle density and the packet
arrival rate, on the performance metrics.
2 SYSTEM MODEL AND VEMA C PROTOCOL
The VANET under consideration consists of a set of vehicles
and a set of gateways placed along the road sides to provide
Internet connectivity to the vehicles. The vehicles employ
multihop communications to connect to the gateways, and
a gateway can communicate only with the vehicles located
within a maximum number of hops from the gateway. The
location of each gateway and the maximum number of hops
that it can use to communicate with a vehicle are determined
as described in Section 3. The VANET has one control channel
(CCH) for transmission of high priority safety messages and
control information, and multiple service channels (SCHs)
for transmission of safety and non-safety related application
messages. The VeMAC protocol [2] is used by all nodes to
access the communication channels, as briefly explained in
the following.
Each node has two transceivers: Transceiver1 is always
tuned to the CCH, while Transceiver2 switches among the
SCHs. On the CCH, the time is partitioned to frames consist-
ing of a constant number L of time slots of equal duration
t, and each second contains an integer (fixed) number of
frames. Each time slot is identified by the index (from 0
to L − 1) of the time slot within a frame, and each node
is identified by a unique MAC address and a set of short
VeMAC identifiers (IDs), where each VeMAC ID corresponds
to a certain time slot that the node is accessing per frame on
the CCH. Each VeMAC ID is chosen by a node at random,
included in the header of each packet transmitted in the
corresponding time slot, and changed if the node detects
that its ID is already in use by another node. For a certain
node, x, set T
x
denotes the set of time slots acquired by
node x on the CCH, and set N
x
is defined as the set of one-
hop neighbours of node x, from which node x has received
packets on the CCH in the previous L slots. Each node must
1. A THS is a set of nodes in which each node can reach any other node
in at most two hops.
acquire at least one time slot per frame on the CCH to
broadcast its safety messages, organize the communications
with the one-hop neighbours over the SCHs, and announce
the control information necessary to manage a distributed
time slot assignment on the CCH. For the purpose of time
slot assignment on the CCH, each node x should broadcast
the VeMAC ID(s) and the corresponding time slot(s) of each
node in set N
x
, once in each frame over one of its acquired
time slot(s) in set T
x
. The short length of a VeMAC ID (9 bits
[2]) serves to decrease the protocol overhead as compared to
broadcasting the corresponding MAC address. Now, suppose
node x is just powered on and needs to acquire a time slot.
By listening to the CCH for L successive time slots, node
x can determine set N
x
and the time slot(s) used by each
node in N
x
. Also, since each one-hop neighbour y ∈ N
x
announces the time slot(s) used by each node in N
y
, node x
can determine all the time slots used by each of its two-hop
neighbours, and consequently acquires one of the available
time slots as described in [2]. Then, set N
x
is updated by
node x at the end of each time slot, always based on the
packets received on the CCH in the previous L slots.
At each node, the packets which require transmission over
the SCHs are queued and served on a first-come-first-served
basis as follows. Suppose that node x needs to transmit a
packet to its one-hop neighbour y on a SCH. At its first op-
portunity to access the CCH, node x uses the corresponding
time slot in set T
x
to announce for node y the index of the
SCH over which the packet will be transmitted. Following
this announcement, both of nodes x and y turn Transceiver2
to the correct SCH and exchange packets. In each time slot
in T
x
, node x can announce on the CCH for a maximum of b
packets to be transmitted on the same SCH (not necessarily
to the same one-hop neighbour). At the start of a time slot in
T
x
, if the number of queued packets is less than the constant
b, referred to as the bath-size, node x does NOT wait until
the number of queued packets reaches b, but announces on
the CCH to transmit the existing packets on the chosen SCH.
Only one SCH index can be announced by node x in a time
slot on the CCH, and the batch-size b represents the maximum
number of packets which can be transmitted by node x on
the SCH after each announcement.
3 GATEWAY PLACEMENT
In order to deploy Internet gateways in a certain geographical
region, the map of the region is partitioned into equal-size
square areas, called cells, by overlaying a uniform square
grid over the map. Each cell which cannot be traversed by
a vehicle (e.g., a cell with no overlap with any part of the
roads) is removed from the set of cells, and the rest of the
cells are indexed from 1 to N
cells
, where N
cells
denotes the total
number of remaining cells. Potential locations for deploying
an Internet gateway are defined on the map (e.g., equally
spaced along each road) and the total number of potential
gateway locations is denoted by N
gate
. The potential locations
are indexed from 1 to N
gate
, and the cost of deploying a
gateway at the j
th
location is denoted by γ
j
. If a gateway
is deployed at the j
th
location, j = 1, ..., N
gate
, let ρ
j
denote
the maximum number of hops that the gateway can use to
connect to a certain vehicle, and ρ
max
the maximum allowed
value of ρ
j
for any j. Given the potential gateway locations,
3
it is required to find an optimal set J of location indices,
and determine the values of ρ
j
∀j ∈ J . Set J and the
corresponding ρ
j
values should minimize the total cost of
gateway deployment, while ensuring that the number of
gateways, which a vehicle located at the i
th
cell can connect
to, is not less than a specified value denoted by ν
i
, each
with a probability not less than a specified threshold, denoted
by α
i
∈ (0, 1], i = 1, ..., N
cells
. Based on the vehicle traffic
conditions in the region where the gateways are deployed,
let σ
ijk
denote the probability that a vehicle at the i
th
cell
can reach a gateway at the j
th
position within k hops, where
i = 1, ..., N
cells
, j = 1, ..., N
gate
, and k = 1, ..., ρ
max
. The values
of σ
ijk
∀i, j, k can be calculated by using a simulation model
of the vehicle traffic in the region where the gateways are
deployed, as described in Subsection 6.1. For each cell i,
define set β
i
as the index set of all gateways which can be
reached by a vehicle located in cell i within ρ
max
hops, i.e.,
β
i
= {j : σ
ijρ
max
6= 0}.
The gateway deployment is formulated by binary inte-
ger programming problem (1), which has three sets of de-
cision variables: x
j
, y
jk
, and z
im
, where i = 1, ..., N
cells
,
j = 1, ..., N
gate
, k = 1, ..., ρ
max
, and m ∈ β
i
for each i. Let
x
j
= 1 iff a gateway is deployed at the j
th
potential gateway
location, and y
jk
= 1 iff a gateway is deployed at the j
th
location and has ρ
j
= k. Therefore, objective function (1a)
represents the total cost of gateway deployment. For the third
set of decision variables, constraints (1b)-(1d) ensure that, a
variable z
ij
= 1 if [only if] a gateway is deployed at the
j
th
location and can reach a vehicle at the i
th
cell within ρ
j
hops with a probability greater than [greater than or equal
to] α
i
. Given this proposition, constraint (1e) guarantees that
a vehicle at any cell i can communicate with at least ν
i
gateways, each with a probability not less than α
i
. To show
the validity of the proposition, first suppose that x
j
0
= 1
for a certain j
0
∈ {1, ..., N
gate
}. Hence, constraint (1b) ensures
that there exists exactly one value k
0
∈ {1, .., ρ
max
} such that
y
j
0
k
0
= 1, which means ρ
j
0
= k
0
. Consequently, for each
cell i such that j
0
∈ β
i
, due to constraints (1c) and (1d),
z
ij
0
= 1 if σ
ij
0
k
0
> α
i
, and z
ij
0
= 0 if σ
ij
0
k
0
< α
i
(note that
ρ
max
P
k=1
σ
ij
0
k
y
j
0
k
= σ
ij
0
k
0
). If it happens that σ
ij
0
k
0
= α
i
, the value
of z
ij
0
can be 0 or 1 (more likely the solver let z
ij
0
= 1 to
satisfy constraint (1e)). On the other hand, if x
j
0
= 0, then
constraint (1b) sets y
j
0
k
= 0 ∀k, while constraints (1c) and
(1d) set z
ij
0
= 0 ∀i such that j
0
∈ β
i
.
minimize
x
j
,y
jk
,z
im
∈{0,1}
∀i,j,k,m
N
gate
X
j=1
γ
j
x
j
(1a)
subject to
ρ
max
X
k=1
y
jk
= x
j
, j = 1, ..., N
gate
, (1b)
z
im
≥
ρ
max
X
k=1
σ
imk
y
mk
− α
i
, i = 1, ..., N
cells
, m ∈ β
i
, (1c)
z
im
≤ 1 +
ρ
max
X
k=1
σ
imk
y
mk
− α
i
, i = 1, ..., N
cells
, m ∈ β
i
, (1d)
X
m∈β
i
z
im
≥ ν
i
, i = 1, ..., N
cells
. (1e)
Note that, the solution of problem (1) depends on the values
of σ
imk
in constraints (1c) and (1d), which mainly depend
on the vehicle traffic conditions in the region where the
gateways are deployed, as will be shown in Subsection 6.1.
The traffic conditions in different situations (e.g., weekday,
weekend, morning, rush hour, etc.) can be simulated by
the traffic simulator which generates the σ
imk
values, by
adjusting suitable parameters such as the rate of vehicle
arrivals to the road network, the probabilities of a left or
right turn at intersections, the schedule of public transit buses,
etc. Additionally, special incidences can be introduced in the
simulation, such as an accident or a road closure, to simulate
the vehicle traffic during such events. Hence, problem (1)
can be solved by using the σ
imk
values obtained from the
simulator based on target vehicle traffic.
4 ROUTING SCHEME
The proposed routing scheme consists of two main compo-
nents: 1) gateway discovery, which determines how the vehicles
discover the existence of a gateway and how they obtain
the information necessary to connect to that gateway; and
2) packet forwarding, which defines how a packet is delivered
via multihop communications from a vehicle to a gateway
and vice versa.
4.1 Gateway Discovery
In order to announce for its service, a gateway, g, periodically
broadcasts a gateway discovery packet (GDP) containing
the necessary information that a vehicle needs to access
the gateway’s service, such as the network layer address of
gateway g and the maximum number of hops, ρ
g
, that it
can use to communicate with a certain vehicle, where ρ
g
is
determined as described in Section 3. Before broadcasting a
GDP, as mentioned in Section 2, gateway g first announces
on the CCH the index of the SCH over which the GDP
will be broadcasted. Accordingly, each one-hop neighbour
which receives the announcement turns its Transceiver2 to the
correct SCH in order to receive the GDP. Among these one-
hop neighbours, a subset is chosen to re-broadcast the GDP,
and so on, until the GDP initiated by gateway g propagates
ρ
g
hops away from the gateway. The propagation of the GDP
in the network is controlled via a time-to-live (TTL) field in
the GDP header, which is originally set to ρ
g
− 1 by gateway
g and decremented by each vehicle which relays the GDP.
Every GDP is identified by a broadcast ID, together with
the network layer address of the gateway which initiated
the GDP. These two fields are used by a vehicle to discard
any duplicate of a previously received GDP. At each hop,
the subset of the vehicles which relay the GDP is determined
as follows. Suppose that a node, x, announces for a GDP
on one of its time slots, t
x
, on the CCH. For each node y
which receives the announcement, let D
y
denote the set of
one-hop neighbours of node y which did not receive the
announcement for the GDP sent by node x. Node y does
NOT relay the GDP if any of the following conditions holds:
• TTL = 0;
• D
y
= φ;
• ∃ z ∈ N
y
\D
y
such that D
y
⊆ N
z
and |N
y
| < |N
z
|, where
| · | denotes the cardinality of a set;
4
Fig. 1: The GDP relaying process based on a time slot assignment
on the CCH.
• ∃ z ∈ N
y
\D
y
such that D
y
⊆ N
z
, |N
y
| = |N
z
|, and
min
t
z
∈T
z
t
z
− t
x
+ L × I
(t
z
<t
x
)
< min
t
y
∈T
y
t
y
− t
x
+ L × I
(t
y
<t
x
)
,
where the notation I
(a<b)
equals 1 if a < b and equals 0
otherwise.
When node y receives an announcement for the GDP
from node x on time slot t
x
, it listens to the CCH for the
L − 1 time slots following t
x
. At the end of this listening
period, node y can determine sets T
z
and N
z
for each one-
hop neighbour z (recall that, each one-hop neighbour z
broadcasts the VeMAC IDs of the nodes in its N
z
set at
least once in each frame). Consequently, node y sets D
y
=
{z ∈ N
y
: ID
t
x
is not broadcasted by node z}, where ID
t
x
is the VeMAC ID of node x corresponding to time slot t
x
.
Consequently, node y relays the GDP if none of the mentioned
conditions is true. The last condition means that, node y does
not relay the GDP if it has a one-hop neighbour z which
satisfies that D
y
⊆ N
z
and |N
y
| = |N
z
|, and which can
access the CCH before node y at the end of the listening
period following time slot t
x
. This condition allows for a
faster propagation of the GDP in the network by choosing
the relay which can announce for the GDP on the CCH first.
Fig. 1 explains how a GDP broadcasted by gateway g is
delivered to all the vehicles located within ρ
g
= 3 hops from
the gateway by using a few number of transmissions. In Fig.
1, a group of nodes is surrounded by an ellipse iff any two
nodes in the group can reach each other in one hop (the same
applies to Fig. 2). That is, the set of one-hop neighbours of
a node, x, consists of all the nodes that are surrounded with
node x by a certain ellipse. Fig. 1 also shows the time slot
assignment on the CCH for all the nodes. Note that, different
nodes may access the same time slot if they do not belong to
the same THS, e.g., nodes x and w accessing time slot number
7. Each time slot that is highlighted in Fig. 1 is a time slot
over which an announcement for the GDP is broadcasted.
When gateway g announces for the GDP in the first frame,
vehicles h, i, and j receive the announcement and listen to
the CCH for a duration of 9 time slots (L = 10) in order to
decide whether or not to relay the GDP. Vehicle h does not
relay the GDP because D
h
= φ. Similarly, vehicle j does not
relay the GDP since D
j
= {m, n, u, v} ⊆ N
i
, |N
j
| = |N
i
|,
and vehicle i can access the CCH before vehicle j at the
end of the listening period. Consequently, vehicle i is the
only vehicle which relays the GDP at the first hop. At the
second hop, vehicles u, v, m, and n receive the GDP relayed
by vehicle i. Vehicle v relays the GDP since none of its one-
hop neighbours, u, m, and n (which received the GDP from
vehicle i) can reach vehicles x and y in the third hop, i.e.,
@ z ∈ N
v
\D
v
such that D
v
⊆ N
z
. On the other hand, among
the three vehicles u, m, and n, only vehicle u relays the
GDP, while vehicles m and n do not, for the same reason
explained before for vehicle j. At this point, TTL = 0 as it
has been decremented by the first and second hop relays.
Hence, at the third hop, when vehicles, x, y, and w receive
the GDP, none of these vehicles will relay it further. Note
that, when a certain relay broadcasts the GDP, every vehicle
which has previously received the same GDP can discard the
relayed copy by checking the broadcast ID and the address
of the initiating gateway, e.g., nodes j and h discard the GDP
relayed by node i.
4.2 Packet Forwarding
The packet routing from a vehicle to a gateway is done in
a proactive way. That is, each vehicle, v, stores a routing
table which has an entry corresponding to each gateway g
located within ρ
g
hops from vehicle v. Each routing table
entry at vehicle v consists of the network address of a certain
gateway, the number of hops that the gateway can be reached
in, and the MAC addresses of the one-hop neighbours of
vehicle v which can relay a packet to the gateway. The routing
table entry corresponding to a gateway, g, is created/updated
during the propagation of each GDP broadcasted by gateway
g, as explained in the following. Each vehicle, v, which relays
a GDP initiated by gateway g includes in the relayed GDP
the VeMAC IDs of a subset of its one-hop neighbours as
potential vehicles which can relay a packet to gateway g. This
set of potential relays included by vehicle v is denoted by
R
v
, and the cardinality |R
v
| should be limited to a certain
number, denoted by n
R
. The set R
v
consists of the one-
hop neighbours of vehicle v which received the GDP and
which can reach (in one hop) the highest number of one-
hop neighbours of vehicle v which have not yet received
the GDP, i.e., R
v
= {z ∈ N
v
\D
v
: |R
v
| ≤ n
R
, D
v
∩ N
z
6=
φ, |D
v
∩ N
z
| ≥ |D
v
∩ N
z
0
| ∀ z
0
/∈ R
v
}. If vehicle v has more
than one one-hop neighbour z ∈ N
v
\D
v
that have the same
|D
v
∩ N
z
| > 0, vehicle v gives priority of inclusion in set
R
v
to the one-hop neighbours that are farther from the node
from which vehicle v has received the GDP (each vehicle
is aware of the positions of all its one-hop neighbours [1]).
The reason is that, those one-hop neighbours are likely to
be closer to the vehicles to which vehicle v is going to relay
the GDP. When a vehicle, w, receives the GDP relayed by
vehicle v, by calculating R
v
∩ N
w
, vehicle w determines the
set of its one-hop neighbours which can relay a packet to
gateway g. Also, by subtracting the TTL field from ρ
g
, vehicle
w determines the number of hops currently separating it from
gateway g. Consequently, vehicle w creates/updates the entry
in its routing table corresponding to gateway g. If vehicle w
does not receive a GDP from gateway g for a time duration
larger than a specified threshold, the entry corresponding
to gateway g is removed from the routing table. The GDPs
should be broadcasted by each gateway at a broadcast rate
which ensures that the routing table at each vehicle is always
up-to-date based on the current network topology.
Fig. 2 explains how different vehicles update their routing
table entries corresponding to gateway g. When the gateway
broadcasts a GDP, among all the vehicles which receive the
GDP at the first hop (in the blue ellipse), only one vehicle
will relay the GDP based on the relaying scheme described
in Subsection 4.1. If the time slot assignment on the CCH
5
Fig. 2: Routing tables update during a GDP propagation.
requires that vehicle e is the one to relay the GDP, and if we
assume that n
R
= 4, then vehicle e includes in the relayed
GDP set R
e
= {e, d, c, b}. We have R
e
= {e, d, c, b}, because
D
e
= {h, i, f}, N
e
\D
e
= {e, d, c, b, a}, and D
e
∩ N
a
= φ.
When the GDP relayed by vehicle e is received by vehicles
f, h, and i at the second hop (in the red ellipse), each of
these vehicles finds the intersection of its N set with the
R
e
set, and updates the routing table entry corresponding
to gateway g accordingly. Vehicle f indicates in its routing
table that vehicles e, d, c, and b can relay a packet to gateway
g, while each of vehicles i and h only indicates vehicles e,
d, and c as potential relays (since vehicle b is not a one-hop
neighbour of either vehicle i or h). Similarly, at the second
hop, assuming that vehicle i decides to relay the GDP, it
includes set R
i
= {i, h} in the relayed GDP, which is used
by vehicle j at the third hop to determine the set of possible
relays to gateway g by calculating R
i
∩ N
j
= {i, h}.
To deliver a packet from a vehicle to a gateway, the vehicle
forwards the packet to a randomly chosen relay among the
ones listed in the routing table entry corresponding to the
intended gateway. This process is repeated by each relay
vehicle until the packet is finally delivered to the destination
gateway. For instance, in Fig. 2, if vehicle j wants to send a
packet to gateway g, by consulting its routing table, vehicle j
will forward the packet to either vehicle i or vehicle h equally
likely. Then, assuming that vehicle j chooses vehicle h to
relay the packet, vehicle h in turn forwards the packet to
a randomly chosen relay among vehicles e, d, and c, which
delivers the packet directly to gateway g.
Unlike the packet routing from a vehicle to a gateway,
which is done on a proactive hop-by-hop basis, packets are
routed from a gateway to a vehicle on a reactive source-
routing basis. That is, a source gateway includes in the header
of each transmitted packet the MAC address of each vehicle
which should relay the packet until it reaches the destination
vehicle. This information about the whole network path to a
certain vehicle, v, is provided to a gateway, g, through the
packets that it receives from vehicle v. That is, each relay
which forwards a packet from vehicle v to gateway g includes
its MAC address in the header of the relayed packet. In this
way, gateway g can find a network path to vehicle v by
reversing the order of the relays in the header of the most
recent packet received from vehicle v. Note that, the way
that the routing table at each vehicle is built ensures that
all the links on a network path from a vehicle to a gateway
are bidirectional. If gateway g does not have information
about the network path to a certain vehicle, or if the available
network path has not been updated for a time duration larger
than a specified threshold, the gateway broadcasts a route-
request packet, which propagates in the network as the GDP
does, until it reaches the destination vehicle. The vehicle then
replies by a route-reply packet which accumulates a network
path in its header while propagating back to the gateway.
5 PERFORMANCE ANALYSIS
This section investigates the end-to-end delay required to
deliver a packet from a vehicle to a gateway through multiple
relay vehicles. The total delay that a packet encounters at
each vehicle consists of two main components: queueing
delay and service delay. The queueing delay is the time
duration from the instant that a packet arrives to the queue
of a certain vehicle to the instant that the vehicle starts to
announce for the transmission of the packet on the CCH. This
delay includes the time duration that the packet spends in
the queue until it becomes in the head-of-line (HOL) batch,
i.e., among the first b packets, and the duration that the
transmitting vehicle spends on waiting for one of its acquired
time slots on the CCH (to announce the index of the SCH over
which the HOL batch will be transmitted). On the other hand,
the service delay of a tagged packet in the HOL batch consists
of the duration of one time slot, which is used to transmit
the announcement for the HOL batch on the CCH, and the
time duration required to deliver the tagged packet in the
HOL batch to its destination one-hop neighbour on the an-
nounced SCH. The analysis in this section neglects the second
component of the packet service delay, which in general is
relatively short compared to the packet queueing delay. When
“delay” is mentioned solely, it refers to the total delay, which
is the sum of the queueing delay and the duration of one
time slot. To simplify the delay analysis, we assume that each
vehicle, x, releases its time slot(s) in set T
x
and acquires a new
one(s) after each time it accesses the CCH. This assumption
guarantees that, at each vehicle, the intervals of time between
successive occasions of announcement for an HOL batch on
the CCH are independent and identically distributed (i.i.d.)
random variables. The assumption is appropriate in scenarios
with high rates of transmission collisions, where the vehicles
repeatedly release their time slots and acquire new ones.
Consequently, each vehicle can be modeled as a queueing
system with independent time intervals between successive
occasions of service, where the packets are served in batches
of a maximum batch-size b. In such a queuing system, when
the packets arrive according to a Poisson process, we denote
the system by M/G
(b)
/1. Hence, by considering only the
arrival of packets generated at the application layer of a
certain vehicle (assuming Poisson arrivals), the vehicle can
be modeled as an M/G
(b)
/1 queueing system. However,
each vehicle not only transmits the packets generated at its
own application layer, but also relays the packets arriving
from its one-hop neighbours. Therefore, in order to analyze
the end-to-end packet delay, a network of M/G
(b)
/1 queues
should be considered. The exact analysis of such a network
of queues is extremely difficult, even when b = 1 [12]. Hence,
to make the analysis tractable, we approximate the arrival
of packets which should be relayed by a vehicle as a single
Poisson process with rate parameter equal to the sum of
the packet arrival rates coming to the relay vehicle from
all its one-hop neighbours. That is, the superposition of the
departure processes of a number, N
input
, of M/G
(b)
/1 queues
(representing N
input
one-hop neighbours of a relay vehicle)
