Fog Computing Applications: Taxonomy and Requirements
Arif Ahmed HamidReza Arkian Davaadorj Battulga Ali J. Fahs Mozhdeh Farhadi Dimitrios Giouroukis Adrien Gougeon Felipe Oliveira Gutierrez Guillaume Pierre Paulo R. Souza Jr Mulugeta Ayalew Tamiru Li Wu
cs.DC










 







































Fog Computing Applications:
 Taxonomy and Requirements
    Arif Ahmed,
  HamidReza Arkian,
  Davaadorj Battulga,
  Ali J. Fahs,
  Mozhdeh Farhadi,
  Dimitrios Giouroukis,
  Adrien Gougeon,
  Felipe Oliveira Gutierrez,
  Guillaume Pierre,
  Paulo R. Souza Jr,
  Mulugeta Ayalew Tamiru,
  Li Wu,
  
    A. Ahmed, H. Arkian, A. J. Fahs, A. Gougeon, G. Pierre and P. R. Souza Jr are with Univ Rennes, INRIA, CNRS, IRISA.
    D. Battulga and M. Farhadi are with U-Hopper srl.
    D. Giouroukis and F.O. Gutierrez are with TU Berlin.
    M.A. Tamiru and L. Wu are with Elastisys AB.
  
  All co-authors contributed equally to this paper.

    December 30, 2023
=================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================






  Fog computing was designed to support the specific needs of
  latency-critical applications such as augmented reality, and IoT
  applications which produce massive volumes of data that are
  impractical to send to faraway cloud data centers for
  analysis. However this also created new opportunities for a wider
  range of applications which in turn impose their own requirements on
  future fog computing platforms. This article presents a study of a
  representative set of 30 fog computing applications and the
  requirements that a general-purpose fog computing platform should
  support.





§ INTRODUCTION



Fog computing extends cloud computing platforms with additional
compute, storage and networking resources that are placed in the
immediate vicinity of end-user devices. Because of its proximity to
end users and their IoT devices, fog computing promises to deliver
extremely low network latencies between the end-user devices and the
fog computing resources serving them, and to process transient data
produced by the end-user devices locally. Research in the domain of
fog computing is currently very active and many researchers propose
new mechanisms to design the next-generation fog computing
platforms <cit.>.

Fog computing researchers however need to face a difficult challenge:
currently, no large-scale general-purpose fog computing platform is
publicly available. To design useful fog computing platforms they,
however, need to understand in detail which kind of applications will
make use of fog computing technologies and which requirements they
will put on the underlying fog platforms. On the other hand, few (if
any) developers will spend significant time building applications
which exploit the capabilities of fog computing platforms unless these
platforms already actually exist.

To break this vicious circle we propose to study a representative set
of fog applications which either were already implemented, or simply
proposed for future development. We carefully selected 30 actual or
proposed applications that cover a wide range of usage types for
future fog computing platforms. We then use this set of reference
applications to address a number of crucial questions about the
functional and non-functional requirements that a general-purpose fog
computing platform should have. We show that fog applications and
their respective requirements are very diverse, and highlight the
specific features that fog platform designers may want to integrate in
their systems to support specific categories of applications.

This article is organized as follows. Section <ref>
presents a general background about fog computing platforms and
applications. Section <ref> discusses our methodology
for selecting a representative set of reference applications. Then,
Section <ref> analyses the requirements that these
applications put on fog computing platforms and
Section <ref> concludes this article.





§ BACKGROUND



Fog computing was originally designed as an extension of cloud
computing with additional compute, storage and communication resources
located close to the end users <cit.>. The main purpose of
this technology was to support the specific needs of latency-critical
applications such as augmented reality <cit.>,
and IoT applications which produce massive volumes of data that are
impractical to send to faraway cloud data centers for
analysis <cit.>. Several excellent surveys of fog
computing technologies are available <cit.>.

However, the expected availability of fog computing technologies has
created opportunities for other types of applications than the
originally anticipated ones. These applications bring their own sets
of requirements which must also be taken into account in the design of
future fog computing platforms.  The published fog computing surveys
focus mostly on fog computing technologies (i.e., the solutions). To
our best knowledge, no article so far has attempted at deriving the
requirements for fog computing platforms from a representative set of
actual and anticipated fog applications. This is the purpose of the
current article.





§ METHODOLOGY



We base this study on a review of literature describing specific fog
computing applications. The objective is not to build an exhaustive
list of all proposed applications for fog computing, but rather to
identify a representative sample of typical usages of fog computing
technologies. Because fog computing is still an emerging technology,
we included descriptions of both actual implemented fog application
and proposed future ones. We selected papers based on the following
criteria:


  Detailed application description.  We sought for papers
  containing a detailed technical description of the proposed
  application, and discarded papers which proposed an idea with no
  further technical details.

  Publication venue. We sought for papers which were published in
  peer-reviewed international conferences and journals. In addition,
  we also included white papers published by reputable corporations
  such as Cisco or organizations such as E.U. projects and the OpenFog
  Consortium[The OpenFog Consortium recently merged with the
    Industrial Internet Consortium. Their use case descriptions are
    temporarily offline while being rebranded to IIC documents. In the
    mean time we make these documents available at
    <http://www.fogguru.eu/tmp/OpenFog-Use-Cases.zip>.].

  Economic sectors. We aimed at identifying applications which
  cover a broad range of economic sectors such as transportation,
  healthcare, entertainment, smart cities, supply chain management,
  smart factories, robotics, agriculture, and security.

  No overlap. To keep the list of application short, we avoided
  including multiple applications which resembled each other too
  much. In such cases we kept the most detailed description in the
  list, and discarded the other similar applications.


Tables <ref>–<ref> show the resulting
list of reference applications.

















  
  
  
  
  
  
  
  
  
  
  
  




















  
  
  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  

  
  
  
  
  
  
  

  
  
  
  
  

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  
  
  
  
  

  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  
  
  




The rest of the paper is organized to answer specific
questions about the types of requirements a fog computing system
should fulfill. For each such question, we studied the full list of
applications to build an understanding of the requirements that
different types of applications would have. It is of course up to each
future fog computing systems to decide whether they choose to address
some or all of these requirements.





§ ANALYSIS





 §.§ Why use a fog?



Fog computing was mainly proposed to deliver IoT services (i.e.,
mobility support, context-awareness, geo-distribution and low-latency)
from the edge of the network <cit.>.  By extending cloud
datacenters resources i.e.  compute, storage, and network resources at
the closest vicinity of end users, fog computing also promises to
enhance performance of many applications that require low latency from
IoT devices to their closest fog server, or applications that process
data locally where it is produced <cit.>.

The number of applications running in fog platform is growing. The new
use cases of fog platform are driven by innovative application design
that requires additional platform characteristics which can only be
delivered if the application were deployed next to the end
users <cit.>. 



Therefore, we study all the referred applications and characterize
them based on their reasons for using a fog platform:











  Reduce latency: latency-sensitive applications such as
  augmented reality games require end-to-end latency (including
  network and processing delay) under 10-20 ms <cit.>.  However, the latency between an end user and
  the closest available cloud data center comes in the range of
  20–40 ms (over wired networks) and up to 150 ms (over 4G mobile
  networks) <cit.>. Therefore, such applications
  cannot realistically run in the cloud.  An obvious solution to
  reduce the end-to-end latency is to deploy the server part of these
  applications in fog platforms.

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  Bandwidth optimization: edge devices such as IoT sensors, video
  surveillance camera produce large amount of raw data
  everyday <cit.>.  Sending such enormous
  amount of collected data to the cloud for processing creates huge
  network traffic <cit.>.  For such applications,
  fog computing plays an intermediate role to reduce the network
  traffic. Fog middlewares are deployed in between the end device and
  the cloud to pre-process the raw collected data at the source and
  only the residual outcome are sent to the cloud for further
  processing <cit.>.










  

  



















  Computational offloading: edge devices such as smart phones,
  smart IoT devices have limited processing capacity.  Running
  compute-intensive applications such as face recognition in those
  devices is painfully slow. Offloading some execution of the
  application to the moderate fog servers may improve the performance.
  Offloading could be another way around: for instance, when a cloud
  server is overloaded, server-side of the running applications cloud
  be offloaded to fog servers <cit.>.

























  Privacy and security: privacy and security are main concerns
  for many applications. For example, E-health applications in health
  care management record enormous amount of patient data for further
  study. Usually, those recorded data are sent to the public cloud for
  the long term storage <cit.>.  However, data theft of
  personal medical records is one concerning issue faced by many
  hospitals <cit.>. Private fog mitigates the data privacy
  and security issue by delivering storage capacity on-premise of the
  users or the hospitals <cit.>.



  Service management: a growing number of devices like IoT
  sensors and actuators potentially require powerful computing
  machines to operate and manage the devices such as service
  deployment, fault management, hardware installation and device turn
  on/off etc <cit.>. Fog computing works as a middleware
  to provide computing power which not only enables one the control of
  the devices but also allows to customize the services based on the
  environment <cit.>.


  Monitoring edge devices: monitoring technology has seen
  improvement in hospitals such as monitoring infusion pumps,
  heartbeats, etc.  However, the integration of such devices with
  patients is still challenging which leads to the third-leading cause
  of death each year in the US <cit.>. Fog computing enables to
  remotely host applications that directly communicate with the
  monitoring devices which allow to takes response dynamically based
  on the real-time data <cit.>.


  Energy efficiency: energy consumption by large IoT devices
  remains one open issue in the IoT
  environment <cit.>.  Fog computing enables these
  devices to take decisions intelligently such as switch
  on/off/hibernate that reduces overall energy
  consumption <cit.>.


  Cost saving: traditional cloud charges the rented resources
  based on the usage, also known as a pay-you-go model. However, for
  some applications, a one-time investment cost for acquiring the
  private fog resources is preferable to the total cost of cloud
  instances.


  Content caching: content caching or content delivery network or
  content distribution in fog platform is one way to reduce network
  traffic and improve response time by caching popular content
  locally <cit.>. This practice has been well
  studied, matured, and was able to benefit many
  applications <cit.>.
  Traditionally cloud has been used to deploy content delivery
  network <cit.>. However, with fog computing, the
  contents can be cached with fine granularity based on the user's
  locality and popularity of the content <cit.>.
 

Table <ref> presents a comparison of the surveyed
applications based on the above fog usage. It is not surprising that
most of the applications leverage fog platform to reduce end-to-end
latency and optimizing bandwidth consumption. However one cannot
ignore the other reasons why a fog platform may be used but different
applications.






 §.§ Fog deployment models



We can classify fog models based on the ownership of the fog
infrastructure and underlying resources. There are four
different types of fog models:



  Private fog: A private fog is created, owned, managed and
  operated by some organization, a third party, or some combination of
  them. It may be deployed on or off-premises. The resources of
  private fog are offered for exclusive use by a single organization
  (e.g., business units).


  Public fog: A public fog is created, owned, managed and
  operated by a company, academic institute or government
  organization, or some combination of them.  It is deployed on the
  premises of the fog providers. The resources of public fog are
  offered for open use by the general public.


  Community fog: The community fog is created, managed and
  operated by one or more organizations in the community, also a third
  party, or a combination of them. It may be deployed on or
  off-premises and the resources are offered for exclusive use,
  usually by consumers of a specific community of organizations that
  have shared concerns.


  Hybrid fog: A hybrid fog is a form of fog computing that
  combines the use of public/private/community fog with public/private
  cloud (i.e., hybrid cloud).  It can be useful due to physical
  resource limitations in the fog. Therefore, the platform is extended
  to the hybrid cloud to scale performance. A hybrid cloud is
  scalable, elastic, and resources are available on-demand.


Table <ref> classifies the applications based on the
underlying fog models used to deploy the applications. We found that
nearly half (13 out of 30) of the surveyed applications are deployed
in the private fog and the majority (17 out of 30) in the
hybrid fog. However, none of the applications are deployed in
public fog and community fog. Remarkably the
applications can be further categorized based on their requirements
and functionality provided by the respective fog models. We,
therefore, identified the following main reasons for choosing a
private fog:



  * Privacy and security: many applications that deals with personal
  data such as wearable devices produce a large volume of personal
  data which are too risky to deploy in the open cloud for privacy and
  security concern and, therefore, those applications are usually
  preferred to deploy in a secure fog cloud usually owned by the
  individual or trusted third party.  Similarly, many industries
  prefer to deploy a secure cloud to run automatic robotic application
  due to security reasons.

  * Latency sensitivity and modest resource requirements:
  applications that require moderate resources and low latency are
  deployed in fog platform such as web hosting.

  * Cost-saving: traditional cloud charges rented resources based on
  the usage, also known as a pay-as-you-go model. For some
  applications, the cost is less expensive while deploying the
  application in on-premise, particularly those applications that do
  not need high scalability and maintenance.  For such applications,
  one-time cost for acquiring the private fog resources is cheaper
  than the traditional cloud.


A hybrid fog mainly aims to scale the resources of fog platforms; 
therefore, applications that require an enormous amount of
resources (i.e., computation, storage, etc.).  We further categorized the
applications deployed in hybrid fog based on the following
criteria:



  * Compute intensive applications: applications that require
  relatively high computation such as big data analytics in Swarm
  project 23, face recognition 04 are preferred to deploy
  in hybrid fog.

  * Storage: applications such as 25 that need to store a
  large amount of data for future reference use hybrid fog.



 



 §.§ Types of access networks


Access networks connect the IoT devices to the fog platform, and are
therefore a important basic building blocks for fog platforms. Data
generated from applications need to be processed and acted upon in
terms of milliseconds, therefore, the network architecture should
support ultra-low latency, and large data volumes. There are many
standards and types of access networks that can be deployed on fog
environment. 




Considering the complexity of fog nodes topologies, and due to their
distribution and mobility, wireless connectivity is essential in fog
environment. Wireless connectivity provides flexibility, mobility, and
reachability for levels of hierarchies of fog communication.

As mentioned in the OpenFog Reference Architecture <cit.>,
wireless support at the fog node will depend on variety of parameters:
function and position in the hierarchy, mobility, coverage, range,
throughput and data transfer rates, etc.




Various wireless technologies were classified in
Table <ref>, depending on their frequency,
coverage, data transfer rate, and power consumption:


  * Low Power Wide Area Network (LPWAN) is a protocol for
  resource-constrained devices and networks over long ranges. It
  covers tens of kilometers, and provides low data rate and power
  usage. Agriculture is the perfect use case for using LPWAN
  technology. Some of the protocols based on LPWAN are LoRa and
  SigFox.

  * Cellular networks are suitable for long distance communications
  in IoT applications. However, all mobile network protocols come at a
  high price due to their licensed Radio Frequency, intellectual
  property protection, and high power consumption.  NB-IoT and LTE-M
  standards are aimed at providing low-power, low-cost IoT
  communication options using existing cellular networks, which can be
  categorized as LPWAN technology. The 5th Generation cellular network
  (5G) is starting to get commercialized, and will improve IoT
  communications. It also promises to lower costs, battery
  consumption, and latency.

  * There exists a wide range of devices with Wi-Fi compatibility,
  with IEEE 802.11 being the most popular network protocol for Local
  Area Networking (LAN). Its high power usage, high data transfer
  rate, and medium-range make it a popular option for latency-aware
  fog applications. HaLow (IEEE 802.11ah) and Wi-Fi 6 (IEEE 802.11ax),
  were designed to address the constraints of IoT networks.

  * The traditional frame format of MAC layer protocols was not
  suitable for IoT low power and multi-hub communications. IEEE
  802.15.4 was created with a more efficient frame format that has
  become the most used IoT MAC layer standard. Applications such as
  home automation are suitable to use low data rate, medium range
  Zigbee, 6LoWPAN technologies.

  * Lastly, other short range Personal Area Network (PAN)
  technologies such as Near Field Communication (NFC), Bluetooth Low
  Energy (BLE), and Radio Frequency Identification (RFID) can be used
  for personal IoT devices like wearable health and fitness trackers,
  asset tracking, check-in systems.


Depending on the area that must be covered by the fog platform,
different types of antennas can be proposed. For example, directed
Wi-Fi antennas can be used for Live Video Broadcasting application
04.



Table <ref> illustrates the possible access
network usages for each application. Some applications are shown
multiple times based on their usage of different access network types
on levels of deployment. Also some of the applications have already
been evaluated in real life testbed. For example, Power Consumption
Management application (22) proposed to use Zigbee, Vehicle
Video Processing (23) examined Dedicated Short Range
Communication (DSRC) and LTE, and deployed promising Vehicular Fog
Computing (VFC) architecture.




 §.§ Hardware platforms



The servers which constitute a fog computing platform may be highly
heterogeneous, not only physically but also in terms of resource
capacity such as processing, storage, and network
bandwidth <cit.>.  They are considered
the building blocks of fog infrastructures <cit.>. Unlike
in traditional cloud platforms, fog architectures are composed of
large number of small computing fog nodes or servers which are placed
in strategic locations across a vast geographical area to cover a
large number of users <cit.>.  Since the fog nodes can
be deployed anywhere between the end users and the cloud, the latency
between an user and the nearest fog nodes largely depends on the
location where the fog nodes are
deployed <cit.>.
Depending on the application requirements, application developers have
to choose appropriate fog nodes to improve the QoS of the
applications. We therefore explore different fog nodes used to deploy
the surveyed applications.

Table <ref> compares different characteristics of
potential fog nodes.  We broadly classify the fog nodes into
static and mobile nodes.



  Static nodes are placed in strategic locations. Some examples
  of static nodes are base stations,small-scale datacenters and
  personal laptops, switches, routers, etc. Such devices are
  practically not mobile, therefore need to be placed in a fixed
  location.  Statics nodes can be further categorized based on the
  premise where they are deployed. For example, base stations, network
  resources (switches and routers), small-scale datacenters.


  Mobile nodes are movable, physically small, less resourceful
  and flexible to install and configure.  Some examples of mobile
  nodes are single-board machines <cit.> (RPIs, Pine
  A64+, etc.), drones, vehicles, etc. They may have small computation
  capacity, however the resources can scale horizontally by
  aggregating nodes <cit.> as discussed in
  Section <ref>.





Table <ref> shows the types of fog nodes that are
used to deploy our reference applications. Many of the surveyed
applications may be deployed using one or multiple potential
fog nodes depending on various requirements (i.e. computation
capacity, proximity, etc.). We can however draw a number of
conclusions for different types of applications:



  Applications focusing on close proximity: IoT Applications that
  require compute resources at very close proximity of end-users,
  often take the benefits of single-board machines. Some examples of
  such applications are 08 and 17 collect sensor data from
  the surrounding environment of the fog nods and process locally.
  Due to the small physical size of single-board machines, they could
  easily be deployed and move from one place to another. Therefore
  applications such as 21 use such small machines to trail
  computation where the robot moves.


  Vehicular-based applications: applications which collect data
  from roadside and process locally such as vehicle video processing,
  autonomous driving, traffic congestion management etc. often take
  advantage of in-built computation capacity of the vehicles.


  Drone-based applications: drone-based applications such
  as 25 and 15 take advantage of drones to relocate
  computation resource from one place to another.  The drone is
  equipped with single-board machines that allows to process locally
  and makes communication with other fog nodes.


  Compute-intensive applications: applications such as 04
  and 09 require relatively high computation power, therefore
  they are usually deployed in laptops or small-scale datacenters.







 §.§ Distribution within the fog



Distribution is a key element of fog computing. Locating one node at
the edge of the network is often not sufficient to deliver low
latency, as nodes should be distributed to cover a certain
geographical area. The diffusion of the nodes grants access to nearby
resources for all the users located in a specified area. Fog computing
platforms can provide distribution in two different forms:


  * Hardware distribution: portrayed by the distributed
  nodes.

  * Software distribution: portrayed by the distribution of
  the applications' instances and components.


For hardware distribution, two common solutions are available. The
first is based on having multiple nodes at the same layer in the
architecture, which is referred to as Horizontal Distribution
of the nodes. Meanwhile, if the nodes vary in the size of their
resources (e.g., through some hardware upgrade), then they implement
Vertical Distribution. Typically the nodes that have limited
resources are distributed on the edge, however, nodes with more
resources will be placed in a higher vertical layer to serve a greater
number of users. The end of these vertical layers is the cloud with
unlimited resources.

Applications, in general, can be distributed over the cluster either
using Replication, where more than one instance of the same
application are placed in different nodes, or by splitting the
application into Multi-Component, where each component is
usually a microservice located in a separate node.

Most of the applications intending to run on top of fog try to invest
and benefit from the distribution offered by fog. Some of the
applications that are based on widely-distributed users require a
congruent distribution of the fog nodes. This trend was notable in
IoT-based applications, where for example, in <cit.> the IoT
devices cover the lamps in the street, and the nodes should be placed
according to the placement of these devices. This enforces a
horizontal distribution with replication.

We have noticed that some applications rely on software distribution
and more specifically replication of the same components over
different nodes. This approach was evident in the case of
processing-intensive applications like video stream processing. The
reason behind this replication is lowering the latency by placing the
replica in different nodes, and improving performance by providing
more resources <cit.>.

For applications that require vertical distribution, the fog cluster
is layered in a way that the edge node will collect the data, that
will later be sent to the fog nodes which will process the data and
send only the results to the cloud. This architecture is very
efficient in the case of data streams, such that one does not need to
send all the collected data but rather the output results. This is an
effective way to reduce latency and traffic volume over the Internet
connection <cit.>.

Most of the applications that require no distribution at all, are
mainly applications that will run only on the edge or applications
that will load balance between the edge and the cloud.

Table <ref> summarizes the surveyed applications and the
types of distribution they require.






 §.§ Fog service models




Much like cloud platforms, there are multiple ways by which a fog
computing platform may expose low-level or high-level virtualized
resources to its users. We can classify them in three categories
depending whether they offer infrastructure, platform, and software.
We call them FogIaaS, FogPaaS and FogSaaS to differentiate them from
them cloud-only counterparts.













  FogIaaS (Fog-Infrastructure-as-a-Service) allows users to take
  advantage of different hardware, such as CPU, network, disk, etc.
  without mentioning the hardware running behind it. The users have
  the independent choice to deploy any Operating System and other
  utilities on the provided resources.


  FogPaaS (Fog-Platform-as-a-Service) provides end-users to
  access basic operating software and optional services for running
  applications and software development environment. FogPaaS builds on
  top of FogIaaS and makes development, testing, and deployment of a
  software quick, robust, and cost-effective.


  FogSaaS (Fog-Software-as-a-Service) provides end-users to use
  software applications without installing them on their personal
  computer.  The services are accessed from the web browser remotely
  through a network.
  


Table <ref> classifies the reference applications
based on the service models they rely on. In particular, only one
application uses FogSaaS while the others uses either FogPaaS
(10 out of 30) or FogIaaS (19 out of 30).
 



 




 §.§ Required middlewares



As an increasing number of fog computing applications are being
developed, fog platforms may need to provide greater numbers of
middleware systems (in the form of FogPaaS services) to support easy
application development. We survey the most used types of middlewares
below.




  Data stream processing systems were initially developed by the
  Big Data community <cit.>.  However, multiple authors
  also recognized their interest in a fog computing environment, where
  they have the potential of reducing data transfers between IoT
  devices and the cloud <cit.>. Multiple systems have been
  developed with a number of variations in their provided
  features <cit.>.












































  Function-as-a-Service supports the development of event-driven,
  serverless applications.  It enables one to develop, run, and manage
  functions or pieces of code without provision or management of
  servers.  Fog computing is aiming to leverage the possibility to use
  IoT devices in a serverless architecture, which is a type of
  Function as a Service.  This is essentially some extension of the
  Cloud services to the edge where there are the IoT and mobile
  devices, web browsers, and other computing at the edge.


  Message-oriented middleware (MOM) is a method of communication
  between software components in distributed systems.  It can be
  defined as a software or hardware infrastructure which aims to
  support receiving or sending messages between distributed and
  heterogeneous components.  It aims to reduce the complexity of
  developing applications across multiple operating systems and
  network protocols <cit.>.  Message-oriented
  middleware are being used in fog computing environments to improve
  the scalability of Fog nodes and task
  scheduling <cit.>.


  Web application servers are software frameworks which provide
  an environment where applications can run regardless of what they
  do.  They usually contain comprehensive service layers where each
  one addresses a separate concern.  Common application servers
  running on the cloud can serve up web pages, provide a container
  model or services for applications, adhere to specification
  controlled by industry, distributed requests across multiple
  physical servers, and provide management and/or development tools.
  Fog computing enhances the capabilities of application servers in
  the direction of facilitating management and programming of
  computing, networking, and storage services between data centers and
  end devices.


Table <ref> lists the types of
middleware used by the reference applications. Some applications
employ more than one type of middleware, so they are listed multiple
times. Those applications that did not reference any specific type of
middleware are described as unspecified.







 §.§ Types of processed data



The type of data processed by an application provides an idea about
the required computing capacity for the nodes constituting the Fog
architecture. This information is closely related to the data volume
produced by the applications and the timeliness of its processing,
detailed in Section <ref>.

Fog architectures are often seen as a widely distributed network based
on horizontal scalability <cit.>: if a pool of resource
is insufficient, then a simple solution is to connect more nodes to
the Fog. Nevertheless, the distribution of a single task over several
nodes is rarely mentioned. Nodes are often supposed to be able to host
a full task <cit.> and therefore should have adapted
processing and storage capacity to respect the timeliness of
applications.



Table <ref> classifies the applications according to
their processed data.







A handful of applications process only textual information, and
arguably do not require very large processing capacity. Applications
processing sensor information may be delay-sensitive. Depending on the
type and number of sensors they may require varying amounts of
processing capacity. We however observed that many of the most
demanding applications actually process either static images or even
video. This often requires the usage of specialized devices such as
GPUs to process incoming (live) video streams in real time.
















 §.§ Data volume



The constant growth of data production is due to the emergence of the
use and collection of sensor data and process automation. Data volume
is the most important aspect in the point of view of the Big Data
community, and it is regarding the amount, size, scale of data
produced and stored <cit.>.

We observe that few applications use the fog to store significant
amounts of data. Data storage is usually delegated to cloud computing
platforms whereas the fog platforms are mostly used to process streams
of data which are supposed to be processed or filtered quickly,
possibly before being returned to the
users <cit.>. 

















Table <ref> shows a classification of the volume of data
processed by each application in broad categories ranging from
kilo-bytes to tera-bytes. We observe that a majority of applications
handle relatively modest amounts of data, in the order of kilo-bytes
to mega-bytes. This is because there is a high demand for real-time
services which relies on receiving, processing, and forwarding the
information without keeping any history or data persistence. For
instance, data stream application or message-oriented applications may
require greater storage capability in situations where it is necessary
to maintain fault tolerance and high parallelism using multiple
replicas. We observe similar strategies for applications which handle
larger volumes of camera-generated data (e.g., 04
and 11).

Fog applications which belong to the tera-byte scale usually require
persistent and distributed storage in fog nodes (e.g., 22)
either for keeping history data generated by cameras or personal
files. However, the volume of data they handle largely depends on
their number of users and IoT devices. Applications that use machine
learning or deep learning (e.g., pattern recognition from videos
cameras feeds) may need to frequently retrain their models so storing
large amounts of historical data is important for them. All these
applications usually make use of private for platforms where
sufficient storage capacity may be provisioned for specific
applications.






 §.§ Data velocity and latency sensitivity




One of the fundamental advantages of fog computing is delivering low
user-to-resource latency <cit.>.  The
widely distributed nodes serve this purpose where some of the
resources should be in the vicinity of the end-users. As a result, the
promised low latency of fog is an incentive for applications seeking
ultra-low latencies that may not exceed a couple of milliseconds
regardless of the velocity of the input data.

A very similar notion promoted by the Big Data community is data
velocity, which refers both to the speed at which new input data is
being produced, and to their expected end-to-end processing
latency. In the domain of IoT, the increasing availability of
connected devices and the rapid development of interconnected
applications are leading to continuously increasing rates of input
data that must be processed in a timely fashion <cit.>.









We classify the reference applications according to the two dimensions
of data velocity:


  Data production speed: depending on the applications, the input
  data may be produced in the order of kilobytes per second or less,
  megabytes per second, or more.

  Expected response latency: depending on the application, the
  results may be expected within couple of milliseconds, hundreds of
  milliseconds, seconds, or possibly more.


Table <ref> classifies the reference applications
according to these two metrics. We can observe that most of the input
data production of the applications are relatively low, in the order
of MBps or even kBps. Such data production rates may initially seem
easy to handle, however, most of the applications require a very quick
response for the generated data. As a result, an increased data
production rate could be challenging for any fog computing platform.

Throughout the reviewed applications, we have noticed certain
trends. While some IoT-based applications such as 17 and
20 require no latency restrictions, a significant number of the
applications mention low latency as a vital component for proper
functioning. However, the exact meaning of “low latency” varies a
lot depending on the applications. Some applications such as 06
and 29 require extremely low latency under 5 ms, whereas others
such as 08 and 09 can operate with much softer delivery
time constraints. The applications that require ultra-low latencies
can be classified in two categories:



  Real-Time Decision Making: For these applications such as
  06, 11 and 12, ultra-low latency is a matter of
  human safety. For example, a set of autonomous vehicles calculating
  their trajectory in a fog platform require very fast decisions to
  avoid crashes.

  High-Quality User Experience: Applications falling in this
  category often belong to the entertainment sector for gaming or
  video streaming (02, 29, 30). In such
  applications, excessive latencies will not cost human lives but may
  seriously affect the users' experience.


Data velocity requirements are an important driver for the design of
any large-scale fog computing platform which must be able to process
input data very close to the location where they have been generated,
and to forward only pre-processed data further to other fog or
cloud-hosted resources.




 §.§ Multiple data providers



A number of fog applications need to integrate data which originate
from multiple independent data providers. For instance, 06
provides item deliveries through the usage of drone vehicles. This
application may need to know the current location of the recipient as
well as other crucial parts of information, such as weather conditions
or energy-efficient routes. These parameters help the decision-making
process of the application and are usually not available locally
altogether, hence the need to access them from other providers. These
data have different owners and are provided by different companies
with different benefits, possibly with no established trust relation
between them. As external sources are under the control of different
providers, often under different security protocols (e.g., different
keys and algorithms), fog applications may need to deal with different
security mechanisms defined by various data providers. The number of
providers dictates the way the fog application may access and consume
data since the providers employ various data security protocols and
mechanisms, which leads to the application needing to address all
intricacies posed by the different protocols.

Table <ref> classifies our reference applications
according to their data providers. Future fog computing platforms may
need to provide specific mechanisms for the many applications which
rely on multiple independent data providers.

















 §.§ Privacy sensitivity



In today's societies, data is acting as fuel for most of the services
that we use <cit.>. On the one hand, users are requested to
provide data about themselves in order to receive services. On the
other hand, many citizens are concerned about the usage that may be
made of these data, and prefer not to reveal too much about their
personal life. For example a number of mobile health applications that
receive every day physical activity of their users and provide advice
for healthier life styles. Although the users are interested in such
advices, they do not want their everyday physical activity to be
accessible to their neighbors or colleagues. The European Commission
published the General Data Protection Regulation (GDPR) to address
concerns about the privacy of the citizens <cit.>.

Privacy can be defined in many different ways: legal, technical,
societal, etc. In this article we define data privacy as the rules and
acts that can be taken to share personal data to only the legitimate,
intended recipient. Privacy, as a legal term, refers to individuals'
rights to keep their information private and not be accessed by
non-authorized parties.

Because fog applications are located in the immediate vicinity of end
users, they often have access to private user data. Fog computing
therefore inherits all the privacy issues that already existed in IoT
and Cloud computing. Additionally, in Fog computing, we also deal with
data which normally belong to a user, which are in close proximity to
a fog node. For example, a user's location may be inferred from the
location of her closest fog node, which exacerbates the problem of
user privacy.

We categorize data privacy into the following three levels:


  Public: the data may be accessed by anyone. For example, street
  names in a city are public information.

  Conditional: the data may be accessed by some depending on a
  number of conditions. For example, the list of streets in a city
  with higher crime rates may be private or public depending on the
  city's policy.

  Private: the data may be accessed only by a restricted number
  of entities. For example, individual health-related data is usually
  private.





Table <ref> classifies the reference applications with
respect to the privacy level of the data they manipulate.  It is clear
that many applications manipulate private data, which creates
important issues that future fog platforms will have to deal with.




 §.§ Security sensitivity



An important concern in any large-scale computing infrastructure is
the security of data.  As Fog computing has access to IoT data whether
in the form of data sensed from devices or commands (data) sent from
Cloud to the device, it is important to provide guarantees with
regards to data's integrity and confidentiality. Integrity means that
any sent data should be received intact at its
destination. Confidentiality means that data should only be accessible
to the data source and the legitimate, intended destination.




As an example for the need of confidentiality, health-related data
sent from an IoT device to a fog application may have high value for
unauthorized organizations, and is therefore at risk for potential
attacks. One such attack happened in 2005 to Anthem where nearly 80
millions users' health records were stolen by an
attacker <cit.>.

Existing solutions utilize encryption as means to provide data
confidentiality. However, cryptography is a compute-intensive process
so not all IoT devices have sufficient processing capacity on
board. In Fog computing we are dealing with heterogeneous IoT devices
with different cryptographic abilities, thus a fog computing platform
may also need to consider the importance of confidentiality as the
other important vector of security in the Fog/IoT space.

In order to avoid data breach, security mechanisms may utilize
context-aware security process where the system alternates between
different security levels according to its own surroundings. As an
example, a node may switch to more powerful encryption schemes because
nodes in proximity to the current one have been marked as infected by
malware.

Table <ref> categorizes the requirements of our reference
applications with respect to data integrity and
confidentiality. Obviously, all applications would prefer operating in
a safe and secure environment. We only list here the applications
where integrity or confidentiality breaches would cause major issues
for their users.








 §.§ Workload characteristics
 

Fog computing platforms are necessarily widely distributed to be
located close to their end users. As such, they experience many
challenges in running highly distributed and large-scale fog
applications as both the fog computing infrastructure itself. To
guarantee the best possible performance and high quality of service,
fog computing platforms need to adapt to dynamic workloads and also be
able to identify and remedy misbehaving workloads.

We can characterize the workload produced by our reference
applications in two general categories and few sub-categories based on
the characteristics of their workloads:



  Stable: the workload is almost static.

  Dynamic: the workload varies according to some criterion:
  
  
  * Location: the workload varies according to the location of fog node.
  
  * Time: the workload varies as a function of time.
  
  * User: the workload varies according to the load generated by users.
  




Table <ref> classifies the reference applications
according to their type of workload. We see that the workloads for
most of the fog applications are stable. In these scenarios, sensors
collect data periodically and send them to fog application for
processing. For example, 04 uses surveillance cameras to take
pictures at periodic intervals and sends them to the fog for
analysis. These types of applications are present in different sectors
such as transportation, health, entertainment, smart cities, smart
factories, smart buildings, and smart grid.

Seven out of the surveyed applications have dynamic workloads among
which three are dynamic with respect to location, one is dynamic with
respect to time and the rest three are dynamic with respect to
users. Applications that are dynamic with respect to time and user are
the same as typically found in web services running in the
cloud. However, applications that are dynamic with location are
specific to fog environments. When the location changes, a number of
surrounding sensors may change as well as in 05. In 09 the
number of self-adaptive added stations may change. In 11 the
number of surrounding fog nodes with which the fog node communicates
may changes. Finally, 13 collects real-time transport demand in
a mobile way which makes the workload change.

We believe that the awareness of workload characteristics of fog
applications helps in the design of effective and efficient management
and operation of fog computing platforms. Especially for fog
applications with dynamic workloads, it is necessary for the fog
infrastructures and applications to be designed and deployed in a
scalable manner. Meanwhile, fog management platforms need to
incorporate intelligent application placement, dynamic resource
allocation mechanisms and automated operation systems to ensure
acceptable QoS is guaranteed.





 §.§ Implementation maturity


The reference applications used in this article widely differ in the
level of maturity of their implementation.  We therefore classify them
in four main categories:


  * Conceptualization

  * Simulation

  * Prototyping

  * Production






Table <ref> classifies applications according to their
implementation maturity. Interestingly, no application has already
progressed to a “production” level of maturity. This shows that the
fog computing technologies and applications still have a long way to
go before they become mainstream. In fact, only 13 out of 30
applications have been developed at all. Three are being simulated and
analyzed with data set or simulation platform, whereas 10 have
actually been prototyped and tested by setting up fog platform or
emulating fog node with similar devices such as cloudlet, laptop, and
gateways. 






















§ CONCLUSION


Fog computing application are extremely diverse, and they logically
impose a very varied types of requirements on the fog computing
platforms designed to support them. Although no current
general-purpose fog platform can pretend addressing all these
requirements, this study aims at helping future platform designers
make informed choices about the features they may or may not support,
and the types of applications that may benefit from them.






















 


















 





§ ACKNOWLEDGEMENTS


This work is part of the FogGuru project which has received
  funding from the European Union's Horizon 2020 research and
  innovation programme under the Marie Skłodowska-Curie grant
  agreement No 765452. The information and views set out in this
  publication are those of the author(s) and do not necessarily
  reflect the official opinion of the European Union. Neither the
  European Union institutions and bodies nor any person acting on
  their behalf may be held responsible for the use which may be made
  of the information contained therein.






10

url@samestyle








Yousefpour2019
A. Yousefpour, C. Fung, T. Nguyen, K. Kadiyala, F. Jalali, A. Niakanlahiji,
  J. Kong, and J. P. Jue, “All one needs to know about fog computing and
  related edge computing paradigms: A complete survey,” Journal of
  Systems Architecture, 2019.

bonomi2012fog
F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and its role in
  the internet of things,” in Proc. workshop on Mobile computing,
  2012.

vaquero2014finding
L. Vaquero, “Finding your way in the fog: Towards a comprehensive definition
  of fog computing,” ACM SIGCOMM Computer Communication Review,
  vol. 44, no. 5, 2014.

openfog-refarch
OpenFog Consortium, “OpenFog reference architecture for fog computing,”
  2017, <https://www.openfogconsortium.org/ra/>.

IEEE-def
IEEE Standards Association, “IEEE 1934-2018 – IEEE standard for
  adoption of OpenFog reference architecture for fog computing,” 2018,
  <https://standards.ieee.org/standard/1934-2018.html>.

chen2014decentralized
X. Chen, “Decentralized computation offloading game for mobile cloud
  computing,” IEEE Transactions on Parallel and Distributed Systems,
  vol. 26, no. 4, 2014.

atlam2018fog
H. Atlam, R. Walters, and G. Wills, “Fog computing and the Internet of
  Things: a review,” Big Data and Cognitive Computing, vol. 2, no. 2,
  2018.

2017-redowan
R. Mahmud, R. Kotagiri, and R. Buyya, Fog Computing: A Taxonomy, Survey
  and Future Directions.1em plus 0.5em minus 0.4emSpringer,
  2018.

DBLP:journals/corr/abs-1807-00976
R. K. Naha, S. K. Garg, D. Georgekopolous, P. P. Jayaraman, L. Gao, Y. Xiang,
  and R. Ranjan, “Fog computing: Survey of trends, architectures,
  requirements, and research directions,” CoRR, vol. abs/1807.00976,
  2018. [Online]. Available: <http://arxiv.org/abs/1807.00976>


app01
W. Hu, Z. Feng, Z. Chen, J. Harkes, P. Pillai, and M. Satyanarayanan, “Live
  synthesis of vehicle-sourced data over 4G LTE,” in Proc. ACM
  MSWiM, 2017.

app02
K. Ha, Z. Chen, W. Hu, W. Richter, P. Pillai, and M. Satyanarayanan, “Towards
  wearable cognitive assistance,” in Proc. MobiSys, 2014.

app03
OpenFog Consortium, “Out of the fog: Use case scenarios (live video
  broadcasting),” 2018, <http://www.fogguru.eu/tmp/OpenFog-Use-Cases.zip>.

app04
——, “Visual security and surveillance scenario (3.2),” 2017,
  <https://www.iiconsortium.org/pdf/OpenFog_Reference_Architecture_2_09_17.pdf>.

app05
——, “Transportation scenario: Smart cars and traffic control (3.1),”
  2017,
  <https://www.iiconsortium.org/pdf/OpenFog_Reference_Architecture_2_09_17.pdf>.

app06
——, “Out of the fog: Use case scenarios (high-scale drone package
  delivery),” 2018, <http://www.fogguru.eu/tmp/OpenFog-Use-Cases.zip>.

app07
——, “Process manufacturing – beverage industry,” 2018,
  <http://www.fogguru.eu/tmp/OpenFog-Use-Cases.zip>.

app08
——, “Smart cities scenario (3.3),” 2017,
  <https://www.iiconsortium.org/pdf/OpenFog_Reference_Architecture_2_09_17.pdf>.

app09
——, “Real-time subsurface imaging,” 2018,
  <http://www.fogguru.eu/tmp/OpenFog-Use-Cases.zip>.

app10
——, “Patient monitoring,” 2018,
  <http://www.fogguru.eu/tmp/OpenFog-Use-Cases.zip>.

app11
——, “Autonomous driving,” 2018,
  <http://www.fogguru.eu/tmp/OpenFog-Use-Cases.zip>.

app12
S. Dey and A. Mukherjee, “Robotic SLAM: A review from fog computing and
  mobile edge computing perspective,” in Proc. MOBIQUITOUS, 2016.

app13
Cisco, “Enabling MaaS through a distributed IoT data fabric, fog
  computing and network protocols,” White paper, 2018,
  <https://alln-extcloud-storage.cisco.com/ciscoblogs/5c0a6ea91edbb.pdf>.

app14
B. Thomas, B. Close, J. Donoghue, J. Squires, P. D. Bondi, M. Morris, and
  W. Piekarski, “ARQuake: An outdoor/indoor augmented reality first person
  application,” in Proc. International Symposium on Wearable
  Computers, 2000.

app15
P. Hu, S. Dhelim, H. Ning, and T. Qiu, “Survey on fog computing: architecture,
  key technologies, applications and open issues,” Journal of Network
  and Computer Applications, vol. 98, Nov. 2017.

app16
S. Kyriazakos, M. Mihaylov, B. Anggorojati, A. Mihovska, R. Craciunescu,
  O. Fratu, and R. Prasad, “eWALL: an intelligent caring home environment
  offering personalized context-aware applications based on advanced sensing,”
  Wireless Personal Communications, vol. 87, no. 3, 2016.

app17
G. Jia et al., “SSL: Smart street lamp based on fog computing for
  smarter cities,” in IEEE Transactions on Industrial Informatics,
  vol. 14, no. 11, 2018.

app18
Y.-D. Chen, M. Z. Azhari, and J.-S. Leu, “Design and implementation of a power
  consumption management system for smart home over fog-cloud computing,” in
  Proc. International Conference on Intelligent Green Building and Smart
  Grid, 2018.

app19
C. Zhu et al., “Vehicular fog computing for video crowdsourcing:
  Applications, feasibility, and challenges,” in IEEE Communications
  Magazine, vol. 56, no. 10, Oct. 2018.

app20
R. Rajesh and V. Shijimol, “Vehicular pollution monitoring and controlling
  using fog computing and clustering algorithm,” in International
  Journal of New Innovations in Engineering and Technology, Mar. 2016.

app21
R. K. Barik, R. Priyadarshini, H. Dubey, V. Kumar, and K. Mankodiya,
  “FogLearn: Leveraging fog-based machine learning for smart system big data
  analytics,” International Journal of Fog Computing, vol. 1, no. 1,
  2018.

app22
H. A. A. Hamid, S. M. M. Rahman, M. S. Hossain, hmad Almogren, and A. Alamri,
  “A security model for preserving the privacy of medical big data in a
  healthcare cloud using a fog computing facility with pairing-based
  cryptography,” IEEE Access, vol. 5, 2017.

app23
SWAMP Project, “Smart water management platform,” 2018,
  <swamp-project.org/communication/WRNP2018_lamina_SWAMP_EN.pdf>.

app24
C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos, “Sensing as a
  service model for smart cities supported by Internet of Things,”
  Transactions on Emerging Telecommunications Technologies, 2013,
  <https://doi.org/10.1002/ett.2704>.

app25
N. Chen, Y. Chen, Y. You, H. Ling, P. Liang, and R. Zimmermann, “Dynamic urban
  surveillance video stream processing using fog computing,” in Proc.  BigMM, 2016.

app26
D. Deyannis, R. Tsirbas, G. Vasiliadis, R. Montella, S. Kosta, and
  S. Ioannidis, “Enabling GPU-assisted antivirus protection on android
  devices through edge offloading,” in Proc. EdgeSys, 2018.

app27
U. Drolia, K. Guo, J. Tan, R. Gandhi, and P. Narasimhan, “Cachier:
  Edge-caching for recognition applications,” in Proc. ICDCS, 2017.

app28
P. Hao, Y. Bai, X. Zhang, and Y. Zhang, “Edgecourier: An edge-hosted personal
  service for low-bandwidth document synchronization in mobile cloud storage
  services,” in Proc. ACM/IEEE SEC, 2017.

app29
Y. Lin and H. Shen, “CloudFog: Leveraging fog to extend cloud gaming for
  thin-client MMOG with high quality of service,” IEEE Transactions on
  Parallel and Distributed Systems, vol. 28, no. 2, 2017.

app30
G. Ma, Z. Wang, M. Zhang, J. Ye, M. Chen, and W. Zhu, “Understanding
  performance of edge content caching for mobile video streaming,” IEEE
  Journal on Selected Areas in Communications, vol. 35, no. 5, 2017.

hong2013mobile
K. Hong, D. Lillethun, U. Ramachandran, B. Ottenwälder, and B. Koldehofe,
  “Mobile fog: A programming model for large-scale applications on the
  internet of things,” in Proc. workshop on Mobile cloud computing,
  2013.

latency-abrash
M. Abrash, “Latency – the sine qua non of AR and VR,” 2012,
  <http://blogs.valvesoftware.com/abrash/latency-the-sine-qua-non-of-ar-and-vr/>.

latency-oculusRift
OculusRift, “Delivers some home truths on latency,”
  <https://oculusrift-blog.com/john-carmacks-message-of-latency/682/>.

CLAudit-project
CLAudit Project, “Planetary-scale cloud latency auditing platform,” 2016,
  <http://bit.do/bS4js>.

iot-data
Cisco Inc., “Internet of things (iot) data continues to explode
  exponentially. who is using that data and how?” 2019,
  <https://blogs.cisco.com/datacenter/internet-of-things-iot-data-continues-to-explode-exponentially-who-is-using-that-data-and-how>.

video-surveillance
IHS Inc, “Big, big, big data: The rise of HD video surveillance cameras
  spurs information explosion,” 2013,
  <https://news.ihsmarkit.com/press-release/design-supply-chain-media/big-big-big-data-rise-hd-video-surveillance-cameras-spurs-in>.

shahid:hal-01994156
M. R. Shahid, G. Blanc, Z. Zhang, and H. Debar, “IoT devices recognition
  through network traffic analysis,” in Proc. Big Data, Dec. 2018.

oueis2015fog
J. Oueis, E. C. Strinati, and S. Barbarossa, “The fog balancing: Load
  distribution for small cell cloud computing,” in Proc. VTC, 2015.

basu2012fusion
S. Basu, A. H. Karp, J. Li, J. Pruyne, J. Rolia, S. Singhal, J. Suermondt, and
  R. Swaminathan, “Fusion: managing healthcare records at cloud scale,”
  Computer, vol. 45, no. 11, 2012.

data-theft
Trend Micro, “Healthcare under attack: What happens to stolen medical
  records?” 2016,
  <https://www.trendmicro.com/vinfo/pl/security/news/cyber-attacks/healthcare-under-attack-stolen-medical-records>.

stolfo2012fog
S. J. Stolfo, M. B. Salem, and A. D. Keromytis, “Fog computing: Mitigating
  insider data theft attacks in the cloud,” in Proc. IEEE symposium on
  security and privacy workshops, 2012.

biswas2014iot
A. R. Biswas and R. Giaffreda, “IoT and cloud convergence: Opportunities and
  challenges,” in Proc. IEEE World Forum on Internet of Things, 2014.

taneja2017resource
M. Taneja and A. Davy, “Resource aware placement of IoT application modules
  in fog-cloud computing paradigm,” in Proc. Symposium on Integrated
  Network and Service Management, 2017.

patient-monitoring
OpenFog Consortium, “Patient monitoring,” 2019,
  <https://www.openfogconsortium.org/wp-content/uploads/Patient-Monitoring-Short.pdf>.

arshad2017green
R. Arshad, S. Zahoor, M. A. Shah, A. Wahid, and H. Yu, “Green iot: An
  investigation on energy saving practices for 2020 and beyond,” IEEE
  Access, vol. 5, 2017.

jalali2016interconnecting
F. Jalali, A. Vishwanath, J. De Hoog, and F. Suits, “Interconnecting fog
  computing and microgrids for greening IoT,” in Proc. ISGT-Asia,
  2016.

buyya2008content
R. Buyya, M. Pathan, and A. Vakali, Content delivery networks.1em
  plus 0.5em minus 0.4emSpringer, 2008, vol. 9.

pathan2007taxonomy
A.-M. K. Pathan and R. Buyya, “A taxonomy and survey of content delivery
  networks,” Grid Computing and Distributed Systems Laboratory,
  University of Melbourne, Technical Report, vol. 4, 2007.

choi2011survey
J. Choi, J. Han, E. Cho, T. Kwon, and Y. Choi, “A survey on content-oriented
  networking for efficient content delivery,” IEEE Communications
  Magazine, vol. 49, no. 3, 2011.

papagianni2013cloud
C. Papagianni, A. Leivadeas, and S. Papavassiliou, “A cloud-oriented content
  delivery network paradigm: Modeling and assessment,” IEEE Transactions
  on Dependable and Secure Computing, vol. 10, no. 5, 2013.

wang2017social
X. Wang, S. Leng, and K. Yang, “Social-aware edge caching in fog radio access
  networks,” IEEE Access, vol. 5, 2017.

openfogRA
IEEE Standards Association, “IEEE standard for adoption of OpenFog
  reference architecture for fog computing,” 2018,
  <https://standards.ieee.org/standard/1934-2018.html>.

margelis2015low
G. Margelis, R. Piechocki, D. Kaleshi, and P. Thomas, “Low throughput networks
  for the IoT: Lessons learned from industrial implementations,” in
  Proc. WF-IoT, 2015.

centenaro2016long
M. Centenaro, L. Vangelista, A. Zanella, and M. Zorzi, “Long-range
  communications in unlicensed bands: The rising stars in the IoT and smart
  city scenarios,” IEEE Wireless Communications, vol. 23, no. 5, 2016.

sinha2017survey
R. S. Sinha, Y. Wei, and S.-H. Hwang, “A survey on LPWA technology: LoRa
  and NB-IoT,” ICT Express, vol. 3, no. 1, 2017.

rg4GLTE
G. S. Nitesh and A. Kakkar, “Generations of mobile communication,”
  International Journal of Advanced Research in Computer Science and
  Software Engineering, 2016.

FGr16band
3GPP, “Early progress on rel-16 bands for 5G,” 2019,
  <https://www.3gpp.org/news-events/2025-early-progress-on-rel-16-bands-for-5g>.

5Gtest
E. Kauppalehti, “Real world 4G LTE vs. 5G test benchmark: 14x
  bandwidth),” 2018,
  <https://react-etc.net/entry/real-world-4g-lte-vs-5g-test-benchmark-14x-bandwidth>.

