By Zhimin He Oct 1st,2003 Computer Science Department University of Virginia

1. SPAN: An Energy-Efficient Coordination Algorithm for Topology Maintenance in Ad Hoc Wireless Networks By Zhimin He Oct 1st,2003 Computer Science Department University of Virginia

2. Novelty and contribution • Bases the selection of coordinators on nodes’ utility • Rotates the role of coordinator among nodes • Good extension to 802.11 PSM

3. Outline • Introduction • SPAN’s coordinator selection algorithm • Examples • 802.11 Power Saving Mode • SPAN’s Improvement over 802.11 PSM • Performance evaluation • Relate to Previous Papers • Summary

4. Roadmap • Introduction • SPAN’s coordinator selection algorithm • Examples • 802.11 Power Saving Mode • SPAN’s Improvement over 802.11 PSM • Performance evaluation • Relate to Previous Papers • Summary

5. Introduction • Recharging sensors is difficult • Minimizing energy consumption is essential in sensor networks • Sensor networks have high level of redundancy • A dense sensor network can work with only part of its nodes being active • It possible to prolong the network lifetime while maintain its functionality by carefully choosing the active nodes

6. Roadmap • Introduction • SPAN’s coordinator selection algorithm • Essential idea • Backoff algorithm • Problems with backoff & Possible improvement • Coordinator withdraw • Examples • 802.11 Power Saving Mode • SPAN’s Improvement over 802.11 PSM • Performance evaluation • Relate to Previous Papers • Summary

7. The Essential Ideas of SPAN • Part of the nodes become coordinators to form the network backbone, only coordinators can forward messages • Non-Coordinator nodes check periodically whether it should become a coordinator • A node with higher utility and energy level is more likely become a coordinator • A coordinator checks periodically whether it should become a non-coordinator • A coordinator may withdraw if it is redundant or it can find a replacement • Nodes makes announcements when it’s role changes

8. How span works OnWakeUp() { if(! all neighbors can reach each other directly or via one or two coordinators) { backoff if( no announcements from other neighbors received during the backoff) { become coordinator sent out HELLO annoucement } else { update state table if(! all neighbors can reach each other directly or via one or two coordinators) { become coordinator sent out HELLO annoucement } } } }

9. Coordinator Eligibility Rule • If two neighbors of a non-coordinator node cannot reach each other directly or via one or two coordinators, the node should become a coordinator 1 2 1 2 3 3 4 5 4 5 6 7 6 7 8 9 A 8 9 A

10. HELLO Announcement • HELLO message contains each node’s status, its current coordinators, and its current neighbors • Each node maintains its coordinators, neighbors, coordinators of neighbors • SPAN HELLO message is piggybacked onto the broadcast updates required by geographic forwarding • Does a Nodes send separate HELLO message when it’s role changes?

11. Coordinator Contention 1 2 1 2 1 2 3 4 5 3 3 4 5 4 5 6 7 6 7 6 7 Initial configuration All the nodes are eligible Try to be a coordinator at the same time 1 2 Boo 3 4 5 Announcement Contention Boo Boo 6 7

12. Resolving announcement contention using backoff • Each node delays its announcement by a certain value • Assume all the nodes have roughly equal energy • Only topology should play a role in deciding which nodes become coordinators number of neighbors for node i number of additional pairs among the neighbors that can be connected Number of neighbor pairs A node with higher should volunteer more quickly

13. A question about utility Why do we need the denominator? 1 2 5 3 4 A 6 7 Normalize the Utility … Is it necessary?

14. Introducing randomness • Q: What if there are multiple nodes within radio range that all have the same utility? • A: Introduce randomness into the delay As the number of neighbors increases, chance of contention increase

15. Problem with 1 2 3 4 5 6 7 Chance of delay1 > delay4? 100,000 delay1 and delay2 generated in the simulation More than four out of five times, node 1 has priority over node 4!

16. Possible improvement (1) • Utility • Coordinators aim to increase number of connected neighbor pairs, not percent of connected neighbor pairs • Use instead of • Utility is no longer normalized • Use the max possible number neighbor pairs to Normalize

17. Possible improvement (2) • Time constant • The purpose of introducing is avoiding collision • Use instead of ＝Max possible number of neighbors • Coordinator election time may become longer • Election doesn’t happen too often

18. The new formula 1 2 5 3 4 A 6 7 1 2 3 4 5 6 7

19. Energy concern • Nodes with more energy should volunteer as a coordinator more quickly • The energy level is normalized using the max energy level, which is Er/Em • The simple linear 1-Er/Em worked in experiment comparing to other more complex functions

20. Putting everything together • Er : the amount of energy at a node that still remains • Em: the maximum amount of energy available at the same node • Nmax: max possible number of neighbors • Ci: number of additional pairs of nodes among these neighbor that would be connected if I were to become a coordinator. 0 <= Ci <= Ni*(Ni-1)/2 <= Nmax*(Nmax-1)/2 • T: round-trip delay for a small packet over the wireless link

21. Coordinator Withdrawal • Rules • Every pair of its neighbors can reach other either directly or via some other coordinators • Every pair of its neighbors can reach other either directly or via some other neighbors • Grace period 1 2 1 2 1 2 3 3 3 4 5 4 5 4 5 6 7 6 7 6 7

22. Roadmap • Introduction • SPAN’s coordinator selection algorithm • Examples • Ideal layout • Critical Path node • Effect of mobility • 802.11 Power Saving Mode • SPAN’s Improvement over 802.11 PSM • Performance evaluation • Relate to Previous Papers • Summary

