domingo, 26 de mayo de 2013

Reporte - Resumen: Aplicación de redes sensoras

Tema: Mobile Agent Middleware for Sensor Networks: An Application Case Study
Autores: Chien-Liang Fok, Gruia-Catalin Roman, and Chenyang Lu
Washington University in Saint Louis

1.- Introducción:

Las redes de sensores inalámbricos (siglas en ingles: WSN) consisten en pequeños sensores arraigados en el entorno.
Algunos ejemplos donde se aplica seria en la supervisión del hábitat, vigilancia, atención médica y en monitorear alguna estructura.
Estas aplicaciones tienen intervalos largos de implementación por el gran número de nodos, y su exposición al medio físico, y eso da lugar a una alta probabilidad de que muchos de ellos se desactivan.

Las WSN deben hacer frente a entornos altamente dinámicos, por ejemplo: mientras que una red de seguimiento de incendios este desplegado en un bosque, puede permanecer inactivo la mayor parte del tiempo, si un ocurre un incendio forestal y se extiende, debe de provocar rápidamente numerosas actividades en la red, entonces las aplicaciones de WSN tienen que ser flexibles y adaptables.

Las aplicaciones WSN son difíciles de desarrollar y desplegar, por ejemplo: una plataforma WSN se compone de MICA2 y TinyOS del sistema operativo, TinyOS es un sistema operativo basado en eventos, con una curva de aprendizaje alta, por lo tanto, las aplicaciones de TinyOS sólo pueden ser ligeramente ajustados, cambiando los parámetros definidos antes del despliegue.

En este tipos de casos, los Middlewares promete mejorar la flexibilidad de las aplicaciones WSN.
Excluyendo al proyecto Agilla, otros middlewares incluyen a XNP, Diluvio, Mat'e, SensorWare, Impala y los mensajes inteligentes.

Para hacer frente a las limitaciones de los middleware más arriba, se desarrollo "Agilla", un agente de middleware móvil para redes inalámbricas con sensores.

Agilla se basa en Mat'e, pero a diferencia de Mat'e, que divide una aplicación en cápsulas que se inundan a través de una red, Agilla permite a los usuarios instalar aplicaciones mediante la inyección de agentes móviles en una red de sensores.

Se implemento Agilla en un modulo MICA2 Mote y en el sistema operativo TinyOS.

En este artículo se presenta un estudio de caso de Agilla, utilizando una aplicación de seguimiento de incendios.
En esta aplicación, los agentes móviles se despliegan para formar y mantener dinámicamente un perímetro alrededor de un fuego ya que se propaga a través de una red.

En este artículo hacen tres contribuciones principales:
  • En primer lugar, muestran cómo el middleware de agente móvil se puede utilizar para facilitar el desarrollo y el despliegue de una aplicación no trivial.
  • En segundo lugar, se presentan resultados sobre el rendimiento a nivel de aplicación, demuestran la fiabilidad y la eficiencia de los agentes móviles.
  • Y finalmente, en tercer lugar se proporcionan nuevos conocimientos con lecciones para técnicas de programación en agentes móviles para redes inalámbricas de sensores.

Y a continuación los temas del documento.

2.- Agilla Overview

Como se habia mencionado antes en el documento, las aplicaciones Agilla consisten en agentes móviles que pueden moverse y clonarse a sí mismos con realización a tareas específicas de la aplicación.

Agilla proporciona instrucciones de alto nivel que permiten a los agentes internos que lleven a cabo tareas complejas.

La arquitectura del agente móvil se muestra en la Figura 1.
Se compone de una pila, un montón, y diversos registros.

Los agentes móviles utilizan una arquitectura de pila, ya que permite la mayoría de las instrucciones por ser de un solo byte.

El modelo Agilla se muestra en la Figura 2.

Cada nodo es compatible con un máximo de cuatro agentes, Agilla maneja automáticamente el cambio de contexto que permite a los agentes que se ejecutan simultáneamente e independientemente.

Agilla proporciona dos componentes que facilitan la coordinación entre los agentes: un espacio como tupla, y una lista conocida, Ambos se mantienen en cada nodo del middleware.

Para evitar el "sondeo", Agilla aumenta el espacio de tuplas con reacciones, que permiten a un agente para reaccionar a la presencia de una tupla que coincide con una plantilla determinada.

Se debe de tener en cuenta que Agilla no admite un espacio de tuplas global que se extiende a través de múltiples nodos, debido principalmente a las limitaciones de ancho de banda y la energía, en cambio, soporta espacios de tuplas locales en cada nodo mantiene un espacio de tuplas distintas y separadas.

Agilla también mantiene una lista de conocimiento en cada nodo, esta lista contiene la localización de todos los vecinos de un salto, también implementa su propio gestor de memoria dinámica para obtener instrucciones de agente y los espacios de tuplas.

3.- Aplicacion para monitorear el fuego.

La aplicación para monitorear el fuego se muestra en la Figura 4.

Un fuego se enciende en una región que estará dentro de la red de sensores, y a medida que el fuego se extiende, los agentes que estarán alrededor de él, se clonan en repetidas ocasiones para crear un perímetro, y una vez que se forma el perímetro, notifican al departamento de bomberos.

Al realizar el caso de estudio, se centraron en los agentes para monitorear.

Ellos moldearon el fuego con insertar tuplas donde contuvieran la cadena "estrella" en los nodos que informaban que se estaba "quemando", y el agente podía utilizar las operaciones de las tuplas remotas (por ejemplo, rrdp o rrdpg) para detectar los incendios.

Se utilizan dos tipos de agentes contra incendios para el modelado de fuego: estáticos y dinámicos, los agentes contra incendios estáticos simplemente insertan una tupla incendio en el espacio de tuplas locales.

El código se muestra en la Figura 5.

Los agentes estáticos se utilizan para crear los incendios de diferentes formas para el agente de seguimiento y así formar un perímetro alrededor del incendio.
El agente extintor dinámico funciona mediante la inserción de una tupla a su llegada, y luego haciendo parpadear el LED rojo un cierto número de veces.

Ahora, si el agente perseguidor del fuego descubre y forma un perímetro alrededor del fuego, muere si el nodo captura el fuego en ese perímetro, esto se realiza mediante el registro de una reacción que mata el agente cuando se inserta una tupla de fuego en el espacio de las tuplas locales.

El código que registra esta reacción se muestra en la Figura 6.

El ciclo de vida de un agente rastreador o perseguidor se muestra en la Figura 7.

El ciclo anterior muestra el como funciona comprobando repetidamente si alguno de sus vecinos están en llamas, si no hay ninguno, se realiza un movimiento débil para un vecino aleatorio y repite el proceso, y si un vecino está en llamas, entra en modo de seguimiento.

4.- Indicadores de Rendimiento

En este apartado, para evaluar su agente de seguimiento de incendios, probaron su rendimiento en una WSN con un modulo wirelles MICA2 Mote en una cuadrícula de 5 x 5 (el modulo sirve como estación base por separado).

Mediante la disposición del modulo, fueron capaces de calcular la ubicación del nodo (x, y) en función de su dirección.

Para crear una red multi-hop en el espacio limitado de su laboratorio, modificaron la pila de red TinyOS para filtrar todos los mensajes, excepto los de los vecinos horizontales, verticales y diagonales sobre la base de la topología de la red.

Los resultados reflejaron los escenarios en los peores de los casos, debido a un aumento de la probabilidad de colisiones inalámbricas.

