The Internet of Things - White paper - version 1.0

THE INTERNET OF THINGS 1
The Internet of Things
An overview of the architecture, reference model and system components
Andre Ferreira
Senior Solutions Architect – IoT Systems
Dimension Data

Table of Contents
Introduction......................................................................................................................... 4
The IoT reference model..................................................................................................... 6
Reference Architecture........................................................................................................ 8
Architecture overview..................................................................................................... 9
Devices Layer ............................................................................................................. 9
Communications Layer............................................................................................. 10
Aggregation Layer .................................................................................................... 10
Data Processing Layer .............................................................................................. 10
External Access Layer............................................................................................... 10
Management Layer ................................................................................................... 11
Security Layer........................................................................................................... 11
Components of an IoT system .......................................................................................... 12
Sensors.......................................................................................................................... 12
Actuators....................................................................................................................... 14
Communications layer .................................................................................................. 14
Gateways....................................................................................................................... 15
Application Enablement Platform................................................................................. 15
Customer Application ................................................................................................... 15
Summary........................................................................................................................... 16

Table of figures
Figure 1 - The IoT World Forum seven layer model ...................................................................... 6
Figure 2 - Internet of Things – Architecture Group reference architecture framework.................. 8
Figure 3 - IoT Reference Architecture............................................................................................ 9
Figure 4 - A representative IoT system......................................................................................... 12

Introduction
Short of Software Defined Networking or SDN, the term IoT must rate as one of the IT
industries’ recently most hyped, and most confused, three letter acronyms. The term is
generically used to cover anything related to smart connected objects and their
intercommunication, but by all accounts, the IoT phenomena could have as big an
impact on our lives as the Internet has since its inception all those years ago.
The concept of machine to machine communication (M2M) and connected devices is
nothing new. Supervisory Control And Data Acquisition (SCADA) networks having been
around for decades, controlling power plants and factories before even the Internet
existed. The actual term “Internet of Things” was coined at MIT back in 1991, however,
the confluence of enabling technologies, decreasing component costs, increasing
processing power and application frameworks designed to manage and analyse massive
data sets (big data), have created the environment under which a connected device
world can flourish.
In its most basic form, an IoT system essentially revolves around physical entities that
observe their environment, report this data back to a central application which then
makes decisions based on the incoming data. The application could issue instructions
to actuators that would change the state of the system, or they may simply provide this
data to other systems for analysis and decision making.
Either way, the heart of any IoT system, is the data that is gathered from the sensors.
Without this constant flow of ever changing data, the IoT system is useless. However,
while the concept may sound simple enough, the actual implementation is certainly non
trivial, to say the least. This hidden complexity has given rise to a great deal of confusion
over what an IoT system is and how it works.
To alleviate confusion and misunderstanding in any technology industry, standards
bodies build two artefacts that can be used by industry players to promote a particular
technology concept and formalise development and integration between interested
parties.
The first is a reference model which will promote a common understanding of the
concept across industry vertical boundaries, while the second is a reference
architecture that will allow players to build functional, interoperable systems or system
components. Therefore, by making use of this common understanding (model) and best
practice (reference architecture), and by inputting situation specific parameters, a
systems architect can select the protocols, functional components and architectures
required to build a functioning system for their specific requirement.

To this end, it is important to first understand both the reference model and reference
architecture at a high level before diving into the more technical aspects of what makes
up a complete IoT system.
This document will briefly describe these reference components and then continue on
to analyse the detailed technical components of a generic IoT system.

The IoT reference model
The World Forum on Internet of Things have developed a 7-layer model, Figure 1, to
identify and classify the various functional layers of any IoT system.
Figure 1 - The IoT World Forum seven layer model
The model is not dissimilar to the networking ISO 7-layer model in the way it abstracts
the various functional layers, and can essentially be distilled down to three basic
sections.
At the bottom of the model, comprising layers 1 and 2, one has the physical entities
interfacing with the system under study, and the transmission medium allowing them to
communicate, while at the top of the model, at layers 6 and 7, one has the application
layer. The application layer is responsible for reporting, analysing and making decisions
based on the information being collected by the sensors.
The central component of the model, layer 3 through 5, is responsible for the managing
the end devices, collecting their data, sorting and aggregating the data and making it
available to the applications above.
When broken down in this manner, one can quickly see the challenge facing the industry
with regard to formulating some cohesive model and architecture framework for IoT.
The IoT world essentially spans (at least) three fundamentally disparate vertical
technology sectors. The sensor market comes out of the engineering world and is
steeped in legacy and strict standards bodies. This is the world of electronics and
protocols such as RS323 or MODBUS.

