mirror of
https://gitlab.com/manzerbredes/paper-lowrate-iot.git
synced 2025-04-19 04:09:43 +00:00
Correct some typos
This commit is contained in:
parent
789784fce4
commit
c7b325d759
3 changed files with 36 additions and 37 deletions
|
@ -1 +0,0 @@
|
|||
loic@lguegan.1106:1558519162
|
|
@ -61,21 +61,21 @@ component, formatting, style, styling, insert
|
|||
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 AP which forms a
|
||||
cell. It is model using the ns-3 network simulator. Thus, 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 400m2
|
||||
around the AP which correspond to a typical real use case. All the nodes of the cell are setup
|
||||
with the default WIFI energy model provided by ns-3. The different energy values used by the
|
||||
energy model are provided on Table \ref{tab:wifi-energy}. These energy were extracted from
|
||||
previous work\cite{halperin_demystifying_nodate,li_end--end_2018} on 802.11n. Note that we
|
||||
suppose that the energy source of the cell nodes are unlimited and thus every nodes can
|
||||
communicate until the end of all the simulations.
|
||||
In the first place, the IoT part is composed of several sensors connected to an Access Point (AP)
|
||||
which forms a cell. This cell is model using the ns-3 network simulator. Consequently, 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 400m2 around the AP which corresponds to a typical real use case. All
|
||||
the cell nodes are setup with the default WIFI energy model provided by ns-3. The different
|
||||
energy values used by the energy model are provided on Table \ref{tab:wifi-energy}. These energy
|
||||
were extracted from previous work\cite{halperin_demystifying_nodate,li_end--end_2018} on
|
||||
802.11n. Besides, we suppose that the energy source of each nodes are unlimited and thus each of
|
||||
them can communicate until the end of all the simulations.
|
||||
|
||||
As a scenario, sensors send to the AP packets of 192 bits that include: \textbf{1)} A 128 bits
|
||||
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 time. The data are transmitted immediately at each
|
||||
sensing interval $I$ varied from 1s to 60s. Finally, the AP is in charge of relaying data to the
|
||||
cloud using the network part.
|
||||
timestamp representing the temperature sensing time to store them as time series. The data are
|
||||
transmitted immediately at each sensing interval $I$ varied 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}[]
|
||||
|
@ -104,26 +104,26 @@ component, formatting, style, styling, insert
|
|||
#+END_EXPORT
|
||||
|
||||
** Network Part
|
||||
The network part represents the network starting from the AP to the Cloud excluding the server.
|
||||
It is also model into ns-3. 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. Each node from the AP to the Cloud is
|
||||
assume to be network switches with static and dynamic network energy consumption. ECOFEN
|
||||
The network part represents the a network section starting from the AP to the Cloud excluding the
|
||||
server. It is also model into ns-3. 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. Each node from the AP to the Cloud
|
||||
is assume to be network switches with static and dynamic network energy consumption. ECOFEN
|
||||
\cite{orgerie_ecofen:_2011} is used to model the energy consumption of the network part. ECOFEN
|
||||
is a ns-3 network energy module for ns-3 dedicated to wired network energy estimation. It is
|
||||
based on an energy-per-bit model including static consumption by assuming a linear relation
|
||||
between the amount of data sent to the network interface and the power consumption. The different
|
||||
energy values used to instantiate the ECOFEN energy model for the network part are shown in Table
|
||||
\ref{tab:net-energy} and come from previous work \cite{cornea_studying_2014-1}.
|
||||
is a ns-3 network energy module dedicated to wired network. It is based on an energy-per-bit
|
||||
model including static energy consumption by assuming a linear relation between the amount of
|
||||
data sent to the network interface and its power consumption. The different energy values used to
|
||||
instantiate the ECOFEN energy model for the network part are shown in Table \ref{tab:net-energy}
|
||||
and come from previous work \cite{cornea_studying_2014-1}.
|
||||
|
||||
** Cloud Part
|
||||
Finally, to measure the energy consumption of the server, we used real server from the
|
||||
large-scale test-beds Grid5000 (G5K). In fact, G5K has a cluster called Nova composed of several
|
||||
nodes which are connected to watt-meters. In this way, we can benefit from real energy
|
||||
measurements. The server used in the experiment is composed of Intel Xeon E5-2620 processor with
|
||||
64 GB of RAM and 600GB of disk space on a Linux based distribution. This server is configured to
|
||||
use KVM as virtualization mechanism. We deploy a classical Linux x86_64 distribution on the
|
||||
Virtual Machines (VM) along with a MySQL database. We different amount of allocated memory for
|
||||
the VM namely 1024MB/2048MB/4096MB to highlight its effects on the server energy consumption.
|
||||
Finally, to measure the energy consumed by the server, we used real server from the large-scale
|
||||
test-beds Grid5000 (G5K). In fact, G5K has a cluster called Nova composed of several nodes which
|
||||
are connected to watt-meters. In this way, we can benefit from real energy measurements. The
|
||||
server used in the experiment include an Intel Xeon E5-2620 processor 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 Linux x86_64 distribution on the Virtual Machine
|
||||
(VM) along with a MySQL database. We used different amount of allocated memory for the VM namely
|
||||
1024MB/2048MB/4096MB to highlight its effects on the server energy consumption.
|
||||
|
||||
The sensors requests are simulated using another server. This server is in charge to send hundred
|
||||
of requests to the VM in order to fill the database. Consequently, it is easy to vary the
|
||||
|
@ -188,10 +188,10 @@ component, formatting, style, styling, insert
|
|||
** Cloud Energy Consumption
|
||||
In this End-To-End energy consumption study, cloud account 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 hyperscale data center is 1.2. Thus, in
|
||||
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.
|
||||
|
||||
In a first place, we analyse the impact of the VM allocated memory on the server energy
|
||||
In a first place, we analyze the impact of the VM allocated memory on the server energy
|
||||
consumption. Figure \ref{fig:vmSize} depict the server energy consumption according to the VM
|
||||
allocated memory for 20 sensors sending data every 10s. Note that red horizontal line represent
|
||||
the average energy consumption for sample of energy value. We can see that at each sensing
|
||||
|
@ -216,7 +216,7 @@ component, formatting, style, styling, insert
|
|||
number of sensors. These shows 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 server, the
|
||||
more energy we can save. In fact, since the idle server energy consumption is high, it is more
|
||||
energy efficient to maximze the number of sensors per server. As showed on Figure
|
||||
energy efficient to maximize the number of sensors per server. As showed on Figure
|
||||
\ref{fig:sensorsNumber-WPS}, a significant amount of energy can be save when passing from 20
|
||||
sensors to 300 per server.
|
||||
|
||||
|
@ -260,11 +260,11 @@ component, formatting, style, styling, insert
|
|||
energy consumption while varying the number of sensors. It is important to see that, for
|
||||
small-scale systems, the server energy consumption is dominant face to the energy consumed by the
|
||||
sensors. However, since we are using a single server, large-scale sensors deployment lead to an
|
||||
increasing consumtion of energy in the sensors side. On the other side, network energy
|
||||
increasing consumption of energy in the sensors side. On the other side, network energy
|
||||
consumption is stable regarding to the number of sensors that are deployed since network the
|
||||
system use case do not required large data transfert. Thus, it is important to remember that, to
|
||||
system use case do not required large data transfer. Thus, it is important to remember that, to
|
||||
save energy, we should maximize the number of sensors handle by each cloud server while keeping a
|
||||
resonable sensors requests intervals.
|
||||
reasonable sensors requests intervals.
|
||||
|
||||
#+BEGIN_EXPORT latex
|
||||
\begin{figure}
|
||||
|
|
BIN
2019-Mascots.pdf
BIN
2019-Mascots.pdf
Binary file not shown.
Loading…
Add table
Add a link
Reference in a new issue