Simplified Configuration Profiles And Service Profiles 8 May 2017 John Pietras Global Science and Technology, Inc. Updated on 9 May 2017

Purpose of the Simplified Configuration Profiles To identify the minimum set of requirements that will allow TT&C networks to develop their own localized configuration profiles ASAP that will meet the content requirements necessary to support: SMURF Service Package Request Simple Schedule Service Package Result Event Sequences MD-CSTS, and SC-SCTS To set the groundwork for defining fully-standardized CCSDS configuration profiles

Outline Background General concepts for configuration profiles and service agreements Minimum requirements for simplified configuration profiles Example: SMURF Service Package Request -> Simple Schedule & Service Package Result Space Link Service Profiles Next steps

Background: SCCS-SM Blue-1 (2009) Monolithic configuration profile structure (Space Communication Service Profile) Support for CCSDS 401, TM, TC, and AOS Sync and Coding and Space Data Link Protocols, and RAF, RCF, and FCLTU SLE services No easy way to incrementally insert new RF modulation schemes, sync and channel coding, space data link protocols, or remaining SLE/new CSTS transfer services Limited timing offset relationships among “carrier” subsets within Space “Extensibility” via all-or-nothing bilateral substitution of “something else” for CCSDS-standard configuration profile Tied to, and validated against, Service Agreements Allowed for dynamic creation of configuration profiles and automated validation thereof Makes most sense in the context of a Configuration Profile Service Little or no linkage between configuration profiles and Simple Schedule categories of “service” – telecommand, telemetry, Doppler, etc.

Background: “Next Generation” Configuration Profiles (2010 – April 2016) Modular, plug-and-play approach to allow new technologies to be introduced at differing rates Adoption of Functional Resources as the “modules” Groupings of Functional Resources into larger plug-and-play blocks (Functional Groups -> Service Components -> Functional Sets) Service Access Points (SAPS)/Accessors, required/provided ancillary interfaces Originally envisioned elaborate framework and documented construction rules that would allow practically anyone to generate new configuration profile component specifications Large effort would be required to create the detailed construction rules Scaled back approach: new component specification kept within CSSMWG fro foreseeable future Also tied to, and validated against, Service Agreements Structure of Service Agreement would mimic that of configuration profile Extensible method for expressing timing relationships among components of configuration profiles Still no obvious relationship to Simple Schedule “services”

Background: Cleveland Meeting – April 2016 SMURF Service Package Request relies on configuration profile at the mechanism for specifying configuration values Respecification capability of Service Package Request relies on mutually-agreed set of configured Functional Resource instances Simple Schedule scheduled “services” must somehow relate to the resources requested via the SMURF Monitored Data CSTS relies on configuration profiles to relate the resources that are scheduled to the monitored values being reported Realization: not enough funded resources identified to develop a fully-articulated Configuration Profile (and Service Agreement) Blue Book within the timeframe needed for SMURF, Simple Schedule and MD-CSTS Conclusion: develop requirements that allow locally-developed configuration profiles to be usable with SMURF, Simple Schedule, Service Package Result, MD-CSTS, Event Sequences, and SC-CSTS Not intended to constitute a full, interoperable specification (although it should be able to evolve into one) All timing specification/relationships deferred to the Service Package Request itself Highly desirable to relate configuration profiles to traditional TT&C service categories

General Configuration Profile Concepts Use of configuration profiles is the de facto method that TT&C networks employ for configuring contacts (a.k.a. passes, tracks, Events) Configuration profiles is the CCSDS name – actual TT&C networks currently have their own network-dependent names (e.g., SN service specification codes (SSCs), NEN Support Activity Codes) Today, each TT&C network has its own syntax and semantic rules for its configuration profiles Common characteristics of configuration profiles They represent a collection of space communication and radiometric data processing resources They contain the initial values of the configuration parameters of all of the resources in the collection They represent the relationships among the resources Data flow between space link and interface to user ground element(s) “Lateral” data flows between forward and return links (e.g., CLCW throttling of forward link) They have identifiers that are used in service package requests as short-hand indicators for what is being requested Service package requests and resulting schedules associate start/stop times with configuration profiles For some TT&C networks, respecification (in the service request) and/or reconfiguration (real-time control, event sequences) of individual configuration parameter values must relate to configuration profiles

General Service Agreement Concepts Service agreements define the boundaries or envelopes of agreed service within which configuration profiles may be created and used Multiple service agreements between a Provider CSSS and a Mission may exist concurrently: service agreements must have identifiers to indicate the context in which configuration profiles (and Service Package Requests) exist The primary benefit of standard-formatted, machine-readable (e.g., XML) service agreements is to support automation of configuration profile validation E.g., when a submitted configuration profile fails validation, the rejection response can report the reason in a standardized way The only appearance of service agreement information in SMURF Service Package Request, Service Package Result and Simple Schedule is reference to the SA identifier to establish the context A standardized Service Agreement format is not needed until automated configuration profile creation and validation becomes available Until then, configuration profiles can be validated manually or by locally-defined validation processes

Minimum Requirements for Simplified Configuration Profiles (1 of 2) They represent a collection of space link data processing resources in the form of Functional Resources. Individual Functional Resources must be identified in terms of the CCSDS-standard (SANA-registered) Functional Resource Type (an OID) and FR Instance Number, as required by: respecification in the SMURF Service Package Request, the verbose mode of the Service Package Result the terse mode of the Service Package Result for those FR instances that have respecified configuration parameters (proposed) Event Sequences (TBD) MD-CSTS SC-CSTS They represent the values of the configuration parameters of all of the resources in the collection. Each configuration parameter is identified by its CCSDS-standard (SANA-registered) parameter ID (an OID), as required by: respecification in the SMURF Service Package Request

Minimum Requirements for Simplified Configuration Profiles (2 of 2) They represent the interconnection of the resources Identification of the actual interconnection among the Functional Resources is not exposed in the SMURF Service Package Request, MD-CSTS, SC-CSTS, or Event Sequence. Therefore, representation of this information can be left to the local network to define in the simplest configuration profiles that still meet the needs of SMURF Service Package Request, Simple Schedule, etc. E.g., XML containment, inter-FR connection parameters They have identifiers that are used in service package requests as short-hand indicators for what is being requested The SMURF specifies this identifier as a string, with no other syntax or semantic requirements The Simple Schedule does not reference configuration profiles MD-CSTS and SC-CSTS do not know or care about configuration profile identification The Event Sequence will need to be able to reference the configuration profile(s?) that specify the initial configuration parameter values

Notional Simplified Configuration Profile (Space Link Session/Online) (UPDATED)

Notional Simplified Configuration Profile (1 of 2) Each Simplified Configuration Profile has a Configuration Profile identifier (syntax TBD) and a Service Agreement reference Each Simplified Configuration Profile is composed of one or more Space Link Service Profiles All space link services scheduled from a single configuration profile have the same start/end time offsets from the Service Package The start/end offsets for a configuration profile are set by the Service Package Request Multiple configuration profiles can be used in the same Service Package Request to specify differing start/end time offsets Each Space Link Service Profile is composed of the Functional Resource instances that are appropriate to that space link service type, from Aperture through Transfer Service instance(s) and/or offline storage For Transfer Service instances, user-definable offsets could be defined (as in SCCS-SM B-1). Alternatively, for simplified profiles, the offsets could be defined uniformly (or calculated) by the Provider CSSS. Topic for research and discussion

Notional Simplified Configuration Profile (2 of 3) Each FR Instance has a FR Type, an FR Instance Number (FRIN), and a set of configuration parameters and values All FR types have an isConfigured parameter that is used for respecification of configurations in Service Package Requests Space Link Service Profiles may share the same Functional Resource instances within the same Configuration Profile Shared FR instances indicate that the corresponding physical resources are to be shared, e.g.: Aperture that is “shared” between a forward service and a return service Forward space link carrier and return space link carrier that are shared with a ranging service Approach to be explored this summer – use of FR instance aliases Only the original FR instance contains all of the parameters and parameter values for the FR instance Each “piggy-backed” service contains only an alias of that FR instance – in essence, just the FR Name. Use of aliases would reduce the tedium of specifying redundant data, chance of inconsistent specification of the same parameter value

Notional Simplified Configuration Profile (3 of 3) Simplified Configuration Profile requirements do not specify how required relationships among the FR instances are expressed Until a fully-standardized CCSDS Configuration Profile is defined, any Provider CSSS that develops configuration profiles that conform to the Simplified Configuration Profile requirements must still express these relationships. Some candidate approaches might include combinations of: XML containment Required/Provided interface pairs Space link data channels Once the requirements for simplified configuration profiles are agreed, the standardization of the expression of the relationship information can be addressed. Once that has been done, the result will be a CCSDS-standard, fully-interoperable Configuration Profile No assumptions made about how configuration profiles are validated No requirements (for now) for CCSDS-standard, parameter-by-parameter Service Agreements

Multi-Service Configuration Profiles vs Multi-Service Configuration Profiles vs. Multiple Single Service Configuration Profiles Multi-service configuration profiles Advantages Inter-service relationship information is internal to the configuration profile Routinely-used groups of services called in with only one reference Disadvantages All services in config profile share the same offsets The same Service Profile has to be repeated in each Configuration Profile that uses it Multiple single-service configuration profiles Each service can have its own timing offsets Unique Service Profiles need to be created only once each Inter-service relationship info may have to be “wired up” by Service Package Request Possible mitigation: default connections that are only re-specfied if needed Slide added on 9 May 2017

Service Package Request with 3 Single-Service Configuration Profiles Example (1 of 3) The Mission has established (among others) three configuration profiles with the Provider CSSS: A profile for a Telecommand service (Configuration Profile ID = “standardTelecommandConfiguration”) with the Frequency Band attribute set to “S-Band”; A profile for a Doppler service (Configuration Profile ID = “standardDopplerConfiguration”) with the Frequency Band attribute set to “S-Band”; and A profile for a Telemetry service (Configuration Profile ID = “standardTelemetryConfiguration”) with the Frequency Band attribute set to “S-Band” This Telemetry service profile contains 3 RAF Provider FR instances (FRINS 1, 2, and 3) SMURF Service Package Request is used to schedule a service package that uses the 3 configuration profiles with the following offsets with respect to the Service Package Telemetry service using “standardTelemetryConfiguration” operates full duration of service package (15 minutes) Command service using “standardCommandConfiguration” has start time offset by 120 seconds (starts 2 minutes after service package start time) and end time offset by 600 seconds (ends 10 minutes before end of service package) Doppler service using “standardDopplerConfiguration” has start time offset by 360 seconds (starts 6 minutes after service package start time) and no end time offset (ends at end of service package) The Service Package Request also removes the third RAF service instance from the Telemetry service The requested duration of the Service Package itself is 15 minutes

Service Package Request with 3 Single-Service Configuration Profiles Example (2 of 3)

Service Package Request with 3 Single-Service Configuration Profiles Example (3 of 3) Establishes Service Package duration of 15 minutes Currently required even though it is empty

Resulting Simple Schedule (1 of 2)

Resulting Simple Schedule (2 of 2) Revised on 9 May 2017

Resultant “Simplified” Service Package Result - Terse Mode ServicePackageResultDetails object scheduled service package start and end times Service object (serviceType = Telecommand) References “standardTelecommandConfiguration” as the source configuration profile Service start (<Pkg Start + 120 secs>) and end (Pkg End - 600 secs>) times frequencyBand = “S-Band” Telemetry Service object (serviceType = Telemetry) References “standardTelemetryConfiguration” as the source configuration profile Service start (<Pkg Start >) and end (Pkg End >) times Contains OIDParameter object for re-specified RAF TS Provider FR parameter fRType-OID = {RAF TS Provider} fTInstanceNumber = 3 Parameter-OID = {isConfigured} parameterValue = FALSE Doppler Service object (serviceType = Doppler) References “standardDoppler Configuration” as the source configuration profile Service start (<Pkg Start + 360 secs>) and end (Pkg End>) times Revised on 9 May 2017

Resultant “Simplified” Service Package Result - Verbose Mode ServicePackageResultDetails object Scheduled service package start and end times Contains VerbServicePkgResult object containing: ConfigurationProfileContents object with Ref “standardTelecommandConfiguration” All contents the same as original configuration profile ConfigurationProfileContents object with Ref “standardTelemetryConfiguration” All contents the same as original configuration profile except respecified isConfigured parameter of 3rd RAF TS Provider FR instance ConfigurationProfileContents object with Ref “standardDopplerConfiguration” All contents the same as original configuration profille Service object (serviceType = Telecommand) References “standardTelecommandConfiguration” as the source configuration profile Service start (<Pkg Start + 120 secs>) and end (Pkg End - 600 secs>) times frequencyBand = “S-Band” Telemetry Service object (serviceType = Telemetry) References “standardTelemetryConfiguration” as the source configuration profile Service start (<Pkg Start >) and end (Pkg End >) times Doppler Service object (serviceType = Doppler) References “standardDoppler Configuration” as the source configuration profile Service start (<Pkg Start + 360 secs>) and end (Pkg End>) times Revised on 9 May 2017 .

Space Link Service Profiles The term space link service refers to one of the “services” enumerated by the ServiceType parameter of the Simple Schedule Formats Blue Book, the current draft version of which is 902x1b0_working-1.1-20170201-CRH.doc* APA-AZ/EL APA-X/Y DELTADOR DOPPLER OFFLINE-TM-RECORDING OFFLINE-TM-PROVISION RF-ONLY RANGING TELECOMMAND** TELEMETRY VLBI A space link service profile is a configuration of Functional Resource types that collectively perform that space link service More than one configuration of FR types may perform a space link service – e.g., different return space link protocols may be used in different configurations of the Telemetry service *The services listed here do not include the ServiceType enumerated values ‘Reserved’, ‘TBD’, ‘Test’, or ‘Unused’ **For the purposes of this exercise, the name “Telecommand” for this service is assumed to apply to space links that use any forward sync and channel coding and space data link protocol (in particular, AOS) and not be confined to the Telecommand sync and channel coding and space data link protocol (CCSDS 231.0 and CCSDS 232.0, respectively). Perhaps the ‘Telecommand’ enumeration name should be changed to something like ‘Command’ to reduce the potential confusion

Differences between Space Link Service Profile Concept and FR RM Tech Note Service Profile (1 of 2) The draft Functional Resource Reference Model Technical Note concept of service profile was formulated in terms of the IOAG Service Catalog #1 data delivery services Forward Data Delivery Services Group Forward CLTU Forward Space Packet Forward Synchronous Encoded Frame (Forward Frames)* Forward File Return Data Delivery Service Group Return All Frames Return Channel Frames Return Operational Control Field Return File Radiometric Services Group Validated Data Radiometric Raw Data Radiometric Delta-DOR * CCSDS is not developing a separate Forward Synchronous Encoded Frame (FSEF) service but is proceeding directly to the Forward Frames service (an IOAG Catalog #2 service), which encompasses the capabilities of the FSEF service

Differences between Space Link Service Profile Concept and FR RM Tech Note Service Profile (2 of 2) The FR RM service profile for any given data transfer service includes any FR instances that might be involved in the provision of that transfer service E.g., the F-CLTU and Forward Space Packet service profiles included the return link physical channel, sync and channel decoding, and space data link protocol FRs necessary to receive the CLCWs that are used to gate the forward link and close the COP “Lateral” relationships between protocol stacks were established using ports that linked FR instances E.g., the forward link TC Encap, VC Pkt Processing, and VC Gen FR instance (which performs the COP) must be linked to the port of the return link VC Demux and Reception FR instance that extracts the CLCWs use by the COP In contrast, the space link service profile contains only those FR instances in the primary path of the service between aperture and data transfer/storage When fully fleshed out, the space link service profiles will identify the relationships among the FR instances within the profile, and define the means by which lateral relationships across space link service profiles are to be expressed In the meantime, the simplified Space Link Service Profiles must rely on Provider-CSSS-specific information in the configuration profiles to express these relationships

Space Link Service Profile Mapping (1 of 2) Space Link Service Profiles are technology-specific: each uses a specific set of Functional Resource types As new technologies are included in configuration profiles, the new combinations will result in new Profile types E.g., use of Forward 415 Space link Carrier Transmission FR instead of (the current) Forward 401 Space Link Carrier Transmission FR will require a new Space Link Service Profile Simplicity of cookie cutter configurations will result in combinatorial growth – at least in the near term this will be acceptable for simplified Configuration Profiles

Space Link Service Profile Mapping (2 of 3) Forward Communication Space Link Service Profiles Forward CLTU (maps into the TELECOMMAND Simple Schedule Service Type) Telecommand Multiplexed (maps into the TELECOMMAND Simple Schedule Service Type) Forward AOS CADU (maps into the TELECOMMAND Simple Schedule Service Type) Forward AOS Multiplexed (maps into the TELECOMMAND Simple Schedule Service Type) Return Communication Space Link Service Profiles Return Online Communication (maps into the TELEMETRY and OFFLINE-TM-RECORDING Simple Schedule Service Types) Offline RAF Delivery (maps into the OFFLINE-TM-PROVISION Simple Schedule Service Type) Offline RCF Delivery (maps into the OFFLINE-TM-PROVISION Simple Schedule Service Type) Offline Return File Delivery (maps into the OFFLINE-TM-PROVISION Simple Schedule Service Type)

Space Link Service Profile Mapping (3 of 3) Radiometric Space Link Service Profiles Aperture Pointing Angles (maps into the APA-AZ/EL or APA-X/Y Simple Schedule Service Types) Doppler (maps into the DOPPLER Simple Schedule Service Type) Ranging (maps into the RANGING Simple Schedule Service Type) Delta-DOR (maps into the DELTADOR Simple Schedule Service Type) Open Loop (maps into the RF-ONLY Simple Schedule Service Type) Aperture Pointing Angles (APA), Doppler, and Ranging can be provided “raw” in real-time and delayed (complete mode) via TD-CSTS TD-CSTS standard allows multiple RM data types to be reported in the same TDM -> TDM Segment Generation and TD-CSTS Provider FR instances are shared by the service profiles Service Management Function Profiles Monitored Data Service Management Function Profile Service Control Service Management Function Profile

Issues with Radiometric Space Link Service Profiles No Simple Schedule Service Types for offline RM data provision Presumably, the Simple Schedule Service Types APA (both AZ/EL and X/Y), DOPPLER, RANGING, DELTADOR, and RF-ONLY refer to these data types are being acquired during the scheduled Space Link Session, and possibly delivered concurrently (i.e., online) for the APA, DOPPLER, and RANGING types There are no Simple Schedule Service Types for offline provision (delivery) of radiometric data parallel to OFFLINE-TM-PROVISION Pointing Angles, Doppler, and Ranging are provided offline via TD-CSTS in Complete mode (for “raw” data ) or validated via TGFT Delta-DOR and Open Loop data are provided offline via TGFT Production processing and delivery of validated APA, Doppler, and Ranging data (IOAG Validated Data Radiometric service) Each of these data types use a Non-validated Radiometric Data Collection and a Non-validated Radiometric Data Store FR instance If two or more of these data types are being acquired concurrently during a space link session, do they each get their own separate FR instances or do they share the FR instances (especially the Data Store(s)?

Forward CLTU Space Link Service Profile If Forward CLTU service is used, only one CLTU service instance can use that forward space link service

Telecommand Multiplexed Space Link Service Profile Handles all data delivery services over Telecommand other than CLTU Must be trimmed by each mission to included only the data delivery services used by that Mission

Forward AOS CADU Space Link Service Profile If Forward AOS CADU service is used, only one Forward Frames CSTS service instance can use that forward space link service

Forward AOS Multiplexed Space Link Service Profile Handles all data delivery services over Forward AOS other than CADU Must be trimmed by each mission to included only the data delivery services used by that Mission

Return Online Communication Space Link Service Profile Handles all return communication data delivery services Also includes recording Must be trimmed by each mission to included only the data delivery services used by that Mission

Return Offline Communication Space Link Service Profiles

Aperture Pointing Angles Space Link Service Profile Supports both APA-AZ/EL and APA-X/Y This profile deals only with the space link service that is provided during a Space Link Session (i.e., “online”), which includes the storage of Atomic Segments for subsequent retrieval via TD-CSTS and storage of non-validated data for subsequent validation. However, the list of service types in the Simple Schedule book do not include provisions for offline retrieval of angles via TD-CSTS or in validated radiometric data files

Doppler Space Link Service Profile

Ranging Space Link Service Profile

Delta-DOR Space Link Service Profile

Open Loop Space Link Service Profile

Service Management Function Profiles A Service Management Function Profile applies to the whole online (Space Link Session) Service Package of which it is a part: its service instance provision period is equal to the duration of the Service Package Structurally, the Service Management Function Profiles can simple be contained in, and treated as, a configuration profile (no change to Service Package Request) Monitored Data Service Management Function Profile Service Control Service Management Function Profile

Next Steps Update Tech Note (v0.2) to reflect last-minute changes that are contained in this presentation (next two weeks) Respond to comments on: Proposed concepts for configuration profiles and space link service profiles Number and composition of the proposed space link service profiles Flesh out options for expressing relationships within and among space link service profiles XML containment? Provided/required interfaces, space link data channels, or other? Aliases? Produce updated Tech Note (v0.3) by 1 September Goal: Agreed content and structure of simplified Configuration Profiles and Space Link Service Profiles (i.e., content and structure minus expression of relationships) Goal: Have a proposed approach for expressing relationships within and among space link service profiles Goal: Have XML example(s) of Configuration Profiles using the proposed relationship mechanism(s)