Module-2 Iot and M2M: Machine-To-Machine (M2M)
Module-2 Iot and M2M: Machine-To-Machine (M2M)
Module-2 Iot and M2M: Machine-To-Machine (M2M)
Figure 3.1 shows the end-to-end architecture for M2M systems Architecture.
M2M system comprising of (1) M2M area networks, (2) communication network and (3) application domain.
(1) An M2M area network comprises of machines (or M2M nodes) which have embedded hardware
modules tor sensing, actuation and communication. Various communication protocols can be used
for M2M local area networks such as ZigBee, Bluetooth, 6-LOWPAN, IEEE 802.15,4, etc. These
communication protocols provide connectivity between M2M nodes within an M2M area network.
(2) 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 cither proprietary or non-IP based communication protocols, the communication
network uses IP-based networks.
Prepared by
Swagat Kumar Jena
M2M gateway
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.
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).
M2M has various application domains such as smart metering, home automation, industrial
automation, smart grids, etc.
M2M is point-to-point communication. In case of IoT, devices are always connected to internet either using
wired or wireless internet. The connectivity to internet is for processing data and delivering it through a
middle layer which is hosted in the cloud.
M2M IoT
Communication Protocols
Prepared by
Swagat Kumar Jena
3) The focus of communication in M2M is
usually on the protocols below the network 3) The focus of communication in IoT is
layer such as ZigBee, Bluetooth, 6LoWPAN, usually on the protocols above the network
IEEE 802.15.4, Z-Wave, etc. layer such as HTTP, CoAP, WebSockets,
MQTT, XMPP, DDS, AMQP, etc.
1) The emphasis of M2M is more on hardware 1) The emphasis of IoT is more on software
with embedded modules. which are used for sensor data collection,
data analysis and interfacing with the cloud
through IP-based communication.
1) M2M data is collected in point solutions and 1) In contrast to M2M, the data in IOT is
often in on-premises storage infrastructure. collected in the cloud (can be public.
private or hybrid cloud).
Applications
1) M2M data is collected in point solutions and 1) IoT data is collected in the cloud and can
can be accessed by on-premises be accessed by cloud applications such as
applications such as diagnosis applications, analytics applications, enterprise
service management applications, and on- applications, remote diagnosis and
premises enterprise applications. management applications, etc.
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.
Due to the complexity of conventional network devices, making changes in the networks to meet
the dynamic traffic patterns has become increasingly difficult.
Prepared by
Swagat Kumar Jena
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.,)
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 huge data for analytics.
Such computing environments require highly scalable and easy to manage network architectures
with minimal manual configurations, which is becoming increasingly difficult with conventional
networks.
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.
Prepared by
Swagat Kumar Jena
SDN Application
SDN Controller
Network Device
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.
2. 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.,
3. Standard Communication Interface (OpenFlow): OpenFlow (OF) is considered one of the first
software-defined networking (SDN) standards. With OpenFlow, the forwarding plane of the network
devices can be directly accessed and manipulated (Southbound Open API).
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 5 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
Prepared by
Swagat Kumar Jena
SDN Controller
OpenFlow Protocol
OpenFlow Group
Channel Table
Prepared by
Swagat Kumar Jena
The Key elements of the NFV architecture are as follows:
NFV comprises of network functions implemented in software that run on virtualized resources in the
cloud. NFV enables separation 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.
Prepared by
Swagat Kumar Jena
IOT System Management with NETCONF-YANG
Prepared by
Swagat Kumar Jena
Figure 7. Managing a device with SNMP
Limitations of SNMP
While Simple Network Management Protocol (SNMP) has been the most popular protocol for network
management, it has several limitations which may make it unsuitable for configuration management.
SNMP was designed to provide a simple management interface between the management
applications and the managed devices. For a sequence of SNMP interactions, the application
needs to maintain state and also to be smart enough to roll back the device into a consistent state
in case of errors or failures in configuration.
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.
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.
Prepared by
Swagat Kumar Jena
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. Figure
8 shows the layered architecture of NETCONF protocol.
1. 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.
2. The RPC layer provides mechanism for encoding of RPC calls and notifications. NETCONF provides
various operations to retrieve and edit
3. The operation layer provides a list of operations on network devices such as copy-config, edit-config,
delete-config, connect, lock, unlock etc.
4. 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.
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.
Prepared by
Swagat Kumar Jena
IoT Systems Management with NETCONF-YANG
Figure 9 shows the generic approach of IoT device management with NETCONF-YANG.
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: 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
3. Transaction Manager: Transaction Manager executes all the NETCONF transactions and ensures
that the ACID (Atomicity, Consistency. Isolation, Durability) properties hold true for the transactions.
Prepared by
Swagat Kumar Jena
4. Rollback Manager: Rollback manager is responsible for generating all the transactions necessary to
rollback a current configuration to its original stale.
5. 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.
6. Configuration Validator: Configuration validator checks if the resulting configuration after applying a
transaction would be a valid configuration.
7. Configuration Database: This database contains both the configuration and operational data.
8. Configuration API: Using the configuration API the applications on the IoT device can read
configuration data from the configuration data store and write operational data to the operational
database.
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.
Prepared by
Swagat Kumar Jena
Module-3
Developing Internet of Things & Logical Design using
Python
Prepared by
Swagat Kumar Jena
Step 5: Service Specifications
The fifth step in the IoT design methodology is to define the service specifications. Service specifications
define the services in the IoT system, service types, service inputs/output, service endpoints, service
schedules, service preconditions and service effects.
Python
For python refer the slides attached.
Prepared by
Swagat Kumar Jena
Module-4
IoT Physical Devices & Endpoints
Prepared by
Swagat Kumar Jena