Vol.:(0123456789)1 3

Journal of Ambient Intelligence and Humanized Computing https://doi.org/10.1007/s12652-018-0732-4

ORIGINAL RESEARCH

CoAP‑based collaborative sensor networks in the Semantic Web of Things

Michele Ruta1 · Floriano Scioscia1 · Agnese Pinto1 · Filippo Gramegna1 · Saverio Ieva1 · Giuseppe Loseto1 · Eugenio Di Sciascio1

Received: 5 September 2017 / Accepted: 12 December 2017 © Springer-Verlag GmbH Germany, part of Springer Nature 2018

AbstractThe Semantic Web of Things (SWoT) integrates knowledge representation and reasoning techniques originally devised for the Semantic Web into Internet of Things architectures, in order to provide more advanced service/resource management and discovery. This paper proposes a novel SWoT framework, enabling collaborative discovery of sensors and actuators in pervasive contexts. It is based on a backward-compatible extension of the Constrained Application Protocol (CoAP), sup-porting advanced semantic matchmaking via non-standard inference services. The proposed mobile agent is able to discover devices and share smartphone embedded sensors in a peer-to-peer fashion. Efficient data stream mining is also integrated to analyze raw data gathered from the environment and detect high-level events, annotating them with machine-understandable metadata. Finally, a case study about cooperative environmental risk monitoring and prevention in Hybrid Sensor and Vehicular Networks is presented. Experimental performance results on a real testbed assess the approach.

Keywords Semantic Web of Things · CoAP · Collaborative sensing · Resource discovery · Matchmaking · Data mining

1 Introduction

The emerging Semantic Web of Things (SWoT) vision, introduced by Ruta et  al. (2012), couples the Semantic Web and the Internet of Things (IoT). According to Linked Data (LD) best practices summarized by Heath and Bizer (2011), each available information resource in the Seman-tic Web is denoted by a dereferenceable URI (i.e., a Uni-form Resource Identifier pointing to an accessible HTTP resource). The SWoT paradigm aims to enable new classes of smart applications and services by augmenting real-world objects, locations and events with semantically rich and machine-understandable information. Knowledge frag-ments are conveyed through unobtrusive, inexpensive and often disposable micro-devices such as wireless sensors and Radio Frequency IDentification (RFID) tags. SWoT environ-ments are intrinsically dynamic: the availability of hosts, data sources and services can vary frequently and unpredict-ably, due to device and people mobility, battery limitations

and wireless networks unreliability. Resource discovery is therefore both more necessary and more challenging than in conventional Web scenarios.

The Constrained Application Protocol (CoAP) Bor-mann et al. (2012) is an application-layer protocol expressly defined for networks of objects with limited computational, memory and bandwidth resources. Unfortunately, it cur-rently allows only a basic data-oriented representation of resources. In addition, elementary retrieval procedures are allowed relying on string matching between requests and resource attributes. Just binary “in/out” outcomes are pos-sible. Exact request/resource matches are uncommon in real-world scenarios with heterogeneous devices, sensors and actuators from several independent providers. The SWoT needs more effective resource discovery, supporting also approximate matches and possibly providing a relevance metric of available resources. This could strongly promote interoperable collaboration in large IoT environments and scenarios as multi-party Wireless Sensor Network (WSN) deployments and federations. Integrating smart objects and WSNs with Semantic Web technologies and infrastructures is a relevant research trend. Without a general-purpose interoperability layer, IoT technologies and solutions tend to become detached pillars, impairing both information and

* Michele Ruta michele.ruta@poliba.it

1 Polytechnic University of Bari, via E. Orabona 4, 70125 Bari, Italy

M. Ruta et al.

1 3

service sharing. Furthermore, as observed by Guinard and Trifa (2009), a large human effort is required on a case-by-case basis for the design, deployment and integration of current IoT and Web of Things (WoT) applications, much like for Web mashups.

This paper borrows technologies from the Semantic Web to define a comprehensive SWoT framework for fully decen-tralized cooperative sensor networks. The approach man-ages high-level annotations of data streams, devices, events of interest and services, with a well-defined meaning w.r.t. a shared domain conceptualization (i.e., ontology). From a technological standpoint, the proposal integrates several contributions:

– extensions to CoAP and CoRE Link Format resource dis-covery protocol—specified in RFC (Request For Com-ments) by Shelby (2012)—to support semantic resource discovery while preserving backward compatibility;

– a data mining methodology for resource-constrained nodes to enable event/condition detection and annota-tion in Description Logics (DLs), exploiting the SSN-XG ontology for Semantic Sensor Networks by Compton et al. (2012) as reference vocabulary;

– semantic-based matchmaking described in Scioscia et al. (2014) for resource retrieval and ranking, grounded on non-standard reasoning services supporting approximate matches in addition to exact ones;

– a mobile user agent capable to discover devices and data sources via semantic matchmaking, as well as to share embedded sensors as CoAP resources on the network.

A case study on collaborative environmental risk monitoring and management in Hybrid Sensor and Vehicular Networks (HSVNs) is presented to validate and explain the approach. A testbed was developed implementing the framework with real devices and experiments were executed.

The remainder of the paper is organized as follows. Section 2 illustrates motivation for the work via a refer-ence scenario. Section 3 recalls technical notions useful to understand the proposed approach, as well as relevant related research. Section 4 outlines the overall framework architecture and provides details about functions and com-ponents. The case study is described in Sect. 5. Section 6 provides qualitative and quantitative evaluations of the pro-posal. Finally, Sect. 7 closes the paper.

2 Motivating scenario: collaborative sensing

Let us consider the following scenario. Regional authorities request the harmonization of existing city-level road sensor networks. The goal is a large-scale monitoring of traffic sta-tus and patterns, road conditions and safety risks for drivers

and pedestrians. A Hybrid Sensor and Vehicular Network (HSVN) is required, with sensors deployed along roads to monitor and gather information about the environmental conditions of a given area. Allowed sensors are different in terms of type (possibly including wind, humidity, tempera-ture, rain, vibration, cameras, etc.), manufacturer, measure-ment properties and performance. They are deployed with varying density. By analyzing sensor data, relevant high-level conditions and risk factors can be identified. By means of Vehicle-to-Infrastructure (V2I) wireless communication technologies, each vehicle is able to receive safety warn-ings and traffic information from Road-Side Units (RSUs). Simultaneously, vehicles equipped with on-board sensing devices should be able to share their information with RSUs, in order to make data gathering even more capillary. Col-lected data are analyzed to annotate the situation in real time for emergency services.

Such kind of environmental monitoring and ambient intelligence scenarios is relevant and challenging for WSN and IoT technologies. It requires coping with hard issues, such as:

– large-scale data and sensor management;– volatility of resources, users and devices;– heterogeneity of hardware/software platforms;– dependence on context;– strict computational resource constraints.

The need for very large scale data management is more and more relevant. Big Data [following the terminology in Gan-domi and Haider (2015)] are even more materialized due to the large availability of IoT technologies including wireless sensors, RFID tags, personal mobile and wearable devices. Each device individually generates a non-negligible data amount. While data sources are easily handled individually, their increasingly large number makes data management a very challenging subject. Main typical problems in this field have been identified as in what follows:

– Volume The amount of generated data is too large for online storage in traditional database infrastructures.

– Velocity Data is produced and must be processed at very fast rates, as its value decreases significantly with time.

– Variety Data sources are very heterogeneous, includ-ing structured (e.g., detection events generated by RFID readers), semi-structured (e.g., user inputs in survey-ing, healthcare or social networking applications) and unstructured (e.g., audio-video streams) information. They can be either periodic or sporadic.

– Veracity Individual data samples are often unreliable, due to inherent measurement uncertainty, device limitations and issues due to failures or unexpected context condi-tions. Due to velocity requirement, validation of each

CoAP-based collaborative sensor networks in the Semantic Web of Things

1 3

low-level data point is unfeasible; data fusion techniques could be adopted instead to reconcile inconsistencies and generate relatively few high-level descriptions to be used to take decisions and actions.

The above issues are exacerbated in ubiquitous and pervasive contexts, featured by mobile ad-hoc networks (MANETs) of resource-constrained things. In such scenarios, centralized approaches and infrastructures become hardly manageable, while distributed collaborative paradigms can be more effec-tive. Recent trends propose sensing as a service models, as described by Sheng et al. (2013), where mobile agents offer, request, discover and exploit data sensing and analysis services, enabled by on-board sensors or devices in their immediate proximity, connected through low-power wireless links. This model is peer-to-peer (any node can request data or search for specific kinds of sensors), opportunistic (i.e., aimed to exploit dynamically all the available resources in a given area in a certain time frame) and participatory (i.e., users are invited to contribute their data, sensing and com-puting resources to the network). Solutions must be general enough to support various types of applications, platforms and devices. Furthermore, effective incentive mechanisms must be devised in order to promote collaboration: as stud-ied by Koutsopoulos (2013), some approaches are based on rewards adopting various pricing schemes, while other ones may offer a direct benefit from participation which could not be obtained otherwise (e.g., an agent can enable some application features only by sharing its own sensor data).

