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.
Some essential background information before we tackle your questions. Details of the Nevion products you mentioned from what we understand.
TNS4200 https://nevion.com/wp-content/uploads/2015/11/Nevion_TNS4200_data_sheet_R1730-1.pdf
NX4600 https://nevion.com/wp-content/uploads/2015/11/Nevion_NX4600_data_sheet_R2107.pdf
Virtuoso Platform https://nevion.com/wp-content/uploads/2016/08/Nevion_Virtuoso_Platform_R2051.pdf
Below is the summary status of our protocols from the catalog (courtesy of DataMiner services)
NX4600 https://catalog.dataminer.services/result/driver/4250 since 2016, firmware version supporting up to 2.8.3, last change 2021
TNS4200 https://catalog.dataminer.services/result/driver/3366 since 2015, firmware version supporting up to 2.0.0.7, last change 2019
Virtuoso MI https://catalog.dataminer.services/result/driver/6708 since 2020, firmware version supporting up to 1.2.14, last change 2021
These are all different product offerings from Nevion; hence Skyline provides separate drivers for these products. Maybe the underlying API interface and technology are the same. As Skyline provides the drivers catering different
customer needs, we have developed the features customers requested rather than unifying the features in all drivers.
Short Term:
As detailed in the old thread, Skyline doesn't provide the driver for Virtuoso FA driver. We can develop a new driver based on the requirements you have. Features are added as the customer's request for the TNS4200 and NX4600 drivers; hence they are not consistent. These protocols may be working for you, but they are not designed in the way they are currently getting utilised.
Mid Term:
Our understanding is that Virtuoso FA, NX4600 are separate devices and offerings; it would be great to collaborate with you and Nevion to understand the rebranding part of the devices. Virtuoso MI driver is also designed to support
the newer virtual platform, which has many media functions, so we do see a possibility to merge media functions into this driver. Whether that would be DVE's or some other mechanism will depend on the features users are requesting.
Long Term:
We need to work with the users and Nevion to streamline some of these services and clarify future development.