Unified Service Access for Wireless Sensor Networks

Transcription

1 Unified Service Access for Wireless Sensor Networks Jukka Suhonen, Olli Kivelä, Teemu Laukkarinen, and Marko Hännikäinen Department of Computer Systems Tampere University of Technology Tampere, Finland {jukka.suhonen, olli.kivela, teemu.laukkarinen, Abstract Sensor networks enable large scale and fine resolution monitoring via interconnected sensor devices that range from home appliances and mobile phones to dedicated sensing platforms. While new wireless technologies are emerging, the challenge is in the interpretation and utilization of heterogeneous data received through varying types of interfaces. This paper presents a unified service access architecture, interfaces, and message formats for Wireless Sensor Networks (WSNs) collectively referred to as WSN OpenAPI. It supports sensor data collection, actuator control, real-time alerts based on sensor values, and querying measurement and alert history. Compared to the related work, WSN OpenAPI allows efficient machine-tomachine (M2M) communications with low complexity message formats and avoiding extensive queries with publish/subscribe paradigm. Keywords-wireless sensor networks; web services; sensor systems; information management I. INTRODUCTION Sensor networks enable large scale and fine resolution monitoring of physical world via interconnected sensor devices. The devices include computers, mobile phones, home appliances, and dedicated sensing platforms. A Wireless Sensor Network (WSN) is a specific case where the main purpose of the network is in sensing and actuation. A WSN combines environmental sensing, data processing, and wireless multihop ad-hoc networking with low cost and lowenergy hardware [1]. In general, sensor networks enable a vast amount of applications in various areas such as military surveillance, interactive games, security and asset management, environment monitoring, health care, building and home automation, and industrial control. The key challenge is the utilization of heterogeneous sensor values to allow collaboration and data fusion between sensor networks. Sensor devices use various protocols, different interfaces for accessing sensors, and incompatible sensor data formats, which makes combining data from different sources hard. For example, WSNs alone comprise myriad of different network technologies [2], such as IEEE /ZigBee, IEEE RuBee, WirelessHART, Z- Wave, and proprietary protocols. As the technologies have different capabilities, e.g. in throughput, communication range, and energy-efficiency, it might be beneficial to combine different technologies even on the same installation site. This paper presents the design and reference implementation of WSN OpenAPI, which is our proposal for a unified service architecture for WSNs 1. It is a set of specifications that define interfaces and data formats for accessing sensors and actuators (transducers). WSN OpenAPI supports common sensor tasks comprising sensor data collection, actuator control, real-time alerts based on sensor values, and querying measurement and alert history. Unlike the related proposals, WSN OpenAPI is targeted at efficient machine-to-machine (M2M) communications. Small message formats enable the use of resource constrained hardware and limited bandwidth. The design has been industry-driven. In addition to the sensing functionality, the developed specifications support maintenance and the life cycle management of WSNs. WSN OpenAPI has been verified in deployments with a prototype low-energy WSN called Tampere University of Technology Wireless Sensor Network (TUTWSN), and Android and Nokia N900 mobile phones. As a practical use case, this paper presents a greenhouse pilot study. The rest of this paper is organized as follows. Section II lists related work on WSN interfaces and data gathering. Section III describes WSN OpenAPI in detail. A reference implementation and experimental results are described in IV. Section IV concludes the paper. II. RELATED WORK IEEE 1451 describes a set of standards for connecting transducers to microprocessors via different network technologies. The standards share a common Transducer Electronic Data Sheet (TEDS) specification that describes transducer identification, calibration, and manufacturer related information. The standards define only methods to access to transducers directly, while e.g. data collection and alert services must be implemented as separate services [3]. To guarantee compatibility between products from different manufacturers, several communication standards, such as ZigBee and Bluetooth, define application profiles. The profiles describe the procedures and data formats supported by a device. However, the profiles are generally technology dependent, and to exchange data between technologies it needs to be converted to shared data formats and messages. 1 Openapi specification is available with reference applications at http: //

2 Sensor query languages gather data from the network based on complex requests [4]. However, they usually require that data is stored at nodes [5] and expect certain capabilities from the sensor devices. Thus, their applicability is limited as the interoperability between different networks is not considered. Open Geospatial Consortium (OGC) has developed sensor related extensible Markup Language (XML) encodings referred to as Sensor Web Enablement (SWE) [6]. Two metadata formats have been defined. Sensor Model Language (SensorML) describes sensors and their capabilities, while Observations & Measurements (O&M) describes sensor measurements. These formats may be used separately or together with other OGC standards. SWE defines several services for practical utilization of sensors. Sensor Observation Service (SOS) defines an interface for requesting simple observations from sensor networks and observation repositories (e.g. a measurement database). Sensor Planning Service (SPS) extends SOS by allowing complex sensor queries that require time consuming computation or waiting for future data. Sensor Alert Service (SAS) defines an interface for publishing and subscribing to sensor alerts. Alerts can be delivered to the client with Web Notification Services (WNS), which is intended to deliver messages with various methods, e.g. , HTTP to other services, and SMS. WNS is not tied to alerts, but can be used generally with other services and protocols e.g. to indicate client the completion of SPS query. Sensor measurements in SWE are encoded with Transducer Markup Language (TML). It can be used for real-time streaming or carrying SOS or SPS results. For convenience, TML includes additional transducer information such as characteristics (accuracy, coordinates,...), calibration, operational conditions, and the relationships of transducers. Thus, TML can be used independently from O&M and SensorML. OGC SWE has been implemented in Open Sensor Web Architecture (OSWA) [7], PULSENet [8], and WSN Application Service Platform (WASP) [9]. The common goal of these platforms is to ease the development of applications that utilize sensor data by defining a middleware layer for SWE. Additionally, WASP extends SWE with user authentication, WSN hardware configuration management, and application management for inserting, updating, and discovering sensor services. SenseWeb [10] aims to provide an open infrastructure for registering and utilizing sensors. It uses a centralized architecture where sensors connect to a coordinator via gateways. The gateways hide network technology details and determine which data is available publicly. Compared to SWE, SensorWeb has less features. It supports only storing and querying sensor data, whereas alerts and other sensor related services are not specified. Furthermore, the platform does not support real-time streaming of sensor data making it mostly suitable for infrequent queries. IrisNet [11] and Hourglass [12] are frameworks that allow complex queries over distributed Internet-connected sensors. Their goal is to reduce bandwidth usage to allow high bandwidth sensing, e.g video streams, with data filtering, smart query routing, and data caching. As a drawback, these frameworks expects significant computing power and storage for the routing devices. WSN OpenAPI act as an abstraction layer for sensor network services. Thus, it can be used to connect network specific standards such as IEEE 1451 to data query frameworks. Compared to SenseWeb, WSN OpenAPI supports several sensor related services and historical data queries. WSN OpenAPI does not mandate a specific communication protocol. This relaxes implementation requirements and allows using it e.g. over TCP/IP, SOAP, SIP, or other communication protocols in WSNs such as 6LoWPAN. Unlike SWE that pulls data from passive services [13] thus causing query overhead to the sensor network, WSN OpenAPI uses an active publishing mechanism. In addition, data collection can be adjusted based on client requirements thus reducing sensor network overhead. WSN OpenAPI allows implementation on very resource constrained devices by defining simple data formats. Still, it can be used in conjunction with the SWE interfaces and services. Specifically, SensorML that has been adopted as meta-data format. III. WSN OPENAPI WSN OpenAPI defines a unified access to sensor network services as shown in Fig. 1. This way, clients (e.g. applications or M2M systems) that connect to the gateway function similarly regardless of sensor network technology. A sensor network may comprise multiple nodes, or consist of only one node e.g. a personal computer or a mobile phone that publish their sensors. The architecture of WSN OpenAPI presented in Fig. 2 comprises sensing, actuation, data storage, and metadata services. An WSN OpenAPI gateway connects sensor networks to clients. A sensor device can interact with the Figure 1. Unified access to sensor network services.

3 gateway directly with WSN OpenAPI, but for compatibility, an adapter may be used to convert between WSN OpenAPI and proprietary data formats. Data archive service stores measurement values for later examination and can be realized e.g with a file or database. Meta-data archive is a data storage that holds node and sensor related information such as sensing accuracy, manufacturer, and model. The architecture allows the distribution of these services to separate machines to increase performance when interfacing large networks, or they can be co-located in a single machine. WSN OpenAPI uses a hierarchical structure to address nodes and transducers: a sensor network comprises nodes, which contain one or more transducers. As a physical sensor may measure several related quantities e.g. temperature and humidity, a transducer is further divided into components. For example, an acceleration transducer comprises components for acceleration on each axis. The network hierarchy fits naturally to WSNs but can also be applied to single devices such as satellites or mobile phones. In that case, each device forms a virtual network. A. Network Interfaces WSN OpenAPI consists of several interfaces that can be used separately. Thus, an WSN OpenAPI client need to implement only the interfaces that are required for its functionality. The interfaces are: Authentication and Capability Format (ACF) defines message formats for authenticating to the gateway and querying the list of supported interfaces. Thus, this is the only mandatory interface for an implementation. Network Management Format (NMF) describes message formats for querying network structure and status, configuring measurement collection, and setting alerts. Meta-Data Format (MEDF) defines an interface for querying node capabilities and sensors. Sensor Information Data Format (SIDF) describes the format to present measurement data. Sensor Archive Data Format (SADF) defines request and response data formats for accessing values stored in a WSN data archive. Node Actuator and Sensor Control (NASC) presents an interface for sending actuator commands to sensors. If a sensor network/device does not natively support the features specified in certain interface, such as alerts, it is expected that these features are emulated in the gateway. The relations between the interfaces and their connectivity to the gateway, data archive, and meta-data archive are presented in Fig. 3. The interfaces utilize publish/subscribe paradigm where data consumers register themselves to the data sources to receive the data they are interested in. WSN OpenAPI messages are defined both in XML and Comma Separated Value (CSV) formats. Using textual presentation for data instead of binary format increases compatibility between different machine architectures. XML format is being adopted as a common language between software systems, and benefits from the common availability of parser libraries and language support. Also, as the defined XML messages define the data types and interface part in WSDL, allowing describing the service easily in WSDL. CSV is more compact allowing its use in M2M communications where bandwidth is limited and data compression would require too much processing power. B. Network Structure and Status In addition to the sensor measurements, WSNs have often industry-driven requirements for system integration. These require the knowledge of network structure, the status of devices, e.g. their location and whether their are working correctly or being replaced. The hierarchical model of the WSN OpenAPI supports storing and querying the maintenance information in network, node, and sensor levels. In addition, the knowledge of network structure allows efficient targeting of requests and commands to individual sensors. For example, a gateway can return error message immediately when trying to send an actuator command to a non-existing actuator. Figure 2. WSN OpenAPI service architecture comprising a gateway, an optional technology specific gateway adapter, data archives, and network elements. Figure 3. Relations between the WSN OpenAPI interfaces. Arrows denote the direction in which messages are forwarded.

4 C. Configuration of Measurements Measurement requests control real-time data collection of sensor values. This way, a client does not need to poll gateway continuously. Instead, a client requests certain sensor readings by defining the measured quantity (sensor type) and how often a sensor is sampled. The gateway sends the measurements periodically to the client. By default, a request is directed to the whole network but can be limited to certain nodes. An example request is presented in Fig. 4. The data collection depends on implementation. Ideally, a gateway adjusts sensing based on the measurement requests. Thus, sensors are sampled only when required which reduces overhead in the sensor network. If the run-time modification of data collection intervals is not possible, e.g. due to the lack of support in WSN protocols, the sensors can be sampled at fixed intervals. Then, the gateway can generate measurements at specified intervals from the latest measurement values. D. Sensor Alerts Some of the collected sensor values may indicate critical conditions that could cause loss of property, information, or lives, e.g. machine malfunction, intruder, or fire. Alerts provide a method to identify these situations and send realtime message to the client. Alert service is configured via NMF interface. An alert defines a sensor type and value range that triggers a notification. An alert can be targeted to the whole network or specific sensors. An alert is delivered to the client as SIDF message. High level actions, such as generating an or SMS message, are outside the scope of the specification. However, high level messages can be generated by another alert service, e.g. SAS in OGC SWE, which has subscribed to the WSN OpenAPI alerts. A configuration example is shown in Fig. 5. <SetMeasurements xmlns="urn:wsn-openapi:xml:ns:nmf" > <Measurement quantity="temperature" interval="2" time_unit="minute"/> <Measurement quantity="luminance" interval="1" time_unit="minute"> <Network id="1"><node id="2"/></network> </Measurement> </SetMeasurements> Figure 4. Measurement request example comprising a generic temperature request and luminance request targeted at a specific node. <Alerts network="13"> <Alert id="1" quantity="humidity" min="50" max="70"/> <Alert id="2" quantity="acceleration" min="20" max="30" inclusive="false"> <Node id="2"/> </Alert> </Alerts> Figure 5. Alert configuration example. Inclusive parameter means that an alert is generated when sensor value is within the defined bounds. E. Sensor Data Collection An example of data collection is shown in Fig. 6. Gateway associates the measured raw sensor values with time and quantity and forwards measurements to clients. To complete the understanding about the measurement, a client may request related information from data archives, such as the current sensor location and measurement unit and margin of error. The SIDF and SADF interfaces are used to deliver measurements to the client. SIDF is targeted as streaming realtime data directly from nodes, whereas SADF is designed for archived sensor data queries. Figure 7 presents an example of SIDF measurement in XML and CSV formats. Compared to SIDF, SADF message may include data from several nodes. A SADF request contains a time frame and can be limited to certain measurement type, nodes, or sensors. SADF reply is grouped based on measurement type as Network: {Time frame, Measurement: {Node, Sensor}}} to ease result handling. Figure 8 shows an example of subscription to real-time measurements generated by another client. A data consumer client defines in its request the measurements it wants to receive. The request can be limited to specific networks, nodes, or sensors. Figure 6. Composition of measurement related information. <SIDF version="1.0" xmlns="urn:wsn-openapi:xml:ns:sidf"> <Network id="13"> <Node id="2"> <Sensor id="acceleration"> <Measurement quantity="acceleration" unit="mg" time=" t14:24:46+00:00"> <Component id="x">142</component> <Component id="y">46</component> <Component id="z">895</component> <Component id="roll" unit="degree">8</component> <Component id="pitch" unit="degree">2</component> <Component id="total">907.36</component> </Measurement> </Sensor> </Node> </Network> </SIDF> SIDF;1.0;1 "13";"2";"Acceleration"; T14:24:46+00:00;;142,46, 895,8,2, Figure 7. Example of sensor measurement in XML and CSV formats. The first row of CSV denotes the message type, version, and the number of data lines.

