Transport layer
This presentation is the property of its rightful owner.
Sponsored Links
1 / 85

Transport Layer PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on
  • Presentation posted in: General

Transport Layer. 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. Transport-Layer Challenges in WSNs.

Download Presentation

Transport Layer

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Transport layer

Transport Layer


Motivation

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.


Transport layer challenges in wsns

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


Motivation cont d

Motivation ..cont’d.

  • Application specific.

  • Spectra for known constraints:

Low data Rate High data Rate

Power limitedNot Power limited

Storage limitedNot Storage limited

Bursty samples Periodic samples


Motivation cont d1

Low data Rate High data Rate

Power limited Not power limited

Storage limited Not storage limited

user

Sink

Motivation ..cont’d.

In general,


Trend

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.


Existing solutions

Existing Solutions

  • Reliable delivery.

  • Congestion control.

  • Real-time scheduling.


Reliable delivery

Reliable Delivery


Transport layer

PSFQ

  • Pump Slowly, Fetch Quickly.

  • Wan et al., ACM WSNA 2002.


Motivation1

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.


Goals

Goals

  • Provide lossless delivery.

  • Minimize control overhead.

  • Provide delay guarantee for delivery to all intended nodes.


Probability of successful delivery using end to end model

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

between two hops


Psfq s main principle

PSFQ’s Main Principle

  • “Slow” data propagation (pump).

  • Enough time for hop-by-hop error recovery (fetch).


Multi hop packet forwarding

1

2

3

4

1

1

1

2

2

2

3

3

3

Multi-hop packet forwarding

When no link Loss – multi-hop forwarding takes place


Recovering from errors

1

3

4

2

1

1

1

2 lost

3

3

Recover 2

3

Recover 2

Recover 2

Recovering from errors

Error recovery messages are wasted


How psfq recovers from errors store and forward

1

3

4

2

1

1

2

2 lost

1

3

Recover 2

2

2

2

3

3

How PSFQ recovers from errors:“store and forward”

No waste of error recovery messages


Psfq operation

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.


Psfq pump schedule

1

2

1

t

Tmin

1

Tmax

Tmin

1

Tmax

PSFQ Pump Schedule

If not duplicate and in-order and TTL not 0 then

Cache and schedule for forwarding at time t (Tmin<t<Tmax)


Fetch quickly operation

1

2

1

1

2

2 lost

3

Tr

Tr

Recover 2

2

Tmin

2

Tmax

“Fetch Quickly” Operation

When loss detected,

then fetch mode.

Loss aggregation: try to recover a window

of lost packets.


Proactive fetch

1

2

last-1

last

Tproc

last

“Proactive Fetch”


Report

Report

  • Report aggregation.

  • Carries status information: node id, seq. #.

  • Triggered by user.

    • Inject data message with “report” bit set.


Performance evaluation

Performance evaluation

  • Compare with SRM (Scalable Reliable Multicast)

  • Performance Metrics

    • Average Delivery Ratio

    • Average Latency

    • Average Delivery Overhead


Experimental setup

Experimental setup

2 Mbps CSMA/CA Channel Access

Tmax = 100ms Tmin = 50ms Tr = 20ms


Error tolerance

Error tolerance


Average latency

Average latency


Overhead

Overhead


Conclusion psfq

Conclusion - PSFQ

  • Light weight and energy efficient

  • Simple mechanism

  • Scalable and robust

  • Need to be tested for high bandwidth applications

  • Cache size limitation


Transport layer

RMST


Transport layer

RMST

  • Reliable Multi-Segment Transport.

  • Where to do reliability?

    • MAC.

    • Transport.

    • Application.


Mac reliability

MAC reliability

  • 802.11.

    • RTS/CTS, Data, Ack.

    • Basic stop-and-wait ARQ.

    • No ARQ when in broadcast or multicast modes.

      • Random slot selection.

  • Options:

    • No ARQ.

    • AEQ always.

    • Selective ARQ.


Mac reliability cont d

MAC reliability (cont’d)

  • Without ARQ:

    • Use broadcast mode.

    • For unicast: address screening at routing layer.

    • +’s: no overhead.

  • With ARQ:

    • Unicast transmissions.

    • For broad- & multicast, use multiple unicast.

    • Number of retries is configurable.

  • Selective ARQ:

    • Unicast uses ARQ.

    • Broad- and multicast use no ARQ.

      • E.g., route discovery.


Transport reliability

Transport reliability

  • Strictly e2e.

    • Initiated by sink.

  • Local recovery.

    • Intermediate nodes trigger repair when loss is detected.

    • Nodes cache packets.

  • NACK-based.


Application layer reliability

Application-layer reliability

  • Directed-diffusion based.

    • Sink sends out request (“interest”).

    • When complete data received, sink removes request.


Question

Question?

  • Benefits of lower-layer reliability?

  • Additional overhead?


Rmst overview

RMST overview

  • Functions:

    • Fragmentation/reassembly.

    • Guaranteed delivery.

  • Unique identifiers:

    • “No fragments”.

    • Fragment id’s and number of fragments.

  • Loss detection and repair:

    • Sequence # holes and timers.

    • Loss detection at either sinks or intermediate nodes.

    • NACKs.


Preliminary analysis

Preliminary analysis

  • Demonstrate the benefits of hop-by-hop reliability.


Rmst evaluation

RMST evaluation

  • MAC-only reliability.

  • Local recovery.

    • With and without MAC reliability.

  • End-to-end reliability.

    • With and without MAC reliability.


Observations

