Reference Architecture

The focus of INTER-IoT is to bridge different IoT platforms and make them fully inter-operable. To attain this goal, interoperability must be achieved at different levels. To complicate matters, the number of solutions at time of writing is simply unsustainable, heading towards 500 different platforms. Even looking only at the \"big players\", there isn't a clear winner or a superior set of solution.

In such fragmented ecosystem, there is no doubt that being able to use the same modeling for different system is the first important step towards true interoperability. Modeling is a valuable mechanism to abstract commonalities of existing platforms, extracting the main features that define the IoT domain and to build general approaches to face the interoperability in a universal way.

For this reason, INTER-IoT has defined a Reference Model for IoT Platforms Interoperability, a Reference Architecture defined based on this model and a complete interoperability system.

INTER-IoT Reference Model

The INTER-IoT project used the OASIS definition for describing the reference model. As a reminder, OASIS (Organization for the Advancement of Structured Information Standards) gives the following definition of a reference model:

[Reference model is] an abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist. A reference model is not directly tied to any standards, technologies or other concrete implementation details, but it does seek to provide a common semantics that can be used unambiguously across and between different implementations.

The INTER-IoT Reference Model (RM) description and fundamentals are based in the successful results of the IoT-A project. The Inter-IoT RM however, unlike the RM proposed in IoT-A, is fully focused in providing a model for interoperability of existing IoT Platforms.

Domain Model

A Domain model is a class diagram that is used to describe specific aspects of a set of knowledge or activities. The main use for it is to represent use cases and real-world concepts in a way that can then be used by technical people to develop a service, application or a product.

The INTER-IoT Domain Model is an extension of the IoT-A's DM model towards a full interoperability of different systems.

In Figure 1 the proposed Domain Model for interoperability of IoT Platforms is shown. The diagram is based on IoT-A DM; IoT-A's colors have been extended to include two new types of entities:

  • Purple: new entities that are intrinsic to each IoT Platform.

  • Light brown: new entities that are outside the scope of an IoT Platform, and which are necessary for the interoperability of IoT Platforms.

Regarding the new entities related to IoT Platforms, a new abstract Service entity has been created. A Service represents an Active Digital Artifact that provides a generic service of an IoT Platform. Platform Service and IoT Service extend this Service to provide two different types of service. In short, an IoT Service is a Mechanism to interact with specific Resources related to Virtual Entities, like query, subscribe, insert, etc.; a Platform Service is a Complex service provided by the platform not directly related to a specific Resource or Virtual Entity -- usually processing, monitoring, etc.

Regarding the new entities necessary for the interoperability of IoT Platforms, the Interoperability Service defines the abstract concept of making interoperable different Services at different platforms. They include interoperability mechanisms among homogeneous Services available at the IoT Platforms.

Functional Model

The focus of the INTER-IoT Functional Model is to break up complexity in systems by grouping similar Functional Components (FC) together. The Functional Decomposition (FD) is the process by which different FCs are identified and related to one another into Functional Groups (FG).

Fig. 1 INTER-IoT generic domain model.

The Functional Model is divided into 9 FGs:

  • At the bottom, we put the FG Device. This FG regroups all the Devices according to the definition in the Domain Model.

  • However, as INTER-IoT also deals with Platforms that opaquely cover some of the devices, another FG has been made: this is the the IoT Platform FG. Those two FG are outside the scope of the INTER-IoT FM, and are outlined only to show where the original data and interaction are based upon.

  • A FG Communication has been identified as both Devices and IoT Platforms need to transfer information,

  • A number of main abstractions identified in the Domain Model have been put into the IoT Service FG, namely Service, Platform Service, Digital Artifact, Virtual Entities, Resources.

  • The Service Interoperability FG Includes the Interoperability Service and the VE Interoperability Service.

  • In the Ontology FG there are the Platform Ontology and the Global Interoperability Ontology.

  • The Application FG corresponds to the upper layers. As defined in the requirements, the users of INTER-IoT will be also applications or systems willing to access the different platforms.

  • To address consistently the concern expressed about IoT Trust, Security and Privacy in the interoperability realm, the need for an orthogonal Security FG is identified.

  • Finally, the orthogonal Management FG is required for the management of and/or interaction between the functionality groups.

Fig. 2 Overall INTER-IoT Functional Model.

Communication Model

Communication protocols on IoT Platforms

The INTER-IoT Communication Model aims at defining the paradigms for connecting the elements that compose any IoT system. These elements have to be previously defined by the Domain Model (DM).

As the IoT domain is composed by both constrained and unconstrained resources, we consider protocols ranging from the device level to the application level. Additionally the Communication Model involves those Users that have to exchange information. These Users can be divided in Human Users, Services or Artifacts. Moreover, the communication between these Users has to support two paradigms; Unicast and Multicast.

Given the IoT domain it's possible to identify three different cases:

  1. Both Users belong to a normal (non-constrained) network; in this case there is no need of translator or gateways to be implemented in the communication, and a a non-constrained protocol is used for the User to communicate.

  2. One User belongs to a constrained network and one to a unconstrained one; here there is a need of a gateway to translate the protocols and the information from the non-constrained network to the constrained one.

  3. Both Users belong to a constrained network; in this case there can be the need of a gateway, in case the users do not belong to the same \"island\".

