Ethernet is emerging as the network of choice for infotainment and advanced driver assistance systems that include cameras, telematics, rear-seat entertainment systems and mobile phones. A typical system is shown in fig 1. But standard Ethernet protocols can’t assure timely and continuous audio/video (A/V) content delivery for bandwidth intensive and latency sensitive applications without buffering, jitter, lags or other performance hits.
Audio-Video Bridging (AVB) over Ethernet is a collection of extensions to the IEEE802.1 specifications that enables local Ethernet networks to stream time synchronised, loss sensitive A/V data. Within an Ethernet network, the AVB extensions help differentiate AVB traffic from the non-AVB traffic that can also flow through the network. This is done using an industry standard approach that allows for plug and play communication between systems from multiple vendors.
The extensions that define the AVB standard achieve this by:
* reserving bandwidth for AVB data transfers to avoid packet loss due to network congestion from ‘talker’ to ‘listener(s)’
* establishing queuing and forwarding rules for AVB packets that keep packets from bunching and guarantee delivery of packets with a bounded latency from talker to listener(s) via intermediate switches, if needed
* synchronising time to a global clock so the time bases of all network nodes are aligned precisely to a common network master clock, and
* creating time aware packets which include a ‘presentation time’ that specifies when A/V data inside a packet has to be played.
Designers of automotive A/V systems need to understand the AVB extensions and requirements and how their chosen microcontroller will support that functionality.
AVB: a basket of standards
AVB requires that three extensions be met in order to comply with IEEE802.1:
* IEEE802.1AS – timing and synchronisation for time-sensitive applications (gPTP)
* IEEE802.1Qat – stream reservation protocol (SRP)
* IEEE802.1Qav – forwarding and queuing for time-sensitive streams (FQTSS).
In order to play music or video from one source – such as a car’s head unit – to multiple destinations, such as backseat monitors, amplifiers and speakers, the system needs a common understanding of time in order to avoid lags or mismatch in sound or video. IEEE802.1AS-2011 specifies how to establish and maintain a single time reference – a synchronised ‘wall clock’ – for all nodes in a local network. The generalised precision time protocol (gPTP), based on IEEE1588, is used to synchronise and syntonise all network nodes to sub-microsecond accuracy. Nodes are synchronised if their clocks show the same time and are syntonised if their clocks increase at the same rate.
Fig 2: New MCUs, such as Atmel's SAMV7x, are designed for Ethernet AVB applications |
This protocol selects a Grand Master Clock from which the current time is propagated to all network end-stations. The protocol also specifies how to correct for clock offset and clock drifts by measuring path delays and frequency offsets. New MCUs, such as the Atmel SAMV7x (see fig 2), detect and capture time stamps automatically when gPTP event messages cross MII layers. They can also transport gPTP messages over raw Ethernet, IPv4 or IPv6. This hardware recognition feature helps to calculate clock offset and link delay with greater accuracy and minimal software load.
SRP, meanwhile, guarantees end to end bandwidth reservation for all streams to ensure packets aren’t delayed or dropped at any switch due to network congestion, which can occur with standard Ethernet. For the in-vehicle environment, SRP is typically configured in advance by the car maker, who defines data streams and bandwidth allocations.
Talkers (the source of A/V data) ‘advertise’ data streams and their characteristics. Switches process these announcements from talker and listeners to:
* register and prune streams’ path through the network
* reserve bandwidth and prevent over subscription of available bandwidth
* establish forwarding rules for incoming packets
* establish the SRP domain, and
* merge multiple listener declarations for the same stream
The standard stipulates that AVB data can reserve only 75% of total available bandwidth, so for a 100Mbit/s link, the maximum AVB data is 75Mbit/s. The remaining bandwidth can be used for all other Ethernet protocols.
In automotive systems, the streams may be preconfigured and bandwidth can be reserved statically at system startup to reduce the time needed to bring the network into a fully operational state. This supports safety functions, such as driver alerts and the reversing camera, that must be displayed within seconds.
SRP uses other signalling protocols, such as Multiple MAC Registration Protocol, Multiple VLAN Registration Protocol and Multiple Stream Registration Protocol to establish bandwidth reservations for A/V streams dynamically.
The third extension is FQTSS, which guarantees that time sensitive A/V streams arrive at their listeners within a bounded latency. It also defines procedures for priority regenerations and credit based traffic shaper algorithms to meet stream reservations for all available devices.
The AVB standard can support up to eight traffic classes, which are used to determine quality of service. Typically, nodes support at least two traffic classes – Class A, the highest priority, and Class B. Microcontroller features help manage receive and transmit data with multiple priority queues to support AVB and ‘best effort class’ non AVB data.
Automotive tailored requirements
Automotive use cases typically fix many parameters at the system definition phase, which means that AVB implementation can be optimised and simplified to some extent.
* Best Master Clock algorithm (BMCA): the best clock master is fixed at the network definition phase so dynamic selection using BCMA isn’t needed.
* SRP: all streams, their contents and their characteristics are known at system definition and no new streams are dynamically created or destroyed; the proper reservation of data is known at the system definition phase; switches, talkers and listeners can have their configurations loaded at system startup from pre-configured tables, rather than from dynamic negotiations
* Latency; while this is not critical, delivery is. Automotive networks are very small with only a few nodes between a talker and listener. It is more important not to drop packets due to congestion.
Conclusion
The requirement to transfer high volumes of time sensitive audio and video content inside vehicles requires developers to understand and apply the Ethernet AVB extensions. AVB standardisation results in interoperable end-devices from multiple vendors that can deliver audio and video streams to distributed devices on the network with micro-second accuracy or better. While the standard brings complexities, new MCUs are designed with advanced features to simplify automotive A/V design.
Author profile:
Tim Grai is Atmel’s director of automotive MCU application engineering.
Transport of A/V data over an Ethernet AVB network Transport Protocol – a high level encapsulation that defines how A/V data are encapsulated into Ethernet frames for transportation across the network – is critical for interoperability. Typically, the carmaker will define the transport protocols, but system vendors need to ask which protocol is being used to transport data if it hasn’t been communicated. |
