Wireless Sensor Networks

Thomas Kunz Professor and Director, Technology Innovation Management Program

WSN Definition
Wikipedia entry
A wireless sensor network (WSN) is a wireless network consisting of spatially distributed autonomous devices using sensors to cooperatively monitor physical or environmental conditions, such as temperature, sound, vibration, pressure, motion or pollutants, at different locations.

Electrical Engineering Glossary Definition for Wireless Sensor Network:

Wireless Sensor Network, or WSN, is a network of RF transceivers, sensors, machine controllers, microcontrollers, and user interface devices with at least two nodes communicating by means of wireless transmissions.
Sensor Node

Sensor

CPU

Radio

Technology that enables WSN is relatively new (wireless data networks, microcontrollers/computers)

Data Networks/Internet: From Humble Beginnings in 1969 .

Internet: slowly.

Internet: to a global communications network

Wireless Data Networks

Even more recent than Internet Cellular networks: AMPS started in 1983, currently rollout of 3rd generation networks, research on 4th generation technologies IEEE: Wireless link standards developed in 1990s and later
IEEE 802.11 (WiFi): first standard in 1997, many revisions and extensions since IEEE 802.15 (Bluetooth, ZigBee): Bluetooth 2002, ZigBee 2004 IEEE 802.16 (WiMax): first standards in 2001, many revisions and updates since (mobile WiMax 802.16e approved in 2005)

Wireless products sometimes earlier, work also pushed forward in industry consortia (ZigBee Alliance, Bluetooth SIG, WiFi Alliance, WiMAX Forum)

Microcontrollers: Started Big (Computers)

What machine is that? Hint: British Connection.

More Big Computers

And More Big Computers

Portable Computers: The Early Days

1981: The first portable computer, the Osborne 1, is unveiled. The 25-pound unit was designed to fit underneath an airline seat. One problem for users was the machine's minuscule 5-inch display.

Today: Many Sleek Compact and Portable Devices

Wireless Sensor Nodes

Micro-sensors
Sensor module (e.g., acoustic, seismic, image) A digital processor for signal processing and network protocol functions Radio for communication (Zigbee/IEEE 802.15.4) Battery-operated, but increasingly focus on energy-scavenging

Sensors monitor environment

Cameras, microphones, physiological, magnetic, pressure, biological sensors, etc. Gather data for some purpose

Fun with a Single Sensor/Actuator: Pickles (March 26, March 24)

Wireless Sensor Networks (WSNs)

Sensor data limited in range and accuracy
Each node can only gather data from a limited physical area of the environment Data may be noisy

Tens, hundreds, thousands of nodes scattered throughout an environment Sensor nodes have to be cheap Each sensor can collect data Data routed via other sensors to
One or more sink or base station nodes Other sensors

Networking sensors enables

Extended range of sensing improved quality Fault tolerance due to redundancy in data from different sensors Distributed processing of large amounts of data Duty-cycling individual nodes Scalability: quality can be traded for system lifetime Team-work: nodes can help each perform a larger sensing task

Complete Architecture: multiple WSN, fixed Core (Example: surveying multiple airports, border crossings, etc.)

Event collection & presentation

IP Router
Monitoring data processing Event dissemination 1st responder notification

XML Routed Network

XML Router

Wireless Transceiver

Monitored Area

Sensor

IP
sensor data collection and archive: information made available via web services

Fun with Networked Sensors

Wireless Sensor Networks: Examples

WSN Applications
Many ways to categorize them
IEEE Computer, August 2004: special issue on sensor networks Monitoring Space Habitat monitoring, precision agriculture, surveillance, treaty verification, indoor climate control, . Monitoring Things Structural monitoring, ecophysiology, medical diagnostics, urbain terrain mapping, . Monitoring interaction of Things with each other and surrounding Space Wildlife habitat, disaster management, pervasive computing, asset tracking, manufacturing process flow, . 2008 PhD Thesis Disaster Relief and Response Medicine and Health Care Environmental Monitoring and Control Intelligent Buildings Military Applications

Key point: lots of applications

Example Application: Environmental Monitoring

Example projects
ZebraNet Ecology of rare plants in Hawaii California Redwood Forest (first real example) Great Duck Island: bird monitoring

Collecting detailed data about some phenomenon can help advance respective science/knowledge

A New Instrument for the Sciences

