Web Services for Sensor Node Access

Markus Hillenbrand1 , Aline Verney1 , Paul M uller1 , and Tom Koenig2

University of Kaiserslautern, Department of Computer Science, Postfach 3049, 67653 Kaiserslautern, Germany {hillenbr, verney, pmueller}@informatik.uni-kl.de http://www.icsy.de Fraunhofer Institute for Experimental Software Engineering IESE, Sauerwiesen 6, 67661 Kaiserslautern-Siegelbach, Germany koenig@iese.fhg.de http://www.iese.fhg.de

Abstract. Some research areas rely on simulation instead of experiments. And these simulation scenarios need a suitable data basis to operate on. Besides existing databases containing previously acquired or calculated data, sensor networks are a useful way to acquire necessary data. This paper introduces a software and hardware system that allows users to seamlessly access and integrate data provided by wireless and mobile sensors through a dedicated XML and Web Service enabled middleware. It describes the hardware components that have been utilized and combined to create a sensor node, and it outlines a dedicated middleware architecture to manage sensor nodes, the data gathering process and data access.

Introduction

While it is possible to make experiments in many research areas, there are some sectors where only simulations can be used to generate acceptable results. These simulations often operate on mathematical models representing - or modeling - the real world or at least parts of it. As these models need a data basis to calculate their results, suitable input must be generated or acquired. Sensor networks applied in the real world are a common means to measure necessary data and provide the models with the facts they require [3]. Urban planning can be seen as one possible use case for such a scenario. The key word sustainable development has become a main principle in some countries, either by insight of the planners or by guidelines of governments. Its basic message is that current decisions and actions in society, economy and environment should consider the needs of future generations. And to achieve this, it is obviously necessary to nd a balance between the three areas (society, economy and environment) and to detect interdependencies between them to understand how they inuence each other. But it is not possible to build a city and check its state and progress over the time. Thus, simulation is the only way to gain information about interdependencies and the three-dimensional eects of urban planning.

Markus Hillenbrand et al.

This paper introduces a system using a dedicated middleware platform and special hardware delivered as sensor devices that may be used to gather environmental information and other data needed by mathematical models and distribute it to the (human or software) client. In the following, section 2 gives a short overview of currently available and suitable technologies in the area of hardware and software for the creation of wireless sensor devices. Section 3 introduces the selected hardware and section 4 explains the software written for the sensor devices. Section 5 takes a look into the Web Service architecture provided for client access. The main focus of this paper lies within the sensors, providing information about hardware and software while the middleware and its architecture are only described shortly to present its benet for programmers and users.

Available Technologies and their Requirements

Before presenting the actual hardware and software realization in the next sections, a short outline of adequate hardware and software requirements for building a sensor network will be presented now. The topics covered are localization, communication, data formats and security issues3 . As sensors can either be mobile or statically attached to a xed location, their gathered data has to be annotated with the position it has been at the time of measurement. While there are numerous techniques to obtain a spatial coordinate representing a real world position like beacon based techniques, signal strength variations and various triangulation techniques, the decision which to use has to consider the usage scenario, power consumption and cost. A comprehensive overview of currently available location sensing systems can be found in [1] and [5]. The use of the Global Positioning System GPS in sensor nodes has often been ruled out in many scenarios due to high power consumption and other obstacles [2]. As shown in section 3, this exclusion should be considered again as with the so called GPS on a chip solutions power consumption and size have been reduced dramatically. Another hindrance for the usage of GPS in sensor nodes might have been the deliberately low precision of the U.S. GPS system for civil and commercial usage due to its primary military origin4 . This may change with the availability of the European GALILEO [11] equivalent scheduled to be ready by 2006 (early test phase) and 2008 (nal operational service). It promises better accuracy and reliability because of its civil and commercial purpose. When data gathered by sensor nodes should be made accessible from other entities via the Internet, a suitable form of communication must be established. And there are several possibilities to achieve this. A solution using a hard wired connection is not suitable for mobile sensors, so only a wireless solution can be
3

Power consumption will not be regarded in this paper as it solely covers the computer science perspective. The usage of GLONASS, the Russian GPS system, is also not very widespread.

Web Services for Sensor Node Access

