Routing protocols based on node selection for freely floating underwater wireless sensor networks: a survey

Abstract

Recently, there has been an increasing interest in monitoring and exploring the underwater environment for scientific applications such as oceanographic data collection, marine surveillance, and pollution detection. Underwater acoustic sensor networks (UASN) have been proposed as the enabling technology to observe, map and explore the ocean. Due to the unique characteristics of underwater aquatic environment, which are low bandwidth, long propagation delays, and high energy consumption, the data forwarding process is very difficult. This paper presents a survey of the routing protocols for UASN. The addressed routing protocols are classified from a mobility point of view in freely floating underwater sensor networks. Indeed, managing the mobility of freely floating underwater sensors is one of the most critical constraints in the design of routing protocols. That is why we classify the routing protocols into “reliable data forwarding protocols” and “prediction-based data forwarding protocols.” In the first category, the proposed protocols mainly endure nodes’ mobility by continuously updating location information aiming at delivering the packets to the sink. In the second category, routing protocols try to rather master the nodes’ mobility by predicting the future nodes’ positions either based on a mobility model or on historical nodes’ positions using filtering techniques. We believe that our classification will help not only in deeply understanding the main characteristics of each protocol but also in investigating the evolution of research work evolution to provide energy-efficient data forwarding solutions for freely floating UASN.

1 Introduction

Earth is a water planet that consists of about 71% of water. By the year 2018, according to the National Oceanic and Atmospheric Administration (NOAA), more than 80% of the aquatic environment, whether oceans or seas, is still unexplored, unobserved, and unmapped. Nowadays, there have been increased interests in monitoring and exploring the aquatic environment for scientific exploration, prediction of natural disasters, and coastline protection. The monitoring systems of the aquatic environment are critical for various applications, such as disaster avoidance, oceanographic exploration, marine surveillance, and pollution detection. Underwater sensor networks are the enabling technologies for such applications. Indeed, UASN consist of a number of underwater sensor nodes that are randomly deployed and endowed with sensing, processing, storing, and underwater wireless communication capabilities to gather and capture the condition of the underwater environment. The nodes in UASN are in charge of collecting data packets and sending them from source nodes (sensor nodes which gather and generate the packets) toward the sink node (the node which is connected to data centers) for further processing. UASN undergo various challenges and issues.

Indeed, they have unique and very challenging environmental characteristics, which are poor channel quality, high propagation delay, low bandwidth, high error probability, water current depending on mobility in a 3-dimensional space, and a high packet loss rate [1, 2]. Moreover, energy efficiency is a significant concern that should be carefully addressed in UASN. Indeed, underwater sensor nodes are powered by batteries, which are considerably hard to replace or recharge in harsh underwater circumstances. Additionally, in UASN, the transmission power is 125 times greater than the power required for reception [3]. Consequently, data forwarding protocols are a fundamental key concept, as they have to overcome all the harsh underwater environment features in order to successfully deliver data to the sink. Indeed, these protocols are responsible of dynamically determining a forwarding route from the sensor node toward the sink node, where the data can be processed in a meaningful way. In order to achieve optimum performance, these protocols must be strong against severe underwater channel conditions while considering the energy consumption constraint.

Note that finding an efficient path in UASN would be relatively easy if the underwater sensors were static which is not a realistic scenario. In fact, assuming static nodes will not only reduce the complexity of the problem but also it will allow the adaptation of the efficient routing schemes that were extensively proposed for terrestrial sensor networks. Thus, the mobility of the UASN is one additional severe challenge, as nodes are generally freely floating with the water currents, unless bottom anchored, which may impose the exchange of extensive messages in order to establish a path to the sink in such dynamic topology.

Freely floating underwater sensor nodes move according to water currents, resulting in a highly dynamic network topology. To manage dynamic topology, the existing data forwarding protocols for underwater acoustic sensor networks adopt two approaches. In the first approach, they exclusively focus on the successful delivery of data packets by extensively exchanging notification messages in order to periodically update the routing information, which results in significant communication overhead. In the second approach, they either rely on a predefined mobility model or on past nodes’ positions in order to predict a path to the sink node. Hence, an efficient path can be predicted without exchanging extensive notification messages.

Accordingly, data forwarding protocols in UASN, especially for freely floating underwater sensors, can be classified into two categories. In the first category, works [4,5,6,7,8,9] focus mainly on reliable delivery of the data reports without a specific guarantee on any other additional performance criteria like energy efficiency or reduced end-to-end delay. Indeed, in this category, the main interest was in how to guarantee successful delivery to the sink, no matter what it may cost in terms of energy or delay. In the second category, works [10,11,12,13,14,15,16] tend to take into consideration additional performance metrics by using prediction-based data forwarding protocols, either by relying on a given mobility model [17,18,19,20,21] or by using filtering techniques [22,23,24,25]. Indeed, opting for prediction-based data forwarding protocols allows, most importantly, the design of energy-efficient routing protocols in addition to maximizing the network throughput by mitigating collisions and reducing the end-to-end delay. Furthermore, the use of a given mobility model allows also to achieve high-precision localization.

In this paper, a comprehensive review of data forwarding techniques for UASN is presented. As compared to the existing surveys (depicted in Table 1), we classify the forwarding protocols according to two categories, namely reliable data forwarding protocols and predication-based data forwarding protocols. We want to point out that the main contribution of our survey paper compared to the existing ones is the main idea behind the classification, namely mobility management. Indeed, managing the mobility of freely floating underwater sensors is one of the most critical constraints in the design of routing protocols. That is why we classify the routing protocols into “reliable data forwarding protocols” and “prediction-based data forwarding protocols.” In the first category, the proposed protocols mainly endure nodes’ mobility by continuously updating location information with a main objective of delivering the packets to the sink. In the second category, authors try to rather master the nodes’ mobility by predicting the future nodes’ positions either based on a mobility model or on historical nodes’ positions using filtering techniques. Most of the previous survey papers ignored the mobility management as a main classification idea. They rather build their classification based on which localization information is needed. According to our classification, previous survey papers rather fall within the “reliable data forwarding protocols” category, as they ignore the “prediction-based data forwarding protocols” category. Consequently, they strive to classify reliable data forwarding protocols according to many criteria, such as the need for geographical coordinates, depth-based routing, or vector-based routing. The survey paper in [26] also focuses on the mobility when classifying the routing protocols. However, they ignore the prediction-based data forwarding protocols, where a predefined mobility pattern can be defined, or by using filtering techniques. Our described classification is captured in Fig. 1. An exhaustive and extensive comparative study will then be conducted to evaluate the performance of the described protocols in terms of (I) the next forwarder selection mechanism, (II) the network model hypothesis and characteristics and (III) the addressed performance metrics in selecting a path to the sink.

Table 1 Description of previous related survey papers

Fig. 1

Classification of Data Forwarding protocols for UASN

The remainder of this paper is organized as follows. Section 2 describes the faced challenges in underwater communications. Section 3 presents the routing protocols according to the mobility-based classification. Section 4 conducts a comparison between the previously described protocols. Section 5 concludes the paper.

2 Challenges in underwater communications

UASN are suffering from many issues and challenges, which makes the implementation of routing protocols in underwater environments hard and problematic as compared to terrestrial sensor networks. These challenges require careful attention from academia and the research communities to be overcome. The following sections describe the main challenges in underwater acoustic sensor networks.

