path: root/2019-ICA3PP.org

#+TITLE: Estimating the end-to-end energy consumption of low-bandwidth IoT applications for WiFi devices

#+EXPORT_EXCLUDE_TAGS: noexport
#+STARTUP: hideblocks
#+OPTIONS: H:5 author:nil email:nil creator:nil timestamp:nil skip:nil toc:nil ^:nil
#+LATEX_CLASS: llncs
#+LATEX_HEADER: \usepackage{hyperref}
#+LATEX_HEADER: \usepackage{booktabs}
#+LATEX_HEADER: \usepackage{subfigure}
#+LATEX_HEADER: \usepackage{graphicx}
#+LATEX_HEADER: \usepackage{xcolor}
#+LATEX_HEADER: \author{
#+LATEX_HEADER:       Loic Guegan and
#+LATEX_HEADER:       Anne-Cécile Orgerie\\  
#+LATEX_HEADER: }
#+LATEX_HEADER: \institute{Univ Rennes, Inria, CNRS, IRISA, Rennes, France\\
#+LATEX_HEADER: Emails: loic.guegan@irisa.fr, anne-cecile.orgerie@irisa.fr
#+LATEX_HEADER: }





#+BEGIN_EXPORT latex
\newcommand{\hl}[1]{\textcolor{red}{#1}}
#+END_EXPORT

#+BEGIN_EXPORT latex
\begin{abstract}
Information and Communication Technology takes a growing part in the 
worldwide energy consumption. One of the root causes of this increase 
lies in the multiplication of connected devices. Each object of the 
Internet-of-Things often does not consume much energy by itself. Yet, 
their number and the infrastructures they require to properly work 
have leverage. In this paper, we combine simulations and real 
measurements to study the energy impact of IoT devices. In particular, 
we analyze the energy consumption of Cloud and telecommunication 
infrastructures induced by the utilization of connected devices, And 
we propose an end-to-end energy consumption model for these devices. 
\end{abstract}
#+END_EXPORT


* Introduction 
In 2018, Information and Communication Technology (ICT) was estimated
to absorb around 3% of the global energy consumption
\cite{ShiftProject}. This consumption is estimated to grow at a rate
of 9% per year \cite{ShiftProject}. This alarming growth is explained
by the fast emergence of numerous applications and new ICT
devices. These devices supply services for smart building, smart
factories and smart cities for instance. Through connected sensors
producing data, actuators interacting with their environment and
communication means -- all being parts of the Internet of Things (IoT)
-- they provide optimized decisions. 

This increase in number of devices implies an increase in the energy
needed to manufacture and utilize them. Yet, the overall energy bill
of IoT also comprises indirect costs, as it relies on computing and 
networking infrastructures that consume energy to enable smart
services. Indeed, IoT devices communicate with Cloud computing
infrastructures to store, analyze and share their data.  

In February 2019, a report by Cisco stated that ``IoT connections will
represent more than half (14.6 billion) of all global connected
devices and connections (28.5 billion) by 2022" \cite{Cisco2019}. This
will represent more than 6% of global IP traffic in 2022, against 3%
in 2017 \cite{Cisco2019}. This increasing impact of IoT devices on
Internet connections induces a growing weight on ICT energy
consumption.  

The energy consumption of IoT devices themselves is only the top of
the iceberg: their use induce energy costs in communication and cloud
infrastructures. In this paper, we estimate the overall energy
consumption of an IoT device environment by combining simulations and
real measurements. We focus on a given application with low bandwidth
requirement and we evaluate its overall energy consumption: from the
device, through telecommunication networks, and up to the Cloud data
center hosting the application. From this analysis, we derive an
end-to-end energy consumption model that can be used to assess the
consumption of other IoT devices.

While some IoT devices produce a lot of data, like smart vehicles for
instance, many others generate only a small amount of data, like smart
meters. However, the scale matters here: many small devices can end up
producing big data volumes. As an example, according to a report
published by Sandvine in October 2018, the Google Nest Thermostat is
the most significant IoT device in terms of worldwide connections: it
represents 0.16% of all connections, ranging 55th on the list of
connections \cite{Sandvine2018}. As a comparison, the voice assistants
Alexa and Siri are respectively 97th and 102nd with 0.05% of all
connections \cite{Sandvine2018}. This example highlights the growing
importance of low-bandwidth IoT applications on Internet
infrastructures, and consequently on their energy consumption. 

In this paper, we focus on IoT devices for low-bandwidth applications
such as smart meters or smart sensors. These devices send few
data periodically to cloud servers, either to store them or to get
computing power and take decisions. This is a first step towards a
comprehensive characterization of the global IoT energy
footprint. While few studies address the energy consumption of
high-bandwidth IoT applications \cite{li_end--end_2018}, to the best
of our knowledge, none of them targets low-bandwidth applications,
despite their growing importance on the Internet infrastructures.

Low-bandwidth IoT applications, such as the Nest Thermostat, often
relies on sensors powered by batteries. For such sensors, reducing
their energy consumption is a critical target. Yet, we argue that
end-to-end energy models are required to estimate the overall impact
of IoT devices, and to understand how to reduce their complete energy
consumption. Without such models, one could optimize the consumption
of on-battery devices at a heavier cost for cloud servers and
networking infrastructures, resulting on an higher overall energy 
consumption. Using end-to-end models could prevent these unwanted
effects. 

Our contributions include:
- a characterization of low-bandwidth IoT applications;
- an analysis of the energy consumption of a low-bandwidth IoT
  application including the energy consumption of the WiFi IoT device
  and the consumption induced by its utilization on the Cloud and
  telecommunication infrastructures;
- an end-to-end energy model for low-bandwidth IoT applications
  relying on WiFi devices.

The paper is organized as follows. Section \ref{sec:sota} presents the
state of the art. The low-bandwidth IoT application is characterized
in Section \ref{sec:usec}, and details on its architecture are
provided in Section \ref{sec:model}. Section \ref{sec:eval} provides
our experimental results combining real measurements and
simulations. Section \ref{sec:discuss} discusses the key findings an
the end-to-end energy model. Finally, Section \ref{sec:cl} concludes
this work and presents future work. 



* Related Work 
#+LaTeX: \label{sec:sota}
** Energy consumption of IoT devices
The multiplication of smart devices and smart applications pushes the
limits of Internet: IoT is now used everywhere for home automation,
smart agriculture, e-health, smart cities, logistics, smart grids,
smart buildings, etc. \cite{Wang2016,Ejaz2017,Minoli2017}. IoT devices
are typically used to optimize processes and the envisioned
application domains include the energy distribution and management. It
can for instance help the energy management of product life-cycle
\cite{Tao2016}. Yet, few studies address the impact of IoT itself on
global energy consumption \cite{jalali_fog_2016,li_end--end_2018} or
CO2 emissions \cite{Sarkar2018}.  

The underlying architecture of these smart applications usually
includes sensing devices, cloud servers, user applications and
telecommunication networks. Concerning the computing part, the cloud
servers can either be located on Cloud data centers, on Fog
infrastructures located at the network edge, or on home gateways
\cite{Wang2016}. Various network technologies are employed by IoT
devices to communicate with their nearby gateway; either wired
networks with Ethernet or wireless networks: WiFi, Bluetooth, Near
Field Communication (NFC), ZigBee, cellular network (like 3G, LTE, 4G),
Low Power Wide Area Network (LPWAN),
etc. \cite{Samie2016,Gray2015}. The chosen technology depends on the
smart device characteristics and the targeted communication
performance. The Google Nest Thermostat can for instance use WiFi,
802.15.4 and Bluetooth \cite{Nest}. In this paper, we focus on WiFi as
it is broadly available and employed by IoT devices
\cite{Samie2016,ns3-energywifi}.  

Several works aim at reducing the energy consumption of the device
transmission \cite{Andres2017} or improving the energy efficiency of
the access network technologies \cite{Gray2015}. An extensive
literature exists on increasing the lifetime of battery-based wireless
sensor networks \cite{Wang2016}. Yet, IoT devices present more
diversity than typical wireless sensors in terms of hardware
characteristics, communication means and data production patterns.

Based on real measurements, previous studies have proposed energy
models for IoT devices. Yet, these models are specific to a given kind
of IoT device or a given transmission technology. 
Martinez et al. provide energy consumption measurements for wireless
sensor networks using SIGFOX transmissions and employed for
smart-parking systems \cite{Martinez2015}. Wu et al. implement an
energy model for WiFi devices in the well-known ns3 network simulator 
\cite{ns3-energywifi}. 


** Energy consumption of network and cloud infrastructures
IoT architecture rely on telecommunication networks and Cloud
infrastructures to provide services. The data produced by IoT devices
are stored and exploited by servers located either in Cloud data
centers or Fog edge sites. While studies exist on the energy
consumption of network and cloud infrastructures in general
\cite{Ehsan}, they do not consider the specific case of IoT devices.
To the best of our knowledge, no study estimates the direct impact of
IoT applications on the energy consumption of these infrastructures.

Most work focusing on energy consumption, Cloud architecture and IoT
applications tries to answer the question: where to locate data
processing in order to save energy
\cite{jalali_fog_2016}, to reduce the CO2 impact \cite{Sarkar2018}, or
to optimize renewable energy consumption \cite{li_end--end_2018}.   

In both cases, the network and cloud infrastructures, attributing the
energy consumption to a given user or application is a challenging
task. The complexity comes from the shared nature of these
infrastructures: a given Ethernet port in the core of the network
processes many packets coming from a high number of sources
\cite{jalali_fog_2016}. Moreover, the employed equipment is not power
proportional: servers and routers consume consequent amounts of
energy while being idle
\cite{mahadevan_power_2009,li_end--end_2018}.
The power consumed by a device is divided into two parts: a dynamic
part that varies with traffic or amount of computation to process, and
a static part that is constant and dissipated even while being idle
\cite{Ehsan}. This static part implies that a consequent energy cost
of running an application on a server is due to the device being
simply powered on. Consequently, sharing these static energy costs
among all the concerned users requires an end-to-end model
\cite{li_end--end_2018}.  

In this paper, we focus on IoT devices using WiFi transmission and
generating low data volumes. Our model, extracted from real
measurements and simulations, can be adapted to other kinds of devices
and transmission technologies. 



* Characterization of low-bandwidth IoT applications
   #+LaTeX: \label{sec:usec}

   In this section, we detail the characteristics of the considered IoT
   application. While the derived model is more generic, we focus on a
   given application to obtain a precise use-case with accurate power
   consumption measurements.  

   The Google Nest Thermostat relies on five sensors: temperature,
   humidity, near-field activity, far-field activity and ambient light
   \cite{Nest}. Periodical measurements, sent through wireless
   communications on the Internet, are stored on Google data centers and
   processed to learn the home inhabitants habits. The learned behavior
   is employed to automatically adjust the home temperature managed by
   heating and cooling systems.

       #+BEGIN_EXPORT latex
       \begin{figure}
         \centering
         \includegraphics[width=0.5\linewidth]{./plots/home.png}
         \caption{Overview of IoT devices.}
         \label{fig:IoTdev}
       \end{figure}
       #+END_EXPORT

   Each IoT device senses periodically its environment. Then, it sends
   the produced data through WiFi (in our context) to its gateway or
   Access Point (AP). The AP is in charge of transmitting the data to the
   cloud using the Internet. Figure \ref{fig:IoTdev} illustrates this
   architecture. Several IoT devices can share the same AP in a
   home. We consider low-bandwidth applications where devices produces
   several network packets during each sensing period. The transmitting
   frequency can vary from one to several packet sent per minute
   \cite{Cisco2019}. 

   #+BEGIN_COMMENT
   The IoT part is composed of an Access Point (AP), connected to several sensors using WIFI. In the
   system, the IoT part is considered as the part where the system data are created. In fact, the
   data life cycle start when the sensors records their respective local temperature at a frequency
   $f$ and the local timestamp. Then, these data are transmitted through the network along with an
   arbitrary sensor id of 128 bits. Finally, the AP is in charge to transmit the data to the cloud
   using the network part.

   The network part is considered as the medium that link the IoT part to the cloud. It is composed
   of several network switches and router and it is considered to be a wired network.

   #+END_COMMENT

   We consider that the link between the AP and the Cloud is composed of
   several network switches and routers using Ethernet as shown in Figure
   \ref{fig:parts}. The number of routers on the path depends on the
   location of the server, either in a Cloud data center or in a Fog site
   at the edge of the network.

   We assume that the server hosting the application data for the users
   belongs to a shared cloud facility with classical service level
   agreement (SLA). The facility provides redundant storage and computing
   means as virtual machines (VMs). A server can host several VMs at the
   same time.

   #+BEGIN_EXPORT latex
   \begin{figure}
     \centering
     \includegraphics[width=0.6\linewidth]{./plots/parts2.png}
     \caption{Overview of the IoT architecture.}
     \label{fig:parts}
   \end{figure}
   #+END_EXPORT

   In the following, we describe the experimental setup, the results and
   the end-to-end model. For all these steps, we decompose the overall
   IoT architecture into three parts: the IoT device part, the networking
   part and the cloud part, as displayed on Figure \ref{fig:parts}. 


* Experimental setup 
  #+Latex: \label{sec:model}
  In this section, we describe the experimental setup employed to
  acquire energy measurements for each of the three parts of our
  system model. The IoT and the network parts are modeled
  through simulations. The Cloud part is modeled using real
  servers connected to wattmeters. In this way, it is possible to
  evaluate the end-to-end energy consumption of the system. 

** IoT Part
   In the first place, the IoT part is composed of several sensors connected to an Access Point (AP)
   which form a cell. This cell is studied using the ns3 network
   simulator. In the experimental scenario, we setup
   between 5 and 15 sensors connected to the AP using WiFi 5GHz 802.11n. The node are placed
   randomly in a rectangle of $400m^2$ around the AP which corresponds
   to a typical use case for a home environment. All
   the cell nodes employ the default WIFI energy model provided by ns3. The different
   energy values used by the energy model are provided in Table \ref{tab:params}. These parameters
   were extracted from previous work\cite{halperin_demystifying_nodate,li_end--end_2018} On
   IEEE 802.11n. Besides, we suppose that the energy source of each
   nodes is not limited during the experiments. Thus each node
   can communicate until the end of all the simulations.

   As a scenario, sensors send 192 bits packets to the AP composed of: \textbf{1)} A 128 bits
   sensors id \textbf{2)} A 32 bits integer representing the temperature \textbf{3)} An integer
   timestamp representing the temperature sensing date. They are stored as time series. The data are
   transmitted immediately at each sensing interval $I$ that we vary from 1s to 60s. Finally, the AP is in
   charge of relaying data to the cloud via the network part.
   
   #+BEGIN_EXPORT latex
   \begin{table}[]
     \centering
     \caption{Simulations Energy Parameters}
     \label{tab:wifi-energy}
     \subtable[IoT part]{
       \begin{tabular}{@{}lr@{}}
         Parameter      & Value  \\ \midrule
         Supply Voltage & 3.3V   \\
         Tx             & 0.38A  \\
         Rx             & 0.313A \\
         Idle           & 0.273A \\ \bottomrule
     \end{tabular}}
     \hspace{0.3cm}
     \subtable[Network part]{
       \label{tab:net-energy}
       \begin{tabular}{@{}lr@{}}
         Parameter  & Value \\ \midrule
         Idle       & 0.00001W           \\ 
         Bytes (Tx/Rx)  & 3.4nJ           \\ 
         Pkt (Tx/Rx)    & 192.0nJ         \\ \bottomrule
       \end{tabular}
     }
     \label{tab:params}
   \end{table}
   #+END_EXPORT

