Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Module-2 Iot and M2M: Machine-To-Machine (M2M)

Download as pdf or txt
Download as pdf or txt
You are on page 1of 15
At a glance
Powered by AI
The key takeaways are that M2M refers to networking of machines for remote monitoring and control via data exchange. M2M systems have area networks, communication networks and application domains. M2M gateways enable communication between remote area networks by performing protocol translations.

The main steps in IoT system design methodology are: defining purpose and requirements, specifying processes, developing domain and information models, defining services, specifying IoT level, and developing functional, operational and application views.

The different views defined in IoT system design are the functional view which defines system functions, and the operational view which specifies deployment and operation options.

Module-2

IoT and M2M


Machine-to-Machine (M2M)
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 System Architecture

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.

(3) Application servers provide the access to various user applications.

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.

Figure 2. M2M Gateway

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

Difference between IoT and M2M


Both IoT and M2M refer to some devices being connected and transferring data with each other. However,
they differ in the underlying technologies, systems architectures and types of applications.

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

1) Primarily M2M uses point-to-point 1) In case of IoT, devices are always


communication. Devices in M2M send and connected to internet either using wired or
receive information directly from each other wireless internet.
and generally, devices in M2M
communication are not connected to internet. 2) Primarily communication in IoT is IP
based.
2) Primarily communication in M2M is Non-IP
based.

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.

Machines in M2M vs Things in IoT

1) M2M involve homogeneous machines 1) IoT involve heterogeneous machines


within an M2M area network. within an IoT network.

Hardware vs Software Emphasis

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.

Data Collection & Analysis:

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.

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. 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 are as follows:

(i) 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.
 Due to the complexity of conventional network devices, making changes in the networks to meet
the dynamic traffic patterns has become increasingly difficult.

(ii) Management Overhead:

 Conventional networks involve significant management overhead.

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.,)

(iii) 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 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.

SDN architecture and the SDN layers


Figures 3 and 4, 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.

Figure 3. SDN Architecture

Prepared by
Swagat Kumar Jena
SDN Application

SDN Controller

Network Device

Figure 4. SDN Layers

Key elements of SDN architecture are as follows:

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

Flow Table Flow Table

Open Flow Switch

Figure 5. Open Flow Switch

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. Network functions
can be virtualized without, similarly, SDN can run without NFV.

Figure 6 shows the NEV architecture.

Figure 6. NFV Architecture

Prepared by
Swagat Kumar Jena
The Key elements of the NFV architecture are as follows:

1. Virtualized Network Function (VNF):


VNF is a software implementation of a network function which is capable of running over the NFV
Infrastructure (NEVI).

2. NFV Infrastructure (NFVI):


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

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

Need of IoT Systems Management


To manage multiple devices within a single IoT system requires advanced management capabilities. The
need for managing IoT systems is described as follows:
1) Automating Configuration: IoT system management capabilities can help in automating the system
configurations. System management interfaces provide predictable and easy to use management
capability and the ability to automate system configuration.
2) Monitoring Operational & Statistical Data: Operational data is the data which is related to the system's
operating parameters and is collected by the system at runtime. Statistical data is the data which
describes the system performance (e.g. CPU and memory usage). 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: In system wide configuration, all devices are configured in a single atomic
transaction. This ensures that the configuration changes are either applied to all devices or to none.
In the event of a failure in applying the configuration to one or more devices, the configuration
changes are rolled back.
4) 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.
5) 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.

Simple Network Management Protocol (SNMP)


SNMP is a well-known application layer protocol and used for network management that allows monitoring
and configuring network devices such as routers, switches, servers, printers, etc. SNMP is an application
layer protocol that uses User Datagram Protocol (UDP) as the transport protocol. Figure 6 shows the
components of entities involved in managing a device with SNMP.

(a) Network Management Station (NMS)


(b) Managed Device
 Management Information Base
 SNMP Agent

(a) Network Management Station (NMS):


NMS executes SNMP commands to monitor and configure the Managed Device.

(b) Managed Device:


The Managed Device contains the Management Information Base MIB which has all the information
of the device attributes to be managed. MIBs use the Structure of Management Information (SMI)
notation for defining the structure of the management data.

(c) SNMP Agent:


The agent is a program that is packaged within the network element. Enabling the agent allows it to
collect the management information database from the device locally and makes it available to the
SNMP manager, when it is queried for.

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.

 It is difficult to differentiate between configuration and state data in MIBs.

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

Figure 8. NETCONF protocol layer

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.

Figure 9 IoT device management with NETCONF-YANG

The roles of the various components are described as follows.

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

IoT system design methodology includes the following steps:

1. Purpose & Requirements Specification


2. Process Specification
3. Domain Model Specification
4. Information Model Specification
5. Service Specifications
6. IoT Level Specification
7. Functional View Specification
8. Operational View Specification
9. Device & Component Integration
10. Application Development

Step 1: Purpose & Requirements Specification:


The first step in IoT system design methodology is to define the purpose and requirements of the system.
In this step, the system purpose, behavior and requirements (such as data collection requirements, data
analysis requirements, system management requirements, data privacy and security requirements, user
interface requirements, ...) are captured.

Step 2: Process Specification


The second step in the IoT design methodology is to define the process specification. In this step, the use
cases of the IoT system are formally described based on and derived from the purpose and requirement
specifications.

Step 3: Domain Model Specification


The third step in the IoT design methodology is to define the Domain Model. The domain model describes
the main concepts, entities and objects in the domain of IoT system to be designed. Domain model defines
the attributes of the objects and relationships between objects. Domain model provides an abstract
representation of the concepts, objects and entities in the IoT domain, independent of any specific
technology or platform. With the domain model, the IoT system designers can get an understanding of the
IoT domain for which the system is to be designed.

Step 4: Information Model Specification


The fourth step in the IoT design methodology is to define the Information Model. Information Model defines
the structure of all the information in the IoT system, for example, attributes of Virtual Entities, relations,
etc. Information model does not describe the specifics of how the information is represented or stored. To
define the information model, we first list the Virtual Entities defined in the Domain Model. Information model
adds more details to the Virtual Entities by defining their attributes and relations.

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.

Step 6: IoT Level Specification


The sixth step in the IoT design methodology is to define the IoT level for the system. In Chapter-1, we
defined five IoT deployment levels.

Step 7: Functional View Specification


The seventh step in the IoT design methodology is to define the Functional View. The Functional View (FV)
defines the functions of the IoT systems grouped into various Functional Groups (FGs). Each Functional
Group either provides functionalities for interacting with instances of concepts defined in the Domain Model
or provides information related to these concepts.

Step 8: Operational View Specification


The eighth step in the IoT design methodology is to define the Operational View Specifications. In this step,
various options pertaining to the IoT system deployment and operation are defined, such as, service hosting
options, storage options, device options, application hosting options, etc

Step 9: Device & Component Integration


The ninth step in the IoT design methodology is the integration of the devices and components.

Step 10: Application Development


The final step in the IoT design methodology is to develop the IoT application.

Python
For python refer the slides attached.

Prepared by
Swagat Kumar Jena
Module-4
IoT Physical Devices & Endpoints

For module 4 follow the slides on Raspberry Pi attached.

Prepared by
Swagat Kumar Jena

You might also like