summaryrefslogtreecommitdiff
path: root/2019-Mascots.org
diff options
context:
space:
mode:
authorLoic Guegan <manzerberdes@gmx.com>2019-05-20 16:48:17 +0200
committerLoic Guegan <manzerberdes@gmx.com>2019-05-20 16:48:17 +0200
commit4045a41e029ed11dde5763455095bd33c7746a72 (patch)
treef60f6a33417b086912714a12428dc9c3d72271b4 /2019-Mascots.org
parent04b79f058e18904a7c0f634b66d820ad810add06 (diff)
Update paper
Diffstat (limited to '2019-Mascots.org')
-rw-r--r--2019-Mascots.org71
1 files changed, 53 insertions, 18 deletions
diff --git a/2019-Mascots.org b/2019-Mascots.org
index fc79d29..a306a16 100644
--- a/2019-Mascots.org
+++ b/2019-Mascots.org
@@ -30,14 +30,14 @@ component, formatting, style, styling, insert
#+END_EXPORT
-* Introduction
-* Related Work
-* Use-Case
+* Introduction [2 col]
+* Related Work [1 col]
+* Use-Case [1 col]
** Application Characteristic
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 respectives local temperature at a frequency
+ 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.
@@ -46,19 +46,28 @@ component, formatting, style, styling, insert
of several network switches and router and it is considered to be a wired network.
** Cloud Infrastructure
-* System Model
+
+* System Model [2 col]
The system model is divided in two parts. First, the IoT and the Network part are models through
- simulations. Then, the Cloud part is model using real servers connected to wattmeters. In this way,
+ simulations. Then, the Cloud part is model using real servers connected to watt-meters. 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 AP which forms a
cell. It is model using the ns-3 network simulator. Thus, we setup between 5 and 20 sensors
- connected to the AP using WIFI 5GHz 802.11n. 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 come
- from the litterature and are provided on Table \ref{tab:wifi-energy}. Note that we suppose that the
- energy source of the cell nodes are unlimited and thus every nodes can communicate for all the
- simulation duration.
+ connected to the AP using WIFI 5GHz 802.11n. The node are placed randomly in a square of 30
+ meters 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 come from the literature and are provided on Table \ref{tab:wifi-energy}. Note
+ that we suppose that the energy source of the cell nodes are unlimited and thus every nodes can
+ communicate for all the simulation duration.
+
+ As a scenario, sensors send to the AP packets of 192 bits that include: \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 to relay data to the
+ cloud using the network part.
+
#+BEGIN_EXPORT latex
\begin{table}[]
@@ -74,25 +83,51 @@ component, formatting, style, styling, insert
Idle & 0.273A & TODO \\ \hline
\end{tabular}
\end{table}
-
#+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 aways from the AP with a typical
+ round-trip latency of 100ms from the AP to the server. 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. The different energy values used in the
+ network part are from the literature and shown in Table \ref{tab:net-energy}.
+
+ #+BEGIN_EXPORT latex
+ \begin{table}[]
+ \centering
+ \caption{Network Part Energy Settings}
+ \label{tab:net-energy}
+ \begin{tabular}{|l|l|l|}
+ \hline
+ & Value & Reference(s) \\ \hline
+ Idle & 1J & TODO \\ \hline
+ Bytes (Tx/Rx) & 3.4nJ & TODO \\ \hline
+ Pkt (Tx/Rx) & 192.0nJ & TODO \\ \hline
+ \end{tabular}
+ \end{table}
+ #+END_EXPORT
-
** Cloud Part
-* Evaluation
+ 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 is configured to use KVM for virtualization. Virtual Machines (VM)
+
+
+* Evaluation [3 col]
** IoT/Network Consumption
** Cloud Energy Consumption
** Virtual Machine Size Impact
** Application Accuracy
Refresh frequency etc...
** End-To-End Consumption
-* Discussion
-* Conclusion
-
-
+* Discussion [1 col]
+* Conclusion [1 col]
+* References [1 col]
+\bibliographystyle{IEEEtran}
+\bibliography{references}
* Emacs settings :noexport:
# Local Variables: