Interoperability in Internet of Things: Taxonomies and Open Challenges

3.1 Device interoperability

IoT is composed of a variety of devices, even more than the traditional Internet. These devices, which are called “smart objects/things”, may consist of high-end devices or low-end devices [24]. The high-end IoT devices have enough resources and computational capabilities such as Raspberry Pi and smartphones. On the other hand, the low-end IoT devices are resource-constrained in terms of energy, processing power and communication capabilities than typical hosts such as RFID tags, tiny and low-cost sensors, and actuators, Arduino, and OpenMote to name a few. The microcontroller (MCU) architecture and key system characteristics of IoT devices such as processor speed, RAM, communication technology, and battery capacity differ broadly between different brands and models Also, various communication protocols have emerged due to the different requirements of IoT markets. For example, IoT devices such as Smart TV, printers, air conditioners support traditional ubiquitous Wi-Fi technologies and 3G/4G cellular communications. Most recent IoT medical devices are based on ANT+ standard; other wearable devices mostly support Bluetooth SMART and NFC, while the environmental sensors use ZigBee-based on IEEE 802.15.4 standard. Besides these protocols, the standard communication protocols are utilised for smart devices, sensor, and actuators (i.e., Z-Wave, ZigBee, and WirelessHart) as well as the non-standard proprietary solution (i.e., LoRa, SIGFOX).

In the absence of a de-facto communication standard(s), not all smart devices implement all these communication technologies. In some cases, the devices that want to exchange information may be using different communication technologies which requires interoperability between the different types of heterogeneous devices that co-exist in the IoT ecosystem. Device interoperability refers to enabling the integration and interoperability of such heterogenous devices with various communication protocols and standards supported by heterogeneous IoT devices. Device interoperability is concerned with (i) the exchange of information between heterogeneous devices and heterogenous communication protocols and (ii) the ability to integrate new devices into any IoT platform.

3.2 Network interoperability

The networks that IoT devices will be operating on will continue to be heterogenous, multi-service, multi-vendor and largely distributed. Different from desktop computers, IoT devices generally rely on various short-ranged wireless communication and networking technologies which is rather more intermittent and unreliable [24]. Network level interoperability deals with mechanisms to enable seamless message exchange between systems through different networks (networks of networks) for end-to-end communication. To make systems interoperable, each system should be able to exchange messages with other systems through various types of networks. Due to the dynamic and heterogenous network environment in IoT, the network interoperability level should handle issues such as addressing, routing, resource optimization, security, QoS, and mobility support [25].

3.3 Syntactical interoperability

Syntactic interoperability refers to interoperation of the format as well as the data structure used in any exchanged information or service between heterogeneous IoT system entities. An interface needs to be defined for each resource, exposing some structure according to some schema. WSDL and REST APIs are examples. The content of the messages need to be serialized to be sent over the channel and the format to do so (such as XML or JSON). The message sender encodes data in a message using syntactic rules, specified in some grammar. The message receiver decodes the received message using syntactic rules defined in the same or some other grammar. Syntactic interoperability problems arise when the sender’s encoding rules are incompatible with the receiver’s decoding rules, which leads to mismatching message parse trees.

3.4 Semantic interoperability

The W3C defines semantic interoperability as “enabling different agents, services, and applications to exchange information, data and knowledge in a meaningful way, on and off the Web” [26]. The WoT addresses the current fragmentation by exposing things and systems data and metadata through API. But, such efforts have been hampered because the corresponding parties need to share knowledge of an API [27] and many devices do not speak the same language and cannot exchange across different gateways and smart hubs [28]. To be more precise, the data generated by things about the environment may have a defined data format (e.g. JSON, XML or CSV), but the data models and schemas used by different sources are usually dissimilar and not always compatible. Besides, the data may be represented in diverse units of measurements and consist of other information. This semantic incompatibility between data models and information models results in IoT systems not being able to dynamically and automatically inter-operate as they have different descriptions or understandings of resources and operational procedures, even if IoT systems expose their data and resources to others [27].

3.5 Platform interoperability

Platform interoperability issues in IoT arises due to the availability of diverse operating systems (OSs), programming languages, data structures, architectures and access mechanisms for things and data. There are currently many different OSs developed specifically for IoT devices such as Contiki⁸, RIOT⁹, TinyOS [29] and OpenWSN [30], each with several versions, to deliver services to users. Besides, the IoT platform providers such as Apple HomeKit, Google Brillo, Amazon AWS IoT, and IBM Watson provide different Oss, programming languages, and data structures. For example, Apple HomeKit supports its own open source language Swift, Google Brillo uses Weave, and Amazon AWS IoT offers SKDs for embedded C and NodeJS. This non-uniformity causes hindrance for application developers to develop cross-platform and cross-domain IoT applications.

Developers need to obtain extensive knowledge of the platform specific APIs and information models of each different platform to be able to adapt their applications from one platform to another. A cross-platform IoT application can access different IoT platforms and integrate data from various platforms. For example, consider the following application scenario: a user who has health problems uses an IoT cross-platform application every day to help him with his everyday tasks. The IoT application connects to the user’s smart health platform of wearable sensors to continuously monitor his health conditions (heart rate, fall situation, and glucose level) and in an emergency, locates him and sends an ambulance. The application can also access a smart-city platform to buy a ticket to the users desired destination and shows the fastest route to the bus/train station. The cross-platform interoperability between things and data in this scenario enables interoperability across separate IoT platforms specific to one vertical domain such as smart home, smart healthcare, smart garden, etc. After cross-platform interoperability is enabled, cross-domain interoperability can be achieved in which different platforms within heterogenous domains are federated to build horizontal IoT applications. Fig. 2. shows the concept behind cross-domain interoperability where different IoT platforms from different IoT domains (e.g. health, home, transport, etc.) can be integrated to build new innovative applications. For example, a smart home platform can provide domain-specific enablers such as air temperature and the lighting conditions.

Open image in new window

These enablers can then be exploited by other IoT platforms, such as smart healthcare, to provide more innovative applications and scenarios.

4.1 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)¹⁰, 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.

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

Open image in new window

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

4.3.1 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].

Open image in new window

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

Open image in new window

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.

4.4 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. LinkSmart¹¹, IFTTT and OpenIoT¹²), 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 ThingSpeak¹³ enable the creation of widgets written in Javascript, HTML and CSS that may be distributed on the platform to other users. HyperCat¹⁴ 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 symbIoTe¹⁵ and Big-IoT¹⁶ 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.

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

4.6 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, HYDRA¹⁷, SPITFIRE [77], SENSEI¹⁸ 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 SensorML¹⁹ 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.

4.7 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 IoTivity²⁰, AllSeen Alliance providing AllJoyn, oneM2M²¹, OMA LWM2M²² and ETSI M2M²³. 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.