To improve the state of IoT interoperability, researchers have leveraged numerous approaches and technologies which we refer to interoperability handling approaches. In the following, we provide an overview of the different interoperability handling approaches for addressing interoperability challenges in IoT. In addition, we provide a summary of a representative sample of proposals for IoT in Table 1. The aim is to provide an overview of the interoperability perspective they focus on and the approaches they take for interoperability. In particular, for each proposal we consider the interoperability perspective (device, network, syntactical, semantic, cross-platform and cross-domain interoperability), interoperability approach, openness, connectivity, application protocols, and security/privacy metrics. The different proposals are divided into IoT standard frameworks, projects, and platforms. We do not cover the recent H2020 projects as they have already been compared in our previous work [9]. Furthermore, the technical details of all the proposals are not included, since the main objective here is to define their interoperability approach.
Table 1. Summary of the IoT interoperability proposals, ✓=supported; ✗=not supported; NG = Not Given Adapters/gateways
Gateways or adapters are the class of schemes which address interoperability through the development of an intermediate tool sometimes called mediators to improve interoperability between IoT devices. The objective here to bridge between different specifications, data, standards, and middleware’s etc. To perform a conversion between the protocol of the sending device and the protocol of the receiving device, the gateway can be expanded with the use of plug-ins. For example, when IoT devices use dissimilar communication technologies (i.e., Bluetooth and ZigBee) or when they use dissimilar application layer protocols (i.e., XMPP and MQTT). Gateways can be dedicated hardware, or the function can be embedded in the firmware or software of an intelligent device such as a programmable logic controller (PLC), human-human interface (HMI), or computer. A one-to-one protocol gateway enables interoperability among two types of protocols. This approach has limitation on scalability in terms of the number of different IoT products interacting together requiring specific connectors (design time complexity) and the high number of IoT products in a deployment requiring brokering (runtime complexity). If we suppose to bind n distinct IoT products, the eventual complexity will be n(n-1)/2. Using a single protocol for IoT would impossible. Therefore, several one-to-any protocol gateways are used for providing seamless interoperability.
There are many industrial and academic works which focus on standardization and design of IoT gateways. For example, the Apple HomeKit, Alphabet (Google) Net ecosystem, If-This-Then-That (IFTTT)Footnote 10, and Ponte [31] design different connectors to support various IoT device communication protocols. For example, Ponte [31] was initially developed as QEST [32] and is a framework which enables publish and receive of data from sensors and actuators through M2M protocols, accessible through a REST API. It allows the programmer to automatically convert and exchange data between HTTP, CoAP and MQTT. However, the main limitation of Ponte is that it assumes the underlying devices support TCP/IP, and resource-constrained devices have not been taken into account. In addition, Zhu et al. [33] proposes an IoT gateway based on user-space programmable software to bridge the heterogeneity between WSN protocols and mobile communication networks or Internet and includes functionalities like data forwarding, protocol conversion and management. The gateway functionality is realized by a smartphone and connects networks with different protocols such as ZigBee, Bluetooth, GPRS and Ethernet. However, the main limitation of their approach is that users cannot access the sensor data unless they install server software on their PC. The authors of [34] discuss the lack of interoperability in IoT applications and services. The proposed gateway is responsible for the adaption of the different device protocols and for ensuring the proper management and security functionalities. The architecture supports standard and proprietary interfaces which also allows it to extend the gateway capabilities. But, scalability features are not discussed. Similarly, efforts like [35, 36] present off-the-shelf smartphones as mobile gateways for IoT interoperability. However, their main limitation is the excessive energy consumption. Asensio et al. propose Common Thing Protocol (CTP) to provide a specification to bring things into the IoT [37] by using an intelligent IoT gateway as a main component in the architecture. The Semantic Gateway as a Service (SGS) is presented as a gateway between the physical world and the high-level layers of an IoT system. According to the SGS architecture, raw sensor data are transferred from external sink nodes to the central gateway node via the multi-protocol proxy. Before being forwarded, data are semantically annotated using W3C SSN ontology, SemSOS tool and other domain specific ontologies. Semantic annotation of sensor data provides semantic interoperability between messages and supply higher-level actionable knowledge for implementing.
Virtual networks/ overlay-based solutions
Virtual networks or Overlay-based solutions have been proposed in [38] the “Managed Ecosystems of Networked Objects” (MENO), with the aim to integrate sensor and actuators and other IP-smart objects seamlessly to the Internet for end-to-end communication. The main idea behind MENO is to create a virtual network on top of physical networks and thereby allow communication with other types of devices, including sensor nodes. Within each virtual network, end-to-end communication is possible using different protocols. Once end-to-end communication is enabled, it becomes possible for application developers to write new applications that utilize sensors, actuators, and other devices. It appears to be on track to use a clean-slate approach to integrate the physical work with the Internet in a seamless way. The concept utilized by MENO is used to develop the Internet of Things Virtual Network (IoT-VN) [39] shown in Fig. 3 to integrate smart-resource constrained devices into the Internet. This is achieved by creating a virtual network of all the devices that want to communicate and cooperate. Their solution focuses on both resource-constrained and non-constrained things. This integration is achieved by integrating all involved devices into a secured virtual network, named an Internet of Things Virtual Network (IoT-VN). The advantage of this approach is enabling end-to-end communication between devices, however the key issues are scalability and binding to specific protocols.
Networking technologies
Different networking protocols and technologies have been used to provide networking interoperability in IoT. For example, the conventional Universal Plug and Play (UPnP) and DLNA protocols is used for communication between IoT devices and the gateway. In the following, we discuss the main technologies/solutions for interoperability at the network level.
IP-based approaches
The IP-based approaches embed the full TCP/IP stack on smart devices. By embedding the TCP/IP stack in Fig. 4, the sensor and actuators are directly connected to the IP network to allow end-to-end communication between sensor network and IP network. Therefore, the sensor and actuators are directly connected to the IP network to allow end-to-end communication between sensor network and IP network. Some have attempted to implement the TCP/IP stack on sensor nodes such as uIP [40], TinyTCP [41], and lwIP [42]. The key benefit of implementing the TCP/IP stack on sensor nodes is that gateways and protocol translations are not required. However, the authors of [43] argue that an all IP sensor network is not possible on sensor nodes because of their resource-constraint property. Due to the success of these implementation, the IETF has formed working groups (WGs) at the network layer such as Routing Over Low Power and Lossy Networks (ROLL) [44], IPv6 over Low Power WPAN (6LoWPAN), Constrained Application Protocol (CoAP) which is based on UDP, and Constrained Restful Environment to solve the connectivity problem of resource-constrained devices. This approach, still uses gateways to convert between standard protocols used in the Internet and proprietary protocols used in the sensor network, e.g. IPv6 to 6LoWPAN. Therefore, due to the use of standard protocols, this approach does not have the limitations of the gateway-based approaches. The key benefit is that the gateway and the sensor nodes do not have to be from the same vendor which improves the interoperability between devices. IP as the de facto standard of the Internet provides a single open standard interface for a trillion things. However, by permitting direct access with the resource-constrained devices, security related issues like authentication and access control are presented. The security challenges in the IP-based approaches are detailed in [45].
Software-defined networking (SDN)
Software defined networking (SDN) [46] is a new networking paradigm to make the current wireless and mobile networks more “intelligent”, efficient, secure, and scalable in order to handle the large amount of data produced in the IoT [47]. One of the main novelties of SDN for breaking the vertical silos in IoT, is to separate the control and data planes in networking devices. Fig. 5 illustrates a simplified view of the integration of IoT and SDN.
SDN has been applied to IoT to facilitate networking applications such as heterogeneity [48, 49], mobility management [50, 51], QoS management [52, 53], and security [54]. For instance, Martinez-Julia and Skarmeta [48] used SDN to allow different objects from different networks to communicate with each other using IPv6 and at the same time simplify the management and control operations of various objects types by adding an additional IoT controller over the SDN controller. Thus, even so the devices have different protocols, the forwarding devices in the router convert it in a form understandable by the receiver. This enables the communication of diverse devices in the network. Another work that emphasises the necessity to deal with the heterogeneity of the diverse IoT devices and applications is presented in [49]. The authors conclude that, using the IPv6 may be a suitable choice to handle the large number of connected devices, but the heterogeneity in terms of the diverse characteristics and capabilities is still an open research issue. To address it, they provide a rather high-level architecture of an IoT controller, which to a generic level seems an adequate framework to handle heterogenous IoT flows.
In [50], the authors proposed a new mobility service adapted for sSDN concept to solve the performance issues of PMIPv6 protocol. The authors argue that their solution can be used for mobility management instead of PMIPv6 without using the legacy IPv4 protocol. A middleware is designed and implemented by Qin, Z. et al. [52], which is composed of a layered IoT SDN controller to manage distributed, heterogeneous, and dynamic IoT multinetwork. In their research, a central controller monitors the existing resources and schedules the data streaming according to the specific service requirement e.g., a minimum data rate, maximum tolerable delay or packet loss for each separate flow. IoT SDN exploits network calculus to model the end-to-end flow performance in IoT multi-network environments, semantic modelling for resource matching and the genetic algorithm schedules flows, to optimize the usage of the existing IoT network opportunities. The performance results show that the genetic algorithm based flow scheduling algorithm has better performance compared to bin packing and load balance algorithms.
Network function virtualization
A complementary approach to SDN is network function virtualization (NFV). NFV separates the physical network equipment’s (i.e., network address translator, firewall) from the functions that run on them. This way, numerous service providers can create several isolated virtual networks which could then share the physical network equipment’s provided by the network infrastructure providers. NFV has the potential to reduce Operational Expenditure (OPEX) and Capital Expenditure (CAPEX) costs by sharing the network infrastructure, dynamic scaling, on-the-fly, and flexible network function deployment [55].
An example where NFV is used in IoT is [56], they defined their own abstract IoT architecture which is then combined with SDN architecture (Application, Control and Infrastructure layers) to produce a general SDN-IoT framework. This consists of an upper layer with servers providing developers with the necessary APIs for IoT applications, a middle layer, which contains a distributed network OS, commanding several physically distributed SDN controllers, a south layer, which contains the SDN-enabled network switches, and the IoT gateway, which connects them to the middle layer. In essence, this is just the classic SDN architecture, with IoT applications in mind. The authors take it one step further when they claim that, to achieve an IoT-optimized network, one must design the network OS, which sits in the middle layer, using virtualization techniques. The network OS must be used in such a way that the diversity of use-cases and IoT devices is acknowledged. The exact details of using virtualization in the middle layer is missing, but linking NFV techniques with an SDN orchestration logic for an IoT network is noteworthy.
Fog computing
The cloud has been used as a medium to address interoperability called the Fog of Things [57], where the computing, storage and networking services are placed at the edge of the network rather than centralized cloud servers, i.e., as close as possible to the end user devices. This decreases network latency that arises when converting the raw data produced by resource-constrained mobile devices and sensors into knowledge or actionable instructions. Fog computing paradigm provides value to the data before making it available to the web facilitating interoperability in IoT, 5G, AI, tactile internet, virtual reality, and other complex data and network intensive applications [58] and preparing the managed data for further applications to be interoperable [59]. Fog computing provides interoperability of local ecosystems in the fog and also at the cloud level.
Open API
API is an interface provided by service providers that exposes data or functions to an application written in a high-level language. Publicly available APIs, for providing cross-platform and cross-domain interoperability focuses on well-documented open APIs that provides developers with streamlined access to functionalities and services. There are many popular APIs such Google Maps, YouTube, Flickr, Twitter, Amazon, and Facebook. Today’s IoT platforms almost all provide a public API to assist developers access their services. The APIs are usually based on RESTful principles, and allow common operations such as PUT, GET, PUSH, or DELETE. Only three of the studied IoT platforms did not include a REST API for easing the development of web services (i.e. LinkSmartFootnote 11, IFTTT and OpenIoTFootnote 12), but use different interaction means. However, the majority of IoT platform providers develop and deploy APIs that are platform-specific and proprietary relying on internal information models to define the syntax of specific operations to be used by their consumers. For example, a mobile application may offer to control your Internet-connected refrigerator. It may have functionalities like showing the items inside the refrigerator, notify you with the expiry date of the ingredients, or start/stop an operation. Without a standard API, if the mobile application wants to integrate more than one refrigerator vendor, it must write custom code to use another platform-specific API, which is a substantial burden for the application developers. However, a standard API enables cross-platform interoperability between the existing solutions with minimal change in the application.
With the massive development of IoT platform providers a vast silo of diverse APIs has been created that increases the difficulty of developing applications as well as interoperability issues. To overcome the effect of API heterogeneity in IoT, some platforms such as ThingSpeakFootnote 13 enable the creation of widgets written in Javascript, HTML and CSS that may be distributed on the platform to other users. HyperCatFootnote 14 is a specification which provides syntactic interoperability between different APIs and services based on a Catalog that can be tagged with metadata. The catalog contains many resources identified by its URI. Moreover, the symbIoTeFootnote 15 and Big-IoTFootnote 16 European projects are working on a generic interworking API to provide uniform access to resources of all existing and future IoT platforms to address syntactic and cross-platform interoperability. The Interworking API acts like an adapter which needs to be implemented by other platforms.
Service oriented architecture (SOA)
To provide syntactic interoperability between heterogeneous devices and across all systems, researchers have proposed Service Oriented Architecture (SOA) as a major technology in different ways [60,61,62,63]. SOA is built on top of the network layer so that data and information processing can be easily managed through different service components [64, 65]. In the SOA of the IoT, the interaction with and operations of different wireless devices are classified into different service components and the application layer software can access resources exposed by devices as services. Exposing each component’s functionalities as a standard service can significantly increase the interoperability of both network and device. In particular, the Web Service technology has been proposed for realizing the SOA promise of maximum service sharing, reuse, and interoperability [66]. The classic web service oriented approach (WS-* web service) [61, 67] and resource oriented approach (REST web services) [68, 69] have been used to address syntactic interoperability. A study conducted by Pautasso et al [70] compared REST web services with WS-* servers and they concluded that RESTful services are preferred for tactical, ad-hoc integration over the Web, while WS-* are preferred for professional enterprise application integration scenarios.
An extension to SOA named Event-driven SoA (EDSOA) [71] has been proposed for constructing IoT services. Event-driven architecture (EDA) is integrated with SOA to compose IoT services. SOA breaks the application into multiple independent services described by the standard interface specification, whereas EDA coordinates independent services using event flows. The authors focus on building a scalable EDSOA which could use resource information to compose IoT services, use independent and shared events to run those services, and then use event sessions to coordinate the services.
Semantic web technologies
Originally, the Semantic Web technologies developed by the W3C such as Resource Description Framework (RDF), SPARQL and Web Ontology Language (OWL) have been used for describing resources on the Web. Currently, the same standards are used in many different areas including IoT. The Semantic Web of Things (SWoT) [72] paradigm is proposed for the integration of the Semantic Web with the WoT, for realizing a common understanding of the various entities which form the IoT. Recent research has concluded that semantic web technologies are a major driver for interoperability across heterogenous environments [73]. The literature uses semantic web technologies to achieve semantic interoperability by using standards or agreements on the format and meaning of data or in a dynamic way by using shared vocabularies either in a schema form and/or in an ontology-driven approach.
Ontologies (or vocabularies) in IoT are a set of objects and relationships used to define and represent an area of concern. They represent an abstraction technology which aims to hide heterogeneity of IoT entities, acting as a mediator between IoT application provider and consumers, and to support their semantic matchmaking [74]. Many ontologies have been proposed in the context of IoT such as W3C Semantic Sensor Network (SSN) [44], IoT-Ontology, SAREF and OpenIoT. A comprehensive survey of the existing ontologies which are ready to be used in three different domains: general IoT ontologies, health, and transportation and logistics can be found in [75]. They also outline an approach using ontologies to achieve semantic interoperability among heterogeneous IoT platforms. The authors believe that the SSN ontology has seen the strongest adoption and inspired other projects. However, no single domain has a global ontological standard, and most application specific ontologies are proprietary.
There are several IoT research projects which utilize the capabilities of the above-mentioned ontologies or other semantic technologies to improve semantic interoperability such as Semantic Sensor Web (SSW) [76], OpenIoT, HYDRAFootnote 17, SPITFIRE [77], SENSEIFootnote 18 to name a few. The SSW is one of the initial studies on semantic IoT/WoT concept, usually understood as a marriage of Sensor Web and Semantic Web technologies. The Open Geospatial Consortium (OGC) has developed SensorMLFootnote 19 which is only a syntactic standard for sensor web enablement (SWE) using XML-based protocols and APIs without providing however, either semantic interoperability nor a basis for reasoning. UbiROAD [78] achieves semantic interoperability by two layers: 1) data-level interoperability and 2) functional protocol-level interoperability and coordination. Serrano [79] discuss the semantic interoperability challenges in the context of IoT and present SEG 3.0 methodology to provide semantic interoperability between heterogenous applications. The methodology uses semantic web technologies to combine heterogeneous IoT data, as well as adding value to the data to assist developers and IoT practitioners for building IoT applications. The framework consists of 12 layers which focus on heterogeneity of devices, communication networks, data, reasoning and services. The authors of [80] present the idea of “sensing as a service”, where standard service technologies are used as an interface that represents the IoT resources (i.e. the physical world devices) and provide an access to the functions and capabilities of these resources. In this work a set of semantic models for IoT resources, entities and services is presented. These semantic models for the IoT component descriptions offers interoperability at the data and service layers.
Open standard
Open standards are one significant means to provide interoperability between and within different domains. A standard is framework of specification that has been approved by a recognized organization, or is generally accepted and widely used throughout by the industry [81]. Currently there are several standard bodies, consortiums and alliances trying to solve IoT standard issues including Open Interconnect Consortium (OIC) providing IoTivityFootnote 20, AllSeen Alliance providing AllJoyn, oneM2MFootnote 21, OMA LWM2MFootnote 22 and ETSI M2MFootnote 23. The IPSO alliance focuses on semantic interoperability in IoT and the standardization of resource-based object model which is based on standards like SenML, CoAP and 6LoWPAN. Frameworks such as LWM2M and IoTvitiy work with the IPSO alliance. The IoTivity focuses on device interoperability irrespective of form factor, operating system or service provider through protocol plug-ins. The AllJoyn framework functions as a software bus between devices facilitating device interoperability for home automation and industrial lighting applications. Constrained devices use a thin library, and do not have a bus attachment. This framework introduces high overhead for low end devices. The framework has also an open source codebase and various modular services which ensures interoperability. OneM2M enables interoperability on the platform level using a horizontal service layer for M2M and IoT communications, that is network independent and offers internetworking to different existing M2M vertical systems. Syntactic and semantic interoperability between platforms are achieved by using ontologies.