This article has been accepted for publication in a future issue of this journal, but has not been
fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
IEEE INTERNET OF THINGS JOURNAL, VOL. X, NO. X, OCTOBER 2018
Fog/Edge Computing-based IoT (FECIoT):
Architecture, Applications, and Research Issues
Babatunji Omoniwa, Riaz Hussain, Muhammad Awais Javed, Safdar H. Bouk, Senior Member, IEEE
and Shahzad A. Malik
Abstract—The Internet-of-Things (IoT) is the future of the In-
ternet, where everything will be connected. Studies have revealed
that Fog/Edge Computing (FEC)-based services will play a major
role in extending the cloud by carrying out intermediary services
at the edge of the network. Fog/Edge Computing-based IoT’s
(FECIoT) distributed architecture enhances service provisioning
along the Cloud-to-Things continuum, thereby making it suitable
for mission-critical applications. Furthermore, the proximity of
fog/edge devices to where the data is produced makes it stand-
out in terms of resource allocation, service delivery, and privacy.
From the business perspective, FECIoT will lead to a boom
and spring up of small-to-medium-sized enterprises (SMEs),
thereby encouraging inclusion for all. To this end, we present a
comprehensive survey on state-of-the-art IoT literature over the
period 2008-2018 and propose the FECIoT framework which
covers the enabling technologies, services, and open research
issues. A tutorial approach is employed, progressing from basic to
more advanced concepts within the IoT domain. Lastly, we show
how FECIoT can be deployed in real-life Cyber-Physical Systems
(CPS) such as the intelligent transportation system, smart grid,
smart health-care, smart homes, and smart environment.
Index Terms—Fog/edge computing, Internet-of-Things, service-
oriented architecture, enabling technologies, cyber-physical sys-
tems.
I. I NTRODUCTION
VER the years, there has been the trend of moving
O storage, computing, and network management function-
alities to centralized data centers, IP backbone networks, and
core networks. With exploding volume of data collected from
underlying IoT devices, there is the need for data to be
processed close to where it is produced in order to minimize
response delay, and effectively distribute network load. Recent
studies have shown the shortcomings of the cloud as regards
handling of big-data. By the year 2020, it is projected that
about 50 billion things are expected to be connected to the
Internet [1], inclusive of both “smart” and “dumb” (e.g., a
dishwasher, a car, a parcel, livestock, thermostats) objects. To
this point, IoT requires a robust and resilient architecture that
will enable faster data processing, as well as storage. Several
researchers [2], [3] have suggested the need to integrate the
fog/edge computing (FEC) with the IoT. FEC promises to run
IoT-enabled applications for real-time control and analytics,
B. Omoniwa is with National Mathematical Centre, PMB 118, Abuja-
Nigeria, email: tunjiomoniwa@gmail.com.
R. Hussain, M. A. Javed and S. A. Malik are with COMSATS University,
Islamabad, Pakistan, email: {rhussain, awais.javed, smalik}@comsats.edu.pk.
S. H. Bouk is with Daegu Gyeongbuk Institute of Science and Technology
(DGIST), Daegu 42988, Korea, email: bouk@dgist.ac.kr.
Copyright (c) 2012 IEEE. Personal use of this material is permitted.
However, permission to use this material for any other purposes must be
obtained from the IEEE by sending a request to pubs-permissions@ieee.org.
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
1
with millisecond response time. Furthermore, FEC enables
designing and building a scalable and adaptable IoT platform
that supports systems requiring reliable sensing, actuation,
analysis, and control. Moreover, FEC can facilitate manage-
ment of a very large amount of geographically distributed
“things” and also handle systems with dynamic mobility [1].
In order to adequately deploy FECIoT, a closer study should
be carried out on the features of IoT. In [2], IoT is defined
as a large-scale network where various networks coexist, and
are capable of interacting with one another through various
gateways and middlewares, with the support of the complex
control plane. In essence, ubiquitous devices should be able
to communicate over various networks with the sole aim
of providing services, sharing information and applications.
However, connectivity, latency, bandwidth, service and privacy
issues have posed challenges in fully implementing IoT. Thus,
there is need to include mechanisms that can handle objects
and things on a large scale. The architectural framework
for many emerging systems like the IoT and Cyber-Physical
Systems (CPS) is still frail [3]. A service-based architecture
was discussed in [2]. The Service-oriented Architecture (SoA)
is a component-based model that focuses on the systematic
design of the workflow of coordinated services. Where and
how to perform computation and storage along the Cloud-
to-Things continuum, and how decisions can be managed
within heterogeneous systems is still a debatable issue [4].
Localized data analytics coupled with control can provide
some level of autonomy to devices close to the edge of the
network (FEC devices), which may help in enhancing the
performance of mission-critical IoT applications. This paper
presents new challenges in emerging IoT and the bottlenecks
faced in resolving these challenges using today’s computing
and networking models. The paper further discusses why
the FECIoT architecture should be deployed to fill possible
technological gaps with a view to enhancing new business
opportunities. An in-depth look into protocols and technolo-
gies is presented in the context of the proposed architecture.
Various services that can be derived from the FECIoT are also
presented. Furthermore, we discuss security features, as well
as security challenges that exist within the FECIoT framework.
Lastly, applications and research issues will be presented.
FEC has received tremendous attention and has been de-
ployed in several cyber-physical systems [2], [3]. Though still
in the infancy stage, FEC has the potential of solving chal-
lenges faced by cloud computing, such as connectivity, latency,
bandwidth, service and privacy issues. In recent years, several
surveys have been published in the area of IoT and FEC [1]-
[35]. These works focused on areas such as architecture,
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
IEEE INTERNET OF THINGS JOURNAL, VOL. X, NO. X, OCTOBER 2018 2

TABLE I
enabling technology, security and privacy, protocols, networks,
L IST OF ACRONYMS . physical systems, and possible applications to mention but a
few.
Acronym Definition Despite global attention received by IoT over the years,
3GPP Third Generation Partnership Project there is no single consensus on how the architecture will
5G Fifth Generation be framed [4]. Lin et al. in [2] presented a survey on the
6LoWPAN IPv6 over Low Power WPAN architecture, enabling technologies, security and privacy, and
BLE Bluetooth Low Energy applications of IoT. However, research issues and directions
BSN Body Sensor Networks
were not covered. Chiang et al. in [3] comprehensively covered
CAN Controller Area Network
CCTV Closed-Circuit Television
inherent challenges in both fog and IoT. However, the enabling
CoAP Constrained Application Protocol technologies and architectural framework were not covered.
CoRE Constrained RESTful Environments Although, the FECIoT framework proposed in this paper ex-
CORPL Cognitive Ripple Routing Protocol tends on the fundamental ideas presented in [2] and [3], which
CPS Cyber-Physical Systems were both built upon the foundation laid by Bonomi et al. in
DODAG Destination Oriented Directed Acyclic Graph [6]. The work of Sethi et al. in [4] focused on architectures and
DTLS Datagram Transport Layer Security protocols in IoT with no consideration for the emerging FEC
FEC Fog/Edge Computing paradigm. One of the first comprehensive surveys carried out
FaaS Fog-as-a-Service in the area of IoT was by Atzori et al. in [5]. The work covered
GATT Generic Attribute Profiles enabling technologies, as well as elaborating on the service-
HaaS Hardware-as-a-Service
oriented architecture. Applications into various CPS domains
HTTPS Hypertext Transfer Protocol Secure
IaaS Infrastructure-as-a-Service
were presented, however, integrating the FEC paradigm was
IEC International Electrotechnical Commission not envisioned then.
IEEE Institute of Electrical and Electronics Engineers We survey state-of-the-art literatures related to IoT, fog,
IETF Internet Engineering Task Force edge, and cloud computing, and we present a table summary
IPSec Internet Protocol Security based on the scope and topics covered. In this paper, we
IPv4/v6 Internet Protocol version 4/6 attempt to cover most of these topics using a tutorial style
ISM Industrial, Scientific, and Medical for the sake of new entrants in the area of IoT. Table II
ITS Intelligent Transportation Systems show the topics covered in 42 review papers. We begin
ITU International Telecommunication Union by presenting basic concepts, then proceed to the FECIoT
LTE-A Long Term Evolution-Advanced architectural framework, protocols and enabling technologies,
MANET Mobile Ad hoc Network
services from a business perspective, security and privacy
MDC Microdata Center
issues, open research challenges and applications in the context
MEC Mobile Edge Computing
NFC Near Field Communication of FECIoT. The contribution of our work is five-fold, which
OaaS Offload-as-a-Service are listed as follows.
OC Offload Computation 1) We provide a comprehensive discussion on the basic con-
OSGi Open Service Gateway cepts like the Fog computing, Edge computing, CPS, and
P2P Peer-to-Peer IoT. Furthermore, we provide a summary of protocols and
PaaS Platform-as-a-Service standards from different standard development organiza-
PAN Personal Area Networks tions (IEEE, ITU, IETF, 3GPP, etc.) to enable researchers
PDU Protocol Data Unit have hands-on material without having to go through RFC
QoS Quality of Service
volumes and other specification standards.
RAN Radio Area Network
2) We provide an exhaustive review of the up-to-date research
REST REpresentational State Transfer
RFID Radio-Frequency Identification progress in FECIoT, and highlight key areas such as
ROLL Routing Over Low power and Lossy architecture, services, security and privacy issues.
SaaS Software-as-a-Service 3) We provide a detailed comparison of variously available
SCADA Supervisory Control and Data Acquisition simulators in terms of their FECIoT simulation capa-
SoA Service-oriented Architecture bilities. We also perform simulations on NetLogo and
SOAP Simple Object Access Protocol Cooja and compare the proposed FECIoT-based model
TCP Transmission Control Protocol with the centralized cloud-based model by analyzing key
TEDS Transducer Electronic Data Sheets performance metrics such as storage efficiency, network
UDP User Datagram Protocol efficiency, computational efficiency and service discovery.
W3C World Wide Web Consortium
In addition, we also present an example of a link-level
WISP Wireless Identification and Sensing Platform
simulation for FECIoT communications. Furthermore, to
WLAN Wireless Local Area Networks
WPAN Wireless Personal Area Networks improve the communication reliability in FECIoT systems,
WSDL Web Service Description Language we also formulated an optimization problem that minimizes
WSN Wireless Sensor Network the outage probability in the network.
XML Extensible Markup Language 4) We present detailed applications and use cases within the
CPS (Intelligent transportation systems, smart grid, smart

2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
homes, smart health-care, and smart environment) to show
how different protocols presented in the paper fuse to
provide desirable FECIoT services.
5) We also present a variety of open research challenges and
suggest possible future trends for FECIoT, with respect to
the latest development in the field.
The remainder of this work is organized as follows. In
Section II, we present basic concepts. The FECIoT architec-
tural framework is presented in Section III. In Section IV,
we discuss some relevant services offered by deploying the
FECIoT framework. Protocols and enabling technologies re-
quired to drive the FECIoT framework are presented in Section
V. In Section VI, we perform some simulations to validate
the efficiency of the proposed FECIoT model. Security and
privacy issues are presented in Section VII. Applications of
FECIoT in some selected cyber-physical systems are discussed
in Section VIII. Some open research issues that could spark-
up new ideas are presented in Section IX. Finally, Section X
concludes the paper.
II. OVERVIEW OF BASIC C ONCEPTS
In this section, we present basic concepts and provide
comparisons amongst seemingly similar, but misunderstood
concepts. Thus, we provide an overview of cloud computing,
fog computing, edge computing, similarities and differences,
CPS and IoT.
A. Cloud Computing (CC)
With top multi-national computing giants like Amazon web
services,1 Microsoft Azure,2 Google Cloud platform,3 and
IBM Cloud4 championing the adoption of the generic cloud
computing model where big-data analytics, decision making,
and computations all take place centrally in the distant cloud
data-centers. Many drawbacks to this centralized model have
been presented by various researchers [3], [6]. The increase
in machine-type communication (MTC) as observed in IoT
will lead to massive amounts of data flow within the IoT
ecosystem. As such it becomes difficult to manage traffic
and congestion within the network using the CC model.
Furthermore, delay sensitive data and applications will expe-
rience greater latency considering the relatively far distance
between IoT end-devices and the cloud data-centers. Market
monopoly is also a noticeable trend since only top multi-
national enterprise can afford to set up a cloud infrastructure,
and define and deploy propriety protocols [7]. Despite the
emergence of FEC which promises better business prospects
for SMEs, lower latency, and higher bandwidth efficiency, the
cloud will continue to have a key role to play in the proposed
FECIoT framework. The partitioning of where, how and what
tasks go to the cloud are application specific. It is possible
to predefine such tasks, however, they could be subject to
the dynamic changes going on within the network, such as
1 http://aws.amazon.com
2 https://azure.microsoft.com/en-gb/
3 https://cloud.google.com/
4 https://www.ibm.com/cloud-computing/
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Cloud Services
Request
Response Things
End user
Fig. 1. Cloud computing model.
processing and storage capacities, bandwidths, security threats,
link downtime, cost constraints etc. [6].
Fig. 1 shows the cloud computing model along with three
generic services. These services are,
i) Platform-as-a-Service (PaaS): This is a customer-based
cloud computing service that supports clients, by given
them the flexibility of developing, running, and managing
web-based applications without going through the rigour
of building and maintaining infrastructures typically as-
sociated with developing and launching an application.
The PaaS also supports the overall life-cycle manage-
ment of cloud applications, including coding, testing,
deployment and maintenance [43]. A good example is
Apprenda,5 which is a provider of private cloud PaaS
for .NET and Java.
ii) Infrastructure-as-a-Service (IaaS): This service model is
also known as Hardware-as-a-Service (HaaS), it is a
cloud computing service model that provides computing
infrastructure to enhance enterprise operations, usually
based on outsourcing. In other words, IaaS manages
computing, storage and networking resources and pro-
vides basic resource services to the PaaS or to users
directly [43]. Generally, IaaS provides hardware (may
include software), storage, servers, and data center space
or network elements. Amazon Web Services (AWS),
Cisco Metacloud6 (formerly Metapod), Microsoft Azure,
Google Compute Engine (GCE), and Joyent7 etc. all fall
within the IaaS category.
iii) Software-as-a-Service (SaaS): This is a software distri-
bution model which allows clients to have access to
applications hosted by third-party providers over the
Internet [10]. Good examples of SaaS used in everyday
life are Twitter,8 Instagram,9 Facebook,10 and Google’s
suite of intelligent apps11 (formerly Google Apps).
5 https://apprenda.com/
6 https://www.cisco.com/
7 https://www.joyent.com
8 https://twitter.com/
9 https://www.instagram.com/
10 https://www.facebook.com/
11 https://gsuite.google.com/
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of Things Journal

TABLE II
S UMMARY OF STATE OF THE ART REVIEWS / SURVEYS .

Reference IoT Fog Edge Architecture Protocols Services Security Technology Research issues Applications Our Contributions
Detailed review with
AI-Doghmant et al. [1] - X - - - - - X - - much more coverage
(2016)
on the subject
More focus on FECIoT,
X X X X - - X X - X five-layer architecture,
Lin et al. [2] (2017)
simulators, research di-
rections
Built upon the idea,
and provided updated
Chiang et al. [3] (2016) X X - X - - - - X X details on FECIoT ser-
vices, protocols, and
security
Detailed review on FE-
X - - X X - - - - X CIoT architecture and
Sethi et al. [4] (2017)
potential research is-
sues
More reviews have
X - - - X - X X X X been included since
Atzori et al. [5] (2010)
2010, update on
protocols
New ideas were built
Bonomi et al. [6] X X - X - - - - - X on this foundation pa-
(2012) per, with more practical
applications
Detailed discuss on the
Pan et al. [7] (2018) X X X X - - - X X - enabling technologies
and security features
- X X X - X - - - X Elaboration on poten-
Dolui et al. [8] (2017)
tial research issues
Details on FECIoT
Hu et al. [9] (2017) - X - X - - X X X X services, protocols and
simulators
Update on protocols,
Shi et al. [10] (2016) - - X - - X X - - X technologies, and re-
search issues
Al-Fuqaha et al. [11] X - - X X X - X - X Elaborated on security
(2015) and research issues

2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of Things Journal

TABLE II: S UMMARY OF STATE OF THE ART REVIEWS / SURVEYS (C ONTD . 1).
Reference IoT Fog Edge Architecture Protocols Services Security Technology Research issues Applications Our Contributions
Enhanced ideas
on architecture,
Bilal et al. [12]
- X X - - - - X - X protocols, services
(2018)
and research
directions
Miorandi et al. [13] Focus on the FE-
X - - - - - X X X X
(2012) CIoT framework
Comprehensive
Mehmood et al. [14]
X - - - X - - X X - review on FECIoT
(2017)
applications
Detailed review on
Aazam et al. [15] FECIoT architecture,
X X - X - - - - - -
(2016) services and proto-
cols, and security
Presented the FE-
Zhu et al. [16]
X - - - - - - X X X CIoT framework and
(2015)
developments
Enhanced details on
Ngu et al. [17]
X X - X - X X X X - protocols and appli-
(2017)
cations
Detailed review on
Raggett et al. [18] FECIoT architecture,
X - - - X - - - X -
(2015) services, security,
and research issues
Detailed review on
Want et al. [19] FECIoT architecture,
X - - - - - - X X -
(2015) services, security,
and applications
Detailed review on
Razzaque et al. [20]
X - - X - X - - X X FECIoT security and
(2016)
enabling technology
Sheng et al. [21] Detailed discuss on
X - - X X - - - X -
(2013) FECIoT applications
Enhanced review
with FECIoT
Ai et al. [22] (2017) - - X - - - - X - X architecture, services
and research
directions

2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of Things Journal

TABLE II: S UMMARY OF STATE OF THE ART REVIEWS / SURVEYS (C ONTD . 2).
Reference IoT Fog Edge Architecture Protocols Services Security Technology Research issues Applications Our Contributions
Detailed FECIoT
Verma et al. [23]
X - - X - - - X X X protocols and
(2017)
security services
Luong et al. [24] Presented the FE-
X - - X - - X X X X
(2016) CIoT framework
Detailed discuss on
Ni et al. [25] (2017) X X - X - - X - X X FECIoT services and
protocols
Presented the
Granja et al. [26] FECIoT framework,
X - - - X - X - X -
(2015) covering simulators
and research issues
Elaborated on
Palattella et al. [27]
X - - - X - - - - - FECIoT architecture
(2013)
and applications
Emphasized on FE-
Varghese et al. [28]
- - X - - - - - X X CIoT services and
(2016)
enabling technology
Satyanarayanan et Comprehensive FE-
- - X X - - - - X X
al. [29] (2017) CIoT review
Detailed discuss on
Alrawais et al. [30]
- X - - - - X - X X the FECIoT simula-
(2017)
tors and applications
Wen et al. [31] Presented practical
X X - - - X - - X -
(2017) FECIoT applications
Presented some re-
Atzori et al. [32]
X - - X - X - X - X search issues in FE-
(2012)
CIoT
Detailed discuss on
Lan et al. [33]
X - - X - X - - - - security and applica-
(2014)
tions
Detailed discuss on
Ray et al. [34]
X - - X - - X X X X latest protocols and
(2016)
technologies
Gubbi et al. [35] Presented some re-
X - - X - X - X - X
(2013) search directions

2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of Things Journal

TABLE II: S UMMARY OF STATE OF THE ART REVIEWS / SURVEYS (C ONTD . 3).
Reference IoT Fog Edge Architecture Protocols Services Security Technology Research issues Applications Our Contributions
Detailed review on
Atlam et al. [36] FECIoT protocols,
X X - X - - - - X X
(2018) technologies, and
security services
Presented protocols,
Dutta et al. [37]
X X - X - - - X - - applications, and re-
(2017)
search directions
Much wider cover-
Puliafito et al. [38] age on the FECIoT
X X X - - - - - X X
(2017) domain, detailed re-
search directions
Detailed FECIoT
Mohan et al. [39] protocols, security
X X X X - - - - X -
(2016) services, and
applications
Enhanced ideas on
fog computing
Yannuzzi et al. [40]
X X - - - - - - X X to produce a
(2014)
comprehensive
FECIoT review
Comprehensive
review on FECIoT
Mouradian et al. [41]
X X - X - - - - X X protocols, security
(2018)
services, and
simulators
Detailed FECIoT
Porambage et al.
X - X X - - X X X X protocols, services,
[42] (2018)
and simulators

