Transport Protocol in Wireless Sensor Networks. Motivation What is expected out of a “transport” protocol for sensor networks ? Reliability, congestion.

Transport Protocol in Transport Protocol in Wireless Sensor Wireless Sensor

NetworksNetworks

MotivationMotivation What is expected out of a “transport” protocol for What is expected out of a “transport” protocol for

sensor networks ? sensor networks ? Reliability, congestion control, mux/demux,……Reliability, congestion control, mux/demux,……

Why can’t we use the existing protocols ?Why can’t we use the existing protocols ?Resource constraints – power, storage, computation Resource constraints – power, storage, computation

complexity, data rates, …complexity, data rates, …

Are these constraints common for all sensor Are these constraints common for all sensor networks ? networks ?

No, they are application specific.No, they are application specific.

Motivation ..contd.Motivation ..contd.

►Any application can have a Any application can have a unionunion of of the constraints that we know or yet the constraints that we know or yet to figure outto figure out

►Spectra for known constraints:Spectra for known constraints:Low data Rate High data Rate

Power limited Not Power limited

Storage limited Not Storage limited

Bursty samples Periodic samples

Motivation ..contd.Motivation ..contd.

General notion for sensor networksGeneral notion for sensor networksLow data Rate High data Rate

Power limited Not power limited

Storage limited Not storage limited

Sink

user

Motivation ..contd.Motivation ..contd.

Radar application:Radar application:

Range of Transport protocols is yet to be Range of Transport protocols is yet to be exploredexplored

ESRT, PSFQ, CODA …….……!!!!………..TRABOLESRT, PSFQ, CODA …….……!!!!………..TRABOL

Low data Rate High data Rate

Power limited Not Power limited

Storage limited Not storage limited

High data RateNot Power limited

Not Storage limited

Two Issues in TransportTwo Issues in Transport

First look at First look at resource-constrainedresource-constrained sensors sensors

►What is the proper reliability notion for What is the proper reliability notion for wireless sensor networks?wireless sensor networks? ESRT as an exampleESRT as an example

►How to achieve reliable end-to-end How to achieve reliable end-to-end delivery in a less wasteful way? delivery in a less wasteful way? PSFQ as an examplePSFQ as an example

Main Design GuidelinesMain Design Guidelines

► Application drivenApplication driven Application-oriented notions such as reliability, Application-oriented notions such as reliability,

loss recovery, delayloss recovery, delay►Filling in the “gray area”, Different from the InternetFilling in the “gray area”, Different from the Internet

Expose application semanticsExpose application semantics►E.g., the concept of “application level framing” hereE.g., the concept of “application level framing” here

► ““End to end” versus “region-based”End to end” versus “region-based” Other extreme: Hop by hop?Other extreme: Hop by hop?

References for This PPTReferences for This PPT

►ESRT: Event-to-Sink Reliable Transport ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networksin Wireless Sensor Networks

►PSFQ: A Reliable Transport Protocol for PSFQ: A Reliable Transport Protocol for Wireless Sensor NetworksWireless Sensor Networks

Event-to-Sink Reliable Transport Event-to-Sink Reliable Transport (ESRT) for Wireless Sensor (ESRT) for Wireless Sensor

NetworksNetworks

Features:Features:►Event-to-sink reliabilityEvent-to-sink reliability►Self-configurationSelf-configuration►Energy awareness [low power Energy awareness [low power

consumption requirement!]consumption requirement!]►Congestion ControlCongestion Control►Variation in complexity at source Variation in complexity at source

and sink. [computation complexity]and sink. [computation complexity]

S

ESRT: OverviewESRT: Overview

► Focus on events, not individual pieces of Focus on events, not individual pieces of datadata Reflect application/user’s viewpointReflect application/user’s viewpoint

► Application-drivenApplication-driven Application defines what its desired event Application defines what its desired event

reporting rate should bereporting rate should be► Includes a congestion-control elementIncludes a congestion-control element► Runs mainly on the sinkRuns mainly on the sink►Main goal: Adjust reporting rate of sources Main goal: Adjust reporting rate of sources

to achieve optimal reliability requirementsto achieve optimal reliability requirements

Problem DefinitionProblem Definition► Assumption:Assumption:

Detection of an event is related to the number of packets received during Detection of an event is related to the number of packets received during a specific intervala specific interval

► Reliability is measured in terms of the number of packets received. Or Reliability is measured in terms of the number of packets received. Or reporting frequency i.e., number of packets/decision interval.reporting frequency i.e., number of packets/decision interval.

► Observed event reliabilityObserved event reliability r rii:: # of packets received in decision interval I# of packets received in decision interval I

► Desired event reliabilityDesired event reliability R: R: # of packets required for reliable event detection# of packets required for reliable event detection Application-specificApplication-specific

► Normalized reliability = observed/desired.Normalized reliability = observed/desired.

► Goal: configure the reporting rate of nodesGoal: configure the reporting rate of nodes Achieve required event detectionAchieve required event detection Minimize energy consumptionMinimize energy consumption

Reliability vs Reporting Reliability vs Reporting frequencyfrequency

► Initially, reliability increases linearly with reporting frequencyInitially, reliability increases linearly with reporting frequency► There is an optimal reporting frequency (fThere is an optimal reporting frequency (fmaxmax), after which ), after which

congestion occurscongestion occurs► FFmaxmax decreases when the # of nodes increases decreases when the # of nodes increases

Characteristic RegionsCharacteristic Regions► n: normalized reliability indicatorn: normalized reliability indicator

► (NC,LR): No congestion, Low reliability(NC,LR): No congestion, Low reliability f < fmax, n < 1-ef < fmax, n < 1-e

► (NC, HR): No congestion, High reliability(NC, HR): No congestion, High reliability f <= fmax, n < 1+ef <= fmax, n < 1+e

► (C, HR): Congestion, High reliability(C, HR): Congestion, High reliability f > fmax, n > 1f > fmax, n > 1

► (C, LR): Congestion, Low reliability(C, LR): Congestion, Low reliability f < fmax, n <= 1f < fmax, n <= 1

► OOR: Optimal Operating RegionOOR: Optimal Operating Region f < fmax, 1-e <= n <= 1+ef < fmax, 1-e <= n <= 1+e

Characteristic RegionsCharacteristic Regions

ESRT RequirementsESRT Requirements

►Sink is powerful enough to reach all Sink is powerful enough to reach all source nodessource nodes

►Nodes must listen to the sink Nodes must listen to the sink broadcast at the end of each decision broadcast at the end of each decision interval and update their reporting interval and update their reporting ratesrates

►A congestion-detection mechanism is A congestion-detection mechanism is requiredrequired

Congestion Detection and Congestion Detection and Reliability LevelReliability Level

►Both done at the sinkBoth done at the sink

►Congestion:Congestion: Nodes monitor their buffer queues and Nodes monitor their buffer queues and

inform the sink if overflow occursinform the sink if overflow occurs

►Reliability LevelReliability Level Calculated by the sink at the end of each Calculated by the sink at the end of each

interval based on packets receivedinterval based on packets received

Algorithm for ESRTAlgorithm for ESRT

► If congestion and low reliability: decrease reporting If congestion and low reliability: decrease reporting frequency aggressively. (exponential decrease)frequency aggressively. (exponential decrease)

► If congestion and high reliability: decrease reporting If congestion and high reliability: decrease reporting to relieve congestion. No compromise on reliability to relieve congestion. No compromise on reliability (multiplicative decrease)(multiplicative decrease)

► If no congestion and low reliability: increase reporting If no congestion and low reliability: increase reporting frequency aggressively (multiplicative increase)frequency aggressively (multiplicative increase)

► If no congestion and high reliability: decrease If no congestion and high reliability: decrease reporting slowing (half the slope)reporting slowing (half the slope)

Components of ESRTComponents of ESRT

► In sink:In sink: Normalized reliability computationNormalized reliability computation A congestion detection mechanismA congestion detection mechanism

► In source:In source: Listen to sink broadcastListen to sink broadcast Overhead free local congestion detection Overhead free local congestion detection

mechanismmechanism

E.g., buffer level monitoring, CN – E.g., buffer level monitoring, CN – Congestion NotificationCongestion Notification

ESRT Protocol OperationESRT Protocol Operation

►(NC, LR):(NC, LR):►(NC, HR):(NC, HR):►(C, HR): (C, HR): ►(C, LR): (C, LR):

ESRT SummaryESRT Summary

►Reliability notion is application-basedReliability notion is application-based No delivery guarantees for individual No delivery guarantees for individual

packetspackets

►Reliability and congestion control Reliability and congestion control achieved by changing the reporting achieved by changing the reporting rate of nodesrate of nodes

►Pushes all complexity to the sinkPushes all complexity to the sink►Single-hop operation onlySingle-hop operation only

PSFQ: OverviewPSFQ: Overview► Key ideasKey ideas

Slow data distribution (pump slowly) Slow data distribution (pump slowly) Quick error recovery (fetch quickly)Quick error recovery (fetch quickly) NACK-basedNACK-based Data caching guarantees ordered deliveryData caching guarantees ordered delivery Assumption: no congestion, losses due only to poor link qualityAssumption: no congestion, losses due only to poor link quality

► GoalsGoals Ensure data delivery in poor link quality caseEnsure data delivery in poor link quality case Minimize signaling overhead for detection/recovery operationsMinimize signaling overhead for detection/recovery operations Provide loose delay bounds for data delivery to all intended Provide loose delay bounds for data delivery to all intended

receiversreceivers

► OperationsOperations PumpPump FetchFetch ReportReport

Probability of successful Probability of successful delivery using End to End delivery using End to End

Model 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

End-to-end considered harmful ?End-to-end considered harmful ?

► Probability of reception degrades exponentially Probability of reception degrades exponentially over multiple hopsover multiple hops Not an issue in the Internet Not an issue in the Internet Serious problem if error rates are considerableSerious problem if error rates are considerable

► ACKs/NACKs are also affectedACKs/NACKs are also affected

Proposed solution: Hop-by-Hop Proposed solution: Hop-by-Hop error recoveryerror recovery

► Intermediate nodes now responsible for Intermediate nodes now responsible for error detection and recoveryerror detection and recovery NACK-based loss detection probability is now NACK-based loss detection probability is now

constantconstant►Not affected by network size (scalability)Not affected by network size (scalability)►Exponential decrease in end-to-endExponential decrease in end-to-end

► Cost: Keeping state on each nodeCost: Keeping state on each node Potentially not as bad as it sounds!Potentially not as bad as it sounds!

►Cluster/group based communicationCluster/group based communication► Intermediates are usually receivers as wellIntermediates are usually receivers as well

Multi-Hop Packet Multi-Hop Packet Forwarding Forwarding

1 2 3 4

1

11

22 2

33 3

When No Link Loss – Multi-Hop Forwarding takes place

Issue: Recovering from Issue: Recovering from Errors Errors

2 431

2 lost

1 1 1

33

3

Recover 2

Recover 2

Recover 2

Error Recovery Control Messages are wasted

How PSFQ Recovers from How PSFQ Recovers from ErrorsErrors

“Store and Forward”“Store and Forward”2 31 4

2 lost

Recover 2

1

22

3

11

33 2

2

No wastage of the Error Recovery control messages

Pump operationPump operation

► Node broadcasts a packet to its neighbors every Node broadcasts a packet to its neighbors every TminTmin Data cache used for duplicate suppressionData cache used for duplicate suppression

► Receiver checks for gaps in sequence numbersReceiver checks for gaps in sequence numbers

► If all is fine, it decrements TTL and schedules a If all is fine, it decrements TTL and schedules a transmissiontransmission Tmin < Ttransmit < TmaxTmin < Ttransmit < Tmax By delaying transmission, quick fetch operations are By delaying transmission, quick fetch operations are

possiblepossible Reduce redundant transmissions (don’t transmit if 4 or Reduce redundant transmissions (don’t transmit if 4 or

more nodes have forwarded the packet already)more nodes have forwarded the packet already) Tmax can provide a loose delay bound for the last hopTmax can provide a loose delay bound for the last hop

► D(n)=Tmax * (# of fragments) * (# of hops) D(n)=Tmax * (# of fragments) * (# of hops)

PSFQ Pump SchedulePSFQ Pump Schedule

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

Tmin

TmaxTmin

Tmax

21

1

1

1

t

Fetch operationFetch operation

► Sequence number gap is detectedSequence number gap is detected Node will send a NACK message upstreamNode will send a NACK message upstream

► ‘‘Window’ specifies range of sequence numbers missingWindow’ specifies range of sequence numbers missing► NACK receivers will randomize their transmissions to NACK receivers will randomize their transmissions to

reduce redundancyreduce redundancy It will NOT forward any packets downstream It will NOT forward any packets downstream NACK scope is 1 hopNACK scope is 1 hop NACKs are generated every Tr if there are still gapsNACKs are generated every Tr if there are still gaps

► Tr < TminTr < Tmin This is the pump/fetch ratioThis is the pump/fetch ratio

► NACKs can be cancelled if neighbors have sent similar NACKs can be cancelled if neighbors have sent similar NACKsNACKs

““Fetch Quickly” Fetch Quickly” OperationOperation

21

11

2 lost2

3

Tmin

Tmax

TrRecover 2Tr 2

2

Proactive FetchProactive Fetch

► Last segments of a file can get lostLast segments of a file can get lost Loss detection impossible; no ‘next’ segment exists!Loss detection impossible; no ‘next’ segment exists!

► Solution: timeouts Solution: timeouts Node enters ‘proactive fetch’ mode if last segment Node enters ‘proactive fetch’ mode if last segment

hasn’t been received and no packet has been delivered hasn’t been received and no packet has been delivered after Tproafter Tpro

Timing must be rightTiming must be right► Too early: wasted control messagesToo early: wasted control messages► Too late: increased delivery latency for the entire fileToo late: increased delivery latency for the entire file

Tpro = a * (Smax - Smin) * TmaxTpro = a * (Smax - Smin) * Tmax► A node will wait long enough until all upstream nodes have A node will wait long enough until all upstream nodes have

received all segmentsreceived all segments If data cache isn’t infiniteIf data cache isn’t infinite

► Tpro = a * k * TmaxTpro = a * k * Tmax (Tpro is proportional to cache size)(Tpro is proportional to cache size)

““Proactive Fetch”Proactive Fetch”

Tproc

1 2

last-1

last

last

Report OperationReport Operation

► Used as a feedback/monitoring mechanismUsed as a feedback/monitoring mechanism► Only the last hop will respond immediately Only the last hop will respond immediately

(create a new packet)(create a new packet) Other nodes will piggyback their state info when they Other nodes will piggyback their state info when they

receive the report replyreceive the report reply If there is no space left in the message, a new one If there is no space left in the message, a new one

will be createdwill be created

Experimental resultsExperimental results

► TmaxTmax = 0.3s, Tr = 0.1s= 0.3s, Tr = 0.1s

► 100 30-byte packets sent100 30-byte packets sent► Exponential increase in delay happens at 11% loss rate or higherExponential increase in delay happens at 11% loss rate or higher

PSFQ SummaryPSFQ Summary►Slow data dissemination, fast data recoverySlow data dissemination, fast data recovery

All transmissions are broadcastAll transmissions are broadcast►NACK-based, hop-by-hop recoveryNACK-based, hop-by-hop recovery

End-to-end behaves poorly in lossy environmentsEnd-to-end behaves poorly in lossy environments NACKs are superior to ACKs in terms of energy NACKs are superior to ACKs in terms of energy

savingssavings►No out-of-order delivery allowedNo out-of-order delivery allowed

Uses data caching extensivelyUses data caching extensively►Several timers and duplicate suppression Several timers and duplicate suppression

mechanismsmechanisms Implementing any of those on motes is Implementing any of those on motes is

challenging (non-preemptive FIFO scheduler)challenging (non-preemptive FIFO scheduler)

What more can be done at What more can be done at “transport”“transport”

► Robust “transport”Robust “transport” Now rely on end to end based approach: slowNow rely on end to end based approach: slow Possible new way: Location-based, rather than Possible new way: Location-based, rather than

node-based designnode-based design

► Application perspectiveApplication perspective Support aggregationSupport aggregation

► reliability & rate control & semantic aggregationreliability & rate control & semantic aggregation

Look at what application you haveLook at what application you have►Tradeoff of different metrics & requirementsTradeoff of different metrics & requirements