Computers and Electrical Engineering 88 (2020) 106839

Contents lists available at ScienceDirect

Computers and Electrical Engineering

journal homepage: www.elsevier.com/locate/compeleceng

Fuzzy logic-based emergency vehicle routing: An IoT system

development for smart city applications✩
Rashmi Ranjan Rout a ,∗, Satish Vemireddy a , Sanjib Kumar Raul a ,
D.V.L.N. Somayajulu a,b
a
Department of Computer Science & Engineering, National Institute of Technology Warangal, India
b
Indian Institute of Information Technology Design and Manufacturing, Kurnool, India

ARTICLE INFO ABSTRACT

Keywords: Reducing the travel time of an Emergency Vehicle (EV) is essential to increase the chance of
Fuzzy logic casualty’s survival. An efficient vehicle routing solution can avoid instantaneous road blockages
IoT such as construction works, strikes, and accidents. This paper proposes an Internet of Things
Senor node
(IoT) network model for an EV routing using fuzzy logic-based data fusion technique. The data
OSRM
fusion process estimates the location-specific congestion by considering sensory data and human
Emergency vehicle
Routing
inputs from the crowd. Further, an open source routing engine (Open Source Routing Machine
Smart city (OSRM)) computes the shortest congestion-aware route by responding to live traffic updates in
a road network. Moreover, a sensor node has been designed for gathering the emissions and
speeds of moving vehicles on the road. An Android application is developed to collect road
blockage information from the crowd. Leveraging the Android application service, a driver in
the EV is guided towards a medical center through the shortest congestion-aware route.

1. Introduction

Nowadays, traffic congestion in urban areas is a major problem that has a direct or indirect impact on public health-care
services [1]. The traffic congestion not only depends on traffic density but also depends on post-disaster events such as earth-quake,
fire incidents, construction works, human strikes, and road accidents. In [2], the U.S Department of Transportation has presented
a study on the impact of congestion on traffic flow and the importance of alternative routes. This report categorizes the causes
of traffic congestion into planned and unplanned events. Planned events include roadway construction works and road segment
closures. Unplanned events are traffic incidents, adverse weather, natural disaster, and emergency events. In these situations, the
timely arrival of an Emergency Vehicle (EV) (e.g., ambulance) to the nearest hospital having necessary specializations is very crucial
for the survival of casualty. According to Golden Hour Theory [3], providing medical assistance to a victim of car crash within
60 minutes has more chance of survival. Thus, reducing the travel delay of the emergency vehicle is an important task for efficient
vehicle routing in smart city.
Traditional sensor networks are useful for data acquisition in a variety of decision-making applications, namely environmental
monitoring, traffic management, and public healthcare services [4]. The advent of Internet of Things (IoT) networks along with
the data fusion [5] techniques is promising for monitoring the road traffic congestion. The real-time traffic congestion monitoring

✩ This paper was recommended for publication by associate editor Dr. Mohammad Mehedi Hassan.
∗ Corresponding author.
E-mail addresses: rashrr@nitw.ac.in (R.R. Rout), svreddy@student.nitw.ac.in (S. Vemireddy), sanjib.roul@student.nitw.ac.in (S.K. Raul), soma@nitw.ac.in
(D.V.L.N. Somayajulu).

https://doi.org/10.1016/j.compeleceng.2020.106839
Received 13 October 2019; Received in revised form 25 August 2020; Accepted 31 August 2020
Available online 14 September 2020
0045-7906/© 2020 Elsevier Ltd. All rights reserved.
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

facilitates emergency medical services, e.g., guiding an emergency vehicle in smart cities. In this work, for guiding an emergency
vehicle, we have designed an IoT system architecture that can avoid temporary road blockages and congested routes in smart cities.
There are various methods available for collecting traffic data in the literature [6], such as loop detectors, on-road sensors, aerial
videos and Floating Car Data (FCD). The FCD is a probe vehicle data collected from a fleet of vehicles equipped with on-board
sensors and a GPS unit. It provides spatio-temporal traffic data e.g., real-time vehicle speeds, but it suffers from lower penetration
rates i.e., only a fraction of vehicles have communication capabilities on-road. However, traffic data obtained from both FCD and
on-road sensors also can be used in the proposed IoT system. The IoT system has a routing engine that provides a congestion-aware
route from the current location of the vehicle to an intended medical center (such as hospital).
Many open source routing engines exist for road networks such as pgRouting, Open Trip Planner and Open Source Routing
Machine [7]. According to [8], the Open Source Routing Machine (OSRM) has advantages over other routing engines. Routing
environment setup for pgRouting is challenging, and it does not support turn instructions. The Open Trip planner is slow in route
calculation and requires more resources to build routing graph. The OSRM is faster, and it needs fewer resources to calculate shortest
route using contraction hierarchies or multi-level Dijkstra algorithm by considering live traffic updates. Therefore, the OSRM is a
preferable routing environment to support the proposed IoT system. The OSRM computes congestion-aware routes by considering
the location-specific congestion of the road network.
In our proposed model, road traffic congestion has been determined by considering parameters, namely average speed, emissions
of vehicles and real-time human inputs from the crowd. Selected geo-tagged sensors are deployed at specific locations along the
road-side, and these sensors are responsible for gathering vehicle speeds and emissions like CO2 , CO, sound and temperature. Further,
an Android application is developed for crowdsourcing [9] of the real-time traffic congestion information such as congestion type,
congestion level, duration of congestion and GPS location. The influx of sensor data and crowdsource information is invariably
used in data fusion (a process of combining the data collected from multiple sources to achieve more significant inferences [5]) for
determining the congestion. Fuzzy logic inference is a rule-based inference where membership functions and rules are inspired by
designer’s perception and experience. A fuzzy logic-based data fusion technique has been presented in this work to assist the routing
engine for facilitating the emergency vehicle routing in a smart city.
The major contributions of this work are as follows:

• Design and development of a low-cost geo-sensor node to measure vehicular speeds, emissions such as CO2 , CO, sound, and
temperature. These are the input parameters to determine the traffic congestion severity at possible geographical locations of
the road network.
• Development of an Android mobile application for collecting real-time traffic information such as congestion type (event),
congestion level and congestion duration. This crowdsource information also acts as an additional input useful in determining
the congestion severity.
• Design of a fuzzy logic-based decision support system to estimate the location-specific congestion of road network and assist
the Open Source Routing Machine (OSRM) server in generating shortest and congestion-aware route.
• The efficacy of the proposed routing solution has been demonstrated through experimentation. Moreover, performance of the
proposed IoT network model has been evaluated in-terms of scalability and querying delay.

The rest of the paper is organized as follows. The related work is discussed in Section 2. The proposed model of IoT system
for guiding emergency vehicles is explained in Section 3. The customization of IoT sensor node and Android mobile application for
crowdsourcing details are also described in Section 3. Section 4 discusses the implementation of the decision support system using
fuzzy logic-based data fusion technique. Section 5 describes the process of traffic data collection. Section 6 presents the experimental
results along with the performance evaluation of the proposed IoT system. Section 7 concludes the paper.

2. Related work

There are some emergency situations that indirectly involve healthcare services including post-disaster events, e.g., adverse
weather conditions, road accidents, and fire. In such cases, dedicated healthcare service is necessary for a bundle of solutions such
as accident alert notification and emergency vehicle routing. According to [10], no major study has been conducted related to
emergency healthcare services based on IoT networks. A Traffic View framework [11] has been developed to gather and disseminate
information about vehicles on roads. It gives an alert message to drivers about adverse weather conditions or accidents in their route.
A GPS enabled device provides the static view of the traffic information to vehicle driver for necessary action. However, the Traffic
View framework has not considered the traffic data received from on-road sensors.
A crowdsourcing based vehicle routing application known as crowdITS has been proposed in [12]. Crowdsourcing enables
smartphone users to provide traffic related information for some monetary rewards. Collected information pushes into the CrowdITS
processing server for aggregation. Google′ s Cloud to Device Messaging (C2DM) allows pulled out events to be delivered to each
member of the crowd based on their geo-location. In [13], a fuzzy logic-based accident monitoring system has been proposed to
detect road accidents during emergency trip. It uses tilt sensors, sound sensors and Raspberry Pi to detect accidents. A traffic flow
prediction model has been presented in [14] to address the emergency vehicle routing problem. In [15], a post-disaster ambulance
dispatching and routing simulation model has been proposed. The authors have considered a scenario after an earth-quake where a
large number of patients have a medical emergency. Using inflow of information such as hospital locations, road traffic conditions,
the ambulance is routed to pick and deliver the patient to an appropriate hospital. These routes are generated by taking into

2
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 1. Proposed IoT system architecture for smart city.

consideration of road damages and congestion. However, these works have not addressed the dynamic route adjustment ability
of the emergency vehicle using the IoT network model.
An intelligent location-aware data aggregation of real-time traffic congestion estimation for VANET scenario has been proposed
in [16]. It provides efficient data dissemination of traffic information while maintaining the accuracy of the location awareness. This
mechanism uses Kalman filter data fusion technique to quantify the level of congestion for location-aware traffic data. It enables each
vehicle to have global knowledge of congestion with a significant reduction in data dissemination overhead in the road network.
In [17], a multilevel data fusion method has been presented for road traffic congestion detection. It is a combination of feature
information fusion and decision level information fusion. The feature information is produced by the vehicles [17] and most often the
vehicles are equipped with on-board units for vehicle to vehicle communication [18]. Moreover, in [17], a fuzzy logic cluster-based
message aggregation scheme is designed for feature information aggregation. The decision level information fusion is performed at
a higher level by integrating feature information that is aggregated at lower levels. A Dempster–Shafer fusion method is used at the
decision level to detect congestion on road networks [17]. However, these works have not addressed the traffic data acquisition
methods either by using sensors or crowdsourcing.
IoT based emergency vehicle routing solution using open source routing engine for health-care services has not been adequately
addressed in the above literature. The impact of temporary road blockages on traffic flow and the dynamic route adjustment ability
of the emergency vehicles need more attention in vehicle routing solutions. Therefore, in this work, we propose a fuzzy logic-based
congestion-aware IoT architecture to guide emergency vehicles in a smart city environment.

3. Proposed IoT system for guiding emergency vehicles in smart city

This work proposes an IoT system architecture for guiding emergency vehicles in least congested route by avoiding temporary
road blockages in Smart City environment, as shown in Fig. 1. Sensors are the primary source of real-time data. A selective set of
sensors and a GPS device are connected to a Wi-Fi enabled Micro-Controller Unit (MCU) and this constitutes a Geo-sensor node.
The Geo-sensor node is configured to establish a Wi-Fi connection to the nearest access point (i.e., sensor gateway). The sensor
node gathers data from the surrounding environment and forwards it to a Traffic Monitoring Center (TMC). The TMC is a connected
system of Web server, Database server, Decision support system and OSRM server. Moreover, an Android application has been developed
to collect the current state of traffic information at a particular geographical location from the crowd who are using the application.
A web server situated at TMC maintains the received geo-tagged sensor data and crowdsource information in a database server.
A decision support system is implemented in two different phases. In the first phase, it uses a fuzzy logic-based data fusion technique
to aggregate and analyze the collected data. In the second phase, it assists the routing engine (i.e., OSRM) in generating congestion-
aware routes. The OSRM server sends a route reply to the application user upon receiving a route request for an intended hospital.
The user may follow the route to reach the requested hospital. In this paper, the terms Traffic Monitoring Center and Central Server
are used interchangeably.
This section describes the data collection methods using sensors and crowdsourcing techniques. The sensors are connected to
an IoT device along with the GPS module to collect vehicle speeds and environmental information. The customization of the IoT

3
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 2. NodeMCU ESP 12-E.

Fig. 3. NodeMCU pin mapping.

device and its supporting software libraries are discussed in Section 3.1. Furthermore, the functionalities of an Android application
for collecting crowdsource information related to traffic congestion is explained in Section 3.2.

3.1. Customizing a low cost geo-sensor node in IoT network

In a sensor network, the sensor node is a mote that is capable of processing, gathering sensory data and communicating with
other motes. A sensor node that provides location-based data is referred to as Geo-sensor node. A low cost re-configurable geo-sensor
node is designed to measure the emissions and speeds of vehicles on road. The geo-sensor node is equipped with an open source
IoT platform called NodeMCU.1 This micro-controller unit has an integrated system on chip ESP8266 Wi-Fi 802.11 b/g/n module
that contains a firmware which is based on LUA scripting language [19].
The NodeMCU ESP 12-E is a development board that combines the features of a Wi-Fi access point, Wi-Fi station and micro-
controller as shown in Fig. 2. It offers Arduino like Input/Output, event-driven API for network applications, 10 GPIO (General
Purpose Input/Output) pins (D0 to D10), a single analog A0 pin, etc. Programming NodeMCU can be done by configuring ESP8266
core into Arduino IDE 1.6.4. The NodeMCU provides access to GPIO pins of ESP8266 through IO pins. Fig. 3 shows mapping of
NodeMCU IO pins to GPIO pins of ESP8266.

3.1.1. Integrating multiple sensors

The electronic circuit of the geo-sensor node is depicted in Fig. 4. It shows the way of connecting multiple sensors to NodeMCU.
Here, reading analog values of sensors is challenging due to the availability of single analog pin(A0) in the NodeMCU. A Dual 4 × 1
Line Multiplexer (74LS153N) has been chosen to overcome this challenge. This multiplexer(MUX) has four channels (C0–C3), two
select pins (B and A), one enable pin and one output pin. The D0 pin of MCU is appropriate to enable the multiplexer. The D3 and
D5 pins of NodeMCU are used as select lines (B and A) of MUX. The C0 and C1 channels of MUX are connected to Carbon Monoxide
sensor(MQ2) and sound sensor analog outputs respectively. The MQ 135 sensor for measuring CO2 is attached to channel C2 of
the multiplexer. Channel C3 is reserved for future purpose. Finally, the output pin of MUX connects to the A0 pin of NodeMCU.
Furthermore, the DHT11 sensor is attached to D4 pin. Humidity and temperature can be read with the help of a DHT11 sensor and
its supporting library. The connected sensors are required to calibrate (adjust) their output voltage values to measurable quantities
such as Decibels, Celsius and Parts per million.

