Audio Video Bridging

Background

Audio and video (AV) equipment connections historically were analog one-way, single-purpose and point-to-point. Even digital AV standards often were point-to-point and one-way such as S/PDIF for audio and the serial digital interface (SDI) for video. This connection model resulted in large confusing masses of cables, especially in professional and high-end consumer applications.

Attempts to get around these problems included new technologies such as IEEE 1394 (known as FireWire), and adaptations of standard computer network technologies such as Audio over Ethernet or Audio over IP. Specialized professional, home, and automotive protocols did not interoperate. Adapting standard networks could use commodity technology, but tight quality of service control was difficult.

Benefits

Some benefits of AVB systems are:

Requirements

Requirements included synchronizing multiple streams to ensure they can be rendered correctly in time; a simple example of this is lip synch. For more stringent applications, such as keeping multiple digital speakers properly in phase within a professional environment, synchronization within 1μs is needed. Worst case delay, including source and destination buffering, must be low and deterministic. For example, consumer user-interface responses of about 50ms, or about 2ms for live performances. Applications must be able to reserve network resources, sometimes called admission control. AVB is also considered for industrial control applications.

IEEE standardization

In July 2004, the IEEE 802.3 started a residential Ethernet study group for A/V streaming. In November 2005, work moved to the IEEE 802.1 working group, responsible for cross-network bridging standards. In particular, the group wanted the technology to be scalable from inexpensive consumer applications to professional standards.

Summary of Audio Video Bridging

An "Audio Video Bridging" (AVB) network implements a set of protocols being developed by the IEEE 802.1 Audio/Video Bridging Task Group. AVB works by reserving a fraction of the available Ethernet bandwidth for AVB traffic. There are four primary differences between the proposed architecture and existing 802 architectures:

These are implemented using relatively small extensions to standard layer-2 MACs and bridges. This "minimal change" philosophy allows non-AVB and AVB devices to communicate using standard 802 frames. However, as shown in Figure 2, only AVB devices are able to: a) reserve a portion of network resources through the use of admission control and traffic shaping and b) send and receive the new timing-based frames. AVB packets are sent regularly in the allocated slots. As the bandwidth is reserved, there will be no collisions.

IEEE 802.1AS - Precise synchronization

AVB devices periodically exchange timing information that allows both ends of the link to synchronize their time base reference clock very precisely. This precise synchronization has two purposes:

The protocol used for maintaining timing synchronization is specified in IEEE 802.1AS, which is a very tightly-constrained subset of another IEEE standard (IEEE 1588), with extensions to support IEEE 802.11 and also generic "coordinated shared networks" (CSNs – examples include some wireless, coaxial cable, and power line technologies). IEEE 1588 is used for industrial control and test and measurement applications.

An 802.1AS network timing domain is formed when all devices follow the requirements of the 802.1AS standard and communicate with each other using the IEEE 802.1AS protocol. Within the timing domain there is a single device called the grandmaster that provides a master timing signal. All other devices synchronize their clocks with the grandmaster as shown in Figure 3.

The device acting as grandmaster can either be auto selected or can be specifically assigned (e.g., if the network is used in a professional environment that needs "house clock" (audio), or "genlock" (video), or if the timing hierarchy needs to be specified for other reasons). AVB devices typically exchange capability information after physical link establishment. If peer devices on a link are network synchronization capable they will start to exchange clock synchronization frames. If not, then an AVB timing domain boundary is determined (as shown in Figure 2).

IEEE 802.1Qav - Traffic shaping for AV streams

In order to provide professional AV services, the AVB architecture implements traffic shaping using existing 802.1Q forwarding and priority mechanisms but also defines a particular relationship between priority tags and frame forwarding behaviour at endpoints and bridges. Traffic shaping is the process of smoothing out the traffic for a stream, distributing its packets evenly in time. If traffic shaping is not done at sources and bridges, then the packets tend to "bunch", i.e. agglomerate, into bursts of traffic that can overwhelm the buffers in subsequent bridges, switches and other infrastructure devices. "bunching" is described in greater detail in the following sections.

Tagging requirements at the stream source and the bridge

AVB streams consist of 802 frames with priority tagging and with normal restrictions on format and length. The default 802.1Q tagging for a particular market segment should be chosen to avoid potential conflict with existing uses of the 802.1Q priority tags within that market segment.

Traffic shaping at the stream source

Endpoint devices are required to transmit frames very evenly for a particular stream based on the AVB traffic class and on the specific quality of service (QoS) parameters that were used when the stream was OK’d by the network (see Admission controls below). The specific rules for traffic shaping are described in the IEEE 802.1Qav specification, and are a simple form of what is known as "leaky bucket" credit-based fair queuing where the bandwidth reserved for a stream controls the time between the packets that make up the stream.

Traffic shaping at an AVB bridge

The traffic shaping mechanism used by stream sources is also employed by AVB bridges. AVB frames are forwarded with precedence over Best Effort traffic (i.e., reserved AVB stream traffic traversing an AVB bridge has forwarding precedence over non-reserved traffic) and will be subjected to traffic shaping rules (they may need to wait for sufficient credits). Just like for stream sources, the traffic shaping rules for bridges require that frames be distributed very evenly in time, but only on an aggregate class basis rather than on a per-stream basis. This means that all the AVB traffic being transmitted out of a particular port is distributed evenly in time measured using the QoS parameters of that class; this is the sum of the bandwidths of all the reservations for a particular AVB class for the particular port, made by the admission control process described below. This is to achieve the effect of smoothing out the delivery times (preventing bunching of frames ) while a stream propagates through a network. The limited bunching provides the very useful benefit of placing a relatively small upper limit on the size of the AVB output buffers needed at all egress ports on a bridge, independent of the number of hops in the path. This bounded buffer size is a key attribute that enables bounded delay and eliminates network congestion for admitted AV streams in AVB networks even when non-admitted traffic does experience congestion.

IEEE 802.1Qat - Admission controls

Even though the preceding mechanism can reliably deliver data with a deterministic low latency and low jitter, it will only do so if the network resources (e.g., throughput on a port, buffer space in a bridge) are available along the entire path from the talker to the listener(s). In the AVB protocols, the term ‘talker’ denotes a stream source while ‘listener’ denotes a stream destination. In this architecture, it is both the talker’s and the listener's responsibility to guarantee the path is available and to reserve the resources. The process to do this is specified by the 802.1Qat "Stream Reservation Protocol" (SRP). This protocol registers a stream and reserves the resources required through the entire path taken by the stream: Talkers initiate by sending an SRP "talker advertise" message. This message includes a Stream ID composed of the MAC address of the stream source plus a talker-specific 16-bit unique ID and the MAC address of the stream destination. Additionally, the "talker advertise" message includes QoS requirements (e.g., AVB traffic class and data rate information), and accumulated worst case latency. Even though the address and QoS requirements are originated by the talker, the worst case latency is recalculated at every bridge allowing the listener to communicate this information to higher layers for media synchronization sake.

Figure 5 – Successful reservation (talker advertise) All AVB intermediate bridges receiving a "talker advertise" message check for bandwidth availability on their output ports. When the bridge has got sufficient resources available on that port, then the "talker advertise" is propagated to the next station. When those resources are not available, rather than propagating the advertise message, the bridge sends a "talker failed" message. Included in this message is a failure code and bridge identification allowing a higher-layer application to provide error checking or notification. An intermediate bridge receiving a "talker failed" should just pass on the message out towards the listener. When a listener receives a "talker advertise" message, it should know whether the resources are available, and if so, the latency for the path. It can then respond with a "listener ready" message that is forwarded back towards the talker. Intermediate bridges use the "ready" message to lock down the resources needed by the stream and to make the appropriate entries in their forwarding database to allow the stream to be sent on the port that received the "ready" message. When the talker receives a "ready" message, it can start transmitting the stream.

The talker can explicitly tear down a stream by de-registering the "talker advertise", and a listener can disconnect by de-registering the "listener ready". A de-registration message propagates through the network in the same manner as the original registration. There are also implicit methods used for tearing down a connection and for releasing the allocated resources. For example, the listener must periodically resend registrations and "ready" messages, and talkers must periodically resend "advertise" messages. That way any receiving device (including intermediate bridges) could automatically release assigned resources and notify higher layers if the appropriate registrations and reservations were not received due to a system halt, for example, suddenly lost power.

LAN-specific considerations

Although the intent of the AVB Task Group is to provide a LAN-technology-independent method for requesting and providing streaming services, the characteristics and architectures of different LAN technologies require specific ways of implementing those services as outlined in the next few sections.

IEEE 802.3 / Ethernet Links

Today's Ethernet devices predominantly support full-duplex operation at 100 Mbit/s or greater. Thus, since the total available bandwidth available over such an Ethernet link is both known and constant, an AVB reservation over those Ethernet links combined with the appropriate traffic shaping assures both throughput and delivery latency parameters are met for packets of reserved streams. Since the bandwidth and delivery timing cannot be assured between two devices in an older shared CSMA/CD Ethernet using hubs, these older technologies are not supported by AVB. AVB’s Ethernet time synchronization standard, 802.1AS, leverages and simplifies deployed IEEE 1588-2008.

IEEE 802.11 / Wireless LAN

To date, the AVB support planned for 802.11 is limited to time synchronization. 802.1AS provides for accurate time synchronization over 802.11 links, in part by invoking MAC-specific timestamp-reporting primitives defined in IEEE Std 802.11v-2011. The time synchronization protocol defined by 802.1AS has been designed to be resilient to the transmission characteristics that are possible on wireless medium.

