Audio Video Bridging (AVB) es un nombre común para un conjunto de estándares técnicos que brindan sincronización mejorada, baja latencia y confiabilidad para redes Ethernet conmutadas . [3] AVB incorpora las siguientes tecnologías y estándares:
Las enmiendas 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 a medios (MAC) y las redes de área local con puentes virtuales .
AVB fue desarrollado inicialmente por el grupo de trabajo de puentes de audio y video del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) del comité de estándares IEEE 802.1 . En noviembre de 2012, el grupo de trabajo Audio Video Bridging pasó a llamarse 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 vídeo analógicos (AV) 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 serie (SDI) para vídeo, conservan estas propiedades. Este modelo de conexión da lugar a grandes masas de cables, especialmente en aplicaciones profesionales y de 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 sobre Ethernet y Audio sobre IP . Las soluciones AV profesionales, domésticas y automotrices llegaron a utilizar protocolos especializados que no interoperan entre sí ni 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 la conexión y priorizar el tráfico de la red, lo que garantiza una sincronización precisa del reloj y una baja latencia de transmisión para cada transmisión. [7]
Se necesita una sincronización estrecha entre múltiples transmisiones AV para la sincronización labial entre video y transmisiones de audio relacionadas, para mantener en fase varios parlantes conectados digitalmente en un entorno profesional (lo 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 provoca la caída de un fotograma de vídeo y fallos de audio no deseados, como un estallido o un silencio. Se requiere que el retraso en el peor de los casos, incluido el almacenamiento en búfer de origen y destino, sea bajo y determinista: el retraso de la interfaz de usuario debe ser de alrededor de 50 ms, de modo que la presión de un botón y la acción resultante se perciban como si ocurrieran instantáneamente, y 2 ms para presentaciones en vivo o trabajos de estudio. [7]
Audio Video Bridging se implementa como una red Ethernet conmutada que funciona reservando una fracción de la Ethernet disponible para el tráfico AV. La arquitectura AVB introduce tres diferencias principales:
El IEEE 802.1BA es un estándar general para estas tres tecnologías principales, que define configuraciones de aplicaciones específicas 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 terminales compatibles con AVB pueden reservar recursos de red con control de admisión y sincronizar la hora local con un reloj maestro, lo cual es necesario para el tráfico sensible al tiempo de baja latencia. .
El tráfico AVB se replica en forma de multidifusión, con un hablante (iniciador de transmisión) y múltiples oyentes. Los paquetes AVB se envían a intervalos regulares en los intervalos de tiempo asignados, evitando colisiones en el tráfico AV. AVB garantiza una latencia de 2 ms para tráfico Clase A y 50 ms para tráfico Clase B en un máximo de 7 saltos, con un período de transmisión de 125 μs para tráfico Clase A y 250 μs para tráfico 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 cada hablante y puente de red tenga capacidad de gran maestro.
Los protocolos de medición de retardo de enlace 802.3 y 802.1AS calculan el retardo de ida y vuelta hasta el punto final AVB; esto debe ser mejor que el retraso de cable en el peor de los casos del algoritmo de retraso de pares 802.1AS.
Los protocolos de nivel superior pueden utilizar información de reloj 802.1AS para establecer la hora exacta de presentación de cada transmisión AV.
IEEE Std 1722-2011 [8] para un protocolo de transporte de audio y vídeo de capa 2 (AVTP) define detalles para transmitir transmisiones IEEE 1394 / IEEE 61883 y otros formatos AV, configurar el tiempo de presentación para cada transmisión AV y administrar las latencias en el peor de los casos. calculado por el protocolo gPTP.
IEEE Std 1722.1-2013 [9] es un estándar que proporciona descubrimiento, enumeración, administración de conexiones y control (AVDECC) de dispositivos que utilizan IEEE Std 1722-2011. AVDECC define operaciones para descubrir la adición y eliminación de dispositivos, recuperar el modelo de entidad del dispositivo, conectar y desconectar transmisiones, administrar el estado del dispositivo y la conexión, 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 transmisión AVB a identificadores de transmisión internos y basar las marcas de tiempo internas en el reloj maestro gPTP.
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 el RTP. Marcas de tiempo para el tiempo de presentación con reloj maestro 802.1AS gPTP.
AES67 se basa en RTP estándar sobre UDP/IP y el protocolo de tiempo de precisión (PTPv2) IEEE 1588 para temporización; La interoperabilidad con AVB/TSN se puede lograr vinculando la información de temporización IEEE 802.1AS a 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, 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 sincronización de medios basada en AVTP CRF (formato de referencia de reloj) y una frecuencia de muestreo de 48 kHz (opcionalmente 96 y 192 kHz); El formato de transmisión de audio se basa en el formato de audio AAF estándar de 32 bits AVTP IEC 61883 -6 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). La redundancia se proporciona con dos redes lógicas independientes para cada punto final y un mecanismo de conmutación perfecto. [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á tanto en segmentos puenteados de Capa 2 como en segmentos enrutados de Capa 3, confiando en la interoperabilidad con conmutadores AVB/TSN cuando sea posible. [18]
Una de las posibles aplicaciones de DetNet es el audio/vídeo profesional, como la producción de música y películas, transmisiones, cine, sonido en vivo y sistemas para grandes espacios (estadios, salas, centros de conferencias, parques temáticos, aeropuertos, terminales de trenes, etc.). para megafonía, transmisión de medios y anuncios de emergencia. El objetivo declarado es permitir una intranet distribuida geográficamente, en campus o en toda la empresa , para la entrega de contenido con baja latencia limitada (10-15 ms). Una única red manejará tanto el tráfico A/V como el de TI, con enrutamiento de Capa 3 sobre las redes QoS de AVB para permitir compartir contenido entre segmentos AVB de Capa 2 y proporcionar integración de 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 tendrá capacidades Plug-and-play de arriba a abajo para reducir la configuración y administración manual y permitir cambios rápidos de los dispositivos de red y la topología de la red. [19]
Las redes AVB a gran escala, como las utilizadas por la instalación de transmisión "Digital Center 2" de ESPN SportsCenter , que alberga múltiples estudios individuales, cuentan con muchos kilómetros de fibra y tienen diez Tbps 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 personalizado definido por software . [20] [21]
El trabajo sobre la 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 puentes entre redes . [23]