During the LSO orchestration, one PLS shall deal with a delay in configuring the resource because the signal might not be immediately available when the Booking starts.
Because of the lack of a signal, the device won’t report certain information, so we must keep monitoring it until detecting the signal and then setting the other parameters based on a reported value. What is the recommended strategy for this case? I’m thinking of two approaches:
a. Create a custom event on the Booking that shall trigger the monitoring and adjust itself for a future time in case the signal is still unavailable.
b. Modify the device’s connector to allow a push to a queue of the requested configuration so that when the device detects the signal, it configures itself with the passed information. Alternatively, we can push a Profile instance, and the device will trigger the PLS script to complete the configuration.
Gelber,
Can you further describe the use case here ( device type, missing information, … ) ?
I would just add 1 single event ( during on-air ) to check if the missing info is now available. If not available , then booking should be flagged as ‘Failed’. Then, user can still manually force LSO execution, when signal is present.
Regarding option a, you should never update a booking from a script triggered by the booking itself.
Gelber, I presume the signal will be available at the end of the preroll, latest. Therefore, you can add one event 1 min before the end of the preroll to finalize config. Event related to the end of the preroll could still also check if final configuration is still required (in case signal was still not available 1 min before end of preroll ).
If the signal is not available at the end of the preroll, then there is operational impact, so it does not hurt to me to flag the booking as ‘failed’ and have the user checking why signal is not present and manually trigger LSO.
Alternatively, if you already know the service name, you could also implement a feature in the driver to automatically decode a signal for which you provide the service name.
You would then have a dummy parameter to store the target Service Name. As soon as the signal is available, the driver would compare the target service name with the list of services part the incoming signal and tune the receiver accordingly.
I like the idea of implementing the automatic decoding of a signal in the driver itself.
Per the customer’s explanation, the signal might be available anytime during the pre-roll. Still, we should detect and configure it as soon as possible to allow enough time to validate the event before the on-air start time.
That should really be evaluated on a case per case basis, and implementing something extra in the driver should be considered as an exceptional case. We should not start adjusting all drivers to hand over the orchestration to the Elements.
In this case, this is a decoding feature we sometimes see on Decoders, so it does not really hurt to implement similar feature in the driver.
Thanks for the feedback Emmanuel. The use case is for the DMG3200 on which the received satellite signal might be available at any time during the pre-roll.
Without the signal, the device won’t decode and report the service number that should be used to complete other configuration parameters.
As this is an operative constraint, we can’t tell an initial check event time (let’s say 5 minutes after the start of preroll), and forcing the user to apply the configuration when the signal is available manually, will defeat a bit the purpose of the orchestration. However, I can also imagine the possibility of implementing a very simple toggle mechanism that will trigger a correlation rule to keep the automatic reconfiguration. I’ll definitively discard option a.