** Network Part
   The network part represents the a network section starting from the AP to the Cloud excluding the
   server. It is also modeled into ns3. We consider the server to be 9 hops away from the AP with a
   typical round-trip latency of 100ms from the AP to the server
   \cite{li_end--end_2018}. Each node from the AP to the Cloud 
   is a network switch with static and dynamic network energy consumption. The first 8
   hops are edge switches and the last one is consider to be a core router as mentioned in
   \cite{jalali_fog_2016}. ECOFEN \cite{orgerie_ecofen:_2011} is used to model the energy
   consumption of the network part. ECOFEN is an ns3 network energy module dedicated to wired
   networks. It is based on an energy-per-bit and energy-per-packet
   model for the dynamic energy consumption
   \cite{sivaraman_profiling_2011,Serrano2015}, and it includes also a static energy consumption.
   The different values used to instantiate the ECOFEN energy model for the
   network part are shown in left part of Table \ref{tab:params} and come from previous work
   \cite{cornea_studying_2014-1}.

** Cloud Part
   Finally, to measure the energy consumed by the Cloud part, we use a real server from the large-scale
   test-bed Grid'5000. Grid'5000 provides clusters composed of several nodes which
   are connected to wattmeters. The wattmeters provide 50
   instantaneous power measurements per second and per server. This
   way, we can benefit from real energy measurements. The server used
   in the experiment embeds two Intel Xeon E5-2620 v4 processors with
   64 GB of RAM and 600GB 
   of disk space on a Linux based operating system. This server is configured to use KVM as
   virtualization mechanism. We deploy a classical Debian x86_64 distribution on the Virtual Machine
   (VM) along with a MySQL database. We use different amounts of allocated memory for the VM namely
   1024MB/2048MB/4096MB to highlight its effects on the server energy
   consumption. The server only hosts this VM in order to easily isolate its
   power consumption.

   #+BEGIN_EXPORT latex
   \begin{figure}
     \centering
     \includegraphics[width=0.45\linewidth]{./plots/g5k-xp.png}
     \caption{Grid'5000 experimental setup.}
     \label{fig:g5kExp}
   \end{figure}
   #+END_EXPORT

   The data sent by the IoT devices are simulated using another
   server from the same cluster. This server is in charge of sending
   the data packets to the VM hosting the application in order to fill
   its database. In the following, each data packet coming from an IoT
   device and addressed to the application VM is called a request. Consequently, it is easy to vary the
   different application characteristics namely: \textbf{1)} The number
   of requests, to virtually
   add/remove sensors \textbf{2)} The requests interval, to study the
   impact of the transmitting frequency. Figure \ref{fig:g5kExp} presents this simulation
   setup.




