UNIT 2

MIDDLEWARE AND PROTOCOLS OF IOT

IOT ECOSYSTEM OVERVIEW

In IoT ecosystems, computing interactions are driven by smart objects, which are system entities
considered the main building blocks of the IoT environment. By putting intelligence into
everyday objects (i.e., dedicated embedded systems into everyday physical devices), these
devices are turned into smart objects able not only to collect information from the environment
and interact/control the things of the physical world, but also to be interconnected to each other
through the Internet to autonomously exchange pervasive data and information. The expected
huge number of interconnected devices and the significant amount of available data, open new
opportunities to create smart services that will bring tangible benefits to the society,
environment, economy, and individual citizens.

Let us consider the “city ecosystem” as an example of how the city of the future (i.e the Smart
City) will look like in the coming years. Indeed, a smart city is a kind of city that should be able
to operate simultaneously on two representation levels, physical and virtual, respectively. These
abstractions should imply in the provision of intelligent solutions that ensure efficiency at
multiple levels, aiming basically to: (i) a more aware and optimized usage of the resources of the
city, (ii) a minimization of environmental impact (e.g.,by reducing CO2 emissions), and (iii) an
increase in the life quality of citizens’ in terms of safety, health, and wellness. This smart
capability is desired due to the fact that, today, half of the global population is concentrated in
the cities, and hence, is increasingly consuming the city’s resources (e.g., light, water) every day.
Besides, quality, sustainability, and security are crucial requirements and unavoidable issues for
the city
HORIZONTAL ARCHITECTURE APPROACH FOR IOT SYSTEMS

A systemic implementation of IoT ecosystems is usually based on a layered architecture style,

which can range from data acquisition layer (i.e., Perception layer) at the bottom, to application
layer at the top as shown.In this kind of architecture, layers from the bottom usually contribute to
devices integration and data capturing, while layers from the top are responsible for data
distribution and utilization by IoT applications.

Perception layer: it refers to procedures for sensing the physical environment, collecting
real time data, and reconstructing a general perception of it in the virtual world (i.e., in the
system logical domain). Technologies such as RFID and sensors provide identification of
physical objects and sensing of physical parameters. While technologies such as IEEE 802.15.4
and Bluetooth are responsible for data collecting.

Transportation layer: it includes mechanisms to deliver the collected data to applications and
to different external servers. Methods are therefore required for accessing the network through
gateways and heterogeneous technologies (e.g., wired, wireless, satellite), as well as for
addressing and/or routing.
Applications layer: it deals with processing and analyzing information flows, forwarding data to
applications and services, and providing feedbacks to control applications. In addition, it is
responsible for critical functions such as device discovery, device management, data filtering,
data aggregation, semantic analysis, and information utilization/distribution. Indeed, these
functions are essential for IoT ecosystems, and as such, must be handled by an IoT middleware
platform.

Fig. IoT systems architecture overiew

SOA BASED IOT MIDDLEWARE

A service-oriented architecture (SOA) is a set of principles and methodologies for designing and
developing software in the form of interoperable services, usually over the Internet. Services
comprise unassociated, loosely coupled units of functionality that have no calls to each other
embedded in them.

Fig.SOA-based IoT middleware architecture

Service-oriented architecture consists of components which are implemented as independent

services which can be dynamically bonded and orchestrated, and which possess loosely coupled
configurations, while the communication between them uses messages. Orchestrating means a
process which predefines an order of calling the services (in sequences and in parallel) and the
data and message exchanges.

In IoT ecosystems, computation, storage, data management, and communication services are
intended to be high ubiquitous and distributed. Furthermore, the entities of the environment
(people, things/objects, platforms, and surrounding spaces) are intended to create to IoT
applications a highly decentralized common pool of resources, which must be interconnected by
a dynamic network of networks. The smart integration of both intended services and entities
represents the real ecosystem of the IoT. In this context, middleware for IoT is considered an
important building block for the provision of IoT services, which are extremely desired to be
highly pervasive and distributed. Indeed, middleware is an IoT platform intended to be a service
of services to IoT ecosystems.

IoT middleware is a software layer or a set of sub-layers interposed between technological

(perception and transportation layers) and application layers as shown in fig.2.5. The
middleware’s ability to hide the details of different technologies is fundamental to exempt the
programmer from issues that are not directly pertinent to her/his focus, which is the development
of specific applications enabled by IoT infrastructures. In this way, IoT middleware has received
much attention in the last years due to its major role of simplify the development of application
and the integration of devices.

MIDDLEWARE ARCHITECTURE OF RFID

RFID networking shares a similar three-tiered communication architecture as shown in Figure

2.9. RFID readers are the gateways similar to MAN. Data from the readers go to the corporate
LAN and then are transmitted to the Internet as needed. However, just like the scenarios of M2M
and SCADA, most current RFID systems stop at the corporate LAN level and are IoT systems
only. RFID middleware (including the edge middleware or edge ware) is currently no doubt the
most well-defined, comprehensive, standardized middleware compared with the other three pillar
segments of IoT. Before 2004, an RFID middleware-based system was defined by EPC global,
which included.

• A format for the data called physical markup language (PML), based on XML

• An interface to the servers containing PML records

• A directory service called ONS (object naming service), analogous to the DNS.

Given a tag’s EPC, the ONS will provide pointers to the PML servers containing records related
to that tag. An example of commercial RFID middleware product is IBM’s WebSphere Sensor
Events. WebSphere Sensor Events delivers new and enhanced capabilities to create a robust,
flexible, and scalable platform for capturing new business value from sensor data. WebSphere
Sensor Events is the platform for integrating new sensor data, identifying the relevant business
events from that data using situational event processing, and then integrating and acting upon
those events with SOA business processes.

Fig. RFID architecture

• A format for the data called physical markup language (PML), based on XML

• An interface to the servers containing PML records

• A directory service called ONS (object naming service), analogous to the DNS. Given a tag’s EPC, the
ONS will provide pointers to the PML servers containing records related to that tag. An example of
commercial RFID middleware product is IBM’s WebSphere Sensor Events. WebSphere Sensor Events
delivers new and enhanced capabilities to create a robust, flexible, and scalable platform for capturing
new business value from sensor data. WebSphere Sensor Events is the platform for integrating new
sensor data, identifying the relevant business events from that data using situational event processing,
and then integrating and acting upon those events with SOA business processes.
WSN MIDDLEWARE ARCHITECTURE

WSN middleware is a kind of middleware providing the desired services for sensor based
pervasive computing applications that make use of a WSN and the related embedded operating
system or firmware of the sensor nodes. In most cases, WSN middleware is implemented as
embedded middleware on the node. It should be noted that while most existing distributed
system middleware techniques aim at providing transparency abstractions by hiding the context
information, WSN-based applications are usually required to be context aware.

A complete WSN middleware solution should include four major components: programming
abstractions, system services, runtime support, and quality of service (QoS) mechanisms.
Programming abstractions define the interface of the middleware to the application programmer.
System services provide implementations to achieve the abstractions. Runtime support serves as
an extension of the embedded operating system to support the middleware services. QoS
mechanisms define the QoS constraints of the system.

The system architecture of WSN middleware is shown in Middleware for WSN should also
facilitate development, maintenance, deployment, and execution of sensing-based applications.

Many challenges arise in designing middleware for WSN due to the following reasons:

• Limited power and resources, e.g., battery issues

• Mobile and dynamic network topology

• Heterogeneity, various kinds of hardware and network protocols

• Dynamic network organization, ad-hoc capability

WSN middleware is designed using a number of approaches such as virtual machine, mobile
agents, database based, message-oriented, and more. The WSN middleware is considered to be
“proactive” middleware in the middleware family.

Example middleware are as follows:

MagnetOS : power-aware, adaptive; the whole network appears as a single JVM, standard Java
programs are rewritten by MAGNET as network components, and components may then be
“injected” into the network using a power-optimized scheme.

IMPALA: modular; efficiency of updates and support dynamic applications; application

adaption with different profiles possible; energy efficient; used in the ZebraNet project for
wildlife monitoring.

Cougar: represents all sensors and sensor data in a relational database; control of sensors and
extracting data occurs through special SQL-like queries; decentralized implementation; message
passing based on controlled flooding.

SINA (system information networking architecture): based on a spreadsheet database

wherein the network is a collection of data sheets and cells are attributes; attribute-based naming;
queries performed in an SQL-like language; decentralized implementation based on clustering.

MQTT-S (Message Queue Telemetry Transport for Sensors, IBM): a publish/subscribe

messaging protocol for WSN, with the aim of extending the MQTT protocol beyond the reach of
TCP/IP infrastructures (non-TCP/ IP networks, such as Zigbee) for sensor and actuator solutions;
a commercial product.

MiLAN: This provides a mechanism that allows for the adaptation of different routing protocols;
sits on top of multiple physical networks; acts as a layer that allows network-specific plug-ins to
convert MiLAN commands to protocol-specific ones that are passed through the usual network
protocol stack; can continuously adapt to the specific features of whichever network is being
used in the communication.
 Fig.WSN middleware architecture

MIDDLEWARE ARCHITECTURE OF SCADA

The concept of MAN (M2M area network) was introduced in 3GPP/ETSI’s MTC (Machine
Type Communication) specification. This concept also applies to other pillar segments of IoT.
However, not all IoT applications will use a cellular network. In fact, most of the traditional
SCADA (Supervisory Control And Data Acquisition) applications have been using local wireline
networks for communications. The remote terminal units (RTUs), programmable logic
controllers (PLCs), or even process control systems (PCSs) communicate to the SCADA
middleware server via gateways (similar to MAN but all wired) that aggregate data from
different wired field buses. The SCADA system is accessed in a LAN environment (sometimes
xDSL, cable, WiFi, or WiMax can be used) before it is integrated into the corporate back office
system.
 SCADA middleware architecture

Central Data Control: CDC provides the software platform Integra, which utilizes data agents
to translate protocols from different building system components into single management
system.

Elutions: Its Control Maestro product has a SCADA heritage. SCADA may be best known for
industrial processes but is also deployed for infrastructure (water treatment plants, gas pipelines,
etc.) as well as facility systems. Control Maestro is web-based, uses human–machine interfaces
(HMI), and is able to deliver real-time and historical information.

Tridium: It provides the Niagara Java-based middleware framework and JACE hardware
controllers. The Niagara platform provides protocol translation for a range of systems and the
tools to build applications
MIDDLEWARE ARCHITECTURE OF M2M

Although the rest of the world may not agree, in the United States, machine-to-machine is a more
popular term than the Internet of Things, thanks perhaps to M2M Magazine’s efforts since 2004.
Two of the six pillars, remote monitoringand smart service, are features or functions of an IoT
sys tem rather than pillars. Conceptually, the terms M2M, RFID, and WSN are similar, but
when the underlying communi cation network is taken into consideration, they are quite
different segments. In this book, the term M2M is restricted to refer to device connectivity
technologies, products, and services relevant to the cellular wireless networks operated by
telecompanies. In fact, most of the M2M market research reports assume M2M modules are
simply just cellular modules. However, there is overlap between M2M and the consumer
electronics applications. The consumer electronics offerings include the following

◾ Personal navigation devices

◾ eReaders

◾ Digital picture frames

◾ People-tracking devices

◾ Pet-tracking devices

◾ Home security monitors

◾ Personal medical devices

Cellular networks were designed for circuit-switched voice. While they do a perfectly adequate
job for regular, packet switched data such as email and web browsing, they do not have the
requisite functionality for M2M applications. For example, the normal OSS (operation support
system) and BSS (business support system) are not designed for low-cost, mass handling of huge
amounts of similar subscriptions. That led to the development of service enablement middleware
platforms by specialized service providers
Perspectives and a Middleware Approach Toward 5G (COMPaaS
Middleware)

IoT middleware systems will have to support the requirements imposed by 5G which will result
in specific changes to allow the applications requirements demanded by 5G. illustrates a
possible system architecture for 5G-based IoT Middleware with two application examples: (a) a
“Healthcare Monitoring application” oriented to mission-critical services in a hospital (i.e., a
group of medical devices and sensors for patients monitoring that continuously route data
through redundant networks to guarantee delivery of priority data) (b) a non-critical example
focused on “Social Networks” as WhatsApp Messenger (i.e., a set of smart phones interacting
through the Internet with the middleware which acts as a topic-based pub/sub server notifying
users with appropriated data).
COMPaaS Middleware

COMPaaS (Cooperative Middleware Platform as a Service) is an IoT middleware system that

has been tailored to support the 5G technology integration. Basically, the goals of the COMPaaS
can be summarized as follows:

Abstraction of the integration and interoperation between applications and physicaldevices

through the provision of hierarchical system services according to device profiles (i.e., a set of
functional characteristics describing each physical device).

Abstraction of the collection and management of data provided by physical devicesthrough the
provision of application-level services. Provision of high-level services to facilitate the
development and integration of IoT applications. Provision of a software architecture based on
IoT/M2M andWoT (Web of Things) standards.

COMPaaS architecture is based on SOA approach and is composed of two main systems as
“Middleware” and “Logical Device”. Logical Device is the system responsible for hiding all the
complexity of physical devices and abstracts the functionality of these devices to the upper layer.
Middleware: Middleware is the system responsible for abstracting the interaction between
applications and devices and also for hiding all the complexity involved in these activities. It
provides an API to be used by applications in order to use the services of the COMPaaS. The
main functions of the middleware range from data management to device integration and

address the provision of high-level services to applications. figure presents the organization of
the modules of the middleware. All services are part of the middleware API available to
applications, except the communication service, which is used for both applications and logical
devices. The rest of the modules (Resource Manager, Resource Handler, and Event Handler) .
ZIGBEE ARCHITECTURE:

Zigbee Architecture is divided into three sections.

 IEEE 802.15.4 which consists of MAC and physical layers

 ZigBee layers, which consist of the network layer, the ZigBee device object (ZDO), the
application sublayer, and security management
 Manufacturer application: Manufacturers of ZigBee devices can use the ZigBee
application .