INTERNET OF THINGS DEFINITION EVOLUTION

1.2.1 IoT EMERGENCE

Kevin Ashton is accredited for using the term “Internet of Things” for the first time during a
presentation in 1999 on supply-chain management [6]. He believes the “things” aspect of the
way we interact and live within the physical world that surrounds us needs serious
reconsideration, due to advances in computing, Internet, and data-generation rate by smart
devices. At the time, he was an executive director at MIT’s Auto-ID Center, where he
contributed to the extension of RFID applications into broader domains, which built the
foundation for the current IoT vision.
1.2.2 INTERNET OF EVERYTHING
Since then, many definitions for IoT have been presented, including the definition [7] that
focuses mostly on connectivity and sensory requirements for entities involved in typical IoT
environments. Whereas those definitions reflect IoT’s basic requirements, new IoT
definitions give more value to the need for ubiquitous and autonomous networks of objects
where identification and service integration have an important and inevitable role. For
example, Internet of Everything (IoE) is used by Cisco to refer to people, things, and places
that can expose their services to other entities [8].
1.2.3 INDUSTRIAL IoT
Also referred to as Industrial Internet [9], Industrial IoT (IIoT) is another form of IoT applications
favored by big high-tech companies. The fact that machines can perform specific tasks such as data acquisition
and communication more accurately than humans has boosted IIoT’s adoption. Machine to machine (M2M)
communication, Big Data analysis, and machine learning techniques are major building blocks when it comes to
the definition of IIoT. These data enable companies to detect and resolve problems faster, thus resulting in
overall money and time savings. For instance, in a manufacturing company, IIoT can be used to efficiently track
and manage the supply chain, perform quality control and assurance, and lower the total energy consumption.
1.2.4 SMARTNESS IN IoT
Another characteristic of IoT, which is highlighted in recent definitions, is “smartness.” This distinguishes IoT
from similar concepts such as sensor networks, and it can be further categorized into “object smartness” and
“network smartness.” A smart network is a communication infrastructure characterized by the following
functionalities:
• standardization and openness of the communication standards used, from layers interfacing with the physical
world (ie, tags and sensors), to the communication layers between nodes and with the Internet;
• object addressability (direct IP address) and multifunctionality (ie, the possibility that a network
built for one application (eg, road-traffic monitoring) would be available for other purposes (eg,
environmental-pollution monitoring or traffic safety) [10].

1.3 IoT ARCHITECTURES

The building blocks of IoT are sensory devices, remote service invocation, communication networks, and
context-aware processing of events; these have been around for many years. However, what IoT tries to picture
is a unified network of smart objects and human beings responsible for operating them (if needed), who are
capable of universally and ubiquitously communicating with each other. When talking about a distributed
environment, interconnectivity among entities is a critical requirement, and IoT is a good example. A holistic
system architecture for IoT needs to guarantee flawless operation of its components (reliability is considered as
the most import design factor in IoT) and link the physical and virtual realms together. To achieve this, careful
consideration is needed in designing failure recovery and scalability. Additionally, since mobility and dynamic
change of location has become an integral part of IoT systems with the widespread use of smartphones, state-of-
the-art architectures need to have a certain level of adaptability to properly handle dynamic interactions within
the whole ecosystem. Reference architectures and models give a bird’s eye view of the whole underlying
system, hence their advantage over other architectures relies on providing a better and greater level of
abstraction, which consequently hides specific constraints and implementation details.
FIGURE 1.3 A Reference Architecture for IoT
Several research groups have proposed reference architectures for IoT [19,20]. The IoT-A [19]
focuses on the development and validation of an integrated IoT network architecture and supporting building
blocks, with the objective to be “the European Lighthouse Integrated Project addressing the Internet-of-Things
Architecture.” IoT-i project, related to the previously mentioned IoT-A project, focuses on the promotion of IoT
solutions, catching requirements and interests. IoT-i aims to achieve strategic objectives, such as: creating a
joint strategic and technical vision for the IoT in Europe that encompasses the currently fragmented sectors of
the IoT domain holistically, and contributing to the creation of an economically sustainable and socially
acceptable environment in Europe for IoT technologies and respective R&D activities. Fig. 1.3 depicts an
outline of our extended version of a reference architecture for IoT [20]. Different service and presentation layers
are shown in this architecture. Service layers include event processing and analytics, resource management and
service discovery, as well as message aggregation and Enterprise Service Bus (ESB) services built on top of
communication and physical layers. API management, which is essential for defining and sharing system
services and web-based dashboards (or equivalent smartphone applications) for managing and accessing these
APIs, are also included in the architecture. Due to the importance of device management, security and privacy
enforcement in different layers, and the ability to uniquely identify objects and control their access level, these
components are prestressed independently in this architecture. These components and their related research
projects are described in more detail throughout this chapter.

SOA-BASED ARCHITECTURE
In IoT, service-oriented architecture (SOA) might be imperative for the service providers and users [21,22].
SOA ensures the interoperability among the heterogeneous devices [23,24]. To clarify this, let us consider a
generic SOA consisting of four layers, with distinguished functionalities as follows:
• Sensing layer is integrated with available hardware objects to sense the status of things
• Network layer is the infrastructure to support over wireless or wired connections among things Service layer is
to create and manage services required by users or applications • Interfaces layer consists of the interaction
methods with users or applications Generally, in such architecture a complex system is divided into subsystems
that are loosely coupled and can be reused later (modular decomposability feature), hence providing an easy
way to maintain the whole system by taking care of its individual components [25]. This can ensure that in the
case of a component failure the rest of the system (components) can still operate normally. This is of immense
value for effective design of an IoT application architecture, where reliability is the most significant parameter.
SOA has been intensively used in WSN, due to its appropriate level of abstraction and advantages pertaining to
its modular design [26,27]. Bringing these benefits to IoT, SOA has the potential to augment the level of
interoperability and scalability among the objects in IoT. Moreover, from the user’s perspective, all services are
abstracted into common sets, removing extra complexity for the user to deal with different layers and protocols
[28]. Additionally, the ability to build diverse and complex services by composing different functions of the
system (ie, modular composability) through service composition suits the heterogeneous nature of IoT, where
accomplishing each task requires a series of service calls on all different entities spread across multiple locations
[29].
API-ORIENTED ARCHITECTURE
Conventional approaches for developing service-oriented solutions use SOAP and Remote Method Invocation
(RMI) as a means for describing, discovering, and calling services; however, due to overhead and complexity
imposed by these techniques, Web APIs and Representational State Transfer (REST)- based methods were
introduced as promising alternative solutions. The required resources range from network bandwidth to
computational and storage capacity, and are triggered by request–response data conversions happening regularly
during service calls. Lightweight data-exchange formats like JSON can reduce the aforementioned overhead,
especially for smart devices and sensors with a limited amount of resources, by replacing large XML files used
to describe services. This helps in using the communication channel and processing the power of devices more
efficiently. Likewise, building APIs for IoT applications helps the service provider attract more customers while
focusing on the functionality of their products rather than on presentation. In addition, it is easier to enable
multitenancy by the security features of modern Web APIs such as OAuth, APIs which indeed are capable of
boosting an organization’s service exposition and commercialization. It also provides more efficient service
monitoring and pricing tools than previous service-oriented approaches [30]. To this end, in our previous
research we have proposed Simurgh [31], which describes devices, sensors, humans, and their available services
using web API notation and API definition languages. Furthermore, a two-phase discovery approach was
proposed in the framework to find sensors that provide desirable services and match certain features, like being
in a specific location. Similarly, Elmangoush et al. [32] proposed a service-broker layer (named FOKUS) that
exposes a set of APIs for enabling shared access to the OpenMTC core. Novel approaches for defining and
sharing services in distributed and multiagent environments like IoT can reduce the sophistication of service
discovery in the application development cycle and diminish service-call overhead in runtime. Shifting from
service delivery platforms (SDPs) toward web-based platforms, and the benefits of doing so are discussed by
Manzalini et al. [33]. Developers and business managers are advised to focus on developing and sharing APIs
from the early stage of their application development lifecycle, so that eventually, by properly exposing data to
other developers and end users, an open-data environment is created that facilitates collaborative information
gathering, sharing, and updating.

Open Connectivity Foundation (OCF)

The Open Connectivity Foundation (OCF) was originally formed under the name Open Interconnect
Consortium (OIC). Broadcom, Intel, and Samsung were among the initial founders of OIC and were
later joined byElectrolux, Microsoft, and Qualcomm. IoTivity is the open source reference
implementation of both OIC and OCF specifications. The OIC later became OCF when the AllSeen
Alliance and OIC merged in October of 2016. The AllSeen Alliance is discussed in more detail in a
following section. The OCF framework (Figure 2-8) consists of three layers, Transports, Core
Framework, and Profiles. The transport layer is a plugin interface that supports any number of
transport plugin modules. Although the architecture refers to them as transports, the remaining
networking layers (network, data link, and physical) are presumed to be provided as well. The OCF
specifications do not prescribe how the layers are implemented, but the IoTivity reference
implementation (see https://iotivity.org/downloads) may offer guidance. Support for various wired
and wireless transports in IoTivity continues to grow. At the time of this writing, there was support for
CoAP (UDP) over IPv4, IPv6, Ethernet, Wi-Fi, and Bluetooth LE. At the time of this writing, an
Object Security for Constrained RESTful Environments (OSCORE) draft specification22 defines a
REST message binding to CoAP and HTTP. OSCORE supports connections originating in IoT
networks based on a UDP transport that terminates in cloud services environments or remote access
gateways that are based on a TCP transport. OCF transport plugin module interface is transport
agnostic, making it possible to define transport plugin modules that implement REST
(Representational State Transfer) semantics. This implies OCF transport plugins could implement
message queuing techniques such as MQTT (Message Queuing Telemetry Transport) or XMPP
(eXtensible Messaging and Presence Protocol) without structural modifications to the framework.

The transport interface interaction model roughly follows an objectlifecycle pattern called CRUDN –
Create, Retrieve, Update, Delete, and Notify. RESTful interaction semantics easily map to a series of
request-response exchanges for each interaction – for example, Send Create_Request message
followed by Receive Create_Response message. OCF interface semantics are typically defined using
RAML23 (RESTful API Modeling Language), although there is interest in migrating to
Swagger24 which complies with the OpenAPI specification. The OpenAPI specification25 is an open
source community effort aimed at defining robust data modeling languages and tools.

OCF conceptual framework

OCF Core Framework Layer
The Core Framework lies at the center of the OCF architecture. It definesthe “resource”
abstraction model which is arguably its most fundamental building block concept and the
characteristic that most distinguishes it from other frameworks. An OCF resource is
primarily a sequence of tag-value pairs but can have nested sequences as well. Resources are
typically described using JSON. The OCF resource model approach to IoT networking
presumes all aspects of the network can be represented declaratively, as a set of resource data
structures having CRUDN interaction semantics. The traditional notion of a network
topology consisting of nodes having routable IP addresses is hidden behind the resource
abstraction. Resources have several built-in properties (tags) that are common to
all resources such as name, resource type, interface type, and whether or not it is discoverable
and observable. Resource names are a URI (Universal Resource Identifier). Property names
and name prefixes that are common to all are reserved by the OCF specification.

INTERNET COMMUNICATIONS:
AN OVERVIEW
Suppose that you wanted to send a message to the authors of this book, but you didn’t have
the postal address, and you didn’t have any way to look up our phone number (because in this
example you don’t have the Internet). You remember that we’re from the UK, and London is
the biggest city in the UK. So you send a postcard to your cousin Bob, who lives there. Your
cousin sees that the postcard is for some crazy hardware and technology people. So he puts
the postcard in an envelope and drops it off at the London Hackspace because the guys there
probably know what to do with it. At the Hackspace, Jonty picks up the envelope and sees
that it’s for some people in Liverpool. Like all good Londoners, Jonty never goes anywhere
to the north of Watford, but he remembers that Manchester is in the north too. So he calls up
the Manchester Digital Laboratory (MadLab), opens the envelope to read the contents, and
says, “Hey, I’ve got this message for Adrian and Hakim in Liverpool. Can you pass it on?”
The guys at MadLab ask whether anyone knows who we are, and it turns out that Hwa Young
does. So the next time she comes to Liverpool, she delivers the postcard to us. IP The
preceding scenario describes how the Internet Protocol (IP) works. Data is sent from one
machine to another in a packet, with a destination address and a source address in a
standardised format (a “protocol”). Just like the original sender of the message in the
example, the sending machine doesn’t always know the best route to the destination in
advance. Most of the time, the packets of data have to go through a number of intermediary
machines, called routers, to reach their destination. The underlying networks aren’t
always the same: just as we used the phone, the postal service, and delivery by hand, so data
packets can be sent over wired or wireless networks, through the phone system, or over
satellite links. In our example, a postcard was placed in an envelope before getting passed
onwards. This happens with Internet packets, too. So, an IP packet is a block of data along
with the same kind of information you would write on a physical envelope: the name and
address of the server, and so on. But if an IP packet ever gets transmitted across your local
wired network via an Ethernet cable—the cable that connects your home broadband router or
your office local area network (LAN) to a desktop PC—then the whole packet will get
bundled up into another type of envelope, an Ethernet Frame, which adds additional
information about how to complete the last few steps of its journey to your computer. Of
course, it’s possible that your cousin Bob didn’t know about the London Hackspace, and then
maybe the message would have got stuck with him. You would have had no way to know
whether it got there. This is how IP works. There is no guarantee, and you can send only what
will fit in a single packet.
TCP
What if you wanted to send longer messages than fit on a postcard? Or wanted to make sure
your messages got through? What if everyone agreed that postcards written in green ink
meant that we cared about whether they arrived. And that we would always number them,
so if we wanted to send longer messages, we could. The person at the other end would be
able to put the messages in order, even if they got delivered in the wrong order (maybe you
were writing your letter over a number of days, and the day you passed the fifth one on to
cousin Bob, he happened to visit Liverpool and passed on that postcard without relaying
through London Hackspace or MadLab). We would send back postcard notifications that just
told you which postcards we had received, so you could resend any that went missing.
That is basically how the Transmission Control Protocol (TCP) works. The simplest transport
protocol on the Internet, TCP is built on top of the basic IP protocol and adds sequence
numbers, acknowledgements, and retransmissions. This means that a message sent with TCP
can be arbitrarily long and give the sender some assurance that it actually arrived at the
destination intact. Because the combination of TCP and IP is so useful, many services are
built on it in turn, such as email and the HTTP protocol that transmits information
across the World Wide Web.
THE IP PROTOCOL SUITE (TCP/IP)
The combination of TCP and IP is so ubiquitous that we often refer simply to “TCP/IP” to
describe a whole suite or stack of protocols layered on top of each other, each layer building
on the capabilities of the one below.
 The low-level protocols at the link layer manage the transfer of bits of information across
a network link. This could be by an Ethernet cable, by WiFi, or across a telephone network,
or even by short-range radio standards such as IEEE 802.15.4 designed to carry data over the
Personal Area Network (PAN), that is to say between devices carried by an individual.
The Internet layer then sits on top of these various links and abstracts away the gory
details in favour of a simple destination address.
Then TCP, which lives in the transport layer, sits on top of IP and extends it with more
sophisticated control of the messages passed.
Finally, the application layer contains the protocols that deal with fetching web pages,
sending emails, and Internet telephony. Of these, HTTP is the most ubiquitous for the web,
and indeed for communication between Internet of Things devices. We look at standards such
as MQTT briefly in Chapter 7.
UDP
As you can see, TCP is not the only protocol in the transport layer. Unlike TCP, but as with IP
itself, in UDP each message may or may not arrive. No handshake or retransmission occurs,
nor is there any delay to wait for messages in sequence. These limitations make TCP
preferable for many of the tasks that Internet of Things devices will be used for. The lack of
overhead, however, makes UDP useful for applications such as streaming data, which can
cope with minor errors but doesn’t like delays. Voice over IP (VoIP)—computer-based
telephony, such as Skype—is an example of this: missing one packet might cause a tiny glitch
in the sound quality, but waiting for several packets to arrive in the right order could
make the speech too jittery to be easy to understand. UDP is also the transport for some very
important protocols which provide common, low-level functionality, such as DNS and DHCP,
which relate to the discoveryand resolution of devices on the network. We look at this topic in
detail in the next section.

IP ADDRESSES
We mentioned earlier that the Internet Protocol knows the addresses of the destination and
source devices. But what does an “address” consist of? Here is a typical human (or in this
case, hobbit) address:
Bilbo Baggins
“Bag End”, Bagshot Row
Hobbiton
The Shire
Middle Earth

In the world of low-level computer networking, however, numbers are much easier to deal
with. So, IP addresses are numbers. In Internet Protocol version 4 (IPv4), almost 4.3 billion
IP addresses are possible—4,294,967,296 to be precise, or 232. Though that is convenient for
computers, it’s tough for humans to read, so IP addresses are usually written as four 8-bit
numbers separated by dots (from 0.0.0.0 to 255.255.255.255)—for example, 192.168.0.1
(which is often the address of your home router) or 8.8.8.8 (which is the address of one of
Google’s DNS servers). This “dotted quad” is still exactly equivalent to the 32-bit number. As
well as being simply easier for humans to remember, it is also easier to infer information
about the address by grouping certain blocks of addresses together. For example, 8.8.8.x —
One of several IP ranges assigned to Google. 192.168.x.x — A range assigned for private
networks. Your home or office network router may well assign IP addresses in this range.
10.x.x.x — Another private range.
Every machine on the Internet has at least one IP address. That means every computer, every
network-connected printer, every smartphone, and everyInternet of Things device has one. If
you already have a Raspberry Pi, an Arduino board, or any of the other microcontrollers
described in Chapters 3 and 4, they will expect to get their own IP address, too. When you
consider this fact, those 4 billion addresses suddenly look as if they might not be enough. The
private ranges such as 192.168.x.x offer one mitigation to this problem. Your home or office
network might have only one publicly visible IP address. However, you could have all the IP
addresses in the range 192.168.0.0 to 192.168.255.255 (2^16 = 65,536 addresses) assigned
to distinct devices. A better solution to this problem is the next generation of Internet
protocol, IPv6, which we look at later in this chapter. DNS Although computers can easily
handle 32-bit numbers, even formatted as dotted quads they are easy for most humans to
forget. The Domain Name System (DNS) helps our feeble brains navigate the Internet.
Domain names, such as the following, are familiar to us from the web, or perhaps from email
or other services:
google.com
bbc.co.uk
wiley.com
arduino.cc
Each domain name has a top-level domain (TLD), like .com or.uk, which further subdivides
into .co.uk and .gov.uk, and so on. This top-level domain knows where to find more
information about the domains within it; for example, .com knows where to find google.com
and wiley.com. The domains then have information about where to direct calls to individual
machines or services. For example, the DNS records for .google.com know where to point
you for the following:
www.google.com
mail.google.com
calendar.google.com
The preceding examples are all instantly recognizable as website names, which is to say you
could enter them into your web browser as, for example, http://www.google.com
But DNS can also point to other services on the Internet—for example:
pop3.google.com — For receiving email from Gmail
smtp.google.com — For sending email to Gmail
ns1.google.com — The address of one of Google’s many DNS
servers
Configuring DNS is a matter of changing just a few settings. Your registrar (the company that
sells you your domain name) often has a control panel to change these settings. You might
also run your own authoritative DNS server. The settings might contain entries like this one
for roomofthings.com:
book A 80.68.93.60 3h

This entry means that the address book.roomofthings.com (which hosts the blog for this
book) is served by that IP address and will be for the next three hours.