Lecture 1 Module 2

IoT & M2M

Thursday:: 6th Feb:: 2025

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Outlines of the Discussion

❑ M2M
❑ Diff. and Similarities between M2M and IoT
❑ SDN and NFV for IoT
❑ Need for IoT Systems Management
❑ Simple Network Management Protocol
❑ Limitations of SNMP
❑ Network Operator Requirements
❑ NETCONF and YANG
❑ IoT Systems Management with NETCONF-YANG

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Machine-to-Machine (M2M)

❑ Machine-to-Machine (M2M) refers to the

networking of machines (or devices) for remote
monitoring, control, and data exchange.
❑ M2M area network comprises of machines (or M2M
nodes) that have embedded hardware modules for
sensing, actuation, and communication.
❑ Various communication protocols are used for M2M
local area networks such as ZigBee, Bluetooth,
ModBus, M-Bus, Wireless M-Bus, Power Line
Fig: M2M communication
Communication (PLC), 6LoWPAN, IEEE 802.15.4

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Machine-to-Machine (M2M)

❑ The communication network provides

connectivity to remote M2M area networks.

❑ The communication network can be either

wired or wireless networks(IP-based).

❑ M2M area networks use either proprietary

or non-IP-based communication protocols,
Fig: M2M communication
but the communication network uses
IP-based networks.

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 M2M Gateway

❑ 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 Fig: M2M Gateway

gateways are used.

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Difference between IoT and M2M

❑ IoT and M2M seem to be the same from an external view

❑ Both IoT and M2M involve the networking of machines or devices
❑ They are different in
○ Underlying Technology

○ System Architecture

○ Application used

❑ Differences can be described using

○ Communication Protocols

○ Machines in M2M and Things in IoT

Fig: M2M vs IoT [ source: Altizon Inc. ]

○ Hardware
Prof. Panchanan Nath vs Software Emphasis
:: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 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, while IoT uses interoperable communication protocols

❑ 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 (end-user applications) or their internal physical
states.

○ M2M systems, in contrast to IoT, typically have homogeneous machine types within an M2M

Prof. Panchanan Nath

area :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
network.
 Difference between IoT and M2M

❑ Hardware vs Software Emphasis

○ M2M is more on hardware with embedded modules, and the emphasis of IoT is more on
software.
❑ Data Collection & Analysis
○ In 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).
❑ 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-premise 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.

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Communication in IoT vs M2M

Fig: Communication in IoT vs M2M

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 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
simple.

❑ SDN uses simple packet forwarding hardware as

opposed to specialized hardware in conventional Fig: Functional Blocks of IoT

networks.
Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Key elements of SDN

❑ Centralized Network Controller

○ With decoupled control and data planes and centralized network controllers, the network administrators

can rapidly configure the network.

❑ Programmable Open APIs

○ SDN architecture supports programmable open APIs for interface between the SDN application and

control layers (Northbound interface).

❑ Standard Communication Interface (OpenFlow)

○ SDN architecture uses a standard communication interface between control and infrastructure layers

(Southbound interface).

○ OpenFlow, defined by the Open Networking Foundation(ONF) is the broadly accepted SDN protocol for
Prof. Panchanan
theNath :: Assistant
Southbound interface Professor, Dept. of CSE :: NIST University :: Jan-July 25
 NFV

❑ Network Function Virtualization (NFV) is a

technology that leverages virtualization to

accommodate heterogeneous network devices
onto industry-standard infrastructure such as
high-volume servers, switches, and storage.

❑ NFV is complementary to SDN as NFV can

provide the infrastructure on which SDN can run.

Fig: High-level view of NFV

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Key elements of NFV

❑ Virtualized Network Function (VNF)

○ VNF is a software implementation of a network function that is capable of running over the NFV

Infrastructure (NFVI).

❑ NFV Infrastructure (NFVI)

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

❑ NFV Management and Orchestration:

○ Focuses on all virtualization-specific management tasks and covers the orchestration and life-cycle

management of physical and/or software resources that support the infrastructure virtualization
Prof. Panchanan
andNath :: Assistant
the life-cycle Professor,
management Dept. of CSE :: NIST University :: Jan-July 25
of VNFs.
 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 and IPTV.

Fig: Use cases of NFV

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 References

Books:

Chapter 3 : Internet of Things A Hands-On- Approach by Arshdeep Bahga and Vijay Madisetti

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Q&A

Thank You
Any Question?

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Lecture 2 Module 2

IoT & M2M

Wednesday:: 12th Feb:: 2025

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Outlines of the Discussion

❑ M2M
❑ Diff. and Similarities between M2M and IoT
❑ SDN and NFV for IoT
❑ Need for IoT Systems Management
❑ Simple Network Management Protocol
❑ Limitations of SNMP
❑ Network Operator Requirements
❑ NETCONF and YANG
❑ IoT Systems Management with NETCONF-YANG

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Need for IoT Systems Management

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

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 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
Fig: SNMP

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 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 feature
Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 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 configuration task-oriented access control

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 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

Fig: NETCONF

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 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.

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 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' state

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 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
toasterStatus’) 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’)

Fig: YANG Module Example

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 IoT Systems Management with NETCONF-YANG

❑ Management System
❑ Management API
❑ Transaction Manager
❑ Rollback Manager
❑ Data Model Manager
❑ Configuration Validator
❑ Configuration Database
❑ Configuration API
❑ Data Provider API
Fig: IoT Systems Management with NETCONF-YANG

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 References

Books:

Chapter 4 : Internet of Things A Hands-On- Approach by Arshdeep Bahga and Vijay Madisetti

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25
 Q&A

Thank You
Any Question?

Prof. Panchanan Nath :: Assistant Professor, Dept. of CSE :: NIST University :: Jan-July 25