1. © Robin Kravets, 2009 Energy Conservation in Wireless Networks

2. © Robin Kravets, 2009 2 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?

3. 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 © Robin Kravets, 2009 3

4. 4 Control Overhead Medium Access Control Protocol  Channel access  Contention resolution  Ex: IEEE 802.11 Channel acquisition RTS/CTS handshake medium busy DIFS contention window (randomized back-off mechanism) slot time direct access if medium is free  DIFS RTSCTS DATA Sense medium time

5. © Robin Kravets, 2009 5 Device Energy Costs Base card power P base  Cost of running the card  Fixed, defined by the card Base transmission power P xmit  Processing costs for sending  Fixed, defined by the card Base reception power P recv  Processing costs for reception  Fixed, defined by card Transmit power level P t  Cost for driving the transmitter  Tunable

6. © Robin Kravets, 2009 6 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 P base

7. © Robin Kravets, 2009 7 Device Energy Costs Transmission-time energy consumption  Base card costs  Base transmission costs  Transmission time Transmission rate Transmit power level transmission time P base P xmit PtPt

8. © Robin Kravets, 2009 8 Device Energy Costs Receive-time energy consumption  Base card costs  Base reception costs  Reception time Transmission rate reception time P base P recv

9. © Robin Kravets, 2009 9 Example Card Costs 0 500 1000 1500 2000 2500 Cisco Aironet 350 CabletronORiNOCO 11b Socket Low Power SDIO Mica2 Mote Power (W) Transmit Receive Idle Sleep

10. © Robin Kravets, 2009 10 Example Card Costs Cisco Aironet off1600 Off RF Power Amp. 100300 0.05 RF/IF Converter 35Off 35 OffLow Noise Amp. RXTXIDLESLEEPIC/Mode 125 40 5MAC 900250011020Max Total Power 40 0.075 Dual Freq. Synth. 500400 10 IF Modem 10033 23 2Baseband

11. Example Network Energy Consumption © Robin Kravets, 2009 11 Power (mW) 0 500 1000 1500 2000 2500 0102030405060708090 Time P base P xmit

12. Example Network Energy Consumption © Robin Kravets, 2009 12 Power (mW) 0 500 1000 1500 2000 2500 0102030405060708090 Time P base

13. 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 © Robin Kravets, 2009 13

14. Idle-Time Energy Conservation Techniques Device suspension (sleep)  Reduced energy consumption  Suspended communication capabilities  Effects Buffer overflow Wasted bandwidth Lost messages Breaks broadcast medium © Robin Kravets, 2009 14

15. © Robin Kravets, 2009 15 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

16. © Robin Kravets, 2009 16 Communication Device Suspension 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

17. Communication Device Suspension Approach  Ensure overlap between sender’s and receiver’s awake times Protocols  Periodic Resume  Triggered Resume  MAC-based Approaches © Robin Kravets, 2009 17

18. 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 © Robin Kravets, 2009 18

19. 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 © Robin Kravets, 2009 19

20. 802.11 Synchronization Infrastructure mode  Transmit beacon at start of beacon interval  Or at earliest idle time after start © Robin Kravets, 2009 20 beacon interval (20ms – 1s) t medium access point busy B BBB value of the timestamp B beacon frame

21. Synchronization Ad hoc mode  Nodes ad random back off to prevent beacon collisions © Robin Kravets, 2009 21 t medium station 1 busy B1B1 beacon interval busy B1B1 value of the timestamp B beacon frame station 2 B2B2 B2B2 random delay

22. 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 © Robin Kravets, 2009 22

23. 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?) © Robin Kravets, 2009 23

24. © Robin Kravets, 2009 24 B1B1 B2B2 IEEE 802.11 PSM – Ad Hoc Mode awake A Transmit ATIM D Transmit Data t Node 1 B Beacon Frame Node 2 Random Delay B2B2 D d B1B1 ATIM window beacon interval A a a Acknowledge ATIM d Acknowledge Data

25. 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 © Robin Kravets, 2009 25

26. 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 © Robin Kravets, 2009 26

27. © Robin Kravets, 2009 27 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

28. © Robin Kravets, 2009 28 Asynchronous Periodic Resume 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

29. © Robin Kravets, 2009 29 Asynchronous Periodic Resume 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

30. © Robin Kravets, 2009 30 Asynchronous Periodic Resume 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 IntervalEven Beacon Interval Odd Beacon IntervalEven Beacon Interval Node 1 Node 2

31. © Robin Kravets, 2009 31 Asynchronous Periodic Resume Problem  Nodes stay awake more than half the time  Wastes too much energy! Solution  Do not wake up every beacon interval

32. © Robin Kravets, 2009 32 Asynchronous Periodic Resume 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

33. © Robin Kravets, 2009 33 cici riri Node i is awake Asynchronous Periodic Resume Approach 2  Increase number of beacon intervals in cycle (n)  Increase number of awake periods (2n – 1 of n 2 ) cjcj Node j is awake rjrj n n Both nodes are awake Delay is determined by where the overlap is (worst case n 2 )

34. © Robin Kravets, 2009 34 Node i is awake Node j is awake Asynchronous Periodic Resume Approach 2  Example: n = 4, n 2 = 16, 2n-1 = 7 Two overlapping intervals: delay = n 2 - 2 Both nodes are awake 0123 4567 891011 12131415 0123 4567 891011 12131415 Node iNode j

35. © Robin Kravets, 2009 35 Approach 3  Find a feasible overlapping pattern Guarantee at least one overlapping interval with every other node Asynchronous Periodic Resume Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 slot1234567 awake pattern Node 1

36. © Robin Kravets, 2009 36 Asynchronous Periodic Resume 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

37. © Robin Kravets, 2009 37 Asynchronous Periodic Resume Challenges  Reducing time spent awake  Reducing delay  No support for broadcast None of the current approaches provide an interval where all nodes are awake

38. © Robin Kravets, 2009 38 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

39. © Robin Kravets, 2009 39 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

40. © Robin Kravets, 2009 40 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 ACBD Awake/listen Data transmission/ reception E BUSY Probe on control channel

41. © Robin Kravets, 2009 41 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 : f 1 Data plane : f 2

42. © Robin Kravets, 2009 42 Triggered Resume Approach – STEM time Node B - control Node B - data Awake/listen Receive and reply Transmit request Node A – control Node A - data Data transmission/ reception

43. © Robin Kravets, 2009 43 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

44. MAC-Based Approaches Break away from straight 802.11  Change the mechanisms in the MAC layer Allow packet trains Use new notification mechanisms © Robin Kravets, 2009 44

45. MAC-Based Approaches 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 © Robin Kravets, 2009 45

46. MAC-Based Approaches 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 © Robin Kravets, 2009 46

47. B-MAC © Robin Kravets, 2009 47 PREAMBLE A B C D E DATA t1: Flow 1 data arrival DIFS wait t2: Flow 2 data arrival DATA Channel Polling Interval t3 Flow1 data Flow2 data PREAMBLE

48. 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 © Robin Kravets, 2009 48