+\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 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. 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.\\
+
+\textcolor{blue}{\textbf{\textsc{Answer 1:}
+To implement PeCO on real sensors nodes with limited memories capacities, we can act on :
+\begin{itemize}
+\item the solver : GLPK is memory consuming for the resolution of integer
+ programming (IP) compared with other commercial solvers like
+ CPLEX\textregistered. Commercial solvers generally outperform open source
+ solvers (See the report : ``Analysis of commercial and free and open source
+ solvers for linear optimization problems" by B. Meindl and M. Templ from
+ Vienna University of Technology). Memory use depends on the number of
+ variables and number of constraints. For linear programs (LP), a reasonable
+ estimate of memory use with CPLEX \textregistered~is to allow one megabyte per
+ thousand constraints. For integer programs, no simple formula exists since
+ memory use depends so heavily on the size of the branch and bound tree (B \& B
+ tree). But, the estimate for linear programs still provides a lower bound. In
+ our case, the characteristics of the integer programming (2) are the
+ following:
+\begin{itemize}
+\item number of variables : $S* (2*I+1)$
+\item number of constraints : $2* I *S$
+\item number of non-zero coefficients : $2* I *S * B$
+\item number of parameters (in the objective function) : $2* I *S$
+\end{itemize}
+where $S$ denotes the number of sensors in the subregion, $I$ the average number
+of cover intervals per sensor, $B$ the average number of sensors involved in a
+coverage interval. The following table gives the memory use with GLPK to solve
+the integer program (column 3) and its LP-relaxation (column 4) for different
+problem sizes. The sixth column gives an estimate of the memory use with
+CPLEX\textregistered to solve the LP-relaxation according to the number of
+constraints.
+\medskip \\
+\begin{tabular}{|c|c|c|c|c|c|r|}
+\hline
+Total number & S & I & GLPK IP & GLPK LP & nodes&CPLEX\\
+of nodes &&&&relaxation &B\&B tree &\\
+\hline
+100 & 6.25& 5&0.2 MB & 0.2 Mb &1 & 64 kB\\
+\hline
+200 & 12.5& 11&1.7 MB & 1.6 Mb &1 & 281 kB\\
+\hline
+300 &18.5 & 17&3.6 MB & 3.5 Mb & 3 &644 kB\\
+\hline
+\end{tabular}
+\medskip \\
+It is noteworthy that the difference of memory used with GLPK between the
+resolution of the IP and its LP-relaxation is very weak (not more than 0.1
+MB). The size of the branch and bound tree dos not exceed 3 nodes. This result
+leads one to believe that the memory use with CPLEX\textregistered for solving
+the IP would be very close to that for the LP-relaxation, that is to say around
+100 Kb for a subregion containing $S=10$ sensors. Moreover the IP seems to have
+some specifities that encourage us to develop our own solver (coefficents matrix
+is very sparse) or to use an existing heuristic to find good approximate
+solutions (Reference : ``A feasibility pump heuristic for general mixed-integer
+problems", Livio Bertacco and Matteo Fischetti and Andrea Lodi, Discrete
+Optimization, issn 1572-5286).
+\item the subdivision of the region of interest. To make the resolution of
+ integer programming tractable by a leader sensor, we need to limit the number
+ of nodes in each subregion (the number of variables and constraints of the
+ integer programming is directly depending on the number of nodes and
+ neigbors). It is therefore necessary to adapt the subdvision according to the
+ number of sensors deployed in the area and their sensing range (impact on the
+ number of coverage intervals).
+\end{itemize}
+A discussion about memory consumption has been added in Section 5.2}}
+\bigskip \\
+\indent \textcolor{blue}{\textbf{\textsc{Answer 2:} In Section 5.2 we give a table with
+ the power consumption values which are used to compute the energy
+ consumption. These ones are based on the energy model of (Vu et al. 2006).
+}}