1 www.nodemcu.com.

4
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 4. Electronic circuit of Geo-sensor node.

3.1.2. Integrating GPS module

A Ublox NEO-6M GPS [20] receiver is attached to NodeMCU with the help of a software serial library to provide serial
communication between the microcontroller unit and GPS (Global Positioning System) receiver. A GPS satellite transmits a low
power radio signal that travels in a line of sight. This signal contains three different types of information to calculate the global
position. (i) The pseudo-random code includes the identity of the satellite that transmits the signal. (ii) The ephemeris data gives the
satellite position in orbit along with the current time and date. (iii) The almanac data used to predict information about the satellites
that are nearby. The GPS receiver generates a sequence of messages in NMEA (National Marine Electronics Association) format, if it
receives the signal from at least three satellites.
The NMEA message sentence starts with $ symbol and NMEA message format [21] is ‘‘$GPGGA,184530.000, 1759.0510,N,
07931.5110,E,2,4,2.18,746.4,M,−22.2,M,*6B’’. GPGGA tells about sentence type. Each value in the sentence is separated by comma
(,). Further, 184530.000 denotes time 18 h 45 min 30 s in UTC. The value 1759.0510 N indicates latitude of 17 degrees 59 min
North, 07931.5110 E tells longitude of 79 degrees 31 min East, number of connected satellites 4, speed of GPS receiver 2.18 Knots
and checksum at the end is *6B.
A TinyGPS++ library is required to parse the NMEA messages to retrieve the geographical position information. This library
retrieves GPS information with its rich set of functions. As described in the algorithm 1, a custom delay procedure is introduced in
the Arduino code to verify the availability of GPS signals at regular intervals.

Algorithm 1 Custom Delay Procedure

Define TinyGPSPlus gps
Define SoftwareSerial serial (GPIO 12, GPIO 1) ⊳ Refer Fig. 3
1: procedure Custom Delay (𝑚𝑠) ⊳ Input: delay(ms)
2: begin ← millis() ⊳ millis(): Number of milliseconds since program start
3: loop:
4: if (serial.available() > 0) then
5: gps.encode(serial.read())
6: if (millis() - begin < ms) then
7: goto loop
8: close

5
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 5. Vehicle speed measurement.

3.1.3. Measuring average speed of vehicles

Average speed of moving vehicles is an important parameter to estimate the traffic density on roads. Lower the speeds of vehicles,
higher will be the predicted traffic congestion and vice versa. The development of a low-cost sensor system for collecting vehicle
speeds using laser detectors follow the work mentioned in [22]. As shown in Fig. 5, two lasers are deployed at one side of the road,
pointing towards laser detectors placed at another side of the road. Distance between the lasers is same as the distance between the
detectors and it is fixed.
Initially, lasers are turned ON. The laser detector output signal is detected as HIGH when the laser beam falls on its photo-
resistor. Detector output goes LOW if any vehicle obstructs the laser beam while traveling on the road. In NodeMCU, interrupts can
be attached to all GPIO pins, except GPIO 16. The pins D7 and D8 are configured as interrupt pins to first and second laser detectors
respectively. The micro-controller detects an interrupt on FALLING edge (HIGH to LOW) of the output signal of the laser detector.
When an interrupt is triggered, the corresponding interrupt handler is executed. The interrupt handlers calculate the time lapse (in
milliseconds) between successive interrupts when a vehicle obstructs the first laser beam, followed by second laser beam during its
travel. The speed of the vehicle can be determined based on the calculated time lapse and the fixed distance between the lasers.

3.1.4. Sensor data transfer

The collected data is forwarded from the sensor node to the Web server through Wi-Fi. To access the available wireless networks,
the sensor node establishes a connection to a nearest access point using ESP8266. In this implementation test-bed, two access points
are available, namely ‘‘IoT-LAB’’ and ‘‘TrainingNITW’’. Based on the availability, the sensor node establishes a Wi-Fi connection to
either of these access points with the following Arduino code. The library WiFiMulti.h allows adding multiple access points to the
sensor node.

# include <ESP8266HTTPClient .h>

# include <ESP8266WiFiMulti .h>
WiFiMulti .addAP( " IoT -LAB " , " <password > " );
WiFiMulti .addAP( " TrainingNITW " , " <password > " );

The standard HTTP protocol allows transmission of sensor data to Web server. An HTTPClient object named client can call
methods like content request, header preparation, HTTP POST request and checking HTTP response code from the Web server.
Before forwarding the set of collected sensor values, it is required to verify Wi-Fi connection status with WiFi.status() method. After
forwarding the data successfully, it closes HTTP connection using client.end() method. The following Arduino code shows the data
forwarding procedure.

HTTPClient client ;
client .begin( " http :// < IPaddress >:<port >/ sensor /data/ " );
client . addHeader ( " Content -Type " , " application /json " );
int httpCode = client .POST(data); // collected data
String timer = client . getString ();
client .end ();
It is often required to control the sensor nodes from the Web server. A simple technique is implemented to control the frequency
of calling HTTP POST method. This approach enables each sensor node to be accessible and usable via Web server. Every sensor

6
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 6. Flowchart for updating location-specific congestion to OSRM & Route generation.

node is discoverable by its identifier or GPS location. The sensor node receives a timer value (i.e, sleeping time) as an HTTP response
from the Web server that is specific to its geo-location. In every iteration, the sensor node forwards the collected data when the
sleep timer expires. During this time interval, the sensor node can be engaged in the collection and aggregation of sensor data. This
approach supports Sensor Web Enablement (SWE) [23] as per the guidelines of Open Geo-spatial Consortium (OGC).

3.2. Smart mobile application for crowdsourcing traffic information

Crowdsourcing is defined as an act of taking a job traditionally performed by employees and outsourcing it to a large undefined
network of people (i.e., ‘‘Crowd’’) in the form of an open call [9]. Initially, a format of the problem is formulated, and it is
disseminated to a large group of solvers (i.e., crowd) in the form of open call. The crowd submit the solutions via web-based
technology. The submitted solutions are filtered to find the best solution(s) that are owned by problem initiator i.e., crowdsourcer.
Often, individuals who contribute the best solution(s) may be offered monetary rewards for their satisfaction.
An android application has been developed to collect current state of traffic information such as event type, congestion level,
and duration of congestion from the crowd who are using this application. Initially, information related to various hospitals such
as name, location, and specializations is registered through the application. A user can view the location of nearby hospitals having
required specializations on the digital map. Based on the request received from the Android application user, our proposed system
provides a route to the requested hospital. In-detail explanation is given in Section 5. Note that, this paper uses terms ‘‘Android
application’’ and ‘‘Ambulance Route Monitoring (ARM) application’’ interchangeably.

