Unified Data Model for Wireless Sensor Network - IEEE Xplore

5 downloads 4696 Views 2MB Size Report
THE constant evolution of wireless technologies and the miniaturization of devices have led to the massive usage and development of Wireless Sensor ...
IEEE SENSORS JOURNAL, VOL. 15, NO. 7, JULY 2015

3657

Unified Data Model for Wireless Sensor Network Lina Nachabe, Member, IEEE, Marc Girod-Genet, Member, IEEE, and Bachar El Hassan, Member, IEEE

Abstract— The constant evolution of technology in terms of inexpensive and embedded wireless interfaces and powerful chipsets has led to the massive usage and deployment of wireless sensors networks (WSNs). These networks are made of a growing number of small sensing devices and are used in multiple use cases, such as home automation (e.g., smart buildings), energy management and smart grids, crisis management and security, e-Health, entertainment, and so forth. Sensor devices, generally self-organized in clusters and domain dedicated, are provided by an increasing number of manufacturers, which leads to interoperability problems (e.g., heterogeneous interfaces and/or grounding, heterogeneous descriptions, profiles, models, and so forth). Furthermore, the data provided by these WSNs are very heterogeneous because they are coming from sensing nodes with various abilities (e.g., different sensing ranges, formats, coding schemes, and so forth). In this paper, we propose a solution for handling WSNs’ heterogeneity, as well as easing interoperability management. The solution consists of a semantic open data model for sensor and sensor data generic description. This data model, designed for handling any kind of sensors/actuators and measured data (which is still not the case of existing WSNs data models), is fully detailed and formalized in an original ontology format called MyOntoSens and written using Ontology Web Language 2 description logic language. The proposed ontology has been implemented using Protégé 4.3, prevalidated with pellet reasoner, and is being standardized (A Body Area Network (BAN) dedicated instance of the proposed “MyOntoSens” ontology is being standardized as a Technical Specification (TS) within the SmartBAN Technical Committee of the ETSI (European Telecommunications Standards Institute) standardization body: ETSI SmartBAN Technical Committee website: portal.etsi.org/portal/server.pt/community/SmartBAN/368v). In addition, this original ontology has been prequalified through a runner’s exercise monitoring application, using in particular SPARQL query language, within a small wireless body area network platform comprising heartbeat, GPS sensors, and Android mobile phones. Index Terms— Sensor, WSNs, BANs, heterogeneity management, semantic, ontology, open data model, OWL 2 DL, Protégé, pellet.

I. I NTRODUCTION

T

HE constant evolution of wireless technologies and the miniaturization of devices have led to the massive usage and development of Wireless Sensor Networks (WSNs), which potentially affects all aspects of our lives ranging from

Manuscript received October 14, 2014; revised January 14, 2015; accepted January 15, 2015. Date of publication January 19, 2015; date of current version May 13, 2015. The associate editor coordinating the review of this paper and approving it for publication was Dr. Santiago Marco. The authors are with the Département Réseaux et Services Multimédia Mobiles, Telecom Sud Paris, Evry 91001, France (e-mail: lina_nachabe@ yahoo.com; [email protected]; bachar.elhassan@ gmail.com). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/JSEN.2015.2393951

health care through home automation and energy management, to military services and many other applications. WSNs are networks of small sensing devices collaborating with each other to gather, process and communicate information about some physical phenomena over wireless channels [1]. In addition, a data-centric approach is used and a WSN is viewed as a distributed system consisting of many autonomously cooperating nodes at the application level [2]. These nodes can be grouped to form clusters. Each cluster can have one or multiple sinks. In general, the data is sent hop by hop to the elected sink which can then forward it to an external gateway in order to be e.g. stored and managed either in a dedicated cloud or in remote monitoring and management centers. There are many characteristics and constraints associated with a WSN. One of the main constraints is the topology changes of such network where hundreds to thousands of sensors and actuators are deployed randomly in the sensing fields. These nodes are either stationary or moving, which leads to highly dynamic and multiple scales networks being prone to frequent failures. WSNs are thus self-organizing networks where nodes frequently change their positions and/or geo-locations, and states (e.g. active or sleep modes). Furthermore, as additional sensors may be deployed or changed at any time, the need for a dynamic network reconfiguration seems to be essential in these networks. Low power and low energy are also two other main constraints of WSNs. Indeed, sensors are micro-electronic devices generally equipped with limited and irreplaceable source of energy like cell batteries. They also have restricted energy source, power, memory and computational capabilities. In many cases, the nodes are deployed in inaccessible and unattended areas. In addition, the installation and maintenance of WSNs are considered expensive. Thus, the remote management and the extension of life-time are at the heart of WSNs’ characteristics. An important issue to be considered in these networks is their heterogeneity in terms of node models and profiles, data gathered (e.g. sensing ranges, formats, coding schemes and metadata), communication protocols and/or grounding, and applications. Within the same WSN, each node coming from different manufacturers may offer different processing functionalities and may require different resources depending on its role (node, actuator or sink). Furthermore, the required data rate and data type may diverge from one application to another. Where some scenarios need periodic data transmission, others are based on event driven or on requests from a gateway. In Body Area Networks (BANs) for example, real-time monitoring and alarms, as well as reliability and maximum security levels are also mandatory. Additionally, the lifetime and Quality of Service (QoS) also vary from

1530-437X © 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

3658

IEEE SENSORS JOURNAL, VOL. 15, NO. 7, JULY 2015

