Lightweight Path Recovery in IPv6 Internet-of-Things Systems
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.
- In literature review, add 3 to five more relevant and latest techniques.
- Add Comparison table at the end of section 2 and compare with at least 10 to 15 techniques with appropriate parameters.
- 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!
