Audio Video Bridging (AVB) es un nombre común para un conjunto de estándares técnicos que proporcionan una mejor sincronización, baja latencia y confiabilidad para redes Ethernet conmutadas . [3] AVB incorpora las siguientes tecnologías y estándares:
Las modificaciones IEEE 802.1Qat y 802.1Qav se han incorporado al documento base IEEE 802.1Q -2011, que especifica el funcionamiento de los puentes de control de acceso al medio (MAC) y las redes de área local con puentes virtuales .
El grupo de trabajo Audio Video Bridging del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) del comité de estándares IEEE 802.1 desarrolló inicialmente el AVB . En noviembre de 2012, el grupo de trabajo Audio Video Bridging cambió su nombre a grupo de trabajo Time-Sensitive Networking para reflejar el alcance ampliado de su trabajo, que consiste en "proporcionar las especificaciones que permitirán servicios de transmisión de baja latencia sincronizados en el tiempo a través de redes IEEE 802 ". [5] Se están realizando más esfuerzos de estandarización en el grupo de trabajo IEEE 802.1 TSN.
Para ayudar a garantizar la interoperabilidad entre dispositivos que implementan los estándares AVB y TSN, AVnu Alliance desarrolla certificación de dispositivos para los mercados de audio y video automotriz, de consumo y profesional. [6]
Los equipos de audio y video (AV) analógicos históricamente utilizaban conexiones punto a punto unidireccionales y de propósito único. Incluso los estándares AV digitales, como S/PDIF para audio y la interfaz digital serial (SDI) para video, conservan estas propiedades. Este modelo de conexión da como resultado grandes cantidades de cables, especialmente en aplicaciones profesionales y audio de alta gama. [7]
Los intentos de resolver estos problemas se basaron en topologías de red multipunto, como IEEE 1394 (FireWire), e incluyeron la adaptación de tecnologías de redes informáticas conmutadas estándar , como Audio over Ethernet y Audio over IP . Las soluciones audiovisuales profesionales, domésticas y automotrices comenzaron a utilizar protocolos especializados que no interoperaban entre sí o protocolos de TI estándar, mientras que las redes informáticas estándar no proporcionaban una calidad de servicio estricta con tiempos estrictos y latencia predecible o limitada. [7]
Para superar estas limitaciones, las redes Audio Video Bridging transmiten múltiples flujos audiovisuales a través de conmutadores Ethernet estándar (es decir, puentes MAC ) conectados en una topología de árbol jerárquico . AVB incluye protocolos de capa 2 para reservar el ancho de banda de conexión y priorizar el tráfico de red, lo que garantiza un reloj de sincronización preciso y una baja latencia de transmisión para cada flujo. [7]
Se necesita una sincronización estrecha entre múltiples transmisiones AV para sincronizar los labios entre el video y las transmisiones de audio relacionadas, para mantener en fase varios altavoces conectados digitalmente en un entorno profesional (que requiere una precisión de 1 μs) y para evitar que los paquetes de audio o video lleguen tarde al punto final, lo que da como resultado la pérdida de un cuadro de video y fallas de audio no deseadas, como un pop o un silencio. El retardo en el peor de los casos, incluido el almacenamiento en búfer de origen y destino, debe ser bajo y determinista: el retardo de la interfaz de usuario debe ser de alrededor de 50 ms, de modo que la pulsación de un botón y la acción resultante se perciban como si ocurrieran instantáneamente, y de 2 ms para presentaciones en vivo o trabajo en estudio. [7]
El puente de audio y video se implementa como una red Ethernet conmutada que funciona reservando una fracción de la Ethernet disponible para el tráfico de AV. La arquitectura AVB presenta tres diferencias principales:
El IEEE 802.1BA es un estándar general para estas tres tecnologías principales, que define configuraciones específicas de la aplicación y procedimientos de operación para dispositivos en redes de audio y video conmutadas.
Los nuevos protocolos de configuración de capa 2 funcionan con extensiones compatibles con versiones anteriores del formato de trama Ethernet 802.1; estos cambios mínimos permiten que los dispositivos AVB coexistan y se comuniquen en redes de TI estándar; sin embargo, solo los conmutadores y puntos finales compatibles con AVB pueden reservar recursos de red con control de admisión y sincronizar la hora local con un reloj maestro, lo cual se requiere para el tráfico sensible al tiempo de baja latencia.
El tráfico AVB se replica de forma multicast, con un emisor (iniciador de flujo) y varios receptores. Los paquetes AVB se envían a intervalos regulares en los intervalos de tiempo asignados, lo que evita colisiones en el tráfico AV. AVB garantiza una latencia de 2 ms para el tráfico de clase A y de 50 ms para el tráfico de clase B en un máximo de 7 saltos, con un periodo de transmisión de 125 μs para el tráfico de clase A y de 250 μs para el tráfico de clase B.
Un dominio de temporización de red IEEE 802.1AS incluye todos los dispositivos que se comunican mediante el protocolo gPTP. El gran maestro es un dispositivo elegido como reloj de referencia; la especificación 802.1BA requiere que todos los transmisores y puentes de red sean compatibles con el gran maestro.
Los protocolos de administración de enlaces 802.3 y de medición de retardo de enlaces 802.1AS calculan el retardo de ida y vuelta al punto final AVB; este debe ser mejor que el retardo de cable del peor caso del algoritmo de retardo de pares 802.1AS.
Los protocolos de nivel superior pueden utilizar la información del reloj 802.1AS para establecer el tiempo de presentación exacto para cada transmisión AV.
La norma IEEE Std 1722-2011 [8] para un protocolo de transporte de audio y video de capa 2 (AVTP) define detalles para transmitir secuencias IEEE 1394 / IEC 61883 y otros formatos AV, establecer el tiempo de presentación para cada secuencia AV y administrar latencias a partir del retraso del peor caso calculado por el protocolo gPTP.
IEEE Std 1722.1-2013 [9] es un estándar que proporciona detección, enumeración, gestión de conexión y control (AVDECC) de dispositivos mediante IEEE Std 1722-2011. AVDECC define operaciones para detectar la adición y eliminación de dispositivos, recuperar el modelo de entidad del dispositivo, conectar y desconectar transmisiones, administrar el estado de la conexión y el dispositivo, y controlar dispositivos de forma remota.
Los servicios de capa superior pueden mejorar la sincronización y la latencia de la transmisión de medios al asignar el ID de flujo AVB a los identificadores de flujo internos y basar las marcas de tiempo internas en el reloj maestro gPTP.
La norma IEEE Std 1733-2011 [10] define un perfil de protocolo de capa 3 para aplicaciones de protocolo de transporte en tiempo real (RTP) con un formato de carga útil RTCP , que asigna el ID de flujo de SRP al identificador de fuente de sincronización (SSRC) del RTP y correlaciona las marcas de tiempo del RTP para el tiempo de presentación con el reloj maestro gPTP 802.1AS.
AES67 se basa en el estándar RTP sobre UDP/IP y el protocolo de tiempo de precisión IEEE 1588 (PTPv2) para sincronización; la interoperabilidad con AVB/TSN se puede lograr vinculando la información de sincronización IEEE 802.1AS con los datos de carga útil AES67 PTPv2. [11] [12] [13] [14]
La implementación de AES67 con interoperabilidad AVB se demostró en InfoComm 2016. [15] [16]
En 2018, la Avnu Alliance anunció la iniciativa de Milán para promover la interoperabilidad de los dispositivos AVB y proporcionar certificación y pruebas de productos. [17]
La especificación requiere una sincronización de medios basada en el CRF (formato de referencia de reloj) de AVTP y una frecuencia de muestreo de 48 kHz (opcionalmente, 96 y 192 kHz); el formato de la transmisión de audio se basa en el formato de audio AAF estándar de 32 bits IEC 61883-6 de AVTP con 1 a 8 canales de audio por transmisión (opcionalmente, formato de alta capacidad de 24 y 32 bits con 56 y 64 canales). Se proporciona redundancia con dos redes lógicas independientes para cada punto final y un mecanismo de conmutación sin interrupciones. [17]
El grupo de trabajo de redes deterministas (DetNet) del IETF está trabajando para definir rutas de datos deterministas con límites de latencia, pérdida y variación del retardo de paquetes (jitter), y alta confiabilidad. DetNet operará sobre segmentos puenteados de capa 2 y segmentos enrutados de capa 3, basándose en la interoperabilidad con conmutadores AVB/TSN cuando sea posible. [18]
Una de las posibles aplicaciones de DetNet es el audio/video profesional, como la producción de música y películas, la transmisión, el cine, el sonido en vivo y los sistemas de megafonía, transmisión de medios y anuncios de emergencia en grandes recintos (estadios, salas, centros de conferencias, parques temáticos, aeropuertos, terminales de trenes, etc.). El objetivo declarado es permitir una Intranet distribuida geográficamente en campus o en toda la empresa para la distribución de contenido con baja latencia limitada (10-15 ms). Una única red debe manejar tanto el tráfico de A/V como el de TI, con enrutamiento de Capa 3 sobre redes QoS AVB para permitir compartir contenido entre segmentos AVB de Capa 2 y proporcionar integración IntServ y DiffServ con AVB cuando sea posible. El ancho de banda reservado no utilizado se liberará para el tráfico de mejor esfuerzo. La pila de protocolos debe tener capacidades Plug-and-play de arriba a abajo para reducir la configuración y administración manuales, permitir cambios rápidos de dispositivos de red y topología de red. [19]
Las redes AVB a gran escala, como las que utiliza el centro de transmisión "Digital Center 2" de ESPN SportsCenter , que alberga varios estudios individuales, están tendidas con muchos kilómetros de fibra y tienen diez Tbit/s de ancho de banda para cien mil señales transmitidas simultáneamente; en ausencia de una solución basada en estándares para interconectar segmentos AVB individuales, se requiere un enrutador de red definido por software personalizado . [20] [21]
El trabajo sobre transmisión A/V comenzó en el grupo de estudio IEEE 802.3re ' Ethernet residencial ' en julio de 2004. [22] En noviembre de 2005, se trasladó al comité IEEE 802.1 responsable de los estándares de puenteo entre redes . [23]