Unit 2

IoT & M2M

-by
GVNSK Sravya
ECE Dept.
GNITS
 Outline

• M2M
• Differences and Similarities between M2M and
IoT
• SDN and NFV for IoT
• Difference between SDN and NFV for IoT
• Basics of IoT System Management with
NETCONF
• YANG-NETCONF
• YANG and SNMP NETOPEER.
3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 2
2
 Machine-to-Machine (M2M)

• Machine-to-Machine (M2M) refers to networking of machines (or

devices)
• Provides communicating and computation facilities between machines or
devices

• Purpose of remote monitoring and control and data exchange.

• Free of an human intervention
• M2M provides cross platform integration.

3/14/202 3
2 IV/IV ECE-C IoT by GVNSK Sravya
 Machine-to-Machine (M2M)

3/14/202 4
2 IV/IV ECE-C IoT by GVNSK Sravya
 Machine-to-Machine (M2M)

3/14/202 5
2 IV/IV ECE-C IoT by GVNSK Sravya
 Machine-to-Machine (M2M) Applications

3/14/202 6
2 IV/IV ECE-C IoT by GVNSK Sravya
 Machine-to-Machine (M2M) Features

3/14/202 7
2 IV/IV ECE-C IoT by GVNSK Sravya
 Machine-to-Machine (M2M)

3/14/202 8
2 IV/IV ECE-C IoT by GVNSK Sravya
 Machine-to-Machine (M2M)

3/14/202 9
2 IV/IV ECE-C IoT by GVNSK Sravya
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 0
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 1
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 2
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 3
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 4
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 5
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 6
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 7
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 8
 Machine-to-Machine (M2M)

3/14/202 1
2 IV/IV ECE-C IoT by GVNSK Sravya 9
 Machine-to-Machine (M2M)

3/14/202 2
2 IV/IV ECE-C IoT by GVNSK Sravya 0
 Machine-to-Machine (M2M)

3/14/202 2
2 IV/IV ECE-C IoT by GVNSK Sravya 1
 Machine-to-Machine (M2M)

• Machine-to-Machine (M2M) area network comprises of machines which

have embedded hardware modules for sensing, actuation and
communication
• Various communication protocols such as ZigBee, Bluetooth, ModBus,
Power line communication (PLC), 6LoWPAN etc., can be used

3/14/202 2
2 IV/IV ECE-C IoT by GVNSK Sravya 2
 Machine-to-Machine (M2M)

3/14/202 2
2 IV/IV ECE-C IoT by GVNSK Sravya 3
 Machine-to-Machine (M2M)

• An M2M area network comprises of machines (or M2M nodes)

which have embedded hardware modules for sensing,
actuation and communication.
• Various communication protocols can be used for M2M local
area networks such as ZigBee, Bluetooh, ModBus, M-Bus,
Wirless M-Bus, Power Line Communication (PLC), 6LoWPAN,
IEEE 802.15.4, etc.
3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 2
2 4
 Machine-to-Machine (M2M)

• The communication network provides connectivity to remote

M2M area networks.
• The communication network can use either wired or wireless
networks (IP- based).
• While the M2M area networks use either proprietary or non-IP
based communication protocols, the communication network
uses IP-based networks.
3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 2
2 5
 M2M Gateway

• Since non-IP based protocols are used within M2M area networks,
the M2M nodes within one network cannot communicate with
nodes in an external network.
• To enable the communication between remote M2M area
networks, M2M gateways are used.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 26

2
 M2M Gateway

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 27

2
 Difference between IoT and M2M

Communication Protocols
• M2M and IoT can differ in how the communication between the
machines or devices happens.
• M2M uses either proprietary or non-IP based communication
protocols for communication within the M2M area networks.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 28

2
 Difference between IoT and M2M

Machines in M2M vs Things in IoT

• The "Things" in IoT refers to physical objects that have unique
identifiers and can sense and communicate with their external
environment (and user applications) or their internal physical
states.
• M2M systems, in contrast to IoT, typically have homogeneous
machine types within an M2M area network.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 29

2
 Difference between IoT and M2M

