-\subsection{Primary Point Coverage Model}
-\label{ch3:sec:02:02}
-\indent Instead of working with the coverage area, we consider for each
-sensor a set of points called primary points. We also assume that the
-sensing disk defined by a sensor is covered if all the primary points of
-this sensor are covered. By knowing the position (point center: ($p_x,p_y$)) of a wireless
-sensor node and its $R_s$, we calculate the primary points directly
-based on the proposed model. We use these primary points (that can be
-increased or decreased if necessary) as references to ensure that the
-monitored region of interest is covered by the selected set of
-sensors, instead of using all the points in the area.
-
-\indent We can calculate the positions of the selected primary
-points in the circle disk of the sensing range of a wireless sensor
-node (see figure~\ref{fig1}) as follows:\\
-$(p_x,p_y)$ = point center of wireless sensor node\\
-$X_1=(p_x,p_y)$ \\
-$X_2=( p_x + R_s * (1), p_y + R_s * (0) )$\\
-$X_3=( p_x + R_s * (-1), p_y + R_s * (0)) $\\
-$X_4=( p_x + R_s * (0), p_y + R_s * (1) )$\\
-$X_5=( p_x + R_s * (0), p_y + R_s * (-1 )) $\\
-$X_6= ( p_x + R_s * (\frac{-\sqrt{2}}{2}), p_y + R_s * (0)) $\\
-$X_7=( p_x + R_s * (\frac{\sqrt{2}}{2}), p_y + R_s * (0))$\\
-$X_8=( p_x + R_s * (\frac{-\sqrt{2}}{2}), p_y + R_s * (\frac{-\sqrt{2}}{2})) $\\
-$X_9=( p_x + R_s * (\frac{\sqrt{2}}{2}), p_y + R_s * (\frac{-\sqrt{2}}{2})) $\\
-$X_{10}=( p_x + R_s * (\frac{-\sqrt{2}}{2}), p_y + R_s * (\frac{\sqrt{2}}{2})) $\\
-$X_{11}=( p_x + R_s * (\frac{\sqrt{2}}{2}), p_y + R_s * (\frac{\sqrt{2}}{2})) $\\
-$X_{12}=( p_x + R_s * (0), p_y + R_s * (\frac{\sqrt{2}}{2})) $\\
-$X_{13}=( p_x + R_s * (0), p_y + R_s * (\frac{-\sqrt{2}}{2})) $\\
-$X_{14}=( p_x + R_s * (\frac{\sqrt{3}}{2}), p_y + R_s * (\frac{1}{2})) $\\
-$X_{15}=( p_x + R_s * (\frac{-\sqrt{3}}{2}), p_y + R_s * (\frac{1}{2})) $\\
-$X_{16}=( p_x + R_s * (\frac{\sqrt{3}}{2}), p_y + R_s * (\frac{- 1}{2})) $\\
-$X_{17}=( p_x + R_s * (\frac{-\sqrt{3}}{2}), p_y + R_s * (\frac{- 1}{2})) $\\
-$X_{18}=( p_x + R_s * (\frac{\sqrt{3}}{2}), p_y + R_s * (0) $\\
-$X_{19}=( p_x + R_s * (\frac{-\sqrt{3}}{2}), p_y + R_s * (0) $\\
-$X_{20}=( p_x + R_s * (0), p_y + R_s * (\frac{1}{2})) $\\
-$X_{21}=( p_x + R_s * (0), p_y + R_s * (-\frac{1}{2})) $\\
-$X_{22}=( p_x + R_s * (\frac{1}{2}), p_y + R_s * (\frac{\sqrt{3}}{2})) $\\
-$X_{23}=( p_x + R_s * (\frac{- 1}{2}), p_y + R_s * (\frac{\sqrt{3}}{2})) $\\
-$X_{24}=( p_x + R_s * (\frac{- 1}{2}), p_y + R_s * (\frac{-\sqrt{3}}{2})) $\\
-$X_{25}=( p_x + R_s * (\frac{1}{2}), p_y + R_s * (\frac{-\sqrt{3}}{2})) $.
-
-\begin{figure}[h!]
-\centering
- \begin{multicols}{3}
-\centering
-\includegraphics[scale=0.20]{Figures/ch3/fig21.pdf}\\~ ~ ~ ~ ~(a)
-\includegraphics[scale=0.20]{Figures/ch3/fig22.pdf}\\~ ~ ~ ~ ~(b)
-\includegraphics[scale=0.20]{Figures/ch3/principles13.pdf}\\~ ~ ~ ~ ~(c)
-\hfill
-\includegraphics[scale=0.20]{Figures/ch3/fig24.pdf}\\~ ~ ~(d)
-\includegraphics[scale=0.20]{Figures/ch3/fig25.pdf}\\~ ~ ~(e)
-\includegraphics[scale=0.20]{Figures/ch3/fig26.pdf}\\~ ~ ~(f)
-\end{multicols}
-\caption{Wireless Sensor Node represented by (a)5, (b)9, (c)13, (d)17, (e)21 and (f)25 primary points respectively}
-\label{fig1}
-\end{figure}
-
-
-
-\subsection{Main Idea}
-\label{ch3:sec:02:03}
-\noindent We start by applying a divide-and-conquer algorithm to partition the
-area of interest into smaller areas called subregions and then our protocol is
-executed simultaneously in each subregion.
-
-\begin{figure}[ht!]
-\centering
-\includegraphics[scale=0.60]{Figures/ch3/FirstModel.pdf} % 70mm
-\caption{DiLCO protocol}
-\label{FirstModel}
-\end{figure}
-
-As shown in Figure~\ref{FirstModel}, the proposed DiLCO protocol is a periodic
-protocol where each period is decomposed into 4~phases: Information Exchange,
-Leader Election, Decision, and Sensing. For each period there will be exactly
-one cover set in charge of the sensing task. A periodic scheduling is
-interesting because it enhances the robustness of the network against node
-failures. First, a node that has not enough energy to complete a period, or
-which fails before the decision is taken, will be excluded from the scheduling
-process. Second, if a node fails later, whereas it was supposed to sense the
-region of interest, it will only affect the quality of the coverage until the
-definition of a new cover set in the next period. Constraints, like energy
-consumption, can be easily taken into consideration since the sensors can update
-and exchange their information during the first phase. Let us notice that the
-phases before the sensing one (Information Exchange, Leader Election, and
-Decision) are energy consuming for all the nodes, even nodes that will not be
-retained by the leader to keep watch over the corresponding area.
-
-Below, we describe each phase in more details.
-
-\subsubsection{Information Exchange Phase}
-\label{ch3:sec:02:03:01}
-Each sensor node $j$ sends its position, remaining energy $RE_j$, and the number
-of neighbors $NBR_j$ to all wireless sensor nodes in its subregion by using an
-INFO packet (containing information on position coordinates, current remaining
-energy, sensor node ID, number of its one-hop live neighbors) and then waits for
-packets sent by other nodes. After that, each node will have information about
-all the sensor nodes in the subregion. In our model, the remaining energy
-corresponds to the time that a sensor can live in the active mode.
-
-\subsubsection{Leader Election Phase}
-\label{ch3:sec:02:03:02}
-This step includes choosing the Wireless Sensor Node Leader (WSNL), which will be responsible for executing the coverage algorithm. Each subregion in the area of interest will select its own WSNL independently for each round. All the sensor nodes cooperate to select WSNL. The nodes in the same subregion will select the leader based on the received information from all other nodes in the same subregion. The selection criteria are, in order of importance: larger number of neighbors, larger remaining energy, and then in case of equality, larger index. Observations on previous simulations suggest to use the number of one-hop neighbors as the primary criterion to reduce energy consumption due to the communications.
-
-
-\subsubsection{Decision phase}
-\label{ch3:sec:02:03:03}
-The WSNL will solve an integer program (see section~\ref{ch3:sec:03}) to select which sensors will be activated in the following sensing phase to cover the subregion. WSNL will send Active-Sleep packet to each sensor in the subregion based on the algorithm's results.
-
-
-\subsubsection{Sensing phase}
-\label{ch3:sec:02:03:04}
-Active sensors in the round will execute their sensing task to
-preserve maximal coverage in the region of interest. We will assume
-that the cost of keeping a node awake (or asleep) for sensing task is
-the same for all wireless sensor nodes in the network. Each sensor
-will receive an Active-Sleep packet from WSNL informing it to stay
-awake or to go to sleep for a time equal to the period of sensing until
-starting a new round.
-
-An outline of the protocol implementation is given by Algorithm~\ref{alg:DiLCO}
-which describes the execution of a period by a node (denoted by $s_j$ for a
-sensor node indexed by $j$). At the beginning a node checks whether it has
-enough energy to stay active during the next sensing phase. If yes, it exchanges
-information with all the other nodes belonging to the same subregion: it
-collects from each node its position coordinates, remaining energy ($RE_j$), ID,
-and the number of one-hop neighbors still alive. Once the first phase is
-completed, the nodes of a subregion choose a leader to take the decision based
-on the following criteria with decreasing importance: larger number of
-neighbors, larger remaining energy, and then in case of equality, larger index.
-After that, if the sensor node is leader, it will execute the integer program
-algorithm (see Section~\ref{ch3:sec:03}) which provides a set of sensors planned to be
-active in the next sensing phase. As leader, it will send an Active-Sleep packet
-to each sensor in the same subregion to indicate it if it has to be active or
-not. Alternately, if the sensor is not the leader, it will wait for the
-Active-Sleep packet to know its state for the coming sensing phase.
-
-
-\begin{algorithm}[h!]
-
- \BlankLine
- %\emph{Initialize the sensor node and determine it's position and subregion} \;
-
- \If{ $RE_j \geq E_{th}$ }{
- \emph{$s_j.status$ = COMMUNICATION}\;
- \emph{Send $INFO()$ packet to other nodes in the subregion}\;
- \emph{Wait $INFO()$ packet from other nodes in the subregion}\;
- %\emph{UPDATE $RE_j$ for every sent or received INFO Packet}\;
- %\emph{ Collect information and construct the list L for all nodes in the subregion}\;
+
+A testbed is a large evaluation tool. However, to construct a suitable tool with capable architecture, the information about wanted requirement is required. Many existing testbeds are developed without obvious definition of requirements. Therefore, the research efforts may be halted due to the lack of the precisely defined requirements~\cite{ref186}. The tests and experiments on a large number of sensor nodes lead to a scalability challenge, and a large amount of data for logging, debugging, and measurement output. There are no enough tools so as to deal (semi-)automatically with the amount of data and supporting the researchers to evaluate their systems. For evaluating the systems and protocols on a large sensor networks, the simulation tools are the better choice due to the costs for hardware and maintenance~\cite{ref186}.
+
+Several sensor nodes testbeds are found in order to support WSNs research efforts, but only a few of them provide common evaluation goals for a large number of users~\cite{ref187,ref181}. However, all the WSN testbeds are shared in general properties, such as the number of sensors are at most hundreds and sometimes only tens of nodes are involved in the typical testbeds; the sensor nodes are placed in a static grid topology; metrics and debug information are obtained via wired connections. Therefore, the WSN testbeds impose strong limitations on the WSNs in terms of size and topology. Moreover, the cost of performing an experiment on a testbed is much higher than on a simulation because setting up the experiments, instrumenting the nodes, gathering the metrics on the performance, and so on are so expensive. Hence, the simulation tools stay the most practical tools to obtain a feedback on the performance of a new solution~\cite{ref180}.
+
+
+
+\subsection{Simulation Tools}
+% take the simulators from paper "Limitations of simulation tools for large-scale wireless sensor networks" \cite{ref179}
+
+The simulation tools are widely used due to the complexity and difficulty to apply real testbed for WSNs experiments. The simulation tools permit users to evaluate and validate their systems and protocols on WSNs before the deployment. This can reduce the correction actions before operating the WSN. The large-scale evaluation of systems, applications, and protocols are practicable in a flexible environment~\cite{ref180}.
+Most of the papers on the wireless sensor networks use the simulation tools to evaluate the performance of their algorithms and protocols. This is a confirmation to consider these tools as predominant techniques used to study and analyze the performance and potency of a wireless sensor networks. Several simulation tools are available for WSNs, which vary in their characteristics and capabilities. So, this section introduces only some of these simulators, and for more details about simulators are available in~\cite{ref188,ref189,ref190}.
+
+\begin{enumerate} [(i)]
+
+\item \textbf{NS2:}
+
+The Network Simulator-2 (ns-2)~\cite{ref191,ref192} is an open source, discrete event network simulator. The major goal of ns-2 is to provide a simulation environment to wired as well as wireless networks to simulate different protocols with different network topologies. The ns-2 is constructed using C++, and the simulation interface is provided via OTcl, an object-oriented dialect of Tcl. The network topology is determined by writing OTcl scripts by the users, and then the main program of ns-2 simulates that topology with fixed parameters. ns-2 provides a graphical view of the network by using network animator (NAM). NAM interface includes control features that permit to the researchers to forward, pause, stop, and control the simulation. The ns-2 is the most common and widely used network simulator for scientific research work.
+
+The ns-3 is considered a new simulator and a final replacement of ns-2, not an extension~\cite{ref194}. The ns-3 project~\cite{ref193} was started in mid-2006 and is still under intensive development. Like ns-2, ns-3 is an open source, discrete-event network simulator targeted essentially for research and educational use~\cite{ref195}. The ns-3 supports both simulation and emulation using sockets. It also provides a tracing facility in order to help users in debugging.
+
+
+
+\item \textbf{OMNeT++:}
+
+The OMNeT++ (Objective Modular Network Testbed) is an open-source, free, discrete-event, component-based C++ simulation library, modular simulation framework for building network simulators~\cite{ref158,ref203}. In spite of OMNeT++ is not a network simulator itself, it is obtained a global popularity as a network simulation platform for both scientific and industrial communities. The major goal behind the development of OMNeT++ is to provide a strong simulation tool, which can be used by the academic and commercial researchers for simulating different types of networks in a distributed and parallel way~\cite{ref197}. OMNeT++ has extensive graphical user interface (GUI) and intelligence support. It runs on Windows, Linux, Mac OS X, and other Unix-like systems. It provides a component architecture for models. Components (modules) are programmed in C++, then assembled into larger components and models using a high-level language (NED)~\cite{ref198}. Several simulation frameworks can be used with OMNeT++ such as INET, INETMANET, MiXiM, and Castalia, where each of them provides a set of simulation facilities and can be used for a specific applications.
+
+
+\item \textbf{OPNET:}
+
+The OPNET (Optimized Network Engineering tool)~\cite{ref192,ref200,ref201} is the first commercial simulation tool that developed in 1987 for communication networks. It is a discrete event, object-oriented, general purpose network simulator, which is widely used in industry. It uses C and Java languages. It provides a comprehensive development environment for the specification, simulation, configuration, and performance analysis of the communication network. The OPNET permits researchers in developing the various models by means of a graphical interface. It provides different types of tools such as Probe Editor, Filter Tool, and Animation Viewer for data collection to the model graph and animate the resulting output. Unlike ns-2, the OPNET provides modeling for different sensor-specific hardware, such as physical-link transceivers and antennas. It includes sensor-specific models such as ad-hoc connectivity, mobility of nodes, node failure models, modeling of power-consumption, etc. The OPNET is commercial simulator and the license is very expensive. Therefore, this represents the main disadvantage of that simulator.
+
+
+\item \textbf{GloMoSim:}
+
+The GloMoSim(Global Mobile System Simulator)~\cite{ref202,ref204,ref205} is an open source, well-documented source code and scalable simulation environment developed in 1998 for mobile wireless networks. It uses a Parsec, which is an extension of C for parallel programming. The main feature of GloMoSim simulator is using parallel environment. The parallel network simulation is hard due to the communication among the simulated nodes on different machines. Several types of protocols and models are found in GloMoSim including TCP,
+IEEE 802.11 CSMA/CA, MAC, UDP, HTTP, FTP, CBR, ODMRP, WRP, DSR, MACA, Telnet, AODV, etc. It uses a VT visualization tool to observe and debug these protocols. The GloMoSim is designed to be extensible with all protocols implemented as modules in its library. It also uses an object-oriented approach. It is dividing the nodes, and each object is responsible for executing one layer in the protocol stack of every node for its given division. This mechanism minimizes the overhead of a large-scale sensor network.
+
+The GloMoSim supports a wide range of protocols and its configuration is easy. Due to the parallel processing nature, it supplies a fast simulation. The GloMoSim provides efficient simulation for IP networks whilst it does not support accurate simulation for many sensor network applications. Since 2000, the GloMoSim has been stopping releasing updates. It is currently updated as a commercial product called QualNet.
+
