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 UnderwaterWireless Sensor Networks

Muhammad Ayaz ⇑, Azween Abdullah, Ibrahima Faye, Yasir BatiraCIS Department, FAS Department, Universiti Teknologi PETRONAS, Tronoh, Perak, Malaysia

a r t i c l e i n f o a b s t r a c t

Article history:Received 5 December 2010Received in revised form 9 November 2011Accepted 17 November 2011Available online 26 November 2011

Keywords:Dynamic AddressingCourier nodesS-HopIDC-HopIDUnderwater Sensor Networks (USNs)

0140-3664/$ - see front matter � 2011 Elsevier B.V. Adoi:10.1016/j.comcom.2011.11.014

⇑ Corresponding author. Tel.: +60125585903.E-mail address: ayazsharif@hotmail.com (M. Ayaz

Underwater Wireless Sensor Networks (UWSNs) are different in many aspects as compared to terrestrialsensor networks. Other than long propagation delays and high error probability, continuous node move-ment makes it hard to manage the location information of sensor nodes. Determining the location ofevery node is a major issue as nodes can move continuously with the water currents. In order to handlethe problem of large propagation delays and unreliable link quality, many algorithms have been proposedand some of them provide good solutions for these issues, but continuous node movements still needattention. In order to handle the problem of node mobility, we proposed a Hop-by-Hop Dynamic Address-ing Based (H2-DAB) routing protocol, where every node in the network will be assigned a routableaddress in a quick and efficient way without requiring an explicit configuration or any dimensional loca-tion information. It helps to provide an option where nodes can communicate without any centralizedinfrastructure, also a mechanism is available where nodes can come and leave the network without hav-ing any serious effect on the rest of the network. Simulation results show that H2-DAB can manage easilyduring the quick routing changes where node movements are very frequent yet require little or no over-head in order to complete its tasks.

� 2011 Elsevier B.V. All rights reserved.

1. Introduction

A scalable Underwater Wireless Sensor Network (UWSN) pro-vides a promising solution for discovering the aqueous environ-ment efficiently and observing such locations for differentapplications which operates under many important constraints.On one hand, these environments are not feasible for human pres-ence as unpredictable underwater activities, high water pressureand vast areas of water are major reasons for un-manned explora-tion [1,2]. At the same time, localized exploration is better than re-mote for getting more precise results, as remote sensingtechnologies may not be able to find appropriate knowledge aboutthe events that happen in unstable underwater environment.

In fact, UWSNs share many properties with terrestrial sensornetworks such as the large number of nodes and energy issues, stillthese are different in many aspects from the terrestrial sensortechnology. Firstly, radio communications are not suitable for deepwater, so we have to replace this with the acoustic communica-tions. Due to this replacement, available propagation speed isshifted from the speed of light to the speed of sound. Although,acoustic sound travels faster (four times) and longer in water thanin air but yet five order of magnitude slower than electromagnetic

ll rights reserved.

).

waves. Secondly, most of the times, sensor nodes are considered asstatic but underwater sensor nodes can move up to 1–3 m/sec dueto different underwater activities [3]. Thirdly, consumption of en-ergy is different for both types of networks, as underwater nodesare larger in size so they consume more power and the replace-ment of the nodes or even batteries is not so easy. Low data ratesdue to limited bandwidths are also a major problem for such typeof networks. The routing protocols that require higher bandwidths,results in large end-to-end delays and are not suitable for theseenvironments. Although UWSN communications are divided intodifferent categories in terms of bandwidth and ranges, acoustic sig-nals can work even for 5 km, but data rates at such ranges are verysmall and not suitable for real time communications. In short, it ishard 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 dy-namic underwater environments with energy constraint and sud-den topology changes due to some node failures. For thesecircumstances, recently many routing schemes have been pro-posed for UWSNs and among these, most of them require or as-sume special network setups and generally can be divided in twocategories [4]. First, those required special network setups and ex-tra 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 areequipped with pressure or depth sensor, many nodes are anchoredat different depths in throughout the observing area and etc.Arrangements like these are not easily possible for long term appli-cations; in addition when we are interested in large areas then costbecome a major issue. Second category is of geographical basedrouting schemes, those require full dimensional location informa-tion of the network. For the sake of simplicity, most of the proto-cols of this type assume that every node in the network alreadyknows its own location and location of final destination. Assump-tions like these are not so simple because in order to get the local-ization information in UWSNs, we need some extra location awaremethod, which is another research issue left to be solved. Someimportant schemes belong to this category are [12–17]. For com-parison purpose, a short summary of some routing schemes is de-scribed in Table 1.

Contributions: Although, some impressive hop based routingtechniques like [21,22] are available in literature review but it isnot easy to implement them for UWSNs due to different environ-mental characteristics. In this paper, we proposed a novel routingprotocol called Hop-by-Hop Dynamic Addressing Based (H2-DAB) for critical underwater monitoring missions. H2-DAB is scal-able and energy efficient and it will use multi-sink architecture.Surface buoys will be used to collect the data at the surface andsome nodes will be anchored at the bottom. Remaining nodes willbe deployed at different levels from surface to bottom. Nodes nearthe surface sinks will have smaller addresses and these addresseswill increase as the nodes go down towards the bottom. These dy-namic addresses will be assigned with the help of hello packets;those are generated by the surface sinks. Any node which collectsthe information will try to deliver it towards the upper layer nodes

Table 1Short summary of protocols which require special network setups.

Algorithm Requirement/assumption (s)

DBR [5] Every node should be equipped with a depth sensor.Localization

scheme [11](i) Special DET nodes are required, equipped with

an elevator.(ii) Some nodes require anchoring at different

depths and locations in whole area.Localization For

USN [18](i) All nodes must be clocked synchronized.

(ii) GPS communication and Time of Arrival (ToA)method required.

VBF [12] Assumed that full dimensional location information ofwhole network is available.

FBR [13] It is assumed that every node knows its own location.REBAR [14] It is assumed that every node knows its own location

and location of sink.SBR-DLP [15] Every node knows its own location information and pre-

planned movement of destination.DFR [16] All nodes know not only their own location but the

location of one hop neighbors and location of sink aswell.

LASR [19] (i) Accurate timing required for synchronizationand range estimation.

(ii) Network should consist of small number ofnodes; adding new nodes will expand the proto-col header overhead.

