1. 1 ProposeServicePackage (PSP) Operation SLE-SM Red-1 RID GSFC-01-JP John Pietras

2. 2 Outline Overview of the PSP operation PSP-related message flow PSP message contents –PSP-I –PSP-AR –PSP-SR –PSP-FR Issues and proposed resolutions

3. 3 PSP Overview This operation supports rule-based scheduling (sometimes known as generic scheduling and standing order scheduling), in which the Complex (TT&C service provider) generates candidate contacts for a space mission based on rules (e.g., “An uplink of between 15 and 20 minutes is required four times a week, no closer than 20 hours and no farther apart than 50 hours.”) How the mission and the Complex agree to use rule-based scheduling, and how the rules themselves are formulated, are outside the scope of the definition of this operation –For the purposes of SLE-SM Blue-1, these can be established bilaterally The expectation is that the PSP would be used for routine, on-orbit support (e.g., only one scenario would be proposed) –However, there is nothing in the proposal that would prohibit CM from proposing multi-scenario service packages (if those happen to make sense and CM is able to do that) –Similarly, nothing prohibits CM from generically scheduling a contact that uses an Event Sequence, but that would rely on CM’s ability to do so and a bilaterally- established approach for making it meaningful The PSP is a 3-phase operation, with CM as the Invoker and UM as the Responder Try to reuse as many existing CSP building blocks as possible

4. 4 PSP Flow The spaceflight mission and the TT&C/SLE service provider Complex agree to support rule-based scheduling for the mission The mission and the Complex mutually establish the Carrier Profiles (and Event Sequence Profiles?) by which Service Packages will be proposed The mission and the Complex mutually establish the rules by which Service Packages will be proposed –Rules include references to Carrier Profiles and Event Sequence Profiles which have been established prior to the establishment of the rule set E.g., a rule might be hypothetically phrased something like “Execute Carrier Profile XYZ three times a week for between 10 and 30 minutes each time” –For the purposes of this proposal, establishment of the rule set is accomplished by bilaterally-defined means CM is provided with trajectory information that spans the complete time during which the CM is to provide rule-based support to the mission During Complex operations, on whatever timeline, CM identifies one or more potential space link sessions that satisfy the rules for the Mission For each such potential space link session, CM tentatively schedules the contact and generates a PSP-I –See PSP Contents slide for details UM must explicitly accept or reject each proposed Service Package –When accepting (PSP-SR) a proposed SP, UM can select a smaller window within the one proposed –If UM does not respond by the timeout, the CM terminates the tentative service package Once the accepted SP is on the schedule, UM can further modify it with RSP, DSP, SAS, and ANT operations, and CM may subsequently cancel (SPC) or modify (SPM) it.

5. 5 PSP-I Contents Inherits from the > and > stereotypes –scheduledAcquisitionStartTime and scheduledAcquisitionStopTime span largest possible window for the proposed space link session –Specific antenna is assigned Transfer service options available to a mission and a Complex –CM could invoke PSP with transferServicesDeferred (simple) Good for Complexes/missions that operate on the “schedule the link time first, sort out the details later” philosophy Would require that successful establishment of SP be followed up with RSP to add the necessary transfer service instances –CM could invoke PSP with all transfer service instances of the Carrier Profile included (simple) Good for Complexes/missions that work with very static configurations Would require that UM follow up with RSP if the set of transfer service instances needs to be trimmed See Issues slide for problem with current Carrier Profile information –CM could invoke PSP with only a subset transfer service instances of the Carrier Profile included (sophisticated) Subset selection would be based on bilaterally-defined rules UM could follow up with RSP if the set of transfer service instances needs to be modified See Issues slide for problem with current Carrier Profile information Event Sequence options available to a mission and a Complex (if Event Sequences are used) –CM could invoke PSP with eventSequenceDeferred (simple) Good for Complexes/missions that operate on the “schedule the link time first, sort out the details later” philosophy Would require that successful establishment of SP be followed up with RSP to add the necessary transfer service instances –CM could invoke PSP with an Event Profile assigned (more sophisticated) Event Profile selection would be based on bilaterally-defined rules UM could follow up with RSP if the selection needs to be changed

6. 6 PSP-AR Inherits from the > stereotype Contains a ServicePackageReference data set with a ServicePackageRef parameter Signals receipt of the PSP-I by UM and intention to respond by a specified time

7. 7 PSP-SR Inherits from the > stereotype Has the same composition as > stereotype, except that the CarrierRequestResult data sets do not contain: –ServiceInstanceResult data sets –SpaceLinkEventSequence data sets UM is allowed to modify the scheduledAcquisitionStartTime and scheduledAcquisitionStopTime –Constraints PSP-SR scheduledAcquisitionStartTime > PSP- I scheduledAcquisitionStartTime PSP-SR scheduledAcquisitionStopTime < PSP-I scheduledAcquisitionStopTime –It’s understood that if UM changes the scheduledAcquisitionStartTime and/or scheduledAcquisitionStopTime service instance and sequence event times will be moved in accordance with those times

8. 8 PSP-FR Inherits from the > stereotype PspError data set contains the diagnostics: –‘servicePackageId already in use’ –‘no matching trajectory for trajectoryRef’ PspDenial data set contains the reason: –‘Service Package declined’

9. 9 Issues sleSmCreatorName semantic conflict: PSP-I is created by CM, but the SP is really owned by UM Carrier Profiles do not currently contain userIds, which would be needed by CM to propose a SP without deferring transfer services

10. 10 sleSmCreatorName Semantics Uses of sleSmCreatorName in SLE-SM service specification 1.Identifies the sender of a message set 2.Allows messageSequenceNumbers to be unique and incrementing across multiple message sources 3.Used for ascertaining permission to communicate within the context of a given Service Agreement (“static” access control) 4.Used for establishing “ownership” (modification/deletion rights) of Service Packages, Carrier Profiles, and Trajectory files Eliminates possibility of two creators issuing contradictory operations on a single data entity Eliminates message sequence ambiguity for operations on a single data entity Normally, the creator of the message set that contains the invocation that creates the data entity is the “owner” of that entity –However, for the PSP, the PSP is created by CM on behalf of UM: UM owns it but CM is the creator of the invocation message

11. 11 Possible Solutions to sleSMCreatorName Conflict Treat PSP as special case –Creator name containing an operation’s invocation would still nominally identify the owner –For PSP, ownership would be redefined Service Agreement would specify the UmCreatorName that owns the SPs that are created via the PSP in the context of that Service Agreement Add an explicit “owner name” to the PSP-I –Confirms the owner, but otherwise doesn’t solve the problem CM still needs to know from the Service Agreement who the owner is and where to send the PSP-I Let MDOS own the information entity –Levy requirement on MDOS to enforce exclusivity among “creators” (if necessary) by local means –Might require changes to message sequence rules –Service Agreement would still need to identify the performer of the PSP operation, and CM would need to send PSP-Is to that performer –Related to RID JPL-SZ-15 (which was rejected) Define ownership of information entities on an operation-by-operation basis –Ownership no longer defined as inherent in “sleSmCreatorName” –Each operation has text (template?) that defines how ownership is established –Will produce a few more word than Red-1, but ambiguity would be reduced (also solves RID JPL-SZ-48) Recommend defining ownership on operation-by-operation basis

12. 12 Carrier Profiles Do Not Contain userIds Proposed solution –Add optional (nullable) default userId value for each TransferService profile in the CarrierProfile CM would use the default value to populate the service instances in a PSP –Details will be included in the proposed resolution for RID GSFC-03-JP (forthcoming)