Thesis Report Final (1) - 230901 - 202841

Acknowledgment
First of all, I would like to thank M. Walid BARHOUMI, professor at ENI Carthage and the
chair of the defense jury, and M. Mahdi HAJJI, assistant professor at ISSAT Mateur and the
examiner of the defense jury, for their presence, for their attentive reading of my thesis as well
as for the remarks they will address to me during this defense to improve my work.
I would like to acknowledge all the people who have helped and supported me for the success
of this master thesis.
First and foremost, I want to express my heartfelt gratitude to my supervisors, M. Abdelmajid

KHELIL Professor at Landshut University of Applied Sciences, PhD student Ahmed
CHEBAANE, and M. Bchira BEN MABROUK assistant professor at ISSAT Mateur, for their
unconditional support, scientific guidance, patience, constant optimism, enthusiasm, and
sympathy throughout this work. I am especially grateful to my co-supervisor Ahmed
CHEBAANE for his advice and supervision, which enabled me to produce high-quality
research results. I am extremely grateful to have met and worked with M. CHEBAANE.
I would also like to thank all of the jury members for their participation in my master's defense
and for their encouraging and motivating comments.
I am extremely thankful to the CPS master teachers of the department of computer sciences at
the Higher Institute of Applied Science and Technology in Mateur(ISSATM), Bizerte,Tunisia.
Last but not least, I would like to thank my parents, my siblings, and my friends, who have
helped me with the valuable suggestion and support. Their guidance has been helpful in various
type and form in the phases of completion of the project.
Abstract
Over the last internet of things became something very important in our lives, everything we
see in our daily basis is connected such as smart appliances (stoves, washers and dryers), smart
homes, connected cities, connected vehicles and a lot of other things that we deal with in our
daily life.
Numerous of new use cases such as computing and storage anywhere and whenever needed,
have been made possible by cloud computing. A well-known example of cloud computing is
storing data and information from your smart phone to data centers.
Connected vehicles would change people’s life in the near future by making the transportation
safer cleaner and more comfortable, but due to some internal (the navigation app) and external
(uncertainties, risk) factors it may cause some level of distribution for the cloud and also the
vehicle itself.
Other applications like collision alerts, obstacle detection, and autonomous driving are delay-
critical. Subsequently, they need to be processed deterministically in a very short amount of
time (few tens of milliseconds).
Fog computing has been suggested as a solution for connected vehicle applications that need
to accommodate delay-critical computation, security concerns, and communication latency.
That brings cloud computing to the network's edge. Instead of centralized cloud analysis,
processing, and storage functions, they are now decentralized and run-on gateways/fogs close
to end user devices.
The majority of the vehicles require the immediate offloading of delay-sensitive applications to
the nearby fog infrastructure because to the resource limitations on the onboard computers of
the vehicles.
Due to these uncertainties, it is difficult to ensure high availability and deterministic guarantee
of computation resources. As a result, reserving the desired resources in advance is required.
In this thesis, we design a reservation technique based on uncertainties and probability maps to
reserve for the future the desired computation resources on fog nodes. Experimental results
show that the proposed algorithm performs remarkably well concerning useful and wasted
reservation.
Table of Contents
General Introduction .................................................................................................................. 1
Chapter 1: IOT Basics and Computing Paradigms .................................................................... 2
1. Introduction ..................................................................................................................... 2
2. Internet Of Things (IOT) Basics ..................................................................................... 2
2.1 IOT Definition ......................................................................................................... 2
2.2 IOT Architecture ...................................................................................................... 2
3. Computing Paradigm....................................................................................................... 4
3.1 Cloud Computing ..................................................................................................... 6
3.2 Edge Computing ...................................................................................................... 6
3.3 Fog Computing ........................................................................................................ 8
4. Vehicular Fog Computing ............................................................................................... 9
4.1 Definition of VFC .................................................................................................... 9
4.2 VFC Architecture ................................................................................................... 10
4.3 VFC Features ......................................................................................................... 11
4.4 Taxonomy of Application Execution Step in VFC ................................................ 11
5. Conclusion ..................................................................................................................... 13
Chapter 2: Task offloading and Computation Resource Allocation ........................................ 14
1. Introduction ................................................................................................................... 14
2. Task Offloading in Fog Computing .............................................................................. 14
2.1 Task offloading challenges .................................................................................... 15
2.2 Task Offloading Approaches ................................................................................. 16
3. Application Areas of Task Offloading in VFC ............................................................. 16
4. Fog Computing Resource Reservation for Connected Vehicles ................................... 18
4.1 Movement Prediction of the Vehicles .................................................................... 18
4.2 Computation Resource Reservation ....................................................................... 19
5. Conclusion ..................................................................................................................... 21
Chapter 3: Our Fuzzy-Logic-Based Solution ........................................................................... 22
1. Introduction ................................................................................................................... 22
2. What is fuzzy logic ........................................................................................................ 22
2.1 Fuzzy Expert System ............................................................................................. 24
2.2 Fuzzy logic pros and cons ...................................................................................... 26
2.3 Fuzzy logic application area .................................................................................. 26
3. Design of the Proposed Solution ................................................................................... 28
3.1 Probability Map ..................................................................................................... 28
3.2 Problem Description and Assumptions .................................................................. 29
3.3 Proposed algorithm ................................................................................................ 30
4. Conclusion ..................................................................................................................... 37
Chapter 4: Performance Evaluation ......................................................................................... 38
1. Introduction ................................................................................................................... 38
2. Simulation settings ........................................................................................................ 38
2.1 Simulation environment ......................................................................................... 38
3.2 Software programing environment ........................................................................ 40
3.3 Hardware programming environment .................................................................... 40
3.4 Performance Metrics .............................................................................................. 40
3. Simulation results .......................................................................................................... 40
3.1 Simulation on vehicle 1292 ................................................................................... 41
3.2 Simulation on vehicle 27245 ................................................................................. 50
4. Conclusion ..................................................................................................................... 56
Conclusion and Perspective ..................................................................................................... 57
References ................................................................................................................................ 58
Annexes .................................................................................................................................... 61
List of Figures
Figure 1: IOT Architecture (A: Three-tier) (B: Five-tier) [1]. ................................................... 4
Figure 2: First appearance of Cloud, Edge, and Fog computing in the literature [3]. ............... 5
Figure 3: Relationship between Cloud, Fog & Edge computing [2]. ......................................... 5
Figure 4: Architecture of vehicular fog computing [7]. ........................................................... 10
Figure 5: Steps involved in Application Execution. ................................................................ 12
Figure 6: Task offloading. ........................................................................................................ 15
Figure 7: Boolean logic VS FL (ref.
https://www.techtarget.com/searchenterpriseai/definition/fuzzy-logic) . ................................ 23
Figure 8: Concept of a fuzzy logic expert system. ................................................................... 25
Figure 9: Visualization of a visit probability map.................................................................... 29
Figure 10: Explanation of creation of universe variable. ......................................................... 32
Figure 11: Example of membership function in our algorithm. ............................................... 33
Figure 12: Aggregated membership function. .......................................................................... 34
Figure 13: Threshold reservation result using the centroid method. ........................................ 34
Figure 14: Threshold reservation result using the SOM method. ............................................ 35
Figure 15: Threshold reservation result using the MOM method. ........................................... 35
Figure 16: Threshold reservation result using the LOM method. ............................................ 36
Figure 17: Flowchart of the proposed solution. ....................................................................... 37
Figure 18: Area of InTAS simulation. ..................................................................................... 38
Figure 19: Probability map of matrix 1 of vehicle 1292 on cell size 20. ................................. 43
Figure 20: Result of threshold reservation on of matrix 1 of vehicle 1292 on cell size 20 with
Centroid method. ...................................................................................................................... 43
Figure 21: Probability map of matrix 84 of vehicle 1292 on cell size 20. ............................... 44
Figure 22: Result of the threshold reservation of matrix 84 of the vehicle 1292 on cell size 20
with Centroid method. .............................................................................................................. 44
Figure 27: Probability map of matrix 102 of vehicle 1292 on cell size 100. ........................... 49
Figure 28: Result of the threshold reservation of matrix 102 of the vehicle 1292 on cell size
100 with Centroid method. ....................................................................................................... 49
Figure 29: Probability map of matrix 50 of vehicle 1292 on cell size 100. ............................. 50
100 with Centroid method. ....................................................................................................... 50
Figure 31: Probability map of matrix 6 of the vehicle 27245 on cell size 150. ....................... 52
150. ........................................................................................................................................... 52
Figure 33: Probability map of matrix 90 of the vehicle 27245 on cell size 150. ..................... 53
150. ........................................................................................................................................... 53
Figure 36: Result of the threshold reservation of matrix 20 of vehicle 27245 on cell size 200
Figure 38: Result of the threshold reservation of matrix 64 of vehicle 27245 on cell size 200
List of Tables
Table 1: Main differences between cloud computing and edge. ................................................ 7
Table 2: Comparison between Fog Computing and Edge Computing....................................... 9
Table 3: Head-to-Head Comparison between Fuzzy Logic and Probability. .......................... 24
Table 4: Pros & Cons of Fuzzy logic. ...................................................................................... 26
Table 5: Input data for the vehicle in Time T. ......................................................................... 30
Table 6: Used matrices sizes. ................................................................................................... 39
Table 7: Results of the threshold reservation on vehicle 1292 on cell size 20......................... 42
Table 8: Results of the threshold reservation on vehicle 1292 on cell size 50......................... 45
Table 9: Results of the threshold reservation on vehicle 1292 on cell size 100....................... 48
Table 10: Results of the threshold reservation on vehicle 27245 on cell size 150. ................. 51
Table 11: Results of the threshold reservation on vehicle 27245 on cell size 200. ................. 54
List of annexes
Annex 1: Threshold reservation of the vehicle 1292 with cell size 20 .................................... 61
Annex 2: Threshold reservation of the vehicle 27245 with cell size 200 ................................ 87
General Introduction
The pinnacle of the current distributed computing era has been the transfer of programs from
local Internet of Things devices to nearby infrastructures. For real-time applications, cloud
computing has proven fairly troublesome due to excessive latency and network limitations.
As a result, it has been suggested that Fog Computing should be provided in addition to Cloud
Computing for almost all applications.
To handle the generated data near to its source, the Fog computing architecture relies on so-
called fog nodes. The physical component of a fog node could be a router, switch, or gateway.
Fog computing therefore provides a wide range of services to time-critical use cases, such as
autonomous driving, to address a variety of issues, including obstacle detection.
In this circumstance, connected vehicles must often offload their time-critical applications or a
chosen subset of them to the nearby fog nodes with the least amount of latency. This task
offloading requires to reserve computational resources in advance to guarantee the safety on
roads.
The research team from University of Applied Sciences Landshut – Germany has already
developed a reservation and re-reservation technique based on probability map and simulate it
on the area of InTAS (Ingolstadt Traffic Scenario) using SUMO (Simulation of Urban
MObility) simulator and find out that the results are very specific for the selected simulation
scenario. However, the question that arises: what is the impact of the uncertainties, a dynamic
reservation, and a deterministic cell size on the probability map consequently on the
performance of this reservation technique.
The main challenge of this thesis is to develop a counter measure to cope with uncertainties
which facilitates finding a dynamic threshold allowing vehicles to decide which fog node must
be reserved. Therefore, we developed a fuzzy logic algorithm that connected vehicles use to
determine the dynamic threshold at a given time based on their context. To look into the
suggested algorithm, we use simulations to demonstrate the effectiveness of the suggested
strategy in comparison to the static criteria already used in the reservation technique.
The thesis is organized as follows. In Chapter 1, we give basic knowledge on IoT and computing
paradigms. In Chapter 2, we focus on the classification linked to task offloading and
computation resource reservation. Chapter 3 discusses the recommended solution to the
difficulties associated with our dilemma. Finally, in Chapter 4, we assess and explain the
experimental data, and we conclude the thesis with perspectives.
1
Chapter 1: IOT Basics and Computing Paradigms
1. Introduction
In this chapter, we’ll present some basics and background knowledge in order to understand the
state of the art in the next chapter. We will begin by a rundown on the Internet of Things (IOT).
Next, we will discuss the most know and used computing paradigms (Cloud, Edge and Fog).
Finally, we’ll introduce the Vehicular Fog Computing (VFC).
2. Internet Of Things (IOT) Basics

In this section, we briefly present the IOT definition and architecture.
2.1 IOT Definition

The global user community does not currently have a consensus definition for the Internet of
Things. In reality, IOT has been defined by a wide range of groups, including academics,
researchers, and businesspeople.
But we are going to give it the omniscient definition that everyone consensus of. The Internet
of Things is the outcome of the evolution of several technologies that lead to this novel concept,
which explain why IOT systems contain a large number of heterogenous components. First,
sensors and actuators are tools that allow us to interact with the physical world. The
environment can be monitored using a sensor (e.g., camera, GPS, light sensor, etc.), but changes
to the environment are made using an actuator (e.g., motor, switch relay, etc.). Second, the data
gathered or collected can be processed and stored on a remote server or at the network’s edge.
Thirdly, the majority of IoT device communication is wireless due to the dispersed locations.
All of these elements (sensors, actuators, computing servers, and communication network) are
essential to construct an IoT system. However, we require software to connect and manage all
of these disparate components.
2.2 IOT Architecture

When looking for an IOT architecture we face the same triviality as in IOT definition, because
there is no consensus on architecture for IOT, Different researchers have presented several
architectural designs.
In the following, we present the two most fundamental IOT architectures, three- and five-layer
architectures [1].
2
A. Three-layer IOT Architecture
This architecture was introduced in the early stages of research in this area, which make it
inadequate because frequently IOT applications focuses on finer concepts of the IoT. It has
three layers, namely, the perception, network, and application layers as shown in Figure 1 A.
(i) The perception layer is the physical layer, which has sensors for sensing and
gathering information about the environment. It senses some physical parameters or
identifies other smart objects in the environment.
(ii) The network layer is responsible for connecting to other smart things, network
devices, and servers. Its features are also used for transmitting and processing sensor
data.
(iii) The application layer is responsible for delivering application specific services to
the user. It defines various applications in which the Internet of Things can be
deployed, for example, smart homes, smart cities, and smart health.
The three-layer architecture defines the main idea of the Internet of Things, but it is not
sufficient for research on IoT because research often focuses on finer aspects of the Internet of
Things. That is why, we have other architectures such as five-layers architecture.
B. Five-layer IOT Architecture

The five-layer architecture, which additionally includes the processing and business layers,
those five layers are perception, transport, processing, application, and business layers as shown
in Figure 1 B.
The role of the perception and application layers is the same as the architecture with three layers.
We outline the function of the remaining three layers.
(i) The transport layer transfers the sensor data from the perception layer to the
processing layer and vice versa through networks such as wireless, 3G, LAN,
Bluetooth, RFID, and NFC.
(ii) The processing layer is also known as the middleware layer. It stores, analyzes, and
processes huge amounts of data that comes from the transport layer. It can manage
and provide a diverse set of services to the lower layers. It employs many
technologies such as databases, cloud computing, and big data processing modules.
(iii) The business layer manages the whole IoT system, including applications, business
and profit models, and users’ privacy. The business layer is out of the scope of this
paper. Hence, we do not discuss it further.
3
Figure 1: IOT Architecture (A: Three-tier) (B: Five-tier) [1].
3. Computing Paradigm
In the last decade, we have witnessed a significant evolution of computing paradigms. The most
known and consolidated ones are cloud computing, edge computing and fog computing, they
have received a great deal of interest from both industry and academia. However, it is difficult
to find a clear and concise characterization of these computer paradigms and their relationships
in the literature. This makes it difficult for new researchers to obtain a clear grasp of these
paradigms.
As shown in Figure 2 [3], the idea of Edge computing first appeared in the
literature in 2004-2005 with the concept of pushing the application logic and data to the edge
of the network. Subsequently, Cloud computing and IoT appeared. The term “Cloud
computing” was first used by Google and Amazon in 2006. Eric Schmidt, Google CEO,
mentioned it in the Search Engine Strategies (SES) conference, while Amazon referred to the
Cloud as a commercial product. Later, in 2008, scientific papers about Cloud computing also
appeared. Fog computing has instead a clear origin. It was first mentioned and defined in 2012
by Flavio Bonomi at CISCO.
4
Figure 2: First appearance of Cloud, Edge, and Fog computing in the literature [3].
Figure 3 illustrates the relationship between these three paradigms through IOT devices.
According to the research community efforts and industrial advances, a fully-implemented real-
world landscape for IoT applications would consists of four layers: 1st layer is IoT layer, 2nd
layer is Edge Computing layer, 3rd layer is Fog Computing layer and final and 4th layer is Cloud
Computing layer [2].
Figure 3: Relationship between Cloud, Fog & Edge computing [2].
5
3.1 Cloud Computing
Nowadays, Cloud computing is a well-known paradigm, we can define it as a network access
approach that enables ubiquitous, easy, on-demand network access to a shared pool of
programmable computing resources. (e.g., networks, servers, storage, applications, and
services) It may be installed and removed quickly with no administrative effort or service
provider interaction. Cloud computing have many strengths points, we can name the most
essential ones [3]:
- On-demand self-service: computing capabilities can be provided automatically

when needed, without requiring any human interaction between consumer and
service provider.
- Broad network access: computing capabilities are available over the network and
accessible through several mechanisms’ disposable for a wide range of client
platforms (e.g., workstations, laptops, and mobile devices).
- Resource pooling: computing resources are pooled to accommodate multiple
consumers, dynamically allocating and deallocating them according to consumer
demand. In addition, the provider resources are location independent, i.e., the
consumer does not have any knowledge or control of their exact location.
- Rapid elasticity: computing capabilities can flexibly be provided and released to
scale in and out according to demand. Thus, the consumer has the perception of
unlimited, and always adequate, computing capabilities.
- Measured service: resource usage can be monitored and reported according to the
type of service offered. This is particularly relevant in charge-per-use, or pay peruse,
services because it grants great transparency between the provider and the consumer
of the service.
Nonetheless, the rapid proliferation of IoT has weakened its position. Indeed, there are some
IoT-related difficulties that Cloud computing cannot handle.
3.2 Edge Computing

The Internet of Things revolution has opened up new research avenues, increasing interest in
decentralized paradigms. Edge computing emerged in this context, with the goal of bringing
the power of the Cloud to the network edge, addressing most of the new difficulties that Cloud
computing alone cannot address, such as bandwidth, latency, and connectivity.
6
Edge computing refers to the enabling technologies that allow computation to be conducted at
the network's edge, on downstream data for Cloud services and upstream data for IoT services.
Edge computing architecture is a federated network topology that introduces edge devices
between terminal devices and cloud computing to extend cloud services to the network's edge.
The cloud-edge cooperation structure is commonly separated into three layers: the terminal
layer, the edge layer, and the cloud computing layer. We can briefly put in place those layers
with their functions and compositions [4]:
- Terminal Layer: The terminal layer consists of all types of devices connected to the
edge network, including mobile terminals and many IOTS devices (e.g., sensors,
smartphones, smart cars, cameras, etc.). In the terminal layer, the device is not only
a data consumer, but also a data provider.
- Boundary Layer: The edge layer is the core of the three-tier architecture. It is located
at the edge of the network and consists of edge nodes widely distributed between
terminal devices and clouds. It usually includes base stations, access points, routers,
switches, gateways, etc.
- Cloud Layer: Among the federated services of cloud-edge computing, cloud
computing is still the most powerful data processing center. The cloud computing
layer consists of a number of high-performance servers and storage devices, with
powerful computing and storage capabilities, and can play a good role in areas
requiring large amounts of data analysis.
The following table illustrate the main differences between cloud computing and edge
computing.
Applicable Network Latency Calculation

situation bandwidth mode
overhead
Cloud Global More High Large scale
Computing centralized
processing
Edge Local Less Low Small scale
Computing intelligence
analysis
Table 1: Main differences between cloud computing and edge.
7
3.3 Fog Computing
Fog computing is often considered as an implementation of Edge computing and it is an
expansion of Cloud computing but nearer to things that perform with IoT information. Fog
computing acts as a bridge between end devices and cloud computing, bringing storage,
networking, and computation capabilities closer to the edge devices. These end devices are
known as fog nodes, and they may be placed anywhere there is a network connection. A fog
node is a device that contains processing, computing, network connectivity, and storage.
Switches, servers, security cameras, and routers are examples of fog nodes.
The following are the major characteristics of fog computing [5]:
- Adaptability: There are extensive network sensors that keep track of the neighboring
environment. The fog delivers storage resources and disseminated computing which
can operate with such extensive end devices.
- Real-time communications: Fog computing solicitations provide simultaneous
communications amid fog nodes relative to the batch analysis utilized in the cloud.
- Physical distribution: In divergence to the integrated cloud, fog delivers applications
and services that are decentralized and can be hosted in any location.
- Less latency and position awareness: Fog is near to edge devices; it delivers less
waiting time when computing the information of edge devices. Besides, it assists
position responsiveness in which fog nodes can be hosted in various places.
- Compatibility: Fog modules can adapt and interoperate with dissimilar platforms
through diverse service providers.
The following table illustrate the differences between Fog computing and Edge computing
[5]:
Fog Computing Edge Computing
It shifts the edge computing operations to It generally takes place instantly on the IoT
CPU that are linked to the local area network devices in which the IoT sensors are
or into the hardware of local area network so connected or an entry point of IoT device that
that they may physically be more far away is physically “nearby” to the IoT sensors.
from the IoT sensors and IoT actuators.
The information is computed inside the fog The information is computed on the sensor or
nodes or gateway of IoT which is located IoT device, without being relocated to
inside the local area network. datacenters or cloud.
8
It can manage more information at a It keeps all information and computation on
particular time intervals which essentially the device which initially generated it.
rallies upon the capabilities of edge through
its capacity to handle real time needs.
The perfect period to adopt fog computing is Works well when high amounts of
when you have billions of IoT devices information have to be handled and instantly.
connected, exchanging the information in bi
directional
It can compute high volumes of information The information resides on the network
with very less or no interruption delay. “edges” and can be processed instantly.
Clients can handle various data locally and It stalls the time and saves the resources by
depend on their safety methods. looking after the processes by gathering and
examining the information generated in real-
time.
It does not necessitate continuous connected The information is primary computed locally,
access. The information can be kept locally and then sent to the central data centers.
or drawn up from local storage.
Table 2: Comparison between Fog Computing and Edge Computing.
4. Vehicular Fog Computing

Developing vehicular applications require a large amount of computer capability to perform
compute-intensive and latency-sensitive operations. Fog computing, which focuses on
relocating computing resources to the network's edge, complements cloud computing by
addressing latency issues and minimizing traffic to the cloud. This spawned a new paradigm
known as Vehicular Fog Computing (VFC).
In this section, we provide an overview of the VFC so that will make it easy to comprehend the
state of the art in the next chapter.
4.1 Definition of VFC

VFC, a new computing paradigm, is the use of fog computing in the vehicular environment. By
relocating data storage and computation to the network's edge, it minimizes the strain and traffic
generated to reach cloud data centers. VFC is closer to the end users and enables mobility due
to its geographical distribution.
9
The argument behind VFC is that cars have progressed and are now capable of data processing,
analysis, and reasoning thanks to sophisticated computer and networking capabilities. In fact,
VFC is often made up of vehicles and infrastructures (both mobile and stationary), such as fog
nodes (FN). FN is often more powerful in terms of computing than automobiles.[6]
4.2 VFC Architecture
Figure 4 depicts a high-level architecture of vehicular fog computing that includes three types
of entities: smart automobiles as the data production layer, roadside units/fog nodes as the fog
layer, and cloud servers as the cloud layer.
Figure 4: Architecture of vehicular fog computing [7].
(i) Data generation layer: Because of their real-time processing, sensing (cameras, radars,
GPS, etc.), networking, and storage capabilities, the vehicles serve as the primary data
generators in a VFC system. Some of this data can be analyzed by the smart vehicle
itself to inform real-time decision making (vehicle-level decision), while others will be
sent to the fog nodes for analysis and usage in other ways.
(ii) Fog layer: Fog Nodes, which are often located in different locations of a city, will gather
data supplied by smart cars, process the acquired data, and transmit the processed data
to cloud servers. In a VFC system, these nodes also function as middleware/intermediate
devices between the cloud servers and the smart automobiles. These fog nodes, unlike
existing vehicular networks, will have additional functionalities and will provide more
diversified services for smart cars, such as navigation, video streaming, and smart traffic
signals.
(iii) Cloud layer: From a faraway location, cloud servers conduct city-level monitoring and
centralized control. These servers will receive data from the fog nodes and use
computationally demanding analytics to make the best judgments (city-level decision).
10
To achieve optimal city-level traffic control, they will monitor, administer, and regulate
the city's road traffic infrastructures.
4.3 VFC Features
The following baseline properties can be easily achieved with VFC [7].
- Confidentiality: Confidentiality ensures that any unauthorized access attempts to

both data at-rest and data-in-transit in a vehicular fog computing system will be
detected and prevented.
- Integrity: Integrity ensures that any unauthorized attempts to modify data being
transmitted or stored will be detected. In a vehicular fog computing system, it is
critical to meet the integrity requirement since unauthorized modification may result
in serious and/or fatal consequences, especially in life-critical vehicular application
contexts such as a traffic control system.
- Authentication: Authentication ensures that any two communication entities are able
to corroborate the data in transmission.
- Access control: Access control is designed to limit fog node access only to
authorized entities (e.g., participating and non-compromised smart vehicles to gain
access to the fog nodes for some subscribed services like navigation and
entertainment).
- Non-repudiation: non-repudiation ensures that any entity in the system is not able to
deny a previous action (e.g., sending data).
- Availability: Availability ensures that whenever a vehicular application attempts to
access the fog nodes or cloud servers, they are always available.
- Reliability: Reliability ensures that the data collected from smart vehicles and fog
nodes has not been modified or fabricated.
- Forensics: Forensics ensures that the capability to identify, collect, and analyze data
from smart vehicles, fog nodes, and the underlying infrastructure for tracing and
identifying the malicious sources.
4.4 Taxonomy of Application Execution Step in VFC

To be able to manage application execution in vehicular fog computing, four steps are required,
as illustrated in Figure 5: application partitioning, decisions on local or remote execution of
subtasks, task scheduling at fog nodes, and service resumption in the event of node failure or
mobility [8].
11
The process starts with application partitioning in which the code of the application is
partitioned, and computationally intensive tasks are selected and are offloaded to an identified
fog node. Task offloading involves resource discovery of nearby mobile devices and fog node
available. The resource mapping algorithm is used to map task to best node available that fulfills
Quality of Services (QoS) and resource requirements of application execution. If the number of
devices increases in the network, then the problem grows exponentially. This problem includes,
also, service resiliency, data security and privacy of the fog computing environment. Then the
scheduling of the task is performed, which leads to its execution, and finally, the results are
returned to the requesting node. Finally, in case of device failure or mobility, this process needs
to be resumed, and all these steps are executed again.
All these steps cannot be treated independently for distributed application execution, moreover
each step is a distinct research perspective that need special addressing (Figure 5).
Figure 5: Steps involved in Application Execution.
12
5. Conclusion
In this chapter, we presented an overview about the main concepts that are related to this thesis.
At first, we have provided an overview of the IoT, its definitions and its architectures. Then,
we have introduced the three computing paradigms: cloud, fog, and edge. Finally, we have
presented an important concept for our study namely VFC by introducing it, its architecture and
its features. This overview will allow us to introduce two important concepts in the next chapter:
the task offloading and the computation resource reservation.
13
Chapter 2: Task offloading and Computation Resource Allocation
1. Introduction
In the prior chapter, we discussed how VFC decreases the strain and traffic created to reach
cloud data centers by relocating data storage and computation to the network's edge. The VFC
architecture, in particular, provides the required capabilities for speeding up computation tasks
and minimizing latency. One of these methods is resource allocation (reservation), it is
designed to manage available resources and reduce computation costs, such as how the vehicle
and network operator interact and how computational tasks are split across several neighboring
fog nodes.
In the literature, the taxonomy of resource allocation is widely varied. There are several
terminologies of the term “resource allocation” such as: resource placement, resource
scheduling, resource migration, resource offloading, etc. At this point, we should note that, for
the rest of this master’s thesis, we refer to the term “resource allocation” [9]. Moreover, task
offloading is considered to be one of the main resource allocation steps in the field of fog
computing. In fact, industry and academia proposed it as a promising solution for resource
management in computing systems based on edge, fog, and cloud paradigm [10].
In this chapter, we first discuss task offloading, including approaches and challenges, and then
present fog computing resource reservations for connected vehicles based on path prediction.
2. Task Offloading in Fog Computing

In Vehicular Fog Computing (VFC) system, Vehicles can now outsource resource-intensive
tasks to a nearby fog node, therefore reducing total execution time without adding extra
communication paths to a distant Cloud infrastructure. This approach, known as task offloading
(transferring all or part of a set of activities to a fog node), illustrated in Figure 6, can overcome
vehicle resource limits since some computation-intensive tasks can benefit from the fog node's
storage and high processing capability.
Task offloading is a complex process that can be influenced by a variety of circumstances. This
procedure, in particular, incorporates mobile device resource discovery, resource allocation
algorithms, and task transfer from vehicle to fog nodes.
14
Figure 6: Task offloading.
2.1 Task offloading challenges

As the system's various components (vehicles, fog nodes, etc.) target a variety of goals, multiple
distinct objectives may be used to solve the task offloading problem. The following are the
objectives of the task offloading problem [11]:
- Delay: The delay minimization of task execution is one of the main objectives
during offloading. Regardless of the type of task offloading, the overall goal is to
reduce the total execution delay.
- Energy: The energy consumption typically refers to the end devices. The reason is
that mobile and IoT devices are usually battery powered, that’s why a major concern
is how to maximize the lifetime of the battery by reducing the device’s energy
consumption.
- Bandwidth: Due to the great influence that it has on the task offloading performance,
bandwidth can also be considered as an objective. Since to the limited available
bandwidth, especially in IoT networks and dense cellular networks, the careful
allocation of spectrum becomes of utmost importance.
- Load balancing: Due to the availability of physical hardware resources, load
balancing is another objective to consider during task offloading. The goal is to
provide the necessary scalability by increasing the resource availability, increasing
the number of offloaded tasks, maximizing the resource sharing, and facilitating the
offloading of future tasks.
15
- Deployment cost: It can be modeled in various ways, each having a different
interpretation. For example, the cost can be expressed as the monetary cost for
computing processing, memory and network bandwidth, induced for using network
resources.
- Multi-objective: The objectives presented previously are usually conflicting,
making task offloading a challenging problem. For example, minimize the latency
can lead to higher energy consumption on the end device, by deciding to execute the
tasks locally. Adopting load balancing objectives, offloaded tasks can be distributed
among different fog sites, in order to reduce the total delay and energy consumption.
In the same way, when minimizing the deployment cost, offloaded tasks may be
gathered in one single fog site; these results create significant congestion in the
infrastructure and thus higher communication delays.
2.2 Task Offloading Approaches
Many difficult challenges arise while offloading tasks. Because fog computing involves various
dynamic elements, such as the dynamic nature of networks, the dynamic behavior of fog nodes,
and the availability of resources in fog nodes, etc.,
These issues require answers for some critical questions, such as how to select the destination
node for the offloading and how to choose tasks to be offloaded. For the first question, two
approaches exist to address it, namely static and dynamic offloading.
In static offloading, the destination node is chosen regardless of the status of the nodes and the
network. Even though static offloading provides a response to this question, real-time
applications require a lot of techniques that can fully and efficiently exploit resources in fog
networks. On the other hand, dynamic offloading evolves promising solutions, where the
decision is made considering the current status of the nodes and the needs of the offloaded task.
3. Application Areas of Task Offloading in VFC

Offloading tasks from vehicles to fog nodes has numerous applications or use cases, including
object identification, video analytics, traffic management, and so on.
Below, we’re going to give a few use cases [12]:
A. Object Detection
The task of object identification includes image collecting, recognition, pre-processing, feature
extraction, and database searching. This object could be a signboard, a number plate, a human
16
face and/or animal recognition, or anything else that is involved in an event that has to be
recognized. These jobs require significant compute capability and are time sensitive, therefore
we must offload them, partially or entirely, to the fog node.
B. Traffic Management
Vehicular networks enable communication and data sharing between vehicles. The increased
number of vehicles on the road infrastructure has an impact on road safety and traffic load.
Traffic management, which is time sensitive and requires precision, makes advantage of
accident and road blockage information acquired from vehicles and fog nodes via offloading.
C. Augmented Reality (AR)

AR is a cutting-edge and growing technology that overlays a virtual layer of data on top of
reality. Typically, it can add objects to what you see, but it can also delete them by shifting
them out of the way. AR technology in vehicles can integrate synthetic information with
original content. Furthermore, by offloading duties, AR can improve eyesight, safety, and
comfort by leveraging the large compute capacity of fog nodes.
D. Video Analytics
The process of extracting relevant information from a video is known as video analytics. Video
Crowdsourcing is a method of gathering information from several clients at the same time. This
method can be employed in vehicles equipped with dash-mounted cameras. These videos are
transferred to a fog node, where they are evaluated for a variety of purposes, including traffic
management, driving assistance, road situations, weather conditions, and event recognition,
among others.
E. Autonomous Driving
Autonomous driving seeks to provide safe navigation in the face of changes in surroundings
caused by automobiles, people, or other barriers. Furthermore, this system must deal with
unexpected events such as roadblocks, traffic congestion, and accidents. Perception, planning,
and control are the three most important difficulties in autonomous driving. The perception is
in charge of gathering data, which is subsequently sorted and filtered. However, the data
acquired in the vehicle may necessitate a high computational capability in order to make a
judgment. As a result, tasks are offloaded to fog nodes.
F. Content Distribution
A large amount of content, such as music, games, and essential information like traffic
congestion or accidents, must be downloaded/uploaded in vehicle networks. The content
17
supplied could be a little file containing important information in the form of bits or a huge
video file. Some content distributions, such as emergency notifications, may be delay-sensitive
and need minimal latency, but infotainment-related content distribution (data distribution) may
not be.
G. Parking Assistance
One of the critical focuses of the parking assistance system is to provide a location where
vehicles can be parked with minimal effort and fuel. There are numerous parking assistance
system designs in the literature. When a car enters or exits a parking slot in a parking
management system, its status is relayed to the server for recording and computation. The server
side responds to the car request for a parking space by using information from sensors indicating
available spaces. Parking assistance systems have numerous advantages, including the ability
to save time, reduce fuel use, and improve traffic and parking efficiency.
4. Fog Computing Resource Reservation for Connected Vehicles

Vehicle must estimate its path in order to reserve fog resources in advance. In this section, we
shall define two fundamental concepts to better comprehend the situation at hand in this thesis.
To begin, we will provide an overview of vehicle movement prediction approaches. Then, for
linked vehicles, we concentrate on fog computing resource reservation strategies.
4.1 Movement Prediction of the Vehicles

The rapid movement of vehicles is one of the primary aspects that affects the performance and
accuracy of location-based predictors. Estimating future vehicle location with respect to time
enables prediction of its movement.
Prediction techniques can be divided into three categories: Deterministic, History-based,

and Stochastic models [13]:
- Deterministic prediction computes a vehicle's future position using the vehicle's

kinetics. This position is defined as a state, although it cannot be accurate or
trustworthy when moving in a vehicle.
- History-based prediction learns from repeated movement patterns to predict
future positions. This procedure will take time to learn from patterns and will most
likely necessitate resets, as movement patterns might change at any time.
- Stochastic models use probabilities to correct the prediction error. It can be more
appropriate for predicting vehicle’s movements.
18
There is another known approach such as:
- Occupancy-based map for prediction of the vehicle movement. This method

discretizes the real world into a finite number of cells using two-dimensional
probability density functions. The map is set of cells that represents the state of the
real world in the meaning that cells with high probability correspond to areas where
the target is more likely to be located. This approach is used for searching target by
a team of heterogeneous autonomous vehicles. The team members maintain an
occupancy-based map which includes the estimate of possible target states. This
map is propagated in time and strategic decisions are made autonomously based on
its prediction [14].
- Location-aware mechanism which is based on the use of WLAN (Wireless Local
Area Network), also called info-station, in order to predict the user movement. This
mechanism is used to transfer information, which is probably needed by the user in
the near future, in advance, so that it is already stored on the user’s mobile device
when it is actually accessed, it’s called Hoarding. Each zone z in the hording area
has a probability with which this zone is visited. For this purpose, authors use a
probability map which is a set of zones located in the info-station’s Hoarding area.
Finally, similar to the occupancy-based map of the approach from above, the color
of the cell indicates its probability: the brighter the cell is depicted, the higher its
probability of visit. [15].
4.2 Computation Resource Reservation

Some efforts have been made to build fog resource reservation strategies for connected vehicles
up to this point. To guarantee that computing resources are used efficiently, [16] proposed a
mixed integer linear programming formulation in order to minimize the deployment cost of
edge devices, in an urban scenario, by satisfying both constraints: the target level of network
coverage and the computational demand. The authors used a simulator to extract the road
network from Dublin map as line segments and buildings as polygons. Then, they divided the
map into a grid of cells with a maximum size of 200m×200m but may not all have the same
size.
However, in [17] they introduced a resource reservation technique, based on machine learning,
that predict resource consumption of vehicles in a given area. In this approach, the authors
consider that the automotive company is responsible of providing services to the connected
19
vehicle, such as path planning, and real-time object detection, etc. Also, due to the multiple
constraints for real world, they claim that the configuration of vehicular network is variational
which makes almost impossible to build one ML model that is compatible for all the cases. For
that reason, the authors propose a two-stage meta-learning-based approach in order to choose
the appropriate machine learning algorithms based on the meta-features extracted on database
to be able to predict the resource consumption in edge nodes accurately for different scenarios.
According to [18], edge computing allows to facilitate edge services in vehicular networks by
using edge computing devices (ECDs). In this paper, the writers establish a reservation service
framework that ensures a connection between a vehicle's reservation service request and one of
the ECDs that is ahead of its driving direction. However, due to the trustworthiness of the cars,
they suggest a trusted relay selection system for edge services based on dynamic traffic status
and the reputation management mechanism.
Another approach is presented in [19], In fact, the authors presented Deep Reserve, a
spatiotemporal reinforcement learning method based on the deep deterministic policy gradient
algorithm. According to them, existing schemes rely on statistical information can’t satisfy real
problems due to the time-varying demands. We mainly have three developed parts in [19]:
- A convolutional LSTM (Long Short-Term Memory) network: used to encode

resource demands by edge servers.
- An action amender: designed to ensure that an action does not violate spatiotemporal
correlation.
- A new training method: designed to stabilize the training procedure.
In [20], authors proposed a proactive resource reservation scheme to predict slice needs in fifth
generation (5G) networks based on the URLLC key service (Ultra-Reliable Low Latency
Communications). However, the authors confirm that URLLC slice resource dimensioning
cannot be static in some cases such as safety message exchange in vehicular services due to the
varying number of vehicles in the cell. That said, they propose three proactive resource
reservation schemes:
- static Maximal Reservation: in order to ensure the reliability of URLLC, a maximal
number of resources must be reserved, in a static, for URLLC slice for each cell in
the network. To determine this optimal number of allocated resources needed by a
given number of User Equipment (UE) per cell, they use an offline simulation.
20
- Proactive reservation on neighboring cells: in this case, the scheme is dynamic and
proactive. Without knowing the users’ trajectory, the authors suppose that an
URLLC user can move to any of the neighboring cells. When the user moves from
a source cell to a target cell, the number of URLLC users is increased for the
neighboring cells of the target cell that are not neighbors of the source cell and
decreased for the neighbors of the source cells that are not neighbors of the target
cells.
- Proactive reservation on predicted vehicular URLLC UEs trajectory: in this scheme,
they suppose that they can deduce the expected total number of URLLC UEs and
determine the corresponding resource reservation if they can predict the URLLC
UEs trajectory. The authors confirm that this scheme allow to prevent useless
reservation of resources.
To summarize, reserving fog computation resources in Vehicular Fog Computing is difficult

due to numerous constraints such as the limited coverage of fog nodes and vehicle mobility.
Furthermore, current research efforts do not address proactive reservation of fog computational
resources for safety-critical vehicular applications. Accordingly, it is essential to create and
develop a guaranteed reservation approach that addresses the vehicle's requirements in order to
identify a threshold reserve and reach a sufficient degree of vehicle satisfaction based on the
uncertainties that face the vehicles and the probability map.
5. Conclusion
Task offloading is an inevitable action, particularly in resource-constrained nodes, and the
research community has presented a variety of approaches for effective and successful task
offloading. In this chapter, we initially addressed the problems, techniques, and application
areas of task offloading in Vehicular Fog Computing. In the second section, we concentrated
on fog computing resource reservation for connected vehicles based on path prediction, we
presented three prediction techniques deterministic, history-based, and stochastic models. Then,
we studied the stat of the art on the problem of computation resource reservation.
Because of that, in the next chapter we’re going to introduce our counter measure that cope
with uncertainties for a guaranteed reservation of computing resources for connected vehicles.
21
Chapter 3: Our Fuzzy-Logic-Based Solution
1. Introduction
In Vehicular Fog Computing, reserving fog computation resources is a challenge because of
the limited coverage of the fog nodes and the mobility of the vehicles that can browse many of
them. In addition, the access to the computation resources must be guaranteed at any times
because of the time critical vehicular applications. In order to guarantee access to computational
resources, vehicles must reserve the remaining context-depending resources in advance (such
as offloading current sensor values from the vehicle to the fog). This reservation process
depends on the probability map and probability threshold to reserve the needed resources for
the vehicles.
In this thesis, we propose to use fuzzy logic to determine a guaranteed reservation threshold
based on the vehicle position and the risk surrounding it. Depending on this context, our
technique allows to the vehicle to decide which fog nodes must be reserved on given Time T,
in order to save resources and costs.
2. What is fuzzy logic

Fuzzy logic (FL) was invented in 1965 by Prof. Lotfi A. Zadeh (mathematician, computer
scientist, electrical engineer, artificial intelligence researcher and professor emeritus in
computer science). Basically, FL is a multivalued logic, that allows intermediate values to be
defined between conventional evaluations like true/false, yes/no, high/low, etc. Notions like
rather tall or very fast can be formulated mathematically and processed by computers, in order
to apply a more human-like way of thinking in the programming of computers [21]. Fuzzy
systems are an alternative to traditional notions of set membership and logic that has its origins
in ancient Greek philosophy.
Fuzzy set theory has been used for solving different problems in diverse fields. It is mostly used
in the field of engineering as it resolves the problems of imprecision and vagueness.
FL is the only mathematical framework able to do reasoning based on linguistic information

(i.e., linguistic variables) and simulate human reasoning. It is also able to deal with uncertainty
and imprecision, model non-deterministic problems and deal with multiple parameters that
describe the problem modeled. These characteristics make FL a suitable tool to model and solve
a large plethora of real-world problems [22].
22
FL mainly depends upon the rules formed by the Linguistic variables. FL control is free of
complex numerical calculations, unlike other methods. It only uses simple mathematical
calculations to control the model. Despite relying on basic mathematical analysis, it provides
good performance in a control system. Hence, this method is one of the best methods available
and also easier one to control a plant.
In fuzzy set theory, each element has a degree of membership with which it belongs to any
particular set. We can say that fuzzy sets are like classical sets without much sharper boundaries.
Instead of Boolean logic, fuzzy logics are utilized while designing any fuzzy logic expert
framework. As such, a fuzzy expert system is a gathering of membership functions and
principles that are used to reason about information.
FL has had a significant impact: it is utilized on a large scale and in a variety of areas, including
engineering, medicine, science, and business. There is numerous well-known and effective FL
applications in use in the industry (for example, Sendai subway control (Hitachi), airplane
control (Rockwell Corporation), and intelligent cruise control (Peugeot and Nissan
automobiles)). Aside from these well-known industrial uses, several current research projects
in many fields are exploring FL's enormous potential.
Figure7 illustrates the main difference between Boolean logic and FL:
Figure 7: Boolean logic VS FL (ref. https://www.techtarget.com/searchenterpriseai/definition/fuzzy-logic) .
There is a widespread misunderstanding/confusion between FL and probability so the

discussions about the relation between FL and probability are still numerous and sometimes
rather controversial. In particular, using FL to reason in a probabilistic way may be a priori
considered as a "dangerous mixture" of both formalisms. In [23], the authors see that the relation
between FL and probability must start by making clear the basic differences. Admitting some
23
simplification, we consider that FL is a logic of vague, imprecise notions and propositions,
propositions that may be more or less true. Fuzzy logic is then a logic of partial degrees of truth.
On the contrary, probability deal with crisp notion and propositions, propositions that are either
true or false; the probability of a proposition is the degree of belief on the truth of that
proposition.
In Table 3, we highlight the main difference between fuzzy logic and probability:
Fuzzy Logic Probability

Fuzzy logic essentially deals with the idea of Probability is related to occasions and not
vagueness in thinking. realities, and those occasions will either
happen or not happen.
Fuzzy logic deals with the significance of Probability hypothesis catches fractional
incomplete truth information.
Fuzzy rationale accepts truth degrees as a Probability is a numerical model of
scientific basis obliviousness.
Table 3: Head-to-Head Comparison between Fuzzy Logic and Probability.
2.1 Fuzzy Expert System

Fuzzy logic expert systems (also termed “fuzzy inference systems”) have been introduced by
Mamdani and Assilian (1975) for the control of technical systems. Fuzzy inference is the
process of mapping the relationship between the input into a system to the output of the system
using fuzzy logic. Fuzzy logic expert systems simulate human reasoning by applying a set of
heuristic rules given by a human expert [24].
Fuzzy expert systems, which work based on the fuzzy-logic approach, can model the rules
obtained from fuzzy preferences of experts and can provide outputs by using these rules. The
most important application of fuzzy system (fuzzy logic) is in uncertain issues. When a problem
has dynamic behavior, fuzzy logic is a suitable tool that deals with this problem [25].
A fuzzy logic expert system is composed of the following components: fuzzification interface,
rule base, inference system and defuzzification interface (Figure 8).
The fuzzification interface assigns measured input values a certain degree of membership to
each of the linguistic terms of a linguistic variable. The rule base and the inference system map
combinations of linguistic terms of the input variables to the output variable. The
defuzzification interface transforms the fuzzy output set into a crisp score
24
Figure 8: Concept of a fuzzy logic expert system.
Now, we are going to define each component in the fuzzy expert system [26]:
- Input: The input is the crisp values that are given to the system for taking decision.
- Fuzzification interface: Here the input variables are compared with the membership
functions on the antecedent part of fuzzy rule to obtain the membership values of
each linguistic label. In this process crisp inputs from the domain are transformed
into fuzzy inputs with help of membership function.
- Inference system: Combine the membership values using multiplication or min
function on the premise part to get firing strength i.e., degree of fulfilment of each
rule. Inference Engine generates the qualified consequents which can be either fuzzy
or crisp on each rule depending on the firing strength. It uses rules to map inputs to
outputs. The appropriate rule is applied to the conclusion part of each rule. This
results in one fuzzy subset to be assigned to each output variable for each rule.
- Rule base: Or Knowledge base is a repository of rules which is applied on fuzzy sets
to find degree of membership. The rule base is the most important requirement for
the fuzzy logic. The rule base generally consists of various cases of If-Then rules.
First the fuzzy sets and the membership functions are declared. Then the If-Then
rules for the membership functions are decided for the particular control. The output
is controlled by these rules on input.
- Defuzzification: Here the qualified consequents are aggregated to produce crisp
output. It is a process of transposing the fuzzy outputs to crisp outputs, from the
given fuzzy sets and corresponding membership degrees.
- Output: Final crisp value that system gives as decision.
25
2.2 Fuzzy logic pros and cons
Fuzzy logic, like almost every framework, has advantages and disadvantages. In this part we
are going to discuss some of the most important strength point of fuzzy logic and some of its
most known weak points [27]. We are going to sum up those pros and cons in the following
table (table. 4).
Advantages Disadvantages
The structure of Fuzzy Logic systems is The fuzzy rationale isn't always exact.
simple and justifiable.
It is generally utilized for business and Approval and verification of a fuzzy
useful purposes. information-based framework needs broad
testing with equipment.
It encourages you to control machines and Setting accurate, fuzzy guidelines and,
purchase items. enrollment capacities can be a tough task.
It asks you to manage vulnerabilities in the Occasionally, the fuzzy rationale is mistaken
design process. for likelihood hypothesis.
Generally strong as no exact information
sources required.
On the off chance that the input sensor quits
working, you can program it into the
circumstance.
You can change it to improve or modify
framework execution.
Economical sensors can be utilized which
encourages you to keep the general
framework cost and intricacy low.
Table 4: Pros & Cons of Fuzzy logic.
2.3 Fuzzy logic application area

Fuzzy logic is a modeling method well suited for the control of complex and non-linear systems.
Fuzzy Logic, known for its ability to deal with complexity, imprecision and model non-
deterministic problems, is a very promising technology to use in dynamic and complex
applications. In this section we are going to discover some application filed based on fuzzy
logic.
26
A. Medical fields
In recent years, computational intelligence has been used to solve many complex problems by
developing intelligent systems. And fuzzy logic has proved to be a powerful tool for decision-
making systems, such as expert systems and pattern classification systems. Fuzzy set theory has
already been used in some medical expert systems [28].
- Conservative disciplines: Conservative medicine can be classified into the following

disciplines: internal medicine, cardiology, intensive care, pediatric, endocrinology,
oncology gerontology, and general practice. The literature search only found limited
application of fuzzy control mostly in general practice and cardiology. Fuzzy logic
is utilized for improved monitoring in pre-term infants. A self-organizing anomaly
detection system for an electrocardiogram (ECG) using a fuzzy logic reasoning
method was also developed.
- Invasive medicine: The invasive medicine field involves surgery, orthopedics,
anesthesia, and artificial organs. The field of surgery is very wide as many factors
contribute to it such as diagnostics, image processing, pathos-physiological
reasoning, and anesthesia control. In anesthesia, many applications have been
reported in the use of fuzzy logic to control drug infusion for maintaining adequate
levels of anesthesia, muscle relaxation, and patient monitoring and alarm. In the
field of orthopedics, there has been no reported application of fuzzy control. The
field of anesthesia is where most of the applications of fuzzy control have been
reported. It involves monitoring the patient vital parameters and controlling the drug
infusion to maintain the anesthetic level constant.
- Image and signal processing: Image and signal processing are mainly concerned
with signal processing, radiation medicine, and radiology. The application of fuzzy
control is divided into two sections, control and monitoring. Most of the applications
have been concerned with signal processing. The first application is a combined
fuzzy monitoring and control of the electrical and chemical responses of nerve
fibers.
B. Renewable energy fields

The applications of fuzzy logic in renewable energy systems have been reviewed. It is found
that every nation is involved in energy modeling and planning for sustainable development. The
past decade has witnessed the extensive use of fuzzy based modeling in renewable energy
27
systems. Fuzzy logic controller (FLC) is being widely used in solar PV (Photovoltaics)
applications for MPPT (Maximum Power Point Tracking) [29].
- Solar: some authors have presented a fuzzy set methodology for comparing the
benefit to cost ratios of different solar systems for various applications in Jordan.
Overall fuzzy weights are given for each solar system. GIS (Global System
Integrator) based spatial fuzzy multi-criteria evaluation was carried out at Oman to
assess the land suitability for large PV farms implementation. The electricity
generation potential using solar PV technology on highly suitable lands have been
estimated.
- Wind: Fuzzy approach has been applied in wind energy for site identification,
economic analysis, capturing uncertainties, wind prediction, wind energy
assessment etc. The probable sites where wind energy conversion systems can be
located have been identified using fuzzy based risk analysis. The variables used in
the analysis are wind speed and its frequency of occurrence.
3. Design of the Proposed Solution

In this section, we will detail the proposed solution that will allow us to determine a guaranteed
threshold reservation depending on the context (Risk and Uncertainties). For this, we start with
a key concept which is the probability map.
3.1 Probability Map

Even though we don't always know the vehicle destinations in advance, as shown in Chapter
II, Section IV.1, it is difficult to decide which path must be reserved. Furthermore, unexpected
events such as accidents, traffic jams, and other issues complicate the computation resource
reservation process.
Nevertheless, we chose the visit/residence probability map to model a vehicle navigation space.
In fact, as shown in Figure 9, the probability map is a graphical representation that indicates the
probability that the cell (area) will be visited by the vehicle or not. It divides a specified area
into cells of equal size. Each cell in the probability map has a value that represents the odds of
a visit. The brightest cells have the highest probability. All possible paths are represented by
the yellow links [15].
28
Figure 9: Visualization of a visit probability map.
It is difficult to reserve fog computation resources, particularly for vehicles. Fog nodes have a
limited coverage area, and vehicles can move through many of them. Because of the importance
of time-critical applications, the availability of computation resources must be guaranteed at all
times. As a result, computation resources must be reserved for the future.
Coordination is required between fog computing resources and moving objects such as vehicles.
Resources must be available at all times, especially for time-critical applications of autonomous
vehicles. To ensure availability, computation resources must be partially reserved in the future.
3.2 Problem Description and Assumptions

Autonomous vehicles frequently offload their time-critical application or a subset of its tasks
to neighboring Fog nodes with minimal latency. To ensure road safety, this task offloading
necessitates the advance reservation of computational resources. The research team has already
developed a reservation/cancellation and re-reservation technique based on probability maps
and simulation it on the area of InTAS (Ingolstadt Traffic Scenario) using SUMO (Simulation
of Urban MObility) simulator and discovered that the results are very specific for the chosen
simulation scenario. What impact do a dynamic probability threshold and a deterministic cell
size have on the residence probability map, and thus on the performance of this reservation
technique?
29
The main challenge of this thesis is to develop a counter measure to cope with uncertainties for
a guaranteed reservation of fog computing resources for connected vehicles which makes it
possible to find a dynamic threshold allowing vehicle to decide which fog nodes must be
reserved according to the context. Our technique is based mainly on the probability map, cell
size, position, the uncertainties, and speed of the initiator vehicle as input. For each simulation
time, the input parameters are changed.
In this work, we assume that the fog nodes cover the entire simulation area and that bandwidths
are reserved in advance at any time with a deterministic guarantee. Furthermore, the fog
provider always responds positively to the initiator vehicle.
Moreover, we assume that the cell size of the probability map can have the following values:
20 – 50 – 100 – 150 – 200 meters. Finally, in this study, we consider a static fog node.
3.3 Proposed algorithm

Our concept is based on the vehicle's context, which is a set of input data at time T. These
inputs, as described in Table 5, provide a set of data about the vehicle's current state.
Input Description
Probability Matrix (Mrc) The probability matrix of the vehicle at time
T. It is the implementation of the probability
map.
Cell size (Cs) The cell size of the probability matrix (20 –
50 – 100 –150 – 200 m).
Vehicle Speed (speed) The vehicle speed at time T.
Vehicle Position (Vp) The vehicle position on the probability
matrix at time T.
Risk The risk of an uncertainties that can face the
vehicle which can cause a delay (bad
weather, accident on the road, road
construction, etc.).
Table 5: Input data for the vehicle in Time T.
The probability matrix Mrc is a critical input to our reservation algorithm. It represents the area
where reservations will or will not take place. A matrix can be represented in various ways in
programming, but the most common is as a two-dimensional array. The number of cells in each
30
dimension determines the size of the matrix. Because there are an infinite number of possible
matrices, the algorithm must be able to handle any size.
For our algorithm, Mrc can be any n × m matrix where (n, m) Ꞓ ℕ. We expect that Mrc scale
based on the historical movement of the vehicle and the current desired destination. Because
any size of matrix can represent any size of a real map, the additional information of the cell
size Cs Ꞓ ℚ+ where 5 < Cs < 200 is needed. In this thesis we assume Cs is between the size of
the car (5 meters) and the maximum range of the coverage of one fog node (200 meters).
In our algorithm, we followed the fuzzy logic process to attend the desired result for the
dynamic threshold reservation.
In the following, we study and explain the steps of our proposed fuzzy logic algorithm:
A. Create the universe variables:

We need to set the maximum and minimum value of our input and output variables for example
the minimum value of the input speed in 0 which mean that the vehicle is not moving and 100
is the maximum value of that input, in this case we have to create the universe variable of the
speed in the range [0,100]. So, in order to generate this universe variable, we need to use np.
arange () which is one of the array creation routines based on numerical range.it creates an
instance of array with evenly spaced values and returns the reference to it. You can define the
31
interval of the values contained in an array, space between them, and their type with four
parameters of arange.
Figure 10: Explanation of creation of universe variable.
- start is the number (integer or decimal) that defines the first value in the array.
- stop is the number that defines the end of the array and isn’t included in the array.
- step is the number that defines the spacing (difference) between each two
consecutive values in the array and defaults to 1.
B. Custom membership function for the inputs and the output:

A membership function for a fuzzy set speed on the universe of discourse X is defined as µspeed:
X → [0,100], where each element of X is mapped to a value between 1 and 100. This value is
called membership value or degree of membership, which quantifies the grade of membership
of the elements in the X to the fuzzy set of speed.
The most common range of values of membership functions is the unit interval [0,1]. In this
case, each membership function maps elements of a given universal set X, which is always a
crisp set, into real numbers in [0,1].
Two distinct notations are commonly used and employed in the literature to denote membership
function. In one of them, the membership function in the fuzzy set A is denoted by µ A, that is:
µA: X→ [0,1], which is the method that we used. And in the other one, the function is denoted
by A and has, of course, the same form: A→X [0,1].
Figure 11 depicts how membership function is presented in a Triangular membership function

generator.
32
Figure 11: Example of membership function in our algorithm.
C. Construct all the rules for the inference system rule base:
In this section, we take advantage of existing data and information to infer knowledge and
experience in the form of rules, these rules are based on various case of if (X and Y)→ then(Z).
Those rules are an encoding of knowledge that can be used for prediction, but there are some
difficulties with this, because our experience is often encoded in a vague language. Therefore,
we need to inject some precision in our problem to make solving it rather easy, but the issue is
that the linguistic term that we use to describe the degree of something are fuzzy, so by making
it precise, we’ve lost some of the intent. So, we need to take into account the fuzziness or the
impreciseness of the language in our logical rules.
After the process of going from crisp input value to a fuzzy value (fuzzification), comes the
inference and the rule constructing that is based on those fuzzified value. In general, these rules
could create new fuzzy variables that are drastically different form the fuzzy set that was created
in the previous process.
After constructing the needed rules for our inference system, we have to apply them in function
of our desired result (if [input1 and input2] or [input3 and input4] then [output]).
D. Aggregate the input and the output membership function:

The results shown in the next part (aggregation of the inputs and output membership fct and the
defuzzified results with the four defuzzification method), are just an example to test our
algorithm, they are not simulated on a real probability matrix.
After fuzzifying the crisp inputs, and setting up the inference system (rule base), we need to
cluster the input and the output membership function together in order to get our dynamic
reservation threshold. The aggregated result is shown in a plot (fig.12), the threshold reservation
result depends on the input and the inference rules, the bleu zone in the plot is the range of the
33
result, the threshold reservation can be in any point of this zone, and the finale result will be
determined in the final step which is defuzzification.
Figure 12: Aggregated membership function.
E. Calculate the defuzzified result to get the output result:

The finishing step of our fuzzy logic algorithm is defuzzification and obtaining the final result
of the threshold reservation. Defuzzification is the process of taking the fuzzy outputs and
converting them to a single or crisp output value. This process may be performed by any one
of several defuzzification methods, but we worked with those four ones:
- Centroid method: this method is also known as the center of mass, center of area or
center of gravity, it is the most commonly used defuzzification method. In the
following image we can see the result of the centroid method in numerical shape on
the top of the figure and the black line in the yellow zone is the graphical
presentation of the result.
Figure 13: Threshold reservation result using the centroid method.
- Min of Maximum (SOM): This method determines the smallest value of the domain
with maximum membership value. The SOM result is shown in the figure and the
34
back line that show the defuzzified result is nearly impossible to see because the
result is zero.
Figure 14: Threshold reservation result using the SOM method.
- Mean of Maximum (MOM): In this method, the defuzzified value is taken as the
element with the highest membership values. When there are more than one element
having maximum membership values, the mean value of the maxima is taken. In
other words, the fuzzy controller uses the typical value of the consequent term of
the most valid rule as the crisp output value. This behavior results in stepped output
characteristics, as shown in the following image.
Figure 15: Threshold reservation result using the MOM method.
35
- Max of Maximum (LOM): Determine the largest value of the domain with
maximum membership value.
Figure 16: Threshold reservation result using the LOM method.
The following flowchart (fig.17) summarize all the steps above, this flowchart has been
converted into an algorithm is shown on Algorithm: Dynamic Reservation Threshold.
The flowchart starts with receiving the crisp inputs variables after initialization, then the
defuzzification of the inputs with the input membership function if succeeded, we continue to
the next step which is the inference and creation of the rule base, if not we go back to the
previous step. And is the same for the inference process if failed we go back to the fuzzification
process, and if it is well done it moves to the next process that is defuzzification which provides
the output membership function and aggregate it with the input membership function, and like
the two previous processes if it’s done flourishingly it comes to the final step in the flowchart
the output which is attending the dynamic threshold reservation, if not it goes back to the
previous step.
36
Figure 17: Flowchart of the proposed solution.
4. Conclusion
In this chapter, we focused on the problem to solve in this thesis: finding a dynamic threshold
for reservation of fog computing resources for connected vehicles. First, we started with the
main tool used which is the probability matrix. Then, we described the problem and the
assumptions considered. Afterwards, we detailed all steps for our approach which is based on
the context of the vehicle in order to determine the dynamic reservation threshold. Finally, this
approach was formulated as an algorithm which will be implemented, simulated, and discussed
in the next chapter.
37
Chapter 4: Performance Evaluation
1. Introduction
During this chapter, we evaluate the performance of our solution through simulation using
Python programming language. We first present the simulation settings followed by the
performance metrics which should be considered while analyzing the performance of our
solution. Then, we detail the simulation scenarios followed by the given results and discus them.
2. Simulation settings
In this part we are going to study the area where our simulation is conducted, the software and
the hardware environment where our programed solution is simulated.
2.1 Simulation environment

The probability matrices that we are going to simulate our algorithm on were generated, as we
mentioned before, by another researcher team from the SUMO (Simulation of Urban Mobility)
and the realistic traffic simulation InTAS (Ingolstadt Traffic Scenario). SUMO is an open-
source traffic simulation package developed by the German Aerospace Center (DLR) since
2001. As the traffic simulation requires the representation of road networks and traffic demand
to simulate in an own format, both have to be imported or generated using different sources.
The figure below shows the Area of InTAS simulation.
Figure 18: Area of InTAS simulation.
38
SUMO is a purely microscopic traffic simulation where each vehicle is defined at least by an
identifier (name), the departure time, and the vehicle’s route through the network. Also, each
vehicle can be described more detailed by adding the departure and arrival properties, the lane
to use, the velocity, or the position. Furthermore, the definitions of vehicles can be generated
using different sources such as:
- origin/destination matrices: they describe the movement between traffic assignment
zones in vehicle number per time.
- od2trips: an application for converting O/D matrices to single vehicle trips.
- jtrrouter: uses definitions of turn percentages at intersection for computing routes
through the network.
In recent years, some of research work were trying to create an accurate scenario based on real
traffic-data using SUMO. Among these works, InTAS have more advantages than other
scenario such as [30]:
- Modeled and validated with real traffic numbers.
- 24 hours of simulation.
- Actual road network based on the city of Ingolstadt.
- Reallocation of all Traffic Lights in city.
- Simulation of real Traffic Light Systems.
InTAS provides a great variety of roads (inner city, highway and federal roads) with a total
length of 717 km and a total area of about 52 square kilometers. To prepare the evaluation of
our solution, we received the probability matrices of 10 vehicles with their speed. From these
matrices, we deducted the vehicle position and the road type. Table 6 illustrate the whole
information about used vehicles. Obviously, when we decrease the cell size then we increase
the matrix size, consequently, simulation process needs more time computing.
Vehicle Id Road type Number Cell size (meters)
Highway Urban of 20 50 100 150 200
matrices Number of cells per matrix
1292 × 123
1617 × 887
15267 × 571
27245 × 269
41629 × 4382 32400 52560 13140 5810 3285
99851 × 795
101117 × 1053
118316 × 1100
119762 × 780
133499 × 1084
Table 6: Used matrices sizes.
39
3.2 Software programing environment
For the implementation of the dynamic reservation algorithm described in Chapter 3, we use
Python version 3 as a programming language. Beside C++ and Java, Python is one of the most
popular programming languages. Due to lack of skills and knowledge about the programming
language C++, it falls out of the selection of the language to be used. Compared to the compiled
language Java, Python is an interpreted Language, so testing smaller amounts of codes while
coding is faster with Python due to no need for compiling the code first to machine code like in
Java. Writing code in Python is 3-5 times shorter than equivalent Java programs, which makes
it more transparent and better understandable for other programmers to read. Also, for plotting
figures, it is faster to read and write of the files and it makes the evaluation of the data much
easier, Python can be used for all purpose of this thesis.
3.3 Hardware programming environment

All experiments are conducted on a pc, with 6 GB of RAM, 2.00 GHz speed, Intel Core i3-
5005, 2000 MHz based speed, equipped with 2 cores and 4 logical processors, and it has 5.92
Go physical memory and 8.83 Go virtual memory.
3.4 Performance Metrics

The measurements of computational time taken by the prediction algorithms were done for
every iteration. Decreasing the cell size increases the total number of cells within a matrix, thus
the algorithm needs more time computing because of calculating for more cells.
Knowing that as the cell size decreases, the number of cells (n) increases, and thus the algorithm
requires more computing time. With a cell size of 20 meters, execution time can exceed 1
second at worst. It is the execution time in the worst-case scenario.
3. Simulation results
In this section, we are going to present the results of our algorithm on different cell size. The
shown results were conducted on Vehicle 1292 in highway and then Vehicle 27245 in urban
area. It is noteworthy that every cell of the used probability matrix has its own risk.
As we mentioned before in Table 6, Vehicle 1292 is on the highway road with 123 matrices,
and Vehicle 27245 in on urban road with 269 matrices. We tested all of them but we are going
to present 16 of them according to the fuzzy rules that we conducted in our algorithm (Figure
14).
We are going to reformulate those fuzzy rules to if then rules:
40
- If the “risk” is very low and “speed” is very slow then the “threshold reservation” is
high.
- If the “risk” is very low and “speed” is slow then the “threshold reservation” is high.
- If the “risk” is very low and “speed” is fast then the “threshold reservation” is
middle.
- If the “risk” is very low and “speed” is very fast then the “threshold reservation” is
middle.
- If the “risk” is low and “speed” is very slow then the “threshold reservation” is high.
- If the “risk” is low and “speed” is slow then the “threshold reservation” is high.
- If the “risk” is low and “speed” is fast then the “threshold reservation” is middle.
- If the “risk” is low and “speed” is very fast then the “threshold reservation” is
middle.
- If the “risk” is middle and “speed” is very slow then the “threshold reservation” is
middle.
- If the “risk” is middle and “speed” is slow then the “threshold reservation” is middle.
- If the “risk” is middle and “speed” is fast then the “threshold reservation” is low.
- If the “risk” is middle and “speed” is very fast then the “threshold reservation” is
very low.
- If the “risk” is high and “speed” is very slow then the “threshold reservation” is low.
- If the “risk” is high and “speed” is slow then the “threshold reservation” is low.
- If the “risk” is high and “speed” is fast then the “threshold reservation” is very low.
- If the “risk” is high and “speed” is very fast then the “threshold reservation” is very
low.
After conducting all the rules in our algorithm, we choose to work with four defuzzification
methods (centroid, mean of the maximum, min of the maximum, and max of the maximum),
but the most relay on method in our work is centroid one.
3.1 Simulation on vehicle 1292

In the simulation of the vehicle 1292, we are going to test it on the cell size 20-50-100.
A. Speed-based threshold reservation with cell size 20

Table 7 represents the results of the simulated matrixes by cell size 20:
Vehicle ID: 1292 with cell size 20

Rule number Threshold result (%)
41
Matrix Vehicle Risk Centroid SOM MOM LOM
number speed (%)
(km per
h)
Speed Rule1 1292-1 14,82 12 87,363 86 93 100
very Rule 2 1292-3 4,46 36 83.46 96 98.0 100
low & Rule 3 1292-122 3,69 52 79,7 86 93 100
Risk Rule 4 1292-35 17,16 88 50,06 33,5 18 49
variable
Speed Rule 5 1292-50 48,22 18 71,42 85 92,5 100
low & Rule 6 1292-39 43,44 33 75,21 91 95,5 100
Risk Rule 7 1292-60 49,02 59 51,75 51 66,5 82
variable Rule 8 1292-38 36,65 78 54,14 56 67 78
Speed Rule 9 1292-65 66 8 66,67 59 66,5 74
fast & Rule 10 1292-70 78,40 26 66,66 56 67 78
Risk Rule 11 1292-78 60.89 54 47,8 21 33,5 46
variable Rule 12 1292-64 58,39 100 23,49 0 4 8
Speed Rule 13 1292-100 199 20 66,66 54 67 80
very Rule 14 1292-90 172,28 42 67,27 59 67 75
fast & Rule 15 1292-84 132,38 68 20,86 0 6 12
Risk Rule 16 1292-102 199,86 91 20 0 6 12
variable
Table 7: Results of the threshold reservation on vehicle 1292 on cell size 20.
- Matrix 1292-1 probability map and threshold reservation result using centroid
method on cell size 20
Figure 19 presents the probability map of Matrix 1 of Vehicle 1292 (a vehicle on the highway
after coming from an urban area). The white line in the figure shows the possible path of the
road that Vehicle 1292 with the 1st matrix can go take on the cell size 20. When the cells in the
line get darker that means that the probability matrix is getting lower and vis-versa (when the
cells get brighter the probability matrix is higher).
42
Figure 19: Probability map of matrix 1 of vehicle 1292 on cell size 20.
As we mentioned before, the method that we rely on method is the centroid. Figure 20 illustrates
the result of the threshold reservation with a plot. The yellow zone represents the range of our
result, it can change depending on the inputs and the defuzzification method, which is
represented as a black line in the yellow zone (the other plots of the threshold reservation result
are illustrated in Annex 1), and the result is written on the top left of the figure.
Figure 20: Result of threshold reservation on of matrix 1 of vehicle 1292 on cell size 20 with Centroid method.
- Matrix 1292-102 probability map and threshold reservation result using

centroid method on cell size 20
The figure 21 represents the probability map of the matrix 84 of the vehicle 1292, it is a vehicle
on the highway after coming from an urban area. The white line in the figure shows the possible
path of the road that the car 1292 with the 84th matrix can go take on the cell size 20.
43
Figure 22 illustrates the result of the threshold reservation with centroid method, the numerical
result is presented on the top left of the figure and the graphical presentation of the result is
presented as a line the yellow zone.
Figure 22: Result of the threshold reservation of matrix 84 of the vehicle 1292 on cell size 20 with Centroid
method.
The other threshold reservation with the other methods and the other matrixes probability map
and results of the vehicle 1292 on cell size 20 are presented in annex 1.
B. Speed-based threshold reservation with cell size 50
Table 8 represents the results of the simulated matrixes by cell size 50

Rule number Matrix Vehicle Risk Threshold result (%)
number speed (%) Centroid SOM MOM LOM
44
(km per
h)
Speed Rule1 1292-1 14,82 90 43,69 19 33,5 48
very Rule 2 1292-3 4,46 60 33,33 29 33 37
low & Rule 3 1292-122 3,69 24 88,20 91 95,5 100
Risk Rule 4 1292-35 17,16 0 87,12 84 92 100
variable
Speed Rule 5 1292-50 48,22 95 37,42 19 33 48
low & Rule 6 1292-39 43,44 60 56,10 57 66,5 76
Risk Rule 7 1292-60 49,02 37 65,17 85 92,5 100
variable Rule 8 1292-38 36,65 12 87,33 89 94,5 100
Speed Rule 9 1292-65 66 91 19,44 0 4,5 9
fast & Rule 10 1292-70 78,40 55 48,37 22 33,5 45
Risk Rule 11 1292-78 60.89 15 67,24 52 66,5 81
variable Rule 12 1292-64 58,39 3 67,63 59 66,5 74
Speed Rule 13 1292-100 199 100 9,76 0 0 0
very Rule 14 1292-90 172,28 82 20,86 0 6 12
fast & Rule 15 1292-84 132,38 40 58,63 61 67 73
Risk Rule 16 1292-102 199,86 15 66 52 66,5 81
variable

on the highway after coming from an urban area. The white line in the figure shows the possible
path of the road that the car 1292 with the 38th matrix can go take on the cell size 50.
45
Figure 24 illustrates the result of the threshold reservation with centroid method of matrix 38
on cell size 50, the numerical result is presented on the top left of the figure and the graphical
presentation of the result is presented as a line the yellow zone.
method.

The figure 25 represents the probability map of the matrix 70 of the vehicle 1292 on cell size
50.
46
on cell size 50.
method.
C. Speed-based threshold reservation with cell size 100

Table 9 represent the result of the simulation matrixes by cell size 100:

(km per
h)
Rule1 1292-1 14,82 15 87,33 86 93 100
47
Speed Rule 2 1292-3 4,46 29 88,71 96 98 100
very Rule 3 1292-122 3,69 55 83,73 89 94,5 100
low & Rule 4 1292-35 17,16 85 50,51 19 33,5 48
Risk
variable
Speed Rule 5 1292-50 48,22 20 87,61 87 93,5 100
low & Rule 6 1292-39 43,44 38 79,28 89 94,5 100
Risk Rule 7 1292-60 49,02 62 67,76 58 66,5 75
variable Rule 8 1292-38 36,65 79 56,14 52 66,5 81
Speed Rule 9 1292-65 66 6 88,57 95 97,5 100
fast & Rule 10 1292-70 78,40 22 77,96 89 94,5 100
Risk Rule 11 1292-78 60,89 55 68,58 55 66,5 78
variable Rule 12 1292-64 58,39 90 44,83 24 33,5 43
Speed Rule 13 1292-100 199 11 66,66 56 65,5 77
very Rule 14 1292-90 172,28 48 55,17 53 67 81
fast & Rule 15 1292-84 132,38 76 32,83 25 33,5 42
Risk is Rule 16 1292-102 199,86 98 18,86 0 1 2
variable

100. As we said before the white line in the figure shows the possible path of the road that the
car 1292 with the 102th matrix can go take on the cell size 100. When the cells in the line get
darker that means that the probability matrix is getting lower and when the cells get brighter
the probability matrix is higher.
48
on cell size 100, the numerical result is presented on the top left of the figure and the graphical
presentation of the result is presented as a line the yellow zone.
method.

100.
49
on cell size 100.
method.
3.2 Simulation on vehicle 27245

In the simulation of the vehicle 27245, we are going to test it on the cell size 150-200.
A. Risk-based threshold reservation with cell size 150


50
(km per
h)
Speed Rule1 27245-1 14,27 20 87,61 87 93,5 100
very Rule 2 27245-90 20,67 33 88,06 90 95 100
low & Rule 3 27245-140 20,65 58 74,68 90 95 100
Risk Rule 4 27245-80 20,43 89 42,52 23 33,5 44
variable
Speed Rule 5 27245-64 38,56 13 87,49 86 93 100
low & Rule 6 27245-4 36,39 46 72,15 85 92,5 100
Risk Rule 7 27245-5 43,47 62 68,56 56 67 78
variable Rule 8 27245-59 40,76 99 35,05 21 33,5 46
Speed Rule 9 27245-20 51,75 22 87,92 89 94,5 100
fast & Rule10 27245-28 51,89 55 68,58 55 66,5 78
Risk Rule11 27245-35 52,05 72 60,65 60 66,5 73
variable Rule12 27245-6 50,69 100 33,33 26 33,5 41
Speed Rule13
very Rule14 The vehicle 27245 is in an urban area it doesn’t reach the “very fast”
fast & Rule15 level of speed.
Risk is Rule16
variable

in an urban area. The two white lines in the figure shows the possible path of the road that the
vehicle 27245 with the 6th matrix can go take on the cell size 150.
51
Figure 31: Probability map of matrix 6 of the vehicle 27245 on cell size 150.
Figure 32 presents the result of the threshold reservation for the matrix 6 of the vehicle on cell
size 150.
Figure 32: Result of the threshold reservation of matrix 6 of the vehicle 27245 on cell size 150.

The figure 33 represents the probability map of the matrix 90 of the vehicle 27245.
52
Figure 33: Probability map of matrix 90 of the vehicle 27245 on cell size 150.
The following figure represents the threshold reservation result of the matrix 90 of the vehicle
27245 on cell size 150.
Figure 34: Result of the threshold reservation of matrix 90 of the vehicle 27245 on cell size 150.
B. Risk-based threshold reservation with cell size 200


(km per
h)
Rule1 27245-1 14,27 15 87 86 93 100
Rule 2 27245-90 20,67 23 88,06 90 95 100
53
Speed Rule 3 27245-140 20,65 62 74,68 90 95 100
very Rule 4 27245-80 20,43 100 33,33 24 33,5 43
low &
Risk
variable
Speed Rule 5 27245-64 38,56 21 87,49 86 93 100
low & Rule 6 27245-4 36,39 59 69,91 52 66,5 81
Risk Rule 7 27245-5 43,47 73 60,37 56 67 78
variable Rule 8 27245-59 40,76 82 53,61 52 67 82
Speed Rule 9 27245-20 51,75 4 88,42 93 96,5 100
fast & Rule 10 27245-28 51,89 49 71,14 85 92,5 100
Risk Rule 11 27245-35 52,05 68 65,45 60 66,5 73
variable Rule 12 27245-6 50,69 89 46,55 23 33,5 44
Speed Rule13
very Rule14 Because the vehicle 27245 is in an urban area it doesn’t reach the “very
fast & Rule15 fast” level of speed.
Risk is Rule16
variable

54
on cell size 200.
Figure 36: Result of the threshold reservation of matrix 20 of vehicle 27245 on cell size 200 with Centroid
method.

Figure 38 shows the result of the threshold reservation with centroid method of matrix 64 on
cell size 200.
55
Figure 38: Result of the threshold reservation of matrix 64 of vehicle 27245 on cell size 200 with Centroid
method.
The probability map of each executed matrix and the defuzzified plotted results for vehicle
27245 on cell size 200 are shown in annex 2.
4. Conclusion
The simulation results shown in this chapter demonstrate how the suggested strategy can
maximize the number of reserved fog nodes in comparison to a static threshold. Additionally,
we tested the efficiency of the suggested algorithm for various cell sizes (20, 50, 100, 150, and
200 meters) and two different types of roadways (urban and highway). The suggested solution
would assist in enhancing both the reservation time and the level of car satisfaction.
56
Conclusion and Perspective
To accomplish compute-intensive and latency-sensitive tasks, emerging vehicular applications
necessitate a large amount of computing capacity. Fog computing, which focuses on relocating
computing resources to the network's edge, complements cloud computing by addressing
latency issues and reducing traffic to the cloud. This spawned a new paradigm known as
Vehicular Fog Computing (VFC).
A significant challenge with this new paradigm arises when a vehicle attempts to reserve
computing fog resources based on its probability matrix at a given time. As a result, we have
concentrated our efforts throughout this thesis on the reservation threshold in order to achieve
a guaranteed reservation and an adequate level of vehicle satisfaction.
To do, at first, we started to study and provide background information about IoT, cloud, edge,
and fog computing. In addition, we also presented detailed overview about vehicular fog
computing. Here, our goal was to get a deeper understanding on this new paradigm, in order to
get position of the thesis in relation to the problem to be solved.
In addition, we discussed task offloading in fog computing, its challenges, and application areas
in VFC. As a matter of fact, we examined various resource reservation techniques for connected
vehicles. Following that, we presented our proposed solution.
We have shown that the proposed solution allows to cope with uncertainties to guarantee
reservation with dynamic threshold. In addition, we validated the effectiveness of the proposed
algorithm by testing it for different cell size (20 – 50 – 100 – 150 – 200 meters) and for two
types of roads (urban and highway).
However, in this thesis some constraints have not been addressed since we made assumptions,
but they represent shortcomings that will be addressed in the future. Thus, future works can be
further extended to the following direction: we have always assumed that the current budget
of the vehicle covers the cost of the fog node reservation and we took for granted the risk that
the vehicle faced.
Nevertheless, in the real world the budget default case can easily be encountered. To get closer
to reality, it is recommended to design an extension based on fuzzy logic which consider the
vehicle budget and infuse machine learning to fuzzy logic which help us detect accident and
uncertainties in both urban and highway roads.
57
References
[1] P. Sethi and S. R. Sarangi, « Internet of things: architectures, protocols, and applications »,
Journal of Electrical and Computer Engineering, vol. 2017, 2017.
[2] M. S. Aslanpour, S. S. Gill and A. N. Toosi, «Performance Evaluation Metrics for Cloud,
Fog and Edge Computing: A Review, Taxonomy, Benchmarks and Standards for Future
Research», Part of the Studies in Computational Intelligence book series (SCI,volume 731),
2017.
[3] M. De Donno, K. Tange, and N. Dragoni, « Foundations and Evolution of Modern
Computing Paradigms: Cloud, IoT, Edge, and Fog », IEEE Access, vol. 7, p. 150936‑150948,
2019, doi: 10.1109/ACCESS.2019.2947652.
[4] K. Cao, Y. Liu, G. Meng, and Q. Sun, « An Overview on Edge Computing Research »,
IEEE Access, vol. 8, p. 85714‑85728, 2020, doi: 10.1109/ACCESS.2020.2991734.
[5] S. H. et N. V., « A Review on Fog Computing: Architecture, Fog with IoT, Algorithms and
Research Challenges », ICT Express, vol. 7, no 2, p. 162‑176, June 2021, doi:
10.1016/j.icte.2021.05.004.
[6] N. Gaouar and M. Lehsaini, « Toward vehicular cloud/fog communication: A survey on
data dissemination in vehicular ad hoc networks using vehicular cloud/fog computing », Int J
Common Syst, vol. 34, no 13, sept. 2021, doi: 10.1002/dac.4906.
[7] C. Huang, R. Lu, and K.-K. R. Choo, « Vehicular Fog Computing: Architecture, Use Case,
and Security and Forensic Challenges », IEEE Common. Mag., vol. 55, no 11, p. 105‑111,
November. 2017, doi: 10.1109/MCOM.2017.1700322.
[8] M. Ashraf, M. Shiraz, A. Abbasi, and S. Albahli, « Distributed application execution in fog
computing: A taxonomy, challenges and future directions », Journal of King 56 Saud University
- Computer and Information Sciences, vol. 34, no 7, p. 3887‑3909, July. 2022, doi:
10.1016/j.jksuci.2022.05.002.
[9] I. B. Lahmar and K. Boukadi, « Resource Allocation in Fog Computing: A Systematic
Mapping Study », in 2020 Fifth International Conference on Fog and Mobile Edge Computing
(FMEC), Paris, France, April. 2020, p. 86‑93. doi: 10.1109/FMEC49853.2020.9144705.
[10] K. Gasmi, S. Dilek, S. Tosun, and S. Ozdemir, « A survey on computation offloading and
service placement in fog computing-based IoT », J Supercomput, vol. 78, no 2, p. 1983‑2014,
February. 2022, doi: 10.1007/s11227-021-03941-y.
58
[11] F. Saeik et al., « Task offloading in Edge and Cloud Computing: A survey on mathematical,
artificial intelligence and control theory solutions », Computer Networks, vol. 195, p. 108177,
August 2021, doi: 10.1016/j.comnet.2021.108177.
[12] A. Waheed et al., « A Comprehensive Review of Computing Paradigms, Enabling
Computation Offloading and Task Execution in Vehicular Networks », IEEE Access, vol. 10,
p. 3580‑3600, 2022, doi: 10.1109/ACCESS.2021.3138219.
[13] N. Aljeri and A. Boukerche, « Movement prediction models for vehicular networks: an
empirical analysis », Wireless Netw, vol. 25, no 4, p. 1505‑1518, May 2019, doi:
10.1007/s11276-017-1607-x.
[14] C. Lum, R. Rysdyk, and A. Pongpunwattana, « Occupancy Based Map Searching Using
Heterogeneous Teams of Autonomous Vehicles », presented in AIAA Guidance, Navigation,
and Control Conference and Exhibit, Keystone, Colorado, August 2006. doi: 10.2514/6.2006-
6196.
[15] U. Kubach and K. Rothermel, « Exploiting location information for infostation-based
hoarding », in Proceedings of the 7th annual international conference on Mobile computing and
networking - MobiCom ’01, Rome, Italy, 2001, p. 15‑27. doi: 10.1145/381677.381680.
[16] G. Premsankar, B. Ghaddar, M. Di Francesco, and R. Verago, « Efficient placement of
edge computing devices for vehicular applications in smart cities », in NOMS 2018 - 2018
IEEE/IFIP Network Operations and Management Symposium, Taipei, Taiwan, April. 2018, p.
1‑9. doi:10.1109/NOMS.2018.8406256.
[17] D. Chen, Y.-C. Liu, B. Kim, J. Xie, C. S. Hong, and Z. Han, « Edge Computing Resources
Reservation in Vehicular Networks: A Meta-Learning Approach », IEEE Trans. Veh.
Technol., vol. 69, no 5, p. 5634‑5646, May 2020, doi: 10.1109/TVT.2020.2983445.
[18] Y. Hui, Z. Su, T. H. Luan, and C. Li, « Reservation Service: Trusted Relay Selection for
Edge Computing Services in Vehicular Networks », IEEE J. Select. Areas Common., vol. 38,
no 12, p. 2734‑2746, December. 2020, doi: 10.1109/JSAC.2020.3005468.
[19] J. Zhang, S. Chen, X. Wang, and Y. Zhu, « DeepReserve: Dynamic Edge Server
Reservation for Connected Vehicles with Deep Reinforcement Learning », in IEEE INFOCOM
2021 - IEEE Conference on Computer Communications, Vancouver, BC, Canada, May 2021,
p. 1‑10. doi: 10.1109/INFOCOM42981.2021.9488888.
[20] N. Naddeh, S. B. Jemaa, S. Eddine ELAYOUBI, and T. Chahed, « Proactive RAN
Resource Reservation for URLLC Vehicular Slice », in 2021 IEEE 93rd Vehicular Technology
Conference (VTC2021-Spring), Helsinki, Finland, April. 2021, p. 1‑5. doi: 10.1109/VTC2021-
Spring51267.2021.9448703.
59
[21] L. A. Zadeh, «Making computers think like people [fuzzy set theory] », in IEEE Spectrum,
Volume: 21, Issue: 8, p.26-32, August 1984, doi: 10.1109/MSPEC.1984.6370431.
[22] I. Tal, and G. B. Muntean, «Towards Reasoning Vehicles: A Survey of Fuzzy Logic-Based
Solutions in Vehicular Networks», ACM Computing Surveys, Volume 50, Issue 6, November
2018, Article No: 80, p.1–37, doi: 10.1145/3125640.
[23] P. Hajek, L. Godo, and F. Esteva,« Fuzzy Logic and Probability», Cornell University, in
Proceedings of the Eleventh Conference on Uncertainty in Artificial Intelligence, 2013, doi:
/10.48550/arXiv.1302.4953.
[24] M. Kaufmann, S. Tobias, and R. Schulin, «Quality evaluation of restored soils with a fuzzy
logic expert system», Geoderma, Volume 151, Issues 3–4, 15 July 2009, Pages290-302, doi:
10.1016/j.geoderma.2009.04.018.
[25] A. Adeli, and M. Neshat, «A Fuzzy Expert System for Heart Disease Diagnosis»,
Proceedings of the International Multi Conference of Engineers and Computer Scientists 2010,
Hong Kong, Vol I, IMECS 2010, March 17 - 19, 2010, doi: 10.1109/20780966.
[26] S. Thakera, and V. Nagorib, «Analysis of Fuzzification Process in Fuzzy Expert System»,
International Conference on Computational Intelligence and Data Science, Procedia Computer
Science, Volume 132, Pages 1308-1316, 2018, doi: 10.1016/j.procs.2018.05.047.
[27] P. Albertos, A. Sala, M. Olivers, «Fuzzy logic controllers. Advantages and drawbacks», X
Spanish Congress on Fuzzy Technologies and Fuzzy Logic ESTYLF'00, Sevilla, Spain,
September 2000.
[28] M. Mahfouf, M. F. Abbod, and D. A. Linkens, «A survey of fuzzy logic monitoring and
control utilisation in medicine», Artificial Intelligence in Medicine, Volume 21, Issues 1–3,
Pages 27-42, January–March 2001, doi: /10.1016/S0933-3657(00)00072-5.
[29] L. Suganthi, S. Iniyan, and A. A. Samuel, «Applications of fuzzy logic in renewable energy
systems – A review», Renewable and Sustainable Energy Reviews, Volume 48, Pages 585-
607, August 2015, doi: /10.1016/j.rser.2015.04.037.
[30] S. C. Lobo, S. Neumeier, E. M. G. Fernandez, and C. Facchi, « InTAS -- The

Ingolstadt Traffic Scenario for SUMO ». arXiv, 24 November 2020. Last consultation of the
site : novembre 16th 2022, doi : 2011.11995.
60
Annexes
Annex 1: Threshold reservation of the vehicle 1292 with cell size 20
- Matrix 1: Threshold reservation results:
Annex 1-fig 1: Result of the threshold reservation of matrix 1 of vehicle 1292 on cell size 20 with MOM method.
Annex 1-fig 2: Result of the threshold reservation of matrix 1 of vehicle 1292 on cell size 20 with SOM method.
Annex 1-fig 3: Result of threshold reservation of matrix 1 of vehicle 1292 on cell size 20 with LOM method.
61
- Matrix 3: Probability map and threshold reservation results:
Annex 1-fig 4: Probability map of matrix 3 of vehicle 1292 on cell size 20.
Annex 1-fig 5 : Result of threshold reservation on of matrix 3 of vehicle 1292 on cell size 20 with Centroid
method.
Annex 1-fig 6: Result of threshold reservation on of matrix 3 of vehicle 1292 on cell size 20 with SOM method.
62
Annex 1-fig 7: Result of threshold reservation on of matrix 3 of vehicle 1292 on cell size 20 with MOM method.
Annex 1-fig 8: Result of threshold reservation on of matrix 3 of vehicle 1292 on cell size 20 with LOM method.
- Matrix 122: Probability map and threshold reservation results
Annex 1-fig 9: Probability map of the matrix 122 of the vehicle 1292 on cell size 20.
63
Annex 1-fig 10: Result of the threshold reservation of matrix 122 of the vehicle 1292 on cell size 20 with
centroid method.
Annex 1-fig 11: Result of the threshold reservation of matrix 122 of the vehicle 1292 on cell size 20 with MOM
method.
Annex 1-fig 12: Result of the threshold reservation of matrix 122 of the vehicle 1292 on cell size 20 with SOM
method.
64
Annex 1-fig 13: Result of the threshold reservation of matrix 122 of the vehicle 1292 on cell size 20 with LOM
method.
Annex 1-fig 15: Result of the threshold reservation of matrix 35 of the vehicle 1292 on cell size 20 with centroid
method
65
.
method.
method.
method.
66
Annex 1-fig 20: Result of the threshold reservation of matrix 50 of the vehicle 1292 on cell size 20 with Centroid
method
method.
67
method.
method.
- Matrix 39: Probability map and threshold reservation result
68
method.
method.
method.
69
method.
method
70
method.
method.
method.
71
method.
method.
72
method.
method.
73
Annex 1-fig 39: Probability map of the matrix 65 of the vehicle 1292 on cell size 20
method.
method.
74
method.
method.
75
method.
method.
76
method.
method.
77
method.
method.
78
method.
method.
79
method.
method.
80
method.
method.
- Matrix 100: Probability map and threshold reservation result
81
Annex 1-fig 60: Result of the threshold reservation of matrix 100 of the vehicle 1292 on cell size 20 with
Centroid method.
method.
82
method.
Annex 1-fig 63: Result of the threshold reservation of matrix 100 of the vehicle 1292 on cell size 20 with LOM method.
83
method.
method.
84
method.
method.
- Matrix 84: Threshold reservation results
method.
85
method.
method.
86
Annex 2: Threshold reservation of the vehicle 27245 with cell size 200
Annex 2-fig 2: Results of threshold reservation of matrix 1 of vehicle 27245 on cell size 200 with Centroid
method.
Annex 2-fig 3: Results of threshold reservation of matrix 1 of vehicle 27245 on cell size 200 with MOM method.
87
Annex 2-fig 4: Results of threshold reservation of matrix 1 of vehicle 27245 on cell size 200 with SOM method.
Annex 2-fig 5: Results of threshold reservation of matrix 1 of vehicle 27245 on cell size 200 with LOM method.
- Matrix 90: Probability map and threshold results
88
Annex 2-fig 7 : Results of threshold reservation of matrix 90 of vehicle 27245 on cell size 200 with Centroid
method.
Annex 2-fig 8: Results of threshold reservation of matrix 90 of vehicle 27245 on cell size 200 with MOM
method.
Annex 2-fig 9: Results of threshold reservation of matrix 90 of vehicle 27245 on cell size 200 with SOM
method.
89
Annex 2-fig 10: Results of threshold reservation of matrix 90 of vehicle 27245 on cell size 200 with LOM
method.
- Matrix 140: Probability map and threshold results
Annex 2-fig 12: Result of the threshold reservation of matrix 140 of vehicle 27245 on cell size 200 with Centroid
method.
90
Annex 2-fig 13: Result of the threshold reservation of matrix 140 of vehicle 27245 on cell size 200 with MOM method.
Annex 2-fig 14: Result of the threshold reservation of matrix 140 of vehicle 27245 on cell size 200 with SOM
method.
Annex 2-fig 15: Result of the threshold reservation of matrix 140 of vehicle 27245 on cell size 200 with LOM
method.
91
method.
Annex 2-fig 18: Result of the threshold reservation of matrix 80 of vehicle 27245 on cell size 200 with MOM
method.
92
method.
method.
method.
93
method.
method.
- Matrix 6: probability map and threshold reservation results
94
method.
method.
method.
95
method.
method.
96
method.
method.
method.
97
method.
method.
98
method.
method.
method.
99
method.
method.
100
method.
method.
method.
101
method.
method.
102
method.
method.
method.
103
method.
method.
104
method.
method.
105

Thesis Report Final (1) - 230901 - 202841

Uploaded by

Copyright:

Available Formats

Thesis Report Final (1) - 230901 - 202841

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thesis Report Final (1) - 230901 - 202841

Uploaded by

Copyright:

Available Formats

Acknowledgment

First and foremost, I want to express my heartfelt gratitude to my supervisors, M. Abdelmajid

Chapter 1: IOT Basics and Computing Paradigms .................................................................... 2

2. Internet Of Things (IOT) Basics ..................................................................................... 2

2.1 IOT Definition ......................................................................................................... 2

2.2 IOT Architecture ...................................................................................................... 2

3.1 Cloud Computing ..................................................................................................... 6

3.2 Edge Computing ...................................................................................................... 6

3.3 Fog Computing ........................................................................................................ 8

4. Vehicular Fog Computing ............................................................................................... 9

4.1 Definition of VFC .................................................................................................... 9

4.2 VFC Architecture ................................................................................................... 10

4.3 VFC Features ......................................................................................................... 11

4.4 Taxonomy of Application Execution Step in VFC ................................................ 11

Chapter 2: Task offloading and Computation Resource Allocation ........................................ 14

2. Task Offloading in Fog Computing .............................................................................. 14

2.1 Task offloading challenges .................................................................................... 15

2.2 Task Offloading Approaches ................................................................................. 16

3. Application Areas of Task Offloading in VFC ............................................................. 16

4. Fog Computing Resource Reservation for Connected Vehicles ................................... 18

4.1 Movement Prediction of the Vehicles .................................................................... 18

4.2 Computation Resource Reservation ....................................................................... 19

2. What is fuzzy logic ........................................................................................................ 22

2.1 Fuzzy Expert System ............................................................................................. 24

2.2 Fuzzy logic pros and cons ...................................................................................... 26

2.3 Fuzzy logic application area .................................................................................. 26

3. Design of the Proposed Solution ................................................................................... 28

3.1 Probability Map ..................................................................................................... 28

3.2 Problem Description and Assumptions .................................................................. 29

3.3 Proposed algorithm ................................................................................................ 30

Chapter 4: Performance Evaluation ......................................................................................... 38

2. Simulation settings ........................................................................................................ 38

2.1 Simulation environment ......................................................................................... 38

3.2 Software programing environment ........................................................................ 40

3.3 Hardware programming environment .................................................................... 40

3.4 Performance Metrics .............................................................................................. 40

3. Simulation results .......................................................................................................... 40

3.1 Simulation on vehicle 1292 ................................................................................... 41

3.2 Simulation on vehicle 27245 ................................................................................. 50

Conclusion and Perspective ..................................................................................................... 57

2. Internet Of Things (IOT) Basics

2.1 IOT Definition

2.2 IOT Architecture

B. Five-layer IOT Architecture

Figure 3: Relationship between Cloud, Fog & Edge computing [2].

- On-demand self-service: computing capabilities can be provided automatically

3.2 Edge Computing

Applicable Network Latency Calculation

Table 1: Main differences between cloud computing and edge.

4. Vehicular Fog Computing

4.1 Definition of VFC

Figure 4: Architecture of vehicular fog computing [7].

- Confidentiality: Confidentiality ensures that any unauthorized access attempts to

4.4 Taxonomy of Application Execution Step in VFC

Figure 5: Steps involved in Application Execution.

2. Task Offloading in Fog Computing

2.1 Task offloading challenges

3. Application Areas of Task Offloading in VFC

Below, we’re going to give a few use cases [12]: