Unit-2

IoT & M2M

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.) 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, Bluetooth, Modbus, M-Bus, Wireless M-Bus, Power Line
Communication (PLC), 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.

Fig.1 M2M system Architecture

 Fig 2: Block diagram of an M2M gateway
Figure 2 shows a 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,
etcM2M solution designs (such as data collection and storage architectures and applications)
are specific to the M2M application domain.
2.1 Differences between M2M and IoT
Differences between IoT and M2M can be discussed in the following aspects.
 Communication Protocols
 Machines in M2M vs Things in IoT
 Hardware vs Software Emphasis
 Data Collection & Analysis
 Applications

 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, Bluetooth, Modbus, M-Bus, Wireless
M-Bus, Power Line Communication (PLC), etc.. The focus of communication in M2M is
usually on the protocols below the network layer. The focus of communication in loT is
usually on the protocols above the network layer such as HTTP, COAP, WebSocket as shown
in Figure 3.
 Fig 3: Communication Protocol
 Machines in M2M vs Things in IoT: The "Things" in loT 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 loT 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 nave Heterogeneous things (e.g., a home
automation IoT system can include lol 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 1s more on hardware
with embedded modules, the emphasis of loT is more on software (loT devices run
specialized software for sensor data collection, data analysis and interfacing with the
cloud through IP-based communication) Figure 4 shows the various components of loT
systems including the things, the, internet, communication infrastructure and the
applications.
 Fig 4:IoT Components
 Data Collection & Analysis: M2M data is collected in point solutions and often in on-
premises storage infrastructure. In contrast to M2M, the data in loT is collected in the
cloud (can be public, private or hybrid cloud)) from the various loT-levels, and the IoT
components deployed in the 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-premises enterprise applications. IoT data is collected in the cloud and can
accessed by cloud applications.
2.2 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) Figure 5. shows the
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.
 Fig 5: Conventional network architecture
Limitations:
[Link] Network Devices
[Link] Overhead
3. Limited Scalability
1. Complex Network Devices:
Conventional networks are getting increasingly complex with more and protocols
being implemented to improve link speeds and reliability. patterns and had a large number of
protocols designed for specific applications. For loT 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 overhead. Network managers find it
increasingly difficult to manage multiple network devices and interfaces from multiple
vendors.
3. Limited Scalability:
The virtualization technologies used in cloud computing environments has increased
the number of virtual hosts requiring network access. loT applications hosted in the cloud are
distributed across multiple virtual machines that require exchange of traffic. 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 attempts to create network architectures that are simpler, inexpensive, scalable,
agile and easy to manage. figures 7 and 8 show the SDN architecture and the SDN layers in
which 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. 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. 1hese devices can be simpler and cost less as they can be built from
standard hardware and software components.

Fig 6: SDN architecture

Fig 7:SDN layers

Key Elements of SDN:
 Centralized Network Controller
 Programmable Open APls
 Standard Communication Interface (OpenFlow):
1. 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.
[Link] Open APls
SDN architecture supports programmable open APIs for interface between the SDN
application and control layers (Northbound interface). With these open APls various network
services can be implemented, such as routing, quality of service (QoS), access control, etc...
[Link] 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 8 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 9 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.

Fig 8: Open Flow switch

 Fig 9: Open Flow flow table
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.
Fig 10 shows the NFV architecture, as being standardized by the European
Telecommunications Standards Institute (ETS).

Fig 10: NFV Architecture

Key elements of the NFV architecture are as follows:
 Virtualized Network Function (VNF)
 NFV Infrastructure (NFVI)
 NFV Management and Orchestration

 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.
Let us look at an example of how NFV can be used for virtualization of the home
networks. Figure 11 shows a home network with a Home Gateway that provides Wide Area
Network (WAN) connectivity to enable services such as Internet, IPTV, VoIP, etc. The
Home Gateway performs various functions including - Dynamic Host Configuration Protocol
(DHCP) server, Network Address Translation (NAT), application specific gateway and
Firewall. The Home Gateway provides private IP addresses to each connected device in the
home. The Home Gateway provides routing capabilities and translates the private IP
addresses to one public address (NAT function). The gateway also provides application
specific routing for applications such as VoIP and IPTV.
Figure 12 shows how 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.

Fig 11: Conventional home network architecture

 Fig 12: Home network with virtualized Home Gateway
2.4 BUILDING BLOCKS of IoT
Four things form basic building blocks of the IoT system – sensors, processors,
gateways, applications. Each of these nodes has to have its own characteristics in order to
form an useful IoT system.

Figure 13: Simplified block diagram of the basic building blocks of the IoT
Sensors:
• These form the front end of the IoT devices. These are the so-called “Things”
of the system. Their main purpose is to collect data from its surroundings
(sensors) or give out data to its surrounding (actuators).These have to be
uniquely identifiable devices with a unique IP address so that they can be
easily identifiable over a large network.
• These have to be active in nature which means that they should be able to
collect real-time data. These can either work on their own (autonomous in
 nature) or can be made to work by the user depending on their needs (user-
controlled).
• Examples of sensors are gas sensor, water quality sensor, moisture sensor, etc.

Processors:
• Processors are the brain of the IoT system. Their main function is to process
the data captured by the sensors and process them so as to extract the valuable
data from the enormous amount of raw data collected. In a word, we can say
that it gives intelligence to the data.
• Processors mostly work on real-time basis and can be easily controlled by
applications. These are also responsible for securing the data – that is
performing encryption and decryption of data.
• Embedded hardware devices, microcontroller, etc are the ones that process the
data because they have processors attached to it.
Gateways:
• Gateways are responsible for routing the processed data and send it to proper
locations for its (data) proper utilization.
• In other words, we can say that gateway helps in to and fro communication of
the data. It provides network connectivity to the data. Network connectivity is
essential for any IoT system to communicate.
• LAN, WAN, PAN, etc are examples of network gateways.

Applications:
• Applications form another end of an IoT system. Applications are essential for
proper utilization of all the data collected.
• These cloud-based applications which are responsible for rendering the
effective meaning to the data collected. Applications are controlled by users
and are a delivery point of particular services.
• Examples of applications are home automation apps, security systems,
industrial control hub, etc.