Mostrando entradas con la etiqueta Laboratorio Redes de Telecomunicaciones. Mostrar todas las entradas
Mostrando entradas con la etiqueta Laboratorio Redes de Telecomunicaciones. Mostrar todas las entradas

domingo, 19 de mayo de 2013

[Lab RT] Actividad 12: Redes Ad-hoc

Para ésta semana continuamos con los temas de lecturas científicas, ahora el tema es referente a técnicas de usabilidad en sistemas de cómputo ubicuo, el documento seleccionado fue:

 ... 
MANET POSSIBLE APPLICATIONS WITH PDA IN WIRELESS IMAGING ENVIRONMENT

 El paper aparece en: IEEE International Symposium on Personal, Indoor and Mobile Radio Communications
 Tipo de producto: Conferencia
Fecha de publicación: 2002 
Autores: M. Guarnera, M. Villari, A. Zaiaz, A. Puliafito
... 

Resumen

El paper ya tiene un poco de tiempo, menciona que los sistemas de comunicación inalámbrica se están convirtiendo en una tecnología que permite acceder, compartir y procesar datos. Los futuros usuarios tendrán acceso a internet inalámbrico a través de dispositivos tipo PDA. Las redes ad-hoc móviles o MANET son parecidas a las redes inalámbricas pero que no dependen de la presencia de una infraestructura por cable. Se identifican algunos de los posibles campos de aplicación de tales sistemas inalámbricos, analizando sus ventajas y desventajas.


Introducción

Gracias a los últimos avances tecnológicos, los dispositivos móviles están disponibles para cualquier usuario, su  potencia computacional es casi comparable con la de algunas computadoras de escritorio. Esto ha llevado a la creación de un nuevo tipo de mercado donde se ofrecen dichos dispositivos para desarrollar nuevos y sofisticados servicios con el fin de acceder a los datos en cualquier lugar y en cualquier momento. Los PDA aprovechan dichos servicios, y suelen almacenar información confidencial. Actualmente los dispositivos móviles se adaptan a cualquier situación  y las redes ad hoc permiten seguir esta dirección, ya que se pueden crear con cualquier dispositivo compatible y en cualquier tipo de ambiente ya que no necesitan ninguna infraestructura.
Los campos de aplicación de estas redes puede ser:


  • Militar: es decir, es posible equipar soldados con dispositivos en entornos enemigos para que puedan comunicarse entre sí.
  • Red de área personal, es decir, impresoras, PDA, teléfonos móviles, aplicaciónes de negocios.
  • Aplicaciones civiles, es decir, taxis, coches, aplicaciones de emergencia, dispositivos de emergencia.
  • Dispositivos de inteligencia en el hogar.


Una gran cantidad de desafíos se interponen en el desarrollo de esta tecnología inalámbrica como un ancho de banda, la falta de estándar global, el mercado, etc.
A pesar de ello, una gran cantidad de oportunidades se dan.

En el paper se demuestra cómo MANET persegue el objetivo de comunicarse en cualquier momento y en todas partes al pasar de un lugar a otro. Se presentan algunas aplicaciones posibles que pueden ser desarrolladas en un entorno MANET y se analiza un prototipo de  cómo crear un sistema de procesamiento de imágenes a distancia mediante un servicio corriendo en una red ad-hoc.


Red Ad hoc


Son ​​redes inalámbricas que se han caracterizado por la correr en ausencia de una infraestructura fija. El uso de este tipo de redes se hace en circunstancias especiales, tales como eventos desastrosos, la reducción o eliminación del cableado y el intercambio de información entre los usuarios independientemente del medio ambiente.


Los dispositivos que pertenecen a la red son capaces no sólo para transmitir y recibir datos, sino también para gestionar todas las funciones de la red en un entorno distribuido, así como implementar métodos de enrutamiento de paquetes, seguridad, QoS, etc. Los dispositivos no son sólo terminales, se trata de nodos que tienen una interfaz inalámbrica, y son por lo general sistemas móviles de varios tipos, desde los sencillos como PDA hasta computadoras portátiles. Estas redes se caracterizan por tener un ancho de banda limitado con capacidad variable, son topologías que varían en el tiempo dependiendo no solo de la posición de los nodos, sino también en función de la terminales, ya que pueden entrar y salir de la red en cualquier momento, sin embargo la conectividad de la red debe mantenerse a fin que las aplicaciones y los servicios funcionan correctamente.

La desventaja es que cuentan con una cantidad limitada cantidad de memoria y energía, la cual generalmente depende de la potencia de una batería.
La comunicación entre los nodos se puede hacer a través de caminos multi-hop. Por otra parte, para la inserción de un nodo a la red se necesita que toda la configuración necesaria sea automática.

Las topologías de red pueden ser variadas, se basan en las aplicaciones a las que se destinan las redes. Para construir redes ad hoc, es posible usar dos tecnologías: IEEE 802.11 y Bluetooth.
El estándar IEEE 802.11 representa una buena plataforma para implementar redes ad hoc, ya que es muy simple. Bluetooth representa realmente una red de área personal (WPAN) y permite la conexión de dispositivos dentro de radio de diez metros.


Aplicaciones


Se propone un sistema de adquisición de imágenes. Para ello se requiere de una cámara digital con un cable de interfaz de red, una webcam inalámbrica, el PDA va conectado a una cámara fotográfica digital, algunos teléfonos móviles y PDAs equipados con una cámara. Todos estos dispositivos se conectan con el fin de crear una red ad hoc.


a) Transferencia de archivos:
Podría se útil tener la posibilidad de descargar las imágenes adquiridas por otros dispositivos en forma de thumbnails para su pre-visualización. Para ello, es necesario establecer una conexión inicial e intercambiar información tal como las capacidades de vídeo, tipo de imágenes para descargar, tipo de pantalla en los dispositivos, la cantidad de colores en las pantallas, etc. De esta manera se es posible codificar las mismas para que sean compatibles con el máximo número de dispositivos.}

b) Mando a distancia
Podría ser útil tener la capacidad de controlar el dispositivo a distancia. Con ello sería posible tomar una foto con otros dispositivos y utilizar las herramientas de edición de imagenes individualmente, tales como el balance de blancos, el formato, dimensiones y calidad.

c) Visualización a distancia
Si algunos dispositivos conectados no cuentan con una pantalla para ver las fotos recien tomadas, a través de la pantalla de otro dispositivo sería posible ver la foto tal y como se tomó. Podría ser útil seleccionar uno de los dispositivos conectados y convertirlo en un visor. El servicio podría ser gestionado por un solo dispositivo y éste decide qué dispositivo de la red va a ver la fotografía.
El servicio tiene que tener en cuenta las características de la red en términos de la banda disponible. El paper menciona un ejemplo:
Una imágen con resolución VGA (640x480), no se puede transmitir como una secuencia VGA por una red 802.11, para transmitirla se requiere una velocidad de 15 fps, y un ancho de banda de 40Mbps.
Por lo tanto, en primer lugar, tenemos que escalar cada frame a resolución QSIF (160x120) o QCIF (176x144). Por otra parte, las imágenes a escala no pueden ser de color, ya que en este caso
tenemos tres veces la cantidad de datos del sensor. La solución podría estar en comprimir los datos con un algoritmo simple, como IGS, y luego transferir la trama codificada por la conexión inalámbrica.
Todo ello para ahorrar un 83% del ancho de banda.

d) Videoconferencias
Se espera que la configuración de la red permita que nuevos usuarios se unan al servicio y desconectar en cualquier momento. Los mecanismos de seguridad deben ser implementados a nivel de aplicación para evitar que usuarios no deseados se unan a las videoconferencias.

e) Procesamiento remoto
Podría ser útil utilizar los demás dispositivos como co-procesadores de color a partir de los datos en bruto del sensor. Obtener la imagen de un dispositivo a distancia y realizar a distancia el proceso de color.


Procesamiento de imágenes en un entorno MANET

Para el prototipo presentado en paper se utilizan algunos dispositivos PDAs inalámbricos y una LCDC (Low Cost Digital Camera) como dispositivo de adquisición de imágenes. Los dispositivos interconectados entre sí emulan cámara fotográfica digital. La conexión se realiza con un RS232 a 15Kbps. El entorno de la aplicación consiste en dos tipos de aplicaciones: un emulador en las PDAs y otro emulador de DSC. El software es capaz de determinar el número de dispositivos HLE (que han cargado el software de gestión de imágenes adecuado) y  decidir a quién enviar las imágenes adquiridas.

A través de la aplicación gráfica que se ejecuta en los PDA, es posible conocer en todo momento y en cualquier lugar, el número de dispositivos de adquisición de vídeo que están conectados a la red. Y es posible controlar alguno a distancia.

Los resultados de las pruebas realizadas han establecido un alcance máximo de red de 50 metros. 

