Takte, Timing, Ethernet

Ethernet als dominanter lokaler Netzwerkstandard ist schnell aber nicht deterministisch, kann also nicht die Zustellung von Daten innerhalb definierter Zeiten garantieren. Die 802.1-Erweiterung „Audio Video Bridging (AVB)" behebt diese Problematik und ergänzt damit ausge­rüstete Segmente um synchrone Paketzustellung, ohne dabei aber den konventio­nellen Datenverkehr zu beeinträchtigen. Inzwischen gibt es vor allem aus dem Bereich des professionellen Audio-Equipments zahlreiche AVB-Imple­men­tierungen und viele davon setzen auf die Echtzeit-Controller samt zuge­höriger Software der britischen Firma XMOS.

Mit AVB zum synchronen Ethernet

Der IEEE-Standard 802.1BA[1] oder Audio-Video Bridging (AVB) besteht im Wesent­lichen aus 3 Erweiterungen, die Ethernet rückwärtskompatibel zur Echtzeitfähigkeit verhel­fen:

802.1AS liefert die not­wendigen präzisen Zeitin­formationen und sorgt für die Synchronizität der AVB-Teilnehmer.

802.1Qav beschreibt die Sicher­stellung von QoS über Queuing- und For­warding-Regeln und 802.1Qat definiert die Reservierung und Allo­kation von Übertragungs­res­sourcen.

Auf der Teil­nehmerebene wie „Talker" und „Listener" wird zudem IEEE1722[2] zum Ver­packen der Me­dien­ströme ein­ge­setzt. REF003

All diese Proto­kolle stellen Er­weite­rungen des Media-Access-Ver­fahrens auf Ebene 2 des OSI Schichten­mo­dells dar und folglich führen sie in der prak­tischen Um­set­zung zu Ände­rungen des Me­dia-Access-Con­trollers (MAC) eines NICs[3] oder Switches. Dabei können die um AVB-Features er­weiterten Netzteilnehmer mit klas­sischen Kompo­nenten koexistieren und den üb­lichen asynchronen Datenverkehr abwickeln. Synchrones Ethernet ist aber ausschließlich in den AVB-Clustern möglich und jede non-AVB-Kom­po­nente trennt den Cluster in 2 „asyn­chrone" Be­reiche.

AVB ist im Übrigen kooperativ gegen­über anderen Ether­net A/V-Protokollen, kann also im gleichen Netz mit CobraNet, EtherSound, Audinate Dante, AES50 und Q-LAN genutzt werden.

AVB-Endpoints sind zunächst einmal „Talker", „Listener" oder eine Kom­bination aus beiden, wo­bei das im August 2013 verabschiedete Steue­rungs­protokoll AVDECC[4] noch die beiden Rollen „Controller" und „Respon­der" hinzugefügt hat.

Ein einschlägig ausge­rüsteter CD-Player kann bei­spielsweise ein Tal­ker sein, während Laut­sprecher die Rolle des Listeners über­nehmen und Misch­pulte etwa bei­de Funktionen ver­körpen.

Innerhalb des End­points ist es i.d.R. ein dedi­zierter AVB-Con­troller, der für die Umsetzung der Medienstöme in AVB-Pakete sorgt. Im Falle des Talkers über­nimmt er  Audio­daten über eine genormte Schnittstelle wie I²S und wandelt diese, versehen mit Zeit­informationen und Zieladressen in einen Strom von AVB-Paketen um, die schließlich über einen PHY[5]  in das Ethernet-LAN eingespeist werden.

Auf Seite des Listeners ist dieser Prozess genau entgegengesetzt – die Signale vom Netzwerk ge­langen an den AVB-Controller, der sie „auspackt" und dosiert nach den enthaltenen Timing-Infor­matio­nen über einen angeschlossenen Codec zu Audio­daten zurück wan­delt.

AVB fügt dem 1980 von 3Com einge­führten Ether­net 3 grundlegend neue Eigenschaften zu :

• Ein Zeit­konzept.
• Reser­vierung von Übertra­gungs­ressourcen
• Regeln zum Einreihen in Warteschlangen und Weiterleiten von Daten