Se realizaron dos tipos de pruebas: el primero, utiliza agentes contra incendios estáticos para determinar la velocidad del perímetro, y el segundo, utilizaron los agentes contra incendios dinámicos para determinar qué tan bien los agentes Tracker puede ajustar el perímetro cuando el fuego se propaga.

Para las pruebas de fuego con agentes estáticos, se inicia el WSN mediante la inyección de agentes contra incendios estáticos en ciertos nodos para generar incendios de diversas formas y tamaños, un agente de seguimiento de incendios se inyecta en un nodo al lado del fuego, al inyectar el agente de seguimiento junto al fuego, se aísla la fase de descubrimiento de la fase de seguimiento.

Se hicieron pruebas en varios incendios diferentes, como se muestra en la Figura 8.

En la imagen se muestra cuando en el nodo se inyecta el agente detector y está marcado con una estrella de color negro, las flechas indican que el detector debe clonarse a sí mismo para formar el perímetro.

Para realizar una captura del progreso al momento de formarse el perímetro, se utilizo una videocámara digital, y los resultados se muestran en la Figura 9.

En la imagen se puede observar que en la mayoría de los casos se forma el perímetro dentro de 3 segundos.
En el escenario que llevó más tiempo es la escena A, y se debe a que su configuración contenían áreas que impedían la propagación de agentes múltiples en paralelo.

Los resultados que se muestran en la Figura 9, muestran claramente cómo el punto inicial de seguimiento de fuego tiene un impacto significativo en la velocidad a la que se forma el perímetro.

Para evaluar la capacidad del detector para mantener un perímetro en un incendio, se inyectan cuatro agentes de seguimiento de incendios en la red con una estrella negro en la Figura 10, y luego se inyecta un agente de fuego dinámico en el nodo (5,5).

Se llevaron a cabo dos pruebas: una con un agente de fuego lento y otro con fuero rápido, y se utilizó la cámara de vídeo digital para grabar cada ejecución de las pruebas de fuego dinámico

Los resultados se muestran en la Figura 11.

En la imagen se muestra que el rastreador de fuego hace un buen trabajo al mantener un perímetro alrededor del fuego lento, pero tiene dificultades con el fuego rápido. 

En el experimento rápido, el agente de fuego se extiende rápidamente.


La razón por la que ambos convergen al 100% se debe porque el fuego se propaga, y la red se convierte en el tiempo saturado de un agente en cada nodo.

5.- Lecciones aprendidas

Aquí, en este apartado muestran un pequeño resumen sobre las lecciones aprendidas durante todo el proyecto y en que se batallo y que fue lo mejor.

Se debe de tener una buena elección entre el uso de operaciones con migración fuerte y débile, ya que tiene un impacto significativo en la complejidad y la eficiencia del código.

Definitivamente el código fuente del agente se dividió en dos módulos para reflejar los dos modos de funcionamiento, por ejemplo: la detección de incendios y el seguimiento de incendios.

Se encontraron problemas con respecto al tamaño del agente, al ser demasiado grande para caber dentro de las limitaciones de memoria en el modulo MICA2 Mote.

Después de optimizar el agente en los dos módulos, se percataron que el modo del agente podría inferir en base a que si habían nodos vecinos en el fuego, eso permitió combinar los dos bloques de código para la reducción del tamaño de la agencia.

También notaron que el conjunto de instrucciones puede reducir significativamente el tamaño del código.

Se agregaron dos instrucciones en el caso de estudio, fueron rrdpg y surrondings, rrdpg determina la dirección de todos los vecinos, sin ella, cada vecino tendría que ser consultada de forma individual.
A diferencia de otras instrucciones, rrdpg almacena los resultados en la pila, ya que a menudo se utilizan en numerosas ocasiones.

La arquitectura de Agilla, permite a los usuarios añadir y eliminar las instrucciones off-line, y cuando se compila y se instala, no se pueden agregar nuevas instrucciones. 

Y finalmente notaron que la programación en un lenguaje ensamblador es una tarea extremadamente tediosa y propenso a tener muchos errores.

6.- Conclusión:

A lo largo de todo el trabajo realizado, se demostró que Agilla se puede utilizar para implementar aplicaciones complejas en redes de sensores inalámbricas.

También se demostró cómo las aplicaciones múltiples pueden compartir simultáneamente una red.

Se presento un caso de estudio de cómo los agentes móviles se pueden utilizar para programar un WSN para el seguimiento de fuego.

Se demostró que los agentes móviles y su comunicación basada en tuplas son factibles, y estas abstracciones se pueden utilizar para aumentar la flexibilidad de la red.

También se demostró que los agentes del perseguidor de fuego pueden mantener un perímetro alrededor de un fuego dinámico, ya que se propaga a través de una red.


Con la experiencia al desarrollar esta aplicación, se llevó a la adición de varias instrucciones, lo que permite  a Agilla proporcionar una mejor base para desarrollar rápidamente aplicaciones flexibles para redes inalámbricas de sensores.

Critica:

Durante todo el proceso del proyecto, debido al tiempo en que a pasado desde que se realizo, utilizaron herramientas algo obsoletas, ahora se podrían adquirir las mismas herramientas pero de mejores versiones y con nuevas funcionalidades.

También se podrían mejorar los algoritmos utilizados en la red de nodos, ya que como se mostró en algunas ocasiones se mostró que hubo fallas.

Y por ultimo, utilizaron lenguaje ensamblador es demaciado complicado, tedioso, consume tiempo, y todo por que es algo dificil, es mejor utilizar lenguajes de alto nivel, ya que se evitarian demaciados problemas

Referencia:

viernes, 24 de mayo de 2013

Laboratorio - Simulación 3D adhoc

Esta entrada es sobre una simulación de una red Ad Hoc, pero esta vez en 3D, con alguna superficie, si requieren ver mi entrada sobre simulación de una red Ad Hoc, entren al siguiente enlace: Reporte: Ad Hoc

Me base en varios programas de varios compañeros y algunas documentaciones para realizar esta entrada:

Introducción

Las simulaciones que realice, fueron realizadas para simular una red sensóra Ad Hoc, donde tienen como fondo 3D, los nodos son sensores, los cuales realizan una acción cada que tienen contacto con el terreno simulado en 3D

Herramientas

Algunas herramientas que utilice para realizar las diferentes simulaciones, fueron las siguientes:
  • Blender 2.6
  • Matplotlib 1.2.1 
  • Python 2.7

Instale Matplotlib para python, si quieren obtener mas información, entren al siguiente enlace: Matplotlib.org

Encontraran las opciones donde podrán descargar matplotlib, algunas paginas con documentación y ejemplos.

Simulación 

Como lo comente antes, realice varias simulaciones, primero realice una simulación en Blender, después varias pruebas con Matplotlib, pero tuve algunos problemas, enseguida una pequeña explicación de cada uno:

Simulación Blender

En esta simulación, genere lluvia, genere unos nodos estáticos, y solo mostraba un mensaje cuando el agua "tocaba" al nodo.

Primero genere el entorno en 3D con los nodos generados estáticos, quedo así:

Aquí una muestra que los nodos estaban colocados en la posición donde cae el "agua" y no se encuentran en otra posición, quedo así:

En esta imagen ya con la animación iniciada, se obtuvo lo siguiente:

Aquí un vídeo de la simulación:

Simulación en Matplotlib

En las siguientes simulaciones, solo cree entornos en 3D, con nodos estáticos, y los nodos se conectaban unos con otros.

En estas simulaciones falto implementar al 100% la red con sensores, ya que era la primera vez que utilizaba este lenguaje y fue algo complicado, batalle y quedaron en algo muy básico.

Simulación 1:

En la primera simulación, solo genere los nodos estáticos, y no era una red de sensores, quedo así:

Código uno:


Simulación 2:

En esta segunda simulación simule un escenario en 3D en donde consistía el "mar" no salio perfecto, pero volví a colocar nodos, simulando la red con sensores, pero también tuve problemas, aun así quedo algo básico:

Aquí la muestra que se genero en 3D y se tiene una vista desde arriba:

Código dos:


Simulación 3: 

 En esta ultima simulación volví a colocar nodos, y ahora si logre colocar una red de nodos con algo de sensores, se unían dos nodos con un evento de por medio.

Otra imagen desde con otro punto vista:

Coloque los nodos sensores, y los nodos se conectaban por medio de un evento, las lineas cambiaban de color cuando se conectaban unos con otros.

Código tres:


Comentarios

Las simulaciones en matplotlib batalle, ya que como lo había mencionado antes, era la primera vez en que realizaba pruebas con esa herramienta, falto crear las redes de sensores, me quede a la mitad del trabajo, y crear la animación como lo hice en Blender.

Falto implementar la comunicación con rangos ajustables y TTL

Referencias

martes, 21 de mayo de 2013

Reporte - Ad hoc

Para esta semana se pidió que realizáramos una simulación de una red Ad Hoc.

Me base en otros programas de mis compañeros, para realizar la tarea.

Introducción 

El programa consiste en simular una red MANET, con llegada y salida de nodos, tiene consigo un modelo de movilidad (En este caso se lleva a cabo una movilidad en grupo, que en este caso se utilizo "Random Waypoint"), nodos con capacidad de batería, envió de mensajes y cada nodo reduce su batería según su radio de transmisión.

Simulación

Primero tenemos los nodos generados en la ventana:

Los nodos cuentan con la "pila":

pila = 700

Después tenemos al nodo "enemigo" y es el nodo al que siguen todos los demás, de color negro:

Desaparecen los nodos cuando se acaba su pila, y vuelven a aparecer en otro color
Se muestra cuando los nodos mueren, en la ventana vuelven a aparecer.
Falto implementar el envió de mensajes y reducir su batería según su radio de transmisión.

Código


Un vídeo de la simulación a continuación:

Vídeo

Los nodos se movilizan buscando al "enemigo", después a cada nodo se le acaba la pila, y después vuelven a re-aperecer con un color random.

Referencias

lunes, 20 de mayo de 2013

Laboratorio - Reporte: Redes Adhoc

Tema: CarNet - A Scalable Ad Hoc Wireless Network System
Autores: Robert Morris, John Jannotti, Frans Kaashoek, Jinyang Li and Douglas Decouto

Introducción 

CarNet es una aplicación para sistemas de redes móviles con una red AdHoc a gran escala y no se necesita una infraestructura de red para en-rutar los mensajes.

Esta aplicación apoya la conectividad por medio de IP, así como aplicaciones para la monitorización cooperativa de congestión, el seguimiento de EET, y en descubrir los puntos cercanos de interés.

Mencionaban que estaban diseñando una arquitectura de red escalable y dinámica denominada Grid, y que sería más fácil de implementar que muchas aplicaciones ya existentes.

Deseaban diferentes tipos de dinamismos para el proyecto, primero: introducir un nuevo nodo a la red y que no debería requerir la intervención humana, toda la configuración debe de ser de forma automática; segundo: la red no debe depender de una infraestructura; tercero, los nodos deben ser capaces de moverse; cuarto: debe ser fácil para que las aplicaciones interactuen entre si y quinto: los protocolos subyacentes deberían proporcionar API's y utilizar algoritmos.

Los objetivos principales de esta investigación son similares a los de los sistemas de redes móviles AdHoc (MANET).

En el documento se muestra como quisieron construir un sistema que pudiera escalar a cientos de miles de nodos, sin escalas con tecnología de red ya existentes y sin depender de técnicas jerárquicas estáticas.

Para probar la red que se estaba diseñando e implementando, escogieron la aplicación CarNet porque su despliegue va en incremento.

En este trabajo se describe el diseño general provisional y cuadricular en los sistemas de organización del CarNet.

2.- Arquitectura

En esta parte, se explica que la funcionalidad de la escalabilidad funciona de manera de reenvío geográfico, el nodo de origen anota cada paquete en conjunto con la ubicación a donde tiene que llegar el cual es su destino.

En cada nodo, se realiza una decisión puramente local para reenviar el paquete al nodo vecino que está geográficamente más cercano al destino.
El reenvío no implica ninguna información global de ayuda a la escala del enrutamiento geográfico.

2.1.- Servicio de Ubicación de Red (GLS)

La expedición geográfica requiere el envío de nodos para descubrir los lugares de destino, es decir, la red debe proporcionar una base de datos con los mapas de cada nodo con su ID permanente en conjunto con su ubicación geográfica.

La base de datos no debería depender de cualquier infraestructura porque podría dificultar el despliegue de escalabilidad, al contrario, debe ser distribuido por todos los nodos..

Todos los nodos en el sistema están coordinados con un algoritmo distribuido "f(i)"que mapea cada nodo identificado a una lista de ubicaciones físicas, con sus latitudes y longitudes.

Las ubicaciones producidas por "f(i)" actúan como servidores de localización de nodos, sin embargo si el nodo "i" se mueve, utiliza el reenvío geográfico para enviar actualizaciones con las ubicaciones especificadas por "f(i)", los nodos cercanos a esos lugares recuerdan la posición del nodo "i".

En la siguiente figura 1 se muestra un mensaje sobre el encabezado de GLS en un rango de tamaños, y la figura 2 indica los paquetes de datos entregados con éxito.
Figura 1:

Figura 2:


Esas figuras fueron obtenidas por medio de simulaciones que implicaban una buena cantidad de movilidad en los nodos.

2.2 Gestión de Densidad  

Aquí explican que el reenvío geográfico puede fallar cuando la red no es suficientemente densa, por lo que los paquetes encuentran agujeros en la topología, es decir, un paquete puede llegar a un nodo donde no tiene vecinos en su radio y que están cerca de su destino.

Por otro lado, una red de radio también puede ser demasiado densa.  Las radios que se encuentran dentro
del alcance del radio de cada nodo con otro, debe compartir el espectro limitado, y a medida que aumenta la densidad de los nodos, el ancho de banda disponible para cada nodo disminuye.

Tomando en cuenta el radio de los agujeros en la distribución de nodos utilizan técnicas como Karp y Bose.

La idea básica es que los nodos estén de acuerdo en las conexiones necesarias para enviar los paquetes alrededor de los perímetros del agujero hasta que avancen o regresen al punto de partida.

La idea es variar la potencia de transmisión con la idea de mantener un número con  una constante aproximada al rango de nodos del radio, esto ayuda a mantener la red conectada a densidades bajas.
También se obtiene un ahorro de energía similar a la del enrutamiento.

3.- Aplicaciones

En el documento explican que construyeron un sistema con una cuadrícula alrededor para explorar cómo la rejilla interactua con las aplicaciones, el hardware y con sus tensiones de despliegue a gran escala.

En el CarNet cada Coche tendrá un nodo y que consiste en un equipo Linux, con radio IEEE 802.11, un receptor GPS y pantallas para el conductor y pasajero.

3.1.- Localización de Recursos

