0% found this document useful (0 votes)
8 views

IoT Comp Module 3 Ppt Notes

Uploaded by

snehalparab183
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

IoT Comp Module 3 Ppt Notes

Uploaded by

snehalparab183
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 49

Module 3

The Core IoT Functional Stack


The Core IoT Functional Stack
• 3.1 Layer 1 – Things: Sensors and Actuators
Layer
• 3.2 Layer 2 – Communications Network Layer,
Access Network Sublayer, Gateways and
Backhaul Sublayer, Network Transport Sublayer,
IoT Network Management Sublayer
• 3.3 Layer 3 – Applications and Analytics Layer,
Analytics Vs. Control Applications, Data Vs.
Network Analytics, Data Analytics Vs. Business
Benefits, Smart Services
A SIMPLIFIED IOT ARCHITECTURE

 we can describe an IoT framework that highlights the


fundamental building blocks that are common to most IoT
systems and which is intended to help you in designing an IoT
network.

• This framework is presented as two parallel stacks:


i. The IoT Data Management and Compute Stack
ii. The Core IoT Functional Stack
A SIMPLIFIED IOT ARCHITECTURE
THE CORE IOT FUNCTIONAL STACK
 IoTnetworks are built around the concept of “things,”
or smart objects performing functions and delivering
new connected services.

 These objects are “smart” because they use a


combination of contextual information and configured
goals to perform actions.

 “thing” interacts with an external system to report


information that the smart object collects, to exchange
with other objects, or to interact with a management
platform.
 From an architectural standpoint, several components
have to work together for an IoT network to be
operational
 “Things” layer

 Communications network layer


⚫ Access network sublayer
⚫ Gateways and backhaul network sublayer
⚫ Network transport sublayer
⚫ IoT network management sublayer
 Application and analytics layer
LAYER 1: THINGS: SENSORS AND
ACTUATORS LAYER
 Most IoT networks start from the object, or “thing,”
that needs to be connected.

 From an architectural standpoint, the variety of


smart object types, shapes, and needs drive the
variety of IoT protocols and architectures.
1. Battery-powered or power-connected
2. Mobile or static
3. Low or high reporting frequency
4. Simple or rich data
5. Report range
6. Object density per cell
 Battery-powered or power-connected
⚫ This classification is based on whether the object carries its
own energy supply or receives continuous power from an
external power source.

⚫ Battery-powered things can be moved more easily than line-


powered objects.

⚫ Batteries limit the lifetime and amount of energy that the


object is allowed to consume, thus driving transmission
range and frequency
 Mobile or static:
⚫ This classification is based on whether the “thing”
should move or always stay at the same location.

⚫ A sensor may be mobile because it is moved from one


object to another or because it is attached to a moving
object

⚫ The frequency of the movement may also vary, from


occasional to permanent.
 Low or high reporting frequency
⚫ This classification is based on how often the object
should report monitored parameters.

⚫ A rust sensor may report values once a month.

⚫A motion sensor may report acceleration several


hundred times per second.

⚫ Higher frequencies drive higher energy consumption


 Simple or rich data
⚫ This classification is based on the quantity of data exchanged
at each report cycle.
⚫ A humidity sensor in a field may report a simple daily index
and while an engine
⚫ sensor may report hundreds of parameters, from temperature
to pressure, gas velocity etc.
⚫ Richer data typically drives higher power consumption.
 Report range
⚫ This classification is based on the distance at which the
gateway is located.

 Object density per cell


⚫ This classification is based on the number of smart
objects over a given area, connected to the same
gateway
Figure 2.8: Example of Sensor Applications Based on Mobility and Throughput
LAYER 2: 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 sublayers:

i. Access Network Sublayer


ii. Gateways and backhaul network sublayer
iii. Network transport sublayer
iv. IoT network management sublayer
I. ACCESS NETWORK SUBLAYER

 There is a direct relationship between the IoT network


technology we 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.
 As IoT continues to grow exponentially, we will encounter a
wide variety of applications and special use cases.

 For each of them, an access technology will be required. IoT


sometimes reuses existing access technologies whose
characteristics match more or less closely the IoT use case
requirements.

 One key parameter determining the choice of access


technology is the range between the smart object and the
information collector.
 Figure 2.9 lists some access technologies we may encounter
in the IoT world and the expected transmission distances.

 Range estimates are grouped by category names that


