Journal of Ambient Intelligence and Humanized Computing

https://doi.org/10.1007/s12652-018-0785-4

ORIGINAL RESEARCH

A methodology for deployment of IoT application in fog

Salvatore Venticinque1 · Alba Amato1 

Received: 4 January 2018 / Accepted: 30 March 2018

© Springer-Verlag GmbH Germany, part of Springer Nature 2018

Abstract
The foreseen increase of IoT connected to the Internet is worrying the ICT community because of its impact on network
Infrastructure when the number of requesters become larger and larger. Moreover also reliability of network connection and
real-time constraints can affect the effectiveness of the Cloud Computing paradigm for developing IoT solutions. The neces-
sity of an intermediate layer in the whole IoT architecture that works as a middle ground between the local physical memories
and Cloud is proposed by the Fog paradigm. In this paper we define and use a methodology that supports the developer to
address the Fog Service Placement Problem, which consists of finding the optimal mapping between IoT applications and
computational resources. We exploited and extended a Fog Application model from the related work to apply the proposed
methodology in order to investigate the optimal deployment of IoT application. The case study is an IoT application in the
Smart Energy domain. In particular, we extended a software platform, which was developed, and released open source by
the CoSSMic European project, with advanced functionalities. The new functionalities provide capabilities for automatic
learning of energy profiles and lighten the platform utilization by users, but they introduce new requirements, also in terms of
computational resources. Experimental results are presented to demonstrate the usage and the effectiveness of the proposed
methodology at deployment stage.

Keywords  Cloud computing · Fog computing · Smart grid · Internet of things

1 Introduction consequence of the onset of the Internet of Things (IoT)

Fog Computing is a new architecture for the internet of
things, with an intermediate layer between local and Cloud.
In Cloud data have been moved on large servers remotely,
away and accessible via the Internet. But the Cloud model
is not perfect. Above all it is designed to hold the data but
not to react in real time. And the real time is the key for
the internet of things: without this readiness we could not
run the cars that drive themselves, smart cities, and so
on. So it is necessary an intermediate level in the whole
architecture. A middle ground between the local physical
memories and Cloud, where small data centers work at local
level and facilitate the flow and data management. This dis-
tributed approach is becoming increasingly important as a
* Alba Amato
alba.amato@unicampania.it
Salvatore Venticinque
salvatore.venticinque@unicampania.it
1
Università degli studi della Campania Luigi Vanvitelli, via
Roma 29, Aversa, Italy
and the huge number of devices connected to it that by a
few years will become about 50 billion Evans (2011). The
transmission of all these data to the Cloud may be inefficient
as it would require high computing power and bandwidth,
increasing the latencies and consequently adversely affecting
the performance of the entire network.
While Cloud Computing is based on large data center
away from the user, the Fog promises to bring more process-
ing power in the network edge in particular on the devices
themselves or on the local gateway so reducing the amount
of data to be transmitted to the Cloud for processing, analy-
sis and archiving.
Fog Computing is a highly virtualized platform that pro-
vides compute, storage, and networking services between
end devices and traditional Cloud Computing Data Centers,
typically, but not exclusively located at the edge of network
Bonomi et al. (2012). The Fog extends the Cloud to be closer
to things that produce and act on IoT data. These devices,
called fog nodes, can be deployed anywhere with a network
connection: on a factory floor, on top of a power pole, along-
side a railway track, in a vehicle, or on an oil rig. Any device

13
Vol.:(0123456789)

with computing, storage, and network connectivity can be a
fog node. Examples include industrial controllers, switches,
routers, embedded servers, and video surveillance cameras
Evans (2015).
By acting at the peripheral level, that is, on the Edge of
the network, it is possible to manage vast amounts of data
without necessarily passing from the Cloud, with two unde-
niable advantages: on the one hand, it reduces the required
bandwidth needed to reach the Cloud or the date corporate
center, and on the other one can assume an increase in the
level of security, because the infrastructure may be more
controllable. In fact processing does not take place on the
Cloud, but on local smart structures, capable of providing its
own limited computational power to perform simple tasks,
however, designed to allow the sending and processing in
the Cloud only critical and useful data. In this way, they
decrease latency and saves bandwidth.
This paper addresses the Fog Service Placement Prob-
lem (FSPP), that aims to determine an optimal mapping
between IoT applications and computational resources
with the objective of optimizing the fog landscape utiliza-
tion while satisfying QoS requirements of applications. In
the FSPP, we consider a methodology to design the best
deployment configuration in the context of smart energy
domain. To account for QoS requirements of applications,
deadlines and throughput of application must be preserved.
The propose methodology allows to estimate an upper bound
(i.e., worst-case estimation) of the response time of relevant
transactions, which guides the design of test scenarios to be
executed on a real testbed.
The main contributions made in this work are briefly
described as follows:
a) a new methodology to address the Fog Service Place-
ment Problem has been defined;
b) a Fog Application model from the related work has been
extended and used to apply the proposed methodology;
c) an IoT application from the Smart Energy domain has
been chosen as real case study to demonstrated the effec-
tiveness of the methodology;
d) new advanced functionalities have been developed to
extend a peer to peer platform that implemented the cho-
sen case study in the CoSSMic European project;
e) three different deployment solutions of the platform have
been investigated using the proposed methodology dem-
onstrating the effectiveness of the Fog computing para-
digm;
f) experimental results have been described and discussed
to validate the methodology and to estimate the process-
ing capability of the extended CoSSMic platform.
The remaining materials are organized in this fashion.
In Sect.  2 introduce advance and limitations of Cloud
13
S. Venticinque, A. Amato
computing for IoT applications. Section 3 discusses improve-
ment of Fog to Cloud. In Sect. 4 the Fog Application model
and the metodology to address the Fog Service Placement
Problem are described. Section 4 presents the case study.
The application of the proposed methodology and experi-
mental results are described in Sect. 5. Section 6 reviews
the related work providing an overview of works related
to Fog Computing in Smart Grid. Finally conclusions are
drawn in Sect. 7.
2 Cloud computing for IoT applications
and smart grids
The main strengths introduced by the Cloud Computing in
IoT sector are the high quality and fast services at the low-
est cost to the user. The limited autonomy, due to a small
capacity of batteries, creates an upper limit with regard to
the hardware components of the device itself. As the vast
majority of IoT devices has significantly limited resources
compared to the Cloud platforms, Cloud is considered an
essential model to allow mobile customers to perform bur-
densome operations.
Nevertheless, from the point of view of the Internet of
Things, the real limitation of Cloud Computing actually
stems from the type of network for which it was designed
a decade ago. Given the inevitable convergence of Mobile
and Cloud Computing, the focus shifts to the actual condi-
tions of utilization of these models, which are often placed
in a hostile operating environment. The additional resource
shortage of IoT devices, compared to current smartphones
and tablets, is due to their spread even in very specialized
domains where they often need a miniaturization of the
components which does not allow high performance. For
the whole category of objects connected wearable, for sen-
sors, actuators and small gateway IoT, the limited available
resources force users to move a quantity of data, and related
computations, on the Cloud; with a frequency and quantity
greater than in the case of mid range devices such as tablets,
smartphones and laptops.
Internet of Things (IoT) needs to operate on a fast net-
work topologies that provides end-to-end connection and
real-time responses. For instance the frequent disconnec-
tions and reconnections by the devices, or notifications of
a disaster or an imminent collapse of the system. In many
cases, decisions must be taken in a short time and it is nec-
essary to be able to rely on a reliable connection between
the customer and the corresponding servant who performs
complex tasks. In many situations, especially dictated by
the overload of communications in multi-hop WAN net-
works, these qualities are not guaranteed by the Cloud. In
fact, it aims to manage the modern real-time responsiveness
requirements in a secure data and user applications, in more
A methodology for deployment of IoT application in fog
relaxed timings of which the IoT needs. In addition, Cloud is
designed to work on large networks, which may contain bot-
tlenecks or even interruptions. The lack of connection is not
actually the only service interruption reason. Let’s consider
the case in which a shared access to a resource is present
for all user connected to the same WAN. As often happens
in networks which convey a large number of users that can
be both human and artificial, as more and more frequently
occur in modern IoT scenarios, in correspondence of peak
usage there is an high probability that the resource sharing
becomes effectively unusable by users, due to an overload
of network communications. Cloud is not designed for the
reception of data with frequency and speed like those that
are produced by numerous IoT devices; moreover analysis of
those data on Cloud platforms involves a continuous move-
ment of a huge amount of data. All this leads to congestion,
which directly results in denial of service, slowdowns or
disconnections Papageorgiou et al. (2015).
In addition to the congestion problems, Cloud is unsuited
to mobile users, since it is not rare that they change their
address, while using the same service, to move from one net-
work to another. Moreover, Cloud Computing suffers other
problems, such as those related to security and law issues.
With regard to security, it can be said that the main issues
are related to the location of user’s data. It is not always pos-
sible, or convenient, to move the computational load on the
network to the Cloud because performance are not guaran-
teed in some critical situations of particular interest.
Smart Grid represents the most relevant IoT application
in the wider Smart Metering context. It has emerged to pro-
vide an intelligent power infrastructure, but it is integrating
IoT devices to gather more and more detailed information
and introducing additional requirements. The integration of
WSNs, actuators, smart meters, and other components of
the power grid with together with information and commu-
nication technology (ICT), is referred to as the Internet of
Energy (IoE). IoT technology integrated within the smart
power grid comes with a cost of storing and processing large
volume of data every minute. This data includes end users
load demand, power lines faults, network’s components sta-
tus, scheduling energy consumption, forecast conditions,
advanced metering records, outage management records,
enterprise assets, and many more. Hence, utility companies
must have the software and hardware capabilities to store,
manage, and process the collected data efficiently. In  Witt
(2015) explains how the high volume data gather in smart
grid is similar in size and characteristics to the concept of
big data.
The utilization of Cloud architecture provides, in addi-
tion to high scalability, a number of other the advantages
in the field Smart Grid such as better interoperability, rapid
elasticity, better maintainability, as well as cost reduction.
On the other had, data security and privacy remain rel-
evant obstacles to migration Smart Grid applications in
Cloud Simmhan et al. (2010). In particular, scalable access
to information on energy assets need to be balanced with
data privacy and security (using identified data), which must
not affect the performance of such mission-critical applica-
tions. The resilience of the ICT infrastructure is so relevant
to make available data from which information is extracted
in order to detect faults, isolate the fault, and then resolve
faults. Also the security of the ICT infrastructure becomes
a requirements to avoid failures caused by cyber-attacks
or by combined attacks to the power grid and to the ICT
infrastructures.
So for an important domain, such as Smart Grid, is really
important to go towards an architecture that overcome the
described limitations.
3 From cloud to Fog: benefits
and challenges
Moving resources in a point of the network closest to the
production data is the solution to meet the high latencies
that impede the execution of applications that require near
real-time to the timing and generate high data traffic. Fog
Computing aims at moving the Cloud Computing paradigm
to the edge of networks, in particular those that connect all
the devices belonging to the IoT Bonomi et al. (2012). The
edge of the network is identified by the subnet of the devices
in the network and can have a reduced or a wide extension
depending on whether the internal devices are wireless or
broadband.
The nodes, even if are less performing compared to the
cloud platforms, are suitable for execution of complex tasks
and the storing of data. They are also scalable and adaptable
to different types of deployment.
In this place of the network, Cloud services can operate
directly, or at the most by a single intermediary, with mobile
customers that consume or produce data. According to the
commonly accepted definition of Fog Computing Vaquero
and Rodero-Merino (2014), it represents a scenario where an
high number of wireless devices communicate and cooper-
ate among them and with network services to support the
storage of data and the computational processes without
intervention from third party.
The conceptual model that describes the Fog archi-
tecture fits all devices that extend the capabilities of the
Cloud in a dedicated intermediate level of connection
to end devices for data protection. Fog nodes have the
characteristic of being distant from the Cloud data center
with which they communicate, but very close to the user
devices. Fog nodes also are in large number and scattered
13

Fig. 1  Fog architecture overview
throughout the territory according to a geographically
convenient distribution that covers the largest number of
users.
As it is shown in Fig.  1, Fog nodes work as a bridge
between IoT devices and the Cloud. Using this information
they send signals to actuators or communicate with users via
mobile devices. The variety and the potentially enormous
numbers of endpoint devices spotlight, the significance of
the such a layer in the IoT architecture. Data processing does
not take place only in the Cloud, but also in local smart
structures, capable of providing its own limited computa-
tional power to perform simple tasks. However, they offload
to the Cloud critical tasks whose requirements overcome
their capabilities. In this way, they decrease latency. The
main goal of the Fog is not just the latency, which is a key
issue in hostile environments for the early identification of
significant and potentially damaging events that occur in the
system, but also the downsizing of unnecessary and redun-
dant data sent to the central network. The fog computation
reduces the redundant and unnecessary traffic, preserving
the band for most significant processes, and sending only
regular statements (clustering) regarding the state of the sys-
tem under test. The availability of computational resources
distributed close to the data sources can be exploited to
deploy technical solutions that have been already applied
in other fields for data gathering and data fusion (e.g. algo-
rithms proposed by  Ling et al. (2017) to increase lifetime
of Wireless Sensor Networks).
The advantages of adopting such a model include also
support to mobility. When a node realizes that the connec-
tion with the device is becoming too weak and the latency
is affected, it can move the application to another Fog node,
nearest to the device you are moving, in order to avoid ser-
vice interruptions.
The Fog tier also contextual data to devices, and appli-
cations that need it. Fog nodes are also able to extrapo-
late the infrastructural information in a more detailed way
respect to the data cloud center. Services enjoy of additional
information about the status of the radio channel used for
13
S. Venticinque, A. Amato
communication and the geographic location of the unit, as
well as the devices that use them.
The resulting model is the element that will enable exist-
ing infrastructure to meet the demands of modern applica-
tions, especially related to IoT that need to process data close
to the source to minimize latency and avoid frequent connec-
tions with the Cloud, limiting traffic generated by network.
The applications residing on Fog nodes are not software
sectors in isolation, but are part of larger solutions that also
cover Cloud, and user level.  Arridha et al. (2017) shows
how fog nodes are relevant to collect and forward data for
real time monitoring, however Cloud sources are necessary
to run big data analytics. The optimal deployment of soft-
ware components proposed in the next sections will allow
for an effective distribution of the analytics between Cloud
and Fog layers. In this way the Cloud level will only be
solicited by requests requiring soft time constraints, such
as, for example, the statistical processing of the system or
of the historical analysis and long term storage of Big Data.
Fog nodes store less data respect to the Cloud and data are
preserved for less time, just the time needed for the execu-
tion of real-time IoT service. This separation of responsibil-
ity, lightens the load of data sent to the cloud and allows
you to increase the security of sensitive information passing
through the Fog level.
Fog nodes inherit the characteristics of the Cloud server
devices and are highly virtualized environments. The ben-
efits resulting from virtualized software model are the same
of the cloud environment. They ensure a logical isolation
of shared components, both between the various processes
running and among the areas where the data are allocated.
Manage a myriad of heterogeneous devices, leveraging
the centralized Cloud technologies is a very complex task,
so that often it leads to the lost of the benefits of adopting the
Fog computing paradigm. In particular this paper contrib-
utes to address the problem of placing software components
of an IoT application in the Fog.
4 Fog Application model
Here we use and extend the Fog Application model defined
in  Skarlat et al. (2017) and shown in Fig.  2. An IoT appli-
cation consists of several services, which run on virtualized
IoT devices (i.e., Fog cells) and interact with each other to
provide a well-defined functionality. Hence, an application
is distributed in a Fog landscape by placing the services onto
particular Fog cells. Let A = ∪ni=1 Ai be a set of applications
to be placed in a fog landscape. Each application consists
of a set of services. A service a ∈ Ai is characterized by its
demands for computational resources, i.e., CPU cCa , RAM
a  , storage ca , bandwidth ca and by a service type Ta . The
cM S N
type Ta specifies the requirement of a service to be executed
A methodology for deployment of IoT application in fog
Fig. 2  Fog architecture
on a specific kind of resource, e.g., which is equipped with
a specific sensor. Without loss of generality, we consider
three types of services: sensing, processing, and actuating
services. A service has an estimated make-span duration ma.
An application Ai could be characterized by a deadline
DAi which defines the maximum amount of time allowed for
the application execution and by an arrival rate of requests
ARi that represents the maximum workload it is necessary
to process. The application response time rAi , with Ai ∈ A ,
depends on the make-spans of its services a ∈ Ai , and on the
communication time.
A Fog cell f is a virtualized single IoT device coordinat-
ing a group of other IoT devices, i.e., sensors and actuators.
Fog cells run on IoT devices with computational, network, and
storage capacities, while pure sensors and actuators are IoT
devices without such resources. A Fog cell is a software envi-
ronment that provides access to, control of, and monitoring of
an underlying physical IoT device. Computational resources
of a Fog cell are usually very limited. Fog cells are organ-
ized in a Fog colony. Each colony is identified and managed
by its control node F. We denote Res(F) the set of Fog cells
which are managed by F. A colony acts as a micro data center
with resources scattered in a certain area, i.e., each Fog cell
belongs to the resources of a colony: f ∈ Res(F) . The com-
munication link between a Fog cell f and a control node F is
characterized by a negligible delay. Under the assumption of
symmetric links and considering that a Fog cell f can com-
municate only with the control node F of its own colony, we
denote df as the communication link delay between f and F
with f ∈ Res(F) . Colonies communicate with each other via
their control nodes. A control node is a more powerful Fog
cell. It could work as a proxy server or a gateway. Usually, a
control node F is supplemented with faster and more expensive
computational resources than resources of Fog cells, however,
at the same time, slower and cheaper than Cloud resources. F
is characterized by its capacities CPU CFC , RAM CFM , network
CFN and storage CFS  . Each control node has to perform resource
provisioning by exploiting the computational resources of the
Cloud to overcome its own limitations. A Cloud R has theoreti-
cally unlimited resources. The logical link between a control
node F and the Cloud R has a not negligible delay dR.
4.1 Fog service placement problem
Fog Service Placement Problem consist of finding the opti-
mal mapping between IoT applications and computational
resources, with the objective of optimizing the Fog landscape
utilization while satisfying QoS requirements of applications.
Here we do not care about services allocation to Fog cells, but
we focus on the Fog service placement on the Control nodes
rather than on the Cloud. The proposed methodology aims at
supporting the developer to determine the following subsets
of placements:
– Which services have to be executed locally on F’s own
resources?
– Which services have to be deployed in the Cloud R?
Recalling the application model, we observe that could be
mandatory to deploy a service a ∈ Ai on the Fog Node F
because of its type Ta that may require specific resources. This
is the case of drivers that communicate directly to sensors or
to Fog cells f ∈ Res(F).
The binary variable xa indicates whether it is mandatory to
deploy a service in the current Fog node F. ya defines that the
service a is optionally placed on the control node. The binary
variable za defines whether the service a is deployed to the
cloud. Variables xa implicitly account for the types of services
and types of IoT devices through Resa (F) . Analogously, vari-
ables ya indicates that the control node can host the service a.
As a first constraint, each service a has to be placed either
in the Fog or in the cloud:
Resa (F)
∑
xa + ya + za = 1, ∀a ∈ Ai , ∀Ai ∈ A (1)
f
Second, placed services must not exceed the capacities of
CPU, RAM, Bandwidth and storage of a corresponding Fog
resource. The Eq.  2 guarantees that the services placed on
the control node do not exceed a given percentage 𝜇 of avail-
able resources.
Ai
(2)
∑
c𝛾a ∗ (ya + za ) ≤ 𝜇CF𝛾 , 𝛾 = {C, M, S}
a
A different formulation defines the network requirements
in terms of bandwidth. Here we further distinguish the
case of data are sent from the Fog to Cloud and vice versa
13
 S. Venticinque, A. Amato

