osu-mac

5/20/2018 osu-mac

1/43

1

MAC Layer Protocols for

Sensor Networks

Prasun Sinha

Department of Computer Science and Engineering

Ohio State University

April 25th, 2007

(some slides adapted from authors presentations found on the Internet)

5/20/2018 osu-mac

2/43

2

Introduction

Wireless sensor network

Special ad hoc wireless network

Large number of nodes w/ sensors & actuators

Battery-powered nodes energy efficiency

Unplanned deployment self-organization

Node density & topology change robustness

Sensor-net applications Nodes cooperate for a common task

In-network data processing

5/20/2018 osu-mac

3/43

3

Some Applications of Sensor Networks

Data Collection Networks Sensing Movement of Glaciers

Environment Monitoring

Habitat Monitoring Habitat Monitoring of Storm Petrels in Great Duck Island

Microsofts Effort to put every sensor on the web

Event Triggered Networks Structural Monitoring

Golden Gate Bridge

Precision Agriculture Oregon and British Columbia Vineyards

Condition based Maintenance Hardware Manufacturing facilities

Military Applications Environment Monitoring

Poisonous gas, pollutants etc.

National Asset Protection Coastline, Border Patrol, Roadways, Oil/gas pipelines, Secure facilities
http://www.esica.com/products/index.htmlhttp://www.esica.com/products/index.html

5/20/2018 osu-mac

4/43

4

Talk Outline

SMAC: http://www.isi.edu/~weiye/pub/smac_ton.pdf

Medium Access Control With Coordinated Adaptive Sleeping for Wireless

Sensor Networks, Wei Ye, John Heidemann, and Deborah Estrin, Transactions

on Networking, 2004, (also Infocom 2002)

BMAC: http://www.polastre.com/papers/sensys04-bmac.pdf Versatile Low Power Media Access for Wireless Sensor Networks, Joseph

Polastre, Jason Hill and David Culler, ACM SENSYS 2004

CMAC: http://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdf

CMAC: An Energy Efficient MAC Layer Protocol Using Convergent PacketForwarding for Wireless Sensor Networks, Sha Liu, Kai-Wei Fan and Prasun

Sinha, IEEE SECON 2007
http://www.isi.edu/~weiye/pub/smac_ton.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.isi.edu/~weiye/pub/smac_ton.pdf

5/20/2018 osu-mac

5/43

5

Medium Access Control in Sensor Nets

Important attributes of MAC protocols

1. Collision avoidance

2. Energy efficiency

3. Scalability in node density

4. Latency

5. Fairness

6. Throughput7. Bandwidth utilization

Primary

Secondary

5/20/2018 osu-mac

6/43

6

Major sources of energy waste (cont.) Idle listening

Long idle time when no sensing event happens

Collisions

Control overhead

Overhearing

We try to reduce energy consumption from

all above sourcesCombine benefits of TDMA + contention

protocols

Energy Efficiency in MAC

Common to allwireless networks

Dominant in sensornets

5/20/2018 osu-mac

7/437

Sensor-MAC (S-MAC) Design

Tradeoffs

Major components in S-MAC Periodic listen and sleep

Collision avoidance

Overhearing avoidance Massage passing

Latency

FairnessEnergy

5/20/2018 osu-mac

8/438

Periodic Listen and Sleep

Problem:Idle listening consumes significantenergy

Solution:Periodic listen and sleep

Turn off radio when sleeping

Reduce duty cycle to ~ 10% (200ms on/2s off)

sleeplisten listen sleep

Latency Energy

5/20/2018 osu-mac

9/43

9


Schedules can differ

Prefer neighboring nodes have same schedule

easy broadcast & low control overhead

Border nodes:two schedulesbroadcast twice

Node 1

Node 2



Schedule 2

Schedule 1

5/20/2018 osu-mac

10/43

10


Schedule Synchronization

Remember neighbors schedules

to know when to send to them

Each node broadcasts its schedule every fewperiods of sleeping and listening

Re-sync when receiving a schedule update

Schedule packets also serve as beacons for new

nodes to join a neighborhood

5/20/2018 osu-mac

11/43

11

Collision Avoidance

Problem:Multiple senders want to talk

Options:Contention vs. TDMA

Solution:Similar to IEEE 802.11 ad hoc

mode (DCF)

Physical and virtual carrier sense

Randomized backoff time

RTS/CTS for hidden terminal problem

RTS/CTS/DATA/ACK sequence

5/20/2018 osu-mac

12/43

12

Overhearing Avoidance

Problem:Receive packets destined to others Solution:Sleep when neighbors talk

Basic idea from PAMAS (Singh, Raghavendra 1998)

But we only use in-channel signaling Who should sleep?

All immediate neighbors of sender and receiver

How long to sleep? The durationfield in each packet informs other

nodes the sleep interval

5/20/2018 osu-mac

13/43

13

Message Passing

Problem:Sensor net in-network processingrequires entire message

Solution:Dont interleave different messages Long message is fragmented & sent in burst

RTS/CTS reserve medium for entire message

Fragment-level error recovery ACK

extend Tx time and re-transmit immediately

Other nodes sleep for whole message time

FairnessEnergyMsg-level latency

5/20/2018 osu-mac

14/43

14

Msg Passing vs. 802.11 fragmentation

S-MAC message passing

RTS 21 ...

...

Data 19

ACK 18CTS 20

Data 17

ACK 16

Data 1

ACK 0

RTS 3 ...

...

Data 3

ACK 2CTS 2

Data 3

ACK 2

Data 1

ACK 0

Fragmentation in IEEE 802.11

No indication of entire time other nodes keep listening

If ACK is not received, give up Tx fairness

5/20/2018 osu-mac

15/43

15

Implementation on Testbed Nodes

PlatformMotes (UC Berkeley)

8-bit CPU at 4MHz,

8KB flash, 512B RAM916MHz radio

TinyOS:event-driven

Compared MAC modules1. IEEE 802.11-like protocol w/o sleeping2. Message passing with overhearing avoidance

3. S-MAC (2 + periodic listen/sleep)

5/20/2018 osu-mac

16/43

16

Experiments

Topology and measured energy consumption

on source nodesSource 1

Source 2

Sink 1

Sink 2

Each source node sends10 messages

Each message has 400Bin 10 fragments

Measure total energy overtime to send all messages

0 2 4 6 8 10

200

400

600

800

1000

1200

1400

1600

1800Average energy consumption in the source nodes

Message inter-arrival period (second)

Energyconsumption(mJ)

802.11-like protocolOverhearing avoidanceS-MAC

5/20/2018 osu-mac

17/43

17

S-MAC Conclusions

S-MAC offers significant energy efficiency

over always-listening MAC protocols

S-MAC can function at 10% duty cycle

5/20/2018 osu-mac

18/43

18

Talk Outline





BMAC: http://www.polastre.com/papers/sensys04-bmac.pdf

Versatile Low Power Media Access for Wireless Sensor Networks,

Joseph Polastre, Jason Hill and David Culler, ACM SENSYS 2004

CMAC: http://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdf

CMAC: An Energy Efficient MAC Layer Protocol Using Convergent Packet

Forwarding for Wireless Sensor Networks, Sha Liu, Kai-Wei Fan and Prasun

Sinha, IEEE SECON 2007
http://www.isi.edu/~weiye/pub/smac_ton.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.isi.edu/~weiye/pub/smac_ton.pdf

5/20/2018 osu-mac

19/43

19

BMAC Objectives

Information sharing with higher layers

Control and reconfiguration of link protocol

Tradeoffs in link protocols

5/20/2018 osu-mac

20/43

20

B-MAC Design

Principles

Reconfigurable MAC

protocol

Flexible control Hooks for sub-primitives

Backoff/Timeouts

Duty Cycle

Acknowledgements

Feedback to higher

protocols

Minimal implementation

Minimal state

Primary Goals

Low Power Operation

Effective Collision Avoidance

Simple/Predicable Operation

Small Code Size

Tolerant to ChangingRF/Networking Conditions

Scalable to Large Number ofNodes

Implementation is on Mica2motes with CC1000

5/20/2018 osu-mac

21/43

21

B-MAC Link Protocol Interaction

Reconfiguration and control of link layer protocol parameters Acknowledgements, Backoff/Timeouts, Power Management,

Ability to choose tradeoffsknobs Fairness, Latency, Energy Consumption, Reliability

