1. Design of a Wireless Sensor Network from an Energy Management Perspective
Jinfu Zheng, Charles Elliott, Anand Dersingh, Ramiro Liscano, Mikael Eklund
Faculty of Engineering and Applied Science
University of Ontario Institute of Technology
2000 Simcoe Street North, Oshawa, ON, Canada
{Jinfu.Zheng, Anand.Dersingh, Ramiro.Liscano, Mikael.Eklund}@uoit.ca
{Charles.Elliott}@mycampus.uoit.ca
Abstract
It is common knowledge that Energy Management
(EM) is a crucial design criterion for wireless sensor
networks and it influences many software components of
a wireless sensor network. To facilitate the application
developer, EM algorithms at the physical and device level
are generally abstracted out by the Operating System, but
this is not sufficient. This paper presents the design of a
wireless sensor network for the acquisition of temperature
values from the EM perspective in particular from the
application layer perspective. Power measurements on a
wireless sensor node show that the energy consumption is
close to the theoretical and manufacturer’s posted energy
budget, but the predicted lifespan of the nodes when
placed in a network is not achieved. Explanations are
given of why the amounts are not exactly the same.
1. Introduction
SensIV (Sensor Infrastructure for Viticulture) is a project
proposed to monitor temperature variation in a vineyard.
Vineyards can experience frost damage to grapevines in
the spring and fall, and a freeze can do potential damage
to the quality of the wine or to the plant itself depending
on the type of frost and when it occurs. In order to
mitigate this risk, vineyard managers need to know or be
notified of temperature values near or below the freezing
point. Generally, thermal sensors can be used to measure
temperatures. However, temperatures in different heights
and areas within a vineyard are not the same. For
example, temperatures near the ground can vary by up to
10 degrees per meter [1] when a cold draft moves in.
Therefore, multiple temperature sensor readings at
different heights and locations are required. In addition, it
is also inconvenient to run wires across a vineyard this is
why a wireless sensor network (WSN) is preferred in
order to obtain a detailed temperature map of a vineyard.
Generally, a wireless sensor network for data collection is
composed of wireless nodes (motes), interfaced to several
sensors, and one or more base stations. Each node in a
WSN is called a “mote”, which is a wireless module
composed of a micro-processor and a wireless transceiver.
The mote itself requires a sensor board which acts as an
interface to the sensors. One or more sensors can be
connected to a sensor board. A network is formed among
all motes based on wireless communications. Motes are
programmed to sample data from sensors attached to
them. In turn, the data is packed into a data stream and
forwarded using multi-hop routing to one or more base
stations.
In outdoor monitoring, motes in a wireless sensor network
are powered by batteries [2]. This means that a wireless
sensor network is often designed for low power
transmission, low duty cycle, and low data rates in order
to prolong the lifetime or reduce the maintenance
overhead of the network. This paper presents the approach
taken in the design and development of a wireless sensor
network by which Energy Management (EM) was taken
into account as the primary design criteria, in particular it
emphasis the importance of EM design at the application
layer even when the operating system has implemented
EM at the physical and device layer.
As Klues et. al. [6] pointed out; EM is a critical concern in
low-power systems and therefore proposed an architecture
at the device layer aspect for handling EM so that the
details of EM are abstracted from the application
developer. This work leverages Klues et. al.’s approach at
the device layer but also takes EM into account at the
hardware and sensor application layer, because it is not
possible to abstract all EM decisions to the device layer.
For example, it is not possible to capture details of the
sensors’ functionality and acquisition rates until the
application is known. Also, the application layer has to
coordinate the operations between the sensor excitations
and the analog to digital converters (ADC).
The EM-based design is developed and implemented
using IRIS motes connected to an MDA 300 data
acquisition board servicing four temperature sensors for
each mote. All software implementation was done by
leveraging the TinyOS 2 programming environment that
supports EM abstraction for the motes and devices like the
MDA 300.

