Redes Inalambricas

domingo, 14 de diciembre de 2014

Bibliografia

http://es.scribd.com/doc/215589760/Nuevas-tecnologias-inalambricas
http://upload.wikimedia.org/wikipedia/commons/e/e3/Fr_cir.PNG
http://es.wikipedia.org/?title=Modelo_TCP/IP
http://www.it.uc3m.es/jmoreno/cursos_verano/2003/4_redes4G.pdf
http://html.rincondelvago.com/redes-frame-relay.html
http://madaoradio.galeon.com/73.html
http://www.um.edu.ar/catedras/claroline/backends/download.php?url=L0FUTV9JbmcuX0FyZXMvMTExMi5wZGY%3D&cidReset=true&cidReq=IT002
http://html.rincondelvago.com/redes-frame-relay.html
http://madaoradio.galeon.com/62.html
http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_tr%C3%A1fico
http://trevinca.ei.uvigo.es/~mdiaz/rdo01_02/tema12.pdf
http://10380054.blogspot.mx/2012/11/44-celdas-atm.html
http://www2.rhernando.net/modules/tutorials/doc/redes/atm.html
http://www.it.uc3m.es/jmoreno/cursos_verano/2003/4_redes4G.pdf
http://www.zonamovilidad.es/noticia/2430/Reportajes/La-necesidad-de-WiFi-4G.html
http://www.tyr.unlu.edu.ar/tyr/TYR-2005/TCPW.pdf
http://es.wikipedia.org/wiki/Red_de_sensores

Uno de los algoritmos de encaminamiento más conocido, es el llamado inundación, donde cada nodo envía la información que desea mandar a todos sus vecinos, sin considerar si estos ya la recibieron por otra ruta. Este comportamiento puede llevar rápidamente a provocar una implosión en la cantidad de mensajes ni bien la red se torne más compleja para reflejar situaciones del mundo real. Uno de los comportamientos que se puede pensar para limitar esta implosión es no enviar el mensaje al nodo del cual se recibió, no enviar un mensaje ya enviado con anterioridad, o alguna otra acción que acote la cantidad de mensajes enviados.

Otra técnica de encaminamiento habitualmente usada en los algoritmos, se basa en buscar un camino óptimo mediante el ajuste de algunas características, como ser cantidad de saltos, máximo ahorro de energía, máxima calidad de comunicación.

Las redes de sensores inalámbricas deben manejarse con algoritmos que gasten lo menos posible de energía. En una red la mayor parte de la energía se consume durante la transmisión de datos de un nodo a otro y por lo tanto se buscan técnicas que minimicen la cantidad y el tamaño de los mensajes.

En estos algoritmos lo fundamental son los datos a transmitir. Por ese motivo se los califica como centrados en datos (DC). Sobre ellos es posible realizar algún procesamiento de las variables censadas aplicando agregación, limitando de esta forma, la información a transmitir para lograr algún ahorro de energía.

Otras redes trabajan con algoritmos centrados en direcciones, donde cada nodo tiene definido a que vecino dentro de la red, debe enviar los datos. Cuando tiene información para transmitir, lo hace sin analizar si el mensaje es significativo para los objetivos de la red. Por ejemplo, considerar si es correcto enviar un mensaje ya enviado, o si es posible que la transmisión dure menos tiempo, para mejorar la funcionalidad y lograr mayor performance. Estas redes no presentan en general restricciones de energía y por lo tanto el análisis sobre cantidad de mensajes enviados o consumo de potencia no es problema para ellas.

Unidad 6 Redes Inalámbricas de Sensores

6.1 Ejemplos de Redes de Sensores

Una red de sensores es una red de [Computadora [ordenadores]] pequeñísimos («nodos»), equipados con sensores, que colaboran en una tarea común.

Las redes de sensores están formadas por un grupo de sensores con ciertas capacidades sensitivas y de comunicación inalámbrica los cuales permiten formar redes ad hoc sin infraestructura física preestablecida ni administración central.

