Fundação para os Transportes em Rede da AES67

O AES67 não reinventa a rede. Funciona como um perfil que seleciona tecnologias específicas e comprovadas do conjunto de protocolos padrão da Internet. A pilha de protocolos foi projetada para priorizar a baixa latência e a entrega em tempo real sobre mecanismos de confiabilidade que introduzem atraso. Esta escolha fundamental do design dita toda a estrutura do pacote.

Porquê RTP/UDP/IP?

A AES67 manda a utilização do Protocolo de Transporte em Tempo Real (RTP) sobre Protocolo de Datagram do Usuário (UDP) sobre Protocolo Internet (IP). Esta combinação é deliberadamente escolhida sobre TCP. Enquanto TCP fornece entrega garantida através de retransmissão, estas retransmissões introduzem latência variável e jitter que são inaceitáveis para áudio ao vivo. RTP fornece a informação de sequenciamento e tempo necessário para fluxos em tempo real, enquanto UDP fornece uma camada de transporte rápida e sem conexão. AES67 utiliza especificamente IP multicast, permitindo que uma única fonte de áudio seja distribuída para múltiplos receptores sem duplicar dados no fio, tornando-o altamente eficiente para distribuição ponto-a-multiponto.

Anatomia de um pacote AES67

Um pacote AES67 consiste numa sequência de cabeçalhos que envolvem uma carga útil de amostras de áudio. Compreender a função de cada campo de cabeçalho é fundamental para solucionar erros de perda de pacotes, problemas de latência e sincronização. O tamanho total do pacote é limitado pela Unidade de Transmissão Máxima Ethernet (MTU), tipicamente 1500 bytes, o que limita o número de canais de áudio ou amostras por pacote.

Frame Ethernet (Layer 2)

A viagem começa na camada física. O cabeçalho Ethernet inclui a origem e o destino Endereços MAC. Em um fluxo multicast, o endereço MAC de destino é um endereço multicast derivado do grupo multicast IP, tipicamente na gama de 01:00:5E: para IPv4. Alternar usa este endereço para encaminhar o tráfego de forma eficiente. O cabeçalho também contém um opcional Marca VLAN 802.1Q, que é altamente recomendado para separar o tráfego de áudio de outros dados de rede e para transportar bits Priority Code Point (PCP) para Qualidade de Serviço (QoS).

O campo EtherType (0x0800 para IPv4 ou 0x86DD para IPv6) identifica o protocolo de camada de rede.

Cabeçalho IP (Layer 3)

O cabeçalho IP gerencia endereçamento lógico e roteamento. O AES67 usa normalmente endereços multicast IPv4 no 239.0.0.0 a 239.255.255.255 intervalo (administrativo). Ponto de Código de Serviços Diferenciados (DSCP) campo é talvez o byte mais crítico no cabeçalho IP para a qualidade de áudio. AES67 recomenda um valor DSCP específico (tipicamente EF - Encaminhamento Avançado, ou AF41) para garantir que os pacotes de áudio recebem tratamento prioritário através de switches e roteadores. Sem marcação DSCP adequada, pacotes de áudio podem ser largados durante o congestionamento da rede.

Cabeçalho UDP (Layer 4)

O cabeçalho UDP é mínimo, mas essencial. Ele fornece os números de portas de origem e destino. A porta de destino é usada pelo receptor para desmultiplexar o fluxo de entrada para a aplicação correta. O checksum de 16 bits fornece a detecção de erros básicos para o datagram do UDP e sua carga útil. Como o UDP não tem conexão, não há aperto de mão, permitindo fluxo de dados imediato.

O Cabeçalho RTP