Para mejorar el rendimiento del sistema diseñado es necesario adoptar el sistema operativo Embedded Linux ya que permite mantener toda funcionalidad descrita anteriormente y permite utilizar protocolos y arquitecturas oficiales y no oficiales para comunicación inalámbrica. Además utilizar una herramienta desarrollada por el MIT que ofrece enrutamiento, descubrimiento y mecanismos de localización geográfica. 


Conclusión
Las redes ad-hoc (MANET) pueden correr bastantes tipos de aplicaciones y sistemas inalámbricos de comunicación personal. A pesar de que se han pensado originalmente para fines militares y situaciones de emergencia, las MANET son aptas para acceder a información multimedia en diversos dispositivos. El paper ya es algo viejo, actualmente se tienen mejores métodos, más rápidos y confiables para la compartición de contenido multimedia, tal es el caso del protocolo DLNA, sin embargo, me parece una buena aproximación para la implementación de éste tipo de redes, posiblemente no es la primera investigación de este tipo pero es una buena aproximación.


Referencias


M. Guarnera, M. Villari, A. Zaiaz, A. Puliafito, 2002, MANET Possible applications with PDA in wireless imaging environment, publicado en "IEEE International Symposium on Personal, Indoor and Mobile Radio Communications" [conferencia], recuperado el 18 de mayo de 2013 desde http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1046573

martes, 14 de mayo de 2013

[Lab RT] Actividad 11: Satélites

La comunicación satelital es un tipo de radiocomunicación que sirve para transmitir diferentes tipos de señales, ya sean de audio, voz o datos, mediante el uso de algún sistema de satélites.
Un satélite artificial es un dispositivo estacionado en el espacio con el propósito de servir a telecomunicaciones usando frecuencias de radio y microondas.

Fuente de la imágen: http://concurso.cnice.mec.es/cnice2006/material121/unidad3/satelite2.htm


Los satélites orbitan la tierra a diferentes niveles según el uso que se les vaya a dar:

  • Órbitas bajas: Son satélites que se sitúan entre unos 500 a 2000 km sobre la superficie terrestre. En éste tipo de órbitas los satélites viajan a grandes velocidades y pueden dar la vuelta a la tierra en menos de 2 horas. Dado la altura a la que se encuentran, un sistema satélital en ésta orbita necesita una gran cantidad de dispositivos para cubrir grandes extensiones.
  • Órbitas medias: Su altura oscila entre los 8000 a 20000 km sobre la superficie terrestre. A ésta altura se necesitan 3 o 4 satélites para tener una cobertura global.
  • Órbitas geoestacionarias: Su altura se encuentra exactamente a los 35786 km, y se encuentran directamente sobre el Ecuador. Orbitan en sincronía con la Tierra por lo que tienen un periodo de 24 horas. A ésta altura cada satélite es capaz de cubrir un tercio del planeta.
  • Órbitas altas: Por su altura describen una órbita muy elíptica  en el perigeo se encuentran a unos 500 km de altura y en el apogeo a unos 50000 km. Su periodo oscila entre las 8 y 24 horas.

Fuente de la imágen: http://radiomen.tripod.com/satelites.htm 


Además existen dos tipos de satélites de comunicaciones

  • Satélites pasivos: Se encargan de reflejar las señales recibidas sin llevar a cabo ninguna otra tarea.
  • Satélites activos: Amplifican las señales que reciben antes de retransmitirlas hacia la Tierra. Son las más comunes.
Los satélites básicamente se encargan de transmitir señales a grandes distancias, incluso a lugares muy remotos e inaccesibles del planeta de forma rápida y barata; así por ejemplo es posible proveer servicios de televisión, radio, telefonía e internet en zonas rurales, boscosas o desérticas, o en lugares donde los sistemas cableados no son viables o difíciles de instalar.

Aplicaciones de las comunicaciones satelitales


Existen diferentes usos para las comunicaciones satelitales, entre ellos se encuentran:

1. Telecomunicaciones

Televisión y radio

Posiblemente es la principal aplicación de los satélites de comunicaciones es la transmisión de contenidos de televisión o radio.
Las empresas de televisión y de radio transmiten desde sus estaciones terrestres a los satélites los cuales las retransmiten a diferentes zonas sobre la Tierra o directamente al domicilio del usuario.
Un único satélite puede dar servicio a varias cadenas de televisión en un país e incluso a todo un continente. La digitalización de la transmisión de las señales ha elevado enormemente el potencial de los satélites en términos de cantidad de cadenas, lo que ha abierto la puerta a nuevos servicios vía satélite. Las emisiones las pueden recibir tanto los usuarios privados como los públicos mediante claves que dan acceso a la conexión satélite. En la actualidad, gracias a los satélites, todos los hogares poseen acceso a las mismas cadenas, tanto si son de calidad estándar o de alta definición.
Los sistemas que hacen uso de ésta tecnología se conocen con el nombre de DBS (Direct Broadcast Satellite) y en ésta clasificación encontramos a las constelaciones de satélites HotBird, Astra y SatMex.

Telefonía satelital

Gracias a las comunicaciones satelitales es posible contar con un pequeño dispositivo móvil que permite estar comunicado en tiempo real en cualquier parte del planeta.

Éste tipo de dispositivos hace posible contar con un sistema de comunicación en áreas muy remotas del planeta.
Las constelaciones de satélites Sirius, Inmarsat y XM Satellite Radio Holdings ofrecen este tipo de servicios.

Internet de banda ancha

Este tipo de satélites hacen posible proporcionar el beneficio del internet a lugares lejanos del planeta.
En años recientes se han desarrollado satélites que permiten alcanzar tasas de transferencia de hasta 70 Gbps, lo cual permite un acceso a internet en tiempo real, de super alta velocidad y de alta capacidad de usuarios.
En ésta clasificación encontramos a los satélites Hylas y Ka-Sat.

Comunicaciones de alta seguridad

Son utilizados principalmente por agencias militares.Las comunicaciones militares consisten en enlaces protegidos con una gran flexibilidad de cobertura.

Independientemente del ambiente hostil y de la situación, las comunicaciones deben estar garantizadas y aseguradas por lo que los requerimientos de las agencias militares son muy especificos en comparación con otras redes terrestres. Además necesitam mayor flexibilidad en cuanto a cobertura, potencia, frecuencias, ancho de banda, etcétera.
En esta clasificación encontramos a la constelacion Skynet.


2. Navegación 

Se tratan de satélites geoestacionarios que sirven para proporcionar información sobre la ubicación, velocidad y tiempo a personas que cuenten con el equipo necesario sobre la tierra.

Éste tipo de satélites cuentan con una excelente precisión y proporcionan la ubicación exacta de un individuo o dispositivo que se encuentre en la superficie del planeta.
Actualmente existen dos constelaciones de satélites que proporcionan éste servicio, la constelación GPS (Global Positioning System) y GLONASS, más la constelación GALILEO que está en construcción por la Unión Europea.
La navegación por satélite hace uso de un concepto llamado trilateración para ubicar un objeto en tiempo real sobre la tierra.


3. Clima

Sirven para monitorear los cambios en la atmósfera terrestre y analizar su composición a lo largo de los años.
Fue entre 1970 y 1980 cuando se comenzarón a utilizar éste tipo de satélites lanzados en una gran variedad de misiones espaciales.
Dichos satélites cuentan con diferentes tipos de instrumentos que les permiten medir la humedad y estimar la velocidad del viento, también realizan mediciones de la radiación infraroja y ultravioleta que llega al planeta .
En ésta clasificación entran las constelaciones satelitales GOES y METEOSAT


4. Cartografía y observación planetaria

Son necesarios para llevar un control sobre las condiciones ambientales en distintos puntos del planeta. Su objetivo es medir la calidad del medio ambiente. Se utilizan para medir y monitorear los recursos naturales del planeta mediante la recolección de datos que permiten entender los diferentes procesos e interacciones entre las masas de tierra, los océanos y la atmósfera. La información recolectada es de mucha utilidad para la agricultura, geología, cartografia, defensa del medio ambiente, entre otras.

Profundizando un poco en la cartografía,  los satélites han permitido mejorar de una manera impresionante la precisión de los mapas y a su vez ha permitido disminuir los precios.
En éste aspecto los satélites han permitido crear todo tipo de mapas, desde medir las elevaciones de las montañas, contabilizar y ubicar rios, mejorar los mapas carreteros y de las ciudades, y muchas aplicaciones mas.


Mecanismos para interceptar las comunicaciones satelitales.

Los riesgos al interceptar una transmisión satelital son muchos y puede comprometer la seguridad de una nación. La preocupación reside en que al interceptarse una señal se puede hacer mal uso del enlace y de la información recolectada.

Mecanismo de acción preventiva y ofensiva

La acción preventiva consiste en colocar obstáculos para que un mensaje no pueda continuar a su destino. Típicamente, estas medidas sólo se emplean durante los tiempos de hostilidades abiertas y con la intención de eliminar los recursos de los enemigos. Un método para llevar a cabo este fin es bloqueo de la señal vía satélite utilizando interferencia, ésto implica la transmisión señal modulada a la terminal de recepción de un objetivo en la misma frecuencia de la señal de los remitentes. Las llamadas "inundaciones" consisten en desbordar el receptor con una señal de ruido y la prevención de la interpretación de cualquier señal original. Esto puede ser combatido utilizando señales moduladas y secuenciadas, y es un medio eficaz para prevenir que cualquier señal sea recibida. 
Otro método utilizado es la acción ofensiva abierta. Con el fin de evitar cualquier intercambio de comunicaciones, una fuerza hostil podría destruir una estación en tierra o un satélite fundamental para una operación.

Mal uso de las señales

Éste mecanismo suele ser pasivo e indetectable. Muchas veces consiste en robar los códigos de acceso a las constelaciones satelitales para tener acceso "oficial" a las transmisiones y con ello la mayoria de las veces obtener el control de una estación transmisora y los satelites.
Otro método más simple es interceptar las señales en tierra, lo que es muy simple si se sabe donde la posición de la transmisión y el tiempo. Para ello se necesita una estación modificada en tierra que permite escuchar las transmisiones.

Existe un caso llamado "Privateer" que consiste en la "piratear" las comunicaciones satelitales utilizando objetos comunes.
Los componentes fueron, como en todo sistema satelital, un receptor y un decodificador. El equipo completo contenía una antena, un preamplificador, un radio-escaner. Todos estos componentes se consiguen fácilmente hoy en día. Diversos dibujos y esquemas fueron encontrados en internet mediante los cuales fue posible ensamblar todo y construir los componentes faltantes, la mayoria con materiales como PVC, tubos de cobre, etcétera. Por último, se consiguio un programa freeware en internet el cual se instaló en el decodificador el cual era una copia 100% operable que servía para decodificar las señales de la constelación NOAA (satélites meteorológicos). Todos los componentes se conectaron a una computadora de bajo rendimiento, el cual pudo traducir en imágenes de mapa bits los datos recolectados por el receptor.
Éste caso demostro lo sencillo que es interceptar las señales con componentes simples que toda la gente tiene a su alcance.


Mecanismos para la protección de las señales satelitales


En las épocas tempranas de las telecomunicaciones, los mecanismos de protección de las señales satelitales consistían en eludir las amenazas temporalmente, sin embargo esto resulto insuficiente con el paso del tiempo. Ahora existen 4 mecanismos, cada uno con sus deficiencias, para proteger las comunicaciones satelitales contra ataques:

  • Evasión: Consiste en la capacidad de las naves espaciales para modificar su curso para evitar cualquier interrupción en su funcionamiento. Por lo general, el curso de un satélite es predecible, pues es definido desde la planeación de la misión. Esto aumenta la vulnerabilidad de los satélites. Existen problemas en este mecanismo, ya que un satélite puede quedar inoperable. Es necesario implementar sistemas de computo capaces de operar aun cuando la comunicación con las estaciones terrestres esté perdida y así poder volver a rectificar su rumbo y volver a operar correctamente. Además, los sistemas de propulsión están diseñados para un cierto ciclo de vuelo, utilizar el combustible en éste tipo de eventos puede reducir el tiempo útil del satélite al agotar sus reservas más rápidamente.
  • Preparación táctica: Consiste en preparar al satélite para que sea capaz de protegerse contra ataques, que pueden ir desde dispositivos de escucha y transmisión pasiva hasta armas montadas en el cuerpo del satélite (dependiendo de su aplicación).
  • Alteración del haz de comunicaciones: Posiblemente el método más simple para evitar los ataques a las telecomunicaciones. Consiste en minimizar el espacio de cobertura de tal forma que no de lugar a la interceptación  de las señales satelitales. Por lo general se logra concentrando la señal en un haz que solo es posible escuchar en un ancho muy reducido y que por lo general es dirigido directamente a las antenas receptoras oficiales. El método requiere una sincronización perfecta entre el satélite y la estación receptora, así como una gran potencia de transmisión basada en rayos láser que permite dirigir el haz de comunicaciones de forma muy precisa.
  • Cifrado: Posiblemente el método más empleado en las telecomunicaciones. No es necesario afectar de forma física ninguno de los dispositivos terrestres, ni el transmisor ni la antena. Consiste simplemente en cifrar los datos mediante cualquier método y descifrarlos en las estaciones destino. El principal problema es que las capacidades computacionales actuales permiten romper los mecanismos de cifrado en cuestión de segundos.

Conclusiones

Debido a la masificación de las telecomunicaciones y a la variedad de servicios prestados a través de las mismas, algunos bastante comunes y otros bastante delicados, es necesario proteger las comunicaciones satelites contra ataques de cualquier tipo.
Ya sea para proteger los intereses monetarios de una empresa de televisión de paga o la seguridad de una nación, las señales satelitales cuentan con distintos mecanismos que aseguran las telecomunicaciones de cierta forma, sin embargo, aún asi es posible que con materiales bastante comunes se puedan interceptar las señales de un satélite y con las capacidades computacionales actuales descifrar los datos transmitidos a través de ellas.
Cabe mencionar que los métodos para vulnerar las telecomunicaciones satélites están penados en todo el mundo y se clasifican delitos federales, por lo que hay que tener mucho cuidado al intentar implementarlos, fue complicado encontrar un documento que hablara abiertamente del tema y parece que hasta con una simple búsqueda en internet ya me han clasificado como un posible terrorista (de no ser porque estoy en México).



Referencias

martes, 30 de abril de 2013

[Lab RT] Actividad 9: Ahorro de energía (Lectura)



Para ésta semana continuamos con los temas de lecturas científicas, ahora el tema es referente a ahorro de energía, el documento seleccionado fue:

...


An Energy-Efficient MAC Protocol with Random
Listen-Sleep Schedule for Wireless Sensor Networks

Sung-Chan Choi∗ , Jang-Won Lee∗ , Yeonsoo Kim† , Hakjin Chong†
∗ Dept. of Electrical and Electronic Engineering, Yonsei University, Seoul, Korea
† Future Technology Laboratory, KT, Seoul, Korea

...

Resumen

En el paper, se prope un protocolo MAC que hace uso eficiente de la energía para redes de sensores inalámbricos. Puesto que los nodos sensores utilizan energía de una batería, reducir el consumo de energía es un tema crítico para prolongar la vida útil de la red.
Para resolver este problema, se utiliza un ciclo de escucha-espera conocido como S-MAC, lo que permite a los nodos apagar su transceptor durante un período de espera. En S-MAC, los nodos sensores tienen un ciclo fijo de actividad y un calendario sincronizado en un clúster virtual. Por lo tanto, en la S-MAC, no es fácil adaptar una variación del entorno de red. Por otra parte, debido a la programación sincronizada, las colisiones de transmisión aumentarán resultando en el desperdicio de energía y de bajo rendimiento. Para hacer frente a tales ineficiencias en S-MAC, se propone un sensor de probabilidad MAC (PS-MAC), en el que cada nodo determina su estado, "escuchar" o "sueño", basado pseudo-aleatoriamente en su propia probabilidad de activación previa y las probabilidades de pre-wakeup de su nodos vecinos en cada intervalo de tiempo. Esto permite que el programa de escucha-dormir mantega cada par transmisor-receptor sincronizado mientras que el del resto de los nodos puede ser asincrónico. Por lo tanto, las colisiones pueden reducirse incluso bajo condiciones de tráfico pesado que resultan en la reducción de desperdicio de energía y el logro de un alto rendimiento. Además, ya que la probabilidad de pre-activación de cada nodo se puede ajustar la adaptación al cambio del entorno de red, mediante el ajuste de forma dinámica probabilidades pre-wakeup de nodos de sensores, el rendimiento del sistema puede ser mejorado aún más.


Introducción


Las redes de sensores inalámbricos tienen diversas aplicaciones, tales como el monitoreo del clima, animales o plantas, el seguimiento de objetivos en campo de batalla, y los edificios o infraestructuras de observación para la defensa. En general, los nodos sensores se hacen funcionar con una pequeña
batería que tiene una cantidad limitada de energía y que no puede ser fácilmente recargada o reemplazada. Por lo tanto, en el sensor inalámbrico redes, reducir el consumo de energía de cada nodo sensor es una de las cuestiones importantes para prolongar la vida de la red.
En un nodo sensor, el consumo de energía se produce en el transceptor cuya utilización está controlada un protocolo de control (MAC).

En la capa MAC, hay varias fuentes principales de desperdicio de energía. La primera de ellas es la escucha ociosa, lo que ocurre cuando un nodo se convierte en el receptor a pesar de que no hay datos para transmitir o recibir. Se ha estudiado que el consumo de energía durante el estado inactivo de escucha es comparable al consumo durante el estado de recepción. La segunda
uno está oyendo, que se produce cuando un nodo recibe y decodifica los paquetes que no estén destinados a la misma. El tercero es una overemitting, que se produce cuando el nodo transmisor transmite un paquete, mientras que el nodo receptor no está preparado para recibir. la última fuente importante de desperdicio de energía es de colisión, que se produce cuando hay transmisiones simultáneas de varios nodos que están dentro del alcance de la interferencia del nodo receptor. 