Table 1  Taxonomy of fog Parameter Description

application model
Application A Set of applications to be executed
Ai Application
D Ai Deadline for an application (in s)
rAi Response time of an application (in s)
a Service in an application
cCa CPU demand of a service
cM
a
RAM demand of a service
cSa Storage demand of a service
cNa Network demand of a service
ma Makespan of a service
Ta Type of a service
d(a, F)S Response time of a service executing on a Fog node
d(a, R)S Response time of a service executing on a Cloud node
Fog Landscape R Cloud
F Control Node
CFC CPU capacity of F
CFN Network capacity of F
CFM RAM capacity of F
CFS Storage capacity of F

(Eq. 4). This is necessary for asymmetric channels, such As a third constraint, we account for the response time rAi
as the ones available in residential buildings or in mobile of an application, so that it does not violate the application
networks. Equation 3 computes the bandwidth cF u used by deadline as in  5.
N

all services placed on the control node, which send data to

services running on the Cloud. It also defines the upload
rAi ≤ DAi , ∀Ai ∈ A (5)
constraint CF u of control node and the download constraint
N The application response time rAi depends on the overall
CR of the Cloud.
Nd make-span mAi The overall make-span mAi accounts for the
time needed to transfer services to computational resources,
N
Res(F) Res(R)
∑ ∑ u
execute them, and retrieve the results, considering that the
cF u = cNa ,j ∗ mai ,aj ∗ (yai ∗ zaj + yaj ∗ zai ) communications are coordinated by the control node. The
i
ai aj
make-span mAi depends on the execution time of each service
∀a ∈ Ai , Aj ∀Ai , Aj ∈ A (3) according to its placement as in  6–7. We define mAi as:
N N
cF u ≤ 𝜇CF u Ai
(6)
∑ N ∑
N mAi = d(a, F) ∗ (xa + ya ) + d(a, R) ∗ zA
cF u ≤ 𝜇CR d
F a

where d(a, F) and d(a, R) represent the make-span of a

service, when it is executed on the control node F and the
Equation 4 computes the used by all services
bandwidth cF d
N
Cloud R respectively.
placed on the control node, which receive data from services
In Table  1 we summarize the defined notation.
running on the Cloud. It also defines the download constraint
In the following sections the service placement problem
CF u of the control-node and the upload constraint CR d of the
N N
will be addressed focusing on CPU and Network require-
Cloud.
ments applying a three steps methodology.
Res(F) Res(R)
N d
∑ ∑
cF d = cNa ,j ∗ mai ,aj ∗ (yai ∗ zaj + yaj ∗ zai )
i
ai aj 4.2 BET methodology
∀a ∈ Ai , Aj ∀Ai , Aj ∈ A (4)
N N A solution to the presented model will be found using a the
cF d ≤ 𝜇CF d methodology based on Benchmarking, Evaluation and Test-
ing (BET) activities.
∑ N N
cF d ≤ 𝜇CR u
F

