Estudio y evaluación de los parametros del protocolo de enrutamiento Ad Hoc on Demand Distance Vector (AODV)

Texto completo

(1)1. ESTUDIO Y EVALUACIÓN DE LOS PARAMETROS DEL PROTOCOLO DE ENRUTAMIENTO AD HOC ON DEMAND DISTANCE VECTOR (AODV). Proyecto de grado Presentado por. Sael Andrés Bayona Páez COD. 200112632. Dirigida por: Ph.D. Néstor Peña Traslaviña. Universidad de los Andes Departamento de Ingeniería Eléctrica y Electrónica Programa de Pregrado Bogotá Junio de 2005.

(2) 2. NOTA DE ACEPTACIÓN ________________________ ________________________ ________________________. ________________________ Asesor de Tesis. ________________________ Jurado 1. ________________________ Jurado 2.

(3) 3. Agradecimientos. A los profesores Néstor Peña y Marco Alzate por la paciencia en la asesoría prestada en la construcción, validación y análisis de este estudio. A mis padres por los esfuerzos que han realizado para que pueda terminar mis estudios profesionales. A todas las personas que de alguno u otro modo tomaron parte en la consolidación de este trabajo..

(4) 4. Tabla de Contenido. 1. INTRODUCCION. 8. 2. FUNCIONAMIENTO DEL PROTOCOLO ON DEMAND DISTANCE VECTOR (AODV). 9 2.1 Route Request (RREQ) 2.2 Route Reply (RREP) 2.3 Route Error (RERR) 2.4 Funcionamiento del protocolo por medio de los paquetes de Enrutamiento 2.4.1 Manteniendo números de secuencia 2.4.2 Mantenimiento de las tablas de enrutamiento 2.4.3 Generando un Route Request (RREQ) 2.4.4 Controlando el proceso de Inundación de un RREQ 2.4.5 Procesando Y Retransmitiendo un RREQ cuando llega a un nodo 2.4.6 Generando un Gratuitous RREP 2.4.7 Generando un Gratuitous RREP 2.4.8 Retransmitiendo un RREP 2.4.9 Mensajes Hello 3. PARAMETROS QUE AFECTAN EL DESEMPEÑO DE LA RED 3.1 Net_Diameter 3.2 Node_Traversal_Time 3.3 RREQ_Retries 3.4 Active_Route_Timeout 3.5 Hello_Interval 3.6 My_Route_Timeout. 25. 4. MARCO DE REFERENCIA SIMULACIONES 4.1 Descripción del escenario de simulación 4.1.1 Velocidad de los nodos 4.1.2 Trafico 4.1.3 Bursty Traffic 4.1.4 Reference Traffic 4.1.5 Numero de Nodos Fuente 4.1.6 Descripción del proceso de simulación. 34. 5. SIMULACIONES Y ANALISIS DE RESULTADOS. 37.

(5) 5. 5.1. Escenario de 50 y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro Active Route Timeout 5.1.1 Observaciones 5.2 Escenario de 50 nodos y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro Hello Interval 5.2.1 Observaciones 5.3 Escenario de 50 nodos y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro My Route Timeout 5.3.1 Observaciones 5.4 Escenario de 50 nodos y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro Net Diameter 5.4.1 Observaciones 5.5 Escenario de 50 nodos y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro Node Traversal Time 5.5.1 Observaciones 5.6 Escenario de 50 nodos y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro RREQ Retries 5.6.1 Observaciones 6. CONCLUSIONES Y RECOMENDACIONES 7. REFERENCIAS.. 53 54.

(6) 6. LISTA DE FIGURAS. Figura 1. Figura 2. Figura 3. Figura 4. Figura 5. Figura 6. Figura 7. Figura 8. Figura 9. Figura 10. Figura 11. Figura 12. Figura 13. Figura 14. Figura 15. Figura 16. Figura 17. Figura 18. Figura 19. Figura 20. Figura 21. Figura 22. Figura 23. Figura 24. Figura 25. Figura 26. Figura 27. Figura 28. Figura 29. Figura 30. Figura 31. Figura 32. Figura 33. Figura 34. Figura 35. Figura 36. Figura 37. Figura 38. Figura 39. Figura 40. Figura 41. Figura 42. Figura 43.. Facción de Paquetes para 100 nodos, parámetro Active_Route_Timeout ..................... 37 Carga Normalizada 100 nodos, parámetro Active_Route_Timeout .............................. 38 Caudal 100 nodos, parámetro Active_Route_Timeout ............................................... 39 Carga Normalizada para Active_Route_Timeout, ráfagas de 10s, 100 Nodos .............. 39 Fracción de Paquetes para Active_Route_Timeout, ráfagas de 10s, 100 Nodos............ 40 Caudal para Active_Route_Timeout, ráfagas de 10s, 100 Nodo…………………………41 Carga Normalizada para Hello_Interval, ráfagas de 10s, 50 nodos........................... 42 Fracción de Paquetes para Hello_Interval, ráfagas de 10s, 50 nodos ........................ 43 Caudal de datos para Hello_Interval, ráfagas de 10s, 50 nodos................................ 44 Carga Normalizada para My_Route_Timeout, ráfagas de 10s, 50 nodos .................... 45 Fracción de paquetes para My_Route_Timeout, ráfagas de 10s y 50 nodos. ............... 46 Caudal de Datos para My_Route_Timeout, ráfagas de 10s, 50 nodos ........................ 46 Carga Normalizada para Net_Diameter, ráfagas de 10s, 50 nodos ............................ 47 Fracción de Paquetes para Net_Diameter, ráfagas de 10s, 50 nodos .......................... 48 Caudal de datos para Net_Diameter, ráfagas de 10s, 50 nodos. ................................. 48 Carga Normalizada para Node_Traversal_Time, ráfagas de 10s, 50 nodos.................. 49 Fracción de Paquetes para Node_Traversal_Time, ráfagas de 10s, 50 nodos ............... 49 Caudal de datos para Node_Traversal_Time, ráfagas de 10s, 50 nodos...................... 50 Carga Normalizada para RREQ_Retries, ráfagas de 10s, 50 nodos ........................... 51 Fracción de paquetes para RREQ_Retries, ráfagas de 10s, 50 nodos.......................... 51 Caudal de Datos para RREQ_Retries, ráfagas de 10s, 50 nodos. .............................. 52 Carga Normalizada para Active_Route_Timeout, ráfagas de 50s, 100 Nodos. ............ 55 Carga Normalizada para Active_Route_Timeout, ráfagas de 10s, 50 Nodos. ............... 55 Carga Normalizada para Active_Route_Timeout, ráfagas de 50s, 50 Nodos. ............... 56 Fracción de Paquetes para Active_Route_Timeout, ráfagas de 50s, 100 Nodos............ 57 Fracción de Paquetes para Active_Route_Timeout, ráfagas de 10s, 50 Nodos. ............ 57 Fracción de Paquetes para Active_Route_Timeout, ráfagas de 50s, 50 Nodos. ............ 58 Caudal para Active_Route_Timeout, ráfagas de 50s, 100 Nodos. .............................. 59 Caudal para Active_Route_Timeout, ráfagas de 10s, 50 Nodos. ................................ 59 Caudal para Active_Route_Timeout, ráfagas de 50s, 50 Nodos . ............................... 60 Carga Normalizada para Hello_Interval, ráfagas de 50s, 50 nodos........................... 61 Carga Normalizada para Hello_Interval, ráfagas de 10s, 100 nodos ......................... 61 Carga Normalizada para Hello_Interval, ráfagas de 50s, 100 nodos ......................... 62 Fracción de Paquetes para Hello_Interval, ráfagas de 50s, 50 nodos ........................ 63 Fracción de Paquetes para Hello_Interval, ráfagas de 10s, 100 nodos ...................... 63 Fracción de Paquetes para Hello_Interval, ráfagas de 50s, 100 nodos ...................... 64 Caudal de datos para Hello_Interval, ráfagas de 50s, 50 nodos............................... 65 Caudal de datos para Hello_Interval, ráfagas de 10s, 100 nodos ............................. 65 Caudal de datos para Hello_Interval, ráfagas de 50s, 100 nodos ............................. 66 Carga Normalizada para My_Route_Timeout ráfagas de 50s y 50 nodos................... 67 Carga Normalizada para My_Route_Timeout, ráfagas de 10s, 100 nodos.................. 67 Carga Normalizada para Hello_Interval, ráfagas de 50s, 100 nodos ......................... 68 Fracción de paquetes para My_Route_Timeout, ráfagas de 50s y 50 nodos ................ 69.

