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 ausgerüstete Segmente um synchrone Paketzustellung, ohne dabei aber den konventionellen Datenverkehr zu beeinträchtigen. Inzwischen gibt es vor allem aus dem Bereich des professionellen Audio-Equipments zahlreiche AVB-Implementierungen und viele davon setzen auf die Echtzeit-Controller samt zugehöriger Software der britischen Firma XMOS.
Mit AVB zum synchronen Ethernet
Der IEEE-Standard 802.1BA[1] oder Audio-Video Bridging (AVB) besteht im Wesentlichen aus 3 Erweiterungen, die Ethernet rückwärtskompatibel zur Echtzeitfähigkeit verhelfen:
802.1AS liefert die notwendigen präzisen Zeitinformationen und sorgt für die Synchronizität der AVB-Teilnehmer.
802.1Qav beschreibt die Sicherstellung von QoS über Queuing- und Forwarding-Regeln und 802.1Qat definiert die Reservierung und Allokation von Übertragungsressourcen.
Auf der Teilnehmerebene wie „Talker" und „Listener" wird zudem IEEE1722[2] zum Verpacken der Medienströme eingesetzt. REF003
All diese Protokolle stellen Erweiterungen des Media-Access-Verfahrens auf Ebene 2 des OSI Schichtenmodells dar und folglich führen sie in der praktischen Umsetzung zu Änderungen des Media-Access-Controllers (MAC) eines NICs[3] oder Switches. Dabei können die um AVB-Features erweiterten Netzteilnehmer mit klassischen Komponenten koexistieren und den üblichen asynchronen Datenverkehr abwickeln. Synchrones Ethernet ist aber ausschließlich in den AVB-Clustern möglich und jede non-AVB-Komponente trennt den Cluster in 2 „asynchrone" Bereiche.
AVB ist im Übrigen kooperativ gegenüber anderen Ethernet 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 Kombination aus beiden, wobei das im August 2013 verabschiedete Steuerungsprotokoll AVDECC[4] noch die beiden Rollen „Controller" und „Responder" hinzugefügt hat.
Ein einschlägig ausgerüsteter CD-Player kann beispielsweise ein Talker sein, während Lautsprecher die Rolle des Listeners übernehmen und Mischpulte etwa beide Funktionen verkörpen.
Innerhalb des Endpoints ist es i.d.R. ein dedizierter AVB-Controller, der für die Umsetzung der Medienstöme in AVB-Pakete sorgt. Im Falle des Talkers übernimmt er Audiodaten über eine genormte Schnittstelle wie I2S und wandelt diese, versehen mit Zeitinformationen 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 gelangen an den AVB-Controller, der sie „auspackt" und dosiert nach den enthaltenen Timing-Informationen über einen angeschlossenen Codec zu Audiodaten zurück wandelt.
AVB fügt dem 1980 von 3Com eingeführten Ethernet 3 grundlegend neue Eigenschaften zu :
- Ein Zeitkonzept.
- Reservierung von Übertragungsressourcen
- Regeln zum Einreihen in Warteschlangen und Weiterleiten von Daten
AVB gibt dem lokalen Netzwerk eine Zeitreferenz (aka „Master Clock"), auf die sich alle AVB-Teilnehmer synchronsieren. Die Endpoints können daher Operationen simultan ausführen, wie etwa Lautsprecher, die Audioinhalte phasengleich oder lippensynchron zu Videoinhalten abgeben.
Während der Datentransport bei Ethernet über Pakete als kleinste Einheit organisiert wird, verlangen 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 Netzwerk, indem er über ein „Advertise" signalisiert, dass er einen Datenstrom an einen oder mehrere Listener senden möchte und dafür einen Pfad durch das Netzwerk für eine bestimmte Zeitspanne benötigt.
Um sicherzustellen, dass die Stream-Übertragung auch wirklich funktioniert, gibt es für alle Netzteilnehmer Regeln zum Einreihen und Weiterleiten von Daten, die eine Priorisierung der Streams gegenüber dem übrigen Datenverkehr erlauben.
Mit diesen Techniken lässt sich auch die Laufzeit durch das Netzwerk, die Latenz also, recht genau bestimmen. 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 Synchronizität der AVB-Teilnehmer erreicht dabei etwa 1 µs. REF001
AVB Standardisierungsorganisationen
Im wesentlichen sind es 2 relevante Organisationen, 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 unterschiedlichen, meist privaten Organisationen, gelten aber als objektiv, will sagen ausschließlich ihrer jeweiligen technischen Zielsetzung verpflichtet.
Während die Task-Group an der Entwicklung des AV-Bridging-Standards als technologisch unabhä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 Unternehmen aus dem Bereich Halbleiter sowie des professionellen Audioequipments.
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 verwendet wird.
Die Mitglieder der Allianz entwickeln Testprozeduren und organisieren sog. „Plug-Fests", um vor allem die Interoperabilität verschiedener AVB-Komponenten untereinander sicherzustellen.
Erkennen & Steuern – das AVDECC-Protokoll
Nun ist AVB als Layer-2 Protokoll zwar elegant und flink, führt aber auf Bedienerebene zur Problematik einer gewissen Intransparenz. Einfach ausgedrückt lassen sich Layer-2-Geräte nicht von einem PC aus steuern und nur sehr mittelbar ansprechen, da sie über MAC-Adressen identifiziert werden, nicht über IP-Adressen. Ebenso können ihre jeweiligen Eigenschaften und Dienste nicht abgefragt werden.
Ursprünglich vorgesehen für die Steuerung von AVB-Teilnehmern war Zeroconf[10] („Bonjour" oder „Rendevouz" in der Apple-Diktion), ein IETF-Standard zur automatischen Vergabe von IP-Adressen und Austausch 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-Discovery Protokoll von mDNS.
Multicast DNS läuft über das User Datagram Protokoll von TCP, festgelegt 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 Audio/Video Discovery, Enumeration, Connection management und Control und definiert eine einheitliche Prozedur zur Erkennung und Steuerung von AVB-Komponenten 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-Verbindungen.
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 Implementierung eignen sich ganz generell Prozessoren aus dem Embedded-Bereich, doch müssen sie in hohem Maße deterministisch, also echtzeitfähig sein, um den Anforderungen 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 benötigten Funktionsblöcke als HDL-Code.
Optimal ist daher ein hoch deterministischer Prozessor mit der Möglichkeit zur Programmierung in gewohnter Hochsprache, wie er von der Firma XMOS[14] mit der sog. XCore-Achitektur angeboten wird.
Entwickler von AVB-konformen Produkten möchten weitestgehend von der Implementierung des AVB-Protokolls entlastet werden, um sich auf ihre Zielsetzung konzentrieren zu können. Sie benötigen daher einen kostengünstigen Controller und die notwendigen Subroutinen zu Unterstützung des des AVB-Standards.
Um diesen Bedarf zu decken, hat XMOS gemeinsam mit dem Design-Haus Atterotech bereits vor einigen Jahren ein AVB-Referenzsystem geschaffen, das auch kontinuierlich gepflegt wird, um Änderungen des AVB-Standards zu reflektieren.
Das Referenzdesign nutzt den kostengünstigen XS1-L16 Controller als Basis einer AVB Audio-Endpoint-Implementierung, die sowohl als Talker als auch Listener genutzt werden kann und bis zu 8 Duplex-Kanäle Audio überträgt. Es integriert die gesamte Breite der AVB-Protokolle sowie zahlreiche analoge und digitale I/Os.
Damit brauchen sich Entwickler nicht mit der Verbindungsebene herumschlagen und dank der Echtzeitfähigkeit der XMOS-Controller auch keine Bedenken haben, dass ihre Anwendungssoftware das Timing des AVB-Unterbaus beeinträchtigt.
Zudem können sie Verbesserungen oder Anpassungen an geänderte Protokolle recht einfach über Updates ihrer Firmware anbieten.
Inzwischen hat XMOS AVB auch auf sein neues modulares Entwicklungsboard „sliceKIT"[15] portiert und zwar in Form eine „High Channel Talker/Listeners" als auch als „Daisy-Chain Talker/Listener", letzteres im Hinblick vor auf Automotive-Anwendungen mit der Möglichkeit, TP-Ethernet durch BroadR-Reach zu ersetzen.
st
- Webseite der IEEE Audio Video Bridging Task Group unter http://www.ieee802.org/1/pages/avbridges.html
- Webseite der IEEE 1722 Working Group: http://grouper.ieee.org/groups/1722/
- NIC = Network Interface Adapter
- AVDECC = IEEE Std 1722.1-2013
- Physical Layer Interface
- IEEE = Institute of Electrical and Electronics Engineers
- Webseite der IEEE AVB Task Group: http://www.ieee802.org/1/pages/avbridges.html
- Webseite der AVNu Alliance: http://www.avnu.org/
- Wikipedia über BroadR-Reach: http://de.wikipedia.org/wiki/BroadR-Reach
- Siehe auch: http://www.zeroconf.org/
- Weitere Infomationen zu mDNS-SD unter http://www.dns-sd.org/
- Verzeichnis der TCP-Portnummern, hier AVDECC
- GUID – Globally Unique Identifyer
- Siehe http://www.xmos.com/products/why
- Siehe https://www.xmos.com/products/xkits/slicekit