Abstract Modeling of Service Package Result Components 31 March – 3 April 2014 Noordwijkerhout,...
-
Upload
eugene-brooks -
Category
Documents
-
view
217 -
download
1
description
Transcript of Abstract Modeling of Service Package Result Components 31 March – 3 April 2014 Noordwijkerhout,...
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