13
A methodology for deployment of IoT application in fog
Fig. 3  Architecture overview
1. Benchmarking: The computation and the communication
requirements will be estimated on the target platform for
different workloads. In particular each service will run
on the target platform in order to estimate the execution
time d(a, F) and d(a, R) with increasing input sizes.
2. Evaluation: the presented model will be used to compute
an upper bound to the workload that can be processed by
different deployment configurations. In particular, Eq.  2
in the case of CPU utilization becomes:
∑Ai
a
cCa ∗ (ya + za )
= hood level. Users’ preferences and constraints include some
CFC
(7)
n Ai
� �
(d(a, F) ∗ ya + d(a, R) ∗ za ) ∗ 𝜆a ≤𝜇
i a
where 𝜆a is the arrival rate of requests for the service
a that must be maximized ∀a ∈ Res(F)a and others
parameters have been estimated by benchmarks. Equa-
tion  7 defines the same problem in terms of percentage
of time used by services. The objective is to maximize
the throughput of all services 𝛌 = {𝜆1 , ..., 𝜆n } keeping
free 𝜇 percentage of CPU, which takes into account the
error introduced by the model and the overhead con-
suming processng resources. The analytical solution of
Eq. 7 provides a pareto front of solution consisting of
thresholds values for the arrival rates in different deploy-
ment configurations.
3. Testing: the evaluation results will be used to reduce
the space dimension of test cases. It provides an upper
bound to the maximum throughput that can be processed
by the nodes in each deployment configuration. Testing
will be used to validate the evaluation results, to tune the
deployment configuration reproducing, by a testbed, the
real environment and to estimate the overhead.
Smart Energy represents a killer use case for the adoption
of the Fog paradigm.
In order to demonstrate the application of the proposed
approach we extended the CoSSMic platform described
in  Jiang et al. (2016) and evaluated three different deploy-
ment solutions. In the CoSSMic scenario consuming appli-
ances and photo-voltaic panels of a neighbourhood are
continuously monitored. Users plan the utilization of their
devices using a software application, and the system com-
putes and enforces the best schedule of consuming appli-
ances, to optimize the global self-consumption at neighbour-
parameters that allow to define the flexibility of the schedule,
but they need to set in advance which kind of program they
are running.
Here we focus on some extended functionalities that have
been developed to automatically learn energy profiles cor-
responding to different working programs of an appliance,
and to predict at device switch time which program is actu-
ally going to run.
Let’s suppose an users has switched-on her washing
machine. The start will be detected by the system, which
will stop the device and will schedule the next switch-on
at the best time of the day, according to the energy require-
ments of the predicted working program. At the end of the
run measured energy consumption will be used to improve
the average consuming profiles and to update the prediction
model.
In Fig. 3 we show an overview of the CoSSMiC platform.
It is possible identify four main layers:
– The Sensor Layer is composed of different kind of sen-
sors  Gupta et al. (2016), digital smart meters, digital
controls, and analytic tools to monitor and control two-
way energy flow.
13

– The Sensor Network, collects and disseminates envi-
ronmental’s data. Wireless sensor networks facilitate
monitoring and controlling of physical environments
from remote locations at any time. Devices in the grid
can send information through wireless interfaces (for
example UHF or Zigbee). Such a communication layer
allows for transmission of data and control signals using
heterogeneous technologies and across different kinds of
area networks. For example data can be collected locally
using embedded systems that are hosted at the user’s
home, in a server, or directly to the user’s smartphone,
according to the complexity of applications, the amount
of data and the provided functionalities.
– Drivers implement the bridge between sensors and the
integration platform. In fact sometimes the same tech-
nology cannot adequately manage the characteristics of
data from different sources. The lack of standards and
the availability of many proprietary solutions require an
effort to develop a new driver for each different technol-
ogy to be integrated into the architecture. At the next
layer data are collected in centralized or distributed
repositories.
– The Integration Layer integrates data coming from
a number of sensors drivers providing a uniform rep-
resentation model, which is used to store and manage
the information at the Data Layer. Data flowing from
the sensor layer are characterized here by complexity
of different type, that make challenging the extraction
of relevant information they provide as a whole. In fact
data are heterogeneous as they come from very different
sources or they are representative of different phenomena
(the sources can be rather than utility meter sensors that
detect environmental quantities or human phenomena).
– The Data Layer holds all data that have to be processed.
– The Application Logic. Specifically-designed data analy-
sis procedures are also used to detect and analyse data
Patel et al. (2012). On relevant situations, productions
activate messages which are sent to the User Interface
and notify users about dangerous situations or recom-
mend correct behaviors. XMPP1 (Extensible Messag-
ing and Presence Protocol) is used as transport layer to
deliver such messages to final users reusing the mecha-
nisms of protocol (friendship, presence, multi-user chat,
etc.) to identify available receivers, groups, etc. Other
actions consist of real time commands to electric devices
in the smart house. They are delivered using specific API
of the integration, which are implemented by the differ-
ent drivers. the For example, through device drivers the
mediator APIs allow to switch on or switch off devices,
when there is a dangerous situation.
1
  https​://xmpp.org/.
13
S. Venticinque, A. Amato
– The User Interface (UI) supports interactive control and
configuration of the system. It provides to the user real
time monitoring information, statistics on historical data
and feedback from the coaching system. XMPP messages
are used to trigger alerts, to communicate with other
users and with the application layer providing informa-
tion and feedbacks to the Application Logic.
4.3 The software platform
In Fig. 4 the component diagram of the CoSSMic applica-
tion is shown.
1. The Data collector stores measures for monitoring, real
time processing and analysis.
2. The Event detector is in charge to detect the start and the
stop of a consuming devices.
3. The Profile clustering identifies from historical measures
the energy profiles of different working programs for
each device.
4. The Profile modeler computes the average profile for
each cluster.
5. The Usage modeler learn from historical measures the
common usage of a device by each user.
6. The Profile prediction predicts for each user and for each
device the next program is running, when a device is
switched-on.
7. The Device scheduler according to PV production,
energy requirements and users’ constraints computes
the best schedule of appliances.
8. The Device controller enforce the schedule automati-
cally switching on/off the controlled devices.
Profile clustering, Profile modeler and Profile prediction
implement the new functionalities that automatically execute
tasks which were manually performed by users.
The main issue investigated in this section and in the
following ones will be the deployment of services, which
implement the monitoring and the learning functionali-
ties, in the Fog nodes rather than in the Cloud. The energy
scheduler is a peer to peer application that exploits the col-
laboration of all control nodes and is out of scope in this
contribution.
In Table 2 the learning and monitoring software compo-
nents are renamed according to the notation defined in the
previous Section. For convenience, the terms service and
component will be used interchangeably.
4.4 Deployment configurations
Different deployment configurations of the CoSSMic
platform has been preliminarily defined and investigated
A methodology for deployment of IoT application in fog
Fig. 4  Component diagram of the CoSSMic application
Table 2  CoSSMic application Application
model
A0 : drivers
A1 : monitoring
A2 : learning
A3 : prediction
A4 : scheduler
in  Amato et al. (2014b) and in  Amato et al. (2014a). Here
we focus on deployment of new monitoring and learning
components to evaluate the new overhead introduced and
the compliance with some relevant requirements. For sake
of simplicity we will deploy the full applications A0−3 in
Cloud or in Fog according to the following configurations:
The All-in-cloud configuration locates all the software
components remotely. The Fog nodes will just host a
queue service that is in charge to route energy measures
to the Cloud and to receive commands from remote.
The cost of a centralized and complete knowledge about
the distributed system will be a greater latency and
eventually privacy issues to be addressed.
Services Interaction
a0,i : driver A0 − > A 1 , A 1 − > A 0 , A 4 − > A 0
a1,1 : collector A0 − > A 1 , A 1 − > A 2
a1.2 : detection
a2,1 : clustering A1 − > A 2 , A 2 − > A 3
a2,2 : profile approximation
a2,3 : user model
a3.1 : prediction A3 − > A 4
a4.1 : scheduler A4 − > A 0 , A 3 − > A 4
The All-in-fog solution hosts every component in Fog
nodes. Here we have no privacy issues and reduced
latency, but we need to tune the software components in
order to comply with the limited resource of each node.
The Half-in-fog solution will try to find a good compro-
mise between performance and system capabilities.
The main requirements for this application is the response
time of prediction ( A1 ) and of detection, in fact it is relevant
to apply the reaction in real time for switching-off the device
and for triggering the scheduler to allocate the required
energy. Another requirement we investigate in this paper is
the bandwidth in upload that can be limited when the Fog
control node is installed in an household by an ADLS link.
13
 S. Venticinque, A. Amato

