[Smwg] scheduling windows

[Marcin.Gnat at dlr.de]

Dear all,

Without recalling very good what we talked about this during den Haag meetings (it was for sure my jetlag ;-), I wanted to give some comment from my side to scheduling windows.

As I understand, this idea covers some specific use of the Space Network, whereas users may send to the provider a bunch of time windows in which they are going to use specific service. And as I understand it is somehow equivalent to the direct schedule request (or multiple schedule requests in that term) with specific tolerances. Scheduling Windows give user some more nice functionality to user, as they can decouple the decision on visibilities from the actual service request.

There will be already my first question: we now have SERVICE requests in SM, and we try to get away from schedule requests or pass requests as typically used. Are such multiple scheduling windows stretching over single service? Or one should see it rather as multiple services (accidentally same type) one after another? In the latter case, there would be really no difference to the "normal" service or service package request.

Secondly, my impression is that with that we put here an actual user (or provider) functionality into the interface. I'm afraid with such rather "special" cases, we will blow our standards again to the sizes of SM-1 (or even larger as a matter of fact). I know someone could say this part is "optional" and so on, but still when implementing we have to somehow take care of that.

We will definitely discuss it during Spring Meetings, but in general I'd opt for keeping things simple. The point of the common standard is to have a common version everybody understands, and not to have collection of versions from everybody. And finally, as our SM is "Extensible" it should be easily extensible for specific uses for individual users. So maybe this would be the way to go...

Best Regards
Marcin

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.]
Sent: Dienstag, 20. März 2018 16:41
To: Colin.Haddow at esa.int; CCSDS SMWG ML (smwg at mailman.ccsds.org)
Cc: Barkley, Erik J (JPL-3970)[Jet Propulsion Laboratory]
Subject: [Smwg] scheduling windows

Colin et al, here is a description of scheduling windows (TSWs) as used in the Space Network today, which may help in understanding the use case.

There is text in the SNUG that describes how users can either use the start times in their requests, or TSWs to make sure their services are scheduled within timeslots that make sense:

A MOCC is responsible for ensuring its own customer platform-to-TDRS visibility prior to adding a schedule event. The MOCC may do this directly by submitting schedule requests with start time tolerances that comply with customer platform-to-TDRS visibility requirements or indirectly by submitting TDRSS Scheduling Windows (TSWs) to the NCCDS and then submitting schedule requests that specify that they are to fit within these TSWs. Use of TSWs makes it feasible to submit schedule requests that specify TDRS flexibility and with start time tolerances that exceed a single TDRS view.

The further description of how TSWs relate to the scheduling process is:

Each TSW message contains TSWs applicable to a specified time period for a single customer-defined TSW set for a single TDRS. The TSWs may be transmitted before, after, or at the same time as the schedule requests that depend on the TSWs. However, if a schedule request requires TSWs from a particular TSW set for a particular TDRS during a certain time period, it cannot be processed if applicable TSWs have not been received.

Each TSW set contains the TSWs applicable to a particular combination of customer visibility constraints based on factors such as antenna type, power, and frequency. Each customer may define as many TSW sets as needed, and may define new TSW sets at any time without negotiation with the NCCDS.

Each SSC (an "SSC" in the SN is equivalent to a configuration profile for us) either specifies the TSW set applicable to the scheduling of the service specified by that SSC, or specifies that TSWs are not applicable. A TSW set is a re-specifiable parameter.

If it is useful, I can provide a description of the fields in a TSW, but the short story relevant to Colin's question about included/excluded times is that a TSW set consists of the included windows, and there is not a notion of excluded windows.  If not in the included windows, then a time is understood to be excluded.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180328/40651995/attachment.html>