PIP: A Connection-Oriented, Multi-Hop, Multi-Channel …vijaygabale/pip/pip-docs/pip-pres-4.pdfWiFi...

PIP: A Connection-Oriented, Multi-Hop, Multi-Channel TDMA-based MAC for

High Throughput Bulk Transfer

Bhaskaran Ramanbr@cse.iitb.ac.in

Kameswari Chebroluchebrolu@cse.iitb.ac.in

Sagar Bijwesag.bijwe@gmail.com

Vijay Gabalevijaygabale@cse.iitb.ac.in

SyNerG: Systems and Networks GroupDepartment of CSE, IIT Bombay, India

SenSys 2010

Other applications: Volcanic activity monitoring (50KB/sensor), bulk data collection in sensor network

Motivating Example

Sink

Source (sensing nodes,

bulk data)

Structural health monitoring

Goal: Effective and efficient delivery of sensed data over a multi-hop wireless sensor network.

Requirements and Challenges

Quick data transfer/High Throughput Event detection ability is minimally affected. Energy savings after data collection.

Reliability Delivers important fragments of data.

Mitigating inter­path, intra­path interference?

Goal: Effective and efficient delivery of sensed data over a multi-hop wireless sensor network.

Using multiple channels for spatial efficiency?

Handling wireless packet errors?

Focus of This Work

What is the efficacy of a time synchronization

mechanism for a multi-hop wireless

network?

A TDMA-based MAC for multi-hop bulk data transfer

PIP: A TDMA-based MAC for high throughput bulk transfer

What is the capacity upper bound for bulk

transfer on an 802.15.4-based multi-hop wireless network?

Outline of Talk

PIP Design Choices

A Transport Protocol using PIP MAC

PIP Implementation

PIP Evaluation

Related Work

Conclusion

PIP MAC: Design Choices

PIP: Design Choices

Connection-oriented MAC

Channel Access: TDMA

Access Control: Centralized

Multi-Channel Operation

Goal: Effective and efficient delivery of sensed data over a multi-hop wireless sensor network.

Mitigating inter­path*, intra­path interference

Using multiple channels for spatial efficiency

Handling wireless packet errors

*We assume one flow at a time, and thus do not consider inter-path interference much like in Flush, Fetch.

1.

2.

3.

4.

Channel Access: TDMA

Goal: Effective and efficient delivery of sensed data over a multi-hop wireless sensor network.

Mitigating intra­path interference

Using multiple channels for spatial efficiency

Handling wireless packet errors

1.

Time divided into a frame. A frame divided into slots. Interfering links on different slots.

L1 L2 L3 L4

L1 & L4

Slots 1 2 3

Frame 1

L2 L3 L1 & L4

What is the efficacy of time sync in practice? Later in Evaluation.

PIP: Design Choices

Channel Access: TDMA

Access Control: Centralized

Multi-Channel Operation

Goal: Effective and efficient delivery of sensed data over a multi-hop wireless sensor network.

1.

2.

3.

L1 L2 L3 L4

L1

1 2 1 2

L3

1

L2

L4

L1

L3

L2

L4

2

Slots

Frame

Ch 1

Ch 2

Interfering links on different channels

Mitigating intra­path interference

Using multiple channels for spatial efficiency

Handling wireless packet errors

PIP: Design Choices

50% thrput improvement

Channel Access: TDMA

Access Control: Centralized

Multi-Channel Operation

Goal: Effective and efficient delivery of sensed data over a multi-hop wireless sensor network.

1.

2.

3.

In-band time sync

Using multiple channels for spatial efficiency

Handling wireless packet errors

PIP: Design Choices

Reliability

Loss of time-sync

Per-hop ack

Mitigating intra­path interference

Connection-oriented

Channel Access: TDMA

Access Control: Centralized

Multi-Channel Operation

Goal: Effective and efficient delivery of sensed data over a multi-hop wireless sensor network.

1.

2.

3.

4.

Connection-state for a node: (slot, channel, sender/receiver).

Using multiple channels for spatial efficiency

Handling wireless packet errors

PIP: Design Choices

Mitigating intra­path interference

PIP: MAC Interfaces

ConnReq

SNACK

Sink Source

.

.

.

Data

EOF

TearDown

Transport protocol is simplified using PIP MAC module.

PIP MAC module

Transportmodule

statussend(pkt_type,

pkt_body,pkt_len,extra_params)

voidsendDone(pkt_type,

status)

voidrecv(pkt_type,

pkt_body,pkt_len,extra_params)

TimeSync module

voidabortConn()

pkt_type: ConnReq, Data, EOF, SNACK, TearDown

Routingmodule

nodelistgetPath(nodeid)

send()

recv()

3 phases: Schedule dissemination, data transfer, tear down

Phase 1

Phase 2

Phase 3

PIP: MAC Operation

E D C B A

Sink SourceU1C

Has routing path, computes schedule

Bulk data

PIP: MAC Operation

E D C B ASchedule + Conn RequestSink Source

U1C/UMC

Extract schedule info Forward request Start MAC level timer Tune to reception data channel

PIP: MAC Operation

E D C B ASchedule + Conn Request

