UCMAC: A Cooperative MAC Protocol for Underwater Wireless ... - MDPI

sensors Article

UCMAC: A Cooperative MAC Protocol for Underwater Wireless Sensor Networks Hee-won Kim 1 , Tae Ho Im 2 and Ho-Shin Cho 1, * 1 2

*

School of Electronics Engineering, Kyungpook National University, Daegu 41566, Korea; [email protected] Oceanic IT Convergence Technology Research Center, Hoseo University, Asan 31499, Korea; [email protected] Correspondence: [email protected]; Tel.: +82-53-950-7577

Received: 21 May 2018; Accepted: 19 June 2018; Published: 19 June 2018

Abstract: This paper proposes a cooperative medium access control (MAC) protocol for underwater wireless sensor networks (UWSNs) named UCMAC, which fundamentally benefits from cooperative communication. In UCMAC, a source identifies cooperators and provides its destination with a list of the cooperators while also delineating their proximity to the destination. For erroneous reception of data packets, the destination then requests retransmission to the cooperators in a closest-one-first manner. A designated cooperator transmits the buffered data packet it has successfully overheard from the source or other cooperators. A signaling procedure and the various waiting times of the nodes are carefully designed to address the overheads that stem from cooperation. Through computer simulation, this paper evaluates UCMAC in terms of system throughput, latency, single-hop packet delivery ratio (PDR), and energy efficiency. The results show that UCMAC performs better than existing schemes, including MACA-U and CD-MACA. Keywords: underwater wireless sensor network; automatic repeat request; medium access control; cooperative communication; spatial diversity; cooperative region; cooperative ARQ; cooperative MAC

1. Introduction In recent years, researchers have actively studied numerous applications of underwater wireless sensor networks (UWSNs), including tactical surveillance, disaster prevention, and oceanographic observation [1]. In particular, studies have proposed an array of medium access control (MAC) protocols to enable communicating nodes to access the shared underwater channel. Compared to terrestrial radio signals, underwater acoustic signals suffer from high attenuation, long propagation delays, severe multipath fading, and high bit error rates (BER) in the channel. Achieving reliable delivery of data packets under such poor channel conditions necessitates the use of the automatic repeat request (ARQ) and/or the forward error correction (FEC) techniques at the link layer. Traditionally, ARQ methods are divided into three categories: stop-and-wait (S&W), go-back-n (GBN), and selective repeat (SR) [2]. In the S&W method, a transmitter waits for an acknowledgement (ACK) from a receiver after transmitting a data packet and then retransmits the data packet if it fails to receive the ACK. Many existing MAC protocols for the UWSNs [3–5] employ the S&W method due to its simplicity and suitability for half-duplex channels. However, long propagation delays in the acoustic signals make the S&W method inefficient because the sender’s lengthy waiting time wastes resources. In the GBN and SR methods, on the other hand, senders can transmit data packets continuously while waiting for receivers’ ACKs. This can increase network throughput at the expense of receiver processing complexity, but it requires the full-duplex system for concurrent delivery of ACK packets, which has yet to prove workable in the bandwidth-limited underwater channel. Another new Sensors 2018, 18, 1969; doi:10.3390/s18061969

www.mdpi.com/journal/sensors

Sensors 2018, 18, 2018, 196918, x FOR PEER REVIEW Sensors

2 of 17

2 of 17

Another new approach is the so-called cooperative ARQ, which is based on the cooperative

approach is the so-called cooperative based on the cooperative communication technique. communication technique. TheARQ, basic which idea ofisthe cooperative communication technique is that neighbor (cooperators) can provide an alternative path for otherneighbor pairs of communicating nodes The basic idea ofnodes the cooperative communication technique is that nodes (cooperators) can (source–destination), as shown in Figure 1. This generates spatial diversity by enabling the provide an alternative path for other pairs of communicating nodes (source–destination), as shown in transmission of independent copies of the signal, thus allowing independently faded versions of the Figure 1. This generates spatial diversity by enabling the transmission of independent copies of the signal at the destination [6]. signal, thus allowing independently faded versions of the signal at the destination [6].

Neighbor

Source Destination Neighbor

Figure Cooperative communication. Figure 1. 1. Cooperative communication.

Earlier research on cooperative communication—mainly conducted in the terrestrial domain—

Earlier research on cooperative communication—mainly conductedtheory in theand terrestrial domain—focused focused on issues such as theoretical analysis based on information its implementation Such analyses led to based the creation of link layer protocols to gain benefits by coordinating on issuesaspects such [7,8]. as theoretical analysis on information theory and its implementation aspects [7,8]. nodes thereafter. Some studies [9,10] proposed a cooperative ARQ scheme that simply describes Such analyses led to the creation of link layer protocols to gain benefits by coordinating nodesthe thereafter. behavior of proposed the nodesafor cooperative retransmission, performance using their own Some studies [9,10] cooperative ARQ scheme that analyzing simply describes the behavior of the nodes for analysis model, while others [11–21] proposed a so-called cooperative MAC protocol that mostly combines cooperative retransmission, analyzing performance using their own analysis model, while others [11–21] the cooperative ARQ mechanism with the MAC protocol. Depending on the cooperative mechanism, proposed so-called cooperative MAC that mostly combines the cooperative ARQ mechanism theacooperative MAC protocols can protocol be categorized as a proactive type, a reactive type, or a hybrid type. In with theproactive-type MAC protocol. Depending on theprocess cooperative mechanism, the cooperative protocols protocols, the cooperation mostly starts before a destination receivesMAC an initial data packet from a source, type, whereas reactive-type are type. an on-demand method where the can be categorized as a proactive a reactive type,protocols or a hybrid In proactive-type protocols, the destination requests cooperation only when it fails to receive the data packet. A major problem with cooperation process mostly starts before a destination receives an initial data packet from a source, is that cooperators may send a redundant data packet to the destination even whereasproactive-type reactive-typeprotocols protocols are an on-demand method where the destination requests cooperation when the destination succeeds in receiving the initial packet from the source. This redundancy leads to only when it fails to receive the data packet. A major problem with proactive-type protocols is that a waste of energy but can decrease delay with a high chance of successful destination decoding. On the cooperators a redundant data packet to energy the destination even succeeds othermay hand,send the reactive-type protocols can save at the expense ofwhen delay. the Bothdestination features of the in receiving the and initial packet from thecombine source.to form Thishybrid-type redundancy leads to a waste of energy but proactivereactive-type protocols protocols. MAC protocols for terrestrial wireless networks are largely based on the can decreaseExisting delay cooperative with a high chance of successful destination decoding. On the other hand, the distributed coordination function (DCF) of the IEEE 802.11 standard [22], known as carrier sense reactive-type protocols can save energy at the expense of delay. Both features of the proactiveand multiple access with collision avoidance (CSMA/CA). In addition, for cooperator selection, these reactive-type protocols combine to form hybrid-type protocols. protocols largely rely on channel state information (CSI) between nodes. However, due to intrinsic Existing MAC protocols forchannel terrestrial networks arework largely channelcooperative characteristics and ever-changing states,wireless these protocols do not wellbased in the on the distributed coordination function (DCF) of the IEEE 802.11 standard [22], known as carrier underwater environment. In other words, utilizing the carrier sensing technique and keeping the CSI sense neighboring nodes up to date(CSMA/CA). in the underwater are difficult. Until now, relevant these multiplebetween accessall with collision avoidance In channel addition, for cooperator selection, research has taken account such constraints (CSI) to dealbetween with several important issuesdue such protocols largely rely on into channel state information nodes. However, toas intrinsic cooperative signaling strategies [23], criteria for best cooperator selection [24–26] and cooperative channel characteristics and ever-changing channel states, these protocols do not work well in the routing protocols [27,28]. To the best of our knowledge, however, researchers have not yet actively underwater environment. In other words, utilizing the carrier sensing technique and keeping the examined the cooperative MAC protocol in the underwater channel. Unlike the terrestrial case, CSI between all neighboring nodes upso-called to datespace–time in the underwater channel difficult. Until now, underwater networking suffers from uncertainty problem dueare to intrinsic channel relevantcharacteristic research has taken into account such constraints to deal with several important issues of the long propagation delay [29]. The space–time uncertainty opens up new aspect on such packet collision in the underwater channel, this is irrelevantselection to terrestrial networks the as cooperative signaling strategies [23], criteriawhereas for best cooperator [24–26] and as cooperative delay is To negligibly small and can be ignored.however, Therefore,researchers we are motivated devise routing propagation protocols [27,28]. the best of our knowledge, havetonot yet aactively examined the cooperative MAC protocol in the underwater channel. Unlike the terrestrial case, underwater networking suffers from so-called space–time uncertainty problem due to intrinsic channel characteristic of the long propagation delay [29]. The space–time uncertainty opens up new aspect on packet collision in the underwater channel, whereas this is irrelevant to terrestrial networks as the propagation delay is negligibly small and can be ignored. Therefore, we are motivated to devise a novel underwater-specific cooperative MAC protocol that can perform efficiently even with the space–time uncertainty.

Sensors 2018, 18, 1969

3 of 17

Based on our previous work [30,31], we propose a reactive-type cooperative MAC protocol for the UWSNs, named Underwater Cooperative MAC (UCMAC). A source identifies cooperators and provides the destination with a list of cooperators along with information about their proximity to the destination. For erroneous reception of data packets, the destination then requests retransmission to the cooperators in a closest-one-first manner. A designated cooperator transmits the buffered data packet stored just in case to the destination. If no available cooperators exist, UCMAC follows the conventional MACA-U protocol [32] that basically uses 3-way handshaking (RTS–CTS–DATA) and optionally adds ACK without cooperation process. We evaluate the proposed scheme in terms of system throughput, latency, single-hop packet delivery ratio (PDR), and energy efficiency, comparing it to MACA-U and CD-MACA [12]. The novelty of this paper lies in the design of signaling procedure and in the calculation of the appropriate timer lengths of nodes to benefit from the cooperative diversity gains while overcoming the space–time uncertainty problem in the underwater channel. Also, we escape potential collisions between cooperators by making them cooperate one at a time and define a cooperative region to involve only qualified cooperators in cooperation process. The remainder of this paper is organized as follows: in Section 2, we review some related work. After describing a system model in Section 3, we explain how the UCMAC works in Section 4. Section 5 analyzes UCMAC’s performance through computer simulation. Finally, we conclude the paper by presenting additional work in Section 6. 2. Related Work Previous studies have proposed many cooperative MAC protocols for terrestrial wireless networks. In [14], Liu et al. presented a proactive type of the cooperative MAC protocol called CoopMAC. Based on the capability of rate adaptation at the physical (PHY) layer, a low-rate source first decides whether data forwarding through a high-rate cooperator (source–cooperator–destination) reduces delay compared to direct transmission (source–destination). Then, the source invokes the cooperative mode instead of the IEEE 802.11 protocol only if doing so could decrease the delay. The point is that each node should overhear all transmissions and continuously update a neighbor table in which the rate information of all neighbors is stored. Because this would be demanding in the changeable underwater channel, UCMAC simply uses propagation delay information instead of keeping the table. In addition, CoopMAC uses the S&W ARQ, which means that the destination does not request any cooperation from the cooperators when it fails to receive a data packet. A reactive-type protocol, cooperative diversity–multiple access with collision avoidance (CD-MACA), was proposed in [12]. In CD-MACA, cooperators buffer overheard data and then transmit it to a destination when overhearing a clear-to-send (CTS) packet that corresponds to the data. This gives the destination more chances to successfully decode its received data packet with independent samples. However, in the underwater channel where carrier sensing is less effective, such diversity gain may not be obtained because of packet collision among the data packets transmitted by the source and the cooperators. Another issue is that even the nodes that have inferior channel qualities to the destination cooperate. For efficient cooperation, cooperator selection criteria should be considered. Note that, in CoopMAC, the cooperator through which a minimum delay occurs is selected as the sole cooperator. To alleviate the need to identify the best cooperator each time the source transmits data, persistent relay CSMA (PRCSMA) [15] enables a set of the most appropriate nodes near to the destination to become cooperators. If the destination fails in decoding a data packet, the cooperators persistently retransmit data packets until the destination succeeds or the cooperation phase ends. However, loss of ACK packets forces the cooperators to continue sending the data packets even after the destination’s successful decoding. Moreover, they know whether to cooperate or not only after receiving a claim-for-cooperate (CFC) packet transmitted by the destination, which makes all neighbors of the source store overheard data in their memory banks. UCMAC eliminates these redundancies by requesting the retransmission from the cooperators one at a time and defining a cooperative region where nodes cooperate. The

Sensors 2018, 18, 1969

4 of 17

authors have also proposed DQCOOP [17], which is based on their previous work, DQCA [33] and its different version, DQMAN [34]. In DQCOOP, the contention window is divided into slots so that each cooperator randomly selects one slot for the channel access. Then the destination feeds information of access success or failure back to the cooperators, which retransmit their data packets accordingly. This can prevent data packet collision, but every node must be tightly synchronized and maintain special queues and variables. UCMAC requires neither time synchronization nor special queues and variables. In [19], Antonopulous et al. proposed a network coding-based cooperative MAC protocol named NCCARQ-MAC that applies network coding technique at the MAC layer perspective. Similar to CD-MACA, every node keeps a copy of all data packets overheard in preparation for cooperation. In NCCARQ-MAC, a destination piggybacks its data (if it exists) on a request-for-cooperation (RFC) packet transmitted to request retransmission of the source’s data. Then a cooperator creates a network coded-packet with the source’s and destination’s data packets and then transmits it to the source and the destination, which allows them to obtain the respective data quickly. Taking into account the impact of PHY layer, the performance of NCCARQ-MAC is further investigated and analyzed under realistic channel conditions, especially for correlated shadowing [20,21]. In that context, network coding technique contributes to increase in network throughput when bidirectional traffic is dominantly generated. Such technique may be inefficient in sensor networks where unidirectional traffic dominates. Reference [16] proposed a hybrid-type cooperative MAC protocol where both of the proactive and the reactive mechanisms are applied. Graded back-off time that depends on a maximum achievable rate makes only the highest-rate cooperator cooperate alone (proactive). If data packet decoding is unsuccessful, the destination sends a negative ACK (NACK) packet to its source and/or the cooperator to request data retransmission (reactive). Prior to the retransmission, handshake of request-to-send (RTS) and CTS packets is performed again. In the UCMAC, a cooperator directly retransmits a data packet eliminating this handshaking procedure to reduce delay. Meanwhile, existing related work for the underwater wireless networks has dealt with several important issues other than MAC layer ones. In [23], Han et al. proposed a new signaling method called wave cooperative (WC) transmission where a cooperator immediately amplifies and forwards source signals whenever their multipath components pass through. The WC method can outperform existing methods such as the amplify-and-forward (AF) and the decode-and-forward (DF) because a destination can receive high strength multipath components in less time. Reference [24] developed a best-relay (or cooperator) selection criterion, called cooperative best relay assessment (COBRA) to select best cooperators under the varying underwater channel. Rather than using the CSI, the COBRA relies on propagation delays between any pair of nodes in the network and statistical channel parameters when selecting the best cooperator. The researchers in [24] briefly mentioned a methodology for MAC based on RTS–CTS handshaking and the COBRA criterion. Clearly, it is necessary for the cooperative MAC protocols to utilize the RTS–CTS handshaking procedure in acquiring and/or sharing cooperator information. 3. System Description We assume that all nodes, which are equivalent in terms of capability and physical specification, are fixed on the seabed without timing synchronization and that they acquire propagation delay information from/to one-hop-distance neighbors through network initialization [35]. In addition, the nodes configure a distributed and partially connected mesh topology where they are connected to their one-hop distance neighbors. Each node can communicate directly with any of its one-hop distance neighbor. Regarding the means of cooperation, the DF signaling strategy [6] is applied, and a cooperator selectively joins the retransmission of erroneous packets as a replacement of source. We also assume that bit errors happen only in the data payload, not in control messages such as header and control packets, which are much smaller than the payload. In regard to the channel model, the empirical underwater acoustic channel model [36] is considered, which is in wide use in the literature. In this model, the underwater channel is characterized by attenuation that increases with

Sensors 2018, 2018, 18, 18, x1969 Sensors FOR PEER REVIEW

of 17 17 55 of

frequency, noise of which power spectral density decays with the frequency, and signal-to-noise ratio signal frequency, noise of which power spectral density decays with the frequency, and signal-to-noise (SNR) that varies over the signal bandwidth, etc. ratio (SNR) that varies over the signal bandwidth, etc. 4. 4. Operation Operation of of Proposed Proposed Protocol Protocol Figure illustratesa abasic basic UCMAC procedure with cooperators ( C1 Cand C ) that are Figure 22 illustrates UCMAC procedure with twotwo cooperators (C1 and 2 ) that 2are located located between the source (S) and destination (D). UCMAC consists of two phases, channel reservation between the source (S) and destination (D). UCMAC consists of two phases, channel reservation and and data transfer. In the channel reservation phase, the source reserves the channel and identifies data transfer. In the channel reservation phase, the source reserves the channel and identifies the the cooperators cooperators through through their their control control packet packet responses. responses. In In the the data data transfer transfer phase, phase, the the source source transmits transmits aa data of cooperators cooperators sequenced data packet packet (DATA) (DATA) attaching attaching aa list list of sequenced by by closeness closeness to to the the destination. destination. Then, Then, referring to the list, the destination requests retransmission of erroneous packets to cooperators in referring to the list, the destination requests retransmission of erroneous packets to cooperators in the the closest-one-first manner. Meanwhile, the cooperators store the data packet (denoted by xDATA closest-one-first manner. Meanwhile, the cooperators store the data packet (denoted by xDATA in in Figure 2) that is overheard during source’s transmission. parameters carried by packets Figure 2) that is overheard during thethe source’s transmission. TheThe parameters carried by packets are are denoted inside speech bubbles as shown in Figure 2 and the details along with time parameters denoted inside speech bubbles as shown in Figure 2 and the details along with time parameters like like w_ACK w_DATA are explained in corresponding the corresponding subsections. Table 1 defines some of w_ACK and and w_DATA are explained in the subsections. Table 1 defines some of the the parameters in advance to make it easier to understand subsequent sections. parameters in advance to make it easier to understand subsequent sections. Channel reservation phase ℕneg , τS,D

τC1 ,D

τC2 ,D

Data transfer phase

ℕcoop

τD,H Delay

Source (S)

w_CTS

w_ACK d_DATA

Back off Cooperator 1 (C1 )

w_DATA

w_ACK

Erroneous

Back off Cooperator 2 (C2)

w_DATA

w_ACK

Erroneous Request retransmission Destination (D)

time

w_DATA

RTS xRTS

RTC

CTS xCTS

DATA xDATA

ACK xACK

NACK

Figure 2. 2. Basic Basic procedure procedure of of UCMAC. UCMAC. Figure Table 1. 1. Notations Notations used used to to explain explain UCMAC. UCMAC. Table

Symbol Symbol Tx Tτx i,j τi,j τmax τmax Cj j τCback τback max N max coop N

Description Description Transmission time of a packet x 1 1 Transmission time of a packet x Propagation delay between nodes i and j Propagation delay between nodes i and j Maximum propagation delay Maximum propagation delay Backoff Backofftime timeofofa acooperator cooperatorj j Maximum number of cooperators Maximum number of cooperatorsallowed allowedininone onesession session Delay of DATA transmission at a source Delay of DATA transmission at a source Duration that a node i waits forfor reception ofof a packet Duration that a node i waits reception a packetx x1 1 List ofof cooperators List cooperatorsrecognized recognizedbybya asource source List potentialRTC–CTS RTC–CTScollision-causing collision-causingneighbors neighbors List ofof potential

coop S

ddelay dSdelay idiw_x dw_x Nℕ coop coop Nℕ neg neg 1

{RTS,RTC, RTC, CTS, NACK, ACK}. x 1∈x ∈{RTS, CTS,DATA, DATA, NACK, ACK}.

4.1. Channel Channel Reservation Reservation Phase Phase 4.1. The source with the the channel reservation by sending a request-to-send (RTS) to the destination, The sourcebegins begins with channel reservation by sending a request-to-send (RTS) to the which contains the propagation delay between source and destination, τ . Overhearing the RTS, destination, which contains the propagation delay between sourceS,D and destination, τS,D a. neighbor n determines it isnan eligible cooperator the following criteria: Overhearing the RTS, awhether neighbor determines whether based it is anoneligible cooperator based on the following criteria:

τS,n < τS,D and τn,D < τS,D τS,n < τS,D and τn,D < τS,D

(1) (1)

Sensors 2018, 18, x FOR PEER REVIEW

6 of 17

Sensors 2018, 18, 1969

6 of 17

This2018, means the cooperator Sensors 18, x that FOR PEER REVIEW

should be closer to both the source and the destination than the 6 of 17 source-to-destination distance. Accordingly, the cooperative region is defined as the area where eligible This means the cooperator should closer to the source andin the destination than the This means that the cooperator should be closer to both the source and the destination than the cooperators may that exist, as shown in Figure 3.be Every neighbor n that resides the cooperative region source-to-destination distance. Accordingly, the cooperative region defined as the area where eligible source-to-destination distance. Accordingly, the cooperative region is defined as the area where eligible sends a request-to-cooperate (RTC) containing τn,D , while the destination sends a clear-to-send (CTS) cooperators may exist, shown Figure Everyreferring neighbor to nn that in cooperative cooperators may exist, asas shown ininthe Figure Every neighbor that resides inthe the cooperative back to the source in response to RTS.3.3.Then, the resides RTC, the source builds region a region list of sends a request-to-cooperate (RTC) containing τ , while the destination sends a clear-to-send (CTS) sends a request-to-cooperate (RTC) containing τ , while the destination sends a clear-to-send (CTS) back n,D n,D on their closeness to the destination. To prevent cooperators, ℕcoop , which is sequenced based back to theinsource in response to Then, the RTS. Then, to referring to the the source RTC, the source builds a list of to the source response to the RTS. referring the RTC, builds a list of cooperators, excessively long operation time resulting from the participation of the cooperators, the number of cooperators, ℕcoop , which is sequenced based their to the To prevent Ncoop , whichincluded is sequenced based on theirby closeness thecloseness destination. To destination. prevent long maxon to cooperators in ℕcoop is limited Ncoop . Supposing τC2,D is smaller thanexcessively τC1,D in Figure excessively operation resulting from the cooperators, participation the of the cooperators, the number of operation timelong resulting from time the participation of the number of cooperators included 3, the destination givesin selection preference to .CSupposing of C2τ alsoinfails, the max 2 . If the retransmssion max cooperators included ℕ is limited by N τ is smaller than Figure coop coop C ,D C ,D in Ncoop is limited by Ncoop . Supposing τC2 ,D is smaller than τC1 ,D2 in Figure 3, the destination gives 1 retransmission continues through the next most preferred cooperator, C1 , in this example. If no 3, the preference destinationtogives preferenceoftoC2Calso the the retransmssion of Ccontinues the 2 . Iffails, 2 also fails, selection C2 . Ifselection the retransmssion retransmission through available cooperator exists, then the conventional MACA-U protocol works. continues through the most preferred cooperator, If no 1 , in this example. theretransmission next most preferred cooperator, C1 , next in this example. If no available C cooperator exists, then the available cooperator exists, then the conventional MACA-U protocol works. conventional MACA-U protocol works.

N1 N1

τ S,D τ S,D

Cooperative region Cooperative region N3 τS,C1 C1 τC ,D N3 τS,C1 τCS,1D τC1 ,D 1 S D τ S,D S τ D S,C C2 τC2 ,D τS,C22 C2 τC2 ,D N2 N2

τ S,D τ S,D

N4 N4

N5

N5

Figure Figure 3. 3. Cooperative Cooperative region. region. Figure 3. Cooperative region.

