diff --git a/ensps.sty b/ensps.sty index 493915d..608d5c0 100644 --- a/ensps.sty +++ b/ensps.sty @@ -210,7 +210,7 @@ %------- Abréviations, langages et programme utiles -\newcommand{\ens}{École normale supérieur Paris-Saclay} +\newcommand{\ens}{École normale supérieure Paris-Saclay} \newcommand{\matlab}{\textsc{Matlab}} \newcommand{\python}{\emph{python}} diff --git a/makefile b/makefile index d1bde73..ea173f6 100644 --- a/makefile +++ b/makefile @@ -1,6 +1,6 @@ FIGURES_SVG=$(wildcard raw_img/*.svg) -FIGURES_PDF=$(subst raw_img/,pdf_img/,$(FIGURES_SVG:.svg=.pdf_tex)) -FIGURES_PNG=$(subst raw_img/,png_svg_img/,$(FIGURES_SVG:.svg=.png)) +FIGURES_PDF=$(FIGURES_SVG:.svg=.pdf_tex) +FIGURES_PNG=$(FIGURES_SVG:.svg=.png) DOT_DOT=$(wildcard dot/*.dot) DOT_PNG=$(DOT_DOT:.dot=.png) @@ -14,9 +14,9 @@ all : rapport.pdf poster.pdf rapport.pdf : rapport.tex rapport.bib $(FIGURES_PNG) $(UML_PNG) png_img/gain_action.png $(DOT_PNG) lualatex -shell-escape rapport.tex - bibtex rapport makeglossaries rapport lualatex -shell-escape rapport.tex + bibtex rapport lualatex -shell-escape rapport.tex lualatex -shell-escape rapport.tex @@ -25,7 +25,6 @@ poster.pdf : poster.tex poster.bib $(FIGURES_PNG) $(UML_PNG) png_img/gain_action bibtex poster lualatex -shell-escape poster.tex lualatex -shell-escape poster.tex - lualatex -shell-escape poster.tex rapport.bib : biblio.bib cp biblio.bib rapport.bib @@ -37,12 +36,14 @@ png_img/gain_action.png : python3 png_img/gen_fig_g.py clean : clean-rapport clean-poster - rm -f -r pdf_img/ - rm -f -r png_svg_img/ + rm -f -r svg_img/*.png + rm -f -r svg_img/*.pdf + rm -f -r svg_img/*.pdf_tex rm -f -r puml/*.svg rm -f -r puml/*.png rm -f -r dot/*.png rm -f rapport.pdf + rm -f poster.pdf clean-rapport : rm -f rapport.aux @@ -78,13 +79,13 @@ clean-poster : rm -f poster.glo rm -f texput.log -pdf_img/%.pdf : raw_img/%.svg pdf_img/%.pdf_tex +svg_img/%.pdf : svg_img/%.svg svg_img/%.pdf_tex inkscape -D -z --file=$< --export-pdf=$@ --export-latex -pdf_img/%.pdf_tex : raw_img/%.svg +svg_img/%.pdf_tex : svg_img/%.svg inkscape -D -z --file=$< --export-pdf=$@ --export-latex -png_svg_img/%.png : raw_img/%.svg +svg_img/%.png : svg_img/%.svg inkscape $< --export-type=png --export-filename=$@ puml/%.svg : puml/%.puml diff --git a/puml/cas_utilisation_coap_1.puml b/puml/cas_utilisation_coap_1.puml index 6773c50..eed0fc3 100644 --- a/puml/cas_utilisation_coap_1.puml +++ b/puml/cas_utilisation_coap_1.puml @@ -4,7 +4,7 @@ hide footbox participant Capteur as capt database Cloud as cld -[-> capt ++: activation exterieur\ntimer, interuption... +[-> capt ++: activation extérieure\ntimer, interruption... capt -> cld : CON[0x77]\nPUT/url?val cld --> capt !!: ACK[0x77] diff --git a/puml/classe.puml b/puml/classe.puml index 66ac9c6..3f2fdc5 100644 --- a/puml/classe.puml +++ b/puml/classe.puml @@ -21,7 +21,7 @@ package "Notre ajout" as us { +float avg_RTT +envoie_token() - +receprion_token() + +reception_token() +failed_request() +reset() } @@ -61,14 +61,14 @@ package "tf_agent" as tf{ } helper_client_coap "1" *-- "1" client_coap : > Simplifie l'usage -client_coap "1" *-- "1" superviseur_local : < Surveille et controle +client_coap "1" *-- "1" superviseur_local : < Surveille et contrôle superviseur_global "1" o-- "N" superviseur_local : > fait la synthèse maquette "1" *-- "N" helper_client_coap maquette "1" *-- "1" superviseur_global : < envoie les données\nrécoltées -maquette "1" *-- "N" requette : < permet le controle\nde la charge du réseau -requette "1" --> "1" helper_client_coap : > envoie des requettes\navec une période précise +maquette "1" *-- "N" requette : < permet le contrôle\nde la charge du réseau +requette "1" --> "1" helper_client_coap : > envoie des requêtes\navec une période précise tfenv <|-- maquette : < implémente @enduml \ No newline at end of file diff --git a/rapport.tex b/rapport.tex index 34e465b..61878e8 100644 --- a/rapport.tex +++ b/rapport.tex @@ -21,6 +21,12 @@ \usepackage{lscape} \usepackage{wrapfig} +\usepackage[% + all, + defaultlines=3 % nombre minimum de lignes +]{nowidow} + + \newcommand{\code}[1]{\mintinline[breaklines, breakafter=.]{python}{#1}} \usepackage[toc]{glossaries} @@ -61,7 +67,7 @@ \newglossaryentry{cocoa} { name=Cocoa+, - description={Evolution de \coap{}, protocole de la couche \osi{} 7, voir \cite{shelbyConstrainedApplicationProtocol2014}} + description={Évolution de \coap{}, protocole de la couche \osi{} 7, voir \cite{shelbyConstrainedApplicationProtocol2014}} } \newcommand{\cocoa}{\gls{cocoa}} @@ -76,7 +82,7 @@ \newglossaryentry{keras} { - name=keras, + name=Keras, description={Module Python pour la manipulation de réseaux de neurones} } @@ -141,7 +147,7 @@ \newglossaryentry{mac} { name=MAC, - description={Media Access Control, Contrôle de l'accès à médium de communication} + description={Media Access Control, Contrôle de l'accès au médium de communication} } \newcommand{\mac}{\gls{mac}} @@ -236,8 +242,9 @@ \hspace{0pt} \vfill \begin{center} - \section*{Remerciement} - Je remercie Lynda Zitoune et Véronique Vèque de m'avoir permis de réalisé ce stage dans leur équipe. + \section*{Remerciements} + Je remercie Lynda Zitoune et Véronique Vèque\\ + de m'avoir permis de effectuer ce stage dans leur équipe. \end{center} \vfill \hspace{0pt} @@ -276,7 +283,7 @@ Nos objectifs sont \begin{itemize} \item détermination des scénarios pertinents \item simulation ou test de ces scénarios \end {itemize} -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. +Le stage se déroule entièrement en distanciel, avec des réunions hebdomadaires avec mes encadrantes, soit en présentiel dans les locaux de CentraleSupélec, soit sur Teams. \subsection{Qu'est-ce qu'un réseau \iot{} ?} @@ -296,9 +303,9 @@ Ces connexions se font au moyen de normes et de protocoles organisés dans un mo \toprule Couche & Rôle & Protocole\\ \midrule - 7 - Application & Utilisation finale & http, ssh...\\ + 7 - Application & Utilisation finale & \http{}, ssh...\\ 4 - Transport & \CC{} \& multiplexage & \tcp{}, \udp{}\\ - 3 - Réseau & Routage & IP\\ + 3 - Réseau & Routage & \ip{}\\ 1 \& 2 - Physique & Support des communications & Ethernet, Wi-Fi...\\ \bottomrule \end{tabular} @@ -306,9 +313,9 @@ Ces connexions se font au moyen de normes et de protocoles organisés dans un mo Les couches $1$ et $2$ permettent la communication entre deux machines directement reliées. C'est ici qu'intervient l'adresse \mac{}. -La couches $3$ décrit le routage pour passer par des machines intermédiaires afin de voyager dans l'ensemble du réseau. +La couche $3$ décrit le routage pour passer par des machines intermédiaires afin de voyager dans l'ensemble du réseau. C'est ici qu'intervient l'adresse \ip{}. -La couches $4$ décrit les protocoles permettant d'établir une connexion entre deux applications sur les machines hôtes. +La couche $4$ décrit les protocoles permettant d'établir une connexion entre deux applications sur les machines hôtes. Cela inclut donc le multiplexage des données (c'est le port sur la machine hôte), ainsi que la gestion de la congestion. 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}. @@ -328,18 +335,19 @@ Suivant l'application, il faut favoriser l'un ou l'autre, ou trouver un compromi \subsubsection{Qu'est-ce que la congestion ?} -Malheureusement, les réseaux étant hétérogènes, on ne contrôle pas tout les paramètres lorsqu'on les utilise. +Malheureusement, les réseaux étant hétérogènes, on ne contrôle pas tous les paramètres lorsqu'on les utilise. 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 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, 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. -Une grande partie des optimisations du \CC a lieu au niveau de ce temps d'attente, le \rto. +Une grande partie des optimisations du \CC{} a lieu au niveau de ce temps d'attente, le \rto{}. \subsubsection{Quelles sont les spécificités des réseaux \iot{} ?} @@ -350,7 +358,7 @@ Dans un réseau \iot, les contraintes et applications sont différentes : \begin \end{itemize} Les technologies employées sont surtout des connexions sans fil à basse consommation, et à bas débit. -On peut citer les technologies comme le BLE, le 802.15.4, 6LoWPAN. %manque référence +On peut citer les technologies comme le BLE, le 802.15.4, 6LoWPAN \dots %manque référence De plus, pour accéder aux ressources d'une autre machine, on ne peut pas utiliser l'\http{} comme sur un ordinateur de bureau ou un téléphone. En effet, \http{} s'appuie sur \tcp{}, et induit donc beaucoup de messages supplémentaires. @@ -363,8 +371,8 @@ Un nouveau protocole a donc été développé pour proposer des fonctionnalités L'interface en question est une interface \emph{RestFull} :\begin{itemize} \item Les ressources sont identifiées par des url, par exemple \url{coap://exemple.com/ressource/en/ligne}, \item On peut interagir avec les ressources au moyen de plusieurs méthodes: \begin{itemize} - \item GET : On demande le contenu de la ressource distante, - \item POST, PUT : On crée ou remplace le contenu de la ressource distante, + \item GET : on demande le contenu de la ressource distante, + \item POST, PUT : on crée ou remplace le contenu de la ressource distante, \item DELETE : on supprime la ressource. \end{itemize} \end{itemize} @@ -425,7 +433,7 @@ Les deux paramètres sont : \begin{itemize} \end{itemize} La méthode pour déterminer l'action appropriée à chaque pas de temps est juste de prendre $argmax_{a \in \mathbb{A}} \mathbb{Q}\left(s_t, a \right) $. En réalité, on fait des actions aléatoires avec une probabilité faible pour explorer l'environnement. -Deux des limites de cette solution sont la taille en mémoire d'un tel tableau quand les ensembles $mathbb{S}$ et $\mathbb{A}$ sont grands, et le temps qu'il faut pour que la convergence des valeurs du tableau ait lieu. +Deux des limites de cette solution sont la taille en mémoire d'un tel tableau quand les ensembles $\mathbb{S}$ et $\mathbb{A}$ sont grands, et le temps qu'il faut pour que la convergence des valeurs du tableau ait lieu. Pour pallier à cela, on peut approximer la fonction par un réseau de neurones, c'est le principe du \dqlearn{}. \section{État de l'art\label{part_cc}} @@ -465,9 +473,9 @@ Mais interpréter ces variations de \rtt{} et prendre la décision adéquate est \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 fenêtre 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 délai de transmission est déjà de l'ordre du \rto, alors il risque d'y avoir des retransmissions systématiques. +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 évolutions du \coap{} est \cocoa{}, qui ne change que le \CCA{}\cite{ancillottiRTTBasedCongestionControl2018}. C'est un algorithme inspiré de FAST-\tcp{} et Compound-\tcp{}. @@ -488,8 +496,8 @@ Ensuite, on crée une fonction $T$ permettant de prendre une décision : \end{equation} 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( -1 \right) \le RTT_S < T\left( +1 \right)$ : congestion faible, on se trouve à un point de fonctionnement 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 mais en augmentation, il faut être moins agressif pour ne pas congestionner 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$. @@ -497,12 +505,12 @@ Le choix des autres valeurs, les seuils et les actions prises sont choisis empir \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. +L'idée derrière ces algorithmes est de déléguer la prise de décision à 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 La modélisation de l'environnement : \begin{itemize} \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 + \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 être sûr que les ressources réseau sont équitablement réparties entre les agents, @@ -514,35 +522,36 @@ L'intégration de l'IA dans le \CC{} n'est encore qu'à l'état de tests, de bal \section{Modélisation choisie} La première étape est de modéliser le système. -Notre modélisation s'appuie sur la modélisation de \cite{xiaoTCPDrincSmartCongestion2019}. +Notre modélisation s'appuie sur celle de \cite{xiaoTCPDrincSmartCongestion2019}. \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$. +On choisit de se placer dans le cas où on interagit avec un nombre fixe de capteurs, $N$. \begin{figure}[htp] \centering - \includegraphics[scale=1]{puml/cas_utilisation_coap_1.png} + \includegraphics[scale=0.9]{puml/cas_utilisation_coap_1.png} \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[scale=1]{puml/cas_utilisation_coap_2.png} + \includegraphics[scale=0.9]{puml/cas_utilisation_coap_2.png} \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[scale=1]{puml/cas_utilisation_coap_3.png} + \includegraphics[scale=0.9]{puml/cas_utilisation_coap_3.png} \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 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. +Lorsque l'on veut établir une connexion avec un capteur, il y a trois cas de figure, il faut donc choisir le plus avantageux. +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. @@ -553,7 +562,7 @@ La grandeur la plus simple à se représenter est le \rtt{}. 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. +Ce problème peut être contourné en changeant le token dans les retransmissions, mais nous ne mett rons pas en place cette solution pour l'instant. \begin{figure}[htp] \centering @@ -577,7 +586,7 @@ Ces retransmissions peuvent être dues à la congestion mais aussi à des probl 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. +Dans ces intervalles, on suppose 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". @@ -585,7 +594,7 @@ On nomme cet intervalle "intervalle de contrôle". 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 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. +Pour la suite, on appelle "serveur \coap{}" la partie de programme s'exécutant sur les capteurs, et "clients \coap{}" les programmes s'exécutant 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.} @@ -632,7 +641,7 @@ Une fois que chaque client a généré son vecteur, il suffit de les concaténer \label{eq:modele:mat} \end{equation} 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. +Une autre possibilité, qui est de concaténer les matrices de plusieurs échantillon de temps successifs pour créer un tenseur à trois dimensions (ce qui permettrait d'avoir plus d'informations sur l'évolution temporelle des valeurs) n'a pas pu être testée. \subsection{Comment l'acteur influence-t-il le client \coap{} ?} La principale valeur permettant de contrôler le comportement du client est le \rto{}. @@ -659,11 +668,11 @@ D'autres choix sont possibles, par exemple $\mathbb{A} = \left\lbrace 0.1, 0.5, \subsection{Comment quantifier la réussite de l'agent ?} 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} +Les critères 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. + \item le nombre de messages envoyés est équitablement réparti entre les clients. \end{itemize} L'équité est une grandeur permettant de mesurer si certains capteurs utilisent plus le réseau que d'autres. @@ -703,12 +712,12 @@ Cela représente le fonctionnement normal du système. 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 le pré-entraînement, \item l'entraînement en position. \end{enumerate} 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. +Pour cela, il faut générer de l'expérience (les transitions $\left( s_t, a_t, r_t, s_{t+1} \right)$ que l'on a vues plus haut), et l'utiliser pour optimiser la politique. 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. @@ -736,24 +745,24 @@ Il faut donc trouver des solutions plus rapides que l'exploration simple si on v \subsubsection{Par exploration en simulateur} Une solution simple, en théorie, est d'utiliser un simulateur. Le plus utilisé est \ns{}. -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{}. +C'est un simulateur à événements discrets destiné à la simulation de réseaux informatiques permettant de travailler 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{}. +Malheureusment, c'est un simulateur complexe à utiliser : tous les scripts de simulation sont écrits 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 artificielle de transitions\label{part:yaml}} -Une autre méthode possible est de créer des transitions artificiellement. +Une autre méthode 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 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 peut ainsi construire une série de transitions $s_n, a_{n, m}, r_m, s_m$. -On recommence avec un autre $f$ +On recommence avec un autre $f$. 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é 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. +Cela permet malgres tout 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'algorithme est réalisée en Python. @@ -767,7 +776,7 @@ De plus, pour la partie apprentissage, on utilise \TF{}, un module répandu pour \label{fig:imple:class} \end{figure} -\subsection{Modules uilisés} +\subsection{Modules utilisés} 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} @@ -778,9 +787,9 @@ Les modules que nous utilisons ont leur propre interface et fonctionnement Inter 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 nécessaires à l'entraînement de modèles d'IA. +\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{}. +Pour cela, il a besoin que l'on mette l'environnement sous un format spécial : l'interface \gym{}. 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} @@ -789,13 +798,13 @@ Pour cela, il faut définir une nouvelle classe, héritant de \code{tf_agents.en \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 premiers permettent de signaler à l'agent quelles valeurs sont autorisées. +Les deux premiers membres 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 neurones. -Puisqu'on n'utilise que des réseaux simples, les fonctionalités du module ne seront pas abordées. +Puisqu'on n'utilise que des réseaux simples, les fonctionnalités du module ne seront pas abordées. \subsection{Structure du code} @@ -822,7 +831,7 @@ On modifie aussi \code{client.CoAP.send_datagram._start_retransmission} pour que On modifie finalement \code{client.CoAP.receive_datagram} pour enregistrer les réceptions de messages en fonction de leurs tokens. 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{SuperviseurLocalPlaceHolder}, qui est utilisé par défaut et n'a aucune fonctionn alité, 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} @@ -832,7 +841,7 @@ Elle réalise aussi le calcul des récompenses. \subsubsection{Boucle d'apprentissage} 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 +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, attend la durée de l'intervalle de contrôle, puis renvoie l'état du système. 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] @@ -880,7 +889,7 @@ while True: Le code \ref{lst:collecteur} implémente le collecteur d'expérience. -Le collecteur est éxecuté dans un thread à part. +Le collecteur est exécuté dans un thread à part. 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}. @@ -939,21 +948,21 @@ Si on tentait de réduire le \rto{}, ces messages seraient retransmis alors qu'i \begin{figure}[htp] \centering \includegraphics[width=0.7\textwidth]{png_img/n_client_saturation.png} - \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é.} + \caption[Évolution des grandeurs mesurées en fonction du nombre de requêtes simultanées]{Évolution 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 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.} + \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 messages 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} \begin{figure}[htp] \centering \includegraphics[width=0.7 \textwidth]{png_img/varrtt_demo.png} -\caption[Evolution de $VARRTT$ lors d'un changement de charge du réseau.]{Evolution de $VARRTT$ lors d'un changement de charge du réseau au moment du $500$-ième message.} +\caption[Évolution de $VARRTT$ lors d'un changement de charge du réseau.]{Évolution de $VARRTT$ lors d'un changement de charge du réseau au moment du $500$-ième message.} \label{fig:res:varrtt} \end{figure} @@ -962,7 +971,7 @@ On place d'abord un unique client sur le réseau, et on regarde l'évolution de 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} +\subsection{Tests d'apprentissage} 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, @@ -994,8 +1003,8 @@ La modélisation que nous proposons est une transposition de méthodes existante 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. +On ne mesure que le \rtt{} de chaque message, ainsi que le nombre de retransmissions. +On construit ensuite une matrice 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. @@ -1005,7 +1014,7 @@ 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 ê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{}. +Le travail réalisé sera repris dans une thèse du \lss{}. \clearpage @@ -1078,12 +1087,12 @@ Le travail réalisé sera repris dans une thèse de \lss{}. \noindent\rule[2pt]{\textwidth}{0.5pt}\\ {\textbf{Abstract :}} -Congestion control the bottleneck of network throughput. -Since a few year, deep-learning is beeing used in congestion control algorithm. -We aim to applied deep-learning to congestion control and \coap{}, an embbeded system protocol. -The environement chosen is a whole network of sensor, this way the AI agent has access to every connection information. -The only input used are the \rtt{} and number of retransmission of every transaction. -Our protocol use a pre-traning phase in a \ns{}, then an inline traning to tune itself to the network. +Congestion control is the bottleneck of network throughput. +For a few years, deep-learning has beeing used in congestion control algorithms. +We aim to apply deep-learning to congestion control and \coap{}, an embbeded system protocol. +The environement chosen is a whole network of sensors, this way the AI agent has access to every connection information. +The only inputs used are the \rtt{} and number of retransmission of every transaction. +Our protocol uses a pre-training phase in a \ns{}, then an inline training to tune itself to the network. The protocol was implemented in \python{} as a patch to \coapthon{}. We tried to test the protocol on a physical system, a \rasp{}. diff --git a/raw_img/test_uml.svg b/raw_img/test_uml.svg deleted file mode 100644 index f064f71..0000000 --- a/raw_img/test_uml.svg +++ /dev/null @@ -1,116 +0,0 @@ -Client CoAP«Thread»Superviseur«Threads»SessionUn par capteurInterface CoAPCollecteur donnée«main»GestionaireglobalStatisticienbufferd'experienceNNoptimiseur«interuption»horlogeSocket UDPSession handleRTOBuffer«main»Gestionairede la session«interuption»timerUtilisateurBase dedonnée«lib»UDP«lib»TensorFlow«lib»Kerasexpériencemet à jourdéclancheremplispacketudpaquitement&réponseuseuseuseuseuseuse \ No newline at end of file