(7) 7. Figura 44. Figura 45. Figura 46. Figura 47. Figura 48. Figura 49. Figura 50. Figura 51. Figura 52. Figura 53. Figura 54. Figura 55. Figura 56. Figura 57. Figura 58. Figura 59. Figura 60. Figura 61. Figura 62. Figura 63. Figura 64. Figura 65. Figura 66. Figura 67. Figura 68. Figura 69. Figura 70. Figura 71. Figura 72. Figura 73. Figura 74. Figura 75.. Fracción de paquetes para My_Route_Timeout, ráfagas de 10s y 100 nodos .............. 69 Fracción de paquetes para My_Route_Timeout, ráfagas de 50s y 100 nodos.............. 70 Caudal de Datos para My_Route_Timeout, ráfagas de 50s, 50 nodos ........................ 71 Caudal de datos para My_Route_Timeout, ráfagas de 10s y 100 nodos .................... 71 Caudal de datos para My_Route_Timeout, ráfagas de 50s, 100 nodos........................ 72 Carga Normalizada para Net_Diameter, ráfagas de 50s, 50 nodos ............................ 73 Carga Normalizada para Net_Diameter, ráfagas de 10s, 100 nodos ........................... 73 Carga Normalizada para Net_Diameter, ráfagas de 50s, 100 nodos .......................... 74 Fracción de Paquetes para Net_Diameter, ráfagas de 50s, 50 nodos ......................... 75 Fracción de Paquetes para Net_Diameter, ráfagas de 10s, 100 nodos........................ 75 Fracción de Paquetes para Net_Diameter, ráfagas de 50s, 100 nodos......................... 76 Caudal de datos para Net_Diameter, ráfagas de 50s, 50 nodos .................................. 77 Caudal de datos para Net_Diameter, ráfagas de 10s, 100 nodos ................................ 77 Caudal de datos para Net_Diameter, ráfagas de 50s, 100 nodos ............................... 78 Carga Normalizada para Node_Traversal_Time, ráfagas de 50s, 50 nodos.................. 79 Carga Normalizada para Node_Traversal_Time, ráfagas de 10s, 100 nodos ................ 79 Carga Normalizada para Node_Traversal_Time, ráfagas de 50s, 100 nodos ................ 80 Fracción de Paquetes para Node_Traversal_Time, ráfagas de 50s, 50 nodos ............... 81 Fracción de Paquetes para Node_Traversal_Time, ráfagas de 10s, 100 nodos ............. 81 Fracción de Paquetes para Node_Traversal_Time, ráfagas de 50s, 100 nodos ............ 82 Caudal de datos para Node_Traversal_Time, ráfagas de 50s, 50 nodos...................... 83 Caudal de datos para Node_Traversal_Time, ráfagas de 10s, 100 nodos .................... 83 Caudal de datos para Node_Traversal_Time, ráfagas de 50s, 100 nodos .................... 84 Carga Normalizada para RREQ_Retries, ráfagas de 50s, 50 nodos ........................... 85 Carga Normalizada para RREQ_Retries, ráfagas de 10s, 100 nodos.......................... 85 Carga Normalizada para RREQ_Retries, ráfagas de 50s, 100 nodos.......................... 86 Fracción de paquetes para RREQ_Retries, ráfagas de 50s, 50 nodos.......................... 87 Fracción de paquetes para RREQ_Retries, ráfagas de 10s, 100 nodos ....................... 87 Fracción de paquetes para RREQ_Retries, ráfagas de 50s, 100 nodos ........................ 88 Caudal de Datos para RREQ_Retries, ráfagas de 50s, 50 nodos ............................... 89 Caudal de Datos para RREQ_Retries, ráfagas de 10s, 100 nodos ............................. 89 Caudal de Datos para RREQ _Retries, ráfagas de 50s, 100 nodos............................. 90.

(8) 8. 1. INTRODUCCION En el mundo actual de las telecomunicaciones, en donde se busca un buen desempeño de las redes en cualquier lugar y a bajo costo se han creado nuevas aplicaciones y sistemas inalámbricos con el objetivo de poder usar estos en situaciones en donde otros sistemas podrían fallar, como catástrofes ambientales, en escenarios donde los usuarios se estén desplazando, en zonas remotas y hostiles o en donde se necesite establecer redes por demanda, esto es redes de tiempo transitorio. Entre los resultados mas importantes a este tipo de requerimientos se encuentran las redes Ad Hoc que al no necesitar de ningún tipo de infraestructura como enrutadores comerciales o puntos de acceso o cableado para poder ensamblarse son muy útiles, Ya que estas redes solo necesitan de servidores para poder conectarse entre si. En redes Ad Hoc dos dispositivos se pueden conectar entre si aun si no se encuentran dentro de su alcance de radio, gracias a la presencia de nodos intermedios que actuaran como routers y reenviaran los paquetes de datos de la fuente al destino. Las redes Ad hoc se caracterizan por tener topologías dinámicas donde los nodos se mueven arbitrariamente dentro de un área definida, este tipo redes puede cumplir con estos requerimientos gracias a muchos factores que las caracterizan, como son los protocolos de enrutamiento los cuales son de gran utilidad a la hora de establecer las rutas por donde se enviaran los paquetes de datos. En este trabajo investigaremos sobre un protocolo de enrutamiento que funciona bajo demanda, esto quiere decir que solo establecerá rutas cuando sea necesario, después de un tiempo determinado las rutas dejaran de estar activas, este protocolo se llama Ad Hoc On Demand Distance Vector (AODV). En este tipo de redes es importante realizar una caracterización adecuada de este protocolo con métricas de desempeño apoyadas por simulación, ya que una mala selección o parametrización del protocolo de enrutamiento puede llevar a resultados no consecuentes con el desempeño de la redes Ad Hoc [1]. Para poder realizar esto se debe tener en cuenta los parámetros que afectan el desempeño de la red ya que estas redes son muy sensibles a las variaciones de los mismos. En el capitulo 3 presentaremos una explicación del protocolo AODV, allí se mostrara el funcionamiento del mismo y la forma en que se utilizan los parámetros para que este proceso se pueda realizar. En el capitulo 4 analizaremos de manera detallada los efectos en el desempeño del protocolo al variar los parámetros del mismo. En el capitulo 5 se presenta el escenario de simulación y por último en el capitulo 6 se presentan y analizan los resultados..

(9) 9. 2.. FUNCIONAMIENTO DEL PROTOCOLO ON DEMAND DISTANCE VECTOR (AODV). AODV es un protocolo de enrutamiento reactivo salto a salto, es decir es un protocolo de enrutamamiento que establece rutas solo cuando las necesita, por esta razón este protocolo no mantiene rutas permanentes, en lugar de esto se crean rutas nuevas cada vez que un nodo necesita transmitir datos a un destino, estas rutas son mantenidas por el tiempo que el mismo protocolo establece para enviar los datos. Las rutas nuevas son establecidas por medio de un proceso llamado descubrimiento de ruta (Route Discovery), en el cual se envían y reciben una serie de paquetes llamados paquetes de enrutamiento que sirven para establecer los caminos por donde se enviaran los datos [2], estos paquetes son: 2.1 Route Request (RREQ) Este es el paquete que es enviado por nodo fuente para establecer la nueva ruta. En Qualnet ®, este paquete es transmitido por medio de un mecanismo llamado Expanding Ring Search, el cual es un mecanismo que controla la inundación de este paquete para que no sea transmitido a cada nodo de la red, esto se realiza para controlar la carga de enrutamiento sobre la red ya que esta tiene un impacto sobre el desempeño de la misma. Este paquete tiene los siguientes campos: 1. Tipo: Este es un número por medio del cual el protocolo clasifica a los paquetes de enrutamiento, para este paquete el tipo=1. 2. J y R: Son banderas usadas en multicast. 3. G: Bandera gratuita para RREP, indica si un paquete de enrutamiento RREP puede ser transmitido por una sola ruta al nodo especificado en la dirección IP. 4. Hop Count: El número de saltos que lleva el paquete RREQ desde el nodo fuente hasta el nodo que actualmente procesa el paquete. 5. Flooding ID: Numero de secuencia que sirve para identificar a este paquete..

(10) 10. 6. Destination IP Adress: La dirección IP del destino para la cual una ruta es deseada.. 7. Destination Sequence Number: El ultimo número de secuencia recibido en el pasado por la fuente para cualquier ruta en dirección al destino. 8. Source IP Adress: La dirección IP del nodo que origino el RREQ. 9. Source Sequence Number: El número de secuencia actual que esta siendo usado por la fuente, para acceder la ruta del RREQ en su tabla de enrutamiento. En la tabla 1 se observa el tamaño de cada campo en el paquete RREQ:. Tabla 1: Paquete RREQ 2.2 Route Reply (RREP) Este es el paquete de enrutamiento utilizado por un nodo destino o un nodo intermedio con una ruta hacia el destino para contestar la petición que la fuente hizo por medio del paquete RREQ, este paquete es trasmitido por el mismo camino que llego el RREQ pero en dirección contraria. Este paquete tiene los siguientes campos: 1. Tipo: Este es un número por medio del cual el protocolo clasifica a los paquetes de enrutamiento, para este paquete el tipo=2. 2. R: Es una bandera usada en multicast. 3. A: Es usada cuando se requiere de un reconocimiento por parte del destino. 4. Hop Count: El número de saltos que lleva el paquete RREQ desde el nodo fuente hasta el nodo que actualmente procesa el paquete. 5. Flooding ID: Número de secuencia que sirve para identificar a este paquete..

