garuda: achieving effective reliability for downstream communication in wireless sensor networks...

GARUDA: Achieving Effective Reliability forDownstream Communication in Wireless Sensor Networks

Seung-Jong Park et al

IEEE Transactions on mobile computingFeb, 2008

presented by jae-hong Kim

2 / 31

Contents

Transport Layer Issues for ad hoc WSN Reliable bi-directional transport protocol

Characteristics of GARUDA Pulsing based solution Virtual infrastructure called core Two-Phase Loss Recovery Multiple Reliability Semantics

Evaluation Discussion

3 / 31

Transport Layer Issues for ad hoc WSN

Vision Statement Reliable and Robust bi-directional (sink to

sensors and sensors to sink) transport pro-tocol for Ad-hoc Wireless Sensor Networks

4 / 31

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

5 / 31

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.

6 / 31

Is it challenging?

Limitations of sensor nodes Application specific requirements

Objectives Reliable Transport Flow Control Congestion Control Self Configuration Energy Awareness

7 / 31

Types of Data

Single Packet Block of packets Stream of Packets

8 / 31

Today’s Situation

Downstream Reliability: from sink to Sensors

Reliability semantics are different PSFQ (Block of packets data) MOAP (block of packets data) GARUDA (Block of packets data) (Single Packet)

9 / 31

Introduction

Reliable downstream point-to-multipoint data deliv-ery The need for the reliability is dependent on the type of

applications. Ex) security application

Reliability in multihop wireless networks vs Reliabil-ity in wireless sensor networks Environment considerations

Limited life time, bandwidth, energy, size of the network Message considerations

In a sensor networks, small-sized queries Reliability considerations

Dependent on reliability semantics

10 / 31

GARUDA

GARUDA is a large mythical bird or bird-like creature that ap-pears in both Hindu and Buddhist mythology

Transport reliably

11 / 31

Characteristics of GARUDA

1. An efficient pulsing-based solution for reli-able short message delivery

2. A virtual infrastructure called the core, which approximates an optimal assign-ment of local designated servers

3. A two-stage negative acknowledgment (NACK) based recovery process and out-of-sequence forwarding

4. A simple candidacy based solution to sup-port the different notions of reliability

12 / 31

ACK / NACK Paradox (1)

NACKs Well established as an effective loss adver-

tisement in multi-hop wireless networks In case loss probabilities are not inordinately

high Not for single-packet delivery or all packets

are lost It cannot possibly advertise a NACK to request

retransmissions

13 / 31

ACK / NACK Paradox (2)

ACK implosion

14 / 31

Pulsing based solution (1)

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 Amplitude : at least 3dB larger

Much larger than that of a regular data transmis-sion

Reliability of pulsing mechanism? Proved by “A Power Control MAC Protocol for

Ad Hoc Networks”.

15 / 31

Pulsing based solution (2)

WFP (Wait-for-First-Packet) pulses Used only for first packet reliability Short duration pulses Single radio Advertisement of incoming packets Negative ACK Simple energy detection

Different types of WFP Forced pulses Carrier sensing pulses Piggybacked pulses

16 / 31

Pulsing based solution (3)

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

17 / 31

Pulsing based solution (4)

18 / 31

Pulsing based solution (5)

Implicit NACK

19 / 31

Pulsing based solution (6)

3 modes in delivery procedure for single/first packet 1. the advertisement that notifies the en-

suring single/first packet to all nodes with the forced WFP pulses

2. the delivery that sends the single/first packet through simple forwarding (for (ex)CSMA)

3. the recovery that sends NACKs using WFP pulses to request for the retransmis-sion of the single/first packet

20 / 31

Virtual infrastructure called core (1)

The Core An approximation of the minimum dominat-

ing set (MDS) of the network sub graph to which the reliable message delivery is de-sired. the set of local designated loss recovery

servers that help in the loss recovery process. Constructing the core during the course of

a single packet flood.

21 / 31

Virtual infrastructure called core (2)

Principle The retransmission

by neighbor is suf-ficient to recover the loss of the same packet of all neighbors around it

22 / 31

Virtual infrastructure called core (3)

Instantaneous Core Construction To approximate the MDS problem, we select a node at 3i

hop distance as a core node

Approximate number of hops from the sink to the sensor

23 / 31

Two-Phase Loss Recovery (1) Core recovery – first phase recovery

Out-of-sequence Packet Forwarding with A-map Propagation

Out-of-sequence : NACK implosion

Solve the above prob-lem : uses a scalable A-map (Available Map)

Overhead? The ratio of the

number of core nodes (10 – 30%)

A map request ra-tio (less than 1 %)

24 / 31

Two-Phase Loss Recovery (2) Non-core recovery – second phase re-

covery Starts only when a noncore node overhears an A-map from the core node indicat-ing that it has received all the packets in a message

25 / 31

Multiple Reliability Seman-tics (1)

26 / 31

Multiple Reliability Seman-tics (2)

Involving nodes employing a candidacy check before participating in the core construction algorithm

The candidacy check is where nodes, upon receiv-ing the first packet, deter-mine whether or not they belong in the subset G(s)

27 / 31

Evaluation (1)

For n2-based experiments 100 nodes in 650 m * 650 m square area Randomly deployed within that area Sink is located in center Transmission range of each node is 67 m Channel capacity is 1Mbps Each message : 100 packets (25 pkts/ sec) Size of packet : 1Kbyte

28 / 31

Evaluation (2)

Evaluation of single-packet delivery

29 / 31

Evaluation (3)

Evaluation of multiple-packet delivery

30 / 31

Discussion

Considerations for upstream? Network model

Sink and sensors static? There is exactly one sink coordinating the

sensors? Congestion control?

If congestions are appeared, how can GARUDA control them?

Loss recovery for noncore nodes How can we reduce snooping overheads?

31 / 31

Q & A