Embed Size (px)
Citation preview
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
TITULACIÓN DE INGENIERO EN SISTEMAS
INFORMÁTICOS Y COMPUTACIÓN
Implementación de un protocolo de enrutamientojerárquico proactivo en NS-2.
Trabajo de fin de titulación.
Autores
Criollo Cabrera, Julio Wladdimir
Ruilova Rojas, María Esther
Director
Torres Tandazo, Rommel Vicente. Dr.
Loja – Ecuador
2013
II
CERTIFICACIÓN
Dr.
Rommel Vicente Torres Tandazo,
DIRECTOR DEL TRABAJO DE FIN DE TITULACIÓN
CERTIFICA:
Que el presente trabajo, denominado: “Implementación de un protocolo de
enrutamiento jerárquico proactivo en Network Simulator 2”, realizado por los
profesionales en formación: Julio Wladdimir Criollo Cabrera y María Esther
Ruilova Rojas; cumple con los requisitos establecidos en las normas generales
para la Graduación en la Universidad Técnica Particular de Loja, tanto en el
aspecto de forma como de contenido, por lo cual me permito autorizar su
presentación para los fines pertinentes.
Loja, Mayo de 2013.
________________________
III
CESIÓN DE DERECHOS
Nosotros: Julio Wladdimir Criollo Cabrera y María Esther Ruilova Rojas
declaramos ser autores del presente trabajo y eximimos expresamente a la
Universidad Técnica Particular de Loja y a sus representantes legales de
posibles reclamos o acciones legales.
Adicionalmente, declaramos conocer y aceptar la disposición del Art. 67 del
Estatuto Orgánico de la Universidad Técnica Particular de Loja que en su parte
pertinente textualmente dice: “Forman parte del patrimonio de la Universidad la
propiedad intelectual, trabajos científicos o técnicos y tesis de grado que se
realicen a través, o con el apoyo financiero académico o institucional
(operativo) de la Universidad”.
________________________________
Autor: Julio Wladdimir Criollo Cabrera
Cédula: 110402049-8
________________________________
Autora: María Esther Ruilova Rojas
Cédula: 070419990-0
IV
DEDICATORIA
Con infinito amor dedico el presente trabajo a mi mami, Esperanza Rojas
Bustamante, pilar fundamental de mi existencia, gracias a su sacrificio y apoyo
incondicional estoy donde estoy. A mi esposo Paul y mi hijo Francisco por su
apoyo, comprensión y amor.
María Esther
Con mucho cariño Agradezco a Dios, A la Virgen María y al Divino Niño
quienes por la fe que tengo en ellos me han ayudado a encontrar la fortaleza
para seguir siempre adelante. Dedico este trabajo a mi madre querida Olga y a
mi hermano mayor Pepe quienes son mis ejemplos y me han empujado a
seguir siempre adelante sin importar lo que la vida nos ponga adelante,
también agradezco a mis hermanos y hermana quienes son parte importante
en mi vida.
Julio Wladdimir
V
AGRADECIMIENTO
Queremos agradecer a todos los docentes de la Universidad Técnica Particular
de Loja de quienes hemos aprendido mucho durante todos estos años de
estudio, en especial al Dr. Rommel Torres por su acertada dirección en la
presente. A nuestros compañeros y amigos de la Universidad por su apoyo y
comprensión y por todos los momentos maravillosos que hemos compartido a
lo largo de este recorrido.
A nuestras familias, nuestras madres quienes han sido el pilar fundamental
durante nuestra vida entera, nuestros hermanos y hermanas quienes siempre
nos han apoyado y alentado para que sigamos adelante.
En general queremos agradecer a todas las personas que directa e
indirectamente han contribuido en nuestro hacer profesional.
Agradecemos finalmente a Dios por permitirnos cumplir un objetivo más en
nuestra vida.
VI
CONTENIDO
CERTIFICACIÓN............................................................................................................ II
CESIÓN DE DERECHOS .............................................................................................. III
DEDICATORIA.............................................................................................................. IV
AGRADECIMIENTO....................................................................................................... V
CONTENIDO ................................................................................................................. VI
ÍNDICE DE FIGURAS..................................................................................................... X
ÍNDICE DE TABLAS .................................................................................................... XII
ÍNDICE DE ANEXOS.................................................................................................... XII
RESUMEN.................................................................................................................... 13
CAPÍTULO 1
INTRODUCCIÓN .......................................................................................................... 14
1.1 Definición del Problema..................................................................................... 15
1.2 Hipótesis ........................................................................................................... 16
1.3 Objetivos ........................................................................................................... 16
1.3.1 Objetivo General ........................................................................................... 16
1.3.2 Objetivos Específicos .................................................................................... 16
1.4 Estructura de la tesis ......................................................................................... 16
CAPÍTULO 2
ESTADO DEL ARTE .................................................................................................... 18
2.1 Introducción a las Redes Móviles ...................................................................... 18
2.1.1 Redes Inalámbricas....................................................................................... 18
2.1.2 Redes móviles Ad Hoc .................................................................................. 19
VII
2.1.3 Características de las redes inalámbricas ..................................................... 19
2.2 Protocolos de enrutamiento en redes Ad Hoc.................................................... 20
2.2.1 Protocolos Reactivos..................................................................................... 21
2.2.2 Protocolos Proactivos.................................................................................... 22
2.2.3 Protocolos Jerárquicos .................................................................................. 23
2.3 Clústering .......................................................................................................... 23
2.4 Backup Cluster Head Protocol........................................................................... 24
2.4.1 Creación del clúster....................................................................................... 24
2.4.2 Mantenimiento del clúster.............................................................................. 25
2.4.3 Envío de la información ................................................................................. 25
CAPÍTULO 3
DISEÑO DEL PROTOCOLO BCHPE........................................................................... 27
3.1 Descripción del protocolo .................................................................................. 27
3.2 Consumo de energía ......................................................................................... 29
3.3 Niveles de interacción de los nodos .................................................................. 30
3.4 Componentes del modelo de gestión para BCHPE ........................................... 30
3.4.1 Nodo común (NC) ......................................................................................... 31
3.4.2 Jefe de Cluster (JC)....................................................................................... 31
3.4.3 Jefe de Cluster de Respaldo (JCR) ............................................................... 31
3.5 Mantenimiento Proactivo del Clúster ................................................................. 32
CAPÍTULO 4
ESPECIFICACIÓN DEL PROTOCOLO BCHPE .......................................................... 33
4.1 Introducción....................................................................................................... 33
4.2 Definición de clases........................................................................................... 33
VIII
4.2.1 Definición del agente..................................................................................... 33
4.2.2 Tabla de enrutamiento................................................................................... 36
4.3 Algoritmos empleados para la implementación del protocolo ............................ 39
4.3.1 Inicialización del nodo ................................................................................... 39
4.3.2 Formación del cluster y elección del JC y JCR.............................................. 40
4.3.3 Inclusión de un nodo en el cluster ................................................................. 42
4.3.4 Proceso Proactivo del Jefe de Cluster........................................................... 42
4.4 Modelo de Energía en NS2 (Energy Model en C++).......................................... 43
4.5 Implementación de BCHPE............................................................................... 45
4.6 Inclusión del protocolo proactivo BCHPE en la herramienta de simulación ....... 46
4.7 Proceso de Simulación...................................................................................... 49
4.7.1 Etapa de pre-simulación................................................................................ 51
4.7.2 Etapa de simulación ...................................................................................... 52
4.7.3 Etapa de post-simulación .............................................................................. 52
CAPÍTULO 5
VALIDACIÓN DE LA PROPUESTA............................................................................. 53
5.1 Definición de Escenarios ................................................................................... 53
5.2 Resultados experimentales ............................................................................... 55
5.2.1 Rendimiento .................................................................................................. 56
5.2.2 Tasa de envío de paquetes (Packet Delivery Ratio) ...................................... 62
5.2.3 Sobrecarga del protocolo .............................................................................. 64
5.2.4 Pérdida de paquetes ..................................................................................... 66
5.2.5 Retardo promedio (Average end to end delay) .............................................. 67
5.2.6 Variación de retardo de paquetes (Jitter)....................................................... 69
IX
Conclusiones ................................................................................................................ 72
Líneas Futuras.............................................................................................................. 74
ANEXOS
Instalación y configuración de herramientas ................................................................. 75
BIBLIOGRAFÍA........................................................................................................... 151
X
ÍNDICE DE FIGURAS
FIGURA 2-1. ESTRUCTURA DE UNA RED DE TIPO INFRAESTRUCTURA. (SOLANO, 2010)...........19
FIGURA 2-2 ESTRUCTURA DE UNA RED AD HOC (SOLANO, 2010).........................................19
FIGURA 2-3. TRASMISIÓN DE PAQUETES DEL ORIGEN AL DESTINO EN UNA MANET ...............21
FIGURA 3-1. MODELO PROPUESTO PARA BCHPE............................................................... 28
FIGURA 3-2. LÍMITES DE CONSUMO DE BATERÍA...................................................................29
FIGURA 4-1. DIAGRAMA DE CLASES DEL NODO BCHPE GENERADO EN UMBRELLO(COMMUNITYUMBRELLO, 2012) .....................................................................................................35
FIGURA 4-2. DIAGRAMA DE CLASES PARA EL MANEJO DE TABLAS DE ENRUTAMIENTO ...........38
FIGURA 4-3. INICIO DEL NODO ............................................................................................39
FIGURA 4-4. FORMACIÓN DEL CLUSTER .............................................................................41
FIGURA 4-5. INCLUSIÓN DE UN NUEVO NODO ......................................................................42
FIGURA 4-6. PROCESO PROACTIVO DEL JC........................................................................43
FIGURA 4-7. PROCESO DE SIMULACIÓN EN NS2..................................................................50
FIGURA 5-1. CAPTURA DE PANTALLA DE UN ESCENARIO CON 100 NODOS EN EL PROGRAMANAM (THE NETWORK ANIMATOR), APLICACIÓN QUE ACOMPAÑA A NS Y VISUALIZA LASSIMULACIONES REALIZADAS CON ÉSTE. .......................................................................54
FIGURA 5-2. RENDIMIENTO CON 25 NODOS ........................................................................57
FIGURA 5-3. RENDIMIENTO CON 30 NODOS ........................................................................57
FIGURA 5-4. RENDIMIENTO CON 40 NODOS ........................................................................58
FIGURA 5-5. RENDIMIENTO CON 50 NODOS ........................................................................59
FIGURA 5-6. RENDIMIENTO CON 60 NODOS ........................................................................59
FIGURA 5-7. RENDIMIENTO CON 70 NODOS ........................................................................60
FIGURA 5-8. RENDIMIENTO CON 80 NODOS ........................................................................60
FIGURA 5-9. RENDIMIENTO CON 90 NODOS ........................................................................61
XI
FIGURA 5-10. RENDIMIENTO CON 100 NODOS.....................................................................61
FIGURA 5-11. TASA DE ENVÍO DE PAQUETES.......................................................................63
FIGURA 5-12. TASA DE ENVÍO DE PAQUETES DE APLICACIÓN TCP........................................63
FIGURA 5-13. SOBRECARGA DEL PROTOCOLO TIPO TCP.....................................................65
FIGURA 5-14. PAQUETES BORRADOS .................................................................................67
FIGURA 5-15. RETARDO EXTREMO A EXTREMO TIPO TCP....................................................68
FIGURA 5-16. VARIACIÓN DE RETARDO DEL PAQUETE TIPO TCP ..........................................70
FIGURA ANEXO -1. CAMBIO DE VARIABLES DE ENTORNO....................................................76
FIGURA ANEXO -2. EJECUCIÓN DE NS ..............................................................................77
FIGURA ANEXO -3. VALIDACIÓN SATISFACTORIA DE NS ......................................................78
FIGURA ANEXO -4. EXTRACCIÓN DEL INSTALADOR DE TRACEGRAPH ...................................80
FIGURA ANEXO -5. EXTRACCIÓN DE LIBRERÍAS MATLAB......................................................80
FIGURA ANEXO -6 EDICIÓN DE PATH ./BASHRC..................................................................81
FIGURA ANEXO -7 ACTUALIZACIÓN DEL PATH ...................................................................81
FIGURA ANEXO -8. EJECUTAR TRACEGRAPH.....................................................................81
FIGURA ANEXO -9 INTERFAZ DE TRACEGRAPH...................................................................82
FIGURA ANEXO -10 VERIFICACIÓN DE LA VERSIÓN DE JAVA INSTALADA .............................. 83
FIGURA ANEXO -11. PÁGINA OFICIAL PARA DESCARGA DE ECLIPSE .....................................84
FIGURA ANEXO -12. DESCOMPRIMIR ECLIPSE ..................................................................84
FIGURA ANEXO -13. INSTALACIÓN DE ECLIPSE ...................................................................84
FIGURA ANEXO -14 INSTALACIÓN DE ECLIPSE ....................................................................84
FIGURA ANEXO -15 ENTORNO DE TRABAJO ......................................................................85
FIGURA ANEXO -16 VENTANA DE INICIO DE ECLIPSE.........................................................85
XII
FIGURA ANEXO -17 DANDO NOMBRE AL PROYECTO NS-2.34..............................................86
FIGURA ANEXO -18. PROYECTO NS-2.34 CARGADO EN ECLIPSE ........................................86
FIGURA ANEXO -19. CONFIGURACIÓN DE EJECUCIÓN.........................................................87
FIGURA ANEXO -20. EJECUTABLE DE NS ...........................................................................88
FIGURA ANEXO -21. EJECUTABLE DE NS...........................................................................88
FIGURA ANEXO 22. NS EJECUTÁNDOSE CORRECTAMENTE ................................................89
ÍNDICE DE TABLAS
TABLA 4-1.ESTRUCTURA DE ARCHIVOS ...............................................................................47
TABLA 4-2. INCLUSIÓN DE BCHPE EN NS2.........................................................................48
TABLA 5-1. PARÁMETROS GENERALES DE LA SIMULACIÓN ....................................................54
TABLA 5-2. RELACIÓN PROMEDIO DE PAQUETES ENVIADOS .................................................64
TABLA 5-3. RELACIÓN PROMEDIO DE SOBRECARGA DEL PROTOCOLO ..................................65
TABLA 5-4. RELACIÓN PORCENTAJE PROMEDIO DE PAQUETES PERDIDOS ............................66
TABLA 5-5. RELACIÓN RETARDO PROMEDIO.......................................................................69
TABLA 5-6. RELACIÓN RETARDO PROMEDIO.......................................................................71
ÍNDICE DE ANEXOS
ANEXO 1. DESCARGAR E INSTALAR NS2.34......................................................................76
ANEXO 2. TRACEGRAPH .................................................................................................79
ANEXO 3. ECLIPSE HELIOS ............................................................................................. 83
ANEXO 4. CAMBIOS EN NS2 PARA INCLUIR AL PROTOCOLO BCHPE..................................89
ANEXO 5. CONFIGURACIÓN DE LA TOPOLOGÍA................................................................ 116
ANEXO 6. ARCHIVO OTCL USADO EN LA SIMULACIÓN...................................................... 117
ANEXO 7. ARCHIVOS AWK PARA LOS RESULTADOS ......................................................... 124
ANEXO 8. ARTÍCULO ......................................................................................................134
13
RESUMEN
En el presente proyecto de fin de titulación se presenta el funcionamiento del
Protocolo BackupCluster Head ProtocolEnhanced (BCHPE) aplicado para
redes móviles Ad Hoc, el mismo que es un protocolo de enrutamiento
jerárquico proactivo. Los protocolo proactivos dividen la red en subconjuntos de
nodos llamados cluster, en donde cada nodo jefe de cluster (JC) es utilizado
para concentrar y distribuir la información generada dentro del cluster.
BCHPE tiene un Jefe de Cluster de Respaldo (JCR) en caso de fallas del
principal, y gracias a la inclusión de una estrategia proactiva, permite controlar
el estado de la batería del nodo Jefe de Cluster y del Jefe Cluster de Respaldo,
estableciendo un valor umbral con la finalidad de mantener la red lo más
estable posible, evitando la ruptura de comunicación intracluster y extracluster.
El cambio entre el jefe cluster y su backup se hará de forma proactiva evitando
la pérdida excesiva de paquetes, manteniendo la red Ad Hoc estable.
14
CAPÍTULO 1
INTRODUCCIÓN
Las redes Móviles Ad Hoc, MANET (Mobile Ad Hoc Network) consisten en un
conjunto de nodos móviles o routers que se comunican entre sí a través de
enlaces inalámbricas, la comunicación es realizada de forma distribuida, donde
cada nodo toma decisiones sobre su participación en el intercambio de
información. La0020forma de comunicación de las redes Ad Hoc es broadcast.
Las redes móviles son indispensables para la comunicación entre diferentes
tipos de dispositivos móviles, permitiendo que los usuarios tengan acceso aun
cuando vayan de un lugar a otro sin necesidad de realizar una nueva conexión.
(Torres, 2012)
Las MANETs poseen protocolos de enrutamiento cuya función principal es la
de proporcionar una ruta para la transmisión de paquetes desde un nodo fuente
a un nodo destino.
Existen varias clasificaciones de los protocolos de enrutamiento, pero la más
conocida según (Biradar & Patil, 2006) y (Royer & Toh, 1999) es la clasificación
de protocolos proactivos, reactivos y jerárquicos. En los protocolos reactivos
solo se realiza el descubrimiento de rutas cuando es necesaria una conexión,
presentan tiempos de descubrimiento de ruta bastante cortos ya que trabajan
bajo demanda, de esta manera hacen que el tiempo de entrega de paquetes
sea menor; utilizan mecanismos de descubrimiento y mantenimiento de ruta.
Los protocolos proactivos intercambian periódicamente mensajes entre ellos a
fin de mantener actualizadas las rutas, pueden elegir la mejor ruta a cada
instante, ofreciendo una rápida respuesta ante las solicitudes de ruta, lo cual
hace que la sobrecarga de información sea alta. Los protocolos jerárquicos en
cambio dividen la red en subconjuntos de nodos llamados cluster, en donde un
nodo Jefe de Cluster (JC) es utilizado para concentrar y distribuir la información
15
generada dentro del cluster, dentro de este tipo de protocolos se encuentra
BCHP “Backup Cluster Head Protocol”. (Torres, 2012)
En este contexto uno de los retos que tiene BCHP es lograr la mejora de la red
a través de la inclusión de un Jefe Cluster de Respaldo (JCR) para que tome
lugar del Jefe de Cluster cuando este falle.
Sin embargo BCHP mejora este proceso pero lo realiza de forma reactiva, lo
que provoca que en tiempos cortos haya pérdida de comunicación entre los
nodos.
Nuestra propuesta es una mejora al BCHP que considera una estrategia
proactiva basada en el consumo de energía del JC.
Para lograr este objetivo proponemos el BCHPE (Backup Cluster Head
Protocolo Enhanced) que es una mejora del BCHP la cual la implementamos
en un simulador de redes llamado Network Simulator 2 (ISI, 2012).
1.1 Definición del Problema
Un tema de interés son las redes móviles Ad Hoc (MANET), las mismas que
están diseñadas para brindar comunicaciones rápidas y eficientes sin
necesidad de que exista una infraestructura de red ya que se basa en una
topología descentralizada. En este contexto, el estudio de diversos protocolos
de enrutamiento, debe ser adaptado a las necesidades específicas de las redes
móviles.
Se ha desarrollado un nuevo protocolo de enrutamiento jerárquico denominado
Backup Cluster Head Protocol el mismo que incorpora la elección de un Jefe de
Cluster de Respaldo (JCR) en caso de fallas del principal para que tome su
lugar.
16
Sin embargo BCHP mejora este proceso pero lo realiza en forma reactiva, es
decir que el JCR actúa cuando el JC no está disponible, lo que provoca que en
tiempos cortos de simulación haya pérdida de comunicación entre los nodos.
1.2 Hipótesis
De acuerdo a los estudios realizados a los protocolos de enrutamiento para
redes Ad Hoc, en específico al BCHP, se plantea la siguiente hipótesis, cuyo
resultado será verificado mediante el uso de la herramienta de simulación
Network Simulator 2 y herramientas de análisis de resultados como
TraceGraph (Jaroslaw, 2007). La hipótesis es la siguiente:
Un protocolo de enrutamiento jerárquico proactivo aplicado a redes
móviles Ad Hoc permite mejorar los tiempos de respuesta y por ende
mejorar el rendimiento de la red con respecto a BCHP.
1.3 Objetivos
1.3.1 Objetivo General
Mejorar la gestión de redes móviles Ad Hoc, a través de la propuesta del uso
de una estrategia proactiva en el nuevo protocolo de enrutamiento jerárquico.
1.3.2 Objetivos Específicos
Estudiar los modelos de gestión de red existentes para determinar e
incorporar características que nos permitan la mejora de BCHP.
Mejorar la disponibilidad de las estrategias de enrutamiento jerárquico
mediante la inclusión de una estrategia proactiva al JC.
Validar la propuesta mediante Simulación.
1.4 Estructura de la tesis
Con el objetivo de que la presente tesis sea autocontenida se ha hecho una
distribución entre los contenidos y desarrollo de la misma de la siguiente forma:
17
El Capítulo 1: Introducción, se presenta el marco científico al que se
adhiere el proyecto, plantea los objetivos a cumplir y la metodología
empleada.
El Capítulo 2: Estado del Arte, se revisa los contenidos teóricos con la
base contextual para la elaboración de la presente investigación.
El Capítulo 3: Diseño del Protocolo, se aborda la propuesta del
protocolo de enrutamiento y como éste mejorará la disponibilidad de la
red.
El Capítulo 4: Especificación del Protocolo BCHPE, se presenta la
estructura de nuestro protocolo BCHPE, los algoritmos propuestos para
su ejecución y una descripción del modelo de energía usado para su
funcionamiento proactivo; así mismo el proceso de inclusión del
protocolo dentro de la herramienta network Simulator NS-2.
El Capítulo 5: Validación de la propuesta, se muestra la definición de
los escenarios donde se desarrollará la simulación, además los
resultados experimentales (cualitativos y cuantitativos) incluyendo los
parámetros de evaluación.
Conclusiones y líneas Futuras, se muestra las conclusiones de la
presente investigación y propone algunas orientaciones que dan
continuidad al presente proyecto.
Anexos, se muestra los manuales de instalación y configuración de las
herramientas utilizadas, los archivos usados para la simulación y
generación de gráficas, y el código del nuevo protocolo.
18
CAPÍTULO 2
ESTADO DEL ARTE
2.1 Introducción a las Redes Móviles
En esta sección se hace una revisión de los conceptos e investigaciones
relacionados al tema que nos sirven de guía para el desarrollo en la presente
tesis. Se analiza de forma detallada a las Redes Móviles Ad Hoc (MANET) y
sus características, también los protocolos de enrutamiento aplicados a las
redes móviles, en especial el protocolo de enrutamiento BCHP de cuyo análisis
nos servirá para completar nuestra investigación.
2.1.1 Redes Inalámbricas
Desde la segunda guerra mundial las redes inalámbricas han tenido un gran
impacto a nivel mundial, donde se empezó a usar para estrategias militares.
Desde entonces, estas redes se han desarrollado y su uso ha crecido
significativamente por ejemplo, en tecnologías como los teléfonos, grandes
áreas Wifi, ofrecidas en diferentes puntos de ciudades, conexiones Bluetooth
entre dispositivos, el sistema GPS o simplemente una red local casera o
empresarial.
Uno de los principales factores para el crecimiento éstas redes, es que las
redes tradicionales no permiten la movilidad de sus usuarios. En cambio, las
redes inalámbricas permiten el libre movimiento de los usuarios dentro de la
red, reduciendo significativamente los costes de mantenimiento. (García;
González; Martín, 2009)
Las redes inalámbricas pueden dividirse en dos categorías:
Redes inalámbricas basadas en infraestructura prestablecida (ver figura
2-1) , y
19
Redes Ad Hoc (ver Figura 2-2)
Figura 2-1. Estructura de una red de tipo infraestructura. (Solano, 2010)
Figura 2-2 Estructura de una red Ad Hoc (Solano, 2010)
2.1.2 Redes móviles Ad Hoc
Una red móvil Ad Hoc “MANET” es una red inalámbrica formada por nodos
móviles que se interconectan entre sí a través de enlaces inalámbricos de
comunicación, los cuales pueden ser de uno o múltiples saltos. Estas redes se
establecen sin una infraestructura predefinida y no requieren de un control
centralizado.
2.1.3 Características de las redes inalámbricas
El propósito de las redes móviles ad hoc es el de apoyar operaciones robustas
y eficientes, incorporando un enrutamiento funcional en los nodos móviles.
Debido a que las MANET se pueden construir espontáneamente sin necesidad
de una infraestructura existente, estas redes presentan restricciones especiales
20
que se deben considerar para el diseño de soluciones. (Morocho, 2010) A
continuación se describen algunas características:
Topologías dinámicas
En las topologías dinámicas, los nodos se mueven libremente en cualquier
dirección independientemente de los demás nodos haciendo que la topología
esté en constante cambio.
Operación en forma distribuida
Normalmente los nodos tienen conocimiento local sobre su entorno, cada nodo
sólo conoce la información sobre los nodos vecinos que se encuentran dentro
de su radio de transmisión y no tienen un conocimiento global de la red.
Limitaciones de energía
Las baterías son su fuente de energía, las cuales tienen una reserva de
energía limitada, esto hace que sea necesario el ahorro de energía.
Seguridad física limitada
Son susceptibles de tener carencia de seguridad por su conexión inalámbrica y
pueden ser atacadas fácilmente.
Ancho de banda restringido
Restricciones impuestas por el canal inalámbrico, tal como acceso múltiple,
interferencias, ruido, disponibilidad limitada del espectro, etc.
2.2 Protocolos de enrutamiento en redes Ad Hoc
El protocolo de enrutamiento tiene como función principal proporcionar una ruta
para la transmisión de paquetes de un nodo fuente a un nodo destino. Ver
figura 2.3.
21
Figura 2-3. Trasmisión de paquetes del origen al destino en una MANET
Los protocolos de enrutamiento diseñados para las redes cableadas no son
eficientes para su aplicación en redes móviles debido a la movilidad de sus
nodos, por lo tanto han sido modificados con la finalidad de que ofrezcan
mejores soluciones de enrutamiento en movilidad y se adapten al entorno
dinámico de las redes móviles, permitiendo que superen problemas tales como
topología dinámica, recursos de ancho de banda limitada y seguridad reducida.
Existen varias clasificaciones de los protocolos de enrutamiento, pero la más
conocida es la clasificación de reactivos, proactivos y jerárquicos.
2.2.1 Protocolos Reactivos
Los protocolos reactivos pretenden buscar las rutas bajo demanda entre un
nodo origen y un nodo destino. De este modo cuando un nodo debe enviar un
paquete, inicia un mecanismo que le permite averiguar qué camino debe seguir
este paquete. Una desventaja de este planteamiento es el retardo adicional
necesario para descubrir una ruta. Sin embargo el overhead (sobrecarga) de
encaminamiento se puede reducir hasta cero si ningún nodo debe mandar
información.
AODV (Ad Hoc On Demand Vector)
Es un protocolo de enrutamiento reactivo basado en el algoritmo Vector
Distancia. (Bhagwat & Perkins, 2003)
22
En AODV los nodos de una trayectoria, antes de proporcionar
información de direccionamiento, crean un número de secuencia de
destino (destination sequence number), que proporciona a los nodos un
instrumento para evaluar cuando se ha actualizado un determinado
recorrido evitando la formación de lazos (loop) en el camino de
enrutamiento. (Gil, 2009)
Soporta el enrutamiento multidifusión (multicast) a través de la MAODV.
(Royer, 2000)
Usa mensajes particulares llamados RREQ (Route Request), RREP
(Route Replies), y RRER (Route Errors) que son enviados y recibidos
mediante el protocolo UDP.
2.2.2 Protocolos Proactivos
El encaminamiento proactivo tiene como objetivo mantener las tablas de los
nodos permanentemente actualizadas, de forma que cuando un nodo quiera
enviar datos a otro, ya disponga de la información necesaria para alcanzar a su
destino. En términos generales, esto supone un intercambio periódico de
información entre los nodos, y por tanto, la existencia de un overhead en la red.
Sin embargo, la disponibilidad de rutas en cualquier momento permite que el
retardo extremo a extremo asociado a la transmisión de un paquete sea bajo,
puesto que cuando un nodo quiere mandar un paquete, ya conoce la ruta.
DSDV (Destination Sequenced Distance Vector)
Es un protocolo de direccionamiento tipo proactivo, que pertenece a los
algoritmos vector distancia. (Carrillo, 2011) (Bhagwat & Perkins, 2003)
DSDV está basado en la actualización de las tablas de enrutamiento,
cada nodo perteneciente a la red tiene una tabla de enrutamiento que
indica los posibles destinos y el número de saltos que hacen falta
atravesar para llevar el paquete desde su origen a su destino. Para
23
mantener la consistencia de la red se envían periódicamente mensajes
de actualización a través de la red.
DSDV es en general aceptable en escenarios donde intervienen los
nodos directamente y existe una movilidad media.
2.2.3 Protocolos Jerárquicos
Los protocolos de enrutamiento jerárquico dividen la red en subconjuntos de
nodos llamados clúster, en donde un nodo jefe de clúster es utilizado para
concentrar y distribuir la información generada dentro del clúster. Un ejemplo
de este tipo de protocolo es el Backup Cluster Head Protocol (BCHP), el mismo
que es analizado para el desarrollo del presente proyecto.
Los protocolos deben buscar un compromiso entre el tiempo de la búsqueda de
ruta y la sobrecarga de la búsqueda/mantenimiento. Los proactivos suelen
tener mejor latencia ya que las rutas se mantienen todo el tiempo, pero puede
ser que sufran mayor sobrecarga debido a continuas actualizaciones de
caminos, operaciones que consumen tiempo, ancho de banda y energía. Por lo
contrario los reactivos suelen tener mayor latencia, porque se intentará buscar
caminos entre dos nodos sólo cuando el origen desee comunicarse con el
destino, mientras que la sobrecarga es menor, pues las rutas son buscadas
sólo si se necesitan. La combinación de las dos aproximaciones anteriores da
lugar a los protocolos híbridos, que minimizan la desventaja de los mismos.
2.3 Clústering
Clústering es un procedimiento en el cual se clasifican los nodos en diferentes
grupos, según una medida de similitud determinada. A los diferentes grupos
obtenidos se los conoce como clústers. Los procesos de clústering realizan una
partición sobre un gran conjunto de nodos llevándolos a componentes más
pequeños, además estos procesos permiten que las MANET presenten un
mejor desempeño en cuanto a la rapidez de conexión, el enrutamiento y el
manejo de la topología.
24
Las redes Ad Hoc basadas en clústering, tienen como características la
estabilidad de la estructura del clúster, control de sobrecarga de construcción y
mantenimiento del clúster, consumo de energía de nodos móviles con
diferentes estados relacionados al clúster, distribución de carga de tráfico en
clústers y la equidad de servir como clúster cabeza de un nodo móvil. (Basagni,
Turgut, & Das, 2001)
Una MANET se organiza dinámicamente en clusters para mantener una
topología relativamente estable y de esta forma mejorar su desempeño; provee
características como:
Minimizar la sobrecarga de comunicación
Escoger puntos de agregación de datos
Incrementa la probabilidad de agregar datos redundantes
Minimiza el consumo de energía
El protocolo de enrutamiento BCHP por ejemplo, tiene tres epatas claramente
definidas:
Creación del clúster
Mantenimiento del clúster y,
Envío de la información
2.4 Backup Cluster Head Protocol
2.4.1 Creación del clúster
Cuando los nodos inician no pertenecen a ningún clúster, su estado inicial es
INDECISO, calculan un valor denominado métrica de acuerdo a las
características de velocidad, estado de la batería y ubicación dentro del clúster.
Luego envían su estado junto con el valor de su métrica a todos los nodos a
través de mensajes de difusión. Con estos valores cada nodo crea su tabla de
enrutamiento y determina cuáles vecinos tienen enlaces bidireccionales hacia
él. Esta información sirve para determinar los dos nodos con mejores
25
características y que pueden ser elegidos Jefe de Cluster (JC) y Jefe de Cluster
de Respaldo (JCR). Cada nodo almacena la dirección del JC y JCR para
acelerar el proceso de enrutamiento. (Torres, 2011)
2.4.2 Mantenimiento del clúster
Una vez que los clúster han sido definidos, debido al movimiento de los nodos,
al consumo de energía y al fallo de los nodos JC, pueden cambiar en cantidad
y ubicación. Además se pueden dividir o unir, por lo que para mantener la
convergencia de la red es importante mantener la jerarquía del clúster.
Cuando se unen varios cluster es posible que un nodo JC esté dentro del área
de cobertura de otro nodo JC, en este caso se inicia un periodo de contención.
Luego de que el tiempo de contención expira se elige nuevamente el nodo JC y
JCR del nuevo cluster.
Cuando un JC no está disponible, el JCR toma el valor del JC. El nodo JCR
determina que el nodo JC no está disponible y avisa a través del uso de
mensajes periódicos y de actualización que se transmiten entre ellos. Cuando
el nodo JCR asume la jerarquía, se convierte en JC y envía un mensaje por
difusión a todos los nodos del cluster informando de su nuevo estado.
Nuevamente se elige de entre los nodos el nuevo JCR.
2.4.3 Envío de la información
Existen tres niveles de enrutamiento:
1. Dentro del área de transmisión: en donde los nodos pueden ser
alcanzados directamente ya que tienen un enlace bidireccional entre
ellos y son visibles directamente. Aquí el nodo origen envía la
información directamente al nodo de destino.
26
2. Dentro del clúster: aquí los equipos se comunican directamente entre
sí a través de su tabla de vecinos. Cada nodo mantiene una tabla de
enrutamiento de vecinos en donde puede obtener la dirección del nodo
que servirá como enrutador para alcanzar su destino.
3. Fuera del cluster: donde cada JC concentra la información y la envía
hacia el clúster de destino. Un nodo determina que no existe camino
hacia el nodo de destino entonces entrega el paquete al Jefe de Cluster.
El Jefe de Cluster contiene una tabla de enrutamiento adicional para la
comunicación entre cluster. El JC envía la información al cluster de
destino o por difusión a todos los JC, dependiendo de si tiene una
entrada en la tabla de enrutamiento al nodo de destino.
Agente y nodo son términos que en esta tesis son sinónimos y se usarán
indistintamente para conceptualizar un dispositivo en la red. El término agente
es propio de la herramienta de simulación utilizada Network Simulator 2
(Simulator, 2008).
27
CAPÍTULO 3
DISEÑO DEL PROTOCOLO BCHPE
En el capítulo anterior se revisaron los componentes principales para la gestión
de redes e investigaciones asociadas con la gestión en Redes MANET.
En este capítulo, se propone un protocolo de enrutamiento para mejorar la
gestión de las redes móviles ad hoc denominado Backup Cluster Head Protocol
Enhanced “BCHPE” basado en BCHP.
Las redes móviles ad hoc se enfrentan al problema de pérdida de
comunicación entre los nodos por la inestabilidad que se produce en la
transmisión de información que provoca muchos conflictos dentro de una
topología.
La presente propuesta se diferencia de las demás y de su predecesor BCHP ya
que incorpora una estrategia proactiva basada en el consumo de energía
(INRIA) (Feeney, 2011) de los nodos principales Jefes de Cluster, de tal forma
que se logra gestionar de manera eficiente la red.
3.1 Descripción del protocolo
Como aporte para la gestión de red se propone el protocolo BCHPE (Backup
Cluster Head Protocol Enhanced). Como se muestra en la Figura 3-1, la red es
dividida en diferentes grupos denominados cluster, donde cada cluster tiene un
nodo Jefe de Cluster (JC), un nodo Jefe de cluster de Respaldo (JCR) que
tomará las funciones principales del cluster en caso de falla del nodo principal.
El JCR mantiene una comunicación periódica con su JC para tener información
actualizada del estado del JC, a través de éste se logra mejorar la
convergencia de la red ya que el cluster no realiza la elección de un nuevo JC.
Además tiene una cantidad arbitraria de nodos comunes (NC) que son
28
miembros de los cluster y un nodo Gateway (NG) el mismo que permite la
comunicación entre clusters.
El dividir la red Ad Hoc en cluster permite que la sobrecarga de la red se
disminuya, debido a que la comunicación se concentra entre los JC, a través de
una red malla o backbone.
Adicionalmente se puede observar que se toma en cuenta el estado de batería
del nodo JC para establecer el cambio con el JCR cuando éste se encuentre
cerca al valor límite.
Figura 3-1. Modelo propuesto para BCHPE
El proceso de descubrimiento de la topología se realiza periódicamente para
mantener la red en convergencia y sincronizar la información en todos los
nodos. (Torres, 2011).
29
3.2 Consumo de energía
La autonomía energética es un factor importante a la hora de diseñar
dispositivos móviles.
Una batería es un dispositivo electroquímico el cual almacena energía en forma
química. Cuando se conecta a un circuito eléctrico, la energía química se
transforma en energía eléctrica. Las baterías de los nodos tienen carga Q.
La carga eléctrica se define como la intensidad de corriente eléctrica que
circula por el circuito en una unidad de tiempo, como se muestra en la ecuación
(3.1).
= (3.1)
Donde I es la intensidad de corriente eléctrica y T es el tiempo.
0%
0%
Qmin
Qlim85%
100 % Qmax
Figura 3-2. Límites de Consumo de batería
Como se puede apreciar en la Figura 3-2, la carga de los dipositivos se
encuentra al 100%. Para el cálculo del límite de la carga de la batería se toma
como valor referencial que Q debe llegar a una variable l, que para pruebas se
ha definido en 85% de su consumo, para que se ejecute el cambio de roles
entre el JC y su respaldo, lógicamente este consumo está relacionado al
tiempo en el cual se está dando el proceso de simulación, por tanto también
hay un tiempo límite, además el consumo de energía es variable dependiendo
30
del dispositivo con que se trabaje, es por esto que se toma el porcentaje (%) y
no un valor específico de carga Q. De esto se tiene la siguiente deducción:
Si: = Tiempo de duración de la batería (3.2)
Donde Tmax representa el tiempo.
Por lo tanto el tiempo límite es igual a:
= (3.3)
Y la carga límite es igual a:
= (3.4)
3.3 Niveles de interacción de los nodos
El modelo se basa en una arquitectura jerárquica ya definida por HAMAN (High
Availability Management Ad Hoc Networks)(Torres, 2012) en 2 niveles de
interacción:
1. Nivel de acceso: Está dada por la interacción de los Nodos Comunes (NC),
incluyendo la comunicación entre los NC y los JC y JCR. En este nivel se
llevan a cabo los procesos de elección y sincronización del JC y del JCR.
2. Nivel de distribución: Dada por la interacción entre los JC. En este nivel
se llaman a cabo los procesos de la creación de la red malla o backbone
entre los nodos JC (Basagni, Turgut, & Das, 2001) para la distribución de la
información.
3.4 Componentes del modelo de gestión para BCHPE
El modelo está formado por algunos tipos de nodos, protocolos y bases de
datos para la representación de la información, a continuación se describen
cada uno de ellos.
31
3.4.1 Nodo común (NC)
Son todos aquellos dispositivos que son parte del cluster y contienen toda la
información referente al estado de energía que poseen, la misma que va a ser
compartida con el JC. (Morocho, 2010)
El NC guarda la información de identificación del JC y JCR, la misma que es
utilizada para el envío de información y cuando existen problemas con el nodo
JC. Gestiona su pertinencia y el nivel de interactividad dentro del cluster. Se
definen dos tipos de nodos manejados.
3.4.2 Jefe de Cluster (JC)
Es un NC con mejores prestaciones que el resto de nodos pertenecientes al
cluster. Es seleccionado como JC cuando tiene las mejores prestaciones
tomando en cuenta: recursos disponibles del nodo, menor movilidad en el
nodo, rango de transmisión y el nivel de estado de la batería.
3.4.3 Jefe de Cluster de Respaldo (JCR)
Es el segundo mejor nodo. Su propósito principal es mejorar la disponibilidad
de la red, interactúa con los NC y el JC. En caso de que el JC falle o haya
llegado a su límite de nivel de energía, el JCR asume automáticamente sus
funciones, seguido de esto se invoca nuevamente al proceso de elección del
JCR. Junto al JC mantienen sesiones de sincronización periódica para validar
la integridad de la información. (Torres, 2012).
Existen ciertos eventos que identifican fallas de los nodos principales:
El nivel de energía ha llegado a su límite de carga eléctrica Qlim.
El nodo JCR no recibe actualización de la información de gestión en los
intervalos acordados.
El nodo JC no recibe acuses de recibo en los tiempos determinados.
32
Los NC envían información de gestión al nodo JCR porque ha
determinado que el nodo JC no está disponible.
3.5 Mantenimiento Proactivo del Clúster
Una vez que se han definido los clusters, éstos pueden cambiar de cantidad de
nodos existentes en cada cluster y de ubicación debido al movimiento de los
nodos, al consumo de energía y a fallos de los nodos JC; es por eso que nos
hemos enfocado directamente en el estado de la batería del nodo, ya que sin
energía el nodo deja de funcionar y la comunicación entre los cluster se rompe.
Además los nodos se pueden dividir o unir, por lo que es importante mantener
la red convergente y así la jerarquía del cluster.
Al unirse varios cluster es posible que un JC esté dentro del rango de cobertura
de otro nodo JC lo que produce un tiempo de contención. Luego de que expira
el tiempo de contención, se elige nuevamente JCR del nuevo cluster.
Cuando un JC no está disponible el JCR toma el valor del JC. El JCR
determina que el JC no está disponible a través del uso de mensajes periódicos
y de actualización que se transmiten entre ellos. Cuando el nodo JCR asume la
jerarquía, se convierte en JC y envía un mensaje por difusión a todos los nodos
del cluster informando de su nuevo estado. Nuevamente se elige de entre los
nodos el nuevo JCR.
De lo anterior, la estrategia proactiva que se propone en la presente
investigación, consiste en la inclusión de la (clase Modelo de Energía en C++)
dentro del protocolo de enrutamiento, la misma que permite acceder a la carga
eléctrica de la batería de los nodos – cantidad de energía que poseen- y de
esta manera establecer un valor límite (umbral) en la batería del nodo JC para
que cuando éste llegue al límite (ver fórmula 3.4) automáticamente se produzca
el cambio entre el JC y JCR, manteniendo de esta manera la conectividad de la
red y su estabilidad.
33
CAPÍTULO 4
ESPECIFICACIÓN DEL PROTOCOLO BCHPE
4.1 Introducción
En este capítulo se especifica las etapas del protocolo Backup Cluster Head
Protocol Enhanced, BCHPE que es una mejora del protocolo BCHP. La
diferencia principal entre BCHPE y BCHP es la mejora de la disponibilidad de la
red a través de la utilización de una estrategia proactiva que consiste en el
consumo de carga eléctrica Q que genera energía de los JC y JCR.
Básicamente mantiene la misma estructura de BCHP en cuanto a sus clases,
tablas de enrutamiento. Finalmente se muestra el proceso de inclusión del
protocolo BCHPE en la herramienta de simulación Network Simulator 2.
4.2 Definición de clases
Un agente (nodo) de tipo BCHPE contiene los siguientes componentes:
Un Agente: que recopila toda la información del nodo
Las Tablas de enrutamiento: donde se almacena la información de los
nodos y los cluster vecinos, sirve como entrada para los procesos de
cluster.
A continuación se detalla las clases para cada uno de los componentes de un
nodo BCHPE.
4.2.1 Definición del agente
La Figura 4-1 muestra las clases principales con sus propiedades (atributos) y
métodos que definen la estructura de un nodo BCHPE.
34
BCHPEagent es la clase principal donde se definen las propiedades y métodos,
las propiedades generalmente heredan comportamientos de sus clases
superiores lo que le permite interactuar con los siguientes componentes del
simulador: El manejo de eventos, trazas, temporizadores.
Un nodo BCHPE implementado en el simulador NS2, hereda y modifica el
comportamiento general y básico definido en las clases MobileNode y Agentpara el proceso de envío y recepción de paquetes para nodos inalámbricos y
nodos normales.
La interacción con el simulador se la hace a través de eventos y manejadores
definidos en las clases NsObject, Event, Handler y que son heredados por el nodo
BCHPE. Para obtener los métodos de manejo de trazas hereda de la claseTrace.Dentro del protocolo, el nodo maneja una tabla de enrutamiento definida en la
clase BCHP Agent::HNeighborTable.
El protocolo BCHPE utiliza el concepto de temporizador para el manejo de las
entradas de la tabla de enrutamiento y para determinar el estado de un vecino.
El manejo de los temporizadores es heredado de la clase TimerHandler y
modificado en la clase BCHP Agent::BCHP SendBufferTimer.
35Figura 4-1. Diagrama de clases del nodo BCHPE generado en Umbrello(Community Umbrello, 2012)
36
4.2.2 Tabla de enrutamiento
La Figura 4-2 muestra las clases principales con sus propiedades (atributos) y
métodos que definen la tabla de enrutamiento de un nodo BCHPE.
Dependiendo del tipo de nodo puede o no contar con dos tablas de
enrutamiento. Si es un nodo manejado solo contará con la tabla de ruta de
vecinos. Si es un nodo JC o JCR, contará además con la tabla de adyacencias
que se forma cuando dos routers vecinos han intercambiado información de
routing y han sincronizado sus tablas. Ambos routers están en la misma red.
La clase principal HNeighborTable define las propiedades y métodos, las
propiedades por lo general heredan comportamientos de clases definidas en el
simulador lo que permite interactuar con los siguientes procesos: el manejo de
eventos, trazas y temporizadores. En esta clase se definen las tablas de rutas:
tabla de rutas para vecinos, tabla de rutas para los nodos JC y JCR. También
se definen los métodos para obtener, crear, borrar y actualizar registros de las
tablas de enrutamiento. Además se crean métodos para elegir el JCR, para
generar paquetes de actualización y de broadcast que permiten tener
actualizadas todas las tablas de enrutamiento de todos los nodos. Así como
también se definen métodos para la actualización periódica y por eventos de
las entradas de las tablas de enrutamientos.
Las características más importantes relacionadas con las tablas de rutas son:
Existe una tabla de ruta de vecinos para cada nodo, definido en la clase
ntable_ent.
Cada JCR y JC tienen campos en la tabla de enrutamiento para
identificar cual es su JC y su JCR respectivamente, estos campos son:
my_cluster_head y my_cluster_head_backup.
La tabla de ruta de vecinos está conformada por entradas que identifican
el estado, la dirección, el tiempo de la última actualización del destino y
el próximo salto.
37
Existe una tabla de jefes de cluster, que define el backbone, la cual
contiene una dupla formada por entradas para los jefes de cluster y los
respectivos nodo Gateway, donde adjtable_ent es una entrada a la
dirección del JC adyacente y nexthop_ent es una o más entradas para los
nodos gateways entre el cluster y el JC adyacente.
Un nodo puede tener mas de un nodo JC, o en otras palabras, un nodo
puede pertenecer a más de un cluster. Un claro ejemplo son los nodos
Gateway. Esto implica que una entrada hacia un nodo de destino puede
tener más de un camino de enrutamiento, adjtable_ent y nexthop_ent.
La interacción con el simulador se la hace a través de eventos y manejadores
definidos en las clases Event y que son heredados por los atributos de tipo Event
definidos en la tabla de enrutamiento.
La clase HNeighborContentionHandler define los atributos y métodos que permiten
organizar los cluster. Solo está permitido un JC y un JCR por cluster, en esta
clase se definen los procesos que se invocan cuando existe la presencia de
más de un JC en el mismo cluster.
La clase HNeighborCFormationHandler define los procesos para la formación de
cluster. Estos son invocados cuando inicia la simulación y cada vez que un
cluster pierde su JC y su JCR.
El mantenimiento periódico de los cluster y de la tabla de enrutamiento en cada
nodo se lo realiza a través de los métodos definidos en la clase
HNeighborPeriodicHandler.
El control de temporizadores para eventos que han expirado, por ejemplo
finalizó el tiempo para recibir acuse de recibo, se lo hace a través de los
métodos implementados en la clase HNeighborTimeoutHandler.
38
Figura 4-2. Diagrama de Clases para el manejo de tablas de enrutamiento
39
4.3 Algoritmos empleados para la implementación del protocolo
A continuación se detallan los algoritmos propuestos para el funcionamiento del
protocolo BCHPE.
4.3.1 Inicialización del nodo
Al iniciar un nodo (ver Figura 4-3) lo hace con un estado INDECISO, obtiene
su métrica basado en la carga de la batería Q (establecido en la sección 3.2
Consumo de energía), que junto con la con la dirección del nodo serán
utilizadas para la elección de los JC, JCR.
Figura 4-3. Inicio del nodo
El nodo envía su métrica (carga Q) a sus vecinos a través su tabla de
enrutamiento en forma de broadcast y a su vez recibe las métricas de sus
vecinos y se actualizan los estados de los nodos. Luego de esta inundación se
40
inicia el proceso de formación del cluster, y el JC y JCR llevan un registro el
uno del otro.
Una vez inicializadas las tablas de enrutamiento se invocan e inician los
temporizadores para los procesos de formación del cluster, mantenimiento
periódico del cluster, expiración de las tablas de enrutamiento y contención del
cluster. (Torres, 2012)
4.3.2 Formación del cluster y elección del JC y JCR
Una vez de recibidos los mensajes HELLO de parte de los nodos (que contiene
el valor de su métrica Q), un nodo entra en un proceso de formación de cluster.
Este proceso incluye la identificación de todos los cluster a los que el nodo
puede pertenecer, además la elección del JC y JCR. (Ver Figura 4-4).
La elección del JC se la hace en función a su métrica basada en el mejor
estado de energía, donde puede darse el caso de que QA > QN, es decir que el
nodo A tiene mejor métrica que el resto de nodos del cluster, si existe dos
nodos con la misma métrica se toma aquel que tenga el valor de dirección mas
bajo. El nodo A comunica a todo sus NC que es el JC. Seguidamente se
pregunta si el nodo N tiene la segunda mejor métrica (Q), entonces cambia su
estado a JCR y comunica a sus vecinos de su nuevo estado, caso contrario es
un NC. Alternativamente se pregunta si QN > QA, entonces el nodo N es el JC y
se ejecuta el proceso anterior para determinar si el nodo A es JCR o NC.
Si el nodo cambia de estado, se genera un paquete BCHPE, y lo envía
inmediatamente a todos sus vecinos por medio de un mensaje de broadcast.
41
Figura 4-4. Formación del Cluster
42
4.3.3 Inclusión de un nodo en el cluster
Si hay un nodo nuevo dentro del dominio del cluster, envía su estado (Indeciso
o NC) a través de mensaje HELLO vecino a todos los nodos del cluster incluido
el JC, a su vez el JC le da la bienvenida notidicando quien es. Con la finalidad
de mantener la convergencia de la red, así tenga mejor métrica (Q), no pasa a
ser el JC sin embargo es tomado en cuenta para asumir la funciones de JCR.
Seguidamente a través de mensajes HELLO avisa que es el nuevo JCR. Si el
nodo tiene peor métrica pasa a ser un NC del cluster y actualiza su información
de pertenencia con respecto al cluster (ver Figura 4-5).
Figura 4-5. Inclusión de un nuevo nodo
4.3.4 Proceso Proactivo del Jefe de Cluster
Los nodos poseen baterías que tienen carga eléctrica Q (ver fórmula 3.1 de la
sección 3.2 Consumo de energía), y esta carga genera energía la misma que
43
se consume en todos los estados de los nodos, el JC informa su estado de
carga Q al JCR a través de mensajes de HELLO periódicamente hasta que
informa que ha llegado al límite establecido se su carga (ver fórmula 3.4) y es
cuando el JCR toma el valor de JC y comunica al resto de nodos del cluster su
nuevo estado. Los nodos miembros o NC inician el proceso de elección de un
nuevo jefe cluster de respaldo, una vez elegido se informa al jefe de cluster de
cual es el nuevo respaldo, este proceso se muestra a continuación: (ver Figura
4-6)
Figura 4-6. Proceso Proactivo del JC
4.4 Modelo de Energía en NS2 (Energy Model en C++)
El modelo de energía, tal como se aplica en NS2, es un atributo del nodo el
cual representa el nivel de energía en un nodo móvil; tiene un valor inicial que
es el nivel de energía que el nodo tiene al inicio de la simulación (initialEnergy_).
Haciendo referencia a la sección 3.2 Consumo de energía ,que muestra las
ecuaciones de la carga eléctrica que tienen la batería de los dispositivos
44
móviles, que generan energía, la misma que es utilizada por la clase
energymodel.c dentro de ns2.
La clase también tiene un consumo de energía dada para cada paquete que
transmite txPower_ y recibe rxPower_ (INRIA “Inventeurs Du Monde Numérique”)
(Feeney, 2011). Los archivos en los que se define el modelo energético son
ns/energymodel [. And.h cc]. Otras funciones / métodos descritos en este capítulo
se pueden encontrar en ns/wireles-phy.cc, ns/cmu trace.cc, ns/tcl/lib [ns-lib.tcl, ns-
node.tcl, ns-mobilenode.tcl] (Henderson, 2011).
La interfaz de una red inalámbrica puede estar en cualquiera de los siguientes
estados:
Transmisión: un nodo está transmitiendo un paquete con una potencia
consumida en transmisión Ptx.
Recepción: un nodo está recibiendo un paquete con una potencia de
recepción Prx..
Idle (listening): incluso cuando no hay mensajes que se transmiten a
través del medio, los nodos pueden permanecer inactivos y seguir
escuchando el medio con una potencia Pidle.
Dormido (sleep) Los nodos frenan su actividad y permanecen inactivos
para el ahorro de energía. El nodo en este caso usa una potencia Psleep
mínima en comparación a los otros estados.
Cada uno de los estados antes mencionados tiene una potencia eléctrica
asociada, definida como la relación de paso de energía de un flujo por unidad
de tiempo, es decir la cantidad de energía entregada o absorbida por un
elemento en un tiempo determinado, se tiene que:= (4.1)
Donde:
Ptx, Potencia consumida en transmisión.
45
V, Voltaje generado por la batería
I, Intensidad de corriente, que circula por los circuitos en el
transmisor
De (4.1) despejamos la intensidad de corriente y tenemos:
= (4.2)
Reemplazando (4.2) en (3.1) se obtienen la relación de la potencia y carga
eléctrica:
= (4.3)
Tomando en cuenta que la Potencia consumida en trasmisión es constante Ptx,
el Tiempo máximo de duración de la carga de la batería es:
= (4.4)
Donde Q y V son la carga y voltaje en la batería y Pmin es la potencia mínima.
Por lo tanto, reemplazando Tmax en (3.3) se tiene que el tiempo límite en el
cual los nodos JC y JCR deben cambiar de roles es igual a:
= (4.5)
4.5 Implementación de BCHPE
La implementación de la mejora del protocolo BCHPE se realizó en el software
de simulación NS2 –Network Simulator 2-. Con respecto a otros simuladores,
NS2 es más complejo en cuanto a entendimiento y uso, sin embargo el que sea
una herramienta de código abierto que permite agregar nuevos protocolos de
enrutamiento y funcionalidades lo hace mas óptimo, además el ser el simulador
más usado para simular a redes MANET.
46
NS2 fue creado por la Universidad de California. Es un simulador basado en
eventos orientado a objetos, usa dos lenguajes de programación C++ y OTcl.
Sus componentes desarrollados en C++, permiten la implementación de
funcionalidades básicas para los protocolos de enrutamiento, como son las
tablas de enrutamiento.
La parte de OTcl del simulador permite la modificación por parte del usuario de
escenarios de simulación tales como tiempo de duración de la simulación,
estado de batería inicial de los nodos, sin afectar al protocolo de enrutamiento.
NS2 implementa las clases necesarias que permiten la interacción entre las
clases C++ y OTcl y viceversa.
En el ANEXO 1 se puede observar el manual de instalación y validación de la
herramienta NS2, y posterior inclusión en el programa de eclipse helius (The
Eclipse Foundation, 2012).
4.6 Inclusión del protocolo proactivo BCHPE en la herramienta desimulación
Se ha implementado el protocolo de enrutamiento jerárquico proactivo dentro
del simulador ns-2. Para incluir BCHPE dentro del simulador, debemos crear
una estructura de archivos dentro de la estructura del simulador. Dentro de un
directorio colocamos los archivos de cabecera y el código fuente. En el caso
específico de BCHPE proponemos la siguiente organización y archivos (véase
Tabla 4-1). Ver (ANEXO 4. Cambios en NS2 para incluir al protocolo
BCHPE) para ver el archivo de cambios.
47
CLASES YCABECERAS
DESCRIPCIÓN
bchpeagent.h Se encuentran definidas las propiedades y métodos del
agente BCHPE
bchpeagent.cc En este archivo se encuentra la implementación de los
métodos del agente BCHPE. Constructores, métodos para
la recepción y envío de paquetes del protocolo de
enrutamiento, métodos para el manejo de errores y fallas
de comunicación.
bchpentable.h Definición de clases, propiedades y métodos para el
manejo de las tablas de enrutamiento del protocolo.
bchpentable.cc En este archivo se encuentra el código fuente para la
implementación de los métodos y acceso a las
propiedades de las clases que definen el enrutamiento del
protocolo BCHPE. También se encuentra la
implementación para el manejo de temporizadores.
Procesos para la creación y mantenimiento de los clusters.
Además se incluye el acceso al estado de batería de los
nodos para el funcionamiento proactivo del mismo.
bchpe_packet.h Se define la estructura del paquete BCHPE que será
utilizada para enviar y recibir información del protocolo.
hdr_bchpe.h Define la estructura de la cabecera del paquete BCHPE.
Sus métodos y propiedades.
hdr_bchpe.cc En este archivo se encuentra la implementación de las
clases necesarias para la integración entre las clases
definidas en C++ y OTcl.Tabla 4-1.Estructura de archivos
Con la estructura ya definida, debemos realizar algunos cambios en la
herramienta de simulación. En la presente investigación hemos modificado NS2
48
para incluir el algoritmo BCHPE propuesto, los cambios se presentan en los
archivos definidos a continuación (véase Tabla 4-2):
ARCHIVO DETALLE
ns-2.34/common/packet.h
Se define el método de acceso a la cabecera
del paquete BCHPE. Se incluye el paquete
BCHPE en la lista de paquetes reconocidos
por NS2. Define a BCHPE como protocolo de
enrutamiento. Define la palabra BCHPE para
identificar el protocolo en las trazas.
ns-2.34/trace/cmu-trace.h
Declaración de la función de registro de trazas
ns-2.34/trace/cmu-trace.cc
Inclusión de las librerías del encabezado del
paquete BCHPE. Implementación de la función
del registro de trazas. Obtención del
desplazamiento del encabezado BCHPE con
respecto al paquete
ns-2.34/tcl/lib/ns-packet.tcl
Agregar el encabezado del paquete BCHPE al
paquete general.
ns-2.34/tcl/lib/ns-lib.tcl Inicializar el agente de enrutamiento en el
entorno OTcl. Permitir la coexistencia de
BCHPE y otros protocolos de enrutamiento en
el caso de que exista una estación base.
Definir el nodo como de tipo BCHPE. Enlazar
los agentes de los nodos con el protocolo de
enrutamiento, en este caso BCHPE.
ns-2.34/tcl/lib/ns-mobilenode.tcl
Implementación de las funciones en OTcl para
instanciar y relacionar el agente y el protocolo
de enrutamiento en el simulador.
ns-2.34/Makefile Incluir el código fuente para se que compile
con el simulador.Tabla 4-2. Inclusión de BCHPE en NS2
49
4.7 Proceso de Simulación
Una vez estudiado el contexto de la problemática, identificados los objetivos e
índices de medición y definido el sistema a modelar, se muestra el siguiente
proceso de simulación (Figura 4-7) a ejecutarse en la presente investigación.
Como se puede observar en la Figura 4-7, existen 3 fases secuenciales que
permiten realizar una etapa de:
Definición de escenarios
Simulación, y
Post-simulación.
Fases de Simulación
Representado por las flechas que definen la dirección, el origen y el destino.
Procesos
Los rectángulos con puntas redondeadas definen aquellos procesos que se
deben ejecutar, los mismos que poseen argumentos de entrada y generan
información que puede ser usada en otros procesos.
Entradas y Salidas
Los rectángulos definen toda la información que es requerida o el producto de
algún proceso.
Todo lo que se encuentra fuera del rectángulo mayor son elementos externos a
la versión del simulador utilizada, en la presente tesis se han agregado a la
herramienta de simulación el protocolo BCHP y su mejora el protocolo BCHPE;
se han utilizado herramientas y desarrollado programas para los procesos de
animación y obtención de resultados respectivamente.
Los elementos ubicados dentro del rectángulo mayor son aquellos procesos,
protocolos y herramientas que vienen integrados con el simulador NS2.
50
Figura 4-7. Proceso de simulación en NS2
51
4.7.1 Etapa de pre-simulación
Se realiza todo el trabajo previo necesario para satisfacer los requisitos de
entrada de la simulación. En esta estapa realizamos:
Análisis de la estructura y funcionamiento de NS2. Se realiza la
instalación, configuración y validación de la herramienta. Para mas
detalle de como se efectuó el proceso se puede revisar el ANEXO 1.
Descargar e instalar ns2.34.
Analizamos el código fuente de BCHP, usamos Eclipse Helius (The
Eclipse Foundation, 2012) como herramienta de desarrollo y
depuración. Para mayor detalle revisar el ANEXO 3. Eclipse
Helios, incluye la instalación de eclipse y como integrar la
herramienta ns2.34 dentro de eclipse.
Se ha desarrollado el protocolo de enrutamiento BCHPE y lo
adicionamos al simulador NS2. Para mas detalle se puede revisar el
ANEXO 4. Cambios en NS2 para incluir al protocolo BCHPE,
donde encontrarán el procedimiento completo de las rutas de archivos
que fueron modificados.
Se incluyó BCHPE al simulador.
Se ha definido los escenarios, que incluye: el tamaño del plano,
ubicación inicial de los nodos, el modelo de movilidad. Para generar la
topología que nos ayude a reflejar el modelo de movilidad, usamos la
herramienta scengen desarrollada por Li Quiming (Li, 2001).
Para poder definir los patrones de tráfico y la cantidad de conexiones
llevadas a cabo en la simulación, se ha usado la herramienta incluida
en NS2 denominada cbrgen, dentro del ANEXO 5. Configuración
de la topología se puede observar los comandos para definir tanto
los escenarios cono la cantidad de conexiones usadas en la presente
investigación.
Finalmente se ha generado la secuencia de comandos de simulación
en lenguaje OTcl. Es aquí donde se configuran las características
52
iniciales de los nodos, se inicializa el simulador, se llama a los
archivos que definen los escenarios y conexiones, se definen los
nombres para los archivos de salida donde se almacena la
información, para mas detalle revisar ANEXO 6. Archivo OTcl
usado en la simulación.
4.7.2 Etapa de simulación
Se ejecuta en secuencia de comandos una a una hasta el final. Instancia los
objetos de las clases definidas, instancia el simulador, instancia el
organizador. Dentro del ANEXO 4. Cambios en NS2 para incluir al
protocolo BCHPE, se encuentra en el apartado “Código de C++ para la
implementación del protocolo BCHPE” el código fuente de BCHPE.
4.7.3 Etapa de post-simulación
Incluye los siguientes procesos:
Para la animación de las simulaciones se utiliza la herramienta
network animator NAM (Hernandez & Márquez, 2005) propia del
simulador NS2. Esta herramienta toma como base el archivo nam de
animación generados en la simulación.
En el proceso de post-simulación se permite obtener un resultado del
comportamiento del protocolo. Con la ayuda de la programación en
awk para la generación de scripts, estos archivos se los puede
observar para mayor detalle en el ANEXO 7. Archivos awk para
los resultados.
Para mostrar en forma gráfica los resultados filtrados se usan gráficas
y tablas estadísticas. Para el desarrollo de esta tesis se usó
Tracegraph (Jaroslaw, 2007) y Excel, en el ANEXO 2. Tracegraph
se puede observar el proceso de instalación.
53
CAPÍTULO 5
VALIDACIÓN DE LA PROPUESTA
Con el propósito de que esta Tesis sea autocontenida, en este capítulo se
especifica en forma general los valores que son utilizados para cada uno de
los escenarios definidos. La validación del Protocolo de Enrutamiento
Proactivo BCHPE se hace mediante el proceso de simulación y posterior
análisis de resultados.
El objetivo principal de la simulación es analizar el comportamiento de los
protocolos de enrutamiento BCHP y BCHPE, por ello se ha creado para la
simulación con 9 escenarios variando para cada uno de ellos la cantidad de
nodos.
5.1 Definición de Escenarios
En este apartado se especifica de forma general la topología, atributos de
los nodos; así como también los valores que se usan para cada uno de los
escenarios definidos para la simulación.
Se ha tomado el mismo escenario usado para BCHP (Torres, 2011) para
hacer las comparaciones posteriores con BCHPE.
Como se puede observar en Tabla 5-1 se trabaja en un área plana de
1000m X 500m ya que este perímetro permite la generación de más de un
cluster. Para determinar el comportamiento de los protocolos en diferentes
cantidades de nodos se toman: 25, 30, 40, 50, 60, 70, 80, 90 y 100 nodos
con una duración de simulación de 100 segundos. Se trabaja en un área
plana sin obstáculos, con antenas Omnidireccionales. Para el análisis de
resultados y posterior comparación se toma los protocolos BCHP y BCHPE
54
Parámetros Valores ObservacionesÁrea desimulación
1000m x 500m Permite la generación de más de uncluster
Cantidad denodos
25, 30, 40, 50,60, 70, 80, 90,100
Para determinar el comportamientode los protocolos para diferentedensidad de nodos en los cluster.
Modelo demovilidad
Random WayPoint
Cantidad deconexiones
20
Tiempo desimulación
100 En segundos
Protocolos BCHP, BCHPEModelo depropagación
TwoRayGround Para escenarios planos y sinobstáculos
Tipo de antena OmnidireccionalTabla 5-1. Parámetros generales de la simulación
Figura 5-1. Captura de pantalla de un escenario con 100 nodos en el programa nam (TheNetwork Animator), aplicación que acompaña a NS y visualiza las simulaciones realizadas con
éste.
55
La Figura 5-1 muestra un ejemplo de como se han formado los clusters
(representados por las circunferencias) para una cantidad de 100 nodos con
el protocolo BCHPE en la herramienta nam del NS-2 en un tiempo
determinado.
Cada cluster posee su JC con su respectivo JCR, un NG que permite la
comunicación entre cluster, y los nodos NC que son miembros de toda la red
Ad Hoc.
Los nodos que se encuentran fuera es porque aún están indecisos y a su
vez esperan la pertinencia a nuevos clusters.
Esta herramienta permite observar como se da el tráfico en la red.
5.2 Resultados experimentales
Una vez concluida la ejecución de BCHPE se obtiene los archivos de trazas
que contienen toda la información referente al proceso de simulación, como
por ejemplo en que tiempo determinado nodo ha cambiado su estado. A
continuación se procede al análisis de resutados tomando en cuenta los
siguientes parámetros de medición:
Rendimiento
Tasa de envío de paquetes
Sobrecarga del protocolo
Pérdida de paquetes
Retardo promedio
Variación de retardo de paquetes
Para un mejor entendimiento de los resultados presentados en las gráficas
siguientes, se ha tomado el método de Proyección Exponencial (Flores,
2011) ya que los datos datos proporcionados crecen y decrecen en
proporción variable a lo largo del tiempo de la simulación, contrario a los
56
datos necesitados para una proyección lineal que deben ser tener un
crecimiento constante.
5.2.1 Rendimiento
Se refiere a la fracción de la capacidad del canal empleado en la transmisión
de datos. Es el total de paquetes recibidos por un destino.
Valores altos de throughput indican que la red presenta un buen rendimiento,
es decir realiza una entrega de paquetes confiable, por lo contrario valores
bajos indica que han habido pocas transmisiones en el intervalo de tiempo
dado o bien que no se ha conseguido realizar una entrega de paquetes
eficiente. = [ ] (5.1)
En donde:
TH, Throughput
Br, Bytes recibidos
Ts, Tiempo de simulación
Según (Torres, 2012) el establecimiento de clusters mejora el desempeño de
esta métrica. Se ha medido el rendimiento de toda la red para conexiones
TCP variando la densidad de los nodos entre 25, 30, 40,50, 60, 70, 80, 90 y
100.
Los valores presentados en la Figura 5-2 muestran el comportamiento del
tamaño de ventana TCP durante la transmisión desde el nodo origen (0) al
nodo destino (25) de los dos protocolos de enrutamiento jerárquico
simulados, es decir la cantidad de datos recibidos durante la conexión. El eje
de las ordenadas representa el tiempo de simulación y el eje de las
ordenadas la cantidad de datos recibidos. Se observa que el rendimiento
va incrementando a medida que aumenta el tiempo de la simulación, en el
57
caso de los 25, 40, 60, 90 y 100 nodos (Figuras 5.2, 5.4, 5.6, 5.9 y 5.10), los
protocolos BCHP y BCHPE mantienen un rendimiento promedio.
Figura 5-2. Rendimiento con 25 nodos
Figura 5-3. Rendimiento con 30 nodos
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción25 nodos
BCHP25TCP
BCHPE25TCP
Exponencial(BCHP25TCP)
Exponencial(BCHPE25TCP)
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
500
550
600
650
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción30 nodos
BCHP30TCP
BCHPE30TCP
Exponencial(BCHP30TCP)
Exponencial(BCHPE30TCP)
58
En las figuras 5-3 a la 5-9, se puede observar que hay unos picos en declive
y aumento que aparentan menor rendimiento en la recepción de paquetes
durante los primeros 20 segundos aproximadamente, esto es debido a que
la energía en esos tiempos de simulación para determinados nodos JC está
en decremento y por ende se produce un cambio de roles e inundación de
mensajes anunciando los nuevos estados de los nodos, sin embargo,
tomando en cuenta las líneas de tendencia, se observa que BCHPE para
estos casos, entre los 60 y 70 seguntos empieza una mejora significativa.
El rendimiento del protocolo BCHPE es mas estable por ser un protocolo
proactivo, aunque en términos generales BCHPE y BCHP mantienen un
rendimiento promedio, se puede apreciar que la tendencia es creciente para
este parámetro, a medida que que la tasa de transmisión promedio aumenta,
la variación del rendimiento también lo hace.
Figura 5-4. Rendimiento con 40 nodos
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción40 nodos
BCHP40TCP
BCHPE40TCP
Exponencial(BCHP40TCP)
Exponencial(BCHPE40TCP)
59
Figura 5-5. Rendimiento con 50 nodos
Figura 5-6. Rendimiento con 60 nodos
0 10 20 30 40 50 60 70 80 900
100
200
300
400
500
600
700
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción50 nodos
BCHP50TCP
BCHPE50TCP
Exponencial(BCHP50TCP)Exponencial(BCHPE50TCP)
0 10 20 30 40 50 60 70 80 900
100
200
300
400
500
600
700
tiempo de simulacion (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción60 nodos
BCHP60TCP
BCHPE60TCP
Exponencial(BCHP60TCP)
Exponencial(BCHPE60TCP)
60
Figura 5-7. Rendimiento con 70 nodos
Figura 5-8. Rendimiento con 80 nodos
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
500
550
600
650
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción70 nodos
BCHP70TCP
BCHPE70TCP
Exponencial(BCHP70TCP)Exponencial(BCHPE70TCP)
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
500
550
600
650
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción80 nodos
BCHP80TCP
BCHPE80TCP
Exponencial(BCHP80TCP)Exponencial(BCHPE80TCP)
61
Figura 5-9. Rendimiento con 90 nodos
Figura 5-10. Rendimiento con 100 nodos
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
500
550
600
650
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción90 nodos
BCHP90TCP
BCHPE90TCP
Exponencial(BCHP90TCP)Exponencial(BCHPE90TCP)
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
500
550
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción100 nodos
BCHP100TCP
BCHPE100TCP
Exponencial(BCHP100TCP)
Exponencial(BCHPE100TCP)
62
5.2.2 Tasa de envío de paquetes (Packet Delivery Ratio)
Es el resultado entre el número de paquetes enviados para el número de
paquetes recibidos
= % (5.2)
En donde:
TPE, Tasa de Paquetes Entregados
Pr, Paquetes recibidos
Pe, Paquetes enviados.
Se debe considerar que mientras más cercana a uno el protocolo es mejor.
Por lo tanto: ≥Partiendo de (5.2), se toma las siguientes consideraciones:
= → = (5.3)> → > (5.4)≫ → ≫ (5.5)
La cantidad de paquetes enviados varían en cada protocolo dependiendo del
tiempo de comunicación que realicen durante el lapso de periodo de
simulación. Se calcula en base a (5.2) donde la relación cociente expuesto
se multiplica por 100 para medir la eficiencia del protocolo en un tanto por
ciento.
Debido a que la formación y mantenimiento del cluster necesita el
intercambio de paquetes para mantener su información actualizada, se
puede ver en la Figura 5-11 que el protocolo de enrutamiento jerárquico
BCHPE tiene una tasa de envío de aproximadamente 1.25% mayor que
BCHP. Cuando se utilizan conexiones TCP (Ver Figura 5-12), en BCHPE la
tasa es mejor que el protocolo BCHP.
63
Con lo antes mencionado, a medida que va aumentando la densidad de
nodos se puede concluír que el protocolo proactivo BCHPE es mejor en
comparación al protocolo BCHP.
Figura 5-11. Tasa de envío de paquetes
Figura 5-12. Tasa de envío de paquetes de aplicación TCP
0123456789
1011
25 n
odos
30 n
odos
40 n
odos
50 n
odos
60 n
odos
70 n
odos
80 n
odos
90 n
odos
100
nodo
s
prom
edio
byt
es e
nvia
dos
Número de Nodos
Tasa promedio de paquetes enviadosPaquetes enviados / paquetes recibidos
BCHP
BCHPE
Lineal(BCHP)Lineal(BCHPE)
0.93
0.94
0.95
0.96
0.97
0.98
0.99
1
25 30 40 50 60 70 80 90 100
Paq
uete
s / s
egun
dos
Número de nodos
Tasa de envio de paquetes de aplicaciónpaquetes de aplicación recibidos / paquetes de aplicación enviados
BCHP
BCHPE
Exponencial(BCHP)
Exponencial(BCHPE)
64
TASA DE ENVIO DE PAQUETES DE APLICACIÓNREC/ENV
Nodos %BCHP %BCHPERelación
BCHPE vs BCHP(%)
25 nodos 98.4791 99.26 0.7809
30 nodos 97.6911 98.7354 1.0443
40 nodos 98.4024 98.7323 0.3299
50 nodos 95.9988 97.4656 1.4668
60 nodos 98.7345 98.7411 0.0066
70 nodos 96.9959 97.8406 0.8447
80 nodos 96.1768 98.3531 2.1763
90 nodos 95.7131 98.1668 2.4537
100 nodos 96.6626 98.8244 2.1618
Relaciónpromedio
97.20603333 98.4577 1.25166667%
Tabla 5-2. Relación Promedio de Paquetes enviados
La Tabla 5-2. Relación Promedio de Paquetes enviados, muestra los datos
cuantitativos para relacionar la mejora.
5.2.3 Sobrecarga del protocolo
La es el número total de paquetes de enrutamiento transmitidos
durante la simulación dividido para el número de paquetes de aplicación.
= (5.6)
Donde Pr representa la cantidad de paquetes recibidos y, Pt representa la
cantidad de paquetes transmitidos.
Este indicador mide que tan eficiente es un protocolo de enrutamiento Ad
Hoc. Mientras cercano a 1 es su valor, el protocolo es más eficiente.
Como se puede observar en la Figura 5-13, el protocolo de enrutamiento
jerárquico proactivo BCHPE (con un valor promedio de 1.29) es más
eficiente que BCHP (con un valor promedio de 1.52) debido al uso del cluster
65
de respaldo y su estado de energía en la disminución del intercambio de
información para el mantenimiento del cluster, además, a medida que
aumenta la densidad de nodos en la red, el protocolo BCHPE se
desenvuelve mejor (con un valor promedio de 0.22) ya que los clusters se
hacen más estables geográficamente. (Ver Tabla 5-3. Relación Promedio de
Sobrecarga del Protocolo)
Figura 5-13. Sobrecarga del protocolo tipo TCP
SOBRECARGA DEL PROTOCOLO
Nodos BCHP BCHPE bchp-bchpe
25 nodos 1.125366649 1.058969841 0.066396807
30 nodos 1.158031569 1.141646568 0.016385001
40 nodos 1.204356071 1.153863636 0.050492435
50 nodos 1.556460761 1.370302177 0.186158584
60 nodos 1.17528608 1.18667921 -0.01139313
70 nodos 1.522598106 1.468036949 0.054561157
80 nodos 1.817312914 1.362577316 0.454735598
90 nodos 2.281547139 1.553021124 0.728526015
100 nodos 1.858162445 1.401942 0.456220445
RelaciónPromedio
1.522124637 1.29967098 0.222453657
Tabla 5-3. Relación Promedio de Sobrecarga del Protocolo
0
0.25
0.5
0.75
1
1.25
1.5
1.75
2
2.25
2.5
25 30 40 50 60 70 80 90 100
Tiem
po
Número de Nodos
Promedio de sobrecarga del protocoloPaquetes de enrutamiento / Paquetes de aplicación
BCHP
BCHPE
Exponencial(BCHP)Exponencial(BCHPE)
66
5.2.4 Pérdida de paquetes
Es la cantidad de paquetes eliminados por los nodos intermedios a causa de
los efectos producidos por la movilidad de los nodos, expiración de
temporizadores, destinos inalcanzables o borrados por el protocolo ARP
(Address Resolution Protocol).
En la fórmula 5.7 (Noroño & Fermín, 2012), se puede apreciar la fórmula
para el cálculo de paquetes perdidos:
= − (5.7)
En donde:
PP, paquetes perdidos
paqTx, paquetes transmitidos
paqRx, paquetes recibidos
PAQUETES PERDIDOS
Nodos BCHP BCHPE Mejora BCHPE vsBCHP
(diferencia)25 1,5209 0,74 0,7809
30 2,3089 1,2646 1,0443
40 1,5976 1,2677 0,3299
50 4,0012 2,5344 1,4668
60 1,2655 1,2589 0,0066
70 3,0041 2,1594 0,8447
80 3,8232 1,6469 2,1763
90 4,2869 1,8332 2,4537
100 3,3374 1,1756 2,1618
Promedio depaquetesperdidos (%)
2,793967 1,542300 1,251667
Tabla 5-4. Relación Porcentaje promedio de paquetes perdidos
Como se muestra en la Tabla 5-4, y se puede apreciar en la Figura 5-14, el
protocolo BCHPE pierde menor cantidad de paquetes (1.54% promedio) en
relación a BCHP (2.79% promedio) para todas las densidades de nodos, por
67
lo cual la mejora promedio de BCHPE vs BCHP es del 1.25% en relación a
la pérdida de paquetes, los datos de porcentajes se pueden apreciar en la
Tabla 5-4. Relación Porcentaje promedio de paquetes perdidos.
Figura 5-14. Paquetes borrados
5.2.5 Retardo promedio (Average end to end delay)
El retardo promedio es una medida muy significativa para nuestro propósito
debido a que se desea enviar y recibir información acerca de la gestión de la
red lo más rápido posible. Mientras más cercano a cero el protocolo es
mejor.
La fórmula 5.8, se emplea para calcular el retardo pormedio de extremo a
extremo.
= ∑ ( − ) 100 [ ] (5.8)
En donde:
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
25 30 40 50 60 70 80 90 100
Tasa
de
pérd
ida
de p
aque
tes
Número de nodos
Paquetes borrados
BCHP
BCHPE
BCHP
BCHPE
68
D, Average and to end delayi, identificador del paqueten, Número de paquetes entregados exitosamenteTri, Tiempo de recepciónTsi, Tiempo de envío
En la Figura 5-15 con respecto al protocolo BCHPE (20.66%) el retardo
promedio de extremo es mucho mejor que BCHP (56.86%) para cualquier
densidad de nodos y se utiliza como tráfico conexiones con TCP.
Por lo tanto el protocolo proactivo BCHPE es más rápido al momento del
envío y recepción de información, y por ende mejor en un valor promedio del
35.6% con respecto al protocolo BCHP, este valor se puede apreciar en la
Tabla 5-5. Relación Retardo Promedio.
Figura 5-15. Retardo extremo a extremo tipo TCP
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
25 30 40 50 60 70 80 90 100
Tiem
po
Número de Nodos
Retardo promedio extremo a extremo
BCHP
BCHPE
Lineal(BCHP)Lineal(BCHPE)
69
RETARDO PROMEDIO
Nodos %bchp %bchpemejora
de%BCHPE vs
%BCHP25 nodos 45.7626 17.6352 28.1274
30 nodos 41.4978 14.8072 26.6906
40 nodos 45.6021 17.0179 28.5842
50 nodos 58.3592 17.602 40.7572
60 nodos 18.6628 17.492 1.1708
70 nodos 59.5314 29.1563 30.3751
80 nodos 76.779 19.5914 57.1876
90 nodos 68.1292 24.188 43.9412
100 nodos 92.4316 28.4795 63.9521
RelaciónRetardo
promedio56.30618889 20.6632778 35.6429111
Tabla 5-5. Relación Retardo Promedio
5.2.6 Variación de retardo de paquetes (Jitter)
Es la diferencia en el retardo entre comunicaciones extremo a extremo entre
paquetes seleccionados. Mientras más cercano a cero la viariación del
retardo, el protocolo es mejor.
La fórmula para la estimación del jitter es la siguiente (ver fórmula 5.9):
= (( ( ) ( )) ( ( ) ( )))(5.9)
con j > i . De donde:
recvtime (j), tiempo de recepción del paquete j
sendtime(j), tiempo de envío de paquete j
recvtime (j), tiempo de recepción del paquete i
sendtime(j), tiempo de envío de paquete i
70
En una red Ad Hoc, el jitter sirve para medir la estabilidad y la convergencia
de la red. Como se puede observar en la Figura 5-16, se ha obtenido el
promedio de la variación del retardo de paquetes (Average Packet Delay
Variation) para toda la red. Los protocolos de enrutamiento jerárquico
funcionan mejor que los reactivos. El protocolo BCHPE con un promedio
global de retardo del 0.69% funciona mejor que BCHP con un promedio
global del 0.41% para todas las densidades de nodos analizadas en la
presente investigación. Con lo antes mencionado se puede establecer que el
protocolo BCHPE mantiene una mejora del 0.28% con respecto al protocolo
BCHP en la variación de retardo del paquete.Los valores de porcentajes se
pueden apreciar en la Tabla 5-6. Relación de Variación Retardo Promedio.
Figura 5-16. Variación de retardo del paquete tipo TCP
0
0.002
0.004
0.006
0.008
0.01
0.012
0.014
25 30 40 50 60 70 80 90 100
Tiem
po
Número de Nodos
Promedio de variación de retardo del paquete
BCHP
BCHPE
Lineal(BCHP)Lineal(BCHPE)
71
VARIACIÓN DEL RETARDO DEL PAQUETE
Nodos BCHP % BCHPE %RELACIÓNBCHP VSBCHPE
25 nodos 0.3426 0.85 0.504
30 nodos 0.3272 0.80 0.4719
40 nodos -0.0327 0.35 0.3778
50 nodos 1.1236 1.25 0.1267
60 nodos -0.0763 0.21 0.2889
70 nodos 0.5165 0.70 0.1804
80 nodos 0.1676 0.30 0.137
90 nodos 0.5676 0.95 0.3813
100 nodos 0.7721 0.84 0.07
Relación retardopromedio (%)
0.412022222 0.69 0.282
Tabla 5-6. Relación de Variación Retardo Promedio
72
CONCLUSIONES Y LÍNEAS DETRABAJOS FUTUROS
Hoy en día el estudio de los protocolos de enrutamiento de las redes ah doc
son un tema de creciente interés, donde no hay soluciones cerradas. Las
mejoras que se puedan adaptar a los mismos para un mayor rendimiento y
disponibilidad de las redes son el objetivo principal.
Una vez se han obtenido los resultados en la validación y verificación del
protocolo a través de la simulación, este capítulo surge de la reflexión acerca
del trabajo realizado.
Conclusiones
A partir de los resultados analizados en el Capítulo 5 se determinan
cualitativamente y cuantitativamente las prestaciones de los protocolos
BCHP y BCHPE en términos de eficiencia de encaminamiento. Esta
evaluación de prestaciones se efectúa a través de tres parámetros clave en
una red ad hoc inalámbrica: topología, número de nodos y tiempo de
simulación. A continuación se enuncian las principales conclusiones de
manera sintetizada:
Se ha implementado un nuevo protocolo de enrutamiento jerárquico
proactivo denominado Backup Cluster Head Protocol Enhanced
(BCHPE). BCHPE incluye límite de uso de la batería del nodo Jefe de
Cluster para obtener la mejora de la disponibilidad y convergencia de
la red comparado con BCHP; de esta manera el Jefe de Cluster de
Respaldo actúa de forma proactiva.
Se demostró mediante simulación que BHCPE mejora la
disponibilidad y convergencia de la red comparado con el protocolo
73
BCHP al tomar en cuenta el análisis para las tazas de medición que
se hizo en el capítulo anterior.
En resumen se puede decir que se ha cumplido con los objetivos propuestos
en la presente tesis, esto es:
Se ha logrado mejorar la convergencia de la red usando una estrategia
proactiva a través del protocolo de enrutamiento jerárquico proactivo
Backup Cluster Head Protocol Enhanced (BCHPE).
Se ha demostrado mediante simulación que el funcionamiento de BCHPE
con el uso de la estrategia proactiva del consumo de energía de los
clusters mejora la disponibilidad de la red
En cuanto al rendimiento en recepción de datos, el protocolo BCHPE es
mejor en comparación a BCHP, como se puede apreciar en la Figuras de
la 5.2 a la 5.10, ya que debido a la actualización contínua que se hace de
los JCs de cada cluster, la red mantiene mayor estabilidad en un
promedio a partir del segundo 60.
BCHPE pierde la menor cantidad de paquetes (con un valor corto del
1.25%) en comparación a BCHP como se puede apreciar en la Tabla 5-4.
Relación Porcentaje promedio de paquetes perdidos.)
BCHPE es más rápido al momento del envío y recepción de información,
y por ende mejor en un valor promedio del 35.64% con respecto al
protocolo BCHP como se puede apreciar en la Tabla 5-4.
BCHPE mantiene una mejora del 0.28% en un promedio global de
retardo comparado con BCHP como se puede apreciar en la Tabla 5-5.
BCHPE por ser un protocolo de enrutamiento jerárquico proactivo es más
eficiente, mantiene una mejora (con un valor promedio de 0.22) en la
sobrecarga en comparación con BCHP como se puede apreciar en la
Tabla 5-6.
74
Líneas Futuras
El ámbito de las redes ad hoc inalámbricas propicia una gran variedad de
aspectos a explorar. Las propias limitaciones inherentes a este tipo de redes
ofrecen numerosas posibilidades de investigación.
Esta tesis aborda algunos problemas de investigación que se encuentran
abiertos dentro de las redes móviles Ad Hoc, quedando algunas cuestiones
por resolver. Desde el punto de vista de la presente investigación tenemos:
Se pueda implementar el protocolo proactivo BCHPE en dispositivos
móviles reales para contrastar con los resultados favorables obtenidos en
el presente trabajo de investigación, ya que la simulación permitió
enfocarse en las funcionalidades sin tomar en cuenta variables propias
de un ambiente real.
La Implementación de una herramienta capáz de hacer un análisis de
consumo de energía de los nodos contrastando con varios escenarios al
mismo tiempo.
La aplicabilidad del presente trabajo de investigación es una base para
aplicaciones que permitan, por ejemplo en situaciones de emergencia y
rescate, establecer las rutas adecuadas de escape y la recuperación de
victimas.
Implementación Óptima de BCHPE.
75
ANEXOSInstalación y configuración de herramientas
76
ANEXO 1. Descargar e instalar ns2.34
Se lo puede descargar de la siguiente página:
http://sourceforge.net/projects/nsnam/files/allinone/ns-allinone-2.34/ns-allinone-2.34.tar.gz/download
Copiar el archivo al directorio donde se va a instalar y descomprimirlo,
luego ir al directorio ns-allinone-2.34.tar.gz
$ tar -xzvf ns-allinone-2.34.tar.gz$ cd ns-allinone-2.34$ sudo apt-get install build-essential autoconf automake libxmu-dev gcc-4.3
Ya que OTcl no funciona con la versión de gcc instalado por defecto
en Lucid, hay que ir al directorio ns-allinone-2.34/otcl-1.13, en
Makefile.in buscar la línea que dice:
CC= @CC@
y cambiar por la siguiente:
CC= gcc-4.3
Figura ANEXO -1. Cambio de variables de entorno
Instalar y Ejecutar el siguiente comando: $./install
Configuración de variables de entorno
Añadir las siguiente líneas al final dentro del archivo bashrc.
Remplazar “home/proyecto/tesis/” por el directorio donde se instale el
ns-2.34.
77
$ gedit ~/.bashrc
# LD_LIBRARY_PATHOTCL_LIB=/home/proyecto/tesis/ns-allinone-2.34/otcl-1.13NS2_LIB=/home/proyecto/tesis/ns-allinone-2.34/libX11_LIB=/usr/X11R6/libUSR_LOCAL_LIB=/usr/local/libexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIBexportLD_LIBRARY_PATH=$LD_LIBRARY_PATH:$X11_LIB:$USR_LOCAL_LIB
# TCL_LIBRARYTCL_LIB=/home/proyecto/tesis/ns-allinone-2.34/tcl8.4.18/libraryUSR_LIB=/usr/libexport TCL_LIBRARY=$TCL_LIB:$USR_LIB
# PATHXGRAPH=/home/proyecto/tesis/ns-allinone-2.34/bin:/home/proyecto/tesis/ns-allinone-2.34/tcl8.4.18/unix:/home/proyecto/tesis/ns-allinone-2.34/tk8.4.18/unix:/home/proyecto/tesis/ns-allinone-2.34/xgraph-12.1/NS=/home/proyecto/tesis/ns-allinone-2.34/ns-2.34/NAM=/home/proyecto/tesis/ns-allinone-2.34/nam-1.13/export PATH=$PATH:$XGRAPH:$NS:$NAM
Recargar el archivo con el siguiente comando:
$ source ~/.bashrc
Ejecutar el ns
$ns
Figura ANEXO -2. Ejecución de ns
La imagen muestra que se han configurado correctamente las variables de
entorno para ns, se debe digitar exit para salir.
78
Validación de la instalación
Dentro del directorio ns-allinone-2.34 digitar:
$ cd ns-2.34$ ./validate
La validación puede tomar algún tiempo. Al final de la validación debe
mostrar la información de la imagen Figura ANEXO -3 “all tests passed”:
Figura ANEXO -3. Validación satisfactoria de ns
Una vez realizados todos los pasos anteriosres se tiene instalado
correctamente el ns-2.34.
79
ANEXO 2. Tracegraph
Tracegraph (Jaroslaw, 2007), es una herramienta libre que sirve para
analizar archivos de traza desarrollados en el simulador ns-2 convirtiendo las
trazas en graficas, para que la herramienta se ejecute se debe instalar
librerías de Matlab, también existe una herramienta denominada Trace
converter1, que se ha utilizado para convertir los archivos de traza a un
formato compatible con la herramienta Tracegraph, debido al formato
complejo de la misma. En la herramienta se puede graficar los parámetros
de evaluación antes mencionados con los datos obtenidos de la traza.
Descarga de los instaladores
Se debe descargar el instalador de tracegraph 2.02 y mglinstaller
(librerías de matlab)
Links de descarga:http://www.mediafire.com/?z0o0ma44ovb8ohjhttp://www.mediafire.com/?c9735hyvbnrdc1e
Instalación de tracegraph y librerás en matlab
Descomprimir el instalador de tracegraph (Por lo general en el
directorio ns-allinone-2.34)
$ tar -xvf /home/usuario/tracegraph202linux.tar
1 Descargar desde: http://www.tracegraph.com/traceconverter.html
80
Figura ANEXO -4. Extracción del instalador de tracegraph
Copiar el archivo mglinstaller.gz al directorio donde se instale
mglinstaller*
$ cp mglinstaller.gz /ns-allinone-2.34/tracegraph/tracegraph202/
Seguidamente se descomprime y se ejecuta los siguientes comandos:
$ gunzip mglinstaller.gz$ ./mglinstaller
Figura ANEXO -5. Extracción de librerías matlab
Después de instalar las librerías de matlab se edita el path .bashrc
con el comando:
$ gedit ~/.bashrc
Y se agregan las siguientes líneas tal como se muestra en la Figura
ANEXO -6 Edición de path ./bashrc
81
exportLD_LIBRARY_PATH=/home/usuario/tracegraph202/bin/glnx86/:$LD_LIBRARY_PATH
Figura ANEXO -6 Edición de path ./bashrc
Actualizar el path como se muestra a continuación con el comando
~/.bashrc:
Figura ANEXO -7 Actualización del Path
Finalmente se debe ejecutar el tracegraph, dentro del directorio
tracegraph202 con el comando que se muestra en la Figura
ANEXO -8:
Figura ANEXO -8. Ejecutar tracegraph
Errores de instalación
Es muy posible que durante la ejecución de tracegraph salga el
siguiente error:
82
ERROR: failed to find MEX-File on path : cellfun.mexglx
Debemos localizar el archivo cellfun.mexglx con el comando:
$ sudo locate cellfun.mexglx
En caso de no encontrarse este archivo, generalmente se localiza en
el directorio de instalación de tracegraph 2.0.2:
/tracegraph202/toolbox/matlab/datatypes/
Una vez encontrado el archivo se copia hacia el directorio de
tracegraph 2.0.2:
cp /usr/local/src/ns-allinone-2.34/tracegraph/tracegraph202/toolbox/matlab/datatypes/cellfun.mexglx /home/proyecto/tesis/ns-allinone-2.34/tracegraph/tracegraph202/
Finalmente se vuelve a ejecutar el tracegraph como se muestra en la
Figura ANEXO -8, y en la Figura ANEXO -9 se muestra la ventana
principal del tracegraph.
Figura ANEXO -9 Interfaz de Tracegraph
83
ANEXO 3. Eclipse Helios
Pasos previos a la instalación
Para instalar Java en Ubuntu ejecutamos el siguiente comando en la
terminal:
………………..sudo apt-get install sun-java6-jdk……………….
Esto descargará internamente los paquetes requeridos y los instalará en el
computador.
Se debe actualizar la versión del java puesto que está funcionando
con la GNU y no la SUN
…………..sudo update-java-alternatives –s java-6-sun…………..
Verificar que la versión de java esté instalado
Figura ANEXO -10 Verificación de la versión de java instalada
Descarga, instalación y creación de proyecto ns-2.34
Se ocupa eclipse helios para sistema operativo Ubuntu 10.04 de 32 bits, la
descarga se la puede hacer de la página oficial de la comunidad de eclipse
en el siguiente enlace
84
http://www.eclipse.org/downloads/packages/release/helios/sr2
Figura ANEXO -11. Página oficial para descarga de Eclipse
Una vez descargado el eclipse se procede a descomprimir el
instalador y copiarlo dentro del directorio que desee tipiando el
siguiente comando:
Figura ANEXO -12. Descomprimir eclipse
Entrar al directorio de eclipse y proceder con la ejecución (./eclipse)
como se muestra en la Figura ANEXO -13
Figura ANEXO -13. Instalación de eclipse
Ya ejecutado eclipse, muestra la pantalla de presentación
Figura ANEXO -14 Instalación de eclipse
85
Se debe seleccionar el espacio de trabajo, en este caso se ha
seleccionado el directorio de ns-allinone-2.34 para el presente trabajo
de investigación:
Figura ANEXO -15 Entorno de trabajo
A continuación aparece la página de inicio de eclipse listo para trabajar.
Figura ANEXO -16 Ventana de inicio de Eclipse
Creamos un nuevo proyecto
Vamos a la opción de:
Archivo ->Nuevo -> Proyecto C++
Y nos aparece la siguiente pantalla de la Figura ANEXO -17, se debe dar el
nombre al proyecto, es este caso es ns-2.34 la misma que ya existe dentro
del directorio de trabajo escogido previamente. Además se debe tener en
cuenta que se debe escoger un proyecto en blanco que trabaje con el
compilador de C para Linux “Linux GCC”, Hacer click en “siguiente” y luego
“finalizar”. De esta manera queda agregado el nuevo proyecto
86
Figura ANEXO -17 Dando nombre al proyecto ns-2.34
Finalmente en el Explorador de proyectos de eclipse aparece
agregado el Nuevo Proyecto “ns-2.34” y se carga todo el contenido de
la carpeta del proyecto por primera vez automáticamente.
Figura ANEXO -18. Proyecto ns-2.34 cargado en eclipse
Configuración para la ejecución con ns2
Se procede con las configuraciones de ejecución para lo cual vamos a
las siguiente opción:
87
Ejecutar -> Configuraciones de ejecución…
Con lo cual muestra la pantalla de la Figura ANEXO -19, se debe tomar en
cuenta que se debe escoger la opción de C/C++ Application para que se
cargue el proyecto. Seguidamente se debe verificar que en la Pestaña de
“Principal” en la opción Proyecto esté cargado ns-2.34, en caso de no estar
se debe poner la opción de Examinar y escoger el proyecto
Figura ANEXO -19. Configuración de ejecución
Ahora en la opción C/C++ Application damos click en “search Project”
y presenta una nueva pantalla (Figura ANEXO -20) con algunas
opciones de las cuales se debe escoger “ns” y damos click en
Aceptar.
Nota: Si la opción “ns” no está en la lista se debe a que está mal instalado el
ns-allinone-2.34 o se encuentra mal cargado dentro de Eclipse.
88
Figura ANEXO -20. Ejecutable de ns
Aparece en la opción C/C++ Application la variable de ejecución “ns”,
se da click en “Aplicar” y luego “Cerrar”
Figura ANEXO -21. Ejecutable de ns
Finalmente se manda a ejecutar el proyecto y en la parte de consola
se muestra el signo “%” indicando que ns se está ejecutando
exitosamente.
89
Figura ANEXO 22. ns ejecutándose correctamente
De esta forma queda integrado ns2 con eclipse helios y se puede empezar a
trabajar.
ANEXO 4. Cambios en NS2 para incluir al protocolo BCHPE
ns-2.34/common/packet.h
Para definir el método de acceso a la cabecera del paquete BCHPE.
………..
#define HDR_BCHPE(p) (hdr_bchpe::access(p)) // Added Proyecto………..
Incluir a BCHPE en la lista de paquetes reconocidos por NS2.
………..
90
// AOMDV packetstatic const packet_t PT_AOMDV = 61;
// Bchp packet Added Proyectostatic const packet_t PT_BCHP = 62;
// Bchpe packet Added Proyectostatic const packet_t PT_BCHPE = 63;
// CBRP packet Added Proyectostatic const packet_t PT_CBRP = 64;………..
Definir a BCPE como protocolo de enrutamiento.
………..static packetClass classify(packet_t type) {if (type == PT_DSR ||type == PT_MESSAGE ||type == PT_TORA ||type == PT_AODV ||type == PT_HAMAN ||type == PT_CBRP|| // Added Proyectotype==PT_BCHP|| // Added Proyectotype==PT_BCHPE) // Added Proyectoreturn ROUTING;………..
Define la palabra BCHPE para identificar el protocolo en las trazas.
..……..name_[PT_AODV]= "AODV";name_[PT_HAMAN]= "HAMAN";name_[PT_CBRP]= "CBRP"; // Added Proyectoname_[PT_CBRP]= "BCHP"; // Added Proyectoname_[PT_CBRP]= "BCHPE"; // Added Proyecto………..
ns-2.34/trace/cmu-trace.h
Declaración de la función de registro de trazas.
………..
91
void format_cbrp(Packet *p, int offset); // CBRP Added Proyectovoid format_haman(Packet *p, int offset);void format_bchp(Packet *p, int offset); //Bchp Added Proyectovoid format_bchpe(Packet *p, int offset); // Bchpe Added Proyecto………..
ns-2.34/trace/cmu-trace.cc
Inclusión de las librerías del encabezado del paquete BCHPE.
………..#include <aodv/aodv_packet.h> //AODV#include <cbrp/hdr_cbrp.h> // BCHPE Added Proyecto#include <bchp/hdr_bchp.h> // BCHP Added Proyecto#include <bchpe/hdr_bchpe.h> // BCHPE Added Proyecto
// AOMDV patch#include <aomdv/aomdv_packet.h>………..
Implementación de la función de registro de trazas
voidCMUTrace::format_bchpe(Packet *p, int offset){
hdr_bchpe *bchpeh = HDR_BCHPE(p); //hdr_ip *iph = HDR_IP(p);
sprintf(pt_->buffer() + offset,"[%d #%d %d->%d] [%d #%d %d %d %d->%d] [%d %d] [%d %d %d %d->%d]",
bchpeh->route_request(),bchpeh->rtreq_seq(),iph->saddr(),bchpeh->request_destination(),bchpeh->route_reply(),bchpeh->rtreq_seq(),bchpeh->route_reply_len(),// the dest of the src routebchpeh->reply_addrs()[bchpeh->route_reply_len()-1].addr,bchpeh->reply_addrs()[0].addr,iph->daddr(),bchpeh->route_shortened(),bchpeh->route_repaired(),
92
bchpeh->route_error(),bchpeh->num_route_errors(),bchpeh->down_links()[bchpeh->num_route_errors() - 1].tell_addr,bchpeh->down_links()[bchpeh->num_route_errors() - 1].from_addr,bchpeh->down_links()[bchpeh->num_route_errors() - 1].to_addr);
}………..
Obtención del desplazamiento del encabezado BCHPE con respecto
al paquete.
………..case PT_BCHPE:format_bchpe(p, offset);break;………..
ns-2.34/tcl/lib/ns-lib.tcl
Inicializar el Agente de enrutamiento en el entorno OTcl.
………..AODV {
set ragent [$self create-aodv-agent $node]}
# Added ProyectoCBRP {
$self at 0.0 "$node start-cbrp"}
AOMDV {set ragent [$self create-aomdv-agent $node]}
}# Added ProyectoBCHP {
$self at 0.0 "$node start-bchp"}# Added ProyectoBCHPE {
$self at 0.0 "$node start-bchpe"}
# FIN ProyectoTORA {
93
Simulator set IMEPFlag_ ONset ragent [$self create-tora-agent $node]
}………..
Permitir la coexistencia de BCHPE y otros protocolos de enrutamiento
en el caso de que exista una estación base.
………..# Bind routing agent and mip agent if existing basestation# address setting# Added Proyectoif { [info exist wiredRouting_] && $wiredRouting_ == "ON" } {
if { $routingAgent_ != "DSR" && $routingAgent_ != "CBRP" &&$routingAgent_ != "BCHP" && $routingAgent_ != "BCHPE" } {$node mip-call $ragent}}………..
Definir el nodo como tipo BCHPE
elseif { $routingAgent_ == "CBRP" } { # Added Proyectoset nodeclass CBRPNode
} elseif { $routingAgent_ == "BCHP" } { # Added Proyectoset nodeclass BCHPNode
} elseif { $routingAgent_ == "BCHPE" } { # Added Proyectoset nodeclass BCHPENode
} else {set nodeclass Node/MobileNode}return [eval new $nodeclass $args]………..
Enlazar los agentes de los nodos con el protocolo de enrutamiento, en
este caso BCHPE.
………..if {$routingAgent_ != "DSR" && $routingAgent_ != "CBRP" && $routingAgent_!= "BCHP" && $routingAgent_ != "BCHPE" } {$node attach $ragent [Node setrtagent_port_] }………..
94
ns-2.34/tcl/lib/ns-mobilenode.tcl
Implementación de las funciones en OTcl para instanciar y relacionar
el agente y el protocolo de enrutamiento en el simulador.
## BCHP Added Proyecto#Class BCHPENode -superclass Node/MobileNode
BCHPENode instproc init {args} {$self instvar bchpe_agent_ dmux_ entry_point_ address_set ns_ [Simulator instance]eval $self next $args ;# parent class constructor}if {$dmux_ == "" } {
# Use the default mash and shiftset dmux_ [new Classifier/Port]
}set bchpe_agent_ [new Agent/BCHPE]$bchpe_agent_ ip-addr $address_$bchpe_agent_ set myaddr_ $address_$bchpe_agent_ node $self$self addr $address_puts "Creating node $address_";if { [Simulator set RouterTrace_] == "ON" } {
# Recv Targetset rcvT [$self mobility-trace Recv "RTR"]
set namfp [$ns_ get-nam-traceall]if { $namfp != "" } {
$rcvT namattach $namfp}
$rcvT target $bchpe_agent_set entry_point_ $rcvT
} else {# Recv Targetset entry_point_ $bchpe_agent_
}$self set ragent_ $bchpe_agent_}$bchpe_agent_ target $dmux_# packets to the DSR port should be dropped, since we've# already handled them in the DSRAgent at the entry.set nullAgent_ [$ns_ set nullAgent_]$dmux_ install [Node set rtagent_port_] $nullAgent_
95
# $dmux_ install $opt(rt_port) $bchpe_agent_# BCHPENodes don't use the IP addr classifier. The DSRAgent should# be the entry point$self instvar classifier_set classifier_ "BCHPENode made illegal use of classifier_"return $self
}BCHPENode instproc start-bchpe {} {
$self instvar bchpe_agent_$bchpe_agent_ startbchpe# if {$opt(cc) == "on"}# checkcache $bchpe_agent_
}BCHPENode instproc entry {} {
$self instvar entry_point_return $entry_point_
}BCHPENode instproc add-interface args {# args are expected to be of the form# $chan $prop $tracefd $opt(ll) $opt(mac)
eval $self next $args$self instvar bchpe_agent_ ll_ mac_ ifq_set ns_ [Simulator instance]$bchpe_agent_ mac-addr [$mac_(0) id]
if { [Simulator set RouterTrace_] == "ON" } {# Send Targetset sndT [$self mobility-trace Send "RTR"]
set namfp [$ns_ get-nam-traceall]if {$namfp != "" } {
$sndT namattach $namfp}
$sndT target $ll_(0)$bchpe_agent_ add-ll $sndT $ifq_(0)
} else {# Send Target$bchpe_agent_ add-ll $ll_(0) $ifq_(0)
}# setup promiscuous tap into mac layer$bchpe_agent_ install-tap $mac_(0)
}BCHPENode instproc reset args {
$self instvar bchpe_agent_eval $self next $args
96
$bchpe_agent_ reset}………..
ns-2.34/Makefile
Incluir el código fuente para que se compile con el simulador.
………..bchp/bchpagent.o bchp/bchpntable.o bchp/hdr_bchp.o \bchpe/bchpeagent.o bchpe/bchpentable.o bchpe/hdr_bchpe.o \cbrp/cbrpagent.o cbrp/ntable.o cbrp/hdr_cbrp.o \………..
Código de C++ para la implementación del protocolo BCHPE
Estas librerías han sido tomadas de la implementación del protocolo BCHP,
sin embargo la implementación de los procesos y funciones han sido
modificadas para su uso dentro del protocolo BCHPE, son colocadas en los
anexos para mejorar la lectura del presente trabajo de investigación.
Definición del Agente
/* bchpeagent.h */struct BCHPE_RtRepHoldoff { // Taken from DSR's implementation
ID requestor;ID requested_dest;int best_length;int our_length;
};struct BCHPE_SendBufEntry {Time t; // insertion timeBCHPE_Packet p;
};class BCHPE_SendBufferTimer : public TimerHandler { //Taken from DSR'simplementationpublic:BCHPE_SendBufferTimer(BCHPE_Agent *a) : TimerHandler() { a_ = a;}void expire(Event *e);
protected:
97
BCHPE_Agent *a_;};class BCHPE_Agent : public Tap, public Agent {friend class ENeighborTable;friend class ENeighborTablePeriodicHandler;friend class ENeighborTableTimeoutHandler;friend class ENeighborTableCFormationHandler;friend class ENeighborTableCContentionHandler;friend class BCHPE_SendBufferTimer;public:
BCHPE_Agent();virtual int command(int argc, const char * const * argv);virtual void recv(Packet *, Handler* callback = 0);void Terminate(void);void lost_link(Packet *p);static int no_of_clusters_ ;
// Jinyang It prints out how many clusters that have been formed in total
void tap(const Packet *p);protected:
void process_cluster_update(Packet * p);void forwardSRPacket(Packet *);void startUp();void trace(char* fmt, ...);void tracepkt(Packet *, double, int, const char *);Trace *logtarget; // Trace TargetPriQueue *ll_queue; // link level output queueMobileNode* node_;int myaddr_; // My address...int myclusterid_ ; // Identificador del cluster ID Added RT ene/2011int be_random_;ENeighborTable *ntable; // Randomness/MAC/logging parameters used
// in DSR's implementationint use_mac_;int verbose_;int trace_wst_;private:int off_mac_;int off_ll_;int off_ip_;int off_bchpe_;ID net_id, MAC_id; // our IP addr and MAC addrNsObject *ll; // our link layer outputPriQueue *ifq; // output interface queue/******** internal state ********/
98
BCHPE_SendBufferTimer send_buf_timer;BCHPE_SendBufEntry send_buf[SEND_BUF_SIZE];RequestTable request_table;RouteCache *route_cache;int route_request_num; // number for our next route_request//below codes r inherited from DSR for dealing with route errorsbool route_error_held; // are we holding a rt err to propagate?ID err_from, err_to; // data from the last route err sent to usTime route_error_data_time; // time err data was filled in
void handlePktWithoutSR(BCHPE_Packet& p, bool retry);void handlePacketReceipt(BCHPE_Packet& p);void handleForwarding(BCHPE_Packet& p);void handleRREQ(BCHPE_Packet &p);int handleRREP(BCHPE_Packet &p);bool ignoreRouteRequestp(BCHPE_Packet& p);void sendOutPacketWithRoute(BCHPE_Packet& p, bool fresh, Time delay = 0.0);void sendOutRtReq(BCHPE_Packet &p, int max_prop = MAX_SR_LEN);void getRouteForPacket(BCHPE_Packet &p, bool retry);void acceptRREP(BCHPE_Packet &p);void returnSrcRouteToRequestor(BCHPE_Packet &p);bool replyFromRouteCache(BCHPE_Packet &p);void processBrokenRouteError(BCHPE_Packet& p);void xmitFailed(Packet *pkt);void undeliverablePkt(Packet *p, int mine);void dropSendBuff(BCHPE_Packet &p);void stickPacketInSendBuffer(BCHPE_Packet& p);void sendBufferCheck();void sendRouteShortening(BCHPE_Packet &p, int heard_at, int xmit_at);void BroadcastRREQ(BCHPE_Packet &p);int UnicastRREQ(BCHPE_Packet &p, nsaddr_t nextcluster);void fillBCHPEPath(Path &path, hdr_bchpe *&bchpeh);
void testinit();friend void BCHPE_XmitFailureCallback(Packet *pkt, void *data);friend int BCHPE_FilterFailure(Packet *p, void *data);
};
Tablas de enrutamiento
Archivo bchpentable.h
99
class ntable_ent {public:ntable_ent() { bzero(this, sizeof(struct ntable_ent));}nsaddr_t neighbor; //target nodeuint neighbor_status; /*whether neighbor is a cluster member, head or
undecided…. si el prójimo es un miembro del clúster, jefe o indeciso. */uint link_status; /* whether the link with this neighbor is bidirectional
or unidirectional link.si el vínculo con este vecino es el enlace bidireccional o
unidireccional. */double last_update; //last update time for this entry // tiempo de la última
actualización de esta entradaPacket* n_pkt;Event* timeout_event; //time out event sent out //el tiempo de espera de
eventos enviadosntable_ent *next; //pointer to the next entry //puntero a la entrada
siguientedouble nseid; //addeddouble iEnergy; //Proyectodouble posx; //Proyectodouble posy; //Proyecto
};
class nexthop_ent {public:nexthop_ent() { bzero(this,sizeof(struct nexthop_ent)); }nsaddr_t next_node;Event* timeout_event;nexthop_ent *next;
};class adjtable_ent {public:adjtable_ent() { bzero(this, sizeof(struct adjtable_ent));}nsaddr_t neighbor_cluster; //the neighboring cluster headnexthop_ent *next_hop; //the next hop node in order to reach neighbor_clusteradjtable_ent *next; //pointer to the next adjtable_ent
};class nextnode {public:nextnode() {bzero(this,sizeof(struct nextnode));}nsaddr_t the_node;nsaddr_t dest_status;double last_updated;
};
100
class ENeighborTable {friend class ENeighborTablePeriodicHandler; //The handler function inside is// invoked periodically to send out BROADCAST messagesfriend class ENeighborTableTimeoutHandler; // The handler function inside is// invoked to remove outdated neighbortable entryfriend class ENeighborTableCFormationHandler; // The handler function is invoked// to perform cluster formation algorithm.friend class ENeighborTableCContentionHandler; // The handler function is invoked// to resolve cluster head contention
friend class BCHPE_Agent;public:
ENeighborTable(BCHPE_Agent *a_);void AddUpdateEntry(ntable_ent *ent);int DeleteEntry(nsaddr_t dest);ntable_ent *GetEntry(nsaddr_t dest);bool isNeighbor(nsaddr_t addr);
void AddUpdateQuickAdj(nsaddr_t dest, uint dest_status, nsaddr_t next_node);nsaddr_t GetQuickNextNode(nsaddr_t dest);bool existsLink(nsaddr_t from, nsaddr_t to);
void AddUpdateAdj(nsaddr_t dest, nsaddr_t next_hop, int primary);void DeleteAdjEntry(nsaddr_t dest,int primary);adjtable_ent *GetAdjEntry(nsaddr_t dest_cluster, int primary);
int RemainingLoop();void InitLoop();ntable_ent *NextLoop();/** Added Proyecto* For Cluster_head_bakcup election*/ntable_ent *electCHB();Packet *getUpdatePacket();Packet *getBroadcastPacket();void processUpdate(Packet *);void startUp();
#ifdef BCHPE_DEBUGchar *printNeighbors();char *printHELLOpkt(Packet *p);char *PrintTwoHopNeighbors();
#endif
101
uint no_of_clusterheads;uint my_status; //whether I am undecided, cluster head, cluster bakcup head// or member onlyuint my_size; // Size of my neighbor table
nsaddr_t my_cluster_head; // used only by the cluster head backup// Added RT 9-02-2011nsaddr_t my_cluster_head_backup; // used only by the cluster head.// Added RT 9-2-2011uint backup_updates; // for backups updates maintenanceuint adjtable_size;
Event *periodic_event;Event *c_form_event;Event *c_contention_event;
ENeighborTablePeriodicHandler *periodic_handler;// ENeighborTableenergyHandler *energy_handler;ENeighborTableTimeoutHandler *timeout_handler;ENeighborTableCFormationHandler *c_formation_handler;ENeighborTableCContentionHandler *c_contention_handler;
protected:void lostClusterHeads();nextnode *adjtable;adjtable_ent *adjtable_1;adjtable_ent *adjtable_2;
private:BCHPE_Agent *a;ntable_ent *head;ntable_ent *prev;ntable_ent *now;ntable_ent *my_ch; // Used only by the Cluster Head. Added RT 9-2-2011ntable_ent *my_chb; // Used only by the Cluster Head Backup.
//Added RT 9-2-2011int in_contention;int maxelts;int ctr;double *last_update; // a supplementary table used to updating the main onedouble preenergy; //added Proyectodouble inicialenergy; // added Proyectodouble result_t;double result_r;
102
double r_i;double r_s;
//Proyectodouble trans;double prueba;double energia;double energyinicial;FILE* dumpFile;char dumpFileName[50];
};class ENeighborTablePeriodicHandler : public Handler {public:ENeighborTablePeriodicHandler(BCHPE_Agent *a_, ENeighborTable *t_);virtual void handle(Event *e);
private:ENeighborTable *t;BCHPE_Agent *a;Event *periodic_event_;
};
class ENeighborTableCFormationHandler : public Handler {public:ENeighborTableCFormationHandler(BCHPE_Agent *a_, ENeighborTable *t_);virtual void handle(Event *e);//int cont;
private:ENeighborTable *t;BCHPE_Agent *a;double preenergy; //addeddouble inicialenergy;//Proyecto//Proyecto 07-09-2012// uint my_status;
};
Archivo bchpentable.cc
Incluye las librerías para inclusión de la energía.
103
#include <string.h>#include <stdlib.h>#include <stdio.h>#include <assert.h>#include <random.h>#include <cmu-trace.h>#include "bchpeagent.h"#include "energy-model.h"
/*librerìa anexada para el control de energìa Proyecto* Hasta aquí anexo de librerías Proyecto 04-Agon-2012*/
class Phy;class WirelessPhy;double iEnergy = 0;
A continuación se efectúan las llamadas para la energía de los nodos
Packet *ENeighborTable::getBroadcastPacket() {
// periodically broadcast my own neighbor table to my neighbors// Difunden periódicamente mi propia tabla de vecinos de mis vecinosdouble b_time = 1.1 * BROADCAST_INTEVAL;
/* proyecto 25-JUL-2012* PONIENDO AQUÍ LA ENERGÍA ME ARROJA LOS VALORES
DE TODOS LOS NODOS PARA LOS CLUSTER_HEAD*/
// proyecto 30-JUL-2012FILE* dumpFile;
char dumpFileName[50]="bchpe_packet.txt";dumpFile = fopen(dumpFileName, "a");double energia1 = energia-a->node_->energy_model()->energy();
double energyinicial1 = energyinicial-a->node_->energy_model()->initialenergy();
trans = (a->node_->energy_model()->et());result_t=(a->node_->energy_model()->et())+result_t;double rec=(a->node_->energy_model()->er());result_r=(a->node_->energy_model()->er())+result_r;double nombre = a->myaddr_;r_i=(a->node_->energy_model()->ei());r_s=(a->node_->energy_model()->es());
104
fprintf(dumpFile, "-Nodo: %f + -inicial energy: %.6f + -Energy %.6f + -estado:%i: + t %f + r %f\n", nombre, energyinicial1 , energia1, (int)(my_status), trans, rec);
fclose(dumpFile);// proyecto 30-JUL-2012
Packet *p = a->allocpkt();
hdr_bchpe *bchpeh = HDR_BCHPE(p);hdr_ip *iph = HDR_IP(p);hdr_cmn *hdrc = HDR_CMN (p);ntable_ent *prte;unsigned char *walk;unsigned char *count_pos;unsigned char *n_count_pos;uint adj_count;int count;double now = Scheduler::instance().clock();
bchpeh->valid()= 0; // we set the bchpeh->valid_ to 0 to indicate it's a broadcastpkt
// Ponemos el bchph-> valid_ a 0 para indicar que es un pkt broadcasthdrc->ptype() = PT_MESSAGE;hdrc->next_hop_ = MAC_BROADCAST; // valor de 13hdrc->addr_type_ = AF_INET; // valor de 2
iph->daddr() = IP_BROADCAST;iph->dport() = ROUTER_PORT;iph->saddr() = a->myaddr_;iph->ttl()=3;if ((my_status == CLUSTER_HEAD) || (my_status ==
CLUSTER_HEAD_BACKUP) ){adj_count = 0;
}else {adj_count = adjtable_size;
}// termina el if-else
assert((my_size+adj_count)<= (1500 / 12));p->allocdata((MAX_NODE_NUM * 2) + (adj_count * 1) + 3);
walk = p->accessdata ();*(walk++) = my_status;n_count_pos = walk++;count_pos = walk++;*(count_pos) = adj_count;
105
count = 0;for (InitLoop ();(prte = NextLoop ()); ){
if ((prte->neighbor<0 )||(prte->neighbor> MAX_NODE_NUM)){//modificado
abort();}if ((now - prte->last_update)< b_time) {*(walk++) = prte->neighbor;*(walk++) = prte->neighbor_status;count++;
}}
*(n_count_pos) = count;
if (!adj_count) {*(count_pos) = 0;
} else {adjtable_ent *padj = adjtable_1;nsaddr_t dest;adj_count = 0;
while (padj) {dest = padj->neighbor_cluster;assert((dest>=0) && (dest<= MAX_NODE_NUM)); //modificadoif (!GetEntry(dest)) {*(walk++) = dest;adj_count++;
}padj = padj->next;
}assert(adj_count <= adjtable_size);*(count_pos) = adj_count;
}#ifdef ENERGYdouble eprob=(preenergy-a->node_->energy_model()->energy())/(a->node_-
>energy_model()->energy()+0.0000001); //added by zhaoqi 2007.6.28preenergy=a->node_->energy_model()->energy(); //agregadodouble cost=100*eprob*count; //agregadocost=cost+a->node_->getspeed()/16*100;bchpeh->nseid_=cost;#endif// hdrc->size_ = count * 2 + adj_count * 1 + 20 + 3;hdrc->size_ = count * 4 + adj_count*4 + 5; // size of the broadcast packet //
Tamaño del paquete de difusión
106
return p;}
En el presente método se controla el límite de energía para que se
haga el cambio de roles en caso de que el nivel de energía del JC
esté al límite.
// Proceso de Expiración del temporizador proyecto* En este metodo es donde debemos controlar el límite de energía para que se hagael cambio*/voidENeighborTableTimeoutHandler::handle(Event *event) {ntable_ent *prte;int deleted=0;int bandera = 0;iEnergy = a->node_->energy_model()->energy();nombre = a->myaddr_;iniEnergy = a->node_->energy_model()->initialenergy();double limite=((iniEnergy*15)/100);// Scheduler & s = Scheduler::instance();// check out the entry that caused this timeout event// echa un vistazo a la entrada que causó este evento tiempo de espera.for (t->InitLoop(); (prte = t->NextLoop());) {
if (prte->timeout_event == event) {//if ((prte->timeout_event == event) || (iEnergy <= limite)) {
// ProyectoFILE* dumpFile;char dumpFileName[50]="bchpe_ch.txt";dumpFile = fopen(dumpFileName, "a");
fprintf(dumpFile,"Nodo: %f + iE: %.6f +E: %.6f + Est: %i + Ban: %i \n", nombre,iniEnergy, iEnergy, (int)(t->my_status), bandera);
fclose(dumpFile);/* Cluster backup timeout process* Added RVTT*/
if ( t->my_status == CLUSTER_HEAD ) {bandera=1;
if (prte->neighbor == t->my_cluster_head_backup) {t->my_cluster_head_backup = 0;t->my_chb = NULL;
107
t->backup_updates = 0;// Aqui se debe llamar a un proceso para elección del NUEVO CHB.
t->my_chb = t->electCHB();if (t->my_chb) {t->my_cluster_head_backup = t->my_chb->neighbor;t->backup_updates = 0;t->my_chb->neighbor_status = CLUSTER_HEAD_BACKUP;Scheduler & s = Scheduler::instance();Packet *p;p = t->getBroadcastPacket();//send out the packet immediately //enviar el paquete
inmediatamentes.schedule(a->ll, p, 0);
} else {}
}} else if(t->my_status == CLUSTER_HEAD_BACKUP){
if (prte->neighbor == t->my_cluster_head) {t->my_cluster_head = 0;t->my_ch = NULL;t->backup_updates = 0;t->my_status = CLUSTER_HEAD;Scheduler & s = Scheduler::instance();Packet *p;// cancel my periodic event and restart again how CHs.cancel(t->periodic_event);
s.schedule(t->periodic_handler,t->periodic_event,BROADCAST_INTEVAL);
p = t->getBroadcastPacket();//send out the packet immediately //enviar el paquete inmediatamentes.schedule(a->ll, p, 0);
// Se debe enviar inmediatamente un paquete anunciando que soy el nuevoCLUSTER_HEAD
}}prte->timeout_event = NULL;t->DeleteEntry(prte->neighbor);delete event;deleted++ ;if (deleted>1) {printf("duplicated!\n");
}}
}if (deleted) {
108
return;}if (checkAdjTimeout(event,1) || checkAdjTimeout(event,0)) {
delete event;return;
}}
En el presente método puedo hacer las declaraciones y llamadas para
la clase energy model para la energía de cada nodo creado en el
cluster
ENeighborTableCFormationHandler::ENeighborTableCFormationHandler(BCHPE_Agent *a_, ENeighborTable *t_){a = a_;t = t_;preenergy=1;
/* proyecto lo que coloque aquí me sale por cada nodo creado desde 0 <= n* */
}
Dentro del presente método que analiza si hay alguna entrada
eliminada agregamos la condición del nivel de energía del JC justo
antes de llamar al método de JC perdidos.
intENeighborTable::DeleteEntry(nsaddr_t dest) {ntable_ent *tmp;ntable_ent *tmp_prev;
Scheduler & s = Scheduler::instance();
//check if the entry to be deleted is the current entry// Comprobar si la entrada que desea eliminar es la entrada actual.if (now && (now->neighbor == dest)) {tmp = now;tmp_prev = prev;
}else {tmp = head;
109
tmp_prev = NULL;while (tmp && (tmp->neighbor != dest)) {tmp_prev = tmp;tmp = tmp->next;
}}/**REVISAR ESTO*/if (tmp) {// check if the no_of_clusterheads I belong to has decreased.
// comprobar si los no_of_clusterheads que pertenezco ha disminuido.assert(tmp->neighbor == dest);if ((tmp->neighbor_status == CLUSTER_HEAD) &&
(tmp->link_status == LINK_BIDIRECTIONAL)) {
no_of_clusterheads--;// check if the no_of_clusterheads has decreased to zero// Proyecto 04-10-2012if (((!no_of_clusterheads)&& ((my_status == CLUSTER_MEMBER) ||
(my_status==CLUSTER_HEAD_BACKUP)) )||((a->node_->energy_model()->energy()<=75)&&(my_status==CLUSTER_HEAD)) ){
lostClusterHeads();} }
//delete the entry //borrar la entradaif (tmp_prev) {tmp_prev->next = tmp->next;
}else {head = tmp->next;
}my_size--;
if (tmp->n_pkt) {Packet::free(tmp->n_pkt);
}tmp->n_pkt = NULL;
// see if any entries in adjtable_1 need to be deleted// Ver si alguna entrada en adjtable_1 deben ser eliminadosDeleteAdjEntry(dest,1);
for (int i=0;i<MAX_NODE_NUM;i++) {if (adjtable[i].the_node == dest) {if (adjtable[i].dest_status == CLUSTER_HEAD) { //there may be redundancies
in adjtable_1 //puede haber redundancias en adjtable_1.adjtable_ent *ent = GetAdjEntry(i+1,1);if (ent) {
110
adjtable[i].the_node= ent->next_hop->next_node;adjtable[i].last_updated = Scheduler::instance().clock();
}else {adjtable[i].the_node= 0;
}}else {adjtable[i].the_node= 0;
}}
}
DeleteAdjEntry(dest,0);if (tmp->timeout_event) {s.cancel(tmp->timeout_event);
}tmp->timeout_event = NULL;tmp->next = NULL;delete tmp;
}else {return 0;
}return 1;
}
Dentro de este método colocamos la condición para el cambio de
roles entre el JC y JCR cuando el nivel de energía del JC está al
límite
voidENeighborTable::lostClusterHeads() {nsaddr_t min_addr= a->myaddr_;ntable_ent *prte;Scheduler & s = Scheduler::instance();Packet *p;assert ((((my_status == CLUSTER_MEMBER) ||
(my_status==CLUSTER_HEAD_BACKUP)) && (no_of_clusterheads == 0))||((a->node_->energy_model()->energy()<=75)&&(my_status==CLUSTER_HEAD)));//assert(((my_status == CLUSTER_HEAD_BACKUP) || (my_status ==
CLUSTER_MEMBER)) && (no_of_clusterheads == 0));// Proyectoif ((my_status == CLUSTER_HEAD) && (a->node_->energy_model()-
>energy()<=75)) {
111
my_cluster_head = NULL;my_ch = 0;backup_updates = 0;my_cluster_head_backup = 0;
my_status = CLUSTER_MEMBER;printf("prueba Proyecto2 + N: %i + S: %i + E: %.6f \n", a->myaddr_,
(int)(my_status), a->node_->energy_model()->energy());//Proyecto 04-10-2012p = getBroadcastPacket();s.schedule(a->ll, p, 0);
}//fin Proyecto
if (my_status == CLUSTER_HEAD_BACKUP) {my_cluster_head = 0;my_ch = NULL;backup_updates = 0;my_cluster_head_backup = 0;
my_status = CLUSTER_HEAD;p = getBroadcastPacket();s.schedule(a->ll, p, 0);
} else if (my_status == CLUSTER_MEMBER) {for (InitLoop ();
(prte = NextLoop ()); ) {if ((prte->link_status == LINK_BIDIRECTIONAL) &&
(prte->neighbor < min_addr)) {min_addr = prte->neighbor;
} //fin_if} //fin_for
if (min_addr == a->myaddr_) {my_status = CLUSTER_HEAD;BCHPE_Agent::no_of_clusters_++;a->trace("SUM CLUSTERS %.5f %d",Scheduler::instance().clock(),
BCHPE_Agent::no_of_clusters_);}else {
my_status = CLUSTER_UNDECIDED;Scheduler::instance().schedule(c_formation_handler,c_form_event,1.1*BROADCAST_INTEVAL);
}// fin_if}// fin_else
}
También se agrega la condición del límite de energía para JC ya que
son métodos redundantes durante la simulación. Además colocamos
112
en un archivo de texto los datos de los nodos que se han cambiado
como JC.
voidENeighborTable::AddUpdateEntry(ntable_ent *prte) {ntable_ent *tmp;ntable_ent *prev_tmp;Scheduler & s = Scheduler::instance();
assert((prte->neighbor>=0) && (prte->neighbor<= MAX_NODE_NUM));tmp = head;prev_tmp = NULL;while (tmp && (tmp->neighbor != prte->neighbor)) {
prev_tmp = tmp;tmp = tmp->next;
}
if (tmp) {if (tmp->n_pkt) {Packet::free(tmp->n_pkt);
}prte->timeout_event = tmp->timeout_event;s.cancel(tmp->timeout_event);
}else {//size of neighbor table has increased by 1//tamaño de tabla de vecinos ha aumentado en 1my_size++;prte->timeout_event = new Event;
}s.schedule(timeout_handler, prte->timeout_event, 2.1*BROADCAST_INTEVAL);
if (tmp) {// Un vecino pasó de no jefe cluster a jefe clusterif ((tmp->neighbor_status != CLUSTER_HEAD) && // ntable_ent *tmp;
(prte->neighbor_status == CLUSTER_HEAD) && // ntable_ent *prte(prte->link_status == LINK_BIDIRECTIONAL)) {
no_of_clusterheads++;// A neighbor changed from clusterhead to non-clusterhead// Un vecino pasó de jefe cluster a no jefe cluster.}else if ((tmp->neighbor_status == CLUSTER_HEAD) &&(prte->neighbor_status
!= CLUSTER_HEAD) && (tmp->link_status == LINK_BIDIRECTIONAL)) {no_of_clusterheads--;
113
}else if ((tmp->neighbor_status == CLUSTER_HEAD) &&(prte->neighbor_status == CLUSTER_HEAD)) {
if ((tmp->link_status == LINK_FROM) &&(prte->link_status == LINK_BIDIRECTIONAL)) {
no_of_clusterheads++;}else if ((tmp->link_status == LINK_BIDIRECTIONAL)&&
(prte->link_status==LINK_FROM)) {no_of_clusterheads--;
}}
// if this entry is a new one// Si esta entrada es nueva}else if ((prte->neighbor_status == CLUSTER_HEAD)&&
(prte->link_status == LINK_BIDIRECTIONAL)) {no_of_clusterheads++;
}
if (prev_tmp && tmp) {prev_tmp->next = prte;prte->next = tmp->next;tmp->next = NULL;delete tmp;
} else if (tmp) {prte->next = tmp->next;head = prte;tmp->next = NULL;delete tmp;
} else {prte->next = head;head = prte;
}
Packet *p;/* Proyecto para la actualización de las tablas de enrutamiento.* si la entrada identifica a un nodo con mejor métrica q el JCR actual, el estado* del nodo de la nueva entrada es modificado a JCR e informado al resto de nodos* para la actualización respectiva de sus tablas de enrutamiento*/
if (prte->link_status == LINK_BIDIRECTIONAL) {// Proyecto
FILE* dumpFile;char dumpFileName[50]="bchpe_prueba.txt";dumpFile = fopen(dumpFileName, "a");
//double energyinicial2 = a->node_->energy_model()->initialenergy();
114
double energia1 = (a->node_->energy_model()->energy()*-1);double nombre = a->myaddr_;
//fprintf(dumpFile, "-Nodo %f + -inicial energy: %.6f + -Energy %.6f+ -estado: %i: + t %f + r %f\n", nombre ,energyinicial1 , energia1,(int)(CLUSTER_HEAD), trans, rec);
fprintf(dumpFile, "N: %.0f + es: %i + Ns: %i + E: %.6f + Ns:%i \n",nombre, (int)(my_status), prte->neighbor_status, energia1, prte->neighbor);
//fprintf(dumpFile, "N: %f + EI: %.6f + E: %.6f + es %i + Ns: %i \n",nombre, energyinicial1, energia1, (int)(my_status), prte->neighbor_status);
fclose(dumpFile);// fin Proyecto
if (my_status == CLUSTER_HEAD) {if (prte->neighbor_status == CLUSTER_HEAD) {
if (!in_contention) {in_contention = 1;
s.schedule(c_contention_handler,c_contention_event,2*BROADCAST_INTEVAL);
}}else if (prte->neighbor_status == CLUSTER_HEAD_BACKUP) {
if (prte->neighbor == my_cluster_head_backup)backup_updates++;}
}/* For cluster head backup process* Para el proceso jefe_cluster_respaldo*/
} else if (my_status == CLUSTER_HEAD_BACKUP) {if ((prte->neighbor_status == CLUSTER_HEAD_BACKUP) && (a-
>myaddr_ < prte->neighbor)) {my_cluster_head_backup = 0;my_cluster_head = 0;my_ch = NULL;my_chb = NULL;backup_updates = 0;s.cancel(c_form_event);my_status = CLUSTER_MEMBER;p = getBroadcastPacket();
/* Proyecto 25-JUL-2012* PONIENDO AQUÍ LA ENERGÍA NO ME ARROJA NINGÚN VALOR MASQUE SÓLO LA CREACIÓN DE LOS NODOS * */
s.schedule(a->ll, p, 0);
/* Proyecto 25-JUL-2012
115
* PONIENDO AQUÍ LA ENERGÍA NO ME ARROJA NINGÚN VALOR MASQUE SÓLO LA CREACIÓN DE LOS NODOS * */
}/** If i am a cluster head backup and i receive an update for my cluster head* Si yo soy un cluster_head_backup y recibo una actualización para mi
cluster_head*/
else if ((prte->neighbor_status == CLUSTER_HEAD) ) {if (my_cluster_head == prte->neighbor) {
if (prte->neighbor == my_cluster_head)backup_updates++;
// } else {// I am the chb at another cluster ? its not posible ... I just permit one chb by
cluster// Yo soy el chb a otro grupo? no es Posible ... Acabo de permitir una chb por grupos
}} else if (my_status == CLUSTER_UNDECIDED) {
if (prte->neighbor_status == CLUSTER_HEAD) {s.cancel(c_form_event);my_status = CLUSTER_MEMBER;p = getBroadcastPacket();s.schedule(a->ll, p, 0);
}}
}/* Proyecto* OPCIÓN PARA CAMBIAR DE JCR A JC CUANDO NO HAY RTA. DEL JC*/
if (((no_of_clusterheads == 0) &&((my_status == CLUSTER_MEMBER) || (my_status ==
CLUSTER_HEAD_BACKUP)) )||((a->node_->energy_model()->energy()<=75)&&(my_status==CLUSTER_HEAD))) {
//check if I have lost all cluster heads//comprobar si he perdido todos los jefes cluster.
lostClusterHeads();
/* If I am CLUSTER_HEAD_BACKUP I must change to cluster head* Si soy jefe_cluster_respaldo tengo que cambiar a jefe_cluster.*/
}}
116
ANEXO 5. Configuración de la topología
setdest
La herramienta setdest se utiliza para generar las posiciones de los nodos y
su velocidad de movimiento y direcciones de movimiento. (Wu, 2007)
Deben ejecutarse dentro de las carpetas contenedoras del proyecto de ns2:/home/proyecto/tesis/ns-allinone-2.34/ns-2.34/indep-utils/cmu-scen-gen/setdest
./setdest -v 2 -n 50 -s 1 -m 2 -M 6 -t 500 -P 1 -p 2 -x 600 -y 500 >scen-50-1000-500
scengen
El generador de escenarios es una herramienta para generar escenarios de
movilidad para MANET NS-2. (scengen, 2001)
scengen
cbrgen.tcl
Generación de conexiones debe ejecutarse en su carpeta contenedora del
proyecto de ns2: / ns-allinone-2.34/ns-2.34/indep-utils/cmu-scen-gen
ns cbrgen.tcl -type tcp -nn 50 -seed 1 mc 20 -rate 5 > scen-tcp
117
ANEXO 6. Archivo OTcl usado en la simulación
Funciones principales de la simulación
A continuación se describen las líneas de código más importantes usadas en
la simulación:
Este código es para la creación del escenario con 25 nodos, de tipo CBR. La primera parte
es la definición de opciones, donde se da los valores correspondientes a cada una de las
variables utilizadas. Se configura el número de nodos utilizados y los valores de los
parámetros que se utilizarán como es el caso de tipo de canal, modelo de antena, tiempo de
simulación, tipo de protocolo de enrutamiento (BCHPE), entre otros.
============================================================# Definición de opciones#============================================================set val(chan) Channel/WirelessChannel ;#Channel Typeset val(prop) Propagation/TwoRayGround ;# radio-propagation modelset val(netif) Phy/WirelessPhy ;# network interface typeset val(mac) Mac/802_11 ;# MAC typeset val(ifq) Queue/DropTail/PriQueue ;# interface queue typeset val(ll) LL ;# link layer typeset val(ant) Antenna/OmniAntenna ;# antenna modelset val(ifqlen) 100 ;# max packet in ifqset val(nn) 26 ;# number of mobilenodesset val(rp) BCHPE ;# routing protocol#set val(rp) DSR ;# routing protocolEn esta sección se define el tamaño de la topología de la simulación, es decir el espacio quese mostrará. También se definen las variables globales como “ns, bchpe25cbr, simulación”la variable bchpe25cbr sirve para abrir los archivos .tr, donde se guarda los resultados dela traza de la simulación que será posteriormente analizada con la herramienta tracegraphy los archivos awk, la variable “simulación” es la variable que guarda el nombre delarchivo .nam, donde se guarda la ejecución del escenario de simulación que se ejecuta conla herramienta nam.
# Tamaño de la topografíaset val(x) 1000set val(y) 500
118
# Configuración de los archivos de escenarios y conexionesset val(conexiones) "scen-tcp" ;# Llamada a archivo de conexionesset val(scenario) "scen25total" ; # Llamada a archivo de escenariosset val(stop) 100 ; # Tiempo de simulación en segundos# Configuración de las Opciones de energía
set val(engmodel) EnergyModelset val(txPower) 3 ;# transmitting power in mWset val(rxPower) 2 ;# recving power in mWset val(sensePower) 1 ;# sensing power in mWset val(idlePower) 1 ;# idle power in mWset val(initeng) 200 ;# Initial energy in Joules============================================================# Main Program============================================================# Initialize the SharedMedia interface with parameters to make# it work like the 2.4GMHz Lucent Orinoco WaveLAN DSSS radio interface (11Mb/s and 170 m)Phy/WirelessPhy set CPThresh_ 10.0Phy/WirelessPhy set CSThresh_ 5.011872e-12Phy/WirelessPhy set RXThresh_ 1.02054e-10Phy/WirelessPhy set Rb_ 11*1e6Phy/WirelessPhy set Pt_ 0.031622777Phy/WirelessPhy set freq_ 2.472e9Phy/WirelessPhy set L_ 1.0# Ajuste del ancho de banda en 11 Mbps
Mac/802_11 set dataRate_ 11MbMac/802_11 set basicRate 11Mb# Inicialización de variables globales
set ns_ [new Simulator]set tracefd [open bchpe25cbr.tr w]$ns_ trace-all $tracefd
$ns_ use-newtraceset namtrace [open bchpe25cbr.nam w]$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)# Configuración de topografía
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)# Create Godcreate-god $val(nn)
119
# New API to config node:# 1. Create channel (or multiple-channels);# 2. Specify channel in node-config (instead of channelType);# 3. Create nodes for simulations.# Create channel #1 and #2set chan_1_ [new $val(chan)]set chan_2_ [new $val(chan)]# Create node(0) "attached" to channel #1# configure node, please note the change below.$ns_ node-config -adhocRouting $val(rp) \
-llType $val(ll) \-macType $val(mac) \-ifqType $val(ifq) \-ifqLen $val(ifqlen) \-antType $val(ant) \-propType $val(prop) \-phyType $val(netif) \-channelType $val(chan) \-topoInstance $topo \-agentTrace ON \-routerTrace ON \-macTrace OFF \-movementTrace OFF \
-energyModel $val(engmodel)\-rxPower $val(rxPower) \-txPower $val(txPower) \-sensePower $val(sensePower) \-idlePower $val(idlePower) \-initialEnergy $val(initeng)
set node_(0) [$ns_ node]$node_(0) color red$ns_ at 0.0 "$node_(0) color red"$node_(0) label “SAâ€# Creación de los 25 nodos
for {set i 1} {$i < $val(nn)} {incr i} {set node_($i) [$ns_ node]
$node_($i) random-motion 0;# deshabilitar forma randómica}
puts "Loading scenario file..."source $val(scenario)
# Setup traffic flow between nodes# TCP connections between node_(0) and node_(1)
120
puts "Loading connection pattern..."source $val(conexiones)# Dice a los nodos cuando finalizar la simulación
for {set i 0} {$i < $val(nn) } {incr i} {$ns_ at $val(stop) "$node_($i) reset";
}$ns_ at $val(stop) "stop"$ns_ at $val(stop).01 "puts \"NS EXITING...\" ; $ns_ halt"
En este procedimiento se cierra los archivos .tr y .nam que fueron abiertos anteriormente.Aquí termina la simulación y se llama al archivo .nam para visualizar la simulación en laherramienta NAM.
proc stop {} {global ns_ tracefd$ns_ flush-traceclose $tracefd
}puts "Starting Simulation..."
# Ejecución de la simulación planteada
$ns_ run
Scripts de la simulación
Script para bchpe con 25 nodos
set val(chan) Channel/WirelessChannel ;#Channel Typeset val(prop) Propagation/TwoRayGround ;# radio-propagation modelset val(netif) Phy/WirelessPhy ;# network interface typeset val(mac) Mac/802_11 ;# MAC typeset val(ifq) Queue/DropTail/PriQueue ;# interface queue typeset val(ll) LL ;# link layer typeset val(ant) Antenna/OmniAntenna ;# antenna modelset val(ifqlen) 100 ;# max packet in ifqset val(nn) 26 ;# number of mobilenodesset val(rp) BCHPE ;# routing protocolset val(x) 600set val(y) 500set val(conexiones) "scen-tcp" ;
121
set val(scenario) "scen25total" ;set val(stop) 100 ;
# Opciones de energíaset val(engmodel) EnergyModelset val(txPower) 3 ;# transmitting power in mWset val(rxPower) 2 ;# recving power in mWset val(sensePower) 1; ;# sensing power in mWset val(idlePower) 1 ;# idle power in mWset val(initeng) 200 ;# Initial energy in Joules
============================================================# Programa Principal# Initialize the SharedMedia interface with parameters to make
# it work like the 2.4GMHz Lucent Orinoco WaveLAN DSSS radio interface (11Mb/s and 170 m)
Phy/WirelessPhy set CPThresh_ 10.0Phy/WirelessPhy set CSThresh_ 5.011872e-12Phy/WirelessPhy set RXThresh_ 1.02054e-10Phy/WirelessPhy set Rb_ 11*1e6Phy/WirelessPhy set Pt_ 0.031622777Phy/WirelessPhy set freq_ 2.472e9Phy/WirelessPhy set L_ 1.0# Ajuste del ancho de banda en 11 Mbps
Mac/802_11 set dataRate_ 11MbMac/802_11 set basicRate 11Mb# Inicialización de variables globales
set ns_ [new Simulator]set tracefd [open bchpe25tcp.tr w]$ns_ trace-all $tracefd$ns_ use-newtraceset namtrace [open bchpe25tcp.nam w]$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)# Configurando la topografía
set topo [new Topography]$topo load_flatgrid $val(x) $val(y)# Create Godcreate-god $val(nn)}
122
# New API to config node:# 1. Create channel (or multiple-channels);# 2. Specify channel in node-config (instead of channelType);# 3. Create nodes for simulations.# Create channel #1 and #2set chan_1_ [new $val(chan)]set chan_2_ [new $val(chan)]# configure node, please note the change below.$ns_ node-config -adhocRouting $val(rp) \
-llType $val(ll) \-macType $val(mac) \-ifqType $val(ifq) \-ifqLen $val(ifqlen) \-antType $val(ant) \-propType $val(prop) \-phyType $val(netif) \-topoInstance $topo \-agentTrace ON \-routerTrace ON \-macTrace OFF \-movementTrace OFF \-channel $chan_1_ \
-energyModel $val(engmodel)\-rxPower $val(rxPower) \-txPower $val(txPower) \-sensePower $val(sensePower) \-idlePower $val(idlePower) \-initialEnergy $val(initeng)
set node_(0) [$ns_ node]$node_(0) color red$ns_ at 0.0 "$node_(0) color red"$node_(0) label “SAâ€
for {set i 1} {$i < $val(nn)} {incr i} {set node_($i) [$ns_ node]
$node_($i) random-motion 0;# enable random motion}
puts "Loading scenario file..."source $val(scenario)# Configurando el fllujo de tráfico entre nodos
# TCP connections between node_(0) and node_(1)
123
puts "Loading connection pattern..."source $val(conexiones)# Dice a los nodos el final de la simulación
for {set i 0} {$i < $val(nn) } {incr i} {$ns_ at $val(stop) "$node_($i) reset";
}$ns_ at $val(stop) "stop"$ns_ at $val(stop).01 "puts \"NS EXITING...\" ; $ns_ halt"proc stop {} {
global ns_ tracefd$ns_ flush-traceclose $tracefd
}
puts "Starting Simulation..."$ns_ run
124
ANEXO 7. Archivos awk para los resultados
Rendimiento
BEGIN {# Las instrucciones contenidas dentro de BEGIN sólo se ejecutan una vez# Se abre el fichero de salidasalida2="Graf_troughput.txt"# Se inicializan las variables globalesmayor_id=-1bytes_env_0=0rec_1=0env_0=0drop=0bytes_rec_11=0}{# Las instrucciones contenidas dentro de este apartado principal se ejecutan una vez# para cada fila del fichero# Se asignan variables a las columnas o campos a utilizar del fichero de trazasaccion=$1nodo_actual=$9bytes_paquete=$37id_paquete=$41nodo_destino=$7prot_mes=$35trace_level=$19if(accion!="SFESTs" && accion!="SFs" && trace_level=="AGT"){# Se analizan los paquetes enviadosif ( accion == "s"){
if (id_paquete > mayor_id){ # Se miran los paquetes no analizados previamentemayor_id=id_paquete
# if ( prot_mes == "cbr"){ # Sólo interesan los paquetes CBRif ( nodo_actual == 0){
# Se comprueba si el paquete lo envÃa el nodo fuentebytes_env_0 = bytes_env_0 + bytes_paquete# Se suman los bytes CBR enviados por el nodo 0 o fuente
env_0++# Se incrementa el número de paquetes CBR enviados por el nodo 0
}}
}# Se analizan los paquetes recibidos
125
if ( accion == "r"){if (nodo_actual == nodo_destino){
if (nodo_actual == 0){bytes_rec_1 = bytes_rec_1 + bytes_paquete - 20# Se suman los bytes CBR recibidos por el nodo 0 o destino, se descuenta la
cabecera IP de 20 bytesrec_1++# Se incrementa el número de paquetes CBR recibidos por el nodo 1
}}
}if ( accion == "d"){
if (nodo_actual == nodo_destino){if (nodo_actual == 0){
# Se suman los bytes CBR recibidos por el nodo 0 o destino, se descuenta# la cabecera IP de 20 bytesdrop++# Se incrementa el número de paquetes CBR recibidos por el nodo 1
}}
}}}END{
# Las instrucciones contenidas dentro de END sólo se ejecutan una vez
# Se guardan los resultados obtenidos en el fichero de salidaprintf(": ") >> salida2printf("Paquetes recibidos %i ", rec_1) > salida2printf("Paquetes enviados %i ", env_0) > salida2printf("Paquetes borrados %i ", drop) > salida2printf("Throughput1 %f ", rec_1/env_0) > salida2printf("Bytes recibidos %i ", bytes_rec_1) > salida2printf("Bytes enviados %i ", bytes_env_0) > salida2printf("Throughput2 %f \n", bytes_rec_1/bytes_env_0) > salida2printf("Throughput2 %f \n", bytes_rec_1/bytes_env_0) > salida2
# Aunque se calculan dos throughputs, uno a partir de los paquetes y otro a partir de# los bytes (descontando en este último caso los bytes de las cabeceras IP), en este# proyecto todos los datos obtenidos del throughput usados son a partir del número# de paquetes. El segundo throughput no se ha usado para extraer los resultados pero#se mantiene aquà como dato extra.# Se cierra el fichero de salida
close(salida2)}
126
Paquetes Perdidos
# Para ejecutar awk -f thisfile trazafile listadodearchivos# ARGCV[1] trazafile ARGV2[2] listadodearchivos# Para obtener el listado de archivos# find . -type f | grep \.tr$ > listadodearchivosBEGIN {# Las instrucciones contenidas dentro de BEGIN sólo se ejecutan una vez# Se abre el fichero de salidasalida2="./Graf_dropped.txt"
# Se inicializan las variables globalestotal=0end=0col=0dup=0err=0ret=0sta=0bsy=0nrte=0loop=0ttl=0tout=0cbk=0ifq=0arp=0out=0file=ARGV[1]}{# Las instrucciones contenidas dentro de este apartado principal se ejecutan una vez# para cada fila del fichero. Se asignan variables a las columnas o campos a utilizardel fichero de trazasaccion=$1nodo_actual=$9bytes_paquete=$37id_paquete=$41nodo_destino=$7prot_mes=$35trace_level=$19borrado=$21#if(accion!="SFESTs" && accion!="SFs" && trace_level=="AGT"){
127
# Se analizan los paquetes enviados#if ( accion == "s"){
# if (id_paquete > mayor_id){ # Se miran los paquetes no analizados previamente# mayor_id=id_paquete# if ( prot_mes == "cbr"){ # Sólo interesan los paquetes CBR# if ( nodo_actual == 0){
# Se comprueba si el paquete lo envÃa el nodo fuente# bytes_env_0 = bytes_env_0 + bytes_paquete
# Se suman los bytes CBR enviados por el nodo 0 o fuente# env_0++
# Se incrementa el número de paquetes CBR enviados por el nodo 0# }# }# }#}# Se analizan los paquetes recibidos
#if ( accion == "r"){# if (nodo_actual == nodo_destino){# if (nodo_actual == 0){# bytes_rec_1 = bytes_rec_1 + bytes_paquete - 20
# Se suman los bytes CBR recibidos por el nodo 0 o destino, se descuenta# la cabecera IP de 20 bytes # rec_1++# Se incrementa el número de paquetes CBR recibidos por el nodo 1
# } }}if ( accion == "d"){
total++if (borrado == "END") {
end++}if (borrado == "COL") {
col++}if (borrado == "DUP") {
dup++}if (borrado == "ERR") {
err++}if (borrado == "RET") {
ret++}if (borrado == "STA") {
sta++
128
}if (borrado == "BSY") {
bsy++}if (borrado == "NRTE") {
nrte++}if (borrado == "LOOP") {
loop++}if (borrado == "TTL") {
ttl++}if (borrado == "TOUT") {
tout++}if (borrado == "CBK") {
cbk++}if (borrado == "IFQ") {
ifq++}if (borrado == "ARP") {
arp++}if (borrado == "OUT") {
out++}
# if (nodo_actual == nodo_destino){# if (nodo_actual == 0){
# Se suman los bytes CBR recibidos por el nodo 0 o destino, se descuenta# la cabecera IP de 20 bytes# Se incrementa el número de paquetes CBR recibidos por el nodo 1
# }}}}
END{
# Las instrucciones contenidas dentro de END sólo se ejecutan una vez# Se guardan los resultados obtenidos en el fichero de salida
printf("%s|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i|%i \n",file,total,end,col,dup,err,ret,sta,bsy,nrte,loop,ttl,tout,cbk,ifq,arp,out) >> salida2
129
# Aunque se calculan dos throughputs, uno a partir de los paquetes y otro a partir de# los bytes (descontando en este último caso los bytes de las cabeceras IP), en este# proyecto todos los datos obtenidos del throughput usados son a partir del númerode# paquetes. El segundo throughput no se ha usado para extraer los resultados pero se# mantiene aquà como dato extra.# Se cierra el fichero de salida
close(salida2)}
Jitter
#This program is used to calculate the jitters for CBR# jitter ((recvtime(j)-sendtime(j))-(recvtime(i)-sendtime(i)))/(j-i), j > iBEGIN {# Inicialización
highest_packet_id = 0;salidajitter="./Graf_jitter";salidae2edelay="./Graf_e2edelay";flowfile="./flowfile";split(ARGV[1],a,"/");tmp=a[4];split(tmp,a,".");
# printf("archivo %s; a[4] %s; b[1] %s", ARGV[1], tmp, a[1])graphjitter=sprintf("%s-%s",salidajitter,a[1]);graphe2edelay=sprintf("%s-%s",salidae2edelay,a[1]);
# printf("nuevo archivo: %s, %s\n", salidajitter, salidae2edelay)allsend=0;allreceive=0;allAGT=0;allRTR=0;allrecAGT=0;allrecRTR=0;
}{
action = $1;time = $3;from = $5;to = $7;type = $35;pktsize = $37;flow_id = $39;
130
level_trace = $19;src = $31;dst = $33;seq_no = $47;packet_id = $41;
# printf("flow_id id: %i, packet_id, %i \n %s \n", flow_id,packet_id, $0);if (flow_id > 0) {
printf("flow_id id: %i, packet_id, %i \n %s \n", flow_id,packet_id, $0);}
if (action == "s") {allsend++;
# By protocolo Overheadif (level_trace=="AGT") {
allAGT++;}
if (level_trace=="RTR") {allRTR++
}}if (action == "r") {
allreceive++if (level_trace=="AGT") {
allrecAGT++;}
if (level_trace=="RTR") {allrecRTR++
}}
if ( packet_id > highest_packet_id ) {highest_packet_id = packet_id;
}#Record the transmission timeif ( start_time[packet_id] == 0 ) {
# Record the sequence numberpkt_seqno[packet_id] = seq_no;start_time[packet_id] = time;
}
#Record the receiving time for CBR (flow_id=2)
if ( flow_id == 0 && action != "d" ) {if ( action == "r" ) {
end_time[packet_id] = time;}
} else {
131
end_time[packet_id] = -1;}
}END {
last_seqno = 0;last_delay = 0;seqno_diff = 0;
jitter_average = 0;e2edelay_average = 0;
for ( packet_id = 0; packet_id <= highest_packet_id; packet_id++ ) {start = start_time[packet_id];end = end_time[packet_id];packet_duration = end - start;
if ( start < end ) {e2edelay_average = e2edelay_average + packet_duration;seqno_diff = pkt_seqno[packet_id] - last_seqno;delay_diff = packet_duration - last_delay;
# if (seqno_diff <= 0 || delay_diff <= 0) {if (seqno_diff == 0 ) {
jitter =0;} else {
jitter = delay_diff/seqno_diff;jitter_average = jitter_average + jitter;
}# Print jitter graf for each trace file
printf("%f %f\n", start, jitter) >> graphjitter;# Print End to end dely for each trace file
printf("%f %f\n", start, packet_duration) >> graphe2edelay;last_seqno = pkt_seqno[packet_id];last_delay = packet_duration;
}}
# printf("flow_id id: %i, packet_id, %i \n %s \n", flow_id,packet_id, $0);printf("File|Delay Average|Jitter
Average|AllSend|SendAGT|SendRTR|AllReceive|recAGT|recRTR");if (packet_id != 0 ) {
printf("%s|%f|%f|%d|%d|%d|%d|%d|%d\n", ARGV[1],e2edelay_average/packet_id, jitter_average/packet_id,allsend,allAGT, allRTR,allreceive,allrecAGT, allrecRTR) >> salidae2edelay;# } else {
132
# printf("%s|%f|%f|%d|%d|%d|%d\n", ARGV[1], e2edelay_average/1,jitter_average/1,allsend,allreceive,allAGT, allRTR) >> salidae2edelay;
}close(salidae2edelay);close(graphjitter);close(graphe2edelay);
}
Paquetes enviados/recibidos (rateAGTsendingpackets)
BEGIN {# Este script obtiene la tasa de envio de paquetes solo para AGT, no toma en cuenta# las trazas de enrutamiento (RTR) ni las trazas (MAC)# Se divide los paquetes enviados para los paquetes recibidos# Las instrucciones contenidas dentro de BEGIN solo se ejecutan una vez# Se abre el fichero de salida
salida2="./AGTratesending"split(ARGV[1],a,"/");tmp=a[4];split(tmp,a,".");printf("archivo %s; a[4] %s; b[1] %s", ARGV[1], tmp, a[1])Nombre=a[1];
# Se inicializan las variables globales
mayor_id=-1bytes_env_0=0rec_1=0env_0=0drop=0bytes_rec_11=0}{# Las instrucciones contenidas dentro de este apartado principal se ejecutan una vez# para cada fila del fichero# Se asignan variables a las columnas o campos a utilizar del fichero de trazasaccion=$1nodo_actual=$9bytes_paquete=$37id_paquete=$41nodo_destino=$7prot_mes=$35trace_level=$19if(trace_level=="AGT"){
133
# Se analizan los paquetes enviados
if ( accion == "s"){if (id_paquete > mayor_id){ # Se miran los paquetes no analizados previamente
mayor_id=id_paquete# if ( prot_mes == "cbr"){ # Sólo interesan los paquetes CBR# if ( nodo_actual == 0){
# Se comprueba si el paquete lo envÃa el nodo fuentebytes_env_0 = bytes_env_0 + bytes_paquete# Se suman los bytes CBR enviados por el nodo 0 o fuente
env_0++
# Se incrementa el número de paquetes CBR enviados por el nodo 0# }# }
}}# Se analizan los paquetes recibidos
if ( accion == "r"){# if (nodo_actual == nodo_destino){# if (nodo_actual == 0){# bytes_rec_1 = bytes_rec_1 + bytes_paquete - 20
bytes_rec_1 = bytes_rec_1 + bytes_paquete - 20;# Se suman los bytes CBR recibidos por el nodo 0 o destino, se descuenta# la cabecera IP de 20 bytesrec_1++# Se incrementa el número de paquetes CBR recibidos por el nodo 1
}}}END{# Las instrucciones contenidas dentro de END sólo se ejecutan una vez# Se guardan los resultados obtenidos en el fichero de salida
# Imprime nombre del fichero, paquetesrecibibos, enviados, recibidos/enviados,bytesenviados, bytesrecibidos,bytesrecibidos/bytesenviados
printf("%s|%i|%i|%f|%i|%i|%f\n ", Nombre, rec_1, env_0, rec_1/env_0, bytes_rec_1,bytes_env_0, bytes_rec_1/bytes_env_0) >> salida2
close(salida2)
}
134
ANEXO 8. Artículo
Implementación de un Protocolo de Enrutamiento JerárquicoProactivo en NS-2
Julio Criollo, María Esther Ruilova, Rommel Torres,
Escuela de Ciencias de la ComputaciónCarrera de Sistemas Informáticos y Computación
Universidad Técnica Particular de LojaSan Cayetano Alto (Loja)
Teléfono: 2570275
[email protected], [email protected], [email protected]
Resumen. En este artículo se presenta el funcionamiento del Protocolo Backup Cluster HeadProtocol Enhanced aplicado para redes móviles Ad Hoc, gracias a la inclusión de una estrategiaproactiva que permite controlar el estado de la batería del nodo Jefe de Cluster y del Jefe Clusterde Respaldo, estableciendo un valor umbral con la finalidad de mantener la red lo más estableposible, evitando la ruptura de comunicación intracluster y extracluster. El cambio entre el jefecluster y su backup se hará de forma proactiva evitando la pérdida excesiva de paquetes,manteniendo la red ad hoc estable.
Palabras clave: Protocolojerárquico proactivo, BHCPE, Redes Móviles AdHoc, EnergyModel.
1 Introducción
Las redes Móviles Ad hoc, MANET (Mobile Ad Hoc Network) son redes temporales yautoconfigurables. Estos nodos podrían ser origen, destino y puente de información. Tienerecursos finitos (ancho de banda, batería, procesamiento) que deben ser bien utilizados con elfin de mejorar el rendimiento de toda la red. En este tipo de redes es importante maximizar ladisponibilidad, velocidad y estado de la red en su conjunto. Por ejemplo, si un nodo tieneinsuficiente batería, o su procesador está saturado, entonces, con el foin de no comprometerla disponibilidad de toda la red, su participación debe limitarse a un nodo puente o router enel intercambio de información.
Existen varias clasificaciones de los protocolos de enrutamiento según (Biradar & Patil,2006) y (Royer & Toh, 1999), pero la más conocida es la clasificación de proactivos,reactivos y jerárquicos. En los protocolos reactivos solo se realiza el descubrimiento de rutascuando es necesaria una conexión, presentan tiempo de descubrimiento de ruta bastantecortos ya que trabajan bajo demanda, de esta manera hacen que el tiempo de entrega depaquetes sea menor; utilizan mecanismos de descubrimiento y mantenimiento de ruta. Losprotocolos proactivos intercambian periódicamente mensajes entre ellos a fin de manteneractualizadas las rutas, pueden elegir la mejor ruta a cada instante, ofreciendo una rápidarespuesta ante las solicitudes de ruta, lo cual hace que la sobrecarga de información sea alta.
135
Los protocolos jerárquicos en cambio dividen la red en subconjuntos de nodos llamadoscluster, en donde un nodo Jefe de Cluster (CH) es utilizado para concentrar y distribuir lainformación generada dentro del cluster, dentro de este tipo de protocolos se encuentraBCHP (Backup Cluster Head Protocol). (Torres, 2011)
En este contexto uno de los retos que tiene BCHP es lograr la mejora de la red a través de lacreación de un Jefe Cluster de Respaldo (BCH) para que tome lugar del Jefe de Clustercuando este falle.
Sin embargo BCHP mejora este proceso pero lo realiza de forma reactiva, lo que provocaque en tiempos cortos haya pérdida de comunicación entre los nodos.
Nuestra propuesta es una mejora al BCHP que considera una estrategia proactiva basada enel consumo de energía del CH.
Para lograr este objetivo proponemos el BCHPE (Backup Cluster Head Protocolo Enhanced)que es una mejora del BCHP la cual la implementamos en un simulador de redes llamadoNetwork Simulator 2. (Fall & Varadhan, 2005),(Fedora TM) (Clases usadas por NS-2)
2 Related Work
2.1 Enrutamiento jerárquico
La capa de red OSI, es donde los procesos de las redes Ad Hoc se llevarán a cabo y seidentifican. De esta manera los esfuerzos de mejora de esta capa son visibles directamente enlas capas superiores.
Mientras mas nodos llegan a formar parte de la red MANET, los protocolos de enrutamientojerárquico son mejores gestionados que los protocolos proactivos y reactivos. En estos casoslos protocolos reactivos tiene la desventaja de la sobrecarga que supone mantener lainformación en toda la red. Los protocolos proactivos son mas lentos en la consecución de laconvergencia de la red ya que deben intercambiar información entre un mayor número denodos.
Esta investigación se centra en mejorar el proceso de subcapa de una red ad hoc utilizandoenrutamiento jerárquico proactivo con el fin de lograr mayor disponibilidad posible para losprocesos de comunicación.
Hay varios estudios que identifican y agrupan protocolos de enrutamiento jerárquicos. Estosprotocolos de enrutamiento jerárquicos y estrategias se centran en la elección de jefes decluster y el mantenimiento de los grupos y no se centran en la mejora de la disponibilidad dela red en su conjunto, como ocurre en esta investigación.
136
Esta investigación es diferente del trabajo anterior en como mejora la disponibilidad de lared mediante el uso de redundancia para los nodos principales y a través de incorporar unaestrategia proactiva basada en el consumo de energía (Feeney, 2011) de los nodosprincipales.
2.2 BCHP (Backup Cluster Head Protocol)
BCHP es un protocolo de enrutamiento jerárquico que propone la mejora de ladisponibilidad de la red a través de la inclusión de los nodos BCH. (Torres, 2011)
La ¡Error! No se encuentra el origen de la referencia. 1, muestra la formación de loscluster para la red ad hoc, cada cluster tiene su CH y BCH junto a los nodos miembros delcluster, un nodo Gateway que se comunica con los demás NG de los cluster.
Figura 1. Clustered ad hoc network
Consta de tres etapas: la creación del cluster, el mantenimiento del cluster y el enrutamientoentre cluster. El enrutamiento se hace en tres niveles: dentro del área de transmisión, dentrodel cluster, fuera del cluster.
Para la elección del CH y BCH se toman en cuenta los dos nodos con mejores prestaciones,las métricas se calculan en base a los recursos disponibles del nodo, menor movilidad delnodo, rango de transmisión y estado de la baetría.
Cuando el CH deja de funcionar ya sea por movilidad, fallas o estado de batería, el BCHtoma el rol del CH, pero durante estos segundos de cambio de roles la comuniacción sepierde. (Torres, 2011)
Un nodo (agente) BCHP lógicamente tiene los siguientes componentes: la definición delagente, la tabla de enrutamiento y la definición del paquete del protocolo. Figura 2, muestralos tipos de nodos del Modelo HAMAN donde opera BCHP.
137
Figura 2. Model Node Types HAMAN.2
2.3 Energy Model in NS2
Energy Model, tal como se aplica en ns2, es un atributo del nodo. El modelo de energíarepresenta el nivel de energía en un nodo móvil. El modelo de energía en un nodo tiene unvalor inicial que es el nivel de energía que el nodo tiene al inicio de la simulación. Esta esconocida como initialEngery_. También tiene un consumo de energía dada para cadapaquete que transmite y recibe; son llamados txPower_ y rxPower_. (NS-2), (Feeney, 2011),(Clases usadas por NS-2)
2.3.1 La interface OTcl
Dado que el modelo de energía es un atributo del nodo, esta puede ser definida por elsiguiente API’s de configuración del nodo: (Henderson, 2012)
$ns_ node-config -energyModel $energymodel \-rxPower $p_rx \-txPower $p_tx \-initialEnergy $initialenergy
3 Backup Cluster Head Protocol Enhanced, modelo jerárquico
En esta sección, se propone un protocolo de enrutamiento para mejorar la gestión de lasredes ad hoc denominado Backup Cluster Head Protocol Enhanced “BCHPE”.
2 Tomado de Tesis Doctoral (Torres, 2011)
138
3.1 Propuesta
Las redes móviles Ad Hoc se enfrentan a un problema grande con la pérdida decomunicación entre los nodos (Correa & Ospina, 2007), (Vicente & Dominguez, 2008) Lainestabilidad que se produce en la transmisión de información provoca muchos conflictosdentro de un topología.
La presente propuesta se diferencia de las demás y de su predecesor BCHP ya que incorporauna estrategia proactiva basada en el consumo de energía (Feeney, 2011) de los nodosprincipales Servidor Administrador y Jefe de Cluster, de tal forma que se logre gestionar demanera eficiente la red.
3.1.1. Descripción del modelo
Figura 3. Modelo propuesto para BCHPE
Como podemos observar en la Figura 3, la red es dividida en un conjunto de clusters, dondecada cluster tiene un nodo responsable o Jefe de Cluster (CH) encargado de la comunicaciónentre toda la red , un Jefe Cluster de Respaldo (BCH) que se encarga de gestionar el clusteren caso de que el principal falle, a un radio de dos saltos en el rango de transmisión del Jefede Cluster. Además está compuesto por un número arbitrario de Nodos Miembros quepertenecen a determinado cluster y Nodos Puentes (NG) a través de los cuales se comunicanlos clústers.
El proceso de descubrimiento de topología se realiza periódicamente con el fin de mantenerla red en la convergencia y sincronizar la información en todos los nodos
Una variante importante dentro de estas redes es monitorear y gestionar de forma proactivael consumo de energía (NS-2) de los nodos principales y sus respaldos, para esto
139
consideramos establecer un valor umbral (límite) en el desgaste de energía del nodo jefe decluster para lograr mantener la estabilidad en la comunicación. Cuando el nodo principalhaya llegado al tope establecido de energía, su nodo respaldo asumirá el papel como nuevojefe de cluster y se procederá a elegir un nuevo respaldo, manteniendo la conectividad en lared.
Con lo antes mencionado, se logra una comunicación eficaz y eficiente dentro de la red,atacando el principal problema de las redes ah doc. (Universidad de New York. InstitutoPolitécnico), (Feeney, 2011)
4 Implementación del Protocolo BCHPE en NS-2 – Protocolo de enrutamientojerárquico Proactivo
Esta sección describe los estados del Protocolo Backup Cluster Head Enhanced. El BCHEha sido mejorado tomando como base del protocolo BCHP. La principal diferencia entreBCHPE y BCHP es la mejora de la disponibilidad de la red a través de la inclusión de unaestrategia proactiva (estado de energía de los nodos) a los nodos CH y BCH.
El protocolo BCHPE tiene tres etapas claramente definidas:
4.1 Creación del Clúster
Cuando los nodos inician no pertenecen a ningún clúster, y su estado inicial esUNDECIDED, calculan un valor denominado métrica de acuerdo a las características develocidad, estado de la batería y ubicación dentro del clúster. Luego envían su estado juntocon el valor de su métrica a todos los nodos a través de mensajes de difusión. Con estosvalores cada nodo crea su tabla de enrutamiento y determina cuáles vecinos tienen enlacesbidireccionales hacia él. Esta información sirva para determinar los dos nodos con mejorescaracterísticas y que pueden ser elegidos CH3 y BCH4. Cada nodo almacena la dirección delCH y BCH para acelerar el proceso de enrutamiento. (Torres, 2011)
4.2 Mantenimiento del Clúster
Una vez que los clúster han sido definidos, debido al movimiento de los nodos, al consumode energía y al fallo de los nodos CH, pueden cambiar en densidad y ubicación. Además sepuede dividir o unir, por lo que para mantener la convergencia de la red es importantemantener la jerarquía del clúster.
3 Jefe Clúster4 Jefe Clúster de Respaldo
140
Cuando se unen varios cluster es posible que un nodo CH esté dentro del área de coberturade otro nodo CH, en este caso se inicia un periodo de contención. Luego de que el tiempo decontención expira se elige nuevamente el nodo CH y BCH del nuevo cluster.
Cuando un CH no está disponible, el BCH toma el valor del CH. El nodo BCH determinaque el nodo CH no está disponible debido a través del uso de mensajes periódicos y deactualización que se transmiten entre ellos. Cuando el nodo BCH asume la jerarquía, seconvierte en CH y envía un mensaje por difusión a todos los nodos del cluster informando desu nuevo estado. Nuevamente se elige de entre los nodos el nuevo BCH
4.3 Enrutamiento entre Clústers
Hay tres niveles de enrutamiento:
1. Dentro del área de transmisión: en donde los nodos pueden ser alcanzadosdirectamente ya que tienen un enlace bidireccional entre ellos y son visiblesdirectamente. Aquí el nodo origen envía la información directamente al nodo dedestino.
2. Dentro del clúster: aquí los equipos se comunican directamente entre sí a través de sutabla de vecinos. Cada nodo mantiene una tabla de enrutamiento de vecinos en dondepuede obtener la dirección del nodo que servirá como enrutador para alcanzar sudestino.
3. Fuera del cluster: donde cada CH concentra la información y la envía hacia el clústerde destino. Un nodo determina que no existe camino hacia el nodo de destino entoncesentrega el paquete al Jefe de Cluster. El Jefe de Cluster contiene una tabla deenrutamiento adicional para la comunicación entre cluster. El CH envía lainformación al cluster de destino o por difusión a todos los CH, dependiendo de sitiene una entrada en la tabla de enrutamiento al nodo de destino.
4.4 Proceso proactivo
Los nodos consumen energía en todos sus estados, el CH informa su estado de energía alBCH a través de mensajes de HELLO periódicamente hasta que informa que ha llegado allímite establecido de energía y es cuando el BCH asume el rol de CH y comunica al resto denodos del cluster su estado. Los nodos miembros inician el proceso de elección de un nuevojefe cluster de respaldo, una vez elegido se informa al jefe de cluster de cual es el nuevorespaldo, este proceso se muestra en la Figura 4.
141
Figura 4. Proceso proactivo del Jefe de Cluster
5 Métodos de Validación
Se especifica de forma general las características, topología, atributos de los nodos; así comotambién se especifica los valores que son utilizados para cada uno de los escenariosdefinidos.
5.1 Validación Matemática
Consumo de energía
La autonomía energética es un factor importante a la hora de diseñar dispositivosmóviles.
Una batería es un dispositivo electroquímico el cual almacena energía en formaquímica. Cuando se conecta a un circuito eléctrico, la energía química se transformaen energía eléctrica. Las baterías de los nodos tienen carga Q.
La carga eléctrica se define como la intensidad de corriente eléctrica que circula por elcircuito en una unidad de tiempo, como se muestra en la ecuación (3.1).= (5.1)
Donde I es la intensidad de corriente eléctrica y T es el tiempo.
142
Figura 5. Límites de Consumo de batería
Como se puede apreciar en la Figura 5, la carga de los dipositivos se encuentra al100%. Para el cálculo del límite de la carga de la batería se toma como valorreferencial que Q debe llegar a un 85% de su consumo para que se ejecute el cambiode roles entre el JC y su respaldo, lógicamente este consumo está relacionado altiempo en el cual se está dando el proceso de simulación, por tanto también hay untiempo límite, además el consumo de energía es variable dependiendo del dispositivocon que se trabaje, es por esto que se toma el porcentaje (%) y no un valor específicode carga Q. De esto se tiene la siguiente deducción:
Si:T = Tiempo de duración de la batería (5.2)
Donde Tmax representa el tiempo máximo de consumo de la batería de 1 hora.
Por lo tanto el tiempo límite es igual a:T = lT (5.3)
Y la carga límite es igual a:Q = lQ (5.4)
5.2 Validación por simulación
Usamos en Network Simualtor 2 (Ns2) para validar el protocolo BCHPE, hay otrossimuladores que incluyen MANET: OPNET5, OMNeT++6, GloMoSim7, NS38, yQUALNET9. Sin embargo ha sido elegido como:
5 OPNET, Application and Network Performance. http://www.opnet.com6 OMNet++, Discrete event simulation environment. http://www.omnetpp.org
143
El simulador NS2 es el más utilizado por los investigadores en las redes MANET. Dela cantidad total de artículos de investigación publicados que mencionan el uso de unsimulador en ACM10 y ACM7 NS2 se usó en un 43.8%. El siguiente simulador másutilizado en uso, el GloMoSim, se utiliza en un 10%. []
La experiencia y el conocimiento de la forma en que la herramienta de simulaciónfunciona.
Es gratuito y de código abierto que permite añadir nuevos protocolos yfuncionalidades.
Con el fin de definir los escenarios de la simulación, los parámetros descritos en [] se hanutilizado como base. Los valores para cada uno de estos parámetros se muestran en la Tabla1.
Para el análisis de los resultados, algunos autores [],[],[], han revisado las serise deindicadores. Con el fin de evaluar el protocolo BCHPE, inidcadores especiales han sidoseleccionados para medir la disponibilidad de la red. Estos indicadores son: rendimiento,sobrecarga, variación de retardo y la variación de retardo del paquete o jitter. Estos valoresse han comparado con los protocolos BCPE y BCHPE.
Parámetros Valores Observaciones
Área de simulación 1000m x 500m Permite la generación de más de un cluster
Cantidad de nodos 25, 30, 40, 50, 60, 70,
80, 90, 100
Para determinar el comportamiento de los protocolos
para diferente densidad de nodos en los cluster.
Cantidad de conexiones 20
Tiempo de simulación 100 En segundos
Protocolos BCHP, BCHPE
Modelo de propagación TwoRayGround Para escenarios planos y sin obstáculos
Tipo de antena Omnidireccional Necesario para el trabajo en redes MANET
Tabla 1. Parámetros generales de la simulación
6 Resultados de la simulación
6.1 Rendimiento
Se refiere a la fracción de la capacidad del canal empleado en la transmisión de datos. Es eltotal de paquetes recibidos por un destino. El establecimiento de clusters mejora eldesempeño de esta métrica. Se ha medido el rendimiento de toda la red para conexiones TCPvariando la densidad de los nodos entre 25, 30, 40,50, 60, 70, 80, 90 y 100.
7 GloMoSim - Global Mobile Information Systems Simulation Library.http://pcl.cs.ucla.edu/projects/glomosim/8 The ns-3 network simulator. http://www.nsnam.org/9 QualNet. http://www.scalable-networks.com/products/qualnet/10 Association for Computing Machinery. http://www.acm.org
144
Los valores presentados en la ¡Error! No se encuentra el origen de la referencia. muestranel comportamiento del tamaño de ventana TCP durante la transmisión desde el nodo origen(0) al nodo destino (25) de los dos protocolos de enrutamiento jerárquico simulados, es decirla cantidad de datos recibidos durante la conexión, el eje ordenado x representa el tiempo desimulación y el eje ordenado y la cantidad de datos recibidos con respecto al tiempo.
El rendimiento del protocolo BCHPE es mas estable por ser un protocolo proactivo, aunqueen términos generales BCHPE y BCHP mantienen un rendimiento promedio general.
En las figuras 6 a la 16, se puede observar que hay unos picos en declive y aumento queaparentan menor rendimiento en la recepción de paquetes, esto es debido a que la energía enesos tiempos de simulación para determinados nodos CH está en decremento y por ende seproduce un cambio de roles e inundación de mensajes anunciando los nuevos JCs en lugar derecibir los paquetes, sin embargo, tomando en cuenta las líneas de tendencia, se observa queBCHPE es mejor a pesar de mantener un rendimiento promedio.
Figura 6 Rendimiento con 25 nodos
Figura 7. Rendimiento con 30 nodos
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción25 nodos
BCHP25TCP
BCHPE25TCP
Exponencial(BCHP25TCP)
0 10 20 30 40 50 60 70 80 900
50100150200250300350400450500550600650
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción30 nodos
BCHP30TCP
BCHPE30TCP
Exponencial(BCHP30TCP)Exponencial(BCHPE30TCP)
145
Figura 8. Rendimiento con 40 nodos
Figura 9. Rendimiento con 50 nodos
Figura 10. Rendmiento con 60 nodos
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción40 nodos
BCHP40TCP
BCHPE40TCP
Exponencial(BCHP40TCP)Exponencial(BCHPE40TCP)
0 10 20 30 40 50 60 70 80 900
100
200
300
400
500
600
700
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción50 nodos
BCHP50TCP
BCHPE50TCP
Exponencial(BCHP50TCP)
0 10 20 30 40 50 60 70 80 900
100
200
300
400
500
600
700
tiempo de simulacion (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción60 nodos
BCHP60TCP
BCHPE60TCP
Exponencial(BCHP60TCP)Exponencial(BCHPE60TCP)
146
Figura 11. Rendmiento con 70 nodos
Figura 12. Rendmiento con 80 nodos
Figura 13. Rendmiento con 90 nodos
0 10 20 30 40 50 60 70 80 900
50100150200250300350400450500550600650
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción70 nodos
BCHP70TCP
BCHPE70TCP
Exponencial(BCHP70TCP)Exponencial(BCHPE70TCP)
0 10 20 30 40 50 60 70 80 900
50100150200250300350400450500550600650
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción80 nodos
BCHP80TCP
BCHPE80TCP
Exponencial(BCHP80TCP)Exponencial(BCHPE80TCP)
0 10 20 30 40 50 60 70 80 900
50100150200250300350400450500550600650
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción90 nodos
BCHP90TCP
BCHPE90TCP
Exponencial(BCHP90TCP)
Exponencial(BCHPE90TCP)
147
Figura 14. Rendmiento con 100 nodos
6.2 Retardo promedio
Para nuestro propóstio es una medida muy significativa ya que es deseable paraenviar y recibir información de gestión de red tan rápido como sea posible.
En la Figura 15, en el protocolo BCHPE el retardo de entremo promedio es muchomejor que BCHP y se se mantiene una estabilidad promedio para todas lasdensidades de nodos y se utiliza como tráfico de conección TCP. Esto significa queel uso de un protocolo de enrutamiento jerárquico proactivo es la mejor opción contráfico no orientado a conección.
Figura 15. Tasa de envío de paquetes
0 10 20 30 40 50 60 70 80 900
50
100
150
200
250
300
350
400
450
500
550
tiempo de simulación (s)
paqu
etes
/ se
gund
os
Rendimiento en Recepción100 nodos
BCHP100TCP
BCHPE100TCP
Exponencial(BCHP100TCP)
Exponencial(BCHPE100TCP)
0123456789
1011
25 n
odos
30 n
odos
40 n
odos
50 n
odos
60 n
odos
70 n
odos
80 n
odos
90 n
odos
100
nodo
s
prom
edio
byt
es e
nvia
dos
Número de Nodos
Tasa promedio de paquetes enviadosPaquetes enviados / paquetes recibidos
BCHP
BCHPE
Lineal(BCHP)
Lineal(BCHPE)
148
Figura 16. Tasa de paquetes de aplicación enviados
6.3 Pérdida de paquetes
Es la cantidad de paquetes eliminados por los nodos intermedios a causa de losefectos producidos por la movilidad de los nodos, expiración de temporizadores,destinos inalcanzables o borrados por el protocolo ARP (Address ResolutionProtocol).
Como se muestra en la Tabla 2, y se puede apreciar en la Figura 17¡Error! No seencuentra el origen de la referencia., el protocolo BCHPE pierde menor cantidadde paquetes (1.54% promedio) en relación a BCHP (2.79% promedio) para todas lasdensidades de nodos, por lo cual la mejora promedio de BCHPE vs BCHP es del1.25% en relación a la pérdida de paquetes.
Nodos
Paquetes perdidos (%)Mejora BCHPE vs
BCHP
(Diferencia)
BCHP BCHPE
25 1,5209 0,74 0,7809
30 2,3089 1,2646 1,0443
40 1,5976 1,2677 0,3299
50 4,0012 2,5344 1,4668
60 1,2655 1,2589 0,0066
70 3,0041 2,1594 0,8447
80 3,8232 1,6469 2,1763
90 4,2869 1,8332 2,4537
100 3,3374 1,1756 2,1618
Promedio de paquetes
perdidos (%)
2,793967 1,542300 1,251667
Tabla 2. Porcentaje promedio de paquetes perdidos
0.93
0.94
0.95
0.96
0.97
0.98
0.99
1
25 n
odos
30 n
odos
40 n
odos
50 n
odos
60 n
odos
70 n
odos
80 n
odos
90 n
odos
100
nodo
s
REC
/EN
V
Numero de nodos
TASA DE ENVIO DE PAQUETES DE APLICACIONTCP REC/ENV
BCHP
149
Figura 17. Paquetes Borrados
6.4 Variación de retardo de paquetes
Es la diferencia en el retardo de conecciones de extremo a estremo entre los paquetesseleccionados. En una red ad hoc ésta sirve para medir la estabilidad y convergenciade la red. Como se puede observar en la Figura 18, la variación de retardo promediode paquetes se ha obtenido para toda la red. El protocolo de enrutamiento jerárquicoproactivo BCHPE funcionan de mejor forma que BCHP con una variación muchomejor.
Figura 18. Retardo punto a punto
7 Conclusiones
Un protocolo de enrutamiento proactivo jerárquico ha sido implementado, llamadoBackup Cluster Head Protocol Energy (BCHPE). El protocolo BCHPE incluye el usode una estrategia proactiva para sus Jefes de Cluster (CH) y Jefes de Cluster deRespaldo (BCH). El comportamiento proactivo para el Jefe de Cluster de Respaldoconsiste en que cuando el Jefe de Cluster esté en un límite crítico de energía, sea
0
0.005
0.01
0.015
0.02
0.025
0.03
0.035
0.04
0.045
0.05
25 30 40 50 60 70 80 90 100
Tasa
de
pérd
ida
de p
aque
tes
Número de nodos
Tasa de paquetes borrados
BCHP
BCHPE
00.10.20.30.40.50.60.70.80.9
1
25 n
odos
30 n
odos
40 n
odos
50 n
odos
60 n
odos
70 n
odos
80 n
odos
90 n
odos
100
nodo
s
Tiem
po
Numero de Nodos
Retardo promedio extremo a extremoTCP Delay Average
BCHP
BCHPE
Lineal(BCHP)
Lineal(BCHPE)
150
reemplazado por el BCH para evitar que haya un evento en la red que da lugar lapérdida de estabilidad de la red.
El protocolo jerárquico BCHPE al ser proactivo, mantiene mayor estabilidad de lared como se puede evidenciar en el análisis de resultados, a mayor densidad de nodossu rendimiento es mejor debido a que hay más nodos que pueden ser elegibles comoCH y BCH lo que hace que la red se mantenga estable. La tasa de rendimiento depaquetes es considerablemente mayor en comparación con el protocolo BCHP.
Referencias
Correa Montes, B. A., & Ospina Alzate, L. E. (2007). Universidad PontificiaBolivariana. Obtenido dehttp://eav.upb.edu.co/banco/files/04CAPITULOS.pdf
Documentación de NS-2. (s.f.). Obtenido de http://www-sop.inria.fr/planete/software/ns-doc/ns-current/AllCode__.html#EnergyModelClass__create
Feeney, L. M. (Junio de 2011). An Energy Consuption Model forPerformance Analysis of Routing Protocols for Mobile Ad Hoc Networks.Mobile Networks and Aplications. Suecia: Swedish Institute of ComputerScience.
García Pérez, Víctor; González Peña, Fernando; Martín Sánchez, Carlos;.(2009). SARA Protocol for MANET. Tesis de Grado, UniversidadComplutense de Madrid, Facultad de Informática, Madrid.
Henderson, T. (s.f.). Information Sciences Institute. Recuperado el 2012, deEnergy Model: http://www.isi.edu/nsnam/ns/doc/node225.html
NS-2. (s.f.). APIs deEnergía.http://www.isi.edu/ilense/software/smac/ns2_energy.html
Ns2. (s.f.). NS-2. Obtenido de TraceGraph: http://ns-2.blogspot.com/2008/10/trace-graph-network-simulator-ns-2.html
Torres Tandazo, R. V. (24 de Enero de 2011). A managemente Ad HocNetworks Model for rescue and emergency scenaries. Obtenido deScienceDirect: Procedia Computer Science
Universidad de New York. Instituto Politécnico. (s.f.). Sistemas deInformación y seguridad de Internet. Obtenido dehttp://isis.poly.edu/~qiming/scengen/index.html
Vicente, C., & Dominguez, J. (2008). Network Startup Resource Center(NSRC). Obtenido de Universidad de Oregon:http://www.nsrc.org/workshops/2008/walc/presentaciones/Intro_Gestion_Redes.pdf
151
BIBLIOGRAFÍA
Basagni, S., Turgut, D., & Das, S. K. (2001). Mobility Adaptative Protocols for
Managing Ad Hoc Nextorks. IN COMUNICATIONS.
Bhagwat, P., & Perkins, C. E. (2003). University of Virginia. Obtenido de
Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV)
for Mobile Computers: http://www.cs.virginia.edu/~cl7v/cs851-
papers/dsdv-sigcomm94.pdf
Biradar, R., & Patil, V. (2006). Classification and comparison of oruting
techniques and wireless ad hoc networks. International Symposium on,
pages 7-12.
Carrillo Arellano, C. E. (2011). Análisis de Protocolo de encaminamiento para
redes inalámbricas tipo malla en modo infraestructura. Tesis Maestría.
Universidad Autónoma Metropolitana, Facultad de Informática.
Community Umbrello. (2012). Umbrello UML Modeller. Obtenido de
http://uml.sourceforge.net/
Feeney, L. M. (Junio de 2011). An Energy Consuption Model for
Performance Analysis of Routing Protocols for Mobile Ad Hoc Networks.
Mobile Networks and Aplications. Suecia: Swedish Institute of Computer
Science.
Flores, C. L. (Octubre de 2011). Monografías.com. Obtenido de
http://www.monografias.com/trabajos89/series-tiempo-algunos-metodos-
proyeccion/series-tiempo-algunos-metodos-proyeccion.shtml
Fotino, M., & De Rango, F. (2011). INTECH. Energy Issues and Energy
aware Routing in Wireless Ad-hoc Netwroks(Online). (W. Xing, Ed.) Italy:
InTech.
152
García Pérez, Víctor; González Peña, Fernando; Martín Sánchez, Carlos;.
(2009). SARA Protocol for MANET. Tesis de Grado, Universidad
Complutense de Madrid, Facultad de Informática, Madrid.
Gil Jiménez, M. E. (2009). Estudio de la eficiencia de encaminamiento del
protocolo AODV en redes ad hoc inalámbricas de gran escala. Tesis de
Ingeniería. Universidad Rey Juan Carlos, Ingeniería de
Telecomunicación.
Henderson, T. (05 de 11 de 2011). Information Sciences Institute.
Recuperado el 2012, de http://www.isi.edu/nsnam/ns/doc/node225.html
Hernandez, J. P., & Márquez, D. (2005). The Network Simulator NS-2.
Obtenido de http://www.isi.edu/nsnam/ns
INRIA Inventeurs Du Monde Numérique. (s.f.). Centro de investigación de
Redes. Obtenido de http://www-sop.inria.fr/planete/software/ns-doc/ns-
current/AllCode__.html#EnergyModelClass__create
Jaroslaw, M. (2007). Trace graph - network simulator ns-2 trace files
analyser. Obtenido de http://www.tracegraph.com/
Li, Q. (09 de 05 de 2001). El generados de escenarios. Obtenido de
http://isis.poly.edu/~qiming/scengen/index.html
Morocho Sinche, L. I. (2010). Propuesta de un modelo de gestión de red
para red móviles ad hoc. Loja: UTPL.
Noroño, N., & Fermín, J. (2012). Influencia del tamaño de paquetes sobre la
pérdida de paquetes en un enlace UDP/IP/IEEE 802.11a. 11(1).
Venexuela.
Peral, A. B., Morillo Molinuelo, M., & Sánchez-Moncayo Álvarez, J. (2007).
Estudio del rendimiento y la seguridad en redes ad hoc. Madrid:
Universidad Complutense de Madrid.
153
Quiming, L. (2002). The Scenario Generator. Obtenido de
http://isis.poly.edu/~qiming/
Royer, E., & Toh, C. -K. (1999). A review of current routing protocols for ad
hoc mobile wireless networks.
Royer, I. M. (2000). Multicast Ad hoc On-Demand Vector Distancia (MAODV)
Enrutamiento. Obtenido de draft-ietf-manet-maodv-00.txt:
http://tools.ietf.org/id/draft-ietf-manet-maodv-00.txt
scengen. (2001). Generados de escenarios. Obtenido de
http://isis.poly.edu/~qiming/scengen/index.html
Simulator, N. (15 de Octubre de 2008). Network Simulator, NS-2 Blog.
Obtenido de http://ns-2.blogspot.com/2008/10/trace-graph-network-
simulator-ns-2.html
Solano, R. (2010). Seguridad en el Enrutamiento en Redes Móbiles Ad H.
Tesis Ingeniería. Loja, Loja, Ecuador: Universidad Técnica Particular de
Loja, Escuela de Ciencias de la Computación.
The Eclipse Foundation. (2012). Eclipse. Obtenido de
http://www.eclipse.org/downloads/packages/release/helios/sr2
Torres Tandazo, R. (2012). Contribución a los Modelos de Gestión de las
Redes Móviles Ad Hoc. Tesis Doctoral. LOJA: Universidad Politécnica de
Madrid, Facultad de Informática.
Torres Tandazo, R. V. (24 de Enero de 2011). A managemente Ad Hoc
Networks Model for rescue and emergency scenaries. Obtenido de
ScienceDirect: Procedia Computer Science
Wu, Z. (2007). Los escenarios de simulación Wireless en ns-2. Obtenido de
http://www.winlab.rutgers.edu/~zhibinwu/html/ns2_wireless_scene.htm
