universidad de colima facultad de ingenierÍa mecÁnica y...

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


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


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


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


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


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.


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.


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


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)


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.


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


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.


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]


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].


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:


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.


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.


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.


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


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.


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.


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


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.


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


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


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.


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


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


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].


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


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.


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


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


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.


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.


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


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


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.


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,


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.


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.


FIME

41

Figura 24 Estructura General del dorsal

( ( ) )

Internet

( ( ) )

( ( ) )

( ( ) )

( ( ) )

( ( ) )

( ( ) )

G G

G

G

G


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.


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


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


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


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


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.


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


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.


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


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.


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,


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:


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


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%.


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.


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


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


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


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


Saltos

Tie

mp

o (

ms)

Manual

Pandora

Figura 37 diferencias para EED en paquetes de 1028 bytes a uno dos y tres saltos


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


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.


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.


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 mPacketId;


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" );


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)


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]++;


next].connections[j].dest]]=graph[next].connections[j].dest;

}

else

{

for

}


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;


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


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];


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);


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;

}


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


/* 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)

{


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;


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 */


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);


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);} }

}


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.

http://www.locustworld.com/

http://www.tropos.com/

http://zolder.scii.nl/~elektra/meshlinux/index.htm

http://www.tropos.com/


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.

http://www.mandriva.com/

http://www.redhat.es/fedora/

http://www.ubuntu-es.org/

http://www.cs.umd.edu/~moustafa/mapi/mapi.html

http://sourceforge.net/projects/libpcap/

http://www.e-ghost.deusto.es/docs/2005/conferencias/pcap.pdf

http://www.ethereal.com/

http://libdnet.sourceforge.net/

http://anjuta.sourceforge.net/


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.

http://www.garmin.com/aboutGPS/

http://www.gpsinformation.org/dale/nmea.htm#GLL

http://www.wireshark.org/about.html

http://gcc.gnu.org/releases.html

http://cebu.mozcom.com/riker/iptraf/

http://es.wikipedia.org/wiki/Algoritmo_de_Dijkstra

http://es.wikipedia.org/wiki/Algoritmo_voraz

universidad de colima facultad de ingenierÍa mecÁnica y...

Documents