Para reducir los desperdicios de energía, se propondrán algunos protocolos MAC para redes de sensores inalámbricos.
Estos protocolos se pueden clasificar como:
  • Los protocolos basados en programación suelen utilizar protocolos TDMA, en el que cada nodo sensor  se le asigna uno de los intervalos de tiempo y se puede comunicar sólo en  el intervalo de tiempo asignado. Protocolos basados ​​en TDMA son libres de contención, y por lo tanto, no hay desperdicio de energía causada por  colisiones. Sin embargo, generalmente no es fácil diseñar un sencillo  algoritmo para la asignación de ranura de tiempo, debido a un gran número de nodos sensores y la falta de la unidad central. Además, se requiere sincronización de tiempo elaborada para corregir temporización error causado por la deriva del reloj.
  • Los protocolos basados ​​en contención no son libres de colisiones. Sin embargo, debido a su simplicidad y escalabilidad, se prefieren en la práctica. Hasta el momento, muchos de estos protocolos tienen como objetivo reducir el consumo de energía. S-MAC es uno de los protocolos MAC mejor conocidos por su eficiencia energética en redes de sensores inalámbricos. Adopta una ciclo periodico de escucha-espera para reducir el tiempo de escucha ociosa. Cada nodo apaga su transceptor de radio en un período de espera. Despierta en un período de escucha y puede comunicarse con otros nodos. Este período de escucha se utiliza para el intercambio de paquetes de control tales como SYNC, RTS, CTS y ACK y paquetes de datos. Por otra parte, puesto que cada nodo tiene un ciclo de trabajo fijo, S-MAC no puede adaptarse a la variación de los entorno de red.
Se propone un nuevo protocolo MAC con el concepto de 'escuchar' y 'esperar' para reducir el plazo escucha ociosa. Sin embargo, en contraste con la técnica de sincronizado y la técnica de escucha-espera de otros protocolos, en la propuesta los periodos de escuchar y esperar están determinados pseudoaleatoriamente en las probabilidades de pre-wakeup. Esto permite que el protocolo MAC propuesto operar en un modo asíncrono entre los diferentes pares de transmisor y receptor de nodos. Esto da como resultado un trafico uniformemente distribuido a través de intervalos de tiempo y la reducción de las colisiones.

2. Diseño propuesto



El protocolo MAC propuesto se conoce como "Sensor de Probabilidad MAC (PS-MAC).
PS-MAC es un protocolo de tiempo segmentado como S-MAC. Sin embargo, a diferencia de S-MAC, en el que todos los nodos tienen ciclos de escucha sincronizados y periódicos, y el mismo ciclo de espera, en el protocolo propuesto los pares de nodos transmisor y el receptor tienen ciclos escucha asíncronos y no periódicos y horarios de espera.
Para decidir entre escuchar o esperar en cada segmento de tiempo, cada nodo sensor hace uso de un generador de números pseudoaleatorios y determina su decisión según su probabilidad de preactivación y el número de semillas. Aunque cada nodo sensor determine de manera autónoma su periodo de escucha-espera, los nodos no pueden conocer el de nodos vecinos y podría haber un problema de overemitting que es causada por la la transmisión de paquetes cuando el nodo receptor está todavía en la
modo de suspensión. Para hacer frente a esta situación, los nodos vecinos intercambian sus probabilidades de preactivación y números de semillas. esto permite a cada nodo de saber la programación nodos vecinos, que se llama "programa de pre-activación", ya que en generador pseudo-aleatorio la secuencia generada es una secuencia determinista que depende del número de semillas. Basándose en su propio programa de pre-activacion y en el de sus vecinos, cada nodo determina su tiempo de escucha real y su tiempo de espera por la elección de un intervalo de tiempo como un modo de escucha si tanto algunos de sus nodos vecinos y sí está en el modo de escucha en ese intervalo de tiempo.

Algoritmo


1. Programa de preactivación


El algoritmo consta de dos etapas:
  1. Determinación del programa de preactivación
  2. Determinación de programa de activación real.
Cada nodo i tiene su propio número de semillas Seedi que se utiliza para generar una secuencia de números pseudo-aleatorios y probabilidad de preactivacion Pi. Cada nodo determina su programa de preactivación en función de su número de semillas y la probabilidad preactivación.
En primer lugar, en cada intervalo de tiempo t, cada nodo i genera un número Ui(t) entre 0 y 1 mediante con el uso de su generador pseudo-aleatorio y su número de semillas. El nodo establece la variable P Li (t) para el intervalo de tiempo t como:
$$ P L_{i} \left ( t \right ) = \begin{cases} & 1 \text{ if } U_{i} \left ( t \right ) \leq P_{i} \\ & 0 \text{ otherwise } \end{cases} $$
Basandose en P Li (t), el nodo i determina su programa de preactivación. Si P Li (t) = 1, el nodo i permanece en el modo de escucha en el intervalo de tiempo t , y si P Li (t) = 0, el nodo i permanece en el modo de suspensión en el intervalo de tiempo t.

La figura 1 ilustra un ejemplo de programación de pre-activación de dos nodos diferentes, el nodo 1 y el nodo 2; ambos tienen la misma probabilidad de pre-activación P1 = P2 = 0.3. Cada número en cada intervalo de tiempo representa un número generado pseudoaleatoriamente según el número de semillas de cada nodo. Desde que el programa de preactivación de cada nodo se determina (pseudo) al azar, cada nodo tiene un horario preactivación asincrónica en PS-MAC.


Después de determinar su programa de preactivación, cada nodo determina su programa de activación real basado en su propio horario preactivación y el de sus vecinos. Cada nodo i determina Lij (t) para cada nodo j su vecino en el intervalo de tiempo t  comparando su horario preactivación y el de preactivación del nodo j de la siguiente manera:
$$ L_{ij} \left ( t \right ) = \begin{cases} & 1 \text{ if } P L_{i} \left ( t \right ) = P L_{j} \left ( t \right ) \\ & 0 \text{ otherwise } \end{cases} $$

Por lo tanto, si Lij (t) = 1, entonces el nodo i y el nodo j se encuentran en modo escucha en sus programas de pre-activacion. Por lo tanto, el nodo i y el nodo j son capaces de comunicarse entre sí en el intervalo de tiempo t si Lij (t) = 1. Por lo tanto, en el programa de activación real, el nodo i esta en modo de escucha, si Lij (t) = 1 para alguno de sus vecinos nodo j.

2. Programa de activación real

El programa de activación de nodo i se determina mediante la realización de este procedimiento para cada uno de sus nodos vecinos. La figura 2 muestra programación de activación real entre el nodo 1 y el nodo 2. En la figura 1, el nodo 1 está en el modo de escucha en intervalos de tiempo de 1, 4,
y 9, y el nodo 2 en las ranuras de tiempo 4, 9, y 10. Por lo tanto, los nodos 1 y 2 estan en el modo de escucha en intervalos de tiempo de 4 y 9 en su programas de activación reales y se pueden comunicar uno con el otro en aquellos intervalos de tiempo.

3. Evaluación del desempeño

3. Topología de la simulación

Se utiliza el simulador NS-2 para las pruebas. Suponemos que la PS-MAC tiene formación SYNC-RTS-CTS como en S-MAC y que el número de semillas y la probabilidad de activación de cada nodo se transmite al vecino los nodos a través de un paquete SYNC. En esta simulación, 15 nodos están desplegados en un círculo regularmente, como se ilustra en la figura. 4. el nodo receptor está situado en el centro de un círculo cuyo radio es 50 metro. Cada nodo en la línea de un círculo transmite paquetes a el nodo receptor. El tiempo de ejecución de la simulación es de 1000 segundos.
Cada nodo sensor en la red experimental tiene un nivel inicial de energía de 100 joules. Un nodo consume una potencia de 500 mW en la transmisión de paquetes, 300 mW en la recepción y de 50 MW en el estado de reposo. Los parámetros del sistema son:

Transmit Power0.5 W
Receive Power0.3 W
Idle Power0.05 W
Radio Transmission Range250 m
Radio Interference Range550 m
Packet Length50 bytes

Para el modelo de tráfico, se utiliza tráfico UDP / CBR. La probabilidad de preactivación de cada nodo PS-MAC se ajusta para que sea 0.3.

4. Consumo de energía total de S-MAC y PS-MAC

La figura 4 muestra el consumo total de energía en comparación con el paquetetiempo entre llegadas. Como se muestra en esta figura, cuando el intervalo de tiempo de llegada es más de 20 segundos, PS-MAC está consumiendo menos energía quee S-MAC. Sin embargo, cuando el tiempo entre llegadas es
menos de 20 segundos, PS-MAC consume más energía que la S-MAC. Esto se debe a una situación de carga de tráfico pesado, el cual resulta en colisiones de paquetes graves en S-MAC. Cuando una colisiónse produce en S-MAC, el nodo emisor realiza al azar un retroceso y regenera el paquete RTS. Sólo después de que el nodo emisor recibe una respuesta de paquete CTS desde el nodo receptor, se transmiten los paquetes. Sin embargo, si aumentan las colisiones, es más probable que los paquetes RTS sólo se transmiten en lugar de la secuencia completa RTS-CTS-DATA-ACK. Por lo tanto, el número de paquetes transmitidos disminuye y S-MAC tiene menos energía el consumo.

