2017 IEEE Symposium on Computers and Communications (ISCC)

A Novel Urban Traffic Management Mechanism

Based on FOG
Celso A. R. L. Brennand∗‡§ , Azzedine Boukerche‡ , Rodolfo Meneguette‡ and Leandro A. Villas∗
∗ Institute
of Computing, University of Campinas, Brazil
‡ PARADISE,
University of Ottawa, Canada
§ UAST, Federal Rural University of Pernambuco, Brazil

Email: celso@lrc.ic.unicamp.br, {boukerch, rmenegue}@site.uottawa.com and leandro@ic.unicamp.br

Abstract—An increase of vehicles in a city without an efficient
infrastructure of traffic management can cause damages not
only financial but also environmental and social. In order to
support urban traffic system to relieve the traffic congestion and
the damage caused by congestion of vehicles, in this paper, we
propose a mechanism for Intelligent Transport Systems named
FOg RoutE VEhiculaR (FOREVER), in order to assist the traffic
management in Vehicular Networks (VANET). For achieving this,
FOREVER will detect and recommend an alternative route for
the vehicles to avoid previous congestion. FOREVER is based on
FOG computing paradigm that aims of to compute and modify
the route of the vehicle to avoid the formation of congestion. Thus,
the results show that FOREVER had a reduction about 7.9% of
the CO2 emissions, 8.3% the stop time and 7.6% of the trip time.
I. I NTRODUCTION
There is an increasing rise in the number of vehicles in the
transport system each year. According to the U.S. Department
of Transportation, in a period of 9 years (from 2002 to 2011),
the number of registered vehicles increased from 234 million
to 253 million [1]. Furthermore, an estimate made by IBM [2]
showed that the current number of vehicles in the world exceeds
1 billion and this number will double by 2020. This means that
the transport system can have a significant influence on society
and the economy.
Modern urban society has to tackle many problems arising
from traffic congestion. The estimated cost of traffic congestion
in the U.S. is more than 160 billion dollars per year [3].
In the European Union, it is approximately 2 percent of its
gross domestic product (GDP) [4] and in Brazil it amounts
to US$ 80 billion [5]. However, the problems of traffic
congestion cannot be solved by extending or improving the
road network because of the high costs incurred, as well
as environmental and geographical constraints. An efficient
computational infrastructure is needed to deal with the traffic,
not only with regard to particular vehicles but also that covers
the entire transport system of the city.
The Intelligent Transport System (ITS) is a combination of
several technologies that is aimed at assisting the management
of the transport system [6]. Thus, ITS offers several services
and applications for monitoring, controlling and optimizing
vehicular traffic [7]. The ITS can take advantage of the Fog
paradigm. Fog computing is an emerging computing paradigm
with storage, networking and processing capabilities [8]. Unlike
Clouds and DataCenters, which have their resources located
in the Core of the network (Internet), the Fog resources are
located on the edge of the network [9]. Thus, the main features
of Fog computing are the proximity of its resources to where
they are needed, its geographic distribution, heterogeneous
communication technologies and mobility support [10]. These
enable ITS to respond faster to user requests and meet all the
Quality of Service (QoS) parameters of the requested service.
The route management service is one of most important because
it handles vehicle management and logistics which is the main
problem in cities.
In the literature, there are several studies that address the
problem of route management in public roads [11], [12], [13].
Most of them employ an architecture for carrying out the
monitoring and control of traffic that is based on the information
about the vehicles, as well as the characteristics of the routes.
However, these architectures also have to handle a huge amount
of data generated by the devices that are embedded in the
vehicles and used for monitoring the traffic. In addition, the
response time for executing the request must be within an
acceptable time frame so that the information is still useful to
the user.
Given these challenges, we propose a real-time route
management system called FOg RoutE VEhiculaR (FOREVER).
FOREVER is an architecture based on a FOG computing
paradigm that uses the RSU as a FOG entity to management,
independently, the traffic of vehicles inside of your region. This
involves using the RSUs to monitor the traffic conditions from
the information s received from the vehicles. This information
is used by FOG to calculate the vehicle route.
This paper is structured as follows. In Section II, we
describe the most relevant related solutions. Section III we
introduce the FOREVER re-routing mechanism and its function-
alities. In Section IV, we introduce our experimental scenario
and analyze the simulation results. Finally, in Section V we
summarize the work, providing direction for future works.
II. R ELATED W ORK
FOREVER is a real-time vehicular network mechanism that
assists in managing the flow of vehicles in cities. It enables
the traffic congestion of vehicles to be reduced by cutting the
travel time and also seeks to lower the rate of CO2 emissions
and fuel consumption. These problems are extensively explored
in the literature, and some solutions have been proposed to
optimize the flow of vehicles in cities [11], [13], [14], [12].
PAN et-al. [11] propose a centralized system for predicting
and detecting traffic jams and reducing their harmful effects.
Data about vehicular traffic is gathered by the system in real
time and used to detect and control traffic congestion. Three

