Middleware for Internet of Things: A Survey Aditya Bhanje Athul Iddya

"Middleware for Internet of Things: A Survey" from IEEE Internet of Things Journal Mohammad Abdur Razzaque, Marija Milojevic-Jevric, Andrei Palade, and Siobhán Clarke

Definition of “Internet of Things” “A world-wide network of interconnected objects uniquely addressable, based on standard communication protocols” Things include a very wide variety of elements such as: Industrial Objects Personal Objects Elements in our environment

IoT Infrastructure Characteristics Heterogeneous devices Resource-constrained Spontaneous interaction Ultra-large-scale network and large number of events Distributed and dynamic network Context and Location-awareness Intelligence

Middleware in IoT and its Requirements Provides a software layer between applications, the operating system and the network communications layers Facilitates and coordinates some aspect of cooperative processing In brief, a middleware provides a layer between application software and system software Middleware requirements can be grouped into two sets: Functional and non-functional requirements Architectural requirements

Functional Requirements

Resource Discovery Requirements Challenges Automated Scale well and efficient distribution of load discovery Challenges Tradeoffs between registry discovery and number of registries Research is required in probabilistic models for IoT Deal with trade offs between distribution of registries and number of registries - smaller number provides consistency and speed, but doesn’t scale well for large networks Probabilistic model is used for matching a search with its results - better as it scales well, but cannot guarantee service discovery

Resource Management Requirements Challenges Monitoring of resource usage Resolving resource conflicts and fair distribution of resources Challenges Frequent conflicts during resource allocation Agent-based cooperative conflict resolution is a possible solution

Data Management Requirements Challenges Data acquisition, data processing and data storage Challenges Data transmission is more expensive than local processing Support for data filtering and data compression is sparse

Event Management Requirements Challenges Real time analysis of high velocity data Challenges Rate of event handling is untested Middleware might become a bottleneck

Code Management Requirements Challenges Code allocation and code migration services Challenges Deploying updates is complicated Some types of middleware support code management, but none of them support updating both application code and firmware code

Non-functional Requirements

Scalability Requirements Challenges Accommodate growth in the network size and application/services Challenges Middleware designed for wireless sensor networks might not scale to ultra-large-scale networks Each system component has to scale

Real Time Requirements Challenges Provide real-time services On-time delivery of information or services Challenges Some middleware approaches are non-real time by design Rest support soft-real time, none support hard-real time

Reliability Requirements Challenges Each component needs to be reliable for overall reliability of system Challenges Not addressed in most middleware Synergies between reliability and other requirements could be exploited

Availability Requirements Challenges Zero or small recovery time and failure frequency to achieve desired availability Challenges Service availability should be resilient to hardware failure

Security and Privacy Requirements Challenges Preserve owner’s privacy and provide security to all blocks of middleware Challenges Authentication-based security is insufficient Holistic solution is needed

Ease of Deployment Requirements Challenges No expert knowledge should be required Challenges Remote deployment without preconfiguration is a challenge

Popularity Requirements Challenges Middleware should be continuously supported and extended Challenges Growing an active community is a challenge

Architectural Requirements

Programming Abstraction Requirements Isolation of applications or services development from the underlying, heterogeneous IoT infrastructures Challenges Steep learning curve Providing an API is important any middleware High-level interface to abstract away the underlying heterogeneity and network structure APIs can often be complicated - challenge is to make a simple API that is easily understandable but also powerful

Interoperable Requirements Challenges A middleware should work with heterogeneous devices/technologies/applications, without additional effort from the application or service developer Challenges Network interoperability is well-supported, but semantic and syntactic interoperability are not Service-based approach offers the best semantic interoperability, but syntactic interoperability is rare Middleware should be able to handle differences in network structure, syntax and semantics between IoT devices Syntax - Structure of data/information should be understandable to the other Semantics - Meaning of data/information should be understandable to the other

Service-based Requirements Challenges Offer high flexibility for new and advanced functions added to middleware Services like data management, reliability and security provide abstraction for complex functionality Challenges Services should be designed while keeping resource constraints in mind Service discovery needs to be autonomous Middleware should be service-based to allow easy addition of new functionality It allows abstraction of complex functionality for easy application development

Adaptive Requirements Challenges Able to evolve to fit itself into changes in circumstances such as in network or application demands Challenges Decision-making is often hard coded Dynamic and context-aware adaptation to QoS requirements is absent Middleware needs to be able to handle changes in network or application demands

Context-aware, Distributed and Autonomous Requirements Context-awareness is important for building adaptive systems and to establish values from sensed data Middleware should be self-governed, without any human intervention Support functions that are distributed across physical infrastructure of the IoT Challenges Exploitation of context in resource discovery, data management is missing Most middleware cannot adapt themselves to self-* behaviour such as self-adaptiveness and machine-to-machine communication Middleware should be able to aware of the context of users and devices Sensed data should be accompanied by context such as location (spatial) and time (temporal)

Types of IoT Middleware Event-based Service-oriented VM-based Agent-based Tuple-spaces Database-oriented Application-specific

Event-based Application components are split into publishers and users Uses publish-subscribe pattern Events are classified by topic and published through a database to select users that are subscribed This design addresses non-functional requirements such as reliability, availability, real-time performance, scalability, and security

Service-oriented Application components are split based on functionality into services Services are reusable, loosely-coupled, composable and discoverable Requirements have to be addressed through functionalities like service discovery, service, data and QoS management Ultra-large-scale network and resource-constrained devices makes service discovery and composition challenging

VM-based Applications are divided into smaller modules that are spread throughout the network Each node holds a VM, which runs the modules Provide safe-execution environment through virtualization This provides high-level programming abstraction, self-management and adaptivity

Agent-based Applications are divided into modular programs that spread through the network using mobile agents This creates a decentralized system that can handle failures This addresses requirements like resource and code management, availability, reliability and adaptiveness This approach can work well with resource-constrained devices

Tuple spaces Each node has a local space to store tuples The middleware creates a federated tuple space on a gateway that provides read and write access to users The federated tuple space stores the tuples in tuple spaces of individual nodes This approach works well with devices with mobile devices that stay connected to a gateway

Database-oriented The sensor network is viewed as a virtual relational database system Data is accessed through a SQL-like query language This enables support for complex queries Implementation is similar to a distributed database system Somewhat similar to tuple-based approach No support for real time access

Application-specific Optimizes network infrastructure for specific application Takes application domain requirements into consideration Focuses on resource management such as QoS

Conclusion The paper formulates a list of key characteristics of IoT and requirements for IoT middleware It judges the middlewares based on how well each of them addresses the requirements It classifies the middleware based on their architecture and identifies the requirements addressed by each type of middleware It identifies gaps in the requirements addressed by each type of middleware and recommends areas of focus for future research

Thank you!