Audio-Netzwerke sind zum Rückgrat moderner Live-Soundverstärkungs-, Broadcast-Produktions- und Studio-Aufnahmeumgebungen geworden. Da die Branche von traditionellen analogen Schlangen und dedizierten digitalen Bussen zu Ethernet-basierter Infrastruktur übergeht, war der Bedarf an zuverlässiger, hochtreuer Audioübertragung über Standard-IP-Netzwerke noch nie größer. Der AES67-Standard - offiziell mit dem Titel "AES67-2018: AES-Standard für Audioanwendungen von Netzwerken - Hochleistungs-Streaming-Audio-over-IP-Interoperabilität" - adressiert diesen Bedarf, indem er ein gemeinsames Framework bietet, das Audiogeräte verschiedener Hersteller nahtlos kommunizieren lässt. Eine entscheidende Komponente des Erfolgs von AES67 ist sein robuster Ansatz für die Servicequalität (QoS), der sicherstellt, dass zeitkritische Audiodaten intakt ankommen, in Ordnung und pünktlich, auch wenn das Netzwerk anderen Datenverkehr transportiert. Dieser Artikel untersucht jeden wesentlichen QoS-Mechanismus in AES67, bietet konkrete Konfigurationsleitlinien und erklärt, warum eine ordnungsgemäße QoS-Bereitstellung ein stabiles professionelles System von einem trennt, das von

Was ist Quality of Service (QoS) in AES67?

Quality of Service ist ein weit gefasster Begriff, der die Menge an Technologien und Mechanismen umfasst, die verwendet werden, um Netzwerkressourcen zu verwalten und bestimmte Arten von Datenflüssen zu priorisieren. In IP-Netzwerken werden alle Pakete standardmäßig gleich behandelt - eine Situation, die als "Best-Effort" -Bereitstellung bezeichnet wird. Während dies für das Surfen im Internet, E-Mail- oder Dateitransfers gut funktioniert, ist es für Echtzeit-Audiostreams völlig inakzeptabel, bei denen verspätete oder verlorene Pakete zu hörbaren Ausfällen, Störungen oder vollständigem Synchronisationsverlust führen. QoS ändert dies durch die Zuweisung höherer Priorität für Audiopakete, wodurch sichergestellt wird, dass sie vor weniger zeitkritischem Datenverkehr weitergeleitet werden. In einer AES67-Bereitstellung ist QoS kein optionales Add-on; der Standard schreibt bestimmte Verhaltensweisen vor, die sowohl Layer 3 (IP) als auch Layer 2 (Ethernet)-Prioritätsmechanismen unterstützen müssen.

Dieser zweischichtige Ansatz gibt Systementwicklern die Flexibilität, QoS in verschiedenen Netzwerkumgebungen zu implementieren, von einfachen Single-Switch

Die Rolle von QoS bei der Aufrechterhaltung der Audiointegrität

Warum ist QoS in einem AES67-Netzwerk so wichtig? Die Antwort liegt in der Natur von Audiopaketen. AES67-Streams tragen typischerweise mehrere Kanäle von unkomprimiertem Pulse-Code-Modulation (PCM)-Audio, mit Paketgrößen, die so konzipiert sind, dass sie die Latenz minimieren und gleichzeitig die Effizienz erhalten. Ein typischer AES67-Stream könnte Pakete alle 125 Mikrosekunden (für ein 8-Sample-Paket bei 48 kHz) oder alle 1 Millisekunde (für ein 48-Sample-Paket) senden. Jede signifikante Verzögerungsvariation - genannt "Jitter" - oder Paketverlust wird die Audioqualität beeinträchtigen.

QoS behebt diese Probleme direkt durch:

  • Latenz reduzieren: Die Prioritätswarteschlange sorgt dafür, dass Audiopakete weniger Zeit in Switch-Buffern warten. Wenn ein Datentransfer-Datenverkehr ankommt, werden nicht prioritäre Pakete in die Warteschlange gestellt, während Audiopakete nach vorne springen.
  • Jitter minimieren: Konsequente Weiterleitungsbehandlung über das Netzwerk hält Ankunftszeiten vorhersehbar. Audioempfänger können dann kleine Jitterpuffer (oft <1 ms) verwenden, ohne Unterschreitungen zu riskieren.
  • Paketverlust beseitigen: Durch die Reservierung von Bandbreite und Markierung von Paketen verhindert QoS, dass Staus Audiopakete zum Herunterfallen zwingen. Selbst ein einzelnes verlorenes Paket kann einen hörbaren Klick erzeugen, so dass Nullverlust das Ziel ist.

Neben diesen grundlegenden Vorteilen schützt QoS auch die Precision Time Protocol (PTP)-Pakete, die alle AES67-Geräte synchronisieren. Wenn das PTP-Timing verzögert oder verloren geht, verschlechtert sich die Uhrengenauigkeit des gesamten Netzwerks, was zu Pufferunterschreitungen oder Überschreitungen über jeden Audiostream führt. Eine gut konfigurierte QoS-Richtlinie behandelt den Timing-Datenverkehr mit der gleichen Dringlichkeit wie die Audio-Nutzlast.

QoS-Mechanismen definiert durch AES67

Der AES67-Standard nutzt mehrere etablierte Netzwerktechnologien, um seine QoS-Garantien zu erreichen. Diese Mechanismen arbeiten auf verschiedenen Ebenen des OSI-Modells und ergänzen sich gegenseitig, um eine zuverlässige Audiotransportschicht zu schaffen. Das Verständnis jedes Mechanismus und wie sie interagieren, ist für jeden, der AES67-Netzwerke entwirft, einsetzt oder Fehlerbehebung.

1. Differentiated Services Code Point (DSCP) – Schicht 3 QoS

DSCP ist der primäre Schicht-3-QoS-Mechanismus, der in AES67 verwendet wird. Er arbeitet, indem er einen 6-Bit-Wert in das Type of Service (ToS)-Byte jedes IP-Pakets einfügt. Router und Schicht-3-Switches können konfiguriert werden, um diese DSCP-Markierung zu untersuchen und Pakete in die entsprechende Prioritätswarteschlange zu legen. AES67 definiert drei spezifische DSCP-Werte für verschiedene Klassen von Datenverkehr:

  • AES67 Audio Streams – DSCP 46 (EF – Expedited Forwarding): EF sorgt für geringe Verzögerung, geringes Jitter und geringen Verlust - oft als "Premium" -Behandlung bezeichnet. In der Praxis sollte der EF-Verkehr überwacht werden, um zu verhindern, dass ein einzelner Stream die Prioritätswarteschlange überwindet.
  • AES67 Control and Discovery – DSCP 56 (CS7): Kontrollverkehr wie SAP-Ankündigungen und Verbindungsmanagement ist mit Class Selector 7 gekennzeichnet, um sicherzustellen, dass die kritische Signalisierung nicht blockiert wird. Obwohl Kontrollpakete klein sind, kann deren Verlust verhindern, dass Geräte sich gegenseitig entdecken oder eine Verbindung aufrechterhalten.
  • AES67 PTP (Precision Time Protocol) – DSCP 46 (EF) oder DSCP 44 (CS5): PTP-Pakete tragen Zeitinformationen, die alle Geräte synchronisieren müssen. Viele Implementierungen verwenden die gleiche EF-Markierung wie Audio oder eine etwas niedrigere Priorität wie CS5, um zu vermeiden, dass Audio gestört wird, wenn Warteschlangenressourcen knapp sind. Eine gängige Konfiguration besteht darin, PTP in eine dedizierte Warteschlangen mit strikter Priorität mit einer sehr geringen Bandbreitengarantie zu stellen, um sicherzustellen, dass es vor allem außer Audio bedient wird.

Netzwerkadministratoren müssen überprüfen, ob ihre Switches und Router diese DSCP-Markierungen einhalten. Leider haben viele Switches auf Unternehmensebene unterschiedliche Standard-Vertrauensmodelle: einige vertrauen nur Layer 2 QoS (802.1p), während andere so konfiguriert werden können, dass sie DSCP vertrauen. Eine korrekte Konfiguration ist unerlässlich, um zu verhindern, dass Audiopakete neu markiert oder auf Best-Effort herabgestuft werden. Zum Beispiel wird ein Cisco-Switch, der auf „untrusted“ an einem Access-Port eingestellt ist, das DSCP-Feld auf Null setzen und sofort die Priorität zerstören. Setzen Sie die Vertrauensgrenze immer auf „dscp“ an Ports, an denen AES67-Endpunkte angeschlossen sind.

2. IEEE 802.1Q VLAN Tagging und Priority Code Points (PCP) – Schicht 2 QoS

Auf Schicht 2 schreibt AES67 die Verwendung von IEEE 802.1Q VLAN-Tagging für Audiostreams vor. Ein VLAN-Tag enthält ein 3-Bit-Priority Code Point (PCP)-Feld, das acht Prioritätsstufen (0 bis 7) angeben kann. Der AES67-Standard empfiehlt einen PCP-Wert von 5 für Audio-Traffic, was "kritischen Anwendungen" in der 802.1Q-Prioritätsabbildung entspricht. Diese Tagging dient zwei Zwecken:

  • Segregierender Audio-Traffic: Durch das Einfügen von Audio in ein dediziertes VLAN wird es von Broadcast-Stürmen, Multicast-Rauschen und anderem Datenverkehr isoliert, der zu Staus führen könnte. Ein separates VLAN vereinfacht auch die Anwendung von Sicherheits-ACLs und die Überwachung der Bandbreitennutzung.
  • Per-Hop-Priorisierung: Ethernet-Switches, die DSCP nicht unterstützen, können den PCP-Wert weiterhin verwenden, um Audiopakete gegenüber anderen VLANs oder nicht markiertem Datenverkehr zu priorisieren. Selbst wenn DSCP vertrauenswürdig ist, bietet Layer 2-Priorität einen Fallback-Mechanismus für einfachere Switches.

Es ist wichtig zu beachten, dass VLAN-Tagging allein nicht für Ende-zu-Ende-QoS in gerouteten Netzwerken ausreicht. Die PCP-Markierung wird entfernt, wenn ein Paket einen Router durchquert, es sei denn, Switch und Router sind so konfiguriert, dass sie die Priorität der Schicht 2 auf DSCP abbilden. Daher muss ein robustes AES67-Netzwerk eine konsistente QoS-Konfiguration über beide Schichten hinweg haben. Viele Ingenieure verwenden eine Policy Map auf der gerouteten Schnittstelle, die PCP in DSCP kopiert, oder sie verlassen sich darauf, dass der Endpunkt die DSCP korrekt einstellt, so dass die Priorität der Schicht 2 daraus abgeleitet wird.

3. Reservierungs- und Zulassungskontrolle für Bandbreiten

Obwohl es sich nicht unbedingt um einen QoS-"Mechanismus" im gleichen Sinne wie DSCP handelt, fördert AES67 die Verwendung von Bandbreitenreservierungstechniken, um eine Überbuchung von Netzwerkverbindungen zu verhindern. Der Standard definiert eine maximal zulässige Bandbreite für AES67-Streams über ein bestimmtes Netzwerksegment, typischerweise 100 Mbit/s für Gigabit-Ethernet, um Headroom für anderen Datenverkehr zu verlassen. Netzwerkingenieure können Protokolle wie das Resource Reservation Protocol (RSVP) verwenden, um dynamisch Bandbreite für Audioflüsse anzufordern, obwohl RSVP in AES67 nicht obligatorisch ist. In der Praxis wird manuelle Bandbreitenplanung oft bevorzugt, um deterministisches Verhalten zu gewährleisten. Wenn Sie beispielsweise 48 Kanäle bei 24-Bit-, 48 kHz-, verbrauchen jeder Stream etwa 24 Mbit/s (einschließlich Header).

