SAIL: A Sensor Abstraction and Integration Layer ... - Semantic Scholar

34th Euromicro Conference Software Engineering and Advanced Applications

SAIL: a Sensor Abstraction and Integration Layer for Context Awareness Michele Girolami1 , Stefano Lenzi1, Francesco Furfari1, Stefano Chessa1,21 1 ISTI – CNR, via Moruzzi 1, 56100 Pisa, Italy 2 Department of Computer Science, University of Pisa, Largo Pontecorvo 3, 56127 Pisa, Italy {stefano.chessa, francesco.furfari, michele.girolami, stefano.lenzi}@isti.cnr.it physiological/emotional data, user actions/movements, user identity, status of the surrounding environment, location, time, profiles, agendas and data referable to the user and even presence and context of other users [3]. Context aware systems are particularly useful to support mobile applications since the context may change rapidly with mobility (of the user and/or of the environment), and the system should react rapidly to such context changes. A conceptual architecture of a context aware system (appeared in [6]), includes several layers for detecting and using the acquired context information, in particular: sensors, raw data retrieval, preprocessing, storage/management, and an application layer. The sensor layer includes both the hardware sensors (physical sensors), virtual sensors (that provide information extracted from applications or services, and logical sensors which combine information obtained from physical and virtual sensors. The raw data retrieval layer is responsible of the low level management of the sensors, by providing drivers for physical sensor access. This layer provides an abstraction of the sensor layer by offering more general primitives to access context information. The preprocessing layer combines and preprocess data coming from several sensors to give aggregated context information to the upper layer programmers and to solve conflicts among data provided by different sensors. The storage and management layer organizes the gathered data in a repository accessible to the client applications. At this level the clients can request for context data by synchronous and asynchronous services. The application layer defines the application goals by implementing the reactions to the context information acquired from the underlying levels. In this paper we present a layered architecture, called SAIL (Sensor Abstraction and Integration Layer), that focuses on the raw data retrieval in a context aware architecture. SAIL aims at the

Abstract Wireless Sensor Networks (WSN) are an important technological support for ambient assisted applications. Up to now most WSN applications are based on ad hoc solutions, and attempts to provide reusable applications are still in their youth. Under this trend of research we propose a layered architecture called SAIL (Sensor Abstraction and Integration Layers) to be used in context aware architectures, and aimed at integrating WSN as context information sources. In the proposed approach, the applications running on WSN can be exposed using either a node centric or a data centric paradigm, and they are interfaced with different access technologies. SAIL is currently encapsulated within the OSGi framework and has been tested on MICAz motes.

1. Introduction Smart environments unobtrusively assist people by predicting their needs. This prediction is often based on information implicitly acquired from the users, from their behavior and from the environment. To this purpose they exploit wireless sensor networks [1] placed into indoor or outdoor areas, or on the users themselves. The interpretation and management of sensor data is offered to the applications through middleware encapsulating context aware engines, which mask the sensors to offer higher level services. The first efforts to introduce context awareness have been related to the localization of users [2]. Localization is still one of the main building blocks of context aware systems, although recently the concept of context awareness has been enriched to take into account more general environmental parameters, where the meaning of the term "environmental" is as broad as possible. Environmental parameters may refer to user 1

Work funded in part by the EU FP6 projects PERSONA (contract N. 045459) and INTERMEDIA (contract N.38419).

978-0-7695-3276-9/08 $25.00 © 2008 IEEE DOI 10.1109/SEAA.2008.30

374

Authorized licensed use limited to: Chungnam National University. Downloaded on March 24,2010 at 23:17:03 EDT from IEEE Xplore. Restrictions apply.

metadata describing the dependencies with other bundles. The main features of the OSGi platform are: • a service model where every application component can be registered as service into a Service Registry; • an execution environment where multiple applications can run on the same JVM; • a set of API for control the component life cycle; • a secure environment where multiple applications can not harm themselves or the platform; • a cooperative model where application components can discover others components in the same platform or hosted by remote platforms. All the cited features meet the requirements of the Smart Environment (presented in section 2.1) and of SAIL architecture, thus making OSGi a natural choice. OSGi has also been adopted in different context aware applications as infrastructure for Smart Environments. In [10] the authors show how the OSGi framework meets the requirements for pervasive computing spaces, by providing an extensible framework connecting various devices, and by defining an execution environment which allows the dynamic discovery of devices and services.

integration of wireless sensor networks in different context aware systems, easing the sensor interaction and the sensor access.

2. Preliminary concepts 2.1. Smart Environments challenges The constraints on WSN combined with Smart Environments applications introduce several unique challenges that can be summarized as follows. Integration of different WSN technologies: Smart Environment may be populated by different network technologies used in different application domains like Home Automation, Digital Entertainment or Personal Healthcare Systems. As a concrete example we can consider ZigBee or Bluetooth. Management of different applications on the same WSN: The WSN may support simultaneously different applications, for example user localization, posture detection of users, monitoring of energy consumption of appliances, etc. Dynamic discovery of sensor applications: because of the innate dynamism of users’ activities, such applications may starts or stops arbitrary in according to the user behavior. Management of logical sensors: the physical sensors deployed either in the environment or worn by the users could be represented (virtualised) by a dissimilar number of logical sensors. For example consider an application that detects the user’s posture by means of a number of accelerometers placed on the body: in this case the posture can be represented by a single logical sensor that aggregates information produced by all the accelerometers to produce the state of the user (sitting, walking, etc.). In this case the accelerometers may not even be visible to the application layer; Configuration of WSN applications: many sensor applications need to be configured during the deployment phase for example to bound the user’s metadata to the sensor used to co-locate a person. The next section describes some existing works that try to answer to the listed challenges.

2.3. Wireless Sensor Networks paradigms An early attempt to provide an unifying organization of WSN is the Directed Diffusion paradigm [4] in which the WSN is controlled by a special sensor node (called sink) which acts as network entry point. This first effort has evolved into proposals combining database technology with WSN such as [5]. These approaches (e.g. TinyDB [5]) abstract specific sensor features and offer to the application an SQL-like query language through which it can program the network and access the sensed data. All these proposals exploit a data centric paradigm in the network organization, where all the communications are for named data, that is the queries describe the data to be fetched by the WSN rather than the addresses of the nodes that should execute the query. These approaches have been designed keeping in mind very general monitoring applications where the number of sensors can scale (almost) arbitrarily and in which the sensors are homogeneous in terms of features and monitoring capabilities. On the other hand, the requirements on wireless sensor networks applied to Smart Environments applications (described in section 2.1) are in general rather different. In particular the environment is generally indoor and limited, hence also the size of the WSN hardly scales up to hundreds of sensors, and the network often has a small diameter. Furthermore the WSN is deployed in the same environment of the user, hence it can be

2.2. The OSGi platform The OSGi specification [9] defines a service oriented, component based environment for developers and offers standardized ways to manage the software life cycle for Java applications. OSGi implementations are containers running on top of a JVM which enable installation, removal, start, and stop of components at run time. An OSGi component is a JAR file called bundle which contains Java classes, resources and

375

Authorized licensed use limited to: Chungnam National University. Downloaded on March 24,2010 at 23:17:03 EDT from IEEE Xplore. Restrictions apply.

becomes difficult to configure and calibrate the sensor application. In [17] the interaction with the WSN occurs by means of an Application Programming Interface (API) rather than a (two-components) middleware as in [14,15]. The API comprises the Gateway API and the Node API. The Node and Gateway API implement a vertical solution that affects its flexibility. Indeed, the WSN developers are strictly bound with these API which are not designed to be compliant with legacy technologies or existing WSN solutions. The approach of [16] uses a declarative language called WADL (Wireless Application Description Language) to describe sensor-based applications. WADL is based on a producer consumer pattern constructed according to the OSGi WireAdmin specification: the producers and the consumers are modeled as OSGi services and connected at runtime by wire objects. The WireAdmin service allows to create, delete, retrieve and update wire objects. WADL defines wireapp and wireset elements. Wireapp represents the wired sensor application composed by a dynamic set of producers, consumers and their connections called wires. Wireset represents a dynamic set of wires that connect different producers and consumers. This approach is strongly characterized by the assumption that the sensors behave according to a producer consumer pattern. Although this assumption leads to a simple and elegant solution, it may result too limiting when used to abstract arbitrary WSN (for example a ZigBee based WSN) that may exhibit more complex behaviors. The paper described in [18] introduces a communication protocol that enables opportunistic communication between a mobile device and a WSN. The paper describes a model called scene, that aims at select only a subset of nodes providing the information needed from the mobile device. The scene is described in terms of constraints defined by the mobile user and propagated into the WSN through ad hoc messages. As soon as a node receives a scene message, it runs the scene algorithm checking if it is member of the scene. The authors propose some Java API to define the scene from the application’s perspective, but they do not describe how the mobile users can access the information collected from the scene’s nodes. The work presented in [19] describes the TeenyLime middleware to support sense and react WSN applications. This kind of applications collect data from sensors and react to this information by performing some actions in according to prefixed conditions. The middleware is based upon the tuple space notion defined as a collection of typed fields shared among one-hop neighbors. TeenyLime provides several API to manipulate the tuples (create, read and

expected human intervention at least for simple management operations such as battery or sensors’ replacement. Under these requirements the data centric paradigms play a minor role and it becomes more important the ability of addressing an individual node. Recently appeared solution [11] adopts a node centric paradigm, where it is possible to address each individual sensor in the network. An example of applicative scenario is the user localization into indoor or outdoor environments. The application in this case may be interested in the position of a given user wearing a sensor x, thus it need to request it position directly to x.

3. Related Works The authors of [14] propose an approach in which the UPnP stack protocol is adopted to manage multiple WSN. Since the sensors do not usually have enough resources to host the UPnP stack, a network gateway called BOSS (Bridge Of SensorS) acts as bridge between the UPnP Control Points (application clients) and the sensor networks. BOSS is a standard UPnP device that provides generic WSN management services (such as localization, power management, discovery, security services) and that forwards the messages exchanged between the control points and the WSN. The internal BOSS architecture defines a service manager which interacts with the WSN by using proprietary protocols; however it does not provide any mechanism aimed at the integration of different WSN applications and technologies. A more structured approach is adopted in [15] where it is proposed an architecture comprising a gateway and a server side. The gateway side (based on the OSGi Service Platform) maps every sensor into a Sensor Bean component. The communication mechanisms between the physical sensors and the Sensor Bean comply with the OSGi WireAdmin specification. The role of the server side is to store data collected from several and distributed gateways into a database called Sensor Warehouse. The server side (based on J2EE) communicates with the gateways by using either a push or a pull model and provides also a web server access to direct HTML browsing of logs and configurations. According to the WireAdmin specification, Sensor Bean models the WSN as a composition of simple data producers, thus disregarding any sensor hardware feature. This means that, for example, it is not possible to discriminate between a sensor embedding a transducer and a sensor embedding an actuator. Under this constraint it

376

Authorized licensed use limited to: Chungnam National University. Downloaded on March 24,2010 at 23:17:03 EDT from IEEE Xplore. Restrictions apply.

events generated may be re-elaborated and transformed in high level events (situations) by components subscribed to the bus (e.g. context reasoners). The service bus is used to group all the services available in AAL-spaces. They are atomic or composite services whose availability is managed by a Service Orchestrator component. Services belonging to the service bus may be requested by the Situation Manager in consequence of situation detections and rules stored in the Knowledge Base of the system. Many other basic components are foreseen in PERSONA system which is not discussed here.

remove) and to set the node reactions in according to relevant tuple value changes. The authors propose a detailed middleware description focusing on WSN application level without defining how the collected data can be exported to higher applicative layers or how to integrate the acquired information with already existing applicative scenarios.

5. The Sensor Abstraction and Integration Layers (SAIL) Figure 1. Conceptual Architecture of PERSONA system

SAIL provides a layered architecture that simplifies the data acquisition and node interaction between WSN applications and existing context-aware systems. The purpose of SAIL is to integrate already existing WSN applications, which may or may not be based upon the discussed paradigms, in order to make WSNs efficient and flexible context information sources. SAIL has been designed keeping in mind all the challenges introduced in section 2.1 for Smart Environments: • integration of the different sensor network technologies: SAIL provides a set of high level API that abstract from the sensor hardware adopted and ease the management of the heterogeneous WSN; • management of different applications on the same WSN: SAIL has been projected in top of the OSGi platform that provides a flexible component model. SAIL modularizes every application with a component that can be easily controlled exploiting the component life cycle primitives provided by OSGi itself; • dynamic discovery of sensor applications: the SAIL access layer (described in section 5.2) provides a smart WSN application detection strategy based on the OSGi event mechanism; • management of logical sensors: the SAIL API model the notion of node as a Java class provided with transducers and actuators. WSN developers are free to choose the best modelling between the physical network deployment and the abstraction provided by SAIL; • configuration and calibration of sensor applications: the SAIL API also consider a node interaction model enabling users to set the transducer and actuator parameters. Figure 2 exemplifies the relationship between the PERSONA middleware and SAIL, the figure shows a ZigBee and Bluetooth network integrated within the PERSONA middleware by means of SAIL. The

4. Overview of the PERSONA system The PERSONA project [7] (Perceptive Spaces prOmoting iNdepentent Aging) is a EU-funded research project (FP6) started in 2007, aiming at develop a scalable open standard technological platform to build a broad range of Ambient Assisted Living (AAL) Services. AAL is the concept that embraces all the technological challenges in the context of Ambient Intelligence to face the problem of population aging in Europe. In this context the main technical challenge is the design of a self-organizing middleware infrastructure allowing the extensibility of component/device ensembles in an ad hoc fashion. In order to achieve this goal the communication patterns of the infrastructure must be able to execute distributed coordination strategies in order to provide the necessary service discovery, service orchestration and service adaptation functionalities. The components of a PERSONA system are interfaced with the PERSONA middleware that enables the allocation of a different number of communication buses, each of them adopting specific and extendible communication strategies. Components linked with the PERSONA middleware may register to some of these communication buses, find each others and collaborate trough the local instances of the buses. Figure 1 shows the conceptual architecture of PERSONA. Input and output buses are used to interact with users, typically multi-modal interactions are carried out trough these buses. The context bus is an event based bus on which are attached context sources (in particular the WSNs are attached to this bus), the

377

Authorized licensed use limited to: Chungnam National University. Downloaded on March 24,2010 at 23:17:03 EDT from IEEE Xplore. Restrictions apply.

push or pull models. In the push model the Sensor Node automatically sends the data to the upper layers, while in the pull model the data should be explicitly requested by the upper layers. The Query Node (Figure 3b) models WSN accepting queries in the data centric paradigm. The query should be defined according to the actual application running on the sensors, i.e. if the WSN implements TinyDB the query should be expressed in the TinyDB syntax. The Query Node supports both a push and a pull behavior. a) b)

