AES67

AES67 utiliza el Protocolo de Tiempo de Precisión (PTPv2) IEEE 1588-2008 para la sincronización del reloj. Para equipos de red estándar, AES67 define parámetros de configuración para un "perfil PTP para aplicaciones multimedia", basado en la sincronización de solicitud-respuesta de retardo IEEE 1588 y (opcionalmente) sincronización punto a punto (Anexos J.3 y J.4 de IEEE 1588); los mensajes de eventos se encapsulan en paquetes IPv4 sobre transporte UDP (Anexo D de IEEE 1588). Algunos de los parámetros predeterminados se ajustan; específicamente, logSyncInterval y logMinDelayReqInterval se reducen para mejorar la precisión y el tiempo de inicio. El grado de reloj 2, tal como se define en la Señal de Referencia de Audio Digital (DARS) de AES11 , se señala con clockClass.

Los equipos de red que cumplen con la norma IEEE 1588-2008 utilizan perfiles PTP predeterminados; para transmisiones de vídeo, se puede utilizar el perfil PTP SMPTE 2059-2 .

En las redes AVB/TSN, la sincronización se logra mediante el perfil IEEE 802.1AS para aplicaciones sensibles al tiempo.

El reloj multimedia se basa en la sincronización horaria de la red con la época IEEE 1588 (1 de enero de 1970, 00:00:00 TAI). Las frecuencias de reloj están fijas a frecuencias de muestreo de audio de 44,1  kHz, 48  kHz y 96  kHz (es decir, mil muestras por segundo). El transporte RTP funciona con un desfase horario fijo respecto al reloj de la red.

Los datos multimedia se transportan en paquetes IPv4 y se intenta evitar la fragmentación de IP .

El protocolo de transporte en tiempo real con perfil RTP para audio y vídeo (formatos L24 y L16) se utiliza sobre el transporte UDP. La carga útil RTP está limitada a 1460 bytes para evitar la fragmentación con la MTU Ethernet predeterminada de 1500 bytes (después de restar la sobrecarga IP/UDP/RTP de 20+8+12=40 bytes). ^{[ 7 ]} No se admiten los identificadores de origen contribuyente (CSRC) ni el cifrado TLS.

Los protocolos de sincronización horaria, entrega de flujos multimedia y descubrimiento pueden utilizar multidifusión IP con negociación IGMPv2 (opcionalmente IGMPv3). A cada flujo multimedia se le asigna una dirección de multidifusión única (en el rango de 239.0.0.0 a 239.255.255.255); solo un dispositivo puede enviar a esta dirección (no se admiten conexiones de muchos a muchos).

Para supervisar el estado de keepalive y asignar ancho de banda, los dispositivos pueden usar el intervalo de informe RTCP, los temporizadores de sesión SIP y el ping OPTIONS, o la solicitud de eco ICMP (ping).

AES67 utiliza DiffServ para establecer prioridades de tráfico QoS en el campo Punto de Código de Servicios Diferenciados (DSCP) del paquete IP. Se deben admitir al menos tres clases:

• Anunciar, Sincronizar, Seguimiento, Retraso solicitado, Retraso solicitado, Retraso solicitado, Retraso solicitado Seguimiento de respuesta de retraso

Para aplicaciones críticas en cuanto al tiempo, puede ser necesario un retardo máximo de 250  μs para evitar pérdidas de audio. Para priorizar flujos multimedia críticos en una red extensa, las aplicaciones pueden usar valores adicionales en la clase de reenvío garantizado 4 con baja probabilidad de pérdida (AF41), que normalmente se implementa como una cola round-robin ponderada. El tráfico de reloj se asigna a la clase de reenvío acelerado (EF), que normalmente implementa un comportamiento de prioridad estricta por salto (PHB). El resto del tráfico se gestiona con el reenvío predeterminado, según el mejor esfuerzo posible.

El procedimiento de señalización de la fuente de reloj RTP se utiliza para especificar el dominio PTP y el ID del maestro principal para cada flujo multimedia.

Los formatos de muestra incluyen PCM lineal de 16 y 24 bits con  una frecuencia de muestreo de 48 kHz, y opcionalmente de 24 bits a 96  kHz y de 16 bits a 44,1  kHz. Es posible que se admitan otros formatos de audio y vídeo RTP . Se pueden usar varias frecuencias de muestreo. Los dispositivos pueden imponer una configuración global de frecuencia de muestreo.

Los paquetes multimedia se programan según el "tiempo de paquete", que es la duración de la transmisión de un paquete Ethernet estándar. El origen del flujo negocia el tiempo de paquete para cada sesión de transmisión. Los tiempos de paquete cortos proporcionan baja latencia y alta velocidad de transmisión, pero generan una sobrecarga considerable y requieren equipos y enlaces de alto rendimiento. Los tiempos de paquete largos aumentan la latencia y requieren mayor almacenamiento en búfer.  Se define un rango de 125 μs a 4 ms, aunque se recomienda que los dispositivos se adapten a los cambios en el tiempo de paquete o lo determinen analizando las marcas de tiempo RTP.

El tiempo de paquete determina el tamaño de la carga útil RTP según una frecuencia de muestreo admitida.  Se requiere 1 ms para todos los dispositivos. Los dispositivos deben admitir un mínimo de 1 a 8 canales por flujo. ^{[ 7 ]}

• Las restricciones de tamaño de MTU limitan una  transmisión de audio de 96 kHz que utiliza un tiempo de paquete de 4 ms a un solo canal.

La latencia de red ( desfase de enlace ) es la diferencia de tiempo entre el momento en que una transmisión de audio ingresa a la fuente (tiempo de entrada), marcado por la marca de tiempo RTP en el paquete multimedia, y el momento en que sale del destino (tiempo de salida). La latencia depende del tiempo del paquete, los retrasos de propagación y en cola, la sobrecarga del procesamiento del paquete y el almacenamiento en búfer en el dispositivo de destino; por lo tanto, la latencia mínima es el tiempo de paquete y el tiempo de reenvío de red más cortos, que puede ser inferior a 1 μs en un enlace Gigabit Ethernet punto a punto con un tamaño de paquete mínimo, pero en redes reales podría ser el doble del tiempo del paquete.

Los búferes pequeños reducen la latencia, pero pueden provocar cortes de audio cuando los datos multimedia no llegan a tiempo. Los cambios inesperados en las condiciones de la red y la fluctuación (jitter) derivada de la codificación y el procesamiento de paquetes pueden requerir un almacenamiento en búfer más prolongado y, por lo tanto, una mayor latencia. Los destinos deben usar un búfer equivalente a 3 veces el tiempo del paquete, aunque  se recomienda al menos 20 veces el tiempo del paquete (o 20 ms si es menor). Las fuentes deben mantener la transmisión con una fluctuación inferior a 17 veces el tiempo del paquete (o 17  ms si es menor), aunque  se recomienda 1 vez el tiempo del paquete (o 1 ms si es menor).

Los métodos de descubrimiento compatibles con cada dispositivo son cruciales para la integración, ya que la especificación AES67 no estipula cómo debe realizarse, sino que ofrece diversas opciones y sugerencias. Además, AES67 especifica multidifusión y unidifusión, pero muchos dispositivos AES67 solo admiten multidifusión.