abdelrahman2015comparison
R. B. M. Abdelrahman, A. B. A. Mustafa, and A. A. Osman, “A comparison between
  IEEE 802.11 n and ac standards,” 2015.

ahmed2016comparison
N. Ahmed, H. Rahman, and M. I. Hussain, “A comparison of 802.11 ah and 802.15.
  4 for IoT,” ICT Express, vol. 2, no. 3, 2016.

cisco802.11ax
Cisco, “IEEE 802.11ax the sixth generation of Wi-Fi,” 2018,
  <https://www.cisco.com/c/dam/en/us/products/collateral/wireless/white-paper-c11-740788.pdf>.

al2017internet
S. Al-Sarawi, M. Anbar, K. Alieyan, and M. Alzubaidi, “Internet of things
  (iot) communication protocols,” in Proc. ICIT, 2017.

marin2017we
E. Marín-Tordera, X. Masip-Bruin, J. García-Almiñana, A. Jukan,
  G.-J. Ren, and J. Zhu, “Do we all really know what a fog node is? current
  trends towards an open definition,” Computer Communications, vol.
  109, 2017.

adhatarao2017fogg
S. S. Adhatarao, M. Arumaithurai, and X. Fu, “FOGG: A fog computing based
  gateway to integrate sensor networks to internet,” in Proc. ITC,
  vol. 2, 2017.

