Abstract Modeling of Service Abstract Modeling of Service Package Result ComponentsPackage Result Components

31 March – 3 April 2014Noordwijkerhout, Netherlands

John PietrasGlobal Science and Technology, Inc., Greenbelt, MD, USA

www.ccsds.org

Purpose of This Analysis/Presentation

• To fulfill CSSMWG Action Item #2013-1031-04: “Create an abstract model of service package result components”

2

www.ccsds.org

Purpose Of the Service Package Result

3

• Identifies the Functional Resource instances and the connections among them that comprise the Service Package Result• Implicitly identifies the SCCS services that have been scheduled• Specifies the values of the configuration parameters of those Functional

Resource instances• Used to confirm settings• Used to specify exact configurations/values when the flexibilities of the Service Package Request

allowed multiple possible configurations/settings

• Contains the Functional Resource Name of each Functional Resource in the Service Package• Needed to identify the sources of monitored parameter values and event notifications (and the targets

of future real-time control directives)

• Contains the time(s) at which the services will be available• Identifies the “locations” at which the services will be available

• ESLT aperture locations• Network addresses

• Documents the provenance of the Service Package• Closes the loop on Service Package Requests• Useful for Service Accounting purposes

• Other forms of Service Package “result”?

www.ccsds.org

Three Kinds of Service Package Results

• SLS Service Package Resulto Schedules the space link resources and real-time transfer services for

moving data across those space linkso Expansion of B-1 SLS Service Package Result

• Retrieval Service Packageo Schedules/configures the return data transfer services and associated

production processes for retrieving data from an ESLT data store during or after the SLS that generated that data

o Expansion of B-1 Retrieval Service Package Result

• Forward Offline Service Packageo Schedules/configures the forward transfer services and associated

production processes for moving data into an ESLT data store before the SLS is available

o New

• More kinds?

4

www.ccsds.org

Components of the SLS Service Package Result

• Identificationo Unique and unambiguouso In Blue-1, this was the same as the ID of the Service Package Request

Not so simple in all situations, e.g., a single Recurrent Service Package Request can spawn multiple Service Package Results

• Provenanceo Same Service Package ID can be associated with multiple versions of the

Service Package Request, e.g., when a Service Package is replacedo 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

o Identification and provenance could be combined in an appropriately constructed naming scheme

• SLS Functional Resourceso Instanceso Start/stop timeso Groupings (e.g., scenarios)

• External relationships/constraints (maybe?)

5

www.ccsds.org

SLS Service Package Functional Resource Instances (1 of 4)

• Grouped by Functional Group (FG)o (Space Link) Physical Channel FRso Sync and Channel Coding FRso Space Data Link Protocol FRso SLS Data Delivery Production FRs

Data Delivery Transfer Service Mapso Offline Data Delivery Production FRs

Data Sinkso 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

6

www.ccsds.org

SLS Service Package Functional Resource Instances (2 of 4)

7

ApertureFG

ForwardPhysicalChannelTransmissionFG

ReturnPhysicalChannelReceptionFG

ReturnSyncAndChannelDecodingFG

ReturnSpaceLinkProtocolReceptionFG

ForwardSpaceLinkProtocolTransmissionFG

ForwardSyncAndChannelEncodingFG

SpaceInternetworkingFG

ServiceManagementFunctionsFG

DataDeliveryProductionFG

A

A

A

A

S

A

S

S

S

S

S

S

A A AS

S

S

S

A A A

A

A

A

S

DataDeliveryTransferServicesFG

A A AS A

RadioMetricDataProductionFG

A A

A S

RadioMetricDataProductionFG

RetrievalRadioMetricDataProductionFG

AA

S

S

A

OfflineDataDeliveryProductionFG

S A

SA

www.ccsds.org

SLS Service Package Functional Resource Instances (3 of 4)

8

www.ccsds.org

SLS Service Package Functional Resource Instances (4 of 4)

• At least 2 versions of each FR type in an SLS Service Packageo Terse

Just enough information to tell the user what all of the Functional Resource Names are

o Verbose Contains all of the configuration parameters and their initial values

9

www.ccsds.org

Start/Stop Times

• In Blue-1 Service Package Result, containment determined the start/stop times of production functionalityo Classes without start/stop times inherited them from their containing

classes

• Assumption: all start/stop times will continue to be expressed as absolute timeso No need to express relative or conditional times

• Some options for expression of start/stop timeso Every FG instance

Unambiguous but full of opportunities for inconsistencieso Implied containment

Inheritance through SAP/Accessor ports pairso Some sort of “wrapper” around configurations

May limit extensibilityo External Start/Stop time component that references every FR under its

purview10

www.ccsds.org

Groupings

• Grouping by Configuration Profileo 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

o 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

o 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 scenarioo No identification of scenario inherent in FRso Possible approaches are similar to those for grouping by start/stop timeso Scenario should be optional – many providers don’t intend to use it

• Grouping by ESLT/relay satelliteo Inherent in the identification of the specific aperture(s) that are used

• Other kinds of groupings?11

www.ccsds.org

External Relationships/Constraints

• Coupling the Service Package to external events or entitieso E.g., Service Packages across multiple Provider CSSSes for 3-way

tracking, D-DOR serviceso Could imply some communication among Provide CSSSes

• Would it apply to a whole Service Package or just a subset?o If the whole SP, then it could be handled as identification and/or

provenance

12

www.ccsds.org

Components of the Retrieval Service Package Result

13

• Identification

• Provenance (?)o No current use for this in the Retrieval Service Package

• Retrieval Functional Resourceso Instanceso Start/stop timeso Groupings

• External relationships/constraints (?)

• Assumption: return DTN services across the terrestrial WAN will require no scheduling in the User CSSS – Provider CSSS Service Package senseo There may be some coordination with the SSP ISP, but that’s a different

Information Entity

www.ccsds.org

Retrieval Functional Resources

• In Blue-1, a Retrieval Service Package consists of one retrieval transfer service instance and a reference to one antennao Equates antenna with data store

• Next version needs to be more flexibly definedo 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

o Scheduling of CS File Transfer service files?o 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 couplingo 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

• Is there any need to monitor a Retrieval Service Package?14

www.ccsds.org

Forward Offline Service Package Result

• No precedent in Blue-1

• So far, only identified possible use is for Forward File serviceo Is it even needed for that? Hard to say since the service hasn’t been

defined yeto No other transfer service-based forward services in Service Catalog 1

or 2

• Assumption: forward DTN services across the terrestrial WAN will require no scheduling in the User CSSS – Provider CSSS Service Package senseo There may be some coordination with the SSP ISP, but that’s a different

Information Entity

• Is there any need to monitor a Forward Offline Service Package?

15

www.ccsds.org

Concluding Thoughts Inspired (at the Last Minute) by the Previous Material

• 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 Packageo E.g., when the Provider CSSS satisfies 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 instanceso Multiple results for a single request is already on the table for recurrent requestso Extended identification and provenance information would support traceability

back to the source request

• Propose to investigate this simplification over the next 6 months

16