Application-Based Collision
Avoidance in Wireless
Sensor Networks
Thanos Stathopoulos, Rahul Kapur, Deborah
Estrin, John Heidemann, Lixia Zhang
Presented by Paul Ruggieri
1
Summary
The Problem:

Energy usage in wireless sensor networks needs to be
minimized
The Idea:

Collisions cause retransmissions and increased latency, both
resulting in wasted energy due to radio use
The How:

Application-based collision avoidance (help the MAC layer)
TCP-like collision avoidance
Phase-offset Collision avoidance
The Claim:



Reduce collision-sourced retransmissions by a factor of 8
Reduce energy consumption by up to 50%
(What is the effect on throughput and delay?)
2
Setting
Wireless Sensor Networks



Collection of small, low-power nodes
Collect information about the world around
them
Expected to operate unmanned for extended
period of time
3
MOAP
Multihop Over-the-Air Programming






Target solution to this particular application
Code distribution mechanism
Code injected at one source, broadcast to all
sensors in network
Code transmitted neighborhood-byneighborhood
Publish-subscribe mechanism
Better than simply flooding the network
4
Wireless MAC Layer
Transfer data across the wireless medium


Shared wireless medium is lossy and unreliable
Not all nodes using the medium can be sensed by
any one node
Losses due to Collisions and link-loss dealt with
here

CSMA/CA
Hidden Terminal Problem



Source believes it can send
Background sources, out of range to source but in
range of receiver, concurrently transmit
Collision at the receiver
5
MAC Hidden Terminal Solutions
TDMA



Token-ring-like
Centralized algorithm that splits up channel usage
among nodes
Inefficient, unless many/all nodes very busy
RTS/CTS



Ready-to-send, clear-to-send frames “claim” medium
for a node
Only works for point-to-point (our app is broadcast)
Assumes symmetric links (doesn’t work for us)
6
Our approach
Tailor the solution to the problem
Augment collision avoidance done at the MAC
layer with application support
Take advantage of Multi-packet Transmissions

Tell the receiver when we are expecting to send the
next packet
Trade generality for efficiency

(Valid in this context in hopes to prolong battery life)
7
MOAP application
Time partitioned into epochs
Each source can send one packet per epoch
Epochs large compared to packet send time

We “hope” to avoid collisions
Epoch duration affects latency

(Wasted idle time)
Epoch duration based on network size


Not adaptive
Design an adaptive solution to reduce latency and
react to collisions
8
Source/Receiver-based Collision
Avoidance
Source-Based Collision Avoidance


Source infers a collision
Example: TCP
Receiver-based Collision Avoidance



Receiver notifies source of a collision
How do we know that a collision occurred?
Example: XCP
9
Failed Wireless Transmissions
Collisions


Caused by two or more nodes trying to use the
medium at once, results in useless data
This can be avoided!
Link-loss

Caused by many factors (Poor signal strength)
Reflections
Radio Orientation
Fading

This can’t be avoided.
This is outside our control, we should not take any actions
on this type of loss at application level (nature of the beast)
(MAC does this for us? 802.11 levels?)
10
Uninformed TCP-like Collision
Avoidance
Source-based collision avoidance
Source adjusts it’s sending rate on collision




AIMD
Reacts to both collisions and link-loss
Expected to be influenced by link quality
(Included to show how poor this is)
(Support argument that we need to differentiate collisions
and link-loss)

(Very TCP-like)
(React to collisions instead of congestion)
(Rate-based, not window-based)
11
Informed TCP-like Collision
Avoidance
Receiver-based collision avoidance
Receiver must distinguish between
collisions and link-loss

(How do we differentiate the two?)
Source adjusts it’s sending rate when the
receiver tells it a collision occurred


AIMD
(Only similar to TCP in that it is AIMD)
12
Phase-offset collision avoidance
Receiver-based collision avoidance
Assume: all active sources transmit once per
interval

(Again, tailor solution to the problem)
Receiver monitors for large “silent periods”

(Idle time)
When a collision is detected, send the source
this information
The source then adjusts itself to transmit during
this “silent period”
13
Receiver-Based Functionality
Need to do some work for our receiverbased solutions
Collision detection
Estimate transmission time variation

(Will this work if we have mobile sensors?)
Calculate largest silent period
14
Collision Detection
Corrupted packet does not mean a collision
occurred



Corruption can be result of link-loss
Corruption can result in total packet loss
Corruption can only destroy the portion telling us who
sent the packet
(We need this to notify the node)
Solution:


Determine when we will send our next packet before
we send our current packet
Include this expected next delivery time in the current
packet so the receiver knows when to expect the next
packet
15
Collision Detection
Receiver can construct arrival timeline
Time of arrival is not deterministic

Transmission Interval
(When to expect the packet to arrive)

Variance
Helps account for MAC layer backoff
These determine a range over which the
receiver can expect to hear from the
sender
16
Collision Detection
17
Collision Detection
Collision is inferred if by the end of the
expected arrival interval:



No data packet from the primary source has
arrived
The arrival timeline showed an overlap
between the primary source’s arrival time and
a background source’s arrival time
At least one corrupted packet was received
18
Collision Detection Issues
Best-effort estimation of collisions
False-positive: A collision could be predicted, but
have actually be lost due to link-loss
False-negative: If no packets are received when
two sources overlap, we can’t tell if this is due to
link-loss or a collision.

(Classified as link-loss, but could have been a
collision)
Upon packet losses, we loose control data
stored in that packet about future packet arrivals

Future packets maybe incorrectly marked as link-loss
19
Transmission Time
Accounts for propagation delay and MAC
backoff


For this application, assume propagation delay is
negligible as motes have weak radios
(Is this really a valid assumption?)
Source calculates variance

Same as RTO in TCP
Receiver waits until T + 4v to hear from the
source

Guardband (Why 4v?)
20
Transmission Time
21
Largest Silent Period
Assume: link utilization is low
Can avoid collisions by shifting transmission
times

Maintain our transmission rate
Receiver monitors time interval for longest idle
period


Informs source of this
(Keep a stack of idle periods incase of multiple
collisions?)
(How do we determine an epoch?)

(Explicitly set in MOAP?)
22
Phase Shift
23
Implementation - General
Implemented in TinyOS
Packets expanded to include Transmission
time (T) and Variance (v)
Receiver



Use bitmap to store packets received
Set timer to detect packet loss based on T
and v
Send NACK upon timer
24
Implementation – Uninformed TCP
ITO set to 500ms
AIMD

a = 10
Multiplicative decrease uses random float
on range 1.5-1.9

Attempt to avoid global synchronization
Decrease on all NACKs
(Reasoning for constants?)
25
Implementation – Informed TCP
ITO set to 500 ms
Only decrease sending rate on NACK
which indicates a loss due to collision
Collision flag included in NACK
26
Implementation – Phase-Offset
NACK includes time offset

(Only for NACKs indicating a collision?)
Source “sleeps” duration of time offset
then resumes normal operation
27
Evaluation
Simulation
EmStar framework used
Simulation based on a real network
First run – two sources, one receiver
Second run - multiple sources, one receiver
Results averaged over 10 runs
Sources send 200 packets
All packets are 150 bytes
28
Two Sources, One Receiver
Three nodes arranged in a line



Primary source, Receiver, Background source
Link quality of ~80% source/receiver pairs
Link quality of ~50% between sources
Primary source transmits every 500 ms
TCP-like cases

Background source transmits at constant rate
randomly chosen between 500-2500 ms
29
Two Sources, One Receiver
Phase-rand:

Background source transmits every 500-2500 ms as
with TCP-like
Phase-single:


Background source transmits on the same period as
Primary source (500 ms)
Largest silent period should change less
Base:


Each source sent as fast as possible
Quickest completion time, most retransmissions
Graphs are that of the primary source
30
Two Sources, One Receiver
31
Two Sources, One Receiver
32
Two Sources, One Receiver
33
Two Sources, One Receiver
Base case results in quickest completion


But also greatest amount of retransmissions
Collision avoidance schemes reduced retransmission
by a factor of 8
Uninformed TCP backed off so much that the
background source finished very quickly
Additional energy calculated based on ideal
case and constant transmission times
Phase-offset and informed TCP reduce our
energy overhead by almost 50% over base case


(At some cost to completion time)
(Preferable for this application)
34
Multiple Sources, One Receiver
Drop uninformed-TCP
Keep placement of previous three nodes

Add 2, 4, and 6 nodes randomly within a
10x10 meter square
Phase-offset: All sources transmit on 800
ms intervals

Theoretically accommodate up to seven nonoverlapping sources
35
Multiple Sources, One Receiver
36
Multiple Sources, One Receiver
37
Multiple Sources, One Receiver
38
Multiple Sources, One Receiver
Phase-single performs the best followed
by informed-TCP
Phase-rand performs poorly
Phase seems bad when all sources do not
transmit on equivalent intervals
In this case informed-TCP is the way to go
39
Conclusions
Take advantage of multi-packet communication
Customize our solutions to the specific problem
Methods proved to generate significant energy
savings when certain assumptions can be made
If we know we have a maximum amount of
concurrent sources who transmit on the same
intervals -> phase-offset is a great supplement
to the MAC layer
Informed-TCP is a great supplement when we
can’t fix the transmission periods of all sources
40
Comments
(Why only do this for MOAP, why not also for
sensor data collection?)

(This should also be very periodic traffic as MOAP is)
(Phase is best choice when applicable)


(Phase maintains nodes sending rates, which is what
the nodes want)
(Nodes have no desire to send faster or slower)
(Good useful work)


(Authors made some valid assumptions given the
environment and generated useful results, good
energy savings at a small latency cost)
(Some choices could have been discussed more)
41
Future Work
Multiple sources, multiple receivers
Running real experiments
Explore more solutions

Possibly a combination of informed-TCP and
Phase-offset which works in a more general
case
42
Acknowledgements
All figures taken from the original paper
43