2.1 High energy consumption in UASN

Using acoustic waves as a medium of communication in UASN consumes higher energy compared to conventional terrestrial WSNs, which use radio frequency as a medium of communication. More precisely, the transmission energy consumption in UASN is much higher than the receiving energy. Indeed, in underwater acoustic sensor networks, the transmission power is 125 times greater than the power required for reception. Indeed, the transmission power may reach up to $10 W$, while the reception energy is only $0.75 W$[3, 31]. Moreover, underwater sensor nodes are powered by batteries, with a limited energy budget. Battery replacement is not an efficient option in such networks, as batteries cannot be easily replaced or recharged. In such harsh energy constraints, communication protocols must consider energy conservation as one of the most important design parameters. In fact, once the sensors begin to drain their batteries power, the energy holes (dead nodes) begin to appear in the network, which may lead to network partition. Therefore, degradation in the network performance may be observed, which may impede the delivery of data packets to the sink node. Consequently, conceiving an energy-efficient networking protocol that makes judicious use of the node’s energy budget is critical.

2.2 UASN are highly prone to error

Acoustic communication channels in underwater are affected by a number of factors such as noise, path loss, multi-path, and high collision rate [3, 31]. Therefore, UASN communication links are highly prone to errors. In addition, sensor nodes are further vulnerable to corrosion in underwater environments. Thus, underwater sensor networks have a higher rate of node failure compared to their counterparts on land.

2.3 UASN are highly dynamic

Underwater sensor nodes float freely with water currents, with the exception of some nodes that are anchored to the bottom and pushed to the water surface using buoys tied with long rope, which have low or medium stability. Empirical observations show that a freely floating underwater node can travel at a pace of 2–3 knots (or 3–6 km per hour) in a normal underwater environment [32]. This kind of movement may drift apart some nodes which may result in an unstable connection in the network, disrupt the end-to-end paths, and create void regions in the network topology. For this reason, while designing a data forwarding protocol, the freely floating movement nature of nodes must be taken into consideration.

2.4 UASN have limited bandwidth

Acoustic communication is the enabling technology for underwater sensor networks since radio waves do not propagate well in water. Indeed, using high radio waves frequency causes rapid absorption (attenuation) of the signal. Note that absorbing radio frequency (RF) waves is a water property. The rate at which water absorbs the radio waves’ energy for a specific frequency is $45 f \mathrm{dB}/\mathrm{km}$. At very low frequencies in the range of $30-300 \mathrm{Hz}$, the water becomes a conductor of the RF waves. However, the use of this radio frequency range requires high transmit power and a very large antenna size. This requirement is impractical, and therefore, the use of radio frequency as a communication medium in underwater sensor networks is impossible. Using acoustic waves in such a harsh underwater medium allows data to be transmitted only at specific frequencies that depend on the transmission range. The long-range transmissions impose very low bandwidths, while the short-range ones may have high bandwidth. In both cases, the underwater channel impairments impose low bit rates. The transmission range of the underwater networks is inversely proportional to its bandwidth, as shown in Table 2 [1].

Table 2 Available bandwidth for different ranges in UWSNs [1]

Note that, in water, the propagation speed of acoustic signals approximately reaches $1.5 \times {10}^{3} \mathrm{m}/\mathrm{sec}$, which is five orders of magnitude less than the speed of propagation of the radio that approximately equals $3 \times {10}^{8} \mathrm{m}/\mathrm{sec}$. This low propagation speed will result in high propagation delay ($0.67 \mathrm{s}/\mathrm{km}$) that can significantly reduce the throughput of the forwarding protocol in UASN.

2.5 Connectivity void

The connectivity void is one of the major issues that occur if a node which lies on a packet’s path from the sender node to the sink node goes down due to the energy drain. Moreover, in a dynamic UASN environment, the connectivity void may happen when some nodes drift away such that they won’t have an upstream forwarder toward the sink. The connectivity void affects the packet delivery severely during data forwarding, which may lead to packet loss if multiple paths are not explored. A simple solution to deal with connectivity void problem is by increasing the density of the network. However, such a solution is not feasible all the time. Moreover, it cannot entirely eliminate the void problem as the network topology is dynamic. That is why an efficient data forwarding protocol should select the appropriate path that avoids the connectivity voids in order to successfully deliver packets to the sink.

3 Underwater routing protocols

Routing is one of the most critical issues in UASN [28, 33,34,35,36,37,38,39]. The process of developing and implementing UASN routing protocol is difficult and challenging due to the harsh underwater environment, characterized by energy constraints, high error rate, limited bandwidth, long propagation delay and high mobility, especially for freely floating underwater sensors. Therefore, this paper takes these limitations and challenges into consideration in order to analyze the functionalities of routing protocols in freely floating UASN. It is true that some of the papers don’t clearly state that the proposed routing protocol is for freely floating underwater acoustic sensor networks. However, after a deep investigation of every described paper, it is clear that the authors are assuming that routes are continuously changing which is possible only in freely floating underwater acoustic sensor networks. Indeed, in the first category of our classification, “reliable data forwarding protocols,” the authors’ main objective is to find a path to the sink for every transmitted packet, no matter what the network topology is. It is true that the protocols in this category may also work with anchored nodes that have limited movement but they are conceived with the main assumption that sensors are dynamically changing positions. These protocols strive for collecting nodes’ geographical information, such as depth and coordinates, and discovering new neighbors in order to successfully deliver packets to the sink. This information is updated dynamically after a fixed interval of time, as the node’s position may change due to water flow. As for the second category, “prediction-based data forwarding protocol,” authors try to predict a path to the sink in dynamic topology either using a mobility model or the historical positions of nodes. In both cases, nodes are assumed to be continuously moving which may happen only when the nodes are freely floating. Achieving energy efficiency or reduced end-to-end delay is much easier in this category, as it does not require extra packets exchange in order to set a new path for every transmitted packet due to dynamic 3D topology.

One of the major decisions to be taken by the routing strategy in UASN that has a huge impact on the packet delivery ratio and the energy consumption is the selection of the next forwarding node. More precisely, the next forwarding node is generally chosen based on a given selected performance metric to be optimized, like the energy efficiency, the reduced end-to-end delay, etc. Therefore, only the best neighbors, according to the chosen performance metric, will proceed with forwarding data packets toward the sink. In this context, we focus on next-hop selection techniques and challenges. The impact of the selection of the next forwarding node on the performance of routing protocols in UASN is also highlighted. Moreover, in this paper, we will not only focus on the next forwarder selection technique but also on deployment, node mobility, data forwarding, route discovery, and route maintenance.

Our classification, as shown in Fig. 1, is based on two main design goals that affect the performance of data forwarding protocols in UASN, namely I) reliable data forwarding protocols and II) prediction-based data forwarding protocols. Each type is further classified according to the routing strategy or the major parameter(s) it utilizes for routing purposes. The first class deals with the protocols that mainly focus on providing guaranteed delivery of data packets over unreliable UASN [6, 12, 40,41,42]. It is called reliable data forwarding protocols that is further classified into location-based data forwarding protocols and depth-based data forwarding protocols. The second class deals with protocols that predict nodes' future movement patterns and estimate the location and coverage probability for each node without the help of any localization techniques [6, 11, 28, 43,44,45,46]. We called this class predication-based data forwarding protocols which is further classified into data forwarding protocols using mobility model and filter-based data forwarding protocols. The following subsections describe these categories in more details.