In all the above approaches, state-of-the-art discovery technologies are not fully adequate. Although efficient IoT application-level protocols have been devised, such as CoAP, they do not support rich and structured feature-based discov-ery of data sources and streams, as explained in Sect. 3.2. On the other hand, technologies for articulated resource descrip-tion and discovery, such as the ones provided by the Seman-tic Web initiative, were designed for the conventional Web, where computational and bandwidth resources of hosts are largely available. The integration of advanced collaborative discovery protocols with IoT infrastructures requires non-trivial adaptation and optimization.

3 Background

This section briefly recalls basics of DLs and CoAP to make the paper self-contained, then it surveys relevant related work.

3.1 Description Logics

Description Logics, discussed in Baader et al. (2002), are a family of logic languages for Knowledge Representation in

a decidable fragment of First Order Logic. Basic DL syntax elements are:

– concept (a.k.a. class) names, standing for sets of objects, e.g., vehicle, road, acceleration;

– role (a.k.a. object property) names, linking pairs of objects in different concepts, like hasTire, hasTraffic;

– individuals (a.k.a. instances), special named elements belonging to concepts, e.g., Sedan_Car_207, Highway_A14.

These elements can be combined using constructors to form concept and role expressions. Each DL has a different set of constructors. A constructor used in every DL is the conjunction of concepts, usually denoted as ⊓ ; some DLs include also disjunction ⊔ and complement ¬ . Roles can be combined with concepts using existential role quantification (e.g., car ⊓ ∃hasEngine.DieselEngine , which indicates the set of cars with a Diesel engine) and universal role quan-tification (e.g., vehicle ⊓ ∀hasPneumatic.SnowTire , which describes vehicles equipped only with snow tires). Other constructs may involve counting, as number restrictions: car ⊓ ≤ 2 hasSeat denotes cars having at most 2 seats, and vehicle ⊓ ≥ 7 hasSeat describes vehicles with at least 7 seats. Concept expressions can be used in inclusion and defi-nition axioms, which model knowledge elicited for a given domain by restricting possible interpretations. A set of such axioms is called Terminological Box (TBox), a.k.a. ontology. Analogously, a set of individual axioms (a.k.a. facts) forms an Assertion Box (ABox), which together with its reference TBox builds a Knowledge Base, KB.

Adding new constructors makes DL languages more expressive. Nevertheless, this usually leads to a growth in computational complexity of inference procedures. Hence a tradeoff is needed. This paper refers specifically to the Attributive Language with unqualified Number restrictions ( ) DL. It provides adequate expressiveness, while granting polynomial complexity to both standard and non-standard inference services. Logical notation of con-structors is reported in Table 1, along with the corresponding Manchester syntax serialization of the W3C OWL Working Group (2012b) for the Web Ontology Language (OWL 2) specified by the same W3C OWL Working Group (2012a).

3.2 Constrained application protocol

Following the REpresentational State Transfer (REST) archi-tectural style, CoAP adopts a loosely coupled client/server model, based on stateless operations on resources represen-tation, as explained by Bormann et al. (2012). Each resource is a server-controlled abstraction, unambiguously identi-fied by a URI (Uniform Resource Identifier). Clients access resources via synchronous request/response interactions,

M. Ruta et al.

1 3

using HTTP-derived methods basically mapping the Read, Create, Update and Delete operations of data management. According to the official RFC 7252 Shelby et al. (2014), a CoAP message is composed of: (1) a 32-bit header, con-taining the request method code (or response status); (2) an optional token value, used to associate replies to requests, (3) zero or more option fields (carrying information as resources URI and payload media type), (4) the payload data. Possible request methods, option types and response statuses are distin-guished by means of binary codes, listed in the CoAP speci-fication. Some CoAP options are derived from HTTP header fields (e.g., content type, headers for conditional requests and proxy support), while some other ones have no counterpart in HTTP. In particular, the target resource URI for a CoAP request (which must refer to the coap or coaps scheme) is split in a Uri-Host, a Uri-Port (default UDP port is 5683) and a Uri-Path option, with one Uri-Query option for each field in the query URI portion. If an option value is longer than 255 B, it is split in consecutive option fields of the same type. Moreover, the Observe option—defined in RFC 7641 Hartke (2015)—allows a client to regis-ter in a server as observer for a resource, so that the server will notify the client of further resource changes automatically, without the need of polling. HTTP lacks this capability; it was introduced in CoAP specifically for scenarios like WSNs, where data have to be monitored over a time span.

In CoAP-based scenarios, each sensor is seen as a server, exposing both readings and internal information as resources toward clients, which act on behalf of end-user applications. Different data series will be identified by distinct URIs. Fur-ther URIs refer to sensor device status and operating param-eters; clients will be able to read or modify them as appropri-ate. For example, a temperature sensor S can expose the latest

temperature reading at the URI coap://[S-address]/temperature; in order to access it, a client should issue a GET request with Uri-Host=S-address and Uri-Path=/temperature options. In case of success, it will receive status code 2.05 and the response message payload will contain the value, e.g., ��.� ◦

� if it is returned as plain text. Furthermore, since CoAP supports proxies, cluster-head or sink nodes can reply on behalf of a set of (possibly more constrained) sensor nodes deployed in an area, exploiting caching and decreasing the load at the edge of the network. This feature allows also the adoption of data fusion and min-ing techniques over data extracted from sensors, useful to nodes managing high-level applications.

Resource discovery is needed to know what resources a given CoAP server is making available. The CoAP discovery protocol is defined in the CoRE Link Format specification edited by Shelby (2012). It allows any host to expose its resources, as well as to act as a directory service for other hosts willing to enroll their resources. A client accesses the reserved URI path /.well-known/core on the server with POST method to register a resource, or with GET to discover available ones. GET requests can include URI-query fields to retrieve only resources with specific attrib-utes. Standardized query attributes comprise:

– href (hypertext reference), a regular expression to filter resources based on their path (e.g., “/temperature” or “/temperature/*”);

– type (media type), MIME (Multipurpose Internet Mail Extensions) type/subtype for the resource;

– rt (resource type), an opaque string representing an application-specific meaning of a resource (e.g., “out-door-temperature”);

– if (interface description), an opaque string used to pro-vide a name or a URI which indicates what operations can be performed on the resource and their meaning; it typically references a machine-readable document.

Further non-reserved attributes can be freely used. Response payload consists of a comma-separated list of resource paths, each having optionally a list of semicolon-separated attributes.

3.3 Related work

Integrating smart objects and wireless sensor networks with Semantic Web technologies and infrastructures is a currently relevant research trend. Various solutions have been proposed, exploiting reference ontologies to annotate data, devices and services and sharing sensor data along the Linked Data (LD) guidelines in Heath and Bizer (2011) through RESTful web services—e.g., in Patni et al. (2010)—or interfaces compliant with Open Geospatial Consortium’s

Table 1 constructors

Name DL syntax Manchester syntax

Top ⊤ owl:Thing

Bottom ⊥ owl:Nothing

Concept C C

Role R R

Conjunction C ⊓ D C and DAtomic negation ¬A not AUnqualified existential

restriction∃R R some owl:Thing

Universal restriction ∀R.C R only CUnqualified greater-than

number restriction≥ n R R min n

Unqualified less-than number restriction

≤ n R R max n

Definition axiom A ≡ C Class: A EquivalentTo: CInclusion axiom A ⊑ C Class: A SubClassOf: C

CoAP-based collaborative sensor networks in the Semantic Web of Things

1 3

Sensor Web Enablement (SWE) standards as in Llaves et al. (2016).

The SPITFIRE service infrastructure for semantic applica-tions—described in Pfisterer et al. (2011)—leveraged Inter-net-connected sensors and lightweight protocols like CoAP. Sensors were described with triples in Resource Description Framework (RDF)—Semantic Web standard edited by Cyga-niak et al. (2014)—and service discovery was based on meta-data such as device features or location. An ontology-based architecture was also proposed by Desai et al. (2015), exploit-ing semantic annotations of sensor data to support interoper-ability among different IoT technologies and to obtain higher-level knowledge from low-level sensor data. Barnaghi et al. (2010) proposed Sense2Web, a LD-based platform to publish sensor data and link them to existing resources on the Seman-tic Web. Different ontologies were used to describe physical resources, query data and relations to obtain implicit infor-mation and integrate sensor information coming from vari-ous sources. Likewise, the Linked Stream Middleware (LSM) platform proposed by Le-Phuoc et al. (2012) integrated sensor data with other LD sources, by enriching both sensor sources and sensor data streams with semantic descriptions. There, a processing engine adopted SPARQL specification of the W3C SPARQL Working Group (2013) to perform queries across both dataset types, mashup the data and compute results. The use of semantics for automatic sensor composition was investi-gated in Tran et al. (2010). The system proposed there was able to combine sensors and services to satisfy user goals by means of semantic descriptions of functional and non-functional sensor properties. A more refined approach is in Perera et al. (2014): resource discovery combined quantitative constraints and semantic reasoning to satisfy user requests expressed in terms of device attributes. That system also exploited a form of user-driven exploratory search to select the most appropriate sensors for the particular problem. Unfortunately, all the above works allowed only basic queries in SPARQL fragments on RDF annotations. More advanced resource discovery features were not supported. Data and sensor management in mobile and pervasive contexts require techniques such as ontology-based complex event processing adopted in Taylor and Lei-dinger (2011) and semantic matchmaking exploited in Ruta et al. (2011). The latter in particular supported approximated matches and resource ranking with explanation of outcomes, by means of logic-based inference services. Conversely, novel proposals by Djamaa et al. (2017) and of Görgü et al. (2017) for distributed sensor discovery in the IoT appear as flexible and robust, but they lack semantic discovery capabilities; inte-grating them would make the approaches even more versatile.

Peculiarities of the approach proposed here w.r.t. the state of the art are assessed in the comparison reported in Table 2. Only the solution presented in this paper combines fitness for resource-constrained environments (by using CoAP and a distributed search strategy), expressiveness of sensor

modeling (by exploiting OWL 2) and support of both exact and approximated matches, with formal resource ranking and composition.

Finally, the verbosity of XML-based ontological lan-guages is a non-negligible related issue in large-scale per-vasive sensing and monitoring applications. Compression ratio, processing/memory requirements and efficiency of queries on compressed data become critical parameters. The Efficient XML Interchange (EXI) Profile—a W3C Recom-mendation edited by Schneider et al. (2014)—limits usage of both storage and dynamic memory. Specific experimental algorithms for the SWoT, e.g., DIGcompressor and COX proposed by Scioscia and Ruta (2009), also aim at either maximum compression ratio or high query efficiency, while keeping the computational costs low.

4 Semantic sensor network framework

The following subsections report on details about system architecture, semantic-based discovery approach and context mining.

4.1 Architecture

An explanatory architecture of the proposed framework is depicted in Fig. 1. It extends an earlier version of the CoAP-based solution in Ruta et al. (2013).

Each sensor is described through a semantic annotation modeling its capabilities and characteristics, in addition to data-oriented attributes. Sink nodes act as cluster heads for sensors deployed locally, communicating via CoAP. They embed CoAP servers to:

– register sensors as CoAP resources along with their semantic descriptions;

– support logic-based resource discovery on annotated metadata, leveraging the lightweight embedded match-maker in Scioscia et al. (2014).

Furthermore, sinks detect events through data gathering and mining. Recognized events are annotated and stored by updating resource records in the server. A record also includes context-dependent extra-logical attributes, such as timestamp and geographic coordinates. Finally, a gateway is connected to multiple sinks and interfaces with exter-nal devices and systems. Clients searching for events or devices in a given area, send resource discovery requests via CoAP to the gateway, which replies on behalf of con-nected sinks. Gateways can also communicate with each other through CoAP, allowing for complex meshes of fed-erated micronetworks.

M. Ruta et al.

1 3

The developed software implements the framework pro-posed here to support a collaborative sensing process on different platforms. Basically, the toolkit consists of the fol-lowing prototypical modules.

Semantic CoAP core. It is a core library for Java Stand-ard Edition (Java SE) enabling the semantic-based enhance-ments of the CoAP protocol described in Sect. 4.2. As shown

in Fig. 2, communication in SSNs was implemented extend-ing the Californium CoAP library1 proposed by Kovatsch et al. (2012). CoAP core also includes the FemtoZip com-pression library2, based on the shared dictionary approach in

Table 2 Comparison of the proposed approach with related work

a Ranking based on semantic distanceb Top-K on weighted attributes

Approach Application protocol

Represen-tation language

Contextual query attributes

Distrib-uted search

Match types Resource ranking

Resource com-position

Contribution

Barnaghi et al. (2010)

HTPP RDF In SPARQL query

No Exact only No Mashup com-poser

RDF-based data annota-tions avail-able through SPARQL endpoints

Tran et al. (2010)

Agnostic OWL 1.1 In OWL anno-tation

No Exact and approximated

Yesa Yes OWL ontology for sensor composition

Taylor and Leidinger (2011)

Agnostic OWL 2 In CEP lan-guage

No Exact only No Yes Ontology–driven CEP for events recognition on sensor data

Pfisterer et al. (2011)

CoAP RDF In SPARQL query

No Exact only No No CoAP support for SWoT scenarios

Le-Phuoc et al. (2012)

HTPP RDF In SPARQL query

No Exact only No Mashup com-poser

Real-time data collection and publishing

Ruta et al. (2013)

CoAP OWL 2 In CoAP parameters

No Exact and approximated

Yesa Yes Resource discov-ery and rank-ing through non-standard inferences

Perera et al. (2014)

Agnostic RDF In SPARQL query

Yes Exact and approximated

Yesb No Distributed and context-aware sensor search

Desai et al. (2015)

CoAP, MQTT RDF In RDF or JSON-LD

No Exact only No No Semantic gateway for multi-protocol SSNs

Djamaa et al. (2017)

CoAP Agnostic In CoAP parameters

Yes Exact only No No Hybrid proactive and push-pull discovery

Görgü et al. (2017)

Agnostic Proprietary Proprietary message format

No Exact only No No Discovery decou-pled from sen-sor description and adaptation middleware

Proposed approach

CoAP OWL 2 In CoAP parameters

Yes Exact and approximated

Yesa Yes Distributed sen-sor composi-tion via concept covering

1 http://eclip se.org/calif orniu m.2 http://githu b.com/gtoub assi/femto zip.

CoAP-based collaborative sensor networks in the Semantic Web of Things

1 3

Doblander et al. (2016) and optimized for small documents. It results very useful to encode small OWL annotations rep-resenting requests in the semantic-based discovery process. Finally, the Mini Matchmaking Engine (Mini-ME) library3 includes non-standard inference services based on DL in Scioscia et al. (2014).

Reference implementation is available on Github4. The repository also includes two modules related to the imple-mentation of a SSN gateway and a CoAP sink on Java-based platforms.

JOSM SSN dashboard. Fig. 3 illustrates the SSN dash-board, based on the Java OpenStreetMap (OSM) open source editor5. It provides a user-friendly graphical user interface (GUI) to perform the following tasks:

– SSN browsing. A geographic area of interest can be downloaded from the OSM server. The map on the left-hand panel (A) shows available sensor and sink nodes registered on CoAP gateways. Both real and simulated nodes can be accessed and queried.

– Semantic-based sensor discovery. Semantic-based CoAP requests can be sent to discover sensors in the area. Requests are customizable through the right-hand panel (B), by specifying the inference task to perform, a semantic relevance threshold, reference location and maximum discovery range. The semantic request can be composed by selecting properties and classes defined in the reference ontology via drag-and-drop.

– SSN scenario generation. Panel (C) in Fig. 3 extends the OSM to Rescue JOSM plugin by Gobelbecker and Dornhege (2009) and allows the creation of random con-figurations for large-scale SSN simulations. In this way, it is also possible to define hybrid SSNs composed of different off-the-shelf and simulated CoAP nodes.

Scenarios can be customized according to the parameters reported in Table 3. The algorithm for scenario generation progresses along the following stages:

1. the user selects an area of interest, named Bounding Box (BBox);

2. all OSM nodes within the BBox containing the highway tag are extracted;

3. S of these nodes are randomly selected, representing the sink nodes of the SSN;

4. for each sink, M ( Dmin ≤ M ≤ Dmax ) sensors are created near the sink and positioned in randomly selected loca-tions within a circle area of radius dMaxS and centered in the sink node position;

5. exploiting the K-means algorithm the sink nodes, along with related sensors, are split in G clusters each includ-ing a number N of sinks between Smin and Smax . Each cluster of sinks will be associated to a CoAP gateway having as geographical location the cluster centroid;

6. finally, a connection will be created for each pair of gate-ways ⟨Gi,Gj⟩ ( i ≠ j ) if distance(Gi,Gj) ≤ dMaxG.

CoAP Mobile Node. An Android-based agent was devel-oped to support SSN browsing, sensor discovery and col-laborative sensing. A detailed description is provided in Sect. 4.3.

4.2 Semantic discovery in CoAP

Resource discovery in basic CoAP exploits the CoRE Link Format specification. This protocol only enables a syntactic

SS

SCoAP

SinkNode

SS

SCoAP

SinkNode

Gateway

Mobile Nodes

CoAP

JOSMDashboard

CoAP-based Sensor Network

CoAP

SensorsSensors

Fig. 1 CoAP-based sensor network architecture

<californium-core> package

<semantic-coap> package

extends

<minime-reasoner> package

<coap-mobile> package

requires

<FemtoZip> package

requires

requires

Fig. 2 Reference software modules

3 http://sisin flab.polib a.it/swott ools/minim e/.4 http://githu b.com/sisin flab-swot/seman tic-coap.5 http://josm.opens treet map.de/.

M. Ruta et al.

1 3

match of attributes, without a characterization of resource semantics. More sophisticated discovery is possible and needed, thanks to more and more powerful off-the-shelf devices and due to more demanding applications. Advanced discovery services should be adopted to improve protocol capabilities allowing to (1) rank resources w.r.t. a request

and (2) identify also partial correspondences—very frequent in practical scenarios involving heterogeneous resources—between a request and device descriptions.

In the approach proposed here, the semantic-based CoAP protocol enhancements described in Ruta et al. (2013) have been extended to support non-standard inferences and to allow automated collaborative sensor discovery and composition. The proposed variant of the protocol is still fully backward compatible: servers which do not support semantics will just reply by returning no resource records. Semantic-based requests are similar to the standard ones, they only use differently the standard URI-query CoAP option along with the novel resource attributes and context-dependent parameters reported in Table 4. In particular, lg, lt and md attributes are exploited to specify a (center, distance) constraint. It filters out resources outside the requested area (so avoiding the relatively expensive infer-ence procedures) as well as to grade matchmaking outcomes of resources inside the area.

Fig. 3 JOSM dashboard for CoAP-based SSNs

Table 3 Parameters for scenario generation

Parameters Description

S Number of sink nodesG Num. of CoAP gateways (GWs)Dmin Min num. of CoAP sensors per sinkSmin Min num. of sinks connected to a CoAP GWDmax Max num. of CoAP sensors per sinkSmax Max num. of sinks connected to a CoAP GWdMaxS Max distance in m between sink and sensorsdMaxG Max distance in m between two connected

GWs

Table 4 Semantic-based CoAP resource attributes and context-dependent parameters

Attribute Type Description

ct Integer Content type, basic MIME types extended to support OWL-based annotationro IRI Reference ontologysd String Semantic description of the discovery request, compressed to reduce data trans-

fersat Integer Annotation type, used in case of data encodingst Integer Semantic task to be performed (1 for logic-based ranking; 2 for concept covering)sr Float Reference match threshold for selected semantic tasklg Float Longitude of reference geographical location (in degrees)lt Float Latitude of reference geographical location (in degrees)md Integer Maximum distance from reference location (in meters)hop Integer Hop count specified in case of forwarded requests

CoAP-based collaborative sensor networks in the Semantic Web of Things

1 3

The framework and algorithms reported in Scioscia et al. (2014) have been exploited to enable a logic-based match-making between a request and one or more resource descrip-tions. Ranking of resource annotations w.r.t. the original request has been made possible, based on the meaning of descriptions with reference to a shared ontology. Description Logics (recalled in Sect. 3.1) are the reference formalism and particularly the DL has been adopted, having a well-known polynomial computational complexity for standard and non-standard inferences. Given a request Q and a resource R, both consistent w.r.t. a common ontol-ogy (containing axioms that model knowledge for the reference problem domain), Concept Subsumption standard inference service—discussed in Baader et al. (2002)—can be used to identify full matches, i.e., resources providing all features requested in Q. Unfortunately, such correspond-ences are infrequent in real-world scenarios. Particularly, whenever R is not a full match for Q, Concept Abduction Problem non-standard inference service allows to determine what should be hypothesized in R in order to completely satisfy Q. The solution H (for Hypothesis) represents “why” the subsumption relation ⊧ R ⊑ Q does not hold and can be interpreted as what is requested in Q and not specified in R. Inferences are implemented via structural algorithms based on Conjunctive Normal Form (CNF) normalization of concept expressions, as detailed in Ruta et al. (2011). Since a concept CNF is unique, a semantic distance can be associated to every (Q, R) pair, based on a “norm” on the respective solution H. This enables a logic-based relevance ranking of a set of available resources w.r.t. a given request.

The semantic-based discovery has been further enhanced to support a slightly refined version of the Concept Covering service, previously defined in Scioscia et al. (2014), in order to select a minimum set of resources best covering a request. Given a request Q and a set of resources S = {S1, S2, ..., Sk} , where Q and S1 , S2 , ..., Sk are satisfiable in , the Concept Covering Problem (CCoP) aims to find a pair ⟨Sc,H⟩ where Sc includes concepts in S (partially) covering Q w.r.t. and H is the (possible) part of Q not covered by concepts in Sc . Algorithm 1 is applied in the proposed discovery framework. To verify if a sensor si (from set S) can partially (or totally) cover the request, a compatibility check is performed (line 7). Afterwards Concept Abduction Problem is solved (line 8) to determine what is missing in the sensor description to completely satisfy the request. In line 9 a rank value is computed via the following utility function:

where s_match measures the CAP-induced semantic distance between a request Q and a description Hi , as presented in Ruta et al. (2011). The geographical distance of the sensor si from the reference point P (defined by the attributes lt and

rank(Q,Hi

)= 100 ∗

[1 − s_match

(Q,Hi

)∗

(1 +

distance(P, si

)

md

)],

lg), normalized by user-specified maximum distance (attrib-ute md), is combined as weighting factor. Finally, the sensor with the highest rank ( Smax ) is selected and moved from S to Sc (lines 17–18) and the part of Q covered by Smax is removed (line 19). The algorithm outcome is the set of sensors best covering the request, along with the uncovered part, if present. In some circumstances, it could be necessary to automatically and dynamically substitute no longer available sensor nodes. In that case, the status of registered nodes will be periodi-cally monitored and, if any one is down, CCoP can be used to replace disabled ones with most suitable available sensors.

ALGORITHM 1: Request covering proce-dureAlgorithm: requestCovering (〈L, T , Q, S〉)

Require:– L : a Description Logic;– T : an acyclic TBox;– Q: concept expression of request;– S = {s1, s2, . . . sn}: concept expressions of sensors;Q and si are expressed in L and satisfiable in T .

Ensure:– Sc = {s1, s2, . . . sk}: set of sensors covering therequest Q;– H: uncovered part of the request.

1: Sc := ∅2: H := Q3: repeat4: Rmax := 05: Smax := �6: for all si ∈ S do7: if (si �D) is satisfiable in T and si is a cover for

Q then8: Hi := solveCAP (〈L, T Q, si〉)9: R := rank(Q,Hi)

10: if R > Rmax then11: Rmax := R12: Smax := si13: end if14: end if15: end for16: if Smax �= � then17: Sc := Sc ∪ Smax

18: S := S − Smax

19: H := H \ {Smax}20: end if21: until Smax �= �22: return Sc, H

Concept Covering is particularly useful in semantic-based IoT scenarios, e.g., cooperative sensor networks, where sev-eral devices query one or more SSN gateways to: (1) find the set of most suitable sensors, among those managed by sinks connected to the gateway; (2) gather data from specific and different types of sensors to infer proper events.

A toy example will clarify the structure and content of request and reply messages in the semantic-enhanced variant of CoAP protocol. Semantic annotations will be voluntarily omitted here for the sake of clarity. In the fol-lowing example, a CoAP client sends to the gateway (with

M. Ruta et al.

1 3

193.204.59.75:5683 IP address) a compressed semantic-based request Q expressed in OWL w.r.t. a shared ontology. The application is interested only in sensors located within 800 m from the location at (41.079769, 16.763571) coor-dinates. The application will therefore send a GET CoAP request to:coap://193.204.59.75:5683/.well-known/

core? &ro= SSN-XG-IRI&sd=yyyyyy=&at=30004&lg=16.763571 &lt=41.079769&md=800&st=2&sr=70

The gateway carries out semantic matchmaking by solv-ing a Concept Covering Problem (CCoP), in order to identify the set of resources which collectively satisfy the request to the best extent and what elements in the request are not covered by the retrieved resource list.

Let us suppose that the returned set is composed of two sensors matching the above request. The discovery reply payload sent by the CoAP server will be:

</Hts2030HumidSens>;ct=0;ct=41;at=30004;lg=16.768277;lt=41.077286;md=480;ro= SSN-XG-IRI;

sd=aaaaaaa;title=“Humidity-Sensor-2030”,</BitLineAnemomSens>;ct=0;ct=41;at=30

004;lg=16.758347;lt=41.081983;md=500;ro=SSN-XG-IRI;

sd=bbbbbbb;title=“Anemometer-Sensor-111”,</H>;sd=ccccccc;sr=9.12In case of a partial cover, the outcome also includes:

(1) the semantic description of the uncovered part (H) of the request; (2) the percentage of request still not covered, obtained comparing H w.r.t. the original Q—see Scioscia et al. (2014) for algorithmic details.

A CoAP SSN gateway could also forward the uncovered request in the area of interest as a new request to other gate-ways. In this way, each gateway searches for more resources to satisfy lacking features through cooperative multi-hop discovery. The gateway also forwards all the query param-eters related to the original request and includes an addi-tional attribute (hop) to specify the depth reached in the collaborative discovery, i.e., the number of nodes crossed to satisfy the request. As shown in Fig. 4, hop will be increased at each forwarding stage and can be used to limit

the collaborative discovery procedure at a given accept-able limit. This value can be customized for each network, according to device performance and network configuration, to prevent useless or too far gateways from being involved in the discovery. This reduces both overall data exchange and response latency.

4.3 Mobile client

A mobile client6 was also devised to enable the communica-tion between SSNs and Android-based devices. It provides the following capabilities.

—SSN browsing and sensor discovery. The user can view all sensors connected to a specific gateway or only devices selected through semantic-based discovery, as shown in Fig. 5a. A radial indicator shows the resource score with respect to the discovery request. Furthermore, its properties (Fig.5b) and location can be seen. Data measured by each sensor can be also retrieved. In addition to classic CoAP messages, a semantic-based CoAP request can be composed as in Fig. 5c. For each attribute, the user must specify a value. Finally, the semantic description is completed by selecting properties and classes extracted from the reference ontology on a list-based menu (Fig. 5d);

—Collaborative sensing When a mobile node (e.g., an Android smartphone) connects to a CoAP gateway for SSN browsing, it becomes also an information source temporarily connected to that gateway. Therefore it exposes data streams coming from its embedded microdevices (e.g., accelerom-eter, gyroscope) as well as from nearby beacons and sensing devices connected by means of low-range wireless protocols, e.g., Bluetooth Low Energy. These data further characterize the reference environment, enabling a better context detec-tion. In this way, mobile nodes are encouraged to share their perceptions with the rest of the SSN in order to obtain a more accurate feedback.

4.4 Data mining

In WSN scenarios, large amounts of data have to be col-lected and interpreted to extract useful application infor-mation. Scenarios like environmental monitoring strongly require automatic procedures. The proposed framework includes a simple, yet effective data mining method for SSNs, designed to extract significant information from sensor readings and annotate it. The steps for identification

2 6 5

1 3 Forwarded hop=1

hop=1

hop=2

hop=2

hop=3

4 Not Forwarded

Fig. 4 Example of request forwarding

6 Developed using Android SDK Tools (revision 26.0.1), Android Platform version 5.1 (API level 22), and tested on a Google LG Nexus 4 smartphone with Qualcomm APQ8064 Snapdragon S4 Pro Quad Core CPU at 1.5 GHz, 2 GB RAM, 16 GB internal memory, and Android version 5.1.1. Source code available online on the pro-ject repository.

CoAP-based collaborative sensor networks in the Semantic Web of Things

1 3

of high-level events from sensory data streams are outlined hereafter:

—Both data streams from smartphone microdevices and those from field sensors are read and collected in a given time window through standard CoAP requests. A list of ele-ments is built, consisting of ⟨ID, value, timestamp⟩ triples. ID is the sensor identifier, denoting indirectly the type of data, while value is the data point.

—To evaluate the variability of the information collected in the monitored area, mean and variance of data in the cur-rent time window are calculated.

—Incremental ratios of the above indexes are calculated on the same time windows, in order to detect significant changes in the collected data, which can be traced back to relevant events.

—A (binary or multiple) classifier is exploited to detect relevant events when given conditions occur, for every data stream. The identification is performed by taking into account threshold values for statistical indexes.

—Finally, a logic-based annotation referred to knowledge modeled in a proper ontology (formalizing a conceptualiza-tion of the sensing domain) is built as logical conjunction of all expressions derived from sensor data.

5 Case study

A case study on cooperative environmental risk monitoring has been developed to highlight peculiarities of the proposed framework. Considering the reference scenario sketched in Sect. 2, each RSU of the HSVN acts as a CoAP gateway and periodically queries the CoAP sinks in its range, which return the most suitable sensors set. The RSU can then start gathering raw data from sensors, further destined to a min-ing procedure as described in Sect. 4.4. Event annotations are then exposed for external applications. With reference to parameters in Table 3, three RSUs, eight sinks and four-teen sensors compose the example network, with maximum distance of 100 m between a sensor and its sink and 1000 m between a sink and its RSU. As reported in Ruta et al. (2013), the SSN-XG ontology proposed in Compton et al. (2012) has been extended to specify both observed param-eters (e.g., temperature, humidity, atmospheric pressure, wind speed) and sensor measurement capabilities (e.g., accuracy, precision, resolution, frequency) as conjunctive concept expressions. It has maintained the Stimulus-Sen-sor-Observation design pattern in Compton et al. (2012) for that. Fig. 6 shows an example of a temperature sensor modeling. In general, a sensor measures entities modeled as subclasses of ssn:FeatureOfInterest and has proper measurement capabilities expressed as subclasses of the ssn:MeasurementCapability class. In turn, each specific subclass of ssn:MeasurementCapability has a set of measurement properties and (optional) operating range, represented as subclasses of the ssn:Property class. Furthermore, a sensor is related to a subclass of ssn:EnergyDevice through the ssn:hasSubSystem property featuring its energy source.

Let us consider a car travelling in the morning on SS16, a highway near Bari in Italy. The air humidity is high and the atmospheric pressure values quite low. Furthermore, the road has low-density traffic with less than 100 vehicles flowing per hour. Possible risks are due to crossroads. The scenario was randomly generated by the JOSM plugin pre-sented in Sect. 4.1, as shown in Fig. 7. The RSU1 gateway composes a discovery request Q reported in Fig. 8 (OWL 2 Manchester Syntax adopted). For the sake of readability,

Fig. 5 Mobile CoAP SSN client

M. Ruta et al.

1 3

concept expressions for both request and sensors are summa-rized in textual form. The CoAP GET request also includes: (1) the RSU reference location P, defined through attributes lt and lg; (2) maximum distance md; (3) minimum cov-ering threshold sr for resource retrieval. RSU1 looks for devices located near SS16 with a maximum distance of 2000 m from P and a coverage threshold value of 75%. After a distance-based pre-filtering, RSU1 solves Algorithm 1.

Figure 8 reports on semantic descriptions for the request and some of the sensors inside the measurement area in

Fig. 7, connected to the gateway node RSU1. Based on the required measurement features, active sinks retrieve a cover-ing set Sc(RSU1) composed of SE95Sensor, BMP085Sensor and FS11Sensor. They do not fully cover the request, the uncovered part is URSU1 , corresponding to the 53.85% of Q. In particular, no anemometer or humidity sensors have been retrieved, while SE95Sensor and BMP085Sensor do not completely satisfy the required features in terms of tem-perature and pressure measurement capabilities. Accord-ingly, RSU1 sends a CoAP semantic request to each reach-able gateway (in the reference scenario, RSU2), forwarding URSU1 to possibly discover remaining sensors. Based on its configuration, Sc(RSU2) is composed by Hts2030Sensor, while URSU2 is 30.77%. Likewise, RSU2 sends URSU2 to RSU3, obtaining BitLineBLVSensor. Finally, RSU2 returns the discovered sensor set to RSU1, also specifying the final uncovered part URSU3 , corresponding to 21.33% of the origi-nal Q.

Now RSU1 acquires data from the retrieved sensors for weather event detection. Let us suppose after a period of observation the mining process produces the following aver-age values for the gathered parameters: sea level tempera-ture: 7.09 ◦C ; temperature between 0 ÷599 m: 1.98 ◦C ; tem-perature between 600÷1499 m: 1.01 ◦C ; temperature ≥ 1500 m: − 2.34 ◦C ; relative humidity: 80.5%; wind speed: 19.7 km/h; atmospheric pressure: 971.5 mbar; visibility: 254.4 m.

Based on studies and laws of weather science, a classifier has been designed, able to detect one of the weather condi-tions reported in Table 5.

The mining process described in Sect. 4.4 identifies Fog and Rain events; due to high humidity and low pressure val-ues. Each detected event is annotated w.r.t. the reference ontology as subclass of the Weather concept and in terms of safety requirements a car must implement to limit risks (Fig. 9).

ssn:SensingDevice

ssn:EnergyDevice

TemperatureSensor

Ba�ery

HighLifeTimeBa�ery

Panasonic_VLRA_LC

rdfs:subClassOf

rdfs:subClassOf

rdfs:subClassOf

rdfs:subClassOf

rdfs:subClassOf

ssn:hasSubsystem

SE95TemperatureSensor

ssn:FeatureOfInterest

Temperature

rdfs:subClassOf

ssn:observes

ssn:SurvivalProperty

ssn:Ba�eryLife�me HighBa�eryLife�me

ssn:Property

rdfs:subClassOf

ssn:MeasurementProperty

rdfs:subClassOf

SE95TemperatureMeasurementCapability

ssn:hasMeasurementProperty

ssn:MeasurementCapability

TemperatureMeasurementCapability

rdfs:subClassOf

rdfs:subClassOf

ssn:Resolu�on

ssn:Accuracy

ssn:Frequency

ssn:hasSurvivalProperty

rdfs:subClassOf

rdfs:subClassOf

ssn:hasMeasurementCapability

rdfs:subClassOf

Fig. 6 Temperature sensor modeling

Fig. 7 Case study for HSVN configuration

Q (request) ≡ Sensor and (hasTemperature only (LowRes. andLowAcc. and HighLaten.)) and (hasVisibility only (LowAcc.and LowFreq.)) and (hasOperatingRange only MedHighAltit.) and(hasPressure only (LowAcc. and MediumRes.)) and (hasWindSpeedonly (MediumRes. and MediumAcc. and LowPrec.)) and (hasHumidityonly (MediumAcc. and MediumRes. and HighFreq.))

TSic306Sensor (S1) ≡ TemperatureSensor and (hasTemperatureonly (HighAcc. and LowRange and MediumRes. and MediumPrec. andMediumFreq.)) and (hasOperatingRange only LowAltit.)

SE95Sensor (S3) ≡ TemperatureSensor and (hasTemperatureonly (LowAcc. and HighRange and LowRes. and HighFreq. )) and(hasOperatingRange only MedHighAltit.)

BMP085Sensor (S2) ≡ Barometer and (hasPressure only (LowAcc.and MediumRes. and LowRange and MedPrec.))

FS11Sensor (S2) ≡ VisibilitySensor and (hasVisibility only(LowAcc. and LowRes. and LowFreq. and LowSelect.))

Hts2030Sensor (S5) ≡ HumiditySensor and (hasHumidity only(MediumAcc. and MediumRes. and MediumRespTime and HighFreq.))

BitLineBLVSensor (S7) ≡ AnenometerSensor and (hasWindSpeed only(MediumAcc. and LowRes. and MiddleRange and LowPrec.))

Fig. 8 Request and sensors descriptions

CoAP-based collaborative sensor networks in the Semantic Web of Things

1 3

RSU1 waits for vehicles equipped with a wireless inter-face entering its radio range. Let us suppose the vehicles described in Fig. 10 drive nearby RSU1 and are equipped with a system for real-time monitoring and driving assis-tance like the one described in Ruta et al. (2010). Each vehicle is able to interpret data extracted from On-Board Diagnostics (OBD-II) car interface and smartphone micro-devices integrating local environmental information and potential risk factors in a proper annotation. Each RSU can use the information received from cars to further enrich event descriptions, e.g., with road surface conditions and traffic level.

As soon as a vehicle comes into the gateway radio cover-age, RSU1 will exploit the Concept Abduction inference service to infer the vehicle risk level (RL) w.r.t. the detected events: very low ( 0 ≤ RL ≤ 1 ), low ( RL = 2 ), medium

( RL = 3 ), high ( 4 ≤ RL ≤ 5 ), very high ( RL = 6 ), ultra high ( RL ≥ 7 ). As evidenced in Table 6, the safest vehicle is SUV_Car, because it is equipped with snow tires (also useful in case of rain), fog lamps, ABS and ESP. Sedan_Car has higher risk level in case of rain due to its high speed and due to lacking of ribbed tires. This contributes to increase the risk level in a significant way, despite the activated ABS and fog lamps. Absolutely inadequate for the detected weather conditions are the safety equipment and the high speed of the Economy_Car; indeed it has the highest risk level.

6 Evaluation

In order to obtain a quantitative performance analysis of the proposed framework, the following metrics were considered: (1) average response time and data transfer during gateway initialization phase and (2) average response time and data transfer for performing the discovery procedure. Taking as a reference the network configuration in Fig. 7, semantic-enhanced CoAP servers and sink nodes were deployed on heterogeneous hardware platforms with different computing resources. The main goal was to verify how the framework performance varies according to the different hardware exploited to build SSN devices. In particular, as shown in Fig. 11, the following embedded boards have been used to implement the semantic sensor network:

(a) one UDOO Quad7 board, corresponding to RSU1 gate-way, equipped with quad-core ARM Cortex A9 CPU at 1 GHz clock frequency, ARM Cortex M3 coprocessor, 1 GB DDR3 RAM, 32 GB storage memory on SD card, UDOObuntu 2.0 Minimal Edition OS;

(b) two Raspberry Pi Model B8, representing the RSU2 gateway and the S3 sink nodes, equipped with a single-core ARM11 CPU at 700 MHz, 512 MB RAM (shared with GPU), 8 GB storage memory on SD card, Rasp-bian Wheezy OS;

(c) one Zolertia WSN Gateway9 as RSU3 gateway con-nected to three Z1 motes10 acting as sink nodes (S6,

Fog ≡ Weather and (hasSpeed only ModerateSpeed) and (hasLamponly FogLamp) and (hasSafetyDevice only ABS)

Rain ≡ Weather and (hasSpeed only ModerateSpeed) and(hasSafetyDevice only (ABS and ESP)) and (hasPneumatic onlyRibbedTire)

Fig. 9 Weather events descriptions

Table 5 Criteria for weather event detection

tddew point temperature

Parameters Weather event

Fog Wind Rain Snow

Temp 0 m ( ◦�) – – ≥ 6 –Temp 0 ÷599 m ( ◦�) t − td ≤ 4 – – ≤ 5Temp 600÷1499 m ( ◦�) – – – 5÷10Temp ≥ 1500 m ( ◦�) – – – ≤ 0Visibility(m) ≤ 1000 – – –Wind speed (km/h) – ≥ 100 – –Humidity (%) – – 80÷100 –Pressure (mbar) – – 970÷1000 –

SUV Car ≡ Vehicle and SUV and (hasSpeed only ModerateSpeed) and(hasLamp only (XenonLamp and FogLamp)) and (hasSafetyDevice only(ABS and ESP)) and (hasPneumatic only SnowTire)SUV Car Sensed ≡ (trafficLevel only Low) and (roadSurface onlyIrregular)

Sedan Car ≡ Vehicle and Sedan and (hasSpeed only HighSpeed)and (hasLamp only FogLamp) and (hasSafetyDevice only ABS) and(hasPneumatic only SlickTire)Sedan Car Sensed ≡ (trafficLevel only Low) and (roadSurface onlySlightlyIrregular)

Economy Car ≡ Vehicle and EconomyCar and (hasSpeed onlyHighSpeed) and (hasLamp only HeadLamp) and (hasPneumatic onlySlickTire)Economy Car Sensed ≡ (trafficLevel only Low) and (roadSurfaceonly Irregular)

Fig. 10 Vehicles semantic annotations

Table 6 Vehicle risk levels for detected events

SUV_Car Sedan_Car Economy_Car

RLFog Very low (1) Low (2) Very high (6)RLRain Very low (1) High (4) Very high (7)

7 http://www.udoo.org/udoo-dual-and-quad.8 http://www.raspb erryp i.org/produ cts/model -b/.9 http://zoler tia.sourc eforg e.net/wiki/index .php/Mainp age:Gatew ay.10 http://githu b.com/Zoler tia/Resou rces/wiki/The-Z1-mote.

M. Ruta et al.

1 3

S7 and S8) establishing an IEEE 802.15.4 network. Each mote is equipped with MSP430F2617 low-power microcontroller, which features a 16-bit RISC CPU at 16 MHz, 8 KB RAM and 92 KB of flash memory. The Zolertia Gateway itself is equipped with an internal Z1 mote that runs a border router application to enable the communication between the IEEE 802.15.4 motes and the other devices compliant with IEEE 802.11;

(d) two Intel Edison Kit boards11, corresponding to S4 and S5 sinks, equipped with an Intel Quark x86 CPU at 400 MHz, 1 GB RAM, 4 GB eMMC flash storage and Yocto Poky Linux OS (32-bit kernel 3.10.98);

(e) two Arduino Due12, corresponding to S1 and S2 sinks, equipped with an ARM Cortex-M3 CPU, 96 KB SRAM and 512 KB of flash storage memory.

Network Initialization. Effectiveness of the proposed approach has been evaluated measuring data transfers and time required by CoAP gateways to initialize their resources and retrieve sensors suitable for road environment moni-toring. All messages contain a payload encoded by means of FemtoZip library to minimize the data exchange. In this phase, each gateway sends a basic CoAP GET request to each connected sink in order to obtain data about all avail-able sensors. As shown in Fig. 12, RSU1 and RSU2 send a single request message of about 27 bytes and receive one response packet by each sink with an average size of 388 bytes (depending on the length of compressed OWL anno-tations provided by each sensor). On the contrary, RSU3 exchanges more data with the sinks due to the smaller size of each CoAP packet on the IEEE 802.15.4 network, which has a maximum frame size of 48 B. In this case, accord-ing to the CoAP Block-Wise Transfers specification by Bor-mann and Shelby (2016), the gateway sends the same CoAP request several times with a different value of the block2

option, until the response is completely received. Due to this reason, RSU3 also presents the highest communica-tion time (reported in Fig. 13), defined as interval between the discovery request sent by the gateway and the response received from the sink. Sink devices based on RaspberryPi and Intel Edison require the smallest times to reply, thanks to the faster I/O and network operations. Instead, the process-ing time depends only on the gateways’ capabilities and is spent to: (1) parse received data to extract semantic-based attributes; (2) decode and process sensor annotations; (3) create for each sensor a remote resource used to query the device after the discovery procedure. As highlighted, UDOO board provided better results than RaspberryPi and Zolertia Gateway (which show similar performances).

RSU1

S1

S2

S3

(a)RSU1 subnetwork

RSU2

S4 S5

(b)RSU2 subnetwork

RSU3

S6

S7

S8

(c)RSU3 subnetwork

Fig. 11 Testbed devices

0

200

400

600

800

1000

1200

S1 S2 S3 S4 S5 S6 S7 S8

RSU1 RSU2 RSU3

Mes

sage

Siz

e (b

yte)

Request Response

Fig. 12 Data exchanged during network initialization

0

1000

2000

3000

4000

5000

S1 S2 S3 S4 S5 S6 S7 S8

RSU1 RSU2 RSU3

Tim

e (m

s)

Communica�on Time Processing Time

Fig. 13 Gateways initialization time

11 http://www.intel .com/conte nt/www/us/en/do-it-yours elf/ediso n.html.12 http://www.ardui no.cc/en/Main/Ardui noBoa rdDue .

CoAP-based collaborative sensor networks in the Semantic Web of Things

1 3

Collaborative Discovery. Experiments have been car-ried out performing the collaborative discovery procedure described before to satisfy a common request with 15 dif-ferent configurations reported in Table 7. This test aimed to feature in detail the performance of the proposed frame-work. Each configuration consists of a reference gateway

( GW1 ) receiving the discovery request and one or two addi-tional gateways ( GW2 and GW3 ) sequentially called in case of forwarded requests. Tests have been repeated five times and average time values have been taken. In particular, the turnaround time in Table 7 is defined as the time elapsed on the device starting a semantic-based discovery to send the request and receive the related reply. The covering value, instead, represents how much the request is satisfied after the overall discovery process. It can be noticed that both processing time and covering value grow as more gateways are involved in the collaborative discovery. In particular, Fig. 14 shows the contribution added by each gateway to the overall covering score during the collaborative discovery. In the same way, the response time is greater with respect to the configurations with a single gateway (1–3 in Table 7). As detailed in Fig. 15, the resource discovery consists of the following tasks performed by a semantic-based gateway:

Table 7 Testbed configuration ID Max Hop GW1 GW2 GW3 Covering (%) Time (ms)

1 0 RSU3 – – 38.46 18582 RSU2 – – 34.62 23923 RSU1 – – 46.15 7434 1 RSU3 RSU1 – 73.08 42505 RSU2 – 53.85 58546 RSU2 RSU1 – 69.23 48117 RSU3 – 53.85 57898 RSU1 RSU2 – 69.23 33769 RSU3 – 73.08 357010 2 RSU3 RSU1 RSU2 78.67 819511 RSU2 RSU1 78.67 1074612 RSU2 RSU1 RSU3 78.67 856213 RSU3 RSU1 78.67 1013714 RSU1 RSU2 RSU3 78.67 738715 RSU3 RSU2 78.67 7460

20

30

40

50

60

70

80

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Cove

ring

Scor

e (%

)

Covering-GW1 Covering-GW2 Covering-GW3

Fig. 14 Covering results

0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000

123456789

101112131415

Request Time (ms)

Request Loading Local Covering Forward-1 Forward-2 Response Genera�on Communica�on

Fig. 15 Processing time

M. Ruta et al.

1 3

– Request loading. Decode the received request and load the related annotation in the reference KB;

– Local covering. Perform the Concept Covering locally and select most suitable sensors to satisfy the request;

– First forward. GW1 forwards the uncovered request to GW2 (only if max_hop ≥ 1);

– Second forward. GW2 forwards the uncovered request to GW3 (only if max_hop = 2);

– Response generation. Compose the discovery reply according to CoRE Link Format;

– Communication. Receive the request and send the overall discovery response by means of CoAP messages.

As expected, longer processing time is mainly due to the number of devices (i.e., number of forwarded requests) involved in the process. However, it can be noticed a sig-nificant variation among configurations with the same maximum hop value, due to the different adopted hardware. RaspberryPi requires a longer time to load and process the requests due to lower computational capabilities. On the contrary, UDOO is the fastest platform, particularly for I/O operations, thanks to the internal flash memory. As a particularly interesting example, configurations 13 and 15 involve the same devices but in different order. In 13, Rasp-berryPi acts as first gateway; it loads and processes the over-all request, covering only 34.62% of it. So, a large uncovered part is produced and forwarded to the other gateways. In configuration 15, the request is received by UDOO: it covers 46.15% of it (thus forwarding a smaller payload), and also performs faster request loading, response generation and communication, as shown in Fig. 15. It is useful to notice covering task is very fast on all platforms, thanks to the inference algorithms of the Mini-ME micro-reasoner from Scioscia et al. (2014), which was expressly designed and implemented for low-performance devices.

Another relevant parameter of the framework perfor-mance is the amount of data exchanged over the network. Figures 16 and 17 report on the total size of requests and responses respectively produced during the discovery pro-cess. Also in this case, both charts specify the amount of data sent and received for each involved gateway. Obviously, data exchanged increase with the device number. In general,

the network load appears as acceptable considering the ver-bosity of semantic-based resource description languages.

7 Conclusion

The paper described a Semantic Sensor Network framework suitable for applications requiring advanced context detec-tion and annotation, such as environmental monitoring and ambient intelligence. It exploits novel backward-compatible CoAP extensions for semantic-based resource description, management and discovery. Efficient data stream mining and collaborative sensing are notable features of the proposal. A case study in a hybrid sensor and vehicular network sce-nario and experimental tests on a real testbed implementa-tion allowed to evaluate feasibility of the approach.

Main limitations of the proposal concern higher request processing time and induced network traffic than in standard CoAP, due to semantic resource annotations. Nevertheless, considering the improvement in the quality of discovery, this appears as acceptable. The distributed and additive request covering approach helps to mitigate both latency and net-work load, because only uncovered parts of requests are for-warded. As a further drawback, developing sensor networks with the proposed framework may be more complex than with non-semantic approaches. The development effort may not pay back for small-scale networks with homogeneous devices and limited application scope. Conversely, the pre-sented approach is beneficial in dynamic complex scenarios like large-scale distributed environmental monitoring, where wide interoperability is required and sensing tasks need care-ful selection of data sources and devices.

Future work includes: the combination of machine learn-ing algorithms with semantic-based sensor data management for more flexible context mining; the adoption of Linked Data Platform—W3C Recommendation edited by Speicher et al. (2015)—to expose and organize resources in CoAP servers, as proposed by Loseto et al. (2016); the integration of specialized compression algorithms for Semantic Web languages such as in Scioscia and Ruta (2009) to further reduce storage and network load.

0

500

1000

1500

2000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Requ

est S

ize

(Byt

e)

Request-GW1 Request-GW2 Request-GW3

Fig. 16 Request size

0 1000 2000 3000 4000 5000 6000 7000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Resp

onse

Siz

e (B

yte)

Response-GW1 Response-GW2 Response-GW3

Fig. 17 Response size

CoAP-based collaborative sensor networks in the Semantic Web of Things

1 3

Acknowledgements The authors acknowledge partial support of the Italian PON project ASMARA (Pilot Applications post Directive 2010/65 in Italian port realities of the Suite MIELE to support the Authority to optimize the inteRoperability in the intermodAlity of city-port flows).

References

Baader F, Calvanese D, McGuinness DL, Nardi D, Patel-Schneider P (2002) The description logic handbook. Cambridge University Press, Cambridge

Barnaghi P, Presser M, Moessner K (2010) Publishing linked sensor data. In: CEUR Workshop Proceedings: Proceedings of the 3rd International Workshop on Semantic Sensor Networks (SSN), Organised in conjunction with the International Semantic Web Conference, vol 668

Bormann C, Shelby Z (2016) Block-Wise Transfers in the Constrained Application Protocol (CoAP). Internet proposed standard RFC 7959

Bormann C, Castellani AP, Shelby Z (2012) CoAP: an application protocol for billions of tiny internet nodes. Internet Comput IEEE 16(2):62–67

Compton M, Barnaghi P, Bermudez L, García-Castro R, Corcho O, Cox S, Graybeal J, Hauswirth M, Henson C, Herzog A et al (2012) The SSN ontology of the W3C semantic sensor network incubator group. Web Seman Sci Serv Agent World Wide Web 17:25–32

Cyganiak R, Wood D, Lanthaler M (2014) RDF 1.1 concepts and abstract syntax. W3C Recommendation https ://www.w3.org/TR/rdf11 -conce pts/

Desai P, Sheth A, Anantharam P (2015) Semantic Gateway as a Service Architecture for IoT Interoperability. In: 2015 IEEE International Conference on Mobile Services, pp 313–319

Djamaa B, Yachir A, Richardson M (2017) Hybrid CoAP-based resource discovery for the Internet of Things. J Ambient Intell Humaniz Comput 8(3):357–372

Doblander C, Ghinaiya T, Zhang K, Jacobsen HA (2016) Shared dic-tionary compression in publish/subscribe systems. In: Proceedings of the 10th ACM International Conference on Distributed and Event-based Systems, ACM, New York, NY, USA, DEBS ’16, pp 117–124

Gandomi A, Haider M (2015) Beyond the hype: big data concepts, methods, and analytics. Int J Inf Manag 2(35):137–144

Gobelbecker M, Dornhege C (2009) Realistic Cities in Simulated Envi-ronments—an Open Street Map to Robocup Rescue Converter. In: 4th International Workshop on Synthetic Simulation and Robotics to Mitigate Earthquake Disaster (SRMED 2009)

Görgü L, Kroon B, O’Grady MJ, Yılmaz Ö, O’Hare GM (2017) Sensor discovery in ambient IoT ecosystems. J Ambient Intell Humaniz Comput. https ://doi.org/10.1007/s1265 2-017-0623-0

Guinard D, Trifa V (2009) Towards the Web of Things: Web Mashups for Embedded Devices. In: Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web (MEM 2009), in proceedings of WWW (International World Wide Web Confer-ences), Madrid, Spain

Hartke K (2015) Observing resources in the constrained application protocol (CoAP). RFC 7641. https ://doi.org/10.17487 /RFC76 41, URL https ://rfc-edito r.org/rfc/rfc76 41.txt

Heath T, Bizer C (2011) Linked Data: evolving the web into a global data space. Synthesis lectures on the semantic web: theory and technology. Morgan and Claypool Publishers, San Rafael, USA

Koutsopoulos I (2013) Optimal incentive-driven design of participatory sensing systems. In: IEEE International Conference on Computer Communications (Infocom 2013), IEEE, pp 1402–1410

Kovatsch M, Mayer S, Ostermaier B (2012) Moving application logic from the Firmware to the cloud: towards the thin server archi-tecture for the internet of things. In: 6th Int. Conf. on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS 2012)

Le-Phuoc D, Nguyen-Mau HQ, Parreira JX, Hauswirth M (2012) A middleware framework for scalable management of linked streams. Web Seman Sci Serv Agent World Wide Web 16:42–51

Llaves A, Corcho O, Taylor P, Taylor K (2016) Enabling RDF stream processing for sensor data management in the environmental domain. Int J Semant Web Inf Syst (IJSWIS) 12(4):1–21

Loseto G, Ieva S, Gramegna F, Ruta M, Scioscia F, Di Sciascio E (2016) Linked Data (in low-resource) Platforms: a mapping for Constrained Application Protocol. In: International Semantic Web Conference, Springer, pp 131–139

Patni H, Henson C, Sheth A (2010) Linked Sensor Data. In: Collabora-tive Technologies and Systems (CTS), 2010 International Sympo-sium on, IEEE, pp 362–370

Perera C, Zaslavsky A, Liu C, Compton M, Christen P, Georgakopou-los D (2014) Sensor search techniques for sensing as a service architecture for the internet of things. Sens J IEEE 14(2):406–420. https ://doi.org/10.1109/JSEN.2013.22822 92

Pfisterer D, Romer K, Bimschas D, Kleine O, Mietz R, Truong C, Hasemann H, Kroller A, Pagel M, Hauswirth M et al (2011) SPITFIRE: toward a semantic web of things. Commun Mag IEEE 49(11):40–48

Ruta M, Scioscia F, Gramegna F, Di Sciascio E (2010) A Mobile Knowledge-based System for On-Board Diagnostics and Car Driving Assistance. UBICOMM 2010, The 4th Int. Conf. on Mobile Ubiquitous Computing, Systems, Services and Technolo-gies, pp 91–96

Ruta M, Di Sciascio E, Scioscia F (2011) Concept abduction and con-traction in semantic-based P2P environments. Web Intell Agent Syst 9(3):179–207

Ruta M, Scioscia F, Di Sciascio E (2012) Enabling the Semantic Web of Things: framework and architecture. Sixth IEEE International Conference on Semantic Computing (ICSC 2012). IEEE, IEEE, pp 345–347

Ruta M, Scioscia F, Pinto A, Di Sciascio E, Gramegna F, Ieva S, Loseto G (2013) Resource annotation, dissemination and discovery in the Semantic Web of Things: a CoAP-based framework. Green Computing and Communications (GreenCom), 2013 IEEE and Internet of Things (iThings/CPSCom). IEEE Int. Conf. on and IEEE Cyber, Physical and Social Computing, IEEE, pp 527–534

Schneider J, Kamiya T, Peintner D, Kyusakov R (2014) Efficient XML Interchange (EXI) Format 1.0 (Second Edition). W3C Recom-mendation https ://www.w3.org/TR/exi/

Scioscia F, Ruta M (2009) Building a Semantic Web of Things: issues and perspectives in information compression. In: Semantic Web Information Management (SWIM’09). In Proceedings of the 3rd IEEE International Conference on Semantic Computing (ICSC 2009), IEEE Computer Society, pp 589–594

Scioscia F, Ruta M, Loseto G, Gramegna F, Ieva S, Pinto A, Di Scias-cio E (2014) A mobile matchmaker for the ubiquitous semantic web. Int J Seman Web Inf Syst 10(4):77–100

Shelby Z (2012) Constrained RESTful Environments (CoRE) Link Format. RFC 6690, https ://doi.org/10.17487 /RFC66 90. https ://rfc-edito r.org/rfc/rfc66 90.txt

Shelby Z, Hartke K, Bormann C (2014) The Constrained Application Protocol (CoAP). RFC 7252, https ://doi.org/10.17487 /RFC72 52. https ://rfc-edito r.org/rfc/rfc72 52.txt

Sheng X, Tang J, Xiao X, Xue G (2013) Sensing as a service: challenges, solutions and future directions. IEEE Sens J 13(10):3733–3741

Speicher S, Arwe J, Malhotra A (2015) Linked Data Platform 1.0. W3C Recommendation http://www.w3.org/TR/ldp/

M. Ruta et al.

1 3

Taylor K, Leidinger L (2011) Ontology-driven complex event process-ing in heterogeneous sensor networks. Research and applications, the semanic web, pp 285–299

Tran KN, Compton M, Jemma Wu RG (2010) Semantic Sensor Composition. In: 3rd Int. Work. on Semantic Sensor Networks. Proc. of the 9th International Semantic Web Conf. (ISWC 2010), CEUR-WS, CEUR Workshop Proceedings, vol 668, pp 33–48

W3C OWL Working Group (2012a) OWL 2 Web Ontology Language Document Overview (Second Edition). W3C Recommendation https ://www.w3.org/TR/owl2-overv iew/

W3C OWL Working Group (2012b) OWL 2 Web Ontology Language Manchester Syntax (Second Edition). W3C Working Group Note, W3C, https ://www.w3.org/TR/owl2-manch ester -synta x/

W3C SPARQL Working Group (2013) SPARQL 1.1 Overview. W3C Recommendation https ://www.w3.org/TR/sparq l11-overv iew/