Software-Defined Networking-Enabled Efficient Default Route Configuration in IEEE 802.15.4 Protocol: A Smart Algorithmic Approach

Round 1

Reviewer 1 Report

I quit agree that the SDN is not proposed for a Ad-Hoc network like WSN. Then what’s the benefit to involve SDN for WSN, as which already be “soft defined” with its self forming pattern? This issue may failed to be clearly discussed in the intro. Section. Also what’s the different between the proposed SDWSN and traditional WSN? Please clarify

The topology in fig.1 is slightly strange, as this configuration will contribute to a all-connected network with on 15cm between each node. Please clarify.

I appreciate that the authors have provide in-depth information for their implemented work, which is obvious good. However, the whole motivation should be strengthened. Also some too detail information may be removed to focus on the main contribution.

Author Response

Author Response File: Author Response.pdf

Reviewer 2 Report

While the introduction provides a foundation for the article, it could benefit from more explicit connections between the background information and the specific focus of the research, along with a more comprehensive literature review. Providing a clear statement of the problem and the contributions of the research would enhance the overall clarity and impact of the introduction.

It is suggested that the authors enhance the background section by offering additional context regarding the specific challenges or limitations within the current state of Software-Defined Wireless Sensor Networks (SDWSNs) utilizing IEEE 802.15.4. This augmentation would contribute to a deeper understanding of the research context and enrich the overall content of the paper.

The authors' emphasis on showcasing the performance improvement pre and post-implementation of the proposed algorithms is notable. However, it would be valuable to include a comparative analysis with existing methods. Incorporating a comparison of the obtained results with those from established approaches in the field would enhance the robustness of the study and provide a more comprehensive evaluation of the proposed algorithms.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

Applying SDN algorithm in WSN is an interesting topic, but sadly in my opinion ,the experiments presented in the paper paper have several flaws/unclear methodological issues that hinder the claims made by the authors and should be clarified in order to accept the paper. 

According to the authors they have conducted their tests uniquelyy in a real testbed comprised by several microcontrolled-based WSN nodes in which they have deployed their algorithm. However, there are some hints that reveal that it may no have been the case, and they have instead used a mix of real testing & simulation under some assumptions. If this is the case, my recommendation to the authors is to state that clearly in the paper instead of trying to conceal it. 

I'll try to summarize some of the issues that I think should be clarified:

1) The authors claim that they measure the "transmission time between nodes...without considering processing at the nodes". Could you please explain how is exactly this measurement performed, by using which tools, and how can be the processing at the nodes "eliminated" from the measurement?

2) Can you explain why this transmission time is always 3ms between some nodes (fig 9), and up to 10ms between others (for example 8 and 2 in fig 11, 2 and 8 in fig 21 and 22) even if there is no "hopping"?

3) In the tested scenario all the nodes are in the reach of every one other node (they are 15cm appart from each other), and also in reach of the "controller". Thus the controller can receive information of all nodes without routing. In fact, no routing is needed in such an scenario and the best strategy would always be direct transmission instead of hopping through several nodes.  

4) The authors seem to ignore the real energy consumption behaviour of 802.15.4 real transceivers. For most real transceivers the current drained from the battery is quite similar for the listeting/receiving and transmitting operations. Furthermore, the current drained during transmission does not change that much depending on the transmission power and thus with the distance to the intended receiver (which is not necessarily known, by the way). That is the reason why in 802.15.4 standards as zigbee, routing nodes (also called FFD), that have to be continuosly listening  waste much more energy than End-Devices (which are allowed sleep and enter the Idle state of the transceiver). Routers waste a great deal because of having to be in the listening state most of the time. Of course they waste a bit more of energy if they also have to retransmit packets, but not depending on the distance to the intended receiver. 

5) Authors seem also to have neglected the behaviour of the 802.15.4 MAC. This is another clue hinting that they have carried out most of their study by simulation under certain assumptions, instead of real tests as they claim.

The English of the paper is mostly finished, although I recommend a final editing if it finally published.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 3 Report

The authors have corrected some of the results included in the previous version of the paper. They have now clearly stated the different stages involved in the transmission of a message and added some diagrams in order to clarify it. The order od the stages, however is not correct (clear channel assesment and backoff actually happen before packet tranmissions, not after.), but it's an improvent respecto to the previous version. 

I agree with the authors that packet's "hoping time" in the routers/packet forwarding nodes can be measured with the sniffer, but what I don't believe can be measured with the sniffer is the time the originating/source node takes to send a packet to the first relay node, because the sniffer can only detect the packet when it is already "in the air". Consequently (or, also), If there is only one hop, the end-to.end  delay can't be measured using the sniffer. 

The authors have provided the source code for their testbed, which is nice and a good practice in general. However, the source code in the github repositories they have linked in the references is quite poorly documented. There is not a README file explaining the code or the structure, and the source code itself is commented in Spanish, not in English. The code sould be better formatted, presented and documented if it is going to be cited in the references. 

In addition to this, I must say that the implementation seems a"minimum viable prototype" (and very "minimum", indeed), in which a lot of values corresponding to the tested scenario (number of nodes, addresses, etc) have been "hardcoded", array limits are not correctly tested, so they could be "overflowed" (in the C code for the microcontroller), and so on. 

All this do not help to support the claims made by the authors, but since the other reviewers think the paper is suitable for publication, I am not going to be the one hindering it. However, I recomend the author to tidy and better document their source code, and clearly state that is a very basic minimum vialble prototype in the documentation. 

English is mostly fine.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf