UNIT 2

IOT AND M2M

IOT:
IoT stands for Internet of Things. It refers to the interconnectedness of
physical devices, such as appliances and vehicles, that are embedded with
software, sensors, and connectivity which enables these objects to connect and
exchange data. This technology allows for the collection and sharing of data
from a vast network of devices, creating opportunities for more efficient and
automated systems.

Internet of Things (IoT) is the networking of physical objects that contain

electronics embedded within their architecture in order to communicate and
sense interactions amongst each other or with respect to the external
environment. In the upcoming years, IoT-based technology will offer
advanced levels of services and practically change the way people lead their
daily lives. Advancements in medicine, power, gene therapies, agriculture,
smart cities, and smart homes are just a few of the categorical examples where
IoT is strongly established.
IOT is a system of interrelated things, computing devices, mechanical and
digital machines, objects, animals, or people that are provided with unique
identifiers. And the ability to transfer the data over a network requiring
human-to-human or human-to-computer interaction.

As we have a platform such as a cloud that contains all the data through which
we connect all the things around us. For example, a house, where we can
connect our home appliances such as air conditioner, light, etc. through each
other and all these things are managed at the same platform. Since we have a
platform, we can connect our car, track its fuel meter, speed level, and also track
the location of the car.
If there is a common platform where all these things can connect to each other
would be great because based on my preference, I can set the room temperature.
For example, if I love the room temperature to to be set at 25 or 26-degree
Celsius when I reach back home from my office, then according to my car
location, my AC would start before 10 minutes I arrive at home. This can be
done through the Internet of Things (IoT).

How does Internet of Thing (IoT) Work?

The working of IoT is different for different IoT echo system (architecture).
However, the key concept of there working are similar. The entire working
process of IoT starts with the device themselves, such as smartphones, digital
watches, electronic appliances, which securely communicate with the IoT
platform. The platforms collect and analyze the data from all multiple devices
and platforms and transfer the most valuable data with applications to devices.
Features of IOT

The most important features of IoT on which it works are connectivity,

analyzing, integrating, active engagement, and many more. Some of them are
listed below:

Connectivity: Connectivity refers to establish a proper connection between all

the things of IoT to IoT platform it may be server or cloud. After connecting the
IoT devices, it needs a high speed messaging between the devices and cloud to
enable reliable, secure and bi-directional communication.

Analyzing: After connecting all the relevant things, it comes to real-time

analyzing the data collected and use them to build effective business
intelligence. If we have a good insight into data gathered from all these things,
then we call our system has a smart system.

Integrating: IoT integrating the various models to improve the user experience
as well.

Artificial Intelligence: IoT makes things smart and enhances life through the
use of data. For example, if we have a coffee machine whose beans have going
to end, then the coffee machine itself order the coffee beans of your choice from
the retailer.

Sensing: The sensor devices used in IoT technologies detect and measure any
change in the environment and report on their status. IoT technology brings
passive networks to active networks. Without sensors, there could not hold an
effective or true IoT environment.

Active Engagement: IoT makes the connected technology, product, or services

to active engagement between each other.

Endpoint Management: It is important to be the endpoint management of all

the IoT system otherwise, it makes the complete failure of the system. For
example, if a coffee machine itself order the coffee beans when it goes to end
but what happens when it orders the beans from a retailer and we are not present
at home for a few days, it leads to the failure of the IoT system. So, there must
be a need for endpoint management.

History of IOT
Here you will get to know about how IOT is involved and also from the
explanation of each will let you know how IOT plays a role in this innovations
!
  1982 – Vending machine: The first glimpse of IoT emerged as a
vending machine at Carnegie Mellon University was connected to the
internet to report its inventory and status, paving the way for remote
monitoring.
 1990 – Toaster: Early IoT innovation saw a toaster connected to the
internet, allowing users to control it remotely, foreshadowing the
convenience of smart home devices.
 1999 – IoT Coined (Kevin Ashton): Kevin Ashton coined the term
“Internet of Things” to describe the interconnected network of
devices communicating and sharing data, laying the foundation for a
new era of connectivity.
 2000 – LG Smart Fridge: The LG Smart Fridge marked a
breakthrough, enabling users to check and manage refrigerator
contents remotely, showcasing the potential of IoT in daily life.
 2004 – Smart Watch: The advent of smartwatches introduced IoT to
the wearable tech realm, offering fitness tracking and notifications
on-the-go.
 2007 – Smart iPhone: Apple’s iPhone became a game-changer,
integrating IoT capabilities with apps that connected users to a
myriad of services and devices, transforming smartphones into hubs.
 2009 – Car Testing: IoT entered the automotive industry, enhancing
vehicles with sensors for real-time diagnostics, performance
monitoring, and remote testing.
 2011 – Smart TV: The introduction of Smart TVs brought IoT to the
living room, enabling internet connectivity for streaming, app usage,
and interactive content.
 2013 – Google Lens: Google Lens showcased IoT’s potential in
image recognition, allowing smartphones to provide information
about objects in the physical world.
 2014 – Echo: Amazon’s Echo, equipped with the virtual assistant
Alexa, demonstrated the power of voice-activated IoT, making smart
homes more intuitive and responsive.
 2015 – Tesla Autopilot: Tesla’s Autopilot system exemplified IoT in
automobiles, introducing semi-autonomous driving capabilities
through interconnected sensors and software.

Four Key Components of IOT

 Device or sensor
 Connectivity
 Data processing
 Interface
IoT is network of interconnected computing devices which are embedded
in everyday objects, enabling them to send and receive data.
Over 9 billion ‘Things’ (physical objects) are currently connected to the
Internet, as of now. In the near future, this number is expected to rise to a
whopping 20 billion.

Main Components Used in IoT

 Low-power embedded systems: Less battery consumption, high

performance are the inverse factors that play a significant role during
the design of electronic systems.
 Sensors: Sensors are the major part of any IoT application. It is a
physical device that measures and detects certain physical quantities
and converts it into signal which can be provided as an input to
processing or control unit for analysis purpose.

Ways of Building IOT

There are two ways of building IoT:

 Form a separate internet work including only physical objects.
 Make the Internet ever more expansive, but this requires hard-core
technologies such as rigorous cloud computing and rapid big data
storage (expensive).
In the near future, IoT will become broader and more complex in terms of
scope. It will change the world in terms of
“anytime, anyplace, anything in connectivity.”
IoT Enablers
 RFIDs: uses radio waves in order to electronically track the tags
attached to each physical object.
 Sensors: devices that are able to detect changes in an environment
(ex: motion detectors).
 Nanotechnology: as the name suggests, these are tiny devices with
dimensions usually less than a hundred nanometers.
 Smart networks: (ex: mesh topology).

Working with IoT Devices

 Collect and Transmit Data : For this purpose sensors are widely
used they are used as per requirements in different application areas.
 Actuate device based on triggers produced by sensors or
processing devices: If certain conditions are satisfied or according to
 user’s requirements if certain trigger is activated then which action to
perform that is shown by Actuator devices.
 Receive Information: From network devices, users or devices can
take certain information also for their analysis and processing
purposes.
 Communication Assistance: Communication assistance is the
phenomenon of communication between 2 networks or
communication between 2 or more IoT devices of same or different
networks. This can be achieved by different communication
protocols like: MQTT, Constrained Application Protocol, ZigBee,
FTP, HTTP etc.
Characteristics of IoT

 Massively scalable and efficient

 IP-based addressing will no longer be suitable in the upcoming