The application layer represents an altogether more fluid environment, with rapidly
evolving programming languages, development frameworks and minimal interest in the
hardware upon which they operate. Applications, by their very design, ignore the
technology layers below them and assume a level of hardware abstraction that makes
them scalable and portable across differing underlying technologies.
The middle section of the model, conversely, is more akin to a traditional IT environment
with standard IT networks, systems and processes.
When combined, little commonality is found in the architectures, understanding or
operating environments of the three sections, leading to the fragmented approach to
IoT one sees today.
For an entity to produce a viable, transferable and scalable IoT solution, they would
require skills in all three of these diverse sectors of the market and would either need
to build an “across the model” competency in house, or partner with other entities who
have the required skills.
To build an in-house IoT competency would require some degree of engineering
capability, a strong networking and data management capability and an application
development division. Not many organisations exist today that fit this bill, thus one sees
the market currently in the state where very few organisations are attempting this
“across the model” approach. Rather, organisations are focussing on one or two of the
sections and attempting to become the leader in that space.
This is borne out with some organisations spending R&D time and effort on the sensor
market, while others are building sensor communication networks. Still others are
developing gateways and aggregation devices, while others are offering the
management and data aggregation services (usually in the cloud). Organisations with
a software background are ignoring all the lower layers and focussing solely on
converting the incoming data into information and then knowledge.
From a future revenue point of view, the application layer is likely to be the most
profitable as the lower layers become increasingly commoditised. One would expect to
see more players entering this section of the market over time.

Reference Architecture
The Institute of Electrical and Electronic Engineers (IEEE), one of the foremost
engineering standards bodies, defines a technology architecture as follows:
“The fundamental organization of a system embodied in its components,
their relationships to each other, and to the environment, and the
principles guiding its design and evolution”.
When one talks IoT architectures in terms of the above definition, it is clear that the
“system”, in this case a IoT system, will comprise a number of differing components
from a diverse range of technologies. As discussed above, these will range from the
engineering focused sensors, via the IT focused data transport, aggregation and
storage, to the application focused processing and reporting.
In terms of usability, the Internet of Things – Architecture Group define the IoT reference
architecture as a resource to be used by system designers, that when combined with
use case requirements and other inputs, will results in valid concrete architectures as
described in Figure 2.
Figure 2 - Internet of Things – Architecture Group reference architecture framework

From a practical point of view, a reference architecture needs to have enough detail to
allow systems engineers to apply the principles effectively, while not providing so much
detail as to obscure the underlying intent.
Architecture overview
In its instantiation, a reference architecture consists of a number of layers, each of
which can be delivered through technology. The architecture must, by definition,
correlate closely with the reference model, since the two artefacts are used as input
resources when constructing concrete, solution specific architectures.
Figure 3 - IoT Reference Architecture
The architecture shown in Figure 3 describes such a layered approach. The layers are
detailed as follows:
Devices Layer
The device layer is where the sensors and actuators are described. This layer is typically
solution or market vertical specific, with sensor devices often being bespoke or highly
specialised around the specific physical entity under study. Legacy sensors make use
of proprietary protocols and generally require gateway devices to communicate with the
rest of the system.

Communications Layer
The communications layer is one of the fastest developing layers currently, with new
transport media being defined to meet the varying requirement of the sensors that are
communicating. For instance, WiFi can be used for high bandwidth capacity sensors,
however, it has a negative impact on sensor battery life. Zigbee can be used to create
localised, low volume, battery efficient mesh networks, however, the communications
range is severely limited. LoRa or SigFox can be used for long distance, battery efficient
communications, however, the data throughput is very limited. Each technology
developed has its pros and cons and the system designer will need to choose the
technology that best fits the requirement.
The communications layer, either way, needs to cater for the transport of any sensor
and actuator data in a seamless manner that is consistent with the rest of system.
Aggregation Layer
The aggregation layer is responsible for collating the various differing data channels,
formats and types emanating from the sensors below and presenting them in a clear,
reliable and consistent manner to the layer above. This layer is often best deployed via
a service bus or message broker running on a gateway device, and essentially forms
the glue that binds the, inherently diverse, world of sensors to the uniform world of
applications and data processing. It should be noted that this is the first of the layers
that could be delivered from the cloud.
Data Processing Layer
This layer, often called the Application Enablement layer, is responsible for processing
and analysing the streams of data arriving from the sensor gateways. It is also
responsible for storing the data in some meaningful manner. Output from this layer can
come in a number of different forms, ranging from simple reports to actual actions that
need to be effected via a return communication to an actuator in the Devices Layer.
This layer can also be instantiated in the cloud and, if the data volumes are large
enough, can be subject to big data analysis mechanisms.
External Access Layer
Once the data has been processed and analysed, it may be required for action by
external systems or parties. The layer would be responsible for the presentation and

management of these interactions, and is usually presented as some form of Application
Program Interface (API).
Management Layer
The first of the vertical layers, the management layer is responsible for managing the
functioning of each layer based on that layer’s specific activities. For instance, devices
might need to be managed in terms of their location, being wiped if stolen,
provisioned/activated/deactivated etc, or management of the aggregation layer could
revolve around issues and errors that occur with translation or messaging. Either way,
each functional layer of the architecture requires some level of management to ensure
its correct and continued operation.
Security Layer
Inherent in every system architecture today is the requirement for security, and the IoT
world has an added reliance on this layer owing to its fundamentally diverse nature.
From securing the devices themselves, to ensuring their identity, to encrypting the traffic
they generate, to securing their stored data, to ensuring secure access by third parties
to the data, the security layer is a complex combination of a number of security policies,
principles and systems.

Components of an IoT system
While the reference model and architecture are critical components in understanding
and designing a functional IoT system, it is worth investigating the actual physical
components that would make up a typical deployment. The diagram shown in Figure 4
below, describes a representative IoT system with a number of differing sensor types
and communications media.
Figure 4 - A representative IoT system
It should be noted that not all IoT systems will contain all the components described
below. Some simple systems may only require a subset of these components depending
on their size and application.
Sensors
The sensors in the IoT network are the source of all data for the IoT system. There are
a myriad of different sensor types ranging from a simple hall sensors signalling the

open/closed state of a door, to the more complex gas analysis sensors that can detect
trace gas elements in the air.
Sensors should not be thought of as IP connected devices on the network (akin to a
desktop PC for instance), but rather as sources of data. Sensors can either be simplistic,
or complex, but they all need to be able to report some value or other when required.
Sensor construction will usually be in two parts, with one part being the actual sensing
component (hall sensor, strain gauge, thermistor etc) and the other being the electronic
controller that is responsible to doing some low level conversion of the sensor reading
and then transmitting that value to the upstream gateway. However, the following are
true for sensors in general:
• The sensor may be unresponsive (may not be bidirectional)
Sensors are not required to be able to respond to queries. In their simplest
form, sensors will simply wake up on a trigger, transmit a value and go back
to sleep, regardless of whether the transmission was received or not. Some
early sensor protocols (such as SigFox) actually only allowed one-way
communication to reduce energy consumption.
• Sensors may not be always connected
Again, sensors are not required to be connected to the network at all times.
In fact, for remote battery powered sensors, this is discouraged as it
consumes valuable energy. These types of sensors will only power up their
radio modules when they have something to transmit.
• Sensors may not always have anything to communicate
Sensors are typically monitoring some physical value and may well be
programmed to only transmit data when this value deviates from a given
threshold. Thus, one could expect some sensors to go for days, months,
even years, without transmitting any data.
• Sensors may not implement a ‘full stack’
The simpler the sensor, the less power it will consume and the longer the
battery will last. However, with really simple sensors comes a lack of
processing power. These kinds of sensors my not be able to implement the
full protocol stack of their chosen communications technology. A good
example of such a sensor would be an RFID tag. The tag is incredibly simple
(to keep costs down) and as such can only implement a very simple
communications protocol. In situations like this, the upstream gateway will
be responsible to “filling in the blanks”

Actuators
Actuators are similar in nature to sensors, however, instead of reading a value off the
physical entity being monitored, they will effect an action on that entity. This could be
closing a switch, shutting off a value or bringing an entire plant to a halt. The scale of
the actuator would depend entirely on the IoT system deployed.
Actuators are functionally constructed in a similar manner to sensors, with the actuator
device (switch, valve etc) replacing the sensor element in the system. However,
actuators do require the ability to receive transmissions at any time and will normally
be continuously connected to the network to facilitate this.
Communications layer
The communications layer, while integral to any IoT system, differs substantially
depending on the communications medium in use. Essentially the communications
layer, in this context, is taken to mean the method through which sensors, actuators
and head-end devices are able to communicate back to the gateways in the greater IoT
network.
From a communications point of view (only), an IoT system can be compared to a mobile
telecommunications network, with end devices communicating via central controllers to
data stores, applications or other end devices. This analogy can be useful in
understanding the components of the communications system as, fundamentally, the
underlying infrastructure of an IoT system is very similar to that of a mobile service
provider network.
The IoT sensors can be likened to mobile handsets, connected to the network via some
form of radio frequency communication. The traffic from these end devices is
aggregated by IoT gateways, analogous to the MSP base stations. These gateways are
then further connected to the network core via (usually) fixed line IP connections.
Management of the end devices also happens in a similar manner, where a centralised
“network server”, or Home Location Register (HLR) in MSP parlance, is used to
authenticate, provision, manage and track end devices.
Mobile networks are also designed to cater for very large numbers of end devices and
the industry fully expects the same to be true for large scale IoT deployments.
It should be noted that this analogy is only suitable for the more IoT focused
communications media such as GSM, LoRa, SigFox, 6LoPWAN etc. When sensors are
connected via simpler RF regimes such as WiFi, Bluetooth or ZigBee, the scenario is
much simpler.

Gateways
Gateway devices may or may not exist in an IoT system. In some situations, it is possible
to combine the gateway function with the Application Enablement Platform (discussed
below), but this requires the sensors to have a fairly high level of sophistication.
Where gateways exist, they function to aggregate localised sensor data and are often
found at the bridge point between different transmission media. For instance, as shown
in Figure 4 above, a gateway could be found at the boundary between a LoRa or WiFi
RF termination and an Ethernet/IP handoff. The gateway will generally be responsible
for accepting the sensor data from a number of different sensors, converting this data
into a format suitable to send to the AEP and, possibly, storing the data for a limited
period of time. Gateways will generally not contain stateful information and can be
replaced without any changes to the sensors in the field.
Gateways often run a message bus or some similar common transport mechanism that
allows the AEP to access their data whenever required. The message format can vary,
but usually a common format such as JSON is used to structure messages on the bus.
Application Enablement Platform
The Application Enablement Platform (AEP) layer is possibly the most important
component of any IoT system and is seeing a large amount of industry development
currently. The term AEP is generically used for the functional layer responsible for the
collection, storage, processing and presentation of the sensor data, and can be as
simple or as complex as the system requires. A generic centralised AEP platform will,
by nature, be a complex system of receivers, databases, processing algorithms,
management components and API presentation layers, while, from a deployment point
of view, the AEP layer is often instantiated as a multi tenanted cloud based application
platform, although private deployment models also exist.
Customer Application
The customer application will differ for every deployed system in that this application
consumes the output of the AEP and produces information that is meaningful to the
specific customer for a specific set of incoming sensor data. A single customer could
have a number of applications, which could range from a simple web application
displaying graphs and gauges on a wall board, to full integration with an ERP system
automatically enabling workflows or other business processes based on the incoming
data.

Summary
While this document seeks to promote a fundamental understanding of what comprises
an IoT system from a technical point of view, much of the components are in a state of
flux. For instance, while the technology across the model, although new and evolving,
is fairly well understood, details of some of the functional layers still need much work.
There is still much to be done around securing IoT systems and the communications
layer has yet to be standardised and formalised. Data analysis and management, again,
is fairly well understood, however, data ownership and the commercialisation of this
data is not.
Vendors and integrators are currently battling to identify and secure a portion of this
evolving market that will best suit their existing operating models, making for new and
interesting business models and solutions from, sometimes unexpected, sources.
However, regardless of how one approaches the IoT market, one thing everyone agrees
upon is that it will fundamentally change the way the world operates. Aside from the
expected corporate and commercial benefits, we should expect to see a much better
application of technology to solving real world problems such as environmental resource
management, poverty, climate control and global hunger as IoT enables insights into
global systems that were never possible before.
Owing to its complexity and diverse technical nature, IoT is inherently an ecosystem of
players working together towards a common goal. This fact alone could well be its
defining, and most powerful, characteristic.

The Internet of Things - White paper - version 1.0

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to The Internet of Things - White paper - version 1.0

Similar to The Internet of Things - White paper - version 1.0 (20)

The Internet of Things - White paper - version 1.0