Table 3  CoSSMic deployment App. All-in-cloud All-in-Fog Half-in-Fog

configurations
xa ya za xa ya za xa ya za

A0 0 1 0 0 1 0 0 1 0
A1 0 0 1 0 1 0 0 1 0
A2 0 0 1 0 1 0 0 0 1
A3 0 0 1 0 1 0 0 1 0

Obviously, the compliance with this requirements depends
both on the hardware resources and on the workload to be
processed, but they can change according to the deployment
configuration.
The placement of each application according to the pro-
posed model is shown in Table 3. Additional technological
details are provided in the following sub-sections.
the scheduler is also running in Cloud, the only informa-
tion to be communicated to the gateway is the assigned
start time. We assume that the delay of the assigned start
time is not relevant respect to the dynamic of the schedule,
which needs a certain degree of flexibility from the user to
optimize the energy utilization.

4.4.1 All‑in‑cloud 4.4.2 All‑in‑fog

As it shown in Fig. 5 measures and application data for
all users and all devices are stored in Cloud. Also all ser-
vices run in Cloud, except IoT drivers. The data collector
is implemented by a web service with a REST interface
that receives energy samples in real time from devices
through the Fog control node. The event detector works
in pipeline with the data collector in order to identify the
switch-on and the switch-off of each device. That means
there will be relevant latency from the switch-on detec-
tion and the switch-off control that must be applied in real
time. On the other hand, this solution has the advantage
to store all data in Cloud, which means a centralized full
knowledge base of energy measures. For this reason, all
the needed information are available for clustering the
time-series of the same device type. Clustering is trig-
gered when the completion of a device run is detected.
It allows to classify different working programs, which
will be used to predict the energy requirements at the next
switch-on. Of course, time-series recorded for the same
device type at different households allow to characterize
earlier and better the energy profiles, which can be used
for new households, or for those that have not been col-
lected any measures yet. The clustered time-series are used
by the Profile modeler to compute the representation of
each energy profile. There will be one average profile for
cluster. The clustering will also allow to learn the user’s
behaviour in terms of device utilization. It means that,
for each user and for each device a regression model will
be estimated to predict the next program will be planned,
observing the sequence of previous runs. Such a model
is used by the Profile prediction when the switch-on of a
device has been detected. The energy profile correspond-
ing to the same model is used by the Device scheduler to
compute the assigned start time for the device. In the case
As it shown in Fig.  5 measures and application data of
each user are stored locally, in her own Fog node. Also all
services run locally. In this configuration all components
will run on the Fog node. This was the default configura-
tion deployed by the CoSSMic project in all trials. No data
are transferred to the Cloud, and only the average profiles
need to be communicated between the distributed instance
of the scheduler to compute the assigned start time. It is
straightforward to observe that there are not latency issues
in this case, a part the time required to update the sched-
ule. Even security and privacy issues are reduced, because
only an analytical model of the average energy profile is
shared among gateways. On the other hand, the utilization
of local data will limit the learning process of energy pro-
files, that cannot exploit time-series of other households.
Focusing on the scope of this contribution, it is critical
to evaluate the performance resulting from the execution
of all software components on the embedded platform
hosting the gateway, in fact the original software did not
include the new learning capabilities (Fig.  6).
Fig. 5  All-in-cloud deployment configuration

13
A methodology for deployment of IoT application in fog
Fig. 6  All-in-Fog deployment configuration
Fig. 7  Half-in-Fog deployment configuration
4.4.3 Half‑in‑fog
The third configuration aims at reducing the latency and
the bandwidth utilization, but would like to use the Cloud
resources to exploit the collective knowledge about energy
consumption by appliances, and off-loading the most expen-
sive computation. The proposed deployment configuration
is shown in Fig.  7. The only software components running
in Cloud are the Profile clustering, Profile modeler and the
User modeler. The local gateway will upload to the Cloud
the time-series of a completed run after that the switch-
off has been detected. The Cloud services are in charge to
return the updated average profiles, and the usage model.
This allows also for providing energy profiles as a service
to other energy management systems adopting alternatives
approaches like the one described in  Gentile et al. (2016).
There are not hard constraints for updating the models,
because there will be at least the time until the next utili-
zation of the appliance by the user. On the other hand the
only computational burden, which is the utilization of the
regression model for predicting the starting working pro-
gram, is less than the computational requirements of the
training phase.
5 Experimental results
Experiments aim at evaluating the performance and the
resource utilization of different IoT deployment configura-
tions. The testbed has been set-up with a 8GB I7 worksta-
tion hosting Ubuntu Linux 17.04 and a fog node that is a
raspberry PI3 board with Raspbian Jessie operating system.
Three different configurations have been evaluated to
estimate performance improvement provided by an optimal
deployment choice. To reproduce a realistic scenario we
emulated the workload using energy measures of CoSSMic
trials.
The tsung2 stress tool has been used to model and run the
tests and to monitor the resource utilization. Tsung allows
to define a testing scenario by concurrent sessions. Sessions
can start on a single or on multiple machines. Each session
is composed of one or more requests, which can grouped by
transactions. A transaction is defined as a sequence of mes-
sages whose statistics will be evaluated.
The first designed scenario is shown in Fig.  8a. It
describes, by a sequence diagram, the workload model in
the case software components are deployed all in Cloud or
all in Fog. Two concurrent sessions have been defined. The
first session, which is called metering, sends measured data
to the Emoncms content management system. This session
simulates the common behaviour of any smart meters. It
includes just a transaction, sending only one HTTP request
to invoke a REST method for posting energy samples.
The second session, which is called run, emulates the
start and the stop of an appliance. It occurs with a lower
probability than the first session. It includes two kind of
transactions. The first one, which is called prediction, is
composed of a blocking XMPP message that notifies the
start of the device. Than it waits for the predicted energy
profile that is going to execute. The second transaction,
called learning, is non-blocking, it notifies the stop of the
device. The learning transaction is delayed according to the
duration of the run. The samples of the run between the start
and stop are emulated by instances of the metering session.
The schedule transaction is missing because it is out of the
scope in this paper. The second designed scenario is shown
in Fig.  8b. It describes, by a sequence diagram, the work-
load model in the case software components are distributed
in Cloud and Fog. In particular we have two instances of the
learning agent that executes the prediction function locally
and the learning functions in Cloud. The light blue color is
used here to highlight the only one transaction distributed
between Fog and Cloud. In this case the energy sample are
not transmitted to the Cloud, but at the end of the run the
monitored consumption of a run is communicated by only
2
 tsung.erlang-projects.org.
13