future.
 An abundance of physical objects is present that do not use IP, so IoT
is made possible.
 Devices typically consume less power. When not in use, they should
be automatically programmed to sleep.
 A device that is connected to another device right now may not be
connected in another instant of time.
 Intermittent connectivity – IoT devices aren’t always connected. In
order to save bandwidth and battery consumption, devices will be
powered off periodically when not in use. Otherwise, connections
might turn unreliable and thus prove to be inefficient.

Modern Applications
 Smart Grids and energy saving
 Smart cities
 Smart homes/Home automation
 Healthcare
 Earthquake detection
 Radiation detection/hazardous gas detection
 Smartphone detection
 Water flow monitoring
 Traffic monitoring
 Wearables
 Smart door lock protection system
 Robots and Drones
 Healthcare and Hospitals, Telemedicine applications
 Security
 Biochip Transponders (For animals in farms)
 Heart monitoring implants (Example Pacemaker, ECG real time
tracking)
 Agriculture
 Industry

Advantages of IoT
 Improved efficiency and automation of tasks.
 Increased convenience and accessibility of information.
 Better monitoring and control of devices and systems.
 Greater ability to gather and analyze data.
 Improved decision-making.
  Cost savings.

Disadvantages of IoT
 Security concerns and potential for hacking or data breaches.
 Privacy issues related to the collection and use of personal data.
 Dependence on technology and potential for system failures.
 Limited standardization and interoperability among devices.
 Complexity and increased maintenance requirements.
 High initial investment costs.
 Limited battery life on some devices.
 Concerns about job displacement due to automation.
 Limited regulation and legal framework for IoT, which can lead to
confusion and uncertainty.

M2M (MACHINE TO MACHINE):

M2M stands for Machine to Machine communication. It is a direct
communication system between the devices using wired or wireless
communications channels without any human interaction. It collects the data
and shares it with other connected devices. It is a technology that allows devices
without the use of the internet to connect between devices. Various applications,
such as defense, monitoring and tracking, production and facility management,
are provided by M2M communications.
M2M technology may be present in offices, shopping malls, houses, and many
other places. A common example of a machine to machine is controlling
electrical devices like fans and bulbs using Bluetooth from the smartphone.
Here, the smartphone and electrical devices are the two interacting devices with
each other.
Key Components for M2M System:

Key components of an M2M system include

o Sensors,
o RFID,
o a Wi-Fi or cellular communications link and
o To help a networked device to interpret data and make decisions, the need
for Autonomic Computing software programmed.

Machine to machine communication can include industrial instrumentation,

 o Enabling a sensor to communicate the data it records (such
as temperature, inventory level, etc.) to application software
o This application software can use it (for example, adjusting an industrial
process based on temperature or placing orders to replenish inventory).

Applications of Machine to Machine communication:

M2M communication is often used for

o Remote monitoring
o Product restocking (a vending machine can generate an alert or message
the distributor when a particular item is running low)
o In Warehouse management to remote control, robotics, traffic
control, supply chain management, fleet management, logistic services,
and telemedicine services.

Products built with Machine to Machine communication capabilities are often

marketed to end-users as being “smart.”

Such communication initiated by a remote network of machines generated

information sent to a central hub for analysis, which would then share with a
system like a personal computer.

Benefits of Machine to Machine:

M2M wireless networks can use to

o Improve the efficiency and production of machines,

o To increase the reliability and safety of complex systems, and
o To encourage the life-cycle management for key assets and products.

By applying Prognosis and Health Management (PHM) techniques in machine

networks, the following can achieve
 o Health management of a fleet of similar machines
o Near-zero downtime performance of machines and system.

Advantages of M2M:

1. Efficiency and Productivity:

o Automated Processes: M2M allows for automated monitoring and
management of processes, leading to increased efficiency and
productivity.
o Real-time Data: Devices can communicate in real-time, enabling
businesses to make immediate decisions based on accurate data.
2. Cost Savings:
o Reduced Labor Costs: By automating tasks that would otherwise
require human intervention, businesses can save on labor costs.
o Predictive Maintenance: M2M facilitates predictive maintenance,
allowing organizations to identify and address issues before they
lead to costly breakdowns.
3. Enhanced Customer Experience:
o Improved Service: M2M enables businesses to provide better
customer service through remote monitoring and troubleshooting.
o Personalization: By analyzing data collected through M2M
communication, organizations can personalize products and
services to meet customer needs.
4. Scalability:
o Expandability: M2M solutions are scalable, allowing businesses
to easily add more devices or integrate with existing systems as
their needs evolve.
o Integration: M2M devices can be integrated with various
platforms and applications, providing flexibility and
interoperability.
5. Safety and Security:
o Remote Monitoring: M2M enables remote monitoring of critical
infrastructure and assets, enhancing safety and security.
o Data Encryption: Advanced encryption techniques can be
employed to secure data transmitted between devices, protecting
against unauthorized access and cyber threats.

Disadvantages of M2M:

1. Complexity and Integration Challenges:

 o Compatibility Issues: Integrating diverse devices and systems can
be challenging due to differences in protocols, standards, and
technologies.
o Complex Infrastructure: Building and maintaining a robust M2M
infrastructure requires expertise in various domains, including
networking, security, and software development.
2. Cost Implications:
o Initial Investment: Implementing M2M solutions involves
significant upfront costs for hardware, software, and infrastructure.
o Maintenance Costs: Ongoing maintenance and support can add to
the total cost of ownership, especially as the number of devices
increases.
3. Security Concerns:
o Vulnerabilities: M2M devices may be susceptible to security
vulnerabilities, including malware attacks, data breaches, and
unauthorized access.
o Privacy Issues: Collecting and transmitting data between devices
raises privacy concerns related to data ownership, consent, and
compliance with regulations.
4. Reliability and Performance:
o Network Congestion: As the number of connected devices
increases, network congestion and bandwidth limitations may
impact performance and reliability.
o Downtime: System failures, software bugs, and hardware
malfunctions can lead to downtime, affecting operations and
service availability.
5. Regulatory and Compliance Issues:
o Legal Requirements: Organizations must comply with various
regulations and standards governing data privacy, security, and
interoperability.
o Data Governance: Managing data generated by M2M devices
requires robust governance policies to ensure compliance with
legal and ethical standards.
DIFFERENCE BETWEEN IOT AND M2M:

There are various differences between the IoT and M2M. Some of the popular
comparisons between the IoT and M2M are discussed in the below tabular
form.

Features IoT M2M

Abbreviation IoT stands for the Internet of M2M stands for Machine-to-
Things. Machine communication.

Intelligence Devices include objects that In M2M, there is a limited

are responsible for decision- amount of intelligence
making processes. observed.

Communicatio IoT has used internet Communication technology

n Protocol Used protocols like FTP, Telnet, and Traditional protocols are
and HTTP. uses in M2M technology.

Connection The connection of IoT is M2M uses a point to point

Type Used through the network and connection.
using various types of
communication.

Scope It has a wide range of It has a limited Scope for

devices, yet the scope is devices.
large.

Business Type It has Business to Consumer It has Business to Business

Used (B2C) and Business to (B2B) communication.
Business (B2B).

Data Sharing In IoT, data sharing depends In M2M, devices may be

on the Internet protocol connected through mobile or
network. any other network.

