Funcionamiento Protocolo WiFi
IEEE 802.11
¿Por qué no funciona bien nuestra red wifi?
¿Por qué tenemos problemas, si disponemos de muchos AP’s y SSID’s, para segmentar y aislar correctamente las redes?
¿Tenemos un problema de cobertura?
Muchas empresas se hacen estas preguntas cuando tienen problemas en sus redes WiFi. Para desplegar redes WiFi correctamente, primero hay que entender cómo trabaja internamente el protocolo 802.11, en el que se basan.
Desde A16BIT, con este breve resumen, intentamos explicar de la forma más sencilla posible, el funcionamiento de dicho protocolo, para poder entender, el porqué de los problemas que se generan normalmente en estas redes.
Antes de entrar en materia, dejemos claros unos términos:
AP: Access Point
SSID: Service Set Identifier
802.11
802.3
Ethernet
Site Survey
Siempre se achaca el problema de las redes WiFi, a un problema en la cobertura, y como veremos, este es muchas veces, el menor de los problemas.
La mayoría de las veces, el problema es una mala planificación del despliegue, una mala configuración, o problemas en la electrónica de red, que conecta las redes WiFi con el “mundo” (por ejemplo, que la salida a internet esté saturada, etc.).
Entrando en materia…
Debido a que las redes WiFi, son posteriores a las redes cableadas basadas en el protocolo Ethernet, se aprovecharon los protocolos existentes para dichas redes cableadas, y modificándolos para entornos no cableados, se creó el nuevo protocolo 802.11.
Así pues, el 802.11, se basa en su predecesor el: 802.3 para redes cableadas, en el cual se describe el CSMA/CD (Carrier Sense Multiple Access / Collision Detection). CSMA/CD, es el algoritmo de acceso al medio compartido en el que se basan estas redes, y, por tanto, también las redes WiFi.
¿Cómo funciona CSMA/CD?
Cuando un equipo A desea transmitir una información, escucha primero si hay otro equipo transmitiendo. En caso de no haber ninguno haciéndolo, comienzan a transmitir, pero se mantiene a “la escucha”, por si otro equipo B se pusiera a transmitir también mientras dura su transmisión. En caso de que esto pase, el equipo A, supone que ha habido una colisión, e inmediatamente deja de transmitir, y difunde una señal especial (Jamming), para decir a todos los equipos que estén escuchando, que descarten el paquete de información transferida. Después de esta colisión, A, espera un tiempo aleatorio, antes de intentar volver a transmitir la información, y el proceso se vuelve a iniciar, tantas veces como sea necesario, para que el paquete de información se transmita correctamente.
El hecho de que múltiples redes compartan un medio puede provocar y provoca, que, aunque escuchemos para intentar asegurarnos de que somos los únicos que vamos a transmitir en nuestra red, otro equipo de otra red, pero que comparta el medio, se ponga a transmitir y provoque una colisión.
En WiFi, nuestro medio será el AIRE. Y la frecuencia a la que modulemos la señal en el aire, dentro del espectro de 2,4 GHz o 5 GHz, será el CANAL.
Debido a que fabricar receptores/emisores WiFi (AP’s), que transmitan y reciban de forma simultánea, tiene un coste muy elevado, el protocolo 802.11 en el que se soporta WiFi, no utiliza CSMA/CD, sino que utiliza: CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance), o lo que es lo mismo, evasión de colisiones. La diferencia principal entre CSMA/CD y CSMA/CA, radica precisamente en la detección de colisiones, ya que, en el AIRE, es muy difícil detectar una colisión, tal y como se hace en los entornos cableados, con lo cual, siempre se intentarán evitar dichas colisiones.
¿Cómo funciona CSMA/CA?
Cuando un equipo A desea transmitir una información hacia un equipo B, lo primero que hace es mirar si el canal (canal WiFi en este caso), está libre; si lo está, espera un tiempo predeterminado de 50ms (se conoce como DIFS), y comienza a transmitir. De esta forma, se asegura, que cualquier trama emitida en la red, por el medio aéreo, irá separada de otra, un mínimo de 50 milisegundos.
Una vez A, ha terminado de transmitir su trama, espera una confirmación de B (se conoce como ACK), pero como dicha confirmación es un mensaje que se considera prioritario, y por tanto tiene preferencia, A solo esperará 10 milisegundos a recibir dicha confirmación (este tiempo se conoce como SIFS).
Si A recibe la confirmación de B, todo ha ido bien y el proceso ha sido rápido y ha concluido para ese paquete. (Recordemos, que una transmisión estará compuesta de muchísimos paquetes). Si, por el contrario, A no recibe de B el ACK, deberá volver a comenzar el proceso de envío.
Supongamos ahora, que, en algún momento, durante la transmisión de A hacia B, otro equipo C, quiere también realizar una transmisión a un equipo D. Cuando C, antes de empezar el proceso de transmisión, escuche el canal para ver si está ocupado, detectará que, si lo está, y se esperará sin iniciar el proceso, hasta que la actual transmisión entre A y B finalice.
Cuando la transmisión entre A y B concluya, C, que seguía a la escucha esperando turno, detectará el canal vacío y comenzará la espera de 50ms (DIFS), para empezar a transmitir hacia D. No obstante, C, detectará la confirmación (ACK) de B hacia A, a los 10ms (SIFS), con lo que, C volverá a iniciar la espera de 50ms (DIFS), para empezar a transmitir.
Cuando la transmisión de A hacia B ha concluido, con ACK incluido, por fin, C puede empezar a transmitir hacia D, después de esperar los 50ms en los que no ha escuchado nada en el canal, pero: ¡NO LO HARA! …, C no transmitirá de inmediato, sino que comenzará el denominado algoritmo de Backoff. El algoritmo de Backoff, determina otro tiempo de espera adicional, en milisegundos, que es aleatorio entre un intervalo mínimo (CWmin), y máximo (CWmax). A este intervalo se le conoce como Ventana de Contienda (CW).
Así pues, el algoritmo de Backoff, dará, como hemos dicho, un número entero y aleatorio, que será el tiempo en milisegundos, que C deberá esperar de forma adicional, para poder empezar a transmitir.
La finalidad del algoritmo de Backoff, teniendo en cuenta que nuestro medio es el AIRE, y que nuestros CANALES son finitos, es el de reducir la probabilidad de colisiones, con otros equipos que también quieran transmitir, y que también estén observando el proceso entre A y B, y esperando su turno.
Llegados a este punto, podemos entender ya, porque es mejor trabajar a 5GHz que a 2,4GHz, debido a que, el número de canales del que disponemos, sin solapamiento, es mucho mayor.
Pero ¿Qué pasa con C, que todavía no ha conseguido transmitir?: Si durante los milisegundos que ha determinado el algoritmo de Backoff, no escucha nada, al finalizar dicho tiempo, C, por fin podrá transmitir; no obstante, si durante el tiempo de Backoff, SI escucha algo, congelará el contador de Backoff donde esté en la cuenta atrás, y esperará a no volver a escuchar nada en el canal. Cuando de nuevo haya silenció, esperará los 50 milisegundos (DIFS), y si todo sigue en silencio, descongelará el contador de Backoff, y seguirá el decremento, hasta llegar a 0 y poder transmitir.
Como se deduce del proceso, para poder llegar a transmitir, es realmente largo y tedioso, y aun así, no se garantiza que no haya colisiones.
¿Qué pasa pues con las colisiones?:
Una colisión se produce, cuando dos o más equipos que esperan, sacan el mismo número aleatorio en el algoritmo de Backoff. Cuando estos equipos lleguen a 0 y transmitan, solo uno de ellos recibirá el ACK, o tal vez ninguno, y, por tanto, ya que no pueden detectar las colisiones en el aire, entenderán que ha habido una colisión y comenzarán de nuevo todo el proceso. No obstante, como se trata del segundo intento de transmisión, el equipo ampliará el intervalo de Backoff, para la elección del tiempo aleatorio.
El número de intervalos de Backoff, crece de forma exponencial, hasta que se consigue transmitir, o hasta que se llega a un valor máximo, después del cual, sin haber transmitido aún, todo el proceso vuelve a comenzar de nuevo.
Como se puede observar, el proceso es parecido al de Ethernet, salvo que los equipos no detectan las colisiones, sino que deducen que se han producido, al no recibir el ACK, y reinician sus procesos de transmisión.
También se producen colisiones, cuando dos o más equipos, deciden empezar a transmitir a la vez o casi a la vez.
Además de todo esto, en entornos inalámbricos, CSMA/CA, tiene otros dos problemas:
- Equipo Oculto: Un equipo cree que un canal está libre, pero en realidad no lo está, debido a que el equipo no lo está oyendo.
- Equipo Expuesto: Un equipo cree que un canal está ocupado, pero en realidad está libre, ya que lo que oye, no le interferiría para transmitir a otro destino.
Estos dos casos se dan normalmente, con equipos que emiten y reciben con diferentes potencias de señal o capacidades de recepción.
Dos ejemplos: Equipo Oculto se daría, cuando un equipo A quiere transmitir a B, y cree que hay silencio porque no escucha nada, pero en realidad, hay un equipo C, más cerca de B que de A, que si está transmitiendo en ese momento a B, pero que por distancia, A no está escuchando. Equipo Expuesto se daría, cuando un equipo A quiere transmitir a B, y cree que no puede, porque está oyendo transmitir a C; lo que no sabe, es que B no está escuchando a C por distancia, y por tanto la transmisión de A hacia B, no se vería afectada por lo que A está escuchando de C.
La solución que 802.11 da a los problemas de Equipo Oculto y Equipo Expuesto, es MACA (MultiAccess Collision Avoidance). MACA complementa a CSMA/CA, con el intercambio de mensajes RTS (Request to Send), y CTS (Clear to Send).
Antes de transmitir, el equipo emisor, envía al equipo receptor, una trama RTS, indicándole la longitud de los datos que le quiere enviar; a su vez, el receptor, le responde con una trama CTS, repitiendo la longitud. Cuando el emisor recibe correctamente el CTS, y todo lo visto hasta ahora se cumple, la transmisión comienza.
¿Cómo ayuda MACA a los problemas de Equipo Oculto y Equipo Expuesto? Pongamos un ejemplo: Cuando A le envía a B la trama RTS, C no recibe está trama por distancia, pero cuando B responde a A, con la trama CTS, C si escucha esta trama, que contiene también la longitud de lo que se va a enviar, con lo que C, que sabe la velocidad de transmisión, y la longitud de lo que se va a transmitir, es capaz de deducir, el tiempo que va a tardar en realizarse dicha transmisión, y adaptar su tiempo de envío, para hacerlo en el momento en que haya silencio.
Otra solución que 802.11 da a los problemas de colisiones, es NAV (Network Allocation Vector). NAV es una variable, que contiene la predicción del tiempo en que el medio va a quedar libre para poder transmitir. Cuando se envían tanto las tramas RTS, como las CTS, se envía un campo que es: Duration/ID, que contiene en milisegundos, el tiempo reservado para la transmisión. Cuando los equipos reciben el Duration/ID, modifican su NAV, y tienen una estimación de cuando el medio quedará libre, pero el tiempo que ponen en su NAV, es siempre el mayor de todas las tramas que hayan escuchado.
Como se aprecia, aquí volvemos a tener muchos milisegundos de espera, en redes saturadas de equipos y redes (SSID’s).
Por último, otra solución que 802.11 da a los problemas de colisiones, es la Fragmentación y el Reensamblado. Debido a que por todo lo explicado hasta ahora, es altamente probable que una trama grande, al ser transmitida, no llegue correctamente a su destino, debido a colisiones, lo que hará el emisor, es fragmentar el paquete en paquetes mas pequeños, y el receptor, reensamblara dichos paquetes en la trama original. Esto se podrá conseguir, gracias a la información de RTS y CTS.
Cabe comentar que CSMA/CA, tiene mas mecanismos para optimizar 802.11, tales como: La Función de Coordinación Puntual, el Formato de Trama MAC, los Servicios Básicos de Gestión y Movilidad, la Gestión de Potencia, o la Sincronización, pero para entender porque las redes WiFi pueden funcionar mal, nos basta con lo explicado hasta ahora. Los mecanismos citados aquí, mejorarían cosas tales como: los tráficos prioritarios para Voz IP o Videoconferencia por ejemplo.
Como hemos visto, conseguir enviar y recibir tramas correctamente mediante WiFi, es un proceso complejo y lento, que va consumiendo milisegundos de forma exponencial, al número de equipos (AP’s y dispositivos) y de redes (SSID’s) existentes en el mismo medio (AIRE).
¿Qué es el Beacon Frame?
El Beacon Frame, es una trama, que cada AP emite a intervalos regulares de tiempo, para informar de que el AP está disponible, y que redes tiene (SSID’s). O lo que es lo mismo, que cada x milisegundos, cada AP, emite por cada uno de sus SSID, un Beacon Frame, dando información al medio, para que los equipos le puedan solicitar comunicarse con él.
El hecho de que muchos AP’s con múltiples SSID’s, convivan en un mismo medio, donde se están escuchando entre ellos, ya provoca una cantidad de tráfico muy importante, que llega a colapsar el medio, y a generar miles de colisiones por segundo, sin que todavía, ningún equipo haya llegado a transmitir.
Conclusión
El Beacon Frame, es una trama, que cada AP emite a intervalos regulares de tiempo, para informar de que el AP está disponible, y que redes tiene (SSID’s). O lo que es lo mismo, que cada x milisegundos, cada AP, emite por cada uno de sus SSID, un Beacon Frame, dando información al medio, para que los equipos le puedan solicitar comunicarse con él.
Para que una red WiFi funcione correctamente, hay que seguir las siguientes reglas básicas:
- Hacer un esquema de los AP’s a colocar y su posición, con un software de diseño como Ekahau, basándose en un plano, y marcando correctamente las zonas de atenuación. (Predictivo).
2. No colocar mas AP’s de los estrictamente necesarios, para dar una cobertura correcta en toda la zona a cubrir, ya sea sin alta disponibilidad, o con alta disponibilidad (mas de un AP cubriendo una misma zona).
3. Intentar, en la medida de lo posible, contener la señal WiFi de cada AP, a la zona donde queramos que dé cobertura, de manera, que su señal, no se extienda a grandes distancias, donde no nos interesa que ese AP irradie. Para ello, son buenos consejos, no colocar los AP’s en los pasillos o zonas muy despejadas, e incluso utilizar antenas direccionales, en vez de omnidireccionales.
4. Crear las mínimas redes posibles (SSID’s), para evitar tener el medio colapsado con el envío masivo de Beacon Frames.
5. Intentar, en la medida de lo posible, utilizar siempre el espectro de 5GHz, debido a que disponemos de mayor número de canales, sin solapamiento. En el caso de necesitar utilizar el espectro de 2,4GHz, por compatibilidad, o por capacidad de penetración, nunca utilizar canales distintos del 1, el 6 o el 11, ya que son los únicos que no se solapan entre ellos.
6. Dotar a la infraestructura WiFi, de una correcta electrónica de red, que la conecte con “el mundo”, de manera que no se generen cuellos de botella, que provocarían un aparente mal funcionamiento de la WiFi, sin ser el problema real.
7. Realizar un Site Survey final con Ekahau Sidekick, con la instalación realizada, para verificar el correcto funcionamiento y ajustar los parámetros o posiciones que sean necesarios.
Bibliografía
- Redes de Área Local Inalámbricas: Diseño de la WLAN de Wheelers Lane Technology College.
- Ekahau ECSE Survey Engineer Certification.
