See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/349206905

An Elastic IoT Device Management Platform

Conference Paper · December 2020

DOI: 10.1109/GCAIoT51063.2020.9345907

CITATION READS
1 197

2 authors:

Rakesh Dhakshina Murthy Mingming Liu

Dublin City University Dublin City University
2 PUBLICATIONS 1 CITATION 75 PUBLICATIONS 591 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Mingming Liu on 17 April 2021.

The user has requested enhancement of the downloaded file.

 An Elastic IoT Device Management Platform
Rakesh Dhakshina Murthy Mingming Liu
School of Electronic Engineering School of Electronic Engineering
Dublin City University Dublin City University
Dublin, Ireland Dublin, Ireland
[email protected] [email protected]

Abstract—With the recent advancement of technologies over networking services between the cloud layer and edge devices/
the past year, IoT has become a paradigm in which devices things. As the things are generally heterogeneous, the data
communicate with each other and the cloud to achieve various
arXiv:2010.06062v1 [cs.NI] 12 Oct 2020

produced by them are also diversified in those scenarios where

applications in multidisciplinary fields. However, developing,
deploying, and experimenting with IoT applications are still interoperability and transcoding can be tedious. In this regard,
tedious, expensive, and time-consuming due to the factors like fog nodes perform a key role in time-sensitive applications.
heterogeneity of hardware and software. This is where an IoT In general, most IoT applications need to deploy both
testbed plays a vital role in aiding developers to test their appli- sensors and actuators in the fields. Before their deployment,
cations without being deploying it to the target environment. In these applications usually undergo an appropriate evaluation
this paper, we present a testbed that is scalable for heterogeneous
devices and mainly focused on a small scale and medium scale and testing by using various testing tools. For example, to
IoT application. This testbed would be best suited for testing develop a prototype of a large application involving hundreds
applications which demand robust nature, remote monitoring and of sensors and actuators may not be practical due to economic
control, incorporation of heterogeneous devices, location tracking and operational constraints, especially when a novel IoT
of devices, and easy troubleshooting with security and internet protocol is still under consideration and yet to be developed.
connectivity concerns. This testbed is also embraced with the
feature to work limit access to the internet. A detailed explanation Moreover setting up the hardware and IoT network elements in
of the design and architecture of the proposed testbed is provided. the real world is much challenging and often requires expertise
We also present a conceptual prototype of the testbed and the knowledge in a particular domain. In order to minimize the
results obtained on experimenting under various conditions. expenditure and time for setting up the application, developers
Index Terms—IoT, Testbed, Edge Computing, Fog Computing usually prefer testbed to test the IoT applications before actu-
ally implementing it. In this regard, an IoT testbed serves as a
platform for carrying out numerous relentless, transparent, and
I. I NTRODUCTION
repetitive testing of IoT applications in different environments
With recent advancements in the fourth industrial revolution, [7], [8]. IoT testbeds are usually designed for the following
individuals and organizations, embedded devices have shown proposes: 1) To verify the development of the prototype; 2)
a renewed interest towards the Internet of Things (IoT) where To verify the operational stability; 3) To perform the test on
millions of heterogeneous devices or things are interconnected. communication protocols and load; 4) To verify the speed
These devices collect real-world data and exchange them over of communication and processing; and 5) To verify field
the network [1]. IoT aims to create a smart environment by demonstration (practical test run) [9].
making use of the smart things/devices which has sensory and Many testbeds have been developed previously targeting
actuating capabilities and transmit the fetched data via the different IoT applications (small scale, medium scale, and
internet. These data could be used in several domains such as large scale). In this paper, we discuss the testbed we devel-
energy management, vehicles, transportation, building automa- oped, capable of integrating a large number of heterogeneous
tion, health care, logistics, power plants, among others [2]–[5]. things/devices and suitable for small and medium scale appli-
It appears that things which are connected to the IoT network cations supporting various protocols. The proposed testbed has
are typically heterogeneous and can generate enormous un- a unique feature of working under an internet-less environment
precedented and unorganized data flows, especially for time- and considers to have good robustness. In addition, our testbed
sensitive applications. The difficulty in handling the data could also comes with a user-friendly GUI support. Both features are
be addressed by implementing suitable middle-ware between seen as the contributions to the paper. The rest of the paper
things and cloud serving as a platform for data processing is organized as follows. related works in the literature are de-
and communication among things as well to the adjacent scribed in Section II. The overall explanation of the testbed are
IoT layers facilitated with interfaces, operating systems, and discussed in Section III along with the design procedures and
suitable architecture. Thus, fog nodes come into the picture to implementation of the prototype in the subsections. Section
complement the toils in IoT [6]. Fog nodes are also present at IV presents the results of the experimentations conducted on
the edge of the network but establishing a group of network the testbed under different circumstances. Finally, the paper is
resources capable of performing the computation, storage, and concluded in Section V with future scopes.
 II. R ELATED W ORK E. SmartICS