"Nothing tends so much to the advancement of knowledge as the application of a new instrument. The native intellectual powers of men in different times are not so much the causes of the different success of their labours as the peculiar nature of the means and artificial resources in their possession. -Sir Humphry Davy
exponent of the scientific method; discoverer of sodium and potassium.

Contaminant Transport

Seismic Structure Response

Embedded Networked Sensing helps reveal previously unobservable phenomena

NY Times, May 10, 2005

Marine Microorganisms

Ecosystems, Biocomplexity

10

Example Application: Firebug

The FireBug system is composed of a network of GPS-enabled, wireless thermal sensors, a control layer for processing sensor data, and a command center for interactively communicating with the sensor network. (http://firebug.sourceforge.net) Challenges: 1) How to detect fire (i.e., processing the sensor readings) 2) Harden the sensors (collect more info longer) 3) Ensure sensor nodes work

Example Application: CodeBlue

Collect heart rate (HR), oxygen saturation (SpO2), and EKG data, relay it over a short-range (100m) wireless network to any number of receiving devices Display data in real time. The sensor devices process the vital sign data, for example, raise an alert condition when vital signs fall outside of normal parameters. Any adverse change in patient status signaled to a nearby medical expert. Challenges: wearable sensors, reliability, QoS/prioritization, privacy, .

11

Example Application: Smart Homes

(Specific Example from http://www.cs.virginia.edu/wsn/medical/index.html)

Smart Homes (cont.)

Challenges: 1) Privacy/Security 2) Ease of operation 3) Acceptance 4) Change over time 5) ..

12

Example Application: Tunnel Safety