Auf einer 1-Gbit/s-Verbindung könnten Sie theoretisch 40 solcher Streams ausführen, aber QoS-Richtlinien und praktische Headroom legen eine Grenze von etwa 80% für die Prioritätswarteschlange vor. Die Zutrittskontrolle wird wichtig, wenn mehrere Multicast-Gruppen vorhanden sind.

4. Precision Time Protocol (PTP) und seine Beziehung zu QoS

Die genaue Zeitsynchronisation ist ein Eckpfeiler von AES67. Alle Geräte müssen mit einer gemeinsamen Uhr synchronisieren, indem sie IEEE 1588-2008 (PTPv2) verwenden. PTP-Pakete sind selbst zeitkritisch; wenn sie verzögert oder verloren gehen, verschlechtert sich die Taktgenauigkeit, was zu Pufferunterläufen oder Überläufen führt. QoS gilt daher auch für PTP-Verkehr. AES67 empfiehlt, PTP mit dem gleichen beschleunigten Weiterleitungs-DSCP wie Audio (46) oder mindestens mit einer Class Selector 5 (CS5, DSCP 40) zu markieren.

Viele reale Bereitstellungen widmen PTP eine separate VLAN- oder Multicast-Gruppe, um sie von anderem Verkehr zu isolieren, was die Wahrscheinlichkeit von Verzögerungsschwankungen weiter verringert. Zusätzlich können Switches, die PTP-Grenzuhren oder transparente Uhren unterstützen, Brückenverzögerungen korrigieren, aber diese Funktionen erfordern eine korrekte Funktion von QoS. Ohne ordnungsgemäße Priorität können PTP-Pakete durch Warteschlangen verzögert werden, was eine transparente Uhr dann falsch ausgleicht, was zu Synchronisationsfehlern führt.

Warum QoS für professionelle Audionetzwerke nicht verhandelbar ist

In jeder professionellen Audioanwendung, vom Broadway-Musical bis zur Live-Nachrichtensendung, sind die Toleranzen für Latenz, Jitter und Paketverlust extrem eng. Das menschliche Ohr kann sogar ein einzelnes verlorenes Paket erkennen, wenn es zu einem Klick oder Pop führt, und Jitter von nur wenigen Millisekunden kann zu hörbaren Verzerrungen oder zur Störung der Synchronisation zwischen Lautsprechern führen. QoS-Mechanismen bieten die notwendigen Leitplanken, um sicherzustellen, dass AES67-Netzwerke diese hohen Anforderungen erfüllen. Ohne QoS kann ein Netzwerk, das während einer ruhigen Probe perfekt funktioniert, katastrophal während einer Performance scheitern, wenn Beleuchtungskonsolen, Videoserver und Dateiübertragungen alle um Bandbreite konkurrieren.

Latenzbudgets im Live Sound

Bei der Live-Soundverstärkung muss die End-to-End-Latenz typischerweise unter 10 Millisekunden und oft viel weniger bleiben. Jeder Netzwerk-Hop - Switch, Router oder Kabel - fügt eine kleine Latenz hinzu. Ohne QoS kann ein Datensprung aus einem Dateitransfer oder Videostrom Schaltpuffer füllen, wodurch Audiopakete hinter Dutzenden von Nicht-Audiopaketen Schlange stehen. Dieser "Bufferbloat" kann Dutzende Millisekunden unvorhersehbarer Verzögerung hinzufügen, wodurch das System unbrauchbar wird. Mit den richtigen DSCP- und PCP-Markierungen umgehen Audiopakete diese Warteschlangen, wobei die Latenz konsistent und niedrig bleibt.

In einem gut abgestimmten Netzwerk sollte die zusätzliche Latenz aufgrund von Warteschlangen für Audio unter 100 Mikrosekunden pro Hop liegen.