978-1-5386-1629-1/17/$31.00 ©2017 IEEE

 2017 IEEE Symposium on Computers and Communications (ISCC)
strategies were employed for re-routing the vehicles: i) Dynamic
Shortest Path (DSP), which calculates the shortest path; ii)
Random k Shortest Paths (RkSP), which calculates how the
k alternative can be computed and one chosen at random; iii)
Entropy Balanced k Shortest Paths (EbkSP), which calculate
the k alternative in a similar way to RkSP. However, the EbkSP
takes into account the impact that each of the k paths might
have on the future density of the way.
Meneguette et. al. [14] proposed a solution for detecting
and controlling congestion in urban and highway environments.
The proposal solution is based on an Artificial Neural Network
(ANN) that is designed to detect and classify the levels of
congestion on roads, as well as suggest new routes for drivers
to enable them to avoid congested roads. ANN used the average
speed and the density of vehicles on the road as the input of the
system to classify the traffic. The results of the classification
are propagated through the beacon messages. When a vehicle
receives a message about a congested road, it can decide
whether to keep to its current route or calculate the advantages
of an alternative route.
Doolan et-at. [13] set out a system, called EcoTrec, where
each vehicle disseminates information about its fuel consump-
tion and current route periodically. EcoTrec uses its data to
determine the roads conditions. The routes for each vehicle
are calculated in a distributed way so that each vehicle can
calculate its best route by means of Dijkstra’s algorithm.
Souza et al. [12], proposed SCORPION (System with
Cooperative Routing to improve traffic condition) which is
a real-time traffic management service for traffic congestion
detection and route planning using hybrid VANET commu-
nication. The SCORPION is divided into two main parts: i)
congestion detection and traffic classification; ii) cooperative re-
routing. SCORPION carries out congestion detection and traffic
classification using K-NN (k nearest neighbors) in accordance
with the average speed and the density of the path.
Compared with FOVEREVER, these solutions lack some
features. In the works of [12], [11], all the vehicles require
information about new routes from a central entity (RSU). This
often causes a longer processing time for the routes and a
high traffic bandwidth in the network. According to studies in
the [13], [14], the route is computed in a distributed way and
each vehicle is allowed to calculate its own route. However,
these solutions lack a complete knowledge of the condition of
all the city roads and only have information about their local
neighborhood. Thus, several overlapping routes between the
vehicles may have to be computed, which means there might
be new traffic jams. Moreover, the scalability of the system
is compromised by a large number of messages exchanged
between the vehicles.
For this reason, the FOVEREVER uses several RSUs with
a FOG paradigm capability. In this way, the response time
can be reduced more than with [11], [12], because each RSU
only computes new routes for vehicles that are located in its
coverage area. In addition, this helps to solve the problems
of the distributed routing system observed in [13], [14], since
each FOG has knowledge of a particular region of the map,
and can thus avoid allocating the same route to several vehicles
in its own region.
The large demand for computational resources generated by
the high volume of data and services required by ITS, has led
to systems being designed that integrate cloud computing with
the VANETs [15], [16], [17], [18]. However, since the cloud
data centers are centralized, and are usually far away from
the end-users, (and this requires a constant and high network
bandwidth), this paradigm is not recommended for some ITS
services which require a faster response time, such as routing
services. It is unnecessary to send all ITS data to a centralized
location because its data is spatially correlated [19] and hence
its data are only applicable to a certain region. As a means of
overcoming these problems, we propose an architecture based
on FOG computing in which the computational resources are
moved to the network edge, where they are required (e.g. the
RSU, vehicles, sensors) and the data are collected.
III. P ROPOSED S OLUTION
In this section, we describe the solution to our proposal
called FOREVER: FOg RoutE VehiculaR. FOREVER is a
route management mechanism that uses FOG computing. FOG
computing can make both data and computing available closer
to the place where they are required. Thus, in the FOREVER
system, each FOG is responsible for collecting, storing and
processing data in a specific region; this means they can
be moved closer to vehicles, and result in more efficient
communication and a speedier response system.
FOREVER uses RSU and sensors that are distributed in the
entry map to make a set of FOG. This requires the proposed
solution to divide the city into areas and implies that each area
will be responsible for a single FOG, which is independent of
each other. These areas correspond to the RSU communication
coverage (see the orange circle in Figure 1). Each RSU
possesses storage, processing, and wireless communication
capabilities and thus comprise a single FOG. Furthermore, It
is responsible for managing all the data and components (e.g.,
road sensors, vehicles).
This Fog seeks to obtain knowledge about the part of the
city that encompasses the RSU coverage communication area
that belongs to it. In this work, a single RSU is included for
each FOG and the RSU is homogeneously distributed in the
map to achieve full coverage. If the vehicle is at the FOG
intersection, the closest RSU is chosen. The RSU transmission
power influences the number of RSU disposed in the city
consequently affecting the system efficiency and the monetary
cost to perform the RSUs deployment. Whether coverage area
is small, the number of RSU are greater and only a few vehicles
involved in the communication for each RSU, and hence, there
are fewer control messages in the network. Otherwise, the
network could suffer from a large number of control messages
being sent through the vehicle communication system.
FOREVER also uses a virtual section of the map called Area
of Knowledge (AoK). This area is a region where each RSU
has knowledge of the roads (their features and current situation
) and is able to compute a new route for the vehicles that are
inside its RSU (see the yellow circle in Figure 1). Moreover,
the AoK is at least the size of the RSU communication area.
The size of the AoK affects the performance of the mechanism
 2017 IEEE Symposium on Computers and Communications (ISCC)

