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

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

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

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

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

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

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

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 }

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 3 A A

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?

Coordinator Contention Try to be a coordinator at the same time Initial configuration All the nodes are eligible Boo Announcement Contention

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

A question about utility A Why do we need the denominator? Normalize the Utility … Is it necessary?

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

Problem with Chance of delay1 > delay4? Trial num Count of delay1 > delay Percent %18.824%18.570%18.712%18.552% 100,000 delay1 and delay2 generated in the simulation More than four out of five times, node 1 has priority over node 4!

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

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

The new formula A

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

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 Putting everything together

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

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

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

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)

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

One scenario in simulation

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

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)

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

ATIM Window XMit ATIM Rcv ACK Rcv ATIM XMit ACK 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

Power Saving Mode

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

Improvement over (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

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

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

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

Energy Saving 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.

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

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

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

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

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

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

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 Power saving mode 3 5 A 4 2 B CD 1

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