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 802.11 PSM

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

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

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 802.11 Power Saving Mode SPAN’s Improvement over 802.11 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 worksOnWakeUp() {

if(! all neighbors can reach each other directly or via one or two coordinators) {

backoffif( no announcements from other neighbors received during the b

ackoff) {become coordinatorsent out HELLO annoucement

} else {update state tableif(! all neighbors can reach each other directly or via one

or two coordinators) {become coordinatorsent 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

5

6 7

8 9

2

4

1

3

A

5

6 7

8 9

2

4

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 Contention1

3 5

6 7

2

4

1

3 5

6 7

2

4

Try to be a coordinator at the same time

Initial configuration

1

3 5

6 7

2

4

All the nodes are eligible

1

3 5

6 7

2

4

Boo

BooBoo 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

)2

( iii

NCUtility

number of neighbors for node inumber of additional pairs among the neighbors that can be connectedNumber of neighbor pairs

iN

iC

A node with higher 　　 should volunteer more quickly 　 iC

)2

( iN

TN

Cdelay iii *))

2(1(

A question about utility)

2( i

ii

NCUtility

0.11/1 AUtility

67.015/10

15/)12/)6*3((4

Utility

1

35

6 7

2

4

A

Why do we need the denominator?

Normalize the Utility …

Is it necessary?

?!4 AUtilityUtility

TN

Cdelay iii *))

2(1(

Introducing randomness Q: What if there are multiple nodes within

radio range that all have the same utility? A: Introduce randomness into the delay

?)))

2(

1(( RNCi

delayi

TN i ?As the number of neighbors increases, chance of contention increase

Problem with TN i 1

3 5

6 7

2

4

TR

TRdelay

)32(

3))3/11((

1

11

TR

TRdelay

)64.2(

6))15/91((

2

24

Chance of delay1 > delay4?Trial num 1 2 3 4 5

Count of delay1 > delay 4 18746 18824 18570 18712 18552

Percent 18.746% 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!

TNRNCi

delay ii

)))

2(

1((

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

iC )2

/( iNCi

)2

/( maxNCi

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

TNmax

TN i

TNmax

TN i

The new formula

TNRPCdelay i maxmax ))/1((

max/ PCUtility i

max7,6,5,3,2,1 /1 PUtilitly 1

35

6 7

2

4

A

1

3 5

6 7

2

4

max4 /10 PUtility max/1 PUtilityA

TNRPdelay maxmax7,6,5,3,2,1 ))/11((

TNRPdelay maxmax4 ))/91((

)2

( maxmax

NP

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 sam

e node Nmax: max possible number of neighbors Ci: number of additional pairs of nodes among these neig

hbor 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

TNRNC

E

EDelay i

m

r maxmax

)))

2(

1()1((

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

1

3 5

6 7

2

4

1

3 5

6 7

2

4

1

3 5

6 7

2

4

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

Ideal layout

hexagonideal S

dC

2

2

162380hexagonS

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

DS

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 802.11 Power Saving Mode SPAN’s Improvement over 802.11 PSM Performance evaluation Relate to Previous Papers Summary

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)

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

802.11 Power Saving Mode

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

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

Improvement over 802.11(2)

New advertised traffic windowBeacon

ATIM

Advertised traffic window

Beacon Period

Advertised packets &Packets to coordinators

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 802.11 Power Saving Mode SPAN’s Improvement over 802.11 PSM Performance evaluation Relate to Previous Papers Summary

Capacity preservation

PSM drops significantly after the send rate increase past 3KbpsReason: 1. the ATIM window is not long enough to allow all buffered unicast

packets to be advertised2. There is not enough time until the start of the next beacon for all

advertised packets to be transmitted

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.

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

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

SPAN Vs ASCENTSPANUses neighbor connectivityTwo status: Coordinator & Non-CoordinatorCoordinators rotator among nodesLimited mobility supportUses routing layer informationNeeds MAC and Routing Layer ModificationASCENTUses neighbor count and loss rate Four status: Active, test, passive, sleepTransmitters stay awake No mobility supportCollects local informationOnly 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 coordi

nator 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 receiver

s off Minimal increase of delay Preserve network capacity Compatible with most existing link-layer protocols. E.

g 802.11 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