robin kravets, 2009 energy conservation in wireless networks

© R

obin

Kra

vets

, 200

9

Energy Conservation in Wireless Networks

© R

obin

Kra

vets

, 200

92

Power is Everything

Mobile devices are power constrained

Battery powered May be hard to replace or

replenish power Desire long operational

time

How to reduce energy consumption?

http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_DisplayProductInformation-Start;sid=wiUXZMrYz6kXcYvYtREdb4XUR5lM29OQx8Q=?CategoryName=hid_pr_p_100ecouponEligibleModels_cpu&ProductSKU=PCGABP3T

Energy Consumption in Wireless Networks

Data communication Transmission of data packets from source to destination

Overhead Data transmission

Have to do this! MAC protocols

Effects all communication Control Packets

Ex: RTS, CTS, ACK Idle devices

Wireless nodes consume energy even if they are not actively transmitting data MAC protocol constantly listens to the channel

© R

obin

Kra

vets

, 200

93

© R

obin

Kra

vets

, 200

94

Control Overhead

Medium Access Control Protocol Channel access Contention resolution Ex: IEEE 802.11

Channel acquisition RTS/CTS handshake

medium busy

DIFSDIFScontention window(randomized back-offmechanism)

slot timedirect access if medium is free DIFS

RTS CTS DATA

Sense medium

time

© R

obin

Kra

vets

, 200

95

Device Energy Costs

Base card power Pbase Cost of running the card Fixed, defined by the card

Base transmission power Pxmit Processing costs for sending Fixed, defined by the card

Base reception power Precv Processing costs for reception Fixed, defined by card

Transmit power level Pt Cost for driving the transmitter Tunable

© R

obin

Kra

vets

, 200

96

Device Energy Costs

Idle-time energy consumption Base card costs Time node spends idle Typically node is listening to

the idle channel

Main target of many energy conservation techniques

Idle time

Pba

se

© R

obin

Kra

vets

, 200

97

Device Energy Costs

Transmission-time energy consumption Base card costs Base transmission costs Transmission time

Transmission rate Transmit power level

transmission time

Pba

seP

xmit

Pt

© R

obin

Kra

vets

, 200

98

Device Energy Costs

Receive-time energy consumption Base card costs Base reception costs Reception time

Transmission rate

reception time

Pba

seP

recv

© R

obin

Kra

vets

, 200

99

Example Card Costs

0

500

1000

1500

2000

2500

Cisco Aironet350

Cabletron ORiNOCO11b

Socket LowPower SDIO

Mica2 Mote

Pow

er (W

)

TransmitReceiveIdleSleep

Example Network Energy Consumption

© R

obin

Kra

vets

, 200

911

Pow

er (m

W)

0

500

1000

1500

2000

2500

0 10 20 30 40 50 60 70 80 90

Time

Pbase

Pxmit

Example Network Energy Consumption

© R

obin

Kra

vets

, 200

912

Pow

er (m

W)

0

500

1000

1500

2000

2500

0 10 20 30 40 50 60 70 80 90

Time

Pbase

Idle-Time Energy Conservation

Goal Reduce idle listening costs

Idle 1W Sleep 0.05W

Support communication in the network If all nodes are asleep, no one can communicate!

Approach Allow idle nodes to transition into a low power

sleep state Device suspension

© R

obin

Kra

vets

, 200

913

Idle-Time Energy Conservation Techniques

Device suspension (sleep) Reduced energy consumption Suspended communication capabilities Effects

Buffer overflow Wasted bandwidth Lost messages Breaks broadcast medium

© R

obin

Kra

vets

, 200

914

© R

obin

Kra

vets

, 200

915

Communication Device Suspension

Ideal Power Management Sleep whenever there is no data to receive from

the base station Wake up for any incoming receptions

Realistic Goals Adapt the sleep duration to reflect the

communication patterns of the application Remain awake when there is active

communication Otherwise, suspend

© R

obin

Kra

vets

, 200

916


Problems How can a sender differentiate between a

suspended node and a node that has gone away? Suspended receiver buffer packet Confused sender dropped packet, extra energy

consumption How can a suspended node know there is

communication for it? Wake up too soon waste energy Wake up too late delay/miss packets


Approach Ensure overlap between sender’s and

receiver’s awake times Protocols

Periodic Resume Triggered Resume MAC-based Approaches

© R

obin

Kra

vets

, 200

917

Periodic Resume

Approach Suspend most of the time Periodically resume to check for pending

communication Communication indications

Out-of-band channel In-band signaling

Protocols Synchronous Asynchronous

© R

obin

Kra

