From f930372b1f95a44c3b1efc26cbf61f0a3ae12907 Mon Sep 17 00:00:00 2001
From: ORGERIE Anne-Cecile <anne-cecile.orgerie@inria.fr>
Date: Sun, 1 Sep 2019 12:49:24 +0200
Subject: relecture jusqu'à la section VI
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 2019-CloudCom.tex | 110 +++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 72 insertions(+), 38 deletions(-)

(limited to '2019-CloudCom.tex')

diff --git a/2019-CloudCom.tex b/2019-CloudCom.tex
index 12ee727..6880238 100644
--- a/2019-CloudCom.tex
+++ b/2019-CloudCom.tex
@@ -38,7 +38,7 @@ 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 
+infrastructures induced by the utilization of connected devices, and 
 we propose an end-to-end energy consumption model for these devices. 
 \end{abstract}
 
@@ -115,11 +115,12 @@ 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. 
+consumption. Indeed, shifting computations to the cloud is often used
+to reduce the consumption of IoT devices~\cite{offloading}, without studying the 
+additional cost for the cloud infrastructure. Consequently, such
+an energy-saving technique, from the IoT device point of view, can
+result on an higher overall energy consumption.
+Using end-to-end models could prevent these unwanted effects. 
 
 Our contributions include:
 \begin{itemize}
@@ -179,7 +180,7 @@ 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
+sensor networks~\cite{offloading,Wang2016}. Yet, IoT devices present more
 diversity than typical wireless sensors in terms of hardware
 characteristics, communication means and data production patterns.
 
@@ -190,7 +191,23 @@ 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}. 
+simulator~\cite{ns3-energywifi}.
+
+These models can be used to evaluate
+the energy efficiency of communication protocols or computation
+offloading techniques~\cite{offloading}. However, they do not
+provide an overall view of the energy consumption of the entire
+system architecture: from the IoT device to the cloud server. 
+To the best of our knowledge, one previous work targets 
+an end-to-end energy model for IoT devices~\cite{li_end--end_2018}. 
+However, this work focus on high-bandwidth IoT devices with data
+streaming-oriented applications. This study shows that, in this
+case (high-bandwidth IoT applications), the cloud server hosting
+the application consumes more energy per IoT devices than the 
+device itself (an IP camera in the case study)~\cite{li_end--end_2018}.
+In our context of low-bandwidth devices, conclusions could be the
+opposite as the IoT devices' consumption is optimized since they
+are often powered through batteries.
 
 
 \subsection{Energy consumption of network and cloud infrastructures}
@@ -286,7 +303,7 @@ same time.
 \end{figure}
 
 In the following, we describe the experimental setup, the results and
-the end-to-end model. For all these steps, we decompose the overall
+the derived 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}. 
 
@@ -306,14 +323,20 @@ evaluate the end-to-end energy consumption of the system.
 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
+between 5 and 15 sensors connected to the AP using WiFi 5GHz 802.11n. The sensors 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
+to a typical use case for a home environment.
+
+All the cell sensors employ the default WIFI energy model provided by ns3.
+This model comprises different power levels depending on the state of the WiFi device
+(i.e. idle, transmitting, receiving). The power consumption of receiving and transmitting
+states depends on the data rate of the device at a given time. In this paper, 
+we consider only one data rate as the target is low-bandwidth devices in a home environment.
+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
+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
+sensor is not limited during the experiments. Thus, each sensor 
 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
@@ -349,7 +372,7 @@ charge of relaying data to the cloud via the network part.
 
 \subsection{Network Part}
 \label{sec:orgaeb55ca}
-The network part represents the a network section starting from the AP to the Cloud excluding the
+The network part represents the 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 
@@ -366,7 +389,7 @@ network part are shown in left part of Table~\ref{tab:params} and come from prev
 \subsection{Cloud Part}
 \label{sec:orgfc9ea54}
 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
+test-bed Grid'5000. Grid'5000 provides clusters composed of several servers 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
@@ -395,7 +418,11 @@ 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.
+setup. We consider here a simple IoT application able to store the sensed values
+and provide them upon request. We do not include any data mining or machine learning
+techniques as they are highly dependent on the targeted application and quality
+of service. They can be added a posteriori to the derived end-to-end model
+if they are known, or estimated from specific energy models.
 
 
 
@@ -410,11 +437,13 @@ 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.
+   Table~\ref{tab:sensorsSendIntervalEffects} show that the transmission frequency has a very limited impact
+   on the energy consumption of sensor and network parts, and on the average end-to-end application delay. 
+This is due to the fact that in such a scenario with very small
+   number of communications spread over the time, sensors do not have to contend for accessing to the
+   WiFi channel. Note that for the network part, we include the dynamic power consumption due to the
+   traffic generated by the sensors themselves, and we split the static power consumption of the routers
+   according the the utilization ratio taken by the sensors. This model is detailed in Section~\ref{sec:discuss}.
 
 % Please add the following required packages to your document preamble:
 % \usepackage{booktabs}
@@ -442,13 +471,11 @@ In our case with small and sporadic network traffic, these results show that wit
    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.
-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.
+We then vary the number of sensors in the WiFi cell.
+Figure~\ref{fig:sensorsNumber} represents the energy consumed by the sensor and the network (from the AP to the cloud) parts
+according to the number of sensors. Similarly to the results of Table~\ref{tab:sensorsSendIntervalEffects}, the network part
+is almost not affected by the number of sensors as their traffic is negligible compared to the network devices capacities.
+Consequently, sensors energy consumption is dominant, as each sensor adds its own consumption.
 
 \begin{figure}[htbp]
   \centering
@@ -461,12 +488,13 @@ can become dominant.
 \subsection{Cloud Energy Consumption}
 \label{sec:org9daa066}
 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}.
+consumption. According to 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. This metric
+accounts for indirect data center power costs, such as the cooling infrastructure and the power distribution losses. 
+
+In our analysis, we use the PUE to account for these costs and all energy measurement on cloud servers use it. 
+It means that the power consumption of the server is multiplied by
+the PUE~\cite{Ehsan}.
 
 \begin{figure*}[htbp]
   \centering
@@ -493,7 +521,9 @@ Figure~\ref{fig:sensorsNumber-server} presents the results of the average server
 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
+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 
@@ -504,6 +534,10 @@ 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}\}.
+As traditionally cloud servers host several VMs at the same time, our 
+model will in fact share the static power consumption of the server
+among the VMs it can host, depending on their VM size (allocated CPU and
+RAM). This model is detailed in Section~\ref{sec:discuss}.
 
 \begin{figure}[htbp]
   \centering
@@ -536,7 +570,7 @@ occur. Therefore, it leads to an increase of the server energy consumption.
   \label{fig:sensorsFrequency}
 \end{figure*}
 
-\section{End-To-End Consumption Model}
+\section{End-to-End Consumption Model}
 \label{sec:orgfd3b6ae}
 \label{sec:discuss}
 
@@ -585,7 +619,7 @@ 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
+per traffic 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}.
-- 
cgit v1.2.3