Auswirkungen des Paketverlusts auf die Audio-Fidelity

AES67 verwendet das Echtzeit-Transportprotokoll (RTP) über UDP, das keine verlorenen Pakete wieder überträgt. Folglich korrumpiert jeder Paketverlust direkt die Audiowellenform. Während einige Empfangsgeräte eine kleine Anzahl aufeinanderfolgender verlorener Samples verbergen können, kann ein anhaltender Verlust von sogar 0,1% der Pakete hörbar sein. QoS verhindert Verluste, indem sichergestellt wird, dass das Netzwerk niemals einen Punkt erreicht, an dem Audiopakete aufgrund von Staus verworfen werden. Dies ist besonders kritisch in Multicast-Umgebungen, in denen ein verlorenes Paket Hunderte von nachgelagerten Geräten betreffen kann.

Ein einzelner Tropfen kann sich als kurze Stille oder ein Klick in allen Kanälen dieser Multicast-Gruppe manifestieren, was in einem Broadcast- oder Performance-Szenario inakzeptabel ist.

Synchronisation und Uhrenstabilität

Die Daten des PTP-Timings werden auch über UDP übertragen und sind gleichermaßen anfällig für Verzögerung und Verlust. Ein stark überlastetes Netzwerk kann dazu führen, dass PTP-Pakete zu spät ankommen, was dazu führt, dass die Taktwiederherstellungsalgorithmen in Empfängern driften. Im Laufe der Zeit führt diese Drift zu Pufferüberläufen oder -unterläufen, die sich als Störungen oder Stille manifestieren. Durch die Anwendung einer großzügigen QoS-Behandlung auf den PTP-Verkehr stellen die Netzwerkingenieure sicher, dass alle Geräte genau synchronisiert bleiben, oft bis zu einer Genauigkeit von Submikrosekunden, wie von AES67 gefordert. Einige Implementierungen verwenden ein dediziertes PTP-Profil (wie SMPTE ST 2110-10), das die Timing-Anforderungen weiter verschärft und QoS noch kritischer macht.

QoS in einem AES67-Netzwerk implementieren – Best Practices

Die Implementierung eines erfolgreichen AES67-Netzwerks erfordert eine sorgfältige Konfiguration an jedem Netzwerkgerät entlang des Datenpfads. Im Folgenden finden Sie konkrete Schritte und Überlegungen zur Implementierung von QoS, die den AES67-Empfehlungen entsprechen. Diese Schritte gehen von einem verwalteten Layer 2/3-Netzwerk mit Hardware aus, das Standard-QoS-Funktionen unterstützt. Die Prinzipien gelten für Cisco, Arista, Juniper, HP und die meisten anderen Switch-Familien von Unternehmen.

Schritt 1: Vertrauen Sie den richtigen Markierungen

Moderne verwaltete Switches können so konfiguriert werden, dass sie DSCP-Werten von eingehenden Paketen vertrauen. Diese "Vertrauensgrenze" muss an den Switch-Ports festgelegt werden, die mit AES67-Endpunkten verbunden sind. Wenn ein Switch-Port auf "untrusted" eingestellt ist (der Standard bei vielen Unternehmens-Switches), wird der Switch den DSCP-Wert auf Null ummarkieren, wodurch die Priorität wegfällt. Konfigurieren Sie immer Zugriffsports, die mit Audiogeräten mit (Cisco) oder gleichwertigen Befehlen anderer Marken verbunden sind. Für Verbindungsleitungen zu anderen Switches sollte das Vertrauen auch aufrechterhalten werden, obwohl einige Administratoren es vorziehen, eine bestimmte Richtlinie an diesen Punkten mit einer Per-Port-Richtlinienkarte durchzusetzen.

Es ist auch ratsam, ACLs zu konfigurieren, die nur hohe DSCP-Markierungen von bekannten IP-Adressen von AES67-Geräten zulassen, wodurch verhindert wird, dass Rogue-Datenverkehr Priorität beansprucht.

