How to make symbIoTe-enabled Your Smart IoT Device

By making symbIoTe-enabled Smart Devices , device manufacturers can expose IoT resources to any third-party application. With SymbIoTe resources will be visible under the Smart Space and can be used together with resources from other IoT platforms, in a way that the wider use is ensured and roaming becomes truly possible and devices can be  tracked and operate while visiting different Smart Spaces.

The symbIoTe architecture is built around a hierarchical IoT stack, where smart objects are expected to be connected to IoT gateways within the smart spaces which in turn host various computing and storage resources. The local infrastructure shares the available local resources and is connected to platform services running in the cloud. This architecture comprises four layered domains: two of them have been presented in a previous blog post, the last two (Smart Space and Device Domain) are described here.

Figure 1 – symbIoTe Domains and compliance Levels

These two domains are strictly related. From one side, they refer to the integration of platforms and devices within smart spaces, to simplify the local integration and dynamic reconfiguration of IoT resources, which in symbIoTe is called Level-3 compliance; on the other side, they govern the way device can do roaming and smart objects interact with visited smart spaces. This is what symbIoTe calls Level-4 compliance.

Smart Spaces and Smart Devices

First of all, it’s necessary to introduce the Smart Space and Smart Device concepts we developed in symbIoTe: these are the very building blocks that lay under the L3 / L4 compliancy vision.

When saying Smart Space (SSP) in symbIoTe, we refer to environments (residence, campus, vessel, etc.) where one or more IoT platforms provide coordinated services. Such environments are typically related to a physical space (e.g. a smart residence space is bound to a house or building), but in the more general case we can extend the concept of SSP to a broader physical space (e.g. a smart campus or smart city). We explicitly exclude from our notion of SSP the concept of a geographically dispersed IoT architecture, therefore, for instance, we do not consider as SSP the “space” of a fleet of trucks controlled by an IoT platform. There is a somehow arbitrary blurred line in this distinction: for example, we can consider weather sensors in a city controlled by a single platform as a “space” or they can be grouped to form multiple SSPs. An SSP comprises both virtual and physical objects, such as gateways and smart objects.

Let’s explore now, what a Smart Device is in symbIoTe: it’s a device where a piece of software is installed in order to make it to interact with a symbIoTe Smart Space. That’s pretty simple, isn’t it?

Well, the interaction with the Smart Space is characterized by the physical space in which the Smart Device is located. Indeed, in such a physical space, the wireless medium and the technologies providing local connectivity represent some resources that need to be shared, in a coordinated manner, by the IoT platforms and the Smart Devices that are in radio visibility. Moreover, the device contains additional resources, including sensing and actuating capabilities, applications, storage, etc., which may generally depend on the device type and can be accessed by exposing a symbIoTe-compliant API.

In order to define the architecture of this symbIoTe software component, we considered two main features for Smart Devices:

• attaching to a Smart Space, by configuring an authorized physical link to a selected gateway, in order to make available the device resources and participate to the service creation in the smart space (which we call in symbIoTe Level-3 Compliance).
  

  Figure 2 – symbIoTe Level-3 Compliance

   

• roaming across heterogeneous Smart Spaces, which are usually managed by heterogeneous administrators (which we call in symbIoTe Level-4 Compliance).
  

  Figure 3 – symbIoTe Level-4 Compliance

   

It’s important to clarify that the roaming concept for a Smart Device, into symbIoTe, only deals with the service plane, not involving the physical roaming from a network infrastructure to another, maybe managed by different operators. This involves a logical registration of the Smart Device, which can be completely decoupled by the attachment to the physical gateway.

Figure 4 – symbIoTe Middleware Components

From a software point of view, a Smart Space is a physical environment under the control of a middleware, that has been installed somewhere locally (e.g. a pc, a gateway, etc.).
Components in SSP Middleware and their main functionalities are:

• Innkeeper: handles registration of resources which platform providers / SDEV manufacturers want to expose to symbIoTe Smart Space, also keeping a register where it stores them,
• SSP Resource Access Proxy (RAP): receives requests for resource access from applications running in the Smart Space,
• Resource Access Proxy (RAP) Gateway: provides an access point for local resources to be addressable from outside the Smart Space,
• Local Authentication and Authorization Manager (AAM):  enables a common authentication and authorization mechanism.

Level 3 vs. Level 4 Compliance

In the context of symbIoTe, a Smart Device has no relation to a specific IoT Platform. It only relies on the functions provided by the symbIoTe Middleware in any SSP in order to be accessible from the symbIoTe Core and, ultimately, by any symbIoTe app. As a consequence, the SDEV is required to expose a way to access the resources it contains: basically, the SDEV should include its own RAP Specific Plugin.