2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
B. Fog Computing (FC)
The concept of fog computing (FC) was first introduced
in 2012 by Bonomi et al. [7], working at Cisco Inc. The
FC paradigm entails moving intelligence down to Local Area
Network (LAN) level and data is processed at an IoT gateway.
The main aim of its introduction was to extend services
and functionalities offered by the cloud at the edge of the
network. Such functionalities may include storage, processing,
database operation, integration, security, and management to
IoT end-devices, leveraging on its proximity to the edge of the
network. With exciting benefits of minimizing network con-
gestion, minimizing end-to-end latency, tackling connectivity
bottlenecks, improving security and privacy, and enhancing
scalability, FC is seen as the way forward. Furthermore, there
are claims within the industry of the vast business opportu-
nities that could be derived with the advent of FC. With the
effective distribution of computing, storage, networking, and
management service along the Cloud-to-Things continuum,
it meets today’s application requirements for local content,
resource pooling, and real-time processing [44]. As such, FC
has attracted interest from both the academia and industry. It is
a fact that FC does not replace the CC, rather it complements
by offloading data or service request that can be processed
locally [45]. However, we acknowledge the limitations of the
CC-based model and stress the need for FC integration to
allow for global applicability. Another emerging paradigm
that can revolutionize IoT is Dew Computing (DC). In [46],
DC is expected to depend on micro-service approach in a
highly heterogeneous, vertical, and distributed hierarchy. It
gives room for a centralized-virtualization-free computational
horizon where data scattering into low-end devices is possible.
Hence, allowing for data accessibility even without continuous
internet access. The extreme scalability and self-adaptive at-
tributes of DC makes it prime to the success of IoT. However,
several research issues will arise due to its extreme complexity.
With FC’s intermediary role of deploying existing computing
infrastructure in bridging the cloud to things, FC will be prime
to the success of existing and emerging technologies like the
smart grids, smart homes, smart cities, wireless sensor net-
works, mobile healthcare, manufacturing, vehicular networks,
and lot more. Below are some advantageous features of FC:
i) Geographically dispersed.
ii) Support for large-scale sensor networks and end nodes.
iii) Provides better real-time response than the cloud-based
model.
iv) Supports heterogeneity and interoperability.
v) Online analytics and interaction with the cloud.
Despite these advantageous features, FC is frail, and as
such presents new challenges that are discussed in subsequent
sections.
C. Edge Computing (EC)
As the name implies, the edge computing (EC) entails
computation that is carried out at the edge of the network.
EC aims at overcoming limitations associated with the cloud
computing-based model. It serves as the intermediary between
the end-users/devices and the cloud, providing processing and
8
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
storing functionalities to a large number of IoT end-devices.
The proximity of edge devices will minimize computational
load on data centers situated far away in the cloud. Real-time
response will be enhanced, as well as reduced latency [8].
Another merit of EC is the distributed nature and support
for device mobility within heterogeneous networks. In fact,
significant research effort is presently being carried out in the
area of Mobile Edge Computing (MEC). According to [8],
edge layer can be implemented in three modes, the MEC,
FC, and Cloudlet Computing (CC). MEC is the deployment
of intermediary nodes with capabilities of processing and
storing information within the BS of cellular mobile networks,
hence enabling cloud computing functionalities inside the
Radio Area Network (RAN). Cloudlets is a smaller version
of the cloud which uses dedicated devices that offer cloud-
like functionalities. In [10], it was shown that response time
is reduced from 900 ms to 169 ms just by moving computation
from cloud to the edge in a face recognition application. Below
are some advantageous features of EC:
i) Geographically dispersed.
ii) Improved security, as encrypted data moves further into
the core network.
iii) Provides better real-time response than the cloud-based
model.
iv) Better scalability through virtualization.
v) Limits potential communication bottlenecks.
D. Fog/Edge Computing (FEC)
It is pertinent to note that FC devices may not necessarily
be at the network edge, but reside close to the edge of the
network. In contrast, edge devices often reside at the network
edge, and are often the first point of contact to the IoT end-
devices. In essence, FC devices and EC devices are both
close to the IoT end-devices, but the EC devices are often
closer. In many works, fog computing and edge computing
have been used interchangeably. Some consider FC as a part
of the EC and microdata center (MDC) paradigm for IoT [15].
Both FC and EC have their services located close to the
end users, however, EC is resident in edge devices, while
FC resides in the network edge devices, usually a single or
few network hops away from the edge.The EC platform has
constrained energy and limited storage, and fall within the
class of constrained devices. The increase in the number of
IoT applications may result in higher contention for resources
and additional latency [9]. In essence, the resource contention
of EC is greater than FC due to proximity to IoT end-devices.
Furthermore, EC focuses more on the things domain, while
fog computing focuses more on the infrastructure domain.
FEC has certain pillars, they include security, scalability,
openness, autonomy, reliability, agility, hierarchical organiza-
tion and programmability, which is inherent to both FC and
EC. As such, the motivation for integrating both the FC and
EC is based on the peculiarities between them.
1) They both use a virtualized IaaS platform and allow for
multi-tenancy of applications at the edge of the network.
2) They both compliment functionalities offered by the cloud
and are located between end users and data centers.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal

Far away datacentres equipped

with sophisticated storage and

Cloud Computing Layer

CPS 2: CPS 3:
CPS 1: Intelligent CPS n:
Smart

super computers
Smart Grid Transport Smart
Homes World
System

Highly distributed with support for

Fog/Edge Computing (FEC) Layer
mobility, constrained devices with
some processing capabilities
All things embedded with
sensors, actuators

Things Layer

Fig. 3. IoT integrates n CPS

data collected to and from sensors and actuators down to

the cyber systems situated in control centers, which analyze
data and provide feedback to the physical component, thereby
Fig. 2. FEC architecture and interaction in the Cloud-to-Things continuum
providing effective monitoring and control.
The physical world connects to the cyber systems via
interfaces. These interfaces are the communication network
3) They both can be physically co-located with access points, and other intermediary components such as sensors, actua-
roadside units, base stations, routers, switches, and gate- tors, analog-to-digital converters (ADC), and digital-to-analog
ways. converters (DAC) [49]. From Fig. 3, we see that CPS ver-
4) They both are mostly deployed wirelessly and provide low tically cut across a unique set of physical devices, com-
latency, low jitter, and cognition within the system. munication/network technologies, and applications specific to
5) They both provide computational services in distributed each CPS domain, while IoT horizontally integrates diverse
geographical locations in order to minimize the load on CPS. It is important to note that the interconnection of the
the cloud. heterogeneous networks goes beyond physical connection,
Based on functionalities, both FC and EC can overlap but homogenize protocols, middleware, interfaces within the
and coexist within the CPS [44]. Fig. 2 shows a pictorial control plane across diverse networks. A good scenario is
representation of the FECIoT model with various domains. where an asthmatic patient connected to the smart health-care
In this paper, we arrive at a consensus that FC and EC are gets notified by a vehicle connected to the smart transport
congruent. network about the air pollution ahead by the smart monitoring
network. In fact, there are thousands of real-life scenarios
E. Cyber-Physical Systems (CPS) where multiple CPS applications simultaneously operate. CPS
During the last decade, Cyber-Physical Systems (CPS) and IoT share close similarities in their functionalities, as
blossomed with lots of research work carried out in the areas of well as open challenges. In the following, we identify key
smart grid, smart homes, smart weather, smart manufacturing, developments and challenges related to CPS/IoT.
intelligent transportation, and many more. Just like IoT, CPS a) Flexible middleware support: Rather than assuming
consist of heterogeneously distributed subsystems [2]. CPS CPS/IoT end-devices to be completely dumb or passive,
are complex systems with systematic and well-coordinated with little or no computing capacity, it is important to
computation, communications and control [47]. Generally, explore the role of this middleware in easing the burden
CPS are the integration of physical and computational process of many CPS/IoT applications via built-in functionalities.
involving embedded computer and networks, monitoring and This built-in intelligence allows for dynamic sensor de-
controlling the physical processes [48]. CPS integrate physical tection, device selection, deployment of software, system
components (with the deployment of sensors to measure and configuration and reconfiguration [50], [51].
observe the physical components, and the actuators to ensure b) Data requirement: CPS/IoT applications should stipulate
that operations are effectively performed on the physical that collected data meet requirements specified by comput-
components). The communication network helps to transmit ing processes [52]. Without adequate representation of the

9
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
quality of the data, which includes accuracy, lifetime, loca-
tion, and sample time, it is very likely that the computing
processes will misinterpret or misuse the data collected
from physical processes [53]. However, the computing
processes may assume that the data received meets the
requirement. This remains a big issue for computing
services in CPS/IoT.
c) Computing model: Data and services can either be man-
aged centrally or in a distributed manner. Both have
pros and cons, as seen in the cloud-based and proposed
FECIoT-based model, which depicts the centralized and
distributed model, respectively. Since data is growing at an
enormous pace, the main challenge will be in processing
such huge amount of data with the available computing
resources. Other limitations to existing models include
complexity in algorithm design, latency, and communi-
cation among computing components [54], [55].
d) Fault-tolerance: IoT device failure may lead to disruptions
or hazard in many sensitive CPS applications. CPS/IoT
technologies, services, and applications are heterogeneous,
hereby, making interoperability a challenge and making
the system susceptible to failures [54]. As such, efficient
interoperation, integration, and control of CPS/IoT com-
ponents is required for a robust and resilient to unexpected
conditions in the CPS/IoT system [55].
e) Virtual run-time environment: CPS/IoT hardware provides
variety for applications, however, it poses big compatibility
challenge. Virtual machines can ease the deployment of
applications and offer several advantages on resource-
constrained IoT devices [51]. Way and manner of ef-
fectively implementing the virtual run-time environment
remains an issue [56].
f) Security: CPS/IoT systems are prone to security threats
and attacks due to its complexity and dynamic nature. It is
necessary to ensure controlled-access to system resources
and also ensure that unauthorized persons cannot have
access to sensitive information [49]. Eavesdropping, man-
in-the-middle, denial-of-service, and the injection of fake
or malicious sensor measurements or actuation requests
are some of the challenges faced in CPS/IoT [57].
In this section, we have presented basic concepts on IoT-
related areas. This will be useful in having a firm grasp on
the FECIoT architecture discussed in the next section.
III. FECI OT A RCHITECTURE
The term “FECIoT” was first coined by Lin et al. in [2]
with a motive to emphasize the immense potential that could
be derived when the fog/edge computing paradigm is well-
integrated into the IoT architecture. In this section, we present
the FECIoT architectural framework. Fog/edge devices may be
linked to form a mesh to provide load balancing, resilience,
fault tolerance, data sharing, and reduction in the Cloud-
to-Things communication [58]. Architecturally, this demands
that fog/edge devices have the ability to communicate both
vertically and horizontally within the IoT ecosystem. The
FECIoT inherits the basic IoT architecture and delivers all
10
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
IoT requirements in a more efficient way by leveraging on
the distributed FEC paradigm. As mentioned earlier, there
is no generally accepted architecture for IoT. Architectures
presented in previous works only illustrate the way and manner
the authors view IoT. In this paper, we will discuss three (3)
different architectures that have been presented in previous
surveys.
A. Three-Layer Architecture
This architecture is traditional in design and considers three
basic layers [2], [32], [59], [60]. Fig. 4(a) shows the three-
layer architecture comprising of: (i) the sensing layer, (ii) the
network layer, and (iii) the application layer.
(i) Sensing layer: This layer is also known as the percep-
tion layer, acquires data through sensing using Radio-
frequency identification (RFID), sensors, Wireless Iden-
tification and Sensing Platform (WISP),12 actuators etc.
Nodes within radio range of each other may collaborate
for the purpose ensuring ubiquitous data communication
within the IoT network.
(ii) Network layer: This layer performs the task of routing
data across diverse networks. Sensed information is
received from the sensing layer and then routed to
IoT hubs and devices over the Internet. This layer
supports computing platforms such as cloud computing
platforms, Internet gateways, mobile communication,
switching, and routing devices etc. which operate using
state-of-the-art technologies like 5G/LTE, Bluetooth,
WiFi etc., [59], [60]. The network layer uses gateways
to send data to and from applications or things across
heterogeneous networks, and over multiple protocols
and technologies.
(iii) Application layer: This layer provides services (storage,
processing or analysis) based on received data or request
from the network layer. Several IoT applications exist
in this layer with diverse requirements and deployed
together with the middleware functionalities [32]. With
emerging fog/edge deployments, multi-vendor ecosys-
tem applications need to be able to migrate and operate
seamlessly despite system heterogeneity. Applications
should have the ability to span all levels of a deployment
to maximize their value [58].
The three-layer architecture looks simple, however, when
taking a closer look at the network and application layer, we
observe complexities in grafting data services (data aggrega-
tion, data mining and analytics) into this architecture. Thus,
giving rise to a new layer called the service layer.
B. Four-Layer Architecture
This architecture is also known as the service-oriented
architecture (SoA) [2]. The SoA is the application framework
that allows establishments and enterprises to build, deploy and
integrate these services independent of the technology systems
on which they run. Here, the service layer is placed in between
the application and network layer in order to enhance data
12 https://wisp.wikispaces.com/
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
(a) (b) (c)
Three-Layer Four-Layer Five-Layer
Architecture Architecture Architecture
Fig. 4. FECIoT (a) Three-Layer architecture, (b) Four-Layer architecture, (c)
Five-Layer architecture
services in IoT. This service-oriented architecture focuses on
designing the work-flow of coordinated services, and allowing
for hardware/software reuse because it supports the design, de-
ployment, and integration of services, which are not dependent
on the technology platform they operate on [5], [61]. Fig. 4(b)
shows the four-layer architecture comprising of: (i) the sensing
layer, (ii) the network layer, (iii) service layer, and (iv) the
application layer, which are briefly discussed with emphasis
on the service layer.
(i) Sensing layer: This layer is at the base of this architec-
ture, and responsible for data collection, measurement
and extraction of physical devices. This data is passed
on to the upper layers.
(ii) Network layer: This layer provides support for data to
be transmitted over multiple networks and topologies.
Route decisions are made in this layer.
(iii) Service layer: This layer as the name implies, provides
a variety of services. This layer is also known as
the interface or middleware layer. The service layer
can be further broken down into four (4) components,
namely [2], [5], [35], [62]:
• Service discovery: This helps in discovering desired
service request. In [63], a global service discovery
framework was introduced which allows users to
register their own sensors into a common infrastruc-
ture, and discover the available services via a mobile
device.
• Service composition: A sub-layer in the SoA which
provides functionalities for the composition of spe-
11
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
cific services offered by networked objects in building
specific applications. Web of services also plays a
vital role, in the sense that they allow for a pre-
cise definition of capabilities of interfaced objects
and interaction with them [64]. A service request
can be effectively managed by efficient interactions
of the networked object using workflow languages.
Workflows can be nested, and as such represented as
a sequence of coordinated actions carried out by a
single component [5].
• Service management: This provides the primary func-
tional requirements and management for each object.
The functionalities in services may cut across QoS
management, lock management, and semantics. In
addition, newer services may be deployed at run-time,
in order to meet application requirements. Service
repository is carried out in this sub-layer in order
to ascertain service-object pair within the IoT net-
work. The work in [65] compared two alternative
architectures for service management: Open Service
Gateway initiative (OSGi) and REpresentational State
Transfer (REST). OSGi was observed to be simpler
and better suited for homogeneous sensor networks,
while REST was observed to be more complex and
well suited for heterogeneous and widely distributed
IoT devices/services.
• Service interface: This interface serves as a bridge
to connect all provided services. Interfaces are nec-
essary for the reduction of complexities in business
processes [66].
Services, as it relates to FECIoT, are further discussed
in a subsequent section.
(iv) Application layer, is at the top of this architecture,
providing overall support based on system’s function-
alities to end user. Unlike the traditional three-layer
architecture, the application layer is not part of the
middleware, rather it instructs the service/middleware
layer. This layer provides an interactive interface via
standard web service protocols and service composition
technologies over heterogeneously distributed systems
and applications [5], [67]. Examples of such applications
include, smart homes, intelligent transportation, smart
industry, smart health-care, etc.
C. Five-Layer Architecture
This model has a business outlook and is extracted from
the traditional application layer to provide more complex
services [68]. The five-layer architecture comprises of the
following: (i) the sensing layer, (ii) network layer, (iii) service
layer, (iv) application layer, and (v) the business layer. Here,
we focus on the business layer, since previous architecture has
covered lower layers.
The main role of this layer is to record and analyze all
IoT operations that have already taken place across heteroge-
nous CPS. The business layer which carries out petabyte-
scale analytics [4], is also governed by the compliance and
record retention policies. Machine learning models are usually
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
deployed on this layer to enhance operational optimization,
mining insights, business planning. Furthermore, metadata and
reference data management, business rule management, and
the operational health of lower layers are the other aspects of
this layer [58].
The business layer handles the entire IoT system, which
includes applications, business and profit models and users
confidential information [4]. Fig. 4(c) shows the business
layer as an additional feature in the SoA. The SoA actually
facilitates the creation of systems, which support the derivation
of independent business solutions from technological con-
straints [61], [64]. The FEC architecture will play an im-
portant role in reshaping the networking, server and software
industry, with the convergence of routers, switches, storage
and application servers into FEC devices. Furthermore, the
distributed FEC architecture supports the emerging Fog-as-
a-Service (FaaS), where smaller business enterprise can also
participate in delivering private and public services at diverse
scales to end-users [3]. The FECIoT promises better service
delivery to end-users, and also inspire novel business models.
IV. S ERVICES
Prompt response is needed in today’s mission-critical sys-
tems. Fog/edge computing (FEC) will help in complementing
the cloud through mutually beneficial and inter-dependent
services. Storage, computing, control, and communication ser-
vices will be easily executed with this emerging architecture,
thereby minimizing latency and bandwidth demands [69]. The
FEC paradigm enables a service continuum where hierarchi-
cally higher-placed devices can locally provide computing,
control, and even data analytics to hierarchically lower devices
in the IoT ecosystem. A good example is where sensors are
placed on a human body to monitor different body organs. The
smart wristwatch worn by the patient may become the FEC
device by collecting and analyzing sensed data. The patient
may be driving at that instance, as such, the vehicle can serve
as a FEC device to the smart wrist-watch by providing even
more intelligent functionalities, such as an alert display, user
interface, situation update. The roadside traffic control unit
may, in turn, serve as a FEC device to the moving vehicle.
The process may continue until the information reaches the
medical center where further processing may be taken.
It is pertinent to note that cloud services may be deployed
to manage the fog [3], with the fog remotely delivering cloud
services to end-users. IoT management system should be
designed in such a way as to enable end-users to invoke the
most suitable service. Recently, a novel service called Offload-
as-a-Service (OaaS), was introduced in [70]. Though research
in the area of offload computation (OC) has been on for a while
now. Offload computation offers capability to extend mobile
resources limitations in terms of CPU, GPU, memory, storage
and battery life. As mentioned earlier, IoT devices are resource
constrained by default, and as such, there is need to synergize
the offload computation technology with fog/edge computing.
Offloading can be defined as transferring data/services to other
devices, in essence, migrating the computation to stronger and
more resourceful computing devices.
12
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
OaaS in FECIoT will benefit from thousands of readily
available mobile devices, each having some computational
capability. These devices are often under-utilized with extra
storage capacity, idle CPU clocks, free memory, etc. A typ-
ical FEC environment is composed of several FEC devices
such as the pc terminal, Internet gateway, server and smart-
phone/sensor. Each of these devices has services provided by
different service providers.
The scenario presented in [70] considered two (2) service
providers, each service provider provides services to two
FEC devices, and two end-user devices. Fig. 5(a) shows
the OaaS model where IoT end-devices/users can offload
their tasks. These IoT end-devices/users have the intention of
utilizing the OaaS service provided by the service providers.
Before the OaaS is utilized, the IoT end-devices/users must
activate the proposed framework. This will enable the IoT
end-device/user’s preferences to be received/registered by the
framework. Furthermore, the current statuses of the end-user
devices, such as battery level, network bandwidth, CPU speed,
free memory, amongst others will be stored. Based on gathered
data, the framework will locate the best FEC device within
its vicinity to offload computational tasks, as well as establish
communication between users and FEC device for the duration
of the service. With the FEC paradigm gaining more and more
ground, offload computation can now rely on FEC, rather than
traditional cloud computing, in order to enhance capacity and
user experience.
Fig. 5(b) illustrates the service logic behind the FEC
framework. Fog/edge applications will differ from each other
based on deployment, use case, and resource availability. Also,
the FEC applications are composed of a collection of micro
services [58]. These services are briefly explained below:
a) Fog connector services: It is composed of a set of APIs
for enabling higher-layer fog services to communicate with
devices, sensors, actuators, and other platforms using the
edge protocol of choice [58]. The fog connectors translate
the data generated and communicated by the physical
things into a unified data formats. This is then passed on
to the core services.
b) Core services: The core demarcates the edge from the
cloud. This service entails collection of data from the edge.
The collected data is passed on to other higher services
and systems. The core services route request from higher
systems to edge devices [58], [71]. This may also include
receipt and translation of commands from the cloud to
edge devices for actuation.
c) Supporting services: As the name implies, it entails a
large scope of micro-services. This may include logging,
scheduling, service registration, and data clean up. For
example, received data may be logged, scheduled for
processing, or even wiped-off based on this security report.
d) Analytics services: This may encompass both reactive
and predictive capability. The reactive feature is usually
exhibited by fog nodes situated close to the edge of the
network. On the other hand, hierarchically higher-placed
fog nodes which possess more processing capacity usually
have better cognition and predictive ability based on
machine learning [58]. For example, sensors are deployed
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal

FEC
(a) Service
Provider A

FEC
FEC Device 2
Device 1
Offload
Service

IoT End-
Devices/
Things

FEC
FEC Device 4
Device 3
Service
Provisioning

FEC
Service
Provider B

(b)
Fig. 6. Protocols within the FECIoT domain
Logical Service Layers

web and mobile applications, hence resulting in placing in-

FEC creased priority on user-interface in an attempt to improve
Application
Services the overall user experience.

V. FECI OT P ROTOCOLS AND E NABLING T ECHNOLOGIES

Fig. 5. (a) Offload-as-a-Service using the FEC architecture, (b) FEC appli-
cation services
to monitor earthquakes within a city. A single sensor out
of a thousand deployed sensed massive vibrations due to
building construction within the neighborhood, thus rais-
ing a false alarm. The fog node closest to that sensor reacts
immediate due to proximity, however, a hierarchically
higher fog node at the city’s observatory office collates
all responses from sensors. Thus, a predictive judgment is
made based machine intelligence. This prediction can be
used for future occurrences.
e) Integration services: These services allow other FEC de-
vices to register and determine where, when, how, and in
what format the data should be delivered. For example,
a taxi driver may request that all traffic updates within a
particular road axis be sent through REST to a particular
address, hourly, encrypted, and in XML format. During the
client registration phase, a filtering mechanism is specified,
which facilitates the way data is delivered [58].
f) User-interface services: The primary objective of these
services is to display data collected and managed, status
and operation of services, results of analytics, and system
management in the FEC device. For instance, in today’s
world, many companies have increased dependence on the
In IoT, especially for life-critical systems like disaster re-
sponse, it is important to have well-harmonized standards [72].
Considering the distributed architectural framework of FE-
CIoT, scalability, mobility, and compatibility will remain big
issues for heterogeneous devices communicating across di-
verse CPS. To support FECIoT applications with this exigent
and demanding heterogeneous requirements, it is imperative
to consider technologies and protocols that support resource
constrained (limited energy and limited bandwidth) devices.
The IETF has taken the lead in standardizing several commu-
nication protocols that are well-suited for resource-constrained
FECIoT environments, such as, the Routing Protocol for Low
Power and Lossy Networks (RPL) and Constrained Appli-
cation Protocol (CoAP) [21], among others. IEEE and the
ITU have also proposed several IoT protocols within the last
decade. Research is on-going in the design of resource allo-
cation protocols, hereby improving resilience and robustness
of communication, and decreasing the energy consumption
to match stringent energy requirements of constrained de-
vices [102].
Most often, for sensed information to get to the Internet,
several protocols must have provided specialized support.
Fig. 6 show the protocols that can operate under the FECIoT
domain, emphasizing a wide range of protocols within the
fundamental layers, namely, sensing/data-link layer, network
layer, transport layer, services layer, business/management
layer, and application layer. It is worthwhile to note that
some legacy Internet protocols may be applicable in the
IoT domain. However, due to inherently limited processing

