Module -2

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.
➢ IoT and M2M provides access to information without human intervention.
➢ M2M: M2M provides direct communication between individual machines or
devices . it is designed to communicate between devices(machines) for a
specific purposes.
➢ IoT : IoT is a broader concept for internet communication between devices. It
involves a wide range of devices, sensors, actuators and applications that
communicate with the internet.
❖ 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, ModBus, M-Bus, Wireless M-Bus, Power Line Communication (PLC),
6LoWPAN, IEEE 802.15.4, etc.

❖ The communication network provides connectivity to remote M2M area networks.

❖ While the M2M area networks use either proprietary or non-IP based communication
protocols, the communication network uses IP-based networks.

❖ To enable the communication between remote M2M are network, M2M gateways are used.
 End-to-end architecture of M2M systems comprises of M2M area networks, communication networks
and application domain.
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, Wireless M-Bus etc.

In IoT uses HTTP, CoAP, WebSocket etc

2) Machines in M2M Vs Things in IoT: Machines in M2M will be homogeneous

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).
 Applications of M2M (Machine-to-Machine)
M2M refers to direct communication between devices without much human intervention.
1. Smart Meters (Utilities)
* Electricity, water, and gas meters automatically send usage data to providers.
* Enables real-time billing and monitoring.
2. Industrial Automation
* Machines on a factory floor communicate directly for predictive maintenance and process
optimization.
* Example: A machine sends an alert before it fails.
3. Fleet Management
* Trucks send location, fuel consumption, and maintenance data to control centers.
* Helps optimize routes and reduce downtime.
4. Remote Healthcare Monitoring
* Medical devices (like pacemakers, glucose monitors)
send real-time data to doctors.
* Enables early detection of health issues.

5. ATM & Vending Machines

* ATMs send cash status or errors directly to the bank.
* Vending machines report stock levels and maintenance
issues.
Real-time Applications of IoT (Internet of Things)
IoT connects devices to the internet so they can be monitored/controlled remotely.

1. Smart Homes
* Devices like smart lights, thermostats, CCTV, and appliances are connected to
smartphones.
* Example: Adjusting AC temperature remotely.

2. Smart Agriculture
* IoT sensors monitor soil moisture, weather, and crop health in real time.
* Automated irrigation when soil is dry.
3. Connected Cars

* Cars send data on fuel, speed, traffic, and engine performance.

* Used in **self-driving cars** and accident alerts.

4. Smart Cities

* IoT-enabled streetlights, traffic management systems, waste bins, and parking

sensors.

* Example: Real-time traffic control to reduce congestion.

5. Healthcare (IoMT – Internet of Medical Things)

* Wearables like smart watches track heart rate, oxygen level, sleep.

* Data sent to doctors/hospitals in real-time.

Communication in IoT vs M2M
 Conventional Network Architecture

❖ Conventional network architecture built with specialized hardware (switches, routers,

etc.).
❖ Network devices in conventional network architectures are getting exceedingly complex
with the increasing number of distributed protocols being implemented and the use of
proprietary hardware and interfaces.
❖ 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
1. Complex Network Devices: Conventional networks are getting increasingly
complex with more and more protocols being implemented to improve link speeds
and reliability.

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. Upgradation of network
requires configuration changes in multiple devices (switches, routers, firewalls, etc.)

3. Limited Scalability: The analytics components of loT applications run distributed

algorithms on a large number of virtual machines that require huge amounts of data
exchange between virtual machines. Such computing environments require highly
scalable and easy to manage network architectures with minimal manual
configurations, which is becoming increasingly difficult with conventional
networks.
 SDN and NFV 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 SDN uses simple packet forwarding hardware as opposed to specialized

hardware in conventional networks.
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: 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.
 OpenFlow Switch

1. Controller: This represents the centralized control plane of the SDN architecture. It's
responsible for managing and programming the network devices, including OpenFlow
switches, by defining forwarding rules and policies.
2. OpenFlow Protocol: This is the standardized communication protocol used to exchange
messages between the OpenFlow Controller and the OpenFlow Switch, enabling the
controller to remotely manage the switch's forwarding behavior.
3. OpenFlow Channel: This is the secure communication interface that connects the
OpenFlow Switch to the OpenFlow Controller, facilitating the exchange of control messages
and network events.
OpenFlow Switch: The data plane element that receives and forwards network traffic based on instructions
from the controller. It comprises several key components, as shown.

1. Flow Table(s): These tables contain flow entries that define how specific packets (flows) should be
processed. Each entry consists of match fields (to identify packets), actions (to be performed on
matched packets), and counters (for statistics). Packets are matched against entries in these tables
to determine forwarding decisions.
2. Group Table: This table allows for applying a common set of actions to multiple flows or for
implementing advanced forwarding behaviors like multicast, broadcast, or load balancing. Flow
entries can point to group entries for more complex actions.
3. Pipeline: This refers to the sequential processing of packets through multiple flow tables within
the switch. Packets may be matched in one table and then directed to subsequent tables for further
processing based on the defined instructions
 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.
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 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 operational 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. In
a smart office,

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.
1. Automating Configuration
Example: In a smart home, when a new Wi-Fi enabled bulb is added, the IoT management
system automatically configures it with the same network settings as the existing devices
—no need for manual setup.

2. Monitoring Operational & Statistical Data

Example: In a smart agriculture system, sensors continuously monitor soil moisture and
temperature data. If soil moisture drops below a threshold, the system can alert the
farmer or trigger irrigation.

3. Improved Reliability
Example: In a connected car system, software updates are validated in a test mode
before being installed, ensuring the car’s safety functions are not disrupted by faulty
updates.