one WSN to another. All these aforementioned interoperability and heterogeneity issues complicate WSNs interworking and thus make actually impossible the generic interactions with any kind of sensors at the management, monitoring and application levels (e.g. generically reuse and share of their data within different applications). In order to provide solutions to the aforementioned heterogeneity and interoperability issues, we must in particular assign an explicit and common semantic to every terminology used, i.e. introduce and specify an open data model dedicated for WSNs. Since this open data model has to incorporate in particular the grounding information of the WSN nodes, it will thus facilitate WSNs interworking. Using the formal definition extracted from [3], ontologies are “tools for specifying the semantics of terminology system in a well-defined and unambiguous manner”. Ontologies can then be used to formalize the WSN dedicated open data model by introducing a common vocabulary, associated with well-defined semantics, for data (sensed, monitoring, control, alarms…) and information sharing between different components, applications and services in WSNs. In this paper, we present, formalize and pre-validate an original semantic open data model dedicated for sensor and sensor data generic description. This model is designed for handling any kinds of sensors/actuators and their associated data, thus providing a solution to interoperability and heterogeneity management key issues in WSNs. The foremost reason behind this semantic ontology is also to provide associated standardized information management enablers allowing: the discovery of nodes and clusters, the effective data collection and aggregation, and the dynamic monitoring and control for WSNs. The paper is organized as follows. Section II provides a brief survey about the existing data models and ontologies for WSNs. The full specification and formalization of our proposed semantic open data model and ontology for WSNs is provided within section III. Then, a first symbolic validation and a pre-qualification of our ontology (through a runner exercise monitoring application within a small WBAN test platform) are depicted and discussed in section IV. Finally, section V concludes the paper. II. E XISTING O NTOLOGIES Reviewing the literature on WSNs’ ontologies [4], [5], we notice that some ontologies are dedicated to the description of sensor’s features and observation, while others introduce characteristics that describe the data. Table 1 presents a comparison between existing ontologies that are focusing on the sensors features and the observed data. Table 1 shows that none of these existing ontologies fully describes the sensor features. For example, while Avancha ontology focuses on the observation’s features, it ignores the sensor characteristics. However, other ontologies have been proposed for describing WSNs while including the observed data. These ontologies, depicted in Table 2, are mainly based on three axes: Sensor, Observation and Data. Table 2 shows that most existing sensor networks’ ontologies do not effectively describe the entire data feature.

TABLE I C OMPARISON B ETWEEN E XISTING O NTOLOGIES BASED ON

S ENSOR AND O BSERVATION

OntoSensor is stemming from a combination of SensorML (Sensor Model Language), defined by Open Geospatial Consortium (OGC or OpenGIS), IEEE Suggested Upper Merged Ontology (SUMO) and the International Organization for Standardization (ISO) 19115 [6]. Its latest updated was released in 2008. The main objective of OntoSensor is to provide an ontological description for sensor data and observations. OntoSensor ontology supports data discovery, processing and analysis of sensor measurements, geo-location of observed values (measured data), performance characteristics (e.g. accuracy, threshold, etc.), and explicit description of the process by which an observation was obtained (i.e. its lineage). It also provides additional functionalities (executable process chain) for new data product derivation. In spite of its quite extensive semantic knowledge model, OntoSensor does not incorporate any distinctive data description model for facilitating observation and data representation interoperability. This is however mandatory for WSNs’ data management. The CISRO ontology, presented by M. Compton in 2009, focuses on describing and reasoning about sensors and observed process, without covering the data part [4]. The Semantic Sensor Network Ontology (SSN), developed by the W3C Semantic Sensor Network Incubator Group in 2009, and updated in 2011, describes the capabilities of sensors, the measurement processes used and the resultant

NACHABE et al.: UNIFIED DATA MODEL FOR WSN

TABLE II C OMPARAISON OF E XISTING O NTOLOGIES BASED ON

3659

TABLE III R EQUIRED ATTRIBUTES P ROPOSED BY NIST

S ENSOR , O BSERVATION , AND D ATA

observations [7], [8]. SSN can also be aligned with other ontologies that describe, for example, the observed phenomena. This ontology covers large parts of the SensorML and O&M (Observations & Measurements) standards from the OGC, omitting calibrations as well as process descriptions and data types which were deemed not sensor specific (if required, it can always be included from other ontologies). However, SSN does not provide facilities for abstraction, categorization, and reasoning offered by semantic technologies. Wireless Semantic Sensor Network Ontology (WSSN) was proposed by W3C to extend SNN with three new concepts: the communication process, the data stream and the state [9]. The “Communicating class” is added to the ontology for describing the sensor communication process. The WSN node and the observed phenomenon pass through several states. In the WSSN ontology, the state of any entity is represented by the “State class”. In 2011, a new semantic ontology, called SWSN, was proposed by Nikoli´c et al. to manage hardware heterogeneity in Wireless Sensor Networks [10]. The proposed architecture consists of three segments: Application, Middleware and Sensor. As shown in Table 2, SWSN includes Sensor,

Observation and Data descriptions. Moreover, unlike previous ontologies, this ontology includes an additional processing component composed of the memory component. However, SWSN does not include security and QoS features that are needed for WSNs’ fault tolerance management. In 2013, the National Institute of Standard and Technology (NIST) proposed the requirements for designing the manufacturing perception sensor ontology [11]. The list of these required attributes is given in Table 3. NIST mainly introduced new attributes that describe data type, state, confidence and provenance. Moreover, NIST has also introduced network topology/geometry and resource processing in their ontology. However, NIST ontology is still under construction. Nevertheless, to efficiently manage a Wireless Sensor Network, more components than the ones already proposed need to be added for conflict resolution, similarity detection, data fusion, routing, error detection, etc. Let us precise that our proposed ontology will overcome these limitations by: • Including all the sensor, observation and data features, • Introducing new components related to WSN management (power, traffic and fault management), the state of links and nodes, the security features and the Quality of Service (QoS). In summary, none of the existing ontologies are fully providing a solution to heterogeneity and interoperability management for WSNs since they are only covering a part of the required information to model. Furthermore, no combination of the existing ontologies is able to provide a complete level of reasoning over sensor data and measurements since

3660

IEEE SENSORS JOURNAL, VOL. 15, NO. 7, JULY 2015