used to connect to the Internet. LAN connections following the IEEE802.11 wireless communication standards are applicable in small areas which are equipped with enough access points providing a sucient infrastructure. The benets of this solution are high bandwidth and ubiquitous availability, while cost and narrowness limit its usability [5]. The Global System for Mobile Communications (GSM) allows not only for mobile and wireless telephone services, it also enables users and devices to access the Internet using Circuit Switched Data (CSD), High Speed CSD (HSCSD) or Global Packet Radio Service (GPRS). As table 1 shows, connection speeds between 1.2 kByte/s using CSD and 21.4 kByte/s using GPRS-CS4 are possible (but not all connection speeds are available in all countries). While it is possible to dial into arbitrary networks by using (HS)CSD, GPRS currently only allows a connection to one dedicated provider dened by the telephone company chosen. Currently available GPRS chips can be integrated in sensor devices seamlessly and thus provide access to the Internet. At this point, only a Virtual Private Network (VPN) can be used to establish a secure connection to a private subnet.
Table 1. Connection Speeds in the GSM Net 1 channel 4 channels CSD HSCSD GPRS CS GPRS CS GPRS CS GPRS CS 9,6 14,4 9,1 13,4 15,6 21,4 kBit/s kBit/s kBit/s kBit/s kBit/s kBit/s 57,6 36,2 53,6 62,4 85,6 n/a kBit/s kBit/s kBit/s kBit/s kBit/s 8 channels 115,2 72,4 107,2 124,8 171,2 n/a kBit/s kBit/s kBit/s kBit/s kBit/s

1 2 3 4

The Universal Mobile Telecommunications System (UMTS) introduces the next generation of mobile telecommunication and currently steps into the future of feature-rich and powerful wireless services. Its limited availability in Europe at present prevents any prototype usage for mobile sensors. But a glimpse into the future shows sensors providing not only text and value based measurements, but also audio and video streams. Another important step during the design of a mobile wireless sensor node is to dene data formats that are suitable for the scenario, easy to use and allow for future changes and improvements. At this time, the imperative choice for this is XML - a exible, human readable, easy to use and future-proof le format, that can be seen as a universal language between entities of dierent kinds [7]. Thus, a sensor node should store its data using XML les regarding standardized - or at least widely agreed - XML schemas. Using XML enables dierent clients to access the data gathered by the sensor nodes, regardless of their operating system or programming language. It is therefore necessary to dene some XML schemas that are exible enough to be used in various sensor

Markus Hillenbrand et al.

scenarios and simple enough to become a commonly used data format. This will be explained in more detail in section 4. The probably most important aspect to regard creating sensor nodes is security. The Internet Engineering Task Force IEEE considers the abbreviation AAA [6] be a major task in current and future distributed systems: authentication, authorization and accounting are increasingly important as devices and services are becoming more and more ubiquitous. In the case of sensor nodes - which obviously may dene some kind of service to protect - data security, secure data access and data encryption should be used wherever applicable.

Hardware Conguration

Now that possible hardware and software technologies have been outlined in the previous sections, this section describes the hardware chosen to realize the prototype of a mobile sensor node. Three major elements can be found inside the prototype: a Beck IPC@Chip embedded micro-controller, a u-blox GPS chip, and a IC109 control chip. Figure 1 shows the locations of important components within the prototype.

Fig. 1. The prototype: (1) u-blox GPS chip, (2) control chips, (3) serial interfaces, (4) LAN interface, (5) external I2C bus, and (6) Beck IPC micro controller.

The Beck IPC SC12 is an integrated (embedded) controller - a miniature high-tech combination of hardware and software. The software consists of a realtime multitasking operating system (RTOS) with a le system, a TCP/IP stack and a hardware abstraction layer. Its two asynchronous serial interfaces (X101) or its I2C bus can easily be used to operate on appropriate sources or to observe resp. collect data measured by attached devices. Additional features are

Web Services for Sensor Node Access

a 10Base-T network interface, a synchronous serial interface, and fourteen programmable I/O pins. The controller itself is a 80C186 and 80C188 compatible 16 bit micro-controller running at 20 MHz; the necessary power supply is 5 V. The u-blox GPS-MS1E chip installed in the prototype is directly connected to the SC12 micro-controller via one of the serial interfaces. It provides several GPS output formats and three dierent operating modes: in Normal Mode, the module is continuously running as long as the operating voltage is supplied and the position xes are generated at the maximum update rate. In Trickle Power Mode, voltage is continuously supplied to the module and a software congurable internal timer periodically forces the module to acquire a position x. In between, the module remains in an ultra-low power sleep mode. In Push to Fix Mode, the GPS chip sleeps until an external request wakes it up and initiates a position x. This mode is best used for applications where no periodical position xes and low power consumption is required.

BUS

Module: Temperature

LCD

X101 Board
GPS SC12 IC109

Fig. 2. While the mobile device itself contains the micro-controller and the GPS chip, all external sensors are attached via a bus module with several addressable connection points.

As the prototype has only one serial interface that can be used (the second is connected to a PC for programming and debugging purposes), the third important component on board is a IC109 control chip that allows for switching between the element connected to the port at the outside and the internally attached GPS chip. In order to attach more than one sensor to the serial port of the prototype, a special bus-module acts as a connection switch: all elements connected to it have an address and can be accessed asking the bus module with the correct address. Depending on the conguration of the prototype board it-

Markus Hillenbrand et al.

