In Part 1 we looked at the problem AVB/TSN was created to solve. In Part 2 we look at how AVB/TSN achieves this.

OSI Layers

Without going too far into a big subject, not all audio systems based on Cat5e/Cat6/Twisted Pair cabling work in the same way. Systems differ in their use of Ethernet and this can be understood in terms of the OSI 7 Layer model. Any networked system can use the entire protocol stack to communicate. Proprietary hardware might not use 'standard' protocols above layer-2, but would encode the audio data transfer using it's own upper layer protocol(s), whereas AoIP leverages the existing TCP/IP stack. This is all rather technical and beyond the scope of this article but the important thing to understand is that you can’t really directly compare systems which operate on different network layers. AVB/TSN operates on Layer 2. For an overview of which technologies operate on which network layer look at the primer I wrote last year on just this: Part 1 Part 2. You’ll see that in those articles I referred to "Cat5 audio" to acknowledge that layer 1 and 2 systems couldn’t accurately be described as Audio over IP because IP is Layer 3. Since then the industry seems to have settled on Audio over IP as a catch all term whether it is accurate or not.

Bandwidth Management

AVB/TSN doesn’t treat all data the same. Time critical data can use bandwidth which has been reserved for it. By default audio and video traffic can reserve up to 75% of the total bandwidth on a network. The other 25% is always available for general network traffic. This value can be customised but this system is in place to guarantee that normal network traffic can’t impede audio and video traffic and conversely that audio and video traffic doesn’t force all other traffic off the network (for example control data associated with the audio streams). To maintain the deterministic performance of the network the “Talkers” and “Listeners” need to request permission before putting a stream on the network. The bandwidth management process in AVB/TSN is automatic and only requires the attention of the user when the network’s capacity is exceeded at any point. If a stream is requested and allowing that stream would push any part of the network beyond the permitted limit then the request will be denied. This is a very different behaviour to standard Ethernet which is based on a best effort model which will allow extra traffic at the expense of predictable arrival time. Anyone who has ever seen a video stream interrupted as it buffers will know this behaviour. Latency for AV media streams is typically 2ms overall network delay though the figure can be lower. MOTU have got their overall network latency down to 0.625ms when using their hardware and being AVB/TSN this isn't a best case figure, it is guaranteed.

Traffic shaping

To maintain transit speeds across a network AVB doesn’t treat all data equally. Audio and video has the highest priority, other data is delayed. This is common to all Quality of Service (QoS) systems but maintaining quality of service isn’t just about passing traffic across the network as quickly as possible, large bursts of data are also disallowed. Traffic shaping is relatively easy to visualise as it is very similar to traffic on a road network. While it is possible to run a traffic network by putting policemen at each junction and leaving them to control traffic independently letting priority traffic (e.g. ambulances) through, this would constitute a “best effort” model and precise arrival time at the hospital would vary depending on how busy the roads were. Coning off a lane from the accident scene all the way to the hospital would give predictable results unaffected by other traffic. This is similar to how AVB/TSN works. Transit time across the network is guaranteed up to 7 hops - travelling through 6 switches. AVB/TSN networks self-manage bandwidth allocation requiring no input from the user.

More Than Just Audio

The clue is in the name but AVB/TSN supports video as well as audio streams. Because of the very different bandwidth requirements of production quality audio and video, audio is currently more achievable than video but AVB/TSN can support video streams, actually most of the AoIP technologies have support for video streams planned for future support but AVB/TSN supports video today.

In Part 3 we touch on some of the issues facing AVB/TSN and look at how these new standards which started in AV will have far greater use in wider industrial applications.