RTC and CTS, the responses to the RTS from cooperators and the destination, respectively, may RTC and CTS, the responses andthe thedestination, destination,respectively, respectively, may RTC and CTS, the responsestotothe theRTS RTSfrom from cooperators cooperators and may collide at the source. Figure 4a shows examples of RTC–RTC and RTC–CTS collisions. RTC–CTS collide at the source. collisions.RTC–CTS RTC–CTS collide at the source.Figure Figure4a4ashows showsexamples examples of of RTC–RTC RTC–RTC and RTC–CTS RTC–CTS collisions. collisions are significantly more severe than RTC–RTC collisions; they trigger the whole procedure collisions significantly more severe than RTC–RTC collisions;they theytrigger triggerthe thewhole wholeprocedure procedureto collisions areare significantly more severe than RTC–RTC collisions; to restart from the beginning. To avoid RTC–CTS collisions, we prohibit the neighbors that may cause to restart the beginning. To avoid RTC–CTS collisions,we weprohibit prohibit the neighbors restart fromfrom the beginning. To avoid RTC–CTS collisions, neighborsthat thatmay maycause cause collisions from transmitting RTC. Based on the pre-acquired knowledgeregarding regarding propagation delay collisions from transmittingRTC. RTC.Based Basedon onthe the pre-acquired pre-acquired knowledge delay collisions from transmitting knowledge regardingpropagation propagation delay information, the source builds a list of potential RTC–CTS collision-causing neighbors, ℕ , and neg information, the source builds a list of potential RTC–CTS collision-causing neighbors, ℕ , and neg information, the source builds a list of potential RTC–CTS collision-causing neighbors, N neg , and includes it into RTS. Then the neighbors included ℕ are banned banned from fromsending sendingRTC. RTC.InInFigure Figure includes it into RTS. Then neighbors includedinin inNneg ℕneg neg includes it into RTS. Then thethe neighbors included areare banned from sending RTC. In Figure 4b, 4b, C represents a case of RTC transmission prohibition so that CTS can escape a collision atthe the 3 C3 represents a case RTC transmission prohibition thatcan CTSescape can escape a collision C3 4b, represents a case of RTCof transmission prohibition so thatsoCTS a collision at theatsource. source. Meanwhile, RTC–RTC collisions can by implementing random backofftimes. times. source. Meanwhile, RTC–RTC collisions canbe bealleviated alleviated by implementing Meanwhile, RTC–RTC collisions can be alleviated by implementing randomrandom backoffbackoff times. Datatransfer transfer Data phase phase

Channel Channelreservation reservationphase phase τC1 ,D τC 1 ,D Source Source (S) (S)

ττCC22,D ,D

RTC–RTCcollision collision RTC–RTC

Cooperator Cooperator 1 1 (C1 )(C1 )

τC33,D ,D

ττD,H D,H

RTC–CTS collision RTC–CTS collision

. .. . . . .. .. . RTS

RTS

. .. .. .

Cooperator 2 Cooperator 2 (C2)

xRTS

xRTS

RTC

(C2) Cooperator 3 Cooperator (C3) 3 (C3) Destination Destination (D) (D)

RTC

...

CTS

...

CTS

...

...

time

time

(a)

(a)

Figure 4. Cont.


7 of 17

Channel reservation phase

Data transfer phase

τD,H τC2 ,D τC1 ,D Sensors 2018, 18, 1969 ℕneg = C3 Sensors 2018, 18, x FOR PEER REVIEW ... Source (S) Back off No RTC–RTC collision No RTC–CTS collision Data transfer ... Channel reservation phase Cooperator 1 phase (C1 ) τD,H τC2 ,D τC1 ,D Back off ... ℕneg = C3 Cooperator 2 . .. Source (C2) Not send RTC (S) Back off ... No RTC–RTC collision No RTC–CTS collision Cooperator 3 . .. Cooperator (C3) 1 (C1 ) ... Destination Back off . .. Cooperator 2 (D) time (C2) Not send RTC

...

(b)

Cooperator 3 (C3)

7 of 17 7 of 17

RTS xRTS RTC CTS

RTS xRTS RTC CTS

Figure 4. RTC–RTC and RTC–CTS collision cases: (a) without any countermeasures; (b) with backoff

...

Destination and prohibition of RTC transmission. (D)

time

4.2. Data Transfer Phase

(b) In Figure 5, the source sends the deferred DATA to the destination, which contains ℕcoop . The Figure 4. RTC–RTC and RTC–CTS collision cases: (a) countermeasures; (b) RTC–RTCthe andreason RTC–CTS cases:Overhearing (a) without without any any (b) with with backoff backoff in next Figure section4.explains for collision deferment. thecountermeasures; DATA, the neighbors included and prohibition of RTC transmission. and prohibition of RTC transmission. ℕcoop recognize themselves as cooperators and hold the successfully decoded data payload in case a request retransmission is sent. Those not included in ℕcoop are exempted from the cooperation. 4.2. Datafor Transfer Phase 4.2. Data Transfer Phase The possible reasons for not being included in ℕcoop are: In Figure 5, the source sends the deferred DATA to the destination, which contains ℕcoop . The In Figure 5, the source sends the deferred DATA to the destination, which contains Ncoop . The next  The source fails to receive RTCs. next section explains the reason for deferment. Overhearing the DATA, the neighbors included in section explains the reason for deferment. Overhearing the DATA, the neighbors included in Ncoop max  coopThe size of themselves ℕcoop reaches the limit, Ncoop . hold the successfully decoded data payload in case a ℕ recognize as cooperators and recognize themselves as cooperators and hold the successfully decoded data payload in case a request request forpayload retransmission sent.decoded, Those notthe included in ℕ are exempted from the cooperation. coop for retransmission issuccessfully sent. isThose not included in Ncoop are exempted from the source. cooperation. The If the is destination sends ACK back to the Otherwise, The reasons for being not being included incontinuously ℕare: coop are: possible reasons for not included in by Ncoop the possible destination requests retransmission sending NACK to the closest available specified to in ℕcoop until the retransmission is successful or ℕcoop is exhausted. Once the cooperator RTCs. • The The source source fails fails to receive receive RTCs. maxsends ACK to the source. Overhearing the ACK, the retransmission is successful, the destination • The ℕcoop reaches reachesthe thelimit, limit,NN max coop The size size of of N .. coop coop cooperators recognize the completion and discard the stored data. If the payload is successfully decoded, the destination sends ACK back to the source. Otherwise, the destination requests retransmission by continuously sending NACK to the closest available Channel Data transfer phase reservation cooperator specified in ℕcoop until the retransmission is successful or ℕcoop is exhausted. Once the phase ℕcoop = C2 , C1 retransmission .is. . successful, the destination sends ACK to the source. Overhearing the ACK, the Delay Source cooperators recognize the completion and discard the stored data. (S) Store DATA overheard by C2

Erroneous Cooperator 1 (C1 ) Cooperator 2 (C2) Source (S) Destination (D) Cooperator 1 (C1 ) Cooperator 2 (C2)

Possible to retransmit DATA

...

DATA


NACK

...

... ...

xDATA

Data transfer phase ℕcoop = C2 , C1

ACK

Delay

xACK

Erroneous Erroneous

Erroneous

Store DATA overheard by C2

Possible to retransmit DATA

...

Figure 5. 5. Enabling Enabling cooperation cooperation through through additional additional DATA DATA overhearing. Figure overhearing. ...

time DATA xDATA NACK ACK xACK

Erroneous Erroneous Asthe Figure 5 shows, even when cooperators (C1 in thissends example) overhear DATA If payload ACK fail backattofirst theto source. Otherwise, . . . is successfully decoded, the destination Destination from the source, they can recover the failed DATA by overhearing other cooperators’ (C (D) the destination requests retransmission by continuously sending NACK to the closest 2 in this time available example) retransmission and join the retransmission (denoted by bold arrow) with the cooperator specified in N until thecan retransmission is successful or Ncoop is exhausted. Once cooptherefore 5. Enabling through DATA overhearing. recovered DATA. Figure the retransmission is successful, thecooperation destination sends additional ACK to the source. Overhearing the ACK, the cooperators recognize the completion and discard the stored data. As As Figure Figure 55 shows, shows, even even when when cooperators cooperators(C (C11 in in this this example) example) fail fail at at first first to to overhear overhear DATA DATA from the source, they can recover the failed DATA by overhearing other cooperators’ (C in 2 from the source, they can recover the failed DATA by overhearing other cooperators’ (C2 in this this example) example) retransmission retransmission and and therefore therefore can can join join the the retransmission retransmission (denoted (denoted by by bold bold arrow) arrow) with with the the recovered recovered DATA. DATA.

Sensors 2018, 18, 1969

8 of 17

4.3. Waiting Times The source, the cooperators, and the destination each manages a waiting-mechanism to escape undesirable collisions. In this section, we calculate the waiting times that must be very carefully set to Sensors 2018, 18, xscheme FOR PEERwork REVIEW 8 of 17 make the proposed properly. 4.3. Waiting Times 4.3.1. Waiting Times at Source The source, the cooperators, and the destination each manages a waiting-mechanism to escape

The source manages two kinds of waiting time and one deferment as shown in Figure 6. In the channel undesirable collisions. In this section, we calculate the waiting times that must be very carefully set reservation after transmitting source waits for CTS from the destination during the period of: to phase, make the proposed schemeRTS, workthe properly. dSw_CTS = 2 × τS,D + TCTS

4.3.1. Waiting Times at Source

(2)

The source manages two kinds of waiting time and one deferment as shown in Figure 6. In the