Open API IoT technology supports In M2M technology, there is

Support Open API integrations. no Open API support.

Example Big Data, Cloud, Smart Data and Information,

wearables, and many more. sensors, and many more.
SDN (Software defined Networking)
SDN stands for Software Defined Network which is a networking architecture
approach. It enables the control and management of the network using
software applications. Through Software Defined Network (SDN) networking
behavior of the entire network and its devices are programmed in a centrally
controlled manner through software applications using open APIs.
To understand software-defined networks, we need to understand the various
planes involved in networking.
1. Data Plane
2. Control Plane
Data plane: All the activities involving as well as resulting from data packets
sent by the end-user belong to this plane. This includes:
 Forwarding of packets.
 Segmentation and reassembly of data.
 Replication of packets for multicasting.
Control plane: All activities necessary to perform data plane activities but do
not involve end-user data packets belong to this plane. In other words, this is
the brain of the network. The activities of the control plane include:
 Making routing tables.
 Setting packet handling policies.

Why SDN is Important?
 Better Network Connectivity: SDN provides very better network
connectivity for sales, services, and internal communications. SDN
also helps in faster data sharing.
 Better Deployment of Applications: Deployment of new
applications, services, and many business models can be speed up
using Software Defined Networking.
 Better Security: Software-defined network provides better visibility
throughout the network. Operators can create separate zones for
devices that require different levels of security. SDN networks give
more freedom to operators.
 Better Control with High Speed: Software-defined networking
provides better speed than other networking types by applying an
open standard software-based controller.
In short, it can be said that- SDN acts as a “Bigger Umbrella or a HUB” where
the rest of other networking technologies come and sit under that umbrella and
get merged with another platform to bring out the best of the best outcome by
decreasing the traffic rate and by increasing the efficiency of data flow.
Where is SDN Used?
 Enterprises use SDN, the most widely used method for application
deployment, to deploy applications faster while lowering overall
deployment and operating costs. SDN allows IT administrators to
manage and provision network services from a single location.
 Cloud networking software-defined uses white-box systems. Cloud
providers often use generic hardware so that the Cloud data center
can be changed and the cost of CAPEX and OPEX saved.
Components of Software Defining Networking (SDN)
The three main components that make the SDN are:
1. SDN Applications: SDN Applications relay requests or networks
through SDN Controller using API.
2. SDN controller: SDN Controller collects network information from
hardware and sends this information to applications.
3. SDN networking devices: SDN Network devices help in forwarding
and data processing tasks.
SDN Architecture
In a traditional network, each switch has its own data plane as well as the
control plane. The control plane of various switches
exchange topology information and hence construct a forwarding table that
decides where an incoming data packet has to be forwarded via the data plane.
Software-defined networking (SDN) is an approach via which we take the
control plane away from the switch and assign it to a centralized unit called the
SDN controller. Hence, a network administrator can shape traffic via a
centralized console without having to touch the individual switches. The data
plane still resides in the switch and when a packet enters a switch, its
forwarding activity is decided based on the entries of flow tables, which are
pre-assigned by the controller. A flow table consists of match fields (like input
port number and packet header) and instructions. The packet is first matched
against the match fields of the flow table entries. Then the instructions of the
corresponding flow entry are executed. The instructions can be forwarding the
packet via one or multiple ports, dropping the packet, or adding headers to the
packet. If a packet doesn’t find a corresponding match in the flow table, the
switch queries the controller which sends a new flow entry to the switch. The
switch forwards or drops the packet based on this flow entry.
A typical SDN architecture consists of three layers.
 Application layer: It contains the typical network applications
like intrusion detection, firewall, and load balancing
 Control layer: It consists of the SDN controller which acts as the
brain of the network. It also allows hardware abstraction to the
applications written on top of it.
  Infrastructure layer: This consists of physical switches which form
the data plane and carries out the actual movement of data packets.
The layers communicate via a set of interfaces called the north-bound
APIs(between the application and control layer) and southbound
APIs(between the control and infrastructure layer).

Different Models of SDN

There are several models, which are used in SDN:
1. Open SDN
2. SDN via APIs
3. SDN via Hypervisor-based Overlay Network
4. Hybrid SDN

1. Open SDN: Open SDN is implemented using the OpenFlow switch. It is a

straightforward implementation of SDN. In Open SDN, the controller
communicates with the switches using south-bound API with the help of
OpenFlow protocol.
 2.SDN via APIs: In SDN via API, the functions in remote devices like
switches are invoked using conventional methods like SNMP or CLI or
through newer methods like Rest API. Here, the devices are provided with
control points enabling the controller to manipulate the remote devices using
APIs.

3. SDN via Hypervisor-based Overlay Network: In SDN via the hypervisor,

the configuration of physical devices is unchanged. Instead, Hypervisor based
overlay networks are created over the physical network. Only the devices at
the edge of the physical network are connected to the virtualized networks,
thereby concealing the information of other devices in the physical network.
 4.Hybrid SDN: Hybrid Networking is a combination of Traditional
Networking with software-defined networking in one network to support
different types of functions on a network.

Difference between SDN and Traditional Networking

Software Defined Networking Traditional Networking

Software Defined Network is a A traditional network is the old

virtual networking approach. conventional networking approach.

Software Defined Network is Traditional Network is distributed

centralized control. control.

This network is programmable. This network is nonprogrammable.

Software Defined Network is the A traditional network is a closed

 Software Defined Networking Traditional Networking

open interface. interface.

In Software Defined Network data In a traditional network data plane

plane and control, the plane is and control plane are mounted on the
decoupled by software. same plane.

Advantages of SDN
 The network is programmable and hence can easily be modified via
the controller rather than individual switches.
 Switch hardware becomes cheaper since each switch only needs a
data plane.
 Hardware is abstracted, hence applications can be written on top of
the controller independent of the switch vendor.
 Provides better security since the controller can monitor traffic and
deploy security policies. For example, if the controller detects
suspicious activity in network traffic, it can reroute or drop the
packets.

Disadvantages of SDN
  The central dependency of the network means a single point of
failure, i.e. if the controller gets corrupted, the entire network will be
affected.
 The use of SDN on large scale is not properly defined and explored.

IOT SYSTEM MANAGEMENT WITH NETCONF-YANG

IoT System Management with NETCONF-YANG
NETCONF (Network Configuration Protocol) and YANG are essential
components in the realm of Internet of Things (IoT) system management.

THE FOLLOWING ARE THE OUTLINES:

Need for IoT Systems Management
• Automating Configuration
• Monitoring Operational & Statistical Data
• Improved Reliability
• System Wide Configurations
• Multiple System Configurations
• Retrieving & Reusing Configurations
Simple Network Management Protocol (SNMP)
• SNMP is a well-known and widely used network management protocol that
allows monitoring and configuring network devices such as routers, switches,
servers, printers, etc.
• SNMP component include
• Network Management Station (NMS)
• Managed Device
• Management Information Base (MIB)
• SNMP Agent that runs on the device
Limitations of SNMP
• SNMP is stateless in nature and each SNMP request contains all the
information to process the request. The application needs to be intelligent to
manage the device.
• 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.
• Earlier versions of SNMP did not have strong security features.
Network Operator Requirements
• Ease of use
• Distinction between configuration and state data
• Fetch configuration and state data separately
• Configuration of the network as a whole
• Configuration transactions across devices
• Configuration deltas
• Dump and restore configurations
• Configuration validation
• Configuration database schemas
• Comparing configurations
• Role-based access control
• Consistency of access control lists:
• Multiple configuration sets
• Support for both data-oriented and task- oriented access control.
NETCONF

