# PC-MAC: A Prescheduling and Collision-Avoided MAC Protocol for Underwater Acoustic Sensor Networks

Authors: Zhigang Jin; Shenyang Xiao; Yishan Su; Yajing Li
Journal: Journal of Sensors
 (2017)

---

## Abstract

The impact of the acoustic modem with long preamble characteristic on the collision feature of the media access control scheme in underwater acoustic sensor networks (UANs) is evaluated. It is observed that the collision probability is relatively high due to the extremely long duration of preamble. As a result, UANs generally have much lower network throughput. To address this problem, a prescheduling MAC protocol named PC-MAC for UANs is proposed, which leverages a novel prescheduling scheme for the exchange of control packet to alleviate the collision probability among control packets. PC-MAC is a reservation-based channel access scheme. In the proposed protocol, an extra guard time is introduced to avoid the influence of dynamic spatial-temporal uncertainty of the sender and receiver positions. Simulation results show that PC-MAC outperforms classic reservation-based MAC protocol named SFAMA in terms of network goodput and end-to-end delay and lowers collision probability among control packets in two representative network scenarios.


---

## Body

## 1. Introduction

Underwater acoustic sensor networks (UANs), due to their wide scientific, commercial, and military applications including ocean sampling, environment monitoring, undersea explorations, distributed tactical surveillance, and disaster prevention, have become a very active research area during the past decade [1–3]. All these applications have motivated researches on UANs’ design. Since the acoustic signal is the only effective media for long-range transmission in water, the acoustic communication is considered to be an ideal technique for data transmission in the networks.However, due to the characteristic of acoustic signal including low transmission speed and narrow bandwidth, the implementation of UANs faces many challenges especially for media control access (MAC) scheme. In a layered network, MAC scheme is responsible for the scheduling of data’s transmission and reception. Because of the characteristic of acoustic signal compared with the radio signal, many existing MAC protocols dedicated for terrestrial sensor networks cannot be directly applied in UANs. In the past decades, researchers have developed many MAC protocols [4–7] to improve the performance of UANs.Initially, random access MAC protocols are widely studied. To overcome the long propagation delay feature of underwater acoustic signal, slotted-ALOHA is proposed in [8], which can increase the throughput performance by introducing guard time. Then, since the random access MAC scheme cannot avoid collisions efficiently, researchers begin to study reservation-based MAC scheme in underwater environment. Many reservation-based MAC protocols for UANs have been proposed including SFAMA [9] and DACAP [10]. Compared with random access MAC scheme, reservation-based MAC protocol can improve the network’s performance especially in a heavy traffic load situation.Although the existing underwater MAC protocols can achieve good performance theoretically, there are still challenges to apply those protocols to underwater systems. For many proposed reservation-based MAC protocols, with an assumption that the propagation time of control packets should be short enough, the collision problem among control packets is rarely considered. However, referring to existing underwater acoustic modem hardware design [11, 12], each packet has a relatively long preamble before the payload, which may last from 0.5 s to 1.5 s. Such design will increase the duration of both control packets and data packets and result in failure of many reservation-based schemes.In this paper, to explore a practical underwater MAC scheme, the collision probability of control packets on random access-based and reservation-based MAC protocols is first analyzed. Through the analyses, it is found that the collision problem among control packets can significantly reduce the success ratio of reservation. To solve this problem, then, a prescheduling and collision-avoided underwater MAC protocol named PC-MAC for a centralized underwater network is proposed. In PC-MAC, the sink node schedules the receiving time of RTS (request to send) packets and broadcasts this information to all sending nodes. Extra guard time is introduced to avoid the influence of spatial-temporal uncertainty. Hence, collisions between control packets can be avoided effectively.The reminder of this paper is organized as follows. In Section2, related works on underwater MAC protocols are presented. Section 3 analyzes the collision of control packet and the influence of node movements in MAC protocols. Details of the newly proposed MAC protocol are presented in Section 4. Simulations and analyses are in Section 5. Finally, Section 6 concludes this paper and gives guidance to future work.


## 2. Related Work

Before the solutions on collision-free MAC scheme for UANs are presented, some related works on existing MAC protocols in this section are introduced. To provide high throughput (goodput) in energy efficient way is of paramount importance for MAC design in UANs. A MAC protocol allows the nodes in a network to share the media while preventing collisions among packets from simultaneous transmission.In the past couple of years, there has been an amount of researches on the design and implementation of MAC protocols for UANs. For the proposed MAC protocols, they can usually be categorized into either “contention free” or “contention based,” while contention-free MAC protocols are simple paradigm which means that direct adoption in underwater networks is not necessarily an ideal solution. For example, a frequency division multiple access- (FDMA-) based MAC protocol and its improvements mainly face the design challenges of limited bandwidth. The time division multiple access- (TDMA-) based protocols mainly face the design challenges of synchronization and high propagation/transmission delay, while the near-far problem is the great challenge faced by code division multiple access- (CDMA-) based schemes.As for contention-based MAC protocols, they can be further classified into random access and handshaking protocols. Most random access schemes are developed purely from the ALOHA protocol which is easily implemented without any effort to prevent collisions. To overcome the shortcoming of pure ALOHA, a research on slotted ALOHA protocol for UANs has been presented. In the slotted ALOHA, nodes can only send out their packets at the beginning of one slot. Compared with the pure ALOHA, a slotted-based scheme can reduce the chances of collisions. However, due to the long propagation delay feature of the acoustic channel, [8] shows that the slotted ALOHA has a similar performance as the pure ALOHA.Handshaking or reservation-based MAC protocols are a significant type of contention-based MAC protocol. The basic idea of these protocols is that a sender has to capture the channel before sending out a packet. Reservation-based MAC protocols such as slotted FAMA [9] have been proved to have a better performance with heavier traffic loads. With the exchange of control packets, they can effectively alleviate collisions and achieve a relatively high network throughput. To deal with the synchronization in SFAMA, distance-aware collision avoidance protocol (DACAP) is proposed in [10]. DACAP is a collision avoidance protocol which can be easily implemented in scalable network. To reduce the negative impact of long delays, a modified four-way handshaking scheme, named MACA-U (multiple access collision avoidance for underwater), has been proposed in [11]. However, collision probability could be high in the MACA-U scheme.All the aforementioned protocols have significantly improved the performance of MAC layer in theory. However, many proposed MAC protocols fail to fully consider the hardware characteristics in the commercial modem-based real systems such as low transmission rates and long preambles. Previously, handshaking based MAC protocols are considered to be effective in collision avoidance since the transmission time of control packets are neglected. However, when considering the length of preamble of an acoustic modem, their transmission time becomes longer, which increases the collision probability. Later, in [12], the author illustrates the impact of long preamble and long transmission rate on MAC protocols named COD-TS. Then, they propose a time sharing-based MAC protocol and analyze its nodal throughput. However, even if the simulation result shows that the COD-TS can improve the throughput performance, it still cannot entirely avoid collision among packets. Therefore, solutions on collision-free MAC scheme for UANs are presented in the next section.


## 3. Modem Characteristic and Collision Analysis for Underwater MAC Protocol

### 3.1. Acoustic Modem Characteristic

In order to detect, synchronize, and estimate acoustic signal, a preamble sequence is applied in many existing acoustic modem’s physical layer frames. Different from the radio frequency signal-based hardware setting, the duration of the preamble for acoustic modem is extremely long and cannot be ignored anymore. Table1 shows the packet length of 3 existing underwater acoustic modems. From the table, it can be observed that even the shortest preamble lasts about 0.5 s. Since the preamble is necessary for every transmitted packet, it elongates the transmission time of packets and highly increases the collision probability.Table 1
Data packet length in different modems.
Modem type
Data rate
Preamble duration time
Packet duration time
Benthos ATM-855
800 bps
1.5 s
5.5 s
Aqua-sent
3.045 kbps
0.49 s
1.53 s
WHOI micromodem
300–5000 bps
0.87 s
1.5 s–11.54 s


### 3.2. Collision Analysis for Underwater Control Packet

