This removes the requirement for any other form of signal splitting or replication to not only simplify the physical design and installation process, but potentially allow an almost infinity flexible signal path topology that can be deployed as required, and without any physical re-wiring.

In analogue and SDI environments, connecting all signals to cross-point routers to provide this same level of flexibility would have resulted in a very big and expensive routing system. Consequently, signals were split, often using Distribution Amplifiers (DAs) and point-to-point cables, so the signal could be carried to the receiving equipment with only a limited number of sources and destinations being presented to the router.

Fig 1 shows a typical SDI signal flow comprising an incoming source being split by a DA to feed both monitoring equipment and the router. The output side of the router shows a studio REM (Remote Source) being split to feed the various destinations within a production studio. The use of a DA at this point not only reduces the number of router outputs required but also ensures that the same signal is reaching the various, related, destinations.

Is any of this still relevant in an IP routing environment?

With the dramatically increased flexibility IP routing has over traditional SDI cross-point routers and DAs, comes the increased potential for erroneous routes being set up when multiple flows need to be changed together. Fig. 1 shows that if the Source flow to the Monitoring and then into the router is taken in isolation, the resultant IP Flows, shown in Fig. 2 look very simple. However, if the physical source needs to be changed, for instance due to equipment failure, previously, only a single cable would need to be moved to the new device and all destinations including the Monitoring, would receive the new source. In the IP environment this becomes much more complex. Either the new device would need to be configured to be the same as the old source device in terms of IP addressing, or all the destinations, including the Monitoring, would need to have new flows established using the credentials of the new source device.

The situation becomes more complex for the studio REM flow, or flows, that are feeding the receiving equipment, as it will probably be altered on a regular basis as the requirements of the production change. Having to remember which destinations are being fed with a particular source and then re-routing the new source to all of them in a timely manner, is best not done manually if errors are to be avoided.

It is theoretically possible to use some of the switch’s functionality to, in some way, mirror packets from one port to others, but this is not usually selective at an IP addressing level so all packets from Port X would appear on Port Y, which becomes an issue if Port X has multiple flows from differing sources and Port Y only requires a few of these to fulfil its routing requirements. This method is operationally inconvenient as the switch would need to be reconfigured each time the routing needed to change

Therefore, the Broadcast Control System (BCS) needs to replicate the functionality of a DA so that making one route change will re-route the selected source flow to all required receiving destinations. The BCS can do this in two ways, it could be configured to check the source routed to a particular destination and, should this change, route the new source to a list of other destinations. Although this would work, it would require a large degree of customisation that is not easily changed from the normal user interface. The other method involves the use of Virtual Signal Paths (also known as Virtual Destinations) where additional destinations and associated sources are included in the routing environment that are not related to any physical device.

A Brief Overview Of Virtual Signal Paths

The router control system within the BCS comprises one or more logical router levels which control and monitor physical routing environments, each level having sources and destinations associated with physical IO or IP flows. An example of this is a ST2110 environment having video (-20), audio (-30) and data (-40) flows all on the same physical IP infrastructure. The BCS would have a logical level for each flow type. Each logical level would control the same IP fabric, and on each logical level there would be sources and destinations associated with the physical transmitters and receivers of the same signal type.

In addition to physical associations, each level can also have virtual sources and destinations, with each virtual destination having a matching source. Sources with physical associations can be routed to virtual destinations, but no actual physical routing is made, a source name is simply recorded as being routed to a virtual destination.

When a virtual source is routed to a destination with an association to a physical device, the physical source feeding the virtual source’s related virtual destination is routed to the physical destination.

A virtual source may be routed to a physical destination without its related virtual destination having any physical source routed to it. Some BCS do not update the Routed Source Mnemonic related to the physical destination until a physical source has been routed to the virtual destination, if this is the situation for the user’s BCS, it is best practise to either arrange that a holding source is always routed to the virtual destinations when there is no operation source, as this would cause the Routed Source displays to update with the virtual sources name, or ensure that the order of setting routes follows the signal flow starting with the physical source.

In designing the structure of the Broadcast Control System’s routing sub-system, care is needed in the naming of device flows and virtual points. In Fig. 3, the source that will be routed by the system user is actually the virtual path (called Source) not the physical device (Device A), therefore it will be the virtual path that will be carrying the user-friendly source names (Sat Rx 1, SVR 5, etc.) and not the physical devices. In fact, physical devices may not be included on any standard router control UI at all, their routing to the virtual path sources may possibly be only undertaking by system maintenance engineers.

Similarly, the studio REM virtual path would be the operational destination to which users would route the required signals, and the onward routing to the physical devices would effectively be fixed and may only be available for advanced system users to modify if needed.

Virtual paths may be routed to other virtual paths, using the signal flow shown in Fig. 4 as an example, the user would route a virtual source (here called Source) to a virtual destination (here called REM), in order to route the output from Device A to the various destinations within the studio. The routing of Device A to Source and REM to the various points within the studio having been previously established.