wireless sensor networks review professor jack stankovic university of virginia
TRANSCRIPT
Wireless Sensor Networks
Review
Professor Jack Stankovic
University of Virginia
Review OutlineReview Outline
• Architecture – Where all this fits
• Clock Sync• Power Management• Database View of WSN• Programming Abstractions• Security and Privacy (questions?)
WSN Architecture ExampleWSN Architecture Example
Clock Sync ProtocolsClock Sync Protocols
• NTP (Network Time Protocol) – for Internet
• RBS (Reference Broadcast Sync)• TPSN (Time-sync Protocol for Sensor
Networks)
• FTSP (Flooding Time Sync Protocol)
NTPNTP• Network Time Protocol (NTP) on Internet
– Included in OS code– Simple NTP (SNTP) exists for PCs– Runs as background process– Get time from “best” servers
• Finds those with lowest jitter/latency• Depends on wired and fast connections
– Use statistical analysis of round trip time to clock servers
– Clock servers get time from GPS
NTPNTP
• Not (directly) usable for WSN– Complex – see 50 page document– Continuous cost– Large code size– Expensive in messages/energy
Clock Sync DelaysClock Sync Delays• Uncertainties of radio message
deliveryApplication
Routing
MAC
RADIO
Application
Routing
MAC
RADIO
Send timehighly non-
determ(100ms)
Access time (ms - s)
Transmission time (10ms)
Propagation time (< 1microsec)
Reception time (10ms)
receive timehighly non-
determ(100ms)
RBSRBS
• Reference message is broadcast• Receivers record their local time when message
is received– Timestamps are ONLY on the receiver side– This eliminates access and send times
• Nodes exchange their recorded times with each other
• No transmitter side non-determinism
RBSRBS
5
6
7
Local Time
Send MSGNo Clock
6,7
5,7
5,6
Exchange AdjustPlus 2
Plus 1
OK
Propagation Time = 0
TPSNTPSN
• Creates a spanning tree• Perform pair-wise sync along edges
of the tree• Must be symmetric links
– Recall radio irregularity paper
• Considers “entire” system– RBS looks at one hop
• Exchange two sync messages with parent node
Synchronization PhaseSynchronization Phase
• Delta = clock drift• P = propagation delay
T1
T2 T3
T4
Node A
Node B
P = ((T2-T1)+(T4-T3))/2 Delta = ((T2-T1)-(T4-T3))/2
Node A corrects its clock by DeltaNote: Sender A corrects to clock of receiver B
T2=T1+P+Delta
(T1) (T1,T2,T3)
ExampleExample
T1= 5.0
T2=5.35 T3=6.0
T4=5.75
Node A
Node B
P = ((T2-T1)+(T4-T3))/2 Delta = ((T2-T1)-(T4-T3))/2P= ((5.35-5.0)+(5.75-6))/2 Delta= ((.35)-(-.25))/2P=((.35)+(-.25))/2 Delta= 0.6/2 =.3P= .1/2=.05
5.3
.05 .05
5.7
So A adds .3 to 5.75 to get 6.05Only need Delta to adjust clocks
5.05
Read Clock in MAC Layer Read Clock in MAC Layer • Uncertainties of radio message
deliveryApplication
Routing
MAC
RADIO
Application
Routing
MAC
RADIO
Send timehighly non-
determ(100ms)
Access time (ms - s)
Transmission time (10ms)
Propagation time (< 1microsec)
Reception time (10ms)
receive timehighly non-
determ(100ms)
Flooding Time Sync Protocol (FTSP)
Flooding Time Sync Protocol (FTSP)
• ~1 Microsec accuracy• MAC-layer timestamp• Skew compensation with linear
regression (accounts for drift)• Handles large scale networks
Remove UncertaintiesRemove Uncertainties
• Eliminate Send Uncertainty– Get time in the MAC layer
• Eliminate Access Time– Get time after the message has access
to the channel
• Eliminate Receive Time– Record local time message received at
the MAC layer
RemainingRemaining
• (Mostly) Deterministic Times– Transmit – Propagation– Reception
Basic IdeaBasic Idea• When to time stamp the message
cpu:
radio:
antenna:
cpu:
radio:
antenna:
radio:
Interrupt handling
encoding
propagation
decoding
byte alignment
Interrupt handling
sender
receiver
Mica2 uncertainties:
Interrupt:5us, 30us(<2%)
Encode+decode:110us -112us
Byte align: 0us – 365us
Propagation: 1us
Get timestamp
Set timestamp
Ready
Basic IdeaBasic Idea• When to time stamp the message
– Radio layer, after the second SYN sent out, 6 timestamps in row, take the average and send only 1 timestamp
RADIO
PreamblesSYNSYNDATACRC
T0Ti
Normalize and then take Average of these
timestamps for 6 bytes of data
Why take 6 samples?Why take 6 samples?
• Because of all the uncertainties as described in a previous slide
FTSPFTSP
• Root maintains global time for system
• All others sync to the root• Nodes form an ad hoc structure
rather than a spanning tree
Clock Drift - Basic IdeaClock Drift - Basic Idea
• 8 entry linear regression table to estimate clock skew (each entry derived from 1 clock sync protocol execution)
Example
1 5 us offset2 5 us offset3 7 us offset4 4 us offset5 4 us offset6 5 us offset7 7 us offset8 5 us offset
5 us overSay a 10 secResync period
Compensate .5 usEach sec
10 seconds
1 sec
Multi-HopRoot/Reference Point
Multi-HopRoot/Reference Point
Root/Reference Point
Step 1
Step 28 sync msgsto performLinear regression
How to handlemessages frommultiple nodes
Root Election ProcessRoot Election Process
• If no sync message for time T, declare myself to be root
• May be multiple roots• Smallest ID wins; so roots will give
up their root status when it eventually gets a sync message from another root with lower ID
Power ManagementPower Management
• Hardware layer• MAC layer - review• Routing layer – review• Localization and Clock Sync - review• Overarching power management
schemes– Sentry service– Tripwire service– Duty cycle– Differentiated surveillance
Power Management- Hardware layer
Power Management- Hardware layer
• Turn off/on– CPU – Memory– Sensors– Radio (most expensive)– Fully awake ………… Deep Sleep– Dynamic voltage scaling also possible
• SW ensures a node/components are awake when needed
ArchitectureArchitecture
Sentry-Based Power Management (SBPM)Sentry-Based Power Management (SBPM)
• Two classes of nodes: sentries and non-sentries
– Sentries are awake – Non-sentries can sleep
• Sentries – Provide coarse monitoring & backbone communication network– Sentries “wake up” non-sentries for finer sensing
• Sentry rotation– Even energy distribution– Prolong system lifetime
• Decentralized Algorithm–See photo
1
4
3
2
Tripwire Service – Scaling to 1000s
Tripwire Service – Scaling to 1000s
10-N dormant sections
...
...
...
...
...
...
...
...
……
……
N Tripwire sections
...
...
...
...
...
.........
...
...
...
...
……
……
……
10 relays
Suggest N = 2
100M
1000m
Network partitioning• 2 tripwire sections• 8 dormant sections• 100 motes, 1 relay
per section• Size and number of
sections reconfigurable
• Rotate sections
Sentries• N% in tripwire
section• Rotate sentries
Sensing Coverage = 100%Sensing Coverage = 100%
Basic design with 100% sensing coverage
Basic design with 100% sensing coverage
• Solution – 100% Grid point sensing coverage– Divide whole network into virtual grids– For each grid point x, guarantee that x is covered by at
least one node’s sensing range at ANY time
r
Decide Working ScheduleDecide Working Schedule
• Schedule example
If we want to provide sensing coverage for point x, we can have either A or B or C awake.
B
A
C
Point x
Node A
Node B
Node C
Waking Sleeping
0 10030 70
10 60
5 45
time
Scheduling example for A, B and C
Decide Working ScheduleDecide Working Schedule
• Challenge: For each node, how to coordinate with other nodes and decide its own schedule?– Solution - Random Reference Point
Scheduling Algorithm
Decide Working ScheduleDecide Working Schedule
• Concepts– A node’s working schedule is
determined by a four parameter tuple – (T, Ref, Tfront, Tend)
Decide Working ScheduleDecide Working Schedule
• Solution – Random Reference Point Scheduling Algorithm1) Each node N chooses a “Reference Point (Ref)”
randomly from [0, 100) and broadcasts its Ref and position.e.g. T = 100, RefA = 40, RefB= 90, RefC = 20
2) For each grid point P in its own sensing area, N sorts all the Refs from nodes (including N) which can also sense P in ascending order.For A according to point P1, we have:Ref(1) = RefC = 20, Ref(2) = RefA = 40, Ref(3) = RefB = 90
B
A
C
Point P10 refC refA refB
20 40 90
100
Decide Working ScheduleDecide Working Schedule
3) Assuming RefN is the (i)th Ref, N’s four parameter tuple is computed as follows:• TfronN = (Ref(i)- Ref(i-1))/2, 1<i<M• TendN = (Ref(i+1)-Ref(i))/2, 1<i<MTfrontA = (Ref(2)-Ref(1))/2 = (40-20)/2 = 10TendA = (Ref(3)-Ref(2))/2 = (90-40)/2 = 25(T, RefA, TfrontA, TendA) = (100, 40, 10, 25)
4) N’s working period for point P (TwN(P)) is decided by:[T*j + RefN – TfrontN , T*j + RefN + TendN), j = 0, 1, 2, …
TwA(P1) = [100*j+40–10, 100*j+40+25) = [100*j+30, 100*j+65)
0
refC refA refBt
t20 40 90
30 65
Decide Working ScheduleDecide Working Schedule
5) Calculate the union of TwN(Px) for all grid points within N’s sensing area, choose this union as the final working period of N (TwN).
TwA(P1)TwA(P2)TwA(P3)
TwA(Pn)
TwA
.
.
.
0 1005 65
6545
5 50…
B
A
C
Point P1
Enhanced Design with Differentiation
Enhanced Design with Differentiation
• Goal– provide sensing coverage with DOC = a
• a > 1 or a < 1
• Solution– Extend 4-parameter tuple to 5-
parameter tuple (T, Ref, Tfront, Tend, a)– Determine a node’s working period as
follows:• [T*j + Ref – Tfront*a , T*j + Ref + Tend*a)
An ExampleAn Example
Schedule for Grid Point P1 (a=2)
(T, RefA, TfrontA, TendA, a) = (100, 40, 10, 25, 2)
(T, RefB, TfrontB, TendB, a) = (100, 90, 25, 15, 2)
(T, RefC, TfrontC, TendC, a) = (100, 20, 15, 10, 2)
TwA = [T*j + Ref – Tfront*2,T*j + Ref + Tend*2)
= [100*j + 20, 100*j + 90)
TwB = [100*j + 40, 100*j + 120)
TwC = [100*j -10, 100*j + 40)
A
refC refA refB
20 40 90
C
B
0
30 655
Database ViewDatabase View
• Architectures• GHT• TinyDB• SEAD
Architecture (1)Architecture (1)Base StationData Stored hereQueries performed here
Data
Data
Data Data
Architecture (2) Architecture (2)
Base Station
QueriesFlood
Data Stored Decentralized at Each Node
Architecture (3)Architecture (3)
Base Station
Query toRendezvousPoints
Stargates/Log motes
Hierarchical Network
Architecture (4) Architecture (4) DistantWorkStation
Data Stored Decentralized at Each Node Collected by Data Mules
Disconnected System
Geographic Hash Table (GHT)
Geographic Hash Table (GHT)
• Translate from a attribute to a storage location
• Distribute data evenly over the network
• Example: GHT system (A Geographic Hash Table for Data Centric Storage – see Ch 6.6 in text))
GHTGHT
Base Station
QueryStore Tank Info Here
TAG of TinyDBTAG of TinyDB
Base Station
2 Phases (sleep when possible)• disseminate periodic query• collect data (scheduled)
EpochPipelining
SEAD: Scalable Energy Efficient Asynchronous Dissemination Protocol
SEAD: Scalable Energy Efficient Asynchronous Dissemination Protocol
• An asynchronous content distribution multicast tree is maintained
• Tree is modified when– a sink joins– a sink leaves– a sink moves beyond
some threshold
• Cost of building tree is minimized
r1
r4
r3
r2r4
r2
CachingSteinerpoints
Disseminationto Mobile Sinks
Access node
Mobile node
Forwardingchain
Subscription Query (1)Subscription Query (1)
Source
Sink 1 (access node)
Sink 2 (access node)
4 Phases 4 Phases
• Subscription Query– Mobile node attaches to nearest node
as access point– Access node sends join query to source
• Second -Gate replica search– Attach new node on current tree at best
gate replica
Gate Replica Search (2)Gate Replica Search (2)
Source
Sink 1 (access node)
GateReplicas(assume they existfor some currenttree – not shown)
Gate Replica Search (2)Gate Replica Search (2)
Information source
Receivers
Attach to mostappropriate gatereplica
• Saves energy
Adjust ReplicaAdjust Replica
• If node moves and access point is no longer appropriate re-adjust tree in the local area, if necessary
• If new access node can attach without increasing cost then no need for additional replica (i.e., no better neighbors exist)
• If new replica is needed then it is chosen based on minimizing overall cost for this area
4 Phases 4 Phases
• Subscription Query– Mobile node attaches to nearest node
as access point– Access node sends join query to source
• Gate replica search– Attach new node on current tree at best
gate replica
• Third - Replica Placement– Locally adjust the tree to a better
dissemination tree
Gate Replica Placement (3)Gate Replica Placement (3)
Source
Sink 1 (access node)
Sink 2 (access node)
GateReplica
Replica PlacementReplica Placement
• Branch cost must reflect the amount of energy spent on communication along the branch
• Tree cost = branch cost
r1
r4
r3
r2r4
r2
Branch Cost?
Branch Cost MetricBranch Cost Metric
Geographic Forwarding
Branch Cost = Distance x Packet_Rate
Distance
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
1. Broadcast replica request
2. Collect replica cost bids
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
Current cost: Sum of branch
lengths weighted by rate
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
1. Broadcast replica request
2. Collect replica cost bids
3. If local cost decreased,
choose least cost child
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
1. Broadcast replica request
2. Collect replica cost bids
3. If local cost decreased,
choose least cost child
Process Repeated:
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
1. Broadcast replica request
2. Collect replica cost bids
3. If local cost decreased,
choose least cost child
Process Repeated:
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
Current cost: Sum of branch
lengths weighted by rate
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
1. Broadcast replica request
2. Collect replica cost bids
3. If local cost decreased,
choose least cost child
Process Repeated:
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
1. Broadcast replica request
2. Collect replica cost bids
3. If local cost decreased,
choose least cost child
Process Repeated:
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
Current cost: Sum of branch
lengths weighted by rate
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
Can’t reduce cost further.
Replica placement
terminates
Access nodes are NOT
replicas
Cost Minimizing Replica Placement Example
Cost Minimizing Replica Placement Example
Source
Sink 1 (access node)
Sink 2 (access node)
Minimum cost replica
placement found
New Replica
Programming AbstractionsProgramming Abstractions
• Nine types of approaches– Component – nesC
– Environment– Middleware– VM
personevent
Base Station
vehicleevent
object type: VEHICLE object ID: vehicle01
method:report location to thebase station every 5seconds
attribute: location
object type: PERSON object ID: person01
method:turn on a nearby micro-phone if current locationis less than 1 mile awayfrom the base station
attribute: location
mapping
EnviroSuite
Middleware APIsMiddleware APIs
• Group Management– Create– Terminate– Merge– Join/Leave– Assign function
• Track target• Classify target• Map temperature region
– Consensus
Group Management - APIGroup Management - API
– Create_Group(name,function,criterion,atleast,accuracy) - implicit and explicit
– Destroy_Group(name)– Join()– Leave()– Merge()– Move_COG()– Expand() -- to gain sensing confidence– Shrink() -- to save power– Commit(grp_ID) - to synchronize group re-
configurations
ArchitectureArchitecture
API for Other ServicesAPI for Other Services
• Naming• Directory• Location• Monitor• Configure• …
User Defined Instructions User Defined Instructions
TinyOS
Mate VM(interprets)
24 Instruction Programs
Code capsules InstructionsUnderstood byMate
User defined
1 2 3 4
1 3
3
1
- Sound alarm
- Write to flash
Mate ArchitectureMate Architecture
0 1 2 3
Subroutines
Clo
ck
Sen
d
Receiv
e
Events
gets/sets
0 1 2 3
Subroutines
Clo
ck
Sen
d
Receiv
e
Events
gets/sets
Co
de
OperandStack
ReturnStack
PC
Co
de
OperandStack
ReturnStack
PC
Stack based architecture Operand stack Return address stack
Three events/execution contexts:•Clock timer•Message reception•Message send
Code Example(1)Code Example(1)
• Display Counter to LEDgets # Push heap variable on stackpushc 1 # Push 1 on stackadd # Pop twice, add, push resultcopy # Copy top of stacksets # Pop, set heappushc 7 # Push 0x0007 onto stackand # Take bottom 3 bits of valueputled # Pop, set LEDs to bit patternhalt #