Three Tips for Setting Up and Managing a Standard and AES67 Network
Contribution – Infrastructure – Studio
A lthough large radio stations and groups typically have the resources to develop dedicated networks for AES67 (IP audio) and for corporate traffic, small and mid-sized stations often need to pursue a less-expensive approach. Here we provide three recommendations that help smaller radio broadcasters ensure the peaceful coexistence of AES67 audio-over-IP (AoIP) traffic and standard network traffic on a single network.
Seamless Handling of AoIP and Standard Traffic on One Network
The AES67 standard makes AoIP protocols such as Dante, Livewire and Ravenna interoperable, in turn simplifying connectivity and reducing hardware and overall clutter. To identify the requirements of handling and optimizing AoIP traffic and standard traffic — web, video transfers, and corporate data — on one network, we examined the interoperability of AES67-compatible products from four different manufacturers and then created three recommendations for small and mid-sized radio broadcasters in setting up and managing AES67 (IP audio) on an existing network.
In short, we recommend the use of Internet Group Management Protocol (IGMP) snooping protocol to distribute predictable bandwidth on a high number of streams; installation of PTP (Precision Time Protocol)-enabled switches; and activation of quality of service (QoS) mechanisms to limit disruption and avoid audio glitches.
Making It Happen: Three Keys to AES67/AoIP on a Standard Network
Recommendation 1: Enable IGMP
First step: Activate the IGMP. By realizing select communications, IGMP enables the management of subscriptions to the multicast addresses. It manages the distribution of network and audio packets, in turn preventing saturation of bandwidth and reducing clutter on the network.
Recommendation 2: Consider PTP
The switch used to support this single-network model can be PTP-enabled or not. If it is, it facilitates better synchronization of the network and is less sensitive to the disruptive effects that can be generated by the corporate network. Although a PTP-enabled switch is more expensive than the alternative, its benefits often are worth the extra cost. When the switch is not PTP-enabled, synchronization or jitter problems may occur during heavy use of the network. (One way to avoid this issue is to configure the QoS present on the switches.) Without PTP support, clock jitter on AES67 traffic becomes quite high above 100 audio channels.
Recommendation 3: Configure Packet Priority via QoS
QoS is used to manage the priority of packets over the network, and it improves the network capabilities of a switch that does not contain PTP. The AES67 standard imposes rules on manufacturers regarding QoS eligibility. It integrates the management of the priorities of the IP packets and to which class of service they are associated. The equipment and the network must follow the AES67 recommendations to ensure a uniform understanding of priorities.
Optimizing the Single-Network Model
Enabling the IGMP is the most important step radio broadcasters can take to avoid saturation of the audio network, regardless of whether or not they are using a PTP-enabled switch. That said, the bottom line is that the combination of PTP and Qos makes it possible to increase the quality and quantity of available audio streams. Through our tests, we determined that the combination of a non-PTP-enabled switch with QoS enabled made it possible to exchange 120 full-duplex channels on the network without loss of packets and without any latency problems.
Conclusion: Creating an AES67 Network is an Option for All
Network audio competence is increasingly essential for radio broadcasters, but today’s AES67-compatible IP-based products for AoIP — and a few helpful tips for implementation — can go a long way in enabling small and mid-sized operations to take advantage of IP audio and its many benefits.
Setting Up and making an AES67 network coexist with standard network traffic
Download the eBrief introduced by Digigram during the 140 th AES convention in May 2016.