The IoT6 architecture has been designed by taking into account to the furthest possible extent the outcomes of other relevant projects, most notably IoT-A (i.e., the IoT ARM), ETSI M2M and FI-WARE. These outcomes were adapted and enhanced with IoT6 specific features and components, mainly coming from project’s reliance on IPv6 functionality. The aim was to utilize the properties of this protocol and to re-use them within the architecture model, possibly replacing some of the standard components. For example, parts of the service and resource discovery functionality has been replaced with the DNS-SD and mDNS based approaches. As shown in the IoT ARM Functional Model in the Figure, IoT6 has contributed mainly to the Communication, Service organization, IoT service and Security components.
The initial IoT6 architecture design approach followed the initial IoT ARM Guidances that were available at that time. Then, it was mainly relying on modification of already available ETSI M2M and FI-WARE IoT architectures. The resulting IoT6 architecture is shown in Figure below.
On the device level, it is possible to distinguish devices supporting IPv6, and legacy devices (i.e., devices not supporting it). IPv6-based devices can be organized in small or large clusters. Legacy devices can support a range of specific protocols, such as KNX, ZigBee, or Bluetooth, as well as IPv4. An additional cluster is dedicated to EPC global compliant RFID system.
At the communication level, IoT6 utilizes IPv6 (and 6LoWPAN for low power devices). Devices are connected either via the so-called half gateways (that convert legacy protocols to IPv6) or directly, when they are IPv6-enabled. This setup can be directly mapped to the IoT ARM communication channel model; IoT ARM’s constrained networks are mapped to one or the other group of devices as defined above, while IoT6’s half-gateways represent IoT ARM’s gateways.
On top of the IPv6 layer, CoAP has been selected as the preferred protocol with different encoding techniques (JSON, XML). For a specific case of building automation, oBix protocol was also included.
At the IoT service level, the IoT6 architecture support several solutions. In the case of small IPv6 clusters, mDNS is used for service registration and discovery (inside the cluster). In the case of large clusters, DNS-SD is used for internal cluster service registration and discovery. For the EPCIS cluster, an adaptation of the Digcovery solution was needed. On the global level, two solutions are supported: Digcovery and CoAP Resource Discovery (RD). When it comes to the service organization level, the project relies on the cloud based workflow and process management services which interact with the rest of the system using CoAP. As the IoT ARM methodology matured, the IoT6 project was able to apply the final IoT ARM approach and to update the architecture accordingly.