diff --git a/rapport.tex b/rapport.tex
index 95f2d29..50cc528 100644
--- a/rapport.tex
+++ b/rapport.tex
@@ -7,7 +7,7 @@
 
 \hypersetup{
   pdftitle={Titre},
-  pdfauthor={Auteur},
+  pdfauthor={Léopold Clément},
   pdfsubject={Sujet},
   pdfproducer={Conversion PDF},
   pdfkeywords={Quelques mots-clés} %
@@ -18,6 +18,7 @@
 
 % ------------- Packages spéciaux, nécessaires pour ce rapport, à insérer ici ------------- 
 \usepackage{minted}
+\usepackage{lscape}
 
 \usepackage[toc]{glossaries}
 \makeglossaries
@@ -62,6 +63,14 @@
 
 \newcommand{\cocoa}{\gls{cocoa}}
 
+\newglossaryentry{ns}
+{
+  name=ns-3,
+  description={Simulateur réseau puissant. \url{https://www.nsnam.org/}}
+}
+
+\newcommand{\ns}{\gls{ns}}
+
 \newglossaryentry{keras}
 {
   name=keras,
@@ -146,6 +155,7 @@
 \newcommand{\dqlearn}{Deep-Q-learning}
 \newcommand{\cubic}{TCP-Cubic}
 \newcommand{\newreno}{TCP-NewReno}
+\newcommand{\cpp}{C++}
 
 \newglossaryentry{rtt}
 {
@@ -593,16 +603,102 @@ D'autre choix sont possibles, par exemple $\mathbb{A} = \left\lbrace 0.1, 0.5, 0
 
 \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
+Pour cela, il faut se demander ce que l'on veux comme caractéristique.
+Je choisit comme critaire : \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.
+\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$:
+\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$ :
+\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 : 
+\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}
+\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.
 
 \subsection{Quel type d'agent utilisé ?}
+Maintenant que l'environement est fixé, on peut déterminer comment l'acteur va s'intégrer.
+On choisit le fonctionement 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 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.
+
+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.
+\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.
+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.
+
+\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{}.
+
+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é.
+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.
 
 \subsection{Comment récolté de l'expérience ?}
 
-\subsubsection{Par exploration}
+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.
+
+\subsubsection{Par exploration en simulateur}
+Une solution simple, en théorie, est d'utilisé 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, je n'ais pas réalisé de simulation \ns{}, mais ca peut etre une piste à étudier pour le pré-entrainement.
 
 \subsubsection{Par création artificiel de transition}
 
+Une autre méthode possible est de créer des transitions artificiellement.
+Pour cela, je 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 je prend plusieurs consigne de \rto{} $c_n$, et pour chaque consigne, je l'applique à l'agent, et je mesure le vecteur d'observation associé $s_n$ ainsi que $r_n$.
+Puis pour chaque couple $(s_n, s_m)$, je calcule l'action $a_{n , m}$ pour passer de $c_n$ à $c_m$.
+Je peu ainsi construire une série de trnasition $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.
+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.
 
 \section{Implémentation de l'algorithme}
 
@@ -614,7 +710,7 @@ Pour cela, il faut se demander ce que l'on veux comme caractéristique
 
 \subsection{Structure du code}
 
-\subsection{Maquette utilisée}
+\subsection{Maquette utilisée\label{part_maquette}}
 
 \subsection{Astuce pour simuler une congestion}
 
@@ -659,8 +755,15 @@ Pour cela, il faut se demander ce que l'on veux comme caractéristique
 \appendix
 \begin{appendices}
 
-  \section{}
+  \section{Structure du code}
 
+  \begin{landscape}
+    \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.}
+  \end{figure}
+  \end{landscape}
 
 \end{appendices}