vets

, 200

918

Synchronous Periodic Resume

Approach If all nodes are synchronized, all nodes are

guaranteed to have overlapping awake periods Examples

IEEE 802.11 PSM Idea: switch the transceiver off if not needed States of a station: sleep and awake Timing Synchronization Function (TSF)

Stations wake up at the same time

© R

obin

Kra

vets

, 200

919

802.11 Synchronization

Infrastructure mode Transmit beacon at start of beacon interval Or at earliest idle time after start

© R

obin

Kra

vets

, 200

920

beacon interval(20ms – 1s)

tmedium

accesspoint

busy

B

busy busy busy

B B B

value of the timestamp B beacon frame

Synchronization

Ad hoc mode Nodes ad random back off to prevent beacon

collisions

© R

obin

Kra

vets

, 200

921

tmedium

station1

busy

B1

beacon interval

busy busy busy

B1

value of the timestamp B beacon frame

station2

B2 B2

random delay

IEEE 8021.11 PSM

Nodes are synchronized and wakeup periodically Each beacon period is broken up into two segments

Ad-hoc Traffic Indication Map (ATIM) Window A node makes an announcement in the ATIM window if it

has a packet for another node The target node responds with an ATIM ACK

Transmission period The sender can transmit the packet until the end of the

beacon period If a node receives no announcements, it goes back to sleep

© R

obin

Kra

vets

, 200

922

IEEE 8021.11 PSM

Infrastructure Mode Traffic Indication Map (TIM)

List of unicast receivers transmitted by AP Delivery Traffic Indication Map (DTIM)

List of broadcast/multicast receivers transmitted by AP Ad hoc Mode

Ad hoc Traffic Indication Map (ATIM) Announcement of receivers by stations buffering frames More complicated - no central AP Collision of ATIMs possible (scalability?)

© R

obin

Kra

vets

, 200

923

© R

obin

Kra

vets

, 200

924

B1

B2

IEEE 802.11 PSM – Ad Hoc Mode

awake A Transmit ATIM D Transmit Data

t

Node 1

B Beacon Frame

Node 2

Random Delay

B2

D

d

B1

ATIMwindow beacon interval

A

a

a Acknowledge ATIM d Acknowledge Data

Automatic Power Save Delivery (APSD)

Automatic Power Save Delivery Infrastructure mode Allows setting up scheduled delivery of packets Better power management method When data is sent by a station AP sends back queued

frames Good for synchronous traffic Benefits

The station now does not have to wake up for every beacon Time offset in the beacon interval can be specified so

stations wake up in different parts of the beacon interval to listen

© R

obin

Kra

vets

, 200

925

Synchronous Periodic Resume

Problems Maintaining synchronization in ad hoc networks

is difficult Synchronization overhead may outweigh benefits of

sleeping Throughput is limited by the size of the ATIM

window If the ATIM window is too small, packets get buffered Buffers may eventually overflow

© R

obin

Kra

vets

, 200

926

© R

obin

Kra

vets

, 200

927

Asynchronous Periodic Resume

Approach Stay awake longer to guarantee overlap of

awake periods Use beacon messages at the start of awake

periods Some protocols use notification messages

(similar to ATIM) Basic protocol

Overlap is guaranteed if the awake periods are more than half the beacon period

© R

obin

Kra

vets

, 200

928


Problem No guarantee that nodes will hear each

other’s beacon or notification messages

time

Beacon Interval

Suspend Period

Node 1

Node 2

Beacon window

Notification Window

Awake Period

Beacon Message

© R

obin

Kra

vets

, 200

929


Alternate solution Have a beacon at the beginning and end

of the beacon interval

time

Beacon Interval

Suspend Period

Beacon window

Notification Window

Awake Period

Beacon Message

Node 1

Node 2

© R

obin

Kra

vets

, 200

930


Alternate solution Beacon at the beginning of odd periods

Beacon at the end of even periods

time

Beacon window

Notification Window

Awake Period

Beacon Message

Odd Beacon Interval Even Beacon Interval

Odd Beacon Interval Even Beacon Interval

Node 1

Node 2

© R

obin

Kra

vets

, 200

931


Problem Nodes stay awake more than half the

time Wastes too much energy!

Solution Do not wake up every beacon interval

© R

obin

Kra

vets

, 200

932


Approach 1 Wake up once every T intervals Adds delay up to T length of beacon interval

time

Beacon Interval

Beacon window

Notification Window

Awake Period

Beacon Message

Node 1

Node 2

© R

obin

Kra

vets

, 200

933

ci

ri

Node i is awake