iorga2018fog
M. Iorga, L. Feldman, R. Barton, M. Martin, N. Goren, and C. Mahmoudi, “Fog
  computing conceptual model, recommendations of the national institute of
  standards and technology,” NIST Special Publication, 2018.

ahmed2018docker
A. Ahmed and G. Pierre, “Docker container deployment in fog computing
  infrastructures,” in Proc. IEEE EDGE, 2018.

Peterson:2019:DNE:3336937.3336942
L. Peterson, T. Anderson, S. Katti, N. McKeown, G. Parulkar, J. Rexford,
  M. Satyanarayanan, O. Sunay, and A. Vahdat, “Democratizing the network
  edge,” SIGCOMM Comput. Commun. Rev., vol. 49, no. 2, May 2019.

fahs2019proximity
A. Fahs and G. Pierre, “Proximity-aware traffic routing in distributed fog
  computing platforms,” in Proc. IEEE/ACM CCGrid, 2019.

single-board
Wikipedia, “Single board computer,” 2019,
  <https://en.wikipedia.org/wiki/Single-board_computer>.

abrahamsson2013affordable
P. Abrahamsson, S. Helmer, N. Phaphoom, L. Nicolodi, N. Preda, L. Miori,
  M. Angriman, J. Rikkilä, X. Wang, K. Hamily et al., “Affordable
  and energy-efficient cloud computing clusters: The Bolzano Raspberry Pi
  cloud cluster experiment,” in Proc. Intl. Conference on Cloud
  Computing Technology and Science, 2013.