(a) All in Cloud and all in Fog
Fig. 8  Testing scenarios
one message at the end of the execution. Moreover the pre-
diction model is asynchronously received from the Cloud,
but it does not belong to a transaction because we are inter-
ested only to its effect on the bandwidth utilization.
5.1 Benchmarking
A preliminary analysis about the performance of software
components has been investigated running all functions in
Cloud with different workloads. We emulated the sequence
of 200 runs of a washing machine. Each clustering and the
learning algorithm is executed on all the collected profiles,
as well as the prediction use the model trained on the full
history. But the spline approximation is computed for each
cluster, but using just the last five recorded profiles assigned
to each cluster.
In Fig.  9 the blue points represent the time for complet-
ing each computation. The red line is the linear approxima-
tion of the time distribution that allows to predict the per-
formance figures with increasing workload. In Fig.  9a the
time increases with number of processed individuals. The
time to compute the splines models depends on the number
of clusters identified and on the number of time-series in
each clusters. For this reason in Fig.  9b on the x axis we
plotted the product between the number of identified clus-
ters and the number of time-series. Such a number varies
between 1 and 45 because just the last five runs are used to
compute the spline. Figure  9c, d show the time needed to
build a classification model using the random forest algo-
rithm and the application of the same model to predict which
program is starting, according to the switch-on date-time
and the previous occurrences. We can observe that the time
13
S. Venticinque, A. Amato
(b) Half in Fog
increases slightly linear with the length of the sequence, and
the time to complete the prediction is comparable with the
classification.
In Fig.  10 performance of processing elements has been
evaluated in the case all the software components run on the
raspberry. Here we can observe that performance results are
obviously worse, but they are comparable with the case they
run in Cloud.
They relevant issue to be addressed deals with the the
number of devices and data to be handled locally. In fact the
processing time of each element will affect the maximum
acceptable arrival rate of incoming requests. We expect a
reduced number of devices to be handled locally, but such a
solution does not allow to exploit data from other fog nodes
to speed up and improve the learning process. Benchmark
results will be assigned to the parameters of Eq. 7 to select
the feasible deployment configurations.
5.2 Evaluation
Here we evaluate the model formulated in Sect.  4.1, setting
the arrival rates of energy samples. In Table  4 evaluation
results are shown for different values of the arrival rate of the
energy samples. We also supposed that 20% of energy sam-
ples belong to switching events. Values have been chosen
to reproduce underloaded, overloaded and normal working
conditions.
We expect that when either cCF > 1 or cCR > 1 the system
will be overloaded and the execution time will continuously
increase until a failure.
The system will work in normal condition when both
cCF < 𝜇F or cCR < 𝜇R where the 𝜇 parameter depends on the
A methodology for deployment of IoT application in fog
(a) Clustering performance
(c) Random Forest classification
Fig. 9  All in cloud performance
overhead and the amount of resources used by the operating
systems. In normal conditions, we expect that the execu-
tion time will match the values provided as an input to the
model, even if fluctuation of the workload can introduce
several deviation.
The system will work in normal condition when both
cCF << 𝜇F or cCR << 𝜇R . It will be able to reduce deviations
and process longer and greater fluctuation. We do not dis-
tinguish in this case upload and download. In this case cNR
and cFR are the same as we consider one Fog control node.
5.3 Testing
The performance evaluation of processing element allowed
only for an estimation of the processing capability of
working nodes (Fog and Cloud). It allows to estimate a
upper bound for the arrival rate of processing requests.
However in order to evaluate the latency, bandwidth and
the computation overhead it needs to test realistic work-
load on real testbeds.
(b) Spline computation
(d) Random Forest prediction
Here we reproduce the scenario shown in Fig.   8a to
evaluate the resource utilization in term of CPU load and
communication overhead at Cloud side, and to estimate the
latency of each transaction. In particular, we are presenting
performance results with different values of the arrival rate.
Each test will last for 2 min.
5.3.1 All in cloud scenario
In this scenario the fog node is sending all sensors data to the
cloud node and receive both the prediction about next load
profile to schedule and the energy profile itself. Every com-
putation is done in the Cloud and all the historical data are
stored there. In three different experiments requests arrives
at a different rate. For this scenario values of inter-arrivals
are 1, 0.5, and 0.1 s. In each experiment 20% of requests
corresponds to the start and to the stop of a device, 80%
of requests are any other energy samples. The arrival rate
of request during the run of each experiment is shown in
Fig.  11a.
13
 S. Venticinque, A. Amato

(a) Clustering performance (b) Spline computation

(c) Random Forest classification (d) Random Forest prediction

Fig. 10  All in Fog performance

The processing capability of the Cloud can be under-

Table 4  Evaluation of CPU and network utilization stood comparing the arrival rate of Fig.  11 with the dura-
Sample rate
tion of transaction shown in Fig.  12.
cCF cCR cNR (KB/s)
(req/s) In Fig.  12a the load of the Cloud node is shown for the
different experiments. Of course the workload grows with
All-cloud 1 0 0.075 0.385 the arrival rate. It can be more than 1 because it has a quad
2 0 0.15 0.77 core processor.
10 0 0.72 3.85 In Fig.  12b–d the duration of different transactions
All-fog 0.2 0.11 0 0 must be evaluated with different criteria. In fact, we must
1 0.52 0 0 observe that each sample transaction is an HTTP request
2 1.04 0 0 that simply posts an energy value. It means that each
Half-fog 1 0.14 0.042 0.27 request waits only until the HTTP response is received.
2 0.28 0.084 0.54 On the other hand the stop transaction triggers the clus-
10 1.4 4.42 2.7 tering and this learning processes. It is asynchronous, that
means the duration include only the transmission time as
no acknowledge its expected and also the connection is
already open. Finally, the predict transaction must wait
In Fig. 11 the rate of relevant transactions is also shown. for the response. In fact, nevertheless the previous requests
In particular we observe how the arrival rate of different simply increase the load of the Cloud node, the predict
requests increases in different experiments. They are all transaction must complete as soon as possible to start the
accepted, but some of them wait enqueued for being pro- schedule and to find the best time to switch-on the device.
cessed when the inter-arrival is too short.

13
A methodology for deployment of IoT application in fog
(a) Requests per seconds
(c) 0.5 sec inter-arrivals
Fig. 11  Transaction rate in three experiments of all-in-cloud scenario
The effect of the higher overhead of the Cloud node is
observed by a longer duration of the prediction. In the case
of the highest arrival rate the prediction is received after 20
s, that becomes not acceptable after two minutes, and it is
expected to increase because the Cloud node is not able to
process the workload.
In fact another effect, not shown in the Fig. 12 is repre-
sented by the number of requests processed after the end of
the experiment, when all the message have been sent.
Average arrival rate and average duration of transactions
are provided in Table 5.
5.3.2 All in Fog scenario
In this scenario the fog node never sends data to the Cloud.
All data are stored locally and reactions are locally com-
puted and applied. Clustering and learning is computed in
the Fog node as well as prediction is performed locally.
Because of the limited capability of the raspberry platform
(b) 1 sec inter-arrivals
(d) 0.1 sec inter-arrivals
the same throughput cannot be processed locally. For this
reason, in three different experiments sessions are started
with the following values of inter-arrivals: 10, 1, 0.5 s.
In each experiment 10% of requests corresponds to the
switch-on and 10% to the switch-off of a device, 80% of
requests are any other energy samples. The arrival rate of
requests during each experiment is shown in Fig. 13 a).
In Fig. 13 the throughput of transactions in different
experiments is shown. The arrival rate has been chosen to
show the result in overloaded, normal and edge conditions.
In Fig.  14 the duration of transactions in different
experiments show that in the overloaded and in edge con-
dition the prediction increases as the throughput is not sus-
tainable by the fog node. With 10 s inter-arrivals the node
is able to process the incoming workload. Let’s observe
that it means we collect receive a measure from any device
each 10 s and a device can switch-on or switch-off not
more often than 100 s, in average. Additional details are
provided in Table 6.
13
 S. Venticinque, A. Amato

(a) CPU load (b) 1 sec inter-arrivals

(c) 0.5 sec inter-arrivals (d) 0.1 sec inter-arrivals

Fig. 12  Duration of transactions and CPU load in different experiments of all-in-cloud scenario

Table 5  Transactions statistics Name 1_r 0.5_r 0.1_r 1_d 0.5_d 0.1_d

of all-in-cloud scenario
Predict 0.06/s 0.29/s 0.56/s 0.51 s 0.92 s 5.30 s
Sample 0.59/s 1.56/s 4.32/s 21.18 ms 22.44 ms 16.31 ms
Stop 0.12/s 0.16/s 0.52/s 0.731 ms 0.634 ms 0.738 ms