Coordinated Shared Network Links

Several MAC/PHY specifications and standards are currently deployed or being developed which operate over existing wires within the home (e.g. AC power lines, coax cabling,). These wires are electrically "Shared" between multiple devices (not point-to-point like Ethernet), so to provide predictable performance, transmission of information onto the wire is "Coordinated" to avoid collisions by one of the devices on the network. Such networking technologies are typically called Coordinated Shared Networks (CSN). If the CSN provides an access method with bounded latency (as most do), and if accurate link-specific time stamping or clock distribution is available for the CSN, then extensions can be defined to take advantage of them.

IEEE 802.1BA - Identification of participating devices

Since the whole AVB scheme depends on the participation of all devices between the talker and listener, any network element that does not support AVB (including so-called "unmanaged bridges") must be identified and flagged. The process to do this is described in the developing IEEE 802.1BA "Audio Video Bridging Systems" standard, which specifies the default configuration for AVB devices in a network. For Ethernet, the method specified by 802.1BA to determine if its peer is AVB capable is a combination of 802.3 link capabilities (determined during Ethernet link establishment) and the link delay measurements done by IEEE 802.1AS. An AVB capable Ethernet port uses AVB if:

1. the link is full duplex 100 Mbit/s or greater
2. the 802.1AS protocol discovers exactly one peer
3. the round-trip delay to the responding AVB device is no more than a worst case wire delay (computed from the IEEE 802.1AS "PDelay" exchange) Note: the worst case wire delay is less than that of a non AVB switch
4. an SRP reservation request or acknowledge is received on the port

Other layer 2 connections will have their own specific methods to identify cooperating peers. Even though a port may be enabled for AVB operation, there is a possibility that a complete end-to-end AVB connection cannot be made to another endpoint device that is AVB enabled. For example, in Figure 2 above, devices in AVB domain 1 cannot establish an AVB connection to devices in AVB domain 2. An AVB connection can only be assured if a successful reservation is made using SRP and SRP "talker advertise" messages will not be propagated by a non-AVB bridge.

Higher layer protocols

For applications to take advantages of the features of AVB, there needs to be some coordination with portions of the higher layer communication protocols in between. In addition, some transport protocols have been adapted to provide information for applications to use AVB. An application can implement synchronized distributed rendering using 802.1AS and higher layers. Specific audio samples and/or video frames carried by higher-layer protocols are given an associated presentation time (in terms of the shared 802.1AS clock) by the media source that is also an AVB talker. Each media renderer, that is also an AVB listener, renders the referenced audio sample or video frame at the 802.1AS presentation time.

IEEE 1722 and IEEE 1722.1

Applications using IEC 61883 and other formats can use procedures defined in IEEE Std 1722-2011 to sample the 802.1AS clock relevant for an A/V data block and then add the worst case transport delay to the sample time to get a presentation time which is inserted into the 1722 packet.

IEEE Std 1722.1-2013 is a standard which allows AVB Discovery, Enumeration, Connection management and Control (AVDECC) of devices using IEEE Std 1722-2011.

IEEE 1733

If an application uses the IETF Real-time Transport Protocol (RTP), it can use a new RTCP payload format defined in IEEE 1733 that correlates the RTP timestamp with the 802.1AS presentation time. The applications at the renderer(s) then use that correlation to translate the RTP timestamp to the presentation time stamp allowing the renderer(s) to start playing at the same time and keep playing at the same rate.

HTTP

Applications using HTTP can also take advantage of AVB’s time synchronization by carrying a presentation time. For example, MPEG2 transport streams that require clock synchronization between the server and client can include transport time stamps (TTS) as defined by ARIB TTS (ARIB STD-B24) which are derived from the 802.1AS clock. Similarly, an application could utilize clock synchronization through methods described in ISO 13818-1 Annex J which includes a discussion of various clock recovery schemes proposed for MPEG2 Transport Streams over jitter inducing networks, and figure J.2 illustrates a simple way to use the 802.1AS clock for this purpose.

If the media source is not a real-time source (e.g. a media file on a mass storage device), the presentation times can be generated based on the nominal media rate. If the media source is a real-time source (e.g. a microphone), the presentation time can be constructed by the talker based on its observation of the 802.1AS time in relation to the microphone’s sample clock. Other higher layer services can use AVB in a similar way. Existing connection management schemes, for example, can use the AVB SRP reservation services by mapping their internal stream identifiers with the SRP stream ID. Once a connection is established, streaming can start. E.g., applications using RTP transmit RTCP packets defined by IEEE 1733 that correlate the SSRC to the SRP stream ID. Furthermore, listener applications using 1722 use the SRP stream ID to discriminate between different streams.

Standardization

Standardization efforts are ongoing in IEEE 802.1. The following AVB improvement projects are proposed or in progress.