Multi-path virtualsink [20]

(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).

UW-HSN [9] (i) Every node should be equipped with both, radioand acoustic modems.

(ii) Every node uses a mechanical module, toemerge and submerge operation.

Resilient routing[6]

(i) Every sensor node is connected with a long wirewhich is anchored at the bottom.

(ii) Sensor should have an electronically controlledengine to adjust the length of the wire.

in a greedily fashion. Packets that reach any one of the sinks will beconsidered as delivered successfully to the final destination asthese buoys have the luxury of radio communications, where theycan communicate with each other at higher bandwidths and lowerpropagation delays. For better resource consumption and to in-crease the reliability, we will use some special nodes called Couriernodes. These Courier nodes will collect the data packets from lowerlayer nodes, especially from the nodes anchored at the bottom andafter collecting will deliver these packets directly to the surfacesinks.

The main advantages of H2-DAB are as follows:

I. Node movements with water currents can be handled easily.II. No need to maintain complex routing tables.

III. It does not require any location information.IV. It will take the advantage of multi-sink architecture (For sin-

gle sink, nodes around the sink entertain large amount ofdata packets, not only it can lead to the problem of conges-tions and data losses but also these nodes can die early dueto frequent energy consumption).

3. Problem statement and network architecture

We are considering the application of underwater oil/gas fieldmonitoring, for this purpose sensor nodes are deployed in thewhole monitoring area in order to collect the information fromthe surroundings. As already mentioned, our protocol based onthe multi-sink architecture, which not only very helpful forincreasing the delivery ratios but also increase the network lifeby decreasing the energy consumption of the nodes around thesink. Surface sinks are equipped with radio and acoustic modems,where RF modems will be used to communicate with each otherand to communicate with the final data processing centre, whileacoustic modems are used to communicate with the sensor nodes.The sensor nodes are deployed at different depth levels with thebuoyancy control [8,23,24]. In horizontal directions, they can movefreely with the water currents but vertically a node may have smallvariations, which can be negligible [3,23].

By doing so, nodes will form layers from the surface to the bot-tom. The numbers of layers depend on the depth of the monitoringarea, and the communication range of the sensor nodes. The aver-age depth of oceans is around 2.5–3 km [25,26], and acoustic com-munication 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 tosurface at the average ocean depths. It is important to note thatthe performance of our protocol does not depend on the numberof layers. The proposed algorithm can support easily more layers,but if we increase the number of layers, it will increase the costof the network as more nodes are required for the same depth. Ifwe decrease these layers as acoustic communications support upto the range of 5 km but it is not preferred as long distance com-munications drain more energy [13,27]. In order to save energyand extend the network life time, we define the acoustic commu-nication range of sensor nodes up to 800 m. It is found that acous-tic communications are considered short range up to the distanceof 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 thissuggested range.

In many applications we are more interested to collect datafrom the nodes anchored at the bottom like oil/gas field monitor-ing; in such applications events occur more frequently at the bot-tom. In order to collect this frequent data from the lower layers in afast way with the involvement of fewer nodes, we prefer the use ofCourier nodes. These special nodes can sense as well as can receive

M. Ayaz et al. / Computer Communications 35 (2012) 475–486 477

the data packets from other ordinary nodes and will deliver it tothe surface sinks directly. These nodes can move vertically, withthe help of a mechanical module, which helps to push the node in-side the water till the node reaches the bottom where it will stopfor a specified amount of time and then pull back to the ocean sur-face. Equipped piston can do this by creating the positive and neg-ative buoyancy. Here one thing should be clear that, these Couriernodes can reach at any place at the bottom and surface. Due towater currents it is not easy to reach any specific place, so weare assuming that any Courier node can reach at any place at thebottom and then it can come back at any area on the surface.

According to the underwater conditions and requirements, themain objectives of H2-DAB routing protocol are as follows.

I. Dynamic address configuration: every node throughout thenetwork can obtain its address dynamically, without theinvolvement of any static or manual configuration.

II. Scalability: our protocol is scalable as its performance doesnot depend on the size of the network.

III. Robustness: H2-DAB is robust as it can adopt the networkchanges easily, where nodes can come or leave the networkwithout making any serious effect on the rest of network.

4. H2-DAB routing protocol

Through extensive literature review, it is found out that under-water routing (forwarding data packets) is not an easy job butgetting and then maintaining location information of sensor nodes

Hello Packet Type S-HopID S

Fig. 1. Surface sink hello

Hello Packet Type C-HopID Courier-ID

Fig. 2. Courier node hello

Fig. 3. Assigning HopIDs with

is more challenging task [4]. For this purpose, H2-DAB completesits task in two phases. In the first phase, route creations are doneby assigning dynamic HopIDs to every ordinary sensor node in thenetwork. In the second phase, data packets are forwarded towardsthe surface sinks by using these HopIDs.

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 dynami-cally, and is changeable with the node movements according tonew locations in the network. The Node-ID is a unique addressfor every node (anchored or not) throughout its life time andthroughout the network.

Every surface sink will have two types of addresses,

� Sink-ID: a unique Sink-ID for every sink, hello packets will usethis 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 twotypes of addresses.

� Node-ID: again a unique Node-ID for all the nodes, it will help torecognize them during inquiries and data packets forwarding(Section 4.5).� HopID:

ink-ID(s) Max. Hop Count

packet (S-hp) format.

Expiry Time Max. Hop Count

packet (C-hp) format.

the help of hello packets.

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-HopIDcan reach a maximum of ‘‘99’’, and each node has this high-est value as the default S-HopID, before receiving the hellopackets. After receiving the hello packet from any sink, it willupdate 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 Couriernodes.

– Courier nodes will use a static HopID ‘‘19’’, and these nodeswill not entertain hello packets. If any Courier node receiveshello packet from any other node of the same type or evenfrom 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 asshown in the Fig. 1. Hello Packet Type will be used to differentiatethe type of hello packet, either it is from the surface sink or fromthe Courier node. S-HopID consists of two digits and shows howmany 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 pri-mary route, as compared to the right hop number, which can beused as a backup route. Sink-ID (s) will be used when every sinkbroadcasts hello packets during the first phase then the Sink-ID willhelp the accepting nodes to differentiate the hello packets, re-ceived from the multiple sinks. Last, the Maximum Hop Count fieldhas a value of 9 at start when sink broadcasts hello packet. Afterreceiving, every node will apply the decrement of one, so whenninth node receives this hello packet, it will make this value zeroand will not forward further to any other node.

Courier node hello packet (C-hp): Hello packets broadcastedby the Courier nodes have five fields as shown in Fig. 2. The first fieldis the same as in the S-hp, which shows the hello packet is from theCourier node. Then C-HopID will consist of the same 2-digit, whichshows that how many hops the receiving nodes are away from theCourier node. Sink-ID is replaced by the Courier-ID of the Couriernode, which has broadcasted it. Next, one extra field with the nameof ‘‘Expiry Time’’ is used, and this new field shows that how long thisCourier node will be available. Every ordinary node which updatestheir C-HopID through these hello packets can forward and deliverdata packets to the Courier node before this expiry time. Then, thepurpose of Maximum Hop Count field is also same as in the surfacesink hello packet, but it has a value of 3 at start instead of 9, so thishello 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 HopIDand ‘‘0000’’ as Sink-ID in routing table, till it has not received anyhello packet. When a node receives the hello packet from any surfacesink, Courier or ordinary node with a minimum power threshold(PTmin), it will start to update its respective HopID. For example, anode receives the hello packet directly from the sink; it will updateits S-HopID as ‘‘19’’. This new S-HopID shows that, this node is onlyone hop away from a sink, and can be 9 hops away from any othersink. After updating, it will forward the S-hp with its newS-HopID. Similarly, the receiving nodes will use the increment ofone in their S-HopIDs, and will forward them towards their neigh-bors, and this will continue till the hop count value of S-hp becomeszero. During this time, if some nodes receive the S-hp from any othersink, 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 receivedthen it will update its S-HopID, only if the arrived packet has smallhop numbers. Otherwise, it will discard it, if so then hello packet willnot broadcast further. This whole process is depicted in Fig. 3. This isfurther clarified by referring to Algorithm 1, for calculating andassigning these HopIDs.

Algorithm 1. Algorithm for assigning the HopIDs with thehelp of hello packets

Hello packets (hp) broadcastsFrom all Sinks (S-hp) with HopID ‘‘N00’’ &

Max Hop Count = 9From all Courier (C-hp) with HopID ‘‘N19’’ &

Max Hop Count = 3//Hello packet received1. If Packet Type = S-hp

Get received S-HopID ‘‘Nrs’’ from S-hpGet own S-HopID ‘‘Npq’’

2. If r = 0 & & SkID(p) – SkID(r) // Existing sinkID – Receiving sink ID

Or r – 0 & & r < p < =s Then3. q p4. p r + 15. else If r – 0 & & r & s < p Then6. p r + 17. q s + 18. else If r > =p & & s < q Then9. q r + 110. Else11. Max Hop Count = 1 // In order to stop

further broadcast12. End If13. End If14. End If15. Max. Hop Count-116. If Max Hop Count > 0 Then17. Update S-hp Own S-HopID18. Broadcast S-hp further19. Else20. No further broadcast for this S-hp21. End If22. End If23. If Packet Type = C-hp

Get Received HopID ‘‘Nm n’’ from C-hpGet Own HopID ‘‘Nx y’’

24. If m < x Then25. x m + 126. Else27. Max Hop Count = 1 // In order to stop further

broadcast28. End If29. Max Hop Count-130. If Max Hop Count > 0 Then

Update C-hp Own C-HopIDBroadcast C-hp further

31. Else32. No further broadcast for this C-hp33. End If34. End If

Similarly, a node can receive hello packet from Courier node(C-hp). The procedure of updating the C-HopIDs from the hellopackets generated by the Courier nodes is simple as compare toS-HopIDs. It will update only in the left hop, and the right side or

Table 2Routing information maintained by an ordinary node.

Node-ID

P Q Sink-ID P

Sink-ID Q

X Y Courier-ID

Courierexpiry

Nexthop

t0 107D 9 9 0000 0000 9 9 0000 N/A Expiret1 107D 1 9 5D87 0000 9 9 0000 N/A 5D87t2 107D 1 6 5D87 8E23 2 9 4BB1 Adaptive 5D87

Source Node-ID

Next Node-ID

Packet Seq. Number

Dest. ID Data …

Fig. 4. H2-DAB data packet format.

M. Ayaz et al. / Computer Communications 35 (2012) 475–486 479

backup hop value will remain the same which is 9. Therefore, thereis no need to check the Node-ID of Courier node before updatingthe C-HopID. If C-HopID of new received C-hp is smaller than itsown then update own C-HopID; if not then discard it simply. Hereone thing is important that why we are not using the backup hopfor Courier nodes, which is due to couple of reasons. First, the pos-sibility of availability of the Courier nodes in a specific region isvery small as one or two Courier nodes can visit a place at the sametime. Secondly, Courier nodes visit for short intervals and thenthese can leave for any other location. For these short intervalsand small Courier nodes, only the primary hop can provides the re-quired results. Every ordinary node will maintain a simple routingtable consists of only one entry, which can be shown in Table 2.

Table 2 gives an idea on how an ordinary node (107D in thisexample) maintains the information about the surface sinks andCourier nodes at different times. The first row provides the statusof routing table at time t0, where first column presents its ownNode-ID. Next four columns maintain the surface sink HopID andthe Sink-IDs from which it has received the hello packets. Similarly,next four columns maintain the C-HopID, the permanent ID of theCourier node and its expiry, which is mentioned in the hello pack-ets. The last column presents the Node-ID of the possible next hop,where current node can forward the data packet. In the caseswhere no node is available as a next hop and it shows ‘‘Expire’’in this column then the current node will follow the Algorithm 2in order to find the next hop. When the current node is able to findthe next hop successfully, then it can store the Node-ID of thatnode in this last column. Remaining two rows, t1 and t2providethe updated status of first row at different time intervals whichcan be possible after receiving the hello packets.

4.4. Data packet format

The data packet format required for the H2-DAB is simple, as itrequires only four fields for control purpose, Source Node-ID, NextNode-ID, Packet Sequence Number and Destination ID, as shown inFig. 4.

Source Node-ID, the node which senses the information will useits Node-ID before forwarding the data packet. Next Node-ID, theNode-ID of a node which considered eligible for next hop amongthe neighbor nodes, usually near the surface sink or Courier node.Packet Sequence Number is a unique number assigned by the sourcenode to every data packet at the time of generation. Destination IDis 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. Asource 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 availablein this area); it will ask its neighbors about their HopIDs with thehelp of a simple ‘‘Inquiry Request’’. This Inquiry contains only theNode-ID of the requesting node. ‘‘Inquiry Reply’’ will be used to re-ply, and it contains only three fields, Node-ID, S-HopID and C-HopIDof replying nodes. Nodes N15, N16, N22, N24 and N25 are in thecommunication range and will reply with their Node-IDs and Ho-pIDs. After receiving, N23 sort out these Inquiry replies and getthe minimum HopID, Min{<N15,55:99>, <N16,56:99>, <N22,67:99>, <N24,66:99>, <N25,78:99>}. As diagram shows, nodes N15and N16 are declared as the candidates for the Next Hop, becauseboth of these have smaller S-HopIDs as compare to S-HopID of thesource node, but N15 wins this competition as its backup link isalso smaller than the N16. The source node will forward the datapacket with N15 Node-ID as a Next Hop. In some cases, if two nodesreply with the same minimum HopIDs, then the node which repliedfirst, will be eligible as next hop. For energy concerns, packets overmultiple short hops are preferred instead of long links [13].

A more general scenario is shown in Fig. 6, which describes howto 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 itsrange so both of these will reply with their HopIDs. C-HopID of itsneighbor nodes shows that Courier node is not available so packetwill be forwarded to the N51 and then N51 will repeat the sameprocedure and it will select N45 as the next hop and it will con-tinue till the data packet reaches the surface sink.

In the second case, N65 also has data packet, so it will ask itsneighbor nodes for their HopIDs. Here N53, N74 and N75 are inits range and will reply their HopIDs. From the replied HopIDs itis clear that Courier node is also available and N75 has smallerC-HopID, so it will be considered as the next hop. After receiving,N75 will repeat the same process and it will continue till datapacket reaches the Courier node ‘‘C1’’ which has ‘‘19’’ as the small-est C-HopID. The process of forwarding the data packets is furtherdescribed in Algorithm 2.

However, it is not possible that every time the source node canget the response from the neighbor nodes with the smaller HopIDs.In cases, when a source node cannot get such response, especiallyin sparse areas then it will wait for a defined amount of time (Sec-tion 4.6) and try again to get the HopIDs. After the third attempt, ifthe result is same, it mean no node is available with smaller Ho-pIDs. Now, it can forward the data packet towards a node on thesame layer with the HopID value nearly or equal to its own HopIDor it can be forwarded towards the lower layer nodes. The reasonwe advocate for trying 3 times in upward direction in our schemeis that we get finer results combining both, delivery ratios and end-to-end delays. In some worst cases, if source node cannot commu-nicate with any other node, then as the last choice, it can removethe restriction of suggested range of 800 m [27,31].

From the earlier scenario it is clear that, delivery ratios forH2-DAB, does not depend completely on the network density orsparseness. Further, we can improve the performance accordingto the nodes densities. If the network is dense, then for simplicitywe can define that, after receiving the Inquiry Request only thenodes with smaller HopIDs than requesting node can reply. If thenetwork is sparse, then all the nodes receiving the Inquiry Requestwill reply.

C-HopID

S-HopID

Node-ID

Fig. 5. Selecting the next hop for the data delivery.

Fig. 6. Selecting the next hop when courier node is available.

Table 3HopIDs of nodes in Fig. 6.

Node-ID S-HopID C-HopID

480 M. Ayaz et al. / Computer Communications 35 (2012) 475–486

Algorithm 2. Forwarding the data packets with the help ofHopIDs

Data packet (dp) ready to send (Either own generated orreceived)

1. If Next Hop – Expire // From last column of routingtable

2. Forward dp to Next Hop3. If Ack. Received = Yes4. If next dp ready = yes5. go to step 16. Else7. wait until dp ready8. End If9. Else10. go to step 1311. End If12. Else13. Request Count for this dp = 014. Request neighbors for HopIDs15. Req. Count + 116. If Current HopID >= dp Source HopID & Request

Count < 3 Then *Discard Inquiry Reply of Source node

17. Replied HopIDs put in arraySort out and get the Minimum of both S-HopID andC-HopID

(Min. S-HopID & Min. C-HopID)18. Else19. Replied HopIDs put in array

Sort out and get the Minimum of both S-HopID andC-HopID

(Min. S-HopID & Min. C-HopID)20. End If21. Compare (Min. S-HopID) & (Min. C-HopID) and

get Smaller(SML-HopID)

22. If Request Count < 4 Then23. If SML. HopID < Own HopID Then24. Next Hop Node-ID of SML. HopID25. go to line 126. Else27. Wait defined amount of time // Section 4.628. go to step 1429. End If30. Else31. Forward dp to Node-ID of SML. HopID, Until

packets in buffer are available32. End If33. End If

*Is current dp received from upper layer? If so then do not considerthe inquiry reply from that source node.

N62 7 8 9 9

N74 8 8 9 9N51 6 7 9 9N45 5 5 9 9N53 6 6 9 9

N65 7 7 9 9

N75 8 9 4 9N77 8 9 3 9N66 7 8 3 9N79 8 9 2 9C1 NA NA 1 9

4.6. Calculating the waiting time

When a source or forwarding node cannot find next hop fromupper layers after the first try then it will make two attempts tosend current data packets towards the upper layers, before sendingthem 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, itwill wait t1 time, depending on the number of nodes replied inthe 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 waitingtime and n1 is the number of neighbor nodes replied in the first in-quiry request.

After the 2nd try, if it still cannot find any node from the upperlayers then it will wait t2 time depending on two parameters’ first,the number of nodes replayed after the 2nd inquiry request andsecond, the difference between the number of nodes in the 1stand 2nd inquiry request. We then get the average of theseparameters.

N68 7 7 2 9N81 8 8 2 9

M. Ayaz et al. / Computer Communications 35 (2012) 475–486 481

t2 ¼C

jn2�n1 jþ1þ Cn2þ1

h i

2ð2Þ