5. Proporción de entrega de paquetes de S-MAC y PS-MAC


La figura 5 muestra comparación ente las proporciones de la entrega de paquetes en diferentes intervalos de tiempo. La relación de la entrega de paquetes se define como la relación entre el número de paquetes recibidos con éxito a la de los paquetes transmitidos. Como se muestra en esta figura, PS-MAC tiene una relación de la entrega de paquetes más alto que S-MAC en todas las situaciones.
Por otra parte, cuando el tiempo entre llegadas es inferior a 30 segundos, PS-MAC es mucho mejor que el S-MAC. Esto sucede debido al programa de sincronización en S-MAC, lo que resulta en una gran número de colisiones en situaciones de carga de tráfico pesado. Sin embargo, en PS-MAC, debido a la programación asíncrona los tiempos de escucha-espera entre cada par de nodos, el número de colisiones disminuye proporcionando una relación de entrega de paquetes más alta.

6. Eficiencia energética de PS-MAC relativa a S-MAC

La figura 6 muestra la eficiencia energética de PS-MAC relativa a S-MAC. Se muestra el consumo de energía por paquete transmitido con éxito para cada protocolo. Como se muestra en esta figura, PS-MAC tiene mejor rendimiento que el S-MAC. Por otra parte, como el tráfico cargas se vuelven más pesados​​, PS-MAC proporciona una mayor eficiencia energética que S-MAC. Este resultado nos dice que en S-MAC, el desperdicio de energía es mucho más grande en situaciones de carga más pesadas debido a la mucho mayor número de colisiones en comparación con PS-MAC.



Conclusión

Como se puede ver en los experimentos, me parece que el método propuesto es bastante bueno, ya que, establecer periodos donde los nodos permanecen activos y después entran en espera o dormidos parece ser una solución bastante simple y lógica, que mejor forma de ahorrar energía que apagar los nodos cuando no están haciendo nada.
Como ya puede leer, el único detalle es el establecimiento de dichos intervalos de escucha-espera, ya que se hace de forma pseudoaleatoria, pienso que en este aspecto aún se puede mejorar más. Es de esperarse que en condiciones de tráfico pesado el modelo propuesto se comporte un poco peor, pues los periodos de espera son pseudoaleatorios, una distribución pseudoaleatoria obvio no corresponde al comportamiento real del tráfico en una red, por lo que los nodos pueden entrar en espera aún cuando realmente deben estar despiertos porque la red se los exige. Lo bueno es que este método se puede adaptar a las condiciones de cada red modificando las probabilidades y el número de semillas.
Sin embargo, los experimentos demuestran que el modelo propuesto es mejor a uno ya existente por lo que se puede decir que el experimento fue exitoso.
Como trabajo adicional se puede experimentar con los diferentes parámetros para establecer las probabilidades reales de preactivación que proporcionen resultados mejores en condiciones de congestión alta.


Referencias

An Energy-Efficient MAC Protocol with Random

Listen-Sleep Schedule for Wireless Sensor Networks

Sung-Chan Choi∗ , Jang-Won Lee∗ , Yeonsoo Kim† , Hakjin Chong†
∗ Dept. of Electrical and Electronic Engineering, Yonsei University, Seoul, Korea
† Future Technology Laboratory, KT, Seoul, Korea

** Imágenes tomadas del respectivo paper.

martes, 23 de abril de 2013

[Lab RT] Actividad 8: Mecanismos de control de congestión


Para ésta semana continuamos con los temas de lecturas científicas, ahora el tema es referente a mecanismos de control de congestión, el documento seleccionado fue:

...


RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime
Streams in the Internet


Reza Rejaie, Mark Handley, Deborah Estrin
University of Southern California
Information Sciences Institute
Marina Del Rey, CA 90292
{ reza, mjh, estrin} @ isi.edu

...

1. Introducción


El Internet ha venido experimentando un aumento explosivo en el uso de aplicaciones de stream de audio y video. Dichas aplicaciones son bastante sensitivas a retrasos, cambios en las tasas de transferencia y necesitan tener un buen grado de confiabilidad, para esto se utilizan mecanismos QoS de punto a punto.
A pesar de todo esto, el Internet no garantiza bajos niveles de retrasos o un buen nivel de banda ancha disponible, por lo que el servicio provisto no es ni controlable ni predecible. Estas fallas en los mecanismos QoS no frenan el crecimiento de las aplicaciones de stream.
En redes compartidas, los sistemas reaccionan a las congestiones adaptando sus tasas de transferencia, para evitar que el sistema colapse; así mismo, adaptan su uso de banda ancha para que todos los flujos e información puedan coexistir sobre la misma conexión. Lo sistemas que toman estas medidas se conocen como "buenos ciudadanos".

La porción de tráfico dominante en Internet esta basado en TCP, por lo que es más viable implementar mecanismos de control de congestión que sean amigables con el entorno de dicho protocolo. Esto quiere decir que las aplicaciones de stream de datos deben tener la misma cantidad de banda ancha promedio sobre una sesión TCP que permanezca activa en el mismo camino y bajo las mismas condiciones de latencia y pérdida de paquetes.

Se hace uso de una arquitectura que se encarga de proveer streams codificados por capas y almacenados en Internet, el enfoque principal es el uso de un servidor web o de video bajo demanda que provea acceso a una gran variedad de contenido multimedia para un gran número de clientes. La meta es que las aplicaciones de reproducción en tiempo real sean buenos ciudadanos. La idea es separar el control del tráfico del control de errores porque el primero depende del estado de la red mientras que el segundo es especifico de la aplicación.

Las tasas de transferencia de los servidores son continuamente adaptadas por el protocolo RAP (Rate Adaptation Protocol), y dicho módulo es exclusivo para el control de congestiones y la detección de pérdidas. El gestor de capas adapta la calidad del stream transmitido de acuerdo a la tasa de transferencia especificada por el RAP y trata de enviar la mayor cantidad de capas posibles según la cantidad de banda ancha disponible. Durante un viaje de ida y vuelta algunas capas pueden perderse, por lo que se hace uso de un buffer en el lado del cliente para almacenarlas y ordenarlas temporalmente, así mismo, para hallar dónde faltan capas. El buffer ayuda a la retransmisión selectiva de capas las cuales son determinadas por el gestor de retransmisión. La banda ancha agregada utilizada por el servidor y por el gestor de retransmisión no debe exceder la banda ancha especificada por el RAP.

El paper presenta el diseño y evaluación del protocolo RAP a través de simulaciones, como método de control de congestión  adecuado para aplicaciones unicast de streams en tiempo real, asi como para otras aplicaciones compatibles. La meta es lograr que RAP se comporte correctamente y se amigable en TCP.


2. Trabajos relacionados


El estudio de mecanismos de control de congestión no es nuevo, sin embargo, el estudio de mecanismos de control de congestión amigables con TCP en redes de mejor intento es un poco más limitado.
Una aproximación común para la adaptación de tasas de transferencia es utilizar métodos de codificación adaptativa mediante el ajuste de los parámetros de los codecs basándose en el estado de la red. Sin embargo, esto no es muy recomendable ya que hace un uso intensivo del CPU para codificar los diferentes streams de los diferentes clientes.
Existe, por ejemplo, el protocolo SCP que es una versión modificada de TCP que utiliza un método parecido al TCP-Vegas para adaptar las tasas de transferencia, sin embargo, SCP no es muy amigable con TCP, por lo que para TCP se basa en el RTT calculado (Round Trip delay time).


3. Protocolo RAP


El protocolo fue implementado desde el principio. Básicamente, el protocolo envía todos los paquetes numerados secuencialmente, el destino de los paquetes reconoce los paquetes lo que provee un sistema de retroalimentación en la comunicación. Cada mensaje ACK contiene una secuencia de números que corresponde con la información entregada por el paquete. Utilizando la retroalimentación, la fuente RAP puede detectar las pérdidas. Durante el diseño del mecanismo de adaptación, se hallaron 3 problemas:

a) Función de decisión

El esquema de adaptación se basa en 2 reglas simples

  • Si no se detecta congestión, aumentar periódicamente la tasa de transferencia.
  • Si se detecta congestión, reducir inmediatamente la tasa de transferencia.