5 Figure 8. Subscription to real-time measurements. reception of all sensor data, it only receives measurements from networks, nodes, and sensors to which it has access rights. As message handling performance is of concern in the resource constrained devices, message parsing times were recorded on the test setup. On test computer (Java 1.6.0_26, Windows 7, and Intel i5 M540 processor) XML parsing took 0.27 ms while CSV message was decoded in ms. As a comparison, the same implementation on mobile phone (Android 2.2.1, 800 MHz Scorpion processor) parsed XML and CSV messages in 10.1 ms and 0.41 ms, respectively. Thus, CSV format is especially suitable when processing power is limited but is beneficial also in PC class devices when large quantities of data need to be handled. F. Actuator and Sensor Control NASC interface controls sensor network actuators and configures node specific operational parameters, e.g., how sensors should collect their data. Figure 9 presents an example of an actuator command to turn on lights. IV. IMPLEMENTATION AND EXPERIMENTS The interface has been verified with several practical deployments. In this paper, we consider two distinct use cases. In the first use case, mobile phones represent a network comprising only one sensor device that interacts directly with the WSN OpenAPI gateway. The second use case presents a multihop mesh network with several TUTWSN [14] sensor nodes. The basic operation principle of TUTWSN is comparable e.g. to ZigBee as it uses similar multi-hop low duty cycle operation. In the implementations, the mobile phones transmit data in WSN OpenAPI format, whereas the second use case uses an adapter on the WSN OpenAPI gateway to convert native WSN message format to WSN OpenAPI as presented in Fig. 10. In addition to the sensor devices, a user interface was implemented for viewing sensor data and controlling the networks. Both the gateway and the user interface were implemented in Java for ease of portability. The implementation used TCP/IP as a transport protocol. In the used approach, a TCP connection acts as a session which is initialized by sending an ACF authentication message. The user privileges were stored in PostgreSQL database on the gateway, and detailed users and their rights to read sensors, control actuators, and configure network settings. For example, when a client program requests the A. Use Case: Mobile Phone as a Sensor Modern mobile phones are equipped with several sensors, thus allowing many sensing applications. As users almost always carry a phone, phones can act as personal alert devices, and allow large scale distributed sensing. A WSN OpenAPI client for Nokia N900 mobile phone was implemented as a Python script. The client uses CSV format, allowing a low complexity implementation with only 200 lines of code (LOC). The actual WSN OpenAPI message calls took only 50 LOC while the remaining of the code comprised polling sensor values. This indicates the suitability of the proposed interface for resource constrained devices. The N900 client publishes acceleration, luminance, and GPS location information to the gateway with SIDF interface. Similar client was implemented in Java for Android platform. From the application point of view, the WSN OpenAPI architecture allows seamless convergence of different network technologies: the mobile phone can be viewed as just another node in the sensor network. Based on the GPS information, the user interface co-located mobile phones on the same map with nodes from other networks as show in Fig. 11. B. Use Case: Greenhouse Monitoring In the greenhouse monitoring, a sensor network allows fine grained control in environmental conditions, thus potentially increasing crops and saving resources as unnecessary <Network id="1"> <Node id="2"> <Commands> <Actuator id="light_switch">on</actuator> </Commands> </Node> </Network> Figure 9. Actuator command to turn on lights on a target node. Figure 10. WSN OpenAPI implementation including gateway software, mobile phone sensor devices, connection to WSN, and an user interface.