3.1 Reliable data forwarding protocols

The “Reliable Data Forwarding Protocols” class focuses mainly on protocols that provide guaranteed delivery of data packets over unreliable UASN by forwarding through multiple paths instead of using one optimal single path [4, 11, 12, 16, 43, 47,48,49]. Indeed, due to the severe constraints of the underwater environment constraints, reliable data forwarding protocols aim at providing reliable delivery rather than optimizing any complementary performance criteria like energy efficiency or throughput. Indeed, in “Reliable Data Forwarding Protocols,” authors’ main objective is to find a path to the sink for every transmitted packet, no matter what the network topology is. Reliable delivery of data has been one of the most challenging research areas in UASN. Indeed, some protocols that claim to provide reliable packet transmission usually seek to reduce the packet loss or error that occurs in hop-by-hop transmission and hence provide an end-to-end connection that is more stable and reliable. The reliable data forwarding protocols class is further divided into two sub-classes, namely location-based data forwarding protocols and depth-based data forwarding protocols. We review work related to the focus of these two subclasses in the following sections.

3.1.1 Location-based data forwarding protocols

This section discusses the protocols that require nodes’ geographic location in order to find a path to the sink node [27, 28, 50, 51]. Indeed, in this category of protocols, it is supposed that each and every node knows its 3D coordinates as well as the ones of the sink node using the Global Positioning System (GPS) [52]. These protocols are used in underwater object tracking applications where it is important to know the exact location of the sensor nodes or any other application that requires the precise location of the sensor nodes. Nonetheless, it is difficult to timely calculate the location information of the sensor nodes as they continuously move with water currents. Knowing and calculating the position information of the sensor nodes is energy consuming. Therefore, these challenges compromise the performance of localization-based data forwarding protocols.

3.1.1.1 Vector-based forwarding protocol (VBF)

VBF is a location-based data-forwarding protocol that was proposed in [53, 54]. VBF addresses the node mobility problem in the underwater sensor nodes and proposes a solution that aims at providing energy efficiency, scalability and robustness. According to VBF, the packet forwarding route is specified by predefining a virtual pipe from the source node to the sink node. In VBF, only nodes within the radius of the virtual pipe participate in the forwarding process of the data packets to the sink node. Indeed, every data packet includes the position information of the source node, forwarder node, and sink node. When a node receives a data packet to be forwarded, it first, it calculates its relative location to the forwarding pipe based on the source node and sink node positions. If it lies within the pipe, it inserts its own computed location in the data packet header, and it proceeds to forward the packet to its one-hop neighbor nodes (the next forwarder nodes); otherwise, it simply discards the data packet. Figure 2 illustrates the process of selecting the next forwarder nodes in the VBF protocol. In fact, in Fig. 2, nodes $({\varvec{A}}, {\varvec{B}}, {\varvec{C}})$ have a data packet to send; therefore, they are source nodes. Consequently, they generate a virtual pipe in the direction of the sink node; the source node adds in the data packet header its own location and the sink node’s location and broadcasts it. Every node receives the packet, calculates its position relative to the source and generates a virtual pipe. If the calculated node position is located inside the virtual pipeline, the node is therefore a candidate to forward the packet. Thus, the node accepts the data packet, updates the header information of the data packet, and then broadcasts the data packet to its one-hop neighbors; otherwise, it drops the packet. The performance of VBF is sensitive to the radius of the virtual pipe, which affects the selection process of the next forwarders. This may have a potential impact on the number of potential forwarders in the virtual pipe from the source node to the sink node. Indeed, in case the radius of the virtual pipe is small, then the number of nodes in the virtual pipe from the source node to the sink node may be limited or even none. Thus, the overall performance of VBF in the underwater network will be degraded. In the other case, if the radius of the virtual pipe is large, then the number of nodes located in the virtual pipe from the source node to the sink may be large, leading thus to further energy loss as many nodes will redundantly forward the data packet.

Fig. 2

An illustration of VBF [52]

3.1.1.2 Hop-by-hop vector-based forwarding protocol (HH-VBF)

In [40], HH-VBF is designed to overcome the VBF performance sensitivity to the radius of the "virtual pipe." Different from VBF, when a node receives a data packet, the receiving node calculates the virtual pipe from itself to the sink node. The process is repeated at each receiving node. So, the forwarding path changes at each intermediate node toward the sink. Figure 3 illustrates the process of selecting the next forwarder nodes in the HH-VBF protocol. In Fig. 3, nodes $({\varvec{A}}, {\varvec{B}}, {\varvec{C}})$ generate their own virtual pipelines. Every source node generates individually a virtual pipe in the direction of the sink node to forward the data packet. When a sensor node receives a data packet, it checks if it is located inside the virtual pipe of the sending node. If so, the sensor node will proceed to create its own virtual pipe to forward the data packet. Therefore, each candidate forwarder node will create its own virtual pipeline to forward the data packet. By doing so, better paths are formed, especially in a sparse network where node densities are quite low. However, re-computing the routing pipe on each hop increases the computational delay and will affect the overall network throughput.

Fig. 3

An illustration of HH-VBF [52]

3.1.1.3 Focused beam routing protocol (FBR)

In [55], the focused beam routing protocol is proposed. FBR uses multiple power levels in order for the sender node to communicate with its neighbors. First, the source node creates a virtual cone from itself in the direction of the sink node to select the next forwarder node. It starts sending a Request-To-Send (RTS) message with the lowest power level. Every receiver node of the RTS message calculates its position to determine if it is located within the cone. If the receiver node position is located within the cone, it replies with a Clear-To-Send (CTS) message and embeds its own location information and node ID. Accordingly, the sender node sends the data packet to neighbors that reply with a CTS message. If no CTS messages have been received, the sender node raises the power level and sends an RTS message until it receives CTS messages from the suitable neighbors. If the sender node reached the maximum power level and there is no response with CTS message, implying that the node is located in a void region. Consequently, the FBR protocol shifts the virtual cone to the right or left to bypass the void region and carry out the communication.

Figure 4 illustrates the process of selecting the next forwarder nodes in the FBR protocol. Accordingly, the source node (${\varvec{A}}$) has a data packet to forward to the node (${\varvec{B}}$). The node (${\varvec{A}}$) will send a request-to-send (RTS) message to its neighbors at the lowest power level (${\varvec{P}}1$). Since no reply messages have been received, node (${\varvec{A}}$) raises the power level to (${\varvec{P}}2$) and again sends (RTS). Node (${\varvec{A}}$) succeeds to reach two candidate nodes (${\varvec{C}}$ and ${\varvec{D}}$) at a power level (${\varvec{P}}2$). Therefore, nodes (${\varvec{C}}$) and (${\varvec{D}}$) send a clear-to-send (CTS) message that contains its own position information and node ID in addition to the addresses of the destination and source (${\varvec{B}}$ and ${\varvec{A}}$). If there is no collision, the source node (${\varvec{A}}$) receives both (CTS) messages from (${\varvec{C}}$ and ${\varvec{D}}$). After that node (${\varvec{A}}$) chooses to forward the data packet to node (${\varvec{D}}$). Node (${\varvec{C}}$) will overhear the transmission of the data packet and drop the data packet from its queue since it has not been selected as a next forwarder node.

