24-07-2025

Unit I

Internet of Things Based on

Introduction to IoT

1
 24-07-2025

Definition of IoT

A dynamic global network infrastructure with self-configuring

capabilities based on standard and interoperable communication
protocols where physical and virtual "things" have identities, physical
attributes, and virtual personalities and use intelligent interfaces, and
are seamlessly integrated into the information network, often
communicate data associated with users and their environments.

Characteristics of IoT

• Dynamic & Self-Adapting

• Self-Configuring
• Interoperable Communication Protocols
• Unique Identity
• Integrated into Information Network

2
 24-07-2025

Applications of IoT

Physical Design of IoT

• The "Things" in IoT usually refers to IoT devices which have unique
identities and can perform remote sensing, actuating and monitoring
capabilities.
• IoT devices can:
• Exchange data with other connected devices and applications (directly or
indirectly), or
• Collect data from other devices and process the data locally or
• Send the data to centralized servers or cloud-based application back-ends for
processing the data, or
• Perform some tasks locally and other tasks within the IoT infrastructure,
based on temporal and space constraints

3
 24-07-2025

Physical Design of an IoT Device

• An IoT device may consist of

several interfaces for connections
to other devices, both wired and
wireless.
• I/O interfaces for sensors
• Interfaces for Internet
connectivity
• Memory and storage interfaces
• Audio/video interfaces.

Logical Design of IoT

• Logical design of an IoT system refers to an abstract representation of the entities

and processes without going into the low-level specifics of the implementation.

•Comprises of
IoT Functional Blocks
IoT Communication Models
IoT Communication APIs

4
 24-07-2025

Logical Design of IoT – IoT Functional Blocks

• Provides the system the capabilities for

identification, sensing, actuation,
communication, and management.

Logical Design of IoT – IoT Communication Model

i. Request-Response
ii. Publish-Subscribe
iii. Push-Pull
iv. Exclusive Pair

5
 24-07-2025

i. Request-Response communication model

• Request-Response is a
communication model in which
the client sends requests to the
server and the server responds
to the requests.

• When the server receives a

request, it decides how to
respond, fetches the data,
retrieves resource
representations, prepares the
response, and then sends the
response to the client.

ii. Publish-Subscribe communication model

• Publish-Subscribe is a
communication model that
involves publishers, brokers and
consumers.
• Publishers are the source of data.
Publishers send the data to the
topics which are managed by the
broker. Publishers are not aware
of the consumers.
• Consumers subscribe to the topics
which are managed by the broker.
• When the broker receives data for
a topic from the publisher, it
sends the data to all the
subscribed consumers.

6
 24-07-2025

iii. Push-Pull communication model

• Push-Pull is a communication
model in which the data
producers push the data to
queues and the consumers pull
the data from the queues.
Producers do not need to be
aware of the consumers.
• Queues help in decoupling the
messaging between the producers
and consumers.
• Queues also act as a buffer which
helps in situations when there is a
mismatch between the rate at
which the producers push data
and the rate rate at which the
consumers pull data.

iv. Exclusive Pair communication model

• Exclusive Pair is a
bidirectional, fully duplex
communication model that
uses a persistent connection
between the client and
server.
• Once the connection is setup
it remains open until the
client sends a request to
close the connection.
• Client and server can send
messages to each other after
connection setup.

7
 24-07-2025

Logical Design of IoT – IoT Communication APIs

i. REST based communication APIs (Request Response Based Model)

ii. WebSocket based Communication APIs (Exclusive Pair Based Model)

i. REST-based Communication APIs

• Representational State Transfer

(REST) is a set of architectural
principles by which you can design
web services and web APIs that
focus on a system’s resources and
how resource states are
addressed and transferred.
• REST APIs follow the request-
response communication model.
• The REST architectural constraints
apply to the components,
connectors, and data elements,
within a distributed hypermedia
system.

8
 24-07-2025

ii. WebSocket-based Communication APIs

• WebSocket APIs allow bi-

directional, full duplex
communication between
clients and servers.
• WebSocket APIs follow the
exclusive pair
communication model

IoT Levels & Deployment Templates

An IoT system comprises of the following components:

• Device: An IoT device allows identification, remote sensing, actuating and
remote monitoring capabilities.

• Resource: Resources are software components on the IoT device for

accessing, processing, and storing sensor information, or controlling
actuators connected to the device. Resources also include the software
components that enable network access for the device.

• Controller Service: Controller service is a native service that runs on the

device and interacts with the web services. Controller service sends data
from the device to the web service and receives commands from the
application (via web services) for controlling the device.

9
 24-07-2025

IoT Levels & Deployment Templates

• Database: Database can be either local or in the cloud and stores the data generated by
the IoT device.

• Web Service: Web services serve as a link between the IoT device, application,
database and analysis components. Web service can be either implemented using HTTP
and REST principles (REST service) or using WebSocket protocol (WebSocket service).

• Analysis Component: The Analysis Component is responsible for analyzing the IoT data
and generate results in a form which are easy for the user to understand.

• Application: IoT applications provide an interface that the users can use to control and
monitor various aspects of the IoT system. Applications also allow users to view the
system status and view the processed data.

IoT Level-1

• A level-1 IoT system has a single

node/device that performs sensing
and/or actuation, stores data,
performs analysis and hosts the
application

• Level-1 IoT systems are suitable for

modeling low- cost and low-
complexity solutions where the data
involved is not big and the analysis
requirements are not
computationally intensive.

10
 24-07-2025

IoT Level-2

• A level-2 IoT system has a

single node that performs
sensing and/or actuation and
local analysis.
• Data is stored in the cloud and
application is usually cloud-
based.
• Level-2 IoT systems are
suitable for solutions where
the data involved is big,
however, the primary analysis
requirement is not
computationally intensive and
can be done locally itself.

IoT Level-3

• A level-3 IoT system has a

single node. Data is stored
and analyzed in the cloud
and application is cloud-
based.
• Level-3 IoT systems are
suitable for solutions where
the data involved is big and
the analysis
requirements are
computationally intensive.

11
 24-07-2025

IoT Level-4

• A level-4 IoT system has multiple

nodes that perform local analysis.
Data is stored in the cloud and
application is cloud-based.
• Level-4 contains local and cloud-
based observer nodes which can
subscribe to and receive
information collected in the cloud
from IoT devices.
• Level-4 IoT systems are suitable
for solutions where multiple
nodes are required, the data
involved is big and the analysis
requirements are computationally
intensive.

IoT Level-5

• A level-5 IoT system has multiple end

nodes and one coordinator node.
• The end nodes that perform sensing
and/or actuation.
• Coordinator node collects data from
the end nodes and sends to the cloud.
• Data is stored and analyzed in the
cloud and application is cloud-based.
• Level-5 IoT systems are suitable for
solutions based on wireless sensor
networks, in which the data involved
is big and the analysis requirements
are computationally intensive.

12
 24-07-2025

IoT Level-6

• A level-6 IoT system has multiple

independent end nodes that
perform sensing and/or actuation
and send data to the cloud.
• Data is stored in the cloud and
application is cloud-based.
• The analytics component analyzes
the data and stores the results in
the cloud database.
• The results are visualized with the
cloud-based application.
• The centralized controller is aware
of the status of all the end nodes
and sends control commands to
the nodes.

IoT System Management with

NETCONF-YANG

13
 24-07-2025

Need for IoT Systems Management

• Automating Configuration
• Monitoring Operational & Statistical Data
• Improved Reliability
• System Wide Configurations
• Multiple System Configurations
• Retrieving & Reusing Configurations

Simple Network Management Protocol (SNMP)

SNMP Manager: It is a centralized system used to monitor the network. It is
also known as a Network Management Station (NMS). A router that runs the
SNMP server program is called an agent, while a host that runs the SNMP
client program is called a manager.

SNMP agent: It is a software management software module installed on a

managed device. The manager accesses the values stored in the database,
whereas the agent maintains the information in the database. To ascertain if
the router is congested or not, for instance, a manager can examine the
relevant variables that a router stores, such as the quantity of packets
received and transmitted.

Management Information Base: MIB consists of information on resources

that are to be managed. This information is organized hierarchically. It
consists of objects instances which are essentially variables. A MIB, or
collection of all the objects under management by the manager, is unique to
each agent. System, interface, address translation, IP, UDP, and EGP, ICMP,
TCP are the eight categories that make up MIB. The MIB object is home to
these groups.

14
 24-07-2025

SNMP Messages

• GetRequest : It is simply used to retrieve data from SNMP agents. In response to this, the SNMP agent responds with the
requested value through a response message.

• GetNextRequest : To get the value of a variable, the manager sends the agent the GetNextRequest message. The values of the
entries in a table are retrieved using this kind of communication. The manager won't be able to access the values if it doesn't
know the entries' indices. The GetNextRequest message is used to define an object in certain circumstances.

• SetRequest : It is used by the SNMP manager to set the value of an object instance on the SNMP agent.

• Response : When sent in response to the Set message, it will contain the newly set value as confirmation that the value has been
set.

• Trap : These are the message sent by the agent without being requested by the manager. It is sent when a fault has occurred.