6 Figure 13. case. Figure 11. User interface showing both dedicated TUTWSN nodes and a mobile phone with current sensor values. heating and watering are avoided. The greenhouse monitoring network comprised two data collecting nodes that were connected to the WSN OpenAPI gateway, and 28 TUTWSN nodes as shown in Fig. 12. The other data collecting node was used for load balancing. Nodes were equipped with temperature, humidity, and luminance sensors that were sampled once per two minutes. The use case presented the interoperability with an existing technology. The message between the TUTWSN gateway (data collectors) and the WSN OpenAPI gateway used a proprietary binary message format as shown in Fig. 13. Table I shows the typical amount of samples per day collected from the sensor network and the amount of traffic Connectivity and the message formats in the greenhouse use required to encode the samples with different data formats. A typical SIDF message for a sensor sample consumed 258 B in XML and 54 B in CSV format. As a comparison, the same data in TUTWSN binary format required 18 B. Requesting historical data with SADF requires 48% less space than the real-time reception of the same data with SIDF, assuming that the sensor data is requested in one query. Compared to the XML messages, CSV format requires 79% and 55% less bandwidth in SIDF and SADF, respectively. V. C ONCLUSIONS This paper presents a sensor network architecture that defines a unified access for sensor data collection, actuator control, real-time alerts, and querying measurement history. Compared to binary formats, the used XML and CSV formats increase overhead but improve interoperability between systems. The structured XML messages allow application specific extensions, while the more compact CSV enable efficient M2M communications. The current interface design concentrates on the first phase sensor networks comprising sensing and actuation. As a future work, the interface will be extended with data processing components to support distributed computing in smart and autonomous sensor networks. R EFERENCES [1] I. F. Akyildiz, S. Weilian, Y. Sankarasubramaniam, and E. Cayirci, A survey on sensor networks, IEEE Communications Magazine, vol. 40, no. 8, pp , Aug [2] J. Yick, B. Mukherjee, and D. Ghosal, Wireless sensor network survey, Elsevier Computer Networks, vol. 52, no. 12, pp , Aug Raw data Data Temperature / node All sensors / node All sensors / network SIDF XML CSV SADF XML CSV Table I T RAFFIC Figure 12. Multihop network topology in the greenhouse use case showing the typical routes toward data collecting nodes. REQUIREMENTS OF THE WSN O PENAPI FORMATS PER DAY IN THE GREENHOUSE USE CASE ( VALUES AS MB S ).

7 [3] E. Song and Kang Lee, Smart transducer web services based on the IEEE standard, in Instrumentation and Measurement Technology Conference (IMTC), May 1-3, 2007, pp [4] P. Bonnet, J. Gehrke, and P. Seshadri, Querying the physical world, IEEE Personal Communications, vol. 7, no. 5, pp , Oct [5] R. Sugihara and R. K. Gupta, Programming models for sensor networks: A survey, ACM Trans. Sen. Netw., vol. 4, pp. 8:1 8:29, Apr [Online]. Available: [6] M. Botts, G. Percivall, C. Reed, and J. Davidson, OGC R sensor web enablement: Overview and high level architecture, in Second Int l Conf., GSN 2006, Boston, MA, USA, October 1-3, 2006, Revised Selected and Invited Papers, S. Nittel, A. Labrinidis, and A. Stefanidis, Eds. Springer, 2008, pp [7] X. Chu and R. Buyya, Service oriented sensor web, in Sensor Networks and Configuration Fundamentals, Standards, Platforms, and Applications, N. P. Mahalik, Ed. Springer, 2007, ch. 3, pp [8] S. M. Fairgrieve, J. A. Makuch, and S. R. Falke, Pulsenet TM : An implementation of sensor web standards, in Int l Symposium on Collaborative Technologies and Systems (CTS 09), May 2009, pp [9] J.-C. Liu and K.-Y. Chuang, WASP: An innovative sensor observation service with web-/gis-based architecture, in 17th Int l Conf. on Geoinformatics, Aug. 2009, pp [10] J. L. Aman Kansal, Suman Nath and F. Zhao, Senseweb: An infrastructure for shared sensing, IEEE Multimedia, vol. 14, no. 4, pp. 8 13, Oct.-Dec [11] S. Nath, A. Deshpande, Y. Ke, P. B. Gibbons, B. Karp, and S. Seshan, Irisnet: an architecture for internet-scale sensing services, in VLDB 2003: Proceedings of the 29th international conference on Very large data bases. VLDB Endowment, 2003, pp [12] J. Shneidman, P. Pietzuch, J. Ledlie, M. Roussopoulos, M. Seltzer, and M. Welsh, Hourglass: An infrastructure for connecting sensor networks and applications, Harvard University, Tech. Rep., 2004, harvard Technical Report TR [13] D. Moodley and I. Simonis, A new architecture for the sensor web: The SWAP framework, in 5th Int l Semantic Web Conference (ISWC), Nov., , p. 17. [14] M. Kohvakka, J. Suhonen, T. D. Hämäläinen, and M. Hännikäinen, Energy-efficient reservation-based medium access control protocol for wireless sensor networks, EURASIP Journal on Wireless Communications and Networking, 2010, article ID