Data + Ack

Sink Source

.

.

.

.

In-band time sync Data packets carry time sync info Nodes synchronized to source

SMC

PIP: MAC Operation

E D C B ASchedule + Conn Request

EOF

SNACK

Sink Source

.

.

.

.

.

.

.

.

EOF: End Of File SNACK: Selective Negative Ack

SMCData + Ack

PIP: MAC Operation

E D C B ASchedule + Conn Request

SNACK

Tear Down

Sink Source

.

.

.

.

.

.

.

.

A B

C D

B C

D E

PIP: “Packets In Pipeline” along the path

Odd (slot 1) Even (slot 2)

SMC

CH2

CH1

CH2

CH1

EOFData + Ack

PIP: Features

Combination of design choices is unique to achieve multi-hop bulk transfer.

Protocol is simple to implement on resource constrained platforms.

In-built and on-demand time synchronization.

Periodic data packets carry timing info, no separate channel required for time sync.

PIP: Prototype Implementation

PIP: Prototype Implementation

Telosb Platform

TI MSP 430 MCU (8MHz, 10K RAM, 48K Flash)

CC2420 802.15.4 Radio (250Kbps, TX/RX Buffer = 128 B)

Onboard Antenna (50m Indoors)

TinyOS 2.1.0

Software/Hardware Platform:

All functions of the MAC implemented in prototype. Data of 103 B. Logging module to collect logs

at each node

SFD based Time Sync: Hardware level timestamping (e.g. TSMP) No software latency Clock skew ~2 ticks (1 tick = 30.5 us)

PIP: Guard Band, Frame Duration

Component Measured value(1 tick = 30.5 micro-sec)

Time sync error(a) right after sync

(b) drift error+/- 1 tick per hop< 1.5 ticks/sec

Inaccuracy in timer fire 1-2 ticks

Processing jitter 1-2 ticks

Channel switching time ~ 10 ticks

Guard Time = 15 ticks.

RXTX

RX TX

TX RX

RX TX

Slot Time = 200 ticks. Transmission + ACK

Frame Duration = (200 + 15) X 2 = 430 ticks.

Frame Duration

2

3

TX RXRX TX1

Time Sync is required only w.r.t. neighboring nodes.

MCU

1

2

3

4

No Pipelining With Pipelining

PIP: Pipelining Inside a Node

CC2420 MCU CC2420

1

1

Tmote Sky platform

RX BUF

TX BUFCritical Path:

MCU

1

2

3

4

No Pipelining With Pipelining

PIP: Pipelining Inside a Node

CC2420 MCU CC2420

2

2

Tmote Sky platform

RX BUF

TX BUFCritical Path:

PIP: Evaluation and Comparison

10 node (9 hop) implementation results Used Implementation parameters for PIP simulator Modeling a node's queue as DTMC and analytical results Comparison with Flush

PIP: Throughput vs. Number of Nodes

Simulation, analytical and implementation results match.

~ 63Kbps throughput,12 X improvement over Flush.

PIP: Throughput vs. Number of Nodes

PIP throughput decreases only slightly with number of nodes. PIP throughput is robust to error rates.

Throughput decreases slightly.

Robust to wireless packet errors

PIP: Throughput Upper Bound

Radio capacity of 250 Kbps = 138 ticks/128 B packet

3 2 1

Single radio forwarding, 2 slots, capacity reduced to 125 Kbps = 276 ticks/128 B packet

Ack packet reception 37 ticks

Software overhead (e.g. interrupts, logging) 25 ticks

Guard band 15 ticks

total ticks = 276 + 2 * (37+25 +15) = 430 (frame duration)

Effective throughput = 103 * 8 / 430 =~ 63 Kbps

PIP: Throughput ComparisonHow would it have helped had PIP been used for the

Volcano Monitoring application (thought experiment)?

Effectiveness due to the multi-channel TDMA operation Time required/node to transfer data is ~7 seconds. Node’s ability to sense the events is minimally affected!

No. No. Fetch Flush PIPof of Single­ Single­ Total Single­ Single­ Total Single­ Single­ Total

Hops Nodes flow thr' flow Lat­ Latency  flow thr' flow Lat­ Latency flow thr' flow Lat­ Latencyput (Kbps) ency (sec) (sec) put (Kbps) ency (sec)  (sec) put (Kbps) ency (sec) (sec)

1 1 4.4 94 94 11 38.35 38.35 59.4 7 72 6 2.6 157 942 9.4 44.88 269.29 59.2 7.1 35.63 5 1.9 220 1100 7 60.27 301.35 58.6 7.2 364 2 1.4 283 566 6.2 68.05 136.09 58.5 7.2 14.45 1 1.2 346 346 5.4 78.13 78.13 58.5 7.2 7.26 1 1 409 409 5 84.38 84.38 58.4 7.3 7.3

3457 907.59 107.5

PIP: Comparison with Flush

For 10% error rate, PIP gives 50Kbps whereas Flush gives 8.5Kbps, a factor of 5.6 improvement over Flush.

PIP: External Interference

E D C B AE

5 Mhz channel of 802.15.4

WiFi source(channel occupancy

of ~2.3 ms)

