Die Implementierung von AES67-Standards in einem großen Funknetz kann die Interoperabilität von Audiosystemen erheblich verbessern und den Betrieb rationalisieren. In dieser Fallstudie wird untersucht, wie ein nationales Funknetz AES67 erfolgreich einsetzte, um seine Rundfunkinfrastruktur zu verbessern und messbare Verbesserungen bei Synchronisation, Zuverlässigkeit und Kosteneffizienz zu erzielen. Der folgende Bericht beschreibt die Herausforderungen, den Entscheidungsprozess, die schrittweise Umsetzung und die erreichten transformativen Ergebnisse.

Hintergrund des Funknetzes

Das nationale Radionetz betreibt über 40 regionale Stationen, die über ein vielfältiges geografisches Gebiet verteilt sind und täglich Millionen von Zuhörern bedienen. Vor dem AES67-Projekt verwendete jede Station einen Patchwork aus alten Audioprotokollen - einige proprietäre, einige ältere offene Standards wie MADI und AES3 -, was zu erheblichen Interoperabilitätsproblemen führte. Die Audiosynchronisation über Stationen hinweg während Live-Simulcasts war ein anhaltendes Problem mit Verzögerungen von 5 bis 20 Millisekunden. Die gemeinsame Nutzung von Inhalten erforderte manuelle Konvertierungen und Remote-Produktions-Setups erforderte oft teure dedizierte Leitungen und benutzerdefinierte Brückenhardware. Das Engineering-Team verbrachte durchschnittlich 15 Stunden pro Woche mit der Fehlersuche bei Audio-Routing-Missanpassungen und Synchronisierungsfehlern und entwässerte Ressourcen, die für die Content-Innovation hätten verwendet werden können.

Das Engineering-Team des Netzwerks unter der Leitung des Director of Technology erkannte, dass die bestehende Infrastruktur nicht skalierbar war. Budgetbeschränkungen beschränkten die Möglichkeit, alle Geräte auf einmal zu ersetzen, und die Vielfalt der Anbieter (einschließlich Mischpulten von Calrec, Lawo und Yamaha sowie Codecs von Tieline und Comrex) machten die Protokollvereinheitlichung unerlässlich. Nach einem sechsmonatigen Bewertungszeitraum stellte sich AES67 als klare Wahl gegenüber proprietären AoIP-Lösungen wie Dante oder Ravenna heraus, da sie einen offenen Standardcharakter hatten und herstellerübergreifende Kompatibilität garantierten. Das Team zog auch SMPTE ST 2110-30 in Betracht, das AES67 einbettet, aber entschied, dass beginnend mit reinen AES67 die breiteste Geräteunterstützung und einen reibungsloseren Übergangsweg für ihre bestehende Infrastruktur ermöglichen würde.

Warum AES67 gewählt wurde

Das technische Team entschied sich für AES67, weil es sich als offener, profilbasierter Standard für Audio-over-IP-Interoperabilität etabliert hat, der von der Audio Engineering Society formal definiert wurde. Im Gegensatz zu proprietären Systemen, die Unternehmen in Ökosysteme von einzelnen Anbietern einbinden, stellt AES67 sicher, dass Geräte verschiedener Hersteller Audioströme mit vorhersehbarer Latenz und Qualität entdecken, synchronisieren und austauschen können.

  • Interoperabilität mit mehreren Anbietern AES67 wird von fast allen großen Rundfunkausrüstungsherstellern unterstützt, einschließlich Calrec, Lawo, Yamaha, Digigram und Axia. Dies ermöglichte es dem Netzwerk, bestehende Konsolen und Codecs zu behalten und gleichzeitig AES67-Fähigkeiten über Schnittstellenkarten oder Firmware-Updates hinzuzufügen.
  • Keine Lizenzgebühren Der Standard ist frei umsetzbar und vermeidet wiederkehrende Kosten im Zusammenhang mit proprietären Lösungen. Dies war für eine öffentlich-rechtliche Rundfunkanstalt mit strengen Kostenkontrollmandaten von entscheidender Bedeutung.
  • IEEE 1588 Precision Time Protocol (PTP) Integration, die eine Sub-Millisekunden-Synchronisation über geografisch verteilte Standorte ermöglicht. Die bestehende Timing-Infrastruktur des Netzwerks aus GPS und NTP war nicht genau genug für die anspruchsvolle Phasenausrichtung, die bei Live-Simulcasts erforderlich ist.
  • Flexible Abtastraten und Bittiefen - Die Unterstützung für 24-Bit, 48 kHz und bis zu 96 kHz gewährleistet eine zukunftssichere Verwendung von hochauflösendem Audio. Das Netzwerk wählte 48 kHz/24-Bit als Basis, um die Konsistenz mit den Legacy-Archivformaten zu gewährleisten.

