This action might not be possible to undo. Are you sure you want to continue?
Dr. Miguel S´nchez L´pez a o Computer Engineering Department Universidad Polit´cnica de Valencia, Spain e e-mail: email@example.com Rasmus Thielke & Borislav Cvetkov University Of Applied Sciences, Osnabr¨ck u Thomas Holick Deutsche Telekom Hochschule f¨r Telekommunikation, Leipzig u 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. Diﬀerent issues make this type of network quite diﬀerent from general purpose data networks. This paper details a real case implementation of such a network using oﬀ the shelf components and open source software for oﬃce environment monitoring.
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 that could run TinyOS, an specially crafted operating system for creating concurrent programs for embedded sensor networks. Based on this project’s success others have oﬀered either compatible hardware or proprietary alternatives for both hardware and software. Our project followed a diﬀerent 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 ﬁnal 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 oﬃce space to improve the energy eﬃciency 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 staﬀ.
Figure 1: (left) wireless sensor network, (right) system 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 ﬂow 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 ﬂow, which simpliﬁes 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 oﬀers 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.
For the network to oﬀer a mid-range communication over short-range links it is mandatory that each network node acts as a forwarder of other node’s traﬃc. In this WSN the diﬀerence 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 suﬃcient 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 traﬃc 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 ﬁeld that holds a count and a second ﬁeld with a unique identiﬁer. The initial value for that ﬁeld is zero. Each beacon packet
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 ﬁeld if the beacon identiﬁer is a new one. Nodes receiving beacons with a known (old) identiﬁer will do nothing. A node that receives a beacon with a new identiﬁer for the ﬁrst 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.
Sensor network administration and management
To use the sensor network in an eﬃcient 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 diﬀerent magnitudes, like temperature, humidity or light level, all this is conﬁgured 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
Figure 3: Several screenshots of the application
Figure 4: Floor plan with sensors shown as red circles interface.
Web-based monitoring application
This makes the
Besides the administrative interface, the system may consist of a web-based interface.
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 ﬂoor level. Once a ﬂoor has been selected the user is shown the ﬂoor 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.
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 diﬀerent 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 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 wireless interface was called Squidbee 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 eﬀort 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).
Conclusions and future work
Three diﬀerent students worked to make this project possible. A working prototype has been built and diﬀerent software pieces have been developed. There are still some open issues, mostly getting a version of the hardware that oﬀers 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.
 http://www.xbow.com/Products/Product pdf ﬁles/Wireless pdf/MICA.pdf
 http://www.tinyos.net/  http://www.arduino.cc/  http://ftp1.digi.com/support/documentation/90000982 A.pdf  http://www.squidbee.org
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.