Szodar – Shadow Zone and Delay Aware
Routing for Acoustic Underwater Sensor
Networks
Erdal Cayirci
Son T. Nguyen
Liang Yan
Chunming Rong
Agenda
•
•
•
•
•
•
Objective
Underwater Wireless Sensor Networks
Shadow Zone Characteristics
Szodar Algorithm
Experiment Results
Future Works
09/06/08
SWACOM Meeting
2
Objective
Design a delay aware routing
algorithm to solve the problem of
shadow zone for ad hoc
underwater acoustic networks
09/06/08
SWACOM Meeting
3
Underwater WSN
• Used for sensing, monitoring and surveillance
of underwater applications
• Can be mobile or fixed
• Can use acoustic or RF signals as comm.
medium
• Can be 2D or 3D
09/06/08
SWACOM Meeting
4
Underwater WSN - Classifications
3D UWSN
2D UWSN
( [email protected])
09/06/08
SWACOM Meeting
5
Acoustic Underwater WSN - Challenges
• Acoustic signals for UWSN
–
–
–
–
Speed: 105 times less than RF signals ⇒ large delay
Underwater signal ⇒ high attenuation
Bandwidth ⇒ limited
BER ⇒ high, due to changes in environment
• Other challenges
– Temporary loss of connectivity
– Limited battery power, hard to replace
– Failure of sensors due to other underwater
influences
09/06/08
SWACOM Meeting
6
Law of Refraction
09/06/08
SWACOM Meeting
7
Shadow Zone Characteristics
• Shadow Zone: changes in the underwater
environment, making signal transmission
disrupted
• Always presented in thermocline.
09/06/08
SWACOM Meeting
8
Szodar Algorithm
• Goal: keeping UWSN
connected when shadow
zone appears in the
sensing region
• Contains two sub
algorithms
– isConnected: to check if a
node is connected to the
sink
– getConnected: to make a
node re-connected if it
loses connection
09/06/08
SWACOM Meeting
acoustic transceiver
sensor cluster
anchor
9
Tasks Solved by Szodar Algorithm
• isConnected
 how often to run isConnected
• getConnected
 which direction to go
 what is the moving step
09/06/08
SWACOM Meeting
10
isConnected
• Checking status of a node ⇒ two approaches
– Proactive: a node checks its status every certain
period
– Reactive: a node checks its status when it has the
data to transmit
• Can use either proactive or reactive approach
to solve the problem
• Our current proposal is to use proactive
approach
09/06/08
SWACOM Meeting
11
isConnected
• Every node setups a routing table
– Routing table structure:
Uplink node ID
Delay
• Each node contains a status field, marked
Connected/notConnected.
• Node broadcasts HELLO message when need
to check its status
– Broadcast message structure:
09/06/08
SWACOM Meeting
HELLO
Node ID
12
isConnected
• Node check ID of the HELLO message and its
status
– if (status==connected) AND (the sender’s ID is not
the only one in its routing table) ⇒ node will send
back a routeReply message.
• Upon received routeReply message, the node
updates its routing table
• If the status changed, node will broadcast its
status to its neighbor nodes.
• Nodes received the status changed message
will update its routing table.
09/06/08
SWACOM Meeting
13
isConnected
• Need to calculate status check time interval σ
• Three important parameters related with the
status check time interval σ=f(d,p,q)
– d: node density (number of nodes within the node
transmission range).
– p: probability that a node in transmission range
becomes out of the transmission range after 1
second.
– q: probability that a node is connected after time .
d
ln  1−  1−q 
σ=
ln  1− p 
09/06/08
4∗n∗∗r 3
d =⌈
⌉
3∗v
SWACOM Meeting
14
getConnected
• Make a node re-connected in case it loses
connection
– Assumption: a node changes position by going up or
down
– A node know it depth by using a pressure sensor
• Challenges:
– Decide the direction to go (up or down)
– Check connection (using isConnected) while moving.
09/06/08
SWACOM Meeting
15
getConnected
• getDirection(): Go to the direction that can
maximize the chance of being connected
– If node is above the mean depth ⇒ go down,
otherwise ⇒ go up
– Applied for uniform distribution along vertical axis
Average depth
09/06/08
SWACOM Meeting
16
getConnected
• Use isConnected
• When a node moves ⇒ run isConnected
• Challenges: how often?
– finding∆
l
– Calculate and compare ∆ P with different ∆
09/06/08
SWACOM Meeting
l
17
getConnected::Scenarios
• One node loses connection
– a.k.a nodes work independently
– Run algorithms as described
• Two nodes lose connections
– Do these two nodes solve their problems
independently?
– Is there any cooperative method?
• Network partitioning
– Group of nodes is connected but no connections
among groups
– Do all nodes in each group move to seek new
connections?
09/06/08
SWACOM Meeting
18
getConnected
• Objective:
– Minimizing node's energy consumption to re-connect
– Finding the appropriate moving step
l
ΔP =⌈
⌉∗ Pm∗ l Pc− Pm∗l  Pc
l
l: travelled distance to get out of the shadow zone
(0<l<h), where h is the depth of the shadow zone
l: moving step = moving distance before running
isConnected
Pm: moving power per distance unit
Pc: power consumption per checking
09/06/08
SWACOM Meeting
19
Experiment Results - P
Results are coming
09/06/08
SWACOM Meeting
20
Experiment Results - l
09/06/08
SWACOM Meeting
21
Experiment Results - 
p = 0.2
12
δ : recheck time interval(s)
δ : recheck time interval(s)
40
30
20
10
0
20
10
8
6
4
2
0
20
15
10
d: node density
5
0
0
0.2
0.4
0.6
15
1
0.8
10
5
d: node density
q:node connection probability
0
0
0.2
0.4
1
0.8
0.6
q:node connection probability
p = 0.9
p = 0.2
p = 0.5
p = 0.9
35
δ : recheck time interval(s)
4
δ : recheck time interval(s)
p = 0.5
3
2
1
30
25
20
15
10
5
0
20
0
20
15
10
d: node density
09/06/08
5
0
0
0.2
0.4
0.6
0.8
1
15
10
d: node density
q:node connection probability
SWACOM Meeting
5
0
0
0.2
0.4
0.6
0.8
1
q:node connection probability
22
Future Works
• Simulate to calculate and compare
connectivity of Szodar and other algos (e.g
directed diffusion)
• Develop solutions for different node
distribution models
• Solve isConnected using reactive approach
• Extend the work for different scenarios
09/06/08
SWACOM Meeting
23
Thank you for your attention
Discussion?
09/06/08
SWACOM Meeting
24