Fig. 4

An illustration of FBR [55]

3.1.2 Depth-based data forwarding protocols

This section discusses the protocols that require only depth information in order to forward a packet to the sink instead of the three-dimensional coordinates used by the location-based data forwarding protocols. In fact, in the depth-based data forwarding protocols class, the selection of the next forwarding node toward the sink is from bottom to top, which means that a shallower node is selected as the forwarder. Thus, from a given water depth to a shallower one, this process is continuously repeated in a hop-by-hop manner until the data packet ends up reaching the water surface where the sink is located [52, 56,57,58]. These protocols preserve the energy and save the delay spent in the calculation of the sensor nodes position.

3.1.2.1 Depth-based routing protocol (DBR).

In [41], DBR, a depth-based data forwarding protocol, is proposed. DBR main idea is based on comparing the forwarder depth with the sender depth in order to decide whether to forward the data packet or not. In other words, the selection of the next forwarder node relies mainly on its depth. Indeed, if the next forwarder depth is less than the current forwarder depth, then the next forwarder will proceed to send the data packet. This protocol starts with the source node broadcasting the data packet with its own depth value embedded in the packet header to all its one-hop neighbors. Each receiver neighbor node compares the depth of the previous forwarder node with its own depth. If the receiver neighbor node is closer in terms of depth to the sink destination node (node located on the water surface), then the neighbor comprehends that it is a potential forwarder of the received data packet. In order to avoid forwarding the same data packet by many nodes, DBR uses a hold timer. Accordingly, every potential forwarder refrains from the immediate transmission of the data packet. The hold-timer depends on the difference between the sender node depth and the potential forwarder depth. Therefore, the shallower the node is (closest to the water surface), the shorter the hold timer will be. After the expiration of the hold timer, the potential forwarder will proceed to forward the data packet if it does not receive from other nodes the same data packet. If so, it will drop the data packet. The DBR is a hop-by-hop process to reach the sink node. Despite its robustness, DBR does not provide the selection of an optimal single next forwarder node and suffers from a redundant packet in the network, which may rapidly drain the energy budget of the sensor. Consequently, nodes die shortly and create communication holes in the network, which creates a void area problem. The void area problem is where the forwarder node finds itself at the local maximum with a shallower depth to the sink node but with no potential forwarder to reach the sink. Figure 5 illustrates the process of selecting the next forwarder nodes in the DBR protocol. DBR protocol starts with the source node (${\varvec{S}}$) broadcasting to its one-hop neighbors, the data packet with the depth information embedded in the header. After the nodes (${\varvec{n}}1$, ${\varvec{n}}2$, ${\varvec{n}}3$) receive the data packet, each node compares the sender’s node (${\varvec{S}}$) depth with its own depth. The nodes (${\varvec{n}}1$, ${\varvec{n}}2$) will be a potential forwarder of the packet because their depth location is closer to the water surface than the sender node (${\varvec{S}}$) depth location. While the node (${\varvec{n}}3$) drops the data packet because its depth location is deeper than the sender node (${\varvec{S}}$) depth location. Consequently, the node (${\varvec{n}}1$) broadcast the received data packet, with its own depth information embedded in the packet header, to its one-hop neighbor nodes. Note that, (${\varvec{n}}1$) will proceed to forward first since the hold timer depends on ${\varvec{d}}1$ (the distance between ${\varvec{n}}1$ and ${\varvec{S}}$). Therefore, node (${\varvec{n}}2$) will drop the data packet since it overhears it from the node (${\varvec{n}}1$).

Fig. 5

An illustration of DBR [41]

3.1.2.2 Hydraulic pressure-based anycast routing protocol (HydroCast)

In [42], HydroCast, a depth-based data forwarding protocol for reliable underwater sensor networks is proposed. HydroCast forwards the data packets toward the sink node on the water surface depending on the depth location. The HydroCast operation consists of two modes: the greedy mode and the void handling mode. The greedy mode is responsible for selecting a set of next forwarder candidate nodes. At first, every receiving node computes an Expected Packet Advance (EPA), which is a link quality metric in order to select a subset of candidate nodes that can better reach the sink node. After that, the best nodes are arranged based on their priorities, which reflect how close they are to the sink node. The highest priority goes to the sensor nodes on or closer to the water surface. The source node broadcasts the data packet with a list of the neighbor's IDs. The nodes receive the data packet and check if their own ID is on the list. If the receiver node ID is on the list, it calculates a holding time based on their depth information and proceeds to send the data packet after the expiration of the holding time. Otherwise, if the receiver node ID is not included in the list, it drops the data packet.

During the void handling mode, each local maximum node has a node that has more depth than itself as a recovery route, so a packet can be routed out of the void area and can turn back to the greedy mode. Figure 6 illustrates the process of selecting the next forwarder nodes in the HydroCast protocol. In Fig. 6, the node (${\varvec{L}}{\varvec{M}}1$) is located in a void area and it is a local maximum node due to the absence of a shallower node. In order to avoid the void area, the node (${\varvec{L}}{\varvec{M}}1$) will forward the data packet to the node (${\varvec{L}}{\varvec{M}}2$) which is a shallower node through a deeper node. Node (${\varvec{L}}{\varvec{M}}2$) is also located in a void area, and it is a local maximum node. Consequently, the node (${\varvec{L}}{\varvec{M}}2$) discovers a route to the node (${\varvec{S}}$) and forwards the data packet through its route. The node (${\varvec{S}}$) is a non-void node so using the greedy mode it can forward the data packet to a shallower node and ultimately to the sink node.

Fig. 6

The void handling mode in HydroCast [42]

3.1.2.3 Void-aware pressure routing protocol (VAPR)

