-
Research ArticleParking Backbone: Toward Efficient Overlay
Routing in VANETs
Jinqi Zhu,1 Ming Liu,2 Yonggang Wen,3 Chunmei Ma,2 and Bin
Liu2
1 School of Computer and Information Engineering, Tianjin Normal
University, Tianjin 300387, China2 School of Computer Science and
Engineering, University of Electronic Science and Technology of
China, Chengdu, China3 School of Computer Engineering, Nanyang
Technological University, Singapore
Correspondence should be addressed to Jinqi Zhu;
[email protected]
Received 18 April 2014; Accepted 15 July 2014; Published 12
August 2014
Academic Editor: Nianbo Liu
Copyright © 2014 Jinqi Zhu et al.This is an open access article
distributed under the Creative CommonsAttribution License,
whichpermits unrestricted use, distribution, and reproduction in
any medium, provided the original work is properly cited.
In vehicular ad hoc networks (VANETs), message dissemination to
one or more vehicles is very challenging, due to frequentnetwork
disconnections anduncertain locations of the destination
vehicles.Deploying roadside units (RSUs) is a possible solution
toovercome the challenges, but it often requires a large amount of
investment. In this paper, we propose the idea of Parking
Backbone,which does not need any RSUs but leverages a virtual
overlay network formed by outside parked vehicles to track vehicles
and todisseminate messages between moving vehicles. Our scheme
consists of three parts. At first, to each road, parked vehicles
both atroadside and off street are grouped into a cluster as far as
possible. An urban overlay network is established based on this
type ofclusters for data transmission. Secondly, to a specific
vehicle, a daily mobility model is established, to determine its
location througha corresponding location prediction algorithm.
Finally, a novelmessage delivery scheme is designed to efficiently
transmitmessagesto destination vehicles through the proposed
virtual overlay network. Thanks to the extensive and stable outside
parking in cities,once grouped into the overlay structure, data
transmission can be easily achieved over the Parking Backbone.
Extensive simulationresults prove that our scheme achieves high
performance in message dissemination.
1. Introduction
Nowadays, as more and more vehicles are equipped withwireless
devices, positioning systems, and digital maps, large-scale
vehicular ad hoc networks (VANETs) are emergingas a new technology
in the near future. In VANETs, vehi-cles are allowed to not only
exchange messages with eachother as vehicle-to-vehicle
communication (V2V), but alsoexchange messages with roadside
infrastructures as vehicle-to-infrastructure communication (V2I)
[1]. The applicationsrange from driving safety, intelligent
transportation as well asinformation and entertainment
applications.
In order to facilitate better road safety and comfortdriving,
message dissemination among vehicle drivers is fastbecoming a
requisite to vehicular users. Through vehicularmessage
dissemination, we can check the latest traffic jamdata, get traffic
alert information, book desired restaurant,deliver announcement,
inquire certain services, and havemany other useful services, which
greatly benefit our dailyvehicle trips. However, due to the unique
characteristics of
VANETs, such as rapid-changing topology, high mobility ofvehicle
nodes, and intermittent node connectivity, how toefficiently
disseminate message in VANETs becomes verychallenging. Towards
solving the problem, many existingworks [2, 3] utilize one or two
metrics for next hop selec-tion. For example, in VADD [2], a
message is deliveredalong the currently available shortest-delay
trajectory to thedestination, in which the message delivery delay
dependson the vehicle density on each road. However, most ofthese
algorithms assume that the sender knows the currentlocation of the
receiver in advance. As a matter of fact, toa specific vehicle,
precisely determining its current locationis usually difficult due
to its high-speed movement. Thus,these foregoing works are probably
not suitable to tacklemessage dissemination among moving vehicles.
Moreover,flooding and opportunistic transmission are two
possiblemethods to deliver messages among moving vehicles, butthese
two methods are not so efficient since flooding costsmuch traffic
overhead and in opportunistic transmission,message delivery delay
might be very long.
Hindawi Publishing CorporationInternational Journal of
Distributed Sensor NetworksVolume 2014, Article ID 291308, 13
pageshttp://dx.doi.org/10.1155/2014/291308
-
2 International Journal of Distributed Sensor Networks
As promising augmentation to intervehicle communica-tion,
roadside units (RSUs) have drawnmuch research efforts[4, 5], for
routing between vehicles using them. Since RSUsare infrastructure,
it is much easier to send a message to afixed RSU than to a moving
object. In addition, the delay ofsending the message through the
fixed RSU-based network ismuch less than through the highly dynamic
VANET. Theseapproaches, however, have their own drawbacks. First,
asthe transmission range of RSUs is limited, they are
hardlyadaptive to rapid-changing traffic. Apparently, the
messagedelivery delay depends on opportunistically
encounteredpublic RSUs on a user’s trip. The sparser the deployment
ofRSUs is, theworse the performance is. Second, the installationof
RSUs is costly. Jupiter research [6] has shown that thesecosts can
be as high as 5,000 US dollars per unit. Third, RSUsmay not exist
in certain urban area or may be damaged oncein some incidental
happened disasters (e.g., flood, powercut, and hurricane). For
example, in the heavy hurricane𝑆𝑎𝑛𝑑𝑦 that happened in New York,
USA, since most ofinfrastructures stopped working due to being
destroyed orloss of power, the infrastructure based network cannot
offerservice to users for a long time [7].
In this paper, we propose the idea of Parking Backbone,which
does not need any RSUs but leverages a virtual overlaynetwork
formed by outside parked vehicles to delivery mes-sages
betweenmoving vehicles.Withwireless devices enabledin the vehicle,
parked vehicles can easily communicate withany vehicles driving
through them.Owing to the huge storagecapacity of the vehicle, a
large amount of available informa-tion can be stored inside the
parked vehicle. Thanks to theextensive and stable outside parking
in cities, once groupedinto the overlay structure, data
transmission can be easilyachieved over the Parking Backbone. Our
scheme consistsof three parts. At first, to each road, parked
vehicles both atroadside and off street are grouped into a road
cluster as faras possible. An urban overlay network is established
basedon road clusters for data transmission. Then, to a
specificvehicle, a daily mobility model is established, to
determine itslocation through a corresponding location prediction
algo-rithm. Finally, a novelmessage delivery scheme is designed
toefficiently transmit messages to destination vehicles throughthe
proposed virtual overlay network. We investigate ourscheme through
realistic survey and simulation. The resultsprove that our scheme
achieves high performance inmessagedissemination.
The major contributions of this work are as follows.
(i) To the best of our knowledge, we are the first toconsider
the using of Parking Backbone network ontop of the VANETs in
message dissemination. Ourscheme aims at fully exploiting the
benefits of outsideparking, without requiring any extra
infrastructureinvestment.
(ii) To a specific vehicle, we propose a location
predictionalgorithm to predict the vehicle’s location in a
precisemanner. Since messages can then be routed along anoptimal
routing to the destination vehicle, compared
with flooding and opportunistic transmission, mes-sage
transmission overhead in our protocol is largelyreduced.
(iii) We evaluate the proposed scheme through realisticsurveys
and extensive simulations. The numericalresults obtained verify
that our scheme achieveseffective routing performance.
The rest of paper is structured as follows. Section 2presents a
brief overview of related works. Section 3 describesthe assumption
and the framework of Parking Backbone.In Section 4, we explain the
design of Parking Backbone.Section 5 focuses on vehicle location
prediction, whileSection 6 discusses message dissemination through
ParkingBackbone. Section 7 evaluates Parking Backbone
throughrealistic survey and simulation, and Section 8 summarizes
thepaper.
2. Related Works
In recent years, many routing schemes have been proposedfor
VANETs. For example, in RBVT [8], a source vehicle thatneeds to
transmit a message to a destination first broadcastsa route request
message (RR) to discover a connected pathto the destination. After
RR reaches the destination vehicle,it sends a route reply that
contains the connected path tothe source vehicle. Since RBVT sends
messages only whena connected path is available, the message
delivery ratiomight be very low. Skordylis and Trigoni [9]
developed a D-Greedy algorithm for traffic routing. In D-Greedy
algorithm,a vehicle makes decision on whether to forward a
messageor to keep carrying it based on the message’s TTL and
itsdistance to the RSU.
Alternatively, approaches based on RSUs to disseminatedata
between mobile vehicles have also been considered. Forexample, in
[4], Mershad et al. operate by using vehicles tocarry and
forwardmessages from a source vehicle to a nearbyRSU and, if
needed, route these messages through the RSUnetwork andfinally send
them fromanRSU to the destinationvehicle. In addition, overlay
networks on top of VANETshave been discussed in previous works. In
[10], Hsieh andWang propose an overlay multicast for VANETs (OMV),
inwhich interested vehicles join a multicast tree initiated bya
source vehicle. The drawback of the method is that theconnectivity
between two group member nodes depends onthe intermediate nonmember
nodes, which is a major causeof long delay in data
transmission.
Finally, the authors in [11] believe that the huge amountof
parked vehicles is an abundant and underutilized compu-tational
resource that can be tapped into for the purpose ofproviding
third-party or community services. Since vehiclesare parked above
95% of a day average [11], permitting theircommunication in the
parking state will obviously improvethe connectivity of VANETs.This
means that more and moreattention will be paid to the parked
vehicles, which inspiresour motivation to utilize Parking Backbone
to performintelligent message routing in VANETs.
-
International Journal of Distributed Sensor Networks 3
Physicallayer
Applicationlayer
Logicallayer
Cluster 1
Cluster 2 Cluster 3
Destination Source
Overlay path
· · ·
· · ·
Figure 1: Layered architecture.
3. Proposed Framework3.1. Assumptions. First, we assume that the
onboard batteryhas no strict size and weight limits, so that the
powerconsumption is not a problem in daily parking. Second,we
assume that each vehicle is equipped with a positioningsystem
(e.g., GPS) and an electric map, which are alreadyavailable to most
of cars nowadays and will be common inthe future.Third, we assume
that some vehicle users will sharetheir devices and data during
parking.This could be achievedby incentive mechanism. According to
the previous work ofVANETs in [12], the businessmen may be willing
to provideall sorts of incentives to make it attractive for the
owner ofparked vehicles to share the resources in their parked
vehicles.Finally, we assume that the capacity of the vehicle is
largeenough for data storage.
3.2. Framework View. According to a real world urbanparking
report, street parking, off-street parking, and interiorparking
(garages or underground parking) account for 69.2%,27.1%, and 3.7%
of total, respectively. In this study, we mainlyfocus on the
outside parked vehicles, including street parkedvehicles and
off-street parked vehicles. We aim at construct-ing a stable
Parking Backbone on top of the highly dynamicVANETs.Then we provide
effective message routing betweenmoving vehicles and to track
vehicles for this purpose overthe proposed virtual infrastructure.
Since parked vehicles arenatural roadside nodes characterized by
large number, longtime staying, and wide distribution, they can
serve as stableservice infrastructure for the underlying dynamic
VANETs.Our layered framework architecture is shown in Figure 1.
Itconsists of three layers named physical layer, logical layer,
andapplication layer, respectively.
(1) Physical Layer. The physical layer is the vehicular adhoc
network, in which moving vehicles or parked vehicles
communicate with each other through one-hop or
multihoptransmission.
(2) Logical Layer. The logical layer is our Parking
Backboneformed by outside parked vehicles that work as both
datastorage units and data transmission units in the
virtualinfrastructure. This virtual overlay network self-organized
ina distributedmanner for the support of target vehicle trackingand
message dissemination on top of the VANET.
(3) Application Layer. Application layer focuses on safety
andcomfort applications for vehicle users. In this layer, the
drivercan send data to a target vehicle or issue certain request
fromit on the driver’s demand.
As shown in Figure 1, since the source vehicles dependon the
proposed overlay network for destination vehiclestracking
andmessages transmission, how to effectively estab-lish and
maintain the overlay network is an important issuethat needs to be
carefully addressed. Accordingly, we suggesta novel overlay network
design approach in this paper, asParking Backbone over VANETs.
4. Design of Parking Backbone
For the idea of Parking Backbone, we first define the
roadcluster and then focus on the overlay network design basedon
road clusters.
4.1. Road Cluster. In Parking Backbone, we try to group
allparked vehicles both on one road and off the road into aroad
cluster. It is viable, even though some parked vehiclesare isolated
from each other or belong to different partiallydistributed groups.
The reason is that, for the on-streetvehicles, the width of a
parking space is about 5 meters. Sincethe transmission range of the
vehicle is about 250 meters
-
4 International Journal of Distributed Sensor Networks
H1
H2
M1 M2
M4 M5(QH1)
M6
M7
M8
M9 M10
M5(QH2)V
Figure 2: A typical road cluster.
and the off-peak occupancy ratio averages almost 80%, fora
parked vehicle in a parking lot, the probability of findinganother
parked vehicle is very high. For the off-street parkedvehicles,
some vehicles will drive in and out of the parkinglots where they
parked in. These moving vehicles bridge thedisconnection in the
store-carry-forward way and help tomaintain the whole road
cluster.
A typical road cluster is as shown in Figure 2, which hastwo
cluster heads 𝐻1 and 𝐻2 and some cluster members as𝑀1–𝑀10. The
creation process of a road cluster is describedas follows. At
first, the vehicles located at the two ends of aroad are elected to
be cluster heads, so that a moving vehicleentering or leaving the
road will encounter one of them. Ina two-way road, the two cluster
heads, respectively, provideservices for the vehicles coming from
the nearest intersection.After the cluster head is determined,
other parked vehicleson that road or off the road join the cluster
and becomethe cluster members.The cluster numbers periodically
reporttheir ID number, position, routing request, and other
usefulinformation to the two cluster heads. Thus, the cluster
headsare able to manage all cluster members and their resources.We
notice that the road cluster will malfunction once thecluster head
became invalid. For example, in Figure 2, thecluster head 𝐻1 which
is isolated at the road end may haveno chance to inform others of
its leaving. Thus, we introducetwo quasi heads, as 𝑄𝐻1 and 𝑄𝐻2 in
Figure 2, to enhancethe robustness of the road cluster. A quasi
head is the clustermember which is on the same road with a cluster
head andnext to it.The quasi head always keeps a copy of recent
clusterstatus from the cluster head.
4.2. Overlay Network Construction. Instead of deployingRSUs, we
try to construct a Parking Backbone overlay net-work on top of the
physical VANETs, to achieve target vehicletracking and efficient
data delivery. Concretely, the virtualoverlay network construction
process has the following steps.
(1) Each road cluster starts a neighbor discovery processusing a
simplemechanismwith the help of intermedi-ate vehicles. For
instance, a cluster head of road cluster
𝐽 periodically broadcasts a 𝑁𝑒𝑖.𝑅𝐸𝑄 message thatcontains its
location and cluster number to the roadclusters within two or three
hops (the TTL time is setas 2 or 3 accordingly). When a road
cluster 𝐼 receivesa 𝑁𝑒𝑖.𝑅𝐸𝑄 message from road cluster 𝐽, it records
𝐽as its neighbor cluster. After the neighbor discoveryprocess, each
road cluster has the location of otherroad clusters within a
certain range. We also noticethat there exist singular road
clusters which have noneighbor found during neighbor discovery
process.The main reason can be explained from two aspects.Thefirst
reason is that the singular road clustermay belocated in a
relatively remote area; no outside parkingvehicles are near it. The
other reason stems from thefact that roadside parking is prohibited
at some maincity roads. If a road cluster is surrounded by
roadswhere roadside parking is prohibited, the distancebetween it
and other road clusters could be very long,and no neighbor road
cluster will be found in the𝑁𝑒𝑖.𝑅𝐸𝑄message broadcasting
process.
(2) To organize road clusters into a Parking Backbone,we let
each road cluster connect with all its neighborclusters. Thus, each
road cluster becomes a membernode and each connection between two
neighborcluster members becomes a virtual link of the
overlaynetwork.Moreover, eachmember nodemaintains thetopology map
of the virtual network. This could berealized with the help of
intermediate vehicles; forexample, eachmember node broadcasts its
location toothermember nodes over the network.This process
issimilar to link-state broadcast [13]. Figure 3 illustratesthe
concept of our overlay network.
As a survey [14] that explores on-street parking in citiespoints
out, the utilization of the parking spaces is quitestable. The
occupancy ratio, which is defined as occupiedspace-hour/available
space-hour, averages 93% throughoutone day. Even off-peak occupancy
ratio averages almost 80%.In addition, the authors in [15]
spatially describe the detailed
-
International Journal of Distributed Sensor Networks 5
Virtual overlay network
Road cluster 2
Roadcluster 3
Road cluster shown in the VANET Road cluster not shown in the
VANET
· · ·
Road
clus
ter 1
Figure 3: The virtual overlay network.
parking distribution in Montreal city in Canada at 12:00and
22:00, respectively, which demonstrates the substantivevehicle
sources in all hours of one day. Consequently, weconclude that,
guaranteed by the high utilization and widecoverage of outside
parking, establishing a stable ParkingBackbone is feasible.
The proposed overlay network has the following
distinctadvantages. First, the virtual topology can remain
staticeven though the underlying physical topology is
changingrapidly. Thus, we can shield the complicated
implementationdetails of the underlying physical network and tackle
themessage transmission issue on top of the VANETs. Second,as
member nodes of the overlay network, each road clustercan be
assigned a static network address like a static IPaddress on the
Internet. A routing protocol similar to the link-state routing can
then be designed for efficient data deliveryover the overlay
network. The other advantage is messagebundling. That is, messages
with the same destination canbe bundled into one message, with the
aim of reducingprocessing overhead and bandwidth consumption.
A real world urban parking utilization report [16] givesa
parking study conducted in old town Alexandria, fromwhich we obtain
the density of roadside parking reachesone roadside parked vehicle
per 7.58 meter road lengths.Similarly, [17, 18] provide the
roadside parking situation andthe road construction in Singapore,
respectively, from whichwe acquire that the density of roadside
parked vehicles inSingapore reaches one roadside parked vehicle
every 52.63meters in average, as shown in Table 1. Due to the
high
Table 1: On-street parking in two cities.
Area Parking space Road length (m)Distance
between twoparked vehicles
Old town 4,399 26,660 7.58Singapore 16,900 9,045,000 52.63
density of parked vehicle in the two cities, we deduce thatmost
of roadside parked vehicles can mutually connect inthe city. Thus,
our Parking Backbone achieves good networkconnectivity.
5. Vehicle Location Prediction
In this section, we first present the idea of vehicle tracking
andlocating. Second, how to establish vehicular mobility modelsto
achieve vehicle tracking is described. Third, we focus onthe method
to track a target vehicle. Finally, the algorithmto locate the
target vehicle based on its mobility model isdiscussed.
5.1. Overview of Vehicle Tracking and Locating. To transmitthe
message to a mobile target object, some previous workstry to use
flooding or large-scale multicopy delivery. How-ever, due to their
large traffic overhead and high energyconsumption in message
transmission, these algorithms areimpractical to be applied in
large networks. So, if we can
-
6 International Journal of Distributed Sensor Networks
Source vehicle S
The road cluster S will
meet
Matched road cluster
(1) Message transfer “P”
(2) Query“P, T1, road cluster number”
(4) Location prediction“ the road cluster D will meet
in the next moment”
(3) Echo“mobility model of D”
The road cluster
D will meet
(5) Transmit again“P”
Destination vehicle D
(6) Receive “P”
Figure 4: A typical destination vehicle tracking and
locationacquisition.
track the location of the target vehicle, the message can thenbe
transmitted more efficiently. However, due to the highlymoving
speed, tracking and preciously locating a movingvehicle are a tough
work, especially in no fixed infrastructurebased network. Thus, a
new method to track and locate avehicle is extremely needed.
Here we explain how to track and locate a specific vehicleby
giving a simple example. In Figure 4, a moving vehicle 𝑆needs to
send a message 𝑃 to a target vehicle 𝐷, in whichsteps of a specific
vehicle tracking and location acquisitionare concisely
described.
(1) Message transfer: when a driver issues a message 𝑃,the
source vehicle transmits 𝑃 to the road cluster itis about to
encounter (named 𝑅1) and records theencounter time as 𝑡
simultaneously.
(2) Query: if no information about vehicle 𝐷 is found inthe head
of 𝑅1, 𝑅1 then distributes a query messagecontaining the encounter
time and the ID of 𝑅1 overthe Parking Backbone, for obtaining the
mobilitymodel of the destination vehicle.
(3) Echo: Parking Backbone members are checked onthe destination
vehicle’s mobility model during thedissemination of the
querymessage, with which someroad clusters that contain the
mobility model of𝐷 arefound. Each of these road clusters then sends
an echomessage back to 𝑅1.
(4) Location prediction: the road cluster 𝐷 which isabout to
pass by (named road cluster 𝑅2) is predictedaccording to both its
mobility model and time 𝑡.
(5) Transmit again: message 𝑃 is sent to 𝑅2 over
ParkingBackbone.
Table 2: Vehicles and regular features.
Vehicle type Purpose Regular featuresBus Public YesPersonal
vehicle Business YesAmbulance, and so forth Emergency NoTaxi
Personal Yes
(6) Receive: 𝑃 is transmitted to the destination vehicle𝐷as soon
as𝐷 encounters 𝑅2.
There are several challenges in the implementation of thisidea.
First, since our target vehicle tracking and locating lie
inexplicit vehicular mobility model, how to describe
andmodelvehicle’s daily moving is the key content. Second,
efficientvehicle location tracking is necessary. Finally, precise
locationprediction should be considered.
5.2. Establishing Mobility Model. Table 2 lists some
vehiclestightly related to our life. Buses support public
transportationon some predefined routines. Taxies provide business
ser-vices for passengers. Ambulances and other special
vehiclesrespond to emergency calling, while personal vehicles
arecontrolled by individual drivers and follow their
respectivesocial activities. Since different vehicles move in
differentways, in the following, we introduce how to build
mobilitymodels for main types of vehicles.
5.2.1. For Personal Vehicle. Many researches validate
thatpersonal vehicles have regular mobility. Two to four
mainlocations cover more than 70% of the overall trips of apersonal
vehicle. Some previous mobility prediction schemestry to establish
the mobility pattern of a personal vehicleby recording its
node-specific trajectories from GPS data.Since a vehicle will
encounter a road cluster when enteringa road where parking is
permitted, we inspire to describethe movement of the personal
vehicle by recording the roadclusters it passes by. For example, a
series of trips takenby the driver can be kept as records in Table
3, where“No.” represents the ID of the road cluster that the
driverencountered in history, while the meeting time with eachroad
cluster is separated into day (Mon., Tues., Wed., Thurs.,Fri.,
Sat., Sun.) and the concrete time on that day. Duringmovement,
whenever a driver meets a road cluster, theonboard device will log
the encounter time and record theID of the road cluster.
We also find from Table 3 that, unlike usual, the drivertook a
different trip on Tuesday. This is possible for that hemight go to
other places such as hospital before going toworkplace on that day.
Moreover, in order to shorten datasize, the onboard device merges
the same trip trajectories byletting both themean time value and
the variance indicate theencounter time fluctuation of these
trajectories. A simplifiedmobility model of Table 3 is shown in
Table 4. With themobility model, home road cluster and destination
roadcluster for each vehicle are defined in Table 3.
-
International Journal of Distributed Sensor Networks 7
Table 3: Trip cluster record.
Day Time1 No. Time2 No. Time3 No. Time4 No. Time5 No.Monday 8:00
2 8:30 5 17:10 6 17:20 8 18:00 2Tuesday 8:10 2 8:35 5 17:10 6 17:25
8 18:06 2Tuesday 7:50 3 8:20 7 17:00 6 17:12 8 17:40 2Wednesday
8:05 2 8:53 5 17:30 6 17:39 8 18:15 2Saturday 14:00 9 14:15 4 18:00
4 18:20 9
Table 4: Simplified trip cluster record.
Day Time1(mean, variance) No.Time2
(mean, variance) No.Time3
(mean, variance) No.Time4
(mean, variance) No.Time5
(mean, variance) No.
Monday (8:05, 4.08) 2 (8:39, 9.42) 5 (17:17, 9.43) 6 (17:28,
12.69) 8 (18:07, 8.45) 2Tuesday 7:50 3 8:20 7 17:00 6 17:12 8 17:40
2Saturday 14:00 9 14:15 4 18:00 4 18:20 9
5.2.2. Home Road Cluster. The road cluster the driver startswith
and goes back to after a whole day’s driving (like roadcluster 2 in
Table 4).
5.2.3. Destination RoadCluster. If the encounter time
intervalbetween a road cluster and its next road cluster is larger
thana threshold 𝜇, this road cluster is a destination road
clusterfor this vehicle. Generally, the vehicle stays at its
destinationroad cluster for a long time.
When a moving vehicle shows an up-to-date trip, thevehicle
updates its previous mobility model and informsthe new model to all
its encountered road clusters timely.Consequently, road clusters
always keep the latest mobilitymodel of vehicles.
5.2.4. For Taxi. Huang et al. [19] prove that taxi mobilitynot
only has regular microscopic behavior, but also showsmacroscopic
features. A taxi located in a certain area prefersto go to another
area as the destination of a travel. Since itis very difficult to
capture the microscopic regularity of thetaxi, here we try to find
the highly frequented locations of thetaxi, in order to capture the
taxi’smacroscopicmovement. Fora taxi 𝑚, suppose the probability of
encounter road cluster 𝑖while driving is expressed as
𝑃𝑚𝑖=𝑓𝑚𝑖
𝑁𝑚
, (1)
where 𝑁𝑚is the total frequency of encounter road clusters
while 𝑓𝑚𝑖
denotes the times of meeting road cluster 𝑖 in taxi𝑚’s moving
history. Here we define a threshold 𝜂, if and onlyif 𝑃𝑚𝑖
is not smaller than 𝜂; road cluster 𝑖 is one of the
mostfrequently visited locations of this taxi.
5.2.5. For Bus. Generally, buses have predefined trips.
Theschedule of the bus, including the first bus, the last bus,
andthe frequency of the bus service, is available from
predefinedroutines. Since electric map is widely deployed in
busesnowadays, the road clusters that a bus will meet
whilemovingcan be obtained easily. Accordingly, a bus can estimate
the
meeting time with each road cluster on its trip accordingto its
start time, its average moving speed, and the distancefrom the
start point to each road cluster calculated usingthe electric map.
However, since the movement of the busis seriously affected by
traffic conditions (e.g., traffic jam),using the bus schedule to
predict bus movement is not soaccurate. Thus, instead of utilizing
bus schedule, we use thesamemethod as we used with personal
vehicle, to predict busmovement.
5.3. Mobility Model Diffusion and Location Tracking. When
amoving vehicle meets a cluster head, it will report its
mobilitymodel. By this means, vehicle mobility models in the
urbanarea are recorded after a time period. When a source vehicle𝑆
issues a message 𝑃 to a vehicle𝐷, since it has no knowledgeof the
location of 𝐷, it should firstly track the target vehicle.To track
a specific vehicle, the cluster head of 𝑅1 does thefollowing three
operations step by step.
(1) It checks whether 𝐷 is now within the same roadcluster with
itself. If so, it initiates internal commu-nication to distribute 𝑃
to𝐷 directly.
(2) Otherwise, it checks whether it has the mobilitymodel of 𝐷,
if so, indicating that 𝐷 can be trackedimmediately.
(3) If it does not have the mobility model of 𝐷, a querymessage
that contains the encounter time between 𝑆and 𝑅1 is broadcasted
over the overlay network, fortarget vehicle tracking, as we
described in Figure 5.Due to the small size of the query message
(containsonly the ID of destination vehicle and the ID of theroad
cluster which issues the query message), querymessage broadcasting
brings a litter extra overheadto the whole network. In our
simulation, it is shownthat the total size of query message for all
vehicles tobroadcast once is almost 1 KB.
5.4. Location Prediction. After obtaining the mobility modelof
the destination vehicle, the location of the destination vehi-cle
should be determined, for efficient message transmission.
-
8 International Journal of Distributed Sensor Networks
Input:(𝛼, 𝛽), the mobility model of destination vehicle𝐷 and a
threshold 𝜀 for location selection
Output: ID Numbers of the destination road clusters(1) match(𝛼,
day value in mobility model of𝐷)(2) for 𝑚 = 1;𝑚≤ 𝑘;𝑚++ do(3) if
((𝑇
𝑘+ 𝑑𝑘) ≥ 𝛽 ≥ (𝑇
1− 𝑑1)) then
(4) 𝑆⋅add(1);(5) end if(6) if ((𝑇
𝑚+ 𝑑𝑚) ≥ 𝛽 ≥ (𝑇
𝑚+1− 𝑑𝑚+1)) then
(7) if ((𝑇𝑚+1
− 𝑇𝑚) < 𝜇) or [((𝑇
𝑚+1− 𝑇𝑚) ≥ 𝜇) and ((𝑇
𝑚+1− 𝑑𝑚+1) − 𝛽) ≤ 𝜀)] then
(8) 𝑆⋅add(𝑚 + 1);(9) else(10) 𝑆⋅add(𝑚);(11) end if(12) end
if(13) if ((𝑇
𝑚− 𝑑𝑚) < 𝛽 < (𝑇
𝑚+ 𝑑𝑚)) then
(14) if ((𝑇𝑚+1
− 𝑇𝑚) ≥ 𝜇) then
(15) 𝑆⋅add(𝑚);(16) else(17) 𝑆⋅add(𝑚 + 1);(18) 𝑆⋅add(𝑚);(19) end
if(20) end if(21) end for(22) return 𝑆;
Algorithm 1: Destination road cluster prediction.
In the following, we propose a simple algorithm, as shownin
Algorithm 1, to effectively predict the next location of
thedestination vehicle.
The main idea of the algorithm is tried to find theroad cluster
the destination vehicle is currently parked inor about to encounter
by comparing the encounter timevalue provided in the query message
with the history timerecords in mobility model of the destination
vehicle. Notethat𝑑
1, 𝑑2, . . . , 𝑑
𝑘inAlgorithm 1denote variance of each time
record and 𝑇1, 𝑇2, . . . , 𝑇
𝑘represent mean time value of each
time record on day 𝛼.
6. Message Dissemination
Todisseminatemessages to destination vehicles efficiently,
weabstract the whole overlay network as a weighted connectedgraph
𝐺(𝑉, 𝐸), where 𝑉 is the set of road clusters, 𝐸 is theset of
virtual links between adjacent members, and weight𝐷𝑖𝑗on 𝐸
represents the connectivity degree between adjacent
member nodes 𝑖 and 𝑗. Since some adjacent road clusters
areintermittent connected by moving vehicles, it is necessary
topredict the connectivity degree between them. Figure 5 showsone
such weighted connected graph.
In order to calculate𝐷𝑖𝑗, we let adjacent road cluster heads
periodically send a delay probe packet to each other. Since,for
two neighbor nodes, the less the average message trans-mission
delay between them is, the better they connect witheach other, we
let the reciprocal of the estimated transmissiondelay between two
neighbors be their connectivity degree
2
1
18
0.3
0.2
0.3
0.14
0.125
0.46
0.13
9
0.1
1
7
32
0.4
0.54
6
5
0.6
Figure 5: The weighted connected graph.
value. The process of estimating the connectivity degree canbe
described as follows:
𝐷𝑖𝑗,𝑛=
𝑡𝑛+ 𝑇𝑖𝑗,(𝑛−1)
𝐷𝑖𝑗,𝑛−1
𝑇𝑖𝑗,(𝑛−1)
+ 𝑑𝑖𝑗,𝑛𝑡𝑛
, (2)
where parameters 𝐷𝑖𝑗,𝑛
, 𝑇𝑖𝑗(𝑛 − 1), 𝑑
𝑖𝑗,𝑛, and 𝑡
𝑛represent the
value of 𝐷𝑖𝑗after receiving 𝑛 delay probe replies, the sum
of timestamps of the 𝑛 delay probe replies, the 𝑛th delayprobe
reply, and the timestamp of the 𝑛th delay probe
reply,respectively.
We explain our message dissemination from two modes.In the
straightway mode, messages are routed along themaximum spanning
tree to their destination road clusters.The maximum spanning tree
could be easily acquired ateach member node through the classic
Kruskal’s algorithm.In the intersection mode, if two adjacent road
clusters onthe optimal path cannot connect with each other
directly,
-
International Journal of Distributed Sensor Networks 9
Table 5: Roadside parking in survey.
Street Policy Density Average𝑅04, 𝑅15, 𝑅26
No limits 280–320 veh/km 308 veh/km𝑅37, 𝑅79
Strict limits 15–25 veh/km 21 veh/km𝑅01, 𝑅12, 𝑅23, 𝑅45, 𝑅56,
𝑅67, 𝑅48, 𝑅68, 𝑅89
Moderate limits 72–180 veh/km 95 veh/km
Optimalcarrier
Figure 6: Select the next vehicle in the intersection.
we must check if there is a moving vehicle available tohelp
forward through intersections. Among all the movingvehicles in the
intersection, the vehicle which is moving inthe message-forwarding
direction is the optimal messagecarrier. If no optimal vehicle
exists, a vehicle that is movingtowards the reverse direction of
the message-forwarding isselected as the message carrier, as shown
in Figure 6. Ifthere is no vehicle available to forward ahead,
messagesshould be stored until an available vehicle appears.
Overall,in our method, messages are tried to be forwarded with
theminimummessage transmission delay and message-loss rateto their
destinations.
7. Performance Evaluation
In this section, we investigate realistic parking and
trafficprofile in real urban environments. We also evaluate
theperformance of Parking Backbone in NS-2.33.
7.1. Survey. We performed a six-week survey on an ordinaryurban
area of Chengdu, a city in China, for collecting realisticparking
and traffic profile. As shown in Figure 7, we extracta real street
map with the range of 1600m × 400m, whichcontains both 10
intersections and 14 bidirectional roadstotaled up to 7,860 meters
and 8 off-street parking lots. Eachintersection is marked by a
number from 0 to 9.
During the survey, we investigated the traffic and
roadsideparking statistics at 16:00, 18:00, and 22:00 of every
Tuesday,Thursday, and Saturday. We counted the vehicles parkedalong
each street within 5 meters and skipped those parkedin the middle
of obstacles or too far from the roads. To 33 on-street parking
lots, only fringed vehicles along road direction
0
98
7654
321
Figure 7: Road topology in simulation.
were calculated. As show in Table 5, there are three classesof
streets with different parking limits. The first class permitsfree
parking at roadside, as 𝑅
04, 𝑅15, and 𝑅
26, which results in
a very high node density.The second one, as𝑅37and𝑅
79, lacks
public parking spaces. These streets have a very low
vehicledensity that comes from some reserved parking spaces
andillegal parking.The remaining streets belong to the third
one,where it has amoderate vehicle density. Generally, the
parkedvehicle numbers are stable in different hours of a day.
Duringthe survey, we also calculated daily traffic by counting
thepassing vehicles within fifteen minutes at random positionsand
found traffic fluctuating from 300 veh/h (vehicle perhour) to 2200
veh/h at different times of one day.
-
10 International Journal of Distributed Sensor Networks
102030405060708090
100
Deli
very
ratio
(%)
RBVT CAN DELIVER Parking Backbone
Figure 8: Message delivery ratio under default parameters.
7.2. Simulation Environment. In this section, simulations
areconducted in NS-2.33. We use the open source
softwareVanetMobiSim-1.1 [20] to generate realistic urban
mobilitytraces. The default number of vehicles is set to 200, and
theirradio range is set to 250m. The average speed ranges from40 to
80 kilometers per hour. The MAC protocol is 2Mbps802.11. In the
simulation, parked vehicle nodes are locatedon random positions of
each street or each off-street parkinglot. For parked vehicles
located on street, they follow thedensity collected in Table 5.The
average parking time is 41.40minutes with a standard deviation of
27.17, which is providedin [21]. Each vehicle generates a new
request 𝑅
𝑟every 30 s.
By default, the sender chooses another random vehicle as
thedestination. The threshold values 𝜇 and 𝜂 are set to 2 hoursand
60%, respectively.
To compare our scheme with other VANET routingprotocols, we
simulated two protocols: CAN DELIVER [4]and RBVT [8]. We modified
the design of RBVT to makeeach intermediate vehicle carry
themessage for a specific time(default of 10 s) if it finds that
the next link is broken. Tosimulate the performance of CANDELIVER,
four RSUs weredeployed uniformly across the map. The transmission
rangeof RSU is set to 250m. The metrics used for comparison
aremessage delivery ratio, message delivery delay, and
averagevehicle traffic, which is the average traffic generated,
received,and forwarded by a vehicle during the simulation time.
7.3. Results under Default Parameters. In Figure 8, we com-pare
the message delivery ratio in Parking Backbone andthe other two
protocols under default parameters. We cansee that Parking Backbone
achieves higher message deliveryratio than CANDELIVER and RBVT.This
is mainly because,based on stable and large amount of roadside
parking andoff-street parking formessage delivery, Parking Backbone
hasstable contact opportunities and high-quality contacts
withparked vehicle. On the other hand, since the number of RSUsis
limited in CANDELIVER, the distance of the nearest RSUto a vehicle
is long. Hence, the opportunity to send a messageto the nearest RSU
is small. RBVT has the lowest deliveryratio since it sends messages
only when a connected path isavailable.
7.4. Varying the Number of Vehicles. We study the effect
ofvarying the number of vehicles on the performance of thethree
schemes. Figure 9(a) shows that the message deliveryratio of our
scheme is higher than those of the other twoprotocols. With the
increase of the number of vehicles, thedelivery ratio
ofCANDELIVERandRBVT increases steadily.The reason is that more
vehicles provide better possibilitiesand more contact opportunities
to select a relay vehicle todelivery messages in dense traffic.
However, since ParkingBackbonemainly is based on stable roadside
parking and on-street parking for message transmission, it has
stable contactopportunities and high-quality contacts, and slightly
affecttedby vehicular number change. In Figure 9(b), the
messagedelivery delay of CAN DELIVER is less than RBVT in
denseconditions, which proves that routing message via RSUs
isfaster in such cases. Figure 9(c) shows that the average
vehicletraffic of CAN DELIVER and RBVT becomes high whenthe number
of vehicles increases due to redundancy, whichproduces high
traffic.
7.5. Varying the Request Rate. In this section, we discuss
theperformance of the three schemes when varying the requestrate
𝑅
𝑟between 1 to 60 requests per minute. As Figure 9(d)
describes, the message delivery ratios of the three
schemesdecrease as 𝑅
𝑟increases due to high congestion and message
collisions. Figure 9(f) shows that the average vehicle traffic
ofCAN DELIVER is less affected than that of our scheme as 𝑅
𝑟
increases since the latter uses flooding to find
vehiclemobilitymodel before a message is sent. On the other hand,
as can beseen from Figure 9(e), since Parking Backbone tries its
bestto use stable parked vehicles to deliver messages, it speeds
upthe dissemination of message.
7.6. Varying the Number of RSUs. In this section, we uni-formly
deploy 1, 4, 10, and 20 RSUs in the simulation areaand then compare
the performance of CAN DELIVER withboth our scheme and RBVT.The
results are shown in Figures10(a)–10(d). In Figure 10(a), the
delivery ratio of our protocolis higher thanCANDELIVERwith 4 RSUs
but lower than thelatterwith 10 and 20RSUs.This is reasonable
sincewhenmoreRSUs are deployed, a vehicle to its nearest RSU will
be closer.Hence, the opportunity to send a message to the nearest
RSUwill increase. Figure 10(b) depicts that the message
deliveryratio of CAN DELIVER increases as the number of
RSUsincreases.The reason is the same as described in Figure
10(a).We also notice that when the number of RSUs is large
enoughsuch that the whole network is well covered, the delivery
ratiowill significantly increase and the average message
deliverydelay will largely decrease (see Figure 10(c)).
8. Conclusion
This paper proposes Parking Backbone, which lets extensiveparked
vehicles support vehicle tracking andmessage dissem-ination as
roadside units. In this paper, we first investigatethe design of
Parking Backbone. Then, we establish mobilitymodel for different
vehicles and propose algorithm to predictthe rough location of the
destination vehicle. Finally, effective
-
International Journal of Distributed Sensor Networks 11
30
40
50
60
70
80
90
Number of vehicles
Deli
very
ratio
(%)
40035030025020015010050
(a) Delivery ratio
0
5
10
15
20
25
30
35
Deli
very
del
ay (s
)
Number of vehicles40035030025020015010050
(b) Delivery delay
0
5
10
15
20
25
30
35
40
Aver
age v
ehic
le tr
affic (
kb/s
)
Number of vehicles40035030025020015010050
(c) Average vehicle traffic
10
20
30
40
50
60
70
80
Deli
very
ratio
(%)
Request rate100 20 30 40 50 60
(d) Delivery ratio
10
20
30
40
50
Deli
very
del
ay (s
)
Request rate100 20 30 40 50 60
RBVTCAN DELIVER Parking Backbone
(e) Delivery delay
10
15
20
25
30
35
40
Aver
age v
ehic
le tr
affic (
kb/s
)
Request rate100 20 30 40 50 60
RBVTCAN DELIVER Parking Backbone
(f) Average vehicle traffic
Figure 9: Impact of number of vehicles and request rate.
-
12 International Journal of Distributed Sensor Networks
90
30
40
50
60
70
80
Deli
very
ratio
(%)
RBVTOursCAN DELIVER (4 RSUs)
CAN DELIVER (1 RSU)CAN DELIVER (10 RSUs)CAN DELIVER (20
RSUs)
(a) Delivery ratio over number of RSUs
30
40
50
60
70
80
90
RBVTParking Backbone
Deli
very
ratio
(%)
Number of vehicles40035030025020015010050
CAN DELIVER (RSUs = 4)
CAN DELIVER (RSUs = 10)CAN DELIVER (RSUs = 1)CAN DELIVER (RSUs =
20)
(b) Delivery ratio
10
15
20
25
30
35
Deli
very
del
ay (s
)
Number of vehicles40035030025020015010050
RBVTParking BackboneCAN DELIVER (RSUs = 4)
CAN DELIVER (RSUs = 10)CAN DELIVER (RSUs = 1)CAN DELIVER (RSUs =
20)
(c) Delivery delay
6
12
18
24
30
36Av
erag
e veh
icle
traffi
c (kb
/s)
Number of vehicles40035030025020015010050
RBVTParking BackboneCAN DELIVER (RSUs = 4)
CAN DELIVER (RSUs = 10)CAN DELIVER (RSUs = 1)CAN DELIVER (RSUs =
20)
(d) Average vehicle traffic
Figure 10: Parking Backbone, RBVT, and CAN DELIVER for different
number of RSUs versus number of vehicles.
message delivery scheme is discussed. The evaluation ofParking
Backbone confirms its effectiveness as compared torecent routing
protocols for VANETs.
Conflict of Interests
The authors declare that there is no conflict of
interestsregarding the publication of this paper.
Acknowledgment
This work was supported by the National Natural Sci-ence
Foundation of China (Grant nos. 61103227, 61103226,61272526,
61170256, 61173172, 61173171, and 61370204).
References
[1] S. Yousefi,M. S. Mousavi, andM. Fathy, “Vehicular Ad hoc
Net-works (VANETs): challenges and perspectives,” in Proceedingsof
the 6th International Conference on ITS Telecommunications(ITST
’06), pp. 761–766, June 2006.
[2] J. Zhao and G. Cao, “VADD: vehicle-assisted data delivery
invehicular Ad hoc networks,” IEEE Transactions on
VehicularTechnology, vol. 57, no. 3, pp. 1910–1922, 2008.
[3] B. Karp and H. T. Kung, “GPSR: greedy perimeter
statelessrouting forwireless networks,” in Proceedings of the ACM
6thAnnual International Conference on Mobile Computing
andNetworking (MOBICOM ’00), pp. 243–254, August 2000.
[4] K. Mershad, H. Artail, and M. Gerla, “We can deliver
messagesto far vehicles,” IEEE Transactions on Intelligent
TransportationSystems, vol. 13, no. 3, pp. 1099–1115, 2012.
-
International Journal of Distributed Sensor Networks 13
[5] J. P. Sheu, C. Y. Lo, andW.K.Hu, “A distributed routing
protocoland handover schemes in hybrid vehicular ad hoc networks,”
inProceedings of the 17th IEEE International Conference on
Paralleland Distributed Systems (ICPADS ’11), pp. 428–435,
Tainan,Taiwan, 2011.
[6] Jupiter Research, “Municipal wireless: partner to spread
risksand costs while maximizing benefit opportunities,” Tech.
Rep.,Jupitermedia Corporation, 2005.
[7]
http://nymag.com/daily/intelligencer/2013/05/new-york-hur-ri-cane-preparations-sandy-summer.html.
[8] J. Nzouonta, N. Rajgure, G. Wang, and C. Borcea,
“VANETrouting on city roads using real-time vehicular traffic
informa-tion,” IEEE Transactions on Vehicular Technology, vol. 58,
no. 7,pp. 3609–3626, 2009.
[9] A. Skordylis and N. Trigoni, “Efficient data propagation
intraffic-monitoring vehicular networks,” IEEE Transactions
onIntelligent Transportation Systems, vol. 12, no. 3, pp.
680–694,2011.
[10] Y. L. Hsieh and K. Wang, “Road layout adaptive
overlaymulticast for urban vehicular ad hoc networks,” in
Proceedingsof the IEEE 73rdVehicular TechnologyConference (VTC
’11),May2011.
[11] N. B. Liu,M. Liu,W. Lou,G. Chen, and J. Cao, “PVA
inVANETs:stopped cars are not silent,” in Proceedings of the IEEE
AnnualJoint Conference of the Computer and Communications
Societies(INFOCOM ’11), Shanghai, China, 2011.
[12] S. Olariu, I. Khalil, and M. Abuelela, “Taking vanet
totheclouds,” International Journal of PCC, pp. 7–12, 2011.
[13] J. F. Kurose and K. W. Ross, Computer Networking: A
Top-downApproach Featuring the Internet, 2012.
[14] A. Adiv andW.Wang, “On-street parkingmeter behavior,”
1987.[15] C. Morency and M. Trepanier, “Characterizing parking
spaces
using travel survey data,” CIRRELT, 2006.[16]
http://alexandriava.gov/uploadedFiles/localmotion/Existing-
ParkingConditions.pdf.[17]
http://www.lta.gov.sg/content/ltaweb/en/publications-and-
research.html.[18] http://www.onemotoring.com.sg.[19] H. Y.
Huang, Y. M. Zhu, X. Li, M. Li, and M. Wu, “META:
a mobility model of MEtropolitan TAxis extracted from
GPStraces,” in Proceedings of the IEEEWireless Communications
andNetworking Conference 2010 (WCNC ’10), April 2010.
[20] J. Härri, F. Filali, C. Bonnet, andM. Fiore,
“VanetMobiSim: gen-erating realistic mobility patterns for VANETs,”
in Proceedingsof the 3rd ACM International Workshop on Vehicular Ad
HocNetworks (VANET ’06), pp. 96–97, September 2006.
[21] B. Albanese and G. Matlack, “Utilization of parking lots
inHattiesburg, Mississippi, USA, and impacts on local
streams,”Environmental Management, vol. 24, no. 2, pp. 265–271,
1999.
-
International Journal of
AerospaceEngineeringHindawi Publishing
Corporationhttp://www.hindawi.com Volume 2014
RoboticsJournal of
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Active and Passive Electronic Components
Control Scienceand Engineering
Journal of
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
International Journal of
RotatingMachinery
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Hindawi Publishing Corporation http://www.hindawi.com
Journal ofEngineeringVolume 2014
Submit your manuscripts athttp://www.hindawi.com
VLSI Design
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Shock and Vibration
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Civil EngineeringAdvances in
Acoustics and VibrationAdvances in
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Electrical and Computer Engineering
Journal of
Advances inOptoElectronics
Hindawi Publishing Corporation http://www.hindawi.com
Volume 2014
The Scientific World JournalHindawi Publishing Corporation
http://www.hindawi.com Volume 2014
SensorsJournal of
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Modelling & Simulation in EngineeringHindawi Publishing
Corporation http://www.hindawi.com Volume 2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Chemical EngineeringInternational Journal of Antennas and
Propagation
International Journal of
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
Navigation and Observation
International Journal of
Hindawi Publishing Corporationhttp://www.hindawi.com Volume
2014
DistributedSensor Networks
International Journal of