With the advancement in the latest IoT technologies, there This testbed model mainly focuses on smart buildings and
is a demand for solutions that require real experimentation campuses. The testbed primarily makes use of hundreds of
for their validation. Several experimental testbeds have been indoor environmental sensors, which can be used to actively
developed over the past years providing multiple services and capture a number of sensor reading quantities related to air
testing solutions. quality, ambient environment, energy consumption and desk
occupancy. This testbed has been deployed in the institute of
A. FIT loT-LAB the communication system at the University of Surrey. The
This test platform has about 2728 low-power wireless nodes researchers make use of two open plane floor on which their
and 117 mobile robots. They mainly experiment on wireless devices are fixed on an office floor. The sensor data directly
IoT technologies over a large scale from primitive protocols to goes to the testbed and is monitored over the application. They
advanced internet services. They also offer multi-user scientific are best suited for limited coverage of the area [14].
tools that are open source. They are deployed across 6 sites
each site having different hardware and software capabilities. III. T HE P ROPOSED I OT M ANAGEMENT P LATFORM
These sites are interconnected by a common web portal, Our proposed testbed is capable of incorporating hundreds
CLIs, and rest APIs. As a result, a heterogeneous testing of fog nodes and thousands of heterogeneous edge devices and
environment is created. “FIT IoT-LAB” makes use of open- manage them jointly under a common platform. Edge devices
source to manage their backend operations [10]. are usually sensors or actuators which can be easily controlled
by microcontrollers. Smart devices such as Raspberry Pi, Bea-
B. SmartSantander glebone, capable of running OS are chosen as fog nodes. The
The SmartSantander testbed is an advanced testbed which fog node application is deployed on the chosen smart device.
has a large platform and can be used to test entire smart city Fog nodes communicate with the edge node by embedded
services and applications. It is targeted for more than 20000 protocols like GPIO, Bluetooth, Wifi, UART/USART, I2C. All
network nodes and these nodes are termed as “service nodes”. required computations are carried out in the fog node. The fog
These nodes produce data that can be configured only by the nodes are connected to the cloud via a gateway which is, in
testbed administrators. The end-user does not have access to turn, connects to the internet. Appropriate cloud application is
reprogramming the nodes. However, some nodes with fewer developed to store the data from the edge devices and instruc-
battery constraints are allowed to be programmed by the user tion for the edge devices in their respective cloud database.
allowing the user to test their protocols. IoT and smart city Testbed management program, which is the key application,
applications are the main targets of the testbed [11]. is software that could be easily installed on the PC or Laptop.
This software is user friendly and comes with catchy GUIs to
C. Smart CCR IoT facilitate simplified user interaction. Once the physical IoT set
It is a conceptual framework still under development at the up is done all the active network elements could be controlled,
Pheonix metropolitan area aimed at Smart Campus, Cities, monitored, tracked, and logically connect and disconnect from
and Regions (Smart CCR). This testbed aims to carry out the the IoT application via testbed application. This testbed is also
functioning of the motorization of blue light safety pole on capable of working in an offline mode i.e. with no access to
ASU campuses. Each pole module is equipped with a smart the internet [15].
data collection unit that can interface with other sensors. The
main target of the testbed is to establish a large scale data A. Design and Architecture
collection and processing point for future IoT applications Our IoT testbed is designed to have five stacked layers
[12]. arranged as shown in the Fig. 1. Each layer plays a specific
role in the functioning of the testbed.
D. AssIUT IOT Layer 1: Edge Layer This layer consists of the edge
The AssIUT IOT is a remotely accessible testbed and it devices namely sensors and actuators which measures and con-
is based on a five-layer architecture, namely the things layer, trols the physical parameter of the environment. The desired
sensor layer, nodes layer, communication layer, and the cloud edge devices are selected according to the requirement of the
layer. This testbed is widely heterogeneous and capable of IoT application and are integrated with the fog nodes. These
incorporating billions of edge devices. This testbed is very edge devices are generally heterogeneous and the generated
complex and requires knowledge in multiple domains to test heterogeneous data are sent to the second layer.
IoT applications. AssIUT IoT testbed is mainly designed Layer 2: Fog Layer This is the second layer of the
for students and young researchers and it aims to provide testbed. This layer includes the number of distributed fog
sufficient education tools to help them better understand the nodes. To increase efficiency of an IoT system, data from
IoT concepts to build novel IoT application and projects. The edge layers are processed locally and only the processed data
testbed mainly makes use of hardware components that can are transmitted to the cloud infrastructure or to other IoT
be easily accessible in local markets, and thus it is handy for node elements. This helps in reducing the consumption of
local researchers to implement the testbed [13]. the bandwidth as well as the response latency. Fog nodes are
 could be controlled and monitored via this layer remotely. Our