Schritt 2: Zuordnung der Priorität von Schicht 2 zu Schicht 3 konsistent

Nicht alle Switches inspizieren DSCP – insbesondere jene in der Zugriffsebene, die nur auf 802.1p PCP schauen. Um die Lücke zu schließen, können Sie eine Mapping-Richtlinie erstellen, die ankommende PCP in DSCP-Markierung auf gerouteten Schnittstellen umwandelt. Dies stellt sicher, dass, wenn ein Paket eine Layer-3-Grenze verlässt, sein DSCP-Tag korrekt ist. Umgekehrt kann der DSCP beim Ausstieg bei Bedarf zurück in PCP übersetzt werden. Zum Beispiel können Sie bei einem Cisco-Switch eine Klassenkarte konfigurieren, die mit PCP 5 übereinstimmt und DSCP 46 setzt.

Diese Mapping sollte auf alle Schnittstellen angewendet werden, bei denen AES67-Verkehr erwartet wird. Konsistente End-to-End-Priorität ist die häufigste Ursache für QoS-Ausfälle in Audionetzwerken.

Schritt 3: Reservebandbreite für Audiostreams

Obwohl AES67-Streams relativ klein sind - ein 48-Kanal-Stream mit 24 Bit, 48 kHz könnte etwa 24 Mbit/s verbrauchen - kann das Zusammenführen vieler Streams eine Netzwerkverbindung schnell sättigen. Verwenden Sie die DSCP EF-Markierung, um eine minimale Bandbreite für Audio zu garantieren. Viele Switch-Plattformen unterstützen Warteschlangenmechanismen wie Priority Queuing (PQ) oder Low-Latency Queuing (LLQ). Audio-Verkehr sollte in die Warteschlange mit strenger Priorität gelegt werden, aber achten Sie darauf, dass Sie nicht zu viel abonniert werden: Wenn die Prioritätswarteschlange mehr Datenverkehr empfängt, als der Link tragen kann, werden Schwanztropfen auftreten. Setzen Sie einen Polizisten ein, um den Audio-Verkehr auf ein bekanntes Maximum zu begrenzen, z. B. 80% der Linkbandbreite, um einen solchen Hunger zu verhindern.

Für eine 1 Gbit/s-Verbindung ergeben diese 800 Mbit/s für Audio, was normalerweise weit mehr als genug ist, aber der Polizist stellt sicher, dass eine Fehlkonfiguration oder ein Fehler die Prioritätswarteschlange

Schritt 4: Isolieren Sie PTP auf einem dedizierten VLAN

Obwohl PTP-Verkehr DSCP EF oder CS5 verwendet, ziehen es viele Ingenieure vor, ihn weiter zu trennen, indem PTP in eine dedizierte Multicast-Gruppe und VLAN platziert wird. Diese Praxis vereinfacht die Fehlersuche und verhindert, dass sich Steuerdaten mit Audio-Nutzlast vermischen. Das PTP-VLAN sollte auch eine hohe QoS-Priorität erhalten, möglicherweise mit einem noch strengeren Polizisten, um sicherzustellen, dass Timing-Pakete niemals durch große Multicast-Audioströme verzögert werden. Einige Netzwerke gehen so weit, dass sie eine separate PTP-Multicast-Adresse und ein separates VLAN nur für das Timing verwenden mit einer eigenen Prioritätswarteschlange. Diese Isolation hilft auch bei der Verwendung von PTP-Grenzuhren, die PTP-Nachrichten ohne Störungen des Audio-Verkehrs verarbeiten müssen.

Schritt 5: Testen und Validieren

