# Federation of Internet of Things Testbeds for the Realization of a Semantically-Enabled Multi-Domain Data Marketplace

Luis Sanchez, Jorge Lanza, Juan Ramón Santana, Rachit Agarwal, Pierre Guillaume Raverdy, Tarek Elsaleh, Yasmin Fathy, Seungmyeong Jeong, Aris Dadoukis, Thanasis Korakis, et al.

<figure><img src="image_1.png" /></figure>

## To cite this version:

Luis Sanchez, Jorge Lanza, Juan Ramón Santana, Rachit Agarwal, Pierre Guillaume Raverdy, et al. "Federation of Internet of Things Testbeds for the Realization of a Semantically-Enabled Multi-Domain Data Marketplace. Sensors, 2018, 18 (10), pp.34. 10.3390/s18103375. hal-01889896

HAL Id: hal-01889896

https://inria.hal.science/hal-01889896

Submitted on 8 Oct 2018

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
1

2

3

# Federation of Internet of Things Testbeds for the
Realization of a Semantically-Enabled Multi-Domain
Data Marketplace

4

5

6

7

8

Luis Sánchez<fnref n="1" />*, Jorge Lanza<fnref n="1" />, Juan Ramón Santana<fnref n="1" />, Rachit Agarwal<fnref n="2" />, Pierre Guillaume Raverdy<fnref n="2" />,

Tarek Elsaleh<fnref n="3" />, Yasmin Fathy<fnref n="3" />, SeungMyeong Jeong<fnref n="4" />, Aris Dadoukis<fnref n="5" />, Thanasis Korakis<fnref n="5" />, Stratos

Keranidis<fnref n="6" />, Philip O'Brien<fnref n="7" />, Jerry Horgan<fnref n="7" />, Antonio Sacchetti<fnref n="8" />, Giuseppe Mastandrea<fnref n="8" />, Alexandros

Fragkiadakis<fnref n="9" />, Pavlos Charalampidis<fnref n="9" />, Nicolas Seydoux<fnref n="10" />, Christelle Ecrepont<fnref n="10" /> and Mengxuan

Zhao<fnref n="11" />

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

Received: date; Accepted: date; Published: date

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

**Abstract:** The Internet of Things (IoT) concept has attracted a lot of attention from the research and innovation community for a number of years already. One of the key drivers for this hype towards the IoT is its applicability to a plethora of different application domains. However, infrastructures enabling experimental assessment of IoT solutions are scarce. Being able to test and assess the behavior and the performance of any piece of technology (i.e. protocol, algorithm, application, service, etc.) under real-world circumstances is of utmost importance to increase the acceptance and reduce the time to market of these innovative developments. This paper describes the federation of eleven IoT deployments from heterogeneous application domains (e.g. smart cities, maritime, smart building, crowd-sensing, smart grid, etc.) with over 10,000 IoT devices overall which produce hundreds of thousands of observations per day. The paper summarizes the resources that are made available through a cloud-based platform. The main contributions from this paper are twofold. In the one hand, the insightful summary of the federated data resources are relevant to the experimenters that might be seeking for an experimental infrastructure to assess their innovations. On the other hand, the identification of the challenges met during the testbed integration process, as well as the mitigation strategies that have been implemented to face them, are of interest for testbed providers that can be considering to join the federation.

43

**Keywords:** Data Marketplace; Federation; Internet of Things; Testbeds; Platform;

<footnote n="1">¹ Network Planning and Mobile Communications Lab, Universidad de Cantabria. Santander, Spain. [lsanchez, jlanza, jrsantana]@tlmat.unican.es</footnote>

<footnote n="2">² MiMove Team, Inria Paris. Paris, France. [rachit.agarwal, pierre-guillaume.raverdy]@inria.fr</footnote>

<footnote n="3">³ Institute for Communication Systems, University of Surrey. Guildford, United Kingdom. [t.elsaleh, y.fathy]@surrey.ac.uk</footnote>

<footnote n="4">⁴ Korea Electronics Technology Institute (KETI). Seongnam, South Korea. sm.jeong@keti.re.kr</footnote>

<footnote n="5">⁵ Network Implementation Testbed Lab, University of Thessaly. Volos, Greece. [ardadouk, nasoskor]@gmail.com</footnote>

<footnote n="6">⁶ Gridnet. Volos, Greece. sk@gridnet.gr</footnote>

<footnote n="7">⁷ Telecommunications Software & Systems Group, Waterford Institute of Technology. Waterford, Ireland. [pobrien, jhorgan]@tssg.org</footnote>

<footnote n="8">⁸ Tera s.r.l. Conversano, Italy. [antonio.sacchetti, giuseppe.mastandrea]@terasrl.it</footnote>

<footnote n="9">⁹ Institute of Computer Science, FORTH. Heraklion, Greece. [alfrag, pcharala]@ics.forth.gr</footnote>

<footnote n="10">¹⁰ Laboratory for analysis and architecture of systems, CNRS. Toulouse, France. [nseydoux, christelle.ecrepont]@laas.fr</footnote>

<footnote n="11">¹¹ Easy Global Market. Valbone, France. mengxuan.zhao@eglobalmark.com</footnote>

<footnote>* Correspondence: lsanchez@tlmat.unican.es; Tel.: +34-942 203 940</footnote>
## 1. Introduction

It goes without saying that experimentation is one of the basis for technological advances [1]. Being able to test and assess the behavior and the performance of any piece of technology (i.e. protocol, algorithm, application, service, etc.) under real-world circumstances is of utmost importance to increase the acceptance and reduce the time to market of these innovative developments. However, despite the attention that the Internet of Things (IoT) has attracted [2] thanks to the large number of application domains where it can play a game changer role [3–7], there is still a lack of real, large-scale testbeds where all these innovations can be actually assessed. In this respect, real-life experimentation should play a major role in these developments. It would be necessary to deploy, maintain and open to the research community this kind of infrastructures so that their research can have tangible results from real-world deployments [8,9].

Interestingly, there are initiatives that, in order to improve these solutions' maturation and significant rollout, try to support the evaluation of IoT solutions under realistic conditions in real world experimental deployments [10–12]. However, still they tend to lack the necessary scale or they fail to fulfil some key indicators [13,14]. Nonetheless, large-scale infrastructures enabling the assessment of developed solutions under real-world circumstances are scarce and are not always available for those willing to test their innovations. Moreover, such infrastructures are typically bound to a specific application domain, thus, not facilitating the testing of solutions with a horizontal approach (i.e. fulfilling requirements from different application domains). Finally, even when, through the combination of different testbeds, the requirements from an experimenter were fulfilled, it is necessary to deal with interoperability issues resulting from the different interfaces and models used by the different testbeds.

This paper describes the federation of testbeds that have been created within the framework of the H2020 FIESTA-IoT project [15]. The platform designed in the project provides the tools and techniques for building applications that horizontally integrate silo platforms and applications. The semantic interoperability of the diverse sensor clusters and IoT networks federated is based on the virtualization of sensors in the cloud. At the heart of these virtualization mechanisms is the modelling of heterogeneous IoT devices according to a common ontology. However, the detailed description of the platform design principles and building blocks is out of the scope of this paper. Specific insights about the EaaS IoT Platform designed and implemented in the FIESTA-IoT Project can be found at [16].

The main aim of this paper is to present the actual federation of testbeds on top of a running instance of this platform. This federation aggregates and ensures the interoperability of data streams stemming from eleven different IoT deployments. The paper summarizes the resources that are made available from eleven IoT deployments from heterogeneous application domains (smart cities, maritime environment monitoring, smart building, crowd-sensing, smart grid, smart agriculture) with over 10,000 IoT devices overall which produce hundreds of thousands of observations per day. Detailed information is provided on the amount of sensors and observations that are made available to the interested experimenters.

The main contributions from this paper are twofold. On the one hand, the paper provides an insightful summary of the federated data resources. While some informational details about the papers is publicly available<fnref n="1" />, the review presented in this paper provide the necessary insights to fully understand the experimentation possibilities raised by having access to all the federated resources. This detailed and precise overview is particularly relevant to the experimenters that might be seeking for an experimental infrastructure to assess their innovations. In this sense, to the best of our knowledge, there is no single or federated IoT experimentation infrastructure currently offering the amount of data resources described in this paper. On the other hand, the paper discusses over the most relevant challenges that have been met during the testbed integration process, as well as the mitigation strategies that have been implemented to face them. This discussion summarizes the

<footnote n="1">¹ The FIESTA-IoT Testbeds. http://fiesta-iot.eu/index.php/fiesta-testbeds/ [Online 13th August 2018]</footnote>
technical solutions adopted to provide semantic and functional interoperability among the heterogeneous underlying IoT infrastructures and should be of particular interest for testbed providers that can be considering to join the federation. Thus, the paper goes beyond the plain description of data offerings but also presents practical insights on how the main technical challenges involved in the semantically-enabled federation of IoT platforms have been tackled. In this sense, it is important to highlight that the technical discussion presented in the paper recaps on lessons learnt from actual deployment and development experience.

The remaining of the paper is organized as follows. Section 2 briefly reviews existing related work. A high-level overview of how the testbeds have been federated and the requirements imposed by the underlying FIESTA-IoT Platform for allowing new testbeds to federate are introduced in Section 3. Section 4 presents the summary of the testbeds' federation as well as the key details of each of the testbeds within the federation. Lessons learnt during the federation process and some discussions about the testbeds' federation concept are sketched in Section 5. Finally, Section 6 concludes the paper.

## 2. Related Work

This section reviews on the key aspects and technologies that are behind the developments described in the paper to position the research and contributions of the paper in context and to validate its relevance by establishing the similarities and highlighting its differentiating features with currently existing approaches.

**Experimental Infrastructures.** The required effort and cost for creating realistic environments over which new IoT solutions and technologies could be tested has led to the creation of experimental testbeds open to the research and innovation community. Wisebed [17], FIT IoT-Lab [11], Fed4FIRE [18], BonFIRE [19] and GENI [20] are all testbeds that support wireless sensor network experimentation. They allow testing of new communication protocols and wireless communications that underpin the IoT domain. However, these experimental infrastructures are technology specific and mainly focused on Wireless Sensor Networks rather than on IoT as a whole. As a consequence, they do not support experimentation of new IoT applications and services. In response, SmartSantander [10] provides a large-scale, geographically distributed range of real-world sensors to test new innovative IoT services; LiveLab [21] offers a facility to evaluate human-usage of the technologies; and [22] presents a Mobile Sensing testbed of smart phones to support field-testing of new crowd-sourcing applications. Even if the usefulness of these experimental infrastructures in their own right is out of any doubt, these higher-layer testbeds are all domain specific. Thus, they do not consider an important aspect that is currently at stake within the research community. Achieving interoperability across domain silos and heterogeneous technologies is the next frontier that has to be overcome to unleash the IoT foreseen potential. The FIESTA-IoT facility is technology and domain agnostic (federating multiple smart city, smart home, crowd-sensing testbeds) to allow experiments that demonstrate IoT interoperability across highly heterogeneous IoT environments.

**Experimentation-as-a-Service.** Experimentation-as-a-Service (EaaS) model can be seen as an instance of the general Everything-as-a-Service paradigm [23] introduced and developed by leveraging the advances in cloud computing. EaaS enables stakeholders belonging to the research community or industrial sector to promote and accelerate innovation by testing and verifying new technologies supported by realistic and specialized experimental testbeds, through the use of a cloud environment. In [24] a platform for assessing the performance and reliability of commercial mobile broadband networks is presented, where authenticated users are able to orchestrate network experiments following an EaaS paradigm. FLAME project [25] is developing an EaaS architecture for exploring the viability of Future Media Internet platforms in smart-city deployments. The experiments aim to highlight the benefits of a software-enabled communication infrastructure for the optimal information distribution and control. While the FLAME project is not related with IoT, it develops an EaaS architecture for content distribution aimed at the support of experimentation and innovation on top of open platforms. This platform is similar to the FIESTA-IoT platform on top of the testbed federation presented in the paper does.
144 The EaaS model applied to the IoT domain stands out as an upgrade to the Sensing-as-a-Service [26] model; EaaS services are not confined to a number of virtualized sensor queries but implement 145 and execute complex experimental workflows “in the wild” by orchestrating various devices and 146 diverse testbeds. Thus, it is possible to widen the scope and complexity of the IoT applications 147 supported as well as reuse the infrastructures and data streams provided and maximize their 148 utilization. The SmartCampus facility [27] offers a testbed based on a three-tier architecture for 149 executing user-centric experiments in an office environment, set up by external stakeholders. 150 Although adopting the EaaS paradigm, the facility is highly domain specific in stark contrast to the 151 FIESTA-IoT platform. A federation of experimentation platforms is presented in [28], where users are 152 able to rapidly deploy reproducible experiments related to several smart city domains, by on-demand 153 access to virtual reusable resources. Organicity [29] provides a facility for federating different smart 154 city platforms and assessing the crowd-sensing problem by encouraging different stakeholders to 155 identify urban challenges and tackle them by co-creating suitable experiments. These platforms bear 156 a number of similarities with the one presented in this work. They offer virtualized access to IoT data 157 produced by real-world IoT infrastructure. Datasets available over a number of different 158 application domains. They allow experimentation through web-based APIs. Some of them have 159 aggregated data from IoT infrastructures which are managed by different providers. Nevertheless, 160 they neither enjoy the diversity of testbeds described here nor employ semantic web technologies for 161 facilitating the semantic interoperability between deployed IoT infrastructures. 162

163 **Semantic Interoperability.** Semantic web technologies to query and manage information within 164 federated cyber-infrastructures [30–32] are being used as a promising approach to guarantee the 165 necessary consistency among IoT infrastructures. However, they usually only defines the framework 166 and assesses the meta-directory service using their own ontologies [33,34]. Thus, they fail in taking 167 into account the needs from IoT infrastructures that are already deployed. Moreover, the definition 168 of the procedures to extend their deployments by integrating already existing ones is also missing. 169 Additionally, some of them are still only proposed as theoretical solutions [35] which have not been 170 implemented nor assessed. Finally, those that present some kind of assessment of their solutions’ 171 implementation, while supporting the potential of the solution, exhibit a lack of exposure to real-life 172 situations and actual heterogeneous testbeds, including large-scale IoT experimental infrastructures, 173 which would show the true scalability and flexibility of the solutions. Only recently, the semantic 174 interoperability have been explored in standardization fora [36] defining some base ontology and 175 data catalogues that can be adopted by a large community, both already existing and forthcoming. 176 The approach followed, mainly by oneM2M base ontology, is similar to the one followed within the 177 FIESTA-IoT project for defining the FIESTA-IoT ontology [37]. The main reason for defining our own 178 ontology was that at the time of initiating our work, the oneM2M standard was not available. 179 However, the same that it has been possible to federate one oneM2M-based testbed, it is possible to 180 define and implement the adaptations in the opposite direction.

181 **IoT data marketplaces.** The data generated by IoT devices is mostly owned by device owners 182 and is often private in nature. There are however third parties that could benefit from using that data, 183 and the challenge is in allowing them to access it under the conditions that data owners find 184 acceptable. The concept of data marketplace has been introduced already some years ago [38]. 185 However, although data management was clearly identified as one of the key challenges for IoT [39], 186 solutions proposed until recently focused on creating the backend storage solutions plus the indexing 187 mechanisms to discover the relevant pieces of information among the massive amount of data that 188 IoT infrastructures can generate [40–42]. Nevertheless, there is an important requirement that has to 189 be fulfilled. Developers who want to use existing platforms need to negotiate access individually and 190 adapt to the platform-specific API and information models. Having to perform these actions for each 191 platform often limits the applicability of the developed applications as they have to be tailored to the 192 different platforms. This fragmentation of the IoT and the missing interoperability result in high entry 193 barriers for developers and prevent the emergence of broadly accepted IoT ecosystems. Only recently 194 some initiatives have appeared defining not only the data management platforms that support the 195 marketplace but also the interoperability mechanisms that make the proposed solutions prepared to
integrate a potentially endless amount of IoT heterogeneous infrastructures [43-46]. Although these approaches have multiple commonalities with the federation of IoT testbeds that is described in this paper, to the best of our knowledge, none of them shows the diversity and scale of the one presented in this paper.

**Sensor Web Enablement and Web of Things.** The Sensor Web Enablement (SWE) initiative (http://www.ogcnetwork.net/swe) has developed a suite of standards that can be used as building blocks for a Sensor Web. SWE defines the term Sensor Web as "Web accessible sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application programming interfaces" [47]. To achieve this, SWE incorporates models for describing sensor resources and sensor observations. Further, it defines web service interfaces leveraging the models and encodings to allow accessing sensor data, tasking of sensors, and alerting based on gathered sensor observations. Leveraging the SWE concepts, the Web of Things (WoT) emerges from applying web technologies to the IoT to access information and services of physical objects. In WoT, each physical object possesses a digital counterpart. These objects are built according to Representational state transfer (REST) architecture and accessed with HTTP protocol via RESTful API. A Web Thing can have an HTML or JSON representation, REST API to access its properties and actions, and an OWL-based semantic description.

W3C has recently launched the Web of Things Working Group [48] to develop initial standards for the Web of Things. Its main aim is "to counter the fragmentation of the IoT". They are still working on defining the WoT architecture and the description of the WoT Thing, which should define a model and representation for describing the metadata and interfaces of Things, where a Thing is the virtualization of a physical entity that provides interactions to and participates in the WoT.

In parallel to this standardization efforts, several projects and platforms have been developed targeting the support of service provision based on the SWE and WoT paradigms. In [49], authors present their WoT-based platform for the development and provision of smart city services. Precision agriculture is the application domain which benefits from the platform described in [34]. While they provide some of the solutions promised by the WoT, still do not address the IoT fragmentation as they rely on proprietary modelling. In the works presented in [50-52], semantic technologies are employed to fulfil the extendable modelling requirement. As we are proposing in this paper, we believe that this is the necessary combination in order to fully develop the WoT concept into a running system. The key novelty from the work presented in this paper is that, most of the existing previous works have not been implemented and proven over real-world scenarios with federation of heterogeneous IoT infrastructures, as it is the case of the platform presented in this paper. Some well-known implemented Sensor Webs [53-55], which have actually put SWE and WoT standards and paradigms in practice, have not faced the necessary heterogeneity to actually face the interoperability challenge.

**Semantic Web and Semantic annotation of sensor data.** In semantic web, there exists standards such as SSN ontology [56] that are widely accepted and used by different testbeds. A new version of SSN ontology [57] covers mainly concepts that are common to most of the domains (horizontal concepts). SSN ontology defines concepts such as Sensor, Observation, Samples and Actuators that form core concepts within the Domain and Information Models defined in the IoT Architecture Reference model (ARM) [58]. However, in more abstract terms, definitions of such concepts are provided in another widely promoted oneM2M ontology [59]. There are several other ontologies such as Smart Appliance REFerence (SAREF) [60] that are standardized but are context-based and only focus on one domain (vertical concepts). Efforts have been made to unify concepts defined vertically and horizontally so that federation and interoperability can be achieved. One such effort is that of lightweight FIESTA-IoT ontology [37] that reuses concepts to focuses on competency based questions [61] across different domains. It mainly targets concepts that are necessary to answer: who is the provider of the information, under what conditions observations are collected, when and where are the observations made and how collected information is exposed. In FIESTA-IoT ontology the core concepts are borrowed from SSN and IoT-lite ontology [62], a lighter version of the IoT-A ontology
[63], to conform with IoT ARM's Domain and Information Models. These core concepts relate to defining:

* A Resource which is a “Computational element that gives access to information about or actuation capabilities on a Physical Entity” [58].

* An IoT service which is a “Software component enabling interaction with IoT resources through a well-defined interface.” [58].

* An Observation is an “Act of carrying out a procedure to estimate or calculate a value of a property of a feature of interest” [64].

Further many related concepts to abovementioned core concepts have been reused in FIESTA-IoT ontology. As it has been already said, the FIESTA-IoT ontology is defined to be as lightweight as possible precisely to cope with this requirement of easing the integration process. To keep it lightweight, on top of the core concepts FIESTA-IoT ontology reuses some of the already defined concepts and relationships between the concepts. To name a few, these are: Platform defined via SSN, Instant defined via Time [65], QuantityKind and Unit defined through the M3-Lite taxonomy [66], Point defined through WGS84 [67], Metadata defined using IoT-lite, hasDataValue defined using DUL [68], hasDomainOfInterest defined using M3-lite taxonomy and location defined using WGS84.

## 3. Testbed Federation Concept and Conditions

The main aim of the FIESTA-IoT federation is to enable an EaaS paradigm for IoT experiments. However, instead of deploying yet another physical IoT infrastructure it enables experimenters to use a single EaaS API for executing experiments over multiple existing IoT testbeds that are federated in a testbed agnostic way [16]. Testbed agnostic implies in this case the ability to expose a single testbed that virtualizes the access to the underlying physical IoT testbeds. Experimenters learn once and accordingly use the EaaS API to access data from any of the underlying testbeds.

To this end, the testbeds that aim to participate in the federation have to implement the common standardized semantics and interfaces that have been defined within the FIESTA-IoT project. This enables the FIESTA-IoT meta-platform to access the data that their devices produce as well as the descriptions of their devices and the services that these devices might expose.

Figure 1 presents the abstract EaaS and testbed federation concepts overview for the of the FIESTA-IoT meta-platform. Its central component is a directory service (so-called FIESTA-IoT meta-directory), where sensors (or IoT resources) from multiple testbeds are registered along with the observations produced by them. This directory enables the dynamic discovery and use of IoT resources (e.g., sensors, actuators, services, etc.) from all the interconnected testbeds.

<figure><img src="image_3.png" /><figcaption>Figure 1. FIESTA-IoT Platform abstract EaaS and testbed federation concepts overview</figcaption></figure>
281 The key concept behind the federation of IoT testbeds is the specification of a common Testbed
282 API that defines the interfaces to carry out the registration of the testbed resources as well as pushing
283 of the observations to the meta-directory. Besides the actual technologies used for implementing
284 these interfaces, the main feature that underlies the FIESTA-IoT Testbed API is the fact that the
285 information is exchanged in a semantically annotated format.

286 In this sense, the main design decision is the use of semantic technologies to support the
287 interoperability between heterogeneous IoT platforms and testbeds. The FIESTA-IoT ontology [37,69]
288 makes it possible to seamlessly deal with data from different sources. The phenomena and units of
289 measurement related concepts have been incorporated to the FIESTA-IoT ontology through the M3-
290 Lite taxonomy. This taxonomy has been created by integrating and aligning already existing
291 ontologies in order to homogenize the existing scattered environment in which a quite large number
292 of similar ontologies define the same concepts in an overlapping manner.

293 Federated testbeds have to implement their own Semantic Annotators to transform the data they
294 handle internally to the common semantic ontology defined by FIESTA-IoT. Different RDF
295 representation formats (e.g. RDF/XML, JSON-LD, Turtle, etc.) are supported as long as the common
296 ontology is used.

297 The FIESTA-IoT Platform takes as reference the IoT ARM as defined in the IoT-A project [58].
298 ARM consists of Domain and Information model that also form a base for data that is being stored
299 in. Although, the model defines Resources [58] and IoT-Services [58], it misses to define the
300 observations [64] collected by the IoT-devices. FIESTA-IoT ontology considers all such aspects (see
301 Section 2) and thus enables the FIESTA-IoT architecture to be based on a canonical set of concepts
302 that all IoT platforms can easily adopt.

303 The adoption of these essential concepts only requires, from the underlying testbeds, a
304 straightforward tuning of the models that they handle internally. In this sense, independently of
305 which internal model the testbeds uses, whether it is proprietary or based on existing standards
306 [70,71], the Testbed Provider (TP) should be able to find in a quite straightforward manner how to
307 map the internal modelling to the canonical concepts managed within the FIESTA-IoT ontology. The
308 aforementioned tuning of models basically consist on mapping the internal structure of information
309 to the one that uses the FIESTA-IoT ontology as a basis. The less number of concepts to map and the
310 more fundamental these concepts are, the less the chances to have a TP that is unable to perform the
311 mapping between her internal data model and the interoperable model used within the FIESTA-IoT
312 Platform that is based in the FIESTA-IoT ontology.

313 The complete description of the FIESTA-IoT ontology is out of the scope of this paper. A
314 complete specification of the FIESTA-IoT ontology is defined in [37]. It is important to emphasize that
315 this ontology is the baseline for the interoperability of the heterogeneous testbeds and IoT platforms
316 that have been already federated and those that will be joining the FIESTA-IoT meta-platform in the
317 future. The different testbeds have to converge for participating in the federation and they use this
318 ontology as the reference for this convergence. Precisely this is the main reason why the ontology has
319 been kept simple as a design decision.

320 Since a testbed may internally use various standard and/or proprietary interfaces, in addition to
321 the semantic model that underpins the interaction between each of the testbeds and the FIESTA-IoT
322 Platform, a list of services (so-called Testbed Provider Interface – TPI) has been specified. A testbed
323 has to expose, at least, a subset of them in order to enable different connection methods to the
324 platform.

325 The TPI is a set of RESTful web services that spans across two different realms [16]. The first is
326 the FIESTA-IoT Platform side with the TPI Configuration & Management layer that controls the
327 functionality of the TPI. The second is the testbed side with the Testbed Provider Services (TPS) where
328 the TP has to implement a set of services that enables the management and manipulation of the
329 offered data. These services can be grouped into two types according to the relation established
330 between the testbed and the FIESTA-IoT Platform, namely get-based and push-based. For the Get
331 case, the services should respond with the latest observations from a list of sensors. For the Push case,
332 the services correspondingly initiate a stream at the testbed side that pushes the observations from a
333 list of sensors. In both cases, the list of sensors from whom the observations are retrieved or have to be pushed is the input parameter. The TPs can choose which of these two options fit better in their platforms and decide to either let the platform control the schedule (get-like option) or control the schedule of when to push the data (push-like option).

337 **4. Federated Testbeds**

338 This section summarizes the main characteristics and datasets available through the FIESTA-IoT Platform<fnref n="2" /> after the integration, until the time of writing this paper, of eleven different IoT infrastructures.

341 **4.1. Criteria for Testbed Federation**

342 The federation initially started with five testbeds being integrated with the platform to serve as reference implementations for testbed integration [72]. These were SmartSantander, SmartICS, SoundCity, Grasse Smart Territory and CABIN. In order to enlarge the value of the offer and also to proof the adequacy of the solutions designed to enable interoperability among heterogeneous IoT platforms, two open calls for testbed integration were conducted. As a result of these Calls, six more testbeds were selected.

348 The main aim of federating more IoT testbeds and not restricting it to the original four ones is to challenge the platform design. This way tuning of that design can be made by following the lessons learnt and best practices that can only be elicited from actual implementation. Moreover, addition of more application domains also brings further challenges that were not initially considered as they were not present in the initial set of testbeds. This selection was based on the following criteria:

353 • **Usefulness**: the degree of expected future use of the extension, which takes into account the amplitude (number and variety) of the testbed IoT resources, their nature (i.e. real or virtual resources), the testbed availability and the accessibility to the testbed resources for platform users during the whole project duration and beyond.

357 • **Complementarity**: the degree at which the testbed will provide new datasets and data streams, whereby it contributes to enlarge the critical mass of the existing experimentation support capacity offered by the 4 integrated testbeds, as well as to probe the interoperability solutions developed within the project, by providing additional datasets and data-streams on the domains of interest of the existing ones. Else, it can offer extra scenarios (smart agriculture, smart factory, crowd-sensing, underwater, etc.) with a high potential impact in terms of the real-world innovation enabled through the offered infrastructure and its associated datasets and data-streams.

365 • **Sustainability**: The guarantee of availability of the services offered by the extension in absence of future funding. This is linked with the history of the infrastructure and its demonstrable ability to support experimentation.

368 • **Technical competence**: The testbed provider should exhibit prior testbed management experience and the necessary qualifications to integrate their testbeds within the FIESTA-IoT federation.

371 • **Feedback**: The potential for providing feedback regarding the platform and the process of integrating new testbeds within the federation. Testbed providers must demonstrate value of the FIESTA-IoT federation procedures and/or motivate added-value extensions. Also, the business impact for joining the federation was considered.

375 Figure 2 illustrates the assessment of the testbeds based on the criteria set out in the Calls 376 processes. As it has been previously mentioned, the six testbeds whose key features are assessed in 377 Figure 2 are those that were selected during the Open Calls process. The remaining five testbeds were 378 the founding members of the federation.

<footnote n="2">² FIESTA-IoT Platform. https://platform.fiesta-iot.eu. [Online 3rd September 2018]</footnote>
The overall marks of the different testbeds are remarkable and interestingly high in Complementarity. This provides good insight on the heterogeneity that, in general, is exhibited by the compound offering of the federation of testbeds. This conclusion is also supported by the above average marks that all the testbeds received in the Feedback criterion. On the one hand it shows that the integration of these testbeds can generate valuable lessons learnt, which could not be elicited otherwise, and, on the other hand, it indicates, together with the respective Usefulness marks, the added-value of integrating the offerings from these testbeds.

<figure><img src="image_4.png" /><figcaption>Figure 2. Assessment of the six testbeds that joined the federation through Open Calls process</figcaption></figure>

Another criterion with several excellent marks is the Sustainability. While this is not related to the technical challenges brought forward by the inclusion of this testbed, it certainly demonstrates that the federated testbeds have a long track of previous and future IoT experimentation support.

## 4.2. Overall Federation Summary and Data Marketplace Offering

For almost all the cases, the IoT devices are actually located around the TP premises. However, since the SoundCity testbed is based on data stemming from smartphones, its actual coverage is not limited to Paris.

Table 1 provides a summary of the eleven testbeds and highlights roughly the application domain and the IoT devices that are part of each of the deployments. Further, the Table 2 presents categorization of the eleven testbed in different application domain.

<table><caption>Table 1. FIESTA-IoT testbeds summary</caption><thead><tr><td>Testbed</td><td>Short description</td><td>Deployed devices</td></tr></thead><tbody><tr><td>SmartSantander [73]</td><td>Large-scale Smart City deployment.</td><td>Thousands of fixed and mobile sensors (environment, parking, transportation, etc.).</td></tr><tr><td>SmartICS [74]</td><td>Smart Environment based on an indoor deployment of sensor nodes.</td><td>Hundreds of indoor environment sensors.</td></tr><tr><td>SoundCity [75]</td><td>Crowdsensing testbed using mobile phones</td><td>Variable number of phone-based sensors measuring noise pollution and proximity.</td></tr></tbody></table>
<table><tr><td>CABIN<fnref n="3" /></td><td>Indoor and outdoor environment smart building deployment with outdoor sensors.</td><td>Hundreds of indoor environmental sensors with tens of outdoor parking sensors.</td></tr><tr><td>NITOS [76]</td><td>Heterogeneous Lora and Wireless Sensor Network.</td><td>20 LoRa and 60 Zigbee indoor environmental and presence sensors.</td></tr><tr><td>MARINE<fnref n="4" /></td><td>Seawater and Air quality monitoring testbed.</td><td>4 floating seawater quality monitoring buoys and 5 fixed air quality monitoring stations (17 different sensor types).</td></tr><tr><td>RealDC</td><td>Live data center testbed for monitoring DC operations.</td><td>100 sensors for power consumption and weather station producing over 2000 observations.</td></tr><tr><td>Tera4Agri</td><td>Outdoor testbed for Smart Agriculture.</td><td>More than 10 sensors for environmental, soil and tree monitoring.</td></tr><tr><td>FINE</td><td>Smart City, smart building and home automation testbed.</td><td>40 outdoor environmental monitoring and 6 indoor automation sensors and actuators.</td></tr><tr><td>Grasse Smart Territory</td><td>Smart City testbed open to local developer community who bring their own sensors</td><td>5 sensor boxes with each containing multi environmental sensors.</td></tr><tr><td>ADREAM</td><td>Large-scale smart building testbed</td><td>6500 sensors for lighting, electricity, HVAC, solar panels, etc.</td></tr></table>

Most of these testbeds are internally using proprietary platforms which does not follow any specific standard or largely adopted IoT platform. CABIN testbed is based on oneM2M standard. However, it only implements the functional specifications and not the semantic ontology that has been recently defined by the ETSI oneM2M standard. ADREAM testbed uses a proprietary ontology [77] which is certainly aligned with the oneM2M base ontology but still is not part of any standard. Finally, SmartSantander testbed is based on FIWARE<fnref n="5" /> generic enablers and follows the data catalogues. All in all, the heterogeneity is, significantly, the main feature that can be derived from these testbeds.

<table><caption>**Table 2.** Categorization of Testbeds in different Application domain</caption><thead><tr><td>Application Domain</td><td>Testbeds</td></tr></thead><tbody><tr><td>Smart City</td><td>SmartSantander, SoundCity, CABIN, FINE, Grasse Territory</td></tr><tr><td>Smart Agriculture</td><td>Tera4Agri</td></tr><tr><td>Smart Buildings</td><td>SmartICS, CABIN, NITOS, FINE, ADREAM</td></tr><tr><td>Smart Energy</td><td>SmartICS, RealDC, ADREAM</td></tr><tr><td>Smart Sea</td><td>MARINE</td></tr></tbody></table>

<footnote n="3">³ CABIN testbed. http://developers.iotocean.org [Online 13th August 2018]</footnote>

<footnote n="4">⁴ GRIDNET. http://gridnet.gr/MARINE/ [Online 13th August 2018]</footnote>

<footnote n="5">⁵ FIWARE. https://www.fiare.org/ [Online 3rd September 2018]</footnote>
Overall, there is a reasonable balance between indoor and outdoor sensors (cf. Figure 3a) covering five wide application domains (cf. Figure 3b), namely smart city, smart building, smart energy, smart agriculture and smart sea). The spider graph in Figure 3b roughly represents the depth in which each of the application domains are covered attending to how many of the federated testbeds cover that particular domain. This creates a quite varied offering able to cope with the needs of a good number of potential IoT researchers and innovators which would like to assess their developments in a scenario excerpted from the combined offering.

Indoor vs outdoor testbed distribution

<figure><img src="image_5.png" /><figcaption>**Figure 3.** Application domains of the integrated sensors</figcaption></figure>

Application Domains supported by federated testbeds

<figure><img src="image_6.png" /></figure>

In addition to the general details, it is important to highlight the raw figures that the federation of testbeds is continuously providing in terms of active sensors and amount of observations generated. In this sense, Figure 4 shows these two key parameters evolution during second half of December 2017.

Observations and Active Sensors (per quarter of day)

<figure><img src="image_7.png" /><figcaption>**Figure 4.** Active sensors and generated observations during Dec’ 17</figcaption></figure>

More or less constantly, every 6 hours (time scale in X-axis is set to quarter of day for the sake of clarity), the testbeds’ federation is generating around 150,000 observations. These observations are coming, on average, from 2,000 active sensors that are continuously capturing events in its environment and reporting them to the platform. Appendix A. FIESTA-IoT testbeds detailed offering

Table 3 (in Appendix A) and Figure 5 present the detailed analysis of the offerings from each of the FIESTA-IoT testbeds. In contrast with information available on-line [78], the figures summarized in Appendix A. FIESTA-IoT testbeds detailed offering

Table 3 have been extracted from the actual FIESTA-IoT Platform, thus, presenting the actually available number of active sensors and their observations' generation frequency and not the textual description of testbeds that indicates the deployed devices but not the ones regularly producing
434

435

436

observations, which is the most relevant information for the experimenters willing to carry out their experiments on top of the FIESTA-IoT Platform. The key details presented in Appendix A. FIESTA-IoT testbeds detailed offering

437

438

439

440

441

Table 3, apart from the actual amount of devices producing data from each testbed, are the Phenomenon, which stands for the physical parameter observed, and the Quantity Kind, which stands for the Internationalized Resource Identifier (IRI) assigned in the FIESTA-IoT ontology to the respective physical phenomenon. This latter parameter is particularly important as it is the one that has to be used within the FIESTA-IoT Platform when looking for the corresponding phenomenon.

<figure><img src="image_8.png" /><figcaption>Figure 5. Amount of active sensors per phenomenon</figcaption></figure>

442

443

In terms of the covered application domains, the Smart Energy domain is the one that has both more active sensors and more generated observations. In this respect, the RealDC, SmartICS and ADREAM testbeds have a large set of IoT devices measuring the power consumption at its Data Centre, offices' desks and buildings respectively, which produce observations quite often.

444

445

446

447

<figure><img src="image_9.png" /><figcaption>Figure 6. Distribution of active sensors (a) and observations (b) per application domain</figcaption></figure>

448
449

450

451

452

453

454

455

456

457

458

459

Following, the Smart City deployments from the SmartSantander and FINE testbeds also contribute with a significant amount of observations and active sensors to the federation offering. Testbeds, such as CABIN and NITOS, characterized under Smart Building accounts for the sensors that are deployment at indoor environments measuring environmental conditions at the different buildings at which some of the federated testbeds are deployed. Last but not least, Smart Agriculture deployments (Tera4Agri) has a smaller but still relevant share of the available offering. Finally, there are several sensors made available by various testbeds that can be catalogued under other application domains (such as CrowdSensing - SoundCity, Smart Sea - MARINE, Testbed Management or Wireless Network Status - Grasse Territory) as well and still can be discovered by a researcher and/or innovator willing to experiment with them. More yet brief description about the testbeds is provided in Section 4.3.

## Active sensors for Smart City application domains

<figure><img src="image_10.png" /><figcaption>**Figure 7.** Distribution of active sensors per application sub-domain within the Smart City domain</figcaption></figure>

460

461

Interestingly, for the Smart City domain, several sub-domains (cf. Figure 7) are covered by the combined deployments. While SmartSantander deployment accounts for most of these active sensors, there are other testbeds like FINE or SoundCity that contribute with several environment monitoring sensors or CABIN that includes parking availability sensors, thus, enabling experiments that can be transparently applied to different cities.

462

463

464

465

466

## Active sensors for Smart Building application domains

<figure><img src="image_11.png" /><figcaption>**Figure 8.** Distribution of active sensors per application sub-domain within the Smart Building domain</figcaption></figure>

467

468
The other two large domains, in terms of available active sensors, are the Smart Energy and Smart Building. They can be combined into one since they are actually building energy management sensors the ones coming mainly from RealDC and ADREAM testbeds. For this combined domain, also some internal categorization can be made as presented in Figure 8. The other testbeds related to this category, like SmartICS, NITOS and CABIN contribute to the other big sub-domain, namely, building environmental conditions.

## 4.3. Federated testbeds overview

One of the largest testbed within FIESTA-IoT federation is the SmartSantander testbed. It is an experimental test facility for the research and experimentation of architectures, key enabling technologies, services and applications for the IoT in the context of a city. The infrastructure made up of 12,000 deployed diverse IoT devices covers a wide area of the city of Santander, located in the north of Spain. This testbed goes beyond the experimental validation of novel IoT technologies. It also aims at supporting the assessment of the socio-economical acceptance of new IoT solutions and the quantification of service usability and performance with end users in the loop.

SmartICS focuses on the domain of smart buildings and is deployed in the Institute of Communication Systems at the University of Surrey. It provides a facility for IoT experimentation using a variety of sensor devices deployed within the building. These sensor devices are mainly installed on office desks in the building and are used to capture a number of quantity kinds relating to air quality, ambient environment, energy consumption and desk occupancy. Observations from the devices are reported to a proprietary testbed server every minute. The proprietary testbed server keeps a register of all reporting sensor devices, and a data repository for each sensor device. Experimenters can interact with the testbed through a proprietary RESTful API, whereby sensors are exposed as dereferenceable web resources.

SoundCity testbed leverages the Ambiciti<fnref n="6" /> mobile application and the sensors within the smartphone to collect ambient noise measurements. On top of collecting such participatory data on a large scale, the Ambiciti mobile application provides its users with the ability to form groups and contribute to that specific group. The SoundCity testbed leverages such grouping feature and only federates data within the “FIESTA-IoT” group in the FIESTA-IoT platform.

CABIN (Context Aware smart BuildINg) is located on the KETI headquarter premises in Seongnam city, South Korea. This testbed is deployed using OCEAN³ open source software that implement oneM2M IoT platform global standard. The main purpose for the deployed infrastructure is to study building energy optimization considering human behavior. In addition to the indoor sensors, parking sensors are also deployed outside the building. The benefit of having the CABIN testbed is to ensure oneM2M TPS replicability for future oneM2M and FIESTA-IoT enabled testbeds.

NITOS Future Internet Facility is an integrated facility with heterogeneous testbeds that focuses on supporting experimentation-based research in wired networks, wireless networks and IoT in general. NITOS is remotely accessible and open to the research community 24/7 and supports evaluation of protocols and applications under real world settings. The testbed is based on open-source software that allows the design and implementation of new algorithms, enabling new functionalities on the existing hardware. NITOS WSN testbed is part of the overall facility and offers several NITOS Wireless Sensor Motes developed in house by NITlab<fnref n="7" /> and deployed in an office environment. NITOS WSN is a smart building testbed, capable of measuring environmental parameters with the purpose of providing the infrastructure upon which an experimenter can build own applications.

MARINE testbed has been deployed by GRIDNET⁴ for testing the performance of own prototype communication hardware enabling IoT applications in the marine and city environments. Testbed nodes are equipped with a wide variety of heterogeneous communication technologies, ranging from

<footnote n="6">⁶ Ambiciti. http://ambiciti.io [Online 13th August 2018]</footnote>

<footnote n="7">⁷ NITLab. https://nitlab.inf.uth.gr/ [Online 13th August 2018]</footnote>
516 IoT related standards (ZigBee, LoRa) to the widely adopted Wi-Fi and LTE protocols, along with a
517 unique real-time power monitoring framework for monitoring consumption of wireless interfaces.
518 Moreover, the nodes feature a wide set of environmental sensors (17 different sensor types), suitable
519 for application scenarios such as monitoring of water and air quality and detection of potential
520 dangers for inhabitants of the area. The facility currently consists of 8 fixed air quality monitoring
521 stations deployed in the city of Volos, Greece and 4 floating seawater quality monitoring buoys
522 deployed in a bathing and recreation coastal area, close to the city.

523 RealDC provides live Data Centre environmental information into the FIESTA-IoT ecosystem.
524 This integration comes in the form of power consumption, cooling and ambient weather. The data is
525 captured at five-minute intervals.

526 Tera4agri Testbed comprises of data collected from the monitoring of environment, soil and
527 trees. Thereby enabling the implementation of innovative experiments in the agriculture domain. The
528 testbed is located in Minervino Murge (Italy) in the Tormaresca - "Bocca di Lupo" (one of Italy's top
529 wineries) estate. The testbed collects data from the sensors using the Tera s.r.l.'s Internet of Everything
530 Gateway.

531 FINE facility provides an experimental testbed that is able to support innovative IoT applications
532 in the smart city domain. It utilizes RERUM architecture [79] for enabling the interconnectivity of a
533 large number of heterogeneous IoT devices based on the concept of security, privacy and reliability
534 by design. The testbed comprises several indoor and outdoor deployments in the city of Heraklion
535 in Crete, Greece, operating on 6LoWPAN and LoRaWAN communication technologies to aid
536 applications such as environmental monitoring, comfort quality and energy management and smart
537 parking.

538 The Grasse Smart Territory Testbed is an experimental testbed for Smart City applications for
539 the urban, suburb and rural areas of the City of Grasse. The main purpose of the testbed is to provide
540 experimental digital facilities and applications to the citizens to make life greener and more efficient
541 using state-of-the-art IoT technologies, and to make public authorities' managers understand the way
542 IoT technologies can benefit to citizens. It is developed with the collaboration of the local authorities
543 and other local associations and companies. The privileges are given to the use of LoRa technology
544 for the connectivity of devices, which can significantly extend the battery life on the field devices.
545 Several environmental sensors, i.e. CO2, pollen, humidity, are being deployed and tested to be
546 connected to the testbed.

547 The ADREAM building is a living lab providing a horizontal platform to foster research projects,
548 either focused on one aspect of the building or cross-domain. The building is meant to have as little
549 energy footprint as possible and is thus equipped with a large range of sensors to analyze its energy
550 consumption, as well as its production based on solar panels.

551 **5. Federation Process Discussion**

552 Interoperability is at the core of many IoT applications [80]. That is what the FIESTA-IoT
553 platform, with its unified interface and vocabulary enabling access to testbeds data, adds value to
554 said data by improving its interoperability. However, the original value remains within the data
555 itself, collected by each testbed individually and unified by the platform. Therefore, the value is
556 created by the testbeds, and improved by the platform. This section of the paper aims at describing
557 the scientific and technical challenges met during the integration of the currently federated testbeds,
558 in order to pave the way for future testbeds and ease their integration.

559 The integration of a testbed within the platform is a well-defined process, constituted of a series
560 of steps [16]:

561 • The testbed's data model is aligned to the FIESTA-IoT taxonomy;

562 • The testbed provider develops an annotator to enrich the data, and a TPS to expose it;

563 • The compliance of the annotated data and of the TPS are examined, and the testbed is
564 certified;

565 • The testbed and its resources (sensors) are registered on the platform;

566 • The testbed provider configures the data collection process.
567 Data arriving to the FIESTA-IoT Platform from the testbeds has to be semantically annotated
568 using the FIESTA-IoT Ontology. So, for the first step TPs can either develop the annotator themselves
569 or use the AaaS API provided by the FIESTA-IoT platform. After successfully generating the testbed's
570 annotator, the TP should decide on how the captured observations are going to be provided and
collaborate with the TPS accordingly. The two possibilities are to instruct FIESTA-IoT Platform to periodically
571 poll the testbed for the observations generated or to directly push observations into the FIESTA-IoT
572 Platform as they are generated. In order to facilitate the TP with the TPS development, FIESTA-IoT
573 provides a skeleton component in Java<fnref n="8" /> implementing all the services required by the FIESTA-IoT
574 Platform. From this skeleton, the TP would only need to develop the testbed's internal data access
575 and annotator integration. Once the TPS implementation is completed, the next step would be to
576 validate the implemented TPS and annotator. The FIESTA-IoT Platform includes a Certification
577 Portal that can be used by the TP to get FIESTA-IoT certified. Moreover, the tools available on this
578 Certification Portal can help the TP in the previous two steps. The next step would be to register the
579 available testbeds and resources to the FIESTA-IoT Platform. The TP can make use of the tools at the
580 FIESTA-IoT Platform Portal UI for this process. Finally, the TP should instantiate and schedule the
581 data pushing (testbed controls the scheduling) or retrieval (platform polls periodically).
582

583 In the remainder of this section, the challenges met at each step of this integration process are
described, as well as the mitigation strategies that have been implemented to face them. Indeed,
model alignment, data transformation or massive data publication are not trivial topics, present in
584 many IoT deployments [81] beyond the FIESTA-IoT platform. The description of these challenges
585 and their mitigations is followed by a discussion on the benefits for the TPs who joined the federation.
586
587

## 5.1. *Technical Requirements Discussion*

589 This section discusses the key lessons learnt and best practices that the experience of integrating
590 the previously described testbeds within the FIESTA-IoT Platform has allowed us to extract.

### 591 5.1.1 Preparing the integration

592 The testbeds are completely independent of each other, and the architectures they deploy are
593 highly heterogeneous. The purpose of the integration process described in this section is to lead these
594 initially unrelated data providers into compliance with the FIESTA-IoT platform interface, so that the
595 produced data is seamlessly consumable by the experimenters. At the end of the process, the testbed
596 is certified and is integrated into the federation.

#### 597 5.1.1.1 Data model alignment

598 The data within FIESTA-IoT platform is annotated with a single vocabulary, described using
599 M3-lite taxonomy [66]. Initially, as there is no constraint whatsoever on the testbeds internals, the
data model used by the testbeds are very diverse, and range from relational databases to datasets
600 semantically annotated with an ad-hoc vocabulary. The first step to providing interoperability over
601 the testbed data is to align its idiosyncratic data model to the common vocabulary.
602

603 **Challenges and mitigation:** One of the challenges met at this point in the federation is that some
604 subjective modelling choices do not allow a straightforward one to one equivalence mapping
605 between a testbed model and the target vocabulary (especially when a testbed has its own
606 vocabulary). Some elements implicit on the testbed side had to be made explicit to be compliant with
607 the platform, and knowledge that was stored in a several separate knowledge bases had to be
608 gathered in a single repository. As one of the mitigation strategies, FIESTA-IoT platform provides a
609 dedicated workflow for testbeds to propose updates to the vocabulary with the needed concepts.

<footnote n="8">⁸ Java Software Development Kit: http://www.oracle.com/technetwork/java/index.html [Online 13th August 2018]</footnote>
**Specific technical details:** As it has been already described, the FIESTA-IoT ontology has been designed for the basic modelling of any IoT system. This has been proven correct since all the 11 testbeds were able to accommodate to this basic modelling. However, while the core of the ontology has remained stable, the addition of testbeds to the federation has resulted in extensions to the ontology in terms of *QuantityKind* and *Unit*. These two classes are the parent classes used for describing the physical phenomenon observed and the unit of measurement used respectively. These classes are key both for describing the sensors and actuators that conform an IoT deployment as well as the observations that they generate. In this sense, while the core ontology uses the parent classes (i.e. *QuantityKind* and *Unit*), any sub-class from them can be used for describing IoT devices and observations. The workflow used to progressively update the FIESTA-IoT ontology basically consisted in requesting the TPs to make an initial study of the FIESTA-IoT ontology and only if none of the already existing sub-classes of *QuantityKind* and *Unit* met some of their needs, this is, one of their IoT devices observes a physical phenomenon not yet covered, they could make an argued request for addition. The requests for additions coming from the TPs were subsequently analyzed by the FIESTA-IoT ontology maintainers and incorporated if they were necessary. This process was straightforward in most of the cases. Only some iterations were necessary when the arguments incorporated to the request for addition were not clear enough. Most of the times the TPs seamlessly found the appropriate *QuantityKind* and *Unit* sub-classes that their testbeds needed.

### 5.1.1.2 Building a resource description

The FIESTA-IoT platform hosts the description of the devices that are associated to a testbed. Once the data model is aligned it is essential that resources are described in the needed format and are registered to the FIESTA-IoT platform. The FIESTA-IoT platform provides a tool to generate said descriptions in compliance with the vocabulary with a capability to register one device at a time or perform bulk upload if the annotations are already available.

**Challenges and mitigation:** As said in the previous section, testbeds that use semantics internally to store data have to comply with the unified FIESTA-IoT model. The generation of such mapping could be time consuming effort. For testbeds that already have a semantic description of their devices, the approach proposed by [82] allows the translation of the source description into the target using the alignment between data models. Moreover, for testbeds that do not have semantic descriptions at hand, using AaaS tool, a testbed can generate annotation of the resource description and can use them to register the resources. The services therein have capability to provide annotated descriptions to both resources and observations based on information that is provided to it post the data model alignment phase. On top of AaaS tool, FIESTA-IoT also provides best practices that a testbed should follow while producing annotations to harmonize and ease out building annotations.

**Specific technical details:** The AaaS tool leverages the baseline structure of the FIESTA-IoT ontology and the design criteria followed during its definition. In this sense, for generating the annotated version of their IoT devices, the TPs could directly take the FIESTA-IoT ontology and the examples provided in the handbook<fnref n="9" /> provided as training material, which provides best practices for producing valid annotations. However, it is highly recommended to make use of the AaaS tool. Not only because, it eases the process but also because it guarantees validity and certification of the testbed. In terms of IoT devices descriptions, the AaaS tool followed the cardinality included into the FIESTA-IoT ontology and defined through a JSON schema the mandatory attributes that must be included by the TPs for requesting the annotated description of one of their sensors. Basically, it requested a valid unique identifier, and its sensing and/or actuating capabilities. This latter aspect included the type of sensor and the physical phenomenon observed (or actuated upon). TPs were asked to provide the corresponding *SensingDevice*, *QuantityKind* and *Unit* sub-class from the FIESTA-IoT ontology. Additionally, the TPs had to include their testbed unique identifier in order to

<footnote n="9">⁹ FIESTA-IoT Handbook. http://moodle.fiesta-iot.eu/pluginfile.php/711/mod_resource/content/6/FIESTA-IoT_Handbook4ThirdParties_v4.3.pdf</footnote>
657 internally link their devices to their testbeds. Apart from the mandatory fields, the TPs could enrich
658 the descriptions of their devices with additional optional attributes. For example, the device location,
659 which was not mandatory to support mobile devices, or some metadata about the device sensing
660 capacities (e.g. its accuracy, frequency, etc.). The AaaS tool compiled the information provided by the
661 TP through a JSON document, posted to the RESTful AaaS' API, and generated the corresponding
662 RDF document. The AaaS allowed to generate the description of many devices at once.

663 5.1.1.3 Annotating observation data

664 Providing a unified access to resource observations requires said observations to be annotated
665 with the common vocabulary. This annotation can either be performed by the testbed if it has
666 semantic capabilities, or by the FIESTA-IoT platform using the AaaS tool mentioned in the previous
667 section.

668 **Challenges and mitigation:** As stated before, within FIESTA-IoT, there are different testbeds that
669 are associated with different application domains of IoT. Some testbeds such as SoundCity, SmartICS,
670 and ADREAM face privacy challenges when it comes to publishing data to open platforms such as
671 FIESTA-IoT. In order to publish data, such testbeds have to first get consent of users before the user
672 specific data can be published. Further, testbeds have to anonymize the data so that there is enough
673 noise when correlation of the published data sample to a particular user is performed. Privacy also
674 pose challenge when data attributes are not reported due to privacy concerns. This make it hard for
675 testbeds to comply with the FIESTA-IoT ontology causing annotations to fail the validation step. To
676 mitigate this problem, testbeds should set default value for the data attributes that are not reported.
677

678 **Specific technical details:** Similarly to the case of annotating the description of the testbed
679 resources, the AaaS tool offered the possibility to produce valid RDF documents for the observations
680 generated by that IoT devices. In this case, the mandatory fields, according to the concept's
681 cardinality defined by the FIESTA-IoT ontology, were, apart from the observation value, the
682 observation location, its timestamp, the identifier of the sensor that produced it and the physical
683 phenomenon observed, together with the unit of measurement. As it happened with the device
684 descriptions, these mandatory fields were available for all the testbeds so the integration was
685 seamless. It is important to highlight that this is only possible because of the appropriate design of
686 the FIESTA-IoT ontology, which has demonstrated its flexibility and scalability to accommodate the
687 integration of the eleven testbeds.

688 While the use of the AaaS for the generation of annotated resource descriptions is a process that
689 would not be so frequent (only at the initial testbed integration and when new IoT devices are
690 deployed at the testbed), its use for generating valid RDF-formatted observations had important
691 delay restrictions. The frequency with which a testbed produces an observation can be really big.
692 Thus, the AaaS should not increase the processing time too much. The implementation of the AaaS
693 kept the annotated observation generation time in the range of some milliseconds.

693 5.1.1.4 Implementing the TPS

694 The platform endpoint is publicly known, but each testbed has its own domain name and public
695 interfaces. To make it possible for the platform to collect data from the multiple testbeds, each testbed
696 has to implement on of the services from its TPS. From an architectural standpoint, the TPS is an
697 interworking proxy, hiding the internal specificities of each testbed under a common interface. Using
698 the TPS, the FIESTA-IoT platform is able to either actively collect data (pull-based approach) or to
699 subscribe for push-based publication initiated by the testbed. Implementing the former or the latter
700 is up to the testbed provider, depending on which is more convenient considering its own workflow.

