diff --git a/ensps.sty b/ensps.sty index 87e304d..5b8b63f 100644 --- a/ensps.sty +++ b/ensps.sty @@ -195,7 +195,7 @@ \newcommand{\Lesp}[1] {\ensuremath{\mathrm{L}^{#1}}} % Pour composer les espace L^p \newcommand{\A} {\ensuremath{\mathcal{A}}} \newcommand{\R} {\ensuremath{\mathbb{R}}} -\newcommand{\CC} {\ensuremath{\mathbb{C}}} +%\newcommand{\CC} {\ensuremath{\mathbb{C}}} \newcommand{\N} {\ensuremath{\mathbb{N}}} \newcommand{\K} {\ensuremath{\mathbb{K}}} \newcommand{\Lens} {\mathcal{L}} % Lens pour "l'ENSemble L" diff --git a/rapport.tex b/rapport.tex index 74929d7..9df4c36 100644 --- a/rapport.tex +++ b/rapport.tex @@ -1,7 +1,7 @@ % !TEX encoding = UTF-8 Unicode % -*- coding: UTF-8; -*- % vim: set fenc=utf-8 -\documentclass[a4paper,12pt,french]{article} +\documentclass[a4paper,11pt,french]{article} \usepackage{ensps} @@ -21,11 +21,22 @@ \newcommand{\iot}{\emph{IoT}} \newcommand{\tcp}{\emph{TCP}} +\newcommand{\udp}{\emph{UDP}} \newcommand{\coap}{\emph{CoAP}} \newcommand{\keras}{\emph{keras}} \newcommand{\TF}{\emph{TensorFlow}} \newcommand{\coapthon}{\emph{CoAPthon}} \newcommand{\rasp}{\emph{RaspberryPi}} +\newcommand{\osi}{\emph{OSI}} +\newcommand{\CC}{\emph{CC}} +\newcommand{\mac}{\emph{MAC}} +\newcommand{\ip}{\emph{IP}} +\newcommand{\http}{\emph{http}} +\newcommand{\qlearn}{Q-learning} +\newcommand{\dqlearn}{Deep-Q-learning} + +\newcommand{\rtt}{\emph{RTT}} +\newcommand{\rto}{\emph{RTO}} \begin{document} @@ -86,24 +97,141 @@ \section{Introduction} -\begin{minted}{python} -print("hello world") -\end{minted} - \subsection{Présentation de l'environnement de travail} \subsection{Qu'est-ce qu'un réseau \iot{} ?} +Un réseau \iot{} est un réseau de machine informatique embarqué. +Les machines qui composent ce réseau sont en majorité des machines peut puissante : des capteurs, des actionneurs \dots, ils réalisent chacun une tache simple, et sont soumis à de multiple contrainte, en particulier sur la consomation energetique. +Les réseaux \iot{} présentent donc des thématiques propres au réseaux classique (débit, latence, pertes de données \dots), qui ont déjà été étudier par le passé et où des solutions éxisent, et des thématique nouvelles qui ne n'intégre pas dans le modèle classique. + \subsubsection{Qu'est-ce qu'un réseau ?} +Un réseau informatique est un groupe de machines indépendantes que l'ont connecte entre elles pour qu'elles echange des informations. +Ces connexion se font au travers de normes et de protocoles, qui sont organisé dans un modèle à $7$ couches, le modèle \osi{}: + +\begin{table}[htp] + \caption[modèle \osi{} général]{Le modèle \osi{} pour internet, les couches principales.} + \begin{tabular}{lll} + \toprule + Couche & Rôle & Protocole\\ + \midrule + 7 - Application & Utilisation finale & http, ssh...\\ + 4 - Transport & \CC{} \& multiplexage & \tcp{}, \udp{}\\ + 3 - Réseau & Routage & IP\\ + 1 \& 2 - Physique & Support des communications & Ethernet, WiFi...\\ + \bottomrule + \end{tabular} +\end{table} + +Les couches $1$ et $2$ permetent de communiqué entre deux machines directement reliées. +C'est ici qu'intervien l'adresse \mac{}. +La couches $3$ décrit le routage pour passer par des machines intermediaire afin de voyagé dans l'ensemble du réseaux. +C'est ici qu'intervien l'adresse \ip{}. +La couches $4$ décrit les protocoles permetant d'établire un connexion entre deux application sur les machines hotes. +Cela inclue donc le multiplexage des données (c'est le port sur la machines hotes), ainsi que la gestion de la congestion. +Les couches $5$ et $6$ n'ont pas d'influance sur la suite, et sont donc négligé. +Elles permetent par exemple d'encrypté la connexion avec le \emph{SSL}. +La couche $7$ est la couche applicative, c'est à dire l'utilisations final que l'ont fait de la connexion. +Cela peut etre chargé une page inernet, lire ses mails, regarder une vidéo, ou bien, transmetre des mesures d'un capteur. +C'est cette dernière utilisation qui nous interresse ici. + +La qualité d'une connexion entre deux points peut etre évalué grace à deux valeurs : \begin{itemize} + \item Le delai, qui correspont à la durée écoulé entre le moment où l'application émétrice veux emmetre le message, et le moment où le message est reçu par l'application cliente. + \item Le débit, qui correspont à la quantité de bits pouvant etre envoyé par seconde entre les deux applications. +\end{itemize} + +Ces deux grandeur n'ont pas la même importance selon l'application. +Par exemple, pour envoyé un piece jointe dans un mail, le delai n'est pas très important, c'est le débit qui compte pour que la transactio ne soit pas trop longue. +Mais pour un jeu en ligne, il y a peu de donné à echangée, mais il faut le faire avec le moins de délai possible pour que le jeu reste fluide. +Suivant l'application, il faut favorisé l'un ou l'autre, ou trouver un compromis satifaisant. + \subsubsection{Qu'est-ce que la congestion ?} +Malheureusment, les reseaux étant hétérogène, on ne controle pas tout les parrametres lorsque on les utilise. +En effet, pour envoyé un paquet à une autre machines, il faut (dans le cas général) passer par plusieurs intermediaire, les routeurs. +Lesdit routeurs ne doivent pas géré que un seul flux, et tout les liens entre les routeurs n'ont pas la même capacité, ainsi on se retrove avec des accumulaions de paquet dans certain routeur. +L'accumulations se produit au niveau des goulots d'étranglements. +Les routeurs n'ont pas une mémoire infini, ils ne peuvent donc pas laisser les queues d'envoie grandir à l'infini. +Elles ont donc une taille limite, et il faut donc parfois ne pas traité certain paquet lorsque le réseau est trop chargé. +Ce phénoméne est la congestion. +On cherche à l'évité, car un paquet non-traité est un paquet perdu, et donc le message n'est pas complet pour le client. +La gestion de la congestion sera expliqué avec plus de détail dans la partie \ref{part_cc}. +La detection 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 perdu. +Lorsque des paquets sont perdu à cause de la congestion, il faut les réenvoyé, en faisant attention de ne pas recongestioner le réseau. +Une grande partie des optimisations du \CC à lieu au niveau de ce temps d'attente, le \rto. + \subsubsection{Quelle sont les spécificité des réseaux \iot{} ?} +Dans un réseau \iot, les contraintes et applications sont différentes : \begin{itemize} + \item On échange des messages courts, + \item on veux minimisé la consomation energetique des machines, + \item les machines sont peut puissante, et ne peuvent pas réalisé des calcule complexe. +\end{itemize} + +Les technologies employé sont surtout des connexions dans fils à basse consomation, et à bas débit. +On peut cité les technologies + +De plus, pour accédé aux ressources d'une autre machine, on ne peut pas utilisé l'\http{} comme sur un ordinateur de bureau ou un téléphone. +En effet, \http{} s'appuis sur \tcp{}, et induit donc beaucoup de message supplémentaire. +Ainsi, puisque on echange des petits messages, on se retrouve avec plus d'entête que de contenu dans les couches physique, et donc on consomme beaucoup de ressources pour rien. +Un nouveau protocole a donc été dévolopé pour proposé des fonctionalités similaire à \http{}, mais adapté au contrainte de l'\iot{}, le protocole \coap{}. + \subsection{Quelle sont les particularités du \coap{} ?} +\coap{} est un protocole de la couche $7$ de l'\emph{IETF} (Internet Engenering Task Force) offrant une interface similaire à l'\http. +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 intéragire 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 DELETE : on supprime la ressource. + \end{itemize} +\end{itemize} +En plus de ses méthodes qui ont leurs equivalents chez \http{}, il y a la methode OBSERVE. +Si un client demande à observé une ressource sur un serveur, le serveur lui enveré automatiquement la ressource à chaque fois que elle est modifiée. + +D'un point de vu technique, \coap{} a la particularité de reposé sur l'\udp{} et non le \tcp{}. +Ainsi le \CC{} est réalisé par la couche applicative et non la couche transport. + +Lorsque l'on envoie un message, il peut etre de deux type : \begin{itemize} + \item CON : confirmable, on demande un accusé de reception du message, + \item NCON, non-conformable, on ne demande pas d'accusé de reception. +\end{itemize} +Les messages NCON ne sont donc pas réenvoyé si ils sont perdu à cause de la congestion, car il n'y a pas de moyen de la détecter. +Cela peut ne pas etre un problème pour certaine application. + +Ses derniers temps, des nouvelles solutions bassé sur l'apprentissage machine se sont développé pour le \CC{} en \tcp{}. +Notre problèmatique est donc de savoir si de tel solutions sont applicable à \coap{}. + \subsection{Qu'est-ce que l'apprentissage par renforcement ?} +L'apprentissage par renforcement est une solution d'apprentissage machine pour les systèmes markoviens. +Le système est constitué d'un environnement et d'un acteur. +On suppose que le temps est discontinu. +Ainsi à l'instant $t$, l'environement est dans un état $e \in \mathbb{E}$. +L'acteur observe l'environement au travers d'un interpréteur, qui lui renvoie un vecteur $s \in \mathbb{S}$, le vecteur d'observation. +L'acteur à la possibilité de réalisé une action $a in \mathbb{A}$ pour influancé l'environement. +Suite à cette action, l'environement change d'état, et renvoie à l'acteur un nouveau vecteur d'observation et une récompence $r \in \R$. +Cette récompence permet de quantifier la qualité de l'action et du nouvel état. +Pour la suite, on notera $x ^ i$ la i-ème grandeur, et $x_t$ la grandeur à l'instant $t$. +Le but de l'acteur est de maximisé la récompence total qu'il va recevoire au cours d'un épisode, c'est à dire une succession de pas de temps. +Pour cela, l'acteur doit crée une fonction $\pi : \mathbb{S} \rightarrow \mathbb{A}$ permetant de donner l'action optimal à réaliser pour chaque état. + +La methode de base pour construire cette fonction est le \qlearn{}. +C'est un possecus itératif où l'ont va construire un tableau (la Q-table), noté $\mathbb{Q} : \mathbb{S} \times \mathbb{A} \rightarrow \R$ associant à chaque couple observation/action une valeur. +On parcours l'environement et à chaque pas de temps, on met à jour la valeur de $\mathbb{Q}(s_t, a_t)$ grace à la formule suivante : \begin{equation} + \mathbb{Q}\left(s_t, a_t \right) := \left(1 - \alpha\right) \cdot \mathbb{Q}\left(s_t, a_t \right) + \alpha \cdot \left( r_t + \gamma \cdot max _ {a \in \mathbb{A}} \mathbb{Q} \left((s_{t+1}, a \right) \right) + \label{qlearn_update} +\end{equation} +Les deux paramètre sont : \begin{itemize} + \item $\alpha$ le taux d'apprentissage, c'est à dire à quelle point les nouvelles informations écrasent les anciennes, + \item $\gamma$ l'horizon, qui permet de controler à quelle point l'algorithme se préocupe du future. +\end{itemize} +La méthode pour choisir quelle action prendre à 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éatoire avec une probabilité faible pour exploré l'environement. +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 valeur du tableau ais lieu. +Pour palié à cela, on peut approximé la fonction par un réseau de neurrone, c'est le principe du \dqlearn{}. \section{État de l'art} @@ -163,6 +291,12 @@ print("hello world") \section{Conclusion} \lipsum[3] +\clearpage + +\listoffigures + +\listoftables + % --- Biblio par .bib \bibliography{rapport.bib}