5.3.3 Half in Fog scenario
In this scenario the fog node is sending only time-series
of runs to the Cloud when appliance stops. The fog node
receives prediction models and spline representations of
clustered profiles. All data are stored locally and reactions
are locally computed and applied. Clustering and learn-
ing is computed in the Cloud, but prediction is performed
locally. In three different experiments sessions are started
with the following values of inter-arrivals: 1, 0.5, 0.1 s. In
each experiment 10% of requests correspond to the switch-
on and 10% to the switch-of of a device, 80% of requests
are any other energy samples. The arrival rate of requests
during the run of each experiment is shown in Fig. 15a.
Even if the arrival rate, that means the number of devices,
is the same of the first scenario, the workload is shared
with the Cloud node. Offloading clustering and learning he
fog node can use its own computing capability to increase
its throughput. In Fig.  16 the duration of transactions in
different experiments is shown. We observe that the even
in the third experiment, when the node cannot process the
incoming requests, the duration of prediction is less than
in the first scenario. On the other hand, the fog node is
delegated to handle only local devices and the arrival rate
of 0.5 s would allow to serve the switch-on every 5 s that

13
A methodology for deployment of IoT application in fog
(a) Requests per seconds
(c) 1 sec inter-arrivals
Fig. 13  Transaction rate in three experiments of all-in-fog scenario
is far from being a constraints. Average values of duration
of transactions and of arrival rates are provided in Table 7.
5.4 Communication overhead and bandwidth
In Fig. 17 the size of data read and written by the Cloud
node through the loop-back and the Ethernet interface is
shown. We observe that the read data from the Ethernet
interface are almost the same in the first and in the second
experiment, even if with a slightly different distribution. The
data written to the loop-back interface increase in the all-
in-cloud scenario because the energy sample must be stored
and the database utilization increase. Even the number of
HTTP response written to the Ethernet interface is relevant
because of the higher arrival rate. An interesting phenom-
ena is observed in the third experiment. Here we observe a
transient high bandwidth utilization at the beginning of the
experiment, but the overhead due to the computation slows
(b) 5 sec inter-arrivals
(d) 0.5 sec inter-arrivals
down the following operations and the bandwidth utilization
decreases very fast. The same effect is not shown in the half-
in-cloud experiment because the number of HTTP transac-
tions is 10% respect to the all-in-cloud scenario.
6 Related works
According to Dastjerdi et al. (2016), advantages associated
with Fog computing include the following:
– Reduction of network traffic: fog computing provides a
platform for filtering and analysing of the data generated
by devices close to the edge, and for the generation of
local data views. This drastically reduces the traffic sent
to the Cloud.
– Suitable for IoT tasks and queries: with the increasing
number of smart devices, most of the requests are related
13
 S. Venticinque, A. Amato

(a) CPU load (b) 5 sec inter-arrivals

(c) 1 sec inter-arrivals (d) 0.5 sec inter-arrivals

Fig. 14  Duration of transactions and CPU load in different experiments of all-in-fog scenario

Table 6  Transactions statistics Name 5_r 1_r 0.5_r 5_d 1_d 0.5_d

of all-in-fog scenario
Predict 0.05/s 0.08/s 0.17/s 2.73 s 2.97 s 5.61 s
Sample 0.17/s 0.69/s 1.3/s 15.75 ms 14.3 ms 0.25 s
Stop 0.02/s 0.10/s 0.21/s 0.505 ms 0.31 ms 0.258 ms

to the surroundings of the device. Hence, such requests
can be served without the help of the global information
stored in the Cloud.
– Low latency requirement: Mission critical applications
require real-time data processing. The control system
running on the Cloud may make the sense-process-actu-
ate loop slow or unavailable as result of communication
failures. Fog computing helps by performing the process-
ing required for control system very close to the robots
- thus making real-time response possible.
– Scalability: Even with virtually infinite resources, the
Cloud may become the bottleneck if all the raw data
generated by end devices is continued sent to it. Since
fog computing aims at processing incoming data closer
to the data source itself, it reduces the burden of that
processing on the Cloud, thus addressing the scalability
issues arising out of the increasing number of endpoints.
In particular there are several application scenarios that
could benefit from fog computing that has been investigated
in several research papers. In Patil (2015) some application
of fog computing and the benefit that fog provides in those
contexts are described.
The key advantages of Fog Computing in Smart Grid
are described in Gia et al. (2015). The challenges regard
latency-sensitive issues, location awareness and large data

13
A methodology for deployment of IoT application in fog
(a) Requests per seconds
(c) 0.5 sec inter-arrivals
Fig. 15  Transaction rate in three experiments of half-in-fog scenario
transmission. Undoubtedly, the more data is transmitted over
a network, the higher possibility of error occurs because bit
errors, data transmission latency and packet dropping pos-
sibility are proportional to the volume of transmitted data.
Paper Perera et al. (2017) focuses on Fog Computing in
Smart Grid and describes several inspiring use case sce-
narios of Fog computing, identify ten key characteristics
and common features of Fog computing, and compares more
than 30 existing research efforts in this domain. Based on
their review, authors further identify several major function-
alities that ideal Fog computing platforms should support
and a number of open challenges toward implementing them,
to shed light on future research directions on realizing Fog
computing for building sustainable smart cities.
In Minh et al. (2017) authors present present the Fog
Service Placement Problem (FSPP), which allows to
place IoT services on virtualized fog resources while tak-
ing into account Quality of Service (QoS) constraints like
(b) 1 sec inter-arrivals
(d) 0.1 sec inter-arrivals
deadlines on the execution time of applications. Authors
also provide a model for an IoT application and a resource
model for the fog landscape. Afterwards, the FSPP is
described, and an according optimization model is formal-
ized and validated using experimental evaluation.
The Fog Service Placement Problem has been inves-
tigated also in Skarlat et al. (2017) where authors pre-
sent a conceptual fog computing framework and model
the service placement problem for IoT applications over
fog resources as an optimization problem, which explicitly
considers the heterogeneity of applications and resources
in terms of Quality of Service attributes. Authors also
propose a problem resolution heuristic based on a genetic
algorithm showing, through experiments, that the service
execution can achieve a reduction of network communica-
tion delays when the genetic algorithm is used, and a better
utilization of fog resources when the exact optimization
method is applied.
13
 S. Venticinque, A. Amato

(a) CPU load (b) 1 sec inter-arrivals

(c) 0.5 sec inter-arrivals (d) 0.1 sec inter-arrivals

Fig. 16  Duration of transactions in three experiments of half-in-fog scenario

Table 7  Transactions Statistics Name 1_r 0.5_r 0.1_r 1_d 0.5_d 0.1_d

of half in fog scenario
Predict 0.09/s 0.14/s 0.46/s 3.77 s 4.07 s 8.71 s
Sample 0.63/s 1.53/s 1.66/s 33.75 ms 0.11 s 11.30 ms
Stop 0.11/s 0.15/s 0.24/s 0.89 ms 0.9 ms 0.851 ms

7 Conclusion taking into account available resources, architecture and

Fog computing can be seen as an extension of Cloud com-
puting with extra features that address some challenges
of Cloud. In particular it poses the attention on the smart
utilization of all the computational resources distributed
in the network, that become a main challenge because of
the increasing development of IoT technologies. In this
scenario this paper proposed a methodology to address
the Fog Service Placement Problem, that means to find the
best deployment solution of an IoT application in the Fog,
requirements. A Fog Application model defined in related
work has been adopted and extended to apply the pro-
posed methodology. A real case study in the Smart Energy
domain and software platform, from the CoSSMic Euro-
pean project, have been extended with new functionalities
to support the automatic learning of energy profiles of
appliances and for the prediction of energy requirements
of future use. The choice of deployment configurations
can be driven by functional requirements, such the possi-
bility provide energy profiles as a service to other energy
management systems like the one described in  Gentile

13
A methodology for deployment of IoT application in fog

(a) 1-sec (all-in-cloud) (b) 1-sec (half-in-fog)

