## 2 An Underwater Multi-DATA Train Protocol with Multi-RTS Reception and BACK  
We consider an underwater acoustic sensor network which consists of an underwater sink node and multiple underwater sensor nodes. In the underwater acoustic sensor network, we consider that the underwater sink node and the underwater sensor nodes can hear each other via an underwater acoustic channel. Each underwater sensor node can transmit sensory information to the underwater sink node using our proposed underwater multi-DATA train protocol with multi-RTS reception and BACK, which can be shortly called an _underwater multi-DATA train protocol_. As shown in Figure 1, the proposed underwater multi-DATA train protocol is based on the CSMA/CA protocol using the RTS/CTS exchange method. An underwater sensor node, which has sensory information to transmit to an underwater sink node, can check the status of an underwater medium by performing the carrier sensing via an underwater acoustic channel. If the sensor node cannot hear any frame via the underwater acoustic channel during a slot time, the sensor node decrements the value of its own back-off counter by one. Otherwise, the sensor node freezes the value of its own back-off counter. If the value of back-off counter of the sensor node becomes zero, the sensor node sends an RTS frame to the underwater sink node. In the proposed underwater multi-DATA train protocol, our RTS frame contains ID of the RTS sending node and a timestamp. Using this timestamp, the underwater sink node can calculate the underwater propagation delay between the RTS sending node and the sink node. If more than one sensor node sends RTS frames simultaneously, the sent RTS frames may collide at the sink node. But, due to long underwater acoustic propagation delay, some sent RTS frames may not overlap at the sink node in the time domain, even if the RTS frames were sent from different sensor nodes to the sink node simultaneously. We consider that our underwater sink node can recover these nonoverlapping multiple RTS frames, that we can call _multi-RTS reception_ at the underwater sink node. Using the recovered RTS frames each of which contains ID of its sending node and a timestamp, the underwater sink node calculates the underwater propagation delay between each RTS sending node and the sink node. Using the calculated propagation delay and ID of each RTS sending node, the underwater sink node broadcasts a CTS frame. In the proposed underwater multi-DATA train protocol, our CTS frame contains the time information about when each RTS sending node can transmit a DATA frame to the underwater sink node. From this time information contained in our CTS frame, multiple DATA frames each of which is transmitted from each RTS sending node to the sink node can be formed as a train, that we can call a _multi-DATA train_ formed at the sink node. The time information in our CTS frame can make each RTS sending node transmit a DATA frame to the sink node in ascending order of the calculated propagation delay between each RTS sending node and the sink node. The time information in our CTS frame can also make the nearest RTS sending node to the sink node transmit a DATA frame immediately after receiving the CTS frame and a short guard time. The short guard time can be a short inter-frame space (SIFS) [5; 6]. The multi-DATA train formed at the sink node can contain a short guard time between DATA frames. After receiving the train of multiple DATA frames from the RTS sending nodes, the underwater sink node broadcasts a BACK frame which contains the information about whether each DATA frame was successfully received or not. Each underwater sensor node which transmitted the DATA frame chooses a back-off counter value randomly between zero and a contention window size. The contention window size can be controlled to enhance the performance of the proposed underwater multi-DATA train protocol.