La localización de recursos era un propósito general para aplicación proporcionada por la red movil.
En GLS se pueden utilizar recursos sin alteraciones para localizar las inmediaciones.

En la idea simplemente consistía en asociar un nombre estándar a un recurso, como "\impresora", "\cache-web" o para el punto de acceso "\Internet ".

Ya con los nombres, se les aplicaba un algoritmo hash para obtener una identificación y a continuación, participaban en el protocolo de GLS, se tomaba en cuenta que GLS es robusto por los múltiples nodos que utilizan un mismo ID, y por ultimo el resultado final era el deseado, al realizar una búsqueda de ubicación, los nodos veían al recurso más cercano a ellos.

3.2 Conectividad IP

La conectividad IP era un punto importante en CarNet, a cada nodo se le asignaba una dirección IP, una máscara de subred y la dirección IP de su router por defecto.
Los nodos inalámbricos participaban en el protocolo utilizando un hash de la dirección IP como su ID.

Para enviar un paquete a través de Internet, el nodo determinaba la localización de la puerta de entrada y reenviaba el paquete IP.

3.3.- CarNet Specific

Además de los servicios directos como la ubicación de los recursos y la conectividad IP, se esperaba que las propiedades de una red inalámbrica en la que los nodos conocen sus propios lugares pueden inspirar a otras aplicaciones parecidas.

3.4.- Privacidad

El uso del enrutamiento geográfico presenta un problema para los usuarios preocupados por la privacidad de su ubicación y movimientos.

Si se utilizaba GLS, cualquier nodo puede localizar a un nodo cuyo ID sea reconocido.

Creemos que ambas técnicas podrían impedir que este hecho de privacidad se convierta en un tema de preocupación para la mayoría de usuarios.

Los nodos pueden cambiar las direcciones IP en poco tiempo, muchos nodos pueden compartir un grupo de direcciones IP, con lo que el seguimiento de los individuos se dificulta.

Un punto en contra es que si cambia periódicamente la dirección IP protege a un usuario de un seguimiento por parte de terceros, pero no se impide a los nodos contactados por el usuario.

Para solucionar este problema, los usuarios pueden considerar el uso de un proxy para algunas conexiones sensibles.

4.- Trabajos relacionados

En los trabajos relacionados, existen pocos ejemplos de sistemas implementados con redes Ad Hoc, por mencionar algunos son: la Metricom Ricochet y Nokia.

Hay alguno algoritmos existentes sobre redes AdHoc, como: DSR, AODV, DSDV, y TORA.

Conclusión

Los autores esperaban que el despliegue de CarNet sacará a la luz nuevos problemas y nuevas soluciones.

El sistema maneja a un gran número de nodos a grandes escalas mediante el reenvío geográfico.

El problema de la variación en su densidad de cada nodo se volverá a requerir algoritmos adaptativos para gestionar el espectro radioeléctrico y los niveles de potencia.

CarNet facilitará la creación de nuevas aplicaciones adaptadas a las redes geográficamente conscientes.

Critica

En el documento resaltaban de manera muy importante el sistema debería de ser dinámico y así evitar contratiempos, puede que sea una técnica buena, pero no es 100% confiable, aun así en los tiempos modernos hacer un sistema manual ya no es rentable .

Ya que este documento fue editado hace mas de 5 o 6 años, utilizan herramientas como IP; maquinas Linux y todo eso podría ser utilizado de manera mas eficaz con herramientas actualizadas y así tener un resultado mas optimo.

En este caso podría utilizarse otro tipo de algoritmos para que sean mas eficientes con proyectos dedicados a redes AdHoc.

Referencia

martes, 14 de mayo de 2013

Laboratorio - Investigación: Sistemas Satelitales

En esta entrada, se muestra una pequeña investigación sobre sistemas satelitales y en donde se aplica, mecanismos para interceptar la comunicación de dichos sistemas y como protegerlos.

1.- Introducción 

Un satélite artificial es una nave espacial enviada en un vehículo de lanzamiento o un tipo de cohete que envía la carga hacia el espacio y puede realizar diferentes actividades.

Los satélites artificiales pueden orbitar alrededor de lunas u objetos naturales del espacio como planetas. Tras su vida útil, los satélites artificiales pueden quedar orbitando como basura espacial.



Tipos de satélites:

  • Órbita baja terrestre (LEO): a una altitud de 0 a 2000 km
  • Órbita media terrestre (MEO): con una altitud entre 2000 km
  • Órbita alta terrestre (HEO): con una altitud por encima de la órbita de 35 786 km.

2.- Aplicaciones: 

Los sistemas satélites pueden ser útiles para muchos cosas, hoy en día existen muchos satélites con diferentes usos, los cuales pueden ser los siguientes:

  • Astronómicos 
  • Anti-satélites
  • Comunicación  
  • Espías
  • Meteorológicos
*Astronómicos:

Un observatorio espacial, también conocido como telescopio espacial, es un satélite artificial o sonda espacial que se utiliza para la observación de planetas, estrellas, galaxias y otros cuerpos celestes de forma similar a un telescopio en tierra.

 Se han lanzado una cantidad importante de telescopios espaciales a órbita desde que Cosmos 215, considerado el primer observatorio espacial.

*Anti-satélites:

Un arma anti-satélite es un arma espacial diseñada para incapacitar o destruir satélites con fines estratégicos militares.

Actualmente, los Estados Unidos, Rusia y la República Popular de China son los únicos que se conoce que han desarrollado este tipo de armamento.

*Comunicación:

Los satélites artificiales de comunicaciones son un medio muy apto para emitir señales de radio en zonas amplias o poco desarrolladas, ya que pueden utilizarse como enormes antenas suspendidas del cielo.

Se suelen utilizar frecuencias elevadas en el rango de los GHz; además, la elevada direccionalidad de antenas utilizadas permite "alumbrar" zonas especificas de la Tierra.

*Espías:

Un satélite espía es un satélite artificial de observación terrestre o de comunicaciones destinado a uso militar o para inteligencia.

Algunos satelites espías:
  • Estados Unidos
    • Lacrosse/Onyx
    • Misty/Zirconic
    • Samos
    • Quasar
    • Vela suárez
    • Vortex/Chalet
  • Unión Soviética
    • Cosmos
    • Almaz
    • Yantar
    • Zenit
  • Alemania
    • SAR-Lupe 1-5
    • Francia, España, Italia y Bélgica
    • Helios 
  • Reino Unido
    • Zircon
  • India
    • Satélite Experimental de Tecnología
  • Israel
    • Ofeq

*Meteorológicos:

Un satélite meteorológico es un tipo de satélite artificial que se utiliza principalmente para supervisar el tiempo atmosférico y el clima de la Tierra.

Sin embargo, ven más que las nubes, las luces de la ciudad, fuegos, contaminación, auroras, tormentas de arena y polvo, corrientes del océano, etc., son otras informaciones sobre el medio ambiente recogidas por los satélites.

Tipos:

Existe dos tipos básicos de satélites meteorológicos por su órbita: los geoestacionarios y los polares.

3. Proteger comunicaciones satelitales

Algunos métodos para combatir las amenazas en sistemas satelitales pueden ser: evasión y alteración de comunicación.

*Evasión:

Se evita cualquier interrupción en la operación del satélite.
Este método parece simple, pero requiere una coordinación mayor, y en general  los satélites siguen su órbita según sea la misión que vayan a realizar.
Este método puede causar un alto grado de vulnerabilidad.
La habilidad para alterar el curso del satélite en una situación peligrosa desviaría fallas en seguridad.

*Alteración de comunicaciones:

Es simple y es empleado este método como solución para evadir intersecciones, además previene la detección del satélite. Requiere de un transmisor adaptable capaz de transmitir señales de alta resistencia para no darle oportunidad a sistemas que intercepten sus transmisiones.


4. Mecanismos para interceptar comunicaciones:

En las comunicaciones satelitales se da por dar mal uso en los enlaces del satelite con la tierra.

Cuando realiza su rotación normal, una pequeña señal es generada en el satélite cuando se encuentra en su orbita. El transmisor manda la señal a la antena, y este a la ves, proyecta la señal a otro receptor en la estación que se encuentra en la tierra.

Lo preocupante en este proceso, es que se encuentra un mal uso de la comunicación, algunos mensajes enviados por estos enlaces son de suma importancia. Las dos formas principales para la interrupción o intercepción de estos mensajes son:  Acción preventiva, Malversacion e intercepción de señales.

*Acción Preventiva:

Estas medidas son empleadas en tiempos con hostilidades abiertas y con el objetivo de eliminar los recursos de los enemigos.
Aunque esto puede ser combatido usando secuencia de modulos en una tasa de transmisión de datos, es una buena forma para prevenir que cualquier señal sea recibida en un host determinado.

*Malversación:

Este método puede ser considerables al "wire-tapping", permitiendo al agresor obtener información sobre su blanco y usarlo de manera ventajosa.
Si se utiliza este método, el resultado de estos esfuerzos es que la fuerza hostil gana control del satélite, su información y capacidades.

*Intercepción de Señales:

Este método es la intercepción de señal a nivel de tierra y depende mucho de la transmisión de señal desde el satélite objetivo en órbita. Después de la transmisión de la señal, una fuerza hostil puede emplease en la estación de la tierra o dentro del rango de la comunicación.
Este método es una forma efectiva para recolectar inteligencia y ganar ventaja en contra del enemigo.


5.- Conclusión:

Los sistemas satelitales, son demasiado importantes para la vida diaria, si llegaran a ser utilizadas de manera no apropiada, habría un declive de redes de comunicaciones, problemas son sistemas de gobierno, etc.
Para esto, los países deben de tener un muy buen sistema de seguridad para cada uno de sus sistemas satelitales, ya que sin ellos o con alguna falla que se presente, seria un gran problema para la población en general.

Referencias:

Reporte - Geolocalización

Para esta semana, se pidió una simulación de Geolocalización, donde utilizare el método de triangulación.
Me base en trabajos de mis compañeros y realice lo siguiente:

En el código, utilice Python en conjunto con Pygame para dibujar los círculos, después, doy las coordenadas a utilizar y dan la localización de los transmisores y el receptor, ya colocados, se mandan las señales y el receptor solo conoce la señal que mandan los transmisores.

Simulación: 

Primero, tenemos los transmisores, los cuales son 3, y un receptor.

Los transmisores de color verde y el receptor de negro.

Después la señal la manda el primer transmisor, el cual manda la señal y llega con el receptor.

Enseguida, el segundo transmisor manda la señal y también llega al receptor.

Por ultimo, el tercer receptor hace el mismo trabajo, manda la señal y llega al receptor

Y queda de la siguiente manera:

Aquí esta el código:

Código: 


Aquí un vídeo de la simulación final:

Vídeo: 

El vídeo muestro lo anteriormente explicado, donde mandan las señales hacia el receptor.

Referencias: 

lunes, 6 de mayo de 2013

martes, 30 de abril de 2013

Reporte - Control de Congestión.

Para esta semana se nos encargo una simulación en Ns-2 sobre control de congestión y realizar un reporte.

Anteriormente, realice un post sobre ns-2, donde inicie con algo básico, por si es necesario algo de retro alimentación.

Control de Congestión.

Primero, se realizaron las siguientes pruebas:

Prueba 1:

Ya que el nodo 1, enviaba mas paquetes que los demás nodos, como se muestra en la siguiente imagen:
Después que se saturaba de paquetes, se cerraba el nodo (se cerraba y se mostraba con el nodo en color rojo), y así evitar congestionamiento, como se muestra la siguiente imagen:

Prueba 2:

En este método  cuando se congestiona con tantos paquetes, solo lo que hace es reducir el proceso de envió  baja y se estabiliza, y en teoría, se vuelven "normales" las tasas de envió.

Simulación

Y el código es el siguiente:

Código:

Al código esta vez se agrego código para controlar la congestión, esta documentado donde se muestran cuales son los métodos para controlar.

Resultados de Pruebas:

Vídeo de Prueba 1:

Mostrando cuando se cierra el nodo y se controla la perdida de paquetes, así evitamos que la simulación pierda paquetes durante todo el proceso

Vídeo de Prueba 2:

Se muestra como baja el proceso de envió, así evitando perdida de paquetes y se estabiliza. 

lunes, 29 de abril de 2013

Resumen - Ahorro de Energía.

Tema: A Centralized Energy-Efficient Routing
Protocol for Wireless Sensor Networks

SIVA D. MURUGANATHAN, DANIEL C. F. MA, ROLLY I. BHASIN, AND
ABRAHAM O. FAPOJUWO, UNIVERSITY OF CALGARY

Introducción: 

Las Redes de sensores inalámbricos constan de cientos o miles de nodos de baja potencia que operan con capacidades computacionales y de detección limitadas.

La evolución de las tecnologías inalámbricas de micro-sensores integrados han hecho que estos nodos esten disponibles en gran número y a un bajo costo, para ser empleados en aplicaciones de seguridad militar, en vigilancia del medio ambiente, etc.

En contraste con los sensores tradicionales, las redes de sensores ofrecen una proposición flexible en términos de la facilidad de implementación y múltiples funcionalidades.

En el caso de nodos de sensores inalámbricos modernos, sus dimensiones físicas permiten un gran número de nodos de sensores para ser desplegados al azar en terrenos inaccesibles.

Los nodos en una red de sensores inalámbricos también son capaces de llevar a cabo otras funciones tales como el procesamiento de datos y de enrutamiento.


Modelos de Redes y Radio

1.- El modelo de red y Arquitectura

La base de BCDCP radica en que la estación base es un nodo de alta energía con una gran cantidad de suministro de energía.

Por lo tanto, BCDCP utiliza la estación base para controlar la tarea de detección coordinado realizado por los nodos sensores.

Aquí se muestra un modelo de red de sensores con las siguientes propiedades:

• Una estación de base fija que se encuentre lejos de los nodos de sensores.
• Los nodos sensores disponen de energía finita
• Los nodos están equipados con funciones de control de potencia.
• Cada nodo detecta el medio ambiente a una tasa fija.
• Todos los nodos sensores son inmóviles.

Los dos elementos clave que se consideran en BCDCP son los nodos sensores y la estación base.

2.- El Modelo de Radio

Un nodo sensor típico se compone de cuatro componentes principales: una unidad de procesador de datos, un micro-sensor; un sub-sistema de comunicación por radio que consiste en un transmisor/receptor de la electrónica, antenas, y un amplificador y una unidad de fuente de alimentación.

Aunque la energía se disipa en todos los tres primeros componentes de un nodo sensor, se considera que las disipaciones de energía asociados con el módulo de radio ya que el objetivo central es desarrollar un protocolo de capa de red de eficiencia energética para mejorar la vida de la red.



Estación de base controlado
Protocolo Clustering Dinámico

El BCDCP es un sensor inalámbrico de protocolo de enrutamiento, es un componente esencial con capacidades computacionales complejos, por lo que los nodos de sensores son simples y rentables.

Opera en dos fases principales: la configuración y comunicación de datos.


1.- El esquema de direccionamiento

En las redes tradicionales, a los nodos se le asignan direcciones fijas, sin embargo, debido a los altos costos, el esquema de direccionamiento fija podría no ser adecuado para redes de sensores inalámbricas.

Además, ya que el usuario final está más interesado en las consultas basadas en atributos tales como "Envíame el número de vehículos estacionados en el lote número 7," es más probable que utilice un esquema de direccionamiento basado en los nodos, atributos y posiciones geográficas.

Por lo tanto, para BCDCP se uso una clase basada en abordar de forma <Location ID, Tipo de nodo ID>.
El ID identifica la ubicación de un nodo que lleva a cabo actividades de detección en una región determinada de la red.

2.- La fase de configuración

Las principales actividades de esta fase son la configuración del clúster, la selección de cabeza de racimo, formación de ruta de acceso, y la programación para cada cluster.

Durante cada fase de configuración, la estación base recibe información sobre el estado actual de la energía de todos los nodos de la red.

Basado en esta información, la estación base calcula primero el nivel de energía media de todos los nodos y, a continuación elige un conjunto de nodos, denotado S, cuyos niveles de energía están por encima del valor medio.

Las cabezas del clúster se elegirán del conjunto S, que asegura que sólo los nodos con suficiente energía quedan seleccionadas como jefes de racimo, mientras que aquellos con bajo consumo de energía puede prolongar su vida mediante la realización de tareas que requieren bajos costos de energía.

En BCDCP, se llevaron a cabo tareas o pruebas, por medio de un algoritmo iterativo.
Este algoritmo divide primero la red en dos sub-grupos, y procede más mediante el fraccionamiento de los sub-grupos en grupos más pequeños.

El algoritmo se asegura que los jefes de racimo seleccionados se colocan de manera uniforme en todo el campo de detección mediante la maximización de la distancia entre las cabezas de racimo en cada paso de la división.


3.- La fase de comunicación de datos

La fase de comunicación de datos consta de tres actividades principales:

  • La recolección de datos
  • Fusión de datos
  • Enrutamiento de datos

Utilizando el esquema de creación TDMA, cada nodo sensor transmite la información detectada a su cabeza de racimo.
Puesto que los nodos sensores están geográficamente agrupados, estas transmisiones consumen un mínimo de energía debido a pequeñas separaciones espaciales entre la cabeza y los nodos sensores.

Una vez que se han recibido los datos de todos los nodos de sensores, la cabeza de racimo realiza la fusión de datos en los datos recogidos, y reduce la cantidad de datos en bruto que necesita ser enviado a la estación base.


Los datos comprimidos, junto con la información requerida por la estación base para identificar correctamente y decodificar los datos del cluster, son entonces enviados de nuevo a la estación base a través de la ruta de enrutamiento.


Evaluación del Desempeño

Para evaluar el desempeño de BCDCP, se simulo el rendimiento usando Matlab y se comparó su desempeño con otros clustering basado en protocolos de enrutamiento.
El rendimiento se mide por indicadores cuantitativos de la disipación de energía promedio, la vida útil del sistema, los mensajes de datos totales entregadas con éxito, y el número de nodos que están vivos.

A lo largo de las simulaciones, se considero varias configuraciones de red al azar con 500 nodos en los que se asigna a cada nodo de una energía inicial.


Conclusión:


En este artículo se propone un protocolo centralizado clustering basado en BCDCP que utiliza la estación base de alta energía para realizar la mayoría de tareas de uso intensivo de energía.

Mediante el uso de la estación base, los nodos sensores se ven exentas de la realización de tareas de cálculo intensivo de energia tales como la configuración del clúster, la selección de cabeza de racimo, la formación de ruta de enrutamiento y TDMA creación horario.

El rendimiento del protocolo BCDCP se evalúa por simulación y comparación con otros protocolos basados ​​en la agrupación (Leach, Leach-C, y PEGASIS).

Los resultados de simulación muestran que BCDCP supera a sus comparativas mediante la colocación de las cabezas de racimo uniformemente a lo largo de todo el campo del sensor, la realización de agrupación equilibrada, y el uso de una-a-CH CH esquema de enrutamiento para transferir los datos fusionados a la estación base.

Por lo tanto, se concluye que BCDCP proporciona un esquema de enrutamiento energéticamente eficiente adecuado para una amplia gama de aplicaciones de detección.


Referencias: 


Referencia de documento:

lunes, 22 de abril de 2013

Resumen - Control de Congestión

Tema: Improving TCP Congestion Control over Internets with Heterogeneous
Transmission Media

Christina Parsa and J.J. Garcia-Luna-Aceves
Computer Engineering Department
Baskin School of Engineering
University of California

Introducción

La "Transmisión de extremo a extremo de los datos fiables" es un servicio muy necesario para muchas de las aplicaciones actuales se ejecutan a través de Internet (por ejemplo, WWW, transferencia de archivos, correo electrónico, acceso remoto), que hace que TCP sea un componente esencial de la actual Internet.

Los problemas de rendimiento de las implementaciones TCP actuales de Internet en los medios de transmisión heterogéneos se derivan de las limitaciones inherentes en la recuperación de errores y mecanismos de control de congestión que utilizan.

El efecto secundario desafortunado de este enfoque es que no hay estimaciones y se realizan en períodos de congestión.

Dado que todos los métodos Reno y Tahoe no pueden realizar estimaciones de RTT durante períodos de congestión, una estrategia es la de un temporizador de retardo de envío donde se utiliza para evitar las retransmisiones prematuros.

Reno y Tahoe implementan TCP y muchas soluciones alternativas proponen el uso de pérdida de paquete como una indicación primaria de la congestión; un emisor TCP aumenta su tamaño de la ventana, hasta que se produzcan pérdidas de paquetes a lo largo de la ruta de acceso al receptor TCP.

Por otra parte, la fluctuación periódica y amplia de tamaño de la ventana típica de Reno y Tahoe provoca grandes fluctuaciones de retraso, por lo que la variación del retardo en los extremos de la conexión genera un efecto secundario que es inaceptable para aplicaciones sensibles al retardo.

Bajo tales condiciones, el control de la congestión sobre la base de acuse de recibo (ACK) contando como en TCP, Reno y Tahoe resultados en subutilización significativa de la mayor capacidad de enlace hacia delante debido a la pérdida de ACK en el enlace inverso más lenta.

Las pérdidas ACK también conducen al tráfico de datos muy explosivas en el camino hacia adelante.
Por esta razón, se necesita un mejor algoritmo de control de congestión que es resistente a las pérdidas de ACK.

En este trabajo, proponen TCP Santa Cruz, que es una nueva implementación de implementable TCP.

TCP Santa Cruz detecta no sólo las etapas iniciales de la congestión, pero también puede identificar la dirección de la congestión, es decir, se determina si la congestión se está desarrollando en el camino hacia delante y después hacia adelante aísla el rendimiento de eventos tales como la congestión en el camino inverso.

La dirección de la congestión se determina calculando el retraso relativo de que un paquete de experiencias con respecto a otro; este retraso relativo es la base de nuestro algoritmo de control de congestión.

TCP Santa Cruz proporciona una estrategia de recuperación de errores mejor que Reno y Tahoe hacen al proporcionar un mecanismo para llevar a cabo estimaciones RTT para cada paquete transmitido, incluyendo retransmisiones.


