Embed Size (px)
Citation preview
The IoT Architectural Framework, Design Issuesand Application Domains
Gordana Gardasevic1 • Mladen Veletic1 • Nebojsa Maletic2 •
Dragan Vasiljevic1 • Igor Radusinovic3 • Slavica Tomovic3 •
Milutin Radonjic3
Published online: 25 October 2016� Springer Science+Business Media New York 2016
Abstract The challenge raised by the introduction of Internet of Things (IoT) concept will
permanently shape the networking and communications landscape and will therefore have
a significant social impact. The ongoing IoT research activities are directed towards the
definition and design of open architectures and standards, but there are still many issues
requiring a global consensus before the final deployment. The paper presents and discusses
the IoT architectural frameworks proposed under the ongoing standardization efforts,
design issues in terms of IoT hardware and software components, as well as the IoT
application domain representatives, such as smart cities, healthcare, agriculture, and nano-
scale applications (addressed within the concept of Internet of Nano-Things). In order to
obtain the performances related to recently proposed protocols for emerging Industrial
Internet of Things applications, the preliminary results for Message Queuing Telemetry
& Gordana [email protected]
Mladen [email protected]
Nebojsa [email protected]
Dragan [email protected]
Igor [email protected]
Slavica [email protected]
Milutin [email protected]
1 Faculty of Electrical Engineering, University of Banja Luka, Banja Luka, Bosnia and Herzegovina
2 IHP, Im Technologiepark 25, 15236 Frankfurt (Oder), Germany
3 Faculty of Electrical Engineering, University of Montenegro, Podgorica, Montenegro
123
Wireless Pers Commun (2017) 92:127–148DOI 10.1007/s11277-016-3842-3
Transport and Time-Slotted Channel Hopping protocols are provided. The testing was
performed on OpenMote hardware platform and two IoT operating systems: Contiki and
OpenWSN.
Keywords Internet of Things (IoT) � Architectural framework � Applications � IndustrialIoT � MQTT � TSCH � OpenMote platform
1 Introduction
The Internet of Things (IoT) has been denoted as a new wave of information and com-
munication technology (ICT) advancements. The IoT is a multidisciplinary concept that
encompasses a wide range of various technologies, device capabilities, application
domains, different business and operational strategies, industry and market profiles, etc.
[1–3]. ITU-T Study Group 13 has defined the IoT as: ‘‘A global infrastructure for the
information society, enabling advanced services by interconnecting (physical and virtual)
things based on existing and evolving interoperable information and communication
technologies’’ [4]. This definition implies the significance of IoT vision and its impact on
future social, networking and communications landscape.
The number of IoT applications and scenarios is growing day by day and is influencing
our everyday life. They can be categorized into application domains, such as smart cities
and environments, smart grids, industrial automation, traffic management and logistics,
remote monitoring, healthcare and assisted living, agriculture and breeding, public safety,
and others. Recently, the concept of Internet of Nano-Things (IoNT) has been proposed in
order to provide the support for interconnecting the nano-scale devices to IP networks.
Therefore, we can think of IoT as a fuzzy and multi-tiered heterogeneous system based on
open architectural platforms and standards.
Smart objects or things are physical devices (i.e., sensors, actuators, RFID tags, mobile
phones, etc.) or virtual entities with capabilities to cooperate and interact within the IoT
infrastructure. The IETF gives the following definition of term ‘‘things’’: ‘‘In the vision of
IoT, ‘things’ are very diverse, such as computers, sensors, people, actuators, refrigerators,
TVs, vehicles, mobile phones, clothes, food, medicines, books, etc. These ‘things’ should
be identified at least by one unique way of identification for the capability of addressing
and communicating with each other and verifying their identities. In here, if the ‘thing’ is
identified, we call it the ‘object’’’ [5].
The aforementioned nature of IoT indicates that a single reference architecture cannot
be applied for majority of scenarios. It is of a particular importance to build the IoT
ecosystem in a way to support the standardized IoT reference models and architectures.
Although there are plenty of different scenarios and solutions, several common charac-
teristics can be extracted: modularity and interoperability of IoT components, open models
and architectures, flexible service compositions, integrated security solutions, semantic
data integration, etc.
There is an intensified effort regarding development of architectural frameworks and
solutions, such as the IEEE model, the ITU-T model, the NIST model for Smart Grid, the
ETSI model for SmartM2M communications, the Architectural Reference Model from the
EU IoT-A project, as well as other related work, such as the IETF, W3C, OASIS, IPSO
128 G. Gardasevic et al.
123
Alliance, etc. [6]. The IoT related research has been selected as a topic of prime importance
within the scope of Horizon 2020 priorities and EU 2020 Digital Agenda.
The wireless embedded devices require a new generation of communication protocols in
order to be fully integrated into Future Internet infrastructure. These constrained devices
form the Low-Power and Lossy Networks (LLNs) that are connected by wireless, unre-
liable and error-prone links with restricted frame-sizes and low throughput [7]. Therefore,
the design of energy-efficient protocols and mechanisms remains one of the key goals in
creating the reference IoT protocol stack.
The IoT Operating Systems (OSs) are designed to run on devices with constrained
resources and limited functionalities. Therefore, the middleware, data management and
application programming interfaces (APIs) represent some of key design elements in IoT
architecture. The actual research in this field is related to support for real-time analysis,
policy-based access control, user-data management, context-based monitoring and secu-
rity, integration support, and others.
The rest of this paper is structured as follows. Section 2 describes the ongoing stan-
dardization efforts and general IoT reference model. The prerequisites for IoT deployment
in terms of hardware and software resources are given in Sect. 3. Section 4 discusses some
of IoT application domain representatives, such as smart cities, healthcare, agriculture, and
nano-scale applications. In Sect. 5, we provide the preliminary results in testing the
OpenMote platform for Industrial Internet of Things (IIoT) applications. Finally, con-
cluding remarks are provided in Sect. 6.
2 IoT Architectural Framework
The adoption of IoT general reference model is of crucial importance in order to promote
the global IoT deployment, and proliferation of IoT applications and services. A number of
different architectural solutions have been proposed in the past few years, including not
only the international standard organisations (ITU-T, 3GPP, ETSI, ISO, IETF, IEEE, W3C,
oneM2M, OASIS, etc.), but also academia and research institutions, companies, stake-
holders, and civil societies. The industrial vision is also an important element in IoT
deployment.
The core requirements related to IoT protocol stack include low-power communication
protocols and IP-based, secure and reliable communication stack. The standardisation
bodies are addressing the issues related to interoperability of protocol stacks, the trans-
parency of open standards, interfaces, and architectures for IoT. This initiative leads
towards the creation of IoT-specific protocol stack, since there exists a plethora of wireless
protocols, such as ZigBee, IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN), WirelessHART, IEEE 802.15.4e, ISA100.11a, etc.
The essential IoT technology implemented at the physical layer is Wireless Sensor
Networks (WSNs), but other low-power technologies, such as Power Line Communica-
tions (PLC), Bluetooth Low Energy (BLE), Radio-Frequency IDentification (RFID),
Digital Enhanced Cordless Telecommunications (DECT), Ultra-Wide Bandwidth (UWB),
and Near Field Communication (NFC) are also important for the implementation of var-
ious IoT applications within specific environments and domains, as illustrated in Fig. 1 [8].
Recently, the 3GPP started the work towards standardizing the Narrow-Band IoT (NB-
IoT). The objective is to specify a radio access for cellular IoT, based on a E-UTRA variant
that addresses improved indoor coverage, support for massive number of low throughput
The IoT Architectural Framework, Design Issues and... 129
123
devices, low delay sensitivity, ultra low device cost, low device power consumption and
optimised network architecture [9].
The fundamental aspect of IoT infrastructure is the support for the global Internet
Protocol (IP) connectivity. Considering that the IoT is recognized as a Future Internet
architecture, the 6LoWPAN protocol stack has been developed to enable the full IP inte-
gration [10]. There are also other solutions, such as the ZigBee IP specification that adds
the network and security layers, as well as an application framework to the IEEE 802.15.4
standard. It supports the energy-efficient wireless mesh networking based on standard IP
protocols, such as 6LoWPAN, IPv6, RPL, UDP, TCP, Transport Layer Security (TLS), and
Protocol for Carrying Authentication for Network Access (PANA) [11].
The mechanisms at network layer are implemented by the IPv6 protocol. A represen-
tative at this layer is the Routing over Low-power and Lossy Networks (RPL) protocol,
standardized by the IETF ROLL group [12]. The RPL is a link-independent distance vector
routing protocol designed specifically for LLNs, where the connections between nodes
(routers) are lossy and with low packet delivery rates. Such networks usually do not have a
predefined topology and may deploy a large number of nodes. Correspondingly, the role of
RPL is to discover optimal links based on an established set of criteria. This protocol
supports various traffic models, such as point-to-point, point-to-multipoint, and multipoint-
to-point. The IP Security (IPSec) protocol is enabled at network layer in order to support
the secure communications. The IPv6 also provides an efficient and robust mobility
mechanism as a core of Mobile IPv6 (MIPv6) protocol.
At transport layer, two standard protocols may be used: Transmission Control Protocol
(TCP) and User Datagram Protocol (UDP). The UDP is preferably used for 6LoWPAN due
to its lightweight implementation. The flow control mechanism in TCP generates the
Fig. 1 The overview of IoT layered architecture [8]
130 G. Gardasevic et al.
123
overhead that is considered too high for LLNs. But, recently developed IoT hardware
platforms have enough memory and processing resources to support the transmission over
TCP.
An example of application layer protocol is the Constrained Application Protocol
(CoAP) developed for LLNs [13]. The CoAP is built over UDP and therefore has a
significantly lower overhead and support for multicast transmission. As a comparison, the
HTTP relies on TCP that does not have the multicast support and is rather sensitive to
mobility. The CoAP is a request/response protocol that utilizes both synchronous and
asynchronous responses. The ZigBee Smart Energy Protocol version 2.0 (SEP 2.0) offers a
global standard for IP-based control, both wired and wireless, for energy management in
Home Area Networks and industrial automation applications [14]. SEP 2.0 is an industry
open standard, based on open technologies such as REST/HTTP and XML. The connec-
tivity protocol for IoT and Machine-to-Machine (M2M) applications is the Message
Queuing Telemetry Transport (MQTT). This lightweight protocol is designed to connect
the physical devices and networks with applications and middleware used in IT and Web
development [15]. Unlike the CoAP, the MQTT is running over TCP. Additionally, this
protocol provides three levels of Quality of Service (QoS) support for message delivery.
More details about this protocol are provided in Sect. 5.
As already mentioned, the IETF 6LoWPAN protocol family is a key enabler of IP
connectivity for low-power and constrained devices. One possible implementation of
6LoWPAN protocol stack is shown in Fig. 2. The existence of adaptation layer actually
represents the new element in comparison to standard Open Systems Interconnection (OSI)
protocol stack. This adaptation layer enables functionalities, such as header compression
and decompression, fragmentation and reassembly, address auto-configuration, as well as
the support for mesh based routing. Consequently, the transmission of IPv6 packet within
the IEEE 802.15.4 Medium Access Control (MAC) frame becomes possible. The
Fig. 2 The 6LoWPAN ProtocolStack
The IoT Architectural Framework, Design Issues and... 131
123
operations at the physical layer are defined by the IEEE 802.15.4 standard with data rate of
250 kbps, operating in 2400–2483.5 MHz Industrial, Scientific, Medical (ISM) frequency
band. The design of MAC layer still remains an open issue, especially in non-centralized
networks or networks with numerous nodes. Recently, the IEEE 802.15.4e standard has
been proposed as a MAC amendment to the existing IEEE 802.15.4-2011 standard. The
specific mode, called Time Synchronized Channel Hopping (TSCH), significantly increases
robustness against external interference and persistent multi-path fading, while running on
IEEE 802.15.4 hardware [16].
Recent advances in emerging areas such as cloud computing, autonomic computing,
social networks, etc. have changed the scope of the IoT’s convergence. Data management
is another crucial aspect in IoT. When considering a world of objects interconnected and
constantly exchanging all types of information, the volume of the generated data and the
processes involved in the handling of those data become critical. Some of the most relevant
concepts, which enable us to understand the challenges and opportunities of data man-
agement, are: data collection and analysis, big data, semantic sensor networking, virtual
sensors, and complex event processing. The concept of Software Defined Network (SDN)
has also demonstrated its potential for various IoT scenarios and applications [17]. The
integration of SDN and IoT offers a new and promising approach in designing, deployment
and monitoring of network resources and services.
3 IoT Hardware and Software Platforms
An important requirement in designing the IoT devices is related to ‘‘minimum energy’’
concept. This requirement may also be spread to general design approach in creating IoT
hardware and software components.
The IoT devices range from very lightweight sensors powered by 8-bit microcontrollers
(MCUs) to devices equipped with more powerful, but energy-efficient 32-bit processors.
These devices are based on different architectures, such as x86, MSP430, ARM7, Atmel
AVR, Cortex-M0, Cortex-M3, Cortex-M4. An IoT OS should run on various platforms,
including embedded devices as well as common PCs, and to support multiple drivers and
interfaces.
The examples of hardware platforms that support the IEEE 802.15.4 6LoWPAN con-
nectivity, are: TI CC2538 System-On-Chip (SoC) for 2.4-GHz IEEE 802.15.4-2006 and
ZigBee applications [18]; Libelium Waspmote based on ATmega1281 AVR RISC-based
MCU, with 17 different wireless interfaces including long range (3G/GPRS, LoRaWAN,
LoRa, Sigfox, 868MHz, 900MHz), medium range (802.15.4, ZigBee, WiFi) and short
range (Bluetooth 4.0, RFID, NFC), where more than 100 sensors are available to connect
to device [19]; Tmote Sky node based on TI MSP430F1611 MCU with ultra-low current
consumption and on-board humidity, temperature and light sensors, etc. [20]. The nodes
can be also divided into two groups: open-source and closed solutions. The example of
open-source node is Waspmote Pro from Libelium, the M3 open node based on a STM32
(ARM Cortex-M3) MCU. An example of a proprietary solution is, for example, MicaZ
platform [21]. The popular open-source prototyping platforms are Raspberry Pi [22],
Arduino [23], Intel Galileo [24], and BeagleBone [25]. Table 1 gives an overview of
various hardware platforms.
Software for IoT applications must support a variety of hardware platforms. Due to
memory and CPU constraints, the complexity of operations must be very low. Unlike
132 G. Gardasevic et al.
123
Table
1Specificationsofvarioushardwareplatform
s
Device
MCU
CPU
(bits)
CPU
speed
Mem
ory
Connectivity
OS
Prog.language
Open
source
No.ofsensors
Rel.
Year
TelosB
TIMSP430
16
16MHz
10KB
RAM,
48KB
flash,1MB
external
flash
802.15.4,ZigBee,
6LoWPAN
TinyOS,Contiki
nesC,C
Yes
3(relativehumidity,
temperature,light)
2005
MICAz
ATmega128L
88MHz
4KBSRAM,
4KB
EEPROM,
128KB
flash
802.15.4
TinyOS
nesC
No
Sensingavailable
via
expansionboards
2004
OpenMote
ARM
Cortex-
M3SoC
32
32MHz
32KB
RAM,
512KB
flash
802.15.4,ZigBee,
6LoWPAN
Contiki,
FreeR
TOS,
OpenWSN,
RiOT
C,Python
Yes
3(relativehumidity/
temperature,
acceleration,light)
2013
Waspmote
ATmega1281
814MHz
8KBSRAM,
128KB
flash
802.15.4,ZigBee-
Pro,WiFi,3G/
GPRS,LoRa,
Bluetooth
4.0,
RFID
,NFC
No
APIlibraries
?compiler
No
2on-boardsensors:
temperature
and
accelerometer;more
available
toconnect
2013
Raspberry
Pi
3Broadcom
BCM2837
ARMv8
64/ 32
1.2
GHz
1GB
RAM
802.11nWLAN,
10/100Ethernet,
Bluetooth
4.1,BLE
Raspbian,Debian,
Fedora,ARCH,
Linux,ARM,
FreeB
SD,
NetBSD
Python,C,
C??,Java,
Scratch,
Ruby,anyfor
ARMv6
Partial
0,sensingavailable
via
external
sensors
2016
Arduino
Uno
ATmega328
16
16MHz
1KB
EEPROM,
2KB
SRAM,32
KBflash
Wi-Fi,GSM,
Bluetooth
Arduino,Linux
C,C??
Yes
0,sensingavailable
via
external
sensors
2010
The IoT Architectural Framework, Design Issues and... 133
123
Table
1continued
Device
MCU
CPU
(bits)
CPU
speed
Mem
ory
Connectivity
OS
Prog.language
Open
source
No.ofsensors
Rel.
Year
IntelGalileo
IntelQuark
SoCX1000
32
400MHz
256MB,8
KB
EEPROM,
8MBflash
10/100Ethernet,
USB2.0
Arduino,Linux
distributionfor
Galileo
Withsupportto
GCCandICC
compilers
Yes
0,sensingavailable
via
external
sensors
2013
BeagleBone
Black
ARM
AM335x
32
1GHz
512KB
DRAM,4
GB
onboard
flash
10/100Ethernet,
USB2.0
Angstrom,Linux-
kernel
based
OSs
AnyforLinux
OS
Partial
0,sensingavailable
via
external
sensors
2012
134 G. Gardasevic et al.
123
traditional OSs, the IoT OS has to cope with many limitations and restrictions, as well as
with heterogeneity of devices. The OS for embedded devices should have the lightweight
design, thus enabling the low code size, low complexity and low power consumption. The
mature and well tested embedded OSs for WSN applications are TinyOS [26], Contiki [27]
and Linux. Recently, the FreeRTOS [28], RIOT [29], and OpenWSN [30] have been
introduced. Commercial solutions, such as Sensinode’s NanoStack (TM) 2.0 [31] and the
Thingsquare platform [32], are also available on market. In May 2015, Google announced
the Brillo OS for IoT connectivity, and the Weave, a communications standard for smart
devices [33]. Brillo will be based on the lower levels of Android, thus supporting a wide
range of hardware platforms as well as Wi-Fi and Bluetooth connectivity.
TinyOS is an embedded, component-based, and open-source OS designed for low-power
wireless devices. It is written in Network Embedded Systems C (nesC), a variant of the C
programming language. The OS has a support for both 6LoWPAN and RPL, and also have
libraries for CoAP.
Contiki is an open-source, multitasking, event-driven OS designed for networked
embedded devices and smart objects. It consists of the kernel, libraries, the program loader,
and a communication stack with device drivers for a broad range of communication
hardware. Contiki uses a subset of the C programming language, and the configuration with
full IPv6 networking requires less than 10 KB of RAM and 30 KB of ROM.
A real-time OS FreeRTOS, from Real Time Engineers Ltd., supports 35 architectures
(MCUs). FreeRTOS provides methods for multiple threads or tasks and software timers. A
tickless mode is provided for low power applications. It has a very small memory footprint,
low overhead, and fast execution. It is written mostly in C programming language.
The RIOT OS represents the new generation of IoT OSs with real-time capabilities, thus
attempting to bridge the gap between IoT and WSN. The open source RIOT code requires
less than 5 KB of ROM and less than 1.5 KB of RAM. The RIOT uses a multi-threaded
programming model in combination with standard ANSI C code and a common POSIX-
like API for all supported hardware.
The OpenWSN project is a newly released open-source implementation of a fully
standards-based protocol stack for IoT capillary networks, rooted in the new IEEE
802.15.4e TSCH standard. A variety of hardware and software platforms are supported,
thus enabling the seamless integration within the IoT environment.
4 IoT Applications
In the coming years, the number of IoT applications and services will rapidly grow. There
are many application domains that will be impacted by the emerging IoT activities. In
order to address the relevant issues and requirements, we will discuss the following IoT
application domains: smart cities, healthcare, agriculture, and nano-scale applications.
Recently, the novel paradigm of IoNT has been introduced in order to incorporate nano-
networks into existing IoT scenarios.
4.1 Smart City Applications
There are many levels of improvement where the intelligent IoT solutions can increase the
quality of everyday life in dynamic urban environments [34, 35]. The concept of smart
city, which has already been applied in Barcelona, London, Amsterdam, Singapore, etc.,
The IoT Architectural Framework, Design Issues and... 135
123
has proven its efficiency in terms of service management (e.g., energy, lighting, transport,
waste management), urban planning, traffic management, control of pollution and CO2
emissions, and so on. Many service sectors exist within this concept, like smart environ-
ment, smart governance, smart mobility, smart grid, smart utilities, smart traffic, smart
home/buildings, and others.
A novel paradigm referred as capillary network denotes the aggregated wireless con-
nectivity available in urban environment, and to provide seamless transmission from the
user terminal to access network [36].
WSN technologies enable the use of diverse sensors and actuators that must be
accessible individually, by uniquely assigned IP address. Here, devices mainly operate in
the 2.4 GHz band with data rate of 250 kbps, and sensor nodes are typically battery-
powered. The use of M2M communications for creating smart city applications allows a
plenty of user devices to exchange data seamlessly and transparently across the
infrastructure.
Several ongoing projects and campaigns are focusing on the identification of smart city
scenarios, the integration and interaction of various IoT data sources and systems, big data
representations and analytics, security and privacy issues, [37–40]. The primary goal is to
understand and model smart cities by taking into account different system topographies,
various data types, user and business preferences, etc.
One of the large-scale initiatives focused on IoT smart city applications is developed
under the FP7 SmartSantander project [41]. The infrastructure comprises of large number
IoT devices deployed in several urban scenarios, which are spread across several cities
(Guildford, Luebeck, Santander, and Belgrade). The project aims at enabling the large
scale experimentation, the analysis and evaluation of IoT concepts, under real-life
conditions.
The standardization activities in the smart city domain involves ISO/TC 268—Sus-
tainable development in communities; the ITU-T Study Group 5—Environment and cli-
mate change—Focus Group on Smart Sustainable Cities [42]; the IEEE 2030 series based
on a Smart Grid interoperability reference model (SGIRM) [43], etc.
4.2 Medical and Healthcare Applications
WSNs and Wireless Body Area Networks (WBANs) for medical and healthcare applica-
tions have received a significant attention from the research community. An efficient IoT
healthcare system aims at providing a remote monitoring of a patient health status in real
time, the prevention of critical patient conditions, life quality improvement of the elderly
through the smart environment, medical and drugs database administration, wellbeing
services, etc. [44, 45]. It is clear that the IoT networked devices will change radically the
current medical environments.
The IoT smart sensors for healthcare enable accurately measuring, monitoring and
analysing a variety of vital health status indicators, such as heart rate, ECG, blood pressure,
levels of glucose or oxygen saturation in the blood, etc. These parameters are then col-
lected and transferred to IP end-devices. Smart sensors are being assigned an unique IPv6
address for IoT connectivity.
The possibility to design and analyse a specific healthcare scenario within a simulation
platform is of a high importance [46]. The obtained results are giving the insight into the
implementation issues within the real environment. The important performance metrics
include parameters, such as robustness, accuracy and reliability, low power, durability,
136 G. Gardasevic et al.
123
data validation, etc. Choosing the right platform and infrastructure technology for a par-
ticular healthcare scenario is a crucial and necessary requirement.
The standardization activities involve ITU-T: Focus Group on M2M Service Layer with
the priority on e-health, Requirements and network capabilities for e-health monitoring
services, Multimedia e-health data exchange services: data schema and supporting services
[47]; IEEE for wireless, ZigBee Alliance, ITU-T for M2M e-Health Service Layer, Con-
tinua Alliance for Use Case profiles and best practices, NIST, as well as diverse govern-
ment initiatives, etc.
Current research activities are directed towards the design of new and innovative MCU
components, which support the modular and interoperable approach, the high-speed
interfaces, specialized processes of control and sensing, security, patient safety, etc.
Another topic of interest is the generation of clinical data through IoT devices.
4.3 Agricultural Applications
In-field monitoring and control of agriculture and food production can be significantly
improved by adopting the IoT concept [48]. Such systems should ensure the quality of
products and may improve the management and monitoring of farms. Moreover, the IoT
system for agricultural applications should provide the in-depth analysis of application’s
requirement and smart utilization of available resources. The concept of IoT smart agri-
culture is also addressing the safety of agricultural products and the exchange of infor-
mation between producers and consumers.
Research in the areas of food and agriculture has been selected as one of priority areas
in ICT research and development. For example, the FP7 OpenIoT project covers a wide
range of areas spanning: middleware for WSNs, ontologies, semantic models and anno-
tations for representing internet-connected objects, cloud computing, etc. Additionally, the
Phenonet scenario for IoT agriculture has been developed. It enables plant breeders and
farmers to compare and evaluate the performance of different wheat varieties by using the
sensor network to gather environmental data.
The Waspmote Pro platform from Libelium is the example of product that supports
various applications in this domain, such as precision agriculture for predicting vineyard
conditions, monitoring greenhouse conditions, smart farming, smart factory for reducing
the maintenance cost, etc. [49].
4.4 Nano-Scale Applications
The concept of IoNT was proposed six years ago [50] as an intuitive extension of the IoT
paradigm. Nano-Things refer to interconnected miniature devices built either by down-
scaling processes of Mico-Electro-Mechanical Systems (MEMS), e.g., electron beam
lithography [51] or micro-contact printing [52], or from scratch using nano-materials, e.g.,
graphene [53, 54]. Single nano-devices are envisioned to be embedded from intra-body to
hard-to-access areas [55]. Once interconnected, they lead to the concept of nano-networks
[56], which imply the hierarchical architecture of the IoNT: nano-networks connected to
existing communication networks and the Internet.
Nano-networks are the key feature of the IoNT concept, whose realization in particular
has many challenges starting from the communication paradigm to be used. Nonetheless,
two are identified as candidates: molecular communication [57–59] and electromagnetic
communication. Molecular communication is already a well-functioning paradigm at
atomic and molecular level developed for us by the evolution. The central nervous system
The IoT Architectural Framework, Design Issues and... 137
123
and cardiovascular system are typical representatives where the information between nano-
and micro-scale biological entities is carried via chain of chemical reactions and molecular
diffusion, calcium signalling or bacteria signalling. Molecular communication is used
among the macro-scale entities as well, e.g., animals use pheromones as messengers, which
sets this paradigm as a candidate not only for biomedical (intra-body) IoNT applications
but also for military, industrial and environmental. The challenges that remain are referred
to approaches in designing artificial nano-devices and nano-networks [56]. Electromag-
netic communication is a conventional paradigm which, however, still must be adopted for
the communication at nano-scale. Many issues are open and already identified starting
from quantum effects of nano-materials, terahertz frequency band of operation [50, 60],
channel models, information encoding, protocols for nano-networks and middleware that
connects nano-networks with conventional communication networks [55].
The IoNT offers advancements in various application fields owing to its compliance
with the IoT applications, but also enables completely new ones, e.g., those referred to the
intra-body biomedical applications, where the IoNT concept replaces the on-body wearable
devices with in-body nano-devices to advance monitoring, diagnosis and treatment through
sensing, imaging, detection and stimulation at nano-scale [61–63]. Moreover, the IoNT
offers advancements in general multimedia systems with an application in defense and
security [64], and environmental tracking and sensing [55].
5 Testing the OpenMote Platform for Industrial IoT Applications
The standardization of IIoT is still in its early stages. The main requirements relate to
operational efficiency, end-to-end automation, resource optimization, robustness and
reliability, while the key enablers are embedded sensors, cloud-based platforms, ubiquitous
connectivity, real-time analytics, etc. In this section, we will present preliminary results in
testing performances of hardware and software platforms for IIoT applications.
Recently, the OpenMote platform has drawn significant attention to research community
[65]. This platform belongs to the group of ‘‘resource-rich’’ devices as it has enough
memory and processing resources to support the TCP/IP protocol suite. The OpenMote is a
representative of new generation open-hardware platforms that is particularly adapted to
IIoT applications. This platform consists of three core elements: OpenMote-CC2538,
OpenBattery, and OpenBase, as shown in Fig. 3 (from the left-side to the right-side). The
OpenMote-CC2538 is based on TI CC2538 SoC functionalities, thus combining the 32-bit
Fig. 3 The OpenMote hardware platform [65]
138 G. Gardasevic et al.
123
ARM Cortex-M3 MCU with the IEEE 802.15.4 transceiver. The OpenBattery enables
battery-powered supply for sensor board with three digital sensors: a temperature/humi-
dity sensor, an acceleration sensor, and a light sensor. The OpenBase is the interface board
for OpenMote and provides programming and debugging capabilities. The OpenUSB
provides the USB connection for easier programming and debugging capabilities. The
OpenMote platform has 32 KB of RAM and 512 KB of flash memory, and supports several
peripherals, such as GPIOs, ADC, I2C, SPI, UART, timer modules, and AES/RSA
Encryption Engine. This platform has also a full support for Contiki OS and FreeRTOS,
and a limited support for the RIOT. The OpenWSN OS is particularly tailored to run on
OpenMote. More details about this platform can be found in [66].
The OpenMote-based IoT testbed at the premises of University of Banjaluka, Faculty of
Electrical Engineering consists of 10 motes. The block-diagram in Fig. 4 illustrates the IP
connectivity between WSN and Internet. Motes are positioned in a way to provide the
multihop communications, based on RPL routing mechanisms. One mote is configured as a
root, thus acting as a bridge between the Internet and 6LoWPAN mesh network. Motes are
marked according to hexadecimal values of the last byte of their IPv6 address. In order to
demonstrate the functionalities of different OSs on this platform, we tested both Contiki
and OpenWSN. In order to test MQTT, we have used the latest Contiki 6LoWPAN
implementation for OpenMote platform [67]. For TSCH protocol testing, we have used the
OpenWSN implementation [68].
5.1 MQTT Protocol
Both CoAP and MQTT application protocols are designed to fulfil the requirements for
M2M applications in constrained environments. They provide the application’s interface
for remote monitoring of mote’s status (e.g., temperature, humidity, acceleration, light,
voltage, RSSI). The communication model of CoAP is similar to the client/server model of
HTTP, and relays on REST architecture. This requires that the client has a knowledge of
server preferences in advance to establish a connection. In order to avoid intensive
resources required by HTTP, CoAP is preferably used in edge-based devices. As already
mentioned, CoAP runs over UDP with support to multicast addressing. Similar to HTTP,
Fig. 4 Block-diagram of OpenMote IoT testbed
The IoT Architectural Framework, Design Issues and... 139
123
CoAP provides secure communications based on Datagram Transport Layer Security
(DTLS) [69].
Unlike the CoAP, the MQTT runs over TCP/IP. This protocol has been recognized as a
particularly suitable for IIoT constrained devices and unreliable mesh networks. Due to its
lightweight realisation, the MQTT has been used in a variety of sensor networks scenarios:
home automation, telemetry, remote monitoring, alerting systems, healthcare IoT scenar-
ios, etc. In contrast to the CoAP, the MQTT uses a publish/subscribe architecture, as
illustrated in Fig. 5. The MQTT interface differs from the REST architecture in the sense
that there is a broker in between the source and the user. This type of interface requires the
devices to connect and publish data to a topic on an intermediary broker. MQTT uses SSL/
TLS protocols for secure communications [70].
For MQTT, there are a number of available brokers, both commercial and open source.
We have used the Mosquitto, an open source message broker that implements the MQTT
protocol versions 3.1 and 3.1.1 [71]. The MQTT client can be used to publish sensor
readings to an MQTT broker (Mosquitto in this case), as well as to subscribe to a specific
topic of interest and receive commands from an MQTT broker. This is particularly suit-
able for M2M messaging and IoT applications. We have tested the Contiki’s MQTT
protocol implementation on OpenMote hardware.
Figure 6 shows the status of real mote deployed in our testbed that can be monitored
remotely: sequence number, uptime, default route, RSSI, on-chip temperature, and voltage
level. After a connection between client and server is established, the first packet sent from
the client to the server is a CONNECT packet. The PINGREQ packet is sent from a client
to the server in order to indicate that the network connection is active, as well as to request
from server to confirm that it is active. In the latter case, the server will respond with the
PINGRESP packet. The delivery of application messages is performed according to the
QoS levels. The QoS level 0 indicates that the message is delivered based on the network
capabilities (best effort delivery), that is the message arrives at the receiver either once or
not at all. When using the QoS level 1, it is guaranteed that a message will be delivered at
least once to the receiver (it can be also delivered more than once). The QoS level 2
provides the highest QoS when neither loss nor duplication of messages are acceptable.
Fig. 5 Comparison of MQTT and CoAP
140 G. Gardasevic et al.
123
The selection of particular application protocol depends on IoT scenario. In case of
complex system, it is possible to use several protocols. Publish/subscribe protocols (‘‘one-
to-many’’ or ‘‘many-to-many’’ messaging distribution), such as MQTT, provide better
performances when the IoT infrastructure is not deterministic, or when the deployment
scenario is frequently changing. On the other side, client/server protocols, such as CoAP,
are more interoperable and secure since they are based on point-to-point connections. As a
consequence, the protocol scalability is lower due to the fact that point-to-point connec-
tions are more resource-demanding and more complex to manage. In contrast, pub-
lish/subscribe protocols are more scalable since the decoupling of sources and users (sinks)
allows each to be added and removed independently. In comparison to CoAP, providing
the security for these protocols is more complex task. The interoperability issues may also
appear due to the lose coupling of the source and user. The ongoing research activities
include protocol optimisation and reliable message transmission [72]. In order to overcome
some of MQTT shortcomings, the MQTT-SN protocol is proposed [73]. It specifies a UDP
mapping of MQTT and adds broker support for indexing topic names.
5.2 Testing the OpenWSN OS on OpenMote platform
The another protocol, also recognised as one of a crucial for reliable IIoT applications, is
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH). It is the MAC amendment to the
existing IEEE 802.15.4-2006. TSCH combines time slotted access, multi-channel com-
munication and channel hopping, which significantly increases the robustness against
external interference and multi-path fading. For more details about TSCH and its Open-
Mote implementation, please refer to [68].
In order to test the TSCH performances in the presence of dynamic environment and
interference from WiFi access point and signal-generator that is generated the interfering
noise, we have created the experimental platform (see Fig. 4.). Motes are positioned in a
way to form a multihop network, where the node 4F is placed nearby the WiFi access
point. The distance between the two farthest motes (4F and E3) is around 15 m.
Fig. 6 Testing the MQTT protocol for sensor’s readings
The IoT Architectural Framework, Design Issues and... 141
123
The host computer is running Ubuntu 14.04 LTS with OpenWSN and OpenVisualizer
(OV) installed. The OV creates IPv6 TUN (network TUNnel) interface that is a virtual
IPv6 interface tunnelled through the serial port. This interface enables the IPv6 commu-
nication between the host and motes’ network. OV also provides the graphical web
interface for network management purpose and various traffic and mote parameters
statistics. The mote that is directly connected to host is declared as DODAG root (C3).
Destination Oriented Acyclic Graph (DODAG) represents the hierarchical organization of
nodes in the network, based on RPL protocol specifications.
The transmit power used during experiment was 0 dBm. All motes in a TSCH network
are synchronized, where the time is divided into time slots. A slotframe consists of these
timeslots and it continuously repeats over time. Each mote follows a communication
schedule, where this schedule represents a matrix of cells. The number of cells depends on
a specific IoT application and the trade-off between latency, reliability and power con-
sumption is required. For measurement purpose, we selected the following TSCH
parameters: slotframe size ¼ 9 time slots, number of active time slots = 5, time slot length
¼ 15ms. In addition, 16 channels are available for frequency hopping. The measurements
were carried out in a way that motes are sending packets to the DODAG root. The number
of nodes that are sending the packets at the same time are 3, 5 and 7, respectively. We
performed the extensive measurements campaign. For each measurement, 1000 packets
Table 2 3 nodes; interpacket time ¼ 3000ms
Hop, node Sent packets Received packets Duplicate packets Regular packets PLR (%)
3, 4F 1000 1071 95 976 2.4
2, 31 1000 995 15 980 2
1, 6F 1000 1067 72 995 0.5
Table 3 5 nodes; interpacket time ¼ 3000ms
Hop, node Sent packets Received packets Duplicate packets Regular packets PLR (%)
3, 4F 1000 853 57 796 20.4
2, 31 1000 1001 13 988 1.2
1, 6F 1000 1100 107 993 0.7
1, B4 1000 1028 51 977 2.3
2, 54 1000 1033 62 971 2.9
Table 4 7 nodes; interpacket time ¼ 3000ms
Hop, node Sent packets Received packets Duplicate packets Regular packets PLR (%)
3, 4F 1000 894 62 832 16.8
2, 31 1000 414 8 406 59.4
1, 6F 1000 1080 92 988 1.2
1, B4 1000 1046 53 993 0.7
2, 54 1000 1066 74 992 0.8
1, E3 1000 699 0 699 30.1
2, 5A 1000 776 58 718 28.2
142 G. Gardasevic et al.
123
were generated. The payload size is 20 bytes. We have used different inter-packet times:
1000, 1500 and 3000 ms. Due to space limitation, we present here the results in terms of
Packet Loss Rate (PLR) for 5 different test scenarios, Tables 2, 3, 4, 5 and 6.
The results show that, even in the presence of interference and dynamic environment
where people are moving, PLR is still at acceptable level. PLR depends also on number of
motes that are transmitting at the same time, and is the highest in the case where all 7
motes are sending packets to root (Table 4), and for motes closest to WiFi access point
(E3) and interferer (31). The another important parameter is the interpacket time and it
should be carefully chosen in order to avoid the queue overflow. The duplicate packets
appear as a consequence of interference, where the DODAG root can not process all
packets at scheduled times. Thus, the careful balancing of interpacket times and TSCH
parameters is required.
6 Conclusions
IoT applications are numerous, versatile, and closely related to our everyday life and
activities. There are many challenges and issues related to specific IoT scenario, envi-
ronment, context, technology, or application. Future research directions in IoT applications
and scenarios should also consider the social dimension and integration with social net-
works. This is important also in terms of increased number of IoT devices and connectivity
models. The programming paradigms should be focused on creating the self-aware
applications and systems with the ability of self-adaptation. Due to a variety of hetero-
geneous IoT solutions, protocols and data characterisation models, the interoperability of
standards and architectural frameworks is of prime importance.
This paper gives an overview of ongoing standardization efforts, design issues in terms
of the IoT hardware and software components, and addresses the requirements of relevant
IoT application domains for future IoT scenarios. We present the results obtained by
testing performances of OpenMote hardware platform for industrial IoT applications,
Table 5 3 nodes; interpacket time ¼ 1500ms
Hop, node Sent packets Received packets Duplicate packets Regular packets PLR (%)
3, 4F 1000 882 48 834 16.6
2, 31 1000 972 16 956 4.4
1, 6F 1000 1040 75 965 3.5
Table 6 5 nodes; interpacket time ¼ 1500ms
Hop, node Sent packets Received packets Duplicate packets Regular packets PLR (%)
3, 4F 1000 955 50 905 9.5
2, 31 1000 741 7 734 26.6
1, 6F 1000 1034 62 972 2.8
1, B4 1000 1003 48 955 4.5
2, 54 1000 984 50 934 6.6
The IoT Architectural Framework, Design Issues and... 143
123
where the preliminary results are obtained by testing two protocols for emerging Industrial
IoT applications: MQTT and TSCH. In order to demonstrate the functionalities of different
OSs on this platform, we tested both Contiki and OpenWSN. The MQTT represents the
lightweight messaging protocol for IIoT and M2M communications, optimized for con-
strained networks and resources. Regarding the TSCH protocol, the experimental results
show that this protocol can provide good immunity to interference. In terms of a future
research, we will further investigate the performances of TSCH protocol in different
scenarios and for other metrics such as latency, throughput and energy-efficiency. More-
over, we will explore the possible implementations of QoS mechanisms at different layers
of protocol stack.
Acknowledgments This work is partially supported by the Ministry of Education and Science of Bosniaand Herzegovina and the Ministry of Science of Montenegro, under the bilateral Project Architecture, designand performances of DCQ switch, and by the Ministry of Science of Montenegro under Grant 01-451/2012(FOREMONT). The research is also partially supported by NORBOTECH (NORway-BOsnia TECHnologyTransfer) project under reference 2011/1370, within the Programme in Higher Education, Research andDevelopment; financed by the Norwegian Ministry of Foreign Affairs.
References
1. Botterman, M. (2009). Internet of Things: An early reality of the Future Internet. Workshop Report,European Commission Information Society and Media, May 2009.
2. Atzori, L., Iera, A., & Morabito, G. (2010). The internet of things: A survey. Computer Networks,54(15), 2787–2805.
3. Stankovic, J. A. (2014). Research directions for the Internet of Things. IEEE Internet of Things Journal,1(1), 3–9.
4. ITU-T. Internet of things global standards initiative. http://www.itu.int/en/ITU-T/studygroups/2013-2016/13/Pages/default.aspx.
5. IETF. (2010). The internet of things—Concept and problem statement. http://tools.ietf.org/id/draft-lee-iot-problem-statement-00.txt.
6. IEEE Interent of Things, Towards a Definition of the Internet of Things (IoT), Revision 1, May 27(2015).
7. Vasseur, J. (2011). Terminology in low power and lossy networks. IETF Internet Draft, September2011.
8. Vermesan, O., & Friess, P. (2013). Internet of things: Converging technologies for smart environmentsand integrated ecosystems. The River Publishers Series in Communications, June 2013.
9. NarrowBand IoT. http://www.3gpp.org/news-events/3gpp-news/1733-niot.10. IETF 6LoWPAN Working Group. http://tools.ietf.org/wg/6lowpan.11. ZigBee IP and 920IP. http://www.zigbee.org/zigbee-for-developers/network-specifications/zigbeeip/.12. Winter, T. et al. (2012). RPL: IPv6 routing protocol for low-power and lossy networks. In RFC 6550
(Proposed Standard), Internet Engineering Task Force, March 2012.13. IETF, The Constrained Application Protocol (CoAP), in RFC 7252 (Proposed Standard), June 2014.
https://tools.ietf.org/html/rfc7252.14. ZigBee Smart Energy. http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbeesmart
energy/.15. MQTT Protocol. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.16. IETF, Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT):
Problem Statement. https://tools.ietf.org/html/rfc7554.17. Buratti, C., Stajkic, A., Gardasevic, G., Milardo, S., Abrignani, M. D., Mijovic, S., et al. (2016). Testing
protocols for the internet of things on the EuWIn platform. IEEE Internet of Things Journal, 3(1),124–133.
18. Texas Instruments, CC2538 Powerful Wireless Microcontroller System-On-Chip for 2.4-GHz IEEE802.15.4, 6LoWPAN, and ZigBee Applications. http://www.ti.com/lit/ds/symlink/cc2538.
19. Libelium Waspmote. http://www.libelium.com/development/waspmote.20. Tmote Sky platform. http://www.advanticsys.com/shop/mtmcm5000msp-p-14.html.
144 G. Gardasevic et al.
123
21. MICAz platform. http://www.cmt-gmbh.de/MICAz.22. Raspberry Pi platform. http://www.adafruit.com/pdfs.23. Arduino platform. https://www.arduino.cc/.24. Intel Galileo platform. http://www.intel.com/content.25. BeagleBone platform. http://beagleboard.org/bone.26. TinyOS Operating System. http://www.tinyos.net/.27. Contiki Operating System. http://www.contiki-os.org/.28. FreeRTOS Operating System. http://www.freertos.org/.29. RIOT Operating System. http://www.riot-os.org/.30. Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., et al. (2012). OpenWSN:
A standards-based low-power wireless development environment. Transactions on EmergingTelecommunications Technologies, 23, 480–493. doi:10.1002/ett.2558.
31. Sensinode NanoStack 2.0. http://sensinode.sivuviidakko.fi.32. Thingsquare platform. http://www.thingsquare.com/.33. Google Brillo OS. https://developers.google.com/brillo/.34. Schaffers, H., Komninos, N., Pallot, M., Trousse, B., Nilsson, M., & Oliveira, A. (2011). Smart cities
and the future internet: Towards cooperation frameworks for open innovation. The Future Internet.Lecturer Notes in Computer Science, 6656, 431–446.
35. Zanella, A., Bui, N., Castellani, A., Vangelista, L., & Zorzi, M. (2014). Internet of things for smartcities. IEEE Internet of Things Journal, 1(1), 22–32. doi:10.1109/JIOT.2014.2306328.
36. Aug-Blum, I., Boussetta, K. Rivano, H. Stanica, R., & Valois, F. (2012). Capillary networks: A novelnetworking paradigm for urban environments. In Proceedings of the first workshop on Urban net-working (UrbaNe ’12), ACM, New York, NY, USA, 25-30. doi:10.1145/2413236.2413243.
37. Open Cities, EU FP7 project. http://www.opencities.net/.38. VITAL, EU FP7 project. http://www.vital-iot.eu/vision.39. RERUM, EU FP7 project. https://ict-rerum.eu/.40. CityPulse, EU FP7 project. http://www.ict-citypulse.eu/page/.41. Smart Santander, EU FP7 project. Future internet research and experimentation. http://www.
smartsantander.eu/.42. ITU-T Study Group 5. Environment and climate change. http://www.itu.int/en/ITU-T/studygroups/
2013-2016/05/Pages/default.aspx.43. IEEE 2030 Smart Grid Interoperability Working Group. https://standards.ieee.org/findstds/standard/
2030-2011.html.44. Riazul Islam, S. M., Daehan, K., Humaun, K., Hossain, M., & Kyung-Sup, K. (2015). The internet of
things for health care: A comprehensive survey. IEEE Access, 3, 678–708. doi:10.1109/ACCESS.2015.2437951.
45. Fang, H., Dan, X., & Shaowu, S. (2013). On the Application of the internet of things in the field ofmedical and health care. In Green Computing and Communications (GreenCom), 2013 IEEE andInternet of Things (iThings/CPSCom), IEEE International Conference on and IEEE Cyber, Physicaland Social Computing, (pp. 2053–2058), 20-23 Aug. 2013. doi:10.1109/GreenCom-iThings-CPSCom.2013.384.
46. Ugrenovic, D., & Gardasevic, G. (2015). Performance analysis of IoT wireless sensor networks forhealthcare applications. In The 2nd International Conference on Electrical, Electronic and ComputingEngineering IcETRAN 2015, Silver Lake, Serbia, June 8–11, 2015.
47. ITU-T Focus Group on Smart Sustainable Cities, An overview of smart sustainable cities and the role ofinformation and communication technologies. www.itu.int/en/ITU-T/focusgroups/ssc/.../TR-Overview-SSC.docx.
48. OpenIoT, EU FP7 project. http://www.openiot.eu/.49. Libelium Agriculture. http://www.libelium.com/case-studies/.50. Akyildiz, I. F., & Jornet, J. M. (2010). The internet of nano things. IEEE Wireless Communications,
17(6), 58–63.51. Tseng, A., Chen, K., Chen, C., & Ma, K. (2003). Electron beam lithography in nanoscale fabrication:
Recent development. IEEE Transactions on Electronics Packaging Manufacturing, 26(2), 141–149.52. Lee, H. H., Menard, E., Tassi, J. A. R. N. G., & Blanchet, G. B. (2005). Large area microcontact
printing presses for plastic electronics. Materials Research Society Bulletin, 846, 731–736.53. Geim, A. K., & Novoselov, K. S. (2007). The rise of graphene. Nature Materials, 6(3), 183–191.54. Geim, A. K. (2009). Graphene: Status and prospects. Science, 324(5934), 1530–1534.55. Balasubramaniam, S., & Kangasharju, J. (2013). Realizing the internet of nano things: Challenges,
solutions, and applications. Computer, 46(2), 62–68.
The IoT Architectural Framework, Design Issues and... 145
123
56. Akyildiz, I. F., Brunetti, F., & Blazquez, C. (2008). Nanonetworks: A new communication paradigm.Computer Networks, 52, 2260–2279.
57. Nakano, T., Eckford, A., & Haraguchi, T. (2013). Molecular communication. Cambridge: CambridgeUniversity Press.
58. Atakan, B. (2014). Molecular communication and nanonetworks: From nature to practical systems.Berlin: Springer.
59. Pierobon, M., & Akyildiz, I. F. (2013). Fundamentals of diffusion-based molecular communication innanonetworks. Founds and Trends in Networking, 8(1–2), 1–147.
60. Jornet, J. M., & Akyildiz, I. F. (2014). Femtosecond-long pulse-based modulation for terahertz bandcommunication in nanonetworks. IEEE Transactions on Communications, 62(5), 1742–1754.
61. Akyildiz, I. F., Pierobon, M., Balasubramaniam, S., & Koucheryavy, Y. (2015). Internet of bio-nan-othings. IEEE Communications Magazine, 53(3), 32–40.
62. Nakano, T. et al. (2008). Microplatform for intercellular communication. In 3rd IEEE InternationalConference on Nano/Micro Engineered and Molecular Systems
63. Mesiti, F., & Balasingham, I. (2012). Nanomachine-to-neuron communication interfaces for neuronalstimulation at nanoscale. IEEE Journal on Selected Areas in Communications, 31(12), 695–704.
64. Jornet, J. M., & Akyildiz, I. F. (2012). The internet of multimedia nano-things. Nano CommunicationNetworks, 3, 242–251.
65. Vilajosana, X., Tuset, P., Watteyne, T., & Pister, K. (2015). OpenMote: Open-source prototypingplatform for the industrial IoT. In International Conference on Ad Hoc Networks (AdHocNets), Sep2015, San Remo, Italy (pp. 211–222).
66. OpenMote platform. http://www.openmote.com/.67. Contiki OpenMote. https://github.com/OpenMote/contiki.68. OpenWSN project. http://www.openwsn.org/.69. Capossele, A., Cervo, V., De Cicco, G., & Petrioli, C. (2015). Security as a CoAP resource: An
optimized DTLS implementation for the IoT. In 2015 IEEE international conference on communica-tions (ICC), London (pp. 549–554). doi:10.1109/ICC.2015.7248379.
70. Lesjak, C., et al. (2015). Securing smart maintenance services: Hardware-security and TLS for MQTT.In 2015 IEEE 13th international conference on industrial informatics (INDIN), Cambridge (pp.1243–1250). doi:10.1109/INDIN.2015.7281913.
71. Mosquitto project. http://www.mosquitto.org/.72. Hwang, H. C., Park, J., Shon, J. G. (2016). Design and implementation of a reliable message trans-
mission system based on MQTT protocol in IoT. Wireless Personal Communications, 1–13. doi:10.1007/s11277-016-3398-2.
73. MQTT for Sensor Networks (MQTT-SN) Protocol Specifications (Ver. 1.2). http://mqtt.org/.
Gordana Gardasevic received the B.Sc., M.Sc., and Ph.D. degrees inElectrical Engineering (with specialization in Telecommunications)from the Faculty of Electrical Engineering, Banja Luka, Bosnia andHerzegovina, in 1995, 2001, and 2008, respectively. She was aResearch Fellow at School of Electrical and Computer Engineering,National Technical University of Athens (NTUA), Greece(2006–2008). She was a Postdoctoral Fellow at the University ofBologna, (2013–2014). Currently, Prof. Gardasevic is the AssociateProfessor and Chief of Department of Telecommunications at Facultyof Electrical Engineering, Banja Luka. Prof. Gardasevic participated inmany national and international projects (PHARE, COST, TEMPUS,FP6, FP7, etc.). She is currently the B&H representative in COSTaction ‘‘Inclusive Radio Communication Networks for 5G andBeyond-IRACON’’, (2016–2020). Prof. Gardasevic has publishedmore than 50 scientific papers in international journals and conferenceproceedings. Key research interests of Prof. Gardasevic include next
generation networks architectures and applications, cross-layer protocol design, embedded wireless systems,Internet of Things architectures and applications.
146 G. Gardasevic et al.
123
Mladen Veletic received the B.Sc. and M.Sc. degrees in electronicsand telecommunications from the Faculty of Electrical Engineering,University of Banja Luka (UNIBL), Banja Luka, Bosnia & Herze-govina in 2010 and 2012, respectively. Since January 2013, he is aPh.D student at the Department of Electronics and Telecommunica-tions, Norwegian University of Science and Technology (NTNU),Trondheim, Norway, and the Faculty of Electrical Engineering,UNIBL, as a scholar within HERD/ICT NORBAS project under ref-erence 2011/1383 supported by the Norwegian Ministry of ForeignAffairs. His research interests include wireless communications,positioning in cellular networks, molecular and nano-neural commu-nications. Mladen Veletic was awarded a Gold Plaque from theUNIBL for his achievements throughout the undergraduate education.
Nebojsa Maletic born in 1986, received B.Sc. and M.Sc. degrees fromthe School of Electrical Engineering, University of Belgrade in 2008and 2010, respectively. Presently, he is a research scientist at IHP(www.ihp-microelectronics.com). His research topics are in wirelesscommunication systems, including millimetre-wave communicationand beamforming systems, relaying systems and hardware impair-ments effects.
Dragan Vasiljevic received the bachelor degree in Electrical Engi-neering from the Faculty of Electrical Engineering, University ofBanja Luka, Bosnia and Herzegovina in 2002. Since 2002, he isemployee of Telecommunications of Republic of Srpska. Currently, heis master student in telecommunications at Faculty of ElectricalEngineering, University of Banja Luka. He has passed exams andsubmitted the master thesis for evaluations. His research interests arewithin Internet of Things applications, Wireless Sensor Network pro-tocols and routing, and embedded systems.
The IoT Architectural Framework, Design Issues and... 147
123
Igor Radusinovic received the Telecommunications Engineeringdegree by the University of Montenegro in 1994. He received theM.Sc. and Ph.D. degree by the University of Belgrade, Serbia, in 1997and 2003 respectively. He is a Full professor in Telecommunicationsnetworks and Switching systems at the Faculty of Electrical Engi-neering, University of Montenegro. From 2009 to 2011 Prof. Radusi-novic was Deputy Minister for Science, Research and TechnologicalDevelopment in the Ministry of Education and Science of theGovernment of Montenegro. He was Montenegrin representative to theBoard of Governors of the Joint Research Centre of the EuropeanCommission (JRC EC) and European Research Area Committee(ERAC). Prof. Radusinovic was Chairmen of Montenegrin Council forScience and Research. He is a Member of the Managing Board ofUniversity of Montenegro and President of the Managing Board ofMontenegro Post. He has published as an author or co-author morethan 120 papers in international and national scientific journals and
international and regional conferences. He participated in a number of international (FP7, COST action) andnational research teams and projects, as well as bilateral research cooperation. Prof. Radusinovic hasconsiderable industry and operating experiences working on many strategic studies, regulatory issues,development strategies and technical solutions in area of ICT. Research interest of Prof. Radusinovic isfocused, but not limited, on: packet switching systems, telecommunications network theory, congestioncontrol algorithms, software defined networking and 5G.
Slavica Tomovic received B.Sc. degree in Electronics, Telecommu-nications and Computer Science from Faculty of Electrical Engineer-ing in Podgorica, University of Montenegro. From the same faculty shereceived M.Sc. degree in Telecommunication (2015). Currently,Slavica is Ph.D. student on Faculty of Electrical Engineering,University of Montenegro. She is also teaching/research assistant at thesame faculty. Her main research interests are in the areas of software-defined networking, quality of service management and architectures,Internet of Things and 5G wireless network design.
Milutin Radonjic received the B.Sc., M.Sc., and Ph.D. degrees inElectrical Engineering from University of Montenegro in 1991, 1997and 2011, respectively. He is an Assistant Professor at University ofMontenegro. Key research and expertise areas of Prof. Radonjic arepacket switching systems, computer networks, embedded systems anddigital system design.
148 G. Gardasevic et al.
123