Persona-aware components created by SAIL, directly interact with the PERSONA Context bus by injecting the sensed information and by receiving actions for the WSN. In the ZigBee network two different applications are highlighted. Figure 2 shows only one possible applicative scenario, but the main purpose of SAIL is to provide to any higher level the above described benefits. Before giving more details about the SAIL layers and the SAIL API, section 5.1 introduces to the Node Model that defines an abstraction of the physical sensors and actuators in the WSN.

Figure 3. a) the Sensor Node and b) the Query Node Figure 2. WSN applications integrated as PERSONA components through SAIL

5.2. The SAIL Architecture SAIL is organized in three layers (figure 5), namely the Access, Abstraction, and Integration layer, constructed over the OSGi platoform. The Access Layer defines a minimal set of functionalities to which any WSN application should provide, either on its own or by means of an application adapter. This layer interacts directly with the WSN to implement the Query Node and the Sensor Node (depending on the behaviour of the underlying WSN). It also hides all the issues concerning the low level communication mechanisms. The Abstraction Layer imports the Sensor Nodes and the Query Nodes defined by the Access Layer in the OSGi framework. To this purpose it registers the Query and Sensor Nodes as OSGi services. The Integration Layer exports the OSGi services registered by the Abstraction Layer to the client applications. To this purpose this layer can encapsulate different exporters suitable to provide access to the OSGi services using different technologies. In the current implementation of SAIL the Integration Layer comprises exporters for UPnP network and PERSONA project. The Access Layer comprises a set of components called Sensor Application Drivers (SAD). Each SAD communicates either with an application running on a WSN and exports the WSN services/functionalities in terms of a Service Provider Interface (SPI) [12] that is specified by the Abstraction Layer. Every SAD

5.1. SAIL Node and Application Management Models The SAIL Node Model takes into account both the node and the data centric paradigms of WSN by defining a Sensor Node and a Query Node. The Sensor Node models an abstract sensor embedding a set of transducers and actuators (Figure 3a). The concept of Sensor Node is not bound to any specific hardware or software platform for the WSN, furthermore a Sensor Node may or may not correspond to a physical sensor of the WSN. In fact this abstraction can be used to model a single physical sensor or to model a collection of them. For example, if a physical sensor comprises transducers for the temperature, residual battery power and accelerometer it is possible to define a Sensor Node embedding three different abstract transducers that map the physical transducers. On the other hand, two different physical sensors embedding an accelerometer and worn by a person can be modeled by a single Sensor Node with a single abstract transducer modeling the posture of the person. The Sensor Node can also provide a set of services corresponding to which implemented by the physical sensors. These services are useful to model service oriented networks such as ZigBee. The services can be accessed by send and receive primitives, while transducers and actuators can be accessed according to

378

Authorized licensed use limited to: Chungnam National University. Downloaded on March 24,2010 at 23:17:03 EDT from IEEE Xplore. Restrictions apply.

implements a notification mechanism used to notify the Abstraction Layer any relevant change. The Abstraction Layer is implemented by a single component called Sensor Base Driver (SBD). The SBD defines the SPI interface that must be implemented by the SAD. The SPI is a general interface that is designed to support different WSN application models. For this reason the SAD, generally, implements only the subset of the SPI functionalities that are relevant for the WSN application it manages. The SBD can be thought as a high level driver which registers the SAD in the OSGi framework: as soon as a new SAD is installed, the SBD registers a manager service associated to the SAD. The SBD implements an API used by the Integration Layer. The Integration Layer comprises a set of components called Sensor Technology Exporters (STE). These components exploit the listener service in the OSGi platform to detect the registration of new services associated to newly registered SAD. Whenever an STE detects a new service, it exports the service in a specific technology according to its internal policies. The development of the STE may take advantage of existing OSGi specification for different access technologies. A notable example is the case of UPnP. In fact OSGi includes an UPnP specification where the services implementing the UPnPDevice interface registered on the OSGi platform can be automatically exported as UPnP Devices. The current implementation of SAIL exploits this specification and the corresponding mechanisms to implement an exporter for UPnP.

