CMPE 259
Sensor Networks
Katia Obraczka
Winter 2005
Transport Protocols
1-1
Announcements
 Projects posted.
 Some projects will be presented/discussed
at the end of class today.
 Proposals due by Friday, 01.21.
1-2
1-3
Motivation
 What is expected out of a transport
protocol for sensor networks ?
Reliability, congestion control.
 Why can’t we use the existing protocols ?
Resource constraints – power, storage,
computation complexity, data rates, …
1-4
Motivation ..cont’d.
 Application specific.
 Spectra for known constraints:
Low data Rate
High data Rate
Power limited
Not Power limited
Storage limited
Not Storage limited
Bursty samples
Periodic samples
1-5
Motivation ..cont’d.
In general,
Low data Rate
Power limited
Storage limited
High data Rate
Not power limited
Not storage limited
user
Sink
1-6
SWSP
 Simple Wireless Sensor Protocol.
 Design challenges:
 Limited capabilities.
 Assumptions:
“Fixed network” topology.
 Access points as data collectors.

1-7
Why not TCP?
 Too heavy-duty.
 Congestion control and wireless links.
 Disable congestion control?
 Low bandwidth.
 Buffer size.

Small windows.
 Multiple connections.
 Single connection.
1-8
SWSP overview
1-9
SWSP overview
Power
off
On
Disconnected
Connecting
Ack received
Leave
Connected
Disconnecting
Ack rec’d
Leave
Ack wait
Data
sent
Data request
Requested
Data
sent
1-10
Observations
 Sensor registers with an AP.
Listens for RR messages.
 Sends registration.
 Waits for ACK => “connected” state.

 Window size?
 Periodic KA from sensors.
 Data retransmitted after 3 retries.
 ACKS piggybacked onto RR messages.
 Data piggybacked onto KA messages.
1-11
SWSP evaluation
 Methodology:

Platform:
•
•
•
•

PC with Linux
Simulated different sensors as different processes.
AP simulated using another PC.
Wireless communication.
Metrics:
• Throughput: # of bytes received by AP/time.
• Delay: time(ACK-recv’d) – time(data-sent).
1-12
SWSP evaluation (cont’d)
 Throughput increases up to certain number
of sensors; then decreases as sink gets
overrun.
 Delay increases substantially beyond a
given number of sensors.
 Solutions?
1-13
Event-to-Sink Reliable Transport (ESRT)
for Wireless Sensor Networks
Salient Features:
 Event-to-sink reliability.
S
 Self-adjusting.
 Energy awareness [low power consumption
requirement!].
 Congestion control.
 Different complexity at source and sink.
1-14
ESRT’s definition of reliability
 Reliability is measured in terms of the number




of packets received. Or reporting frequency i.e.,
number of packets/decision interval.
Observed reliability: number of received data
packets in decision interval at the sink.
Desired reliability: number of packets required
for reliable event detection.
Reporting rate: number of packets sent by
sensor over time interval.
Normalized reliability: observed/desired.
1-15
ESRT problem definition
Determine reporting frequency of source nodes to
achieve required reliability at sink with minimum
resource consumption.
1-16
Preliminary observations:
 Reliability increases as reporting frequency
increases up to a certain threshold.
 Why?
1-17
ESRT operation
1-18
Algorithm for ESRT
 If congestion and low reliability: decrease
reporting frequency aggressively. (exponential
decrease).
 If congestion and high reliability: decrease
reporting to relieve congestion. No compromise
on reliability (multiplicative increase).
 If no congestion and low reliability: increase
reporting frequency aggressively (multiplicative
increase).
 If no congestion and high reliability: decrease
reporting slowing (half the slope).
1-19
Components of ESRT
 In sink:
 Normalized reliability computation.
 Congestion detection mechanism.
 In source:
 Listen to sink broadcast
 Overhead free local congestion detection mechanism
E.g., buffer level monitoring, CN – Congestion
Notification
1-20
Performance results
(based on simulations)
 Starting with no congestion and low
reliability:
1-21
Performance results cont’d
 Starting with no congestion and high
reliability:
1-22
Performance results cont’d
 Starting with congestion and high reliability:
1-23
Performance results cont’d
 Starting with congestion and low reliability:
1-24
Performance results cont’d
 Average power consumption while starting
with no congestion and high reliability:
1-25
Challenges with ESRT
 Multiple concurrent events.
 Is there a way to slow down the nodes
causing the congestion ?
 Others?
1-26
PSFQ
1-27
Motivation
 Most sensor network applications do not
need reliability?

Sources => sink.
 New applications like re-tasking of sensors
need reliable transport.

Sink => sources.
 Current sensor networks are application
specific and optimized for that purpose.
 Future sensor networks may be general
purpose to some extent – ability to reprogram functionality.
1-28
Goals
 Simplicity.
 Robustness.
 Scalability.
 Customizability.
1-29
Probability of successful delivery
using end-to-end model
1
(1-p)
2
n-1
n
(1-p)n-1
(1-p)n
p is the error rate of wireless link
1-30
between two hops
Goals of PSFQ: Pump Slowly and
Fetch Quickly




Recover from losses locally.
Minimum signaling.
Operate correctly in lossy environments.
Independent of underlying routing
infrastructure.
1-31
Multi-hop packet forwarding
1
2
1
3
4
1
1
2
2
2
3
3
3
When no link Loss – multi-hop forwarding takes place
1-32
Recovering from errors
1
3
2
1
4
1
1
2 lost
3
3
3
Recover 2
Recover 2
Recover 2
Error recovery messages are wasted
1-33
How PSFQ recovers from errors:
“store and forward”
1
3
2
1
2
1
2 lost
4
1
3
Recover 2
2
2
3
2
3
No waste of error recovery messages
1-34
PSFQ operation
 Alternate between multi-hop forwarding
when low error rates and store-andforward when error rates are higher.
 3 functions:
 Pump:
message relaying.
 Error recovery: fetch.
 Status reporting: report.
1-35
PSFQ Pump Schedule
1
2
1
Tmin
Tmax
t
1
Tmin
Tmax
1
If not duplicate and in-order and TTL not 0 then
Cache and schedule for forwarding at time t (Tmin<t<Tmax)
1-36
“Fetch Quickly” Operation
When loss detected,
then fetch mode.
1
2
1
1
2
2 lost
Tr
3
Recover 2
2
Loss aggregation: try to recover a window
of lost packets.
Tr
Tmin
Tmax
2
1-37
“Proactive Fetch”
1
2
last-1
last
Tproc
last
1-38
Report
 Report aggregation.
 Carries status information: node id, seq. #.
 Triggered by user.
 Inject data message with “report” bit set.
1-39
Performance evaluation
 Compare with SRM (Scalable Reliable
Multicast)
 Performance Metrics
Average Delivery Ratio
 Average Latency
 Average Delivery Overhead

1-40
Experimental setup
2 Mbps CSMA/CA Channel Access
Tmax = 100ms Tmin = 50ms Tr = 20ms
1-41
Error tolerance
1-42
Average latency
1-43
Overhead
1-44
Conclusion - PSFQ
 Light weight and energy efficient
 Simple mechanism
 Scalable and robust
 Need to be tested for high bandwidth
applications
 Cache size limitation
1-45