Transcript Transport Layer Issues for Ad hoc WSN

Transport Layer Issues for
Ad hoc WSN
Ideas for Today and Tomorrow
Faisal Karim Shaikh
DEEDS, TU Darmstadt, Germany
[email protected]
Vision Statement

DEEDS
Reliable and Robust bi-directional (sink to sensors
and sensors to sink) transport protocol for Ad-hoc
Wireless Sensor Networks
To the knowledge …



Up to this point Reliability and Robustness has
been ignored;
Possible reason:
-- WSN is low-cost;
-- Not necessary (due to redundant data)
-- and also difficult.
But …

We require reliability …


DEEDS
Disaster Recovery
Military Applications etc
Focus

To achieve reliability



Reliable Transport Layer
No packet loss
Bi-directional Reliability
Figure from Akyildiz et al, “Wireless Sensor Networks: A Survey”, Computer Networks, 38(4):393-422, 2002.
DEEDS
Is it challenging ?


Limitations of sensor nodes
Application specific requirements
Objectives





DEEDS
Reliable Transport
Flow Control
Congestion Control
Self Configuration
Energy Awareness
Types of data



DEEDS
Single Packet
Block of packets
Stream of Packets
Today’s Situation
Downstream Reliability: from Sink to Sensors

Reliability semantics are different




DEEDS
100% (on cost of scarce resources?)
PSFQ (Block of packets data)
MOAP (Block of packets data)
GARUDA (Block of packets data) (Single Packet)
Pump Slowly, Fetch Quickly (PSFQ)
 pace the data from a source node at a relatively low speed
 to allow intermediate nodes to fetch missing data segments from their
neighbors,
Assumption: no congestion, losses due only to poor link quality
 hop-by-hop recovery
Goals
•
•
•
•
•
Recover from losses locally.
Ensure data delivery with minimum support from transport infrastructure
Minimize signaling overhead for detection/recovery operations
Operate correctly in poor link quality environments
Provide loose delay bounds for data delivery to all intended receivers
Three basic operations: pump, fetch, and report
Alternate between multi-hop forwarding when low error rates and store-and-forward when error rates are higher.
DEEDS
PSFQ
PUMP OPERATION
If not duplicate and in-order and TTL not 0
Cache and Schedule for Forwarding at time t (Tmin< t < Tmax)
1
2
1
t
Tmin
Tmax
1
Tmin
Tmax
DEEDS
1
PSFQ
FETCH MODE (Recovery from Errors)
1
3
2
4
1
1
2
1
2 lost
3
Recover 2
2
2
2
3
3
DEEDS
PSFQ
Fetch Quickly
1
2
1
1
2
2 lost
3
Recover 2
Tr
Tr
2
Tmin
Tmax
DEEDS
2
PFSQ
REPORT
 Used to provide feedback data of delivery status to source nodes
 To minimize the number of messages, the protocol is designed so that a report
message travels back from a target node to the source nodes intermediate nodes
can also piggyback their report messages in an aggregated manner
Simulation and experimental evaluation
 When compared to a previously proposed similar protocol (Scalable Reliable
Multicast) the simulation results show that the PFSQ protocol has a better
performance in terms of error tolerance, communications overhead, and
delivery latency
 The experimental results were obtained by using the TinyOS platform on
RENE motes. The performance results were much poorer than the simulation
results. The discrepancy is attributed to the simulation experiment being
unable to accurately model the wireless channel and the computational
demands on the sensor node processor
DEEDS
PSFQ - Conclusions






DEEDS
Light weight and energy efficient
Simple mechanism
Scalable and robust
Need to be tested for high bandwidth applications
Cache size limitation
Does not address congestion control
GARUDA



It incorporates an efficient pulsing based solution, which informs the
sensor nodes about an impending reliable short-message delivery by
transmitting a specific series of pulses at a certain amplitude and
period.
A virtual infrastructure called the core that approximates a near optimal
assignment of local designated servers is instantaneously constructed
during the course of a single packet flood.
In case of a packet loss detected by a core node via an out-of-sequence
packet reception, a core node initiates a two-stage NAK based packet
recovery process that performs out-of-sequence forwarding to assure
the reliable delivery of the original message.
DEEDS
GARUDA

Packet forwarding


Loss detection


NACK to avoid ACK implosion
Loss recovery

DEEDS
Out-of-sequence forwarding for better spatial reuse
Local, designated scheme to decrease contention with
packet forwarding
GARUDA
WFP (Wait-for-First-Packet) pulses






Used only for first packet reliability
Short duration pulses
Single radio
Advertisement of incoming packet
Negative ACK
Simple energy detection
Different types of WFP

Forced pulses

Carrier sensing pulses

Piggybacked pulses
DEEDS
GARUDA



DEEDS
A sink sends WFP pulses periodically
Before it sends the first packet
For a deterministic period
A sensor sends WFP pulses periodically
After it receives WFP pulses
Until it receives the first packet
WFP merits
Prevents ACK implosion with small overhead
Addresses the single or all packet lost problem
Less energy consumption
Robust to wireless errors or contentions
GARUDA

Core Construction


Two phase Loss Recovery

DEEDS
Distributed MDS
A-map
GARUDA
GARUDA also supports other reliability
semantics that might be required for
sink-to-sensors communication such as



DEEDS
reliable delivery to all nodes within a
sub-region of the sensor network;
reliable delivery to minimal number of
sensors required to cover entire
sensing area; and
reliable delivery to a probabilistic subset
of the sensor nodes in the network.
GARUDA
DEEDS
MOAP: Overview




DEEDS
Code distribution mechanism specifically targeted
for Mica2 motes
Full binary updates
Multi-hop operation achieved through recursive
single-hop broadcasts
Energy and memory efficient
MOAP
Ripple Dissemination






Transfer data neighborhood-by-neighborhood (Ripple)
Single-hop

Recursively extended to multi-hop
Very few sources at each neighborhood

Preferably, only one
Receivers attempt to become sources when they have the entire image

Publish-subscribe interface prevents nodes from becoming sources if another
source is present

Leverage the broadcast medium
If data transmission is in progress, a source will always be one hop away!

Allows local repairs
Increased latency
DEEDS
MOAP
Reliability Mechanism

Loss responsibility lies on receiver


NACK-based


Only one node to keep track of (sender)
In line with IP multicast and WSN reliability schemes
Local scope

No need to route NACKs


DEEDS
Energy and complexity savings
All nodes will eventually have the same image
MOAP
Retransmission Policies

DEEDS
Unicast RREQ, single reply
 Smallest probability of successful reception
 Highest efficiency
 Simple
 Complexity increases if source fails
 Zero latency
 High latency if source fails
MOAP
Segment Management

Sliding window




DEEDS
Bitmap of up to w segments kept in RAM
Starting point: last segment received in order
RAM lookup
Limited out-of-order tolerance!
MOAP
Current Mote implementation









DEEDS
Using Ripple-sliding window with unicast retransmission policy
User builds code on the PC

Packetizer creates segments out of binary
Mote attached to PC becomes original source and sends PUBLISH message

Receivers 1 hop away will subscribe, if version number is greater than their own
When a receiver gets the full image, it will send a PUBLISH message

If it doesn’t receive any subscriptions for some time, it will COMMIT the new code
and invoke the bootloader

If a subscription is received, node becomes a source
Eventually, sources will also commit
Retransmissions have higher priority than data packets

Duplicate requests are suppressed
Nodes keep track of their sources’ activity with a keepalive timer

Solves NACK ‘last packet’ problem

If the source dies, the keepalive expiration will trigger a broadcast repair request
Late joiner mechanism allows motes that have just recovered from failure to participate in
code transfer

Requires all nodes to periodically advertise their version
Footprint

700 bytes RAM

4.5K bytes ROM
MOAP: Conclusion




DEEDS
Full binary updates over multiple hops
Ripple dissemination reduces energy consumption
significantly
Sliding window method and unicast retransmission
policy also reduce energy consumption and
complexity
Successful updates of images up to 30K in size
Today’s Situation
Upstream Reliability: from sensors to Sink

New notion




DEEDS
Event to Sink
RMST (Block of packets data)
CODA
ESRT (Streaming data)
Reliable Multi-Segment Transport (RMST)
End-to-end data-packet transfer reliability
 Each RMST node caches the packets
 When a packet is not received before the socalled WATCHDOG timer expires, a NAK is sent
backward
 The first RMST node that has the required packet
along the path retransmits the packet
In-network caching brings significant overhead in
terms of power and processing
Relies on Directed Diffusion Scheme

Sink
RMST Node
Source Node
DEEDS
RMST: Overview

A transport layer protocol



Uses diffusion for routing
Selective NACK-based
Provides

Guaranteed delivery of all fragments


DEEDS
In-order delivery not guaranteed
Fragmentation/reassembly
RMST
Placement of reliability for data transport

RMST considers 3 layers




DEEDS
MAC
Transport
Application
Focus is on MAC and Transport
RMST
MAC Layer Choices

No ARQ





ARQ always





All transmissions are unicast
RTS/CTS and ACKs used
One-to-many communication done via multiple unicasts
Benefits: packets traveling on established paths have high probability of delivery
Selective ARQ



DEEDS
All transmissions are broadcast
No RTS/CTS or ACK
Reliability deferred to upper layers
Benefits: no control overhead, no erroneous path selection
Use broadcast for one-to-many and unicast for one-to-one
Data and control packets traveling on established paths are unicast
Route discovery uses broadcast
RMST
Transport Layer Choices

