-\noindent {\bf 1.} The protocol framework is not described in details. In particular, the spatial and temporal subdivision (page 2, line 11) that is at the core of PeCO, is not described nor justified in much detail. How to implement an efficient spatial subdivision? On page 10, line 11, the number of subdivisions is said to be equal to 16, but the clustering algorithm used is not mentioned. Is this number dependent of the size of the sensing area? Of the number of sensors? Of the sensing range? The proposed protocol cannot be adopted by practitioners if such an important step is not documented. Temporal subdivision suffers from the same lack of description and justification: why should time intervals have the same duration? If they have the same duration, how should this common duration should be chosen? \\
-
-\textcolor{blue}{\textbf{\textsc{Answer:} Spatial and temporal choices of subdivision are not the topics of the paper. In the study, we assume that the deployment of sensors is almost uniformly over the region. So we only need to fix a regular division of the region into subregions to make the problem tractable. The subdivision is made such that the number of hops between any pairs of sensors inside a subregion is less than or equal to 3. Concerning the choice of the sensing period duration, it is correlated with the types of applications, with the amount of initial energy in sensors batteries and also with the duration of the exchange phase. All applications do not have the same requirements of Quality of Service. Here information exchange is executed every hour but the length of the sensing period could be reduced and adapted dynamically. On the one hand a small sensing period would allow to be more reliable but would have higher communication costs. On the other hand the choice of a long duration may cause problems in case of nodes failure during the sensing period. Explanation has been given throughout the paper. In particular the sensing duration is discussed in section 5.1.}}\\
-
-
-\noindent {\bf 2.}Page 9, Section 4, is the Perimeter-based coverage problem NP-hard? This question is important for justifying the use of a Mixed Integer Linear Programming model. \\
-
-\textcolor{blue}{\textbf{\textsc{Answer:} The perimeter scheduling coverage problem is NP-hard in general, it has been proved
- in the paper entitled "Perimeter Coverage Scheduling in Wireless Sensor Networks Using Sensors with a Single Continuous Cover Range" from Ka-Shun Hung and King-Shan Lui (EURASIP Journal on Wireless Communications and Networking 2010, 2010:926075 doi:10.1155/2010/926075). In this paper, authors study the coverage of the perimeter of a large object requiring to be monitored. In our study, the large object to be monitored is the sensor itself (or more precisely its sensing area). This point has been highlighted at the beginning of section 4. }}\\
-
-
-\noindent {\bf 3.} Page 9, the major problem with the present paper is, in my opinion, the objective function of the Mixed Integer Linear Program (2). It is not described in the paper, and looks like an attempt to address a multiobjective problem (like minimizing overcoverage and undercoverage). However, using a weighted sum is well known not to be an efficient way to address biobjective problems. The introduction of various performance metrics in Section 5.1 also suggests that the authors have not decided exactly which objective function to use, and compare their protocols against competitors without mentioning the exact purpose of each of them. If the performance metrics list given in Section 5.1 is exhaustive, then the authors should mention at the beginning of the paper what are the aims of the protocol, and explain how the protocol is built to optimize these objectives. \\
-
-\textcolor{blue}{\textbf{\textsc{Answer:} Right. The mixed Integer Linear Program adresses a multiobjective problem, where the goal is to minimize overcoverage and undercoverage for each coverage interval for each sensor. As far as we know, representing the objective function as a weighted sum of criteria to be minimized in case of multicriteria optimization is a classical method. In section 5, the comparison of protocols with a large variety of performance metrics allows to select the most appropriate method according to the QoS requirement of the application. }}\\
-
-
-\noindent {\bf 4.}Page 11 Section 5.2, the sensor nodes are said to be based on Atmels AVR ATmega103L microcontroller. If I am not mistaken, these devices have 128 KBytes of memory, and I didn't find any clue that they can run an operating system like Linux. This point is of primary importance for the proposed protocol, since GLPK (a C API) is supposed to be executed by the cluster leader. In addition to that, GLPK requires a non negligible amount of memory to run properly, and the Atmels AVR ATmega103L microcontroller might be insufficient for that purpose. The authors are urged to provide references of previous works showing that these technical constraints are not preventing their protocol to be implemented on the aforementioned microcontroller. Then, on page 13, in Section "5.2.3 Energy Consumption", the estimation of $E_p^{com}$ for the considered microcontroller seems quite challenging and should be carefully documented. Indeed, this is a key point in providing a fair comparison of PeCO with its competitors. \\
+\noindent {\bf 1.} The protocol framework is not described in details. In
+particular, the spatial and temporal subdivision (page 2, line 11) that is at
+the core of PeCO, is not described nor justified in much detail. How to
+implement an efficient spatial subdivision ? On page 10, line 11, the number of
+subdivisions is said to be equal to 16, but the clustering algorithm used is not
+mentioned. Is this number dependent of the size of the sensing area? Of the
+number of sensors? Of the sensing range? The proposed protocol cannot be adopted
+by practitioners if such an important step is not documented. Temporal
+subdivision suffers from the same lack of description and justification: why
+should time intervals have the same duration? If they have the same duration,
+how should this common duration should be chosen?\\
+
+\textcolor{blue}{\textbf{\textsc{Answer:} Spatial and temporal choices of
+ subdivision are not the topics of the paper. In the study, we assume that
+ the deployment of sensors is almost uniform over the region. So we only
+ need to fix a regular division of the region into subregions to make the
+ problem tractable. The subdivision is made such that the number of hops
+ between any pairs of sensors inside a subregion is less than or equal
+ to~3. Concerning the choice of the sensing period duration, it is correlated
+ with the types of applications, with the amount of initial energy in sensors
+ batteries and also with the duration of the exchange phase. All applications
+ do not have the same Quality of Service requirements. In our case,
+ information exchange is executed every hour, but the length of the sensing
+ period could be reduced and adapted dynamically. On the one hand, a small
+ sensing period would allow the network to be more reliable but would have higher
+ communication costs. On the other hand, the choice of a long duration may
+ cause problems in case of nodes failure during the sensing period.
+ Several explanations on these points are given throughout the paper. In
+ particular, we discuss the number of subregions in Section 5.2 and the
+ sensing duration in the second paragraph of Section 5.1.}}\\
+
+\noindent {\bf 2.}Page 9, Section 4, is the Perimeter-based coverage problem
+NP-hard? This question is important for justifying the use of a Mixed Integer
+Linear Programming model.\\
+
+\textcolor{blue}{\textbf{\textsc{Answer:} The perimeter scheduling coverage
+ problem is NP-hard in general, it has been proved in the paper entitled
+ "Perimeter Coverage Scheduling in Wireless Sensor Networks Using Sensors
+ with a Single Continuous Cover Range" from Ka-Shun Hung and King-Shan Lui
+ (EURASIP Journal on Wireless Communications and Networking 2010, 2010:926075
+ doi:10.1155/2010/926075). In this paper, authors study the coverage of the
+ perimeter of a large object requiring to be monitored. In our study, the
+ large object to be monitored is the sensor itself (or more precisely its
+ sensing area). This point has been highlighted at the beginning of
+ Section~4.}}\\
+
+\noindent {\bf 3.} Page 9, the major problem with the present paper is, in my
+opinion, the objective function of the Mixed Integer Linear Program (2). It is
+not described in the paper, and looks like an attempt to address a
+multiobjective problem (like minimizing overcoverage and
+undercoverage). However, using a weighted sum is well known not to be an
+efficient way to address biobjective problems. The introduction of various
+performance metrics in Section 5.1 also suggests that the authors have not
+decided exactly which objective function to use, and compare their protocols
+against competitors without mentioning the exact purpose of each of them. If the
+performance metrics list given in Section 5.1 is exhaustive, then the authors
+should mention at the beginning of the paper what are the aims of the protocol,
+and explain how the protocol is built to optimize these objectives. \\
+
+\textcolor{blue}{\textbf{\textsc{Answer:} Right. The mixed Integer Linear
+ Program adresses a multiobjective problem, where the goal is to minimize
+ overcoverage and undercoverage for each coverage interval of a sensor. To the best of our knowledge, representing the objective function as a weighted sum of
+ criteria to be minimized in case of multicriteria optimization is a
+ classical method. In Section 5, the comparison of protocols with a large
+ variety of performance metrics allows to select the most appropriate method
+ according to the QoS requirement of the application.}}\\
+
+\noindent {\bf 4.} Page 11 Section 5.2, the sensor nodes are said to be based on
+Atmels AVR ATmega103L microcontroller. If I am not mistaken, these devices have
+128 KBytes of memory, and I didn't find any clue that they can run an operating
+system like Linux. This point is of primary importance for the proposed
+protocol, since GLPK (a C API) is supposed to be executed by the cluster
+leader. In addition to that, GLPK requires a non negligible amount of memory to
+run properly, and the Atmels AVR ATmega103L microcontroller might be
+insufficient for that purpose. The authors are urged to provide references of
+previous works showing that these technical constraints are not preventing their
+protocol to be implemented on the aforementioned microcontroller. Then, on page
+13, in Section "5.2.3 Energy Consumption", the estimation of $E_p^{com}$ for the
+considered microcontroller seems quite challenging and should be carefully
+documented. Indeed, this is a key point in providing a fair comparison of PeCO
+with its competitors.\\
