Service Package Result Strawman

9 November 2015

Jean-Pierre ChamounNASA - GSFC

www.ccsds.org

Overview

• The <<ServicePackageResult>> 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

www.ccsds.org

Blue-1: ServicePackageResult

www.ccsds.org

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

www.ccsds.org

ServicePackageResult vs.New SP Request Model

NEW SP REQUEST MODELBlue-1

N/A forSP 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

www.ccsds.org

ServicePackageResult vs.New SP Request Model

NEW SP REQUEST MODELBlue-1

N/A forSP 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

www.ccsds.org

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

www.ccsds.org

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

www.ccsds.org

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

www.ccsds.org

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

www.ccsds.org

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

www.ccsds.org

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

www.ccsds.org

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

www.ccsds.org

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

www.ccsds.org

servicePackageIdresultTyperequestThreshold

<<ServicePackageResult>>

FwdOfflineInstNoFwdOfflineProfileRefantennaRefStart/stop

smForwrdOfflineInstanceResult

trajectoryRef

TrajectoryReference

originatingOperationRefSP start/StopSP thresholdSP status

SpaceLinkSessionResult

FR typeOID/name/InstNo

FunctionalResoureProfile

Name/value

RespecifiedParameterResult

combinationProfileRefantennaRefStart/stoptransferServicesDeferredsequenceEventDeferred

ServiceCombinationProfile

udserIDproviderIDportID

OfflineServiceInstanceResult

TsInstanceNoTsProfileRefantennaRefStart/stop

smTsInstanceResult

1..*

1..* 1..*

0..*

1

1

1

1

1

1..*

1

1

1 1

1

0..*

1

scenarioId

ServiceScenario

1

1..*

1

1..*

10..*

{XOR}

1..*

1

udserIDproviderIDportID

SlsTSInstanceResult

1..*

11

10..1

1

serviceReqId

externalRef

1

0..1

1

0..1

eventSequenceRef

eventSequenceResult

1

1..*

10..1

1

2

3

4

6

Service Package Strawman

5

7

www.ccsds.org

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