self, it is thus possible to access the whole sensor device using a PC, to monitor its state on a serial terminal or to operate in the normal application mode. Picture XXX shows how the elements of the prototype work together, the two most important parts will be explained in more detail now. 3.1 Accessing the GPS Data

As the GPS chip uses its own default conguration at startup time, it has to be congured to fulll the needs of the system. This includes switching to the NMEA-GPGGA protocol, that contains all the information needed to retrieve the current spatial coordinates (time, latitude, longitude and height above main sea level). It is then possible to send a special command to the GPS chip (using an application programming interface API for the C programming language) to retrieve the current position through the serial port on demand. The GPS coordinates are then available as a string and can be processed further. 3.2 The Temperature Module

The temperature module SMT160 attached to the mobile device as a prototype operates on a 5V input and oers its measured data digitally or analog (no A/D converter is needed). Its absolute accuracy lies within 0.7 and its range of operation is -45 to 130 while its power consumption is below 1 mW.

Data Flow and Software Architecture

While the hardware presented in the last section is responsible for data acquisition, the software running on the Beck IPC micro-controller collects and manages the data. Now, four important steps in this data processing will be presented in detail: data collection, data preparation, data transfer, and data security. 4.1 Collecting and Preparing Data

The basic task for the Beck IPC is to collect all data measured by the connected sensors, annotate it with the correct location data coming from the GPS chip on board and store it for future use. At startup, the software registers all connected sensors and starts some threads responsible for collecting the data at suitable and congurable intervals. The data is then stored as an XML le onto the le system of the chip. These XML les are simple, but powerful: it is possible to store any imaginable sensor information using the corresponding XML schema. The following excerpt from the XML schema shows the simple construction of a measured value: ... <xs:element name="measurement" maxOccurs="unbounded"> <xs:complexType>

Web Services for Sensor Node Access

<xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="type" <xs:attribute name="datatype" <xs:attribute name="unit" <xs:attribute name="datetime" <xs:attribute name="position" </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> ...

type="xs:string" /> type="xs:string" /> type="xs:string" /> type="xs:dateTime"/> type="xs:string" />

A measured value contains information about the value type, the data type, the unit, the date and time of measurement and the position of the device at that time. An example for a current wind strength measurement might be as follows5 : ... <measurement type="WindStrength" datatype="int" unit="km/h" datetime="Mon Jul 7 12:36:29 CEST 2003" position="$GPGGA...*73">10 </measurement> ... As disk space is limited on the prototypes le system, only a xed number of measurements can be stored for each attached sensor. This value is congurable, as is nearly every aspect of the data collection phase.

Mobile Device
id sources uptime

Source n Source 1
id description type status refresh rate measurement

Measured Values

Fig. 3. Every mobile device can be equipped with several sensors (source 1..n) which collect the data.

To enhance readability, the GPGGA-GPS string has been shortened; a real value would be something like GPGGA, 180432.00, 4927.000000, N, 0744.000000, E, 1, 05, 1.0, 210.00, M, -31.81, M, 4.2, 0555*73.

Markus Hillenbrand et al.

4.2

Transferring and Securing Data

After the data being prepared and stored, it should be made available to clients in order to operate on it. There are two possible ways to achieve this: either the clients contact the sensor nodes directly, or they access the data by using some kind of middleware. The prototype introduced here oers both methods. As the Beck IPC operating system includes a small Web server, all data gathered by the sensors can be accessed through the HTTP protocol. The XML les containing the measured data are stored in sensor specic subdirectories on the Web server and can be downloaded by any client. The second - and more reasonable way - is to use a dedicated software instance on the Internet to access or query the sensor data. This specialized middleware manages all mobile sensor nodes on one side and oers their collected data to clients on the other side. To accomplish that, a data transfer from the sensor nodes to the middleware has to be established. The process of transferring the data is divided into three major steps: login, data transfer, and logout. During the login phase, a sensor device registers with the middleware and exchanges conguration data about the number of attached sensors, its identication, its online time and its administrator. The middleware then creates corresponding update threads that are responsible for the data exchange and synchronization itself. All data is then regularly fetched from the sensor node and stored into a database system persistently.

Login (once)

Mobile Device

Query current values (regulary) Logout (once)

Fig. 4. The data ow of the system contains a login/logout phase and a repeating data transmission phase.

Whenever a mobile sensor device goes oine - for maintenance or conguration changes etc. - and discontinues to collect data, it can start a logout process which frees the resources provided by the middleware and stops the regular data exchange threads. All the previously collected sensor data remain in the database system of course. This logout process can also be initiated by the middleware in case of a failure. As data security plays an important role in distributed environments like sensor networks, it is inevitable to use appropriate means to protect the sensor

Middleware

Web Services for Sensor Node Access

