Leipzig Paper

A multi-hop implementation in Wireless Sensor Networks Dr. Miguel S´anchez L´opez Computer Engineering Department Universidad Polit´ecnica de Valencia, Spain e-mail: [email protected] Rasmus Thielke & Borislav Cvetkov University Of Applied Sciences, Osnabr¨ uck Thomas Holick Deutsche Telekom Hochschule f¨ ur Telekommunikation, Leipzig November 15, 2008

Abstract Short-range wireless communication embedded on sensor devices enables a new type of networks. These networks of sensors allow data gathering at a scale never imagined before. Different issues make this type of network quite different from general purpose data networks. This paper details a real case implementation of such a network using off the shelf components and open source software for office environment monitoring.

1

Introduction

This paper presents the design and implementation of a low-cost Wireless Sensor Network (WSN) based on the combination of easily available components. There have been many developments in the area of wireless sensor networks made of tiny nodes. One popular project is Berkeley’s Mica Mote[1] that could run TinyOS[2], an specially crafted operating system for creating concurrent programs for embedded sensor networks. Based on this project’s success others have offered either compatible hardware or proprietary alternatives for both hardware and software. Our project followed a different path, we wanted to have a wireless sensor network as open as possible but keeping the hardware and specially the RF design to a minimum. This requirement came from the fact that most of the project is carried out as final thesis by some of our students. Cost was also an issue here as we wanted to keep development and deployment costs to a minimum as our budget is quite limited. This wireless sensor network is aimed at monitoring office space to improve the energy efficiency of the buildings. A wireless sensor network is very easy to deploy inside of a building and it can be done in no time by non technical staff.

1

Figure 1: (left) wireless sensor network, (right) system architecture

2

Network architecture

The focus of our project is on ”sensor networks” that gather data from the environment and send it to a central facility for storage and presentation. Therefore, our data flow is only concerned on sending sensor data towards that central location we called coordinator. While a general purpose network may need to provide any-to-any communication, our network is concerned only with sensor-to-coordinator data flow, which simplifies routing problem. Another important aspect of our network is that nodes are battery operated, which means that nodes need to be in sleep mode most of the time in order to achieve a considerable battery duration. This aspect may make routing a bit trickier though. All network nodes have a IEEE 802.15.4 low-power wireless interface that offers a basic one-hop media access control (MAC) layer service. Addresses may be 16 or 64 bits long.

There is a special node in the

network we call coordinator that gathers all data coming from the rest of the nodes. Coordinator node also stores gathered data for further analysis. A web application is also hosted by the coordinator node. This software allows authorized personnel to access all the available information in a convenient way.

3

Routing algorithm

For the network to offer a mid-range communication over short-range links it is mandatory that each network node acts as a forwarder of other node’s traffic. In this WSN the difference between end-systems and network core is blurred and each network node also acts as a router. This approach allows the network to be self sufficient and easily deployable. However this imposes a tougher job on network nodes too. Nodes have to build a forwarding table to be used for other node’s traffic but given the dynamic nature of our network (i.e. new nodes may be deployed, old ones may run out of battery, etc) forwarding tables need to adapt quickly to network changes. Our approach to the problem is to deploy a very simple distributed algorithm that helps us to create a forwarding tree rooted on the coordinator node. This tree is built based on the transmission of a special control packet called ”beacon”. The source of beacon packets is the coordinator node. Beacon packets do include a field that holds a count and a second field with a unique identifier. The initial value for that field is zero. Each beacon packet

2

Figure 2: Beacon message being broadcasted transmitted by the coordinator has a count value of zero. Network nodes (other than coordinator) receiving a beacon will retransmit a copy of it after increasing the counter field if the beacon identifier is a new one. Nodes receiving beacons with a known (old) identifier will do nothing. A node that receives a beacon with a new identifier for the first time will store the source MAC address of the sender as the next-hop node in its forwarding table. On the other hand, when a node receives a data packet (not a beacon) it will forward it unchanged to the next-hop address of its forwarding table. If the next-hop address equals the initial value of zero then data packet will be forwarded to the broadcast address (all bits to one). Thus routing table is built and maintained by the beacon packets and data packets are routed using routing tables to the coordinator. To ensure the desired routing convergence rate, the coordinator will send periodically beacon packets.