Nach der Konfiguration ist ein gründliches Testen unerlässlich. Tools wie iPerf können synthetischen Hintergrundverkehr erzeugen, um das Netzwerk zu laden, während die eigenen Diagnoseprotokolle des AES67-Geräts Jitter, Latenz und Paketverlust melden können. Darüber hinaus können kostenlose Ethernet-Analysetools (z. B. Wireshark) DSCP-Markierungen erfassen und bestätigen, dass die Priorität korrekt verbreitet wird. Ein nützlicher Feldtest besteht darin, Audio zu streamen, während gleichzeitig eine große Dateiübertragung über denselben Switch ausgeführt wird. Wenn das Audio sauber bleibt, funktioniert die QoS-Richtlinie.

Fortgeschrittenere Tests können das Einspeisen unterschiedlicher Mengen Hintergrundverkehr beinhalten, indem ein Netzwerk-Beeinträchtigungsemulator die Jittertoleranz überprüft. Testen Sie immer mit den schlimmsten Multicast-Gruppenzahlen und der maximalen Anzahl gleichzeitiger Audiokanäle, die in der Produktion erwartet werden.

Zusätzliche Überlegungen: Multicast und IGMP Snooping

AES67 verwendet üblicherweise IP-Multicast, um Audio effizient an mehrere Empfänger zu verteilen. Während Multicast selbst die QoS-Markierungen nicht ändert, interagiert er mit QoS auf wichtige Weise. Switches mit IGMP-Snooping müssen aktiviert sein, um Multicast-Fluts an allen Ports zu verhindern, aber die QoS-Vertrauensgrenze muss immer noch auf den Multicast-Verkehr angewendet werden. Viele Switches behandeln Multicast-Verkehr unterschiedlich in ihren Switching-ASICs; Sie müssen möglicherweise QoS explizit für Multicast-Gruppen aktivieren. Stellen Sie außerdem sicher, dass das Multicast-Routing-Protokoll (z. B. PIM) die DSCP-Werte beim Weiterleiten zwischen VLANs oder Subnetzen nicht ändert.

Einige Router entfernen oder markieren DSCP standardmäßig auf geroutetem Multicast-Verkehr, was die End-to-End-Priorität unterbrechen würde.

AES67 QoS im Vergleich zu anderen Audio Networking Protokollen

AES67 ist nicht der einzige Audio-over-IP-Standard – andere sind Dante, AVB/TSN und Ravenna. Zu verstehen, wie sich QoS zwischen ihnen unterscheidet, kann Systementwicklern helfen, die richtige Plattform für eine bestimmte Anwendung zu wählen.

Dante verwendet ein proprietäres QoS-Schema mit DSCP 46 für Audio und DSCP 56 für Steuerung, sehr ähnlich wie AES67. Dante verwendet jedoch auch ein proprietäres Discovery-Protokoll und ein Link-Local-Timing anstelle von PTP. Die QoS-Implementierung ist eng in die Hardware von Audinate integriert, was die Bereitstellung etwas einfacher, aber weniger flexibel in heterogenen Netzwerken macht. Dante-Geräte erfordern oft dedizierte Switches oder eine spezifische Konfiguration, um sicherzustellen, dass die interne Warteschlangenabbildung korrekt ist. In der Praxis funktionieren viele Dante-Netzwerke einwandfrei mit den gleichen DSCP-Vertrauenseinstellungen wie AES67.

AVB (Audio Video Bridging) / TSN (Time-Sensitive Networking) AES67 ist ein Set von IEEE-Standards, das QoS-Mechanismen wie kreditbasierte Gestaltung und strenge Priorität beinhaltet. AVB benötigt kompatible Switches, die das gesamte TSN-Toolkit unterstützen, einschließlich 802.1Qat (Stream Reservation Protocol) und 802.1Qav (Forwarding and Queuing). Im Gegensatz zu AES67 garantiert AVB Bandbreite, indem es es a priori reserviert, was deterministisches Verhalten auch bei überlasteten Verbindungen bietet. AVB-Switches sind jedoch teurer und weniger verbreitet als standardmäßige verwaltete Switches. AES67 kann über AVB-Netzwerke laufen, erfordert jedoch kein TSN, was es zugänglicher, aber weniger deterministisch macht in gemeinsamen Netzwerken ohne TSN-Switches.

