UNIT-II

IoT and M2M

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

M2M system architecture

• 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.
• 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
proprietary 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

1
 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:
Commonly uses M2M protocols include ZigBee, Bluetooth, ModBus,
M-Bus, WirelessM-Bustec.,
In IoT uses HTTP, CoAP, WebSocket, MQTT,XMPP,DDS,AMQPetc.,
2) Machines in M2M Vs Things in IoT:
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.

2
 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
• The underlying infrastructure in SDN uses simple packet forwarding
hardware as opposed to specialized hardware in conventional networks.

3
 Coventional network architecture

The limitations of conventional network architecture are:

1) Complex network devices: The conventional networks were well suited for
static traffic patterns and had a large no.of protocols designed for specific
applications. For IoT applications which are deployed in cloud computing
environments, the traffic patterns are more dynamic. Due to the complexity of
conventional network devices,making changes in the networks to meet the
dynamic traffic patterns has become increasingly difficult.
2) Management Overhead: Conventional networks involve significant
management overhead. Network managers find it increasingly difficult to manage
multiple network devices and interfaces from multiple vendors.
3) Limited Scalability: The computing environments require highly scalable and
easy to manage network architectures with minimal manual configurations,
which is becoming increasingly difficult with conventional networks.

4
 SDN LAYERS
SDN Architecture

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 OpenAPIs

SDN architecture supports programmable open APIs for interface

between the SDN application and control layers (Northbound
interface).

3) 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

5
 OpenFlow switch
protocol for the South bound Interface.

OpenFlow Table
OpenFlow protocol is implemented on both sides of the interface between the
controller and network devices. The controller manages the switch via
OpenFlow switch protocol.The controller can add,update, delete flow entries
in flow table.

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.

6
 NFV architecture

Key elements of NFV:

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

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

SNMP
SNMP is a well-known and widely used network management protocol that
allows monitoring and configuring network devices such as routers, switches,
servers, etc. SNMP includes Network Management Station(NMS),Managed
devices, Management Information Base(MIB) and SNMP agent that runs on
device.NMS executes SNMP commands to monitor and configure the Managed
Device. SNMP is an application layer protocol that used User Datagram
Protocol(UDP) as the transport protocol.

8
Limitations of SNMP
1. SNMP is a connectionless protocol which uses UDP as the transport
protocol, making it unreliable.
2. It is difficult to differentiate between state and configuration data in
MIBs.
3. Retrieving current configuration from a device can be difficult with
SNMP.
4. Earlier versions of SNMP did not have strong security features making
management information vulnerable to network intruders. Though
security features were added in the later versions of SNMP, it increased
the complexity a lot.

NETCONF

NETCONF protocol layers

Network Configuration Protocol (NETCONF) is a session based network
management protocol.
NETCONF works on SSH transport protocol. Transport layer provides end-
to-end connectivity and ensure reliable delivery of messages. NETCONF

9
uses XML-encoded RPC for framing request and response messages.
NETCONF provides various operations to retrieve and edit configuration
data from network devices.
Operations:
Connect: Connect to NETCONF server
Get-config: Retrieve all or portion of configuration datastore
Edit-config: Edits the configuration data
Lock:Lock a configuration datastore for exclusive edits by clientrs
Unlock: Release a lock on configuration datastore
Close-session: Gracefully terminate a NETCONF session
Kill-session: Forcefully terminate a NETCONF session.
The content layer consists of configuration and state data which is XML-
encoded. The schema of configuration and state data is defined by data
modeling language called YANG.
The configuration data resides within a NETCONF configuration datastore
on server. For managing a network device the client establishes a
NETCONF session over server.
NETCONF defines one or more datastores.
NETCONF is connection oriented protocol and NETCONF connections
between protocol operations. Authentication, data integrity and
confidentiality can be achieved by NETCONF.NETCONF overcomes the
limitations of SNMP.

YANG
YANG is a data modeling language used to model configuration and stste
data manipulated by NETCONF protocol. YANG contains the definitions of
configuration data,state data,RPC calls. YANG modules defines the data
exchanged between ETCONF client and server.
The YANG module consists of hierarchical tree structure.
NODES:
Leaf nodes: Consists simple data structures. Leaf has exactly one value of
particular type.
Leaf-List Nodes: It is a sequence of leaf nodes.
Container nodes: Used to group related nodes in a subtree. A container has
only one child and no values.
List nodes: Defines a sequence of ist entries.
Example:

10
IoT Systems Management with NETCONF-YANG
YANG is a data modeling language used to model configuration and state
data manipulated by the NETCONF protocol.
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

11
1) Management System: The operator uses a management system to send
NETCONF messages to configure the IoT device and receives state
information and notifications from the device as NETCONF messages.
2) Management API: allows management application to start NETCONF
sessions.
3) Transaction Manager: executes all the NETCONF transactions and
ensures that ACID properties hold true for the trasactions.
4) Rollback Manager: is responsible for generating all the transactions
necessary to rollback a current configuration to its original state.
5) Data Model Manager: Keeps track of all the YANG data models and the
corresponding managed objects. Also keeps track of the applications which
provide data for each part of a data model.
6) Configuration Validator: checks if the resulting configuration after
applying a transaction would be a valid configuration.
7) Configuration Database: contains both configuration and operational data.

12
8) Configuration API : Using the configuration API the application on the IoT
device can be read configuration data from the configuration datastore and
write opeartional data to the opearational datastore.
9) Data Provider API: Applications on the IoT device can register for
callbacks for various events using the Data Provider API. Through the Data
Provider API, the applications can report statistics and operational data.

NETOPEER
NETOPEER is a NETCONF tool built on the Libnetconf library.

Netopeer-server: Netopeer-server is a NETCONF protocol server that runs on

the managed device. Netopeer-server provides an environment for configurating
the device using NETCONF RPC operations and also retriving the state data
from device.
Netopeer-agent: Netopeer-agent is the NETCONF protocol agent running as
SSH/TLS subsystem. Netopeer-agent accepts incoming NETCONF connection
and passes NETCONF RPC operations received from the NETCONF client to
the Netopeer-server.
Netopeer-cli: Netopeer-cli is a NETCONF client that provides a command line
interface for interacting eith Netopeer-server
Netopeer-manager: Netopeer-manager allows managing YANG and

13
 Libnetconf Transaction API(TransAPI) modules on Netopeer-server.
Netopeer-configurator: Netopeer-configurator is a tool that can be used to
configure the Netopeer-server.

Steps for IoT device 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 with
Libnetconf.
3) Fill in the IoT device management code in the TransAPI module.
4) Build the callbacks C file to generate the library file.
5) Load the YANG module and the TransAPI module into the Netopeer server
using Netopeer manager tool.
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.

14