PIP: Data Transfer In Progress

Question: Performance of PIP in the presence of external interference (e.g. WiFi in 2.4 Ghz frequency range)?

20 Mhzspread of 802.11 channel

PIP: External Interference, Channel Hopping

E D C B AE

20 Mhzspread of 802.11 channel

5 Mhz channel of 802.15.4

WiFi source(channel occupancy

of ~2.3 ms)

Node follows a frequency sequence in circular fashion Sequence conveyed during

connection set up.

Frequency/channel hopping across slots

Question: Performance of PIP in the presence of external interference (e.g. WiFi in 2.4 Ghz frequency range)?

PIP: External Interference, Channel Hopping

Frequency hopping effective in mitigating external interfernece.

1.6 to 1.8 X improvement

PIP: External Interference, Channel Hopping

Frequency hopping effective in mitigating external interfernece.

NA NA

802.11802.15.4BMACHOP

DCC(two-radio)

NA NA Flush NA

NA NA

Overlay MAC,FPS,TRAMA,

LMAC, SMAC,TMAC

CHMA, CHAT,MMAC, MAP,

SSCH,McMAC (1-hop)

RT-LinkWimax,TSMP,PIP

NA NA

Con

nec

tion

less

Con

nec

tion

orie

nte

dC

onn

ecti

onle

ssC

onn

ecti

onor

ien

ted

Un

coor

din

ated

(C

SM

A)

Coo

rdin

ated

(T

DM

A)

Single chnl. Multi chnl. Single chnl. Multi chnl.

Centralized Distributed

Related Work

PIP vs. WiMAX: PIP ­ implementation­based evaluation for a bulk transfer application.

PIP vs. TSMP/FPS: PIP ­ optimized for bulk data transfer applications, uses data packets themselves for synchronization.

PIP vs. Flush: Time synchronized slots to clock the packets. Multiple channels to increase the spatial resuse. Hardware optimization to move packet copy off the critical path.

PIP: Concluding Remarks

Goal: Achieve high thorughput bulk data transfer

PIP: An efficient centralized multi-channel TDMA system Effective time sync mechanism Non-requirement of flow control

Feasibility & effectiveness via implementation & evaluation Enables fast data transfer Robust to wireless packet errors, external interference Low memory requirement: queue size of 10 packets

PIP publication/presentation/source code at:http://www.cse.iitb.ac.in/~vijaygabale/pip/pip.php

Vijay Gabalevijaygabale@cse.iitb.ac.in

SyNerG: Systems and Networks Grouphttp://www.cse.iitb.ac.in/synerg

SenSys 2010

Thanks! Questions???

PIP: Pipelining Inside a Node and Slot Size

Timer fired, start TX(R)

S_SFD detected, start RX(S)

E_SFD detected, start ACK timer

FIFOP detected, cancel ACK timer

RX (S) done

Switch to RX channel, set next timer

TX (S) done

S_SFD Packet received

FIFOP high

TX_half_frame RX_half_frame

i - 1

i i

i + 1

TX (R) done RX (R) done

start TX(S)

Slot size = max (TX(R), RX(R), TX(S), RX(S)) = TX(R)

TX(R) = T (MAC payload 103 B + Time stamp 4 B + PIP header 3 B + 802.15.4 header 12 B) + T (ACK 4 B) + Software Overhead = 138 + 37 + 25 = 200 ticks

Node

Global Time

Dir

ecti

on o

f F

low

TX RX RXTX RXTX

TX RX RXTX RXTX

TX RX RXTX RXTX

RX TX RX TX RX TX

RX TX RX TX RX TX

Guard Band

PIP: Synchronization and Pipelining

1

2

3

4

5

Guard Band: (1) No transmission (2) Continue reception

PIP: Requirement of Queue SizeQueue requirement: To account for temporary variations in error rates of the incoming versus the outgoing wireless hop.

We choose queue size of 10 for our implementation.

PIP: Non-requirement of Flow ControlFlow control: In simulator, a node “magically” knows queue

state of downstream node and refrains from transmitting.

PIP performs well despite no flow control.

MCU

PIP: Time Sync Mechanism

CC2420 MCUCC2420

Capture S_SFD, insert global timestamp (T1)

Capture S_SFD, record local time (T2)

Node 1 Node 2

Offset of Node 2: T1 - T2.

Hardware level timestamping, no software latency.

Clock skew of ~2 ticks (1 tick ~ 30.5 us) .

Periodic data packets keep clock correction to minimal.

PIP: External Interference, Channel Hopping

External interference in wireless networks

Performance of PIP in the presence of WiFi in 2.4 Ghz range?

WiFi source on channel 6 (center frequency of 2.426 Ghz) Interferences with five 5Mhz 802.15.4 channels WiFi source generates 1777 B at 6Mbps (channel occupancy of

~2.3ms) for varing the inter-packet time.

Frequency/channel hopping in slots of the frame: Node follows a frequency sequence of {k,

k+1, . . . , n, 1, . . . } in circular fashion Sequence conveyed during connection set up.

Experimental set up:

PIP: External Interference, Channel Hopping

Frequency hopping effective in mitigating external interfernece.