4. Fuzzy logic-based decision support system for estimating congestion

A decision support system has been implemented as a bridge in-between Database server and OSRM server. The proposed model
consists of two phases. First, the road traffic congestion estimation phase. In this phase, a fuzzy logic inference system [24] is used to
aggregate the sensor and crowdsource data to estimate congestion severity (i.e., congestion estimate (CE)) at every location where
data is collected. In second phase, the decision support system updates congestion estimate (CE) to Open Source Routing Machine
(OSRM). Considering the congestion estimate of corresponding geographical locations, the OSRM generates shortest and congestion
aware route from user’s location to intended hospital.
As shown in Fig. 6, web server initiates the process of collecting data by activating geo-sensor nodes. The active sensor node
periodically sends sensing data through a sensor gateway for every fixed duration (in seconds). The web server validates and
authenticates the received sensory data. Similarly, the ARM application users also send crowdsource information to the web server.
Then, the decision support system requests recently collected data from the database server. It aggregates the sensor data and
crowdsource information, and further computes congestion estimate (CE) using a fuzzy logic-based data fusion technique. Later, it
updates location-specific congestion estimate (CE) to OSRM for congestion-aware route generation.

4.1. Phase I: Fuzzy logic-based congestion estimation

Fuzzy logic consists of four stages.

• Fuzzification : Process of translating a quantifiable (crisp) input to an appropriate linguistic variable.

7
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Table 1
Parameters for sensor data.
Parameters Linguistic variables
Sound (S) Low, Medium, High
Carbon-dioxide (CO2 ) Low, Medium, High
Carbon monoxide (CO) Low, Medium, High
Temperature difference (TD) Low, Medium, High
Congestion estimate (CE) Less, Moderate, High, Very high

Table 2
Parameters for crowdsource data.
Parameters Linguistic variables
Congestion rating (CR) Less, Moderate, High, Very high
Congestion duration (CD) Low, Medium, High
Congestion estimate (CE) Less, Moderate, High, Very high

Fig. 7. Sound(S) membership function.

• Membership functions: Gaussian and Bell membership functions.

• Fuzzy rule base: Set of if-then rules which can be built using input and output linguistic variables.
• Defuzzification: Process of translating fuzzy output to a crisp value.

Input parameters and the corresponding linguistic variables mapping is given in Tables 1 and 2. Here, the parameters of sensor
data are Sound(S), Carbon-dioxide (CO2 ), Carbon-monoxide(CO) and Temperature difference (TD). The amount of carbon emissions
indicates the presence of traffic in the roadways. The sound is also another significant parameter near traffic posts. The parameter
temperature difference (TD) is considered as the difference between current city temperature and the temperature at the sensor node
location. Similarly, the parameters of crowdsource data are congestion rating (CR) and congestion duration (CD). These parameters
indicate the severity of congestion and the duration of congestion near to crowdsource individual locations.
The membership functions corresponding to each input and output parameters are shown in Figs. 7–13. Here, a Bell mem-
bership function represents the boundary values and a Gaussian membership function represents the middle values. The Gaussian
membership function (𝜇𝐴̄ (𝑥; 𝑠, 𝑚)) and Bell membership function (𝜇𝐴̄ (𝑥; 𝑎, 𝑏, 𝑐)) are expressed by Eqs. (1) and (2) respectively.
[ 2]
1 || (𝑥 − 𝑚) ||
𝜇𝐴̄ (𝑥; 𝑠, 𝑚) = 𝑒𝑥𝑝 − | | (1)
2 || 𝑠 ||

where 𝑚 and 𝑠 represents mean and standard deviation.

1
𝜇𝐴̄ (𝑥; 𝑎, 𝑏, 𝑐) = (2)
| |2𝑏
1 + | (𝑥−𝑐) |
| 𝑎 |
where a, b and c are responsible for membership function width, slope and center.
Fuzzy rules are constructed based on a set of if-then rules to find the fuzzy value of the congestion estimate(CE). The format of
each rule can be expressed using Eq. (3). The fuzzy rule base is listed in Tables 3 and 4.

𝑅𝑢𝑙𝑒(𝑘) ∶ 𝐼𝐹 𝑥1 𝑖𝑠 𝐴̄ 𝑘1 𝐴𝑁𝐷 𝑥2 𝑖𝑠 𝐴̄ 𝑘2 𝐴𝑁𝐷 … 𝐴𝑁𝐷 𝑥𝑖 𝑖𝑠 𝐴̄ 𝑘𝑖 𝑇 𝐻𝐸𝑁 𝑦 𝑖𝑠 𝐵̄ 𝑘 (3)

where, 𝑥𝑖 is the 𝑖𝑡ℎ input parameter, k is the 𝑘th rule, 𝐴̄ 𝑖 is the 𝑖th fuzzy set of 𝑥𝑖 , y is the output parameter and 𝐵̄ is the fuzzy set
of y.

8
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 8. Carbon monoxide (CO) membership function.

Fig. 9. Carbon dioxide (𝐶𝑂2 ) membership function.

Fig. 10. Temperature difference (TD) membership function.

Table 3
Fuzzy rules for sensor data.
S CO2 CO TD CE
Low Low Low Low Less
Low Low Low Medium Less
Medium Low Medium Low Moderate
Low Low Medium Medium Moderate
Low Medium High Medium High
High Medium High Medium High
High High High High Very High

9
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 11. Congestion rating (CR) membership function.

Fig. 12. Congestion duration (CD) membership function.

Fig. 13. Congestion estimate (CE) membership function.

The generated fuzzy rules are based on Mamdani fuzzy inference system to produce better results. In the final stage, the center of
area (COA) method has been applied for de-fuzzification, which is expressed in Eq. (4). The yield of de-fuzzification is the required
congestion estimate (CE).

∫ 𝜇𝐴̄ (𝑥) 𝑥 𝑑𝑥
𝐶𝑂𝐴(𝐶𝐸) = (4)
∫ 𝜇𝐴̄ (𝑥) 𝑑𝑥

10
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Table 4
Fuzzy rules for crowdsource data.
CR CD CE
Low Low Less
Moderate Low Less
High Medium Moderate
High Low Moderate
High High High
Very High Medium High
Very High High Very High

4.2. Phase II: Update estimated congestion to OSRM and generate routes

The Open Source Routing Machine (OSRM) is a high performance routing engine for computing the shortest paths in road
networks [7]. It combines the routing algorithms, namely contraction hierarchies or Multilevel Dijkstra (MLD) and OpenStreetMap
(OSM) road network data. The Multilevel Dijkstra algorithm is a best fit when there is a need for high query performance e.g., live-
traffic updates to OSM data. The OSRM provides access to HTTP requests through its API services (i.e., route, match, nearest,
table, trip, and tile). Typically, it supports transportation mode LUA profiles like car, bike and foot. In this paper, car.lua profile is
considered for route generation. Coordinate convention for HTTP request is represented as {longitude, latitude}. The response format
for version v1 of OSRM 5.x is geojson.

