In this dissertation, we use linear programming because we used integer programs to optimize the coverage and the lifetime in WSNs.
\section{Evaluation Tools}
-On the one hand, several proposed works in WSNs require evaluating the power depletion efficiently and accurately for network lifetime prediction. On the other hand, the wrong energy evaluation leads to waste of energy because the sensor nodes might be rendered useless long time before draining their energy. Furthermore, the sensor nodes might die before of the expected lifetime. However, evaluation experiments on actually deployed WSN suffer some constraints because of the large number of sensor nodes deployed and of possible in hostile and inaccessible environments. Moreover, the analytical (or theoretical) models might be unrealistic for real world systems.
+On the one hand, several proposed works in WSNs require evaluating the power depletion efficiently and accurately for network lifetime prediction. On the other hand, the wrong energy evaluation leads to waste of energy because the sensor nodes might be rendered useless long time before draining their energy. Furthermore, the sensor nodes might die before of the expected lifetime. However, evaluation experiments on actually deployed WSN suffer some constraints because of the large number of sensor nodes and the deployment in hostile and inaccessible environments. Moreover, the analytical (or theoretical) models might be unrealistic for real world systems.
Two main evaluation tools are available for evaluating and validating the performance of proposed works of researchers in large-scale wireless sensor networks: testbeds and simulations~\cite{ref180}. The energy consumption results obtained by simulation and testbed evaluation tools give an alternative on time, precision, and cost.
-T%herefore, the energy consumption results obtained by simulation and testbed evaluations give an alternative on time, precision and cost. Researchers can also evaluate and test their proposed works with simulation tools as well as testbed devices.
+%Therefore, the energy consumption results obtained by simulation and testbed evaluations give an alternative on time, precision and cost. Researchers can also evaluate and test their proposed works with simulation tools as well as testbed devices.
%Two main evaluation tools are available for evaluating and validating large-scale wireless sensor networks performance: testbeds and simulations~\cite{ref180}.
\item \textbf{MoteLab:}
-MoteLab~\cite{ref181,ref182} is a WSN testbed developed at the electrical and computer engineering department of Harvard University. It is a public testbed, researchers can execute their WSN systems using a web-based interface. Researchers develop and test their applications and protocols on sensor nodes and visualize sensor nodes output via web-based interface. They are allowed to upload their executable files to run on real mote. Each mote is wall-powered and is connected to a central server that offers scheduling, reprogramming, and data logging. It is composed of 190 TMote Sky wireless sensor nodes. The wireless sensor node has the following specifications: TI MSP430 processor, 10 KB RAM, 1Mb flash, and Chipcon CC2420 radio. Each node is connected to the Ethernet. The users should be familiar with NesC programming language because the MoteLab only supports the TinyOS operating system.
+MoteLab~\cite{ref181,ref182} is a WSN testbed developed at the electrical and computer engineering department of Harvard University. It is a public testbed, researchers can execute their WSN systems using a web-based interface. Researchers develop and test their applications and protocols on sensor nodes and visualize sensor nodes output via web-based interface. They are allowed to upload their executable files to run on real mote. Each mote is wall-powered and is connected to a central server that offers scheduling, reprogramming, and data logging. It is composed of 190~TMote Sky wireless sensor nodes. The wireless sensor node has the following specifications: TI MSP430 processor, 10 KB RAM, 1Mb flash, and Chipcon CC2420 radio. Each node is connected to the Ethernet. The users should be familiar with NesC programming language because the MoteLab only supports the TinyOS operating system.
\item \textbf{WISEBED:}
-The WISEBED~\cite{ref183} is a large-scale WSN testbed with a hierarchical architecture that consists of four major parts: wireless sensor nodes, gateways, portal server, and overlay network. The lowest level of the hierarchy corresponds to the WSN in which a set of these sensor nodes is connected to the gateway to provide access to the attached sensor nodes. The gateways are connected to a portal server, which not only supervises the WSN, but also allows user interactions with the testbed. Each WISBED site includes separate portal server. The major goal of this testbed is to provide a multi-level infrastructure of interconnected testbeds of large scale wireless sensor networks for research purposes. It provides an interdisciplinary approach which integrates the hardware, software, algorithms, and data. WISEBED provides heterogeneous large-scale structure because it brings several heterogeneous small-scale devices together to form a large-scale network structure. It provides the research with different quality networks due to the heterogeneous structure of the network.
+The WISEBED~\cite{ref183} is a large-scale WSN testbed with a hierarchical architecture that consists of four major parts: wireless sensor nodes, gateways, portal server, and overlay network. The lowest level of the hierarchy corresponds to the WSN in which a set of these sensor nodes is connected to the gateway to provide access to the other remaining sensor nodes. The gateways are connected to a portal server, which not only supervises the WSN, but also allows user interactions with the testbed. Each WISBED site includes separate portal server. The major goal of this testbed is to provide a multi-level infrastructure of interconnected testbeds of large scale wireless sensor networks for research purposes. It provides an interdisciplinary approach which integrates the hardware, software, algorithms, and data. WISEBED provides heterogeneous large-scale structure because it brings several heterogeneous small-scale devices together to form a large-scale network structure. It provides the research with different quality networks due to the heterogeneous structure of the network.
\item \textbf{IoT-LAB:}
-IoT-LAB testbed~\cite{ref184,ref185} supplies a very large scale infrastructure service appropriate for evaluating small wireless sensor devices and heterogeneous communicating objects. IoT-LAB includes more than 2700 wireless sensor nodes deployed in six different regions in France. Different kinds of wireless sensor nodes are available, with different processor architectures (MSP430, STM32, and Cortex-A8) and different wireless chips (802.15.4 PHY @ 800 MHz or 2.4 GHz). Sensor nodes are either mobile or fixed and can be used in different topologies throughout all the regions.
+IoT-LAB testbed~\cite{ref184,ref185} supplies a very large scale infrastructure service appropriate for evaluating wireless sensor devices and heterogeneous communicating objects. IoT-LAB includes more than 2700 wireless sensor nodes deployed in six different regions in France. Different kinds of wireless sensor nodes are available, with different processor architectures (MSP430, STM32, and Cortex-A8) and different wireless chips (802.15.4 PHY @ 800 MHz or 2.4 GHz). Sensor nodes are either mobile or fixed and can be used in different topologies throughout all the regions.
IoT-LAB provides web-based reservation and tools for protocols and applications development, along with direct command-line access to the platform. Wireless sensor nodes firmware can be constructed from source and deployed on reserved nodes, application activity can be controlled and observed, power consumption or radio interference can be measured using the offered tools. IoT-LAB is a part of the FIT experimental platform, a set of supplementary elements that enable experimentation with innovative services for academic and industrial users.
\end{enumerate}
-A testbed is a large evaluation tool. However, to construct a suitable tool with capable architecture, the information about the desired requirements is required. For instance, table \ref{Tablex:ch3} presents each research topic and the required abilities and provisions for a specialized testbed in the corresponding field of study~\cite{ref186}. 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 to deal (semi-)automatically with the amount of data and supporting the researchers to evaluate their systems.
+A testbed is a large hardware evaluation tool. However, to construct a suitable tool with capable architecture, the information about the desired requirements is required. For instance, table \ref{Tablex:ch3} presents each research topic and the required abilities and provisions for a specialized testbed in the corresponding field of study~\cite{ref186}. 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. Another drawback is that there are no enough tools to deal (semi-)automatically with the amount of data and supporting the researchers to evaluate their systems.
\begin{table}[h]
\end{table}
-Several sensor nodes testbeds are available to support the research efforts in WSNs, but only a few of them provide common evaluation goals for a large number of users~\cite{ref187,ref181}. However, all the WSN testbeds have usually many common properties, such as a typical number of sensors of the hundreds and sometimes only tens of nodes; the deployment of the sensor nodes 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 through a simulation because setting up the experiments, instrumenting the nodes, gathering the metrics on the performance, and so on is so expensive. 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}. Hence, the simulation tools stay the most practical tools to obtain a feedback on the performance of a new solution~\cite{ref180}.
+Several sensor nodes testbeds are available to support the research efforts in WSNs, but only a few of them provide common evaluation goals for a large number of users~\cite{ref187,ref181}. However, all the WSN testbeds have usually many common properties, such as a typical number of sensors of the order of hundreds and sometimes only tens of nodes; the deployment of the sensor nodes 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 through a simulation because setting up the experiments, instrumenting the nodes, gathering the metrics on the performance, and so on is so expensive. 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}. 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}
\item \textbf{OMNeT++:}
-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}. Even if OMNeT++ is not a network simulator itself, it is very popular 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 an 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 first 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 (modelity and soon) and can be used for specific applications.
+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}. Even if OMNeT++ is not a network simulator itself, it is very popular 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 an extensive graphical user interface (GUI) and intelligence support. It runs on Windows, Linux, Mac OS~X, and other Unix-like systems, and provides a component architecture for models. Components (modules) are first 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 (modelity and soon) and can be used for specific applications.
\item \textbf{OPNET:}
\item \textbf{GloMoSim:}
-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 the parallel environment. A 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,
+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 library called Parsec, which is an extension of C for parallel programming. The main feature of GloMoSim simulator is the parallel environment. A 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 tool 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.
\item \textbf{TOSSIM:}
-TOSSIM~\cite{ref205,ref207,ref208} is a discrete event simulator for TinyOS based sensor networks, where the TinyOS application can be compiled on the TOSSIM framework, which runs on a computer rather than on the mote. This allow the users to test, debug, and analyze theirs algorithms in a controlled and repeatable environment. The users can check up their codes using debuggers and other development tools by executing them on the computer. TOSSIM is regarded as an emulator rather than a simulator because of its ability to simulate both software and hardware of the mote. TOSSIM is specially-designed for TinyOS applications run on Berkeley MICA Motes. TOSSIM should be developed to include four requirements: scalability, completeness, fidelity, and bridging. It should manage a large number of sensor nodes with different configurations to be scalable. For completeness, it has to capture behavior and interactions of a system at a different of levels. The simulator should capture behavior of a network with accurate timing of interactions on a mote and among motes for fidelity. The bridging requirement is satisfied due to executing the simulated code directly in a real mote. Two programming interfaces are supported by TOSSIM: Python and C++. The C++ interface transforms the code easily from one form to another. Python allows interaction with an executing simulation dynamically, like a powerful debugger. TOSSIM provides a high fidelity and scalable simulation of a complete TinyOS sensor network. It visualizes and interacts with executing simulations using GUI tool and TinyViz. The users can develop new visualizations and interfaces for TinyViz using simple plug-in model. The simulator's effectiveness for analyzing low-level protocols is decreased due to inaccuracies in the probabilistic bit error model. Moreover, TOSSIM is only supported by MICA motes platform.
+TOSSIM~\cite{ref205,ref207,ref208} is a discrete event simulator for TinyOS based sensor networks, where the TinyOS application can be compiled on the TOSSIM framework, which runs on a computer rather than on the mote. This allow the users to test, debug, and analyze theirs algorithms in a controlled and repeatable environment. The users can check up their codes using debuggers and other development tools by executing them on the computer. TOSSIM is regarded as an emulator rather than a simulator because of its ability to simulate both software and hardware of the mote. TOSSIM is specially-designed for TinyOS applications run on Berkeley MICA Motes. TOSSIM needs to be improved to include four requirements: scalability, completeness, fidelity, and bridging, and to manage a large number of sensor nodes with different configurations to be scalable. For completeness, it has to capture behavior and interactions of a system at a different of levels. The simulator should capture behavior of a network with accurate timing of interactions on a mote and among motes for fidelity. The bridging requirement is satisfied due to executing the simulated code directly in a real mote. Two programming interfaces are supported by TOSSIM: Python and C++. The C++ interface transforms the code easily from one form to another. Python allows interaction with an executing simulation dynamically, like a powerful debugger. TOSSIM provides a high fidelity and scalable simulation of a complete TinyOS sensor network. It visualizes and interacts with executing simulations using GUI tool and TinyViz. The users can develop new visualizations and interfaces for TinyViz using simple plug-in model. The simulator's effectiveness for analyzing low-level protocols is decreased due to inaccuracies in the probabilistic bit error model. Moreover, TOSSIM is only supported by MICA motes platform.
\item \textbf{GTSNetS:}
%IP problems are a special cases of optimization problems, where the variables can only assume integer values. The IP problems are NP-hard. Mixed integer linear programming (MIP) problems are also special cases, where only some of the variables are restricted to integer values. The optimization problems with integer variables can also be linear or nonlinear, depending on the terms of their objective function and their constraints. However, the terms IP and MIP are almost always associated with problems that have linear features.
-Linear optimization is used to solve different problems in various fields of study. It is applied for economic, business, and industry. Several linear optimization models are proposed in the industry such as transportation, energy, telecommunications, and manufacturing.
+Linear optimization is used to solve different problems in various fields of study. It is applied for economic, business, and industry problems. For example, in the industry linear optimization is used to solve transportation, energy, telecommunications, and manufacturing problems.
%Linear optimization is succeeded in modeling different types of problems like planning, routing, scheduling, assignment, and design.
Many approaches have been proposed to solve linear programming (IP or MIP) problems and they are classified into two main groups~\cite{ref221}:
\item \textbf{GNU Linear Programming Kit (GLPK):}
GLPK~\cite{ref214,ref213,AMPL} is a free and open source software written in C programming language, which is presented for solving large-scale Linear Programming (LP), Mixed Integer Programming (MIP), and other related problems. It is a mathematical programming project that is a part of the GNU project. The GLPK uses the revised simplex method and the primal-dual interior point method for non-integer problems, and the branch-and-bound algorithm together with Gomory's mixed integer cuts for (mixed) integer problems.
-The users use either an interactive command line or a C++ application programming interface (API) in order to interact with GLPK, where the C and java API are available with GLPK. Several input file formats are accepted by GLPK such as MPS (Mathematical Programming System), Free MPS, LP, GLPK, and MathProg format. The major components of the GLPK package are primal and dual simplex methods, primal-dual interior-point method, branch-and-cut method, translator for GNU MathProg, API, and stand-alone LP/MIP solver.
+The users use either an interactive command line or C++ and java application programming interface (API) in order to interact with GLPK. Several input file formats are accepted by GLPK such as MPS (Mathematical Programming System), Free MPS, LP, GLPK, and MathProg format. The major components of the GLPK package are primal and dual simplex methods, primal-dual interior-point method, branch-and-cut method, translator for GNU MathProg, API, and stand-alone LP/MIP solver.
\item \textbf{lp$\_$solve:}
\item \textbf{CLP:}
-The COIN-OR Linear Programming (CLP)~\cite{ref216,ref217} is a free, open-source, linear programming solver written in C++ programming language. It is reliable and able to tackle the very large linear optimization problems. The CLP is a part of the Coin-OR project that aims at creating open software for the operations research community. Another COIN-OR projects such as SYMPHONY, BCP (Branch Cut and Price), and CBC (COIN-OR Branch and Cut) are used CLP. It includes Dual and Primal Simplex algorithms, but it also contains an Interior Point algorithm. The CLP is available under the Eclipse Public License version 1.0, and the users interact with it through either an interactive command line or through a C++ API. The CLP is able to use the input MPS, Free MPS, and LP file formats.
+The COIN-OR Linear Programming (CLP)~\cite{ref216,ref217} is a free, open-source, linear programming solver written in C++ programming language. It is reliable and able to tackle the very large linear optimization problems. The CLP is a part of the Coin-OR project that aims at creating open software for the operations research community. COIN-OR projects such as SYMPHONY, BCP (Branch Cut and Price), and CBC (COIN-OR Branch and Cut) also used CLP. It includes Dual and Primal Simplex algorithms, but it also contains an Interior Point algorithm. The CLP is available under the Eclipse Public License version 1.0, and the users interact with it through either an interactive command line or through a C++ API. The CLP is able to use the input MPS, Free MPS, and LP file formats.
\item \textbf{CPLEX:}
-The IBM ILOG CPLEX Optimization Studio (often informally referred to simply as CPLEX)~\cite{ref218,ref211} is a commercial, analytical decision support, and optimization software toolkit for fast development of optimization models using mathematical and constraint programming. It combines an integrated development environment (IDE) with the powerful Optimization Programming Language (OPL) and high-performance ILOG CPLEX optimizer solvers. The CPLEX is developed by IBM and is designed to tackle the large-scale (mixed integer) linear problems. The CPLEX optimizer includes a modeling layer called concert that provides interfaces to the C++, C$\#$, Python, and Java languages. Furthermore, it provides a connection to Microsoft Excel and MATLAB. The CPLEX is capable of optimizing the business decisions with high-performance optimization engines. It develops and deploys optimization models quickly by using flexible interfaces and pre-constructed deployment scenarios. In addition, it creates real-world applications.
+The IBM ILOG CPLEX Optimization Studio (often informally referred to simply as CPLEX)~\cite{ref218,ref211} is a commercial, analytical decision support, and optimization software toolkit for fast development of optimization models using mathematical and constraint programming. It combines an integrated development environment (IDE) with the powerful Optimization Programming Language (OPL) and high-performance ILOG CPLEX optimizer solvers. The CPLEX is developed by IBM and is designed to tackle the large-scale (mixed integer) linear problems. The CPLEX optimizer includes a modeling layer called "Concert" that provides interfaces to the C++, C$\#$, Python, and Java languages. Furthermore, it provides a connection to Microsoft Excel and MATLAB. The CPLEX is capable of optimizing the business decisions with high-performance optimization engines. It develops and deploys optimization models quickly by using flexible interfaces and pre-constructed deployment scenarios. In addition, it creates real-world applications.
\item \textbf{Gurobi:}
B. Meindl and M. Templ~\cite{ref212} studied the efficiency of above optimization solvers. They used a set of instances of difficult optimization problems called the attacker problems in order to achieve a performance comparison of GLPK, lp$\_$solve, CLP, GUROBI, and CPLEX optimization solvers. They considered a total of 200 problem instances for this study, 100 of these problem instances are based on problems with two dimensions, and 100 problem instances are three-dimensional.
-Tables~\ref{my-label1}, \ref{my-label2}, and \ref{my-label3} compares the running times of the five linear program solvers to find solutions to the 200 two-dimensional, 200 three-dimensional, and all 400 problem instances. In order to solve the attacker’s problem for a given problem instance, it is needed to both minimize and maximize any given problem. Therefore, a total of 400 problem instances had been solved when only 200 problem instances have been generated.
+
+Tables~\ref{my-label1}, \ref{my-label2}, and \ref{my-label3} compares the running times of the five linear program solvers to find solutions to the 200 two-dimensional, 200 three-dimensional, and all 400 problem instances. In order to solve the attacker’s problem for a given problem instance, it is needed to both minimize and maximize any given problem. Therefore, a total of 400 problem instances had been solved when only 200 problem instances have been generated. The running time of the fastest solver has been scaled to one and the running times of the other linear solvers were scaled to reflect this scaling.
\begin{table}[h]
-\caption{Scaled running times for 2-dimensional problem instances}
+\caption{Total (in seconds) and scaled running times for 2-dimensional problem instances}
\label{my-label1}
\resizebox{\textwidth}{!}{%
\begin{tabular}{|c|c|c|c|c|c|}
\hline
\textbf{Optimization Solvers} & \textbf{GLPK} & \textbf{lp\_solve} & \textbf{CLP} & \textbf{Gurobi} & \textbf{CPLEX} \\ \hline
-\textbf{Scaled Running Times} & 9.00 & 137.00 & 13.00 & 4.00 & 1.00 \\ \hline
+\textbf{Total Running Time} & 180.1 & 2861.9 & 273.9 & 73.6 & 20.9 \\ \hline
+\textbf{Scaled Running Time} & 9 & 137 & 13 & 4 & 1 \\ \hline
\end{tabular}
}
\end{table}
\begin{table}[h]
-\caption{Scaled running times for 3-dimensional problem instances}
+\caption{Total (in seconds) and scaled running times for 3-dimensional problem instances}
\label{my-label2}
\resizebox{\textwidth}{!}{%
\begin{tabular}{|c|c|c|c|c|c|}
\hline
\textbf{Optimization Solvers} & \textbf{GLPK} & \textbf{lp\_solve} & \textbf{CLP} & \textbf{Gurobi} & \textbf{CPLEX} \\ \hline
-\textbf{Scaled Running Times} & 205.00 & 4149.00 & 2823.00 & 164.00 & 1.00 \\ \hline
+\textbf{Total Running Time} & 48405 & 979876 & 666792 & 38634 & 236 \\ \hline
+\textbf{Scaled Running Time} & 205 & 4149 & 2823 & 164 & 1 \\ \hline
\end{tabular}
}
\end{table}
\begin{table}[h]
-\caption{Scaled running times for all problems}
+\caption{Total (in seconds) and scaled running times for all problems}
\label{my-label3}
\resizebox{\textwidth}{!}{%
\begin{tabular}{|c|c|c|c|c|c|}
\hline
\textbf{Optimization Solvers} & \textbf{GLPK} & \textbf{lp\_solve} & \textbf{CLP} & \textbf{Gurobi} & \textbf{CPLEX} \\ \hline
-\textbf{Scaled Running Times} & 189.00 & 3822.00 & 2594.00 & 151.00 & 1.00 \\ \hline
+\textbf{Total Running Time} & 48585 & 982737 & 667066 & 38708 & 257 \\ \hline
+\textbf{Scaled Running Time} & 189 & 3822 & 2594 & 151 & 1 \\ \hline
\end{tabular}
}
\end{table}
\contentsline {chapter}{List of Figures}{6}{chapter*.2}
\contentsline {chapter}{List of Tables}{7}{chapter*.3}
\contentsline {chapter}{List of Algorithms}{9}{chapter*.4}
-\contentsline {chapter}{Introduction }{11}{chapter*.5}
-\contentsline {section}{1. General Introduction }{11}{section*.6}
-\contentsline {section}{2. Motivation of the Dissertation }{12}{section*.7}
-\contentsline {section}{3. The Objective of this Dissertation}{12}{section*.8}
-\contentsline {section}{4. Main Contributions of this Dissertation}{12}{section*.9}
-\contentsline {section}{5. Dissertation Outline}{14}{section*.10}
-\contentsline {part}{I\hspace {1em}Scientific Background}{15}{part.1}
-\contentsline {chapter}{\numberline {1}Wireless Sensor Networks}{17}{chapter.1}
-\contentsline {section}{\numberline {1.1}Introduction}{17}{section.1.1}
-\contentsline {section}{\numberline {1.2}Architecture}{18}{section.1.2}
-\contentsline {section}{\numberline {1.3}Types of Wireless Sensor Networks}{20}{section.1.3}
-\contentsline {section}{\numberline {1.4}Applications}{22}{section.1.4}
-\contentsline {section}{\numberline {1.5}The Main Challenges}{25}{section.1.5}
-\contentsline {section}{\numberline {1.6}Energy-Efficient Mechanisms of a working WSN}{27}{section.1.6}
-\contentsline {subsection}{\numberline {1.6.1}Energy-Efficient Routing}{27}{subsection.1.6.1}
-\contentsline {subsubsection}{\numberline {1.6.1.1}Routing Metric based on Residual Energy}{27}{subsubsection.1.6.1.1}
-\contentsline {subsubsection}{\numberline {1.6.1.2}Multipath Routing}{27}{subsubsection.1.6.1.2}
-\contentsline {subsection}{\numberline {1.6.2}Cluster Architecture}{28}{subsection.1.6.2}
-\contentsline {subsection}{\numberline {1.6.3}Scheduling Schemes}{28}{subsection.1.6.3}
-\contentsline {subsubsection}{\numberline {1.6.3.1}Wake up Scheduling Schemes}{28}{subsubsection.1.6.3.1}
-\contentsline {subsubsection}{\numberline {1.6.3.2}Topology Control Schemes}{31}{subsubsection.1.6.3.2}
-\contentsline {subsection}{\numberline {1.6.4}Data-Driven Schemes}{31}{subsection.1.6.4}
-\contentsline {subsubsection}{\numberline {1.6.4.1}Data Reduction Schemes}{32}{subsubsection.1.6.4.1}
-\contentsline {subsubsection}{\numberline {1.6.4.2}Energy Efficient Data Acquisition Schemes}{32}{subsubsection.1.6.4.2}
-\contentsline {subsection}{\numberline {1.6.5}Battery Repletion}{32}{subsection.1.6.5}
-\contentsline {subsection}{\numberline {1.6.6}Radio Optimization}{32}{subsection.1.6.6}
-\contentsline {subsection}{\numberline {1.6.7}Relay nodes and Sink Mobility}{33}{subsection.1.6.7}
-\contentsline {subsubsection}{\numberline {1.6.7.1}Relay node placement}{33}{subsubsection.1.6.7.1}
-\contentsline {subsubsection}{\numberline {1.6.7.2}Sink Mobility}{33}{subsubsection.1.6.7.2}
-\contentsline {section}{\numberline {1.7}Network Lifetime}{33}{section.1.7}
-\contentsline {section}{\numberline {1.8}Coverage in Wireless Sensor Networks }{34}{section.1.8}
-\contentsline {section}{\numberline {1.9}Design Issues for Coverage Problems}{36}{section.1.9}
-\contentsline {section}{\numberline {1.10}Energy Consumption Model}{37}{section.1.10}
-\contentsline {section}{\numberline {1.11}Conclusion}{38}{section.1.11}
-\contentsline {chapter}{\numberline {2}Related Works on Coverage Problems}{39}{chapter.2}
-\contentsline {section}{\numberline {2.1}Introduction}{39}{section.2.1}
-\contentsline {section}{\numberline {2.2}Centralized Algorithms}{41}{section.2.2}
-\contentsline {section}{\numberline {2.3}Distributed Algorithms}{44}{section.2.3}
-\contentsline {subsection}{\numberline {2.3.1}GAF}{46}{subsection.2.3.1}
-\contentsline {subsection}{\numberline {2.3.2}DESK}{48}{subsection.2.3.2}
-\contentsline {section}{\numberline {2.4}Conclusion}{50}{section.2.4}
-\contentsline {chapter}{\numberline {3}Evaluation Tools and Optimization Solvers}{53}{chapter.3}
-\contentsline {section}{\numberline {3.1}Introduction}{53}{section.3.1}
-\contentsline {section}{\numberline {3.2}Evaluation Tools}{53}{section.3.2}
-\contentsline {subsection}{\numberline {3.2.1}Testbed Tools}{54}{subsection.3.2.1}
-\contentsline {subsection}{\numberline {3.2.2}Simulation Tools}{55}{subsection.3.2.2}
-\contentsline {section}{\numberline {3.3}Optimization Solvers}{60}{section.3.3}
-\contentsline {section}{\numberline {3.4}Conclusion}{63}{section.3.4}
-\contentsline {part}{II\hspace {1em}Contributions}{65}{part.2}
-\contentsline {chapter}{\numberline {4}Distributed Lifetime Coverage Optimization Protocol in Wireless Sensor Networks}{67}{chapter.4}
-\contentsline {section}{\numberline {4.1}Introduction}{67}{section.4.1}
-\contentsline {section}{\numberline {4.2}Description of the DiLCO Protocol}{68}{section.4.2}
-\contentsline {subsection}{\numberline {4.2.1}Assumptions and Network Model}{68}{subsection.4.2.1}
-\contentsline {subsection}{\numberline {4.2.2}Primary Point Coverage Model}{69}{subsection.4.2.2}
-\contentsline {subsection}{\numberline {4.2.3}Main Idea}{70}{subsection.4.2.3}
-\contentsline {subsubsection}{\numberline {4.2.3.1}Information Exchange Phase}{71}{subsubsection.4.2.3.1}
-\contentsline {subsubsection}{\numberline {4.2.3.2}Leader Election Phase}{71}{subsubsection.4.2.3.2}
-\contentsline {subsubsection}{\numberline {4.2.3.3}Decision phase}{71}{subsubsection.4.2.3.3}
-\contentsline {subsubsection}{\numberline {4.2.3.4}Sensing phase}{71}{subsubsection.4.2.3.4}
-\contentsline {section}{\numberline {4.3}Primary Points based Coverage Problem Formulation}{72}{section.4.3}
-\contentsline {section}{\numberline {4.4}Simulation Results and Analysis}{74}{section.4.4}
-\contentsline {subsection}{\numberline {4.4.1}Simulation Framework}{74}{subsection.4.4.1}
-\contentsline {subsection}{\numberline {4.4.2}Modeling Language and Optimization Solver}{74}{subsection.4.4.2}
-\contentsline {subsection}{\numberline {4.4.3}Energy Consumption Model}{74}{subsection.4.4.3}
-\contentsline {subsection}{\numberline {4.4.4}Performance Metrics}{75}{subsection.4.4.4}
-\contentsline {subsection}{\numberline {4.4.5}Performance Analysis for Different Subregions}{76}{subsection.4.4.5}
-\contentsline {subsection}{\numberline {4.4.6}Performance Analysis for Primary Point Models}{82}{subsection.4.4.6}
-\contentsline {subsection}{\numberline {4.4.7}Performance Comparison with other Approaches}{87}{subsection.4.4.7}
-\contentsline {section}{\numberline {4.5}Conclusion}{93}{section.4.5}
-\contentsline {chapter}{\numberline {5}Multiround Distributed Lifetime Coverage Optimization Protocol in Wireless Sensor Networks}{95}{chapter.5}
-\contentsline {section}{\numberline {5.1}Introduction}{95}{section.5.1}
-\contentsline {section}{\numberline {5.2}MuDiLCO Protocol Description}{96}{section.5.2}
-\contentsline {subsection}{\numberline {5.2.1}Background Idea and Algorithm}{96}{subsection.5.2.1}
-\contentsline {section}{\numberline {5.3}Primary Points based Multiround Coverage Problem Formulation}{97}{section.5.3}
-\contentsline {section}{\numberline {5.4}Experimental Study and Analysis}{99}{section.5.4}
-\contentsline {subsection}{\numberline {5.4.1}Simulation Setup}{99}{subsection.5.4.1}
-\contentsline {subsection}{\numberline {5.4.2}Metrics}{100}{subsection.5.4.2}
-\contentsline {subsection}{\numberline {5.4.3}Results Analysis and Comparison }{101}{subsection.5.4.3}
-\contentsline {section}{\numberline {5.5}Conclusion}{106}{section.5.5}
-\contentsline {chapter}{\numberline {6}Perimeter-based Coverage Optimization to Improve Lifetime in Wireless Sensor Networks}{109}{chapter.6}
-\contentsline {section}{\numberline {6.1}Introduction}{109}{section.6.1}
-\contentsline {section}{\numberline {6.2}The PeCO Protocol Description}{110}{section.6.2}
-\contentsline {subsection}{\numberline {6.2.1}Assumptions and Models}{110}{subsection.6.2.1}
-\contentsline {subsection}{\numberline {6.2.2}The Main Idea}{113}{subsection.6.2.2}
-\contentsline {subsection}{\numberline {6.2.3}PeCO Protocol Algorithm}{113}{subsection.6.2.3}
-\contentsline {section}{\numberline {6.3}Perimeter-based Coverage Problem Formulation}{114}{section.6.3}
-\contentsline {section}{\numberline {6.4}Performance Evaluation and Analysis}{116}{section.6.4}
-\contentsline {subsection}{\numberline {6.4.1}Simulation Settings}{116}{subsection.6.4.1}
-\contentsline {subsection}{\numberline {6.4.2}Simulation Results}{117}{subsection.6.4.2}
-\contentsline {subsubsection}{\numberline {6.4.2.1}Coverage Ratio}{118}{subsubsection.6.4.2.1}
-\contentsline {subsubsection}{\numberline {6.4.2.2}Active Sensors Ratio}{118}{subsubsection.6.4.2.2}
-\contentsline {subsubsection}{\numberline {6.4.2.3}The Energy Consumption}{119}{subsubsection.6.4.2.3}
-\contentsline {subsubsection}{\numberline {6.4.2.4}The Network Lifetime}{119}{subsubsection.6.4.2.4}
-\contentsline {section}{\numberline {6.5}Conclusion}{122}{section.6.5}
-\contentsline {part}{III\hspace {1em}Conclusion and Perspectives}{123}{part.3}
-\contentsline {chapter}{\numberline {7}Conclusion and Perspectives}{125}{chapter.7}
-\contentsline {section}{\numberline {7.1}Conclusion}{125}{section.7.1}
-\contentsline {section}{\numberline {7.2}Perspectives}{126}{section.7.2}
-\contentsline {part}{Bibliographie}{142}{chapter*.11}
+\contentsline {chapter}{Abstruct}{9}{chapter*.4}
+\contentsline {chapter}{Introduction }{13}{chapter*.5}
+\contentsline {section}{1. General Introduction }{13}{section*.6}
+\contentsline {section}{2. Motivation of the Dissertation }{14}{section*.7}
+\contentsline {section}{3. The Objective of this Dissertation}{14}{section*.8}
+\contentsline {section}{4. Main Contributions of this Dissertation}{14}{section*.9}
+\contentsline {section}{5. Dissertation Outline}{16}{section*.10}
+\contentsline {part}{I\hspace {1em}Scientific Background}{17}{part.1}
+\contentsline {chapter}{\numberline {1}Wireless Sensor Networks}{19}{chapter.1}
+\contentsline {section}{\numberline {1.1}Introduction}{19}{section.1.1}
+\contentsline {section}{\numberline {1.2}Architecture}{20}{section.1.2}
+\contentsline {section}{\numberline {1.3}Types of Wireless Sensor Networks}{22}{section.1.3}
+\contentsline {section}{\numberline {1.4}Applications}{24}{section.1.4}
+\contentsline {section}{\numberline {1.5}The Main Challenges}{27}{section.1.5}
+\contentsline {section}{\numberline {1.6}Energy-Efficient Mechanisms of a working WSN}{29}{section.1.6}
+\contentsline {subsection}{\numberline {1.6.1}Energy-Efficient Routing}{29}{subsection.1.6.1}
+\contentsline {subsubsection}{\numberline {1.6.1.1}Routing Metric based on Residual Energy}{29}{subsubsection.1.6.1.1}
+\contentsline {subsubsection}{\numberline {1.6.1.2}Multipath Routing}{29}{subsubsection.1.6.1.2}
+\contentsline {subsection}{\numberline {1.6.2}Cluster Architecture}{30}{subsection.1.6.2}
+\contentsline {subsection}{\numberline {1.6.3}Scheduling Schemes}{30}{subsection.1.6.3}
+\contentsline {subsubsection}{\numberline {1.6.3.1}Wake up Scheduling Schemes}{30}{subsubsection.1.6.3.1}
+\contentsline {subsubsection}{\numberline {1.6.3.2}Topology Control Schemes}{33}{subsubsection.1.6.3.2}
+\contentsline {subsection}{\numberline {1.6.4}Data-Driven Schemes}{33}{subsection.1.6.4}
+\contentsline {subsubsection}{\numberline {1.6.4.1}Data Reduction Schemes}{34}{subsubsection.1.6.4.1}
+\contentsline {subsubsection}{\numberline {1.6.4.2}Energy Efficient Data Acquisition Schemes}{34}{subsubsection.1.6.4.2}
+\contentsline {subsection}{\numberline {1.6.5}Battery Repletion}{34}{subsection.1.6.5}
+\contentsline {subsection}{\numberline {1.6.6}Radio Optimization}{34}{subsection.1.6.6}
+\contentsline {subsection}{\numberline {1.6.7}Relay nodes and Sink Mobility}{35}{subsection.1.6.7}
+\contentsline {subsubsection}{\numberline {1.6.7.1}Relay node placement}{35}{subsubsection.1.6.7.1}
+\contentsline {subsubsection}{\numberline {1.6.7.2}Sink Mobility}{35}{subsubsection.1.6.7.2}
+\contentsline {section}{\numberline {1.7}Network Lifetime}{35}{section.1.7}
+\contentsline {section}{\numberline {1.8}Coverage in Wireless Sensor Networks }{36}{section.1.8}
+\contentsline {section}{\numberline {1.9}Design Issues for Coverage Problems}{38}{section.1.9}
+\contentsline {section}{\numberline {1.10}Energy Consumption Model}{39}{section.1.10}
+\contentsline {section}{\numberline {1.11}Conclusion}{40}{section.1.11}
+\contentsline {chapter}{\numberline {2}Related Works on Coverage Problems}{41}{chapter.2}
+\contentsline {section}{\numberline {2.1}Introduction}{41}{section.2.1}
+\contentsline {section}{\numberline {2.2}Centralized Algorithms}{43}{section.2.2}
+\contentsline {section}{\numberline {2.3}Distributed Algorithms}{46}{section.2.3}
+\contentsline {subsection}{\numberline {2.3.1}GAF}{48}{subsection.2.3.1}
+\contentsline {subsection}{\numberline {2.3.2}DESK}{50}{subsection.2.3.2}
+\contentsline {section}{\numberline {2.4}Conclusion}{52}{section.2.4}
+\contentsline {chapter}{\numberline {3}Evaluation Tools and Optimization Solvers}{55}{chapter.3}
+\contentsline {section}{\numberline {3.1}Introduction}{55}{section.3.1}
+\contentsline {section}{\numberline {3.2}Evaluation Tools}{55}{section.3.2}
+\contentsline {subsection}{\numberline {3.2.1}Testbed Tools}{56}{subsection.3.2.1}
+\contentsline {subsection}{\numberline {3.2.2}Simulation Tools}{57}{subsection.3.2.2}
+\contentsline {section}{\numberline {3.3}Optimization Solvers}{62}{section.3.3}
+\contentsline {section}{\numberline {3.4}Conclusion}{65}{section.3.4}
+\contentsline {part}{II\hspace {1em}Contributions}{67}{part.2}
+\contentsline {chapter}{\numberline {4}Distributed Lifetime Coverage Optimization Protocol in Wireless Sensor Networks}{69}{chapter.4}
+\contentsline {section}{\numberline {4.1}Introduction}{69}{section.4.1}
+\contentsline {section}{\numberline {4.2}Description of the DiLCO Protocol}{70}{section.4.2}
+\contentsline {subsection}{\numberline {4.2.1}Assumptions and Network Model}{70}{subsection.4.2.1}
+\contentsline {subsection}{\numberline {4.2.2}Primary Point Coverage Model}{71}{subsection.4.2.2}
+\contentsline {subsection}{\numberline {4.2.3}Main Idea}{72}{subsection.4.2.3}
+\contentsline {subsubsection}{\numberline {4.2.3.1}Information Exchange Phase}{73}{subsubsection.4.2.3.1}
+\contentsline {subsubsection}{\numberline {4.2.3.2}Leader Election Phase}{73}{subsubsection.4.2.3.2}
+\contentsline {subsubsection}{\numberline {4.2.3.3}Decision phase}{73}{subsubsection.4.2.3.3}
+\contentsline {subsubsection}{\numberline {4.2.3.4}Sensing phase}{73}{subsubsection.4.2.3.4}
+\contentsline {section}{\numberline {4.3}Primary Points based Coverage Problem Formulation}{74}{section.4.3}
+\contentsline {section}{\numberline {4.4}Simulation Results and Analysis}{76}{section.4.4}
+\contentsline {subsection}{\numberline {4.4.1}Simulation Framework}{76}{subsection.4.4.1}
+\contentsline {subsection}{\numberline {4.4.2}Modeling Language and Optimization Solver}{76}{subsection.4.4.2}
+\contentsline {subsection}{\numberline {4.4.3}Energy Consumption Model}{76}{subsection.4.4.3}
+\contentsline {subsection}{\numberline {4.4.4}Performance Metrics}{77}{subsection.4.4.4}
+\contentsline {subsection}{\numberline {4.4.5}Performance Analysis for Different Subregions}{78}{subsection.4.4.5}
+\contentsline {subsection}{\numberline {4.4.6}Performance Analysis for Primary Point Models}{84}{subsection.4.4.6}
+\contentsline {subsection}{\numberline {4.4.7}Performance Comparison with other Approaches}{89}{subsection.4.4.7}
+\contentsline {section}{\numberline {4.5}Conclusion}{95}{section.4.5}
+\contentsline {chapter}{\numberline {5}Multiround Distributed Lifetime Coverage Optimization Protocol in Wireless Sensor Networks}{97}{chapter.5}
+\contentsline {section}{\numberline {5.1}Introduction}{97}{section.5.1}
+\contentsline {section}{\numberline {5.2}MuDiLCO Protocol Description}{98}{section.5.2}
+\contentsline {subsection}{\numberline {5.2.1}Background Idea and Algorithm}{98}{subsection.5.2.1}
+\contentsline {section}{\numberline {5.3}Primary Points based Multiround Coverage Problem Formulation}{99}{section.5.3}
+\contentsline {section}{\numberline {5.4}Experimental Study and Analysis}{101}{section.5.4}
+\contentsline {subsection}{\numberline {5.4.1}Simulation Setup}{101}{subsection.5.4.1}
+\contentsline {subsection}{\numberline {5.4.2}Metrics}{102}{subsection.5.4.2}
+\contentsline {subsection}{\numberline {5.4.3}Results Analysis and Comparison }{103}{subsection.5.4.3}
+\contentsline {section}{\numberline {5.5}Conclusion}{108}{section.5.5}
+\contentsline {chapter}{\numberline {6}Perimeter-based Coverage Optimization to Improve Lifetime in Wireless Sensor Networks}{111}{chapter.6}
+\contentsline {section}{\numberline {6.1}Introduction}{111}{section.6.1}
+\contentsline {section}{\numberline {6.2}The PeCO Protocol Description}{112}{section.6.2}
+\contentsline {subsection}{\numberline {6.2.1}Assumptions and Models}{112}{subsection.6.2.1}
+\contentsline {subsection}{\numberline {6.2.2}The Main Idea}{115}{subsection.6.2.2}
+\contentsline {subsection}{\numberline {6.2.3}PeCO Protocol Algorithm}{115}{subsection.6.2.3}
+\contentsline {section}{\numberline {6.3}Perimeter-based Coverage Problem Formulation}{116}{section.6.3}
+\contentsline {section}{\numberline {6.4}Performance Evaluation and Analysis}{118}{section.6.4}
+\contentsline {subsection}{\numberline {6.4.1}Simulation Settings}{118}{subsection.6.4.1}
+\contentsline {subsection}{\numberline {6.4.2}Simulation Results}{119}{subsection.6.4.2}
+\contentsline {subsubsection}{\numberline {6.4.2.1}Coverage Ratio}{120}{subsubsection.6.4.2.1}
+\contentsline {subsubsection}{\numberline {6.4.2.2}Active Sensors Ratio}{120}{subsubsection.6.4.2.2}
+\contentsline {subsubsection}{\numberline {6.4.2.3}The Energy Consumption}{121}{subsubsection.6.4.2.3}
+\contentsline {subsubsection}{\numberline {6.4.2.4}The Network Lifetime}{121}{subsubsection.6.4.2.4}
+\contentsline {section}{\numberline {6.5}Conclusion}{124}{section.6.5}
+\contentsline {part}{III\hspace {1em}Conclusion and Perspectives}{125}{part.3}
+\contentsline {chapter}{\numberline {7}Conclusion and Perspectives}{127}{chapter.7}
+\contentsline {section}{\numberline {7.1}Conclusion}{127}{section.7.1}
+\contentsline {section}{\numberline {7.2}Perspectives}{128}{section.7.2}
+\contentsline {part}{Bibliographie}{144}{chapter*.11}
