330 likes | 414 Views
Span: An Energy-Efficient Coordination Algorithm for Topology Maintenance in Ad Hoc Wireless Networks. ACM Wireless Networks Journal, 2002 BENJIE CHEN, KYLE JAMIESON, HARI BALAKRISHNAN and ROBERT MORRIS. Outline. Introduction Related works Span design Simulation Conclusion. Introduction.
E N D
Span: An Energy-Efficient Coordination Algorithm for Topology Maintenance in Ad Hoc Wireless Networks ACM Wireless Networks Journal, 2002 BENJIE CHEN, KYLE JAMIESON, HARI BALAKRISHNAN and ROBERT MORRIS
Outline • Introduction • Related works • Span design • Simulation • Conclusion
Introduction • Important Considerations: • 1. It should allow as many nodes as possible to turn their radio receivers off most of the time • 2. it should forward packets between any source and destination with minimally more delay than if all nodes were awake • 3. the backbone formed by the awake nodes should provide about as much total capacity as the original network • A good coordination technique should not make many assumptions about the link layer’s facilities for sleeping
A connected dominating set Without 5 being coordinator, 3->4 contend for bandwidth with 1->2
Span • Making periodic and local decisions on whether to sleep or stay awake as a coordinator • Use a delay announcement to prevent announcement contention • Use a withdrawal scheme to rotate the role of being a coordinator
Related Works (1/2) • Das and Bharghavan [6] approximate the minimum connected dominating set of an ad hoc network • Span has the additional property of being capacity preserving • Wu and Li [27] propose a distributed algorithm for approximating connected dominating sets in an ad hoc network that also appears to preserve capacity • Span, however, elects fewer coordinators because it actively prevents redundant coordinators by using randomized slotting and damping
Related Works (2/2) • The recent GAF [29] scheme of Xu et al. • Span does not require location information • Span integrates with 802.11 power saving mode nicely • In AFECA [28], A node switches between sleeping and listening, with randomized sleep times proportional to the number of nearby nodes. The net effect is that the of listening nodes is roughly constant, regardless of node number density • Span never keeps a node awake unless it is absolutely essential for connecting two of its neighbors
Span design • Span is proactive: each node periodically broadcasts HELLO messages • From these HELLO messages, each node constructs a list of the node’s neighbors and coordinators and for each neighbor, a list of its neighbors and coordinators
Data Structure HELLO: <Id>,<isCoordinator>,<list of coordinators>,<list of neighbors>,<timeStamp> Table: <13>,<True>,<27>,<3,23>,<11934> <25>,<False>,<2,23>,<3,45>,<11933> <27>,< True >,<8,12>,<10,34>,<12001> <43>,<False>,<13,56>,<3,34>,<11912>
Coordinator announcement • Coordinator eligibility rule: • A non-coordinator node should become a coordinator if it discovers, using only information gathered from local broadcast messages, that two of its neighbors cannot reach each other either directly or via one or two coordinators
Announcement contention • Announcement contention occurs when multiple nodes discover the lack of a coordinator at the same time, and all decide to become a coordinator • Span resolves contention by delaying coordinator announcements with a randomized back-off delay
Randomized back-off delay Number of neighbors Round trip time number of additional pairs of nodes among these neighbors that would be connected if i were to become a coordinator R uniformly at random from the interval (0, 1]
Coordinator withdrawal • Each coordinator periodically checks if it should withdraw as a coordinator. A node should withdraw if every pair of its neighbors can reach each other either directly or via one or two other coordinators
Example Tentative Coordinator
Parameters • A coordinator stays tentative for WT amount of time, where • the amount of time a node stays as a coordinator before turning on its tentative-bit is proportional to the amount of energy it has (Er/Em)
Simulator implementation • Span implementation uses a geographic forwarding algorithm [1] • They piggyback Span HELLO information onto the broadcast updates required by geographic forwarding • Upon receiving a packet for a node not in radio range: • find a neighbor coordinator is closest to the destination • If no such coordinator exists, find a non-coordinator that is closer to the destination • Did not resolve void like GPSR[16] • Do not use a location service • Use GOD module of ns to obtain location (hence, the result is better) • [16] GPSR: Greedy Perimeter Stateless Routing for Wireless Networks (2005 3-17 presented by cwlin)
Implemented detail (1/3) • Span election algorithm may not react fast enough to elect new coordinators • Because geographic forwarding falls back to using non-coordinators to route packets if coordinators do not exist, a non-coordinator node announces itself as a coordinator if it has received a large number of packets to route in the recent past • If this coordinator turns out to be redundant, the coordinator withdraw algorithm will force the node to withdraw itself as a coordinator soon after
Implemented detail (2/3) • When the 802.11 MAC layer is asked to send a packet, it may or may not be able to send it immediately • In Span implementation, they buffer packets for two beacon periods. Packets that have not been transmitted after two beacon periods are dropped
Implemented detail (3/3) • The beacon period and ATIM window size greatly affect routing performance [21] • They experimentally determined that a beacon period of 200 ms and an ATIM window size of 40 ms result in good throughput and low loss rate
Energy model • They took measurements of the Cabletron Roama bout 802.11 DS High Rate network interface card (NIC) operating at 2 Mbps in base station mode • And note that these closely match the results obtained by Feeney and Nilsson [7] for similar 802.11 network interface cards in the ad hoc mode
Simulation Environment • Ns-2 network simulator using CMU wireless extensions • Run on top of the 802.11 MAC layer with power saving support and some modification • 120 nodes in different size of square regions • 2 Mbps bandwidth • 250m nominal radio range • Define node density: number of nodes within a radio range (without sources or destinations)
10 Source Random Always on Never move 10 Destination Random Always on Never move 128 bytes packets CBR flow Only 100 node participate in Span Motion follows random waypoint model [2]
Conclusion • Span presents a distributed coordination technique that reduces energy consumption without significantly diminishing the capacity or connectivity of the network • Span adaptively elects coordinators from all nodes in the network, and rotates them in time