where C is a constant and n2 is the number of neighbor nodes re-plied in the 2nd request. From Eq. (1) and (2) it is clear that, thewaiting time depends on the availability of neighbor nodes and fre-quency of change in them. Both of these parameters are inverselyproportional to the waiting time as waiting time start to decreasewhen any of one or both parameters start to increase.

4.7. Route updating and maintenance

Due to buoyancy control, nodes fluctuate slightly vertically, butstill can move easily in horizontal directions with the water cur-rents. As a result of these movements, a node can change its neigh-bors, both with upper and lower layers. Even the neighbors arecontinued to change, still these addresses can be used as addressof any node will remain smaller from the addresses of lower nodesand larger from the upper nodes. In other words, the address of anynode shows that how many layers or hops have to move in order toreach the water surface, as it is not necessary to reach any specifiedsink because data packets can be delivered to any of these sinks.

As we mentioned earlier in our problem statement that we areconsidering the oil/gas field monitoring application, where most ofthe time the samples of the data are required from time to time.During one interval, the event can be detected and informationdelivered in a short time and then nodes can go to sleeping modeor it can shut down the transceiver till the next sampling intervalin order to save the energy. These sensing and sleeping intervalscan be scheduled according to the situations and requirements ofthe network.

For the next interval, nodes will be assigned new HopIDsaccording to the new locations. These interval based HopIDs cangive better results only when these intervals are not very long. Ifsampling intervals are long then, with the node movements theperformance of the network can decrease with the same HopIDs.However, it is not a serious problem as we can handle such situa-tions easily. For long term missions; these HopIDs have a time prop-erty, which denotes the validity time for them. The larger the HopIDlifetime is, the longer time for which it can continue to work. Whenthe lifetime exceeds the threshold value EXPIRE, the HopIDs will bereset to ‘‘99’’ throughout the network, and again new HopIDs willbe assigned with the help of new hello packets. If any node hasdata packets to be sent before the HopID expiry, then it will waitand can forward these packets after getting the new HopIDs. Afixed life for every interval will not be suitable at different opera-tional conditions. The life time of every interval will be dynamicas it depends on the environment. Determining a good life time,the duration of interval is important for good performance of thenetwork. At one side, getting the new HopIDs in such a way helpsto handle the problem of even small vertical movements, as thenext time nodes will get new HopIDs according to their new posi-tions. At the same time, it makes the buoyancy control more flex-ible, 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 amonitored area A where these nodes have formed layers from sur-face to bottom. Each sensor node has an initial energy level e unitand we consider the energy consumption for data packet as well ascontrol packets like, Inquiry Request and Inquiry Reply. In the sce-nario, only the nodes with smaller HopID will send the Inquiry Re-ply. Both control packets are of same size and consume very littleenergy as compared to data packet. For our model, Ed is the com-plete energy required for forwarding a data packet from one layer

to the other which includes ed, the energy consumed for sendingdata packet and ec, energy consumed for sending the control pack-et. While, Ei?s is the total energy consumed when i data packets areforwarded towards the sink, from i layers (each layer generate onedata packet).

Energy consumption in the networkWe divide the depth into m layers and each layer contains n

number of nodes while total D data packets are generated in thenetwork, where each node generates (D/N) data packets. We usek to present (D/N) data packets. The energy consumption at ithlayer is denoted as Ei and life time of this layer can be representedas Ti, while Ti/n is the life time of each sensor node that belongs tothis layer. All the layers can receive data packets from the belowlayers and forward these as well as their own generated data pack-ets towards upper layers. We assumes that HopIDs are already as-signed as it required only once for long intervals. For simplicity, weare considering the energy consumption during the sending pro-cess. While, energy required for the reception process for Under-water Acoustic Communication is usually 100 times smaller thantransmitting [32,33].

We check the energy consumption with both scenarios, firstwith 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 InquiryRequest and will get also single Inquiry Reply. After that, Node-IDof replying node is saved in the routing table and will be used asa next hop for all the remaining data packets.

For the first time, energy consumption for a single data packetfrom any lower layer to next upper layer is

Ed ¼ 2ec þ ed ð3Þ

where, ‘‘ec + ed’’ is the consumption from current layer which hasdata packet. At first it sends an Inquiry Request and then forwardsthe data packet after receiving the Inquiry Reply. While, the remain-ing ‘‘ec’’ is the consumption from upper layer when a node repliedwith the Inquiry Reply. First we consider the case, when data packetis generated at a node in the first layer and it forwards directly tothe sink ‘‘S’’. After that, similarly, data packet is generated at secondlayer and forwarded towards the sink through the first layer and soon. The effect of energy consumption at each layer can be repre-sented by the following equations,

E1!S ¼ ðec þ edÞE2!S ¼ ð2ec þ 2edÞ þ ðec þ edÞE3!S ¼ ð2ec þ 3edÞ þ ð2ec þ 2edÞ þ ðec þ edÞ

..

.

Em�1!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 atevery layer generates a data packet and total m data packets are for-warded towards the sink. It is clear that, layer 1 processes all m datapackets and due to that it faces maximum energy consumption(2ec + m�ed) than any of the other layer. Layer m has the least energyconsumption (ec + ed) as it processes only one data packet. Now,when k data packets are generated on the same node of each layerthen we can represent Eq. (4) as follows

Em�k!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 becalculated, when it processes its own generated data packets as wellas forward the data packets of all the lower layers.

Ei ¼ ðm� iÞk � ed þ k � ed þ 2ec where i < m

We use q to denote k�ed. Now we can write,

Ei ¼ ðm� iÞqþ qþ 2ec ¼ ðm� iþ 1Þqþ 2ec

From here, life time of layer i can be calculated as

Ti ¼n � e

ðm� iþ 1Þqþ 2ecð6Þ

From Eq. (6), we can get the life time of a node at layer i as below,

Ti=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, forthe worst case when it has to make three Inquiry Requests. Now it ispossible that, no node replies in first two tries and then after the 3rdrequest, all nodes have replied from the upper layer. In such case,‘‘n�ec’’ will be the consumption in the form of Inquiry Replies. Hereit should be clear that we are considering the worst case in termsof energy, but not in terms of node failure.

Again, first we consider the case when the data packet is generatedin the first layer, and then remaining lower layers generate packetsand 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Þ

..

.

Em�1!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 staticnodes. Similarly, when k data packets are generated at one nodeof each layer, then we can represent Eq. (6) as follows

