kumoh national institute of technology
Networked Systems Lab.

Review

NSL > Education> Review
Alif - IEEE LANMAN 2017
By :
Date : 2017-04-21
Views : 13

Dear Mr. Pranata

We are delighted to inform you that your paper "Towards an IoT-based Water Quality Monitoring System with Brokerless Pub/Sub Architecture" http://edas.info/showPaper.php?m=1570349363 has been accepted for publication as a long paper (6 pages) in IEEE LANMAN'17. Congratulations!

Comments from the reviewers are appended to this e-mail, and are also available at the submission site. Please revise your paper according to the comments and improve it both in content and English as much as possible, to be accepted into IEEE Xplore. The deadline for camera-ready submission is May 9, 2017.

We will be providing further camera ready instructions and visa information in the next few days.

Per IEEE ComSoc policy, please note that at least one author of the paper MUST register for the conference and present the paper at the conference. Otherwise, your paper will not be forwarded for archival in IEEE Xplore. One registration is valid for up to 3 papers by an author.

We look forward to seeing you in Osaka!

Tommaso Melodia, Timothy Wood
IEEE LANMAN 2017 TPC Co-Chairs

Zhangyu Guan
IEEE LANMAN 2017 TPC Vice-Chair for Information Systems (EDAS)


======= Review 1 =======

> *** Familiarity: Please assess your familiarity with the subject matter of the paper
Working in this area of research (5)

> *** Novelty: Assess the originality of the work and its contribution to the area of research
Complete lack of original ideas (1)

> *** Recommendation: Should the paper be accepted or rejected?
Likely reject (2)

> *** Strengths: What are the major contributions of this paper? Why should the paper be accepted?

- The authors have built a prototype. The evaluation is quite good too
- The authors have done a price comparison of their setup versus related work and that is appreciable

> *** Weaknesses: What are the most important reasons NOT to accept this paper?

- the main contribution is to replace a broker with a broker less system.

> *** Summary and Comments: Brief summary and comments to the authors. Especially in the case of a negative recommendation, please explain why the paper is not good enough.

- the architecture/use-case does not make a convincing argument for a brokerless pub/sub. The proposed solution is also quite simplistic and is a widely known alternate. I.e, instead of the broker taking care of subscriptions, the publisher will have to know about all the interested subscribers.

======= Review 2 =======

> *** Familiarity: Please assess your familiarity with the subject matter of the paper
Familiar with this area of research (3)

> *** Novelty: Assess the originality of the work and its contribution to the area of research
Variation of a known concept (3)

> *** Recommendation: Should the paper be accepted or rejected?
Likely reject (2)

> *** Strengths: What are the major contributions of this paper? Why should the paper be accepted?

In this paper, the authors propose a brokerless publication/subscription architecture for the water quality monitoring system. A system is implemented and presented within the paper. By compared with the existing solutions, the authors demonstrate that the performance of their system is better than the existing ones.

> *** Weaknesses: What are the most important reasons NOT to accept this paper?

The structure of the paper is not very reasonable. The experimental part takes the major space of the paper, and the algorithms listed in the paper do not fully explain.

Some of the items listed in the paper do not make sense. For examples, Table 3 compare the prices with two of existing solutions. However, the paper is not to provide a cost-effective solution, what is the point for making such comparison within such limited space? Moreover, if the price difference is made by employing MQTT, then such comparison is also acceptable. However, it doesn't seem to Reviewer the authors mean that as well.

The take home message is not clear to Reviewer, since the authors sometimes want to demonstrate the quality of the water monitoring is good, and sometimes want to show the system performance is better than MQTT-based system.

> *** Summary and Comments: Brief summary and comments to the authors. Especially in the case of a negative recommendation, please explain why the paper is not good enough.

The organization/structure of the paper is not reasonable, the authors need to modify it and make sure the paper content matches the topic/research question more closely.

======= Review 3 =======

> *** Familiarity: Please assess your familiarity with the subject matter of the paper
Familiar with this area of research (3)

> *** Novelty: Assess the originality of the work and its contribution to the area of research
Variation of a known concept (3)

> *** Recommendation: Should the paper be accepted or rejected?
Definite accept (5)

> *** Strengths: What are the major contributions of this paper? Why should the paper be accepted?

The introduction of a real-time water quality monitoring system by using a proposed broker-less publisher-subscriber (pub/sub) architecture framework is very thoughtful, since an MQTT comparison is provided.

> *** Weaknesses: What are the most important reasons NOT to accept this paper?

Some smaller weaknesses are part of the summary and comments section below, and need to be addressed for the final version of the paper if being accepted.

> *** Summary and Comments: Brief summary and comments to the authors. Especially in the case of a negative recommendation, please explain why the paper is not good enough.

Sec I introduces and motivates well, why water-quality is important, it needs a bit the technology arguments, why IoT is the way to go to make such a problem solvable and secure!

The need for a real-time version may benefit from a clear argument, too.

Related work in Sec II may need some clearly measurable dimensions against which you compare your approach. Thus, the MQTT solution should be discussed, too.

A bit surprising is the fact that Sec III does start with MQTT approach and not the pub/sub one - why? The reason for selecting Arduinos is not well clear. The device's architecture is good.

The analysis in Sec IV is great - and the economic dimension very convincing. But the selection of exactly those sensors is not well explained.

Finally, Sec V does contain a summary, but no conclusions - thus, either change the section's title or add real conclusions, which show that your approach benefits a use case, people, etc - all that is missing.
 
Ʒ ̺
     
Ʒ  WILLIAMS - WFCS 2017