Power consumption estimation through analytical and empiricalmodels Feedback to network protocols

Lifetime estimation

Mechanisms to achieve network protocols goals

5/20/2018 osu-mac

22/43

22

Low Power Listening (LPL) Higher level communication scheduling

Energy Cost = RX + TX + Listen

Start by minimizing the listen cost

Example of a typical low levelprotocol mechanism

Periodically wake up, sample channel, sleep

Properties Wakeup time fixed

Check Time between wakeups variable

Preamble length matches wakeup interval

Overhear all data packets in cell Duty cycle depends on number of neighbors

and cell traffic

RXwakeup

wakeup

wakeup

wakeup

wakeup

wakeup

wakeup

wakeup

wakeup

TX

sleep sleep sleep

sleepsleepsleep

Node 2

Node 1time

time

5/20/2018 osu-mac

23/43

23

Effect of Neighborhood Size

Neighborhood Size affects amount oftraffic in a cell Network protocols typically keep track of

neighborhood size

Bigger Neighborhood More traffic

0 20 40 60 80 1000

20

40

60

80

100

120

140

160

180

200

Neighborhood size

ChannelActivityCheckInterval(ms)

Expected Lifetime Contour

0.25

0.5

0.75

11.25

1.52

2.5

0 20 40 60 80 1000

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1

Number of neighboring nodes

Effectived

utycycle(%)

200ms check interval100ms check interval50ms check interval25ms check interval10ms check interval

Effect of neighborhood size on node duty cycle

5/20/2018 osu-mac

24/43

24

B-MAC Performance

Experimental Setup: nnodes send as quickly as

possible to saturate thechannel

B-MAC never worse thantraditional approach Often much better

Flexible configuration yieldsefficient: Reliable transport (Acks)

Hidden Terminal support(RTS-CTS)

0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

0 5 10 15 200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Per

centageofChannelCap

acity

B-MACB-MAC w/ ACKB-MAC w/ RTS-CTSS-MAC unicastS-MAC broadcastChannel Capacity

Throughput(bps)

Protocol ROM RAM

B-MAC 3046 166

B-MAC w/ ACK 3340 168

B-MAC w/ Duty Cycling 4092 170

B-MAC w/ DC & ACK 4386 172

S-MAC 6274 516

7

8

9

10

1

6

5

4

3

2

0

7

8

9

10

1

6

5

4

3

2

0

topology

5/20/2018 osu-mac

25/43

25

Fragmentation Support S-MAC

RTS-CTS Fragmentation Support

B-MAC w/app control Network protocol sends initial data packet with

number of fragments pending

Disable backoff & LPL for rest of fragments

Measure energyconsumption at C(bottleneck node)

Minimizing power relieson controlling link layerprimitives

0 50 100 150 200 2500

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

Fragment size (bytes)

Energyperb

yte(mJ/byte)

Mean energy consumption per byte (100 second sample period)

B-MAC w/ no app controlB-MAC w/ app controlS-MACT-MAC (simulated)Optimal Schedule

0 50 100 150 200 2500

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

Fragment size (bytes)

Energyperbyte(mJ/byte)

Mean energy consumption per byte (10 second sample period)

B-MAC w/ no app controlB-MAC w/ app controlS-MACT-MAC (simulated)Optimal Schedule

A

B

C

E

D

10 packets every 10 seconds

10 packets every 100 seconds

5/20/2018 osu-mac

26/43

26

BMAC Conclusions

Coordination with higher protocols is essential forlong lived operation

Feedback allows protocols to make informeddecisions

5/20/2018 osu-mac

27/43

27

Talk Outline





BMAC: http://www.polastre.com/papers/sensys04-bmac.pdf

Versatile Low Power Media Access for Wireless Sensor Networks, Joseph

Polastre, Jason Hill and David Culler, ACM SENSYS 2004

CMAC: http://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-

cmac.pdf CMAC: An Energy Efficient MAC Layer Protocol Using Convergent Packet

Forwarding for Wireless Sensor Networks, Sha Liu, Kai-Wei Fan and

Prasun Sinha, IEEE SECON 2007
http://www.isi.edu/~weiye/pub/smac_ton.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.cse.ohio-state.edu/~prasun/publications/conf/secon07-cmac.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.polastre.com/papers/sensys04-bmac.pdfhttp://www.isi.edu/~weiye/pub/smac_ton.pdf