Figure 4 The SAIL layered architecture Since there exist a large number of sensor platforms and middleware for WSN, the SPI take into account different compliance levels. This means that if a SAD does not provide a subscription mechanism then it does not implement the Eventing interface, but it still remains compliant with the SPI. The API are defined by the Node interface, that is extended by the SensorNode and the QueryNode interfaces. Among the other, the Node interface provides methods for: • retrieve the node properties: the sensor can be described with a set of properties such as sensor model, sensor manufacturer, sensor displacement, radio unit model; • fetch the node unique identifier; The SensorNode interface implements the Sensor Node. To this purpose it extends the Node interface to include methods for the retrieval of the transducer list of a sensor and the retrieval of the services offered by a sensor. SensorNode can use a set of Transducer interfaces that provide the following methods: • get value: allows the retrieval of the current value of a transducer on a given sensor; • set value: that is used to drive an actuator on a given sensor; • get transducer id: reads the ID of a transducer on a given sensor; • subscribe: enables the upper layers to request to a given sensor a periodic sampling task on a specific transducer. This task can be customized by means of sampling rate and filter expressions; • unsubscribe: to cancel a previous subscription. Every SensorNode can also use a set of Service interfaces that provide the following methods: • get description: provides the description of a service of a given sensor; • send/receive: primitives enabling the interaction with a given service on a given sensor. The QueryNode interface implements the Query Node. To this purpose it extends the Node interface to include methods aimed at the interaction with data centric WSN. This interface provides method to:

5.3. The SPI and the API The set of functions of the SPI implemented by each SAD can be partitioned in according to this classification: Discovery: the functions that notify the connection and disconnection of sensors to/from the WSN; Control: the functions that set the state of the actuators embedded in the sensors; Monitoring: the functions that provide read access to the sensors transducers; Eventing: the functions that enable the subscription to data update and that notify changes; Description: the functions that describe properties associated to the sensors.

379

Authorized licensed use limited to: Chungnam National University. Downloaded on March 24,2010 at 23:17:03 EDT from IEEE Xplore. Restrictions apply.

• start: diffuse the query into the WSN; • stop : stop a query; • get value: according to the pull behavior, the upper layers can synchronously request for available query results. The API also provides methods for the network management, which include basic functionalities to stop/start the SAD, and to retrieve the status of a WSN application.

services registered form the Abstraction Layer after the Access Layer notifications: • Posture Sensor: an OSGi service associated to the posture detection application; • Localization Sensor: an OSGi service for the localization of the mobile nodes M1 and M2. Posture Sensor and Localization Sensor provide to the PERSONA exporter all the fetched sensor data that will be injected into the context bus.

6. Case study

7. Discussion and conclusions

We tested SAIL in conjunction with PERSONA middleware, in order to exploit a simple WSN application as context source for PERSONA. SAIL was compiled for the Crossbow’s Stargate gateway and a WSN of 9 MICAz sensors [8]. The Stargate is a Linux embedded processing platform based on Intel’s Xscale® 400MHz processor. In our testbed the Stargate supports the Blackdown Java 1.3 distribution and the OSGi open source implementation released by the Apache Felix project. On top of Felix it is installed an instance of the PERSONA middleware linked with SAIL. The motes are provided with a sensor application based on a Simple Sensor Middleware (SMW). The purpose of SMW is to set up a WSN application by reproducing the behaviors described in Section 2.1 in order to test SAIL. SMW has a memory footprint of about 1,5 KByte and it consists of 8 communication primitives that allow to interact with the sensors. The message types are the following: • ping and pong: multicast messages between the sink node and the sensors that support sensor discovery. These messages model the dynamism into a smart environments where sensors may join or leave the network arbitrarily; • request and response: to fetch data values from the transducers; • subscribe/unsubscribe and notify: to subscribe for a value by specifying different sampling parameters (filtering, sampling rate, sampling period, etc.); • command: to calibrate the mote’s actuators. Figure 5 details the Abstraction and Access layers of SAIL architecture in our case study. Two WSN applications, posture detection and localization, are represented. The former is composed of two motes labeled with X and Y virtualized as one single Sensor Node. The later is composed of four anchor nodes (A) and two mobile nodes (M1 and M2) whose position into the environment is computed by the anchors. As soon the WSN applications start, the SAIL Access Layer detects them and notifies to the Abstraction Layer their presence. Figure 5 depicts the OSGi