Das Netz bewertete auch SMPTE ST 2110-30 (das AES67 einbettet), stellte jedoch fest, dass reines AES67 die breiteste Geräteunterstützung für ihre bestehende Infrastruktur bietet. Ravenna, obwohl eng miteinander verbunden, hatte zu diesem Zeitpunkt weniger unterstützte Codecs vor Ort. Der offene Charakter des Standards bedeutete, dass das Netz wettbewerbsfähige Preise von mehreren Anbietern aushandeln konnte, anstatt an die Roadmap eines einzelnen Anbieters gebunden zu sein. Ein Pilottest an der Flaggschiffstation zeigte, dass AES67-Streams mit bestehendem IP-Verkehr in einem segmentierten Netzwerk koexistieren konnten, mit einer gemessenen Latenzzeit von weniger als 1 Millisekunde Ende-zu-Ende.

Umsetzungsprozess

Der Rollout wurde in vier Phasen über 18 Monate geplant, um die Unterbrechung der täglichen Sendungen zu minimieren und gleichzeitig internes Fachwissen aufzubauen. Das Projektteam bestand aus fünf leitenden Ingenieuren, zwei IT-Spezialisten und einem Projektmanager, der dem CTO untersteht. Externe Berater einer AES67-Integrationsfirma leisteten Peer-Review und Unterstützung bei der Inbetriebnahme. Ein Lenkungsausschuss aus Stationsmanagern und dem Leiter der Programmierung stellte sicher, dass die operativen Anforderungen immer bei technischen Entscheidungen berücksichtigt wurden.

Phase 1: Netzwerkbereitschaft und Ausrüstungsaudit

Jede Station wurde einer gründlichen Prüfung der vorhandenen Netzwerkinfrastruktur unterzogen: Switch-Modelle, Verkabelung (Cat6a Minimum erforderlich), Power-over-Ethernet-Verfügbarkeit und Bandbreitenauslastung. Das Kernnetzwerk wurde aktualisiert, um IGMP-Snooping für Multicast-Verkehr zu unterstützen, und ein dediziertes VLAN für Audio wurde konfiguriert, um AES67-Streams vom Daten- und Kontrollverkehr zu isolieren. PTP-Großmeisteruhren wurden am Hauptknotenpunkt und zwei regionalen Verteilungszentren installiert, wobei das Standardprofil verwendet wurde, das in AES67-2018 Das Team führte auch eine detaillierte Bandbreitenanalyse durch: Jeder AES67-Stream mit 48 kHz/24-Bit verbraucht etwa 4,6 Mbit/s Multicast-Verkehr. Bei bis zu 64 gleichzeitigen Streams an größeren Stationen benötigte der Netzwerkkern mindestens 300 Mbit/s reservierte Kapazität, die nach einem Upgrade auf 10 GbE-Backbone-Verbindungen leicht aufgenommen werden konnte.

Phase 2: Geräteintegration und Kompatibilitätsprüfung

Die schrittweise Integration begann an der größten Station, wo die Hauptkonsole von Calrec Artemis mit einer Ravenna/AES67-Schnittstellenkarte aktualisiert wurde. Gleichzeitig wurden Tieline Bridge-IT-Codecs konfiguriert, um AES67-Streams auszugeben und die alten G.722- und APT-X-Verbindungen zu ersetzen. Das Team entwickelte eine Kompatibilitätsmatrix, die die AES67-Fähigkeiten jedes Geräts dokumentiert – unterstützte Sampleraten, PTP-Domänenkonfiguration und RTP-Nutzlasttypen. Einige ältere Codecs erforderten Firmware-Updates, um die AES67-Modi freizulegen. In wenigen seltenen Fällen musste der Anbieter einen bestimmten Patch veröffentlichen.

Während dieser Phase verwendete das Team Neutrik opticalCON Glasfaserläufe für Fernverbindungen zwischen Studios und Sendern, die keine Verschlechterung der PTP-Genauigkeit über Entfernungen von mehr als 100 Metern gewährleisten. Im Ingenieurlabor wurde ein temporärer Prüfstand eingerichtet, um jede Kombination von Sender und Empfänger zu validieren, bevor ein Gerät in Produktion genommen wurde.

Phase 3: Personalschulung und Betriebsspielbücher

Die Schulung wurde in zwei Ebenen durchgeführt. Das Engineering-Team nahm an einem zweitägigen Intensivworkshop teil, der AES67-Transport, PTP-Timing und Fehlersuche mit Wireshark- und AES67-spezifischen Analysatoren abdeckte. Bediener und Produktionsmitarbeiter erhielten halbtägige Sitzungen, die sich auf tägliche Workflows konzentrierten: wie Audiostreams mit den neuen AoIP-Steuerschnittstellen weitergeleitet werden können, wie Synchronisationsfehler erkannt werden und wie Probleme mit dem Engineering eskaliert werden können. Für jede Station wurde ein Playbook erstellt, das IP-Adressen, Stream-IDs und Multicast-Gruppenzuweisungen dokumentiert. Das Playbook beinhaltete auch schrittweise Wiederherstellungsverfahren für gängige Fehlermodi wie PTP-Taktdrift oder Multicast-Gruppen-Timeout.

Zusätzlich wurde eine mobile App entwickelt, die es den Bedienern ermöglichte, die Streamzuweisung schnell nach jedem Remote-Feed oder Studio zu suchen, wodurch Verwirrung bei schnelllebigen Live-Events reduziert wurde.

Phase 4: Vollständiges Rollout und kontinuierliche Verbesserung

Da die Flaggschiffstation drei Monate lang stabil betrieben wurde, wurde der Rollout auf alle 40 Stationen mit einer Rate von zwei pro Monat erweitert. Jede Station wurde während eines geplanten Wartungsfensters (typischerweise 0200–0600 Ortszeit) auf AES67 umgestellt. Nach dem Umschalten überwachte das Engineering-Team die Audio-Synchronisation und Latenz mit einem proprietären Messinstrument basierend auf ITU-T J.209 Empfehlungen. Jede Station, die Jitter über 50 Mikrosekunden zeigte, wurde auf PTP Border Clock Konnektivität überprüft. Am Ende des Rollouts arbeiteten alle Stationen auf AES67 mit einer gemessenen End-to-End Latenz von 0,9 ms (±0,2 ms). Ein kontinuierlicher Verbesserungsprozess wurde etabliert: monatliche Überprüfungen von Synchronisationsprotokollen und Netzwerkverkehrsmustern mit vierteljährlichen Firmware-Updates für PTP-fähige Switches.

Ergebnisse und Auswirkungen

Sechs Monate nach Fertigstellung dokumentierte das Netzwerk die folgenden quantitativen und qualitativen Gewinne:

  • Audio-Synchronisationsfehler um 95% reduziert — Die Simulcast-Verzögerungen sanken von durchschnittlich 12 ms auf unter 1 ms, was eine nahtlose regionale Programmierung ohne hörbare Artefakte ermöglichte. Dies war besonders wichtig für die Live-Nachrichtenberichterstattung, bei der mehrere Korrespondenten von verschiedenen Standorten aus beitrugen.
  • Interoperabilität um 100% verbessert Jedes Gerät jedes Anbieters kommuniziert jetzt ohne proprietäre Gateways, vereinfacht Upgrades und ermöglicht die Beschaffung von Mix-and-Match. Das Netzwerk sparte jährlich geschätzte 200.000 US-Dollar bei der Überbrückung von Hardware- und Protokollkonvertierungslizenzen.
  • Remote-Produktions-Setups von 45 Minuten auf 8 Minuten gekürzt – Der Anschluss eines externen Broadcast-Trucks beinhaltet nun einfach die Zuweisung eines AES67-Streams an die richtige Multicast-Gruppe, im Gegensatz zur Konfiguration mehrerer Hardware-Bridges.
  • Investitionen in Audio-Routing-Hardware um 30% reduziert Das Netzwerk ersetzte teure proprietäre Matrix-Switches durch standardgesteuerte Switches und nutzte softwarebasiertes Routing über AES67. Die Einsparungen wurden auf die Modernisierung von Studio-Akustik- und Überwachungsystemen umgeleitet.
  • Betriebszuverlässigkeit erhöht - Die PTP-basierte Synchronisation eliminierte die manuelle Kalibrierung, die unter dem vorherigen System erforderlich war, und reduzierte On-Air-Audio-Drift-Vorfälle um 80%. Die mittlere Zeit zwischen Fehlern des Netzwerks (MTBF) für das Audio-Routing verbesserte sich von 90 Tagen auf über 400 Tage.

Das Netzwerk berichtete auch von erheblichen Verbesserungen bei der Produktivität der Mitarbeiter. Die Betreiber mussten nicht mehr getrennte Kenntnisse über mehrere Audioprotokolle aufbewahren; ein einziges Playbook und eine einzige Steuerungsschnittstelle deckten alle Stationen ab. Das IT-Team stellte fest, dass die Netzwerküberwachung für Audiostreams einfacher wurde: Sie konnten vertraute SNMP-Falle verwenden, um Multicast-Streamverluste oder PTP-Uhrprobleme zu erkennen, anstatt sich auf herstellerspezifische Diagnosen zu verlassen. Darüber hinaus ermöglichte die Möglichkeit, Audiostreams schnell neu zuzuordnen, dem Netzwerk, innerhalb von Wochen statt Monaten einen neuen regionalen digitalen Funkdienst zu starten, indem es vorhandene IP-Infrastruktur wiederverwendete.