End-to-End Selective Request NACK



Hop-by-Hop Selective Request NACK




DEEDS
Loss detection happens only at sinks (endpoints)
Repair requests travel on reverse (multihop) path from sinks to
sources
Each node along the path caches data
Loss detection happens at each node along the path
Repair requests sent to immediate neighbors
If data isn’t found in the caches, NACKs are forwarded to next hop
towards source
RMST
Application Layer Choices

End-to-End Positive ACK




DEEDS
Sink requests a large data entity
Source fragments data
Sink keeps sending interests until all fragments have
been received
Used only as a baseline
RMST details

Implemented as a Diffusion Filter

Takes advantage of Diffusion mechanisms for



Adds



Fragmentation/reassembly management
Guaranteed delivery
Receivers responsible for fragment retransmission


DEEDS
Routing
Path recovery and repair
Receivers aren’t necessarily end points
Caching or non-caching mode determines classification of node
RMST Details (cont’d)

NACKs triggered by

Sequence number gaps


Transmission timeouts


‘Last fragment’ problem
NACKs propagate from sinks to sources



DEEDS
Watchdog timer inspects fragment map periodically for holes that
have aged for too long
Unicast transmission
NACK is forwarded only if segment not found in local cache
Back-channel required to deliver NACKs to upstream neighbors
RMST: Conclusion

ARQ helps with unicast control and data packets


Route discovery packets shouldn’t use ARQ


In high error-rate environments, routes cannot be established
without ARQ
Erroneous path selection can occur
RMST combines a NACK-based transport layer protocol
with S-ARQ to achieve the best results
DEEDS
Congestion Detection and Avoidance (CODA)
CODA mainly aims to detect and avoids CONGESTION on the forward path via







DEEDS
receiver-based congestion detection,
open-loop hop-by-hop backpressure
signaling to inform the source about the congestion,
closed-loop multi-source regulation for persistent and larger-scale congestion
conditions.
Simulation results show that CODA can increase the network performance
by congestion avoidance.
However, the CODA protocol does not address the reliable event transport in
the sensor networks.
On the contrary, it has been observed in the experiments that the congestion
control performed at the sensor nodes without considering the reliability
impairs the end-to-end reliability.
Congestion Detection and Avoidance (CODA)


Energy efficient congestion control scheme
Three mechanisms are involved



DEEDS
Congestion Detection
Open-loop hop-by-hop backpressure
Closed-loop multi-source regulation
CODA
Congestion Detection

Accurate and efficient congestion detection is
important



DEEDS
Buffer queue length or Buffer occupancy – not a good
measure of the congestion.
Channel loading – sample channel at appropriate time
to detect congestion.
Report rate/Fidelity measurement – slow, observed
over a longer period
CODA
Open-Loop Hop-by-Hop Backpressure
1
2
3
4
Congestion detected
5
2
DEEDS
CODA
Closed Loop Multi-Source Regulation
1
2
1,2,3
Regulate
bit is set
ACK
4,5,6
Congestion
detected
7,8
ACK
DEEDS
CODA Performance – Cost Metrics


Average Energy Tax =
Total Packets dropped in sensor NW /
Total Packets received at Sink
Average Fidelity Penalty =
Measures difference between average number of packets delivered
at a sink using CODA and using ideal congestion scheme
Conclusion


DEEDS
CODA is a energy efficient protocol
Can deal with Persistent and Transient Hotspots
Event-to-Sink Reliable Transport (ESRT)
 In a typical sensor network application the sink node is only interested in the
collective information of the sensor nodes within the region of an event and not in
any individual sensor data
 What is needed is a measure of the accuracy of the information received at the
sink, i.e. and event-to-sink reliability
DEEDS
ESRT
 The basic assumption is that the sink does all the reliability evaluation using
parameters that are application dependent
 One such parameter is the decision time interval τ
 At the end of the decision interval the sink derives a reliability indicator ri based on
the reports received from the sensor nodes
 ri is the number of packets received in the decision interval
 If R is the number of packets required for reliable event detection then
ri > R is needed for reliable event detection
 There is no need to identify individual sensor nodes but instead there is the need to
have an event ID
 The reporting rate, f, of a sensor node is the number of packets sent out per unit
time by that node
 The ESRT protocol aims to dynamically adjust the reporting rate to achieve the
required detection reliability R at the sink
DEEDS
ESRT
r versus f based on simulation results
n = number of source nodes
for f > fmax the reliability
drops because of network
congestion
DEEDS
ESRT – Protocol Overview
 The algorithms mainly run on the sink
 Sensor nodes:
 Listen to sink broadcasts and update their reporting rates accordingly
 Have a simple congestion detection mechanism and report to the sink
 The sink:
 Computes a normalized reliability measure ηi = ri /R
 Updates f based on ηi and if f > fmax or < fmax in order to achieve the