The first consideration on the Access Layer is that sharing a common middleware (such as SMW) at WSN level simplifies the coding of the SAD. Every application driver can be decomposed into a Middleware Driver, that is, a bundle that installs a service shared by all the SAD, and a component (in Figure 4 called Virtualization Logic) that combines the data coming from the WSN application. In our case study the logic processing the raw data is implemented by a Java component, however an approach similar to WADL [16] or alternatively based on Java annotations is also feasible. However the data processing should be enriched with filters and functions for the analysis and classification of the sensed data. In this respect the [13] proposes an open source framework that provides simple features extractors directly on the sensors, and it can play the same role of the SMW middleware and its feature extraction capabilities can be the base on which to design a language for the virtualization logic. Further considerations are related to the link between WSN and context aware systems. In most cases this is achieved by means of metadata describing the sensors and context information. Systems adopting an ontological approach to model context information require at least a reference to the domain ontology to which the sensor belongs. Optionally other information such as the confidence and accuracy of the data can be provided. Typically such metadata can be defined at development time, installation time or run time. In the case of mobile sensors associated to users there is also the problem of binding them together. By means of a configuration procedure a context aware system can manage such bindings by storing the references in its knowledge base, but users mobility across different AAL-spaces may impair any static approach to this binding. In our case the SAD component can be configured by a metadata file which is accessible also through the management API of SAIL, but we believe that the sensor itself may provide simple primitives to store simple metadata records. In this case the metadata record could be retrieved whenever the sensor (or

380

Authorized licensed use limited to: Chungnam National University. Downloaded on March 24,2010 at 23:17:03 EDT from IEEE Xplore. Restrictions apply.

equivalently its user) enters into another AAL-space. This mechanism is also useful to implement a service provisioning feature that is naturally supported by the OSGi platform. In fact the component implementing the Virtualization Logic in the SAD might be stored in public repositories. The OSGi platform may then retrieve the bundle URL from the metadata record and install the bundle. With respect to the Abstraction Layer, we observe that the SBD component can also equalize the access to WSN applications that adopt different access models. For example a SAD that provides only a pull model, i.e. it implements the SPI Monitoring interface but not the Eventing interface, can be adapted by the SBD to simulate notify events. A final consideration concerns the Integration Layer of SAIL. The use of OSGi enables a flexibility in the plug of new STE that is hardly achievable in other system not based on a service oriented framework. Finally, with SAIL the developers do not need to be aware of the application level, neither they have to learn new interfaces and schemas of WSN.

