IoT and M2M

UNIT 2
M2M (Machine to Machine)
•Machine-to-Machine (M2M) refers to
networking of machines (or devices) for the
purpose of remote monitoring and control and
data exchange.
•The architecture for M2M systems comprising
of M2M area networks, communication
network and application domain.
•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,
Bluetooth, Mod Bus, M-Bus, Wireless M-Bus, Power Line Communication (PLC), 6LoWPAN,
IEEE 802.15.4, etc.
•These communication protocols provide connectivity between M2M nodes within an M2M area
network.
•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 non-IP based communication protocols.
•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.
•The communication between the M2M nodes and the M2M gateway is based on the
communication protocols which are native to the M2M area network.
•M2M gateway performs protocol translations to enable IP-connectivity for M2M area networks.
•M2M gateway acts as a proxy performing translations from/to native protocols to/from Internet
Protocol (IP).
•With an M2M gateway, each node in an M2M area network appears as a virtualized node for
external M2M area networks.
Differences between M2M and
IoT
•Communication Protocols:
• M2M and IoT can differ in how the communication between the machines or devices happens.

• M2M uses non-Ip based communication protocols for communication within the M2M area networks.

• The focus of communication in M2M is usually on the protocols below the network layer.

• The focus of communication in IoT is usually on the protocols above the network layer such as HTTP,
CoAP, Web Sockets, MQTT, XMPP, DDS, AMQP, etc.,.
•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). The unique identifiers for the
things in IoT are the IP addresses (or MAC addresses).

• IoT systems can have heterogeneous things (e.g. a home automation IoT system can include IoT devices
of various types, such as fire alarms, door alarms, lighting control devices, etc.)

• M2M systems, in contrast to IoT, typically have homogeneous machine types within an M2M area
network.
•Hardware vs Software Emphasis:
• While the emphasis of M2M is more on hardware with embedded modules, the emphasis of IoT is more
on software.

• IoT devices run specialized software for sensor data collection, data analysis and interfacing with the
cloud through IP-based communication.

•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).
•Applications:
• M2M data is collected in point solutions and can be accessed by on-premises applications.

• IoT data is collected in the cloud and can be accessed by cloud applications.
Software Defined Networking
•Software-Defined Networking (SDN) is a networking architecture that separates the control
plane from the data plane and centralizes the network controller.

•Before SDN there was conventional network, it’s architecture is built with specialized hardware
(switches, routers, etc.).

•Network devices in conventional network architectures are getting exceedingly complex with the
increasing number of protocols being implemented.

•In the conventional network architecture the control plane and data plane are coupled.
•Control plane is the part of the network that carries the signaling and routing message traffic
while the data plane is the part of the network that carries the payload data traffic.

•The limitations of the conventional network architectures are :

• Complex Network Devices

• Management Overhead

• Limited Scalability
•Complex Network Devices:
• Conventional networks are getting increasingly complex with more and more protocols being
implemented to improve link speeds and reliability. The conventional networks were well suited for
static traffic patterns and had a large number 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.
• Management Overhead:
• Conventional networks involve significant management overhead. Network managers find it increasingly difficult to
manage multiple network devices and interfaces from multiple vendors. Upgradation of network requires configuration
changes in multiple devices (switches, routers, firewalls, etc.)

• Limited Scalability:
• The virtualization technologies used in cloud computing environments has increased the number of virtual hosts requiring
network access.

• IoT applications hosted in the cloud are distributed across multiple virtual machines that require exchange of traffic. Cloud
computing environments require highly scalable and easy to manage network architectures with minimal manual
configurations, which is becoming increasingly difficult with conventional networks.
•To overcome the limitations of conventional network architecture SDN attempts to create network
architectures that are simpler, inexpensive, scalable, agile and easy to manage.

•In SDN architecture the control and data planes are decoupled and the network controller is
centralized.

•Software-based SDN controllers maintain a unified view of the network and make configuration,
management and provisioning simpler.

•The underlying infrastructure in SDN uses simple packet forwarding hardware as opposed to
specialized hardware in conventional networks.
•Network devices become simple with SDN as
they do not require implementations of a large
number of protocols.

