IOT UNIT-II PDF
IOT UNIT-II PDF
SYLLABUS
UNIT II
IoT and M2M:Introduction, M2M, Difference between IoT and M2M, SDN and
NFV for IoT.
1
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.
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
2
communication network can use either wired or wireless network(IP based). While the
M2M are networks use either properietorary 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 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.
1) Communication Protocols:
□ Commonly uses M2M protocols include ZigBee, Bluetooth, ModBus, M-Bus,
Wireless M-Bus tec.,
3
□ In IoT uses HTTP, CoAP, WebSocket , MQTT ,XMPP ,DDS ,AMQP etc.,
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.
□ The data in IoT is collected in the cloud (can be public, private orhybrid
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.
4
5
SDN Architecture :
With decoupled control and data planes and centralized network controller, the
network administrators can rapidly configure the network.
SDN architecture supports programmable open APIs for interface between the
SDN application and control layers (Northbound interface).
6
NFV Architecture
2) NFV Infrastructure(NFVI):
NFVI includes compute, network and storage resources that are virtualized.
7
and the life-cycle management of VNFs.
9
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.
10
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 datastore and write operational data to
the operational 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 ldata.
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 withLibnetconf.
3) Fill in the IoT device management code in the TransAPImodule.
4) Build the callbacks C file to generate the libraryfile.
5) Load the YANG module and the TransAPImodule 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
IoTdevice.
11