testbed application retrieves and sends data and instructions
to the cloud database. Other testbed features could be used
in this layer. For the testbed to work under the offline mode,
it is advised to connect the host machine running the testbed
application and the fog nodes to a common gateway.
With these layers in place, the architecture of the proposed
testbed is shown in Fig. 2. The testbed operation flow starts
with the edge node where the data are sent to their respective
fog node for processing. The processed data are sent to the
cloud via a gateway and simultaneously instruction stored in
the cloud for the fog nodes is retrieved. The testbed application
constantly pulls data from the cloud and also updates instruc-
tions to the cloud. Under offline mode or sudden failure of the
internet connection, the testbed application directly connects
to the fog nodes and fetches data from them, and sends the
instructions, provided that the host machine and the fog nodes
Fig. 1. Illustrating multiple layers of a complete IoT system. are connected to the common gateway.
B. Implementation of the Prototype
designed as smart devices capable of performing computation, In this section, the implementation of the testbed prototype
communication, and storage. Fog nodes can communicate is discussed in the order of the layers. This prototype is
with the edge devices using different embedded protocols designed to have one fog node and four edge node. The
including such as Bluetooth, I2C, SPI and WiFi. Fog nodes physical setup of the prototype is shown in the Fig. 3. We shall
are programmed to carry out three important functions, namely first start with the hardware development of the prototype and
processing the data from their respective edge nodes, sending then discuss the associated software development part.
the computed data to the Cloud layer via the communication Hardware Development:
layer, and receiving instructions over the communication layer Layer 1 : Four edge devices chosen for the prototype are
and function accordingly. two DHT-11 sensors, one DS3231 RTC, and a piezoelectric
Layer 3: Communication Layer This layer acts as a buzzer. DHT-11 is a well-known, low cost and low power
transport layer. The router is the best-opted device for this enabled temperature and humidity sensor. It is a capacitive
role. This layer connects the fog nodes to the internet and for- humidity sensor which acts as a thermistor and measures
wards the appropriate data to the cloud by following relevant the surrounding air’s temperature and humidity. It can be
protocols and internet standards. Communication between the energized by supplying a voltage of 3.3V. For data transmis-
gateway and the edge devices is usually low power enabled sion it makes use of single wire digital protocol transmitting
and low rate communication whereas communication with digital data. This sensor was selected because of its worldwide
the cloud demands high-speed connectivity. For this purpose, availability, robustness, and easy to handle. DS3231 is a
a gateway is also embedded with different protocols such CMOS battery-powered Real-Time Clock (RTC). The DS3231
as HTTP/HTTPs, CoAp, MQTT, WebSockets, AMQP, and has been chosen for its high accuracy. It is a RTC that keeps
XMPP [16]. time to ±63 seconds per year (i.e., ±2ppm at 0°C–50°C), and
Layer 4: Cloud Layer The Cloud layer can be accessed it is widely available in module form at very low cost. It
remotely and it can be used to maximize the resource usage. transmits data using I2C or SPI protocol to the controller. The
One of the key functions of the cloud layer is for large data role of RTC in this testbed is to keep track of the timestamp
storage. Cloud application receives all the data from the fog at which the sensor data are uploaded as well as to maintain
nodes and stores them in an organized fashion (e.g. Table). a local clock. A piezoelectric buzzer is a simple electronic
These data are further retrieved from the cloud upon request device that produces sound or tone when powered and acts as
when desired for further operations. A cloud application also an actuator (alarm). The intensity of the sound increases with
receives instructions from the application layer and maintains the increase with the power supplied to the buzzer. The power
a separate database for the instructions and the details about rating ranges from 3.3v to 9V.
the fog nodes and their respective edge nodes. Layer 2 : For the development of the prototype Raspberry
Layer 5: Application Layer The application layer sits on Pi 3 is selected as a fog node. It is a credit card-sized computer
the top of other layers and it is responsible for the human that has 1.2 GHz ARM Cortex-A53 CPU supporting 64bits
interaction facility. It is designed as a software that could architecture with a 32GB SD card enabled storage feature. It
be installed over any PC/Desktop or Laptop. It serves as a has four USB ports, one HDMI port, and one ethernet port.
platform where the IoT application could be tested. All the Basic accessories like monitor, keyboard, and mouse could
sensors and actuators connected to the IoT application network be connected. It supports Debian and has interface options
 Fig. 2. Architecture and Components of elastic IoT device management platform.

for fog node is developed by using python programming

languages and AWS boto3 services. This application is later
deployed on the fog node.
Layer 4 : For the cloud set-up, AWS is used. In particular,
the AWS DynamoDB service is used to create a database
table for storing the data and instruction of the edge devices
and fog nodes. Amazon DynamoDB provides predictable and
high speed performance with seamless scalability. It is a fully
managed NoSQL database service.
Layer 5 : The testbed application is a software developed to
aid the users for efficient handling of the testbed. This testbed
software is developed using python programming language
and later converted into an executable file. Some important
frameworks used in the development are boto3 and Tkinter.
Boto3 is an SDK developed by AWS for easy implementation
and management of AWS services using python. Tkinter is a
python building tool for GUI. Tkinter calls are translated into
Tcl commands which are fed to this embedded interpreter, thus
making it possible to mix Python programming language and
Fig. 3. Physical setup of the prototype. Tcl in a single application.
IV. E XPERIMENTATION AND O BSERVATION
like GPIOs, SPI, UART, I2C, and built-in Wifi support. The This section discusses the behaviour of the testbed under
edge nodes are connected to the fog node using the interface different experimental scenarios demonstrating the key fea-
options. The Wifi support is used to connect the fog node to tures of the proposed testbed compared to others. The below
the gateway which access to the public internet. figure shows the interface of the testbed software.
Layer 3 : In this prototype, TP-LINK’s TL-WA850RE, a A. Overall description of the testbed
Wifi extender connected to a router with an internet connection Different user interfaces of the proposed testbed application
is used as a gateway. It has an Ethernet port that allows the are shown in Fig. 4.
TL-WA850RE to act as a wireless adapter to turn a wired • General information about the user and the application
device into a wireless one. being tested and the field of test area are displayed under
Software Development: the info panel.
Layer 2 : Raspberry Pi is used as a fog node with Raspbian • The health of all the network elements and fog nodes
OS. AWS SDK is installed on the fog node device. Firmware of the application is displayed in the health panel. This
 as well as to send commands to the actuators. Since the
actuator is a buzzer in our prototype set-up, a command
such as duration or tone of the buzzer can be set.
• ’Check All actuators’ button enables the user to check
simultaneously all the actuators in the field manually.

C. Failure of Edge/Fog Nodes

• There are many reasons an edge/fog node could fail
especially due to failure in power. Any failure of sensors
or actuators in the IoT network is reflected immediately
on the health panel.
• The regular functioning of the testbed is not affected
by the failure of devices. The faulty node or device is
indicated precisely along with the location on the testbed
application.
• To experiment this scenario, a faulty edge node is chosen
as sensor 1. The behaviour of the testbed is observed. The
system continues to function normally and the response
of the testbed is shown in the Fig. 5.
Fig. 4. User interface of the elastic IoT device management platform.

feature is added to ensure the proper working of the