* Evaluation 
#+LaTeX: \label{sec:eval}

** IoT and Network Power Consumption
In this section, we analyze the experimental results.
   In a first place, we start by studying the impact of the sensors' transmission frequency on their
   energy consumption. To this end, we run several simulations in ns3 with 15 sensors using
   different transmission frequencies. The results provided by Table
   \ref{tab:sensorsSendIntervalEffects} show that the transmission frequency has a very low impact
   on the energy consumption and on the average end-to-end application delay. It has an impact of
   course, but it is very limited. This due to the fact that in such a scenario with very small
   number of communications spread over the time, sensors don't have to contend for accessing to the
   Wifi channel.
   
   #+BEGIN_EXPORT latex
   % Please add the following required packages to your document preamble:
   % \usepackage{booktabs}
   \begin{table*}[]
   \centering
   \caption{Sensors transmission interval effects with 15 sensors}
   \label{tab:sensorsSendIntervalEffects}
   \begin{tabular}{@{}lrrrrr@{}}
   \toprule
   Transmission Interval        & 10s            & 30s            & 50s       & 70s       & 90s      \\ \midrule
   Sensor Power     & 13.517\hl{94}W & 13.517\hl{67}W & 13.51767W & 13.51767W & 13.517\hl{61}W \\
   Network Power     & 0.441\hl{88}W & 0.441\hl{77}W & 0.44171W & 0.44171W & 0.441\hl{71}W \\
   Application Delay & 0.09951s       & 0.10021s       & 0.10100s  & 0.10203s  & 0.10202s  \\ \bottomrule
   \end{tabular}
   \end{table*}
   #+END_EXPORT
   

   Previous work \cite{li_end--end_2018} on a similar scenario shows that increasing application
   accuracy impacts strongly the energy consumption in the context of data stream analysis. However,
   in our case, application accuracy is driven by the sensing interval and thus, the transmission
   frequency of the sensors.
In our case with small and sporadic network traffic, these results show that with a reasonable
   transmission interval, the energy consumption of the IoT and the
   network parts are almost not affected by the
   variation of this transmission interval. In fact, transmitted data are not large enough to
   leverage the energy consumed by the network.

   We then vary the number of sensors in the Wifi cell.
   The Figure \ref{fig:sensorsNumber} represents the energy consumed by each simulated part
   according to the number of sensors. It is clear that the energy consumed by the network is the
   dominant part. However, if the number of sensors is increasing, the energy consumed by the
   network can become smaller than the sensors part. In fact, deploying new
   sensors in the cell do not introduce much network load. To this end, sensors energy consumption
   can become dominant.
   
    #+BEGIN_EXPORT latex
    \begin{figure}
      \centering
      \includegraphics[width=0.5\linewidth]{./plots/numberSensors-WIFINET.png}
      \caption{Analysis of the variation of the number of sensors on the IoT/Network part energy consumption for a transmission interval of 10s.}
      \label{fig:sensorsNumber}
    \end{figure}
    #+END_EXPORT


** Cloud Energy Consumption
   In this end-to-end energy consumption study, cloud accounts for a huge part of the overall energy
   consumption. According a report \cite{shehabi_united_2016-1} On United States data center energy
   usage, the average Power Usage Effectiveness (PUE) of an hyper-scale data center is 1.2. Thus, in
   our analysis, all energy measurement on cloud server will account
   for this PUE. It means that the power consumption of the server is multiplied by
   the PUE to include the external energy costs like server cooling
   and data center facilities \cite{Ehsan}.

   #+BEGIN_EXPORT latex
   \begin{figure}
     \centering
     \includegraphics[width=0.8\linewidth]{./plots/vmSize-cloud.png}
     \caption{Server power consumption multiplied by the PUE (= 1.2) using 20 sensors sending data every 10s for various VM memory sizes}
     \label{fig:vmSize}
   \end{figure}
   #+END_EXPORT


   Firstly, we analyze the impact of the VM allocated memory on the server energy
   consumption. Figure \ref{fig:vmSize} depicts the server energy consumption according to the VM
   allocated memory for 20 sensors sending data every 10s. Note that
   the horizontal red line represents
   the average energy consumption for the considered sample of energy values. We can see that at
   each transmission interval, the server faces spikes of energy
   consumption. However, the amount of allocated memory to the VM
   does not significantly influence the server energy consumption. In
   fact, simple database requests do not need any particular 
   heavy memory accesses and processing time. Thus, remaining experiments are based on VM with 1024MB
   of allocated memory.

   Next, we study the effects of increasing the number of sensors on the server energy consumption.
   Figure \ref{fig:sensorsNumber-server} presents the results of the average server energy
   consumption when varying the number of sensors from 20 to 500, while Figure
   \ref{fig:sensorsNumber-WPS} presents the average server energy cost per sensor according to the
   number of sensors. These results show a clear linear relation between the number of sensors and
   the server energy consumption. Moreover, we can see that the more sensors we have per VM, the
   more energy we can save. In fact, since the server's idle power
   consumption is high (around 97 Watts), it is more
   energy efficient to maximize the number of sensors per server. As shown on Figure
   \ref{fig:sensorsNumber-WPS}, a significant amount of energy can be save when passing from 20 to
   300 sensors per VM. Note that these measurements are not the row
   measurements taken from the wattmeters: they include the PUE
   but they are not shared among all the VMs that could be hosted on this
   server. So, for the studied server, its static power consumption
   (also called idle consumption) is around 83.2 Watts and we consider
   a PUE of 1.2, this value is taken from \cite{shehabi_united_2016-1}}.

   #+BEGIN_EXPORT latex
   \begin{figure}
     \centering
     \subfigure[Average server energy consumption multiplied by the PUE (= 1.2)]{
       \includegraphics[width=0.4\linewidth]{./plots/sensorsNumberLine-cloud.png}
       \label{fig:sensorsNumber-server}
     }
     \hspace{0.5cm}
     \subfigure[Average sensors energy cost on the server hosting only our VM]{
       \includegraphics[width=0.4\linewidth]{./plots/WPS-cloud.png}
       \label{fig:sensorsNumber-WPS}
     }
     \caption{Server energy consumption multiplied by the PUE (= 1.2) for sensors sending data every 10s}
     \label{fig:sensorsNumber-cloud}
   \end{figure}
   #+END_EXPORT

   A last parameter can leverage server energy consumption, namely
   sensors transmission interval. In addition 
   to increasing the application accuracy, sensors transmission frequency increases network traffic and
   database accesses. Figure \ref{fig:sensorsFrequency} presents the impact on the server energy
   consumption when changing the transmission interval of 50 sensors
   to 1s, 10s and 30s. We can see that, the lower sensors transmission
   interval is, the more server energy consumption peaks
   occur. Therefore, it leads to an increase of the server energy consumption.

   #+BEGIN_EXPORT latex
   \begin{figure}
     \centering
     \includegraphics[scale=0.5]{plots/sendInterval-cloud.png}
     \caption{Server energy consumption multiplied by the PUE (= 1.2) for 50 sensors sending requests at different transmission interval.}
     \label{fig:sensorsFrequency}
   \end{figure}
   #+END_EXPORT
   
* End-To-End Consumption Model
#+LaTeX: \label{sec:discuss}
   
   To have an overview of the energy consumed by the overall system, it is important to consider the
   end-to-end energy consumption.
   We detail here the model used to attribute the energy
   consumption of our application for each part of the
   architecture. For a given IoT device, we have:
   1. For the IoT part, the entire consumption of the IoT device
      belongs to the system's accounted consumption.
   2. For the network part, the data packets generated by the IoT
      device travel through network switches, routers and ports that
      are shared with other traffic.
   3. For the cloud part, the VM hosting the data is shared with
      other IoT devices belonging to the same application and the
      server hosting the VM also hosts other VMs. Furthermore, the
      server belongs to a data center and takes part in the overall
      energy drawn to cool the server room.

   Concerning the IoT part, we include the entire IoT device power
   consumption. Indeed, in our targeted low-bandwidth IoT application,
   the sensor is dedicated to this application. From Table \ref{tab:params}, one can
   derive that the static power 
   consumption of one IoT sensor is around 0.9 Watts. Its dynamic part
   depends on the transmission frequency.
   
   Concerning the sharing of the network costs, for each router, we
   consider its aggregate bandwidth (on all the ports), its average
   link utilization and the share taken by our IoT application. For a
   given network device, we compute our share of the static energy
   part as follows: 
 
   #+BEGIN_EXPORT latex
   \[P_{static}^{netdevice} = \frac{P_{static}^{device} \times Bandwidth^{application}}{AggregateBandwidth^{device}
   \times LinkUtilization^{device}}\]
   #+End_EXPORT
  
   where $P_{static}^{device}$ is the static power consumption of the
   network device (switch fabrics for instance or gateway),
   $Bandwidth^{application }$ Is the bandwidth used by our IoT application,
   $AggregateBandwidth^{device }$ is the overall aggregated bandwidth of the
   network device on all its ports, and $LinkUtilization^{device}$ is the
   effective link utilization percentage. The $Bandwidth^{application }$
   depends on the transmission frequency in our use-case.
   The formula includes the
   link utilization in order to charge for the effective energy cost
   per trafic and not for the theoretical upper bound which is the
   link bandwidth. Indeed, using such an upper bound leads to greatly
   underestimate our energy part, since link utilization typically
   varies between 5 to 40% \cite{Hassidim2013,Zhang2016}.

   Similarly, for each network port, we take the share attributable to
   our application: the ratio of our bandwidth utilization over the
   port bandwidth multiplied by the link utilization and the overall
   static power consumption of the port. Table \ref{tab:netbidules}
   summarizes the parameters used in our model, they are taken from
   \cite{mahadevan_power_2009,Hassidim2013}. These are the parameters
   used in our formula to compute the values that we used in the
   simulations and that are presented in left part of Table \ref{tab:params}. 


   
   #+BEGIN_EXPORT latex
   \begin{table}[]
     \centering
     \caption{Network Devices Parameters}
     \label{tab:netbidules}
       \begin{tabular}{l|l}
         Device      & ~Parameters  \\ \midrule
         Gateway & ~Static power = 8.3 Watts, Bandwidth = 54Mbps, Utilization = 10\%   \\
         Core router & ~Static power = 555 Watts, 48 ports of 1 Gbps, Utilization = 25\% \\
         Edge switch~ & ~Static power = 150 Watts, 48 ports of 1 Gbps, Utilization = 25\% \\
         \bottomrule
     \end{tabular}
   \end{table}
   #+END_EXPORT



   For the sharing of the Cloud costs, we take into account the number
   of VMs that a server can host, the CPU utilization of a VM and the
   PUE. For a given Cloud server hosting our IoT application, we
   compute our share of the static energy part as follows: 

   #+BEGIN_EXPORT latex
   \[P_{static}^{Cloudserver} = \frac{P_{static}^{server} \times PUE^{DataCenter}}{HostedVMs^{server}}\]
   #+End_EXPORT
   
   Where $P_{static}^{server}$ is the static power consumption of the
   server, $PUE^{DataCenter}$ is the data center PUE, and
   $HostedVMs^{server}$ is the number of VMs a server can host. This last
   parameter should be adjusted in the case of VMs with multiple
   virtual CPUs. We do not
   consider here over-commitment of Cloud servers. Yet, the dynamic
   energy part is computed with the real dynamic measurements, so it
   accounts for VM over-provisioning and resource under-utilization.

   In our case, the Cloud server has 14 cores, which corresponds to
   the potential hosting of 14 small VMs with one virtual CPU each,
   and each vCPU is pinned to a server core. We consider that for
   fault-tolerance purpose, the IoT application has a replication
   factor of 2, meaning that two cloud servers store its database.

   The Figure \ref{fig:end-to-end} represents the end-to-end system
   energy consumption using the model described above while varying
   the number of sensors for a transmission interval of 10
   seconds. The values are extracted from the experiments presented in
   the previous section. 

   #+BEGIN_EXPORT latex
   \begin{figure}
     \centering
     \hspace{1cm}
     \includegraphics[scale=0.35]{plots/final.png}
     \label{fig:end-to-end}
     \caption{End-to-end network energy consumption using sensors interval of 10s}
   \end{figure}
   #+END_EXPORT
   

   Note that, for small-scale systems, with WiFi IoT devices, the IoT
   sensor part is dominant in the overall energy consumption. Indeed,
   the IoT application induces a very small cost on Cloud and network
   infrastructures compared to the IoT device cost. But, our model
   assumes that a single VM is handling multiple users (up to 300
   sensors), thus being energy-efficient. Conclusions would be
   different with one VM per user in the case of no over-commitment on
   the Cloud side. For the network infrastructure, in our case of
   low-bandwidth utilization (one data packet every 10 seconds), the
   impact is almost negligible.

   Another way of looking at these results is to observe that only for
   a high number of sensors (more than 300), the power consumption of Cloud and
   network parts start to be negligible (few percent). It means that,
   if IoT applications handle clients one by one (i.e. one VM per
   client), the impact is high on cloud and network part if they have
   only few sensors. The energy efficiency is really poor for only few
   devices: with 20 IoT sensors, the overall energy cost to handle these
   devices is almost doubled compared to the energy consumption of the IoT devices
   themselves. Instead of increasing the number of sensors, which
   would result in a higher overall energy consumption, one should
   focus on reducing the energy consumption of IoT devices, especially
   WiFi devices which are common due to WiFi availability
   everywhere. One could also focus on improving the energy cost of
   Cloud and network infrastructure for low-bandwidth applications and
   few devices.