(11) 11. 6. Destination IP Adress: La dirección IP del destino para la cual una ruta es deseada. 7. Destination Sequence Number: El ultimo número de secuencia recibido en el pasado por la fuente para cualquier ruta en dirección al destino. 8. Source IP Adress: La dirección IP del nodo que origino el RREQ. 9. Source Sequence Number: El número de secuencia actual que esta siendo usado por la fuente, para acceder la ruta del RREQ en su tabla de enrutamiento. 10. Lifetime: El tiempo para el cual el nodo que recibe el RREP considera la ruta como valida. En la tabla 2 se observa la estructura de este paquete:. Tabla 2: Paquete RREP 2.3 Route Error (RERR) Este paquete es usado cuando un enlace por el cual se envían datos se daña, esto es, se corta el enlace debido a que algún nodo se salio del rango de cobertura o debido a que el tiempo de vida de una ruta ha expirado. 1. Tipo: Este es un número por medio del cual el protocolo clasifica a los paquetes de enrutamiento, para este paquete el tipo=3 2. N: Usada cuando un nodo esta realizando una reparación de un enlace, para que los nodos no borren la ruta en reparación. 3. Destcount: El número de destinos inalcanzables al dañarse la ruta debe ser almenos 1. 4. Unreachable Destination IP Adress: La dirección IP del destino la cual llega a ser inalcanzable debido al rompimiento del enlace..

(12) 12. 5. Unreachable Destination Sequence Number: El último número de secuencia conocido, incrementado por uno. En la tabla 3 se observa la estructura para el paquete de enrutamiento RERR:. Tabla 3: Paquete RERR 2.4 Funcionamiento del protocolo por medio de los paquetes de enrutamiento AODV es un protocolo de enrutamiento que funciona bajo demanda, esto significa que el protocolo establece rutas solo cuando estas son necesarias y las mantiene por unos tiempos definidos por los parámetros del mismo. Este protocolo utiliza los paquetes RREQ, RREP y RERR, para mantener las rutas frescas o para crear las mismas. 2.4.1 Manteniendo números de secuencia En AODV se usa un concepto llamado número de secuencia, el cual es usado para evitar que un nodo haga el procesamiento de un paquete varias veces, además es usado para saber si una ruta es fresca o para actualizar la misma. El número de secuencia es como el tiempo de cada nodo, cada vez que un nodo realiza algún evento este actualiza su número de secuencia para estar al día con los demás nodos de la red. Los casos en los que un nodo actualiza su número de secuencia son los siguientes: 1. Antes de originar un RREQ, un nodo incrementa su número de secuencia para que los demás nodos sepan que es un nuevo RREQ, ya que existe la posibilidad de que el nodo haya enviado un RREQ antes, el número de secuencia y la dirección IP de la fuente son necesarios para que el paquete de enrutamiento RREQ sea identificado por los demás nodos de la red. 2. En el caso de que un nodo vaya a responder con un RREP este debe actualizar su número de secuencia al mayor entre el número de secuencia que trae el RREQ y su propio número de secuencia. 3. Para mantener la información actualizada en las tablas de enrutamiento.

(13) 13. de cada nodo se usan los números de secuencia del destino, esta información es actualizada cada vez que el nodo recibe nueva información del destino por medio de los paquetes de enrutamiento que están relacionados con el destino y los cuales tienen un número de secuencia mayor que el actual. 2.4.2 Mantenimiento de las tablas de enrutamiento Como se explico anteriormente cada nodo posee una tab la de enrutamiento en donde guarda información de los destinos a los que un nodo ha necesitado enviar paquetes de datos, además los nodos también tienen una lista de precursores que se encuentra en las tablas de enrutamiento en la cual se almacena la información de los nodos vecinos para los que se ha generado o retransmitido un mensaje RREP, esta lista se utiliza para informar a los nodos destino cuando un enlace se daña. Para crear una entrada en la tabla de enrutamiento se toma información de los paquetes de enrutamiento y se observa si ya se tiene información acerca del nodo que lo envió, si no se tiene ninguna información sobre este nodo, entonces se procede a recolectar la información del paquete de control como el número de secuencia o en el evento en que no se pueda saber que número de secuencia este es inicializado a cero. El tiempo de vida de la nueva ruta es determinada del paquete de control en el caso en que sea un RREP de lo contrario es inicializado en el valor del parámetro My_Route_Timeout. Cada vez que una ruta es utilizada su tiempo de vida (lifetime), es actualizado a el valor del parámetro Active_Route_Timeout, esto se hace para que la ruta en el nodo no expire si se encuentra en uso. Por ultimo el campo Hop Count es inicializado en uno. 2.4.3 Generando un Route Request (RREQ) Un nodo inunda un RREQ cada vez que necesite enviar datos a un destino y no tiene la ruta necesaria para alcanzar el mismo, esto sucede por dos razones, la primera es que la ruta hacia el destino es desconocida. La segunda es si a una ruta establecida anteriormente tiene dañado uno de sus enlaces y esto es notificado al nodo fuente. Cuando el nodo inunda el RREQ utiliza el último número de secuencia conocido para este destino, este número es obtenido directamente de la tabla de enrutamiento del nodo mismo, en caso de no encontrar ninguna entrada para este destino, el número de secuencia en el campo del RREQ será.

(14) 14. inicializado en cero. Otro campo es destination sequence numb er el cual se obtiene del número de secuencia del nodo que envía el paquete de enrutamiento, el campo de identificación de inundación (Flooding ID), se inicializa con el ultimo Flooding ID que halla usado el nodo incrementado en uno, por ultimo el contador de saltos (hop count), es inicializado en cero. Después de establecer los valores de cada campo del paquete de enrutamiento el nodo procede a guardar en un buffer la dirección IP de la fuente que envió el paquete (source IP adress) y el identificador de inundación (Flooding ID) del paquete de enrutamiento RREQ y procede a transmitir el paquete de enrutamiento. Esta información es almacenada en el buffer hasta que un tiempo de espera, que inicia en Flood_Record_Time (ms), es terminado. Almacenar esta información evita que el nodo vuelva a procesar este paquete. Después que se transmite el RREQ un nodo espera por un RREP durante un tiempo definido como sigue: Net _ Traversal _ Time(ms ) = 2 * TTL * Net _ Diameter (1) Si este tiempo se cumple el nodo fuente enviará otro RREQ hasta alcanzar un máximo de RREQ_RETRIES, el cual es definido en los parámetros de simulación. Los parámetros NODE_TRAVERSAL_TIME y NET_DIAMETER también son parámetros de simulación y son definidos por el analista. Cada vez que el nodo fuente retransmita un nuevo RREQ este debe incrementar en uno el campo Flooding ID. Cuando a un nodo intermedio llega un paquete de enrutamiento RREQ y este tiene una ruta para el destino que se encuentra en el mismo, el nodo responde con un paquete de enrutamiento RREP, sin embargo para establecer la ruta entre nodo fuente y nodo destino, el nodo intermedio que contesta la petición de ruta debe también notificar al nodo destino acerca de la petición de ruta. Para hacer esto el nodo fuente que envía el paquete RREQ debe activar la bandera ‘G’, en el campo del paquete RREQ, con esto se garantiza que se establezca una ruta bidireccional. En este proyecto de grado estamos utilizando comunicación bidireccional es decir que la ruta que el nodo fuente tiene hacia el destino debe ser la misma que ruta que el destino tiene hacia el nodo fuente, tanto los paquetes de petición de ruta RREQ que le envía el nodo fuente al destino, como los paquetes de respuesta de petición de ruta que envía ya sea un nodo.

(15) 15. intermedio o un nodo destino deben utilizar el mismo camino. Cuando un nodo necesita establecer una ruta por medio de los paquetes de enrutamiento, este almacena los paquetes de datos en un b uffer, si no se puede establecer una ruta y se ha alcanzado Max_RREQ_Retries, entonces el nodo fuente procede a borrar los paquetes de datos y se envía una señal de destino inalcanzable a la aplicación. En el diagrama de flujo 1, se observa el proceso de inundación. 2.4.4 Controlando el proceso de Inundación de un RREQ AODV utiliza un método llamado Expanding Ring Search, el cual sirve para controlar el proceso de inundación de un paquete. Este proceso Inunda el paquete RREQ por medio de anillos que controlan el numero de saltos, es decir, cuando el nodo fuente inunda el primer paquete RREQ lo hace solo para dos saltos (TTL=2), con esta condición el paquete es transmitido a los nodos vecinos, cuando el paquete llega a estos nodos, si ninguno de ellos tiene una ruta al destino no se realizará ningún procedimiento, ya que estos nodos no pueden transmitir el paquete RREQ ya que el paquete RREQ en su cuenta de saltos tiene el valor 2 y por ende no permite que sea retransmitido. Al no obtener ninguna respuesta (RREP), el tiempo de espera que se menciono anteriormente se cumple y el nodo fuente procede a enviar otro RREQ pero esta vez aumenta el parámetro que controla la inundación con una constante TTL_Increment el cual por defecto es 2, esto es (TTL=TTL+TTL_Increment). Este procedimiento se usa hasta alcanzar un TTL = TTL_Thresold, el cual por defecto es 7. Una vez alcanzado este umbral el TTL es inicializado a Net_Diameter, esto se usa para inundar el paquete por toda la red, es como si no se utilizara el método Expanding Ring Search. En el diagrama de 2, se observa el proceso..

