Startseite > Automotive > Schnelle Datenübertragung

Ethernet Audio Video Bridging für Streaming-Anwendungen

Schnelle Datenübertragung

6. Juli 2015, 11:39 Uhr | Von Tim Grai

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

AVB Traffic Classes

Das Priority-Code-Point-Feld (PCP) des Virtual Local Area Network Tag (VLAN) innerhalb eines Ethernet-Pakets wird mit dem Prioritätswert des Frame kodiert. Jeder Frame wird anhand dieser Priorität und einem „Traffic Class Table“ des Ports einer Traffic Class zugeordnet. Die Frames sind auf eine oder mehrere Warteschlangen aufgeteilt; jede entspricht einer anderen Class.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Sobald der Traffic in eine SRP-Domäne eintritt, ordnet der Switch an der Domänengrenze diesem eine niedrigere Priorität zu. Es gibt keine Möglichkeit, diese Prioritätswerte zurück auf den ursprünglichen Wert zu setzen, wenn der Frame die SRP-Domäne verlässt. Der AVB-Standard kann bis zu acht Traffic Classes unterstützen. Sie werden alphabetisch, mit dem Buchstaben „A“ beginnend, bezeichnet. Die SR-Class A hat die höchste Priorität im Netzwerk. Normalerweise unterstützen die Knoten mindestens zwei Traffic Classes – Class A und Class B. AVB nutzt Traffic Classes, um die Quality of Service (QoS) eines Stream ([2], Bild 4) zu bestimmen.

QoS in Class A bedeutet:

Class Measurement Interval 125 µs
Der obere Latenz-Grenzwert für 7 Hops entspricht 2 ms.
Die erforderliche Pufferzeit für Daten der Class A beträgt 2 ms.

QoS in Class B bedeutet:

Class Measurement Interval 250 µs.
Der obere Latenz-Grenzwert für 7 Hops entspricht 50 ms.
Die erforderliche Pufferzeit für Daten der Class B beträt 50 ms.

Das Traffic Shaping von Frames in Warteschlangen der „Per Traffic“-Klasse erfolgt mit dem CBS Former. Der SAMV7x unterstützt das Management des Empfangs und des Sendens von Daten. In Senderichtung unterstützt SAMV7x bis zu drei Prioritätswarteschlangen. Folglich sind mindestens zwei SR-Klassen auf den zwei Prioritätswarteschlangen möglich, während die Standard-Warteschlange genutzt werden kann, um Best-Effort-Class-, Nicht-AVB-Daten zu senden. SAMV7x unterstützt bis zu drei Warteschlangen, um erhaltene Daten weiterleiten. Die MCU lässt sich so konfigurieren, dass alle Frames außer VLAN-markierte Frames zurückgewiesen werden. Sie verfügt hierzu über Screener-Register, die als Filter arbeiten und die Daten auf spezielle Warteschlangen leiten. Die Screener nutzen dazu eine Kombination aus allen oder eines aus den folgenden Feldern:

VLAN-Priorität
Ethernet-Typ
drei 16-bit-Vergleichsfelder: Hier werden Offset, Maske und Wert angegeben. Ein 16-bit-Wort aus Offset vom Frame-Start wird maskiert und mit dem Wert verglichen. Somit verfügen die Screeners eine Filtermöglichkeit auf der Basis von bis zu drei 16-bit-Feldern.

Ein Frame, der die Filter passiert, wird in eine bestimmte Warteschlange geleitet. So lassen sich AVB-Daten in verschiedene Warteschlangen leiten, während Nicht-AVB-Daten in einer anderen Warteschlange abgearbeitet werden.

Credit-based Shaper

Bei allen Sender-Endstationen müssen ausgehende Frames einen Shaper durchlaufen, um Bursting und Bunching zu reduzieren. AVB (Bild 5) verfügt dafür über einen Credit-based Traffic Shaper (CBS). Die folgenden Parameter werden jeder Warteschlange zugeordnet, die den CBS-Algorithmus unterstützt.

portTransmitRate: Die Übertragungsgeschwindigkeit in bit/s. Das entspricht der Link-Bandbreite.
idleSlope: Die wirkliche Bandbreite in bit/s, die aktuell für diese Warteschlange reserviert ist. Das entspricht auch der Credit-Änderungsrate in bit/s, wenn der Credit-Wert zunimmt. Dieser Wert kann den Wert der portTransmitRate nie überschreiten. sendSlope: Die Credit-Änderungsquote in bit/s, wenn der Credit-Wert abnimmt.
sendSlope = portTransmitRate – idleSlope
hiCredit: Maximaler Credit-Wert, der durch die Warteschlange erhöht wird.
loCredit: Minimaler Credit-Wert einer Warteschlange.

Credit-Based-Traffic-Shaper- Algorithmus

