Date post: | 31-Dec-2015 |
Category: |
Documents |
Upload: | magdalen-james |
View: | 213 times |
Download: | 0 times |
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
Slide 3/24SeNDOR Lab
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, …
Slide 4/24SeNDOR Lab
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?
Slide 5/24SeNDOR Lab
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
Slide 6/24SeNDOR Lab
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
Slide 7/24SeNDOR Lab
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
Network Layer (GenericComm)
Application
Slide 8/24SeNDOR Lab
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
Slide 9/24SeNDOR Lab
SeNDORComm
SeNDORComm Operation - Send
Sender Receiver
05 2
ReceiveQ(FIFO)
Network Layer (GenericComm)
SeNDORComm
SendQ (Heap)SendQ (not shown)
052
52
5
05 2
Slide 10/24SeNDOR Lab
Network Layer (GenericComm)
SeNDORComm SeNDORComm
SeNDORComm Operation - Receive
Sender Receiver
05 2
ReceiveQ(FIFO)
SendQ (Heap)SendQ (not shown)
0 52
Slide 11/24SeNDOR Lab
SeNDORComm
SeNDORComm Operation - Timer Fired
Sender Receiver
05 2
ReceiveQ(FIFO)
Network Layer (GenericComm)
SeNDORComm
SendQ (Heap)SendQ (not shown)
352
52
5
Timer3
25 3
Explicit Packet
Slide 12/24SeNDOR Lab
Network Layer (GenericComm)
SeNDORComm SeNDORComm
SeNDORComm Operation - Timer Fired
Sender Receiver
25 3
ReceiveQ(FIFO)
SendQ (Heap)SendQ (not shown)
2 53
Slide 13/24SeNDOR Lab
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 )
Slide 14/24SeNDOR Lab
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
SeNDORCommGenericComm
Slide 15/24SeNDOR Lab
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
Slide 16/24SeNDOR Lab
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.
Slide 17/24SeNDOR Lab
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
SeNDORCommGenericComm
2
6
10
14
1:0.5 1:5 1:20
Network Load(a)
Goo
dput
(byt
es/n
ode/
roun
d)
SeNDORCommGenericComm
60
80
100
1:0.5 1:5 1:20Network Load
(c)
Rel
iabi
lity
ofIm
med
iate
Mes
sage
s
SeNDORCommGenericComm
60
80
100
1:0.5 1:5 1:20Network Load
(d)
Rel
iabi
lity
of D
efer
red
Mes
sage
s
SeNDORCommGenericComm
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
Slide 18/24SeNDOR Lab
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
SeNDORCommGenericComm
1
3
5
1:1 1:10 1:20Network Load
(a)
Goo
dput
(byt
es/n
ode/
roun
d)
SeNDORCommGenericComm
0
25
50
75
100
1:1 1:10 1:20
Network Load(d)
Rel
iabi
lity
of D
efer
red
Mes
sage
s
SeNDORCommGenericComm
0
25
50
75
100
1:1 1:10 1:20
Network Load(c)
Rel
iabi
lity
ofIm
med
iate
Mes
sage
s
SeNDORCommGenericComm
Slide 19/24SeNDOR Lab
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
Slide 20/24SeNDOR Lab
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
Slide 21/24SeNDOR Lab
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
Slide 22/24SeNDOR Lab
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
Slide 23/24SeNDOR Lab
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