14 de junio de 2021

Transmisiones de video: ancho de banda requerido

Es una pregunta respecto del ancho de banda necesario para sostener comunicaciones de video de diferente tipo es recurrente en nuestra tarea. 
Es que no sólo el streaming de video ha ido ganando cada vez más lugar en el tráfico de la red. También se multiplican las aplicaciones que permiten acceder a contenidos basados en video o establecer comunicaciones de video; y cada vez de mayor calidad. Cuando se implementa QoS o se diseñan redes inalámbricas es necesario considerar la cantidad de comunicaciones de video simultaneas que habrá de sostenerse, y al hacerlo es fundamental conocer la calidad de ese video para poder estimar el ancho de banda necesario para garantizar su fluidez.

¿Qué es un "streaming" de video?
Con este término solemos referirnos a una transmisión de video unidireccional a través de una red de datos.
Es un tipo de transmisión que requiere la transferencia contínua de bits a través de la red de datos (Internet, la red corporativa o la red hogareña) hasta el receptor en el que se reproducirá.
Normalmente se trata de contenido enviado de modo comprimido, utilizando diferentes algoritmos de compresión, que el receptor final visualiza en tiempo real utilizando aplicaciones que no esperan a la descarga completa o a almacenarlo para poder reproducirlo.
Este video puede tener diferente resolución o calidad.
La resolución del video, junto al algoritmo de compresión utilizado, determinan el requerimiento de ancho de banda.

Video HD
Resolución de imagen: 720p, lo que implica una resolución de pantalla de 1280 x 720 píxeles.
Esta calidad de video, utilizando códec H.264 requiere 3 Mbps de ancho de banda.
Si se utiliza códec H.265 es necesario calcular un ancho de banda de 1,5 Mbps.

Video FHD
Resolución de imagen: 1080p, lo que implica una resolución de pantalla de 1920 x 1080 píxeles.
Cuando se utiliza códec H.264 su transmisión requiere 6 Mbps de ancho de banda.
Utilizando H.265 se recomienda estimar 3 Mbps para este streaming.

Video UHD
Resolución de imagen: 2160p, lo que implica una resolución de pantalla de 3840 x 2160 píxeles (el doble que FHD).
Aproximadamente 4 veces la cantidad de píxeles del video FHD.

Video 4K
Esta calidad de video refiere a 2 resoluciones posibles.
La resolución correspondiente a video UHD: 3840 x 2160 píxeles; o la resolución mayor disponible que es 4096 x 2160 píxeles. 
Materiales en esta resolución ya están disponibles en servicios de streaming como Netflix o YouTube.
Para una transmisión en resolución 4096 x 2160, con códec H.264 se recomienda reservar 32 Mbps. Si se utiliza códec H.265 hay que estimar 15 Mbps.

Sintetizando

HD     1280 x 720       H.264    3 Mbps
                                   H.265    1,5 Mbps
FHD   1920 x 1080    H.264     6 Mbps
                                  H.265     3 Mbps
UHD   3840 x 2160    H.264    25 Mbps
                                   H.265   12 Mbps
4K      4096 x 2160   H.264     32 Mbps
                                  H.265   15 Mbps



Estás invitado a participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
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


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.



9 de junio de 2021

Power over Ethernet

En las redes actuales hay una variedad importante de terminales o "endpoints" (cámaras IP, access points, teléfonos IP, laptops, etc.) que por su naturaleza de dispositivos terminales están diseñados para conectarse a la infraestructura de la red a través de dispositivos de acceso, típicamente un switch. 

Estas terminales utilizan un cable UTP para conectarse al puerto de acceso de un switch LAN. Pero para poder operar, además de la conexión de datos requieren de alimentación eléctrica.

Desde hace varios años los switches de acceso de nivel enterprise dan la posibilidad de que el dispositivo terminal reciba energía a través del mismo cable UTP que se utiliza para la transmisión de datos. Es lo que recibe la denominación genérica de Power over Ethernet (PoE). De esta manera es posible simplificar los requerimientos de cableado eléctrico y aprovechar el tendido del cableado de red para un propósito doble: alimentación eléctrica y transporte de datos.

Adicionalmente, al controlar el suministro eléctrico de estos dispositivos desde el switch es también posible tener un control centralizado del encendido y apagado de terminales como teléfonos y otros. Con esto hay un nuevo recurso para el control del consumo eléctrico.

Para dar suministro eléctrico a través del puerto del switch es suficiente un cableado UTP categoría 5e realizado de acuerdo a las especificaciones del estándar.  

En el caso de los switches Cisco, si bien PoE se inicio como una implementación propietaria (Power Inline y UPoE), en la medida en que se publicaron estándares los dispositivos se fueron adaptando a los mismos. En primer lugar la primera norma fue IEEE 802.3af (conocida como PoE), luego actualizada por IEEE 802.3at (llamada PoE+) y finalmente llevada a su expresión más potente en la actualidad, IEEE 802.3bt (UPoE).

PoE IEEE 802.3af

Generalmente recibe la denominación genérica de PoE la implementación del estándar 802.3af aprobado por la IEEE en el año 2003, y que tiene las siguientes características:

  • Puede utilizar 2 o 4 pares de cable UTP categoría 5e.
  • Entrega hasta 15,4 W en el puerto del switch, lo que brinda hasta 12,95 W en el dispositivo alimentado considerando la pérdida de 100 m. de cable.
    Esto es suficiente para alimentar APs IEEE 802.11a/b/g con radio dual, una cámara IP o un teléfono IP que requieren un máximo de 12,95 watts. 
  • Se puede implementar sobre enlaces Ethernet 10BaseT, 100BaseT o 1000BaseT.
  • Mantiene una longitud máxima de 100 m. para cada segmento de cableado UTP.

PoE+ IEEE 802.3at

Estándar IEEE aprobado en el año 2009, que cuenta con las siguientes características:

  • Proporciona hasta 30 watts en el puerto del switch lo que representa hasta 25,5 watts de potencia a los 100 metros de cable.
  • Soportado sobre cableado categoría 5e o superior.
  • Estos dispositivos también son denominados dispositivos “tipo 2”.
  • Mantiene una longitud máxima de 100 m. para el cableado UTP.
  • PoE+ es la solución para dar alimentación eléctrica a APs 802.11n de radio dual y los estándares posteriores, para sostener también cámaras IP color de alta resolución o teléfonos IP con pantalla color de alta resolución.

UPoE+ IEEE 802.3bt

La tecnología de provisión de energía sobre el cableado de datos ha seguido evolucionando para permitir dar alimentación eléctrica a una variedad más amplia de dispositivos terminales.

Inicialmente fue un desarrollo propietario de Cisco para proporcionar alimentación eléctrica de hasta 60 watts en el puerto del switch denominado genéricamente UPoE.

Ahora, estandarizado como IEEE 802.3bt es denominado UPoE+ y proporciona:

  • Proporciona hasta 90 watts en el puerto del switch que representan hasta 71 watts a los 100 metros de cable.
  • Soportado sobre cableado categoría 5e o superior.
  • Mantiene los 100 m. de longitud para el cableado UTP.
  • Requerido para alimentación eléctrica de clientes de infraestructura de escritorio virtual, switches compactos, laptops, sistemas de Telepresencia, etc.


Soporte en dispositivos Cisco
Entre la familia de dispositivos Cisco, soporten PoE+ o UPoE+ los siguientes:
  • Catalyst 9200 soporta PoE+.
  • Catalyst 9300 y 9400 soportan hasta UPoE+.
  • Meraki MS12X, 2XX y 350 soportan PoE+.
  • Meraki MS355 y 390 soportan UPoE.

En el caso de los switches Catalyst, una letra incluida en el Product ID identifica el soporte PoE que ofrece la plataforma:

  • Una letra "P" identifica productos con soporte PoE+ como, por ejemplo: C9200L-48P-4G, o C9300-48P.
  • Una letra "U" identifica productos con soporte UPoE como, por ejemplo: C9300-24U, o C9400-LC-48UX.
  • Una letra "H" identifica productos con soporte UPoE+ como, por ejemplo: C9300-48H o C9400-LC-48H.
En todos los casos es necesario tener presente que la simple declaración de que un dispositivo posee capacidad PoE no es suficiente. Es necesario complementar la información con lo detallado en el hoja técnica del dispositivo respecto de posibles restricciones y requisitos, el rango de puertos soportados, el posible requerimiento de fuentes de alimentación o actualizaciones de software.



Estás invitado a participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
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


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.



23 de mayo de 2021

Productos de la familia Meraki

Meraki ofrece una importante variedad de productos que cubren buena parte de los requerimientos de las actuales redes corporativas; todos dentro del mismo concepto de arquitectura y basados en la misma tecnología.

Cada línea de productos tiene características propias ajustadas a los requerimientos habituales de las implementaciones corporativas, manteniendo la misma facilidad de uso, ya conocida, de los productos Meraki.

Dispositivos de seguridad y SD WAN Meraki MX 

Los dispositivos de seguridad Cisco Meraki MX son dispositivos multifuncionales que permiten el despliegue de implementaciones SD-WAN. Es una solución integral de seguridad y conectividad en el borde de la red corporativa.

Incluye la posibilidad de una conexión de respaldo alternativa LTE implementando adicionalmente un gateway Meraki MG.

El firewall que se incluye en la estructura de Meraki MX tiene componentes avanzados de última generación:

  • Firewall statefull.
  • Protección contra amenazas con la incorporación de AMP.
  • Sistema de prevención de intrusiones que utiliza el motor Snort.
  • Filtrado de contenido basado en categorías de BrightCloud.
  • Gestión en la nube de las prestaciones de seguridad.
  • Reglas de geolocalización.

La implementación de Auto VPN y SD-WAN tiene características específicas:

  • VPN automática para el provisionado de túneles IPsec gestionados desde la nube.
  • Selección de ruta inteligente.
  • Optimización del tráfico a través de túneles VPN.
  • Equilibrio de la carga de tráfico dinámico en función de las condiciones de los enlaces WAN.
  • Gestión de enlaces ISP redundantes.
  • El enlace redundante se puede utilizar para conmutación en caso de fallo o con una política de equilibrio de carga dinámico.
Switches Meraki MS

La línea de switches Meraki incluye prestaciones de enrutamiento dinámico y un alto nivel de seguridad; incluyen herramientas adicionales para la solución de fallos. Entre las funciones que incorporan se pueden destacar:

  • Herramienta de captura de paquetes en vivo.
  • Herramienta de prueba de integridad del cableado.
  • Herramientas de diagnóstico en tiempo real.
  • Características de seguridad de nivel corporativo.
  • Virtual stack para facilitar la configuración de cientos de puertos independientemente de la ubicación física de los switches.
  • Port-security.
  • Página de topología.
  • Visibilidad de capa 7 de las sesiones de los clientes.
  • Calidad de servicios (QoS) para voz y video

Algunas de las prestaciones, dado que requieren hardware especializado, son dependientes del hardware y no están soportadas en todos los modelos de switches:

  • Stack físico.
  • StackPower.
  • Servicios DHCP incorporado.
  • UPoE.
  • Enrutamiento dinámico con OSPF.
Hay también algunos dispositivos de alta performance para tareas de agregación y distribución.

Access points Meraki MR

Son el primer producto que se lanzó y quizás el más conocido de la familia Meraki. Hoy, los APs de la familia Meraki ofrecen prestaciones de última generación e implementan los últimos estándares definidos. Ofrecen soluciones para una amplia gama de necesidades, desde la cobertura básica hasta la operación en entornos de alta densidad y uso intensivo.

Entre sus principales características se puede destacar:

  • Dispositivos que responden al estándar 802.11ax (WiFi 6) y que incluyen seguridad WPA3.
  • Variedad de modelos para despliegues indoor y outdoor, con antenas integradas o conectorizadas.
  • Posibilidad de priorizar tráfico de aplicaciones críticas.
  • Implementación de autenticación con portal web cautivo para usuarios invitados.
  • Despliegue en malla de recuperación automática.
  • Motor de estado inalámbrico que identifica anomalías en la experiencia de los usuarios finales.
  • La mayoría de los modelos incluyen una tercera radio para despliegues de seguridad con Air Marshal, Auto RF y localización.

Cámaras de seguridad Meraki MV

Las cámaras de seguridad Cisco Meraki MV incluyen numerosas funciones que intentan hacer su implementación simple y efectiva, al mismo tiempo que permiten un nivel de personalización adecuado para los requerimientos de implementaciones corporativas. Permiten monitorear e investigar cualquier incidente de modo fácil y rápido.

Utilizan una arquitectura de borde que incluye almacenamiento del video registrado en una tarjeta SSD local, con lo que no se requiere almacenamiento centralizado. La imagen capturada por la cámara se puede visualizar localmente o a través de la nube. Con este propósito incluye el cifrado end-to-end de la transmisión de video.

Incluyen múltiples funciones que aportan valor:

  • Análisis de imágenes retroactivo.
  • Detección de objetos y mapas de calor de movimiento.
  • Diferentes formatos de hardware disponibles.
  • Modelos indoor y outdoor.
  • Dotación de LEDs infrarrojos para contar con imagen de sitios oscuros.
  • Lentes ópticas y lentes fijas.
  • Conectividad inalámbrica.
  • Funcionalidades PTZ disponibles.
  • Posibilidad de almacenamiento en la nube Cisco Meraki MV Cloud Archive con licencia adicional.

System Manager Endpoint

Solución diseñada para administrar y controlar dispositivos terminales.

En aquellos casos en los que se requiere aprovisionamiento dinámico e incorporación este sistema permite asegurar de modo rápido y simple que la red permanecerá segura mientras proporciona la cobertura necesaria para satisfacer el requerimiento de los usuarios finales.

  • Brinda soporte multiplataforma: MacOS, iOS, Apple TV, Windows, Android y Chrome OS.
  • No requiere implementación de dispositivos y/o software on-premise.
  • Brinda visibilidad del comportamiento de las terminales.
  • Permite aplicar perfiles específicos a diferentes tipos de terminales.

La implementación de perfiles permite deshabilitar funciones o aplicaciones en las terminales, pueden descargar una configuración inalámbrica específica y activar la asociación automática a un determinado SSID.

Como resultado de la implementación de perfilado se puede:

  • Desactivar funciones específicas del sistema operativo, ocultar aplicaciones y aplicar restricciones.
  • Forzar el cumplimiento de políticas de seguridad.
  • Establecer límites geográficos para la presencia de un dispositivo.
  • Aplicar herramientas para control en tiempo real.
  • Obtener, de modo remoto, capturas de pantalla de las terminales.
  • Descargar aplicaciones, perfiles y certificados digitales de modo remoto.
  • Apagar y reiniciar terminales.

Meraki Insight


Cisco Meraki Insight es un servicio que analiza el rendimiento y funcionamiento de las diferentes aplicaciones. Por este motivo es una herramienta poderosa y muy útil para contar con información sobre aplicaciones, servicios y su rendimiento; detecta anomalías de comportamiento y las registra de forma gráfica para información del administrador.

Es una herramienta que permite responder de forma rápida, eficiente y en tiempo real a la posibilidad del surgimiento de problemas graves.

  • Se ejecuta en la nube de Meraki.
  • Utiliza los dispositivos Meraki MX como sensores para obtener datos.
  • Permite obtener copias de seguridad de la información procesada.
  • Introduce la función VoIP Health que monitorea la performance de los enlaces ascendentes para el tráfico de VoIP a través de sondas ICMP desde el Meraki MX hasta el punto final de VoIP.
  • VoIP Health puede estimar la calidad de las llamadas y proporcionar información en función de MOS.


Estás invitado a participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
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


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.



12 de mayo de 2021

Meraki, control en la nube

Cisco Meraki introduce la tecnología necesaria para desplazar la gestión y control de los dispositivos a la nube. De esta manera ofrece una funcionalidad completa que se puede gestionar y monitorear fácilmente desde cualquier lugar con acceso a Internet y a través de ella, a la nube. Por otra parte, la integración de los dispositivos a esta nube es sumamente simple:

  • Se implementa el dispositivo en las instalaciones de la empresa. 
  • Como consecuencia de esto el dispositivo adquiere una dirección IP (vía DHCP) de gestión y acceso a Internet.
  • El dispositivo se conecta automáticamente en forma segura a la nube Cisco Meraki.
  • Desde el panel de control se registra el dispositivo en la red adecuada, se actualiza el firmware y se descarga la configuración de modo automático.
  • Se inician las tareas de gestión y monitoreo desde el panel de control que brinda herramientas para estas tareas.


Los dispositivos Meraki se entregan preconfigurados con el nombre de host y las direcciones IP necesarias para poder establecer una conexión segura con la nube de Meraki. Esta configuración inicial incluye un certificado digital que se utiliza en el proceso para establecer un túnel cifrado entre el dispositivo y la nube de Meraki para asegurar el tráfico de gestión y control que circula a través de ese circuito.

  • Todo el tráfico que se intercambia con la nube de Meraki circula en un túnel cifrado con un algoritmo basado en AES 256.

El tablero de control es una interfaz web a la que se puede acceder utilizando cualquier navegador web y desde dónde se administran y monitorean todos los dispositivos Meraki de la red corporativa. Cada dispositivo establece su propio túnel cifrado y a  través de esta conexión con la nube:

  • Cada dispositivo independientemente genera un tráfico de entre 1 y 2 Kbps para la gestión y control.
  • A través de ese túnel se descargan configuraciones y e envían datos de monitoreo que se procesan en la nube.
  • El tráfico de los usuarios se reenvía independientemente sin que pase por la nube de Meraki.

Nota: Las cámaras Meraki MV pueden generar picos de tráfico hacia la nube de hasta 200 Kbps cuando tienen activada la función de detección de movimiento. Esta función puede ser desactivada para reducir el consumo de ancho de banda.


Las objeciones más frecuentes están referidas a:

Seguridad
¿En algún momento el tráfico que circula por la red corporativa fluye a través de la nube de Meraki?

  • El tráfico de los usuarios nunca ingresa a la nube de Meraki.
    Esto permite afirmar que todas las implementaciones de Cisco Meraki cumplen con los requerimientos para certificar HIPAA y PCI.
Confiabilidad
¿Qué ocurre si en algún momento los dispositivos de la infraestructura corporativa no pueden acceder a la nube de Meraki?
  • La nube de Meraki tiene una disponibilidad garantizada del 99,99%.
    Este servicio está basado en centros de datos distribuidos en diferentes puntos del planeta.
    Los problemas de conectividad de dispositivos a la nube se deben en su inmensa mayoría a problemas de conectividad del dispositivo hacia la nube, no de disponibilidad de la nube: interrupciones de servicio del ISP, problemas de cableado, o reglas de bloqueo de tráfico.
  • Si se da una interrupción de la conexión con la nube de Meraki los dispositivos continúan reenviando el tráfico de la red corporativa sin interrupciones porque la última configuración conocida de los dispositivos reside localmente en los mismos.
    De ser necesario, cada dispositivo tiene una interfaz web local que se puede utilizar para realizar cambios de configuración básicos (por ejemplo los que puedan impactar en su acceso a Internet).
Previsibilidad
¿Cómo se realizan las actualizaciones de firmware? 
¿Están aseguradas?
¿Con qué frecuencia se publican actualizaciones?
  • Las actualizaciones de firmware se programan y envían a través del panel de control de Meraki. No requieren ninguna operación local.
  • Cisco Meraki tiene 3 categorías de actualizaciones de firmware: estable, candidato a estable y beta.
    El Administrador puede seleccionar la versión de firmware deseada a través del panel de control y programar el momento (día y hora) en que desea que se realice la actualización; o bien puede activar las actualizaciones manualmente.
Escalabilidad
¿Cómo puede crecer la red?
  • La red puede crecer o expandirse de modo muy simple, sencillamente agregando dispositivos y licencias en el tablero de control.


Estás invitado a participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
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


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.



14 de abril de 2021

Un protocolo de verificación para redes inalámbricas

Una solicitud que he recibido muchas veces es la referida a la necesidad de un protocolo, método o lista de verificación para probar la operación de una red inalámbrica después de su implementación o ante la presunción de alguna necesidad específica.

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/

O si preferís redes sociales con mayor control de tu privacidad,
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


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.