* Conclusion 
#+LaTeX: \label{sec:cl}

Information and Communication Technology takes a growing part in the 
worldwide energy consumption. One of the root causes of this increase 
lies in the multiplication of connected devices. Each object of the 
Internet-of-Things often does not consume much energy by itself. Yet, 
their number and the infrastructures they require to properly work 
have leverage.

In this paper, we combine simulations and real 
measurements to study the energy impact of IoT devices. In particular, 
we analyze the energy consumption of Cloud and telecommunication 
infrastructures induced by the utilization of connected devices.
Through the fine-grain analysis of a given low-bandwidth IoT device
periodically sending data to a Cloud server using WiFi,
we propose an end-to-end energy consumption model. 
This model provides insights on the hidden part of the iceberg: the
impact of IoT devices on the energy consumption of Cloud and network
infrastructures. On our use-case, we show that for a given sensor, its
larger energy consumption is on the sensor part. But the impact on the
Cloud and network part is huge when using only few sensors with
low-bandwidth applications.
Consequently, with the
IoT exploding growth, it becomes necessary to improve the energy
efficiency of applications hosted on Cloud infrastructures and of IoT devices.
Our future work includes studying other types of IoT wireless
transmission techniques that would be more energy-efficient. We also
plan to study other
IoT applications in order to increase the applicability of our model
and provide advice for increasing the energy-efficiency of IoT infrastructures.



\bibliographystyle{IEEEtran}
\bibliography{references}


* Data Provenance :noexport:
  :PROPERTIES:
  :header-args: :eval never-export
  :END:
** Data Analysis (R Scripts)
*** Utils
**** Anne-Cécile Factor
In Mahadevan's paper:
http://dl.ifip.org/db/conf/networking/networking2009/MahadevanSBR09.pdf
- edge switch LAN : 
   - Idle : 150 Watts
   - 48 ports at 1 Gbps : 48000 Mbps
   - 25% utilization
   - so 0.0125 Watt/Mbps
- core switch
   - Idle : 555 Watts
   - 48 ports at 1 Gbps : 48000 Mbps
   - 25% utilization
   - so 0.04625 Watt/Mbps
- gateway
   - Idle = 8.3 Watts
   - 54 Mpbs
   - 10% utilization
   - 1.537 Watt/Mbps
- Link utilization sources:
   https://ieeexplore.ieee.org/abstract/document/6566937
   http://www.dtc.umn.edu/~odlyzko/doc/internet.rates.pdf
Our usecase: for one sensor
- 250 bits (192 bits of data + headers)
- One packet per 10 seconds
- so bitrate: 25 bps = 0.000025 Mbps
- path between sensor and Cloud server: 1 gateway, 1 core switch, 8
  edge switches = 10 devices
- for each sensor: 0.000025 x [1.537 + 8 x 2 x 0.0125 + 2 x 0.04625] x 2
(last x2 = redundancy factor, the other x2 are to account for in/out ports)
   = 0.0001 Watts on the whole path (10 devices)
- so 0.00001 per device
- previously in the simulations: 1 Watt per device, so 10 Watts in
  total, so we need to remove 9.9999 Watts from the result
**** R
      RUtils is intended to load logs (data.csv) and providing
      simple plot function for them.

      #+NAME: RUtils
      #+BEGIN_SRC R  :eval never
        library("tidyverse")

        # Fell free to update the following
        labels=c(time="Time (s)",sensorsSendInterval="Sensors Send Interval (s)", sensorsNumber="Number of sensors")
        PUE=1.2
        ns3SimTime=1800
        g5kSimTime=300

        loadData=function(path){
          data=read_csv(path)
          if("sensorsEnergy"%in%colnames(data)){ # If it is ns3 logs
            data=data%>%mutate(sensorsEnergy=sensorsEnergy/ns3SimTime)  # Convert to watts
            data=data%>%mutate(networkEnergy=networkEnergy/ns3SimTime)
            data=data%>%mutate(networkEnergy=networkEnergy-9.9999) # Anne-Cécile Factor (accounting for port idle (in fact we are not using all the 1W, there is also other communication on ISP switches) 
            data=data%>%mutate(networkEnergy=networkEnergy+getSwitchesIDLE(sensorsNumber,sensorsSendInterval)) # Add Idle conso of switches
            data=data%>%mutate(totalEnergy=totalEnergy/ns3SimTime)
          }
          else{ # Log from g5k
            data=data%>%mutate(energy=energy*PUE) # Take into account PUE
            data=data%>%filter(time<=g5kSimTime) # Remove extrats values (theorical sim time != real sim time)
          }
        }


        getSwitchesIDLE=function(nbSensors, sendInterval){
          pktSize=192
          nEdgeRouter=8
          nCoreRouter=1

          EdgeIdle=4095
          EdgeMax=4550
          EdgeTraffic=560*10^9

          CoreIdle=11070
          CoreMax=12300
          CoreTraffic=4480*10^9

          # Apply 0.6 factor
          EdgeTraffic=EdgeTraffic*0.6
          CoreTraffic=CoreTraffic*0.6

          totalTraffic=pktSize/sendInterval*nbSensors

          EdgeConso=EdgeIdle*(totalTraffic/EdgeTraffic)
          CoreConso=CoreIdle*(totalTraffic/CoreTraffic)

          return(EdgeConso+CoreConso)
        }

                # Get label according to varName
        getLabel=function(varName){
          if(is.na(labels[varName])){
            return(varName)
          }
          return(labels[varName])
        }

        applyTheme=function(plot,...){
          palette<- c("#00AFBB", "#E7B800", "#FC4E07","#0abb00")
          plot=plot+
            theme_bw(...)+
              scale_fill_manual(values=palette)+
                scale_colour_manual(values=palette)
          return(plot)
        }

      #+END_SRC



**** Bash
***** Plots -> PDF
     Merge all plots in plots/ folder into a pdf file.
     #+NAME: plotToPDF
     #+BEGIN_SRC bash :results output :noweb yes
       orgFile="plots/plots.org"
       <<singleRun>> # To get all default arguments

       # Write helper function
       function write {
           echo "$1" >> $orgFile
       }

       echo "#+TITLE: Analysis" > $orgFile
       write "#+LATEX_HEADER: \usepackage{fullpage}"
       write "#+OPTIONS: toc:nil"
       # Default arguments
       write '\begin{center}'
       write '\begin{tabular}{lr}'
       write 'Parameters & Values\\'
       write '\hline'
       write "sensorsPktSize & ${sensorsPktSize} bytes\\\\"
       write "sensorsSendInterval & ${sensorsSendInterval}s\\\\"
       write "sensorsNumber & ${sensorsNumber}\\\\"
       write "nbHop & ${nbHop}\\\\"
       write "linksBandwidth & ${linksBandwidth}Mbps\\\\"
       write "linksLatency & ${linksLatency}ms\\\\"
       write '\end{tabular}'
       write '\newline'
       write '\end{center}'

       for plot in $(find plots/ -type f -name "*.png")
       do
           write "\includegraphics[width=0.5\linewidth]{$(basename ${plot})}"
       done

       # Export to pdf
       emacs $orgFile --batch -f org-latex-export-to-pdf --kill  
     #+END_SRC