The reservation-based MAC protocols show a better throughput performance compared with random access MAC protocols in heavy traffic load situation. In order to avoid the impact of long propagation delay, slotted FAMA is proposed. In slotted FAMA, time is divided into several slots. Packets are only allowed to be transmitted at the beginning of a slot. The focus of this paper is the collision analysis among control packets in the slotted reservation-based protocols in the following.It is assumed that each sensor node is deployed in a square field with a length of L. Among these sensors, node 0, considered to be the sink, is deployed in the center of the square field. Other three sending nodes (nodes 1, 2, and 3) are randomly deployed in the square field. The transmission time (including preamble and data section) of the RTS packet is set to be 0.5 s, and the distances between the sink node and three sending nodes (nodes 1, 2, and 3) ared1, d2, and d3, respectively. In order to avoid collisions among these RTS packets, the receiving time for each RTS packet is at least 0.5 s apart from each other. Since each RTS packet is sent at the beginning of a slot, only when the difference between di and dj, denoted as ΔdijΔdij=di−dji,j=1,2,3,i≠j, is larger than vs×t, where vs is the speed of sound and t is the time duration of control packet, can RTS packets be received without collisions, as shown in Figure 1.Figure 1
Relationship between distance and collision.Furthermore, in practical underwater environment, due to water current, wave, or other reasons, nodes’ positions are not fixed. Such movement can lead to the change of distance and the corresponding propagation delay. As an example shown in Figure2, when sending node 3 moves far away from the sink node, its RTS packet will arrive at the sink node later and collide with the RTS packet from sending node 2. While if sending node 3 moves closer, its RTS packet will arrive at the sink node earlier and collide with the RTS packet from sending node 1.Figure 2
Collision of RTS among moving nodes.Figure1 shows an example of the relationship between distance and collision. If Δd12, the distance difference between d1 and d2, is 750 m, RTS packets from node 1 and node 2 can reach node 0 consecutively without collisions. However, if Δd13, the distance difference between d1 and d3 is less than 750 m (it is 375 m), before node 0 completes receiving RTS packet from node 1, the RTS packet from node 3 starts arriving. There must be collisions between them. Based on geometric models of probability, the probability density function of the distance difference Δdij in different size of square areas is obtained, as shown in Figure 3.Figure 3
Probability density function curve of distance difference in different areas.From the probability density function curve in Figure2, it is observed that with the area getting smaller, the probability for two nodes’ distance difference larger than 750 m is getting lower. Calculation results show that when the length L of the area are 2000 m, 3000 m, and 4000 m, the collision probability of control packets are 93.41%, 77.08%, and 63.75%, respectively. From the result, it can be observed that even in a 4000 m × 4000 m area, when applying slotted reservation-based MAC protocols, the collision probability among control packets is relatively high.


## 3.1. Acoustic Modem Characteristic

In order to detect, synchronize, and estimate acoustic signal, a preamble sequence is applied in many existing acoustic modem’s physical layer frames. Different from the radio frequency signal-based hardware setting, the duration of the preamble for acoustic modem is extremely long and cannot be ignored anymore. Table1 shows the packet length of 3 existing underwater acoustic modems. From the table, it can be observed that even the shortest preamble lasts about 0.5 s. Since the preamble is necessary for every transmitted packet, it elongates the transmission time of packets and highly increases the collision probability.Table 1
Data packet length in different modems.
Modem type
Data rate
Preamble duration time
Packet duration time
Benthos ATM-855
800 bps
1.5 s
5.5 s
Aqua-sent
3.045 kbps
0.49 s
1.53 s
WHOI micromodem
300–5000 bps
0.87 s
1.5 s–11.54 s


## 3.2. Collision Analysis for Underwater Control Packet

The reservation-based MAC protocols show a better throughput performance compared with random access MAC protocols in heavy traffic load situation. In order to avoid the impact of long propagation delay, slotted FAMA is proposed. In slotted FAMA, time is divided into several slots. Packets are only allowed to be transmitted at the beginning of a slot. The focus of this paper is the collision analysis among control packets in the slotted reservation-based protocols in the following.It is assumed that each sensor node is deployed in a square field with a length of L. Among these sensors, node 0, considered to be the sink, is deployed in the center of the square field. Other three sending nodes (nodes 1, 2, and 3) are randomly deployed in the square field. The transmission time (including preamble and data section) of the RTS packet is set to be 0.5 s, and the distances between the sink node and three sending nodes (nodes 1, 2, and 3) ared1, d2, and d3, respectively. In order to avoid collisions among these RTS packets, the receiving time for each RTS packet is at least 0.5 s apart from each other. Since each RTS packet is sent at the beginning of a slot, only when the difference between di and dj, denoted as ΔdijΔdij=di−dji,j=1,2,3,i≠j, is larger than vs×t, where vs is the speed of sound and t is the time duration of control packet, can RTS packets be received without collisions, as shown in Figure 1.Figure 1
Relationship between distance and collision.Furthermore, in practical underwater environment, due to water current, wave, or other reasons, nodes’ positions are not fixed. Such movement can lead to the change of distance and the corresponding propagation delay. As an example shown in Figure2, when sending node 3 moves far away from the sink node, its RTS packet will arrive at the sink node later and collide with the RTS packet from sending node 2. While if sending node 3 moves closer, its RTS packet will arrive at the sink node earlier and collide with the RTS packet from sending node 1.Figure 2
Collision of RTS among moving nodes.Figure1 shows an example of the relationship between distance and collision. If Δd12, the distance difference between d1 and d2, is 750 m, RTS packets from node 1 and node 2 can reach node 0 consecutively without collisions. However, if Δd13, the distance difference between d1 and d3 is less than 750 m (it is 375 m), before node 0 completes receiving RTS packet from node 1, the RTS packet from node 3 starts arriving. There must be collisions between them. Based on geometric models of probability, the probability density function of the distance difference Δdij in different size of square areas is obtained, as shown in Figure 3.Figure 3
Probability density function curve of distance difference in different areas.From the probability density function curve in Figure2, it is observed that with the area getting smaller, the probability for two nodes’ distance difference larger than 750 m is getting lower. Calculation results show that when the length L of the area are 2000 m, 3000 m, and 4000 m, the collision probability of control packets are 93.41%, 77.08%, and 63.75%, respectively. From the result, it can be observed that even in a 4000 m × 4000 m area, when applying slotted reservation-based MAC protocols, the collision probability among control packets is relatively high.