Algorithm 2 Algorithm for data storage

(𝑑1 , 𝑑2 , ..𝑑𝑛 ) = Source data collected from location 𝑑_𝑙𝑜𝑐
𝑑_𝑙𝑜𝑐 = source data location i.e. (𝑑_𝑙𝑜𝑛, 𝑑_𝑙𝑎𝑡)
𝑑_𝑙𝑜𝑛 = longitude of 𝑑_𝑙𝑜𝑐
𝑑_𝑙𝑎𝑡 = latitude of 𝑑_𝑙𝑜𝑐
𝑟_𝑙𝑜𝑐 = on-road location
1: procedure StoreData(𝑑1 , 𝑑2 , ..𝑑𝑛 , 𝑑_𝑙𝑜𝑐)
2: 𝑢𝑟𝑙 ← nearestAPI (𝑑_𝑙𝑜𝑐, 𝑛𝑢𝑚𝑏𝑒𝑟 = 1)
3: (𝑟_𝑙𝑜𝑐, 𝑓 𝑟𝑜𝑚_𝑖𝑑, 𝑡𝑜_𝑖𝑑) ← request_OSRM (𝑢𝑟𝑙)
4: Store (𝑑1 , 𝑑2 , .., 𝑑𝑛 , 𝑟_𝑙𝑜𝑐, 𝑓 𝑟𝑜𝑚_𝑖𝑑, 𝑡𝑜_𝑖𝑑)

The Open Source Routing Machine (OSRM) uses road network data from Open Street Map (OSM). The OSRM recognizes
each road segment in OSM by its identifier (NodeID). In OSM, an on-road location can be identified by two successive NodeIDs
(i.e., 𝑓 𝑟𝑜𝑚_𝑖𝑑, 𝑡𝑜_𝑖𝑑) that are directly connected. The location (i.e, 𝑑_𝑙𝑜𝑐) of sensor or crowdsource data (i.e., 𝑑1 , 𝑑2 , ..𝑑𝑛 ) can be
translated to a nearest on-road location (i.e. 𝑟_𝑙𝑜𝑐). Each on-road location has its NodeIDs. This translation is shown in algorithm
2, which sends a request to OSRM using nearestAPI with argument 𝑛𝑢𝑚𝑏𝑒𝑟 = 1. The 𝑛𝑢𝑚𝑏𝑒𝑟 denotes number of on-road locations
near to 𝑑_𝑙𝑜𝑐. Finally, it stores (𝑑1 , 𝑑2 , … , 𝑑𝑛 , 𝑟_𝑙𝑜𝑐, 𝑓 𝑟𝑜𝑚_𝑖𝑑, 𝑡𝑜_𝑖𝑑) into the database. Two or more data source locations (𝑑_𝑙𝑜𝑐) near
the road may associate to same 𝑟_𝑙𝑜𝑐. In other words, data coming from near by road locations are mapped to same set of NodeIDs.
Further, the collected data are aggregated by grouping the same set of NodeIDs.

Algorithm 3 Algorithm to update congestion to OSRM

1: procedure Update(𝑑1 , 𝑑2 , ..𝑑𝑛 , 𝑟_𝑙𝑜𝑐, 𝑓 𝑟𝑜𝑚_𝑖𝑑, 𝑡𝑜_𝑖𝑑)
2: 𝐶𝐸 ← 𝐹 𝑢𝑧𝑧𝑦_𝐼𝑛𝑓 𝑒𝑟𝑒𝑛𝑐𝑒_𝑆𝑦𝑠𝑡𝑒𝑚(𝑑1 , 𝑑2 , ..., 𝑑𝑛 ) ⊳ Find congestion estimate (CE) from Eq. (4)
3: 𝑢𝑟𝑙 ←nearestAPI(𝑟_𝑙𝑜𝑐, 𝑛𝑢𝑚𝑏𝑒𝑟 = 2)
4: (𝑟𝑠_𝑙𝑜𝑐, 𝑟𝑑_𝑙𝑜𝑐) ←request_OSRM (𝑢𝑟𝑙) ⊳ Returns two nearest on-road locations
5: 𝑢𝑟𝑙 ← matchAPI(𝑟𝑠_𝑙𝑜𝑐, 𝑟𝑑_𝑙𝑜𝑐)
6: 𝑆 ← request_OSRM (𝑢𝑟𝑙) ⊳ 𝑆: Speed at 𝑟_𝑙𝑜𝑐
7: 𝑆 ′ ← Scale(𝑆, 𝐶𝐸) ⊳ 𝐶𝐸 is a scaling factor
8: Write (𝑓 𝑟𝑜𝑚_𝑖𝑑, 𝑡𝑜_𝑖𝑑, 𝑆 ′ ) ⊳ Write to updates.csv file

The OSRM allows accessing the most recent speeds of vehicles at all possible on-road locations of OSM map. As shown in
algorithm 3, the matchAPI is used to retrieve the recent vehicle speed (i.e., 𝑆) at a specific location of OSM data. Based on the fuzzy
inferred congestion estimate (CE), the decision support system scales average vehicle speed (𝑆) to a new speed (i.e 𝑆 ′ ). Then, the
decision support system updates the set of NodeIDs and 𝑆 ′ in the OSRM’s updates.csv file. The format of each line in updates.csv file
is < 𝑓 𝑟𝑜𝑚_𝑖𝑑, 𝑡𝑜_𝑖𝑑, 𝑆 ′ >. The ordered pair (𝑓 𝑟𝑜𝑚_𝑖𝑑, 𝑡𝑜_𝑖𝑑) indicates the direction of traffic flow. Simultaneously, the OSRM computes
the shortest and least congested routes. The following bash script will run the OSRM server for generating routes and listen to route
requests.

11
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 14. Prototype of the Sensor node.

Fig. 15. Ambulance Route Monitoring (ARM) Application.

$osrm - extract warangal .pbf -p osrm - backend / profiles /car.lua --generate -edge -
lookup
$osrm - partition warangal .osrm
$osrm - customize warangal .osrm --segment -speed -file updates .csv
$osrm - routed --port =5000 --algorithm =MLD warangal .osrm
An OSM road network map is imported to OSRM server. Here, the OSM map (i.e. warangal.pbf) is chosen for Warangal city (in
India). The osrm-extact extracts the road network graph from the OSM data. The extracted graph is then partitioned recursively
into cells by osrm-partition. The osrm-customize calculates weights for each cell which are useful in routing. The osrm-routed runs the
OSRM server and listen to route requests at a specified port number.

5. Traffic data collection through sensors and crowdsourcing

This section presents the process of collecting vehicular traffic data using sensor nodes and Android application. Leveraging the
wireless infrastructure of the Smart City, a test-bed is established for experimenting with the proposed IoT system. The sensor nodes

12
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 16. Area I.

are deployed at the strategic locations along the roadside of the city. As aforementioned in Section 3.1, sensors are connected to
a WiFi-enabled microcontroller that collects sensory data from specific locations. The prototype of a sensor node for sensor data
collection is shown in Fig. 14. Moreover, Ambulance Route Monitoring (ARM) application for collecting crowdsource information is
shown in Figs. 15(a)–15(d). The developed ARM application is installed in the smartphones of crowdsourcing users in Smart City.
Further, these users contribute real-time traffic congestion information such as congestion level and expected duration of congestion
to the IoT system.
Initially, the main activity (as shown in Fig. 15(a)) displays a digital map marked to the current location of the ARM user. The
user may be a crowdsource individual, ambulance driver, or hospital authority. This main activity has options to choose register
hospital, update roadblocks and get directions activities. Register hospital activity is used by hospital authorities to register hospital
details. The submitted hospital information is transferred to Traffic Monitoring Center (TMC) for storage. Using update roadblocks
activity, users can send congestion level of traffic from their present location to TMC. The user needs to provide input information
such as congestion event type, congestion level, and duration of congestion. These inputs are considered relative to the perception
of an individual user. Get directions option shows the routes from user’s location to the requested hospital.

6. Results and discussion

This section provides the results and discussion on the route adjustment ability of the proposed system when responding to live
traffic updates (e.g., temporary roadblocks), and the performance analysis of the IoT system in-terms of scalability and querying
delay.

6.1. Route adjustment ability

In this section, the route adjustment ability of the IoT system has been discussed. Here, the congestion-aware routes obtained
from the OSRM server are demonstrated using ARM application for three different areas in the Warangal city (in India). The OSRM
server computes the route based on the traffic congestion information updated by the decision support system. The computed shortest
route is sent to the ARM user in geojson format. The user’s ARM application parses the received geojson response, and the routes are
layered on top of the Google’s digital map in the ARM application. The proposed IoT system uses OSM data (inside OSRM server)
for route generation and Google’s digital map (inside ARM application) for layering congestion-aware routes. The congestion-aware
route is indicated with blue color, and the roadblock locations are marked with red color on the road, as shown in Figs. 16 to 18.
Fig. 16 shows (Area I ) single lane undivided roads and the average speed of vehicles is around 25 km/hr. An ARM application user
is standing at the source location ({17.985800,79.530759}) and requesting a route to NIT Dispensary (at the location {17.981089,
79.529934}). The location information is in the format {latitude,longitude}. A shortest congestion-aware route is displayed to
the ARM user indicating the distance and time to reach NIT Dispensary. When this shortest route is blocked at the location

13
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 17. Area II.

Fig. 18. Area III.

({17.982951,79.529639}), the system adjusts the route to a least congested alternative route towards NIT Dispensary. Furthermore,
the locations ({17.983785, 79.532147},{17.985376, 79.531058}) on the alternative routes are blocked to show the next possible
congestion-aware alternative routes. If all the routes are also blocked in the forwarding direction, then the alternative route takes
backward direction, as shown in Fig. 16(d).
Fig. 17 shows the Area II and this includes a national highway (NH 163) with two-lane roads, and the average speed of vehicles
is around 60km/hr. In this case, the ARM user requests route from the source location ({17.996056, 79.537245}) to the destination

14
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Fig. 19. TMC server performance during route request.

location ({17.995142, 79.546328}). The shortest route follows the national highway towards the destination. When this route
is blocked on the national highway at the locations ({17.993517, 79.541135},{17.994484, 79.544737}), it is observed that the
alternative shortest routes are adjusted alongside to national highway respectively as shown in Fig. 17. Furthermore, Fig. 18 shows
the roadways in Area III includes a flyover on the national highway (NH 163), one-lane roads, and the average speed of vehicles
is around 35 km/hr. This area has the characteristics of both Area I and Area II. When shortest routes are blocked, as shown in
Fig. 18(c), the alternative route takes the longest route to reach the destination. Therefore, it is observed that the proposed IoT
system responds to live traffic congestion updates in these scenarios.

6.2. Performance analysis and testing

In this section, the performance analysis has been done by deploying the Traffic Monitoring Center (TMC) in two different
environments, namely a private network environment and a public cloud (Amazon’s Elastic Computing Cloud (EC2)) environment.

6.2.1. Server side analysis in private network environment

The TMC server has been installed on a machine with the following configuration: Ubuntu 14.04 LTS 64-bit operating system,
Intel Core i7-4770 CPU 3.40 GHz x 8, 16 GB RAM, and 1 TB disk space. Besides, a set of tools are used to evaluate the TMC server
performance in terms of scalability and querying speed [25]. Scalability is an important concern for accommodating a large number
of sensor nodes and ARM application users in the system. Querying speed is also an important metric to assess the performance of
the database server.
To assess the scalability, a large number of concurrent users have been simulated using Webserver stress tool.2 All these users
create asynchronous HTTP route requests to the TMC server. Wherein, each of these requests involve a database operation and a
route request. During route request phase, network and CPU utilization of the TMC server are illustrated in Fig. 19. The rectangular
boxes indicate the utilization of CPU and network bandwidth. Due to the limitation of Webserver stress tool, a maximum of 4000
simultaneous users have been simulated in this test. It is observed that nearly 38% of CPU utilization is recorded when 4000 users
create simultaneous route requests.
To assess the speed of database server, a MySQL server’s bench-marking tool (sysbench) has been adopted to measure the
performance of database server. The querying time of database server is calculated during the period of high data traffic from
Webserver stress tool. Most of this data traffic contains read and write operations to the database server. In this test scenario, a 106
rows of data is created in a separate database. Then, read and write tests are performed to the separate database on the database

2 www.paessler.com/tools/webstress.

15
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

Table 5
Database server read and write query delay.
Read (ms) Write (ms)
Minimum 0.75 67.80
Average 2.03 113.33
Maximum 99.78 342.16

Table 6
OSRM server response time for the remote clients.
Users Average Min Max Std. Dev. Error% Throughput Received Sent Avg. Bytes
10 158 120 229 28.31 0.00% 2.03 5.86 0.45 2950
100 149 93 260 36.31 0.00% 18.65 53.75 4.14 2950
500 149 87 755 48.51 0.00% 81.61 235.13 18.09 2950
1000 1052 90 9302 1865.39 0.00% 63.21 182.11 14.01 2950
1500 3436 91 9825 3872.27 0.00% 93.76 270.11 20.79 2950
2000 8470 99 21 295 8465.4 26.90% 74.26 209.34 12.04 2886.2
3000 10 629 92 21 223 9241.43 41.23% 107.61 299.77 14.02 2852.3
4000 13 270 86 21 271 9153.76 55.78% 148.20 407.82 14.53 2817.8

Table 7
Database server response time for the remote clients.
Users Average Min Max Std. Dev. Error% Throughput Received Sent Avg. Bytes
10 5185 2949 7378 1422.67 0.00% 1.34 0.15 0.00 113
100 4147 1386 6832 1616.35 0.00% 14.38 1.59 0.00 113
500 6284 1997 10 533 2554.14 0.00% 47.38 5.23 0.00 113
1000 8213 2244 14 198 3411.46 0.00% 70.29 7.76 0.00 113
1500 9631 2537 16 685 3931.58 0.00% 89.84 9.91 0.00 113
2000 11 059 1769 18 081 5043.02 22.20% 109.61 11 0.00 102.8
3000 14 203 2856 19 441 4642.13 53.43% 152.23 13.15 0.01 88.4
4000 15 401 5224 20 234 4282.75 58.40% 197.11 16.58 0.01 86.1

server. The querying delay during the read and write operations to the database are presented in Table 5. The average delay of
read and write operations has been observed around 2 ms and 113 ms respectively. These delays are observed when this test is
performed simultaneously with the scalability test.

6.2.2. Client side analysis in public cloud environment

To ensure the availability and accessibility of route monitoring service for the ARM application users, the TMC server is also
deployed in Amazon’s Elastic Computing Cloud (EC2). The EC2 is a computing platform which can allow the users to rent a virtual
machine for the purpose of deploying the computer applications. As part of this work, a virtual machine has been launched in
EC2 (zone: ap-south-1) with the following configuration: instance type is t3.large, Dual core CPU, RAM size 8GB, storage 8GB and
Ubuntu 16.04 LTS. The running instance of virtual machine in the EC2 provides a web service through a public IP. Further, the
ARM application users can send traffic data and route requests to the TMC server deployed in the EC2.
A large number of concurrent users have been simulated to analyze Quality of Experience (QoE) at the remote client (i.e., ARM
application user) in terms of average response time and error rate. The remote users are connected to cloud via a last mile wireless
network. Tables 6 and 7 shows average response time (ms), minimum response time (ms), maximum response time (ms) including
standard deviation for different number of simulated users. From Table 6, it can be observed that the average response time increases
as the number of route requests sent to OSRM server increases. Although the throughput (i.e., requests/sec send to the cloud by the
users) increases, the average response size (i.e., Avg. Bytes) significantly reduces for the large number of concurrent users. Moreover,
the error rate is nearly 55% for the 4000 users, but the error rate is recorded as negligible when the number of users is below 2000.
Similarly, the database server response time analysis for accessing data like traffic congestion data and roadblock data is illustrated
in Table 7. When the number of users is below 2000, the minimum response time is recorded around two seconds and the received
responses are without any errors. Although the number of received bytes (in KB/sec) increases, the average response size (Avg.
Bytes) degrades in the case of more number of users. However, the number of simultaneous user requests plays role to determine
better QoE (based on parameters like error rate, throughput and response time) in the proposed IoT system.

6.3. Advantages and future directions

The proposed IoT system helps casualty to reach the nearest hospital (with intended specialization) in a congestion-aware route
by avoiding temporary road blockages. Since the proposed system is developed using an open source routing engine (OSRM), in
future, more sophisticated and customized systems can be built. Moreover, the data received from various sensors can be used for
different socio-economic applications such as temperature prediction, noise and pollution maps. However, the proposed system has
some challenges. Seamless network connectivity to sensor nodes is required for the widespread deployment of the proposed IoT

16
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

system. The trust evaluation of the crowdsourcing data is necessary to verify the legitimacy of the crowdsource user. Moreover, the
implementation of secure and robust communication protocols is essential to alleviate the risk of security attacks in the proposed
system.

7. Conclusions

In this work, smart routing decision has been taken using Open Source Routing Machine (OSRM) with Fuzzy decision making to
provide safe driving experience in a Smart City. An IoT network model has been designed for Emergency Vehicle (EV) routing by
considering both roadside sensing and crowdsourcing data. An IoT node equipped with sensors and a GPS device has been designed
for gathering the emissions (such as CO, CO2 , sound and temperature) and speeds of moving vehicles on the road. An android
application is developed to collect traffic information such as roadblock type, congestion level, duration of congestion and location
from the crowd. Then, the proposed IoT system aggregates the human inputs along with the sensory data using fuzzy logic-based
data fusion technique to assist the OSRM in generating congestion-aware routes when responding to temporary road blockages. A
smart mobile user in the emergency vehicle (e.g., ambulance) is guided towards a medical center having necessary specializations
through the shortest congestion-aware route. Moreover, the scalability and querying speed of the proposed IoT system is evaluated
in terms of CPU utilization and database access time. It has been observed that nearly 38% of CPU utilization and 2 ms of average
database access time is recorded when the route requests of 4000 simultaneous users are received at the traffic monitoring server.
Further, it has been observed from the cloud implementation that to achieve good quality of experience, an appropriate values of
error rate, response time and throughput must be chosen. The proposed IoT system provides smart decision making for healthcare
in smart cities, and it can be integrated with other emergency social applications such as healthcare-recommender systems and road
traffic prediction. As a future work, the authors would like to provide a more sophisticated solution for emergency vehicle routing
problem by evaluating the trust on the data collected from different sources and using an interval fuzzy optimization technique.

CRediT authorship contribution statement

Rashmi Ranjan Rout: Conceptualization, Methodology, Software, Formal analysis, Writing - review & editing, Funding
acquisition. Satish Vemireddy: Software, Formal analysis, Writing - original draft, Investigation, Validation, Resources. Sanjib
Kumar Raul: Data curation, Visualization, Validation. D.V.L.N. Somayajulu: Data curation, Supervision, Project administration.

Declaration of competing interest

One or more of the authors of this paper have disclosed potential or pertinent conflicts of interest, which may include receipt of
payment, either direct or indirect, institutional support, or association with an entity in the biomedical field which may be perceived
to have potential conflict of interest with this work. For full disclosure statements refer to https://doi.org/10.1016/j.compeleceng.
2020.106839.

Acknowledgments

This research is funded by Department of Science and Technology, Government of India under grants of NRDMS Programme
(No. NRDMS/ 01/97/015).

References

[1] Cook DJ, Duncan G, Sprint G, Fritz RL. Using smart city technology to make healthcare smarter. Proc IEEE 2018;106(4):708–22. http://dx.doi.org/10.
1109/JPROC.2017.2787688.
[2] Alternate route handbook. Federal Highway Administration, U.S. Dept. of Transportation; 2006, URL https://ops.fhwa.dot.gov/publications/ar_handbook/
index.htm.
[3] Barrachina J, Garrido P, Fogue M, Martinez FJ, Cano J-C, Calafate CT, Manzoni P. Reducing emergency services arrival time by using vehicular
communications and evolution strategies. Expert Syst Appl 2014;41(4, Part 1):1206–17. http://dx.doi.org/10.1016/j.eswa.2013.08.004.
[4] Rashid B, Rehmani MH. Applications of wireless sensor networks for urban areas: A survey. J Netw Comput Appl 2016;60:192–219. http://dx.doi.org/10.
1016/j.jnca.2015.09.008, http://www.sciencedirect.com/science/article/pii/S1084804515002702.
[5] Hall DL, Llinas J. An introduction to multisensor data fusion. Proc IEEE 1997;85(1):6–23. http://dx.doi.org/10.1109/5.554205.
[6] Naranjo JE, Jimenez F, Serradilla FJ, Zato JG. Floating car data augmentation based on infrastructure sensors and neural networks. IEEE Trans Intell
Transp Syst 2012;13(1):107–14. http://dx.doi.org/10.1109/TITS.2011.2180377.
[7] Luxen D, Vetter C. Real-time routing with OpenStreetMap data. In: Proceedings of the 19th ACM SIGSPATIAL international conference on advances in
geographic information systems. New York, NY, USA: ACM; 2011, p. 513–6. http://dx.doi.org/10.1145/2093973.2094062.
[8] Dornhofer Markus BW, Elmar K. Comparison of Open Source routing services with OpenStreetMap Data for blind pedestrians. In: FOSS4G-Europe 2014
Bremen; 2014.
[9] Howe J. Crowdsourcing: Why the power of the crowd is driving the future of business. 1st ed. New York, NY, USA: Crown Publishing Group; 2008.
[10] Islam SMR, Kwak D, Kabir MH, Hossain M, Kwak KS. The internet of things for health care: A comprehensive survey. IEEE Access 2015;3:678–708.
http://dx.doi.org/10.1109/ACCESS.2015.2437951.
[11] Nadeem T, Dashtinezhad S, Liao C, Iftode L. TrafficView: a scalable traffic monitoring system. In: IEEE international conference on mobile data management,
2004. proceedings. 2004. 2004, p. 13–26. http://dx.doi.org/10.1109/MDM.2004.1263039.
[12] Ali K, Al-Yaseen D, Ejaz A, Javed T, Hassanein HS. CrowdITS: Crowdsourcing in intelligent transportation systems. In: 2012 IEEE wireless communications
and networking conference. 2012, p. 3307–11. http://dx.doi.org/10.1109/WCNC.2012.6214379.

17
R.R. Rout et al. Computers and Electrical Engineering 88 (2020) 106839

[13] Handayani AS, Marta Putri H, Soim S, Husni NL, Rusmiasih R, Sitompul CR. Intelligent transportation system for traffic accident monitoring. In: 2019
International conference on electrical engineering and computer science. 2019, p. 156–61. http://dx.doi.org/10.1109/ICECOS47637.2019.8984525.
[14] Tian R, Li S, Yang G. Research on emergency vehicle routing planning based on short-term traffic flow prediction. Wirel Pers Commun
2018;102(2):1993–2010. http://dx.doi.org/10.1007/s11277-018-5251-2.
[15] Jotshi A, Gong Q, Batta R. Dispatching and routing of emergency vehicles in disaster mitigation using data fusion. Socio-Econ Plan Sci 2009;43(1):1–24.
http://dx.doi.org/10.1016/j.seps.2008.02.005.
[16] Milojevic M, Rakocevic V. Location aware data aggregation for efficient message dissemination in vehicular ad hoc networks. IEEE Trans Veh Technol
2015;64(12):5575–83. http://dx.doi.org/10.1109/TVT.2015.2487830.
[17] Zhang L, Gao D, Zhao W, Chao H-C. A multilevel information fusion approach for road congestion detection in VANETs. Math Comput Modelling
2013;58(5):1206–21. http://dx.doi.org/10.1016/j.mcm.2013.02.004, The Measurement of Undesirable Outputs: Models Development and Empirical Analyses
and Advances in mobile, ubiquitous and cognitive computing.
[18] Vemireddy S, Rout RR. Clustering based energy efficient multi-relay scheduling in green vehicular infrastructure. Veh Commun 2020;25:100251.
http://dx.doi.org/10.1016/j.vehcom.2020.100251, URL http://www.sciencedirect.com/science/article/pii/S221420962030022X.
[19] Muniz R, Diaz J, Nuno F, Prieto MJ, Pernia AM. A smart power meter to recharge electric vehicles in communal parking areas. IEEE Internet Things J
2019;6(2):3448–54. http://dx.doi.org/10.1109/JIOT.2018.2885171.
[20] Pham HD, Drieberg M, Nguyen CC. Development of vehicle tracking system using GPS and GSM modem. In: 2013 IEEE conference on open systems.
2013, p. 89–94. http://dx.doi.org/10.1109/ICOS.2013.6735054.
[21] Shoab M, Jain K, Anulhaq M, Shashi M. Development and implementation of NMEA interpreter for real time GPS data logging. In: 2013 3rd IEEE
international advance computing conference. 2013, p. 143–6. http://dx.doi.org/10.1109/IAdCC.2013.6514210.
[22] Atluri M, Chowdhury M, Kanhere N, Fries R, Sarasua W, Ogle J. Development of a sensor system for traffic data collection. J Adv Transp 2009;43(1):1–20.
http://dx.doi.org/10.1002/atr.5670430102.
[23] Li H, Fu X. An intelligence traffic accidence monitor system using sensor web enablement. Procedia Eng 2011;15:2098–102. http://dx.doi.org/10.1016/j.
proeng.2011.08.392, CEIS 2011.
[24] Wang R, Xu Z, Zhao X, Hu J. V2V-based method for the detection of road traffic congestion. IET Intell Transp Syst 2019;13(5):880–5. http://dx.doi.org/
10.1049/iet-its.2018.5177.
[25] Al-Ali AR, Zualkernan IA, Rashid M, Gupta R, Alikarar M. A smart home energy management system using IoT and big data analytics approach. IEEE
Trans Consum Electron 2017;63(4):426–34. http://dx.doi.org/10.1109/TCE.2017.015014.

Rashmi Ranjan Rout received Ph.D. from Indian Institute of Technology (IIT) Kharagpur, WB, India. He is currently working as an Associate Professor in the
Department of Computer Science and Engineering at National Institute of Technology (NIT), Warangal. His research interest includes online social networks,
delay tolerant networks, vehicular networks, wireless sensor networks and Internet of Things.

Satish Vemireddy received M.Tech. from the Department of Computer Science and Engineering, Indian Institute of Technology (IIT) Bombay, India. He is
currently a Ph.D. student at the department of Computer Science and Engineering, National Institute of Technology, Warangal, India. His research interest
includes wireless sensor networks, vehicular networks, edge computing and Internet of Things.

Sanjib Kumar Raul received M.Tech. from school of Information technology, Indian Institute of Technology (IIT) Kharagpur, India. He is working as a research
scholar in the department of Computer Science Engineering, National Institute of Technology, Warangal, India. His research interests include online social
networks, data analytics, data modeling and software engineering.

D.V.L.N Somayajulu received Ph.D. from Indian Institute of Technology (IIT) Delhi, India. He was a Professor of computer science and engineering with the
NIT, Warangal, India. He is currently on deputation as the Director of Indian Institute of Information Technology Design and Manufacturing, Kurnool, India. His
research interests include databases, data analytics, query processing and big data.

18