Service Package Result Strawman 9 November 2015 Jean-Pierre Chamoun NASA - GSFC

Overview The > stereotype specifies the collection of parameters, and relationships that represent a valid Service Package. The high level definition of the Blue-1 Service Package Result is still applicable but must be update to remain consistent with the work done in the following two areas  Service Agreements and Configuration Profiles New Functional Resource models  New Service Package Request model New Extensibility focus New service package type: Forward Offline Services

Blue-1: ServicePackageResult

Blue-1: ServicePackageResult Retrieval Transfer Service Resource/Time TsProfile Re-specified Params Bilateral Retrieval Transfer Service Resource/Time Space Link Session Service Package Result TS Reference By Scenario: Trajectory results Configuration Profile Carrier Profile Resources/Time ReSpecified Params Bilateral SL Profile

ServicePackageResult vs.New SP Request Model NEW SP REQUEST MODEL Blue-1 N/A for SP Result Gap? Retrieval Transfer Service Resource/Time TsProfile Re-specified Params Bilateral Retrieval Transfer Service Resource/Time Space Link Session Service Package Result TS Reference By Scenario: Trajectory results Configuration Profile Carrier Profile Resources/Time ReSpecified Params Bilateral SL Profile

ServicePackageResult vs.New SP Request Model NEW SP REQUEST MODEL Blue-1 N/A for SP Result Gap? Retrieval Transfer Service Resource/Time TsProfile Re-specified Params Bilateral Retrieval Transfer Service Resource/Time Space Link Session Service Package Result TS Reference By Scenario: Trajectory results Configuration Profile Carrier Profile Resources/Time ReSpecified Params Bilateral SL Profile

ServicePackageResult: Blue-1 Operations and Data Sets Blue-1 SP Operation CREATE_SERVICE_PACKAGE (CSP) REPLACE_SERVICE_PACKAGE (RSP) DELETE_SERVICE_PACKAGE (DSP) SELECT_ALTERNATE_SCENARIO (SAS) APPLY_NEW_TRAJECTORY (ANT) SERVICE_PACKAGE_CANCELLED (SPC) SERVICE_PACKAGE_MODIFIED (SPM) QUERY_SERVICE_PACKAGE (QSP) CONFIRM_TENTATIVE_SERVICE_PACKAGE (CTSP) APPLY_NEW_SPACE_LINK_EVENTS_PROFILE (ANSLEP) The SP Result stereotype is applies to these messages Blue-1Data Sets SpaceCommunicationServiceProfileInEffect SlsTsProfileInEffect RetrievalTsProfileInEffect SpaceLinkSessionServicePackageResult ServiceScenarioResult TrajectoryResult SpaceCommunicationServiceResult SlsTsInstanceResult BilateralSlsTsInstanceResult CarrierResult TsMapResult FspaceLinkEventsResult, RspaceLinkEventsResult BilateralSpaceLinkEventsResult FSpaceLinkAvailableScheduledState RSpaceLinkAvailableScheduledState FSpaceLinkChangeScheduledEvent RSpaceLinkChangeScheduledEvent RSpaceLinkDataTransportScheduledState FSpaceLinkDataTransportScheduledState FSpaceLinkDataTransportChangeScheduledEvent RSpaceLinkDataTransportChangeScheduledEvent RetrievalTsInstanceResult BilateralRetrievalTsInstanceResult Significant work done in these areas since Blue-1 SP Result Operations from Blue-1 are applicable to the new SP abstract. Note that the new UpdateSvcPkg includes the B-1 RSP, SPM, ANSLEP,ANT. SP Result Data Sets will be significantly impacted by the new work in the area of Configuration Profiles, specifically the focus on Functional Resources

ServicePackageResults: Configuration Profiles and Functional Resources New Configuration Profile: Functional Resource Centric  Service Combination Profile ServiceComponentProfile(s) Flexibilities&Constraints  Service Component Profile Functional resource profile

Components of the Service Package Result Identification  Unique and unambiguous  New SP Request implements different IDs for the SP Request and Instance of the SP Note: In Blue-1, this was the same as the ID of the Service Package Request, which was not so simple in all situations, e.g., a single Recurrent Service Package Request can spawn multiple Service Package Results Provenance  Same Service Package ID can be associated with multiple versions of the Service Package Request, e.g., when a Service Package is replaced  B-1 Service Package Results relies on Document Exchange Protocol (DEP) sequence numbers to keep provenance straight A more explicit and non-DEP-dependent method should be explored  Identification and provenance could be combined in an appropriately constructed naming scheme  Does this apply to offline transfer SP? Functional Resources  Instances and Groupings  Start/stop times  Terse and Verbose specification results types Consider External relationships/constraints 9