Las redes de sensores es un concepto relativamente nuevo en adquisición y tratamiento de datos con múltiples aplicaciones en distintos campos tales como entornos industriales, domótica, entornos militares, detección ambiental.

Esta clase de redes se caracterizan por su facilidad de despliegue y por ser auto configurables, pudiendo convertirse en todo momento en emisor, receptor, ofrecer servicios de encaminamiento entre nodos sin visión directa, así como registrar datos referentes a los sensores locales de cada nodo. Otra de sus características es su gestión eficiente de la energía, que les permite obtener una alta tasa de autonomía que las hace plenamente operativas.

Pasando de largo las aplicaciones militares, éstas tienen usos civiles interesantes como vemos a continuación:

Eficiencia energética: Red de sensores se utilizan para controlar el uso eficaz de la electricidad, como el caso de Japón y España.
Entornos de alta seguridad: Existen lugares que requieren altos niveles de seguridad para evitar ataques terroristas, tales como centrales nucleares, aeropuertos, edificios del gobierno de paso restringido. Aquí gracias a una red de sensores se pueden detectar situaciones que con una simple cámara sería imposible.
Sensores ambientales: El control ambiental de vastas áreas de bosque o de océano, sería imposible sin las redes de sensores. El control de múltiples variables, como temperatura, humedad, fuego, actividad sísmica así como otras. También ayudan a expertos a diagnosticar o prevenir un problema o urgencia y además minimiza el impacto ambiental del presencia humana.
Sensores industriales: Dentro de fábricas existen complejos sistemas de control de calidad, el tamaño de estos sensores les permite estar allí donde se requiera.
Automoción: Las redes de sensores son el complemento ideal a las cámaras de tráfico, ya que pueden informar de la situación del tráfico en ángulos muertos que no cubren las cámaras y también pueden informar a conductores de la situación, en caso de atasco o accidente, con lo que estos tienen capacidad de reacción para tomar rutas alternativas.
Medicina: Es otro campo bastante prometedor. Con la reducción de tamaño que están sufriendo los nodos sensores, la calidad de vida de pacientes que tengan que tener controlada sus constantes vitales (pulsaciones, presión, nivel de azúcar en sangre, etc.), podrá mejorar sustancialmente.
Domótica: Su tamaño, economía y velocidad de despliegue, lo hacen una tecnología ideal para domotizar el hogar a un precio asequible.

5.4.4 Control de Flujo en TCP

TCP permite que el tamaño de la ventana varíe en el tiempo.
Cada reconocimiento, que especifica cuántos bytes han sido recibidos, contiene un campo llamado
ventana_receptor
(WINDOW), que especifica cuántos bytes adicionales el receptor puede recibir (especifica el tamaño del buffer del receptor).
Un aumento en el valor del campo ventana_receptor el emisor incrementa el tamaño de su ventana, por lo que transmite un mayor número debytes.
Una disminución en el valor del campo ventana_receptor el emisor decrementa el tamaño de su ventana, disminuyendo así, el número de bytesa transmitir.
TCP provee un mecanismo de Control de Flujo punto a punto.
Si el buffer del receptor comienza a llenarse, envía un tamaño de ventana menor.
En el caso extremo, un tamaño de ventana = 0 detiene la transmisión.
No controla explícitamente problemas de congestión.
Una buena implementación de TCP (en particular, el esquema de ReTx) puede detectar y recuperarse de problemas de congestión, mientras que una mala lo empeora.

5.4.3 Control de congestión en TCP

El método utilizado por TCP para control de la congestión es el basado en la regulación del tráfico inyectado a la red. Esto supone que implementa funciones que le permiten estudiar cuándo es posible enviar más tráfico por el enlace, y cuándo se ha superado la capacidad del mismo y se debe disminuir la carga.

TCP emplea 4 algoritmos relacionados entre sí a los efectos de efectuar el control de congestión. Ellos son conocidos con slow start, congestion avoidance, fast retransmit y fast recovery.

Los algoritmos slow start y congestión avoidance, deben ser utilizados por la fuente TCP a los efectos de controlar la cantidad de tráfico inyectado en la red.

Para esto se cuenta con tres variables de estado del protocolo. Estas son cwnd (congestión window), que controla del lado de la fuente la cantidad de datos que se puede enviar sin haber recibido un ACK, rwnd (receiver’s advertised window) que indica la cantidad de datos que puede recibir el destino y ssthresh (slow start threshold) que indica en qué fase de control de congestión se encuentra el transmisor (slow start si es mayor que cwnd o congestion avoidance si es menor; de ser iguales, se puede utilizar cualquiera de los dos algoritmos). El mínimo de cwnd y rwnd gobierna la transmisión. El algoritmo slow start es utilizado al comienzo de una transmisión a los efectos de que TCP pueda testear la red y conocer su capacidad evitando congestionarla. También es utilizado en el momento de recuperación ante la pérdida de algún segmento, indicada por timeout. Luego del three-way handshake, el tamaño de la ventana inicial de envío (IW: initial window) debe ser menor o igual que 2 x SMSS1 bytes y no mayor a dos segmentos. El valor de ssthresh debería ser lo más alto posible al comienzo (por ejemplo, igual a rwnd) y deberá reducirse en caso de congestión. Durante la fase slow start se aumenta cwnd en a lo sumo SMSS bytes por cada ACK recibido de datos nuevos entregados al receptor. Esta fase culmina cuando cwnd alcanza a ssthresh o cuando se detecta congestión.

A partir de allí se inicia la fase de congestión avoidance donde cwnd se incrementa en un segmento por round-trip time (tiempo que transcurre entre que sale un segmento y llega el ACK asociado). Esta fase continúa hasta que se alcanza la congestión nuevamente.

Durante la fase de congestión avoindance, la actualización de la variable cwnd, se realiza con la siguiente fórmula:

Cwnd = cwnd + SMSS x SMSS / cwnd (1) calculándose cada vez que llega un ACK no duplicado.

Cuando el transmisor detecta la pérdida de un segmento, a partir del timer de retransmisión, el valor de ssthresh debe pasar a ser:

Ssthresh = max (FS / 2, 2 x SMSS) (2) siendo FS (Flight Size) la cantidad de datos enviados pero aún no reconocidos o ACKed. Al mismo tiempo, cwnd no puede ser mayor que LW (Loss Window) que vale 1 segmento y sin importar el valor de IW. Se identifica con LW al tamaño de cwnd luego de detectar, a través del timer de retransmisión, una pérdida.

Posteriormente se pasa a la fase de slow start hasta alcanzar el ssthresh y luego se seguirá con la fase congestión avoidance. Cuando se detecta la primera pérdida en una ventana de datos, mientras no se reparen todos los segmentos de dicha ventana, la cantidad de segmentos transmitidos en cada RTT no podrá ser mayor a la mitad de los segmentos salientes cuando la pérdida fue detectada. Luego que todos los segmentos fueran exitosamente retransmitidos, cwnd no podrá tomar un valor mayor a ssthresh y la fase siguiente será congestión avoidance. Pérdidas en dos ventanas de datos sucesivas o en retransmisiones indica congestión e implica que cwnd y ssthresh deben bajar dos veces.

El receptor TCP debería enviar inmediatamente un ACK duplicado si recibe un segmento fuera de orden. Con ello busca informar al transmisor el número de secuencia esperado. Las conclusiones a las que puede arribar el transmisor ante la llegada de ACK duplicados pueden ser varias. Primero, puede concluir que está ante la presencia de segmentos descartados; segundo, que por razones de tránsito en la red, los segmentos están llegando en desorden al receptor y tercero, que ocurre por duplicación de los segmentos o de los ACKs en la propia red. El receptor también debería enviar inmediatamente un ACK para aquel segmento que recibe y que se encuentra en el hueco del espacio de número de secuencia esperado de forma de colaborar con el transmisor.

El algoritmo fast retransmit debería ser utilizado para detectar y reparar pérdidas basado en la recepción de ACK duplicados. El algoritmo emplea la recepción de 3 ACK duplicados (4 ACKs idénticos) para concluir que un segmento se ha perdido. El transmisor envía el segmento que deduce se ha perdido sin esperar que expire el timer de retransmisión, sstresh toma el valor dado por la ecuación (2) y cwnd toma un valor dado por la ecuación:

Cwnd = ssthresh + 3 x SMSS (3) (lo que se conoce como inflado artificial de cwnd). Esto hace crecer cwnd en la cantidad de segmentos (ACK en este caso) que abandonaron la red. Un criterio similar seguirá por cada ACK duplicado recibido. Luego de ello, el algoritmo fast recovery gobierna la transmisión mientras no se reciban nuevos ACK duplicados. De ser posible (según los valores de cwnd y rwnd), se transmite un nuevo segmento y ante la llegada de un ACK de datos nuevos lleva el valor de cwnd al de ssthresh (lo que se conoce como desinflado de cwnd). El no pasar a la fase de slow start ante la pérdida del segmento se justifica en el hecho de que la llegada de ACK duplicado implica que quien lo envió recibió un segmento, por lo tanto, hay segmentos que están abandonando la red y por lo tanto dejan de consumir recursos en ella.

Estos algoritmos no se comportan adecuadamente ante pérdidas múltiples en un “single flight” de segmentos lo que motivó el desarrollo de un conjunto de implementaciones adicionales. Para calcular el RTO actual, el transmisor mantiene 2 variables de estado llamadas SRTT (smothed round-trip time) y RTTVAR (round-trip time variation). Mientras no se calcule un RTT, el mismo debe valer como máximo 3 segundos. Cuando se calcula el primer RTT (R), las variables tomarán los siguientes valores:

SRTT = RRTTVAR = R/2 RTO = SRTT + max (G, K x RTTVAR) donde K = 4 y G es la granularidad del reloj, medida en segundos.

Para el siguiente cálculo de RTT (R') los nuevos valores de las variables serán:

RTTVAR = (1 - β) x RTTVAR + β x |SRTT - R'| SRTT = (1 - α) x SRTT + α x R' donde los valores de α y β deberían ser 1/8 y ¼ respectivamente.

RTO = SRTT + max (G, K x RTTVAR) RTO no debería ser menor que 1 ni mayor que 60 segundos.

La toma de las muestras RTT se debe realizar utilizando el algoritmo de Karn. Ello implica que no debe hacerse utilizando segmentos retransmitidos (salvo que se utilice la opción timestamp) y que en caso de expirar, se debería retransmitir el primer segmento no ACKed y efectuar un backoff, pasando RTO a valer el doble y lanzarlo nuevamente. Se debe realizar como mínimo una medida por round-trip time de forma de evitar el efecto de aliasing2 en el cálculo de RTO para el caso de ventanas de congestión grandes.

5.4.2 El Problema de Movilidad con TCP

En la presente sección, presentaremos algunos de los problemas existentes en la implementación de conexiones TCP sobre enlaces Wireless.

Los problemas existentes se basan en la incapacidad de TCP de discriminar cuándo la performance de la conexión ha disminuido debido a pérdidas en el enlace, común en las tecnologías wireless, y cuándo es debida a congestión en la red. El problema radica en que el transmisor no puede determinar con cierto grado de certeza qué ha motivado la pérdida de un segmento.

Cuatro aspectos inherentes a redes Wireless pueden afectar decisivamente la performance de TCP . Por un lado, la bit error rate (BER) del medio físico, que como ya mencionamos, puede ser del orden de 1x10-6 o peor. En segundo lugar debemos considerar que el ancho de banda disponible es en general menor al disponible en medio cableados. Una tercer componente es la posible movilidad de los componentes de la red lo que puede implicar cambios importantes en los tiempos de entrega de los segmentos. Finalmente, es común que el protocolo de capa de Enlace y en particular de la sub-capa MAC así como el protocolo de enrutamiento utilizado implique necesariamente tener un overhead asociado a la movilidad y al aumento en la probabilidad de pérdida de tramas o paquetes.

A los efectos de fijar ideas podemos considerar como ejemplo de protocolo de sub-capa MAC a la familia de estándares de IEEE para Wireless Local Area Network (WLAN) [26, 27, 28, 29, 30]. En ellos se especifica que para el envío de cada trama de datos en el modo de operación Distributed Coordination Function (DCF) se emplee un método de control de acceso al medio Denominado carrier sense multiple access with collision avoidance (CSMA/CA), protocolo que busca reducir la probabilidad de colisiones entre múltiples estaciones a través del evitado de las mismas. A los efectos de detectar portadora, además del mecanismo clásico de “escucha del medio” (detección física de portadora) se realiza una detección virtual de portadora utilizando four-way handshake, donde con dos tramas de control (RTS: Request To Send y CTS: Clear To Send) se reserva el medio, luego se envía la trama conteniendo los datos y posteriormente se espera una trama de control ACK que confirma su recepción. Lo anterior es una muestra clara del overhead involucrado, pero hasta aquí no hemos considerado la movilidad de las estaciones. Durante la misma, una estación móvil puede estar asociada a una estación base (BS) a través de la cual recibe las tramas que provienen por ejemplo de la red cableada y unos mili segundos después, deberá estar asociada a otra estación base a la cual la primera deberá enviar las tramas que tuviera almacenadas para dicha estación.

5.4.1 El protocolo TCP/IP

El modelo TCP/IP es un modelo de descripción de protocolos de red desarrollado en los años 70 por Vintén Cerf y Robert E. Kahn. Fue implantado en la red ARPANET, la primera red de área amplia, desarrollada por encargo de DARPA, una agencia del Departamento de Defensa de los Estados Unidos, y predecesora de la actual red Internet. EL modelo TCP/IP se denomina a veces como Internet Model, Modelo DoD o Modelo DARPA. El modelo TCP/IP, describe un conjunto de guías generales de diseño e implementación de protocolos de red específicos para permitir que un equipo pueda comunicarse en una red.

TCP/IP provee conectividad de extremo a extremo especificando cómo los datos deberían ser formateados, direccionados, transmitidos, enrutados y recibidos por el destinatario. Existen protocolos para los diferentes tipos de servicios de comunicación entre equipos. TCP/IP tiene cuatro capas de abstracción según se define en el RFC 1122. Esta arquitectura de capas a menudo es comparada con el Modelo OSI de siete capas. El modelo TCP/IP y los protocolos relacionados son mantenidos por la Internet Engineering Task Force (IETF). Para conseguir un intercambio fiable de datos entre dos equipos, se deben llevar a cabo muchos procedimientos separados. El resultado es que el software de comunicaciones es complejo. Con un modelo en capas o niveles resulta más sencillo agrupar funciones relacionadas e implementar el software de comunicaciones modular. Las capas están jerarquizadas. Cada capa se construye sobre su predecesora. El número de capas y, en cada una de ellas, sus servicios y funciones son variables con cada tipo de red. Sin embargo, en cualquier red, la misión de cada capa es proveer servicios a las capas superiores haciéndoles transparentes el modo en que esos servicios se llevan a cabo. De esta manera, cada capa debe ocuparse exclusivamente de su nivel inmediatamente inferior, a quien solicita servicios, y del nivel inmediatamente superior, a quien devuelve resultados.

Capa 4 o capa de aplicación: Aplicación, asimilable a las capas 5 (sesión), 6 (presentación) y 7 (aplicación) del modelo OSI. La capa de aplicación debía incluir los detalles de las capas de sesión y presentación OSI. Crearon una capa de aplicación que maneja aspectos de representación, codificación y control de diálogo.
Capa 3 o capa de transporte: Transporte, asimilable a la capa 4 (transporte) del modelo OSI.
Capa 2 o capa de Internet: Internet, asimilable a la capa 3 (red) del modelo OSI.
Capa 1 o capa de acceso al medio: Acceso al Medio, asimilable a la capa 2 (enlace de datos) y a la capa 1 (física) del modelo OSI.