***** CSVs -> data.csv (G5K)
     Merge all energy file into one (and add additional fields).

     #+NAME: G5K-mergeCSV
     #+BEGIN_SRC sh
       #!/bin/bash

       whichLog="last"

       logsLocation="logs/g5k"
       whichLog="${logsLocation}/${whichLog}"



       logFile="$(dirname $(readlink -f $0))"/$whichLog/simLogs.txt
       dataFile=$(dirname "$logFile")/data.csv


       getValue () {
           line=$(echo "$1" | grep "Simulation para"|sed "s/Simulation parameters: //g")
           key=$2
           echo "$line"|awk 'BEGIN{RS=" ";FS=":"}"'$key'"==$1{gsub("\n","",$0);print $2}'
       }

       ##### Add extract info to energy #####
       IFS=$'\n'
       for cmd in $(cat $logFile|grep "Simulation parameters")
       do
           nodeName=$(getValue $cmd serverNodeName)
           from=$(getValue $cmd simStart)
           to=$(getValue $cmd simEnd)
           vmSize=$(getValue $cmd vmSize)
           nbSensors=$(getValue $cmd nbSensors)
           simKey=$(getValue $cmd simKey)
           sendInterval=$(getValue $cmd sensorsSendInterval)
           csvFile="$whichLog/${simKey}_${vmSize}VMSIZE_${nbSensors}NBSENSORS_${from}${to}.csv"
           csvFileIDLE="$whichLog/${simKey}_${vmSize}VMSIZE_${nbSensors}NBSENSORS_${from}${to}_IDLE.csv"
           tmpFile=${csvFile}_tmp
           echo ts,energy,simKey,vmSize,nbSensors,time,state,sendInterval > $tmpFile
           minTs=$(tail -n+2 $csvFile|awk -F"," 'BEGIN{min=0}$1<min||min==0{min=$1}END{print(min)}') # To compute ts field
           minTsIDLE=$(tail -n+2 $csvFileIDLE|awk -F"," 'BEGIN{min=0}$1<min||min==0{min=$1}END{print(min)}') # To compute ts field
           tail -n+2 ${csvFile} | awk -F"," '{print $0",'$simKey','$vmSize','$nbSensors',"$1-'$minTs'",sim,"'$sendInterval'}' >> $tmpFile
           tail -n+2 ${csvFileIDLE} | awk -F"," '{print $0",'$simKey','$vmSize','$nbSensors',"$1-'$minTsIDLE'",IDLE,"'$sendInterval'}' >> $tmpFile
       done


       ##### Fill dataFile #####
       echo ts,energy,simKey,vmSize,nbSensors,time,state,sendInterval > $dataFile
       for tmpFile in $(find ${whichLog}/*_tmp -type f)
       do
           tail -n+2 $tmpFile >> $dataFile
           rm $tmpFile # Pay attention to this line :D
       done
     #+END_SRC

     #+RESULTS: G5K-mergeCSV

     #+RESULTS: mergeCSV



***** Log -> data.csv (ns3)
      logToCSV extract usefull data from logs and put them into logs/data.csv.

      #+NAME: NS3-logToCSV
      #+BEGIN_SRC bash :results output
        logsFolder="./logs/ns3/last/"
        csvOutput="$logsFolder/data.csv"

        # First save csv header line
        aLog=$(find $logsFolder -type f -name "*.org"|head -n 1)
        metrics=$(cat $aLog|grep "\-METRICSLINE\-"|sed "s/-METRICSLINE-//g")
        echo $metrics | awk '{for(i=1;i<=NF;i++){split($i,elem,":");printf(elem[1]);if(i<NF)printf(",");else{print("")}}}' > $csvOutput

        # Second save all values
        for logFile in $(find $logsFolder -type f -name "*.org")
        do
            metrics=$(cat $logFile|grep "\-METRICSLINE\-"|sed "s/-METRICSLINE-//g")
            echo $metrics | awk '{for(i=1;i<=NF;i++){split($i,elem,":");printf(elem[2]);if(i<NF)printf(",");else{print("")}}}' >> $csvOutput
        done
      #+END_SRC

      #+RESULTS: NS3-logToCSV



   
      
*** Plot Scripts
**** Random R Scripts

    Table sensorsSendInterval~Sensors+NetEnergyconsumption
    #+BEGIN_SRC R :noweb yes :results output
      <<RUtils>>

      data=loadData("logs/ns3/last/data.csv")
      sensorsE=data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==15) %>%select(sensorsSendInterval,sensorsEnergy)%>%arrange(sensorsSendInterval)
      delay=data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==15) %>%select(sensorsSendInterval,avgDelay)%>%arrange(sensorsSendInterval)
      netE=data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==15) %>%select(sensorsSendInterval,networkEnergy)%>%arrange(sensorsSendInterval)
      formatData=right_join(sensorsE,netE)%>%right_join(delay)%>%filter(((sensorsSendInterval/10)%%2)!=0)

      print(t(formatData))

    #+END_SRC

    #+RESULTS:
    :                           [,1]      [,2]      [,3]      [,4]      [,5]
    : sensorsSendInterval 10.0000000 30.000000 50.000000 70.000000 90.000000
    : sensorsEnergy       13.5179444 13.517667 13.517667 13.517667 13.517611
    : networkEnergy       10.4417825 10.441668 10.441612 10.441612 10.441612
    : avgDelay             0.0995173  0.100214  0.101002  0.102034  0.102025




    Figure Sensors Position ~ Energy/Delay
    #+BEGIN_SRC R :noweb yes :results graphics :file plots/sensorsPosition-delayenergy.png
      <<RUtils>>
      tr=11 # Offset to center delay plot
      data=loadData("logs/ns3/last/data.csv")

      data=data%>%filter(simKey=="SENSORSPOS",sensorsNumber==9)

      p=ggplot(data,aes(y=sensorsEnergy,x=positionSeed,color="Energy"))+xlab(getLabel("Sensors Position Seed"))+ylab(getLabel("Sensors Power Consumption (W)"))+
      geom_line()+geom_point()+geom_line(aes(y=(avgDelay-tr),color="Delay"))+geom_point(aes(y=(avgDelay-tr),color="Delay"))+expand_limits(y=c(0,15))+
      scale_y_continuous(sec.axis = sec_axis(~.+tr, name = "Application Delay (s)")) +
      guides(color=guide_legend(title="Curves"))

      p=applyTheme(p)      
      p=p+theme(axis.title.y.right = element_text(margin = margin(t = 0, r = -8, b = 0, l = 10)))



      ggsave("plots/sensorsPosition-delayenergy.png",dpi=80, width=4, height=3.2)
    #+END_SRC

    #+RESULTS:
    [[file:plots/sensorsPosition-delayenergy.png]]



       Watt per sensor on server
    #+BEGIN_SRC R :noweb yes :results output
      <<RUtils>>
      # Load data
      data=loadData("./logs/g5k/last/data.csv")

      data=data%>%filter(state=="sim",simKey=="nbSensors")%>%ungroup()


      data=data%>%group_by(nbSensors)%>%mutate(avgEnergy=mean(energy))%>%distinct()%>%ungroup()
      data=data%>%distinct(nbSensors,.keep_all=TRUE)
      data=data%>%mutate(WPS=(avgEnergy/nbSensors))

      print(data%>%select(WPS,nbSensors))
    #+END_SRC



     Impact of vm size
     #+BEGIN_SRC R :results  graphics :file plots/vmSizeBar-cloud.png
       library("tidyverse")
       PUE=1.2
       # Load data
       data=read_csv("./logs/g5k/last/data.csv")

       data=data%>%filter(state=="sim",simKey=="vmSize")%>%mutate(energy=PUE*energy)%>%filter(time<=300)

       data=data%>%group_by(vmSize)%>%mutate(energy=mean(energy))%>%slice(1L)%>%ungroup()
       data=data%>%mutate(vmSize=as.character(vmSize))

       ggplot(data) + geom_bar(aes(x=vmSize,y=energy),stat="identity")+expand_limits(y=c(75,100))+ylab("Server Power Consumption (W)")+
       xlab("Experiment Time (s)")+scale_y_log10()


       ggsave("plots/vmSizeBar-cloud.png",dpi=90,height=3,width=6)  
     #+END_SRC

     #+RESULTS:
     [[file:plots/vmSizeBar-cloud.png]]



     #+NAME: ssiNet
     #+BEGIN_SRC R :noweb yes :results graphics :file plots/sensorsSendInterval-net.png
       <<NS3-RUtils>>
       # Load Data
        data=read_csv("logs/ns3/last/data.csv")

       data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==20) %>% ggplot(aes(x=sensorsSendInterval,y=networkEnergy))+xlab(getLabel("sensorsSendInterval"))+ylab(getLabel("networkEnergy"))+
       geom_line()+labs(title="For 20 sensors")
       ggsave("plots/sensorsSendInterval-net.png",dpi=80)
     #+END_SRC


     Effect of the number of sensors on the application delay
     #+BEGIN_SRC R :noweb yes :results graphics :file plots/delay-nbsensors.png
       <<NS3-RUtils>>
       # Load Data
        data=read_csv("logs/ns3/last/data.csv")

       data%>%filter(simKey=="NBSENSORS") %>% ggplot(aes(y=avgDelay,x=sensorsNumber))+xlab(getLabel("sensorsNumber"))+ylab(getLabel("avgDelay"))+
       geom_line()+labs(title="For 20 sensors")
       ggsave("plots/delay-nbsensors.png",dpi=80)
     #+END_SRC

     #+RESULTS:
     [[file:plots/delay-nbsensors.png]]


   
     #+NAME: ssiWifi
     #+BEGIN_SRC R :noweb yes :results graphics :file plots/sensorsSendInterval-wifi.png
       <<NS3-RUtils>>
       data=read_csv("logs/ns3/last/data.csv")
       data%>%filter(simKey=="SENDINTERVAL",sensorsNumber==20) %>% ggplot(aes(x=sensorsSendInterval,y=sensorsEnergy))+xlab(getLabel("sensorsSendInterval"))+ylab(getLabel("sensorsEnergy"))+
       geom_line() +     geom_line()+labs(title="For 20 sensors")
       ggsave("plots/sensorsSendInterval-wifi.png",dpi=80)
     #+END_SRC


      #+BEGIN_SRC R :results graphics  :noweb yes  :file plots/plot-final.png :session *R*
        <<NS3-RUtils>>
        simTime=1800

        # Network
        data=read_csv("logs/ns3/last/data.csv")
        data=data%>%filter(simKey=="NBSENSORS")
        dataC5=data%>%filter(sensorsNumber==5)%>% mutate(energy=networkEnergy/simTime) %>%select(energy,sensorsNumber)
        dataC10=data%>%filter(sensorsNumber==10)%>%mutate(energy=networkEnergy/simTime) %>%select(energy,sensorsNumber)
        dataNet=rbind(dataC5,dataC10)%>%mutate(type="Network")

        # Network
        dataS5=data%>%filter(sensorsNumber==5)%>% mutate(energy=sensorsEnergy/simTime) %>%select(energy,sensorsNumber) 
        dataS10=data%>%filter(sensorsNumber==10)%>%mutate(energy=sensorsEnergy/simTime) %>%select(energy,sensorsNumber) 
        dataS=rbind(dataS5,dataS10)%>%mutate(type="Sensors")
      
        data=rbind(dataNet,dataS)%>%mutate(sensorsNumber=as.character(sensorsNumber))

        ggplot(data)+geom_bar(aes(x=sensorsNumber,y=energy,fill=type),stat="identity")+xlab("Sensors Number")+ylab("Power Consumption (W)")+guides(fill=guide_legend(title="Part"))
        ggsave("plots/plot-final.png",dpi=80)

      #+END_SRC
    
**** Plot In Paper

     Power sensors vs network
     #+BEGIN_SRC R :noweb yes :results graphics :file plots/numberSensors-WIFINET.png :session *R*
       <<RUtils>>

       data=loadData("logs/ns3/last/data.csv")
       data=data%>%filter(simKey=="NBSENSORS")
       dataW=data%>%mutate(energy=sensorsEnergy)%>% mutate(type="Sensors") %>% select(sensorsNumber,energy,type) 
       dataN=data%>%mutate(energy=networkEnergy)%>% mutate(type="Network") %>% select(sensorsNumber,energy,type)

       data=rbind(dataN,dataW)
       data=data%>%mutate(sensorsNumber=as.character(sensorsNumber))
       data=data%>%mutate(sensorsNumber=fct_reorder(sensorsNumber,as.numeric(sensorsNumber)))
       data=data%>%filter(sensorsNumber%in%c(2,4,6,8,10))

       p=ggplot(data)+geom_bar(aes(x=sensorsNumber,y=energy,fill=type),position="dodge",stat="identity")+
       xlab(getLabel("sensorsNumber"))+ ylab("Power Consumption (W)") + guides(fill=guide_legend(title=""))
       p=applyTheme(p)+theme(text = element_text(size=15))

       size=5
      ggsave("plots/numberSensors-WIFINET.png",dpi=90,width=size,height=size-1)
     #+END_SRC

     #+RESULTS:
     [[file:plots/numberSensors-WIFINET.png]]


    Final plot: Energy cloud, network and sensors 
    #+BEGIN_SRC R :noweb yes :results  graphics :file plots/final.png
      <<RUtils>>

      # Linear Approx
      approx=function(data1, data2,nbSensors){
        x1=data1$sensorsNumber
        y1=data1$energy

        x2=data2$sensorsNumber
        y2=data2$energy

        a=((y2-y1)/(x2-x1))
        b=y1-a*x1

        return(a*nbSensors+b)

      }


      # Load data
      data=loadData("./logs/g5k/last/data.csv")
      data=data%>%filter(state=="sim",simKey=="nbSensors")

      # Cloud
      data=data%>%mutate(sensorsNumber=nbSensors)
      data20=data%>%filter(nbSensors==20)%>%mutate(energy=mean(energy)) %>% slice(1L)
      data100=data%>%filter(nbSensors==100)%>%mutate(energy=mean(energy)) %>% slice(1L)
      data300=data%>%filter(nbSensors==300)%>%mutate(energy=mean(energy)) %>% slice(1L)
      dataCloud=rbind(data20,data100,data300)%>%mutate(sensorsNumber=nbSensors)%>%mutate(type="Cloud")%>%select(sensorsNumber,energy,type)
      dataCloud=bind_rows(dataCloud,tibble(sensorsNumber=1,energy=approx(data20,data100,1),type="Cloud"))
      dataCloud=dataCloud%>%mutate(energy=energy/8) # Divide by 8 because 16 core so 1 machine can host 16 vm but we use redundancy (2VM for 1app)

      # Network
      data=loadData("./logs/ns3/last/data.csv")
      data=data%>%filter(simKey=="NBSENSORS")
      dataN5=data%>%filter(sensorsNumber==5)%>% mutate(energy=networkEnergy) %>%select(energy,sensorsNumber)
      dataN10=data%>%filter(sensorsNumber==10)%>%mutate(energy=networkEnergy) %>%select(energy,sensorsNumber)
      dataNet=rbind(dataN5,dataN10)
      fakeNet=tibble(sensorsNumber=c(1,20,100,300))
      fakeNet=fakeNet%>%mutate(energy=approx(dataN5,dataN10,sensorsNumber),type="Network")

      # Sensors
      dataS5=data%>%filter(sensorsNumber==5)%>% mutate(energy=sensorsEnergy) %>%select(energy,sensorsNumber) 
      dataS10=data%>%filter(sensorsNumber==10)%>%mutate(energy=sensorsEnergy) %>%select(energy,sensorsNumber) 
      dataS=rbind(dataS5,dataS10)
      fakeS=tibble(sensorsNumber=c(1,20,100,300))
      fakeS=fakeNet%>%mutate(energy=approx(dataS5,dataS10,sensorsNumber),type="Sensors")

      # Combine Net/Sensors/Cloud and order factors
      fakeData=rbind(fakeNet,fakeS,dataCloud)
      fakeData=fakeData%>%mutate(sensorsNumber=as.character(sensorsNumber))
      fakeData=fakeData%>%mutate(sensorsNumber=fct_reorder(sensorsNumber,as.numeric(sensorsNumber)))
      fakeData$type=factor(fakeData$type,ordered=TRUE,levels=c("Sensors","Network","Cloud"))

      # Plot
      p=ggplot(fakeData)+geom_bar(position="dodge2",colour="black",aes(x=sensorsNumber,y=energy,fill=type),stat="identity")+ 
      xlab("Number of Sensors")+ylab("Power Consumption (W)")+guides(fill=guide_legend(title="System Part"))
      p=applyTheme(p)+theme(text = element_text(size=16))
      ggsave("plots/final.png",dpi=90,width=8,height=5.5)
      write.csv(last_plot()$data,file=paste0("/home/loic/aa",".csv"))
    #+END_SRC

    #+RESULTS:





    Impact of vm size
    #+BEGIN_SRC R :noweb yes :results graphics :noweb yes :file plots/vmSize-cloud.png
      <<RUtils>>

      # Load data
      data=loadData("./logs/g5k/last/data.csv")

      data=data%>%filter(state=="sim",simKey=="vmSize")%>%filter(time<=300)

      data=data%>%mutate(vmSize=paste0(vmSize," MB"))
      data=data%>%group_by(vmSize)%>%mutate(avgEnergy=mean(energy))%>%ungroup()
      p=ggplot(data,aes(x=time, y=energy)) + geom_line()+facet_wrap(~vmSize)+geom_hline(aes(yintercept=avgEnergy),color="Red",size=1.0)+expand_limits(y=c(0,40))+ylab("Server Power Consumption (W)")+
      xlab("Experiment Time (s)")

      p=applyTheme(p)
      
      ggsave("plots/vmSize-cloud.png",dpi=90,height=3,width=6)  
    #+END_SRC

    #+RESULTS:
    [[file:plots/vmSize-cloud.png]]


    Impact of sensors number
    #+BEGIN_SRC R :noweb yes :results  graphics :file plots/sensorsNumber-cloud.png
      <<RUtils>>
      # Load data
      data=loadData("./logs/g5k/last/data.csv")

      data=data%>%filter(state=="sim",simKey=="nbSensors")%>%ungroup()

      data=data%>%mutate(nbSensorsSort=nbSensors)
      data=data%>%mutate(nbSensors=paste0(nbSensors," Sensors"))
      data$nbSensors=fct_reorder(data$nbSensors, data$nbSensorsSort)

      data=data%>%group_by(nbSensors)%>%mutate(avgEnergy=mean(energy))%>%ungroup()
      p=ggplot(data,aes(x=time, y=energy)) + geom_line()+facet_wrap(~nbSensors)+expand_limits(y=c(0,40))+ylab("Server Power Consumption (W)")+
      xlab("Experiment Time (s)")+geom_hline(aes(yintercept=avgEnergy),color="Red",size=1.0)

      p=applyTheme(p)
      ggsave("plots/sensorsNumber-cloud.png",dpi=90,height=3,width=6)  
    #+END_SRC

    #+RESULTS:
    [[file:plots/sensorsNumber-cloud.png]]
  
    #+BEGIN_SRC R :noweb yes :results graphics :file plots/sensorsNumberLine-cloud.png :session *R:2*
          <<RUtils>>
          # Load data
          data=loadData("./logs/g5k/last/data.csv")

          data=data%>%filter(state=="sim",simKey=="nbSensors")%>%ungroup()


          data=data%>%group_by(nbSensors)%>%mutate(avgEnergy=mean(energy))%>%distinct()%>%ungroup()
          data=data%>%distinct(nbSensors,.keep_all=TRUE)
          data=data%>%mutate(WPS=(avgEnergy/nbSensors))

          p=ggplot(data,aes(x=nbSensors, y=avgEnergy)) + geom_point() +geom_line()+
          xlab(getLabel("sensorsNumber"))+ylab("Average server power consumption (W)")

          p=applyTheme(p)+theme(text = element_text(size=14))+ expand_limits(y=108)
          ggsave("plots/sensorsNumberLine-cloud.png",dpi=90,height=4.5,width=4)
    #+END_SRC

    #+RESULTS:
    [[file:plots/sensorsNumberLine-cloud.png]]
  
    #+BEGIN_SRC R :noweb yes :results graphics :file plots/WPS-cloud.png :session *R:2*
            <<RUtils>>
            # Load data
            data=loadData("./logs/g5k/last/data.csv")

            data=data%>%filter(state=="sim",simKey=="nbSensors")%>%ungroup()


            data=data%>%group_by(nbSensors)%>%mutate(avgEnergy=mean(energy))%>%distinct()%>%ungroup()
            data=data%>%distinct(nbSensors,.keep_all=TRUE)
            data=data%>%mutate(WPS=(avgEnergy/nbSensors))

            oldNb=data$nbSensors
            data=data%>%mutate(nbSensors=as.character(nbSensors))
            data$nbSensors=fct_reorder(data$nbSensors,oldNb)
            p=ggplot(data,aes(x=nbSensors, y=WPS)) + geom_bar(stat="identity")+
            xlab(getLabel("sensorsNumber"))+ylab("Server power cost per sensors (W)")

            p=applyTheme(p)+theme(text = element_text(size=14))+        theme(axis.title.y = element_text(margin = margin(t = 0, r = 8, b = 0, l = 0)))
            ggsave("plots/WPS-cloud.png",dpi=90,height=4,width=4)
    #+END_SRC

    #+RESULTS:
    [[file:plots/WPS-cloud.png]]

    #+BEGIN_SRC R :noweb yes :results  graphics :file plots/sendInterval-cloud.png
      <<RUtils>>
      # Load data
      data=loadData("./logs/g5k/last/data.csv")

      data=data%>%filter(state=="sim",simKey=="sendInterval")%>%ungroup()

      oldSendInterval=data$sendInterval
      data=data%>%mutate(sendInterval=paste0(sendInterval,"s"))
      data$sendInterval=fct_reorder(data$sendInterval,oldSendInterval)

      data=data%>%group_by(sendInterval)%>%mutate(avgEnergy=mean(energy))%>%ungroup()
          print(data)
      p=ggplot(data,aes(x=time, y=energy)) + geom_line()+facet_wrap(~sendInterval,ncol=1)+expand_limits(y=c(0,40))+ylab("Server power consumption (W)")+
      xlab("Experiment Time (s)")+geom_hline(aes(yintercept=avgEnergy),color="Red",size=1.0)

      p=applyTheme(p)
      ggsave("plots/sendInterval-cloud.png",dpi=120,height=6,width=8)  
    #+END_SRC
    
    #+RESULTS:

    
* Emacs settings :noexport:
  # Local Variables:
  # eval:    (unless (boundp 'org-latex-classes) (setq org-latex-classes nil))
  # eval:    (add-to-list 'org-latex-classes
  #                       '("llncs" "\\documentclass[conference]{llncs}\n \[NO-DEFAULT-PACKAGES]\n \[EXTRA]\n"  ("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}" . "\\subsection*{%s}")                       ("\\subsubsection{%s}" . "\\subsubsection*{%s}")                       ("\\paragraph{%s}" . "\\paragraph*{%s}")                       ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
  # End: