2. ī The discipline of IoT network architecture is new and
requires a fresh perspective.
ī It is important to note that while some similarities
between IT and IoT architectures do exist for the most
part, the challenges and requirements of IoT systems
are radically different from those of traditional IT
networks.
3. Overview of the module
ī Drivers Behind New Network Architectures: OT
networks drive core industrial business operations.
They have unique characteristics and constraints that
are not easily supported by traditional IT network
architectures.
ī Comparing IoT Architectures: Several architectures
have been published for IoT, including those by ETSI
and the IoT World Forum.
4. Overview of the module
ī A Simplified IoT Architecture: While several IoT
architectures exist, a simplified model is presented in this
section to lay a foundation for rest of the topics
ī The Core IoT Functional Stack: The IoT network must
be designed to support its unique requirements and
constraints. This section provides an overview of the full
networking stack, from sensors all the way to the
applications layer.
ī IoT Data Management and Compute Stack: This
section introduces data management, including storage
and compute resource models for IoT, and involves edge,
fog, and cloud computing.
7. Comparing IOT Architectures
ī The aforementioned challenges and requirements of
IoT systems have driven a whole new discipline of
network architecture. In the past several years,
architectural standards and frameworks have emerged
to address the challenge of designing massive-scale
IoT networks.
ī The foundational concept in all these architectures is
supporting data, process, and the functions that
endpoint devices perform. Two of the best-known
architectures are those supported by oneM2M and the
IoT World Forum (IoTWF).
9. The IoT World Forum (IoTWF)
Standardized Architecture
10. ī Physical Devices and Controllers Layer
This layer is home to the âthingsâ in the Internet of
Things, including the various endpoint devices and
sensors that send and receive information. The size of
these âthingsâ can range from almost microscopic
sensors to giant machines in a factory. Their primary
function is generating data and being capable of being
queried and/or controlled over a network.
11.
12.
13.
14. IT and OT Responsibilities in the
IoT Reference Model
17. The Core IoT Functional Stack
ī âThingsâ layer: At this layer, the physical devices need to fit the constraints of the
environment in which they are deployed while still being able to provide the
information needed.
ī Communications network layer: When smart objects are not self-contained, they
need to communicate with an external system. In many cases, this communication
uses a wireless technology. This layer has four sub layers:
īŧ Access network sub layer: The last mile of the IoT network is the access network.
This is typically made up of wireless technologies such as 802.11ah, 802.15.4g, and
LoRa. The sensors connected to the access network may also be wired.
īŧ Gateways and backhaul network sublayer: The gateway communicates directly
with the smart objects. The role of the gateway is to forward the collected
information through a longer-range medium (called the backhaul) to a headend
central station where the information is processed.. On IP networks, this gateway
also forwards packets from one IP network to another, and it therefore acts as a
router.
18. The Core IoT Functional Stack
īŧ Network transport sub layer: For communication to be successful, network
and transport layer protocols such as IP and UDP must be implemented to
support the variety of devices to connect and media to use.
īŧ IoT network management sublayer: Additional protocols must be in place
to allow the headend applications to exchange data with the sensors.
Examples include CoAP and MQTT.
ī Application and analytics layer: At the upper layer, an application needs
to process the collected data, not only to control the smart objects when
necessary, but to make intelligent decision based on the information
collected and, in turn, instruct the âthingsâ or other systems to adapt to the
analyzed conditions and change their behaviors or parameters.
19. Layer 1: Things: Sensors and Actuators Layer
īBattery-powered or power-connected:
īMobile or static
īLow or high reporting frequency
īSimple or rich data
īReport range
īObject density per cell
21. Layer 2: Communications Network
Layer
ī Access Network Sub layer
ī There is a direct relationship between the IoT network
technology you choose and the type of connectivity topology
this technology allows.
ī Each technology was designed with a certain number of use
cases in mind (what to connect, where to connect, how much
data to transport at what interval and over what distance).
ī These use cases determined the frequency band that was
expected to be most suitable, the frame structure matching the
expected data pattern (packet size and communication
intervals), and the possible topologies that these use cases
illustrate.
23. Range Estimate Groups
ī PAN (personal area network): Scale of a few meters. This is
the personal space around a person. A common wireless
technology for this scale is Bluetooth.
ī HAN (home area network): Scale of a few tens of meters. At
this scale, common wireless technologies for IoT include
ZigBee and Bluetooth Low Energy (BLE).
ī NAN (neighborhood area network): Scale of a few hundreds
of meters. The term NAN is often used to refer to a group of
house units from which data is collected.
24. Range Estimate Groups
īFAN (field area network): Scale of several tens
of meters to several hundred meters. FAN
typically refers to an outdoor area larger than a
single group of house units. The FAN is often seen
as âopen spaceâ (and therefore not secured and not
controlled
ī LAN (local area network): Scale of up to 100 m.
This term is very common in networking, and it is
therefore also commonly used in the IoT space
when standard networking technologies (such as
Ethernet or IEEE 802.11) are used.
25. Comparison Between Common Last-Mile
Technologies in Terms of Range Versus
Cost, Power, and Bandwidth
26. Gateways and Backhaul Sublayer
īData collected from a smart object may need to be
forwarded to a central station where data is processed.
īAs this station is often in a different location from the
smart object, data directly received from the sensor
through an access technology needs to be forwarded to
another medium (the backhaul) and transported to
the central station.
ī The gateway is in charge of this inter-medium
communication.
28. Network Transport Sublayer
ī The communication structure may involve peer-to-peer (for
example, meter to meter), point-to-point (meter to headend
station), point-to-multipoint (gateway or head-end to multiple
meters), unicast and multicast communications (software
update to one or multiple systems
ī To allow good communication structure, a network protocol
with specific characteristics needs to be implemented. The
protocol needs to be open and standard-based to accommodate
multiple industries and multiple media. Scalability (to
accommodate thousands or millions of sensors in a single
network) and security are also common requirements.
29. IoT Network Management
Sublayer
īFollowing the IP logic, some IoT implementers have
suggested HTTP for the data transfer phase. After all,
HTTP has a client and server component. The sensor
could use the client part to establish a connection to the
IoT central application (the server), and then data can be
exchanged
īWeb Socket is part of the HTML5 specification, and
provides a simple bidirectional connection over a single
connection. Some IoT solutions use Web Socket to
manage the connection between the smart object and an
external application. Web Socket is often combined with
other protocols, such as MQTT (described shortly) to
handle the IoT-specific part of the communication
30. XMPP
īWith the same logic of reusing well-known methods,
Extensible Messaging and Presence Protocol (XMPP)
was created. XMPP is based on instant messaging and
presence. It allows the exchange of data between two
or more systems and supports presence and contact
list maintenance.
īA limitation of XMPP is its reliance on TCP, which may
force subscribers to maintain open sessions to other
systems and may be a limitation for memory-
constrained objects.
31. CoAP
īCoAP uses some methods similar to those of HTTP
(such as Get, Post, Put, and Delete) but implements a
shorter list, thus limiting the size of the header. CoAP
also runs on UDP (whereas HTTP typically uses TCP).
īCoAP also adds a feature that is lacking in HTTP and
very useful for IoT: observation. Observation allows
the streaming of state changes as they occur, without
requiring the receiver to query for these changes.
32. MQTT
īMQTT uses a broker-based architecture. The sensor can
be set to be an MQTT publisher (publishes a piece of
information), the application that needs to receive the
information can be set as the MQTT subscriber, and any
intermediary system can be set as a broker to relay the
information between the publisher and the subscriber(s).
īMQTT client typically holds a connection open to the
broker at all times. This may be a limiting factor in
environments where loss is high or where computing
resources are limited.