for sensor networks”, ACM Transactions on Database Systems, 30(1):122–173, 2005. [6] Baldauf, M., Dustdar, S. and Rosenberg, F., “A survey on context-aware systems”, Int. J. on Ad Hoc and Ubiquitous Computing, 2 (4):263–277, 2007 [7] EU FP6 Integrated Project "PERceptive Spaces prOmoting iNdependent Aging" (PERSONA), 2008 http://www.aal-persona.org. [8] Crossbow Technology Inc., http://www.xbow.com. [9] OSGi Service Platform Release 4, Version 4.1, May 2007 (http://www.osgi.org). [10] C. Lee, D. Nordstedt, and S. Helal, “Enabling smart spaces with OSGi”, IEEE Pervasive Computing 2(3):89-94, 2003. [11] ZigBee Alliance, “ZigBee Specifications”, Dec. 2006. [12] R. Seacord, L. Wrage, ”Replaceable Components and the Service Provider Interface”, Technical Note CMU/SEI2002-TN-009. [13] R. Gravina, et.al., “Demo abstract: SPINE (Signal Processing in Node Environment) framework for healthcare monitoring applications in Body Sensor Networks”, White Paper - http://spine.tilab.com/papers/2008/Demo_SPINE.pdf. [14] H. Song, D. Kim, K. Lee and J. Sung, "UPnP-based Sensor Network Management Architecture and Implementation", 2nd International Conference on Mobile Computing and Ubiquitous Networking, Osaka, 2005 [15] C. Marin, M. Desertot, “Sensor bean: a component platform for sensor-based services”, ACM 3rd international workshop on Middleware for pervasive and ad-hoc computing, Grenoble, France, 2005, pp. 1–8. [16] H. Cervantes, D. Donsez, L. Touseau, “An Architecture Description Language for Dynamic Sensor-Based Applications“,5th IEEE Consumer Communications and Networking Conference (CCNC 08), Las Vegas, Nevada, USA , 10-12 Jan. 2008, pp.147-151. [17] J. K. Juntunen et.al. , “WSN API: Application Programming Interface for Wireless Sensor Networks”, IEEE Personal, Indoor and Mobile Radio Communications, Helsinki, Sept. 2006, pp. 1-5. [18] S. Kabadayi, C. Julien, “A Local Data Abstraction and Communication Paradigm for Pervasive Computing”, IEEE PerCom 2007, 19-23 March 2007, pp. 57 – 68. [19] L. Mottola, P. Costa, A. L. Murphy, and G. Pietro Picco, ”Programming Wireless Sensor Networks with the TeenyLIME Middleware", 8th ACM Inter. Middleware Conference, Newport Beach (CA, USA), November 2007.

Figure 5 Virtualization Layer in SAIL

8. References [1] P. Baronti, P. Pillai, V. Chook, S. Chessa, A. Gotta, and Y. F. Hu, “Wireless sensor networks: a survey on the state of the art and the 802.15.4 and Zigbee standards”, Computer Communications, 30:1655-1695, 2007. [2] G.D. Abowd, C.G. Atkeson, J. Hong, S. Long, R. Kooper, and M. Pinkerton, “Cyberguide: A mobile context aware tour guide”, Wirless Networks, 3(5), 1997. [3] A.K. Dey, “Context aware computing: The Cyber Desk project”, AAAI Spring Symposium on Intelligent Environments, 1998. [4] C. Intanagonwiwat, R. Govindan, and D. Estrin, “Directed diffusion: a scalable and robust communication paradigm for sensor networks”, MOBICOM, 56–67, 2000. [5] S. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong, ”TinyDB: an acquisitional query processing system

381

Authorized licensed use limited to: Chungnam National University. Downloaded on March 24,2010 at 23:17:03 EDT from IEEE Xplore. Restrictions apply.