Next Article in Journal
Low-Cost Unified Pixel Converter from the MIPI DSI Packets into Arbitrary Pixel Sizes
Next Article in Special Issue
Adversarial Attack and Defense: A Survey
Previous Article in Journal
Applying Collective Intelligence in Health Recommender Systems for Smoking Cessation: A Comparison Trial
Previous Article in Special Issue
A Lightweight Remote Sensing Image Super-Resolution Method and Its Application in Smart Cities
 
 
Article
Peer-Review Record

Lightweight Path Recovery in IPv6 Internet-of-Things Systems

Electronics 2022, 11(8), 1220; https://doi.org/10.3390/electronics11081220
by Zhuoliu Liu 1, Luwei Fu 1,*, Maojun Pan 2 and Zhiwei Zhao 1
Reviewer 1: Anonymous
Reviewer 2: Anonymous
Electronics 2022, 11(8), 1220; https://doi.org/10.3390/electronics11081220
Submission received: 28 February 2022 / Revised: 31 March 2022 / Accepted: 6 April 2022 / Published: 12 April 2022
(This article belongs to the Special Issue Edge Computing for Urban Internet of Things)

Round 1

Reviewer 1 Report

The authors propose a Lightweight Path Recovery algorithm (LiPa) to recover the unknown path iteratively in an IoT network. The algorithm determines the path followed by the packet between source and destination.

The approach and the contributions are clearly presented. The English are good.

However, the utility of the solution is not clear. If I understood correctly, the solution would run in a Low power and Lossy Network running RPL as routing protocol. It is not clear why one would need an additional protocol to perform patch recovery, which, if I understood correctly, seems to refer to finding the whole path between the source and destination. How is this path information used and by whom?

Also, the algorithm is running on the sink nod. What does the sink node do with this information? It is not clear at all.

Which is the node ID? In one place you mention: “The information needed in packet k is as follows: the source node o(k) and the destination node d(k) which are already contained in the IPv6”. From this phrase, it seems that the ID is the IPv6 address. In another place, you mention: “occupied by a node ID, i.e. 2 bytes in our network model”, so it seems ID is not the IPv6.

If the ID is not the IPv6 address, who assigns it to all nodes in the network?

The algorithm seems to be computationally expensive. Not clear how the sink node is able to run it, being a low power device.  No evaluation of the computational requirements has been performed. You presented only the advantages of your solution. My guess is that its main drawback is related to the computational and power resources required.

Some minor spell check errors should be corrected. For example, “The hash value of the upstream path, denotes as h(k)”, probably should be … denoted as h(k).

 

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

This work investigates lightweight path recovery scheme that explores the potential correlation of routing paths between different nodes using the node information of parent and grandpa.. The following revisions are required.

  1. In literature review, add 3 to five more relevant and latest techniques.
  2. Add Comparison table at the end of section 2 and compare with at least 10 to 15 techniques with appropriate parameters.
  3. Please make sure your paper has necessary language proof-reading.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Thank you for the additional details. 

I still have some questions about your solution.

If I understood correctly, your solution runs on top of the RPL routing protocol. So, it's like running two routing protocols that complement each other.  It is not clear to me if the other existing solutions are based on RPL, too. If not, it means that your solution has additional costs in terms of power consumption and network overhead, which explains the good scores obtained compared to the other solutions.

Also, the complexity of your algorithm is not discussed.

It seems that you are presenting only the positive aspects of your solution, without considering the drawbacks. 

  Also, it is not clear how the 2 byte IDs are allocated during the initialization phase, considering that it is a multi-hop sensor network. Is this common for the other existing solutions. If not, it seems that this is an additional cost that came with your solution, which was not taken into consideration.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 3

Reviewer 1 Report

Thank you for the clarifications!

Back to TopTop