Computer Communications 35 (2012) 475–486
Contents lists available at SciVerse ScienceDirect
Computer Communications
journal homepage: www.elsevier.com/locate/comcom
An efficient Dynamic Addressing based routing protocol for Underwater
Wireless Sensor Networks
Muhammad Ayaz ⇑, Azween Abdullah, Ibrahima Faye, Yasir Batira
CIS Department, FAS Department, Universiti Teknologi PETRONAS, Tronoh, Perak, Malaysia
a r t i c l e
i n f o
Article history:
Received 5 December 2010
Received in revised form 9 November 2011
Accepted 17 November 2011
Available online 26 November 2011
Keywords:
Dynamic Addressing
Courier nodes
S-HopID
C-HopID
Underwater Sensor Networks (USNs)
a b s t r a c t
Underwater Wireless Sensor Networks (UWSNs) are different in many aspects as compared to terrestrial
sensor networks. Other than long propagation delays and high error probability, continuous node movement makes it hard to manage the location information of sensor nodes. Determining the location of
every node is a major issue as nodes can move continuously with the water currents. In order to handle
the problem of large propagation delays and unreliable link quality, many algorithms have been proposed
and some of them provide good solutions for these issues, but continuous node movements still need
attention. In order to handle the problem of node mobility, we proposed a Hop-by-Hop Dynamic Addressing Based (H2-DAB) routing protocol, where every node in the network will be assigned a routable
address in a quick and efficient way without requiring an explicit configuration or any dimensional location information. It helps to provide an option where nodes can communicate without any centralized
infrastructure, also a mechanism is available where nodes can come and leave the network without having any serious effect on the rest of the network. Simulation results show that H2-DAB can manage easily
during the quick routing changes where node movements are very frequent yet require little or no overhead in order to complete its tasks.
Ó 2011 Elsevier B.V. All rights reserved.
1. Introduction
A scalable Underwater Wireless Sensor Network (UWSN) provides a promising solution for discovering the aqueous environment efficiently and observing such locations for different
applications which operates under many important constraints.
On one hand, these environments are not feasible for human presence as unpredictable underwater activities, high water pressure
and vast areas of water are major reasons for un-manned exploration [1,2]. At the same time, localized exploration is better than remote for getting more precise results, as remote sensing
technologies may not be able to find appropriate knowledge about
the events that happen in unstable underwater environment.
In fact, UWSNs share many properties with terrestrial sensor
networks such as the large number of nodes and energy issues, still
these are different in many aspects from the terrestrial sensor
technology. Firstly, radio communications are not suitable for deep
water, so we have to replace this with the acoustic communications. Due to this replacement, available propagation speed is
shifted from the speed of light to the speed of sound. Although,
acoustic sound travels faster (four times) and longer in water than
in air but yet five order of magnitude slower than electromagnetic
⇑ Corresponding author. Tel.: +60125585903.
E-mail address: ayazsharif@hotmail.com (M. Ayaz).
0140-3664/$ - see front matter Ó 2011 Elsevier B.V. All rights reserved.
doi:10.1016/j.comcom.2011.11.014
waves. Secondly, most of the times, sensor nodes are considered as
static but underwater sensor nodes can move up to 1–3 m/sec due
to different underwater activities [3]. Thirdly, consumption of energy is different for both types of networks, as underwater nodes
are larger in size so they consume more power and the replacement of the nodes or even batteries is not so easy. Low data rates
due to limited bandwidths are also a major problem for such type
of networks. The routing protocols that require higher bandwidths,
results in large end-to-end delays and are not suitable for these
environments. Although UWSN communications are divided into
different categories in terms of bandwidth and ranges, acoustic signals can work even for 5 km, but data rates at such ranges are very
small and not suitable for real time communications. In short, it is
hard to increase the data rate from 40 kb/s with a range of 1 km.
2. Related work
It is a challenging task to find and maintain the routes for dynamic underwater environments with energy constraint and sudden topology changes due to some node failures. For these
circumstances, recently many routing schemes have been proposed for UWSNs and among these, most of them require or assume special network setups and generally can be divided in two
categories [4]. First, those required special network setups and extra hardware like [5–11]. All these protocols require extraordinary
476
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
hardware setup and multiple types of nodes like sensor nodes are
equipped with pressure or depth sensor, many nodes are anchored
at different depths in throughout the observing area and etc.
Arrangements like these are not easily possible for long term applications; in addition when we are interested in large areas then cost
become a major issue. Second category is of geographical based
routing schemes, those require full dimensional location information of the network. For the sake of simplicity, most of the protocols of this type assume that every node in the network already
knows its own location and location of final destination. Assumptions like these are not so simple because in order to get the localization information in UWSNs, we need some extra location aware
method, which is another research issue left to be solved. Some
important schemes belong to this category are [12–17]. For comparison purpose, a short summary of some routing schemes is described in Table 1.
Contributions: Although, some impressive hop based routing
techniques like [21,22] are available in literature review but it is
not easy to implement them for UWSNs due to different environmental characteristics. In this paper, we proposed a novel routing
protocol called Hop-by-Hop Dynamic Addressing Based (H2DAB) for critical underwater monitoring missions. H2-DAB is scalable and energy efficient and it will use multi-sink architecture.
Surface buoys will be used to collect the data at the surface and
some nodes will be anchored at the bottom. Remaining nodes will
be deployed at different levels from surface to bottom. Nodes near
the surface sinks will have smaller addresses and these addresses
will increase as the nodes go down towards the bottom. These dynamic addresses will be assigned with the help of hello packets;
those are generated by the surface sinks. Any node which collects
the information will try to deliver it towards the upper layer nodes
Table 1
Short summary of protocols which require special network setups.
Algorithm
Requirement/assumption (s)
DBR [5]
Localization
scheme [11]
Every node should be equipped with a depth sensor.
(i) Special DET nodes are required, equipped with
an elevator.
(ii) Some nodes require anchoring at different
depths and locations in whole area.
(i) All nodes must be clocked synchronized.
(ii) GPS communication and Time of Arrival (ToA)
method required.
Assumed that full dimensional location information of
whole network is available.
It is assumed that every node knows its own location.
It is assumed that every node knows its own location
and location of sink.
Every node knows its own location information and preplanned movement of destination.
All nodes know not only their own location but the
location of one hop neighbors and location of sink as
well.
(i) Accurate timing required for synchronization
and range estimation.
(ii) Network should consist of small number of
nodes; adding new nodes will expand the protocol header overhead.
(i) Two special types of nodes are required
(ii) Local sinks at different depths and locations are
connected with each other via high speed links
(RF link or Optical Fibre).
(i) Every node should be equipped with both, radio
and acoustic modems.
(ii) Every node uses a mechanical module, to
emerge and submerge operation.
(i) Every sensor node is connected with a long wire
which is anchored at the bottom.
(ii) Sensor should have an electronically controlled
engine to adjust the length of the wire.
Localization For
USN [18]
VBF [12]
FBR [13]
REBAR [14]
SBR-DLP [15]
DFR [16]
LASR [19]
Multi-path virtual
sink [20]
UW-HSN [9]
Resilient routing
[6]
in a greedily fashion. Packets that reach any one of the sinks will be
considered as delivered successfully to the final destination as
these buoys have the luxury of radio communications, where they
can communicate with each other at higher bandwidths and lower
propagation delays. For better resource consumption and to increase the reliability, we will use some special nodes called Courier
nodes. These Courier nodes will collect the data packets from lower
layer nodes, especially from the nodes anchored at the bottom and
after collecting will deliver these packets directly to the surface
sinks.
The main advantages of H2-DAB are as follows:
I.
II.
III.
IV.
Node movements with water currents can be handled easily.
No need to maintain complex routing tables.
It does not require any location information.
It will take the advantage of multi-sink architecture (For single sink, nodes around the sink entertain large amount of
data packets, not only it can lead to the problem of congestions and data losses but also these nodes can die early due
to frequent energy consumption).
3. Problem statement and network architecture
We are considering the application of underwater oil/gas field
monitoring, for this purpose sensor nodes are deployed in the
whole monitoring area in order to collect the information from
the surroundings. As already mentioned, our protocol based on
the multi-sink architecture, which not only very helpful for
increasing the delivery ratios but also increase the network life
by decreasing the energy consumption of the nodes around the
sink. Surface sinks are equipped with radio and acoustic modems,
where RF modems will be used to communicate with each other
and to communicate with the final data processing centre, while
acoustic modems are used to communicate with the sensor nodes.
The sensor nodes are deployed at different depth levels with the
buoyancy control [8,23,24]. In horizontal directions, they can move
freely with the water currents but vertically a node may have small
variations, which can be negligible [3,23].
By doing so, nodes will form layers from the surface to the bottom. The numbers of layers depend on the depth of the monitoring
area, and the communication range of the sensor nodes. The average depth of oceans is around 2.5–3 km [25,26], and acoustic communication range of sensor nodes is not preferred more than 1 km.
However, if we consider every layer at 500 m, then maximum of 5–
7 layers are required to deliver the data packets from bottom to
surface at the average ocean depths. It is important to note that
the performance of our protocol does not depend on the number
of layers. The proposed algorithm can support easily more layers,
but if we increase the number of layers, it will increase the cost
of the network as more nodes are required for the same depth. If
we decrease these layers as acoustic communications support up
to the range of 5 km but it is not preferred as long distance communications drain more energy [13,27]. In order to save energy
and extend the network life time, we define the acoustic communication range of sensor nodes up to 800 m. It is found that acoustic communications are considered short range up to the distance
of 1 km and are able to provide a bandwidth of 20–30 kHz
[28,29]. Although, in special cases, we can increase this [27,30],
but during normal cases there is no need to increase more than this
suggested range.
In many applications we are more interested to collect data
from the nodes anchored at the bottom like oil/gas field monitoring; in such applications events occur more frequently at the bottom. In order to collect this frequent data from the lower layers in a
fast way with the involvement of fewer nodes, we prefer the use of
Courier nodes. These special nodes can sense as well as can receive
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
is more challenging task [4]. For this purpose, H2-DAB completes
its task in two phases. In the first phase, route creations are done
by assigning dynamic HopIDs to every ordinary sensor node in the
network. In the second phase, data packets are forwarded towards
the surface sinks by using these HopIDs.
the data packets from other ordinary nodes and will deliver it to
the surface sinks directly. These nodes can move vertically, with
the help of a mechanical module, which helps to push the node inside the water till the node reaches the bottom where it will stop
for a specified amount of time and then pull back to the ocean surface. Equipped piston can do this by creating the positive and negative buoyancy. Here one thing should be clear that, these Courier
nodes can reach at any place at the bottom and surface. Due to
water currents it is not easy to reach any specific place, so we
are assuming that any Courier node can reach at any place at the
bottom and then it can come back at any area on the surface.
According to the underwater conditions and requirements, the
main objectives of H2-DAB routing protocol are as follows.
4.1. Addressing schemes
In H2-DAB we use HopID (for routing decision) and Node-ID
(node identifier) separately. Every node will get its HopID dynamically, and is changeable with the node movements according to
new locations in the network. The Node-ID is a unique address
for every node (anchored or not) throughout its life time and
throughout the network.
Every surface sink will have two types of addresses,
I. Dynamic address configuration: every node throughout the
network can obtain its address dynamically, without the
involvement of any static or manual configuration.
II. Scalability: our protocol is scalable as its performance does
not depend on the size of the network.
III. Robustness: H2-DAB is robust as it can adopt the network
changes easily, where nodes can come or leave the network
without making any serious effect on the rest of network.
Sink-ID: a unique Sink-ID for every sink, hello packets will use
this ID to recognize the sink.
HopID: a static HopID ‘‘00’’ is the same for all the sinks. All the
data packets will use this ID as destination ID.
Sensor nodes of both types, ordinary or Courier will also use two
types of addresses.
4. H2-DAB routing protocol
Node-ID: again a unique Node-ID for all the nodes, it will help to
recognize them during inquiries and data packets forwarding
(Section 4.5).
HopID:
Through extensive literature review, it is found out that underwater routing (forwarding data packets) is not an easy job but
getting and then maintaining location information of sensor nodes
Hello Packet Type
S-HopID
Sink-ID(s)
Max. Hop Count
Fig. 1. Surface sink hello packet (S-hp) format.
Hello Packet Type
C-HopID
477
Courier-ID
Expiry Time
Fig. 2. Courier node hello packet (C-hp) format.
Fig. 3. Assigning HopIDs with the help of hello packets.
Max. Hop Count
478
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
– Ordinary nodes will manage and update two types of HopIDs,
Sink HopID (S-HopID) and Courier HopID (C-HopID). S-HopID
can reach a maximum of ‘‘99’’, and each node has this highest value as the default S-HopID, before receiving the hello
packets. After receiving the hello packet from any sink, it will
update its new S-HopID according to its current location
(Section 4.3). Similarly, C-HopID will manage the addresses,
built with the help of hello packets received from the Courier
nodes.
– Courier nodes will use a static HopID ‘‘19’’, and these nodes
will not entertain hello packets. If any Courier node receives
hello packet from any other node of the same type or even
from the surface sink, it will discard it simply.
4.2. Hello packet format
H2-DAB will use two types of hello packets, from surface sinks
(S-hp) and from Courier nodes (C-hp).
Surface sink hello packet (S-hp): S-hp consists of four fields,
Hello Packet Type, S-HopID, Sink-ID (s) and Maximum Hop Count as
shown in the Fig. 1. Hello Packet Type will be used to differentiate
the type of hello packet, either it is from the surface sink or from
the Courier node. S-HopID consists of two digits and shows how
many hops every node is away from any of the one or two sinks.
Left hop value has more priority and will be considered as a primary route, as compared to the right hop number, which can be
used as a backup route. Sink-ID (s) will be used when every sink
broadcasts hello packets during the first phase then the Sink-ID will
help the accepting nodes to differentiate the hello packets, received from the multiple sinks. Last, the Maximum Hop Count field
has a value of 9 at start when sink broadcasts hello packet. After
receiving, every node will apply the decrement of one, so when
ninth node receives this hello packet, it will make this value zero
and will not forward further to any other node.
Courier node hello packet (C-hp): Hello packets broadcasted
by the Courier nodes have five fields as shown in Fig. 2. The first field
is the same as in the S-hp, which shows the hello packet is from the
Courier node. Then C-HopID will consist of the same 2-digit, which
shows that how many hops the receiving nodes are away from the
Courier node. Sink-ID is replaced by the Courier-ID of the Courier
node, which has broadcasted it. Next, one extra field with the name
of ‘‘Expiry Time’’ is used, and this new field shows that how long this
Courier node will be available. Every ordinary node which updates
their C-HopID through these hello packets can forward and deliver
data packets to the Courier node before this expiry time. Then, the
purpose of Maximum Hop Count field is also same as in the surface
sink hello packet, but it has a value of 3 at start instead of 9, so this
hello packet can visit a maximum of 3 ordinary nodes.
4.3. Calculating and assigning the HopIDs
Every ordinary sensor node use a default value ‘‘99’’ as its HopID
and ‘‘0000’’ as Sink-ID in routing table, till it has not received any
hello packet. When a node receives the hello packet from any surface
sink, Courier or ordinary node with a minimum power threshold
(PTmin), it will start to update its respective HopID. For example, a
node receives the hello packet directly from the sink; it will update
its S-HopID as ‘‘19’’. This new S-HopID shows that, this node is only
one hop away from a sink, and can be 9 hops away from any other
sink. After updating, it will forward the S-hp with its new
S-HopID. Similarly, the receiving nodes will use the increment of
one in their S-HopIDs, and will forward them towards their neighbors, and this will continue till the hop count value of S-hp becomes
zero. During this time, if some nodes receive the S-hp from any other
sink, it will start to update its right hop number (used as a back up)
just like the left hop value. In some situations, if a node receives any
S-hp from the 3rd sink, or a sink, from which it has already received
then it will update its S-HopID, only if the arrived packet has small
hop numbers. Otherwise, it will discard it, if so then hello packet will
not broadcast further. This whole process is depicted in Fig. 3. This is
further clarified by referring to Algorithm 1, for calculating and
assigning these HopIDs.
Algorithm 1. Algorithm for assigning the HopIDs with the
help of hello packets
Hello packets (hp) broadcasts
From all Sinks (S-hp) with
From all Courier (C-hp) with
HopID ‘‘N00’’ &
Max Hop Count = 9
HopID ‘‘N19’’ &
Max Hop Count = 3
//Hello packet received
1.
If Packet Type = S-hp
Get received S-HopID ‘‘Nrs’’ from S-hp
Get own S-HopID ‘‘Npq’’
2.
If r = 0 & & SkID(p) – SkID(r)
// Existing sink
ID – Receiving sink ID
Or r – 0 & & r < p < =s Then
3.
q
p
4.
p
r+1
5.
else If r – 0 & & r & s < p Then
6.
p
r+1
7.
q
s+1
8.
else If r > =p & & s < q Then
9.
q
r+1
10.
Else
11.
Max Hop Count = 1
// In order to stop
further broadcast
12.
End If
13.
End If
14.
End If
15.
Max. Hop Count-1
16.
If Max Hop Count > 0 Then
17.
Update S-hp Own S-HopID
18.
Broadcast S-hp further
19.
Else
20.
No further broadcast for this S-hp
21.
End If
22. End If
23. If Packet Type = C-hp
Get Received HopID ‘‘Nm n’’ from C-hp
Get Own HopID ‘‘Nx y’’
24.
If m < x Then
25.
x
m+1
26.
Else
27.
Max Hop Count = 1
// In order to stop further
broadcast
28.
End If
29. Max Hop Count-1
30.
If Max Hop Count > 0 Then
Update C-hp
Own C-HopID
Broadcast C-hp further
31.
Else
32.
No further broadcast for this C-hp
33.
End If
34. End If
Similarly, a node can receive hello packet from Courier node
(C-hp). The procedure of updating the C-HopIDs from the hello
packets generated by the Courier nodes is simple as compare to
S-HopIDs. It will update only in the left hop, and the right side or
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
Source
Node-ID
Next
Node-ID
Packet Seq.
Number
Dest. ID
479
Data …
Fig. 4. H2-DAB data packet format.
Table 2
Routing information maintained by an ordinary node.
t0
t1
t2
NodeID
P
Q
SinkID P
SinkID Q
X
Y
CourierID
Courier
expiry
Next
hop
107D
107D
107D
9
1
1
9
9
6
0000
5D87
5D87
0000
0000
8E23
9
9
2
9
9
9
0000
0000
4BB1
N/A
N/A
Adaptive
Expire
5D87
5D87
backup hop value will remain the same which is 9. Therefore, there
is no need to check the Node-ID of Courier node before updating
the C-HopID. If C-HopID of new received C-hp is smaller than its
own then update own C-HopID; if not then discard it simply. Here
one thing is important that why we are not using the backup hop
for Courier nodes, which is due to couple of reasons. First, the possibility of availability of the Courier nodes in a specific region is
very small as one or two Courier nodes can visit a place at the same
time. Secondly, Courier nodes visit for short intervals and then
these can leave for any other location. For these short intervals
and small Courier nodes, only the primary hop can provides the required results. Every ordinary node will maintain a simple routing
table consists of only one entry, which can be shown in Table 2.
Table 2 gives an idea on how an ordinary node (107D in this
example) maintains the information about the surface sinks and
Courier nodes at different times. The first row provides the status
of routing table at time t0, where first column presents its own
Node-ID. Next four columns maintain the surface sink HopID and
the Sink-IDs from which it has received the hello packets. Similarly,
next four columns maintain the C-HopID, the permanent ID of the
Courier node and its expiry, which is mentioned in the hello packets. The last column presents the Node-ID of the possible next hop,
where current node can forward the data packet. In the cases
where no node is available as a next hop and it shows ‘‘Expire’’
in this column then the current node will follow the Algorithm 2
in order to find the next hop. When the current node is able to find
the next hop successfully, then it can store the Node-ID of that
node in this last column. Remaining two rows, t1 and t2provide
the updated status of first row at different time intervals which
can be possible after receiving the hello packets.
4.4. Data packet format
The data packet format required for the H2-DAB is simple, as it
requires only four fields for control purpose, Source Node-ID, Next
Node-ID, Packet Sequence Number and Destination ID, as shown in
Fig. 4.
Source Node-ID, the node which senses the information will use
its Node-ID before forwarding the data packet. Next Node-ID, the
Node-ID of a node which considered eligible for next hop among
the neighbor nodes, usually near the surface sink or Courier node.
Packet Sequence Number is a unique number assigned by the source
node to every data packet at the time of generation. Destination ID
is a fix value ‘‘00’’, which is the HopID of all the sinks on the surface,
so packets can be delivered to any of the reachable sink.
4.5. Data packet forwarding
Fig. 5 describes how to make the decisions about data packets. A
source node N23 has a data packet, with its own HopIDs 66 & 99 (C-
HopIDs for all the nodes are 99 because no Courier node is available
in this area); it will ask its neighbors about their HopIDs with the
help of a simple ‘‘Inquiry Request’’. This Inquiry contains only the
Node-ID of the requesting node. ‘‘Inquiry Reply’’ will be used to reply, and it contains only three fields, Node-ID, S-HopID and C-HopID
of replying nodes. Nodes N15, N16, N22, N24 and N25 are in the
communication range and will reply with their Node-IDs and HopIDs. After receiving, N23 sort out these Inquiry replies and get
the minimum HopID, Min{<N15, 55:99>, <N16, 56:99>, <N22, 67:
99>, <N24, 66:99>, <N25, 78:99>}. As diagram shows, nodes N15
and N16 are declared as the candidates for the Next Hop, because
both of these have smaller S-HopIDs as compare to S-HopID of the
source node, but N15 wins this competition as its backup link is
also smaller than the N16. The source node will forward the data
packet with N15 Node-ID as a Next Hop. In some cases, if two nodes
reply with the same minimum HopIDs, then the node which replied
first, will be eligible as next hop. For energy concerns, packets over
multiple short hops are preferred instead of long links [13].
A more general scenario is shown in Fig. 6, which describes how
to forward the data packets when Courier node is also available.
The HopIDs of all the nodes are shown in the Table 3. Two nodes,
N62 and N65 have data packets in order to send to the destination.
N62 will ask its neighbors for their HopIDs, N51 and N74 are in its
range so both of these will reply with their HopIDs. C-HopID of its
neighbor nodes shows that Courier node is not available so packet
will be forwarded to the N51 and then N51 will repeat the same
procedure and it will select N45 as the next hop and it will continue till the data packet reaches the surface sink.
In the second case, N65 also has data packet, so it will ask its
neighbor nodes for their HopIDs. Here N53, N74 and N75 are in
its range and will reply their HopIDs. From the replied HopIDs it
is clear that Courier node is also available and N75 has smaller
C-HopID, so it will be considered as the next hop. After receiving,
N75 will repeat the same process and it will continue till data
packet reaches the Courier node ‘‘C1’’ which has ‘‘19’’ as the smallest C-HopID. The process of forwarding the data packets is further
described in Algorithm 2.
However, it is not possible that every time the source node can
get the response from the neighbor nodes with the smaller HopIDs.
In cases, when a source node cannot get such response, especially
in sparse areas then it will wait for a defined amount of time (Section 4.6) and try again to get the HopIDs. After the third attempt, if
the result is same, it mean no node is available with smaller HopIDs. Now, it can forward the data packet towards a node on the
same layer with the HopID value nearly or equal to its own HopID
or it can be forwarded towards the lower layer nodes. The reason
we advocate for trying 3 times in upward direction in our scheme
is that we get finer results combining both, delivery ratios and endto-end delays. In some worst cases, if source node cannot communicate with any other node, then as the last choice, it can remove
the restriction of suggested range of 800 m [27,31].
From the earlier scenario it is clear that, delivery ratios for
H2-DAB, does not depend completely on the network density or
sparseness. Further, we can improve the performance according
to the nodes densities. If the network is dense, then for simplicity
we can define that, after receiving the Inquiry Request only the
nodes with smaller HopIDs than requesting node can reply. If the
network is sparse, then all the nodes receiving the Inquiry Request
will reply.
480
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
Algorithm 2. Forwarding the data packets with the help of
HopIDs
Data packet (dp) ready to send (Either own generated or
received)
1. If Next Hop – Expire
// From last column of routing
table
2.
Forward dp to Next Hop
3.
If Ack. Received = Yes
4.
If next dp ready = yes
5.
go to step 1
6.
Else
7.
wait until dp ready
8.
End If
9.
Else
10.
go to step 13
11.
End If
12. Else
13.
Request Count for this dp = 0
14.
Request neighbors for HopIDs
15.
Req. Count + 1
16.
If Current HopID >= dp Source HopID & Request
Count < 3 Then *
Discard Inquiry Reply of Source node
17.
Replied HopIDs put in array
Sort out and get the Minimum of both S-HopID and
C-HopID
(Min. S-HopID & Min. C-HopID)
18.
Else
19.
Replied HopIDs put in array
Sort out and get the Minimum of both S-HopID and
C-HopID
(Min. S-HopID & Min. C-HopID)
20.
End If
21.
Compare (Min. S-HopID) & (Min. C-HopID) and
get Smaller
(SML-HopID)
22.
If Request Count < 4 Then
23.
If SML. HopID < Own HopID Then
24.
Next Hop Node-ID of SML. HopID
25.
go to line 1
26.
Else
27.
Wait defined amount of time
// Section 4.6
28.
go to step 14
29.
End If
30.
Else
31.
Forward dp to Node-ID of SML. HopID, Until
packets in buffer are available
32.
End If
33. End If
*
Is current dp received from upper layer? If so then do not consider
the inquiry reply from that source node.
4.6. Calculating the waiting time
When a source or forwarding node cannot find next hop from
upper layers after the first try then it will make two attempts to
send current data packets towards the upper layers, before sending
them towards the nodes belong to the same or lower layers.
Waiting time of both intervals can be a value between [0, 100],
where 0 mean no wait and 100 can be the maximum wait in the
worst situations like sparse areas. Before going for the 2nd try, it
will wait t1 time, depending on the number of nodes replied in
the first inquiry request, and we can calculate t1 as
t1 ¼
C
n1 þ 1
ð1Þ
where C is a constant, that has the maximum value of the waiting
time and n1 is the number of neighbor nodes replied in the first inquiry request.
After the 2nd try, if it still cannot find any node from the upper
layers then it will wait t2 time depending on two parameters’ first,
the number of nodes replayed after the 2nd inquiry request and
second, the difference between the number of nodes in the 1st
and 2nd inquiry request. We then get the average of these
parameters.
Node-ID
S-HopID
C-HopID
Fig. 5. Selecting the next hop for the data delivery.
Fig. 6. Selecting the next hop when courier node is available.
Table 3
HopIDs of nodes in Fig. 6.
Node-ID
S-HopID
N62
N74
N51
N45
N53
7
8
9
9
8
6
5
6
7
8
7
5
6
7
9
9
9
9
9
9
9
9
9
9
8
8
7
8
NA
7
8
9
9
8
9
NA
7
8
4
3
3
2
1
2
2
9
9
9
9
9
9
9
N65
N75
N77
N66
N79
C1
N68
N81
C-HopID
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
h
t2 ¼
C
jn2 n1 jþ1
þ n2Cþ1
i
2
ð2Þ
where C is a constant and n2 is the number of neighbor nodes replied in the 2nd request. From Eq. (1) and (2) it is clear that, the
waiting time depends on the availability of neighbor nodes and frequency of change in them. Both of these parameters are inversely
proportional to the waiting time as waiting time start to decrease
when any of one or both parameters start to increase.
4.7. Route updating and maintenance
Due to buoyancy control, nodes fluctuate slightly vertically, but
still can move easily in horizontal directions with the water currents. As a result of these movements, a node can change its neighbors, both with upper and lower layers. Even the neighbors are
continued to change, still these addresses can be used as address
of any node will remain smaller from the addresses of lower nodes
and larger from the upper nodes. In other words, the address of any
node shows that how many layers or hops have to move in order to
reach the water surface, as it is not necessary to reach any specified
sink because data packets can be delivered to any of these sinks.
As we mentioned earlier in our problem statement that we are
considering the oil/gas field monitoring application, where most of
the time the samples of the data are required from time to time.
During one interval, the event can be detected and information
delivered in a short time and then nodes can go to sleeping mode
or it can shut down the transceiver till the next sampling interval
in order to save the energy. These sensing and sleeping intervals
can be scheduled according to the situations and requirements of
the network.
For the next interval, nodes will be assigned new HopIDs
according to the new locations. These interval based HopIDs can
give better results only when these intervals are not very long. If
sampling intervals are long then, with the node movements the
performance of the network can decrease with the same HopIDs.
However, it is not a serious problem as we can handle such situations easily. For long term missions; these HopIDs have a time property, which denotes the validity time for them. The larger the HopID
lifetime is, the longer time for which it can continue to work. When
the lifetime exceeds the threshold value EXPIRE, the HopIDs will be
reset to ‘‘99’’ throughout the network, and again new HopIDs will
be assigned with the help of new hello packets. If any node has
data packets to be sent before the HopID expiry, then it will wait
and can forward these packets after getting the new HopIDs. A
fixed life for every interval will not be suitable at different operational conditions. The life time of every interval will be dynamic
as it depends on the environment. Determining a good life time,
the duration of interval is important for good performance of the
network. At one side, getting the new HopIDs in such a way helps
to handle the problem of even small vertical movements, as the
next time nodes will get new HopIDs according to their new positions. At the same time, it makes the buoyancy control more flexible, as violations of strict layering structure can be acceptable.
5. Analytical model for energy consumption for H2-DAB
We consider N number of sensor nodes deployed uniformly in a
monitored area A where these nodes have formed layers from surface to bottom. Each sensor node has an initial energy level e unit
and we consider the energy consumption for data packet as well as
control packets like, Inquiry Request and Inquiry Reply. In the scenario, only the nodes with smaller HopID will send the Inquiry Reply. Both control packets are of same size and consume very little
energy as compared to data packet. For our model, Ed is the complete energy required for forwarding a data packet from one layer
481
to the other which includes ed, the energy consumed for sending
data packet and ec, energy consumed for sending the control packet. While, Ei?s is the total energy consumed when i data packets are
forwarded towards the sink, from i layers (each layer generate one
data packet).
Energy consumption in the network
We divide the depth into m layers and each layer contains n
number of nodes while total D data packets are generated in the
network, where each node generates (D/N) data packets. We use
k to present (D/N) data packets. The energy consumption at ith
layer is denoted as Ei and life time of this layer can be represented
as Ti, while Ti/n is the life time of each sensor node that belongs to
this layer. All the layers can receive data packets from the below
layers and forward these as well as their own generated data packets towards upper layers. We assumes that HopIDs are already assigned as it required only once for long intervals. For simplicity, we
are considering the energy consumption during the sending process. While, energy required for the reception process for Underwater Acoustic Communication is usually 100 times smaller than
transmitting [32,33].
We check the energy consumption with both scenarios, first
with static nodes and then with mobile nodes.
5.1. Energy consumption with static nodes (Best Case)
For static scenario, every node will send only one Inquiry
Request and will get also single Inquiry Reply. After that, Node-ID
of replying node is saved in the routing table and will be used as
a next hop for all the remaining data packets.
For the first time, energy consumption for a single data packet
from any lower layer to next upper layer is
Ed ¼ 2ec þ ed
ð3Þ
where, ‘‘ec + ed’’ is the consumption from current layer which has
data packet. At first it sends an Inquiry Request and then forwards
the data packet after receiving the Inquiry Reply. While, the remaining ‘‘ec’’ is the consumption from upper layer when a node replied
with the Inquiry Reply. First we consider the case, when data packet
is generated at a node in the first layer and it forwards directly to
the sink ‘‘S’’. After that, similarly, data packet is generated at second
layer and forwarded towards the sink through the first layer and so
on. The effect of energy consumption at each layer can be represented by the following equations,
E1!S ¼ ðec þ ed Þ
E2!S ¼ ð2ec þ 2ed Þ þ ðec þ ed Þ
E3!S ¼ ð2ec þ 3ed Þ þ ð2ec þ 2ed Þ þ ðec þ ed Þ
..
.
Em1!S ¼ ð2ec þ ðm 1Þed Þ þ ð2ec þ ðm 2Þed Þ þ þ ð2ec þ 2ed Þ þ ðec þ ed Þ
Em!S ¼ ð2ec þ m ed Þ þ ð2ec þ ðm 1Þed Þ þ þ ð2ec þ 2ed Þ
þ ðec þ ed Þ
ð4Þ
Eq. (4) shows how the upper layers are affected when one node at
every layer generates a data packet and total m data packets are forwarded towards the sink. It is clear that, layer 1 processes all m data
packets and due to that it faces maximum energy consumption
(2ec + med) than any of the other layer. Layer m has the least energy
consumption (ec + ed) as it processes only one data packet. Now,
when k data packets are generated on the same node of each layer
then we can represent Eq. (4) as follows
Emk!S ¼ ð2ec þ k m ed Þ þ ð2ec þ k ðm 1Þed Þ þ þ ð2ec
þ k 2ed Þ þ ðec þ k ed Þ
ð5Þ
482
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
With the above equation, energy consumption at layer i can be
calculated, when it processes its own generated data packets as well
as forward the data packets of all the lower layers.
Ei ¼ ðm iÞq þ ð2k ed 1Þ þ k 3ec
Ei ¼ ðm iÞk ed þ k ed þ 2ec
Ti ¼
where i < m
We use q to denote ked. Now we can write,
From here, life time of layer i can be calculated as
T i=n ¼
ð6Þ
From Eq. (6), we can get the life time of a node at layer i as below,
T i=n ¼
e
ðm i þ 1Þq þ 2ec
5.2. Energy consumption with mobile nodes (Worst Case)
When we talk about mobile nodes, then in worst case Eq. (3)
becomes
Ed ¼ ed þ ðn þ 3Þec
ð7Þ
where, ‘‘ed + 3ec’’ is the energy consumption from current layer, for
the worst case when it has to make three Inquiry Requests. Now it is
possible that, no node replies in first two tries and then after the 3rd
request, all nodes have replied from the upper layer. In such case,
‘‘nec’’ will be the consumption in the form of Inquiry Replies. Here
it should be clear that we are considering the worst case in terms
of energy, but not in terms of node failure.
Again, first we consider the case when the data packet is generated
in the first layer, and then remaining lower layers generate packets
and forward them towards the sinks through the upper layers.
E1!S ¼ ðed þ 3ec Þ
E2!S ¼ ð2ed þ nec þ 2:3ec Þ þ ðed þ 3ec Þ
E3!S ¼ ð3ed þ 2 ec þ 3:3ec Þ þ ð2ed þ nec þ 2:3ec Þ þ ðed þ 3ec Þ
..
.
Em1!S ¼ ððm 1Þed þ ðm 2Þ nec þ ðm 1Þ 3ec Þ þ þ ð2ed þ nec þ 2:3ec Þ þ ðed þ 3ec Þ
Em!S ¼ ðmed þ ðm 1Þ nec þ m 3ec Þ þ þ ð2ed þ nec þ 2:3ec Þ þ ðed þ 3ec Þ
ð8Þ
Eq. (8) provides same effect for mobile nodes as Eq. (4) for static
nodes. Similarly, when k data packets are generated at one node
of each layer, then we can represent Eq. (6) as follows
Emk!S ¼ ðð2 k m ed 1Þ þ kðm 1Þ nec þ k m 3ec Þ þ þ ðð4k ed 1Þ þ k nec þ 2k 3ec Þ þ ðð2k ed 1Þ
þ k 3ec Þ
ne
ðm iÞq þ ð2k ed 1Þ þ k 3ec
ð10Þ
Similarly, from Eq. (10) we can get the life time of a node at layer i
as follows,
Ei ¼ ðm iÞq þ q þ 2ec ¼ ðm i þ 1Þq þ 2ec
ne
Ti ¼
ðm i þ 1Þq þ 2ec
From here, life time of layer i can be calculated as
ð9Þ
For worst situations, we consider the case when sensor nodes try to
forward 2nd packet after receiving 1st acknowledgment, but for
2nd data packet cannot receive it. It makes 2 tries for every data
packet but other than the 1st one, as for 1st data packet, first it will
find the next hop and then can forward it. Now, Eq. (9) can help to
calculate the energy consumption at layer i, where not only it forwards its own generated data packets but the data packets of lower
layers are also forwarded through it.
Ei ¼ ð2kðm i þ 1Þed 1Þ þ kðm iÞnec þ kðm i þ 1Þ3ec where i < m
Ei ¼ ð2kðm iÞed 1Þ þ kðm iÞnec þ kðm iÞ3ec þ ð2k ed 1Þ þ k 3ec
Ei ¼ ðm iÞ½ð2k ed 1Þ þ k:nec þ k:3ec Þ þ ð2k ed 1Þ þ k 3ec
We use q to denote (2ked 1) + knec + k3ec. Now we can write,
e
ðm iÞq þ ð2k ed 1Þ þ k 3ec
Eqs. (6) and (10) shows that, as the value of i increases mean we go at
deeper, the value of q decreases. On the other hand, upper layers face
more energy consumption problem as the number of layers starts to
increase in the network. However, as compare to single sink architecture, the possibility of bottleneck occurrence around the sink is decreased here due to multi sink architecture. For single sink
architecture, only a few nodes around the sink process all the data
packets generated in the network, while here this burden is divided
on the whole upper layer instead of few nodes. Furthermore, in order
to reduce this effect, we introduced Courier nodes that collect data
packets directly from the lower layers, so that upper layers process
less data packets which ultimately increase the life of the network.
6. Performance Evaluation
In this section, we evaluate the performance of the H2-DAB
through extensive simulations, and we used NS2 for this purpose.
We deployed 350 ordinary sensor nodes (some anchored at bottom) in a 1500 m 800 m 800 m 3D area. The process of data
delivery is completed with the help of 8 layers from bottom to surface. Transmission range of sensor nodes can be up to 150 m,
where the average depth and width of every layer are defined at
100 m, while surface sinks are also deployed at a distance of
100 m. The deployment of Courier nodes is optional as our routing
protocol can complete its task without their presence. However, for
better resource usage, we use small number of Courier nodes as 1%
and 2 % of all the sensor nodes. Ordinary sensor nodes can move
freely with the water currents in horizontal direction with 2 and
4 m/s and will return back after reaching the defined boundary
while vertical movements are not considered during the simulation. Any node in the network can generate data packet, but the
nodes anchored on bottom will generate half of the total data packets generated in the network. The size of the hello packet assumes
to be very small as compare to data packet as every hello packet
will consume 1% of the network resources as compare to every
data packet. The power consumption varies for different routing
events; we assume the consumption of 1 energy unit during transmission and 0.02 units for receiving the data packet. In order to
prevent data collisions, a node can transmit data when no other
transmission detected in its collision domain. The medium access
control (MAC) protocol is based on the IEEE 802.11 and traffic
sources are Constant Bit Rate (CBR) with 512 bytes per packet. A
total of 500 data packets are generated with a rate of 1 packet
per second among these 250 packets generated from the nodes anchored at bottom and remaining half are generated randomly from
the floating nodes.
6.1. Performance metrics
We use delivery ratios, end to end delays and energy consumption as the metrics in order to check the performance of the proposed scheme. Delivery Ratio is the total number of data packets
received successfully at all the sinks. End to End delays is defined
as the average time taken for a data packet in order to reach the
surface sink from the source node. Energy Consumption is defined
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
as the total energy consumed throughout the network during all
the routing processes and states like sending, receiving and idling.
6.2. Simulation results
Node Mobility: Fig. 7(a) explains the data delivery ratios at different speeds of node movements, while we use three Courier
nodes during the simulation setup. As shown in the figure, the data
delivery ratios are 100% with the suggested number of nodes in the
network. Even, these delivery ratios are not seriously affected if the
nodes density starts to decrease, we can achieve around 95% delivery ratio if 25–35% nodes are not available. If we look at the delivery ratios in the sparse areas, where 50% nodes are not available,
we can still receive around 85% data packets at the average node
movements. Now, if we observe the effect of node movement on
the end to end delays and energy consumption, those are shown
in Fig. 7(b) and (c). Here we can observe some difference with node
mobility as compare to static nodes. In the beginning, with dense
deployment this difference is minor and then it starts to increase
when nodes start to decrease but still these differences are not
high until more than 50% nodes are part of the network.
In general, node mobility has no serious effect on the data delivery and energy consumption, as the minor difference at different
node speeds. It is due to that, no complex routing tables are going
to be maintained according to the location information of the sensor nodes. So, there is no need to manipulate them before any routing decision when even node has changed its position. Every node
can use its HopID, no matter how far it has moved vertically. Movement of nodes can have some affect on average end to end delays,
but it’s only in sparse areas. In dense areas, all the metrics almost
generate similar results with different node movements.
483
Courier Nodes: As we already mentioned that, H2-DAB can
complete its task without the presence of any Courier node, but
for reliability concern and better resource utilization we suggest
small number of Courier nodes. Fig. 8, shows how different number
of Courier nodes helps to increase the overall performance of the
routing protocol. In Fig. 8(a), from delivery ratios we can see that,
although in dense areas we can achieve high delivery ratios even
without Courier nodes, but in sparse areas the presence of Courier
nodes can lift these ratios. In such situations these Courier nodes
easily accommodate the deficiency of ordinary sensor nodes. From
these results, it’s clear that only 1–2% Courier nodes can provide
more than 90% delivery ratios with 50% ordinary sensor nodes
Not only delivery ratios, Courier nodes also help to reduce the
overall energy consumption of ordinary sensor nodes. These Courier nodes collect the data packets from the bottom layers and
move physically in order to deliver these packets to the surface
sinks directly. By doing so, the involvement of ordinary sensor
nodes decreases, so the cost per packet delivery is decreased which
ultimately increase the life of the network.
Offered Load: In order to check the performance of H2-DAB
with different offered load, we analyzed the delivery ratios and
end-to-end delays by producing more data packets in the network.
In normal case, network generates 1 packet per second, but here
we consider the cases where first the network generates 3 packets
in every 2 s and then 2 packets per second. Fig. 9(a) presents the
delivery ratio with different offered load. It shows that with dense
nodes, the delivery ratios are almost the same and the difference
starts when the number of nodes starts to become sparse. At high
offered load and with fewer nodes in the network, some time a
node cannot find next hop and packets start to increase in the
buffer which results in discarding them.
Fig. 7. The effect of node movements on H2-DAB performance.
484
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
Fig. 8. The effect of Courier nodes on H2-DAB performance.
Fig. 9(b) shows the variations in end-to-end delays when we
increase the number of packets in the network. It shows that, the
network can handle easily when 50% more packets becomes the part
of the network; even these delays are affordable when double
packets have been generated in the network.
6.3. Comparison with DBR
Many routing schemes require and manage full-dimensional
location information of the sensor nodes in the network which itself
is a challenge left to be solved for UWSNs. Instead of requiring complete localized information, DBR [5] needs only the depth information of sensor node and packet forwarding decisions are based on
this depth (or pressure) level. When a node has a data packet to be
sent, it will sense its current depth position relative to the surface
and place this value in the packet header field ‘‘Depth’’ and then
broadcast it. Similarly, the entire receiving nodes will calculate their
depth positions and only those nodes can forward this data packet
that has smaller depth than the value embedded in the packet, and
remaining nodes will simply discard it. This process will be repeated
until the data packet reaches at any of the surface sink. However,
DBR has some serious problems as compare to H2-DAB and among
these two are as follows. First it requires that every node must be
equipped with a depth or pressure sensor which not only increases
the cost of network but also these sensors will be a burden on the
limited node energy. Secondly; DBR cannot handle the problem of
void regions in swarm as it is possible that no node can be eligible
as a forwarding node due to greater depth as compared to sending
node; and current node will continue to make more and more attempts due to its greedy fashion even some routes are available
through higher depth levels.
Further we check the performance of H2-DAB by comparing
with DBR. First, we compare the delivery ratios with single and
multiple sinks in Fig. 10(a). When we use multiple sinks it was
found that both algorithms provide similar results with dense node
deployments. However, when nodes start to decrease then delivery
ratios for DBR starts to decrease as well, while it has less effect on
H2-DAB delivery ratios.
The main reason is that, DBR uses only the greedy mode for data
forwarding and some times when no node found with less depth
then it cannot forward even where some nodes are available in
the communication range with higher depths. Further, when we
use single sink which is placed at the centre of surface, then we
find a clearer difference in delivery ratios. Again due to greedy
mode of DBR, sensor nodes try to send towards the water surface
but not towards the sink which is placed at the centre of the
deployment area. Here no recovery method is available for DBR
and when the nodes in the upper layers broadcast data packets
then no node can accept because no nodes are available with smaller depth and at the same time sinks are not available at those
locations. Due to this, data packets can be discarded which ultimately decrease the delivery ratios.
Further we talk about the end-to-end delays in Fig. 10 (b); here
H2-DAB delivers data packets with less end-to-end delays when
reasonable sensor nodes are available in the deployed area. For
our understanding, it is due to the holding time used in DBR where
Fig. 9. The effect of different offered load on H2-DAB performance.
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
485
Fig. 10. Performance comparison of H2-DAB with DBR.
all the data packet receiving nodes wait, instead of immediate forwarding in order to check that some other neighboring nodes are
also going to forward the same data packet or not. On the other
hand, when the nodes start to become sparser then delays start
to increase for H2-DAB. It is because, with small neighbor nodes
when a node cannot find a forwarding node with smaller HopID
then it waits for a defined amount of time before going for 2nd
or 3rd try, even it can send towards higher depths in much sparse
areas. It results in higher delays when nodes become much sparser
but ultimately it provides better delivery ratios.
Next, Fig. 10(c) shows the comparison of energy consumptions
with different number of sinks. First when we check these consumptions with smaller number of nodes then these consumptions
are almost similar for both schemes. When the number of nodes
starts to increase the consumption difference also start to increase.
For DBR, it happens due to two reasons. First, DBR uses broadcast
for every data packet and in dense areas after receiving, more
and more nodes go for broadcasting of the same data packet. Secondly, in such areas, when more nodes receive the data packet then
every receiving node check its depth every time. Due to large number of neighbouring nodes it can receive burst of data packets and
in order to decide whether to accept or discard it, receiving node
checks its depth every time which ultimately drain more and more
energy. About H2-DAB, it consults the neighbours only when ‘‘Next
Hop’’ expires or not acknowledged.
The proposed algorithm provides better results in most of the
situations and with different parameters. DBR faces problems in
both situations, as when nodes start to increase then energy consumption is high and when nodes start to decrease then delivery
ratios are affected with this sparseness. On the other hand, H2DAB maintain good delivery ratios with small number of nodes
and start to improve with controlled energy consumption when
nodes start to increase in the area.
7. Important aspects of H2-DAB
Besides the advantages such as low cost and requiring no
dimensional location information for task completion, the following are some important aspects of H2-DAB.
Node movements are easily handled: Vertical node movements are
very common for these networks and as a result, a node can
change its neighbors both with upper and lower layers. Even
the neighbors are continued to change, these addresses can still
be used as address of any node will remain smaller from the
addresses of lower nodes and larger from the upper nodes.
Nodes lost and found: In H2-DAB, every node has only one entry
in each of their routing table. Hence, to add or to delete entries
when nodes are lost or added in the network is unnecessary.
Newly deployed nodes will obtain their HopIDs at the next
interval and automatically become a part of the network. H2DAB is highly adaptive to network dynamics such as nodes joining and leaving the network for its reactive hop-by-hop packet
routing mechanism.
Node address expiry: H2-DAB allows an auto update of its HopID
upon receiving new hello packets and then forwards the buffered packets in the same way just like before the expiry of
the old HopID. Thus, old packets need not be discarded when
the address of a node expires.
Loop free routing: The occurrence of loops during the routing
decisions, especially during address assignment is common
for Dynamic Addressing based protocols. However, H2-DAB is
sensitive and intelligent enough to avoid the occurrence of such
routing loops.
Problem of table size: The growth of the routing table is a serious
problem for Dynamic Addressing based networks. For H2-DAB,
the size of routing table is not affected by the network size as it will
486
M. Ayaz et al. / Computer Communications 35 (2012) 475–486
remain of the same size and every node maintains a table of one
entry even when the network consists of a large number of nodes.
Problem of address space exhaustion: Most of the dynamic
address assignment schemes used for the ad hoc networks face
the issue of address space exhaustion, but not in H2-DAB, as
addresses will remain of 2 digits per HopID as well as multiple
nodes that can use the same address without any problem during data deliveries.
Destination movement flexibility: Some protocols assume that
destination is fixed and unable to change its location. However,
it seems not to be always true due to the water currents. While
some other like [15] assumes that destination movement is predefined and already known to all the sensor nodes before
launching, For H2-DAB, no such assumption is made. All sinks
can move and can still receive data packets easily.
Destination address changes: Final destination address for all the
surface sinks is similar and static, so the problem of destination
address change during routing decisions does not occur. Additionally, packets can be delivered to any nearest surface sink.
Routing decisions without maintaining global knowledge: intermediate nodes forward data packets without maintaining global knowledge of whole network which strongly helps to
decrease the communication of the control packets.
Monitoring areas with normal depths: In most of the applications,
the monitored areas are with a depth of not more than 2 km.
H2-DAB in such environments provides even better results
(with 4–5 hops).
8. Conclusions and future work
In this paper we proposed a distributed routing protocol for
UWSNs, based on the local information and current location of
the sensor node. Novelty of this protocol is that, it does not require
full dimensional location information, as well as there is no need to
maintain the complex routing tables. We kept the routing overheads minimum, as available data rates are extremely low for
the UWSN. In this research, we use the idea of per-contact routing,
instead of source routing or per-hop routing according to the underwater requirements. An important fact about the H2-DAB is that,
the delivery ratios are not seriously based on the density or sparseness of sensor nodes. Node mobility due to water currents is a challenge for underwater routing but is handled easily with the
proposed protocol. The problem of node failure, which is a major
threat and possibility for UWSN, is not a serious problem with
H2-DAB. New nodes can be added at any time and at any location,
and these new nodes can configure easily during next interval. We
can get good results for long term applications even in vast areas
with large number of nodes, because every node gets its routing
address despite the network size. In future, we are planning to
integrate H2-DAB with several underwater MAC protocols and to
investigate the relative performance.
References
[1] J.-H. Cui, J. Kong, M. Gerla, S. Zhou. Challenges: building scalable and
distributed Underwater Wireless Sensor Networks (UWSNs) for aquatic
applications. UCONN CSE Technical Report: UbiNet-TR05-02 (BECAT/CSE-TR05-5), January 2005.
[2] I.F. Akyildiz, D. Pompili, T. Melodia, Underwater acoustic sensor networks:
research challenges, Ad Hoc Networks 3 (3) (2005) 257–279.
[3] Nicolas Nicolaou, Andrew See, Peng Xie, Jun-Hong Cui, Dario Maggiorini,
Improving the Robustness of Location-Based Routing for Underwater Sensor
Networks, in: Proceedings of MTS/IEEE OCEANS Conference, Aberdeen,
Scotland, June 18–21, 2007.
[4] M. Ayaz et al., A survey on routing techniques in Underwater Wireless Sensor
Networks, Journal of Network and Computer Applications 34 (6) (2011),
doi:10.1016/j.jnca.2011.06.009.
[5] Hai Yan, Zhijie Shi, Jun-Hong Cui, DBR: Depth-based routing for Underwater
Sensor Networks, in: Proceedings of Networking’08, Singapore, May 5–9, 2008.
[6] D. Pompili, T. Melodia, I.F. Akyildiz. A resilient routing algorithm for long-term
applications in Underwater Sensor Networks, in: Proceedings of MedHocNet,
Lipari, Italy, June 2006.
[7] Uichin Lee; P. Wang, Youngtae Noh; L. Vieira, M. Gerla, Jun-Hong Cui, Pressure
Routing for Underwater Sensor Networks, in: INFOCOM, 2010 Proceedings
IEEE, vol. No. (1–9), 14–19 March, 2010.
[8] Chun-Hao Yang; Kuo-Feng Ssu, An energy-efficient routing protocol in
Underwater Sensor Networks, in: Sensing Technology, 2008. ICST 2008, Nov.
30 2008–Dec. 3, 2008.
[9] K. Ali, H. Hassanein, Underwater wireless hybrid sensor networks, in:
Computers and Communications, 2008. ISCC 2008. IEEE Symposium on, vol.
no. (1166–1171) 6–9 July, 2008.
[10] M. Ayaz, A. Abdullah, Low Tang Jung;, Temporary cluster based routing for
Underwater Wireless Sensor Networks, in: Information Technology (ITSim),
2010 International Symposium in, vol. 2, June 2010.
[11] Kai Chen, Yi Zhou, Jianhua He, A localization scheme for Underwater Wireless
Sensor Networks, International Journal of Advanced Science and Technology 4
(2009).
[12] Peng Xie, Jun-Hong Cui, Li Lao, VBF: Vector-Based Forwarding Protocol for
Underwater Sensor Networks, in: Proceedings of IFIP Networking’06, Coimbra,
Portugal, May 15–19, 2006. A longer version is available as UCONN CSE
Technical Report: UbiNet-TR05-03, February 2005.
[13] J.M. Josep, M. Stojanovic, M. Zorzi, 2008. Focused beam routing protocol for
underwater acoustic networks. in: Proceedings of the 3rd ACM international
Workshop on Underwater Networks (San Francisco, California, USA,
September 15–15, 2008). WuWNeT ’08. ACM, New York.
[14] Jinming Chen, Xiaobing Wu, Guihai Chen, REBAR: A Reliable and Energy
Balanced Routing Algorithm for UWSNs, Grid and Cooperative Computing,
2008. GCC ’08. 7th International Conference on, vol. no. (349–355), 24–26 Oct.
2008.
[15] N. Chirdchoo, Wee-Seng Soh, Kee Chaing Chua, Sector-Based Routing with
Destination Location Prediction for Underwater Mobile Networks, in:
Advanced Information Networking and Applications Workshops, 2009.
WAINA ’09. International Conference on, vol. no. (1148–1153), 26–29 May
2009.
[16] Daeyoup Hwang, Dongkyun Kim, DFR: Directional flooding-based routing
protocol for Underwater Sensor Networks, OCEANS 2008, vol. no. (1–7), 15–18
Sept. 2008.
[17] E. Magistretti, Jiejun Kong, Uichin Lee, M. Gerla, P. Bellavista, A. Corradi, A
mobile delay-tolerant approach to long-term energy-efficient Underwater
Sensor Networking, in: Wireless Communications and Networking Conference,
2007. WCNC 2007, March 2007.
[18] Melike Erol, Sema Okug, A localization and routing framework for mobile
Underwater Sensor Networks, in: INFOCOM Workshops 2008, IEEE, 13–18
April 2008.
[19] E.A. Carlson, P.-P. Beaujean, E. An, An improved location-aware routing
protocol for mobile underwater acoustic networks, OCEANS (2007) 1–7.
[20] W.K.G. Seah, ‘‘Multipath Virtual Sink Architecture for Underwater Sensor
Networks, in: Proceedings of the OCEANS 2006 Asia Pacific Conference,
Singapore, 16–19 May, 2006.
[21] Gang Cheng, Nirwan Ansari, Finding a least hop(s) path subject to multiple
additive constraints, Computer Communications 29 (3) (2006) 392–401.
[22] G. Cheng, Nirwan Ansari, Finding all hop(s) shortest path, IEEE
Communications Letters 8 (2) (2004) 122–124.
[23] Zheng Guo, Gioele Colombi, Bing Wang, Jun-Hong Cui, Dario Maggiorini, Gian
Paolo Rossi, Adaptive routing in underwater delay/disruption tolerant sensor
networks, in: Wireless on Demand Network Systems and Services, 2008. 5th
Annual Conference on, Jan 2008.
[24] Seung-Joo Lee, Jung-Il Namgung, Soo-Hyun Park, Efficient UDD Architecture
for Underwater Wireless Acoustic Sensor Network, in: Computational Science
and Engineering, 2009. CSE ’09. International Conference on, vol. No. 2, (972–
977), 29–31 Aug. 2009.
[25] <http://www.hypertextbook.com/facts/2006/HelenLi.shtml>.
[26] K.R. Anupama, A. Sasidharan, S. Vadlamani, A location-based clustering
algorithm for data gathering in 3D Underwater Wireless Sensor Networks,
in: Telecommunications, 2008. IST 2008. International Symposium on, vol. No.
(343–348), 27–28 Aug. 2008.
[27] Josep M. Jornet, M. Stojanovic, Distributed power control for Underwater
Acoustic Networks, in: IEEE Oceans 2008 Conf., 2008, in press.
[28] Ian F. Akyildiz, Dario Pompili, Tommaso Melodia, State of the art in protocol
research for Underwater Acoustic Sensor Networks, WUWNet’ 06, September
25, 2006.
[29] Lanbo Liu, Shengli Zhou, Jun-Hong Cui, Prospects and Problems of Wireless
Communication for Underwater Sensor Networks, Wireless Communications
& Mobile Computing, vol. 8, Issue 8 (October 2008), (977–994).
[30] Jack Wills, Wei Ye, John Heidemann, Low power acoustic modem for Dense
Underwater Sensor Networks, WUWNet’ 06, September 25, 2006.
[31] N. Ansari, Gang Cheng, Nan Wang, Routing-oriented update scheme (ROSE) for
link state updating, IEEE Transactions on Communications 56 (6) (2008) 948–
956.
[32] Jim Partan, Jim Kurose, Brian Neil Levine, A survey of practical issues in
Underwater Networks, WUWNet’ 06, September 25, 2006, Los Angeles,
California, USA.
[33] Gang Cheng, N. Ansari, L. Zhu, Enhancing > approximation algorithms with
the optimal linear scaling factor, IEEE Transactions on Communications 54 (9)
(2006) 1624–1632.