2. This paper reviews some related work in section 2,
presents the system architecture as well as an energy
budget for the sensor unit in section 3 to help decide the
power supply pattern. Section 4 presents details of how
power management was integrated into the design of a
sensor interface board, the device driver for an MDA 300
sensor acquisition board, and the sensor layer application
program of the wireless module. Section 5 presents some
test results and their corresponding discussions and finally
the conclusion is presented in section 6.
2. Related work
Environmental monitoring using wireless sensor
networks is now becoming common [2][3] and power
management in these sensors is always an important non-
functional requirement. We have found that there have
been few practical implementations and testing on real
wireless sensor nodes with respect to their energy
management models and actual power consumption,
except for the research work by Culler et. al [5][6][7].
An approach on how to integrate concurrency control
and energy management into device drivers was
introduced in [6]. One of the purposes of [6] is to relieve
applications from explicitly managing system energy
states. Concurrency is also advocated in [6] for
application design to allow the operating system to handle
the energy management. Nevertheless, we believe that
some energy management logic still has to be placed into
the application’s behavior. For example, in the SensIV
application, sensor excitation is enabled and disabled by
the sensor layer application because these operations
require application-specific knowledge. If we put this
logic in the device driver, the excitation enable and
disable operation should be set for each of the sensor
readings, which would result in an inefficient solution.
An energy budget is discussed in [2], but it is only used
as a goal to decide the top bound of a mote’s duty cycle
per day, while in this paper we compare the actual energy
consumption against the manufacturer’s energy table and
show that in reality one could be consuming 3x more
energy.
3. General design
The physical infrastructure in this wireless sensor
network is a multi-tier architecture by which wireless
nodes form a network communicating to a gateway. The
gateway acts like a bridge between the WSN and an
Internet-based service as shown in Fig. 1. In this scenario
each of the motes (nodes) is connected to 4 thermal
sensors. The goal is to collect temperatures values at
different heights on a vine including one underground
temperature value.
The motes used in this work are Iris motes from
Crossbow with TinyOS 2 [11] as an operating system.
TinyOS 2 was chosen since it is an open source operating
system and several networking protocols have already
been developed for wireless sensor networks and are
available in the TinyOS release. Each mote collects data
from its sensors and sends it to a base station (or gateway)
using a network layer protocol called Collection Tree
Protocol (CTP) [4]. The gateway service acts as an
interface between TCP/IP and the wireless (IEEE
802.15.4) sensor network. Data collection, monitoring,
and control is facilitated through a Web Service server
(SensIV). Commands from the SensIV server to the sensor
network are disseminated to each mote via the gateway
based on the Dissemination Protocol [9].
Fig. 1. Multi-tier wireless sensor network
The SensIV server supports a middleware layer which
includes a set of APIs to support application development
such as java and web applications in order to interpret,
process, and display data coming from the wireless sensor
network. In addition, applications can be further
developed depending on the users’ requirements such as
3D maps or alarming systems.
This paper though focuses on the design of a sensor
node from an energy management perspective.
3.1. Sensor node hardware components
The sensor node hardware components are composed
of: an Iris wireless module, an MDA300CA data
acquisition, a custom sensor interface, 4 temperature
sensors, a solar panel and associated charging circuit, see
Fig. 2. The Iris wireless module uses the Atmel processor
with 128 KB program memory and 8KB RAM. In terms
of radio communication, it uses 2.4GHz (IEEE802.15.4)
with a range of 500 meters (line of sight and outdoors).
This type of mote also supports a low-power mode for the
micro-processor, radio, and logger.
The MDA300CA data acquisition board from
Crossbow has expansion connectors for 7 single-ended or
3 differential ADC channels, and 4 precise differential
ADC channels with 2.5, 3.3, 5V onboard sensor