desired reliability
 Performs congestion decisions based on feedback reports from the source
nodes
 Congestion detection:
 Uses local buffer level monitoring in sensor nodes
 When a routing buffer overflows the node informs the sink by setting the
congestion notification bit in the header packets traveling downstream
DEEDS
ESRT – Network States
Optimal Operating Region
(Congestion, High reliability)
(No congestion, High reliability)
(Congestion, Low reliability)
(No congestion, Low reliability)
DEEDS
ESRT – Frequency Update
State
(NC, LR)
f update
f i 1 
(NC, HR)
f i 1 
(C, HR)
(C, LR)
OOR
DEEDS
fi
2
Action
Multiplicative increase f to achieve
required reliability as soon as possible
fi
i

1
1  
 i 
f i 1 
fi
i
fi 1  fi(i
fi 1  fi
k)
Decrease f conservatively, reduce
energy consumption and not lose
reliability
Aggressively decrease f to relieve
congestion as soon as possible
Exponential decrease. k is the number
of successive decision intervals spent in
state (C, LR)
Unchanged
ESRT – Summary and Conclusions
 Sensor networks are more interested in event to sink reliability than on
individual end-to-end reliability
 The congestion control mechanism results in energy savings
 Analytical performance evaluation and simulation results show that the system
converges to the state OOR regardless of the initial state
 This self configuration property of the protocol is very valuable for random and
dynamic topologies
 Issues still to be addressed are:
 Extension to handle concurrent multiple events
 Development of a bi-directional reliable protocol that includes the sink-tosensor transport
DEEDS
How Did We Get Here?
Protocol
Error
Recovery
Reliability
Direction
Congestion
Ctrl
MAC/Routing
Requirement
Sim
OS
Purpose
Metrics
PSFQ
h-h
sink to
sensors
--
Broadcast
ns2
tos
compare
SRM
ratio/overhead/
latency
avg delivery
GARUDA
h-h/e-e
sink to
sensors
--
Broadcast
ns2
--
loss
recovery
Latency/energy
consumption
MOAP
h-h
sink to
sensors
--
broadcast/
uni-cast
Em
Star
tos
Code
Updates
Latency/energy
consumption
RMST
h-h/e-e
event to sink
--
DF
ns2
--
evaluate
tradeoffs
total bytes
ESRT
--
collective
event to sink
event report
frequency
CSMA/CA
ns2
--
parameter
tuning
convergence to
OOR
CODA
--
collective
event to sink
event report
frequency
CSMA
ns2
tos
parameter
tuning
energy tax
fidelity penalty
h-h = hop by hop
e-e = end to end
DF = Directed Diffusion
tos = Tiny OS
DEEDS
OVERALL VIEW

Wireless TCP variants are NOT suitable for WSN
(resource constraints – power, storage, computational complexity, data rates)



DEEDS
Different notion of end-to-end reliability
Huge buffering requirements
ACKing is energy draining
What we looking for





DEEDS
Clusters ?
Address reliable transport of concurrent multiple events in the sensor field
Explore possible reliability metrics
Develop unified transport layer protocols for bi-directional reliable transport in
WSN
Integration of WSN domain into Internet

Adaptive Transport Protocols for WSN-Ad Hoc environments
References






DEEDS
C.-Y. Wan, A. T. Campbell, “PSFQ: A reliable transport protocol for wireless sensor
networks,” In Proceedings of ACM WSNA’ 02, Sep. 28, 2002, Atlanta, USA.
F. Stann and J. Heidemann, “RMST: Reliable Data Transport in Sensor Networks,” In
Proc. IEEE SNPA’03, May 2003, Anchorage, Alaska, USA
Y. Sankarasubramaniam, O. B. Akan, and I. F. Akyidiz, “ESRT: Event-to-sink reliable
transport in wireless sensor networks,” In Proceedings of ACM Mobihoc’ 03, June 1-3,
2003, Annapolis, USA.
Thanos Stathopoulos et al, "A Remote Code Update Mechanism for Wireless Sensor
Networks". Technical Report CENS-TR-30, University of California, Los Angeles, Center
for Embedded Networked Computing, November 2003.
C.-Y. Wan, S. B. Eisenman, and A. T. Campbell, “CODA: Congestion
Detection and Avoidance in Sensor Networks,” in Proc. ACM SENSYS 2003, November
2003.
S. J. Park, R.Vedantham, R. Sivakumar and I. F. Akyildiz, A Scalable “Approach for
Reliable Downstream Data Delivery (GARUDA),” ACM MobiHoc’04 Conference, Japan,
June 2004.