service package result strawman 9 november 2015 jean-pierre chamoun nasa - gsfc
Post on 18-Jan-2018
216 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related