Changeset 133 for Publications


Ignore:
Timestamp:
Mar 21, 2014, 2:17:20 PM (11 years ago)
Author:
dron
Message:

Merging from original to the journal template

File:
1 edited

Legend:

Unmodified
Added
Removed
  • Publications/Wilfried Dron/JOURNAL - Scheduling Method for Network Lifetime Estimation of WSN/Scheduling Method for Network Lifetime Estimation of Wireless Sensor Network.tex

    r132 r133  
    388388% correct bad hyphenation here
    389389\hyphenation{op-tical net-works semi-conduc-tor}
    390 
     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\newcommand{\pmsg}{{\textit{PowerMessage}}}
     403\newcommand{\imsg}{{\textit{InterfaceMessage}}}
     404\newcommand{\smsg}{{\textit{SignalMessage}}}
     405\newcommand{\dmsg}{{\textit{DigitalMessage}}}
     406\newcommand{\amsg}{{\textit{AnalogMessage}}}
     407\newcommand{\cmsg}{{\textit{ControlMessage}}}
     408\newcommand{\phymsg}{{\textit{PhysicalMessage}}}
     409\newcommand{\fm}{{{FM}}}
     410\newcommand{\pmm}{{{PM}}}
     411\newcommand{\phym}{{{PhyM}}}
     412
     413\newcommand{\warn}{\textcolor{red}{\textbf{[REF]\space}}}
     414\newcommand{\tuple}[1]{\ensuremath{\left \langle #1 \right \rangle }}
     415\newcommand{\todo}[1]{\textcolor{blue}{{\bf Todo --\xspace}{\em #1}}}
     416\newcommand{\ie}{{\it i.e.},\xspace}
     417\newcommand{\eg}{{\it e.g.},\xspace}
     418\newcommand{\etal}{{\it et al.}\xspace}
     419\newcommand{\cf}{{\it c.f.},\xspace}
     420
     421\newcommand{\sa}{{\textit{SA}}}
     422\newcommand{\fed}{{\textit{FED}}}
     423\newcommand{\sued}{{\textit{SUED}}}
     424\newcommand{\ffs}{{\textit{FFS}}}
    391425
    392426\begin{document}
     
    394428% paper title
    395429% can use linebreaks \\ within to get better formatting as desired
    396 \title{Bare Demo of IEEEtran.cls for Journals}
     430\title{Scheduling Methods for Network Lifetime Estimation of Wireless Sensor Networks}
    397431%
    398432%
     
    406440%
    407441
    408 \author{Michael~Shell,~\IEEEmembership{Member,~IEEE,}
    409         John~Doe,~\IEEEmembership{Fellow,~OSA,}
    410         and~Jane~Doe,~\IEEEmembership{Life~Fellow,~IEEE}% <-this % stops a space
    411 \thanks{M. Shell is with the Department
    412 of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta,
    413 GA, 30332 USA e-mail: (see http://www.michaelshell.org/contact.html).}% <-this % stops a space
    414 \thanks{J. Doe and J. Doe are with Anonymous University.}% <-this % stops a space
    415 \thanks{Manuscript received April 19, 2005; revised January 11, 2007.}}
     442\author{Wilfried~Dron,~\IEEEmembership{Member,~IEEE,}
     443        Khalil~Hachicha,~\IEEEmembership{Fellow,~OSA,}
     444        and~Patrick~Garda,~\IEEEmembership{Life~Fellow,~IEEE}% <-this % stops a space
     445\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.
     446F-75005, Paris, France;
     447e-mail: \texttt{[wilfried.dron; khalil.hachicha; patrick.garda]@lip6.fr}.}% <-this % stops a space
     448\thanks{Manuscript received Month Day, Year; revised Month Day, Year.}}
    416449
    417450% note the % following the last \IEEEmembership and also \thanks -
     
    436469
    437470% The paper headers
    438 \markboth{Journal of \LaTeX\ Class Files,~Vol.~6, No.~1, January~2007}%
    439 {Shell \MakeLowercase{\textit{et al.}}: Bare Demo of IEEEtran.cls for Journals}
     471\markboth{Transactions on COMPUTER-AIDED DESIGN of Integrated Circuits and Systems,~Vol.~X, No.~Y, Month~Year}%
     472{}
     473%{Shell \MakeLowercase{\textit{et al.}}: Bare Demo of IEEEtran.cls for Journals}
    440474% The only time the second header will appear is for the odd numbered pages
    441475% after the title page when using the twoside option.
     
    469503\begin{abstract}
    470504%\boldmath
    471 The abstract goes here.
     505The network lifetime is a major constraint for the design of WSN's hardware and software.
     506%While several simulation tools are focused on power consumption estimation, the network lifetime has been estimated using an ideal battery model.
     507While several simulation tools are focused on estimating power consumption, the lifetime is commonly computed using a simple ideal battery model.
     508As a consequence, issues related with the use of a more realistic (non-ideal) battery model are not addressed yet.
     509Considering the error that is made in node's lifetime estimation using an ideal battery model (up to 40\%), specifications-based models have been implemented to achieve more reliable predictions.
     510In this context, we introduce four scheduling methods to address the challenges relative to such battery models.
     511These methods aim to manage energy transactions between the wireless node model and a non-ideal battery model.
     512%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.
     513Each of our methods is analyzed and compared through a typical temperature sensing application case.
     514We conducted several simulations considering power consumption estimation, simulation performances, node lifetime estimation and scalability.
     515Comparison of the obtained results highlights two methods, one more accurate but, rather slow, whereas the other is strongly scalable but less accurate.
    472516\end{abstract}
    473 % IEEEtran.cls defaults to using nonbold math in the Abstract.
    474 % This preserves the distinction between vectors and scalars. However,
    475 % if the journal you are submitting to favors bold math in the abstract,
    476 % then you can use LaTeX's standard command \boldmath at the very start
    477 % of the abstract to achieve this. Many IEEE journals frown on math
    478 % in the abstract anyway.
    479517
    480518% Note that keywords are not normally used for peerreview papers.
    481519\begin{IEEEkeywords}
    482 IEEEtran, journal, \LaTeX, paper, template.
     520battery, lifetime estimation, wsn, OMNeT++, scheduling.
    483521\end{IEEEkeywords}
    484522
     
    501539
    502540\section{Introduction}
    503 % The very first letter is a 2 line initial drop letter followed
    504 % by the rest of the first word in caps.
    505 %
    506 % form to use if the first word consists of a single letter:
    507 % \IEEEPARstart{A}{demo} file is ....
    508 %
    509 % form to use if you need the single drop letter followed by
    510 % normal text (unknown if ever used by IEEE):
    511 % \IEEEPARstart{A}{}demo file is ....
    512 %
    513 % Some journals put the first two words in caps:
    514 % \IEEEPARstart{T}{his demo} file is ....
    515 %
    516 % Here we have the typical use of a "T" for an initial drop letter
    517 % and "HIS" in caps to complete the first word.
    518 \IEEEPARstart{T}{his} demo file is intended to serve as a ``starter file''
    519 for IEEE journal papers produced under \LaTeX\ using
    520 IEEEtran.cls version 1.7 and later.
    521 % You must have at least 2 lines in the paragraph with the drop letter
    522 % (should never be an issue)
    523 I wish you the best of success.
    524 
    525 \hfill mds
     541\IEEEPARstart{T}{he} network lifetime is a key parameter of the wireless sensor network characterization~\cite{lifetime}.
     542It reflects the time while the network can operate properly according to application-defined constraints.
     543%Even if almost every application defines its own constraints, the network lifetime cannot be estimated without being able to estimate the node's lifetime.
     544Even if almost every application defines its own constraints, the network lifetime is estimated using the individual node's lifetime information.
     545Since 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.
     546
     547Nodes are battery-powered, thus the power consumption of the node and its battery characteristics are both necessary to determine its lifetime.
     548The power consumption profile is easily accessible from hardware measurements~\cite{wsn_energy} whereas it is more challenging to extract battery characteristics.
     549Hence, it is common to use an ideal battery model to model the node's power source.
     550This model is known as a battery with a linear discharge curve and a fixed output voltage.
     551Far 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.
     552%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.
     553To obtain more accurate lifetime estimation, another battery model, closer to the real battery behavior, is required.
     554It can be either based on experimental measurements or technical specifications.
     555To remain consistent using such a model, electrical laws have to be applied.
     556Therefore, it is important to pay attention to the way power transactions between battery and supplied components are acheived.
     557In other words, the scheduling of the energy transactions trough the simulated time is crucial (\cf Fig.~\ref{archi_methods}).
     558%As a consequence, the scheduling of the energy transactions among the battery and the electronic components models is important.
     559%Actually, it has a strong impact over the node's lifetime prediction.
     560%In this article, we show that the way this scheduling is achieved impact significantly the lifetime estimation.
     561%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.
     562%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.
     563
     564In this context, we introduce four scheduling methods to schedule the energy transactions in a modeled wireless sensor network node.
     565%We show that these methods are influencing the node lifetime estimation.
     566We show that the way this scheduling is achieved impact significantly the lifetime estimation showing difference in the obtained results that reaches 11.7\%.
     567%Moreover, the simulation's performance is also impacted, bounding the uses of certain methods to small-sized networks or short lifetime modeling.
     568As 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.
     569This article is structured as follows.
     570The second section hold the background of this work.
     571The scheduling methods principles are explained in the section 3.
     572The fourth section address the implementation of these methods in OMNeT++ trough a WSN framework that is oriented toward power consumption estimation.
     573Finally, the two last sections hold respectively the simulation results and the discussion of these results.
     574
     575\begin{figure}
     576\begin{center}
     577\includegraphics[scale=0.35]{architecture.pdf}
     578\caption{\label{archi_methods}
     579\textbf{Application example of the scheduling methods:}
     580Here, \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.
     581}
     582\end{center}
     583\end{figure}
     584
     585\section{Background}
     586The scheduling method for energy transactions have not been addressed yet, thus there is no previous work on that subject.
     587However, there are related works that are dealing with the power consumption estimation issues for the wireless sensor network simulation.
     588Since the node lifetime estimation relies on the battery models as well it is important to give a brief introduction to the battery behavior.
     589In that purpose, this section holds a short background about the battery behavior before addressing the core-related works.
     590
     591\subsection{Battery Behavior and Modeling} \label{sect:battery_desc}
     592The batteries are electrochemical power sources.
     593In contrast with the wired power sources, the amount of energy that they carry is limited.
     594This 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.
     595Considering a battery under use, its residual varies with the ambient temperature and the instantaneous current draw.
     596In other words, the available amount of energy change over the time according to the aforementioned factors.
     597The battery's \textit{nominal current} (set by the manufacturer) represent the ``normal operation'' current limit under continuous draw.
     598The term \textit{effective capacity} stands for the battery's capacity that is really available given a set of condition (\eg specific instantaneous current draw and a temperature).
     599Furthermore, their supply voltage varies as well with temperature and instantaneous current draw but also with the residual.
     600As a consequence, a specific current draw can produce a drift in the battery's supply voltage value.
     601According to the ohm law, this drift will change the current draw itself leading to a new drift.
     602%Considering a resistive circuit, the voltage value would reach an equilibrium which is not the case considering regulated system like voltage regulators for instance.
     603%All these assumptions were experimentally validated.
     604
     605A first study highlights the fact that the way in which the components are drawing the current has a strong influence in the \textsl{effective capacity}~\cite{battery_char}.
     606These observations were confirmed by a more recent work that characterized commercial Li-Ion batteries behaviors through real measurements~\cite{battery_char_new}.
     607In this work, {K. Mikhaylov} and {J. Tervonen} observed again that the available capacity of the battery depends mainly on the instant current draw under constant temperature.
     608Another article that focuses on remaining capacity measurements agrees on the same conclusion~\cite{remaining_capacity_measurement}.
     609This 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.
     610
     611More battery centered work were achieved to reach a better understanding of the battery properties.
     612Among 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}.
     613As mentioned, when a strong current is drawn from the battery, its \textsl{effective capacity} decrease.
     614In other words, its actual available energy is lower than the nominal value.
     615This assumption is valid for a current draw that remains the same until the end of the battery life.
     616If, for instance, the current draw decrease to a value that is beyond the battery's ``nominal current'', the battery will ``recover'' some capacity.
     617
     618To summarize, there are strong evidences that explain the limitations of ideal battery model.
     619While this model is extremely flexible and fast thanks to the fact that it is not dependent on any phenomena, it is highly inaccurate and does not reproduce the behavior of a real battery.
     620
     621\subsection{Simulation and Modeling Environments}
     622There are several simulators and frameworks that enable the power consumption estimation.
     623Among 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.
     624TOSSIM~\cite{tossim_ws} is, for instance, a network simulator dedicated to Tiny-OS~\cite{tinyos}.
     625This simulator is extended by many further work.
     626The most noticeable are Power-TOSSIM~\cite{powertossim_ws} and mTOSSIM~\cite{mtossim}.
     627Power-TOSSIM enables the power consumption to be computed after the simulation ends.
     628In contrast, mTOSSIM go further allowing the lifetime to be estimated.
     629It does so using a super-capacitor to model the power supply of the nodes.
     630The super-capacitor behavior is very different from battery behavior (\cf Section~\ref{sect:battery_desc}).
     631As a consequence, this model cannot be used to estimate the lifetime of nodes equipped with batteries.
     632
     633%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.
     634%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.
     635%Furthermore, none of them is providing a node lifetime estimation or only based on ideal battery model.
     636%As a consequence, these works are out of the scope of this paper.
    526637 
    527 \hfill January 11, 2007
    528 
    529 \subsection{Subsection Heading Here}
    530 Subsection text here.
    531 
    532 % needed in second column of first page if using \IEEEpubid
    533 %\IEEEpubidadjcol
    534 
    535 \subsubsection{Subsubsection Heading Here}
    536 Subsubsection text here.
    537 
    538 
    539 % An example of a floating figure using the graphicx package.
    540 % Note that \label must occur AFTER (or within) \caption.
    541 % For figures, \caption should occur after the \includegraphics.
    542 % Note that IEEEtran v1.7 and later has special internal code that
    543 % is designed to preserve the operation of \label within \caption
    544 % even when the captionsoff option is in effect. However, because
    545 % of issues like this, it may be the safest practice to put all your
    546 % \label just after \caption rather than within \caption{}.
    547 %
    548 % Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
    549 % option should be used if it is desired that the figures are to be
    550 % displayed while in draft mode.
    551 %
    552 %\begin{figure}[!t]
     638Regarding 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}.
     639Some of them are able to estimate power consumption thanks to extension called \textit{frameworks}.
     640However, the goal of these environments is to deal with network modeling issues more than network lifetime estimation.
     641The 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}.
     642As a consequence, several~\textit{power-aware} framework were developed over the previous years.
     643Energy Model~\cite{modeling_energy}, Pawis~\cite{pawis_fm_2} and Energy Framework~\cite{energy_fm} were thus introduced.
     644Unfortunately a common short-coming of these framework is that none of them provides a non-ideal battery model.
     645
     646Nevertheless, this short-coming was partially covered in an extension of the Energy Framework.
     647In their article, K. Mikhaylov and J. Tervonen were presenting a battery model~\cite{energy_fm_2} that was validated through measurement of real battery.
     648Unfortunately, this validation does not consider battery supply voltage variations due to the current draw.
     649Furthermore, it neglects the internal resistance of the battery and the relaxation effect.
     650A 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$\%.
     651%Their first conclusion is the fact that using an ideal battery model leads to an over-evaluation of the battery lifetime of almost $40$\%.
     652%Unfortunately, the techniques that were used to schedule the transaction between the battery model and the components model were not presented.
     653%Moreover, the simulation case that was chosen was limited to a simple resistive model in which the supply voltage drifts were not considered.
     654%As a result, it is difficult to re-use this work as a base for the network lifetime estimation.
     655A last power-aware framework for OMNeT++ was introduced~\cite{newcas}.
     656The battery model that is provided by the authors was build following technical specifications.
     657Finally, 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.
     658To address this issue, they introduced a periodical scheduling method called \textit{Fixed Frequency Sampling} method.
     659
     660%This latest framework was selected to implement the scheduling method because of its unique component oriented architecture and the several proposed models.
     661%The following section is dedicated to the description of the methods.
     662%Therefore, the firstly introduced scheduling method \textit{Fixed Frequency Sampling} will be exposed again in a more detailed way.
     663
     664\section{Scheduling Methods} \label{sec:schedul_meth}
     665Our scheduling methods can be used in any structure that model one to N battery-supplied components.
     666Modeling of the supply voltage and the instantaneous current draw is the only requirement that could limit their application.
     667The architecture that is considered here is composed of one to N components model and a battery that supply them (\cf Fig.\ref{archi_methods}).
     668A concrete application case is added as example after the general descriptions.
     669% in order to expose the differences between every scheduling method.
     670Integration of these scheduling algorithms is explained as the conclusion of the section.
     671
     672%%%%% METHODS DESCRIPTION
     673\begin{figure}
     674\begin{center}
     675\includegraphics[scale=0.45]{schedule_FFS.pdf}
     676\caption{\label{figure1}
     677\textbf{Fixed frequency sampling method states graphic:}
     678This graph shows the principle of the \ffs\xspace method.
     679It appears that the battery update are triggered periodically (each \textit{T} second) after the step~5.
     680}
     681\end{center}
     682\end{figure}
     683
     684\subsection{Fixed Frequency Sampling method (FFS)}
     685The \textit{Fixed Frequency Sampling} method (shorten to \ffs) was introduced into prior work~\cite{newcas}.
     686This method relies on a periodic update of the battery's parameters and the current drawn by the components.
     687Figure~\ref{figure1} is a state chart that describe its algorithm.
     688First of all, the battery initiates the simulation by sending its supply voltage value to the component.
     689This allow the components to turn into ON mode.
     690Then, they sends back their averaged instantaneous current consumption over the previous period (which is null for the very first period).
     691The battery residual and the supply voltage are then updated according to the received current draw value.
     692Finally, 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 second).
     693If the battery is depleted, it sends a $0.0$V supply voltage that turns the components into OFF mode.
     694
     695\subsection{Self Updating Event Driven method (SUED)}
     696In contrast with the \ffs\xspace method, the \textit{Self Updating Event Driven} method takes into account every current draw changes instantaneously.
     697The \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.
     698When the simulation starts, the battery sends its supply voltage value to the components.
     699The components send back their instantaneous current draw.
     700Then the supply voltage and the remaining capacity of the battery are updated using the received value of the current draw.
     701This current draw value is stored.
     702If none of the components change their instantaneous current draw value, the battery will be updated every \textit{T} seconds.
     703When a component changes its power mode (\eg ON $\rightarrow$ POWER DOWN), the corresponding instantaneous current draw value is sent to the battery.
     704Then, the regular updating process is interrupted.
     705The battery residual and the supply voltage are updated for the time elapsed from the last battery's update using the latest stored current draw value.
     706Finally, the just received instantaneous current draw value is stored and the regular updating process starts again by scheduling the next update at $t+T$.
     707
     708\begin{figure}
     709\begin{center}
     710\includegraphics[scale=0.45]{schedule_FED.pdf}
     711\caption{\label{figure3}
     712\textbf{Fast event driven method state graphic:}
     713This graph shows the principle of the \fed\xspace method.
     714In this method, the battery update are triggered by each changes in the operating state of the components.
     715}
     716\end{center}
     717\end{figure}
     718
     719\subsection{Fast Event Driven method (FED)}
     720The \textit{Fast Event Driven} method is derived from the ``formal'' event driven simulation technique.
     721As a consequence, the battery updates are triggered by each current draw changes.
     722The sate chart depicted Figure~\ref{figure3} represent the behavior of this scheduling method.
     723The battery initiates the simulation by sending its supply voltage value.
     724As a consequence, the components change their state from OFF to ON and send back their associated instantaneous current draw value.
     725Alike the \sued\xspace method, this value is stored in the battery model.
     726When the component changes its state again, this value will be updated.
     727Before storing the just received value, a battery update is processed.
     728%Actually, it will estimate and check its new residual value considering the time elapsed from the previous update.
     729This update consist of checking and computing the new battery's residual considering the time elapsed from the previous update.
     730Battery's supply voltage value is also updated but using the new instantaneous current draw value and the residual that has just been estimated.
     731Finally, this supply voltage value is sent to the component.
     732
     733Since the \fed\xspace scheduling method do not update the battery periodically, using this method can lead to node operating without energy.
     734If there is no event that makes the current draw change such as power mode changing, the simulation can run even if the battery is totally depleted at a certain point.
     735%As a consequence, another mechanism is required.
     736A way to avoid this issue is to ``plan'' the end of the battery life assuming that there will be no more event.
     737To be consistent, this end of life forecast has to be re-evaluated each time the current draw value changes.
     738In other words, the battery's end of life has to be re-planned each time that a battery update is triggered.
     739
     740\subsection{Self Adaptive method (SA)}
     741The \textit{Self Adaptive} method is based on both a periodical update schedule and a event-driven like schedule.
     742%Actually, the previously introduced method are sensitive to the time and/or to the current draw changes events.
     743In addition, the \sa\xspace method is sensitive to the current draw value.
     744Battery behavior observations allow us to make the following assumption: The discharge curve can be separated in two areas, a pseudo-linear area (before the \textit{nominal current} value) and a non-linear area (after the \textit{nominal current} value).
     745The border between these two areas is the \textit{nominal current draw} (\cf Sec.~\ref{sect:battery_desc}).
     746As a consequence, the \sa\xspace scheduling method changes the way it triggers battery's and components updates according to the instantaneous current draw value.
     747When 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.
     748In 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.
     749
     750On the one hand, this scheduling algorithm is able to enhance the accuracy of the estimation when it is necessary (when the battery model is strongly non-linear) and on the other hand, it is able to run the simulation faster when there is no need to (when the battery model is almost linear).
     751
     752\subsection{Application example}
     753The chosen application example is a single component that is supplied by a battery.
     754The functional behavior of this component is not discussed here since the meaningful information is its current draw consumption.
     755As a consequence, the power mode states are the only information that are considered.
     756The following mode sequence was arbitrarily chosen:
     757\begin{itemize}
     758\item OFF $\rightarrow$ ON $\rightarrow$ POWER DOWN $\rightarrow$ ON.
     759\end{itemize}
     760The Figure~\ref{time} is a representation of each scheduling method applied to our example.
     761%Each of the four graphs illustrates the results of its method applied to the example case.
     762All the graph are time aligned making the difference between each scheduling method easier to understand.
     763
     764\begin{figure}
     765\begin{center}
     766\includegraphics[scale=0.45]{method_global.pdf}
     767\caption{\label{time}
     768\textbf{Application example of the scheduling methods:}
     769This figure is a time graph that shows the application of each scheduling method to our application example.
     770The \ffs\xspace method trigger battery update according to its sampling period \textit{T}.
     771The \sued\xspace method trigger as well the update of the battery each \textit{T} seconds but also when a component changes its operating state.
     772The \fed\xspace method only triggers battery updates on the components change.
     773The \sa\xspace method use periodic update when precision is required and event driven updates when less precision is needed.
     774}
     775\end{center}
     776\end{figure}
     777
     778Figure~\ref{time}a is the graph that represent the \ffs\xspace method application.
     779The updates of the battery and the component's current draw changes are asynchronous.
     780Moreover, the supply voltage updates are delayed by one period in comparison with the current draw updates.
     781In 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.
     782Figure~\ref{time}b represent the application of the \sued\xspace method.
     783In contrast with the \ffs\xspace method, it appears that the battery's updates are synchronized with the current draw changes.
     784The periodical update is also observable while the component is in LOW POWER mode.
     785Alike the \ffs\xspace method, the supply voltage updates are also delayed.
     786
     787The application of the \fed\xspace method is plotted in the graph Figure~\ref{time}c.
     788%The fact that the battery updates happen only in synchronization with the component's power mode changes is highlighted.
     789The graph highlight that the battery updates happen only in synchronization with the component's power mode changes.
     790The Figure~\ref{time}d illustrates the application of the \sa\xspace method.
     791This method is sensitive to the current draw value in respect with the battery characteristics.
     792The 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.
     793Consequently, periodical updates are achieved when the components is in ON mode whereas there is no update while the component is in LOW POWER mode.
     794
     795%\section{Modeling and integration in the Framework}
     796\subsection{Framework Integration}\label{implementation}
     797As mentioned previously, we chose to implement our scheduling method in an OMNeT++ framework~\cite{newcas}.
     798%As mentioned previously, a power aware simulation environment was chosen to implement the scheduling methods \cite{newcas}.
     799%Actually, this environment is an OMNeT++'s framework that allows the wireless sensor node to be described with each of its electronic components.
     800This environment allows a node to be described with every of its electronic components.
     801Each component is described using two levels of description: a functional and a hardware one.
     802Practically, the components are described using a functional model and a power model.
     803Regarding the battery, a ``technical specification based'' model is provided.
     804
     805The integration of our scheduling methods requires few modifications in the provided models.
     806Theoretically, each power model should be modified according to the chosen scheduling method.
     807Fortunately, the simulated architecture use a DC/DC step-down converter to keep the supply voltage between the battery and the components steady.
     808Therefore we consider the following assumption: the voltage do not change between the components' power model and the step down converter's output.
     809%WD: to moove in the discussion
     810%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.
     811Consequently to this assumption, the only models that requires to be modified are the battery model and the converter model.
     812
     813To ensure reliable simulation results, mechanisms of the modified components were isolated into functions that takes every necessary information as parameters.
     814Even if it needed additional formalizing and coding efforts, this approach allows us to described the models independently from the scheduling method.
     815%The way and the sequence order in which the function are called determined the scheduling method.
     816
     817\section{Modelling and simulation configuration}
     818\subsection{Battery Modelling}
     819The battery model that was used in the simulation is a model of the CR2032 battery from Panasonic~\cite{cr2032}.
     820The 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}).
     821%\begin{figure}
     822%\begin{center}
     823%\includegraphics[scale=1.1]{cr2032_capacity_vs_load_resistance.pdf}
     824%\caption{\label{cr2032}Panasonic CR2032: \textit{capacity vs. load resistance characteristic} \cite{cr2032} }
     825%\end{center}
     826%\end{figure}
     827The impact of the temperature variation on the battery were not considered in the following simulation case.
     828As a consequence, the battery's \textit{effective capacity} varies only with the instantaneous current draw.
     829\begin{figure}
     830\begin{center}
     831\includegraphics[scale=0.40]{eq_current_plot.pdf}
     832\caption{\label{eq_current}
     833\textbf{Equivalent and instantaneous current draw estimations:}
     834This 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}).
     835}
     836\end{center}
     837\end{figure}
     838
     839In this model, the capacity of the battery is considered as fixed.
     840Therefore, to model the impact of the instantaneous current draw on the \textit{relative capacity}, the equivalent current draw $i_{eq}(t)$ was considered.
     841It has been defined using the following equation:
     842\begin{equation}\label{ieq}
     843i_{eq}(t) = \frac{C_{nominal}}{C_{relative}(i(t))} \times i(t)
     844\end{equation}
     845Where $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.
     846The $i(t)$ is the instantaneous current expressed in mA.
     847The factor between $C_{nominal}$ and $C_{relative}$ is called the \textit{overdraw factor}.
     848Therefore, the equivalent current draw is expressed as a function of the present instantaneous current draw as depicted in the chart Figure~\ref{eq_current}.
     849This graph was plotted using a current draw ramp directly plugged in the battery model.
     850This battery modeling technique has the advantage of modeling both the \textit{effective capacity} and the \textit{relaxation} effects as well.
     851%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.
     852
     853The equation that is used to estimate the battery's residual $R$ at the $t+\Delta t$ instant is the following one:
     854\begin{equation}
     855R(t+\Delta t) = R(t) -  i_{eq}(t) \times \frac{\Delta t}{3600}
     856\end{equation}
     857Where $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.
     858Finally, the $3600$ value stands for the conversion of $\Delta t$ in hours.
     859
     860%\section{Simulation}
     861\subsection{Simulated Architecture}
     862The platform used as modeling base was a prototype under development.
     863It 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}.
     864The power supply is handled by 4 CR2032 batteries~\cite{cr2032} that are assembled in serial.
     865%The figure \ref{omnet} is a screen shot of the modelled node into the simulation environment.
     866%\begin{figure}
     867%\begin{center}
     868%\includegraphics[scale=0.55]{node_omnet.jpg}
     869%\caption{\label{omnet}Description of the node's architecture inside the WSN framework}
     870%\end{center}
     871%\end{figure}
     872The measurements that were used to build the MCU and the transceiver models are reported in Table~\ref{msp_meas}.
     873These measurements were made using a NI PXI-4071 ampere-meter integrated in a NI PXIe-1075 rack from National Instruments.
     874The used precision was seven and a half digits, the maximum precision of the device.
     875The measurements were achieved using a temperature regulated chamber from Binder.
     876The MCU firmware that was used to achieve this was the application that is embedded in the sensing node.
     877Consumption measurements of the MSP430 are not restricted to the core but include also the consumption of the whole chip.
     878
     879\begin{table}[h]
     880\centering
     881\subtable[MSP430]{
     882        \begin{tabular}{|c||c|c|c|c|}
     883                \hline
     884                \textit{Mode} & Active & ADC+LPM4 & LPM4 \\
     885                \hline
     886                Inst. current & 0.813mA & 0.326mA & 0.226mA \\
     887                \hline
     888        \end{tabular}
     889}
     890%\begin{tabular}{cccccccc}
     891 %& & & & & & &\\
     892%\end{tabular}
     893\subtable[CC2520]{
     894        \begin{tabular}{|c||c|c|c|c|c|c|}
     895                \hline
     896                \textit{Mode} & XOSC Off & Idle & RX & RX LP & TX-18dBm \\
     897                \hline
     898                Inst. current & 0.178mA & 1.776mA & 22.48mA & 18.79mA &  16.63mA\\
     899                \hline
     900        \end{tabular}
     901}
     902\smallskip
     903\caption{\label{msp_meas}{\bf Experimental measurements of the current draw}}
     904\end{table}
     905
     906Regarding the functional behavior, the application that is modeled is a typical temperature measuring scenario.
     907The network is organized in a star topology and the IEEE 802.15.4 protocol is used by the node to communicate.
     908The sensing node behavior is the following:
     909\begin{enumerate}
     910\item The node start to listen the channel to seek for a broadcast frame that comes from the central node;
     911\item Once it received the frame with the same PAN-ID and the expected source address, it acknowledge the subscription;
     912\item Every second it wakes up, takes a measure of the temperature and send it to the central node before going back to sleep.
     913\end{enumerate}
     914Each sensor has a time slot that is computed according to its own address, at the beginning of the run.
     915The central node is periodically broadcasting its subscription frame an turns into reception mode right after.
     916Therefore, its power consumption is high in comparison with the sensor node.
     917In the simulation, it is considered as being supplied by an ideal power source with infinite energy.
     918
     919\section{Results}
     920All along this section, several simulation cases and their results are presented.
     921The 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).
     922This choice is motivated by the simulation performances (\cf Sect.~\ref{sim_perfs}).
     923The 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.
     924Ubuntu LTS 12.04 was used as operating system.
     925The OMNeT++ version was the 4.3.
     926Simulator was configured to use only one core over eight in order to have no hardware acceleration that could biased the performance results.
     927%Each simulation case was run at least 10 times in order to verify the reliability of the obtained results.
     928
     929\subsection{Power consumption estimation}
     930The power consumption estimation results were obtained by simulating four instances of the same node for one hour of simulated time.
     931Each node implements a different method to schedule the power transaction between the batteries and the components.
     932As a reference, another simulation was run within the same conditions but using ideal battery models instead of CR2032 models.
     933The battery's residual value results for both simulations are presented in Table~\ref{residual_results}.
     934
     935\begin{table}[h]
     936\centering
     937\subtable[Ideal battery model, \textit{T}=50us]{
     938        \begin{tabular}{|c||c|c|c|c|}
     939        \hline
     940                & FFS & SUED & FED & SA\\
     941        %\hline
     942        %\multicolumn{5}{|c|}{Nodes with Ideal model (\textit{T}=50us)}  \\
     943        \hline
     944        Residual (mAh)&$\textbf{219.9273}$&$\textbf{219.9273}$&$\textbf{219.9273}$&$\textbf{219.9273}$\\
     945        %Consumed Cap. (mAh)&$0.0727$&$0.0727$&$0.0727$&$0.0727$\\
     946        Av. $i_{eq}(t)$ (uA)&$72.7$&$72.7$&$72.7$&$72.7$\\
     947        %Av. voltage (V)&$12.00$&$12.00$&$12.00$&$12.00$\\
     948        \hline
     949        \end{tabular}
     950        }
     951\subtable[CR2032 battery model, \textit{T}=50us]{
     952        \begin{tabular}{|c||c|c|c|c|}
     953        \hline
     954        & FFS & SUED & FED & SA\\
     955        %\hline
     956        %\multicolumn{5}{|c|}{Nodes with CR2032 model (\textit{T}=50us)}  \\
     957        \hline
     958        Residual (mAh)&$\textbf{219.9249}$&$\textbf{219.9248}$&$\textbf{219.9167}$&$\textbf{219.9137}$\\
     959        %Consumed Cap. (mAh)& $0.0751$& $0.0752$& $0.0833$& $0.0863$\\
     960        Av. $i_{eq}(t)$ (uA)& $75.1$& $75.2$& $83.3$& $86.3$\\
     961        \hline
     962\end{tabular}
     963}
     964\smallskip
     965\caption{\label{residual_results}
     966{\bf Battery's residual estimation results:}
     967{\textnormal{
     968The 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.
     969In contrast, they are different for each scheduling method using the technical specification based battery model}
     970}
     971}
     972\end{table}
     973
     974%\begin{table}[h]
    553975%\centering
    554 %\includegraphics[width=2.5in]{myfigure}
    555 % where an .eps filename suffix will be assumed under latex,
    556 % and a .pdf suffix will be assumed for pdflatex; or what has been declared
    557 % via \DeclareGraphicsExtensions.
    558 %\caption{Simulation Results}
    559 %\label{fig_sim}
    560 %\end{figure}
    561 
    562 % Note that IEEE typically puts floats only at the top, even when this
    563 % results in a large percentage of a column being occupied by floats.
    564 
    565 
    566 % An example of a double column floating figure using two subfigures.
    567 % (The subfig.sty package must be loaded for this to work.)
    568 % The subfigure \label commands are set within each subfloat command, the
    569 % \label for the overall figure must come after \caption.
    570 % \hfil must be used as a separator to get equal spacing.
    571 % The subfigure.sty package works much the same way, except \subfigure is
    572 % used instead of \subfloat.
    573 %
    574 %\begin{figure*}[!t]
    575 %\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
    576 %\label{fig_first_case}}
    577 %\hfil
    578 %\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
    579 %\label{fig_second_case}}}
    580 %\caption{Simulation results}
    581 %\label{fig_sim}
    582 %\end{figure*}
    583 %
    584 % Note that often IEEE papers with subfigures do not employ subfigure
    585 % captions (using the optional argument to \subfloat), but instead will
    586 % reference/describe all of them (a), (b), etc., within the main caption.
    587 
    588 
    589 % An example of a floating table. Note that, for IEEE style tables, the
    590 % \caption command should come BEFORE the table. Table text will default to
    591 % \footnotesize as IEEE normally uses this smaller font for tables.
    592 % The \label must come after \caption as always.
    593 %
    594 %\begin{table}[!t]
    595 %% increase table row spacing, adjust to taste
    596 %\renewcommand{\arraystretch}{1.3}
    597 % if using array.sty, it might be a good idea to tweak the value of
    598 % \extrarowheight as needed to properly center the text within the cells
    599 %\caption{An Example of a Table}
    600 %\label{table_example}
    601 %\centering
    602 %% Some packages, such as MDW tools, offer better commands for making tables
    603 %% than the plain LaTeX2e tabular which is used here.
    604 %\begin{tabular}{|c||c|}
     976%\caption{\label{consumption_result}Power consumption estimation}
     977%\begin{tabular}{|c||c|c|c|c|}
    605978%\hline
    606 %One & Two\\
     979%\multicolumn{5}{|c|}{Simulated time = 60 minutes}  \\
    607980%\hline
    608 %Three & Four\\
     981% & FFS & SUED & FED & SA\\
     982%\hline
     983%\hline
     984%\multicolumn{5}{|c|}{Power Consumption: Ideal model}  \\
     985%\hline
     986%Residual (mAh) & $\textbf{219.9273}$ & $\textbf{219.9273}$ & $\textbf{219.9273}$ & $\textbf{219.9273}$\\
     987%Consumed C. (mAh) &$0.0727$&$0.0727$&$0.0727$& $0.0727$\\
     988%Av. eq. current (uA) &$72.7$&$72.7$&$72.7$&$72.7$\\
     989%Av. voltage (V)&$12.00$&$12.00$&$12.00$&$12.00$\\
     990%\hline
     991%\hline
     992%\multicolumn{5}{|c|}{Power Consumption: CR2032 model}  \\
     993%\hline
     994%Residual (mAh) & $\textbf{219.9249}$& $\textbf{219.9248}$ & $\textbf{219.9167}$& $\textbf{219.9137}$\\
     995%Consumed Energy (mAh) & $0.0751$& $0.0752$& $0.0833$& $0.0863$\\
     996%\hline
     997%Max current (mA) & $3.99$ & $3.99$& $3.92$& $3.99$\\
     998%Min current (mA) & $0.073$ & $0.073$& $0.071$& $0.071$\\
     999%\hline
     1000%Max eq. current (mA) & $7.359$& $7.359$& $7.033$& $7.359$\\
     1001%Min eq. current (mA) & $0.70$& $0.073$& $0.071$& $0.071$\\
     1002%Av. eq. current (uA) & $75.1$& $75.2$& $83.3$& $86.3$\\
     1003%\hline
     1004%Max voltage (V) & $12.0$& $12.0$& $12.0$& $12.0$\\
     1005%Min voltage (V) & $9.98$& $9.98$& $10.67$& $9.98$\\
     1006%Av. voltage (V) & $10.62$& $10.54$& $11.40$& $10.70$\\
    6091007%\hline
    6101008%\end{tabular}
    6111009%\end{table}
    6121010
    613 
    614 % Note that IEEE does not put floats in the very first column - or typically
    615 % anywhere on the first page for that matter. Also, in-text middle ("here")
    616 % positioning is not used. Most IEEE journals use top floats exclusively.
    617 % Note that, LaTeX2e, unlike IEEE journals, places footnotes above bottom
    618 % floats. This can be corrected via the \fnbelowfloat command of the
    619 % stfloats package.
    620 
    621 
     1011The 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)).
     1012Actually, 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.
     1013In contrast, the results obtained by the node that were equipped with CR2032 models are not equal (\cf Tab.~\ref{residual_results}(b)).
     1014These variations in the power consumption estimations highlight the fact that scheduling method do influence the residual estimation.
     1015Consequently, the node lifetime estimation is also influenced even if each battery model and each component model is the same.
     1016
     1017\begin{table}[h]
     1018\begin{center}
     1019\begin{tabular}{|c||c|c|c|c|}
     1020\hline
     1021 & FFS & SUED & FED & SA\\
     1022\hline
     1023Max $i(t)$ (mA) & $3.99$ & $3.99$& $3.92$& $3.99$\\
     1024Min $i(t)$ (mA) & $0.073$ & $0.073$& $0.071$& $0.071$\\
     1025\hline
     1026Max $i_{eq}(t)$ (mA) & $7.359$& $7.359$& $7.033$& $7.359$\\
     1027Min $i_{eq}(t)$ (mA) & $0.70$& $0.073$& $0.071$& $0.071$\\
     1028%\hline
     1029%Av. eq. current (uA) & $75.1$& $75.2$& $83.3$& $86.3$\\
     1030\hline
     1031\end{tabular}
     1032\end{center}
     1033\smallskip
     1034\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.}}
     1035\end{table}
     1036
     1037Focusing on the detailed results, the residual estimation that is obtained using the \ffs\xspace method is the highest one with $219.9429$ mAh.
     1038Firstly, the current draw is integrated over the \textit{T} period.
     1039This is comparable to a \textit{low pass filter} that cuts the edges of the current draw spikes.
     1040Secondly, the supply voltage value is the one that has been computed using the previous current draw value.
     1041The impact of the voltage drifts are consequently lowered.
     1042The \sued\xspace method suffers from the same observations, except for the spike transition thanks to the synchronized current updates.
     1043This 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).
     1044To achieve better results with these scheduling methods, the Shannon theorem should be observed.
     1045In other word, the sampling period should be at least twice short as the shorter power mode changing of the system.
     1046In the present case, the shorter period is around 5us.
     1047Therefore a 2.5us period is the minimum period length regarding the accuracy and the precision of the estimation.
     1048Unfortunately, using such a small period results in an extremely slow simulation as presented in the next section.
     1049
     1050%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.
     1051Another 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.
     1052These variations could be explained by the numeric precision.
     1053Since 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.
     1054Actually, this phenomena is partially observable considering the current draw and the equivalent current draw estimation (\cf Tab.~\ref{current_results}).
     1055
     1056\begin{table}[h]
     1057\centering
     1058\begin{tabular}{|c||c|c|c|c|}
     1059        \hline
     1060        & FFS & SUED & FED & SA\\
     1061        \hline
     1062        Max voltage (V) & $12.0$& $12.0$& $12.0$& $12.0$\\
     1063        Min voltage (V) & $9.98$& $9.98$& $10.67$& $9.98$\\
     1064        %Av. voltage (V) & $10.62$& $10.54$& $11.40$& $10.70$\\
     1065        \hline
     1066\end{tabular}
     1067\smallskip
     1068\caption{\label{voltage_results}
     1069{{\bf Battery supply voltage estimation:}
     1070\textnormal{The estimated supply voltage values are the same except for the FED method.}
     1071}
     1072}
     1073\end{table}
     1074
     1075Focusing 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.
     1076This is a result of the event driven-like algorithm.
     1077The current drawn by the components is updated immediately when one of them changes its power mode.
     1078Once 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.
     1079This 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}).
     1080The observation of the current draw and the equivalent current draw in the Table~\ref{current_results} are confirming this assumption.
     1081Actually, 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.
     1082
     1083The sampling mechanism of the \sa\xspace method allows the battery model to react almost instantly to every current draw variation.
     1084Finally, 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}).
     1085This highlights once again the fact that updates are driven by the components' power state changes.
     1086
     1087\subsection{Simulation performance} \label{sim_perfs}
     1088The simulation performance results were obtained by running the nodes for five minutes of CPU time (300 seconds).
     1089Two series of simulation were conducted.
     1090The first one consist of running one single node and its base station at a time.
     1091Each scheduling method is therefore evaluated on its own.
     1092The second one consist of the same principle but running a network of five identical nodes.
     1093The main results are presented in Table~\ref{residual_results}.
     1094In this table there is several abbreviation:
     1095\begin{itemize}
     1096\item the simulated time: \textit{\textbf{Sim.time}}
     1097\item the average simulated sec. per sec. ratio: \textit{\textbf{Av.Sim.s/s}}
     1098\item the number of simulated events: \textit{\textbf{N.ev.}}
     1099\item the average number of event per sec.: \textit{\textbf{Ev/s}}
     1100\end{itemize}
     1101
     1102
     1103The time indications give basic idea on how much of CPU time it would take if the simulation has to reach a specific time.
     1104The event indications give idea about the load of the simulation kernel.
     1105It allows to figure out the raw performances and eventually deduce the impact of porting the scheduling methods to another simulation environment.
     1106\begin{table}[h]
     1107\centering
     1108\begin{tabular}{|c||c|c|c|c|}
     1109\hline
     1110\multicolumn{5}{|c|}{CPU time = 5min (300 s)}  \\
     1111\hline
     1112 & FFS & SUED & FED & SA\\
     1113\hline
     1114\hline
     1115\multicolumn{5}{|c|}{1 Node}  \\
     1116\hline
     1117Av.Sim.s\slash s & \textbf{2.695} & \textbf{5.474} & \textbf{6699} & \textbf{3342}\\
     1118\hline
     1119Sim.time & 13min:28s& 27min:22s & 23d:6h & 11d:22h\\
     1120N.ev. &$48\times10^6$&$98\times10^6$&$80\times10^6$&$82\times10^6$ \\
     1121Ev\slash s &$1.6\times10^5$&$3.2\times10^5$&$2.7\times10^5$&$2.7\times10^5$ \\
     1122\hline
     1123\multicolumn{5}{|c|}{5 Nodes}  \\
     1124\hline
     1125Av.Sim.s\slash s & \textbf{0.576} & \textbf{1.218} & \textbf{1330} & \textbf{713.5}\\
     1126\hline
     1127Sim.time & {2min:52s}&{6min:5s}& {4d:14h}& {2d:11h}\\
     1128N.ev. &$51.8\times10^6$&$109.6\times10^6$&$86.6\times10^6$&$89.3\times10^6$ \\
     1129Ev\slash s &$1.7\times10^5$&$3.6\times10^5$&$2.8\times10^5$&$2.9\times10^5$ \\
     1130\hline
     1131\end{tabular}
     1132\smallskip
     1133\caption{\label{perf_table}
     1134{{\bf Simulation performance (\textit{T}=50us)}:
     1135\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}
     1136}
     1137}
     1138\end{table}
     1139
     1140Regarding the simulated time for a single node, the results are quite clear.
     1141The \ffs\xspace and the \sued\xspace method reach $13$ and $27$ minutes respectively.
     1142In contrast, the \sa\xspace method is able to simulate almost $12$ days in $5$ minutes of CPU time.
     1143The \fed\xspace method outperforms by reaching $23$ days of simulated time and almost $2$h simulated per second.
     1144The results of the 5 nodes are following the same trends.
     1145The 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.
     1146The \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.
     1147Finally, the best performances were obtained using the \sa\xspace and the \fed\xspace method with respectively 2 days and 4 days of simulated time.
     1148
     1149As a consequence, the \ffs\xspace and the \sued\xspace method are not considered in the following experiments.
     1150This 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.
     1151
     1152\subsection{Node lifetime estimation}
     1153The 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.
     1154This scenario focuses on the real node lifetime as it has been defined in the beginning of this article.
     1155If, 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.
     1156Therefore the node can be considered as dead or not reliable enough from the point of view of the network.
     1157
     1158As mentioned before, only the \fed\xspace and the \sa\xspace method were considered in this experiments.
     1159Making the same run with the \ffs\xspace method would have require approximately 1 month of continuous run.
     1160The 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).
     1161This estimation implicitly assumes that the battery is able to supply the node until its total depletion, which is not the case.
     1162The node lifetime estimation results are presented in the Table~\ref{sim_table_2}.
     1163First analysis of these results reveals that estimation obtained by the \fed\xspace and the \sa\xspace methods are significantly different.
     1164The \fed\xspace node lasted three months and twelve days while the \sa\xspace node lasted three months and one day.
     1165This 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}$.
     1166
     1167\begin{table}[h]
     1168\centering
     1169\begin{tabular}{|c||c|c|}
     1170\hline
     1171 & FED & SA\\
     1172\hline
     1173\hline
     1174\multicolumn{3}{|c|}{Node lifetime (\textit{T}=50us)}  \\
     1175\hline
     1176Lifetime &  3m:12d:7h:29min:0s & 3m:1d:8h:50min:29s\\
     1177\hline
     1178Residual (mAh) & $0.0176$ & $\textbf{16.8062}$\\
     1179\hline
     1180Simulation time &  22min:25s & 38min:18s\\
     1181Av.Sim.s\slash s &  $6700$ & $3510$\\.
     1182N.ev. &$3.6\times10^8$ &$64\times10^8$ \\
     1183Ev\slash s &$2.7\times10^5$ & $2.8\times10^5$\\
     1184\hline
     1185%Gain Factor  & $98.5$ & $1.35$\\
     1186%\hline
     1187\end{tabular}
     1188\smallskip
     1189\caption{\label{sim_table_2}
     1190{\bf Node lifetime estimation performance}:
     1191\textnormal{The difference of 11.7\% between the two methods highlight the fact that scheduling methods do influence the lifetime estimation.}
     1192}
     1193\end{table}
     1194
     1195A 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.
     1196It 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.
     1197Considering the technical specification, the battery should not be able to handle the current spike of a RF frame transmission at this depletion level.
     1198Consequently, the results obtained by the \sa\xspace method are more realistic.
     1199Unfortunately, there is no means to measure the remaining capacity in a real battery to have a comparison point.
     1200Further experiments about battery discharge in this particular application case will be conducted in order to experimentally validate this hypothesis.
     1201
     1202\subsection{Scalability}
     1203The last exposed experiment was conducted to evaluate the scalability of the \fed\xspace and the \sa\xspace scheduling methods.
     1204The simulated time was set to $24$h hours.
     1205Each simulation contained a complete network with $10$ to $250$ nodes and a central station.
     1206The obtained result are presented in the table \ref{sim_table_3}.
     1207
     1208\begin{table}[h]
     1209\centering
     1210\begin{tabular}{|c||c|c|}
     1211\hline
     1212\multicolumn{3}{|c|}{Simulated time = 24h (\textit{T}=50us)}\\
     1213\hline
     1214 &FED&SA\\
     1215\hline
     121610 nodes & $2$min $11$s & $4$min $6$s \\
     1217%\cdashline{2-3}
     121850 nodes & $13$min $57$s & $24$min $3$s \\
     1219%\cdashline{2-3}
     1220100 nodes & $36$min $17$s & $56$min $52$s\\
     1221%\cdashline{2-3}
     1222250 nodes & $2$h $58$min & $3$h $45$min \\
     1223\hline
     1224\end{tabular}
     1225\smallskip
     1226\caption{\label{sim_table_3}
     1227{\bf Scalability comparison: simulation time for 10 to 250 nodes}:
     1228\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.}
     1229}
     1230\end{table}
     1231
     1232First 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.
     1233Actually, simulating 250 nodes should be 25 times longer than simulating 10 nodes.
     1234Simulating 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.
     1235This is explained by the fact that each additional node adds a significant traffic load.
     1236A 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.
     1237This difference seems to decrease when the size of the network increase.
     1238With a 250 nodes network, using the \sa\xspace method takes only 26\% more time than the \fed\xspace method.
     1239
     1240More generally, these results are highlighting the high scalability of the \fed\xspace method in comparison with the \sa\xspace method that is slower.
    6221241
    6231242\section{Conclusion}
    624 The conclusion goes here.
    625 
    626 
    627 
    628 
    629 
    630 % if have a single appendix:
    631 %\appendix[Proof of the Zonklar Equations]
    632 % or
    633 %\appendix  % for no appendix heading
    634 % do not use \section anymore after \appendix, only \section*
    635 % is possibly needed
    636 
    637 % use appendices with more than one appendix
    638 % then use \section to start each appendix
    639 % you must declare a \section before using any
    640 % \subsection or using \label (\appendices by itself
    641 % starts a section numbered zero.)
    642 %
    643 
    644 
    645 \appendices
    646 \section{Proof of the First Zonklar Equation}
    647 Appendix one text goes here.
    648 
    649 % you can choose not to have a title for an appendix
    650 % if you want by leaving the argument blank
    651 \section{}
    652 Appendix two text goes here.
    653 
     1243In 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.
     1244Our first experiments revealed that the scheduling methods do have an impact on battery's lifetime estimations and thus on the node lifetime prediction.
     1245As 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.
     1246In contrast, event-driven based method is the fastest scheduling method whereas it appears to lead to inaccurate results.
     1247Finally, 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.
     1248
     1249Our future work will address the comparison of the lifetime prediction and the real measurement thanks to a WSN testbed oriented towards network lifetime characterization.
     1250The technical based proposed model will be compared to real measurement of the battery behavior.
     1251Finally, we will accentuate our efforts on the scheduling methods optimization with the goal of very-large scale and reliable network lifetime estimation.
    6541252
    6551253% use section* for acknowledgement
    6561254\section*{Acknowledgment}
    657 
    658 
    659 The authors would like to thank...
     1255%Liam McNamara (SICS), Beshr Al Nahas (SICS).
    6601256
    6611257
     
    6901286% set second argument of \begin to the number of references
    6911287% (used to reserve space for the reference number labels box)
    692 \begin{thebibliography}{1}
    693 
    694 \bibitem{IEEEhowto:kopka}
    695 H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
    696   0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.
    697 
    698 \end{thebibliography}
     1288\bibliographystyle{IEEEtran}
     1289\bibliography{bib}
    6991290
    7001291% biography section
     
    7091300% or if you just want to reserve a space for a photo:
    7101301
    711 \begin{IEEEbiography}{Michael Shell}
     1302\begin{IEEEbiography}{Wilfried Dron}
    7121303Biography text here.
    7131304\end{IEEEbiography}
    7141305
    7151306% if you will not have a photo at all:
    716 \begin{IEEEbiographynophoto}{John Doe}
     1307\begin{IEEEbiographynophoto}{Khalil Hachicha}
    7171308Biography text here.
    7181309\end{IEEEbiographynophoto}
     
    7221313%\newpage
    7231314
    724 \begin{IEEEbiographynophoto}{Jane Doe}
     1315\begin{IEEEbiographynophoto}{Patrick Garda}
    7251316Biography text here.
    7261317\end{IEEEbiographynophoto}
Note: See TracChangeset for help on using the changeset viewer.