Transport Layer Issues for Ad hoc WSNIdeas for Today and Tomorrow

Faisal Karim ShaikhDEEDS, TU Darmstadt, Germanyfkarim@deeds.informatik.tu-darmstadt.de

DEEDS

Vision Statement

Reliable and Robust bi-directional (sink to sensors and sensors to sink) transport protocol for Ad-hoc Wireless Sensor Networks

DEEDS

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 … Disaster Recovery Military Applications etc

DEEDS

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 Reliable Transport Flow Control Congestion Control Self Configuration Energy Awareness

DEEDS

Types of data

Single Packet Block of packets Stream of Packets

DEEDS

Today’s SituationDownstream Reliability: from Sink to Sensors

Reliability semantics are different 100% (on cost of scarce resources?)

PSFQ (Block of packets data) MOAP (Block of packets data) GARUDA (Block of packets data) (Single Packet)

DEEDS

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 recoveryGoals• 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

PSFQPUMP OPERATION

If not duplicate and in-order and TTL not 0Cache and Schedule for Forwarding at time t (Tmin< t < Tmax)

Tmin

Tmax Tmin

Tmax

1

1

1

t

1 2

DEEDS

PSFQFETCH MODE (Recovery from Errors)

2 lost

Recover 2

1

2

3

2

1 2 3 4

1

1

22

33

DEEDS

PSFQFetch Quickly

1

1

2 lost

2

3

Tmin

Tmax

Tr

Recover 2Tr

2

2

1 2

DEEDS

PFSQREPORT 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

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

DEEDS

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

Packet forwarding Out-of-sequence forwarding for better spatial reuse

Loss detection NACK to avoid ACK implosion

Loss recovery Local, designated scheme to decrease contention with

packet forwarding

GARUDA

DEEDS

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

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

DEEDS

Core Construction Distributed MDS

Two phase Loss Recovery A-map

GARUDA

DEEDS

GARUDA

GARUDA also supports other reliability semantics that might be required for sink-to-sensors communication such as

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.

DEEDS

GARUDA

DEEDS

MOAP: Overview

Code distribution mechanism specifically targeted for Mica2 motes

Full binary updates Multi-hop operation achieved through recursive

single-hop broadcasts Energy and memory efficient

DEEDS

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

MOAP

DEEDS

Reliability Mechanism Loss responsibility lies on receiver

Only one node to keep track of (sender) NACK-based

In line with IP multicast and WSN reliability schemes Local scope

No need to route NACKs Energy and complexity savings

All nodes will eventually have the same image

MOAP

DEEDS

Retransmission Policies

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

DEEDS

Segment Management

Sliding window Bitmap of up to w segments kept in RAM Starting point: last segment received in order RAM lookup Limited out-of-order tolerance!

MOAP

DEEDS

Current Mote implementation 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

DEEDS

MOAP: Conclusion

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

DEEDS

Upstream Reliability: from sensors to Sink

Today’s Situation

New notion Event to Sink

RMST (Block of packets data) CODA ESRT (Streaming data)

DEEDS

Reliable Multi-Segment Transport (RMST)

SinkSink

RMST Node

Source Node

End-to-end data-packet transfer reliability Each RMST node caches the packets When a packet is not received before the so- called WATCHDOG timer expires, a NAK is sent backward The first RMST node that has the required packet along the path retransmits the packetIn-network caching brings significant overhead in terms of power and processingRelies on Directed Diffusion Scheme

DEEDS

RMST: Overview

A transport layer protocol Uses diffusion for routing Selective NACK-based

Provides Guaranteed delivery of all fragments

In-order delivery not guaranteed Fragmentation/reassembly

DEEDS

Placement of reliability for data transport

RMST considers 3 layers MAC Transport Application

Focus is on MAC and Transport

RMST

DEEDS

MAC Layer Choices

No ARQ All transmissions are broadcast No RTS/CTS or ACK Reliability deferred to upper layers Benefits: no control overhead, no erroneous path selection

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 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

DEEDS

Transport Layer Choices

End-to-End Selective Request NACK Loss detection happens only at sinks (endpoints) Repair requests travel on reverse (multihop) path from sinks to

sources Hop-by-Hop Selective Request NACK

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

DEEDS

Application Layer Choices

End-to-End Positive ACK 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

DEEDS

RMST details Implemented as a Diffusion Filter

Takes advantage of Diffusion mechanisms for Routing Path recovery and repair

Adds Fragmentation/reassembly management Guaranteed delivery

Receivers responsible for fragment retransmission Receivers aren’t necessarily end points Caching or non-caching mode determines classification of node

DEEDS

RMST Details (cont’d)

NACKs triggered by Sequence number gaps

Watchdog timer inspects fragment map periodically for holes that have aged for too long

Transmission timeouts ‘Last fragment’ problem

NACKs propagate from sinks to sources Unicast transmission NACK is forwarded only if segment not found in local cache Back-channel required to deliver NACKs to upstream neighbors

DEEDS

RMST: Conclusion

ARQ helps with unicast control and data packets In high error-rate environments, routes cannot be established

without ARQ Route discovery packets shouldn’t use 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

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.

DEEDS

Energy efficient congestion control scheme Three mechanisms are involved

Congestion Detection Open-loop hop-by-hop backpressure Closed-loop multi-source regulation

Congestion Detection and Avoidance (CODA)

DEEDS

Congestion Detection

Accurate and efficient congestion detection is important

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

DEEDS

Open-Loop Hop-by-Hop Backpressure

CODA

Congestion detected

1 2 3

4

5

2

DEEDS

Closed Loop Multi-Source Regulation

1,2,3

ACK

4,5,6

Congestion detected

7,8

Regulate bit is set

ACK

1 2

CODA

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

CODA is a energy efficient protocol Can deal with Persistent and Transient Hotspots

DEEDS

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

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

ESRT

DEEDS

ESRTr versus f based on simulation results

n = number of source nodes

r incre

ases w

ith th

e

source

reportin

g rate f

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

(No congestion, Low reliability)

(Congestion, Low reliability)

(Congestion, High reliability)

(No congestion, High reliability)

Optimal Operating Region

DEEDS

ESRT – Frequency Update

State f update Action(NC, LR) Multiplicative increase f to achieve

required reliability as soon as possible(NC, HR) Decrease f conservatively, reduce

energy consumption and not lose reliability

(C, HR) Aggressively decrease f to relieve congestion as soon as possible

(C, LR) Exponential decrease. k is the number of successive decision intervals spent in state (C, LR)

OOR Unchanged

i

ii

ff

1

121

i

ii

ff

1

i

ii

ff

1

)(1

kiii ff

ii ff 1

DEEDS

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-to-

sensor transport

DEEDS

How Did We Get Here?Protocol Error

RecoveryReliability Direction

Congestion Ctrl

MAC/Routing Requirement

Sim OS Purpose Metrics

PSFQ h-h sink to sensors

-- Broadcast ns2 tos compare SRM

avg delivery ratio/overhead/

latency

GARUDA h-h/e-e sink to sensors

-- Broadcast ns2 -- loss recovery

Latency/energy consumption

MOAP h-h sink to sensors

-- broadcast/uni-cast

EmStar

tos Code Updates

Latency/energy consumption

RMST h-h/e-e event to sink -- DF ns2 -- evaluate tradeoffs

total bytes

ESRT -- collectiveevent 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 taxfidelity penalty

h-h = hop by hope-e = end to endDF = Directed Diffusiontos = Tiny OS

DEEDS

OVERALL VIEW

Wireless TCP variants are NOT suitable for WSN(resource constraints – power, storage, computational complexity, data rates)

Different notion of end-to-end reliability Huge buffering requirements ACKing is energy draining

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

What we looking for

DEEDS

References 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: CongestionDetection 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.