System Architecture of
Networked Sensor Platforms
and
Sensor Networks Applications
Introduction
Wireless sensor networks (WSN) consists of group of sensor
nodes to perform distributed sensing task using wireless
medium.
Characteristics
- low-cost, low-power, lightweight
- densely deployed
- prone to failures
- two ways of deployment: randomly, pre-determined or engineered
Objectives
- Monitor activities
- Gather and fuse information
- Communicate with global data processing unit
Introduction
–
Recent sensor networks research involves almost all the layers and can
be categorized into the following three aspects: [Akyildiz+2002,
Elson+2002]:

Energy Efficiency:
small devices, limited amount of energy, essential to prolong system
lifetime

Scalability:
deployment of thousands of sensor nodes, low-cost

Locality:
smallest networks cannot depend on having global states
Why Sensor Platforms?
–
Traditional mechanisms of exploring the network (analysis and
simulation) are not satisfied for exploring such a large-scale, dynamic
and resource-constrained networks due to their difficulties to modeling
every aspect of the system as a whole
–
For example, energy consumption model of the hardware platforms,
including sensing, computation and communication, is not fully
considered and overly-simplified assumptions have been made
–
Application-specific property of WSN makes the existing research
mechanisms even harder to obtain meaningful results
–
Therefore, the demand to build a platform is increasing; e.g., Berkeley’s
motes and MANTIS
Why Sensor Platforms?
–
Compared to analysis and simulation techniques, designing a system
platform has the following advantages:

Provides genuine executive environment: various proposed
algorithms can be exactly evaluated; good way to examine existing
design principles and discover new ones under different
configurations

More attention can be focused on the application-layer

A real system platform can accelerate the pace of research and
development
General WSN System Architecture
–
Constructing a platform for WSN falls into the area of embedded system
development which usually consists of developing environment,
hardware and software platforms.
1.
Hardware Platform
Consists of the following four components:
a) Processing Unit
Associates with small storage unit (tens of kilo bytes order) and
manages the procedures to collaborate with other nodes to carry out the
assigned sensing task
b) Transceiver Unit
Connects the node to the network via various possible transmission
medias such as infra, light, radio and so on
General WSN System Architecture
1.
Hardware Platform
c) Power Unit
Supplies power to the system by small size batteries which makes the
energy a scarce resource
d) Sensing Units
Usually composed of two subunits: sensors and analog-to-digital
Converters (ADCs). The analog signal produced by the sensors are
converted to digital signals by the ADC, and fed into the processing unit
e) Other Application Dependent Components
Location finding system is needed to determine the location of sensor
nodes with high accuracy; mobilizer may be needed to move sensor
nodes when it is required to carry out the task
General WSN System Architecture
1.
Hardware Platform
Figure 1: The components of a sensor node [Akyildiz+2002]
General WSN System Architecture
2.
Software Platform
Consists of the following four components:
a) Embedded Operating System (EOS)
Manages the hardware capability efficiently as well as supports
concurrency-intense operations. Apart from traditional OS tasks such as
processor, memory and I/O management, it must be real-time to rapidly
respond the hardware triggered events, multi-threading to handle
concurrent flows
b) Application Programming Interface (API)
A series of functions provided by OS and other system-level components
for assisting developers to build applications upon itself
General WSN System Architecture
2.
Software Platform
c) Device Drivers
A series of routines that determine how the upper layer entities
communicate with the peripheral devices
d) Hardware Abstract Layer (HAL)
Intermediate layer between the hardware and the OS. Provides uniform
interfaces to the upper layer while its implementation is highly dependent
on the lower layer hardware. With the use of HAL, the OS and
applications easily transplant from one hardware platform to another
General WSN System Architecture
2.
Software Platform
Figure 2: The software platform for WSN
General WSN System Architecture
3.
System Development Environment
Provides various of tools for every stage of software development over
the specific hardware platform
a) Cross-Platform Development
Generally, an embedded system unlike PC and does not have the ability
of self-development. The final binary code run on that system, termed as
target system, will be generated on the PC, termed as host system, by
cross-platform compilers and linkers, and download the resulted image
via the communication port onto the target system
General WSN System Architecture
3.
System Development Environment
Provides various of tools for every stage of software development over
the specific hardware platform
b) Debug Techniques
Due to the difficulties introduced by cross-platform development mode,
the debug techniques become critical for the efficiency of software
production. For this reason, many chips on the system provide the
on-chip debugger, such as JTAF, to reduce the development time.
Berkeley Motes [Hill+ 2000]
–
Motes are tiny, self-contained, battery powered computers with radio
links, which enable them to communicate and exchange data with one
another, and to self-organize into ad hoc networks
–
Motes form the building blocks of wireless sensor networks
–
TinyOS [TinyOS], component-based runtime environment, is designed to
provide support for these motes which require concurrency intensive
operations while constrained by minimal hardware resources
Figure 3: Berkeley Mote
Berkeley Motes [Hill+ 2000]
Hardware Platform
–
Consists of
o
micro-controller with internal flash program memory
o
data SRAM
o
data EEPROM
o
a set of actuator and sensor devices, including LEDs
o
a low-power transceiver
o
an analog photo-sensor
o
a digital temperature sensor
o
a serial port
o
a small coprocessor unit
Berkeley Motes [Hill+ 2000]
Hardware Platform
Figure 4: The schematic for representative network sensor platform
Berkeley Motes [Hill+ 2000]
Hardware Platform
–
The processing unit
o
MCU (ATMEL 90LS8535), an 8-bit architecture with 16-bit addresses
o
provides 32 8-bit general registers and runs at 4 MHz and 3.0 V
o
has 8 KB flash as the program memory and 512 Bytes of SRAM as
the data memory
o
MCU is designed such that the processor cannot write to instruction
memory; the prototype uses a coprocessor to perform this function
o
the processor integrates a set of timers and counters which can be
configured to generate interrupts at regular time intervals
o
three sleep modes: idle (shuts off the processor), power down (shuts
off everything, but the watchdog and asynchronous interrupt logic
necessary to wake up), power save (keep asynchronous timer on)
Berkeley Motes [Hill+ 2000]
Hardware Platform
–
The sensing units
o
contains two sub-components: photo sensor and temperature sensor
o
photo sensor represents an analog input device with simple control
lines which eliminate power drain through the photo resistor when not
in use
o
temperature sensor (Analog Devices AD7418) represents a large
class of digital sensors which have internal A/D converters and
interface over a standard chip-to-chip protocol (the synchronous twowire I2C protocol with software on the micro-controller synthesizing
the I2C master over general I/O pins. There is no explicit arbiter and
bus negotiations are carried out by the software on the microcontroller
Berkeley Motes [Hill+ 2000]
Hardware Platform
–
The transceiver unit
o
consist of an RF Monolithics 916.50 MHz transceiver (TR1000),
antenna, and a collection of discrete components to configure the
physical layer characteristics such as signal strength and sensitivity
o
operates in an ON-OFF key mode at speeds up to 19.2 Kbps
o
control signals configure the radio to operate in either transmit,
receive, or power-off mode
o
the radio contains no buffering, so each bit must be serviced by the
controller on time
o
the transmitted value is not latched by the radio, so the jitter at the
radio input is propagated into the transmission signal
Berkeley Motes [Hill+ 2000]
Hardware Platform
–
The transceiver unit is an Energizer CR2450 lithium battery rated at
575 mAh
–
The other auxiliary components include:
The coprocessor
o
represents a synchronous bit-level device with byte-level support
o
MCU (AT09LS2343, with 2KB instruction memory, 128 bytes of
SRAM and EEPROM) that uses I/O pins connected to an SPI
controller where SPI is a synchronous serial data link, providing high
speed full-duplex connections (up to 1 Mbit) between peripherals
o
the sensor can be reprogrammed by transferring data from the
network into the coprocessor’s 256 KB EEPROM (24LC256)
o
can be used as a gateway to extra storage by the main processor
Berkeley Motes [Hill+ 2000]
Hardware Platform
–
The other auxiliary components include:
The serial port
o
represents a synchronous bit-level device with byte-level controller
support
o
uses I/O pins that are connected to an internal UART controller
o
in transmit mode, the UART takes a byte of data and shifts it out
serially at a specified interval
o
in receive mode, it samples the input pin for a transition and shifts in
bits at a specified interval from the edge
o
interrupts are triggered in the processor to signal completion of the
events
Berkeley Motes [Hill+ 2000, TinyOS]
Hardware Platform
–
The other auxiliary components include:
Three LEDs
o
represent outputs connected through general I/O ports; they may be
used to display digital values or status
Software Platform
–
based on Tiny Micro-Threading Operating System (TinyOS) which is
designed for resource-constrained MEMS sensors
–
TinyOS adopts an event model so that high levels of concurrency can be
handled in a small amount of space
–
A stack-based threaded approach would require that stack space be
reserved for each execution context
Berkeley Motes [Hill+ 2000, TinyOS]
Software Platform
–
A complete system configuration consists of a tiny scheduler and a graph
of components
–
A component has four interrelated parts: a set of
o
a set of command handlers
o
a set of event handlers
o
an encapsulated fixed-size frame
o
Bundle of simple tasks
–
tasks, commands and event handlers execute in the context of the frame
and operate on its state
–
each component declares the commands it uses and the events it signals
–
these declarations are used to compose the modular components in a
per-application configuration
Berkeley Motes [Hill+ 2000, TinyOS]
Software Platform
–
the composition process creates layers of components where higher-level
components issue commands to lower-level components and lower-level
components signal events to the higher-level components
Frames
–
fixed-size and statistically allocated which allows us to know memory
requirements of a component at a compile time -- prevents overhead
associated with dynamic allocation
Commands
–
non-blocking requests made to lower level components
–
typically, a command will deposit request parameters into its frame and
conditionally post a task for later execution
Berkeley Motes [Hill+ 2000, TinyOS]
Software Platform
Commands
–
can invoke lower commands, but it must not wait for long
–
must provide feedback to its caller by returning status indicating whether it
was successful or not
Event handlers
–
Invoked to deal with hardware events, either directly or indirectly
–
The lowest level components have handlers connected directly to
hardware interrupts which may be external interrupts, timer events, or
counter events
–
An event handler can deposit information into its frame, post tasks, signal
higher level events or call lower level commands
Berkeley Motes [Hill+ 2000, TinyOS]
Software Platform
Event handlers
–
in order to avoid cycles in the command/event chain, commands cannot
signal events
–
both signals and events are intended to perform a small, fixed amount of
work, which occurs within the context of their component’s state
Tasks
–
perform the primary work
–
atomic entities with respect to other tasks, run to completion and can be
preempted by events
–
can call lower level commands, signal higher level events, and schedule
other tasks within a component
Berkeley Motes [Hill+ 2000, TinyOS]
Software Platform
Tasks
–
run-to-completion semantics make it possible to allocate a single stack
that is assigned to the currently executing task which is essential in
memory constrained systems
–
allows to simulate concurrency within each component, since tasks
execute asynchronously with respect to the events
–
must never block or spin wait, otherwise, they will prevent progress in
other components
Task scheduler
–
Utilizes a bounded size scheduling data structure to schedule various
tasks base on FIFO, priority-based or deadline-based policy which is
dependent on the requirements of the application
Berkeley Motes [Hill+ 2000, TinyOS]
Software Platform
Figure 5: The schematic for the architecture of TinyOS
MANTIS [Abrach+ 2003]
–
MANTIS (MultimodAl system for NeTworks of In-situ wireless Sensors)
provides a new multi-threaded embedded operating system integrated
with a general-purpose single-board hardware platform to enable flexible
and rapid prototyping of wireless sensor networks
–
the key design goals of MANTIS are
o
ease of use, i.e., a small learning curve that encourages novice
programmers to rapidly prototype sensor applications
o
flexibility such that expert researchers can continue to adapt and
extend the hardware/software system to suit the needs of advanced
research
MANTIS [Abrach+ 2003]
–
MANTIS OS is called MOS
o
MOS selects its model as classical structure of layered multithreaded operating systems which includes multi-threading,
preemptive scheduling with time slicing, I/O synchronization via
mutual exclusion, a standard network stack, and device drivers
o
MOS choose a standard programming language that the entire
kernel and API are written in standard C. This design choice not only
almost eliminates the learning curve, but also accrues many of the
other benefits of a standard programming language, including crossplatform support and reuse of a vast legacy code base. C also eases
development of cross-platform multimodal prototyping environments
on X86 PCs
MANTIS [Abrach+ 2003]
Hardware Platform
–
MANTIS hardware nymph’s design was inspired by the Berkeley MICA an
MICA2 Mote architecture
–
MANTIS Nymph is a single-board design, incorporating the microcontroller, analog sensor ports, RF communication, EEPROM, and serial
ports on one dual-layer 3.5 x 5.5 cm printed circuit board
–
the Nymph is centered around the AMTEL ATmega128(L) MCU, including
interfaces for two UARTs, an SPI bus, an I2C bus, and eight analog-todigital converter channels. It provides additional 64KB EEPROM external
to MCU in addition to 4KB EEPROM included in MCU
–
the unit is powered either by batteries or an AC adapter, and a set of three
on-board LEDs are included to aid in the debugging process. It is designed
to hold a 24mm diameter lithium ion coin cell battery (CR2477), but any
battery in the range of 1.8V to 3.6V can be connected
MANTIS [Abrach+ 2003]
Hardware Platform
–
in order to facilitate rapid prototyping in research environment, the Nymph
has solderless plug connections for both analog and digital sensors,
which eliminates the external sensor board for many applications
–
each connector provides lines for ground, power and sensor signal,
allowing basic sensors such as photo sensors or complex devices such
as infrared an ultra sounds receivers to be connected easily
–
the Chipcon CC1000 radio was chosen to handle wireless
communication. It supports four carrier frequency bands (315, 433, 868,
and 915 MHz) and allows for frequency hopping which is useful for multichannel communication. It is one of the lowest power commercial radios
and allows MOS to optimize the radio to further reduce the power
consumption
MANTIS [Abrach+ 2003]
Hardware Platform
–
for additional modules, the Nymph includes JTAG interface which allows
the user to easily download code to the hardware. This addition
eliminates a need for separate programming board, simplifying the
process of reprogramming the nodes while reducing the cost of overall
system. As added benefit, the JTAG port allows the user to single-step
through code on the MCU and also supports the remote shell
–
the Nymph uses one of the UARTs to supply a serial port (RS232) for
connection to a PC while the second one is used as an interface to the
optional GPS unit
–
MAX3221 RS232 serial chip is used and may be set in three different
power saving modes: power-down, receive only and shut down
MANTIS [Abrach+ 2003]
Hardware Platform
Figure 6: MANTIS Nymph
MANTIS [Abrach+ 2003]
Software Platform
–
MANTIS OS (MOS) adheres to classical layered multi-threaded design
–
top application and API layers show a simple C API which promotes the
ease of use, cross-platform portability, and reuse of a large installed code
base
–
in lower layers of MOS, it adapts the classical OS structures to achieve
small memory footprint
System APIs
–
MANTIS provides comprehensive System APIs for I/O and system
interaction
–
the choice of C language API simplifies cross-platform support and the
development of a multimodal prototyping environment
MANTIS [Abrach+ 2003]
Software Platform
System APIs
–
since MANTIS System API is preserved across both physical sensor
nodes as well as virtual sensor nodes running on X86 platforms, the same
C code developed for MANTIS sensor Nymphs with AMTEL MCU can be
compiled to run on X86 PCs with little or no alteration
Kernel and Scheduler
–
design of MOS kernel resembles classical UNIX-style schedulers
–
The services provided are subset of POSIX threads, most notably prioritybased thread scheduling with round-robin semantics within a priority level
–
binary (mutex) and counting semaphores are also supported
–
the goal of the kernel design is to implement these familiar services in an
efficient manner for resource-constrained environment of a sensor node
MANTIS [Abrach+ 2003]
Software Platform
Network Stack
–
focused on efficient use of limited memory, flexibility, and convenience
–
implemented as one or more user-level threads
–
different layers can be implemented in different threads, or all layers in the
stack can be implemented in one thread
–
the tradeoff is between performance and flexibility
–
designed to minimize memory buffer allocation through layers
–
the data body for a packet is common through all layers within a thread
–
the headers for a packet is variably-sized and are pre-pended to the single
data body
–
designed in a modular manner with standard APIs between each layers,
thereby allowing developers easily modify or replace layer modules
MANTIS [Abrach+ 2003]
Software Platform
Device Drivers
–
Adopts the traditional logical/physical partitioning with respect to device
driver design for the hardware
–
The application developer need not to interact with the hardware to
accomplish a given task
MANTIS [Abrach+ 2003]
Software Platform
Figure 7: MANTIS OS Architecture
MANTIS [Abrach+ 2003]
System Development
–
application developers need to be able to prototype and test applications
prior to distribution and physical deployment in the field
–
during deployment, in-situ sensor nodes need to be capable of being both
dynamically reprogrammed and remotely debugged
–
in order to facilitates these issues, MANTIS identifies and implements
three key advanced features for expert users of general-purpose sensor
systems
o
multimodal prototyping environment
o
dynamic reprogramming
o
remote shell and commander server
MANTIS [Abrach+ 2003]
System Development
Multimodal Prototyping Environment
–
Provides a framework for prototyping diverse applications across
heterogeneous platforms
–
A key requirement of sensor systems is the need to provide a prototyping
environment to test sensor networking applications prior to deployment
–
Postponing testing of an application until after its deployment across a
distributed sensor network can incur severe consequences
–
MANTIS prototyping environment extends beyond simulation to provide
larger framework for development of network management and
visualization applications as virtual nodes within a MANTIS network
o
MANTIS has property of enabling an application developer to test
execution of the same C code on both virtual sensor nodes and later
on in-situ physical sensor nodes
MANTIS [Abrach+ 2003]
System Development
Multimodal Prototyping Environment
o
Seamlessly integrates virtual environment with the real deployment
network such that both virtual and physical nodes can co-exit and
communicate with each other in the prototyping environment
o
Permits a virtual node to leverage other APIs outside of the MANTIS
API, e.g., a virtual node with the MANTIS API could be realized as a
UNIX X windows application that communicates with other rendering
or database APIs to build visualization and network management
applications
MANTIS [Abrach+ 2003]
System Development
Multimodal Prototyping Environment
Figure 8: Multimodal prototyping integrates both virtual and physical sensor
nodes across heterogeneous X86 and AMTEL sensor platforms
MANTIS [Abrach+ 2003]
System Development
Dynamic Reprogramming
–
Sensor nodes should be remotely reconfigurable over a wireless multi-hop
network after being deployed in the field. Since sensor nodes may be
deployed in inaccessible areas and may scale to thousands of nodes, this
simplifies management of the sensor network
–
MOS achieves dynamic reprogramming in several granularities: re-flashing
the entire OS; reprogramming of a single thread; and changing of variables
within a thread
–
Another useful feature would be the ability to remotely debug a running
thread. MOS provides a remote shell that enables a user to login and
inspect the sensor node’s memory
–
MOS includes two programming modes (simpler and more advanced) in
order to overcome the difficulty of reprogramming the network
MANTIS [Abrach+ 2003]
System Development
Dynamic Reprogramming
–
The simpler programming mode is similar to that used in many other
systems and involves a direct communication with a specific MANTIS node
–
On a Nymph, this would be accomplished via a serial port: the user simply
connects the node to a PC and opens the MANTIS shell
–
Upon reset, MOS enters a boot loader that checks for communication from
the shell. At this point, the node will accept a new code image, which is
downloaded from the PC over the direct communication line
–
From the shell, the user has the ability to inspect and modify the node’s
memory directly as well as spawn threads and retrieve debugging
information including thread status, stack fill, and other statistics from OS
–
The boot loader transfers control to the MOS kernel on command from the
shell, or at a startup if the shell is not present
MANTIS [Abrach+ 2003]
System Development
Dynamic Reprogramming
–
The more advanced programming mode is used when a node is already
deployed, and does not require direct access to the node
–
The spectrum of dynamic reprogramming of in-situ sensor networks
ranges from fine grained reprogramming to complete reprogramming
–
MOS has a provision for reprogramming any portion of the node up to and
including the OS itself while the node is deployed in the field
–
This is accomplished through the MOS dynamic reprogramming interface
MANTIS [Abrach+ 2003]
System Development
Remote Shell and Commander Server
–
MOS includes the MANTIS Command Server (MCS) which is
implemented as an application thread
–
From any device in the network equipped with a terminal, the user may
invoke the command server client (also referred to as the shell) and log in
to either a physical node (e.g., on a Nymph or Mica board) or a virtual
node running as a process on a PC
–
MCS listens on a network port for commands and replies with the results,
in a manner similar to RPC
–
The shell gains the ability to control a node remotely through MCS
MANTIS [Abrach+ 2003]
System Development
Remote Shell and Commander Server
–
The user may alter the node’s configuration settings, run or kill programs,
display the thread table and other OS data, inspect and modify the node’s
data memory, and call arbitrary user-defined functions
–
The shell is powerful debugging tool since it allows the user to examine
and modify the state of any node, without requiring physical access to the
node
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Introduction
–
Habitat and environmental monitoring represent essential class of sensor
network applications by placing numerous networked micro-sensors in
an environment where long-term data collection can be achieved
–
The sensor nodes perform filtering and triggering functions as well as
application-specific or sensor-specific data compression algorithms thru
the integration of local processing and storage
–
The ability to communicate allows nodes to cooperate in performing
tasks such as statistical sampling, data aggregation, and system health
and status monitoring
–
Increased power efficiency assists in resolving fundamental design
tradeoffs, e.g., between sampling rates and battery lifetimes
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Introduction
–
The sensor nodes can be reprogrammed or retasked after deployment in
the field by the networking and computing capabilities provided
–
Nodes can adapt their operation over time in response to changes in the
environment
–
The application context helps to differentiate problems with simple and
concrete solutions from open research areas
–
An effective sensor network architecture and general solutions should be
developed for the domain
–
The impact of sensor networks for habitat and environmental monitoring
is measured by their ability to enable new applications and produce new
results
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Introduction
–
This paper develops a specific habitat monitoring application, but yet a
representative of the domain
–
It presents a collection of requirements, constraints and guidelines that
serve as a basis for general sensor network architecture
–
It describes the core components of the sensor network for this domain–
hardware and sensor platforms, the distinct networks involved, their
interconnection, and the data management facilities
–
The design and implementation of the essential network services –
power management, communications, re-tasking, and node management
can be evaluated in this context
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Habitat Monitoring
–
Researchers in the Life Sciences are concerned about the impacts of
human presence in monitoring plants and animals in the field conditions
–
It is possible that chronic human disturbance may adversely effect results
by changing behavioral patterns or distributions
–
Disturbance effects are of concern in small island situations where it may
be physically impossible for researchers to avoid some impact on an
entire population
–
Seabird colonies are extreme sensitive to human disturbance
–
Research in Maine [Anderson 1995], suggests that a 15 minute visit to a
cormorant colony can result in up to 20% mortality among eggs and
chicks in a given breeding year. Repeated disturbance can lead to the
end of the colony
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Habitat Monitoring
–
On Kent Island, Nova Scotia, research learned that Leach’s Storm Petrels
are likely to desert their nesting burrows in case of disturbance during the
first two weeks of incubation
–
Sensor networks advances the monitoring methods over the traditional
invasive ones
–
Sensors can be deployed prior to the breeding season or other sensitive
period or while plants are dormant or the ground is frozen on small islets
where it would be unsafe or unwise to repeatedly attempt field studies
–
Sensor network deployment may be more economical method for
conducting long-term studies than traditional personnel-rich methods
–
A “deploy ‘em and leave ‘em” strategy of wireless sensor usage would
decrease the logistical needs to initial placement and occasional servicing
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Great Duck Island
–
The College of Atlantic (COA) is field testing in-situ sensor networks for
habitat monitoring
–
Great Duck Island (GDI) is a 237 acre island located 15 km south of
Mount Desert Island, Maine
–
At GDI, three major questions in monitoring the Leach’s Storm Petrel
[Anderson 1995]:
1.
What is the usage pattern of nesting burrows over the 24-72 hour
cycle when one or both members of a breeding pair may alternate
incubation duties with feeding at sea?
2.
What changes can be observed in the burrow and surface
environmental parameters during the course of the approximately 7
month breeding season (April-October)?
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Great Duck Island
3.
What are the differences in the micro-environments with and without
large numbers of nesting petrels?
–
Presence/absence data is obtained through occupancy detection and
temperature differentials between burrows with adult birds and burrows
that contain eggs, chicks, or are empty
–
Petrels will most likely enter or leave during the daytime; however, 5-10
minutes during late evening and early morning measurements are
needed to capture the entry and exit timings
–
More general environmental differentials between burrow and surface
conditions can be captured by records every 2-4 hours during the
extended breeding season; whereas, the differences between “popular”
and “unpopular” sites benefit from hourly sampling
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Great Duck Island Requirements
1.
Internet Access
–
The sensor networks at GDI must be accessible via the Internet since the
ability to support remote interactions with in-situ networks is essential
2.
Hierarchical Network
–
Habitats of interest are located up to several kilometers away. A second
tier of wireless networking provides connectivity to multiple patches of
sensor networks deployed at each of the areas.
3.
Sensor Network Longevity
–
Sensor networks that runs for several month from non-rechargeable
power sources would be desirable since studies at GDI can span multiple
field seasons
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Great Duck Island Requirements
4.
Operating off-the grid
–
Every level of the network must operate with bounded energy supplies
–
Renewable energy such as solar power may be available some
locations, disconnected operation is a possibility
–
GDI has enough solar power that run the application 24x7 with small
probabilities of service interruptions due to power loss
5.
Management at-a-distance
–
Remoteness of the field sites requires the ability to monitor and manage
sensor networks over the Internet. The goal is no on-site presence for
maintenance and administration during the field season, except for
installation and removal of nodes
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Great Duck Island Requirements
6.
Inconspicuous operation
–
It should not disrupt the natural processes or behaviors under study
–
Removing human presence from the study areas would eliminate a
source of error and variation in data collection and source of disturbance
7.
System behavior
–
Sensor networks should present stable, predictable, and repeatable
behavior at all times since unpredictable system is difficult to debug and
maintain
–
Predictability is essential in developing trust in these new technologies
for life scientists
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Great Duck Island Requirements
8.
In-situ interactions
–
Local interactions are required during initial development, maintenance
and on-site visits
–
PDAs can be useful in accomplishing these tasks – they may directly
query a sensor, adjust operational parameters and so on
9.
Sensors and sampling
–
The ability to sense light, temperature, infrared, relative humidity, and
barometric pressure are essential set of measurements
–
Additional measurements may include acceleration/vibration, weight,
chemical vapors, gas concentrations, pH, and noise levels
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Great Duck Island Requirements
10. Data archiving
–
Sensor readings must be achieved for off-line data mining and analysis
–
The reliable offloading of sensor logs to databases in the wired, powered
infrastructure is essential
–
It is desirable to interactively “drill-down” and explore sensors in near
real-time complement log-based studies. In this mode of operation, the
timely delivery of sensor data is the key
–
Nodal data summaries and periodic health-and-status monitoring also
requires timely delivery of the data
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
System Architecture
–
A tiered architecture is developed
–
The lowest level consists of the sensor nodes that perform general
purpose computing and networking as well as application-specific sensing
–
The sensor nodes may be deployed in dense patches and transmit their
data through the sensor network to the sensor network gateway
–
Gateway is responsible for transmitting sensor data from the sensor patch
through a local transit network to the remote base station that provides
WAN connectivity and data logging
–
The base station connects to database replicas across the internet
–
At last, the data is displayed to researchers through a user interface
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
System Architecture
Figure 1: System architecture for habitat monitoring
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
System Architecture
–
The autonomous sensor nodes are placed in the areas of interest where
each sensor node collects environmental data about its immediate
surroundings
–
Since these sensors are placed close to the area of interest, they can be
built using small and inexpensive individual sensors – high spatial
resolution can be achieved through dense deployment of sensor nodes
–
This architecture offers higher robustness compared to traditional
approaches which use a few high quality sensors with complex signal
processing
–
The computational module is a programmable unit that provides
computation, storage and bidirectional communication with other nodes
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
System Architecture
–
The computational module interfaces with the analog and digital sensors
on the sensor module, performs basic signal processing and dispatches
the data according to the needs of the application
–
Compared to traditional data logging systems, networked sensors offer
two main advantages: they can be re-tasked in the field and they can
communicate with the rest of the system
–
In-situ re-tasking gives researchers the ability to refocus their
observations based on the analysis of the initial results – initially, absolute
temperature readings are desired, after a while, only significant
temperature changes exceeding a threshold may become more useful
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
System Architecture
–
Individual sensor nodes communicate and coordinate with one another
–
These nodes form a multi-hop network by forwarding each other’s
messages and if needed, the network can perform in-network aggregation
(e.g., relaying the average temperature across the region)
–
Eventually, data from each sensor needs to be propagated to the Internet
–
The propagated data may be raw, filtered or processed data
–
Since direct wide area connectivity cannot be brought to each sensor path
due to several reasons (e.g., cost of equipment, power, disturbance
created by the installation of the equipment in the environment), wide are
connectivity is brought to a base station instead
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
System Architecture
–
The base station may communicate with the sensor patch using a
wireless LAN where each sensor patch is equipped with a gateway that
can communicate with the sensor network and provides connectivity to
the transit network
–
The transit network may consist of a single hop link or series of networked
wireless nodes and each transit network design has different
characteristics with respect to expected robustness, bandwidth, energy
efficiency, cost and manageability
–
To provide data to remote end-users, the base station includes WAN
connectivity and persistent data storage for the collection of sensor
patches
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
System Architecture
–
It is expected that WAN connection will be wireless
–
The architecture needs to address the disconnection possibilities
–
Each layer (sensor nodes, gateways, base stations) has some persistent
storage to protect against data loss due to power outage as well as data
management services
–
At the sensor level, these will be primitive, taking the form of data logging
–
The base station may provide relational database service while the data
management at the gateways falls somewhere in between
–
When it comes to data collection, long-latency is preferable to data loss
–
Users interact with the sensor network in two ways
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
System Architecture
–
Remote users access the replica of the base station database
–
This approach assists on integration with data analysis and mining tools
while masking the potential wide area disconnections with the base
stations
–
On-site users may require direct interaction with the network and this can
be accomplished with a small, PDA-sized device, referred to as gizmo
–
Gizmo allows the user to interactively control the network parameters by
adjusting the sampling rates, power management parameters and other
network parameters
–
The connectivity between any sensor node and gizmo may or may not
rely on functioning on multi-hop sensor network routing
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Sensor Network Node
–
UC Berkeley motes are used as the sensor nodes
–
Mica uses a single channel, 916 MHz radio from RF Monolithics to
provide bi-directional communication at 40 Kbps, an Atmel Atmega 103
microcontroller running at 4 MHz and 512 KB nonvolatile storage
–
A pair of conventional AA batteries and a DC boost converter provide the
power source; however, other renewable energy sources can be used
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Sensor Board
–
The Mica Weather Board provides sensors that monitor changing
environmental conditions with the same functionality as a traditional
weather station
–
The Mica Weather Board includes temperature, photoresistor, barometric
pressure, humidity, and passive infrared (thermopile) sensors
Table 1: Mica Weather Board
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Sensor Board
Figure 2: Mica Hardware Platform: The Mica sensor node (left) with the Mica
Weather Board developed for environmental monitoring applications
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Energy Budget
–
Typical habitat monitoring applications need to run for nine months
–
The application chooses how to allocate the energy budget between
sleep modes, sensing, local calculations and communications
–
Since different nodes have different functions, they also have different
power requirements, for instance, the nodes near the gateway may need
to forward all messages from a patch while a node in a nest may only
need to report its own readings
–
When a set of power limited nodes exhaust their power supplies, the
network can become disconnected and inoperable
–
There is a need to budget the power with respect to the energy
bottlenecks of the network
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Energy Budget
–
The baseline life time of the node is determined by the current draw in
the sleep state
–
Minimizing power in sleep mode means turning off the sensors, the radio
and putting the processor into a deep sleep mode
Table 2: Power required by various Mica operations
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Sensor Deployment
–
A wireless sensor network using Mica motes with Mica Weather Board
has been deployed in July 2002
–
Environmental protective packaging has been designed which minimally
obstruct sensing functionality
Figure 3: Acrylic enclosure used for deploying the Mica mote
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Patch Gateways
–
Usage of different gateway nodes directly affects the underlying available
transit network
–
Two designs implemented: an 802.11b single hop with an embedded
Linux system and a single hop mote-to-mote network
–
Initially, CerfCube [Cerfcube] which is a small StrongARM-based
embedded system to act as a sensor patch gateway, is chosen
–
Each gateway is equipped with a CompactFlash 802.11b adapter
–
Gateway use permanent storage of up to 1GB
–
The mote-to-mote solution consisted of a mote connected to the base
station and a mote in the sensor patch
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Patch Gateways
–
The differences between the mote and CerfCube include different
o
communication frequency
o
power requirements
o
software components
–
The mote’s MAC layer does not require bi-directional link like 802.11b
–
In addition, the mote sends raw data with a small packet header (4 bytes)
directly over the radio as opposed to overheads imposed by 802.11b and
TCP/IP connections
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Base-station installation
–
For achieve remote access, collection of sensor patches is connected to
the Internet through a wide-area link
–
On GDI, Internet connectivity is accomplished through a two-way satellite
connection provided by Hughes and similar to DirecTV system
–
The satellite system is connected to a laptop which coordinates the
sensor patches and provides a relational database service
Database Management System
–
The base station uses Postgres SQL database which stores timestamped readings from the sensors, health status of the individual
sensors, and metadata (e.g., sensor locations)
Wireless Sensor Networks for Habitat
Monitoring
[Mainwaring+ 2002]
Implementation Strategies
Database Management System
–
The GDI database is replicated every fifteen minutes over the wide-area
satellite link to Postgres database in Berkeley
User Interfaces
–
Many user interfaces can be implemented on top of the sensor database
–
GIS systems provide a widely used standard for analyzing geographical
data and most statistics and data analysis packages implement
interfaces to relational databases
–
Number of web interfaces can be implemented to provide the ubiquitous
interfaces to the habitat data
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
Introduction
–
Focus is on issues related to dynamic sensor networks with mobile
nodes and wireless communication between them
–
In this system, the sensor nodes collars carried by the animals under
study; wireless ad hoc networking techniques are used to swap and store
data in a peer-to-peer manner and to pass it towards a mobile base
station that sporadically traverses the area to upload data
–
Biology and biocomplexity research has been focused on gathering data
and observations on a range of species to understand their interactions
and influences on each other
–
For example, how human development into wilderness areas affects
indigenous species there; understand the migration patterns of wild
animals and how they may be affected by changes in weather patterns or
plant life, by introduction of non-native species, and by other influences
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
Introduction
–
Finding and learning these details require long-term position logs and
other biometric data such as heart rate, body temperature, and frequency
feeding
–
Current wildlife tracking studies rely on simple technology, for example,
many studies rely on collaring a sample subset of animals with simple
VHF transmitters
–
Researchers periodically drive through and/or fly over an area with a
receiver antenna, and listen for pings from previously collared animals
–
Once animal is found, its behavior can be observed and its observed
position can be logged; however, there are limits to such studies
–
First, data collection is infrequent and can miss many “interesting events”
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
Introduction
–
Second, data collection is mostly limited to daylight hours, but animal
behavior and movements in night hours can be different
–
Third, data collection is impossible or very limited for secluded species
that avoid human contact
–
The most elegant trackers commercially available use GPS to track
position and use satellite uploads to transfer data to a base station
–
These systems also suffer from several limitations
–
First, at most a log of 3000 position samples can be logged and no
biometric data
–
Second, since satellite uploads are slow and uses high power
consumption, they are done infrequently – this limits how often position
samples can be gathered without overflowing 3000-entry log storage
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
Introduction
–
Third, downloads of data from the satellite to the researchers are both
slow and expensive, therefore, constraining the amount of data collected
–
Finally, these systems operate on batteries without recharge – when
power is drained, the system become unusable unless it is retrieved,
recharged and re-deployed
–
ZebraNet project is building tracking nodes that include a low-power
miniature GPS system with user-programmable CPU, non-volatile
storage for data logs, and radio transceivers for communicating either
with other nodes or with a base station
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
Introduction
–
One of the key principles of ZebraNet is that the system should work in
arbitrary wilderness locations; no assumptions are made about the
presence of of fixed antenna towers or cellular phone service
–
The system uses peer-to-peer data swaps to move the data around;
periodic researcher drives bys and/or fly-overs can collect logged data
from several animals despite encountering relatively few within range
–
Even though ad hoc sensor networks have been heavily studied, not
much has been published about the characteristics of mobile sensor
networks with mobile base stations and very few studies focus on
building real systems
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
Introduction
–
This paper has the following unique contributions:
o
To the best knowledge of authors, this is the first study of mobile
sensor networks protocols in which the base station is also mobile. It
is presumed that researchers will upload data while driving or flying
by the region
o
Zebra-tracking is a domain in which the node mobility models are
unknown which makes it a research goal. Understanding how, when
and why zebras undertake long-term migrations is the most
essential biological question of this work.
o
ZebraNet’s data collection has communication patterns in which
data can be cooperatively passed towards a base station
o
Energy tradeoffs are examined in detail using real system energy
measurements for ZebraNet prototype hardware in operation
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
Introduction
–
–
Some of the interesting research questions to be explored are:
o
How to make the communications protocol both effective and powerefficient?
o
To what extent can we rely on ad hoc, peer-to-peer transfers in a
sparsely-connected spatially-huge sensor network?
o
How can we provide comprehensive tracking of a collection of
animals, even if some of the animals are reclusive and rarely are
close enough to humans to have their data logs updated directly?
This research work gives quantitative explorations of the design
decisions behind some of these questions
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
ZebraNet Design Goals
–
The ZebraNet project is a direct and ongoing collaboration between
researchers in experimental computer systems and in wildlife biology
–
The wildlife biologists have determined the tracker’s overall design goals:
o
GPS position samples are taken every three minutes
o
Detailed activity logs taken for three minutes every hour
o
One year of operation without direct human intervention – that is, not
counting on tranquilizing and re-collaring an animal more than once
per year
o
No fixed base stations, antennas, or cellular service
o
A high success rate for eventually delivering all logged data is
essential while latency is not as critical
o
For a zebra collar, a weight limit of 3-5 lbs is recommended
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
ZebraNet Design Goals
–
Ultimately, this detailed information may include several position
estimates, temperature information, weather data, environmental data,
and body movements that will serve as signatures of behavior; however,
in this initial system, the focus is only on position data
–
Overall, the key goal is to deliver to researchers a very high fraction of the
data collected over the months or years that the system is in operation
–
Therefore, ZebraNet must be power-efficient, designed with appropriate
data log storage, and must be rugged to ensure reliability under tough
environmental conditions
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
ZebraNet Problem Statement
–
The biologists design goals need to be translated into the engineering
task at hand
–
Success rate at delivering position data to the researchers –data homing
rate– should approach 100%
–
Weight limits on each node translate almost directly to computational
energy limits since weight of the battery and solar panel takes bulk of the
total weight of a ZebraNet node; therefore, collar and protocol design
decisions must manage the number and size of data transmissions
required
–
System design choices must be made that limit the range of
transmissions since the required transmitter energy increases
dramatically with the distance transmitted
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
ZebraNet Problem Statement
–
The amount of storage needed to hold position logs must be limited – if
many redundant copies are stored and swapped, the storage
requirements can scale as O(n2)
–
Although the energy cost of storage is small compared to that of
transmissions, it is still necessary to develop storage-efficient design
–
Due to limited transceiver, coverage and a base station only sporadically
available, ZebraNet must forward data through other nodes in peer-topeer manner and store redundant copies of position logs in other tracking
nodes
–
Some of the key challenges in ZebraNet come from the spatial and
temporal scale of the system
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
ZebraNet Problem Statement
–
In terms of temporal scale, keeping a system running autonomously
months at a time is challenging; it requires tremendous design-time
attention to both hardware and software reliability
–
In terms of spatial scale, ZebraNet is also aggressive; it is the specific
intent of the system to operate over an area of hundreds or thousands of
square square kilometers
–
Due to the large distances involved and sparse sensor coverage,
energy/connectivity tradeoffs become key
Energy-Efficient Computing for Wildlife Tracking:
Design Tradeoffs and Early Experiences with ZebraNet
[Juang+ 2002]
ZebraNet Problem Statement
–
These challenges mentioned here tackles several open problems:
–
ZebraNet protocol promises good communication behavior on mobile
sensors forwarding data towards a mobile base station
–
ZebraNet explores design issues for sensors that are more coarsegrained than many prior sensor proposals. Larger the weight limits
and storage budgets allow researchers to consider different protocols
with improved leverage for sparsely-connected, physicallywidespread sensors
References
[Abrach+ 2003] H. Abrach, S. Bhatti, J. Carlson, H. Dai, J. Rose, A. Sheth, B. Shucker, J, Deng and R.
Han, MANTIS: System Support for MultimodAl NeTworks of In-Situ Sensors, 2nd ACM
International Workshop on Wireless Sensor Networks and Applications (WSNA 2003),
September 2003.
[Akyildiz+ 2002] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, A Survey on Sensor
Networks, IEEE Communications Magazine, Vol. 40, No. 8, pp. 102-114, August 2002.
[Anderson 1995] J.G.T. Anderson, Pilot survey of mid-coast Maine seabird colonies: an evaluation of
techniques, Bangor, ME, 1995. Report to the State of Maine Dept. of Inland Fisheries and
Wildlife.
[Cerfcube] Cerfcube embedded StrongARM system, http://www.intrinsys.com/products/cerfcube
[Elson+ 2002] J. Elson and K. Romer, Wireless Sensor Networks: A New Regime for Time
Synchronization, First Workshop on Hot Topics in Networks (Hotnets-I), Princeton, USA, October
2002.
[Hill+ 2000] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, System Architecture
Directions for Networked Sensors, Architectural Support for Programming Languages and
Operating Systems (ASPLOS) 2000.
[Juang+ 2002] P. Juang, H. Oki, Y. Wang, M. Martonosi, L-S Peh, and D. Rubenstein, Energy-Efficient
Computing for Wildlife Tracking: Design Tradeoffs and Early Experiences with ZebraNet, ACM
SIGARCH Computer Architecture News, vol. 30, no. 5, December 2002 .
[Mainwaring+ 2002] A. Mainwaring, J. Polastre, R. Szewczyk, D. Culler, and J. Anderson, Wireless
Sensor Networks for Habitat Monitoring, 1st ACM International Workshop on Wireless Sensor
Networks and Applications (WSNA 2002), Atlanta, Georgia, September 28, 2002.
[TinyOS] TinyOS: a component-based OS for the networked sensor regime.