which ischannel easilyreservation obtainedphase, fromafter Figure 6a. After receiving CTS, intentionally delays transmitting RTS, the source waitsthe forsource CTS from the destination duringDATA transmission to avoid a collision with RTS sent by a hidden node (H) who starts a new communication the period of: with the destination as shown in Figure S6b. The amount of delay required is denoted by dSdelay . dw_CTS = 2 × τS,D + TCTS (2) To avoid the RTS–DATA collision, the DATA should be scheduled to arrive after the possible RTS which is6b). easily obtained arrival (Figure That is: from Figure 6a. After receiving CTS, the source intentionally delays DATA transmission to avoid a collision with SRTS sent by a hidden node (H) who starts a new 2 × τS,D + ddelay > 2 × τD,H + TRTS (3) communication with the destination as shown in Figure 6b. The amount of delay required is denoted S byτddelay . To avoid the RTS–DATA collision, the DATA should be scheduled to arrive after the where the D,H specified in CTS is a propagation delay between the destination and its farthest neighbor possible RTS arrival 6b). That who may be hidden from (Figure the source. By is: rearranging Equation (3), dS is obtained by: delay

S 2 × τS,D + ddelay > 2 × τD,H + TRTS

(3)

S = is min τS,D )between + TRTSthe , 0)destination . (2 × (τD,H − specifiedddelay in CTS a propagation delay and its farthest

where the τD,H S neighbor who may be hidden from the source. By rearranging Equation (3), ddelay is obtained by:

(4)

After DATA transmission, the source waits for ACK from the destination. The waiting time for S ddelay = min (2 × (τD,H − τS,D ) + TRTS , 0). (4) ACK might be augmented according to the number of cooperators participating in the retransmission. After DATA transmission, the source waits for ACK the destination. The waiting time for The time segment augmented by cooperators j is given by from (Figure 6c): ACK might be augmented according to the number of cooperators participating in the retransmission. The time segment augmented∆by cooperators j is given by (Figure 6c): C = 2 × τC ,D + TNACK + TDATA . j

j

∆Cj = 2 × τCj ,D + TNACK + TDATA .

(5)

(5)

Thus, the maximum time spent by the source until receiving ACK is: Thus, the maximum time spent by the source until receiving ACK is:

S = (2 × τS,D + TACK ) + dSw_ACK ∑ ∆C∆j .Cj . dw_ACK = (2 × τS,D + TACK ) + ∑

(6)

C j ∈Ncoop Cj ∈ℕ coop

(6)

S dS S If CTS and ACK are not within time periods dS , If CTS and ACK are received not received withinthe theaforementioned aforementioned time periods dw_CTS and dand w_CTS w_ACK ,w_ACK respectively, the source the whole procedure beginning withwith sending a new RTS after a random respectively, the restarts source restarts the whole procedure beginning sending a new RTS after a backoff timethe thatbinary followsexponential the binary exponential backoffalgorithm. (BEB) algorithm. backoff random time that follows backoff (BEB)


Data transfer phase

S dw_CTS

Source (S) Cooperator 1 (C1 )

... τS,D

τS,D

TCTS

...

RTS

Back off

xRTS

Back off

RTC

...

Cooperator 2 (C2 )

CTS

...

Destination (D)

time

(a)

Figure 6. Cont.

Sensors 2018, 18, 1969

9 of 17


9 of 17


Data transfer phase τD,H

Delay Source (S)

...

S ddelay

τS,D

τS,D RTS CTS xCTS DATA

...

Destination (D)

τD,H

τD,H

Hidden node (H)

TRTS time

(b) Channel reservation phase

Data transfer phase

ℕcoop = C2 , C1

S

Source (S) Cooperator 1 (C1 )

...

Delay

...

ddelay

dw_ACK ∆C2

τS,D

S

∆C1

τS,D TACK

Cooperator 2 (C2)

DATA xDATA

Erroneous

NACK

...

ACK xACK

Erroneous Destination (D)

...

TDATA 2 × τC1,D 2 × τC2,D TNACK TNACK

time

TDATA

(c) Figure 6. Decision of waiting time at source: (a) d S

; (b) d S

; (c) d S

.

delayS w_ACK S S Figure 6. Decision of waiting time at source: (a) dw_CTS w_CTS ; (b) ddelay ; (c) dw_ACK .

4.3.2. Waiting Times at Cooperators

4.3.2. Waiting Times at Cooperators

Cj

As shown in Figure 7a, the cooperator j takes a random backoff (τback ) before transmitting RTC, Cj which is intended to 7a, prevent RTC–RTC collisions. cooperator j then(τ stays silent to avoid causing As shown in Figure the cooperator j takes The a random backoff back ) before transmitting RTC, any collision with the source–destination communication. In order to estimate the silence duration, which is intended to prevent RTC–RTC collisions. The cooperator j then stays silent to avoid causing the cooperator j needs to know how many cooperators could be engaged in the communication by any collision with the source–destination communication. In order to estimate the silence duration, the reading the ℕcoop carried in DATA, so, the cooperator j waits to overhear the DATA during the cooperator j needs period of: to know how many cooperators could be engaged in the communication by reading

the Ncoop carried in DATA, so, the cooperator j waits to overhear the DATA during the period of: C S j dw_DATA = T* + d̂ delay + τS,Cj + TDATA

Cj dw_DATA

where:

∗

=T =

dˆSdelay

(7)

+ τS,Cj + TDATA

(7)

Cj

S T* = dw_CTS − (τS,Cj + τback + TRTC ),

where: S

(8)

Cj SS T ∗of=dddelay − isτgiven τback + TRTC , to the lack of knowledge S,C j +in w_CTS is a modified value which Equation (4). Due

(8) and d̂ delay S of τD,H at the moment, the cooperator guesses ddelay as the maximum value of τmax . Then, and dˆSdelay is a modified value of dSdelay which is given in Equation (4). Due to the lack of knowledge according to the number of cooperators engaged, the cooperator extends the silence duration in of τD,H which at the the moment, the itself cooperator dSdelay the maximum value of τmaxthe . Then, according cooperator possiblyguesses participates in as retransmission. Figure 7b shows extended Cj to the number of cooperators engaged, the silence in which the silence duration of the cooperator j afterthe the cooperator expiration of extends dw_DATA , which is givenduration by: cooperator itself possibly participates in retransmission. Figure 7b shows the extended silence duration Cj

d

= (τS,D −Cτj S,C + τC ,D + TACK ) +

∑

w_ACK j j of the cooperator j after the expiration of dw_DATA , which is given by: C ∈ℕ j

Cj dw_ACK = τS,D − τS,Cj + τCj ,D + TACK +

∆Cj .

(9)

coop

∑

C j ∈Ncoop

∆C j .

(9)

max ) is In case the cooperator fails to overhear DATA, the maximum number of cooperators (Ncoop used to calculate the second term of Equation (9).


10 of 17

max In case the cooperator fails to overhear DATA, the maximum number of cooperators (Ncoop ) is 10 of 17 used to calculate the second term of Equation (9).

Sensors 2018, 18, 1969


Data transfer phase

ℕcoop

S

dw_CTS

Delay

Source (S)

T* Back off Cooperator j (Cj )

RTS xRTS

Cj dw_DATA

RTC

CTS

𝐒

xCTS

ddelay

τS,Cj − τCj ,D

τS,Cj τCj TRTC back

τS,Cj TDATA

xDATA

Erroneous

τD,H

Destination (D)

DATA

NACK

time

(a) Channel reservation phase

Source (S) Cooperator 1 (C1) Cooperator 2 (C2) Destination (D)

Data transfer phase

ℕcoop = C2 , C1 Delay

...

C

1 dw_ACK

τS,D − τS,C1

...

τS,C1

...

Lost

DATA

τC1 ,D

∆C1

∆C2

xDATA NACK

TACK

xNACK ACK

C

2 dw_ACK

Erroneous

...

xACK

time

τS,D

(b) Cj

Cj

Cj Cj Figure ; (b) dw_ACK . Figure7.7.Decision Decisionofoftime-parameters time-parametersatatcooperator cooperatorj:j:(a) (a)ddw_DATA w_DATA ; (b) dw_ACK .

4.3.3. 4.3.3.Waiting WaitingTimes Timesat atDestination Destination After Aftersending sendingCTS CTSor orNACK, NACK,the thedestination destinationwaits waitsfor forDATA DATAarrival. arrival.As Asshown shownininFigure Figure8,8,the the waiting waitingtime timevaries variesaccording accordingto tothe thepacket packettype type(CTS (CTSor orNACK) NACK)by: by:

( 2×τ +dS +T after sending CTS to source S S,D delay DATA , { 2 × τS,D + ddelay + TDATA , after sending CTS to source ΔCj − TNACK , after sending NACK to cooperator j. ∆Cj − TNACK , after sending NACK to cooperator j.

dD = dD w_DATA= w_DATA

(10) (10)


of 17 If no cooperators exist, the destination does not request any cooperation and returns to an idle11state. Channel reservation phase

Data transfer phase

ℕcoop = C2 , C1 Delay

...

Source (S)

...

Cooperator 1 (C1)

RTS CTS DATA

...

Cooperator 2 (C2)

NACK

Erroneous Destination (D)

xDATA

Erroneous

Erroneous

...

τS,D

S ddelay

D

dw_DATA

τS,D

TDATA TNACK

∆C2

∆C1

time

TNACK D

dw_DATA

D

dw_DATA

Figure 8. Decision of dD w_DATA at destination. D Figure 8. Decision of dw_DATA at destination.

5. Performance Evaluation Through the computer simulation, we compare UCMAC with the conventional MACA-U [32] and CD-MACA [12] in terms of system throughput, latency, energy consumption, and single-hop

Sensors 2018, 18, 1969

11 of 17

If no cooperators exist, the destination does not request any cooperation and returns to an idle state. 5. Performance Evaluation Through the computer simulation, we compare UCMAC with the conventional MACA-U [32] and CD-MACA [12] in terms of system throughput, latency, energy consumption, and single-hop PDR. MACA-U is the non-cooperative underwater-specific MACA [37] protocol that basically uses 3-way handshaking (RTS–CTS–DATA) and optionally adds ACK at the end. In our evaluation, we consider the MACA-U with ACK to make the comparison fair. CD-MACA has a simple cooperation mechanism that allows neighboring nodes to opportunistically participate in retransmission. 5.1. Simulation Model In a grid network, 36 static nodes are located around each grid point with 10% variation in the spacing. Each node generates data traffic that follows the Poisson arrival process with the rate of λ and operates in half-duplexing mode, which may cause the busy terminal problem [38]. To reflect the characteristics of underwater channel, we apply the empirical underwater acoustic channel model [36]. Since we use no error correction technique, DATA with even a single bit error is assumed to be erroneous, while other control packets are assumed to be error-free. We determine the data rate and the transmission/receiving (Tx/Rx) powers by referring to the specifications of the commercial Teledyne Benthos ATM-903 underwater modem [39]. For simplicity, we ignore power consumption in idle mode. For CD-MACA, we set the duration time the cooperator holds DATA and the memory size to 30 s and 100 packets, respectively. Table 2 lists the default values of the system parameters used in the simulation. Table 2. System parameters for simulation. Parameter

Value

Grid size Propagation speed Transmission range Data rate Tx Power Rx power Maximum number of RTS transmission Control packet size 1

1 km × 1 km 1500 m/s 2500 m 2400 bps 20 W 756 mW 5 120 bits

1

RTS, RTC, CTS, NACK, ACK packets.

5.2. Simulation Results First of all, we define performance metrics as follows:

• • • •

System throughput: The average number of DATA bits successfully received by the intended destinations per second (measured in bps) Latency: The average time interval between generation and successful delivery of DATA packets at the intended destinations (measured in s) Single-hop PDR: The ratio of the number of DATA packets successfully delivered at the intended destinations to the total number of DATA packets generated (measured in %) Energy efficiency: The average number of DATA bits successfully received by the intended destinations per Joule (measured in bits/J)

max in terms of the system throughput Figure 9 demonstrates the existence of an appropriate Ncoop for various DATA sizes. It is generally accepted to assume that high cooperative diversity gains lead max is small, the cooperative diversity gains may not be maximally to a high system throughput. If Ncoop



destinations to the total number of DATA packets generated (measured in %) Energy efficiency: The average number of DATA bits successfully received by the intended destinations per Joule (measured in bits/J)

Figure 9 demonstrates the existence of an appropriate Nmax coop in terms of the system throughput 2018, 18, 1969 12 of 17 forSensors various DATA sizes. It is generally accepted to assume that high cooperative diversity gains lead max to a high system throughput. If Ncoop is small, the cooperative diversity gains may not be maximally obtained even though only a small amount of of overheads is is produced byby additional cooperation obtained even though only a small amount overheads produced additional cooperation max max process at at thethe same time. OnOn thethe other hand, a high Ncoop makes excessive overheads exceed thethe process same time. other hand, a high Ncoop makes excessive overheads exceed max max cooperative diversity gains. Consequently, an appropriate level of N exists depending on cooperative diversity gains. Consequently, an appropriate level of Ncoop coop exists depending on network max max network circumstances. For example, the DATA is 3 kbits, we expect Ncoop of 3 results circumstances. For example, whenwhen the DATA size issize 3 kbits, we expect thatthat Ncoop of 3 results in the highest system throughput. in the highest system throughput.

Figure 9. System throughput versus Nmax = 0.002). max(λ(λ coop Figure 9. System throughput versus Ncoop = 0.002).

Meanwhile, the optimal Nmax also varies with the data size. As the data packet size becomes max Meanwhile, the optimal coop Ncoop also varies with the data size. As the data packet size becomes larger, the susceptibility to packet error increases. Therefore, if the data size is too large, thethe data larger, the susceptibility to packet error increases. Therefore, if the data size is too large, data packets retransmitted by cooperators are also likely to be erroneous. In this situation, increasing packets retransmitted by cooperators are also likely to be erroneous. In this situation, increasing Nmax just brings about increase in overheads. On the a small datadata packet is more likelylikely to max coop Ncoop just brings about increase in overheads. On contrary, the contrary, a small packet is more max betosuccessfully received, and and therefore, a relatively higher Ncoop is allowed at at thethe expense of of max be successfully received, therefore, a relatively higher Ncoop is allowed expense additional overheads. additional overheads. max In In Figure 10,10, wewe compare UCMAC with MACA-U andand CD-MACA by setting Nmax and DATA coop Figure compare UCMAC with MACA-U CD-MACA by setting Ncoop and DATA size at 2atand 1 kbits, respectively. Overall, UCMAC outperforms the other schemes as a result of its of size 2 and 1 kbits, respectively. Overall, UCMAC outperforms the other schemes as a result well-coordinated cooperation process. MACA-U, which is non-cooperative, shows relatively low its well-coordinated cooperation process. MACA-U, which is non-cooperative, shows relatively low performances compared to cooperative protocols. First, our analysis shows that UCMAC offers much performances compared to cooperative protocols. First, our analysis shows that UCMAC offers much better system throughput than other schemes (Figure 10a). This is because retransmitted DATAs better system throughput than other schemes (Figure 10a). This is because retransmitted DATAs arrive at the destinations more quickly with the aid of the well-coordinated cooperators. Although arrive at the destinations more quickly with the aid of the well-coordinated cooperators. Although CD-MACA also benefits from cooperation, such cooperative gains areare smaller than those of of UCMAC CD-MACA also benefits from cooperation, such cooperative gains smaller than those UCMAC

mainly due to the lack of coordination between the cooperators. CD-MACA performs slightly better than MACA-U, allowing neighboring nodes or cooperators to retransmit DATA opportunistically. In MACA-U’s case, when packet errors happen, the destinations do not request any cooperation and just rely on source retransmissions. If packet errors persist, each source is more likely to take a longer backoff time, which will result in larger decreases in the system throughput. The result of latency can be understood in the same context (Figure 10b). In CD-MACA, packet collisions may occur between DATAs retransmitted by the cooperators; UCMAC escapes such collisions by making the cooperators retransmit DATA one at a time. This increases the likelihood that the intended destinations successfully receive DATAs after a smaller number of retransmission, thus reducing the latency. At the same time, elimination of packet collisions also helps UCMAC to achieve the high single-hop PDR (Figure 10c). This means that cooperation is highly effective in the delivery of DATAs even when the traffic is heavy, and UCMAC can be reliable under any circumstances. In CD-MACA, more DATAs end up being discarded due to collisions, which results in the lower single-hop PDR in spite of cooperation.

backoff time, which will result in larger decreases in the system throughput. The result of latency can be understood in the same context (Figure 10b). In CD-MACA, packet collisions may occur between DATAs retransmitted by the cooperators; UCMAC escapes such collisions by making the cooperators retransmit DATA one at a time. This increases the likelihood that the intended destinations successfully receive DATAs after a smaller number of retransmission, thus reducing the latency. At the same time, elimination of packet collisions also helps UCMAC to achieve the high single-hop Sensors 2018, 18, 1969 13 of 17 PDR (Figure 10c). This means that cooperation is highly effective in the delivery of DATAs even when the traffic is heavy, and UCMAC can be reliable under any circumstances. In CD-MACA, more DATAs end up being discarded due to collisions, which results in the lower single-hop PDR in spite Obviously, non-cooperative MACA-U has the lowest single-hop PDR as the destinations rely solely of cooperation. Obviously, non-cooperative MACA-U has the lowest single-hop PDR as the on their own sources. In terms of energy consumption, our analysis also shows that UCMAC is most destinations rely solely on their own sources. In terms of energy consumption, our analysis also efficientshows (Figure that10d). UCMAC is most efficient (Figure 10d).

(a)


(b)

(c)

Figure 10. Cont.

14 of 17

Sensors 2018, 18, 1969

14 of 17

(c)

(d) Figure 10. Performance comparison with comparing schemes ( Nmax coop = 2 , DATA size = 1 kbits):

max = 2, DATA size = 1 kbits): Figure 10. Performance comparison with comparing schemes (Ncoop (a) System throughput; (b) Latency; (c) Single-hop PDR; (d) Energy efficiency. (a) System throughput; (b) Latency; (c) Single-hop PDR; (d) Energy efficiency.

Unlike CD-MACA where all neighbors commonly included in both source and destination coverages serve as cooperators considering whetherincluded they have in better channel-to-destination Unlike CD-MACA where allwithout neighbors commonly both source and destination than sources, UCMAC selects only beneficial neighbors in terms of channel quality as cooperators coverages serve as cooperators without considering whether they have better channel-to-destination and accordingly saves energy by using lower transmission power and fewer retransmissions. than sources, UCMAC selects only beneficial neighbors in terms of channel quality as cooperators and Furthermore, since no packet collisions occur between retransmitted DATAs as aforementioned, accordingly energy can by using lower transmission and fewer is retransmissions. energysaves consumption be significantly reduced. The power reason CD-MACA more energy-intensive Furthermore, since no packet collisions occur between retransmitted as aforementioned, than MACA-U is because all cooperators wastefully participate in every DATAs retransmission in CDenergyMACA. consumption can be significantly reduced. The reason CD-MACA is more energy-intensive The decrease in energy efficiency of UCMAC in the range of low λ largely stems from the extra overhead causedallbycooperators cooperator RTC responses and destination NACK transmissions, than MACA-U is because wastefully participate in every retransmission in which CD-MACA. are more noticeable in lower traffic loads. As λ grows, energy efficiency in each scheme converges The decrease in energy efficiency of UCMAC in the range of low λ largely stems from the extra overhead own steady state. causedtobyitscooperator RTC responses and destination NACK transmissions, which are more noticeable in Figure 11 verifies that the waiting times provided in the manuscript guarantee the highest lower traffic loads. As λ grows, energy efficiency in each scheme converges to its own steady state. network performances in UCMAC. In the figure, each result of the performance metrics is normalized Figure 11 of verifies that the waiting times provided in thethrough manuscript guarantee the highest network to result the waiting times (orange-colored bar) obtained the Equations (2)–(10) that could performances in UCMAC. In the figure,performances. each result of the performance to result potentially yield the best network Adding extra time ofmetrics 10–30%istonormalized the calculated waiting times the performances of the network a small margin. That is could largelypotentially due of the waiting timesdegrades (orange-colored bar) obtained throughonly theby Equations (2)–(10) that

yield Adding extra time of 10–30% to the calculated waiting15 times Sensorsthe 2018,best 18, xnetwork FOR PEERperformances. REVIEW of 17 degrades the performances of the network only by a small margin. That is largely due to the waste of to the wasteresources. of the channel resources. Onwith the other withof a the 10%waiting reduction of (blue-colored the waiting times the channel On the other hand, a 10%hand, reduction times bar), (blue-colored bar), the network’s performance is significantly means we the network’s performance is significantly degraded. That meansdegraded. the valuesThat we got fromthe thevalues equations got fromsufficient, the equations provide sufficient, butthe notdesired excessive time for the desired packetsthe to maximum arrive. As provide but not excessive time for packets to arrive. As a result, a result, thediversity maximum cooperative gains require a careful decision the waiting for times, cooperative gains require a diversity careful decision of the waiting times, whichofcompensates the which compensates for the effects of problem. the space–time uncertainty problem. effects of the space–time uncertainty

Figure 11. different lengths of the waiting times (Nmax = 2, DATA size = max coop Figure 11. Performance Performancevariation variationwith with different lengths of the waiting times (Ncoop = 2, DATA 1 kbits, λ = 0.01). size = 1 kbits, λ = 0.01 ).

6. Conclusions This paper proposes a cooperative MAC protocol for UWSNs named UCMAC. For the purpose of improving network capabilities in the error-prone underwater channel, UCMAC builds spatial diversity using cooperative retransmission. In addition, to minimize extra overheads caused by this

Sensors 2018, 18, 1969

15 of 17

6. Conclusions This paper proposes a cooperative MAC protocol for UWSNs named UCMAC. For the purpose of improving network capabilities in the error-prone underwater channel, UCMAC builds spatial diversity using cooperative retransmission. In addition, to minimize extra overheads caused by this cooperation, the neighbors located at more advantageous positions for retransmission than the source selectively participate in the cooperation. Also, the order of preferred cooperators, based on closeness to the destination, is appended to data without extra packet exchange. Moreover, this scheme avoids the packet collisions that frequently occur in previous cooperative communication schemes by designating the most preferable cooperators one by one. Simulation results showed that UCMAC outperforms comparable schemes, including MACA-U and CD-MACA, in terms of system throughput, latency, single-hop PDR, and energy efficiency, alleviating the space–time uncertainty problem. We are currently planning additional research to include the cross-layer approach of establishing a new cooperator selection criterion that adapts to underwater channel quality. Author Contributions: H.-w.K. conceived and designed the protocol; H.-w.K. and T.H.I. performed the simulation; H.-w.K. and H.-S.C analyzed the simulation results and wrote the paper; H.-S.C. supervised the work. Funding: This research was a part of the project titled “Development of Distributed Underwater Monitoring & Control Networks”, funded by the Ministry of Oceans and Fisheries, Korea, and supported in part by the BK21 Plus project funded by the Ministry of Education, Korea (21A20131600011). Conflicts of Interest: The authors declare no conflict of interest.

References 1. 2. 3. 4.

5.

6. 7. 8. 9.

10. 11.

12.

Akyildiz, I.F.; Pompili, D.; Melodia, T. Underwater acoustic sensor networks: Research challenges. Ad Hoc Netw. 2005, 3, 257–279. [CrossRef] Forouzan, B.A. Data Communications and Networking, 4th ed.; McGraw-Hill: New York, NY, USA, 2007; pp. 311–340. ISBN 978-007-125442-7. Molins, M.; Stojanovic, M. Slotted FAMA: A MAC protocol for underwater acoustic networks. In Proceedings of the OCEANS 2006—Asia Pacific, Singapore, 16–19 May 2007; pp. 1–7. Xie, P.; Cui, J.-H. R-MAC: An Energy-Efficient MAC Protocol for Underwater Sensor Networks. In Proceedings of the International Conference on Wireless Algorithms, Systems, and Applications, Chicago, IL, USA, 1–3 August 2011; pp. 187–195. Azad, S.; Casari, P.; Hasan, K.T.; Zorzi, M. MACA–APT: A MACA-based Adaptive Packet Train Transmission Protocol for Underwater Acoustic Networks. In Proceedings of the International Conference on Underwater Networks & Systems, Rome, Italy, 12–14 November 2014. Nosrantinia, A.; Hunter, T.E.; Hedayat, A. Cooperative Communication in Wireless Networks. IEEE Commun. Mag. 2004, 42, 74–80. [CrossRef] Sendonaris, A.; Erkip, E.; Aazhang, B. User Cooperation Diversity—Part 1: System Description. IEEE Trans. Commun. 2003, 51, 1927–1938. [CrossRef] Sendonaris, A.; Erkip, E.; Aazhang, B. User Cooperation Diversity—Part 2: Implementation Aspects and Performance Analysis. IEEE Trans. Commun. 2003, 51, 1939–1948. [CrossRef] Morillo-Pozo, J.; García-Vidal, J.; Pérez-Neira, A.I. Collaborative ARQ in Wireless Energy-Constrained Networks. In Proceedings of the 2005 Joint Workshop on Foundations of Mobile Computing, Cologne, Germany, 2 September 2005; pp. 2–7. Dianati, M.; Ling, X.; Naik, K.; Shen, X. A Node-Cooperative ARQ Scheme for Wireless Ad Hoc Networks. IEEE. Trans. Veh. Technol. 2006, 55, 1032–1044. [CrossRef] Lu, K.; Fu, S.; Qian, Y.; Chen, H.-H. Increasing the Throughput of Wireless LANs via Cooperative Retransmission. In Proceedings of the IEEE Global Communications Conference 2007, Washington, DC, USA, 26–30 November 2007; pp. 5231–5235. Wang, X.; Yang, C. A MAC Protocol Supporting Cooperative Diversity for Distributed Wireless Ad Hoc Networks. In Proceedings of the IEEE 16th International Symposium on Personal, Indoor and Mobile Radio Communications, Berlin, Germany, 11–14 September 2005; pp. 1396–1400.

Sensors 2018, 18, 1969

13.

14. 15.

16. 17.

18. 19. 20. 21.

22. 23.

24.

25.

26. 27.

28. 29.

30. 31.

32.

16 of 17

Shankar, S.; Chou, C.-T.; Ghosh, M. Cooperative Communication MAC (CMAC)—A New MAC protocol for Next Generation Wireless LANs. In Proceedings of the International Conference on Wireless Networks, Communications and Mobile Computing, Maui, HI, USA, 13–16 June 2005; pp. 1–6. Liu, P.; Tao, Z.; Narayanan, S.; Korakis, T.; Panwar, S.S. CoopMAC: A Cooperative MAC for Wireless LANs. IEEE. J. Sel. Areas Commun. 2007, 25, 340–354. [CrossRef] Alonso-Zárate, J.; Kartsakli, E.; Verikoukis, C.; Alonso, L. Persistent RCSMA: A MAC Protocol for a Distributed Cooperative ARQ Scheme in Wireless Networks. EURASIP J. Adv. Signal Process. 2008, 2008, 817401. [CrossRef] Shan, H.; Zhuang, W.; Wang, Z. Distributed Cooperative MAC for Multihop Wireless Networks. IEEE Commun. Mag. 2009, 47, 126–133. [CrossRef] Alonso-Zárate, J.; Kartsakli, E.; Alonso, L.; Verikoukis, C. Cooperative ARQ: A Medium Access Control (MAC) Layer Perspective. In Radio Communications, 1st ed.; Bazzi, A., Ed.; IntechOpen: London, UK, 2010; pp. 227–246. ISBN 978-953-307-091-9. He, X.; Li, F.Y. Cooperative MAC Design in Multi-hop Wireless Networks: Part 1: When Source and Destination are within the Transmission Range of Each Other. Wirel. Pers. Commun. 2011, 57, 339–350. [CrossRef] Antonopoulos, A.; Verikoukis, C.; Skianis, C.; Akan, O.B. Energy efficient network coding-based MAC for cooperative ARQ wireless networks. Ad Hoc Netw. 2013, 11, 190–200. [CrossRef] Antonopoulos, A.; Renzo, M.D.; Verikoukis, C. Effect of Realistic Channel Conditions on the Energy Efficiency of Network Coding-Aided Cooperative MAC Protocols. IEEE Wirel. Commun. 2013, 20, 76–84. [CrossRef] Antonopoulos, A.; Lalos, A.S.; Renzo, M.D.; Verikoukis, C. Cross-Layer Theoretical Analysis of NC-Aided Cooperative ARQ Protocols in Correlated Shadowed Environments. IEEE. Trans. Veh. Technol. 2015, 64, 4074–4087. [CrossRef] IEEE. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications; IEEE: Piscataway, NJ, USA, 2007. Han, Z.; Sun, Y.L.; Shi, H. Cooperative Transmission for Underwater Acoustic Communications. In Proceedings of the 2008 IEEE International Conference on Communications, Beijing, China, 19–23 May 2008; pp. 2028–2032. Luo, Y.; Pu, L.; Peng, Z.; Zhou, Z.; Cui, J.-H.; Zhang, Z. Effective Relay Selection for Underwater Cooperative Acoustic Networks. In Proceedings of the 2013 IEEE 10th International Conference on Mobile Ad-Hoc and Sensor Systems, Hangzhou, China, 14–16 October 2013; pp. 104–112. Gao, C.; Liu, Z.; Cao, B.; Mu, L. Relay Selection Scheme Based on Propagation Delay for Cooperative Underwater Acoustic Network. In Proceedings of the 2013 International Conference on Wireless Communications and Signal Processing, Hangzhou, China, 24–26 October 2013. Li, X.; Liu, J.; Yan, L.; Han, S.; Guan, X. Relay Selection in Underwater Acoustic Cooperative Networks: A Contextual Bandit Approach. IEEE Commun. Lett. 2017, 21, 382–385. [CrossRef] Hafeez, T.; Javaid, N.; Shakeel, U.; Muhammad; Hussain, S.; Maqsood, H. An Energy Efficient Adaptive Cooperative Routing Protocol for Underwater WSNs. In Proceedings of the 2015 10th International Conference on Broadband and Wireless Computing, Communication and Applications, Krakow, Poland, 4–6 November 2015; pp. 304–310. Rahman, M.A.; Lee, Y.; Koo, I. EECOR: An Energy-Efficient Cooperative Opportunistic Routing Protocol for Underwater Acoustic Sensor Networks. IEEE Access 2017, 5, 14119–14132. [CrossRef] Syed, A.; Ye, W.; Heidemann, J. T-Lohi: A New Class of MAC Protocols for Underwater Acoustic Sensor Networks. In Proceedings of the 27th Conference on Computer Communications, Phoenix, AZ, USA, 13–18 April 2008. Lee, J.W.; Cheon, J.Y.; Cho, H.-S. A Cooperative ARQ scheme in Underwater Acoustic Sensor Networks. In Proceedings of the IEEE Oceans 2010, Sydney, Australia, 24–27 May 2010. Kim, H.; Cho, H.-S. A Cooperative ARQ-based MAC Protocol for Underwater Wireless Sensor Networks. In Proceedings of the 11th ACM International Conference on Underwater Networks and Systems, Shanghai, China, 24–26 October 2016. Ng, H.-H.; Soh, W.-S.; Motani, M. MACA-U: A Media Access Protocol for Underwater Acoustic Networks. In Proceedings of the 2008 IEEE Global Telecommunications Conference, New Orleans, LA, USA, 30 November–4 December 2008.

Sensors 2018, 18, 1969

33. 34.

35. 36. 37. 38.

39.

17 of 17

Alonso-Zárate, J.; Verikoukis, C.; Kartsakli, E.; Cateura, A.; Alonso, L. A Near-Optimum Cross-Layered Distributed Queuing Protocol for Wireless LAN. IEEE Wirel. Commun. 2008, 15, 48–55. [CrossRef] Alonso-Zárate, J.; Kartsakli, E.; Skianis, C.; Verikoukis, C.; Alonso, L. Saturation Throughput Analysis of a Cluster-based Medium Access Control Protocol for Single-hop Ad Hoc Wireless Networks. Simulation 2008, 84, 619–633. [CrossRef] Kim, H.-W.; Cho, H.-S. SOUNET: Self-Organized Underwater Wireless Sensor Network. Sensors 2017, 17, 283. [CrossRef] [PubMed] Stojanovic, M.; Preisig, J. Underwater Acoustic Communication Channels: Propagation Models and Statistical Characterization. IEEE Commun. Mag. 2009, 47, 84–89. [CrossRef] Karn, P. MACA–A New Channel Access Method for Packet Radio. In Proceedings of the 9th Computer Networking Conference, London, ON, Canada, 22 September 1990. Zhu, Y.; Zhou, Z.; Peng, Z.; Cui, J.-H. “Busy Terminal Problem” and Implications in Underwater Acoustic Networks. In Proceedings of the 7th ACM International Conference on Underwater Networks and Systems 2012 (WUWNet 2012), Los Angeles, CA, USA, 5–6 November 2012. TELEDYNE MARINE. Available online: http://www.teledynemarine.com/903-series-atm-903?ProductLineID=8 (accessed on 13 November 2017). © 2018 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).