4

Sensor network administration and management

To use the sensor network in an efficient way a Java-based application was written to receive and store sensor data at the coordinator node. The goals of the application are to store and to analyze the sensor data and to manage the whole sensor network. The application manages the available network sensors and the administrator can setup the sensor network, specifying the location and type of each sensor. A wireless sensor network may host several sensors for different magnitudes, like temperature, humidity or light level, all this is configured using management tools of this application. Real-time monitoring of sensor values is also possible from the administrative interface. Figure 3 shows some screenshots from the administrative

3

Figure 3: Several screenshots of the application

Figure 4: Floor plan with sensors shown as red circles interface.

5

Web-based monitoring application

Besides the administrative interface, the system may consist of a web-based interface.

This makes the

wireless network information available anywhere on the Internet. Data is presented in a friendly way, making use of graphs and charts instead of table views of data rows. Users may access desired data not only of individual sensors but also averaged values. Web interface was built around a classic LAPP (Linux, Apache, PostgreSQL –instead of the more popular MySQL– and PHP). All the components are open source software and, if needed, it can run also on Windows instead of Linux. Data is accessed by choosing the desired building and then user can select the desired floor level. Once a floor has been selected the user is shown the floor plan where sensor nodes appear as clickable red circles. Sensor status and data can be obtained by clicking on the desired sensor. It is also possible to access node information directly from a drop down menu. Real time monitoring is also possible, and the user may choose the time period for the averaging of the value, if any.

4

6

Sensor Hardware

Our wireless sensor devices consist of two circuit boards. One of these contains the power adapter, USB/serial modem connections and the main microcontroller (ATMega168), and the other board hosts the XBee embedded radio RF module. While XBee modules do have 6 different analog and 6 digital I/O ports they are not being used in the project. Instead three analog inputs on the main microcontroller are connected to three sensors: temperature with (LM35), relative humidity (808H5V5) and light intensity (using a small CdS LDR). The XBee circuit board contains a MC13193 RF chip from Freescale and a HCS08 MCU for data processing. These modules support IEEE 802.15.4 PHY and MAC layer. Arduino[3] is a project of open source hardware. Arduino was designed to provide artists a cheap and easy platform to develop interactive installations. Being open source hardware means that everything from the schematics to the printed circuit board to the development environment are open and freely available. This features and the fact that it is a well thought-out system made it an instant success. Arduino developers started a company to market these devices to people not interested on building themselves. It seems they have sold tens of thousands of Arduinos now. There are also clones made by other companies too. Later on, some students decided to create a wireless interface based on XBee modules. These are not open source hardware but fully documented and cheap too. The combination of Arduino and XBee[4] wireless interface was called Squidbee[5] and these students started a company too. We used these components as the building blocks of our network because they were cheap, documented and easily available. Unfortunately a closer inspection revealed that electronic design put not a lot of effort on achieving low power consumption. That means that a 9V battery powering one sensor node will last less than three hours of continuous operation. This time can be elongated if power down modes are used on Arduino processor and on XBee module. Again, the original design made use of serial voltage regulators that leak around 5mA each one no matter the microcontroller is running or sleeping. This translates into a poor sensor life if battery operated (i.e. hours instead of months or years).

7

Conclusions and future work

Three different students worked to make this project possible. A working prototype has been built and different software pieces have been developed. There are still some open issues, mostly getting a version of the hardware that offers a decent performance when powered with a battery. To achieve a long battery duration nodes need to be powered down most of the time. It is needed to synchronize the wake up times of nodes with the moment when data is transmitted so data can be forwarded to the coordinator each time nodes wake up. While the project did not focus on sending data back to the nodes from the coordinator, it is easy to envision that data can be sent to any node using the beacon packets as a vehicle. A future project will explore the adaptation of existing ad-hoc routing protocols to this wireless sensor network.

References [1] http://www.xbow.com/Products/Product pdf files/Wireless pdf/MICA.pdf

5

[2] http://www.tinyos.net/ [3] http://www.arduino.cc/ [4] http://ftp1.digi.com/support/documentation/90000982 A.pdf [5] http://www.squidbee.org

6