Hardware vs Software Emphasis

• While the emphasis of M2M is more on hardware with
embedded modules, the emphasis of IoT is more on software.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 30

2
 Difference between IoT and M2M

Data Collection &Analysis

• M2M data is collected in point solutions and often in on-
premises storage infrastructure.
• In contrast to M2M, the data in IoT is collected in the cloud
(can be public, private or hybrid cloud).

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 31

2
 Difference between IoT and M2M

Applications
• M2M data is collected in point solutions and can be accessed
by on-premises applications such as diagnosis applications,
service management applications, and on- premisis
enterprise applications.
• IoT data is collected in the cloud and can be accessed by
cloud applications such as analytics applications, enterprise
applications, remote diagnosis and management
applications, etc.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 32

2
 Communication in IoT vs M2M

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Communication in IoT vs M2M

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 Over View of Current Network

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 1

2 4
 SDN

• Software-Defined Networking (SDN) is a networking

architecture that separates the control plane from the data
plane and centralizes the network controller.
• Software-based SDN controllers maintain a unified view of the
network and make configuration, management and
provisioning simpler.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 46

2
 SDN

• The underlying infrastructure in SDN uses simple packet

forwarding hardware as opposed to specialized hardware in
conventional networks.

IV/IV ECE-C IoT by GVNSK Sravya

3/14/202 47
2
 Conventional Network Architecture

IV/IV ECE-C IoT by GVNSK Sravya

3/14/202 48
2
 Limitations of Conventional Network
Architecture

• Complex network devices

• Management Overhead
• Limited Scalability
SDN attempts to create network architectures that are simple,
inexpensive, scalable and easy to manage

IV/IV ECE-C IoT by GVNSK Sravya

3/14/202 49
2
 SDN Architecture

3/14/202 5
2 IV/IV ECE-C IoT by 0
 SDN Layered Architecture

3/14/202 5
2 IV/IV ECE-C IoT by GVNSK Sravya 1
 Key elements of SDN

Centralized Network Controller

• With decoupled control and data planes and centralized
network controller, the network administrators can rapidly
configure the network.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 52

2
 Key elements of SDN

Programmable OpenAPIs
• SDN architecture supports programmable openAPIs for interface
between the SDN application and control layers (Northbound
interface).

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 53

2
 Key elements of SDN

Standard Communication Interface (OpenFlow)

• SDN architecture uses a standard communication interface
between the control and infrastructure layers (Southbound
interface).

• OpenFlow, which is defined by the Open Networking Foundation

(ONF) is the broadly accepted SDN protocol for the Southbound
interface.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 54

2
 Open Flow Switch

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 55

2
 Key elements of SDN

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 56

2
 NFV

• Network Function Virtualization (NFV) is a technology that

leverages virtualization to consolidate the heterogeneous network
devices onto industry standard high volume servers, switches and
storage.

• NFV is complementary to SDN as NFV can provide the

infrastructure on which SDN can run.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 2

2 1
 NFV

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 2

2 1
 Key elements of NFV

Virtualized Network Function (VNF):

• VNF is a software implementation of a network function which is
capable of running over the NFV Infrastructure (NFVI).

NFV Infrastructure (NFVI):

• NFVI includes compute, network and storage resources that are
virtualized.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 2

2 2
 Key elements of NFV

NFV Management and Orchestration:

• NFV Management and Orchestration focuses on all virtualization-
specific management tasks and covers the orchestrationand life-
cycle management of physical and/or software resources that
support the infrastructure virtualization, and the life-cycle
management of VNFs.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 2

2 2
 NFV Use Case

 NFV can be used to virtualize the Home Gateway. The NFV

infrastructure in the cloud hosts a virtualized Home Gateway.
The virtualized gateway provides private IP addresses to the
devices in the home. The virtualized gateway also connects
to network services such as VoIP andIPTV.

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 61

2
 NFV Use Case Conventional
Home Architecture
•

3/14/202 IV/IV ECE-C IoT by GVNSK Sravya 62