3. excitation. Also, it has 2 relay channels and an external
I2C interface.
Fig. 2. Photograph of the sensor unit
In terms of thermal sensors, the LM135 precision
temperature sensor was chosen. It operates between -55°C
to 150°C with temperature accuracy of ±1°C. The
working current of this type of sensor is 400uA to 5mA.
A solar panel was integrated to each mote to recharge
the batteries. The solar panel’s dimension is 80mm x
80mm and generates an output of 4.2V and at best 130 ~
150 mA.
3.2. Energy budget
Table 1 shows the energy consumption for an IRIS mote
and sensor board (model not specified) as listed by the
manufacturer [12]. The energy table is used later as a
bench mark to compare if the design taken can achieve the
manufacturer’s listed energy budget.
Electrical current consumptions are listed according to
the micro-processor, radio transceiver, logger, and sensor
board. When one estimates the current consumption of a
radio transceiver, the weights for receive and transmission
are set as 3/4 and 1/4.
Based on Table 1 and assuming that the read and write
operations of the logger are not enabled, and four sensors
are taken into account, approximately 24 mA current will
be drawn from the power supply (this includes the current
draw for the micro-processor, radio reception, radio
transmission, sensor board, and four sensors estimated
respectively as 6, 6, 3, 5, and 4 mA). If no energy
management is applied, the lifetime of a regular battery
with 2000 mA-Hr energy will be typically 3.47 days. Even
if one decreases the sampling period, it cannot
significantly reduce the energy consumption because the
radio reception and sensor excitation will always be on
even in the idle state.
Table 1. Energy consumption for the IRIS wireless
module and sensor
Currents Duty cycles
Value (mA) % mA-hr
Micro-processor (Atmega128L)
full operation 6 1 0.06
Sleep .008 99 0.008
Radio
Current in 8 0.75 0.06
Current xmit 12 0.25 0.03
Current sleep .002 99 0.002
Logger
Write 15 0
Read 4 0
Sleep .002 100 0.002
Sensor Board
full operation 5 1 0.05
Sleep .005 99 0.005
Total 0.217
Table 1 also lists the energy consumption if a 1% duty
cycle is used. This means that the necessary components
such as the micro-processor, radio transceiver, sensor
board, and sensors are only in an active state for 1% of the
time. The other 99% of the time, these components will be
in a sleep mode or in a switch-off state. In this case, the
average energy consumption is 0.217 mA-hr. If a mote is
powered by the same regular battery with 2000 mA-Hr
energy, the battery life time will be, theoretically, 384
days. Note that section 5 presents a more practical lifetime
calculation based on empirical test results.
TinyOS provides the following energy management
approaches that can be leveraged by a developer:
• Micro-processor: If there is no task in a task queue,
the task scheduler will automatically put the micro-
processor into the sleep state.
• Radio transceiver: Radio transceiver is in a sleep
state most of the time. It wakes up periodically to
do the communication at the MAC layer
• External devices: External devices such as AD
converters or sensors will be turned off
automatically by a resource manager when there
are no clients trying to access them [6][7][8].
However, a more efficient approach than that
proposed in [6] is used in this paper as described in
section 3, where the application controls the
excitation of the four sensors, and the sensor
readings are sampled in series.
Energy management approaches for the micro-
processor and external devices in TinyOS are quite
mature. TinyOS supports two energy management
approaches at the radio transceiver level, Low Power
Listening (LPL) and Time Division Media Access
(TDMA) protocol. TDMA relies on time-synchronization