(16) 16. Diagrama de Fluj o.1: Proceso de inundación de un RREQ.

(17) 17. Diagrama de Fluj o.2: Proceso de Control para la diseminación de un RREQ.

(18) 18. 2.4.5 Procesando y Retransmitiendo un RREQ cuando llega a un nodo Para procesar RREQ, el nodo primero revisa que la cuenta de saltos no haya excedido el diámetro de la red, si este no es el caso el nodo procede a revisar si ha recibido algún RREQ con la misma dirección y Flooding ID, al no cumplirse ninguno de los casos anteriores el nodo procede a revisar si la dirección destino que trae el RREQ es la misma dirección del nodo, si no son iguales entonces el nodo es un nodo intermedio y por ende procede a revisar si existe alguna ruta al destino en su tabla de enrutamiento, si no existe crea una ruta, si existe tratará de actualizar los datos de la ruta con la información que trae el RREQ solo si el número de secuencia de éste paquete es mayor que el que se tiene para el destino en la tabla de enrutamiento. Si el nodo no tiene ninguna ruta hacia el destino retransmitirá el paquete de enrutamiento, con su número de secuencia actualizado de acuerdo al número mayor entre el RREQ y el número del nodo, la cuenta de saltos también será incrementada en uno, se creará una ruta de regreso con un tiempo de vida igual a: (3*Node_Traversal_Time*Net_Diameter/2)–(rreqPkt >hopCount*Node_Traversal_Time).. (2) Donde Node_Traversal, es el tiempo en que un nodo se demora en procesar un paquete, Net_Dameter es el diámetro de la red y rreqPkt>hopCount es el numero de saltos entre el nodo fuente y el nodo destino. Si el nodo cuenta con una ruta hacia el destino entonces retransmitirá un RREP en dirección al destino, si la bandera “G” esta activada entonces trasmitirá un RREP gratuito al nodo destino. En el diagrama de flujo 3 se muestra el procedimiento realizado. 2.4.6 Generando Route Replies Como se mencionó anteriormente, cuando un nodo recibe una petición de ruta, éste revisa si existe alguna ruta para ese destino en su tabla de enrutamiento, de lo contrario se toma el nodo como el destino y se procede a generar una respuesta a esta petición por medio de un paquete de enrutamiento RREP. Si es un nodo intermedio, es decir, no es el nodo destino pero tiene una ruta para este, entonces se copian la dirección fuente y destino del paquete RREQ, para los campos de dirección fuente y destino del RREP, además se copia el.

(19) 19. último número de secuencia que este nodo tiene para el destino en el campo de Destination sequence numb er, del RREP. Después de esto el nodo procede a actualizar en su tabla de enrutamiento la entrada de la dirección fuente del RREQ, el nodo actualiza las rutas de regreso por medio de la dirección IP de la fuente que viene en el RREQ..

(20) 20.

(21) 21. Diagrama de Fluj o.3: Método de procesamiento de un RREQ. Luego el nodo inicializa la cuenta de saltos al número de saltos que existen desde este hacia el destino, el tiempo de vida que se coloca en el campo del RREP, es calculado por medio de la siguiente ecuación: lifetime = rtToDest- > lifetime - getSimTime(node)) (3) Esta ecuación es la resta del tiempo de vida de la tabla de enrutamiento y el tiempo actual de simulación. El tiempo de vida de la ruta hacia el destino es actualizado al valor Active_Route_Timeout. Si es el nodo destino entonces, el numero de secuencia es inicializado al máximo entre el paquete RREQ y el nodo, la cuenta de saltos es inicializada en cero, el tiempo de vida del RREP es inicializado a Active_Route_Timeout. En el diagrama de flujo 4 se resume el procedimiento seguido por el código implementado en Qualnet ®. 2.4.7 Generando un RREP Gratuito En AODV siempre que se genera un RREQ, se activa una bandera ‘G’, la cual hace que un nodo intermedio que responde a una petición de ruta un nodo fuente envié un RREP, al destino para que este pueda aprender la ruta en dirección hacia la fuente, el RREP gratuito, es el mismo paquete de.

(22) 22. enrutamiento RREP, lo único que cambia son los valores de sus campos.. Diagrama de Fluj o.4: Proceso de Transmisión de un RREP. En el RREP gratuito, la cuenta de saltos se inicializa con el valor del número de saltos que tiene el RREQ, el campo Destination es inicializado con la dirección de la fuente del RREQ, y el campo Source es inicializado con la dirección de destino que tenia el RREQ, el tiempo de vida se inicializa con el valor de la diferencia entre el tiempo de vida hacia el destino de la ruta del nodo que va a.

(23) 23. enviar el paquete y el tiempo actual de simulación. 2.4.8 Retransmitiendo un RREP Cuando un nodo recibe un RREP, primero revisa si tiene una ruta para la fuente, si el nodo no hace parte de la ruta que se esta creando entre la fuente y el destino el paquete será descartado. A continuación el nodo procede a crear el nuevo paquete RREP que será transmitido. Los números de secuencia son los mismos que vienen en el RREP, la cuenta de saltos del RREP es incrementada en uno y asignada al RREP que esta siendo creado. El tiempo de vida del nuevo RREP se inicializa con el tiempo de vida recibido en el antiguo RREP. Por otro lado, el tiempo de vida de la ruta por donde esta siendo transmitido el RREP es actualizada a Active_Route_Timeout. La lista de precursores hacia el destino es actualizada agregando la dirección hacia donde será transmitido el RREP. En el diagrama de flujo 5 se observa de manera mas detallada el funcionamiento del proceso. 2.4.9 Mensajes Hello Los mensajes hello son un tipo de RREP que envía el nodo para mantener una conexión con sus vecinos. Este paquete se transmite con una cuenta de salto igual a cero, es decir que este paquete solo se transmite una vez. Cuando la opción de mensaje hello esta activa, los paquetes hello son enviados cada Allowed_Hello_Loss*Hello_Interval , este intervalo de tiempo es mas pequeño que el Active_Route_Timeout, para este caso. El objetivo de estos paquetes es la actualización del tiempo de vida de las rutas que se han creado con los nodos vecinos. Para efectos de este proyecto esta opción será deshabilitada, para evaluar mejor el impacto de los parámetros en el protocolo..

(24) 24. Diagrama de Fluj o.5: Proceso de Retransmisión de un RREP. El diagrama de flujo 6 es un complemento para el procesamiento de RREP..

(25) 25.

(26) 26. Diagrama de Fluj o.6: Método de procesamiento de un RREP.

(27) 27. 3. PARÁMETROS QUE AFECTAN EL DESEMPEÑO DE LA RED El código del protocolo AOVD implementado en Qualnet esta basado en [1], en este documento se explica detalladamente el protocolo, además se enumeran los parámetros que pueden afectar el desempeño de la red al variar sus valores, según este documento los parámetros que pueden afectar el desempeño de la red son los siguientes: 3.1 Net_Diameter Especifica el máximo número posible de saltos entre dos nodos en la red. El valor por defecto es de 35 saltos . 3.1.1 Eventos en los que se usa el parámetro Net_Diameter 1. Cuando se está transmitiendo un paquete de enrutamiento RREQ, existe un parámetro que esta variando continuamente para controlar su transmisión. Este parámetro es TTL, el cual sirve para establecer el máximo número de veces que se puede retransmitir este paquete para intentar establecer una ruta, el valor por defecto de este parámetro es 7. Cuando este valor es alcanzado se asigna al parámetro TTL, el valor de Net_Diameter, esto indica que el método Expanding Ring Search falló y se procederá a inundar el paquete por toda la red, para encontrar el destino. 2. Cuando se trasmite un RREQ para establecer una ruta hacia el destino, este paquete eventualmente llega a un nodo intermedio o el destino mismo, si la cuenta de saltos que lleva el paquete es mayor que el diámetro de la red, entonces el nodo que recibe este paquete procederá a eliminar el paquete debido a que la ruta que este trae no es optima. 3. El parámetro Net_Diameter, se encuentra en la siguiente formula: Net _ Traversal _ Time =. 2 * Node _ Traversal _ Time * Net _ Diameter (4) 2. Esta fórmula a su vez está en incluida en: Flood_Record_Time = 2 * Net_Traversal_Time (5).