701 **Challenges and mitigation:** In order to enable communication between the testbed and the
702 platform, access credentials have to be provided and right HTTP certificates have to be set. While
703 different identification methods are supported by the FIESTA-IoT Platform, the integrated testbeds
704 only used two of them: API Key over HTTPS connection and IP filtering. Indeed, only the first one
705 impose some requirements on FIESTA-IoT Platform while the second is transparently handled at the
706 testbed side. Being able to identify the issuer of a request to the testbed is a security issue, as it
707 prevents malicious requests to be processed.

708 Specific technical details: After successfully generating the testbed's annotator the TPs had to
709 functionally integrate the two domains at hand, this is, their testbeds and the FIESTA-IoT Platform.
710 For this functional integration, the TPI specification considers the main functionalities and properties
711 that should be exposed by IoT testbeds in order to enable their integration within the EaaS Platform
712 for the purposes of testbed-agnostic experimentation. The TPI spans across two different realms. On
713 the one side, the testbed side, the TPS API have to expose a set of services that enables the
714 management and manipulation of the offered data. At the other side, the FIESTA-IoT Platform side,
715 the behavior of the TPS methods is controlled from a set of services so-called TPI Data Management
716 Services (DMS). They enable the TPs to consume and control the TPS services that their testbeds
717 expose either by identifying a specific schedule or by enabling a data stream connection. The TPs
718 should decide on how the captured observations are going to be provided, this means if the "Get" or
719 the "Push" methodology is going to be used, and develop the TPS accordingly. In order to facilitate
720 the TP with the TPS development a skeleton component implementing all the required services has
721 been provided. This skeleton only requires the testbed's internal data access and annotator
722 integration.

### 723 5.1.1.5 Obtaining a certification

724 At this point, all the functionalities required for the testbed to be integrated to the federation are
725 implemented. To validate this implementation, the testbed must go through a certification process
726 available on the platform where the compliance of both resources and observations description are
727 evaluated along with the conformance of the TPS behavior with the specification.

728 **Challenges and mitigation:** Generally this step was not imposing any challenge in the process.
729 Indeed, as TPs are able to access the tools available on the Certification Portal<fnref n="10" /> as many times as
730 necessary, these tools were used for the tuning and polishing of their annotators and TPS
731 implementations. The key aspect that was necessary to highlight to the TPs was precisely that they
732 should use the certification process for their benefit instead of thinking that it is a hurdle to be
733 overcome.

734 **Specific technical details:** Before the TPs are provided with credentials to register their testbeds
735 at the FIESTA-IoT Platform, they have to obtain a certificate that the previous steps have been
736 accomplished correctly. The Certification Portal basically offers a set of tools for validating the
737 annotations and the TPS interfaces that the underlying testbed is offering. It is important to highlight
738 that it is recommended, as a best practice for the TPs, to exploit the tools available at the Certification
739 Portal during the development of their TPS interfaces and annotators and not restrict its use to the
740 pure certification. In this sense, TPs have an unlimited number of attempts at the Certification Portal
741 and it provides assessment reports on each attempt. Thus, the TPs are able to progressively fine tune
742 the annotations and TPS implementation according to the reports obtained.

743 For the validation of the annotators, the Certification Portal provided a generic semantic
744 validator that assessed both the syntactic (i.e. literals, URI and namespaces validation) and semantic
745 (i.e. predicate and class validation and semantic errors) analysis of the RDF documents provided.

746 For the TPS validation, the Portal had an interoperability testing tool which included tests for all
747 the possible TPS interfaces. TPs can provide the details of their TPS (endpoints, sensor identifiers,
748 API Key, etc.) and check if they behave as the FIESTA-IoT Platform expects.

### 749 5.1.2 Integrating the testbed

750 Once the testbed is certified, it is now ready to be integrated to the FIESTA-IoT platform.

751 As it has been described before, the testbed integration process consists on a number of steps
752 which requires actual interaction with FIESTA-IoT Platform interfaces. All the steps have been

<footnote n="10">¹⁰ FIESTA-IoT Certification Portal. https://certificate.fiesta-iot.eu</footnote>
streamlined to make then user-friendly. However, there are still best practices and lessons to be learnt that can only be acquired through actually taking the aforementioned steps. In this sense, all the steps have been briefly introduced at the beginning of this section and for each of them there is a specific aspect that, from the experience that we have acquired, must be carefully addressed. Thus, during the registration of testbed and devices, which is made through a graphical user interface, the testbed provider must take care of the correct alignment of testbed and resources description as the linked data paradigm is used within the FIESTA-IoT Platform and consistent information is critical in order to exploit the potential of this paradigm. For the configuration of the TPS, even when functional interoperability of interfaces had been previously certified, finding the most suited schedule is not always straightforward. Finally, confirming that the integration has been properly carried out and it is properly maintained in time (testbed integration is a continuous process) requires the execution of a number of tests that qualify this integration.

**Challenges and mitigation:** In order to allow the testbed providers to try out their deployment and fix issues incrementally, the FIESTA-IoT platform provides a controlled test environment. The challenges described in this section were tackled within the test environment, and had no impact on the experimenters, who interact with the actual production environment where the testbeds are only deployed when stable. The entire integration process is first performed in this test environment before being made public.

### 5.1.2.1 Registering the testbed and its resources

The first step to the testbed deployment is its registration, where some information about the testbed as a whole are provided, and in particular the endpoint of its TPS. Once the testbed is declared, its resources can be registered as it is described above. At this point, the resources of the testbed can be discovered by the experimenters, but no observation data has still been published.

**Challenges and mitigation:** Creating the annotated descriptions of the testbed devices can be a tough and complicated task mostly for providers that have little or no expertise with semantics and its peculiarities. Moreover, some of the testbeds had a large number of devices which could make this process time-consuming. The AaaS tool that was provided to the testbeds transforms this potentially complex step into a more user-friendly process in which testbed providers simply creates plain JSON documents from a simple template and through a single API call they can generate the descriptions from all the resources in their testbeds.

### 5.1.2.2 Configuring the TPS

The platform implements a tool to configure its behavior regarding the TPS. If the data is pushed by the TPS, the platform declares the resources it is interested in, and the TPS pushes data observed by these sensors as soon as it is available. Otherwise, the platform collects data from the platform at fixed intervals.

**Challenges and mitigation:** While configuring the TPS one challenge that occurs is that not all resources can be scheduled at a single time. This usually happens when a testbed has thousands of resources. To schedule all the resources it is advised that resources should be grouped in different chunks where each chunk has a different schedule to reduce the load of each individual push. Another issue is the impossibility to edit a schedule once it is registered. This makes it tedious for large testbed if some resources are not reliable, and require to be removed from the platform schedule individually.

### 5.1.3 Running the TPS and publishing data to the platform

At this point in the integration process, the testbed is compliant in every aspects with the FIESTA-IoT specification, and the data it generates can be consumed by the experimenters. The FIESTA-IoT platform acts as a data broker: there is no direct communication between the data producers and consumers, they only communicate with the platform through standardized interfaces.
**Challenges and mitigation:** Some challenges are faced when the TPS is running, especially in the virtual environment. One of the issues is the size of the bulk loads: the data that is transferred via TPS to the platform as RDF/XML. This data can be quite verbose leading to documents that are sometimes too large to be reliably transferred over the network. In order to keep the platform side as generic as possible, the mitigation strategies for this issue have to be implemented by the testbeds. In order to limit overload, the publications of data to the platform must be paced, and a 5-seconds break between the pushes ensures that the pushed data has been completely processed before publishing new data. Moreover, the datasets can be split into smaller subsets before being pushed to the platform. Once integrated to the knowledge graph on the platform's side, this bursting at publication type has not impact on the experimentations. Another issue is the lack of synchronism between the data collection and publication: depending on the testbeds inner configuration, data can only be published sometime after having been collected. This interval can be of several hours, up to days.

### 5.1.4 Technical integration concluding remarks

The evaluation of the testbed integration process was twofold. On the one hand, it was based on feedback provided by the Testbed Providers. The feedback focused on the assessment of the requirements, and the effort to address them, (like annotation process, certification of their testbeds, and interfaces implementation) in order to complete the testbed integration. As it is shown in Figure 9, most of them agreed that the ease of deployment was above satisfactory and they did not experience any significant degradation in terms of performance within their testbeds. This was expected as the integration process, as it has been presented above does not alter any of the internal procedures of the testbeds.

<figure><img src="image_12.png" /><figcaption>**Figure 9.** Evaluation of the testbed integration. Assessment of ease of setting up and deployment</figcaption></figure>

822

823

824

825

826

On the other hand, a non-functional evaluation was carried out focusing on the response times that the platform offered to the underlying testbeds upon they sent their observations for its storage into the FIESTA-IoT Platform.

<figure><img src="image_13.png" /><figcaption>**Figure 10.** Cumulative Distribution Function of processing times for observations' writings</figcaption></figure>

827

828
Figure 10 and Figure 11 shows the results from the performance analysis made. As it can be seen, 829 90% of the queries are handled in less than 4.1 seconds while the amount of queries taking more than 830 8 seconds is negligible. Moreover, it is interesting to highlight that more than half of the queries were 831 responded in less than 2 seconds. In that sense, we can notice that the distribution is not completely 832 exponential, and most probable processing times are around 10, 200 and 2000 milliseconds. In this 833 respect it is important to remind that testbeds were asked not to push individual observations but to 834 digest a number of them into each query. The amount of observations per query were dependent on 835 the size of the testbed and the nature of the observations. In this sense, smaller testbeds typically 836 digested all its observations (up to a couple of tens of them) in each query, while larger ones used a 837 digest size of 100 observations per query. Thus, the response times show this heterogeneity as it can 838 be clearly seen in Figure 11. However, even in the case of this larger batches of observations the 839 response time of the system was rather good. Note that in its semantic representation every 840 observation is composed of 7 objects. 841

<figure><img src="image_14.png" /><figcaption>Figure 11. Probability Density Function of processing times for observations' writings</figcaption></figure>

842
843
844
845
846
847
848
849
850
851

It is important to highlight that these results have been obtained under heavy load in terms of
the demand that the system was experiencing. As it is presented in [16], the performance evaluation
was carried out between 6th February 2018 and 15th March 2018. At that time, the amount of queries
that the FIESTA-IoT platform received each day was, in average, around 13,000 queries per day,
which is equivalent to 9 queries per minute. The FIESTA-IoT platform was not only storing the
observations coming from the 11 testbeds but also serving the experimenters' demands at the same
time. From the total amount of queries, Figure 12 presents the number of data writings (i.e. the
amount of queries for storing observations) coming from the underlying testbeds.
<figure><img src="image_15.png" /><figcaption>Figure 12. Observations' writings per day during the analyzed period</figcaption></figure>

As it can be seen, there were a massive and continuous flow of observations coming from the 11 testbeds towards the FIESTA-IoT Platform.

## 5.2. Federation Exploitation Discussion

The FIESTA-IoT federation has been currently joined by eleven heterogeneous IoT facilities spanning a wide range of application domains. In this section, we discuss the motivation behind joining the testbed federation, both for the testbeds and the affiliated organizations.

The key offering of FIESTA-IoT platform is a common set of Testbed tools and APIs enabling collection of data from any of the federated testbeds. The unified approach of instrumenting experiments and collecting data through a single point of access and set of tools offers unique ease of experimentation over the wide variety of supported testbeds. Developers who want to use existing platforms need to negotiate access individually and adapt to the platform-specific API and information models. Having to perform these actions for each platform often limits the applicability of the developed applications as they have to be tailored to the different platforms. This fragmentation of the IoT and the missing interoperability result in high entry barriers for developers. Considering the complex case of experimenters interested in simultaneously accessing data stemming from multiple testbeds, we understand the advantage of employing the federation that inherently supports such scenarios, through the orchestration of a single experimental description.

The federation driven ease of use and ability to offer open data access generate direct advantages for connected testbeds, such as the expanded user base and platform visibility. In addition, the accumulated access of external users through the common platform portal has the potential to introduce users to new interesting testbeds and resources and further increase the individual testbed community. The federation also attracts totally new types of users that are not directly interested in the underlying facilities, but specifically in the applied semantic technologies, potentially searching for semantic interoperability with their data or application. The increased platform visibility offers also the potential for creating synergies between academic experimenters and industrial developers.

At the heart of the federation-enabling mechanisms lies the common semantic ontology, which serves as means for linking related data streams and ensuring interoperability of data stemming from totally heterogeneous resources. The federation includes testbeds like CABIN and ADREAM that had previously incorporated semantic technologies in their platform operation, which had to work towards aligning their existing taxonomy and vocabulary with the FIESTA-IoT ontology. On the other hand, facilities like MARINE and RealDC had their first experience in implementing common standardized semantics, by joining the federation. Such developments directly benefited the testbeds adopting semantic technologies to query their resources more effectively and layer sophisticated
887 analytics on top of collected data. In addition, the adoption of M3-Lite taxonomy by the FIESTA-IoT
888 ontology has offered semantic interoperability with other testbeds too. Summing up, we remark that
889 all federated testbeds gained significant experience in working with semantically annotated data and
890 applying semantic technologies in-field, which can be beneficial for future projects as well.

891 Moreover, there are also other important benefits that must not be neglected. Firstly, the great
892 dissemination opportunities, stemming from the overall project's promotion and marketing
893 activities, which offer increased visibility to all federated testbeds and affiliated organizations.
894 Secondly, the ability of all participating members to directly strengthen their position in the IoT and
895 testbed experimentation communities, resulting in increased qualification for attracting additional
896 funding through relevant research initiatives (EU research calls, etc.) or through potential
897 organizations interested in using the testbed resources and offered measurements.

898 Last but not least, FIESTA-IoT Platform has proven successful in realizing the open data concept
899 that FIESTA-IoT/EU is supporting in order to democratize the access to data. Not just in the sense of
900 simply opening the data but increasing the meaningfulness of this data as the datasets are upgraded
901 through the interoperability feature that the FIESTA-IoT Platform Error! Bookmark not defined. design and
902 implementation intrinsically conveys.

903 6. Conclusions