NETCONF is a network management protocol that uses a simple remote

procedure call (RPC) mechanism to interact with network devices. It is designed
to work with the Simple Network Management Protocol (SNMP) and uses an
Extensible Markup Language (XML) data encoding format. It allows network
administrators to configure, monitor, and troubleshoot network devices
remotely, making it a valuable tool for managing large and complex networks.

 It is used to connect with the device securely to do the configurations and

fetch the operational data.
 It does not define the data format; this responsibility was taken up by
YANG (Yet Another Next Generation) data modelling language, which
was described by IETF.
 It does the transportation using an SSH connection on port number 830.

In a setup like the one shown above, tools like Ansible and Python can be used
on Management PC to configure routers through Network Configuration
Protocol. The two required things on the router will be the SSH configurations
and enabling the NETCONF. The Data Structuring Language used by the
Network Configuration Protocol is XML (Extensible Markup Language),
meaning the payload you want to push on the device should be in XML format.
NETCONF History

NETCONF was introduced to address the limitations of SNMP and CLI.

Netconf base protocol was first introduced in late 2006 as an RFC 4741
NETCONF Configuration Protocol by NETCONF working groups. In 2011, the
revised version was published as RFC 6241, and today it’s the most current
version. Several RFCs have been published by Internet Engineering Task Force
(IETF).

Some of the supporting RFCs published by IETF are:

 RFC 4742
 RFC 4743
 RFC 5539

The RFCs, as mentioned above, were updated in 2011 and became:

 RFC 6241 (old version 4741)

 RFC 6242 (old version 4742)

Let’s move on and understand why we needed this protocol in the first place.

Why Network Configuration Protocol (NETCONF) vs. Other Approaches

Back in 2002, when the IAB (Internet Architecture Board) and IETF (Internet
Engineering Task Force) set up a workshop with network operators to address
the concerns of network operators on issues related to network management,
they realized that the industry was extensively dependent upon the SNMP
(Simple Network Management Protocol) for the network management. SNMP
is a great protocol when it comes to monitoring the devices, especially when the
information is limited. But SNMP wasn’t good enough to be used for
configuration purposes. Some of the requirements that operators listed that they
wanted were:

 Easy to use technology.

 Clear differentiation between configuration and operational data.
 Compatibility with extensive network services (like VPNs and IPTV)
 In the event of failure, configuration transactions, and simple rollback
should be supported.
 Standardized representation of configurations between different vendors.

How does NETCONF works?

It includes at least one network management system (NMS) that manages
network devices. The following diagram depicts Network Configuration
Protocol’s fundamental network architecture.

There are two main parts to the NETCONF framework: the client and the
server.

The following are some of the services that a client may offer:

 Uses Network Configuration Protocol to control network hardware.

 To get information about or change the value of a parameter, RPC
requests are sent to a NETCONF server.
 Recognizes a controlled device’s state from the alarms and events sent by
the device’s NETCONF server.

A Network Configuration Protocol client will send a request to the server,

which will then analyse the request before responding to the client.

 The NETCONF server receives a request from a NETCONF client,

analyses the request, and returns a response to the client.
 Whenever a problem or other event occurs on a managed device, the
Network Configuration Protocol server will use the notification
mechanism to deliver an alert or event to the client.

NETCONF Structure

As can be seen in the illustration, Network Configuration Protocol may be

conceptually divided into four layers.
 1. The Secure Transport layer ensures that NETCONF messages are
reliably delivered and in the correct sequence. SSH is one example of a
secure transport protocol that may be used to comply with it. Required
functionality includes NETCONF via SSH support.
2. The Network Configuration Protocol requests and replies are formatted
using an RPC-like communication model supplied by the Messages
layer, which rides on top of the Secure Transport layer to provide a
secure and stable connection. Data is gathered from the network and
organized into NETCONF messages in order to be transmitted up to the
Operations layer. The Operations layer frames RPCs for transmission to
the Secure Transport layer in the network’s transmit direction.
3. The Operations layer supplies the collection of management primitives
needed to access and alter NE information. Its operations are defined in
the operation layer.
4. NE data is represented by YANG modules and stored in the Content
layer. YANG modules create a clean separation between NE
configuration data and NE operational data, making administration much
simpler.

Before we discuss the abilities of Network Configuration Protocol, let’s quickly

understand the difference between Configurational and Operational data.
Everything which you can write on a device is configuration data, for
example, interface state and the IP address assigned to the interface; on the
other hand, Operational data, also known as read-only status data, is non-
configurational, for example, the number of packets that were dropped, number
of packets sent or received, or overall interface traffic statistics.
NETCONF Operations

It provides a set of operations that can be used to manage the device (depending
on the NETCONF compatibility of the device.). Actions are performed upon the
network device (and its data stores) via a set of operations.

Let’s understand these operations one by one.

<get> To fetch operational data from the device.

<get-config> To fetch the configurational data from the device.

<edit-config> To push/load configuration on the device.

<copy-config> To replace a set of configurations with new configurations.

<delete-config> To delete a set of configurations.

To copy the candidate configurations to running

<commit>
configurations.

<lock>/<unlock> To lock or unlock the configurations.

<close-session> To close the session.

<kill-session> To forcefully terminate the session.

The operation <edit-config> can be used with different attributes based on the
requirement. The several supported attributes are:

 Merge: This is the default attribute used by the operation and is used to
merge the configurations with the pre-existing configurations.
 Replace: This is used to replace the whole set of configurations with new
ones.
 Create: The attribute create is used to add the configuration data only if
the configuration data doesn’t exist on the device. If it exists, then an
error message is returned.
 Delete: When this attribute has been used, the defined configuration set is
deleted from the device.
Key NETCONF Capabilities

NETCONF is a network management protocol that provides several key

capabilities for configuring and monitoring network devices. Some of these
capabilities are:

 The ability to edit and validate device configuration data in a structured

and consistent way, using XML or JSON encoding and YANG data
models.
 The ability to retrieve operational state data from devices, such as
interface statistics, routing tables, or device status.
 The ability to invoke remote procedure calls (RPCs) on devices, such as
rebooting, testing, or applying changes.
 The ability to subscribe to notifications from devices, such as alarms,
events, or telemetry data.
 The ability to use secure transport protocols, such as SSH or TLS, for
authentication and encryption of Network Configuration Protocol
messages.

YANG
YANG is a data modeling language. The YANG model defines a hierarchical
data structure, which can be used for operations based on network configuration
management protocols (such as NETCONF/RESTCONF). The operations
include configuration, status data, remote procedure calls (RPCs), and
notifications. Compared with the SNMP model MIB, YANG is more
hierarchical, can distinguish between configurations and status, and provides
high extensibility.

Overview of the YANG Model

Positioned as a next-generation modeling language, YANG is used to build data
models.
It is used to model the configuration data, status data, RPCs, and notifications
used by network configuration management protocols (such as NETCONF and
RESTCONF). YANG generates YANG models (also called YANG files) by
describing data structures, data integrity constraints, and data operations.
YANG is defined in the following RFC standards:
 RFC 6020: In 2010, the Internet Engineering Task Force (IETF)