5/20/2018 osu-mac

28/43

28

Existing MAC Layer Approaches

Synchronized Solutions SMAC, TMAC, DMAC

Unsynchronized Solutions BMAC, GeRaF

5/20/2018 osu-mac

29/43

29

Synchronized Approaches

Unnecessary power consumption on

synchronization message exchanges

Can be improved if synchronization is infrequent

Can not achieve very low duty cycles 10% level

5/20/2018 osu-mac

30/43

30

Unsynchronized Approaches - BMAC

Long Preamble Approach

Wasteful if the receiver wakes up early

Sender

Receiver

Sleep Long Preamble

Sleep Receiving Preamble

Packet

Packet

5/20/2018 osu-mac

31/43

31

Our Approach - CMAC

Unsynchronized Duty Cycling

Flow Initialization

Aggressive RTS

Anycasting for Packet Forwarding

Flow Stabilization

Convergent Packet Forwarding

5/20/2018 osu-mac

32/43

32

CMAC: Aggressive RTS

Aggressive RTS

Sender

Receiver

Sleep RTS

Sleep RX

Packet

Packet Sleep

SleepRTS RTS RX

CTS

5/20/2018 osu-mac

33/43

33

CMAC: Aggressive RTS(Double Channel Check)

The receiver only needs to check if the channel is busy afterwaking up

Check the channel twice to avoid missing activities

Time between the two checks

Larger than inter-RTS separation

Smaller than RTS duration

RTS RTS

Channel check

RTS RTS

Channel check

RTS RTS

Channel check

(a) (b)

(c)

(shouldnt

happen)

5/20/2018 osu-mac

34/43

34

CMAC: Anycasting

Anycast Packet Forwarding Exploits network density

Nodes other than the target receiver may

wake up earlier

can make some progress toward the sink

C i A A R i

5/20/2018 osu-mac

35/43

35

Contention Among Anycast Receivers

Anycast to nodes which are

awake

closer to the destination

More than one potential participants

Nodes closer to the sink send CTSs earlier

C i A A R i

5/20/2018 osu-mac

36/43

36

Contention Among Anycast Receivers

Anycast candidate prioritization

Canceled RTS

CTS

RTSSender

CTS slot

Canceled CTS

mini-slot

Node in R1

Node in R1

Node in R2

Node in R3

Canceled CTS

Canceled CTS

5/20/2018 osu-mac

37/43

37

CMAC: Convergent Forwarding

Anycast has higher overhead than unicast

Nodes stay awake for a short duration after

receiving a packet For how long?

Switch from anycast to unicast if

Node is able to communicate with a node in R1

Cannot find a better next hop than current one

5/20/2018 osu-mac

38/43

38

Active nodesSleeping nodes

Unicast linksAnycast links

Time 1 Time 2 Time 3

CMAC: Convergent Forwarding Illustration

5/20/2018 osu-mac

39/43

39

Experiments

Testbed: Kansei Testbed

7 x 15 XSM nodes

Metrics

Normalized Energy Consumption Average energy consumption to deliver one packet

Throughput: Number of packets received by sink

Latency

Scenarios: Static Event

Moving Event

5/20/2018 osu-mac

40/43

40

Experimental Results: Static Scenario

Sink is at one corner of the network The node that is diagonally opposite to sink sends data

to the sink

Vary data rates

5/20/2018 osu-mac

41/43

41

Experimental Results: Moving Event

One node generates data at any point for the sink

The node generating data (event) moves along one

side of the network that does not include the sink.

Vary moving speeds

5/20/2018 osu-mac

42/43

42

CMAC Conclusion

CMAC supports high throughput, low latency andconsumes less energy than existing solutions.

CMACs performance difference from existing

approaches increases with speed of the moving event.

5/20/2018 osu-mac

43/43

Thanks for your attention!

For more information on my researchplease check my webpage at

http://www.cse.ohio-state.edu/~prasun
http://www.cse.ohio-state.edu/~prasunhttp://www.cse.ohio-state.edu/~prasunhttp://www.cse.ohio-state.edu/~prasunhttp://www.cse.ohio-state.edu/~prasun

osu-mac

Documents