Em�k!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Þ ð9Þ

For worst situations, we consider the case when sensor nodes try toforward 2nd packet after receiving 1st acknowledgment, but for2nd data packet cannot receive it. It makes 2 tries for every datapacket but other than the 1st one, as for 1st data packet, first it willfind the next hop and then can forward it. Now, Eq. (9) can help tocalculate the energy consumption at layer i, where not only it for-wards its own generated data packets but the data packets of lowerlayers 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 (2k�ed � 1) + k�nec + k�3ec. Now we can write,

Ei ¼ ðm� iÞqþ ð2k � ed � 1Þ þ k � 3ec

From here, life time of layer i can be calculated as

Ti ¼n � e

ðm� iÞqþ ð2k � ed� 1Þ þ k � 3ecð10Þ

Similarly, from Eq. (10) we can get the life time of a node at layer ias follows,

Ti=n ¼e

ðm� iÞqþ ð2k � ed� 1Þ þ k � 3ec

Eqs. (6) and (10) shows that, as the value of i increases mean we go atdeeper, the value of q decreases. On the other hand, upper layers facemore energy consumption problem as the number of layers starts toincrease in the network. However, as compare to single sink architec-ture, the possibility of bottleneck occurrence around the sink is de-creased here due to multi sink architecture. For single sinkarchitecture, only a few nodes around the sink process all the datapackets generated in the network, while here this burden is dividedon the whole upper layer instead of few nodes. Furthermore, in orderto reduce this effect, we introduced Courier nodes that collect datapackets directly from the lower layers, so that upper layers processless data packets which ultimately increase the life of the network.

6. Performance Evaluation

In this section, we evaluate the performance of the H2-DABthrough extensive simulations, and we used NS2 for this purpose.We deployed 350 ordinary sensor nodes (some anchored at bot-tom) in a 1500 m � 800 m � 800 m 3D area. The process of datadelivery is completed with the help of 8 layers from bottom to sur-face. Transmission range of sensor nodes can be up to 150 m,where the average depth and width of every layer are defined at100 m, while surface sinks are also deployed at a distance of100 m. The deployment of Courier nodes is optional as our routingprotocol can complete its task without their presence. However, forbetter resource usage, we use small number of Courier nodes as 1%and 2 % of all the sensor nodes. Ordinary sensor nodes can movefreely with the water currents in horizontal direction with 2 and4 m/s and will return back after reaching the defined boundarywhile vertical movements are not considered during the simula-tion. Any node in the network can generate data packet, but thenodes anchored on bottom will generate half of the total data pack-ets generated in the network. The size of the hello packet assumesto be very small as compare to data packet as every hello packetwill consume 1% of the network resources as compare to everydata packet. The power consumption varies for different routingevents; we assume the consumption of 1 energy unit during trans-mission and 0.02 units for receiving the data packet. In order toprevent data collisions, a node can transmit data when no othertransmission detected in its collision domain. The medium accesscontrol (MAC) protocol is based on the IEEE 802.11 and trafficsources are Constant Bit Rate (CBR) with 512 bytes per packet. Atotal of 500 data packets are generated with a rate of 1 packetper second among these 250 packets generated from the nodes an-chored at bottom and remaining half are generated randomly fromthe floating nodes.

6.1. Performance metrics

We use delivery ratios, end to end delays and energy consump-tion as the metrics in order to check the performance of the pro-posed scheme. Delivery Ratio is the total number of data packetsreceived successfully at all the sinks. End to End delays is definedas the average time taken for a data packet in order to reach thesurface sink from the source node. Energy Consumption is defined

M. Ayaz et al. / Computer Communications 35 (2012) 475–486 483

as the total energy consumed throughout the network during allthe routing processes and states like sending, receiving and idling.

6.2. Simulation results

Node Mobility: Fig. 7(a) explains the data delivery ratios at dif-ferent speeds of node movements, while we use three Couriernodes during the simulation setup. As shown in the figure, the datadelivery ratios are 100% with the suggested number of nodes in thenetwork. Even, these delivery ratios are not seriously affected if thenodes density starts to decrease, we can achieve around 95% deliv-ery ratio if 25–35% nodes are not available. If we look at the deliv-ery ratios in the sparse areas, where 50% nodes are not available,we can still receive around 85% data packets at the average nodemovements. Now, if we observe the effect of node movement onthe end to end delays and energy consumption, those are shownin Fig. 7(b) and (c). Here we can observe some difference with nodemobility as compare to static nodes. In the beginning, with densedeployment this difference is minor and then it starts to increasewhen nodes start to decrease but still these differences are nothigh until more than 50% nodes are part of the network.

In general, node mobility has no serious effect on the data deliv-ery and energy consumption, as the minor difference at differentnode speeds. It is due to that, no complex routing tables are goingto be maintained according to the location information of the sen-sor nodes. So, there is no need to manipulate them before any rout-ing decision when even node has changed its position. Every nodecan use its HopID, no matter how far it has moved vertically. Move-ment 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 almostgenerate similar results with different node movements.

Fig. 7. The effect of node moveme

Courier Nodes: As we already mentioned that, H2-DAB cancomplete its task without the presence of any Courier node, butfor reliability concern and better resource utilization we suggestsmall number of Courier nodes. Fig. 8, shows how different numberof Courier nodes helps to increase the overall performance of therouting protocol. In Fig. 8(a), from delivery ratios we can see that,although in dense areas we can achieve high delivery ratios evenwithout Courier nodes, but in sparse areas the presence of Couriernodes can lift these ratios. In such situations these Courier nodeseasily accommodate the deficiency of ordinary sensor nodes. Fromthese results, it’s clear that only 1–2% Courier nodes can providemore than 90% delivery ratios with 50% ordinary sensor nodes

Not only delivery ratios, Courier nodes also help to reduce theoverall energy consumption of ordinary sensor nodes. These Cou-rier nodes collect the data packets from the bottom layers andmove physically in order to deliver these packets to the surfacesinks directly. By doing so, the involvement of ordinary sensornodes decreases, so the cost per packet delivery is decreased whichultimately increase the life of the network.