the resulting model will anyway lack extended semantic for that purpose. Thus, we proposed “MyOntoSens” ontology, an original semantic data model and ontology for WSNs that provides a solution for overcoming the aforementioned limitations of existing models, while taking into account the low power and low energy strong requirements of these networks. As this paper has limited space, the essential features of MyOntoSens ontology are described in section III and pre-qualified in section IV, while it has been fully detailed in [12]. III. P ROPOSED O PEN DATA M ODEL AND O NTOLOGY As already discussed in section II, some attempts were made to describe sensors and sensors data. Some properties “MyOntoSens” ontology, are extracted from OntoSensor [6], SSN [7], [8], WSSN [9] and SensorML [6], but reformulated in a semantic description. To ensure extensibility and lightness, we divided our ontology in three main parts: WSN, Nodes, Process and data (this kind of splitting was never proposed before). When defining the properties of each class, we noted that many properties are variables described by their value and unit of measurement (like e.g. frequency, weight, height, speed, etc.). This pushes us to introduce a new class, we called Quantity, and to search for an existing class model that is capable of generically describing any kinds of units. The choice was to use the Unit class from QUDT (Quantities, Units, Dimensions and Data Types) generic model [13]. QUDT was developed by NASA and its last specification and version were released in April 2013. The already proposed SWSN model [10] also suggested the usage of the QUDT ontology for units’ definition due to its wide adaptation in many domains like e-commerce platforms. In the rest of the paper, we only develop the contributed properties of our proposed ontology for WSNs. We will, therefore, not detail the classes and attributes we have directly imported from already existing models (without any modifications). Sections A, B & C will develop each original component of our open data model ontology (“MyOntoSens” ontology). A. MyOntoSens WSN Ontology Even if some existing ontologies (like SSN-XG and WSSN) introduced semantic description of sensors and data, they do not include any specific semantic information about the WSN itself. The use of WSN as independent class in our proposed MyOntoSens ontology paves the way to a new step towards network cooperation and interworking. Indeed, modeling a WSN in a separated class, having WSNID (of type “anyURI”) as a unique identifier and standardized attributes (like application domain, coverage zone, location and radio technology) enables (through the use of SPARQL queries) in particular the automatic discovery of: available neighboring WSNs, WSNs sharing similar properties or application domain. As shown in Fig. 1, MyOntoSens includes two types of WSN: WSN formed of clusters that contain nodes, or WSN

Fig. 1.

Class diagram of the WSN ontology.

that contains nodes not grouped in a cluster. That is why two disjoint object data properties were created: • WSN contains Nodes. (the inverse property of Clusters belong to WSN). • WSN is formed of clusters that are composed of Nodes. The cluster has a determined communication process (Periodic, Event-driven, or by Request) and can elect one or more sinks. The contact person or contact company for each WSN is essential in managing and accessing the WSN. The contact class is an abstract class formed by the union of “ResponsibleParty”, “Person” and “OnlineResource” as shown in Fig.1. The attributes of Contact class and sub-classes are similar to those defined in the SensorML XML schema, but reformulated here in a semantic way [12]. The Patient class (subclass of person) has been added within our model for handling biomedical use cases. This class actually contains attributes coming from Bluetooth LE (Low Energy) profiles provided by the Continua alliance [14], but it can be extended to include any other patient’s attributes. A WSN is also characterized by its required lifetime, density and fault tolerance. We have, therefore, incorporated those attributes within our model in the WSN class. These WSN’s properties can also differ from one sensor network to another. Indeed, while a WSN dedicated for monitoring the concentration of dangerous gases for citizens should last for tens of years, a WBAN could have a lifetime of weeks or few years. In addition, a WBAN should measure accurate value and requires a small fault tolerance and maximum reliability and security levels. B. MyOntoSens Node Ontology A node can be a device playing the role of relay (router, coordinator, etc.), a sensor, an actuator, or a sink (in other terms aggregator, hub, gateway, etc.) as depicted in Fig.2. In general, the sink can monitor other nodes and it is used as an essential indicator in fault management which consists of analyzing network states to detect and to predict potential failures and to take corrective and preventive actions accordingly. One of our major objectives is to enhance WSN’s management. We have, therefore, introduced the new class “LinkState” reflecting the state of a link between two nodes,

NACHABE et al.: UNIFIED DATA MODEL FOR WSN

Fig. 2.

Class diagram of the node’s hierarchy.

Fig. 3.

Class diagram of the node’s properties.

in particular between a node and the sink. The “LinkState” class can in particular keep for each node the record of the last time the sink has received a message from this node. If this time is too long, the sink can predict that this node is facing some troubles. In addition, it will keep track of the error rate of a node and its delay in order to be able to consider a node as invalid. If it is the case, the sink asks the node to go to the inactive mode in order to reduce bandwidth consumption. More data properties could be added to this class in case of a multi-hop topology or for security purposes (e.g. description of the encryption type used in a link). Embedded batteries are typically powering sensor nodes. These batteries have a limited lifetime, even when energy harvesting mechanisms are carried out within the node (as e.g. solar cells or piezo-electric mechanisms). Therefore, energy remains a limited resource to be consumed judiciously and its source is essential in power management. To benefit from this approach, we introduced the “MemoEnergy” class for characterizing the evolution over time of both energy availability and energy consumption of sensor units. When exploring the node’s properties described in previous ontologies, we deduced that we can classify them in two main categories: properties related to the node itself and that change during its lifetime, and properties related to the node type which are static. With this in mind and for improving semantic search and node discovery, the class “NodeType” was created. It provides the constant properties of a node. Figure 3 shows

3661

