Cálculo del ancho de banda (nominal vs efectivo)

La mejor imagen se logra casi siempre en los Monitores. Obteniendo la mejor resolución estática (pixels) y resolución dinámica (cuadros por segundos) de todo el sistema; siempre y cuando se diseñe y configure un sistema eficiente. Casi siempre los stream (flujos de datos) de video, llegan con una calidad muy similar a los servidores que hacen analítica de video (si existen) y que graban la información.

Es dentro de las videograbadoras donde más se modifican los parámetros de configuración para lograr que todo el video necesario quepa dentro de nuestro disco duro… pero creo que estaremos de acuerdo en que el stream de video más crítico es el que enviamos hacia las redes de datos (LAN/WAN), porque sabemos que entre más calidad enviemos, más ancho de banda requerimos de esa red y eso puede significar mayor inversión en gastos operativos.

Y entonces viene la pregunta del millón… ¿cuánto ancho de banda necesito?

Aunque conozco algunos magos en nuestro gremio que se atreven a decir cifras de inmediato y otros que se comprometen con números inventados (… quizás debido a que la pregunta genera un reto y nos da miedo decir “no se”…); en este artículo aprenderemos cómo estimar un ancho de banda de manera profesional y detallada. Mi sugerencia es que tenga a mano una calculadora simple y tenga en cuenta el proceso que describo a continuación.

Recuerde que los streams de video se componen de datos que representan imágenes en movimiento. Por lo tanto es lógico suponer que entre más detalle haya en cada imagen, es mayor la cantidad de datos que tendrá nuestro video. El punto de partida para calcular el ancho de banda o Band Width (BW) de una señal de video son los mismos datos que se requieren para calcular el espacio de un disco duro (DD).

Recordemos que para calcular el DD, calculamos el espacio necesario para almacenar un (1) segundo de video y luego lo multiplicamos por el número de segundos, horas o días que necesitemos almacenar. Para conocer cuánto se requiere para almacenar un segundo de video, debemos analizar e investigar algunos factores:

1. Velocidad a la que deseamos grabar (FPS)
2. Resolución, calidad y algoritmo de compresión que usemos. Esto nos dará el tamaño de un cuadro de video, en promedio (Bytes)
3. El porcentaje de actividad de la escena que nos dice que tanto cambia un cuadro respecto a otro.

Una vez tengamos estos tres datos, aplicamos la fórmula:

Y entonces si expresamos este resultado en bits, obtendremos la cantidad de bits que necesitamos en un segundo de video… esto se puede decir como “bits por segundo” (bps), y es precisamente la unidad usada para expresa el BW, por lo tanto podemos decir que:

Si, así de sencillo.

Debo aclarar que esto mismo se debe hacer para cada stream de video que queramos enviar por nuestro canal de comunicaciones. Y entonces deducimos que el total del ancho de banda efectivo que necesitamos es la sumatoria de todos los anchos de banda de cada stream de video.

Ejemplo:

Suponga que tenemos 8 cámaras de red (IP), en un establecimiento comercial y deseamos verlas simultáneamente, desde nuestra oficina. ¿Qué ancho de banda requiero?

Asumamos los siguientes datos:

1. Debido a que nuestra aplicación es de solo supervisión, requerimos video a solo 10 FPS.
2. Una vez consultada la fábrica de la cámara IP, llegamos a la conclusión que usando un algoritmo de compresión H.264, en calidad media y usando una resolución D1 (720x480 pixels), el promedio de cada imagen es de 9KB.
3. Realizando un estudio de actividad, vemos que en promedio las escenas de las cámaras tienen una actividad del 60%.

Entonces aplicando las fórmulas mencionadas anteriormente, el ancho de banda EFECTIVO que la red de datos necesita, para ver una (1) cámaras es:

Y por lo tanto el ancho de Banda para ver simultáneamente las 8 cámaras será:

Aunque nos parece bajo este número, en realidad sugiero hacer énfasis en la palabra EFECTIVO, debido a que la velocidad de nuestro servicio de “Banda Ancha”, que se contrata con un proveedor de servicio de internet (ISP), es una velocidad nominal y siempre es mucho más alta que la velocidad efectiva que realmente necesito.

Velocidad efectiva vs. velocidad nominal

Cuando hablamos de un servicio de telecomunicaciones como el que las empresas ISP (Internet Service Provider) nos ofrecen, debemos tener en cuenta tres aspectos, para verificar la velocidad que necesitamos contratar: Modelo OSI, Sincronismo, Nivel de Reuso.

Comencemos por definir de que estamos hablando:

• La velocidad nominal es la que se encuentra mencionada en el contrato que se hace con el ISP. Es decir, la que se publicita y sale a la luz pública, casi siempre y en esta época, en números enteros expresados en Mbps (millones de bits por segundo). Sin embargo esta velocidad no es EFECTIVA, es decir, no podemos usar la totalidad de la velocidad nominal que contratamos, porque ocurren varios factores (técnicos y comerciales) que afectan su desempeño.
• La velocidad efectiva es la cantidad de bits por segundo que podemos realmente usar para nuestra señal de video.

La velocidad efectiva siempre es menor que la velocidad nominal. Y depende de los aspectos que recién mencionamos.

1. Modelo OSI. Sin entrar a explicar en detalle, la manera como se transmiten las señales de video en una red que usa Protocolo de Internet (IP), sigue varias pautas del modelo OSI, para transmisión de datos. Cada capa del modelo le adiciona algunos caracteres de control y entrega la nueva trama de datos a la capa inferior y asi sucesivamente… de tal manera que cuando el stream de video viaja por el medio de transmisión escogido, realmente está aumentado en un porcentaje que varía entre el 15% y el 40%, dependiendo del protocolo de comunicación usado.
2. Sincronismo. Se refiere a si la velocidad de bajada (es decir, recibir datos de internet ó DownLoad) es igual a la velocidad de subida (enviar datos a internet ó UpLoad). En la inmensa mayoría de casos, la velocidad de bajada es mucho mayor a la de subida. Los valores en nuestra región latinoamericana, pueden variar a relaciones de 1:4 o 1:2, es decir la velocidad de subida es cuatro veces más baja de la de bajada o a veces la mitad de la velocidad. Cuando la velocidad de subida es igual a la de bajada, se dice que el canal es sincrónico y casi siempre se presenta cuando el canal es dedicado.
3. Reuso. Este término se refiere a la capacidad de compartir el canal contratado con otros usuarios. Las empresas de ISP, deben sacar el mejor provecho a las inversiones que realizan, por lo tanto asumen que no todos los usuarios requieren la máxima velocidad y cantidad de datos simultáneamente. Aun cuando todos puedan estar conectados de manera indefinida y simultánea. Para entender mejor el concepto piense en una avenida que pasa frente a su casa, el Estado no la hace exclusivamente para usted, la pueden usar muchos más y en determinado momento podrían pasar desde un (1) carro hasta cuatro (4) de manera simultánea dependiendo del número de carriles, pero también si la avenida es de buenas especificaciones, podrían pasar carros de manera más ordenada, segura y rápida, por lo tanto en un segundo podrían pasar muchos más carros. Obviamente en los momentos de horas pico, el tráfico se vuelve más pesado y la velocidad general se reduce… es algo absolutamente normal. Exactamente pasa lo mismo en los canales de comunicación hacia internet bajo el servicio que llamamos “Banda Ancha”, se entiende que es compartida. El reuso está asociado con el máximo número de usuarios con quienes debemos compartir el mismo canal, sin sacrificar de manera fuerte las calidades en la comunicación. Para Latinoamérica el factor puede variar desde 1:12 veces hasta 1:4 veces. Aunque en algunos países ya hay servicios sin reuso (1:1). Todo depende de la región donde se encuentre y de los parámetros con que su ISP trabaje.
4. Cuando el canal es totalmente dedicado no se comparte con nadie más, casi siempre es sincrónico y entonces se garantiza que la gran mayoría de ancho de banda nominal es efectivo.

Entonces existe una fórmula para encontrar la velocidad nominal a partir de la velocidad efectiva.

Fijémonos que los contratos de comunicaciones, se hacen con la velocidad de Download, debido a que más del 90% del flujo tradicional de internet es para ver, investigar y bajar información pública o privada; sin embargo cuando estamos usando un sistema de video vigilancia hay que recordar que no bajamos datos de internet sino que los enviamos, por lo tanto la velocidad que realmente nos importa es la de Upload en el sitio donde se conectan las cámaras.

También es importante aclarar que el factor de reuso se vuelve crítico cuando estamos transmitiendo un video en las horas de mayor tráfico en internet y esto depende de dónde estemos ubicados y que vecinos tengamos. La consigna común es que los picos máximos de uso se presentan unos minutos antes o después de las horas de salida y entrada de los usuarios de los inmuebles cercanos. Se entiende entonces que es muy diferente tener como vecino un colegio, que a un centro comercial o un edificio residencial.

Sin embargo recordemos que no podemos diseñar un sistema de seguridad inseguro, por lo tanto siempre es mejor asumir el caso más crítico y diseñar con esos parámetros, así en otros momentos sub-utilicemos el sistema y los servicios contratados.

Continuemos con el Ejemplo:

Ya habíamos encontrado que el ancho de banda efectivo que necesita el establecimiento de comercio para ver simultáneamente 8 cámaras es de 3,5 Mbps aprox.

Supongamos que después de investigar con nuestro ISP (servicio tradicional en Latinoamérica), obtenemos las siguientes configuraciones: Transmisión en protocolo TCP/IP, con 30% de uso real. Download al doble de la velocidad de Upload. Nivel de reuso 1:4; entonces:

Si, leyó bien. Necesitamos contratar un servicio de banda ancha de 40 Mbps !!!, para poder ver todas las 8 cámaras, de manera simultánea, con buena calidad, incluso en las horas pico.

Y entonces, es esto posible?

Técnicamente SI. Lo que sucede es que simplemente va a costar más dinero que el servicio que tenía en la cabeza originalmente.

El error de casi toda la industria es ignorar estas situaciones y no hacer nunca los cálculos. Por lo tanto se pretende que por un canal tradicional de tipo casero (tradicionalmente hoy, unos 4 Mbps), vaya toda la información de las 8 cámaras.

Después de configurar los dos enlaces (transmisión y recepción), el ingeniero responsable al ver que efectivamente le llegan algunas imágenes, a una velocidad mucho menor de la deseada, recurre entonces a disminuir la resolución del stream y “juega” con algunos parámetros que a la postre le quitan calidad y seguridad a la señal, para que la imagen transmitida se vea aceptable. Sin embargo lo único que el usuario final percibe es una mala calidad y un sentimiento de frustración, (incluso con toda la industria) debido a que no era lo que deseaba.

No fuimos lo suficientemente conscientes de nuestra realidad latinoamericana, en donde los anchos de banda promedio están en 4 Mbps, cuando en Tokio o Seul, por el mismo dinero, las ISP les ofrecen anchos de banda de 150 Mbps, a nivel residencial.

Pero lo malo, no es nuestro atraso tecnológico o nuestras políticas de estado. Los malos somos nosotros mismos, por no hacer los cálculos debidos y no explicar a nuestro usuario final las limitaciones y fortalezas de los sistemas que le estamos entregando. Cuando el usuario final se da cuenta, que para mejorar su imagen remota debe pagar más, en la gran mayoría de casos lo hace.

Posibles Soluciones

Continuando con el ejemplo, veamos las posibles soluciones:

1. Contratar un servicio de banda ancha de 40Mbps. Puede costar unas 6 veces más que el promedio.
2. Contratar un servicio de comunicaciones con un canal DEDICADO. Esto implica garantía de que el ancho de banda no se comparte, casi siempre la velocidad de bajada es la misma de subida y finalmente las ISP adjudican en la mayoría de casos, una dirección IP pública fija. Se debería contratar entonces un canal de BW=3.5Mbps x 1 x 1 / 0.7 = 5Mbps. Puede costar unas 4 veces más que el valor base.
3. Disminuir la cantidad de streams de video que deseo ver de manera remota. Es decir, por qué tengo que ver simultáneamente las 8 cámaras? Podría verlas todas, pero de una en una, en ese caso solo necesito 1 stream de video, por lo tanto el BW que requiero es 8 veces menor, entonces necesitaría un canal de solo 5Mbps, que se puede lograr fácilmente a un costo aceptable. Incluso podría solicitar un canal dedicado de solo 600Kbps a un costo bastante bajo y aun así garantizar buena calidad en la transmisión.
4. Podría solicitar a la ISP, que mi canal fuera sincrónico. En algunas ocasiones lo autorizan y configuran sin costo adicional. En ese caso baja el BW del canal.
5. Podría cambiar el protocolo de transmisión (por ejemplo pasar de TCP a UDP), en este caso la latencia y caracteres de control bajan significativamente y la velocidad de refresco podría subir, pero sacrificando la seguridad en el envío de los datos. No es la mejor alternativa para seguridad, sin embargo es aceptable cuando el uso del sistema es solo para monitorear manualmente de vez en cuando.
6. Finalmente es importante NO modificar la resolución de la imagen, ni la velocidad de fresco del video. De esta manera no se sacrifica la calidad.
7. Se podría usar un algoritmo de compresión más sofisticado y eficiente, sin embargo en muchos casos, implica cambiar el hardware de videograbación o la cámara, y no es una opción sencilla ni económica.

Personalmente me parece que la opción c) puede ser la más aceptable, sin embargo todo depende de lo que realmente el diseñador haya pensado y el uso operativo que se le de al sistema de videovigilancia.

Para terminar, le sugiero que todos estos cálculos, estimaciones e investigaciones, las practique con anterioridad y las realice junto con una persona idónea y experimentada; ANTES de la venta de los equipos. De tal manera que cuando el usuario final compre la solución, estén todas las partes conscientes de la responsabilidad que se adquiere, para lograr imágenes locales y remotas de buena calidad.