Module-ll

INTERNET OF THINGS

# LECTURE-12
INTRODUCTION TO M2M SYSTEM, DIFFERENCE BETWEEN IOT
AND M2M

Module-ll
IoT and M2M
M2M-Introduction
Machine-to-Machine (M2M) refers to networking of machines (or devices) for the
purpose of remote monitoring and control and data exchange.

Figure 1: M2M systems architecture

Figure 1: shows the end-to-end 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, Bluetooh, ModBus, M-Bus, Wirless 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 either proprietary or non-IP based
communication protocols, the communication network uses IP-based
networks. 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.

 Figure 2: Block diagram of an M2M gateway

 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.
 The M2M data is gathered into point solutions such as enterprise
applications, service management applications, or remote monitoring
applications. M2M has various application domains such as smart metering,
home automation, industrial automation, smart grids, etc. M2M solution
designs (such as data collection and storage architectures and applications
are specific to the M2M application domain.

Difference between loT and M2M

Though both M2M and IoT involve networking of machines or devices, they differ
in the underlying technologies, systems architectures and types of applications.
The differences between M2M and IoT are described as follows:
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.
Commonly uses M2M protocols include ZigBee, Bluetooh, ModBus, M-Bus,
Wirless M-Bus, Power Line Communication (PLC), 6LOWPAN, IEEE 802.15.4,
Z-Wave. etc.
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, WebSockets, 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) or
their internal physical states.
The unique identifiers for the things in IoT are the IP addresses (or MAC
addresses).
Things have software components for accessing, processing, and storing sensor
information, or controlling actuators connected.
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).
The analytics component analyzes the data and stores the results in the cloud
database.
The IoT data and analysis results are visualized with the cloud-based applications.
The centralized controller is aware of the status of all the end nodes and sends
control commands to the nodes.
Observer nodes can process information and use it for various applications,
however, observer nodes do not perform any control functions.
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. Since the scale of data collected in IoT is so massive, cloud-based
real-time and batch data analysis frameworks are used for data analysis.

Figure 3: Communication in IoT

# LECTURE-13
SDN AND NFV FOR IOT; SOFTWARE DEFINED NETWORKING,
NETWORK FUNCTION VIRTUALIZATION.

SDN and NFV for IoT

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. 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.
 Figure 4 shows the conventional network architecture
The limitations of the conventional network architectures are as follows:
 Complex Network Devices:
Conventional networks are getting increasingly complex with more and
more protocols being implemented to improve link speeds and reliability.
Interoperability is limited due to the lack of standard and open interfaces.
Network devices use proprietary hardware and software and have slow
product life-cycles limiting innovation.
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.
 Figure 5 SDN architecture

 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.
 The analytics components of IoT 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.

Figure 6 SDN Layers

SDN attempts to create network architectures that are simpler, inexpensive,
scalable, agile and easy to manage.
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. The underlying
network infrastructure is abstracted from the applications.
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. These devices can be simpler and cost less as they can be
built from standard hardware and software components.
Key elements of SDN are as follows:
 Centralized Network Controller:
 With decoupled control and data planes and centralized network controller,
the network administrators can rapidly configure the network. SDN
applications can be deployed through programmable open APIs. This speeds
up innovation as the network administrators no longer need to wait for the
device vendors to embed new features in their proprietary hardware.
 Programmable Open APIs:
SDN architecture supports programmable open APIs for interface between
the SDN application and control layers (Northbound interface). With these
open APIs various network services can be implemented, such as routing.
quality of service (QoS), access control, etc.
 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.
With OpenFlow, the forwarding plane of the network devices can be directly
accessed and manipulated OpenFlow uses the concept of flows to identify
network traffic based on pre-defined match rules. Flows can be programmed
statically or dynamically by the SDN control software.
Figure 7 shows the components of an OpenFlow switch comprising of one or more
flow tables and a group table, which perform packet lookups and forwarding. and
OpenFlow channel to an external controller.
OpenFlow protocol is implemented on both sides of the interface between the
controller and the network devices. The controller manages the switch via the
OpenFlow switch protocol.
The controller can add, update, and delete flow entries in flow tables.
 .

Figure-7

Figure 8 OpenFlow Flow table

Figure 8 shows an example of an OpenFlow flow table. Each flow table contains a
set of flow entries. Each flow entry consists of match fields, counters, and a set of
instructions to apply to matching packets. Matching starts at the first flow table and
may continue to additional flow tables of the pipeline.

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 is complementary to SDN as 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.

Figure 9 NFV architecture

Key elements of the NFV architecture are as follows:

 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 comprises of network functions implemented in software that run on
virtualized resources in the cloud.
NFV enables separation of network functions which are implemented in
software from the underlying hardware. Thus network functions can be easily
tested and upgraded by installing new software while the hardware remains the
same.
Virtualizing network functions reduces the equipment costs and also reduces
power consumption. The multi-tenanted nature of the cloud allows virtualized
network functions to be shared for multiple network services.
NFV is applicable only to data plane and control plane functions in fixed and
mobile networks.