Semantic Open USN Service Platform Architecture

Dong-Hwan Park USN/IoT Research Department

ETRI Daejeon, Korea

dhpark@etri.re.kr

Sun-Jin Kim USN/IoT Research Department

ETRI Daejeon, Korea

sunjin@etri.re.kr

Hyo-Chan Bang USN/IoT Research Department

ETRI Daejeon, Korea bangs@etri.re.kr

Abstract�This paper proposes an open software platform architecture to provide semantic information collected from various sensor networks and sensing devices. Semantically expressed sensing information and metadata of sensing devices can improve reusability of sensing data, therefore general consumers as well as the restricted user can observe, monitor and analyze sensing values from pre-installed sensing devices.

Keywords— Open USN, Semantic, Service Platform

I. INTRODUCTION Depending on the rapid adoption of smartphones and

mobile devices, we become able to enjoy a 'mobile life' that can be connecting internet anywhere and anytime. Most smartphones have built in a variety of sensors-ambient light sensor, proximity sensor, global positioning system, accelerometer, compass, and gyroscopic sensor. These sensors can help to make various smarter apps such as interactive games, healthcare apps, educational contents and augmented reality applications. Recently, Japanese carrier announced smartphones include customized IC chips that measure radiation levels in micro Sieverts per hour, and the solar radiation awareness smartphone measures the UV radiation using a wireless sensing unit[1].

Likewise, a lot of sensors and applications are developing in order to meet the need of consumer who wants to know and share environmental information surrounding them. USN (Ubiquitous sensor network) is one of rising technologies in IT convergence domain. USN is a core technology in environmental monitoring such as air/water quality, radiation and traffic noise. Useful information gathered from sensor network is become to information silo because of USNs are operating tightly coupled with sensor application until now. Sensor data representation formats in these sensor networks are various, and cannot understand the meaning of sensing value in other applications. Therefore, sensing values and information must be shared and provided additional information for other applications.

To meet these requirements, this paper proposes the open USN service platform architecture that guarantees the semantic interoperability of sensors’ information and the share of sensor resources. The proposed architecture allows sensor information portal service providers and general developers to develop more useful applications and services easily.

II. RELATED WORKS

A. COSMOS A COSMOS (Common System for Middleware of Sensor

Networks) is a common sensor network middleware platform over heterogeneous USN (Ubiquitous Sensor Network) for USN service applications [2]. The COSMOS provides various functionalities for sensor network service applications. Main functionalities are sensor network abstraction using sensor network common interface, query optimization, integration of data from various sensors, sensor network monitoring, and intelligent sensor data processing such as event handling and sensor data mining [3]. Wired and wireless sensor network connect to COSMOS middleware platform using a sensor network adaptor. Each sensor network adaptor must implement a sensor network abstraction protocol called the sensor network common interface that is proposed as an interface protocol between a sensor network middleware and sensor network field applications in COSMOS middleware platform.

The COSMOS operates like a sensor database that contains various sensing values of multiple sensor networks conceptually. It provides an SQL-like query to gather sensing values in sensor network applications. The query processor and optimizer performs the aggregation and filtering of sensing value stream data, and provides user-friendly SQL-like query to service API. The sensor network directory service provides the static metadata and dynamic metadata of sensor network components – sensor networks, sensor nodes, transducers, and related hardware specifications based on sensor network physical configuration. The sensor network dynamic metadata are the link quality between nodes, parent node’s id, node’s battery level, node’s location and so on. The sensor network monitor monitors variable state or values of sensor networks connected to middleware (COSMOS) and it updates these dynamic metadata using sensor network directory service’s API.

B. Sensor Web Enablement The OGC SWE(Sensor Web Enablement) standards are

based on XML and enable the Web-based discovery, exchange, and processing of sensor observations, as well as the tasking of sensor systems[4]. The OGC SWE supports the main functionalities as following as:

This work was supported by the Industrial Strategic Technology Development Program funded by the Ministry of Knowledge Economy (MKEKorea) [10038653, Development of Semantic Open USN Service Platform]

12978-1-4673-4828-7/12/$31.00 ©20122 IEEE ICTC 2012