•Network devices receive instructions from the

SDN controller on how to forward the packets.
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.

•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 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.
Network Function Virtualization
•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 can provide the infrastructure on which SDN can run. NFV and SDN are mutually
beneficial to each other but not dependent.

•Network functions can be virtualized without SDN, similarly, SDN can run without NFV.
NFV architecture
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.

• 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.
• 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.
Difference between SDN and
NFV
• Scope
• SDN is primarily focused on the control and management of network traffic flows.

• NFV is focused on the virtualization and management of network functions.

• Functionality
• SDN separates the control plane(which determines how traffic is routed) from the data plane (which handles
the actual transmission of data), allowing for more flexible and programmable network management.

• NFV virtualizes network functions such as routing, switching, firewalling, and load balancing, allowing these
functions to be deployed and managed as software-based virtual network functions (VNFs).
•Deployment
• SDN typically requires network hardware, such as switches and routers, that support Open Flow or other
SDN protocols.

• NFV can be deployed on standard x86servers, storage, and switches.

•Management
• SDN typically relies on centralized controllers that manage network traffic flows.

• NFV also requires management, but this is typically focused on the deployment and management of
VNFs.
• Network Architecture
• SDN is typically used to create a centralized, software-defined network architecture that is more
programmable and easier to manage.

• NFV, on the other hand, is focused on virtualizing network functions to create a more flexible and scalable
network architecture.

• Standards
• SDN is primarily defined by the Open Networking Foundation(ONF) and the OpenFlow protocol.

• NFV is defined by the European Telecommunications Standards Institute(ETSI) and its NFV Industry
Specification Group (ISG).
Basics of IoT System
Management
•Need for IoT Systems Management
• IoT systems can have distributed deployments comprising of a number of IoT devices which collect data
from sensors or perform actuation. Managing multiple devices within a single system requires advanced
management capabilities.

•The need for managing IoT systems is described as follows:

• Automating Configuration: IoT system management capabilities can help in automating the system
configurations. Automation becomes important when a system consists of multiple devices or nodes. In
such cases automating the system configuration ensures that all devices have the same configuration and to
avoid variations or errors due to manual configurations.
•Monitoring Operational & Statistical Data: Operational data is the data which is related to the
system's operating parameters and is collected by the system at runtime. Statistical data is the
data which describes the system performance (e.g. CPU and memory usage). Management
systems can help in monitoring operational and statistical data of a system. This data can be used
for fault diagnosis or prognosis.

•Improved Reliability: A management system that allows validating the system configurations
before they are put into effect can help in improving the system reliability.
• System Wide Configuration:
• For IoT systems that consist of multiple devices or nodes, ensuring system-wide configuration can be critical
for the correct functioning of the system. Management approaches in which each device is configured
separately (either through a manual or automated process) can result in system faults or undesirable outcomes.
This happens when some devices are running on an old configuration while others start running on new
configuration.

• To avoid this, system wide configuration is required where all devices are configured in a single atomic
transaction. This ensures that the configuration changes are either applied to all devices or to none. In the event
of a failure in applying the configuration to one or more devices, the configuration changes are rolled back.
This ‘all or nothing’ approach ensures that the system works as expected.
•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.

•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.
• For example, for an IoT system which has multiple devices and requires same configuration for all devices,
it is important to ensure that when a new device is added, the same configuration is applied. For such cases,
the management system can retrieve the current configuration from a device and apply the same to the new
devices.
 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.

•Components involved in managing a device with SNMP:

• Network Management Station (NMS)

• Managed Device
• Management Information Base (MIB)

• SNMP Agent that runs on the device.

•NMS executes SNMP commands to monitor and configure the Managed Device.

•The Managed Device contains the MIB which has all the information of the device attributes to
be managed.

•SNMP is an application layer protocol that uses User Datagram Protocol (UDP) as the transport
protocol.
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. With the absence of writable objects, SNMP can be used only for device monitoring and
status polling.
•Retrieving the current configuration from a device can be difficult with SNMP. SNMP does not
support easy retrieval and playback of configurations.

•Earlier versions of SNMP did not have strong security features making the management
information vulnerable to network intruders.
Network Operator Requirements
•To address the limitations of the existing network management protocols, a list of operator
requirements was prepared.

•The following points provide a brief overview of the operator requirements:

• Ease of use: From the operators point of view, ease of use is the key requirement for any network
management technology.

• Distinction between configuration and state data: Configuration data is the set of writable data that is
required to transform the system from its initial state to its current state. State data is the data which is not
configurable. State data includes operational data which is collected by the system at runtime and statistical
data which describes the system performance.
• Fetch configuration and state data separately: In addition to making a clear distinction between
configuration and state data, it should be possible to fetch the configuration and state data separately from the
managed device. This is useful when the configuration and state data from different devices needs to be
compared.

• Configuration of the network as a whole: It should be possible for operators to configure the network as a
whole rather than individual devices. This is important for systems which have multiple devices and
configuring them within one network wide transaction is required to ensure the correct operation of the
system.

• Configuration transactions across devices: Configuration transactions across multiple devices should be
supported.
• Dump and restore configurations: It should be possible to dump configurations from devices and
restore configurations to devices.

• Configuration database schemas: There is a need for standardized configuration database schemas or
data models across operators.

• Role-based access control: Devices should support role-based access control model, so that a user is
given the minimum access necessary to perform a required task.

• Consistency of access control lists: It should be possible to do consistency checks of access control lists
across devices.
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 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.
•For managing a network device the client establishes a NETCONF session with the server. When
a session is established the client and server exchange messages which contain information on
their capabilities. Client can then send multiple requests to the server for retrieving or editing the
configuration data.

•NETCONF is a connection oriented protocol. For authentication, data integrity, and

confidentiality, NETCONF depends on the transport protocol, e.g., SSH or TLS. NETCONF
overcomes the limitations of SNMP and is suitable not only for monitoring state information, but
also for configuration.
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.
 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’).
 IoT Systems Management with
NETCONF-YANG
•How to manage IoT systems with NECONF and YANG

•Roles of the various components:

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

• Management API: Management API allows management applications to start NETCONF sessions, read
and write configuration data, read state data, retrieve configurations, and invoke RPCs,
programmatically, in the same way as an operator can.
• Transaction Manager: Transaction Manager executes all the NETCONF transactions and ensures that
the ACID (Atomicity, Consistency, Isolation, Durability) properties hold true for the transactions.
• Atomicity property ensures that a transaction is executed either completely or not at all.

• Consistency property ensures that a transaction brings the device configuration from one valid state to another.

• Isolation property ensures that concurrent execution of transactions results in the same device configuration as if transactions were
executed serially in order.

• Durability property ensures that a transaction once committed will persist.

• Rollback Manager : Rollback manager is responsible for generating all the transactions necessary to
rollback a current configuration to its original state.
• Data Model Manager: The Data Model manager keeps track of all the YANG data models and the
corresponding managed objects. The Data Model manager also keeps track of the applications which
provide data for each part of a data model.

• Configuration Validator: Configuration validator checks if the resulting configuration after applying a
transaction would be a valid configuration.

• Configuration Database: This database contains both the configuration and operational data.

• Configuration API: Using the configuration API the applications on the IoT device can read
configuration data from the configuration datastore and write operational data to the operational
datastore.
• 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
•IoT device management with NETCONF-YANG based on the Netopeer tools. Netopeer is set of
open source NETCONF tools 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 configuring the device using NETCONF RPC operations
and also retrieving the state data from the device.

• Netopeer-agent: Netopeer-agent is the NETCONF protocol agent running as a SSH/TLS subsystem.

Netopeer-agent accepts incoming NETCONF connection and passes the 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
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.

• Netopeer-manager: Netopeer-manager allows managing the YANG and Libnetconf Transaction API
(TransAPI) modules on the Netopeer-server. With Netopeer-manager modules can be loaded or removed
from the server.

• Netopeer-configurator: Netopeer-configurator is a tool that can be used to configure the Netopeer-

server.