Observations

  • When there is no transport reliability:

    • MAC reliability critical in lossy links.

  • Hop-by-hop transport reliability:

    • Adds little to reliable MAC.

    • But, hop-by-hop transport reliability only more efficient than adding MAC reliability.

      • MAC ARQ overhead incurred in every packet.

  • E2E transport reliability:

    • When no MAC reliability is used, simulation does not terminate: hop-by-hop recovery is critical.

    • If MAC reliability used, hop-by-hop and e2e transport reliability are equivalent.


Observations cont d

Observations (cont’d)

  • Experiments with high error rates:

    • Hop-by-hop transport reliability without MAC reliability.

    • Hop-by-hop transport reliability+Sel. ARQ.

    • E2e transport reliability+ Sel. ARQ.

  • Hbh transport reliability without ARQ breaks down at high error rates.

    • Routing has hard time establishing routes.


Transport layer

SWSP

  • Simple Wireless Sensor Protocol.

  • Design challenges:

    • Limited capabilities.

  • Assumptions:

    • “Fixed network” topology.

    • Access points as data collectors.


Why not tcp

Why not TCP?

  • Too heavy-duty.

  • Congestion control and wireless links.

    • Disable congestion control?

    • Low bandwidth.

  • Buffer size.

    • Small windows.

  • Multiple connections.

    • Single connection.


Swsp overview

SWSP overview


Swsp overview1

SWSP overview

On

Connecting

Disconnected

Power

off

Ack received

Leave

Connected

Disconnecting

Ack rec’d

Data

sent

Data request

Leave

Ack wait

Requested

Data

sent


Observations1

Observations

  • Sensor registers with an AP.

    • Listens for RR messages.

    • Sends registration.

    • Waits for ACK => “connected” state.

  • Window size?

  • Periodic KA from sensors.

  • Data retransmitted after 3 retries.

  • ACKS piggybacked onto RR messages.

  • Data piggybacked onto KA messages.


Swsp evaluation

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


Swsp evaluation cont d

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?


Congestion control

Congestion Control

  • Limited bandwidth.

  • Congestion is likely, e.g., when an event is detected.


Event to sink reliable transport esrt for wireless sensor networks

S

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

  • Akyildiz et al., ACM Mobihoc 2003

  • Event-to-sink reliability.

  • Self-adjusting.

  • Energy awareness [low power consumption requirement!].

  • Congestion control.

  • Different complexity at source and sink.


Esrt s definition of reliability

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.


Esrt problem definition

ESRT problem definition

Determine reporting frequency of source nodes to

achieve required reliability at sink with minimum

resource consumption.


Preliminary observations

Preliminary observations:

  • Reliability increases as reporting frequency increases up to a certain threshold.

  • Why?


Esrt operation

ESRT operation


Algorithm for esrt

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


Components of esrt

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


Performance results based on simulations

Performance results (based on simulations)

  • Starting with no congestion and low reliability:


Performance results cont d

Performance results cont’d

  • Starting with no congestion and high reliability:


Performance results cont d1

Performance results cont’d

  • Starting with congestion and high reliability:


Performance results cont d2

Performance results cont’d

  • Starting with congestion and low reliability:


Performance results cont d3

Performance results cont’d

  • Average power consumption while starting with no congestion and high reliability:


Challenges with esrt

Challenges with ESRT

  • Multiple concurrent events.

  • Is there a way to slow down the nodes causing the congestion ?

  • Others?


Transport layer

CODA


Congestion detection and avoidance

COngestion Detection and Avoidance

  • Importance of congestion control.


What is coda

What is CODA ?

  • Energy efficient congestion control.

  • Three mechanisms are involved:

    • Congestion detection

    • Open-loop hop-by-hop backpressure.

    • Closed-loop multi-source regulation.


Congestion detection

Congestion detection

  • Accurate and efficient congestion detection is important

    • Channel loading – sample channel at appropriate rate to detect congestion.


Open loop h by h backpressure

1

3

2

4

Congestion detected

5

6

Open-loop h-by-h backpressure

Upstream node

decides to propagate

backpressure or not.


Closed loop multi source regulation

1

2

Regulate bit is set

1,2,3

ACK

4,5,6

Congestion detected

7,8

ACK

Closed loop multi-source regulation


Congestion detection schemes

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.


Coda overview

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.


Coda performance metrics

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.


Simulation setup

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.


Simulation results case 1 dense source high rate

Simulation Results(Case 1: Dense Source , High Rate)


Simulation results case 2 sparse sources low rate

Simulation Results(Case 2: Sparse Sources, Low Rate)


Simulation results case 2 sparse source low rate

Simulation ResultsCase 2: Sparse Source, Low Rate


Simulation results case 3 sparse sources high rate

Simulation Results(Case 3: Sparse Sources, High Rate)

Network Size (#no of nodes)


Conclusion

Conclusion

  • CODA’s energy efficiency.

  • CODA’s ability to handle persistent and transient congestion.


Real time scheduling

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.


Velocity monotonic scheduling

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.


Vms observations

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.


Transport protocols summary

Transport protocols: summary


Pump slow fetch quickly psfq

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. WSNA'02, September 28, 2002, Atlanta, Georgia, USA.


Transport layer

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.


Transport layer

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 Networks ", In Proc. ACM MobiHoc`03


Transport layer

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 Networks ", In Proc. ACM MobiHoc`03


Summarizing transport issues

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


Wsn transport considerations

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?

    • E.g., for reliability, would link-layer error recovery suffice?


  • Login