cmpe 259
DESCRIPTION
CMPE 259. Sensor Networks Katia Obraczka Winter 2005 Transport Protocols. Announcements. Projects posted. Some projects will be presented/discussed at the end of class today. Proposals due by Friday, 01.21. Motivation. What is expected out of a transport protocol for sensor networks ? - PowerPoint PPT PresentationTRANSCRIPT
1-1
CMPE 259 Sensor Networks
Katia Obraczka
Winter 2005
Transport Protocols
1-2
Announcements
Projects posted. Some projects will be
presented/discussed at the end of class today.
Proposals due by Friday, 01.21.
1-3
1-4
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-5
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-6
Motivation ..cont’d.
In general,
Low data Rate High data Rate
Power limited Not power limited
Storage limited Not storage limited
Sink
user
1-7
SWSP
Simple Wireless Sensor Protocol. Design challenges:
Limited capabilities. Assumptions:
“Fixed network” topology. Access points as data collectors.
1-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.
1-9
SWSP overview
1-10
SWSP overview
Disconnected Connecting
Disconnecting
Ack wait
Connected
Requested
Poweroff
On
Ack received
Data request
Datasent
Leave
Leave
Ack rec’d Datasent
1-11
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-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-recv’d) – time(data-sent).
1-13
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-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.
S
1-15
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-16
ESRT problem definition
Determine reporting frequency of source nodes to achieve required reliability at sink with minimum resource consumption.
1-17
Preliminary observations:
Reliability increases as reporting frequency increases up to a certain threshold.
Why?
1-18
ESRT operation
1-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).
1-20
Components of ESRT
In sink: Normalized reliability computation. Congestion detection mechanism.
In source: Listen to sink broadcast Overhead free local congestion detection
mechanismE.g., buffer level monitoring, CN – Congestion
Notification
1-21
Performance results (based on simulations)
Starting with no congestion and low reliability:
1-22
Performance results cont’d
Starting with no congestion and high reliability:
1-23
Performance results cont’d
Starting with congestion and high reliability:
1-24
Performance results cont’d
Starting with congestion and low reliability:
1-25
Performance results cont’d
Average power consumption while starting with no congestion and high reliability:
1-26
Challenges with ESRT
Multiple concurrent events. Is there a way to slow down the nodes
causing the congestion ? Others?
1-27
PSFQ
1-28
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 re-program functionality.
1-29
Goals
Simplicity. Robustness. Scalability. Customizability.
1-30
Probability of successful delivery using end-to-end model
1
2
n-1
n
(1-p)
(1-p)n-1
(1-p)n
p is the error rate of wireless link between two hops
1-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.
1-32
Multi-hop packet forwarding
1 2 3 4
1
11
22 2
33 3
When no link Loss – multi-hop forwarding takes place
1-33
Recovering from errors
2 431
2 lost
1 1 1
33
3
Recover 2
Recover 2
Recover 2
Error recovery messages are wasted
1-34
How PSFQ recovers from errors:“store and forward”
2 31 4
2 lost
Recover 2
1
22
3
11
33 2
2
No waste of error recovery messages
1-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.
1-36
PSFQ Pump Schedule
If not duplicate and in-order and TTL not 0 then Cache and schedule for forwarding at time t (Tmin<t<Tmax)
Tmin
TmaxTmin
Tmax
21
1
1
1
t
1-37
“Fetch Quickly” Operation
21
11
2 lost2
3
Tmin
Tmax
TrRecover 2Tr 2
2
When loss detected,then fetch mode.
Loss aggregation: try to recover a windowof lost packets.
1-38
“Proactive Fetch”
Tproc
1 2
last-1
last
last
1-39
Report
Report aggregation. Carries status information: node id, seq.
#. Triggered by user.
Inject data message with “report” bit set.
1-40
Performance evaluation
Compare with SRM (Scalable Reliable Multicast)
Performance Metrics Average Delivery Ratio Average Latency Average Delivery Overhead
1-41
Experimental setup
2 Mbps CSMA/CA Channel AccessTmax = 100ms Tmin = 50ms Tr = 20ms
1-42
Error tolerance
1-43
Average latency
1-44
Overhead
1-45
Conclusion - PSFQ
Light weight and energy efficient Simple mechanism Scalable and robust Need to be tested for high bandwidth
applications Cache size limitation