Overview - UNT | University of North Texas
Download
Report
Transcript Overview - UNT | University of North Texas
ENVIRONMENTAL MONITORING:
FROM SENSORS TO DATABASE
Jerry Yang
Overview
Design Requirement
System Framework
Wireless Sensor Networks
Telecommunication system
Single Board Computer
GPRS modem
Networking sensors, data loggers and data servers
Database and Client Interfaces
Communications Protocols
Data Interpolating
Energy Harvesting
Over-the-Air Programming
Database
Data Visualization
Conclusion and Future Work
Project Object
Design and implement a fully functional environmental
monitoring system
Collect and report temporal and spatial soil moisture data
with required accuracy
Provide near-real-time data about monitored variables to
the public
Monolithic weather stations
Wired Sensors (Data loggers)
limited Spatial Coverage
Field Study
Data is acquired every month
Go Wireless
Wireless Sensors could fulfill this mission
Unprecedented
temporal and spatial granularities
Near-real-time data is accessible via the Internet
Besides…
Robust
and accurate through dense deployment
Minimize disturbance to the monitored site
Cover larger area (Multihop)
Low installation cost
Ease of deployment and relocation
System Architecture
Data loggers
In the Field:
Download Data
Client Data Browsing
and Processing
Internet
Database Server
In the Lab:
Upload Data
System Architecture
Data loggers
Wireless Sensor Nodes
Base Station Node
Gateway
(Single Board Computer)
Client Data Browsing
and Processing
GPRS Link
Internet
GPRS Modem
Database Server
An introduction to WSNs
A wireless sensor mote is a battery-operated
embedded system including various hardware and
software components. For MicaZ motes:
Processing Unit
7.37MHz micro-controller
4KB RAM 512KB Flash
Sensors
16-bit ADC with MDA 300 Data Acquisition Board
EC-5 Soil Moisture Sensors
Transceiver
2.4 GHz, IEEE 802.15.4 compliant, 250 kbps
Powered by 2 AA batteries
Constraints of Sensor Motes
Limited processing, storage and communication capabilities
100 nodes @250bps = 25kbps (data sampled every second)
WILL be solved in the near future
Streaming Data
to/from the
Physical World
year
Fundamental Problem
Sensor network is un-tethered, and will be operating for
a long time.
Replacing batteries is difficult and expensive if not
impossible
For MicaZ, typical current drawing is 30mA. Powered by 2.4V
3000mAh Batteries, a MicaZ mote could run for 100 hours
continuously.
Communicating 1 bit data over the wireless medium consumes far
more energy than processing it.
Operating Current (mA)
ATMega128L, full operation
ATMega128L, sleep
Radio, receive
Radio, transmit (0dBm)
Radio, sleep
MicaZ
12 (7.37 MHz)
0.010
19.7
17
0.001
Software Support
TinyOS and NesC
An open-source operating system designed for
wireless embedded sensor networks
Component-based architecture which enables rapid
innovation and implementation while minimizing code
size
Event-driven execution model
Communication Protocols
Design requirement
Energy Efficient
Robust, scalable and adaptive
Dynamic topology changes due to unstable links, node failures and network
disconnections
Unique characteristics of our project
Radio communication is the most expensive operation in terms of energy
usage
Long-term operation with very low data rate
A single sink node
At most of the time, data flow is uni-directional
Layered Architecture
Physical/Link Layer
Medium Access Control
Routing
Physical/Link Layer
Radio Propagation
Path
Loss - signal strength attenuates as distance to a
constant exponent
However, radio connectivity is not a simple disk
Shadowing
(due to obstructions) and Multipath Fading
Wireless Channel Characteristics
Great
spatial variability
Non-isotropic propagation
Asymmetric links are common due to hardware
calibration
Link Quality Over Space
Packet reception over distance has a heavy tail. There is a
non-zero probability of receiving packets at distances much
greater than the average cell range
169 motes, 13x13 grid, 2 ft spacing, open area, RFM radio,
simple CSMA
Medium Access Control
MAC protocol decides when and how nodes access the
shared wireless channel
Collision avoidance
Duty-cycle control
MAC layer protocols directly controls radio activities, significantly
affect the overall node lifetime
MAC in Wireless Networks
Contention-based protocols
CSMA/CA – node compete for a single channel
On-demand allocation provides more flexibility and adaptivity
Scheduled protocols
C/T/FDMA – divide wireless channel into different sub-channels
Collision-free and energy-efficient
MAC for Sensors
Sources of energy waste in radio communication
Idle listening
Costs as much power as transmitting or receiving
dominant factor of energy consumption especially in low data
rate systems
Collision – retransmit when packets collide
Build on CSMA but also adopt TDMA-like
sleep/wakeup duty cycle
S-MAC, T-MAC, B-MAC, Z-MAC
Reduce idle listen and minimize collision
Improve power efficiency while retaining flexibility
Sacrifice throughput, increase latency
MAC Protocol Design
We implement a tree-structure data report hierarchy, rooted at the
sink node
A global clock is also maintained by time synchronization
All nodes begin with a Sync slot
Synchronize time, manage neighbor list, select parent
Parent nodes then allocate time slots for their children
All nodes are awake, but only broadcasting very short control packets
A node will report its latest readings to its parent in transmit slot,
while the parent node will become active and listen to the channel
Nodes sleep for the rest of time
Parent
…
Sync
Sleep
Rcv 1
Child 1
…
Sync
Sleep
Transmit
Child 2
…
Sync
Sleep
Rcv2
Sleep
Transmit
Sleep
Transmit
Sleep
Sleep
Network Layer - Routing
Establishing and maintain the multi-hop routing
hierarchy
Link Quality Estimation
Neighbor Management
Discover,
update, remove neighboring nodes
Parent selection
Shortest
Path, Minimal Transmission, Geo-Routing,
Energy-Aware routing
Link Quality Versus Distance
Packet Reception Rate vs Distance
100
-25dBm
-15dBm
90
80
PRR (%)
70
60
50
40
30
20
10
0
1
2
3
4
5
6
Distance (feet)
7
8
9
10
Time Synchronization
Why do we need network-wise clock?
Time stamp data samples
Set up radio schedule
TOA, TDOA in Localization
Pair-wise Synchronization
Estimate communication delays
Estimate clock skew
Send time, access time, propagation time, receive time, etc.
Perform linear regression on past local/global time pairs
Multihop Synchronization
Minimize control overhead
Application Layer
Energy Efficient Map Interpolation for Sensor
Fields using Kriging (E2K)
an
energy efficient and error bounded framework for
interpolating maps from sensor fields
Environmental dynamics, such as temperature and soil
moisture, are continuous
Should be represented as a continuous surface over the
sensor fields through interpolating
Spatial and temporal autocorrelation could be utilized
to reduce sample points
Data Interpolating
Data Interpolating
Localization
Knowing the exact location where information was
collected is critical
A
reading is represented by vectors (x,y,t,v)
Self-localization vs Tracking
Ranging Methods
Radio,
acoustic/ultrasound, laser, etc.
RSS, TOA, TDOA
Lateration and Triangulation
Solar Harvesting Sub-System
Energy Storage Module
Ultra Capacitors and Rechargeable Batteries
Choosing Batteries
NiMH, NiCd, Li-ion
Solar Harvesting Module
Solar Cells
Regulators and Switches
Circuit Design
Smart Battery Monitoring
Energy-Aware Protocol and Considerations
Over-the-Air Programming
Loading a new application or upgrading an existing
application on a sensor node
via a serial port or some physical connections to the node
Reprogram nodes one by one
However, physical access to nodes is in many cases
extremely limited following deployment
Even when access were possible, manually updating
hundreds or thousands of nodes would be a tedious task
indeed
Network reprogramming protocols have recently emerged
as a way to distribute application updates without requiring
physical access to sensor nodes.
Multi-hop Over-the-Air Programming
MOAP divides a program image into packets, and these packets are
distributed through the network. Once received, packets are placed in
stable storage until the entire update has been completed.
In MOAP, sources advertise updated code images to their neighbors. A
node having received a full image become publishers and propagate the
image to other nodes out of range of the original source.
This process is applied iteratively until the update has propagated across the
network.
Packet loss and retransmission
Receiver uses a sliding window to keep track of lost packets.
When a missing packet is detected, the receiver sends a uni-cast retransmission
request.
If the source does not respond within a certain amount of time, the receiver
broadcasts a retransmission request to which all nodes within range reply.
This allows the receiver to choose a new source in case the original source fails.
Duplicate requests arriving at a source within a given time period are suppressed.
Cross Layer Protocol Design
No standard protocol for sensor nets
Resource constraints even demand cross-layer
integration
Sensor protocol design is task-specific
While some protocols can achieve very high performance in
terms of the metrics related to each of the individual layer,
they are not jointly optimized in order to maximize the
overall network performance and minimize energy
expenditure
When designing communication schemes, we can not
simply pick the best protocol in each layer and pile
them up.
Tele-Communication System
The needs for telemetry
Provides near-real-time data feeding
Enables remote control of sensor nets and data loggers
Single Board Computer (SBC)
Change monitoring parameters
Update sensor motes/data logger programs after deployment
200Mhz ARM processor, 64MB RAM, 1GB SD Card
Linux support
Bridge between sensors and Internet
Local Database Server
GPRS modem
PPP and PPP Daemon
a data link protocol commonly used to establish a direct connection between two nodes
over serial cable, phone line, cellular phone, or dial-up network to get access to the
Internet
Conclusion
Data flows from sensors to remote database
System Architecture
Research areas
Energy-Aware
Design
Cross Layer Protocol Design
Over the air programming
Localization
Questions?