illustrate the environment or the vertical where data
collection over that range is expected.

 Common groups are as follows:


 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
 NAN (neighbourhood 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.

 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.

 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.
Figure 2.9 : Access Technologies and Distances
 Figure 2.10 demonstrates four technologies representing
WHAN to WLAN ranges and compares the throughput
and range that can be achieved in each case.

Figure 2.10 : Range Versus Throughput for Four WHAN to WLAN Technologies
 Figure 2.11 combines cost, range, power consumption, and typical
available bandwidth for common IoT access technologies.

Figure 2.11 : Comparison Between Common Last-Mile Technologies in Terms of


Range Versus Cost, Power, and Bandwidth
Communication topologies:
 Some technologies offer flexible connectivity structure
to extend communication possibilities

1.Point-to-point topologies:
 These topologies allow one point to communicate with
another point.
 several technologies are referred to as “point-to-point”
when each object establishes an individual session
with the gateway
2. Point-to-multipoint topologies:
 Thesetopologies allow one point to
communicate with more than one other point.

 Most IoT technologies where one or more than


one gateways communicate with multiple smart
objects are in this category
 To form a network, a device needs to connect with
another device.
 When both devices fully implement the protocol
stack functions,
⚫ they can form a peer-to peer network.

 The sensor which can implement a subset of protocol functions


to perform just a specialized part (communication with the
coordinator). Such a device is called a reduced-function
device (RFD).
 An RFD cannot be a coordinator. An RFD also
cannot implement direct communications to another
RFD.

 The coordinator that implements the full network


functions is called, by contrast, a full-function
device (FFD).
 An FFD can communicate directly with another FFD or
with more than one FFD, forming multiple peer-to-peer
connections.

 Topologies where each FFD has a unique path to another


FFD are called cluster tree topologies. FFDs in the
cluster tree may have RFDs, resulting in a cluster star
topology.

 Figure 2.12 illustrates these topologies

 Other point-to-multipoint technologies allow a node to


have more than one path to another node, forming a mesh
topology.
 Figure 2.13 shows a mesh topology.

 Nodes A and D are too far apart to communicate directly.


In this case, communication can be relayed through
nodes B or C. Node B may be used as the primary relay
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.

 Ex: A dedicated short-range communication (DSRC) allows


vehicle-to-vehicle and vehicle-to-infrastructure communication.
 The gateway is in charge of this inter-medium
communication.

 In most cases, the smart objects are static or mobile within a


limited area.

 The gateway is often static. However, some IoT technologies


do not apply this model.

 When the smart object’s operation is controlled from a local site,


and when the environment is stable (for example, factory or oil
and gas field), Ethernet can be used as a backhaul.

 WiMAX (802.16) is an example of a longer-range technology.


WiMAX can achieve ranges of up to 50 kilometers with rates of
up to 70 Mbps
NETWORK TRANSPORT SUBLAYER

 We know that a hierarchical communication architecture in


which a series of smart objects report to a gateway that
conveys the reported data over another medium and up to a
central station.

 However, practical implementations are often flexible, with


multiple transversal communication paths
 communication structure involve

 peer-to-peer
 point-to-point

 point-to-multipoint (gateway or head-end)

 unicast and multicast communications (software


update to one or multiple systems)
 communication occurs over multiple media
 For ex: power lines inside our house or a short-
range wireless system like indoor Wi-Fi and/or
ZigBee
 a longer-range wireless system to the gateway, and
yet another wireless or wired medium for backhaul
transmission.

 To allow for such 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.

 IP is a protocol that matches all these requirements.

 The flexibility of IP allows this protocol to be embedded in


objects of very different natures, exchanging information
over very different media, including low-power, lossy,
and low-bandwidth networks.
 Finally, the transport layer protocols built above IP (UDP

and TCP) can easily be leveraged to decide whether the

network should control the data packet delivery (with TCP)

or whether the control task should be left to the application

(UDP).
IOT NETWORK MANAGEMENT SUBLAYER

 IP, TCP, and UDP bring connectivity to IoT


networks.

 Upper-layer protocols need to take care of data


transmission between the smart objects and other
systems.

 Multiple protocols have been created to solve IoT


data communication problems.

 Some networks depends on a push model and some


other networks depends on a pull model
 some IoT implementers have suggested HTTP
which has a client and server component.

 But HTTP is something of a fat protocol and was not


designed to operate in constrained environments
with low memory, low power, low bandwidth, and a
high rate of packet failure.
o Despite these limitations, other web-
derived protocols have been suggested for
the IoT space.

o One example is WebSocket.

o WebSocket is part of the HTML5 specification, and


provides a simple bidirectional connection over a
single connection
 WebSocket is often combined with other protocols, such
as MQTT to handle the IoT-specific part of the
communication.

 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
 To respond to the limits of web-based protocols, another
protocol was created by the IETF Constrained Restful
Environments (CoRE) working group: Constrained
Application Protocol (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.

 Another common IoT protocol utilized in these middle to upper


layers is Message Queue Telemetry Transport (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 runs over TCP. A consequence of the reliance on TCP is


that an MQTT client typically holds a connection open to the
broker at all times.
LAYER 3: APPLICATIONS AND ANALYTICS LAYER

• Once connected to a network, our smart objects exchange


information with other systems.

• As soon as our IoT network spans more than a few


sensors, the power of the Internet of Things appears in the
applications that make use of the information exchanged
with the smart objects

• From an architectural standpoint, basic classification can


be as follows:

 Analytics Versus Control Applications


 Data Versus Network Analytics
 Analytics Versus Control Applications

 Multiple applications can help increase the efficiency of an


IoT network.
 Each application collects data and provides a range of
functions based on analysing the collected data.

 Analytics Application

 Control Application
 Analytics Application

⚫ This type of application collects data from multiple smart objects,


processes the collected data, and displays information resulting
from the data that was processed.

⚫ The display can be about any aspect of the IoT network, from
historical reports, statistics, or trends to individual system
states.

 Control Application

⚫ This type of application controls the behaviour of the smart object


or the behaviour of an object related to the smart object.

⚫ For ex : a pressure sensor may be connected to a pump


 An example of control system architecture is SCADA.

 SCADA was developed as a universal method to


access remote systems and send instructions.

 Oneexample where SCADA is widely used is in the


control and monitoring of remote terminal units
(RTUs) on the electrical distribution grid.
SUPERVISORY CONTROL AND DATA ACQUISITION
(SCADA)
DATA VERSUS NETWORK ANALYTICS

 Data analytics:
 This type of analytics processes the data collected by
smart objects and combines it to provide an intelligent
view related to the IoT system.

 Network analytics:
 Most IoT systems are built around smart objects
connected to the network
 A loss or degradation in connectivity is likely to affect
the efficiency of the system. Such a loss can have
dramatic effects.

You might also like