(c) 0.5-sec (all-in-cloud) (d) 0.5-sec (half-in-fog)

(e) 0.1-sec (all-in-cloud) (f) 0.1-sec (half-in-fog)

Fig. 17  Network utilization

13

et al. (2016), however effect on performance and service
levels cannot be neglected. The changed not functional
requirements have been analyzed for an optimal deploy-
ment according to the Fog computing paradigm. Experi-
mental results demonstrated the application of the BET
methodology that allowed for an effective deployment of
new learning functionalities integrated in the CoSSMic
platform. In particular we were able to evaluate and vali-
date the maximum workload can be processed with the
available computational resources in different deployment
configurations. However, the precision of estimated per-
formance is limited by the availability of a testbed, which
is as similar as possible to the real case. We think that
the proposed methodology can provide guidelines to the
developer at programming and deployment stage to meet
application requirements and to optimize performance and
utilization of available resources. The next step will focus
on the development of a tool that allows for running the
benchmarking, evaluation and testing automatically, col-
lecting performance results could speed-up and improve
the job of the developer. The design and development of a
decision support system, which automatically recommends
the optimal deployment configurations, and the estimated
performance figures, is a future work. The dynamic opti-
mization of deployment of a Fog Application by reconfigu-
ration is another hint for future investigation on autonomic
fog applications.
References
Amato A, Aversa R, Di Martino B, Scialdone M, Venticinque S, Hall-
steinsen S, Horn G (2014a) Software agents for collaborating
smart solar-powered micro-grids. In: Caporarello L, Di Martino
B, Martinez M (eds) Smart organizations and smart artifacts: fos-
tering interaction between people, technologies and processes,
Springer International Publishing, Cham, pp 125–133. https​://doi.
org/10.1007/978-3-319-07040​-7_14
Amato A, Di Martino B, Scialdone M, Venticinque S, Hallsteinsen S,
Jiang S (2014b) A distributed system for smart energy negotiation.
In: Fortino G, Di Fatta G, Li W, Ochoa S, Cuzzocrea A, Pathan M
(eds) Internet and distributed computing systems: 7th international
conference, IDCS 2014, Calabria, Italy, September 22–24, 2014.
Proceedings, Springer International Publishing, Cham, pp 422–434.
https​://doi.org/10.1007/978-3-319-11692​-1_36
Arridha R, Sukaridhoto S, Pramadihanto D, Funabiki N (2017) Clas-
sification extension based on iot-big data analytic for smart envi-
ronment monitoring and analytic in real-time system. Int J Space
Based Situated Comput 7(2):82–93. https​://doi.org/10.1504/IJSSC​
.2017.10008​038
Bonomi F, Milito R, Zhu J, Addepalli S (2012) Fog computing and its
role in the internet of things. In: Proceedings of the first edition
of the MCC workshop on mobile cloud computing, ACM, New
York, NY, USA, MCC ’12, pp 13–16. https​://doi.org/10.1145/23425​
09.23425​13
Dastjerdi AV, Gupta H, Calheiros RN, Ghosh SK, Buyya R (2016)
Fog computing: principles, architectures, and applications. arXiv​
:1601.02752​[Cs]. Accessed 5 Apr 2018
Evans D (2011) The internet of things: How the next evolution of the
internet is changing everything. Tech. Rep. April, Cisco Internet
13
S. Venticinque, A. Amato
Business Solutions Group (IBSG). http://www.cisco​.com/web/about​
/ac79/docs/innov​/IoT_IBSG_0411F​INAL.pdf. Accessed 5 Apr 2018
Evans D (2015) Fog computing and the internet of things: extend the
cloud to where the things are. Tech. rep., Cisco Internet Business
Solutions Group (IBSG). https​://www.cisco​.com/c/dam/en_us/solut​
ions/trend​s/iot/docs/compu​ting-overv​iew.pdf. Accessed 5 Apr 2018
Gentile U, Marrone S, Mazzocca N, Nardone R (2016) Cost-energy mod-
elling and profiling of smart domestic grids. Int J Grid Util Comput
7(4):257–271. https​://doi.org/10.1504/IJGUC​.2016.08101​2
Gia TN, Jiang M, Rahmani AM, Westerlund T, Liljeberg P, Tenhunen H
(2015) Fog computing in healthcare internet of things: a case study
on ecg feature extraction. In: Computer and information technology;
ubiquitous computing and communications; dependable, autonomic
and secure computing; pervasive intelligence and computing (CIT/
IUCC/DASC/PICOM), 2015 IEEE international conference on,
IEEE, pp 356–363
Gupta H, Dastjerdi AV, Ghosh SK, Buyya R (2016) ifogsim: A toolkit
for modeling and simulation of resource management techniques
in internet of things, edge and fog computing environments. arXiv​
:abs/1606.02007​
Jiang S, Venticinque S, Horn G, Hallsteinsen S, Noebels M (2016) A
distributed agent-based system for coordinating smart solar-pow-
ered microgrids. pp 71–79. https​://doi.org/10.1109/SAI.2016.75559​
64. https​ : //www.scopu​ s .com/inwar​ d /recor​ d .uri?eid=2-
s2.0-84988​84199​2&doi=10.1109%2fSAI​.2016.75559​64&partn​
erID=40&md5=dd0b5​c7229​b8637​3bf3d​3dc03​78b84​25, cited By
2. Accessed 5 Apr 2018
Ling C, Lifang L, Xiaogang Q, Gengzhong Z (2017) Cooperation for-
warding data gathering strategy of wireless sensor networks. Int
J Grid Util Comput 8(1):46–52. https​://doi.org/10.1504/IJGUC​
.2017.10003​009
Minh QT, Nguyen DT, Le AV, Nguyen HD, Truong A (2017) Toward
service placement on fog computing landscape. In: 2017 4th
NAFOSTED conference on information and computer science, pp
291–296. https​://doi.org/10.1109/NAFOS​TED.2017.81080​80
Papageorgiou A, Cheng B, Kovacs E (2015) Real-time data reduction
at the network edge of internet-of-things systems. In: Tortonesi M,
Schnwlder J, Madeira ERM, Schmitt C, Serrat J (eds) 11th Interna-
tional Conference on Network and Service Management, CNSM
2015, Barcelona, Spain, November 9–13, 2015, IEEE Computer
Society, pp 284–291. https​://doi.org/10.1109/CNSM.2015.73673​73
Patel S, Park H, Bonato P, Chan L, Rodgers M (2012) A review of wear-
able sensors and systems with application in rehabilitation. J Neu-
roEng Rehabilit 9(1):21. https​://doi.org/10.1186/1743-0003-9-21
Patil PV (2015) Fog computing. In: International Journal of Computer
Applications (0975 – 8887), National conference on advancements
in alternate energy resources for rural applications (AERA-2015),
pp 1–6
Perera C, Qin Y, Estrella JC, Reiff-Marganiec S, Vasilakos AV (2017) Fog
computing for sustainable smart cities: a survey. ACM Comput Surv
50(3):32:1–32:43. https​://doi.org/10.1145/30572​66
Simmhan Y, Giakkoupis M, Cao B, Prasanna VK (2010) On using cloud
platforms in a software architecture for smart energy grids. In: Inter-
national conference on cloud computing technology and science
(CloudCom), IEEE, poster [CORE C]
Skarlat O, Nardelli M, Schulte S, Borkowski M, Leitner P (2017) Opti-
mized iot service placement in the fog. Serv Orient Comput Appl
11(4):427–443. https​://doi.org/10.1007/s1176​1-017-0219-8
Vaquero LM, Rodero-Merino L (2014) Finding your way in the fog:
Towards a comprehensive definition of fog computing. SIGCOMM
Comput Commun Rev 44(5):27–32. https​://doi.org/10.1145/26770​
46.26770​52
Witt S (2015) Data management and analytics for utilities. http://www.
smart​gridu​pdate​.com. Accessed 29 Sep 2016