1. TCP Santa Cruz - Descripción del protocolo

TCP Santa Cruz proporciona una mejora a través de TCP Reno en dos áreas principales: el control de la congestión y la recuperación de errores.

El algoritmo de control de congestión TCP introducida en Santa Cruz determina cuando existe congestión o está desarrollando en la ruta de datos hacia adelante - una condición que no puede ser detectada por una estimación del tiempo de ida y vuelta.

Este tipo de monitoreo permite la detección de los estados incipientes de congestión, lo que permite la ventana de congestión para aumentar o disminuir en respuesta a señales de alerta temprana.

Además, TCP Santa Cruz utiliza cálculos retardo relativo para aislar el rendimiento hacia adelante de cualquier congestión que pueda estar presente a lo largo de la ruta inversa.

Los métodos de recuperación de errores introducidos en TCP Santa Cruz realizan oportunas retransmisiones de paquetes perdidos, eliminar las retransmisiones innecesarias para los paquetes recibidos correctamente cuando se producen pérdidas múltiples dentro de una ventana de datos, y proporcionan estimaciones RTT durante períodos de congestión y de la distribución (es decir, eliminar la necesidad de algoritmo de Karn).


1.1. Control de la congestión

a) La eliminación de ambigüedad RTT utilizando retardos relativos

Mediciones de tiempo de ida y vuelta por sí solos no son suficientes para determinar si existe congestión a lo largo de la ruta de datos.

La figura 1 muestra un ejemplo de la ambigüedad que tienen lugar cuando se consideran únicamente las mediciones de RTT.

La congestión es indicada por una cola a lo largo de la trayectoria de transmisión.
El ejemplo muestra la transmisión de dos paquetes de datos y los ACKs que regresan desde el receptor.

La verdadera causa del aumento de RTT para el segundo paquete es la congestión a lo largo del camino de retorno, no la ruta de datos.

Nuestro protocolo resuelve esta ambigüedad mediante la introducción de la noción de la demora relativa.





Demora relativa es el aumento y disminución de la demora que los paquetes de experiencia con respecto a la otra cuando se propagan a través de la red.
Estas medidas son la base de nuestro algoritmo de control de congestión.


b) Algoritmo de control de congestión

En cualquier momento durante una conexión, las colas de la red (y específicamente la cola de cuello de botella) están en uno de tres estados: incrementan en tamaño, disminuyendo de tamaño, o el mantenimiento de su estado actual.

El diagrama de estados de la Figura 4 muestra cómo el cálculo del retardo relativo hacia adelante permite la determinación del cambio en el estado de la cola.

El objetivo en el TCP Santa Cruz es para permitir que las colas de la red (específicamente la cola de cuello de botella) para crecer a un tamaño deseado, el algoritmo específico para lograr este objetivo se describe a continuación.

Los valores de retardo relativos positivos y negativos representan cola adicional o menos en la red, respectivamente.

El algoritmo de control de congestión de TCP Santa Cruz opera mediante la suma de los retardos relativos desde el comienzo de una sesión, y a continuación, la actualización de las mediciones a intervalos discretos, con cada intervalo igual a la cantidad de tiempo para transmitir una ventana completa de datos y recibir los ACKs correspondientes .

En otras palabras, el algoritmo intenta mantener la condición siguiente:


Donde nti es el número total de paquetes en cola en el cuello de botella a la hora de ti, Nop es el punto de trabajo (el número deseado de paquetes, por sesión, para ser puesto en cola en el cuello de botella); MWi-1 es la cantidad adicional de hacer cola durante una presentación la ventana anterior Wi-1, y nt1 = MW0.

1.2. Recuperación de Errores

a) Mejora de la estimación de RTT

TCP Santa Cruz ofrece una mejor estimación de RTT sobre los enfoques tradicionales TCP midiendo el tiempo de ida y vuelta (RTT) de todos los segmentos de transmisión para el cual se recibe un ACK, incluyendo retransmisiones.

Esto elimina la necesidad de que el algoritmo de Karn (en el que no se hacen mediciones de RTT para las retransmisiones) y las estrategias de temporizador backoff (en la que el valor de tiempo de espera se duplicó prácticamente después de cada tiempo de espera y de la distribución).

Para lograr esto, TCP Santa Cruz requiere que cada paquete ACK de retorno para indicar el paquete exacto que causó el ACK que se generan y el remitente debe tener una marca de tiempo para cada paquete transmitido o retransmitido.

Los paquetes se pueden identificar de forma única por especificando un número de secuencia y un número de copias retransmisión.

b) Ventana ACK

Para ayudar en la identificación y la recuperación de paquetes perdidos, el receptor TCP en Santa Cruz devuelve una ventana ACK al remitente para indicar cualquier agujero en la corriente secuencial recibido.

En el caso de múltiples pérdidas por ventana, la ventana TCP ACK permite-SC para retransmitir todos los paquetes perdidos sin tener que esperar por un tiempo de espera de TCP.

La ventana ACK es similar a los vectores de bits utilizadas en los protocolos anteriores, tales como NETBLT y TCP-SACK.

A diferencia de TCP SACK, el enfoque de este documento proporciona un nuevo mecanismo por el que el receptor es capaz de informar sobre el estado de todos los paquetes en la transmisión actual.

La ventana ACK se mantiene como un vector en el que cada bit representa la recepción de un número especificado de bytes más allá de la ACK acumulativo.
El receptor determina una granularidad óptima para los bits en el vector e indica este valor al remitente a través de un campo de un byte en la cabecera.

Esto ayuda a evitar la retransmisión innecesaria de paquetes recibidos correctamente después de un tiempo de espera cuando la sesión entra en arranque lento.

c) Política de retransmisión

La estrategia de retransmisión es motivada por pruebas como los informes de seguimiento de Internet por Lin y Kung, que muestran que el 85% de los tiempos de espera de TCP se debe a la "no-disparo".

"No-disparo" se produce cuando un paquete es retransmitido por el remitente sin intentos anteriores, es decir, cuando tres ACKs duplicados no llegan a la remitente y por lo tanto mecanismo de retransmisión rápida de TCP nunca ocurre.

En este caso, no hay retransmisiones pueden ocurrir hasta que hay un tiempo de espera en la fuente.

Por lo tanto, se necesita un mecanismo para recuperar rápidamente las pérdidas sin que sea necesario esperar tres ACKs duplicados desde el receptor.

Dado que TCP Santa Cruz cuenta con un presupuesto mucho más ajustado del tiempo RTT por paquete y que el TCP Santa Cruz remitente recibe información precisa sobre cada paquete recibido correctamente (a través de la ventana ACK), TCP Santa Cruz puede determinar cuando un paquete se ha caído sin esperando algoritmo de retransmisión rápida del TCP.

TCP Santa Cruz puede retransmitir y recuperar rápidamente un paquete perdido una vez que cualquier ACK sea transmitido posteriormente y sea cumpla una restricción de tiempo.

1.3 Implementación propuesta

TCP Santa Cruz se puede implementar como una opción de TCP que contiene los campos representados en la Tabla 1.

La opción TCP Santa Cruz puede variar en tamaño de 11 a 40 bytes,

2. Resultados de rendimiento

Se muestran los resultados de rendimiento para una configuración básica con una sola fuente y un enlace cuello de botella, y luego una sola fuente de tráfico cruzado en el camino de retorno, y, finalmente, el rendimiento a través de enlaces asimétricos.

