Chapter 3 "Designing for Applications"

Aparte de la infraestructura y los clientes 802.11, hay que tener en consideración las aplicaciones que se utilizaran, al momento de diseñar una red Wi-Fi, ya que los requerimientos y restricciones que esta tenga van a guiar también el diseño, saltar los requerimientos por parte de la aplicación puede ser un riesgo, ya que esta se desempeñara en base a como se haya diseñado la red, por otra parte, quizás no todas las aplicaciones están hechas para un ambiente 802.11 por lo que hay que tener en consideración varios aspectos.

De esto trata el Capítulo 3 "Diseñando para Aplicaciones", la importancia técnica de estas las cuales influyen en el diseño.

Unas de los aspectos más importantes es conocer la aplicación y los protocolos que utiliza, por ejemplo, no es lo mismo una aplicación que utiliza un terminal WEB para levantar su servicio estático, que una aplicación que utiliza una terminal consola corriendo por debajo SSH o Telnet, esta última se puede ver fuertemente afectada a desconexiones Wi.-Fi, generando que la sesión que estableció la aplicación se caiga y se pierda el trabajo realizado, lo cual genera una molestia en el usuario. Usualmente encontramos este tipo de APP en servicio de bodega las cuales escanean códigos de barra para hacer un conteo o levantamiento de productos.

Si no tenemos muchos detalles de la aplicación que se utilizara, es mejor realizar un análisis de esta para seguir avanzando con el proyecto.

 

 

Aplicaciones en Tiempo Real (Real-time Applications)

En esta categoría encontramos dos tipos de servicio, Voz y Video, los cuales tienen diferentes formas de abordar al momento de diseñar una red Wi-Fi, usualmente cada fabricante tiene sus documentos de "Buenas Prácticas" o "Guías de Diseño", para implementar este tipo de aplicaciones en una red Wi-Fi, el libro no entrega una formula universal de cómo se debe diseñar una red Wi-Fi para servicios de voz, video o ambos, sino que, nos indica a que detalles debemos poner atención, especialmente detalles que tienen relación con:

• RSSI /SNR
• Data Rates
• Cambios en el Data Rate
• Roaming
• Cobertura y Zonas de roaming

Estos ítems se pueden abordar al momento de realizar un correcto Site Survey, el cual posteriormente debe ser analizado enfocándose en cada uno de estos puntos, adicionalmente se deben realizar pruebas con los endpoints para validar los procesos de roaming y desempeño de la aplicación.

El proceso de Roaming es uno de los puntos que más se profundiza, es importante indicar que siempre es el cliente quien decide cuando comenzar un proceso de roaming, por parte de la infraestructura se puede influenciar, pero este proceso es de exclusividad del cliente. Los fabricantes son quienes deciden cuando o bajo que parámetros el dispositivo ejecute el proceso, por ejemplo, cuando un dispositivo tenga un nivel de RSSI por debajo de -67dBm debe ejecutar el proceso, o puede ser que cuando el nivel de SNR sea menor a 25dB, o una mezcla de estos dos, por este motivo es importante tratar de averiguar con fabricante cuales son estos parámetros o umbrales.

 

 

Multicast

El manejo de multicas en Wi-Fi puede ser un poco complejo en 802.11 ya que no se comporta igual que en 802.3. Para Wi-Fi el tráfico multicas se comportaría como broadcast, bajo esta condición, se hace complejo el ACK de tramas que sean enviadas a clientes, a esto se le suma que un trafico multicas que es enviado como broadcast se va enviar a todos los clientes con un DataRates en especifico y puede ser que algunos clientes no puedan decodificar la trama debido a que son incapaces de “escuchar” al DataRates que se escogió para enviarla.

Para esto existen diferentes maneras de manejar tráfico multicas en Wi-Fi, para hacer más eficiente su distribución y a su vez usar el “tiempo aire” eficientemente, sin generar impacto en otros clientes:

•  IGMP Snooping Multicast: Se genera un grupo de clientes los cuales están dentro de la cobertura de un AP, por lo tanto, las tramas multicas se enviarán a APs que contengan este grupo de clientes. La trama multicas se enviará con el PHY más bajo.

• Convertir Multicast a Unicast: Las tramas multicas se envían como únicast a los clientes que la necesiten, así se enviara bajo un PHY que el cliente pueda escuchar y puede ser más optimo que enviar a un bajo PHY a muchos clientes.

• Multicast a Multicas PHY Optimizado.