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

Last change on this file was 134, checked in by dron, 11 years ago
File size: 79.9 KB
Line 
1
2%% bare_jrnl.tex
3%% V1.3
4%% 2007/01/11
5%% by Michael Shell
6%% see http://www.michaelshell.org/
7%% for current contact information.
8%%
9%% This is a skeleton file demonstrating the use of IEEEtran.cls
10%% (requires IEEEtran.cls version 1.7 or later) with an IEEE journal paper.
11%%
12%% Support sites:
13%% http://www.michaelshell.org/tex/ieeetran/
14%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
15%% and
16%% http://www.ieee.org/
17
18
19
20% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
21% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
22% *** with production work. IEEE's font choices can trigger bugs that do  ***
23% *** not appear when using other class files.                            ***
24% The testflow support page is at:
25% http://www.michaelshell.org/tex/testflow/
26
27
28%%*************************************************************************
29%% Legal Notice:
30%% This code is offered as-is without any warranty either expressed or
31%% implied; without even the implied warranty of MERCHANTABILITY or
32%% FITNESS FOR A PARTICULAR PURPOSE!
33%% User assumes all risk.
34%% In no event shall IEEE or any contributor to this code be liable for
35%% any damages or losses, including, but not limited to, incidental,
36%% consequential, or any other damages, resulting from the use or misuse
37%% of any information contained here.
38%%
39%% All comments are the opinions of their respective authors and are not
40%% necessarily endorsed by the IEEE.
41%%
42%% This work is distributed under the LaTeX Project Public License (LPPL)
43%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
44%% distributed and modified. A copy of the LPPL, version 1.3, is included
45%% in the base LaTeX documentation of all distributions of LaTeX released
46%% 2003/12/01 or later.
47%% Retain all contribution notices and credits.
48%% ** Modified files should be clearly indicated as such, including  **
49%% ** renaming them and changing author support contact information. **
50%%
51%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
52%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
53%%*************************************************************************
54
55% Note that the a4paper option is mainly intended so that authors in
56% countries using A4 can easily print to A4 and see how their papers will
57% look in print - the typesetting of the document will not typically be
58% affected with changes in paper size (but the bottom and side margins will).
59% Use the testflow package mentioned above to verify correct handling of
60% both paper sizes by the user's LaTeX system.
61%
62% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
63% should be used if it is desired that the figures are to be displayed in
64% draft mode.
65%
66\documentclass[journal]{IEEEtran}
67%
68% If IEEEtran.cls has not been installed into the LaTeX system files,
69% manually specify the path to it like:
70% \documentclass[journal]{../sty/IEEEtran}
71
72
73
74
75
76% Some very useful LaTeX packages include:
77% (uncomment the ones you want to load)
78
79
80% *** MISC UTILITY PACKAGES ***
81%
82%\usepackage{ifpdf}
83% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
84% compilation based on whether the output is pdf or dvi.
85% usage:
86% \ifpdf
87%   % pdf code
88% \else
89%   % dvi code
90% \fi
91% The latest version of ifpdf.sty can be obtained from:
92% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
93% Also, note that IEEEtran.cls V1.7 and later provides a builtin
94% \ifCLASSINFOpdf conditional that works the same way.
95% When switching from latex to pdflatex and vice-versa, the compiler may
96% have to be run twice to clear warning/error messages.
97
98
99
100
101
102
103% *** CITATION PACKAGES ***
104%
105\usepackage{cite}
106% cite.sty was written by Donald Arseneau
107% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
108% \cite{} output to follow that of IEEE. Loading the cite package will
109% result in citation numbers being automatically sorted and properly
110% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
111% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
112% \cite will automatically add leading space, if needed. Use cite.sty's
113% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
114% cite.sty is already installed on most LaTeX systems. Be sure and use
115% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
116% not currently provide for hyperlinked citations.
117% The latest version can be obtained at:
118% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
119% The documentation is contained in the cite.sty file itself.
120
121
122
123
124
125
126% *** GRAPHICS RELATED PACKAGES ***
127%
128\ifCLASSINFOpdf
129  % \usepackage[pdftex]{graphicx}
130  % declare the path(s) where your graphic files are
131  % \graphicspath{{../pdf/}{../jpeg/}}
132  % and their extensions so you won't have to specify these with
133  % every instance of \includegraphics
134  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
135\else
136  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
137  % will default to the driver specified in the system graphics.cfg if no
138  % driver is specified.
139  % \usepackage[dvips]{graphicx}
140  % declare the path(s) where your graphic files are
141  % \graphicspath{{../eps/}}
142  % and their extensions so you won't have to specify these with
143  % every instance of \includegraphics
144  % \DeclareGraphicsExtensions{.eps}
145\fi
146% graphicx was written by David Carlisle and Sebastian Rahtz. It is
147% required if you want graphics, photos, etc. graphicx.sty is already
148% installed on most LaTeX systems. The latest version and documentation can
149% be obtained at:
150% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
151% Another good source of documentation is "Using Imported Graphics in
152% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
153% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
154%
155% latex, and pdflatex in dvi mode, support graphics in encapsulated
156% postscript (.eps) format. pdflatex in pdf mode supports graphics
157% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
158% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
159% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
160% which can result in "jaggedy"/blurry rendering of lines and letters as
161% well as large increases in file sizes.
162%
163% You can find documentation about the pdfTeX application at:
164% http://www.tug.org/applications/pdftex
165
166
167
168
169
170% *** MATH PACKAGES ***
171%
172%\usepackage[cmex10]{amsmath}
173% A popular package from the American Mathematical Society that provides
174% many useful and powerful commands for dealing with mathematics. If using
175% it, be sure to load this package with the cmex10 option to ensure that
176% only type 1 fonts will utilized at all point sizes. Without this option,
177% it is possible that some math symbols, particularly those within
178% footnotes, will be rendered in bitmap form which will result in a
179% document that can not be IEEE Xplore compliant!
180%
181% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
182% thus preventing page breaks from occurring within multiline equations. Use:
183%\interdisplaylinepenalty=2500
184% after loading amsmath to restore such page breaks as IEEEtran.cls normally
185% does. amsmath.sty is already installed on most LaTeX systems. The latest
186% version and documentation can be obtained at:
187% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/
188
189
190
191
192
193% *** SPECIALIZED LIST PACKAGES ***
194%
195%\usepackage{algorithmic}
196% algorithmic.sty was written by Peter Williams and Rogerio Brito.
197% This package provides an algorithmic environment fo describing algorithms.
198% You can use the algorithmic environment in-text or within a figure
199% environment to provide for a floating algorithm. Do NOT use the algorithm
200% floating environment provided by algorithm.sty (by the same authors) or
201% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
202% algorithm float types and packages that provide these will not provide
203% correct IEEE style captions. The latest version and documentation of
204% algorithmic.sty can be obtained at:
205% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
206% There is also a support site at:
207% http://algorithms.berlios.de/index.html
208% Also of interest may be the (relatively newer and more customizable)
209% algorithmicx.sty package by Szasz Janos:
210% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/
211
212
213
214
215% *** ALIGNMENT PACKAGES ***
216%
217%\usepackage{array}
218% Frank Mittelbach's and David Carlisle's array.sty patches and improves
219% the standard LaTeX2e array and tabular environments to provide better
220% appearance and additional user controls. As the default LaTeX2e table
221% generation code is lacking to the point of almost being broken with
222% respect to the quality of the end results, all users are strongly
223% advised to use an enhanced (at the very least that provided by array.sty)
224% set of table tools. array.sty is already installed on most systems. The
225% latest version and documentation can be obtained at:
226% http://www.ctan.org/tex-archive/macros/latex/required/tools/
227
228
229%\usepackage{mdwmath}
230%\usepackage{mdwtab}
231% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
232% especially mdwmath.sty and mdwtab.sty which are used to format equations
233% and tables, respectively. The MDWtools set is already installed on most
234% LaTeX systems. The lastest version and documentation is available at:
235% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/
236
237
238% IEEEtran contains the IEEEeqnarray family of commands that can be used to
239% generate multiline equations as well as matrices, tables, etc., of high
240% quality.
241
242
243%\usepackage{eqparbox}
244% Also of notable interest is Scott Pakin's eqparbox package for creating
245% (automatically sized) equal width boxes - aka "natural width parboxes".
246% Available at:
247% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/
248
249
250
251
252
253% *** SUBFIGURE PACKAGES ***
254%\usepackage[tight,footnotesize]{subfigure}
255% subfigure.sty was written by Steven Douglas Cochran. This package makes it
256% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
257% work, it is a good idea to load it with the tight package option to reduce
258% the amount of white space around the subfigures. subfigure.sty is already
259% installed on most LaTeX systems. The latest version and documentation can
260% be obtained at:
261% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
262% subfigure.sty has been superceeded by subfig.sty.
263
264
265
266%\usepackage[caption=false]{caption}
267%\usepackage[font=footnotesize]{subfig}
268% subfig.sty, also written by Steven Douglas Cochran, is the modern
269% replacement for subfigure.sty. However, subfig.sty requires and
270% automatically loads Axel Sommerfeldt's caption.sty which will override
271% IEEEtran.cls handling of captions and this will result in nonIEEE style
272% figure/table captions. To prevent this problem, be sure and preload
273% caption.sty with its "caption=false" package option. This is will preserve
274% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later
275% (recommended due to many improvements over 1.2) of subfig.sty supports
276% the caption=false option directly:
277%\usepackage[caption=false,font=footnotesize]{subfig}
278%
279% The latest version and documentation can be obtained at:
280% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
281% The latest version and documentation of caption.sty can be obtained at:
282% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/
283
284
285
286
287% *** FLOAT PACKAGES ***
288%
289%\usepackage{fixltx2e}
290% fixltx2e, the successor to the earlier fix2col.sty, was written by
291% Frank Mittelbach and David Carlisle. This package corrects a few problems
292% in the LaTeX2e kernel, the most notable of which is that in current
293% LaTeX2e releases, the ordering of single and double column floats is not
294% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
295% single column figure to be placed prior to an earlier double column
296% figure. The latest version and documentation can be found at:
297% http://www.ctan.org/tex-archive/macros/latex/base/
298
299
300
301%\usepackage{stfloats}
302% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
303% the ability to do double column floats at the bottom of the page as well
304% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
305% LaTeX2e). It also provides a command:
306%\fnbelowfloat
307% to enable the placement of footnotes below bottom floats (the standard
308% LaTeX2e kernel puts them above bottom floats). This is an invasive package
309% which rewrites many portions of the LaTeX2e float routines. It may not work
310% with other packages that modify the LaTeX2e float routines. The latest
311% version and documentation can be obtained at:
312% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
313% Documentation is contained in the stfloats.sty comments as well as in the
314% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
315% does not allow \baselineskip to stretch. Authors submitting work to the
316% IEEE should note that IEEE rarely uses double column equations and
317% that authors should try to avoid such use. Do not be tempted to use the
318% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
319% not format its papers in such ways.
320
321
322%\ifCLASSOPTIONcaptionsoff
323%  \usepackage[nomarkers]{endfloat}
324% \let\MYoriglatexcaption\caption
325% \renewcommand{\caption}[2][\relax]{\MYoriglatexcaption[#2]{#2}}
326%\fi
327% endfloat.sty was written by James Darrell McCauley and Jeff Goldberg.
328% This package may be useful when used in conjunction with IEEEtran.cls'
329% captionsoff option. Some IEEE journals/societies require that submissions
330% have lists of figures/tables at the end of the paper and that
331% figures/tables without any captions are placed on a page by themselves at
332% the end of the document. If needed, the draftcls IEEEtran class option or
333% \CLASSINPUTbaselinestretch interface can be used to increase the line
334% spacing as well. Be sure and use the nomarkers option of endfloat to
335% prevent endfloat from "marking" where the figures would have been placed
336% in the text. The two hack lines of code above are a slight modification of
337% that suggested by in the endfloat docs (section 8.3.1) to ensure that
338% the full captions always appear in the list of figures/tables - even if
339% the user used the short optional argument of \caption[]{}.
340% IEEE papers do not typically make use of \caption[]'s optional argument,
341% so this should not be an issue. A similar trick can be used to disable
342% captions of packages such as subfig.sty that lack options to turn off
343% the subcaptions:
344% For subfig.sty:
345% \let\MYorigsubfloat\subfloat
346% \renewcommand{\subfloat}[2][\relax]{\MYorigsubfloat[]{#2}}
347% For subfigure.sty:
348% \let\MYorigsubfigure\subfigure
349% \renewcommand{\subfigure}[2][\relax]{\MYorigsubfigure[]{#2}}
350% However, the above trick will not work if both optional arguments of
351% the \subfloat/subfig command are used. Furthermore, there needs to be a
352% description of each subfigure *somewhere* and endfloat does not add
353% subfigure captions to its list of figures. Thus, the best approach is to
354% avoid the use of subfigure captions (many IEEE journals avoid them anyway)
355% and instead reference/explain all the subfigures within the main caption.
356% The latest version of endfloat.sty and its documentation can obtained at:
357% http://www.ctan.org/tex-archive/macros/latex/contrib/endfloat/
358%
359% The IEEEtran \ifCLASSOPTIONcaptionsoff conditional can also be used
360% later in the document, say, to conditionally put the References on a
361% page by themselves.
362
363
364
365
366
367% *** PDF, URL AND HYPERLINK PACKAGES ***
368%
369%\usepackage{url}
370% url.sty was written by Donald Arseneau. It provides better support for
371% handling and breaking URLs. url.sty is already installed on most LaTeX
372% systems. The latest version can be obtained at:
373% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
374% Read the url.sty source comments for usage information. Basically,
375% \url{my_url_here}.
376
377
378
379
380
381% *** Do not adjust lengths that control margins, column widths, etc. ***
382% *** Do not use packages that alter fonts (such as pslatex).         ***
383% There should be no need to do such things with IEEEtran.cls V1.6 and later.
384% (Unless specifically asked to do so by the journal or conference you plan
385% to submit to, of course. )
386
387
388% correct bad hyphenation here
389\hyphenation{op-tical net-works semi-conduc-tor}
390\usepackage{cite} 
391\usepackage{graphicx}
392\usepackage{graphicx}
393\usepackage{xcolor}
394\usepackage{upquote}
395%\usepackage{hyperref}
396\usepackage{url}
397\usepackage{arydshln}
398\usepackage{listings}
399\usepackage{subfigure}
400\usepackage{balance}
401\usepackage{xspace}
402%\usepackage[caption=false]{subfig}
403\newcommand{\pmsg}{{\textit{PowerMessage}}}
404\newcommand{\imsg}{{\textit{InterfaceMessage}}}
405\newcommand{\smsg}{{\textit{SignalMessage}}}
406\newcommand{\dmsg}{{\textit{DigitalMessage}}}
407\newcommand{\amsg}{{\textit{AnalogMessage}}}
408\newcommand{\cmsg}{{\textit{ControlMessage}}}
409\newcommand{\phymsg}{{\textit{PhysicalMessage}}}
410\newcommand{\fm}{{{FM}}}
411\newcommand{\pmm}{{{PM}}}
412\newcommand{\phym}{{{PhyM}}}
413
414\newcommand{\warn}{\textcolor{red}{\textbf{[REF]\space}}}
415\newcommand{\tuple}[1]{\ensuremath{\left \langle #1 \right \rangle }}
416\newcommand{\todo}[1]{\textcolor{blue}{{\bf Todo --\xspace}{\em #1}}}
417\newcommand{\ie}{{\it i.e.},\xspace}
418\newcommand{\eg}{{\it e.g.},\xspace}
419\newcommand{\etal}{{\it et al.}\xspace}
420\newcommand{\cf}{{\it c.f.},\xspace}
421
422\newcommand{\sa}{{\textit{SA}}}
423\newcommand{\fed}{{\textit{FED}}}
424\newcommand{\sued}{{\textit{SUED}}}
425\newcommand{\ffs}{{\textit{FFS}}}
426
427\begin{document}
428%
429% paper title
430% can use linebreaks \\ within to get better formatting as desired
431\title{Scheduling Methods for Network Lifetime Estimation of Wireless Sensor Networks}
432%
433%
434% author names and IEEE memberships
435% note positions of commas and nonbreaking spaces ( ~ ) LaTeX will not break
436% a structure at a ~ so this keeps an author's name from being broken across
437% two lines.
438% use \thanks{} to gain access to the first footnote area
439% a separate \thanks must be used for each paragraph as LaTeX2e's \thanks
440% was not built to handle multiple paragraphs
441%
442
443\author{Wilfried~Dron,~\IEEEmembership{Member,~IEEE,}
444        Khalil~Hachicha,~\IEEEmembership{Fellow,~OSA,}
445        and~Patrick~Garda,~\IEEEmembership{Life~Fellow,~IEEE}% <-this % stops a space
446\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.
447F-75005, Paris, France;
448e-mail: \texttt{[wilfried.dron; khalil.hachicha; patrick.garda]@lip6.fr}.}% <-this % stops a space
449\thanks{Manuscript received Month Day, Year; revised Month Day, Year.}}
450
451% note the % following the last \IEEEmembership and also \thanks -
452% these prevent an unwanted space from occurring between the last author name
453% and the end of the author line. i.e., if you had this:
454%
455% \author{....lastname \thanks{...} \thanks{...} }
456%                     ^------------^------------^----Do not want these spaces!
457%
458% a space would be appended to the last name and could cause every name on that
459% line to be shifted left slightly. This is one of those "LaTeX things". For
460% instance, "\textbf{A} \textbf{B}" will typeset as "A B" not "AB". To get
461% "AB" then you have to do: "\textbf{A}\textbf{B}"
462% \thanks is no different in this regard, so shield the last } of each \thanks
463% that ends a line with a % and do not let a space in before the next \thanks.
464% Spaces after \IEEEmembership other than the last one are OK (and needed) as
465% you are supposed to have spaces between the names. For what it is worth,
466% this is a minor point as most people would not even notice if the said evil
467% space somehow managed to creep in.
468
469
470
471% The paper headers
472\markboth{Transactions on COMPUTER-AIDED DESIGN of Integrated Circuits and Systems,~Vol.~X, No.~Y, Month~Year}%
473{}
474%{Shell \MakeLowercase{\textit{et al.}}: Bare Demo of IEEEtran.cls for Journals}
475% The only time the second header will appear is for the odd numbered pages
476% after the title page when using the twoside option.
477%
478% *** Note that you probably will NOT want to include the author's ***
479% *** name in the headers of peer review papers.                   ***
480% You can use \ifCLASSOPTIONpeerreview for conditional compilation here if
481% you desire.
482
483
484
485
486% If you want to put a publisher's ID mark on the page you can do it like
487% this:
488%\IEEEpubid{0000--0000/00\$00.00~\copyright~2007 IEEE}
489% Remember, if you use this you must call \IEEEpubidadjcol in the second
490% column for its text to clear the IEEEpubid mark.
491
492
493
494% use for special paper notices
495%\IEEEspecialpapernotice{(Invited Paper)}
496
497
498
499
500% make the title area
501\maketitle
502
503
504\begin{abstract}
505%\boldmath
506The network lifetime is a major requirement for the design of WSN's hardware and software.
507%While several simulation tools are focused on power consumption estimation, the network lifetime has been estimated using an ideal battery model.
508While several simulation tools are focused on estimating power consumption, the lifetime is commonly computed using a simple ideal battery model.
509As a consequence, issues related to the use of a more realistic (non-ideal) battery model are not addressed yet.
510Considering 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.
511In this context, we introduce four scheduling methods to address the challenges relative to such battery models.
512These methods manage energy transactions between the wireless node model and a non-ideal battery model.
513%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.
514Each of our methods is analyzed and compared through a typical temperature sensing application case.
515We conducted several simulations considering power consumption estimation, simulation performances, node lifetime estimation and scalability.
516Comparison of the obtained results highlights two methods, one more accurate, but rather slow, whereas the other is strongly scalable, but less accurate.
517\end{abstract}
518
519% Note that keywords are not normally used for peerreview papers.
520\begin{IEEEkeywords}
521battery, lifetime estimation, wsn, OMNeT++, scheduling.
522\end{IEEEkeywords}
523
524
525
526
527
528
529% For peer review papers, you can put extra information on the cover
530% page as needed:
531% \ifCLASSOPTIONpeerreview
532% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
533% \fi
534%
535% For peerreview papers, this IEEEtran command inserts a page break and
536% creates the second title. It will be ignored for other modes.
537\IEEEpeerreviewmaketitle
538
539
540
541\section{Introduction}
542\IEEEPARstart{T}{he} network lifetime is a key parameter of the wireless sensor network characterization~\cite{lifetime}.
543It reflects the time while the network can operate properly according to application-defined constraints.
544%Even if almost every application defines its own constraints, the network lifetime cannot be estimated without being able to estimate the node's lifetime.
545Even if almost every application defines its own constraints, the network lifetime is estimated using the individual nodes' lifetime.
546Since 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.
547
548Nodes are battery-powered, thus the power consumption of the node and its battery characteristics are both necessary to determine its lifetime.
549The power consumption profile is easily accessible from hardware measurements~\cite{wsn_energy} whereas it is more challenging to extract battery characteristics.
550Hence, it is common to use an ideal battery model to model the node's power source.
551This model is known as a battery with a linear discharge curve and a fixed output voltage.
552Far 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.
553%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.
554To obtain more accurate lifetime estimation, another battery model, closer to the real battery behavior, is required.
555It can be either based on experimental measurements or technical specifications.
556To remain consistent using such a model, electrical laws have to be applied.
557Therefore, it is important to pay attention to the way power transactions between battery and supplied components are achieved.
558In other words, the scheduling of the energy transactions trough the simulated time is crucial (\cf Fig.~\ref{archi_methods}).
559%As a consequence, the scheduling of the energy transactions among the battery and the electronic components models is important.
560%Actually, it has a strong impact over the node's lifetime prediction.
561%In this article, we show that the way this scheduling is achieved impact significantly the lifetime estimation.
562%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.
563%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.
564
565In this context, we introduce four scheduling methods to schedule the energy transactions in a modeled wireless sensor network node.
566%We show that these methods are influencing the node lifetime estimation.
567We show that the scheduling has a significant impact on the lifetime estimation, showing differences in the obtained results that reach 11.7\%.
568%Moreover, the simulation's performance is also impacted, bounding the uses of certain methods to small-sized networks or short lifetime modeling.
569As 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.
570
571This article is structured as follows.
572The second section holds the background of this work.
573The scheduling methods principles are explained in the section 3.
574The fourth section addresses the implementation of these methods in OMNeT++ through a WSN framework that is oriented towards power consumption estimation.
575Finally, the two last sections hold respectively the simulation results and their discussion.
576
577\begin{figure}
578\begin{center}
579\includegraphics[scale=0.35]{architecture.pdf}
580\caption{\label{archi_methods}
581\textbf{Application example of the scheduling methods:} 
582Here, \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.
583}
584\end{center}
585\end{figure}
586
587\section{Background}
588Scheduling methods for energy transactions have not been addressed yet, thus there is no previous work on that subject.
589However, there are some related works that deal with the power consumption estimation issues for the wireless sensor network simulation.
590Since the node lifetime estimation relies on the battery models as well, it is important to give a brief introduction to the battery behavior.
591For that purpose, this section holds a short background about the battery behavior before addressing the core-related works.
592
593\subsection{Battery Behavior and Modeling} \label{sect:battery_desc}
594The primary batteries are electrochemical power sources.
595In contrast with the wired power sources, the amount of energy that they carry is limited.
596This 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.
597Considering a battery under use, its residual varies with the ambient temperature and the instantaneous current draw.
598In other words, the available amount of energy changes over the time according to the aforementioned factors.
599The battery's \textit{nominal current} (set by the manufacturer) represent the ``normal operation'' current limit under continuous draw.
600The 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).
601Furthermore, the supply voltage varies as well with temperature and instantaneous current draw but also with the residual.
602As a consequence, a specific current draw can produce a drift in the battery's supply voltage value.
603According to the ohm law, this drift will change the current draw itself leading to a new drift.
604%Considering a resistive circuit, the voltage value would reach an equilibrium which is not the case considering regulated system like voltage regulators for instance.
605%All these assumptions were experimentally validated.
606
607A 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}.
608These observations were confirmed by a more recent work that characterized commercial Li-Ion batteries behaviors through real measurements~\cite{battery_char_new}.
609In 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.
610%Another article that focuses on remaining capacity measurements agrees on the same conclusion~\cite{remaining_capacity_measurement}.
611
612Another article agrees on the same conclusion~\cite{remaining_capacity_measurement}.
613This 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.
614
615More battery centered work were conducted to reach a better understanding of the battery properties.
616Among 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}.
617As mentioned, when a strong current is drawn from the battery, its \textsl{effective capacity} decreases.
618In other words, its actual available energy is lower than the nominal value.
619This assumption is valid for a current draw that remains the same until the end of the battery life.
620For instance, if the current draw decrease to a value that is beyond the battery's ``nominal current'', the battery will ``recover'' some capacity.
621
622%To summarize, there are strong evidences that explain the limitations of ideal battery model.
623To summarize, the aforementioned evidences clearly established the limitations of the ideal battery model.
624While 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.
625
626\subsection{Simulation and Modeling Environments}
627There are several simulators and frameworks that enable the power consumption estimation.
628Among 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.
629TOSSIM~\cite{tossim_ws} is, for instance, a network simulator dedicated to Tiny-OS~\cite{tinyos}.
630This simulator is extended by many further work.
631The most noticeable are Power-TOSSIM~\cite{powertossim_ws} and mTOSSIM~\cite{mtossim}.
632Power-TOSSIM enables the power consumption to be computed after the simulation ends.
633In contrast, mTOSSIM goes further, allowing the lifetime to be estimated.
634It does so using a super-capacitor to model the power supply of the nodes.
635The super-capacitor behavior is very different from the battery behavior (\cf Section~\ref{sect:battery_desc}).
636As a consequence, this model cannot be used to estimate the lifetime of nodes equipped with batteries.
637
638%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.
639%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.
640%Furthermore, none of them is providing a node lifetime estimation or only based on ideal battery model.
641%As a consequence, these works are out of the scope of this paper.
642 
643Regarding 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}.
644Some of them are able to estimate power consumption thanks to extensions called \textit{frameworks}.
645However, the goal of these environments is to deal with network modeling issues more than network lifetime estimation.
646The 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}.
647As a consequence, several~\textit{power-aware} frameworks were developed over the previous years.
648Energy Model~\cite{modeling_energy}, Pawis~\cite{pawis_fm_2} and Energy Framework~\cite{energy_fm} were thus introduced.
649Unfortunately, a common short-coming of these frameworks is that none of them provides a non-ideal battery model.
650
651Nevertheless, this short-coming was partially covered in an extension of the Energy Framework~\cite{energy_fm_2}.
652In their article, K. Mikhaylov and J. Tervonen presented a battery model that was validated through measurements of real batteries~\cite{battery_char_new}.
653Unfortunately, this validation does not consider battery supply voltage variations due to the current draw.
654Furthermore, it neglects the internal resistance of the battery and the relaxation effect.
655A 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$\%.
656%Their first conclusion is the fact that using an ideal battery model leads to an over-evaluation of the battery lifetime of almost $40$\%.
657%Unfortunately, the techniques that were used to schedule the transaction between the battery model and the components model were not presented.
658%Moreover, the simulation case that was chosen was limited to a simple resistive model in which the supply voltage drifts were not considered.
659%As a result, it is difficult to re-use this work as a base for the network lifetime estimation.
660
661A last power-aware framework for OMNeT++ was introduced~\cite{newcas}.
662The battery model that is provided by the authors was built following technical specifications.
663%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.
664Finally, the conclusion of their work states that the formal event driven technique used together with their battery model results in erroneous battery lifetime estimations.
665%To address this issue, they introduced a periodical scheduling method called \textit{Fixed Frequency Sampling} method.
666
667%This latest framework was selected to implement the scheduling method because of its unique component oriented architecture and the several proposed models.
668%The following section is dedicated to the description of the methods.
669%Therefore, the firstly introduced scheduling method \textit{Fixed Frequency Sampling} will be exposed again in a more detailed way.
670
671\section{Scheduling Methods} \label{sec:schedul_meth}
672In this context, we introduce four scheduling methods to address the challenges relative to non-ideal battery models.
673
674All 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.
675In 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}).
676Each component's model is assumed to have as many power modes as the modeled component has (\eg ON, OFF, POWER DOWN or SLEEP).
677A specific instantaneous current draw is associated to each power mode.
678Consequently, each power mode change results in a new instantaneous current draw.
679Considering these statements, modeling of the supply voltage and the instantaneous current draw are mandatory to apply the following scheduling methods.
680
681The ``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.
682The cut-off voltage threshold is the most robust approach.
683Actually, the cut-off voltage is the voltage value under which the electronic components operation are not guaranteed.
684However, the above descriptions are applicable in both cases.
685%Our scheduling methods can be used in any structure that model one to N battery-supplied components.
686%Modeling of the supply voltage and the instantaneous current draw is the only requirement that could limit their application.
687
688This sections holds the description of our scheduling methods.
689A concrete application case is added as an example after the general descriptions.
690% in order to expose the differences between every scheduling method.
691Integration of these scheduling algorithms is explained as the conclusion of the section.
692
693%%%%% METHODS DESCRIPTION
694\begin{figure}
695\begin{center}
696\includegraphics[scale=0.45]{schedule_FFS.pdf}
697\caption{\label{figure1}
698\textbf{Fixed frequency sampling method states graphic:} 
699This graph shows the principle of the \ffs\xspace method.
700The battery update are triggered periodically (each \textit{T} second) after the step~5.
701}
702\end{center}
703\end{figure}
704
705\subsection{Fixed Frequency Sampling method (FFS)}
706The \textit{Fixed Frequency Sampling} method (shorten to \ffs) was introduced into prior work~\cite{newcas}.
707This method relies on a periodic update of the battery's parameters and the current drawn by the components.
708Figure~\ref{figure1} is a state chart that describes its scheduling algorithm.
709First of all, the battery initiates the simulation by sending its supply voltage value to the component.
710This allows the components to turn into ON mode.
711Then, they send back their averaged instantaneous current consumption over the previous period (which is null for the very first period).
712The battery residual and the supply voltage are then updated according to the received current draw value.
713Finally, 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).
714If 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).
715%If the battery is depleted, it sends a $0.0$V supply voltage that turns the components into OFF mode.
716
717\subsection{Self Updating Event Driven method (SUED)}
718In contrast with the \ffs\xspace method, the \textit{Self Updating Event Driven} method takes into account every current draw change instantaneously.
719The \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.
720When the simulation starts, the battery sends its supply voltage value to the components.
721The components send back their instantaneous current draw.
722Then the supply voltage and the remaining capacity of the battery are updated using the received value of the current draw.
723This current draw value is stored.
724If none of the components change their instantaneous current draw value, the battery will be updated every \textit{T} seconds.
725When a component changes its power mode (\eg ON $\rightarrow$ POWER DOWN), the corresponding instantaneous current draw value is sent to the battery.
726Then, the regular updating process is interrupted.
727The 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.
728Finally, 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).
729
730\begin{figure} 
731\begin{center}
732\includegraphics[scale=0.45]{schedule_FED.pdf}
733\caption{\label{figure3}
734\textbf{Fast event driven method state graphic:} 
735This graph shows the principle of the \fed\xspace method.
736In this method, the battery update are triggered by each components' power mode change.
737}
738\end{center}
739\end{figure}
740
741\subsection{Fast Event Driven method (FED)}
742The \textit{Fast Event Driven} method is derived from the ``formal'' event driven simulation technique.
743As a consequence, the battery updates are triggered by each instantaneous current draw changes.
744The state chart depicted in the Figure~\ref{figure3} represents the behavior of this scheduling method.
745The battery initiates the simulation by sending its supply voltage value.
746As a consequence, the components change their power modes (\ie from OFF to ON) and send back their associated instantaneous current draw value.
747In the same way as the \sued\xspace method, this current draw value is stored by the battery model.
748When a component changes its power mode again, this value is updated.
749Before storing the just received value, a battery update is performed.
750%Actually, it will estimate and check its new residual value considering the time elapsed from the previous update.
751This update consists of checking and computing the new battery's residual considering the time elapsed since the previous update.
752Battery's supply voltage value is also updated, but using the new instantaneous current draw value and the residual that has just been estimated.
753Finally, this supply voltage value is sent to the component.
754
755Since the \fed\xspace scheduling method does not trigger updates of the battery periodically, using this method can lead to nodes operating without energy.
756If 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.
757%As a consequence, another mechanism is required.
758%A way to avoid this issue is to ``plan'' the end of the battery life assuming that there will be no more event.
759%The end of life of the battery has to be forecast
760A 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.
761To be consistent, this end-of-life forecast has to be re-evaluated each time the current draw value changes.
762In other words, the battery's end of life has to be re-planned each time that a battery update is triggered.
763
764\subsection{Self Adaptive method (SA)}
765The \textit{Self Adaptive} method is based on both a periodical update schedule and an event-driven like schedule.
766%Actually, the previously introduced method are sensitive to the time and/or to the current draw changes events.
767In addition, the \sa\xspace method is sensitive to the current draw value.
768Battery 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).
769The border between these two areas is the \textit{nominal current draw} (\cf Sec.~\ref{sect:battery_desc}).
770As a consequence, the \sa\xspace scheduling method changes the way it triggers battery's and components updates according to the instantaneous current draw value.
771When 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.
772In 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.
773
774On 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).
775
776\subsection{Application example}
777The chosen application example is a single component that is supplied by a battery.
778The functional behavior of this component is not discussed here since the meaningful information is its instantaneous current draw consumption.
779As a consequence, the power mode is the only information that is considered.
780The following mode sequence was arbitrarily chosen:
781\begin{itemize}
782\item OFF $\rightarrow$ ON $\rightarrow$ POWER DOWN $\rightarrow$ ON.
783\end{itemize}
784The Figure~\ref{time} is a representation of each scheduling method applied to our example.
785%Each of the four graphs illustrates the results of its method applied to the example case.
786All the graph are time aligned making the difference between each scheduling method easier to understand.
787
788%\begin{figure}
789%\begin{center}
790%\includegraphics[scale=0.45]{method_global.pdf}
791%\caption{\label{time}
792%\textbf{Application example of the scheduling methods:}
793%This figure is a time graph that shows the application of each scheduling method to our application example.
794%The \ffs\xspace method trigger battery update according to its sampling period \textit{T}.
795%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.
796%The \fed\xspace method only triggers battery updates on the components change.
797%The \sa\xspace method use periodic update when precision is required and event driven updates when less precision is needed.
798%}
799%\end{center}
800%\end{figure}
801
802\begin{figure}
803%\begin{center}
804\centering
805\subfigure[Fixed Frequency Sampling]{
806        \includegraphics[scale=0.45]{time_FFS.pdf}
807        \label{time_ffs}
808}
809\subfigure[Self-Updating Event-Driven]{
810        \includegraphics[scale=0.45]{time_FFS.pdf}
811        \label{time_sued}
812}
813\subfigure[Fast Event-Driven]{
814        \includegraphics[scale=0.45]{time_FFS.pdf}
815        \label{time_fed}
816}
817\subfigure[Self Adaptative]{
818        \includegraphics[scale=0.45]{time_FFS.pdf}
819        \label{time_sa}
820}
821
822%\includegraphics[scale=0.45]{method_global.pdf}
823\caption{\label{time}
824\textbf{Application example of the scheduling methods:} 
825This figure is a time graph that shows the application of each scheduling method to our application example.
826The \ffs\xspace method triggers battery update according to its sampling period \textit{T}.
827The \sued\xspace method triggers as well the update of the battery each \textit{T} seconds but also when a component changes its power mode.
828The \fed\xspace method only triggers battery updates on the components change.
829The \sa\xspace method uses periodic update when precision is required and event driven updates when less precision is needed.
830}
831%\end{center}
832\end{figure}
833
834Figure~\ref{time_ffs} is the graph that represent the \ffs\xspace method application.
835The updates of the battery and the component's current draw changes are asynchronous.
836Moreover, the supply voltage updates are delayed by one period in comparison with the current draw updates.
837In 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.
838Figure~\ref{time_sued} represent the application of the \sued\xspace method.
839In contrast with the \ffs\xspace method, it appears that the battery's updates are synchronized with the current draw changes.
840The periodical update is also observable while the component is in LOW POWER mode.
841Alike the \ffs\xspace method, the supply voltage updates are also delayed.
842
843The application of the \fed\xspace method is plotted in the graph Figure~\ref{time_fed}.
844%The fact that the battery updates happen only in synchronization with the component's power mode changes is highlighted.
845The graph highlight that the battery updates happen only in synchronization with the component's power mode changes.
846The Figure~\ref{time_sa} illustrates the application of the \sa\xspace method.
847This method is sensitive to the current draw value in respect with the battery characteristics.
848The 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.
849Consequently, periodical updates are achieved when the components is in ON mode whereas there is no update while the component is in LOW POWER mode.
850
851%\section{Modeling and integration in the Framework}
852\subsection{Framework Integration}\label{implementation}
853As mentioned previously, we chose to implement our scheduling method in an OMNeT++ framework~\cite{newcas}.
854%As mentioned previously, a power aware simulation environment was chosen to implement the scheduling methods \cite{newcas}.
855%Actually, this environment is an OMNeT++'s framework that allows the wireless sensor node to be described with each of its electronic components.
856This environment allows a node to be described with every of its electronic components.
857Each component is described using two levels of description: a functional and a hardware one.
858Practically, the components are described using a functional model and a power model.
859Regarding the battery, a ``technical specification based'' model is provided.
860
861The integration of our scheduling methods requires few modifications in the provided models.
862Theoretically, each power model should be modified according to the chosen scheduling method.
863Fortunately, the simulated architecture use a DC/DC step-down converter to keep the supply voltage between the battery and the components steady.
864Therefore we consider the following assumption: the voltage do not change between the components' power model and the step down converter's output.
865%WD: to moove in the discussion
866%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.
867Consequently to this assumption, the only models that requires to be modified are the battery model and the converter model.
868
869To ensure reliable simulation results, mechanisms of the modified components were isolated into functions that takes every necessary information as parameters.
870Even if it needed additional formalizing and coding efforts, this approach allows us to described the models independently from the scheduling method.
871%The way and the sequence order in which the function are called determined the scheduling method.
872
873\section{Modelling and simulation configuration}
874\subsection{Battery Modelling}
875The battery model that was used in the simulation is a model of the CR2032 battery from Panasonic~\cite{cr2032}.
876The 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}).
877%\begin{figure}
878%\begin{center}
879%\includegraphics[scale=1.1]{cr2032_capacity_vs_load_resistance.pdf}
880%\caption{\label{cr2032}Panasonic CR2032: \textit{capacity vs. load resistance characteristic} \cite{cr2032} }
881%\end{center}
882%\end{figure}
883The impact of the temperature variation on the battery were not considered in the following simulation case.
884As a consequence, the battery's \textit{effective capacity} varies only with the instantaneous current draw.
885\begin{figure}
886\begin{center}
887\includegraphics[scale=0.40]{eq_current_plot.pdf}
888\caption{\label{eq_current}
889\textbf{Equivalent and instantaneous current draw estimations:} 
890This 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}).
891}
892\end{center}
893\end{figure}
894
895In this model, the capacity of the battery is considered as fixed.
896Therefore, to model the impact of the instantaneous current draw on the \textit{relative capacity}, the equivalent current draw $i_{eq}(t)$ was considered.
897It has been defined using the following equation:
898\begin{equation}\label{ieq}
899i_{eq}(t) = \frac{C_{nominal}}{C_{relative}(i(t))} \times i(t)
900\end{equation}
901Where $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.
902The $i(t)$ is the instantaneous current expressed in mA.
903The factor between $C_{nominal}$ and $C_{relative}$ is called the \textit{overdraw factor}.
904Therefore, the equivalent current draw is expressed as a function of the present instantaneous current draw as depicted in the chart Figure~\ref{eq_current}.
905This graph was plotted using a current draw ramp directly plugged in the battery model.
906This battery modeling technique has the advantage of modeling both the \textit{effective capacity} and the \textit{relaxation} effects as well.
907%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.
908
909The equation that is used to estimate the battery's residual $R$ at the $t+\Delta t$ time is the following one:
910\begin{equation}
911R(t+\Delta t) = R(t) -  i_{eq}(t) \times \frac{\Delta t}{3600}
912\end{equation}
913Where $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.
914Finally, the $3600$ value stands for the conversion of $\Delta t$ in hours.
915
916%\section{Simulation}
917\subsection{Simulated Architecture}
918The platform used as modeling base was a prototype under development.
919It 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}.
920The power supply is handled by 4 CR2032 batteries~\cite{cr2032} that are assembled in serial.
921%The figure \ref{omnet} is a screen shot of the modelled node into the simulation environment.
922%\begin{figure}
923%\begin{center}
924%\includegraphics[scale=0.55]{node_omnet.jpg}
925%\caption{\label{omnet}Description of the node's architecture inside the WSN framework}
926%\end{center}
927%\end{figure}
928The measurements that were used to build the MCU and the transceiver models are reported in Table~\ref{msp_meas}.
929These measurements were made using a NI PXI-4071 ampere-meter integrated in a NI PXIe-1075 rack from National Instruments.
930The used precision was seven and a half digits, the maximum precision of the device.
931The measurements were achieved using a temperature regulated chamber from Binder.
932The MCU firmware that was used to achieve this was the application that is embedded in the sensing node.
933Consumption measurements of the MSP430 are not restricted to the core but include also the consumption of the whole chip.
934
935\begin{table}[h]
936\centering
937\subtable[MSP430]{
938        \begin{tabular}{|c||c|c|c|c|}
939                \hline
940                \textit{Mode} & Active & ADC+LPM4 & LPM4 \\ 
941                \hline
942                Inst. current & 0.813mA & 0.326mA & 0.226mA \\
943                \hline
944        \end{tabular}
945}
946%\begin{tabular}{cccccccc}
947 %& & & & & & &\\
948%\end{tabular}
949\subtable[CC2520]{
950        \begin{tabular}{|c||c|c|c|c|c|c|}
951                \hline
952                \textit{Mode} & XOSC Off & Idle & RX & RX LP & TX-18dBm \\
953                \hline
954                Inst. current & 0.178mA & 1.776mA & 22.48mA & 18.79mA &  16.63mA\\
955                \hline
956        \end{tabular}
957}
958\smallskip
959\caption{\label{msp_meas}{\bf Experimental measurements of the current draw}}
960\end{table}
961
962Regarding the functional behavior, the application that is modeled is a typical temperature measuring scenario.
963The network is organized in a star topology and the IEEE 802.15.4 protocol is used by the node to communicate.
964The sensing node behavior is the following:
965\begin{enumerate}
966\item The node start to listen the channel to seek for a broadcast frame that comes from the central node;
967\item Once it received the frame with the same PAN-ID and the expected source address, it acknowledge the subscription;
968\item Every second it wakes up, takes a measure of the temperature and send it to the central node before going back to sleep.
969\end{enumerate}
970Each sensor has a time slot that is computed according to its own address, at the beginning of the run.
971The central node is periodically broadcasting its subscription frame an turns into reception mode right after.
972Therefore, its power consumption is high in comparison with the sensor node.
973In the simulation, it is considered as being supplied by an ideal power source with infinite energy.
974
975\section{Results}
976All along this section, several simulation cases and their results are presented.
977The 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).
978This choice is motivated by the simulation performances (\cf Sect.~\ref{sim_perfs}).
979The 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.
980Ubuntu LTS 12.04 was used as operating system.
981The OMNeT++ version was the 4.3.
982Simulator was configured to use only one core over eight in order to have no hardware acceleration that could biased the performance results.
983%Each simulation case was run at least 10 times in order to verify the reliability of the obtained results.
984
985\subsection{Power consumption estimation}
986The power consumption estimation results were obtained by simulating four instances of the same node for one hour of simulated time.
987Each node implements a different method to schedule the power transaction between the batteries and the components.
988As a reference, another simulation was run within the same conditions but using ideal battery models instead of CR2032 models.
989The battery's residual value results for both simulations are presented in Table~\ref{residual_results}.
990
991\begin{table}[h]
992\centering
993\subtable[Ideal battery model, \textit{T}=50us]{
994        \begin{tabular}{|c||c|c|c|c|}
995        \hline
996                & FFS & SUED & FED & SA\\
997        %\hline
998        %\multicolumn{5}{|c|}{Nodes with Ideal model (\textit{T}=50us)}  \\
999        \hline
1000        Residual (mAh)&$\textbf{219.9273}$&$\textbf{219.9273}$&$\textbf{219.9273}$&$\textbf{219.9273}$\\
1001        %Consumed Cap. (mAh)&$0.0727$&$0.0727$&$0.0727$&$0.0727$\\
1002        Av. $i_{eq}(t)$ (uA)&$72.7$&$72.7$&$72.7$&$72.7$\\
1003        %Av. voltage (V)&$12.00$&$12.00$&$12.00$&$12.00$\\
1004        \hline
1005        \end{tabular}
1006        }
1007\subtable[CR2032 battery model, \textit{T}=50us]{
1008        \begin{tabular}{|c||c|c|c|c|}
1009        \hline
1010        & FFS & SUED & FED & SA\\
1011        %\hline
1012        %\multicolumn{5}{|c|}{Nodes with CR2032 model (\textit{T}=50us)}  \\
1013        \hline
1014        Residual (mAh)&$\textbf{219.9249}$&$\textbf{219.9248}$&$\textbf{219.9167}$&$\textbf{219.9137}$\\
1015        %Consumed Cap. (mAh)& $0.0751$& $0.0752$& $0.0833$& $0.0863$\\
1016        Av. $i_{eq}(t)$ (uA)& $75.1$& $75.2$& $83.3$& $86.3$\\
1017        \hline
1018\end{tabular}
1019}
1020\smallskip
1021\caption{\label{residual_results}
1022{\bf Battery's residual estimation results:}
1023{\textnormal{
1024The 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.
1025In contrast, they are different for each scheduling method using the technical specification based battery model}
1026}
1027}
1028\end{table}
1029
1030%\begin{table}[h]
1031%\centering
1032%\caption{\label{consumption_result}Power consumption estimation}
1033%\begin{tabular}{|c||c|c|c|c|}
1034%\hline
1035%\multicolumn{5}{|c|}{Simulated time = 60 minutes}  \\
1036%\hline
1037% & FFS & SUED & FED & SA\\
1038%\hline
1039%\hline
1040%\multicolumn{5}{|c|}{Power Consumption: Ideal model}  \\
1041%\hline
1042%Residual (mAh) & $\textbf{219.9273}$ & $\textbf{219.9273}$ & $\textbf{219.9273}$ & $\textbf{219.9273}$\\
1043%Consumed C. (mAh) &$0.0727$&$0.0727$&$0.0727$& $0.0727$\\
1044%Av. eq. current (uA) &$72.7$&$72.7$&$72.7$&$72.7$\\
1045%Av. voltage (V)&$12.00$&$12.00$&$12.00$&$12.00$\\
1046%\hline
1047%\hline
1048%\multicolumn{5}{|c|}{Power Consumption: CR2032 model}  \\
1049%\hline
1050%Residual (mAh) & $\textbf{219.9249}$& $\textbf{219.9248}$ & $\textbf{219.9167}$& $\textbf{219.9137}$\\
1051%Consumed Energy (mAh) & $0.0751$& $0.0752$& $0.0833$& $0.0863$\\
1052%\hline
1053%Max current (mA) & $3.99$ & $3.99$& $3.92$& $3.99$\\
1054%Min current (mA) & $0.073$ & $0.073$& $0.071$& $0.071$\\
1055%\hline
1056%Max eq. current (mA) & $7.359$& $7.359$& $7.033$& $7.359$\\
1057%Min eq. current (mA) & $0.70$& $0.073$& $0.071$& $0.071$\\
1058%Av. eq. current (uA) & $75.1$& $75.2$& $83.3$& $86.3$\\
1059%\hline
1060%Max voltage (V) & $12.0$& $12.0$& $12.0$& $12.0$\\
1061%Min voltage (V) & $9.98$& $9.98$& $10.67$& $9.98$\\
1062%Av. voltage (V) & $10.62$& $10.54$& $11.40$& $10.70$\\
1063%\hline
1064%\end{tabular}
1065%\end{table}
1066
1067The 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)).
1068Actually, 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.
1069In contrast, the results obtained by the node that were equipped with CR2032 models are not equal (\cf Tab.~\ref{residual_results}(b)).
1070These variations in the power consumption estimations highlight the fact that scheduling method do influence the residual estimation.
1071Consequently, the node lifetime estimation is also influenced even if each battery model and each component model is the same.
1072
1073\begin{table}[h]
1074\begin{center}
1075\begin{tabular}{|c||c|c|c|c|}
1076\hline
1077 & FFS & SUED & FED & SA\\
1078\hline
1079Max $i(t)$ (mA) & $3.99$ & $3.99$& $3.92$& $3.99$\\
1080Min $i(t)$ (mA) & $0.073$ & $0.073$& $0.071$& $0.071$\\
1081\hline
1082Max $i_{eq}(t)$ (mA) & $7.359$& $7.359$& $7.033$& $7.359$\\
1083Min $i_{eq}(t)$ (mA) & $0.70$& $0.073$& $0.071$& $0.071$\\
1084%\hline
1085%Av. eq. current (uA) & $75.1$& $75.2$& $83.3$& $86.3$\\
1086\hline
1087\end{tabular}
1088\end{center}
1089\smallskip
1090\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.}}
1091\end{table}
1092
1093Focusing on the detailed results, the residual estimation that is obtained using the \ffs\xspace method is the highest one with $219.9429$ mAh.
1094Firstly, the current draw is integrated over the \textit{T} period.
1095This is comparable to a \textit{low pass filter} that cuts the edges of the current draw spikes.
1096Secondly, the supply voltage value is the one that has been computed using the previous current draw value.
1097The impact of the voltage drifts are consequently lowered.
1098The \sued\xspace method suffers from the same observations, except for the spike transition thanks to the synchronized current updates.
1099This 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).
1100To achieve better results with these scheduling methods, the Shannon theorem should be observed.
1101In other word, the sampling period should be at least twice short as the shorter power mode changing of the system.
1102In the present case, the shorter period is around 5us.
1103Therefore a 2.5us period is the minimum period length regarding the accuracy and the precision of the estimation.
1104Unfortunately, using such a small period results in an extremely slow simulation as presented in the next section.
1105
1106%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.
1107Another 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.
1108These variations could be explained by the numeric precision.
1109Since 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.
1110Actually, this phenomena is partially observable considering the current draw and the equivalent current draw estimation (\cf Tab.~\ref{current_results}).
1111
1112\begin{table}[h]
1113\centering
1114\begin{tabular}{|c||c|c|c|c|}
1115        \hline
1116        & FFS & SUED & FED & SA\\
1117        \hline
1118        Max voltage (V) & $12.0$& $12.0$& $12.0$& $12.0$\\
1119        Min voltage (V) & $9.98$& $9.98$& $10.67$& $9.98$\\
1120        %Av. voltage (V) & $10.62$& $10.54$& $11.40$& $10.70$\\
1121        \hline
1122\end{tabular}
1123\smallskip
1124\caption{\label{voltage_results}
1125{{\bf Battery supply voltage estimation:}
1126\textnormal{The estimated supply voltage values are the same except for the FED method.}
1127}
1128}
1129\end{table}
1130
1131Focusing 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.
1132This is a result of the event driven-like algorithm.
1133The current drawn by the components is updated immediately when one of them changes its power mode.
1134Once 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.
1135This 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}).
1136The observation of the current draw and the equivalent current draw in the Table~\ref{current_results} are confirming this assumption.
1137Actually, 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.
1138
1139The sampling mechanism of the \sa\xspace method allows the battery model to react almost instantly to every current draw variation.
1140Finally, 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}).
1141This highlights once again the fact that updates are driven by the components' power mode changes.
1142
1143\subsection{Simulation performance} \label{sim_perfs}
1144The simulation performance results were obtained by running the nodes for five minutes of CPU time (300 seconds).
1145Two series of simulation were conducted.
1146The first one consist of running one single node and its base station at a time.
1147Each scheduling method is therefore evaluated on its own.
1148The second one consist of the same principle but running a network of five identical nodes.
1149The main results are presented in Table~\ref{residual_results}.
1150In this table there is several abbreviation:
1151\begin{itemize}
1152\item the simulated time: \textit{\textbf{Sim.time}}
1153\item the average simulated sec. per sec. ratio: \textit{\textbf{Av.Sim.s/s}}
1154\item the number of simulated events: \textit{\textbf{N.ev.}}
1155\item the average number of event per sec.: \textit{\textbf{Ev/s}}
1156\end{itemize}
1157
1158
1159The time indications give basic idea on how much of CPU time it would take if the simulation has to reach a specific time.
1160The event indications give idea about the load of the simulation kernel.
1161It allows to figure out the raw performances and eventually deduce the impact of porting the scheduling methods to another simulation environment.
1162\begin{table}[h]
1163\centering
1164\begin{tabular}{|c||c|c|c|c|}
1165\hline
1166\multicolumn{5}{|c|}{CPU time = 5min (300 s)}  \\
1167\hline
1168 & FFS & SUED & FED & SA\\
1169\hline
1170\hline
1171\multicolumn{5}{|c|}{1 Node}  \\
1172\hline
1173Av.Sim.s\slash s & \textbf{2.695} & \textbf{5.474} & \textbf{6699} & \textbf{3342}\\
1174\hline
1175Sim.time & 13min:28s& 27min:22s & 23d:6h & 11d:22h\\
1176N.ev. &$48\times10^6$&$98\times10^6$&$80\times10^6$&$82\times10^6$ \\
1177Ev\slash s &$1.6\times10^5$&$3.2\times10^5$&$2.7\times10^5$&$2.7\times10^5$ \\
1178\hline
1179\multicolumn{5}{|c|}{5 Nodes}  \\
1180\hline
1181Av.Sim.s\slash s & \textbf{0.576} & \textbf{1.218} & \textbf{1330} & \textbf{713.5}\\
1182\hline
1183Sim.time & {2min:52s}&{6min:5s}& {4d:14h}& {2d:11h}\\
1184N.ev. &$51.8\times10^6$&$109.6\times10^6$&$86.6\times10^6$&$89.3\times10^6$ \\
1185Ev\slash s &$1.7\times10^5$&$3.6\times10^5$&$2.8\times10^5$&$2.9\times10^5$ \\
1186\hline
1187\end{tabular}
1188\smallskip
1189\caption{\label{perf_table}
1190{{\bf Simulation performance (\textit{T}=50us)}:
1191\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}
1192}
1193}
1194\end{table}
1195
1196Regarding the simulated time for a single node, the results are quite clear.
1197The \ffs\xspace and the \sued\xspace method reach $13$ and $27$ minutes respectively.
1198In contrast, the \sa\xspace method is able to simulate almost $12$ days in $5$ minutes of CPU time.
1199The \fed\xspace method outperforms by reaching $23$ days of simulated time and almost $2$h simulated per second.
1200The results of the 5 nodes are following the same trends.
1201The 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.
1202The \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.
1203Finally, the best performances were obtained using the \sa\xspace and the \fed\xspace method with respectively 2 days and 4 days of simulated time.
1204
1205As a consequence, the \ffs\xspace and the \sued\xspace method are not considered in the following experiments.
1206This 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.
1207
1208\subsection{Node lifetime estimation}
1209The 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.
1210This scenario focuses on the real node lifetime as it has been defined in the beginning of this article.
1211If, 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.
1212Therefore the node can be considered as dead or not reliable enough from the point of view of the network.
1213
1214As mentioned before, only the \fed\xspace and the \sa\xspace method were considered in this experiments.
1215Making the same run with the \ffs\xspace method would have require approximately 1 month of continuous run.
1216The 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).
1217This estimation implicitly assumes that the battery is able to supply the node until its total depletion, which is not the case.
1218The node lifetime estimation results are presented in the Table~\ref{sim_table_2}.
1219First analysis of these results reveals that estimation obtained by the \fed\xspace and the \sa\xspace methods are significantly different.
1220The \fed\xspace node lasted three months and twelve days while the \sa\xspace node lasted three months and one day.
1221This 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}$.
1222
1223\begin{table}[h]
1224\centering
1225\begin{tabular}{|c||c|c|}
1226\hline
1227 & FED & SA\\
1228\hline
1229\hline
1230\multicolumn{3}{|c|}{Node lifetime (\textit{T}=50us)}  \\
1231\hline
1232Lifetime &  3m:12d:7h:29min:0s & 3m:1d:8h:50min:29s\\
1233\hline
1234Residual (mAh) & $0.0176$ & $\textbf{16.8062}$\\
1235\hline
1236Simulation time &  22min:25s & 38min:18s\\
1237Av.Sim.s\slash s &  $6700$ & $3510$\\.
1238N.ev. &$3.6\times10^8$ &$64\times10^8$ \\
1239Ev\slash s &$2.7\times10^5$ & $2.8\times10^5$\\
1240\hline
1241%Gain Factor  & $98.5$ & $1.35$\\
1242%\hline
1243\end{tabular}
1244\smallskip
1245\caption{\label{sim_table_2}
1246{\bf Node lifetime estimation performance}:
1247\textnormal{The difference of 11.7\% between the two methods highlight the fact that scheduling methods do influence the lifetime estimation.}
1248}
1249\end{table}
1250
1251A 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.
1252It 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.
1253Considering the technical specification, the battery should not be able to handle the current spike of a RF frame transmission at this depletion level.
1254Consequently, the results obtained by the \sa\xspace method are more realistic.
1255Unfortunately, there is no means to measure the remaining capacity in a real battery to have a comparison point.
1256Further experiments about battery discharge in this particular application case will be conducted in order to experimentally validate this hypothesis.
1257
1258\subsection{Scalability}
1259The last exposed experiment was conducted to evaluate the scalability of the \fed\xspace and the \sa\xspace scheduling methods.
1260The simulated time was set to $24$h hours.
1261Each simulation contained a complete network with $10$ to $250$ nodes and a central station.
1262The obtained result are presented in the table \ref{sim_table_3}.
1263
1264\begin{table}[h]
1265\centering
1266\begin{tabular}{|c||c|c|}
1267\hline
1268\multicolumn{3}{|c|}{Simulated time = 24h (\textit{T}=50us)}\\
1269\hline
1270 &FED&SA\\
1271\hline
127210 nodes & $2$min $11$s & $4$min $6$s \\
1273%\cdashline{2-3}
127450 nodes & $13$min $57$s & $24$min $3$s \\
1275%\cdashline{2-3}
1276100 nodes & $36$min $17$s & $56$min $52$s\\
1277%\cdashline{2-3}
1278250 nodes & $2$h $58$min & $3$h $45$min \\
1279\hline
1280\end{tabular}
1281\smallskip
1282\caption{\label{sim_table_3}
1283{\bf Scalability comparison: simulation time for 10 to 250 nodes}:
1284\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.}
1285}
1286\end{table}
1287
1288First 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.
1289Actually, simulating 250 nodes should be 25 times longer than simulating 10 nodes.
1290Simulating 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.
1291This is explained by the fact that each additional node adds a significant traffic load.
1292A 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.
1293This difference seems to decrease when the size of the network increase.
1294With a 250 nodes network, using the \sa\xspace method takes only 26\% more time than the \fed\xspace method.
1295
1296More generally, these results are highlighting the high scalability of the \fed\xspace method in comparison with the \sa\xspace method that is slower.
1297
1298\section{Conclusion}
1299In 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.
1300Our first experiments revealed that the scheduling methods do have an impact on battery's lifetime estimations and thus on the node lifetime prediction.
1301As 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.
1302In contrast, event-driven based method is the fastest scheduling method whereas it appears to lead to inaccurate results.
1303Finally, 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.
1304
1305Our future work will address the comparison of the lifetime prediction and the real measurement thanks to a WSN testbed oriented towards network lifetime characterization.
1306The technical based proposed model will be compared to real measurement of the battery behavior.
1307Finally, we will accentuate our efforts on the scheduling methods optimization with the goal of very-large scale and reliable network lifetime estimation.
1308
1309% use section* for acknowledgement
1310\section*{Acknowledgment}
1311%Liam McNamara (SICS), Beshr Al Nahas (SICS).
1312
1313
1314% Can use something like this to put references on a page
1315% by themselves when using endfloat and the captionsoff option.
1316\ifCLASSOPTIONcaptionsoff
1317  \newpage
1318\fi
1319
1320
1321
1322% trigger a \newpage just before the given reference
1323% number - used to balance the columns on the last page
1324% adjust value as needed - may need to be readjusted if
1325% the document is modified later
1326%\IEEEtriggeratref{8}
1327% The "triggered" command can be changed if desired:
1328%\IEEEtriggercmd{\enlargethispage{-5in}}
1329
1330% references section
1331
1332% can use a bibliography generated by BibTeX as a .bbl file
1333% BibTeX documentation can be easily obtained at:
1334% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
1335% The IEEEtran BibTeX style support page is at:
1336% http://www.michaelshell.org/tex/ieeetran/bibtex/
1337%\bibliographystyle{IEEEtran}
1338% argument is your BibTeX string definitions and bibliography database(s)
1339%\bibliography{IEEEabrv,../bib/paper}
1340%
1341% <OR> manually copy in the resultant .bbl file
1342% set second argument of \begin to the number of references
1343% (used to reserve space for the reference number labels box)
1344\bibliographystyle{IEEEtran}
1345\bibliography{bib}
1346
1347% biography section
1348%
1349% If you have an EPS/PDF photo (graphicx package needed) extra braces are
1350% needed around the contents of the optional argument to biography to prevent
1351% the LaTeX parser from getting confused when it sees the complicated
1352% \includegraphics command within an optional argument. (You could create
1353% your own custom macro containing the \includegraphics command to make things
1354% simpler here.)
1355%\begin{biography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{mshell}}]{Michael Shell}
1356% or if you just want to reserve a space for a photo:
1357
1358\begin{IEEEbiography}{Wilfried Dron}
1359Biography text here.
1360\end{IEEEbiography}
1361
1362% if you will not have a photo at all:
1363\begin{IEEEbiographynophoto}{Khalil Hachicha}
1364Biography text here.
1365\end{IEEEbiographynophoto}
1366
1367% insert where needed to balance the two columns on the last page with
1368% biographies
1369%\newpage
1370
1371\begin{IEEEbiographynophoto}{Patrick Garda}
1372Biography text here.
1373\end{IEEEbiographynophoto}
1374
1375% You can push biographies down or up by placing
1376% a \vfill before or after them. The appropriate
1377% use of \vfill depends on what kind of text is
1378% on the last page and whether or not the columns
1379% are being equalized.
1380
1381%\vfill
1382
1383% Can be used to pull up biographies so that the bottom of the last one
1384% is flush with the other column.
1385%\enlargethispage{-5in}
1386
1387
1388
1389% that's all folks
1390\end{document}
1391
1392
Note: See TracBrowser for help on using the repository browser.