Offered Load: In order to check the performance of H2-DABwith different offered load, we analyzed the delivery ratios andend-to-end delays by producing more data packets in the network.In normal case, network generates 1 packet per second, but herewe consider the cases where first the network generates 3 packetsin every 2 s and then 2 packets per second. Fig. 9(a) presents thedelivery ratio with different offered load. It shows that with densenodes, the delivery ratios are almost the same and the differencestarts when the number of nodes starts to become sparse. At highoffered load and with fewer nodes in the network, some time anode cannot find next hop and packets start to increase in thebuffer which results in discarding them.

nts on H2-DAB performance.

Fig. 8. The effect of Courier nodes on H2-DAB performance.

484 M. Ayaz et al. / Computer Communications 35 (2012) 475–486

Fig. 9(b) shows the variations in end-to-end delays when weincrease the number of packets in the network. It shows that, thenetwork can handle easily when 50% more packets becomes the partof the network; even these delays are affordable when doublepackets have been generated in the network.

6.3. Comparison with DBR

Many routing schemes require and manage full-dimensionallocation information of the sensor nodes in the network which itselfis a challenge left to be solved for UWSNs. Instead of requiring com-plete localized information, DBR [5] needs only the depth informa-tion of sensor node and packet forwarding decisions are based onthis depth (or pressure) level. When a node has a data packet to besent, it will sense its current depth position relative to the surfaceand place this value in the packet header field ‘‘Depth’’ and thenbroadcast it. Similarly, the entire receiving nodes will calculate theirdepth positions and only those nodes can forward this data packetthat has smaller depth than the value embedded in the packet, andremaining nodes will simply discard it. This process will be repeateduntil the data packet reaches at any of the surface sink. However,DBR has some serious problems as compare to H2-DAB and amongthese two are as follows. First it requires that every node must beequipped with a depth or pressure sensor which not only increasesthe cost of network but also these sensors will be a burden on thelimited node energy. Secondly; DBR cannot handle the problem ofvoid regions in swarm as it is possible that no node can be eligibleas a forwarding node due to greater depth as compared to sending

Fig. 9. The effect of different offered

node; and current node will continue to make more and more at-tempts due to its greedy fashion even some routes are availablethrough higher depth levels.

Further we check the performance of H2-DAB by comparingwith DBR. First, we compare the delivery ratios with single andmultiple sinks in Fig. 10(a). When we use multiple sinks it wasfound that both algorithms provide similar results with dense nodedeployments. However, when nodes start to decrease then deliveryratios for DBR starts to decrease as well, while it has less effect onH2-DAB delivery ratios.

The main reason is that, DBR uses only the greedy mode for dataforwarding and some times when no node found with less depththen it cannot forward even where some nodes are available inthe communication range with higher depths. Further, when weuse single sink which is placed at the centre of surface, then wefind a clearer difference in delivery ratios. Again due to greedymode of DBR, sensor nodes try to send towards the water surfacebut not towards the sink which is placed at the centre of thedeployment area. Here no recovery method is available for DBRand when the nodes in the upper layers broadcast data packetsthen no node can accept because no nodes are available with smal-ler depth and at the same time sinks are not available at thoselocations. Due to this, data packets can be discarded which ulti-mately decrease the delivery ratios.

Further we talk about the end-to-end delays in Fig. 10 (b); hereH2-DAB delivers data packets with less end-to-end delays whenreasonable sensor nodes are available in the deployed area. Forour understanding, it is due to the holding time used in DBR where

load on H2-DAB performance.

Fig. 10. Performance comparison of H2-DAB with DBR.

M. Ayaz et al. / Computer Communications 35 (2012) 475–486 485

all the data packet receiving nodes wait, instead of immediate for-warding in order to check that some other neighboring nodes arealso going to forward the same data packet or not. On the otherhand, when the nodes start to become sparser then delays startto increase for H2-DAB. It is because, with small neighbor nodeswhen a node cannot find a forwarding node with smaller HopIDthen it waits for a defined amount of time before going for 2ndor 3rd try, even it can send towards higher depths in much sparseareas. It results in higher delays when nodes become much sparserbut ultimately it provides better delivery ratios.

Next, Fig. 10(c) shows the comparison of energy consumptionswith different number of sinks. First when we check these con-sumptions with smaller number of nodes then these consumptionsare almost similar for both schemes. When the number of nodesstarts to increase the consumption difference also start to increase.For DBR, it happens due to two reasons. First, DBR uses broadcastfor every data packet and in dense areas after receiving, moreand more nodes go for broadcasting of the same data packet. Sec-ondly, in such areas, when more nodes receive the data packet thenevery receiving node check its depth every time. Due to large num-ber of neighbouring nodes it can receive burst of data packets andin order to decide whether to accept or discard it, receiving nodechecks its depth every time which ultimately drain more and moreenergy. About H2-DAB, it consults the neighbours only when ‘‘NextHop’’ expires or not acknowledged.

The proposed algorithm provides better results in most of thesituations and with different parameters. DBR faces problems inboth situations, as when nodes start to increase then energy con-sumption is high and when nodes start to decrease then deliveryratios are affected with this sparseness. On the other hand, H2-DAB maintain good delivery ratios with small number of nodesand start to improve with controlled energy consumption whennodes start to increase in the area.

7. Important aspects of H2-DAB

Besides the advantages such as low cost and requiring nodimensional location information for task completion, the follow-ing are some important aspects of H2-DAB.

