Trunking is the use of interconnections between two or more intercom matrices, to enable a user on one intercom to talk to a user on another, as if they were on the same system. Audio signals can be transmitted from one matrix to another using a variety of technologies such as AIO, OMNEO, MADI, or RVON (RTS Voice Over Network, a VoIP technology). Figure 1 shows an example that uses AIO audio only to interconnect three ADAM-M matrices.
AIO, OMNEO, and MADI all require physical connections, which of course costs money. If a user on the upper matrix is trying to talk to a user on the lower left matrix, that works provided at least one connection is available. If both are busy, there is no way of getting through. It’s potentially poor use of resources, too. The system has six trunk lines, four of which could have provided an alternate path. The type of static trunking shown in Figure 1 is sometimes called “dumb four-wire” because it transmits audio only, using one pair of cables for audio in one direction, and one pair for the other.
If the system were smart enough, it could have routed the call via the matrix on the lower right. Trunkmaster is a device that will achieve exactly this. Figure 2 shows how it is connected in the system.
In this scenario, the call from our example will go through, provided there’s at least one available connection from the top matrix to the lower right, and at least one from the bottom right to the left. Note the lines going to and from the Trunkmaster are data lines. The Trunkmaster does not transmit audio. It only instructs the matrices to close crosspoints, to enable a call to go through.
Although a more efficient use of transmission capacity is an advantage, the main advantage of trunking is the ability of the system to use the trunks for any system function. The Trunkmaster dynamically decides for which intercom function it wants to use the line. That is not possible in the scenario in Figure 1.
The example above uses RS-485 serial data connections. Trunkmaster has a total of 32 ports for RS-485 data. If the matrix and Trunkmaster are colocated, an RS-485 connection may be the simplest way to create a data connection between the devices. RS485 is independent of any IP network settings because it is a serial protocol, not based on IP. If a serial data connection is not practical, it is also possible to use an IP-based protocol, as shown in Figure 3.
The instructions from the Trunkmaster to the master controllers in each matrix are transmitted as IP-packages, so this architecture goes beyond 32 matrices. In fact, a single Trunkmaster can manage up to 255 matrices, each with 880 ports, for a total of 225,000 ports. By all accounts, a 32 matrix system is a very large system (up to 28,160 ports). Even in the largest trunking system in the world, more than 32 matrices are very rarely active at the same time.
The architecture shown above can be improved in a number of ways, and we’ll look at three ways of making it more resilient.
Using a Redundant Optical Fiber Ring
The architecture shown in Figure 3 is sensitive to individual physical connections going down or getting accidentally disconnected. Physical diversity, e.g., pulling the cables through different ducts, decreases the risk of simultaneous failure of two connections, but is not always easy to achieve. Figure 4 shows an architecture that uses the FMI-4 to create redundancy for each connection. Technically, the FMI is a multiplexer, but they are usually referred to as fiber conversion interfaces or fiber conversion boxes.
The optical fiber ring is highly resilient to faults. First, each green line is actually two fibers. Second, even if both fibers between any two multiplexors are severed or accidentally disconnected, the audio is automatically recovered within microseconds, because there is an alternate path. The optical fiber protocol is capable of carrying analog audio and digital data, in this case the trunking data. An optical fiber ring may only make sense if the matrices are relatively far apart.
Using RVON Protocol Over Internet
The architecture in Figure 4 requires the use of specialized multiplexors to create a very high level of resilience and a fully predictable and fixed latency. A slightly variable network latency (e.g., the delay of individual packets varies) can be accommodated by the RVON protocol, a VoIP protocol developed by RTS. The architecture in Figure 5 shows a solution that uses internet to interconnect the matrices.
The green lines are audio lines that use RVON. This requires the RVON-16 card in each of the matrices. The Trunkmaster data is also transmitted over internet. RVON technology applied to Trunking represents a very realistic use case. In fact, it is the most commonly used solution. Compared to an uncompressed analog signal, some audio quality is sacrificed, but as long as an internet connection is available, an audio path can always be established between the matrices.
In Figure 5, the Trunkmaster itself is still a so-called single source of failure. If it dies, the trunking network will stop working. Figure 6 shows a solution where two Trunkmasters are working in tandem. If one fails, control is shifted to the other. The device that makes this possible is the SWP-2000. The connection between the SWP2000 and the two Trunkmasters uses a proprietary 25-pin cable. The graphic also shows two laptops connected to the SWP-2000, running two software packages for configuration and overview of the trunking network.
A Real Trunked Network
Figure 7 shows a real trunked network from a large broadcaster.
The thickness of the green lines indicate how many trunk lines are available, and the red is what’s actually in use at this very instant. The names of the locations have been removed entirely from the overview, but they would appear in the blue boxes to identify the locations, as well as on the overview pane on the left hand side.