the classes describing both the dynamic properties (current mode and memo-energy) and the static properties (Interface, Energy Source, Processor and Modes) as defined in our model. Although SWSN has already semantically described the battery and the memory components of a node, it does not separate between dynamic and constant characteristics ([10] and Section 2). On the contrary, in our model, the energy source is introduced in the “Energy” class while the available RAM and Flash memories were included in the “MemoEnergy” class. The node has also a processor, described in the “Processor” class related to the node type. The processor is identified by a “processorID” and contains RAM, ROM and a flash memory. Moreover, it is characterized by the duty cycle, MIPS and frequency (already introduced by SWSSN ontology model). These properties will enhance the network management. For example, the nodes having high MIPS will be engaged in certain tasks that are sensitive to delay like any real time processing. The node has one to many interfaces. An interface has standardized properties like for example “IntName” (interface name), “IntDescription” (interface description), “IntProtocol” (protocol type) and “Baud” (data rate). Furthermore, all interfaces having the same type have also the same properties (the one already mentioned for our “Interface” class). That is why we added the class “InterfaceType” to our model. A given interface has obviously only one “InterfaceType”. The interface is uniquely identified by an id (“InterfaceID” attribute added) and is provided with an address (MAC address, IP address, etc.). These attributes are added to our Interface class. In addition, the Boolean data property “IsGateway” has also been added to our “Interface” class for indicating if an interface offers the gateway functionality (a gateway interface could be accessed by external servers for managing the WSN or collecting certain data). Each node type can operate in different modes (transmission, sleep, etc.). However, each node can only have one current mode. We thus introduced the object property “InCurrentMode” to our node ontology. This object property can be used for example in energy aware procedure where the sink or server sends data only to nodes in a transmission or a receiving mode. Furthermore, it is obvious that a node in a sleeping mode does not have to be discovered and this information will improve the working process of a dynamic node discovery procedure. More static data for the “Node” class have also been added in MyOntoSens. We can e.g. cite the “Level of Trust” attribute, used for security purposes, and the “Level” attribute, indicating the number of hops between a node and the sink (this new attribute can be used in particular within a multi hop routing procedure). Regarding the “NodeType” properties, we added the wakeup latency for fault management. The wakeup latency is the time required by the sensor to generate a correct value once activated. Clearly, if the sensor reading is performed before the wakeup latency has elapsed, the acquired data is not valid. The “survival” property (already introduced within SSN [7], [8]) has also been included in our model for describing the conditions to which a sensor node can be exposed without

3662

IEEE SENSORS JOURNAL, VOL. 15, NO. 7, JULY 2015

Fig. 4.

Fig. 5.

Constrains classes.

Fig. 6.

Process and data.

NodeType properties.

causing a lasting damage. When this property occurs on a network node, we should consider all data sent from this node as insignificant data and thus turn off this node. The velocity of a mobile sensor (attribute of the “NodeType” class), the energy consumption during its movement (attribute of the “Mode” class), and the maximum distance that this sensor can travel (attribute of the “Node” class) are registered in our MyOntoSens model. These attributes can be useful for data collection procedures in large scale sensor networks. Figure 4 summarizes the semantic properties of the “NodeType” class. Finally, each node is used in a process and it can measure one or more measurements. To ensure an effective inference, we created the inverse data property: the measurement is done by a sensor. C. MyOntoSens Process and Data Ontology The process is the observed phenomenon like temperature, humidity, etc. Influenced from the existing ontologies (OntoSensor [6] & SSN [7], [8]), our Process class has inputs, outputs, description, calibration, drift, latency, unit of measurement, precision and response order attributes. A process measures Data. The Data has a special Format (numeric, image, etc.). The Format class was introduced in our model for interoperability management purposes. It is a generic container used for referencing/importing any external data format into our ontology. The data can also have many constraints as described in Fig.5. The legal and security constraints are reused from SensorML model. A heterogeneous network might handle different types of traffic, each type with its own constraints. It is therefore important to classify the data based on different priorities. For example, if this data is reporting an urgent change in the insulin dose of a patient, it should have the highest priority for reaching the sink as early as possible. We have thus added the QoS property to our data class. Beside the QoS, the data is considered as multicast when it is sent to group of nodes within a cluster and considered as broadcast when it is sent to the entire active nodes in the WSN.

If the remaining lifetime of a node is crucial, it can ignore a broadcast or multicast data to save power. Therefore, the “DataType” attribute (unicast, multicast, broadcast, etc...) has been added to our model. For each Data, we have many measurements characterized by its value, Time to Live (TTL) and Timestamp (to ensure the data freshness). These attributes are also added to our Measurement class. Figure 6 shows the object properties and data properties for the process and data ontology. D. MyOntoSens Description Language Retained The most used and well known language to describe ontologies is Ontology Web Language (OWL) proposed as a standard by W3C’s Web Ontology Working Group in 2004 [15]. Its latest version is OWL 2 published in 2009 [16]. Merely, having an ontology language without reasoning facilities to discover non-intended consequences and inconsistency is pointless. We have thus retained OWL 2 DL (Description Logic) that offers decidability by allowing consistency checking. OWL 2 DL also offers automatic reasoning on the knowledge base using realistic computing resources in a reasonable time. It can also be extended to support Semantic Web Rule language (SWRL) [17]. Being one of the most complete OWL editors, we have chosen Protégé 4.3 that enables users to build and edit classes and properties, to import ontologies, to visualize ontologies in different manners, to access reasoning engines edit and execute queries and rules, to compare ontology versions, and to acquire instances using a configurable Graphical User Interface (GUI) [18].

NACHABE et al.: UNIFIED DATA MODEL FOR WSN

3663

The Pellet reasoner [19] is used as a complete OWL-DL consistency checker and OWL syntax checker. It is thus retained to pre-validate our ontology since it offers the standard set of Description Logic Inference services listed below: • Consistency checker that ensures that our ontology does not contain any conflicting facts. • Verification for each class if it is possible to have instances. • Classification of the ontology and creation of the complete hierarchy. • Realization by finding the most specific classes the individuals belong to. Pellet also supports inverse and transitive properties, cardinality restrictions and data-type reasoning. In the following section, we will detail our proposed ontology while keeping in mind the capabilities of Pellet in checking the DL rules (as type, equality, inverse, subclass).

IV. S IMULATION , VALIDATION AND D ISCUSSION Exercising is becoming primordial in our daily life. Thus, to pre-validate and qualify our ontology, we created an m-health android mobile application for monitoring runner’s exercise parameters (heartbeat, burned calories, speed, etc.). This application is fully designed by relying on our proposed ontology. In this application context, the WSN testing use case consists of WBANs of runners comprising heartbeat (HR) sensors, GPS sensors and mobile phones that play the role of sinks (or Hubs). We have first conducted a symbolic pre-validation of our open data model and ontology. This validation is presented in section A. We then tested and finally pre-qualified our ontology in a real test-bed carrying out the aforementioned WBAN use-case and runner’s parameter monitoring application. The corresponding results are presented in section B, and commented in section C.

