Post on 11-Oct-2018
UNIVERSIDAD DE COLIMA
FACULTAD DE INGENIERÍA MECÁNICA Y ELÉCTRICA
PROTOCOLO PARA DORSAL DE UNA RED MULTIPUNTO
QUE PARA OBTENER EL GRADO DE MAESTRO PRESENTA
EL INGENIERO GABRIEL ALEJANDRO GALAVIZ MOSQUEDA
ASESOR: DR. RAÚL AQUINO SANTOS
COQUIMATLÁN, COLIMA MAYO DE 2007
Universidad de Colima Preeliminares
I
1.- Introducción ..................................................................................................................... 1
2.- Estado del Arte ................................................................................................................. 3
2.1 Resumen ...................................................................................................................... 3
2.2 Introducción ................................................................................................................ 3
2.3 Breve Historia de las Comunicaciones Inalámbricas .................................................. 5
2.4 El Estándar 802.11 y sus extensiones .......................................................................... 6
2.5 Redes de área local Inalámbricas (WLAN) ................................................................. 8
2.6 Redes Multipunto ...................................................................................................... 11
2.6.1 Redes Multipunto con Infraestructura ................................................................ 11
2.6.2 Arquitectura Cliente ........................................................................................... 12
2.6.3 Arquitectura Hibrida .......................................................................................... 13
2.7 Seguridad ................................................................................................................... 14
2.8 Protocolos de ruteo para redes MULTIPUNTO ....................................................... 15
2.8.1 Enrutamiento con Multi-Radio ........................................................................... 15
2.8.2 Enrutamiento Multi-trayectoria .......................................................................... 17
2.8.3 Enrutamiento Jerárquico .................................................................................... 18
2.8.4 Enrutamiento Geográfico ................................................................................... 19
2.8.5 Enrutamiento Por Estado de Enlace ................................................................... 19
2.9 Dijkstra ...................................................................................................................... 20
2.10 Propuesta ................................................................................................................. 21
2.11 Desarrollo open-source y LINUX ........................................................................... 22
2.12 Herramientas ........................................................................................................... 24
2.12.1 Librerías ........................................................................................................... 24
2.12.2 Entorno de Desarrollo ...................................................................................... 25
2.12.3 Monitoreo ......................................................................................................... 25
2.13 Sistema de Posicionamiento Global ........................................................................ 28
2.14 Conclusiones ........................................................................................................... 30
3 Análisis del Desarrollo ..................................................................................................... 31
3.1 Resumen .................................................................................................................... 31
3.2 Diseño ........................................................................................................................ 33
3.3 IROOT ....................................................................................................................... 34
3.3.1 Procesos .............................................................................................................. 34
3.3.2 Configuración de inicio ...................................................................................... 34
3.3.3 Registro .............................................................................................................. 35
3.3.4 Establecimiento de Rutas ................................................................................... 38
3.4 NODO ....................................................................................................................... 42
3.4.1 Registro .............................................................................................................. 42
3.4.2 Formación de subgrupos ........................................................................................ 49
3.5 Conclusiones ............................................................................................................. 52
4 Pruebas ............................................................................................................................. 53
4.1 Resultados ................................................................................................................. 55
4.1.1 Un salto sin Pandora ........................................................................................... 55
4.1.2 Un salto con Pandora.......................................................................................... 55
4.1.3 Dos saltos sin Pandora........................................................................................ 56
4.1.4 Dos saltos con Pandora ...................................................................................... 56
4.1.5 Tres saltos sin Pandora ....................................................................................... 56
4.1.6 Tres saltos con Pandora ...................................................................................... 57
4.2 Análisis de Resultados .............................................................................................. 58
Universidad de Colima Preeliminares
II
4.3 Conclusión de Resultados ......................................................................................... 60
5 Conclusiones .................................................................................................................... 61
ANEXO I Código ................................................................................................................ 62
libpandora ........................................................................................................................ 62
Recibe_b .......................................................................................................................... 69
ANEXO II ........................................................................................................................... 73
Referencias .......................................................................................................................... 74
Universidad de Colima Preeliminares
III
Figura 1 PC con procesador 486 ........................................................................................... 4
Figura 2 A la izquierda un micro 486 de 1989, y a la izquierda un micro Intel core-duo uno
de los mas nuevos de Intel. Equiparables en tamaño pero no en rendimiento. ..................... 4
Figura 3 Muestra las distintas extensiones del estándar 802.11, así como los usos de cada
uno, coloreado en rojo los estándares que no se han aprobado. ............................................ 6
Figura 4 Muestra el tipo de modulación, la frecuencia de operación y la tasa de
transferencia de datos para distintos estándares de la familia 802.11 ................................... 7
Figura 5 Muestra el tipo de modulación, la frecuencia de operación y la tasa de
transferencia de datos para distintos estándares de la familia 802.11 ................................... 9
Figura 6 Red con infraestructura de 2 nodos que depende de la cobertura del PA ............... 9
Figura 7 Red multipunto con infraestructura extraída de [3]: los enrutadores forman una dorsal que permite la interconexión de distintas redes de distintas tecnologías a través de los enrutadores con la funcionalidad de pasarela/puente. ............................................................................................................................................. 12
Figura 8 Arquitectura Cliente para RMI’s tomada de [3]. ............................................ 12
Figura 9 Arquitectura híbrida exhibida en [41], que reduce el efecto de cuello de botella para las pasarelas. .............................................................................................. 13
Figura 10 Enrutador Linksys WRT54GX con tecnología MIMO ...................................... 16
Figura 11 Enrutador Belkin compatible con 802.11 a, b y g con antenas inteligentes. ...... 16
Figura 12 La mascota de Linux TUX .............................................................................. 22
Figura 13 Logo de la distribución Kubuntu que usa KDE como manejador de ventanas .. 22
Figura 14 Logo de la distribución edubuntu que usa GENOME como manejador de
ventanas y esta enfocado para usuarios jóvenes. ................................................................. 23
Figura 15 Logo de la distribución xubuntu que esta enfocado a máquinas con recursos
pobres utiliza XFCE como escritorio. ................................................................................. 23
Figura 16 Pantalla de wireshark que muestra la captura en línea de paquetes de todo tipo.26
Figura 17 Dibujo de la Constelación de satélites para el sistema de posicionamiento global
orbitando sobre la tierra. ...................................................................................................... 28
Figura 18 referencia gráfica de los nodos que se utilizaran. ...................................... 31
Figura 19 Muestra una configuración valida para los parámetros que se establecieron, punteados los enlaces con wi-fi en la frecuencia de dorsal, con guión y punto enlaces con wi-fi también pero para la parte baja y finalmente en continuo los enlaces con los sensores a través de 802.15.4. ................................... 32
Figura 20 my_callback función que recibe los paquetes para el proceso de registro para
nodos en el dorsal. ............................................................................................................... 36
Figura 21 Proceso de mantenimiento de tabla de vecinos que permite tener actualizada la
información en cada uno de los nodos. ............................................................................... 37
Figura 22 Registro de un nuevo nodo en la dorsal ...................................................... 38
Figura 23 Establecimiento de rutas en el dorsal ........................................................... 40
Figura 24 Estructura General del dorsal ........................................................................ 41
Figura 25 diagrama de la función my_callback .................................................................. 43
Figura 26 diagrama de flujo de la función analiza .............................................................. 45
Figura 27 Tmisdatos complemento de my_callback y analiza en el registro de nodos ...... 46
Figura 28 diagrama de la función de envío de Tabla de vecinos que genera una
actualización general. .......................................................................................................... 48
Figura 29 Función de recepción de Tabla global ................................................................ 48
Figura 30 Nuevo nodo sin decisión pidiendo ser pasarela a un nBB. ....................... 49
Universidad de Colima Preeliminares
IV
Figura 31 Nueva hoja un nBB. ......................................................................................... 50
Figura 32 Explicación de la petición de un servicio o comunicación ......................... 51
Figura 33 que muestra como se ubicaron los equipos para la realización de las pruebas. .. 53
Figura 34 comparativa, con y sin protocolo corriendo, de EED en paquetes de 84bytes. .. 58
Figura 35 EED Promedio para paqutes de 1028 bytes a uno dos y tres saltos .................... 58
Figura 36 comparación de EED máximo para uno dos y tres saltos sin Pandora .............. 59
Figura 37 diferencias para EED en paquetes de 1028 bytes a uno dos y tres saltos ........... 59
Figura 38 Comparativa de Throughput para uno dos y tres saltos con el protocolo corriendo
y con las rutas configuradas manualmente. ......................................................................... 60
Universidad de Colima Preeliminares
V
Summary
In the multipoint wireless networks there has not been much development
of specific protocols that allow to take advantage of all their capacities, are
implementations, like GNU ZEBRA, Locust or 4g, based on protocols developed
for, traditional ad-hoc networks (AODV) or even for wired networks (OSPF), which
definitively does not catch each one of kindness that allows the networks
multipoint. This document presents an option that propouse a metric based On
position, energy and bandwidth, basic aspects in radio networks, as well as one
structures hierarchic supported with multiple interfaces.
Resumen
En las redes de inalámbricas multiputo no ha habido mucho desarrollo de
protocolos específicos que permitan aprovechar todas sus capacidades, hay
implementaciones, como GNU ZEBRA, Locust o 4g, basadas en protocolos
desarrollados para, redes ad-hoc tradicionales (AODV) o incluso para redes
cableadas (OSPF), lo que definitivamente no capta cada una de las bondades que
permiten las redes multipunto. Este documetno presenta una propuesta de
métrica basada en posición, energía y ancho de banda, aspectos básicos en
redes inalámbricas, así como una estructura jerárquica soportada con múltiples
interfaces que permita un mejor desempeño y desgaste uniforme de la red.
Universidad de Colima Introducción
FIME
1
1.- Introducción
Los administradores de los sistemas de emergencia siempre han tenido
conciencia de lo importante de la comunicación en situaciones a las que se
enfrentan día a día, de tal manera que se han preocupado por desarrollar y/o
adquirir tecnología de punta que les permita estar enlazados lo mejor posible
durante sus operativos, ejemplos de estas tecnologías van desde los simples
radios hasta sistemas de bases de datos remotas que proporcionan información
pertinente ayudándole al operador a tomar mejores decisiones.
Lo anterior se da sin problemas en ambientes preestablecidos donde la
infraestructura que hace posible la comunicación entre el grupo de emergencia ya
ha sido previamente instalada, sin embargo en situaciones de desastres naturales
o en lugares remotos como bosques o montañas le instalación de torres de
comunicación, además de costosa, no resultaría práctica ya que sería poco
utilizada.
Una solución viable, de bajo costo y eficiente, son las redes ad-hoc ,que
son redes auto configurables y necesitan poca o ninguna intervención del usuario
para su instalación y configuración por lo que facilita su uso.
Para este tipo de redes es necesario solo desplegar el equipo, el cual
automáticamente sensara los equipos a su alrededor y establecerá comunicación
con ellos, permitiendo la interacción de los miembros del grupo de emergencia en
una red de voz y datos eficiente y robusta que tiene la capacidad de auto
regenerarse, es decir que cuando un miembro se agrega o se va la red
automáticamente reestructura las rutas de comunicación.
Con la tecnología de redes ad-hoc cada equipo funciona como un
enrutador y cliente a la vez, con capacidad para crear y actualizar las rutas
Universidad de Colima Introducción
FIME
2
necesarias para la comunicación cada vez que un equipo sufre modificaciones,
entra o sale de esta por lo que las hace ideales para situaciones de emergencia.
En este tipo de aplicaciones ha habido ya distintos desarrollos como
MeshCube[6] o locust [7] pero están basados en algoritmos para redes ad-hoc
tradicionales lo que no permite que desarrollen todas sus capacidades ya que en
las redes ad-hoc se presupone una movilidad continua situación que en las redes
multipunto no se da así, además las métricas para la selección de la ruta solo
están basadas en saltos, dejando fuera métricas esenciales en las redes de
emergencia como los son distancia y ancho de banda.
El presente documento propone un algoritmo de enrutamiento para la
dorsal de una red de emergencia con métrica basada en distancia, ancho de
banda y energía factores fundamentales que bien manejados permiten una
utilización uniforme de la red dándole así el mayor tiempo de vida posible a esta,
ya que como se puede suponer los equipos en este tipo de redes dependen
estrechamente de su capacidad de suministro de energía.
Este trabajo esta dividido en 4 capítulos, el primero es la introducción, el
segundo capitulo establece las relaciones de las bases teóricas con el desarrollo
que se propone así como los trabajos que se han realizado sobre temas similares,
el tercer capitulo se le dedica al diseño de la aplicación propuesta y el cuarto
capitulo expresa los resultados que se obtuvieron y las conclusiones sobre estos.
Un complemento, a futuro, de este trabajo puede ser la implementación de
colas de servicio par las peticiones de servicios y rutas, otro desarrollo posterior
interesante sería la implementación en UClinux.
Universidad de Colima Estado del arte
FIME
3
2.- Estado del Arte
2.1 Resumen
En las redes de inalámbricas no ha habido mucho desarrollo de protocolos
específicos que permitan aprovechar todas sus capacidades, hay
implementaciones, como GNU ZEBRA, Locust o 4g, basadas en protocolos
desarrollados para, redes ad-hoc tradicionales (AODV) o incluso para redes
cableadas (OSPF), lo que definitivamente no capta cada una de las bondades que
permiten las redes multipunto. Este capitulo presenta las bases teóricas que
permitirán sustentar una métrica basada en posición, energía y ancho de banda,
aspectos básicos en redes inalámbricas, así como una estructura jerárquica
soportada con múltiples interfaces.
2.2 Introducción
El hombre siempre ha tenido la necesidad de comunicarse y compartir
información, por lo que ha desarrollado herramientas que, a través de las distintas
etapas de su evolución, le han ido facilitando este proceso. Una llave importante
para ayudar a solucionar las necesidades de comunicación es la tecnología, que a
jugado un papel fundamental; posibilitando extender y mejorar cada vez más,
tanto la comunicación, como el acceso común a la información.
Una de las tecnologías claves ha sido el avance de la electrónica que ha
permitido desarrollar dispositivos cada vez más capaces y menos costosos, en
particular, los equipos de cómputo y las redes han avanzado rápidamente;
tenemos ejemplos claros en nuestra vida diaria, en la Figura 1, se muestra una
PC 486 a 33MHZ, MODEM de 14,400 bps y con 4mb de RAM con fecha de 1989,
nada comparable a las modernas laptops que tienen ya mucho mejor rendimiento
que la anterior descrita y a un menor costo, en la figura 2, se muestra que en
cuanto a tamaño el cambio en los microprocesadores aparentemente no ha
avanzado, sin embargo no es así, la miniaturización a permitido que en el mismo
Universidad de Colima Estado del arte
FIME
4
espacio quepan millones de transistores más, además en rendimiento es muchas
veces mejor.
Figura 1 PC con procesador 486
Figura 2 A la izquierda un micro 486 de 1989, y a la izquierda un micro Intel core-duo uno de los mas
nuevos de Intel. Equiparables en tamaño pero no en rendimiento.
Universidad de Colima Estado del arte
FIME
5
2.3 Breve Historia de las Comunicaciones Inalámbricas
Las redes de computadoras han tenido una historia relativamente corta
pero han entrado en una dinámica de crecimiento sumamente veloz, sobre todo
con la creación de estándares tanto cableados como inalámbricos, que han
posibilitado mayores contribuciones de diversos grupos.
Desde el nacimiento de las comunicaciones inalámbricas en 1985[1] esta
tecnología ha entrado en un devenir vertiginoso que ha permitido que las
comunicaciones públicas y privadas de radio, televisión y las redes inalámbricas
crezcan a pasos agigantados.
Las redes inalámbricas en especifico han ido tomando interés
particularmente rápido, la primer red Inalámbrica digital fue ALOHANET,
desarrollada en Hawai en 1971, esta permitía la comunicación de 7 campus a
través de 4 islas con una computadora central en Oahu vía radio transmisiones, la
red tenia una topología de estrella y la computadora central actuaba como
concentrador [1]; después entre la década de 1970 y principios de los 80‟s, el
Defense Advance Research Project Agency (DARPA) desarrollo una red
inalámbrica para comunicación estratégica en batalla, que se podía configurar y
reconfigurar sin la necesidad de una infraestructura preestablecida [1] hoy
conocida como red ad-hoc.
Una de las vertientes más importantes de las Redes Inalámbricas son las
WLAN (“Wireless Local Area Network”) o redes de área local inalámbricas , que
son sistemas de intercambio inalámbrico de datos, el éxito de estas redes se ha
enfatizado, debido a los altos costos de mantenimiento e instalación de sus
contrapartes cableadas, el conservar edificios históricos o el hecho de que una
red sea implementada solo por un lapso corto son factores que han ayudado a
que las redes inalámbricas se desarrollen como una alternativa seria dentro de las
redes.
Universidad de Colima Estado del arte
FIME
6
2.4 El Estándar 802.11 y sus extensiones
El estándar IEE 802.11 se ha popularizado debido a su robusto desempeño
dentro de las WLAN en la figura 3, tomada de [9] muestra las diferentes
extensiones.
Figura 3 Muestra las distintas extensiones del estándar 802.11, así como los usos de cada uno,
coloreado en rojo los estándares que no se han aprobado.
Los usuarios finales usualmente exigen las mismas capacidades en las
redes inalámbricas que las que se podrían encontrar sobre redes cableadas, para
esto, la comunidad inalámbrica debe enfrentar distintos aspectos que en una LAN
común no son un problema [2] por ejemplo:
La saturación del espectro de radio, al popularizarse, la interferencia de
otras redes inalámbricas es más común lo que resulta en un desempeño menos
eficiente. El que las señales transmitidas no estén confinadas a tramo de cable en
el interior de nuestras instalaciones sino que por el contrario viajan a través del
MESH
QoS
Seguridad
Radio
Tasas de
transferencia más
altas
Universidad de Colima Estado del arte
FIME
7
aire haciendo más fácil su intercepción, aumentan el riesgo de una intromisión no
deseada. La energía de los nodos de la red es un aspecto importante a tomar
también en cuenta, ya que los nodos móviles tienen, en la mayoría de las
ocasiones, solo su batería, mientras que en la red cableada, los equipos más
frecuentemente toman la energía de la red eléctrica. La movilidad, nula en las
redes cableadas, es una premisa en las redes inalámbricas, esto se traduce en la
necesidad de establecer la ubicación del nodo en el momento de la transmisión
para mandar la información por la ruta correcta, finalmente la capacidad de
transmisión en las redes inalámbricas si bien es cierto que se ha ido mejorando,
desde los 20kbps [1] hasta los 54 Mbps en el estándar 802.11g, las redes
cableadas han avanzado también hasta velocidades de 1 Gb con gigabit ethernet.
En la figura 4, se puede observar los estándares mas usados comercialmente de
802.11.
Figura 4 Muestra el tipo de modulación, la frecuencia de operación y la tasa de transferencia de datos
para distintos estándares de la familia 802.11
Modelos
OSI
Capa
Física (Capa 1)
Capa
Enlace
de Datos
(Capa 2)
Capa Enlace de Datos (Capa 2b)
Control de Acceso al Medio (Capa 2a)
Universidad de Colima Estado del arte
FIME
8
2.5 Redes de área local Inalámbricas (WLAN)
Como ya se menciona las WLAN son redes desarrolladas bajo el estándar
IEEE 802.11 para proveer banda ancha en una área geográficamente limitada [2]
Las WLAN funcionan básicamente de la siguiente manera:
Una BSS (Basic Service Set) o Conjunto de Servicios Básicos (CBS)
es la pieza fundamental en la arquitectura 802.11. El CSB es un grupo de
estaciones que están bajo el control directo de una sola función de coordinación.
El área geográfica cubierta por la CSB es conocida como el área básica de
servicio, (BSA por sus siglas en ingles). Teóricamente todos los nodos dentro de
una CSB pueden intercomunicarse directamente pero algunos aspectos como la
degradación de la señal debido al ambiente e interferencia de CSBs vecinas
pueden causar que algunos nodos sean invisibles para otros [2].
Las WLAN pueden dividirse en redes con infraestructura, redes ad-hoc o
sin infraestructura y mas recientemente en redes multipunto (malla) que tiene
parte de las 2 anteriores [3].
Una red ad-hoc, o Independiente CSB (ICBS), según Según Brian P.Crow
en [2], es un grupo de nodos dentro de un mismo CSB con el propósito de
intercomunicarse y compartir recursos sin la ayuda de ninguna infraestructura, en
la figura 5, se muestra una red ad-hoc con 3 miembros.
Universidad de Colima Estado del arte
FIME
9
Figura 5 Muestra el tipo de modulación, la frecuencia de operación y la tasa de transferencia de datos
para distintos estándares de la familia 802.11
Las redes con infraestructura por el contrario que las redes ad-hoc
necesitan un punto de acceso (PA) común para comunicarse, como lo muestra en
la figura 6, la red inalámbrica con infraestructura la establece un PA y se
pertenece a dicho CSB siempre y cuando se este dentro del alcance del PA
correspondiente.
Figura 6 Red con infraestructura de 2 nodos que depende de la cobertura del PA
Finalmente las redes multipunto representan una de las tecnologías
inalámbricas mas nuevas, una red multipunto (redes multipunto inalambricas RMI)
( ( ) )
ICSB ( ( ) )
( ( ) )
X
( ( ) )
( ( ) )
CSB
AP
Universidad de Colima Estado del arte
FIME
10
es una red auto-configurable y que se organiza también por si sola, aquí cada
equipo es responsable de establecer y mantener la conectividad dentro de la red
[3] esto quiere decir que cada nodo dentro de la red se comporta además de
cómo cliente, también como un enrutador.
Universidad de Colima Estado del arte
FIME
11
2.6 Redes Multipunto
Una importante característica de las redes multipunto es que son también
multi-salto, esto quiere decir que para la comunicación de dos extremos en la red
la información puede viajar a través de varios nodos, así, estos extremos confían
en los nodos intermedios para el éxito de su conexión tal como en las redes ad-
hoc [4] tradicionales pero a diferencia de estas, en las redes multipunto pueden
existir Clientes y enrutadores multipunto, estos últimos con menos o ninguna
movilidad con respecto a los clientes, es decir los enrutadores multipunto son
relativamente estables en cuanto a posición y generalmente dotados con recursos
mas robustos que los clientes. Los enrutadores multipunto pueden estar basados
en computadoras dedicadas (sistemas embebidos) o en equipos de propósito
general [3] la mayor parte de los enrutadores cuentan con múltiples radios [5] lo
que permite un mejor desempeño.
En general las redes multipunto pueden clasificarse en 3 arquitecturas
principales:
2.6.1 Redes Multipunto con Infraestructura
En este tipo de RMI los enrutadores forman una infraestructura a la que los
clientes multipunto se conectan para acceder a los servicios de la red, se agrega
a la dorsal de la red equipos que desarrollan la función de pasarela hacia Internet
y otros con la posibilidad de servir como puente entre la dorsal y otras redes
inalámbricas distintas como redes celulares o de sensores, a estos nodos se les
designa pasarela/puente. Esta arquitectura se muestra en la figura 7, tomada de
[3]
Universidad de Colima Estado del arte
FIME
12
Figura 7 Red multipunto con infraestructura extraída de [3]: los enrutadores forman una dorsal que permite la interconexión de distintas redes de distintas tecnologías a través de los enrutadores con la funcionalidad de pasarela/puente.
2.6.2 Arquitectura Cliente
Otra de las arquitecturas que corresponden a las redes multipunto es la de
cliente, aquí la red esta compuesta solo por los equipos clientes que la integran,
es decir no existen los enrutadores y los clientes por si mismos desarrollan todas
las tareas de enrutamiento y configuración por lo que son mas exigidos, en este
tipo de redes usualmente se utiliza un solo tipo de tecnología inalámbrica. La
figura 8, tomada también de [3], presenta un ejemplo de redes multipunto sin
infraestructura o redes multipunto cliente.
Figura 8 Arquitectura Cliente para RMI’s tomada de [3].
Universidad de Colima Estado del arte
FIME
13
2.6.3 Arquitectura Hibrida
Finalmente una combinación entre la arquitectura de infraestructura y
cliente se combinan para formar una híbrida, en esta los clientes pueden
comunicarse entre ellos mientras no necesiten acceder a la red principal,
comunicarse con otras redes o a nodos que no estén a su alcance. La figura 9,
describe gráficamente la arquitectura hibrida.
Figura 9 Arquitectura híbrida exhibida en [41], que combina la de infraestructura y cliente.
Entonces una red multipunto hibrida es simplemente una red que incorpora
infraestructura y se extiende con una o mas redes ad-hoc [41] además según
Asherson y Hutchison en [41], deben ser capaces de soportar clientes
inalámbricos regulares, clientes cableados y clientes mesh..
Actualmente hay distintos desarrollos sobre redes multipunto [6-8] que
incluyen hardware y software para este tipo de redes sin embargo la mayor parte
de los desarrollos de redes multipunto utilizan protocolos de comunicación para
redes ad-hoc tradicionales [3] puros o adaptados lo que, por consecuencia
natural, evita que las redes tengan un desempeño óptimo esto hace evidente la
necesidad de desarrollar tecnología enfocada a las redes multipunto sobre todo
en las primeras 4 capas del modelo OSI [10], por ejemplo:
Universidad de Colima Estado del arte
FIME
14
Para la capa física, tarjetas con múltiples radios pueden ayudar a aliviar las
interferencias, en la capa de enlace de datos, protocolos de MAC diseñados para
multi-saltos son indispensables, en este sentido ya se han estado desarrollando
diferentes opciones como MUP y SSCH [11,12], saltando la capa 3 para poder
extendernos mas en el tema, para la capa de transporte es necesario también
implementar modificaciones, aunque ya se esta trabajando en protocolos mas
adecuados como [13] y [14] aún es necesario continuar las investigaciones para
lograr hacer mas eficientes y una realidad tangible a las redes multipunto.
2.7 Seguridad
Un rubro importante dentro de las RMI‟s es la seguridad, un aspecto
precisamente crítico en este tipo de redes ya que debido a la naturaleza de estas
es más complicado presentar un esquema de seguridad [3], por ejemplo avisos
falsos de cambios en rutas, desvío de paquetes, etc. Para esto es necesario
incrementar la seguridad, aunque WEP proporciona una buena opción es
vulnerable, sin embargo el grupo de trabajo i de la IEEE para 802.11 a ha
desarrollado un protocolo basado en WEP que actualiza automáticamente la llave
de encriptación llamado TKIP [20], este actualiza la llave de encriptación cada
cierto tiempo solo que esta implementado para redes con infraestructura, en [20]
Vincent Guyot de Paris desarrollo un protocolo similar a TKIP pero para redes ad-
hoc que aun se encuentra en etapa experimental.
Por lo pronto WEP será nuestra opción ya que no hay por el momento más
opciones tangibles en el área de seguridad.
Universidad de Colima Estado del arte
FIME
15
2.8 Protocolos de ruteo para redes MULTIPUNTO
Un rubro que puede incrementar el rendimiento de la transmisión de datos
es la ruta que se escoge para que la información viaje, esto es responsabilidad de
la capa de red sobre la cual trabajan los protocolos de enrutamiento, al igual que
en los otros casos aún no se desarrollan ampliamente estos, son en su mayoría
protocolos para las redes ad-hoc como AODV[31], en la mayoría de los casos
adaptaciones de estos para las redes multipunto y en otras ocasiones no tan
comunes son protocolos dedicados exclusivamente para este tipo de redes.
En general los protocolos de red para redes multipunto [3] podemos
agruparlos en:
2.8.1 Enrutamiento con Multi-Radio
La inherente ventaja que nos da el tener la posibilidad de más de una
interfaz es similar a la transmisión “full duplex”, ya que podemos estar enviando y
recibiendo información por distintas bandas de frecuencia o dentro de la misma
banda pero en un canal distinto, otra ventaja es el usar radios de distinta
tecnología lo que nos permite darle entrada a otro tipos de redes. Un buen
ejemplo de este tipo de protocolos esta en [15] éste toma en cuenta que la red
esta conformada solo por nodos fijos, lo que le que lo ubica en pocos escenarios
donde puede ser útil y una bajo rendimiento para la movilidad de nodos, aunque
fortalece la parte de la dorsal, este tipo de protocolos aprovechan que las
interfaces inalámbricas han bajado su costo e incrementado sus funciones y
eficiencia. En la figura 10, se muestra un enrutador Linksys con múltiples radios y
antenas, el WRT54GX ya disponible.
Universidad de Colima Estado del arte
FIME
16
Figura 10 Enrutador Linksys WRT54GX con tecnología MIMO
En la figura 11 observamos un enrutador con tecnología MIMO de Belkin
(PRE-N)
Figura 11 Enrutador Belkin compatible con 802.11 a, b y g con antenas inteligentes.
Universidad de Colima Estado del arte
FIME
17
2.8.2 Enrutamiento Multi-trayectoria
El escoger distintos caminos para el viaje de la información nos provee de
un mejor balance de carga, tolerancia a fallos y mayor ancho de banda [17].
El balance de cargas se da al separar los flujos de información en caminos
distintos permitiendo una utilización uniforme de la red, esto alivia un poco el
problema de los cuellos de botella [17].
Con referencia a la tolerancia a fallos el establecer caminos alternos
permite tener opciones en caso de fallo de la transmisión, ya que no se necesita
buscar de nuevo una ruta y generar más tráfico, puesto que se tiene un camino
alterno previamente escogido.
Uno de los protocolos más usados actualmente es AODV desarrollado en
conjunto por los laboratorios Sun y la Universidad de California [31], en Estados
Unidos, este es un protocolo desarrollado para redes ad-hoc, diseñado hasta para
miles de nodos, tiene buena respuesta en ambientes móviles[31] sin embargo no
considera conceptos básicos en una red multipunto, como que la dorsal esta
prácticamente fija [3], esto es particularmente importante ya que AODV utiliza un
distintos paquetes para los procesos de descubrimiento de rutas uno es el
paquete de requisición (RREQ) que se manda cuando una maquina desea
encontrar a un nodo otro es el de respuesta de ruta (RREP) que indica al nodo
que solicito la ruta por donde debe encaminar su tráfico hacia la dirección
solicitada otro paquete mas es el de error de ruta (RERROR) que indica cuando
una ruta solicitada no ha sido encontrada, todos estos paquetes crearían una
sobrecarga de información innecesaria.
Otro punto importante es la elección de la mejor ruta que se basa en los
números de secuencia y el conteo de saltos, lo que no en todas las ocasiones
resultará ser la mejor opción, ya que puede sobrecargar a un nodo causando un
Universidad de Colima Estado del arte
FIME
18
detrimento importante en sus capacidades, drenándolo de energía y recursos,
esto resultaría en una utilización heterogéneo de la red [17].
2.8.3 Enrutamiento Jerárquico
En este tipo de enrutamiento se forman estructuras organizadas de nodos
llamados grupos, los clientes que pertenecen a este grupo pueden comunicarse
solo entre ellos y su grupo, para salir de su grupo es necesario hacerlo a través
del cabeza de grupo [3]
Para este tipo de algoritmos se pueden usar combinaciones de algoritmos
reactivos y proactivos con buenos resultados, mientras que para la comunicación
inter-grupal se usan algoritmos proactivos, para los clientes se usan algoritmos
reactivos, esto tomando en cuenta un dorsal de cabezas de grupo con movilidad
muy baja o casi nula.
De nuevo AODV en su versión “multicast” [31] es un buen ejemplo, este
crea grupos “multicast” y permite la intercomunicación de estos grupos a través de
pasarelas interconectadas, pero al igual que en su versión “unicast” solo toma los
números de secuencia y el conteo de saltos como métrica.
Otra opción dentro de los algoritmos jerárquicos es OSPF organizado en
sistemas autónomos (SA) cuyo líder o enrutador contiene una base de datos con
la información de los enlaces a su grupo, cada SA debe mandar esta base de
datos a los otros SA donde el enrutador correspondiente procesa y determina la
mejor ruta hacia cada nodo en los demás SA o también llamados dominios, si
bien es cierto que este protocolo tiene estabilidad la tiene solo para redes fijas, ya
que en un ambiente móvil genera una sobrecarga de información, sin embargo es
usado en la implementación de redes multipunto GNU ZEBRA , además no toma
en cuenta un aspecto básico en las redes con nodos móviles, la energía,
finalmente no contempla un cambio automático de enrutadores si es que alguno
falla por lo que quedarían áreas aisladas en caso de algún fallo.
Universidad de Colima Estado del arte
FIME
19
2.8.4 Enrutamiento Geográfico
Para los algoritmos geográficos es necesario contar con GPS que nos den
la ubicación de el nodo en todo momento, para estos algoritmos la métrica es la
posición de los nodos [18] así la movilidad afecta menos a este tipo de protocolos
ya que se basa en posiciones absolutas.
2.8.5 Enrutamiento Por Estado de Enlace
Otro tipo de protocolos son los de estado de enlace, en este cada nodo
tiene una fotografía de la red con la cual calcula, en base al menor número de
saltos, la mejor ruta hacia un nodo, en este rubro podemos encontrar a “Mobile
Mesh” protocolo de estado de enlace desarrollado por Kevin H. Grace para la
corporación MITRE en Estados Unidos[32], éste consta de un grupo de tres
protocolos, el primero es el descubrimiento de enlaces a través de paquetes
“Hello” mandados en “broadcast”, el segundo es el de ruteo que se desarrolla con
los paquetes LSP (paquetes de estado de enlace) que cada nodo transmite y que
sus vecinos retransmiten, por último el protocolo de descubrimiento de frontera
que detecta a los nodos que tienen conexión con la red fija y al encontrar más de
uno hace un túnel directamente con estos nodos para que se intercambien
información a través de la red cableada y no de la inalámbrica.
Aunque para la parte fija de la red multipunto puede funcionar bien, para la
parte móvil tendría un desempeño deficiente ya que se requiere actualización de
las tablas por cada cambio, ya sea agregar o quitar nodos, en la red.
Universidad de Colima Estado del arte
FIME
20
2.9 Dijkstra
Entre los algoritmos de ruta mas corta se encuentra el creado por Edsger
Dijkstra de origen holandés, este básicamente consiste en explorar los enlaces de
menos peso desde el nodo origen hasta cada uno de los demás. Una vez que se
han encontrado las rutas mas cortas el algoritmo se detiene [39].
Este algoritmo utiliza el principio del algoritmo voraz, que consiste en dadas
un numero finito de nodos, el algoritmo devuelve un conjunto S tal que SC y
que, además, cumple con las restricciones del problema inicial. Cada conjunto C
que satisfaga las restricciones se le suele denominar prometedor, si éste además
logra que la función objetivo se minimice o maximice (según convenga) diremos
que S es una solución óptima [40].
El pseudocódigo tomado de [39], que se presenta a continuación
corresponde al algoritmo de Dijkstra.
DIJKSTRA (Grafo G, nodo_fuente s)
//Se inicializamos todos los nodos del grafo. La
distancia de cada nodo es infinita
// y los padres son NULL
for u ∈ V[G] do distancia[u] = INFINITO
padre[u] = NULL
distancia[s] = 0
//encolamos todos los nodos del grafo
Encolar (cola, V[G])
mientras cola != 0 do
// OJO: Se extrae el nodo que tiene distancia
mínima y se conserva la condición
// de Cola de prioridad
u = extraer_minimo(cola)
for v ∈ adyacencia[u] do if distancia[v] > distancia[u] + peso(u,v)
do
distancia[v] = distancia[u] + peso(u,v)
padre[v] = u
Universidad de Colima Estado del arte
FIME
21
2.10 Propuesta
Como podemos observar las opciones para el desarrollo de algoritmos son
muchas, y todas con aspectos a favor y en contra sin embargo se puede ver que
distintos protocolos [31],[32] y [33] no combinan aspectos importantes en la
métrica como la posición, ancho de banda o energía que para una red multipunto
son necesarios, esto es entendible dado que no fueron pensados para este tipo
de redes y son solo adaptaciones para estas, por lo que deja muchos vacíos para
ser cubiertos.
Se propone una combinación de 3 aspectos para generar una métrica
confiable: ancho de banda, posición y energía que nos darán la oportunidad de
balancear mejor el flujo de información en la red y la sobrevivencia de los nodos,
enmarcados estos tres rubros en una estructura jerárquica y equipos con dos
interfaces, permitirá sólidos enlaces en la parte fija (dorsal) y un desgaste
homogéneo en la parte baja.
Para este documento, se realizaran las implementaciones en software
necesarias para en una etapa posterior, cuando se cuente con el hardware que se
requiere, hacer las adaptaciones pertinentes.
Universidad de Colima Estado del arte
FIME
22
2.11 Desarrollo open-source y LINUX
Linux es un sistema operativo parecido a Unix, originalmente escrito por
Linus Torvalds, pero posteriormente se desarrollaron proyectos paralelos por
cientos de usuarios, originalmente escrito para Intel 386, pero ahora se ha
desarrollado para otras plataformas como PowerPC, DEC Alpha, Sun SPARC y
SPARC64, incluso para PDA‟s [21] el sistema auspiciado por tux (la mascota de
Linux) ha ido ganando adeptos conforme los desarrollos se simplifican. La figura
12, nos muestra una imagen del carismático TUX.
Figura 12 La mascota de Linux TUX
Aunque con un kernel igual, distintos desarrollos de Linux ofrecen manejos
distintos en la instalación de paquetes y la interfaz gráfica, pero prácticamente, los
desarrollos sobre un sistema Linux debe funcionar en otras distribuciones
distintas.
Figura 13 Logo de la distribución Kubuntu que usa KDE como manejador de ventanas
Universidad de Colima Estado del arte
FIME
23
Actualmente existen muchas distribuciones distintas entre las mas
importantes están mandriva, fedora, y ubuntu [22-24] que ofrecen un sistema
totalmente gráfico muy similar a Windows, además de que proveen todo el
soporte de red que Linux tiene.
Particularmente Ubuntu que significa, “humanidad hacia otros” o “soy lo
que soy debido a lo que todos somos” [24] es una distribución de Linux que nos
ofrece un excelente soporte para controladores, Ubuntu esta disponible en varias
versiones, pero además ofrece distintos manejadores de ventanas como
GENOME y KDE, KDE ofrece
Figura 14 Logo de la distribución edubuntu que usa GENOME como manejador de ventanas y esta
enfocado para usuarios jóvenes.
mejor interfaz gráfica aunque sacrifica un poco los recursos de la máquina, ambos
son muy estables y como se menciona anteriormente cualquiera que sea el
manejador de ventanas el núcleo del sistema operativo es el mismo, potente y
estable. En las figuras 13,14 y 15 se muestran los logos que identifican algunas
distribuciones de Linux.
Figura 15 Logo de la distribución xubuntu que esta enfocado a máquinas con recursos pobres utiliza
XFCE como escritorio.
Linux ofrece una consistencia bastante deseable para la programación de
aplicaciones que necesiten manejo de las interfaces de red, protocolos de
Universidad de Colima Estado del arte
FIME
24
enrutamiento, etc. Ya que ofrece un sistema totalmente abierto para el acceso a
las interfaces con librerías ya desarrolladas por la comunidad.
2.12 Herramientas
Sin duda uno de los ejes del proyecto son las herramientas que
posibilitaron la implementación del diseño, los tres principales instrumentos fueron
Linux del que ya se comento anteriormente, las librerías que facilitaron la
interacción con el kernel del sistema, el entorno de desarrollo donde se
implemento el código y finalmente las herramientas de monitoreo dan una
radiografía de los paquetes que facilita bastante el diagnóstico en la depuración.
2.12.1 Librerías
Respecto a las librerías que se utilizaron una de estas es MAPI [25]
desarrollada por Moustafa Youssef que permite obtener estadísticas de las
interfaces inalámbricas, basada en WirelessTools.
Otro proyecto interesante en cuanto a librerías es la libPCAP disponible en
[26], esta potente librería permite la captura de paquetes de distintos protocolos
(TCP,UDP,ICMP, etc.) Además cuenta con un buen soporte y manuales muy
útiles como el que se puede encontrar en [27]. Algunas herramientas de
monitoreo de red están basadas en la librería, mencionada, se encuentra también
para Windows, ethereal [28], un analizador de protocolos.
Otra de las librerías también importante es la dnet [29] librería
multiplataforma que permite entre otras cosas:
Manipulación de las direcciones de red.
Monitorear y manipular las tablas de ruta y el cache ARP
Firewall (IP filter, ipfw, ipchains, pf, PktFilter, ...)
Monitoreo y Manipulación de las interfaces de red.
Universidad de Colima Estado del arte
FIME
25
IP tunneling.
Todas las librerías anteriores están disponibles como .h para el compilador
gcc. Pcap y dnet cuentan con un archivo de instalación mientras que mapi, que es
la menos desarrollada, aun no cuenta con tanto soporte como las otras dos.
2.12.2 Entorno de Desarrollo
El desarrollo de software sobre Linux ofrece herramientas de depuradores
par C como Anjuta, que se pude obtener en [30], desarrollado por Naba Kumar a
la cabeza, tiene un depurador, editor y una aplicación “built-in” en modo de
asistente, para crear compilaciones, entre otras cosas, este potente ambiente de
desarrollo esta disponible para cualquier plataforma Linux y varios lenguajes de
programación entre ellos C, java, Perl, Pascal, etc.
Otro entorno menos elegante pero mas ligero es utilizar el compilador
directamente en la consola auxiliado con un editor de textos propio del sistema,
en el presente proyecto se utilizó el editor kate, empacado con el sistema (ubuntu)
y el compilador gcc que se puede obtener de [37].
2.12.3 Monitoreo
Finalmente las herramientas de monitoreo que se utilizaron fueron iptraf y
wireshark (ethereal) [36] que se describen brevemente a continuación:
Ethereal, ahora llamado también wireshark, es un analizador de paquetes de
código libre disponible para ambientes Windows y Unix, que detalla el contenido
de los paquetes capturados por cualquier interfaz, ya sea inalámbrica o cableada.
Los usos de wireshark pueden ser variados: desde la docencia para desglosar los
distintos tipos de protocolo, examinar problemas de seguridad y como en el caso
Universidad de Colima Estado del arte
FIME
26
del presente proyecto para ayudar a depurar el código monitoreando la entrada y
salida de paquetes.
Algunas de las características de este analizador de paquetes son las siguientes:
• Captura de paquetes en línea y análisis fuera de línea.
• La captura de paquetes puede ser vista a través de una GUI o vía TTy
• Análisis robusto de VoIP
• Paquetes comprimidos pueden ser descomprimidos instantáneamente.
• Los paquetes son coloreados para un mejor análisis.
La Figura 16 muestra una captura impresa de la pantalla de wireshark en
una red lan inalámbrica.
Figura 16 Pantalla de wireshark que muestra la captura en línea de paquetes de todo tipo.
IPTraf es otra aplicación para monitoreo en modo de consola que se utiliza
bajo Linux para generar estadísticas de red. Provee de gran cantidad de datos
tales como paquetes de conexión TCP, conteo de bytes, estadísticas de
Universidad de Colima Estado del arte
FIME
27
interfaces e indicadores de actividad, interrupciones de trafico TCP/UDP entre
otros.
Características
Monitoreo de tráfico IP, muestra información sobre el tráfico que pasa en
una red , incluye información de TCP flag, contador de paquetes y bytes,
detalles de ICMP, tipos de paquetes OSPF.
Genera estadísticas detalladas de las interfases sobre paquetes IP, TCP,
UDP, ICMP, non-IP y otros paquetes IP, chequeo de errores IP, actividad
de las interfaces, tamaño de paquete.
Monitoreo de servicios TCP y UDP por puerto.
Estadísticas en una LAN, descubre actividad en los host y el tráfico que en
ellos se da.
TCP, UDP, y otros protocolos, aplica filtros para ver solo el tráfico de
interés.
Registro
La información generada por IPTraf para el proyecto constituía un elemento
importante al hacer las pruebas de nuevas rutinas ya que identifica plenamente
los paquetes que viajan por la interfaz a analizar.
Así con lo anterior se puede ver que el desarrollo de protocolos para redes de
cualquier tipo es perfectamente viable en un sistema Linux, ya que esta
desarrollado para redes y que ofrece ventajas importantes como la facilidad en el
manejo de interfaces con herramientas como “wirelesstools” iptraf[38],
ethereal[36] y gcc[37].
Universidad de Colima Estado del arte
FIME
28
2.13 Sistema de Posicionamiento Global
Uno de los aspectos importantes en las redes inalámbricas es la distancia,
ya que de esta dependen en cierta medida la capacidad de conectividad de un
nodo hacia otro.
Una herramienta que ha ido tomando importancia es el Sistema de
Posicionamiento Global (SPG) que nos da la posición geográfica en donde nos
encontramos, esto auxiliado de una constelación de 24 satélites puestos en orbita
por los Estados Unidos [34] los cuales proveen de nuestra posición con errores
que van desde algunos metros hasta centímetros en el caso de SPG‟s
geodésicos.
En la figura 17, tomada de [34], podemos observar una simulación de cómo
esta distribuida la constelación del sistema de posicionamiento global.
Figura 17 Dibujo de la Constelación de satélites para el sistema de posicionamiento global orbitando
sobre la tierra.
La entrega de información de los SPG para la computadora puede ser en
formato NMEA (National Marine Electronics Association) o asociación nacional de
electrónica marina que fue definido para el intercambio de información con
distintos equipos, por la marina Estadounidense. Este consiste en sentencias que
definen la manera en como se va a enviar la información, para el caso de las
Universidad de Colima Estado del arte
FIME
29
coordenadas geográficas y tiempo una sentencia adecuada es la GPGLL o GP
que indica que es una sentencia NMEA para SPG y GLL que es Longitud y Latitud
Geográfica, el formato de esta es el siguiente [35]:
$GPGLL,4916.45,N,12311.12,W,225444,A,*31
Donde:
GLL Longitud y Latitud Geográficas
4916.45,N Latitud 49 grad. 16.45 min. Norte
12311.12,W Longitud 123 grad. 11.12 min. Oeste
225444 tiempo en formato 22:54:44 UTC (Tiempo Universal Coordinado)
A Dato Activo o V (void)
*31 checksum
Esta, para el caso de tiempo latitud y longitud es una buena opción ya que
es la que tiene menos datos sin utilidad para el propósito que ya se menciono.
Universidad de Colima Estado del arte
FIME
30
2.14 Conclusiones
El hombre ha tenido siempre la necesidad de comunicarse y ha buscado
cada vez más, mejores maneras de hacerlo, sobre todo en situaciones donde se
requiere una coordinación para su sobrevivencia.
Después del análisis realizado a los distintos protocolos de rede multipunto
existentes y las tecnologías actuales, manifiestan la necesidad de un algoritmo de
enrutamiento que cubra los vacíos que los actuales no han tomado en cuenta, por
ejemplo métricas esenciales como distancia y el ancho de banda, esto pone de
manifiesto la necesidad y pertinencia de la implementación que a continuación se
propone.
Universidad de Colima Análisis del Desarrollo
FIME
31
3 Análisis del Desarrollo
3.1 Resumen
A través del capitulo se describirá la conformación de la red de emergencia
apoyado con distintos iconos, la figura 18 asocia un icono con un rol determinado
dentro de la red esta será tomada en cuenta para figuras posteriores.
Figura 18 referencia gráfica de los nodos que se utilizaran.
La estructura de la red de emergencia, consiste en una dorsal con n nodos
fijos que pueden tener hasta 3 hijos, cada uno denominado pasarela y que este a
su vez podrá tener 6 hijos mas cada uno. Dentro de la dorsal también puede
agregarse una pasarela para sensores que tendrá la única función de reportar el
estado de estos al nodo principal.
Una configuración posible con las condiciones previamente descritas se
muestra en la figura 19.
Nodo de dorsal
Nodo Común
Stargate
Sensor
G Pasarela
Universidad de Colima Análisis del Desarrollo
FIME
32
Figura 19 Muestra una configuración valida para los parámetros que se establecieron, punteados los enlaces con wi-fi en la frecuencia de dorsal, con guión y punto enlaces con wi-fi también pero para la parte baja y finalmente en continuo los enlaces con los sensores a través de 802.15.4.
El objetivo de este trabajo estará en desarrollar el algoritmo que forme y
mantenga comunicado a la dorsal sin preocuparse por transferencia de
información en la parte baja, que será tarea de un proyecto que se realizo en
paralelo, el algoritmo desarrollado para la dorsal deberá ser capaz también de una
vez recibida información desde una pasarela retransmitirla al destino indicado,
todo esto sin impactar de manera significativa en el trafico de la red.
( ( ) )
Internet
( ( ) )
( ( ) )
( ( ) )
( ( ) )
( ( ) )
( ( ) )
G G
G
G
G
Universidad de Colima Análisis del Desarrollo
FIME
33
3.2 Diseño
Los nodos en la dorsal no tendrán movilidad por lo que esta parte de la red
solo cambiara cuando un nodo se de de baja por cualquier razón o se agregue
uno nuevo; por esto, el algoritmo para este nivel debe ser proactivo, ya que el
generar rutas a pedido provocaría un retardo en el traslado de la información; los
elementos de la dorsal pueden trabajar en una frecuencia y segmento de red
distinto al de las pasarelas y nodos comunes, esto para darle más solidez y
minimizar el tráfico, aunque como se especifica en la propuesta para este
documento se contara solo con una interfaz pero estarán los procesos
estructurados para adaptarlos fácilmente cunado se tenga el hardware necesario,
esto indica que para cada equipo en esta parte de la red es posible tener dos
interfaces inalámbricas, una para comunicarse con sus iguales y la otra para
formar grupos. De esta manera se le da flexibilidad y solidez al protocolo
permitiendo trabajar con una interfaz en caso de que no exista otra o se halla
caído por alguna razón, si se cae la interfaz conectada a la dorsal este nodo
quedara inactivo.
Habrá un nodo principal que contara con una interfaz extra para estar
conectado a Internet, esta puede ser de preferencia cableada, aunque también
podría ser inalámbrica conectada a un punto de acceso de una red con
infraestructura común, este nodo tendrá comportamientos distintos a los nodos
comunes y merece una explicación aparte por lo que se dedicara una parte de
este capitulo para analizar su comportamiento, otra a las acciones de los nodos
comunes de la dorsal.
Universidad de Colima Análisis del Desarrollo
FIME
34
3.3 IROOT
3.3.1 Procesos
En este apartado se describen los procesos involucrados en la dorsal
registro, eliminación, establecimiento de rutas, etc.
3.3.2 Configuración de inicio
Antes que el programa comience deben de inicializarse las banderas y
funciones que permiten la recepción de paquetes y establecimiento de rutas para
esto se creo la función Miinicio() que se encarga de definir la configuración inicial
del IROOT, en primer lugar obtiene la ip, elemento que se vuelve esencial en los
diversos procesos que se involucran, posterior a ello se toma los valores de MAC,
tiempo, latitud y longitud para la etapa de prueba y por la escasez de GPS estos
valores se toman desde un archivo almacenado en /etc/gps y de nombre lgps, el
nivel de energía la tomamos con la función que se implemento batery() y la tasa
de transferencia con la función bitrate() que tomamos de la librería mapi.h estos
son los parámetros que permitirán conocer la calidad del enlace.
Para el IROOT desde el inicio se definen configuraciones importantes;
primero se establece como nodo de dorsal, ya que como su nombre lo indica es la
raíz de la red con conexión a Internet, posteriormente, para diferenciarlo de todos
los demás nodos, se le asigna un ID 1.
Por ultimo limpiamos nuestra tabla de vecinos la cual puede almacenar un
máximo de 6 vecinos y lanzamos la función de iniciatRuteo(), función que inicia
todo el proceso de actualización de rutas.
Universidad de Colima Análisis del Desarrollo
FIME
35
3.3.3 Registro
Una vez que el nodo adquirió una IP entonces se procede al registro de
este en la dorsal a través de mensajes udp enviados a sus vecinos, para poder
ser registrado se debe contar con la clave WEP preestablecida, y la bandera
correspondiente para indicar que es un nodo con capacidades de dorsal.
El proceso de integración comprende dos partes como ya se había
comentado una en el IROOT y otra en los nodos comunes, por el momento se
explicara lo referente al nodo IROOT que consiste en que una vez que el nodo
común ha recabado información de su entorno y se la envía el IROOT la integra
en la tabla general Debido a que en este nivel se manejan puertos distintos a los
de la parte baja solo es necesario preguntar si el paquete proviene de un nodo
distinto al que escucha para no confundir al sistema con nuestros propios datos
ya que necesariamente será de un nodo perteneciente a la red fija. Los diagramas
de flujo de la figura 20,21 explican las funciones que permiten registrar al nodo y
la figura 22 representa de manera más intuitiva estas funciones.
En la función my_callback recibimos paquetes “hello” para su análisis, el
objetivo aquí es buscar cuales paquetes nos ofrecen información de nodos para
integrarlos a nuestro grupo de vecinos, para que esto suceda antes debemos
verificar que el nodo este en condiciones de realizar esta tarea, las
consideraciones se explican a continuación:
Primero en el instante de recepción de un paquete no debemos estar
haciendo uso de la tabla de vecinos la razón es que un cambio en esta tabla
afecta a la información contenida en la tabla global ya que las modificaciones se
realizan directamente sobre ella, la variable procesandoR sirve como semáforo
para controlar esta acción.
Si la variable antes mencionada tiene valor de uno no permitirá hacer
movimientos por lo que cuando esto suceda se cuida que los tiempos se
mantengan actualizados para cuando se corra el proceso completo lo haga de
Universidad de Colima Análisis del Desarrollo
FIME
36
forma correcta de otra forma se daría de baja a los nodos aun cuando sigan
activos por que el valor de esta variable no estaba actualizado.
My_callback
ProcesandoR=0
nodo
NO
SI
NO
SI
SI
NO
BuscatHost
Esta?
Analiza( )
ProcesandoR=0
Nodo=„B‟
procesandoH=1
Tmp=nodoprocesandoH=0
FIN
Actualiza Nodo
NO
SI
Figura 20 my_callback función que recibe los paquetes para el proceso de registro para nodos en el
dorsal.
Ahora en caso contrario si no se esta procesando peticiones de
enrutamiento se cuidara que el paquete que recibo sea de tipo B (de dorsal) si
esto se cumple se le avisa al sistema que se hará modificaciones a la tabla de
vecinos habilitando la variable procesandoH, en este punto se obtiene otro valor
que define la calidad del enlace y hace referencia al peso, conformado por
Universidad de Colima Análisis del Desarrollo
FIME
37
factores como numero de usuarios, energía, ancho de banda actual y la distancia
del nodo IROOT al nodo fuente.
Una vez que se termina esto llama a la función analiza una vez que regresa
de la función entonces se desbloquea la recepción de peticiones de enrutamiento
deshabilitando procesandoH , a continuación se explica la función analiza y se
apoya la descripción con en el diagrama de la figura 21.
En Analiza se realizan tareas especificas de mantenimiento de la tabla de
vecinos de igual forma actualizamos la posición cero de la tabla global ya que en
ella se ubica la información referida al IROOT.
La primera tarea es la asignación de los valores de id, ip y peso en la posición
cero, después pregunta por el paquete que llego para saber si se trata de un
vecino si fuera el caso actualiza su información en la tabla global y en la de
vecinos.
Después de esto hace un recorrido por la tabla de vecinos para buscar por
nodos que no se han actualizado, y proceder a su baja.
analiza
Esta=0
i=0
i<6
Esta=0
TH.id=tmp.idi++
i=0
i<6
TH[i]=vacio
i++
dbw=TS-TTH dbw>10
TH=TablaHost
TS=Tiempo del sistema
TTH=Tiempo de Tabla Hello
SI
NO
SI
SI
NO
SI
SI
NO
NO
i=0
movN=2
&
NO
NO
Baja Usuario
procesandoR=1
envTimer()
FIN
Actualizo TH[i]
Esta=1
Actualizo TH
%
%
Figura 21 Proceso de mantenimiento de tabla de vecinos que permite tener actualizada la información
en cada uno de los nodos.
Universidad de Colima Análisis del Desarrollo
FIME
38
Las funciones que se acaban de describir se resumen en un esquema más
intuitivo en la figura 22 que da una visión en un nivel más alto del proceso de
registro.
Internet
iroot
nBBUb
Al llegar un nuevo nodo se intercambian paquetes para petición y aceptación en el backbone
Una vez que se acepta a un nuevo nodo el vecino que lo acepta envía su actualización de rutas en bcast
nBB
Después de 1 segundo
todos ejecutan Dijkstra para
rehacer las rutas por el
nuevo vecino
Figura 22 Registro de un nuevo nodo en la dorsal
3.3.4 Establecimiento de Rutas
Una vez que el nodo se ha registrado mediante el proceso explicado en el
apartado anterior el nodo principal (IROOT) empieza la comunicación para la
parte de enrutamiento que consiste en insertar en la tabla global que guarda la
configuración detallada de la red, es decir que nodos existen, cuales se
comunican entre si y como es la calidad del enlace entre estos. Una vez que se
determina esta información el IROOT lanza un paquete para que todos los nodos
conozcan la nueva actualización.
Así mediante este procedimiento cada nodo en la parte fija de la red tendrá
una fotografía de ésta determinando a través del algoritmo de ruta más corta,
Universidad de Colima Análisis del Desarrollo
FIME
39
Dijkstra ,reenviar la información que se le solicita. Una vez que a cada nodo le
llega un paquete de un nuevo nodo o uno para avisar que se dio de baja algún
equipo debe de ejecutarse de nuevo el algoritmo de ruta mas corta para
reacomodar las rutas.
Anteriormente se hablo que el protocolo determinaba la calidad del enlace
entre cada nodo, esto lo hace con una métrica compuesta que genere un peso
único y estará determinado por:
- Distancia (30%)
- Energía (10%)
- Ancho de Banda (30%)
- Usuarios (30%)
La Distancia, ancho de banda y Usuarios tienen el mismo peso debido a
que se consideran igual de importante ya que un aumento en cualquiera de estos
parámetros afecta importantemente la calidad del enlace provocando mayor
perdida de paquetes o el retardo en la entrega de estos, en cuanto a la energía no
será muy critica ya que los nodos de dorsal, debido a su movilidad nula, podrán
tener fuentes de energía mas robusta.
Esta métrica se estará actualizando dinámicamente cada 2 minutos ya que
la dorsal no presentara mucho movimiento en cuanto entrada y salida de nodos lo
que permite darle un tiempo de actualización mayor.
Los nodos de dorsal estarán enviando paquetes ligeros para avisar que
están vivos cada 5 segundos y cada vez que exista un cambio (alta o baja de
nodos) se avisará con paquetes con más información que contendrá los cambios
en las tablas estos serán retransmitidos por los nodos vecinos hasta que se
alcance a el dorsal para que este lo agregue a la tabla global y se los envíe a
todos los nodos.
Universidad de Colima Análisis del Desarrollo
FIME
40
En la figura 23 se muestra un esquema que ayuda a asimilar el
establecimiento de rutas. Las rutas se establecen directamente en el sistema con
la librería dnet y algunas auxiliados del comando “ip route” a través de la
instrucción “system” de C para cuando están a un salto.
Internet
iroot
nBBnBB
Para ejecutar Dijkstra cada nodo, debe rellenarse la estructura vertex
DijkEdge connections[6]
int numconnect
int distance
int isDead
short int ID
ULI MiIPr;
Después de ejecutarse dijkstra se establecen las rutas en el sistema y quedan comunicados los nodos por el mejor camino
nBB
Figura 23 Establecimiento de rutas en el dorsal
Las tablas de enrutamiento contiene información básica ID, dirección física,
ip y Peso del enlace entre el nodo propietario de la tabla.
Una vez que el dorsal se ha formado, la estructura es similar a la mostrada
en la figura 24 con nodos dedicados al transporte de información solamente, con
rutas presentes para cada nodo siempre que este presente ya que esta fija, nodos
de pasarela y los nodos de cada uno de estos.
Universidad de Colima Análisis del Desarrollo
FIME
41
Figura 24 Estructura General del dorsal
( ( ) )
Internet
( ( ) )
( ( ) )
( ( ) )
( ( ) )
( ( ) )
( ( ) )
G G
G
G
G
Universidad de Colima Análisis del Desarrollo
FIME
42
3.4 NODO
En el apartado anterior se describió el proceso de registro y enrutamiento
para el nodo principal ahora la explicación se enfocara en los nodos comunes
3.4.1 Registro
En este proceso están involucradas tres funciones my_callback(),
Tmisdatos() y Analiza() que se explicaran a continuación con los diagramas de las
figuras 25, 26 y 27.
Se empezará describiendo la fusión que recibe los paquetes:
My_callback recibe los paquetes “hello” pero solo los procesa si vienen de
un nodo de dorsal:
La función my_callback primero pregunta si el “hello” es de dorsal si lo es
verifica que no se este procesando paquetes de enrutamiento, preguntando por
rcbHB si es 0 entonces deshecha el paquete, si es 1 entonces verifica que el
estatus de el nodo local sea U (sin decisión).
Si el nodo local es U entonces pregunta si recibió el “hello” del IROOT, si
lo recibió de este entonces lo agrega a sus rutas directas, si no, entonces
establece que alcanzará al IROOT a través del nodo que acaba de recibir.
Posteriormente copia el “hello” a una estructura temporal (tmp), obtiene el peso
hacia el nodo y llama a la función analiza que se encargara de dar de alta, baja o
solo actualizar al nodo.
Si el nodo local no es U entonces solo copia el “hello” a tmp, obtiene el
peso hacia el nodo que recibió y manda llamar a analiza.
Universidad de Colima Análisis del Desarrollo
FIME
43
Finalmente regresa a payload() para esperar un “hello” más. La figura 25
representa la explicación anterior en un diagrama de flujo para facilitar su
explicación.
Figura 25 diagrama de la función my_callback
La siguiente función es la de Analiza() que es llamada por my_callback
()(recepción de hellos) esto para dar mantenimiento a la tabla de vecinos (alta,
bajas y actualizaciones).
my_callback
Hello de B
Escucha Hellos
PermHB =1
RecibiHB =1
Misdatos = „ U ‟
Hello.id = Iroot
rutaSys
Iroot via dev eth1
Ruta
Dst : ip1id
Gw:ipHello
Tmp = hello
Peso(hello ) Misdatos.npeso =
pesoNodo(Iroot )
goto my_callback
*
*
analiza
goto my_callback
NO
SI
SI
SI
SI
NO
NO
NO
Universidad de Colima Análisis del Desarrollo
FIME
44
Primero busca al nodo que llego en la tabla de vecinos, si se encuentra
(esta=1) se actualiza el vecino con los nuevos datos y aborta la búsqueda si no se
encuentra sigue buscando hasta el final de la tabla de vecinos.
Entra en otro ciclo que permitirá dar de baja o alta. Se recorre la tabla en
busca de lugares que tengan vecinos activos (TH[i]=vacio) cuando encuentra una
posición ocupada toma el tiempo del sistema y se lo resta al del vecino en esa
posición (TS-THH) se asigna a dbw, si esta es mayor que 10 quiere decir que ya
hemos dejado de recibir paquetes de este nodo por mas de 10 segundos (2
hellos), se dará de baja, especificando que se ha dado de baja a un nodo para su
posterior notificación al IROOT (movN=2) Si la diferencia no es mayor de 10
entonces seguimos revisando la tabla de vecinos hasta finalizar (i<6) si hubo una
baja se avisa de esta al IROOT (EnviotRuta).
Si no se encontró el nodo (esta=0) entonces se verifica que halla capacidad
para admitirlo si la hay se da de alta, después se asegura de que el periodo de
espera al inicio halla terminado (envieIR>6) si termino entonces se notifica al
IROOT, si no terminó la función finaliza, de no haber capacidad o si se encontró
entonces la función termina.
A continuación se presenta la figura 26 que establece en forma grafica la
explicación anterior
Universidad de Colima Análisis del Desarrollo
FIME
45
analiza
Esta=0
i=0
i<6
Esta=0
TH.id=tmp.id
Actualizo
Tmp
Esta=1
i++
i=0
i<6
TH[i]=vacio i++
dbw=TS-TTH dbw>10 Baja Usuario
TH=TablaHost
TS=Tiempo del sistema
TTH=Tiempo de Tabla Hello
SI
NO
SI
SI
NO
SI
SI
NO
NO
NO
*
Esta=0
capacidad
Alta
Fin
EnviotRuta
i=0
movN=2
movN=2
envieIR>6
NO
NO
SI
SI
SI
SI
NO
NO
envieIR>6
EnviotRuta
&
&
NO
Figura 26 diagrama de flujo de la función analiza
Para completar el proceso de registro se describirá la parte que envía los
paquetes “hello” llamada Tmisdatos() que tiene sin duda diferencias importantes
con la correspondiente en el IROOT.
Tmisdatos() es la función encargada de enviar los paquetes “hello”, esto lo
realizara de dos maneras distintas, se inicia desde el comienzo del programa:
Primero se dan 5 segundos de espera para dar tiempo a que el nodo
escuche a todos sus vecinos y no sobrecargue la red de trafico, la variable
envieIR controla el tiempo de espera aumentando cada vez que se envía un
“hello”, siempre y cuando se halla recibido ya un “hello” de la dorsal. Si envieIR
aun es menor que 6 entonces se verifica que el estatus del nodo local se U (sin
decisión) si lo es entonces se toma el tiempo del sistema (get_tiempo()) envía el
hello y se duerme 1 segundo, cuando despierta se pregunta si ya recibió un
“hello” de dorsal si si aumenta envieIR en 1 y posteriormente aumenta Kpaz en 1,
si no ha recibido aun un “hello” de la dorsal entonces solo aumenta Kpaz en 1. Si
Universidad de Colima Análisis del Desarrollo
FIME
46
Kpaz es mayor o igual a 5 permisoHB se hace 1, esta servirá para cuando pierda
su gw.
Si ya se cumplieron los 5 segundos y se recibió un “hello” de la dorsal,
entonces envieIR deberá ser ya mayor de 6, toma el tiempo del sistema aumenta
kpaz en 5 y pregunta si es Hruteo=0 esto para asignarle el estatus de B al nodo
local una sola vez envía el “hello” con su estatus actualizado y Hruteo lo hace 1 ,
se duerme 5 segundos, si ya es dorsal, si no, solo 1 segundo, al despertar ,
pregunta si kpaz es mas de 120, esto para actualizar sus datos para el peso
(Posición y energía). Al final regresa al comienzo para volver a manda un “hello”
ya como dorsal.
Esta información se puede visualizar mejor con la figura 27 que explica
detalladamente los procesos en la función Tmisdatos():
*Tmisdatos
envieIR ≥ 6
Kpaz+5
HRuteo=0
Misdatos=„B‟
envioHellos
HRuteo=1
Sleep(5)
Misdatos=„U‟
get_tiempo()
Sleep(1)
rcbHB=1 envieIR++
Kpaz++
Kpaz ≥ 5 PermisoHB=1
NO
SI
SI
NO
SI
NO
SI
*
Kpaz ≥ 120
SI
NO
*
NO
SI
NO
envioHellos()
get_tiempo()
EnviotRuta()
Misdatos=„B‟Sleep(1)
&
&
Actualiza datos
Kpaz=0
*
Figura 27 Tmisdatos complemento de my_callback y analiza en el registro de nodos
Universidad de Colima Análisis del Desarrollo
FIME
47
El enrutamiento para los nodos comunes se desarrolla a través de las
actualizaciones que se reciben del nodo principal, cada vez que se modifican los
enlaces de algún nodo se le notifica a el IROOT y este a su vez procesa la
información, esta actualización no es inmediata dado que, cuando los vecinos de
un nodo se modifican, el IROOT sabe que los nodos alrededor de este que se
modifico también mandaran su actualización, por lo que espera a recibirlas para
que después de ingresarla a la tabla global difundirla entre todos los nodos.
Una vez que se ha recibido la tabla global cada nodo ejecuta localmente el
algoritmo de Dijkstra para establecer la mejor ruta hacia cada uno de los nodos
existentes y como ruta por defecto al nodo que lo lleve hacia el IROOT, como se
menciono previamente Dijkstra habrá determinado ya, basado en el peso de los
enlaces, que este es el mejor camino para llegar al nodo principal.
Debido a que el enrutamiento depende totalmente de la actualización
proveniente del IROOT se hacen ciertas consideraciones para asegurarse que la
tabla llegue, una de ellas es el reenvío de la petición de la tabla global que se
solicita mientras no llegue, otra de ellas es establecer un periodo de espera para
enviar las modificaciones locales, esto para no provocar perdidas de paquetes por
exceso de tráfico, ya que los vecinos también mandaran sus actualizaciones,
todas estas consideraciones se muestran detalladamente en los diagramas de
flujo de la figura 28 y 29
La figura 28 describe la función EnviotRuta(), este proceso se lanza cuando
se ha sufrido una modificación, o bien han pasado ya dos minutos desde la ultima
actualización, se limita a mandar la tabla con un retardo programado hasta
asegurarse de haberla recibido.
Universidad de Colima Análisis del Desarrollo
FIME
48
EnviotRuta
Abre Socket
4955
Hruteo=1
RcbTG=0
RcbTG=0
NO
NO
SI
SI
usleep(wfns)
Envia nodoIROOT
4955Sleep (4) movN='3‟RcbTG=0
FIN
Cierra socket
Figura 28 diagrama de la función de envío de Tabla de vecinos que genera una actualización general.
El siguiente esquema de la figura 29 corresponde al proceso que sucede
una vez que se ha recibido una actualización de rutas, este consiste en ejecutar
localmente Dijkstra y establecer las rutas correspondientes.
Figura 29 Función de recepción de Tabla global
A continuación se describe brevemente la formación de la parte baja que
solicita servicios, que aunque fuera del alcance de este documento vale la pena
dedicarle algunos párrafos para dimensionar el alcance del proyecto
Ruteo Callback
Mi version< version pkt
Actualizo
maintable
Reenvío
TG
Dijkstra
FIN
NO
SI
Universidad de Colima Análisis del Desarrollo
FIME
49
3.4.2 Formación de subgrupos
Este documento se desarrollo en paralelo con otro proyecto que se encarga
de formar subgrupos apoyados en la dorsal implementado en el presente trabajo
por lo que a manera de presentación de una visión global del proyecto se
presenta brevemente una explicación de cómo es que interactúan estos dos
proyectos.
Para agregar la parte de las pasarelas (G) es muy similar al proceso de
unirse la dorsal es decir se intercambiaran tres paquetes de control, iniciando el
nodo que llega sin decisión, el siguiente paso se da en el nBB que verifica si tiene
menos de 3 pasarelas, si es así le contesta un paquete más para indicarle que fue
aceptado y que cambie su estado, finalmente el nodo, ya pasarela, le confirma su
cambio de estado y lo toma como ruta por defecto para la salida a Internet, este
proceso se ejemplifica en la figura 30.
Internet
iroot
nBBnBB
nBB
U
( ( ) )
Si el nBB detecta un
nuevo nodo inicia el
proceso de aceptación
para hacerlo gaeway(1)
Si se acepta al nodo el
nBB lo agrega a sus
tablas de enrutamiento
Los demás nBB
no se enteran del
cambio en su
vecino
Internet
iroot
nBBnBB
nBB
U
( ( ) )( ( ) )
Si el nBB detecta un
nuevo nodo inicia el
proceso de aceptación
para hacerlo gaeway(1)
Si se acepta al nodo el
nBB lo agrega a sus
tablas de enrutamiento
Los demás nBB
no se enteran del
cambio en su
vecino
Figura 30 Nuevo nodo sin decisión pidiendo ser pasarela a un nBB.
Universidad de Colima Análisis del Desarrollo
FIME
50
Una vez que el nBB recibe la confirmación agrega una ruta a su tabla que
le indique que tiene una nueva pasarela, este cambio se mantiene local, es decir,
no se informa a ningún nodo vecino.
Cuando se agrega una nueva hoja o nodo1, la única acción del nBB cuando
se entera a través de la pasarela, es agregar una ruta en sus tablas para saber
que se puede llegar a al nodo de dorsal por medio de esa pasarela y para
buscarlo posteriormente si es requerido por una hoja dentro del mismo nBB o en
otra isla. En la figura 31 se esquematiza la explicación para mejor entendimiento
Internet
iroot
nBB
( ( ) )
G
( ( ) )
nBB
Cuando el nBB recibe el paquete de que se agrego una nueva hoja lo agrega a sus rutas vía el G para búsquedas posteriores
USi se encuentra un nuevo nodo se agrega al gatewayy este envía un aviso al nBB
Los demás nBB
no se enteran del
cambio en su
vecino
Internet
iroot
nBB
( ( ) )( ( ) )
G
( ( ) )( ( ) )( ( ) )
nBB
Cuando el nBB recibe el paquete de que se agrego una nueva hoja lo agrega a sus rutas vía el G para búsquedas posteriores
USi se encuentra un nuevo nodo se agrega al gatewayy este envía un aviso al nBB
Los demás nBB
no se enteran del
cambio en su
vecino
.
Figura 31 Nueva hoja un nBB.
Lo anterior explica la parte formativa del protocolo, en cuanto a prestación
de servicios, estará dedicado como red de transporte.
1 Este proceso corresponde a un trabajo paralelo, específicamente, a la formación de grupos en ad-hoc
Universidad de Colima Análisis del Desarrollo
FIME
51
Internet
iroot
nBB
( ( ) )
G
( ( ) )
nBB
El gateway retransmite la petición de búsqueda al nBB
N
Si un nodo busca a alguien fuera de su grupo el mensaje lo manda directo al gateway
Si el nBB no tiene el
nodo especificado
manda un broadcast
para que lo busquen
los demas nBB
( ( ) )
G
( ( ) )
N
Si el nBB tiene el nodo
buscado entonces
regresa un paquete de
ack
Internet
iroot
nBB
( ( ) )( ( ) )
G
( ( ) )( ( ) )( ( ) )
nBB
El gateway retransmite la petición de búsqueda al nBB
N
Si un nodo busca a alguien fuera de su grupo el mensaje lo manda directo al gateway
Si el nBB no tiene el
nodo especificado
manda un broadcast
para que lo busquen
los demas nBB
( ( ) )( ( ) )
G
( ( ) )( ( ) )( ( ) )
N
Si el nBB tiene el nodo
buscado entonces
regresa un paquete de
ack
Figura 32 Explicación de la petición de un servicio o comunicación
Cuando una hoja o un gate solicita una ruta, lo hacen directamente al nodo
de dorsal este, si lo tiene, le envía un paquete al nodo que solicito la ruta para
avisarle que lo encontró. Si los nodos que se buscan están en diferentes nBB la
búsqueda se realiza solo a nivel de dorsal ya que cada nBB tiene conciencia de
quienes dependen de el. El proceso es simple y se muestra en la figura 32, solo
se manda un paquete “broadcast” al dorsal, ya que se tienen todas las rutas no
será necesario el reenvío de la petición y solo el nBB que encuentre al nodo
buscado responde a quien busca con un mensaje “unicast”.
Universidad de Colima Pruebas Y Resultados
FIME
52
3.5 Conclusiones
La propuesta que se muestra ofrece mas capacidades al usuario final de
las que otros protocolos, en situaciones de emergencia brindan, ya que asegura la
utilización uniforme de la red, esto es esencial ya que si se crean zonas de
sombra este grupo de nodos y, por ende sus usuarios, quedara incomunicado y
expuesto al peligro propio de la situación, lo que muestra la importancia de las
métricas que se eligieron para regir al protocolo.
Universidad de Colima Pruebas Y Resultados
FIME
53
4 Pruebas
Una vez terminada la etapa de diseño e implementación se pasó a la etapa
de pruebas, estas debían mostrar que el protocolo tiene un mínimo efecto en dos
parámetros importantes que se deseaban medir: por un lado el retraso punto a
punto (end to end delay) que muestra significativamente la calidad del enlace y
por otro lado se debería medir también la capacidad del canal (throughput).
Para el retardo punto a punto las pruebas consistieron en dos fases de dos
pruebas cada una para 1, 2 y 3 saltos,para la primera fase se configuraron las
rutas manualmente y cada prueba consistía en hacer 100 pings, hacia un nodo a
1 2 o 3 saltos, primero con un tamaño de paquete de 84 bytes y la segunda
también de 100 paquetes ICMP pero con una carga de 1000 bytes.
Posteriormente, en la segunda fase, se repetían las pruebas pero ahora el
protocolo es quien establecía las rutas y permanecía funcionando hasta el final de
la prueba. La separación de las maquinas fue de 25 metros entre 1 y 2, 50 metros
entre 2 y 3, y 25 metros entre 3 y 4 entre cada salto en la vía publica y sin línea de
vista a excepción de las ultimas dos maquinas en el caso de las pruebas a 3
saltos, la figura 33 muestra la configuración de las pruebas,
( ( ) )( ( ) )( ( ) )
( ( ) )( ( ) )( ( ) )
( ( ) )( ( ) )( ( ) )
( ( ) )( ( ) )( ( ) )
25 m
50 m
25 m
Figura 33 que muestra como se ubicaron los equipos para la realización de las pruebas.
Para el caso de la capacidad del canal se transmitió vía sftp un archivo de
3489 kbytes, se registraron los tiempos en que se envió esto se realizo para uno,
Universidad de Colima Pruebas Y Resultados
FIME
54
dos y tres saltos con el protocolo funcionando y con las rutas configuradas
manualmente.
Los equipos utilizados fueron 4 computadoras portátiles con las siguientes
características:
HP pavilion zt3377LA 512 en ram proceador Intel centrino 1.5GHz , 60 Gb
en HDD y tarjeta inalámbrica de 11mbps con Kubuntu instalado.
Gateway con 2Gb de ram 160 HDD y procesador Intel centrino core duo y
tarjeta inalámbrica de 54 mbps
HP nc6000 con 1Gb de ram proceador Intel centrino y 60Gb de HDD con
Ubuntu y tarjeta inalámbrica de 54mbps.
HP pavilion dv1125LA con 60Gb de disco duro 512 en ram y procesador
Intel centrino y tarjeta inalámbrica de 54 mbps.
Los resultados de todas las pruebas se muestran a continuación:
Universidad de Colima Pruebas Y Resultados
FIME
55
4.1 Resultados
4.1.1 Un salto sin Pandora
La primera prueba a un salto con un ICMP de 84 bytes y las rutas
configuradas manualmente resulto en un retraso promedio punto a punto de
1.158ms con un máximo de 4.5225ms y un mínimo de .8425ms sin perdida de
paquetes.
Para un paquete ICMP de 1028 bytes los resultados se dieron así: el
máximo retraso fue de 3.2695 el mínimo de 1.7425 y un promedio de 1.9485
todos los resultados expresados en milisegundos, esta prueba no tuvo perdida de
paquetes.
En el caso del sftp el resultado fue un promedio de 436.125kbps
4.1.2 Un salto con Pandora
Cuando el protocolo estaba funcionando los resultados obtenidos fueron
los siguientes:
Para los pings con una carga de 84 bytes el retraso punto a punto mínimo
fue de 0.856ms el máximo de 5.5265ms y el promedio de 1.196ms sin perdida de
paquetes.
Para los ICMP de 1028 bytes el mayor tiempo de retraso se registro en
3.0125 ms, el tiempo promedio fue de 1.898ms finalmente el menor tiempo fue de
1.753ms.
Para el caso de la capacidad de canal se transmitió también un paquete de
3489 Kb y el resultado fue de 387.666 Kbps
Universidad de Colima Pruebas Y Resultados
FIME
56
4.1.3 Dos saltos sin Pandora
Las pruebas a dos saltos sin Pandora funcionado con paquetes de 84 bytes
arrojaron un retraso máximo de 5.9825ms mínimo de 1.7215ms y un promedio de
2.0245ms, con 1% de perdida de paquetes.
Para una carga de 1028 bytes el menor tiempo fue 3.5415ms el máximo de
52.8926ms promediando 6.6595ms con un 2% de perdida en los paquetes.
El sftp realizado con 3489 kb promedio una velocidad de 56.2741 Kbps.
4.1.4 Dos saltos con Pandora
Para ICMP de 84 bytes el mayor fue de 19.496 ms el menor de 1.7435 ms
y el promedio de 2.544 ms sin perdida de paquetes.
Con los pings de 1028 bytes se obtuvieron los resultados de: máximo
49.767ms 6.571ms promedio y un mínimo de 3.537 ms en todos los casos y una
perdida de paquetes del 1%.
Para el sftp de 3489 Kbytes el resultado fue de 49.1408 Kbps.
4.1.5 Tres saltos sin Pandora
Esta prueba arrojo los resultados que a continuación se escriben, el
máximo retraso fue de 57.332 ms, el mínimo de 3.2395ms, con un promedio de
6.6045 ms, estas anotaciones son para el ping de 84 bytes, la perdida de
paquetes fue la mayor registrada de todas las pruebas con 24%.
Universidad de Colima Pruebas Y Resultados
FIME
57
Para cuando se enviaron paquetes de 1028 bytes los resultados que se
observaron fueron así: máximo 137.3165, mínimo de 12.717 y un promedio de
26.0425 con un 4% de perdidas.
En cuanto al sftp el resultado fue de 64.611.
4.1.6 Tres saltos con Pandora
Para tres saltos con el protocolo y un paquete de 84 bytes las pruebas
ofrecieron los siguientes resultados: máximo de 59.423ms mínimo de 3.32ms y un
promedio de 6.945 ms.
Cuando el paquete fue de 1028 bytes el retraso máximo fue de 125.653ms,
el mínimo de 12.823ms y un promedio de 26.642 ms en todos los casos.
Para el sftp el resultado medido fue de 60.456 kbps.
Universidad de Colima Pruebas Y Resultados
FIME
58
4.2 Análisis de Resultados
Una vez obtenidos los resultados se graficaron para compararlos las
imágenes resultantes se muestra a continuación:
La grafica de la figura 34 es referente a la comparación del retardo punto a
punto (EED) para un paquete de 84 bytes con Pandora funcionando (línea) y sin
el (barra), para uno dos y tres saltos, esta nos muestra que el protocolo tiene un
mínimo efecto en este parámetro.
EED Promedio (84 bytes)
0
2
4
6
8
1 salto 2 saltos 3 saltos
Numero de saltos
Tie
mp
o (
ms)
Manual
Pandora
Figura 34 comparativa, con y sin protocolo corriendo, de EED en paquetes de 84bytes.
Para el caso de paquetes de 1028 bytes la situación fue muy similar como
se muestra en la figura 35 que muestra las diferencias en el EED tanto con el
protocolo como sin él, para uno dos y tres saltos.
EED Promedio (1028 bytes)
0
5
10
15
20
25
30
1 salto 2 saltos 3 saltos
Número de Saltos
Tie
mp
o (
ms)
Manual
Pandora
Figura 35 EED Promedio para paqutes de 1028 bytes a uno dos y tres saltos
Universidad de Colima Pruebas Y Resultados
FIME
59
Otro resultado importante es EED máximo para paquetes tanto de 84 como
de 1028 bytes, esto para conocer la probabilidad de perdidas en aplicaciones
especificas.
En particular para paquetes de 84 bytes los resultados muestran que tanto
con el protocolo como sin el la diferencia no es representativa como lo podemos
observar en la figura 36.
EED Máximo (84 bytes)
0
10
20
30
40
50
60
70
1 salto 2 saltos 3 saltos
Número de Saltos
Tie
mp
o (
ms)
Manal
Pandora
Figura 36 comparación de EED máximo para uno dos y tres saltos sin Pandora
La misma situación se presento en los paquetes con una carga de 1028
que se notan la figura 37.
EED Máximo (1028 bytes)
0
50
100
150
1 salto 2 saltos 3 saltos
Saltos
Tie
mp
o (
ms)
Manual
Pandora
Figura 37 diferencias para EED en paquetes de 1028 bytes a uno dos y tres saltos
Universidad de Colima Pruebas Y Resultados
FIME
60
Finalmente para el caso de la capacidad del canal una vez mas la grafica
enseña que el protocolo tiene un efecto mínimo en la capacidad, en la figura 38 se
puede observar esto.
Capacidad del Canal
0
100
200
300
400
500
1 salto 2 saltos 3 saltos
Saltos
Th
rou
gh
pu
t (K
bp
s)
Manual
Pandora
Figura 38 Comparativa de Throughput para uno dos y tres saltos con el protocolo corriendo y con las
rutas configuradas manualmente.
4.3 Conclusión de Resultados
Las gráficas nos muestran que el protocolo no tiene un impacto significativo
ni en la capacidad del canal ni en el retardo de los paquetes, en los casos mas
extremos las diferencias son debidas al ambiente donde se desarrollaron las
pruebas y aún en estos casos los contrastes son realmente muy parejos, por lo
que se puede concluir que el protocolo Pandora no tiene una influencia negativa
en los parámetros fundamentales de la red.
Universidad de Colima Pruebas Y Resultados
FIME
61
5 Conclusiones
Después de haber implementado la proupuesta y de aplicarle las pruebas
correspondientes observar que según los datos registrados en las pruebas el
protocolo se comporta adecuadamente y no introduce una carga significativa en la
red, esto es debido a que los paquetes “hello” son enviados en intervalos que
permiten tanto la comunicación eficaz entre las maquinas tanto de controlo como
de transporte de datos, además también contribuye a su buen desempeño el
eficiente manejo e intercambio de las tablas de enrutamiento.
Aunque sin duda el protocolo se puede mejorar en trabajos futuros como el
montar el protocolo sobre plataformas embebidas, mejorar las rutinas de
comunicación con el sistema e implementar colas de servicio, la presente
implementación sienta las bases funcionales para un proyecto que mas que
aislarse en las vertientes operativas puras, trata de aportar en el aspecto mas
significativo para el cual la tecnología fue creada, el de servir y facilitar las
actividades relevantes del ser humano como son el de coordinarse en situaciones
de emergencia.
Universidad de Colima Pruebas Y Resultados
FIME
62
ANEXO I Código
El código que se muestra continuación es el que corresponde a la
implementación, se presenta con la finalidad de dimensionar el alcance del
proyecto además también esperando que sea de utilidad para quien desee
contribuir al proyecto.
libpandora
#include <stdio.h>
#include "libpandora.h"
#define INFINITY (2147 - 1)
#pragma pack(push, 1)
typedef struct {
u_int8_t mPacketType;
u_int8_t mReserved1;
u_int16_t mReserved2;
u_int16_t mPacketId;
u_int16_t mReserved3;
u_int32_t mDataSize;
u_int8_t mData[1];
} Packet_t;
#pragma pack(pop)
void getTiempo()
{
int cDbw,cDbwA=0;
time_t tiempoDbw;
struct tm *tiempoDbw2;
char ttDbw[27],tt1Dbw[7];
tiempoDbw=time(NULL);
tiempoDbw2=gmtime(&tiempoDbw);
sprintf(ttDbw,"%s", asctime(tiempoDbw2));
for (cDbw=11;cDbw<=18;cDbw++)
{
if(ttDbw[cDbw]!=':')
{
tt1Dbw[cDbwA]=ttDbw[cDbw];
cDbwA++;
}
}
tt1Dbw[cDbwA]='\0';
printf("HOLA IMRPIMO ttidbW %s\n",tt1Dbw);
strcpy(Cltime,tt1Dbw);
/*Cltime[6]='\0';*/
}
int busca_ruta(unsigned long int IP_b)
{
char r_cmp[50]="";
FILE *lruta;
int ir=0,jr=0,cmp=1,ir_cmp;
char getruta[30]="ip route get ";
struct sockaddr_in ipS;
ipS.sin_addr.s_addr=IP_b;
strcat (getruta,inet_ntoa(ipS.sin_addr));
strcat (getruta," > /etc/gps/ruta");
system(getruta);
r_dstB[0]='\0';
r_gwB[0]='\0';
intentoR:
lruta = fopen("/etc/gps/ruta","r");
if( lruta )
printf( "existe lruta (ABIERTO)\n" );
else
{
printf( "Error (NO ABIERTO)\n" );
sleep(1);
goto intentoR;
}
r_cmp[0]='\0';
fgets(r_cmp,50, lruta);
ir=fclose(lruta);
if(ir==0)
printf( "Fichero lruta cerrado\n" );
else
printf( "Error: fichero NO CERRADO\n" );
Universidad de Colima Pruebas Y Resultados
FIME
63
//addr_aton(ip_dest, &entry.route_dst);
kpso=route_get(r, &entry);
if ( kpso< 0)
kpso=-100;
} else if (strcmp(cmd, "add") == 0) {
if (addr_aton(ip_dest, &entry.route_dst) < 0
|| addr_aton(ip_gw, &entry.route_gw) < 0)
printf("addr_aton");
if (route_add(r, &entry) < 0)
printf("route_add\n");
printf("add %s %s: gateway %s\n",
(entry.route_dst.addr_bits <
IP_ADDR_BITS) ?
"net" : "host",
addr_ntoa(&entry.route_dst),
addr_ntoa(&entry.route_gw));
} else if (strcmp(cmd, "delete") == 0) {
if (addr_aton(ip_dest, &entry.route_dst) < 0)
printf("addr_aton");
if (route_delete(r, &entry) < 0)
printf( "route_delete");
printf("delete %s %s\n",
(entry.route_dst.addr_bits <
IP_ADDR_BITS) ?
"net" : "host",
addr_ntoa(&entry.route_dst));
}
route_close(r);
//exit(0);
if (kpso==0)
kpso=1;
else
kpso=0;
return kpso;
}
void waitrand()
{ int i;
time_t t1;
(void) time(&t1);
srand48((long) t1); /* use time in seconds to set seed */
/*printf("5 random numbers (Seed = %d):\n",(int) t1);*/
wfns=lrand48()/10000;
printf("esperare por %d ",wfns);
printf("\n\n"); /* flush print buffer */
/* lrand48() returns non-negative long integers
uniformly distributed over the interval (0, ~2**31)
*/
}
//void Dijkstra(Vertex* graph, int nodecount, int source);
void Dijkstra(int nodecount, int source)
{
int i,j,h,v;
int next;
int min = INFINITY+1,ind,vecino;
int camino[10][10];
int auxcam[10]={0,0,0,0,0,0,0,0,0,0};
ULI *ipl;
short int idx;
gateway=0;
for(i = 0; i < nodecount; i++)
{
if(i == source)
{
graph[i].distance = 0;
graph[i].isDead = 0;
}
else
{
graph[i].distance=INFINITY;
graph[i].isDead = 0;
}
}
int min = INFINITY+1;
ind=0;
for(j = 0; j < nodecount; j++)
{
if((!graph[j].isDead) && (graph[j].distance <
min))
{
next = j;
min = graph[j].distance;
}
}
for(j = 0; j < graph[next].numconnect; j++)
{
if(graph[graph[next].connections[j].dest].distance
> graph[next].distance +
graph[next].connections[j].weight)
Universidad de Colima Pruebas Y Resultados
FIME
64
{
//printf ("HI HI from road i=%d next=%d dest=%d
wei=%d\n",i,next,graph[next].connections[j].dest,graph[next].conn
ections[j].weight);
graph[graph[next].connections[j].dest].distance =
graph[next].distance + graph[next].connections[j].weight;
//determino camino
for (h=0;h<graph[source].numconnect;h++)
{
if
(((graph[source].connections[h].dest==next)||(source==next))&&(a
uxcam[next]<2))
{
vecino=1;
break;
}
else
{
vecino=0;auxcam[graph[next].connections[j].dest]=0;
}
}
if (vecino==1)
{
camino[graph[next].connections[j].dest][auxcam[graph[
next].connections[j].dest]]=next;
// printf ("HI HI from VECINOS %d
aux=%d\n",graph[next].connections[j].dest,auxcam[graph[next].co
nnections[j].dest]);
auxcam[graph[next].connections[j].dest]++;
camino[graph[next].connections[j].dest][auxcam[graph[
next].connections[j].dest]]=graph[next].connections[j].dest;
}
else
{
for
}
camino[graph[next].connections[j].dest][auxcam[graph[
next].connections[j].dest]]=graph[next].connections[j].dest;
}
}
graph[next].isDead = 1;
}
ActtmainRutas()
{
ULI ipl;
short int idx,nodec;
nodec=guardaVecinos();
// busca en la tabla de nodo a uno solicitado y envia IP y
el indice del nodo en la tabla
BuscatRuteo(&ipl,&idx,misdatos.id,'4');
printf("\n
##############################################
##### DIJKSTRA desde ACT
%d############################################
##\n",idx);
Dijkstra(nodec,idx);
}
//regresa la direccion de la interfaz
unsigned long int interfaces(void)
{
short int i;
//direccion ip y mac de la interface de intf_entry
struct intf_entry *entryi;
char buf[1024];
//handle de la estructura tipo intf_entry
static intf_t *intf;
entryi = (struct intf_entry *)buf;
memset(entryi, 0, sizeof(*entryi));
entryi->intf_len = sizeof(buf);
char dirip[18];
unsigned long int dirunsi;
if ((intf = intf_open()) == NULL)
err(1, "intf_open");
strlcpy(entryi->intf_name, "eth1",
sizeof(entryi->intf_name));
//funcion que envia la estructura completa para rellenar
dikjstra solo si el no ha hecho esta actualizacion
int envioTG()
{
int sockt,o,addr_len,ie;
struct sockaddr_in addrE,my_addrE;
Universidad de Colima Pruebas Y Resultados
FIME
65
// Abrimos un Socket Para envio
if ((sockt =
socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP)) == -1) {
perror("socket()");
exit(EXIT_FAILURE);
}
// Habilita el Broadcast para el socket de envio
o=1;
if(
setsockopt(sockt,SOL_SOCKET,SO_BROADCAST,&o,sizeof(o))
== -1 ) {
perror("setsockopt()");
exit(EXIT_FAILURE);
}
// Asigna el socket a la interfaz Inalambrica
if ((setsockopt(sockt,SOL_SOCKET,
SO_BINDTODEVICE,"eth1",sizeof("eth1"))<0))
{
perror ("setsockopt()");
exit(EXIT_FAILURE);
};
/* Rellena la estructura sockaddr_in */
memset(&addrE,0,sizeof(struct sockaddr_in));
addrE.sin_family = AF_INET;
addrE.sin_addr.s_addr=inet_addr("255.255.255.255");
addrE.sin_port=htons(4958);
// Enviamos el paquete
addr_len=sizeof(addrE);
printf("ESTOY MANDANDO
DESDE REENVIO TG ESTO EN version
%d\n",mainTable.version);
if
((sendto(sockt,&mainTable,sizeof(mainTable),0,(struct
sockaddr*)&addrE,addr_len)) ==-1)
{
perror("sendto");
exit(EXIT_FAILURE);
}
close(sockt);
}
envioTG();
//funcion que inicializa la recepcion de paquetes de ruteo
void *paylRuteo(void *filtrox)
{
struct pktIR payloadR;
struct sockaddr_in my_addr, their_addr;
//char *filtro;
int sock,i;
unsigned long int alex,addr_len;
/* Socket de captura de todos los paquetes. (modo
promiscuo) */
if((sock = socket(AF_INET, SOCK_DGRAM,
IPPROTO_UDP )) == -1) {
perror("socket()");
exit(EXIT_FAILURE);
}
memset(&my_addr,0,sizeof (my_addr));
my_addr.sin_family=AF_INET;
my_addr.sin_port=htons(4958);
//my_addr.sin_port=inet_addr("172.168.1.65");
if (bind(sock,(struct sockaddr *)&my_addr,sizeof(struct
sockaddr))==-1)
{
perror("bind()");
exit(1);
}
for(;;)
{
addr_len=sizeof(their_addr);
recvfrom(sock,(struct pktIR
*)&payloadR,sizeof(payloadR), 0, (struct sockaddr
*)&their_addr,(socklen_t *)&addr_len);
if((misdatos.nip!=their_addr.sin_addr.s_addr)&&(misdato
s.ntipo=='B')&&(HabilitaRuteo==1))
{RcbTG=1;
Ruteocallback(&payloadR);}
}
}
// funcion que nos permite generar el ID unico del nodo
Universidad de Colima Pruebas Y Resultados
FIME
66
int hash(char mac[18], char time[12])
{
char macTime[32];
int ih,nHash=0,LmT;
macTime[0]='\0';
emset(&addrE,0,sizeof(struct sockaddr_in));
addrE.sin_family = AF_INET;
addrE.sin_addr.s_addr=misdatos.ip1id;
addrE.sin_port=htons(4955);
printf("AKI MANDO EL PPP a la
DIRECCION %ld \n",addrE.sin_addr.s_addr);
// Enviamos el paquete
addr_len=sizeof(addrE);
// printf("ESTOY MANDANDO DESDE ENVIOTRUTA ESTO
EN id1s %d \n",nodoIROOT._vecinod[0].id1s);
// printf("ESTOY MANDANDO DESDE ENVIOTRUTA ESTO
EN IP %ld \n",nodoIROOT._ip);
printf("ESTOY MANDANDO DESDE ENVIOTRUTA ESTO EN
peso %d \n",nodoIROOT._vecinod[0].peso);
if(HabilitaRuteo==1)
usleep(wfns);
/*while(RcbTG==0)
{ */ /* envieIR=0;*/
if
((sendto(sockt,&nodoIROOT,sizeof(nodoIROOT),0,(struct
sockaddr*)&addrE,addr_len)) ==-1)
{
perror("sendto");
exit(EXIT_FAILURE);
}
// sleep(2);
// }
close(sockt);
}
//lanza la funcion lpcap para capturar paquetes de ruteo
void envPLR(char filtro1[80])
{
int error_envio;
pthread_t HenvioR;
error_envio=pthread_create(&HenvioR, NULL, paylRuteo,
NULL);
if (error_envio!=0)
printf("El hilo paylRuteo no se pudo abrir \n");
else
printf("El hilo paylRuteo se abrio \n");
}
int guardaVecinos()
{
ULI ipl;
short int idx;
VLista=rRuteo;
int ig=0;
int ig1;
// }
// int buscaVecino(int Bid)
// {
// VLista=rVecino;
// pVecino=NULL;
// while (VLista!=NULL)
// {
// if (VLista->id==Bid)
// return 1;
// else
// {
// pVecino=VLista;
// VLista=VLista->siguiente;
// }
// }
// return 0;
// }
/*int iniciaVecino()
{
rVecino = (struct _nodo*)malloc(sizeof(struct _nodo));
VLista=rVecino;
return 1;
}
*/
//abre el archivo donde se guardan las coordenadas y
tiempo local
// en esta funcion falta la integracion de lo del GPS ver las
coordenadas que toma del archivo de datos locales
void open_lcordgeo()
{
FILE *lcoord;
char tcoordg[44];
long int mtime; /* Guarda Teimpo*/
time_t tiempo;
struct tm *tiempo2;
char tt[27],tt1[7];
Universidad de Colima Pruebas Y Resultados
FIME
67
int si,isi=0;
int i=0,j=0;
intento:
lcoord = fopen("/etc/gps/lgps","r");
if( lcoord )
printf( "existe (ABIERTO)\n" );
else
{
printf( "Error (NO ABIERTO)\n" );
sleep(1);
goto intento;
}
fgets(tcoordg, 44, lcoord);
//printf(" ESTO TIENE LGPS2 %s\n",tcoordg);
i=fclose(lcoord);
if(i==0)
printf( "Fichero cerrado\n" );
else
printf( "Error: fichero NO CERRADO\n" );
i=0;
while(tcoordg[i]!=',')
{ llongitud[i]=tcoordg[i]; i++;}
llongitud[i]='\0';
//strcpy(llatitud,"10343.9728W");
printf(" longitud %s \n",llongitud);
i++;
while(tcoordg[i]!=',')
{ llatitud[j]=tcoordg[i]; i++; j++;}
//printf(" mi tiempo %s \n",ltime);
}
// funcion para convertir de coordenadas geograficas a distancia
//int concgd(void)
void concgd(char latc[16], char lonc[16])
{
//primeros 3 grados, el resto son minutos
char
lagrados[3]="",laminutos[13]="",logrados[3]="",lominutos[13]="";
char las[2],los[2];
int entero,j,i,k;
i=0;
while (latc[i]!='.') i++;
// printf("donde esta el punto %d \n",i);
// printf("la longitud de latitud es %d \n",(strlen(latc)));
las[0]=latc[(strlen(latc))-1];
latc[(strlen(latc))-1]='\0';
/* printf("el signo es %c \n",las[0]);*/
las[1]='\0';
if(i<5) {
j=0;
for (k=(i-2);k<=(strlen(latc));k++)
{
laminutos[j]=latc[k];
j++;
}
laminutos[j]=='\0';
for (j=0;j<=(i-3);j++)
lagrados[j]=latc[j];
lagrados[j]=='\0';
}
else
{
for (i=0;i<=2;i++)
lagrados[i]=latc[i];
lagrados[i]='\0';
j=0;
for (i=3;i<=(strlen(latc));i++)
{
laminutos[j]=latc[i];
j++;
}
laminutos[j]='\0';
}
ll.gradosla=atof(lagrados)+(atof(laminutos)/60);
strcpy(ll.cla,las);
las[1]='\0';
// printf("latitud %s \n",latc);
// printf(" grados %s \n",lagrados);
// printf(" minutos %s \n", laminutos);
// printf(" signo %c \n", las[0]);
// printf(" signo %s \n", ll.cla);
// printf(" asi kdo llla %f \n",ll.gradosla);
//
// printf(" ========================= \n");
ia;
strcpy(ll1.cla,ll.cla);
// printf(" desde RESTA %f
%f\n",ll1.gradosla,ll1.gradoslo);
/* open_lcordgeo();*/
concgd(llatitud,llongitud);
Universidad de Colima Pruebas Y Resultados
FIME
68
if (ll1.clo[0]=='W')
ll1.gradoslo=ll1.gradoslo*(-1);
if (ll1.cla[0]=='S')
ll1.gradosla=ll1.gradosla*(-1);
if (ll.clo[0]=='W')
ll.gradoslo=ll.gradoslo*(-1);
if (ll.cla[0]=='S')
ll.gradosla=ll.gradosla*(-1);
*a=90-ll1.gradosla;
*b=90-ll.gradosla;
*p=ll1.gradoslo-ll.gradoslo;
/* printf("numeros reales a ,b ,p %f,%f,%f \n",*a,*b,*p);*/
}
double dstxy (char latd[16], char lond[16])
{
double lc,aa,ab,ac;
/*printf(" latitud y longitud en dstxy %s %s \n",latd,lond);*/
resta(&aa,&ab,&ac,latd,lond);
/*printf("numeros reales en la funcion distancia a ,b ,p %f,%f,%f
\n",aa,ab,ac);*/
aa=aa*M_PI/180;
ab=ab*M_PI/180;
ac=ac*M_PI/180;
lc=acos((cos(aa)*cos(ab))+(sin(aa)*sin(ab)*cos(ac)));
lc=(lc*(40000/(2*M_PI)));
/*printf(" Esta es la distancia %f \n",lc);*/
return lc;
}
// esta funcion genera el peso es optimo cuando es igual con 0 y
pesimo cuando es igual con 100
int pesoNodo(short int energy,short int usr,short int bw,char
latp[16],char lonp[16])
{
int mx,my;
double x;
double mc;
int ret;
float bwA;
struct pesos {
float a,p,e,u,ps,pt;
}tpesos;
//para obtener la distancia entre los dos puntos
/* printf(" en la funcion peso %s %s\n",latp,lonp);*/
mc=dstxy(latp,lonp);
mc=mc*1000;
//se ve el peso para tomar desiciones
bwA=(bw*.555555555);
tpesos.e=energy*0.20;
tpesos.u=15-(usr*2.5);
tpesos.a=(bw*.555555);
tpesos.ps=35-(mc*0.7);
if (mc>50)
tpesos.ps=0;
tpesos.pt=tpesos.e+tpesos.u+tpesos.a+tpesos.ps;
ret=100-tpesos.pt;
printf("IMPRIMO TPESOS tpesos.e=%f tpesos.u=%f
tpesos.a=%f tpesos.ps=%f ret
%d\n",tpesos.e,tpesos.u,tpesos.a,tpesos.ps,ret);
return ret;
}
int pktbuf_size() {
return (PKTBUF_SIZE - pktbuf_head +
pktbuf_tail) % PKTBUF_SIZE;
}
int pktbuf_peek(char *buf, int n) {
int i;
int mypktbuf_head = pktbuf_head;
for (i = 0; (i < n) && (mypktbuf_head !=
pktbuf_tail); i++) {
buf[i] = pktbuf[mypktbuf_head];
mypktbuf_head++;
if (mypktbuf_head ==
PKTBUF_SIZE)
mypktbuf_head = 0;
}
return i;
}
int pktbuf_deq(char *buf, int n) {
int i;
for (i = 0; (i < n) && (pktbuf_head !=
pktbuf_tail); i++) {
buf[i] = pktbuf[pktbuf_head];
pktbuf_head++;
if (pktbuf_head == PKTBUF_SIZE)
pktbuf_head = 0;
}
return i;
}
Universidad de Colima Pruebas Y Resultados
FIME
69
int pktbuf_enq(char *buf, int n) {
int i;
if (pktbuf_size() + n >= PKTBUF_SIZE)
return 0;
for (i = 0; i < n; i++) {
pktbuf[pktbuf_tail] = buf[i];
pktbuf_tail++;
if (pktbuf_tail == PKTBUF_SIZE)
pktbuf_tail = 0;
}
return i;
}
int sendpacket(Packet_t *pack) {
t);
return NULL;
}
if (pktbuf_enq(tmp, nr) == 0)
fprintf(stderr, "Input buffer full!");
goto chkbuf;
}
/*
garmin_pvton()
turn on position records
receiver measurement records could also be enabled
with
command 110 (instead of 49), but we don't need them at
present
*/
void gpsF(char *latgp, char *longp, char *tiempo) {
char buff_gps[80];
char nmeabuf[256];
u_int32_t privcmd[4];
FILE *nmeaout;
struct termios termio;
/*if (argc < 2) {
printf("Usage: %s gpsdev [nmeaoutdev]\n",
argv[0]);
return 1;
}*/
gps_fd = open("/dev/ttyUSB0", O_RDWR);
if (gps_fd == -1) {
perror("Cannot open GPS device");
}
tcgetattr(gps_fd, &termio);
cfmakeraw(&termio);
tcsetattr(gps_fd, TCIOFLUSH, &termio);
privcmd[0] = 0x01106E4B;
privcmd[1] = 2;
privcmd[2] &(wrq.u.bitrate), sizeof(iwparam));
}
CloseSocket();
/* Display the currently used/set bit-rate */
sprintf(bit,"%g", (Info.bitrate.value / MEGA));
return (atoi(bit));
}
Recibe_b
#include "libpandora.h"
/* variables globales */
// definicion de funciones
float dif_time(char *tiempo1,char *tiempo2); rec[0];
hrs[1]=tiempo_rec[1];
hrs[2]='\0';
mins[0]=tiempo_rec[2];
mins[1]=tiempo_rec[3];
mins[2]='\0'; seg[0]=tiempo_rec[4];
seg[1]=tiempo_rec[5];
seg[2]='\0';
time_stru.tm_hour=atoi(hrs);
time_stru.tm_min=atoi(mins); time_stru.tm_sec=atoi(seg);
}
//*********************************************
***********************************//
//Funcion callback, sera invocada cada vez que se
reciba un paquete
void my_callback(u_char *useless,const struct pcap_pkthdr *pkthdr,const u_char *packet)
{
Universidad de Colima Pruebas Y Resultados
FIME
70
static int count=0; //inicializamos el contador count ++;printf
("\n"); int error=0,i;
char latS[16],lonS[16];
//struct ether_header *eptr;
/* Apuntamos el puntero a la cabecera Ethernet al
comienzo del paquete */ struct ether_header *eptr = (struct ether_header *)packet;
struct ip *ipc;
int size_tcp=sizeof(struct tcphdr); int size_udp=sizeof(struct udphdr);
ipc=(struct ip *)(packet+sizeof(struct ether_header)); //strcpy(mip,inet_ntoa(auxip));
unsigned long int iporigen;
iporigen=ipc->ip_src.s_addr;
struct _hellobb *payload2;
payload2=(struct _hellobb *)(sizeof(struct
ether_header)+ packet+sizeof(struct ip)+size_udp); /* printf(" direccion del payload \n %d \n",(int
*)payload2);*/
if (ipc->ip_p==17) {
printf ("Paquete UDP\n");
printf("\n IMPRIMO DESDE
MY_CALLBACK(HELLOS) \n");
printf(" ========================================\n");
printf(" payload->id %d \n",payload2->id);
printf(" payload->nip %ld \n",payload2->nip); printf(" payload->ip1id %ld \n",payload2->ip1id);
printf(" payload->nivelE %d \n",payload2->nivelE);
printf(" payload->Usuarios %d \n",payload2->Usuarios); printf(" payload->lat %s \n",payload2->lat);
printf(" payload->lon %s \n",payload2->lon); printf(" payload->lon %s \n",payload2->tiempo);
printf(" payload->bw %d \n",payload2->bw);
printf(" payload->ntipo %c \n",payload2->ntipo); printf("
========================================\n\n\n");
if ((payload2->ntipo=='B')&&(permisoHB==1)) //AKI
KAMBIAMOS SOLO PARA PRUEBAS a U, B es lo correcto {
// if (envieIR>6)
// misdatos.ntipo='B'; rcbHB=1;
/*****************************************************
*****/ if (misdatos.ntipo=='U')
{
printf("\n E \n",misdatos.Usuarios);
misdatos.ip1id=payload2->ip1id;
if (payload2->id==1) rutaSys(1,misdatos.ip1id);
else
route("add",misdatos.ip1id,payload2->nip); // printf("\n CAMBIE A B \n",misdatos.Usuarios);
}
/**********************************************************/
tmp.id=payload2->id; tmp.nip=payload2->nip;
tmp.ip1id=payload2->ip1id;
tmp.nivelE=payload2->nivelE; tmp.Usuarios=payload2->Usuarios;
strcpy(tmp.lat,payload2->lat);
strcpy(tmp.lon,payload2->lon); tmp.bw=payload2->bw;
tmp.ntipo=payload2->ntipo;
//tmp.npeso=payload2->npeso;
strcpy(tmp.tiempo,payload2->tiempo); tmp.npeso=pesoNodo(tmp.nivelE, tmp.Usuarios,
tmp.bw, tmp.lat,tmp.lon);
if (tmp.id==1)
misdatos.npeso=pesoNodo(misdatos.nivelE,
misdatos.Usuarios, misdatos.bw, tmp.lat,tmp.lon); analiza();
}
}
}
void analiza()
{
short int i=0,esta=0;
float dbw,dbw1;
nodoIROOT._ip=misdatos.nip; nodoIROOT._id=misdatos.id;
nodoIROOT.usuarios=misdatos.Usuarios;
nodoIROOT._peso=misdatos.npeso; while ((i<6)&&(esta==0))
{
if (tabla_host[i].id==tmp.id) {
printf("ya se encuentra el usuario solo actualiza
\n"); myGw=inet_addr(r_gwB);
if
((misdatos.Usuarios==0)||(myGw==tabla_host[i].nip)) {
misdatos.ntipo='U'; MIinicio();
permisoHB=0;
#include "libpandora.h"
void iniciaSOCK()
{
// Abrimos un Socket Para envio if ((socktEH =
socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP)) == -
1) {
perror("socket()");
exit(EXIT_FAILURE); }
// Habilita el Broadcast para el socket de envio oEH=1;
if(
setsockopt(socktEH,SOL_SOCKET,SO_BROADCAST,&oEH,sizeof(oEH)) == -1 ) {
perror("setsockopt()"); exit(EXIT_FAILURE);
}
// Asigna el socket a la interfaz Inalambrica
if ((setsockopt(socktEH,SOL_SOCKET,
SO_BINDTODEVICE,"eth1",sizeof("eth1"))<0)) {
perror ("setsockopt()");
exit(EXIT_FAILURE); };
/* Rellena la estructura sockaddr_in */
Universidad de Colima Pruebas Y Resultados
FIME
71
memset(&addrEH,0,sizeof(struct sockaddr_in));
addrEH.sin_family = AF_INET; addrEH.sin_addr.s_addr=inet_addr("255.255.255.255");
addrEH.sin_port=htons(4957);
addr_lenEH=sizeof(addrEH);
// while(1)
// sleep(5432); }
void envioHellos()
{
// printf("\n IMPRIMO DESDE envioHellos() \n");
printf(" ========================================\n");
printf(" misdatos.tiempo %s \n",misdatos.tiempo);
/*printf(" misdatos.ntipo %c \n",misdatos.ntipo);
printf(" misdatos.id %d\n",misdatos.id);
printf(" misdatos.vacio %d\n",misdatos.vacio);
printf(" ========================================\n\n\n");
*/ // Enviamos el paquete
if ((sendto(socktEH,&misdatos,sizeof(misdatos),0,(struct
sockaddr*)&addrEH,addr_lenEH)) ==-1)
{
perror("sendto");
exit(EXIT_FAILURE); }
} void *Tmisdatos(void *temp)
{
struct sockaddr_in MIip; char mipc[20]="";
char mac[18]; char Mtiempo[7];
int kpaz=0,Cruta=0;
float x25,x26; //obtengo la ip de mi maquina
iniciaSOCK();
while (1) {
//toma los datos del nodo cada 5B o 1U seg
if (envieIR>=6) {
getTiempo();
strcpy(misdatos.tiempo,Cltime); kpaz=kpaz+5;
if (HabilitaRuteo==0)
{
misdatos.ntipo='B';
/* nodoIROOT.tipo='B';*/
EnviotRuta(); printf("\n envieIR > 6\n");
}
envioHellos(misdatos);
HabilitaRuteo=1;
Cruta=Cruta+5; sleep(5);
}
else if (misdatos.ntipo=='U')
{
getTiempo();
strcpy(misdatos.tiempo,Cltime);
envioHellos(); sleep(1);
if (rcbHB==1)
envieIR++;
kpaz++; if (kpaz>=5)
permisoHB=1; }
if(kpaz>=120)
{
MIip.sin_addr.s_addr=interfaces();//OBTIENE
LA IP EN ENTERO LARGO
strcpy(mipc,inet_ntoa(MIip.sin_addr));//REGR
ESA LA IP strcpy(mac,dirmac);
//
gpsF(&Mlatitud,&Mlongitud,&Mtiempo);
open_lcordgeo();
/* strcpy(Mtiempo,ltime);*/
misdatos.nip=MIip.sin_addr.s_addr;
misdatos.nivelE=batery();
strcpy(misdatos.lat,llatitud);
strcpy(misdatos.lon,llongitud);
misdatos.bw=get_bit_rate();
//misdatos.npeso=pesoNodo(misdatos.nivelE,
misdatos.Usuarios,misdatos.bw,Mlatitud,Mlongitud); kpaz=0;
}
if (Cruta>=300) {
Cruta=0; nodoIROOT.movN='1';
EnviotRuta();
} }
}
void MIinicio()
{
struct sockaddr_in MIip; char mipc[20]="";
char mac[19];
char Mtiempo[7]; char Mlatitud[16],Mlongitud[16];
envieIR=0;
gateway=0; rcbHB=0;
HabilitaRuteo=0;
/**********************************************
************/
id1time[0]='0'; id1time[1]='\0';
/**********************************************************/
//obtengo la ip de mi maquina
MIip.sin_addr.s_addr=interfaces();//OBTIENE LA IP EN ENTERO LARGO
strcpy(mipc,inet_ntoa(MIip.sin_addr));//REGRESA
LA IP strcpy(mac,dirmac);
mainTable.version=1;
//gpsF(&Mlatitud,&Mlongitud,&Mtiempo); se utilizara openlcordenose ppor no tener suficientes GPSs
misdatos.nip=MIip.sin_addr.s_addr;
rutaSys(3,inet_addr("172.168.1.0")); open_lcordgeo();
strcpy(Mtiempo,ltime);
Universidad de Colima Pruebas Y Resultados
FIME
72
misdatos.ntipo='U';
misdatos.id=hash(mac, Mtiempo); misdatos.vacio=0;
misdatos.nivelE=batery();
strcpy(misdatos.lat,llatitud); strcpy(misdatos.lon,llongitud);
strcpy(misdatos.tiempo,Mtiempo);
misdatos.bw=get_bit_rate();
//misdatos.npeso=pesoNodo(misdatos.nivelE,misdatos.Usuarios,mi
sdatos.bw,Mlatitud,Mlongitud); strcpy(misdatos.tiempo,Mtiempo);
printf("\n IMPRIMO DESDE MIinicio() \n");
printf(" ========================================\n");
printf(" misdatos.nip %ld \n",misdatos.nip);
printf(" misdatos.ip1id %ld \n",misdatos.ip1id);
printf(" misdatos.ntipo %c \n",misdatos.ntipo);
printf(" misdatos.id %d\n",misdatos.id);
printf(" misdatos.vacio %d\n",misdatos.vacio); printf(" misdatos.nivelE %d\n",misdatos.nivelE);
printf(" misdatos.lat %s\n",misdatos.lat);
printf(" misdatos.lon %s\n",misdatos.lon); printf(" misdatos.tiempo %s\n",misdatos.tiempo);
printf(" misdatos.bw %d\n",misdatos.bw);
printf(" ========================================\n\n\n");
int ia=0;
for (ia=0;ia<6;ia++) {
tabla_host[ia].vacio=0;
tabla_host[ia].id=0; }
Iruta=iniciatRuteo();
}
main() {
SocketFileDescriptor =-1; pktbuf_head = 0;
pktbuf_tail = 0;
satdata_valid = 0; struct sockaddr_in aux;
char mipc[20]="";
int Emisdatos; pthread_t Hmisdatos;
MIinicio();
permisoHB=1; Emisdatos=pthread_create(&Hmisdatos,NULL,Tmisdat
os,NULL);
if (Emisdatos!=0) printf(" El hilo no se puedo abrir no se
iniciara PANDORA \n");
else {
// filtro de paquetes de hello
char filtro[80]="udp and port 4957 and not src host ";//not src host ";
// filtro de paquetes de ruteo
aux.sin_addr.s_addr=misdatos.nip; strcpy(mipc,inet_ntoa(aux.sin_addr));
strcat(filtro,mipc);
char filtro1[80]="udp and port 4955 and not src host ";//not src host ";
strcat(filtro1,mipc);
//solo el trafico udp de direcciones no mias envPLR(filtro1);//lanza la funcion lpcap para capturar
paquetes de ruteo
waitrand(); payload(filtro);//lanza la funcion lpcap para capturar
paquetes de Hellos
// while(1){ printf(" hola \n");sleep(1);} }
}
Universidad de Colima Pruebas Y Resultados
FIME
73
ANEXO II
iwconfig eth1 mode ad-hoc iwconfig eth1 essid PANDORA iwconfig eth1 enc 1234567891 ifconfig eth1 172.168.1.IP netmask 255.255.255.0 echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iwconfig eth1 ifconfig eth1
Universidad de Colima Bibliografía
FIME
74
Referencias
[1] David Tse, Pramod Viswanath, “Fundamentals of Wireless Communication”, 2005. [2] Brian P. Crow, Indra Widjaja, Jeong Geun Kim, Prescott T. Sakai. ” IEEE 802.11 Wireless Local Area Networks” IEEE Communications Magazine, Septiembre 1997. [3] Ian F. Akyildiz, Xudong Wang, Welin Wang, “Wireless mesh networks: a survey”, Computer Networks, Enero 2005. [4] Claude Chaudet, Dominique Dhoutaut, “Performance issues with IEEE 802.11 in ad hoc networking”, 2005. [5] Ashish Raniwala Tzi-cker Chiueh, “Architecture and Algorithms for an IEEE 802.11-Based Multi-Channel Wireless Mesh Network”, Computer Science Department, Stony Brook University, 2004 [6] LocustWorld, http://www.locustworld.com/ [7] Tropos Networks; http://www.tropos.com [8] MeshLinux http://zolder.scii.nl/~elektra/meshlinux/index.htm [9] Tropos Networks, “802.11 Technologies: Past, Present and Future” http://www.tropos.com, 2005. [10] Raman, L., OSI systems and network management, Communications Magazine, IEEE Volume 36, Issue 3, March 1998 Page(s):46 – 53. [11] Atul Adya, Paramvir Bahl, Jitendra Padhye, Alec Wolman, Lidong Zhou, “A Multi-Radio Unification Protocol for IEEE 802.11Wireless Networks”, Microsoft Research, 2004. [12] Paramvir Bahl, Ranveer Chandra, John Dunagan, “SSCH: Slotted Seeded Channel Hopping for Capacity Improvement in IEEE 802.11 Ad-Hoc Wireless Networks”, 2004. [13] Kartik Chandran, Sudarshan Raghunathan, S. Venkatesan, Ravi Prakash, A Feedback Based Scheme For Improving TCP Performance In Ad-Hoc Wireless Networks, Computer Science Program, 1998. [14] Karthikeyan Sundaresan, Raghupathy Sivakumar, Mary Ann Ingram and Tae-Young Chang, “A fair medium access control protocol for ad-hoc networks with MIMO links”, School of Electrical and Computer Engineering Georgia Institute of Technology, 2004.
Universidad de Colima Bibliografía
FIME
75
[15] Richard Draves Jitendra Padhye Brian Zill, “Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks”, Microsoft Research, 2004. [16] Ashish Raniwala Tzi-cker Chiueh, “Architecture and Algorithms for an IEEE 802.11-Based Multi-Channel Wireless Mesh Network”, Computer Science Department, Stony Brook University, 2004. [17] Stephen Mueller, Rose P. Tsang, and Dipak Ghosal, “Multipath routing in mobile ad-hoc networks: issues and challenges”, University of California, Sandia National Laboratories, Livermore, 2001. [18] Frey, H., “Scalable geographic routing algorithms for wireless ad hoc networks”, Trier Univ., Germany, Agosto 2004. [19] Ian F. Akyildiz, Janise McNair Joseph Ho, H• useyin Uzunalio,glu Wenye Wang, “Mobility management in next generation wireless systems”, Broadband and Wireless Networking Laboratory School of Electrical and Computer Engineering Georgia Institute of Technology Atlanta, Agosto 1999. [20] Vincent Guyot, “Using WEP in Ad-Hoc Networks”, Universite Pierre et Marie Curie, 2006. [21] Godfrey, M.W. Qiang Tu, “Evolution in Open Source Software:A Case Study”, 2000. [22] Linux Mandriva Website, www.mandriva.com. [23] Redhat Website, www.redhat.es/fedora/. [24] Ubuntu Website, http://www.ubuntu-es.org/. [25] An API for Wireless Cards under Linux, http://www.cs.umd.edu/~moustafa/mapi/mapi.html. [26] Download Site, http://sourceforge.net/projects/libpcap/. [27] Alejandro L´opez Monge, “Aprendiendo a programar con Libpcap”, http://www.e-ghost.deusto.es/docs/2005/conferencias/pcap.pdf, tomado de la World Wide Web en enero 2005. [28] Sitio Oficial de ethereal, http://www.ethereal.com/. [29] Sitio de descarga, http://libdnet.sourceforge.net/. [30] Sitio de descarga, http://anjuta.sourceforge.net/. [31] Charles E. Perkins, Elizabeth M. Royer, “Ad-hoc On-Demand Distance Vector Routing”, Sun Microsystems Laboratories, Dept. of Electrical and Computer Engineering University of California. 1999.
Universidad de Colima Bibliografía
FIME
76
[32] LaMaire, R.O.; Krishna, A.; Bhagwat, P.; Panian, J, “Wireless LANs and mobile networking: standards and futuredirections”, Communications Magazine, IEEE Volume 34, Issue 8, Aug 1996 Page(s):86 – 94. [33] Zhou Haijun; Pan Jin; Shen Pubing, “Cost adaptive OSPF”, Computational Intelligence and Multimedia Applications, 2003. ICCIMA 2003. Proceedings. Fifth International Conference on 27-30 Sept. 2003 Page(s):55 – 60. [34] Página de Garmin, http://www.garmin.com/aboutGPS/. [35] Tomado de la World Wide Web, http://www.gpsinformation.org/dale/nmea.htm#GLL. [36] Sitio Oficial de Wireshark, http://www.wireshark.org/about.html. [37] Sitio oficial de Gcc http://gcc.gnu.org/releases.html. [38] Sitio Oficial de iptraf http://cebu.mozcom.com/riker/iptraf/. [39] Tomado de la World Wide Web diciembre 2006, http://es.wikipedia.org/wiki/Algoritmo_de_Dijkstra. [40] Tomado de la World Wide Web diciembre 2006, http://es.wikipedia.org/wiki/Algoritmo_voraz. [41] Asherson, Stephen and Andrew Hutchison, Secure Routing for Wireless Mesh Networks. In Proceedings Southern African Telecommunication Networks and Applications Conference (SATNAC) 2006, Spier Wine Estate, Stellenbosch, South Africa.