AVB gibt dem lokalen Netzwerk eine Zeitrefe­renz (aka „Master Clock"), auf die sich alle AVB-Teil­nehmer syn­chron­sieren. Die End­points können daher Operationen simul­tan ausführen, wie etwa Laut­sprecher, die Audio­inhalte phasengleich oder lippen­synchron zu Video­inhalten ab­geben.

Während der Datentransport bei Ethernet über Pakete als kleinste Einheit organisiert wird, ver­langen A/V-Daten eine an Streams orientierte Organisation. Daher bietet AVB ein Reservierungs-Protokoll, mit dem sich aus Paketen Streams definieren lassen. Dabei reserviert ein Talker  Ressourcen im Netz­werk, indem er über ein „Advertise" signali­siert, dass er einen Datenstrom an einen oder mehrere Listener senden möchte und dafür einen Pfad durch das Netzwerk für eine bestimmte Zeitspan­ne benötigt.

Um sicherzustellen, dass die Stream-Übertragung auch wirklich funktio­niert, gibt es für alle Netz­teilnehmer Regeln zum Einreihen und Weiter­leiten von Daten, die eine Priorisierung der Streams gegenüber dem übrigen Daten­ver­kehr erlau­ben.

Mit diesen Techniken lässt sich auch die Laufzeit durch das Netzwerk, die Latenz also, recht genau be­stimmen. Sie liegt bei maximal 2 ms für Fast Ethernet (100 MBit/s) mit 7 Hops (Switches) zwischen Talker und Listener und ist noch kleiner bei Gigabit Ethernet. Die Synchronizi­tät der AVB-Teilnehmer erreicht dabei etwa 1 µs. REF001

AVB Standardisierungsorganisationen

Im wesentlichen sind es 2 relevante Organisa­tionen, die Audio Video Bridging (AVB) entwickeln. Die technischen Grundlagen definiert die IEEE[6] mit ihrer 802.1 Audio/Video Bridging Task Group[7]. Aus diesem Standard kommerzielle Produkte zu schaffen ist hingegen das vorrangige Ziel der AVnu Alliance[8].

Mitglieder der IEEE-Arbeitsgruppe stammen aus unter­schiedlichen, meist privaten Organisationen, gelten aber als objektiv, will sagen ausschließlich ihrer jeweiligen technischen Ziel­setzung ver­pflichtet.

Während die Task-Group an der Entwicklung des AV-Bridging-Standards als technologisch unab­hängig vom zugrunde liegenden Netzwerk arbeitet, liegt der Fokus doch eindeutig auf Ethernet, wie in den 802.3-Dokumenten definiert. Daneben gibt es aber auch Initiativen zu Portierung von AVB auf drahtlose 802.11-Netze (WLAN bzw. WiFi).

Die Avnu-Alliance auf der kommerziellen Seite wird getragen von einer Gruppe führender Unter­nehmen aus dem Bereich Halbleiter sowie des  professionellen Audio­equipments.

Derzeit konzentriert sich die Allianz auf den Markt des Profi-Audios wie etwa Konferenzsysteme oder Beschallungsanlagen aber auch auf den Bereich der Automobilelektronik, da zu erwarten ist, dass mit zunehmender Verbreitung von Ethernet im Auto (z.B. über BroadR-Reach[9]) AVB als Standard zur Übertragung von multimedialen Inhalten ver­wendet wird.

Die Mitglieder der Allianz entwickeln Testproze­duren und organisieren sog. „Plug-Fests", um vor allem die Interoperabilität ver­schiedener AVB-Komponenten untereinander sicherzustellen.

Erkennen & Steuern – das AVDECC-Protokoll

Nun ist AVB als Layer-2 Protokoll zwar elegant und flink, führt aber auf Be­dienerebene zur Proble­matik einer gewissen Intrans­parenz. Einfach ausge­drückt lassen sich Layer-2-Geräte nicht von einem PC aus steuern und nur sehr mit­telbar an­sprechen, da sie über MAC-Adressen identi­fiziert werden, nicht über IP-Adressen. Ebenso kön­nen ihre jeweiligen Eigen­schaften und Dienste nicht abgefragt werden.

Ursprünglich vorgesehen für die Steuerung von AVB-Teilnehmern war Zeroconf[10] („Bonjour" oder „Ren­devouz" in der Apple-Diktion), ein IETF-Stan­dard zur auto­matischen Vergabe von IP-Adressen und Aus­tausch von Device-Eigenschaften in kleinen Netzwerken. Genutzt wurde es im wesentlichen zur Einbindung von Druckern, Scannern und ähnlichen Netzwerkgeräten.

Zeroconf ist inzwischen weiterentwickelt zu 2 sich ergänzenden Protokollen, nämlich Multicast DNS (mDNS) sowie mDNS-SD[11], das Service-Disco­very Protokoll von mDNS.

Multicast DNS läuft über das User Datagram Protokoll von TCP, festge­legt wurde dabei Port-Nummer 5353 für mDNS und Port 17221[12] für AVDECC.

Die Steuerung von AVB-Komponenten stützt sich daher auf diese beiden Protokolle und wurde unter dem Namen AVDECC bzw. IEEE1722.1 beschrieben und im August 2013 ratifiziert.

AVDECC steht für Au­dio/Video Discovery, Enu­meration, Connection management und Control und definiert eine ein­heitliche Prozedur zur Erkennung und Steue­rung von AVB-Kompo­nenten in einem Netzwerk. Dabei betrachtet AVDECC jedes Netzwerk-Gerät (End-Station) in einer von 3 Rollen bzw. einer Kombination daraus:

• Der AVDEC-Controller sendet Inquiry- oder Control-Nachichten zu AVDECC-Talkern und -Listenern.
• Der AVDECC-Talker ist Quelle eines oder mehrerer Audio-Streams.
• AVDECC-Listenerist Empfänger eines oder mehreren Audio-Streams aus dem Netz.

AVDECC wird noch immer weiter entwickelt und besteht derzeit aus folgenden Protokollen:

• AVDECC Discovery Protocol (ADP)
• definiert einen Erkennungsmechanismus für vernetzte AVDECC End-Stations.
• AVDECC Enumeration and Control Protocol (AECP)
• definiert, wie Eigenschaften und Funktionen innerhalb einer End-Station erkannt und genutzt werden können.
• AVDECC Connection Management Protocol (ACMP) definiert Verfahren und Kommandos zum Einrichten und Auflösen von Stream-Verbin­dungen.

AVDECC End-Stations werden durch ihre GUID[13] identifiziert, ein 64-Bit Feld, das ein individuelles Unikat für jede End-Station ist.

Mit dem 1722.1 Protokoll ist es nun möglich, AVB Geräte im Netz sehr komfortabel über TCP/IP zu steuern und graphische Bedienoberflächen wie etwa Mischpulte zu schaffen. Ein Beispiel dafür bietet die Firma UNOS mit dem frei erhältlichen AVB-Browser UNOS-Vision.REF002

XMOS Implementierung - das AVB-Endpoint Referenzdesign

AVB mit seinen Substandards verlangt spezifische Erweiterungen der Media-Access-Controller, dazu die Unterstützung digitaler Medienaufzeichnung- und Wiedergabe. Zur Imple­mentierung eignen sich ganz generell Prozessoren aus dem Embedded-Bereich, doch müssen sie in hohem Maße deter­ministisch, also echtzeit­fähig sein, um den Anfor­derungen des synchronen Ethernets gerecht zu werden.

Architekturen auf Basis von State-Machines in Gestalt von FPGAs und CPLDs etwa erfüllen diese Forderung natürlich in idealer Weise, sind aber recht sperrig in der Formulierung der be­nötigten Funktions­blöcke als HDL-Code.

Optimal ist daher ein hoch deterministischer Pro­zes­sor mit der Möglichkeit zur Programmierung in gewohnter Hochsprache, wie er von der Firma XMOS[14] mit der sog. XCore-Achitektur ange­boten wird.

Entwickler von AVB-kon­formen Produkten möchten weitestgehend von der Implementierung des AVB-Protokolls entlastet wer­den, um sich auf ihre  Zielsetzung konzentrieren zu können. Sie benöti­gen daher einen kosten­günstigen Controller und die notwendigen Sub­routinen zu Unterstützung des des AVB-Standards.

Um diesen Bedarf zu decken, hat XMOS ge­mein­sam mit dem Design-Haus Atterotech bereits vor einigen Jahren ein AVB-Referenzsystem geschaf­fen, das auch konti­nuierlich gepflegt wird, um Änderungen des AVB-Standards zu reflektieren.

Das Referenzdesign nutzt den kostengünstigen XS1-L16 Controller als Basis einer AVB Audio-Endpoint-Implemen­tier­ung, die so­wohl als Talker als auch Listener genutzt werden kann und bis zu 8 Duplex-Kanäle Audio über­trägt. Es integriert die gesamte Breite der AVB-Protokolle sowie zahl­reiche analoge und digitale I/Os.

Damit brauchen sich Entwickler nicht mit der Verbindungsebene he­rum­schlagen und dank der Echtzeitfähigkeit der XMOS-­Controller auch keine Bedenken haben, dass ihre Anwendungs­software das Timing des AVB-Unterbaus beein­trächtigt.

Zudem können sie Ver­besserungen oder Anpas­sungen an geänderte Protokolle recht einfach über Updates ihrer Firm­ware anbieten.

Inzwischen hat XMOS AVB auch auf sein neues mo­dulares Entwicklungs­board „sliceKIT"[15] portiert und zwar in Form eine „High Channel Talker/­Listeners" als auch als „Daisy-Chain Talker/­Listener", letzteres im Hinblick vor auf Automo­tive-Anwendungen mit der Möglichkeit, TP-Ethernet durch BroadR-Reach zu ersetzen.

st