(Scenario developed by RUNES project: http://www.ist-runes.org/)

Communications of the ACM, March 2008

Cover story: collect information from users in urban environments -Rich sensing infrastructure (CCTV, RFID, ) -Cellphones: location, sound, sight (camera) -additional sensors in cellphones New data collection paradigm: -Previous: fully centralized sensing -Now: participatory sensing, distr. sensing Raises questions about who owns and has access to what data, build data repositories/commons Web 2.0 and OSS model: Participatory collaborative efforts between citizens and scientists, artists, business, May or may not be a good thing

13

WSN Applications: Summary

Original applications very much driven by this idea of a new instrument to advance science
See also NEON (http://www.neoninc.org/), the National Ecological Observatory Network

Later, more applications about impacting everyday life in new and useful ways (includes humans in the loop very much)
FireBug: monitor for fire fronts, help firefighters to combat fire, warn them about changes, etc. CodeBlue: monitor patients, alert medical personal Smart Homes: allow elderly/sick to stay at home, in their usual environment RUNES: provide improved tunnel safety

All applications above are still single-purpose WSN: designed for one purpose, run by a single organization, very centralized approach What happens if single WSN supports many different applications for different users (resource scheduling and contention), application requires data from multiple sensors/domains/networks,

WSN Challenges

14

WSN Limitations
Communication
Bandwidth is limited and must be shared among all the nodes in the sensor network Spatial reuse essential Efficient local use of bandwidth needed

Sensor energy
Each sensor node has limited energy supply Nodes may not be rechargeable Eventually nodes may be self-powered Energy consumption in sensing, data processing, and communication Communication often the most energy-intensive For some sensors (e.g., imagers), sensing may also be energy-intensive Must use energy-conserving protocols

Sensor node limitations

Limited memory Slow CPU Nodes prone to failure (cheap, mass-produced) Redwood study: 30% of sensors failed, no monitoring system to revive them

Diversity of Application Characteristics

Seismology Sampling Rate Sampling Density Sample resolution Spatial Extent Estimation Fidelity Latency Lifetime Access Cost Platform Cost Platform mobility Where is the answer needed? Nature of Task KHz Km 24 bit 100 Km2 High Minutes-Days Months Medium High No Centrally Source Ecology < Hz Meters 8 bit 1 Km2 High Hours-Months Years Medium Medium Yes Centrally Field Battlefield KHz Meters 8 bit 10 Km2 High Seconds Weeks High High Yes Distributed Source

Are there reusable architectures, platforms, design tools, run-time services, estimation algorithms etc.? Answer is probably still out Standards are being developed: TinyOS, Zigbee, etc. Lots of efforts still going on to develop customized solutions (for example, http://www.thisisant.com)

15

Typical Sensing Application: Lots of Communalities

Sensor Node

Sensor
Sensor duty cycle period determined by latency and dynamics Sample rate determined by signal b/w

CPU

Radio

Periodic tasks Triggered Events Long Lifetime Key design principles

Sleep: majority of the time (>99%) Wakeup: quickly start processing Active: minimize work & return to sleep

# of samples determined by sensor characteristics

Sensor Processor
Rare EVENT

Radio Tx

What design and operation principles have emerged?

Marginal energy cost of communication >> energy cost of computation
Energy per bit / Energy per op ~ > O(100) - O(1000) Every bit transmitted brings a sensor node one moment closer to death In-network processing important! Collaborative signal processing, localized algorithms for desired global behavior

Tx power ~> Rx power, Tx energy << Rx energy

Short range makes Rx relatively expensive Nodes spend most of their time idle Putting nodes to sleep and minimizing reception is important

High cost of data acquisition

Obstacles, uncertainties Adaptive sampling is important Exploiting spatio-temporal correlations, physical models, and actuation

Hierarchical and heterogeneous sensor field, as opposed to flat fields

Complementary energy efficiency vs. power management efficiency behavior Mix of nodes of different capabilities: StarGates or PASTA (32b, 400 MHz, 802.11b) vs. Motes (8b, 8MHz, Chipcon) E.g. Tripwires vs. Tracker

16

What design and operation principles have emerged? (contd.)

Data-centric organization of the network
Id of nodes dont matter - the data value does! Attribute-based addresses and routing Sensor networks as active databases

Avoiding communication overheads of indirections

Internet-like multiple levels of indirections (search engine, DNS, routing) not acceptable in the resource-constrained embedded arena

Modeling the statistics and the physics of the phenomena

Efficiency: node sleep scheduling, when and where to sample Integrity: fault detection, missed data compensation

Exploiting of data correlation in local neighborhood

Without that, network doesnt scale (seminal result by Gupta & Kumar)

Multidisciplinary Challenges
Embed numerous distributed devices to monitor and interact with physical world Network devices to coordinate and perform higher-level tasks

Embedded
Control system w/ Small form factor Untethered nodes

Networked
Exploit collaborative Sensing, action

Sensing & Control

Tightly coupled to physical world

Exploit spatially and temporally dense, in situ, sensing and actuation

Large-scale Distributed Real-time (control, events) Physically-coupled

Unattended Resource-constrained Wireless Collaborative computations

Combines the hard problems of the Internet, Embedded Systems, Wireless Networks, and Distributed Computing!

17

Lifecycle of a Sensor Network

Design
What h/w and s/w platform to use? How to organize the application? What are good programming abstractions?

Deployment & Configuration

How many nodes? Where should the nodes be placed? How to discover address, location, clock etc.?

Runtime: Inside the network

How to route queries to the nodes? How to estimate and exfiltrate the answers? How to maintain location, time, calibration etc.? How to operate in an energy-aware manner? How to manage the network?

Runtime: At the back-end

How to manage the network? How to visualize and manage the data from the sensor network? How to interface with the applications/users?

WSN Application Development Challenges

Sensors and Actuators (mostly sensors): what types/characteristics Programming-in-the-Small
Hardware platform severely resource constrained: what OS/Middleware to program a single node?

Programming-in-the-Large
WSN are large: programming abstractions for programming and reprogramming 100s or 1000s of nodes Software development tools: Testing applications before deployment Monitoring nodes

WirelessNetworking
Design of network protocol stack (layered, cross-layered, .?) New WSN-specific protocol paradigms (data-centric routing, security, energy-efficient protocols, .) New protocol requirements (localization, clock synchronization, in-network data aggregation, coverage and topology control, )

Wired Networking:
impact of sensor data flows how to route what data to interested parties discovering sensors/WSN

18

Canonical Sensor and Actuator Node

actuator

Far cry from general purpose computers!

Electro-magnetic interface
CPUs
8 b / 8 MHz to 32 b / 400 MHz 2 KB - 64 MB RAM 1 MB - 1 GB Flash No disk 38 Kbps / 10 m - 802.11b / 100 m 30 mW - 3 W

Acoustic, seismic, image, magnetic, sensors etc. interface

CPU

radio

Storage

battery

Radio

Limited energy supply

Power

Ideally, all integrated on a single chip!

Sensors
Vast majority of work uses Sensors, few examples include actuators Used to be taken for granted, but
Sensor capabilities determine core WSN functionality (hence new sensor developed all the time) Sensors may consume a significant amount of energy (cameras, for example) Provide very different types and amount of data, may be programmable/controllable Biomedical sensors have unique constraints Calibrating sensors is not trivial even for trivial sensors

Example: Open GeoSpatial Consortium (http://www.opengeospatial.org/)

SensorML: version 1.0 approved July 2007 The primary focus of SensorML is to define processes and processing components associated with the measurement and post-measurement transformation of observations. TransducerML: version 1.0 approved July 2007 TML defines: a set of models describing the response characteristics of a transducer an efficient method for transporting sensor data and preparing it for fusion through spatial and temporal associations

19

Trade-offs among Nodes

StarGate

Capabilities

XYZ

MICA Mote
Microcontroller (8 16b) Narrow Band radio Low bit rate, low performance sensors Long relative lifetime at continuous operation

Size, Power Consumption, Cost

Microprocessor (32b) Broad Band radio High performance sensors Short relative lifetime at continuous operation

Various Energy Costs

Energy/bit >> Energy/op even for short ranges!
Transmit Receive Transmit Receive 720 nJ/bit 110 nJ/bit 6600 nJ/bit 3300 nJ/bit Processor 4 nJ/op

Mote-class Node

~ 200 ops/bit Processor 1.6 nJ/op

Microserver-class Node

~ 6000 ops/bit

Even larger in actuality, due to protocol overheads

E.g. Effective energy/bit on Mica2 0.01-0.1 mJ

Energy/bit sent ~ Energy/bit stored

802.15.4 radio (250 kbps): 0.2 J/bit (1 byte @ 1.5 J, 32 s) Atlmet flash: 0.4 J/bit (1 byte @ 3 J, 78 s) However, for high density Flash storage costs go down

20

The Dominant OS for Mote-class Platforms: TinyOS

Not really an operating system in the traditional sense More like an application specific operating system Application = Scheduler + Graph of Components Concurrency Model - Event-driven architecture Naturally implies a Single shared stack Static memory allocation, whole program analysis and optimization Programming in NesC, an extension of C

Both OS and application written in NesC

TinyOS: Pros and Cons

Pros
Static memory allocation => resource guarantee. Non-preemptive scheduling => minimal memory requirement. Modularized language => allow independent software development.

Cons
A new programming language Static memory allocation => resource over subscription. Not really an OS. Blur resource abstraction. No resource management. Simple concurrency model => lots of critical sections. Monolithic firmware image hard to reconfigure dynamically

21

Beyond TinyOS
Three key aspects of TinyOS
Component model (static graph) Concurrency model (foreground-background, non-preemptive FIFO scheduled tasks) Memory model (static)

Newer sensor OSs pushing boundary in each of these three dimensions

Reconfigurable component models Proto threads Dynamic memory with ownership tracking etc.

Why software reconfiguration?

Sensor networks require uninterrupted operation indefinitely Post-deployment software updates are common
Customizing the system to the environment Feature upgrades Bug removal Re-tasking of the system

E.g. sensor networks for environmental observation evolving towards a shared observatory model
NSF NEON initiative

Re-programming a deployed system is hard Remote reprogramming is essential for sustainability

22

Reconfiguration Options

Update Cost (Transport + Storage)

Entire Image (TinyOS) Modular Binary (SOS) Differential Binary Patching Lightweight Scripts (VMs - e.g. Mat)

Flexibility

SOS: A Dynamic Sensor Node OS

Embedded OS with built-in support for remote (wired or wireless) code configuration
Retasking the system Customizing to deployment environment Sharing the system among concurrent users and missions Upgrades, bug fixes, feature additions

Approach
Execution environment with capability to remotely insert and remove binary modules without disruption in mote-class devices Efficient multihop module distribution protocol

Dynamic Modules
Dynamic Loadable Binary Modules Dynamic Loadable Binary Modules Drivers, protocols, and applications Inexpensive to modify after deployment Position independent

Static SOS Kernel Hardware Abstraction Module Communication Memory Manager

Static Kernel
Hardware abstraction and common services Costly to modify after deployment Data structures to enable module loading

23

Other OS for Low-end Sensor Nodes

Nutt/OS
Used by Btnode Non-preemptive multithreading, events, periodic and one-shot timers, dynamic heap memory allocation, inerrupt driven streaming I/O, TCP/IP stack, graphical configurator http://www.ethernut.de/en/software/index.html

Contiki
Event-driven kernel, neat light-weight protothread feature, per-process optional pre-emptive multithreading, TPC/IP stack, GUI subsystem with VNC support, loading and unloading of programs http://www.sics.se/~adam/contiki/

Mantis
Thread-based kernel with subset of POSIX threa API http://mantis.cs.colorado.edu/

uC/OS-II, uClinux etc. Note: for high-end sensors, increasingly use (embedded) Linux

Programming-in-the-Large
How do we task a 1000+ node dynamic sensor network to conduct complex, long-lived queries and tasks ?
What constructs does the query language need to support?

What sorts of mechanisms need to be running in the background in order to make tasking efficient?
Small databases scattered throughout the network, actively collecting data of nearby nodes, as well as accepting messages from further away nodes? Active messages traveling the network to both train the network and identify interesting or anomalous conditions?

24

System Level Programmability

The user issues a query to the network and the nodes are tasked autonomously. Database model: Network is seen as a distributed database (e.g., TinyDB, Cougar) Active sensor approaches: adaptation of the AN idea (e.g., Mat, Smart Messages) + Intuitive - No control over the distributed algorithm executed + Expressive in terms of distributed algorithms - Added responsibility to specify distributed algorithm

Macroprogramming
Higher level programming designed to remove node specifics from sensor network programming Abstractions
Basic How should the network be exposed, how to do distributed control and data flow, etc. How to be language agnostic Advanced Allow dynamic user-level control of heterogeneity, resource management,

Robustness
How to programmably discover, recover from, and tolerate faults

Efficiency
How to minimize energy consumption by optimizing network traffic How to minimize the effect of a layered architecture on nodes

25

The Big Picture

Abstractions vs. Support
Abstractions: Provide programmers with abstractions of sensors and sensor data. Support: Provide additional runtime mechanisms that simplify program execution

Global vs. Local Behavior

Local: Provides the programmer abstractions that simplify the task of specifying the node local behavior of a distributed computation Global: Provides the programmer with an ability to express the global behavior of the distributed computation

Macroprogramming Space
Macroprogramming

Abstractions

Support

Global Behavior

Local Behavior

Composition
Snack DFuse Sensorware

Safe Execution
Mate Tofu Agilla Sensorware

Services
Impala Emstar

Node Dependent Kairos Regiment

Node Independent Database (TinyDB, Cougar, etc.) Astrolabe DFuse

Data/Task Centric EIP Statespace Sensorware Agilla

Geometric Regions Hood

26

Database Model
Macroprogramming

Abstractions

Support

Global Behavior

Local Behavior

Composition

Safe Execution

Services

Node Dependent

Node Independent Database (TinyDB, Cougar, etc.)

Data/Task Centric

Geometric

Why Database Model?

Sensor networks are capable of producing massive amounts of data
Sensor networks should be able to Accept queries for data Respond with results Users will need An abstraction that guarantees reliable results Largely autonomous, long lived network

Efficient organization of nodes and data will extend network lifetime

Database techniques already exist for efficient data storage and access

27

Traditional Databases vs. Sensor Network Database Model

Traditional Database
Static data Centralized Failure is not an option Plentiful resources Administrated

Sensor Network
Streaming data Large number of nodes Multi-hop network No global knowledge about the network Frequent node failure Energy is the scarce resource, limited memory Autonomous

Traditional Approach: Warehousing

Data is extracted from sensors and stored on a front-end server Query processing takes place on the front-end.

Warehouse

Front-end

Sensor Nodes

28

Sensor Network as a Database

Sensor Database System model supports distributed query processing over a sensor network
Sensor DB Sensor DB Sensor DB

Front-end
Sensor DB

Sensor DB

Sensor DB Sensor DB

Sensor DB

Sensor Nodes

Performance Metrics
High accuracy
Distance between ideal answer and actual answer? Ratio of sensors participating in answer?

Low latency
Time between data is generated on sensors and answer is returned

Limited resource usage

Energy consumption

29

Representing Sensor Data and Sensor Queries

Sensor Data:
Output of signal processing functions Time Stamped values produced over a given duration Inherently distributed

Sensor Queries
Conditions on time and space Location dependent queries Constraints on time stamps or aggregates over time windows Event notification

The Tiny Aggregation (TAG) Approach

Push declarative queries into network
Impose a hierarchical routing tree onto the network

Divide time into epochs Every epoch, sensors evaluate query over local sensor data and data from children
Aggregate local and child data Each node transmits just once per epoch Pipelined approach increases throughput

Depending on aggregate function, various optimizations can be applied

30

SQL-like syntax
The sensors relation (table) has one column for each reading-type one row for each value
SELECT AVG(light) FROM sensors WHERE sound < 100 GROUP BY roomNo HAVING AVG(light) < 50

SELECT FROM WHERE GROUP BY HAVING EPOCH DURATION

{aggn(attrn), attrs} sensors {selPreds} {attrs} {havingPreds} s

Hood: Neighborhood abstractions for sensor networks

Macroprogramming

Abstractions

Support

Global Behavior

Local Behavior

Composition

Safe Execution

Services

Node Dependent

Node Independent

Data/Task Centric

Geometric Hood

31

Hood
Neighborhood is a common concept Hood supports neighborhood as a programming primitive Neighborhood-based algorithms are decomposed into
Neighbor lists Data caches Messaging Protocols

The Hood Abstraction

Sharing and viewing of neighbor attributes What data? Which nodes? Multiple neighborhoods Get/set interface Broadcast/Filter mechanism
Discovery and data sharing Decouples owners from observers Asymmetry Suitable for wireless sensor networks Cheap broadcast No handshaking Weak sharing semantics

32

WSN: Networking

WSN Network Challenges

What is the right design philosophy? How to solve traditional network problems
Enable end-to-end communication (routing, medium access, sequencing, error control, flow control, congestion control, reliability, QoS, .)

How to revisit/redesign known protocols under energy-constraints New protocol challenges (network protocols: nodes jointly solve a task)
Topology control: ensure all sensors are connected, even if some sensors sleep or use less than maximum transmission power Coverage: ensure that set of currently no sleeping sensors cover the area, given a certain sensing range (maybe ensure n-times coverage) Clock Synchronization Localization

33

Networking: Traditional Layered Architecture

Application Transport Network MAC Physical Channel

FTP - A TCP - A

C A

D TCP - E

E FTP - E

Cross-layer Architectures
Application Transport Network MAC Physical Conventional Application Transport Network MAC Physical Cross-layer Application & Transport

Network & MAC

Physical

34

Core Functionality for many WSN: Clock Synchronization and Localization

Clock synchronization is critical at many layers
Beam-forming, localization, distributed DSP, MAC Tracking; data aggregation & caching

Similarly, localization is fundamental

Routing, security, location-aware services, Tracking; data aggregation & caching

t=1 t=3 t=2 t=0

Localization
Many devices embedded in real-world artifacts, so GPS is not an option
Tunnel: no LOS to satellites, unlikely to upgrade tunnels with pseudolites Also imposes additional cost on sensor nodes and drain on energy

Software-based solutions
Communicate with neighbors to determine location Iteratively, starting with nodes with known locations (anchors), will provide either relative or absolute location information Cooperatively (relative location information) If some nodes are anchors, can turn this into absolute location info Ranging measurements based in wireless interface helpful where available, but not always available or of sufficient accuracy to be useful SNR not a really good indicator of distance (noise, non-linear relationship) UWB: more accurate ranging possible

35

Basics of Localization

Iterative Trilateration/Triangulation: utilize distance/angle information between the node and the anchor nodes
Often requires high volume of anchor nodes (12 channel GPS receiver better than 8 channel) Iterations of messaging

Cooperative Localization: joint utilization of all connectivity/distance information among all nodes
Require minimum anchor nodes or anchor free High level of accuracy Computationally intensive

Results: Network Topologies

10

10 10
8

8 6 4

8 6 4 2 0 5 10 0 0 5 10

2 0

(b)

(c)

10

(a)

C-shaped network, 160 nodes

Random topology, 200 nodes

Uniform grid (with small placement errors) 100 nodes

36

Results: Random Topologies

(a) Range-based: 3 anchor nodes 0.2
Median Error (r) (a) Range free: 3 anchor nodes 0.5 0.4 0.3 0.2 0.1 MDS-MAP(P,R) CCA-MAP

Median Error (r)

0.15 0.1 0.05 0 5

MDS-MAP(P,R) CCA-MAP

0.2 Median Error (r) 0.15 0.1 0.05 0

15 20 25 Connectivity (b) Range based: 10 anchor nodes MDS-MAP(P,R) CCA-MAP

10

30
0.4 Median Error (r) 0.3 0.2 0.1 0

10

15 20 25 Connectivity (b) Range free: 10 anchor nodes MDS-MAP(P,R) CCA-MAP

30

10

15 20 Connectivity

25

30

10

15 20 Connectivity

25

30

Network Time-Synchronization
Objective => To align the time processes T(t) of all the clocks belonging to a network through the use of the links (wireless in our case) used for communication purposes. A clock:
Oscillator Counter

dT =1 dt

Tp

Periodic epochs of events (Tp)

Clocks are inaccurate (run at different speeds): IEEE 802.11 requires clocks with 25 ppm accuracy IEEE 802.15 requires clocks with 40 ppm accuracy

>4 secs drift/day >6 secs drift/day

37

Some Network Time-Synchronization methods

Reference Broadcast Synchronization (RBS): Fundamental idea is to eliminate uncertainty when transmitting timing info. by using receiver-based synchronization
Reference node Tx. Time info.

Excessive Overhead Hu and Servettos Protocol: Node Located in the networks center of mass (How to find it? What if it breaks?)

Rx

Rx

Rx

Receiving nodes Rx. time info. at same time and then exchange their observations

Many more, but

Standard Network Synchronization approach (IEEE 802.11 TSF) T(t) 1 2 3

1

TSF advantages: Distributed Simple

44 33 11

55

22

2 3 4
5

TSF disadvantages: Marginally convergent Not scalable

aBeaconPeriod

38

The extended TSF

First idea: improve basic TSF
What if a station is allowed to transmit Its beacon even after having successfully received one?
1 0.9 0.8 0.7 Pgiven 0.6 0.5 0.4 0.3 0.2 0.1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 N umber of nodes Pgiven of IEEE 802.11 TSF (Analysis) Pgiven of Extended TSF (Analysis) Pgiven of Extended TSF (Simulation)

Maybe, but overhead is increased, and only marginal improvement

1 0.9 0.8 Pany of IEEE TSF with DSSS PHY. Pgiven of IEEE TSF Pany of IEEE TSF with DSSS PHY
The diffe re nce be twe e n Pany and Pgive n sugge sts a pote ntial gain by using the information carrie d in any be acon trans mitte d succe s sfully

What if ALL beacons transmitted are used for synchronization?

Pany and Pgiven

0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 2

How?

10

20

40 60 Number of nodes

80

100

150

CSMNS: Clock-Sampling Mutual Network Synchronization

T(t)

3
4 4 3 3 1 1 2 2 5 5

1 2 3 4 5

CSMNS: Non-hierarchical Convergent Distributed Scalable Simple

39

Local WSN Research

WSN Research in National Capital Region (very partial)

WSN Sensors
Safenet/SENECA: photonic sensors Biomedical Researchers (Carleton, U of O)

WSN Network Protocols

SCE CRC (http://www.crc.ca/en/html/manetsensor/home/home) DRDC Ottawa (Security) WiSense: Wireless Heterogeneous Sensor Networks in the e-Society (lead U of O) Alcatel/Bell Labs: impact on fixed networking

WSN OS/Middleware
????

WSN Testbeds/Prototypes
CRC SCE

40

Additional Work: WSN Security

Work with one PhD student Properly authorized and authenticated access to sensor data important for many WSN applications
Assisted living: only authorized medical personal/caregivers/relatives should have access to medical data, not your insurance company WSN at home: dont allow burglars to deduce state of home occupancy

Assumption: no central online entity, no pre-configuration

Make it easy to set up WSN for everyday users WSN will grow over time (new sensors as occupants age, technology improves, )

Research question: how to bootstrap and manage trust

Derive node ID for each node from RF fingerprint If successful, prevents man-in-the-middle attacks, sybil attacks (really bad for reputationbased trust systems) Unique? Time-invariant? Forgeable by adversaries with SDR? Extend local knowledge to network-wide protocols

Additional Work: Network Coding

Work with one PhD student, co-supervised with Prof. Banihashemi Original network coding work done for fixed point-to-point networks Capacity is more of a wireless network problem, in particular for multihop wireless communication
Scaling laws Measurements in real testbeds Design of Wireless Mesh Networks: limit max wireless hops to 2 or 3

Application of network coding to wireless network very simplistic/opportunistic

XOR of data packets (sometimes subject to size) Coding happens over single hops only Network coding not always promising (in particular with rate-adaptive radios)

Throughput bounds for multihop wireless networks Network coding in the presence of link/node/route errors

41