A multi-hop implementation in Wireless Sensor Networks

Dr. Miguel Sánchez López

Computer Engineering Department
Universidad Politécnica de Valencia, Spain
e-mail: misan@disca.upv.es
Rasmus Thielke & Borislav Cvetkov
University Of Applied Sciences, Osnabrück
Thomas Holick
Deutsche Telekom Hochschule für 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 em-
bedded 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