RavennaDie von ALC NetX entwickelten QoS-Empfehlungen sind nahezu identisch: DSCP 46 für Audio, DSCP 56 für Steuerung und PTP mit hoher Priorität. Ravenna-Netzwerke profitieren von den gleichen QoS-Praktiken, die hier diskutiert werden. Einige Ravenna-Implementierungen fügen proprietäre Jitterpufferoptimierungen hinzu, die größere Verzögerungsvariationen tolerieren können, aber das Prinzip der korrekten Markierung von Paketen bleibt gleich.

Häufige Fallstricke und Fehlerbehebung QoS in AES67

Selbst bei sorgfältiger Planung können QoS-Probleme auftreten, die am häufigsten sind:

  • Switch Trust Fehlkonfiguration: Wenn das Netzwerkgerät DSCP-Markierungen vom Endpunkt aus nicht vertraut, geht die Priorität verloren.
  • Mismatched Warteschlangenpolitik: Einige Switches verwenden eine feste Prioritätsreihenfolge, andere verwenden gewichtetes Round Robin (WRR). Audio-Verkehr muss in der Warteschlange mit strikter Priorität (Warteschlange 4 oder 5 auf vielen Plattformen) platziert werden.
  • Interferenz von Rogue-Anwendungen: Jedes Gerät im Netzwerk kann Pakete mit hohen DSCP-Werten senden. Ein falsch konfigurierter Drucker oder Server kann dazu führen, dass Prioritätswarteschlangen überlaufen. Verwenden Sie ACLs, um DSCP-Markierungen mit hoher Priorität auf bekannte AES67-Endpunkte zu beschränken. Erwägen Sie die Implementierung einer DiffServ-Richtlinie, die DSCP 46 nur von den MAC-Adressen oder IP-Subnetzen von Audiogeräten erlaubt.
  • PTP-Timing über VLANs: Wenn PTP-Pakete VLAN-Grenzen überschreiten müssen (über einen Router oder Layer-3-Switch), muss das Gerät PTP-fähig sein oder Border-Clock-Funktionalität unterstützen. Andernfalls führt der Switch Latenz und Jitter ein, die QoS allein nicht beheben kann.
  • Staus in der Prioritätswarteschlange selbst: Selbst bei der Polizei kann ein Burst zu Schwanzverlusten innerhalb der Prioritätswarteschlange führen, wenn der Shaper zu aggressiv eingestellt ist.

Externe Ressourcen für weitere Lesung

Für einen tieferen Einblick in AES67 und seine QoS-Mechanismen werden folgende Ressourcen empfohlen:

Schlussfolgerung

Die in AES67 definierten Quality of Service-Mechanismen sind nicht nur Empfehlungen – sie sind unerlässlich für die Bereitstellung von professionellem Audio über IP-Netzwerke. Durch die Nutzung von DSCP-Markierungen auf Schicht 3, 802.1Q PCP-Tags auf Schicht 2, sorgfältige Bandbreitenplanung und ein angemessenes PTP-Timing können Systemintegratoren Netzwerke aufbauen, die sowohl zuverlässig als auch skalierbar sind. Während die Konfiguration Disziplin und ein solides Verständnis der Netzwerkgrundlagen erfordert, ist die Auszahlung eine flexible Infrastruktur, die hochkanalige, latenzarme Audio in praktisch jeder modernen Ethernet-Umgebung unterstützt. Da sich die Industrie weiterhin auf All-IP-Workflows zubewegt, wird die Beherrschung von AES67 QoS eine wichtige Fähigkeit für Audioprofis und Netzwerkingenieure bleiben. Regelmäßige Validierung, gründliche Dokumentation und Einhaltung der Standards wird sicherstellen, dass selbst die anspruchsvollsten Live- oder Broadcast-Produktionen einwandfrei laufen.