Node movements are easily handled: Vertical node movements arevery common for these networks and as a result, a node canchange its neighbors both with upper and lower layers. Eventhe neighbors are continued to change, these addresses can stillbe used as address of any node will remain smaller from theaddresses of lower nodes and larger from the upper nodes.Nodes lost and found: In H2-DAB, every node has only one entryin each of their routing table. Hence, to add or to delete entrieswhen nodes are lost or added in the network is unnecessary.Newly deployed nodes will obtain their HopIDs at the nextinterval and automatically become a part of the network. H2-DAB is highly adaptive to network dynamics such as nodes join-ing and leaving the network for its reactive hop-by-hop packetrouting mechanism.Node address expiry: H2-DAB allows an auto update of its HopIDupon receiving new hello packets and then forwards the buf-fered packets in the same way just like before the expiry ofthe old HopID. Thus, old packets need not be discarded whenthe address of a node expires.Loop free routing: The occurrence of loops during the routingdecisions, especially during address assignment is commonfor Dynamic Addressing based protocols. However, H2-DAB issensitive and intelligent enough to avoid the occurrence of suchrouting loops.Problem of table size: The growth of the routing table is a seriousproblem 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 oneentry even when the network consists of a large number of nodes.Problem of address space exhaustion: Most of the dynamicaddress assignment schemes used for the ad hoc networks facethe issue of address space exhaustion, but not in H2-DAB, asaddresses will remain of 2 digits per HopID as well as multiplenodes that can use the same address without any problem dur-ing data deliveries.Destination movement flexibility: Some protocols assume thatdestination is fixed and unable to change its location. However,it seems not to be always true due to the water currents. Whilesome other like [15] assumes that destination movement is pre-defined and already known to all the sensor nodes beforelaunching, For H2-DAB, no such assumption is made. All sinkscan move and can still receive data packets easily.Destination address changes: Final destination address for all thesurface sinks is similar and static, so the problem of destinationaddress change during routing decisions does not occur. Addi-tionally, packets can be delivered to any nearest surface sink.Routing decisions without maintaining global knowledge: inter-mediate nodes forward data packets without maintaining glo-bal knowledge of whole network which strongly helps todecrease 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 forUWSNs, based on the local information and current location ofthe sensor node. Novelty of this protocol is that, it does not requirefull dimensional location information, as well as there is no need tomaintain the complex routing tables. We kept the routing over-heads minimum, as available data rates are extremely low forthe UWSN. In this research, we use the idea of per-contact routing,instead of source routing or per-hop routing according to the under-water requirements. An important fact about the H2-DAB is that,the delivery ratios are not seriously based on the density or sparse-ness of sensor nodes. Node mobility due to water currents is a chal-lenge for underwater routing but is handled easily with theproposed protocol. The problem of node failure, which is a majorthreat and possibility for UWSN, is not a serious problem withH2-DAB. New nodes can be added at any time and at any location,and these new nodes can configure easily during next interval. Wecan get good results for long term applications even in vast areaswith large number of nodes, because every node gets its routingaddress despite the network size. In future, we are planning tointegrate H2-DAB with several underwater MAC protocols and toinvestigate the relative performance.

References

[1] J.-H. Cui, J. Kong, M. Gerla, S. Zhou. Challenges: building scalable anddistributed Underwater Wireless Sensor Networks (UWSNs) for aquaticapplications. UCONN CSE Technical Report: UbiNet-TR05-02 (BECAT/CSE-TR-05-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 SensorNetworks, 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 SensorNetworks, 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 UnderwaterSensor 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-termapplications 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, PressureRouting for Underwater Sensor Networks, in: INFOCOM, 2010 ProceedingsIEEE, vol. No. (1–9), 14–19 March, 2010.

[8] Chun-Hao Yang; Kuo-Feng Ssu, An energy-efficient routing protocol inUnderwater 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 forUnderwater 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 WirelessSensor Networks, International Journal of Advanced Science and Technology 4(2009).

[12] Peng Xie, Jun-Hong Cui, Li Lao, VBF: Vector-Based Forwarding Protocol forUnderwater Sensor Networks, in: Proceedings of IFIP Networking’06, Coimbra,Portugal, May 15–19, 2006. A longer version is available as UCONN CSETechnical Report: UbiNet-TR05-03, February 2005.

[13] J.M. Josep, M. Stojanovic, M. Zorzi, 2008. Focused beam routing protocol forunderwater acoustic networks. in: Proceedings of the 3rd ACM internationalWorkshop 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 EnergyBalanced 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 withDestination 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 May2009.

[16] Daeyoup Hwang, Dongkyun Kim, DFR: Directional flooding-based routingprotocol for Underwater Sensor Networks, OCEANS 2008, vol. no. (1–7), 15–18Sept. 2008.

[17] E. Magistretti, Jiejun Kong, Uichin Lee, M. Gerla, P. Bellavista, A. Corradi, Amobile delay-tolerant approach to long-term energy-efficient UnderwaterSensor Networking, in: Wireless Communications and Networking Conference,2007. WCNC 2007, March 2007.

[18] Melike Erol, Sema Okug, A localization and routing framework for mobileUnderwater Sensor Networks, in: INFOCOM Workshops 2008, IEEE, 13–18April 2008.

[19] E.A. Carlson, P.-P. Beaujean, E. An, An improved location-aware routingprotocol for mobile underwater acoustic networks, OCEANS (2007) 1–7.

[20] W.K.G. Seah, ‘‘Multipath Virtual Sink Architecture for Underwater SensorNetworks, 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 multipleadditive constraints, Computer Communications 29 (3) (2006) 392–401.

[22] G. Cheng, Nirwan Ansari, Finding all hop(s) shortest path, IEEECommunications Letters 8 (2) (2004) 122–124.

[23] Zheng Guo, Gioele Colombi, Bing Wang, Jun-Hong Cui, Dario Maggiorini, GianPaolo Rossi, Adaptive routing in underwater delay/disruption tolerant sensornetworks, in: Wireless on Demand Network Systems and Services, 2008. 5thAnnual Conference on, Jan 2008.

[24] Seung-Joo Lee, Jung-Il Namgung, Soo-Hyun Park, Efficient UDD Architecturefor Underwater Wireless Acoustic Sensor Network, in: Computational Scienceand 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 UnderwaterAcoustic Networks, in: IEEE Oceans 2008 Conf., 2008, in press.

[28] Ian F. Akyildiz, Dario Pompili, Tommaso Melodia, State of the art in protocolresearch for Underwater Acoustic Sensor Networks, WUWNet’ 06, September25, 2006.

[29] Lanbo Liu, Shengli Zhou, Jun-Hong Cui, Prospects and Problems of WirelessCommunication 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 DenseUnderwater Sensor Networks, WUWNet’ 06, September 25, 2006.

[31] N. Ansari, Gang Cheng, Nan Wang, Routing-oriented update scheme (ROSE) forlink state updating, IEEE Transactions on Communications 56 (6) (2008) 948–956.

[32] Jim Partan, Jim Kurose, Brian Neil Levine, A survey of practical issues inUnderwater Networks, WUWNet’ 06, September 25, 2006, Los Angeles,California, USA.

[33] Gang Cheng, N. Ansari, L. Zhu, Enhancing � > approximation algorithms withthe optimal linear scaling factor, IEEE Transactions on Communications 54 (9)(2006) 1624–1632.