Work partially supported by: National Science Foundation SeNDORComm: An Energy Efficient Priority-Driven Communication Layer for Wireless Sensor Networks

Work partially supported by:National Science Foundation

SeNDORComm: An Energy Efficient Priority-Driven

Communication Layer for Wireless Sensor Networks

Vinaitheerthan Sundaram, Saurabh Bagchi, Yung-Hsiang Lu, Zhiyuan Li

SeNDOR – Sensor Networks: Detect, Optimize and Repair

Purdue University

Slide 2/24SeNDOR Lab

Outline

Problem Definition Our approach – SeNDORComm SeNDORComm’s Design and Operation Evaluation: Experimental, Simulation, and

Analytical Analysis: Code and memory size Related Work Summary of Our Contribution


Problem Definition

Wireless Sensor Networks (WSN) Two AA batteries => Energy conservation is critical Bandwidth (Mica2 = 19.2Kbps) is very limited RAM ( 4k to 10k) is precious

Energy required for communication is much higher than that required for computation

Therefore, reducing communication can improve energy efficiency as well as network utilization

Combining messages is an appealing idea to reduce communication traffic. However, …


Problem Definition

Messages in WSNs have priority. Examples: Debugging Framework - Data messages vs. Debug messages Surveillance Applications - Intruding motor vehicle vs. pedestrian Indoor Climate Control - Harmful gas presence vs. CO2 reading

Moreover, in wireless environments, increase in packet size increases the chances of packet getting corrupted.

Questions: How to combine messages that have priority? What is the trade-off between reliability and energy

efficiency? What layer in the radio stack should provide this

functionality?


Our approach - SeNDORComm Terminology

Message priorities: 1 byte priority or 0(highest) – 255(lowest) Immediate messages are the messages with the highest

priority Deferred messages are messages that are not immediate Packets are messages in the network layer and below

Design Goals Reduce deferred message traffic to conserve energy Send critical/immediate messages promptly Keep the interface modular and close to default

communication layer in the system, eg. GenericComm in TinyOS


Our approach - SeNDORComm Key Observations

Predominant traffic pattern in WSNs is from motes to the base station

Bursty traffic exists in WSNs Every WSN is designed to send immediate messages Multiple application components can use the priority-driven

communication layer SeNDORComm - a priority driven communication layer that

satisfies the stated design goals At the heart of SeNDORComm is the policy for deciding

“when to send a message” Immediate messages are sent without buffering Deferred messages are buffered in a priority queue (Q). Later, they

are sent out along with immediate messages or as an explicit packet in priority order


SeNDORComm – Where does it fit in the radio stack?

SeNDORComm is between application and network layer Example: TinyOS Applications Radio Stack

Why separate communication layer? Useful for many application components Preserves the end-to-end nature of priority Avoids repacking at each intermediate node Can work with any network layer

Messages

Application

Packets

Packets

SeNDORComm

Network Layer (GenericComm)

MAC LayerPackets

Messages

MAC Layer


Application


Interface and Implementation

Similar to GenericComm interface, but Send function takes an additional parameter: urgency or

priority value Application provides a small queue to store multiple

messages received in a packet.

Priority queue is implemented as a heap of pointers. Internal memory management Only one memory copy per heap update Each heap element has 4 additional bytes


SeNDORComm

SeNDORComm Operation - Send

Sender Receiver

05 2

ReceiveQ(FIFO)


SeNDORComm

SendQ (Heap)SendQ (not shown)

052

52

5

05 2



SeNDORComm SeNDORComm

SeNDORComm Operation - Receive

Sender Receiver

05 2

ReceiveQ(FIFO)


0 52


SeNDORComm

SeNDORComm Operation - Timer Fired

Sender Receiver

05 2

ReceiveQ(FIFO)


SeNDORComm


352

52

5

Timer3

25 3

Explicit Packet



SeNDORComm SeNDORComm

SeNDORComm Operation - Timer Fired

Sender Receiver

25 3

ReceiveQ(FIFO)


2 53


Experimental Evaluation

Goal: To quantify energy efficiency and improvement in

message reliability To show the capability to handle bursty traffic

We implemented SeNDORComm in NesC Experiment 1: Energy Expenditure under

Interference Experiment 2: Improvement in Network Utilization

A real-world case study using LEACH ( a clustering protocol ) and HSEND (a debugging framework )


Experiment 1: Energy Expenditure under Interference No Interference

Two Mica2 motes, a sender and receiver, are kept at 5 meters apart and at 1 meter height The sender mote sends 200 messages to the receiver mote The ratio of immediate is to deferred is set to 1:3 A simple retransmission scheme of trying each failed message three times. Results: Energy improvement and comparable reliability

With Interference Interfering nodes send packets at the highest data rate possible Results: Improvement in energy efficiency and in reliability

10.05

3.6

6.65

43.47%

44.2%

59.3%

0

4

8

12

16

0 3 5Number of Interfereing Nodes

(a)

En

erg

y P

er

Us

efu

lB

yte

Re

ce

ive

d (

mJ

) SeNDORCommGenericComm

13.3%

-2.4%

-0.33%

60%

80%

100%

0 3 5

Number of Interfering Nodes(b)

% Im

me

dia

te M

es

sa

ge

sR

ec

eiv

ed

Co

rre

ctl

y

