span: an energy-efficient coordination algorithm for topology maintenance in ad hoc wireless...

Span: An Energy-Efficient Coordination Algorithm for Topology Maintenance in Ad Hoc Wireless Networks

ACM Wireless Networks Journal, 2002BENJIE 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

Without 5 being coordinator, 3->4 contend for bandwidth with 1->2

A connected dominating set

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 pre

vents 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

Examples (1/2)

Examples (2/2)

High Complexity

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 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]

Number of neighborsRound trip time

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 updat

es 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

Only 100 node participate in Span

Motion follows random waypoint model [2]

128 bytes packets CBR flow

Capacity

Effects of mobility

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