With Release 2020-2, vsmStudio (B2333) comes with a fundamental change in the internal processing and visualization of crosspoints. This short summary explains the differences to former versions of vsmStudio, as well as the reasons and implications of the changes.

Summary

Cross Point Centric (CPC) is a new method of processing and visualization of crosspoints within vsmStudio. CPC aims to immediately confirm crosspoint triggering actions to VSM users when operating in IP environments, even if the controlled systems do not respond in time. CPC applies the mechanisms to handle asynchronous status of multiple controlled systems and interprets a summarized crosspoint status towards the user to respond immediately and transparently to user actions on hardware and software panels. The CPC mechanisms include various methods to recover flows across a network, if they encounter issues during initialization or runtime.

Background

When switching a flow in an IP environment, multiple systems are involved and the controller will manage them all in order to create a proper route. When data is supposed to travel from a sender to a receiver across a network, the controller triggers at least the receiver and the network (directly or via SDN) in order to ensure a route. More systems may get involved, depending on signal workflows.

All involved systems must be regarded as self-contained systems, exchanging their status separately with the controller. Some of them will respond fast, others may need more time. Consequently, the controller must be able to manage all statuses and responses triggered by a single user action in a way, which allows to generate a clear action feedback to the operator. This is essential, as the user will otherwise retrigger his action or report an issue.

The large number of controllable systems from third-party providers and their individual behavior makes it impossible to adapt the traditional VSM mechanism for visualizing the crosspoint status, which is based solely on system feedback. Instead, a fundamental change in the VSM processing was required, which enables both: to allow controlled systems the time required for a reaction and at the same time to give the operator immediate feedback on his actions.

With CPC, this change has been addressed.

So, what's new?

There are two fundamental differences to all former versions of vsmStudio.

  1. vsmStudio now uses the internal matrix as reference for the desired initial crosspoint status to drive crosspoint visualization in hardware and software panels.
  2. Crosspoint commands get buffered in VSM in order to recall them in case a route has not been completed.

The "desired" Routing State

If an operator triggers a crosspoint by pressing the corresponding keys on a panel (or by recalling a salvo, etc.), he desired to change the routing state of the system deliberately. vsmStudio generates and sends all necessary commands to control the infrastructure accordingly. If all involved system would immediately process the routing commands and send feedback, the system status would equal the desired state.

In vsmStudio, the related crosspoint would then be indicated as "blue dot" (see above) in all layers where it is hosted. CPC does not change anything about this, as the mechanism aims to set this final status, in which all cross points are shown in blue, where the desired status corresponds to the set status.

With CPC, the trigger of a route results in two separate actions: Firstly, the desired routing status represented by the VSM internal matrix is immediately updated, as the user desires a specific route to change. Secondly, the corresponding commands will be sent into the infrastructure.

If a controlled system (e.g. an edge device) is now unreachable or reacting late, there will be no or a delayed answer from this device.

With CPC, vsmStudio is now using the "desired" state of the internal matrix to visualize the crosspoint and to confirm the trigger action towards the user. In a matrix view, the crosspoint is indicated as "orange dot" (see above). This indication means, that there has been a valid trigger to change the routing status of the system, but not all involved systems have positively responded to this trigger. However, the matrix status is used to confirm the user action.

The Command Buffer

At the same time, CPC buffers all relevant commands for this specific route.

If the disconnected device returns into operation (above), VSM will resend the commands buffered for all devices involved in the specific route.


This happens automatically and without the need of manual interaction. Assuming the device responds positively to the commands which have been resent, the crosspoint status in the matrix view will change from "orange" to "blue", indicating a matching status between "desired" and "set".

Crosspoint Visualization

The two different crosspoint states in VSM matrix (orange and blue dots) will be indicated accordingly on LBP panels, but with a different color scheme.

An orange crosspoint status (not all involved systems have responded) will be indicated to the user by a purple key (top left), which turns into blue once the flow is completely established.

On a software panel, incomplete crosspoints will be indicated by a red framing around the source key.

CPC in Combination with Tielines

CPC has been firstly introduced for operation in pure ST2110 IP network setups. Setups using tielines to bridge IP routes between baseband crossbars currently underlie some operational restrictions, which will be described here. These restrictions are temporary and will be addressed shortly.

For efficiency reasons, it is good practice to let VSM decide autonomously which path a signal travels through an infrastructure, when switching sources to targets. The tool widely used for this is a signal tieline, which will cover the IP path from the transmitting device across the network to the receiving device and is managed through VSM. The trigger for VSM to manage a tieline is a the routing command at the baseband crossbar on the target side. That being said, it becomes clear that the successful end-to-end routing of a signal depends on the accessibility of the receiving edge device as such.

Everything is Connected

When VSM can connect to both, the transmitting and the receiving device, crosspoints can be properly set. CPC will indicate the crosspoint to the end user.

Transmitting Device (TX) is missing

When VSM can connect to the receiving device only, crosspoints can be properly set or prepared. The information required for the tieline to prepare the path is stored in vsmStudio, which enables the process. CPC will indicate the crosspoint to the end user and will ensure the flow is completed as soon as the transmitting device is back in operation.

Receiving Device (RX) is missing

When VSM can connect to the transmitting device only, crosspoints can't be properly set or prepared. Although all information required for the tieline to prepare the path is available, the triggering of the tieline will not be possible in vsmStudio, as control of the baseband crossbar in the receiving device is not possible. CPC will not be able to indicate the crosspoint to the end user. A valid routing process requires the RX device to return.

Disable CPC per Target or Globally

Some workflows require that Crosspoint routing is controlled in parallel or exclusively by another, external Controller instance. For instance, an external Studio Automation System is requested to trigger stream patches directly in a device that is also controlled by VSM. In this case VSM cannot act as single Master and therefore the CPC behavior, as described above, is not applicable. For this situation it is possible to disable the default CPC processing on Signal base or even globally.


To disable CPC processing per target, open the Properties view of the respective Target by double-click on the Signal Path (1). Open the tab Attributes (2) and check the box for "Disable CPC (where applicable)" (3). Confirm with OK (4).


To disable CPC processing globally, a setting has to be done in the Server Registry (1). Navigate to "HKEY_LOCAL_MACHINE\SOFTWARE\VirtualStudioManager\vsmStudio\Settings"(2) and if not yet present, create a new String Value entry.


The Value name has to be cpc disable (1). Set the respective Value data to true (2). Confirm with OK (3).

In order to enable CPC set the Value data accordingly to false.


Editing the System Registry incorrectly can cause serious issues that may require you to reinstall the operating system. We cannot guarantee that problems resulting from the incorrect use of the Registry Editor can be solved. Use the Registry Editor at your own risk.


Questions and Answers

A: As some devices might need more time to react after a reboot or a reconnect, the buffer recall will be triggered up to 3x in sequence. The earliest recall will be triggered after 20s, the final recall will be triggered after 1min.
A: If the time between trigger and response takes longer than the buffer recall period, another recall will be initiated, but the first positive incoming answer will be stop this cycle and change the crosspoint visualization.
A: No, there is no limitation. CPC applies for the entire path end-to-end.
A: The basis for the crosspoint indication is the internal crosspoint status of vsmStudio, which is synchronized across all servers of a cluster. This means that all panels will indicate the correct crosspoint status independent to which server a panel is connected to.
A: vsmStudio continuously monitors the status of a crosspoint, even if it renders "blue". If vsmStudio identifies a difference between desires status and the status of the controlled system, it will try to reset the status following the processes described above.