� Discovery of sensor systems, observations, and observation processes that meet an application or users immediate needs

� Determination of a sensor’s capabilities and quality of measurements

� Access to sensor parameters that automatically allow software to process and geolocate observations

� Retrieval of real-time or time-series observations and coverage in standard encodings

� Tasking of sensors to acquire observations of interest � Subscription to and publishing of alerts to be issued by

sensors or sensor services based upon certain criteria

III. ARCHITECTURE AND FUNCTIONS OF SEMANTIC BASED OPEN USN SERVICE PLATFORM

In the open USN service framework including the proposed platform, there are four main elements – applications, the proposed platform, USN middleware such as COSMOS or SWE, and sensor or sensor networks. In this framework, applications utilize the sensed data, sensor networks and sensor attached devices produce sensed. The proposed platform provides functions for unified access to sensor network resources and sensed data through heterogeneous sensor network middleware and SWE to satisfy application service requests. Figure 1 shows the architecture of open sensor network service framework and there are 7 functional entities in the proposed platform.

Figure 1. Semantic Open Sensor Network Service Platform Architecture

A. Semantic Query Engine Semantic Query Engine performs the functions to generate

and handle middleware query and SPARQL (SPARQL Protocol and RDF Query Language) query for providing

responses to applications' information requests. It consists of service-level query analyzer, middleware query processor and SPARQL query processor. The service-level query analyzer provides the functions to create queries by analyzing intention of applications' requests, to translate the result of query process according to applications' message specifications, and to deliver the translated data to applications. It classifies request from applications into middleware query and SPARQL query. The middleware query, which requests the sensed data from sensor network middleware, is created according to APIs that sensor network middleware provides. The SPARQL query, which requests the sensor network resources and sensed data from the Semantic Sensor Information Repository, is created by translating queries that applications request into SPARQL.

The middleware query processor performs the functions to send middleware queries to sensor network middleware, and to collect the resulted data from sensor network middleware. It provides the functions to manage query status about lots of middleware queries created from the query analyzer, and to deliver the data received from sensor network middleware to the Semantic Sensor Information Repository or the query analyzer. The SPARQL query processor performs the functions to handle simultaneously lots of SPARQL queries created from the query analyzer, and to produce the results of queries from the Semantic Sensor Information Repository, and to deliver them the query analyzer.

B. Semantic Sensor Information Repository Semantic Sensor Information Repository translates SensorML of OGC (Open Geospatial Consortium) to RDF (Resource Description Framework) of triple of sensing value and related information such as metadata and specification. Figure 2 shows the USN resource ontology that contains specifications of various USN resources in USN middleware and real-time sensing data. The USN resource is an entity which provides USN service including sensor, actuator, sensor node, sensor network and gateway.

Figure 2. USN Resource Ontology

13

Semantic Sensor Information Repository stores the semantically expressed RDF data of sensor network resources and sensed data collected from sensor network middleware for a certain period of time as a physical repository. Also, it provides API functions to query for inserting new data, searching, querying, and deleting stored data following SPARQL specification.

C. Sensor Network Resource Management Sensor Network Resource Management provides the

functions to issue and manage the identifier and URI of sensor network resource, and to manage mapping relations with the address of sensor network resource. Also, it supports the functions which enable sensor network resource to be automatically registered in the proposed platform when sensor network resource is connected in the network, and applications to obtain and utilize information about sensor network resource. It performs the functions which enable sensor network resource to actively register its own status and connection information. It provides the functions to search identifiers of sensor network resources for performing queries which can provide necessary information for requests from applications. In some cases, it can provide the functions to configure and manage a logical group on sensor network resources for satisfying applications' service request. It may perform the functions to create a resource group and to manage the list of sensor network resources which belong to the resource group. Also, it provides the functions to manage the lifecycle of each resource group because there is a lifecycle of the resource group according to the duration of service.

D. Adaptors It provides the functions which handle the protocol and

message for setting connection with sensor network middleware and delivering queries and commands as a kind of interface for processing several types of data generated from heterogeneous sensor network middleware into the proposed platform.