Carbone2017
P. Carbone, G. E. Gévay, G. Hermann, A. Katsifodimos, J. Soto, V. Markl,
  and S. Haridi, Large-Scale Data Stream Processing Systems.1em
  plus 0.5em minus 0.4emSpringer, 2017.

lee2017data
H. Lee, J. Oh, K. Kim, and H. Yeon, “A data streaming performance evaluation
  using resource constrained edge device,” in Proc. ICTC, 2017.

To:2018:SSM:3296598.3296611
Q.-C. To, J. Soto, and V. Markl, “A survey of state management in big data
  processing systems,” The VLDB Journal, vol. 27, no. 6, Dec. 2018.

curry2004message
E. Curry, “Message-oriented middleware,” Middleware for
  communications, 2004.

DBLP:journals/corr/GuptaNCG16
H. Gupta, S. B. Nath, S. Chakraborty, and S. K. Ghosh, “SDFog: a software
  defined computing architecture for QoS aware service orchestration over
  edge devices,” CoRR, vol. abs/1609.01190, 2016. [Online]. Available:
  <http://arxiv.org/abs/1609.01190>


ISHWARAPPA2015319
Ishwarappa and J. Anuradha, “A brief introduction on big data 5Vs
  characteristics and Hadoop technology,” Procedia Computer Science,
  vol. 48, 2015.

Gandomi2015
A. Gandomi and M. Haider, “Beyond the hype: Big data concepts, methods, and
  analytics,” International Journal of Information Management, vol. 35,
  no. 2, 2015.

economist
Economist, “Data is giving rise to a new economy,” 2017,
  <https://www.economist.com/briefing/2017/05/06/data-is-giving-rise-to-a-new-economy>.

gdpr
Council of European Union, “Council regulation (EU) no 269/2014,” 2014,
  <https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L:2016:119:FULL   from=EL>.

treacherous12
Cloud Security Alliance, “The treacherous 12 – top threats to cloud
  computing + industry insights,” 2017,
  <https://downloads.cloudsecurityalliance.org/assets/research/top-threats/treacherous-12-top-threats.pdf>.






