template latex para informe

docs/installation

@@ -347,8 +347,5 @@ Pasos para llevar a cabo la instalación de Openstack Ansible
 
 
 
-
-
-
-
-
+------ AGREGAR INFO DEL COMMIT 
+https://github.com/openstack/openstack-ansible-lxc_hosts/commit/43e61820f42d88f36ec0ab4865800cbb4b1076ae#diff-a32feedfc0fe75301cf2f812b316e6a2R27

docs/latex/.gitignore

+report.aux
+report.bbl
+report.blg
+report.log
+report.out
+report.synctex.gz
+texput.log

docs/latex/references.bib

+@MastersThesis{tesis,
+author = {Richart, Matías},
+title = {IEEE 802.11 parameters adaptation for Performance enhancement in high density Wireless networks},
+school = {Facultad de Ingeniería},
+year = {2014}
+}
+
+@Article{articulo,
+author = {Richart, Matías and Visca, Jorge and Baliosian, Javier},
+title = {Rate, Power and Carrier-Sense Threshold Coordinated Management for High-Desity IEEE 802.11 Networks},
+journal = {IEEE},
+year = {2015}
+}
+
+@thesis{proyecto,
+author = {Artave, Jorge and Irland, Matías},
+title = {Control de parámetros de transmisión en Redes WiFi 802.11},
+type = {Grado},
+institution = {Facultad de Ingeniería},
+year = {2017}
+}
+
+@Misc{gnuplot,
+author = {Williams, Thomas and Kelly, Colin},
+title = {{gnuplot}: an interactive plotting program},
+howpublished = {\url{http://www.gnuplot.info/}},
+note = {Accessed: 2017-12-14}
+}
+
+@Misc{iperf,
+author = {Dugan, Jon and Elliott, Seth and Mah, Bruce A. and Poskanzer, Jeff and Prabhu, Kaustubh},
+title = {{iperf}: the ultimate speed test tool for TCP, UPD and SCTP},
+howpublished = {\url{https://iperf.fr/}},
+note = {Accessed: 2017-12-14}
+}
+
+@Misc{kprint,
+title = {System log in OpenWrt},
+howpublished = {\url{https://wiki.openwrt.org/doc/howto/log.essentials}},
+note = {Accessed: 2017-12-16}
+}
+
+@Misc{aircrack,
+title = {Aircrack-ng},
+howpublished = {\url{https://www.aircrack-ng.org/}},
+note = {Accessed: 2017-12-16}
+}
+
+

docs/latex/report.tex

+\documentclass[a4paper, 10pt]{article}
+
+%% Language and font encodings
+\usepackage[spanish]{babel}
+\usepackage[utf8x]{inputenc}
+\usepackage[T1]{fontenc}
+
+%% Sets page size and margins
+\usepackage[a4paper,top=3cm,bottom=2cm,left=3cm,right=3cm,marginparwidth=1.75cm]{geometry}
+
+%% Useful packages
+\usepackage{amsmath}
+\usepackage{graphicx}
+\usepackage{multicol}
+\usepackage{listings}
+\usepackage{algorithm,algorithmic}
+\usepackage{subcaption}
+\usepackage{fancyhdr}
+\graphicspath{ {resources/} }
+\usepackage[colorinlistoftodos]{todonotes}
+\usepackage[colorlinks=true, allcolors=black]{hyperref}
+
+
+\title{Despliegue de un Datacenter con Openstack}
+\author{Matías Capucho, Santiago Elizondo \\
+			Universidad de la República, Montevideo, Uruguay. \\
+			Email: \href{mailto:matias.capucho@fing.edu.uy}{selizondo@fing.edu.uy}, \href{mailto:santiago.elizondo@fing.edu.uy}{santiago.elizondo@fing.edu.uy} }
+
+\date{4 de Junio de 2019}
+
+\pagestyle{fancy}
+
+
+\begin{document}
+\maketitle
+
+\begin{abstract}
+El presente documento relata el proceso de diseño, instalación, y configuración básica de un Datacenter mediante la utilización de Openstack. Durante el mismo se especifican los pasos necesarios a seguir  y se detallan puntos sumamente relevantes a tener en cuenta.
+\end{abstract}
+
+\section{Introducción}
+En la actualidad es muy común encontrar redes inalámbricas IEEE 802.11 (WiFi) en la mayoría de los sitios urbanos. Estas redes tienden a ser denominadas de alta densidad debido a la gran cantidad de Access-Points (AP) cuyas áreas de cobertura se encuentran solapadas. Generalmente, la disposición de los AP no es planificada adecuadamente y sumado a la alta y fija potencia de transmisión de todos estos dispositivos genera que la calidad del servicio y el ancho de banda se vean altamente perjudicados. Esto impacta directamente en los usuarios que demandan un servicio de alta velocidad.\\
+
+Para lidiar con este problema existen diversos algoritmos que intentan regular de forma personalizada la tasa y la potencia de transmisión (rate y power) para cada terminal asociada al AP. El estándar IEEE 802.11 permite modificar estas variables pero no define cómo se deben tomar las decisiones de modificación. Dentro de los algoritmos mencionados, pondremos foco en el Robust Rate and Power Adaptation Algorithm (RRPAA) diseñado por Matías Richart como parte de su tésis de Maestría \cite{tesis} y analizaremos su comportamiento para ajustar y mejorar el desempeño del mismo.
+
+\section{Análisis inicial}
+\subsection{Algoritmo RRPAA}
+El RRPAA tiene por objetivo central minimizar el power y maximizar el rate que en conjunto maximizan el throughput para cada sesión entre el AP y sus terminales asociadas. Para esto, se intenta mantener el porcentaje de pérdida de tramas, denominado Frame Loss Rate (FLR), dentro de determinado rango para una cierta ventana de tramas enviadas. Durante la sesión entre ambos terminales se recolecta información estadística que permite determinar el valor del FLR y compararlo contra dos valores límites:
+\begin{itemize}
+	\item Maximum Tolerable Loss (MTL)
+	\item Opportunistic Rate Increase (ORI)
+\end{itemize}
+
+Estos valores servirán de referencia para tomar las decisiones a la hora de bajar y subir de estado. Los estados consisten en los pares (power, rate) asociados a la transmisión entre las terminales y son ordenados de forma que un mayor estado implica menor power y mayor rate. El pseudocódigo asociado al orden entre estados puede verse en el algoritmo \ref{alg1}.
+
+\begin{algorithm}[H]
+  \floatname{algorithm}{Algoritmo}
+  \caption{Orden entre estados}
+  \label{alg1}
+  \begin{multicols}{2}
+  \begin{algorithmic}[1]
+    \IF{$p_{0} == p_{max}$}
+      \STATE $anterior(r_{0}, p_{0}) = (r_{-1}, p_{0})$
+    \ELSE
+      \STATE $anterior(r_{0}, p_{0}) = (r_{0}, p_{1})$
+    \ENDIF
+  \end{algorithmic}
+    \begin{algorithmic}[1]
+    \IF{$r_{0} < r_{max}$}
+      \STATE $siguiente(r_{0}, p_{0}) = (r_{1}, p_{0})$
+    \ELSE
+      \STATE $siguiente(r_{0}, p_{0}) = (r_{0}, p_{-1})$
+    \ENDIF
+  \end{algorithmic}
+  \end{multicols}
+\end{algorithm}
+
+Debido a que el medio de transmisión entre dos terminales puede variar continuamente afectando la estabilidad del algoritmo, se define un mecanismo llamado Probabilistic Rate Increase que busca asegurar la convergencia del mismo. Se maneja entonces una tabla de probabilidades que mantiene la probabilidad de ingresar a cada uno de los estados previamente definidos.\\
+Cuando durante la transmisión se dan demasiadas pérdidas y el RRPAA decide pasar a un estado anterior, utilizará previamente una variable aleatoria que comparará contra la probabilidad del estado al que quiere acceder. En caso de caer dentro de la probabilidad, luego de bajar de estado bajará la probabilidad de todos los estados superiores para evitar volver facilmente a una situación con alta tasa de pérdidas.\\
+Análogamente, luego de alcanzar un estado superior se sube la probabilidad de todos los estados anteriores para volver rápidamente en caso de que se produzca un exceso de pérdidas.\\
+
+\begin{algorithm}[H]
+  \floatname{algorithm}{Algoritmo}
+  \caption{Pseudocódigo RRPAA}
+  \label{alg2}
+  \begin{algorithmic}[1]
+    \IF{$FLR > MTL(rate)$  \AND $power < maxPower$}
+      \STATE {$priTable[rate][power] /= \gamma$}
+      \STATE {$power++$}
+    \ELSIF {$FLR > MTL(rate)$ \AND $power == maxPower$}
+      \STATE {$priTable[rate][power] /= \gamma$}
+      \STATE {$rate--$}
+    \ENDIF
+    \IF{$FLR < ORI(rate)$}
+    	\FORALL {$r < rate$}
+    		\STATE {$priTable[r][power] *= \delta$}
+    	\ENDFOR
+    	\IF {$rate < maxRate$ \AND $rand() < priTable[rate+1][power]$}
+    		\STATE {$rate++$}
+    	\ELSE
+    	 	\FORALL {$p > power$}
+    			\STATE {$priTable[rate][p] *= \delta$}
+	    	\ENDFOR
+	    	\IF {$power > 0$ \AND $rand() < priTable[rate][power-1]$}
+	    		\STATE {$power--$}
+	    	\ENDIF
+	    \ENDIF
+	\ELSIF {$FLR >= ORI(rate)$ \AND $loss < MTL(rate)$ \AND $power > 0$}
+		\FORALL {$p > power$}
+    		\STATE {$priTable[rate][p] *= \delta$}
+	    \ENDFOR
+	    \IF {$power > 0$ \AND $rand() < priTable[rate][power-1]$}
+	    	\STATE {$power--$}
+	    \ENDIF
+	\ENDIF    	
+  \end{algorithmic}
+\end{algorithm}
+
+El pseudocódigo del algoritmo utilizado por el RRPPA se encuentra en el algoritmo \ref{alg2}. Mientras que un resumen del comportamiento del mismo puede apreciarse en la figura \ref{flr}.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{linea_flr}
+	\caption{Decisiones tomadas segun FLR}
+	\label{flr}
+\end{figure}
+
+Una descripción mas detallada de su comportamiento puede encontrarse en \cite{proyecto}, \cite{tesis} y \cite{articulo}.
+
+
+\subsection{Implementación}
+El algoritmo RRPAA fue implementado en hardware como parte del proyecto de grado de Matías Irland y Jorge Artave en marco de la carrera Ingeniería en Computación de la Facultad de Ingeniería, UdelaR \cite{proyecto}. Para su desarrollo se utilizó como base la implementación existente de Minstrel incluida en el kernel de OpenWrt. Minstrel se trata de un algoritmo de control de rate que basa su comportamiento en la recolección de estadísticas mediante el envío de tramas de sondeo. No entraremos en mayor detalle sobre este algoritmo pero cabe mencionar que suele ser el estándar incluido en las distribuciones de OpenWrt.\\
+
+La implementación de RRPAA fue realizada sobre el driver Ath9k desarrollado por Qualcomm Atheros para controladores WiFi y basada en el estándar IEEE 802.11g.\\
+El código implementado se encuentra en tres archivos dentro del módulo kmod-mac80211:
+\begin{itemize}
+	\item \textbf{rc80211\_rrpaa.h}: Definición de constantes y estructuras a utilizar y funciones a ser utilizadas por otros archivos del módulo.
+	\item \textbf{rc80211\_rrpaa.c}: Implementación del algoritmo.
+	\item \textbf{rc80211\_rrpaa\_debugfs.c}: Funciones para la recolección de datos estadísticos.
+\end{itemize}
+
+El ciclo de la ejecución consta de cuatro etapas bien definidas:
+\subparagraph{Inicialización}En primer lugar se da la inciailización de las estructuras reservando la memoria necesaria para mantener la sesión con cada terminal cada vez que uno de estos se asocia al AP. Dentro de esta etapa se define el rango de rates y powers soportados por ambos terminales, se calculan los valores de ORI y MTL y se inicializa la tabla de probabilidades asociada.
+\subparagraph{Recolección de datos}La siguiente etapa se trata de la recolección de datos. Esta consiste en almacenar la cantidad de intentos realizados y exitosos para cada estado asociado luego del envío de cada paquete. Esta información es utilizada posteriormente para la ejecucción del algoritmo antes descrito.
+\subparagraph{Toma de decisiones}La tercera etapa se denomina toma de decisiones, es aquí en donde se ejecuta explícitamente el algoritmo diseñado y se determina en función de los datos previamente recolectados y de la tabla de probabilidades, cuál será el próximo estado a ser utilizado en la transmisión de las restantes tramas. Para manejar adecuadamente la representación númerica del kernel, se mapearon las probalidades en el rango $(0,1]$ al rango $[1,4096]$, aplicando un shifteo a la izquierda de doce posiciones.
+\subparagraph{Asignación}Finalmente, se asignan las parejas de rate y power asociadas a la retry chain para la próxima transmisión. La retry chain se trata de una estructura de datos que almacena los parámetros a utilizar en cada intento de transmisión de una trama. En este caso, la cadena tendrá largo 4 y almacenará los pares $(rate, power)$ y la cantidad $c$ de intentos posibles a utilizar hasta saltar al siguiente valor de la cadena. En caso de que se den mas de $c$ pérdidas durante el envío de la trama, se intentará enviar con los valores de la siguiente posición y así sucesivamente hasta el final de la misma. Este mecanismo busca disminuir el overhead necesario para el cálculo del valor de las variables en caso de pérdidas. En esta implementación, los siguientes valores de la retry chain serán calculados en función del estado determinado por RRPAA siguiendo el pseudocódigo \ref{alg3}. Cabe resaltar que para la última posición de la cadena se optó por asignar el menor estado posible (power máximo y rate mínimo) con el fin de asegurar el envío de la trama en cuestión.
+
+\begin{algorithm}[H]
+  \floatname{algorithm}{Algoritmo}
+  \caption{Asignación de valores a la retry chain}
+  \label{alg3}
+  \begin{algorithmic}[1]
+	\WHILE {$can\_add\_items\_to\_retry\_chain$}
+		\IF {$power < p_{max}$}
+			\STATE {$power = next_power$}
+		\ELSIF {$rate > rate_{min}$}
+			\STATE {$rate = previous_rate$}
+		\ENDIF
+	\ENDWHILE   	
+  \end{algorithmic}
+\end{algorithm}
+
+\section{Detección de errores}
+Luego de tener claro el diseño del algoritmo RRPAA y de analizar la implementación en hardware del mismo, se detectaron ciertas inconsistencias en el código que no seguían fielmente la idea original. Estos errores podrían generar que los resultados obtenidos durante las pruebas no fueran significativos y por ende requerían de su correción para poder continuar con el proyecto.\\
+A continuación se detallan los errores detectados según la función correspondiente y su solución aplicada.
+
+\subparagraph{\textbf{rrpaa\_tx\_status}} Uno de los primeros errores se daba durante la recolección de datos. Específicamente en la función $rrpaa\_tx\_status$ encargada de recorrer la retry chain y determinar para cada rate la cantidad de intentos realizados y exitosos en caso de que corresponda. El error se debía a que si la trama se había transmitido con éxito, se sumaba 1 a la cantidad de éxitos de los rates de la cadena que se posicionaban desde el inicio hasta el verdadero rate exitoso. Para corregirlo se sumó correctamente sólo al rate que efectivamente obtuvo un éxito en la retry chain.
+
+\subparagraph{\textbf{rrpaa\_update\_stats}} Los siguientes errores se corresponden todos a la etapa de toma de decisiones. La función $rrpaa\_update\_stats$ es la responsable de ejecutar el algoritmo \ref{alg2} pero luego de analizarla se detectaron cuatro errores importantes que no seguían la idea original, todos estos se detallan a continuación:
+\begin{itemize}
+\item Al momento de tomar la decisión de cambio de estado, se recorría todo el arreglo de rates manejado con la terminal y se aplicaba el algoritmo múltiples veces ya que se consideraba el FLR de cada uno de estos. Esto no es correcto ya que para determinar las transiciones entre estados, sólo se debe tener en cuenta el estado actual y no todos los posibles. La solución consistió en seguir estrictamente el pseudocódigo planteado y utilizar solo el estado actual para tomar la decisión.
+
+\item Cuando el algoritmo planteado debía aumentar de estado bajando el power, se utilizaba la probabilidad del estado anterior subiendo el power. Este posiblemente fuera un error de tipeo al colocar un $+$ en lugar de un $-$ pero afectaba significativamente el uso de la tabla de probabilidades para la convergencia del algoritmo. Su correción fue trivial.
+
+\item Cuando el estado actual contenía el máximo power posible  y se debía aumentar el estado bajando esta variable, no se consultaba la tabla de probabilidades para tomar la decisión. Esta determinación no se encuentra en lo especificado por el pseudocódigo y por lo tanto fue removida.
+
+\item Además de tomar las decisiones de transición entre estados, esta función se encarga de actualizar los datos históricos de intentos realizados y exitosos para cada rate y bajar a cero los contadores correspondientes. Esto se realiza cada vez que se ejecuta el $rrpaa\_update\_stats$, sin embargo la bajada a cero de estos contadores solo se estaba realizando para aquellos rates que habían alcanzado el tamaño de ventana requerido para ejecutar el algoritmo en función del FLR. Esto generaba que en los datos históricos aparecieran cantidades mucho mayores que las reales debido a que se sumaban al mismo los mismos intentos más de una vez. Su correción consistió en bajar explícitamente estas variables para todos los rates al final de la función.
+\end{itemize}
+
+\section{Escenarios de prueba}
+El objetivo de estos escenarios consiste en analizar el comportamiento de RRPAA en comparación con Minstrel en tres situaciones muy distintas entre sí. En una primera instancia se analizará un escenario simple. En él se plantea evaluar el comportamiento de un router emisor con un nodo receptor a medida que se aumenta y disminuye la distancia entre ellos.\\
+
+Para una segunda prueba se plantea un escenario mas adecuado al funcionamiento de RRPAA. En este existen  dos routers transmitiendo información, cada uno a un nodo particular de forma que ambos routers generan interferencias entre sí. En este caso se busca verificar que el algoritmo reducirá el power utilizado para evitar interferencias innecesarias, obteniendo un canal más libre y limpio.\\
+
+Finalmente, se plantea un escenario que en la teoría revelaría una falla inevitable del algoritmo RRPAA. Este consiste en tener un nodo N1 asociado a un router R1 a una distancia significativamente amplia, generando que R1 utilice una potencia alta. Por otro lado, sobre la frontera del radio de alcance de R1, se encuentra otro router R2 asociado a un nuevo nodo N2 pero a una distancia muy cercana entre ambos.
+
+\subsection{Distancias}
+\label{Distancias_escenario}
+Con este escenario se busca analizar el comportamiento de la implementación de RRPAA en función de la distancia respecto al router, así como evaluar el algoritmo en un escenario simple. Para esto se propone un escenario en donde se coloca un router y una terminal a una distancia inicial de 3 metros. Tras comenzar la prueba, se alejará el terminal una distancia de 6m cada 3 minutos hasta llegar a una distancia máxima de 63m. Luego de alcanzar esta distancia, se realizará el proceso inverso disminuyendo la misma en intervalos análogos hasta alcanzar el punto inicial.\\
+
+Esta prueba es realizada 10 veces con RRPAA y 10 veces con la implementación original de Minstrel. Por otro lado se utilizarán los resultados obtenidos en las primeras tiradas de la prueba en cuestión para realizar un ajuste inicial del algoritmo buscando mayor estabilidad y convergencia de los resultados.
+
+\begin{figure}[h]
+	\centering
+		\includegraphics[width=0.6\columnwidth]{diagrama_distancias}
+	\caption{Diagrama del escenario distancias}
+	\label{Distancias}
+\end{figure}
+
+\subparagraph{Resultado esperado}
+En este escenario es esperable que el rendimiento de ambos algoritmos sea similar, es decir, que tanto Minstrel como RRPAA garanticen el máximo throughput posible otorgado a un único cliente asociado. Además es esperable que el power utilizado incremente en cuanto se aumenta la distancia y decremente en el caso contrario. Debido a la disminución del power y tiempo de adaptación requerido para el funcionamiento de RRPAA, se espera que exista una tasa de pérdidas levemente superior en comparación con Minstrel.
+
+
+\subsection{Overlapping}
+En este escenario se busca analizar el comportamiento de RRPAA en un ambiente con conexiones solapadas, buscando simular un ambiente denso. Para esto se hará uso de dos terminales asociadas cada una a un router diferente.
+El experimento consistirá de varias etapas con el fin de cubrir los siguientes casos:
+\begin{itemize}
+	\item no es posible aislar las transmisiones entre cada par de nodos
+	\item es posible aislar las transmisiones entre cada par de nodos
+\end{itemize}
+
+Para llevar a cabo lo planteado, se colocará cada par (router, terminal) a diferentes distancias entre sí, en particular serán:
+\begin{itemize}
+	\item 3
+	\item 6
+	\item 18
+	\item 36
+	\item 66
+\end{itemize}
+
+Los terminales estarán a una distancia de 60cm de sus respectivos routers en todas las etapas.
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}{.5\textwidth}
+  \centering
+  \includegraphics[width=.85\linewidth]{diagrama_overlapping_1}
+  \caption{Es posible aislar transmisiones}
+  \label{fig:sub1}
+\end{subfigure}%
+\begin{subfigure}{.5\textwidth}
+  \centering
+  \includegraphics[width=.5\linewidth]{diagrama_overlapping_2}
+  \caption{No es posible aislar transmisiones}
+  \label{fig:sub2}
+\end{subfigure}
+\caption{Diagrama del escenario overlapping}
+\label{overlapping}
+\end{figure}
+
+\subparagraph{Resultado esperado}
+En estos escenarios se esperan distintos comportamientos a medida que avanzan las etapas y por lo tanto se aumenta la distancia. En las distancias iniciales se espera un comportamiento similar en ambos algoritmos, con un degradamiento significativo en el throughput de los routers.
+Luego, a medida que alejamos los dispositivos se espera que las transmisiones mejoren debido a que las interferencias disminuirán. En estos casos RRPAA debería mejorar más rápido que minstrel ya que puede regular la potencia y evitar aún más las interferencias.
+Llegando a la última prueba debería ser insignificante las interferencias entre las transmisiones y el comportamiento de ambos routers se espera que sea similar. 
+
+\subsection{Starvation problem}
+\label{Starvarion_Escenario}
+El algoritmo RRPAA busca ajustar los niveles de potencia con los que se envían los paquetes con el fin de evitar la interferencia en redes densas. Esta técnica puede mejorar la performance en algunos escenarios pero conducir la red a un problema de acceso injusto al medio.\\
+
+Para explicar el problema utilizaremos la figura \ref{starvation} que nos permitirá definir dos rangos distintos:
+\begin{itemize}
+\item \textbf{Rango de transmisión:} un receptor dentro del rango de transmisión de un emisor recibirá los paquetes satisfactoriamente, siempre que no haya interferencia.
+\item \textbf{Rango del Carrier Sense:} un nodo dentro del rango del carrier sense de un emisor podrá sensar si el medio está siendo ocupado cuando hay transmisiones. Entre otras cosas, esto depende de la potencia de transmisión del emisor y de los límites del carrier sense del receptor.
+\end{itemize}
+
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.6\columnwidth]{diagrama_starvation}
+	\caption{Diagrama del starvation problem}
+	\label{starvation}
+\end{figure}
+
+En la figura anterior, T0 y T1 son los transmisores y N0 y N1 los receptores. Las flechas indican un flujo de transmisión, mientras que 
+los círculos cerrados y punteados representan los rangos de transmisión y de Carrier Sense respectivamente.
+La figura muestra un escenario en el que se genera un problema de terminal expuesta asimétrico. En el mismo, T0 puede sensar a T1 y por lo tanto podrá pausar su transmisión pero T1 no puede sensar a T0 por lo que transmitirá continuamente, generando un acceso al medio injusto.
+
+\subparagraph{Resultado esperado} Bajo estas condiciones se espera que RRPAA no sea capaz de evitar el Starvation problem y generar un acceso injusto al medio. En la teoría, el emisor T0 no sería capaz de transmitir hacia N0 debido a que T1 nunca liberaría el medio transmitiendo a un potencia mucho mas alta.
+
+\section{Scripts y herramientas}
+Para la ejecución de todas las pruebas realizadas, se utilizaron diversos scripts tanto a nivel del AP en el sistema OpenWrt como de los terminales Ubuntu asociados al mismo. También fueron requeridos scripts y herramientas para la recolección de datos estadísticos y su posterior análisis gráfico y para el registro de logs de debugging en el propio código. Cada uno de estos será descrito a continuación.
+
+\subsection{Scripts}
+\subparagraph{Access Point:}
+\begin{itemize}
+\item \textbf{clear\_log.sh:} su función es limpiar el registro de $time\_states$ almacenados hasta el momento para cada estación conectada al router.
+
+\item \textbf{list\_device.sh:} este script es utilizado para obtener las MAC de todas las estaciones que se encuentran asociadas al router.
+
+\item \textbf{live\_stats.sh:} utilizado para mostrar en consola la información obtenida por el $rc\_time\_state$ de una estación cuya MAC es pasada como parámetro.
+
+\item \textbf{macState.sh:} brinda información relativa a las frecuencias manejadas por el router.
+
+\item \textbf{save\_time\_state\_log.sh:} en primer lugar limpia los logs de cada estación al igual que en $clear\_log$. Luego, recorre cada estación asociada al router 35 veces y guarda la salida del $rc\_time\_state$ dentro del $/tmp/\$now/\$station$, donde now resulta ser una carpeta con la fecha y hora de cuando se lanzó el script y station es la MAC de cada estación.
+
+\item \textbf{install.sh:} instala en el AP los ipks con el algoritmo en cuestión colocados previamente en la carpeta $tmp$.
+
+\item \textbf{statistics.sh:} se encarga de registrar los datos obtenidos por el $rc\_time\_state$ de cada estación asociada al router dentro de una carpeta $logs/$ ubicada en una unidad USB montada en el directorio $/mnt/usb/$. Además, recibe como parámetro la cantidad de segundos que ejecutará la obtención de datos. Para hacer este control hace uso de la variable $SECONDS$ del sistema que retorna la cantidad de segundos desde que se ha comenzado a ejecutar el script.
+
+\item \textbf{time\_state.sh:} imprime en consola cada 1 seg la información obtenida por el $rc\_time\_states$ para una estación hardcodeada.
+
+\item \textbf{time\_state.sh:} imprime en consola cada 1 seg la información obtenida por el $rc\_stats$ para una estación hardcodeada.
+\end{itemize}
+
+
+\subparagraph{Terminal:}
+\begin{itemize}
+\item \textbf{generate\_test\_rrpaa.sh:} utilizado para iniciar el flujo de tráfico necesario durante una prueba desde el AP hacia el terminal desde el que se ejecuta. Para esto utiliza la herramienta $iperf3$ \cite{iperf}.
+
+\item \textbf{calculate\_graph.py:} su función consiste en generar las gráficas correspondientes a los datos estadísticos obtenidos en cada prueba. Para esto hace uso de scripts auxiliares que generan los cálculos necesarios para obtener las gráficas finales mediante la herramienta $gnuplot$ \cite{gnuplot}.
+
+\end{itemize}
+
+\subsection{Herramientas}
+\subparagraph{iperf3:}\cite{iperf} 
+Iperf3 se trata de una herramienta para la medición del máximo ancho de banda alcanzable en una red IP. Soporta la personalización de diversos parámetros como pueden ser el tiempo, buffers y protocolos utilizados. Para cada rest reporta, entre otros parámetros, el ancho de banda y la tasa de pérdidas. Esta herramienta fue utilizada para la generación de tráfico entre los terminales y los AP con un ancho de banda de 54Mb y flujo de paquetes UDP para evitar el overhead de la capa de transporte del protocolo TCP.
+
+\subparagraph{gnuplot:}\cite{gnuplot}
+Gnuplot consiste en una funcionalidad por línea de comandos portable para realizar gráficas en Linux. Fue utilizada para el tratamiento gráfico de los datos recolectados durante cada prueba. Estos datos eran almacenados en un formato $.csv$ y utilizados por gnuplot para la generación de gráficas que contienen la cantidad de intentos realizados, los exitosos, la tasa de pérdidas, los rate y powers utilizados y el ancho de banda, entre otros.
+
+\subparagraph{kprint:}\cite{kprint}
+\label{Kprint}
+Kprint es un comando que permite escribir en los logs del sistema. La salida generada por el mismo puede ser dirigida a un archivo o directamente a memoria. Para configurar la herramienta se siguieron los pasos mencionados en la referencia. Se debe tener en cuenta que en caso de utilizar un archivo, es importante que su tamaño sea muy chico debido a la escasa memoria del router. Una de las ventajas de utilizar estos logs es que permanecen intactos en los casos en que el dispositivo se crashea por algún error inesperado, siendo muy útil para debbugear lo desarrollado.
+
+\subparagraph{aircrack-ng}\cite{aircrack}
+\label{aircrack}
+Aircrack-ng es una suite de herramientas por línea de comandos que permite evaluar la seguridad de una red wifi. De las herramientas ofrecidas se utilizaron dos: airmon-ng y airodump-ng. La primera fue utilizada para habilitar el modo monitor en la tarjeta de red inalámbrica y la segunda permite visualizar información de las redes wifi detectadas como el essid, bssid, channel, privacy, beacons, data, etc. También muestra información sobre los clientes conectados a dichas redes. Esta herramienta se utilizó para el escenario de Starvation problem, en donde era necesario conocer la distancia a la cual la señal del router que envía a potencia mínima no es detectada porrouter que envía a mayor potencia. Los pasos realizados para utilizar la herramienta son los siguientes:
+\begin{enumerate}
+\item sudo airmon-ng check, con esto se verifica que procesos pueden causar problemas al utilizar estas herramientas.
+\item sudo airmon-ng check kill, con este comando se finalizan los procesos detectados. En algunos casos es necesario ejecutarlo mas de una vez.
+\item sudo airmon-ng start nombre\_interface\_wifi, se inicializa la interfaz en modo monitor.
+\item sudo airodump-ng nombre\_interface\_monitor, con este comando se comienza a sensar las redes wifi vecinas y sus respectivos clientes. Para conocer el nombre de la interfaz en modo monitor se puede averiguar con el comando $ifconfig$.
+\item sudo airmon-ng nombre\_interface\_monitor, para deshabilitar el modo monitor.
+\item sudo service nerwork-manager restart, por ultimo hay que reiniciar el network-manager.
+\end{enumerate}
+
+\subsection{Procedimiento}
+Los pasos a seguir para la recolección de datos en cada prueba son los siguientes:
+\begin{enumerate}
+\item Conectar un terminal por WiFi al AP.
+\item Conectar un pendrive con una carpeta $logs$ al AP
+\item Montar el pendrive (ubicado en $/dev/sda1$) con $ mount /dev/sda1 /mnt/usb/$
+\item Ejecutar el script $generate\_test\_rrpaa.sh$ con los parámetros necesarios
+\item Al finalizar, desmontar el pendrive con $umount /dev/sda1$
+\item Analizar los resultados obtenidos en formato $.csv$ con el script $calculate\_graph.py$
+\end{enumerate}
+
+\section{Primeras pruebas}
+Luego de haber definido los escenarios, se comenzaron a realizar las primeras pruebas al algoritmo y analizar los resultados de las mismas.
+El comienzo de la etapa de pruebas fue un tanto ambicioso, iniciando directamente con el escenario de distancias descrito en \ref{prueba_distancias}. Con una primera ejecución se detectaron algunos problemas importantes en el RRPAA y por lo tanto se debió realizar un estudio más minuicioso con ejecuciones más cortas y controladas, definidas en el punto \ref{pruebas_individuales}.\\
+Cabe resaltar que debido a los distintos problemas que surgieron durante el análisis de la implementación y de los primeros resultados obtenidos, no fue posible seguir completamente el plan de pruebas diseñado. Esto llevó a realizar una única ejecución de la prueba de distancias con el algoritmo RRPAA y poner mayor énfasis en el tercer caso de prueba. Sin embargo, no fue posible comparar ninguna de las ejecuciones contra el algoritmo Minstrel.
+
+\subsection{Prueba de distancias}
+\label{prueba_distancias}
+Esta prueba consistió en llevar a cabo el primer escenario planteado en los escenarios de prueba \ref{Distancias_escenario}. Los resultados obtenidos en una primera ejecución de la prueba pueden apreciarse en las figuras \ref{prueba_distancias} y \ref{throughput_distancias}.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_distancias}
+	\caption{Resultados prueba de distancias}
+	\label{prueba_distancias}
+\end{figure}
+
+En las gráficas anteriores puede apreciarse la inestabilidad presente en el algoritmo. Se esperaba que la potencia de transmisión comenzara a incrementar, alcanzando su máximo sobre la mitad del tiempo y que posteriormente disminuyera volviendo al estado original. Sin embargo, esta variable se mantuvo oscilando la mayor parte del tiempo, siendo predominantes los valores más altos.\\
+Por otro lado, la tasa de transmisión tampoco tuvo un comportamiento deseado. La tasa de pérdidas, a pesar de algunos picos puntuales, se mantuvo dentro de los valores esperados.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{throughput_distancias}
+	\caption{Throughput: prueba de distancias}
+	\label{throughput_distancias}
+\end{figure}
+ 
+\subsection{Pruebas individuales}
+\label{pruebas_individuales}
+Estas pruebas fueron realizadas luego de analizados los resultados anteriores. Su objetivo consistió en detectar la causa de la inestabilidad del algoritmo y el motivo de la predominancia de la utilización de valores de power elevados.
+
+\subsubsection{Prueba 1}
+Consistió en una prueba simple, donde se situaron los terminales a una distancia corta de aproximadamente 3m.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_prueba_1}
+	\caption{Resultados prueba inicial 1}
+	\label{prueba_1}
+\end{figure}
+
+Nuevamente, se observa una inestabilidad durante la toma de decisiones entre estados y valores de power muy elevados para la distancia entre terminales.
+
+\subsubsection{Prueba 2}
+Luego de realizar los ajustes mencionados más adelante en la sección \ref{ajustes_algoritmo}, se repetió el escenario de la prueba anterior obteniendo resultados favorables.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_prueba_2}
+	\caption{Resultados prueba inicial 2}
+	\label{prueba_1}
+\end{figure}
+
+Finalmente, se logró obtener estabilidad en ambos parámetros del RRPAA y la utilización de powers casi nulos para una distancia muy corta.
+
+\subsection{Análisis de resultados}
+A partir de los resultados generados en estas dos pruebas se obtuvieron varias conclusiones sobre el comportamiento del algoritmo:
+\begin{itemize}
+\item El mismo no logró estabilizarse en ningún momento, tanto en las pruebas de distancias en donde los estados oscilaban independientemente de la distancia en la que se encontraba la estación del router, como en la primera de las pruebas individuales, con resultados similares en donde el algoritmo no lograba tender a un estado en particular.
+\item Estudiando la tabla de probabilidades se observó que los estados más altos, dada la inestabilidad del algorimo, tendían a disminuir su probabilidad de ingreso hasta llegar a 1. Esto afectaba en varios sentidos el funcionamiento del algoritmo:
+	\begin{itemize}
+	\item En primer lugar, en el supuesto caso que se pueda mejorar el estado actual del 	algoritmo, esto se iba a ver dificultado debido a que las probabilidades de entrar a 	un estado mayor serían demasiado pequeñas. En estos casos el algoritmo le estaría asignando mayor importancia al comportamiento histórico que a la situación actual de la estación.
+	\item Al llegar una probabilidad a 1, era imposible que la misma comience a incrementarse nuevamente debido a que el factor por el que se multiplica al momento de incrementarla es muy pequeño.
+	\end{itemize}
+\item Un aspecto a estudiar para mejorar la estabilidad del algoritmo es el valor de los parámetros cuando se multiplica y divide una probabilidad. Un detalle observado respecto a estos es que si una probabilidad es disminuida, luego para alcanzar el mismo valor se debe incrementar aproximadamente 8 veces. Es por esto que si el algoritmo no es muy estable las probabilidades de los estados más altos tienden a disminuir rápidamente.
+\end{itemize}
+
+Durante las ejecuciones de las pruebas para observar el valor de los distintos parámetros, el comportamiento del algoritmo o la búsqueda de errores se utilizó la herramienta kprint descrita en \ref{Kprint}. Esta herramienta como se mencionó se utilizó para debuggear las funciones implementadas, permitiendo encontrar los puntos en los cuales ocurrían errores en tiempo de ejecución.\\
+Dado que la memoria del router es muy reducida, al no considerar ésta variable los logs utilizados ocuparon toda la memoria disponible dejando inutilizable el router. Esto fue solucionado asignando un valor pequeño al tamaño máximo del archivo de logs.
+
+\section{Ajustes al algoritmo}
+\label{ajustes_algoritmo}
+Luego de las primeras pruebas realizadas se modificó el algoritmo con el fin de lograr mejorar la estabilidad del mismo:
+\begin{itemize}
+\item Se estableció un límite inferior para las probabilidades equivalente al 1\% del valor máximo de las mismas. Con esto se soluciona el problema de las probabilidades estancadas en 1.
+\item Siguiendo el algoritmo propuesto, las probabilidades son aumentadas cuando se realiza una transición a un estado mayor. Esto generaba que el estado más alto nunca podía aumentar su probabilidad de ingreso. La solución a esto fue modificar el algoritmo para las situaciones en que el estado es el más alto y el porcentaje de pérdidas es menor que el ORI, en lugar de incrementar de estado se incrementará la probabilidad de dicho estado.
+\item Una de las razones por las cuales el algoritmo aumenta las probabilidades de los estados menores al pasar a un estado mayor es tener la posibilidad de regresar rápidamente en caso de que se generen demasiadas pérdidas por el cambio. Lo que realizaba el algoritmo era aumentar las probabilidades de los estados menores del estado actual pero no el actual, lo cual no es consistente con el razonamiento previo, por lo tanto se ajustó para aumentar la probabilidad del estado del que se parte.
+\end{itemize}
+
+\section{Pruebas finales}
+El objetivo principal de estas pruebas fue llevar a cabo el escenario de pruebas de Starvation problem definido en \ref{Starvarion_Escenario}.
+Antes de comenzar con las pruebas centrales de esta sección se realizaron otras auxiliares para verificar el funcionamiento del algoritmo luego de los ajustes realizados, ubicando a la estación en una posicion cercana y otra lejana respecto del router.
+ 
+\subsection{Prueba cercana}
+Esta prueba consistió en tener una estación asociada a un router a una distancia aproximada de 1m. Los resultados obtenidos (ver figura \ref{prueba_cerca}) fueron los esperados, enviando prácticamente siempre con el rate máximo, power mínimo y una tasa de pérdidas pequeña. 
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_prueba_cerca}
+	\caption{Resultados prueba estación cercana al router}
+	\label{prueba_cerca}
+\end{figure}
+
+Con el fin de tener otra medida para comparar resultados mostraremos el throughput instantáneo en cada momento. Este dato lo podemos ver en la figura \ref{thruoghput_cerca}.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{throughput_prueba_cerca}
+	\caption{Throughput: prueba con estación cercana al router}
+	\label{thruoghput_cerca}
+\end{figure}
+
+Como conclusión el algoritmo con una estación cercana funciona correctamente.
+
+\subsection{Prueba lejana}
+Esta prueba consistió en tener una estación asociada a un router a una distancia aproximada de 60m. Los resultados obtenidos no fueron óptimos mas allá que el power y rate parecen estabilizarse. Los aspectos negativos son: el power utilizado era casi el máximo y el rate no llegaba ni a la mitad del valor máximo considerando que prácticamente no había ruido de otros routers. Por otro lado la tasa de pérdidas fue muy elevada ubicandose aproximadamente en 30\%. Los valores obtenidos se pueden observar en la siguiente figura \ref{prueba_lejos}.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_prueba_lejos}
+	\caption{Resultados prueba estación lejana al router}
+	\label{prueba_lejos}
+\end{figure}
+
+Respecto al throughput obtenido se puede observar en la figura \ref{throughput_lejos} que se vio reducido a más de la mitad del obtenido en la prueba con la estación cercana.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{throughput_prueba_lejos}
+	\caption{Información transferida y throughput: prueba con estación lejana al router}
+	\label{throughput_lejos}
+\end{figure}
+
+Los resultados ideales para esta prueba hubieran sido que el rate y power se logren estabilizar un poco más y que la tasa de pérdidas sea menor aunque implique utilizar mayor potencia o menor rate.
+
+\subsection{Prueba lejana con power máximo}
+Dado que los resultados obtenidos en la prueba anterior no fueron muy convincentes y generaron la interrogante de si utilizar un power superior (eventualmente el power máximo) mejoraría la tasa de pérdidas y el rate utilizado, se realizó la misma prueba pero hardcodeando el power en su nivel máximo.
+
+Los resultados obtenidos los podemos observar en la figura \ref{prueba_lejos_max}. Los mismos no fueron buenos, el rate nunca se pudo estabilizar oscilando en un amplio rango de valores. Además se obtuvo una tasa de error superior al 15\% que se considera alta dado que se está utilizando el power máximo.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_prueba_lejos_max}
+	\caption{Resultados prueba estación lejana al router con power máximo}
+	\label{prueba_lejos_max}
+\end{figure}
+
+Como era de esperar el throughput aumentó considerablemente comparado al caso anterior  \ref{throughput_lejos_max}.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{throughput_prueba_lejos_max}
+	\caption{Información transferida y throughput: prueba con estación lejana al router utilizando power máximo}
+	\label{throughput_lejos_max}
+\end{figure}
+
+Como conclusión general de las pruebas con la estación lejos del AP, se genera cierta incertidumbre sobre el correcto funcionamiento del router debido a que se utiliza en ambas pruebas los powers más altos y aún así las tasas de pérdidas son elevadas teniendo en cuenta que la distancia está lejos de ser la máxmima soportada. Estos resultados no sugieren un buen indicio sobre los valores que se obtendrán en las siguientes pruebas.
+
+\subsection{Pruebas del escenario Starvation problem}
+Estas pruebas fueron realizadas en base al escenario definido en \ref{Starvarion_Escenario}. Para ejecutar el caso de prueba se utilizó la herramienta aircrack-ng mencionada en \ref{aircrack}.\\
+En total fueron realizadas tres pruebas bajo este escenario, en dos de ellas la estación que comenzaba primera con la transmisión de información era la lejana y en la otra el caso contrario. Esto fue realizado con el objetivo de observar si afectaba al rendimiento el orden en que se comenzaba a transmitir.\\
+La duración de las pruebas realizadas fue de 7 minutos.
+
+\subsubsection{Prueba 1 y 2}
+La ejecución de estas pruebas se realizó de la siguiente forma:
+\begin{enumerate}
+\item Se encienden ambos routers.
+\item Se comienza con la ejecución del test en la computadora que estaba cerca del router.
+\item Luego que se estabilice (100s aprox.) se comienza con la ejecución de la pc lejana al router.
+\end{enumerate}
+La diferencia de las pruebas es simplemente el rol de las pcs utilizadas, la pc que era la cercana en una prueba, en la siguiente era la lejana y lo mismo con la otra pc utilizada. Esto se realizó para verificar que los resultados obtenidos no eran dependientes de las terminales utilizadas.
+
+Mostraremos solamente los resultados de una prueba debido a que ambas fueron similares.
+
+\subparagraph{Resultados PC cercana}
+Los resultados los podemos observar en las figuras \ref{starvation_1_cerca} y \ref{starvation_throughput_1_cerca}.  
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_starvation_1_cerca}
+	\caption{Resultados caso 1 y 2 prueba starvation problem de la pc cercana al router }
+	\label{starvation_1_cerca}
+\end{figure}
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{starvation_1_cerca_throughput}
+	\caption{Throughput: caso 1 y 2 prueba starvation problem de la pc cercana al router}
+	\label{starvation_throughput_1_cerca}
+\end{figure}
+
+De los resultados se puede ver que el estado del algoritmo fue prácticamente en todo momento el máximo. El segundo aspecto a observar es cómo el throughput se ve disminuida drásticamente en el momento que la segunda pc comienza con la prueba.
+
+\subparagraph{Resultados PC lejana}
+Los resultados los podemos observar en las figuras \ref{starvation_1_lejos} y \ref{starvation_throughput_1_lejos}.  
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_starvation_1_lejos}
+	\caption{Resultados caso 1 y 2 prueba starvation problem de la pc lejana al router }
+	\label{starvation_1_lejos}
+\end{figure}
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{starvation_1_lejos_throughput}
+	\caption{throughput: caso 1 y 2 prueba starvation problem de la pc lejana al router}
+	\label{starvation_throughput_1_lejos}
+\end{figure}
+
+En este caso como era de esperar dados los antecedentes de las pruebas realizadas, los resultados no fueron muy buenos. Las tasas de pérdidas fueron muy altas y aunque el power oscilaba entre los powers más altos, el rate no logró estabilizarse en ningún momento. 
+
+\subsubsection{Prueba 3}
+La ejecución de esta prueba se realizó de la siguiente forma:
+\begin{enumerate}
+\item Se encienden ambos routers.
+\item Se comienza con la ejecución del test en la computadora que estaba lejos del router.
+\item Luego que se estabilice (100s aprox.) se comienza con la ejecución de la pc cercana al router.
+\end{enumerate}
+
+Los resultados obtenidos fueron similares a las casos 1 y 2, la pc cercana tuvo un throughput reducido mientras la otra pc estaba transmitiendo, lograba estabilizar correctamente el estado y tenía una tasa de pérdida muy reducida. Por otro lado la pc lejana continua con un comportamiento irregular, con altos niveles de error y sin poder estabilizar el rate utilizado.
+
+\clearpage
+\textbf{Resultados PC cercana}
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_starvation_2_cerca}
+	\caption{Resultados caso 1 y 2 prueba starvation problem de la pc cercana al router }
+	\label{starvation_2_cerca}
+\end{figure}
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{starvation_2_cerca_throughput}
+	\caption{Throughput: caso 1 y 2 prueba starvation problem de la pc cercana al router}
+	\label{starvation_throughput_2_cerca}
+\end{figure}
+
+\clearpage
+\textbf{Resultados PC lejana}
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{resultado_starvation_2_lejos}
+	\caption{Resultados caso 1 y 2 prueba starvation problem de la pc lejana al router }
+	\label{starvation_2_lejos}
+\end{figure}
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=\columnwidth]{starvation_2_lejos_throughput}
+	\caption{Throughput: caso 1 y 2 prueba starvation problem de la pc lejana al router}
+	\label{starvation_throughput_2_lejos}
+\end{figure} 
+
+
+\subsection{Análisis de resultados}
+En primer lugar se puede concluir que existe un problema presente en todas las pruebas en el router con su estación asociada a gran distancia. Las razones pueden ser que el canal es malo, que el algoritmo tenga problemas para estabilizarse al aumentar la distancia router-estación o algún problema presente en los dispositivos.\\
+Uno de los resultados positivos es que se pudo observar la asimetría presente en dicho escenario, en donde la $pc_lejos$ en todas las pruebas afecta notoriamente a la $pc_cerca$ y en ningún caso ocurre lo contrario.\\
+El resultado esperado que se planteó para este escenario en donde el router con la estación cercana sea totalmente anulada por el otro router no ocurrió por consecuencia del funcionamiento irregular de este otro. Este último no llega a transmitir al medio un volumen de infomación tal que el router cercano no tenga la posibilidad de enviar paquetes en intervalos pequeños de tiempo. 
+\section{Conclusiones y trabajo a futuro}
+En primer lugar, se resalta que el alcance del proyecto se vio afectado por los errores encontrados y la dificultad que implicaba corregirlos. Esto generó que el tiempo disponible para ejecutar las pruebas fuera reducido, quedando pendiente su ejecución formal con varias iteraciones y posterior comparación con el algoritmo Minstrel.\\
+Como aspectos positivos, luego de diferentes correciones, se logró estabilizar el RRPAA tanto a distancias cercanas como lejanas y seguir fielmente el diseño original del algoritmo.\\
+Dado el estado actual del proyecto, aún quedan varias tareas por realizar:
+\begin{itemize}
+\item Analizar posibles ajustes sobre los parámetros $\gamma$ y $\delta$ utilizados para modificar las probabilidades.
+\item Estudiar de forma adecuada cuál es el mejor límite inferior para las probabilidades.
+\item Comparar formalmente el RRPAA con Minstrel.
+\item Ejecutar adecuadamente los tres escesarios definidos.
+\item Extender RRPAA a estánderes WiFi más modernos que 802.11g.
+\end{itemize}
+
+
+
+% BIBLIOGRAFIA CON BIBTEX
+\clearpage \newpage
+\bibliographystyle{plain}
+\bibliography{references}
+
+\end{document}