source: Publications/Wilfried Dron/JOURNAL - Scheduling Method for Network Lifetime Estimation of WSN/Scheduling Method for Network Lifetime Estimation of Wireless Sensor Network.tex @ 148

%% bare_jrnl.tex
%% V1.3
%% 2007/01/11
%% by Michael Shell
%% see http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE journal paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/



% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/


%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
\documentclass[journal]{IEEEtran}
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[journal]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  % \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is Scott Pakin's eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.


%\ifCLASSOPTIONcaptionsoff
%  \usepackage[nomarkers]{endfloat}
% \let\MYoriglatexcaption\caption
% \renewcommand{\caption}[2][\relax]{\MYoriglatexcaption[#2]{#2}}
%\fi
% endfloat.sty was written by James Darrell McCauley and Jeff Goldberg.
% This package may be useful when used in conjunction with IEEEtran.cls'
% captionsoff option. Some IEEE journals/societies require that submissions
% have lists of figures/tables at the end of the paper and that
% figures/tables without any captions are placed on a page by themselves at
% the end of the document. If needed, the draftcls IEEEtran class option or
% \CLASSINPUTbaselinestretch interface can be used to increase the line
% spacing as well. Be sure and use the nomarkers option of endfloat to
% prevent endfloat from "marking" where the figures would have been placed
% in the text. The two hack lines of code above are a slight modification of
% that suggested by in the endfloat docs (section 8.3.1) to ensure that
% the full captions always appear in the list of figures/tables - even if
% the user used the short optional argument of \caption[]{}.
% IEEE papers do not typically make use of \caption[]'s optional argument,
% so this should not be an issue. A similar trick can be used to disable
% captions of packages such as subfig.sty that lack options to turn off
% the subcaptions:
% For subfig.sty:
% \let\MYorigsubfloat\subfloat
% \renewcommand{\subfloat}[2][\relax]{\MYorigsubfloat[]{#2}}
% For subfigure.sty:
% \let\MYorigsubfigure\subfigure
% \renewcommand{\subfigure}[2][\relax]{\MYorigsubfigure[]{#2}}
% However, the above trick will not work if both optional arguments of
% the \subfloat/subfig command are used. Furthermore, there needs to be a
% description of each subfigure *somewhere* and endfloat does not add
% subfigure captions to its list of figures. Thus, the best approach is to
% avoid the use of subfigure captions (many IEEE journals avoid them anyway)
% and instead reference/explain all the subfigures within the main caption.
% The latest version of endfloat.sty and its documentation can obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/endfloat/
%
% The IEEEtran \ifCLASSOPTIONcaptionsoff conditional can also be used
% later in the document, say, to conditionally put the References on a 
% page by themselves.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.





% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}
\usepackage{cite}  
\usepackage{graphicx}
\usepackage{graphicx}
\usepackage{xcolor}
\usepackage{upquote}
%\usepackage{hyperref}
\usepackage{url}
\usepackage{arydshln}
\usepackage{listings}
\usepackage{subfigure}
\usepackage{balance}
\usepackage{xspace}
%\usepackage[caption=false]{subfig}
\newcommand{\pmsg}{{\textit{PowerMessage}}}
\newcommand{\imsg}{{\textit{InterfaceMessage}}}
\newcommand{\smsg}{{\textit{SignalMessage}}}
\newcommand{\dmsg}{{\textit{DigitalMessage}}}
\newcommand{\amsg}{{\textit{AnalogMessage}}}
\newcommand{\cmsg}{{\textit{ControlMessage}}}
\newcommand{\phymsg}{{\textit{PhysicalMessage}}}
\newcommand{\fm}{{{FM}}}
\newcommand{\pmm}{{{PM}}}
\newcommand{\phym}{{{PhyM}}}

\newcommand{\warn}{\textcolor{red}{\textbf{[REF]\space}}}
\newcommand{\tuple}[1]{\ensuremath{\left \langle #1 \right \rangle }}
\newcommand{\todo}[1]{\textcolor{blue}{{\bf Todo --\xspace}{\em #1}}}
\newcommand{\ie}{{\it i.e.},\xspace}
\newcommand{\eg}{{\it e.g.},\xspace}
\newcommand{\etal}{{\it et al.}\xspace}
\newcommand{\cf}{{\it c.f.},\xspace}

\newcommand{\sa}{{\textit{SA}}}
\newcommand{\fed}{{\textit{FED}}}
\newcommand{\sued}{{\textit{SUED}}}
\newcommand{\ffs}{{\textit{FFS}}}

\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Scheduling Methods for Network Lifetime Estimation of Wireless Sensor Networks}
%
%
% author names and IEEE memberships
% note positions of commas and nonbreaking spaces ( ~ ) LaTeX will not break
% a structure at a ~ so this keeps an author's name from being broken across
% two lines.
% use \thanks{} to gain access to the first footnote area
% a separate \thanks must be used for each paragraph as LaTeX2e's \thanks
% was not built to handle multiple paragraphs
%

\author{Wilfried~Dron,~\IEEEmembership{Member,~IEEE,}
        Khalil~Hachicha,~\IEEEmembership{Fellow,~OSA,}
        and~Patrick~Garda,~\IEEEmembership{Life~Fellow,~IEEE}% <-this % stops a space
\thanks{W. Dron, K. Hachicha and P. Garda are with the UPMC Univ Paris 6, UMR 7606, Laboratoire d'Informatique de Paris 6. They are also with CNRS, UMR7606, LIP6.
F-75005, Paris, France;
e-mail: \texttt{[wilfried.dron; khalil.hachicha; patrick.garda]@lip6.fr}.}% <-this % stops a space
\thanks{Manuscript received Month Day, Year; revised Month Day, Year.}}

% note the % following the last \IEEEmembership and also \thanks - 
% these prevent an unwanted space from occurring between the last author name
% and the end of the author line. i.e., if you had this:
% 
% \author{....lastname \thanks{...} \thanks{...} }
%                     ^------------^------------^----Do not want these spaces!
%
% a space would be appended to the last name and could cause every name on that
% line to be shifted left slightly. This is one of those "LaTeX things". For
% instance, "\textbf{A} \textbf{B}" will typeset as "A B" not "AB". To get
% "AB" then you have to do: "\textbf{A}\textbf{B}"
% \thanks is no different in this regard, so shield the last } of each \thanks
% that ends a line with a % and do not let a space in before the next \thanks.
% Spaces after \IEEEmembership other than the last one are OK (and needed) as
% you are supposed to have spaces between the names. For what it is worth,
% this is a minor point as most people would not even notice if the said evil
% space somehow managed to creep in.



% The paper headers
\markboth{Transactions on COMPUTER-AIDED DESIGN of Integrated Circuits and Systems,~Vol.~X, No.~Y, Month~Year}%
{}
%{Shell \MakeLowercase{\textit{et al.}}: Bare Demo of IEEEtran.cls for Journals}
% The only time the second header will appear is for the odd numbered pages
% after the title page when using the twoside option.
% 
% *** Note that you probably will NOT want to include the author's ***
% *** name in the headers of peer review papers.                   ***
% You can use \ifCLASSOPTIONpeerreview for conditional compilation here if
% you desire.




% If you want to put a publisher's ID mark on the page you can do it like
% this:
%\IEEEpubid{0000--0000/00\$00.00~\copyright~2007 IEEE}
% Remember, if you use this you must call \IEEEpubidadjcol in the second
% column for its text to clear the IEEEpubid mark.



% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle


\begin{abstract}
%\boldmath
The network lifetime is a major requirement for the design of WSN's hardware and software. 
%While several simulation tools are focused on power consumption estimation, the network lifetime has been estimated using an ideal battery model. 
While several simulation tools are focused on estimating power consumption, the lifetime is commonly computed using a simple ideal battery model.
As a consequence, issues related to the use of a more realistic (non-ideal) battery model are not addressed yet. 
Considering the error that is made in node's lifetime estimation using an ideal battery model (up to 40\%), specifications-based models were implemented to achieve more reliable predictions. 
In this context, we introduce four scheduling methods to address the challenges relative to such battery models.
These methods manage energy transactions between the wireless node model and a non-ideal battery model.
%In this context, we introduce four scheduling methods to manage the energy transactions between the wireless node model and a non-ideal battery model, allowing a more accurate network lifetime estimation to be achieved. 
Each of our methods is analyzed and compared through a typical temperature sensing application case. 
We conducted several simulations considering power consumption estimation, simulation performances, node lifetime estimation and scalability. 
Comparison of the obtained results highlights two methods, one more accurate, but rather slow, whereas the other is strongly scalable, but less accurate.
\end{abstract}

% Note that keywords are not normally used for peerreview papers.
\begin{IEEEkeywords}
battery, lifetime estimation, wsn, OMNeT++, scheduling.
\end{IEEEkeywords}






% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



\section{Introduction}
\IEEEPARstart{T}{he} network lifetime is a key parameter of the wireless sensor network characterization~\cite{lifetime}. 
It reflects the time while the network can operate properly according to application-defined constraints.
%Even if almost every application defines its own constraints, the network lifetime cannot be estimated without being able to estimate the node's lifetime.
Even if almost every application defines its own constraints, the network lifetime is estimated using the individual nodes' lifetime. 
Since some specific application requires the nodes to have a long lifetime~\cite{outdoor_gplatform} (\eg from several weeks to several years) and/or the network to count several dozen of nodes~\cite{wsn_trends}, it is common to use simulation and modeling tools to design such devices.

Nodes are battery-powered, thus the power consumption of the node and its battery characteristics are both necessary to determine its lifetime.
The power consumption profile is easily accessible from hardware measurements~\cite{wsn_energy} whereas it is more challenging to extract battery characteristics. 
Hence, it is common to use an ideal battery model to model the node's power source. 
This model is known as a battery with a linear discharge curve and a fixed output voltage.
Far from the real battery behavior, this model has the advantage to be flexible enough to not address the physical and electrical laws that exist in a real system. %between a real battery and the node that it supplies. 
%Nevertheless, when more accuracy is needed (as it is for medical applications for instance~\cite{wsn_app_medical_survey}) a more realistic battery model is required. 
To obtain more accurate lifetime estimation, another battery model, closer to the real battery behavior, is required. 
It can be either based on experimental measurements or technical specifications. 
To remain consistent using such a model, electrical laws have to be applied. 
Therefore, it is important to pay attention to the way power transactions between battery and supplied components are achieved.
In other words, the scheduling of the energy transactions trough the simulated time is crucial (\cf Fig.~\ref{archi_methods}).
%As a consequence, the scheduling of the energy transactions among the battery and the electronic components models is important. 
%Actually, it has a strong impact over the node's lifetime prediction. 
%In this article, we show that the way this scheduling is achieved impact significantly the lifetime estimation.
%Moreover, the way this scheduling is managed impacts the overall simulation performances and therefore, the ability to run large scale and/or long time simulation. 
%As a side effect, the scheduling method also impact the overall simulation performances, restricting the ability to simulate large scale and/or long time lasting networks.

In this context, we introduce four scheduling methods to schedule the energy transactions in a modeled wireless sensor network node. 
%We show that these methods are influencing the node lifetime estimation. 
We show that the scheduling has a significant impact on the lifetime estimation, showing differences in the obtained results that reach 11.7\%. 
%Moreover, the simulation's performance is also impacted, bounding the uses of certain methods to small-sized networks or short lifetime modeling.
As a side effect, the scheduling method also impacts the overall simulation performances, restricting the ability to simulate large scale and/or long time lasting networks.

This article is structured as follows. 
The second section holds the background of this work. 
The scheduling methods principles are explained in the section 3. 
The fourth section addresses the implementation of these methods in OMNeT++ through a WSN framework that is oriented towards power consumption estimation. 
Finally, the two last sections hold respectively the simulation results and their discussion.

\begin{figure}
\begin{center}
\includegraphics[scale=0.35]{architecture.pdf}
\caption{\label{archi_methods}
\textbf{Application example of the scheduling methods:} 
Here, \textsl{scheduling} stands for the way the supply voltage (v) is transmitted from battery to components and the way the instantaneous current draw (i) is transmitted from the component to the battery through the simulated time.
}
\end{center}
\end{figure}

\section{Background}
Scheduling methods for energy transactions have not been addressed yet, thus there is no previous work on that subject. 
However, there are some related works that deal with the power consumption estimation issues for the wireless sensor network simulation. 
Since the node lifetime estimation relies on the battery models as well, it is important to give a brief introduction to the battery behavior. 
For that purpose, this section holds a short background about the battery behavior before addressing the core-related works.

\subsection{Battery Behavior and Modeling} \label{sect:battery_desc}
The primary batteries are electrochemical power sources. 
In contrast with the wired power sources, the amount of energy that they carry is limited. 
This amount of energy is called \textit{nominal capacity} if the battery is new or \textit{residual capacity} (shorten to \textit{residual}) if it has been partially used. 
Considering a battery under use, its residual varies with the ambient temperature and the instantaneous current draw. 
In other words, the available amount of energy changes over the time according to the aforementioned factors. 
The battery's \textit{nominal current} (set by the manufacturer) represent the ``normal operation'' current limit under continuous draw.
The term \textit{effective capacity} stands for the battery's capacity that is really available given a set of condition (\eg a specific instantaneous current draw and temperature). 
Furthermore, the supply voltage varies as well with temperature and instantaneous current draw but also with the residual. 
As a consequence, a specific current draw can produce a drift in the battery's supply voltage value. 
According to the ohm law, this drift will change the current draw itself leading to a new drift. 
%Considering a resistive circuit, the voltage value would reach an equilibrium which is not the case considering regulated system like voltage regulators for instance. 
%All these assumptions were experimentally validated.

A first study highlights the fact that the way in which the components are drawing the current has a strong influence on the \textsl{effective capacity}~\cite{battery_char}. 
These observations were confirmed by a more recent work that characterized commercial Li-Ion batteries behaviors through real measurements~\cite{battery_char_new}. 
In this work, {K. Mikhaylov} and {J. Tervonen} observed again that the available capacity of the battery depends mainly on the instantaneous current draw under constant temperature. 
%Another article that focuses on remaining capacity measurements agrees on the same conclusion~\cite{remaining_capacity_measurement}. 

Another article agrees on the same conclusion~\cite{remaining_capacity_measurement}. 
This last work addressed the specific case of determining the remaining battery capacity for a wireless sensor node using a method that consider the effective capacity and the instantaneous current draw instead of the voltage information. 

More battery centered work were conducted to reach a better understanding of the battery properties. 
Among them, another property known as \textit{relaxation effect} is explained in two articles written by L. Feeney and al.~\cite{battery_feeney,battery_model_feeney}.
As mentioned, when a strong current is drawn from the battery, its \textsl{effective capacity} decreases. 
In other words, its actual available energy is lower than the nominal value. 
This assumption is valid for a current draw that remains the same until the end of the battery life. 
For instance, if the current draw decrease to a value that is beyond the battery's ``nominal current'', the battery will ``recover'' some capacity. 

%To summarize, there are strong evidences that explain the limitations of ideal battery model. 
To summarize, the aforementioned evidences clearly established the limitations of the ideal battery model.
While this model is extremely flexible and fast thanks to the fact that it is not dependent on any electrical or electrochemical effects, it is highly inaccurate and does not reproduce the behavior of a real battery.

\subsection{Simulation and Modeling Environments}
There are several simulators and frameworks that enable the power consumption estimation. 
Among them, a distinction is made between the environments that are oriented towards a specific platform and those that are more general, allowing any platform to be modeled. 
TOSSIM~\cite{tossim_ws} is, for instance, a network simulator dedicated to Tiny-OS~\cite{tinyos}. 
This simulator is extended by many further work. 
The most noticeable are Power-TOSSIM~\cite{powertossim_ws} and mTOSSIM~\cite{mtossim}.
Power-TOSSIM enables the power consumption to be computed after the simulation ends.
In contrast, mTOSSIM goes further, allowing the lifetime to be estimated.
It does so using a super-capacitor to model the power supply of the nodes.
The super-capacitor behavior is very different from the battery behavior (\cf Section~\ref{sect:battery_desc}).
As a consequence, this model cannot be used to estimate the lifetime of nodes equipped with batteries.

%Platform-dedicated simulation environment are for instance Cooja~\cite{cooja}, the simulator of ContikiOS or Power-Tossim~\cite{powertossim_ws}, the simulator of Tiny-OS. 
%While these two simulators can achieve a precise power consumption estimation according to a specific application and its targeted hardware platform~\cite{powertossimz}, their main drawback is to be limited to the OS that they are simulating. 
%Furthermore, none of them is providing a node lifetime estimation or only based on ideal battery model. 
%As a consequence, these works are out of the scope of this paper.
 
Regarding the more general simulation environments, there are several network simulators like NS-2/3~\cite{ns2_ws}, OMNeT++~\cite{omnet_ws}, WSNeT~\cite{wsnet} or IdeaOne~\cite{ideaone}. 
Some of them are able to estimate power consumption thanks to extensions called \textit{frameworks}.
However, the goal of these environments is to deal with network modeling issues more than network lifetime estimation. 
The OMNeT++ simulator is less concerned than the other environments since its flexibility allows new features to be integrated more easily, as described in many surveys \cite{sim_survey_0,sim_survey_1,sim_survey_2,sim_survey_3} or in dedicated report from A. Varga and R. Hornig~\cite{omnet_overview}. 
As a consequence, several~\textit{power-aware} frameworks were developed over the previous years. 
Energy Model~\cite{modeling_energy}, Pawis~\cite{pawis_fm_2} and Energy Framework~\cite{energy_fm} were thus introduced. 
Unfortunately, a common short-coming of these frameworks is that none of them provides a non-ideal battery model.

Nevertheless, this short-coming was partially covered in an extension of the Energy Framework~\cite{energy_fm_2}. 
In their article, K. Mikhaylov and J. Tervonen presented a battery model that was validated through measurements of real batteries~\cite{battery_char_new}. 
Unfortunately, this validation does not consider battery supply voltage variations due to the current draw.
Furthermore, it neglects the internal resistance of the battery and the relaxation effect.
A side observation that the authors made is the fact that using an ideal battery model leads to an over-evaluation of the battery lifetime of almost $40$\%.
%Their first conclusion is the fact that using an ideal battery model leads to an over-evaluation of the battery lifetime of almost $40$\%. 
%Unfortunately, the techniques that were used to schedule the transaction between the battery model and the components model were not presented. 
%Moreover, the simulation case that was chosen was limited to a simple resistive model in which the supply voltage drifts were not considered. 
%As a result, it is difficult to re-use this work as a base for the network lifetime estimation. 

A last power-aware framework for OMNeT++ was introduced~\cite{newcas}. 
The battery model that is provided by the authors was built following technical specifications. 
%Finally, the conclusion of their work states on the fact that using of the event driven technique together with their battery model results in erroneous battery lifetime estimations.
Finally, the conclusion of their work states that the formal event driven technique used together with their battery model results in erroneous battery lifetime estimations. 
%To address this issue, they introduced a periodical scheduling method called \textit{Fixed Frequency Sampling} method.

%This latest framework was selected to implement the scheduling method because of its unique component oriented architecture and the several proposed models. 
%The following section is dedicated to the description of the methods. 
%Therefore, the firstly introduced scheduling method \textit{Fixed Frequency Sampling} will be exposed again in a more detailed way.

\section{Scheduling Methods} \label{sec:schedul_meth}
In this context, we introduce four scheduling methods to address the challenges relative to non-ideal battery models.

All along this section we are assuming the statement that the wireless sensor nodes are described using a model for each of the hardware component that they embeds.
In other words, the architecture that is considered here is composed of one to N components models and a battery that supply them (\cf Fig.\ref{archi_methods}). 
Each component's model is assumed to have as many power modes as the modeled component has (\eg ON, OFF, POWER DOWN or SLEEP).
A specific instantaneous current draw is associated to each power mode.
Consequently, each power mode change results in a new instantaneous current draw.
Considering these statements, modeling of the supply voltage and the instantaneous current draw are mandatory to apply the following scheduling methods. 

The ``end-of-life'' of the battery can be expressed in two ways: the total depletion of the battery (which is unlikely to happen in real experimental case) or reaching the cut-off voltage threshold.
The cut-off voltage threshold is the most robust approach. 
Actually, the cut-off voltage is the voltage value under which the electronic components operation are not guaranteed.
However, the above descriptions are applicable in both cases.
%Our scheduling methods can be used in any structure that model one to N battery-supplied components. 
%Modeling of the supply voltage and the instantaneous current draw is the only requirement that could limit their application. 

This sections holds the description of our scheduling methods.
A concrete application case is added as an example after the general descriptions.
% in order to expose the differences between every scheduling method. 
Integration of these scheduling algorithms is explained as the conclusion of the section. 

%%%%% METHODS DESCRIPTION
\begin{figure}
\begin{center}
\includegraphics[scale=0.45]{schedule_FFS.pdf}
\caption{\label{figure1}
\textbf{Fixed frequency sampling method states graphic:} 
This graph shows the principle of the \ffs\xspace method. 
The battery update are triggered periodically (each \textit{T} second) after the step~5.
}
\end{center}
\end{figure}

\subsection{Fixed Frequency Sampling method (FFS)}
The \textit{Fixed Frequency Sampling} method (shorten to \ffs) was introduced into prior work~\cite{newcas}. 
This method relies on a periodic update of the battery's parameters and the current drawn by the components. 
Figure~\ref{figure1} is a state chart that describes its scheduling algorithm. 
First of all, the battery initiates the simulation by sending its supply voltage value to the component.
This allows the components to turn into ON mode. 
Then, they send back their averaged instantaneous current consumption over the previous period (which is null for the very first period).
The battery residual and the supply voltage are then updated according to the received current draw value. 
Finally, if there is enough energy in the battery, the next update is scheduled at $t+T$ time (\textit{T} being the ``sampling period'' expressed in seconds). 
If the battery is depleted, the simulation stops (\eg by sending a $0.0$V supply voltage that force the components to turn into OFF mode).
%If the battery is depleted, it sends a $0.0$V supply voltage that turns the components into OFF mode.

\subsection{Self Updating Event Driven method (SUED)}
In contrast with the \ffs\xspace method, the \textit{Self Updating Event Driven} method takes into account every current draw change instantaneously. 
The \sued\xspace scheduling method uses the same state chart as the \ffs\xspace method (\cf Fig.\ref{figure1}), except that it triggers additional battery updates as explained in the following.
When the simulation starts, the battery sends its supply voltage value to the components. 
The components send back their instantaneous current draw. 
Then the supply voltage and the remaining capacity of the battery are updated using the received value of the current draw. 
This current draw value is stored. 
If none of the components change their instantaneous current draw value, the battery will be updated every \textit{T} seconds. 
When a component changes its power mode (\eg ON $\rightarrow$ POWER DOWN), the corresponding instantaneous current draw value is sent to the battery. 
Then, the regular updating process is interrupted. 
The battery residual and the supply voltage are updated for the time elapsed from the last battery's update using the latest stored instantaneous current draw value. 
Finally, this latest current draw value is replaced by the just received one and the regular updating process starts again by scheduling the next update at $t+T$ ($t$ being the actual simulated time expressed in seconds).

\begin{figure} 
\begin{center}
\includegraphics[scale=0.45]{schedule_FED.pdf}
\caption{\label{figure3}
\textbf{Fast event driven method state graphic:} 
This graph shows the principle of the \fed\xspace method. 
In this method, the battery update are triggered by each components' power mode change.
}
\end{center}
\end{figure}

\subsection{Fast Event Driven method (FED)}
The \textit{Fast Event Driven} method is derived from the ``formal'' event driven simulation technique. 
As a consequence, the battery updates are triggered by each instantaneous current draw changes. 
The state chart depicted in the Figure~\ref{figure3} represents the behavior of this scheduling method. 
The battery initiates the simulation by sending its supply voltage value. 
As a consequence, the components change their power modes (\ie from OFF to ON) and send back their associated instantaneous current draw value. 
In the same way as the \sued\xspace method, this current draw value is stored by the battery model. 
When a component changes its power mode again, this value is updated. 
Before storing the just received value, a battery update is performed. 
%Actually, it will estimate and check its new residual value considering the time elapsed from the previous update. 
This update consists of checking and computing the new battery's residual considering the time elapsed since the previous update.
Battery's supply voltage value is also updated, but using the new instantaneous current draw value and the residual that has just been estimated. 
Finally, this supply voltage value is sent to the component. 

Since the \fed\xspace scheduling method does not trigger updates of the battery periodically, using this method can lead to nodes operating without energy.
If there is no event that makes the current draw change (\ie power mode changes), the simulation can run even if the battery is totally depleted at a certain point. 
%As a consequence, another mechanism is required. 
%A way to avoid this issue is to ``plan'' the end of the battery life assuming that there will be no more event. 
%The end of life of the battery has to be forecast 
A way to avoid this issue is to forecast the battery's end-of-life (being either the full discharge of the battery or the discharge until the cut-off voltage value) assuming that there will be no more event. 
To be consistent, this end-of-life forecast has to be re-evaluated each time the current draw value changes. 
In other words, the battery's end of life has to be re-planned each time that a battery update is triggered.

\subsection{Self Adaptive method (SA)}
The \textit{Self Adaptive} method is based on both a periodical update schedule and an event-driven like schedule. 
%Actually, the previously introduced method are sensitive to the time and/or to the current draw changes events. 
In addition, the \sa\xspace method is sensitive to the current draw value.
Battery behavior observations allow us to make the following assumption: the discharge curve can be separated in two areas, a pseudo-linear area (\ie before the \textit{nominal current} value) and a non-linear area (\ie after the \textit{nominal current} value). 
The border between these two areas is the \textit{nominal current draw} (\cf Sec.~\ref{sect:battery_desc}).
As a consequence, the \sa\xspace scheduling method changes the way it triggers battery's and components updates according to the instantaneous current draw value. 
When this value is under the \textit{nominal current} value of the modeled battery, the battery updates are triggered in the same way as if the \fed\xspace method were used. 
In the opposite case (the current draw is under the \textit{nominal current} value), these updates are triggered as if the \ffs\xspace scheduling method were used. 

On the one hand, this scheduling algorithm is able to enhance the accuracy of the estimation when it is necessary (\ie in the strongly non-linear part of the battery's discharge curve) and on the other hand, it is able to run the simulation faster when there is no need to (\ie in the ``almost'' linear part of the battery's discharge curve).

\subsection{Application example}
The chosen application example is a single component that is supplied by a battery. 
The functional behavior of this component is not discussed here since the meaningful information is its instantaneous current draw consumption. 
As a consequence, the power mode is the only information that is considered. 
The following mode sequence was arbitrarily chosen: 
\begin{itemize}
\item OFF $\rightarrow$ ON $\rightarrow$ POWER DOWN $\rightarrow$ ON.
\end{itemize}
The Figure~\ref{time} is a representation of each scheduling method applied to our example. 
%Each of the four graphs illustrates the results of its method applied to the example case. 
All the graph are time aligned making the difference between each scheduling method easier to understand.

%\begin{figure}
%\begin{center}
%\includegraphics[scale=0.45]{method_global.pdf}
%\caption{\label{time}
%\textbf{Application example of the scheduling methods:} 
%This figure is a time graph that shows the application of each scheduling method to our application example. 
%The \ffs\xspace method trigger battery update according to its sampling period \textit{T}. 
%The \sued\xspace method trigger as well the update of the battery each \textit{T} seconds but also when a component changes its operating state. 
%The \fed\xspace method only triggers battery updates on the components change. 
%The \sa\xspace method use periodic update when precision is required and event driven updates when less precision is needed.
%}
%\end{center}
%\end{figure}

\begin{figure}
%\begin{center}
\centering
\subfigure[Fixed Frequency Sampling]{
        \includegraphics[scale=0.45]{time_FFS.pdf}
        \label{time_ffs}
}
\subfigure[Self-Updating Event-Driven]{
        \includegraphics[scale=0.45]{time_FFS.pdf}
        \label{time_sued}
}
\subfigure[Fast Event-Driven]{
        \includegraphics[scale=0.45]{time_FFS.pdf}
        \label{time_fed}
}
\subfigure[Self Adaptative]{
        \includegraphics[scale=0.45]{time_FFS.pdf}
        \label{time_sa}
}

%\includegraphics[scale=0.45]{method_global.pdf}
\caption{\label{time}
\textbf{Application example of the scheduling methods:} 
This figure is a time graph that shows the application of each scheduling method to our application example. 
The \ffs\xspace method triggers battery update according to its sampling period \textit{T}. 
The \sued\xspace method triggers as well the update of the battery each \textit{T} seconds but also when a component changes its power mode. 
The \fed\xspace method only triggers battery updates on the components change. 
The \sa\xspace method uses periodic update when precision is required and event driven updates when less precision is needed.
}
%\end{center}
\end{figure}

Figure~\ref{time_ffs} is the graph that represent the \ffs\xspace method application. 
The updates of the battery and the component's current draw changes are asynchronous. 
Moreover, the supply voltage updates are delayed by one period in comparison with the current draw updates. 
In other words, the supply voltage value that is used by the component to compute its draw is the one that has been estimated the previous period by the battery model.
Figure~\ref{time_sued} represent the application of the \sued\xspace method. 
In contrast with the \ffs\xspace method, it appears that the battery's updates are synchronized with the current draw changes. 
The periodical update is also observable while the component is in LOW POWER mode. 
Alike the \ffs\xspace method, the supply voltage updates are also delayed.

The application of the \fed\xspace method is plotted in the graph Figure~\ref{time_fed}. 
%The fact that the battery updates happen only in synchronization with the component's power mode changes is highlighted. 
The graph highlight that the battery updates happen only in synchronization with the component's power mode changes.
The Figure~\ref{time_sa} illustrates the application of the \sa\xspace method. 
This method is sensitive to the current draw value in respect with the battery characteristics.
The current drawn in ON mode is assumed as being over the \textit{nominal current} value and the current drawn in the POWER DOWN mode is assumed as being under. 
Consequently, periodical updates are achieved when the components is in ON mode whereas there is no update while the component is in LOW POWER mode.

%\section{Modeling and integration in the Framework}
\subsection{Framework Integration}\label{implementation}
As mentioned previously, we chose to implement our scheduling method in an OMNeT++ framework~\cite{newcas}.
%As mentioned previously, a power aware simulation environment was chosen to implement the scheduling methods \cite{newcas}. 
%Actually, this environment is an OMNeT++'s framework that allows the wireless sensor node to be described with each of its electronic components. 
This environment allows a node to be described with every of its electronic components. 
Each component is described using two levels of description: a functional and a hardware one. 
Practically, the components are described using a functional model and a power model. 
Regarding the battery, a ``technical specification based'' model is provided.

The integration of our scheduling methods requires few modifications in the provided models. 
Theoretically, each power model should be modified according to the chosen scheduling method.
Fortunately, the simulated architecture use a DC/DC step-down converter to keep the supply voltage between the battery and the components steady. 
Therefore we consider the following assumption: the voltage do not change between the components' power model and the step down converter's output. 
%WD: to moove in the discussion
%Actually, even if some precision can be lost by doing this, this assumption is realistic since the modeled converter is not used in its limitations. 
Consequently to this assumption, the only models that requires to be modified are the battery model and the converter model.

To ensure reliable simulation results, mechanisms of the modified components were isolated into functions that takes every necessary information as parameters. 
Even if it needed additional formalizing and coding efforts, this approach allows us to described the models independently from the scheduling method. 
%The way and the sequence order in which the function are called determined the scheduling method. 

\section{Modelling and simulation configuration}
\subsection{Battery Modelling}
The battery model that was used in the simulation is a model of the CR2032 battery from Panasonic~\cite{cr2032}. 
The instantaneous current draw is considered to estimate the residual capacity and thus, predict the battery lifetime according to the technical specifications. %(cf. Fig.\ref{cr2032}). 
%\begin{figure} 
%\begin{center}
%\includegraphics[scale=1.1]{cr2032_capacity_vs_load_resistance.pdf}
%\caption{\label{cr2032}Panasonic CR2032: \textit{capacity vs. load resistance characteristic} \cite{cr2032} }
%\end{center}
%\end{figure}
The impact of the temperature variation on the battery were not considered in the following simulation case. 
As a consequence, the battery's \textit{effective capacity} varies only with the instantaneous current draw. 
\begin{figure}
\begin{center}
\includegraphics[scale=0.40]{eq_current_plot.pdf}
\caption{\label{eq_current}
\textbf{Equivalent and instantaneous current draw estimations:} 
This graph show the difference between the instantaneous current drawn by the components (shorten to \textit{Inst.}, \cf $i(t)$ in Eq.~\ref{ieq}) and the current that is actually seen by the battery (shorten to \textit{Eq.}, \cf $i_{eq}$ in Eq.~\ref{ieq}).
}
\end{center}
\end{figure}

In this model, the capacity of the battery is considered as fixed. 
Therefore, to model the impact of the instantaneous current draw on the \textit{relative capacity}, the equivalent current draw $i_{eq}(t)$ was considered. 
It has been defined using the following equation:
\begin{equation}\label{ieq}
i_{eq}(t) = \frac{C_{nominal}}{C_{relative}(i(t))} \times i(t)
\end{equation}
Where $C_{nominal}$ is the \textit{nominal capacity} and $C_{relative}$ is the \textit{relative capacity} (according to the instantaneous current draw), both expressed in mAh. 
The $i(t)$ is the instantaneous current expressed in mA. 
The factor between $C_{nominal}$ and $C_{relative}$ is called the \textit{overdraw factor}. 
Therefore, the equivalent current draw is expressed as a function of the present instantaneous current draw as depicted in the chart Figure~\ref{eq_current}. 
This graph was plotted using a current draw ramp directly plugged in the battery model. 
This battery modeling technique has the advantage of modeling both the \textit{effective capacity} and the \textit{relaxation} effects as well.
%Even if this abstraction of the real battery behavior is not perfect, it has the advantage of modeling both the \textit{effective capacity} and the \textit{relaxation} effects as well.

The equation that is used to estimate the battery's residual $R$ at the $t+\Delta t$ time is the following one:
\begin{equation}
R(t+\Delta t) = R(t) -  i_{eq}(t) \times \frac{\Delta t}{3600}
\end{equation}
Where $R(t)$ is the previous residual value in mAh, $i_{eq}(t)$ is the \textit{equivalent current draw} (\cf Eq.\ref{ieq}) in mA, $\Delta t$ the time while the $i_{eq}$ current was drawn expressed in second. 
Finally, the $3600$ value stands for the conversion of $\Delta t$ in hours.

%\section{Simulation}
\subsection{Simulated Architecture}
The platform used as modeling base was a prototype under development.
It is composed of a NTC temperature sensor, a Texas Instruments (TI) MSP430FR5739 micro-controller~\cite{msp430_fr}, a TI CC2520 radio frequency transceiver~\cite{cc2520} and a TI TPS62122 step-down DC/DC converter~\cite{tps62122}. 
The power supply is handled by 4 CR2032 batteries~\cite{cr2032} that are assembled in serial. 
%The figure \ref{omnet} is a screen shot of the modelled node into the simulation environment.
%\begin{figure}
%\begin{center}
%\includegraphics[scale=0.55]{node_omnet.jpg}
%\caption{\label{omnet}Description of the node's architecture inside the WSN framework}
%\end{center}
%\end{figure}
The measurements that were used to build the MCU and the transceiver models are reported in Table~\ref{msp_meas}. 
These measurements were made using a NI PXI-4071 ampere-meter integrated in a NI PXIe-1075 rack from National Instruments. 
The used precision was seven and a half digits, the maximum precision of the device.
The measurements were achieved using a temperature regulated chamber from Binder. 
The MCU firmware that was used to achieve this was the application that is embedded in the sensing node. 
Consumption measurements of the MSP430 are not restricted to the core but include also the consumption of the whole chip.

\begin{table}[h]
\centering
\subtable[MSP430]{
        \begin{tabular}{|c||c|c|c|c|}
                \hline
                \textit{Mode} & Active & ADC+LPM4 & LPM4 \\ 
                \hline
                Inst. current & 0.813mA & 0.326mA & 0.226mA \\
                \hline
        \end{tabular}
}
%\begin{tabular}{cccccccc}
 %& & & & & & &\\
%\end{tabular}
\subtable[CC2520]{
        \begin{tabular}{|c||c|c|c|c|c|c|}
                \hline
                \textit{Mode} & XOSC Off & Idle & RX & RX LP & TX-18dBm \\
                \hline
                Inst. current & 0.178mA & 1.776mA & 22.48mA & 18.79mA &  16.63mA\\
                \hline
        \end{tabular}
}
\smallskip
\caption{\label{msp_meas}{\bf Experimental measurements of the current draw}}
\end{table}

Regarding the functional behavior, the application that is modeled is a typical temperature measuring scenario. 
The network is organized in a star topology and the IEEE 802.15.4 protocol is used by the node to communicate. 
The sensing node behavior is the following: 
\begin{enumerate}
\item The node start to listen the channel to seek for a broadcast frame that comes from the central node;
\item Once it received the frame with the same PAN-ID and the expected source address, it acknowledge the subscription;
\item Every second it wakes up, takes a measure of the temperature and send it to the central node before going back to sleep.
\end{enumerate}
Each sensor has a time slot that is computed according to its own address, at the beginning of the run. 
The central node is periodically broadcasting its subscription frame an turns into reception mode right after. 
Therefore, its power consumption is high in comparison with the sensor node. 
In the simulation, it is considered as being supplied by an ideal power source with infinite energy.

\section{Results}
All along this section, several simulation cases and their results are presented. 
The sampling period \textit{T} of the \ffs, the \sued\xspace and the \sa\xspace (\cf Sect.~\ref{sec:schedul_meth}) scheduling methods were set to the same value ($50$us). 
This choice is motivated by the simulation performances (\cf Sect.~\ref{sim_perfs}).
The computer that was used to obtain the results is based on a Core i7 860 @ 2.80GHz processor from Intel and 8 gigabytes of RAM. 
Ubuntu LTS 12.04 was used as operating system. 
The OMNeT++ version was the 4.3. 
Simulator was configured to use only one core over eight in order to have no hardware acceleration that could biased the performance results.
%Each simulation case was run at least 10 times in order to verify the reliability of the obtained results. 

\subsection{Power consumption estimation}
The power consumption estimation results were obtained by simulating four instances of the same node for one hour of simulated time. 
Each node implements a different method to schedule the power transaction between the batteries and the components. 
As a reference, another simulation was run within the same conditions but using ideal battery models instead of CR2032 models. 
The battery's residual value results for both simulations are presented in Table~\ref{residual_results}. 

\begin{table}[h]
\centering
\subtable[Ideal battery model, \textit{T}=50us]{
        \begin{tabular}{|c||c|c|c|c|}
        \hline
                & FFS & SUED & FED & SA\\
        %\hline
        %\multicolumn{5}{|c|}{Nodes with Ideal model (\textit{T}=50us)}  \\
        \hline
        Residual (mAh)&$\textbf{219.9273}$&$\textbf{219.9273}$&$\textbf{219.9273}$&$\textbf{219.9273}$\\
        %Consumed Cap. (mAh)&$0.0727$&$0.0727$&$0.0727$&$0.0727$\\
        Av. $i_{eq}(t)$ (uA)&$72.7$&$72.7$&$72.7$&$72.7$\\
        %Av. voltage (V)&$12.00$&$12.00$&$12.00$&$12.00$\\
        \hline
        \end{tabular}
        }
\subtable[CR2032 battery model, \textit{T}=50us]{
        \begin{tabular}{|c||c|c|c|c|}
        \hline
        & FFS & SUED & FED & SA\\
        %\hline
        %\multicolumn{5}{|c|}{Nodes with CR2032 model (\textit{T}=50us)}  \\
        \hline
        Residual (mAh)&$\textbf{219.9249}$&$\textbf{219.9248}$&$\textbf{219.9167}$&$\textbf{219.9137}$\\
        %Consumed Cap. (mAh)& $0.0751$& $0.0752$& $0.0833$& $0.0863$\\
        Av. $i_{eq}(t)$ (uA)& $75.1$& $75.2$& $83.3$& $86.3$\\
        \hline
\end{tabular}
}
\smallskip
\caption{\label{residual_results}
{\bf Battery's residual estimation results:}
{\textnormal{
The battery residual estimation and the average equivalent current ($i_{eq}(t)$, \cf Eq.~\ref{ieq}) do not change for the ideal battery model regardless of the scheduling method. 
In contrast, they are different for each scheduling method using the technical specification based battery model}
}
}
\end{table}

%\begin{table}[h]
%\centering
%\caption{\label{consumption_result}Power consumption estimation}
%\begin{tabular}{|c||c|c|c|c|}
%\hline
%\multicolumn{5}{|c|}{Simulated time = 60 minutes}  \\
%\hline
% & FFS & SUED & FED & SA\\
%\hline
%\hline
%\multicolumn{5}{|c|}{Power Consumption: Ideal model}  \\
%\hline
%Residual (mAh) & $\textbf{219.9273}$ & $\textbf{219.9273}$ & $\textbf{219.9273}$ & $\textbf{219.9273}$\\
%Consumed C. (mAh) &$0.0727$&$0.0727$&$0.0727$& $0.0727$\\
%Av. eq. current (uA) &$72.7$&$72.7$&$72.7$&$72.7$\\
%Av. voltage (V)&$12.00$&$12.00$&$12.00$&$12.00$\\
%\hline
%\hline
%\multicolumn{5}{|c|}{Power Consumption: CR2032 model}  \\
%\hline
%Residual (mAh) & $\textbf{219.9249}$& $\textbf{219.9248}$ & $\textbf{219.9167}$& $\textbf{219.9137}$\\
%Consumed Energy (mAh) & $0.0751$& $0.0752$& $0.0833$& $0.0863$\\
%\hline
%Max current (mA) & $3.99$ & $3.99$& $3.92$& $3.99$\\
%Min current (mA) & $0.073$ & $0.073$& $0.071$& $0.071$\\
%\hline
%Max eq. current (mA) & $7.359$& $7.359$& $7.033$& $7.359$\\
%Min eq. current (mA) & $0.70$& $0.073$& $0.071$& $0.071$\\
%Av. eq. current (uA) & $75.1$& $75.2$& $83.3$& $86.3$\\
%\hline
%Max voltage (V) & $12.0$& $12.0$& $12.0$& $12.0$\\
%Min voltage (V) & $9.98$& $9.98$& $10.67$& $9.98$\\
%Av. voltage (V) & $10.62$& $10.54$& $11.40$& $10.70$\\
%\hline
%\end{tabular}
%\end{table}

The first important observation is the fact that scheduling method do not influence the lifetime estimation in the case of ideal battery modeling (\cf Tab.~\ref{residual_results}(a)). 
Actually, the four nodes reach the end of the simulation with the same residual value ($219.9273$ mAh), the same current draw and the same voltage value. 
In contrast, the results obtained by the node that were equipped with CR2032 models are not equal (\cf Tab.~\ref{residual_results}(b)). 
These variations in the power consumption estimations highlight the fact that scheduling method do influence the residual estimation. 
Consequently, the node lifetime estimation is also influenced even if each battery model and each component model is the same.

\begin{table}[h]
\begin{center}
\begin{tabular}{|c||c|c|c|c|}
\hline
 & FFS & SUED & FED & SA\\
\hline
Max $i(t)$ (mA) & $3.99$ & $3.99$& $3.92$& $3.99$\\
Min $i(t)$ (mA) & $0.073$ & $0.073$& $0.071$& $0.071$\\
\hline
Max $i_{eq}(t)$ (mA) & $7.359$& $7.359$& $7.033$& $7.359$\\
Min $i_{eq}(t)$ (mA) & $0.70$& $0.073$& $0.071$& $0.071$\\
%\hline
%Av. eq. current (uA) & $75.1$& $75.2$& $83.3$& $86.3$\\
\hline
\end{tabular}
\end{center}
\smallskip
\caption{\label{current_results}{\bf Instantaneous $i(t)$ and equivalent current $i_{eq}(t)$ draw estimation (cf., Eq.~\ref{ieq}):} \textnormal{The estimated values are slightly different for each scheduling method.}}
\end{table}

Focusing on the detailed results, the residual estimation that is obtained using the \ffs\xspace method is the highest one with $219.9429$ mAh. 
Firstly, the current draw is integrated over the \textit{T} period. 
This is comparable to a \textit{low pass filter} that cuts the edges of the current draw spikes. 
Secondly, the supply voltage value is the one that has been computed using the previous current draw value. 
The impact of the voltage drifts are consequently lowered. 
The \sued\xspace method suffers from the same observations, except for the spike transition thanks to the synchronized current updates. 
This explains why the average \textit{equivalent current draw} (\cf Eq.~\ref{ieq}) value that is obtained using the \sued\xspace scheduling method is slightly more important than the \ffs\xspace one ($75.2$uA $>$ $75.1$uA). 
To achieve better results with these scheduling methods, the Shannon theorem should be observed. 
In other word, the sampling period should be at least twice short as the shorter power mode changing of the system. 
In the present case, the shorter period is around 5us. 
Therefore a 2.5us period is the minimum period length regarding the accuracy and the precision of the estimation. 
Unfortunately, using such a small period results in an extremely slow simulation as presented in the next section. 

%Another fact that could explain that the result of the sampling based method are not the same as the \fex\xspace and \sa\xspace methods is the numeric precision. 
Another noticeable result is the difference in the residual estimated with \ffs\xspace and \sued\xspace methods in comparison with \fed\xspace and \sa\xspace methods. 
These variations could be explained by the numeric precision. 
Since there is more computation using the CR2032 model than the ideal battery model, precision could have been lost in every intermediary value computation ending to a under-estimated power consumption. 
Actually, this phenomena is partially observable considering the current draw and the equivalent current draw estimation (\cf Tab.~\ref{current_results}). 

\begin{table}[h]
\centering
\begin{tabular}{|c||c|c|c|c|}
        \hline
        & FFS & SUED & FED & SA\\
        \hline
        Max voltage (V) & $12.0$& $12.0$& $12.0$& $12.0$\\
        Min voltage (V) & $9.98$& $9.98$& $10.67$& $9.98$\\
        %Av. voltage (V) & $10.62$& $10.54$& $11.40$& $10.70$\\
        \hline
\end{tabular}
\smallskip
\caption{\label{voltage_results}
{{\bf Battery supply voltage estimation:}
\textnormal{The estimated supply voltage values are the same except for the FED method.}
}
}
\end{table}

Focusing on the event-driven based scheduling method \fed, the obtained residual estimation is lower than the \ffs\xspace and the \sued\xspace method but higher than the \sa\xspace method. 
This is a result of the event driven-like algorithm. 
The current drawn by the components is updated immediately when one of them changes its power mode. 
Once a new current value draw has been transmitted to the battery, its residual is computed and its voltage value is updated but there is no further updates from both the components and the battery until a components change its current draw again. 
This explain also why the average equivalent current obtained thanks to the \sa\xspace method was higher with $86.3$uA (\cf Tab.~\ref{residual_results}). 
The observation of the current draw and the equivalent current draw in the Table~\ref{current_results} are confirming this assumption. 
Actually, even if every battery has to supply the same current both the maximal current and the maximal equivalent current estimated using the \fed\xspace method are lower than the other methods.

The sampling mechanism of the \sa\xspace method allows the battery model to react almost instantly to every current draw variation. 
Finally, while the average voltage obtained using the \ffs\xspace, \sued\xspace and \sa\xspace methods are quite close, the supply voltage value obtained using the \fed\xspace method is higher (\cf Tab.~\ref{voltage_results}). 
This highlights once again the fact that updates are driven by the components' power mode changes.

\subsection{Simulation performance} \label{sim_perfs}
The simulation performance results were obtained by running the nodes for five minutes of CPU time (300 seconds). 
Two series of simulation were conducted. 
The first one consist of running one single node and its base station at a time. 
Each scheduling method is therefore evaluated on its own. 
The second one consist of the same principle but running a network of five identical nodes. 
The main results are presented in Table~\ref{residual_results}. 
In this table there is several abbreviation: 
\begin{itemize}
\item the simulated time: \textit{\textbf{Sim.time}}
\item the average simulated sec. per sec. ratio: \textit{\textbf{Av.Sim.s/s}}
\item the number of simulated events: \textit{\textbf{N.ev.}}
\item the average number of event per sec.: \textit{\textbf{Ev/s}}
\end{itemize}


The time indications give basic idea on how much of CPU time it would take if the simulation has to reach a specific time. 
The event indications give idea about the load of the simulation kernel. 
It allows to figure out the raw performances and eventually deduce the impact of porting the scheduling methods to another simulation environment.
\begin{table}[h]
\centering
\begin{tabular}{|c||c|c|c|c|}
\hline
\multicolumn{5}{|c|}{CPU time = 5min (300 s)}  \\
\hline
 & FFS & SUED & FED & SA\\
\hline
\hline
\multicolumn{5}{|c|}{1 Node}  \\
\hline
Av.Sim.s\slash s & \textbf{2.695} & \textbf{5.474} & \textbf{6699} & \textbf{3342}\\
\hline
Sim.time & 13min:28s& 27min:22s & 23d:6h & 11d:22h\\
N.ev. &$48\times10^6$&$98\times10^6$&$80\times10^6$&$82\times10^6$ \\
Ev\slash s &$1.6\times10^5$&$3.2\times10^5$&$2.7\times10^5$&$2.7\times10^5$ \\
\hline
\multicolumn{5}{|c|}{5 Nodes}  \\
\hline
Av.Sim.s\slash s & \textbf{0.576} & \textbf{1.218} & \textbf{1330} & \textbf{713.5}\\
\hline
Sim.time & {2min:52s}&{6min:5s}& {4d:14h}& {2d:11h}\\
N.ev. &$51.8\times10^6$&$109.6\times10^6$&$86.6\times10^6$&$89.3\times10^6$ \\
Ev\slash s &$1.7\times10^5$&$3.6\times10^5$&$2.8\times10^5$&$2.9\times10^5$ \\
\hline
\end{tabular}
\smallskip
\caption{\label{perf_table}
{{\bf Simulation performance (\textit{T}=50us)}:
\textnormal{This table summarize the performances of each method. The FFS and SUED scheduling methods are the slowest and the less scalable methods. In contrast, the FED and the SA scheduling methods allow to simulate in a faster way larger networks}
}
}
\end{table}

Regarding the simulated time for a single node, the results are quite clear. 
The \ffs\xspace and the \sued\xspace method reach $13$ and $27$ minutes respectively. 
In contrast, the \sa\xspace method is able to simulate almost $12$ days in $5$ minutes of CPU time. 
The \fed\xspace method outperforms by reaching $23$ days of simulated time and almost $2$h simulated per second.
The results of the 5 nodes are following the same trends. 
The average simulated second per second rate of the \ffs\xspace method decrease to $0.57$ sim.s/s which is quite slow since its under the ``unity rate'' of $1$ sim.s/s. 
The \sued\xspace method is slightly faster with 1.2 sim.s/s rate that enables it to reach $6$ minutes of simulated time in $5$ minutes. 
Finally, the best performances were obtained using the \sa\xspace and the \fed\xspace method with respectively 2 days and 4 days of simulated time.

As a consequence, the \ffs\xspace and the \sued\xspace method are not considered in the following experiments. 
This choice is motivated by the fact that these two methods are not suitable for long-time simulation (several months) nor for networks that implies several nodes.

\subsection{Node lifetime estimation}
The node lifetime estimation results were obtained by running one single node and the central node until the first voltage drops that makes the node reset. 
This scenario focuses on the real node lifetime as it has been defined in the beginning of this article. 
If, for any reason, there is a voltage drop that makes the node reset, there is high chances that it happens again and again until the complete depletion of the battery. 
Therefore the node can be considered as dead or not reliable enough from the point of view of the network.

As mentioned before, only the \fed\xspace and the \sa\xspace method were considered in this experiments. 
Making the same run with the \ffs\xspace method would have require approximately 1 month of continuous run. 
The theoretical lifetime $L_{TH}$ of the node obtained with an ideal battery model is around 4 months ($L_{TH} \approx 220\slash 0.0727 \approx$ 4.2 months). 
This estimation implicitly assumes that the battery is able to supply the node until its total depletion, which is not the case. 
The node lifetime estimation results are presented in the Table~\ref{sim_table_2}. 
First analysis of these results reveals that estimation obtained by the \fed\xspace and the \sa\xspace methods are significantly different. 
The \fed\xspace node lasted three months and twelve days while the \sa\xspace node lasted three months and one day. 
This represent a difference of $11.7$\% between the two methods and a difference of $20.8$\% (\fed) and $35.0$\% (\sa) between each method's lifetime estimation and $L_{TH}$.

\begin{table}[h]
\centering
\begin{tabular}{|c||c|c|}
\hline
 & FED & SA\\
\hline
\hline
\multicolumn{3}{|c|}{Node lifetime (\textit{T}=50us)}  \\
\hline
Lifetime &  3m:12d:7h:29min:0s & 3m:1d:8h:50min:29s\\
\hline
Residual (mAh) & $0.0176$ & $\textbf{16.8062}$\\
\hline
Simulation time &  22min:25s & 38min:18s\\
Av.Sim.s\slash s &  $6700$ & $3510$\\.
N.ev. &$3.6\times10^8$ &$64\times10^8$ \\
Ev\slash s &$2.7\times10^5$ & $2.8\times10^5$\\
\hline
%Gain Factor  & $98.5$ & $1.35$\\
%\hline
\end{tabular}
\smallskip
\caption{\label{sim_table_2}
{\bf Node lifetime estimation performance}:
\textnormal{The difference of 11.7\% between the two methods highlight the fact that scheduling methods do influence the lifetime estimation.}
}
\end{table}

A closer observation of the residual values at the end of the simulation is highlighting the fact that the \sa\xspace node stops operate properly before the \fed\xspace node. 
It appears that the battery's voltages drift are not well modeled with the \fed\xspace method since the likelihood of the fact that the battery lasts until almost complete depletion ($0.0176$ mAh) is low. 
Considering the technical specification, the battery should not be able to handle the current spike of a RF frame transmission at this depletion level. 
Consequently, the results obtained by the \sa\xspace method are more realistic. 
Unfortunately, there is no means to measure the remaining capacity in a real battery to have a comparison point. 
Further experiments about battery discharge in this particular application case will be conducted in order to experimentally validate this hypothesis. 

\subsection{Scalability}
The last exposed experiment was conducted to evaluate the scalability of the \fed\xspace and the \sa\xspace scheduling methods. 
The simulated time was set to $24$h hours. 
Each simulation contained a complete network with $10$ to $250$ nodes and a central station. 
The obtained result are presented in the table \ref{sim_table_3}. 

\begin{table}[h]
\centering
\begin{tabular}{|c||c|c|}
\hline
\multicolumn{3}{|c|}{Simulated time = 24h (\textit{T}=50us)}\\
\hline
 &FED&SA\\
\hline
10 nodes & $2$min $11$s & $4$min $6$s \\
%\cdashline{2-3}
50 nodes & $13$min $57$s & $24$min $3$s \\
%\cdashline{2-3}
100 nodes & $36$min $17$s & $56$min $52$s\\
%\cdashline{2-3}
250 nodes & $2$h $58$min & $3$h $45$min \\
\hline
\end{tabular}
\smallskip
\caption{\label{sim_table_3}
{\bf Scalability comparison: simulation time for 10 to 250 nodes}:
\textnormal{This table is a comparison of the time that is required for each methods to reach 24h of simulated time considering various network size. The results show clearly that the SA method needs almost twice the time of the FED method to achieve it. However, when the size of the network increase, this factor decreases.}
}
\end{table}

First observation that can be made is the fact the evolution of the time as a function of the number of the nodes is not linear. 
Actually, simulating 250 nodes should be 25 times longer than simulating 10 nodes. 
Simulating 10 nodes with the \fed\xspace method takes 2.18 minutes but simulating 250 node takes almost three hours instead of 54 minutes as it could be expected. 
This is explained by the fact that each additional node adds a significant traffic load. 
A second observation is the fact that when network are small (\eg less than 50 nodes) the \fed\xspace method is roughly two time faster than the \sa\xspace method. 
This difference seems to decrease when the size of the network increase. 
With a 250 nodes network, using the \sa\xspace method takes only 26\% more time than the \fed\xspace method. 

More generally, these results are highlighting the high scalability of the \fed\xspace method in comparison with the \sa\xspace method that is slower.

\section{Conclusion}
In this work, we have introduced four scheduling methods to address the specific issue of network lifetime estimation when a non-ideal battery model is used. 
Our first experiments revealed that the scheduling methods do have an impact on battery's lifetime estimations and thus on the node lifetime prediction. 
As expected, our results are showing that the sampling based methods are not suitable for large scale simulation whereas it seems to be the most intuitive way to reach an accurate and precise estimation. 
In contrast, event-driven based method is the fastest scheduling method whereas it appears to lead to inaccurate results. 
Finally, the compromise between the event-driven and the periodical scheduling methods was found as the \sa\xspace method which enables a fast and accurate network lifetime estimation. 

Our future work will address the comparison of the lifetime prediction and the real measurement thanks to a WSN testbed oriented towards network lifetime characterization. 
The technical based proposed model will be compared to real measurement of the battery behavior. 
Finally, we will accentuate our efforts on the scheduling methods optimization with the goal of very-large scale and reliable network lifetime estimation.

% use section* for acknowledgement
\section*{Acknowledgment}
%Liam McNamara (SICS), Beshr Al Nahas (SICS).


% Can use something like this to put references on a page
% by themselves when using endfloat and the captionsoff option.
\ifCLASSOPTIONcaptionsoff
  \newpage
\fi



% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
\bibliographystyle{IEEEtran}
\bibliography{bib}

% biography section
% 
% If you have an EPS/PDF photo (graphicx package needed) extra braces are
% needed around the contents of the optional argument to biography to prevent
% the LaTeX parser from getting confused when it sees the complicated
% \includegraphics command within an optional argument. (You could create
% your own custom macro containing the \includegraphics command to make things
% simpler here.)
%\begin{biography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{mshell}}]{Michael Shell}
% or if you just want to reserve a space for a photo:

\begin{IEEEbiography}{Wilfried Dron}
Biography text here.
\end{IEEEbiography}

% if you will not have a photo at all:
\begin{IEEEbiographynophoto}{Khalil Hachicha}
Biography text here.
\end{IEEEbiographynophoto}

% insert where needed to balance the two columns on the last page with
% biographies
%\newpage

\begin{IEEEbiographynophoto}{Patrick Garda}
Biography text here.
\end{IEEEbiographynophoto}

% You can push biographies down or up by placing
% a \vfill before or after them. The appropriate
% use of \vfill depends on what kind of text is
% on the last page and whether or not the columns
% are being equalized.

%\vfill

% Can be used to pull up biographies so that the bottom of the last one
% is flush with the other column.
%\enlargethispage{-5in}



% that's all folks
\end{document}