Se midio el rendimiento de TCP Santa Cruz a través de simulaciones que utilizan la red "ns" simulador
El simulador contiene implementaciones de TCP Reno y TCP Vegas.

TCP Santa Cruz se llevó a cabo mediante la modificación del código fuente TCP Reno existente para incluir los nuevos regímenes de recuperación de errores y evitar la congestión.

2.1 Con guración Básica Cuello de botella

Nuestro primer experimento muestra el rendimiento del protocolo en una red simple, representado en la Figura 7, que consiste en una fuente TCP enviando paquetes de datos 1 Kbyte a un receptor a través de dos enrutadores intermedios conectados por un enlace de cuello de botella de 1,5 Mbps.

El BWDP de esta configuración es igual a 16.3Kbytes, por lo tanto, con el fin de acomodar una ventana completa de los datos, los routers se establecen para mantener los paquetes 17.

Las figuras 8 (a) y (b) muestran el crecimiento de ventana de congestión de TCP Reno y la acumulación de cola en el enlace de cuello de botella.

Los routers empiezan a caer los paquetes una vez que la cola está llena, con el tiempo Reno da cuenta de la pérdida, retransmisiones y reduce la ventana de congestión a la mitad.
Esto produce oscilaciones sube y baja, tanto en el tamaño de la ventana y de la longitud de la cola cuello de botella.

En contraste, las Figuras 9 (a) y (b) muestran la evolución de la ventana de congestión del remitente y la acumulación de cola en el cuello de botella para TCP Santa Cruz.

Estas cifras demuestran la fortaleza principal de TCP Santa Cruz: la adaptación del algoritmo de control de congestión para transmitir en el ancho de banda de la conexión sin congestionar la red y sin desbordamiento de las colas de cuello de botella.

La Figura 9 (b) muestra la longitud de la cola en el enlace de cuello de botella para TCP Santa Cruz alcanza un valor de estado estacionario entre 1 y 2 paquetes.

El algoritmo mantiene este valor de estado estacionario durante la duración de la conexión.

Conclusión

Se presento TCP Santa Cruz, que implementa un nuevo enfoque para el control de congestión de extremo a extremo y fiabilidad, y que puede ser implementado como una opción TCP.

TCP Santa Cruz hace uso de una marca de tiempo sencilla devuelto desde el receptor para estimar el nivel de formación de colas en el enlace de cuello de botella de una conexión.

El protocolo aísla con éxito el rendimiento hacia adelante de la conexión de eventos en el enlace inverso teniendo en cuenta los cambios en el retardo a lo largo de sólo el enlace directo.

El protocolo proporciona rápida y eficiente de recuperación de errores mediante la identificación de las pérdidas a través de una ventana ACK sin esperar tres ACKs duplicados.

Una estimación del RTT para cada paquete transmitido permite que el protocolo para recuperarse de retransmisiones perdidos sin el uso de estrategias de temporizador-backoff, eliminando la necesidad de algoritmo de Karn.

Los resultados de simulación muestran que TCP Santa Cruz proporciona un alto rendimiento y bajo retardo de extremo a extremo y la varianza del retardo a través de redes con un simple enlace cuello de botella, las redes con la congestión en el camino de retorno de la conexión, y redes que exhiben camino
asimetría.

Hemos demostrado que el TCP Santa Cruz elimina las oscilaciones en la ventana de congestión, pero todavía mantiene una alta utilización de enlace.

Referencias


[1] H. Balakrishnan, S. Seshan, and R. Katz. Improving reliable transport and handoff performance in cellular wireless networks. ACM Wireless Networks, Dec. 1995.

[2] L. Brakmo, S. O’Malley, and L. Peterson. TCP Vegas: New techniques for congestion detection and avoidance. In Proc. SIGCOMM’94, pages –, London, UK, Aug./Sept. 1994. ACM.

[3] L. Brakmo and L. Peterson. TCP Vegas: End-to-end congestion avoidance on a global internet. In IEEE Journal of Selected Areas in Communication, October, 1995.

[4] D. Clark, M. Lambert, and L. Zhang. NETBLT: A high throughput transfer protocol. In Proc. SIGCOMM, pages 353–59, Stowe, Vermont, Aug. 1987. ACM.

[5] K. Fall and S. Floyd. Simulation-based comparisons of tahoe,reno, and SACK TCP. In Computer Communication Review, volume 26 No. 3, pages 5 – 21, July, 1996.

[6] S. Floyd and V. Jacobson. Random Early Detection gateways for congestion avoidance. IEEE/ACM Transactions on Networking, 4(1):397–413, Aug 1993.

[7] R. Jacobson, R. Braden, and D. Borman. Rfc 1323 TCP extensions for high performance. Technical report, May 1992. Technical Report 1323.

[8] V. Jacobson and S. Floyd. TCP and explicit congestion notification. In Computer Communication Review, volume 24 No. 5, pages 8 – 23, October, 1994.

[9] P. Karn and C. Partridge. Improving round-trip time estimates in reliable transport protocols. In Computer Communication Review, volume 17 No. 5, pages 2 – 7, August 1987.

[10] S. Keshav. Packet-pair flow control. http://www.cs.cornell.edu/skeshav/papers.html.

[11] T. Lakshman, U. Madhow, and B. Suter. Window-based error recovery and flow control with a slow acknowledgement channel: a study of TCP/IP performance. In Proceedings IEEE INFOCOM ’97, number 3, pages 1199–209, Apr 1997.

[12] D. Lin and H. Kung. TCP fast recovery strategies: Analysis and improvements. In Proceedings IEEE INFOCOM ’98, Apr. 1998.

[13] L.Kalampoukas, A. Varma, and K. Ramakrishnan. Explicit window adaptation: a method to enhance TCP performance. In Proceedings IEEE INFOCOM ’98, pages 242 – 251, Apr. 1998.

[14] M. Mathis and J. Mahdavi. Forward acknowledgment: Refining TCP congestion control. In Proc. SIGCOMM’96, pages 1–11, Stanford, California, Sept. 1996.

[15] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP selective acknowledgment options. Technical report, Oct. 1996. RFC 2018.

[16] S. McCanne and S. Floyd. ns-lbnl network simulator. http://wwwnrg.ee.lbl.gov/ns/.

[17] C. Parsa and J. Garcia-Luna-Aceves. Improving TCP performance over wireless networks at the link layer. ACM Mobile Networks and Applications Journal, 1999. to appear.

[18] N. Samaraweera and G. Fairhurst. Explicit loss indication and accurate RTO estimation for TCP error recovery using satellite links. In IEE Proceedings - Communications, volume 144 No. 1, pages 47 – 53, Feb., 1997.

[19] W. R. Stevens. TCP/IP Illustrated, Volume 1. Addison-Wesley, 1996.

[20] J. Waldby, U. Madhow, and T. Lakshman. Total acknowledgements: a robust feedback mechanism for end-to-end congestion control. In Sigmetrics ’98 Performance Evaluation Review, volume 26, 1998.

[21] Z. Wang and J. Crowcroft. Eliminating periodic packet losses in the 4.3-Tahoe BSD TCP congestion control algorithm. In Computer Communication Review, volume 22 No. 2, pages 9 – 16, April, 1992.

[22] Z. Wang and J. Crowcroft. A new congestion control scheme: Slow start and search (Tri-S). In Computer Communication Review, volume 21 No. 1, pages 32 – 43, Jan., 1991.


Referencias de documento