IoT Unit 2

INTERNET OF THINGS – LECTURE MATERIAL
UNIT - II
INTRODUCTION TO M2M:
Machine-to-Machine (M2M) refers to networking of machines (or devices) for the purpose of
remote monitoring and control and data exchange.
 Term which is often synonymous with IoT is Machine-to-Machine (M2M).
 IoT and M2M are often used interchangeably.
Fig. Shows the end-to-end architecture of M2M systems comprises of M2M area networks,
communication networks and application fomain.
 An M2M area network comprises of machines ( or M2M nodes) which have embedded
network modules for sensing, actuation and communicating various communication
protocols can be used for M2M LAN such as ZigBee, Bluetooth, M-bus, Wireless M-Bus
etc., These protocols provide connectivity between M2M nodes within an M2M area
network.
MRITS/ECE/IV-I 27
 The communication network provides connectivity to remote M2M area networks. The
communication network provides connectivity to remote M2M area network. The
communication network can use either wired or wireless network (IP based). While the
M2M are networks use either properitorary or non-IP based communication protocols,
the communication network uses IP-based network. Since non-IP based protocols are
used within M2M area network, the M2M nodes within one network cannot
communicate with nodes in an external network.
 To enable the communication between remote M2M are network, M2M gateways are
used.
Fig. Shows a block diagram of an M2M gateway.

The communication between M2M nodes and the M2M gateway is based on the communication
protocols which are naive to the M2M are network. M2M gateway performs protocol translations
to enable Ip-connectivity for M2M are networks. M2M gateway acts as a proxy performing
translations from/to native protocols to/from Internet Protocol(IP). With an M2M gateway, each
mode in an M2M area network appears as a virtualized node for external M2M area networks.
Differences between IoT and M2M
1) Communication Protocols:
MRITS/ECE/IV-I 28
 Commonly uses M2M protocols include ZigBee, Bluetooth, ModBus, M-Bus,

WirelessM-Bus etc.,
 In IoT uses HTTP, CoAP, WebSocke
2) Machines in M2M Vs Things inIoT:

 Machines in M2M will be homogenous whereas Things in IoT will be heterogeneous.
3) Hardware Vs Software Emphasis:

 The emphasis of M2M is more on hardware with embedded modules, the emphasis of
IoT is more on software.
4) Data Collection &Analysis

 M2M data is collected in point solutions and often in on-premises storage infrastructure.
 The data in IoT is collected in the cloud (can be public, private or hybrid cloud).
5) 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.
SDN and NVF for IoT

Software Defined Networking (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
MRITS/ECE/IV-I 29
• The underlying infrastructure in SDN uses simple packet forwarding hardware as opposed to
specialized hardware in conventional networks.
SDN Architectur e
Key elements of SDN:
1) Centralized Network Controller
With decoupled control and data planes and centralized network controller, the network
administrators can rapidly configure the network.
2) Programmable Open APIs
MRITS/ECE/IV-I 30
SDN architecture supports programmable open APIs for interface between the SDN application
and control layers (Northbound interface).
3) Standard Communication Interface (Open Flow)

SDN architecture uses a standard communication interface between the control and infrastructure
layers (Southbound interface). Open Flow, which is defined by the Open Networking Foundation
(ONF) is the broadly accepted SDN protocol for the South bound interface.
Network Function Virtualization (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.
MRITS/ECE/IV-I 31
Key elements of NFV:

NFV Architecture
1) Virtualized Network Function (VNF):
VNF is a software implementation of a network function which is capable of running over the
NFV Infrastructure (NFVI).
2) NFV Infrastructure (NFVI):
NFVI includes compute, network and storage resources that are virtualized.
3) NFV Management and Orchestration:
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, and the life-cycle management of VNFs.
Need for IoT Systems Management

Managing multiple devices within a single system requires advanced management capabilities.
1) Automating Configuration: IoT system management capabilities can help in automating the
system configuration.
2) Monitoring Operational & Statistical Data: Management systems can help in monitoring
opeartional and statistical data of a system. This data can be used for fault diagnosis or
prognosis.
3) Improved Reliability: A management system that allows validating the system
configurations before they are put into effect can help in improving the system reliability.
4) System Wide Configurations: For IoT systems that consists of multiple devices or nodes,
ensuring system wide configuration can be critical for the correct functioning of the system.
5) Multiple System Configurations: For some systems it may be desirable to have multiple
valid configurations which are applied at different times or in certain conditions.
6) Retrieving & Reusing Configurations: Management systems which have the capability of
retrieving configurations from devices can help in reusing the configurations for other devices of
the same type.
MRITS/ECE/IV-I 32
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.
MRITS/ECE/IV-I 33
 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
 Distinction between configuration and state data
 Fetch configuration and state data separately
 Configuration of the network as a whole
 Configuration transactions across devices
 Configuration deltas
 Dump and restore configurations
 Configuration validation
 Configuration database schemas
 Comparing configurations
 Role-based access control
 Consistency of access control lists:
 Multiple configuration sets
 Support for both data-oriented and 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
MRITS/ECE/IV-I 34
 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 data store on the server.
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.
MRITS/ECE/IV-I 35
 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.
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 (‘toaster Manufacturer’, ‘toaster Model Number’ and ‘toaster Status’) 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

YANG is a data modeling language used to model configuration and state data manipulated by
the NETCONF protocol.
MRITS/ECE/IV-I 36
The generic approach of IoT device management with NETCONF-YANG. Roles of various
components are:
1) Management System
2) Management API
3) Transaction Manager
4) Rollback Manager
5) Data Model Manager
6) Configuration Validator
7) Configuration Database
8) Configuration API
9) Data Provider API
MRITS/ECE/IV-I 37

IoT Unit 2

Uploaded by

Copyright:

Available Formats

IoT Unit 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IoT Unit 2

Uploaded by

Copyright:

Available Formats

INTERNET OF THINGS – LECTURE MATERIAL

Fig. Shows a block diagram of an M2M gateway.

 Commonly uses M2M protocols include ZigBee, Bluetooth, ModBus, M-Bus,

2) Machines in M2M Vs Things inIoT:

3) Hardware Vs Software Emphasis:

4) Data Collection &Analysis

SDN and NVF for IoT

3) Standard Communication Interface (Open Flow)

Network Function Virtualization (NFV)

Key elements of NFV:

Need for IoT Systems Management

Simple Network Management Protocol (SNMP):

 It is difficult to differentiate between configuration and state data in MIBs.

Network Operator Requirements:

 NETCONF works on SSH transport protocol.

IoT Systems Management with NETCONF-YANG

You might also like