The distinguishing features between L3 and L4 compliance are dynamic configuration (L3- compliance) and roaming (L4-compliance). Hence, an SDEV is considered L3-compliant if it can be attached to a Smart Space and be dynamically configured (i.e. registered to the SSP and thus searchable and accessible). The SDEV is considered L4-compliant if it can also move across different Smart Spaces and still be recognized as the same object it was before. In other words:

• device identity is the main characterizing aspect of an L4 SDEV: if the device can be uniquely recognized independently of the Smart Space it is connected to, it is actually roaming across platforms. Otherwise, there is no way to distinguish that device from another identical device;
• maintaining identity only makes sense if there is a service (symbIoTe enabler) or application which needs to track the device, either because it is associated with a specific service or user, or because the history of the device is meaningful for the purpose it is used for.

The choice of using the SDEV as an L3 or L4 device, though, is up to the specific service and may even change over time, as the SDEV is being used for different purposes. Hence, an L4-compliant SDEV does not necessarily always roam.

How to make a Smart Device L3/L4 compliant?

First of all, we must said that resources coming from one Smart Device can be exposed to Smart Spaces and used along with resources from other symbIoTe enabled platforms (within the same SSP).

Figure 5 – symbIoTe Level 3/4 Compliance

The process of making Smart Devices symbIoTe L3/L4 enabled consists of writing the necessary software adapters (Agent and RAP plugin) to allow the SDEV to properly register itself and its resources to the symbIoTe Smart Space and then to translate the access to resources (from symbIoTe compliant applications) in a format that they can understand (as shown in Figure 2).

The difference between L3 and L4 SDEV is in the procedure for registering the device itself: since a L4 SDEV must be recognized within the whole symbIoTe ecosystem, first of all it needs to be registered in the Core to get a unique Id. After this has been done, it is able to provide this identifier every time it joins a different SSP.
In the case of L3 SDEVs, this pre-procedure is not needed, and is the SSP, once it joins, that takes care of giving an identifier to the device.

Step 1. Develop your SDEV Agent

The SDEV Agent is a piece of software, developed by the SDEV manufacturer, in charge of sending registration requests for itself (only for L3 devices) and its resources to the Innkeeper. During the registration of the SDEV (whether L3 or L4), the manufacturer has to specify the Information Model that will be used to describe resources. Once defined, the payload of the requests must match this format in the payload of the registration (for the resources).

Moreover, the SDEV Agent is the component that can turn the device into a symbIoTe client for other SDEVs and Platforms residing in the SSP: therefore, for example, it would be possible to access a light owned by a Platform from a SDEV that doesn’t belong to that Platform (providing all necessary access credentials).

Step 2. Develop your SDEV Plugin in RAP

You might have given a look to the previous blog post, that describes how to make your Platform L1 compliant. You also might have read about Resource Access Proxy component and the relative plugin the Platform Owner has to write to support the access to his resources. If you did, you already know what we’re talking about, otherwise it is explained in the following paragraph.

Resource Access Proxy (RAP) is a module that is in charge of receiving access requests to resources. It is composed by two parts: one is the interface to query from the outside, which is the same for every platform / SDEV, the other, called Plugin, is in charge of actually accessing the resources exposed by the SDEV. SDEV manufacturers are required to implement this plugin, in order to interface with the proprietary APIs of the SDEV to acquire the data. Once obtained, plugin just forwards them to the generic part of the RAP which then will handle all communication with the upper layers.

Step 3. Switch On symbIoTe

SymbIoTe SSP Middleware is the enabling point for switching on symbIoTe in local environment (read Smart Space). The software can be downloaded from the project’s git repository (https://github.com/symbiote-h2020/SmartSpaceMiddleware) and it’s a standalone application that needs to be installed and configured in a machine such as a gateway connected to the Smart Space local network.

Then, an administrative procedure must follow in order to register the Smart Space to the symbIoTe Core. This procedure is supposed to be made by the SSP administrator. 
Once did this, the Platforms and the Smart Devices (with their agent and plugin) have an entry point for registering their resources and for enabling third-party applications to access to them.

Figure 6 – symbIoTe Level 3/4 Components

Conclusions

With this blog post, we introduced the Smart Space and Smart Device concepts designed in  symbIoTe and provided some explanations of the Level 3 and Level 4 compliance and the general process to make a Smart Device symbIoTe L3/L4 compliant.

In a future blog post we will show how this can be implemented in practice, with exemplary IoT devices and SSPs.

Gianluca Insolvibile
Matteo Pardi
(Nextworks)