4. System Wide Configurations

Example: In a smart office, all air conditioning units can be set to energy-saving mode at
7 PM using a single configuration command instead of adjusting each unit separately.

5. Multiple System Configurations

Example: In a factory, machines have a "day configuration" for full production and a
"night configuration" for low-power standby. The system automatically switches based on
time of day.

6. Retrieving & Reusing Configurations

Simple Network Management Protocol (SNMP)

Simple Network Management Protocol (SNMP) is an widely used

network management protocol that allows monitoring and configuring
network devices such as routers, switches, servers, printers, etc.

SNMP is an application layer protocol that uses UDP port number

161/162. SNMP is used to monitor the network, detect network
faults, and sometimes even to configure remote devices.
SNMP component include

1. Network Management Station (NMS)

2. Managed Device
3. SNMP Agent that runs on the device
4. Management Information Base (MIB)
SNMP Manager: It is a centralized system used to monitor the network. It is also known as a
Network Management Station (NMS). A network device (router, switch, firewall) that runs the
SNMP server program is called an agent, while a computer/device that runs the SNMP client
program is called a manager.

SNMP agent: It is a software management software module installed on a managed device.

The manager accesses the values stored in the database, whereas the agent maintains the
information in the database. For instance, a manager can examine the relevant variables that a
router stores, such as the quantity of packets received and transmitted.

Management Information Base:It stores information about a device’s, configuration and

status. Each item in the MIB is identified by an Object Identifier (OID),MIB can store system
name, uptime, CPU usage, or interface status.
Here’s a short and clear version 👇

* **Management Information Base (MIB)** is a **hierarchical database** used in

SNMP.
* It stores information about a device’s **configuration and status**.
* Each item in the MIB is identified by an **Object Identifier (OID)**.
* **SNMP agents** maintain the MIB, and **SNMP managers** query or modify
it.
* Example: MIB can store system name, uptime, CPU usage, or interface status.

Do you want me to also give you a **2–3 line exam-style definition**?

Limitations of SNMP:
[Link] 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.
2. SNMP is a connectionless protocol which uses UDP as the transport
protocol, making it unreliable as there was no support for acknowledgement
of requests.
3. MIBs often lack writable objects without which device configuration is not
possible using SNMP
[Link] is difficult to differentiate between configuration and state data in MIBs.

5. Retrieving the current configuration from a device can be difficult with

SNMP.
NETCONF

1. NETCONF is a network management protocol that uses a simple remote

procedure call (RPC) mechanism to interact with network devices.
2. It is designed to work with the Simple Network Management Protocol (SNMP)
and uses an Extensible Markup Language (XML) data encoding format.
3. It allows network administrators to configure, monitor, and troubleshoot
network devices remotely, making it a valuable tool for managing large and
complex networks.
● It is used to connect with the device securely to do the
configurations and fetch the operational data.
● It does not define the data format; this responsibility was taken
up by YANG (Yet Another Next Generation) data modelling
language, which was described by IETF.
● 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.
● NETCONF provides a clear separation of the configuration and state data.
● Configuration = The settings or instructions that define how a network device (like
a router, switch, or firewall) should operate.
● state/operational data=it is the actual current status (like interface UP/DOWN,
CPU usage, etc.).
Eg: Config data*= hostname, IP addresses, routing protocol settings.
State dat= eth0 is UP, CPU = 30%, OSPF neighbor count = 5.
YANG:

● YANG (Yet Another Next Generation) is a data modeling language used to model configuration
and state data manipulated by the NETCONF protocol.
● It is mainly used with NETCONF and RESTCONF protocols for network/device configuration
and management.
● Think of YANG as a blueprint or schema that tells devices:
1. what parameters exist,
2. their data type (string, int, boolean, etc.),
3. whether they can be read-only or configurable,
4. and how they are organized hierarchically.
● 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.
● YANG can model both configuration data and state data using the 'config' statement.
Simple Example (YANG in IoT)

Imagine a Smart Home IoT device: a Smart Light [Link] want to model its configuration and state using YANG.

id → Every bulb has a unique ID

(string).

status → Can be on or off. It’s marked

as

config false, meaning it’s state data

(device reports it, you don’t set it).

brightness → User can configure

between 0 and 100.

color → User can set the bulb’s color

(default = white).
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’).
YANG Node Types
Node Type Description

Leaf node Represents a single data value of a specific type, such as an integer, string,
or boolean. It does not contain any child nodes.

Leaf-list node Represents a sequence of leaf nodes of the same type. It is used when
multiple instances of a simple value are needed

Container node Groups related nodes into a subtree. It contains only child nodes (which can
be other containers, lists, leaves, or leaf-lists) and does not hold a value
itself.

List nodes Represents a sequence of list entries, where each entry is a structured
collection of child nodes (similar to a record or structure). Each entry in a
list is uniquely identified by the values of its key leaf nodes.
IoT Systems Management with NETCONF-YANG
● YANG is a data modeling language used to model configuration and state data
manipulated by the NETCONF protocol.

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

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.

8) Configuration API: Using the configuration API the application on the IoT device can
be read configuration data from the configuration data store and write operational data to the
operational data store.

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 is set of open source NETCONF tools built on the Libnetconf
library.
The Netopeer tools include:
1. Netopeer- Server
2. Netopeer - agent
3. Netopeer - cli
4. Netopeer - manager
5. Netopeer - configurator
Fig shows: IoT device management with NETCONF - a specific approach based on Netopeer tools.
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 ‗Inc tool‘ which comes with Libnetconf.

3) Fill in the IoT device management code in the Trans API 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 Netopeer
CLI.

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.