Mostrando entradas con la etiqueta lab. Mostrar todas las entradas
Mostrando entradas con la etiqueta lab. Mostrar todas las entradas

martes, 30 de abril de 2013

Actividad #9 Lab - Ahorro de Energía (lifetime)

Para esta tarea, se realizó un resumen del siguiente documento:


Maximum Network Lifetime in Wireless Sensor Networks with Adjustable Sensing Ranges
Autores: Mihaela Cardei, Jie Wu, Mingming Lu, Mohammad O. Pervaiz

El documento habla acerca de mecanismos para extender o como optimizar la vida útil o tiempo de actividad de una red inalámbrica (cuando se están usando baterías) esto debido al alto consumo de energía al transmitir datos o al tratar de conectar con nuevos nodos.

Debido a que las redes inalámbricas son muy dinámicas en cuanto a la conexión con otros nodos/clientes, es decir la mayoría de las veces no se tiene un límite de usuarios por lo que el consumo de energía puede variar mucho además de esto las variados posiciones que los nodos pueden tomar hacen que el uso de una topología para tener más orden sea más complejo.

Para estos casos, los limitantes son el tamaño (capacidad) de la batería y el peso de esta, generalmente a más capacidad más peso, por lo que actualmente esto impacta directamente en el tiempo de vida de una red de este tipo (sobre todo en dispositivos móviles) ya que siempre se busca la movilidad.

Los mecanismos para extender la vida de estas redes se pueden clasificar en dos tipos:
·         Manejar la activación y desactivación de ciertos nodos.
·         Ajustar la transmisión de datos o el rango que cubre la red.

Algunos problemas que se deben repasar para llevar a cabo el punto central del documento, son los algunos ya conocidos como:
·         Área de cobertura: el objetivo es cubrir cierta área de interés.
·         Puntos/objetivos a cubrir: Dar servicio de cobertura a ciertos nodos.
·         Problemas de cobertura: Determinar el máximo tráfico que puede viajar dentro de la red.

Algunas soluciones propuestas a estos problemas en otras ocasiones, una de ellas es:
·         Una correcta distribución de nodos y protocolo (manejando la activad de la red en rounds), estos nodos se activan para cubrir cierto espacio (donde se requieren conexión) mientras los otros se desactivan porque no se requiere conexión.

El punto aquí es como determinar el número óptimo de nodos para satisfacer las necesidades de la red, como determinar los rounds y en qué punto se debe de cambiar de uno a otro, la posición correcta de estos nodos, la transmisión de datos, todos estos puntos son necesarios con el fin de optimizar el consumo de energía y con esto alargar la vida útil de la red.

El problema planteado (de manera muy general) más formalmente se puede definir de la siguiente forma:
Se tiene cierta cantidad de nodos ubicados de manera aleatoria con el fin de cubrir ciertos objetivos, cada nodo tiene su consumo inicial de energía y la capacidad de ajustar la intensidad de su señal (se definen n opciones). El nodo central tiene la capacidad de conectarse a cualquier otro nodo.
Y se necesita un método para calcular la relación de cobertura entre un nodo y un objetivo (cliente), es decir si la distancia Euclidiana entre el nodo y el cliente no es mayor a una distancia dentro del área de cobertura original.
Con esta información, si la distancia es menor que la cubierta originalmente, se puede modificar para que se disminuya intensidad y así reducir el consumo de energía, en caso de lo contrario se recalcula un nuevo nodo, y se repite el proceso para tratar de disminuir la intensidad de su señal.


La idea de problema se puede aclarar con la siguiente figura:


Donde las sn son los nodos, los tn son las clientes/objetivos y las rn son las opciones de intensidad.
  

Para la obtención de resultados sobre este problema, en el documento se proponen y se aplican tres métodos heurísticos (LP-based heuristic and greedy-based heuristic(centralized and distributed) ) creados por ellos mismos, los métodos se aplican sobre el planteamiento del problema como Programación Entera.
Dos de los métodos se ejecutan en el nodo central, mientras que otro se ejecuta en los nodos con el fin de obtener diferentes perspectivas y nombrar el “más” correcto.

Después de las respectivas simulaciones, los resultados se pueden categorizar de la siguiente forma:



En la figura se muestra el tiempo de vida útil de la red, obtenida de los tres diferentes métodos variando el número de nodos.


En esta figura se muestra como varía la vida útil de la red al modificar la intensidad de los nodos.

Conclusiones

La idea que se propone es buena al tratar de economizar el consumo de energía sobre todo si se trata de dispositivos dependientes de una batería, pero como lo dije en la entrada anterior, los resultados de una simulación pueden resultar engañosos ya que es muy difícil el replicar completamente el comportamiento de cierto medio, por lo que los resultados obtenidos en una simulación pueden no ser los mismos al aplicarse los métodos en un contexto real.