defined YANG for the first time. YANG is a data modeling language
for NETCONF.
 RFC 6021: In 2010, the IETF defined various data types commonly
used in network communication technologies. This allows us to import
 and use predefined network data types without redefining them when
building YANG models.
 RFC 6991: In 2013, the IETF added data types to the YANG model on
the basis of RFC 6021.
 RFC 7950: In 2016, the IETF released YANG1.1 to correct ambiguity
and defects in the initial version (RFC 6020).
Through ongoing standardization, YANG is gradually becoming a mainstream
data description specification in the industry. Standards organizations, vendors,
carriers, and OTTs all define their own YANG models. As shown in the
following figure, the YANG model is integrated on the devices, which function
as the servers. Network administrators can use NETCONF or RESTCONF to
centrally manage, configure, and monitor various YANG-capable network
devices, simplifying network O&M and reducing O&M costs.

Why Do We Use YANG?

In 2002, the Internet Architecture Board (IAB) called attention to SNMP's
disadvantages in configuration management, triggering the emergence of
NETCONF. Although the NETCONF protocol is standardized, the data content
is not. As a result, a better modeling language — YANG — was developed,
making the data model simpler and easier to understand.
Compared with the SNMP model MIB, YANG is more
hierarchical, can distinguish between configurations and status, and provides
high extensibility.
The following uses part of the if-mib file as an example. The MIB is a tiled
table, in which all elements of an IfEntry are arranged side by side. This makes
it impossible to distinguish between configuration data and status data.
The labels yang-version, namespace, organization, etc are known as
"statements" in YANG terminology. Let's go over the function of each
statement below.

 yang-version - Identifies the YANG language specification that the

module will conform to. We'll ensure our module conforms to
YANG 1.1 which is defined in RFC 7950.

 namespace - This is an XML namespace that must be unique for the

module. We used a URL but you can use a URN, URI or any other
unique identifier here. The namespace specified here must match the
namespace on any XML objects which conform to our YANG
model.

 prefix - A short and unique string to identify our module. This prefix
may be used in other YANG modules to import definitions contained
in this one.

 organization - A string identifying the entity responsible for the

module.

 contact - Contact details for the entity responsible for the module.

 description - A description of the module.

 revision - Used for version control. Each edit to a YANG module

will add a new revision statement detailing the changes in sub-
statements.

IoT Systems Management with NETCONF-YANG

• Management System

• Management API

• Transaction Manager

• Rollback Manager

• Data Model Manager

 • Configuration Validator

• Configuration Database

• Configuration API

• Data Provider AP

IOT PLATFORM DESIGN METHODOLOGY

Designing IoT systems can be a complex and challenging task as these systems
involve interactions between various components. A wide range of choices are
available for each component. IoT designers often tend to design the system
keeping specific products in mind.

We will look at a generic design methodology which is independent of specific

product, service or programming language. IoT systems designed with this
methodology will have reduced design time, testing time, maintenance time,
complexity and better interoperability.
The steps involved in the designing of an IoT system or application can be
summarized as shown in the below figure:
Let’s discuss all the ten steps in the IoT design methodology with the help of a
case study: Home Automation System.

1. Purpose and Requirements Specification

First step is to define the purpose and requirements of the system. In this step,
the system purpose, behavior and requirements are captured. Requirements can
be:

 Data collection requirements

 Data analysis requirements
 System management requirements
 Security requirements
 User interface requirements
2. Process Specification

The use cases of the IoT system are formally described based on or derived
from the purpose and requirements specifications. The process specification for
home automation system is as shown below.

3. Domain Model Specification

The domain model describes the main concepts, entities and objects in the
domain of the IoT system to be designed. Domain model defines the attributes
of the objects and relationships between objects. The domain model is
independent of any specific technology or platform.

Using domain model, system designers can get an understanding of the IoT
domain for which the system is to be designed. The entities, objects and
concepts defined in the domain model of home automation system include the
following:

• The physical identifiable objects in the environment

ysical • IoT system provides information about the physical entity (using
Entity sensors) or performs actuation upon the physical entity
 • Virtual entity is a representation of the physical entity in the
Virtual digital world
Entity • For every physical entity there is a virtual entity

• Devices provide a medium for interaction between physical and

virtual entities
Device • Devices are used to gather information from or perform actuation
on physical entities

• Resources are software components which can be either on-

device or network-resources
• On-device resources are hosted on the device and provide sensing
Resource or actuation (eg: operating system)
• Network-resources include software components that are
available on the network (eg: database)

• Services provide an interface for interacting with the physical

entity
Service • Services access resources to perform operations on physical
entities

The domain model specification diagram for home automation system is as

shown in the below figure.
4. Information Model Specification

Information model defines the structure of all the information in the IoT system.
Does not describe how the information is stored and represented. To define the
information model, we first list the virtual entities. Later more details like
attributes and relationships are added. The information model specification for
home automation system is as shown below:
5. Service Specifications

The service specification defines the following:

 Services in the system

 Service types
 Service inputs/output
 Service endpoints
 Service schedules
 Service preconditions
 Service effects

For each state and attribute in the process specification and information model,
we define a service. Services either change the state of attributes or retrieve
their current values. The service specification for each state in home automation
systems are as shown below:
6. IoT Level Specification

Based on the requirements we will choose the IoT application deployment level.
The deployment level for home automation system is shown in the below
figure.
7. Functional View Specification

The functional view defines the functions of the IoT systems grouped into
various functional groups. Each functional group provides functionalities for
interacting with concepts in the domain model and information related to the
concepts.

The functional groups in a functional view include: Device, Communication,

Services, Management, Security, and Application. The functional view
specification for home automation system is shown in the below figure:
8. Operational View Specification

In this step, various options related to the IoT system deployment and operation
are defined, such as:

 Service hosting options

 Storage options

 Device options

 Application hosting options

The options chosen for home automation system are as shown in the below
figure.
9. Device and Component Integration

In this step the devices like sensors, computing devices and other components
are integrated together. The interconnection of different components in our
home automation system are as shown in the figure given below.
10. Application Development

Using all the information from previous steps, we will develop the application
(code) for the IoT system. The application interface for home automation
system is shown below.

M2M HIGH-LEVEL ETSI ARCHITECTURE

high-level architecture for Machine-to-Machine (M2M) communication as
defined by the European Telecommunications Standards Institute (ETSI).
1. Device and Gateway Domain:
o This domain encompasses the functional and topological aspects
associated with physical infrastructure, including M2M
Devices and Gateways.
o M2M Devices are the focal points in M2M scenarios. For instance,
a device equipped with a temperature sensor falls into this
category. Each M2M Device contains M2M
Applications and M2M Service Capabilities.
o These devices connect to the Network Domain either directly or
via an M2M Gateway:
 Direct connection: An M2M Device can independently
handle registration, authentication, authorization,
management, and provisioning within the Network Domain.
It also possesses the necessary physical layer to
communicate directly with the Access Network.
 Through M2M Gateways: Some M2M devices lack the
compatible physical layer for direct communication with the
Access Network. In such cases, an M2M Gateway acts as a
proxy, performing authentication, authorization,
management, and provisioning on behalf of the device.
Multiple M2M Gateways may be involved.
 o M2M Area Network: This local area network (LAN) or Personal
Area Network (PAN) connects M2M Devices and M2M Gateways.
Common networking technologies include IEEE 802.15.1
(Bluetooth), IEEE 802.15.4 (ZigBee, IETF
6LoWPAN/ROLL/CoRE), MBUS, KNX (wired or wireless), and
PLC.
o M2M Gateway: These devices provide connectivity for M2M
Devices within an M2M Area Network, bridging the gap between
the Device and Gateway Domain and the Network Domain. M2M
Gateways also host M2M Applications and Service Capabilities,
and they may serve other legacy devices not directly visible to the
Network Domain.
2. Network Domain:
o This domain facilitates communication between the Device and
Gateway Domain and the Core Network.
o Key components include:
 Access Network: The network enabling communication
between devices in the Device and Gateway Domain and the
Core Network. Access Network technologies include fixed
(xDSL, HFC) and wireless (Satellite, GERAN, UTRAN, E-
UTRAN, W-LAN, WiMAX).
 Core Network: Examples of Core Networks are 3GPP Core
Network and ETSI TISPAN Core Network. Core Networks
provide IP connectivity, service control, and network control
functions.

This high-level architecture is a combination of both a functional and

topological view showing some functional groups (FG) clearly associated with
pieces of physical infrastructure (e.g. M2M Devices, Gateways).  There are
two main domains, a network domain and a device and gateway domain.  The
boundary between these conceptually separated domains is the topological
border between the physical devices and gateways and the physical
communication infrastructure (Access network).
The Device and Gateway Domain contains the following functional/topological
entities:  M2M Device:

 This is the device of interest for an M2M scenario, for example, a device with
a temperature sensor.

 An M2M Device contains M2M Applications and M2M Service Capabilities.

 An M2M device connects to the Network Domain either directly or through an

M2M Gateway:

• Direct connection:

The M2M Device is capable of performing registration, authentication,

authorization, management, and provisioning to the Network Domain. Direct
connection also means that the M2M device contains the appropriate physical
layer to be able to communicate with the Access Network. • Through one or
more M2M Gateway: M2M device does not have the appropriate physical layer,
compatible with the Access Network technology, and therefore it needs a
network domain proxy.

Moreover, a number of M2M devices may form their own local M2M Area
Network that typically employs a different networking technology from the
Access Network. The M2M Gateway acts as a proxy for the Network Domain
and performs the procedures of authentication, authorization, management, and
provisioning.

An M2M Device could connect through multiple M2M Gateways. 

M2M Area Network:

 This is a local area network (LAN) or a Personal Area Network (PAN) and
provides connectivity between M2M Devices and M2M Gateways.

 Typical networking technologies are IEEE 802.15.1 (Bluetooth), IEEE

802.15.4 (ZigBee, IETF 6LoWPAN/ROLL/CoRE), MBUS, KNX (wired or
wireless) PLC, etc. 

M2M Gateway:

 The device that provides connectivity for M2M Devices in an M2M Area
Network towards the Network Domain.

 The M2M Gateway contains M2M Applications and M2M Service

Capabilities.

 The M2M Gateway may also provide services to other legacy devices that are
not visible to the Network Domain. The Network Domain contains the
following functional/topological entities: 

Access Network:

 This is the network that allows the devices in the Device and Gateway
Domain to communicate with the Core Network.

 Example Access Network Technologies are fixed (xDSL, HFC) and wireless
(Satellite, GERAN, UTRAN, E-UTRAN W-LAN, WiMAX). 

Core Network:

 Examples of Core Networks are 3GPP Core Network and ETSI TISPAN
Core Network. It provides the following functions

: • IP connectivity.

• Service and Network control.

• Interconnection with other networks.

• Roaming. 

M2M Service Capabilities:

 These are functions exposed to different M2M Applications through a set of

open interfaces.

 These functions use underlying Core Network functions, and their objective is
to abstract the network functions for the sake of simpler applications. 

M2M Applications:

 These are the specific M2M applications (e.g. smart metering) that utilize the
M2M Service Capabilities through the open interfaces.

 Network Management Functions:

 The application logic can be deployed on a Device (Device Application,
DA), Gateway (Gateway Application, GA) or Network (Network
Application, NA).
 The SCL (Service Capability Layer ) is a collection of functions that are
exposed through the open interfaces or reference points mIa, dIa, and mId
(ETSI M2M TC 2013b).
 Because the main topological entities that SCL can deploy are the Device,
Gateway, and Network Domain, there are three types of SCL: DSCL
(Device Service Capabilities Layer), GSCL (Gateway Service
Capabilities Layer), and NSCL (Network Service Capabilities Layer).
 SCL functions utilize underlying networking capabilities through
technology-specific interfaces.

IETF ARCHITECTURE FOR IOT

 Internet Engineering Task Force architecture

 An RD plays the role of a rendezvous mechanism for CoAP Server
resource descriptions, in other words, for devices to publish the
descriptions of the available resources and for CoAP clients to locate
resources that satisfy certain criteria such as specific resource types.
(e.g. temperature sensor resource type).
 Resource Directory is a rendezvous mechanism for CoAP Server
resource descriptions, a Mirror Server is a rendezvous mechanism for
CoAP Server resource presentations.
 A Mirror Server is a CoAP Server resource (/ms) that maintains a list of
resources and their cached representations (Figure 6.8b).
 A CoAP Server registers its resources to the Mirror Server, and upon
registration a new mirror server resource is created on the Mirror Server
with a container (mirror representation) for the original server
representation.
 The original CoAP Server updates the mirror representation either
periodically or when the representation changes.
 A CoAP Client that retrieves the mirror representation receives the latest
updated representation from the original CoAP Server. The Mirror
Server is useful when the CoAP Server is not always available for direct
access.
 An example of such a CoAP Server is one that resides on a real device
whose communication capabilities are turned off in order to preserve
energy, e.g. batterypowered radio devices whose radio and/or processor
goes to sleep mode.
 Typically, a Mirror Server is hosted on a device or machine that is
always available.
 The IETF CoRE workgroup has included the fundamentals of a
mapping process between HTTP and CoAP in the IETF CoAP
specification as well as a set of guidelines for the interworking between
HTTP and CoAP.
 The main is the different transport protocols used by the HTTP and
CoAP: HTTP uses TCP while CoAP uses UDP.
 The guidelines focus more on the HTTP-to-CoAP proxy and
recommend addressing schemes (e.g. how to map a CoAP resource
address to an HTTP address), mapping between HTTP and CoAP
response codes, mapping between different media types carried in the
HTTP/CoAP payloads, etc.
 HTTP Client sends an HTTP request to a CoAP server (Figure 6.9a)
through a Gateway Device hosting an HTTP-CoAP Cross Proxy.
 The Gateway Device connects to the Internet via an Ethernet cable using
a LAN, and on the CoAP side the CoAP server resides on a
Sensor/Actuator (SAN) based on the IEEE 802.15.4 PHY/MAC.
 The HTTP request needs to include two addresses, one for reaching the
Cross Proxy and one for reaching the specific CoAP Server in the SAN.
 The request is in plain text format and contains the method (GET). It
traverses the IPv4 stack of the client, reaches the gateway, traverses the
IPv4 stack of the gateway and reaches the Cross proxy.
 The request is translated to a CoAP request (binary format) with a
destination CoAP resource coap://s.coap.example.com/foo, and it is
dispatched in the CoAP stack of the gateway, which sends it over the
SAN to the end device.
 A response is sent from the end device and follows the reverse path in
the SAN in order to reach the gateway.
 The Cross proxy translates the CoAP response code to the
corresponding HTTP code, transforms the included media, creates the
HTTP response, and dispatches it to the HTTP client.
 OGC (OPEN GEOSPATIAL CONSORTIUM) ARCHITECTURE

 The Open Geospatial Consortium (OGC 2013) is an international

industry consortium of a few hundred companies, government agencies,
and universities that develops publicly available standards that provide
geographical information support to the Web, and wireless and location-
based services.
 OGC includes, among other working groups, the Sensor Web Enablement
(SWE) (OGC SWE 2013) domain working group, which develops
standards for sensor system models (e.g. Sensor Model Language, or
SensorML), sensor information models (Observations & Measurements,
or O&M), and sensor services that follow the Service-Oriented
Architecture (SOA) paradigm.
 The functionality that is targeted by OGC SWE includes:
 • Discovery of sensor systems and observations that meet an
application’s criteria.

• Discovery of a sensor’s capabilities and quality of measurements.

• Retrieval of real-time or time-series observations in standard encodings.

• Tasking of sensors to acquire observations.

• Subscription to, and publishing of, alerts to be issued by sensors or

sensor services based upon certain criteria.

 OGC SWE includes the following standards:

• SensorML and Transducer Model Language (TML), which include a

model and an XML schema for describing sensor and actuator systems
and processes; for example, a system that contains a temperature sensor
measuring temperature in Celsius, which also involves a process for
converting this measurement to a measurement with Fahrenheit units.

• Observations and Measurements (O&M), which is a model and an

XML schema for describing the observations and measurements for a
sensor (Observations and Measurements, O&M).

• SWE Common Data model for describing low-level data models (e.g.
serialization in XML) in the messages exchanged between OGC SWE
functional entities.

• Sensor Observation Service (SOS), which is a service for requesting,

filtering, and retrieving observations and sensor system information. This
is the intermediary between a client and an observation repository or near
real-time sensor channel.

• Sensor Planning Service (SPS), which is a service for applications

requesting a user-defined sensor observations and measurements
acquisition. This is the intermediary between the application and a sensor
collection system.

• PUCK, which defines a protocol for retrieving sensor metadata for

serial port (RS232) or Ethernet-enabled sensor devices.
 OGC follows the SOA paradigm, there is a registry (CAT) that maintains
the descriptions of the existing OGC services, including the Sensor
Observation and Sensor Planning Services.
 Upon installation the sensor system using the PUCK protocol retrieves
the SensorML description of sensors and processes, and registers them
with the Catalog so as to enable the discovery of the sensors and
processes by client applications.
 The Sensor System also registers to the SOS and the SOS registers to the
Catalog.
 A client application #1 requests from the Sensor Planning Service that
the Sensor System be tasked to sample its sensors every 10 seconds and
publish the measurements using O&M and the SWE Common Data
model to the SOS.
 Another client application #2 looks up the Catalog, aiming at locating an
SOS for retrieving the measurements from the Sensor System.
 The application receives the contact information of the SOS and requests
from the sensor observations from the specific sensor system from the
SOS.
 As a response, the measurements from the sensor system using O&M and
the SWE Common Data model are dispatched to the client application.
 The main objective of the OGC standards is to enable data, information,
and service interoperability.
 SERVICE ORIENTED ARCHITECTURE

Service-Oriented Architecture (SOA) is a stage in the evolution of application

development and/or integration. It defines a way to make software components
reusable using the interfaces.
Formally, SOA is an architectural approach in which applications make use of
services available in the network. In this architecture, services are provided to
form applications, through a network call over the internet. It uses common
communication standards to speed up and streamline the service integrations
in applications. Each service in SOA is a complete business function in itself.
The services are published in such a way that it makes it easy for the
developers to assemble their apps using those services. Note that SOA is
different from microservice architecture.
 SOA allows users to combine a large number of facilities from
existing services to form applications.
 SOA encompasses a set of design principles that structure system
development and provide means for integrating components into a
coherent and decentralized system.
 SOA-based computing packages functionalities into a set of
interoperable services, which can be integrated into different
software systems belonging to separate business domains.
The different characteristics of SOA are as follows :
Provides interoperability between the services.
o Provides methods for service encapsulation, service discovery, service
composition,
service reusability and service integration.
o Facilitates QoS (Quality of Services) through service contract based on
Service Level
Agreement (SLA).
o Provides loosely couples services.
o Provides location transparency with better scalability and availability.
o Ease of maintenance with reduced cost of application development and
deployment.
There are two major roles within Service-oriented Architecture:
1. Service provider: The service provider is the maintainer of the
service and the organization that makes available one or more
services for others to use. To advertise services, the provider can
publish them in a registry, together with a service contract that
specifies the nature of the service, how to use it, the requirements for
the service, and the fees charged.
 2. Service consumer: The service consumer can locate the service
metadata in the registry and develop the required client components
to bind and use the service.

Services might aggregate information and data retrieved from other services or
create workflows of services to satisfy the request of a given service
consumer. This practice is known as service orchestration Another important
interaction pattern is service choreography, which is the coordinated
interaction of services without a single point of control.
Components of SOA:

Guiding Principles of SOA:

1. Standardized service contract: Specified through one or more
service description documents.
2. Loose coupling: Services are designed as self-contained
components, maintain relationships that minimize dependencies on
other services.
 3. Abstraction: A service is completely defined by service contracts
and description documents. They hide their logic, which is
encapsulated within their implementation.
4. Reusability: Designed as components, services can be reused more
effectively, thus reducing development time and the associated costs.
5. Autonomy: Services have control over the logic they encapsulate
and, from a service consumer point of view, there is no need to know
about their implementation.
6. Discoverability: Services are defined by description documents that
constitute supplemental metadata through which they can be
effectively discovered. Service discovery provides an effective
means for utilizing third-party resources.
7. Composability: Using services as building blocks, sophisticated and
complex operations can be implemented. Service orchestration and
choreography provide a solid support for composing services and
achieving business goals.
Advantages of SOA:
 Service reusability: In SOA, applications are made from existing
services. Thus, services can be reused to make many applications.
 Easy maintenance: As services are independent of each other they
can be updated and modified easily without affecting other services.
 Platform independent: SOA allows making a complex application
by combining services picked from different sources, independent of
the platform.
 Availability: SOA facilities are easily available to anyone on
request.
 Reliability: SOA applications are more reliable because it is easy to
debug small services rather than huge codes
 Scalability: Services can run on different servers within an
environment, this increases scalability
Disadvantages of SOA:
 High overhead: A validation of input parameters of services is done
whenever services interact this decreases performance as it increases
load and response time.
 High investment: A huge initial investment is required for SOA.
 Complex service management: When services interact they
exchange messages to tasks. the number of messages may go in
millions. It becomes a cumbersome task to handle a large number of
messages.

Characteristics of SOA

The services have the following characteristics:

 o They are loosely coupled.
o They support interoperability.
o They are location-transparent
o They are self-contained.

Components of service-oriented architecture

The service-oriented architecture stack can be categorized into two parts -

functional aspects and quality of service aspects.

Functional aspects

The functional aspect contains:

 o Transport - It transports the service requests from the service consumer to