(28) 28. 4. Net_Diameter se usa para inicializar los tiempos de vida de las rutas de regreso en los nodos. revRtLifetime = Rev_Route_Life – (rreqPkt->hopCount*Node_Traversal_Time). (6). Este parámetro es el tiempo usado para mantener un paquete de RREQ en Seen tab le, que es la tabla que revisa un nodo para evitar procesar paquetes de petición de ruta RREQ mas de una vez. Net_Traversal_Time y por ende Net_Diameter son usados en: BlackList_TimeOut = RREQ_Retries * Net_Traversal_Time (7) Esta lista es usada para mantener un registro de todos los nodos sobre los cuales se ha intentado trasmitir un RREP sin obtener una transmisión exitosa. Además se mantienen los registros de estos nodos por un tiempo definido para que los paquetes RREQ, provenientes de nodos que se encuentren en esta lista sean descartados. Los nodos a los que no se pudo enviar el paquete de RREQ permanecen en la tabla BlackList por un cierto tiempo y luego son eliminados de la misma para que el nodo vuelva a aceptar paquetes provenientes de estos nodos, el tiempo que los nodos permanecen en la tab la BlackList es BlackList_TimeOut, el cual envuelve al parámetro Net_Traversal_Time que por defecto esta compuesto del Net_diameter, como se puede observar en las ecuaciones (4) y (5). En conclusión al variar el parámetro Net_Diameter se ven afectados todos los aspectos mencionados anteriormente, se observa que para valores pequeños de Net_Diameter, si el método de Expanding Ring Search falla y se procede a inundar el paquete RREQ por la red por medio de la asignación del parámetro TTL al valor del parámetro Net_Diameter no dará buenos resultados puesto que este parámetro puede ser incluso mas pequeño que el TTL_Threshold. Por otro lado al tener un valor pequeño del parámetro Net_Diameter entre el rango de [3 nodos a 5 nodos], se descartaran muchos paquetes de enrutamiento RREQ, debido a que la mayoría de estos paquetes traerán un número de saltos mayor a este parámetro, esto generara una sobrecarga de paquetes de enrutamiento que afectará directamente el desempeño de la red..

(29) 29. 3.1.2 Caso 1 Al tener el parámetro Net_Diameter en un valor pequeño dentro del rango [2 nodos-5 nodos], los nodos mantendrán menos tiempo la tabla Seen tab le y BlackList, lo cual se vera reflejado en que el nodo puede procesar de nuevo un paquete RREQ que ya había procesado o puede recibir un RREQ, de una ruta que presenta problemas en la transmisión de los paquetes RREP.. 3.1.3 Caso 2 Al tener un valor muy grande dentro del rango [2 nodos-5 nodos], del parámetro Net_Diameter un nodo podría aceptar rutas que tienen muchos saltos, lo cual incrementa la probabilidad de que la ruta se dañe y por ende se pierdan muchos de los paquetes de datos que se envíen, este aspecto afectaría el desempeño de la red. Por otro lado, al tener un valor grande de este parámetro, en caso de fallar el método de Expanding Ring Search, se podrá inundar el paquete de petición de ruta por el método antiguo de AODV, con lo cual se podrá establecer una ruta hacia el destino, además se asegurará de que el nodo no procese mas de una vez un paquete de petición de ruta RREQ y se evitará procesar paquetes de enrutamiento que posean rutas con problemas de transmisión. 3.1.4 Objetivos El objetivo es balancear los problemas anteriormente mencionados por medio de un valor que presente estos problemas en su mínima expresión, para poder alcanzar el máximo desempeño de la red. 3.2. Node_Traversal_Time. Es un tiempo estimado de la duración “viaje” de un salto a través de un nodo el valor por defecto es 40ms. 3.2.1 Eventos en los que se usa el parámetro Node_Traversal_Time 1. Se usa para inicializar el tiempo de espera de un RREP después de que el nodo fuente inunda con un RREQ:.

(30) 30. Timer=2 * TTL *Node_Traversal_Time .. (8). 2. Se usa para mantener las rutas de regreso en cada nodo: RevRtLifetime = Rev_Route_Life – (rreqPkt->hopCount*Node_Traversal_Time).. (9). 3. Se usa para calcular el Net_Traversal_Time Net_ Traversal_ Time=. 2* Node_ Traversal_ Time* Net_ Diameter (10) 2. Se observa que el parámetro Node_Traversal_Time, afecta el tiempo de espera de un RREP, también se observa que afecta el tiempo de vida de una ruta de regreso, ósea la ruta por donde viajara el RREP, en respuesta al RREQ. 3.2.3 Caso 1 Si hacemos que el valor de este parámetro Node_traversal_Time, sea pequeño dentro del rango [50ms-500ms], el resultado será que los nodos esperarán muy poco tiempo después de enviar un RREQ, para esperar una respuesta, con lo cual el nodo fuente procederá a iniciar un nuevo proceso de descubrimiento de ruta que generará una congestión por parte de los paquetes de enrutamiento sobre la red, lo cual trae implicaciones en el desempeño de la red al incrementarse la competencia por el acceso al ancho de banda para transmitir los datos. Por otro lado las rutas de regreso de mantendrán menor tiempo lo que incrementara la probabilidad de que se pierda la transmisión de los RREP que van dirigidos hacia el destino. Esto tendrá un efecto dramático en el desempeño de la red debido a que no se podrán establecer rutas para transmitir los datos, 3.2.4 Caso 2 Por otro lado al tener valores muy grandes de este parámetro dentro del rango [2.6s-3.2s], el tiempo de espera para una respuesta de un paquete RREP que se encuentra regido por este parámetro aumentará y en el caso de que la transmisión del RREP, halla tenido algún problema y debido a que esto no se.

(31) 31. le informa al nodo que envió el RREP, se perderá mucho tiempo esperando el regreso del RREP para comenzar a transmitir datos. Por otro lado, las rutas de regreso también se mantendrán mas tiempo lo que causara que se envíen RREP por rutas que ya no están disponibles, los nodos que hallan tenido problemas con la transmisión de RREP estarán deshabilitados mucho tiempo lo cual hace que l nodo fuente escoja rutas que no sean las mas optimas para transmitir los datos debido a la disminución de nodos vecinos para establecer rutas.. 3.3. RREQ_Retries. Especifica el número de veces que AODV repite el Expanding Ring Search para un destino si no se recibe un RREP como respuesta en el tiempo especificado. 3.3.1 Eventos en los que se usa el parámetro RREQ_Retries Este parámetro es usado en la lista BlackList: BlackList_TimeOut = RREQ_Retries * Net_Traversal_Time (11) 1. Cuando se usa el método Expanding Ring Search, el cual aparece por defecto en el código de AODV implementado en Qualnet, éste inicialmente inunda el paquete de enrutamiento RREQ, controlado por medio del parámetro TTL, si al inundar la primera vez el nodo fuente no recibe ninguna respuesta de petición de ruta entonces procede a incrementar el valor del TTL, esto se hace para que cada vez se pueda inundar más lejos el paquete de enrutamiento, si el TTL alcanza el umbral máximo entonces el paquete de enrutamiento será inundado al valor del diámetro de la red, esto es al valor del parámetro Net_Diameter. Con esto se busca que el paquete sea inundado por toda la red para que pueda alcanzar al destino o a un nodo, sin embargo este paquete se puede inundar sobre toda la red un numero limitado de veces, el parámetro que acota las veces en que se puede inundar un paquete es el RREQ_Retries, el cual tiene un valor por defecto igual a 2..

(32) 32. 3.3.2 Caso 1 Cuando el número de intentos para inundar un paquete está dentro del rango de 14 intentos a 17 intentos, entonces aumentará el tiempo que se puede mantener un registro de un nodo en la lista BlackList, con lo cual se afectará la conectividad del nodo con los demás nodos de la red. Por otro lado si el TTL_THRESHOLD es pequeño dentro del rango [2 nodos a 5 nodos], entonces el nodo se inundará siempre por toda la red y mecanismo de Expanding Ring Search no cumplirá su función ya que el número de intentos es insuficiente comparado con el mínimo que se requiere para este método el cual se en encuentra en 7 nodos, además se presentará congestión de paquetes de enrutamiento sobre la red, lo cual impactará directamente el desempeño de la red. Además en caso de que la red tenga una densidad de nodos muy pequeña colocar el parámetro en un valor grande dentro del rango [15 nodos a 17 nodos], puede ayudar a que la red funcione mejor, ya que para este tipo de escenarios el mecanismo de Expanding Ring Search no es efectivo, en estos casos es mejor inundar por toda la red. 3.3.3 Caso 2 Si hacemos que este parámetro tenga un valor pequeño dentro del rango de 1 nodos hasta 3 nodos, entonces en condiciones como las mencionadas anteriormente, el nodo inundará el paquete de enrutamiento RREQ, hasta alcanzar el máximo de RREQ_Retries, debido a que éste valor es pequeño el nodo fuente recibirá una notificación que le informa que el nodo destino es inalcanzable, una vez recibida esta notificación el nodo fuente procederá a eliminar los paquetes que fueron almacenados en el buffer en espera de una ruta para ser transmitidos. 3.3.4 Objetivos El objetivo es buscar un valor para este parámetro en donde se alcance el máximo desempeño de la red..

