Wireless Sensor Network Testbed on Public Lighting Infrastructure Miha Smolnikar, Carolina Fortuna, Matevž Vučnik, Marko Mihelin, Mihael Mohorčič Department of Communication Systems Jožef Stefan Institute Ljubljana, Slovenia
[email protected]
Abstract—This paper introduces a new outdoor testbed for Wireless Sensor and Actuator Networks (WSAN) deployed on the public lighting infrastructure. Currently it consists of 25 sensor nodes attached to light poles and 2 gateways, one for xDSL and the other for GSM/GPRS. The sensor nodes control dimming of the public LED lights and collect temperature, humidity, pressure, luminance and battery voltage measurements. The sensor nodes and gateways are implement on a Versatile Sensor Node (VSN) platform running a proprietary networking protocol for their interconnection. VSN is a fully modular WSAN platform featuring a powerful microcontroller, custom power supply with battery charger and optional solar cell extension. It supports numerous on board peripherals to cover different application requirements as well as several communication technologies to realize local sensor network and implement gateways to other existing fixed or mobile networks. The data is gathered, processed, stored and exposed by the Global Sensor Networks (GSN) middleware, which enables fast deployment and addition of new nodes in the network as well as basic web-based visualisation of data. It is designed to separate metadata from data in order to allow efficient use of semantic and data mining technologies. Keywords-Wireless Sensor Network (WSN), Public Lighting, LED Lighting, Versatile Sensor Node (VSN), Middleware
I. INTRODUCTION In accordance with the Internet of Things (IoT) paradigm, Wireless Sensor and Actuator Networks (WSAN) are evolving from dedicated typically homogeneous small scale networks to heterogeneous large scale networks of shared resources. Thus they are becoming an important part of the environment we live in. The scale and heterogeneity call for appropriate sensor network testbeds in order to gain necessary experience from real-life deployments and operation. In recent years, sensor deployments gained popularity especially in the area of environmental monitoring. Sensors are typically connected to or featured on sensor nodes, which collectively form WSAN and generate large amount of data, which is then analyzed and used by scientists and public communities. Several research WSAN testbeds exist already. However, most of them are deployed indoor and their size is relatively small, except for TWIST from TU Berlin, which supports 204 mostly Tmote Sky nodes. Outdoor testbeds are
less common due to higher deployment and maintenance costs. In the Swiss Experiment, several research groups from areas such as environmental monitoring and computer science collaborate for deploying and maintaining monitoring stations in the Swiss Alps. The deployment consists of over 4000 sensor streams, but the testbed is mostly manually maintained by several groups. CitySense is an outdoor testbed with 100 wireless sensors deployed across the city of Cambridge, USA. Each sensor node consists of an embedded PC with 802.11a/b/g interface. The Copenhagen Wheel project seems to be one of the few mobile outdoor sensing experiments in which sensor nodes are embedded into the bicycles’ wheels [1]. This paper presents the components, functional operation and experiences gained in the deployment of outdoor WSAN testbed on the public lighting infrastructure, in the Gorica region of Slovenia. Currently it consists of 25 sensor nodes mounted on the public light poles, but it is planned to grow to 100 nodes by mid-2011 and subsequently up to several hundred nodes. It is based on the use of Versatile Sensor Node (VSN) platform running a proprietary networking protocol. The nodes are equipped with sensors for temperature, humidity, air pressure and light intensity, and capable of dimming the lamps individually. The rest of the paper is structured as follows. Section II briefly describes the characteristics of public lighting infrastructure and requirements for the sensor network. Section III provides architecture and functional blocks of the testbed, as well as discusses possible use cases. Section IV concludes the paper. II.
WIRELESS SENSOR NETWORK ON PUBLIC LIGHTING INFRASTRUCTURE Public lighting represents roughly 20% of world electricity consumption, which is driving the worldwide policy to outlaw the inefficient incandescent lights. In EU the phase out period ends in 2015. With the Light Emitting Diode (LED) luminous efficacy approaching 100 lm/W, this technology is becoming attractive for mass market production in general lighting sector. Besides efficiency, LED advantages include also long lifecycle, high degree of light directionality, robustness to shocks and vibrations, compact form factor, lack of ultraviolet spectrum and inherent support for dimming and powering
through renewable energy sources (i.e. solar cell and battery combination). In this respect, figures show that up to 40% savings in electricity consumption can be achieved by replacing old lamps with LED technology, while additional 25% saving could be achieved with intelligent dimming. Besides direct economic savings due to reduced energy consumption, mutual benefits include lower CO2 emissions and reduced light pollution. If LED technology represents one of the biggest opportunities in public lighting sector, coupling this infrastructure with communication networks opens a portfolio of new applications. As to communication, sensor networks seem to represent a direct-fit technology, with the possible communication media being wireless and power-line. Since the latter is quite complex and not always suitable for application in existing infrastructure, we focused in the testbed on the evaluation of wireless solutions. Currently, we deployed a sensor network running a proprietary protocol, whilst ZigBee and Wireless M-BUS technologies, operating the 2.4 GHz and 868 MHz frequency bands respectively, are considered for future deployments. III. TESTBED ARCHITECTURE The public lighting architecture is depicted in Figure 1 and it consists of three main functional blocks: (1) the network of sensors; (2) middleware; and (3) data/application. In the following subsection we present the VSN platform, which presents the hardware foundation for the implementation of sensor node and gateway functionalities. That is followed by subsections describing vital parts of the overall testbed architecture. A. Versatile Sensor Node Platform One of the aims of the public lighting WSAN testbed is to investigate the use of custom hardware that is fully reconfigurable and offers easy prototyping of investigated applications and mash-ups. At this stage of deployment we are using a VSN platform, which has a modular structure and can be quickly adapted to various applications. The core module (VSC) is based on a powerful 32-bit microcontroller with ARM Cortex-M3 low-power high performance core. The actual microcontroller used is STM32F103 with the maximum clock frequency of 72 MHz, 64 kB of RAM and 512 kB of Flash memory. There is an additional 128 kB of fast FRAM and the possibility to use miniSD cards to store larger amounts of data. VSN supports digital interfaces such as I2C, SPI, UART, USB and analog interfaces, 12-bit ADC and DAC. The node has various power supply options, including mains, batteries with on-board charger and optional extension for solar cells. For energy saving it supports three low-power states, i.e. sleep, stop and standby, plus additional deep hibernate low-power state in which the circuit consumes below 7 µA. The sensor network radio used in the testbed configuration is XBee-PRO which works in the 868 MHz industrial, scientific and medical (ISM) frequency band. It is interfaced on one of the radio modules (VSR) with antenna and has indoor or
Figure 1. Testbed architecture
urban range of up to 500 m and the range of 40 km in ideal line-of-sight conditions with dipole antenna. The basic VSC and VSR modules can be extended with an expansion module (VSE) which defines the node functionalities and is custom designed for each application. In the testbed configuration the gateway nodes’ VSE implements Ethernet interface, which can be interfaced either to xDSL or GSM/GPRS modem. On the other hand, sensor nodes’ VSE modules comprise (i) sensors for measuring temperature, humidity, pressure, luminance and battery voltage; (ii) an actuator for light dimming; and (iii) a safety circuit. Light dimming is controlled with respect to luminance measurements, where some of the nodes have two sensors to increase accuracy; one directed to the sky and the other to the ground. B. Sensor Network Protocol Currently the testbed consists of two sensor networks with star topology. Sensor nodes are connected to the coordinator node, which also serves as xDSL or GSM/GPRS gateway. The role of the coordinator is to monitor the local sensor network, discover sensor nodes, acquire data, set the configuration (e.g. dimming) of sensor nodes, and communicate with the server. Sensor nodes respond to coordinator requests, control the light and handle power management. Since electricity is in the current setup only available during the night, when the light is on, sensor nodes operate on batteries during daytime and charges them during the night. The proprietary sensor network protocol is based on pooling. After power-on or reset and then periodically every 30 s, the coordinator node broadcasts node discovery message containing its address. This is followed by the binding process, when nodes respond with a special status message, which contains node’s address, status and settings. The status currently contains power supply state (battery/charging/ external), while settings refer to the light being powered on or off, and to the dimming level (0-100%). Upon receiving a node status message, gateway adds a node to its network table. Following the network setup, the coordinator obtains sensor measurements or sets the sensor nodes’ settings by sending appropriate unicast messages. Upon reception of request, sensor nodes perform measurements and respond with a data message. The response time is up to 0.5 s. The coordinator appends a time stamp to the data message and forwards it to the server. To perform gateway functions, coordinator upon obtaining an IP address, periodically reports its status to the server. This is especially important for control purposes, where the server side application sends requests for sensor network.
Since sensor nodes do not send the data only to particular coordinator, these are easily interchangeable and can cover for each other’s failures. Which coordinator pools which sensor nodes in the vicinity is managed by the server-side management of coordinators’ network tables. C. xDSL and GPRS Gateways For relaying the data from sensor network to the middleware application on the server a specifically outfitted VSN platform was used as a gateway. Its VSE module is built around a Serial-to-Ethernet module, the Lantronix XPort. This module allows the gateway to communicate with a HTTP server directly through UART interface, without the need of a TCP/IP stack running on the microcontroller. The XPort behaves just as a regular modem and it can be controlled with standard AT command set. Due to increased power demands from the XPort module, the VSE is also equipped with an additional power supply. Where land line infrastructure is available, this configuration is connected to an xDSL modem, while GPRS modem is selected where only cellular network is an option. D. Sensors and Actuators Three different sensors were used to gather environmental data. SHT11 is a digital temperature and relative humidity sensor that connects to the VSN via a proprietary interface similar to I2C. SCP1000 is a digital absolute pressure and temperature sensor with an SPI interface, and TLS2561 is a luminance sensor and connects to VSN with an I2C bus. These sensors are mounted on a PCB outside the sensor node protective box. The PCB and sensors are encased in epoxy resin for weather proofing, with only the “measurement holes” of the sensors exposed to the environemnt. The dimming of the lights is accomplished with a 1-10 V DC interface that is supported by the manufacturer of the lights. The dimming control voltage is generated with a pulse width modulation (PWM) function of the VSN. The modulated waveform is averaged with an RC filter and multiplied so it matches the interface voltage. The duty cycle of
Figure 3. Middleware stack
the PWM waveform is equal to dimming of the light. A hardware watchdog is added for cases of VSN hardware or software failure. A second watchdog waveform is created using software toggling of a VSN output. This waveform controls a relay that disconnects the dimming control interface of the light in case of VSN failure. E. Middleware In general the middleware is used to link the heterogeneous sensor node level of the WSN infrastructure with the application level. It has to support the development, maintenance, deployment, and execution of sensing-based applications [2]. This includes communication with the sensor network; data aggregation so that it can be linked back to the source; and provision of high-level abstraction of heterogeneous nodes. Another equally important issue is scalability, since middleware services must be capable of maintaining acceptable performance levels as the network grows [3]. Middleware can be placed on different levels of WSN infrastructure. There are however two popular abstraction levels for the middleware. First one is on the node level and second one is on the border level using conventional servers. In the first case we have database-like solutions where the database is distributed over the sensor network so that it abstracts the network giving the user the SQL like interface for extracting the sensor data. Examples of solutions that adopt this approach are TinyDB and COUGAR [4]. The border level approach separates the sensing network from data management which relieves the nodes so they can be more power efficient. Such examples are Senceive [5] and Global Sensor Networks (GSN) [6]. In the border approach sink nodes are used to reliably deliver sensed data the middleware. A sink node is a node which is connected to a more powerful base computer which runs middleware [7]. For data storage the conventional databases are used which can handle large amounts of data. Since we would like to collect from the environment as much data as possible we propose our middleware stack which is based on GSN, but it is designed to evolve over time in a custom middleware so that GSN will no longer be needed. It includes message server, database, GSN and Miner [8]. The message server communicates with the sink node over HTTP protocol. As depicted in Figure 2, the server periodically receives measurements from the sink node and multiplexes it in the required format to the receivers which are GSN, database,
Figure 2. Database schema
and Miner. The GSNs’ key abstraction is a virtual sensor [7] which enables the user to specify XML-based description of sensors or of entire sensor nodes. Furthermore, virtual sensor can be anything from a mobile phone, internet camera or some other data source. For the processing of the input data streams, GSN uses wrappers which adjust the data received from the data source into the standard GSN data model. The idea is to enable the user to build a data-oriented “Sensor Internet” consisting of sensor networks connected via GSN [7]. Our implementation uses CSV wrapper for data adjustment. The data is coming in raw streams and the metadata is stored in the virtual sensor. Thus we avoid additional overhead in data streams. Furthermore, GSN includes a web server for publishing the data and plotting graphs, and it also provides an option to download the data in various formats. The database used for archiving the measurements is designed to be closely related to the hardware design in which the sensor node features a set of sensors. The database schema is composed of four tables, as shown in Figure 3. The three upper tables, Sensor Node, Sensor and Sensor Type store the metadata describing the physical devices and the phenomena observed. The Sensor Node Table stores information about each sensor node deployed in the network, providing unique IDs, text descriptions and geo-location coordinates of the deployed sensor nodes. The Sensor Table is used to uniquely identify the sensing devices attached to sensor nodes. The description of sensing devices is provided in the Sensor Type Table, which contains information about the physical device used and the phenomena it observes. The lower table stores the sensor measurements with their timestamp, numerical value of the measurements and the corresponding sensor ID. The metadata and data are separated in this way to avoid overhead in the database. However, each measurement can be linked back to the sensor (through Sensor ID) and to the node (through Sensor Node ID) when needed to retrieve the full context. This kind of separate data and metadata management makes it easy to establish previously mentioned virtual sensor networks on higher levels of abstraction. GPS coordinates are stored as metadata in this implementation as all the sensor nodes used in our work are fixed at this point in time. However, once sensors are mobile, the GPS modules themselves will be considered sensors and their measurements will be saved in the Measurement Table. Each sensor node can have several sensors attached to it. Currently our testbed contains sensor nodes where each node has six sensors. Multiple sensors on the same node can be of the same type and they could measure the same phenomena (e.g. temperature). Generally, the number of sensors on one node is not fixed and it can vary between nodes. The last part of the implemented middleware is Miner, which is a large scale data mining toolkit developed at JSI. We use it for building mash-ups1 on the application level. Miner scales over millions of measurements and gives the result in real-time when we request to plot the graph. Data is fed to 1
http://sensors.ijs.si/
Miner by the message server, but Miner loads from the database only the current data, archived data and metadata. The fast response is especially important when we plot graphs (e.g. temperature graph for one year). Our mash-up is a combination of web services regarding the testbeds we have. There is a geographic map with positions of sensor nodes and by clicking on the node we get different options of plotting graphs. The graphs can be plotted by day, week, month or year. Thanks to the Miner underneath the graphs are plotted in real-time. IV. CONCLUSION With the developments of LED technology on one hand and different initiatives and policy to enforce energy efficient products on the other, public lighting infrastructure is expected to be extensively modernised in the future years. Coupling LED-based public lighting with sensor network technology not only promises additional energy savings, but also opens a whole new space of applications. This motivated the deployment of WSN testbed on public lighting infrastructure that is presented in this paper. It consists of VSN-based sensor nodes running a proprietary networking protocol, measuring selected environmental parameters and controlling the light dimming. Through xDSL or GSM/GPRS gateways the testbed is connected to the server-side middleware application, which manages with the network, stores sensor measurements and offers different textual and graphical representations of data. ACKNOWLEDGMENT The authors would like to thank Miren-Kostanjevica Municipality and Envigence Ltd for hosting the testbed and SensorLab members for their support and valuable contributions. REFERENCES [1] [2]
[3]
[4]
[5]
[6]
[7]
[8]
N. Savage, “Cycling through data,” Communications of the ACM, vol. 53, no. 9, September 2010. K. Romer, O. Kasten and F. Mattern, “Middleware Challenges for Wireless Sensor Networks,” Mobile Computing and Communications Review, vol, 6, no. 2, October 2002. S. Hadim and N. Mohamed, “Middleware: Middleware Challenges and Approaches for Wireless Sensor Networks,” IEEE Distributed Systems Online, vol. 7, no. 3, March 2006. K. Henricksen, R. Robinson, “A Survey of Middleware for Sensor Networks: State-of-the-Art and Future Directions,” in Proc. of the International workshop on Middleware for sensor networks (MidSens’06), Melbourne, Australia, December 2006. C. Hermann and W. Dargie, “Senceive: A Middleware for a Wireless Sensor Network,” in Proc. Of the 22nd International Conference on Advanced Information Networking and Applications (AINA 2008), Okinawa, Japan, March 2008. H. Jeung, et al., “Effective Metadata Management in Federated Sensor Networks,” in Proc. Of the IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing (SUTC 2010), California, USA, June 2010. K. Aberer, M. Hauswirthy and A. Salehi, “Infrastructure for data processing in large-scale interconnected sensor networks,” in Proc. of the International Conference on Mobile Data Management (MDM2007), Mannheim, Germany, May 2007. B. Fortuna, C. Fortuna and D. Mladenić, “Real-time News Recommender System,” ECML/PKDD, Barcelona, Spain, September 2010.