E. MyOntoSens Rationale

A. Symbolic Pre-Validation Using Pellet

In Summary, reusing basic attributes of previously proposed solutions (such as SSN [6], [7] and Bluetooth LE profiles [14]) and introducing extended semantic knowledge (compared to already proposed sensor network ontologies) allow the integration of our MyOntoSens ontology with existing technologies and provide a solution for WSNs/sensors data heterogeneity management. In addition, since MyOntoSens also incorporates grounding information of the WSN nodes, it thus facilitates WSNs interworking and interoperability management. Furthermore, dealing with tiny devices pushes us to offer a modular ontology (MyOntoSens) where we can implement some classes on the nodes depending on their computational power. Many scenarios for reasoning implementation could be envisioned based on our ontology and we are only proposing some of these scenarios. Further works are under development in order to find the optimal distribution for different applications. Taking the example of a Wireless Body area Network (WBAN), sensors might not be able to execute the full reasoning process locally. Nevertheless, we introduced the “Measurement” class in a very light manner so that it could be reasoned by the sensor itself. The sink or the cluster head (i.e. WBAN’s hub) can include the metadata related to the cluster and the nodes data. An aggregator can also play the role of the gateway and the context agent responsible of transforming the data about the WBAN, its sensors and the responsible parties into structured information using our proposed ontology. Once the gateway discovers the types of nodes used, an external server (e.g. located in a dedicated private cloud or a remote monitoring and control center) can retrieve all the properties of the “NodeType” and “InterfaceType” classes. Monitoring and control servers could periodically check the reasoning interface on the gateway to enquire about the current state of the network and any incipient or detected faults. The initial validity and qualification tests of our MyOntoSens ontology have been conducted for an m-health application scenario which is detailed in [20]. These initial tests are presented in Section IV.

To pre-validate our ontology, we used Protégé 4.3 and the Pellet reasoner. We have instantiated our case study by presenting two runners: Runner1 and Runner2. We will only detail some individuals created for Runner1. WSN_Runner1 is the individual of type WSN and having as WSNID the Android ID of Runner1’s mobile phone (unique for each user). WSN_Runner1 is formed of two clusters: Runner1_Android and Runner1_Watch. Runner1_Android is composed of Runner1_GPS sensor and Runner1_Mobile as sink. Runner1_Watch is composed of Runner1_ECG_Sensor and also elects Runner1_Mobile as sink. Each sensor is used for a process (location, speed or HR) and does some measurements. The location process has two data: longitude and latitude, both captured by the GPS sensor. The HR data has a validity constraint (maximum value) calculated based on the runner’s age (Eq. 1). The Mobile has “Nexus” as node type, for example, and a processor. The processor’s characteristics are described in our ontology to reflect the processing capabilities of the Sink. After instantiating our ontology, we moved to the pre-validation phase. Three main approaches for qualifying and validating ontology exist: evolution-based validation, symbolic-based validation and attribute-based validation [21]. In the context of our paper, the first approach cannot be used because it is mandatory to test our ontology before its usage. Since we are still working on validating our ontology based on the third approach (i.e. attribute-based), we will only be focusing on the symbolic-based validation approach for this paper. This approach is a rule-based evaluation. On the one hand, we test the rules coming from the ontology itself by using a reasoner. On the other hand, we test the rules coming from the user domain as, for example: only accept values of a certain process that belong to the valid range. Pellet reasoner was used in order to check the consistency of our ontology and to create its complete hierarchy. Some tested examples coming from the ontology itself are presented below: • Functional data property: uniqueness of a WSN by defining the WSNID as Functional. So, when creating

3664

IEEE SENSORS JOURNAL, VOL. 15, NO. 7, JULY 2015

two WSNIDs for the same WSN, the reasoner will generate an inconsistency error. • Maximum Cardinality: a measurement can be done by maximum one sensor. So, when assigning two different sensors to the same measurement, an inconsistency error is generated. • Inverse Property: by asserting that Runner1_Android “belongTo” WSN_Runner1, Pellet inferred that WSN_Runner1 “isFormedof” Runner1_Android. • SubClass Of: by defining the object property “hasConstraint” between Data and Constraint classes, and by having Validity subclass of Constraint, we can assign a validity constraint between Data and Validity classes. Then, we moved to the definition of SWRL rules coming from the application domain. We first started by adding the rules applicable for all WSNs. For example, Rule 1 confirms that if two clusters are electing the same Sink, they should belong to the same WSN.

Fig. 7.

Runner1_Watch inferred object properties.

WSN(?W), ElectSink(?C, ?S), ElectSink(?C1, ?S), isFormedOf(?W, ?C) ->belongTo(?C1, ?W) (Rule 1) In addition, when a node measures some measurements related to a certain process, the server should infer that this node is used for this process. This inference could be deduced by adding Rule2 as follow:

Fig. 8.

Runner1_ECG_Sensor inferred object properties.

Node(?N), measures(?N, ?M), hasData(?P, ?D), hasMesurement(?D, ?M) ->usedFor(?N, ?P) (Rule 2) Furthermore, we created SWRL rules related to our special m-health application. We can cite here Rule 3 which calculates the maximum HR for the runner as defined in Eq.1 [22]. maxi mum H R = 208 − (Age ∗ 0.7)

(1)

Afterwards, we have defined a validity constraint for the HR data where the maximum value is calculated using Rule 3: WSN(?W), composedOf(?C, ?N), hasData(ECG, ?D), hasContact(?W, ?P), isFormedOf(?W, ?C), hasConstraint(?D, ?V), usedFor(?N, ECG), Age(?P, ?age), multiply(?y, ?age, 0.7), subtract(?x, 208, ?y) ->MaxValue(?V, ?x) (Rule 3) Finally, in order to register the location of the runner, the server will infer the runner’s location from the GPS sensor of the mobile. Rule 4 will infer the runner’s location form the GPS measurements: the same rule is also defined in order to deduce the latitude of the runner. WSN(?W), composedOf(?C, ?S), measures(?S, ?M), hasData(Location, Longtitude), hasMesurement(Longtitude, ?M), isFormedOf(?W, ?C), hasLongtitude(?W, ?Q), usedFor(?S, Location), value(?M, ?x) ->hasvalue(?Q, ?x) (Rule 4) Other rules can be added to enhance the inference model. Each developer can add SWRL rules related to his application domain in order to retrieve new knowledge from the basic ontology information. Figures 7, 8 and 9 depict some inferred object properties and data type properties that were obtained using Pellet reasoner.

Fig. 9.

Maximum heart rate value inferred from the age of the runner.

Verifying that our ontology does not contain any infinite loops or contradictions, and asserting that all inferred data are accurate and well classified, allow us to pass to the real implementation of the proposed m-health application. B. Implementation of the Ontology Driven Mobile Application To test our ontology in a real environment, we developed an Android application that receives the heartbeat of the runner from H7 Polar sensor [23] via Bluetooth LE interface. Figure 10 shows the general architecture of our testing environment, and Fig. 11 depicts the general architecture of our m-health application. The Jena API [24] is used on the server side to create individuals and infer the entire model. The AndroJena [25], dedicated for Android mobile phone, helped us to create individuals on the mobile side and retrieve the inferred schema. Once the runner downloads the application, he will be authenticated using the Google plus API. The mobile willthen send its MAC address (used to identify the runne’s WSN), the user’s Gmail account (used to identif the Contact) the use’s age, the user’s gender and the user’s weight (used as data properties of the Contact class) to the semantic server

NACHABE et al.: UNIFIED DATA MODEL FOR WSN

3665

W = Weight (in kilograms) A = Age (in years) T = Exercise duration time (in hours) The user can also discover the nearby runners and check the history of his activities. For the discovery of neighboring runners, the following SWRL query (Query 1) has been carried out:

Fig. 10.

SELECT ?Contact WHERE { ?WSN w:hasContact f:Runner1. ?WSN f:hasLatitude ?lat. ?WSN f:hasLongtitude ?long. ?lat rdf:type w:Quantity; p:hasvalue ?Runner1_lat. ?long rdf:type w:Quantity;p:hasvalue ?Runner1_long. ?WSN1 w:hasContact ?Contact. ?WSN1 w:isFormedOf ?Cluster. ?Cluster n:composedOf ?N. ?N n:inCurrentMode f:Active.?WSN1 f:hasLatitude ?lat1. ?lat1 rdf:type w:Quantity; p:hasvalue ?val1. ?WSN1 f:hasLongtitude ?long1. ?long1 rdf:type w:Quantity; p:hasvalue ?val2. Filter ( ( (?Runner1_lat - ?val1)∗ (?Runner1_lat - ?val1) + (?Runner1_long - ?val2) ∗ (?Runner1_long - ?val2) ) >0.05) } (Query 1)

General architecture of the testing environment.

If the HR exceeds the maximum range, the user will receive a notification in order to reduce his speed. We tested our application on many users equipped with an H7 Polar sensor and having Android mobiles supporting Kitkat version in order to be able to use the embedded Bluetooth LE interface. The automatic node discovery on the server side was successfully accomplished. The neighbors were detected due to the use of SPARQL query. Fig. 11.

General architecture of the m-health application.

C. Discussions