4. among the motes, while LPL relies on a preamble message
being inserted in the sender side. Even though TDMA is
more efficient than LPL, because it does not require a
preamble message time, the LPL method was chosen
because its implementation is simpler than the TDMA
approach [13].
4. Sensor node
The physical design of the sensor nodes includes a
hardware design of an interface board for the sensors, a
charging circuit connected to a solar panel, and a housing
box for protection. In terms of firmware, this consists of a
device driver for an MDA300 for an IRIS mote (this had
to be developed because it did not exist in the TinyOS 2
release for the IRIS,) communication messages, and the
sensor layer application program. The main task of each
sensor node is to collect the sensor values and send them
to the gateway by leveraging the Collector Tree Protocol
(CTP). The following two subsections briefly overview
the hardware and the device driver design.
4.1 Hardware design: sensor interface board
The MDA300 sensor board was chosen as the interface
between 4 thermal sensors (external) and the IRIS mote.
This is because of its onboard AD converter and its
connectors to external sensors. Some blank areas are
provided in the printed circuit board (PCB) of the
MDA300 to accommodate for any necessary resistors
required for customization based on the type of sensors
used by the application, but in general the sensors require
sufficient modifications that a custom sensor interface
board is designed.
The schematic of this interface board is presented in
Fig. 3. R1 to R4 are the excitation resistors. R9 to R16
are the voltage proportional division circuit. The voltage
regulator is used to charge the batteries through diode D2
that is connected to the solar panel output. Resistors R6
and R7 are the pull up resistors required by the I2C
interface signals.
Fig 3. Schematic of the sensor interface board.
One aspect that has to be taken into account in order to
reduce power consumption is the value of the excitation
resistor. Recall that the excitation voltage (booster) is
5.8V, and the working current of the LM135 is between
0.4 mA and 5 mA. The excitation resistor value should be
selected by balancing between satisfying the working
current of the LM135 and low power consumption.
kR 8.6
4.0
08.38.5
max =
−
= (1)
kR 68.0
5
43.28.5
min =
−
= (2)
According to equations (1) and (2), the resistor value
used in the excitation circuit should be between 0.68
kOhm to 6.8 kOhm. In the implementation, the excitation
resistor value was selected as 2k, which implies that the
working current for a temperature sensor will be from
1.36 mA ((5.8-3.08)/2) to 1.66 mA ((5.8-2.43)/3)
corresponding to the temperature range from -30°C to
35°C. In the case of four sensors, the total working current
for the temperature sensors should be from 5.44 mA to
6.64 mA. These current draws are significant in relation to
the battery power supply. Thus, the sensor excitation
should be turned off so that the temperature sensors are
not accessed during the idle period. This is an example of
energy management at the physical layer that is difficult to
abstract out by the operating system because this
knowledge is only known at the time the application is
developed.
4.2 Implementation of a device driver of the MDA300
At the time of this design, there was no MDA300
device driver for the IRIS motes in the TinyOS 2 release.
A device driver was designed and implemented for the
MDA300 according to the TinyOS architecture. Even
though this is not a simple task the approach for designing
a device driver is well documented and we simply
overview it here for the purpose of understanding how the
application interacts with this layer.
In TinyOS, a device driver is often divided into three
layers: HPL/HAL/HIL [5]. HPL is the Hardware
Presentation Layer. In this layer, all the hardware
resources such as register name and field are defined as
specific constants. Also, interface, commands, and events
are used to directly access the hardware. HIL is the
Hardware Interface Layer, in which different hardware
implementations in the same category are virtualized by
software as the unified interface. Between the HPL and
HIL is the Hardware Adaptation Layer (HAL).
The HIL can be invoked by the sensor layer
application for unification while the HAL can also be
invoked for higher efficiency, or for time critical and low
overhead usage. Energy management and concurrency are

