Python-Based TinyIPFIX in Wireless Sensor Networks

Round 1

Reviewer 1 Report

1. The authors design a TinyIPFIX-based system with an application layer protocol, which is now used to exchange data in WSNs efficiently.
2. The abstract section should be demonstrated in detail. What are the displayed valuable overhead and power efficiency properties for the proposed system?
3. The manuscript cited 18 papers; the number of the cited papers should be increased.
4. The manuscript has 13 figures; this numbers should be reduce
5. Please revise and enhance the English writing to increase readability.

Author Response

We would like to thank the reviewer for the time spent on the review of our paper and the valuable comments provided. 

Please find the response to the problems pointed out in the manuscript.

1. The authors design a TinyIPFIX-based system with an application layer protocol, which is now used to exchange data in WSNs efficiently.
   • -
2. The abstract section should be demonstrated in detail. What are the displayed valuable overhead and power efficiency properties for the proposed system?
   • We have added the following content to the abstract: "TinyIPFIX outperforms the data overhead of the Type-Length-Value (TLV) paradigm by a factor of 7% when a TinyIPFIX Data Message carries
     only two records, and one TinyIPFIX Template Message is sent per 3 TinyIPFIX Data Messages. A further decrease of overhead is observed when the number of data records per message and the number of TinyIPFIX Data Messages sent per one TinyIPFIX Template Message increase to larger values. The message delivery between End Devices and the application server resides at a very high level, close to 100%, when transmission reliability is secured with acknowledgments
     and retransmissions. The energy efficiency resides at the limited level, as the experienced deep sleep power consumption of the ESP32 device resided at the milliwatt level."
3. The manuscript cited 18 papers; the number of the cited papers should be increased.
   • We have increased the number of cited papers. Currently, we cite 30 items.
4. The manuscript has 13 figures; this number should be reduced
   • The number of figures was reduced to eight.
   • The number of tables is at the level of three.
5. Please revise and enhance the English writing to increase readability.
   • We have used Grammarly to revisit the content of the paper which should improve the presentation quality of the paper.

Reviewer 2 Report

Dear Authors

Very interesting what you propose, I suggest the following:

1. Improve the results of the energy consumption based on time, if possible show some graph.
2. Explain what other types of communication technologies (SIGFOX, BT, LoRa, etc) could support your proposal. 

 

Author Response

We would like to thank the reviewer for the time spent on the review of our paper and the valuable comments provided.

Please find the response to the problems pointed out in the manuscript.

1. Improve the results of the energy consumption based on time, if possible show some graph.
   • We have added the following: "Figure 7 shows the End Device and Concentrator current. In this setup, the End Device is configured to send measurements roughly every 10 seconds. It is visible that in
     the deep sleep mode (i.e., between readings), the device consumes around 35 mW, while the peaks are at 260 mW. The current consumed by Concentrator A is measured when no End Devices are
     attached to it. The Concentrator works consuming 355–400 mW power. As the power is measured in a dynamic state. Therefore, the power values might differ between this experiment and the previous experiment, in which the measured setup was static, i.e., residing in a given state for a longer duration (cf. Table 3)."
   • We have added Fig. 7 titled Current Measurements for an End Device and a Concentrator.
2. Explain what other types of communication technologies (SIGFOX, BT, LoRa, etc) could support your proposal.
   1. We have added the following: " The analysis of underlying communication protocols, which serve as the foundation
      for TinyIPFIX-based IoT systems is required to fully understand the benefits of TinyIPFIX. To properly support IoT use cases, several facets such as communication range, data rates, maximum transmission units (MTUs), communication protocol dependability, and energy efficiency are required. The IEEE 802.15.4 standard was created specifically for IoT devices in the range of a personal network, i.e., Wireless Personal Area Network (WPAN).
      Prototype IoT applications are often developed and analyzed in the context of Low Power Wide Area Networks (LPWAN), where Long Range (LoRa) Wide Area Network (WAN), Sigfox, IngenuRPMA, Weightless-N, Long Term Evolution (LTE) Machine Type
      Communication (MTC), i.e., LTE Cat-M or Narrowband-IoT (NB-IoT) communication technologies are currently under deployment.
      A brief overview of LPWANs is available in Table 1 based on [17,22,27]. These technologies are characterized in terms of communication range, throughput, and Medium Access Control (MAC) MTU sizes."
   2. We have added Table 1.
   3. We have added the following: "TinyIPFIX is especially of interest for communication technologies supporting very short MTUs, such as LoRaWAN, SigFox, IngenuRPMA, Weightless-N, or IEEE
      802.15.4. However, the impact of TinyIPFIX will be limited in cellular applications providing MTUs of 1600 Bytes because there is no need to save space in the case of a large MTU. Furthermore, TinyIPFIX is best suited for technologies allowing for in-network aggregation [12,26] like IEEE 802.15.4. Therefore, the advent of LoRa Mesh
      Network [6], which enables in-network aggregation on LoRa concentrators, can have a stimulating impact on the development of TinyIPFIX."

Reviewer 3 Report

This manuscript reports a platform based on using ESP32 to build a Wireless Sensor Network. TinyIPFIX protocol and architecture were set up and the performances of the systems i.e. the message transmission, transmission reliability and energy consumption were tested. As a whole data transmission sensing system, this report focuses more on the system configuration but lacks the implementation and a test of the system for a real sensing measurement. A simple temperature or humidity sensing might be helpful to evaluate the sensor network.

Author Response

We would like to thank the reviewer for the time spent on the review of our paper and the valuable comments provided.

Please find the response to the problems pointed out in the manuscript.

1. This manuscript reports a platform based on using ESP32 to build a Wireless Sensor Network.
   • -
2. TinyIPFIX protocol and architecture were set up and the performances of the systems i.e. the message transmission, transmission reliability, and energy consumption were tested.
   • We would like to thank the reviewer that they acknowledge the overall message of the paper.  
3. As a whole data transmission sensing system, this report focuses more on the system configuration but lacks the implementation and a test of the system for a real sensing measurement. A simple temperature or humidity sensing might be helpful to evaluate the sensor network.
   • We added a new section 4.2 on our implementation details: "One temperature record set is defined and transported between all devices (i.e., Concentrators and End Devices) and the Application Server. The record consists of a hardcoded node identifier (2 Bytes), temperature readout (4 Bytes), and textual timestamp (19 Bytes). The temperature value is provided by the hall temperature sensor residing on the ESP32 chip. The hall sensor returns an elevated temperature compared to the current room temperature. At the time of writing this article, the hall sensor provided the authors with around 27°C, when the experienced room temperature was around
     23°C. However, ESP32 is compatible with many sensors (e.g., based on UART connectors or providing a signal as voltage) attached to the Input/Output pins of the device. Finally, the timestamp is derived from the RTC attribute, which exposes a daytime function. The
     daytime returned is converted into the textual timestamp of 19 Bytes on the sensor."

Round 2

Reviewer 2 Report

Dear Authors 

Now, it is much better. 

Reviewer 3 Report

The authors have addressed my previous concern about this system to be demonstrated as a real sensing device.