(e.g. remote control and monitoring center) via 3G interface. These user related data are transferred via JSON format [26] because of its lightness in processing and its non-intensive bandwidth utilization. Therefore, the Server will create a new WSN: • Having as contact the user. • And made of the Mobile Cluster comprising the GPS sensor built in the mobile. When the user turns on the H7 Polar, the mobile detects its presence and informs the server that a new cluster has been created and has elected the mobile as Sink. The user can now start a new task. During exercises, the HR data, the burned calories and the attempted distance are displayed in real time. The burned calories are calculated based on Eq 2.1 and Eq. 2.2 [18] as follow: Calori es bur ned For Male = ((−55.06309 + (0.6309 ∗ H R) + (0.1988 ∗ W ) + (0.2017 ∗ A))/4.184 ∗ 60 ∗ T. (2.1) Calori es bur ned For Female = ((−20.4022 + (0.4472 ∗ H R) − (0.1263 ∗ W ) + (0.074 ∗ A))/4.184) ∗ 60 ∗ T Where HR = Heart rate (in beats/minutes)

(2.2)

The proposed m-health application demonstrates the compatibility of our ontology with Bluetooth LE GATT profiles that were just directly mapped into this ontology. This application is thus able to accept any other Bluetooth LE enabled sensor, from any vendor, without any reprogramming (thanks to our MyOntoSens ontology). Furthermore, the “Format” class that is introduced in our model can be linked to any external data format. In that way, vendors and developers that will carry out their own applications and services based on our ontology will make them interoperable with any data types. Due to the use of: • Extended semantic attributes of MyOntoSens ontology (in particular “CurrentMode” and “Location”), • Additional object properties (in particular “isFormedOf” and “hasContact”) and rules added within our data model, • And SPARQL rules and queries (refer to Section 4B), we were able to provide automatic sensor discovery, as well as automatic neighboring WBANs discovery within both our remote monitoring/control server (semantic central depicted in Fig.10) and our mobile application. Integrating semantic sensor data into the web, due to the use of IRI, alleviated the reusability of data by different applications [24]. In our proposed model, the WSNID, the ClusterID, the NodeID, the ProcessID and the InterfaceID are defined as “anyURI”, which means that we are also giving

3666

IEEE SENSORS JOURNAL, VOL. 15, NO. 7, JULY 2015

an IRI to all of them for providing a shared access to the associated information through the web (via e.g. SPARQL queries). Taking the example of biomedical data, it is essential for different medical applications and servers to share data in order to detect severe diseases or anomalies. Moreover, it is useful for a patient if services and applications share the same data, thus eliminating the need to fill redundant information about the patient. Our tests also pointed out that being able to define a generic ontology covering the most important features of WSNs not only provides a solution for interoperability and heterogeneity management, but allows the reduction of the power consumption of the WSN. Indeed, we are only sending few data to the remote monitoring and control server due to the carrying out of local data processing operations directly within the sinks. This was feasible thanks to both the extended semantic knowledge introduced by our ontology within the sinks (i.e. the mobile phones in our use case) and the use of simplified SWRL rules and inference engines on that local semantic knowledge. These simplified inference operations were performed without any noticeable extra energy consumption. As an illustration, once the H7 Polar is on, the mobile only sends that “H7 Polar is in active mode”, with its MAC address. On the server side, the creation of H7 Polar as cluster electing the user’s mobile as sink automatically infer the fact that this sensor belongs to this user (runner). Moreover, creating the object property describing that the sensor has H7 Polar as “NodeType”, permits the retrieval of all node’s characteristics (processor, interfaces, energy source, etc.). In addition, using SWRL rules and thanks to SPARQL query, the mobile can retrieve the burned calories with minimum processing. Finally, we are using JSON instead of an XML-based protocol to exchange data between the sink (i.e. the mobile phone in our use case) and the server (i.e. the semantic central in our case), which reduces the bandwidth usage. Indeed, JSON has simpler information modeling and message structures than XML-based mechanisms. Furthermore, JSON is also low processing oriented, which makes it better adapted to devices with limited capabilities such as e.g. cluster sinks or sensors. V. C ONCLUSION AND F UTURE W ORK In this paper, we have proposed a new semantic open data model and ontology, named MyOntoSens (its full specification and formalization, as well as the corresponding owl files, within the framework of WBANs can be downloaded from [27]), which generically describes any kind of components of these sensor networks. As pre-validation use case, we took the example of a running exercise application that calculates the burned calories during a defined task and alerts the runner if he exceeds certain speed or if his HR exceeds the maximum threshold. In addition, our application can inform the runner about the nearby WBANs and runners. Each runner was equipped with a smart heart-rate sensor, a smartphone as data aggregator and sink, and a GPS sensor for location tracking and speed calculation (in order to deduce the burned calories).

To ensure syntax checking and consistency checking, Pellet reasoner was used. Within Pellet, all the inferred properties were deduced and our ontology was well classified, which confirms its validity. MyOntoSens was then qualified in a real environment comprising an H7 Polar heart-rate sensor and an Android mobile phone provided with a GPS sensor. Our running exercise and control application was fully implemented based on MyOntoSens and installed on the Android mobile phones of runners. The tests that were performed in this environment show the interoperability of MyOntoSens with Bluetooth LE GATT profiles and also prove that the use of inference engine on MyOntoSens in our m-health application reduces the Smartphone’s battery usage. However, more work need to be conducted to finalize the validation of our ontology and to study its scale up, in particular by investigating more complex test scenarios. Evaluation methods based on metrics could also be used to measure the knowledge level provided by MyOntoSens through the use of quantitative metrics. We are actually both creating more complex scenarios such as Smart Home to evaluate the efficiency of MyOntoSens, and constructing extended service ontology in order to offer an effective WSN management and data collection and aggregation. This upper ontology will use the properties described in MyOntoSens ontology in order to ease the implementation of end user services. R EFERENCES [1] S. Taruna, K. Jain, and G. N. Purohit, “Application domain of wireless sensor network:—A paradigm in developed and developing countries,” Int. J. Comput. Sci. Issues, vol. 8, no. 4, p. 611, Jul. 2011. [2] T. H. Kim and S. Hong, “Sensor network management protocol for statedriven execution environment,” in Proc. ICUC, Oct. 2003, pp. 197–199. [3] T. Bittner, M. Donnelly, and S. Winter, Ontology and Semantic Interoperability Large-Scale 3D Data Integration. London, U.K.: CRC Press, 2005. [4] M. Compton, C. A. Henson, L. Lefort, H. Neuhaus, and A. P. Sheth, “A survey of the semantic specification of sensors,” in Proc. CEUR Workshop, 522, 2009, pp. 17–32. [5] R. Bendadouche, C. Roussey, G. De Sousa, J.-P. Chanet, and K. M. Hou, “Extension of the semantic sensor network ontology for wireless sensor networks: The stimulus-WSNnode-communication pattern,” in Proc. 11th Int. Semantic Web Conf., Boston, MA, USA, Nov. 2012, pp. 11–15. [6] D. J. Russomanno, C. R. Kothari, and O. A. Thomas, “Building a sensor ontology: A practical approach leveraging ISO and OGC models,” in Proc. Int. Conf. Artif. Intell., Las Vegas, NV, USA, 2005, pp. 637–643. [7] H. Neuhaus and M. Compton, “The semantic sensor network ontology: A generic language to describe sensor assets,” in Proc. AGILE Workshop, Challenges Geospatial Data Harmonization, 2009, pp. 1–33. [8] L. Lefort, C. Henson, and K. Taylor, “Semantic sensor network XG final report,” W3C Incubator Group, Tech. Rep. 28, Jun. 2011. [9] R. Bendadouche, C. Roussey, G. De Sousa, J. P. Chanet, and K. M. Hou, “Extension of the semantic sensor network ontology for wireless sensor networks: The stimulus-WSNnode-communication pattern,” in Proc. 11th Int. Semantic Web Conf., Boston, MA, USA, Nov. 2012, pp. 22–48. [10] S. Nikoli´c, V. Penca, M. Segedinac, and Z. konjovi´c, “Semantic web based architecture for managing hardware heterogeneity in wireless sensor network,” Int. J. Comput. Sci. Issues, vol. 8, no. 2, pp. 38–58, Jul. 2011. [11] R. D. Eastman, C. I. Schlenoff, S. B. Balakirsky, and T. H. Hong, “A sensor ontology literature review,” Intell. Syst. Division, NIST, Gaithersburg, MD, USA, Tech. Rep. NIST7908, Apr. 2013. [12] ETSI TC SmartBAN, Smart Body Area Networks (SmartBAN); SmartBAN Unified Data Representation Formats, Semantic and Open Data Model, document Rec. DTS/SmartBAN-009V1.0.0, Nov. 2014.

NACHABE et al.: UNIFIED DATA MODEL FOR WSN

[13] R. Hodgson, P. Keller, J. Hodges, and J. Spivak. QUDT—Quantities, Units, Dimensions and Data Types Ontologies. [Online]. Available: http://qudt.org/, accessed Mar. 18, 2014. [14] Bluetooth Developer Portal. [Online]. Available: http://developer. bluetooth.org, accessed Jun. 2014. [15] D. L. McGuinness and F. van Harmelen, “OWL web ontology language overview,” W3C Recommendation 10, Feb. 2004. [16] B. Motik, P. F. Patel-Schneider, and B. Parsia, “OWL 2 web ontology language: Structural specification and functional-style syntax,” W3C Recommendation 11, Sep. 2009. [17] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, and M. Dean, “SWRL: A semantic web rule language combining OWL and RuleML,” W3C Member Submission 21, May 2004. [18] H. Knublauch et al., “The Protégé OWL experience,” in Proc. OWLED, vol. 188. Nov. 2005, pp. 14–25. [Online]. Available: http://ceur-ws.org [19] E. Sirin and B. Parsia, “Pellet: An OWL-DL reasoner,” in Proc. Int. Semantic Web Conf. (ISWC), Japan, 2004. [Online]. Available: http://www.mindswap.org/2003/pellet [20] L. Nachabé, M. Girod-Genet, B. El-Hassan, and F. Aro, “Applying ontology to WBAN for mobile application in the context of sport exercises,” in Proc. 9th Int. Conf. Body Area Netw. (BodyNets), London, U.K., Sep./Oct. 2014, pp. 204–209. [21] S. Tartir, I. B. Arpinar, and A. P. Sheth, “Ontological evaluation and validation,” in Theory and Applications of Ontology: Computer Applications. Amsterdam, The Netherlands: Springer-Verlag, 2010, pp. 115–130. [22] D. P. Swain, K. S. Abernathy, C. S. Smith, S. J. Lee, and S. A. Bunn, “Target heart rates for the development of cardiorespiratory fitness,” Med. Sci. Sports Exerc., vol. 26, no. 1, pp. 112–116, Jan. 1994. [23] H7 Heart Rate Sensor Polar Global. [Online]. Available: http://www. polar.com/en/products/accessories/H7_heart_rate_sensor, accessed May 31, 2014. [24] Jena Ontology API. [Online]. Available: http://jena.apache.org/ documentation/ontology/, accessed May 31, 2014. [25] Apache Jena on Android. [Online]. Available: http://elite.polito.it/ jena-on-android, accessed May 31, 2014. [26] Introducing JSON. [Online]. Available: http://json.org, accessed Jun. 15, 2014. [27] ETSI TC SmartBAN. [Online]. Available: http://portal.etsi.org/portal/ server.pt/community/SmartBAN/368, accessed Mar. 2014.

Lina Nachabe received the Diploma degree in engineering from the Faculty of Engineering, Lebanese University, Beirut, Lebanon, in 2007. She is currently pursuing the Ph.D. degree at the RS2M Department, Telecom Sud Paris, Evry, France. Since 2009, she has been teaching database and networking courses in Lebanese universities. She is actually a Telecom Laboratory Assistant with the Faculty of Engineering, Lebanese University. She supervised engineering project with the Al-Manar University of Tripoli, Tripoli, Lebanon. She is contributing in the ETSI Technical Committee SmartBAN, Work Item 1 Heterogeneity Management, Data Representation and Transfer as part of her Ph.D. study. She is interested in wireless sensor networks and ontology researches.

3667

Marc Girod-Genet received the Engineering (Hons.) (top in one’s year) degree in telecommunications and advanced techniques from the EPITA Engineering School, Paris, France, in 1994, the M.S. degree in computer science from the Stevens Institute of Technology, Hoboken, NJ, USA, in 1995, and the Ph.D. (Hons.) degree in computer science from the University of Versailles/Paris VI, Versailles, France, in 2000. He joined Telecom SudParis, Evry, France, first as a Research Project Manager, in 2000, and then was confirmed as a Full Associate Professor in 2005. He teaches courses in personal communications, short-range wireless technologies, service and context management architectures, optimization/modeling, and machine learning. He is also an Associate Researcher with the French National Centre for Scientific Research (network intelligence field; UMR 5157 SAMOVAR Research Unit of Télécom SudParis), Evry, where he works on several national and European research projects. He is involved in the ETSI Technical Committee SmartBAN, where he serves as a Reporter of Work Item 1 Heterogeneity Management, Data Representation and Transfer. He is a Technical Program Committee Member of the IEEE conferences, and a reviewer for conferences and journals, such as the IEEE Communications Magazine and the IEEE T RANSACTIONS ON W IRELESS C OMMUNICATIONS. He has been involved in organizing international conferences, symposia, and events, such as the Globecom Wireless Communication Symposium and the ASWN Workshop. He was a recipient of the two awards, such as the ITEA2 Achievement Award (Silver Medal) for the CAM4Home EU project and the ADEME Special Award Prix de la Croissance Verte Numérique (digital green growth) for his joint work on Smart Grids with two of his colleagues in 2010.

Bachar El Hassan received the Diploma degree in engineering from the Faculty of Engineering, Lebanese University, Beirut, Lebanon, in 1991, the M.S. degree in signal processing from the National Polytechnic Institute of Grenoble (INPG), Grenoble, France, in 1992, and the Ph.D. degree in electronics from INPG in collaboration with France Telecom, Paris, France, in 1995. Since 1996, he has been with the Faculty of Engineering, Lebanese University, where he is currently an Associate Professor. He served as the Chairman of the Department of Electrical Engineering for six years. He founded the Telecommunications and Networking Research Team at the Laboratory of Electronics Systems, Telecommunication and Networking, Doctoral School of Sciences and Technologies, Lebanese University. His research interests concern digital communication and wireless sensor networks. He has been the Chair of the IEEE ComSoc Lebanon Chapter since 2013.