the service provider and service responses from the service provider to
the service consumer.
o Service Communication Protocol - It allows the service provider and the
service consumer to communicate with each other.
o Service Description - It describes the service and data required to invoke
it.
o Service - It is an actual service.
o Business Process - It represents the group of services called in a particular
sequence associated with the particular rules to meet the business
requirements.
o Service Registry - It contains the description of data which is used by
service providers to publish their services.

Quality of Service aspects

The quality of service aspects contains:

o Policy - It represents the set of protocols according to which a service

provider make and provide the services to consumers.
o Security - It represents the set of protocols required for identification and
authorization.
o Transaction - It provides the surety of consistent result. This means, if we
use the group of services to complete a business function, either all must
complete or none of the complete.
o Management - It defines the set of attributes used to manage the services.

IOT REFERENCE ARCHITECTURE

There are several reasons why a reference architecture for IoT is a good thing: •
IoT devices are inherently connected – we need a way of interacting with them,
often with firewalls, network address translation (NAT) and other obstacles in
the way. • There are billions of these devices already and the number is growing
quickly; we need an architecture for scalability. In addition, these devices are
typically interacting 24x7, so we need a highly-available (HA) approach that
supports deployment across data centers to allow disaster recovery (DR).

The devices may not have UIs and certainly are designed to be “everyday”
usage, so we need to support automatic and managed updates, as well as being
able to remotely manage these devices. • IoT devices are very commonly used
for collecting and analyzing personal data. A model for managing the identity
and access control for IoT devices and the data they publish and consume is a
key requirement.

REQUIREMENTS FOR A REFERENCE ARCHITECTURE

There are some specific requirements for IoT that are unique to IoT devices and
the environments that support them, e.g. many requirements emerge from the
limited formfactors and power available to IoT devices.

Other requirements come from the way in which IoT devices are manufactured
and used. The approaches are much more like traditional consumer product
designs than existing Internet approaches. Of course there are a number of
existing best practices for the server-side and Internet connectivity that need to
be remembered and factored in.

We can summarize the overall requirements into some key categories:

• Connectivity and communications

• Device management

• Data collection, analysis, and actuation

• Scalability

• Security

• HA

• Predictive analysis

• Integration

3.1 CONNECTIVITY AND COMMUNICATIONS

Existing protocols, such as HTTP, have a very important place for many
devices. Even an 8-bit controller can create simple GET and POST requests and
HTTP provides an important unified (and uniform) connectivity. However, the
overhead of HTTP and some other traditional Internet protocols can be an issue
for two main reasons. Firstly, the memory size of the program can be an issue
on small devices. However, the bigger issue is the power requirements. In order
to meet these requirements, we need a simple, small and binary protocol. We
will look at this in more detail below. We also require the ability to cross
firewalls.

In addition, there are devices that connect directly and those that connect via
gateways. The devices that connect via a gateway potentially require two
protocols: one to connect to the gateway, and then another from the gateway to
the cloud. Finally, there is obviously a requirement for our architecture to
support transport and protocol bridging, e.g. we may wish to offer a binary
protocol to the device, but allow an HTTP-based API to control the device that
we expose to third parties.

3.2 DEVICE MANAGEMENT

While many IoT devices are not actively managed, this is not necessarily ideal.
We have seen active management of PCs, mobile phones, and other devices
become increasingly important, and the same trajectory is both likely and
desirable for IoT devices. What are the requirements for IoT device
management?

The following list covers some widely desirable requirements:

• The ability to disconnect a rogue or stolen device

• The ability to update the software on a device

• Updating security credentials

• Remotely enabling or disabling certain hardware capabilities

• Locating a lost device

• Wiping secure data from a stolen device

• Remotely re-configuring Wi-Fi, GPRS, or network parameters The list is not

exhaustive, and conversely covers aspects that may not be required or possible
for certain devices.

3.3 DATA COLLECTION, ANALYSIS, AND ACTUATION

A few IoT devices have some form of UI, but in general IoT devices are
focused on offering one or more sensors, one or more actuators, or a
combination of both. The requirements of the system are that we can collect
data from very large numbers of devices, store it, analyze it, and then act upon
it.
The reference architecture is designed to manage very large numbers of devices.
If these devices are creating constant streams of data, then this creates a
significant amount of data. The requirement is for a highly scalable storage
system, which can handle diverse data and high volumes.

The action may happen in near real time, so there is a strong requirement for
real-time analytics. In addition, the device needs to be able to analyze and act on
data. In some cases this will be simple, embedded logic. On more powerful
devices we can also utilize more powerful engines for event processing and
action.

3.4 SCALABILITY

Any server-side architecture would ideally be highly scalable, and be able to

support millions of devices all constantly sending, receiving, and acting on data.
However, many “high-scalability architectures” have come with an equally high
price – both in hardware, software, and in complexity. An important
requirement for this architecture is to support scaling from a small deployment
to a very large number of devices.

Elastic scalability and the ability to deploy in a cloud infrastructure are

essential. The ability to scale the serverside out on small cheap servers is an
important requirement to make this an affordable architecture for small
deployments as well as large ones.

3.5 SECURITY

Security is one of the most important aspects for IoT. IoT devices are often
collecting highly personal data, and by their nature are bringing the real world
onto the Internet (and viceversa).

This brings three categories of risks:

• Risks that are inherent in any Internet system, but that product/IoT designers
may not be aware of

• Specific risks that are unique to IoT devices

• Safety to ensure no harm is caused by, for instance, misusing actuators

The first category includes simple things such as locking down open ports on
devices (like the Internet-attached fridge that had an unsecured SMTP server
and was being used to send spam).
The second category includes issues specifically related to IoT hardware, e.g.
the device may have its secure information read. For example, many IoT
devices are too small to support proper asymmetric encryption.

Another specific example is the ability for someone to attack the hardware to
understand security. Another example - university security researchers who
famously reverse-engineered and broke the Mifare Classic RFID card solution3.
These sort of reverse engineering attacks are an issue compared with pure web
solutions where there is often no available code to attack (i.e. completely server-
side implementation).

Two very important specific issues for IoT security are the concerns about
identity and access management. Identity is an issue where there are often poor
practices implemented. For example, the use of clear text/ Base64 encoded user
IDs/passwords with devices and machine-to-machine (M2M) is a common
mistake. Ideally these should be replaced with managed tokens such as those
provided by OAuth/OAuth2.

Another common issue is to hard-code access management rules into either

client- or server-side code. A much more flexible and powerful approach is to
utilize models such as “Attribute Based Access Control” and “Policy Based
Access Control”. The most well known of these approaches is that provided by
the XACML standard5. Such approaches remove access control decisions from
hard-coded logic and externalize them into policies, which enabled the
following:

 More powerful and appropriate decisions;

• Can potentially be based on contexts such as location, or which network

is being used, or the time of day;

• Access control can be analyzed and audited; and

• Policies can be updated and changed, even dynamically, without

recoding or modifying devices.

THE ARCHITECTURE

The reference architecture consists of a set of components. Layers can be

realized by means of specific technologies, and we will discuss options
for realizing each component. There are also some cross-cutting/vertical
layers such as access/identity management.
The layers are

• Client/external communications - Web/Portal, Dashboard, APIs

• Event processing and analytics (including data storage)

• Aggregation/bus layer – ESB and message broker

• Relevant transports - MQTT/HTTP/XMPP/CoAP/AMQP, etc.

• Devices

The cross-cutting layers are

• Device manager

• Identity and access management