## 4. PC-MAC: A Prescheduling and Collision-Avoided MAC Protocol

To avoid the frequent collisions in traditional slotted reservation-based MAC protocols, a novel underwater MAC scheme, named prescheduling and collision-avoided MAC protocol (PC-MAC), is proposed in this section. The proposed MAC protocol takes the spatial-temporal uncertainty issue into consideration. The network could achieve collision-free communication by prescheduling the receiving time of RTS and DATA packets. There are two assumptions in PC-MAC:(1)
Refer to the nodes’ movement in [13], it is assumed that the movement model for sensor nodes is the accumulation of several regular sine waves. Therefore, there exists the maximum range of movement, denoted as ΔD.(2)
It is also assumed that the fixed sink node is a central node in the sensor network, which is responsible for collecting the data generated by sensor nodes. Furthermore, sending nodes know the initial distance from the sink nodedi by many existing localization algorithms such as [14, 15] and corresponding propagation delay τi, where τi=di/v, with v the sound speed in underwater.The proposed PC-MAC is reservation-based MAC protocol. There are five types of packets applied in this protocol, namely, CONFIG, RTS, CTS (clear to send), DATA, and ACK. Among them, CONFIG, RTS, CTS, and ACK are control packets. The CONFIG packet is used to broadcast control information, and the other four kinds of packets are used for data’s transmission. Since CONFIG, CTS, and ACK are sent by sink nodes, there is no collision among these types of control packets. Therefore, the focus is the schedule of RTS packet and DATA packet.


### 4.1. Overview of the PC-MAC

An example is firstly used to show the workflow of PC-MAC. The proposed protocol is divided into two stages. In the first stage, the sink node preschedules the receiving time of each RTS packet and broadcasts the prescheduled time to all sending nodes in CONFIG packet. In the second stage, based on the receiving time for RTS packet, the sending nodes calculate their sending time for RTS packet and start transmission towards the sink node. In this example, there are two sending nodes (node 1 and node 2) and one sink node in this network, and in every DATA burst, a sending node can send more than one DATA packet (no more than 3 packets), as shown in Figure4.Figure 4
Work flow of PC-MAC.Since the sink node is responsible for data collection, it requires the collected data from its neighbors by broadcasting the CONFIG packets. The CONFIG packets contain the information that is responsible for scheduling of packets’ exchange from different senders which will be discussed in detail later. After receiving the CONFIG packets from the sink node, if the sending node has collected data to transmit, it will check the schedule of the transmission time of its RTS packets. The sending nodes will not send the RTS packets, which contain the length of the packet to be transmitted until the prescheduled time. While receiving the RTS packets, the sink node will prepare for CTS packet’s transmission. The CTS packets are used for the schedule for DATA packet transmission. Finally, after successfully receiving DATA packet, the sink node will schedule ACK to finish the handshaking process.


### 4.2. Prescheduling the Receiving Time of RTS Packet

In order to avoid collision among RTS packets, the sink node schedules the receiving time of RTS packet from different sending nodes with a consideration of their distances. To minimize the waiting time, the RTS packet from the nearest sending node is scheduled to arrive first. Now, the nearest node (node 1) is taken as an example to show how to preschedule the receiving time of RTS packets.Denote the starting time for a certain type of a packet from a certain nodeid by tid_packet. For example, t1r_DATA is the sink node’s receiving time for ith DATA packet from node 1. The length for packets is denoted as Ttype. Transformation interval, with its length of Ttransformation, is the time period between receiving and sending. Sending interval, with its length of Tsending_interval, is the time period between sending two successive DATA packets.Suppose the sink node is ready to receive the first RTS packet att1r_RTS. In order to avoid the influences of node’s movement, the sink node should set apart a guard time to deal with the possible drifting of the receiving time of RTS packet. As shown in Figure 5, the variation of distance is from 0 to ΔD, and the corresponding maximum variation of time is Δτ=ΔD/v. That is, the true propagation delay is between τ1−Δτ and τ1+Δτ. Therefore, to make sure that the RTS packet can be received successfully, the receiving window of the sink node is with the length of TRTS+2Δτ. In order to avoid collisions among RTS packets, the second RTS packet should arrive after t1r_RTS+TRTTS+2Δτ. From this example, the receiving time for all RTS packets is obtained, where i is the number of sending nodes.
(1)tir_RTS=t1r_RTS+i−1×TRTS+2Δτ.Figure 5
Scheme of the prescheduled receiving time for RTS packets.With the calculated receiving time of all RTS packets, the sink node can broadcast CONFIG packet. The prescheduled receiving times for RTS packet are contained in CONFIG packet.


### 4.3. Calculating the Sending Time of RTS Packet

Since the exchange of control packet is of consuming time and energy, the sending of DATA packet is designed in a burst way which means that a node is permitted to send DATA packet only if the number of DATA packet is beyond a threshold. Otherwise, it needs to wait for more DATA packets and then starts sending at the next round. For sending nodes which already have enough packets, they need to schedule their sending time for RTS packet according totir_RTS, and the number of DATA packet ni in the RTS packets.Node 1 is shown in Figure5 as an example; the sending node can use t1r_RTS to calculate the sending time for RTS packet following t1s_RTS=t1r_RTS−τ1+Δτ.Other sending nodes can calculate the sending time for their RTS packet in the same way. Knowing the sink node’s receiving time for RTS packetstir_RTS, each sending node can calculate its tis_RTS according to tis_RTS=tir_RTS−τi+Δτ.With the above strategy, the network can make sure that the RTS packet can be sent and received without collisions.


### 4.4. Managing the Sending Time of DATA and ACK Packet

Suppose thatM sending nodes (M ≤ N) request to send RTS packets and transmit DATA packets in the network, after receiving RTS packets, based on the number of DATA packets ni from each sending node, the sink node needs to schedule the receiving time of each DATA packet.It is assumed that the sink node is ready to receive the first DATA packet from the sending node 1 att1−1r_DATA. Similar to the reception of RTS packet, the setting of this period of time still needs to take the spatial-temporal uncertainty into consideration by applying a guard time Δτ. Therefore, the time duration of the reception of a DATA packet is TDATA+2Δτ and the receiving time for the ith DATA packet from sending node 1 is
(2)t1−ir_DATA=t1−1r_DATA+i−1×TDATA+2Δτ+Tsending_interval,where Tsending_interval is a period of time between sending two DATA packets.The time for receiving the last DATA packetn1th from sending node 1 is
(3)t1−n1r_DATA=t1−1r_DATA+n1−1×TDATA+2Δτ+Tsending_interval.When receiving all DATA packets from node 1 (n1 bursts in total) is finished, and after a period of time for transformation from receiving stage to sending stage (the length is denoted as Ttransformation), the sink node should send ACK packet to the sending node 1. So the sending time of this ACK packet is
(4)t1s_ACK=t1−n1r_DATA+2Δτ+TDATA+Ttransformation.In the same way, when finishing sending the ACK packet and after the transformation time, the sink node is ready for the receiving of DATA packets from the next sending node. The receiving time for the first DATA packet from the next sending node is(5)t2−1r_DATA=t1s_ACK+2Δτ+TACK+Ttransformation.All the receiving time for DATA packets and the sending time for ACK packets can be calculated following the strategy mentioned above. Then, the sink node should broadcast these prescheduled times in the CTS packet.When the sending nodes receive the CTS packet, they can calculate the sending time for each packet. As an example for node 1, the sending time forith DATA packet is
(6)t1−is_DATA=t1−ir_DATA−τ1+Δτ.With the prescheduled time, all nodes can send each packet without collision.


## 4.1. Overview of the PC-MAC

An example is firstly used to show the workflow of PC-MAC. The proposed protocol is divided into two stages. In the first stage, the sink node preschedules the receiving time of each RTS packet and broadcasts the prescheduled time to all sending nodes in CONFIG packet. In the second stage, based on the receiving time for RTS packet, the sending nodes calculate their sending time for RTS packet and start transmission towards the sink node. In this example, there are two sending nodes (node 1 and node 2) and one sink node in this network, and in every DATA burst, a sending node can send more than one DATA packet (no more than 3 packets), as shown in Figure4.Figure 4
Work flow of PC-MAC.Since the sink node is responsible for data collection, it requires the collected data from its neighbors by broadcasting the CONFIG packets. The CONFIG packets contain the information that is responsible for scheduling of packets’ exchange from different senders which will be discussed in detail later. After receiving the CONFIG packets from the sink node, if the sending node has collected data to transmit, it will check the schedule of the transmission time of its RTS packets. The sending nodes will not send the RTS packets, which contain the length of the packet to be transmitted until the prescheduled time. While receiving the RTS packets, the sink node will prepare for CTS packet’s transmission. The CTS packets are used for the schedule for DATA packet transmission. Finally, after successfully receiving DATA packet, the sink node will schedule ACK to finish the handshaking process.


## 4.2. Prescheduling the Receiving Time of RTS Packet

In order to avoid collision among RTS packets, the sink node schedules the receiving time of RTS packet from different sending nodes with a consideration of their distances. To minimize the waiting time, the RTS packet from the nearest sending node is scheduled to arrive first. Now, the nearest node (node 1) is taken as an example to show how to preschedule the receiving time of RTS packets.Denote the starting time for a certain type of a packet from a certain nodeid by tid_packet. For example, t1r_DATA is the sink node’s receiving time for ith DATA packet from node 1. The length for packets is denoted as Ttype. Transformation interval, with its length of Ttransformation, is the time period between receiving and sending. Sending interval, with its length of Tsending_interval, is the time period between sending two successive DATA packets.Suppose the sink node is ready to receive the first RTS packet att1r_RTS. In order to avoid the influences of node’s movement, the sink node should set apart a guard time to deal with the possible drifting of the receiving time of RTS packet. As shown in Figure 5, the variation of distance is from 0 to ΔD, and the corresponding maximum variation of time is Δτ=ΔD/v. That is, the true propagation delay is between τ1−Δτ and τ1+Δτ. Therefore, to make sure that the RTS packet can be received successfully, the receiving window of the sink node is with the length of TRTS+2Δτ. In order to avoid collisions among RTS packets, the second RTS packet should arrive after t1r_RTS+TRTTS+2Δτ. From this example, the receiving time for all RTS packets is obtained, where i is the number of sending nodes.
(1)tir_RTS=t1r_RTS+i−1×TRTS+2Δτ.Figure 5
Scheme of the prescheduled receiving time for RTS packets.With the calculated receiving time of all RTS packets, the sink node can broadcast CONFIG packet. The prescheduled receiving times for RTS packet are contained in CONFIG packet.


## 4.3. Calculating the Sending Time of RTS Packet

Since the exchange of control packet is of consuming time and energy, the sending of DATA packet is designed in a burst way which means that a node is permitted to send DATA packet only if the number of DATA packet is beyond a threshold. Otherwise, it needs to wait for more DATA packets and then starts sending at the next round. For sending nodes which already have enough packets, they need to schedule their sending time for RTS packet according totir_RTS, and the number of DATA packet ni in the RTS packets.Node 1 is shown in Figure5 as an example; the sending node can use t1r_RTS to calculate the sending time for RTS packet following t1s_RTS=t1r_RTS−τ1+Δτ.Other sending nodes can calculate the sending time for their RTS packet in the same way. Knowing the sink node’s receiving time for RTS packetstir_RTS, each sending node can calculate its tis_RTS according to tis_RTS=tir_RTS−τi+Δτ.With the above strategy, the network can make sure that the RTS packet can be sent and received without collisions.


## 4.4. Managing the Sending Time of DATA and ACK Packet

Suppose thatM sending nodes (M ≤ N) request to send RTS packets and transmit DATA packets in the network, after receiving RTS packets, based on the number of DATA packets ni from each sending node, the sink node needs to schedule the receiving time of each DATA packet.It is assumed that the sink node is ready to receive the first DATA packet from the sending node 1 att1−1r_DATA. Similar to the reception of RTS packet, the setting of this period of time still needs to take the spatial-temporal uncertainty into consideration by applying a guard time Δτ. Therefore, the time duration of the reception of a DATA packet is TDATA+2Δτ and the receiving time for the ith DATA packet from sending node 1 is
(2)t1−ir_DATA=t1−1r_DATA+i−1×TDATA+2Δτ+Tsending_interval,where Tsending_interval is a period of time between sending two DATA packets.The time for receiving the last DATA packetn1th from sending node 1 is
(3)t1−n1r_DATA=t1−1r_DATA+n1−1×TDATA+2Δτ+Tsending_interval.When receiving all DATA packets from node 1 (n1 bursts in total) is finished, and after a period of time for transformation from receiving stage to sending stage (the length is denoted as Ttransformation), the sink node should send ACK packet to the sending node 1. So the sending time of this ACK packet is
(4)t1s_ACK=t1−n1r_DATA+2Δτ+TDATA+Ttransformation.In the same way, when finishing sending the ACK packet and after the transformation time, the sink node is ready for the receiving of DATA packets from the next sending node. The receiving time for the first DATA packet from the next sending node is(5)t2−1r_DATA=t1s_ACK+2Δτ+TACK+Ttransformation.All the receiving time for DATA packets and the sending time for ACK packets can be calculated following the strategy mentioned above. Then, the sink node should broadcast these prescheduled times in the CTS packet.When the sending nodes receive the CTS packet, they can calculate the sending time for each packet. As an example for node 1, the sending time forith DATA packet is
(6)t1−is_DATA=t1−ir_DATA−τ1+Δτ.With the prescheduled time, all nodes can send each packet without collision.


## 5. Evaluations

In this section, the performance of PC-MAC protocol is evaluated. The performance metrics are successful reservation ratio, network’s throughput, and end-to-end delay. The successful reservation ratio is defined as the ratio of the number of packets sent by a sending node and the number of packets generated by this sending node. Network’s throughput is defined as the rate of successful message delivery over the network in bits per second. End-to-end delay is defined as the time duration between a DATA packet being received and this packet being generated. The following simulations are conducted by Aqua-sim, which is an NS2-based simulator dedicated for underwater acoustic networks. The simulation time is 2000 s in total, with the generated data following the Poisson distribution. The time duration for a packet can be calculated by(7)tpacket=tpreamble+lc,where tpreamble is the time duration of the preamble which is equal for all types of packets, l is the length of a packet in bits, and c is the transmission rate in bits per second. The simulation parameters are shown in Table 2.Table 2
Simulation parameters.
Parameters
Value
Transmission range
3000 m
Full power
40 W
Preamble
0.5 s/1 s
Packet size
100 bytesIn this section, the performance of PC-MAC in both sparse network and dense network scenarios is evaluated, respectively. In the sparse network, there are four nodes deployed in the network, among which node 0 is the sink node located in the center of the network; node 1, node 2, and node 3 are three sending nodes, which are randomly deployed in a 4000 m × 4000 m area. While in the dense network, there are three sending nodes randomly deployed in a 2000 m × 2000 m area. The maximum change of a sensor node in positionΔD is assumed to be 5 meters.


### 5.1. Successful Reservation Ratio

In this section, the collision probability in the classic MAC protocol named SFAMA in two different network scenarios is analyzed. Figure6(a) reflects the collision probability for SFAMA in the densely deployed scenario. From this figure, it can be observed that the collision probability of control packets rapidly increase as the packet generation rate rise. The simulation results also show that a longer preamble will result in a higher collision probability. If the packet generation rate reaches 0.08 packets/s for a longer preamble setting or 0.1 packets/s for a shorter setting, the collision among control packets will interrupt almost all data transmission in the network. Figure 6(b) shows the collision probability for SFAMA in the sparsely deployed scenario. The simulation results show a similar trend as the result in the dense network. From Figure 6(b), it can be observed that a sparser deployment can alleviate the collision problem. The reason is that the length of slot in SFAMA is determined by the maximum transmission range of between the sender and receiver. The length of the time slot in the sparse network scenario is longer than that in the dense network. Since the control packets will arrive at the sink node in one slot, a longer time slot can reduce the collision probability.Figure 6
Collision probability.
(a)
Dense
(b)
Sparse


### 5.2. Network’s Throughput

The network goodput is one of the most important metrics of the evaluation of the protocol. The simulation results are shown in Figures7(a) and 7(b) with varying packet generation rates for the two target MAC protocols and SFAMA and PC-MAC in two network scenarios. To further evaluate the impact of the length of preamble, the performance of SFAMA with two different length of preamble, 0.5 second and 1 second, is compared, respectively. Figure 7 reflects the performance of two protocols in the sparse network. From this figure, it is observed that PC-MAC achieves a better network goodput performance compared to SFAMA. From this figure, it can be also observed that, as for SFAMA, the shorter the preamble is, the higher the goodput can be achieved.Figure 7
Packet generation rate.
(a)
Dense
(b)
SparseThe reason is that a longer preamble of the hardware design can result in a higher reservation failure probability which directly decreases the network’s goodput. However, since the PC-MAC employs the collision avoidance scheme, the different length of preamble has little impact on the network’s performance. From Figure6, it can also be observed that, with the increase of the packet generation rate, the goodput performance may rapidly decrease for SFAMA, while it remains stable for PC-MAC. The performance deterioration of SFAMA is caused by too frequent collision among reservation packets.As for the dense network, the result of goodput performance shows a similar trend to the result of the sparse network. Figure7 shows that PC-MAC achieves a better network goodput performance. The gap between these two protocols becomes larger with the increase of packet generation rate. From the result, it is concluded that the collision avoidance scheme plays a much more significant role in the heavy traffic load situation. PC-MAC will benefit more in such network.


### 5.3. Average End-to-End Delay

Since the end-to-end delay is another critical metric of network, the end-to-end delay between PC-MAC and SFAMA is compared. In this simulation, the maximum lifetime of one packet is set to 1000 s, which means one node will drop the packet generated before 1000 s. Figure8 shows that PC-MAC can achieve a better end-to-end delay performance compared to SFAMA at two different length of preamble in two scenarios, respectively. The reason is that frequent collision among control packets leads to the delay of data packets’ transmission. PC-MAC can reduce queuing delay which further results in a shorter end-to-end delay by the collision avoidance scheme. It also can be observed that the minimum delay is around 40 s, which results from the delay of the hand-shaking process of the protocols.Figure 8
Time delay of different MAC protocols.


