Video Transcript
Q-SYS Networking and Topologies (Part 1)
7m 48s
00:08
When we speak of Q-SYS, networking is easy to say but not always as straightforward to grasp.
00:14
Q-SYS supports a number of different services and protocols,
00:18
so understanding each one and the best practices for implementation can be complex.
00:23
In this course we’ll examine the details and work on strategies to make Q-SYS networks work.
00:29
To begin our journey, let’s first look at the connectivity available from the perspective of hardware.
00:35
All Q-SYS Cores and most peripherals have:
00:38
LAN A, which is the primary Q-SYS connection,
00:41
supporting all control functionality and it creates the primary Q-LAN network
00:46
and LAN B, which is the secondary Q-SYS connection when redundant Q-LAN networking is used.
00:52
It also supports all control-related features.
00:56
Integrated and Enterprise Cores such as the 510i and Core 5200 have an AUX A connection
01:03
that supports control functionality and some audio protocols.
01:07
The current Core 5200 and legacy enterprise Cores have one more, an AUX B connection that is like AUX A.
01:15
There are also Q-SYS plugin cards that can facilitate other functionality.
01:20
They provide dedicated Network interfaces for Dante, Cobranet and AVB.
01:25
If you consider a configurable product like the 510i, it’s easy to see why we need a course like this.
01:31
Depending on the needs for a project, there could be more than 5 network interfaces on a single unit!
01:37
And don’t forget that the connections on the NV32-H and the Q-SYS cameras also support Q-LAN video protocols.
01:44
This chart lists a number of the service types supported by Q-SYS
01:49
and exactly which of the network connections support them.
01:52
The simplest way to understand the limitations is this:
01:55
LAN A is ALWAYS the primary Q-SYS network connection.
01:59
It supports ALL services required except for the secondary audio network.
02:04
ONLY LAN A and LAN B support real-time media streams
02:09
that require the precision time protocol and the PTP protocols themselves.
02:13
These protocols include Q-LAN, Dante and AES67.
02:18
All control-related protocols are supported by every network port.
02:23
They can be enabled and disabled for security purposes, but they are available.
02:28
Let’s look at these services another way.
02:31
As we discussed in the previous networking topic,
02:33
certain types of services have different networking requirements.
02:37
Multicast services require IGMP snooping and filtering in significant bandwidth.
02:42
Time-sensitive services require packet prioritization through QoS.
02:47
Q-SYS discovery and the precision time protocols are multicast in nature,
02:51
but they don’t consume much bandwidth.
02:54
IGMP snooping and filtering becomes necessary when real-time protocols like AES67
02:59
and multicast video are flowing on the network.
03:03
Virtually all audio and video streaming protocols are time-sensitive in some way
03:08
and so they need to be prioritized using Quality of Service.
03:12
It’s also important to prioritize the precision time protocols (PTPv1/v2),
03:17
as they’re responsible for clocking many of the audio protocols.
03:21
The Q-SYS Dante card, or CDN64, supports some multicast and time-sensitive elements.
03:28
Note that while Dante audio streams are unicast by default, they can be configured as multicast.
03:35
Audinate does suggest the use of QoS to prioritize the audio traffic on the network.
03:41
The CAN32, which is the Q-SYS AVB card also supports multicast and time-sensitive elements,
03:48
but remember AVB requires special switch features that allow stream reservations
03:53
and bandwidth allocations to happen automatically.
03:56
These networks do not require IGMP snooping & filtering or manual QoS.
04:02
The CCN32, or Q-SYS Cobranet card, is obsolete.
04:07
If you have one of these in a legacy system, remember that all Cobranet devices are 100Mbps devices.
04:14
This means they saturate much earlier than the 1Gbps devices due to broadcast and multicast traffic.
04:21
The makers of Cobranet also recommend that Class of Service (CoS) be used for packet prioritization rather then QoS.
04:30
Now that we’ve seen which protocols are supported where
04:33
and discussed some concerns about the configuration of the network switches,
04:36
let’s look at how these devices get physically plugged into the network to make the magic happen.
04:42
Here we see the basic network topology for a Q-SYS system.
04:46
We have a Q-SYS Core and a Q-SYS peripheral connected to a network switch.
04:50
Note that LAN A must be used in this case as the primary Q-LAN network.
04:55
In this case the configuration computer, the one running Q-SYS Designer software,
05:00
is connected to the LAN A network.
05:03
Here it can discover and configure both the Core and the peripheral.
05:06
The computer could be connected directly to another connection on the Core,
05:11
but it would not then be able to discover and configure the peripheral.
05:15
This is the best practice topology for that reason.
05:18
What about the need for IGMP and QoS in this case?
05:22
The Q-LAN streams on this network are unicast, so we wouldn’t need IGMP.
05:27
While QoS might not be absolutely necessary for a small standalone system like this, we’d would still recommend it.
05:34
This helps manage the risk of what happens when someone accidentally plugs an unknown device into the network.
05:40
We see some instances in the field where this topology is used to avoid the need for a network switch.
05:47
Note this is NOT a valid way to connect a Core to two peripheral devices.
05:52
LAN A is the primary Q-SYS network, so all peripherals should be connected to it.
05:58
LAN B is only used if redundant Q-LAN networks are used in the system.
06:03
Consider the above diagram where a TSC-7t control panel is used for user control of a Q-SYS system.
06:10
Keep in mind that the TSC-7t in the diagram is a Q-SYS peripheral.
06:14
It should placed on the primary Q-SYS network as would any other Q-SYS device.
06:20
In the below diagram, an external controller is used to control the system.
06:24
It would make use of the Q-SYS external control protocol, which is hosted on any Core NIC.
06:30
The controller in the diagram would be connected to any available connection.
06:35
Keep in mind that control of a Q-SYS system is NOT a time-sensitive service.
06:40
QoS is not a requirement for a control-only network.
06:45
IGMP snooping and filtering would not be needed either,
06:48
as Q-SYS discovery is the only multicast service on the network in these cases.
06:54
Let’s look at external control of Q-SYS from another perspective.
06:57
Many integrators struggle with the idea of ‘should I or shouldn’t I’ with placing the external controller
07:03
on the same network as the Q-SYS peripherals and Q-LAN audio traffic.
07:07
Should external control be separated onto a separate network?
07:10
The answer is ‘whatever you’re comfortable with’.
07:13
It’s completely acceptable to join the control and Q-LAN audio networks as seen in the diagram on the left,
07:19
provided QoS is configured to prioritize the time-sensitive services.
07:23
It’s also ok to separate the control network from the Q-LAN network as seen on the right.
07:28
It requires management of more networks and more network equipment, however,
07:32
and it won’t work better as a result.
07:35
It does provide some isolation of functionality, so there’s no harm if you like it that way.
07:41
Alright, let's take a quick break right there and we'll come back and talk about another scenario.
Downloads and Links
Q-SYS Networking and Topologies (Part 1)
7m 48s