Service Package Functional Resource Instances Grouped by Functional Group (FG)  (Space Link) Physical Channel FRs  Sync and Channel Coding FRs  Space Data Link Protocol FRs  SLS Data Delivery Production FRs Data Delivery Transfer Service Maps  Offline Data Delivery Production FRs Data Sinks  Data Delivery Transfer Service FRs FRs within a FG specialization are related by containment; FRs in different FG specializations are related by Service Access Point (SAP)/Accessor port pairs Note: Requiring Provision Management to supply the Functional Resource Names in the Service Package Result is a potential burden to users:  Motivation for requiring PM to do so was the possibility of the same configuration profile being used repeatedly in the same Service Package such as would be the case when a request for a single space link by splitting it up across multiple handovers in the same Service Package Result allowing multiple Service Package Results to be provided in response to a single Service Package Request could possibly eliminate this possible redundant use of configuration profile FR instances 10

Service Package Functional Resource Groupings Grouping by Service Type? Grouping by Configuration Profile  Configuration Profiles are used to identify the requested services/functional resources in the Service Package Request, but the Service Package Result does not necessarily have to reflect the organization of those profiles  SCCS-SM B-1 uses references to Configuration Profiles to minimize content of the Service Package Result Space Communication Service Profile Space Link Carrier Profile  In extensible Service Package Result, every FR instance must be individually identified to provide the FR Name No need to group FRs by the configuration profile that triggered them Grouping by scenario  No identification of scenario inherent in FRs  Possible approaches are similar to those for grouping by start/stop times  Scenario should be optional – many providers don’t intend to use it Grouping by ESLT/relay satellite  Inherent in the identification of the specific aperture(s) that are used 11

Service Package Start/Stop Times In Blue-1 Service Package Result, containment determined the start/stop times of production functionality  Classes without start/stop times inherited them from their containing classes Work is still being done to define temporal relationship/specification between service component profiles in the configuration profiles:  Every FG instance Unambiguous but full of opportunities for inconsistencies  Implied containment Inheritance through SAP/Accessor ports pairs  Some sort of “wrapper” around configurations May limit extensibility  External time component that references every FR under its purview This may result in start/stop times of the Service Package Request being expressed as a mix of absolute and relative times  Should the result normalize all times to absolute times? 12

External Relationships/Constraints Coupling the Service Package to external events or entities  E.g., Service Packages across multiple Provider CSSSes for 3-way tracking, D-DOR services  Could imply some communication among Provide CSSSes For simplicity this should apply to the whole Service Package (not just a subset) 13

Summary of Considerations for the Service Package Result 1. Should a more explicit and non-DEP-dependent method should be explored to manage provenance? 2. Do we need a references to identify the trigger for the SPR (e.g. new trajectory, planning request, provider modification etc.)? [yes] 3. Should Provision Management to supply the Functional Resource Names in the Service Package Result? [yes] 4. How should Functional Resources be Grouped [Config. Profiles] 5. Allow for external references to other entities (e.g. ServicePackages) [yes] 6. Allow for verbose and terse representation of the results [yes] 7. New Forward Offline Service 8. No need for explicit bilateral provision 14

servicePackageId resultType requestThreshold servicePackageId resultType requestThreshold > FwdOfflineInstNo FwdOfflineProfileRef antennaRef Start/stop FwdOfflineInstNo FwdOfflineProfileRef antennaRef Start/stop smForwrdOfflineInstance Result trajectoryRef TrajectoryReference originatingOperationRef SP start/Stop SP threshold SP status originatingOperationRef SP start/Stop SP threshold SP status SpaceLinkSessionResult FR typeOID/name/InstNo FunctionalResoureProfile Name/value RespecifiedParameterResult combinationProfileRef antennaRef Start/stop transferServicesDeferred sequenceEventDeferred combinationProfileRef antennaRef Start/stop transferServicesDeferred sequenceEventDeferred ServiceCombinationProfile udserID providerID portID udserID providerID portID OfflineServiceInstanceResult TsInstanceNo TsProfileRef antennaRef Start/stop TsInstanceNo TsProfileRef antennaRef Start/stop smTsInstanceResult 1..* 0..* * * 1 scenarioId ServiceScenario 1 1..* * {XOR} 1..* 1 udserID providerID portID udserID providerID portID SlsTSInstanceResult 1..* serviceReqId externalRef eventSequenceRef eventSequenceResult 1 1..* Service Package Strawman 5 7

Additional considerations for Offline Services In Blue-1, a Retrieval Service Package consists of one retrieval transfer service instance and a reference to one antenna. Next version needs to be more flexibly defined  Multiple transfer service instances per Retrieval Service Package Allows access to groups of users for the period of the service package – supportive of a common playback mode of operation  Scheduling of CS File Transfer service files?  More flexible way of identifying the data stores that the Service Package accesses, e.g.: Named data store at a ground terminal Named data store for the whole Provider CSSS Data store used by a specified SLS Service Package Use case analysis should be done External coupling  Need to be able to share complete-mode CSTSes with SLS Service Packages Current plan is to do this with TS maps, but something else may be required Assumption: return DTN services across the terrestrial WAN will require no scheduling in the User CSSS – Provider CSSS Service Package sense 16