1. R2, 23 April 2007 1 Space Link Service Profiles SLE-SM Red-1 RID GSFC-03-JP (formerly “Composite Carrier Profiles” and before that “Add Prototype Carrier Requests to Service Packages”) John Pietras

2. R2, 23 April 2007 2 Outline Overview of changes since R1 of this presentation Summary of issues with SLE-SM red-1 Carrier Profiles and how they are used by CSP (slides 3-5) Overview of proposed approach (slides 6-7) Recap of Red-1 information entities (slides 7-11) Capabilities of proposed Carrier Profile (notional) (slides 13-15) Capabilities of new proposed new Transfer Service Profile (slides 16-17) Capabilities of proposed CSP (slides 18-23) CSPs for Service Packages with no modifications to default Configuration Profile parameter values (slides 24-26) Respecification of Carrier Profile values (slides 27-29) Deletion of Transfer Service Instances (slides 30 – 32) Respecification of Transfer Service Profile parameter values (slides 33 – 35) CSP support for Event Sequences (slides 36 – 38) Deferment of Service Instance Specification (slide 39) Proposed QSP (slide 40)

3. R2, 23 April 2007 3 Overview of Changes Since the R1 Version of this Presentation The main change has been to go back to using “carrier” to refer to the individual space link carrier, and use the term “Space Link Service” to identify the higher-level collection of (possibly) multiple carriers and their associated transfer services Some of the example object diagrams have been updated from the R1 version to illustrate the new terminology, but most have not (due to time constraints) The class diagrams include not only components related to this presentation, but also components that have been included to support offline transfer services, as described more fully in the presentation “Management of Data Retrieval Transfer Services” –Note that the Data Retrieval TS presentation has not been updated to reflect the latest changes (e.g., the use of the “space link service” terminology)

4. R2, 23 April 2007 4 Summary of Issues with Red-1 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

5. R2, 23 April 2007 5 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

6. R2, 23 April 2007 6 Other Capabilities Included in this Proposal Ability to Modify Configuration Profile Contents for a Single Service Package –At the 2007 Colorado Springs meeting, SMWG decided to address the request for an ability to change the EIRP for a given Service Package by providing a general capability to modify any referenced configuration profile parameter value. This proposal includes that capability –NOTE - This proposal does not address modification of Event Profile parameter values on a per-Service Package basis. Such a capability could be added if desired, following the same general approach described herein Support for bilaterally-defined carrier profiles and transfer service instances Provides the framework for including future Cross Support Transfer Services (CSTS) when they are defined Changes the QSP-SR to report all of the parameters of the referenced configuration profiles, in addition to the parameter values set as part of the performance of the CSP operation

7. R2, 23 April 2007 7 Overview of Proposed Approach Allow a single Space Link Service Profile to contain configuration information for multiple space link carriers –The space link carrier retains its Red-1 definition and scope, i.e., a single forward or return link Allow the start and stop times of the space link carriers to be offset from the start and stop times assigned to the Space Link Service Session in a given Service Package –The Space Link Service Session is the result of the scheduling of a Space Link Service Profile 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 contain RAF, RCF, and FCLTU services Establishes transfer service profiles as configuration profiles that are independent of individual space 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) –In particular, adds support for bilaterally-defined transfer services, and the framework fornew CSTSs Add ability to override Space Link Service Profile parameter values

8. R2, 23 April 2007 8 1 sends carrier signals to 1 sends carrier signals to Extension of SLE-SM Resource Model for Bilateral and CSTS Services Associated with an Active Space Link Forward Space Link Carrier Production Forward Symbol Stream Production Forward Link Protocol Production Forward CLTU Transfer Service Provison Return Link Protocol Production Return RAF Online Transfer Service Provision 1 provides symbols to Return RCF Online Transfer Service Provision Return Space Link Carrier Production 1 1..2 provides symbols to 1 provides bitstream to 1 0..1 provides CLTUs to Return Symbol Stream Production 1 provides bitstream to 1 0..* provides transfer frames to 1 0..* provides transfer frames to antenna CSTS Provision is shown in dashed boxes because they represent abstractly where concrete forward and return CSTSs would plug in Return Timely CSTS Provision 1 0..* provides data to Return Online Transfer Service Provision 1 0..* provides data to Forward CSTS Provision 1 0..* provides data to 1 0..* provides data to Forward Online Transfer Service Provision

9. R2, 23 April 2007 9 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

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

11. R2, 23 April 2007 11 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)

12. R2, 23 April 2007 12 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

13. R2, 23 April 2007 13 Red-1 CSP-I Structure

14. R2, 23 April 2007 14 Capabilities of Proposed Space Link Service Profiles (1 of 2) A Space Link Service Profile specifies the RF, modulation, and production (e.g., frame-synching, error correction) for one or more forward, return, or bilaterally-defined space link carriers Each forward, return, or bilaterally-defined space link carrier that is included in the Space Link Service Profile is defined by a contained SpaceLinkCarrier data set that has a nullable carrierStartTimeOffset and nullable carrierStopTimeOffset relative to the start and stop times of the Space Link Service Session (which is specified via the Service Package) –These can be null if the carrier start or stop is equal to the space link session start or stop, respectively –carrierStartTimeOffset can only be used to have carrier start after the space link service session starts (carrierStartTimeOffset >= 0) –carrierStopTimeOffset can only be used to have carrier stop before the space link service session stops (carrierStopTimeOffset <= 0) Each SpaceLinkCarrier that is included in the Space Link Service Profile still specifies a carrierProfileId for that carrier –The value of the carrierProfileId must be unique across all carrierProfileIds within the context of the Service Agreement –Used to identify the 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

15. R2, 23 April 2007 15 Capabilities of Proposed Space Link Service Profiles (2 of 2) Each forward, return, or bilaterally-defined space link carrier that is included in the space link service profile specifies the maximum set of transfer service mappings that are to be associated with the active period of that carrier –Each service instance references a separate space link session (SLS) transfer service (TS) configuration profile that is defined independently of the space link service profile SLS TSs are used for “online” SLE services (which are dependent on a co-incident space link session, hence the name). The term is used to differentiate these transfer services from “offline” services (as described more fully in the companion briefing “Management of Data Retrieval Transfer Services”) –Return 401 carriers may contain RAF, RCF, or bilaterally-defined return SLS TS mappings –Return bilaterally-defined carriers may contain RAF, RCF, or bilaterally-defined return SLS TS mappings –Each F401SpaceLinkCarrier can now contain only one forward SLS TS instance –Forward bilaterally-defined carriers may contain FCLTU or bilaterally-defined forward transfer service mappings No a priori constraint on the number or combinations of SLS TS mappings allows for bilateral support e.g., for FSP Each transfer service mapping carries an instanceEnabled parameter (default = ‘true’) that can be subsequently set to false for a specific Service Package to remove it from the support configuration

16. R2, 23 April 2007 16 Proposed > Stereotype

17. R2, 23 April 2007 17 Capabilities of New Proposed Space Link Session Transfer Service Profiles A SLS TS profile specifies all parameters of an SLS TS instance except the serviceInstanceNumber* –All transfer service profiles must have a transferServiceProfileId –currentTsVersion, functionalGroupId, lowerBoundReportingPeriod, timeoutPeriod specified for every potential CCSDS transfer service instance (RAF, RCF, and FCLTU) –deliveryQuality, transferBufferSize, and latencyLimit specified for all RAF and RCF transfer service instances (and return CSTSs) –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 CCSDS 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 versions of CSTS services –CSTS profiles may be added as they are defined CSTS profiles may have some inheritance hierarchy, but it’s too early to tell now 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) * serviceInstanceNumber will be provided by CM in the CSP-SR

18. R2, 23 April 2007 18 New > Stereotype

19. R2, 23 April 2007 19 Capabilities of Proposed CSP-I If the Service Package is to include a Space Link Session*, the CSP-I includes a SpaceLinkSession data set that specifies one or more ServiceScenario s, each of which contains one or more SpaceLinkServiceRequests –Each SpaceLinkServiceRequest references the Space Link Service Profile that has the detailed configuration parameters for that “service session” Each “service session” can have either a single carrier or a compound carrier, depending on the referenced Space Link Service Profile –The time window associated with each SpaceLinkServiceRequest is the “base window” for that SpaceLinkServiceRequest Each space link carrier contained in the referenced SpaceLinkServiceProfile may be requested to 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 SpaceLinkServiceRequests, each of which references a Space Link Service Profile with a single space link carrier CSP-I nominally uses default SLS TS mappings as defined in the Space Link Service Profiles, which in turn reference SLS TS Profiles Space Link Service Session parameters can be respecified in the configuration being requested in the CSP-I Default SLS TS instances can be removed from the configuration being requested in the CSP-I Default SLS TS parameters can be respecified in the configuration being requested in the CSP-I Service Packages may also contain (or exclusively contain) configurations of Retrieval Transfer Services, which are a addressed in the companion briefing “Management of Data Retrieval Transfer Services”

20. R2, 23 April 2007 20 Respecification of Configuration Profile Values A CSP-I may contain optional (nullable) RespecifiedParameterList data sets to change the values of referenced configuration profiles for the duration of the single Service Package –SpaceLinkServiceProfileRespecification data sets contain respecified parameters for one or more parameters of a Space Link Service Profile instantiated within a single scenario Note: if the same space link service profile is referenced by multiple scenarios, it must be explicitly respecified for each scenario where respecification is desired –SlsTsProfileRespecification data sets contain respecified parameters for one or more parameters of an SLS TS Profile instantiated within the Service Package Note: respecification of an SLS TS profile parameter applies to all instances of that transfer service throughout the Service Package Each RespecifiedParameterList data set contains a parameter that references the configuration profile that is to be modified, and contains one or more pairs of the following: –A parameterDistinguishedName parameter, the value of which is the unambiguous identifier of the parameter If a referenced configuration profile can have multiple instances of the “same” parameter, the parameterDistinguishedName adds the data to distinguish them (e.g., symbolRate for a carrier profile that has I & Q channels and therefore 2 symbolRate parameters. The parameterDistinguishedName s would (logically) be “I-channel:symbolRate” and “Q- channel:symbolRate” The actual syntax of the parameterDistinguishedName depends on the specific representation mapping used. For XML, it will be an XPath expression –A parameterValue parameter, the value of which is the new value to be applied for this Service Package

21. R2, 23 April 2007 21 > Stereotype Class Diagram

22. R2, 23 April 2007 22 Proposed CSP-SR (1 of 2) If the Service Package includes a Space Link Session, the CSP-SR includes a SpaceLinkSessionResult data set that specifies: –One or more ServiceScenarioResult s, each of which contains one or more SpaceLinkServiceRequest data sets –Zero or more SlsTsInstanceResult data sets, each of which specifies an SLS TS instance Only one SlsTsInstanceResult data set exists in the Service Package Result for each SLS TS instance: if multiple scenarios use the same SLS TS instances, thay all “point” to the single result Each ServiceScenarioResult may contain multiple SpaceLinkServiceResult data sets, each of which maps to a SpaceLinkServiceRequest in the original CSP-I –If the referenced Space Link Service Profile has multiple space link carriers, a separate CarrierResult is reported for each scheduled carrier –Each CarrierResult data set contains a set of TsMapResult data sets, one for each SLS TS instance that is to be associated with that carrier Expanded to report on bilaterally-defined link carriers –Red-1 currently forces bilaterally-defined carrier to be either forward or return only –Bilaterally-defined 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 carriers are left to the specifications of those bilaterally-defined carrier profiles

23. R2, 23 April 2007 23 Proposed CSP-SR (2 of 2) If any of the parameters of a Space Link Service Profile have been respecified in the CSP-I, the ServiceScenarioResult that contains the respecified SpaceLinkServiceResult will contain: – A SpaceLinkProfileRespecResult data set, which is derived from RespecifiedParamterList, and as such contains a RespecifiedParameter data set (see Proposed CSP-I) for each parameter that has been respecified in the Space Link Service Profile –A SpaceLinkServiceProfileInEffect data set, which has the identical structure of the referenced Space Link Service Profile information entity, but contains the parameter values as they have been modified by the CSP-I If a respecification of a Space Link Service Profile includes disabling of an SLS TS instance, the disabled SLS TS mapping data set still appears, but with the instanceEnabled value = ‘false’ If any of the parameters of an SLS TS Profile have been respecified in the CSP-I, the respective SlsTsInstanceResult data set of the CSP-SR will contain: – An SlsTsProfileRespecResult data set, which is derived from RespecifiedParamterList, and as such contains a RespecifiedParameter data set (see Proposed CSP-I) for each parameter that has been respecified in the SLS TS Profile –An SlsTsProfileInEffect data set, which has the identical structure of the referenced SLS TS Profile information entity, but contains the parameter values as they have been modified by the CSP-I For the purposes of this proposal, the Event Sequence components of > are unchanged

24. R2, 23 April 2007 24 > Stereotype Class Diagram

25. R2, 23 April 2007 25 Example 1: CSP for Service Packages with No Modifications to Default Configuration Profile Parameter Values Only one scenario, containing one Space Link Service Request Referenced Space Link Service Profile contains one forward and one return space link carrier –Forward space link carrier profile contains one FCLTU TS instance: “NominalCommand” –Return space link carrier Profile contains two RAF TS instances “HighRateTelem” “LowRateTelem” –No Sequence of Events No respecification parameters appear in CSP-I or CSP-SR

26. R2, 23 April 2007 26 Example 1: CSP-I for Service Package With Unmodified Default SLS Transfer Services

27. R2, 23 April 2007 27 Example 1: CSP-SR for Service Package With Unmodified Default Transfer Services

28. R2, 23 April 2007 28 Respecification of Space Link Service Profile Values The CSP-I may modify the values of Space Link Service Profile parameters to be used during the execution of the Service Package by including in the CSP-I a SpaceLinkServiceProfileRespecification data set contained in the to-be-respecified SpaceLinksServiceRequest data set For each parameter value to be respecified in the referenced Space Link Service Profile, the SpaceLinkProfileRespecification data set contains a respecifiedParameter data set, with: parameterDistinguishedName = the distinguished name of the parameter of the CarrierProfile data set that is to be modified for this scenario parameterValue = the new value of the parameter for this scenario An example of respecification of modulationIndex parameter of return space link carrier “RConfig1” is shown in the following CSP-I object diagram –NOTE THAT THE ACCOMPANYING CSP-SR DIAGRAM HAS NOT BEEN UPDATED

29. R2, 23 April 2007 29 Example 2: CSP-I for Respecified modulationIndex Parameter in Return Space Link

30. R2, 23 April 2007 30 Example 2: CSP-SR for Respecified modulationIndex Parameter in Link Carrier 1 Restates the complete Carrier Profile FandRConfig1 with modified mod Index for link carrier 2 THIS DIAGRAM HAS NOT BEEN UPDATED

31. R2, 23 April 2007 31 Deletion of Transfer Service Instances The CSP-I may delete a default Transfer Service associated with a Space Link Service Profile to be used during the execution of the Service Package by including in the CSP-I a SpaceLinkProfileRespecification data set contained in the to-be-respecified SpaceLinksServiceRequest data set For each transfer service instance to be deleted from the referenced Space Link Service Profile, the SpaceLinkServiceProfileRespecification data set contains a respecifiedParameters data set with: parameterDistinguishedName = the distinguished name of the instanceEnabled parameter of the xxxTsM entity that is to be deleted from this Service Package parameterValue = ‘false’ The following example slides of deletion of the instance of transfer service profile HighRateTelem from Carrier Profile RConfig1 for this Service Package HAVE NOT BEEN UPDATED

32. R2, 23 April 2007 32 Example 3: CSP-I with Deleted Transfer Service Instances THIS DIAGRAM HAS NOT BEEN UPDATED

33. R2, 23 April 2007 33 Example 3: CSP-SR with Deleted Transfer Service Instances Restates the complete Carrier Profile FandRConfig1 with deleted RafTsM for link carrier 1 No TransferServiceInstanceResult for deleted default HighRateTelem profile THIS DIAGRAM HAS NOT BEEN UPDATED

34. R2, 23 April 2007 34 Respecification of Transfer Service Profile Parameter Values The CSP-I may modify the values of Transfer Service Profile parameters to be used during the execution of the Service Package by including in the CSP-I an SlsTsProfileRespecification data set. –In the TransferProfileRespecification data set, the transferServiceProfileRef = the value of the transferServiceProfileId of the target SLS TS Profile within which the parameters to be respecified reside The transferServiceProfileRef must match the transferServiceProfileRef of a default transfer service mapping contained by a Space Link Service Profile that is referenced by a SpaceLinkServiceRequest data set that is contained within the CSP-I –For each parameter value to be respecified in the referenced SLS TS Profile, the SlsTsProfileRespecification data set contains a respecifiedParameters data set with: parameterDistinguishedName = the distinguished name of the parameter of the TransferServiceProfile data set that is to be modified for this Service Package parameterValue = the new value of the parameter for this Service Package The following example slides of respecification of the userId parameter of Transfer Service Profile HighRateTelem have not been updated

35. R2, 23 April 2007 35 Example 4: CSP-I with Respecified userId Parameter in Transfer Service Profile HighRateTelem THIS DIAGRAM HAS NOT BEEN UPDATED

36. R2, 23 April 2007 36 Example 4: CSP-SR with Respecified userId Parameter in Transfer Service Profile HighRateTelem THIS DIAGRAM HAS NOT BEEN UPDATED

37. R2, 23 April 2007 37 CSP Support for 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 Event Profile parameter values will not be respecified by the mechanisms described in this presentation The following examples of two Event Sequences (one forward, one return) associated with the composite carrier have not been updated

38. R2, 23 April 2007 38 Example 5: CSP-I for Event Sequences THIS DIAGRAM HAS NOT BEEN UPDATED

39. R2, 23 April 2007 39 Example 5: CSP-SR for Event Sequences Same as currently defined in Red-1 THIS DIAGRAM HAS NOT BEEN UPDATED

40. R2, 23 April 2007 40 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? At the Colorado Springs SMWG meeting, we decided to retain the concept of deferment with the following interpretation: –If transferServicesDeferred is set to ‘true’, then UM must replace the Service Package with a subsequent RSP, or the Service Package will be cancelled by CM –From this, it is inferred that all default TS mappings contained by the Carrier Profile are automatically disabled We will add a rule (I don’t think there’s one now) that transferServicesDeferred can be set to true only if RSP is supported

41. R2, 23 April 2007 41 Proposed QSP This proposal for the QSP operation extends the content of th QSP operation so the complete context of the Service Package is returned The content and structure of the QSP-SR is the same as that of the CSP-SR, with the following differences: –A SpaceLinkServiceProfileInEffect data set exists for each referenced Space Link Service Profile, regardless of whether it was modified in the CSP –A SlsTsProfileInEffect data set exists for each referenced SLS TS Profile, regardless of whether it was modified in the CSP