Simplifying the INTER-Layer solutions, and being the aim of these the creation of interoperability between elements from the same of different IoT system, it easy to see that the three environments are perfectly covered as mediators that understand several protocols are implemented at each of the layers

  • Device Layer; Implementation of a gateway.

  • Network Layer; Implementation of an SDN network (with controller) to make the translation from constrained sensor networks to IP-based networks with the collaboration of the gateway.

  • Platform Layer; Implementation of a middleware that acts as a broker or intermediary between platform communication.

  • Application Layer; Implementation of a service compose modeler to orchestrate the composition of services.

  • Data and Semantic Layer; Implementation of a channel-based semantic mediator.

However, once we have the solutions implemented at different layers (INTER-Layer), the communication of these solutions with other systems, e.g. using INTER-FW, is carried out without any kind of constrain. That is, both sites or artifacts that want to communicate are located in a non-constrained environment, so that, the communication between INTER-IoT interoperability solutions and INTER-FW is performed over common non-constrained protocols e.g. HTTP with REST, and without the use of any broker, mediator, gateway or intermediary.

Security Model

In general, IoT systems are composed of a number of devices, actuators and computing resources that handle a number of physical data and information. Even if this information can be public, it is important to guarantee that the information is correct, comes from a trusted source, and in certain cases, that it is not readable by non-authorized actors.

In the context of INTER-IoT, where different IoT systems and platforms connect, our role is not to be the "weakest link" of the security chain: this means that INTER-IoT should be able to provide -- at the very least -- the same security of the systems it connects.

We will now analyze the main properties, also listed in IoT-A Security Model: Trust, Security, Privacy, and Reliability.

Trust

Trust is very important in IoT systems, as IoT terminals are likely to generate a large quantity of data which will then be used by different services. Trusting the source of data is then of paramount importance, as data sent by malicious sources may compromise entire systems.

IoT-A lists different Trust-models. For INTER-IoT, as it connects different IoT systems, it is important to understand all different models as the systems may use them, in a way or another, and we must be able to carry the "trustiness" between different systems.

Hereafter we have a short list of the most important concepts in this domain:

  • Trust-Model domains: Complex systems encompass several entities; therefore, a one-size-fits-all model able to be applied to completely different domains, objects, use cases, . . . , is not feasible. Any IoT system should then be split into coherent blocks, each one of them following a specific trust model.

  • Trust-evaluation mechanisms: These are used in order to define a unique methodology for determining the "trustworthiness degree" of a subject within a specific system. Usually, these systems follow a deductive pattern, building up knowledge on a subject by the information collected, using any means (from direct experience to reputation from other community members).

  • Behavior policies: They regulate how two subjects within the same Trust Model domain interact according to their trustworthiness value. In other words, a subject may decide, when exchanging information with another subject, to accept or not the value coming from another subject, according to the trust he has towards the subject.

  • Trust anchor: A subject trusted by default by all subjects using a given Trust Model, and used to compute the trustworthiness of unknown subjects in absence of data.

  • Federation of trust: It delineates the rules under which trust relationships among systems with different Trust Models can be defined.This is fundamental for INTER-IoT, as it's necessary to have a federation of trust to provide interoperability between different systems, platforms, and consequently, trust models.

Security

Similarly to IoT-A, the security model has three layers: Service, Communication and Application. However, while IoT-A is focused on an IoT system, INTER-IoT extends the domain to the integration of different systems. Therefore, while

in the communication field IoT-A divides the space in two (namely, Unconstrained Devices and Constrained Devices, INTER-IoT adds the platforms communication, which is similar to the Unconstrained node, although it may have different security characteristics. If both can bear the most complete security protocols, an IoT platform can include both constrained and unconstrained nodes, making his overall security more complex.

The domain of constrained nodes is very heterogeneous, with a large number of protocols, most of which focus on small bandwidth and low power use. Bluetooth Low Energy (BLE), for instance, is a typical example of a very insecure communication protocol often used in IoT devices. It is quite easy, and has been demonstrated in numerous occasions, that is possible to perform eavesdropping on BLE communication, as well as man-in-the-middle attacks and identity tracking.

As outlined in IoT-A, the role of gateways is fundamental for keeping the constrained domain secure. Gateways, as they are unconstrained device, need to "sandbox" constrained nodes so that, if they are compromised, the effect is just limited to the dropping of the information sent by them, and if possible to deactivate them until the attacker has been found and isolated.

In the implementation of the layers, security is a first-class citizen, specially in the lower interoperability layers. Thus, at gateway level, security in source and destination is supported, via SSL. Device-level security is a responsibility of the manufacturer, since it needs an embedded implementation. To handle this, the INTER-IoT Gateway reports about the security implementation of the connected devices, letting the data consumer rely or not in the data according their security constraints, or even implement further mechanisms.

Moreover, all exposed interfaces in INTER-IoT (not only at device level) are protected with authentication and authorization mechanisms in a centralized Identity Manager. This is specially relevant for the use of INTER-API, which can be accessed publicly.

Privacy

Privacy is a mandatory characteristics of INTER-IoT; as well, one of our use-cases deals with health data, which have clearly a very important privacy requirement.

Following the IoT-A work, we will also use the functional components Authentication component, Trust and Reputation component in order to guarantee the privacy of the data whenever required.

The table 1 illustrates the way INTER-IoT will handle privacy within these functional components.

Table 1 Privacy in functional components