by zhimin he oct 1st,2003 computer science department university of virginia
DESCRIPTION
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. Novelty and contribution. Bases the selection of coordinators on nodes ’ utility - PowerPoint PPT PresentationTRANSCRIPT
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