904 Supporting real-world experimentation is undoubtedly part of the innovation cycle for any
905 technological advance. In view of the attention that the IoT is attracting, several IoT open
906 infrastructures have been deployed all around the world. Even if the usefulness of these experimental
907 infrastructures in their own right is out of any doubt, the ecosystem that they have created is scattered
908 and domain specific. It is deemed necessary to offer a homogeneous and interoperable framework
909 that can actually fulfil the requirements from IoT research and innovation communities. These
910 communities are in need of an IoT data marketplace that can serve them with cross-domain,
911 interoperable, real-world data and environments.

912 In this paper, we have described the instantiation of such an environment stemming through
913 the federation of eleven different IoT deployments. The resulting environment offers, to the best of
914 our knowledge, the highest level of diversity and scale available through any single or federated IoT
915 experimentation infrastructure, integrating totally heterogeneous application domains (e.g. smart
916 cities, maritime, smart building, crowd-sensing, smart grid, etc.) and offering over 10,000 IoT devices.
917 The paper briefly introduces, for the sake of completeness, the high-level architecture and key
918 technologies employed for the realization of this unique federation of heterogeneous IoT
919 infrastructures. In addition, the key paper contribution is presented through the analysis of the
920 insightful summary of the actual data offerings and key characteristics of all the testbeds that are
921 currently federated. For the community of IoT-based innovators and developers it is of utmost
922 importance to be acquainted with the real offerings stemming from the unparalleled ecosystem for
923 IoT experimentation that the interoperable federation of testbeds described in the paper is making
924 available [83].

925 Moreover, the paper summarizes first hand experiences, lessons learnt and best practices that
926 have been elicited during the integration of the testbeds. The description of the challenges faced
927 during the integration process and their mitigations is followed by a discussion on the benefits for
928 the TPs who joined the federation. The discussion included in the paper condenses the views of the
929 different testbed providers and, apart from describing the techniques employed to fulfil the technical
930 challenges associated with the federation of heterogeneous IoT platforms, it should be extremely
931 valuable for other infrastructure owners that might consider joining the current federation of
932 testbeds.

933 In order to highlight the value of the contributions of this paper, it is important to mention that
934 the platform design represents the necessary condition for supporting IoT experimentation, as it
935 enables the dynamic discovery of resources and their data. However, it is only through the actual
936 federation of testbeds described in the paper that the sufficient condition is met. Thus, we remark the
937 significant value of our work for the IoT research community, since it is essentially the federation of
testbeds the one that tangibly (i.e. not as an academic exercise but in the real-world) enables the dynamic on-demand formulation of cloud-based IoT services over a virtualized Data Marketplace.

The contributions of the paper are the description of the resulting federation of testbeds and the lessons learnt during the process of federating one testbed. Details of the actual platform and insights about the technical details about the platform that supports the federation are out of the scope of the paper. However, the semantically-enabled multi-domain data marketplace can be accessed on-line. In this sense, the testbed federation itself is, implicitly, the proof for the realization of this concept. Through the tools available from the FIESTA-IoT Platform², the experimenters can discover and access the whole variety of datasets and develop their research or innovative applications. The experimenters are able to discover the offerings from the data marketplace independently of the origin of the data. They only have to follow the FIESTA-IoT ontology while browsing and consuming the data that the underlying testbeds have previously pushed.

Future lines of development will include the development of cross-domain data analytics. Having the ability to apply data mining or machine learning techniques on top of the federation presented in this paper will have a twofold benefit. On the one hand, analytics developers benefit from the homogeneous access to heterogeneous datasets, thus, maximizing the re-utilization of the developed algorithms and minimizing the burden of having access to information that nowadays are part of different vertical. On the other hand, re-use of the techniques and services (like dashboards, KPIs derivation) developed for any of the testbeds federated boosts the attractiveness of the federation itself. In particular, data quality and infrastructure performance insights should be of great interest to IoT infrastructure providers who, in the majority of the cases, are experts in managing the physical infrastructure but does not have the know-how to effectively manage and curate the data that the infrastructure is producing and, more important, their customers consuming.

**Acknowledgments:** This work is partially funded by the European project "Federated Interoperable Semantic IoT/cloud Testbeds and Applications (FIESTA-IoT)" from the European Union's Horizon 2020 Programme with the Grant Agreement No. CNECT-ICT-643943. The authors would also like to thank the FIESTA-IoT consortium for fruitful discussions.

**Author Contributions:** L. Sanchez has carried out the editorship of the paper and contributed to the Related Work and Overall Federation Summary and Data Marketplace Offering sections. J. Lanza described and integrated the SmartSantander testbed; J.R. Santana performed the performance analysis of the testbed federation; R. Agarwal and P. G. Raverdy contributed with the description and integration of SoundCity testbed; correspondingly T. Elsaleh and Y. Fathy provide input related to the SmartICS testbed; S. Jeong described CABIN testbed; A. Dadoukis and T. Korakis provided the content related to NITOS testbed; S. Keranidis lead the edition and contributions to section 5.2 in addition to the integration and description of MARINE testbed; P. O'Brien and J. Horgan contributed with the RealDC testbed sketch; A. Sacchetti and G. Mastandrea worked on the integration of Tera4Agri testbed; A. Fragkiadakis and P. Charalampidis integrated and described FINE testbed; N. Seydoux lead the edition and contributions to section 5.1 in addition to the description and integration of ADREAM testbed, which was also carried out by C. Ecrepont; Finally, M. Zhao authored the content related to the Grasse Smart Territory testbed. J. Lanza, L. Sanchez, R. Agarwal, T. Elsaleh and M. Zhao have lead the design, implementation and integration of many components of the FIESTA-IoT Platform which underlies the testbed integration described in this paper.

**Conflicts of Interest:** "The authors declare no conflict of interest."

## 983 References

1. Thomke, S. H. *Experimentation matters: unlocking the potential of new technologies for innovation*; Harvard Business School Press, 2003; ISBN 9781578517503.

2. Rachedi, A.; Rehmani, M. H.; Cherkaoui, S.; Rodrigues, J. J. P. C. IEEE Access Special Section Editorial: The Plethora of Research in Internet of Things (IoT). *IEEE Access* **2016**, *4*, 9575–9579,
988 doi:10.1109/ACCESS.2016.2647499.

989 3. Almeida, A.; Fiore, A.; Mainetti, L.; Mulero, R.; Patrono, L.; Rametta, P. An IoT-Aware Architecture for
990 Collecting and Managing Data Related to Elderly Behavior. *Wirel. Commun. Mob. Comput.* **2017**, *2017*, 1-
991 17, doi:10.1155/2017/5051915.

992 4. Zheng, K.; Zhao, S.; Yang, Z.; Xiong, X.; Xiang, W. Design and Implementation of LPWA-Based Air
993 Quality Monitoring System. *IEEE Access* **2016**, *4*, 3238–3245, doi:10.1109/ACCESS.2016.2582153.

994 5. Tsai, K.-L.; Leu, F.-Y.; You, I. Residence Energy Control System Based on Wireless Smart Socket and IoT.
995 *IEEE Access* **2016**, *4*, 2885–2894, doi:10.1109/ACCESS.2016.2574199.

996 6. Wan, J.; Yi, M.; Li, D.; Zhang, C.; Wang, S.; Zhou, K. Mobile Services for Customization Manufacturing
997 Systems: An Example of Industry 4.0. *IEEE Access* **2016**, *4*, 8977–8986, doi:10.1109/ACCESS.2016.2631152.

998 7. Al-Fuqaha, A.; Guizani, M.; Mohammadi, M.; Aledhari, M.; Ayyash, M. Internet of Things: A Survey on
999 Enabling Technologies, Protocols, and Applications. *IEEE Commun. Surv. Tutorials* **2015**, *17*, 2347–2376,
1000 doi:10.1109/COMST.2015.2444095.

1001 8. Jara, A. J.; Genoud, D.; Bocchi, Y. Big data for smart cities with KNIME a real experience in the
1002 SmartSantander testbed. *Softw. Pract. Exp.* **2015**, *45*, 1145–1160, doi:10.1002/spe.2274.

1003 9. Treboux, J.; Jara, A. J.; Dufour, L.; Genoud, D. A predictive data-driven model for traffic-jams forecasting
1004 in smart santander city-scale testbed. In *2015 IEEE Wireless Communications and Networking Conference
1005 Workshops (WCNCW)*; IEEE, 2015; pp. 64–68.

1006 10. Sanchez, L.; Muñoz, L.; Galache, J. A.; Sotres, P.; Santana, J. R.; Gutierrez, V.; Ramdhany, R.; Gluhak, A.;
1007 Krco, S.; Theodoridis, E.; others SmartSantander: IoT experimentation over a smart city testbed. *Comput.
1008 Networks* **2014**, *61*, 217–238.

1009 11. Adjih, C.; Baccelli, E.; Fleury, E.; Harter, G.; Mitton, N.; Noel, T.; Pissard-Gibollet, R.; Saint-Marcel, F.;
1010 Schreiner, G.; Vandaele, J.; Watteyne, T. FIT IoT-LAB: A large scale open experimental IoT testbed. In
1011 *IEEE 2nd World Forum on Internet of Things (WF-IoT)*; IEEE, 2015; pp. 459–464.

1012 12. Latre, S.; Leroux, P.; Coenen, T.; Braem, B.; Ballon, P.; Demeester, P. City of things: An integrated and
1013 multi-technology testbed for IoT smart city experiments. In *2016 IEEE International Smart Cities
1014 Conference (ISC2)*; IEEE, 2016; pp. 1–8.

1015 13. Gluhak, A.; Krco, S.; Nati, M.; Pfisterer, D.; Mitton, N.; Razafindralambo, T. A survey on facilities for
1016 experimental internet of things research. *IEEE Commun. Mag.* **2011**, *49*, 58–67,
1017 doi:10.1109/MCOM.2011.6069710.

1018 14. Tonneau, A.-S.; Mitton, N.; Vandaele, J. A Survey on (mobile) Wireless Sensor Network Experimentation
1019 Testbeds. In *IEEE International Conference on Distributed Computing in Sensor Systems*; IEEE, 2014; pp. 263–
1020 268.

1021 15. FIESTA-IoT Project Available online: http://fiesta-iot.eu/ (accessed on May 10, 2018).

1022 16. Lanza, J.; Sánchez, L.; Santana, J. R.; Agarwal, R.; Kefalakis, N.; Grace, P.; Elsaleh, T.; Zhao, M.; Tragos,
1023 E.; Nguyen, H.; Cirillo, F.; Steinke, R.; Soldatos, J. Experimentation as a Service over Semantically
1024 Interoperable Internet of Things Testbeds. *IEEE Access* **2018**, *6*, doi:10.1109/ACCESS.2018.2867452.

1025 17. Coulson, G.; Anwander, M.; Wagenknecht, G.; Fekete, S. P.; Kröller, A.; Baumgartner, T.; Porter, B.;
1026 Chatzigiannakis, I.; Koninis, C.; Fischer, S.; Pfisterer, D.; Bimschas, D.; Braun, T.; Hurni, P. Flexible
1027 experimentation in wireless sensor networks. *Commun. ACM* **2012**, *55*, 82, doi:10.1145/2063176.2063198.

1028 18. Vandenberghe, W.; Vermeulen, B.; Demeester, P.; Willner, A.; Papavassiliou, S.; Gavras, A.; Sioutis, M.;
1029 Quereilhac, A.; Al-Hazmi, Y.; Lobillo, F.; others Architecture for the heterogeneous federation of future
1030 internet experimentation facilities. In *Future Network and Mobile Summit*; 2013; pp. 1–11.
1031 19. Kavoussanakis, K.; Hume, A.; Martrat, J.; Ragusa, C.; Gienger, M.; Campowsky, K.; Van Seghbroeck, G.; Vázquez, C.; Velayos, C.; Gittler, F.; others Bonfire: The clouds and services testbed. In *Cloud Computing Technology and Science (CloudCom), 2013 IEEE 5th International Conference on*; 2013; Vol. 2, pp. 321–326.

1034 20. Berman, M.; Chase, J. S.; Landweber, L.; Nakao, A.; Ott, M.; Raychaudhuri, D.; Ricci, R.; Seskar, I. GENI: A federated testbed for innovative network experiments. *Comput. Networks* **2014**, *61*, 5–23, doi:10.1016/J.BJP.2013.12.037.

1037 21. Misra, A.; Balan, R. K. LiveLabs. *ACM SIGMOBILE Mob. Comput. Commun. Rev.* **2013**, *17*, 47–59, doi:10.1145/2557968.2557975.

1039 22. Cardone, G.; Cirri, A.; Corradi, A.; Foschini, L. The participact mobile crowd sensing living lab: The testbed for smart cities. *IEEE Commun. Mag.* **2014**, *52*, 78–85, doi:10.1109/MCOM.2014.6917406.

1041 23. Banerjee, P.; Friedrich, R.; Bash, C.; Goldsack, P.; Huberman, B.; Manley, J.; Patel, C.; Ranganathan, P.; Veitch, A. Everything as a service: Powering the new information economy. *Computer (Long. Beach. Calif.)* **2011**, *44*, 36–43.

1044 24. Alay, Ö.; Lutu, A.; Peón-Quirós, M.; Mancuso, V.; Hirsch, T.; Evensen, K.; Hansen, A.; Alfredsson, S.; Karlsson, J.; Brunstrom, A.; others Experience: An open platform for experimentation with commercial mobile broadband networks. In *Proceedings of the 23rd Annual International Conference on Mobile Computing and Networking*; 2017; pp. 70–78.

1048 25. Boniface, M.; Crowle, S.; Phillips, S.; Rosati, J.; Trossen, D.; Carrozzo, G. Experimentation-as-a-Service methodology for building urban-scale media ecosystems. **2017**.

1050 26. Perera, C.; Zaslavsky, A.; Christen, P.; Georgakopoulos, D. Sensing as a service model for smart cities supported by Internet of Things. *Trans. Emerg. Telecommun. Technol.* **2014**, *25*, 81–93, doi:10.1002/ett.2704.

1052 27. Nati, M.; Gluhak, A.; Domaszewicz, J.; Lalis, S.; Moessner, K. Lessons from smartcampus: external experimenting with user-centric internet-of-things testbed. *Wirel. Pers. Commun.* **2017**, *93*, 709–723.

1054 28. Santana, J. R.; Galache, J. A.; Akiyama, T.; Gurgen, L.; Matsuoka, M.; Maggio, M.; Murata, S. Festival: Towards an intercontinental federation approach. In *International Conference on Mobile Networks and Management*; 2015; pp. 269–280.

1057 29. Gutiérrez, V.; Theodoridis, E.; Mylonas, G.; Shi, F.; Adeel, U.; Diez, L.; Amaxilatis, D.; Choque, J.; Camprodom, G.; McCann, J.; others Co-creating the cities of the future. *Sensors* **2016**, *16*, 1971–1997.

1059 30. Willner, A.; Giatili, M.; Grosso, P.; Papagianni, C.; Morsey, M.; Baldin, I. Using Semantic Web Technologies to Query and Manage Information within Federated Cyber-Infrastructures. *Data* **2017**, *2*, 21, doi:10.3390/data2030021.

1062 31. Avgeris, M.; Kalatzis, N.; Dechouniotis, D.; Roussaki, I.; Papavassiliou, S. Semantic Resource Management of Federated IoT Testbeds. In *16th International Conference on Ad-Hoc Networks and Wireless*; 2017; pp. 25–38.

1065 32. Jabbar, S.; Ullah, F.; Khalid, S.; Khan, M.; Han, K. Semantic Interoperability in Heterogeneous IoT Infrastructure for Healthcare. *Wirel. Commun. Mob. Comput.* **2017**, *2017*, 1–10, doi:10.1155/2017/9731806.

1067 33. Tachmazidis, I.; Batsakis, S.; Davies, J.; Duke, A.; Vallati, M.; Antoniou, G.; Clarke, S. S. A Hypercat-enabled semantic Internet of Things data hub. In *16th European Semantic Web Conference*; 2017; Vol. 10250 LNCS, pp. 125–137.

1070 34. D'elia, A.; Viola, F.; Azzoni, P. Enabling Interoperability in the Internet of Things: A OSGi Semantic Information Broker Implementation. *Int. J. Semant. Web Inf. Syst.* **2017**, *13*, 147–167, doi:10.4018/IJSWIS.2017010109.

1073 35. Palavalli, A.; Karri, D.; Pasupuleti, S. Semantic Internet of Things. In *IEEE Tenth International Conference*
1074 on Semantic Computing (ICSC); IEEE, 2016; pp. 91–95.

1075 36. Kovacs, E.; Bauer, M.; Kim, J.; Yun, J.; Le Gall, F.; Zhao, M. Standards-Based Worldwide Semantic Interoperability for IoT. *IEEE Commun. Mag.* **2016**, *54*, 40–46, doi:10.1109/MCOM.2016.1600460CM.

1076 37. Agarwal, R.; Fernandez, D. G.; Elsaleh, T.; Gyrard, A.; Lanza, J.; Sanchez, L.; Georgantas, N.; Issarny, V. Unified IoT ontology to enable interoperability and federation of testbeds. In *IEEE 3rd World Forum on Internet of Things (WF-IoT)*; IEEE, 2016; pp. 70–75.

1079 38. Schomm, F.; Stahl, F.; Vossen, G. Marketplaces for data. *ACM SIGMOD Rec.* **2013**, *42*, 15, doi:10.1145/2481528.2481532.

1082 39. Gubbi, J.; Buyya, R.; Marusic, S.; Palaniswami, M. Internet of Things (IoT): A vision, architectural elements, and future directions. *Futur. Gener. Comput. Syst.* **2013**, *29*, 1645–1660, doi:10.1016/J.FUTURE.2013.01.010.

1085 40. Misura, K.; Zagar, M. Data marketplace for Internet of Things. In *2016 International Conference on Smart Systems and Technologies (SST)*; IEEE, 2016; pp. 255–260.

1087 41. Ma, Y.; Rao, J.; Hu, W.; Meng, X.; Han, X.; Zhang, Y.; Chai, Y.; Liu, C. An efficient index for massive IOT data in cloud environment. In *Proceedings of the 21st ACM international conference on Information and knowledge management - CIKM '12*; ACM Press: New York, New York, USA, 2012; p. 2129.

1090 42. Li, T.; Liu, Y.; Tian, Y.; Shen, S.; Mao, W. A Storage Solution for Massive IoT Data Based on NoSQL. In *2012 IEEE International Conference on Green Computing and Communications*; IEEE, 2012; pp. 50–57.

1092 43. Broring, A.; Schmid, S.; Schindhelm, C.-K.; Khelil, A.; Kabisch, S.; Kramer, D.; Le Phuoc, D.; Mitic, J.; Anicic, D.; Teniente, E. Enabling IoT Ecosystems through Platform Interoperability. *IEEE Softw.* **2017**, *34*, 54–61, doi:10.1109/MS.2017.2.

1095 44. Carrez, F.; Elsaleh, T.; Gomez, D.; Sanchez, L.; Lanza, J.; Grace, P. A Reference Architecture for federating IoT infrastructures supporting semantic interoperability. In *2017 European Conference on Networks and Communications (EuCNC)*; IEEE, 2017; pp. 1–6.

1098 45. Ramparany, F.; Marquez, F. G.; Soriano, J.; Elsaleh, T. Handling smart environment devices, data and services at the semantic level with the FI-WARE core platform. In *2014 IEEE International Conference on Big Data (Big Data)*; IEEE, 2014; pp. 14–20.

1101 46. Kovacs, E.; Bauer, M.; Kim, J.; Yun, J.; Le Gall, F.; Zhao, M. Standards-Based Worldwide Semantic Interoperability for IoT. *IEEE Commun. Mag.* **2016**, *54*, 40–46, doi:10.1109/MCOM.2016.1600460CM.

1103 47. Botts, M.; Percivall, G.; Reed, C.; Davidson, J. OGC® Sensor Web Enablement: Overview and High Level Architecture. In *GeoSensor Networks*; Nittel, S., Labrinidis, A., Stefanidis, A., Eds.; Springer, Berlin, Heidelberg, 2008; pp. 175–190.

1106 48. Web of Things at W3C Available online: https://www.w3.org/WoT/ (accessed on May 10, 2018).

1107 49. Paganelli, F.; Turchi, S.; Giuli, D. A Web of Things Framework for RESTful Applications and Its Experimentation in a Smart City. *IEEE Syst. J.* **2016**, *10*, 1412–1423, doi:10.1109/JSYST.2014.2354835.

1109 50. Keppmann, F. L.; Maleshkova, M.; Harth, A. Semantic Technologies for Realising Decentralised Applications for the Web of Things. In *2016 21st International Conference on Engineering of Complex Computer Systems (ICECCS)*; IEEE, 2016; pp. 71–80.

1112 51. Nagib, A. M.; Hamza, H. S. SIGHTED: A Framework for Semantic Integration of Heterogeneous Sensor Data on the Internet of Things. *Procedia Comput. Sci.* **2016**, *83*, 529–536, doi:10.1016/J.PROCS.2016.04.251.

1114 52. Wu, Z.; Xu, Y.; Zhang, C.; Yang, Y.; Ji, Y. Towards Semantic Web of Things: From Manual to Semi-automatic Semantic Annotation on Web of Things. In *2016 International Conference on Big Data Computing and Communications*; Shenyang, China, 2016; pp. 295–308.
1117 53. Chien, S.; Cichy, B.; Davies, A.; Tran, D.; Rabideau, G.; Castano, R.; Sherwood, R.; Mandl, D.; Frye, S.; Shulman, S.; others An autonomous earth-observing sensorweb. *IEEE Intell. Syst.* **2005**, *20*, 16–24.

1118
1119 54. Di, L.; Moe, K.; van Zyl, T. L. Earth observation sensor web: An overview. *IEEE J. Sel. Top. Appl. Earth Obs. Remote Sens.* **2010**, *3*, 415–417.

1120
1121 55. Chien, S.; Tran, D.; Doubleday, J.; Davies, A.; Kedar, S.; Webb, F.; Rabideau, G.; Mandl, D.; Frye, S.; Song, W.; others A multi-agent space, in-situ Volcano SensorWeb. In *International Symposium on Space Artificial Intelligence, Robotics, and Automation for Space (i-SAIRAS 2010), Sapporo, Japan*; 2010.

1124 56. Compton, M.; Barnaghi, P.; Bermudez, L.; Garc\iA-Castro, R.; Corcho, O.; Cox, S.; Graybeal, J.; Hauswirth, M.; Henson, C.; Herzog, A.; others The SSN ontology of the W3C semantic sensor network incubator group. *Web Semant. Sci. Serv. agents World Wide Web* **2012**, *17*, 25–32.

1127 57. Semantic Sensor Network Ontology Available online: https://www.w3.org/TR/vocab-ssn/ (accessed on May 10, 2018).

1129 58. Bassi, A.; Bauer, M.; Fiedler, M.; Kramp, T.; Van Kranenburg, R.; Lange, S.; Meissner, S. *Enabling things to talk*; Bassi, A., Bauer, M., Fiedler, M., Kramp, T., van Kranenburg, R., Lange, S., Meissner, S., Eds.; Springer, 2013; ISBN 978-3-642-40402-3.

1132 59. *TS-0012 oneM2M Base Ontology*; 2016;

1133 60. Daniele, L.; den Hartog, F.; Roes, J. Created in Close Interaction with the Industry: The Smart Appliances REFerence (SAREF) Ontology. In: Springer, Cham, 2015; pp. 100–112.

1135 61. Bajaj, G.; Agarwal, R.; Singh, P.; Georgantas, N.; Issarny, V. *A study of existing Ontologies in the IoT-domain*; 2017;

1137 62. Bermudez-Edo, M.; Elsaleh, T.; Barnaghi, P.; Taylor, K. IoT-Lite: A Lightweight Semantic Model for the Internet of Things. In *Intl IEEE Conferences on Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress*; IEEE, 2016; pp. 90–97.

1141 63. De, S.; Barnaghi, P.; Bauer, M.; Meissner, S. Service modelling for the Internet of Things. In *Federated Conference on Computer Science and Information Systems*; 2011; pp. 949–955.

1143 64. Observation description from Semantic Sensor Network (SSN) Ontology Available online: https://www.w3.org/TR/vocab-ssn/#SOSAObservation (accessed on May 24, 2018).

1145 65. Time Ontology in OWL Available online: https://www.w3.org/TR/owl-time/ (accessed on May 25, 2018).

1146 66. M3-Lite Taxonomy Documentation Available online: http://ontology.fiesta-iot.eu/ontologyDocs/m3-lite.html (accessed on May 24, 2018).

1148 67. Basic Geo (WGS84 lat/long) Vocabulary Available online: https://www.w3.org/2003/01/geo/ (accessed on May 25, 2018).

1150 68. DOLCE Ultra-Lite ontology Available online: http://www.loa.istc.cnr.it/ontologies/DUL.owl (accessed on May 25, 2018).

1152 69. FIESTA-IoT Ontology Documentation Available online: http://ontology.fiesta-iot.eu/ontologyDocs/fiesta-iot.html (accessed on May 24, 2018).

1154 70. Cox, S. Observations and measurements. *Open Geospatial Consort. Best Pract. Doc. Open Geospatial Consort.* **2006**, *21*.

1156 71. FIWARE Data Models Available online: https://www.fiare.org/developers/data-models/ (accessed on May 24, 2018).

1158 72. Lanza, J.; Sanchez, L.; Gomez, D.; Elsaleh, T.; Steinke, R.; Cirillo, F. A Proof-of-Concept for Semantically Interoperable Federation of IoT Experimentation Facilities. *Sensors* **2016**, *16*, 1006, doi:10.3390/s16071006.
1160 73. Lanza, J.; Sotres, P.; Sánchez, L.; Galache, J. A.; Santana, J. R.; Gutiérrez, V.; Muñoz, L. Managing Large Amounts of Data Generated by a Smart City Internet of Things Deployment. *Int. J. Semant. Web Inf. Syst.* **2016**, *12*, 22–42.

1161
1162
1163 74. Nati, M.; Gluhak, A.; Abangar, H.; Headley, W. Smartcampus: A user-centric testbed for internet of things experimentation. In *Wireless Personal Multimedia Communications (WPMC), 2013 16th International Symposium on*; 2013; pp. 1–6.

1164
1165
1166 75. Issarny, V.; Mallet, V.; Nguyen, K.; Raverdy, P.-G.; Rebhi, F.; Ventura, R. Dos and Don'ts in Mobile Phone Sensing Middleware. In *Proceedings of the 17th International Middleware Conference on - Middleware '16*; ACM Press: New York, New York, USA, 2016; pp. 1–13.

1167
1168
1169 76. Pechlivanidou, K.; Katsalis, K.; Igoumenos, I.; Katsaros, D.; Korakis, T.; Tassiulas, L. NITOS testbed: A cloud based wireless experimentation facility. In *2014 26th International Teletraffic Congress (ITC)*; IEEE, 2014; pp. 1–6.

1170
1171
1172 77. Seydoux, N.; Drira, K.; Hernandez, N.; Monteil, T. IoT-O, a Core-Domain IoT Ontology to Represent Connected Devices Networks. In: Springer, Cham, 2016; pp. 561–576.

1173
1174 78. FIESTA-IoT Testbeds Available online: http://fiesta-iot.eu/index.php/fiesta-testbeds/ (accessed on May 25, 2018).

1175
1176 79. Moldovan, G.; Tragos, E. Z.; Fragkiadakis, A.; Pohls, H. C.; Calvo, D. An IoT Middleware for Enhanced Security and Privacy: The RERUM Approach. In *2016 8th IFIP International Conference on New Technologies, Mobility and Security (NTMS)*; IEEE, 2016; pp. 1–5.

1177
1178
1179 80. Barnaghi, P.; Wang, W.; Henson, C.; Taylor, K. Semantics for the Internet of Things: early progress and back to the future. *Int. J. Semant. Web Inf. Syst.* **2012**, *8*, 1–21.

1180
1181 81. Serrano, M.; Gyrard, A. A Review of Tools for IoT Semantics and Data Streaming Analytics. *Build. Blocks IoT Anal.* **2016**, *139*.

1182
1183 82. Euzenat, J.; Polleres, A.; Scharffe, F. Processing Ontology Alignments with SPARQL. In *2008 International Conference on Complex, Intelligent and Software Intensive Systems*; IEEE, 2008; pp. 913–917.

1184
1185 83. FIESTA-IoT Platform Portal Available online: https://platform.fiesta-iot.eu (accessed on May 25, 2018).

1186

1187
<table><caption>Table 3. FIESTA-IoT testbeds detailed offering</caption><thead><tr><th>Testbed</th><th>Phenomenon</th><th>FIESTA-IoT Quantity Kind</th><th>Avg. number of active sensors</th><th>Avg. number of observation per hour (aprox.)</th></tr></thead><tbody><tr><td rowspan="17">SmartSantander</td><td>Parking Availability</td><td>m3-lite#PresenceStateParking</td><td>150</td><td>n/a</td></tr><tr><td>Air Temperature</td><td>m3-lite#AirTemperature</td><td>144</td><td>12</td></tr><tr><td>Air Dust</td><td>m3-lite#ChemicalAgentAtmosphericConcentrationAirParticles</td><td>74</td><td>50</td></tr><tr><td>CO</td><td>m3-lite#ChemicalAgentAtmosphericConcentrationCO</td><td>74</td><td>50</td></tr><tr><td>NO<sub>2</sub></td><td>m3-lite#ChemicalAgentAtmosphericConcentrationNO2</td><td>74</td><td>50</td></tr><tr><td>O<sub>3</sub></td><td>m3-lite#ChemicalAgentAtmosphericConcentrationO3</td><td>74</td><td>50</td></tr><tr><td>Relative Humidity</td><td>m3-lite#RelativeHumidity</td><td>17</td><td>12</td></tr><tr><td>Noise</td><td>m3-lite#SoundPressureLevelAmbient</td><td>11</td><td>12</td></tr><tr><td>2.4 GHz Electromagnetic Field</td><td>m3-lite#ElectricField2400MHz</td><td>10</td><td>12</td></tr><tr><td>2.1 GHz Electromagnetic Field</td><td>m3-lite#ElectricField2100MHz</td><td>10</td><td>12</td></tr><tr><td>1.8 GHz Electromagnetic Field</td><td>m3-lite#ElectricField1800MHz</td><td>10</td><td>12</td></tr><tr><td>900 MHz Electromagnetic Field</td><td>m3-lite#ElectricField900MHz</td><td>10</td><td>12</td></tr><tr><td>Soil Humidity</td><td>m3-lite#SoilMoistureTension</td><td>8</td><td>12</td></tr><tr><td>Soil Temperature</td><td>m3-lite#SoilTemperature</td><td>8</td><td>12</td></tr><tr><td>People Count</td><td>m3-lite#CountPeople</td><td>7</td><td>6</td></tr><tr><td>Waste Bin Fill Level</td><td>m3-lite#FillLevelWasteContainer</td><td>4</td><td>6</td></tr><tr><td>Atmospheric Pressure</td><td>m3-lite#AtmosphericPressure</td><td>1</td><td>12</td></tr><tr><td>Solar Radiation</td><td>m3-lite#SolarRadiation</td><td>1</td><td>12</td></tr><tr><td>Wind Speed</td><td>m3-lite#WindSpeed</td><td>1</td><td>12</td></tr><tr><td>Wind Direction</td><td>m3-lite#WindDirection</td><td>1</td><td>12</td></tr><tr><td rowspan="2">SmartICS</td><td>Building Temperature</td><td>m3-lite#Temperature and m3-lite#RoomTemperature</td><td>104</td><td>6</td></tr><tr><td>Relative Humidity</td><td>m3-lite#Humidity</td><td>104</td><td>6</td></tr></tbody></table>
<table><tbody><tr><td></td><td>Noise</td><td>m3-lite#Sound</td><td>103</td><td>6</td></tr><tr><td></td><td>Illuminance</td><td>m3-lite#Illuminance</td><td>103</td><td>6</td></tr><tr><td></td><td>People Presence</td><td>m3-lite#Distance</td><td>98</td><td>6</td></tr><tr><td></td><td>Active Power Consumption</td><td>m3-lite#Power</td><td>29</td><td>6</td></tr><tr><td rowspan="4">SoundCity</td><td>Noise</td><td>m3-lite#Sound</td><td>4</td><td>n/a</td></tr><tr><td>Direction Heading</td><td>m3-lite#DirectionHeading</td><td>4</td><td>n/a</td></tr><tr><td>Presence</td><td>m3-lite#Proximity</td><td>4</td><td>n/a</td></tr><tr><td>Average Speed</td><td>m3-lite#SpeedAverage</td><td>4</td><td>n/a</td></tr><tr><td rowspan="6">CABIN</td><td>People Presence</td><td>m3-lite#PresenceStatePeople</td><td>49</td><td>n/a</td></tr><tr><td>Building Temperature</td><td>m3-lite#BuildingTemperature</td><td>41</td><td>6</td></tr><tr><td>Relative Humidity</td><td>m3-lite#RelativeHumidity</td><td>41</td><td>6</td></tr><tr><td>Illuminance</td><td>m3-lite#Illuminance</td><td>39</td><td>6</td></tr><tr><td>Parking Availability</td><td>m3-lite#PresenceStateParking</td><td>19</td><td>n/a</td></tr><tr><td>CO2</td><td>m3-lite#CO2</td><td>10</td><td>6</td></tr><tr><td rowspan="6">NITOS</td><td>Active Power Consumption</td><td>m3-lite#Power</td><td>9</td><td>6</td></tr><tr><td>People Presence</td><td>m3-lite#PresenceStatePeople</td><td>4</td><td>3</td></tr><tr><td>Building Temperature</td><td>m3-lite#AirTemperature</td><td>3</td><td>3</td></tr><tr><td>Relative Humidity</td><td>m3-lite#Humidity</td><td>3</td><td>3</td></tr><tr><td>Illuminance</td><td>m3-lite#WeatherLuminosity</td><td>3</td><td>3</td></tr><tr><td>Noise</td><td>m3-lite#SoundPressureLevel</td><td>2</td><td>3</td></tr><tr><td rowspan="5">MARINE</td><td>Door Status</td><td>m3-lite#DoorStatus</td><td>2</td><td>3</td></tr><tr><td>Radiation</td><td>m3-lite#IonisingRadiation</td><td>1</td><td>3</td></tr><tr><td>Sea Water PH</td><td>m3-lite#PH</td><td>3</td><td>4</td></tr><tr><td>Sea Water Temperature</td><td>m3-lite#WaterTemperature</td><td>3</td><td>4</td></tr><tr><td>Sea Water Conductivity</td><td>m3-lite#Conductivity</td><td>2</td><td>4</td></tr><tr><td></td><td>Sea Water Oxidation Reduction</td><td>m3-lite#Voltage</td><td>2</td><td>4</td></tr><tr><td></td><td>Atmospheric Pressure</td><td>m3-lite#AtmosphericPressure</td><td>2</td><td>6</td></tr><tr><td></td><td>Air Temperature</td><td>m3-lite#AirTemperature</td><td>2</td><td>6</td></tr></tbody></table>
<table><tbody><tr><td></td><td>Relative Humidity</td><td>m3-lite#Humidity</td><td>2</td><td>6</td></tr><tr><td></td><td>Water NO<sub>3</sub> Ion</td><td>m3-lite#ChemicalAgentWaterConcentrationNO3Ion</td><td>1</td><td>4</td></tr><tr><td></td><td>IEEE 802.15.4 Signal Level</td><td>m3-lite#Power</td><td>1</td><td>6</td></tr><tr><td></td><td>IEEE 802.11 Signal Level</td><td>m3-lite#Power</td><td>1</td><td>6</td></tr><tr><td></td><td>LoRa Device RSSI</td><td>m3-lite#Power</td><td>1</td><td>6</td></tr><tr><td rowspan="11">RealDC</td><td>Electric Voltage</td><td>m3-lite#Voltage</td><td>486</td><td>4</td></tr><tr><td>Electric Current</td><td>m3-lite#ElectricCurrent</td><td>243</td><td>4</td></tr><tr><td>Active Power Consumption</td><td>m3-lite#ActivePower</td><td>81</td><td>4</td></tr><tr><td>Reactive Power</td><td>m3-lite#ReactivePower</td><td>81</td><td>4</td></tr><tr><td>Electric Frequency</td><td>m3-lite#Frequency</td><td>81</td><td>4</td></tr><tr><td>Air Temperature</td><td>m3-lite#AirTemperature</td><td>33</td><td>3</td></tr><tr><td>Cooling Water Temperature</td><td>m3-lite#WaterTemperature</td><td>32</td><td>3</td></tr><tr><td>Atmospheric Pressure</td><td>m3-lite#AtmosphericPressure</td><td>1</td><td>4</td></tr><tr><td>Dew Point</td><td>m3-lite#DewPointTemperature</td><td>1</td><td>4</td></tr><tr><td>Relative Humidity</td><td>m3-lite#RelativeHumidity</td><td>1</td><td>4</td></tr><tr><td>Rainfall</td><td>m3-lite#Rainfall</td><td>1</td><td>4</td></tr><tr><td>Wind Chill</td><td>m3-lite#WindChill</td><td>1</td><td>4</td></tr><tr><td>Wind Speed</td><td>m3-lite#WindSpeed</td><td>1</td><td>4</td></tr><tr><td>Wind Direction</td><td>m3-lite#WindDirection</td><td>1</td><td>4</td></tr><tr><td rowspan="8">Tera4Agri</td><td>Soil Humidity</td><td>m3-lite#SoilHumidity</td><td>9</td><td>2</td></tr><tr><td>Soil Temperature</td><td>m3-lite#SoilTemperature</td><td>1</td><td>2</td></tr><tr><td>Air Temperature</td><td>m3-lite#AirTemperature</td><td>1</td><td>2</td></tr><tr><td>Dew Point</td><td>m3-lite#DewPoint</td><td>1</td><td>2</td></tr><tr><td>Leaf Wetness</td><td>m3-lite#LeafWetness</td><td>1</td><td>2</td></tr><tr><td>Rainfall</td><td>m3-lite#Precipitation</td><td>1</td><td>2</td></tr><tr><td>Relative Humidity</td><td>m3-lite#RelativeHumidity</td><td>1</td><td>2</td></tr><tr><td>Solar Radiation</td><td>m3-lite#SolarRadiation</td><td>1</td><td>2</td></tr><tr><td>Wind Speed</td><td>m3-lite#WindSpeed</td><td>1</td><td>2</td></tr></tbody></table>
<table><tbody><tr><td></td><td>Wind Direction</td><td>m3-lite#WindDirection</td><td>1</td><td>2</td></tr><tr><td></td><td>Board Temperature</td><td>m3-lite#BoardTemperature</td><td>20</td><td>6</td></tr><tr><td></td><td>Board Voltage</td><td>m3-lite#Voltage</td><td>20</td><td>6</td></tr><tr><td></td><td>Device Uptime</td><td>m3-lite#DeviceUptime</td><td>20</td><td>6</td></tr><tr><td></td><td>IEEE 802.15.4 Signal Level</td><td>m3-lite#Power</td><td>20</td><td>6</td></tr><tr><td></td><td>Air Temperature</td><td>m3-lite#AirTemperature</td><td>17</td><td>6</td></tr><tr><td></td><td>Relative Humidity</td><td>m3-lite#RelativeHumidity</td><td>17</td><td>6</td></tr><tr><td rowspan="8">FINE</td><td>Air Dust</td><td>m3-lite#ChemicalAgentAtmosphericConcentrationAirParticles</td><td>12</td><td>6</td></tr><tr><td>Illuminance</td><td>m3-lite#Illuminance</td><td>11</td><td>6</td></tr><tr><td>Noise</td><td>m3-lite#SoundPressureLevelAmbient</td><td>10</td><td>6</td></tr><tr><td>Electric Current</td><td>m3-lite#ElectricCurrent</td><td>7</td><td>6</td></tr><tr><td>Electric Voltage</td><td>m3-lite#Voltage</td><td>2</td><td>6</td></tr><tr><td>NO</td><td>m3-lite#ChemicalAgentAtmosphericConcentrationNO</td><td>2</td><td>6</td></tr><tr><td>NO<sub>2</sub></td><td>m3-lite#ChemicalAgentAtmosphericConcentrationNO2</td><td>2</td><td>6</td></tr><tr><td>CO<sub>2</sub></td><td>m3-lite#CO2</td><td>2</td><td>6</td></tr><tr><td></td><td>O<sub>3</sub></td><td>m3-lite#ChemicalAgentAtmosphericConcentrationO3</td><td>2</td><td>6</td></tr><tr><td></td><td>SO<sub>2</sub></td><td>m3-lite#ChemicalAgentAtmosphericConcentrationSO2</td><td>2</td><td>6</td></tr><tr><td></td><td>VOC</td><td>m3-lite#ChemicalAgentAtmosphericConcentrationVOC</td><td>2</td><td>6</td></tr><tr><td rowspan="2">Grasse Smart Territory</td><td>Lora Device SNR</td><td>m3-lite#SNR</td><td>7</td><td>10</td></tr><tr><td>Lora Device RSSI</td><td>m3-lite#RSSI</td><td>7</td><td>10</td></tr><tr><td rowspan="4">ADREAM</td><td>Electric Voltage</td><td>m3-lite#Voltage</td><td>145</td><td>8</td></tr><tr><td>Building Temperature</td><td>m3-lite#Temperature</td><td>54</td><td>3</td></tr><tr><td>Air Temperature</td><td>m3-lite#AirTemperature</td><td>36</td><td>2</td></tr><tr><td>Electric Power</td><td>m3-lite#Energy</td><td>10</td><td>10</td></tr></tbody></table>