Frames in der Warteschlange werden nur übertragen, wenn diese einen nicht negativen Credit haben.
Der Credit-Wert einer Warteschlange wird anfangs auf null gesetzt.
Der Credit-Wert wird um den sendSlope-Wert verringert, wenn ein Frame aus der Warteschlange übertragen wird.
Der Credit-Wert wird um den idleSlope-Wert erhöht, wenn eine Übertragung abgeschlossen ist.
Der Credit-Wert wird erneut um den idleSlope-Wert erhöht, wenn ein in der Warteschlange wartender Frame auf einen freien Port wartet.
Wenn der Frame nicht groß genug ist, um alle verfügbaren Credits zu verbrauchen, und es keine weiteren Frames in der Warteschlange gibt, wird der Credit-Wert nach der Übertragung auf null reduziert.
Frames werden ohne Rücksicht auf den Credit-Wert vollständig übertragen, nachdem eine Übertragung gestartet wurde.

Die SR-Klasse bestimmt die Priorität der Streams. CBS stellt sicher, dass die Bandbreiten-Garantien in jeder Verkehrsklasse beachtet, aber bei jeder einzelnen Netzwerkverbindung nicht überschritten werden. SAMV7x unterstützt das Traffic Shaping in der Hardware, was die Software-Last reduziert. Ein Traffic Shaping ist nur bei den beiden höchsten Prioritätswarteschlangen möglich. Somit wird ein Traffic Shaping lediglich für bis zu zwei Verkehrsklassen unterstützt.

Transport von A/V-Daten über AVB-Ethernet-Netzwerk

Das Transportprotokoll ist eine High-Level-Kapselung, die definiert, wie die A/V-Daten innerhalb eines Frame formatiert werden ([3], Bild 6). AVB Transport Protocol (AVBTP) Frames, die A/V-Daten enthalten, werden für den Transport über das Netzwerk in Ethernet Frames eingebettet. Ethernet Frames, in denen das Feld EtherType auf 0x88B5 gesetzt ist, sind AVBTP Ethernet Frames.

IEEE 1722.1-2013 ist ein Standard, der AVB-Erkennung, Aufzählung, Verbindungsmanagement und eine Steuerung (AVDECC) von Geräten auf der Basis von IEEE 1722-2011 erlaubt. AVBTP ist für seine Datennutzlast transparent, weil es einen eigenen Header definiert. Einige wichtige Felder des AVBTP-Headers sind:

Subtyp: Dieses Feld spezifiziert das Streaming-Protokoll. – Dieser Wert kann von 0x00 bis 0x7F reichen. – 0x00 – IEC 61883 / IIDC-Streaming-Protokoll. Dieses lässt sich dazu nutzen, diverse Mediaformate einschließlich roher und komprimierter Audio-/Videoformate zu übertragen. Zu den auf IEC 61883 basierenden Formaten gehören SD DVCR (IEC 61883-2), MPEG2-TS-komprimiertes Video (IEC 61883-4), unkomprimiertes Audio (IEC 61883-6), Satelliten-TV-MPEG (IEC 61883-7). – 0x7F – proprietär/experimentell. Das kann zur Übertragung beliebiger Digitaldaten genutzt werden. S
tream_id: Eine 64-bit-Stream-ID wird genutzt, um verschiedene Streams über alle Knoten eindeutig zu identifizieren. Diese 64 bit bestehen aus – einer 48-bit-MAC-Adresse, die vom Talker abgeleitet wurde. – einem unsignierten ganzzahligen 16-bit-Wert, Unique ID, um mehrere Streams von einem Talker zu unterscheiden.
Presentation_time: 802.1AS-Zeitpunkt, wann die Daten abgespielt werden müssen. Der Talker misst den für einen A/V-Datenblock relevanten 802.1AS-Takt und fügt dann die Worst-Case-Transportverzögerung zur Sample-Zeit hinzu, um eine Präsentationszeit zu erhalten, die in das 1722-Paket eingefügt wird.

Diese Präsentationszeit ist immer die Präsentationszeit des ersten Sample im Paket. Nachfolgende Samples werden mit der Media-Taktfrequenz abgespielt. Diese lässt sich einsetzen, um Medien bei mehreren Listeners mit variablen Latenzen/Pfadverzögerungen synchron wiederzugeben, beispielsweise Front- und Heck-Lautsprecher in einem Auto für die Audio-Wiedergabe. Damit lassen sich auch variable Verzögerungen zwischen mehreren Streams synchronisieren, z.B. Audio Stream und Video Stream beim Abspielen eines Films.

Ein Talker tastet analoge Medien mit einer standardisierten Frequenz ab (Media Clock) und produziert somit unbearbeitete digitale Samples. Eine Anwendung packt diese Samples dann in einen AVBTP Frame. Die Anzahl der Samples in einem AVBTP hängt von der Media Clock ab (Bild 7).