13
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
Fig. 7. Stack of some enabling technologies in FECIoT
and communication capabilities of IoT devices, IoT-specific
protocols and standards must be defined. Fig. 7 show the
stack of some enabling technologies that can provide unique
functionalities within the FECIoT domain. A brief overview
of this is as follows:
A. Physical and Data-link layer: Technologies and Protocols
Here, we explore some enabling technologies like RFID,
WISP, WSN, Barcode, which allow for object identification.
Within the proposed FECIoT framework, sensed information
or certain service request is forwarded to a FEC node, which
may decode and process the information, or it may re-forward
such information of request to other FEC devices capable of
handling such data. On this note, we now briefly look into
some protocols and give a summary of each technology along
with their unique functionalities.
1) RFID: The Radio Frequency Identification system is typi-
cally made up of an RFID tag, RFID reader which contains
a coil that serves as an antenna for transmitting and receiv-
ing signals. RFID tags deploy a backscatter technology to
reflect back the radio wave, thus passing on data to the
reader [73]. RFID readers are able to read and extract
the information stored inside RFID tags. RFID systems
operate on 125 kHz, and they require a 12 V power supply.
Unique IDs on tags make it possible for each object/thing
to be independently known without human assistance [74].
RFID devices fall into three categories explained below.
• Active RFID tags: It uses battery to broadcast radio
waves to the reader. The broadcast spans considerably
distance, which is subject to battery power. A practical
example is the LoJack device attached to a car, which
uses both Global Positioning System (GPS) and mobile
technology to track stolen vehicles.
• Semi-active RFID tags: It also uses battery, however it is
based on the same principle as passive tags, and extend
its communication range using the battery.
• Passive RFID tags: Passive RFID tags totally depend on
the power source of the reader. They are usually deployed
on inexpensive items. Example is taking inventories of
large number of items in a store.
RFID-based systems have a lot of advantages in today’s
IoT. Some of which are: (i) its ability to automatically
14
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
pick up tag IDs from a distance without strict consideration
for line-of-sight operations, (ii) its ability to simultane-
ously scan multiple items without having to scan them
independently, (iii) its ability to scan tags speedily (in
milliseconds), (iv) its low cost as compared to prices in
past years. Despite growing potential and popularity, RFID-
based systems face drawbacks in the area of security and
privacy. Also, tag collision may occur when multiple tag
signals are read from the RFID reader simultaneously.
Today, RFID systems are installed in commercial stores
to address shoplifting. Another good application of RFIDs
is in hospitals. For example, an active RFID bracelet can
be attached to the hand of a psychiatric patient for safety
monitoring. If the patient attempts to leave his/her confined
vicinity by passing through the doorway configure with
an RFID reader/exciter, then the exciter triggers the tag,
which in turn sends beacon over the wireless network for
immediate action to be taken.
2) WISP: Wireless Identification and Sensing Platform13 is
a wireless, battery-free platform for sensing and com-
putation. Ultra-High Frequency (UHF) RFID readers are
used to wirelessly power the WISP device. Just like
the RFID-based system, WISP uses backscatter commu-
nication technology, however, it is unique with a fully
programmable micro-controller. Moreover, WISP supports
flexibility unlike conventional RFID tags which are fixed-
function devices with minimal, non-programmable state
machine used to report a hard-coded ID when energized
by a reader [75].
In [76], WISPCam was proposed to allow for battery-free
imaging by harvesting wireless power and using low-power
backscatter communication to both capture and transmit
images. As mentioned earlier, RFID tags are not secure
since they can be compromised by unauthorized persons
that has access to them without the owner’s knowledge.
Due to WISPs programmability, it is possible to address
this limitation within the sensing layer. In fact, WISP
has attracted attention in the area of cryptography and
security [77].
3) WSN: Wireless sensor networks have been around for quite
some time now with a countless number of research publi-
cations. WSNs are made up of tiny nodes with processor,
memory, sensors, and battery, whose primary functional-
ities are sensing and transmitting data [78], [79]. With
global focus on IoT, WSN can be readily deployed into
existing IoT framework with little or no modifications. IoT
supports global interoperability of several networks, includ-
ing the WSN, by unveiling standards that applications can
be built upon [80]. In [81], the authors focused on integrat-
ing WSN into IoT. This was achieved by deploying real-
world wireless sensors that can smartly control appliances
within a building. In [82], both WSN and MANET were
used to boost urban data harvesting in IoT. Experimental
results showed the feasibility and effectiveness of their
approach. Another attempt to integrate WSN with IoT was
presented in [83], where sensor nodes collect data such as
13 https://sensor.cs.washington.edu/WISP.html
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
temperature, humidity, motion detection, illuminance, CO
gas, air quality from the surrounding environment and store
it on the cloud for universal accessibility by the users.
Unlike RFID systems which require the presence of a
reader, WSN communicates in a peer-to-peer (P2P) man-
ner. Though WSN sinks can be used to harvest data
collected, based on the algorithm and configuration of the
WSN. WSN have key features stated below:
• WSN nodes operate on battery with a lifespan of fewer
than 3 years [5], making them energy-constrained.
• WSN nodes also have some processing capability, mak-
ing it useful in intelligent sensing and monitoring [84],
however, its computational capability is limited.
• Scalability and ability to function in harsh and hostile
environments, especially in industry [85].
In 2018, the BeWhere wireless sensors was introduced
in the market which can be used to track and monitor
shipments and get alerts of adverse events that could
happen en route. The Bewhere wireless module integrates
a number of sensors like temperature, humidity, pressure,
accelerometer and a location service, which is GPS. The
sensor features small amount of data storage capability,
small amount of power usage (Two AA batteries that run
for as long as 10 years).
4) BLE: Bluetooth Low Energy is a simple Bluetooth standard
developed to support the transmission very little packets
of data at an instance, while significantly minimizing the
power consumed by the device [86], [87], [88]. BLE
operates on the 2.4 GHz frequency and uses a frequency
hopping mechanism. This mechanism is used to countervail
for fading and interference in the 2.4 GHz Industrial, Sci-
entific, and Medical (ISM) band. Today, many smartphone
manufacturers are beginning to adopt the BLE standard,
with support from major operating systems like iOS, An-
droid, Windows Phone, and Blackberry. BLE devices can
operate in four different modes, they include [89]:
• Peripheral: Server device which provides data to clients
in form of Generic Attribute Profiles (GATT).
• Central: Client device which subscribes to Peripherals
to read and write data.
• Broadcaster: Server device which only supports unidi-
rectional broadcasts.
• Observer: Client device which only scans for broadcasts
but does not initiate connections.
A BLE beacon is a small device which emits BLE signal.
Smartphones within the vicinity can pick up the emitted
signals. In [90], BLE was deployed in industrial and
process automation to help acquire data wirelessly from
substation control room, thereby easing the process of data
acquisition and storage. A practical example of BLE is a
medical device providing periodic glucose measurements
to a doctor’s mobile phone. Another example is in the
area of real-time marketing when a customer enters a less
visited section within the store, the customer, via his/her
Smartphone, may be are offered an instant 35% savings off
their highest-priced item from that section for that day.
15
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
5) NFC: Near field communication14 (NFC) operates based
on the principle of magnetic field induction and has a very
short communication range. This wireless standard enables
devices to communicate only in close proximity to each
other (usually less than 10 cm). It operates on 13.56 MHz
frequency. NFC devices operate in three modes:
a) Card emulation mode: This allows NFC-enabled de-
vices to behave like smart cards, thus carrying out
smart card functions like payments and ticketing.
b) Reader/Writer mode: Here, NFC-enabled devices can
read/write information from and to smart posters.
c) P2P mode: Here, two NFC-enabled devices can per-
form peer-to-peer communication without any network
infrastructure.
Despite the fact that NFC is commercially outpaced by
the Barcodes and RFID technologies, it still has relevance
in several applications. A unique application opened up by
NFC is the opportunity for proximate financial transactions.
Recently, we are beginning to see smartphones doubling
as electronic wallet, even replacing credit cards in a more
integrated virtual form [91], [92], [93].
In [94], an approach was proposed using a smartphone
integrated with an NFC reader and application for the
detection of drug allergies and drug interactions for peo-
ple with multi-morbidity during medication administration.
The work provided strategies of minimizing errors in
medication. NFC can also be used in mobile ticketing [95],
museum tourism [96], and social networking [97], for
sharing contacts, photos, videos or files. Some recent
advancements includes, Apple Pay15 , Google Wallet16 ,
and Android Pay17 , hosted on smartphones that are NFC
enabled.
6) Barcode: Barcode represents encoded digital data which
can be interpreted with an optical machine [98]. Today,
many smartphones are able to read barcodes using their
inbuilt camera, however, they may not be as fast as dedi-
cated factory designed barcode scanners. Types of barcodes
include:
• Linear barcodes: It is also known as one-dimensional
barcode, and composed of lines and gaps of different
widths to create unique patterns.
• Matrix barcodes: It is also known as two-dimensional
barcode, and is similar to the linear barcodes. However,
it can represent additional data per unit area.
Many research advances are recently made in barcode
technology. Today, barcodes are not limited to identification
of items but are capable of sensing environmental changes
like sensors. In [99], a dynamic and sensitive barcode was
proposed to smartly monitor the environment. This was
achieved by using environmentally sensitive materials in
printing the barcode. Hence, the findings can be applied to
IoT and other environmental monitoring application.
7) IEEE 802.15.4: This standard defines the physical and
14 http://nearfieldcommunication.org/
15 https://www.apple.com/apple-pay/
16 https://www.google.com/wallet/
17 https://www.android.com/pay/
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
MAC layers specifications for low-power consumption,
low bit rate communication in wireless personal area net-
works (WPAN) [5], [100]. The physical layer of the IEEE
802.15.4 is responsible for some basic functionalities, such
as sending and receiving data, detecting energy levels of
current channel, link quality indication and clear channel
assessment [101]. Twenty-seven channels are supported
over three frequency bands, with Europe having one chan-
nel, which is operating on the 868 MHz frequency band, the
United States has 10 channels on the 915 MHz frequency
band, and the rest of the world with 16 channels on the 2.4
GHz frequency band. The MAC layer of the IEEE 802.15.4
is responsible for association and disassociation, acknowl-
edging delivered frames, channel access mechanism, frame
validation, guaranteed time slot management, and beacon
management. The IEEE 802.15.4 supports two categories 10) LTE-A: Long Term Evolution-Advanced (LTE-A) was
of devices, which are:
a) Fully functional devices (FFD): This acts as coordina-
tor or master in the personal area network (PAN). It
is responsible for setting up the network and sending
beacon messages and routing packets in the network
based on available neighbors and routers on its list.
b) Reduced functional devices (RFD): This is an end de-
vice which operates at low duty-cycle power, meaning
it consumes power only while transmitting information.
It can collect data from the environment and send them
to a PAN coordinator. It can join or leave the network.
This protocol uses time synchronization and channel hop-
ping to improve reliability, minimize cost, and ultimately
meet IoT requirements. With these merits, the IEEE
802.15.4 can be considered a de facto standard for many
IoT applications [78], [102].
8) IEEE 802.11AH: This is an enhancement to the widely
used IEEE 802.11 wireless medium standard. It is designed
to support low energy consumption, as well as mini- 1) LoRaWAN: LoRaWAN can be mapped to the MAC and
mize overhead in order to meet IoT requirements. Unlike
conventional Wi-Fi that operates on 2.4GHz and 5GHz
frequency bands, it uses the 900MHz frequency band to
provide extended network coverage. Some notable features
makes this protocol suitable for use in IoT applications,
which include target wake time mechanism to enhance
power saving, high achievable data rates, support for large
number of end-devices, and minimal overhead with only
about 12 bytes as compared to 30 bytes MAC frame size
in traditional IEEE 802.11 [102], [103]. In [104], it was
verified using software simulations that IEEE 802.11AH
is suitable for IoT, M2M (Machine-to-Machine), and V2V
(Vehicle-to-Vehicle) applications requiring long battery life
and long range communication.
9) Z-Wave: This is a low power MAC protocol developed by
Zensys18 specifically for home automation [105]. Z-Wave19
is designed for small data packets at relatively low speeds
up to 100 kbps, range of 30 m P2P communication, and
operates at 908 MHz. Its low data rate makes it unsuitable
for streaming or transmitting time critical data [106]. The 2) IPv6: The main reason for introducing Internet Protocol
18 http://www.zensys.com/
19 http://www.z-wave.com/
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Things Journal
Z-Wave protocol has two types of devices:
a) Controllers: The controller initiates commands and
sends them to other nodes/slaves.
b) Slaves: The slaves execute the commands and provide a
response to issued commands. Slaves can also serve as
forwarders of commands received from the controller,
hereby extending communication range.
The Z-Wave protocol uses a 32-bit unique identifier called
the Home ID to differentiate networks. The controller
assigns a home ID to each slave. Slave nodes are also
assigned an 8 bit unique ID, which is unique to that home
ID. The Z-Wave solution can be seen in smart homes,
where the protocol runs over a variety of home appliances,
with smart lighting, smart locks, smart hubs, smart sensors,
and smart thermostats, etc.
standardized by the 3rd Generation Partnership Project20
(3GPP) aims to achieve a higher level of system perfor-
mance [129]. The motivation is to provide higher bit rates
in a cost-efficient way. The additional features in LTE-A are
Carrier Aggregation (CA), enhanced use of multi-antenna
techniques and support for Relay Nodes (RN). With these
functionalities, it is well suited for FECIoT, considering
the fact that FEC devices may be deployed to offer relay
services to other hierarchically higher fog nodes or even to
end-devices.
B. Network layer: Technologies and Protocols
Since we have seen a practical scenario of deploying FEC
devices to aid communication, we go further to present some
enabling technologies and standards that can be used within
the FECIoT framework for efficient communication of IoT
devices.
network layer of the OSI model. The Low Power Wide
Area Network (LPWAN) technology operating in the ISM
band is designed to allow low-powered devices communi-
cate over long range, and can used in various FECIoT sce-
narios. LoRaWAN networks usually deploy a star-of-stars
topology and comprise of distributed gateways (GW) which
relay data between distributed end-devices and a central
network server. Communication between the GW and end-
devices is spread out on different data rates and frequency
channels, thereby eliminating interference. LoRaWAN has
three classes that operate simultaneously; namely Class A,
Class B, and Class C [113], [114]. LoRaWAN data rates
range from 0.3 kbps to 50 kbps and has the ability to
manage the data rate of end-devices using the adaptive
data rate (ADR) scheme [114]. LoRaWAN has attracted
immense attention in areas of capacity and throughput
maximization. A mathematical model was analyzed in
[115] which accurately estimates how packet error rate
depends on the offered load.
Version 6 (IPv6) was to overcome inherent shortcomings of
20 http://www.3gpp.org
16
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
Internet Protocol Version 4 (IPv4). IPv6 adequately handles
scalability by ensuring that a large number of things will
have unique addresses. The IETF’s Internet Protocol Next
Generation (IPng) working group was responsible for stan-
dardizing the specifications. As mentioned earlier, IPv6’s
main motivation is its large address space [116], [117].
With the proliferation of IoT devices, address space will no
longer be a major challenge, but the need to ensure security
to these devices. The IPv6 offers support for Internet
Protocol Security (IPSec). The protocol was designed for
more capable nodes in mind, and the seemingly large
IPv6 addresses are more amenable to cross-layer com-
pression [118]. Furthermore, the IPv6 supports neighbor
discovery (ND). This mechanism enables neighboring IPv6
nodes to communicate, and also determine the presence of
one another. This makes this protocol very suitable in the
FECIoT framework, where FEC devices share reachability
information, and determine available FEC device through
which information can be relayed.
3) 6LoWPAN: IPv6 over Low Power Wireless Personal Area
Networks (6LoWPAN) is an open standard defined by IETF
to support IEEE 802.15.4 low-power wireless networks in
the 2.4 GHz band [119]. It is a networking technology
that enables IPv6 connectivity for constrained embedded
devices that use 802.15.4 low power wireless communica-
tion [120]. Edge routers are used to connect the 6LoWPAN
network to the IPv6 network. 6LoWPAN hosts must ex-
plicitly indicate their presence to neighboring attachment
routers. The edge routers facilitates the exchange of data
between 6LoWPAN devices and the Internet, internally
within the 6LoWPAN network, and overall maintenance
of the 6LoWPAN network. In fact, technologies like 6Lo
leverage on 6LoWPAN to significantly increase the spec-
trum of IPv6-supported technologies [121].
4) RPL: Routing Over Low power and Lossy (ROLL) net-
works working group was formed in 2008 by the IETF
to provide an IPv6-based standardized solution for smart
object networks [122], thus resulting in the Ripple routing
protocol (RPL). RPL operates at the IP layer and allows
for routing across diverse link layer protocols, unlike other
forms of “routing” operating at the lower layer. RPL is
a Distance Vector IPv6 routing protocol for Low power
and Lossy Networks (LLNs) that defines how a Destina-
tion Oriented Directed Acyclic Graph (DODAG) is built.
Graphs in RPL are based on logical routing topology to
meet certain predefined objectives. RPL supports point-
to-point (P2P) communication and provides the ability
to perform multi-topology routing (MTR). The protocol
was specifically designed to be robust and highly adaptive
in situations where default routes are inaccessible. RPL
can also support 6LoWPAN networks in a route-over
configuration [122]. In [123], the Contiki COOJA simulator
was used to explore the efficiency of RPL, as well as its
QoS in monitoring applications. The work proposed further
research to optimize the RPL signaling in order to decrease
the protocol overhead, despite the algorithm’s fast network
set-up and limited delays.
5) CORPL: Cognitive RPL (CORPL) is an extension of
17
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
RPL protocol, and was designed specifically for cognitive
networks. Just like RPL, it also uses the DODAG topology,
and opportunistic forwarding in order to forward the packet
between nodes [102]. The parent nodes, as well as every
other node maintains forwarding list and updates the list
periodically. Based on the updated information, it uses a
cost function approach to dynamically prioritize the nodes
in the forwarder set [124].
6) Sigfox: Sigfox21 is a lightweight network protocol that
handles machine-type messages, thus minimizes energy
consumption. Sigfox operates in the 200 kHz frequency
band using Ultra Narrow Band modulation. This technol-
ogy is specifically designed to meet the requirements of
massive IoT applications, longer device life-cycle, lower
cost of devices, higher network capacity, and longer com-
munication range [125]. Sigfox offers a throughput of only
0.1 kbps rendering it a candidate for low traffic applica-
tions [126]. A key feature of this technology is its software-
based communications solution, where all network and
computing complexity is managed in the Cloud. Sigfox
will have better potential within the FECIoT architecture
due to the ability of FEC devices to carry out some of its
task closer to the edge of the network.
7) CARP: Channel-Aware Routing Protocol (CARP) is a
cross-layer distributed routing protocol specifically de-
signed for wireless sensor networks. CARP exploits link
quality information for cross-layer relay determination,
with nodes selected as relays if previous transmissions
with neighboring nodes have been successful [127]. Fur-
thermore, the protocol also takes into consideration power
control mechanisms for selecting robust links. The protocol
can be effectively deployed within the FECIoT domain
since it supports lightweight packets [102].
8) E-CARP: Enhanced Channel-Aware Routing Protocol (E-
CARP) is an enhancement of CARP designed by Basagni
et al. in [127]. This protocol aims to achieve location-
free and greedy hop-by-hop packet forwarding strategy. E-
CARP significantly reduces the communication overhead
and can be effectively deployed for FECIoT applications.
Moreover, the strategies used in E-CARP decreases the
energy consumption when the environment to be monitored
is relatively steady [128].
C. Business/Management layer
In order to enhance interoperability among diverse appli-
cations, topologies, and technologies, business/management
layer standards needs to be well designed. Thus, we present
some of the available standards.
1) IEEE Std 1905.1aT M -2014: With the inherent complex-
ities involved in interfacing applications, topologies, and
technologies within the IoT domain, management standards
need to be effectively deployed to handle these require-
ments. The IEEE Std 1905.1a defines an abstraction layer
that supports a common interface for the deployment of
several home networking technologies [130]. As packets
21 www.sigfox.com
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
arrive from any interface or application, connectivity se-
lection is carried out by the IEEE Std 1905.1a abstraction
layer. This abstraction layer is between layers 2 and 3,
and each interface is abstracted separately, hence allowing
for seamless integration. The layer also ensures end-to-end
QoS, providing a platform for increasing network range,
establishing secured connections, and other network man-
agement functionalities like discovery, path selection, auto-
configuration, and QoS negotiation. This standard can be
readily deployed to FECIoT with features like self-install,
aggregated throughput, load balancing, and its support for
multiple and simultaneous streams.
2) IEEE 1451: Due to heterogeneity in standards of devices,
the IEEE 1451 set of standards was developed to inte-
grate the different standards and protocols by providing
a unified protocol which supports interoperability between
sensor/actuator networks and busses [131]. An important
feature of these set of standards is defining Transducer
electronic data sheets (TEDS) for each transducer which
are communicated in the same format on the Internet,
independent of the type of physical layer device. The
hardware interfaces support open standard interfaces like as
RS-232/ USB, CAN, IEEE 802.11, Bluetooth, and ZigBee
(802.15.4). It manages nearly all smart sensors, allowing
for interoperability and inclusion in the network, and also
making it adaptable to the FECIoT framework.
D. Services
1) WSDL: The Web Service Description Language (WSDL)
standard uses Extensible Markup Language22 (XML) syn-
tax to address capabilities and invocation mechanisms of
web services. Usually, services contain all information
of a physical object, consisting of both functional and
non-functional components [132]. In essence, it describes
Web services based on an abstract model of what the
service offers. Furthermore, WSDL is extensible to allow
description of endpoints and their messages irrespective of
the type of format or protocol used in communication.
WSDL is often deployed together with Simple Object
Access Protocol (SOAP) and an XML Schema to provide
Web services over the Internet.
2) SOAP: Simple Object Access Protocol (SOAP) is a pro-
tocol specification that prescribes an unambiguous XML
message format. Here, service requests and responses are
encapsulated in an XML-based way. This may entail re-
quests to invoke a method on a service, responses from
a service method, or errors from a service. SOAP is a
transport-agnostic messaging system which describes the
structure and data types of message payloads by using the
emerging the World Wide Web Consortium (W3C) XML
Schema standard. SOAP requests and responses travel
using HTTP, HTTPS, or some other transport mechanism.
Considering resource constrained IoT networks, [133] pro-
posed a strategy to bind SOAP to Constrained Application
Protocol (CoAP), thus resulting in a lightweight protocol
that can be readily deployed in the FECIoT framework.
22 https://www.xml.com/
18
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
http://...
Thousands
Endpoint
of bytes http://... Proxy
Subscriber
Tens of coap://...
bytes
Few bytes
Fig. 8. Comparison of IoT Protocols
This is due to the fact that in highly resource-constrained,
the HTTP and UDP protocols binding may not yield
desired network performance.
E. Security
1) DTLS: Datagram Transport Layer Security (DTLS) in
Constrained Environments (DICE) working group worked
on supporting the use of DTLS in both constrained devices
(e.g. memory usage, security algorithm) and constrained
networks (e.g. PDU sizes, packet loss). Since the IoT
environment is highly susceptible to attacks, the working
group defined the DTLS record layer which can be used
to transmit multicast messages securely, and this will
require the use of session keys. Also, due to possible frag-
mentation, re-transmission, and reordering of messages,
DTLS handshaking mechanism can be effectively used to
minimize potential complexities in the system.
In fact, DTLS binding makes CoAP secure as seen in
Fig. 8. In [134], an architecture which reduces the possi-
bility of a Denial of Service attack in constrained devices
was proposed using a strategic DTLS procedure. The
procedure employed a third party device called the Internet-
of-Things Security Support Provider (IoTSSP) and two
main mechanisms (the Optional Handshaking Delegation,
and a new extension of DTLS, called Transfer of Session).
2) TLS: Transport Layer Security (TLS) is widely deployed
and resides between the transport and application layer.
TLS requires reliable transport, and as such, it will in-
cur additional overhead within the network. IoT applica-
tions are best suited with UDP than TCP, due to UDP’s
lightweight. Just like DTLS, Transport Layer Security
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
Fig. 9. Message queuing telemetry transport (MQTT) architecture
(TLS) provides a lot of flexibility in terms of credentials,
and choice of encryption algorithm. However, bandwidth
constraints subject TLS to be used only for secure key
exchange and to setup secured data connection in some
IoT scenarios [135]. Recently, the GUARD TLS, also
known as MatrixSSL was introduced. The MatrixSSL is a
modular implementation of TLS and DTLS ideally suited
for IoT usage due to its minimum memory footprint and
efficient RAM utilization. It is delivered as a lean and well-
documented C source code for easy integration. It is ideal
for the proposed FECIoT framework.
F. Application layer
1) MQTT: Message Queue Telemetry Transport23 is well-
suited for low-bandwidth and high-latency constrained net-
works. This protocol is known for its many-to-many com-
munication, thus, making it suitable for real-time sensor
data. The aim of this protocol is to connect embedded
devices and networks with applications and middleware.
The MQTT architecture comprises of the MQTT client
(Publisher/Subscriber), MQTT broker (Central server), and
other components as seen in Fig. 9. The primary function
of the publisher is to continuously produce and send data
to the server. The message is received by the server and
then forwards it to the intended device. Also, previously
registered devices will continually receive message unless
subscription is terminated. The central server has the capac-
ity to handle thousands of MQTT clients simultaneously.
The lightweight protocol can be readily deployed in the
FECIoT framework since it utilizes network bandwidth
efficiently. However, it is noteworthy that implementing
stringent security policies may undermine the lightweight
nature of the protocol.
A Fog-based scheme which was built over the lightweight
MQTT protocol was presented in [136], with results show-
ing significant reduction in the energy consumed. The work
further revealed that with higher QoS levels, the model is
cost-efficient. The protocol can also been used to monitor
oil pipelines miles away. The protocol has been applied
in cases of network latency due to occasional bandwidth
constraints or unreliable connections. In fact, the Facebook
mobile app uses MQTT to deliver messages efficiently in
23 https://mqtt.org/
19
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
(a)
Gateway
(b)
Fig. 10. Architectural model for (a) Extensible Messaging and Presence
Protocol (XMPP) (b) Advanced Message Queuing Protocol (AMQP)
milliseconds despite poor network connectivity. MQTT is
also supported by the Amazon Web Services (AWS) for
connecting remote devices to the Amazon IoT cloud.
2) XMPP: Extensible Messaging and Presence Protocol24
(XMPP), also known as Jabber, is an IETF standardized
protocol that well suits the FECIoT domain since it ad-
dresses issues of security and interoperability. This protocol
is highly scalable, however, it consumes bandwidth and
processing power with no guarantee on QoS [137]. XMPP
supports diverse open source software for servers, clients,
and libraries that support different operating systems and
provides the platform for possible enhancements, thereby
providing significant cost savings and reducing complex-
ity [138]. In essence, this protocol facilitates technology
agnostic and protocol independent transport of data over
wired or wireless networks including the Internet. From
Fig. 10 (a), we can see that the XMPP protocol sup-
ports request/response model which allows for bidirectional
communication, and also supports publish/subscribe model
which allows multi-directional communication. The popu-
lar instant messenger, WhatsApp25 , uses a slimmed-down
version of XMPP.
3) CoAP: The Constrained Application Protocol (CoAP) was
created by the IETF Constrained RESTful Environments
(CoRE) working group. This protocol was specifically
designed to overcome some of the limitations of HTTP in
meeting with IoT application requirements. CoAP defines
a web transfer protocol based on REpresentational State
24 https://xmpp.org/
25 https://www.whatsapp.com/
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
(a) REST
Internet
Constrained Network
(using CoAP)
(using HTTP)
(b)
CoAP GET Requests
CoAP Responses
CoAP Client
Fig. 11. (a) CoAP and HTTP in Constrained and Unconstrained Environments
(b) CoAP Interaction
Transfer (REST), which operates over HTTP functionali-
ties [11]. Fig. 11 (a) shows the interoperability of CoAP
and HTTP in constrained and unconstrained environments.
CoAP uses an asynchronous means to support pushing
information from servers to clients [139]. Fig. 11 (b) show
a typical client/server interaction using CoAP. This inter-
action helps in request confirmation. For instance, a CoAP
client may send a GET message, requesting for the room
temperature from a CoAP server. The request is confirmed
if an ACK message containing the room temperature is
then received by the client. CoAP is a suitable application
protocol for the IoT, and can readily be deployed in the FE-
CIoT framework [120]. Despite operating over traditional
IP networks, the CoAP protocol is governed by the ROLL
and 6Lo working groups which have more constraints
when compared to the traditional IP networks. Proxies
may be deployed to interconnect devices using CoAP with
other Internet protocols. Caching is also supported in order
to minimize the energy consumed in low-power nodes.
CoAP operates over User Datagram Protocol (UDP) and
Datagram Transport Layer Security (DTLS). UDP, which
may be seen as a best-effort datagram delivery transport
layer protocol, is made reliable at the application layer and
offers minimum protocol mechanism [140]. This makes it
useful for machine-type communication. DTLS, which is
based on the TLS, allows client/server applications like
CoAP to communicate over the Internet by preventing
eavesdropping, and forging of messages.
4) AMQP: The Advanced Message Queuing Protocol
(AMQP) is an open source standard that supports com-
munication between diverse applications across heteroge-
neous devices and networks. The protocol was initially
developed for speedy M2M communication. AMQP fully
supports functional interoperability between conforming
clients and messaging middleware servers (“brokers”) as
seen in Fig. 10 (b). The AMQP protocol is multi-channel,
negotiated, asynchronous, secure, portable, neutral, and
efficient. AMQP can be divided into two useful layers,
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Things Journal
the Functional and Transport layer. The functional layer
defines a set of commands that carry out tasks on behalf
of the application, while the transport layer delivers these
methods to/from, between the application and server. The
AMQP server has functionalities similar to an email server,
with each exchange acting as a message transfer agent, and
each message queue as a mailbox [141]. The Windows
Azure Service Bus uses AMQP 1.0 to build applications.
The AMQP 1.0 defines a portable data representation.
Messages sent to the Service Bus from a .NET program
can be read using any Java, Python, Ruby, etc., thus, the
protocol is able to glue together applications that span over
the FECIoT ecosystem.
CoAP Server
VI. S IMULATION IN THE FECI OT D OMAIN
Simulators are valuable tools for system development, and
are considered an alternative to prototyping since it signifi-
cantly depicts the actual testbeds where devices are physically
installed, connected and configured. Theoretically, a simula-
tion should not be limited by the amount of installed devices or
data transmitted. Simulation-based approaches gives room for
researchers and developers to repeatedly carry out experiments
in a controlled manner, lesser cost, and collect data, which can
be useful in validating hypothesis, or some analytical results.
Since simulations gives flexibilities in tuning parameters based
on diverse networking scenarios. A FECIoT simulator needs
to provide high accuracy for diverse heterogeneous scenarios,
provide computational support for complex network design,
provide for scalability, provide for mobility based on realistic
scenarios, and support extensibility. In Table III, we compare
some possible FECIoT simulators based on various features.
With a wide range of available simulators, IoT researchers
are left with the choice of selecting a suitable simulator that
satisfies their research objectives [142].
However, in order to meet the demand of a full-fledged
FECIoT architecture, we propose the use of multi-level sim-
ulators as proposed in [143], [144]. A multi-level simulation
glues together multiple simulation models, with each model
performing a unique task. Multi-level simulation is considered
as a major framework that supports the simulation of large-
scale IoT networks while retaining high-level of details. This
can be seen in [143], where smart service are deployed in
decentralized territories. An adaptive, agent-based, Parallel
and Distributed Simulation (PADS), integrated with multilevel
simulation can be employed within the context of FECIoT.
The FECIoT framework can be simulated using different
simulation tools, such as Network Simulator (NS-3) [145],
Cooja [146], NetLogo [147], IoTSim [148], iFogSim [149],
CupCarbon [150], OMNET++ [151], QualNet [152] amongst
others.
1) NetLogo: NetLogo31 was authored by Uri Wilensky32
in 1999, and often used for modeling complex systems
developing over time. This simulator runs on the Java
virtual machine, thus making it compatible with major
31 https://ccl.northwestern.edu/netlogo/
32 uri@northwestern.edu
20
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal

TABLE III
C OMPARISON OF SOME POSSIBLE FECI OT SIMULATION TOOLS

Simulation Tool NS-326 [145] Cooja27 [146] NetLogo IoTSim [148] iFogSim28 CupCarbon29 OMNET++30 QualNet [152]
[147] [149] [150] [151] (GloMoSim)

Latest Release 2017 (NS 2015 2017 2017 2017 (v2.0) 2017 (U-One 2017 (v5.2.1) 2017 (v8.1)
3.27) (Contiki 3.0) (NetLogo 3.8)
6.0.2)
Language C++ C/Java Logo Java Java SenScript C++ C/C++
GUI/Command Command Both Both Both Both GUI Both GUI
Type Discrete Discrete Agent-based MapReduce Discrete Agent-based Discrete Discrete
event event event and Discrete event event
event
FEC
Capability Moderate Moderate Moderate Moderate High Moderate Moderate Moderate
Scalability High Low High High High Low High High
Built-in
IoT standard LoRaWAN Yes No No No LoRaWAN, Available Zigbee
LoRa, extensions
802.15.4
Node
Heterogeneity Yes Yes Yes Yes Yes Yes Yes Yes
Protocol
Heterogeneity Yes Yes No Not known Not known Yes Yes Yes
Mobility support Yes No (Plugin) Yes No Yes Yes Yes Yes
(MyiFogSim)
Extensibility Yes Yes Yes Yes Yes Not Known Yes Yes
Limitations Does not Memory May not be Restrictions Does not Not scalable. Compatible Not open
guarantee limitations of powerful in handling support user issues may source, high
flawless the emulated enough to IoT device arise when purchasing
real-world node which model a truly applications mobility, combining cost.
behaviour. limits asynchronous that have Access Point different
number of system. real-time and is not models.
deployed low-latency available, no
motes. requirements. migration of
virtual
machines.
Other features Easy to use Supports User-friendly Fault- Supports 2D/3D Supports Supports
flow-monitor holistic platform, injection real-time visualisation, animation 802.11s,
for collecting simultaneous rapid models, stream useful for and Built-in
network simulation at prototyping big-data processing. generation of interactive measurement
statistics. different tool to processing. networks for execution, on each
levels. develop OMNET++, supports layer,
larger and detailed energy Supports fast
more energy modeling. real-time
complicated diagram rep- traffic
systems. resentation. modeling.

operating systems like Windows, Linux, MAC etc. It is
the next generation of the series of multi-agent modeling
languages. It is fully programmable, has a user-friendly
syntax, a variation of the Logo language that supports
agents, supports mobile agents, and links agents to form
a network/graph. In this paper, we experimented using
NetLogo to visualize IoT data/services flow within the
FECIoT ecosystem. A scenario is proposed where IoT end-
devices communicate directly with the centralized cloud
infrastructure (Cloud-to-Things model) with full-fledged
directory and another scenario where distributed FEC de-
vices having partial directory communicates with proxi-
mate IoT end-devices (FECIoT model) [153]. We measured
the system performance based on certain key performance
indicators (KPIs) such as storage efficiency, computational
efficiency, service/device discovery, and network efficiency
with respect to traffic. However, energy consumption and
some other KPIs were not considered in the simulation.
Table IV shows a summary of the parameters used in
simulating the output in Fig. 12 (a) and (b). IoT end-devices
are randomly distributed within the 61 × 41 simulation
space in Fig. 12 (a) and (b), and 5000 simulations are
carried out. In the simulations, we assume that every node
attempts to connect with the nearest available supernode
(a node with higher computational and processing capa-
bilities). In Fig. 12 (a), all end-devices were configured

21
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal

(a) TABLE IV
N ET L OGO S IMULATION PARAMETERS

Parameter Values
Number of simulations 5000
Simulation dimension box 61 × 41 spaceunits
Number of IoT end-devices 999
Number of fog nodes 10
Number of cloud infrastructure 1
Average node degree 2
Maximum Time-To-Live (TTL) 100 timeunits
Probability of failure 0.3
Maximum number of failing nodes 100

(b)
Unit
1.1
1 1 1 1

Normalized values
0.88
0.750.75
0.66

0.5 0.5
0.44

0.22

Key FECIoT Model Centralized Model

IoT End-Devices
Fog/Edge Devices
Centralized Cloud Infrastructure Key
Storage Efficiency Computational Efficiency

Fig. 12. NetLogo Simulation using 999 IoT End-Devices (a) Centralized Service Discovery Network Efficiency
Cloud-to-Things model, (b) Distributed FECIoT model using 10 fog nodes
Fig. 13. System Performance based on Simulations

to reach out to the central infrastructure for computation,
storage, and service/data request, while in Fig. 12 (b),
the end-devices were configured to reach out to available
and geographically close FEC devices. The average node
degree as used in our simulation is 2, which defines
the number of neighbor nodes. An upper bound of 100
timeunits was experimentally set for Time-To-Live (TTL).
From Fig. 13, we can see that the storage efficiency in
the decentralized FECIoT framework is much higher than
the centralized model. This is because the FEC devices,
which are geographically closer to the end-devices, sup-
port localized storage and computations with lesser delay
and transmission overhead as will be experienced in the
centralized model. Network efficiency for the centralized
model is a little better than the FECIoT model, due to
the fact that the centralized infrastructure uses a single
message to discover devices/services. This is not the case
with the FECIoT model where packets are flooded leading
to increased traffic in the network. From observation, there
is going to be a trade-off between energy utilization and
efficient service/device discovery in the centralized model.
In general, we observe that the FECIoT model exhibits
good balance in the overall KPIs considered. In our future
work, we aim at experimenting on real-world testbeds to
help validate the simulation results. However, the cost
(acquisition and configuration) of setting up real-world
testbeds could be major challenge.
2) Cooja: Cooja runs on Contiki33 , which is an open source
operating system for the IoT. The Contiki OS runs on
tiny low-power microcontrollers, thus making it possible to
develop applications that efficiently utilize hardware while
providing standardized low-power wireless communication
for diverse hardware platforms. Contiki fully supports the
IPv6 and IPv4 standard along with low-power wireless
standards like 6LowPAN, RPL, CoAP etc. Contiki applica-
tions are written in standard C language The Cooja simula-
tor is a flexible Java-based simulator designed for simulat-
ing networks of motes/node (depending on functionalities)
running the Contiki OS. Cooja supports simultaneous sim-
ulation at the network level, the operating system level,
and the machine code instruction set level. Fig. 14 shows
the Cooja simulation environment with 50 motes/nodes.
Motes can be assigned different functionalities based on
the considered scenario.
3) CupCarbon: CupCarbon is a traditional wireless sensor
network, smart city, and IoT simulator that is multi-agent
and discrete event-based. It uses the concept of geo-
location to model and simulate sensor networks on digi-
33 http://www.contiki-os.org/

22
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal

Link 1 via R1
Link 2 via R2
Link 3 via R3
Link 4 via R4

R2
R1 Obstacles or large
separations (i.e. No
line-of-sight exists) R3
from ISN to SFN.
R4

Fig. 14. Cooja Simulation Environment Destination FEC device (SFN)

offering localized services to the
IoT devices
Potential static/mobile FEC relay
(RFN) candidates to forward
tally represented “OpenStreetMap”. The simulator provide recieved data to the SFN

better optimisation of the simulation time by leveraging
on the parallelism of agents and events [150]. The key
components of this simulator are (i) a multi-agent sim-
ulation environment which allows for running simulations
and monitor various event over time, (ii) mobile simulation
for coordinating mobility of agents, and (iii) the WSN/IoT
simulator which is basically kernel of CupCarbon used
for simulating sensor events. A major feature with this
simulator is it’s 3D environment which helps to do an
accurate deployment where the elevation can be taken
into account. This simulation tool can be well suited
for the FECIoT framework, since it allows for multi-
agent simulations which can be used to parallelise the
behaviour of each IoT end-devices, and also for discrete
event simulations which is used to simulate the interactions
among IoT devices.
4) Mathematical Approach in Simulating Communications in
FECIoT Networks: Fog/edge devices are notable for sup-
porting mobility, as well as real-time processing of data and
service requests from a wide variety of IoT end-devices.
For instance, a smartphone, smart wrist-watch, industrial
robot may become a fog device to provide local control and
application data analytics to IoT end-devices within any
cyber-physical system. Furthermore, FEC devices can act
as relays within the IoT ecosystem, in order to improve the
resilience of the network. In a heterogeneous and multi-tier
fog-based IoT architecture, diverse services can be offered
at different layers and by different vendors. In fact, the
destination of some data and service requests may be some
hops away from the source. In this section, focus on the
communication link between the source and destination via
a fog relay. It is known that most IoT end-devices are often
isolated due to sparse deployment, making them prone to
obstructions and no line-of-sight link. As such, it will be
necessary to deploy FEC devices as relays in order to
efficiently minimize communication outage. Several works
in [107] - [110] focused on improving the communications
within the IoT ecosystem. Hence, we propose using a single
relay scenario to model outage probability from source
(IoT end-device) to destination (static fog node) as seen
in Fig. 15.
IoT sensor node (ISN) capable of
sending data or service request via
Relay R in Set {R1, R2,..., R n}
Fig. 15. Single-hop IoT communication using FEC devices as relays.
We assume two consecutive time slots where the source
transmits data to the relay fog device in t time slot, then
the relay will amplify and forward the received data to
the destination in (t + 1) time slot. In both time slots,
we assume that there is perfect synchronization between
the communicating nodes. We can now formulate the
optimization problem to satisfy certain constraints based
on the approach in [111]. The outage probability is derived
as,
t
 N0 γ̃ 
Pout = 1 − (1 + 2Ψ2 ln Ψ) exp − t t −α (1)
PI (DI )
q
where Ψ = (N0 γ̃)/(PRt+1 (DSt+1 )−α ), PIt . As such, our
objective will be to minimize the outage probability by
optimizing the power and location of the fog relay.
t
t+1
min t+1
Pout
PIt , PR , DIt , DS
s.t. PIt + PRt+1 ≤ Pmax , (2)
PIt , PRt+1 ≥ 0,
δ∆ ≤ ι
where PRt+1 are the transmit power of the IoT end-device
and the fog relay, respectively. Also, DIt and DSt+1 are the
distances at two consecutive time slots. ι is the mobility
constraint on the change in position δ∆ fog relay, N0 is the
noise power, α is the path-loss index. From (1), we can see
that the outage probability in time slot t depends on power
and location parameters in time slot t and (t + 1). We can
see that the problem in (2) is non-convex, and as such, we
propose an iterative algorithm based on the steepest descent
method [112]. In our work that is recently submitted for
review, we propose a joint location and power optimization
(JLPO), and compare the performance with the traditional
fixed approach where no optimization is carried out. The

23
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
Fig. 16. Time slot, T vs. Outage probability, Pout .
JLPO scheme jointly optimizes power and location of the
relay. Fig. 16 shows the outage probability over 600 time
slots. Results from our simulations reveal the JLPO scheme
yields better performance. In essence, this approach can be
used prior to deployment of fog relays in any FEC-based
IoT network.
VII. S ECURITY AND P RIVACY
Security is important for the safe and reliable operation of
connected IoT devices. With pervasive data emanating from
heterogeneous systems, data confidentiality, integrity, privacy,
as well as authentication to verify data source is very impor-
tant. IoT data networks, just like the traditional data networks
are susceptible to diverse attacks such as eavesdropping, denial
of service, man-in-the-middle concept, data and identity theft,
to mention but a few. Legacy Internet systems use some
form of encryption and authentication across the link layer,
network layer, transport layer or application layer, in order to
mitigate attacks, however, due to processing limitations of IoT
devices, it is almost impossible to deploy full-fledged security
suites [154].
The FECIoT helps in overcoming some of the challenges
encountered in existing IoT architectures that use the cloud
computing-based model. In the aspect of security, FEC devices
can be deployed as proxies for IoT end-devices. These proxies
help in managing and updating security credentials of the
IoT end-devices. Due to the resource and computationally-
constrained nature of these devices, the FEC nodes helps in
performing security functionalities, such as malware scanning,
monitoring the security status of distributed systems in a
scalable and trustworthy manner, and also able to detect real-
time threats without compromising service delivery [3].
Despite the merits of FECIoT, there exist several security
issues associated with this architecture. In this section, we
present some security features of FECIoT and possible security
attacks in FECIoT.
24
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
A. Security Features in FECIoT
Security requirements impact different layers depending on
the specific security principles [155]. We briefly discuss some
important security features in FECIoT.
1) Trust: Establishing communications between IoT devices,
FEC devices, and infrastructures in the cloud requires some
level of trust. Also, to effectively implement trust within
the FECIoT architecture, devices need to be equipped with
adequate security, making them trusted elements. When
trusted devices are deployed, it provides the basis for a
secure FECIoT ecosystem [58]. Authentication and trans-
parency play an important role in fostering prior relations
between devices [156]. Trust is not limited to communica-
tions among devices, rather covers the relationship between
different IoT layers and applications. Devices within the
IoT devices are susceptible to malicious attacks, and as
such, trust is often built based on previous interactions. For
example, FEC devices offering services to IoT end-devices
should be capable of validating the genuineness of services
requested by end-devices based on previous experience,
this is known as reputation. Similarly, IoT end-devices that
send data/requests should be capable of verifying whether
the intended FEC devices are trust-worthy. As such, en-
forcing trust within the FECIoT architecture will require
a robust trust model to ensure reliability and security.
Due to mobility and the distributed FECIoT architecture,
estimating the trust-level provided by the fog service
providers remains a big challenge. This is not the case
using the centralized architecture, where trust assessment
is handled by a third party, usually a certificate authority
(CA). Several trust-management models have been applied
in cloud computing domain, using artificial intelligence,
fuzzy methods, game theory, and Bayesian estimation-
based techniques [157] [159], however, many of these
models may not be practical in the FECIoT framework,
which requires lightweight trust assessment models.
2) Authentication: This involves entity identification. Before
a device can become part of any given network, it is
necessary that the device is first authenticated. However,
the constrained nature of IoT devices makes it even
more challenging when considering complexity in both
registration and re-authentication phases. Traditional au-
thentication mechanisms using certificates and Public-Key
Infrastructure (PKI) are not suitable due to the resource
constraints of IoT devices [156]. FEC-based authentication
servers will be a better choice for the centralized cloud
authentication servers, due to the distributed nature and
proximity of FEC devices. The issue of authentication in
FECIoT has been discussed in previous works, however,
no comprehensive solution has been provided [9]. Mobil-
ity within the FECIoT architecture also poses an issue
to IoT end-devices, as devices will need to authenticate
themselves to newly formed fog layer, especially when
the previous connected FEC node transits. Therefore, it is
important to design a robust authentication mechanism in
FECIoT.
3) Integrity: Integrity ensures that data or service request
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
cannot be altered during the process of data transmis-
sion. Integrity is assured only when the intended and
authorized entity receives data accurately as was sent.
Compromised data may cause serious disruption within
the network and further cause harm to the operation of
the IoT application [2]. In [160], a sampling and signature
scheme was presented, providing opportunity to relieve the
burden of the network, where the local collector acts as the
coordinator and periodically transmits the sampled packets
to the global traffic analytic. This scheme was able to
provide integrity and can be modified to suit the FECIoT
framework. A Game-theoretic approach was adopted in
[161] to examine the best strategies to slowly corrupt the
integrity of an IoT network. This approach can be used in
designing better defensive measures in FECIoT.
4) Confidentiality: Confidentiality ensures that only autho-
rized users/devices can have access to useful information
or modify it, hereby keeping unauthorized users/devices
away from interfering with data and services. Data in
the FECIoT framework flows from the physical devices
(e.g. sensors and actuators) through to FEC devices and
then to/from higher layers. This increases the chance for
this data to be accessed by malicious devices within
the network. It is pertinent to address the access control
mechanism and also the device authentication process [13].
Ensuring confidentiality in the FECIoT domain is quite
difficult due to scalability issues. Also, controlling access
to heterogeneous data and services is a complex task due
to the real-time nature and response within the system. For
example, consider body monitoring application, whereby
health information of a patient is fed to fog devices (e.g.
smartphones, smartwatches etc.) to give a prompt warning
for medical attention in cases of danger. This information
should be highly confidential, however, if there is a leakage
of this information to malicious devices, such information
could be altered and cause serious damage to the health-
care provider.
5) Privacy: Privacy ensures that data is accessed only by
the corresponding entity/device within the network. It is
important to ensure that other users/devices may pos-
sess some specific controls based on received data, but
should be unable to infer other useful information from
the received data [2]. Due to the huge number of IoT
end-devices, and sheer volume of data flowing within
the FECIoT ecosystem, privacy cannot be undermined.
As such, personal data of IoT end-users should be kept
private and stored effectively for strict access by only
authorized users/devices. For example, in a health-care
delivery system where real-time patients data are monitored
and transmitted via a series of FEC devices that perform
certain processing on the received data. The data may be
sent via other nodes, however, no useful information should
be gathered if an attempt is made by an unauthorized inter-
mediary node. The relay FEC devices should only render
a store and forward service, without attempting to infer
users’ personal information. Several security mechanisms
can help in minimizing privacy threat in FECIoT, they
include, reducing data acquisition and knowledge gathering
25
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
in FEC devices, and minimizing data stored by effectively
discarding raw data after the secondary context is derived.
However, implementing these mechanisms may have some
trade-off with system performance.
6) Availability: Availability is a very crucial security feature
in FECIoT. It ensures that data and system resources should
be available to authorized users/devices requesting for data
or services. Most IoT applications are latency-sensitive,
and as such, any downtime in system operations may
have an adverse impact on end-users. Distributed denial of
service (DDoS) attack is one that renders data and services
unavailable to legitimate users/devices. Just recently, the
servers of Dyn, a company that controls much of the
Internet’s domain name system, was attacked. This led to
an outage in several web services in Europe and America.
7) Access Control: Access control is the process of deter-
mining whether users/devices can have access to system
resources, this could be data, or services [159]. This
process involves denying or revoking access, especially
to unauthorized users/devices. Before the access control
process, authentication phase must have been carried out.
Robust access control techniques are important in ensuring
secure interoperability between heterogeneous devices and
applications within the FECIoT ecosystem. Several access-
control mechanisms have been proposed using the Cloud-
Things model. Many exploited hybridization of several
encryption schemes to develop an efficient data access
control mechanism. In [162], an access control system
was developed which enables offloading of complex access
control decisions to third, trusted parties. The design which
is based on a simple communication protocol imposes
minimal overhead. Thus, making it suitable for FECIoT
applications.
B. Possible Security Attacks in FECIoT
Here, we present possible security attacks in FECIoT.
1) Distributed Denial of Service (DDoS): One of the most
lethal attacks in the FECIoT architecture is the DDoS.
The risk of malicious clients and coordinated groups of
clients (“botnets”) mounting DoS attacks is still an issue of
concern. DDoS attacks may emanate from IoT end-devices,
for example, several malicious IoT devices may consis-
tently launch a lot of fictitious service requests concur-
rently, hereby making FEC devices incapable of handling
simultaneous service request based on limited processing
capabilities. The FEC devices may become preoccupied
handling these malicious service request, and as a result
may be unable to handle legitimate service request. It
is important to note that malicious service request may
emanate from legitimate IoT end-devices which have been
compromised. Considering the large-scale deployment of
these IoT devices, it will be difficult for all end-device to
be authenticated. As such, reliance on a trusted third party
like a certification authority that issues credentials between
communicating parties may minimize DDoS attacks [156].
Attempts to filter service request or spoof incoming IP
packets may increase complexity, due to the size of the
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
network. On the other hand, FEC devices may also be
used to launch DDoS attack. As most of the computation
and processing is gradually migrated to the network edge,
a subverted FEC devices may cause severe havoc in the
IoT ecosystem. In 2016, some Internet-connected home de-
vices, such as printers and surveillance cameras, were used
to carry out DDoS attacks against popular websites, such as
PayPal34 , Twitter, Spotify35 , Reddit36 , SoundCloud37 , and
amongst others [9]. A similar kind of attack was launched
also in 2016, leading to several hours of blackout in
some parts Ukraine. The attackers gained control over the
grid’s Supervisory Control and Data Acquisition (SCADA)
system and it affected over a million residents [159].
Furthermore, most industrial control systems (ICS) are
sensitive to process interruptions, and as such intolerant
to downtime. FECIoT supports incident response without
interrupting or denying service to on-going processes.
2) Man-in-the-Middle Attack: The man-in-the-middle attack is
a prominent attack that could constitute a serious threat in
FECIoT, especially in the area of privacy. The attack easily
exploits this platform to disclose sensitive information
such as location and identity of the FEC devices [156].
This kind of attack is often successful, as devices cannot
implement secure communication protocols due to resource
constraints. Despite existing works on ways to overcome
this attack, this attack still poses a serious challenge in
FECIoT.
3) Physical Attack: This type of attack involves physical
compromise of hardware components. This hardware com-
ponents could be RFID tags, sensor devices, FEC devices,
or even more centralized infrastructure. Susceptibility of
this kind of attack varies with respect to the location of
deployment, level protection given to such devices [163].
VIII. FECI OT A PPLICATIONS
In this section, we present practical applications of FECIoT
along with state-of-the-art works presented by several re-
searchers. FECIoT plays a major role in response and latency-
sensitive IoT applications. There exist a vast number of cyber-
physical systems such as intelligent transportation systems,
smart grid, smart health-care, smart homes, smart environment,
and smart cities amongst others.
1) Intelligent Transportation Systems (ITS): Traffic conges-
tion and vehicle accidents are common plights faced by ma-
jor cities around the globe. As such, the need to incorporate
some degree of intelligence to our transportation system
cannot be overemphasized. Moreover, transportation data
will be huge and result in large delays if analysed at a
central server. Fog devices located at certain intersections
can analyse local data and inform travelers of updated
routes, thus reducing delay. ITS, also known as Smart
Transport, enhances daily lives of road users via monitoring
34 https://www.paypal.com/
35 https://www.spotify.com/
36 https://www.reddit.com/
37 https://soundcloud.com/
26
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
and managing traffic flow, minimizing traffic congestion,
providing alternative routes and reducing the environmental
impacts of transport. ITS comprises of four main com-
ponents, they include vehicle subsystem (consisting of
GPS, RFID reader, OBU, and communication), station
subsystem (road-side equipment), ITS monitoring center
and security subsystem [11]. A smart traffic light system
which is a subset of ITS helps decongest traffic flow within
a city [164]. In [165], an IoT-based Smart Transportation
system using Atmega328P Arduino microcontroller and
SIM28ML GPS module was used to enhance fare collec-
tion. ITS also interacts with other CPS to ensure safety. An-
other good application will be the large-scale deployment
of Closed-Circuit Televisions (CCTVs) in transportation
infrastructure, and relying on a centralized and distant
Cloud platform will be technically infeasible [166]. As
such, the FECIoT framework can be used to leverage com-
putation infrastructure that is closer to the network edge
to complement Cloud Computing in providing latency-
sensitive applications and services. In 2018, Australian
Communications and Media Authority issued regulations to
support the roll-out of intelligent transport systems (ITS).
Also in USA and Europe, significant progress has been
made in their ITS projects.
2) Smart Grid: Smart Grid helps in managing energy use in
houses and buildings. Smart Grid offers transparent energy
distribution where both the consumers and utilities are able
to monitor and control their pricing, production, and con-
sumption in almost real time [167]. Utilities in the context
of Smart Grid are the service providers. The Smart Grid
network helps the utility to effectively balance load and
ensure reliable energy transmission. Smart meters are used
within the network to collect, analyze, control, monitor,
and transmit information on electricity consumption, and
customer device usage. The data collected may then be
transmitted and stored up in the cloud, hence resulting
in additional delay and breach of privacy. Moreover, as
more customers get connected to the Smart Grid network,
the system complexity increases significantly. Fog/edge
devices can be used for collecting, computing and storing
smart meter data before passing them to the cloud if need
be. Thus, making the FECIoT framework appropriate in
Smart Grids for reducing latency, enhancing privacy and
localization of processing. FECIoT architecture enhances
Smart Grid by complementing SCADA with a decen-
tralized micro-grid model to improve scalability, security,
response and optimize the cost of the system [168], [169].
A fog-based Internet-of-Energy (IoE) architecture for trans-
active energy management systems was proposed in [170].
An inter-customer energy trading cost function was used
where the customers prefer to buy energy from each other
rather than buying from the power grid which is at a higher
cost especially at peak periods. Fog nodes were used as
retail energy market server which provides energy services
to the end-users. Furthermore, an expression for the total
delay of fog and cloud-based models [170] are given in (3)
and (4), respectively.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
C opt 2Siopt
 
τ f og
= f og + max
1 − P (Siopt ) RLAN


ν trolled remotely. A good example of a smart home is
C opt

2Siopt
 from a remote location. This will help warm up the room
cloud
τ = cloud + max
1 − P (Siopt ) RW AN


ν
For all i = 1, 2, ..., N , where C opt represents the size
of optimization problem which is equal for both fog and
cloud-based models. Siopt is the required data size for
transferring optimization information of customer i to the
server. ν f og and ν cloud represent the fog and cloud server
processing speed, respectively. RLAN and RLAN represent
the channel speed of LAN and WAN network connections.
Results showed that the fog-based model significantly
decreases the total bandwidth and delay.
3) Smart Health-care: Smart health-care plays an important
role in mitigating the impact of chronic diseases and
enhancing health-care delivery. This can be achieved by
embedding sensors and actuators in patients to help in
monitoring health status and providing feedback to the
health-care provider. A survey that evaluated the overall
suitability of wearable IoT in health-care systems was
presented in [171]. Sensors will make it much easier to
access correct information about the current status and
location of medical equipment and patients [158], [172].
A good example of Smart Health-care is when the blood
pressure of a monitored patients exceeds a predefined
threshold, feedback can be sent immediately to the health-
care providers for immediate action to be taken. Since
Smart Health-care is response-critical and delay-sensitive,
it is appropriate to deploy the FECIoT framework in this
CPS in order to enhance reliability. Smart watches and
Smartphones can be used as intermediary FEC devices to
relay information to health-care providers. In 2014, Google
announced its smart-lens project, which employed the use
of smart contact lenses to help in examining the interior
of the body via the fluids that bathe the eye. The sensors
were capable of measuring the glucose in these tears in
order to regulate sugar levels in diabetes patients. The
smart-lens can also be used to monitor Glaucoma and other
acute infections. The smart-lens is connected to a recording
device, which acts as an intermediary FEC device with
some processing capabilities. In [173], a remote patient
health monitoring in smart homes by using the concept
of fog computing at the smart gateway was proposed.
The proposed model employed advanced techniques and
services such as embedded data mining, distributed storage,
and notification services at the edge of the network. Results
revealed better enhancement in decision making based on
real-time health-care data (using health data of 67 patients
in IoT-based smart homes over a period of 30 days).
4) Smart Homes: Smart home entails automating the home
with some degree of machine intelligence [174]. Devices
within the home are made smarter by embedding additional
chips or sensors which help in monitoring, reporting,
and even taking actions based on higher layer decisions.
In today’s world, several home appliances such as air
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Things Journal
conditioners, dishwashers, electric meters, home security
(3) cameras, and heating systems can be monitored and con-
putting on the heating system during winter in the home
(4) before arriving home. Another application will be smart
lighting, which puts off the light when no one is in the
room. However, the light comes on when human pres-
ence is sensed. Smart homes may have interactions with
other CPS, such as Smart Grid which involves monitoring
and adjusting power consumption, Smart Building which
may involve maintenance of appliance and safety, Smart
Weather which helps in adjusting humidity level, and
temperature within the home. As such, Smart Homes will
be heavily dependent on the robust FECIoT architecture
which supports highly distributed FEC devices to make
local decisions. A framework was presented in [175] which
extend the smart home to microgrid level, in order to
integrate all renewable distributed energy sources from
the microgrid and to achieve better energy optimization.
Through simulations on a real dataset, they were able to
show that fog computing based on predictive filters can
reduce the number of transmissions and minimize smart
home network energy consumption.
5) Smart Environment: With growing global concerns for the
environment, drastic measures need to be taken to curtail
the alarming climate change and evident degradation of
our environment. Industrialization has also contributed its
part in polluting the environment, as such, the 11th goal of
the UN’s Sustainable Development Goals38 (SDGs) ensures
to “make cities and human settlements inclusive, safe,
resilient and sustainable,” and this is achievable using the
FECIoT architecture. Fog/edge devices can be ubiquitously
distributed to effectively monitor the environment with
minimal latency. Furthermore, the FECIoT can be read-
ily deployed with available sensors, controllers, actuators,
and FEC processors for monitoring, and control in any
industrial setup, thus providing a real-time response, as
well as location-based services [9]. A Spatial Monitoring
and Reporting Tool (called SMART) was introduced in
Belize to help collect, store, communicate, and analyze
data on illegal activities, wildlife, patrol routes, and take
management actions. Since the country is heavily depen-
dent on natural resources, in early 2018, the Ministry of
Agriculture, Fisheries, Forestry, Environment, Sustainable
Development, and Climate Change, are beginning to incor-
porate SMART in combatting environmental challenges.
6) Smart Cities: A Smart City is one that leverages intelligent
technology in monitoring, controlling, and managing the
conditions of all critical infrastructures within a city, such
as roads, hospitals, water, electricity supply, communica-
tion, airport, seaport, amongst others in order to provide
optimized services and comfort to the citizens [176]. It is
complex due to its inherent heterogeneity. This complexity
extends to the magnanimity of computation and processing
that will be carried out using the cloud platform. However,
38 www.un.org/sustainabledevelopment/cities/
27
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
the FECIoT framework provides a more reliable and robust
platform to run optimization models for the purpose of
making accurate and cost-efficient decisions within the city.
Moreover, the FECIoT architecture supports localized real-
time monitoring, control, and optimization for smart city
applications while the cloud-based platform may rely on
intermediary FEC devices to provide global monitoring,
control, optimization, and future planning for smart city
applications. Recently, Panasonic began building a model
Smart City near Denver in Colorado. The project empha-
sizes mobility and sustainability and is expected to pave
way for future smart city initiatives.
IX. O PEN R ESEARCH I SSUES
As observed with emergent technologies, numerous research
questions arise, requiring critical attention. FEC should not
be seen as a revolutionary concept, rather an evolutionary
one, evolving from years of progressive research. As such,
there exist inherent drawbacks and areas that will require
optimization. As can be seen in Fig. 2, fog nodes have the
ability to interact both vertically with the things or the cloud,
and horizontally with other fog devices. This new architecture
poses several research issues. We briefly categorize them.
A. Interfacing
The highly distributed nature of the FECIoT architecture
provides some degree of robustness and resilience within the
network, however, the reliability of both vertical and horizontal
interfaces remains an issue. Below are the interfaces that exist
within the FECIoT framework.
1) Fog-to-Cloud Interface: Interfacing between the fog and
cloud is essential for end-to-end service provisioning. The
interface enables interaction between the fog and cloud and
facilitates tasks assignment based on whether real-time or
delay tolerant processing is required. The decision on who
handles storage and computation is also based on the nature
of data or service.
2) Fog-to-Fog Interface: Fog computing features network
measurement, network management, service enablement,
and real-time control [3]. This interface allows fog devices
to jointly collaborate with each other, thereby delivering
improved services. For instance, fog node A may not have
data storage or computing capacity at a particular time,
another fog node B may be capable of offering storage or
computing service. With the help of this interface, the load
can be effectively distributed.
3) Fog-to-Things Interface: This interface is very important
in ensuring the Cloud-to-Things continuum via fog nodes.
Fog to Things interface enables things and end-users to
harness services rendered by the fog in a resource-efficient
manner.
As seen above, several research effort and proposals can be
developed to improve the reliability of these interfaces.
28
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
B. Service Coordination and Energy Management
With the proximity of the fog to the edge of the network, fog
nodes are best suited to deliver a wide range of services to end-
devices. This may involve fog nodes performing local storage
and application services. Based on the capabilities of the fog
nodes, it becomes necessary to determine how services are
coordinated, as well as fog functionalities are interfaced with
operating systems and hardware components of end-devices.
FECIoT opens up room for SMEs to own and manage FEC-
based infrastructure, hereby, increasing the number of devices
and services offered. As such, a dynamic service coordination
approach that is capable of integrating heterogeneous devices
into the context-aware FECIoT infrastructure is required. In
[177], a practical smart surgery process was carried out using
well organized service coordination algorithms. The process
can be easily extended to the FECIoT domain to achieve lower
latency. Furthermore, potential fog devices are often power-
constrained, as such, it is necessary to management energy
usage within the FECIoT ecosystem using optimal power-
control strategies. Communication within FECIoT ecosystem
is often machine-oriented, leading to drastic energy consump-
tion in IoT devices. Several algorithms have been proposed
to improve energy efficiency within the IoT framework. In
[178], a modified discontinuous reception (DRX) mechanism
incorporating the quick sleeping indication (QSI) as a novel,
simple, and energy-efficient solution for low-complexity, low-
mobility MTC user equipments (UEs). Further studies will
need to be carried out within the FECIoT framework for
efficient energy utilization.
C. Scalability and System Stability
Over the last decade, researchers have been exploring
alternative architectures to address scalability problems for
large, distributed application over the Internet. Graph theoretic
approach can be effectively used in modeling large scale net-
works, particularly FECIoT. Moreover, modern industrial en-
vironment stipulate lesser down-times, reconfiguration times,
and increase of its production rate. The flexible orchestration
of the FECIoT framework is capable of meeting the needs of
emerging industry model [179]. The scarcity of real-world data
on FEC systems results in algorithms that are not being de-
signed for real-world scenarios. As such, research efforts needs
to be made on optimal algorithms that depict the complexity
of FECIoT systems. Furthermore, the local interactions within
the FECIoT network could lead to oscillation and instability
of global states, which is common in most distributed systems.
This could further degenerate as the size of the network
increases. Mechanisms to tackle this challenge will greatly
improve the overall performance of FECIoT networks.
D. Simulation Capabilities and Mobility
Most available IoT simulators are highly specialized, in
the sense that they fail to support end-to-end IoT service
scenario modelling with detailed representation of entities and
their interactions across all layers of the IoT architecture. For
instance, Cooja can be used to design several networking
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
topology with good physical representations, however, it is
unable to model the higher layers collectively, as part of
the simulation [142]. This may require virtualization, which
will still require some synchronization for proper integration.
Furthermore, FEC device can either be static or mobile, with
the latter presenting more communication issues. As more
mobile fog nodes are deployed within the FECIoT, issues like
connectivity and handover will need to be addressed. Mobility
is not limited to fog nodes, but also to things, wearables
etc. Mobility brings about complexities in the network, as
such several potential research scenarios could be modeled.
As discussed earlier in subsequent section, we illustrated how
fog devices can be deployed as static/mobile relays to im-
prove QoS by minimizing communication outages within the
FECIoT ecosystem. Moreover, these relays serve as redundant
elements to minimize the probability of link failure and it can
also be effectively used to offload vital services across the
FECIoT network.
E. Virtualization
Several research issues still exist despite virtual FEC frame-
work out-performing Cloud platforms [180]. Some of this boils
down to the challenge of resource procurement and resource
utilization. We briefly present them below.
1) Resource Procurement: Fog/edge resources are often spa-
tially distributed due to different geographical location
of the devices. It becomes necessary for FEC service
providers to create a unified platform for various fog
players to share the common infrastructure. This will
help to locate, secure and orchestrate resources prior to
deployment of their applications. Since these resources are
heterogeneous and pervasive by default, the challenge will
be to come up with a computationally-efficient and stable
resource procurement mechanism.
2) Resource Utilization: Fog/edge device provides platform
for heterogeneous technologies providing multiple services
to IoT end-devices. However, linking resources across
multiple platforms remains an issue. As such, it becomes
imperative to deploy efficient scheduling, matching and
synchronization algorithms for proper utilization of re-
sources on resource-constrained IoT devices/networks.
F. Security and Enabling Technologies
Facilities in the edge of the network may not be equipped
with sophisticated security mechanisms, as such security at-
tacks can be relatively easier compared with centralized cloud
computing [7]. Within the FECIoT ecosystem, communication
is predominantly wireless, and as such prone to security
attacks. Managing security on a smaller scale with fewer fog
devices may seem like a very easy task, however, considering
the magnanimity in the number of fog nodes that will be
operational in the future, tackling security will be a big issue.
In fact, it becomes imperative to secure all interfaces within
the FECIoT architecture, as well as ensure the security of all
nodes within the network. Data integrity and authentication
must be ensured at all levels.
29
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Furthermore, for any emerging technology to succeed, it
is imperative to have basic building blocks in the form of
protocols and enabling technologies. In fact, the development
of the industrial IoT will be linked to the success of the
proposed FECIoT framework. Just recently, the blockchain
technology, which is a distributed ledger, voting and con-
sensus combined with execution protocols, with fault-tolerant
communication capability, is capable of delivering a secure
and trusted foundation for data regulation and information
transactions between autonomously operating devices in the
FECIoT domain. Blockchain technology can make rules that
allow decentralised and autonomous systems jointly make
decisions about the execution of transactions based on voting
and consensus algorithms, hereby, providing “secure, audit-
level tracking of IoT data transactions, eliminating the need
for a central, trusted intermediary between communicating
devices” [181]. Moreover, innovative ideas on securing the
distributed FECIoT architecture using the SDN and blockchain
techniques will provide immense number of research opportu-
nities. In general, the FECIoT framework is still in its infancy
stage and is open to further research.
X. C ONCLUSION
FECIoT has the potential to add value to existing IoT
systems by enabling real-time response as well as providing
storage and computational services in a distributed manner
to IoT end-devices. The proximity of FEC devices to where
the data is produced makes it stand-out in terms of resource
allocation, service delivery, and privacy. The FECIoT frame-
work offers more responsiveness and eliminates the need for
costly bandwidth additions by offloading gigabytes of network
traffic from the core network. Mobility in FECIoT improves
on fault tolerance, however, poses new research issues. From
the business perspective, FECIoT will lead to a boom and
spring up of SMEs, thereby encouraging inclusion for all.
The proposed FECIoT service-based framework will greatly
enhance service delivery to IoT end-users, hence, FECIoT
should be considered as part of the overall Internet of the
future, which will transform the Internet industry.
In this paper, we surveyed the key aspect of the FECIoT
framework and presented open research issues. We presented
FECIoT in a tutorial form, especially for new entrants in the
area of IoT. It should, however, be noted that the FECIoT
framework may seem to have provided improvements on
existing frameworks, numerous research issues abound. This
is expected to be a prime focus for researchers in the next
decade.
R EFERENCES
[1] F. Al-Doghman, Z. Chaczko, A. R. Ajayan and R. Klempous, “A
review on Fog Computing technology,” IEEE International Conference on
Systems, Man, and Cybernetics (SMC), Budapest, 2016, pp. 1525-1530.
[2] J. Lin, W. Yu, N. Zhang, X. Yang, H. Zhang, and W. Zhao, “A Survey
on Internet of Things: Architecture, Enabling Technologies, Security and
Privacy, and Applications,” IEEE Internet of Things, vol. 4, no. 5, pp.
1125-1142, Oct. 2017.
[3] M. Chiang, and T. Zhang, “Fog and IoT: An Overview of Research
Opportuinities,” IEEE Internet of Things, vol. 3, no. 6, pp. 854-864, Dec.
2016.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
[4] P. Sethi, and S. R. Sarangi, “Internet of Things: Architecture, Protocols,
and Applications,” Journal of Electrical and Computer Engineering, vol.
2017, no. 9324035, 25 pages, 2017.
[5] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,”
Computer Networks, vol. 54, no. 15, pp. 2787-2805, Oct. 2010.
[6] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and
its role in the internet of things,” In Proceedings of the first edition of
the MCC workshop on Mobile cloud computing (MCC ’12). ACM, New
York, NY, USA, pp. 13-16, 2012.
[7] J. Pan and J. McElhannon, “Future Edge Cloud and Edge Computing for
Internet of Things Applications,” IEEE Internet of Things Journal, vol.
5, no. 1, pp. 439-449, Feb. 2018.
[8] K. Dolui and S. K. Datta, “Comparison of edge computing implementa-
tions: Fog computing, cloudlet and mobile edge computing,” IEEE Global
Internet of Things Summit (GIoTS), Geneva, 2017, pp. 1-6.
[9] P. Hu, S. Dhelim, H. Ning, and T. Qiu, “Survey on Fog Computing:
Architecture, Key Technologies, Applications and Open Issues,” Journal
of Network and Computer Applications, pp. 27-42, Nov. 2017.
[10] W. Shi, J. Cao, Q. Zhang, Y. Li and L. Xu, “Edge Computing: Vision and
Challenges,” IEEE Internet of Things Journal, vol. 3, no. 5, pp. 637-646,
Oct. 2016.
[11] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari and M.
Ayyash, ”Internet of Things: A Survey on Enabling Technologies, Pro-
tocols, and Applications,” IEEE Communications Surveys and Tutorials,
vol. 17, no. 4, pp. 2347-2376, Fourthquarter 2015.
[12] K. Bilal , O. Khalid , A. Erbad, and S. U. Khan, ”Potentials, Trends, and
Prospects in Edge Technologies: Fog, Cloudlet, Mobile Edge, and Micro
Data Centers,” Computer Networks, vol. 130, pp. 94-120, Jan. 2018.
[13] D. Miorandi, S. Sicari, F. D. Pellegrini, and I. Chlamtac, “Internet of
things: Vision, applications and research challenges,” Ad Hoc Networks,
vol. 10, no. 7, pp. 1497–1516, Sep. 2012.
[14] Y. Mehmood, F. Ahmad, I. Yaqoob, A. Adnane, M. Imran and S.
Guizani, “Internet-of-Things-Based Smart Cities: Recent Advances and
Challenges,” IEEE Communications Magazine, vol. 55, no. 9, pp. 16-24,
Sept. 2017.
[15] M. Aazam, and E. N. Huh, “Fog computing: The cloud-IOT/IoE
middleware paradigm,” IEEE Potentials, vol. 35, no. 3, pp. 40–44, May
2016.
[16] C. Zhu, V. C. M. Leung, L. Shu and E. C. H. Nga, “Green Internet
of Things for Smart World,” IEEE Access, vol. 3, pp. 2151–2162, Nov.
2015.
[17] A. H. Ngu, M. Gutierrez, V. Metsis, S. Nepal and Q. Z. Sheng, “IoT
Middleware: A Survey on Issues and Enabling Technologies,” IEEE
Internet of Things Journal, vol. 4, no. 1, pp. 1–20, Feb. 2017.
[18] D. Raggett, “The Web of Things: Challenges and Opportunities,” IEEE
Computer, vol. 48, no. 5, pp. 26-32, May 2015.
[19] R. Want, B. N. Schilit and S. Jenson, “Enabling the Internet of Things,”
Computer, vol. 48, no. 1, pp. 28-35, Jan. 2015.
[20] M. A. Razzaque, M. Milojevic-Jevric, A. Palade and S. Clarke, “Middle-
ware for Internet of Things: A Survey,” IEEE Internet of Things Journal,
vol. 3, no. 1, pp. 70-95, Feb. 2016.
[21] Z. Sheng, S. Yang, Y. Yu, A. V. Vasilakos, J. A. Mccann and K. K.
Leung, “A survey on the ietf protocol suite for the internet of things: stan-
dards, challenges, and opportunities,” IEEE Wireless Communications,
vol. 20, no. 6, pp. 91-98, Dec. 2013.
[22] Y. Ai, M. Peng, K. Zhang, “Edge cloud computing technologies for
internet of things: A primer,” Digital Communications and Networks,
July 2017.
[23] S. Verma, Y. Kawamoto, Z. M. Fadlullah, H. Nishiyama and N. Kato, “A
Survey on Network Methodologies for Real-Time Analytics of Massive
IoT Data and Open Research Issues,” IEEE Communications Surveys and
Tutorials, vol. 19, no. 3, pp. 1457-1477, thirdquarter 2017.
[24] N. C. Luong, D. T. Hoang, P. Wang, D. Niyato, D. I. Kim and Z.
Han, “Data Collection and Wireless Communication in Internet of Things
(IoT) Using Economic Analysis and Pricing Models: A Survey,” IEEE
Communications Surveys and Tutorials, vol. 18, no. 4, pp. 2546-2590,
Fourthquarter 2016.
[25] J. Ni, K. Zhang, X. Lin and X. Shen, “Securing Fog Computing
for Internet of Things Applications: Challenges and Solutions,” IEEE
Communications Surveys and Tutorials, vol. PP, no. 99, pp. 1-1, Oct.
2017.
[26] J. Granjal, E. Monteiro and J. S. Silva, “Security for the Internet of
Things: A Survey of Existing Protocols and Open Research Issues,” IEEE
Communications Surveys and Tutorials, vol. 17, no. 3, pp. 1294-1312,
thirdquarter 2015.
30
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
[27] M. R. Palattella et al., “Standardized Protocol Stack for the Internet of
(Important) Things,” IEEE Communications Surveys and Tutorials, vol.
15, no. 3, pp. 1389-1406, Third Quarter 2013.
[28] B. Varghese, N. Wang, S. Barbhuiya, P. Kilpatrick and D. S. Nikolopou-
los, “Challenges and Opportunities in Edge Computing,” IEEE Interna-
tional Conference on Smart Cloud (SmartCloud), New York, NY, 2016,
pp. 20-26.
[29] M. Satyanarayanan, “Edge Computing,” Computer, vol. 50, no. 10, pp.
36-38, 2017.
[30] A. Alrawais, A. Alhothaily, C. Hu and X. Cheng, “Fog Computing
for the Internet of Things: Security and Privacy Issues,” IEEE Internet
Computing, vol. 21, no. 2, pp. 34-42, Mar.-Apr. 2017.
[31] Z. Wen, R. Yang, P. Garraghan, T. Lin, J. Xu and M. Rovatsos, “Fog
Orchestration for Internet of Things Services,” IEEE Internet Computing,
vol. 21, no. 2, pp. 16-24, Mar.-Apr. 2017.
[32] L. Atzori, A. Iera, G. Morabito, and M. Nitti, “The Social Internet
of Things (SIoT)- When social networks meet the Internet of Things:
Concept, architecture and network characterization,” Computer Networks,
vol. 56, no. 16, pp. 3594-3608, Nov. 2012.
[33] L. Lan, F. Li, B. Wang, L. Zhang and R. Shi, “An Event-Driven Service-
Oriented Architecture for the Internet of Things,” 2014 IEEE Asia-Pacific
Services Computing Conference, Fuzhou, 2014, pp. 68-73.
[34] P. P. Ray, “A survey on Internet of Things architectures,” Journal of
King Saud University - Computer and Information Sciences, Oct. 2016.
[35] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of Things
(IoT): A vision, architectural elements, and future directions,” Future
Generation Computer Systems, vol. 29, Issue 7, pp. 1645-1660, Sept.
2013.
[36] H. F. Atlam, R. J. Walters, and G. B. Wills, “Fog Computing and the
Internet of Things: A Review” Big Data Cogn. Comput., vol. 2, no. 10,
pp. 1-18, April 2018.
[37] J. Dutta, and S. Roy, “IoT-fog-cloud based architecture for smart city:
Prototype of a smart building,” 2017 7th International Conference on
Cloud Computing, Data Science and Engineering - Confluence, Noida,
2017, pp. 237-242.
[38] C. Puliafito, E. Mingozzi and G. Anastasi, “Fog Computing for the Inter-
net of Mobile Things: Issues and Challenges,” 2017 IEEE International
Conference on Smart Computing (SMARTCOMP), Hong Kong, 2017, pp.
1-6.
[39] N. Mohan and J. Kangasharju, “Edge-Fog cloud: A distributed cloud
for Internet of Things computations,” 2016 Cloudification of the Internet
of Things (CIoT), Paris, 2016, pp. 1-6.
[40] M. Yannuzzi, R. Milito, R. Serral-GraciÃă, D. Montero and M. Ne-
mirovsky, “Key ingredients in an IoT recipe: Fog Computing, Cloud
computing, and more Fog Computing,” 2014 IEEE 19th International
Workshop on Computer Aided Modeling and Design of Communication
Links and Networks (CAMAD), Athens, 2014, pp. 325-329.
[41] C. Mouradian, D. Naboulsi, S. Yangui, R. H. Glitho, M. J. Morrow and
P. A. Polakos, “A Comprehensive Survey on Fog Computing: State-of-
the-Art and Research Challenges,” IEEE Communications Surveys and
Tutorials, vol. 20, no. 1, pp. 416-464, Firstquarter 2018.
[42] P. Porambage, J. Okwuibe, M. Liyanage, M. Ylianttila and T. Taleb,
“Survey on Multi-Access Edge Computing for Internet of Things Re-
alization,” IEEE Communications Surveys and Tutorials, Early Access,
Secondquarter 2018.
[43] A. Chen, H. Wu, L. Tian, and G. Luo, “HCOS: A Unified Model
and Architecture for Cloud Operating System,” ZTE Communications
Magazine, vol. 15, no. 4, pp. 23-29, Nov. 2017.
[44] S. Chen, T. Zhang and W. Shi, “Fog Computing,” IEEE Internet
Computing, vol. 21, no. 2, pp. 4-6, Mar.-Apr. 2017.
[45] F. Bonomi, R. Milito, P. Natarajan, J. Zhu (2014), “Fog Computing:
A Platform for Internet of Things and Analytics.” In: Bessis N., Dobre
C. (eds) Big Data and Internet of Things: A Roadmap for Smart
Environments.” Studies in Computational Intelligence, vol 546. Springer,
Cham.
[46] P. P. Ray, “An Introduction to Dew Computing: Definition, Concept and
Implications,” emphIEEE Access, vol. 6, pp. 723-737, 2018.
[47] Y. Liu, Y. Peng, B. Wang, S. Yao and Z. Liu, “Review on cyber-physical
systems,” IEEE/CAA Journal of Automatica Sinica, vol. 4, no. 1, pp. 27-
40, Jan. 2017.
[48] E. A. Lee, ”Cyber Physical Systems: Design Challenges,” 11th IEEE
International Symposium on Object and Component-Oriented Real-Time
Distributed Computing (ISORC), Orlando, FL, 2008, pp. 363-369.
[49] V. Gunes, S. Peter, T. Givargis, and F. Vahid, “A Survey on Concepts,
Applications, and Challenges in Cyber-Physical Systems,” KSII Transac-
tions on Internet and Information Systems, vol. 8, no. 12, pp. 4242-4268,
Dec. 2014.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
[50] N. Reijers, K. J. Lin, Y. C. Wang, C. S. Shih, and J. Y. Hsu, “Design
of an intelligent middleware for flexible sensor configuration in M2M
systems”, Proc. Second Int. Conf. on Sensor Networks (SENSORNETS),
February 2013, pp. 1-6.
[51] C. S. Shih, J. J. Chou, N. Reijers and T. W. Kuo, “Designing CPS/IoT
applications for smart buildings and cities,” IET Cyber-Physical Systems:
Theory and Applications, vol. 1, no. 1, pp. 3-12, Dec. 2016.
[52] K. J. Lin, N. Reijers, Y. C. Wang, C. S. Shih and J. Y. Hsu, “Building
Smart M2M Applications Using the WuKong Profile Framework,” 2013
IEEE International Conference on Green Computing and Communica-
tions and IEEE Internet of Things and IEEE Cyber, Physical and Social
Computing, Beijing, 2013, pp. 1175-1180.
[53] A. J. Jara, D. Genoud and Y. Bocchi, “Big Data for Cyber Physical
Systems: An Analysis of Challenges, Solutions and Opportunities,” 2014
Eighth International Conference on Innovative Mobile and Internet
Services in Ubiquitous Computing, Birmingham, 2014, pp. 376-380.
[54] D. Garlan, “Modeling Challenges for CPS Systems,” 2015 IEEE/ACM
1st International Workshop on Software Engineering for Smart Cyber-
Physical Systems, Florence, 2015, pp. 1-1.
[55] L. Zhang, “A framework to model big data driven complex cyber physi-
cal control systems,” 2014 20th International Conference on Automation
and Computing, Cranfield, 2014, pp. 283-288.
[56] W. Mueller, M. Becker, A. Elfeky and A. DiPasquale, “Virtual proto-
typing of Cyber-Physical Systems,” 17th Asia and South Pacific Design
Automation Conference, Sydney, NSW, 2012, pp. 219-226.
[57] E. K. Wang, Y. Ye, X. Xu, S. M. Yiu, L. C. K. Hui and K. P.
Chow, “Security Issues and Challenges for Cyber Physical System,”
Green Computing and Communications (GreenCom), 2010 IEEE/ACM
Int’l Conference on and Int’l Conference on Cyber, Physical and Social
Computing (CPSCom), Hangzhou, 2010, pp. 733-738.
[58] Open Fog Consortium, OpenFog reference architecture for fog comput-
ing. [Online]. Available: https://www.openfogconsortium.org/wp-content/
uploads/OpenFog_Reference_Architecture_2_09_17-FINAL-1.pdf
[59] R. Mahmoud, T. Yousuf, F. Aloul and I. Zualkernan, “Internet of things
(IoT) security: Current status, challenges and prospective measures,”
10th IEEE International Conference for Internet Technology and Secured
Transactions (ICITST), London, 2015, pp. 336-341.
[60] M. Leo, F. Battisti, M. Carli and A. Neri, “A federated architecture ap-
proach for Internet of Things security,” 2014 Euro Med Telco Conference
(EMTC), Naples, 2014, pp. 1-5.
[61] P. Swiatek, P. Stelmach, A. Prusiewicz, and K. Juszczyszyn, “Service
Composition in Knowledge-based SOA Systems,” New Generation Com-
puting, 30(2), 165-188, 2012.
[62] D. M. Silva, C.C., Ferreira, H.G.C., R. T. D. S. Junior, F. Buianti, and
L. J. G. Villalba, Wireless Pers Commun, (2016) 91: 1711.
[63] A. J. Jara, P. Lopez, D. Fernandez, J. F. Castillo, M. A. Zamora and
A. F. Skarmeta, “Mobile Digcovery: A Global Service Discovery for the
Internet of Things,” 27th IEEE International Conference on Advanced
Information Networking and Applications Workshops, Barcelona, 2013,
pp. 1325-1330.
[64] P. Stelmach (2013), “Service Composition Scenarios in the Internet
of Things Paradigm.” In: Camarinha-Matos L.M., Tomic S., Graca P.
(eds) Technological Innovation for the Internet of Things. DoCEIS 2013.
IFIP Advances in Information and Communication Technology, vol 394.
Springer, Berlin, Heidelberg
[65] J. Rykowski and D. Wilusz, “Comparison of architectures for service
management in IoT and sensor networks by means of OSGi and REST
services,” 2014 Federated Conference on Computer Science and Infor-
mation Systems, Warsaw, 2014, pp. 1207-1214.
[66] M. Kalverkamp and C. Gorldt, “IoT service development via adaptive
interfaces: Improving utilization of cyber-physical systems by competence
based user interfaces,” 2014 IEEE International Conference on Engineer-
ing, Technology and Innovation (ICE), Bergamo, 2014, pp. 1-8.
[67] N. Lin and W. Shi, “The research on Internet of things application
architecture based on web,” 2014 IEEE Workshop on Advanced Research
and Technology in Industry Applications (WARTIA), Ottawa, ON, 2014,
pp. 184-187.
[68] H. Freeman and T. Zhang, “The emerging era of fog computing and
networking [The President’s Page],” IEEE Communications Magazine,
vol. 54, no. 6, pp. 4-5, June 2016.
[69] Y. Yang, “FA2 ST: Fog as a Service Technology,” 2017 IEEE 41st Annual
Computer Software and Applications Conference (COMPSAC), Turin,
2017, pp. 708-708.
[70] D. H. Tran, N. H. Tran, C. Pham, S. M. A. Kazmi, E. N. Huh, and C. S.
Hong, “OaaS: offload as a service in fog networks,” Computing, (2017)
99: 1081.
31
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
[71] Y. Shi, G. Ding, H. Wang, H. E. Roman and S. Lu, “The fog computing
service for healthcare,” 2015 2nd IEEE International Symposium on
Future Information and Communication Technologies for Ubiquitous
HealthCare (Ubi-HealthTech), Beijing, 2015, pp. 1-5.
[72] P. A. Laplante, J. Voas and N. Laplante, “Standards for the Internet of
Things: A Case Study in Disaster Response,” Computer, vol. 49, no. 5,
pp. 87-90, May 2016.
[73] T. S. Lim, S. C. Sim and M. M. Mansor, “RFID based attendance sys-
tem,” 2009 IEEE Symposium on Industrial Electronics and Applications,
Kuala Lumpur, 2009, pp. 778-782.
[74] R. Want, “An introduction to RFID technology,” IEEE Pervasive Com-
puting, vol. 5, no. 1, pp. 25-33, Jan.-March 2006.
[75] J. R. Smith, A. P. Sample, P. S. Powledge, S. Roy, and A. Mamishev.
2006. “A wirelessly-powered platform for sensing and computation,”
Proceedings of the 8th international conference on Ubiquitous Computing
(UbiComp’06), Paul Dourish and Adrian Friday (Eds.). Springer-Verlag,
Berlin, Heidelberg, pp. 495-506.
[76] S. Naderiparizi, A. N. Parks, Z. Kapetanovic, B. Ransford and J. R.
Smith, “WISPCam: A battery-free RFID camera,” 2015 IEEE Interna-
tional Conference on RFID (RFID), San Diego, CA, 2015, pp. 166-173.
[77] J. R. Smith, (2013) “History of the WISP Program,” In: Smith J. (eds)
Wirelessly Powered Sensor Networks and Computational RFID. Springer,
New York, NY
[78] L. F. Schrickte, C. Montez, R. d. Oliveira, and A. R. Pinto, “Integration
of wireless sensor networks to the internet of things using a 6lowpan
gateway,” In 2013 III Brazilian Symposium on Computing Systems Engi-
neering, pp. 119-124, Dec 2013.
[79] M. Kocakulak and I. Butun, “An overview of Wireless Sensor Networks
towards internet of things,” 2017 IEEE 7th Annual Computing and
Communication Workshop and Conference (CCWC), Las Vegas, NV,
2017, pp. 1-6.
[80] S. Gaur, “Bringing context awareness to IoT-based wireless sensor
networks,” 2015 IEEE International Conference on Pervasive Computing
and Communication Workshops (PerCom Workshops), St. Louis, MO,
2015, pp. 228-229.
[81] N. Khalil, M. R. Abid, D. Benhaddou and M. Gerndt, “Wireless
sensors networks for Internet of Things,” 2014 IEEE Ninth International
Conference on Intelligent Sensors, Sensor Networks and Information
Processing (ISSNIP), Singapore, 2014, pp. 1-6.
[82] P. Bellavista, G. Cardone, A. Corradi and L. Foschini, “Convergence of
MANET and WSN in IoT Urban Scenarios,” IEEE Sensors Journal, vol.
13, no. 10, pp. 3558-3567, Oct. 2013.
[83] K. Laubhan, K. Talaat, S. Riehl, T. Morelli, A. Abdelgawad and K.
Yelamarthi, “A four-layer wireless sensor network framework for IoT
applications,” 2016 IEEE 59th International Midwest Symposium on
Circuits and Systems (MWSCAS), Abu Dhabi, 2016, pp. 1-4.
[84] W. T. Sung, J. H. Chen and M. H. Tsai, “Applications of wireless sensor
network for monitoring system based on IOT,” 2016 IEEE International
Conference on Systems, Man, and Cybernetics (SMC), Budapest, 2016,
pp. 613-617.
[85] T. Farnham, “Proactive wireless sensor network for industrial IoT,” 2017
IEEE International Conference on Communications (ICC), Paris, 2017,
pp. 1-6.
[86] P. Wiecha, M. Cieplucha, P. Kloczko and W. A. Pleskacz, “Architecture
and design of a Bluetooth Low Energy Controller,” 2016 MIXDES -
23rd International Conference Mixed Design of Integrated Circuits and
Systems, Lodz, 2016, pp. 164-167.
[87] B. Yu, L. Xu and Y. Li, “Bluetooth Low Energy (BLE) based mobile
electrocardiogram monitoring system,” 2012 IEEE International Confer-
ence on Information and Automation, Shenyang, 2012, pp. 763-767.
[88] E. Mackensen, M. Lai and T. M. Wendt, “Bluetooth Low Energy (BLE)
based wireless sensors,” 2012 IEEE Sensors, Taipei, 2012, pp. 1-4.
[89] R. Frank, W. Bronzi, G. Castignani and T. Engel, “Bluetooth Low
Energy: An alternative technology for VANET applications,” 2014 11th
Annual Conference on Wireless On-demand Network Systems and Ser-
vices (WONS), Obergurgl, 2014, pp. 104-107.
[90] M. Grover, S. K. Pardeshi, N. Singh and S. Kumar, “Bluetooth low
energy for industrial automation,” 2015 2nd International Conference on
Electronics and Communication Systems (ICECS), Coimbatore, 2015, pp.
512-515.
[91] R. Want, “Near field communication,” IEEE Pervasive Computing, vol.
10, no. 3, pp. 4-7, July-September 2011.
[92] R. Schamberger, G. Madlmayr and T. Grechenig, “Components for an
interoperable NFC mobile payment ecosystem,” 2013 5th International
Workshop on Near Field Communication (NFC), Zurich, Switzerland,
2013, pp. 1-5.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
[93] E. Husni, Kuspriyanto, N. Basjaruddin, T. Purboyo, S. Purwantoro and
H. Ubaya, “Efficient tag-to-tag near field communication (NFC) protocol
for secure mobile payment,” 2011 2nd International Conference on In-
strumentation, Communications, Information Technology, and Biomedical
Engineering, Bandung, 2011, pp. 97-101.
[94] M. Alabdulhafith, R. V. Sampangi and S. Sampalli, “NFC-enabled
smartphone application for drug interaction and drug allergy detection,”
2013 5th International Workshop on Near Field Communication (NFC),
Zurich, Switzerland, 2013, pp. 1-6.
[95] U. B. Ceipidor et al., “Mobile ticketing with NFC management for
transport companies. Problems and solutions,” 2013 5th International
Workshop on Near Field Communication (NFC), Zurich, Switzerland,
2013, pp. 1-6.
[96] U. B. Ceipidor, “NFC technology applied to touristic-cultural field: A
case study on an Italian museum,” 2013 5th International Workshop on
Near Field Communication (NFC), Zurich, Switzerland, 2013, pp. 1-6.
[97] A. Fressancourt, C. Herault and E. Ptak, “NFCSocial: Social Networking
in Mobility through IMS and NFC,” 2009 First International Workshop
on Near Field Communication, Hagenberg, 2009, pp. 24-29.
[98] R. A. John and K. Raahemifar, “Designing a 2D color barcode,” 2015
IEEE 28th Canadian Conference on Electrical and Computer Engineering
(CCECE), Halifax, NS, 2015, pp. 297-301.
[99] Z. Li and W. Chen, “D & S Barcode: A Dynamic and Sensitive Barcode
for Intelligent Environment Monitoring,” 2014 International Conference
on Intelligent Environments, Shanghai, 2014, pp. 47-51.
[100] IEEE Standard for Low-Rate Wireless Networks, IEEE Std 802.15.4-
2015 (Revision of IEEE Std 802.15.4-2011), vol., no., pp.1-709, April
2016.
[101] E. Karapistoli, F. N. Pavlidou, I. Gragopoulos, and I. Tsetsinas,
“An overview of the IEEE 802.15.4a Standard,” IEEE Communications
Magazine, vol. 48, no. 1, pp. 47-53, 2010.
[102] T. Salman, R. Jain, “Networking Protocols and Standards for Internet
of Things,” Internet of Things and Data Analytics Handbook, John Wiley
and Sons, Inc. 2015.
[103] W. Sun, M. Choi, S. Choi, “IEEE 802.11ah: A Long Range 802.11
WLAN at Sub 1 GHz,” Journal of ICT Standardization, pp. 33-38, Mar.
2013.
[104] R. Akeela and Y. Elziq, “Design and verification of IEEE 802.11ah for
IoT and M2M applications,” 2017 IEEE International Conference on Per-
vasive Computing and Communications Workshops (PerCom Workshops),
Kona, HI, 2017, pp. 491-496.
[105] M. B. Yassein, W. Mardini and A. Khalil, “Smart homes automation
using Z-wave protocol,” 2016 International Conference on Engineering
and MIS (ICEMIS), Agadir, 2016, pp. 1-6.
[106] S. Al-Sarawi, M. Anbar, K. Alieyan and M. Alzubaidi, “Internet of
Things (IoT) communication protocols: Review,” 2017 8th International
Conference on Information Technology (ICIT), Amman, 2017, pp. 685-
690.
[107] X. Liu and N. Ansari, “Green Relay Assisted D2D Communications
With Dual Batteries in Heterogeneous Cellular Networks for IoT,”IEEE
Internet of Things Journal, vol. 4, no. 5, pp. 1707-1715, Oct. 2017.
[108] Z. Yan, S. Chen, X. Zhang, and H. L. Liu, “Outage Performance Anal-
ysis of Wireless Energy Harvesting Relay-Assisted Random Underlay
Cognitive Networks,” IEEE Internet of Things Journal, Feb. 2018.
[109] M. Shokrnezhad and S. Khorsandi, “On the Performance Improvement
of IoT Networks Using Relay-Based Communications,” in 2016 Interna-
tional Conference on Information Technology (ICIT), Bhubaneswar, pp.
17-22, Dec. 2016.
[110] Z. Behdad, M. Mahdavi, and N. Razmi, “A new Relay Policy in RF
Energy Harvesting for IoT Networks-A Cooperative Network Approach,”
IEEE Internet of Things Journal, April 2018.
[111] S. Zhang, H. Zhang, Q. He, K. Bian and L. Song, “Joint Trajectory and
Power Optimization for UAV Relay Networks,” IEEE Communications
Letters, vol. 22, no. 1, pp. 161-164, Jan. 2018.
[112] A. Antoniou and W.-S. Lu, Practical Optimization: Algorithms and
Engineering Applications. New York: Springer, 2007.
[113] D. Bankov, E. Khorov and A. Lyakhov, “On the Limits of LoRaWAN
Channel Access,” 2016 International Conference on Engineering and
Telecommunication (EnT), Moscow, 2016, pp. 10-14.
[114] LoRa Alliance, LoRaWAN Specification, 2015.
[115] D. Bankov, E. Khorov and A. Lyakhov, “Mathematical model of
LoRaWAN channel access,” 2017 IEEE 18th International Symposium
on A World of Wireless, Mobile and Multimedia Networks (WoWMoM),
Macau, 2017, pp. 1-3.
[116] A. Durand, “Deploying IPv6,” IEEE Internet Computing, vol. 5, no. 1,
pp. 79-81, Jan/Feb 2001.
32
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
[117] T. Savolainen, J. Soininen and B. Silverajan, “IPv6 Addressing Strate-
gies for IoT,” IEEE Sensors Journal, vol. 13, no. 10, pp. 3511-3519, Oct.
2013.
[118] J. W. Hui and D. E. Culler, “IPv6 in Low-Power Wireless Networks,”
Proceedings of the IEEE, vol. 98, no. 11, pp. 1865-1878, Nov. 2010.
[119] J. Olsson, “6LoWPAN demystified,” Texas Instruments, 2014.
[120] F. T. Mamo and A. Sikora, “Implementation of standardized 6LoWPAN
based application layer protocols,” 2015 IEEE 8th International Confer-
ence on Intelligent Data Acquisition and Advanced Computing Systems:
Technology and Applications (IDAACS), Warsaw, 2015, pp. 817-822.
[121] C. Gomez, J. Paradells, C. Bormann and J. Crowcroft, “From 6LoW-
PAN to 6Lo: Expanding the Universe of IPv6-Supported Technologies
for the Internet of Things,” IEEE Communications Magazine, vol. 55,
no. 12, pp. 148-155, Dec. 2017.
[122] Internet Protocol for Smart Objects (IPSO) Alliance, RPL: The IP
routing protocol designed for low power and lossy networks, 2011.
[123] N. Accettura, L. A. Grieco, G. Boggia and P. Camarda, “Performance
analysis of the RPL Routing Protocol,” 2011 IEEE International Confer-
ence on Mechatronics, Istanbul, 2011, pp. 767-772.
[124] A. Aijaz, H. Su and A. H. Aghvami, “CORPL: A Routing Protocol for
Cognitive Radio Enabled AMI Networks,” IEEE Transactions on Smart
Grid, vol. 6, no. 1, pp. 477-485, Jan. 2015.
[125] M. Lauridsen, H. Nguyen, B. Vejlgaard, I. Z. Kovacs, P. Mogensen
and M. Sorensen, “Coverage Comparison of GPRS, NB-IoT, LoRa, and
SigFox in a 7800 km2 Area,” 2017 IEEE 85th Vehicular Technology
Conference (VTC Spring), Sydney, NSW, 2017, pp. 1-5.
[126] M. Elsaadany, A. Ali and W. Hamouda, “Cellular LTE-A Technologies
for the Future Internet-of-Things: Physical Layer Features and Chal-
lenges,” IEEE Communications Surveys & Tutorials, vol. 19, no. 4, pp.
2544-2572, Fourthquarter 2017.
[127] S. Basagni, C. Petrioli, R. Petroccia and D. Spaccini, “Channel-aware
routing for underwater wireless networks,” 2012 Oceans - Yeosu, Yeosu,
2012, pp. 1-9.
[128] Z. Zhou, B. Yao, R. Xing, L. Shu and S. Bu, “E-CARP: An Energy
Efficient Routing Protocol for UWSNs in the Internet of Underwater
Things,” IEEE Sensors Journal, vol. 16, no. 11, pp. 4072-4082, June,
2016.
[129] P. K. Wali and D. Das, “A novel access scheme for IoT communications
in LTE-Advanced network,” 2014 IEEE International Conference on
Advanced Networks and Telecommuncations Systems (ANTS), New Delhi,
2014, pp. 1-6.
[130] IEEE Standard for a Convergent Digital Home Network for Hetero-
geneous Technologies Amendment 1: Support of New MAC/PHYs and
Enhancements, IEEE Std 1905.1a-2014 (Amendment to IEEE Std 1905.1-
2013), vol., no., pp.1-52, Feb. 20 2015
[131] D. Wobschall, “IEEE 1451-a universal transducer protocol standard,”
2007 IEEE Autotestcon, Baltimore, MD, 2007, pp. 359-363.
[132] C. Dai and Z. Wang, “A Flexible Extension of WSDL to Describe Non-
Functional Attributes,” 2010 2nd International Conference on E-business
and Information System Security, Wuhan, 2010, pp. 1-4.
[133] G. Moritz, F. Golatowski and D. Timmermann, “A Lightweight SOAP
over CoAP Transport Binding for Resource Constraint Networks,” 2011
IEEE Eighth International Conference on Mobile Ad-Hoc and Sensor
Systems, Valencia, 2011, pp. 861-866.
[134] G. L. D. Santos, V. T. Guimaraes, G. D. C. Rodrigues, L. Z. Granville
and L. M. R. Tarouco, “A DTLS-based security architecture for the Inter-
net of Things,” 2015 IEEE Symposium on Computers and Communication
(ISCC), Larnaca, 2015, pp. 809-815.
[135] R. Behrens and A. Ahmed, “Internet of Things: An end-to-end security
layer,” 2017 20th Conference on Innovations in Clouds, Internet and
Networks (ICIN), Paris, 2017, pp. 146-149.
[136] G. Peralta, M. Iglesias-Urkia, M. Barcelo, R. Gomez, A. Moran and J.
Bilbao, “Fog computing based efficient IoT scheme for the Industry 4.0,”
2017 IEEE International Workshop of Electronics, Control, Measurement,
Signals and their Application to Mechatronics (ECMSM), Donostia-San
Sebastian, 2017, pp. 1-6.
[137] M. B. Yassein, M. Q. Shatnawi and D. Al-zoubi, “Application layer
protocols for the Internet of Things: A survey,” 2016 International
Conference on Engineering & MIS (ICEMIS), Agadir, 2016, pp. 1-4.
[138] M. Kirsche and R. Klauck, “Unify to bridge gaps: Bringing XMPP into
the Internet of Things,” 2012 IEEE International Conference on Pervasive
Computing and Communications Workshops, Lugano, 2012, pp. 455-458.
[139] C. Bormann, A. P. Castellani and Z. Shelby, “CoAP: An Application
Protocol for Billions of Tiny Internet Nodes,” IEEE Internet Computing,
vol. 16, no. 2, pp. 62-67, March-April 2012.
[140] J. B. Postel, “User datagram protocol; RFC-768,” Internet Requests for
Comments (768), Aug. 1980.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2875544, IEEE Internet of
Things Journal
[141] S. Vinoski, “Advanced Message Queuing Protocol,” IEEE Internet
Computing, vol. 10, no. 6, pp. 87-89, Nov.-Dec. 2006.
[142] M. Chernyshev, Z. Baig, O. Bello and S. Zeadally, “Internet of Things
(IoT): Research, Simulators, and Testbeds,” IEEE Internet of Things
Journal, vol. PP, no. 99, pp. 1-1.
[143] G. D’Angelo, S. Ferretti and V. Ghini, “Simulation of the Internet of
Things,” 2016 International Conference on High Performance Computing
& Simulation (HPCS), Innsbruck, 2016, pp. 1-8.
[144] T. Grass C. Allande, A. Armejach, A. Rico, E. Ayguade, J. Labarta,
M. Valero, M. Casas, and M. Moreto, “MUSA: A Multi-level Simulation
Approach for Next-Generation HPC Machines,” SC16: International
Conference for High Performance Computing, Networking, Storage and
Analysis, Salt Lake City, UT, 2016, pp. 526-537.
[145] Y. Zhao, H. Yu and G. Liang, “NS3-based simulation system in het-
erogeneous wireless network,” 11th International Conference on Wireless
Communications, Networking and Mobile Computing (WiCOM 2015),
Shanghai, 2015, pp. 1-6.
[146] F. Osterlind, A. Dunkels, J. Eriksson, N. Finne and T. Voigt, “Cross-
Level Sensor Network Simulation with COOJA,” 31st IEEE Conference
on Local Computer Networks, Tampa, FL, 2006, pp. 641-648.
[147] I. Muscalagiu, C. Illes and H. E. Popa, “Large scale multi-agent-based
simulation using NetLogo for the multi-robot exploration problem,” 2013
11th IEEE International Conference on Industrial Informatics (INDIN),
Bochum, 2013, pp. 325-330.
[148] X. Zeng, S. K. Garg, P. Strazdins, P. Jayaraman, D. Georgakopoulos
and R. Ranjan, “IOTSim: a Simulator for Analysing IoT Applications,”
Journal of System Architecture, Elsevier, vol. 72, issue C, pp. 93-107,
Jan. 2017.
[149] H. Gupta, A. V. Dastjerdi, S. K. Ghosh, and R. Buyya, “ifogsim: A
toolkit for modeling and simulation of resource management techniques
in internet of things, edge and fog computing environments,” tech.
report CLOUDS-TR-2016-2, Cloud Computing and Distributed Systems
Laboratory, Univ. of Melbourne, 2016.
[150] K. Mehdi, M. Lounis, A. Bounceur, and T. Kechadi, “CupCarbon:
a multi-agent and discrete event wireless sensor network design and
simulation tool,” In Proceedings of the 7th International ICST Conference
on Simulation Tools and Techniques (SIMUTools ’14). ICST (Institute
for Computer Sciences, Social-Informatics and Telecommunications En-
gineering), ICST, Brussels, Belgium, Belgium, pp. 126-131, 2014.
[151] X. Xian, W. Shi, and H. Huang, “Comparison of OMNeT++ and
other simulator for WSN simulation,” IEEE Conference on Industrial
Electronics and Applications (ICIEA’08), pp. 1439-1443, Jun. 3-5, 2008.
[152] H. Ghayvat, L. Jie, A. Babu, M. E. Alahi, U. A. B. U. A. Bakar, S. C.
Mukhopadhyay and X. Gui, “Simulation and evaluation of ZigBee based
smart home using Qualnet simulator,” 2015 9th International Conference
on Sensing Technology (ICST), Auckland, 2015, pp. 536-542.
[153] P. C. Ccori, L. C. C. De Biase, M. K. Zuffo and F. S. C. da
Silva, “Device discovery strategies for the IoT,” 2016 IEEE International
Symposium on Consumer Electronics (ISCE), Sao Paulo, 2016, pp. 97-98.
[154] R. Bonetto, N. Bui, V. Lakkundi, A. Olivereau, A. Serbanati and M.
Rossi, “Secure communication for smart IoT objects: Protocol stacks, use
cases and practical examples,” 2012 IEEE International Symposium on
a World of Wireless, Mobile and Multimedia Networks (WoWMoM), San
Francisco, CA, 2012, pp. 1-7.
[155] A. Burg, A. Chattopadhyay and K. Y. Lam, “Wireless Communication
and Security Issues for Cyber-Physical Systems and the Internet-of-
Things,” Proceedings of the IEEE, vol. 106, no. 1, pp. 38-60, Jan. 2018.
[156] M. Mukherjee, R. Matam, L. Shu, L. Maglaras, M. A. Ferrag, N.
Choudhury, and V. Kumar, “Security and Privacy in Fog Computing:
Challenges,” IEEE Access, vol. 5, pp. 19293-19304, 2017.
[157] V. Suryani, Selo and Widyawan, “A Survey on Trust in Internet of
Things,” 2016 8th International Conference on Information Technology
and Electrical Engineering (ICITEE), Yogyakarta, 2016, pp. 1-6.
[158] F. A. Kraemer, A. E. Braten, N. Tamkittikhun and D. Palma, “Fog
Computing in Health-care–A Review and Discussion,” IEEE Access, vol.
5, pp. 9206-9222, 2017.
[159] H. Kim and E. A. Lee, “Authentication and Authorization for the
Internet of Things,” IT Professional, vol. 19, no. 5, pp. 27-33, 2017.
[160] X. Li, H. Wang, Y. Yu and C. Qian, “An IoT Data Communication
Framework for Authenticity and Integrity,” 2017 IEEE/ACM Second In-
ternational Conference on Internet-of-Things Design and Implementation
(IoTDI), Pittsburgh, PA, 2017, pp. 159-170.
[161] G. Margelis, R. Piechocki, T. Tryfonas and P. Thomas, “Smart Attacks
on the Integrity of the Internet of Things: Avoiding Detection by Em-
ploying Game Theory,” 2016 IEEE Global Communications Conference
(GLOBECOM), Washington, DC, 2016, pp. 1-6.
33
2327-4662 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
[162] N. Fotiou, T. Kotsonis, G. F. Marias and G. C. Polyzos, “Access
Control for the Internet of Things,” 2016 International Workshop on
Secure Internet of Things (SIoT), Heraklion, 2016, pp. 29-38.
[163] M. Abomhara and G. M. Koien, “Security and privacy in the Internet of
Things: Current status and open issues,” 2014 International Conference
on Privacy and Security in Mobile Systems (PRISMS), Aalborg, 2014,
pp. 1-8.
[164] D. P. F. Moller and H. Vakilzadian, “Cyber-physical systems in
smart transportation,” 2016 IEEE International Conference on Electro
Information Technology (EIT), Grand Forks, ND, 2016, pp. 0776-0781.
[165] D. H. Mrityunjaya, N. Kumar, Laxmikant, S. Ali and H. M. Kelagadi,
“Smart transportation,” 2017 International Conference on I-SMAC (IoT
in Social, Mobile, Analytics and Cloud) (I-SMAC), Palladam, 2017, pp.
1-5.
[166] N. K. Giang, V. C. M. Leung, and R. Lea, “On Developing Smart
Transportation Applications in Fog Computing Paradigm,” Proceedings
of the 6th ACM Symposium on Development and Analysis of Intelligent
Vehicular Networks and Applications (DIVANet ’16), ACM, New York,
NY, USA, 2016, pp. 91-98.
[167] F. Y. Okay and S. Ozdemir, “A fog computing based smart grid
model,” 2016 International Symposium on Networks, Computers and
Communications (ISNCC), Yasmine Hammamet, 2016, pp. 1-6.
[168] S. Yi, Z. Hao, Z. Qin and Q. Li, “Fog Computing: Platform and
Applications,” 2015 Third IEEE Workshop on Hot Topics in Web Systems
and Technologies (HotWeb), Washington, DC, 2015, pp. 73-78.
[169] R. J. Tom and S. Sankaranarayanan, “IoT based SCADA integrated
with Fog for power distribution automation,” 2017 12th Iberian Confer-
ence on Information Systems and Technologies (CISTI), Lisbon, 2017,
pp. 1-4.
[170] M. H. Yaghmaee and A. Leon-Garcia, “A Fog-Based Internet of
Energy Architecture for Transactive Energy Management Systems,” IEEE
Internet of Things Journal, vol. PP, no. 99, pp. 1-1.
[171] S. B. Baker, W. Xiang and I. Atkinson, “Internet of Things for Smart
Healthcare: Technologies, Challenges, and Opportunities,” IEEE Access,
vol. 5, pp. 26521-26544, 2017.
[172] K. Aziz, S. Tarapiah, S. H. Ismail and S. Atalla, “Smart real-time
healthcare monitoring and tracking system using GSM/GPS technolo-
gies,” 2016 3rd MEC International Conference on Big Data and Smart
City (ICBDSC), Muscat, 2016, pp. 1-7.
[173] P. Verma and S. K. Sood, “Fog Assisted-IoT Enabled Patient Health
Monitoring in Smart Homes,” IEEE Internet of Things Journal, vol. PP,
no. 99, pp. 1-1.
[174] S. Suresh and P. V. Sruthi, “A review on smart home technology,” 2015
Online International Conference on Green Engineering and Technologies
(IC-GET), Coimbatore, 2015, pp. 1-3.
[175] B. R. Stojkoska and K. Trivodaliev, “Enabling internet of things for
smart homes through fog computing,” 2017 25th Telecommunication
Forum (TELFOR), Belgrade, Serbia, 2017, pp. 1-4.
[176] N. Mohamed, S. Lazarova-Molnar and J. Al-Jaroodi, “Cloud of Things:
Optimizing smart city services,” 2017 7th International Conference on
Modeling, Simulation, and Applied Optimization (ICMSAO), Sharjah,
2017, pp. 1-5.
[177] B. Cheng, M. Wang, S. Zhao, Z. Zhai, D. Zhu and J. Chen,
“Situation-Aware Dynamic Service Coordination in an IoT Environment,”
IEEE/ACM Transactions on Networking, vol. 25, no. 4, pp. 2082-2095,
Aug. 2017.
[178] N. M. Balasubramanya, L. Lampe, G. Vos and S. Bennett, “DRX With
Quick Sleeping: A Novel Mechanism for Energy-Efficient IoT Using
LTE/LTE-A,” IEEE Internet of Things Journal, vol. 3, no. 3, pp. 398-
407, June 2016.
[179] N. Verba, K. M. Chao, A. James, J. Lewandowski, X. Fei and C. F.
Tsai, “Graph Analysis of Fog Computing Systems for Industry 4.0,” 2017
IEEE 14th International Conference on e-Business Engineering (ICEBE),
Shanghai, 2017, pp. 46-53.
[180] J. Li, J. Jin, D. Yuan and H. Zhang, “Virtual Fog: A Virtualization En-
abled Fog Computing Framework for Internet of Things,” IEEE Internet
of Things Journal, vol. 5, no. 1, pp. 121-131, Feb. 2018.
[181] P. K. Sharma, M. Y. Chen and J. H. Park, “A Software Defined Fog
Node Based Distributed Blockchain Cloud Architecture for IoT,” IEEE
Access, vol. 6, pp. 115-124, 2018.