1-1

CMPE 259 Sensor Networks

Katia Obraczka

Winter 2005

Transport Protocols

1-2

Announcements

Projects posted. Some projects will be

presented/discussed at the end of class today.

Proposals due by Friday, 01.21.

1-3

1-4

Motivation

What is expected out of a transport protocol for sensor networks ?

Reliability, congestion control. Why can’t we use the existing

protocols ?Resource constraints – power, storage, computation complexity, data rates, …

1-5

Motivation ..cont’d.

Application specific. Spectra for known constraints:

Low data Rate High data Rate

Power limited Not Power limited

Storage limited Not Storage limited

Bursty samples Periodic samples

1-6

Motivation ..cont’d.

In general,

Low data Rate High data Rate

Power limited Not power limited

Storage limited Not storage limited

Sink

user

1-7

SWSP

Simple Wireless Sensor Protocol. Design challenges:

Limited capabilities. Assumptions:

“Fixed network” topology. Access points as data collectors.

1-8

Why not TCP?

Too heavy-duty. Congestion control and wireless links.

Disable congestion control? Low bandwidth.

Buffer size. Small windows.

Multiple connections. Single connection.

1-9

SWSP overview

1-10

SWSP overview

Disconnected Connecting

Disconnecting

Ack wait

Connected

Requested

Poweroff

On

Ack received

Data request

Datasent

Leave

Leave

Ack rec’d Datasent

1-11

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.

1-12

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

1-13

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?

1-14

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

Salient Features: Event-to-sink reliability. Self-adjusting. Energy awareness [low power

consumption requirement!]. Congestion control. Different complexity at source and

sink.

S

1-15

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.

1-16

ESRT problem definition

Determine reporting frequency of source nodes to achieve required reliability at sink with minimum resource consumption.

1-17

Preliminary observations:

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

Why?

1-18

ESRT operation

1-19

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

1-20

Components of ESRT

In sink: Normalized reliability computation. Congestion detection mechanism.

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

mechanismE.g., buffer level monitoring, CN – Congestion

Notification

1-21

Performance results (based on simulations)

Starting with no congestion and low reliability:

1-22

Performance results cont’d

Starting with no congestion and high reliability:

1-23

Performance results cont’d

Starting with congestion and high reliability:

1-24

Performance results cont’d

Starting with congestion and low reliability:

1-25

Performance results cont’d

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

1-26

Challenges with ESRT

Multiple concurrent events. Is there a way to slow down the nodes

causing the congestion ? Others?

1-27

PSFQ

1-28

Motivation

Most sensor network applications do not need reliability? Sources => sink.

New applications like re-tasking of sensors need reliable transport. 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.

1-29

Goals

Simplicity. Robustness. Scalability. Customizability.

1-30

Probability of successful delivery using end-to-end 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

1-31

Goals of PSFQ: Pump Slowly and Fetch Quickly

Recover from losses locally. Minimum signaling. Operate correctly in lossy environments. Independent of underlying routing infrastructure.

1-32

Multi-hop packet forwarding

1 2 3 4

1

11

22 2

33 3

When no link Loss – multi-hop forwarding takes place

1-33

Recovering from errors

2 431

2 lost

1 1 1

33

3

Recover 2

Recover 2

Recover 2

Error recovery messages are wasted

1-34

How PSFQ recovers from errors:“store and forward”

2 31 4

2 lost

Recover 2

1

22

3

11

33 2

2

No waste of error recovery messages

1-35

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.

1-36

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)

Tmin

TmaxTmin

Tmax

21

1

1

1

t

1-37

“Fetch Quickly” Operation

21

11

2 lost2

3

Tmin

Tmax

TrRecover 2Tr 2

2

When loss detected,then fetch mode.

Loss aggregation: try to recover a windowof lost packets.

1-38

“Proactive Fetch”

Tproc

1 2

last-1

last

last

1-39

Report

Report aggregation. Carries status information: node id, seq.

#. Triggered by user.

Inject data message with “report” bit set.

1-40

Performance evaluation

Compare with SRM (Scalable Reliable Multicast)

Performance Metrics Average Delivery Ratio Average Latency Average Delivery Overhead

1-41

Experimental setup

2 Mbps CSMA/CA Channel AccessTmax = 100ms Tmin = 50ms Tr = 20ms

1-42

Error tolerance

1-43

Average latency

1-44

Overhead

1-45

Conclusion - PSFQ

Light weight and energy efficient Simple mechanism Scalable and robust Need to be tested for high bandwidth

applications Cache size limitation