E. Open API OpenAPI provides the functions which enable sensor

network application to obtain open sensor network services and/or the sensed data from the proposed platform. It also provides some useful SensorQL (Sensor Query Language) like SQL statement and sensor data push mechanism.

F. LOD It provides the functions which enable users to access the

sensor network resources and sensed data in the world by opening the sensor network resources and sensed data generated from the proposed platform to the LOD, and to provide links between external LOD data and the sensor network resources and sensed data from the proposed platform. Also, it supports the interface for query about the sensor

network resources and sensed data in the LOD.

G. Semantic Inference It provides the inference functions based on the information

described in the ontology schema and users' rules by using lots of RDF data stored in the Semantic Sensor Information Repository. Through these functions, the original data are processed into more semantic data such as context data. The inferred data are updated into the Semantic Sensor Information Repository and utilized in other services. Maintaining the Integrity of the Specifications

IV. INFORMATION FLOWS

A. Sensing Information Flow from USN Resource Figure 3 shows the information flows describing how to

access sensed data directly from USN resources in real-time.

Figure 3. Sensing Information Flow from USN Resource

1. Applications request the sensing data to the proposed platform through OpenAPI interface.

2. The OpenAPI interface sends a request message to the Semantic Query Engine.

3. The Semantic Query Engine requests the identifiers of USN resources to Sensor Network Resource Manager and receives the ids as response message.

4. The Semantic Query Engine queries the sensing data to corresponding USN resources via USN Middleware or SWE.

5. The Semantic Query Engine receives the sensing data from corresponding USN resources.

6. The Semantic Query Engine sends the sensed data to the OpenAPI.

14

7. The OpenAPI sends the sensed data to the Applications.

B. Sensing Information Flow from Semantic Sensor Information Repository Figure 4 shows the information flows describing how to

access sensed data and inference information stored in Semantic Sensor Information Repository.

Figure 4. Sensing Information Flow from Semantic Sensor Information

Repository

1. The sensing data from USN resources are periodically or continuously stored in the Semantic Sensor Information Repository.

2. Applications request the sensed data and inference information to the proposed platform through the OpenAPI or LOD SPARQL Endpoint.

3. The OpenAPI or LOD SPARQL Endpoint sends a request message to the Semantic Query Engine.

4. The Semantic Query Engine requests the identifiers

of USN resources to Sensor Network Resource Manager and receives the ids as response message.

5. The Semantic Query Engine queries the sensed data to corresponding USN resources, or valuable inference information.

6. The Semantic Sensor Information Repository sends response message such as sensed data or inference information to the Semantic Query Engine

7. The Semantic Query Engine sends the sensed data or inference information in USN resource and event ontology to the OpenAPI or LOD SPARQL Endpoint.

8. The OpenAPI and LOD SPARQL Endpoint sends the sensed data or inference information to the Applications

V. CONCLUSION The proposed semantic open USN service platform

architecture is supporting semantic expression and interoperability of sensing value and related information, and we can share semantic sensor information in other sensor applications. To verify the practicality of the proposed architecture, a prototype of the proposed architecture has been implemented using Ontobase RDF repository and light-weight COSMOS. And some USN related business companies are developing useful open USN service prototypes using the proposed platform prototype.

REFERENCES [1] T. Fahrni, M. Kuhn, P. Sommer, R.Wattenhofer, and S. Welten,

“Sundroid: Solar Radiation Awareness with Smartphones,” Ubicomp'11, pp.365-374.

[2] Marie Kim, Jun Wook Lee, Yong Joon Lee, and Jae-Cheol Ryou, “COSMOS: A Middleware for Integrated Data Processing over Heterogeneous Sensor Networks”, ETRI Journal, Volume 30, Number 5, October 2008, p696-706.

[3] T.H.H. Vu et al., “Spatiotemporal Pattern Mining Technique for Location-Based Service System,” ETRI Journal, vol. 30, no. 3, June 2008, pp.421-431.

[4] Mike Botts et al., “OGC Sensor Web Enablement: Overview and High Level Architecture (OGC 07-165), “ Open Geospatial Consortium white paper, 28 Dec. 2007.

15