From b2378fbbd9ca25a7c7426d875836ca169ac3d010 Mon Sep 17 00:00:00 2001 From: ORGERIE Anne-Cecile Date: Fri, 18 Oct 2019 21:53:35 +0200 Subject: [PATCH] ajout app charac --- 2019-CloudCom.tex | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/2019-CloudCom.tex b/2019-CloudCom.tex index f419ede..1cffd3c 100644 --- a/2019-CloudCom.tex +++ b/2019-CloudCom.tex @@ -260,6 +260,8 @@ 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. +\subsection{IoT device side} + 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 @@ -284,6 +286,8 @@ 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}. + +\subsection{Cloud server side} 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 @@ -303,6 +307,14 @@ same time. \label{fig:parts} \end{figure} +The Cloud part of the application gathers the data sent by the IoT +devices. These data are treated either on the fly (e.g. threshold +detection) or periodically, and action commands are sent back to the +device if required. For instance, if the user has set a targeted +temperature, the connected thermostat sends the measured +temperature regularly, and once the target is reached, the Cloud server detects +it, and sends back to the IoT device the command to pause the heater. + In the following, we describe the experimental setup, the results and 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