Mi respuesta habitualmente tiende a ser más o menos la siguiente: lo que están buscando es un protocolo de prueba que en realidad debiera haberse definido en el momento de diseñar esa red inalámbrica. La red inalámbrica no es un ente teórico sino un despliegue de tecnología que se supone que debe responder a una necesidad o requerimiento de la organización que la implementa.
Es por esto que un buen diseño debiera incluir una prueba a ejecutar inmediatamente después de la implementación que verifique el cumplimiento de esos requerimientos.
Por lo tanto el inicio de toda verificación debiera ser una pregunta: "¿cuál es el requerimiento al que se está respondiendo?" La prueba debe diseñarse pensando en responder a ese requerimiento, no a parámetros puramente teóricos.
Es decir, no se trata de verificar parámetros puramente técnicos, sino el cumplimiento de objetivos específicos; muchas veces objetivos vinculados a la operación de la empresa, el desarrollo del negocio u otras áreas vinculadas.
Estas verificaciones debieran considerar al menos 4 elementos básicos.
1. ¿A qué dispositivos se desea dar conectividad?
No todos los dispositivos terminales inalámbricos operan exactamente igual.
La capacidad de de las terminales inalámbricas para conectarse a la red depende básicamente del hardware y el software con el que operan. Y hay diferencias muy significativas entre diferentes terminales, aún del mismo fabricante.
Las terminales pueden tener una sola radio (generalmente de 2,4 GHz) o dos radios (2,4 y 5 GHz); además, pueden estar dotadas de 1, 2 o 3 antenas; y su sensibilidad de recepción es diferentes (típicamente un smartphone tiene menor sensibilidad que una laptop).
Al mismo tiempo, pueden dar soporte a diferentes estándares, hoy, típicamente 802.11n, 802.11ac u 802.11ax, con diferentes anchos de canal, con diferente cantidad de cadenas de transmisión simultáneas.
Diferentes dispositivos, de diferentes fabricantes (o aún del mismo fabricante) pueden responder de modo diferente al conectarse a nuestra red. Esto es lo que explica porqué en muchas situaciones, dos dispositivos colocados uno junto al otro, conectados al mismo access point, presentan performances diferentes.
En este sentido es importante, entonces, que el diseño de la red inalámbrica esté ajustado para dar la mejor respuesta posible a los dispositivos terminales a los que debe ofrecer conectividad; y es eso lo que debemos verificar.
Esto es determinante también al momento de definir con qué dispositivos se van a hacer las pruebas. En este punto debieran elegirse dispositivos que reflejen la realidad operativa del día a día y no terminales de alto nivel que pueden brindar una percepción errónea de lo que luego será el día a día de esa red.
2. ¿Cuál es el throughput esperado?
El concepto es throughput, no data rate.
Lo que debemos considerar es la performance que han de experimentar los usuario, la capacidad real de transporte de datos que brinda la red inalámbrica.
Los usuarios no esperan simplemente conectarse a la red; esperan conectarse y poder operar en condiciones mínimas de performance que consideran adecuadas. ¿Cuáles son esas condiciones? ¿cuántos terminales deben conectarse en esas condiciones dentro de la misma celda? ¿Cuál es throughput total que se espera de la celda?
Porque el througput de una conexión no sólo es resultado del data rate que negocia la conexión sino también de la cantidad y tipo de terminales conectadas simultáneamente dentro de la misma celda.
Para ser claros, para este tipo de mediciones no es adecuada la información que brinda normalmente el software de las terminales, que expresa "data rate". Tampoco se trata de una medición puramente técnica de potencia de la señal o RSSI. Lo que se requiere es una medición de throughput.
La mejor forma de hacerlo es utilizar alguna aplicación diseñada con ese propósito, como puede ser Jperf.
Y lo que debemos evaluar es el throughput total de la celda. Por ejemplo, si se considera que lo adecuado es que una terminal pueda disponer de un throughput de unos 20 Mbps para operar, y se estima que en una celda puede haber aproximadamente 10 terminales conectadas simultaneamente, el objetivo a cubrir es un throughput promedio de 220 Mbps por celda (20 Mbps x 10 terminales y un adicional del 10% por la degradación que genera el incremento en el número de terminales).
3. ¿Cuál es el área de cobertura esperada?
Es sumamente importante tener claro el área o superficie dentro de la cual se espera lograr una conectividad aceptable.
Esto incluye espacios complejos para la propagación de la señal de los APs como son ángulos o rincones, cajas de escalera, sitios en los que la señal de radiofrecuencia pueda estar bloqueada por columnas o paredes gruesas, etc.
¿Dónde esperan lograr conectividad los usuarios?
Para esto es importante contar con un plano del lugar, marcar el área de cobertura acordada y seleccionar los puntos en los que se harán las mediciones de throughput. Es importante contar con la información del site survey previo a la implementación que nos mostrará áreas más difíciles o complejas para verificar cobertura y throughput en los puntos más difíciles.
4. ¿Hay un requerimiento de roaming?
Si en los requerimientos se incluye soportar movilidad para algunos servicios, es importante tenerlo presente y aclarar a qué tipo de servicios hay que dar soporte. Puede tratarse simplemente de movilidad para aplicaciones de datos, o en casos más complejos aplicaciones de voz y/o video.
Es igualmente importante aclarar qué aplicaciones deben operar con movilidad y verificar para esas aplicaciones cuáles son las condiciones soportadas de pérdida de paquetes, delay y jitter.
Otro elemento necesario es determinar las "rutas de roaming", es decir, los caminos más probables a recorrer por los usuarios mientras mantienen operativas sus aplicaciones. Estas rutas son relevantes porque han de estar cubiertas por celdas específicas que son las que deben cumplir con requerimiento de superposición y de sensibilidades mínimas al momento de hacer roaming.
Pero al hablar de movilidad también es preciso tener presente que, por defecto, la determinación del momento de cambio de celda es realizada por el dispositivo terminal, y consecuentemente la operación del roaming está supeditada también a la terminal con la que se está trabajando. Por este motivo, la respuesta al roaming puede variar entre diferentes terminales.
En este punto también es importante, al momento de evaluar si una implementación responde a los objetivos inicialmente propuestos, hacerlo utilizando terminales similares a las que luego se desplegarán en el día a día de la organización.
Mucho más se puede decir sobre el tema pero creo que esta es una primera síntesis que espero pueda ser útil.
Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking
o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking
De forma atrevida sugiero:
ResponderBorrarQue diseñó inicial fue base en esa la red inalámbrica especifica. Las redes de ofimática tienen criterios distintos a las de retail y a las de un Call center. El soporte de VoIP, Video lento (de seguridad o de menos de 20 FPS), etc… una vez entendiendo el “uso diseñado”, se debe evaluar el rendimiento de las aplicaciones específicas para ese diseño en la misma red wifi.
Criterios de aceptación del usuario “invitado” en la red wifi y su impacto. (Ocupación de canal post-Instalación)
En que puntos NO debería llegar la señal wifi. (Seguridad)
Como interfiere (ruido) las redes wifi vecinas. El impacto en el canal, su nivel de ruido, evaluar si se puede mover ese canal a otro menos ruidoso y reevaluar las aplicaciones, etc…
Evaluar la homogeneidad configurada en la red, ejemplo: Que de los 10 AP en funcionamiento, no exista uno que este aceptando clientes viejos con IEEE802.11b, por ejemplo, que en su señal de beacon hace que los clientes mas nuevos y rápidos bajen la velocidad, afectando el conjunto. (revisar y reevaluar la configuración del sistema de forma continua)
Niveles de firmware del sistema para evitar errores presentes o que estén por llegar sin que lo hubiésemos notado aun..