El RAP utiliza los mensajes de pérdidas como señales de congestión, y los tiempos de espera y las separaciones en las secuencias para detectar las pérdidas.
Mantiene un RTT (round trip delay time) estimado, al igual que en TCP, llamado SRTT y calcula el timeout utilizando el algoritmo de Jacobson/Karel. 
A diferencia de TCP, RAP puede enviar varios paquetes antes de recibir un nuevo ACK que permita recalcular el RTT estimado.
Para la deteccion de perdidas basado en ACK, RAP utiliza la misma intuición que el fast-recovery en TCP. Si una fuente RAP recibe un ACK, implica la entrega de tres paquetes después de perder uno.


b) Algoritmo de incremento/decremento

El algoritmo de incremento/reducción. En ausencia de pérdidas, la tasa de transferencia ira incrementándose en buena forma.
El algoritmo es controlado ajustando la separación entre paquetes, dicho ajuste depende de la tasa de transferencia y el tamaño del incremento, también depende de una constante de tiempo.

c) Frecuencia de decisión

Especifica que tan seguido se actualiza la tasa de transferencia. La frecuencia de ajuste optimo depende del delay en la retroalimentación. Los delays en la retroalimentación son iguales a un RTT. Esto sugiere que los esquemas basados en la tasa de transferencia no deben actualizarse mas de una vez por RTT, cambios muy frecuentes pueden causar oscilaciones inesperadas y ocasionar que el sistema no responda.
RAP realiza los ajustes una vez por SRTT. El tiempo entre dos ajustes es llamado step.


Pérdidas agrupadas

En una red compartida basada en el mejor esfuerzo con un alto nivel de multiplexing estadístico, se observa que el patrón de pérdidas se acerca mucho a un comportamiento aleatorio.
Ésto dificulta el control de las pérdidas ajustando solamente la tasa de transferencia.
RAP requiere de un mecanismo para identificar donde se concentran las pérdidas y saber si estan relacionadas a un mismo evento de congestión. La pérdida de un paquete resulta en un retroceso, los paquetes pendientes en la cola, llamada cluster, tienen un número de secuencia que se enumeran desde la ultima perdida hasta el momento en que sucede la siguiente pérdida.
Un evento de pérdida define un nuevo evento de congestión.


Random Early Detection Gateway

Parece existr un acuerdo general en la comunidad para desarrollar Random Early Detection gateways para mejorar el desempeño del trafico TCP.
El manejo de la cola de paquetes en RED intenta mantener un tamaño promedio pequeño y también acomodar una gran cantidad de paquetes para evitar el desbordamiento del buffer.
Uno de los principales problemas en el control de congestión en TCP es intentar recuperarse de multiples perdidas dentro de un mismo periodo. Esto se debe a que durante un desbordamiento se tiran todas las colas de datos.
Idealmente, los gateways RED deben estar configurados de tal manera que cada flujo experimenta como máximo una sola pérdida por RTT. Bajo estas circunstancias, los flujos de TCP pueden recuperar de manera eficiente a partir de una sola pérdida sin experimentar un tiempo de espera de retransmisión. Intuitivamente, siempre y cuando un gateway RED funcione en su región ideal, RAP y TCP obtienen una parte igual de ancho de banda ya que ambos utilizan el algoritmo AIMD. Sin embargo, si la longitud media de la cola supera el umbral máximo, RED comienza a descartar paquetes con una probabilidad muy alta. En este punto, RAP y TCP empiezan a comportarse de forma diferente. Cuando el TCP normal experimenta pérdidas múltiples dentro de una ventana, se somete a un tiempo de espera de retransmisión y sus control de congestión divergen del algoritmo AIMD.

Se espera observar una mejora sustancial en el rendimiento mediante la implementación de RED aunque sólo impide que el búfer se desborde y causando la pérdida de ráfaga. Este comportamiento limita la divergencia de control de congestión de TCP del algoritmo AIMD.
Como parámetros RED dependen estrechamente del comportamiento del tráfico total, es difícil mantener el trafico RED en su región ideal debido a los cambios de tráfico con el tiempo.
Por lo tanto, la configuración de RED sigue siendo un tema de investigación.


4. Simulación


El objetivo de la simulación presentada es explorar las propiedades de RAP y su capacidad de hacer frente al trafico TCP, su interacción con gateways RED.
Las simulaciones demuestran que RAP es amigable bajo el protocolo TCP.
Las simulaciones se realizaron utilizando el simulador NS2 y se comparo con TCP Tahoe, Reno, NewReno, Sack y con experimentos del mundo real.
La topología de la simulación se muestra en la siguiente imagen:



Las especificaciones de la simulación son:
  • La conexión entre SW1 y SW2 siempre tiene un cuello de botella y el nodo SW1 es el inicio del cuello de botella.
  • Los switches implementan un scheduler tipo FIFO y una cola tipo drop-tail, con excepción en las simulaciones RED.
  • Son m conexiones tipo RAP desde los nodos R1 ... Rm, hasta los nodos P1 ... Pm.
  • Las conexiones comparten la banda ancha en el cuello de botella con n flujos TCP desde las fuentes T1 ... Tn, hasta los receptores S1 .. Sn.
  • Los datos y los paquetes ACK son similares para RAP y TCP.
  • Todas las conexiones cuentan con el mismo delay
  • El tamaño del buffer en SW1 tiene cuatro veces mas banda ancha RTT.
  • Todas las simulaciones correrán hasta que muestren un comportamiento estático.
  • Todos los flujos TCP son sesiones de tipo FTP con una cantidad infinita de información.
  • La banda ancha promedio es medida por el número de paquetes durante los últimos tres cuartos del tiempo de la simulación para ignorar el comportamiento transitorio del principio
Los parámetros de la simulación son:

Packet size100 bytes
ACK Size40 bytes
Bottleneck delay20 ms
B/W per flow5 Kbytes/s
B/W of Side Links1.25 Mbytes/s
Tot. Delay of Side Links6 ms
Simulation Length120 sec
TCP Maximum Window1000
TCP Timeout Granularity100 ms

5. Conclusiones y trabajo futuro


Aunque alcanzar una buena compatibilidad con TCP  en una amplia gama de parámetros de la red es extremadamente difícil, RAP alcanza razonablemente este objetivo. Se diseño y evalúo un mecanismo de adaptación de la tasa de transferencia para emular la propiedad de temporización ACK de TCP. Los resultados muestran que la adaptación de la tasa de transferencia la coexistencia de ambos protocolos a un nivel más amplio. La divergencia del control de congestión de TCP respecto al algoritmo AIMD suele ser la causa principal de la falta de equidad de TCP en casos especiales. Este problema se manifiesta con mayor claridad con Reno y Tahoe, mientras que tiene un impacto más limitado en Sack.
Si los gateways RED son debidamente configurados, se puede alcanzar una capacidad de intercambio ideal entre protocolos.
RAP es un componente esencial de la arquitectura de extremo a extremo para la reproducción de flujos unicast en tiempo real a través de redes de mejor esfuerzo. Se ha desarrollado una "adaptación de calidad" mecanismo que ajusta sin problemas la calidad de una reproducción de vídeo codificada en capas, mientras que su velocidad de transmisión es controlada por RAP.


Referencias


Imágenes tomadas del paper.

martes, 16 de abril de 2013

[Lab RT] Actividad 7: Medidas de desempeño y métodos de generación de tráfico

La tarea de esta semana constitió en:
  • Investigar sobre los métodos de generación de tráfico en el simulador NS-2 o NS-3, cómo  generarlo y cómo modificar sus propiedades.
  • Cómo se pueden monitorear las medidas de desempeño en la red simulada.

Seguimos utilizando NS-2, con algunas mejoras al generador de topologías de la entrada anterior.

Generación de tráfico


La generación de tráfico en NS-2 entra dentro de la clasificación Application Objects. Un Application Object puede ser de 2 tipos, una aplicación simulada o un generador de tráfico.

Lo que nos interesa son, justamente los generadores de tráfico.
Los objetos generadores de tráfico, generan tráfico de 4 tipos principales, y con una pequeña modificación, hasta 5 tipos diferentes, cada uno con sus propiedades y los cuales se describen a continuación.


Exponencial (Application/Traffic/Exponential)

Los objetos de tráfico exponencial, generan tráfico que puede "encenderse" o "apagarse" (comenzar y detenerse) por ciertos periodos de tiempo.
Durante los periodos de "encendido" los paquetes son generados en forma de ráfagas constantes. Durante los periodos de "apagado", pues ningún tipo de tráfico es generado.
Los periodos de encendido y apagado, y sus tiempos de duración, son tomados de acuerdo a una distribución exponencial.

Los parámetros de configuración de éste tipo de tráfico son:
  • PacketSize_ : El tamaño del paquete a generar, constante.
  • burst_time_ : Tiempo promedio para el estado "encendido" del tráfico.
  • idle_time_ : Tiempo promedio para el estado "apagado" del tráfico.
  • rate_ : Velocidad de transferencia durante los tiempos de "encendido".
set e [new Application/Traffic/Exponential] $e set packetSize_ 210 $e set burst_time_ 500ms $e set idle_time_ 500ms $e set rate_ 100k

Poisson:

Configurando de forma especial el generador exponencial se puede obtener un generador que tome la forma de la distribución de Poisson.
Estableciendo la variable burst_time_ a cero y la variable rate_ a un valor demasiado alto se obtiene el resultado esperado.
Adicionalmente, el valor entre llegadas de paquetes es la suma de la tasa de transferencia (rate_) y el valor aleatorio correspondiente al parámetro idle_time_ . Para hacer el primero valor de la suma muy pequeño, el parámetro burst_time_ debe ser muy alto, de tal forma que el tiempo de transmisión sea despreciable comparado con los tiempos típicos de espera (idle_times).


Pareto (Application/Traffic/Pareto)

Genera tráfico con las mismas caracteristicas que el generador exponencial, la diferencia es que éste toma la forma de la distribución de Pareto.
Los parámetros de configuración son:
  • PacketSize_ : Tamaño constante de los paquetes generados.
  • burst_time_ : Tiempo promedio para el estado "encendido" del tráfico.
  • idle_time_ : Tiempo promedio para el estado "apagado" del tráfico.
  • rate_ : Velocidad de transferencia durante los tiempos de "encendido".
  • shape_ : Parámetro propio de la distribución.

set p [new Application/Traffic/Pareto] $p set packetSize_ 210 $p set burst_time_ 500ms $p set idle_time_ 500ms $p set rate_ 200k $p set shape_ 1.5

CBR (Application/Traffic/CBR)

El tipo de tráfico genera ráfagas constantes de paquetes a una velocidad constante, es útil para simular aplicaciones multimedia como stream de música o videos. Por lo general se utiliza bajo el protocolo UDP.
Los parámetros de configuración son:
  • PacketSize_ : El tamaño del paquete a enviar, constante.
  • rate_ : La tasa de transferencia.
  • interval_ : El intervalo de tiempo entre los paquetes.
  • random_ : Si se desea introducir ruido aleatorio en los tiempos de salida.
  • maxpkts_ : La cantidad máxima de paquetes a enviar, por ejemplo, en videostream, el tamaño del video a ver.
Los parámetros rate_ e interval_ son mutualmente excluyentes, es decir, en algunos scripts de puede configurar el intervalo en lugar de la tasa de transferencia o al revés  para cualquier simulación algunos de los 2 parámetros debe ser especificado.
set cbr [new Application/Traffic/CBR] $cbr set packetSize_ 48 $cbr set rate_ 64Kb $cbr set random_ 1

Trace (Application/Traffic/Trace)

Los objetos de éste tipo son utilizados para generar tráfico a partir de un archivo de trazado.
Se debe adjuntar el archivo de trazado a este objeto, el cual especifica los datos del tráfico ya existentes.
Un archivo consiste en una serie de lineas con un formato y largo fijos. Cada línea o registro consiste en campos de 2*32 bit.
El primero indica el intervalo hasta el cual de podrá generar el siguiente paquete. El segundo indica el largo del siguiente paquete en bytes.

No hay parámetros de configuración para éste generador.


FTP over TCP (Application/FTP)

Como ya sabemos, se trata de tráfico que simula la transferencia de archivos bajo el modelo de cliente servidor.
Este tipo de tráfico es útil por ejemplo, para simular la descarga o subida de archivos, o para simular la transferencia de videos desde Youtube (desde que youtube utiliza TCP para la transferencia de videos.)

No hay parámetros de configuración para éste generador.
set ftp [new Application/FTP]
$ftp attach­agent $tcp0



Telnet over TCP (Application/Telnet)
Con éste tipo de tráfico se pueden simular sesiones de línea de comandos, no generan paquetes de un tamaño muy grande pero son útiles para simular tráfico real.

No hay parámetros de configuración para éste generador.
set telnet [new Application/Telnet]
$telnet attach­-agent $tcp0


Medidas de desempeño

Para analizar el rendimiento de nuestra red podemos analizar los archivos de salida de NS-2, estos archivos son los archivos de visualización en Network Animator (*.nam) y los archivos de trazas o trazado (*.tr)

Los archivos de trazas estan separados por espacios, y siguien el siguiente formato:

tipo de evento
tiempo
Nodo inicial
Nodo final
Tipo de tráfico
Tamaño del paquete
+,-,r,h,d
1.15
10
0
TCP,UDP
1000

Los archivos de nam tienen flags para separar los elementos utilizando el siguiente formato:

tipo de eventotiempoNodo inicialNodo finalTipo de tráficoTamaño del paquete
+,-,r,h,d-t 1.15-s 10-d 0-p TCP,UDP-e 1000

Los tipos de eventos pueden ser:

  • + : archivo en cola
  • -  : paquete sacado de la cola
  • r : paquete recibido
  • h : paquete enrutado
  • d : paquete desechado (dropped)

Se pueden utilizar scripts de AWK que nos ayudan a leer dichos archivos y generar las estadísticas correspondientes de latencia, retraso, jitter y throughput.

Escribi un ejemplo de archivo para calcular el rendimiento de la red, los paquetes enviados y recibidos:

Prueba


Las mejoras al código de generación de topologías fue agregar redes un poco más reales, entonces ayudandome un poco con la libreria de python networkx pude generar redes en forma de grafos tipo small-world y scale-free

Solo se agregaron las siguientes lineas:

Después sigue la generación de tráfico, para ello implemente un módulo sencillo que lee un archivo que contiene el tráfico en la red con el siguiente formato:

n1,n2,1.0,4.0,tcp,ftp,0 n1,n2,1.0,4.0,tcp,tel,0 n1,n2,1.0,4.0,udp,cbr,700;1000 n1,n2,1.0,4.0,udp,exp,310;500;500;1000 n1,n2,1.0,4.0,udp,par,500;300;100;1000

Los elementos de cada línea del archivo son:

  • Nodo inicial
  • Nodo final
  • Tiempo de inicio del stream
  • Tiempo final del stream
  • Protocolo
  • Generador
  • Parámetros propios de cada generador (ver descripciones arriba)

Así, al leer el archivo se van generando las topologías y sus conexiones, después se genera el tráfico.
Es necesario conocer la topología para generar el tráfico, es decir, cuantos nodos son para introducir tráfico solo a conexiones existentes.

Cabe recordar que el script de python genera el script TCL de la simulación.

El método es un poco simple, pero cumple para generar el tráfico de distintos tipos, la función encargada de generar el tráfico es la siguiente:



En el siguiente video se puede ver como se programó el nodo 10 como "servidor" enviando tráfico UDP a los demás nodos, además se programo que el flujo de datos siguiera la distribución Exponencial y Pareto por lo que se puede ver como los nodos se conectan y desconectan repentinamente, siguiendo estas distribuciones. La topología es una malla que conecta 4 redes tipo scale-free.



Calculando el rendimiento:



Referencias

martes, 9 de abril de 2013

[Lab RT] Actividad 6: Métodos de ruteo y creación de topologías en NS2

La tarea de esta semana constitió en:
  • Investigar sobre los métodos de ruteo en el simulador NS-2 o NS-3, y cómo habilitarlos y/o cambiarlos para una simulación.
  • Crear un generador de topologías.

Para las simulaciones utilizaré NS-2 ya que, aunque ya es antiguo  considero que tiene mejor documentación y sirve muy bien para las actividades requeridas.

Para su instalación y configuración pueden seguir la guía que escribí en la entrada anterior:


Métodos de ruteo


En NS-2 es posible activar 3 métodos diferentes de ruteo, cada uno con sus tipos más específicos, los métodos son:

  • Unicast: Se utiliza cuando la información (paquetes) viajan desde un solo emisor a un solo receptor. Es decir, de nodo a nodo.
  • Multicast: Se utiliza cuando la información (paquetes) viajan desde un emisor a varios destinatarios. De un nodo a una lista específica de nodos.
  • Adhoc: Se utiliza en las transmisiones inalámbricas, donde no existe un nodo central sino que todos están listos para enviar y recibir información.

Unicast:

Es el método de ruteo por default en NS-2 y por lo general no es necesario especificarlo, sin embargo, se pueden activar diferentes protocolos y algoritmos que entran en ésta clasificación:

  • Static: Es la estrategia de ruteo por default, y utiliza el algoritmo de Dijkstra para el calculo de las  rutas, el cual corre una vez justo después del inicio de la simulación
  • Session: Se utiliza para realizar cambios en el ruteo de los nodos de la topología, lo que permite redes dinámicas. Sin embargo, no es muy realista ya que no hay interrupciones transitorias como en el caso del ruteo estático.
  • DV: Implementación del algoritmo Bellman-Ford para hallar las mejores rutas entre los nodo. Las rutas se actualizan periódicamente según un intervalo de tiempo establecido.
  • Cost: Establece costos a cada una de las conexiones entre los nodos, los costos pueden ser diferentes en cada dirección.
  • Multi-path

Para activar cualquiera de los protocolos o algoritmos de ruteo unicast se debe hacer una llamada al procedimiento rtproto y después especificar el tipo de ruteo a aplicar, por ejemplo:
$ns rtproto Static; $ns rtproto Session; $ns rtproto DV $n1 $n2 $n3;

Multicast:

  • CtrMcast: Similar al PIM-SM (Protocol Independent Multicast Sparse Mode), es un protocolo para ruteo eficiente a grupos de multicast, construye un esquema tipo árbol de cada emisor a receptor en el grupo de multicast.
  • DM: Similar al PIM-DM (Protocol Independent Multicast Sparse Mode), es un protocolo adecuado donde muchos nodos se suscriben para recibir paquetes multicast
  • ST: Shared Tree Model
  • BST: Bi-directional Shared Tree Model

Para activar cualquiera de los protocolos de ruteo basados en multicast se deben hacer llamadas a 2 procedimientos multicast y mrtproto:
$ns multicast (justo despues de set $ns [new Scheduler]) $ns mrtproto BST $ns mrtproto ST $ns mrtproto CtrMcast

Adhoc:

Los protocolos adhoc se utilizan en redes inálambricas, y solo es posible utilizarlo y el nodo se configura especifícamente para ser nodo inalámbrico (que en NS-2 se conoce como nodo móvil [mobile node]). Para configurar un nodo de forma inalámbrica, se deben de tomar en cuenta las siguientes opciones y elegir de los parámetros los que apliquen en nuestro modelo:

OpcionesParametrosNotas
addressTypeflat, hierarchichal
MPLSON,OFFMulti protocol Label Switching
wiredRoutingON, OFF
llTypeLL, LL/SatLink Layer
macTypeMac/802_11, Mac/Csma/Ca, Mac/Sat, Mac/Sat/UnslottedAloha, Mac/TdmaMedium Access Control
ifqTypeQueue/DropTail, Queue/DropTail/PriQueueInterface Queue type
phyTypePhy/wirelessPhy, Phy/SatPhysical Layer Type
adhocRoutingDIFFUSION/RATE, DIFFUSION/PROB, DSDV, DSR, FLOODING, OMNIMCAST,AODV,TORA,PUMAadhoc routing protocol
propTypePropagation/TwoRayGround, Propagation/ShadowingPropagation Type
antTypeAntenna/OmniAntenna, Antenna type
ChannelChannel/WirelessChannel, Channel/SatChannel to be used
mobileIPON,OFFto set the IP for Mobile or not
energyModelEnergyModelenergy model to be enabled or not
initialEnergy<joule>in terms of joules (Ex: 3.24)
txPowerPower in terms of Watts (0.32)
rxPowerPower in terms of Watts (0.1)
idlePowerPower in terms of Watts (0.02)
agentTraceON, OFFTracing to be on or off
routerTraceON, OFFTracing to be on or off
macTraceON, OFFTracing to be on or off
movementTraceON, OFFTracing to be on or off
errProcUniformErrorProc
toraDebugON, OFF


En la opción adhocRouting se pueden elegir los diferentes modos de ruteo.
Un ejemplo de configuración de un nodo inalámbrico con protocolo de enrutamiento adhoc sería:

$ns node-config -addressType hierarchical \ -adhocRouting AODV \ -llType LL \ -macType Mac/802_11 \ -ifqType Queue/DropTail/PriQueue \ -ifqLen 50 \ -antType Antenna/OmniAntenna \ -propType Propagation/TwoRayGround \ -phyType Phy/WirelessPhy \ -topologyInstance \$topo \ -channel Channel/WirelessChannel \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace OFF

Manual:

Si se decide por un método de ruteo manual, se tendrán que escribir las tablas de ruteo una por una, las cuales no son más que un conjunto de reglas que especifican hacia donde viajan los paquetes, cuál nodo es el inicial, cuál nodo es el destino, etcétera. Un ejemplo con 2 nodos:
$ns rtproto Manual set n1 [$ns node] set n2 [$ns node] $ns duplex-link $n1 $n2 10Mb 100ms DropTail [$n1 get-module "Manual"] add-route-to-adj-node -default $n2 [$n1 get-module "Manual"] add-route-to-adj-node $n2 [$n2 get-module "Manual"] add-route-to-adj-node -default $n1

Por default, en la mayoría de los protocolos de ruteo el algoritmo utilizado para hallar los caminos entre los nodos es el algoritmo de Dijkstra.
También se pueden realizar tareas más avanzadas como modificar la tabla de ruteo en cada nodo, o escribir nuestro propio algoritmo de ruteo.


Errores de red


Un concepto adicional y que aporta más realismo a una simulación es la programación de errores en la red. La forma más simple es insertar un error para la pérdida de paquetes en una conexión entre dos nodos. La manera de hacerlo es la siguiente:
set loss_module [new ErrorModel] $loss_module set rate_ 0.01 $loss_module unit pkt $loss_module ranvar [new RandomVariable/Uniform] $loss_module drop-target [new Agent/Null] $ns lossmodel $loss_module $n0 $n1

Generación de topologías


Para la generación de topologías, me centré solamente en un los tipos de ruteo unicast y multicast. El script para la generación de topologías es escalable, por lo que no sería complejo implementar otros métodos de ruteo, como el adhoc, exceptuando el manual el cual tendría que aplicarse editando directamente el archivo *.tcl que da como salida el script

El lenguaje que utilicé para la generación de topologías fue Python, y mediante este script genero un archivo *.tcl.

Primeramente, el script recibe como entrada un archivo separado por comas donde viene especificada la configuración de la red, el archivo tiene el siguiente formato:

sim,3.0,unicast,DV red,r1,30,5,50,duplex-link,null,m;1.0 subred,s1,10,1,75,duplex-link,udp,e subred,s2,10,1,80,duplex-link,tcp,e subred,s3,10,1,50,duplex-link,udp,a

El primer elemento es una etiqueta, ahora solo se soportan 3 etiquetas, cada una con un formato especifico, en este orden deben escribirse en el archivo:

  • sim: Refiere a los parámetros generales de la simulación  en orden, los parámetros especificados en esta linea son tiempo de la simulación, tipo de ruteo, subtipo de ruteo.
  • red: Aquí se especifican los parámetros de la red a crear, en orden, los parámetros especificados son: un id para identificar el objeto, el numero de nodos de toda la red, ancho de banda, latencia, tipo de conexiones, tipo de trafico, tipo de topología, parámetros específicos de la topología.
  • subred: Una vez que se ha creado la red, la red se divide en subredes. Los parámetros son los mismos que para toda la red. Se tiene que ajustar manualmente el número de nodos de cada subred y al final la suma debe coincidir con la cantidad de nodos de toda la red.

Las topologías soportadas son 3 (las más comunes):
  • Estrella: Un nodo central y todos los demás nodos conectados a él.
  • Anillo: Un nodo central, conectados en forma de lista enlazada, el último nodo se conecta con el primero.
  • Malla: Conecta todos los nodos entre sí, pero recibe un parámetro adicional que es un valor entre 0.0 y 1.0, este parámetro es la probabilidad de conexión lo que permite crear topologías con forma de grafo. Se crea una matriz de adyacencia para crear las conexiones pero aun falta ajustar un poco pues pueden salir nodos huerfanos.

Para el caso de las redes con forma de grafo, no es necesario especificar la etiqueta subred, solo en la etiqueta red especifican la cantidad de nodos y el script arma la red completamente.
Los tipos de ruteo soportados son los que entran en la clasificación de unicast y multicast.

El tráfico soportado por el script es de dos tipos:
  • TCP: De tipo FTP
  • UDP: De tipo CBR
El tráfico se genera de manera automática también, pero es diferente para cada subred. Se toman los nodos de una subred y se configuran para ser generadores de tráfico y receptores a la vez.
Sin embargo, el script decide cuales de las posibles conexiones estará activa.

Los tipos de conexión soportados son:
  • Simplex-link
  • Duplex-link

Evaluando las posibilidades, pienso que se pueden simular una buena cantidad de redes con estas características ya que, por si sola, la topología de malla puede tomar muchas formas y soportar una gran cantidad de nodos.


Capturas de ejemplo:
Ejemplo de 2 estrellas y 2 anillos, conectados por una malla


Ejemplo de una red con forma de grafo

Videos

El primer video es básico, una topología de grafo simple con un método de ruteo Unicast tipo Session.


El segundo video es un poco más complejo, 4 topologías, 2 estrellas y 2 anillos conectadas por una malla, utilizando ruteo Unicast tipo DV.
Se puede ver en los primeros segundos como la red envía mensajes broadcast a todos los nodos para calcular las tablas de ruteo.
Hay ciertos segundos donde lo vuelve a hacer pero por la calidad del video no se alcanzan a apreciar claramente.




Código

Implementar la lógica del programa fue todo un desafío, sobre todo tomando en cuenta que el script debe aceptar redes escalables, conectar los nodos, asignar los agentes correctamente y que el trafico se genere y termine donde debe ser, sin embargo, pienso que el resultado final fue muy bueno.
Aún faltan detalles por afinar y cosas que implementar, acepto recomendaciones.

Referencias: