Die Network Transport Foundation von AES67

AES67 erfindet die Vernetzung nicht neu. Es funktioniert als ein Profil, das spezifische, bewährte Technologien aus der Standard-Internet-Protokollsuite auswählt. Der Protokollstapel wurde entwickelt, um niedrige Latenz und Echtzeit-Bereitstellung über Zuverlässigkeitsmechanismen zu priorisieren, die Verzögerungen einführen. Diese grundlegende Design-Entscheidung diktiert die gesamte Paketstruktur.

Warum RTP/UDP/IP?

AES67 schreibt die Verwendung der Echtzeit-Transportprotokoll (RTP) über User Datagram Protocol (UDP) über Internet Protocol (IP)Diese Kombination wird bewusst über TCP gewählt. Während TCP eine garantierte Lieferung durch Retransmission bietet, führen diese Retransmissionen variable Latenz und Jitter ein, die für Live-Audio inakzeptabel sind. RTP bietet die notwendigen Sequenzierungs- und Timing-Informationen für Echtzeit-Streams, während UDP eine schnelle, verbindungslose Transportschicht bietet. AES67 verwendet speziell IP-Multicast, so dass eine einzelne Audioquelle an mehrere Empfänger verteilt werden kann, ohne Daten auf dem Kabel zu duplizieren, was sie sehr effizient für die Punkt-zu-Mehrpunkt-Verteilung macht.

Anatomie eines AES67-Pakets

Ein AES67-Paket besteht aus einer Folge von Headern, die eine Nutzlast von Audio-Samples umschließen. Das Verständnis der Funktion jedes Header-Feldes ist entscheidend für die Fehlerbehebung von Paketverlust, Latenzproblemen und Synchronisationsfehlern. Die Gesamtpaketgröße wird durch die Ethernet Maximum Transmission Unit (MTU) begrenzt, typischerweise 1500 Bytes, was die Anzahl der Audiokanäle oder Samples pro Paket begrenzt.

Ethernet-Rahmen (Schicht 2)

Die Reise beginnt auf der physischen Ebene. Der Ethernet-Header enthält die Quelle und das Ziel MAC-AdressenIn einem Multicast-Stream ist die Ziel-MAC-Adresse eine von der IP-Multicast-Gruppe abgeleitete Multicast-Adresse, typischerweise im Bereich von 01:00:5E: Switches verwenden diese Adresse, um den Datenverkehr effizient weiterzuleiten. 802.1Q VLAN Tag, die für die Trennung des Audioverkehrs von anderen Netzwerkdaten und für die Übertragung von Priority Code Point (PCP)-Bits für Quality of Service (QoS) sehr empfohlen wird. Das EtherType-Feld (0x0800 für IPv4 oder 0x86DD für IPv6) identifiziert das Netzwerkschichtprotokoll.

IP-Header (Schicht 3)

Der IP-Header verwaltet logische Adressierung und Routing. AES67 verwendet typischerweise IPv4-Multicast-Adressen im 239.0.0.0 bis 239.255.255.255 Bereich (administrativ erfasst). Differentiated Services Code Point (DSCP) Ein Feld ist vielleicht das kritischste Byte im IP-Header für Audioqualität. AES67 empfiehlt einen bestimmten DSCP-Wert (typischerweise) EF - Beschleunigte Weiterleitung, oder AF41) um sicherzustellen, dass Audiopakete vorrangig über Switches und Router hinweg behandelt werden.

UDP Header (Schicht 4)

Der UDP-Header ist minimal, aber wichtig. Er liefert Quell- und Zielportnummern. Der Zielport wird vom Empfänger verwendet, um den ankommenden Stream in die richtige Anwendung zu demultiplexen. Die 16-Bit-Prüfsumme bietet grundlegende Fehlererkennung für das UDP-Datagramm und seine Nutzlast. Da UDP verbindungslos ist, gibt es keinen Handshake, der einen sofortigen Datenfluss ermöglicht.

Der RTP-Header

Der RTP-Header ist das Herzstück des AES67-Pakets und stellt die Mechanismen für die Ordnung, das Timing und die Identifizierung der Nutzlast bereit.

  • Version (V), Padding (P), Extension (X): Standard-Flags: AES67 verwendet normalerweise keine Header-Erweiterung.
  • CSRC Count (CC): Bestimmt die Anzahl der beitragenden Quellen, in der Regel Null in einem Standard-AES67-Stream.
  • Markierung (M): Wird verwendet, um Grenzen zu signalisieren, wie z. B. den Beginn eines Gesprächsschubs oder eine Videorahmengrenze in ST 2110-30.
  • Nutzlasttyp (PT): Identifiziert das Format der Audiokodierung. L16 (Lineares PCM 16-Bit) oder L24 (Lineares PCM 24-Bit), häufig mit dynamischen Nutzlast-Typnummern (z. B. 96 oder 97), die über SDP ausgehandelt werden.
  • Laufende Nummer: Die Jitter-Puffer-Logik dient als primäres Werkzeug zur Erkennung von Paketverlusten, Fehlordnungen und zur Verwaltung des Jitterpuffers auf der Empfangsseite. Die Jitter-Puffer-Logik dient zur Umwicklung der Sequenznummer.
  • Zeitstempel: Dieser Zeitstempel wird direkt aus dem Abtastzeitpunkt des ersten Abtastwertes im Paket abgeleitet. PTP-UhrEin 48 kHz-Stream erhöht diesen Zeitstempel um 48 Ticks pro Millisekunde oder 48 Ticks pro Abtastperiode.
  • Synchronisationsquelle (SSRC): Eine eindeutige 32-Bit-Kennung für die Quelle des Stroms, die verwendet wird, um mehrere Ströme von derselben Quelle zu unterscheiden.

Audio Payload

Die Nutzlast enthält die rohen oder kodierten Audio-Samples. AES67 beauftragt die Unterstützung für Lineares PCM Die Nutzlast kann auch das AM824-Format (Audio über USB) übertragen. Die Anzahl der Abtastwerte pro Paket wird durch die Anzahl der Abtastwerte pro Paket bestimmt. Paketzeit (ptime). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Präzisions-Timing mit PTPv2 (IEEE 1588)

Die Synchronisation ist der schwierigste Aspekt von AoIP. AES67 schreibt die Verwendung des IEEE 1588-2008 Precision Time Protocol (PTPv2) Damit wird sichergestellt, dass die Abtastuhr des Senders und die Abtastuhr des Empfängers perfekt synchronisiert sind, wodurch Pufferunterläufe oder Überläufe verhindert werden, die hörbare Klicks und Pops verursachen.

Der beste Master Clock Algorithmus

Jedes PTP-fähige Gerät im Netzwerk läuft mit dem Best Master Clock Algorithm (BMCA) und analysiert die Attribute der Uhrqualität wie Uhrklasse, Uhrgenauigkeit und Priorität, um eine einzelne Uhr auszuwählen. Uhr des Großmeisters (GM)Alle anderen Geräte synchronisieren sich mit dem GM. In einem richtig konzipierten System ist der GM oft ein dediziertes, hochstabiles Gerät (z. B. ein GPS-gesperrter Master-Clock-Generator). Der BMCA bietet auch ein automatisches Failover; wenn der GM ausfällt, wird ein neuer GM von den verbleibenden Geräten gewählt.

PTP-Nachrichtenaustausch

PTPv2 definiert eine bestimmte Nachrichtensequenz, um die Uhrendrift zu korrigieren. Sync Es folgt sofort mit einer Nachricht. Folge Nach oben Die Nachricht, die die genaue Uhrzeit des Syncs enthält, sendet das Slave-Gerät eine Delay Req Die Nachricht und die Zeit, die es gesendet wird. Der GM antwortet mit einem Verzögerung Resp. Die Daten werden in der Regel in einer Weise angezeigt, dass die Daten in der Regel in einer Weise angezeigt werden, die die Daten in einer bestimmten Zeit anzeigt.

Session Discovery mit SAP und SDP

Wie findet ein Empfänger einen verfügbaren AES67-Stream? Session Announcement Protocol (SAP) AES67 Sender senden periodisch eine SAP-Ankündigung an eine bekannte SAP-Adresse, die eine Sitzungsbeschreibungsprotokoll (SDP) Nutzlast.

Die SDP-Datei ist das Rezept für den Stream. Sie enthält alle Metadaten, die ein Empfänger zum Verbinden, Synchronisieren und Dekodieren des Audios benötigt.

  • Medienbeschreibung: definiert den Medientyp, Port und Transport (RTP/AVP).
  • Anschlussdaten: gibt die Multicast-Gruppen-IP-Adresse an.
  • Attribute:
    • ptime: Paketzeit in Millisekunden (z. B. 1,0).
    • rtpmap: Bildet den Nutzlasttyp einer Kodierung zu (z. B. bedeutet 2 Kanäle mit 24-Bit-PCM bei 48 kHz).
    • Medienuhr: oder eine spezifische PTP-Zeitstempelreferenz.
    • Playout-Verzögerung: verbindet die Stream-Uhr mit dem PTP-Großmeister.
    • Channel Order: Während SMPTE ST 2110-30 die Kanalbestellung für AES67 spezifiziert, verlassen sich viele Streams auf eine einvernehmlich vereinbarte Kanalkarte.

Datenflussmechanik

Der Fluss von Audiodaten von der Quelle zur Senke ist ein kontinuierlicher, eng orchestrierter Prozess. Das Verständnis der Sender- und Empfängeroperationen ist der Schlüssel zur Diagnose von Netzwerk- oder Audioartefakten.

Senderbetrieb

Die Audioschnittstelle digitalisiert analoge Audio-Samples mit einer konstanten Rate (z.B. 48 kHz). Der Treiber des Senders liest diese Samples von der Hardware und legt sie in einen Puffer. Bei jedem Paketintervall (z.B. alle 1 ms) kapselt der Treiber einen Block von Samples in ein RTP-Paket. Die Sequenznummer wird inkrementiert und der Zeitstempel wird auf die PTP-ausgerichtete Sample-Zählung gesetzt. Das Paket wird dann in UDP- und IP-Header eingewickelt, mit dem richtigen DSCP-Wert markiert und an die konfigurierte Multicast-MAC-Adresse gesendet.

Sender müssen eine stabile, PTP-gesperrte Sample-Uhr beibehalten, um ein konsistentes Paket-Timing zu gewährleisten.

Receiver Operations und Jitter Management

Das Empfangsgerät horcht auf SAP-Ankündigungen, der Nutzer wählt einen Stream aus und der Empfänger abonniert die Multicast-Gruppe mit IGMP (Internet Group Management Protocol)Wenn die Pakete einmal abonniert sind, werden sie ankommen, aber die Netzwerk-Switches führen variable Verzögerungen ein (Jitter). Die erste Aufgabe des Empfängers besteht darin, eingehende Pakete in eine JitterpufferDieser Puffer glättet die Netzwerkverzögerungsvariationen.

  • Jitterpuffergröße: Der Puffer muss groß genug sein, um den Worst-Case-Netzwerkjitter ohne Unterlaufen zu absorbieren, aber klein genug, um die Latenz zu begrenzen.
  • Prüfung der Laufzahl: Der Empfänger überwacht Sequenznummern auf Lücken, die auf verlorene Pakete hinweisen, und kann diese auch zur Neuordnung von Paketen verwenden.
  • Uhrenwiederherstellung (PLL): Der Empfänger verwendet die vom PTP-Takt abgeleiteten RTP-Zeitstempel, um einen Phase-Locked Loop (PLL) anzusteuern, der den Sample-Takt des Senders rekonstruiert und so sicherstellt, dass sein interner DAC (Digital-to-Analog Converter) in perfekter Synchronisation mit der Quelle läuft.

Umgang mit Latenz und Verlust

Latenz in einem AES67-Netzwerk ist die Summe mehrerer Faktoren: Abtastverzögerung, Paketisierungsverzögerung (ptime), Netzwerktransitverzögerung (Uplinks, Warteschlangen), Jitterpufferverzögerung und Verarbeitungsverzögerung. Eine 1ms ptime mit einer Gesamtend-zu-End-Latenz von 5ms ist in einem gut abgestimmten Netzwerk erreichbar. Während AES67 keine spezifische Vorwärtsfehlerkorrektur (FEC) vorschreibt, unterstützt es RTP-Redundanz (RFC 2198). Häufiger verwenden Hochverfügbarkeitssysteme eine redundante Netzwerktopologie (dual redundant networks), bei der der Sender zwei identische Streams (Stream A und Stream B) über separate Netzwerkpfade sendet, wobei er mit SMPTE ST 2022-7 nahtlose Schutzschaltung ausgerichtet ist.

Anforderungen an die Netzinfrastruktur

AES67 stellt hohe Anforderungen an die Netzwerkhardware. Standard Office-Grade-Switches sind für High-Channel-Count AoIP oft ungeeignet. Professionelle Managed Switches sind erforderlich.

  • IGMP-Schnüffel: Switches müssen IGMP-Nachrichten hören, um Multicast-Datenverkehr nur an Ports weiterzuleiten, die dies explizit angefordert haben.
  • PTP-Aware Switching: Um die Genauigkeit von Sub-Mikrosekunden in großen Netzwerken zu gewährleisten, sollten Switches die PTP-Funktionalität (Brandary Clock, BC) oder Transparent Clock (TC) unterstützen, was die Latenz berücksichtigt, die der Switch selbst in die PTP-Zeitmessnachrichten einführt.
  • Servicequalität (QoS): Die strikte QoS-Warteschlange (z. B. die strikte Priorität) muss auf allen Switch-Ports konfiguriert werden. PTP-Ereignismeldungen sollten die höchste Priorität (CS7) erhalten, gefolgt von Audio-Verkehr (EF oder AF41) und dann Best-Effort-Daten.
  • Bandbreitenplanung: Ingenieure müssen die gesamte Streambandbreite berechnen. Ein einzelner 24-Bit-, 48-kHz-, 8-Kanal-Stream verbraucht ungefähr 9,2 Mbit/s. Ein Netzwerk, das 64 solcher Streams verarbeitet, benötigt fast 600 Mbit/s dedizierte Audiobandbreite. Eine ordnungsgemäße Planung verhindert eine Überbelegung von Uplinks.

Interoperabilität in der Praxis

Das primäre Ziel von AES67 ist es, die Ausrüstung verschiedener Hersteller zum Zusammenwirken zu bringen. Dies wird typischerweise in Geräten über einen "AES67-Modus" aktiviert. Beispielsweise können Dante-Geräte konfiguriert werden, um AES67-Streams auszugeben oder zu akzeptieren, wenn auch oft mit einer Einschränkung der Kanalanzahl oder Paketzeit im Vergleich zu nativen Dante-Flows. Livewire + und Q-LAN-Geräte können ebenfalls über AES67 verbunden sein.

Häufige Interoperabilitätsprobleme ergeben sich häufig aus nicht übereinstimmenden Konfigurationen. Ein Sender, der 1ms-Pakete sendet, ist möglicherweise nicht mit einem Empfänger kompatibel, der nur 4ms-Pakete unterstützt. Die Ausrichtung der Uhrdomänen ist eine weitere häufige Herausforderung; alle Geräte müssen mit dem gleichen PTP-Großmeister gesperrt sein. Die Netzwerkingenieure müssen die von jedem Gerät angekündigten SDP-Parameter genau beachten und sicherstellen, dass die Netzwerkinfrastruktur (PTP-Profile, DSCP-Werte und VLAN-Konfiguration) im gesamten System konsistent ist. Weitere Informationen zu PTP-Profilen finden Sie unter IETF-Spezifikation für PTPv2 und die IEEE 1588-2008-StandardPraktische Konfigurationsführungen sind erhältlich bei AES67-Ressourcen von Audinate.

Schlussfolgerung

AES67 stellt einen grundlegenden Standard für das moderne, interoperable Audio-over-IP-Ökosystem dar. Durch die Aufschlüsselung der Paketstruktur - vom Ethernet-Frame und RTP-Header bis hin zum PTP-Zeitstempel und der Audio-Nutzlast - können wir sehen, wie jede Schicht zur robusten Übertragung von professionellem Audio mit niedriger Latenz beiträgt. Die Mechanik des Datenflusses, angetrieben durch präzises Timing und sorgfältiges Puffermanagement, stellt sicher, dass Audio zuverlässig über komplexe Netzwerktopologien hinweg geliefert wird. Für Audioprofis ist es wichtig, über das Black-Box-Verständnis dieser Technologien hinauszugehen. Die Beherrschung der Prinzipien der Paketstruktur, Synchronisation und Netzwerkkonfiguration ist der Schlüssel zum Einsatz und zur Aufrechterhaltung von hochleistungsfähigen, skalierbaren AoIP-Systemen, die den Test der Zeit bestehen.