testbed elements.
• The proposed testbed is capable of working with or
without the internet. The current network in which the
testbed works is indicated in this panel.
• The live statistical values of all the sensors used in the
application are displayed on the stats panel. Details such
as sensor id, location of the sensor, sensor reading, and
timestamp could be referred from this panel.
• Edge devices (sensors and actuators) can be controlled
by the options provided in the control panel.
Fig. 5. Testbed working with failed edge device
B. Testbed Normal Workflow
• Under the normal working condition, the live data from
the sensors could be monitored on the stats panel along D. Testbed in Offline Mode
with the location and timestamp. • This unique feature could be useful in a situation where
• The sensors could be identified by using their respective proper internet could not be provided to the fog node or
sensor id. the host machine running the testbed application.
• Under the control panel, sensors could be logically con- • Fog node firmware is developed in such a way each fog
nected or disconnected from the network by clicking on node acts as an individual server and the testbed applica-
the ’On/Off’ button. tion behaves as a client. By using a socket communication
• The user is also provided with an option to set an ideal protocol, the fog node and the machine running the
working range for the sensor. When the sensor reading testbed application are connected to a common gateway
exceeds the pre-defined limit, the respective indicator of through which the application sends and receives data to
the sensor turns red from green indicating abnormality. and from the fog node in the form of a data stream.
• Provision is provided to modify the frequency at which • When this feature is enabled, it is indicated in the network
the sensors pushes data to the cloud. panel.
• The user is also provided with an additional feature of • In case of a sudden failure of the internet connectivity of
sending E-mail to the operator when the sensor exceeds the fog node or testbed application, the testbed immedi-
the limit. This could be enabled by checking the ‘send ately switches to offline mode and continues its working,
E-mail’ checkbox. provided they are connected to the common gateway. This
• When the sensor exceeds the limit appropriate actuators feature increases the robustness of the testbed. If not, then
are automatically turned on. Under the actuator section, the appropriate failure reason is indicated on the health
features are provided to turn on the actuator manually panel.
 • To further experiment this feature, the internet connec- components making it very reliable and realisable with a better