## 5.1. Successful Reservation Ratio

In this section, the collision probability in the classic MAC protocol named SFAMA in two different network scenarios is analyzed. Figure6(a) reflects the collision probability for SFAMA in the densely deployed scenario. From this figure, it can be observed that the collision probability of control packets rapidly increase as the packet generation rate rise. The simulation results also show that a longer preamble will result in a higher collision probability. If the packet generation rate reaches 0.08 packets/s for a longer preamble setting or 0.1 packets/s for a shorter setting, the collision among control packets will interrupt almost all data transmission in the network. Figure 6(b) shows the collision probability for SFAMA in the sparsely deployed scenario. The simulation results show a similar trend as the result in the dense network. From Figure 6(b), it can be observed that a sparser deployment can alleviate the collision problem. The reason is that the length of slot in SFAMA is determined by the maximum transmission range of between the sender and receiver. The length of the time slot in the sparse network scenario is longer than that in the dense network. Since the control packets will arrive at the sink node in one slot, a longer time slot can reduce the collision probability.Figure 6
Collision probability.
(a)
Dense
(b)
Sparse


## 5.2. Network’s Throughput

The network goodput is one of the most important metrics of the evaluation of the protocol. The simulation results are shown in Figures7(a) and 7(b) with varying packet generation rates for the two target MAC protocols and SFAMA and PC-MAC in two network scenarios. To further evaluate the impact of the length of preamble, the performance of SFAMA with two different length of preamble, 0.5 second and 1 second, is compared, respectively. Figure 7 reflects the performance of two protocols in the sparse network. From this figure, it is observed that PC-MAC achieves a better network goodput performance compared to SFAMA. From this figure, it can be also observed that, as for SFAMA, the shorter the preamble is, the higher the goodput can be achieved.Figure 7
Packet generation rate.
(a)
Dense
(b)
SparseThe reason is that a longer preamble of the hardware design can result in a higher reservation failure probability which directly decreases the network’s goodput. However, since the PC-MAC employs the collision avoidance scheme, the different length of preamble has little impact on the network’s performance. From Figure6, it can also be observed that, with the increase of the packet generation rate, the goodput performance may rapidly decrease for SFAMA, while it remains stable for PC-MAC. The performance deterioration of SFAMA is caused by too frequent collision among reservation packets.As for the dense network, the result of goodput performance shows a similar trend to the result of the sparse network. Figure7 shows that PC-MAC achieves a better network goodput performance. The gap between these two protocols becomes larger with the increase of packet generation rate. From the result, it is concluded that the collision avoidance scheme plays a much more significant role in the heavy traffic load situation. PC-MAC will benefit more in such network.


## 5.3. Average End-to-End Delay

Since the end-to-end delay is another critical metric of network, the end-to-end delay between PC-MAC and SFAMA is compared. In this simulation, the maximum lifetime of one packet is set to 1000 s, which means one node will drop the packet generated before 1000 s. Figure8 shows that PC-MAC can achieve a better end-to-end delay performance compared to SFAMA at two different length of preamble in two scenarios, respectively. The reason is that frequent collision among control packets leads to the delay of data packets’ transmission. PC-MAC can reduce queuing delay which further results in a shorter end-to-end delay by the collision avoidance scheme. It also can be observed that the minimum delay is around 40 s, which results from the delay of the hand-shaking process of the protocols.Figure 8
Time delay of different MAC protocols.


## 6. Conclusion

In this paper, the collision issue among control packets in MAC protocols for underwater acoustic networks is first evaluated. To address this problem, a novel MAC protocol named PC-MAC to reduce the collision probability and improve the throughput performance by prescheduling the reservation packets is proposed. PC-MAC initiates the hand-shaking process by the center nodes to avoid any possible random access packets. All the senders follow the schedule which is broadcasted by the centers. Simulation results show that PC-MAC improves the network’s goodput performance and reduces end-to-end delay in both dense and sparse network scenarios. Regarding future works, since the performance of the proposed scheme may be dependent on the topology of networks, it is essential for us to research a joint design of deployment and schedule scheme for underwater media access control algorithms.The underwater nodes are constantly moving due to ocean current, the waves of sea surface, and so on, which may result in interrupted communication between sensor nodes and sink nodes. The solution to guarantee reliable link should be considered in practical ocean environment. Besides, the guard time may be accommodated to different network deployment to increase the network goodput in practical implementation.



---

*Source: 4209301-2017-12-24.xml*