Transport Layer
1-1
Motivation
What is expected out of a transport
protocol for sensor networks ?
• Reliability,
• QoS (e.g., delay guarantees, priority delivery),
• Congestion and flow control,
• Energy efficiency,
• Fairness.
1-2
Transport-Layer Challenges in
WSNs
Variety of communication models including
many-to-one.
Wireless communications.
Energy constraints.
Data centric QoS.
Instead of source-destination specificic.
E.g., “provide to sink sufficient quality of
information about an event”.
1-3
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-4
Motivation ..cont’d.
In general,
Low data Rate High data Rate
Power limited Not power limited
Storage limited Not storage limited
user
Sink
1-5
Trend
Departure from TCP-like model.
Relies almost exclusively on end-to-end
involvement.
In general, proposed protocols engage
intermediate nodes.
Transport layer?
Cross-layer approach.
1-6
Existing Solutions
Reliable delivery.
Congestion control.
Real-time scheduling.
1-7
Reliable Delivery
1-8
PSFQ
Pump Slowly, Fetch Quickly.
Wan et al., ACM WSNA 2002.
1-9
Motivation
Most sensor network applications do not
need 100% reliability.
Sources => sink.
But applications like re-tasking of sensors
need reliable delivery.
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-10
Goals
Provide lossless delivery.
Minimize control overhead.
Provide delay guarantee for delivery to all
intended nodes.
1-11
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
1-12
between two hops
PSFQ’s Main Principle
“Slow” data propagation (pump).
Enough time for hop-by-hop error recovery
(fetch).
1-13
Multi-hop packet forwarding
1 2 3 4
1
1
1
2
2 2
3
3 3
When no link Loss – multi-hop forwarding takes place
1-14
Recovering from errors
1 2 3 4
1 1 1
2 lost
3
3
Recover 2
3
Recover 2
Recover 2
Error recovery messages are wasted
1-15
How PSFQ recovers from errors:
“store and forward”
1 2 3 4
1
1
2 2 lost
1
3
Recover 2
2
2 2
3 3
No waste of error recovery messages
1-16
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-17
PSFQ Pump Schedule
1 2
1
t
Tmin 1
Tmax
Tmin 1
Tmax
If not duplicate and in-order and TTL not 0 then
Cache and schedule for forwarding at time t (Tmin “connected” state.
Window size?
Periodic KA from sensors.
Data retransmitted after 3 retries.
ACKS piggybacked onto RR messages.
Data piggybacked onto KA messages.
1-44
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-45
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-46
Congestion Control
Limited bandwidth.
Congestion is likely, e.g., when an event is
detected.
1-47
Event-to-Sink Reliable Transport (ESRT)
for Wireless Sensor Networks
Akyildiz et al., ACM Mobihoc 2003
Event-to-sink reliability.
Self-adjusting.
S
Energy awareness [low power consumption
requirement!].
Congestion control.
Different complexity at source and sink.
1-48
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-49
ESRT problem definition
Determine reporting frequency of source nodes to
achieve required reliability at sink with minimum
resource consumption.
1-50
Preliminary observations:
Reliability increases as reporting frequency
increases up to a certain threshold.
Why?
1-51
ESRT operation
1-52
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-53
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-54
Performance results
(based on simulations)
Starting with no congestion and low
reliability:
1-55
Performance results cont’d
Starting with no congestion and high
reliability:
1-56
Performance results cont’d
Starting with congestion and high reliability:
1-57
Performance results cont’d
Starting with congestion and low reliability:
1-58
Performance results cont’d
Average power consumption while starting
with no congestion and high reliability:
1-59
Challenges with ESRT
Multiple concurrent events.
Is there a way to slow down the nodes
causing the congestion ?
Others?
1-60
CODA
1-61
COngestion Detection and
Avoidance
Importance of congestion control.
1-62
What is CODA ?
Energy efficient congestion control.
Three mechanisms are involved:
Congestion detection
Open-loop hop-by-hop backpressure.
Closed-loop multi-source regulation.
1-63
Congestion detection
Accurate and efficient congestion
detection is important
Channel loading – sample channel at appropriate
rate to detect congestion.
1-64
Open-loop h-by-h backpressure
1 2 3
4
Upstream node Congestion
decides to propagate detected
5
backpressure or not.
6
1-65
Closed loop multi-source regulation
1 2
Regulate
1,2,3
bit is set
ACK
4,5,6 Congestio
n detected
7,8
ACK
1-66
Congestion detection schemes
Buffer occupancy.
Not reliable in CSMA networks.
Channel loading.
Good for the immediate neighborhood.
Energy considerations.
Report rate.
Report rate goes down, congestion.
Detection based on report rate needs to react
on longer time scale.
1-67
CODA overview
Combination of backpressure (fast time
scale) with closed-loop congestion control.
Backpressure targets “local” congestion,
whereas closed-loop regulation targets
persistent congestion.
Backpressure is cheaper/simpler since it’s
open loop.
Congestion control requires a feedback
loop.
Uses ACK from sink to self-clock.
1-68
CODA performance metrics
Average Energy Tax =
Total packets dropped in network /
Total packets received at sink
Average Fidelity Penalty =
Difference between average number
of packets delivered at sink using CODA
and using ideal congestion scheme.
1-69
Simulation Setup
Random network topologies with network
size from 30 to 120 nodes.
2Mbps IEEE 802.11 MAC (RTS/CTS are
disabled).
Directed diffusion is used as routing core.
Fixed work load, 6 sources and 3 sinks.
Source generate data at different rates.
Event packet is 64 bytes and interest
packet is 36 bytes.
1-70
Simulation Results
(Case 1: Dense Source , High Rate)
1-71
Simulation Results
(Case 2: Sparse Sources, Low Rate)
1-72
Simulation Results
Case 2: Sparse Source, Low Rate
1-73
Simulation Results
(Case 3: Sparse Sources, High Rate)
Network Size (#no of nodes)
1-74
Conclusion
CODA’s energy efficiency.
CODA’s ability to handle persistent and
transient congestion.
1-75
Real-Time Scheduling
Some mission-critical applications may
impose strict deadline delivery.
E.g., control and actuation, emergency
response, surveillance.
Goal shifts from delivery reliability to
minimizing packet deadline miss ratio.
1-76
Velocity Monotonic Scheduling
VMS is packet scheduling mechanism that
schedules forwarding of packets based on:
Time until packet deadline expiration (t).
Physical distance (d) between current node and
destination.
Required velocity v = d/t.
Packet priority directly proportional to its
velocity.
1-77
VMS: Observations
Implementation via priority queues or
separate FIFO queues.
Drop discipline: drop packets that have
missed their deadline.
Cross-layer approach for packet
scheduling:
Control random backoff at the MAC layer.
Packets with higher priority use smaller
backoff.
1-78
Transport protocols: summary
1-79
Pump Slow Fetch Quickly PSFQ
For sink-to-
source
communication
(e.g. network
reprogramming)
Reliability via
retransmissions
Sequence-driven
loss detection
C.Y. Wan, A.T. Campbell, and L. Krishnamurthy. PSFQ: A Reliable Transport Protocol for Wireless Sensor Networks.
1-80
WSNA'02, September 28, 2002, Atlanta, Georgia, USA.
RMST
End-to-end or hop-by-hop repair (the latter is
generally better)
Suggests that repair could be done at either MAC
layer (ARQ retransmissions) or Transport Layer
(requests based on fragment numbers etc.)
Timer-driven loss detection and local data caches
Fits with the Directed Diffusion API
F. Stann and J. Heidemann. RMST: Reliable Data Transport in Sensor Networks. IEEE SNPA'03. 1-81
ESRT
Aim for overall quality of service rather than node-to-node
reliability
Sankarasubramaniam, Y., Akan, O.B., and Akyildiz, I.F., "ESRT: Event-to-Sink Reliable Transport in Wireless Sensor
1-82
Networks ", In Proc. ACM MobiHoc`03
CODA
Receiver based congestion detection
Open loop hop-by-hop backpressure
Closed-Loop multi-source regulation
Sankarasubramaniam, Y., Akan, O.B., and Akyildiz, I.F., "ESRT: Event-to-Sink Reliable Transport in Wireless Sensor
1-83
Networks ", In Proc. ACM MobiHoc`03
Summarizing Transport Issues
Because of harsh conditions and severe constraints, it
may be better to implement reliability in a hop-by-hop
rather than end-to-end manner at either the MAC or
transport layer
For energy efficiency, it is best to avoid congestion
entirely, or have packet losses occur close to the
source. Back pressure is a useful technique.
Where possible, scheduled solutions are preferable.
s
1-84
WSN Transport: Considerations
Departure from TCP-like model.
Application dictates needed functionality.
Hop-by-hop reliability.
Why have a transport layer?
Transport protocol suite or flexible
protocol which can be customized?
What kind of functionality?
for reliability, would link-layer error
E.g.,
recovery suffice?
1-85