SeNDORCommGenericComm

7.3%

-0.22%

21.3%

60%

80%

100%

0 3 5Number of Interfering Nodes

(c)

% D

efe

rre

d M

es

sa

ge

sre

ce

ive

d c

orr

ec

tly



Experiment 2: Network Utilization Real-world case study: A CO2 monitoring application using LEACH and

HSEND LEACH [Heinzelman IEEE Trans. Wireless Comm. 2002] - Clustering

protocol Nodes organize themselves into clusters, with one node in each cluster

acting as the cluster head for one round. Each round has

• election timeslots - used to elect a cluster head• data timeslots - used to send data to the cluster head.

In election timeslots, the self-elected cluster heads advertise their status. Nodes that are not cluster heads choose one of the cluster heads to join based on received signal strength.

HSeND [Herbert IEEE SUTC 2006] – Invariant based Error Detection Framework Sends alert messages to base station when error is detected Sends information messages to clusterhead to detect a global invariant


Experiment 2: Setup A 21 node Mica2 motes arranged in 2x1 grid Leach parameters:

Round = 27 slots - 20 data slots and 7 election slots Each slot is 2 seconds 2 clusters - 9 nodes on average per cluster 20 rounds per experiment

H-SEND An invariant that generates an error message with priority value

3 if the rate of successful transmission of sensed data (immediate messages) at each node is below a certain threshold

We set the threshold to be slightly higher than the node’s normal sensed data rate so that on average a debug message is generated at every check.

We vary the frequency of checking the invariant to vary the load in the network.


Experiment 2: Metrics and Results

25

50

75

100

1:0.5 1:5 1:20Network Load

(b)

Tran

smis

sion

Suc

cess

Rat

io


2

6

10

14

1:0.5 1:5 1:20

Network Load(a)

Goo

dput

(byt

es/n

ode/

roun

d)


60

80

100


(c)

Rel

iabi

lity

ofIm

med

iate

Mes

sage

s


60

80

100


(d)

Rel

iabi

lity

of D

efer

red

Mes

sage

s


Metrics - Goodput - the rate of immediate messages that reaches the base station Transmission success ratio - the ratio of the number of messages received

by nodes in the network to the number of message sends attempted by nodes including retransmission

Reliability of immediate (deferred) messages - the ratio of immediate (deferred) messages received by nodes successfully to the total number of immediate (deferred) messages sent by nodes


Simulation Evaluation for large networks

Goal: To show SeNDORComm scales well to large networks

We simulated experiment 2 for a large network with 100 nodes using TOSSIM ( Tiny OS Simulator)

Results follow a similar trend as in the Experiment 2

0

20

40

60

80

100

1:1 1:10 1:20Network Load

(b)

Tran

smis

sion

Suc

cess

Rat

io


1

3

5

1:1 1:10 1:20Network Load

(a)

Goo

dput

(byt

es/n

ode/

roun

d)


0

25

50

75

100

1:1 1:10 1:20

Network Load(d)

Rel

iabi

lity

of D

efer

red

Mes

sage

s


0

25

50

75

100

1:1 1:10 1:20

Network Load(c)

Rel

iabi

lity

ofIm

med

iate

Mes

sage

s



Analytical Evaluation

Goals - Derive an upper bound on the additional traffic injected into the network Guides in choosing the threshold value for the deferred messages


Analysis – Code and Data Memory

Buffers Size - Runtime Memory Required for data structures maintained

Components Program Size

Memory Size

Buffers Size

LEACH with GenericComm and Debugging

17884 811 0

LEACH with SeNDORComm and Debugging (1 buffer priroityQ, 2 buffer receiver list )

21812 1118 138

LEACH with SeNDORComm and Debugging (10 buffer priroityQ, 4 buffer receiver list )

21812 1596 676


Related Work

Priorities: RAP [Lu RTAS 02] Uses priority to do velocity monotonic scheduling Doesn’t consider message combining

Message Combining: AIDA [ He TECS 03], BMAC [Polastre Sensys 04 ] Don’t use priority

Congestion Control: [Hull Sensys 04] [He ICDCS 05] Works at mac/network layer

These works do not consider message combining and application priorities like we do


Discussion

SeNDORComm guarantee covers passing the message to lower layer in the radio stack The guarantee doesn’t cover delivery or even successful send

attempt and it’s weak because of practical reasons such as predicting wireless channel condition and contention for channel is very hard

Any-to-any communication in the network By combining deferred messages going to the same station,

SeNDORComm can improve energy efficiency in such cases too.

Congestion can still form under very high load SeNDORComm’s admission control can stop the application sending

explicit messages to alleviate congestion


Summary

Energy conservation is critical in Wireless Sensor Networks (WSN)

Combining messages is an appealing idea Challenges

Different Priorities for messages exist in WSN Increased packet size reduces reliability in wireless environments

SeNDORComm A new communication layer that combine messages based on

priority without violating timing constraints Significant advantages over default communication layer

conserves energy, increases network utilization, handles bursty traffic, and prevents congestion

Future Work: We are working on problem diagnosis in WSN. We use SeNDORComm to send diagnostic information efficiently to the base station


Q&A

Thank you for your attention!

Documents

Work partially supported by: National Science Foundation SeNDORComm: An Energy Efficient Priority-Driven Communication Layer for Wireless Sensor Networks