[Smwg] scheduling windows

[Barkley, Erik J (3970)]

Marcin,

I can certainly sympathize with your concern about getting into special cases. I think part of the analysis around this will be to determine whether or not this is truly a special case. As I understand it the time windows in some sense are related to what ESA might call "standing orders".   But I think we will indeed have to have a further conversation as to how SN employs these. And then I think we will need to compare and contrast to the closest mechanisms of various agencies and then tease out whether or not this moves forward as part of the "main body" of the SMURF or as some agency specific extension or as something else.

Best regards,

-Erik

From: Marcin.Gnat at dlr.de <Marcin.Gnat at dlr.de>
Sent: Wednesday, March 28, 2018 4:15 AM
To: wesley.m.eddy at nasa.gov; Colin.Haddow at esa.int; smwg at mailman.ccsds.org; Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Subject: RE: scheduling windows

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<mailto:Colin.Haddow at esa.int>; CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto: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/20180329/b78c0dc9/attachment.html>