devices against intrusion and to secure the communication with the middleware. As depicted in section 2, authentication and authorization form the main part of access control, while encryption is responsible for security during data transmission. The prototype uses access control lists to perform authorization and a username and password based authentication model because of its limited computing power and storage capabilities - and unfortunately data encryption is not advisable here, either. But with the ongoing miniaturization in embedded devices technology, this will be possible in the near future.

Accessing the Data using Web Services

While the communication between the middleware and the sensor nodes has been realized using simple XML over HTTP communication, the client side of the middleware can oer more exible, enhanced and secure mechanisms to transfer and access the data. The most recent development in distributed computing and the most promising approach for future distributed systems is the Web Service architecture [4]. Here, a software entity oers its services on the Internet by describing them using the Web Service Description Language WSDL - a standardized XML le format [8]. The software is running on a server; it can be identied by a URI and can be accessed via the Internet, mostly using SOAP6 over HTTP - utilizing MIME encoding extensions for binary attachments where necessary [9], [10]. Thus, Web Services are loosely coupled and independent of the underlying platform (operating system, tools and programming language). The services oered by the prototype include data access for each mobile device and its connected sensors. It is possible to receive data for dierent query parameters like device ID, time period, position, type of data, or any combination of these. A provided Java API can be used to easily access the Web Service from within Java programs. It is thus possible for software clients to retrieve the data they need to compute their models or create their charts. One special service of the middleware is to detect sensors within the range of a mobile clients. Such a client can ask the middleware to present all data from all sensors that can be found within a specied radius; the mobile client can thus be made aware of the environmental data around it. Additionally, this service is event driven which means that while the client is still moving it receives updates about new sensor nodes or sensor data. As client and server use a more powerful hardware and software, all aspects of AAA can be applied [6]. The client communication with the middleware can be secured using data encryption and data access can be managed using high level authentication and authorization techniques, e.g. using certicates. The middleware also allows for accounting in many dierent ways. It is possible to use some kind of at rate, pay for device access, or even calculate the costs for a single measurement. It lies within the usage scenario to dene which accounting techniques to use.
6

Up to version 1.1 known as the Simple Object Access Protocol.

10

Markus Hillenbrand et al.

Conclusion and Future Work

This work has shown a scenario where mobile devices equipped with sensors and a dedicated middleware build a system to gather and manage sensor data and support simulation models in various ways. As currently hardware becomes more integrated - like GPS and GPRS chips - smaller and less power consumptive sensor nodes can be realized. Connected to the Internet, the data gathered by these mobile wireless sensor nodes can be easily integrated into client applications. Using a Web Service enabled middleware architecture with vast management functionality, access and management of sensor data becomes even more attractive to programmers and software vendors. Because of its independence of operating system, programming language or programming model, Web Services in combination with XML make it easy to use sensor data in applications - and will probably provide a standardized interface in the future. During the development phase, it became obvious that a lot of ideas - especially Web Services and an enhanced security model for the mobile device - could not be realized due to the limited processing power and le system space on the Beck IPC micro-controller. The solutions found are practical but need a lot of eort. The development of the middleware on the other side showed, that the use of current technologies like XML and Web Services allow for easy integration and modularization, and additionally provide more exibility and extensibility. With ongoing miniaturization in chip design, computer technology and measurement techniques it will sooner or later be possible to run more advanced software components on the mobile devices. This will certainly lead to a better and less purpose-built integration of such devices into sensor networks scenarios.

References
1. Jerey Hightower, Gaetano Boriello: Location Systems for Ubiquitous Computing, IEEE Computer (August 2001) 2. Estrin, Girod, Pottie et. al.: Intrumenting the World with Wireless Sensor Networks, International Conference on Acoustics, Speech, and Signal Processing (ICASSP May 2001), Salt Lake City, Utah 3. Friedemann Mattern, Kay Rmer: Drahtlose Sensornetzwerke, Informatik Sprektrum 20 (June 2003) 191194 4. Oliver Stiemerling: Web Services als Basis fuer evolvierbare Softwaresysteme, Wirtschaftsinformatik Nr. 44 (2003) 435445 5. A. Savvides, F. Koushanfar, A. Boulis et. al.: Location Discovery in ad hoc wireless networks, Networked and Embedded Systems Laboratory, UCLA (June 2000) 6. IETF: AAA-Charter (2003), http://www.ietf.org/html.charters/aaa-charter.html 7. W3C: XML Schema (2001), http://www.w3c.org/TR/xmlschema-0 8. W3C: WSDL Specication (2001), http://www.w3c.org/TR/wsdl 9. W3C: SOAP Specication (2000), http://www.w3c.org/TR/soap 10. W3C: SOAP Attachments (2000), http://www.w3.org/TR/SOAP-attachments 11. European Union: Directorate-General for Energy and Transport: European Satellite Navigation System, http://europa.eu.int/comm/dgs/energy transport/galileo/