(33) 33. 3.4 Active_Route_Timeout Este parámetro especifica el tiempo de vida de las rutas que tiene cada nodo cuando se esta transmitiendo un paquete de datos 3.4.1 Eventos en los que se utiliza al parámetro Active_Route_Timeout Se utiliza para actualizar las rutas que tiene cada nodo. Cada vez que un nodo transmite un paquete de datos actualiza la ruta al valor de Active_Route_Timeout. 1. Se utiliza para actualizar las rutas de regreso por donde pasan los RREP. 3.4.2. Caso 1. Si tenemos valores grandes para este parámetro del rango de 100s a 450s, entonces los nodos usaran rutas que dejaron de estar disponibles por causa del movimiento de los mismos, por ende se enviaran paquetes por rutas que ya no están disponibles, estos paquetes de datos se perderán. Al durar tanto los tiempos de vida de las rutas, el número de paquetes de enrutamiento de la red disminuye. Al enviarse los paquetes de datos por rutas que ya no están disponibles se afectaran el desempeño de la red, aunque la carga de paquetes de enrutamiento disminuya. 3.4.3 Caso 2 Si tenemos valores pequeños para este parámetro del rango de 50ms a 1s, cuando se estén transmitiendo los datos las rutas se desactivaran lo que conducirá a la perdida de los paquetes de datos, esto generara nuevos paquetes de enrutamiento a causa de informar acerca de los enlaces que se han dañado y de establecer nuevas rutas, la expiración de las rutas también en un problema que afecta el desempeño de la red, debido a la perdida de paquetes de datos y a la competencia generada por la sobre carga de los paquetes de enrutamiento. 3.4.4 Objetivos Se deben establecer valores óptimos para este parámetro en donde el desempeño sea el máximo posible, el valor de este parámetro no puede ser ni.

(34) 34. muy grande ni muy pequeño, para que no expiren rutas que están disponibles aun y para que no se envíen datos por rutas que aunque no han expirado ya no se encuentran disponibles debido a que los nodos han salido del rango de cobertura o a que los enlaces de han dañado.. 3.5 Hello_Interval Se utiliza para calcular el tiempo de vida de un paquete de enrutamiento.. 3.5.1 Eventos en los que se usa el parámetro Hello_Interval 1. Se usa para calcular el tiempo en que se debe borrar una ruta después de que a expirado el tiempo Delete_Period, el cual es un tiempo mayor que Active_Route_Timeout, cuando este tiempo expira el nodo procede a borrar la ruta de su tabla de enrutamiento la ruta. Delete_Period se calcula de la siguiente manera: Delete _ Period = Route _ Delete _ Const × Max(Active _ Route, Hello_ Loss × Hello _ Interval) (12) 2. Este parámetro se utiliza para calcular el tiempo de vida del paquete de enrutamiento RREP, cuando se usan paquetes hello para la conectividad. 3. Este parámetro se utiliza para mantener los tiempos de vida de las rutas en el momento en que se están estableciendo las mismas, es decir, cada vez que un nodo reciba un paquete de enrutamiento como un RREQ, o un RREP, este revisará en su tabla de enrutamiento para saber si tiene una ruta hacia el nodo que le envió el paquete de enrutamiento, de no ser este el caso, se procederá a crear una ruta para este nodo, el tiempo de vida de esta ruta se puede establecer por medio del paquete de enrutamiento que se recibió por ejemplo un RREP, ya que este paquete tiene el campo de tiempo de vida, de no ser esta la situación el nodo inicializará la ruta a:. GetSimTime (node) + ALLOWED_HELLO_LOSS *HELLO_INTERVAL. (13).

(35) 35. En donde getsimtime es una function para calcular el tiempo actual de una simulación, luego cuando se comience a mandar paquetes de datos las rutas actualizaran con otro parámetro este parámetro es Active_Route_Timeout.. 3.5.2 Caso 1 Cuando tenemos valores muy grandes de este parámetro dentro del rango de [100s 400s], las rutas se van a demorar mucho tiempo para ser eliminadas debido a que este parámetro aumenta el tiempo establecido para borrar estas rutas, esto creará una sobrecarga en las tablas de enrutamiento, con lo cual no se podrán crear mas rutas, con lo cual se afectará el desempeño de la red. Por otro lado al durar tanto tiempo las rutas, no se inicializarán nuevos procesos de descubrimiento de rutas lo que disminuirá notablemente la carga de enrutamiento, con el efecto en que se estarán usando rutas que ya no sirven. 3.5.3 Caso 2 Cuando tenemos valores muy pequeños de este parámetro dentro del rango de [50ms 1s], las rutas cumplirán su tiempo muy rápido y serán eliminadas, esto causará que se eleve la carga de enrutamiento y por ende aumente la competitividad por los recursos de la red con los paquetes de datos que se encuentren en la misma en ese momento. 3.5.4 Objetivo Se debe encontrar un valor optimo para este parámetro donde el desempeño sea el máximo posible, el valor de este parámetro no puede ser ni muy grande ni muy pequeño, para que no se eliminen rutas que están disponibles aún y para que no se activen rutas que deberían haberse borrado ya que no se encuentran disponibles debido porque los nodos han salido del rango de cobertura o a que los enlaces de han dañado.. 3.6. My_Route_Timeout. Los nodos utilizan este parámetro para estimar el tiempo de vida en que una ruta puede estar disponible..

(36) 36. 3.6.1 Eventos en los que se usa el parámetro 1. Se utiliza para calcular el tiempo de vida de un paquete de enrutamiento RREP, es decir, el nodo que esta respondiendo la petición de ruta, calcula el tiempo en que estará disponible la misma y lo asigna al campo de tiempo de vida del paquete de enrutamiento RREP, cuando lo crea.. 3.6.2 Caso 1 Cuando tenemos valores muy grandes de este parámetro dentro del rango de [100s 400s], los nodos colocarán estos valores en los tiempos de vida de los paquetes de enrutamiento RREP, con lo cual se podrá creará sobrecarga de paquetes de enrutamiento de RREP que puede tener un impacto débil en la operación de la red..

(37) 37. 4. MARCO DE REFERENCIA SIMULACIONES Se consideran dos escenarios en una misma área de 1400m x 1400m, los cuales son terrenos planos en donde los nodos no tienen ningún obstáculo como edificios o montañas, cada escenario cuenta con 50 nodos ó 100 nodos dispuestos aleatoreamente. Los paquetes de datos 512 bytes son transmitidos cada 0.25 s sobre la capa MAC 802.11 a 2Mb/s y con un radio de transmisión de 300m. Se utiliza el modelo Random Waypoint [3] y [4], el cual es un modelo de movimiento aleatorio, donde los nodos escogen un destino en cualquier dirección y se mueven con una velocidad hasta alcanzar su destino, luego tienen un tiempo de pausa (pause time), que es definido por el modelo con un valor por defecto de 30s y repiten el proceso. 4.1 Velocidad de los nodos Para el modelo de movilidad existen tres opciones para la velocidad de los nodos, los nodos se mueven con una velocidad que puede estar dentro de los rangos: [1m/s – 10m/s], [1m/s – 20m/s], y un caso estático. 4.2 Tráfico Se utiliza un modelo de tráfico de Qualnet ® llamado Packet Trace, este es un modelo en el cual se debe crear un archivo de trafico en donde se especifiquen el tamaño de los paquetes y el tiempo en que serán generados, cada nodo de la red, tendrá este modelo con dos tipos de tráfico. 4.3 Bursty Traffic Este es un tráfico compuesto de ráfagas de paquetes, en el cual los paquetes son enviados en ráfagas de 50s luego de las cuales hay un tiempo de pausa en donde no se envía ningún paquete por parte de las fuentes. Este tiempo de pausa tiene una distribución exponencial con media a 10s. 4.4 Referente Traffic.

(38) 38. Este es un tráfico compuesto de ráfagas de paquetes, en el cual los paquetes son enviados en ráfagas de 10s luego de las cuales hay un tiempo de pausa en donde no se envía ningún paquete de datos por parte de los nodos fuente. Este tiempo de pausa tiene una distribución exponencial con media10s.. 4.5 Descripción de la Simulación Debido a que nuestro propósito es investigar los efectos de los parámetros del protocolo AODV, dejaremos los parámetros externos a éste tal como el radio de transmisión, la velocidad de trasmisión en la capa MAC 802.11 y el área de simulación, en los valores fijados anteriormente, ya que estos parámetros pueden afectar también el desempeño de la red a modificarlos, sin embargo un estudio más completo de la parametrización de las redes Ad Hoc podría incluir la variación de estos parámetros. Las métricas que utilizaremos para medir el impacto del desempeño del protocolo son las usadas en [5], en donde se compara el desempeño del protocolo AODV y el desempeño del protocolo DSR. Estas métricas son: 4.5.1 Carga normalizada El número de paquetes de enrutamiento transmitidos por paquete de datos entregado al destino. C arg a _ Normalizada =. Numero _ total _ de _ paquetes _ de _ enrutamiento (14) Numero _ total _ de _ paquetes _ de _ datos _ recibidos. 4.5.2 Fracción de paquetes Es la razón entre el número de paquetes de datos entregados al destino y el número de paquetes de datos enviados por la fuente. Fraccion _ de _ Paquetes =. Numero_ total _ de _ paquetes _ de _ Datos _ recibidos (15) Numero _ total _ de _ paquetes_ de _ datos _ enviados. 4.5.3 Caudal El número de bits/s recibido por los destinos. Por otro lado se utilizará el protocolo de enrutamiento AODV, que se encuentra implementado en Qualnet ®..

(39) 39. Caudal:. 0.8* Bytes_ Recibidos (16) Tiempo_ del _ primer_ paquete_ datos− Tiempo_ del_ ultimo_ paquete_ datos. En donde la constante 0.8 es una constante implementada en el código de Qualnet ®. Los parámetros del protocolo se irán variando de la siguiente forma: Escenario. velocida d. Tipo de tráfico. Parámetro. Valores del Parámetro para la Simulación. 50, 100 Nodos. 0 m/s, 10m/s, 20m/s. Ráfagas de 10s, 50s. Net_Diameter. 50, 100 Nodos. 1 m/s, 10m/s, 20m/s. Ráfagas de 10s, 50s. Node Traverlsal Time. 3s, 7s, 11s, 17s, 21s, 31s, 37s, 43s, 49s, 65s, 75s, 85s 95s. 0.05s, 0.1s, 0.2s, 0.4s, 0.8s, 1s, 1.6s, 1.8s, 2s, 2.6s, 3.2s. 50, 100 Nodos. 2 m/s, 10m/s, 20m/s 3 m/s, 10m/s, 20m/s. Ráfagas de 10s, 50s. RREQ Retries. 1, 2, 3, 5, 7, 9, 10, 13, 15, 17. Ráfagas de 10s, 50s. Active_route_Timeout My_route_Timeout Hello_Interval. 0.05s, 0.1s, 0.2s, 0.4s, 0.8s, 1.6s, 3.2s, 6.4s, 12.8s, 25.6s, 51.2s, 102.4s, 204.8s, 409.6s.. 50, 100 Nodos. TABLA. 1: Descripción de los Escenarios de Simulación. Como se observa en la tabla 1, cada parámetro se simula con los tres casos para la velocidad, utilizando el modelo de movimiento Ramdon Waypoint. Los parámetros que están relacionados con los tiempos de vida se varían en los mismos intervalos de tiempo para poder observar el efecto de estas variaciones en cada parámetro y poder concluir cual de estos parámetros tiene un mayor efecto en el desempeño del protocolo..

(40) 40. 5. SIMULACIONES Y ANALISIS DE RESULTADOS Se utilizó la fórmula (17) consultada en [6], para saber cuántas simulaciones se deben hacer, basándose en un error del 5%, el cual se considera un error aceptable para obtener unos resultados satisfactorios, debido a que con este porcentaje se realizan en promedio 30 simulaciones, con 30 semillas diferentes, estas semillas cambian la posición de los nodos lo cual le da una aleatoriedad a la recolección de los datos. error = X * S / k. (17). Donde la variable X es la desviación estándar del vector de muestras recolectadas para un valor del parámetro; S es la constante necesaria para obtener los resultados dentro de un intervalo de confianza del 95% (S=1.96) y k es el número de simulaciones que se deben realizar. Se utiliza la herramienta Matlab®, para graficar los datos obtenidos con cada uno de los parámetros mencionados anteriormente, en esta herramienta se usa la función boxplot, la cual es capaz de graficar los datos mostrando la dispersión de los mismos por medio de caja que se puede observar en la figura 1, figura 2 y figura 3, en estas figuras son obtenidas graficando sobre la mediana de los datos en donde existe un cuello de botella en las cajas, las cuales representan la dispersión de los datos, este cuello de botella representa el 95% de los datos de la simulación. Debido a que son muchos parámetros solo mostramos los resultados para el parametro de Active_Route_TimeOut, simulado bajo el escenario de 50 nodos con un tráfico de ráfagas de 10s y una velocidad de 10m/s, los resultados son mostrados para los tres tipos de métricas que se utilizaron en este trabajo.. . Fig. 1: Facción de Paquetes para 100 nodos, parámetro Active_Route_Timeout.

(41) 41. En la figura 1 se observa que la métrica de la fracción de paquetes tiene una dispersión relativamente pequeña excepto en los tiempos desde 100s hasta 400s, donde se observa una gran dispersión de los datos obtenidos. Por otro lado el 95% de los datos en la figura 1, se encuentran en los cuellos de botella de las cajas de la grafica, en donde se puede observar que para la mayoría de valores del parámetro los valores el 95% de los datos se encuentran muy cercanos a la media. En la figura 2, observamos los resultados para la carga normalizada de este parámetro, en esta grafica el 95% de los datos se encuentra dentro de los cuellos de botella. En la grafica de carga normalizada 100 nodos, parámetro Active_Route_Timeout (figura 2), observamos que la carga normalizada para este parámetro en los valores entre [6.4s-409s], disminuye notablemente, además su dispersión es muy pequeña lo cual indica que se intenta estabilizar esta métrica para estos valores.. Fig. 2: Carga Normalizada 100 nodos, parámetro Active_Route_Timeout. Por otro lado para los valores entre [0.05s-6s], se observa una dispersión un poco mayor, en este caso se toman muchos mas datos hasta obtener el porcentaje de error en los datos deseado, el cual se encuentra en 5%..

(42) 42. En la figura 3, se observa el caudal obtenido en el proceso de variación de este parámetro:. Fig. 3: Caudal 100 nodos, parámetro Active_Route_Timeout. En la grafica de caudal 100 nodos, parámetro Active_Route_Timeout (figura 3), se observa que el caudal comienza a disminuir a partir de los valores [6.4s102.4s], debido a que el porcentaje de paquetes de datos enviados y recibidos disminuye para estos valores tal como se observa en la figura 1. 5.1 Escenario de 50 y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro Active_Route_Timeout. Figura. 4: Carga Normalizada para Active_Route_Timeout, ráfagas de 10s, 100 Nodos.

(43) 43. En la figura 4 se observa la grafica para la carga normalizada para Active_Route_Timeout, tomada al variar el parámetro entre [50 ms- 409.6 s], en esta figura se observa que para el caso estático se tiene una menor carga normalizada. Esto indica que el protocolo tiene un mejor desempeño, debido a que esta enviando menos paquetes de enrutamiento por paquete de dato enviado, ya que las rutas establecidas nunca se van a perder debido al estado estático de los nodos. Por otro lado para el caso de velocidad de 20 m/s se observa, que tiene un porcentaje mas alto de carga normalizada debido a que en este caso los nodos se mueven mas rápidamente, lo cual causa que las rutas establecidas se pierdan en un menor tiempo, en este caso los nodos fuente necesitan enviar mas paquetes de enrutamiento por paquete de datos enviado. De la figura 4 se observa que para los rangos entre [1.6 s - 409.6 s], el porcentaje de carga normalizada disminuye debido a que para estos valores el tiempo de vida de las rutas aumenta, lo cual hace que los nodos conserven por mas tiempo las rutas así estas estén fuera de servicio, es decir así ya hayan ocurrido problemas en los enlaces de las rutas como se podrá observar en la figura 5 que se presenta a continuación.. Figura. 5: Fracción de Paquetes para Active_Route_Timeout, ráfagas de 10s, 100 Nodos.

(44) 44. En la figura 5, observamos que para el caso estático se presenta el mejor porcentaje de paquetes de datos entregados entre los tres casos de velocidad al variar el parámetro entre el rango 50 ms- 409.6 s], esto ratifica lo mencionado en el análisis de la carga normalizada de la figura 4. El porcentaje de la fracción de paquetes para el caso estático indica que el desempeño del protocolo mejora entre mas baja sea la velocidad de los nodos dentro del área especificada en el escenario. Se observa que el caso de velocidad de 20m/s es el que presenta un menor desempeño como se observa en los valores que están en los rangos [12.8 s – 409.6 s], donde se presenta el menor porcentaje de paquetes recibidos tal como se indica en la figura 4 (la línea de color rojo), esto se presenta debido a que los paquetes de datos se envían por rutas que presentan enlaces dañados, ya que los tiempos de vida de las rutas se actualizan al valor de este parámetro cuando se están transmitiendo los paquetes de datos. Este efecto también se ve reflejado en el caudal de paquetes de datos recibidos por los nodos destino ya que para el mismo rango de valores del parámetro se presenta una disminución en esta métrica tal como se indica en la figura 6. Por otro lado se puede observar en la figura 6 que el mejor nivel de caudal para los tres casos de velocidad es el caso estático.. Figura. 6: Caudal para Active_Route_Timeout, ráfagas de 10s, 100 Nodo.

(45) 45. 5.2 Escenario de 50 nodos y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro Hello_Interval En estas simulaciones utilizamos este parámetro solo para actualizar los tiempos de vida de las rutas que usan los paquetes de enrutamiento. Como se observa en la figura 7, la carga normalizada disminuye notablemente para los tres casos de velocidad en el rango [3.2 s – 409.6 s], esto se debe a que este parámetro se utiliza para actualizar los tiempos de vida de los enlaces que van creando los paquetes de enrutamiento, es decir los nodos van actualizando los enlaces en sus tablas de enrutamiento pero aun no se están transmitiendo los paquetes de datos, solo existen paquetes de enrutamiento que están creando las enlaces de la respectiva ruta. La carga normalizada disminuye debido a que al aumentar el valor del parámetro aumenta el valor de los tiempos de vida de los enlaces y por ende pocos enlaces expiran, lo cual hace que se generen menos procesos de descubrimiento de ruta, los cuales son los que generan congestión de paquetes de enrutamiento en la red.. Figura. 7: Carga Normalizada para Hello_Interval, ráfagas de 10s, 50 nodos. Por otro lado para los valores dentro del rango [50 ms – 3.2 s], los tiempos de vida de los enlaces expiran muy rápidamente y esto genera sobrecarga de paquetes de enrutamiento en la red, por tal razón observamos el nivel desde 8% de paquetes de enrutamiento en estos rangos..