Otro punto, si la idea es disminuir el consumo de energía para alargar la vida útil de la red, según yo resulta contraproducente el realizar cálculos extras para poder aplicar los métodos que se mencionan en el documento, obtener los resultados y tomar decisiones. Estos cálculos extras se reflejaran directamente en el consumo de energía ya que antes no se hacían y al parecer esto no se tomó en cuenta en el documento.

________________________________________________________________________
Enlaces:

martes, 23 de abril de 2013

Actividad Lab. #8 - Congestión de Redes


Resumen de:
Congestion Control for Scalable Video Streaming Using the Scalability Extension of H.264/AVC
Autores: Dieu Thanh Nguyen and Joern Ostermann
IEEE JOURNAL OF SELECTED TOPICS IN SIGNAL PROCESSING, VOL. 1, NO. 2, AUGUST 2007


Mencionan que en la actualidad la demanda del video streaming ha crecido en gran medida, ya que la mayoría de los servicios que hay en internet ofrecen de diferentes formas contenido presentado de esta forma, como puede ser video streaming de servicios como youtube, dailymotion donde el video se descarga normalmente a nuestra computadora mientras se reproduce o servicios de video on demand donde el video se descarga y se “decodifica” para que lo podamos ver, o también video streaming de transmisiones en vivo, donde puede ocurrir algo parecido al video on demand.

Cada una de estas formas de prestar el servicio de streaming acusa un congestionamiento o saturación de la red, ya que la mayoría de las aplicaciones consumen la mayor parte del ancho de banda que se encuentre disponible dejando sin recursos a otras aplicaciones o usuarios incluso afectando a sí mismos si el ancho de banda no es el adecuado que se ve reflajado como pérdida de paquetes, retrasos, etc.

La propuesta de este paper es una especie de algoritmo para controlar en gran medida el congestionamiento de las redes al utilizar servicios de streaming, la idea que proponen es que este algoritmo se encuentre en funcionamiento directamente en los servidos de las aplicaciones de streaming y no en los clientes (que sería lo más entendible), se busca que este algoritmo sea capaz de optimizar totalmente el flujo de datos teniendo en cuenta las carencias de la red del cliente que se conecte para así no saturar su propia red ni la del cliente, y tener más oportunidades de ofrecer un mejor servicio al momento de la conexión de un gran número de clientes a la vez.

Un aspecto importante a mencionar en el paper es el formato/codificación para video que proponen para mejorar el flujo cuando se hace streaming, que ya desde hace tiempo varias organizaciones han buscado su estandarización y que al parecer a la fecha la norma se quedó en H.264/AVC.
Estos formatos permiten organizar la información contenida en el video de manera que se pueden producir grandes calidades de imagen a menores cantidades de espacio, debido a sus mecanismos de compresión/descompresión por lo que son ideales para aplicaciones para hacer streaming.

Arquitectura del sistema propuesto
Debido a que las aplicaciones de video streaming se ejecutan usando UDP como protocolo de transporte y no TCP, se desaprovechan algunas opciones de este último como el hecho de poder reducir la latencia mediante retransmisión de paquetes, además el protocolo UDP no provee mecanismos para controlar la congestión de la red (TCP si lo hace) y al querer implementar algo para arreglar esto, es necesario que lo que se cree se ejecute en la capa de aplicación del UDP.

Para la estimación del ancho de banda disponible y evitar la congestión de la red, el algoritmo propuesto identifica los cuellos de botella, es decir los puntos en los que la conexión se reduce considerablemente evitando el flujo de la información, con estos embotellamientos detectados procede a disminuir la carga del flujo de información con el fin de no presionar el embotellamiento y causar más caos, y recalcula estos embotellamientos constantemente para decir el tamaño del flujo.

Debido a que la estimación del ancho de banda puede fallar (se calcula el ancho de banda disponible pero la información de este llega retrasada por lo que el flujo de datos a enviar puede no ser el correcto en ese momento), también se propone un mecanismo que actúe en caso de que este error ocurra. La idea es tomar todos los paquetes recibidos y ordenarlos según su prioridad, debido a que el dato de la estimación del ancho de banda puede no ser correcto, estos paquetes se comienzan en enviar de manera que los de mayor prioridad sean los primeros y después los de menor prioridad.
Esto es debido a que el decodificador del video si puede reconstruir la estructura del video a partir de los paquetes con mayor prioridad (lo hace disminuyendo la calidad de video o con breves pérdidas de calidad) y no puede hacer esto partiendo de los paquetes con menos prioridad.
Esto se hace así con el fin de que si el ancho de banda no es el adecuado, solo se pierdan los paquetes de menor calidad y la transmisión del video pueda continuar.

Una imagen de la simulación del sistema con ns-2, donde se espera hacer streaming desde el servidor al cliente, el enlace entre las dos partes de simula utilizando dos routers (R1 y R2) y el cuello de botella será el el menor ancho de banda que produzca alguno de estos dos routers (1200kbit/s). El protocolo de envío de paquetes es UDP.


Los resultados de la simulación anterior comparándolo con los manejos de TCP y UDP se pueden ver en la siguiente gráfica:


Conclusiones
En conclusión se puede decir que la idea de estos tipos es buena, aunque se puede mejorar utilizando un sistema parecido pero ejecutándose en los clientes y que interactúe con el del servidor, de esta manera se puede obtener mayor precisión en los datos para los cálculos de los anchos de banda o el envío de información.

Y aunque a simple vista los resultados pueden ser favorables, un escenario simulado no ofrece con exactitud los mismos factores de un escenario real, por lo que el aplicar este sistema en escenarios reales puede que no arroje los mismos resultados que se muestran anteriormente.

_________________________________________________________________________________
Referencias:
Dieu Thanh Nguyen and Joern Ostermann, "Congestion Control for Scalable Video Streaming Using the Scalability Extension of H.264/AVC", IEEE JOURNAL OF SELECTED TOPICS IN SIGNAL PROCESSING, VOL. 1, NO. 2, AUGUST 2007
Link al paper -> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04276656


martes, 9 de abril de 2013

Actividad #6 : Topologías de Redes con ns-2

Para esta vez la tarea es tratar de lograr topologías de redes parecidas a alguna forma conocida, formé esta con el simulador de ns-2, conocida como "estrella":


El código de ns-2 para lograr esta topología:



Para formar topologías nuevas, partiendo de la anterior, podemos crear los scripts de ns-2 desde un script de python que reciba unos cuantos parámetros y que posterior los ejecute.

Los scripts se crearían a partir de impresiones de texto archivos de txt con la extensión .tcl de ns-2, su ejecución podría ser con alguna llamada al sistema.

Partiendo de querer crear una topología de estrella, la idea podría ser esta:



La salida de este script es la misma que el script mostrado de ns-2, solo con cambios en el numero de nodos que se manejan.

Para crear otras topologías se pueden tomar como referencias otros patrones en la forma de conectar los nodos o inlcusive conectar todos los nodos de manera aleatoria a ver que sale :P.


martes, 26 de febrero de 2013

Actividad #4 - Métricas de Calidad de Servicio

El experimento que se realizó para la clase, LINK_EXPERIMENTO contempla las siguientes métricas para medir la calidad de servicio de la conexión a internet.

Latencia o ping
Se puede explicar como el tiempo de respuesta entre dos puntos cuando se están enviando paquetes, que puede ocurrir debido a que toman la ruta menos corta para llegar al destino, que toman una ruta muy congestionada o también debido a su posición en las colas de envío/recepción.

Latencias muy grandes pueden resultar en pérdidas de conexión, especialmente durante una sesión de excesiva transmisión de datos como, llamadas VoIP, juego online, videos en streaming, etc.

Durante el experimento las latencias obtenidas con ping, era muy alto, tal vez por eso la sesión de hangout se cortaba a cada rato y aunque se recuperaba la conexión se volvía a perder.

Cantidad de paquetes perdidos
Se refiere a la cantidad de paquetes que tras ser enviados, no llegan a su destino debido a errores durante la encapsulación o a una incorrecta ruta de destino.

Esto se puede ver reflejado en llamadas VoIP como deformaciones/errores/manchas en la imagen o ruidos extraños en las voces. (al menos eso fué lo que me paso a mi :P).

Estas manchas o píxeles de colores estuvieron presentes la mayoría de la sesión del experimento.

Jitter
Los paquetes enviados desde cierta parte pueden llegar con diferentes retrasos hacia su destino, este retraso varía dependiendo de la posición del paquete en la cola que se va formando durante una transmisión de datos.
Según wikipedia, jitter se le denomina a la forma en que varía temporalmente el envío de señales digitales.
Básicamente es un cambio indeseado de cierta señal, que se considera como un ruido que afecta a esta señal provocando retraso en la recepción de los paquetes.

En el experimento esto se veía reflejado como lag durante la videollamada de hangout, la imagen se movía más lento de lo normal y la voz no iba acorde al movimiento de los labios, estaba muy retrasado y desfasado.

Una posible solución a esto, es la de crear un pequeño buffer de los paquetes y mostrarlos con un retraso para tener algo mas normalizado, pero contando con un retraso para poder obtener y organizados todos o la mayoría de los paquetes

_________________________________________________________________________________
Referencias:
http://en.wikipedia.org/wiki/Quality_of_service
http://www.ciscopress.com/articles/article.asp?p=357102
http://www.slideshare.net/prestonj_jag/calidad-de-servicio-en-redes


lunes, 18 de febrero de 2013

Actividad #3 Lab: Coberturas de WiFi

Para esta entrada la actividad era monitorear la cobertura de las señales wifi disponibles en un punto "público", yo lo realice cerca de mi casa, donde había una buena cantidad de señales wifi.

Utilicé un dispositivo móvil con android para poder checar mejor la cobertura de las señales y poder tener un aproximado de su ubicación para poder dibujarlos en un mapa de google.

En el dispositivo móvil me apoye de una app llamada Wifi Analyzer que ayuda a mostrando la intensidad y la calidad de las redes wifi, además de otra información como el canal en que se difunde la señal, tipo de seguridad, etc. Si a alguien le interesa la app, aquí dejo el link a google play: Wifi Analyzer.

Aquí dejo unas capturas de la app funcionando, donde se muestra las intensidades de las distintas redes e información como la calidad, nombre, intensidad, etc.

intensidades de las señales disponibles


información más detallada de las redes disponibles


Y aquí una imagen del mapa de google con las coberturas de las redes dibujadas encima (con posiciones aproximadas):



lunes, 4 de febrero de 2013

Actividad #1 Laboratorio - Estándares

               USB 3.0           vs             Thunderbolt


  


Hace poco tiempo hubo una pequeña disputa por establecer cual estándar de estos dos posibles, reemplazaría al ya conocido USB 2.0. Este sustituto debería de reemplazar totalmente al anterior USB 2.0 en todos sus aspectos y debería de ser capaz de mejorarlos inclusive ofrecer nuevas opciones.

Cada uno defendía sus características (mas adelante las menciono), pero las mas importantes que tenían eran que los USB 3.0 físicamente son iguales a los USB 2.0 por lo que ofrecen retro-compatibilidad sin modificar nada (con la restricción de las limitaciones del USB 2.0) y los Thunderbolt físicamente son iguales a los puertos display-port, pero no ofrecen retro-compatibilidad con puertos que no esten preparados con esta nueva tecnología.

Características USB 3.0 (en cuanto a transferencias de datos)
Es la segunda revisión que se le hace a este periferico, diseñada en el 2008:

  • En la primera versión(USB 1.0) las velocidades iban de 1.5Mbits/s hasta 12Mbits.
  • En la segunda versión(USB 2.0) las velocidades se actualizaron e introdujeron un nuevo sistema llamado Hi-Speed que alcanzaba los 480Mbits/s.
  • En la tercera versión se actulizaron otra vez las velocidades con nuevo sistema llamado Super-Speed y ahora alcanzan los 5Gbits/s.


Características Thunderbolt (transferencias de datos)
Fue lanzado en Febrero del 2011, principalmente en computadoras de Apple, ya que es más común el puerto display-port en estas computadoras.

Su velocidad de transmisión máxima es de 10Gbits/s, el doble del estandar USB 3.0 donde aparentemente le lleva ventaja.



Comparaciones y Conclusiones
El detalle está en sus velocidades de transmisión de datos, ya que los dos hacen prácticamente las mismas cosas.
Aparentemente en este apartado el Thunderbolt tendría la ventaja, pero debido a que su implementación generalmente solo es en computadoras Apple su mercado se reduce.

El USB 3.0 aún con menos velocidad de transferencia, su mercado puede ser más grande debido a que puede implementarse en cualquier computadora o dispositivo. Además del plus del poder contar la opción de seguir utilizando tus conexiones USB 2.0.

En un artículo que hace tiempo leí (no recuerdo su nombre ni donde fue) decía que el USB 3.0 originalmente no se llamaría así, si no que usaría otro nombre raro, pero que se declinó esta idea debido a que sería más factible para el usuario final relacionarlo con USB 2.0 y sus funcionalidades. Además de que lo verían como una actualización y no como un nuevo dispositivo.

En conclusión, actualmente el USB 3.0 sigue ganando terreno al Thunderbolt que yo personalmente solo lo he visto en computadoras Apple, la retro-compatibilidad con USB 2.0 ayuda mucho ya que no tenemos que deshacernos de nuestros dispositivos con este estándar en caso de hacernos de esta nueva tecnología o comprar nuevos dispositivos.
Yo creó que al final Thunderbolt es una buena opción pero desaparecerá.

Las empresas deberían de trabajar más en conjunto y no tanto individualmente como lo vienen haciendo para mejor este tipo de cosas. Se podría crear un apartado en la comisión que regula este tipo de cosas que cancele o anule la incursión de nuevos dispositivos/perifericos que se asemejen a alguno ya existente.

_________________________________________________________________________________
Referencias:
http://en.wikipedia.org/wiki/USB_3.0
http://en.wikipedia.org/wiki/Thunderbolt_(interface)