In [59], VAPR protocol was conceived to address and handle carefully the main problem in depth-based routing protocols in UWSNs, which is the void area. The void area problem occurs when a packet reaches a node with no candidate forwarder in the direction of the final destination, which may have a dramatic effect on decreasing the packet delivery ratio. VAPR consists of two main stages, enhanced beaconing and opportunistic directional data forwarding. In the first stage called enhanced beaconing, the sink node on the surface sends periodically a beacon message to all the underwater nodes with four variables information: the sender’s depth location, hop count to the sink, data forwarding direction to the sink, and a sequence number. When a node receives the beacon message from predecessors, every node modifies its information based on depth information and the minimum hop to sink. Accordingly, it updates the minimum number of hops to the sink, the data forwarding direction, the sequence number, and the next-hop data forwarding direction to match the current network. Once done, the receiving node updates and propagates the beacon message. Every node repeats the process until all the nodes in the network updates their variables information. Figure 7 illustrates an example of the enhanced beacon process of VAPR protocol. Figure 7, after the timer has expired, the sink (sonobuoy) initializes a beacon message and then broadcasts the beacon message with the sequence number, depth, hop count equal zero and data forwarding direction equal up. The beacon is received by node ${\varvec{a}}$ and its state is set (for example, seq num = 0 with incremented hop count (${\varvec{a}}$(= 1. Node ${\varvec{a}}$ sets DF_dir (${\varvec{a}}$) as up, and NDF_dir (${\varvec{a}}$) as up, by comparing the depth. Node ${\varvec{a}}$ will broadcast an updated beacon, and node ${\varvec{b}}$ will execute a similar process, which will be continued. Later, node ${\varvec{x}}$ receives a beacon message from node ${\varvec{b}}$; it then changes DF_dir (${\varvec{x}}$) as down depending on the difference in depth and NDF_dir (${\varvec{x}}$) as DF_dir (${\varvec{b}}$) = up. An updated beacon message will be broadcast by node ${\varvec{x}}$. After this, node ${\varvec{y}}$ receives the beacon message where the changes are revealed in a beacon message and will maintain DF_dir (${\varvec{y}}$) and NDF_dir (${\varvec{y}}$) as down-down. Nodes can set up a set of directional trails toward any one of the sinks on the basis of this beacon propagation and upgrade process.

Fig. 7

Enhanced beacon [59]

In Fig. 8, for example, node ${\varvec{i}}$ receives beacon messages from two nodes in a different direction (from ${\varvec{h}}$ and ${\varvec{j}}$). Node ${\varvec{i}}$ chooses the node with the forwarding direction that is closer to sink by comparing the hop counts (down in this case). In case of a tie of both hop counts, it deterministically sets the data forwarding direction as up.

Fig. 8

Beacon receptions in both directions (node $i$). [59]

In the second stage, called opportunistic directional data forwarding, the forwarding process of the data packet is only depends on the data forwarding direction, and the next-hop data forwarding direction. More precisely, when a sensor node has data to send, it sends the data packet either up or down based on the data forwarding direction.

After that, it checks the receiving node’s data forwarding direction if it matches the next-hop data forwarding direction of the forwarder node then it will proceed with the sending process if it does not match then it drops the data packet. Figure 9 illustrates an example of the opportunistic directional data forwarding process of VAPR protocol. The sensor nodes (${\varvec{a}}$, ${\varvec{b}}$, ${\varvec{x}}$) are forming the V-shape topology. The node (${\varvec{x}}$) will ultimately deliver the data packets to the node (${\varvec{z}}$) which is a local maximum. The DF_dir (data forwarding direction) and NDF_dir (next-hop data forwarding direction) of nodes (${\varvec{a}}$, ${\varvec{b}}$) are up-up, while the node (${\varvec{x}}$) is down-up. For example, node (${\varvec{b}}$) has data to be forwarded. The node (${\varvec{b}}$) DF_dir is up so, the node (${\varvec{b}}$) will consider sensor nodes whose depth is less in order to reach the sink node on the water surface, which in this case are nodes (${\varvec{a}}$, ${\varvec{x}}$). Since the (${\varvec{x}}$) node DF_dir is (down) which does not match with the node (${\varvec{b}}$) NDF_dir (up). Therefore, only node (${\varvec{a}}$) is considered as the next forwarding candidate for node (${\varvec{b}}$). In (VAPR) the main disadvantage is in the enhanced beaconing stage where the beacon needs to be sent periodically and in a short time to update the variable but due to the dynamic environment of the UWSNs, which will increase the energy consumption and the network overhead.

Fig. 9

The Opportunistic Directional Data Forwarding [59]

3.2 Prediction-based data forwarding protocols

Due to the highly dynamic nature of UASN, a balance between the reliability and efficiency of data transmission by choosing a relatively reliable and stable transmission route to minimize the link breakage is clearly very necessary. This section discusses the protocols that predict nodes' future movement patterns due to the tides, ocean currents and other environmental forces that help to estimate and calculate the location and coverage probability for each node without the help of any localization technique. Node movement prediction techniques help predicting the candidate forwarder’s locations, calculating their coverage probability in order to select the next hop forwarder [41, 60, 61]. These protocols, as opposed to the previous ones, aim at selecting a single path to the sink in order to achieve much better energy efficiency and network throughput.

3.2.1 Mobility model-based data forwarding protocols

In the underwater environment, the network topology is continuously varying due to node mobility with respect to water currents and water pressure [26, 62, 63]. Accordingly, an underwater mobility model can be used to predict the future movement modality and pattern of sensor nodes and to estimate the probability of their coverage [41]. These protocols capitalize on the mobility model of the sensor nodes in the forwarding data process. The mobility model of the nodes helps this kind of protocols predicting and selecting the right candidate forwarder toward the sink [28, 32, 64,65,66].

3.2.1.1 Movement predicted data forwarding protocol (MPDF).

In [67], the Movement Predicted Data Forwarding protocol is proposed. In MPDF protocol, every node estimates its own location, its coverage probability and predicts its future movement pattern in the absence of any localization technique. In fact, each node estimates its location by calculating its displacement from its original (initial) anchored location. In the MPDF protocol, each candidate forwarder calculates three parameters: link reachability, uplink transmission reliability, and coverage probability. When the node’s timer expires and it has packets to send, the source node $({\varvec{i}})$ broadcasts a “Request” message to its one-hop node neighbors then each one-hop neighbor $({\varvec{j}})$ sends a “Reply” message to the node $({\varvec{i}})$ with its estimated new location. After receiving the “Reply” message, the node $({\varvec{i}})$ computes the coverage probability that indicates whether or not the forwarder $({\varvec{j}})$ is in the sender node $({\varvec{i}})$ coverage range. Every candidate forwarder node also inserts its uplink transmission reliability in the “Reply” message, which is measured by the number of data packets sent by node $({\varvec{i}})$ and successfully forwarded by the forwarder $({\varvec{j}})$. Moreover, $({\varvec{j}})$ includes its link reachability to the destination\sink in the “Reply” message which is measured by the number of minimum known hop count to reach the sink. The neighbor with the highest coverage probability, the best uplink transmission reliability, and the best link reachability will be selected as next hop forwarder. MPDF suffers from routing overhead especially when the number of source nodes increases. Recall that for each data packet and at every hop, “Request” and “Reply” messages have to be exchanged between neighbors’ nodes. MPDF requires exchanging multiple notification messages at each hop to select the next forwarder node which will consume high energy.

3.2.1.2 Sidewinder protocol

In [68], Sidewinder, a prediction-based data forwarding protocol for underwater wireless sensor networks, is proposed. According to sidewinder, the data packets are forwarded in the direction of the sink node with growing precision as the data packet approaches the sink node. The sidewinder architecture for the multi-hop prediction forwarding functionality is accomplished by joining four modules: Mobility Monitor, Adaptive Update, Sequential Monte Carlo (SMC) Prediction and Limited Flooding. In the first module, the Mobility Monitor measures the individual nodes’ mobility based on the location history. In the sidewinder, a sink node is responsible for updating its location and mobility behavior through the adaptive update model. Accordingly, the sink update frequency decreases as the number of hops from the sink increases. Thus, nodes farther from the sink receive fewer updates as they only need an approximate idea of the sink location. In the second module, the Adaptive Update updates the SMC Prediction module with the sink location and mobility behavior information of the underwater network. The purpose of the SMC Prediction module is to estimate the present sink location by combining the previous hop in the routing path estimated sink location with the estimated sink location of the current forwarder hop. The SMC consists of four stages in order: initialization, prediction, filtering, and resampling. In the initialization phase, the source node generates $N$ possible sink locations based on the last received sink update. The source node’s neighbors who lie in the specified $60^\circ$ forwarding zone who received the forwarded data are candidates for the next hop forwarding. In the prediction phase, the next-hop forwarder node combines the previous node generated $N$ sink locations with its own last update of the sink location to predict the current sink location. The filtering phase allows the next-hop forwarder to exclude impossible sink locations after combining the previous hop and sink location with its own estimated ones. In the last phase, the resampling phase replaces those excluded sink locations in the filtering phase with new potential sink locations based on its own estimated sink location information and proceeds to forward the packet. In the limited flooding, the sink one-hop neighbors have the latest update and forward the packet to their two-hop away neighbors to guarantee the packet delivery to the sink even if the sink location changes due to the water current.

Figure 10 illustrates the process of selecting the next forwarder nodes in the Sidewinder protocol. In Fig. 8, the source node $({\varvec{A}})$ has a data packet to send to the sink node. Hence, in its estimated sink area (big, dashed circle), included in the $60^\circ$ forwarding area, $\left({\varvec{A}}\right)$ generates 8 possible sink locations (small white circle). After forwarding the packet to $({\varvec{F}})$. The next forwarder node $({\varvec{F}})$, overlap areas of $({\varvec{A}})$’s with its own prediction area, and creates a new estimated sink area (big solid circle), in the $60^\circ$ forwarding area, $({\varvec{F}})$ generates 8 possible sink locations (small gray circle), then the process will be repeated until the packet reaches the sink. However, sidewinder suffers from significant energy consumption due to the forwarding of a redundant copy of the same data packet through multiple paths to reach the sink node.

Fig. 10

An illustration of Sidewinder [68]

3.2.1.3 Space–time–energy-based forwarding protocol (STE)

In [69], a space–time–energy-based forwarding protocol (STE) is proposed. STE considers the node's location, transmission latency, and energy consumption to select the best path from the source node to the sink node. The STE protocol first selects the forwarders with dominance in both the spatial dimension and the time dimension to identify several paths from the source to the sink. Then, it assigns a probability to each path. The probability is based on the nodes' residual energy in each path. Every time a node has a packet to be sent to the sink, one of the paths is randomly chosen based on the computed probabilities. The STE protocol is divided into three phases: The first two phases aim at choosing a forwarder with a spatial dimension and a time dimension, and the third phase chooses a path with an energy-related probability. The first phase, called the Spatial Angle, tries to choose a forwarder that is closer to the sink and farther away from the sender. In the second phase called the Time Angle, the protocol takes into consideration the current real-time condition of the network by forwarding only to the neighbors further away that have lower transmission latency. Once the first and second phases are done, the best forwarders in both the time and space dimensions are selected. In the third and final phase, the Energy Angle phase, the protocol elects the final best forwarder based on the highest residual energy of nodes to ensure the energy effectiveness of the protocol. Therefore, the STE protocol selects the final forwarder which has the highest forwarding probability, which means the forwarder with the highest residual energy and the nearest to the destination. The STE protocol has a high packet delivery ratio and energy efficiency because it chooses the forwarders with higher residual energy and farther away from the sender toward the destination. However, the STE protocol suffers from higher transmission delay due to the calculation load in space, time, and energy aspects for the forwarding candidates. Therefore, STE is not suitable for real-time networks in which the nodes' processing time has to be short as the network conditions are rapidly changing.

3.2.1.4 Hop-by-Hop dynamic addressing-based routing protocol (H2-DAB)

In [6], the Hop-by-Hop Dynamic Addressing-Based routing protocol is proposed. H2-DAB takes advantage of the multiple-sink architecture, where water buoys will be used as sinks to collect the data at the water surface, and some nodes will be anchored to the bottom. Other sensor nodes will be deployed at different levels, from the surface to the bottom, and will be freely floating in the network. There are two phases in H2-DAB to complete the task of delivering the packets to one of the sinks. In the first phase, called Addressing Scheme, a path is created by assigning the dynamic HopIDs to every floating node in the network. In the second phase called, Data Packet Forwarding the packet is delivered using the assigned HopIDs. Note that every surface sink will have two types of addresses, namely, I) Sink ID: a unique ID for every sink and II) DestID: a static ID that equals $"0"$, which is the same for all the sinks. Similarly, the freely floating sensor nodes will use two types of addresses namely, I) Node ID: a unique ID only for floating nodes and II) HopID: with a default value of $"99"$, that is updated after receiving the Hello packets, according to the node location. However, the anchored nodes will have a unique address which, is a static HopID that is set to $"100"$. During the network initialization, a Hello packet will be broadcast from every sink in order to update the HopID of the floating nodes. Hello packet consists of three fields, Sink ID, HopID, and Maximum Hop Count. The Sink ID will allow the floating nodes to discern the closest sink as they collect Hello packets from multiple sinks. The HopID consists of a two-digit ID where every digit indicates the number of hops to a given sink. For example, a HopID of $"28"$ means that this floating node is 2 hops away from one sink and 8 hops away from another one. The left hop number has more priority and will be considered as a primary path as opposed to the right hop number that can be used as a secondary path. Maximum Hop Count field has a default value of 10 that is set when the sink broadcasts Hello packet. Then every node will decrement the count by one and broadcasts the updated Hello packet. So, if it reaches the value zero, the Hello packets are discarded and will not be further forwarded to any other nodes or it reaches an anchored node where it will be discarded. As mentioned before, the default HopID of the freely floating sensor is set to $"99"$ till the node receives a Hello packet. At that time, if the received HopID in Hello packet is less than 9, then the node will start the update if its own HopID. For example, if a node receives the Hello packet, directly from the sink, it will update its HopID as $"19"$. This means that the node is only one hop away from a sink and can be 9 hops away from some other sink. After that, the node will broadcast the updated Hello packet with its new HopID. If a node receives the Hello packet from other sinks, the node first checks the HopID. If it's less than the left hop number, then it will update its left hop. Otherwise, it will check its right hop number (used as a backup) for a possible update.