tivity to the gateway is disconnected. As can be seen in interface when compared to other developed testbeds in the
Fig. 6, the testbed immediately shifts to the offline mode literature. As part of our future work, this testbed could be
and the testbed application continues to interact with the further improvised to adopt a machine learning model which
fog node flawlessly. can provide predictive analysis of the sensors in real time.
ACKNOWLEDGEMENT
The authors acknowledge the support from the School of
Electronic Engineering at Dublin City University to conduct
this project.
R EFERENCES
[1] I. Bisio, C. Garibotto, A. Grattarola, F. Lavagetto, and A. Sciarrone,
“Exploiting context-aware capabilities over the internet of things for
industry 4.0 applications,” Ieee network, vol. 32, no. 3, pp. 101–107,
2018.
[2] Y. Gu, E. Crisostomi, M. Liu, and R. Shorten, “Identification of new
patterns in urban traffic flows,” in 2018 IEEE Conference on Control
Technology and Applications (CCTA). IEEE, 2018, pp. 626–631.
[3] Y. Gu and M. Liu, “A fair and privacy-aware ev discharging strat-
egy using decentralized whale optimization algorithm,” arXiv preprint
Fig. 6. Testbed working in offline mode. arXiv:2004.05280, 2020.
[4] Y. Gu, M. Liu, J. Naoum-Sawaya, E. Crisostomi, G. Russo, and
R. Shorten, “Pedestrian-aware engine management strategies for plug-in
hybrid electric vehicles,” IEEE Transactions on Intelligent Transporta-
E. Unauthorized User Access tion Systems, vol. 19, no. 1, pp. 92–101, 2017.
• As aforementioned, the testbed can work both with only [5] M. Liu and S. McLoone, “Enhanced aimd-based decentralized residen-
tial charging of evs,” Transactions of the Institute of Measurement and
local networks and with the internet, thus it is possible Control, vol. 37, no. 7, pp. 853–867, 2015.
for unauthorized users to breach into the system. [6] A. Farahzadi, P. Shams, J. Rezazadeh, and R. Farahbakhsh, “Middleware
• As a preventive measure, the fog node’s firmware is technologies for cloud of things: a survey,” Digital Communications and
Networks, vol. 4, no. 3, pp. 176–188, 2018.
programmed in a way that any external client tries to [7] M. Chernyshev, Z. Baig, O. Bello, and S. Zeadally, “Internet of things
access the fog node number of active clients changes. (iot): Research, simulators, and testbeds,” IEEE Internet of Things
Any anonymous user trying to break into the system can Journal, vol. 5, no. 3, pp. 1637–1647, 2017.
[8] B. Gupta and M. Quamara, “An overview of internet of things (iot):
then be detected immediately. Architectural aspects, challenges, and protocols,” Concurrency and
• Additionally, all data transfer using the testbed is en- Computation: Practice and Experience, p. e4946, 2018.
crypted and protected with an encryption key. [9] M. Okuda, T. Mizuya, and T. Nagao, “Development of iot testbed using
opc ua and database on cloud,” in 2017 56th Annual Conference of the
• Cloud level security features are provided by AWS ser- Society of Instrument and Control Engineers of Japan (SICE). IEEE,
vices. DynamoDB encrypts at rest all user data stored in 2017, pp. 607–610.
tables, indexes, streams, and backups using encryption [10] C. Adjih, E. Baccelli, E. Fleury, G. Harter, N. Mitton, T. Noel,
R. Pissard-Gibollet, F. Saint-Marcel, G. Schreiner, J. Vandaele et al.,
keys stored in AWS Key Management Service (AWS “Fit iot-lab: A large scale open experimental iot testbed,” in 2015 IEEE
KMS). This provides an additional layer of data protec- 2nd World Forum on Internet of Things (WF-IoT). IEEE, 2015, pp.
tion by securing users’ data from unauthorized access to 459–464.
[11] L. Sánchez, V. Gutiérrez, J. A. Galache, P. Sotres, J. R. Santana,
the underlying storage. J. Casanueva, and L. Muñoz, “Smartsantander: Experimentation and ser-
vice provision in the smart city,” in 2013 16th International Symposium
V. C ONCLUSION on Wireless Personal Multimedia Communications (WPMC). IEEE,
2013, pp. 1–6.
In this paper, we presented a general overview of our [12] A. J. Raglin, D. Huang, H. Liu, and J. McCabe, “Smart ccr iot:
proposed testbed, which serves as an elastic platform for Internet of things testbed,” in 2019 IEEE 5th International Conference
heterogeneous devices mainly focused on experimenting and on Collaboration and Internet Computing (CIC). IEEE, 2019, pp. 232–
235.
developing IoT applications. Hardware and software architec- [13] M. AbdelHafeez and M. AbdelRaheem, “Assiut iot: A remotely acces-
ture have also been discussed for the prototype developed. sible testbed for internet of things,” in 2018 IEEE Global Conference
This testbed could be used for small scale and medium scale on Internet of Things (GCIoT). IEEE, 2018, pp. 1–6.
[14] L. Sánchez, J. Lanza, J. R. Santana, R. Agarwal, P. G. Raverdy,
applications mainly for developing IoT protocols. This testbed T. Elsaleh, Y. Fathy, S. Jeong, A. Dadoukis, T. Korakis et al., “Federation
does not require the internet every time for its functionality of internet of things testbeds for the realization of a semantically-enabled
and its very robust. This testbed could also be shared by multi-domain data marketplace,” Sensors, vol. 18, no. 10, p. 3375, 2018.
[15] G. Sasirekha, T. Adhisaya, P. Aswini, J. Bapat, and D. Das, “Challenges
multiple users simultaneously in a secure way and capable of in the design of an iot testbed,” in 2019 2nd International Conference
withstanding high load. Tangible results obtained from running on Intelligent Communication and Computational Techniques (ICCT).
the prototype of the testbed are also shown and discussed in IEEE, 2019, pp. 14–19.
[16] J. Krishnan and S. K. Vasudevan, “An extensive survey on iot smart
this paper. The proposed testbed shows high robust behaviour gateways, software architecture, related protocols and challenges,” in
and very low possibilities of failure even under the internet 2019 International Conference on Vision Towards Emerging Trends in
failure. It has a simple yet an efficient architecture and Communication and Networking (ViTECoN). IEEE, 2019, pp. 1–6.

View publication stats