Hi Dojo,

Long story short: I have the same device type that has been integrated in two different DMS clusters with two different protocols – I’ve sent a few questions around, via private channels, and apparently there isn’t any good or wrong choice: it seems to just sit with the history of the different DMS clusters and protocols, and with different requirements at different moments – so I’m just posting here now, hoping the community can pull together some answers I’m looking for, scenario by scenario.

Short-term

Having 2 protocols for the same device is not an issue at present, yet our engineering teams (and different deploy squads) need to detail different procedures for different protocols (no mediation layer), at times for the same action via CUBE (e.g. retrieving the trend of the output bitrate), as the element tables have different names and are implemented with a slightly different logic, so even the alarm and trend templates can be quite different.

What are my options now that I’ve noticed this?

Besides, when updating a protocol to cope with a newer software release of the device, in which integration are we adding new features?

In this specific case, both are SL drivers with a recent release:
———————–

———————–

Mid-Term

For more context, I’m talking about the VIRTUOSO FA media node: historically, this was a rebrand of the NX4600 unit, that later evolved into a newer appliance running different media accelerators (see Thomas’ feedback here), but also still able to offer all the software-defined redundancy switches that were previously running in the NX4600 models.

Apparently, when the manufacturer released the newer series of appliances, API compatibility was preserved, so that the DataMiner protocol for TNS4200 probes could also be used for Virtuoso FA nodes: the TNS4200 is indeed what’s used in the second cluster (Element Type “Analyzer”), vs the NX4600 protocol in the first DataMiner System (Element type “Video Gateway”).

Adding some visual reference in the following picture:
—————————————————————————————-

———————————————————————————————

From a commercial point of view, both protocols were bought for different devices in the first cluster, so I guess both seemed a viable option for the implementation at the time of the deployment in the second DMS. For simplicity, I’m omitting details about our VIRTUOSO MI units, as these are present only in the second cluster and have their own protocol, as shown above.

We’re evaluating new DVEs and we have to build service templates too, so I’m keen to understand which protocol would best fit our use cases: NX46 or TNS42?

Is there a central log for features available in one protocol that are not implemented in the other?
Is switching and seamless switching supported in both protocols as long as it’s licensed on the device? Can both protocols be used also for control purposes? If not, what parameter can be used in TNS42 to trend which input feed is selected as the output of the redundancy switch?

Long-Term

Alternatively, should we just consider a “North-bound” integration with the iPath manager, where this is viable? Or could the SL drivers evolve into some sort of “General Virtuoso Platform” that can export different Child Elements, depending on the equipment that is polled? In case some bookings have to be added later on, what’s the current state of virtual functions with the current protocols?

EDIT: SONY/Nevion and Skyline are both AMWA members – so it might be worth considering the long term scenario in the context of NMOS (IS06).

Thanks,
A.