Lessons Learned

Die Implementierung ergab mehrere wichtige Erkenntnisse für zukünftige AES67-Anwender. Erstens kann die Bedeutung der PTP-Profilkonsistenz nicht überbewertet werden. Das Team versuchte zunächst, das Standard-IEEE 1588-Profil zu verwenden, stellte jedoch fest, dass bestimmte Geräte das AES67-spezifische Profil korrekt verhandeln mussten. Nachdem sie das AES67-2018-Profil standardisiert hatten (das einen bestimmten Satz von PTP-Attributen vorschreibt), mussten alle Geräte richtig synchronisiert werden. Zweitens muss die Netzwerksegmentierung sorgfältig geplant werden: Während AES67-Datenverkehr von Natur aus Multicast ist, verursachte das Mischen mit Legacy-Control-Datenverkehr auf demselben VLAN gelegentlichen Paketverlust.

Das Team löste dies, indem es ein separates VLAN für Audio und die Implementierung von Traffic-Shaping für PTP-Nachrichten mit DiffServ DSCP 46 (Expedited Forwarding) einsetzte. Drittens erwies sich eine umfassende Dokumentation der Stream-Zuordnungen als entscheidend für die Fehlersuche, insbesondere während temporärer Aufstellungen für Sportereignisse oder aktuelle Nachrichten. Das Netzwerk entwickelte eine webbasierte Stream-Registrierung, die es

Künftige Expansionspläne

Aufbauend auf dem Erfolg von AES67 untersucht das Netzwerk nun die Einführung von SMPTE ST 2110-30 für Videobeiträge, die die gleiche Audioschicht wie AES67 teilen. Ein Test im Hauptproduktionszentrum zeigte, dass AES67-Audioströme nahtlos in ST 2110-30-Videoströme eingebettet werden können, was einen einheitlichen IP-Transport für beide Medientypen ermöglicht. Das Netzwerk evaluiert auch AES67-Redundanzfunktionen, wie z. B. Stream-Verschlüsselung mit AES67 Stream Encryption (ASE) und redundante Unicast-Streams, um die Anforderungen an Notübertragungen zu erfüllen. Langfristig erforscht das Engineering-Team die Integration von AES67 mit Cloud-basierten Produktions-Workflows, mit RAVENNA für Remote-Beiträge und AES67 für die Synchronisation zwischen Cloud- und lokalen Ressourcen. Ein Proof-of-Concept mit einem großen Cloud-Anbieter zeigte, dass mit einer geeigneten Netzwerkoptimierung AES67-Streams die Latenz von Sub-2ms über Entfernungen von bis zu 500 km aufrechterhalten können, was die Tür für eine zentrale Produktion für regionale Stationen öffnet.

Schlussfolgerung

Diese Fallstudie zeigt, dass die Einführung von AES67 zu erheblichen operativen Vorteilen für große Rundfunknetze führen kann. Durch die Einführung eines offenen Standards hat das nationale Radionetz nicht nur seine Interoperabilitäts- und Synchronisierungsherausforderungen gelöst, sondern auch erhebliche Kosteneinsparungen und operative Agilität erzielt. Der Erfolg dieses Projekts dient als Modell für andere Organisationen, die ihre Audioinfrastruktur modernisieren wollen, ohne in ein Ökosystem mit nur einem Anbieter eingebunden zu sein. Die wichtigsten Vorteile für jeden Rundfunkanbieter, der AES67 in Betracht zieht, sind: Investitionen in eine gründliche Bewertung der Netzwerkbereitschaft, Priorisierung der PTP-Uhrinfrastruktur, Dokumentation alles und Phase der Einführung sorgfältig, um die Zuverlässigkeit im Luftverkehr zu gewährleisten. Mit diesen Praktiken kann AES67 die Grundlage für ein skalierbares, zukunftssicheres Rundfunkaudionetzwerk sein.

Da sich die Branche in Richtung All-IP-Produktion bewegt, werden Standards wie AES67 und ST 2110 nur wichtiger werden. Organisationen, die ihre Einführung jetzt beginnen, werden gut positioniert sein, um die Vorteile der sich abzeichnenden Fähigkeiten in der Fernproduktion, Cloud-Integration und immersivem Audio zu nutzen.