5. often integrated into the HAL or HIL layers with the
utilization of resource arbitration [5], for this reason we
focus on these 2 layers.
The EM strategies integrated into the HAL layer is the
warming up and cooling down of the AD convertor. There
are four sensors connected to the MDA300, but there is
only one AD convertor. A state variable is used to indicate
the warm up state to avoid the redundant operations. For
example, when the AD converter has not yet cooled down,
the new request for AD converter can be accepted and
started instantly, preventing the redundant operations such
as the cycle of cooling down and warm-up.
4.3 Sensor layer application programming
The source code of the sensor layer application was
implemented using the nesC programming language [10].
The implementation includes interfaces and components
for the radio control, CTP sending and receiving,
dissemination updating and notification, sensor reading,
serial port forwarding, timer firing, and task scheduling
[11]. Figure 4 shows the state chart of the implemented
sensor layer application which is considered as the logic
behaviors for the application.
The logic behaviors of the application are divided into
two parts according to the mote ID. Generally, if the ID is
0, the mote declares itself as the root of the CTP data
collection tree. This mote will act as a gateway between
the sensor network and the Internet network by being
connected to either an Ethernet or USB gateway. Sensor
readings sampled by all other motes will be collected at
mote#0 by leveraging the CTP algorithm. Control
messages to the sensor nodes arrive at mote#0 and
disseminate to all other motes (using the Dissemination
protocol). Thus, the two main events for the mote with
ID#0 are packets arriving from motes in the network via
the CTP protocol and messages arriving from the user.
The other motes in the sensor network act as sensor
nodes. The main duties of a sensor node are to take
readings (sample) from the four thermal sensors, form a
packet containing the readings, send the packet to its
parent, receive a dissemination (control) packet and
forward packets from other motes to the root (act like a
router). Not all sensor nodes may act like a router as it
depends on the topology of the network.
According to the state diagram shown in Fig. 4, after a
mote (sensor node) finishes its initialization procedure, it
will enter a task execution process coordinated by the time
scheduler. If there is no task in the task queue, the timer
scheduler will put the processor into sleep mode. The
main events for time scheduling are a message arriving
signal from the dissemination protocol and the timer firing
event set according to the data collection period. The
former event triggers a mote to change its configuration
parameters. The latter event is a periodic timer event
which triggers the mote to put the sensor readings into a
CTP packet and send it. After the CTP packet is sent, the
mote will start the sensor reading operation again.
Fig. 4. State diagram for the sensor layer application.
Note that the four sensor readings can only be
performed one sensor at a time because the device driver
in the HIL doesn’t support concurrent operations. Recall
also that the low energy management has already been
integrated into the device driver, so the application
doesn’t need to consider how and when to put the AD
converter into sleep mode. However, the application has
to handle when to enable/disable the excitation to the
sensors. Take note that this is not something that the
device drivers are aware of since they only manage the
AD and not the sensors. It is straight forward to
implement this by which prior to posting the sensor
reading task; the application should enable the excitation
output. After the sensor reading task has been notified that
all the four sensor readings are done, it can disable the
excitation output.
5. Test and validation
The purpose of this test is to determine the power
consumption of the sensor node and compare it against the
manufactures listed energy table, Table 1, and other
theoretically computed energy values. The simplest way to
trace energy consumption is to measure current draws
under different load conditions. A multi-meter from
Agilent instrument (Model 34401A) was used to do the
measurement. The minimum sampling resolution supplied
by the multi-meter is 10 samples per second. A total of
600 samples (1 minute duration) were recorded for each
unit test.
In order to accommodate empirical tests, the sensor
layer application was modified for two test scenarios. The