2
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 is a well-known and widely used
network management protocol that allows
monitoring and configuring network devices
such as routers, switches, servers, printers,
etc.
• SNMP component include
• Network Management Station (NMS)
• Managed Device
• Management Information Base (MIB)
• SNMP Agent that runs on the device
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.
Network Operator
Requirements
• Ease of use • Configuration validation
• Distinction between configuration and state • Configuration database schemas
data • Comparing configurations
• Fetch configuration and state data separately • Role-based access control
• Configuration of the network as a whole • Consistency of access control lists:
• Configuration transactions across devices • Multiple configuration sets
• Configuration deltas • Support for both data-oriented and
• Dump and restore configurations task- oriented access control
NETCONF

• Network Configuration Protocol (NETCONF) is a session-based network management

protocol. NETCONF allows retrieving state or configuration data and manipulating
configuration data on network devices
NETCONF

• NETCONF works on SSH transport protocol.

• Transport layer provides end-to-end connectivity and ensure reliable delivery of
messages.
• NETCONF uses XML-encoded Remote Procedure Calls (RPCs) for framing
request and response messages.
• The RPC layer provides mechanism for encoding of RPC calls and notifications.
• NETCONF provides various operations to retrieve and edit configuration
data from network devices.
• The Content Layer consists of configuration and state data which is XML-encoded.
• The schema of the configuration and state data is defined in a data modeling
language called YANG.
• NETCONF provides a clear separation of the configuration and state data.
• The configuration data resides within a NETCONF configuration datastore on the
server.
NETCONF
IV/IV ECE-C IoT by GVNSK 6
Sravya
IV/IV ECE-C IoT by GVNSK 6
Sravya
IV/IV ECE-C IoT by GVNSK 6
Sravya
IV/IV ECE-C IoT by GVNSK 6
Sravya
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
in to a hierarchical tree structure.
IV/IV ECE-C IoT by GVNSK 6
Sravya
YANG
• 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.

IV/IV ECE-C IoT by GVNSK 6

Sravya
YANG

IV/IV ECE-C IoT by GVNSK 6

Sravya
YANG

IV/IV ECE-C IoT by GVNSK 6

Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya
YANG

IV/IV ECE-C IoT by GVNSK 7

Sravya
YANG

IV/IV ECE-C IoT by GVNSK 7

Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya
 NETOPEER
• NETOPEER is a set of open source NETCONF tools built on
the Libnetconf library.
• It allows operators to connect to their NETCONF enabled
devices as well as developers to allow control their devices via
NETCONF.
• NETOPEER tools include
NETOPEER Server
NETOPEER Agent
NETOPEER Cli
NETOPEER Manager
NETOPEER Configurator

IV/IV ECE-C IoT by GVNSK 7

Sravya
IV/IV ECE-C IoT by GVNSK Sravya
4/6/2022
 NETOPEER
NETOPEER-Server
• It is a NETCONF protocol server that runs on the managed
device.
• It provides an environment for configuring the device using
NETCONF RPC operations and also retrieving the state data
from the device.

IV/IV ECE-C IoT by GVNSK 7

Sravya
 NETOPEER
NETOPEER-agent
• It is a NETCONF protocol agent running as a SSH/TLS
subsystem.
• It accepts incoming NETCONF connection and passes the
NETCONF RPC operations received from the NETCONF client
to the NETOPEER Server.

IV/IV ECE-C IoT by GVNSK 7

Sravya
 NETOPEER
NETOPEER-cli
• It is a NETCONF client that provides a command line interface
for interfacing with the NETOPEER- Server.
• The operator can use the NETOPEER-Cli from the
management system to send NETCONF RPC operations for
configuring the device and retrieving the state information.

IV/IV ECE-C IoT by GVNSK 7

Sravya
 NETOPEER
NETOPEER-manager
• NETOPEER manager allows managing the YANG and
Libnetconf Transaction API (Trans API) modules on the
NETOPEER-Server.
• With NETOPEER manager modules can be loaded or removed
from the server.
Netopeer Configurator
• It is a tool that can be used to configure the Netopeer-Server.

IV/IV ECE-C IoT by GVNSK 7

Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya
IV/IV ECE-C IoT by GVNSK 7
Sravya