• InformRequest : It was added to SNMPv2c and is used to determine if the manager has received the trap message or not. It is
the same as a trap but adds an acknowledgement that the trap doesn't provide.

SNMP Security Levels

• noAuthNoPriv:
• This (no authentication, no privacy) security level uses a community string for authentication and no
encryption for privacy.

• authNopriv:
• This security level ( authentication , no privacy) uses HMAC with Md5 for authentication and no
encryption is used for privacy.

• authPriv:
• This security level (authentication, privacy) uses HMAC with MD5 or SHA for authentication and
encryption uses the DES-56 algorithm.

15
 24-07-2025

Limitations of SNMP

• SNMP is stateless in nature and each SNMP request contains all the
information to process the request. The application needs to be intelligent
to manage the device.
• SNMP is a connectionless protocol which uses UDP as the transport protocol,
making it unreliable as there was no support for acknowledgement of
requests.
• MIBs often lack writable objects without which device configuration is not
possible using SNMP.
• It is difficult to differentiate between configuration and state data in MIBs.
• Retrieving the current configuration from a device can be difficult with
SNMP.
• Earlier versions of SNMP did not have strong security features.
• SNMP does not support the transaction mechanism, resulting in a low
configuration efficiency.

NETCONF
• Network Configuration Protocol (NETCONF) is a session-based The Network Configuration Protocol
(NETCONF) is a network management protocol allowing a network management system (NMS) to
deliver, modify, and delete configurations of network devices. Standard application programming
interfaces (APIs) are available on network devices for the NMS to manage the devices using NETCONF.

• NETCONF uses Extensible Markup Language (XML)-based data encoding for the configuration data
and protocol messages, and uses a simple remote procedure call (RPC) mechanism to implement
communication between a client and a server. A client can be a script or an application running on an
NMS. A server is typically a network device.

• Network automation is one of the key requirements for networks in the cloud era, including fast and
on-demand service provisioning and automatic Operations and Maintenance. However, this
requirement cannot be met by the conventional network management methods: command-line
interface (CLI) and Simple Network Management Protocol (SNMP). This is where NETCONF comes in,
which is gaining momentum in network automation.

16
 24-07-2025

NETCONF Architecture
The NETCONF architecture consists of two roles: client and server.

•A client provides the following functions:

• Manages network devices using NETCONF.
• Sends RPC requests to a NETCONF server to query or modify one or
more parameter values.
• Learns the status of a managed device based on the alarms and
events sent by the NETCONF server of the managed device.

•A server maintains information about managed devices and responds to

the client-initiated requests.
• When receiving a request from a NETCONF client, the NETCONF
server parses the request and sends a reply to the client.
• If a fault or another type of event occurs on a managed device, the
NETCONF server reports an alarm or event to the client through
the notification mechanism. This allows the client to learn the
status of the managed device.

NETCONF – Establishing a Session

The NETCONF client and server use the RPC mechanism to communicate with each other. The communication is
allowed only after a secure and connection-oriented session is established between them. The client sends an RPC
request to the server, and the server returns a reply to the client after processing the request.

17
 24-07-2025

NETCONF Protocol Framework

• NETCONF uses a hierarchical

structure.

• Each layer encapsulates certain

functions and provides services
for its upper layer.

• This hierarchical structure

enables each layer to focus only
on a single aspect of NETCONF
and reduces the dependencies
between different layers.

• In this way, the internal

implementation changes of one
layer have minimized impact on
other layers.

YANG

• YANG is a data modeling language used to model configuration and state data
manipulated by the NETCONF protocol
• YANG modules contain the definitions of the configuration data, state data, RPC calls that
can be issued and the format of the notifications.
• YANG modules defines the data exchanged between the NETCONF client and server.
• A module comprises of a number of 'leaf' nodes which are organized into a hierarchical
tree structure.
• The 'leaf' nodes are specified using the 'leaf' or 'leaf-list' constructs.
• Leaf nodes are organized using 'container' or 'list' constructs.
• A YANG module can import definitions from other modules.
• Constraints can be defined on the data nodes, e.g. allowed values.
• YANG can model both configuration data and state data using the 'config' statement.

18
 24-07-2025

YANG Module Example

• This YANG module is a YANG version of the toaster

MIB
• The toaster YANG module begins with the header
information followed by identity declarations which
define various bread types.
• The leaf nodes (‘toasterManufacturer’,
‘toasterModelNumber’ and oasterStatus’) are
defined in the ‘toaster’ container.
• Each leaf node definition has a type and optionally a
description and default value.
• The module has two RPC definitions (‘make-toast’
and ‘cancel-toast’).

IoT Systems Management with NETCONF-YANG

1) Create a YANG model of the system that defines the

