Detailed Overview

The main goal of symbIoTe (symbiosis of smart objects across IoT environments) is to foster a simplified IoT application and service development process over interworking IoT platforms. This will be accomplished by 1) providing the means to create and manage virtual IoT environments across various IoT platforms, 2) implementing high-level APIs –enablers–  leveraging such virtual environments to offer specialized services (e.g., localization in indoor spaces or unified access to environmental data gathered from various sources), tailored to the needs of symbIoTe-specific use cases, 3) offering the means for creating dynamic and self-configurable smart spaces, and 4) implementing a secure interworking protocol between the platforms in accordance with recommendations from standardization bodies. This will support SMEs and new entrants in the IoT domain to build innovative IoT services within short development life cycles.

symbIoTe is built around the concept of virtual IoT environments provisioned over various cloud-based IoT platforms. Virtual IoT environments are an abstraction composed of virtual representations of actual sensors and actuators being exposed by their host platforms to third parties. Of course, a single virtual sensor may emit raw, aggregated or filtered data produced by many sensors residing within a host platform. It needs to be noted that the host platform defines the policies for exposing its virtual sensors to third parties. symbIoTe envisions dynamic and adaptive virtual environments since resource offerings across symbIoTe-enabled IoT platforms are also continuously changing. The environment should be able to offer a quasi-optimal set of resources to application developers in accordance with, e.g., specific sensing requirements, predefined privacy policies, required QoS, etc.

The symbIoTe’s architecture is built around a hierarchical IoT stack (motivated by the OneM2M approach and OpenIoT’s VDK) and spans over different IoT platforms. Smart objects are expected to be connected to IoT gateways within the smart spaces which also host various computing and storage resources. The local infrastructure shares the available local resources (connectivity, computing and storage) and is connected to platform services (e.g. resource discovery and management, data analytics) running in the cloud. The architecture comprises four layered domains, as depicted in the following diagram and described below.


  1. Application Domain offers a high-level API for managing symbIoTe’s virtual IoT environments. The high-level API enables the creation and management of cross-platform virtual IoT environments to support cross-platform discovery and management of resources, data acquisition and actuation as well as resource optimization. In addition to the high-level API, symbIoTe will offer domain-specific enablers to ease the development of domain-specific applications.
  2. Cloud Domain hosts the cloud-adjusted building blocks of specific platforms (e.g., a data store, data analytics and stream processing tools, tools for platform management, etc). To enable platform interoperability and platform federations, we envision a symbIoTe interworking interface to be defined and implemented for the exchange of information between two collaborating IoT platforms (in accordance with standardization efforts which are currently conducted by, e.g., oneM2M). The interworking API will expose a directory of open platform resources and will implement an interwoking protocol for the exchange of information between platforms.
  3. Smart Space Domain comprises smart objects, IoT gateways as well as local computing and storage resources available within, e.g., a home environment or campus building. It is assumed that IoT platform-specific gateways (e.g. an X-GSN component in case of the OpenIoT platform or BETaaS gateway) are setup in the smart space domain. To enable dynamic sensor discovery and configuration in smart spaces as well as dynamic sharing of the wireless medium, symbIoTe adds a new software component –symbIoTe middleware– to the smart space domain. The symbIoTe middleware exposes a standardized API for resource discovery and configuration, and implements a sensor-discovery protocol for a simplified integration of sensors with platforms hosted in smart space domains. After the initial interaction with the middleware, a smart object is connected to and configured with the platform gateway serving the domain (either home or visited). This protocol will also enable that a smart object entering a visited domain becomes part of a new smart space, enabling device roaming.
  4. Device Domain spans over heterogeneous devices which are capable to dynamically blend with the surrounding environment and are discovered by the symbIoTe middleware which performs the initial “introduction” of devices within a smart space. Smart objects exhibit properties of self-organization and can be configured on the fly to be integrated with different IoT platforms hosted within the smart space, preventing thus the lock-in of customers to a specific IoT platform and IoT provider. Device specific symbIoTe clients will run on selected smartphones.

symbIoTe aims at implementing an Open Source middleware prototype, following an agile-like approach. Developers from all consortium partners will join forces in the implementation of the software components in the aforementioned domains. Regarding licensing, the consortium is discussing on the selection of the appropriate licensing scheme. Initial discussions have indicated that for the licensing of the Application/Cloud domain SW components (i.e., the symbIoTe high level APIs), a “copyleft” license will be selected (most probably the GNU Library or ‘Lesser’ General Public License version 3.0 (LGPL-3.0)), so that updates, bug fixes and new features are always given back to the Open Source Community. For the middleware components residing at the platforms’ side (i.e., at the Cloud or Smart Space domains), the licensing will follow the “non-copyleft” approach (e.g., the BSD 3-Clause “New” or “Revised” License (BSD-3-Clause)).