Data Gathering in UWA Sensor Networks: Practical Considerations and Lessons from Sea Trials

Round 1

Reviewer 1 Report

A cross-layer networking solution for data gathering in UASNs was proposed in this paper, including a network discovery protocol, intelligent routing with relay load balancing, scheduling via TDA-MAC, multi-node ARQ, and sleep mode management. Besides, an experimental testbed and underwater sensor node prototype has been used for the trials. Comments are as follows:

The setup of the proposed protocol has not been clearly formulated. For example, are the working frequency for each link the same? Is the performance of the system influenced by the interference from other links?

Has the synchronization been considered in the protocol?  

The complexity of the proposed protocol should be further discussed.

What does the number in Fig. 18 mean?

Author Response

We would like to thank the reviewer for their useful comments. Please see our responses to each point below. All changes to the manuscript are highlighted in yellow. 

1) The setup of the proposed protocol has not been clearly formulated. For example, are the working frequency for each link the same? Is the performance of the system influenced by the interference from other links?

Yes, that is an important point to add to the paper. The protocol is designed for single-band, single-channel acoustic networks, where the key task of the MAC protocol is to avoid interference among multiple nodes. We revised Section 2.4.1 on MAC to address this (l.357-360).

2) Has the synchronization been considered in the protocol?  

A crucial feature of the TDA-MAC protocol is that the nodes do not require clock synchronization. We revised the text on l.362 to stress this point.

3) he complexity of the proposed protocol should be further discussed.

That is indeed an interesting topic, and particularly relevant for the network discovery protocol, as it has O(N^2) complexity and can take a variable time to complete. The other parts of the protocol (the network setup and data gathering phases) have a lower complexity and have been verified to work efficiently in our previous work. We added the discussion on complexity throughout the paper, both in the protocol description and in the discussion of results and further work. The changes were made on l.206-211, l.223-225, l.847-852.

4) What does the number in Fig. 18 mean?

These numbers show the link quality indicator (integer 1-5). We updated the Figure caption (now Figure 21) to make this clearer.

Reviewer 2 Report

I suppose 3a to be replaced by 3b at line no. 287

Author Response

Thank you for spotting this error:

1) I suppose 3a to be replaced by 3b at line no. 287

We changed the reference to 3b (l. 290 of the updated manuscript).

Reviewer 3 Report

This paper proposes a complete cross-layer networking solution for data gathering in UASNs, which includes a network discovery protocol, intelligent routing with relay load balancing, scheduling via TDA-MAC, multi-node ARQ, and sleep mode management. The experimental results verify its feasibility in some specified topologies and the paper is well written, but there are still some issues should be addressed before publication.

1. As the paper focuses on the data gathering, the pseudo-code of the data gathering code should be added in the paper.

2. The formats of some used packets, such as ACK and TDI packets, should be given.

3. In the introduction, the author should address the novelty of this paper compared with author’s previous published papers with more details.

4. How the topology as in the lake trials affects the experimental results? The author should analyze if there is any limitation in topology.

Author Response

We would like to thank the reviewer for their useful comments. Please see our responses to each point below. All changes to the manuscript were highlighted in yellow.

1) As the paper focuses on the data gathering, the pseudo-code of the data gathering code should be added in the paper.

We chose to use flowcharts to describe all protocol logic in this paper, as we found them to be a better way of describing the workings of our proposed stack than pseudo-code. And although data gathering is the main application of the UASNs considered in this paper, our protocol stack consists of multiple phases, all of which are crucial. Therefore, to maintain consistency across all parts of Section 2, we kept the flowcharts instead of pseudo code. We hope that this is acceptable to the reviewer.

2) The formats of some used packets, such as ACK and TDI packets, should be given.

Indeed, this is a useful addition to the paper. Previously, only the structure of the REQ packet was included, as it was used to describe how some of the novel protocol features were implemented. We have now significantly expanded Section 2.5 (l.390-405, l.433-455, Figs 6-9) to include the formats of all key packets used for network discovery, setup and data gathering phases.

3) In the introduction, the author should address the novelty of this paper compared with author’s previous published papers with more details.

Describing the novel contributions of this paper is the focus of Section 1.4. We revised it to describe them more clearly in relation to our previous published work (l. 152-155).

4) How the topology as in the lake trials affects the experimental results? The author should analyze if there is any limitation in topology.

The lake conditions (depth, vegetation etc.) have indeed limited the connectivity options for our lake experiment topologies. However, a similar problem can be expected in many realistic network deployments; therefore, it did not "affect" the experiments in any negative way as such, it just provided a sufficiently challenging test case for our network prototype to deal with. We added a short discussion on this on l.561-565.

Reviewer 4 Report

* eq(1) - what the $n$ stands for in $\tau_p[n]$? So, what is the adaptation procedure? In Fig.2.(b)  one shows that timeout is calculated only once per "ping" discovered node. Thus, how it would be an "adaptive timeout"?

* line 307 - it is not necessary to explain ARQ abbreviation because it is explained in the introduction (line 8)

* There is some inconsistency between equations (11,12) and Fig.5 I mean $\tau_{dp}$ is explained as "data packed duration" while in Fig.5 there is a symbol $\tau_{rp}$ not explained. I infer that it is a "REQ packed duration".

Author Response

We would like to thank the reviewer for their useful comments. Please see our responses to each point below. All changes to the manuscript are highlighted in yellow.

1) eq(1) - what the $n$ stands for in $\tau_p[n]$? So, what is the adaptation procedure? In Fig.2.(b)  one shows that timeout is calculated only once per "ping" discovered node. Thus, how it would be an "adaptive timeout"?

Here $n$ denotes the index of the target node; it is included to stress that there can be multiple target nodes, all of which with a different propagation delay and therefore a different timeout value (as calculated in (1)). We revised l.226-227 to clarify this. Regarding the adaptivity of the timeout, what we meant is that it adapts to the propagation delays to different target nodes (e.g. becomes shorter for closer nodes, and longer for further nodes). However, the reviewer is right in saying that from the point of view of a single target node the timeout is calculated once and does not adapt over time (because it does not need to if the node is quasi-static). We revised the text on p. 7 just before equation (1) to remove the term "adaptive" and avoid this confusion.

2) line 307 - it is not necessary to explain ARQ abbreviation because it is explained in the introduction (line 8)

Thank you for spotting this. This was corrected.

3) There is some inconsistency between equations (11,12) and Fig.5 I mean $\tau_{dp}$ is explained as "data packed duration" while in Fig.5 there is a symbol $\tau_{rp}$ not explained. I infer that it is a "REQ packed duration".

Yes, the reviewer is correct. The problem was that the duration of the REQ packet (\tau_{rp}) is not actually used in any of the equations (as it is not needed), but it was still annotated in Figure 5 for completeness. We revised l. 364,367-368 of the manuscript to explain these terms.