configuration and state data of the system.
2) Complete the YANG model with the ‗Inctool‘ which comes
withLibnetconf.
3) Fill in the IoT device mangement code in the TransAPImodule.
4) Build the callbacks C file to generate the libraryfile.
5) Load the YANG module and the TransAPImodule into the
Netopeer server using Netopeer managertool.
6) The operator can now connect from the management system
to the Netopeer server using the NetopeerCLI.
7) Operator can issue NETCONF commands from the Netopeer
CLI. Command can be issued to change the configuration data,
get operational data or execute an RPC on the IoT device.

19
 24-07-2025

IoT Design Methdology

IoT Design Methodology

20
 24-07-2025

Step 1: Purpose & Requirements Specification

• The first step in IoT system design methodology is to define the

purpose and requirements of the system.

• In this step, the system purpose, behavior and requirements (such

as data collection requirements, data analysis requirements,
system management requirements, data privacy and security
requirements, user interface requirements, ...) are captured.

Step 2: Process Specification

• The second step in the IoT design methodology is to define the

process specification.

• In this step, the use cases of the IoT system are formally
described based on and derived from the purpose and
requirement specifications.

21
 24-07-2025

Step 3: Domain Model Specification

• The third step in the IoT design methodology is to define the Domain
Model.
• The domain model describes the main concepts, entities and objects
in the domain of IoT system to be designed.
• Domain model defines the attributes of the objects and relationships
between objects. Domain model provides an abstract representation
of the concepts, objects and entities in the IoT domain, independent of
any specific technology or platform.
• With the domain model, the IoT system designers can get an
understanding of the IoT domain for which the system is to be
designed.

Step 4: Information Model Specification

• The fourth step in the IoT design methodology is to define the Information Model.
• Information Model defines the structure of all the information in the IoT system, for
example, attributes of Virtual Entities, relations, etc.
• Information model does not describe the specifics of how the information is represented
or stored.
• To define the information model, we first list the Virtual Entities defined in the Domain
Model.
• Information model adds more details to the Virtual Entities by defining their attributes
and relations.

22
 24-07-2025

Step 5: Service Specifications

• The fifth step in the IoT design methodology is to define the service specifications.
• Service specifications define the services in the IoT system, service types, service
inputs/output, service endpoints, service schedules, service preconditions and service
effects.

Step 6: IoT Level Specification

• The sixth step in the IoT design methodology is to define the IoT level for the
system.

Step 7: Functional View Specification

• The seventh step in the IoT design methodology is to define the Functional
View.
• The Functional View (FV) defines the functions of the IoT systems grouped into
various Functional Groups (FGs).
• Each Functional Group either provides functionalities for interacting with
instances of concepts defined in the Domain Model or provides information
related to these concepts.

Step 8: Operational View Specification

• The eighth step in the IoT design methodology is to define the Operational
View Specifications.
• In this step, various options pertaining to the IoT system deployment and
operation are defined, such as, service hosting options, storage options,
device options, application hosting options, etc

23
 24-07-2025

Step 9: Device & Component Integration

• The ninth step in the IoT design methodology is the integration of the
devices and components.

Step 10: Application Development

• The final step in the IoT design methodology is to develop the IoT application.

IoT Sensors and Actuators

24
 24-07-2025

Sensor

A sensor is effectively a measurement device and as such should satisfy design criteria
that are placed on measurement devices:

• The sensor should be sensitive to the property they are measuring. For example, a
temperature sensor should change its measurement value as the temperature
changes.

• The sensor should be insensitive to other properties encountered in its application

domain. For example, a water pollution sensor should not depend on water pressure.

• The sensor should have no influence on the property they are measuring. For
example, a temperature sensor that heats up would impact the temperature readings
(due to thermal radiation) and hence it would not be useful as a measurement device.

Static Characteristics of a Sensor (1/2)

how the output of a sensor changes in response to an input change after steady state condition.

25
 24-07-2025

Static Characteristics of a Sensor (2/2)

Classification of Sensors

26
 24-07-2025

Different Sensors

Source: https://www.geeksforgeeks.org/electronics-engineering/types-of-sensors/

Different Sensors

27
 24-07-2025

Different Sensors

Actuators
An actuator is a machine component or system that moves or controls the mechanism of the
system.

Sensors in the device sense the environment, then control signals are generated for the
actuators according to the actions needed to perform.

The control system acts upon an environment through the actuator. It requires a source of
energy and a control signal. When it receives a control signal, it converts the source of energy to
a mechanical operation.

28
 24-07-2025

Types of Actuators (1/3)

Types of Actuators (2/3)

29
 24-07-2025

Types of Actuators (3/3)

30