Approach 2 Increase number of beacon intervals in cycle (n) Increase number of awake periods (2n – 1 of n2)

cj

Node j is awake

rj

n

n

Both nodes are awake

Delay is determined by where the overlap is (worst case n2)

© R

obin

Kra

vets

, 200

934

Node i is awake

Node j is awake


Approach 2 Example: n = 4, n2 = 16, 2n-1 = 7

Two overlapping intervals: delay = n2 - 2

Both nodes are awake

0 1 2 3

4 5 6 7

8 9 10 11

12 13 14 15

0 1 2 3

4 5 6 7

8 9 10 11

12 13 14 15

Node i Node j

© R

obin

Kra

vets

, 200

935

Approach 3 Find a feasible overlapping pattern

Guarantee at least one overlapping interval with every other node


Node 2

Node 3

Node 4

Node 5

Node 6

Node 7slot1 2 3 4 5 6 7

awake pattern

Node 1

© R

obin

Kra

vets

, 200

936


Approach 3 To prevent buffer overflow, nodes can stay awake longer Delay depends on the number of overlapping intervals

time

Beacon Interval

Beacon window

Awake Period

Beacon Message

Node 1

Node 2

© R

obin

Kra

vets

, 200

937


Challenges Reducing time spent awake Reducing delay No support for broadcast

None of the current approaches provide an interval where all nodes are awake

© R

obin

Kra

vets

, 200

938

Triggered Resume

Approach Use a second control channel (second radio)

Sender transmits RTS or beacon messages in control channel

Receiver replies in control channel and turns on main channel

Main channel is only used for data Second channel

Must consume less energy than the main channel Must not interfere with the main channel Ex: RFID, 915Mhz

© R

obin

Kra

vets

, 200

939

Triggered Resume

Protocols Power Aware Multi-Access Protocol (PAMAS)

Shut off device when channel is busy Wake-on-Wireless

Control channel is always active STEM

Control channel is managed similar to IEEE 802.11 PSM

© R

obin

Kra

vets

, 200

940

Triggered Resume

Approach – PAMAS Data channel

Power off radio when data is destined to a different node Control channel

Probe neighbors to find longest remaining transfer

time

Node A

Node B

RTS/CTS

Node C

A CB D Awake/listen Data transmission/receptionE

BUSY

Probe on control channel

© R

obin

Kra

vets

, 200

941

Triggered Resume

Approach – STEM Low duty cycle paging channel to wake up a

neighboring node Use separate radio for the paging channel to

avoid interference with regular data forwarding Trades off energy savings for setup latency

Wakeup plane: f1

Data plane: f2

© R

obin

Kra

vets

, 200

942

Triggered Resume

Approach – STEM

time

Node B - control

Node B - data

Awake/listen Receive and reply

Transmitrequest

Node A – control

Node A - data

Data transmission/reception

© R

obin

Kra

vets

, 200

943

Triggered Resume

Challenges Two radios are more complex than one Channel characteristics may not be the

same for both radios A successful RTS on the control channel

does not guarantee the reverse channel works

A failed RTS on the control channel does not indicate that the reverse channel doesn’t work

MAC-Based Approaches

Break away from straight 802.11 Change the mechanisms in the MAC

layer Allow packet trains Use new notification mechanisms

© R

obin

Kra

vets

, 200

944


S-MAC RTS-CTS protocol

Reservations for consecutive fragments Duty cycle

Sleep, wake up, listen, return to sleep Variable sleep time

Tradeoff energy for latency Neighbors exchange schedules

Requires loose synchronization Control overhead may dominate energy savings

Adaptive listening Wake up at end of RTS-CTS-DATA-ACK period to send data Lower latency, save energy

© R

obin

Kra

vets

, 200

945


B-MAC Eliminate need to synchronization Put the burden on the sender Sender

Sends a preamble Sends data immediately after preamble

Receiver Wakes up periodically If it hears a preamble, wait for packet transmission

X-MAC Similar to B-MAC Sender sends multiple short preambles and waits for an ACK

between them

© R

obin

Kra

vets

, 200

946

B-MAC

© R

obin

Kra

vets

, 200

947

PREAMBLE

A

B

C

D

E

DATA

t1: Flow 1 data

arrival

DIFS wait

t2: Flow 2 data

arrival

DATA

Channel Polling Intervalt3

Flow1data

Flow2data

PREAMBLE

Energy as a Resource

Energy conservation is still an open problem Must start to consider the applications

and data Trade-offs between application quality

and saving energy

© R

obin

Kra

vets

, 200

948

robin kravets, 2009 energy conservation in wireless networks

Documents