CMPE 259

1
CMPE 259

• Sensor Networks
• Katia Obraczka
• Winter 2005
• Transport Protocols

2
Announcements

• Projects posted.
• Some projects will be presented/discussed at the
  end of class today.
• Proposals due by Friday, 01.21.

3
(No Transcript)
4
Motivation

• What is expected out of a transport protocol for
  sensor networks ?
• Reliability, congestion control.
• Why cant we use the existing protocols ?
• Resource constraints power, storage,
  computation complexity, data rates,

5
Motivation ..contd.

• 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
6
Motivation ..contd.

• In general,

7
SWSP

• Simple Wireless Sensor Protocol.
• Design challenges
• Limited capabilities.
• Assumptions
• Fixed network topology.
• Access points as data collectors.

8
Why not TCP?

• Too heavy-duty.
• Congestion control and wireless links.
• Disable congestion control?
• Low bandwidth.
• Buffer size.
• Small windows.
• Multiple connections.
• Single connection.

9
SWSP overview
10
SWSP overview
On
Connecting
Disconnected
Power off
Ack received
Leave
Connected
Disconnecting
Ack recd
Data sent
Data request
Leave
Ack wait
Requested
Data sent
11
Observations

• Sensor registers with an AP.
• Listens for RR messages.
• Sends registration.
• Waits for ACK gt connected state.
• Window size?
• Periodic KA from sensors.
• Data retransmitted after 3 retries.
• ACKS piggybacked onto RR messages.
• Data piggybacked onto KA messages.

12
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-recvd) time(data-sent).

13
SWSP evaluation (contd)

• Throughput increases up to certain number of
  sensors then decreases as sink gets overrun.
• Delay increases substantially beyond a given
  number of sensors.
• Solutions?

14
Event-to-Sink Reliable Transport (ESRT) for
Wireless Sensor Networks

• Salient Features
• Event-to-sink reliability.
• Self-adjusting.
• Energy awareness low power consumption
  requirement!.
• Congestion control.
• Different complexity at source and sink.

15
ESRTs 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.

16
ESRT problem definition
Determine reporting frequency of source nodes to
achieve required reliability at sink with
minimum resource consumption.
17
Preliminary observations

• Reliability increases as reporting frequency
  increases up to a certain threshold.
• Why?

18
ESRT operation
19
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).

20
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

21
Performance results (based on simulations)

• Starting with no congestion and low reliability

22
Performance results contd

• Starting with no congestion and high reliability

23
Performance results contd

• Starting with congestion and high reliability

24
Performance results contd

• Starting with congestion and low reliability

25
Performance results contd

• Average power consumption while starting with no
  congestion and high reliability

26
Challenges with ESRT

• Multiple concurrent events.
• Is there a way to slow down the nodes causing the
  congestion ?
• Others?

27
PSFQ
28
Motivation

• Most sensor network applications do not need
  reliability?
• Sources gt sink.
• New applications like re-tasking of sensors need
  reliable transport.
• Sink gt sources.
• Current sensor networks are application specific
  and optimized for that purpose.
• Future sensor networks may be general purpose to
  some extent ability to re-program functionality.

29
Goals

• Simplicity.
• Robustness.
• Scalability.
• Customizability.

30
Probability of successful delivery using
end-to-end model
1
(1-p)
2
n-1
(1-p)n-1
n
(1-p)n
p is the error rate of wireless link between two
hops
31
Goals of PSFQ Pump Slowly and Fetch Quickly

• Recover from losses locally.
• Minimum signaling.
• Operate correctly in lossy environments.
• Independent of underlying routing
• infrastructure.

32
Multi-hop packet forwarding
When no link Loss multi-hop forwarding takes
place
33
Recovering from errors
Error recovery messages are wasted
34
How PSFQ recovers from errorsstore and forward
No waste of error recovery messages
35
PSFQ operation

• Alternate between multi-hop forwarding when low
  error rates and store-and-forward when error
  rates are higher.
• 3 functions
• Pump message relaying.
• Error recovery fetch.
• Status reporting report.

36
PSFQ Pump Schedule
If not duplicate and in-order and TTL not 0 then
Cache and schedule for forwarding at time t
(TminlttltTmax)
37
Fetch Quickly Operation
When loss detected, then fetch mode.
Loss aggregation try to recover a window of lost
packets.
38
Proactive Fetch
39
Report

• Report aggregation.
• Carries status information node id, seq. .
• Triggered by user.
• Inject data message with report bit set.

40
Performance evaluation

• Compare with SRM (Scalable Reliable Multicast)
• Performance Metrics
• Average Delivery Ratio
• Average Latency
• Average Delivery Overhead

41
Experimental setup
2 Mbps CSMA/CA Channel Access Tmax 100ms Tmin
50ms Tr 20ms
42
Error tolerance
43
Average latency
44
Overhead
45
Conclusion - PSFQ

• Light weight and energy efficient
• Simple mechanism
• Scalable and robust
• Need to be tested for high bandwidth applications
• Cache size limitation