Figure 11 demonstrates the addressing scheme process where the hop ID of node ${\varvec{N}}16$ is equal to 45, which indicates that its hop distance from one sink is equal to 4, while its distance to another sink is equal to 5.

Fig. 11

H2-DAB addressing technique [52]

In the data packet forwarding phase, the protocol selects the path to the sink based on the HopID. In Fig. 12, node ${\varvec{N}}7$ with HopID $"66"$ has a data packet to send. The node ${\varvec{N}}7$ will send a Request packet to its neighbors with its own Node ID to request the HopID of its neighbors. The neighbors will send a reply packet that contains Node ID and HopID. Nodes ${\varvec{N}}4$, ${\varvec{N}}5$, ${\varvec{N}}6$, ${\varvec{N}}8,$ and ${\varvec{N}}9$ are in the communication range and will send a reply packet, with their Node IDs and HopID’s. Based on the HopIDs, node ${\varvec{N}}4$ and ${\varvec{N}}5$ are declared as next hop forwarder candidates, due to the values of their left hop numbers. However, ${\varvec{N}}4$ is selected to be the Next Hop forwarder because of its backup link shorter number of hops than the one of ${\varvec{N}}5$. The H2-DAB has a high delivery ratio with lower delays and more energy conservation. Nevertheless, it suffers from severe routing overhead due to the need to broadcast the Hello packets to select dynamically the best next hop forwarder that changes frequently due to nodes’ movement.

Fig. 12

The H2-DAB selecting the Next Hop [6]

3.2.1.5 Mobility prediction optimal data forwarding for freely floating underwater acoustic sensor networks (MPODF)

In this protocol [70], the MPODF underwater routing protocol is proposed. MPODF is a mobility prediction-based routing protocol. Accordingly, every source node wishing to send a packet to the Sink will first start by determining the optimal future best path to the final destination. Indeed, using the mobility model of the underwater environment, the source node can predict its future neighbors as well as the neighbors of each one of its neighbors in the farther future and so on until all possible paths are determined. Once done, the source node will apply the highest minimum remaining energy as a criterion to select the best path to the destination. Although the computational cost of MPODF is high, it is highly energy efficient as the source node will succeed to predict a whole reliable path to the Sink without any extra packets exchange among nodes to set a path and most importantly without sending multiple copies through different paths to guarantee successful reception by a mobile Sink in a dynamic environment.

3.2.2 Filter-based data forwarding protocols

This section discusses the protocols that use filtering techniques in order to estimate future events, like the contact probability with a given node, based on historical event information. The filtering techniques allow a forwarding node to use previous historical events in order to predict future events (such as the probability of meeting a given node) and hence select accordingly the best next forwarder. As opposed to the previous mobility-based models, the filtering-based data forwarding protocols rather assume that the node mobility model is completely unknown. That is why, by using a spatial and temporal correlation between previous events, they aim to acquire an exact estimation of future events.

3.2.2.1 Q-learning-based delay tolerant routing protocol (QDTR)

Proposed in [71], the QDTR protocol is a single-copy data forwarding protocol that depends on precise predictions to select the preferred next forwarder node. Consequently, QDTR mobility prediction is not based on an assumed mobility model but rather on the timely spatial and temporal correlations manifested through node movement patterns. This is accomplished, using the adaptive filter. Hence, it helps to use these correlations of node movement patterns to make the best decisions. QDTR is based on Q-learning which is a distributed machine learning technique. The Q-learning is able to learn and predict the next node contact and make the data forwarding decisions which are whether forward data packets to the present neighbor node in contact or wait for the next neighbor node in contact. QDTR consists of two phases: the contact predictor and the forwarder. The contact predictor phase continuously monitors underwater node, and based on an adaptive filter, it predicts future contact events. Once accomplished, the contact predictor phase provides estimated future node contact and future node contact probabilities with neighbors. The forwarder phase determines whether or not to forward the data packets to the encountered neighbor based on the contact predictor phase information. The Q-learning process is based on machine learning which takes data forwarding decisions by assessing the total reward of a state-action pair. The data forwarding decisions have two actions: either FORWARD that forwards the data packet to the current encountered node or HOLD where the data packet will wait for the next node to be encountered. For both possible actions, QDTR evaluates the rewards of the two actions in order to make the optimal decision. QDTR protocol sends regular DATA packets and BEACON messages. The BEACON messages are sent continuously by every sensor node in the underwater network for two purposes: I) exchanging meta-data and II) neighbor discovery. For example, when node ${\varvec{A}}$ and ${\varvec{B}}$ encounter each other, first they exchange the meta-data consisting of the reward of the forwarding action and get the reward of holding action for the next encountered node and the ID of the next encountered node from the local contact predictor. Then QDTR chooses one suitable action between FORWARD or HOLD. Despite its robustness, QDTR broadcasts multiple beacon packets for the purpose of neighbor discoveries that result in high energy consumption.

3.2.2.2 Opportunistic forwarding algorithm based on irregular mobility protocol (OFAIM)

As proposed in paper [72], the main idea of the Opportunistic Forwarding Algorithm based on Irregular Mobility (OFAIM) protocol is based on computing the contact probability and choosing the appropriate route from the source-to-sink node to forward the data packet at a specific time slot. OFAIM is a greedy algorithm that tries to acquire a high delivery ratio within a restricted propagation delay while largely reducing the message cost. The data forwarding process is a compromise between costs and algorithm objectives by selecting dynamic routes with the highest delivery probability, which are calculated according to the node’s current status at every slot. According to OFAIM, a data packet generated by a given source node will be routed hop-by-hop dynamically until it is delivered to the sink. Each intermediate node, called a data holder by OFAIM, will proceed to forward the data packet according to the following steps. In tth slot time, each intermediate node holding a data packet generated by a source node broadcasts a notification message that includes a quintuple value (node ID, time slot, coordinates of the node at the ${t}^{th}$ slot, the maximum movement range of the node, and the maximum communication range of the node). When a node receives this notification message the contacting probability will be computed. Indeed, suppose at time slot $t$, node (${\varvec{i}}$) has data to be forwarded to sink node, node (${\varvec{i}}$) searches for K paths with the largest contacting probability by running Dijkstra’s algorithm. In fact, node (${\varvec{i}}$) selects K next neighbor nodes with the K highest contacting probabilities and then sends searching messages to inform them. This process will be continued until the sink is found. After that, the sink sends a notification message to the node (${\varvec{i}}$) along the K paths that have been discovered from the previous step. During the current $t$ slot, node (${\varvec{i}}$) forwards the data packet through the computed K paths. In every time slot, the computation of paths and data packet forwarding will be a recurrent process until the sink receives the data packet. In Fig. 13 at the tth time slot, there are three nodes ($1$, $3,$ and $5$) that have data to be forwarded, nodes ($1$, $5$) discover paths to the sink and forward the data during the same slot. At the end of the tth slot, the data packet from the node ($1$) will be forwarded to node ($12$) and the data packet from node ($5$) will be forwarded to the node ($19$). However, the node ($3$) did not find a route to the sink node; therefore, the data packet has not been forwarded to any node. At the next ${(t+1)}^{th}$ slot, due to the dynamic underwater environment, all sensor nodes have moved from their time tth slot positions, and current nodes that hold the data packet are ($3$, $12,$ and $19$) will recompute the paths to the sink by repeating the process. OFAIM requires recalculations of dynamic paths at every slot, with the transmission of multiple copies of the same data packets through multiple paths that raise energy consumption and propagation delay. OFAIM requires exchanging multiple notification messages at each hop which will further consume energy.

Fig. 13

Demonstration of OFAIM Execution [72]

4 Comparing between data forwarding protocols for underwater wireless sensor networks (UWSNs)

In this section, we will start by summarizing the addressed routing protocols. For this purpose, we provide Table 3 that contains the publication year, complexity, the routing strategy, assumptions and expected outcome of all the above-described data forwarding protocols for underwater wireless sensor networks. On the other hand, Tables 4, 5, 6 and 7 are designed to compare between those protocols according to different criteria in order to have comprehensive comparative overview according to different dimensions.

Table 3 Data forwarding protocols’ advantages and disadvantages

Table 4 Data Forwarding Protocols’ selecting mechanism

Table 5 Data Forwarding Protocols’ selecting mechanism

Table 6 Data Forwarding Protocols’ Characteristics

Table 7 Data Forwarding Protocols’ Performance Metrics

4.1 Comparing the advantages and disadvantages of data forwarding protocols in underwater wireless sensor networks

In this section, we will assess the advantages and disadvantages of the previously mentioned data forwarding protocols for underwater wireless sensor networks is summarized in Table 4.

4.2 Selection techniques of the next forwarder

In this section, we compare the previously described data forwarding protocols in UASN according to the next forwarder selection techniques. The comparison between the data forwarding protocols in UASN is summarized in Table 5.

The meaning of each column is clarified as follows.

• Selection parameters: rubric highlights the key metrics utilized in the existing routing protocol to select the next forwarding nodes.

• Neighbors’ selection strategy: rubric points out the selection mechanism of all the potential next forwarder candidates [73].

• Forwarder selection strategy: this rubric highlights how the protocols select the best forwarder among the previously chosen potential forwarding candidates based on a well-defined performance metric [73].

Comparison of Data Forwarding Protocols Based on selected Characteristics.

This section provides a concise recap of the fundamental characteristics of all the previously described protocols. Table 6 shows the different characteristics of data forwarding protocols in UASN according to the following criteria.

•: Needed Location information: this rubric points out if the protocol requires any location information.

•Single/Multiple Sink: this rubric highlights the number of deployed sinks in the protocol scenario.

•. Hop-by-hop / end-to-end:

• “End-to-end” means that data forwarding such as the selection of the forwarding nodes and the delivery of the data packet are all handled between the ultimate endpoints, not at intermediate nodes.

• “Hop-by-hop” is the opposite point-of-view, where each intermediate node along the path to the sink should handle the selection of the next forwarding nodes by forwarding to the most suitable adjacent nodes.

• Notification message: this rubric indicates if the protocol exchanges any notification messages.

• Void-aware: the void area is one of the critical problems in data forwarding protocols for UASN due to the dynamic and sparse nature of underwater sensor network topology which may cause a low packet delivery ratio. Void area problem occurs when a data forwarder node finds itself at an impasse to relay the data packet due to the absence of a node in its neighborhood. This rubric points out if a given protocol is overcoming the void area problem.

• Redundant copies of data packet this rubric highlights the number of duplicate copies of the same data packet each protocol forwards at each step.

• Sender/receiver-based forwarding decision The hop-by-hop forwarding decision in a sender-based protocol is exclusively taken by the forwarder node in order to choose the best next hop forwarder among all its candidates. Indeed, when a node receives a data packet, it forwards the packet to the best chosen one among its candidate neighbors. However, in a receiver-based protocol, the forwarding decision is solely taken by the receiver node. In other words, the forwarder node will proceed forwarding the packets to all the next forwarder candidates, and then, it is up to the next hop forwarder to decide to forward the data packet or drop it.

4.3 Comparison of data forwarding protocols based on performance metrics

This section provides a comparison of the previously described data forwarding protocols based on the performance metrics shown in Table 7. The protocols are compared based on the performance evaluation section of every protocol, as well as the comparative study provided in the survey papers [73] and this is how we derive Table 7. Please note that in the survey paper [26] published in 2017, an analytical and simulation-based comparison is provided among all described protocols within the paper under the same simulation setting which was helpful to fill Table 7.

The explanation of each rubric is presented in the following.

• Data delivery ratio represents the ratio of data packets that were successfully received by the sink node to the total number of data packets generated by all the source nodes [73].

• Average delay efficiency measures the average end-to-end delay for the successfully received packets from the generation time at the source node until the reception at the sink node [73].

• Energy efficiency measures the total amount of consumed energy per node to forward the packet until the reception by the sink node including all the exchanged notification messages [73].

Selecting the best next forwarding nodes is a major issue in routing protocols that have a direct impact on overall routing performance, such as network lifetime, energy consumption, and packet delivery ratio. As shown in Fig. 1, we classify the data forwarding protocol into reliable data forwarding protocols and prediction-based data forwarding protocols. The reliable data forwarding protocols consist of the location-based protocols that use the location information of the sending node and the sink to select the best forwarding node. The depth-based data forwarding protocols did not fully use location information, as they only require the depth information for selecting the next forwarding nodes during the routing process to forward a packet to the sink. This reliable data forwarding protocols solution is not efficient to use in UASN due to the cost of using localization and the lack of GPS.

The prediction-based data forwarding protocols as opposed to the previous ones aim at selecting a single path to the sink in order to achieve a much better network lifetime, energy efficiency, and network throughput. The prediction-based data forwarding protocols consist of Mobility Model and Filter-based data forwarding protocols. The Mobility Model-based data forwarding protocols capitalize on the mobility model to predict the sensor nodes' movement in order to select the right candidate forwarders toward the sink. As opposed to the previous mobility-based models, the filtering-based data forwarding protocols rather assume that the node mobility model is completely unknown. Hence, they opt for using the previous historical meeting events to acquire an exact estimation of future meeting events to choose the best next forwarder toward the sink.

As a conclusion, freely floating underwater acoustic sensor networks impose serious challenges to deliver packets to the sink, as the network is continuously dynamic. Moreover, opting for multiple copies transmission through multiple paths may lead to high energy consumption, and hence, the network lifetime may be constrained. We strongly recommend the use of prediction-based data forwarding protocols for freely floating underwater acoustic sensor networks. If the mobility model cannot be clearly stated as the underwater environment mobility is unpredictable, we recommend filter-based data forwarding since future positions will be estimated thanks to the past ones. If, however, the mobility model can be studied and modeled beforehand then mobility-based data forwarding is preferred as it guarantees higher accuracy of the optimal energy efficient path to the sink. That being said, mobility-based data forwarding protocols suffer from high computational overhead. As future research directions, we highly recommend conceiving algorithms to reduce the complexity of finding the bast path in data forwarding protocols that uses a mobility pattern of the underwater environment in order to predict the path to the sink. As a straightforward solution, we recommend combining filter-based and prediction-based techniques. Indeed, if the dynamicity of the underwater environment is relatively low, we can use the mobility prediction model every period of time while filter-based techniques are used during the period. In other words, a source node wishing to send a packet for the first time will use the mobility-based algorithm. Once done, the filter-based algorithm will be applied till the next round of running the mobility-based algorithm. By assuming small topology modifications during a round, filter-based algorithms are more energy efficient. In this direction, determining the optimal round duration that depends on the network dynamic speed is possible. Future research that can help optimally finding a path to the sink that maximizes the network lifetime.

5 Conclusions

One of the fundamental issues in the design of routing protocols is the selection of the next forwarding nodes. This problem stimulates researchers to design effective and efficient methods of selecting of the next forwarding node. Indeed, the next hop-forwarding techniques help to explain the routing operation of the protocols. In this paper, based on the forwarding techniques, we classified the routing protocols into two classes: reliable data forwarding protocols and prediction-based data forwarding protocols. Every protocol is described in terms of its routing strategy, merit(s) and demerit(s). Each routing protocol is carefully analyzed to evaluate its performance in terms of I) the next forwarder selection mechanism, II) the network model hypothesis and characteristics and III) the addressed performance metrics in selecting a path to the sink. We strongly believe that our classification will help the researcher community propose more efficient data forwarding solutions for freely floating UASN.