Merge commit '99c7223b8b7569b6e4f59baa591e209c594843ab'
This commit is contained in:
Leopold Clement
commit
af4e26f721
1 changed files with 271 additions and 271 deletions
542
rapport.tex
542
rapport.tex
|
|
@ -29,7 +29,7 @@
|
|||
\newglossaryentry{iot}
|
||||
{
|
||||
name=IoT,
|
||||
description={Internet of Things, internet des objets}
|
||||
description={Internet of Things, Internet des objets}
|
||||
}
|
||||
|
||||
\newcommand{\iot}{\gls{iot}}
|
||||
|
|
@ -117,7 +117,7 @@
|
|||
\newglossaryentry{gym}
|
||||
{
|
||||
name=GYM,
|
||||
description={Norme de compatibilité pour les environements de machine learning \cite{brockmanOpenAIGym2016}. \url{https://gym.openai.com/}}
|
||||
description={Norme de compatibilité pour les environnements de machine learning \cite{brockmanOpenAIGym2016}. \url{https://gym.openai.com/}}
|
||||
}
|
||||
|
||||
\newcommand{\gym}{\gls{gym}}
|
||||
|
|
@ -216,7 +216,7 @@
|
|||
\begin{flushright} \large
|
||||
\emph{Encadrants :} \\
|
||||
M\up{me} Lynda \textsc{Zitoune}, professeur des universités\\
|
||||
M\up{me} Véronique \textsc{Vèque}, maitresse de conferences
|
||||
M\up{me} Véronique \textsc{Vèque}, maîtresse de conférences
|
||||
\end{flushright}
|
||||
\end{minipage}
|
||||
|
||||
|
|
@ -261,28 +261,28 @@
|
|||
\includegraphics[width=0.30\textwidth]{png_img/cropped-L2S.png}
|
||||
\end{wrapfigure}
|
||||
|
||||
Le laboratoire des signaux et système (\lss{}) est une unité mixe de recherche entre le \emph{CNRS}, l'université PAris-Saclay et l'école CentralSupélec.
|
||||
Les thématique du laboratoire sont l'automatique, les traitements du signal et les télécomunication.
|
||||
En particulier, le pôle télécom et réseau se penche sur des problèmatique de tout niveaux autour des réseaux informatique, que ce soit de l'allcoation de ressource, du routage, de a compressionde donnée\dots
|
||||
Ces recherches s'appuis sur un vaste socle de méthode, que ce soit la théorie des jeux, du control, des graphes, de l'optimisation ou de l'apprentissage machine.
|
||||
L'équite Réseaux, Optimisation Conjointe et codage de Source (ROCS) travail sur deux thématique, l'\iot{} et les services vidéo, c'est à dire l'exploitation optimal d'une conexion limité.
|
||||
C'est dans cette équipe que j'ai réalisé mon stage.
|
||||
Le Laboratoire des signaux et systèmes (\lss{}) est une unité mixe de recherche entre le \emph{CNRS}, l'université Paris-Saclay et l'école CentraleSupélec.
|
||||
Les thématiques du laboratoire sont l'automatique, les traitements du signal et les télécommunications.
|
||||
En particulier, le pôle télécoms et réseaux se penche sur des problèmatiques de tout niveau autour des réseaux informatiques, que ce soit de l'allocation de ressources, du routage, de la compression de données\dots
|
||||
Ces recherches s'appuient sur un vaste socle de méthodes, que ce soit la théorie des jeux, du contrôle, des graphes, de l'optimisation ou de l'apprentissage machine.
|
||||
L'équipe Réseaux, Optimisation Conjointe et codage de Source (ROCS) travaille sur deux thématiques, l'\iot{} et les services vidéo, c'est-à-dire l'exploitation optimale d'une connexion limitée.
|
||||
C'est dans cette équipe que j'ai effectué mon stage.
|
||||
|
||||
La problématique étudier est de déterminer comment intégré un processus d'apprentissage dans la gestion de la congestion des réseaux \iot{}.
|
||||
La problématique étudiée est de déterminer comment intégrer un processus d'apprentissage dans la gestion de la congestion des réseaux \iot{}.
|
||||
En particulier, nous nous concentrons sur le protocole \coap{}.
|
||||
Nos objectifs sont \begin{itemize}
|
||||
\item nous familiariser avec les notions étudier et le protocole \coap{},
|
||||
\item déterminer quelle métrique utilisé pour suivre l'état du réseau,
|
||||
\item détermination des sénarios pertients
|
||||
\item simulation ou test de ces sénarios
|
||||
\item nous familiariser avec les notions étudiées et le protocole \coap{},
|
||||
\item déterminer quelle métrique utiliser pour suivre l'état du réseau,
|
||||
\item détermination des scénarios pertinents
|
||||
\item simulation ou test de ces scénarios
|
||||
\end {itemize}
|
||||
Le stage se déroule entrièrement en distancielle, avec des réunions hébdomadaire avec mes encadrantes soit en présentielle dans les locaux de CentralSupélec, soit sur Teams.
|
||||
Le stage se déroule entièrement en distanciel, avec des réunions hébdomadaires avec mes encadrantes, soit en présentiel dans les locaux de CentralSupélec, soit sur Teams.
|
||||
|
||||
\subsection{Qu'est-ce qu'un réseau \iot{} ?}
|
||||
|
||||
Un réseau \iot{} est un réseau de machines informatiques embarquées.
|
||||
Les machines qui composent ce réseau sont en majorité des machines peu puissantes : des capteurs, des actionneurs \dots, ils réalisent chacun une tâche simple, et sont soumis à de multiples contraintes, en particulier en termes de consommation énergétique.
|
||||
Les réseaux \iot{} présentent donc des thématiques propres aux réseaux classiques (débit, latence, pertes de données \dots), qui ont déjà été étudiées par le passé pour lesquelles des solutions exisent, et des thématique nouvelles qui ne s'intègrent pas dans le modèle classique.
|
||||
Les réseaux \iot{} présentent donc des thématiques propres aux réseaux classiques (débit, latence, perte de données \dots), qui ont déjà été étudiées par le passé et pour lesquelles des solutions existent, et des thématiques nouvelles qui ne s'intègrent pas dans le modèle classique.
|
||||
|
||||
\subsubsection{Qu'est-ce qu'un réseau ?}
|
||||
|
||||
|
|
@ -313,17 +313,17 @@ Cela inclut donc le multiplexage des données (c'est le port sur la machine hôt
|
|||
Les couches $5$ et $6$ n'ont pas d'influence sur la suite, et sont donc négligées.
|
||||
Elles permettent par exemple d'encrypter la connexion avec le \emph{SSL}.
|
||||
La couche $7$ est la couche applicative, c'est-à-dire l'utilisation finale que l'on fait de la connexion.
|
||||
Il peut s'agir de charger une page Internet, lire ses mails, regarder une vidéo, ou bien transmetre les mesures d'un capteur.
|
||||
Il peut s'agir de charger une page Internet, lire ses mails, regarder une vidéo, ou bien transmettre les mesures d'un capteur.
|
||||
C'est cette dernière utilisation qui nous intéresse ici.
|
||||
|
||||
La qualité d'une connexion entre deux points peut être évaluée grâce à deux valeurs : \begin{itemize}
|
||||
\item Le délai, qui correspond à la durée écoulée entre le moment où l'application émettrice veut émettre le message, et le moment où le message est reçu par l'application cliente.
|
||||
\item Le délai, qui correspond à la durée écoulée entre le moment où l'application émettrice veut émettre le message et le moment où le message est reçu par l'application cliente.
|
||||
\item Le débit, qui correspond à la quantité de bits pouvant être envoyés chaque seconde entre les deux applications.
|
||||
\end{itemize}
|
||||
|
||||
Ces deux grandeurs n'ont pas la même importance selon l'application.
|
||||
Par exemple, pour envoyer une pièce jointe dans un mail, le délai n'est pas très important : c'est le débit qui compte pour que la transaction ne soit pas trop longue.
|
||||
Par contre, dans le cas d'un jeu en ligne il y a peu de données à echanger mais il faut le faire avec le moins de délai possible pour que le jeu reste fluide.
|
||||
Par contre, dans le cas d'un jeu en ligne il y a peu de données à échanger mais il faut le faire avec le moins de délai possible pour que le jeu reste fluide.
|
||||
Suivant l'application, il faut favoriser l'un ou l'autre, ou trouver un compromis satifaisant.
|
||||
|
||||
\subsubsection{Qu'est-ce que la congestion ?}
|
||||
|
|
@ -332,10 +332,10 @@ Malheureusement, les réseaux étant hétérogènes, on ne contrôle pas tout le
|
|||
En effet, pour envoyer un paquet à une autre machine, il faut (dans le cas général) passer par plusieurs intermédiaires, les routeurs.
|
||||
Lesdits routeurs ne doivent pas gérer qu'un seul flux, et tous les liens entre les routeurs n'ont pas la même capacité ; ainsi on se retrouve avec des accumulations de paquets dans certains routeurs.
|
||||
L'accumulation se produit au niveau des goulots d'étranglement.
|
||||
Les routeurs n'ont pas une mémoire infinie, ils ne peuvent donc pas laisser les queues d'envoi grandir à l'infini.
|
||||
Elles ont donc une taille limite, et il faut donc parfois ne pas traiter certains paquets lorsque le réseau est trop chargé.
|
||||
Les routeurs n'ont pas une mémoire infinie, ils ne peuvent donc pas laisser les queues d'envoi grandir indéfiniment.
|
||||
Elles ont une taille limite, et il faut donc parfois ne pas traiter certains paquets lorsque le réseau est trop chargé.
|
||||
Ce phénomène est appelé congestion.
|
||||
On cherche à l'éviter, car un paquet non traité est un paquet perdu, donc le message n'est pas complet pour le client.
|
||||
On cherche à l'éviter, car un paquet non traité est un paquet perdu, et le message n'est pas complet pour le client.
|
||||
La gestion de la congestion sera expliquée plus en détail dans la partie \ref{part_cc}.
|
||||
La détection de la congestion se fait souvent à l'aide d'un accusé de réception : si l'accusé n'est pas reçu au bout d'un certain temps, on considère le message comme perdu.
|
||||
Lorsque des paquets sont perdus à cause de la congestion, il faut les réenvoyer, en faisant attention de ne pas recongestionner le réseau.
|
||||
|
|
@ -369,7 +369,7 @@ L'interface en question est une interface \emph{RestFull} :\begin{itemize}
|
|||
\end{itemize}
|
||||
\end{itemize}
|
||||
En plus de ces méthodes, qui ont leur équivalent chez \http{}, il y a la méthode OBSERVE.
|
||||
Si un client demande à observer une ressource sur un serveur, le serveur lui enverrait automatiquement la ressource à chaque fois qu'elle est modifiée.
|
||||
Si un client demande à observer une ressource sur un serveur, le serveur lui enverra automatiquement la ressource à chaque fois qu'elle est modifiée.
|
||||
Les ressources utilisées avec \coap{} ne sont pas les mêmes qu'en \http{}, on ne cherche pas à transférer une suite de centaines voire de milliers de paquets mais un seul.
|
||||
A la congestion classique s'ajoute le risque de perte de paquets à cause des liaisons physiques, car les infrastructures sans fil sont soumises à de la perte aléatoire.
|
||||
|
||||
|
|
@ -393,7 +393,7 @@ Notre problèmatique est donc de savoir si de telles solutions sont applicables
|
|||
\begin{wrapfigure}{r}{0.40\textwidth} %this figure will be at the right
|
||||
\centering
|
||||
\includegraphics[width=0.40\textwidth]{png_img/Markov_Decision_Process_example.png}
|
||||
\caption{Exemple de processus Markovien à trois états et deux actions.}
|
||||
\caption{Exemple de processus markovien à trois états et deux actions.}
|
||||
\end{wrapfigure}
|
||||
|
||||
L'apprentissage par renforcement est une solution d'apprentissage machine pour les processus markoviens.
|
||||
|
|
@ -408,7 +408,7 @@ Pour la suite, on notera $x ^ i$ la i-ème grandeur, et $x_t$ la grandeur à l'i
|
|||
Le but de l'acteur est de maximiser la récompense totale qu'il va recevoir au cours d'un épisode, c'est-à-dire une succession de pas de temps.
|
||||
Pour cela, l'acteur doit créer une fonction $\pi : \mathbb{S} \rightarrow \mathbb{A}$ permettant de donner l'action optimale à réaliser pour chaque état.
|
||||
|
||||
La solution optimal est définie comme l'action permetant de maximiser le retour global : \begin{equation}
|
||||
La solution optimale est définie comme l'action permettant de maximiser le retour global : \begin{equation}
|
||||
R = \sum_{i = 1} ^\infty r _ i \gamma ^ i
|
||||
\label{eq:rl:R}
|
||||
\end{equation}
|
||||
|
|
@ -448,7 +448,7 @@ Ainsi on décide d'une fenêtre de congestion, c'est-à-dire le nombre de paquet
|
|||
Si un paquet n'est pas acquitté avant la fin d'un \rto{} fixe, on le renvoie.
|
||||
Les \CCA{} ont pour rôle de gérer la taille de la fenêtre, et le \rto{} celui d'optimiser la connexion.
|
||||
|
||||
Les \CCA{} de \tcp{} sont nombreux (une classification partielle est lisible dans \cite{haileEndtoendCongestionControl2021}), ils ne seront donc pas tous décrit.
|
||||
Les \CCA{} de \tcp{} sont nombreux (une classification partielle est lisible dans \cite{haileEndtoendCongestionControl2021}), ils ne seront donc pas tous décrits.
|
||||
Le principe de base de la plupart des algorithmes est l'AIMD (additive-increase-multiplicative-decrease).
|
||||
Par exemple \newreno{}, le prédecesseur de \cubic{}, augmente la taille de la fenêtre par pas de $1$ tous les \rtt{}, et multiplie la taille par $\frac{1}{2}$ en cas de détection de congestion.
|
||||
L'évolution proposée par \cubic{} est de ne pas croître linéairement mais de suivre une courbe cubique pour revenir en douceur à la taille de fenêtre qui avait causé la congestion.
|
||||
|
|
@ -458,21 +458,21 @@ D'autres \CCA{} utilisent les variations du \rtt{} pour estimer l'état de conge
|
|||
Le \rtt{} est le temps qui sépare l'émission d'un paquet de la réception de l'acquittement.
|
||||
Le \rtt{} est composé de deux parties : \begin{itemize}
|
||||
\item le temps de propagation, qui correspond au temps que met le signal à faire le trajet ; il est incompressible (sauf changement de route),
|
||||
\item le temps d'attente dans les queues, qui est le temps passé dans les queues des différents routeurs et qui dépend dirrectement de la congestion du réseau.
|
||||
\item le temps d'attente dans les queues, qui est le temps passé dans les queues des différents routeurs et qui dépend directement de la congestion du réseau.
|
||||
\end{itemize}
|
||||
Ainsi l'augmentation du \rtt{} est souvent signe que le réseau se congestionne.
|
||||
Mais interpréter ces variations de \rtt{} et prendre la décision adéquate est trop complexe pour un algorithme classique, et certains ont déjà proposé des solutions utilisant de l'IA \cite{xiaoTCPDrincSmartCongestion2019,liQTCPAdaptiveCongestion2019,naDLTCPDeepLearningBased2019,lanDeepReinforcementLearning2019} .
|
||||
|
||||
\subsection{Comment gère-t-on la congestion avec l’implémentation classique de \coap{} ?}
|
||||
|
||||
Pour le \coap{}, la gestion de la congestion est différente, car on utilise une fenetre unitaire, c'est sur le \rto que se fait le travail.
|
||||
Pour le \coap{}, la gestion de la congestion est différente, car on utilise une fenêtre unitaire ; c'est sur le \rto que se fait le travail.
|
||||
Dans la version de base, le \rto{} de base est tiré aléatoirement entre $2 s$ et $3 s$, et est doublé à chaque retransmission.
|
||||
C'est un protocole simple mais peu performant, car si le delai de transition est déjà de l'ordre du \rto, alors il risque d'avoir des retransmission systèmatique.
|
||||
C'est un protocole simple mais peu performant, car si le délai de transmission est déjà de l'ordre du \rto, alors il risque d'y avoir des retransmissions systématiques.
|
||||
|
||||
Une des évolution du \coap{} est \cocoa{}, qui ne change que le \CCA{}\cite{ancillottiRTTBasedCongestionControl2018}.
|
||||
C'est une algorithme inspiré de FAST-\tcp{} et Compound-\tcp{}.
|
||||
Ici on met en place une estimation du \rtt{} à partir de la mesures du \rtt{} de chaque message.
|
||||
A chaque reception d'un nouveau \rtt{} $r$, on met à jour l'estimation grace aux formules suivantes :
|
||||
Une des évolutions du \coap{} est \cocoa{}, qui ne change que le \CCA{}\cite{ancillottiRTTBasedCongestionControl2018}.
|
||||
C'est un algorithme inspiré de FAST-\tcp{} et Compound-\tcp{}.
|
||||
Ici on met en place une estimation du \rtt{} à partir de la mesure du \rtt{} de chaque message.
|
||||
A chaque réception d'un nouveau \rtt{} $r$, on met à jour l'estimation grâce aux formules suivantes :
|
||||
\begin{equation}
|
||||
\begin{aligned}
|
||||
RTT_S &:= \alpha_S r + \left( 1 - \alpha_S \right) \cdot RTT_S\\
|
||||
|
|
@ -481,161 +481,161 @@ A chaque reception d'un nouveau \rtt{} $r$, on met à jour l'estimation grace au
|
|||
\end{aligned}
|
||||
\label{eq:cocoa:estimateur}
|
||||
\end{equation}
|
||||
Ensuite, on crée une fonction $T$ permetant de prendre une decision :
|
||||
Ensuite, on crée une fonction $T$ permettant de prendre une décision :
|
||||
\begin{equation}
|
||||
T\left( \gamma \right) = RTT_L + \gamma RTTVAR_L
|
||||
\label{eq:cocoa:decision}
|
||||
\end{equation}
|
||||
On a donc $4$ cas pour prendre un décision : \begin{itemize}
|
||||
\item $RTT_S < T\left( -1 \right)$ : pas de congestion, on peut etre beaucoup plus agressif,
|
||||
\item $T\left( -1 \right) \le RTT_S < T\left( +1 \right)$ : congestion faible, on se trouve à un point de fonctionement correct, on ne change rien, mais on peut aussi etre un peu plus agressif si besoin,
|
||||
\item $T\left( +1 \right) \le RTT_S < T\left( +2 \right)$ : congestion normal, la congestion augmente, il faut etre moins agressif pour ne pas congestioner le réseau,
|
||||
\item $T\left( +2 \right) \le RTT_S$ : congestion importante, le réseau est totalement congestioner, il faut etre beaucoup moins agressif.
|
||||
On a donc $4$ cas pour prendre une décision : \begin{itemize}
|
||||
\item $RTT_S < T\left( -1 \right)$ : pas de congestion, on peut être beaucoup plus agressif,
|
||||
\item $T\left( -1 \right) \le RTT_S < T\left( +1 \right)$ : congestion faible, on se trouve à un point de fonctionement correct, on ne change rien, mais on peut aussi être un peu plus agressif si besoin,
|
||||
\item $T\left( +1 \right) \le RTT_S < T\left( +2 \right)$ : congestion normale, la congestion augmente, il faut être moins agressif pour ne pas congestioner le réseau,
|
||||
\item $T\left( +2 \right) \le RTT_S$ : congestion importante, le réseau est totalement congestionné, il faut être beaucoup moins agressif.
|
||||
\end{itemize}
|
||||
La seule contrainte est que $\alpha_S \gg \alpha_L$.
|
||||
Le choix des autres valeurs, les seuils est les actions prisent sont choisit empiriquement, on ne sais pas si elles sont optimale.
|
||||
Le choix des autres valeurs, les seuils et les actions prises sont choisis empiriquement, on ne sait pas si elles sont optimales.
|
||||
|
||||
\subsection{Comment l'apprentissage machine prend place dans les \CCA{}?}
|
||||
Pour palier à ces problèmes, plusieurs \CCA{} utilisant de l'apprentissage machines sont apparut : Q-\tcp{}\cite{liQTCPAdaptiveCongestion2019}, \tcp{}-Drinc\cite{xiaoTCPDrincSmartCongestion2019}\dots
|
||||
L'idée derriere ses algorithme est de délégé la prise de decision à une IA qui serais capable de reconnaitre les signe de la congestion bien plus efficassement que une algorithme "fait-main" classique.
|
||||
Plusieurs problèmatique se présentent : \begin{itemize}
|
||||
\subsection{Comment l'apprentissage machine prend-il place dans les \CCA{}?}
|
||||
Pour pallier ces problèmes, plusieurs \CCA{} utilisant de l'apprentissage machine sont apparus : Q-\tcp{}\cite{liQTCPAdaptiveCongestion2019}, \tcp{}-Drinc\cite{xiaoTCPDrincSmartCongestion2019}\dots
|
||||
L'idée derriere ces algorithmes est de déléguer la prise de decision à une IA qui serait capable de reconnaître les signes de congestion bien plus efficacement qu'un algorithme "fait-main" classique.
|
||||
Plusieurs problèmatiques se présentent : \begin{itemize}
|
||||
\item La modélisation de l'environement : \begin{itemize}
|
||||
\item quel est $\mathbb{S}$, c'est à dire comment représenter l'environement pour l'acteur,
|
||||
\item quel est $\mathbb{A}$, c'est à dire qu'es ce que l'acteur doit donner comme consigne,
|
||||
\item quel est $r_t$, c'est à dire qu'es ce qu'une bonne action
|
||||
\item quel est $\mathbb{S}$, c'est-à-dire comment représenter l'environnement pour l'acteur,
|
||||
\item quel est $\mathbb{A}$, c'est-à-dire qu'est-ce que l'acteur doit donner comme consigne,
|
||||
\item quel est $r_t$, c'est à dire qu'est-ce qu'une bonne action
|
||||
\end{itemize}
|
||||
\item mais aussi des problèmes de compétition multi-agents: \begin{itemize}
|
||||
\item comment etre sûr que les ressource réseau sont équitablement répartie entre les agents,
|
||||
\item comment etre sûur que les agent IA ne vont pas perturber les agents non-IA,
|
||||
\item comment être sûr que les ressources réseau sont équitablement réparties entre les agents,
|
||||
\item comment être sûr que les agents IA ne vont pas perturber les agents non-IA,
|
||||
\end{itemize}
|
||||
\item ainsi que des problèmes d'implémentation, car tout cela toi tourner sur une machine très peu puissante et incapable de faire des calcul complexe.
|
||||
\item ainsi que des problèmes d'implémentation, car tout cela doit tourner sur une machine très peu puissante et incapable de faire des calculs complexes.
|
||||
\end{itemize}
|
||||
Les intégration de l'IA dans le \CC{} n'est encore qu'a l'état de test, de balbutiment, et pourtant des résultats notables et encouragant sont déjà disponible, voir figure \ref{fig:comp_cca_tcp}, ce qui nous motive à tenter de développer des solutions similaire pour \coap{}.
|
||||
L'intégration de l'IA dans le \CC{} n'est encore qu'à l'état de tests, de balbutiements, et pourtant des résultats notables et encourageants sont déjà disponibles, comme l'indique la figure \ref{fig:comp_cca_tcp}, ce qui nous motive à tenter de développer des solutions similaires pour \coap{}.
|
||||
|
||||
\section{Modélisation choisit}
|
||||
La première étape est de modélisé le système.
|
||||
Notre modélisation, s'appuis sur la modélisation de \cite{xiaoTCPDrincSmartCongestion2019}.
|
||||
La première étape est de modéliser le système.
|
||||
Notre modélisation s'appuie sur la modélisation de \cite{xiaoTCPDrincSmartCongestion2019}.
|
||||
|
||||
\subsection{Quels cas d'utilisations nous est le plus favorable ?}
|
||||
Pour notre travail, on se positionne dans une situation où un serveur centrale puissant voudrait récupérer des données sur un ensemble de capteur.
|
||||
Les contraites pour les codes s'éxécutant sur le serveur centrale (un serveur cloud généralement) et sur les capteur sont radicalement différentes.
|
||||
Le cloud peut exécuter le code qu'il veux avec beaucoup de puissance, alors que les capteur doivent se limité au maximum.
|
||||
Le could à acces au données de toutes les connexion, alors que les capteurs n'ont à priori que les données de leur connexion.
|
||||
On choisit de se placer dans le cas où on intéragie avec un nombre fixe de capteur, $N$.
|
||||
\subsection{Quel cas d'utilisation nous est le plus favorable ?}
|
||||
Pour notre travail, on se positionne dans une situation où un serveur central puissant voudrait récupérer des données sur un ensemble de capteurs.
|
||||
Les contraintes pour les codes s'exécutant sur le serveur central (un serveur cloud généralement) et sur les capteurs sont radicalement différentes.
|
||||
Le cloud peut exécuter le code qu'il veut avec beaucoup de puissance, alors que les capteurs doivent se limiter au maximum.
|
||||
Le could a accès aux données de toutes les connexions alors que les capteurs n'ont à priori que les données de leur connexion.
|
||||
On choisit de se placer dans le cas où on intéragit avec un nombre fixe de capteurs, $N$.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{puml/cas_utilisation_coap.png}
|
||||
\caption[Diagramme de séquance de transaction \coap{}, cas 1]{Diagramme de séquance entre le capteur et le serveur \coap{} avec déclanchement de la transaction par le capteur.}
|
||||
\caption[Diagramme de séquence de transaction \coap{}, cas 1]{Diagramme de séquence entre le capteur et le serveur \coap{} avec déclenchement de la transaction par le capteur.}
|
||||
\label{fig:seq_coap:1}
|
||||
\end{figure}
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{puml/cas_utilisation_coap_001.png}
|
||||
\caption[Diagramme de séquance de transaction \coap{}, cas 2]{Diagramme de séquance entre le capteur et le serveur \coap{} avec déclanchement de la transaction par le cloud, et réponse dans l'aquitement.}
|
||||
\caption[Diagramme de séquence de transaction \coap{}, cas 2]{Diagramme de séquence entre le capteur et le serveur \coap{} avec déclenchement de la transaction par le cloud et réponse dans l'acquittement.}
|
||||
\label{fig:seq_coap:2}
|
||||
\end{figure}
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{puml/cas_utilisation_coap_002.png}
|
||||
\caption[Diagramme de séquance de transaction \coap{}, cas 3]{Diagramme de séquance entre le capteur et le serveur \coap{} avec déclanchement de la transaction par le could, et réponse dans un message sépparré.}
|
||||
\caption[Diagramme de séquence de transaction \coap{}, cas 3]{Diagramme de séquence entre le capteur et le serveur \coap{} avec déclenchement de la transaction par le cloud et réponse dans un message séparé.}
|
||||
\label{fig:seq_coap:3}
|
||||
\end{figure}
|
||||
|
||||
Lorsque on veux établir une connexion avec un capteur, il y a trois cas de figure, il nous faut donc choisir celui qui nous avantage le plus. Le cas 1 (figure \ref{fig:seq_coap:1}) permet de réagir à un evenement, mais ne demande au capteur de prendre le rôle de gestionaire du \CC{}, ce qui n'est pas le plus simple.
|
||||
Le cas 2 (figure \ref{fig:seq_coap:2}) et 3 (figure \ref{fig:seq_coap:3}) permet tout deux au cloud de prendre en charge le \CC{}, mais le cas 3 demande l'échange de bien plus message, il sature plus vite le réseau.
|
||||
On choisit dans de travailler dans le cas 2, qui permet d'avoir à la fois toutes les informations au niveau de l'acteur, et de la puissance de calcul.
|
||||
Pour ce qui est de la gestion des evenement, on peu imaginé que le could envoie régulièrement au capteur des consigne siple pour le \CC{}, même si nous n'allons pas taiter cette problèmatique.
|
||||
Lorsque l'on veut établir une connexion avec un capteur, il y a trois cas de figure, il faut donc choisir celui qui nous avantage le plus. Le cas 1 (figure \ref{fig:seq_coap:1}) permet de réagir à un événement, mais demande au capteur de prendre le rôle de gestionnaire du \CC{}, ce qui n'est pas le plus simple.
|
||||
Les cas 2 (figure \ref{fig:seq_coap:2}) et 3 (figure \ref{fig:seq_coap:3}) permettent tous deux au cloud de prendre en charge le \CC{}, mais le cas 3 demande l'échange de bien plus de messages et sature plus vite le réseau.
|
||||
On choisit donc de travailler dans le cas 2, qui permet d'avoir à la fois toutes les informations au niveau de l'acteur, et de la puissance de calcul.
|
||||
Pour ce qui est de la gestion des événements, on peut imaginer que le cloud envoie régulièrement au capteur des consignes simples pour le \CC{}, même si nous n'allons pas traiter cette problématique.
|
||||
|
||||
\subsection{Quelle sont les variables que nous pouvons observer ?}
|
||||
\subsection{Quelles sont les variables que nous pouvons observer ?}
|
||||
|
||||
La grandeur la plus simple à se représenter est le \rtt{}.
|
||||
Chaque envoie de message permet de récupérer un echantillion de \rtt{}.
|
||||
Mais un problème se pose lorsque le \rto{} de base est plus faible que le \rtt{} à cause des retransmissions : on ne sais pas si l'aquitement vient de l'original ou de la rentransmition, car ils ont le même token.
|
||||
Par exemple, dans la figure \ref{fig:temp_coap:valide}, on à sans ambiguité un \rto{} de $25$, mais dans la figure \ref{fig:temp_coap:invalide}, le \rto{} semble etre $5$ alors que il est de $30$.
|
||||
Ce problème peut etre contourné en changeant le token dans les retransmissions, mais nous ne metterons pas en place cette solution pour l'instant.
|
||||
Chaque envoi de message permet de récupérer un échantillon de \rtt{}.
|
||||
Mais un problème se pose lorsque le \rto{} de base est plus faible que le \rtt{} à cause des retransmissions : on ne sait pas si l'acquittement vient de l'original ou de la retransmission, car ils ont le même token.
|
||||
Par exemple, dans la figure \ref{fig:temp_coap:valide}, on a sans ambiguïté un \rto{} de $25$, mais dans la figure \ref{fig:temp_coap:invalide}, le \rto{} semble être $5$ alors qu'il est de $30$.
|
||||
Ce problème peut être contourné en changeant le token dans les retransmissions, mais nous ne metterons pas en place cette solution pour l'instant.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[scale = 0.7]{puml/temporal_transaction_valide.png}
|
||||
\caption{Diagramme temporelle d'un transaction sans ambiguité du \rtt{}.}
|
||||
\caption{Diagramme temporel d'une transaction sans ambiguïté du \rtt{}.}
|
||||
\label{fig:temp_coap:valide}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[scale = 0.7]{puml/temporal_transaction_invalide.png}
|
||||
\caption{Diagramme temporelle d'un transaction avec ambiguité du \rtt{}.}
|
||||
\caption{Diagramme temporel d'une transaction avec ambiguïté du \rtt{}.}
|
||||
\label{fig:temp_coap:invalide}
|
||||
\end{figure}
|
||||
|
||||
L'autre grandeur que l'ont peur facilement mesuré est le nombre de retransmission de chaque message.
|
||||
C'est retransmission peuvent etre dû à la congestion, mais aussi à des erreures de routage ou des couches réseau physique.
|
||||
L'autre grandeur que l'on peut facilement mesurer est le nombre de retransmissions de chaque message.
|
||||
Ces retransmissions peuvent être dues à la congestion mais aussi à des problèmes de routage ou à des erreurs de couches réseaux physiques.
|
||||
|
||||
\subsection{Comment représenter un état du système ?}
|
||||
|
||||
Une fois que l'on a mesurer une grandeur, il faut la transmetre à l'acteur.
|
||||
Le premier problème est que l'acteur vois un temps discontinu, alors que les nouvelles mesures arrive à des instants irréguliers.
|
||||
On choisit donc de couper le temps en une série d'interval de longueur fixe.
|
||||
Dans ces intervals, on supose que l'état du réseau est constant, et les valeur utilisé par le \coap{} le sont aussi.
|
||||
Il faut prendre une durée de l'interval qui soit plus longue que le \rtt{}, car ainsi on ne se retrouve pas dans un cas limite où un message part pendant l'intervale $t$, avec les consignes de l'instant $t$, mais arrive dans l'instant $t+1$ et influe $s_{t+1}$ ou lieu de $s_t$.
|
||||
Mais il faut aussi que cette durée ne soit pas trop importante, car on ne change les consignes que à la fin de ces intervales.
|
||||
On nomme cet interval "interval de controle".
|
||||
Une fois que l'on a mesuré une grandeur, il faut la transmettre à l'acteur.
|
||||
Le premier problème est que l'acteur voit un temps discontinu, alors que les nouvelles mesures arrivent à des instants irréguliers.
|
||||
On choisit donc de couper le temps en une série d'intervalles de longueur fixe.
|
||||
Dans ces intervalles, on supose que l'état du réseau est constant, et les valeurs utilisées par le \coap{} le sont aussi.
|
||||
Il faut prendre une durée de l'intervalle qui soit plus longue que le \rtt{}, car ainsi on ne se retrouve pas dans un cas limite où un message part pendant l'intervalle $t$, avec les consignes de l'instant $t$, mais arrive dans l'instant $t+1$ et influe $s_{t+1}$ au lieu de $s_t$.
|
||||
Il faut aussi que cette durée ne soit pas trop importante, car on ne change les consignes qu'à la fin de ces intervalles.
|
||||
On nomme cet intervalle "intervalle de contrôle".
|
||||
|
||||
De plus, on travail sur un réseau de capteur qui renvoie leurs informations à un serveur cloud unique.
|
||||
De plus, on travaille sur un réseau de capteurs qui renvoient leurs informations à un serveur cloud unique.
|
||||
Puisque le serveur cloud centralise toutes les connexions, on choisit d'avoir un seul agent, qui donne des consignes pour toutes les connexions.
|
||||
|
||||
Pour la suite, on appel "serveur \coap{}" la partie de programme s'executant sur les capteurs, et "clients \coap{}" les programmes s'éxecutant sur le serveur cloud afin de récupérer les données des capteurs.
|
||||
On remarque aussi que on ne fait pas la différence entre l'état du réseau et l'observation que l'on en fait.
|
||||
Pour la suite, on appelle "serveur \coap{}" la partie de programme s'exécutant sur les capteurs, et "clients \coap{}" les programmes s'éxecutant sur le serveur cloud afin de récupérer les données des capteurs.
|
||||
On remarque aussi qu'on ne fait pas la différence entre l'état du réseau et l'observation que l'on en fait.
|
||||
|
||||
\subsubsection{État d'un client seul.}
|
||||
Pour commencer, il faut que chaque client \coap{} soit capable de représenter sa connexion.
|
||||
Pour cela, on dispose de : \begin{itemize}
|
||||
\item le nombre de messages envoyer penant l'interval de control,
|
||||
\item le nombre de messages envoyés pendant l'intervalle de contrôle,
|
||||
\item et pour chaque message : \begin{itemize}
|
||||
\item le nombre de retransmission,
|
||||
\item le \rtt{} mesurer.
|
||||
\item le nombre de retransmissions,
|
||||
\item le \rtt{} mesuré.
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
On construit ensuite les valeurs suivantes : \begin{itemize}
|
||||
\item $RTT_{min}$, le minimum du \rtt{} pendant les $n_m$ derniers interval de control,
|
||||
\item $\overline{RTT}$, la moyenne du \rtt{} sur l'interval de control,
|
||||
\item $RTT_{min}$, le minimum du \rtt{} pendant les $n_m$ derniers intervalles de contrôle,
|
||||
\item $\overline{RTT}$, la moyenne du \rtt{} sur l'intervalle de contrôle,
|
||||
\item $\eta = \frac{RTT_{min}}{\overline{RTT}}$
|
||||
\item $\nu = \frac{n_{retransmission}}{n_{message}}$
|
||||
\item $VARRTT = \frac{RTT_S}{RTT_L}$ à partir des deux valeurs suivantes, que on met à jour à chaque nouvel mesure du \rtt{} $r$ :\begin{align*}
|
||||
\item $VARRTT = \frac{RTT_S}{RTT_L}$ à partir des deux valeurs suivantes, que l'on met à jour à chaque nouvelle mesure du \rtt{} $r$ :\begin{align*}
|
||||
RTT_S &:= \alpha_S \cdot r + \left( 1 - \alpha_S \right) \cdot RTT_S \\
|
||||
RTT_L &:= \alpha_L \cdot r + \left( 1 - \alpha_L \right) \cdot RTT_L \\
|
||||
\alpha_S &\gg \alpha_L
|
||||
\end{align*}
|
||||
\end{itemize}
|
||||
|
||||
Ces valeurs sont plus représentative que les mesures brutes.
|
||||
$RTT_{min}$ permet d'estimé le temps de propagation des messages (on rappel que $RTT = \tau_{propagation} + \tau_{queue}$).
|
||||
Ainsi, $\eta$ permet d'estimer le pourcentage du temps passer dans les queues par les messages au cours de leur voyage.
|
||||
Lorsque $\eta$ est proche de $1$, c'est que les queues sont presque vide, et losque il est proche de $0$, c'est qu'elle represente la majorité de temps de trajet, ce qui est signe de congestion.
|
||||
$\nu$ represente le taux de redondane des messages, il doit etre le plus faible possible.
|
||||
$\nu$ élevé signifi que on revoie des messages et donc que les consignes ne sont pas adapté.
|
||||
Mais $\nu$ est aussi influancé par les défauts du réseau, donc ce n'est pas un indicateur parfait.
|
||||
$VARRTT$ permet d'estimer l'évolution du \rtt{} en comparant deux filtrages des \rtt{} sur des echelles différentes.
|
||||
Ces valeurs sont plus représentatives que les mesures brutes.
|
||||
$RTT_{min}$ permet d'estimer le temps de propagation des messages (on rappelle que $RTT = \tau_{propagation} + \tau_{queue}$).
|
||||
Ainsi, $\eta$ permet d'estimer le pourcentage du temps passé dans les queues par les messages au cours de leur voyage.
|
||||
Lorsque $\eta$ est proche de $1$, c'est que les queues sont presque vides, et lorsqu'il est proche de $0$, c'est qu'il représente la majorité du temps de trajet, ce qui est signe de congestion.
|
||||
$\nu$ représente le taux de redondance des messages, il doit être le plus faible possible.
|
||||
$\nu$ élevé signifie que on renvoie des messages, donc que les consignes ne sont pas adaptées.
|
||||
Mais $\nu$ est aussi influencé par les défauts du réseau, donc ce n'est pas un indicateur parfait.
|
||||
$VARRTT$ permet d'estimer l'évolution du \rtt{} en comparant deux filtrages des \rtt{} sur des échelles différentes.
|
||||
$VARRTT > 1$ indique que la tendance est à la hausse des \rtt{}, et donc que la longueur des queues augmente, et $VARRTT < 1$ que la tendance est à la baisse.
|
||||
Il faut tout de même que le filtrage $RTT_S$ se fasse sûr plusieurs echantillions du \rtt{} (donc $\alpha_S \sim 0.1$) car la mesure du \rtt{} est très bruité.
|
||||
Il faut tout de même que le filtrage $RTT_S$ se fasse sur plusieurs échantillons du \rtt{} (donc $\alpha_S \sim 0.1$) car la mesure du \rtt{} est très bruitée.
|
||||
|
||||
Une fois ces valeur calculer, on construit le vecteur suivant, qui represente l'état du client $i$ : \begin{equation}
|
||||
Une fois ces valeurs calculées, on construit le vecteur suivant, qui représente l'état du client $i$ : \begin{equation}
|
||||
s ^ {\left( i \right)}= \begin{bmatrix} \nu\\ \eta \\ VARRTT \end{bmatrix}
|
||||
\label{eq:modele:vec}
|
||||
\end{equation}
|
||||
|
||||
\subsubsection{État de l'ensemble des clients.}
|
||||
Une fois que chaque client a generé sont vecteur, il suffit de les concaténés pour crée une matrice où chaque ligne représente une des trois valeurs, et chaque colonne un client.
|
||||
Une fois que chaque client a généré son vecteur, il suffit de les concaténer pour créer une matrice où chaque ligne représente une des trois valeurs, et chaque colonne un client.
|
||||
\begin{equation}
|
||||
S = \begin{bmatrix} s ^ {(0)} & \cdots & s^{(N)} \end{bmatrix}
|
||||
\label{eq:modele:mat}
|
||||
\end{equation}
|
||||
L'avantage d'une tel matrice est que on pourra utiliser une convolution dans le réseau de nerrone.
|
||||
Une autre possibilité, qui est de concaténer les matrices de plusieur echantillion de temps successif pour crée un tenseur à trois dimension, qui permetrait d'avoir plus d'informations sur l'évolution temporelle des valeurs, n'a pas pu etre testée.
|
||||
L'avantage d'une telle matrice est que l'on pourra utiliser une convolution dans le réseau de neurones.
|
||||
Une autre possibilité, qui est de concaténer les matrices de plusieurs échantillon de temps successifs pour créer un tenseur à trois dimensions, qui permettrait d'avoir plus d'informations sur l'évolution temporelle des valeurs, n'a pas pu être testée.
|
||||
|
||||
\subsection{Comment l'acteur influance le client \coap{} ?}
|
||||
La principales valeur permetant de controler le comportement du client est le \rto{}.
|
||||
\subsection{Comment l'acteur influence-t-il le client \coap{} ?}
|
||||
La principale valeur permettant de contrôler le comportement du client est le \rto{}.
|
||||
On choisit une solution où $\mathbb{A} = \R ^ N$.
|
||||
Si on note $c_t$ le vecteur des $N$ \rto{} à l'instant $t$, et $a_t$ le vecteur d'action généré par l'acteur, alors :
|
||||
\begin{equation}
|
||||
|
|
@ -645,157 +645,157 @@ Si on note $c_t$ le vecteur des $N$ \rto{} à l'instant $t$, et $a_t$ le vecteur
|
|||
\end{cases}
|
||||
\end{equation}
|
||||
L'effet de cette action est visible dans la figure \ref{fig:modele:action}.
|
||||
Cette action permet d'avoir la capacité de réagir rapidement avec des grandes actions, mais aussi d'avoir de la précision pour s'ajuster autour du point de fonctionement.
|
||||
Cette action permet d'avoir la capacité de réagir rapidement avec des grandes actions, mais aussi d'avoir de la précision pour s'ajuster autour du point de fonctionnement.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width = 0.7\textwidth]{png_img/gain_action.png}
|
||||
\caption[Modification du \rto{} par l'action.]{Modification du \rto{} par l'action, pour un seul client, en échelle logaritmique.}
|
||||
\caption[Modification du \rto{} par l'action.]{Modification du \rto{} par l'action, pour un seul client, en échelle logarithmique.}
|
||||
\label{fig:modele:action}
|
||||
\end{figure}
|
||||
|
||||
D'autre choix sont possibles, par exemple $\mathbb{A} = \left\lbrace 0.1, 0.5, 0.8, 1, 1.25, 2, 10 \right\rbrace ^ N$, et $c ^ {\left( i \right))} _{t+1} c_t ^ {\left( i \right))} \cdot a _ t ^ {\left( i \right))} $
|
||||
D'autres choix sont possibles, par exemple $\mathbb{A} = \left\lbrace 0.1, 0.5, 0.8, 1, 1.25, 2, 10 \right\rbrace ^ N$, et $c ^ {\left( i \right))} _{t+1} c_t ^ {\left( i \right))} \cdot a _ t ^ {\left( i \right))} $
|
||||
|
||||
\subsection{Comment quantifier la réussite de l'agent ?}
|
||||
Une fois que l'on sais représenter l'état du réseau, il faut déterminer si cette état est favorable ou non.
|
||||
Pour cela, il faut se demander ce que l'on veux comme caractéristique.
|
||||
Les critaires choisit sont : \begin{itemize}
|
||||
\item Le delai est le plus petit possible, pour avoir un système réactif,
|
||||
\item il y a peu de retransmission, pour ne pas encombrer le réseau et abusé des ressources energetiques des capteurs,
|
||||
\item il y a tres peu d'echec, c'est à dire de message qui dépasse le nombre de retransmission maximal,
|
||||
\item le nombre de message envoyé est equitablement répartie entre les clients.
|
||||
Une fois que l'on sait représenter l'état du réseau, il faut déterminer si cet état est favorable ou non.
|
||||
Pour cela, il faut se demander ce que l'on veut comme caractéristiques.
|
||||
Les critaires choisis sont : \begin{itemize}
|
||||
\item Le délai est le plus petit possible, pour avoir un système réactif,
|
||||
\item il y a peu de retransmissions, pour ne pas encombrer le réseau et abuser des ressources énergétiques des capteurs,
|
||||
\item il y a très peu d'échecs, c'est-à-dire de messages qui dépassent le nombre de retransmissions maximal,
|
||||
\item le nombre de message envoyés est équitablement réparti entre les clients.
|
||||
\end{itemize}
|
||||
|
||||
L'équité est une grandeur permetant de mesurer si certain capteurs utilise plus le réseau que d'autre.
|
||||
Elle est définie pas \cite{jainQuantitativeMeasureFairness1998} pour un grandeur quelconque $\left( x_i \right) \in {\left(\R ^ {+}\right)} ^ N$:
|
||||
L'équité est une grandeur permettant de mesurer si certains capteurs utilisent plus le réseau que d'autres.
|
||||
Elle est définie par \cite{jainQuantitativeMeasureFairness1998} pour une grandeur quelconque $\left( x_i \right) \in {\left(\R ^ {+}\right)} ^ N$:
|
||||
\begin{equation}
|
||||
f_A (x_i) = \frac{\left[ \sum_{k = 1}^N x_k \right] ^ 2 }{N \cdot \sum_{k = 1}^N x_k^2 }
|
||||
\label{eq:modele_fair_base}
|
||||
\end{equation}
|
||||
Ainsi un système totalement équitable (où tout les $x_i$ sont égaux) à une équité de $1$ et un système non-équitable à une équité d'autant proche de $0$ qu'il est inéquitable.
|
||||
Mais cette indice d'équité ne prend pas en compte que certain utilisateur on besoin de plus de ressource que d'autre.
|
||||
Ainsi on modifie l'équation \ref{eq:modele_fair_base} pour prende un compte un besoin $\left( b_i \right) \in {\left(\R ^ {+}\right)} ^ N$ :
|
||||
Ainsi un système totalement équitable (où tous les $x_i$ sont égaux) a une équité de $1$ et un système non-équitable a une équité d'autant plus proche de $0$ qu'il est inéquitable.
|
||||
Mais cet indice d'équité ne prend pas en compte que certains utilisateurs ont besoin de plus de ressources que d'autres.
|
||||
Ainsi on modifie l'équation \ref{eq:modele_fair_base} pour prendre en compte un besoin $\left( b_i \right) \in {\left(\R ^ {+}\right)} ^ N$ :
|
||||
\begin{equation}
|
||||
f_A (x_i, b_i) = \frac{\left[ \sum_{k = 1}^N \frac{x_k}{b_k} \right] ^ 2 }{N \cdot \sum_{k = 1}^N \left( \frac{x_k}{b_k} \right)^2 }
|
||||
\label{eq:modele_fair_pond}
|
||||
\end{equation}
|
||||
|
||||
Le schéma de récompence est donc, à partir des données du derniers interval de control :
|
||||
Le schéma de récompense est donc, à partir des données du dernier intervalle de contrôle :
|
||||
\begin{equation}
|
||||
r = - \beta _ \nu \frac{\sum_{k=1}^N x^e _ k}{\sum_{k=1}^N x^t_k} - \beta_\text{echec} n_\text{echec} - \beta_{RTT} max_{k} \overline{RTT} _ k + \beta_\text{equite} \frac{\left[ \sum_{k = 1}^N \frac{n^e_k}{n^t_k} \right] ^ 2 }{N \cdot \sum_{k = 1}^N \left( \frac{n^e_k}{n^t_k} \right)^2 }
|
||||
\label{eq:modele:recompence}
|
||||
\label{eq:modèle:récompense}
|
||||
\end{equation}
|
||||
Où $n^e$ est le nombre de message envoyé, emition initial et retransmission, et $n^t$ le nombre de transaction, c'est à dire uniquement les émitions initiales.
|
||||
$n_\text{echec}$ est le nombre de transaction ayant échouée.
|
||||
Les facteurs $\beta$ permetent de pondérer l'effet des différentes composante.
|
||||
Où $n^e$ est le nombre de messages envoyés, émission initiale et retransmissions, et $n^t$ le nombre de transactions, c'est-à-dire uniquement les émissions initiales.
|
||||
$n_\text{echec}$ est le nombre de transactions ayant échoué.
|
||||
Les facteurs $\beta$ permettent de pondérer l'effet des différentes composantes.
|
||||
|
||||
\subsection{Quel type d'agent utilisé ? \label{part:description_boucle}}
|
||||
Maintenant que l'environement est fixé, on peut déterminer comment l'acteur va s'intégrer.
|
||||
On choisit le fonctionement suivant : \begin{itemize}
|
||||
\subsection{Quel type d'agent utiliser ? \label{part:description_boucle}}
|
||||
Maintenant que l'environnement est fixé, on peut déterminer comment l'acteur va s'intégrer.
|
||||
On choisit le fonctionnement suivant : \begin{itemize}
|
||||
\item L'acteur détermine $a_t$ en fonction de $s_t$,
|
||||
\item les clients utilise cet $a_t$ pour trouver leur consigne $c_t$,
|
||||
\item ils traitent toutes les transactions avec ses consigne pendant l'interval de control,
|
||||
\item a la fin de l'interval de control, on fait la synthèse des données, on calcule $s_{t+1}$ et $r_t$,
|
||||
\item les clients utilisent cet $a_t$ pour trouver leurs consignes $c_t$,
|
||||
\item ils traitent toutes les transactions avec ces consignes pendant l'intervalle de contrôle,
|
||||
\item à la fin de l'intervalle de contrôle, on fait la synthèse des données, on calcule $s_{t+1}$ et $r_t$,
|
||||
\item on enregistre $\left( s_t, a_t, r_t, s_{t+1} \right)$,
|
||||
\item on recommence avec $s_{t+1}$
|
||||
\end{itemize}
|
||||
Cela represente le fonctionnement normal du système.
|
||||
Cela représente le fonctionnement normal du système.
|
||||
|
||||
Mais en plus de cela, il faut que l'on fasse s'optimisé la politique.
|
||||
Pour cela on va procédé en deux temps : \begin{enumerate}
|
||||
\item Le pré-entrainement,
|
||||
\item l'entrainement en position.
|
||||
Mais en plus de cela, il faut que l'on fasse s'optimiser la politique.
|
||||
Pour cela on va procéder en deux temps : \begin{enumerate}
|
||||
\item Le pré-entraînement,
|
||||
\item l'entraînement en position.
|
||||
\end{enumerate}
|
||||
Le pré-entrainement se déroule avant le déploiment du réseau de capteur.
|
||||
Il consiste à rendre la politique proche de ce qui est attendu pour que elle soit exploitable, même si elle n'est pas encore optimal.
|
||||
Le pré-entraînement se déroule avant le déploiment du réseau de capteurs.
|
||||
Il consiste à rendre la politique proche de ce qui est attendu pour qu'elle soit exploitable, même si elle n'est pas encore optimale.
|
||||
Pour cela, il faut généré de l'expérience (les transitions $\left( s_t, a_t, r_t, s_{t+1} \right)$ que on a vu plus haut), et l'utilisé pour optimisé la politique.
|
||||
Cette génération peut se faire de plusieur manière que on évoquera plus tard.
|
||||
Une fois que la politique est correct, on peut la déployer sur le réseau de capteur réel.
|
||||
Mais elle n'est pas fixe, puisque on continue à l'optimisé avec de l'exprérence récolté sur le réseau réel.
|
||||
Cette génération peut se faire de plusieurs manières, que on évoquera plus tard.
|
||||
Une fois que la politique est correcte, on peut la déployer sur le réseau de capteurs réels.
|
||||
Mais elle n'est pas fixe, puisqu'on continue à l'optimiser avec de l'expérience récoltée sur le réseau réel.
|
||||
|
||||
\subsection{Quelle politique $\pi$ est utilisé ?}
|
||||
Au vu de la taille des espaces $\mathbb{S}$ et $\mathbb{A}$, on ne peut pas utilisé un Q-table car elle demanderais bien trop d'espaces mémoire.
|
||||
On utilise donc un réseau de neurrones pour approximé la Q-table.
|
||||
Les subtilités de cette approximation, ainsi que la discretisation de $\mathbb{S}$ et $\mathbb{A}$ sont pris en charge par \TF{}.
|
||||
\subsection{Quelle politique $\pi$ est utilisée ?}
|
||||
Au vu de la taille des espaces $\mathbb{S}$ et $\mathbb{A}$, on ne peut pas utiliser une Q-table car elle demanderait bien trop d'espace mémoire.
|
||||
On utilise donc un réseau de neurones pour approximer la Q-table.
|
||||
Les subtilités de cette approximation, ainsi que la discrétisation de $\mathbb{S}$ et $\mathbb{A}$, sont pris en charge par \TF{}.
|
||||
|
||||
Puisque on est en apprentissage permanant, il faut utilisé une politique $\epsilon$-glouton.
|
||||
C'est à dire que pendant la majorité du temps, on se trouve en phase d'exploitation, et on execute l'action optimal.
|
||||
Mais avec une probabilité $\epsilon$, on réalise une action aléatoire, afin de tester de nouvelle possibilité.
|
||||
Puisqu'on est en apprentissage permanent, il faut utiliser une politique $\epsilon$-glouton.
|
||||
C'est-à-dire que pendant la majorité du temps on se trouve en phase d'exploitation, et on exécute l'action optimale.
|
||||
Mais avec une probabilité $\epsilon$, on réalise une action aléatoire, afin de tester de nouvelles possibilités.
|
||||
C'est important car on ne se trouve pas dans un système déterministe, donc il ne suffit pas de tester une fois toutes les transitions.
|
||||
|
||||
Pour ce qui est du réseau de neurrones, on ne travaille pour l'instant que avec un réseau feed-forward, mais on peut envisagé d'utilisé des réseaux plus complexes.
|
||||
Pour ce qui est du réseau de neurones, on ne travaille pour l'instant qu'avec un réseau feed-forward, mais on peut envisager d'utiliser des réseaux plus complexes.
|
||||
|
||||
\subsection{Comment récolté de l'expérience ?}
|
||||
\subsection{Comment récolter de l'expérience ?}
|
||||
|
||||
La recolte de transition est indipensable pour pouvoir optimisé la politique.
|
||||
La récolte in situ est lente, en effet, il faut généralement $10000$ transitions pour réalisé un pas d'optimisation.
|
||||
On peut descendre jusqu'à $1000$, mais le résultats est moins stable.
|
||||
De plus, avec une durée d'interval de controle de $30$s, on se retrouve à devoir attendre $8h$ par pas d'optimisation.
|
||||
Il faut donc trouver des solutions plus rapide que l'exploration simple si on veux pouvoir faire une centaine de pas d'apprentissage pour atteindre une convergence.
|
||||
La récolte de transitions est indipensable pour pouvoir optimiser la politique.
|
||||
La récolte in situ est lente ; en effet, il faut généralement $10000$ transitions pour réaliser un pas d'optimisation.
|
||||
On peut descendre jusqu'à $1000$, mais le résultat est moins stable.
|
||||
De plus, avec une durée d'intervalle de contrôle de $30$s, on se retrouve à devoir attendre $8h$ par pas d'optimisation.
|
||||
Il faut donc trouver des solutions plus rapides que l'exploration simple si on veut pouvoir faire une centaine de pas d'apprentissage pour atteindre une convergence.
|
||||
|
||||
\subsubsection{Par exploration en simulateur}
|
||||
Une solution simple, en théorie, est d'utilisé un simulateur.
|
||||
Une solution simple, en théorie, est d'utiliser un simulateur.
|
||||
Le plus utilisé est \ns{}.
|
||||
C'est un simulateur à envenement discret, destiné à la simulation de réseau informatique permetant de travaillier sur toute les couches du modèle \osi{}.
|
||||
Ainsi on peut entrainer le simulateur avec la topologie du réseau que l'on veux, et la qualité des connexions sans fils que l'on veux.
|
||||
Malheureusment, c'est un simulateur complexe à utilisé : tout les scripts de simulation sont écrit en \cpp{}.
|
||||
Par manque de temps et de compétence, les simulations sur \ns{} n'ont pas pu etre réalisé, mais cela reste une piste à étudier pour le pré-entrainement.
|
||||
C'est un simulateur à événements discrets, destiné à la simulation de réseau informatique permettant de travaillier sur toutes les couches du modèle \osi{}.
|
||||
Ainsi on peut entraîner le simulateur avec la topologie du réseau que l'on veut, et la qualité des connexions sans fil que l'on veut.
|
||||
Malheureusment, c'est un simulateur complexe à utiliser : tous les scripts de simulation sont écrit en \cpp{}.
|
||||
Par manque de temps et de compétence, les simulations sur \ns{} n'ont pas pu être réalisées, mais cela reste une piste à étudier pour le pré-entraînement.
|
||||
|
||||
\subsubsection{Par création artificiel de transition\label{part:yaml}}
|
||||
\subsubsection{Par création artificielle de transitions\label{part:yaml}}
|
||||
|
||||
Une autre méthode possible est de créer des transitions artificiellement.
|
||||
Pour cela, l'algorithme commence par fixer une charge sur le réseau $f$, c'est à dire la fréquence à laquelle chaque client intéroge le capteur associé.
|
||||
Celon cette charge, le réseau est plus ou moins congestioner.
|
||||
Ensuite l'algorithme prend plusieurs consigne de \rto{} $c_n$, et pour chaque consigne, l'algorithme l'applique à l'agent, et mesure le vecteur d'observation associé $s_n$ ainsi que $r_n$.
|
||||
Pour cela, l'algorithme commence par fixer une charge sur le réseau $f$, c'est-à-dire la fréquence à laquelle chaque client interroge le capteur associé.
|
||||
Selon cette charge, le réseau est plus ou moins congestionné.
|
||||
Ensuite l'algorithme prend plusieurs consignes de \rto{} $c_n$, et pour chaque consigne, l'algorithme l'applique à l'agent et mesure le vecteur d'observation associé $s_n$ ainsi que $r_n$.
|
||||
Puis pour chaque couple $(s_n, s_m)$, l'algorithme calcule l'action $a_{n , m}$ pour passer de $c_n$ à $c_m$.
|
||||
L'algorithme peu ainsi construire une série de trnasition $s_n, a_{n, m}, r_m, s_m$.
|
||||
L'algorithme peut ainsi construire une série de transitions $s_n, a_{n, m}, r_m, s_m$.
|
||||
On recommence avec un autre $f$
|
||||
|
||||
Ces transitions sont uniquements des approximation, car elles ne tiennent pas réelement compte des effets de $s_t$ sur $s_{t+1}$ liée au temps de probagation des message dans le système.
|
||||
Ces transitions sont uniquements des approximations car elles ne tiennent pas réellement compte des effets de $s_t$ sur $s_{t+1}$ liés au temps de propagation des messages dans le système.
|
||||
De plus elles supposent que la charge ne change pas sur le système.
|
||||
Malgrès cela, elle permet d'aller plus vite dans la génération de transition pour le pré-entrainement, car en $n$ interval de contrôl à $f$ fixe, on génère $n^2$ transitions.
|
||||
Malgré cela, elle permet d'aller plus vite dans la génération de transitions pour le pré-entraînement, car en $n$ intervalles de contrôle à $f$ fixe, on génère $n^2$ transitions.
|
||||
|
||||
\section{Implémentation de l'algorithme}
|
||||
L'implémentation de l'alforitme est réalisé en Python.
|
||||
Notre implémentation est une modifications d'un module existant, \coapthon{}, qui comprend déjà tout les codes pour réalisé un client ou un serveur \coap{}.
|
||||
De plus, pour la partie apprentissage, on utilise \TF{}, un module répendandu pour l'apprentissage machine.
|
||||
L'implémentation de l'algorithme est réalisée en Python.
|
||||
Notre implémentation est une modifications d'un module existant, \coapthon{}, qui comprend déjà tous les codes pour réaliser un client ou un serveur \coap{}.
|
||||
De plus, pour la partie apprentissage, on utilise \TF{}, un module répandu pour l'apprentissage machine.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width = \textwidth]{puml/classe.png}
|
||||
\caption[Diagramme de classe]{Diagramme de classe de notre système. La partie apprentissage n'est pas représentée. Seul les atribues et méthodes d'intérées sont représentées.}
|
||||
\caption[Diagramme de classe]{Diagramme de classe de notre système. La partie apprentissage n'est pas représentée. Seuls les attributs et méthodes d'intérêt sont représentés.}
|
||||
\label{fig:imple:class}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Modules uilisés}
|
||||
Les modules que nous utilisont ont leur propre interface et fonctionnement internet auquelle nous devont nous adapter.
|
||||
Les modules que nous utilisons ont leur propre interface et fonctionnement Internet, auxquels nous devont nous adapter.
|
||||
|
||||
\paragraph{\coapthon{}}, pour sa partie client, utilise deux objets (voir figure \ref{fig:imple:class}) : \begin{itemize}
|
||||
\item \mintinline{python}{coapthon.cient.helperclient.HelperClient}, qui permet d'avoir acces à des méthodes simple tel que \mintinline{python}{HelperClient.get(url)},
|
||||
\item \mintinline{python}{coapthon.cient.helperclient.HelperClient}, qui permet d'avoir accès à des méthodes simples telles que \mintinline{python}{HelperClient.get(url)},
|
||||
\item \mintinline{python}{coapthon.cient.coap.CoAP}, qui implémente la gestion des retransmissions, que l'on doit modifier.
|
||||
\end{itemize}
|
||||
|
||||
Il y aussi une partie serveur, mais nous ne la modifions pas du tout.
|
||||
C'est elle qui joue le role de serveur \coap{} sur les \rasp{}.
|
||||
Il y a aussi une partie serveur, mais nous ne la modifions pas du tout.
|
||||
C'est elle qui joue le rôle de serveur \coap{} sur les \rasp{}.
|
||||
|
||||
\paragraph{\TF{} et \keras{}} sont des modules \python{} fournissant les outils nessessaire à l'entrainement de modèle d'IA.
|
||||
\TF{} s'occupe des fonctions hautes, avec les outils permetant de mettre en place la boucle d'apprentissage
|
||||
\paragraph{\TF{} et \keras{}} sont des modules \python{} fournissant les outils nécessaires à l'entraînement de modèles d'IA.
|
||||
\TF{} s'occupe des fonctions hautes, avec les outils permettant de mettre en place la boucle d'apprentissage.
|
||||
Pour cela, il a besoin que l'on mette l'environement sous un format spécial : l'interface \gym{}.
|
||||
Cette interface peremt la standardisation des interfaces des environements.
|
||||
Pour cela, il faut définir une nouvelle classe, héritant de \code{tf_agents.environements.py_environement.PyEnvironement}, et surchargant les atribues et méthodes suivantes :
|
||||
Cette interface permet la standardisation des interfaces des environnements.
|
||||
Pour cela, il faut définir une nouvelle classe, héritant de \code{tf_agents.environements.py_environement.PyEnvironement}, et surchargeant les attributs et méthodes suivantes :
|
||||
\begin{enumerate}
|
||||
\item \code{.action_spec}, avec un objets de \code{tf_agents.specs.array_spec}, pour décrire l'espaces d'action $\mathbb{A}$,
|
||||
\item \code{.observation_spec}, avec un objets de \code{tf_agents.specs.array_spec}, pour décrire l'espaces d'observation $\mathbb{S}$,
|
||||
\item \code{.action_spec}, avec un objet de \code{tf_agents.specs.array_spec}, pour décrire l'espace d'action $\mathbb{A}$,
|
||||
\item \code{.observation_spec}, avec un objet de \code{tf_agents.specs.array_spec}, pour décrire l'espace d'observation $\mathbb{S}$,
|
||||
\item \code{._reset()}, qui doit renvoyer un objet \code{tf_agents.trajectories.time_step.transition},
|
||||
\item \code{._step(action)}, qui doit renvoyer un objet \code{tf_agents.trajectories.time_step.transition} ou \code{tf_agents.trajectories.time_step.termination}.
|
||||
\end{enumerate}
|
||||
Les deux premier permetent de signalé à l'agent quelle valeurs sont autoriser.
|
||||
Les troisième permet de remettre l'environement dans un état initial.
|
||||
Les deux premiers permettent de signaler à l'agent quelles valeurs sont autorisées.
|
||||
Le troisième permet de remettre l'environnement dans un état initial.
|
||||
Le quatrième est le plus important, car il représente le passage d'un pas de temps.
|
||||
Les transitions sont les objets $\left( s_t, a_t, r_t, s_{t+1} \right)$.
|
||||
|
||||
\keras{} quant à lui, permet l'utilisation et la manipulation des réseaux de neurrone.
|
||||
Puisque on n'utilise que des réseaux simple, les fonctionalités du module ne seront donc pas abordées.
|
||||
\keras{} quant à lui, permet l'utilisation et la manipulation des réseaux de neurones.
|
||||
Puisqu'on n'utilise que des réseaux simples, les fonctionalités du module ne seront pas abordées.
|
||||
|
||||
|
||||
\subsection{Structure du code}
|
||||
|
|
@ -806,33 +806,33 @@ Puisque on n'utilise que des réseaux simple, les fonctionalités du module ne s
|
|||
\caption{Composants simplifiés de notre implémentation.}
|
||||
\end{wrapfigure}
|
||||
|
||||
La figure \ref{fig:call_stack} résume les appels de fonction au cours d'une requette \coap{}.
|
||||
La figure \ref{fig:call_stack} résume les appels de fonctions au cours d'une requête \coap{}.
|
||||
La modification du client \coapthon{} consiste en l'ajout d'un composant, le \code{SuperviseurLocal}.
|
||||
Ce composant permet de changer la manière dont le \rto{} est choisit, et d'enregistré les \rto{}.
|
||||
Il y a ensuite un \code{SuperviseurGlobal} qui supervise tout les \code{SuperviseurLocal} du réseau pour générer les matrices d'état.
|
||||
C'est aussi ce \code{SuperviseurGlobal} qui distribut les consignes à tous les \code{SuperviseurLocal}.
|
||||
Ce composant permet de changer la manière dont le \rto{} est choisi, et d'enregistrer les \rto{}.
|
||||
Il y a ensuite un \code{SuperviseurGlobal} qui supervise tous les \code{SuperviseurLocal} du réseau pour générer les matrices d'état.
|
||||
C'est aussi ce \code{SuperviseurGlobal} qui distribue les consignes à tous les \code{SuperviseurLocal}.
|
||||
|
||||
La procedure lors de l'envoie d'un message est visible dans la figure \ref{fig:call_stack}.
|
||||
Les modifications réalisées ne sont que l'ajout d'appel de fonction courte pour enregistré les timestamps de départ de transmission et retransmission, et la réception des aquitements/réponses.
|
||||
La procédure lors de l'envoi d'un message est visible dans la figure \ref{fig:call_stack}.
|
||||
Les modifications réalisées ne sont que l'ajout d'appels de fonctions courtes pour enregistrer les timestamps de départ de transmission et retransmission, et la réception des acquittements/réponses.
|
||||
|
||||
\subsubsection{Modification de \coapthon{}}
|
||||
On rajout à la classe \code{client.CoAP} un membre, le \code{SuperviseurLocal}.
|
||||
On modifie \code{client.CoAP.send_datagram} pour enregistré l'envoie d'un datagram, transmission ou retransmission, en fonction du token utilisé.
|
||||
On modifie aussi \code{client.CoAP.send_datagram._start_retransmission} pour que ce soit le superviseur qui done le \rto{}.
|
||||
On modifie finalement \code{client.CoAP.receive_datagram} pour enregistré les recepetion de messages en fonction de leurs tokens.
|
||||
On rajoute à la classe \code{client.CoAP} un membre, le \code{SuperviseurLocal}.
|
||||
On modifie \code{client.CoAP.send_datagram} pour enregistrer l'envoi d'un datagram, transmission ou retransmission, en fonction du token utilisé.
|
||||
On modifie aussi \code{client.CoAP.send_datagram._start_retransmission} pour que ce soit le superviseur qui donne le \rto{}.
|
||||
On modifie finalement \code{client.CoAP.receive_datagram} pour enregistrer les réceptions de messages en fonction de leurs tokens.
|
||||
|
||||
Je définie plusieurs type de \code{SuperviseurLocal} : \begin{itemize}
|
||||
\item \code{SuperviseurLocalPlaceHolder}, qui est utilisé par défaut est n'a aucune fonctionalités, et qui réutilise la génération de \rto{} de base dans \coapthon{},
|
||||
\item \code{SuperviseurLocal}, qui prend en charge l'enregistrement des \rto{}, la moyenne et le minimum, et qui est capable d'utilisé un \rto{} détérminé par l'IA,
|
||||
\item \code{SuperviseurLocalFiltre}, qui prend aussi en charge le filtrage exponentielle pour généré $RTT_L$ et $RTT_S$.
|
||||
Je définis plusieurs types de \code{SuperviseurLocal} : \begin{itemize}
|
||||
\item \code{SuperviseurLocalPlaceHolder}, qui est utilisé par défaut et n'a aucune fonctionalité, et qui réutilise la génération de \rto{} de base dans \coapthon{},
|
||||
\item \code{SuperviseurLocal}, qui prend en charge l'enregistrement des \rto{}, la moyenne et le minimum, et qui est capable d'utiliser un \rto{} déterminé par l'IA,
|
||||
\item \code{SuperviseurLocalFiltre}, qui prend aussi en charge le filtrage exponentiel pour générer $RTT_L$ et $RTT_S$.
|
||||
\end{itemize}
|
||||
|
||||
C'est la classe \code{SuperviseurGlobal} qui fournit le statistitiens permetant de généré les matrices d'état, ainsi que la distribution des consignes.
|
||||
Elle réalise aussi le calcul des récompences.
|
||||
C'est la classe \code{SuperviseurGlobal} qui fournit le statisticien permettant de générer les matrices d'état, ainsi que la distribution des consignes.
|
||||
Elle réalise aussi le calcul des récompenses.
|
||||
|
||||
\subsubsection{Boucle d'apprentissage}
|
||||
L'objet \code{Maquette} est l'objet qui intéragie avec l'agent IA.
|
||||
La methode la plus importante est \code{step(action)} qui prend l'action déterminer par l'IA comme entrée, l'applique
|
||||
L'objet \code{Maquette} est celui qui intéragit avec l'agent IA.
|
||||
La méthode la plus importante est \code{step(action)}, qui prend l'action déterminée par l'IA comme entrée, l'applique
|
||||
C'est donc cette méthode qui joue un rôle prédominant dans l'algorithme de la partie \ref{part:description_boucle}.
|
||||
|
||||
\begin{listing}[htp]
|
||||
|
|
@ -874,79 +874,79 @@ while True:
|
|||
tf_policy_saver.save(policy_dir)
|
||||
n_epoch += 1
|
||||
\end{minted}
|
||||
\caption{Code de la boucle du thread principale.}
|
||||
\caption{Code de la boucle du thread principal.}
|
||||
\label{lst:boucle_principale}
|
||||
\end{listing}
|
||||
|
||||
|
||||
Le code \ref{lst:collecteur} implémente le collecteur d'expérience.
|
||||
Le collecteur est éxecuté dans un thread à part.
|
||||
On lui donne comme paramètre une maquette sur laquelle travaillier, et la politique \code{policy}.
|
||||
Cette politique est déterminer par un autre thread.
|
||||
Les transitions sont stokées dans le \code{replay_buffer}.
|
||||
De plus, pour aller plus vide dans la collecte de transition, et pour saturée plus rapidement le réseau, on utilise plusieurs maquette en parrallèle, chacune dans un thread.
|
||||
On lui donne comme paramètres une maquette sur laquelle travailler, et la politique \code{policy}.
|
||||
Cette politique est déterminée par un autre thread.
|
||||
Les transitions sont stockées dans le \code{replay_buffer}.
|
||||
De plus, pour aller plus vite dans la collecte de transitions, et pour saturer plus rapidement le réseau, on utilise plusieurs maquettes en parallèle, chacune dans un thread.
|
||||
|
||||
\subsection{Maquette physique utilisée\label{part_maquette}}
|
||||
|
||||
La maquette physique que nous utilisont est constitué de deux machines : \begin{itemize}
|
||||
\item Un PC de bureau equipé d'un intel i5gen10, de 32 Go de RAM et d'un adaptateur WiFi ax,
|
||||
La maquette physique que nous utilisons est constituée de deux machines : \begin{itemize}
|
||||
\item Un PC de bureau équipé d'un intel i5gen10, de 32 Go de RAM et d'un adaptateur Wi-Fi ax,
|
||||
\item un \rasp 3B+.
|
||||
\end{itemize}
|
||||
Les deux machines sont connectée par un réseau WiFi $2.5 GHz$ géré par le PC.
|
||||
La connexion est bien trop bonne pour pouvoir etre saturée par un système CoAP classique seul, d'où l'utilisation de plusieurs maquette numérique en même temps sur le modèle physique.
|
||||
Les deux machines sont connectées par un réseau Wi-Fi $2.5 GHz$ géré par le PC.
|
||||
La connexion est bien trop bonne pour pouvoir être saturée par un système CoAP classique seul, d'où l'utilisation de plusieurs maquettes numériques en même temps sur le modèle physique.
|
||||
|
||||
\subsection{Sénario d'interet}
|
||||
Les sénarios d'interet sont : \begin{itemize}
|
||||
\item un réseau peu congestioner,
|
||||
\item un réseau congestioner,
|
||||
\subsection{Scénario d'intérêt}
|
||||
Les scénarios d'intérêt sont : \begin{itemize}
|
||||
\item un réseau peu congestionné,
|
||||
\item un réseau congestionné,
|
||||
\item la transition de l'un à l'autre.
|
||||
\end{itemize}
|
||||
Mais il faut prendre en compte que on peu mettre des charges diffeente sur chaque capteur.
|
||||
Ainsi on peu avoir peu de requettes sur tout les capteurs sauf un qui en a beaucoup plus.
|
||||
La charge sur le réseau est définie par la fréquence à laquelle chaque client émet des requettes.
|
||||
Mais il faut prendre en compte que l'on peut mettre des charges différentes sur chaque capteur.
|
||||
Ainsi on peut avoir peu de requêtes sur tous les capteurs sauf un qui en a beaucoup plus.
|
||||
La charge sur le réseau est définie par la fréquence à laquelle chaque client émet des requêtes.
|
||||
|
||||
\section{Expérience et résultats}
|
||||
Pour commencer, on fait quelque test en local, c'est à dire que le serveur \coap{} se trouve sur la même machine que le client.
|
||||
On obtient les resultats de la figure \ref{fig:res:rtt_local}.
|
||||
On constate que même en local, certain messages sont acquitté avec du retard.
|
||||
Certain on un \rtt{} deux fois plus grand que la moyenne.
|
||||
On peut aussi observer que $RTT_S$ a bien plus de varriation brusque que $RTT_L$.
|
||||
Pour commencer, on fait quelques tests en local, c'est-à-dire que le serveur \coap{} se trouve sur la même machine que le client.
|
||||
On obtient les résultats de la figure \ref{fig:res:rtt_local}.
|
||||
On constate que même en local certains messages sont acquittés avec du retard.
|
||||
Certains ont un \rtt{} deux fois plus grand que la moyenne.
|
||||
On peut aussi observer que $RTT_S$ a bien plus de variations brusques que $RTT_L$.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.7 \textwidth]{png_img/distri_rtt_local.png}
|
||||
\caption[Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ avec un seul client en local.]{Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ pendant un envoie de message sans délai entre la réception d'un messagee et l'envoie du suivant, avec un seul client en local.}
|
||||
\caption[Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ avec un seul client en local.]{Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ pendant un envoi de message sans délai entre la réception d'un message et l'envoi du suivant, avec un seul client en local.}
|
||||
\label{fig:res:rtt_local}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Etude de la maquette}
|
||||
On commence par essayer de mesurer les limites du système.
|
||||
Sur la figure \ref{fig:res:evo_grandeur}, on regarde les grandeurs que l'on va donner à l'agent en fonction du nombre de requette simultané que doit traiter le serveur.
|
||||
Sur la figure \ref{fig:res:evo_grandeur}, on regarde les grandeurs que l'on va donner à l'agent en fonction du nombre de requêtes simultanées que doit traiter le serveur.
|
||||
On utilise le \CCA{} de \coap{} de base.
|
||||
Pour généré $n$ requette, on prend $n$ client qui envoient une nouvelle requettes à la reception de l'ancienne requette.
|
||||
On constate que les grandeurs semblent toutes bruité de manière non-négligéable.
|
||||
Pour générer $n$ requêtes, on prend $n$ clients qui envoient une nouvelle requête à la reception de l'ancienne.
|
||||
On constate que les grandeurs semblent toutes bruitées de manière non négligeable.
|
||||
On constate aussi que le taux de retransmission semble suivre un palier.
|
||||
Le rapport $\eta$ semble plus sensible, et suit une courbe continu, presque une exponentielle décroissante.
|
||||
Cela indique que tres rapidement le temps passé dans les queues est bien plus important que le temps de propagation.
|
||||
$VARRTT$ par contre n'est pas pertinante à regarder ici, car elle mesure l'évolution du système.
|
||||
Pourtant, le niveau de congestion semble avoir un impacte sur la grandeur que nous se savons pas expliquer.
|
||||
En regardant la charge de calcul sur le \rasp{}, on constate que la limite créant la congestion n'est pas la saturation de la connexion WiFi entre les deux machines, mais la puissance de calcule du \rasp{} qui n'arrive pas à traiter les requettes.
|
||||
Le rapport $\eta$ semble plus sensible, et suit une courbe continue, presque une exponentielle décroissante.
|
||||
Cela indique que très rapidement le temps passé dans les queues est bien plus important que le temps de propagation.
|
||||
$VARRTT$ par contre n'est pas pertinente à regarder ici, car elle mesure l'évolution du système.
|
||||
Pourtant, le niveau de congestion semble avoir un impact sur la grandeur que nous ne savons pas expliquer.
|
||||
En regardant la charge de calcul sur le \rasp{}, on constate que la limite créant la congestion n'est pas la saturation de la connexion Wi-Fi entre les deux machines, mais la puissance de calcul du \rasp{}, qui n'arrive pas à traiter les requêtes.
|
||||
|
||||
On peut aussi reproduire \ref{fig:res:rtt_local} mais en utilisant un seveur sur la \rasp{}.
|
||||
Sur la figure \ref{fig:res:rtt_distant}, on vois que la distribution des \rtt{} est similaire, mais que certaine mesure sont tres éloigné de la moyenne.
|
||||
Si on tentais de réduire le \rto{}, ces messages serais retransmie, alors que ils ne sont pas réelement perdus.
|
||||
On peut aussi reproduire \ref{fig:res:rtt_local} mais en utilisant un seveur sur le \rasp{}.
|
||||
Sur la figure \ref{fig:res:rtt_distant}, on voit que la distribution des \rtt{} est similaire, mais que certaines mesures sont très éloignées de la moyenne.
|
||||
Si on tentait de réduire le \rto{}, ces messages seraient retransmis alors qu'ils ne sont pas réellement perdus.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.7\textwidth]{png_img/n_client_saturation.png}
|
||||
\caption[Evolutions des grandeurs mesurer en fonction du nombre de requette simultané]{Evolution des grandeurs mesurer en fonction du nombre de requette simultané traiter par le serveur \coap{} tournant sur une \rasp{}. Le \CCA{} de \coap{} de base est utilisé.}
|
||||
\caption[Evolution des grandeurs mesurées en fonction du nombre de requêtes simultanées]{Evolution des grandeurs mesurées en fonction du nombre de requêtes simultanées traitées par le serveur \coap{} tournant sur un \rasp{}. Le \CCA{} de \coap{} de base est utilisé.}
|
||||
\label{fig:res:evo_grandeur}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.7 \textwidth]{png_img/distri_rtt_distant.png}
|
||||
\caption[Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ avec un seul client.]{Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ pendant un envoie de message sans délai entre la réception d'un messagee et l'envoie du suivant, avec un seul client et un serveur sur le \rasp{}. Même si on ne les distingue pas sur l'histogramme, il y a quelque valeur de \rtt{} très élevées.}
|
||||
\caption[Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ avec un seul client.]{Distribution du \rtt{} et évolution de $RTT_L$ et $RTT_S$ pendant un envoi de message sans délai entre la réception d'un message et l'envoi du suivant, avec un seul client et un serveur sur le \rasp{}. Même si on ne les distingue pas sur l'histogramme, il y a quelque valeurs de \rtt{} très élevées.}
|
||||
\label{fig:res:rtt_distant}
|
||||
\end{figure}
|
||||
|
||||
|
|
@ -957,54 +957,54 @@ Si on tentais de réduire le \rto{}, ces messages serais retransmie, alors que i
|
|||
\label{fig:res:varrtt}
|
||||
\end{figure}
|
||||
|
||||
On peut aussi faire un essaie pour voir le profil de $VARRTT$ en cas de changement de charge sur le réseaux.
|
||||
On place dabbort un unique client sur le réseau, et on regarde l'évolution de $VARRTT$.
|
||||
Au $500$-ieme message, on active $20$ autre client qui vont eux aussi envoyer des requettes au serveur.
|
||||
Dans la figure \ref{fig:res:varrtt}, on constate que il y a bien un pic au moment de l'augmentation de la charge du système, mais il y a aussi des pics dû au bruit dans la mesure du \rtt{}.
|
||||
On peut aussi faire un essai pour voir le profil de $VARRTT$ en cas de changement de charge sur le réseau.
|
||||
On place d'abord un unique client sur le réseau, et on regarde l'évolution de $VARRTT$.
|
||||
Au $500$-ieme message, on active $20$ autres clients qui vont eux aussi envoyer des requêtes au serveur.
|
||||
Dans la figure \ref{fig:res:varrtt}, on constate qu'il y a bien un pic au moment de l'augmentation de la charge du système, mais il y a aussi des pics dus au bruit dans la mesure du \rtt{}.
|
||||
|
||||
\subsection{Test d'apprentissage}
|
||||
|
||||
Les testes de pré-apprentissage ont était réalisé avec : \begin{itemize}
|
||||
\item des réseaux de $25$ capteur, ce qui est un ordre de grandeur du nombre de capteur dans le type de réseaux cible,
|
||||
\item avec $8$ maquette en parrallèle pour acceleré la récupération d'expérience,
|
||||
\item des interval de control de $30$ secondes,
|
||||
Les tests de pré-apprentissage ont été réalisés avec : \begin{itemize}
|
||||
\item des réseaux de $25$ capteurs, ce qui est un ordre de grandeur du nombre de capteurs dans le type de réseaux cibles,
|
||||
\item avec $8$ maquettes en parallèle pour accélérer la récupération d'expérience,
|
||||
\item des intervalles de contrôle de $30$ secondes,
|
||||
\item un facteur d'apprentissage de $\alpha = 0.01$.
|
||||
\end{itemize}
|
||||
On obtient donc un pas d'entrainement toutes les heures.
|
||||
Appres $72$ heures d'entrainement, soit $70$ pas d'entrainement, on n'a toujours pas de résultats stable.
|
||||
En effet, les \rto{} ont des comportement hératique, ils convergent vers $0$ ou divergent vers $+\infty$.
|
||||
On se retrove donc avec un taux d'echec important, le réseau n'est pas exploitable.
|
||||
On obtient donc un pas d'entraînement environ toutes les heures.
|
||||
Après $72$ heures d'entraînement, soit $70$ pas d'entraînement, on n'a toujours pas de résultat stable.
|
||||
En effet, les \rto{} ont des comportements erratiques, ils convergent vers $0$ ou divergent vers $+\infty$.
|
||||
On se retrouve donc avec un taux d'échec important, le réseau n'est pas exploitable.
|
||||
|
||||
Les décisions prise par l'agent non-entrainer sont trop aléatoire pour que il puisse maintenir en etat correct du réseau.
|
||||
Il faudrait attendre longtemps avant que un épisode stable se forme par hasard et que l'agent puisse exploiter la stratégie correct.
|
||||
Cela montre bien que l'entrainement sur simulateur est indispensable car le pré-entrinement sur modèle réel n'est pas assez performant.
|
||||
Les décisions prises par l'agent non-entraîné sont trop aléatoires pour qu'il puisse maintenir un état correct du réseau.
|
||||
Il faudrait attendre longtemps avant qu'un épisode stable se forme par hasard et que l'agent puisse exploiter la stratégie correcte.
|
||||
Cela montre bien que l'entraînement sur simulateur est indispensable car le pré-entraînement sur modèle réel n'est pas assez performant.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{png_img/charge-rtts.png}
|
||||
\caption[Répartition de la \rtt{} et du taux de retransmition en fonction de la charge du réseau.]{Répartition de la \rtt{} et du taux de retransmition en fonction de la charge du réseau. On ne vois pas clairement, mais en bas à gauche de chaque figure, il y a une zone tres dense.}
|
||||
\caption[Répartition de la \rtt{} et du taux de retransmission en fonction de la charge du réseau.]{Répartition de la \rtt{} et du taux de retransmission en fonction de la charge du réseau. On ne le voit pas clairement, mais en bas à gauche de chaque figure il y a une zone très dense.}
|
||||
\label{fig:res:yaml}
|
||||
\end{figure}
|
||||
Pour palier à cela, une méthode pour crée de l'experience plus rapidement à était tenter, mais n'a pas pu etre finaliser.
|
||||
Néanmoins, grace au donné récupérer, on peut tracer la figure \ref{fig:res:yaml} qui nous montre bien qu'il y a une charge critique à partir de laquelle le \rtt{} varrie beaucoup.
|
||||
Pour pallier cela, une méthode pour créer de l'expérience plus rapidement a été tentée mais n'a pu être finalisée.
|
||||
Néanmoins, grâce aux données récupérées, on peut tracer la figure \ref{fig:res:yaml}, qui montre bien qu'il y a une charge critique à partir de laquelle le \rtt{} varie beaucoup.
|
||||
|
||||
|
||||
\section{Conclusion}
|
||||
La modélisation que nous proposon est une transposition de méthode existante dans un nouveau domaine.
|
||||
L'apprentissage machine a déjà montrer qu'il était capable de résoudre des problèmes liée au réseaux et au \CC{}.
|
||||
Nous avons proposer ici une nouvelle modélisation pour intégrer ces nouveau outils à des problématique de l'\iot{}.
|
||||
On ne s'interresse plus à une connexion seule, mais à l'ensemble des connexions vers tout un réseau de capteurs.
|
||||
On ne mesure que les \rtt{} de chaque message, ainsi que le nombre de retransmission.
|
||||
On construit ensuite une matrices qui représente l'état du réseau durant un interval de control.
|
||||
Cette matrice est utilisé par un agent IA pour determiner l'action à prendre.
|
||||
Cette action est une liste de facteurs multiplicatifs à appliquer aux \rto{} de chaque capteurs.
|
||||
La difficulté est que on ne peut pas récupérer assez d'expérience pour réalisé un pré-entrainement.
|
||||
La modélisation que nous proposons est une transposition de méthodes existantes dans un nouveau domaine.
|
||||
L'apprentissage machine a déjà montré qu'il était capable de résoudre des problèmes liés aux réseaux et au \CC{}.
|
||||
Nous avons proposé ici une nouvelle modélisation pour intégrer ces nouveaux outils à des problématiques de l'\iot{}.
|
||||
On ne s'intéresse plus à une connexion seule mais à l'ensemble des connexions vers tout un réseau de capteurs.
|
||||
On ne mesure que les \rtt{} de chaque message, ainsi que le nombre de retransmissions.
|
||||
On construit ensuite une matrices qui représente l'état du réseau durant un intervalle de contrôle.
|
||||
Cette matrice est utilisée par un agent IA pour déterminer l'action à prendre.
|
||||
Cette action est une liste de facteurs multiplicatifs à appliquer aux \rto{} de chaque capteur.
|
||||
La difficulté est que l'on ne peut pas récupérer assez d'expérience pour réaliser un pré-entraînement.
|
||||
Pour cela, il faudrait un simulateur.
|
||||
La solution de la partie \ref{part:yaml} n'a pas pu etre tester.
|
||||
La solution de la partie \ref{part:yaml} n'a pas pu être testée.
|
||||
|
||||
Par manque de temps et de capacité, ledit simulateur n'a pas pu etre réalisé.
|
||||
Parmis les autres élements à perféctioner, il y a les valeurs de pondération utilisé dans la fonction de récompence, qui sont pour l'instant arbitraire.
|
||||
De même, l'agent est pour l'instant assez basique, on pourrait utiliser une structure du réseau de neurrone plus complexe pour prendre en compte les particularités de la matrice d'état.
|
||||
Par manque de temps et de capacité, ledit simulateur n'a pas pu être réalisé.
|
||||
Parmi les autres éléments à perfectionner, il y a les valeurs de pondération utilisées dans la fonction de récompense, qui sont pour l'instant arbitraires.
|
||||
De même, l'agent est pour l'instant assez basique, on pourrait utiliser une structure de réseau de neurones plus complexe pour prendre en compte les particularités de la matrice d'état.
|
||||
Le travail réalisé sera repris dans une thèse de \lss{}.
|
||||
|
||||
\clearpage
|
||||
|
|
@ -1060,7 +1060,7 @@ Le travail réalisé sera repris dans une thèse de \lss{}.
|
|||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[height=\vsize, width=\hsize, keepaspectratio]{puml/call_stack_envoie.png}
|
||||
\caption[Appel de fonction pour une transaction]{Appel de fontion pour une transaction avec \coapthon{} et mes modifications. Chaque couleur représente un thread d'execution.}
|
||||
\caption[Appel de fonction pour une transaction]{Appel de fonction pour une transaction avec \coapthon{} et ses modifications. Chaque couleur représente un thread d'exécution.}
|
||||
\label{fig:call_stack}
|
||||
\end{figure}
|
||||
\end{landscape}
|
||||
|
|
|
|||
Loading…
Reference in a new issue