1. 1 Composite Carrier Profiles SLE-SM Red-1 RID GSFC-03-JP (formerly Add Prototype Carrier Requests to Service Packages) John Pietras

2. 2 Outline Summary of issues with current Carrier Profiles Proposed restructuring of Carrier Profile informational content Proposed restructuring of CSP/RSP operations PSP message contents –PSP-I –PSP-AR –PSP-SR –PSP-FR Issues and proposed resolutions

3. 3 Summary of Issues with Current Carrier Profiles The Red-1 CSP-I* requires that forward and return links be scheduled as individual space link carriers –However, many TT&C networks (e.g., AFSCN, USN, DataLynx) schedule forward and return links as single aggregated links –Also, the NASA Space Network (SN), allows scheduling of both aggregated (forward/return) and individual (single forward or return) space links. Lack of this capability in SLE-SM represents a step backward for adoption of SLE-SM by SN. The Red-1 CSP-I does not allow fixed time relationships to be enforced between carriers other than exact start time (no lag or lead) and duration (no minimum value) –Currently no way to specify “Give me a window starting between 1055 and 1105 and lasting from 10 to 15 minutes, with the forward link starting 1 minute after the start of the return link and ending 1 minute before the end of the return link” The userIds and start and stop time offsets associated with the SLE transfer service instances must specified in each Service Package –Simple missions will probably want to establish static userIds and offsets as part of standing profiles *References to CSP-I also apply to RSP-I throughout

4. 4 Additional Issues Not in the Cited RIDs Problems with current TS service “pool” approach –TS service instance start and stop time offsets are defined to be set to the individual carriers’ acquisition start and stop times. However, this contradicts the intention to allow transfer service instances to span multiple scenarios –TS service instance lowerBoundReportingPeriod, timeoutPeriod, notificationMode, deliveryQuality, transferBufferSize, latencyLimit, allowedFrameQuality, and allowedChannelFrameGvcids are tied to the Carrier Profile, which may change during a change of scenario These should be constant across all scenarios Rules could be established to check consistency during CSP/FSP validation/performance, but it would be easier to normalize the profiles remove redundancy

5. 5 Overview of Proposed Approach Allow a single Carrier Profile to contain configuration information for multiple component link carriers –A component link carrier is equivalent to the current (Red-1) space link carrier, i.e., a single forward or return link Allow the start and stop times of the component link carriers to be offset from the start and stop times assigned to the composite carrier in a given Service Package Allow transfer service profiles to completely define default transfer service instances, with ability to override values to provide Service Package-specific flexibility present in Red-1 CSP –Enables simple missions to forego having to configure static transfer service instances for every Service Package –Also provides flexibility for bilaterally-defined carrier profiles that are not constrained to RAF, RCF, and FCLTU services Establishes transfer service profiles as configuration profiles that are independent of individual component link carrier profiles –Carrier profiles reference the transfer service profiles –Eliminates possibility of inconsistent definition of the “same” transfer service profile when it is referenced by different carrier profiles Adds some “hooks” for extending applicability and flexibility beyond CCSDS 401 and the 3 currently-supported SLE transfer services (RAF, RCF, and FCLTU)

6. 6 Red-1 Capabilities of Carrier Profiles A single carrier profile specifies the RF, modulation, and production (e.g., frame-synching, error correction) for a single forward or return link A single carrier profile specifies the SLE transfer service profiles that are to be enabled during the execution of that profile –transferServiceConfigProfileId, currentTsVersion, functionalGroupId, lowerBoundReportingPeriod, timeoutPeriod specified for every potential transfer service instance (RAF, RCF, or FCLTU) –deliveryQuality, transferBufferSize, and latencyLimit specified for all RAF and RCF transfer service instances –allowedFrameQuality specified for all RAF transfer service instances –allowedChannelFrameGvcids specified for all RCF transfer service instances –notificationMode specified for all FCLTU transfer service instances The transfer service profiles do not contain sufficient information to instantiate a transfer service instance –serviceInstanceNumber, userId, startTimeOffset, and stopTimeOffset are supplied by the Service Package

7. 7 Red-1 Carrier Profile Structure (from ACP-I) Transfer service configuration parameters may be set to different values for the “same” service instances!!

8. 8 Red-1 Capabilities of CSP (1) CSP-I must specify each individual forward and return space link carrier –Specifies the time window –References the Carrier Profile that has the detailed configuration parameters for that carrier CSP-I must create the pool of SLE transfer service instances (SleTransferServices) to be used during the execution of the Service Package –“Inherits” transferServiceConfigProfile parameter values for the referenced transferServiceConfigProfileRef –Specifies the serviceInstanceNumber, startTimeOffset, and stopTimeOffset for each transfer service instance CSP-I must identify which transfer service instances are associated with each carrier (ServiceMappings) –via transferServiceInstanceNumberRef (note – name inconsistency)

9. 9 Red-1 Capabilities of CSP (2) For these cross references to work properly, CM must validate that: –ServiceInstanceRequests in the SleTransferServices pool have unique serviceInstanceNumbers –Each serviceMapping references a transfer service instance in the SleTransferServices pool (and the service types must match) –Each transfer service instance in the SleTransferServices pool has a transferServiceConfigProfileRef that matches at least one transfer service configuration profile in a Carrier Profile that is referenced in the CSP-I* –Each transfer service instance in the SleTransferServices pool is referenced by at most one serviceMapping per scenario* –When multiple scenarios involve the same transfer service instances, the parameter values of the “same” transferServiceConfigProfiles across the referenced carrier Profiles are actually the same* *These constraints are not specified in Red Book-1 but should be

10. 10 Red-1 CSP-I Structure

11. 11 Capabilities of Proposed Carrier Profiles (notional) A carrier profile specifies the RF, modulation, and production (e.g., frame-synching, error correction) for one or more component forward, return, or bilaterally-defined link carriers Each component forward or return link carrier that is included in the carrier profile has a nullable linkCarrierStartTimeOffset and nullable linkCarrierStopTimeOffset relative to the start and stop times of the carrier (which is specified via the Service Package) –These can be null only if there is a single component link carrier in the profile Each component forward or return link carrier that is included in the carrier profile specifies the SLE transfer service instances that are to be enabled during the active period of that carrier –Each service instance reference assigns the serviceInstanceNumber that is to be used with that transfer service config profile when it is used in conjunction with that particular component link carrier –Each service instance references a separate (new) transfer service configuration profile that is defined independently of the carrier profile –NOTE – Each F401SpaceLinkCarrier can now contain only one forward transfer service instance Each component link carrier that is included in the carrier profile specifies a nullable linkCarrierNumber for that link carrier –Used to identify the individual link carriers in the CSP-SR (see later) –Used to correlate Event Sequences with component link carriers when compound carrier profiles are used in CSP-Is –Each component link carrier has a linkCarrierNumber that is unique within the carrier profile –linkCarrierNumber can be null only if there is a single component link carrier in the profile

12. 12 Proposed Carrier Profile (notional)

13. 13 Capabilities of New Proposed Transfer Service Profiles (notional) A transfer service profile specifies all parameters of a transfer service instance except the serviceInstanceNumber –transferServiceConfigProfileId, currentTsVersion, functionalGroupId, lowerBoundReportingPeriod, timeoutPeriod specified for every potential SLE transfer service instance (RAF, RCF, or FCLTU) –deliveryQuality, transferBufferSize, and latencyLimit specified for all RAF and RCF transfer service instances –allowedFrameQuality specified for all RAF transfer service instances –allowedChannelFrameGvcids specified for all RCF transfer service instances –notificationMode specified for all FCLTU transfer service instances –defaultUserId, defaultStartTimeOffset, and defaultStopTimeOffset for every potential service instance completes (default) specification of SLE transfer service instances –The new BilateralTransferServiceProfile allows new transfer service types to be accommodated before they are formally adopted into the SLE-SM specification(s) E.g., FSP, or test version of CSTS services Consolidation of (almost) all transfer service instance parameters into a single profile minimizes inconsistencies in creation of service instances (especially in multi-scenario Service Packages)

14. 14 *New* Proposed Transfer Service Profile (notional)

15. 15 Capabilities of Proposed CSP-I (default transfer services) CSP-I specifies one or more CarrierRequests –Each CarrierRequest references the Carrier Profile that has the detailed configuration parameters for that “carrier” Each “carrier” can be either a single carrier or a compound carrier, depending on the referenced Carrier Profile –The time window associated with each CarrierRequest is the “base window” for that CarrierRequest Each component link carrier may have its window shifted from the base window by the start and stop offsets for that component link carrier Offsets are useful for fixed relationships between carriers – e.g., routinely don’t start the high rate telemetry link until 5 minutes after the command link has been activated Per-Service-Package timing relationships can still be controlled by specifying multiple CarrierRequests, each of which references a Carrier Profile with a single component link carrier CSP-I may use default transfer service instances and service mappings defined in the carrier and transfer service profiles –Not necessary to explicitly create the SleTransferServices pool or specify serviceMappings –All service instances in all referenced carrier profiles are enabled

16. 16 Proposed CSP-I (static transfer services) No directional typing of carrier request To be addressed later in presentation

17. 17 Capabilities of Proposed CSP-I (redefined transfer services) Optional (nullable) data sets allow the same flexibility as the Red-1 CSP-I for specifying transfer service instances CSP-I may modify the pool of SLE transfer service instances (SleTransferServices) to be used during the execution of the Service Package –Specification of a ServiceInstanceRequest with a previously-defined serviceInstanceNumber replaces the previous transfer service instance with one that has the parameters of the referenced transferServiceConfigProfile with the userId, startTimeOffset, and stopTimeOffset overridden –Specification of a ServiceInstanceRequest with a new serviceInstanceNumber creates a new Service Package-specific transfer service instance with the parameters of the referenced transferServiceConfigProfile with the userId, startTimeOffset, and stopTimeOffset overridden CSP-I may modify the transfer service instances that are associated with each carrier (ServiceMappings) –via transferServiceInstanceNumberRef (note – name inconsistency) NOTE – enforced data-typing of RAF, RCF, and FCLTU serviceInstanceRequests and serviceMappings have been removed for simplicity and expandability –Benefit of strong service typing is minimal because application has to type match profile references in any case –Removal of typing is not central to this proposal – it can be put back in if desired

18. 18 Proposed CSP-I (redefined transfer services) No service typing of ServiceInstanceRequests No service typing of ServiceMappings

19. 19 Capabilities of Proposed CSP-I (event sequences) Essentially the same as for the Red-1 CSP-I, but now the linkCarrierNumberRef must be specified to associate the Event Sequence with the proper component link carrier NOTE – this structure is consistent with the Red-1 assumption that Event Sequences are associated with what are now being called component link carriers

20. 20 Capabilities of Proposed CSP (concluded) For these cross references to work properly, CM must validate that: –Each transfer service contained in a Carrier Profile references a transfer service configuration profile in the set of Transfer Service Profiles (and the service types must be appropriate) –ServiceInstanceRequests in the SleTransferServices pool have unique serviceInstanceNumbers –Each serviceMapping references a transfer service instance in the SleTransferServices pool (and the service types must match) –Each transfer service instance in the SleTransferServices pool has a transferServiceConfigProfileRef that matches at least one transfer service config profile in Carrier Profile that is referenced in the CSP-I* –Each transfer service instance in the SleTransferServices pool is referenced by at most one serviceMapping per scenario* –When multiple scenarios involve the same transfer service instances, the parameter values of the “same” transferServiceConfigProfiles across the referenced carrier Profiles are actually the same* *These constraints are not specified in Red Book-1 but should be

21. 21 Issue: Deferment of Service Instance Specification Does it make sense to carry the concept of deferment of service instance specification if there are always default transfer service instances available? Propose dropping notion of deferment –If a CSP-I has no serviceInstanceRequest or serviceMapping overrides, then the default service instances are scheduled –If CSP-I has overrides, then the overriden and original (not overridden) service instances are scheduled –Service instances can be subsequently overriden (if desired) using an RSP-I NOTE – this proposal does not include a provision for disabling a service instance that is specified as part of a Carrier Profile, because it does not seem necessary. However, if such a capability were desirable, it could be added to the CSP-I

22. 22 Proposed CSP-SR Almost exactly the same as the Red-1 CSP-SR for 401 forward and return carriers –Scheduled start and stop times and associated service instances and event sequences are reported for each component link carrier (just as in Red-1 version) Expanded to report on bilaterally-defined link carriers –Red-1 currently forces bilaterally-defined link to be either forward or return only –Bilaterally-defined link carrier may now itself be compound, or even something other than “forward” or “return” E.g., tracking entity, loopback test entity –Types and numbers of service instances and/or event sequences to be contained by bilaterally-defined link carriers are left to the specifications of those bilaterally-defined carrier profiles Nullable linkCarrierNumber added to CarrierRequestResult base class to provide traceability to original placement within the referenced Carrier Profile –Null value only if there is a single component link carrier in the referenced Carrier Profile For the purposes of this proposal, the Event Sequence components of > are unchanged NOTE – Similar changes will be necessary for QSP-SR

23. 23 Red-1 CSP-SR

24. 24 Proposed CSP-SR

25. 25 Impact of Separating the Specification (1) Assume that the formal specification of the “standard” Carrier Profile is separated from Service Package Service specification Notional “essential” Carrier Profiles and “essential” Transfer Service Profiles are all that is needed to be negotiated between UM and CM in order for CSP, FSP, and QSP to work Information associated with Essential Carrier Profile –Visible from Service Package Service carrierProfileId linkCarrierNumber for each component link carrier that is to be identifiable by the Carrier Profile –Optional if only one link carrier is identifiable in the Carrier Profile Identification of each link carrier as forward, return, or bilateral Identification of the transferServiceConfigProfileRef and defaultServiceInstanceNumber for each transfer service that is associated with each component link carrier –Not visible from Service Package Service Identification of the configuration parameters (and their respective values) that are needed to unambiguously define a specific configuration of the carrier

26. 26 Impact of Separating the Specification (2) Information associated with Essential Transfer Service Profile –Visible from Service Package Service transferServiceConfigProfileId The type of the service profile: RAF, RCF, FCLTU, or bilateral –Not visible from Service Package Service For SLE Transfer Service Profiles, the list of parameters applicable to the specific service type (see “Capabilities of New Proposed Transfer Service Profiles” slide) For bilaterally-defined transfer service profiles, whatever parameters must be understood by both UM and CM in order for the service to work