Q-SYS Networking and Topologies (Part 1)

When we speak of Q-SYS, networking is easy to say but not always as straightforward to grasp.

Q-SYS supports a number of different services and protocols,

so understanding each one and the best practices for implementation can be complex.

In this course we’ll examine the details and work on strategies to make Q-SYS networks work.

To begin our journey, let’s first look at the connectivity available from the perspective of hardware.

All Q-SYS Cores and most peripherals have:

LAN A, which is the primary Q-SYS connection,

supporting all control functionality and it creates the primary Q-LAN network

and LAN B, which is the secondary Q-SYS connection when redundant Q-LAN networking is used.

It also supports all control-related features.

Integrated and Enterprise Cores such as the 510i and Core 5200 have an AUX A connection

that supports control functionality and some audio protocols.

The current Core 5200 and legacy enterprise Cores have one more, an AUX B connection that is like AUX A.

There are also Q-SYS plugin cards that can facilitate other functionality.

They provide dedicated Network interfaces for Dante, Cobranet and AVB.

If you consider a configurable product like the 510i, it’s easy to see why we need a course like this.

Depending on the needs for a project, there could be more than 5 network interfaces on a single unit!

And don’t forget that the connections on the NV32-H and the Q-SYS cameras also support Q-LAN video protocols.

This chart lists a number of the service types supported by Q-SYS

and exactly which of the network connections support them.

The simplest way to understand the limitations is this:

LAN A is ALWAYS the primary Q-SYS network connection.

It supports ALL services required except for the secondary audio network.

ONLY LAN A and LAN B support real-time media streams

that require the precision time protocol and the PTP protocols themselves.

These protocols include Q-LAN, Dante and AES67.

All control-related protocols are supported by every network port.

They can be enabled and disabled for security purposes, but they are available.

Let’s look at these services another way.

As we discussed in the previous networking topic,

certain types of services have different networking requirements.

Multicast services require IGMP snooping and filtering in significant bandwidth.

Time-sensitive services require packet prioritization through QoS.

Q-SYS discovery and the precision time protocols are multicast in nature,

but they don’t consume much bandwidth.

IGMP snooping and filtering becomes necessary when real-time protocols like AES67

and multicast video are flowing on the network.

Virtually all audio and video streaming protocols are time-sensitive in some way

and so they need to be prioritized using Quality of Service.

It’s also important to prioritize the precision time protocols (PTPv1/v2),

as they’re responsible for clocking many of the audio protocols.

The Q-SYS Dante card, or CDN64, supports some multicast and time-sensitive elements.

Note that while Dante audio streams are unicast by default, they can be configured as multicast.

Audinate does suggest the use of QoS to prioritize the audio traffic on the network.

The CAN32, which is the Q-SYS AVB card also supports multicast and time-sensitive elements,

but remember AVB requires special switch features that allow stream reservations

and bandwidth allocations to happen automatically.

These networks do not require IGMP snooping & filtering or manual QoS.

The CCN32, or Q-SYS Cobranet card, is obsolete.

If you have one of these in a legacy system, remember that all Cobranet devices are 100Mbps devices.

This means they saturate much earlier than the 1Gbps devices due to broadcast and multicast traffic.

The makers of Cobranet also recommend that Class of Service (CoS) be used for packet prioritization rather then QoS.

Now that we’ve seen which protocols are supported where

and discussed some concerns about the configuration of the network switches,

let’s look at how these devices get physically plugged into the network to make the magic happen.

Here we see the basic network topology for a Q-SYS system.

We have a Q-SYS Core and a Q-SYS peripheral connected to a network switch.

Note that LAN A must be used in this case as the primary Q-LAN network.

In this case the configuration computer, the one running Q-SYS Designer software,

is connected to the LAN A network.

Here it can discover and configure both the Core and the peripheral.

The computer could be connected directly to another connection on the Core,

but it would not then be able to discover and configure the peripheral.

This is the best practice topology for that reason.

What about the need for IGMP and QoS in this case?

The Q-LAN streams on this network are unicast, so we wouldn’t need IGMP.

While QoS might not be absolutely necessary for a small standalone system like this, we’d would still recommend it.

This helps manage the risk of what happens when someone accidentally plugs an unknown device into the network.

We see some instances in the field where this topology is used to avoid the need for a network switch.

Note this is NOT a valid way to connect a Core to two peripheral devices.

LAN A is the primary Q-SYS network, so all peripherals should be connected to it.

LAN B is only used if redundant Q-LAN networks are used in the system.

Consider the above diagram where a TSC-7t control panel is used for user control of a Q-SYS system.

Keep in mind that the TSC-7t in the diagram is a Q-SYS peripheral.

It should placed on the primary Q-SYS network as would any other Q-SYS device.

In the below diagram, an external controller is used to control the system.

It would make use of the Q-SYS external control protocol, which is hosted on any Core NIC.

The controller in the diagram would be connected to any available connection.

Keep in mind that control of a Q-SYS system is NOT a time-sensitive service.

QoS is not a requirement for a control-only network.

IGMP snooping and filtering would not be needed either,

as Q-SYS discovery is the only multicast service on the network in these cases.

Let’s look at external control of Q-SYS from another perspective.

Many integrators struggle with the idea of ‘should I or shouldn’t I’ with placing the external controller

on the same network as the Q-SYS peripherals and Q-LAN audio traffic.

Should external control be separated onto a separate network?

The answer is ‘whatever you’re comfortable with’.

It’s completely acceptable to join the control and Q-LAN audio networks as seen in the diagram on the left,

provided QoS is configured to prioritize the time-sensitive services.

It’s also ok to separate the control network from the Q-LAN network as seen on the right.

It requires management of more networks and more network equipment, however,

and it won’t work better as a result.

It does provide some isolation of functionality, so there’s no harm if you like it that way.

Alright, let's take a quick break right there and we'll come back and talk about another scenario.