Real-time Power-Aware Routing in Wireless Sensor

Networks(RPAR)

Octav ChiparaOctav Chipara, Zhimin He, Guoliang Xing, Qin Chen, Xiaorui Wang, Chenyang Lu, John Stankovic, Tarek Abdelzaher

Washington University in St. LouisUniversity of VirginiaUniversity of Illinois at Urbana-Champaign

2

Mission critical applications for WSNs

Seismic structure response

Must operate for moths to years on battery power Must deliver information tight deadline constraints

E.g. a firefighter must remain aware of fire conditions

Intruder detection Fighting wildfires

3

Challenges for routing protocols Unreliable communication

Probabilistic and asymmetric links Time-variable link quality

Limited energy budget Limited processing power and memory

E.g. MICA2 has

• MCU (8Mhz, 8bit)• Memory (Data 4KB, Program 128Kb)

4

Design goals Minimize energy consumption subject to Minimize energy consumption subject to

deadline constraintsdeadline constraints Adaptive to packet deadlines Handles unreliable links Small overhead

5

Outline Velocity requirements Impact of transmission power on velocity The Real-time Power-Aware Routing (RPAR)

protocol

6

Outline Velocity requirements Impact of transmission power on velocity The Real-time Power-Aware Routing (RPAR)

protocol

7

The velocity requirement of a packet:

Transformed the end-to-end delay requirement into a velocity requirement that may be enforced locally

Adapt to based on the progress of the packet

)()(),(

ABDelaySAelayDeadline-D

BDDBvreq

Velocity requirement

BAS D

Deadline

SDDSvreq ),(

)(),(

SAelayDeadline-D

ADDAvreq

8

Outline Velocity requirements Impact of transmission power on velocity The Real-time Power-Aware Routing (RPAR)

protocol

9

Empirical setup Used XSM motes (similar to MICA2) BMAC as MAC layer

Simple CSMA/CA without RTS/CTS Implemented ARQ

Varied: One-hop distance Transmission power

Observed: Delivery velocity

1 2 3 4 54pkt/s

10

Empirical results Increasing the one-hop distance has a positive

impact up to a point A higher transmission power results in higher velocity

11

Outline Velocity requirements Meeting velocity requirements via power control A Real-time Power-Aware Routing (RPAR)

protocol

12

RPAR ““Find the most energy efficient forwarding Find the most energy efficient forwarding

choice choice

(N, p) that meets the delay requirement”(N, p) that meets the delay requirement”

Node Power Level Est. Delay

A 0dbm 0.25s

A 5dbm 0.15s

B -4dbm 0.35s

Neighborhood Manager

Delay EstimatorForwarding Policy

13

Forwarding policy Determine the velocity requirement The velocity provided by A selecting (N,p) as

forwarding choice:

Estimated energy consumption

)(,)),(,,(

N,p)delay(A

NDAD

delay

progresspNDAvprovided

NDAD

ADpNARpEpNDAE

)),(,()()),(,,(

(N,p)

Energy consumed for one transmissionEnergy cost of forwarding a

packet to NEnergy cost of routing a packet to D

14

Delay estimator Goals:

Reduce storage cost Estimate of the expected worst-case delay of (N,p)

One-hop delay:

To minimize the storage cost split the estimator To estimate the worst-case delay we account for

the variation in contention and number of retransmissions

)),(,())(()),(,( pNSRdelaySdelaypNADelay trancont

15

Neighborhood management Goal:

Discover new neighbors that meet the velocity requirements quickly

Challenges: Limited storage – cannot keep stats for all possible

neighbors Probabilistic links – neighbors that have poor links may

be included Link quality changes over time – stats accurate for

only the frequently used neighbors

16

Node Power Level Retries

N 0dbm

N 5dbm

M -4dbm

Cont.

0.5s

0.5s

2

1

1.5

1

0.5s

0.5sM 1dbm

V=13.2m/s

V=6.6m/s

V=12.5m/s

V=18.8m/s

M 0dbm 1 0.5s V=18.8m/s

Power adaptationTunes the power to an existing neighbor: If the velocity requirement is not satisfied

increase the power to a promising neighbor E.g., When routing Vreq = 15m/s increase power to M

If the velocity requirement is satisfied decrease the power to improve energy efficiency E.g., When routing Vreq = 15m/s decrease power to M

Prog(N)=7m

Prog(M)=10m

17

Neighborhood discovery Goal: Find new neighbors when power adaptation

fails Approach:

Broadcast a request to route (RTR) Nodes receiving the RTR randomize their replies in a

window

Not all nodes should reply: Neighbors that reply may not meet the delay

requirement Prolonged time until a forwarding choice that meets the

delay requirement is found

Need to concentrate only on potentially “good neighbors”

18

Identifying the “good” neighbors Is it already in the table? Is the maximum velocity it provides higher than

the required velocity? E.g. Assuming link quality of 1, when routing Vreq =

20m/s we need a progress of more than 11m

M

N

O

K

A DProg(N)=7m

Prog(M)=10m

Prog(K)=11m

Prog(O)=12m

Node Power Level Retries

N 0dbm

N 5dbm

M -4dbm

Cont.

0.5s

0.5s

2

1

1.5

1

0.5s

0.5sM 1dbm

V=13.2m/s

V=6.6m/s

V=12.5m/s

V=18.8m/s

M 0dbm 1 0.5s V=18.8m/s

O 0dbm 1 0.5s V=20.7m/s

19

Experimental setup Prowler simulator with settings similar to MICA2

Bandwidth 40Kbps 31 power levels [-10dbm, 20 dbm], current

consumption [3.7mA, 21.5 mA]

Implemented the USC probabilistic link model Many-to-one traffic pattern Topology of 150mx150m, a node per grid of size

11.5mx11.5m Packets are generated according to an

exponential distribution whose mean is varied

M. Zuniga and B. Krishnamachari, “Analyzing the transitional region in low power wireless links,” in SECON ’04

20

Experimental setup (2) Baselines:

MaxV – select the forwarding choice with max. velocity MinE – select the most energy efficient forwarding

choice Two versions: high power and default power Beacon-based neighborhood management

Metrics: Miss ratio – the fraction of packets missing their

deadline Energy per packet – total energy per delivered packet

21

Miss ratio results MinEL – achieves low delivery velocity, resulting in high miss ratio MaxVH – achieves high delivery velocity, resulting in low miss

ratio RPAR

Comparable performance to MaxVH Neighborhood management has limited effect on best-case

performance

22

Energy consumption results MinEL is more energy efficient than MaxVH

RPAR is the most energy efficient When routing packets with lax deadlines lower power is used More energy efficient neighborhood discovery

23

Related work Providing QoS

Manipulate MAC parameters (e.g., 802.11e, [H. Zhu et. al. ’04]) Admission and rate control (e.g., SWAN [G.-S. Ahn et. al. ’02]) Routing (e.g., CEDAR [P. Sinha et. al 99], [Y. Yang and R. Kravets

04]) Power-aware routing

A vast body of work Not concerned with meeting deadlines

Closer related to RPAR SPEED [T. He et. al.’03] - delivers packets at a single uniform

speed MM-SPEED [E. Felemban et. al. ‘05] – has multiple speed and

reliability domains LAPC [M. R. Fouad et. al. ’05] – uses power control but reduces

the end-to-end delays in a best-effort manner

24

Conclusions Power control is an effective actuator for

meeting end-to-end delays RPAR is a novel power-aware routing protocol

that meets end-to-end deadlines at low energy cost Reduces the miss ratio Adapts to the deadline requirement Has low overhead Handles probabilistic links

25

Questions?