Content uploaded by Attila Kertész
Author content
All content in this area was uploaded by Attila Kertész on Sep 27, 2018
Content may be subject to copyright.
JoGC manuscript No.
(will be inserted by the editor)
A Mobile IoT Device Simulator
for IoT-Fog-Cloud Systems
A. Kertesz ·T. Pflanzner ·T. Gyimothy
Received: date / Accepted: date
Abstract The Internet of Things (IoT) is the latest trend of the current ICT
evolution, represented by a huge amount of powerful smart devices that have
started to appear on the Internet. By responding to this new trend, many cloud
providers have started to offer services for IoT management. Recent advances
have already shown that cloud computing can be used to serve IoT needs by
performing data generation, processing and visualization tasks. In this currently
forming ecosystem, IoT system developers need to purchase, connect and configure
these devices, and they also have to choose the right infrastructure provider offering
the combination of protocols and data structures fitting their applications. In this
paper, we propose a complex, semi-simulation environment that aims to provide
a solution for these IoT challenges. Our main contribution is the the design of an
Android-based, mobile IoT device simulator called MobIoTSim. We also propose a
customizable cloud gateway to manage these devices by receiving, processing and
visualizing sensor data coming from MobIoTSim. To be as close as possible to real
world application, we created an IoT trace archive service called SUMMON, which
can be used to gather real-world sensor data, which can be used by MobIoTSim.
Finally, we demonstrate how to create IoT applications utilizing numerous IoT
devices with this environment, and evaluate the device management scalability
and responsiveness of its components.
Keywords internet of things ·cloud computing ·simulation
1 Introduction
Cloud computing has become a widespread and reliable solution over the past
decade by providing scalable, virtualized data storage and computation. In the
A. Kertesz, T. Pflanzner, T. Gyimothy
Software Engineering Dept., University of Szeged,
H-6720 Szeged, Dugonics ter 13, Hungary
E-mail: {keratt,tampfla,gyimothy}@inf.u-szeged.hu
This is a pre-print of an article published in Journal of Grid Computing. The final
authenticated version is available online at: https://doi.org/10.1007/s10723-018-9468-9
2 A. Kertesz et al.
past decade, we experienced an evolution in Cloud Computing: the first clouds
appeared in the form of a single virtualized datacenter, then broadened into a
larger system of interconnected, multiple datacenters. As the next step, cloud
bursting techniques were developed to share resources of different clouds, then
cloud federations were realized by interoperating formerly separate cloud systems.
Overcoming interoperability issues of public cloud providers and various middle-
ware implementations, the process of creating and managing cloud federations is
clarified and applied [1]. There are various reasons to optimize resource manage-
ment in such federations: to serve more users simultaneously, to increase quality of
service, to gain higher profit from resource renting, or to reduce energy consump-
tion or CO2emissions. After solving optimization issues in federations addressing
datacenter consolidation, operating costs and energy efficiency, further research
directions started to use clouds to support newly emerging domains, such as the
Internet of Things.
An IoT system is a form of a global, dynamic network infrastructure composed
of smart devices and sensors having self configuring capabilities [5]. These things
can interact and communicate through the Internet by exchanging sensor data,
and they can react autonomously to certain events; even we can influence them
by triggering actions without direct human intervention. It is obvious that such
systems are suitable for numerous application areas having different properties and
requirements. According to reports and predictions in the IoT field, there will be
30 billion devices always online and more than 200 billion devices discontinuously
online by 2020 [3]. These estimations projects the appearance of smart solutions
in the near future, which are capable of interconnecting and efficiently controlling
the ecosystem of IoT devices.
Many cloud providers offer IoT-specific services nowadays, because cloud com-
puting can potentially serve most IoT needs including transparent data genera-
tion, processing and visualization. As a result, the most popular cloud platform
providers support the basic IoT capabilities, but there are some unique features, as
well. Designing and analyzing IoT cloud environments still represent a great chal-
lenge (hence many things have to be managed at the same time), and generally
these systems include a wide range of devices and utilize different data formats.
In the case of IoT Cloud applications, data management operations are bet-
ter placed close to their origins, thus close to the users, which resulted in better
exploiting the edge devices of the network. Finally, as the latest step of this evolu-
tion the group of such edge nodes formed the fog. Dastjerdi and Buyya defined fog
computing as a distributed paradigm [2], where cloud storage and computational
services are performed at the network edge. This new paradigm enables the exe-
cution of data processing and analytics application in a distributed way, possibly
utilizing both cloud and near-by resources. The main goal is to achieve low latency,
but it also brings novel challenges in real-time analytics, stream processing, power
consumption and security. Mukherjee et al. further detailed these challenges in [6],
and stated that secure communication is a key issue and privacy-preserving data
management schemes are needed.
By addressing the needs of IoT-Fog-Cloud ecosystems, we propose the follow-
ing contributions in this paper: (i) we introduce and provide an overview of cloud
providers offering IoT features and define the main requirements for designing an
IoT device simulator. Based on these requirements, (ii) we propose a mobile IoT
device simulator called MobIoTSim that for IoT device management, which is ca-
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 3
pable of simulating up to hundreds of IoT sensors and devices. We also propose (iii)
a real, private cloud gateway service to manage the simulated devices, and an IoT
trace archiving service, which can be used together with MobIoTSim to compose
a complex semi-simulated IoT-Fog-Cloud environment. Finally, (iv) we evaluate
the performance and device management scalability of the proposed solutions.
The goal of our research is to support the proliferation of integrated IoT-Fog-
Cloud technologies, by providing means for evaluating and demonstrating the inner
workings of such ecosystems. By using our proposed tools, real things or devices can
be substituted by mimicking their behavior, thus there is no need to perform initial
investments by buying real sensors or devices to investigate IoT applications. The
first idea of this approach, and the first prototype of MobIoTSim was presented in
a workshop paper [58] in 2016. After this initial version we continuously revised
and improved it with additional features, and developed additional supporting
tools, such as the trace archive and private gateways. The initial version of a
private gateway to manage sensor data was presented in a conference [59] in the
beginning of 2018. Since then we improved its device management features and
scalability. The current work summarizes these approaches, and presents their
recent developments results and achievements, that represent a complex semi-
simulation environment together with all supporting tools.
The remainder of this paper is as follows: Section 2 introduces an overview
of related works and categorizes IoT cloud providers. Section 3 provides the main
contributions by introducing the core requirements of IoT simulation, and presents
our proposed solution called MobIoTSim. Here we also discuss the development
possibilities of private cloud gateways for managing IoT devices, and in Section
5 and 6 we evaluate their scalability and device management features. Section 4
provides an outlook for a dedicated archiving service for real sensor trace manage-
ment. Finally, the contributions are summarized in Section 7.
2 Related work
Lately an increasing competition has been developed among the leading cloud
providers, like Amazon, Google and Microsoft, to attract users requiring services
of these emerging technologies. This trend works against standardization, and
results in incompatible interfaces and formats most of the time [8], both in the
cloud and IoT fields. Recent articles in this field [9][10][11] also show that there is
a high diversity in the applied IoT protocols, and there is a clear need for clouds
to support big data and IoT applications.
There are also several related works available on categorizing IoT systems and
applications. Gubbi et al. [4] were one of the pioneers by describing IoT systems in
2013, and they emphasized the importance of the joint utilization of IoT and cloud
systems. Botta et al. presented the main properties, features, and open issues of
these systems in [23], while Nastic et al. [24] listed the numerous challenges of
realizing IoT cloud systems in practice. Xu et al. [25] presented a detailed survey
of industrial IoT applications. It shows their variety and the key technologies they
use, and it also identifies recent trends and challenges. These related works also
serve as a motivation to our research by raising the need for managing a large
number of protocols and data formats by means of simulation.
4 A. Kertesz et al.
The existing simulators for examining distributed systems can be categorized
as general network simulators, like NetSim [12], Qualnet [13] and OMNeT++
[14]. With these tools, IoT-related processes can hardly be examined, such as
device placement or message handling. The OMNeT++ discrete event simulation
environment is a popular, generic tool for simulating communication networks and
distributed systems [14]. It can be used in various domains ranging from queuing
network simulations to wireless and ad-hoc network simulations.
There are also specialized, IoT simulators addressing issues raised by this work.
Chernyshev et al. [33] presented a recent survey of IoT simulators and testbeds.
They argued that research in this area is especially challenging, and existing sim-
ulators are specialized in the sense that they focus on a particular architectural
layer. One solution to overcome this could be to combine multiple specialized sim-
ulators at various levels. There are only a few large scale open testbeds to validate
proof-of-concepts, therefore testbeds should become commoditized making it pos-
sible to realize prototypes. Our research follows these findings and guidelines. Han
et al. [26] have designed DPWSim, which is a simulation toolkit to support the
development of service-oriented and event-driven IoT applications with secure web
service capabilities. SimIoT [15] was derived from the SimIC simulation framework
[17]. It introduces several techniques to simulate the communication between an
IoT sensor and the cloud, but it is limited to compute activity models.
Moschakis and Karatza [18] introduce several simulation concepts for IoT sys-
tems. First, they show how the interfacing between the various cloud providers and
IoT systems could be modeled (even including workload models) in a simulation.
Compared to our proposal, they are focusing on the behavior of cloud systems that
support the processing of data originated from an IoT system. Silva et al. [19] in-
vestigated the dynamic nature of IoT systems, hence they analyze fault behaviors
and introduce a fault model for such systems. Although faults are important, the
scalability of the introduced fault behaviors and concepts are insufficient for large
scale systems.
Khan et al. [20] introduce a novel infrastructure coordination technique that
supports the use of larger scale IoT systems. They build on top of CloudSim [28],
and provide customizations that are tailored for their specific home automation
scenarios, and as a result they limited the applicability of their extensions. Zeng
et al. [16] proposed a tool called IOTSim, which provides simulation capabilities
for big data processing in IoT systems, but their solution is limited to applications
using the MapReduce model.
The iFogSim [27] solution is also an extension to CloudSim toolkit. It can be
used to simulate IoT and fog environments by measuring resource management
techniques with several metrics, such as latency, network congestion, energy con-
sumption and cost. They presented two case studies to demonstrate IoT modeling
and resource management policies: the first is latency-sensitive online gaming, and
the second is an intelligent surveillance application using distributed camera net-
works. The DISSECT-CF simulator [30] has also been extended with IoT features,
and its operation is demonstrated with a meteorological case study [29]. Both ap-
proaches are simulating all components of an IoT cloud system, while our proposed
device simulator can be connected to real cloud gateways, and sensor simulation
can be done based on real world sensor data.
Concerning device simulation, the SimpleIoTSimulator [31] is an IoT sensor
simulator, which can be used to set up and evaluate test environments having
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 5
thousands of sensors and gateways, on a single computer. It supports many com-
monly used IoT protocols (e.g. CoAP, MQTT, HTTP). Its drawback is that it
needs a specific, RedHat Linux environment, while our approach is more hetero-
geneous, and focuses on IoT device simulation with mobile devices, which is easier
to be applied. Unfortunately, we found that the company is only engaging selected
clients at this time, therefore the tool is not yet available to the general public.
The Atomiton simulator [32] seems to be very close to our concept based on its
description. It manages virtual sensors, actuators and devices with unique behav-
iors composing complex, dynamic systems. Unlike our mobile, open solution, it
is commercial, and provides a web-based environment with limited documenta-
tion. Unfortunately, we were not able to perform a full registration to evaluate the
solution (due to sign-up problems at their website).
Next, we present a comparison of the above mentioned simulators in Table
1. We used 6 categories to compare the main properties of these solutions. The
”Cloud nodes / services” column uses the value ”Simulated”, if the application
can only simulate cloud resources in a certain use case, or ”Real”, if the system
can send data to a real application in the cloud, thus using a semi-simulated en-
vironment. The option ”No inf.” means we could not find any information about
this feature. The ”IoT sensors / devices” category has the ”yes” value, when the
actual tool supports the simulation of IoT devices. The ”Artificially gen. sensor
data” column denotes ”yes”, if the simulator can generate sensor data in an ar-
tificial way (e.g. using certain algorithms and deviation), and the ”Real sensor /
device data” provides the information that a real life IoT device data can be used
or not in the simulation. The ”Learning curve” can be long, if the learning of the
usage of the simulator and setting up a simulation environment takes a longer
time, and short if the simulator can be used almost immediately after installation,
in a self-explanatory way. The GUI support feature has the value ”no”, if there is
no graphical interface provided, ”limited”, if the application requires code writing
and editing for creating a visualized interface, and ”yes”, if it provides graphical
interaction and configuration by default. We can see from this comparison that
MobIoTSim brings novelty to the state-of-the-art with a graphical configuration
and execution interface, offering a unique way for simulating real IoT sensor op-
eration through loading trace data. Due to its mobile design, simulations can also
be performed in wireless locations, composing a semi-simulated environment.
Concerning gateway services to support the IoT world, Kang et al. presented
a study of gateways, highlighting the main features and types [34]. This detailed
survey presents the state-of-the-art and also the foreseen research directions in
this field. Our current work does not aim to propose a generic solution for all
needs of an IoT system, but to provide a gateway solution that can be used to-
gether with MobIoTSim [58] to build-up a complex semi-simulated environment
for investigating IoT-Fog-Cloud systems.
3 MobIoTSim: the Mobile IoT Device Simulator
One of the main motivating forces behind our research is that several cloud
providers have started to offer IoT specific services to ease the development of
IoT cloud applications, but such cases , where many different things need to be
operated and managed at the same time, are hard to realize. Just to mention a few,
6 A. Kertesz et al.
Table 1 Comparison of related simulators.
Simulator Cloud IoT Artificially Real sensor Learning GUI
nodes sensors gen. sensor /device curve support
/services /devices data data
NetSim Simulated no yes no long yes
Qualnet Simulated no yes no long yes
OMNet++ Simulated no yes no long limited
DPWSim Simulated yes yes no long yes
SimIoT Simulated yes yes no long limited
CloudSim Simulated yes yes no long no
IoTSim Simulated yes yes no long no
iFogSim Simulated yes yes no long yes
DISSECT-CF Simulated yes yes yes long no
SimpleIoTSim. Real yes yes limited short yes
Atomiton No inf. yes yes No inf. short yes
MobIoTSim Real yes yes yes short yes
smart city application scenarios using SIGFOX [36] or LoRa [35] technologies are
very expensive and time-consuming to be deployed with real devices, since a base
station costs up to a thousand Euros needing enormous configuration work. As a
result, we propose to use simulated devices with real cloud gateways by creating
a semi-simulated environment.
In an earlier work, we have also presented a categorization, in which we high-
lighted IoT-specific features of (originally) cloud providers [22]. Revisiting and
extending these results, we gathered the main IoT-related properties of the most
popular cloud providers in Table 2 and 3. We used the following properties and
notations in the tables to compare the selected providers. A Provider is the name
of the actual IoT cloud service provider. With Protocols, we summarized the sup-
ported IoT device protocols for connections. Data store is supported, if the system
can store data coming from devices, while BLOB means the system can store bi-
nary data, such as images. If the system supports storing and querying geolocation
coordinates, it is denoted by GEO. Finally, we showed if Push notification, action
Triggering and device data Visualization is supported or not by default.
Table 2 Data-related IoT Cloud provider features.
Provider Protocols Data BLOB
store
Bluemix [37] MQTT + -
Parse [47] REST + +
Google [41] REST + +
Amazon [42] MQTT, REST + +
Azure [39] MQTT, AMQP, REST + +
Heroku [43] MQTT + +
CloudFoundry [44] REST + +
Kinvey [46] REST + +
DreamFactory [45] REST + +
Summarizing these comparison tables, Bluemix, Azure, Google and Amazon
have the highest variety of IoT-related services. The MQTT protocol is widely
supported (which is also expected), but there are still some providers offering
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 7
Table 3 Generic IoT Cloud provider features.
Provider GEO Push Trigger Visualization
not.
Bluemix [37] + + + +
Parse [47] + + + -
Google [41] + + + +
Amazon [42] + + + +
Azure [39] + + + N/A
Heroku [43] N/A - - N/A
CloudFoundry [44] N/A - - -
Kinvey [46] N/A + + N/A
DreamFactory [45] N/A + + N/A
only REST interfaces. From this survey, we can see that the most popular cloud
providers have already realized the need for IoT support, and most of them provide
reasonably good solutions for IoT application development. Nevertheless, interop-
erability issues still exist, and applications managing a large number of different
IoT devices are hard to develop and evaluate.
By conducting this study of the available IoT cloud providers, we found IBM
Bluemix [37] the most appealing by offering easy-to-use and well documented IoT
services. Bluemix has also identified the need for a sensor or device simulator, but
its proposed tool is meant to serve simple demonstration purposes, while our aim
is to design a generic solution to this problem. Nevertheless, as we will see later,
we tried to rely on and use some of the supporting services of Bluemix.
There are different kinds of IoT environments, hence their static or dynamic
properties and the number of utilized devices can affect the design of such a sim-
ulator. For example, a connected house can be regarded as a static environment,
because its devices are usually in one place, possibly with a wired connection,
providing reliable network stability. The dynamic environment is more complex to
simulate, in such cases we would like to simulate a broader part of the environ-
ment considering WiFi interference, battery lifetime and locations of the devices.
From this classification we can derive basic requirements for an IoT cloud sim-
ulator. Since things are usually battery powered, it would be useful to represent
energy metering or monitoring. Many sensors communicate through low-power
wireless technologies, therefore at least the most widespread ones need to be cov-
ered. Various resource constraints are made to low-level devices (e.g. on processor,
memory, or connectivity), which means we need to handle different device types.
IoT systems are very dynamic as network conditions may change rapidly, and also
heterogeneous at the same time.
We are not aiming at simulating all possible IoT systems and networks, but we
still want to aid the design, development and testing processes of these systems.
Our goal is to develop a mobile IoT device simulator that can emulate real devices
and sensors, thus it can be used in the previously mentioned processes instead of
real resources.
The requirements for basic functionalities of such a simulator are to send and
receive messages, generate sensor data (for one or more devices), and react to
received messages. These capabilities are sufficient to use the simulator in IoT
system analysis. Requirements for advanced functionalities (such as simulating
network errors, recording and replaying concrete simulation cases, and connecting
8 A. Kertesz et al.
Fig. 1 A framework for simulating IoT-Fog-Cloud systems
real IoT devices to the simulator) can contribute to the analysis of more realistic
systems.
We aimed at supporting the basic IoT functionalities. To this end, a simulated
device should have a unique identifier, as well as tokens for registration and au-
thentication. The generated sensor data should be made available in plain text,
JSON or binary format including metadata information, such as date, time, and
device state. Lastly, preferably MQTT, or REST communication protocols should
be supported.
By examining related simulators in the IoT field, we found wanting to have a
solution that puts an emphasis on mobility, and provides means for performing
simulations at specific geolocations. This fact served as the major motivation for
designing our simulator for mobile devices. The main purpose of our proposed
mobile IoT device simulator, called MobIoTSim, is to help cloud application de-
velopers to learn IoT device handling without buying real sensors and to test and
demonstrate IoT applications utilizing multiple devices. The design of this appli-
cation lets users create IoT environment simulations in a fast and efficient way
with the options for custom settings. The first, initial version of MobIoTSim has
been published in [58]. Since then, we have made various feature improvements
and releases to the simulator itself, and have developed enhanced, private cloud
gateways. Next, we detail these contributions.
3.1 Simulation architecture
The architectural view of our proposal for simulating IoT-Fog-Cloud systems is
depicted in Figure 1. Compared to traditional simulators, we propose a semi-
simulated environment to stay to real world systems as close as possible. We started
to gather real sensor trace files of public IoT initiatives, and made them available
through an archive (I.), which can be connected to MobIoTSim (II.) to replay real
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 9
device behavior. We also developed gateway services (III.) to manage IoT devices
by processing and visualizing sensor data. These gateways can be instantiated and
operated at private or public cloud or fog providers.
Our mobile IoT device simulator is designed to simulate up to hundreds of
IoT devices, and it is implemented as a mobile application for Android platforms.
Sensor data generation of the simulated devices can be done by artificially gener-
ated, random values in a range given by the user – this is the default option. For
more advanced simulations, data from IoT-specific trace files can also be loaded
and replayed. The data sending frequency can be specified for each device for both
cases. The application uses MQTT protocol (by default) to send messages with
the use of the Eclipse Paho library, which is opensource. The MQTT protocol is
an established messaging protocol for IoT systems [48] and widely supported by
IoT cloud services. Message data is represented in a structured JSON object in
the simulator, compatible with the IBM IoT Foundation message format [49].
Fig. 2 MobIoTSim GUI: a.) On the left - Cloud settings, b.) In the middle - Devices, c.) On
the right - Device settings
3.2 The structure of MobIoTSim
The basic usage of the simulator is to: (i) connect the application to a cloud,
where the data is to be sent, (ii) create and configure the devices to be simulated,
and (iii) start the (data generation of the) required devices. These main steps are
represented by three main parts of the application: the Cloud settings, the Devices
and the Device settings screens – as shown in Figure 2.
In the Cloud settings screen (Figure 2.a), the user can set the required infor-
mation about the target cloud, where the data will be received and processed.
Currently, we support two clouds: we developed gateways for the IBM Bluemix
and the Microsoft Azure providers. Concerning Bluemix, MobIoTSim users can
10 A. Kertesz et al.
use the so-called Quickstart application and a standard Bluemix IoT gateway ser-
vice [37]. The Bluemix Quickstart is a public demonstration application, it can
visualize the data received from a single, selected device. For a fast and easy so-
lution, e.g. to try out the simulator for the first time, this type is recommended.
The standard Bluemix IoT service can be used, once a user has an account for the
Bluemix platform, and has already created an IoT service. This IoT service can
be used to handle devices, which have been registered before. If a simulated device
wants to send data to the Bluemix IoT service, it has to be registered beforehand.
The registered devices have device IDs and tokens for authentication. The Mo-
bIoTSim application handles the device registration to the cloud with REST API
calls, so the user does not have to register the devices manually on the graphical
web interface. The main part of the IoT service is an MQTT broker, this is where
device messages are received, and it possibly forwards them to other cloud ser-
vices. Such cloud services or applications can process the data, react to it or just
perform some visualization tasks. The required configuration parameters for the
standard Bluemix IoT service in MobIoTSim are: the Organization ID, which is
the identifier of the IoT service of the user in Bluemix, and an authentication key,
so that the user does not have to register the devices on the Bluemix web interface,
and the command and event IDs, which are customizable parts of the used MQTT
topics to send messages from the devices to the cloud and occasionally backwards.
MobIoTSim can register the created devices with these parameters automatically,
by using the REST interface of Bluemix. In some cases, the user may want to send
sensor data with MobIoTSim not only to one, but to more cloud gateways at the
same time. This is also possible by changing the organization ID attribute of a
device to one of the already saved ones in the cloud settings.
In the Devices screen (Figure 2.b), we can create or import devices, and also
view the list of existing devices, where every row is a device or a device group.
These entities can be started and stopped by the user at will, both together or
separately for the selected ones. Some devices have the ability to display warnings
and notifications coming back from the gateway, which backward communication
is also supported. By clicking on the Add button we can create new devices or
device groups. Predefined device templates can also be used for this purpose.
These device templates help to create often used devices, such as temperature
sensors, humidity sensors or a thermostat. The import feature is applicable, when
we previously saved a device to a file with its sent messages for a certain simulation
period.
New device creation and the editing of an existing one can be done in the Device
settings (or Edit device) screen (Figure 2.c). If the user selects an existing template
for the base of the device in the Type field, the message content and frequency
will be set to some predefined values. For example, the Thermostat template has a
temperature parameter, and the device turns on by reaching a predefined low-level
value and turns off at reaching a high-level value. The On/Off state of the device
is displayed on the screen of the application all the time. It is possible to select
the Custom template to configure a unique device with various sensor parameters
in detail. By default, random values will be generated within the set ranges as
parameters. A device group is a group of devices with the same base template,
and they can be started and stopped together. A group can be defined by setting
the value of the Number of devices field (which is 1 by default).
Sensor data generation for the simulated devices can be done in different ways:
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 11
–The default way to generate device data is to create a custom device, where
the user can define parameters with ranges, within the random value will be
generated (by default the Generate random data option is activated). To simplify
this process the user can use device templates, which has predefined parameters
and ranges, specific to the device type.
–The user can also choose from the predefined, already existing template devices.
This way the sensor parameters and their ranges are already set, and also an
artificial, random value generation will be performed.
–If the Generate random data option is deactivated, the user can select a file to
load the sensor values. In this way, we can replay previous experiments.
–Beside using random generation and replays, we can even load trace files of real
world applications gathered from public sources. Our first trace file example
comes from the OpenWeatherMap public weather data provider [52], which
monitors many cities and stores many parameters of them, including temper-
ature, humidity, air pressure and wind speed. Using the trace loader feature of
MobIoTSim, the simulation can mimic a real life scenario.
3.3 Using MobIoTSim
To demonstrate the usability of MobIoTSim, we show how to connect it to the
default IBM Quickstart application having an MQTT server, running in the IBM
Cloud. First, we need to create a device with the settings shown in Figure 2.a,
then we can register it to the MQTT server of the IBM Cloud. Finally, we can
start the device in MobIoTSim, like we did for MobIoT test01, as shown in Figure
2.b. From this step on, the data generated by the device is continuously sent to
the demo gateway.
Fig. 3 Screenshots of MobIoTSim connected to the private gateway: a.) On the left: Cloud
settings, b.) On the right: Devices screen showing a warning
12 A. Kertesz et al.
We also developed a customizable private gateway service for the IBM Cloud
(see [60]). It is able to manage numerous devices simultaneously, and can it can
send notifications to simulated devices in MobIoTSim, e.g. by responding to critical
sensor values. This gateway service is an extended version of the IBM visualization
application [51]. It has a web-based graphical interface to visualize sensor data
coming from MobIoTSim. Messages (defined in JSON format) received from the
simulated devices are managed by an MQTT server. It can also be used to send
responses (or notifications) back to the simulated IoT devices in MobIoTSim.
Fig. 4 Data visualization in a private gateway service in Bluemix for a single device
We have also created a gateway service in Azure IoT Hub [39], and connected
MobIoTSim to it. In this way, we can envision an inter-cloud scenario, in which
simulated devices in MobIoTSim can send data to gateways in Bluemix and Azure
clouds simultaneously. Figure 5 shows screenshots of the Azure IoT Hub, including
the gateway service called SED-IoT-App, and a MobIoTSim-simulated device is
depicted as javadevice. We also included a screenshot of the Usage tab in the
platform, showing 23 received messages. This gateway is only capable of receiving
sensor values from the simulated devices, in this current version these is no chart-
based visualization and backward notification implemented.
4 Towards Realizing an IoT Trace Archive
We have also taken the first steps to create a trace archive of IoT applications
as depicted in the I. part of Figure 1. The European Commission has published
a guideline document [53] for encouraging open access to reuse digital research
data generated by Horizon 2020 projects. In this report they defined the so-called
FAIR data principles to help Horizon 2020 beneficiaries to make their research data
findable, accessible, interoperable and reusable. Following these guidelines, we aim
to create an open IoT trace archive to facilitate data search and accessibility, and
to reuse sensor data for experimenting with IoT-Fog-Cloud systems.
As we have already discussed before, we introduced a Weather template for
representing weather monitoring smart city devices such as OpenWeatherMap.
With the trace loading feature of MobIoTSim, we can easily configure experiments
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 13
Fig. 5 An MS Azure gateway service
Fig. 6 Data visualization in the private gateway service in the IBM Cloud for two groups of
Thermostat devices showing median sensor values.
using this format. To further extend the supported application areas, we plan to
realize a public IoT trace archive to be used together with MobIoTSim. For this
aim, we started to gather real sensor data of smart city projects, more specifically
we analyzed the SmartME [57] and the CityPulse [56] projects.
The SmartME project [57] was initiated in 2015 by a group of researchers in the
Mobile and Distributed Systems Lab at the University of Messina. Their goal was
to set up a crowdfunded system using the IoT paradigm in the the municipality
area of the city of Messina, Italy. The project has an illustrative website, where
the installed sensors and devices can be overviewed in a map. The IoT system is
composed of low-cost microcontroller boards equipped with sensors and actuators
and installed on buses, traffic lamps and buildings over the municipality area of
Messina. This sensor network can be used to collect data and information of the
urban area to design advanced services for citizens. In the SmartME project they
use a collection of sensors to monitor environmental properties, traffic conditions
14 A. Kertesz et al.
Fig. 7 Detailed, parameter-wise data visualization in the private gateway in the IBM Cloud
sent by a group of devices in MobIoTSim
and energy utilization. There are 21 sensor groups (or nodes) within the Messina
region, and each group collects sensor data at a given location about the following
environmental properties: temperature, brightness, humidity, pressure and noise.
Besides environmental property monitoring, prototypes have been developed for
smart energy, parking and traffic management.
CityPulse was a former European FP7 project [56] run between 2014 and 2016.
As stated in their website, its goal was to develop innovative, reliable and real-
time smart city applications by adopting and integrating the Internet of Things
paradigm, knowledge-based computing and reliability testing. The project de-
signed a flexible and extensible smart city data analytics framework. They de-
veloped software components for real-time data stream publication and annota-
tion, installed at two locations: in Aarhus, Denmark, and in Brasov, Romania.
The project team composed of citizens, stakeholders and technical colleagues, has
developed over a hundred smart city scenarios that were published and made
available online.
To facilitate and demonstrate real sensor data reuse within MobIoTSim, we
created our first prototype called SUMMON [55], which is a web service for gath-
ering and filtering data from these projects. With this service we can list the
available datasets, and query and filter a selected dataset. In this way users can
easily search, select and apply real sensor data of real IoT applications to define
simulated devices in MobIoTSim.
As Figure 1 shows, the simulation of a whole IoT environment scenario starts
with the filtered JSON data imported from the archive service to the MobIoTSim
simulator (using the corresponding device templates). When the user starts a sim-
ulation with MobIoTSim, the sensor data are sent in the form of messages to the
MQTT broker of the IBM Cloud in our case. After it receives these real-life val-
ues, the broker forwards them to a gateway application. The gateway application
shows a real-time chart with the data, even from several devices simultaneously.
In cases, when we need just specific values from the dataset, or just a specific
number or value of records, the SUMMON service can generate a form, where the
required criteria can be specified. In our first prototype, we can use the SmartME
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 15
dataset, and enter a specified query, e.g. to retrieve the first ten traffic lamp mea-
surements with ”Off” signals in a JSON formatted file. Once this file is returned
by SUMMON, it can be imported to the MobIoTSim simulator. To be able to do
that, we introduced a new template called Smart Lamp to MobIoTSim. The trace
loading process can be done similarly as creating a new device in the simulator,
but instead of generating random data, we can select the downloaded file to read
its values. This way the created simulated device will send this real-life data to the
cloud. It is also possible to add several simulated devices simultaneously, with the
same or different datasource imported from the archive. The IoT gateway service
in the IBM Cloud receives the data from the MobIoTSim through the MQTT pro-
tocol, and forwards it to our gateway application. As a final step of this scenario,
the gateway application is capable of plotting a real-time chart with the received
data. To summarize this section, by realizing this IoT trace archive we can define
a scenario for utilizing all three components of our initially defined simulation
framework shown in Figure 1.
5 A customizable, private IoT-Fog-Cloud gateway
Based on our initial experiments and experiences with the IBM Cloud, we de-
veloped a customizable, private gateway that can be deployed to the IBM Cloud
to handle up to hundreds of different devices at the same time. This generalized
gateway is a node.js application that is able to manage multiple device topics with
the MQTT protocol. It is able to receive and send MQTT messages, and perform
data visualization. In this extended gateway, we use paging to overcome device
management limitations introduced in the free version of the IBM Cloud (i.e. to
manage 25 devices at a time). In order to enhance and better visualize hetero-
geneous device data simultaneously, we introduced device grouping for the chart
generation. This way we can see the data sent by all devices in a single real-time
chart. Two views are supported: the first one depicts the median sensor values
for groups of devices as shown in Figure 6 (here two groups of 50 devices are
managed), and we can detail the device values of the group by depicting all value
curves as shown in Figure 7 (here a group of 10 devices are visualized). Though the
IBM Cloud provides some monitoring information for deployed applications, we
can have access to more detailed monitoring data using custom Docker containers.
As a result, we placed our extended gateway solution to a Docker container, which
has also became more portable at the same time.
After performing these extensions and modifications, we evaluated the scala-
bility of this gateway service. We deployed the gateway in a Docker container as a
micro application having the following parameters: Ubuntu OS with Linux kernel
4.4.0, having 256 MBs of RAM, and an Intel Xeon E5-2690 CPU with 8 cores
(only 2 cores were dedicated to the Docker container as stated in the IBM Cloud
site [37]).
5.1 First round of evaluations
We performed multiple rounds of evaluation. In the initial phase evaluation, we
used the Thermostat template of MobIoTSim to create device groups of simulated
16 A. Kertesz et al.
Fig. 8 Initial evaluation with Thermostat devices
devices. The duration of these simulations were 10 minutes, and the simulated
devices (sensors) generated MQTT messages in every second (hence the data gen-
eration frequency was one second). We performed all simulations five times, and
used the median values. In order to get monitored information on the gateway
behavior, we used the Grafana tool of IBM Cloud, which displays resource con-
sumption for the following categories: memory, CPU and network usage.
The results of this first sound evaluation can be seen in Figure 8. The resource
utilization for the group of 100 simulated thermostat devices are depicted by blue
bars, the group of 450 devices by orange bars, while the 900 devices by gray bars.
Three resources were monitored in each cases: CPU, memory and network utiliza-
tion, respectively. To be more concrete, 900 devices were simulated by 450 actual
devices having 0.5 second data generation frequency (which is also depicted in the
figure legend). The reason to this is that the thread limit of the current version of
MobIoTSim makes able to simulate around 500 devices simultaneously (depend-
ing on the actual mobile phone hardware parameters). These results indicate that
even with this high number of devices only a little load can be observed.
To find the reasons for this, we have to examine and discuss the behavior
of the gateway application. As stated before, it receives MQTT messages, and
generates a chart of the values. The chart generation is performed on the client-
side with javascript, which workload is not represented by these measurements.
To better mimic real world IoT utilization, we need to introduce load for data
processing at the server-side. To enable this, we looked at various benchmarking
algorithms, and found that a parameterizable Fibonacci number generation would
serve our needs well, and it has also been used for stress testing CPUs in the
literature (see e.g. the stress-ng tool in [40]). After performing some parameter-
tuning experiments, we found that computing the the 20th Fibonacci number upon
each received message multiplied by a score (which is the size of the actual message)
can result in a noticeable CPU load. In this way the different computational needs
can be represented by the message size (which is a rough estimation).
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 17
Fig. 9 Evaluation results with CPU stressing
5.2 Second round of evaluations
For the second round of experiments, we introduced CPU stressing as stated before.
We set up MobIoTSim to simulate 10, 100 and 250 thermostat devices in separate
groups. This time we also performed all experiments five times, and computed the
median values, which are depicted in Figure 9. As we expected, the CPU load is
increasing by managing a higher number of devices. By examining a group of 100
thermostat devices, we can see that in the previous round without CPU stressing
we measured around 0.2% of CPU utilization (depicted by the first blue bar on
the left in Figure 8), while in this round with enabled CPU stressing we measured
around 4.69% of CPU utilization (as it can be seen in Figure 9).
5.3 Third round of evaluations
After our assumption for representing computational load in the gateway resource
management had been proved, we performed the third round of measurements.
We created device groups for 10, 100, 250 and 450 devices in MobIoTSim, and re-
executed the simulation with enabled CPU stressing. Table 4 shows the detailed
measurement values for the resource consumption in all cases. To better represent
the results, we compared the ratio of the median results for each simulated device
groups (represented by different colors). The results are shown in Figure 10. Since
stressing only affected CPU utilization, the rest of the consumed resources were
about the same (see the second and third columns from the left). Nevertheless, in
CPU utilization we can observe the differences (see the first column on the left):
the more devices we manage in a group, the higher CPU utilization it implies.
The fourth column depicts the ratio of the message sizes, while the last, fifth
column shows the number of messages managed in the groups. We also wanted to
examine the effects of modifying the frequency. Therefore we configured a similar
experiment with the same device groups, and set data generation frequency to 0.5
second: hence, we doubled the number of sent messages by all simulated devices.
18 A. Kertesz et al.
The detailed results can be seen in Table 5. Figure 11 further details our approved
expectations. It depicts CPU utilization measurements for a concrete simulation,
where we initiated message generation of three groups after the other (containing
100, 250 and 450 devices). We can see that for doubled messages (i.e. 0.5 second
frequencies) the CPU utilization is also doubled.
Table 4 Results of measurements with the Thermostat template with 1 second frequency.
No. of devices 10 100 250 450
CPU util. (%) 1.45 10.54 25.62 48.75
Memory (MB) 111.07 112.25 109.06 110.33
Network (B/s) 740.43 919.51 1149.69 849.41
Message size (KB) 185 1850 4628 8319
No. of messages 5977 59887 149750 268887
Fig. 10 Ratio comparison of different device groups
Table 5 Results of measurements with the Thermostat template with 0.5 second frequency.
No. of devices 10 100 250 450
CPU util. (%) 2.62 21.35 50.61 87.01
Memory (MB) 109.66 110.01 109.57 110.32
Network (B/s) 1428.52 1596.71 1440.24 2820.36
Message size (KB) 369 3689 9120 16093
No. of messages 11940 119621 294587 520582
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 19
Fig. 11 Comparison of different data generation frequencies
5.4 Fourth round of evaluations
The thermostat device is just one simple thing mostly used in smart homes. Smart
cities apply a much wider set of devices, and particularly meteorological applica-
tions have a much longer history dating back to sensor networks [54]. As a result,
in the fourth round of evaluations we chose to simulate parts of the OpenWeath-
erMap service [52], which monitors weather conditions of more than 200 thousand
cities by gathering sensor data from more than 40 thousand weather stations. A
huge amount of data is publicly available at their website, therefore we downloaded
a series of monitored information for certain cities, and studied its format to cre-
ate a template for it in MobIoTSim (as discussed in Section 3). In this evaluation
round we created 10, 100, 250 and 450 devices in four groups, using the Weather
template of MobIoTSim. Since MobIoTSim is capable of loading previously saved
IoT trace data, we used this feature for loading real data provided by OpenWeath-
erMap – an example of such a sensor data is shown in Figure 12. We performed the
experiments for all device groups with 1 second frequency. The detailed results are
shown in Table 6. In order to highlight the differences of using the Thermostat and
the Weather templates, we created comparison diagrams in Figure 13 and Figure
14. The first one shows the differences of the sent message sizes, while the second
one compares the measured CPU utilization. We can observe that the Weather
template uses bigger messages, which also results in higher CPU load.
Table 6 Results of measurements with the Weather template.
No. of devices 10 100 250 450
CPU util. (%) 1.59 12.27 29.53 52.29
Memory (MB) 110.07 110.22 110.35 111.05
Network (B/s) 853.6 855.16 881.34 890.66
Message size (KB) 2468 24695 61666 111110
No. of messages 6000 60046 149940 270165
20 A. Kertesz et al.
{
"coord":{
"lon":20.15,
"lat":46.25
},
"sys":{
"type":1,
"id":5732,
"message":0.2108,
"country":"HU",
"sunrise":1489639720,
"sunset":1489682821
},
"weather":[
{
"id":800,
"main":"Clear",
"description":"Sky is Clear",
"icon":"01d"
}
],
"main":{
"temp":13,
"pressure":1019,
"humidity":35,
"temp_min":13,
"temp_max":13
},
"visibility":10000,
"wind":{
"speed":7.2,
"deg":300
},
"clouds":{
"all":0
},
"dt":1489679100,
"id":715429,
"name":"Szeged"
}
Fig. 12 Sample OpenWeatherMap data in JSON format
5.5 Fifth round of evaluations
Finally, with the fifth round of evaluations we wanted to exemplify the robustness
of the private gateway concerning the heterogeneity of the managed sensor data.
As we have seen in the previous section, we also introduced a Smart Lamp device
type (i.e template) to MobIoTSim. With the help of SUMMON, we can gather
smart lamp sensor data from the Smart City of Messina (or directly through the
SmartME website), and load it to MobIoTSim. In this final round of experiments
we used two different data formats represented by the Weather and the Smart
Lamp templates to send messages with different formats, possibly requiring differ-
ent visualization. In such cases the online chart will be refreshed each time a new
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 21
Fig. 13 Comparison of message data sizes for different device groups of the two templates
Fig. 14 Comparison of CPU utilization of the two device templates
type of sensor data arrives. To have an impression on how the extended gateway
behaves in such situations, we performed the following evaluation.
We created a group of 200 devices, and started them to load sensor data and
send them in JSON format messages to the gateway. First they were set to use
the Smart Lamp template, hence they loaded a file containing smart lamp data
from the SmartME project, and after 10 seconds of operation we switched them
to Weather templates. We continued switching in every 10 seconds, and the sim-
22 A. Kertesz et al.
ulation went on till 50 seconds. An own resource consumption monitoring script
measured the actual memory and CPU consumption every 2 seconds. The results
are depicted in Figure 15 and Figure 16, showing the CPU and memory consump-
tion respectively. From these diagrams we can conclude that each time we change
the data representation (the templates), the chart needs to be regenerated in the
gateway service, which results in additional resource consumption.
Fig. 15 CPU consumption for the private gateway in mixed use
Fig. 16 Memory consumption for the private gateway in mixed use
6 Evaluation of the multiple device simulation scalability of MobIoTSim
After evaluating the proposed private gateway performance, we continue to exam-
ine the device simulation scalability of the MobIoTSim application itself. For this
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 23
purpose we created a simplified version of MobIoTSim (called MQTTDemo), con-
taining only its core parts for device management functionalities. The screenshot
of the application is shown in Figure 17. It enables access to low-level configu-
rations, like specifying the number of threads used for managing the simulated
devices. It also collects detailed statistical information regarding the simulation
by measuring elapsed times for executing certain functions. It can be connected
to our private gateway deployed in the IBM Cloud, and can send messages to it
using the MQTT protocol. By the time we performed the evaluations, the number
of simulated devices were limited to 20 by the IBM Cloud platform.
Fig. 17 MQTT scalability testing application
In the Settings screen (as shown in Figure 17) we can define the number of
devices to be simulated, the message frequency for sensor data generation, the
number of used threads (ThreadPool) and the message type and contents. This type
24 A. Kertesz et al.
can be a simple JSON object with a random parameter, or an OpenWeatherMap
device data in JSON format describing sensor values of certain smart cities. Other
settings are hard-coded to the application for this testing, as well as the address
of the MQTT broker of the IBM Cloud service. After performing a test, the result
statistics can be accessed by pressing the STAT button.
Table 7 Device group simulation performance using different number of threads
Used Num. of Message Send Time
threads devices count time between cycles
3 10 441 405 1374
4 10 588 403 1023
6 10 610 431 991
8 10 603 435 993
12 10 610 462 999
3 15 432 406 2078
4 15 593 402 1531
6 15 863 411 1048
8 15 908 425 988
12 15 915 420 997
3 20 433 402 2766
4 20 583 401 2054
6 20 843 407 1402
8 20 1153 404 1030
12 20 1219 433 993
The screen showing statistical data has two main parts: the Settings and the
Statistics views. In the Settings view, we can find the number of used threads, the
address of the MQTT broker, the number of simulated devices, the frequency of
the messages, the generated clientID of one device, the MQTT topic where the
messages were sent, the content type and an example JSON message. The Statisti-
cal view displays the measured values, such as the duration of the simulation, the
overall messages sent, the total number of errors in the initialization, connection
or send process of the devices. It also depicts the average times of the MQTT
initialization, connection, and message send methods and the average overall time
cost of a message exchange cycle. An important measure is the real time difference
between the process cycles of a device. If the message frequency is set to 1 second
in the settings view, we should be able to verify it during testing. It can happen
that during the simulation the simulated device cannot start the message sending
method every second, because other devices hold the required resources (such as
the CPU). As a result, the average time for creating a randomly generated message
is also measured.
The evaluation was performed with a Samsung S5 device, and a node.js vi-
sualization gateway application running in the IBM Cloud. The Samsung S5 was
released in 2014 having Snapdragon 801, Quad-core 2.5 GHz processor, 2 GB RAM
and the OS is Android 4.4. The most informative measurements were made with
1 sec message frequency, simulating 10 to 20 devices and using 3 to 12 threads.
The message contents were five randomly generated values in a JSON object (ac-
cording to the Weather template). The duration of performing a test is around
one minute.
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 25
The executed test results showed that the random data generalization con-
sumed an almost negligible time, so it did not interfere with the simulation. First,
we started using three threads, because Samsung S5 has four cores, but from the
results shown in Table 7 we can see that the number of threads is an important
factor. With 10 simulated devices three threads had difficulties to cope with si-
multaneous message sending, they required almost 1.5 seconds for the devices to
start a message sending cycle again, instead of the one second given in the settings
(see Figure 18). The figure shows the number of threads used on the x axis, the
number of sent messages with blue and the time between cycles (in ms) with red
color. When the red and blue lines become horizontal, the number of used threads
are high enough to perform the required tasks. As we can see from the results, four
threads are eligible to solve the problem. If the number of simulated devices grow,
obviously more threads are needed to manage them. To manage 15 devices, four
threads are few, but six threads would be enough to perform well. This fact can
be seen in Figure 19, where the blue line represent the number of sent messages,
and the red line denotes the time spent between the sending cycles. To manage 20
devices, we can see that six threads were too few for the acceptable performance,
therefore we had to use eight threads instead (as shown in Figure 20).
Fig. 18 Number of sent messages and time between send cycles with 10 devices
We also made additional experiments to find out the limits of MobIoTSim
using 20 simulated devices. The minimum time required to send a message is
around half a second in general. For lower frequency (e.g. 0.25 second), there is no
difference in the measured time even by using 16 threads as Figure 21 suggests. To
conclude these experiments we can state that our proposed simulator can send a
total number of 2300 messages in a minute with 20 registered devices to the IBM
Cloud.
7 Conclusion
In the phase of the latest Internet evolution, a high number of powerful devices
appeared on the network, which led to the birth of the IoT paradigm. As a result,
26 A. Kertesz et al.
Fig. 19 Number of sent messages and time between send cycles with 15 devices
Fig. 20 Number of sent messages and time between send cycles with 20 devices
cloud technology providers responded to this trend, and broadened their services
to attract users of IoT applications. In this new world, IoT developers are facing
many challenges: they need to purchase smart devices, to design and build-up a
network of these components, to develop IoT applications, to test and evaluate
these applications on the created system and finally, to fine-tune the applications
based on the evaluation results.
In this paper we provided means to overcome some of these challenges. We de-
veloped a complex, semi-simulation environment composed the following tools: an
Android-based, mobile device simulator called MobIoTSim capable of simulating
up to hundreds of IoT devices, a customizable cloud gateway service that is able to
manage the simulated devices, and an IoT trace archive service called SUMMON,
which can be used to gather real-world sensor data to be fed to the simulation
experiments. We exemplified the usage of this complex simulation environments,
and evaluated its device management scalability and responsiveness.
We do believe that these tool can contribute to a more cost efficient IoT system
development and evaluation, and we will continue the enhancement of these tools.
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 27
Fig. 21 Results with 0.5 and 0.25 second frequency
In our future work we plan to further generalize our gateway service with incor-
porating provider-independent MQTT brokers, as well as we plan to add device
templates to MobIoTSim targeting additional IoT application fields. Finally, we
will extend SUMMON with additional real world sensor datasets.
8 Acknowledgment
This research was supported by the Hungarian Government and the European
Regional Development Fund under the grant number GINOP-2.3.2-15-2016-00037
(Internet of Living Things). This paper is a revised and extended version of the
conference papers presented in [58] and [59].
This paper described the behavior and features of MobIoTSim version 1.3. Its
source code is open and available here: https://github.com/sed-szeged/MobIoTSim
References
1. A. Kertesz, Characterizing cloud federation approaches. In: Cloud computing: challenges,
limitations and R&D solutions. Computer communications and networks. Springer,
Cham, pp. 277-296.
2. A. V. Dastjerdi, R. Buyya, Fog Computing: Helping the Internet of Things Realize Its
Potential. Computer, vol. 49, pp. 112-.116, Aug. 2016. doi:10.1109/MC.2016.245
3. J. Mahoney and H. LeHong, The Internet of Things is coming, Gartner report. Online:
https://www.gartner.com/doc/1799626/internet-things-coming, September 2011.
4. J. Gubbi, R. Buyya, S. Marusic, M. Palaniswami. Internet of Things (IoT): A vision,
architectural elements, and future directions. Future Generation Computer Systems, Vol-
ume 29, Issue 7, pp. 1645–1660, September 2013.
5. H. Sundmaeker, P. Guillemin, P. Friess, S. Woelffle. Vision and challenges for realising the
Internet of Things. CERP IoT – Cluster of European Research Projects on the Internet
of Things, CN: KK-31-10-323-EN-C, March 2010.
6. M. Mukherjee et al., Security and Privacy in Fog Computing: Challenges. IEEE Access,
vol. 5, pp. 19293-19304, 2017. DOI: 10.1109/ACCESS.2017.2749422
7. A. Celesti, M. Fazio, M. Giacobbe, A. Puliafito, and M. Villari, Characterizing Cloud Fed-
eration in IoT. IEEE 30th International Conference on Advanced Information Networking
and Applications Workshops - Workshop on Cloud Computing Project and Initiatives,
2016.
8. G. Sperb Machado, D. Hausheer, and B. Stiller, Considerations on the Interoperability of
and between Cloud Computing Standards. In 27th Open Grid Forum (OGF27), G2CNet
Workshop: From Grid to Cloud Networks, Banff, Canada, 2009.
28 A. Kertesz et al.
9. BS. Kim, M. Aldwairi, KI. Kim, An Efficient Real-Time Data Dissemination Multi-
cast Protocol for Big Data in Wireless Sensor Networks. J Grid Computing (2018).
https://doi.org/10.1007/s10723-018-9447-1
10. V. Stankovski, R. Prodan, Guest Editors Introduction: Special Issue on Storage for the
Big Data Era. J Grid Computing (2018) 16: 161. https://doi.org/10.1007/s10723-018-
9439-1
11. P. Kacsuk, J. Kovacs, Z. Farkas, The Flowbster Cloud-Oriented Workflow Sys-
tem to Process Large Scientific Data Sets. J Grid Computing (2018) 16: 55.
https://doi.org/10.1007/s10723-017-9420-4
12. Boson NetSim Network Simulator. Online: http://www.boson.com/netsim-cisco-
network-simulator. Accessed in March, 2017.
13. QualNet communications simulation platform. Online: http://web.scalable-
networks.com/content/qualnet. Accessed in March, 2017.
14. A. Varga and R. Hornig, An overview of the OMNeT++ simulation environment. In
Proceedings of the 1st international conference on Simulation tools and techniques for
communications, networks and systems & workshops (Simutools ’08). 2008.
15. Sotiriadis, S.; Bessis, N.; Asimakopoulou, E.; Mustafee, N. Towards simulating the Inter-
net of Things. Advanced Information Networking and Applications Workshops (WAINA),
2014 28th International Conference on. IEEE, 2014, pp. 444–448.
16. Zeng, X.; Garg, S.K.; Strazdins, P.; Jayaraman, P.P.; Georgakopoulos, D.; Ranjan, R.
IOTSim: A simulator for analysing IoT applications. Journal of Systems Architecture.
Vol. 72, pp. 93-107, 2017.
17. Sotiriadis, S.; Bessis, N.; Antonopoulos, N.; Anjum, A. SimIC: Designing a new Inter-
Cloud Simulation platform for integrating large-scale resource management. Advanced
Information Networking and Applications (AINA), 2013 IEEE 27th International Con-
ference on. IEEE, 2013, pp. 90–97.
18. Moschakis, I.A.; Karatza, H.D. Towards scheduling for Internet-of-Things applications
on clouds: a simulated annealing approach. Concurrency and Computation: Practice and
Experience 2015,27, 1886–1899.
19. Silva, I.; Leandro, R.; Macedo, D.; Guedes, L.A. A dependability evaluation tool for the
Internet of Things. Computers & Electrical Engineering 2013,39, 2005–2018.
20. Khan, A.M.; Navarro, L.; Sharifi, L.; Veiga, L. Clouds of small things: Provisioning
infrastructure-as-a-service from within community networks. Wireless and Mobile Com-
puting, Networking and Communications (WiMob), 2013 IEEE 9th International Con-
ference on. IEEE, 2013, pp. 16–21.
21. Kecskemeti, G. DISSECT-CF: a simulator to foster energy-aware scheduling in infras-
tructure clouds. Simulation Modelling Practice and Theory 2015,58P2, 188–218.
22. T. Pflanzner and A. Kertesz. A survey of IoT cloud providers. In: 39th International
Convention on Information and Communication Technology, Electronics and Microelec-
tronics (MIPRO), Opatija, pp. 730–735, 2016.
23. A. Botta, W. de Donato, V. Persico, A. Pescape, On the Integration of Cloud Computing
and Internet of Things. The 2nd International Conference on Future Internet of Things
and Cloud (FiCloud-2014), August 2014.
24. S. Nastic, S. Sehic, D. Le, H. Truong, and S. Dustdar, Provisioning Software-defined
IoT Cloud Systems. The 2nd International Conference on Future Internet of Things and
Cloud (FiCloud-2014), August 2014.
25. L. D. Xu, W. He and S. Li, Internet of Things in Industries: A Survey. IEEE Transactions
on Industrial Informatics, vol. 10, no. 4, pp. 2233-2243, Nov. 2014.
26. S. N. Han, G. M. Lee, N. Crespi, N. V. Luong, K. Heo, M. Brut, P. Gatellier, DPWSim:
A simulation toolkit for IoT applications using devices profile for web services. In proc.
of IEEE World Forum on Internet of Things (WF-IoT), pp.544-547, 6-8 March 2014.
27. H. Gupta, A. V. Dastjerdi, S. K. Ghosh, R. Buyya. iFogSim: A toolkit for modeling and
simulation of resource management techniques in the Internet of Things, Edge and Fog
computing environments. Softw. Pract. Exper. 47:12751296, 2017.
28. R. N. Calheiros, R. Ranjan, A. Beloglazov, C. A. F. De Rose, and R. Buyya. CloudSim: A
Toolkit for Modeling and Simulation of Cloud Computing Environments and Evaluation
of Resource Provisioning Algorithms. Software: Practice and Experience (SPE), Volume
41, Number 1, pp. 23–50, 2011.
29. A. Markus, G. Kecskemeti, A. Kertesz. Flexible Representation of IoT Sensors for Cloud
Simulators. in proc. of 25th Euromicro International Conference on Parallel, Distributed
and network-based Processing, March 2017.
A Mobile IoT Device Simulator for IoT-Fog-Cloud Systems 29
30. G. Kecskemeti. DISSECT-CF: a simulator to foster energy-aware scheduling in infrastruc-
ture clouds. Simulation Modelling Practice and Theory, 58P2:188218, November 2015.
31. SimpleSoft SimpleIoTSimulator. Online: http://www.smplsft.com/SimpleIoT-
Simulator.html. Accessed in June, 2018.
32. Atomiton IoT Simulator. Online: http://atomiton.com/simulator.html. Accessed in June,
2018.
33. M. Chernyshev, Z. Baig, O. Bello and S. Zeadally, Internet of Things (IoT): Re-
search, Simulators, and Testbeds. IEEE Internet of Things Journal. (2017) doi:
10.1109/JIOT.2017.2786639
34. B. Kang, D. Kim, H. Choo, Internet of Everything: A Large-Scale Autonomic IoT Gate-
way. IEEE Transactions on Multi-Scale Computing Systems, vol. 3, no. 3, pp. 206–214,
2017.
35. LoRa Technology. Online: https://www.lora-alliance.org/What-Is-LoRa/Technology. Ac-
cessed in March, 2017.
36. SIGFOX. Online: http://www.sigfox.com/en/#!/connected-world. Accessed in March,
2017.
37. IBM Bluemix Platform. Online: https://console.ng.bluemix.net/. Accessed in March,
2017.
38. IBM Bluemix IoT Sensor. Online: https://developer.ibm.com/recipes/tutorials/use-the-
simulated-device- to-experience-the-iot-foundation/. Accessed in March, 2017.
39. Azure IoT Hub. Online: https://azure.microsoft.com/en-us/services/iot-hub/. Accessed
in March, 2017.
40. Colin King, stress-ng tool website. Online: https://www.mankier.com/1/stress-ng. Ac-
cessed in February, 2018.
41. Google Cloud Platform. Online: https://cloud.google.com/solutions/iot/. Accessed in
March, 2017.
42. Amazon Web Services. Online: http://aws.amazon.com/. Accessed in March, 2017.
43. Heroku. Online:https://www.heroku.com/. Accessed in March, 2017.
44. CloudFoundry. Online:http://cloudinary.com/. Accessed in March, 2017.
45. DreamFactory. Online:http://www.dreamfactory.com/. Accessed in March, 2017.
46. Kinvey. Online:http://www.kinvey.com/. Accessed in March, 2017.
47. Parse. Online: https://parse.com/products/iot. Accessed in January, 2017.
48. Nitin Naik, Choice of effective messaging protocols for IoT systems: MQTT, CoAP,
AMQP and HTTP. Systems Engineering Symposium (ISSE), 2017 IEEE International.
doi:10.1109/SysEng.2017.8088251
49. IBM IoT Foundation message format. Online: https://docs.internetofthings.ibmcloud.com/-
gateways/mqtt.html#/managed-gateways#managed-gateways. Accessed in March,
2017.
50. IBM Watson IoT Platform Quickstart application. Online:
https://quickstart.internetofthings.ibmcloud.com. Accessed in May, 2017.
51. IBM Watson IoT Platform visualization application. Online: https://github.com/ibm-
watson-iot/rickshaw4iot. Accessed in May, 2017.
52. OpenWeatherMap. Online: http://www.openweathermap.org. Accessed in March, 2017.
53. European Commission, Guidelines on FAIR Data Manage-
ment in Horizon 2020. Version 3.0, July 2016. Online:
http://ec.europa.eu/research/participants/data/ref/h2020/grants manual/hi/oa pilot/-
h2020-hi-oa-data-mgt en.pdf
54. Akyildiz IF, Sankarasubramaniam W, Su Y, Cayirci E., Wireless sensor networks: a
survey. Computer Networks 38(4): 393422, 2002.
55. T. Pflanzner, K. Zs. Leszko and A. Kertesz, SUMMON: Gathering Smart City Data to
Support IoT-Fog-Cloud Simulations. In proc. of the Third International Conference on
Fog and Mobile Edge Computing (FMEC), IEEE, 2018.
56. S. Bischof, A. Karapantelakis, C. Nechifor, A. Sheth, A. Mileo, P. Barnaghi, Semantic
Modeling of Smart City Data. In proc. of W3C Workshop on the Web of Things: Enablers
and services for an open Web of Devices, Berlin, Germany, 2014.
57. D. Bruneo, S. Distefano, F. Longo, G. Merlino and A. Puliafito, Turning Messina into a
Smart City: The #SmartME Experience. In: Stratigea A., Kyriakides E., Nicolaides C.
(eds) Smart Cities in the Mediterranean. Springer, Cham, 2017. doi: 10.1007/978-3-319-
54558-5 6
58. T. Pflanzner, A. Kertesz, B. Spinnewyn, S. Latre. MobIoTSim: Towards a Mobile IoT
Device Simulator. In: 2016 IEEE 4th International Conference on Future Internet of
Things and Cloud Workshops (FiCloudW), pp. 21–27, 2016.
30 A. Kertesz et al.
59. T. Pflanzner, A. Kertesz, A Private Gateway for Investigating IoT Data Management.
In proc. of the 8th International Conference on Cloud Computing and Services Science,
vol. 1, pp. 526-532, SCITEPRESS, 2018.
60. Private Gateway Service for MobIoTSim. Online: https://github.com/sed-
szeged/MobIoTSimBluemixGateway. Accessed in June, 2018.
A preview of this full-text is provided by Springer Nature.
Content available from Journal of Grid Computing
This content is subject to copyright. Terms and conditions apply.