23. Ideal layout For radio range of 250 It’s impossible to achieve the ideal layout

24. Critical Path node Critical nodes will rotates among those are nearby Nodes tends to die at the same time instead of one by one (ASCENT)

25. Effect of mobility SPAN can avoid void because the nodes near a void have less utility S S D D

26. One scenario in simulation

27. Roadmap • Introduction • SPAN’s coordinator selection algorithm • Examples • 802.11 Power Saving Mode • SPAN’s Improvement over 802.11 PSM • Performance evaluation • Relate to Previous Papers • Summary

28. 802.11 Power Saving Mode • Nodes turn off their radio receivers and wake up periodically • Nodes buffer the message received • Nodes use ATIM (ad hoc traffic indication message) to advertise whether they have packet to send • Nodes that have packets to send and receive stay awake the whole period (beacon period)

29. Target beacon • Beacons synchronize nodes clock • Use random backoffs to deal with race condition • All the nodes synchronize it’s clock to the first beacon it hears. • Assumption: all the nodes are roughly synchronized and start listening to the beacon at about the same time

30. ATIM Window • The nodes have buffered packets can send a direct ATIM frame to its intended receivers in PS mode. • The sender shall remain awake the remaining period • On reception of the ATIM frame, the receiver shall reply with an ACK and remain awake the remaining period XMit ATIM Rcv ACK Rcv ATIM XMit ACK

31. 802.11 Power Saving Mode

32. Roadmap • Introduction • SPAN’s coordinator selection algorithm • Examples • 802.11 Power Saving Mode • SPAN’s Improvement over 802.11 PSM • Less advertisement • Individually advertise each broadcast message • Use of advertised traffic window • Performance evaluation • Relate to Previous Papers • Summary

33. Improvement over 802.11(1) • No advertisement for packets between coordinators • IMPACT: less messages transmitted between coordinators and less message delay • Individually advertise each broadcast message • In unmodified version, a node only needs to send one broadcast advertisement even if it has more than one broadcast message to send • IMPACT: nodes can go to sleep as soon as it gets all the broadcast message

34. Improvement over 802.11(2) • New advertised traffic window Beacon Advertised packets & Packets to coordinators Packets to coordinators ATIM Advertised traffic window Beacon Period Beacon Period : 200ms ATIM window: 20ms AT window: 100ms IMPACT: non-coordinator nodes spent less time in active mode

35. Roadmap • Introduction • SPAN’s coordinator selection algorithm • Examples • 802.11 Power Saving Mode • SPAN’s Improvement over 802.11 PSM • Performance evaluation • Relate to Previous Papers • Summary

36. Capacity preservation • PSM drops significantly after the send rate increase past 3Kbps • Reason: • the ATIM window is not long enough to allow all buffered unicast packets to be advertised • There is not enough time until the start of the next beacon for all advertised packets to be transmitted

37. Energy Saving • 802.11 provides little energy saving • Nodes have to say awake through out the whole beacon period when the routing layer uses broadcast • The power saving is not linear regarding to node density • Nodes still consumes power when they are sleep • Nodes have to wake up periodically to monitor the surrounding and get messages.

38. Packet delivery rate • Three modes have the same packet delivery rate initially • 802.11 PSM and 802.11 drop significantly almost at the same time • Most of the nodes in 802.11 PSM and 802.11 die out around 350ms

39. Network Lifetime • Network lifetime gets more improvement as node density increases • Increase is non-linear • Energy saving is non-linear

40. Roadmap • Introduction • SPAN’s coordinator selection algorithm • Examples • 802.11 Power Saving Mode • SPAN’s Improvement over 802.11 PSM • Performance evaluation • Relate to Previous Papers • SPAN vs ASCENT • SPAN’s impact on routing layer protocols • Summary

41. SPAN Vs ASCENT SPAN Uses neighbor connectivity Two status: Coordinator & Non-Coordinator Coordinators rotator among nodes Limited mobility support Uses routing layer information Needs MAC and Routing Layer Modification ASCENT Uses neighbor count and loss rate Four status: Active, test, passive, sleep Transmitters stay awake No mobility support Collects local information Only affects Routing Layer

42. Impact on Routing Layer(1) • Overall • Separation of concern • Less chance of collision with fewer nodes participating in communication • Routing table needs to be refreshed periodically as nodes switch roles • More packets go through active node that might lead to packets loss due to buffer overflow or MAC layer constrain

43. Impact on Routing Layer(2) • DSDV/DSR/AODV • Routing path is bind before the packet is sent • Nodes along the routing path may go to sleep • SPEED & RAP • The calculating of velocity is inconsistent • LSRP • Routing path has to detour due to the choices of coordinator • Trajectory Based Forwarding • Not enough nodes active to follow the trajectory accurately • Mobicast • Larger forwarding zone is required

44. Characteristics of a Good Power-Saving Coordination Technique • Allow as many nodes as possible to turn their receivers off • Minimal increase of delay • Preserve network capacity • Compatible with most existing link-layer protocols. E.g 802.11 Power saving mode 1 3 A 5 B D C 2 4

45. Summary & Discussion • SPAN depends on the routing layer to get neighbor information • SPAN should notify the routing layer whenever a node switches role • Routing layer has to be modified to rout through coordinators • Rotation can maintain the network topology longer, but introduce more state switches • How to minimize the negative impact SPAN has on routing layers • Does SPAN have the all the characteristics of a good power saving technique