(46) 46. Figura. 8: Fracción de Paquetes para Hello_Interval, ráfagas de 10s, 50 nodos. En la figura 8, se observa la fracción de paquetes para el parámetro Hello_Interval. En esta grafica se observa que el 70% de los paquetes de datos que son enviados por las fuentes, logran alcanzar exitosamente el destino, esto se mantiene en un intervalo que va desde [50ms a 6.4s], para valores del parámetro mas grandes que este intervalo, en numero de paquetes comienza a disminuir para todas las velocidades hasta que se estabiliza en un intervalo promedio de [30% a 40%]. La fracción de paquetes comienza a disminuir debido a que muchas de las rutas que ya no están disponibles no son eliminadas, ya que al aumentar el valor del parámetro afecta el tiempo que se programa para borrar una ruta, este tiempo es Delete_Period. Hello_Interval se usa para calcular el tiempo mencionado anteriormente, al no eliminarse estas rutas se alcanza el limite de rutas permitidos por cada tabla de enrutamiento, con lo cual se tendrá problemas para crear nuevas rutas. Por otro lado habrán muchas rutas creadas por los paquetes de enrutamiento que no son las mas optimas y por esta razón no fueron escogidas por el nodo destino, sin embargo al sufrir daños las rutas mas optimas el nodo intentará realizar el proceso de descubrimiento de ruta para lo cual obtendrá las respuestas de los nodos vecinos que tienen las rutas que no son optimas. Esto causará que el desempeño de la red disminuya con lo cual la fracción de paquetes disminuirá..

(47) 47. En la figura 9, se observa el caudal de datos para este parámetro el cual muestra el efecto que tiene el parámetro al aumentar el valor, ya que se observa que el caudal disminuye a medida que el valor del parámetro aumenta. Por otro lado en el valor de 204.6s, se observa un pico el cual no indica que el caudal esta comenzando a aumentar ya que esta grafica no es continua y presenta picos en algunos puntos y seguramente se observara una tendencia a disminuir en los puntos subsecuentes. Al realizar las variaciones de los escenarios explicados anteriormente se observan resultados similares a los obtenidos en este escenario, esto se puede observar en los anexos 4, 5 y 6, los cuales se encuentran al final de este documento. La fracción de paquetes para los escenarios de 50 nodos con ráfagas de 10s y 50s, y el escenario de 100 nodos con ráfagas de 50s, que se pueden observar en el anexo 5, muestran un comportamiento similar para esta métrica. El caudal para los demas escenarios como se puede observar en el anexo 6, muestra un comportamiento similar al explicado anteriormente.. Figura. 9: Caudal de datos para Hello_Interval, ráfagas de 10s, 50 nodos.

(48) 48. 5.3 Escenario de 50 nodos y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro My_Route_Timeout Se observa en la figura 10, que la carga normalizada en promedio permanece constante con algunas variaciones en el valor de 104s, que vuelven a estabilizarse en 400s. Esto se debe a que este parámetro solo se usa para inicializar el tiempo de vida de un paquete de enrutamiento RREP.. Figura. 10: Carga Normalizada para My_Route_Timeout, ráfagas de 10s, 50 nodos. Para redes pequeñas como son las de 50 nodos este parámetro no tiene un impacto significativo, sin embargo para redes de mas de 100 nodos se observa en las figuras de los escenarios de 100 nodos que se encuentran en el anexo 13, en donde se observa que al aumentar el valor del parámetro, la congestión de paquetes de enrutamiento que existe en la red disminuye debido a que las rutas que se están estableciendo caducan con menos periodicidad..

(49) 49. Figura. 11: Fracción de paquetes para My_Route_Timeout, ráfagas de 10s y 50 nodos. En la figura 11, se observa que la fracción de paquetes para este parámetro permanece constante a medida que el parámetro aumenta, esto es debido a que éste parámetro se utiliza para actualizar los tiempos de vida de los enlaces cuando se esta creando la ruta, la métrica de fracción de paquetes se mide cuando se están enviando paquetes de datos, por lo cual esta métrica no sirve para medir el impacto de la variación de este parámetro. Las observaciones anteriores también se pueden observar en los escenarios que se encuentran en el anexo 8 (fracción de paquetes de datos para el parámetro My_route_timeout), en donde se encuentran los escenarios de 100 nodos para los dos tipos de tráfico.. Figura. 12: Caudal de Datos para My_Route_Timeout, ráfagas de 10s, 50 nodos.

(50) 50. En la figura 12, se observa que el caudal disminuye a medida que los valores para el parámetro My_Route_Timeout aumentan. Esto se debe a la utilización de rutas que ya no están disponibles como se explico anteriormente. 5.4 Escenario de 50 nodos y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro Net_Diameter En la figura 13, se observa la métrica de carga normalizada de paquetes para el parámetro Net_Diameter, en esta figura podemos ver que la carga normalizada disminuye notablemente al aumentar el valor del parámetro, esto es debido a que este parámetro se utiliza como umbral para determinar si una ruta es optima, es decir, cuando un nodo recibe un paquete de enrutamiento RREP, que contenga información de una ruta, este revisa si la cuenta de saltos de la ruta que trae el paquete de enrutamiento es mayor al valor que se encuentre especificado para el parámetro Net_Diameter, si esto sucede el nodo procede a eliminar el paquete. Al especificar valores pequeños para este parámetro todas las rutas que se intenten crear serán eliminadas, lo cual causará una congestión en la red paquetes de enrutamiento debido a que los nodos fuente realizarán muchos procesos de descubrimiento de ruta.. Figura. 13: Carga Normalizada para Net_Diameter, ráfagas de 10s, 50 nodos. En la figura 14, se observa la métrica de fracción de paquetes para este parámetro, en donde se muestra que para los tres escenarios de velocidad la.

(51) 51. variación de los valores del parámetro Net_Diameter, no afecta significativamente el desempeño de la red. Esto se debe a que esta métrica mide el desempeño de la red cuando ya se han creado, en cambio el parámetro afecta el desempeño cuando se están creando las rutas. En los anexos 10, 11 y 12, se encuentran los resultados para los demás escenarios explicados anteriormente donde se observan resultados similares a los explicados para el escenario que tratamos actualmente.. Figura. 14: Fracción de Paquetes para Net_Diameter, ráfagas de 10s, 50 nodos. En la figura 15, se muestra el caudal para este parámetro, esta métrica tampoco nos entrega información clara acerca de la forma en que afecta la variación de este parámetro al desempeño del protocolo por la razón explicada anteriormente..

(52) 52. Figura. 15: Caudal de datos para Net_Diameter, ráfagas de 10s, 50 nodos. 5.5 Escenario de 50 nodos y 100 nodos, con un tráfico compuesto por ráfagas de datos de 10s y 50s, parámetro Node_Traversal_Time. Figura. 16: Carga Normalizada para Node_Traversal_Time, ráfagas de 10s, 50 nodos. En la figura 16, observamos la métrica de carga normalizada para el parámetro Node_Traversal_Time, a medida que aumenta el valor del parámetro la carga de enrutamiento disminuye debido a que el tiempo de espera que se activa cuando un nodo fuente transmite un paquete de enrutamiento RREQ aumenta. Al aumentar este tiempo de espera, muy pocos paquetes de enrutamiento son enviados debido a que el tiempo de espera del RREP aumenta, esto causa problemas en la conectividad debido a que los nodos no actualizan las rutas efectivamente..

(53) 53. Figura. 17: Fracción de Paquetes para Node_Traversal_Time, ráfagas de 10s, 50 nodos. En la figura 17, la fracción de paquetes muestra una disminución en el desempeño del protocolo, esto se debe al aumento en el tiempo de espera ya que los nodos fuente no envían paquetes de datos, ni realizan nuevos procesos de descubrimiento de ruta por tal razón al realizar el procedimiento para calcular la fracción de paquetes se va a evidenciar una disminución en esta métrica debido a que muchos nodos no estarán enviando paquetes de datos, sin embargo existirán los paquetes de enrutamiento en la red de enlaces que no se lograron establecer. En la figura 18, se observa un aumento en el caudal de paquetes de datos entregados a los destinos, esto es debido a la disminución en la congestión de los paquetes de enrutamiento, como se explicaba en la figura 16, ya que al disminuir el numero de paquetes de enrutamiento en la red, la competencia por los recursos de la misma también disminuye, lo cual favorece la transmisión de los paquetes de datos de los nodos que tienen enlaces establecidos..