Takte, Timing, Ethernet

We're sorry we don't have an English version of this article

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