about the condition of the road through the publish-subscribe

method to make the data consistent.
The process of RSU collecting data transmitted by vehicles
begin when the beacon time step is reached (stage A in the
Figure 2). The vehicle creates the beacon message (MSG) and
sends to the vehicular network (B). Whether RSU receives the
MSG, it verifies if there is not a duplicate MSG and if the
origin is in your AoK (C). If so, the RSU updates information,
otherwise, it will drop the MSG. Whether other vehicles receive
the MSG, it will verify if there is not a duplicate MSG (D). If
yes, it will drop the message, otherwise, the vehicles will check
if the origin of MSG is on the same road (E). If is true, their
beacons MSG are rescheduled for next beacon time and the
MSG data received are aggregated with data from the current
vehicle (e.g, average between both speeds) and the MSG is
scheduled for forwarding. After the data gathering, there is a
data processing and aggregate phase in each RSU.

No
Fig. 1. ITS-FOG Architecture
Is beacon
Start Interval? A
since the greater the area, the more knowledge of the map and
a smaller area it has, and the faster the computation time of the Yes
congestion control system. The RSUs exchange information Vehicle
between themselves to obtain knowledge of roads that are not create/ B
send MSG
their responsibility. One of the functionalities of the FOG is a
distributed congestion control mechanism. This calculates new MSG
wifi
routes for all the vehicles periodically to prevent traffic passing RSU Vehicle
through congested areas.
Yes
duplicate
MSG?
D
FOREVER has some parameters which can be reconfigured duplicate
Yes
MSG? No
independently for each FOG, depending on the conditions of
each scenario (e.g. the traffic conditions of a particular region, C
No
E MSG Aggregate data
time of day, density) in real time. These parameters are the originated on to MSG and
Yes
Is my AoK? No my current reschedule my
routing interval and the number of alternative routes (K). The road? beacon
parameter for changes in real-time is beyond the scope of this Yes No
work.
Update Schedule MSG
data retransmit
Another parameter used by the system is the route size factor.
The route size factor determines how much longer (in percent)
End
the new route may be in relation with the current route. This
parameter is set by the user in the vehicle embedded system.
Fig. 2. Information message flowchart
A. Gathering and Dissemination of Region Data to the RSU
The elements that involve FOREVER, such as vehicles and B. FOREVER Traffic Care
RSU, they send beacons periodically to inform about the region In this stage, each FOG characterizes the region of its AoK
conditions. The RSU sends beacons with its position, the size based on reported data from vehicles, sensors, and other RSU.
of its AoK and the routing interval, these data will be used Thus, It can create a graph G = (V, E), where V is the set
by vehicles to finding nears RSU for send/requisite some data of crossroads within the range of its AoK (representing the
(e.g. new route) and to know the time to request a new route vertices) and the set of roads connecting the intersections E
in that region. The vehicles send beacons informing speed, (representing the edges).
current route, position, and the time spent to move by way of
each road of its route to the RSU. RSU collect theses data The weight of each road Ei of the graph G is inversely
about one specific region, that is your AoK, for the purpose proportional to the speed at which vehicles travel on the road.
of acquiring knowledge regarding the events that occurred and Therefore, if the vehicles speed is close of the maximum speed
also to understand the behavior of vehicles on the roads in this allowed on road, the weight of the road is lower.
area.
To perform the detection and control of congestion mecha-
As already mentioned, some roads of AoK may be in the nism, each vehicle, periodically, requests a new route for closest
coverage of other RSUs. Thus, RSUs can exchange information FOG, in other words, the vehicle choose the closest RSU is your
 2017 IEEE Symposium on Computers and Communications (ISCC)

list of RSU to send a message to request a new route. Therefore, Start End
the vehicle is re-routed in the scope of its AoK (yellow area NO NO
in Figure 1). For achieve this, it is necessary to identify which
road are under congestion. Therefore, FOREVER performs the Request Check Assign
Check
congestion detection phase on each FOG using the weight of A create/
send MSG
address
YES route size
factor
YES the new
route
the roads under your coverage. Following, the FOG performs
the traffic control calculating new alternative routes to vehicles, D Vehicle
consequently, reducing the load on the congested roads. How
can it be observed in Figure 1, the re-routing of vehicles (e.g.
MSG
red car) is performed considering its current location (point A) wifi

until the last road in its route that is within the AoK of the
FOG (point B). Calculete Boltzman create/
Check
Through the re-routing phase, k alternative shortest paths B address
YES K paths path
chooser
send MSG
with route
are computed for requester vehicle. For each requester vehicle C RSU
the system apply the Boltzmann probability distribution [20] NO

to selected, probabilistically, one of the k alternative routes.

End
Therefore, the system addresses the similar routes problem to
avoid that the vehicles take the same route. Thus, the system
does no create new congestion points (one of the disadvantages
Fig. 3. FOREVER congestion care flowchart
observed in [13], [14]).
The re-routing process begins when the vehicle creates a
request route message (MSG) addressed to closest RSU and
transmits to the VANET (stage A in Figure 3). The MSG has A. A Description of the Scenario
the current position and route. Whenever the RSU receives an We used Luxembourg SUMO Traffic (LuST) [25] as the
MSG, it verifies if is addressed for it (B). If no, the MSG is scenario of the simulations. LuST is a 24-hour realistic scenario
dropped, otherwise, the FOG calculates a set of K shortest of Luxembourg city with an area of 155.95 km2 , 5, 969km of
paths (C). After this stage, one path is chosen in a probabilistic edges and a total of 295, 979 vehicles inserted in the scenario.
way using the Boltzmann algorithm described in [21] (C). In The Figure 4 shows the topology of the LuST Scenario, with
our mechanism, each path has a weight assigned based on the roads colored by type: highway, main arterial roads and the
conditions of its roads. However, choosing the shortest path for residential roads presented in blue, red and black, respectively.
all request should cause a new traffic jam. Due to this problem,
this method decreases the probability of always choosing the
same route, consequently balancing the load between the roads.
After the route is chosen, the RSU creates a message (MSG)
with the new route and send it to the VANET (C). When the
vehicle receives the MSG (D), it checks if is addressed for
it. If so, it drops the MSG, otherwise, it verifies whether the
route size factor is satisfactory. In such case, the new route
is assigned to the vehicle, otherwise, the request routine is
finalized.

IV. P ERFORMANCE E VALUATION

This section describes the scenario used and performance
assessment of the proposed solution, by means of simulated
experiments using the OMNeT++ 5.01 . For the vehicular
network, we used the framework Veins 4.3 [22] that implements
the IEEE 802.11p and IEEE 1609.4 DSRC/WAVE with signal
attenuation model considering obstacles. For the simulation of
mobility and traffic of vehicles, we employed the SUMO 0.25.0
simulator (Simulation of Urban MObility) [23], an open source
traffic simulator, which models and to manipulates objects in Fig. 4. Topology of the LuST Scenario [25]
the road scenario. For managing the traffic provided by SUMO,
TraCI (Traffic Control Interface) [24] was used, which is an In this paper, we use the first slot of time (from 00:00 to
interface that allows traffic management of the simulations at 06:00) due to the high density of vehicles that it is possible to
runtime. observe the effectiveness of proposal mechanism in light and
with some traffic congestion on the roads. Furthermore, we fix
1 http://www.omnetpp.org the size of the AoK in 4000m to verify the impact of these
 2017 IEEE Symposium on Computers and Communications (ISCC)
TABLE I. S IMULATION PARAMETERS
Parameters Values Parameters
Transmission power 2.2 mW Total length edges
Communication range 300 m Confidence interval
Bit rate 18 Mbit/s AoK
Beacons 4s K paths
Scenario LuST Interval to request new route
Scenario area 155.95 kmˆ2 Route size factor
change in the FOREVER.
The parameters K − routes and route size factor used is
k=3 and 25% respectively because of these produced the best
results according to [26]. Furthermore, we set the bit rate to
18 Mbit/s at the MAC layer and the transmission power to 2.2
mW, resulting in a coverage of approximately 300 m under
a two-ray ground propagation model [22]. These values as
obtained through the preveous experiments [26]. Table I shows
the simulation parameters and values used in our evaluation.
When the simulation reaches a steady state, the vehicles
begin to request to the FOREVER new routes, when necessary.
When the FOREVER received these requests the, it calls the
re-routing mechanism to generate a new route to minimize
congestion already in a determined road.
The environment compares the FOREVER with the original
vehicular mobility trace (OVMT). For this comparison, we vary
the Interval to Request new Route in 150 and 300 seconds in
the FOREVER approach.
This environment amid to verify the impact in the network
when the vehicle network uses the FOREVER approach, as
well as verify the efficiency of the traffic congestion manager.
For this, we divide the environment into two parts: (i) Traffic
Efficiency, and (ii) Network Cost.
1) Traffic Efficiency Evaluation: For Traffic Efficiency
evaluation, we consider six metrics where is the averange value
of all vehicles: Traveled Time: travel time from the starting
point to the destination; Stopped time: time spent stuck in traffic
jams; Traveled distance: distance traveled; Fuel consumption:
fuel consumption to traverse the whole route; CO2 emission:
CO2 emissions during their journey.
The evaluation results are presented in Table II. The results
obtained in the OVMT are presented in its capture unit, however,
the results of FOREVER, are showed in percentages in relation
to the OVMT.
We can observe that the FOREVER average travel time
(Table II) has a better performance than the OVMT because
the re-route mechanism that relieves the traffic congestion on
the roads. If we compare both scenarios of the FOREVER
(150 4000 and 300 4000) we can conclude that when the
interval of the request is smaller the FOREVER has a better
performance due to traffic congestion that can be formed during
the interval to request new route.
The FOREVER reduce an average stop time about 8.3% of
the stop time compared with OMVT. When we analise both
FOREVER scenario, we can see that time of request have a
litter impact on the traffic, because the fog computes the route
a portion of the map (4000m).
Values
931.12 km
95% The average traveled distance, as expected, the FOREVER
4000m has a better performance than the OVMT. The proposal solution
3 reduces the distance in approximately 8,5% because the fog
150s-300s
25% chooses the trip with the small path. Therefore, the vehicles
always will achieve their destination earlier. Furthermore, the
re-route mechanism will indicate roads with few vehicle, i.e.,
without congestion. Facilitating the traffic of vehicles on the
roads.
The traveled time, the stopped time and the traveled distance
have a direct impact on the CO2 emission as well as the
fuel consumption. In the Table II, we can observe that the
FOREVER reduce in 7.9% the fuel consumption compared
with the OMVT. This occurs because the vehicles do not spend
much time pausing in congestion. Furthermore, the travel path
of these vehicles are small consequently the vehicles will arrives
their destination faster.
How is showed in Table II, FOREVER also reduces the
CO2 emission compared with OMVT. The proposal solution
achieves a reduction of 7.9% due to the choose of the small
route, as well as, the attribution of weights to already selected
roads. Therefore, avoiding that several cars go to the same
street, Consequently, avoiding the appearance of new traffic
congestion.
Summarizing, the FOREVER reduces the average trip time
about 7,6%, CO2 emissions approximately 7,9% and fuel
consumption about 7,9%, due to the re-route mechanisms that
select the small path, attributing weights on selected road.
2) Network Cost evaluation: For evaluate the Network Cost,
we used three metrics: Delay: the average time to spread
messages to all vehicles; Packet collisions: the percentage
of collided packets; Transmitted messages: total number of
messages transmitted (excluding beacon messages).
Table III show results for all assessed networks metrics
in function of the FOREVER system parameters Interval to
Request new Route (150 and 300 second), keeping the AoK Size
in 4000m. We can observe that the scenario with the interval
of 150 has more transmission due to the time lower time of
the request. Furthermore, this scenario achieves a travel time a
litter bit more than another scenario (Table II, column 2) that
also impact in the number of the message transmitted.
Although the number of transmission of scenario 150 4000
is higher than the 300 4000, the percentage of Collisions have
a small difference, because the Fog creates islands of collisions
that allow isolating the area which vehicles are communicating.
Furthermore, the stop time of both scenario are almost the
same, i. e., the time that the vehicles are competing to transmit
their data are almost the same.
The number of transmissions and the lower percentage os
collision have a significative impact on the delay of the message.
We can observe that the delay of scenario 300 4000 is almost
half of the 150 400 due to the vehicle send less request in
the 300 4000. Moreover, the vehicles are close to the RSU at
the moment of sending the request message that allows a fast
communication between vehicle and RSU.
 2017 IEEE Symposium on Computers and Communications (ISCC)
TABLE II. T RAFFIC E FFICIENCY E VALUATION
Travel time Travel distance
OVMT (unit) 10.097 min 6.185 Km
150 4000 (%) -7.67% -8.74%
300 4000 (%) -7.59% -8.01%
TABLE III. N ETWORK C OST EVALUATION
Parameters Average delay (ms) Transmitted messages Packet collisions (%)
150 4000 4.219 10785 7.809
300 4000 2.954 5079 7.867
The proposal solution does not cause a relevant impact in
the network due to the re-route mechanism, as well as, the
use of Fog structure that assist the communication among the
vehicles and RSUs.
V. C ONCLUSION
In this paper, we proposed FOREVER, a route management
mechanism based on FOG computing. FOGs are responsible for
collect, store and process data in a specific region moving them
closer to vehicles. Therefore, the FOG brings the information
closer to the monitored area, making the communication more
efficiently and system response quicker. The results show that
the FOREVER reduced the flue consumption about 7.9%, the
stop time by 8.3%, and 7.6% of the travel time. As future
work, we aim to develop a mechanism that addresses the level
of traffic congestions by the information stored in the FOG.
ACKNOWLEDGMENTS
The authors would like to thank the grant 2015/07538-1
Sao Paulo Research Foundation (FAPESP) for the financial
support.
R EFERENCES
[1] B. o. T. S. US Department of Transportation (DOT), “National transporta-
tion statistics 2014, technical report,” last visited in January, 2017, https:
//www.rita.dot.gov/bts/sites/rita.dot.gov.bts/files/STS 2014 revised.pdf.
[2] I. S. Traffic, “Epa - united state environmental protection agency,” http:
//www.ibm.com/smarterplanet/us/en/traffic congestion/ideas, 2015.
[3] W. T. J. Texas Transportation Institute, D.L. Schrank, “2015 urban
mobility scorecard, mobility report,” last visited in January, 2017, https:
//mobility.tamu.edu/ums/report/.
[4] K. M. H. Allen and M. Stonehill, “A summary of the proceedings from
the united nations climate change conference in doha, qatar, and their
significance for the land transport sector, copenhagen: Bridging the gap
(btg) initiative,” 2013.
[5] M. Cintra, “A crise do trânsito em são paulo e seus custos,” GVExecutivo,
vol. 12, no. 2, pp. 58–61, Jul/Dez 2013.
[6] L. A. Villas, A. Boukerche, G. Maia, R. W. Pazzi, and A. A. Loureiro,
“Drive: An efficient and robust data dissemination protocol for highway
and urban vehicular ad hoc networks,” Computer Networks, vol. 75, Part
A, no. 0, pp. 381 – 394, 2014.
[7] F. D. da Cunha, L. Villas, A. Boukerche, G. Maia, A. C. Viana, R. A. F.
Mini, and A. A. F. Loureiro, “Data communication in vanets: Protocols,
applications and challenges,” Ad Hoc Networks, vol. 44, pp. 90–103,
2016. [Online]. Available: http://dx.doi.org/10.1016/j.adhoc.2016.02.017
[8] F. Bonomi, R. Milito, P. Natarajan, and J. Zhu, “Fog computing: A
platform for internet of things and analytics,” in Big Data and Internet
of Things: A Roadmap for Smart Environments. Springer, 2014.
[9] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and its
role in the internet of things,” in Proceedings of the first edition of the
MCC workshop on Mobile cloud computing. ACM, 2012, pp. 13–16.
Stopped time Fuel Conssuption CO2 emission
3.827 min 0.533 liters 1.337 Kg
-8.40% -8.14% -8.14%
-8.32% -7.72% -7.72%
[10] F. Bonomi, “Connected vehicles, the internet of things, and fog
computing,” in The Eighth ACM International Workshop on Vehicular
Inter-Networking (VANET), Las Vegas, USA, 2011, pp. 13–15.
[11] J. Pan, M. Khan, I. Sandu Popa, K. Zeitouni, and C. Borcea, “Proactive
vehicle re-routing strategies for congestion avoidance,” in Distributed
Computing in Sensor Systems, May 2012, pp. 265–272.
[12] A. M. de Souza, R. S. Yokoyama, L. C. Botega, R. I. Meneguette,
and L. A. Villas, “Scorpion: A solution using cooperative rerouting to
prevent congestion and improve traffic condition,” in Computer and
Information Technology; Ubiquitous Computing and Communications;
Dependable, Autonomic and Secure Computing; Pervasive Intelligence
and Computing, IEEE International Conference on, 2015, pp. 497–503.
[13] R. Doolan and G.-M. Muntean, “Vanet-enabled eco-friendly road
characteristics-aware routing for vehicular traffic,” in Vehicular Technol-
ogy Conference (VTC Spring), 2013 IEEE 77th, June 2013, pp. 1–5.
[14] R. I. Meneguette, G. P. R. Filho, D. L. Guidoni, G. Pessin, L. A. Villas,
and J. Ueyama, “Increasing intelligence in inter-vehicle communications
to reduce traffic congestions: Experiments in urban and highway
environments,” PLOS ONE, vol. 11, no. 8, pp. 1–25, 08 2016.
[15] M. Whaiduzzaman, M. Sookhak, A. Gani, and R. Buyya, “A survey
on vehicular cloud computing,” Journal of Network and Computer
Applications, vol. 40, pp. 325–344, 2014.
[16] R. Yu, Y. Zhang, S. Gjessing, W. Xia, and K. Yang, “Toward cloud-based
vehicular networks with efficient resource management,” Network, IEEE,
vol. 27, no. 5, pp. 48–55, 2013.
[17] S. Olariu, T. Hristov, and G. Yan, “The next paradigm shift: from
vehicular networks to vehicular clouds,” Mobile ad hoc networking:
cutting edge directions. 2nd ed. John Wiley & Sons, Inc., Hoboken,
2013.
[18] S. Bitam, A. Mellouk, and S. Zeadally, “Vanet-cloud: a generic
cloud computing model for vehicular ad hoc networks,” Wireless
Communications, IEEE, vol. 22, no. 1, pp. 96–102, 2015.
[19] C. Liu, C. Chigan, and C. Gao, “Compressive sensing based data
collection in vanets,” in Wireless Communications and Networking
Conference (WCNC), 2013 IEEE. IEEE, 2013, pp. 1756–1761.
[20] S. Kirkpatrick, C. D. Gelatt, M. P. Vecchi et al., “Optimization by
simmulated annealing,” science, vol. 220, no. 4598, pp. 671–680, 1983.
[21] C. A. Brennand, A. M. de Souza, G. Maia, A. Boukerche, H. Ramos,
A. A. Loureiro, and L. A. Villas, “An intelligent transportation system
for detection and control of congested roads in urban centers,” in 2015
IEEE Symposium on Computers and Communication (ISCC ’15). IEEE,
2015, pp. 663–668.
[22] C. Sommer, R. German, and F. Dressler, “Bidirectionally Coupled
Network and Road Traffic Simulation for Improved IVC Analysis,”
IEEE Transactions on Mobile Computing, vol. 10, no. 1, pp. 3–15,
2011.
[23] M. Behrisch, L. Bieker, J. Erdmann, and D. Krajzewicz, “SUMO
- Simulation of Urban MObility: An Overview,” in International
Conference on Advances in System Simulation (SIMUL ’11), 2011,
pp. 63–68.
[24] A. Wegener, M. Piórkowski, M. Raya, H. Hellbrück, S. Fischer, and
J.-P. Hubaux, “Traci: an interface for coupling road traffic and network
simulators,” in Proceedings of the 11th communications and networking
simulation symposium. ACM, 2008, pp. 155–163.
[25] L. Codeca, R. Frank, and T. Engel, “Luxembourg sumo traffic (lust)
scenario: 24 hours of mobility for vehicular networking research,” in
Vehicular Networking Conference (VNC), 2015 IEEE. IEEE, 2015, pp.
1–8.
[26] C. A. Brennand, F. Cunha, G. Maia, E. Cerqueira, A. A. Loureiro,
and L. A. Villas, “Fox: A traffic management system of computer-
based vehicles fog,” in 2016 IEEE Symposium on Computers and
Communication (ISCC). IEEE, 2016, pp. 1–6.