6. first scenario focused on local activities such as enabling
sensor excitation and turning on the AD converters.
Results are shown in Fig. 5. The other test scenario is the
full operation with data collection transmission enabled,
so for this test there are 2 motes, one behaving as a root
collector and the other as the sensor unit. It is the sensor
unit that is instrumented. Results of this experiment are
shown in Fig. 6.
The sensor read period for each case is set to 10
seconds (from t3 to t13). The sensor excitation is enabled
at t3. After the excitation output delay, which is set to
200ms in Fig. 5 and 1s in Fig. 6, AD conversion is
enabled at t4. Then, four readings from the AD converter
are conducted in series to obtain values from the four
sensors until t5. At t5, the sensor excitation is shut off, but
the AD converter is still on for 2 extra seconds to cool
down until t6.
In both scenarios, low power listening is enabled and
the sleep interval is set to 1000ms. The wake up period is
set to 6 ms in TinyOS to perform the MAC layer listening
(according to the TinyOS library source code).
Because the lowest sampling cycle of the multi-meter
is 0.1s, the current draw corresponding the low power
listening is only captured occasionally and marked as ‘A’
in Fig. 5, or ‘A1’ in Fig. 6. According to the settings
above, the duty cycle for low power listening is 0.6%.
Furthermore, the maximum preamble length for the radio
transmission, as depicted from t4 to t5 in Fig. 6, is around
2s, which is two times of the sleep interval of the low
power listening period. Preamble length is dynamically
adjusted in the sender side based on whether the sender is
acknowledged from its receiver.
Fig. 5. Current draw when the data collection
transmission is disabled.
Fig. 6. Current draw of SensIV sensors in full
operation
Moreover, the current draws are 1.0 mA for the AD
converter and 13.0 mA for the sensor excitation. The
current draw from the excitation voltage at 27°C should
be 5.6mA as shown in equation (3). The equivalent
current from the batteries will be 5.6*5.8/3, which equals
10.8mA. This corresponds to the current draw for the
sensor excitation, which is 13.0 mA, plus the extra current
(2.2mA) that is consumed by the excitation voltage
(booster), which can be measured when no thermal
sensors are connected to the sensor interface board.
mAeC 6.54
2
38.5
=×
−
= (3)
The results show that the current draw in the idle state
with low power listening enabled is as low as 0.4 mA, as
marked with B1 in Fig. 6. This is the most important
accomplishment in terms of power conservation because
the mote spends a significant part of its time in the low
duty cycle mode.
The estimated energy consumptions based on these
tests is presented in Table 2 with a sampling interval set to
5 minutes and calculated using equation (4). The
estimated (calculated) energy consumptions of each
activity are shown in Table 3.
3600/)**( DurationsTimesCurrentEnergy = (4)
Table 2. Current draw vs sensor node status
Mark Status Current
(mA)
Expected
value
(mA)
B Idle 0.3 0.015
B1 Radio enabled under CTP 0.4 0.017
C micro-processor 7.0 6.0
D, D1 Sensor excitation 13.0 11.0
F AD enabled 1.0 1.0
A, A1 radio reception 15-17 8
G1-D1 Radio transmission 11.0 12

7. Table 3. Energy consumption in one hour with the
sample interval of 5 minutes
Activities Current
(mA)
Times Duration
(s)
Energy
Consumption
(mA-hr)
Sensor 13 1*12 2 0.086
AD enabled 1 1*12 4 0.013
Radio 11 1*12 2 0.073
Low power
listening
17 300*12 0.006 0.102
Idle 0.4 1*12 290.2 0.387
Total 0.661
The computed lifetime of a 2000 mA-Hr battery based
on the values in Table 3 will be 126 days
((2000/0.661/24)), using the same type of batteries as
mentioned in the Section 2.2. Note that the estimated
lifetime based on the ideal parameters from Table 1 is 384
days. The difference is caused by two factors. The first
one is that an extra interface board was added into each
sensor unit, which results in more current consumption in
the idle state. Another factor is that the low power
listening state is not the same as the sleep state. A mote
needs to wake up quite frequently to check if there are any
communications targeted for it.
There are also some practical aspects that need to be
taken into account. For example we discovered that the
AD conversion is not done properly when the voltage
value for the sensor unit drops below 2.7 volts resulting in
inaccurate temperature readings although the Iris works
well until the voltage is lower than 2.0 volts. Some
preliminary load experiments on a battery, as presented in
Fig. 7, showed that a voltage value of 1.35 volts was
reached at about 190 ma-Hr energy usage, resulting at best
in 12 days of useful battery life in which we can get the
accurate temperature readings.
For effective wireless communications the motes will
operate until the voltage drops to 2 volt, which was
equivalent to 1258 ma-Hr of battery energy as presented
in Fig. 7. This amount of energy theoretically results in 79
days ((1258/0.661)/24) of effective wireless
communications. However, we found that when the mote
was placed in a network it appeared to consume more
energy and didn’t last as long as predicted. In the lab
when 4 motes were placed in a network and were
communicating to one gateway, a mote would eventually
began to fail in approximately 13-15 days depending on
whether we were using rechargeable or non-rechargeable
batteries. Note that the sample interval was set to 5
minutes similar to all of the previous experiments. A
failure in this case was the point at which one would stop
receiving messages from the sensor unit. Since the units
transmitted their battery voltages as a field in the packet,
we could easily verify that the voltage value of one battery
corresponding to the last transmission was lower than 1.0
volts. The units were also placed within 0.5 meter of each
other and they could all communicate with the gateway so
therefore there was no mutli-hop routing occurring.
Unfortunately we have not formalized any experiments
when the sensors are in a network to determine why there
is such a large discrepancy between the lab bench energy
consumption values and that found when the units are
tested in the scenario of one mote and one base station.
6. Conclusion
This paper describes the experiences in designing and
developing a wireless sensor network from an energy
management perspective. The sensor network is meant to
monitor temperatures in a vineyard. These experiences
include designing an interface board to connect multiple
sensors to a sensor board, programming a device driver
according to the TinyOS architecture, and programming at
the sensor layer application.
Throughout the node design, low energy consumption
is the main driving factor. First, the excitation output is
only enabled when the sensor data is sampled. Also, at the
interface board, the current-limit resistor connected with
the temperature sensor is carefully calculated to suit the
driving requirement, but at the same time to save energy.
Next, low energy management is integrated into the
MDA300 device driver following the HPL/HAL/HIL
device driver architecture model.
The test results presented in Section 5 show that all the
energy management approaches are working well
together. However, we note that the lifetime calculated
based on the empirical test is not the same as the lifetime
estimated based on the data given by the mote
manufacturers so that more empirical testing is required.
In practice, the units we developed have solar panels to
compensate for battery power loss so the sensor units can
tolerate fairly low battery lives but it is still important to
strive for low power consumption.
More improvements can be done in the future. For
example, one can redesign a data acquisition board to
combine the current MDA300 and interface board. The
extra components such as the digital IO and the two relays
on the MDA300 will not be needed any more. By doing
this, the current consumption in idle state is expected to be
Fig. 7. Battery test for energy dissipation over time

8. much lower than shown in Table 3. Also, from Table 3,
we can see that the energy consumptions for the low
power listening protocol is still high. Other more effective
protocols, for example based on TDMA, could be sought
to lower the energy consumptions related to the MAC
layer activities in the sensor network.
7. References
[1] G. Drewitt, R. Pitblado, and I. Nichols, “Real-Time
Monitoring Temperature Inversions in Vineyards For
Deep Freeze Protection,” OCE wind Machine Project
Preliminary Report. 2007.
[2] A. Mainwaring, D. Culler, J. Polastre, R. Szewczyk,
and J. Anderson, “Wireless sensor networks for habitat
monitoring,” In Proc. of the 1st ACM Int. Workshop on
Wireless Sensor Networks and Applications. WSNA '02,
2002, pp. 88-97.
[3] J. Burrell, T. Brooke, and R. Beckwith, “Vineyard
computing: sensor networks in agricultural production,”
IEEE Journal of Pervasive Computing, vol. 3, issue 1,
2004, pp. 38-4.
[4] A. Woo, T. Tong, and D. Culler, “Taming the
underlying challenges of reliable multi-hop routing in
sensor networks,” Proc. of the 1st Int. Conf. on Embedded
Networked Sensor Systems, 2003, pp. 14-27.
[5] V. Handziski, J. Polaste, J. Hauer, C. Sharp, A. Wolisz
and D. Culler, “Flexible hardware abstraction for wireless
sensor networks,” Proc. of the 2nd European Workshop
on Wireless Sensor Networks, 2005, pp.145-157.
[6] K. Klues, V. Handziski, C. Lu, A. Wolisz, D. Culler
D., D. Gay, and P. Levis, ”Integrating concurrency control
and energy management in device drivers,” ACM
SIGOPS Operating Systems Review, Vol. 41, Issue 6,
2007, pp. 251-264.
[7] TinyOS-2.x TEP109, Sensors and sensor boards:
http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-
2.x/doc/html/tep109.html, accessed June 2009.
[8] TinyOS-2.x TEP108, Resource arbitration,
http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-
2.x/doc/html/tep108.html, , accessed June 2009.
[9] P. Levis, N. Patel, D. Culler, and S. Shenker, “Trickle:
A self-regulating algorithm for code propagation and
maintenance in wireless sensor networks,” NSDI 2004,
pp. 15-28.
[10] D. Gay, P. Levis, and D. Culler, “Software Design
Patterns for TinyOS,” ACM Trans. on Embedded
Computing Systems, Vol. 6, Issue 4, No. 22, 2007.
[11] Tinyos-2.x Web document:
http://www.tinyos.net/tinyos-2.x/doc/, accessed June
2009.
[12] Iris and MDA300CA Data sheet:
http://www.xbow.com, accessed June 2009.
[13] T. van Dam and K. Langendoen, “An adaptive
energy-efficient MAC protocol for wireless sensor
networks,” In Proc. of the First ACM Conf. on Embedded
Networked Sensor Systems (SenSys), Los Angeles, CA,
Nov. 2003.