My Satellite Downlink Service Definition contains 2 functions linked to the same L-Band matrix element. One function represents the inputs while the other one represents the outputs of the matrix.
I'm wondering what is the best approach to make sure that the crosspoint is set correctly?
- Do I need to make the linked output(s) available in the input function?
- Do I need to make the linked input available in the output function?
- Is there another way?
Hi Alberto,
Showing the source port(s) and destination port(s) in the east-west service overview comes with advantages compared to showing a matrix X-pt view. Of course, in the service overview, the matrix ports are filtered to the specific media or L-band signal which is very convenient, so as an operator, you only see the data relevant to the selected service or connection. DataMiner can easily add KPI’s to the port visuals as well (signal presence, and for IP systems, any and all port counters such as bitrates, packet errors/drops, etc,), the historical trending and even show alarm status on the ports in use. In SDI and L-Band systems, there are less or no KPI’s to monitor, and the signal path is pretty deterministic (so that operators do not need to look into the specific underlying connections / tie lines). In an IP world, things are different. More information/LPI’s to monitor, dynamic paths rather than fixed tie-lines, and as you mention, multicast IP is really different. Not only because network operators tend to manage the systems from a source perspective and not only from a destination perspective like XY panels offer today. Adding to that, IP connectivity often comes with multiple possible paths to select from, the networks are often blocking (even if only the site interconnects are) and therefore require capacity planning and reservation, and operators may want to have control over the exact point in the network where the multicast streams will flow/be duplicated in a point-to-multi-point connection (hence also the importance of SDN control in DataMiner).
Talking about matrix control, as you mentioned yourself, going into multicast IP stretches the matrix views and XY panels that emerged from an environment in which 1 cable was transporting one signal to route. Of course, we do support matrix view on the element, and could indeed include that in a customer setup. We also have very rich router control panels, enhanced with lot of info (UMD labels, but also things like viewing all destinations connected to a specific source, and even showing the exact signal path!). See https://community.dataminer.services/use-case/software-router-control-xy-panel-operations/. In addition to that, we even have control panels that can be fully customized (not limited to XY, but any imaginable workflow can be initiated by those). You can see an example here https://community.dataminer.services/use-case/production-management/
Btw, we are now even working (I expect MVP in Q1 2021) on sharing those control panels over our DataMiner Cloud Platform. That will allow an end-customer to monitor and control connections direct on the service provider infrastructure.
Thanks for your feedback. Steven
Looking to point 3) If the L-Band matrix configuration is static, this means, Antennas and demodulators are always connected to the same Input/Ouputs, you can use Resource Properties to achieve this, instead of making the Matrix IOs available as resources.
This way, your LSO script can verify what antenna and demodulator are booked, read its resource properties and set the appropriated crosspoint in the L-Band router. Reference to L-Band router name can be also done under another resource property.
Again, this is considering a use case where the L-Band matrix configuration is static.
Subscribed – interested in knowing what are the choices done by others.
In terms of option 1 or 2, I’d prefer 2 – this seems the approach that is also used in the router control app for L-band routers: ops select the destination output first and then the input, then click “Connect” to set the cross-point.
In other routing systems you may want to select the input and send it to multiple outputs (e.g. application layer “iPath” approach – one source sent to multiple outputs represented as a single source “routed” to multiple destinations, even if the actual “sets” are all on the destination units that receive a command to join a new multicast).
As for option 3, would it be feasible to represent just the I/O cross-point functions, or do you need to keep the Input function separated from the Output function?
From a TX point of view, e.g. in a 16×16 matrix, you’d have 256 possible cross-points (plus the “no routing / parked” option): would it be possible to represent just the I/O association (the routing function itself) as a combination of the 257 possible selections? The concept would be similar the “matrix” page of any router element, where each possible cross point is represented in DataMiner element as a little square.
HTH,
A.