O cabeçalho RTP é o coração do pacote AES67, fornecendo os mecanismos para encomendar, cronometrar e identificar carga útil. O cabeçalho fixo tem 12 bytes de comprimento.

  • Versão (V), Padding (P), Extensão (X): Bandeiras padrão. O AES67 normalmente não usa a extensão do cabeçalho.
  • Contagem CSRC (CC): Identifica o número de fontes contribuintes. Normalmente, zero em um fluxo padrão AES67.
  • Marcador (M): Usado para sinalizar limites, como o início de um spurt de conversação ou um limite de moldura de vídeo em ST 2110-30.
  • Tipo de carga útil (PT): Identifica o formato de codificação de áudio. Para o AES67, os valores comuns incluem L16 (Linear PCM 16-bit) ou L24 (Linear PCM 24-bit), muitas vezes usando números dinâmicos de carga útil (por exemplo, 96 ou 97) negociados via SDP.
  • Número de sequência: Incrementos por um para cada pacote RTP enviado. Esta é a ferramenta primária para detectar perda de pacotes, desordenar e para gerenciar o buffer de jitter na extremidade de recepção. Uma envoltória do número de sequência é tratada pela lógica de buffer de jitter.
  • Hora: Reflete o instante de amostragem da primeira amostra no pacote. Esta data- horário é derivada diretamente da Relógio PTP. Um fluxo de 48kHz irá incrementar esta data temporal em 48 tiques por milissegundo ou 48 tiques por período de amostra. O receptor usa isto para reconstruir o domínio original de tempo e relógio de áudio.
  • Fonte de sincronização (SSRC): Um identificador de 32 bits único para a fonte do fluxo. Isto é usado para distinguir vários fluxos da mesma fonte.

Carga de Áudio

A carga útil contém as amostras de áudio em bruto ou codificadas. PCM linear a 48 kHz de taxa de amostragem com 16, 20 ou 24 bits de profundidade. A carga útil também pode transportar AM824 (Audio sobre o formato USB). hora do pacote (ptime). Os valores comuns incluem 1ms (48 amostras), 125 microssegundos (6 amostras), ou 4ms (192 amostras). Um tempo de pacote de 1ms oferece menor latência, mas aumenta a sobrecarga da rede (mais pacotes por segundo).

O tamanho da carga útil deve ser cuidadosamente calculado para caber dentro da rede MTU para evitar fragmentação, o que é estritamente proibido nas redes AoIP devido à latência e complexidade que introduz.

Precisão com PTPv2 (IEEE 1588)

A sincronização é o aspecto mais desafiador da AoIP. IEEE 1588-2008 Protocolo de Precisão do Tempo (PTPv2) para distribuir um relógio comum para todos os dispositivos na rede. Isto garante que o relógio de amostra do transmissor e o relógio de amostra do receptor são perfeitamente sincronizados, evitando falhas de buffer ou ultrapassagens que causam cliques e pops audíveis.

O melhor algoritmo do relógio mestre

Cada dispositivo com capacidade PTP na rede executa o algoritmo de melhor relógio mestre (BMCA). O BMCA analisa atributos de qualidade do relógio – como classe de relógio, precisão de relógio e prioridade – para eleger um único Relógio de Grande Mestre (GM). Todos os outros dispositivos sincronizam com o GM. Em um sistema projetado corretamente, o GM é muitas vezes um dispositivo dedicado, altamente estável (por exemplo, um gerador de relógio mestre bloqueado por GPS). O BMCA também fornece failover automático; se o GM falhar, um novo GM é eleito a partir dos dispositivos restantes.

Troca de mensagens PTP

O PTPv2 define uma sequência de mensagens específica para corrigir a deriva do relógio. O GM envia periodicamente uma Sincronizar mensagem. Segue-se imediatamente com um Seguir Atualização mensagem contendo a hora exata em que a sincronização foi enviada. O dispositivo escravo envia uma Atrasar Req mensagem e regista o tempo em que é enviado. Atrasar Resp mensagem, contendo o tempo exato que o original Delay Req foi recebido.

Computando o tempo de ida e volta, o escravo pode calcular seu deslocamento do GM e ajustar seu relógio local. Este processo repete-se constantemente, mantendo a precisão sub-microsegundo em toda a rede.

Descoberta de Sessão com SAP e SDP

Como um receptor encontra um fluxo disponível do AES67? Protocolo de Anúncio de Sessão (SAP) para descoberta. Transmissores AES67 periodicamente multicast um anúncio SAP para um endereço SAP bem conhecido. Este anúncio contém um Protocolo de Descrição da Sessão (SDP) Carga útil.

O ficheiro SDP é a receita para o fluxo. Contém todos os metadados que um receptor precisa para ligar, sincronizar e descodificar o áudio.

  • Descrição da Mídia: define o tipo de mídia, porta e transporte (RTP/AVP).
  • Dados da Ligação: especifica o endereço IP do grupo multicast.
  • Atributos:
    • ptime: Tempo de embalagem em milissegundos (por exemplo, 1,0).
    • rtpmap: Mapeia o tipo de carga útil para uma codificação (por exemplo, ] significa 2 canais de PCM de 24 bits a 48kHz).
    • Relógio de mídia: ou uma referência específica de PTP.
    • Atraso da reprodução: liga o relógio de fluxo ao Grande Mestre PTP.
    • Ordem do Canal: Enquanto o SMPTE ST 2110-30 especifica a ordenação de canais para o AES67, muitos streams dependem de um mapa de canais mutuamente acordado.

Mecânica do Fluxo de Dados

O fluxo de dados de áudio da fonte para o dissipador é um processo contínuo, fortemente orquestrado. Compreender as operações do transmissor e receptor é fundamental para diagnosticar a rede ou artefatos de áudio.

Operações de Transmissores

A interface de áudio digitaliza amostras de áudio analógicas a uma taxa constante (por exemplo, 48kHz). O controlador do transmissor lê estas amostras do hardware e coloca- as num buffer. Em cada intervalo de pacotes (por exemplo, a cada 1ms), o controlador encapsula um bloco de amostras num pacote RTP. O número de sequência é incrementado e o tempo de contagem é ajustado para a contagem de amostras com o PTP. O pacote é então embrulhado em cabeçalhos UDP e IP, marcados com o valor correcto do DSCP, e enviados para o endereço MAC multicast configurado.

Os transmissores devem manter um relógio de amostra estável e bloqueado pelo PTP para garantir um timing de pacotes consistente.

Operações de Receptor e Gestão de Jitter

O dispositivo receptor ouve anúncios SAP. O usuário seleciona um fluxo e o receptor se inscreve no grupo multicast usando IGMP (Protocolo de Gestão de Grupos de Internet). Uma vez subscritos, os pacotes começam a chegar. Contudo, os interruptores de rede introduzem atrasos variáveis (sofrer). A primeira tarefa do receptor é colocar os pacotes recebidos num buffer de jitter.

Este buffer suaviza as variações de atraso da rede.

  • Tamanho do Tampão Jitter: O buffer deve ser grande o suficiente para absorver o nervosismo de rede mais ruim sem subfluxo, mas pequeno o suficiente para limitar a latência. Os buffers de jitter típicos em dispositivos AES67 variam de 1ms a 20ms.
  • Verificação do número de sequência: O receptor monitora números de sequência para lacunas, indicando pacotes perdidos. Ele também pode usar isso para reordenar pacotes fora de ordem.
  • Recuperação do Relógio (LLP): O receptor usa os timestamps RTP derivados do relógio PTP para conduzir um ciclo de fase fechado (PLL). Este PLL reconstrói o relógio de amostra do transmissor, garantindo que o seu DAC interno (Digital-to-Analog Converter) funcione em perfeita sincronização com a fonte.

Lidando com Latência e Perda

A latência numa rede AES67 é a soma de vários factores: atraso na amostragem, atraso na pacotesização (ptime), atraso no trânsito da rede (uplinks, filas), atraso no buffer do jitter e atraso no processamento. Um ptime de 1ms com uma latência total de 5ms de fim a fim é possível numa rede bem ajustada. Embora o AES67 não exija uma Correção de Erros Encaminhados Específica (FEC), suporta a redundância RTP (RFC 2198). Mais comumente, os sistemas de alta disponibilidade usam uma topologia de rede redundante (redes redundantes duplas) onde o transmissor envia dois fluxos idênticos (Stream A e Stream B) sobre caminhos de rede separados, alinhando- se com a mudança de protecção contínua SMPTE ST 2022-7.

Requisitos de infra-estrutura de rede

AES67 coloca fortes demandas em hardware de rede. Os interruptores padrão de escritório são muitas vezes inadequados para a AoIP de alto canal. São necessários interruptores gerenciados profissionais.

  • IGMP a bisbilhotar: Os switches devem ouvir as mensagens IGMP para encaminhar tráfego multicast apenas para as portas que o solicitaram explicitamente. Sem o IGMP bisbilhotar, as inundações de tráfego multicast para todas as portas, desperdiçando largura de banda.
  • Comutador de conhecimento PTP: Para precisão de submicrosegundos em redes grandes, os switches devem suportar a funcionalidade PTP Boundary Clock (BC) ou Transparent Clock (TC). Isto corrige para a latência que o switch introduz nas mensagens de tempo PTP.
  • Qualidade do Serviço (QoS): A fila de QoS restrita (por exemplo, Prioridade Estrita) deve ser configurada em todas as portas de switch. As mensagens de eventos PTP devem receber a maior prioridade (CS7), seguida de tráfego de áudio (EF ou AF41), e então os dados de melhor esforço.
  • Planeamento da Largura de Banda: Os engenheiros devem calcular a largura de banda total do fluxo. Um fluxo de 8 canais de 24 bits, 48kHz, consome aproximadamente 9.2 Mbps. Uma rede que lida com 64 fluxos requer quase 600 Mbps de largura de banda de áudio dedicada. O planejamento adequado impede a sobre-assinatura de uplinks.

Interoperabilidade na prática

O objetivo principal do AES67 é fazer diferentes equipamentos de fabricantes trabalharem juntos. Isto é normalmente habilitado em dispositivos através de um "Modo AES67". Por exemplo, os dispositivos Dante podem ser configurados para saída ou aceitar fluxos AES67, embora muitas vezes com uma restrição na contagem de canais ou tempo de pacotes em comparação com fluxos Dante nativos. Os dispositivos Livewire+ e Q-LAN podem interface semelhante através do AES67.

Problemas comuns de interoperabilidade geralmente surgem de configurações descombinadas. Um transmissor que envia pacotes de 1ms pode não ser compatível com um receptor que suporta apenas pacotes de 4ms. O alinhamento do domínio do relógio é outro desafio frequente; todos os dispositivos devem ser bloqueados para o mesmo grande mestre de PTP. Os engenheiros de rede devem prestar atenção aos parâmetros SDP anunciados por cada dispositivo e garantir que a infraestrutura de rede (perfis de PTP, valores de DSCP e configuração de VLAN) é consistente em todo o sistema. Especificações IETF do PTPv2 e o Norma IEEE 1588-2008.

Guias práticos de configuração estão disponíveis a partir Recursos do Audinate AES67.

Conclusão

AES67 representa um padrão fundamental para o moderno e interoperável ecossistema de áudio-over-IP. Ao quebrar a estrutura de pacotes – do frame Ethernet e do cabeçalho RTP até o timestamp de PTP e a carga de áudio – podemos ver como cada camada contribui para a transmissão robusta e de baixa latência de áudio profissional. A mecânica do fluxo de dados, impulsionada pelo timing preciso e pelo cuidadoso gerenciamento de buffers, garante que o áudio seja fornecido de forma confiável em topologias de rede complexas. Para profissionais de áudio, mover-se para além de uma compreensão de caixa preta dessas tecnologias é essencial. Dominar os princípios da estrutura de pacotes, sincronização e configuração de rede é a chave para implantar e manter sistemas AoIP de alto desempenho e escalável que suportam o teste do tempo.